./0002755000764400076440000000000014363246651010657 5ustar iustiniustin./draft-ietf-opsawg-yang-vpn-service-pm-15.txt0000644000764400076440000024714114333424442020773 0ustar iustiniustin OPSAWG Working Group B. Wu, Ed. Internet-Draft Q. Wu, Ed. Intended status: Standards Track Huawei Expires: 15 May 2023 M. Boucadair, Ed. Orange O. Gonzalez de Dios Telefonica B. Wen Comcast 11 November 2022 A YANG Model for Network and VPN Service Performance Monitoring draft-ietf-opsawg-yang-vpn-service-pm-15 Abstract The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services that can be used to monitor and manage network performance on the topology of both layers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 15 May 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Wu, et al. Expires 15 May 2023 [Page 1] Internet-Draft Network and VPN Service PM YANG November 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Network and VPN Service Performance Monitoring Model Usage . 4 3.1. Collecting Data via Pub/Sub Mechanism . . . . . . . . . . 6 3.2. Collecting Data On Demand . . . . . . . . . . . . . . . . 6 4. Description of The Data Model . . . . . . . . . . . . . . . . 6 4.1. Layering Relationship between Multiple Layers of Topology . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Network Level Performance Monitoring Augmentation . . . . 9 4.3. Node Level Performance Monitoring Augmentation . . . . . 10 4.4. Link and Termination Point Level Performance Monitoring Augmentation . . . . . . . . . . . . . . . . . . . . . . 11 5. Network and VPN Service Performance Monitoring YANG Module . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.2. Informative References . . . . . . . . . . . . . . . . . 37 Appendix A. Illustrative Examples . . . . . . . . . . . . . . . 39 A.1. VPN Performance Subscription Example . . . . . . . . . . 39 A.2. Example of VPN Performance Snapshot . . . . . . . . . . . 40 A.3. Example of Percentile Monitoring . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction [RFC8969] describes a framework for automating service and network management with YANG [RFC7950] models. It defines that the performance measurement telemetry model should be tied to the services (such as a Layer 3 VPN or Layer 2 VPN) or to the network models to monitor the overall network performance and the Service Level Agreements (SLAs). Wu, et al. Expires 15 May 2023 [Page 2] Internet-Draft Network and VPN Service PM YANG November 2022 The performance of VPN services is associated with the performance changes of the underlay networks that carries VPN services. For example, link delay between Provider Edge (PE) and Provider (P) devices and packet loss status on Layer 2 and Layer 3 interfaces connecting PEs and Customer Edge (CE) devices directly impact VPN service performance. Additionally, the integration of Layer 2/Layer 3 VPN performance and network performance data enables the orchestrator to monitor consistently. Therefore, this document defines a YANG module for both network and VPN service performance monitoring (PM). The module can be used to monitor and manage network performance on the topology level or the service topology between VPN sites. The base model presented here can be extended to include technology- specific details, e.g., adding Explicit Congestion Notification (ECN) statistics for Layer 3 networks or VPN services to support performance-sensitive applications. This document does not introduce new metrics for network performance or mechanisms for measuring network performance, but uses the existing mechanisms and statistics to monitor the performance of the network and the services. The YANG module defined in this document is designed as an augmentation to the network topology YANG model defined in [RFC8345] and draws on relevant YANG types defined in [RFC6991], [RFC8345], [RFC8532], and [RFC9181]. Appendix A provides a set of examples to illustrate the use of the module. 2. Terminology The following terms are defined in [RFC7950] and are used in this specification: * augment * data model * data node The terminology for describing YANG data models is found in [RFC7950]. The tree diagrams used in this document follow the notation defined in [RFC8340]. Wu, et al. Expires 15 May 2023 [Page 3] Internet-Draft Network and VPN Service PM YANG November 2022 2.1. Acronyms The following acronyms are used in the document: CE Customer Edge, as defined in [RFC4026] L2VPN Layer 2 Virtual Private Network, as defined in [RFC4026] L3VPN Layer 3 Virtual Private Network, as defined in [RFC4026] L2NM L2VPN Network Model L3NM L3VPN Network Model MPLS Multiprotocol Label Switching OAM Operations, Administration, and Maintenance OSPF Open Shortest Path First OWAMP One-Way Active Measurement Protocol, as defined in [RFC4656] P Provider Router, as defined in [RFC4026] PE Provider Edge, as defined in [RFC4026] PM Performance Monitoring SLA Service Level Agreement TP Termination Point, as defined in [RFC8345] section 4.2 TWAMP Two-Way Active Measurement Protocol, as defined in [RFC5357] VPLS Virtual Private LAN Service, as defined in [RFC4026] VPN Virtual Private Network 3. Network and VPN Service Performance Monitoring Model Usage Models are key for automating network management operations (Section 3 of [RFC8969]). Particularly, together with service and network models, performance measurement telemetry models are needed to monitor network performance to meet specific service requirements (typically captured in an SLA). Wu, et al. Expires 15 May 2023 [Page 4] Internet-Draft Network and VPN Service PM YANG November 2022 +---------------+ | Customer | +-------+-------+ | Customer Service Models | | +-------+---------+ | Service | | Orchestration | +------+-+--------+ | | Network Service Models | | Network and VPN Service PM Models | | +------+-+--------+ | Network | | Controller | +-------+---------+ | +-----------------------+------------------------+ Network Figure 1: An Example Architecture with a Service Orchestrator The network and VPN service performance monitoring (PM) model can be used to expose operational performance information to the layer above, e.g., to an orchestrator or other BSS/OSS client application, via standard network management APIs. Figure 1 shows an example usage in a layered model architecture described in [RFC8309]. Before using the model, the controller needs to establish topology visibility of the network and VPN. For example, the controller can use network information from [RFC8345], [I-D.ietf-opsawg-sap] or VPN information from the L3VPN Network Model (L3NM) [RFC9182] and the L2VPN Network Model (L2NM) [RFC9291]. Then the controller derives network or VPN level performance data by aggregating (and filtering) lower-level data collected via monitoring counters of the devices involved. The network or VPN performance data can be based on different sources. For example, the performance monitoring data per link in the underlying networks can be collected using a network performance measurement method such as One-Way Active Measurement Protocol (OWAMP) [RFC4656], Two-Way Active Measurement Protocol (TWAMP) [RFC5357], Simple Two-way Active Measurement Protocol (STAMP) [RFC8762], Multiprotocol Label Switching (MPLS) Loss and Delay Measurement [RFC6374] or In Situ OAM (IOAM) [RFC9197]. The performance monitoring information reflecting the quality of the network or VPN service (e.g., network performance data between source Wu, et al. Expires 15 May 2023 [Page 5] Internet-Draft Network and VPN Service PM YANG November 2022 node and destination node in the networks or between VPN sites) can be computed and aggregated, for example, using the information from the Traffic Engineering Database (TED), [RFC7471] [RFC8570] [RFC8571], or LMAP (Large-Scale Measurement Platform) [RFC8194]. The measurement and report intervals that are associated with these performance data usually depend on the configuration of the specific measurement method or collection method or various combinations. This document defines network-wide measurement intervals to align measurement requirements for networks or VPN services. 3.1. Collecting Data via Pub/Sub Mechanism Some applications, such as service-assurance applications, which must maintain a continuous view of operational data and state, can use the subscription model specified in [RFC8641] to subscribe to the specific network performance data or VPN service performance data they are interested in, at the data source. For example, networks or VPN topologies updates may be obtained through on-change notifications [RFC8641]. For dynamic PM data, e.g. VRF routes or MAC entries, link metrics, and interface metrics, various notifications can be specified to obtain more complete data. A periodic notification [RFC8641] can be specified to obtain real-time performance data. For devices/controllers that maintain historical performance data for a period of time, a replay notification [RFC5277] or [RFC8639] can be used to obtain the historical data. And alarm notifications [RFC8632] can be specified to get alarms for the metrics which exceed or fall below the performance threshold. The data source can, then, use the network and VPN service performance monitoring model defined in this document and the YANG Push model [RFC8641] to distribute specific telemetry data to target recipients. 3.2. Collecting Data On Demand To obtain a snapshot of performance data from a network topology or a VPN service topology, service-assurance applications may retrieve information using the network and VPN service PM model through a NETCONF [RFC6241] or a RESTCONF [RFC8040] interface. For example, a specified "link-id" of a VPN can be used as a filter in a RESTCONF GET request to retrieve per-link VPN PM data. 4. Description of The Data Model This document defines the YANG module, "ietf-network-vpn-pm", which is an augmentation to the "ietf-network" and "ietf-network-topology" modules. Wu, et al. Expires 15 May 2023 [Page 6] Internet-Draft Network and VPN Service PM YANG November 2022 4.1. Layering Relationship between Multiple Layers of Topology [RFC8345] defines a YANG data model for network/service topologies and inventories. The service topology described in [RFC8345] includes the abstract topology for a service layer above Layer 1 (L1), Layer 2 (L2), and Layer 3 (L3) underlay topologies. This service topology has the generic topology elements of node, link, and terminating point. One typical example of a service topology is described in Figure 3 of [RFC8345]: two VPN service topologies instantiated over a common L3 topology. Each VPN service topology is mapped onto a subset of nodes from the L3 topology. Figure 2 illustrates an example of a topology hierarchy that maps between the VPN service topology and an underlying Layer 3 network topology: VPN 1 VPN 2 +------------------------+ +------------------------+ / / / / / S1C_[VN3].......... / / / / \ : / / S2A_[VN1]____[VN3]_S2B / / \ : / / * * / / \ :............ * .... * / / S1B_[VN2]____[VN1]_S1A / / * : * / +---------:-------:------+ +-------*------:-----*---+ : : * * * * * : * : : * : * Site-1A : +-------:-*--------------------:-----*-----+ Site-1C [CE1]___:_/_______[N1]___________________[N2]___*____/__[CE3] :/ / / \ _____// * / [CE5]_____:_______/ / \ _____/ / * / Site-2A /: / \ / / * / / : [N5] / * / / : / __/ \__ / * / / : / ___/ \__ / * / Site-1B / : / ___/ \ /* / Site-2B [CE2]__/________[N4]__________________[N3]________/____[CE4] / / +------------------------------------------+ L3 Topology Legend: N:Node VN:VPN-Node S:Site CE:Customer Edge __ Link within a network layer : Mapping between VPN 1 service topology and L3 topology * Mapping between VPN 2 service topology and L3 topology Wu, et al. Expires 15 May 2023 [Page 7] Internet-Draft Network and VPN Service PM YANG November 2022 Figure 2: Example of Topology Mapping Between VPN Service Topology and Underlying Network As shown in Figure 2, two VPN services topologies are built on top of one underlying Layer 3 network: VPN 1: This service topology supports hub-spoke communications for 'customer 1' connecting the customer's access at three sites: 'Site-1A', 'Site-1B', and 'Site-1C'. These sites are connected to nodes that are mapped to node 1 (N1), node 2 (N2), and node 4 (N4) in the underlying Layer 3 network. 'Site-1A' plays the role of hub while 'Site-1B' and 'Site-1C' are configured as spoke. VPN 2: This service topology supports any-to-any communications for 'customer 2' connecting the customer's access at two sites: 'Site- 2A' and 'Site-2B'. These sites are connected to nodes that are mapped to nodes 1 (N1) and node 3 (N3) in the underlying Layer 3 network. 'Site-2A' and 'Site-2B' have 'any-to-any' role. Based on the association between the VPN service topologies and the underlying network topologies, the VPN Network PM YANG module extends the performance status of the underlay networks and VPN services. For example, the module can provide link PM statistics and port statistics of an underlay network, e.g. Layer 1, Layer 2, Layer 3, OSPF networks. And it can also provide VPN PM statistics, which can be further split into PM for the VPN tunnel and PM at the VPN PE access node, as illustrated in the following diagram. Wu, et al. Expires 15 May 2023 [Page 8] Internet-Draft Network and VPN Service PM YANG November 2022 +-----------------------------------------------------+ | | | VPN2 Link | | |<-------------------->| | | | | | | VPN2+---+---+ +---+---+VPN2 | | TP1| VN1 | Tunnel PM | VN3 |TP2 | | ---+ PE A |==============| PE B +---- | |vpn-access+-------+ +-------+ vpn-access| |-interface| | -interface| | |##############################| | | |inter-vpn-access-interface PM | | | | +-----------------------------------------------------+ | | | | +----+ | TP+-----+ Link +---+ Link +-----+TP | +----+ | CE4+-+----------+ N1 +-------+-N2+-------+ N3 +----------+-+CE5 | +----+ | 1-1+-----+1-2 2-1+---+2-2 3-1+-----+3-2 | +----+ | | | | +-----------------------------------------------------+ Legend: N:node VN:VPN-Node TP:Termination Point -:Link Figure 3: An Example of VPN PM Figure 3 illustrates an example of VPN PM and two VPN PM measurement methods including the VPN tunnel PM and the inter-VPN-access interface PM. VPN PM can also provide statistics on VPN access interfaces, the number of current VRF routes or L2VPN MAC entry of VPN node. 4.2. Network Level Performance Monitoring Augmentation The model can be used for performance monitoring both for the underlay networks and the VPN services, which would be separate entries in the network list [RFC8345]. The differences are as follows: * When the "service" presence container is absent, then it indicates performance monitoring of the network itself. * When the "service" presence container is present, then it indicates performance monitoring of the VPN service specified by the "service-type" leaf, e.g. , L3VPN or Virtual Private LAN Service (VPLS). The values are taken from [RFC9181]. When a Wu, et al. Expires 15 May 2023 [Page 9] Internet-Draft Network and VPN Service PM YANG November 2022 network topology instance contains the L3VPN or other L2VPN network type, it represents a VPN instance that can perform performance monitoring The tree in Figure 4 is a part of "ietf-network-vpn-pm" tree. It also defines the following set of network level attributes: "vpn-id": Refers to an identifier of VPN service defined in [RFC9181]. This identifier is used to correlate the performance status with the network service configuration. "vpn-service-topology": Indicates the type of the VPN service topology. This model supports "any-to-any", "Hub and Spoke" (where Hubs can exchange traffic), and "Hub and Spoke disjoint" (where Hubs cannot exchange traffic) that are taken from [RFC9181]. These VPN service topology types can be used to describe how VPN sites communicate with each other. module: ietf-network-vpn-pm augment /nw:networks/nw:network/nw:network-types: +--rw service! +--rw service-type identityref +--rw vpn-id? vpn-common:vpn-id +--rw vpn-service-topology? identityref Figure 4: Network Level YANG Tree of the Hierarchies 4.3. Node Level Performance Monitoring Augmentation The tree in Figure 5 is the node part of "ietf-network-vpn-pm" tree. For network performance monitoring, the module defines the following attributes: "node-type": Indicates the device type of Provider Edge (PE), Provider (P) device, or Autonomous System Border Router (ASBR) as defined in [RFC4026] and [RFC4364], so that the performance metric between any two nodes each with specific node type can be reported. "entry-summary": Lists a set of IPv4 statistics, IPv6 statistics, and MAC statistics. The detailed statistics are specified separately. For VPN service topology, the module defines one attribute: "role": Defines the role in a particular VPN service topology. The Wu, et al. Expires 15 May 2023 [Page 10] Internet-Draft Network and VPN Service PM YANG November 2022 roles are taken from [RFC9181] (e.g., any-to-any-role, spoke-role, hub-role). augment /nw:networks/nw:network/nw:node: +--rw node-type? identityref +--ro entry-summary +--ro ipv4-num | +--ro maximum-routes? uint32 | +--ro total-active-routes? uint32 +--ro ipv6-num | +--ro maximum-routes? uint32 | +--ro total-active-routes? uint32 +--ro mac-num +--ro maximum-mac-entries? uint32 +--ro total-active-mac-entries? uint32 augment /nw:networks/nw:network/nw:node: +--rw role? identityref Figure 5: Node Level YANG Tree of the Hierarchies 4.4. Link and Termination Point Level Performance Monitoring Augmentation The tree in Figure 6 is the link and termination point (TP) part of ietf-network-vpn-pm tree. The 'links' are classified into two types: topology link defined in [RFC8345] and abstract link of a VPN between PEs defined in this module. The performance data of a link is a collection of counters and gauges that report the performance status. All these metrics are defined as unidirectional metrics. augment /nw:networks/nw:network/nt:link: +--rw perf-mon +--rw low-percentile? percentile +--rw intermediate-percentile? percentile +--rw high-percentile? percentile +--rw measurement-interval? uint32 +--ro pm* [pm-type] | +--ro pm-type identityref | +--ro pm-attributes | +--ro start-time? yang:date-and-time | +--ro end-time? yang:date-and-time | +--ro pm-source? identityref | +--ro one-way-pm-statistics Wu, et al. Expires 15 May 2023 [Page 11] Internet-Draft Network and VPN Service PM YANG November 2022 | | +--ro loss-statistics | | | +--ro packet-loss-count? yang:counter64 | | | +--ro loss-ratio? percentage | | +--ro delay-statistics | | | +--ro unit-value? identityref | | | +--ro min-delay-value? yang:gauge64 | | | +--ro max-delay-value? yang:gauge64 | | | +--ro low-delay-percentile? yang:gauge64 | | | +--ro intermediate-delay-percentile? yang:gauge64 | | | +--ro high-delay-percentile? yang:gauge64 | | +--ro jitter-statistics | | +--ro unit-value? identityref | | +--ro min-jitter-value? yang:gauge64 | | +--ro max-jitter-value? yang:gauge64 | | +--ro low-jitter-percentile? yang:gauge64 | | +--ro intermediate-jitter-percentile? yang:gauge64 | | +--ro high-jitter-percentile? yang:gauge64 | +--ro one-way-pm-statistics-per-class* [class-id] | +--ro class-id string | +--ro loss-statistics | | +--ro packet-loss-count? yang:counter64 | | +--ro loss-ratio? percentage | +--ro delay-statistics | | +--ro unit-value? identityref | | +--ro min-delay-value? yang:gauge64 | | +--ro max-delay-value? yang:gauge64 | | +--ro low-delay-percentile? yang:gauge64 | | +--ro intermediate-delay-percentile? yang:gauge64 | | +--ro high-delay-percentile? yang:gauge64 | +--ro jitter-statistics | +--ro unit-value? identityref | +--ro min-jitter-value? yang:gauge64 | +--ro max-jitter-value? yang:gauge64 | +--ro low-jitter-percentile? yang:gauge64 | +--ro intermediate-jitter-percentile? yang:gauge64 | +--ro high-jitter-percentile? yang:gauge64 +--rw vpn-pm-type +--rw inter-vpn-access-interface | +--rw inter-vpn-access-interface? empty +--rw vpn-tunnel! +--ro vpn-tunnel-type? identityref augment /nw:networks/nw:network/nw:node/nt:termination-point: +--ro pm-statistics +--ro last-updated? yang:date-and-time +--ro inbound-octets? yang:counter64 +--ro inbound-unicast? yang:counter64 +--ro inbound-broadcast? yang:counter64 +--ro inbound-multicast? yang:counter64 Wu, et al. Expires 15 May 2023 [Page 12] Internet-Draft Network and VPN Service PM YANG November 2022 +--ro inbound-discards? yang:counter64 +--ro inbound-errors? yang:counter64 +--ro inbound-unknown-protocol? yang:counter64 +--ro outbound-octets? yang:counter64 +--ro outbound-unicast? yang:counter64 +--ro outbound-broadcast? yang:counter64 +--ro outbound-multicast? yang:counter64 +--ro outbound-discards? yang:counter64 +--ro outbound-errors? yang:counter64 +--ro vpn-network-access* [network-access-id] +--ro network-access-id vpn-common:vpn-id +--ro last-updated? yang:date-and-time +--ro inbound-octets? yang:counter64 +--ro inbound-unicast? yang:counter64 +--ro inbound-broadcast? yang:counter64 +--ro inbound-multicast? yang:counter64 +--ro inbound-discards? yang:counter64 +--ro inbound-errors? yang:counter64 +--ro inbound-unknown-protocol? yang:counter64 +--ro outbound-octets? yang:counter64 +--ro outbound-unicast? yang:counter64 +--ro outbound-broadcast? yang:counter64 +--ro outbound-multicast? yang:counter64 +--ro outbound-discards? yang:counter64 +--ro outbound-errors? yang:counter64 Figure 6: Link and Termination point Level YANG Tree of the hierarchies For the data nodes of 'link' depicted in Figure 6, the YANG module defines the following minimal set of link-level performance attributes: Percentile parameters: The module supports reporting delay and Wu, et al. Expires 15 May 2023 [Page 13] Internet-Draft Network and VPN Service PM YANG November 2022 jitter metric by percentile values. There are three percentile values for configuring various percentile reporting levels. By default, low percentile (10th percentile), intermediate percentile (50th percentile), high percentile (90th percentile) are used. Configuring a percentile to 0.000 indicates the client is not interested in receiving particular percentile. If all percentile nodes are configured to 0.000, this represents that no percentile related nodes will be reported for a given performance metric (e.g., one-way delay, one-way delay variation) and only peak/min values will be reported. For example, a client can inform the server that it is interested in receiving only high percentiles. Then for a given link, at a given "start-time", "end-time" and "measurement-interval", the 'high-delay-percentile' and 'high- jitter-percentile' will be reported. An example to illustrate the use of percentiles is provided in Appendix A.3. Measurement interval ("measurement-interval"): Specifies the performance measurement interval, in seconds. Start time ("start-time"): Indicates the start time of the performance measurement for link statistics. End time ("end-time"): Indicates the end time of the performance measurement for link statistics. PM source ("pm-source"): Indicates the performance monitoring source. The data for the topology link can be based, e.g., on BGP-LS [RFC8571]. The statistics of the VPN abstract links can be collected based upon VPN OAM mechanisms, e.g., OAM mechanisms referenced in [RFC9182], or Ethernet service OAM [ITU-T-Y-1731] referenced in [RFC9291]. Alternatively, the data can be based upon the underlay technology OAM mechanisms, for example, Generic Routing Encapsulation (GRE) tunnel OAM. Loss statistics: A set of one-way loss statistics attributes that are used to measure end to end loss between VPN sites or between any two network nodes. The exact loss value or the loss percentage can be reported. Delay statistics: A set of one-way delay statistics attributes that are used to measure end to end latency between VPN sites or between any two network nodes. The peak/min values or percentile values can be reported. Jitter statistics: A set of one-way IP Packet Delay Variation [RFC3393] statistics attributes that are used to measure end to end jitter between VPN sites or between any two network nodes. The peak/min values or percentile values can be reported. Wu, et al. Expires 15 May 2023 [Page 14] Internet-Draft Network and VPN Service PM YANG November 2022 PM statistics per class: "one-way-pm-statistics-per-class" lists performance measurement statistics for the topology link or the abstract link between VPN PEs with given "class-id" names. The list is defined separately from "one-way-pm-statistics", which is used to collect generic metrics for unspecified "class-id" names. VPN PM type ("vpn-pm-type"): Indicates the VPN performance type, which can be "inter-vpn-access-interface" PM or "vpn-tunnel" PM. These two methods are common VPN measurement methods. The "inter- VPN-access-interface" PM is to monitor the performance of logical point-to-point VPN connections between a source and a destination VPN access interfaces. And the "vpn-tunnel" PM is to monitor the performance of VPN tunnels. The "inter-VPN-access-interface" PM includes PE-PE monitoring. Therefore, usually only one of the two methods is used. The "inter-VPN-access-interface" PM is defined as an empty leaf, which is not bound to a specific VPN access interface. The source or destination VPN access interface of the measurement can be augmented as needed. VPN tunnel type ("vpn-tunnel-type"): Indicates the abstract link protocol-type of a VPN, such as GRE or IP-in-IP. The leaf refers to an identifier of the "underlay-transport" defined in [RFC9181], which describes the transport technology to carry the traffic of the VPN service. In the case of multiple types of tunnels between a single pair of VPN nodes, a separate link for each type of tunnel can be created. For the data nodes of 'termination-point' depicted in Figure 6, the module defines the following minimal set of statistics: Last updated time ("last-updated"): Indicates the date and time when the counters were last updated. Inbound statistics: A set of inbound statistics attributes that are used to measure the inbound statistics of the termination point, such as received packets, received packets with errors, etc. Outbound statistics: A set of outbound statistics attributes that are used to measure the outbound statistics of the termination point, such as sent packets, packets that could not be sent due to errors, etc. VPN network access ("vpn-network-access"): Lists counters of the VPN network access defined in the L3NM [RFC9182] or the L2NM [RFC9291]. When multiple VPN network accesses are created using the same physical port, finer-grained metrics can be monitored. If a TP is associated with only a single VPN, this list is not required. Wu, et al. Expires 15 May 2023 [Page 15] Internet-Draft Network and VPN Service PM YANG November 2022 5. Network and VPN Service Performance Monitoring YANG Module The "ietf-network-vpn-pm" module uses types defined in [RFC8345], [RFC6991], [RFC8532], and [RFC9181]. file "ietf-network-vpn-pm@2022-11-11.yang" module ietf-network-vpn-pm { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm"; prefix nvp; import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Types"; } import ietf-vpn-common { prefix vpn-common; reference "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 VPNs."; } import ietf-network { prefix nw; reference "RFC 8345: A YANG Data Model for Network Topologies, Section 6.1"; } import ietf-network-topology { prefix nt; reference "RFC 8345: A YANG Data Model for Network Topologies, Section 6.2"; } import ietf-lime-time-types { prefix lime; reference "RFC 8532: Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications"; } organization "IETF OPSAWG (Operations and Management Area Working Group)"; contact "WG Web: WG List: Wu, et al. Expires 15 May 2023 [Page 16] Internet-Draft Network and VPN Service PM YANG November 2022 Editor: Bo Wu Editor: Mohamed Boucadair Editor: Qin Wu Author: Oscar Gonzalez de Dios Author: Bin Wen "; description "This module defines a model for Network and VPN Service Performance monitoring. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; // RFC Ed.: update the date below with the date of RFC // publication and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove // this note. revision 2022-11-11 { description "Initial revision."; reference "RFC XXXX: A YANG Model for Network and VPN Service Performance Monitoring"; } identity node-type { description "Base identity for node type"; } identity pe { base node-type; Wu, et al. Expires 15 May 2023 [Page 17] Internet-Draft Network and VPN Service PM YANG November 2022 description "Provider Edge (PE) node type. A PE is the device or set of devices at the edge of the provider network with the functionality that is needed to interface with the customer."; } identity p { base node-type; description "Provider router node type. That is, a router in the core network that does not have interfaces directly toward a customer."; } identity asbr { base node-type; description "Autonomous System Border Router (ASBR) node type."; reference "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)"; } identity pm-source-type { description "Base identity from which specific performance monitoring mechanism types are derived."; } identity pm-source-bgpls { base pm-source-type; description "Indicates BGP-LS as the performance monitoring metric source"; reference "RFC 8571: BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions"; } identity pm-source-owamp { base pm-source-type; description "Indicates One-Way Active Measurement Protocol(OWAMP) as the performance monitoring metric source."; reference "RFC 4656: A One-Way Active Measurement Protocol (OWAMP)"; } identity pm-source-twamp { base pm-source-type; Wu, et al. Expires 15 May 2023 [Page 18] Internet-Draft Network and VPN Service PM YANG November 2022 description "Indicates Two-Way Active Measurement Protocol(TWAMP) as the performance monitoring metric source."; reference "RFC 5357: A Two-Way Active Measurement Protocol (TWAMP)"; } identity pm-source-stamp { base pm-source-type; description "Indicates Simple Two-way Active Measurement Protocol(STAMP) as the performance monitoring metric source."; reference "RFC 8762: Simple Two-Way Active Measurement Protocol"; } identity pm-source-y-1731 { base pm-source-type; description "Indicates Ethernet OAM Y.1731 as the performance monitoring metric source."; reference "ITU-T Y.1731: Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks"; } identity pm-source-ioam { base pm-source-type; description "Indicates In Situ Operations, Administration, and Maintenance (IOAM) as the performance monitoring metric source."; reference "RFC 9197: Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)"; } identity pm-type { description "Base identity for PM type."; } identity pm-type-network-link { base pm-type; description "Indicates that the PM type is for the link in the network topology."; } Wu, et al. Expires 15 May 2023 [Page 19] Internet-Draft Network and VPN Service PM YANG November 2022 identity pm-type-vpn-inter-access { base pm-type; description "Indicates that the PM type is for logical point-to-point VPN connections between a source and a destination VPN access interfaces."; } identity pm-type-vpn-tunnel { base pm-type; description "Indicates that the PM type is for VPN tunnels."; } typedef percentage { type decimal64 { fraction-digits 5; range "0..100"; } description "Percentage to 5 decimal places."; } typedef percentile { type decimal64 { fraction-digits 3; range "0..100"; } description "The percentile is a value between 0 and 100 to 3 decimal places, e.g. 10.000, 99.900 ,99.990, etc. For example, for a given one-way delay measurement, if the percentile is set to 95.000 and the 95th percentile one-way delay is 2 milliseconds, then the 95 percent of the sample value is less than or equal to 2 milliseconds."; } grouping entry-summary { description "Entry summary grouping used for network topology augmentation."; container entry-summary { config false; description "Container for VPN or network entry summary."; container ipv4-num { leaf maximum-routes { type uint32; Wu, et al. Expires 15 May 2023 [Page 20] Internet-Draft Network and VPN Service PM YANG November 2022 description "Indicates the maximum number of IPv4 routes for the VPN or network."; } leaf total-active-routes { type uint32; description "Indicates total active IPv4 routes for the VPN or network."; } description "IPv4-specific parameters."; } container ipv6-num { leaf maximum-routes { type uint32; description "Indicates the maximum number of IPv6 routes for the VPN or network."; } leaf total-active-routes { type uint32; description "Indicates total active IPv6 routes for the VPN or network."; } description "IPv6-specific parameters."; } container mac-num { leaf maximum-mac-entries { type uint32; description "Indicates the maximum number of MAC entries for the VPN or network."; } leaf total-active-mac-entries { type uint32; description "Indicates the total active MAC entries for the VPN or network."; } description "MAC statistics."; } } } Wu, et al. Expires 15 May 2023 [Page 21] Internet-Draft Network and VPN Service PM YANG November 2022 grouping link-loss-statistics { description "Grouping for per link error statistics."; container loss-statistics { description "One-way link loss summarized information."; reference "RFC 4656: A One-way Active Measurement Protocol (OWAMP) ITU-T Y.1731: Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks"; leaf packet-loss-count { type yang:counter64; description "Total number of lost packets."; } leaf loss-ratio { type percentage; description "Loss ratio of the packets. Express as percentage of packets lost with respect to packets sent."; } } } grouping link-delay-statistics { description "Grouping for per link delay statistics."; container delay-statistics { description "One-way link delay summarized information."; reference "RFC 4656: A One-way Active Measurement Protocol (OWAMP) ITU-T Y.1731: Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks"; leaf unit-value { type identityref { base lime:time-unit-type; } default "lime:milliseconds"; description "Time units, where the options are hours, minutes, seconds, milliseconds, microseconds, and nanoseconds."; } leaf min-delay-value { type yang:gauge64; description Wu, et al. Expires 15 May 2023 [Page 22] Internet-Draft Network and VPN Service PM YANG November 2022 "Minimum observed one-way delay."; } leaf max-delay-value { type yang:gauge64; description "Maximum observed one-way delay."; } leaf low-delay-percentile { type yang:gauge64; description "Low percentile of observed one-way delay with specific measurement method."; } leaf intermediate-delay-percentile { type yang:gauge64; description "Intermediate percentile of observed one-way delay with specific measurement method."; } leaf high-delay-percentile { type yang:gauge64; description "High percentile of observed one-way delay with specific measurement method."; } } } grouping link-jitter-statistics { description "Grouping for per link jitter statistics."; container jitter-statistics { description "One-way link jitter summarized information."; reference "RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) RFC 4656: A One-way Active Measurement Protocol (OWAMP) ITU-T Y.1731: Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks"; leaf unit-value { type identityref { base lime:time-unit-type; } default "lime:milliseconds"; description "Time units, where the options are hours, minutes, seconds, Wu, et al. Expires 15 May 2023 [Page 23] Internet-Draft Network and VPN Service PM YANG November 2022 milliseconds, microseconds, and nanoseconds."; } leaf min-jitter-value { type yang:gauge64; description "Minimum observed one-way jitter."; } leaf max-jitter-value { type yang:gauge64; description "Maximum observed one-way jitter."; } leaf low-jitter-percentile { type yang:gauge64; description "Low percentile of observed one-way jitter."; } leaf intermediate-jitter-percentile { type yang:gauge64; description "Intermediate percentile of observed one-way jitter."; } leaf high-jitter-percentile { type yang:gauge64; description "High percentile of observed one-way jitter."; } } } grouping tp-svc-telemetry { leaf last-updated { type yang:date-and-time; config false; description "Indicates the date and time when the counters were last updated."; } leaf inbound-octets { type yang:counter64; description "The total number of octets received on the interface, including framing characters."; } leaf inbound-unicast { type yang:counter64; description "The total number of inbound unicast packets."; Wu, et al. Expires 15 May 2023 [Page 24] Internet-Draft Network and VPN Service PM YANG November 2022 } leaf inbound-broadcast { type yang:counter64; description "The total number of inbound broadcast packets."; } leaf inbound-multicast { type yang:counter64; description "The total number of inbound multicast packets."; } leaf inbound-discards { type yang:counter64; description "The number of inbound packets that were chosen to be discarded even though no errors had been detected. Possible reasons for discarding such a packet could be to free up buffer space, not enough buffer for too much data, etc."; } leaf inbound-errors { type yang:counter64; description "The number of inbound packets that contained errors."; } leaf inbound-unknown-protocol { type yang:counter64; description "The number of packets received via the interface which were discarded because of an unknown or unsupported protocol."; } leaf outbound-octets { type yang:counter64; description "The total number of octets transmitted out of the interface, including framing characters."; } leaf outbound-unicast { type yang:counter64; description "The total number of outbound unicast packets."; } leaf outbound-broadcast { type yang:counter64; description "The total number of outbound broadcast packets."; } Wu, et al. Expires 15 May 2023 [Page 25] Internet-Draft Network and VPN Service PM YANG November 2022 leaf outbound-multicast { type yang:counter64; description "The total number of outbound multicast packets."; } leaf outbound-discards { type yang:counter64; description "The number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. Possible reasons for discarding such a packet could be to free up buffer space, not enough buffer for too much data, etc."; } leaf outbound-errors { type yang:counter64; description "The number of outbound packets that contained errors."; } description "Grouping for interface service telemetry."; } augment "/nw:networks/nw:network/nw:network-types" { description "Defines the service topologies types."; container service { presence "Presence of the container indicates performance monitoring of the VPN service, and absence of the container indicates performance monitoring of the network itself."; description "Container for VPN service."; leaf service-type { type identityref { base vpn-common:service-type; } mandatory true; description "This indicates the network service type, e.g., L3VPN, VPLS, etc."; } leaf vpn-id { type vpn-common:vpn-id; description "VPN identifier."; Wu, et al. Expires 15 May 2023 [Page 26] Internet-Draft Network and VPN Service PM YANG November 2022 } leaf vpn-service-topology { type identityref { base vpn-common:vpn-topology; } description "VPN service topology, e.g., hub-spoke, any-to-any, hub-spoke-disjoint."; } } } augment "/nw:networks/nw:network/nw:node" { description "Augments the network node with other general attributes."; leaf node-type { type identityref { base node-type; } description "Node type, e.g., PE, P, ASBR."; } uses entry-summary; } augment "/nw:networks/nw:network/nw:node" { when '../nw:network-types/nvp:service' { description "Augments for VPN service PM."; } description "Augments the network node with VPN service attributes."; leaf role { type identityref { base vpn-common:role; } default "vpn-common:any-to-any-role"; description "Role of the node in the VPN service topology."; } } augment "/nw:networks/nw:network/nt:link" { description "Augments the network topology link with performance monitoring attributes."; container perf-mon { description Wu, et al. Expires 15 May 2023 [Page 27] Internet-Draft Network and VPN Service PM YANG November 2022 "Container for PM attributes."; leaf low-percentile { type percentile; default "10.000"; description "Low percentile to report. Setting low-percentile to 0.000 indicates the client is not interested in receiving low percentile."; } leaf intermediate-percentile { type percentile; default "50.000"; description "Intermediate percentile to report. Setting intermediate-percentile to 0.000 indicates the client is not interested in receiving intermediate percentile."; } leaf high-percentile { type percentile; default "95.000"; description "High percentile to report. Setting high-percentile to 0.000 indicates the client is not interested in receiving high percentile."; } leaf measurement-interval { type uint32 { range "1..max"; } units "seconds"; default "60"; description "Indicates the time interval to perform PM measurement over."; } list pm { key "pm-type"; config false; description "The list of PM based on PM type"; leaf pm-type { type identityref { base pm-type; } config false; description "The PM type of the measured PM attributes"; } Wu, et al. Expires 15 May 2023 [Page 28] Internet-Draft Network and VPN Service PM YANG November 2022 container pm-attributes { description "Container for PM attributes."; leaf start-time { type yang:date-and-time; config false; description "The date and time the measurement last started."; } leaf end-time { type yang:date-and-time; config false; description "The date and time the measurement last ended."; } leaf pm-source { type identityref { base pm-source-type; } config false; description "The OAM tool used to collect the PM data."; } container one-way-pm-statistics { config false; description "Container for link telemetry attributes."; uses link-loss-statistics; uses link-delay-statistics; uses link-jitter-statistics; } list one-way-pm-statistics-per-class { key "class-id"; config false; description "The list of PM data based on class of service."; leaf class-id { type string; description "The class-id is used to identify the class of service. This identifier is internal to the administration."; } uses link-loss-statistics; uses link-delay-statistics; uses link-jitter-statistics; } } Wu, et al. Expires 15 May 2023 [Page 29] Internet-Draft Network and VPN Service PM YANG November 2022 } } } augment "/nw:networks/nw:network/nt:link/perf-mon" { when '../../nw:network-types/nvp:service' { description "Augments for VPN service PM."; } description "Augments the network topology link with VPN service performance monitoring attributes."; container vpn-pm-type { description "The VPN PM type of this logical point-to-point unidirectional VPN link."; container inter-vpn-access-interface { description "Indicates inter-vpn-access-interface PM, which is to monitor the performance of logical point-to-point VPN connections between a source and a destination VPN access interfaces."; leaf inter-vpn-access-interface { type empty; description "This is a placeholder for inter-vpn-access-interface PM, which is not bound to a specific VPN access interface. The source or destination VPN access interface of the measurement can be augmented as needed."; } } container vpn-tunnel { presence "Enables VPN tunnel PM"; description "Indicates VPN tunnel PM, which is to monitor the performance of VPN tunnels."; leaf vpn-tunnel-type { type identityref { base vpn-common:protocol-type; } config false; description "The leaf indicates the VPN tunnel type, e.g., Generic Routing Encapsulation (GRE), Generic Network Virtualization Encapsulation (Geneve), etc."; } } Wu, et al. Expires 15 May 2023 [Page 30] Internet-Draft Network and VPN Service PM YANG November 2022 } } augment "/nw:networks/nw:network/nw:node/nt:termination-point" { description "Augments the network topology termination point with performance monitoring attributes."; container pm-statistics { config false; description "Container for termination point PM attributes."; uses tp-svc-telemetry; } } augment "/nw:networks/nw:network/nw:node" + "/nt:termination-point/pm-statistics" { when '../../../nw:network-types/nvp:service' { description "Augments for VPN service PM."; } description "Augments the network topology termination-point with VPN service performance monitoring attributes"; list vpn-network-access { key "network-access-id"; description "The list of PM based on VPN network accesses."; leaf network-access-id { type vpn-common:vpn-id; description "The reference to an identifier for the VPN network access."; } uses tp-svc-telemetry; } } } Wu, et al. Expires 15 May 2023 [Page 31] Internet-Draft Network and VPN Service PM YANG November 2022 6. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These write operates can lead to inaccurate or incomplete network measurements which can impact the visibility and decisions this data would be used to inform. Unauthorized write access to the following subtrees could have the following impacts: Wu, et al. Expires 15 May 2023 [Page 32] Internet-Draft Network and VPN Service PM YANG November 2022 +--------+----------------------+------------------------------+ | Access | Node | Potential impact | +--------+----------------------+------------------------------+ | /nw:networks/nw:network/nw:network-types | | write | service type | disable VPN PM | | write | VPN identifier | disable VPN PM | | write | VPN service topology | render data unusable | +--------+----------------------+------------------------------+ | /nw:networks/nw:network/nw:node | | write | node type | render data unusable | | write | VPN topology role | render data unusable | +--------+----------------------+------------------------------+ | /nw:networks/nw:network/nw:link/nvp:perf-mon | | write | percentile | impact reporting cadence | | write | measurement interval | impact monitoring fidelity | | write | vpn-pm-type | impact monitoring fidelity | +--------+----------------------+------------------------------+ Some readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It thus might be important to control read access (e.g., via get, get-config, or notification) to these data nodes. When using, the trade-off between confidentiality and proper monitoring of performance needs to be considered. Unauthorized access to the following subtrees could have the following impacts: * "/nw:networks/nw:network/nw:node": Unauthorized read access to this subtree can disclose the operational state information of underlay network instances or VPN instances. * "/nw:networks/nw:network/nt:link/nvp:perf-mon/nvp:one-way-pm- statistics": Unauthorized read access to this subtree can disclose the operational state information of underlay network links or VPN abstract links. Wu, et al. Expires 15 May 2023 [Page 33] Internet-Draft Network and VPN Service PM YANG November 2022 * "/nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm- statistics": Unauthorized read access to this subtree can disclose the operational state information of underlay network termination points or VPN network accesses. This YANG module does not define any RPC (Remote Procedure Call) operations and Actions. 7. IANA Considerations This document requests IANA to register the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document requests IANA to register the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. Name: ietf-network-vpn-pm Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm Maintained by IANA: N Prefix: nvp Reference: RFC XXXX (RFC Ed.: replace XXXX with actual RFC number and remove this note.) 8. Acknowledgements Thanks to Joe Clarke, Adrian Farrel, Tom Petch, Greg Mirsky, Roque Gagliano, Erez Segev, and Dhruv Dhody for reviewing and providing important input to this document. This work was partially supported by the European Commission under Horizon 2020 grant agreement number 101015857 Secured autonomic traffic management for a Tera of SDN flows (Teraflow). 9. Contributors The following authors contributed significantly to this document: Wu, et al. Expires 15 May 2023 [Page 34] Internet-Draft Network and VPN Service PM YANG November 2022 Michale Wang Huawei Email:wangzitao@huawei.com Roni Even Huawei Email: ron.even.tlv@gmail.com Change Liu China Unicom Email: liuc131@chinaunicom.cn Honglei Xu China Telecom Email: xuhl6@chinatelecom.cn 10. References 10.1. Normative References [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, November 2002, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, . [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . Wu, et al. Expires 15 May 2023 [Page 35] Internet-Draft Network and VPN Service PM YANG November 2022 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Wu, et al. Expires 15 May 2023 [Page 36] Internet-Draft Network and VPN Service PM YANG November 2022 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. Raghavan, "Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications", RFC 8532, DOI 10.17487/RFC8532, April 2019, . [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, . [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, . [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, . [RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February 2022, . 10.2. Informative References [I-D.ietf-opsawg-sap] Boucadair, M., de Dios, O. G., Barguil, S., Wu, Q., and V. Lopez, "A YANG Network Model for Service Attachment Points (SAPs)", Work in Progress, Internet-Draft, draft-ietf- opsawg-sap-10, 4 October 2022, . [ITU-T-Y-1731] ITU-T, "Operator Ethernet Service Definition", August 2015, . [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, . Wu, et al. Expires 15 May 2023 [Page 37] Internet-Draft Network and VPN Service PM YANG November 2022 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, . [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, August 2017, . [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, . [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, . [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm Management", RFC 8632, DOI 10.17487/RFC8632, September 2019, . [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, . [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, "A Framework for Automating Service and Network Management with YANG", RFC 8969, DOI 10.17487/RFC8969, January 2021, . [RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, February 2022, . [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . Wu, et al. Expires 15 May 2023 [Page 38] Internet-Draft Network and VPN Service PM YANG November 2022 [RFC9291] Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil, S., and L. Munoz, "A YANG Network Data Model for Layer 2 VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022, . Appendix A. Illustrative Examples A.1. VPN Performance Subscription Example The example shown in Figure 7 illustrates how a client subscribes to the performance monitoring information between nodes ('node-id') A and B in the L3 network topology. The performance monitoring parameter that the client is interested in is end-to-end loss. POST /restconf/operations /ietf-subscribed-notifications:establish-subscription { "ietf-subscribed-notifications:input": { "stream-subtree-filter": { "ietf-network:networks": { "network": { "network-id": "foo:vpn1", "ietf-network-vpn-pm:service": { "service-type": "ietf-vpn-common:l3vpn" }, "node": [ { "node-id": "A", "ietf-network-vpn-pm:node-type": "PE", "termination-point": [ { "tp-id": "1-0-1" } ] }, { "node-id": "B", "ietf-network-vpn-pm:node-type": "PE", "termination-point": [ { "tp-id": "2-0-1" } ] } ], "ietf-network-topology:link": [ Wu, et al. Expires 15 May 2023 [Page 39] Internet-Draft Network and VPN Service PM YANG November 2022 { "link-id": "A-B", "source": { "source-node": "A" }, "destination": { "dest-node": "B" }, "ietf-network-vpn-pm:perf-mon": { "pm": [ { "pm-type": "pm-type-vpn-tunnel", "pm-attributes": { "one-way-pm-statistics": { "loss-statistics": { "packet-loss-count": {} } } } } ], "vpn-pm-type": { "vpn-tunnel": { "vpn-tunnel-type": "ietf-vpn-common:gre" } } } } ] } }, "ietf-yang-push:periodic": { "ietf-yang-push:period": "500" } } } } Figure 7: Pub/Sub Retrieval A.2. Example of VPN Performance Snapshot This example, depicted in Figure 8, illustrates an VPN PM instance example in which a client uses RESTCONF [RFC8040] to fetch the performance data of the link and TP belonged to "VPN1". Wu, et al. Expires 15 May 2023 [Page 40] Internet-Draft Network and VPN Service PM YANG November 2022 { "ietf-network:networks": { "network": { "network-id": "foo:vpn1", "node": [ { "node-id": "A", "ietf-network-vpn-pm:node-type": "PE", "termination-point": [ { "tp-id": "1-0-1", "ietf-network-vpn-pm:pm-statistics": { "inbound-octets": "100", "outbound-octets": "150" } } ] }, { "node-id": "B", "ietf-network-vpn-pm:node-type": "PE", "termination-point": [ { "tp-id": "2-0-1", "ietf-network-vpn-pm:pm-statistics": { "inbound-octets": "150", "outbound-octets": "100" } } ] } ], "ietf-network-topology:link": [ { "link-id": "A-B", "source": { "source-node": "A" }, "destination": { "dest-node": "B" }, "ietf-network-pm:perf-mon": { "pm": [ { "pm-type": "pm-type-vpn-tunnel", "pm-attributes": { "one-way-pm-statistics": { "loss-statistics": { Wu, et al. Expires 15 May 2023 [Page 41] Internet-Draft Network and VPN Service PM YANG November 2022 "packet-loss-count": "120" } } } } ], "vpn-pm-type": { "vpn-tunnel": { "vpn-tunnel-type": "ietf-vpn-common:gre" } } } } ] } } } Figure 8 A.3. Example of Percentile Monitoring This is an example of percentile measurement data that could be returned for a link foo:vpn1-link1 between vpn-node1 and vpn-node3. Wu, et al. Expires 15 May 2023 [Page 42] Internet-Draft Network and VPN Service PM YANG November 2022 { "ietf-network-topology:link": [ { "link-id": "foo:vpn1-link1", "source": { "source-node": "vpn-node1" }, "destination": { "dest-node": "vpn-node3" }, "ietf-network-vpn-pm:perf-mon": { "low-percentile": "20.000", "intermediate-percentile": "50.000", "high-percentile": "90.000", "pm": [ { "pm-type": "pm-type-vpn-inter-access", "pm-attributes": { "one-way-pm-statistics": { "delay-statistics": { "unit-value": "lime:milliseconds", "min-delay-value": "43", "max-delay-value": "99", "low-delay-percentile": "64", "intermediate-delay-percentile": "77", "high-delay-percentile": "98" } } } } ], "vpn-pm-type": { "inter-vpn-access-interface": { "inter-vpn-access-interface": [null] } } } } ] } Authors' Addresses Wu, et al. Expires 15 May 2023 [Page 43] Internet-Draft Network and VPN Service PM YANG November 2022 Bo Wu (editor) Huawei 101 Software Avenue, Yuhua District Nanjing Jiangsu, 210012 China Email: lana.wubo@huawei.com Qin Wu (editor) Huawei 101 Software Avenue, Yuhua District Nanjing Jiangsu, 210012 China Email: bill.wu@huawei.com Mohamed Boucadair (editor) Orange Rennes 35000 France Email: mohamed.boucadair@orange.com Oscar Gonzalez de Dios Telefonica Madrid Spain Email: oscar.gonzalezdedios@telefonica.com Bin Wen Comcast Email: bin_wen@comcast.com Wu, et al. Expires 15 May 2023 [Page 44] ./draft-bar-cfrg-spake2plus-08.txt0000644000764400076440000020434614234725144016520 0ustar iustiniustin Network Working Group T. Taubert Internet-Draft Apple Inc. Intended status: Informational C. A. Wood Expires: 6 November 2022 5 May 2022 SPAKE2+, an Augmented PAKE draft-bar-cfrg-spake2plus-08 Abstract This document describes SPAKE2+, a Password Authenticated Key Exchange (PAKE) protocol run between two parties for deriving a strong shared key with no risk of disclosing the password. SPAKE2+ is an augmented PAKE protocol, as only one party has knowledge of the password. This method is simple to implement, compatible with any prime order group and is computationally efficient. This document was produced outside of the IETF and IRTF, and represents the opinions of the authors. Publication of this document as an RFC in the Independent Submissions Stream does not imply endorsement of SPAKE2+ by the IETF or IRTF. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/chris-wood/draft-bar-cfrg-spake2plus. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 November 2022. Taubert & Wood Expires 6 November 2022 [Page 1] Internet-Draft spake2plus May 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Definition of SPAKE2+ . . . . . . . . . . . . . . . . . . . . 4 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 3.2. Offline Registration . . . . . . . . . . . . . . . . . . 6 3.3. Online Authentication . . . . . . . . . . . . . . . . . . 7 3.4. Key Schedule and Key Confirmation . . . . . . . . . . . . 9 4. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Protocol Flow . . . . . . . . . . . . . . . . . . . 15 A.1. Prover . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.2. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 16 A.3. Transcript Computation . . . . . . . . . . . . . . . . . 16 A.4. Key Schedule Computation . . . . . . . . . . . . . . . . 17 A.5. Protocol Run . . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Algorithm used for Point Generation . . . . . . . . 18 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction This document describes SPAKE2+, a Password Authenticated Key Exchange (PAKE) protocol run between two parties for deriving a strong shared key with no risk of disclosing the password. SPAKE2+ is an augmented PAKE protocol, as only one party makes direct use of the password during the execution of the protocol. The other party only needs a record corresponding to the other party's registration Taubert & Wood Expires 6 November 2022 [Page 2] Internet-Draft spake2plus May 2022 at the time of the protocol execution instead of the password. This record can be computed once, during an offline registration phase. The party using the password directly would typically be a client, and acts as a prover, while the other party would be a server, and acts as verifier. The protocol is augmented in the sense that it provides some resilience to the compromise or extraction of the registration record. The design of the protocol forces the adversary to recover the password from the record to successfully execute the protocol. Hence this protocol can be advantageously combined with a salted Password Hashing Function to increase the cost of the recovery and slow down attacks. The record cannot be used directly to successfully run the protocol as a prover, making this protocol more robust than balanced PAKEs which don't benefit from Password Hashing Functions to the same extent. This augmented property is especially valuable in scenarios where the execution of the protocol is constrained and the adversary cannot query the salt of the password hash function ahead of the attack. Constraints may consist in being in physical proximity through a local network or when initiation of the protocol requires a first authentication factor. This document has content split out from a related document specifying SPAKE2 [I-D.irtf-cfrg-spake2], which is a symmetric PAKE protocol, where both parties have knowledge of the password. SPAKE2+ is the asymmetric or augmented version of SPAKE2, wherein only one party has knowledge of the password. SPAKE2+ is specified separately in this document because the use cases for symmetric and augmented PAKEs are different, and therefore warrant different technical specifications. Neither SPAKE2 nor SPAKE2+ was selected as the result of the CFRG PAKE selection competition. However, this password-based key exchange protocol appears in [TDH] and is proven secure in [SPAKE2P-Analysis]. It is compatible with any prime-order group and relies only on group operations, making it simple and computationally efficient. Thus, it was felt that publication was beneficial to make the protocol available for wider consideration. This document was produced outside of the IETF and IRTF, and represents the opinions of the authors. Publication of this document as an RFC in the Independent Submissions Stream does not imply endorsement of SPAKE2+ by the IETF or IRTF. Taubert & Wood Expires 6 November 2022 [Page 3] Internet-Draft spake2plus May 2022 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Definition of SPAKE2+ Let G be a group in which the computational Diffie-Hellman (CDH) problem is hard. Suppose G has order p*h where p is a large prime; h will be called the cofactor. Let I be the unit element in G, e.g., the point at infinity if G is an elliptic curve group. We denote the operations in the group additively. We assume there is a representation of elements of G as byte strings: common choices would be SEC1 uncompressed or compressed [SEC1] for elliptic curve groups or big endian integers of a fixed (per-group) length for prime field DH. We fix a generate P of (large) prime-order subgroup of G. P is specified in the document defining the group, and so we do not repeat it here. || denotes concatenation of strings. We also let len(S) denote the length of a string in bytes, represented as an eight-byte little endian number. Finally, let nil represent an empty string, i.e., len(nil) = 0. KDF is a key-derivation function that takes as input a salt, intermediate keying material (IKM), info string, and derived key length L to derive a cryptographic key of length L. MAC is a Message Authentication Code algorithm that takes a secret key and message as input to produce an output. Let Hash be a hash function from arbitrary strings to bit strings of a fixed length. Common choices for Hash are SHA256 or SHA512 [RFC6234]. Section 4 specifies variants of KDF, MAC, and Hash suitable for use with the protocols contained herein. Taubert & Wood Expires 6 November 2022 [Page 4] Internet-Draft spake2plus May 2022 Let there be two parties, a prover and a verifier. Their identities, denoted as idProver and idVerifier, may also have digital representations such as Media Access Control addresses or other names (hostnames, usernames, etc). The parties may share additional data (the context) separate from their identities which they may want to include in the protocol transcript. One example of additional data is a list of supported protocol versions if SPAKE2+ were used in a higher-level protocol which negotiates the use of a particular PAKE. Another example is the inclusion of the application name. Including those would ensure that both parties agree upon the same set of supported protocols and therefore prevent downgrade and cross- protocol attacks. Specification of precise context values is out of scope for this document. 3.1. Protocol Overview SPAKE2+ is a two round protocol that establishes a shared secret with an additional round for key confirmation. Prior to invocation, both parties are provisioned with information such as the input password needed to run the protocol. The registration phase may include communicating identities, protocol version and other parameters related to the registration record; see Section 3.2 for details. During the first round, the prover sends a public share shareP to the verifier, which in turn responds with its own public share shareV. Both parties then derive a shared secret used to produce encryption and authentication keys. The latter are used during the second round for key confirmation. (Section 3.4 details the key derivation and confirmation steps.) In particular, the verifier sends a key confirmation message confirmV to the prover, which in turn responds with its own key confirmation message confirmP. (Note that shareV and confirmV MAY be sent in the same message.) Both parties MUST NOT consider the protocol complete prior to receipt and validation of these key confirmation messages. A sample trace is shown below. Taubert & Wood Expires 6 November 2022 [Page 5] Internet-Draft spake2plus May 2022 Prover Verifier | (registration) | |<- - - - - - - - - - - - ->| | | | (setup protocol) | (compute shareP) | shareP | |-------------------------->| | shareV | (compute shareV) |<--------------------------| | | | (derive secrets) | (compute confirmV) | confirmV | |<--------------------------| (compute confirmP) | confirmP | |-------------------------->| 3.2. Offline Registration The registration phase computes the values w0 and w1, as well as the registration record L=w1*P. w0 and w1 are derived by hashing the password pw with the identities of the two participants. w0 and the record L are then shared with the verifier and stored as part of the registration record associated with the prover. The prover SHOULD derive w0 and w1 from the password before the protocol begins. Both w0 and w1 are derived using a function with range [0, p-1], which is modeled as a random oracle in [SPAKE2P-Analysis]. The registration phase also produces two random elements M and N in the prime-order subgroup of G. The algorithm for selecting M and N is defined in Appendix B. Importantly, this algorithm chooses M and N such that their discrete logs are not known. Pre-computed values for M and N are listed in Section 4 for each group. Applications MAY use different M and N values provided they are computed, e.g., using different input seeds to the algorithm in Appendix B, as random elements for which the discrete log is unknown. Applications using this specification MUST define the method used to compute w0 and w1. For example, it may be necessary to carry out various forms of normalization of the password before hashing [RFC8265]. This section contains requirements and default recommendations for computing w0 and w1. The RECOMMENDED method for generating w0 and w1 is via a Password- Based Key Derivation Function (PBKDF), which is a function designed to slow down brute-force attackers. Brute-force resistance may be obtained through various computation hardness parameters such as memory or CPU cycles, and are typically configurable. Scrypt Taubert & Wood Expires 6 November 2022 [Page 6] Internet-Draft spake2plus May 2022 [RFC7914] and Argon2id [RFC9106] are common examples of PBKDFs. Absent an application-specific profile, RECOMMENDED parameters (N, r, p) for Scrypt are (32768,8,1), and RECOMMENDED parameters for Argon2id are in Section 4 of [RFC9106]. Each half of the output of the PBKDF will be interpreted as an integer and reduced modulo p. To control bias, each half must be of length at least ceil(log2(p)) + k bits, with k >= 64. Reducing such integers mod p gives bias at most 2^-k for any p; this bias is negligible for any k >= 64. The minimum total output length of the PBKDF then is 2 * (ceil(log2(p)) + k) bits. For example, given the prime order of the P-256 curve, the output of the PBKDF SHOULD be at least 640 bits or 80 bytes. Given a PBKDF, password pw, and identities idProver and idVerifier, the RECOMMENDED method for computing w0 and w1 is as follows: w0s || w1s = PBKDF(len(pw) || pw || len(idProver) || idProver || len(idVerifier) || idVerifier) w0 = w0s mod p w1 = w1s mod p If an identity is unknown at the time of computing w0s or w1s, its length is given as zero and the identity itself is represented as the empty octet string. If both idProver and idVerifier are unknown, then their lengths are given as zero and both identities will be represented as empty octet strings. idProver and idVerifier are included in the transcript TT as part of the protocol flow. 3.3. Online Authentication The online SPAKE2+ protocol runs between the prover and verifier to produce a single shared secret upon completion. To begin, the prover selects x uniformly at random from the integers in [0, p-1], computes the public share shareP=X, and transmits it to the verifier. x <- [0, p-1] X = x*P + w0*M Taubert & Wood Expires 6 November 2022 [Page 7] Internet-Draft spake2plus May 2022 Upon receipt of X, the verifier checks the received element for group membership and aborts if X is not in the large prime-order subgroup of G; see Section 6 for details. The verifier then selects y uniformly at random from the integers in [0, p-1], computes the public share shareV=Y and transmits it to the prover. Upon receipt of Y, the prover checks the received element for group membership and aborts if Y is not in the large prime-order subgroup of G. y <- [0, p-1] Y = y*P + w0*N Both participants compute Z and V that are now shared as common values. The prover computes: Z = h*x*(Y - w0*N) V = h*w1*(Y - w0*N) The verifier computes: Z = h*y*(X - w0*M) V = h*y*L The multiplication by the cofactor h prevents small subgroup confinement attacks. All proofs of security hold even if the discrete log of the fixed group element N is known to the adversary. In particular, one MAY set N=I, i.e. set N to the unit element in G. It is essential that both Z and V be used in combination with the transcript to derive the keying material. The protocol transcript encoding is shown below. TT = len(Context) || Context || len(idProver) || idProver || len(idVerifier) || idVerifier || len(M) || M || len(N) || N || len(shareP) || shareP || len(shareV) || shareV || len(Z) || Z || len(V) || V || len(w0) || w0 Taubert & Wood Expires 6 November 2022 [Page 8] Internet-Draft spake2plus May 2022 Context is an application-specific customization string shared between both parties and MUST precede the remaining transcript. It might contain the name and version number of the higher-level protocol, or simply the name and version number of the application. The context MAY include additional data such as the chosen ciphersuite and PBKDF parameters like the iteration count or salt. The context and its length prefix MAY be omitted. If an identity is absent, its length is given as zero and the identity itself is represented as the empty octet string. If both identities are absent, then their lengths are given as zero and both are represented as empty octet strings. In applications where identities are not implicit, idProver and idVerifier SHOULD always be non-empty. Otherwise, the protocol risks Unknown Key Share attacks (discussion of Unknown Key Share attacks in a specific protocol is given in [RFC8844]). Upon completion of this protocol, both parties compute shared secrets K_main, K_shared, K_confirmP, and K_confirmV as specified in Section 3.4. The verifier MUST send a key confirmation message confirmV to the prover so both parties can confirm that they agree upon these shared secrets. After receipt and verification of the verifier's confirmation message, the prover MUST respond with its confirmation message. The verifier MUST NOT send application data to the prover until it has received and verified the confirmation message. Key confirmation verification requires recomputation of confirmP or confirmV and checking for equality against that which was received. 3.4. Key Schedule and Key Confirmation The protocol transcript TT, as defined in Section 3.3, is unique and secret to the participants. Both parties use TT to derive the shared symmetric secret K_main from the protocol. The length of K_main is equal to the length of the digest output, e.g., 256 bits for Hash() = SHA-256. The confirmation keys K_confirmP and K_confirmV, as well as the shared key K_shared are derived from K_main. K_main = Hash(TT) K_confirmP || K_confirmV = KDF(nil, K_main, "ConfirmationKeys") K_shared = KDF(nil, K_main, "SharedKey") Neither K_main nor its derived confirmation keys are used for anything except key derivation and confirmation and MUST be discarded after the protocol execution. Applications MAY derive additional keys from K_shared as needed. Taubert & Wood Expires 6 November 2022 [Page 9] Internet-Draft spake2plus May 2022 The length of each confirmation key is dependent on the MAC function of the chosen ciphersuite. For HMAC, the RECOMMENDED key length is equal to the output length of the digest output, e.g., 256 bits for Hash() = SHA-256. For CMAC-AES, each confirmation key MUST be of length k, where k is the chosen AES key size, e.g., 128 bits for CMAC-AES-128. Both endpoints MUST employ a MAC that produces pseudorandom tags for key confirmation. K_confirmP and K_confirmV are symmetric keys used to compute tags confirmP and confirmV over the public key shares received from the other peer earlier. confirmP = MAC(K_confirmP, shareV) confirmV = MAC(K_confirmV, shareP) Once key confirmation is complete, applications MAY use K_shared as an authenticated shared secret as needed. For example, applications MAY derive one or more AEAD keys and nonces from K_shared for subsequent application data encryption. 4. Ciphersuites This section documents SPAKE2+ ciphersuite configurations. A ciphersuite indicates a group, cryptographic hash algorithm, and pair of KDF and MAC functions, e.g., P256-SHA256-HKDF-HMAC-SHA256. This ciphersuite indicates a SPAKE2+ protocol instance over P-256 that uses SHA256 along with HKDF [RFC5869] and HMAC [RFC2104] for G, Hash, KDF, and MAC functions, respectively. Since the choice of PBKDF and its parameters for computing w0 and w1 and distributing does not affect interoperability, the PBKDF is not included as part of the ciphersuite. If no MAC algorithm is used in the key confirmation phase, its respective column in Table 1 can be ignored and the ciphersuite name will contain no MAC identifier. Taubert & Wood Expires 6 November 2022 [Page 10] Internet-Draft spake2plus May 2022 +==============+==================+=============+==============+ | G | Hash | KDF | MAC | +==============+==================+=============+==============+ | P-256 | SHA256 [RFC6234] | HKDF-SHA256 | HMAC-SHA256 | | | | [RFC5869] | [RFC2104] | +--------------+------------------+-------------+--------------+ | P-256 | SHA512 [RFC6234] | HKDF-SHA512 | HMAC-SHA512 | | | | [RFC5869] | [RFC2104] | +--------------+------------------+-------------+--------------+ | P-384 | SHA256 [RFC6234] | HKDF-SHA256 | HMAC-SHA256 | | | | [RFC5869] | [RFC2104] | +--------------+------------------+-------------+--------------+ | P-384 | SHA512 [RFC6234] | HKDF-SHA512 | HMAC-SHA512 | | | | [RFC5869] | [RFC2104] | +--------------+------------------+-------------+--------------+ | P-521 | SHA512 [RFC6234] | HKDF-SHA512 | HMAC-SHA512 | | | | [RFC5869] | [RFC2104] | +--------------+------------------+-------------+--------------+ | edwards25519 | SHA256 [RFC6234] | HKDF-SHA256 | HMAC-SHA256 | | | | [RFC5869] | [RFC2104] | +--------------+------------------+-------------+--------------+ | edwards448 | SHA512 [RFC6234] | HKDF-SHA512 | HMAC-SHA512 | | | | [RFC5869] | [RFC2104] | +--------------+------------------+-------------+--------------+ | P-256 | SHA256 [RFC6234] | HKDF-SHA256 | CMAC-AES-128 | | | | [RFC5869] | [RFC4493] | +--------------+------------------+-------------+--------------+ | P-256 | SHA512 [RFC6234] | HKDF-SHA512 | CMAC-AES-128 | | | | [RFC5869] | [RFC4493] | +--------------+------------------+-------------+--------------+ Table 1 The following points represent permissible point generation seeds for the groups listed in Table 1, using the algorithm presented in Appendix B. These bytestrings are compressed points as in [SEC1] for curves from [SEC1] and [RFC8032]. Note that these values are identical to those used in the companion SPAKE2 specification [I-D.irtf-cfrg-spake2]. For P256: Taubert & Wood Expires 6 November 2022 [Page 11] Internet-Draft spake2plus May 2022 M = 02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f seed: 1.2.840.10045.3.1.7 point generation seed (M) N = 03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49 seed: 1.2.840.10045.3.1.7 point generation seed (N) For P384: M = 030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3dc 36f15314739074d2eb8613fceec2853 seed: 1.3.132.0.34 point generation seed (M) N = 02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543bb 252c5490214cf9aa3f0baab4b665c10 seed: 1.3.132.0.34 point generation seed (N) For P521: M = 02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d85608 cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7aa seed: 1.3.132.0.35 point generation seed (M) N = 0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e494b25 32d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd25 seed: 1.3.132.0.35 point generation seed (N) For edwards25519: M = d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf seed: edwards25519 point generation seed (M) N = d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab seed: edwards25519 point generation seed (N) For edwards448: Taubert & Wood Expires 6 November 2022 [Page 12] Internet-Draft spake2plus May 2022 M = b6221038a775ecd007a4e4dde39fd76ae91d3cf0cc92be8f0c2fa6d6b66f9a12 942f5a92646109152292464f3e63d354701c7848d9fc3b8880 seed: edwards448 point generation seed (M) N = 6034c65b66e4cd7a49b0edec3e3c9ccc4588afd8cf324e29f0a84a072531c4db f97ff9af195ed714a689251f08f8e06e2d1f24a0ffc0146600 seed: edwards448 point generation seed (N) 5. IANA Considerations No IANA action is required. 6. Security Considerations SPAKE2+ appears in [TDH] and is proven secure in [SPAKE2P-Analysis]. The ephemeral randomness used by the prover and verifier MUST be generated using a cryptographically secure PRNG. Elements received from a peer MUST be checked for group membership: failure to properly deserialize and validate group elements can lead to attacks. An endpoint MUST abort the protocol if any received public value is not a member of the large prime-order subgroup of G. Multiplication of a public value V by the cofactor h will yield the identity element I whenever V is an element of a small-order subgroup. Consequently, prover and verifier MUST abort the protocol upon of any received value V such that V*h = I. Failure to do so may lead to subgroup confinement attacks. 7. Acknowledgements Thanks to Ben Kaduk and Watson Ladd, from which this specification originally emanated. 8. References 8.1. Normative References [I-D.irtf-cfrg-spake2] Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", Work in Progress, Internet-Draft, draft-irtf-cfrg-spake2-26, 8 February 2022, . Taubert & Wood Expires 6 November 2022 [Page 13] Internet-Draft spake2plus May 2022 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2006, . [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 8265, DOI 10.17487/RFC8265, October 2017, . [SEC1] "Elliptic Curve Cryptography, Standards for Efficient Cryptography Group, ver. 2", 2009, . Taubert & Wood Expires 6 November 2022 [Page 14] Internet-Draft spake2plus May 2022 [SPAKE2P-Analysis] "Security analysis of SPAKE2+", 2020, . [TDH] "The Twin-Diffie Hellman Problem and Applications", EUROCRYPT 2008, Volume 4965 of Lecture notes in Computer Science, pages 127-145, Springer-Verlag, Berlin, Germany , 2008. 8.2. Informative References [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, August 2016, . [RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)", RFC 8844, DOI 10.17487/RFC8844, January 2021, . [RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications", RFC 9106, DOI 10.17487/RFC9106, September 2021, . Appendix A. Protocol Flow This section describes the flow of the SPAKE2+ protocol, including computations and mandatory checks performed by the prover and verifier. The constants M, N, P, p, and h are defined by the chosen ciphersuite. A.1. Prover The Prover's behavior consists of two functions, ProverInit and ProverFinish, which are described below. Taubert & Wood Expires 6 November 2022 [Page 15] Internet-Draft spake2plus May 2022 def ProverInit(w0): // Compute prover key share x <- [0, p-1] X = x*P + w0*M return (x, X) def ProverFinish(w0, w1, x, Y): if not_in_subgroup(Y): raise "invalid input" // Compute shared values Z = h*x*(Y - w0*N) V = h*w1*(Y - w0*N) return (Y, Z, V) A.2. Verifier The Verifier's behavior consists of a single function, VerifierFinish, which is described below. def VerifierFinish(w0, L, X): if not_in_subgroup(X): raise "invalid input" // Compute verifier key share y <- [0, p-1] Y = y*P + w0*N // Compute shared values Z = h*y*(X - w0*M) V = h*y*L return (Z, V) A.3. Transcript Computation Both Prover and Verifier share the same function to compute the protocol transcript, ComputeTranscript, which is described below. Taubert & Wood Expires 6 November 2022 [Page 16] Internet-Draft spake2plus May 2022 def ComputeTranscript(Context, idProver, idVerifier, shareP, shareV, Z, V, w0): TT = len(Context) || Context || len(idProver) || idProver || len(idVerifier) || idVerifier || len(M) || M || len(N) || N || len(shareP) || shareP || len(shareV) || shareV || len(Z) || Z || len(V) || V || len(w0) || w0 A.4. Key Schedule Computation Both Prover and Verifier share the same function to compute the key schedule, ComputeKeySchedule, which is described below. def ComputeKeySchedule(TT): K_main = Hash(TT) K_confirmP || K_confirmV = KDF(nil, K_main, "ConfirmationKeys") K_shared = KDF(nil, K_main, "SharedKey") return K_confirmP, K_confirmV, K_shared A.5. Protocol Run A full SPAKE2+ protocol run initiated by the prover will look as follows, where Transmit and Receive are shorthand for sending and receiving a message to the peer: Taubert & Wood Expires 6 November 2022 [Page 17] Internet-Draft spake2plus May 2022 Prover(Context, idProver, idVerifier, w0, w1): (x, X) = ProverInit(w0) Transmit(X) Y = Receive() (Z, V) = ProverFinish(w0, w1, x, Y) TT = ComputeTranscript(Context, idProver, idVerifier, X, Y, Z, V, w0) (K_confirmP, K_confirmV, K_shared) = ComputeKeySchedule(TT) expected_confirmV = MAC(K_confirmV, X) confirmV = Receive() if not_equal_constant_time(expected_confirmV, confirmV): raise "invalid confirmation message" confirmP = MAC(K_confirmP, Y) Transmit(confirmP) return K_shared Verifier(Context, idProver, idVerifier, w0, L): X = Receive() (Y, Z, V) = VerifierFinish(w0, L, X) Transmit(Y) TT = ComputeTranscript(Context, idProver, idVerifier, X, Y, Z, V, w0) (K_confirmP, K_confirmV, K_shared) = ComputeKeySchedule(TT) confirmV = MAC(K_confirmV, X) Transmit(confirmV) expected_confirmP = MAC(K_confirmP, Y) confirmP = Receive() if not_equal_constant_time(expected_confirmP, confirmP): raise "invalid confirmation message" return K_shared Appendix B. Algorithm used for Point Generation This section describes the algorithm that was used to generate the points M and N in the table in Section 4. This algorithm produces M and N such that they are indistinguishable from two random points in the prime-order subgroup of G, where the discrete log of these points is unknown. See [SPAKE2P-Analysis] for additional details on this requirement. Taubert & Wood Expires 6 November 2022 [Page 18] Internet-Draft spake2plus May 2022 For each curve in the table below, we construct a string using the curve OID from [RFC5480] (as an ASCII string) or its name, combined with the needed constant, for instance "1.3.132.0.35 point generation seed (M)" for P-512. This string is turned into a series of blocks by hashing with SHA256, and hashing that output again to generate the next 32 bytes, and so on. This pattern is repeated for each group and value, with the string modified appropriately. A byte string of length equal to that of an encoded group element is constructed by concatenating as many blocks as are required, starting from the first block, and truncating to the desired length. The byte string is then formatted as required for the group. In the case of Weierstrass curves, we take the desired length as the length for representing a compressed point (section 2.3.4 of [SEC1]), and use the low-order bit of the first byte as the sign bit. In order to obtain the correct format, the value of the first byte is set to 0x02 or 0x03 (clearing the first six bits and setting the seventh bit), leaving the sign bit as it was in the byte string constructed by concatenating hash blocks. For the [RFC8032] curves a different procedure is used. For edwards448 the 57-byte input has the least- significant 7 bits of the last byte set to zero, and for edwards25519 the 32-byte input is not modified. For both the [RFC8032] curves the (modified) input is then interpreted as the representation of the group element. If this interpretation yields a valid group element with the correct order (p), the (modified) byte string is the output. Otherwise, the initial hash block is discarded and a new byte string constructed from the remaining hash blocks. The procedure of constructing a byte string of the appropriate length, formatting it as required for the curve, and checking if it is a valid point of the correct order, is repeated until a valid element is found. The following python snippet generates the above points, assuming an elliptic curve implementation following the interface of Edwards25519Point.stdbase() and Edwards448Point.stdbase() in Appendix A of [RFC8032]: Taubert & Wood Expires 6 November 2022 [Page 19] Internet-Draft spake2plus May 2022 def iterated_hash(seed, n): h = seed for i in range(n): h = hashlib.sha256(h).digest() return h def bighash(seed, start, sz): n = -(-sz // 32) hashes = [iterated_hash(seed, i) for i in range(start, start + n)] return b''.join(hashes)[:sz] def canon_pointstr(ecname, s): if ecname == 'edwards25519': return s elif ecname == 'edwards448': return s[:-1] + bytes([s[-1] & 0x80]) else: return bytes([(s[0] & 1) | 2]) + s[1:] def gen_point(seed, ecname, ec): for i in range(1, 1000): hval = bighash(seed, i, len(ec.encode())) pointstr = canon_pointstr(ecname, hval) try: p = ec.decode(pointstr) if p != ec.zero_elem() and p * p.l() == ec.zero_elem(): return pointstr, i except Exception: pass Appendix C. Test Vectors This section contains various test vectors for SPAKE2+. (Choice of PBKDF is omitted and values for w0 and w1 are provided directly.) All points are encoded using the uncompressed format, i.e., with a 0x04 octet prefix, specified in [SEC1]. idProver and idVerifier identity strings are provided in the protocol invocation. [Context=b'SPAKE2+-P256-SHA256-HKDF-SHA256-HMAC-SHA256 Test Vectors '] [idProver=b'client'] [idVerifier=b'server'] w0 = 0xbb8e1bbcf3c48f62c08db243652ae55d3e5586053fca77102994f23ad9549 1b3 w1 = 0x7e945f34d78785b8a3ef44d0df5a1a97d6b3b460409a345ca7830387a74b1 dba L = 0x04eb7c9db3d9a9eb1f8adab81b5794c1f13ae3e225efbe91ea487425854c7f c00f00bfedcbd09b2400142d40a14f2064ef31dfaa903b91d1faea7093d835966efd Taubert & Wood Expires 6 November 2022 [Page 20] Internet-Draft spake2plus May 2022 x = 0xd1232c8e8693d02368976c174e2088851b8365d0d79a9eee709c6a05a2fad5 39 shareP = 0x04ef3bd051bf78a2234ec0df197f7828060fe9856503579bb17330090 42c15c0c1de127727f418b5966afadfdd95a6e4591d171056b333dab97a79c7193e3 41727 y = 0x717a72348a182085109c8d3917d6c43d59b224dc6a7fc4f0483232fa6516d8 b3 shareV = 0x04c0f65da0d11927bdf5d560c69e1d7d939a05b0e88291887d679fcad ea75810fb5cc1ca7494db39e82ff2f50665255d76173e09986ab46742c798a9a6843 7b048 Z = 0x04bbfce7dd7f277819c8da21544afb7964705569bdf12fb92aa388059408d5 0091a0c5f1d3127f56813b5337f9e4e67e2ca633117a4fbd559946ab474356c41839 V = 0x0458bf27c6bca011c9ce1930e8984a797a3419797b936629a5a937cf2f11c8 b9514b82b993da8a46e664f23db7c01edc87faa530db01c2ee405230b18997f16b68 TT = 0x38000000000000005350414b45322b2d503235362d5348413235362d484b4 4462d5348413235362d484d41432d534841323536205465737420566563746f72730 600000000000000636c69656e7406000000000000007365727665724100000000000 00004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12 f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d20410 000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f9 8baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1e6 56edbe7410000000000000004ef3bd051bf78a2234ec0df197f7828060fe98565035 79bb1733009042c15c0c1de127727f418b5966afadfdd95a6e4591d171056b333dab 97a79c7193e341727410000000000000004c0f65da0d11927bdf5d560c69e1d7d939 a05b0e88291887d679fcadea75810fb5cc1ca7494db39e82ff2f50665255d76173e0 9986ab46742c798a9a68437b048410000000000000004bbfce7dd7f277819c8da215 44afb7964705569bdf12fb92aa388059408d50091a0c5f1d3127f56813b5337f9e4e 67e2ca633117a4fbd559946ab474356c4183941000000000000000458bf27c6bca01 1c9ce1930e8984a797a3419797b936629a5a937cf2f11c8b9514b82b993da8a46e66 4f23db7c01edc87faa530db01c2ee405230b18997f16b682000000000000000bb8e1 bbcf3c48f62c08db243652ae55d3e5586053fca77102994f23ad95491b3 K_main = 0x4c59e1ccf2cfb961aa31bd9434478a1089b56cd11542f53d3576fb6c2 a438a29 K_confirmP = 0x871ae3f7b78445e34438fb284504240239031c39d80ac23eb5ab9 be5ad6db58a K_confirmV = 0xccd53c7c1fa37b64a462b40db8be101cedcf838950162902054e6 44b400f1680 HMAC(K_confirmP, shareV) = 0x926cc713504b9b4d76c9162ded04b5493e89109 f6d89462cd33adc46fda27527 HMAC(K_confirmV, shareP) = 0x9747bcc4f8fe9f63defee53ac9b07876d907d55 047e6ff2def2e7529089d3e68 K_shared = 0x0c5f8ccd1413423a54f6c1fb26ff01534a87f893779c6e68666d772 bfd91f3e7 [Context=b'SPAKE2+-P256-SHA512-HKDF-SHA512-HMAC-SHA512 Test Vectors '] [idProver=b'client'] [idVerifier=b'server'] Taubert & Wood Expires 6 November 2022 [Page 21] Internet-Draft spake2plus May 2022 w0 = 0x1cc5207d6e34b8f7828206fb64b86aa9c712bc952abf251bb9f5856b24d8c 8cc w1 = 0x4279649e62532b01dc27d2ed39100ba350518fb969672061a01edce752d0e 672 L = 0x043a348ad475d2200d46df876f1eb2e136056da31dafff52cc7762bf3be84d e0097c4e69b0b9321326af1f0af4a14561a9c7b640cb5afd6822d14cb34830fc4511 x = 0xb586ab83f175c1a2b56b6a1b6a283523f88a9befcf11e22efb48e2ee1fe69a 23 shareP = 0x04a7928c4b47f6b8657a5b8ebcb6f1bd266192e152fb9745a4180c946 57a2f323b4d50d536c0325cdb0ec42c9bd8db8d7af3ff6dc85edb4b5365375c62e09 def4a y = 0xac1fb828f041782d452ea9cc00c3fa34a55fa8f7f98c04be45a3d607b092d4 41 shareV = 0x04498c29e37dbd53ebf8db76679901d90c6be3af57f46ac3025b32420 839f0489c6c3b6bf5ddc8ecbc3d7c83d0891ad814a00ad23eba13197c9d96a5b1027 5e35d Z = 0x04a81e31be54283cee81bf7bdc877764b6b2ac6a399f1176380aac8a82172c 18051aa17dfcf438896ad253f53b52cd45ec2c7399488a919bcfcfecc0261cbf5284 V = 0x04de0a53f96cbe4abcd31c1e0a23ea6f169c162dc5a007393c8fcddd2abd5d 518bb2d9734b1d2dfce3fd916e991ab9dc3a2760d439c083eb39b65408857d2bb4aa TT = 0x38000000000000005350414b45322b2d503235362d5348413531322d484b4 4462d5348413531322d484d41432d534841353132205465737420566563746f72730 600000000000000636c69656e7406000000000000007365727665724100000000000 00004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12 f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d20410 000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f9 8baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1e6 56edbe7410000000000000004a7928c4b47f6b8657a5b8ebcb6f1bd266192e152fb9 745a4180c94657a2f323b4d50d536c0325cdb0ec42c9bd8db8d7af3ff6dc85edb4b5 365375c62e09def4a410000000000000004498c29e37dbd53ebf8db76679901d90c6 be3af57f46ac3025b32420839f0489c6c3b6bf5ddc8ecbc3d7c83d0891ad814a00ad 23eba13197c9d96a5b10275e35d410000000000000004a81e31be54283cee81bf7bd c877764b6b2ac6a399f1176380aac8a82172c18051aa17dfcf438896ad253f53b52c d45ec2c7399488a919bcfcfecc0261cbf5284410000000000000004de0a53f96cbe4 abcd31c1e0a23ea6f169c162dc5a007393c8fcddd2abd5d518bb2d9734b1d2dfce3f d916e991ab9dc3a2760d439c083eb39b65408857d2bb4aa20000000000000001cc52 07d6e34b8f7828206fb64b86aa9c712bc952abf251bb9f5856b24d8c8cc K_main = 0x527613439c279a375c116342a4216a8d92441d2fe1921dd1e60f140b2 855916ccac7db4dbf22bd56e344a8cd506d08949bde1e9d83c24d68ff4246458dc14 288 K_confirmP = 0x0aa129d7b82067c2a9607677c9c4fdedc1cd7cfed9ff72c54c0ae bb2b1a8aa915b96834b2986725c6040852ceaafbb17d638a715198f795654eac89bf 0739878 K_confirmV = 0xa1f1038de30a8c12d43d06c27d362daa9699249e941faa2d5cbc5 9a9683bf42aed9537818245677fdb54b5274506542994f4a83455f6d7b3af5ec017f aa58f61 HMAC(K_confirmP, shareV) = 0x6b2469b56cf8ac3f94a8d0b533380ea6b3d0f46 b3e12ee82550d49e129c2412728c9437a64ee5f80c8cdc5e8a30faa0a6deb8a52513 Taubert & Wood Expires 6 November 2022 [Page 22] Internet-Draft spake2plus May 2022 46ba81bb6fc955b2304fc HMAC(K_confirmV, shareP) = 0x154174fc278a935e290b3352ba877e179fa9281 c0a76928faea703c72d383b267511a5cf084cb07147efece94e3cfd91944e7baab85 6858fbebc087167b0f409 K_shared = 0x11887659d9e002f34fa6cc270d33570f001b2a3fc0522b643c07327 d09a4a9f47aab85813d13c585b53adf5ac9de5707114848f3dc31a4045f69a2cc197 2b098 [Context=b'SPAKE2+-P384-SHA256-HKDF-SHA256-HMAC-SHA256 Test Vectors '] [idProver=b'client'] [idVerifier=b'server'] w0 = 0x097a61cbb1cee72bb654be96d80f46e0e3531151003903b572fc193f23377 2c23c22228884a0d5447d0ab49a656ce1d2 w1 = 0x18772816140e6c3c3938a693c600b2191118a34c7956e1f1cd5b0d519b56e a5858060966cfaf27679c9182129949e74f L = 0x04f27dd5384d6b9beb4c5022c94b1978d632779e1d3abe458611e734a529d0 04e25053398e5dc9eeaa4ffa59743ca7ddbc0e7ce69155295cb2b846da83ee6a4449 0dd8e96bb0b0f6645281bfd978dd5f6836561ea0d8b2c045ff04cef2e5873d2c x = 0x2f1bdbeda162ff2beba0293d3cd3ae95f663c53663378c7e18ee8f56a4a48b 00d31ce0ef43606548da485058f12e8e73 shareP = 0x049fb0404ca7ce71fb85d3aaa8fd05fa054affac996135bc245149be0 9571e43e2bf76e00d6d52ac452b8224f6b9da31420a4f5e214b377546daad4d61da5 ca0cfdea59a5a92ebdb6b42da5d14663b8d1f9eb97050139ab89788e0ada27b048fc f y = 0xbbcaf02404a16ed4fa73b183f703a8d969386f3d34f5e98b3a904e760512f1 1757f07dfcf87a2ada8fc6d028445bd53e shareV = 0x0493b1c1f6a30eac4ac4a15711e44640bae3576787627ee2541104298 1e94b2e9604b9374f66bb247bc431759212ef3fa0a20c087863b89efb32219e1337c e94be2175f8cb9fd50cf0b84772717fd063c52b69de1229a01ab840b55993287f32e d Z = 0x048cd880e5147e49b42b5754c1bc6d2091ad414789bc3b030f2d787ea480f3 e35d0fa0d02d0dd06fee7f242b702a2d984efd79c76d99ab35b99e359a205cea56bb a8dd8f995c101a69a5157686d1cf6a7288d7cff2f2a9748db99b24f646ea7b37 V = 0x041c3c9cc38b03a06a49cf17cc5e7754cf1ccbbc6fffc0ddf1a6e23f57294a 25d96f7da5ce4ac0a617c78502f2f235a5fcf2f76a62385434ed2b6e95521b41eff3 c4ce93ecf8fb32005dd76335d0a7c78153257288d7fde1a22d404f5d73d068e2 TT = 0x38000000000000005350414b45322b2d503338342d5348413235362d484b4 4462d5348413235362d484d41432d534841323536205465737420566563746f72730 600000000000000636c69656e7406000000000000007365727665726100000000000 000040ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3 dc36f15314739074d2eb8613fceec285397592c55797cdd77c0715cb7df2150220a0 119866486af4234f390aad1f6addde5930909adc67a1fc0c99ba3d52dc5dd6100000 00000000004c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518 f9c543bb252c5490214cf9aa3f0baab4b665c10c38b7d7f4e7f320317cd717315a79 7c7e02933aef68b364cbf84ebc619bedbe21ff5c69ea0f1fed5d7e3200418073f406 100000000000000049fb0404ca7ce71fb85d3aaa8fd05fa054affac996135bc24514 9be09571e43e2bf76e00d6d52ac452b8224f6b9da31420a4f5e214b377546daad4d6 Taubert & Wood Expires 6 November 2022 [Page 23] Internet-Draft spake2plus May 2022 1da5ca0cfdea59a5a92ebdb6b42da5d14663b8d1f9eb97050139ab89788e0ada27b0 48fcf61000000000000000493b1c1f6a30eac4ac4a15711e44640bae3576787627ee 25411042981e94b2e9604b9374f66bb247bc431759212ef3fa0a20c087863b89efb3 2219e1337ce94be2175f8cb9fd50cf0b84772717fd063c52b69de1229a01ab840b55 993287f32ed6100000000000000048cd880e5147e49b42b5754c1bc6d2091ad41478 9bc3b030f2d787ea480f3e35d0fa0d02d0dd06fee7f242b702a2d984efd79c76d99a b35b99e359a205cea56bba8dd8f995c101a69a5157686d1cf6a7288d7cff2f2a9748 db99b24f646ea7b376100000000000000041c3c9cc38b03a06a49cf17cc5e7754cf1 ccbbc6fffc0ddf1a6e23f57294a25d96f7da5ce4ac0a617c78502f2f235a5fcf2f76 a62385434ed2b6e95521b41eff3c4ce93ecf8fb32005dd76335d0a7c78153257288d 7fde1a22d404f5d73d068e23000000000000000097a61cbb1cee72bb654be96d80f4 6e0e3531151003903b572fc193f233772c23c22228884a0d5447d0ab49a656ce1d2 K_main = 0x61370f8bf65e0df7e9a7b2c2289be1ee4b5dd6c21f4b85165730700c4 4ce30af K_confirmP = 0x2c8940419d94e53d5d240801e702c4658531aa7a9f14ec75f0d67 f12fa84196c K_confirmV = 0x8e74afe16c53a44590ad6bf43aa89324978b8f20014336675f618 387f99f3fdc HMAC(K_confirmP, shareV) = 0x7ae825e242a5a1f86ad7db172c2c12fcb458b6a 2b1ddfc96b2b7cfd2eed5f7ab HMAC(K_confirmV, shareP) = 0x1581062167d6a3d14493447cd170d408f6fdc58 e31225438db86214167426a7a K_shared = 0x99758e838ae1a856589689fb55b6befe4e2382e6ebbeca1a6232a68 f9dc04c1a [Context=b'SPAKE2+-P384-SHA512-HKDF-SHA512-HMAC-SHA512 Test Vectors '] [idProver=b'client'] [idVerifier=b'server'] w0 = 0xb8d44a0982b88abe19b724d4bdafba8c90dc93130e0bf4f8062810992326d a126fd01db53e40250ca33a3ff302044cb0 w1 = 0x2373e2071c3bb2a6d53ece57830d56f8080189816803c22375d6a4a514f9d 161b64d0f05b97735b98b348f9b33cc2e30 L = 0x049ca7217ff6456bb2e2bcf71b31d9b1e5ed6e0c9700936ae617e990cee87e e1ce3a03629dd5532948c39b89f38b39f13c7f513c5b1ada00f6533a4a8b02b9cd04 e1b2a5db1f24ec5fe959198a19666037e04b768cc02e75ac9da0048736db6e5b x = 0x5a835d52714f30d2ef539268b89df9558628400063dfa0e41eb979066f4caf 409bbf7aab3ddddea13f1b070a1827d3d4 shareP = 0x042f382eef464a2c9aecfdf4b81d25c4de2de113ba67405ce336c762c 69217ae7e27bda875144140d7536c4cc08b9b4dace5f872a6a2ed57f34042688ad3c 5d446c187dc0caf9cea812df3a4dd6fdbc64b9d7d7d7ff4bf6965abb06eeb108d55e e y = 0xc883ee5b08cf7ba122038c279459ab1a730f85f2d624a02732d519faab56a4 98e773a8dec6c447ed02d5c00303a18bc4 shareV = 0x04d72e11eee332305062454c0a058b8103a3304785d445510cd8d101e 9cb44cfb159cb7b72123abaf719ab1c42e0558c84c14b0886e8b446e4c880bff2f4b 291fafafc748cb4115824e66732bdeba7fae176388e228ab9d7546255994ca3fb5a5 2 Taubert & Wood Expires 6 November 2022 [Page 24] Internet-Draft spake2plus May 2022 Z = 0x043cb63f5fcb573cf3e2ee40bca5fbc1f00ff2554caab3790329184c45ed69 c39b2e1323bc13c8f821b844feb5921b1470e7b3f70bd10508e5de6db157305badf8 20fa28d68742d8287fb201383a8deec70d5bcf2a61498a481290ed8cc94ab3a0 V = 0x0468604d188f4da560ddaaece126abe40f5de255f8af093c7c3aff71f95d90 92804426127d73d46a817085e9095de6bcf30733a5124a98f567148efe92a7134994 0c7244623247d33a8b78cbc9a53cd45bb22430f318a635084d1840c905f236c8 TT = 0x38000000000000005350414b45322b2d503338342d5348413531322d484b4 4462d5348413531322d484d41432d534841353132205465737420566563746f72730 600000000000000636c69656e7406000000000000007365727665726100000000000 000040ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3 dc36f15314739074d2eb8613fceec285397592c55797cdd77c0715cb7df2150220a0 119866486af4234f390aad1f6addde5930909adc67a1fc0c99ba3d52dc5dd6100000 00000000004c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518 f9c543bb252c5490214cf9aa3f0baab4b665c10c38b7d7f4e7f320317cd717315a79 7c7e02933aef68b364cbf84ebc619bedbe21ff5c69ea0f1fed5d7e3200418073f406 100000000000000042f382eef464a2c9aecfdf4b81d25c4de2de113ba67405ce336c 762c69217ae7e27bda875144140d7536c4cc08b9b4dace5f872a6a2ed57f34042688 ad3c5d446c187dc0caf9cea812df3a4dd6fdbc64b9d7d7d7ff4bf6965abb06eeb108 d55ee610000000000000004d72e11eee332305062454c0a058b8103a3304785d4455 10cd8d101e9cb44cfb159cb7b72123abaf719ab1c42e0558c84c14b0886e8b446e4c 880bff2f4b291fafafc748cb4115824e66732bdeba7fae176388e228ab9d75462559 94ca3fb5a526100000000000000043cb63f5fcb573cf3e2ee40bca5fbc1f00ff2554 caab3790329184c45ed69c39b2e1323bc13c8f821b844feb5921b1470e7b3f70bd10 508e5de6db157305badf820fa28d68742d8287fb201383a8deec70d5bcf2a61498a4 81290ed8cc94ab3a061000000000000000468604d188f4da560ddaaece126abe40f5 de255f8af093c7c3aff71f95d9092804426127d73d46a817085e9095de6bcf30733a 5124a98f567148efe92a71349940c7244623247d33a8b78cbc9a53cd45bb22430f31 8a635084d1840c905f236c83000000000000000b8d44a0982b88abe19b724d4bdafb a8c90dc93130e0bf4f8062810992326da126fd01db53e40250ca33a3ff302044cb0 K_main = 0x571af2e9a0bf4b354cca18d713f8a84315a46c999ceb92ca6a88b8a6d 615795140862dbccd6fdc0abecc5956c43f8ab40343a22fc1b91752cb7c2737dab90 41e K_confirmP = 0x6c8c7fc6becf3bc07f081b4f7f867bec76fd8eeddbd7968356723 bae701e04f35f800e647dfa013b2876958efe0ce68e7595ba46f1de0b17adfc02dfe 3f18a18 K_confirmV = 0x2d0c9702a0f5536bacddd596eb6ea365d17f176db30081b97b83e 05bb87e9a36c0565b7616251c93bc76c76fc5c3531a28db40779d986d4e7b71a24c4 3fbc731 HMAC(K_confirmP, shareV) = 0x7f806ae56ea3e49a8b16ffee528086489418913 641f529d50ff92aa456ad4648e522f9540b403bff6bd94ee1adc95c7d1b2666f7ba6 f9c10748bc7bfb4181d27 HMAC(K_confirmV, shareP) = 0x8daa262decb79cceda4421f4f8dacf22ec027c0 8e036f071beea563c8e00813a29807963ff9d7d6bbff48dd5bdcdd9ca9fd7ffc272b 162258d981913f7253dcb K_shared = 0x31e0075a823b9269af5769d71ef3b2f5001cbfe044584fe8551124a 217dad078415630bf3eda16b5a38341d418a6d72b3960f818a0926f0de88784b59d6 a694b Taubert & Wood Expires 6 November 2022 [Page 25] Internet-Draft spake2plus May 2022 [Context=b'SPAKE2+-P521-SHA512-HKDF-SHA512-HMAC-SHA512 Test Vectors '] [idProver=b'client'] [idVerifier=b'server'] w0 = 0x009c79bcd7656716314fca5a6e2c5cda7ef86131399438e012a043051e863 f60b5aeb3c101731e1505e721580f48535a9b0456b231b9266ae6fff49ee90d25f72 f5f w1 = 0x01632c15f51fcd916cd79e19075f8a69b72b0099922ad62ff8d540b469569 f0aa027047aed2b3f242ea0ac4288b4e4db6a4e5946d8ad32b42192c5aa66d9ef8e1 b33 L = 0x040135072d0fa36f9e80031294cef5c3c35b882a0efa2c66570d64a49f8bec 6c66435bf65bb7c7b2a3e7dece491e02b4d567e7087dbc32fe0fae8af417dcb50be6 d704012a194588b690e6d3db492656f72ddea01fc1c7fcec0f5d34a5af0102939f6f deae39c20cff74fcdb7f09855f0fc9520d20b0520b0b096b8d42c7c3d68b4a66f751 x = 0x00b69e3bb15df82c9fa0057461334e2c66ab92fc9b8d3662eec81216ef5ddc 4a43f19e90dedaa2d72502f69673a115984ffcf88e03a9364b07102114c5602cd93c 69 shareP = 0x0400a14431edf6852ff5fe868f8683e16e9e0a45d9e27f9a96442285a c6b161fc0bf267362a5ffb06f9cbd14b7a37e492146d77cae4c77812df00a91dbae0 9e27e1fac00ae019317ef9768548325bca35ce258e6206fe03c6338b2eb889d09d9f 11400a36cf6328a7e1f81c6c7a2af7ff1d9b5210768318f27e57b75b39b9fbfc7b37 a60ab y = 0x0056d01c5246fbde964c0493934b7ece89eafd943eb27d357880a2a2202249 9e249528c5707b1afe8794c8a1d60ceedaeed96dd0dd904ea075f096c9fec5da7de4 96 shareV = 0x0401aa5af0f3027f63b7170572db5ff06dd1f3d6ea8ea771b26b434fb bc6c9de7d80975131c9c2e94d30c0ed2d62449c4c1b7e95037a85ed7598e415a2591 26365e89500d0f2156b551b70416d719944736990f346f6f9ba4fbaf2f63e0987369 0bcf730582e0a7b03ffede50f5787b631d5021a94287f0a29a081b62b9f5a3bf393b 001b3 Z = 0x0401e3015bf2811891a518d342c63541294dc80e0ee210e8220a5b9cab010d 77945724ef1185d739a62847fdada9da9b1bca6b9fa173fa551185c6084c3db26d3a f0ac01f9356d01beebebd5ff026ca19f9df5d614355f3498816ac20b63bc936eed82 8a7039d1e17dba740471d9afc0e0b4427d65b2d27a57a87e42300004e2b4620c23c9 V = 0x0401058b21ca71e4439281579d6df3b86ae874d70742fe8eae2de60e77e07e 6e1c31b9c277de36b38531f5b769e9e4030ba09258f510c83c5c21957610355ce920 1fe600672db35efd1d0903bc285d4e27e9fb4472c30f17118dfa028f182bc9361c6a 749f560e31b9c404624d24e68010f064101d4a1154e77be8f2105dbeb8b0349adb0e TT = 0x38000000000000005350414b45322b2d503532312d5348413531322d484b4 4462d5348413531322d484d41432d534841353132205465737420566563746f72730 600000000000000636c69656e7406000000000000007365727665728500000000000 00004003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d856 08cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7a a01bdd179a3d547610892e9b96dea1eab10bdd7ac5ae0cf75aa0f853bfd185cf782f 894301998b11d1898ede2701dca37a2bb50b4f519c3d89a7d054b51fb84912192850 00000000000000400c7924b9ec017f3094562894336a53c50167ba8c596387688054 2bc669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc34 9d95575cd2501c62bee650c9287a651bb75c7f39a2006873347b769840d261d17760 Taubert & Wood Expires 6 November 2022 [Page 26] Internet-Draft spake2plus May 2022 b107e29f091d556a82a2e4cde0c40b84b95b878db2489ef760206424b3fe7968aa8e 0b1f33485000000000000000400a14431edf6852ff5fe868f8683e16e9e0a45d9e27 f9a96442285ac6b161fc0bf267362a5ffb06f9cbd14b7a37e492146d77cae4c77812 df00a91dbae09e27e1fac00ae019317ef9768548325bca35ce258e6206fe03c6338b 2eb889d09d9f11400a36cf6328a7e1f81c6c7a2af7ff1d9b5210768318f27e57b75b 39b9fbfc7b37a60ab85000000000000000401aa5af0f3027f63b7170572db5ff06dd 1f3d6ea8ea771b26b434fbbc6c9de7d80975131c9c2e94d30c0ed2d62449c4c1b7e9 5037a85ed7598e415a259126365e89500d0f2156b551b70416d719944736990f346f 6f9ba4fbaf2f63e09873690bcf730582e0a7b03ffede50f5787b631d5021a94287f0 a29a081b62b9f5a3bf393b001b385000000000000000401e3015bf2811891a518d34 2c63541294dc80e0ee210e8220a5b9cab010d77945724ef1185d739a62847fdada9d a9b1bca6b9fa173fa551185c6084c3db26d3af0ac01f9356d01beebebd5ff026ca19 f9df5d614355f3498816ac20b63bc936eed828a7039d1e17dba740471d9afc0e0b44 27d65b2d27a57a87e42300004e2b4620c23c985000000000000000401058b21ca71e 4439281579d6df3b86ae874d70742fe8eae2de60e77e07e6e1c31b9c277de36b3853 1f5b769e9e4030ba09258f510c83c5c21957610355ce9201fe600672db35efd1d090 3bc285d4e27e9fb4472c30f17118dfa028f182bc9361c6a749f560e31b9c404624d2 4e68010f064101d4a1154e77be8f2105dbeb8b0349adb0e4200000000000000009c7 9bcd7656716314fca5a6e2c5cda7ef86131399438e012a043051e863f60b5aeb3c10 1731e1505e721580f48535a9b0456b231b9266ae6fff49ee90d25f72f5f K_main = 0xf672a73216568d20cc3433247bc43a3b875a421cbdba76cf1db8bfe57 2b658bf3f7a4ef8cc9ff1f6a2827ff7b19860454b775a4097009040f3b36b7420407 16e K_confirmP = 0xa211c60ea8d4b3b294bd6ca9515663b77f3caac28af3658b34fe1 512f25077f2f64b8de426caa662b4cbbdc9c2f8f12347993c8d57fdf68c177732d7d da7277b K_confirmV = 0x0e9bf6b9a37339144cb32a78a872f50b10839f81eda6c09a827dd bb158c47162bec274af920cdf809f162b98fa701efebada26cdfbeac408b5a35b052 d18f0c6 HMAC(K_confirmP, shareV) = 0xf0f5c903dfa42fe367659656a26058cd984b76a 8e91ae4d0fa4c13db149008e2ae57713fb230a627761174fefd263b9c10e9a4b6a37 46cde59c5943040c17133 HMAC(K_confirmV, shareP) = 0xa8f7ab43f3a800171d3a3fb26d742e1ed236c2d 5804ecd328f220a7d245cd2e3bfb6c0526983bff9229c94f70fe64ba9bb5a4d0dc10 afcda64a4c96d4c3d81ad K_shared = 0xd1c170e4e55efacb9db8abad286293ebd1dcf24f13973427b9632bb c323e42e447afca2aa7f74f2af3fb5f51684ec543db854b7002cde6799c330b032ba 8820a [Context=b'SPAKE2+-P256-SHA256-HKDF-SHA256-CMAC-AES-128 Test Vector s'] [idProver=b'client'] [idVerifier=b'server'] w0 = 0x9aad90c603cf16cec4ee40d81acd7a865130b28cc6d0664ae2e0f406aa47e d61 w1 = 0x872be859cec1e78d191882bd9c2f032af018a25016813788fe8954bfffc58 c8e L = 0x04d79a53698c5dd79e14b426e73b4a7f1b42469815fe24e8f53ce01579e902 Taubert & Wood Expires 6 November 2022 [Page 27] Internet-Draft spake2plus May 2022 eb198d59f05bc451c41826b88e3db5476a69e197fdf474c75b387f6d40361c3fda35 x = 0x9d39a3511a007a7d3fe6af5555cf60301bcda503f2bf6634b2caf9e4fd0743 a1 shareP = 0x04788218027ba4b17f7279ef0aef47a8733cf88b5bf65d6127ecadc78 b8a0f65b9001f7e54719fb63c072ddd1e1a4adfb376dde37ba1aa2082362b6c2ca14 a8e53 y = 0x9c3219841626325c68d89c22fb6c55611e3136442daa8b9b784db7242afff3 ed shareV = 0x04c05953ea9d1cd6248b8c61becd7d55e46237526d8b1e23495ea7566 b7f6bc24b3da1cfb2e88a975fcfb5dc4e72b5cbea509b1cfdd1ef8f8195fa8bf2bd5 ca1e5 Z = 0x049444a17ad5909548a084fa182275a89a496ec6669bd08892aa9c64a512d4 0212147e6005bf1d510e3bbcfee8efc38243acaf4c5f2decffa009341b1e330b0442 V = 0x0457a8919af393e2da1de209a01fdda275eab0a682d8931b0e6ee1b9339794 63a25ccbcda1956a6a555706f0b062aa880617bd219d09391ad8576d3a73e9233f57 TT = 0x39000000000000005350414b45322b2d503235362d5348413235362d484b4 4462d5348413235362d434d41432d4145532d313238205465737420566563746f727 30600000000000000636c69656e74060000000000000073657276657241000000000 0000004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa 12f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d204 10000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4 f98baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1 e656edbe7410000000000000004788218027ba4b17f7279ef0aef47a8733cf88b5bf 65d6127ecadc78b8a0f65b9001f7e54719fb63c072ddd1e1a4adfb376dde37ba1aa2 082362b6c2ca14a8e53410000000000000004c05953ea9d1cd6248b8c61becd7d55e 46237526d8b1e23495ea7566b7f6bc24b3da1cfb2e88a975fcfb5dc4e72b5cbea509 b1cfdd1ef8f8195fa8bf2bd5ca1e54100000000000000049444a17ad5909548a084f a182275a89a496ec6669bd08892aa9c64a512d40212147e6005bf1d510e3bbcfee8e fc38243acaf4c5f2decffa009341b1e330b044241000000000000000457a8919af39 3e2da1de209a01fdda275eab0a682d8931b0e6ee1b933979463a25ccbcda1956a6a5 55706f0b062aa880617bd219d09391ad8576d3a73e9233f5720000000000000009aa d90c603cf16cec4ee40d81acd7a865130b28cc6d0664ae2e0f406aa47ed61 K_main = 0x6002da6b2740056f2836ac0316ae9e02e2b24c5c109883136e90ed868 b2fcf62 K_confirmP = 0x857d0db7f5e06385853bf4b8abd43b5a K_confirmV = 0x268c75933332157118063550c6bfe846 CMAC(K_confirmP, shareV) = 0xd340bc94a03feafd14491e316514ca5f CMAC(K_confirmV, shareP) = 0x2b42d0fe76bcf9ccc208d06d60082f96 K_shared = 0xe832094adfc028bf288e49ab902fc208b7eeff084f259da7613c047 9869d4fc9 [Context=b'SPAKE2+-P256-SHA512-HKDF-SHA512-CMAC-AES-128 Test Vector s'] [idProver=b'client'] [idVerifier=b'server'] w0 = 0x56e0299ac95739b616a973276c1338e3651285345dde2f7faf74c25c0b50e b90 w1 = 0x462fe5b522a17d3d35b27323113bdd252de9cbfdd6f264b35721bf59a9a74 Taubert & Wood Expires 6 November 2022 [Page 28] Internet-Draft spake2plus May 2022 f0b L = 0x040540332ffec8a2faa8d17ae6da5973c11e078b8c10c89fd6af996726b802 3513eff2914c3ced64fbedd4e261438fb0ea6ef9fc1faef4ba1ead780636faac1bc1 x = 0x254dd22780eeb6af2464dd6a2bd026b46a34966d6933607f1be956314f74b0 ea shareP = 0x049661cfdb0f7bd24b637f8d1d0f464c17f0b9c15129ea31156dcc581 da6c840240b275d72f28ea73a5c088c99d73896af24a5ae26e036eb2dedaf26e511a 24a48 y = 0x695beec24305fbd5660bc200228598e7c891fdf60a55df4bdd3a57debc3847 4a shareV = 0x0461f580eb3eb4b2f412d5c07491f360ad6e4492d8f23e346f0ba999f bbcb9715a3c2485c3b250a6672e6698da3c9a9725645f607ee90a9b1b34fd44b9df6 e551a Z = 0x0406f77a4bca254219dc3eeca9989f377037407105540bfddc5bdeff3d27a8 7d68442e69d543a000077bd4c42e33930f890d29fb4be5e8dcc627f6811ace96c274 V = 0x0442952a531a2937e03808e74f6d65afbedb4cfb7fcf91991498f77db21b14 6f5c2249e727e374de03f32848465aba5c5ebfe6501d3537d09160c7f42e4b3f133d TT = 0x39000000000000005350414b45322b2d503235362d5348413531322d484b4 4462d5348413531322d434d41432d4145532d313238205465737420566563746f727 30600000000000000636c69656e74060000000000000073657276657241000000000 0000004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa 12f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d204 10000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4 f98baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1 e656edbe74100000000000000049661cfdb0f7bd24b637f8d1d0f464c17f0b9c1512 9ea31156dcc581da6c840240b275d72f28ea73a5c088c99d73896af24a5ae26e036e b2dedaf26e511a24a4841000000000000000461f580eb3eb4b2f412d5c07491f360a d6e4492d8f23e346f0ba999fbbcb9715a3c2485c3b250a6672e6698da3c9a9725645 f607ee90a9b1b34fd44b9df6e551a41000000000000000406f77a4bca254219dc3ee ca9989f377037407105540bfddc5bdeff3d27a87d68442e69d543a000077bd4c42e3 3930f890d29fb4be5e8dcc627f6811ace96c27441000000000000000442952a531a2 937e03808e74f6d65afbedb4cfb7fcf91991498f77db21b146f5c2249e727e374de0 3f32848465aba5c5ebfe6501d3537d09160c7f42e4b3f133d200000000000000056e 0299ac95739b616a973276c1338e3651285345dde2f7faf74c25c0b50eb90 K_main = 0x111790ae23de3fc5bb43bdc1f63106461dbd8d86360adf056bf117164 8bfb231503853db2625275b7136b5a823dd5a94482514fce7f791c4daca2b21c7bde 756 K_confirmP = 0xb234d2e152a03168b76c6474d5322070 K_confirmV = 0x683d62024626fe0c5126ef4df58b88ee CMAC(K_confirmP, shareV) = 0x0dc514d262e37470eb43e058e0d615f4 CMAC(K_confirmV, shareP) = 0xde076589efcd5d96c2ea6061d96772d9 K_shared = 0x488a34663d6be5e02590bb8e9ad9ad3e0f580dec41e8b99ed4ae4b7 34da49287638cac4c9f17fe3c3ae18dda0d6d7f14c17e4640d5a2aaab959efa0cbea 4e546 Authors' Addresses Taubert & Wood Expires 6 November 2022 [Page 29] Internet-Draft spake2plus May 2022 Tim Taubert Apple Inc. One Apple Park Way Cupertino, California 95014, United States of America Email: ttaubert@apple.com Christopher A. Wood Email: caw@heapingbits.net Taubert & Wood Expires 6 November 2022 [Page 30] ./draft-ietf-ipsecme-yang-iptfs-11.txt0000644000764400076440000014746514313166601017374 0ustar iustiniustin Network Working Group D. Fedyk Internet-Draft C. Hopps Intended status: Standards Track LabN Consulting, L.L.C. Expires: 26 March 2023 22 September 2022 A YANG Data Model for IP Traffic Flow Security draft-ietf-ipsecme-yang-iptfs-11 Abstract This document describes a YANG module for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 March 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Fedyk & Hopps Expires 26 March 2023 [Page 1] Internet-Draft A YANG Data Model for IP-TFS September 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. YANG Management . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 4.1. Updates to the IETF XML Registry . . . . . . . . . . . . 19 4.2. Updates to the YANG Module Names Registry . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Normative References . . . . . . . . . . . . . . . . . . 21 7.2. Informative References . . . . . . . . . . . . . . . . . 21 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 22 A.1. Example XML Configuration . . . . . . . . . . . . . . . . 22 A.2. Example XML Operational Data . . . . . . . . . . . . . . 23 A.3. Example JSON Configuration . . . . . . . . . . . . . . . 24 A.4. Example JSON Operational Data . . . . . . . . . . . . . . 26 A.5. Example JSON Operational Statistics . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction This document defines a YANG module [RFC7950] for the management of the IP Traffic Flow Security (IP-TFS) extensions as defined in [I-D.ietf-ipsecme-iptfs]. IP-TFS provides enhancements to an IPsec tunnel Security Association to provide improved traffic confidentiality. Traffic confidentiality reduces the ability of traffic analysis to determine identity and correlate observable traffic patterns. IP-TFS offers efficiency when aggregating traffic in fixed size IPsec tunnel packets. The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. The published YANG modules for IPsec are defined in [RFC9061]. This document uses these models as a general IPsec model that is augmented for IP-TFS. The models in [RFC9061] provide for both an IKE and an IKELESS model. Fedyk & Hopps Expires 26 March 2023 [Page 2] Internet-Draft A YANG Data Model for IP-TFS September 2022 2. Overview This document defines configuration and operational parameters of IP traffic flow security (IP-TFS). IP-TFS, defined in [I-D.ietf-ipsecme-iptfs], defines a security association for tunnel mode IPsec with characteristics that improve traffic confidentiality and reduce bandwidth efficiency loss. These documents assume familiarity with IP security concepts described in [RFC4301]. IP-TFS uses tunnel mode to improve confidentiality by hiding inner packet identifiable information, packet size and packet timing. IP- TFS provides a general capability allowing aggregation of multiple packets in uniform size outer tunnel IPsec packets. It maintains the outer packet size by utilizing combinations of aggregating, padding and fragmenting inner packets to fill out the IPsec outer tunnel packet. Zero byte padding is used to fill the packet when no data is available to send. This document specifies an extensible configuration model for IP-TFS. This version utilizes the capabilities of IP-TFS to configure fixed size IP-TFS Packets that are transmitted at a constant rate. This model is structured to allow for different types of operation through future augmentation. The IP-TFS YANG module augments IPsec YANG model from [RFC9061]. IP- TFS makes use of IPsec tunnel mode and adds a small number configuration items to tunnel mode IPsec. As defined in [I-D.ietf-ipsecme-iptfs], any SA configured to use IP-TFS supports only IP-TFS packets i.e. no mixed IPsec modes. The behavior for IP-TFS is controlled by the source. The self- describing format of an IP-TFS packets allows a sending side to adjust the packet-size and timing independently from any receiver. Both directions are also independent, e.g. IP-TFS may be run only in one direction. This means that counters, which are created here for both directions may be 0 or not updated in the case of an SA that uses IP-TFS only in on direction. Cases where IP-TFS statistics are active for one direction: * SA one direction - IP-TFS enabled * SA both directions - IP-TFS only enabled in one direction Case where IP-TFS statistics are for both directions: * SA both directions - IP-TFS enable for both directions Fedyk & Hopps Expires 26 March 2023 [Page 3] Internet-Draft A YANG Data Model for IP-TFS September 2022 The IP-TFS model support IP-TFS configuration and operational data. This YANG module supports configuration of fixed size and fixed rate packets, and elements that may be augmented to support future configuration. The protocol specification [I-D.ietf-ipsecme-iptfs], goes beyond this simple fixed mode of operation by defining a general format for any type of scheme. In this document the outer IPsec packets can be sent with fixed or variable size (without padding). The configuration allows the fixed packet size to be determined by the path MTU. The fixed packet size can also be configured if a value lower than the path MTU is desired. Other configuration items include: * Congestion Control. A congestion control setting to allow IP-TFS to reduce the packet rate when congestion is detected. * Fixed Rate configuration. The IP-TFS tunnel rate can be configured taking into account either layer 2 overhead or layer 3 overhead. Layer 3 overhead is the IP data rate and layer 2 overhead is the rate of bits on the link. The combination of packet size and rate determines the nominal maximum bandwidth and the transmission interval when fixed size packets are used. * User packet Fragmentation Control. While fragmentation is recommended for improved efficiency, a configuration is provided if users wish to observe the effect no-fragmentation on their data flows. The YANG operational data allows the readout of the configured parameters as well as the per SA statistics and error counters for IP-TFS. Per SA IPsec packet statistics are provided as a feature and per SA IP-TFS specific statistics as another feature. Both sets of statistics augment the IPsec YANG models with counters that allow observation of IP-TFS packet efficiency. [RFC9061] has a set of IPsec YANG management objects. IP-TFS YANG augments the IKE and the IKELESS models. In these models the Security Policy database entry and Security Association entry for an IPsec Tunnel can be augmented with IP-TFS. In addition, this model uses YANG types defined in [RFC6991]. 3. YANG Management 3.1. YANG Tree The following is the YANG tree diagram ([RFC8340]) for the IP-TFS extensions. Fedyk & Hopps Expires 26 March 2023 [Page 4] Internet-Draft A YANG Data Model for IP-TFS September 2022 module: ietf-ipsec-iptfs augment /nsfike:ipsec-ike/nsfike:conn-entry/nsfike:spd /nsfike:spd-entry/nsfike:ipsec-policy-config /nsfike:processing-info/nsfike:ipsec-sa-cfg: +--rw traffic-flow-security +--rw congestion-control? boolean +--rw packet-size | +--rw use-path-mtu-discovery? boolean | +--rw outer-packet-size? uint16 +--rw (tunnel-rate)? | +--:(l2-fixed-rate) | | +--rw l2-fixed-rate? yang:gauge64 | +--:(l3-fixed-rate) | +--rw l3-fixed-rate? yang:gauge64 +--rw dont-fragment? boolean +--rw max-aggregation-time? decimal64 +--rw window-size? uint16 +--rw send-immediately? boolean +--rw lost-packet-timer-interval? decimal64 augment /nsfike:ipsec-ike/nsfike:conn-entry/nsfike:child-sa-info: +--ro traffic-flow-security +--ro congestion-control? boolean +--ro packet-size | +--ro use-path-mtu-discovery? boolean | +--ro outer-packet-size? uint16 +--ro (tunnel-rate)? | +--:(l2-fixed-rate) | | +--ro l2-fixed-rate? yang:gauge64 | +--:(l3-fixed-rate) | +--ro l3-fixed-rate? yang:gauge64 +--ro dont-fragment? boolean +--ro max-aggregation-time? decimal64 +--ro window-size? uint16 +--ro send-immediately? boolean +--ro lost-packet-timer-interval? decimal64 augment /nsfikels:ipsec-ikeless/nsfikels:spd/nsfikels:spd-entry /nsfikels:ipsec-policy-config/nsfikels:processing-info /nsfikels:ipsec-sa-cfg: +--rw traffic-flow-security +--rw congestion-control? boolean +--rw packet-size | +--rw use-path-mtu-discovery? boolean | +--rw outer-packet-size? uint16 +--rw (tunnel-rate)? | +--:(l2-fixed-rate) | | +--rw l2-fixed-rate? yang:gauge64 | +--:(l3-fixed-rate) Fedyk & Hopps Expires 26 March 2023 [Page 5] Internet-Draft A YANG Data Model for IP-TFS September 2022 | +--rw l3-fixed-rate? yang:gauge64 +--rw dont-fragment? boolean +--rw max-aggregation-time? decimal64 +--rw window-size? uint16 +--rw send-immediately? boolean +--rw lost-packet-timer-interval? decimal64 augment /nsfikels:ipsec-ikeless/nsfikels:sad/nsfikels:sad-entry: +--ro traffic-flow-security +--ro congestion-control? boolean +--ro packet-size | +--ro use-path-mtu-discovery? boolean | +--ro outer-packet-size? uint16 +--ro (tunnel-rate)? | +--:(l2-fixed-rate) | | +--ro l2-fixed-rate? yang:gauge64 | +--:(l3-fixed-rate) | +--ro l3-fixed-rate? yang:gauge64 +--ro dont-fragment? boolean +--ro max-aggregation-time? decimal64 +--ro window-size? uint16 +--ro send-immediately? boolean +--ro lost-packet-timer-interval? decimal64 augment /nsfike:ipsec-ike/nsfike:conn-entry/nsfike:child-sa-info: +--ro ipsec-stats {ipsec-stats}? | +--ro tx-pkts? yang:counter64 | +--ro tx-octets? yang:counter64 | +--ro tx-drop-pkts? yang:counter64 | +--ro rx-pkts? yang:counter64 | +--ro rx-octets? yang:counter64 | +--ro rx-drop-pkts? yang:counter64 +--ro iptfs-inner-pkt-stats {iptfs-stats}? | +--ro tx-pkts? yang:counter64 | +--ro tx-octets? yang:counter64 | +--ro rx-pkts? yang:counter64 | +--ro rx-octets? yang:counter64 | +--ro rx-incomplete-pkts? yang:counter64 +--ro iptfs-outer-pkt-stats {iptfs-stats}? +--ro tx-all-pad-pkts? yang:counter64 +--ro tx-all-pad-octets? yang:counter64 +--ro tx-extra-pad-pkts? yang:counter64 +--ro tx-extra-pad-octets? yang:counter64 +--ro rx-all-pad-pkts? yang:counter64 +--ro rx-all-pad-octets? yang:counter64 +--ro rx-extra-pad-pkts? yang:counter64 +--ro rx-extra-pad-octets? yang:counter64 +--ro rx-errored-pkts? yang:counter64 +--ro rx-missed-pkts? yang:counter64 augment /nsfikels:ipsec-ikeless/nsfikels:sad/nsfikels:sad-entry: Fedyk & Hopps Expires 26 March 2023 [Page 6] Internet-Draft A YANG Data Model for IP-TFS September 2022 +--ro ipsec-stats {ipsec-stats}? | +--ro tx-pkts? yang:counter64 | +--ro tx-octets? yang:counter64 | +--ro tx-drop-pkts? yang:counter64 | +--ro rx-pkts? yang:counter64 | +--ro rx-octets? yang:counter64 | +--ro rx-drop-pkts? yang:counter64 +--ro iptfs-inner-pkt-stats {iptfs-stats}? | +--ro tx-pkts? yang:counter64 | +--ro tx-octets? yang:counter64 | +--ro rx-pkts? yang:counter64 | +--ro rx-octets? yang:counter64 | +--ro rx-incomplete-pkts? yang:counter64 +--ro iptfs-outer-pkt-stats {iptfs-stats}? +--ro tx-all-pad-pkts? yang:counter64 +--ro tx-all-pad-octets? yang:counter64 +--ro tx-extra-pad-pkts? yang:counter64 +--ro tx-extra-pad-octets? yang:counter64 +--ro rx-all-pad-pkts? yang:counter64 +--ro rx-all-pad-octets? yang:counter64 +--ro rx-extra-pad-pkts? yang:counter64 +--ro rx-extra-pad-octets? yang:counter64 +--ro rx-errored-pkts? yang:counter64 +--ro rx-missed-pkts? yang:counter64 3.2. YANG Module The following is the YANG module for managing the IP-TFS extensions. The model contains references to [I-D.ietf-ipsecme-iptfs] and [RFC5348]. file "ietf-ipsec-iptfs@2022-09-22.yang" module ietf-ipsec-iptfs { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs"; prefix iptfs; import ietf-i2nsf-ike { prefix nsfike; reference "RFC 9061 A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN) Section 5.2"; } import ietf-i2nsf-ikeless { prefix nsfikels; reference "RFC 9061 A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN) Section 5.3"; Fedyk & Hopps Expires 26 March 2023 [Page 7] Internet-Draft A YANG Data Model for IP-TFS September 2022 } import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types"; } organization "IETF IPSECME Working Group (IPSECME)"; contact "WG Web: WG List: Author: Don Fedyk Author: Christian Hopps "; // RFC Ed.: replace XXXX with actual RFC number and // remove this note. description "This module defines the configuration and operational state for managing the IP Traffic Flow Security functionality [RFC XXXX]. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and remove // this note // replace '2016-03-20' with the module publication date // the format is (2022-09-22) revision 2022-09-22 { description "Initial Revision"; Fedyk & Hopps Expires 26 March 2023 [Page 8] Internet-Draft A YANG Data Model for IP-TFS September 2022 reference "RFC XXXX: IP Traffic Flow Security YANG Module"; } feature ipsec-stats { description "This feature indicates the device supports per SA IPsec statistics"; } feature iptfs-stats { description "This feature indicates the device supports per SA IP Traffic Flow Security statistics"; } /*--------------------*/ /* groupings */ /*--------------------*/ grouping ipsec-tx-stat-grouping { description "IPsec outbound statistics"; leaf tx-pkts { type yang:counter64; config false; description "Outbound Packet count"; } leaf tx-octets { type yang:counter64; config false; description "Outbound Packet bytes"; } leaf tx-drop-pkts { type yang:counter64; config false; description "Outbound dropped packets count"; } } grouping ipsec-rx-stat-grouping { description "IPsec inbound statistics"; leaf rx-pkts { type yang:counter64; Fedyk & Hopps Expires 26 March 2023 [Page 9] Internet-Draft A YANG Data Model for IP-TFS September 2022 config false; description "Inbound Packet count"; } leaf rx-octets { type yang:counter64; config false; description "Inbound Packet bytes"; } leaf rx-drop-pkts { type yang:counter64; config false; description "Inbound dropped packets count"; } } grouping iptfs-inner-tx-stat-grouping { description "IP-TFS outbound inner packet statistics"; leaf tx-pkts { type yang:counter64; config false; description "Total number of IP-TFS inner packets sent. This count is whole packets only. A fragmented packet counts as one packet"; reference "draft-ietf-ipsecme-iptfs"; } leaf tx-octets { type yang:counter64; config false; description "Total number of IP-TFS inner octets sent. This is inner packet octets only. Does not count padding."; reference "draft-ietf-ipsecme-iptfs"; } } grouping iptfs-outer-tx-stat-grouping { description "IP-TFS outbound inner packet statistics"; leaf tx-all-pad-pkts { type yang:counter64; config false; Fedyk & Hopps Expires 26 March 2023 [Page 10] Internet-Draft A YANG Data Model for IP-TFS September 2022 description "Total number of transmitted IP-TFS packets that were all padding with no inner packet data."; reference "draft-ietf-ipsecme-iptfs section 2.2.3"; } leaf tx-all-pad-octets { type yang:counter64; config false; description "Total number transmitted octets of padding added to IP-TFS packets with no inner packet data."; reference "draft-ietf-ipsecme-iptfs section 2.2.3"; } leaf tx-extra-pad-pkts { type yang:counter64; config false; description "Total number of transmitted outer IP-TFS packets that included some padding."; reference "draft-ietf-ipsecme-iptfs section 2.2.3.1"; } leaf tx-extra-pad-octets { type yang:counter64; config false; description "Total number of transmitted octets of padding added to outer IP-TFS packets with data."; reference "draft-ietf-ipsecme-iptfs section 2.2.3.1"; } } grouping iptfs-inner-rx-stat-grouping { description "IP-TFS inner packet inbound statistics"; leaf rx-pkts { type yang:counter64; config false; description "Total number of IP-TFS inner packets received."; reference "draft-ietf-ipsecme-iptfs section 2.2"; } leaf rx-octets { type yang:counter64; Fedyk & Hopps Expires 26 March 2023 [Page 11] Internet-Draft A YANG Data Model for IP-TFS September 2022 config false; description "Total number of IP-TFS inner octets received. Does not include padding or overhead"; reference "draft-ietf-ipsecme-iptfs section 2.2"; } leaf rx-incomplete-pkts { type yang:counter64; config false; description "Total number of IP-TFS inner packets that were incomplete. Usually this is due to fragments not received. Also, this may be due to misordering or errors in received outer packets."; reference "draft-ietf-ipsecme-iptfs"; } } grouping iptfs-outer-rx-stat-grouping { description "IP-TFS outer packet inbound statistics"; leaf rx-all-pad-pkts { type yang:counter64; config false; description "Total number of received IP-TFS packets that were all padding with no inner packet data."; reference "draft-ietf-ipsecme-iptfs section 2.2.3"; } leaf rx-all-pad-octets { type yang:counter64; config false; description "Total number received octets of padding added to IP-TFS packets with no inner packet data."; reference "draft-ietf-ipsecme-iptfs section 2.2.3"; } leaf rx-extra-pad-pkts { type yang:counter64; config false; description "Total number of received outer IP-TFS packets that included some padding."; reference Fedyk & Hopps Expires 26 March 2023 [Page 12] Internet-Draft A YANG Data Model for IP-TFS September 2022 "draft-ietf-ipsecme-iptfs section 2.2.3.1"; } leaf rx-extra-pad-octets { type yang:counter64; config false; description "Total number of received octets of padding added to outer IP-TFS packets with data."; reference "draft-ietf-ipsecme-iptfs section 2.2.3.1"; } leaf rx-errored-pkts { type yang:counter64; config false; description "Total number of IP-TFS outer packets dropped due to errors."; reference "draft-ietf-ipsecme-iptfs"; } leaf rx-missed-pkts { type yang:counter64; config false; description "Total number of IP-TFS outer packets missing indicated by missing sequence number."; reference "draft-ietf-ipsecme-iptfs"; } } grouping iptfs-config { description "This is the grouping for iptfs configuration"; container traffic-flow-security { description "Configure the IPSec TFS in Security Association Database (SAD)"; leaf congestion-control { type boolean; default "true"; description "When set to true, the default, this enables the congestion control on-the-wire exchange of data that is required by congestion control algorithms as defined by RFC 5348. When set to false, IP-TFS sends fixed-sized packets over an IP-TFS tunnel at a constant rate."; reference Fedyk & Hopps Expires 26 March 2023 [Page 13] Internet-Draft A YANG Data Model for IP-TFS September 2022 "draft-ietf-ipsecme-iptfs section 2.5.2, RFC 5348"; } container packet-size { description "Packet size is either auto-discovered or manually configured."; leaf use-path-mtu-discovery { type boolean; default "true"; description "Utilize path mtu discovery to determine maximum IP-TFS packet size. If the packet size is explicitly configured, then it will only be adjusted downward if use-path-mtu-discovery is set."; reference "draft-ietf-ipsecme-iptfs section 4.2"; } leaf outer-packet-size { type uint16; units bytes; description "On transmission, the size of the outer encapsulating tunnel packet (i.e., the IP packet containing the ESP payload)."; reference "draft-ietf-ipsecme-iptfs section 4.2"; } } choice tunnel-rate { description "TFS bit rate may be specified at layer 2 wire rate or layer 3 packet rate"; leaf l2-fixed-rate { type yang:gauge64; units "bits/second"; description "On transmission, target bandwidth/bit rate in bits/second for iptfs tunnel. This fixed rate is the nominal timing for the fixed size packet. If congestion control is enabled the rate may be adjusted down (or up if unset)."; reference "draft-ietf-ipsecme-iptfs section 4.1"; } leaf l3-fixed-rate { type yang:gauge64; units "bits/second"; description Fedyk & Hopps Expires 26 March 2023 [Page 14] Internet-Draft A YANG Data Model for IP-TFS September 2022 "On transmission, target bandwidth/bit rate in bits/second for iptfs tunnel. This fixed rate is the nominal timing for the fixed size packet. If congestion control is enabled the rate may be adjusted down (or up if unset)."; reference "draft-ietf-ipsecme-iptfs section 4.1"; } } leaf dont-fragment { type boolean; default "false"; description "On transmission, disable packet fragmentation across consecutive iptfs tunnel packets; inner packets larger than what can be transmitted in outer packets will be dropped."; reference "draft-ietf-ipsecme-iptfs section 2.2.4 and 6.1.4"; } leaf max-aggregation-time { type decimal64 { fraction-digits 6; } units "milliseconds"; description "On transmission, maximum aggregation time is the maximum length of time a received inner packet can be held prior to transmission in the iptfs tunnel. Inner packets that would be held longer than this time, based on the current tunnel configuration will be dropped rather than be queued for transmission. Maximum aggregation time is configurable in milliseconds or fractional milliseconds down to 1 nanosecond."; } leaf window-size { type uint16 { range "0..65535"; } description "On reception, the maximum number of out-of-order packets that will be reordered by an iptfs receiver while performing the reordering operation. The value 0 disables any reordering."; reference "draft-ietf-ipsecme-iptfs section 2.2.3"; } leaf send-immediately { Fedyk & Hopps Expires 26 March 2023 [Page 15] Internet-Draft A YANG Data Model for IP-TFS September 2022 type boolean; default "false"; description "On reception, send inner packets as soon as possible, do not wait for lost or misordered outer packets. Selecting this option reduces the inner (user) packet delay but can amplify out-of-order delivery of the inner packet stream in the presence of packet aggregation and any reordering."; reference "draft-ietf-ipsecme-iptfs section 2.5"; } leaf lost-packet-timer-interval { type decimal64 { fraction-digits 6; } units "milliseconds"; description "On reception, this interval defines the length of time an iptfs receiver will wait for a missing packet before considering it lost. If not using send-immediately, then each lost packet will delay inner (user) packets until this timer expires. Setting this value too low can impact reordering and reassembly. The value is configurable in milliseconds or fractional milliseconds down to 1 nanosecond."; reference "draft-ietf-ipsecme-iptfs section 2.2.3"; } } } /* * IP-TFS ike configuration */ augment "/nsfike:ipsec-ike/nsfike:conn-entry/nsfike:spd/" + "nsfike:spd-entry/" + "nsfike:ipsec-policy-config/" + "nsfike:processing-info/" + "nsfike:ipsec-sa-cfg" { description "IP-TFS configuration for this policy."; uses iptfs-config; } augment "/nsfike:ipsec-ike/nsfike:conn-entry/" + "nsfike:child-sa-info" { Fedyk & Hopps Expires 26 March 2023 [Page 16] Internet-Draft A YANG Data Model for IP-TFS September 2022 description "IP-TFS configured on this SA."; uses iptfs-config { refine "traffic-flow-security" { config false; } } } /* * IP-TFS ikeless configuration */ augment "/nsfikels:ipsec-ikeless/nsfikels:spd/" + "nsfikels:spd-entry/" + "nsfikels:ipsec-policy-config/" + "nsfikels:processing-info/" + "nsfikels:ipsec-sa-cfg" { description "IP-TFS configuration for this policy."; uses iptfs-config; } augment "/nsfikels:ipsec-ikeless/nsfikels:sad/" + "nsfikels:sad-entry" { description "IP-TFS configured on this SA."; uses iptfs-config { refine "traffic-flow-security" { config false; } } } /* * packet counters */ augment "/nsfike:ipsec-ike/nsfike:conn-entry/" + "nsfike:child-sa-info" { description "Per SA Counters"; container ipsec-stats { if-feature "ipsec-stats"; config false; description "IPsec per SA packet counters. tx = outbound, rx = inbound"; Fedyk & Hopps Expires 26 March 2023 [Page 17] Internet-Draft A YANG Data Model for IP-TFS September 2022 uses ipsec-tx-stat-grouping; uses ipsec-rx-stat-grouping; } container iptfs-inner-pkt-stats { if-feature "iptfs-stats"; config false; description "IPTFS per SA inner packet counters. tx = outbound, rx = inbound"; uses iptfs-inner-tx-stat-grouping; uses iptfs-inner-rx-stat-grouping; } container iptfs-outer-pkt-stats { if-feature "iptfs-stats"; config false; description "IPTFS per SA outer packets counters. tx = outbound, rx = inbound"; uses iptfs-outer-tx-stat-grouping; uses iptfs-outer-rx-stat-grouping; } } /* * packet counters */ augment "/nsfikels:ipsec-ikeless/nsfikels:sad/" + "nsfikels:sad-entry" { description "Per SA Counters"; container ipsec-stats { if-feature "ipsec-stats"; config false; description "IPsec per SA packet counters. tx = outbound, rx = inbound"; uses ipsec-tx-stat-grouping; uses ipsec-rx-stat-grouping; } container iptfs-inner-pkt-stats { if-feature "iptfs-stats"; config false; description "IPTFS per SA inner packet counters. tx = outbound, rx = inbound"; uses iptfs-inner-tx-stat-grouping; uses iptfs-inner-rx-stat-grouping; Fedyk & Hopps Expires 26 March 2023 [Page 18] Internet-Draft A YANG Data Model for IP-TFS September 2022 } container iptfs-outer-pkt-stats { if-feature "iptfs-stats"; config false; description "IPTFS per SA outer packets counters. tx = outbound, rx = inbound"; uses iptfs-outer-tx-stat-grouping; uses iptfs-outer-rx-stat-grouping; } } } 4. IANA Considerations 4.1. Updates to the IETF XML Registry This document registers a URI in the "IETF XML Registry" [RFC3688]. Following the format in [RFC3688], the following registration has been made: URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. 4.2. Updates to the YANG Module Names Registry This document registers one YANG module in the "YANG Module Names" registry [RFC6020]. Following the format in [RFC6020], the following registration has been made: name: ietf-ipsec-iptfs namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-iptfs prefix: iptfs Fedyk & Hopps Expires 26 March 2023 [Page 19] Internet-Draft A YANG Data Model for IP-TFS September 2022 reference: RFC XXXX (RFC Ed.: replace XXXX with actual RFC number and remove this note.) 5. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. Certain data nodes defined in this YANG module are writable/creatable/deletable. These changes can enable, disable and modify the behavior of IP traffic flow security, for the implications regarding these types of changes consult the [I-D.ietf-ipsecme-iptfs] which defines the functionality. The relevant sub-trees or nodes are: ../traffic-flow-security: Enabling IP traffic flow security is controlled by setting the entries under traffic-flow-security in IKE or IKE-less models. IP traffic flow security is set either to be congestion sensitive or a fixed rate by setting parameters in this sub-tree. Certain readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. While IP-TFS hides the traffic flows through the network, IP-TFS YANG statistics could reveal some information about traffic flows. Therefore, access to IP-TFS YANG statistics also needs to be protected from third party observation. These IP-TFS YANG statistics can be found at: ../iptfs-inner-pkt-stats and ../iptfs-outer-pkt-stats: Access to IP traffic flow security statistics can provide information that IP traffic flow security obscures such as the true activity of the flows using IP traffic flow security. Fedyk & Hopps Expires 26 March 2023 [Page 20] Internet-Draft A YANG Data Model for IP-TFS September 2022 6. Acknowledgements The authors would like to thank Eric Kinzie, Juergen Schoenwaelder, Lou Berger and Tero Kivinen for their feedback and review on the YANG model. 7. References 7.1. Normative References [I-D.ietf-ipsecme-iptfs] Hopps, C., "IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security", Work in Progress, Internet-Draft, draft-ietf-ipsecme-iptfs-19, 8 November 2021, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC9061] Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- Garcia, "A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)", RFC 9061, DOI 10.17487/RFC9061, July 2021, . 7.2. Informative References Fedyk & Hopps Expires 26 March 2023 [Page 21] Internet-Draft A YANG Data Model for IP-TFS September 2022 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Appendix A. Examples The following examples show configuration and operational data for the IKE-less and IKE cases using XML and JSON. Also, the operational statistics for the IKE-less case is illustrated. A.1. Example XML Configuration This example illustrates configuration for IP-TFS in the IKE-less case. Note that since this augments the IPsec IKE-less schema only minimal a IKE-less configuration to satisfy the schema has been populated. Fedyk & Hopps Expires 26 March 2023 [Page 22] Internet-Draft A YANG Data Model for IP-TFS September 2022 protect-policy-1 outbound 192.0.2.0/16 198.51.100.0/16 protect true true 1000000000 0.1 5 false 0.2 Figure 1: Example IP-TFS XML configuration A.2. Example XML Operational Data This example illustrates operational data for IP-TFS in the IKE-less case. Note that since this augments the IPsec IKE-less schema only minimal IKE-less configuration to satisfy the schema has been populated. Fedyk & Hopps Expires 26 March 2023 [Page 23] Internet-Draft A YANG Data Model for IP-TFS September 2022 sad-1 1 2001:db8:1::/48 2001:db8:2::/48 true true 1000000000 0.100 0 true 0.200 Figure 2: Example IP-TFS XML Operational data A.3. Example JSON Configuration This example illustrates config data for IP-TFS in the IKE case. Note that since this augments the IPsec IKE schema only minimal ike configuration to satisfy the schema has been populated. { "ietf-i2nsf-ike:ipsec-ike": { "ietf-i2nsf-ike:conn-entry": [ { "name": "my-peer-connection", "ike-sa-encr-alg": [ { "id": 1, "algorithm-type": 12, "key-length": 128 Fedyk & Hopps Expires 26 March 2023 [Page 24] Internet-Draft A YANG Data Model for IP-TFS September 2022 } ], "local": { "local-pad-entry-name": "local-1" }, "remote": { "remote-pad-entry-name": "remote-1" }, "ietf-i2nsf-ike:spd": { "spd-entry": [ { "name": "protect-policy-1", "ipsec-policy-config": { "traffic-selector": { "local-prefix": "192.0.2.0/16", "remote-prefix": "198.51.100.0/16" }, "processing-info": { "action": "protect", "ipsec-sa-cfg": { "ietf-ipsec-iptfs:traffic-flow-security": { "congestion-control": true, "l2-fixed-rate": "1000000000", "packet-size": { "use-path-mtu-discovery": true }, "max-aggregation-time": "0.1", "window-size": 1, "send-immediately": false, "lost-packet-timer-interval": "0.2" } } } } } ] } } ] } } Figure 3: Example IP-TFS JSON configuration Fedyk & Hopps Expires 26 March 2023 [Page 25] Internet-Draft A YANG Data Model for IP-TFS September 2022 A.4. Example JSON Operational Data This example illustrates operational data for IP-TFS in the IKE case. Note that since this augments the IPsec IKE tree only minimal IKE configuration to satisfy the schema has been populated. { "ietf-i2nsf-ike:ipsec-ike": { "ietf-i2nsf-ike:conn-entry": [ { "name": "my-peer-connection", "ike-sa-encr-alg": [ { "id": 1, "algorithm-type": 12, "key-length": 128 } ], "local": { "local-pad-entry-name": "local-1" }, "remote": { "remote-pad-entry-name": "remote-1" }, "ietf-i2nsf-ike:child-sa-info": { "ietf-ipsec-iptfs:traffic-flow-security": { "congestion-control": true, "l2-fixed-rate": "1000000000", "packet-size": { "use-path-mtu-discovery": true }, "max-aggregation-time": "0.1", "window-size": 5, "send-immediately": false, "lost-packet-timer-interval": "0.2" } } } ] } } Figure 4: Example IP-TFS JSON Operational data Fedyk & Hopps Expires 26 March 2023 [Page 26] Internet-Draft A YANG Data Model for IP-TFS September 2022 A.5. Example JSON Operational Statistics This example shows the JSON formatted statistics for IP-TFS. Note a unidirectional IP-TFS transmit side is illustrated, with arbitrary numbers for transmit. { "ietf-i2nsf-ikeless:ipsec-ikeless": { "sad": { "sad-entry": [ { "name": "sad-1", "ipsec-sa-config": { "spi": 1, "traffic-selector": { "local-prefix": "192.0.2.1/16", "remote-prefix": "198.51.100.0/16" } }, "ietf-ipsec-iptfs:traffic-flow-security": { "window-size": 5, "send-immediately": false, "lost-packet-timer-interval": "0.2" }, "ietf-ipsec-iptfs:ipsec-stats": { "tx-pkts": "300", "tx-octets": "80000", "tx-drop-pkts": "2", "rx-pkts": "0", "rx-octets": "0", "rx-drop-pkts": "0" }, "ietf-ipsec-iptfs:iptfs-inner-pkt-stats": { "tx-pkts": "250", "tx-octets": "75000", "rx-pkts": "0", "rx-octets": "0", "rx-incomplete-pkts": "0" }, "ietf-ipsec-iptfs:iptfs-outer-pkt-stats": { "tx-all-pad-pkts": "40", "tx-all-pad-octets": "40000", "tx-extra-pad-pkts": "200", "tx-extra-pad-octets": "30000", "rx-all-pad-pkts": "0", "rx-all-pad-octets": "0", "rx-extra-pad-pkts": "0", "rx-extra-pad-octets": "0", Fedyk & Hopps Expires 26 March 2023 [Page 27] Internet-Draft A YANG Data Model for IP-TFS September 2022 "rx-errored-pkts": "0", "rx-missed-pkts": "0" }, "ipsec-sa-state": { "sa-lifetime-current": { "time": 80000, "bytes": "400606", "packets": 1000, "idle": 5 } } } ] } } } Figure 5: Example IP-TFS JSON Statistics Authors' Addresses Don Fedyk LabN Consulting, L.L.C. Email: dfedyk@labn.net Christian Hopps LabN Consulting, L.L.C. Email: chopps@chopps.org Fedyk & Hopps Expires 26 March 2023 [Page 28] ./draft-briscoe-docsis-q-protection-06.txt0000644000764400076440000022010714237433046020267 0ustar iustiniustin Network Working Group B. Briscoe, Ed. Internet-Draft Independent Intended status: Informational G. White Expires: 14 November 2022 CableLabs 13 May 2022 The DOCSIS® Queue Protection Algorithm to Preserve Low Latency draft-briscoe-docsis-q-protection-06 Abstract This informational document explains the specification of the queue protection algorithm used in DOCSIS technology since version 3.1. A shared low latency queue relies on the non-queue-building behaviour of every traffic flow using it. However, some flows might not take such care, either accidentally or maliciously. If a queue is about to exceed a threshold level of delay, the queue protection algorithm can rapidly detect the flows most likely to be responsible. It can then prevent harm to other traffic in the low latency queue by ejecting selected packets (or all packets) of these flows. The document is designed for four types of audience: a) congestion control designers who need to understand how to keep on the 'good' side of the algorithm; b) implementers of the algorithm who want to understand it in more depth; c) designers of algorithms with similar goals, perhaps for non-DOCSIS scenarios; and d) researchers interested in evaluating the algorithm. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 November 2022. Briscoe & White Expires 14 November 2022 [Page 1] Internet-Draft Queue Protection to Preserve Low Latency May 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Document Roadmap . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Copyright Material . . . . . . . . . . . . . . . . . . . 5 2. Approach - In Brief . . . . . . . . . . . . . . . . . . . . . 5 2.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. Policy Conditions . . . . . . . . . . . . . . . . . . 7 2.2.2. Policy Action . . . . . . . . . . . . . . . . . . . . 7 3. Necessary Flow Behaviour . . . . . . . . . . . . . . . . . . 7 4. Pseudocode Walk-Through . . . . . . . . . . . . . . . . . . . 8 4.1. Input Parameters, Constants and Variables . . . . . . . . 9 4.2. Queue Protection Data Path . . . . . . . . . . . . . . . 12 4.2.1. The qprotect() function . . . . . . . . . . . . . . . 13 4.2.2. The pick_bucket() function . . . . . . . . . . . . . 14 4.2.3. The fill_bucket() function . . . . . . . . . . . . . 17 4.2.4. The calcProbNative() function . . . . . . . . . . . . 17 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Rationale: Blame for Queuing, not for Rate in Itself . . 18 5.2. Rationale for Aging the Queuing Score . . . . . . . . . . 20 5.3. Rationale for Transformed Queuing Score . . . . . . . . . 21 5.4. Rationale for Policy Conditions . . . . . . . . . . . . . 22 5.5. Rationale for Reclassification as the Policy Action . . . 25 6. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations (to be removed by RFC Editor) . . . . . . 26 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9.1. Resource Exhaustion Attacks . . . . . . . . . . . . . . . 28 9.1.1. Exhausting Flow-State Storage . . . . . . . . . . . . 28 9.1.2. Exhausting Processing Resources . . . . . . . . . . . 29 10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 Briscoe & White Expires 14 November 2022 [Page 2] Internet-Draft Queue Protection to Preserve Low Latency May 2022 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction This informational document explains the specification of the queue protection (QProt) algorithm used in DOCSIS technology since version 3.1 [DOCSIS]. Although the algorithm is defined in annex P of [DOCSIS], it relies on cross-references to other parts of the set of specs. This document pulls all the strands together into one self-contained document. The core of the document is a similar pseudocode walk- through to that in the DOCSIS spec, but it also includes additional material: i) a brief overview; ii) a definition of how a data sender needs to behave to avoid triggering queue protection; and iii) a section giving the rationale for the design choices. Low queuing delay depends on hosts sending their data smoothly, either at low rate or responding to explicit congestion notifications (ECN [RFC8311], [I-D.ietf-tsvwg-ecn-l4s-id]). So low queuing latency is something hosts create themselves, not something the network gives them. This tends to ensure that self-interest alone does not drive flows to mis-mark their packets for the low latency queue. However, traffic from an application that does not behave in a non-queue- building way might erroneously be classified into a low latency queue, whether accidentally or maliciously. QProt protects other traffic in the low latency queue from the harm due to excess queuing that would otherwise be caused by such anomalous behaviour. In normal scenarios without misclassified traffic, QProt is not expected to intervene at all in the classification or forwarding of packets. An overview of how low latency support has been added to DOCSIS technology is given in [LLD]. In each direction of a DOCSIS link (upstream and downstream), there are two queues: one for Low Latency (LL) and one for Classic traffic, in an arrangement similar to the IETF's Coupled DualQ AQM [I-D.ietf-tsvwg-aqm-dualq-coupled]. The two queues enable a transition from 'Classic' to 'Scalable' congestion control so that low latency can become the norm for any application, including ones seeking both full throughput and low latency, not just low-rate applications that have been more traditionally associated with a low latency service. The Classic queue is only necessary for traffic such as traditional (Reno/Cubic) TCP that needs about a round trip of buffering to fully utilize the link, and therefore has no Briscoe & White Expires 14 November 2022 [Page 3] Internet-Draft Queue Protection to Preserve Low Latency May 2022 incentive to mismark itself as low latency. The QProt function is located at the ingress to the Low Latency queue. Therefore, in the upstream QProt is located on the cable modem (CM), and in the downstream it is located on the cable CMTS (CM Termination System). If an arriving packet triggers queue protection, the QProt algorithm ejects the packet from the Low Latency queue and reclassifies it into the Classic queue. If QProt is used in settings other than DOCSIS links, it would be a simple matter to detect queue-building flows by using slightly different conditions, and/or to trigger a different action as a consequence, as appropriate for the scenario, e.g., dropping instead of reclassifying packets or perhaps accumulating a second per-flow score to decide whether to redirect a whole flow rather than just certain packets. Such work is for future study and out of scope of the present document. The algorithm is based on a rigorous approach to quantifying how much each flow contributes to congestion, which is used in economics to allocate responsibility for the cost of one party's behaviour on others (the economic externality). Another important feature of the approach is that the metric used for the queuing score is based on the same variable that determines the level of ECN signalling seen by the sender [RFC8311], [I-D.ietf-tsvwg-ecn-l4s-id]. This makes the internal queuing score visible externally as ECN markings. This transparency is necessary to be able to objectively state (in Section 3) how a flow can keep on the 'good' side of the algorithm. 1.1. Document Roadmap The core of the document is the walk-through of the DOCSIS QProt algorithm's pseudocode in Section 4. Prior to that, Section 2 summarizes the approach used in the algorithm, then Section 3 considers QProt from the perspective of the end-system, by defining the behaviour that a flow needs to comply with to avoid the QProt algorithm ejecting its packets from the low latency queue. Section 5 gives deeper insight into the principles and rationale behind the algorithm. Then Section 6 explains the limitations of the approach, followed by the usual closing sections. Briscoe & White Expires 14 November 2022 [Page 4] Internet-Draft Queue Protection to Preserve Low Latency May 2022 1.2. Terminology The normative language for the DOCSIS QProt algorithm is in the DOCSIS specs [DOCSIS], [DOCSIS-CM-OSS], [DOCSIS-CCAP-OSS] not in this informational guide. If there is any inconsistency, the DOCSIS specs take precedence. The following terms and abbreviations are used: CM: Cable Modem CMTS: CM Termination System Congestion-rate: The transmission rate of bits or bytes contained within packets of a flow that have the CE codepoint set in the IP- ECN field [RFC3168] (including IP headers unless specified otherwise). Congestion-bit-rate and congestion-volume were introduced in [RFC7713] and [RFC6789]. DOCSIS: Data Over Cable System Interface Specification. "DOCSIS" is a registered trademark of Cable Television Laboratories, Inc. ("CableLabs"). Non-queue-building: A flow that tends not to build a queue Queue-building: A flow that builds a queue. If it is classified into the Low Latency queue, it is therefore a candidate for the queue protection algorithm to detect and sanction. ECN: Explicit Congestion Notification QProt: The Queue Protection function 1.3. Copyright Material Parts of this document are reproduced from [DOCSIS] with kind permission of the copyright holder, Cable Television Laboratories, Inc. ("CableLabs"). 2. Approach - In Brief The algorithm is divided into mechanism and policy. There is only a tiny amount of policy code, but policy might need to be changed in the future. So, where hardware implementation is being considered, it would be advisable to implement the policy aspects in firmware or software: Briscoe & White Expires 14 November 2022 [Page 5] Internet-Draft Queue Protection to Preserve Low Latency May 2022 * The mechanism aspects identify flows, maintain flow-state and accumulate per-flow queuing scores; * The policy aspects can be divided into conditions and actions: - The conditions are the logic that determines when action should be taken to avert the risk of queuing delay becoming excessive; - The actions determine how this risk is averted, e.g., by redirecting packets from a flow into another queue, or to reclassify a whole flow that seems to be misclassified. 2.1. Mechanism The algorithm maintains per-flow-state, where 'flow' usually means an end-to-end (layer-4) 5-tuple. The flow-state consists of a queuing score that decays over time. Indeed it is transformed into time units so that it represents the flow-state's own expiry time (explained in Section 5.3). A higher queuing score pushes out the expiry time further. Non-queue-building flows tend to release their flow-state rapidly --- it usually expires reasonably early in the gap between the packets of a normal flow. Then the memory can be recycled for packets from other flows that arrive in between. So only queue-building flows hold flow state persistently. The simplicity and effectiveness of the algorithm is due to the definition of the queuing score. The queueing score represents the share of blame for queuing that each flow bears. The scoring algorithm uses the same internal variable, probNative, that the AQM for the low latency queue uses to ECN-mark packets (the other two forms of marking, Classic and coupled, are driven by Classic traffic and therefore not relevant to protection of the LL queue). In this way, the queuing score accumulates the size of each arriving packet of a flow, but scaled by the value of probNative (in the range 0 to 1) at the instant the packet arrives. So a flow's score accumulates faster, the higher the degree of queuing and the faster that the flow's packets arrive when there is queuing. Section 5.1 explains further why this score represents blame for queuing. The algorithm as described so far would accumulate a number that would rise at the so-called congestion-rate of the flow (see Terminology in Section 1.2), i.e., the rate at which the flow is contributing to congestion, or the rate at which the AQM is forwarding bytes of the flow that are ECN marked. However, rather than growing continually, the queuing score is also reduced (or 'aged') at a constant rate. This is because it is unavoidable for Briscoe & White Expires 14 November 2022 [Page 6] Internet-Draft Queue Protection to Preserve Low Latency May 2022 capacity-seeking flows to induce a continuous low level of congestion as they track available capacity. Section 5.2 explains why this allowance can be set to the same constant for any scalable flow, whatever its bit rate. For implementation efficiency, the queuing score is transformed into time units so that it represents the expiry time of the flow state (as already discussed above). Then it does not need to be explicitly aged, because the natural passage of time implicitly 'ages' an expiry time. The transformation into time units simply involves dividing the queuing score of each packet by the constant aging rate (explained further in Section 5.3). 2.2. Policy 2.2.1. Policy Conditions The algorithm uses the queuing score to determine whether to eject each packet only at the time it first arrives. This limits the policies available. For instance, when queueing delay exceeds a threshold, it is not possible to eject a packet from the flow with the highest queuing scoring, because that would involve searching the queue for such a packet (if indeed one was still in the queue). Nonetheless, it is still possible to develop a policy that protects the low latency of the queue by making the queuing score threshold stricter the greater the excess of queuing delay relative to the threshold (explained in Section 5.4). 2.2.2. Policy Action In the DOCSIS QProt spec at the time of writing, when the policy conditions are met the action taken to protect the low latency queue is to reclassify a packet into the Classic queue (justified in Section 5.5). 3. Necessary Flow Behaviour The QProt algorithm described here can be used for responsive and/or unresponsive flows. * It is possible to objectively describe the least responsive way that a flow will need to respond to congestion signals in order to avoid triggering queue protection, no matter the link capacity and no matter how much other traffic there is. * It is not possible to describe how fast or smooth an unresponsive flow should be to avoid queue protection, because this depends on how much other traffic there is and the capacity of the link, Briscoe & White Expires 14 November 2022 [Page 7] Internet-Draft Queue Protection to Preserve Low Latency May 2022 which an application is unable to know. However, the more smoothly an unresponsive flow paces its packets and the lower its rate relative to typical broadband link capacities, the less likelihood that it will risk causing enough queueing to trigger queue protection. Responsive low latency flows can use an L4S ECN codepoint [I-D.ietf-tsvwg-ecn-l4s-id] to get classified into the low latency queue. A sender can arrange for flows that are smooth but do not respond to ECN marking to be classified into the low latency queue by using the Non-Queue-Building (NQB) Diffserv codepoint [I-D.ietf-tsvwg-nqb], which the DOCSIS specs support, or an operator can use various other local classifiers. As already explained in Section 2.1, the QProt algorithm is driven from the same variable that drives the ECN marking probability in the low latency queue (see the Immediate Active Queue Management Annex in [DOCSIS]). The algorithm that calculates this internal variable is run on the arrival of every packet, whether it is ECN-capable or not, so that it can be used by the QProt algorithm. But the variable is only used to ECN-mark packets that are ECN-capable. Not only does this dual use of the variable improve processing efficiency, but it also makes the basis of the QProt algorithm visible and transparent, at least for responsive ECN-capable flows. Then it is possible to state objectively that a flow can avoid triggering queue protection by keeping the bit rate of ECN marked packets (the congestion-rate) below AGING, which is a configured constant of the algorithm (default 2^19 B/s ~= 4 Mb/s). Note that it is in a congestion controller's own interest to keep its average congestion-rate well below this level (e.g., ~1 Mb/s), to ensure that it does not trigger queue protection during transient dynamics. If the QProt algorithm is used in other settings, it would still need to be based on the visible level of congestion signalling, in a similar way to the DOCSIS approach. Without transparency of the basis of the algorithm's decisions, end-systems would not be able to avoid triggering queue protection on an objective basis. 4. Pseudocode Walk-Through Briscoe & White Expires 14 November 2022 [Page 8] Internet-Draft Queue Protection to Preserve Low Latency May 2022 4.1. Input Parameters, Constants and Variables The operator input parameters that set the parameters in the first two blocks of pseudocode below are defined for cable modems (CMs) in [DOCSIS-CM-OSS] and for CMTSs in [DOCSIS-CCAP-OSS]. Then, further constants are either derived from the input parameters or hard-coded. Defaults and units are shown in square brackets. Defaults (or indeed any aspect of the algorithm) are subject to change, so the latest DOCSIS specs are the definitive references. Also any operator might set certain parameters to non-default values. // Input Parameters MAX_RATE; // Configured maximum sustained rate [b/s] QPROTECT_ON; // Queue Protection is enabled [Default: TRUE] CRITICALqL_us; // L queue threshold delay [us] Default: MAXTH_us CRITICALqLSCORE_us;// The threshold queuing score [Default: 4000us] LG_AGING; // The aging rate of the q'ing score [Default: 19] // as log base 2 of the congestion-rate [lg(B/s)] // Input Parameters for the calcProbNative() algorithm: MAXTH_us; // Max IAQM marking threshold [Default: 1000us] LG_RANGE; // Log base 2 of the range of ramp [lg(ns)] // Default: 2^19 = 524288 ns (roughly 525 us) Briscoe & White Expires 14 November 2022 [Page 9] Internet-Draft Queue Protection to Preserve Low Latency May 2022 // Constants, either derived from input parameters or hard-coded T_RES; // Resolution of t_exp [ns] // Convert units (approx) AGING = pow(2, (LG_AGING-30) ) * T_RES; // lg([B/s]) to [B/T_RES] CRITICALqL = CRITICALqL_us * 1000; // [us] to [ns] CRITICALqLSCORE = CRITICALqLSCORE_us * 1000/T_RES; // [us] to [T_RES] // Threshold for the q'ing score condition CRITICALqLPRODUCT = CRITICALqL * CRITICALqLSCORE; qLSCORE_MAX = 5E9 / T_RES; // Max queuing score = 5 s ATTEMPTS = 2; // Max attempts to pick a bucket (vendor-specific) BI_SIZE = 5; // Bit-width of index number for non-default buckets NBUCKETS = pow(2, BI_SIZE); // No. of non-default buckets MASK = NBUCKETS-1; // convenient constant, with BI_SIZE LSBs set // Queue Protection exit states EXIT_SUCCESS = 0; // Forward the packet EXIT_SANCTION = 1; // Redirect the packet MAX_PROB = 1; // For integer arithmetic, would use a large int // e.g., 2^31, to allow space for overflow MAXTH = MAXTH_us * 1000; // Max marking threshold [ns] MAX_FRAME_SIZE = 2000; // DOCSIS-wide constant [B] // Minimum marking threshold of 2 MTU for slow links [ns] FLOOR = 2 * 8 * MAX_FRAME_SIZE * 10^9 / MAX_RATE; RANGE = (1 << LG_RANGE); // Range of ramp [ns] MINTH = max ( MAXTH - RANGE, FLOOR); MAXTH = MINTH + RANGE; // Max marking threshold [ns] Throughout the pseudocode, most variables are integers. The only exceptions are floating point variables representing probabilities (MAX_PROB and probNative) and the AGING parameter. The actual DOCSIS QProt algorithm is defined using integer arithmetic, but in the floating point arithmetic used in this document, (0 <= probNative <= 1). Also, the pseudocode omits overflow checking and it would need to be made robust to non-default input parameters. The resolution for expressing time, T_RES, needs to be chosen to ensure that expiry times for buckets can represent times that are a fraction (e.g., 1/10) of the expected packet interarrival time for the system. The following definitions explain the purpose of important variables and functions. Briscoe & White Expires 14 November 2022 [Page 10] Internet-Draft Queue Protection to Preserve Low Latency May 2022 // Public variables: qdelay; // The current queuing delay of the LL queue [ns] probNative; // Native marking probability of LL queue within [0,1] // External variables packet; // The structure holding packet header fields packet.size; // The size of the current packet [B] packet.uflow; // The flow identifier of the current packet // (e.g., 5-tuple or 4-tuple if IPSec) // Irrelevant details of DOCSIS function to return qdelay are removed qdelayL(...) // Returns current delay of the low latency Q [ns] Pseudocode for how the algorithm categorizes packets by flow ID to populate the variable packet.uflow is not given in detail here. The application's flow ID is usually defined by a common 5-tuple (or 4-tuple) of: * source and destination IP addresses of the innermost IP header found; * the protocol (IPv4) or next header (IPv6) field in this IP header * either of: - source and destination port numbers, for TCP, UDP, UDP-Lite, SCTP, DCCP, etc. - Security Parameters Index (SPI) for IPSec Encapsulating Security Payload (ESP) [RFC4303]. The Microflow Classification section of the Queue Protection Annex of the DOCSIS spec. [DOCSIS] defines various strategies to find these headers by skipping extension headers or encapsulations. If they cannot be found, the spec. defines various less-specific 3-tuples that would be used. The DOCSIS spec. should be referred to for all these strategies, which will not be repeated here. The array of bucket structures defined below is used by all the Queue Protection functions: Briscoe & White Expires 14 November 2022 [Page 11] Internet-Draft Queue Protection to Preserve Low Latency May 2022 struct bucket { // The leaky bucket structure to hold per-flow state id; // identifier (e.g., 5-tuple) of flow using bucket t_exp; // expiry time in units of T_RES // (t_exp - now) = flow's transformed q'ing score }; struct bucket buckets[NBUCKETS+1]; 4.2. Queue Protection Data Path All the functions of Queue Protection operate on the data path, driven by packet arrivals. The following functions that maintain per-flow queuing scores and manage per-flow state are considered primarily as mechanism: pick_bucket(uflow_id); // Returns bucket identifier fill_bucket(bucket_id, pkt_size, probNative); // Returns queuing score calcProbNative(qdelay) // Returns probability of ECN-marking The following function is primarily concerned with policy: qprotect(packet, ...); // Returns exit status to either forward or redirect the packet ('...' suppresses distracting detail.) Future modifications to policy aspects are more likely than to mechanisms. Therefore, policy aspects would be less appropriate candidates for any hardware acceleration. The entry point to these functions is qprotect(), which is called from packet classification before each packet is enqueued into the appropriate queue, queue_id, as follows: Briscoe & White Expires 14 November 2022 [Page 12] Internet-Draft Queue Protection to Preserve Low Latency May 2022 classifier(packet) { // Determine which queue using ECN, DSCP and any local-use fields queue_id = classify(packet); // LQ & CQ are macros for valid queue IDs returned by classify() if (queue_id == LQ) { // if packet classified to Low Latency Service Flow if (QPROTECT_ON) { if (qprotect(packet, ...) == EXIT_SANCTION) { // redirect packet to Classic Service Flow queue_id = CQ; } } return queue_id; } 4.2.1. The qprotect() function On each packet arrival, qprotect() measures the current queue delay and derives the native marking probability from it. Then it uses pick_bucket to find the bucket already holding the flow's state, or to allocate a new bucket if the flow is new or its state has expired (the most likely case). Then the queuing score is updated by the fill_bucket() function. That completes the mechanism aspects. The comments against the subsequent policy conditions and actions should be self-explanatory at a superficial level. The deeper rationale for these conditions is given in Section 5.4. Briscoe & White Expires 14 November 2022 [Page 13] Internet-Draft Queue Protection to Preserve Low Latency May 2022 // Per packet queue protection qprotect(packet, ...) { bckt_id; // bucket index qLscore; // queuing score of pkt's flow in units of T_RES qdelay = qL.qdelay(...); probNative = calcProbNative(qdelay); bckt_id = pick_bucket(packet.uflow); qLscore = fill_bucket(buckets[bckt_id], packet.size, probNative); // Determine whether to sanction packet if ( ( ( qdelay > CRITICALqL ) // Test if qdelay over threshold... // ...and if flow's q'ing score scaled by qdelay/CRITICALqL // ...exceeds CRITICALqLSCORE && ( qdelay * qLscore > CRITICALqLPRODUCT ) ) // or qLSCORE_MAX reached || ( qLscore >= qLSCORE_MAX ) ) return EXIT_SANCTION; else return EXIT_SUCCESS; } 4.2.2. The pick_bucket() function The pick_bucket() function is optimized for flow-state that will normally have expired from packet to packet of the same flow. It is just one way of finding the bucket associated with the flow ID of each packet - it might be possible to develop more efficient alternatives. The algorithm is arranged so that the bucket holding any live (non- expired) flow-state associated with a packet will always be found before a new bucket is allocated. The constant ATTEMPTS, defined earlier, determines how many hashes are used to find a bucket for each flow (actually, only one hash is generated; then, by default, 5 bits of it at a time are used as the hash value, because by default there are 2^5 = 32 buckets). Briscoe & White Expires 14 November 2022 [Page 14] Internet-Draft Queue Protection to Preserve Low Latency May 2022 The algorithm stores the flow's own ID in its flow-state. So, when a packet of a flow arrives, the algorithm tries up to ATTEMPTS times to hash to a bucket, looking for the flow's own ID. If found, it uses that bucket, first resettings the expiry time to 'now' if it has expired. If it does not find the flow's ID, and the expiry time is still current, the algorithm can tell that another flow is using that bucket, and it continues to look for a bucket for the flow. Even if it finds another flow's bucket where the expiry time has passed, it doesn't immediately use it. It merely remembers it as the potential bucket to use. But first it runs through all the ATTEMPTS hashes to look for a bucket assigned to the flow ID. Then, if a live bucket is not already associated with the packet's flow, the algorithm should have already set aside an existing bucket with a score that has aged out. Given this bucket is no longer necessary to hold state for its previous flow, it can be recycled for use by the present packet's flow. If all else fails, there is one additional bucket (called the dregs) that can be used. If the dregs is still in live use by another flow, subsequent flows that cannot find a bucket of their own all share it, adding their score to the one in the dregs. A flow might get away with using the dregs on its own, but when there are many mis-marked flows, multiple flows are more likely to collide in the dregs, including innocent flows. The choice of number of buckets and number of hash attempts determines how likely it will be that this undesirable scenario will occur. Briscoe & White Expires 14 November 2022 [Page 15] Internet-Draft Queue Protection to Preserve Low Latency May 2022 // Pick the bucket associated with flow uflw pick_bucket(uflw) { now; // current time j; // loop counter h32; // holds hash of the packet's flow IDs h; // bucket index being checked hsav; // interim chosen bucket index h32 = hash32(uflw); // 32-bit hash of flow ID hsav = NBUCKETS; // Default bucket now = get_time_now(); // in units of T_RES // The for loop checks ATTEMPTS buckets for ownership by flow-ID // It also records the 1st bucket, if any, that could be recycled // because it's expired. // Must not recycle a bucket until all ownership checks completed for (j=0; j>= BI_SIZE; // Bit-shift hash for next attempt } // If reached here, no tested bucket was owned by the flow-ID if (hsav != NBUCKETS) { // If here, found an expired bucket within the above for loop buckets[hsav].t_exp = now; // Reset expired bucket } else { // If here, we're having to use the default bucket (the dregs) if (buckets[hsav].t_exp <= now) { // If dregs has expired... buckets[hsav].t_exp = now; // ...reset it } } buckets[hsav].id = uflw; // In either case, claim for recycling return hsav; } Briscoe & White Expires 14 November 2022 [Page 16] Internet-Draft Queue Protection to Preserve Low Latency May 2022 4.2.3. The fill_bucket() function The fill_bucket() function both accumulates and ages the queuing score over time, as outlined in Section 2.1. To make aging the score efficient, the increment of the queuing score is transformed into units of time by dividing by AGING, so that the result represents the new expiry time of the flow. Given that probNative is already used to select which packets to ECN- mark, it might be thought that the queuing score could just be incremented by the full size of each selected packet, instead of incrementing it by the product of every packet's size (pkt_sz) and probNative. However, the unpublished experience of one of the authors with other congestion policers has found that the score then increments far too jumpily, particularly when probNative is low. A deeper explanation of the queuing score is given in Section 5. fill_bucket(bckt_id, pkt_sz, probNative) { now; // current time now = get_time_now(); // in units of T_RES // Add packet's queuing score // For integer arithmetic, a bit-shift can replace the division qLscore = min(buckets[bckt_id].t_exp - now + probNative * pkt_sz / AGING, qLSCORE_MAX); buckets[bckt_id].t_exp = now + qLscore; return qLscore; } 4.2.4. The calcProbNative() function To derive this queuing score, the QProt algorithm uses the linear ramp function calcProbNative() to normalize instantaneous queuing delay into a probability in the range [0,1], which it assigns to probNative. Briscoe & White Expires 14 November 2022 [Page 17] Internet-Draft Queue Protection to Preserve Low Latency May 2022 calcProbNative(qdelay){ if ( qdelay >= MAXTH ) { probNative = MAX_PROB; } else if ( qdelay > MINTH ) { probNative = MAX_PROB * (qdelay - MINTH)/RANGE; // In practice, the * and the / would use a bit-shift } else { probNative = 0; } return probNative; } 5. Rationale 5.1. Rationale: Blame for Queuing, not for Rate in Itself Figure 1 shows the bit rates of two flows as stacked areas. It poses the question of which flow is more to blame for queuing delay; the unresponsive constant bit rate flow (c) that is consuming about 80% of the capacity, or the flow sending regular short unresponsive bursts (b)? The smoothness of c seems better for avoiding queuing, but its high rate does not. However, if flow c was not there, or ran slightly more slowly, b would not cause any queuing. ^ bit rate (stacked areas) | ,-. ,-. ,-. ,-. ,-. |--|b|----------|b|----------|b|----------|b|----------|b|---Capacity |__|_|__________|_|__________|_|__________|_|__________|_|_____ | | c | | | +----------------------------------------------------------------> time Figure 1: Which is More to Blame for Queuing Delay? To explain queuing scores, in the following it will initially be assumed that the QProt algorithm is accumulating queuing scores, but not taking any action as a result. To quantify the responsibility that each flow bears for queuing delay, the QProt algorithm accumulates the product of the rate of each flow and the level of congestion, both measured at the instant Briscoe & White Expires 14 November 2022 [Page 18] Internet-Draft Queue Protection to Preserve Low Latency May 2022 each packet arrives. The instantaneous flow rate is represented at each discrete event when a packet arrives by the packet's size, which accumulates faster the more packets arrive within each unit of time. The level of congestion is normalized to a dimensionless number between 0 and 1 (probNative). This fractional congestion level is used in preference to a direct dependence on queuing delay for two reasons: * to be able to ignore very low levels of queuing that contribute insignificantly to delay * to be able to erect a steep barrier against excessive queuing delay The unit of the resulting queue score is "congested-bytes" per second, which distinguishes it from just bytes per second. Then, during the periods between bursts (b), neither flow accumulates any queuing score - the high rate of c is benign. But, during each burst, if we say the rate of c and b are 80% and 45% of capacity, thus causing 25% overload, they each bear (80/125)% and (45/125)% of the responsibility for the queuing delay (64% and 36%). The algorithm does not explicitly calculate these percentages. They are just the outcome of the number of packets arriving from each flow during the burst. To summarize, the queuing score never sanctions rate solely on its own account. It only sanctions rate inasmuch as it causes queuing. ^ bit rate (stacked areas) , | ,-. |\ ,- |------Capacity-|b|----------,-.----------|b|----------|b\----- | __|_|_______ |b| /``\| _...-._-': | ,.-- | ,-. __/ \__|_|_ _/ |/ \|/ | |b| ___/ \___/ __ r | |_|/ v \__/ \_______ _/\____/ | _/ \__/ | +----------------------------------------------------------------> time Figure 2: Responsibility for Queuing: More Complex Scenario Figure 2 gives a more complex illustration of the way the queuing score assigns responsibility for queuing (limited to the precision that ASCII art can illustrate). The figure shows the bit rates of three flows represented as stacked areas labelled b, v and r. The unresponsive bursts (b) are the same as in the previous example, but Briscoe & White Expires 14 November 2022 [Page 19] Internet-Draft Queue Protection to Preserve Low Latency May 2022 a variable rate video (v) replaces flow c. It's rate varies as the complexity of the video scene varies. Also on a slower timescale, in response to the level of congestion, the video adapts its quality. However, on a short time-scale it appears to be unresponsive to small amounts of queuing. Also, part-way through, a low latency responsive flow (r) joins in, aiming to fill the balance of capacity left by the other two. The combination of the first burst and the low application-limited rate of the video causes neither flow to accumulate queuing score. In contrast, the second burst causes similar excessive overload (125%) to the example in Figure 1. Then, the video happens to reduce its rate (probably due to a less complex scene) so the third burst causes only a little congestion. Let us assume the resulting queue causes probNative to rise to just 1%, then the queuing score will only accumulate 1% of the size of each packet of flows v and b during this burst. The fourth burst happens to arrive just as the new responsive flow (r) has filled the available capacity, so it leads to very rapid growth of the queue. After a round trip the responsive flow rapidly backs off, and the adaptive video also backs off more rapidly than it would normally, because of the very high congestion level. The rapid response to congestion of flow r reduces the queuing score that all three flows accumulate, but they each still bear the cost in proportion to the product of the rates at which their packets arrive at the queue and the value of probNative when they do so. Thus, during the fifth burst, they all accumulate less score than the fourth, because the queuing delay is not as excessive. 5.2. Rationale for Aging the Queuing Score Even well-behaved flows will not always be able to respond fast enough to dynamic events. Also well-behaved flows, e.g., DCTCP [RFC8257], TCP Prague [I-D.briscoe-iccrg-prague-congestion-control], BBRv2 [BBRv2] or the L4S variant of SCReAM [SCReAM] for real-time media [RFC8298], can maintain a very shallow queue by continual careful probing for more while also continually subtracting a little from their rate (or congestion window) in response to low levels of ECN signalling. Therefore, the QProt algorithm needs to continually offer a degree of forgiveness to age out the queuing score as it accumulates. Scalable congestion controllers such as those above maintain their congestion window in inverse proportion to the congestion level, probNative. That leads to the important property that on average a scalable flow holds the product of its congestion window and the congestion level constant, no matter the capacity of the link or how Briscoe & White Expires 14 November 2022 [Page 20] Internet-Draft Queue Protection to Preserve Low Latency May 2022 many other flows it competes with. For instance, if the link capacity doubles, a scalable flow induces half the congestion probability. Or if three scalable flows compete for the capacity, each flow will reduce to one third of the capacity they would use on their own and increase the congestion level by 3x. This suggests that the QProt algorithm will not sanction a well- behaved scalable flow if it ages out the queuing score at a sufficient constant rate. The constant will need to be somewhat above the average of a well-behaved scalable flow to allow for normal dynamics. Relating QProt's aging constant to a scalable flow does not mean that a flow has to behave like a scalable flow. It can be less aggressive, but not more. For instance, a longer RTT flow can run at a lower congestion-rate than the aging rate, but it can also increase its aggressiveness to equal the rate of short RTT scalable flows [ScalingCC]. The constant aging of QProt also means that a long- running unresponsive flow will be prone to trigger QProt if it runs faster than a competing responsive scalable flow would. And, of course, if a flow causes excessive queuing in the short-term, its queuing score will still rise faster than the constant aging process will decrease it. Then QProt will still eject the flow's packets before they harm the low latency of the shared queue. 5.3. Rationale for Transformed Queuing Score The QProt algorithm holds a flow's queuing score state in a structure called a bucket, because of its similarity to a classic leaky bucket (except the contents of the bucket does not represent bytes). probNative * pkt_sz probNative * pkt_sz / AGING | | | V | | V | | : | ___ | : | |_____| ___ |_____| | | ___ | | |__ __| |__ __| | | V V AGING * Dt Dt Figure 3: Transformation of Queuing Score The accumulation and aging of the queuing score is shown on the left of Figure 3 in token bucket form. Dt is the difference between the times when the scores of the current and previous packets were processed. Briscoe & White Expires 14 November 2022 [Page 21] Internet-Draft Queue Protection to Preserve Low Latency May 2022 A transformed equivalent of this token bucket is shown on the right of Figure 3, dividing both the input and output by the constant AGING rate. The result is a bucket-depth that represents time and it drains at the rate that time passes. As a further optimization, the time the bucket was last updated is not stored with the flow-state. Instead, when the bucket is initialized the queuing score is added to the system time 'now' and the resulting expiry time is written into the bucket. Subsequently, if the bucket has not expired, the incremental queuing score is added to the time already held in the bucket. Then the queuing score always represents the expiry time of the flow-state itself. This means that the queuing score does not need to be aged explicitly because it ages itself implicitly. 5.4. Rationale for Policy Conditions Pseudocode for the QProt policy conditions is given in Section 4.1 within the second half of the qprotect() function. When each packet arrives, after finding its flow state and updating the queuing score of the packet's flow, the algorithm checks whether the shared queue delay exceeds a constant threshold CRITICALqL (e.g., 2 ms), as repeated below for convenience: if ( ( qdelay > CRITICALqL ) // Test if qdelay over threshold... // ...and if flow's q'ing score scaled by qdelay/CRITICALqL // ...exceeds CRITICALqLSCORE && ( qdelay * qLscore > CRITICALqLPRODUCT ) ) // Recall that CRITICALqLPRODUCT = CRITICALqL * CRITICALqLSCORE If the queue delay threshold is exceeded, the flow's queuing score is temporarily scaled up by the ratio of the current queue delay to the threshold queuing delay, CRITICALqL (the reason for the scaling is given next). If this scaled up score exceeds another constant threshold CRITICALqLSCORE, the packet is ejected. The actual last line of code above multiplies both sides of the second condition by CRITICALqL to avoid a costly division. This approach allows each packet to be assessed once, as it arrives. Once queue delay exceeds the threshold, it has two implications: * The current packet might be ejected even though there are packets already in the queue from flows with higher queuing scores. However, any flow that continues to contribute to the queue will have to send further packets, giving an opportunity to eject them as well, as they subsequently arrive. Briscoe & White Expires 14 November 2022 [Page 22] Internet-Draft Queue Protection to Preserve Low Latency May 2022 * The next packets to arrive might not be ejected, because they might belong to flows with low queuing scores. In this case, queue delay could continue to rise with no opportunity to eject a packet. This is why the queuing score is scaled up by the current queue delay. Then, the more the queue has grown without ejecting a packet, the more the algorithm 'raises the bar' to further packets. The above approach is preferred over the extra per-packet processing cost of searching the buckets for the flow with the highest queuing score and searching the queue for one of its packets to eject (if one is still in the queue). Note that by default CRITICALqL_us is set to the maximum threshold of the ramp marking algorithm, MAXTH_us. However, there is some debate as to whether setting it to the minimum threshold instead would improve QProt performance. This would roughly double the ratio of qdelay to CRITICALqL, which is compared against the CRITICALqLSCORE threshold. So the threshold would have to be roughly doubled accordingly. Figure 4 explains this approach graphically. On the horizontal axis it shows actual harm, meaning the queuing delay in the shared queue. On the vertical axis it shows the behaviour record of the flow associated with the currently arriving packet, represented in the algorithm by the flow's queuing score. The shaded region represents the combination of actual harm and behaviour record that will lead to the packet being ejected. Briscoe & White Expires 14 November 2022 [Page 23] Internet-Draft Queue Protection to Preserve Low Latency May 2022 Behaviour Record: Queueing Score of Arriving Packet's Flow ^ | + |/ / / / / / / / / / / / / / / / / / / | + N | / / / / / / / / / / / / / / / / / / / | + |/ / / / / / / / / / | + | / / / / E (Eject packet) / / / / / | + |/ / / / / / / / / / | + | / / / / / / / / / / / / / / / / / / / | + |/ / / / / / / / / / / / / / / / / / / | +| / / / / / / / / / / / / / / / / / / / | |+ / / / / / / / / / / / / / / / / / / | N | + / / / / / / / / / / / / / / / / / | (No actual | +/ / / / / / / / / / / / / / / | harm) | + / / / / / / / / / / / / | | P (Pass over) + ,/ / / / / / / / | | ^ + /./ /_/ +--------------+------------------------------------------> CRITICALqL Actual Harm: Shared Queue Delay Figure 4: Graphical Explanation of the Policy Conditions The regions labelled 'N' represent cases where the first condition is not met - no actual harm - queue delay is below the critical threshold, CRITICALqL. The region labelled 'E' represents cases where there is actual harm (queue delay exceeds CRITICALqL) and the queuing score associated with the arriving packet is high enough to be able to eject it with certainty. The region labelled 'P' represents cases where there is actual harm, but the queuing score of the arriving packet is insufficient to eject it, so it has to be Passed over. This adds to queuing delay, but the alternative would be to sanction an innocent flow. It can be seen that, as actual harm increases, the judgement of innocence becomes increasingly stringent; the behaviour record of the next packet's flow does not have to be as bad to eject it. Conditioning ejection on actual harm helps prevent VPN packets being ejected unnecessarily. VPNs consisting of multiple flows can tend to accumulate queuing score faster than it is aged out, because the aging rate is intended for a single flow. However, whether or not some traffic is in a VPN, the queue delay threshold (CRITICALqL) will be no more likely to be exceeded. So conditioning ejection on actual harm helps reduce the chance that VPN traffic will be ejected by the QProt function. Briscoe & White Expires 14 November 2022 [Page 24] Internet-Draft Queue Protection to Preserve Low Latency May 2022 5.5. Rationale for Reclassification as the Policy Action When the DOCSIS QProt algorithm deems that it is necessary to eject a packet to protect the Low Latency queue, it redirects the packet to the Classic queue. In the Low Latency DOCSIS architecture (as in Coupled DualQ AQMs generally), the Classic queue is expected to frequently have a larger backlog of packets, caused by classic congestion controllers interacting with a classic AQM (which has a latency target of 10ms) as well as other bursty traffic. Therefore, typically, an ejected packet will experience higher queuing delay than it would otherwise, and it could be re-ordered within its flow (assuming QProt does not eject all packets of an anomalous flow). The mild harm caused to the performance of the ejected packet's flow is deliberate. It gives senders a slight incentive to identify their packets correctly. If there were no such harm, there would be nothing to prevent all flows from identifying themselves as suitable for classification into the low latency queue, and just letting QProt sort the resulting aggregate into queue-building and non-queue-building flows. This might seem like a useful alternative to requiring senders to correctly identify their flows. However, handling of mis-classified flows is not without a cost. The more packets that have to be reclassified, the more often the delay of the low latency queue would exceed the threshold. Also more memory would be required to hold the extra flow state. When a packet is redirected into the Classic queue, an operator might want to alter the identifier(s) that originally caused it to be classified into the Low Latency queue, so that the packet will not be classified into another low latency queue further downstream. However, redirection of occasional packets can be due to unusually high transient load just at the specific bottleneck, not necessarily at any other bottleneck, and not necessarily due to bad flow behaviour. Therefore, Section 5.4.1.2 of [I-D.ietf-tsvwg-ecn-l4s-id] precludes a network node from altering the end-to-end ECN field to exclude traffic from L4S treatment. Instead a local-use identifier ought to be used (e.g., Diffserv Codepoint or VLAN tag), so that each operator can apply its own policy, without prejudging what other operators ought to do. Although not supported in the DOCSIS specs, QProt could be extended to recognize that large numbers of redirected packets belong to the same flow. This might be detected when the bucket expiry time t_exp exceeds a threshold. Depending on policy and implementation capabilities, QProt could then install a classifier to redirect a whole flow into the Classic queue, with an idle timeout to remove Briscoe & White Expires 14 November 2022 [Page 25] Internet-Draft Queue Protection to Preserve Low Latency May 2022 stale classifiers. In these 'persistent offender' cases, QProt might also overwrite each redirected packet's DSCP or clear its ECN field to Not-ECT, in order to protect other potential L4S queues downstream. The DOCSIS specs do not discuss sanctioning whole flows, so further discussion is beyond the scope of the present document. 6. Limitations The QProt algorithm groups packets with common layer-4 flow identifiers. It then uses this grouping to accumulate queuing scores and to sanction packets. This choice of identifier for grouping is pragmatic with no scientific basis. All the packets of a flow certainly pass between the same two endpoints. But some applications might initiate multiple flows between the same end-points, e.g., for media, control, data, etc. Others might use common flow identifiers for all these streams. Also, a user might group multiple application flows within the same encrypted VPN between the same layer-4 tunnel end-points. And even if there were a one-to-one mapping between flows and applications, there is no reason to believe that the rate at which congestion can be caused ought to be allocated on a per application flow basis. The use of a queuing score that excludes those aspects of flow rate that do not contribute to queuing (Section 5.1) goes some way to mitigating this limitation, because the algorithm does not judge responsibility for queuing delay primarily on the combined rate of a set of flows grouped under one flow ID. 7. IANA Considerations (to be removed by RFC Editor) This specification contains no IANA considerations. 8. Implementation Status +================+================================================+ | Implementation | DOCSIS models for ns-3 | | name: | | +================+================================================+ | Organization | CableLabs | +----------------+------------------------------------------------+ | Web page | https://apps.nsnam.org/app/docsis-ns3/ | +----------------+------------------------------------------------+ | Description | ns-3 simulation models developed and used in | | | support of the Low Latency DOCSIS development, | | | including models of Dual Queue Coupled AQM, | | | Queue Protection, and the DOCSIS MAC | Briscoe & White Expires 14 November 2022 [Page 26] Internet-Draft Queue Protection to Preserve Low Latency May 2022 +----------------+------------------------------------------------+ | Maturity | Simulation models that can also be used in | | | emulation mode in a testbed context | +----------------+------------------------------------------------+ | Coverage | Complete implementation of Annex P of DOCSIS | | | 3.1 | +----------------+------------------------------------------------+ | Version | DOCSIS 3.1, version I21; | | | https://www.cablelabs.com/specifications/CM- | | | SP-MULPIv3.1?v=I21 | +----------------+------------------------------------------------+ | Licence | GPLv2 | +----------------+------------------------------------------------+ | Contact | via web page | +----------------+------------------------------------------------+ | Last Impl'n | Mar 2022 | | update | | +----------------+------------------------------------------------+ | Information | 7 Mar 2022 | | valid at | | +----------------+------------------------------------------------+ Table 1 There are also a number of closed source implementations, including 2 cable modem implementations written by different chipset manufacturers, and one CMTS implementation by a third manufacturer. These, as well as the ns-3 implementation, have passed the full suite of compliance tests developed by CableLabs. 9. Security Considerations The whole of this document concerns traffic security. It considers the security question of how to identify and eject traffic that does not comply with the non-queue-building behaviour required to use a shared low latency queue, whether accidentally or maliciously. Section 8.2 of the L4S architecture [I-D.ietf-tsvwg-l4s-arch] introduces the problem of maintaining low latency by either self- restraint or enforcement, and places DOCSIS queue protection in context within a wider set of approaches to the problem. Briscoe & White Expires 14 November 2022 [Page 27] Internet-Draft Queue Protection to Preserve Low Latency May 2022 9.1. Resource Exhaustion Attacks The algorithm has been designed to fail gracefully in the face of traffic crafted to overrun the resources used for the algorithm's own processing and flow state. This means that non-queue-building flows will always be less likely to be sanctioned than queue-building flows. But an attack could be contrived to deplete resources in such a way that the proportion of innocent (non-queue-building) flows that are incorrectly sanctioned could increase. Incorrect sanctioning is intended not to be catastrophic; it results in more packets from well-behaved flows being redirected into the Classic queue; thus introducing more reordering into innocent flows. 9.1.1. Exhausting Flow-State Storage To exhaust the number of buckets, the most efficient attack is to send enough long-running attack flows to increase the chance that an arriving flow will not find an available bucket, and therefore have to share the 'dregs' bucket. For instance, if ATTEMPTS=2 and NBUCKETS=32, it requires about 94 attack flows, each using different port numbers, to increase the probability to 99% that an arriving flow will have to share the dregs, where it will share a high degree of redirection into the C queue with the remainder of the attack flows. For an attacker to keep buckets busy, it is more efficient to hold onto them by cycling regularly through a set of port numbers (94 in the above example), rather than to keep occupying and releasing buckets with single packet flows across a much larger number of ports. During such an attack, the coupled marking probability will have saturated at 100%. So, to hold a bucket, the rate of an attack flow needs to be no less than the AGING rate of each bucket; 4Mb/s by default. However, for an attack flow to be sure to hold on to its bucket, it would need to send somewhat faster. Thus an attack with 100 flows would need a total force of more than 100 * 4Mb/s = 400Mb/ s. This attack can be mitigated (but not prevented) by increasing the number of buckets. The required attack force scales linearly with the number of buckets, NBUCKETS. So, if NBUCKETS were doubled to 64, twice as many 4Mb/s flows would be needed to maintain the same impact on innocent flows. Briscoe & White Expires 14 November 2022 [Page 28] Internet-Draft Queue Protection to Preserve Low Latency May 2022 Probably the most effective mitigation would be to implement redirection of whole-flows once enough of the individual packets of a certain offending flow had been redirected. This would free up the buckets used to maintain the per-packet queuing score of persistent offenders. Whole-flow redirection is outside the scope of the current version of the QProt algorithm specified here, but it is briefly discussed at the end of Section 5.5. It might be considered that all the packets of persistently offending flows ought to be discarded rather than redirected. However, this is not recommended, because attack flows might be able to pervert whole- flow discard, turning it onto at least some innocent flows, thus amplifying an attack that causes reordering into total deletion of some innocent flows. 9.1.2. Exhausting Processing Resources The processing time needed to apply the QProt algorithm to each L packet is small and intended not to take all the time available between each of a run of fairly small packets. However, an attack could use minimum size packets launched from multiple input interfaces into a lower capacity output interface. Whether the QProt algorithm is vulnerable to processor exhaustion will depend on the specific implementation. Addition of a capability to redirect persistently offending flows from L to C would be the most effective way to reduce the per-packet processing cost of the QProt algorithm, when under attack. As already mentioned in Section 9.1.1, this would also be an effective way to mitigate flow-state exhaustion attacks. Further discussion of whole-flow redirection is outside the scope of the present document, but briefly discussed at the end of Section 5.5. 10. Comments Solicited Evaluation and assessment of the algorithm by researchers is solicited. Comments and questions are also encouraged and welcome. They can be addressed to the authors. 11. Acknowledgements Thanks to Tom Henderson, Magnus Westerlund, David Black, Adrian Farrel and Gorry Fairhurst for their reviews of this document. The design of the QProt algorithm and the settings of the parameters benefited from discussion and critique from the participants of the cable industry working group on Low Latency DOCSIS. CableLabs funded Bob Briscoe's initial work on this document. Briscoe & White Expires 14 November 2022 [Page 29] Internet-Draft Queue Protection to Preserve Low Latency May 2022 12. References 12.1. Normative References [DOCSIS] CableLabs, "MAC and Upper Layer Protocols Interface (MULPI) Specification, CM-SP-MULPIv3.1", Data-Over-Cable Service Interface Specifications DOCSIS® 3.1 Version I17 or later, 21 January 2019, . [DOCSIS-CCAP-OSS] CableLabs, "CCAP Operations Support System Interface Spec", Data-Over-Cable Service Interface Specifications DOCSIS® 3.1 Version I14 or later, 21 January 2019, . [DOCSIS-CM-OSS] CableLabs, "Cable Modem Operations Support System Interface Spec", Data-Over-Cable Service Interface Specifications DOCSIS® 3.1 Version I14 or later, 21 January 2019, . [I-D.ietf-tsvwg-ecn-l4s-id] Schepper, K. D. and B. Briscoe, "Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Delay (L4S)", Work in Progress, Internet-Draft, draft-ietf- tsvwg-ecn-l4s-id-25, 4 March 2022, . [I-D.ietf-tsvwg-nqb] White, G. and T. Fossati, "A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services", Work in Progress, Internet-Draft, draft-ietf-tsvwg-nqb-10, 4 March 2022, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, January 2018, . Briscoe & White Expires 14 November 2022 [Page 30] Internet-Draft Queue Protection to Preserve Low Latency May 2022 12.2. Informative References [BBRv2] Cardwell, N., "TCP BBR v2 Alpha/Preview Release", github repository; Linux congestion control module, . [I-D.briscoe-iccrg-prague-congestion-control] Schepper, K. D., Tilmans, O., and B. Briscoe, "Prague Congestion Control", Work in Progress, Internet-Draft, draft-briscoe-iccrg-prague-congestion-control-00, 9 March 2021, . [I-D.ietf-tsvwg-aqm-dualq-coupled] Schepper, K. D., Briscoe, B., and G. White, "DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S)", Work in Progress, Internet-Draft, draft-ietf- tsvwg-aqm-dualq-coupled-23, 4 May 2022, . [I-D.ietf-tsvwg-l4s-arch] Briscoe, B., Schepper, K. D., Bagnulo, M., and G. White, "Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture", Work in Progress, Internet-Draft, draft-ietf-tsvwg-l4s-arch-17, 4 March 2022, . [LLD] White, G., Sundaresan, K., and B. Briscoe, "Low Latency DOCSIS: Technology Overview", CableLabs White Paper , February 2019, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., "Congestion Exposure (ConEx) Concepts and Use Cases", RFC 6789, DOI 10.17487/RFC6789, December 2012, . [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements", RFC 7713, DOI 10.17487/RFC7713, December 2015, . Briscoe & White Expires 14 November 2022 [Page 31] Internet-Draft Queue Protection to Preserve Low Latency May 2022 [RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., and G. Judd, "Data Center TCP (DCTCP): TCP Congestion Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, October 2017, . [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December 2017, . [ScalingCC] Briscoe, B. and K. De Schepper, "Resolving Tensions between Congestion Control Scaling Requirements", Simula Technical Report TR-CS-2016-001 arXiv:1904.07605, July 2017, . [SCReAM] Johansson, I., "SCReAM", github repository; , . Authors' Addresses Bob Briscoe (editor) Independent United Kingdom Email: ietf@bobbriscoe.net URI: http://bobbriscoe.net/ Greg White CableLabs United States of America Email: G.White@CableLabs.com Briscoe & White Expires 14 November 2022 [Page 32] ./draft-ietf-payload-vp9-16.txt0000644000764400076440000015735614060424770016045 0ustar iustiniustin AVTCore Working Group J. Uberti Internet-Draft S. Holmer Intended status: Standards Track M. Flodman Expires: 12 December 2021 D. Hong Google J. Lennox 8x8 / Jitsi 10 June 2021 RTP Payload Format for VP9 Video draft-ietf-payload-vp9-16 Abstract This specification describes an RTP payload format for the VP9 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. It includes provisions for temporal and spatial scalability. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 December 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Uberti, et al. Expires 12 December 2021 [Page 1] Internet-Draft RTP Payload Format for VP9 June 2021 extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 3. Media Format Description . . . . . . . . . . . . . . . . . . 3 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 5 4.2. VP9 Payload Descriptor . . . . . . . . . . . . . . . . . 6 4.2.1. Scalability Structure (SS): . . . . . . . . . . . . . 11 4.3. Frame Fragmentation . . . . . . . . . . . . . . . . . . . 13 4.4. Scalable encoding considerations . . . . . . . . . . . . 13 4.5. Examples of VP9 RTP Stream . . . . . . . . . . . . . . . 13 4.5.1. Reference picture use for scalable structure . . . . 14 5. Feedback Messages and Header Extensions . . . . . . . . . . . 14 5.1. Reference Picture Selection Indication (RPSI) . . . . . . 15 5.2. Full Intra Request (FIR) . . . . . . . . . . . . . . . . 15 5.3. Layer Refresh Request (LRR) . . . . . . . . . . . . . . . 15 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 16 6.1. SDP Parameters . . . . . . . . . . . . . . . . . . . . . 18 6.1.1. Mapping of Media Subtype Parameters to SDP . . . . . 18 6.1.2. Offer/Answer Considerations . . . . . . . . . . . . . 19 7. Media Type Definition . . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Congestion Control . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction This specification describes an RTP [RFC3550] payload specification applicable to the transmission of video streams encoded using the VP9 video codec [VP9-BITSTREAM]. The format described in this document can be used both in peer-to-peer and video conferencing applications. The VP9 video codec was developed by Google, and is the successor to its earlier VP8 [RFC6386] codec. Above the compression improvements and other general enhancements above VP8, VP9 is also designed in a way that allows spatially-scalable video encoding. Uberti, et al. Expires 12 December 2021 [Page 2] Internet-Draft RTP Payload Format for VP9 June 2021 2. Conventions, Definitions and Acronyms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Media Format Description The VP9 codec can maintain up to eight reference frames, of which up to three can be referenced by any new frame. VP9 also allows a frame to use another frame of a different resolution as a reference frame. (Specifically, a frame may use any references whose width and height are between 1/16th that of the current frame and twice that of the current frame, inclusive.) This allows internal resolution changes without requiring the use of key frames. These features together enable an encoder to implement various forms of coarse-grained scalability, including temporal, spatial and quality scalability modes, as well as combinations of these, without the need for explicit scalable coding tools. Temporal layers define different frame rates of video; spatial and quality layers define different and possibly dependent representations of a single input frame. Spatial layers allow a frame to be encoded at different resolutions, whereas quality layers allow a frame to be encoded at the same resolution but at different qualities (and thus with different amounts of coding error). VP9 supports quality layers as spatial layers without any resolution changes; hereinafter, the term "spatial layer" is used to represent both spatial and quality layers. This payload format specification defines how such temporal and spatial scalability layers can be described and communicated. Temporal and spatial scalability layers are associated with non- negative integer IDs. The lowest layer of either type has an ID of 0, and is sometimes referred to as the "base" temporal or spatial layer. Layers are designed, and MUST be encoded, such that if any layer, and all higher layers, are removed from the bitstream along either the spatial or temporal dimension, the remaining bitstream is still correctly decodable. Uberti, et al. Expires 12 December 2021 [Page 3] Internet-Draft RTP Payload Format for VP9 June 2021 For terminology, this document uses the term "frame" to refer to a single encoded VP9 frame for a particular resolution/quality, and "picture" to refer to all the representations (frames) at a single instant in time. A picture thus consists of one or more frames, encoding different spatial layers. Within a picture, a frame with spatial layer ID equal to SID, where SID > 0, can depend on a frame of the same picture with a lower spatial layer ID. This "inter-layer" dependency can result in additional coding gain compared to the case where only traditional "inter-picture" dependency is used, where a frame depends on previously coded frame in time. For simplicity, this payload format assumes that, within a picture and if inter-layer dependency is used, a spatial layer SID frame can depend only on the immediately previous spatial layer SID-1 frame, when S > 0. Additionally, if inter- picture dependency is used, a spatial layer SID frame is assumed to only depend on a previously coded spatial layer SID frame. Given above simplifications for inter-layer and inter-picture dependencies, a flag (the D bit described below) is used to indicate whether a spatial layer SID frame depends on the spatial layer SID-1 frame. Given the D bit, a receiver only needs to additionally know the inter-picture dependency structure for a given spatial layer frame in order to determine its decodability. Two modes of describing the inter-picture dependency structure are possible: "flexible mode" and "non-flexible mode". An encoder can only switch between the two on the first packet of a key frame with temporal layer ID equal to 0. In flexible mode, each packet can contain up to 3 reference indices, which identify all frames referenced by the frame transmitted in the current packet for inter-picture prediction. This (along with the D bit) enables a receiver to identify if a frame is decodable or not and helps it understand the temporal layer structure. Since this is signaled in each packet it makes it possible to have very flexible temporal layer hierarchies, and scalability structures which are changing dynamically. In non-flexible mode, frames are encoded using a fixed, recurring pattern of dependencies; the set of pictures that recur in this pattern is known as a Picture Group (PG). In this mode, the inter- picture dependencies (the reference indices) of the Picture Group MUST be pre-specified as part of the scalability structure (SS) data. Each packet has an index to refer to one of the described pictures in the PG, from which the pictures referenced by the picture transmitted in the current packet for inter-picture prediction can be identified. Uberti, et al. Expires 12 December 2021 [Page 4] Internet-Draft RTP Payload Format for VP9 June 2021 (Note: A "Picture Group", as used in this document, is not the same thing as the term "Group of Pictures" as it is traditionally used in video coding, i.e. to mean an independently-decoadable run of pictures beginning with a keyframe.) The SS data can also be used to specify the resolution of each spatial layer present in the VP9 stream for both flexible and non- flexible modes. 4. Payload Format This section describes how the encoded VP9 bitstream is encapsulated in RTP. To handle network losses usage of RTP/AVPF [RFC4585] is RECOMMENDED. All integer fields in the specifications are encoded as unsigned integers in network octet order. 4.1. RTP Header Usage The general RTP payload format for VP9 is depicted below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | VP9 payload descriptor (integer #octets) | : : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | + | : VP9 payload : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Uberti, et al. Expires 12 December 2021 [Page 5] Internet-Draft RTP Payload Format for VP9 June 2021 Figure 1 The VP9 payload descriptor will be described in Section 4.2; the VP9 payload is described in [VP9-BITSTREAM]. OPTIONAL RTP padding MUST NOT be included unless the P bit is set. Marker bit (M): MUST be set to 1 for the final packet of the highest spatial layer frame (the final packet of the picture), and 0 otherwise. Unless spatial scalability is in use for this picture, this will have the same value as the E bit described below. Note this bit MUST be set to 1 for the target spatial layer frame if a stream is being rewritten to remove higher spatial layers. Payload Type (PT): In line with the policy in Section 3 of [RFC3551], applications using the VP9 RTP payload profile MUST assign a dynamic payload type number to be used in each RTP session and provide a mechanism to indicate the mapping. See Section 6.1 for the mechanism to be used with the Session Description Protocol (SDP) [RFC8866]. Timestamp: The RTP timestamp [RFC3550] indicates the time when the input frame was sampled, at a clock rate of 90 kHz. If the input picture is encoded with multiple layer frames, all of the frames of the picture MUST have the same timestamp. If a frame has the VP9 show_frame field set to 0 (i.e., it is meant only to populate a reference buffer, without being output) its timestamp MAY alternatively be set to be the same as the subsequent frame with show_frame equal to 1. (This will be convenient for playing out pre-encoded content packaged with VP9 "superframes", which typically bundle show_frame==0 frames with a subsequent show_frame==1 frame.) Every frame with show_frame==1, however, MUST have a unique timestamp modulo the 2^32 wrap of the field. The remaining RTP Fixed Header Fields (V, P, X, CC, sequence number, SSRC and CSRC identifiers) are used as specified in Section 5.1 of [RFC3550]. 4.2. VP9 Payload Descriptor In flexible mode (with the F bit below set to 1), the first octets after the RTP header are the VP9 payload descriptor, with the following structure. Uberti, et al. Expires 12 December 2021 [Page 6] Internet-Draft RTP Payload Format for VP9 June 2021 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|P|L|F|B|E|V|Z| (REQUIRED) +-+-+-+-+-+-+-+-+ I: |M| PICTURE ID | (REQUIRED) +-+-+-+-+-+-+-+-+ M: | EXTENDED PID | (RECOMMENDED) +-+-+-+-+-+-+-+-+ L: | TID |U| SID |D| (Conditionally RECOMMENDED) +-+-+-+-+-+-+-+-+ -\ P,F: | P_DIFF |N| (Conditionally REQUIRED) - up to 3 times +-+-+-+-+-+-+-+-+ -/ V: | SS | | .. | +-+-+-+-+-+-+-+-+ Figure 2 In non-flexible mode (with the F bit below set to 0), the first octets after the RTP header are the VP9 payload descriptor, with the following structure. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|P|L|F|B|E|V|Z| (REQUIRED) +-+-+-+-+-+-+-+-+ I: |M| PICTURE ID | (RECOMMENDED) +-+-+-+-+-+-+-+-+ M: | EXTENDED PID | (RECOMMENDED) +-+-+-+-+-+-+-+-+ L: | TID |U| SID |D| (Conditionally RECOMMENDED) +-+-+-+-+-+-+-+-+ | TL0PICIDX | (Conditionally REQUIRED) +-+-+-+-+-+-+-+-+ V: | SS | | .. | +-+-+-+-+-+-+-+-+ Figure 3 I: Picture ID (PID) present. When set to one, the OPTIONAL PID MUST be present after the mandatory first octet and specified as below. Otherwise, PID MUST NOT be present. If the V bit was set in the stream's most recent start of a keyframe (i.e. the SS field was present) and the F bit is set to 0 (i.e. non-flexible scalability mode is in use), then this bit MUST be set on every packet. Uberti, et al. Expires 12 December 2021 [Page 7] Internet-Draft RTP Payload Format for VP9 June 2021 P: Inter-picture predicted frame. When set to zero, the frame does not utilize inter-picture prediction. In this case, up-switching to a current spatial layer's frame is possible from directly lower spatial layer frame. P SHOULD also be set to zero when encoding a layer synchronization frame in response to an LRR [I-D.ietf-avtext-lrr] message (see Section 5.3). When P is set to zero, the TID field (described below) MUST also be set to 0 (if present). Note that the P bit does not forbid intra-picture, inter-layer prediction from earlier frames of the same picture, if any. L: Layer indices present. When set to one, the one or two octets following the mandatory first octet and the PID (if present) is as described by "Layer indices" below. If the F bit (described below) is set to 1 (indicating flexible mode), then only one octet is present for the layer indices. Otherwise if the F bit is set to 0 (indicating non-flexible mode), then two octets are present for the layer indices. F: Flexible mode. F set to one indicates flexible mode and if the P bit is also set to one, then the octets following the mandatory first octet, the PID, and layer indices (if present) are as described by "Reference indices" below. This MUST only be set to 1 if the I bit is also set to one; if the I bit is set to zero, then this MUST also be set to zero and ignored by receivers. (Flexible mode's Reference indices are defined as offsets from the Picture ID field, so they would have no meaning if I were not set.) The value of this F bit MUST only change on the first packet of a key picture. A key picture is a picture whose base spatial layer frame is a key frame, and which thus completely resets the encoder state. This packet will have its P bit equal to zero, SID or L bit (described below) equal to zero, and B bit (described below) equal to 1. B: Start of a frame. MUST be set to 1 if the first payload octet of the RTP packet is the beginning of a new VP9 frame, and MUST NOT be 1 otherwise. Note that this frame might not be the first frame of a picture. E: End of a frame. MUST be set to 1 for the final RTP packet of a VP9 frame, and 0 otherwise. This enables a decoder to finish decoding the frame, where it otherwise may need to wait for the next packet to explicitly know that the frame is complete. Note that, if spatial scalability is in use, more frames from the same picture may follow; see the description of the B bit above. V: Scalability structure (SS) data present. When set to one, the Uberti, et al. Expires 12 December 2021 [Page 8] Internet-Draft RTP Payload Format for VP9 June 2021 OPTIONAL SS data MUST be present in the payload descriptor. Otherwise, the SS data MUST NOT be present. Z: Not a reference frame for upper spatial layers. If set to 1, indicates that frames with higher spatial layers SID+1 and greater of the current and following pictures do not depend on the current spatial layer SID frame. This enables a decoder which is targeting a higher spatial layer to know that it can safely discard this packet's frame without processing it, without having to wait for the "D" bit in the higher-layer frame (see below). The mandatory first octet is followed by the extension data fields that are enabled: M: The most significant bit of the first octet is an extension flag. The field MUST be present if the I bit is equal to one. If M is set, the PID field MUST contain 15 bits; otherwise, it MUST contain 7 bits. See PID below. Picture ID (PID): Picture ID represented in 7 or 15 bits, depending on the M bit. This is a running index of the pictures, where the sender increments the value by 1 for each picture it sends. (Note however that because a middlebox can discard pictures where permitted by the scalability structure, Picture IDs as received by a receiver might not be contiguous.) This field MUST be present if the I bit is equal to one. If M is set to zero, 7 bits carry the PID; else if M is set to one, 15 bits carry the PID in network byte order. The sender may choose between a 7- or 15-bit index. The PID SHOULD start on a random number, and MUST wrap after reaching the maximum ID (0x7f or 0x7fff depending on the index size chosen). The receiver MUST NOT assume that the number of bits in PID stay the same through the session. If this field transitions from 7-bits to 15-bits, the value is zero-extended (i.e. the value after 0x6e is 0x006f); if the field transitions from 15 bits to 7 bits, it is truncated (i.e. the value after 0x1bbe is 0xbf). In the non-flexible mode (when the F bit is set to 0), this PID is used as an index to the picture group (PG) specified in the SS data below. In this mode, the PID of the key frame corresponds to the first specified frame in the PG. Then subsequent PIDs are mapped to subsequently specified frames in the PG (modulo N_G, specified in the SS data below), respectively. All frames of the same picture MUST have the same PID value. Frames (and their corresponding pictures) with the VP9 show_frame Uberti, et al. Expires 12 December 2021 [Page 9] Internet-Draft RTP Payload Format for VP9 June 2021 field equal to 0 MUST have distinct PID values from subsequent pictures with show_frame equal to 1. Thus, a Picture as defined in this specification is different than a VP9 Superframe. All frames of the same picture MUST have the same value for show_frame. Layer indices: This information is optional but RECOMMENDED whenever encoding with layers. For both flexible and non-flexible modes, one octet is used to specify a layer frame's temporal layer ID (TID) and spatial layer ID (SID) as shown both in Figure 2 and Figure 3. Additionally, a bit (U) is used to indicate that the current frame is a "switching up point" frame. Another bit (D) is used to indicate whether inter-layer prediction is used for the current frame. In the non-flexible mode (when the F bit is set to 0), another octet is used to represent temporal layer 0 index (TL0PICIDX), as depicted in Figure 3. The TL0PICIDX is present so that all minimally required frames - the base temporal layer frames - can be tracked. The TID and SID fields indicate the temporal and spatial layers and can help middleboxes and endpoints quickly identify which layer a packet belongs to. TID: The temporal layer ID of current frame. In the case of non- flexible mode, if PID is mapped to a picture in a specified PG, then the value of TID MUST match the corresponding TID value of the mapped picture in the PG. U: Switching up point. If this bit is set to 1 for the current picture with temporal layer ID equal to TID, then "switch up" to a higher frame rate is possible as subsequent higher temporal layer pictures will not depend on any picture before the current picture (in coding order) with temporal layer ID greater than TID. SID: The spatial layer ID of current frame. Note that frames with spatial layer SID > 0 may be dependent on decoded spatial layer SID-1 frame within the same picture. Different frames of the same picture MUST have distinct spatial layer IDs, and frames' spatial layers MUST appear in increasing order within the frame. D: Inter-layer dependency used. MUST be set to one if and only Uberti, et al. Expires 12 December 2021 [Page 10] Internet-Draft RTP Payload Format for VP9 June 2021 if the current spatial layer SID frame depends on spatial layer SID-1 frame of the same picture, otherwise MUST be set to zero. For the base layer frame (with SID equal to 0), this D bit MUST be set to zero. TL0PICIDX: 8 bits temporal layer zero index. TL0PICIDX is only present in the non-flexible mode (F = 0). This is a running index for the temporal base layer pictures, i.e., the pictures with TID set to 0. If TID is larger than 0, TL0PICIDX indicates which temporal base layer picture the current picture depends on. TL0PICIDX MUST be incremented by 1 when TID is equal to 0. The index SHOULD start on a random number, and MUST restart at 0 after reaching the maximum number 255. Reference indices: When P and F are both set to one, indicating a non-key frame in flexible mode, then at least one reference index MUST be specified as below. Additional reference indices (total of up to 3 reference indices are allowed) may be specified using the N bit below. When either P or F is set to zero, then no reference index is specified. P_DIFF: The reference index (in 7 bits) specified as the relative PID from the current picture. For example, when P_DIFF=3 on a packet containing the picture with PID 112 means that the picture refers back to the picture with PID 109. This calculation is done modulo the size of the PID field, i.e., either 7 or 15 bits. A P_DIFF value of 0 is invalid. N: 1 if there is additional P_DIFF following the current P_DIFF. 4.2.1. Scalability Structure (SS): The scalability structure (SS) data describes the resolution of each frame within a picture as well as the inter-picture dependencies for a picture group (PG). If the VP9 payload descriptor's "V" bit is set, the SS data is present in the position indicated in Figure 2 and Figure 3. Uberti, et al. Expires 12 December 2021 [Page 11] Internet-Draft RTP Payload Format for VP9 June 2021 +-+-+-+-+-+-+-+-+ V: | N_S |Y|G|-|-|-| +-+-+-+-+-+-+-+-+ -\ Y: | WIDTH | (OPTIONAL) . + + . | | (OPTIONAL) . +-+-+-+-+-+-+-+-+ . - N_S + 1 times | HEIGHT | (OPTIONAL) . + + . | | (OPTIONAL) . +-+-+-+-+-+-+-+-+ -/ G: | N_G | (OPTIONAL) +-+-+-+-+-+-+-+-+ -\ N_G: | TID |U| R |-|-| (OPTIONAL) . +-+-+-+-+-+-+-+-+ -\ . - N_G times | P_DIFF | (OPTIONAL) . - R times . +-+-+-+-+-+-+-+-+ -/ -/ Figure 4 N_S: N_S + 1 indicates the number of spatial layers present in the VP9 stream. Y: Each spatial layer's frame resolution present. When set to one, the OPTIONAL WIDTH (2 octets) and HEIGHT (2 octets) MUST be present for each layer frame. Otherwise, the resolution MUST NOT be present. G: PG description present flag. -: Bit reserved for future use. MUST be set to zero and MUST be ignored by the receiver. N_G: N_G indicates the number of pictures in a Picture Group (PG). If N_G is greater than 0, then the SS data allows the inter- picture dependency structure of the VP9 stream to be pre-declared, rather than indicating it on the fly with every packet. If N_G is greater than 0, then for N_G pictures in the PG, each picture's temporal layer ID (TID), switch up point (U), and the Reference indices (P_DIFFs) are specified. The first picture specified in the PG MUST have TID set to 0. G set to 0 or N_G set to 0 indicates that either there is only one temporal layer (for non-flexible mode) or no fixed inter-picture dependency information is present (for flexible mode) going forward in the bitstream. Uberti, et al. Expires 12 December 2021 [Page 12] Internet-Draft RTP Payload Format for VP9 June 2021 Note that for a given picture, all frames follow the same inter- picture dependency structure. However, the frame rate of each spatial layer can be different from each other and this can be described with the use of the D bit described above. The specified dependency structure in the SS data MUST be for the highest frame rate layer. In a scalable stream sent with a fixed pattern, the SS data SHOULD be included in the first packet of every key frame. This is a packet with P bit equal to zero, SID or L bit equal to zero, and B bit equal to 1. The SS data MUST only be changed on the picture that corresponds to the first picture specified in the previous SS data's PG (if the previous SS data's N_G was greater than 0). 4.3. Frame Fragmentation VP9 frames are fragmented into packets, in RTP sequence number order, beginning with a packet with the B bit set, and ending with a packet with the E bit set. There is no mechanism for finer-grained access to parts of a VP9 frame. 4.4. Scalable encoding considerations In addition to the use of reference frames, VP9 has several additional forms of inter-frame dependencies, largely involving probability tables for the entropy and tree encoders. In VP9 syntax, the syntax element "error_resilient_mode" resets this additional inter-frame data, allowing a frame's syntax to be decoded independently. Due to the requirements of scalable streams, a VP9 encoder producing a scalable stream needs to ensure that a frame does not depend on a previous frame (of the same or a previous picture) that can legitimately be removed from the stream. Thus, a frame that follows a frame that might be removed (in full decode order) MUST be encoded with "error_resilient_mode" set to true. For spatially-scalable streams, this means that "error_resilient_mode" needs to be turned on for the base spatial layer; it can however be turned off for higher spatial layers, assuming they are sent with inter-layer dependency (i.e. with the "D" bit set). For streams that are only temporally-scalable without spatial scalability, "error_resilient_mode" can additionally be turned off for any picture that immediately follows a temporal layer 0 frame. 4.5. Examples of VP9 RTP Stream Uberti, et al. Expires 12 December 2021 [Page 13] Internet-Draft RTP Payload Format for VP9 June 2021 4.5.1. Reference picture use for scalable structure As discussed in Section 3, the VP9 codec can maintain up to eight reference frames, of which up to three can be referenced or updated by any new frame. This section illustrates one way that a scalable structure (with three spatial layers and three temporal layers) can be constructed using these reference frames. +==========+=========+============+=========+ | Temporal | Spatial | References | Updates | +==========+=========+============+=========+ | 0 | 0 | 0 | 0 | +----------+---------+------------+---------+ | 0 | 1 | 0,1 | 1 | +----------+---------+------------+---------+ | 0 | 2 | 1,2 | 2 | +----------+---------+------------+---------+ | 2 | 0 | 0 | 6 | +----------+---------+------------+---------+ | 2 | 1 | 1,6 | 7 | +----------+---------+------------+---------+ | 2 | 2 | 2,7 | - | +----------+---------+------------+---------+ | 1 | 0 | 0 | 3 | +----------+---------+------------+---------+ | 1 | 1 | 1,3 | 4 | +----------+---------+------------+---------+ | 1 | 2 | 2,4 | 5 | +----------+---------+------------+---------+ | 2 | 0 | 3 | 6 | +----------+---------+------------+---------+ | 2 | 1 | 4,6 | 7 | +----------+---------+------------+---------+ | 2 | 2 | 5,7 | - | +----------+---------+------------+---------+ Table 1: Example scalability structure This structure is constructed such that the "U" bit can always be set. 5. Feedback Messages and Header Extensions Uberti, et al. Expires 12 December 2021 [Page 14] Internet-Draft RTP Payload Format for VP9 June 2021 5.1. Reference Picture Selection Indication (RPSI) The reference picture selection index is a payload-specific feedback message defined within the RTCP-based feedback format. The RPSI message is generated by a receiver and can be used in two ways. Either it can signal a preferred reference picture when a loss has been detected by the decoder -- preferably then a reference that the decoder knows is perfect -- or, it can be used as positive feedback information to acknowledge correct decoding of certain reference pictures. The positive feedback method is useful for VP9 used for point to point (unicast) communication. The use of RPSI for VP9 is preferably combined with a special update pattern of the codec's two special reference frames -- the golden frame and the altref frame -- in which they are updated in an alternating leapfrog fashion. When a receiver has received and correctly decoded a golden or altref frame, and that frame had a Picture ID in the payload descriptor, the receiver can acknowledge this simply by sending an RPSI message back to the sender. The message body (i.e., the "native RPSI bit string" in [RFC4585]) is simply the (7 or 15 bit) Picture ID of the received frame. Note: because all frames of the same picture must have the same inter-picture reference structure, there is no need for a message to specify which frame is being selected. 5.2. Full Intra Request (FIR) The Full Intra Request (FIR) [RFC5104] RTCP feedback message allows a receiver to request a full state refresh of an encoded stream. Upon receipt of an FIR request, a VP9 sender MUST send a picture with a keyframe for its spatial layer 0 layer frame, and then send frames without inter-picture prediction (P=0) for any higher layer frames. 5.3. Layer Refresh Request (LRR) The Layer Refresh Request (LRR) [I-D.ietf-avtext-lrr] allows a receiver to request a single layer of a spatially or temporally encoded stream to be refreshed, without necessarily affecting the stream's other layers. +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +---------------+---------+-----+ | RES | TID | RES | SID | +---------------+---------+-----+ Figure 5 Uberti, et al. Expires 12 December 2021 [Page 15] Internet-Draft RTP Payload Format for VP9 June 2021 Figure 5 shows the format of LRR's layer index fields for VP9 streams. The two "RES" fields MUST be set to 0 on transmission and ingnored on reception. See Section 4.2 for details on the TID and SID fields. Identification of a layer refresh frame can be derived from the reference IDs of each frame by backtracking the dependency chain until reaching a point where only decodable frames are being referenced. Therefore it's recommended for both the flexible and the non-flexible mode that, when switching up points are being encoded in response to a LRR, those packets should contain layer indices and the reference field(s) so that the decoder or a selective forwarding middleboxes [RFC7667] can make this derivation. Example: LRR {1,0}, {2,1} is sent by an MCU when it is currently relaying {1,0} to a receiver and which wants to upgrade to {2,1}. In response the encoder should encode the next frames in layers {1,1} and {2,1} by only referring to frames in {1,0}, or {0,0}. In the non-flexible mode, periodic upgrade frames can be defined by the layer structure of the SS, thus periodic upgrade frames can be automatically identified by the picture ID. 6. Payload Format Parameters This payload format has three optional parameters, "max-fr", "max- fs", and "profile-id". The max-fr and max-fs parameters are used to signal the capabilities of a receiver implementation. If the implementation is willing to receive media, both parameters MUST be provided. These parameters MUST NOT be used for any other purpose. A media sender SHOULD NOT send media with a frame rate or frame size exceeding the max-fr and max-fs values signaled. (There may be scenarios, such as pre-encoded media or selective forwarding middleboxes [RFC7667], where a media sender does not have media available that fits within a receivers max-fs and max-fr value; in such scenarios, a sender MAY exceed the signaled values.) max-fr: The value of max-fr is an integer indicating the maximum frame rate in units of frames per second that the decoder is capable of decoding. max-fs: The value of max-fs is an integer indicating the maximum frame size in units of macroblocks that the decoder is capable of decoding. Uberti, et al. Expires 12 December 2021 [Page 16] Internet-Draft RTP Payload Format for VP9 June 2021 The decoder is capable of decoding this frame size as long as the width and height of the frame in macroblocks are less than int(sqrt(max-fs * 8)) - for instance, a max-fs of 1200 (capable of supporting 640x480 resolution) will support widths and heights up to 1552 pixels (97 macroblocks). profile-id: The value of profile-id is an integer indicating the default coding profile, the subset of coding tools that may have been used to generate the stream or that the receiver supports). Table 2 lists all of the profiles defined in section 7.2 of [VP9-BITSTREAM] and the corresponding integer values to be used. If no profile-id is present, Profile 0 MUST be inferred. (The profile-id parameter was added relatively late in the development of this specification, so some existing implementations may not send it.) Informative note: See Table 3 for capabilities of coding profiles defined in section 7.2 of [VP9-BITSTREAM]. A receiver MUST ignore any parameter unspecified in this specification. +=========+============+ | Profile | profile-id | +=========+============+ | 0 | 0 | +---------+------------+ | 1 | 1 | +---------+------------+ | 2 | 2 | +---------+------------+ | 3 | 3 | +---------+------------+ Table 2: Table of profile-id integer values representing the VP9 profile corresponding to the set of coding tools supported. Uberti, et al. Expires 12 December 2021 [Page 17] Internet-Draft RTP Payload Format for VP9 June 2021 +=========+===========+=================+==========================+ | Profile | Bit Depth | SRGB Colorspace | Chroma Subsampling | +=========+===========+=================+==========================+ | 0 | 8 | No | YUV 4:2:0 | +---------+-----------+-----------------+--------------------------+ | 1 | 8 | Yes | YUV 4:2:2,4:4:0 or 4:4:4 | +---------+-----------+-----------------+--------------------------+ | 2 | 10 or 12 | No | YUV 4:2:0 | +---------+-----------+-----------------+--------------------------+ | 3 | 10 or 12 | Yes | YUV 4:2:2,4:4:0 or 4:4:4 | +---------+-----------+-----------------+--------------------------+ Table 3: Table of profile capabilities. 6.1. SDP Parameters 6.1.1. Mapping of Media Subtype Parameters to SDP The media type video/VP9 string is mapped to fields in the Session Description Protocol (SDP) [RFC8866] as follows: * The media name in the "m=" line of SDP MUST be video. * The encoding name in the "a=rtpmap" line of SDP MUST be VP9 (the media subtype). * The clock rate in the "a=rtpmap" line MUST be 90000. * The parameters "max-fr" and "max-fs" MUST be included in the "a=fmtp" line of SDP if the receiver wishes to declare its receiver capabilities. These parameters are expressed as a media subtype string, in the form of a semicolon separated list of parameter=value pairs. * The OPTIONAL parameter profile-id, when present, SHOULD be included in the "a=fmtp" line of SDP. This parameter is expressed as a media subtype string, in the form of a parameter=value pair. When the parameter is not present, a value of 0 MUST be inferred for profile-id. 6.1.1.1. Example An example of media representation in SDP is as follows: m=video 49170 RTP/AVPF 98 a=rtpmap:98 VP9/90000 a=fmtp:98 max-fr=30;max-fs=3600;profile-id=0 Uberti, et al. Expires 12 December 2021 [Page 18] Internet-Draft RTP Payload Format for VP9 June 2021 6.1.2. Offer/Answer Considerations When VP9 is offered over RTP using SDP in an Offer/Answer model [RFC3264] for negotiation for unicast usage, the following limitations and rules apply: * The parameter identifying a media format configuration for VP9 is profile-id. This media format configuration parameter MUST be used symmetrically; that is, the answerer MUST either maintain this configuration parameter or remove the media format (payload type) completely if it is not supported. * The max-fr and max-fs parameters are used declaratively to describe receiver capabilities, even in the Offer/Answer model. The values in an answer are used to describe the answerer's capabilities, and thus their values are set independently of the values in the offer. * To simplify the handling and matching of these configurations, the same RTP payload type number used in the offer SHOULD also be used in the answer and in a subsequent offer, as specified in [RFC3264]. An answer or subsequent offer MUST NOT contain the payload type number used in the offer unless the profile-id value is exactly the same as in the original offer. However, max-fr and max-fs parameters MAY be changed in subsequent offers and answers, with the same payload type number, if an endpoint wishes to change its declared receiver capabilities. 7. Media Type Definition This registration is done using the template defined in [RFC6838] and following [RFC4855]. Type name: video Subtype name: VP9 Required parameters: N/A. Optional parameters: There are three optional parameters, "max-fr", "max-fs", and "profile-id". See Section 6 for their definition. Uberti, et al. Expires 12 December 2021 [Page 19] Internet-Draft RTP Payload Format for VP9 June 2021 Encoding considerations: This media type is framed in RTP and contains binary data; see Section 4.8 of [RFC6838]. Security considerations: See Section 8 of RFC xxxx. [RFC Editor: Upon publication as an RFC, please replace "XXXX" with the number assigned to this document and remove this note.] Interoperability considerations: None. Published specification: VP9 bitstream format [VP9-BITSTREAM] and RFC XXXX. [RFC Editor: Upon publication as an RFC, please replace "XXXX" with the number assigned to this document and remove this note.] Applications which use this media type: For example: Video over IP, video conferencing. Fragment identifier considerations: N/A. Additional information: None. Person & email address to contact for further information: Jonathan Lennox Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Author: Jonathan Lennox Change controller: IETF AVTCore Working Group delegated from the IESG. Uberti, et al. Expires 12 December 2021 [Page 20] Internet-Draft RTP Payload Format for VP9 June 2021 8. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms in Options for Securing RTP Sessions [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of this security consideration section discusses the security impacting properties of the payload format itself. Implementations of this RTP payload format need to take appropriate security considerations into account. It is extremely important for the decoder to be robust against malicious or malformed payloads and ensure that they do not cause the decoder to overrun its allocated memory or otherwise mis-behave. An overrun in allocated memory could lead to arbitrary code execution by an attacker. The same applies to the encoder, even though problems in encoders are typically rarer. This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Nor does the RTP payload format contain any active content. 9. Congestion Control Congestion control for RTP SHALL be used in accordance with RFC 3550 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 [RFC3551]. The congestion control mechanism can, in a real-time encoding scenario, adapt the transmission rate by instructing the encoder to encode at a certain target rate. Media aware network elements MAY use the information in the VP9 payload descriptor in Section 4.2 to identify non-reference frames and discard them in order to reduce network congestion. Note that discarding of non- reference frames cannot be done if the stream is encrypted (because the non-reference marker is encrypted). Uberti, et al. Expires 12 December 2021 [Page 21] Internet-Draft RTP Payload Format for VP9 June 2021 10. IANA Considerations The IANA is requested to register the media type registration "video/ vp9" as specified in Section 7. The media type is also requested to be added to the IANA registry for "RTP Payload Format MIME types" . 11. Acknowledgments Alex Eleftheriadis, Yuki Ito, Won Kap Jang, Sergio Garcia Murillo, Roi Sasson, Timothy Terriberry, Emircan Uysaler, and Thomas Volkert commented on the development of this document and provided helpful comments and feedback. 12. References 12.1. Normative References [I-D.ietf-avtext-lrr] Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. Flodman, "The Layer Refresh Request (LRR) RTCP Feedback Message", Work in Progress, Internet-Draft, draft-ietf- avtext-lrr-07, 2 July 2017, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . Uberti, et al. Expires 12 December 2021 [Page 22] Internet-Draft RTP Payload Format for VP9 June 2021 [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", RFC 8866, DOI 10.17487/RFC8866, January 2021, . [VP9-BITSTREAM] Grange, A., de Rivaz, P., and J. Hunt, "VP9 Bitstream & Decoding Process Specification", Version 0.6, 31 March 2016, . 12.2. Informative References [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, . Uberti, et al. Expires 12 December 2021 [Page 23] Internet-Draft RTP Payload Format for VP9 June 2021 [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, . [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . Authors' Addresses Justin Uberti Google, Inc. 747 6th Street South Kirkland, WA 98033 United States of America Email: justin@uberti.name Stefan Holmer Google, Inc. Kungsbron 2 SE-111 22 Stockholm Sweden Email: holmer@google.com Magnus Flodman Google, Inc. Kungsbron 2 SE-111 22 Stockholm Sweden Email: mflodman@google.com Uberti, et al. Expires 12 December 2021 [Page 24] Internet-Draft RTP Payload Format for VP9 June 2021 Danny Hong Google, Inc. 1585 Charleston Road Mountain View, CA 94043 United States of America Email: dannyhong@google.com Jonathan Lennox 8x8, Inc. / Jitsi Jersey City, NJ 07302 United States of America Email: jonathan.lennox@8x8.com Uberti, et al. Expires 12 December 2021 [Page 25] ./draft-davies-int-historic-05.txt0000644000764400076440000002664514341257163016634 0ustar iustiniustin Network Working Group K. Davies Internet-Draft A. Baber Updates: 1528, 1706 (if approved) IANA Intended status: Informational 28 November 2022 Expires: 1 June 2023 Deprecating infrastructure "int" domains draft-davies-int-historic-05 Abstract The document deprecates the use of any "int" domain names that were designated for infrastructure purposes by the IETF, and identifies them for removal from the "int" top-level domain. Any implementation that involves these domains should be considered deprecated. This document also requests moving the status of RFC 1528 and RFC 1706 to historic. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Davies & Baber Expires 1 June 2023 [Page 1] Internet-Draft Infrastructure .int domains November 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Historical infrastructural uses . . . . . . . . . . . . . . . 3 2.1. atma.int . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. ip4.int . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3. ip6.int . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4. nsap.int . . . . . . . . . . . . . . . . . . . . . . . . 3 2.5. rdi.int . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.6. reg.int . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.7. tpc.int . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Updates to other RFC Series documents . . . . . . . . . . . . 4 3.1. RFC 1528 . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. RFC 1706 . . . . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Additional Information . . . . . . . . . . . . . . . . . . . 4 7. Informative References . . . . . . . . . . . . . . . . . . . 5 Notes (for removal before publication) . . . . . . . . . . . . . 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The "int" top-level domain [RFC1591] is a specialized domain designated for intergovernmental organizations, which are organizations established by international treaties between or among national governments. Historically, the "int" domain was also used for Internet infrastructure related purposes. This practice ended in 2001 when the "arpa" domain was declared the appropriate home for infrastructural identifier spaces [RFC3172]. In conjunction with this change, the eligibility for "int" domains was limited to only intergovernmental treaty organizations. Davies & Baber Expires 1 June 2023 [Page 2] Internet-Draft Infrastructure .int domains November 2022 The documented uses of infrastructural identifiers in the "int" domain were largely experimental and are now in practice obsolete. This document requests moving the related specifications to historic status, along with removing any associated delegations from the "int" zone in the domain name system. 2. Historical infrastructural uses The following domains were used for infrastructural identifier purposes that are now considered historic. Although each of these names was either delegated or documented at one time, the parties administering them have long since stopped using them. 2.1. atma.int The atma.int domain was experimentally defined to implement address lookups for Asynchronous Transfer Mode (ATM), including ATM End System Addresses (AESAs). [ANS] 2.2. ip4.int The ip4.int domain was described as providing an alternative to in- addr.arpa domain for mapping host IPv4 addresses to host names. The in-addr.arpa domain zone continues to be administered for this purpose [RFC1035]. 2.3. ip6.int The ip6.int domain was originally delegated for mapping host IPv6 addresses to host names. It was subsequently removed from the "int" zone, having been replaced by ip6.arpa for this purpose [RFC4159]. 2.4. nsap.int The nsap.int domain name was specified to experimentally map Open Systems Interconnection (OSI) Network Service Access Points to domain names [RFC1706]. 2.5. rdi.int The rdi.int domain name experimentally mapped OSI Inter-Domain Routing Protocol's Routing Domain Identifiers [ISO10747] to the domain name system. 2.6. reg.int The reg.int domain name hosted an experimental mechanism for publishing IANA registration values in the domain name system. Davies & Baber Expires 1 June 2023 [Page 3] Internet-Draft Infrastructure .int domains November 2022 2.7. tpc.int The tpc.int domain name hosted an experimental remote printing service that served as a gateway between Internet mail and facsimile transmission [RFC1528]. 3. Updates to other RFC Series documents 3.1. RFC 1528 The specification for tpc.int [RFC1528] should be deemed historic as it no longer functions as described in the document. 3.2. RFC 1706 The specification for nsap.int [RFC1706] should be deemed historic as it no longer functions as described in the document. 4. IANA Considerations The IANA shall coordinate the removal of any of the historical "int" domains discussed in this document that are still delegated in the "int" zone. 5. Security Considerations Some old systems might have one or more subdomains of these names hardwired and expect a positive response for at least the second- level domain. This is, of course, true for any name in the DNS and should not be the sole basis to retain obsolete names. Existing applications should eliminate any reliance upon these zones for their historic purpose. The operator of the "int" domain should be cautious about any potential re-use of these domains for intergovernmental treaty organizations. 6. Additional Information This document is the result of an comprehensive inventory conducted by the IANA team of .int domains to accurately establish and record their purpose based on historical documentation. As part of this inventory, the domains delegated for infrastructure identifier related purposes were studied. Query patterns in the DNS for these domains were analyzed and judged to be insignificant, and preliminary outreach was conducted to the contacts for the associated domains. The assessment concluded that these domains are highly likely to be obsolete and this document is intended to formalize that assessment. Davies & Baber Expires 1 June 2023 [Page 4] Internet-Draft Infrastructure .int domains November 2022 There are a small number of existing "int" domains nominally for "international databases" that are not defined by any standards documentation, and are assigned to entities rather than for an identifier purpose. While they would not qualify for a "int" domain under current criteria, their disposition is beyond the scope of this memo. 7. Informative References [ANS] "ATM Name Service Specification Version 1.0", ATM Forum AF-SAA-0069.000, November 1996, . [ISO10747] "Protocol for exchange of inter-domain routeing information among intermediate systems to support forwarding of ISO 8473 PDUs", ISO/IEC 10747:1994, October 1994, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1528] Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC 1528, DOI 10.17487/RFC1528, October 1993, . [RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, DOI 10.17487/RFC1591, March 1994, . [RFC1706] Manning, B. and R. Colella, "DNS NSAP Resource Records", RFC 1706, DOI 10.17487/RFC1706, October 1994, . [RFC3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, . [RFC4159] Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159, DOI 10.17487/RFC4159, August 2005, . Notes (for removal before publication) I-D source is maintained at: https://github.com/kjd/draft-davies-int- historic Davies & Baber Expires 1 June 2023 [Page 5] Internet-Draft Infrastructure .int domains November 2022 Acknowledgments This document was compiled with help from Ted Hardie and Michelle Cotton, with additional input from Jari Arkko, John Klensin, Warren Kumari, Pete Resnick, George Michaelson and Toerless Eckert. Authors' Addresses Kim Davies Internet Assigned Numbers Authority PTI/ICANN 12025 Waterfront Drive Los Angeles, 90094 United States of America Email: kim.davies@iana.org Amanda Baber Internet Assigned Numbers Authority PTI/ICANN 12025 Waterfront Drive Los Angeles, 90094 United States of America Email: amanda.baber@iana.org Davies & Baber Expires 1 June 2023 [Page 6] ./draft-ietf-ipwave-vehicular-networking-30.txt0000644000764400076440000045033414325544615021331 0ustar iustiniustin IPWAVE Working Group J. Jeong, Ed. Internet-Draft Sungkyunkwan University Intended status: Informational 24 October 2022 Expires: 27 April 2023 IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases draft-ietf-ipwave-vehicular-networking-30 Abstract This document discusses the problem statement and use cases of IPv6-based vehicular networking for Intelligent Transportation Systems (ITS). The main scenarios of vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communications. First, this document explains use cases using V2V, V2I, and V2X networking. Next, for IPv6-based vehicular networks, it makes a gap analysis of current IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Jeong Expires 27 April 2023 [Page 1] Internet-Draft IPWAVE Problem Statement October 2022 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 12 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 13 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 15 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 19 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 23 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 26 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 27 5.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 28 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 6.1. Security Threats in Neighbor Discovery . . . . . . . . . 32 6.2. Security Threats in Mobility Management . . . . . . . . . 34 6.3. Other Threats . . . . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . 37 8.2. Informative References . . . . . . . . . . . . . . . . . 38 Appendix A. Support of Multiple Radio Technologies for V2V . . . 50 Appendix B. Support of Multihop V2X Networking . . . . . . . . . 50 Appendix C. Support of Mobility Management for V2I . . . . . . . 52 Appendix D. Support of MTU Diversity for IP-based Vehicular Networks . . . . . . . . . . . . . . . . . . . . . . . . 53 Appendix E. Acknowledgments . . . . . . . . . . . . . . . . . . 54 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 56 1. Introduction Vehicular networking studies have mainly focused on improving road safety and efficiency, and also enabling entertainment in vehicular networks. To proliferate the use cases of vehicular networks, several governments and private organizations have committed to allocate dedicated spectrum for vehicular communications. The Federal Communications Commission (FCC) in the US allocated wireless Jeong Expires 27 April 2023 [Page 2] Internet-Draft IPWAVE Problem Statement October 2022 channels for Dedicated Short-Range Communications (DSRC) [DSRC] in the Intelligent Transportation Systems (ITS) with the frequency band of 5.850 - 5.925 GHz (i.e., 5.9 GHz band). In November 2020, the FCC adjusted the lower 45 MHz (i.e., 5.850 - 5.895 GHz) of the 5.9 GHz band for unlicensed use instead of DSRC-dedicated use [FCC-ITS-Modification]. DSRC-based wireless communications can support vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) networking. The European Union (EU) allocated radio spectrum for safety-related and non-safety-related applications of ITS with the frequency band of 5.875 - 5.905 GHz, as part of the Commission Decision 2008/671/EC [EU-2008-671-EC]. Most other countries and regions in the world have adopted the 5.9 GHz band for vehicular networks, though different countries use different ways to divide the band into channels. For direct inter-vehicular wireless connectivity, IEEE has amended standard 802.11 (commonly known as Wi-Fi) to enable safe driving services based on DSRC for the Wireless Access in Vehicular Environments (WAVE) system. The Physical Layer (L1) and Data Link Layer (L2) issues are addressed in IEEE 802.11p [IEEE-802.11p] for the PHY and MAC of the DSRC, while IEEE 1609.2 [WAVE-1609.2] covers security aspects, IEEE 1609.3 [WAVE-1609.3] defines related services at network and transport layers, and IEEE 1609.4 [WAVE-1609.4] specifies the multichannel operation. IEEE 802.11p was first a separate amendment, but was later rolled into the base 802.11 standard (IEEE 802.11-2012) as IEEE 802.11 Outside the Context of a Basic Service Set (OCB) in 2012 [IEEE-802.11-OCB]. 3GPP has standardized Cellular Vehicle-to-Everything (C-V2X) communications to support V2X in LTE mobile networks (called LTE V2X) and V2X in 5G mobile networks (called 5G V2X) [TS-23.285-3GPP] [TR-22.886-3GPP][TS-23.287-3GPP]. With C-V2X, vehicles can directly communicate with each other without relay nodes (e.g., eNodeB in LTE and gNodeB in 5G). Along with these WAVE standards and C-V2X standards, regardless of a wireless access technology under the IP stack of a vehicle, vehicular networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6 protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6) [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Network Mobility (NEMO) [RFC3963], and Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6830bis]. In addition, ISO has approved a standard specifying the IPv6 network protocols and services to be used for Communications Access for Land Mobiles (CALM) [ISO-ITS-IPv6][ISO-ITS-IPv6-AMD1]. Jeong Expires 27 April 2023 [Page 3] Internet-Draft IPWAVE Problem Statement October 2022 This document describes use cases and a problem statement about IPv6-based vehicular networking for ITS, which is named IPv6 Wireless Access in Vehicular Environments (IPWAVE). First, it introduces the use cases for using V2V, V2I, and V2X networking in ITS. Next, for IPv6-based vehicular networks, it makes a gap analysis of current IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management, and Security & Privacy) so that those protocols can be tailored to IPv6-based vehicular networking. Thus, this document is intended to motivate development of key protocols for IPWAVE. 2. Terminology This document uses the terminology described in [RFC8691]. In addition, the following terms are defined below: * Context-Awareness: A vehicle can be aware of spatial-temporal mobility information (e.g., position, speed, direction, and acceleration/deceleration) of surrounding vehicles for both safety and non-safety uses through sensing or communication [CASD]. * DMM: "Distributed Mobility Management" [RFC7333][RFC7429]. * Edge Computing Device (ECD): It is a computing device (or server) at edge for vehicles and vulnerable road users. It co-locates with or connects to an IP-RSU, which has a powerful computing capability for different kinds of computing tasks, such as image processing and classification. * Edge Network (EN): It is an access network that has an IP-RSU for wireless communication with other vehicles having an IP-OBU and wired communication with other network devices (e.g., routers, IP- RSUs, ECDs, servers, and MA). It may have a global navigation satellite system (GNSS), such as Global Positioning System (GPS), radio receiver for its position recognition and the localization service for the sake of vehicles. * IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a computer situated in a vehicle (e.g., car, bicycle, autobike, motorcycle, and a similar one), which has a basic processing ability and can be driven by a low-power CPU (e.g., ARM). It has at least one IP interface that runs in IEEE 802.11-OCB and has an "OBU" transceiver. Also, it may have an IP interface that runs in Cellular V2X (C-V2X) [TS-23.285-3GPP] [TR-22.886-3GPP][TS-23.287-3GPP]. It can play the role of a router connecting multiple computers (or in-vehicle devices) inside a vehicle. See the definition of the term "IP-OBU" in [RFC8691]. Jeong Expires 27 April 2023 [Page 4] Internet-Draft IPWAVE Problem Statement October 2022 * IP-RSU: "IP Roadside Unit": An IP-RSU is situated along the road. It has at least two distinct IP-enabled interfaces. The wireless PHY/MAC layer of at least one of its IP-enabled interfaces is configured to operate in 802.11-OCB mode. An IP-RSU communicates with the IP-OBU over an 802.11 wireless link operating in OCB mode. Also, it may have a third IP-enabled wireless interface running in 3GPP C-V2X in addition to the IP-RSU defined in [RFC8691]. An IP-RSU is similar to an Access Network Router (ANR), defined in [RFC3753], and a Wireless Termination Point (WTP), defined in [RFC5415]. See the definition of the term "IP- RSU" in [RFC8691]. * LiDAR: "Light Detection and Ranging". It is a scanning device to measure a distance to an object by emitting pulsed laser light and measuring the reflected pulsed light. * Mobility Anchor (MA): A node that maintains IPv6 addresses and mobility information of vehicles in a road network to support their IPv6 address autoconfiguration and mobility management with a binding table. An MA has End-to-End (E2E) connections (e.g., tunnels) with IP-RSUs under its control for the address autoconfiguration and mobility management of the vehicles. This MA is similar to a Local Mobility Anchor (LMA) in PMIPv6 [RFC5213] for network-based mobility management. * OCB: "Outside the Context of a Basic Service Set - BSS". It is a mode of operation in which a Station (STA) is not a member of a BSS and does not utilize IEEE Std 802.11 authentication, association, or data confidentiality [IEEE-802.11-OCB]. * 802.11-OCB: It refers to the mode specified in IEEE Std 802.11-2016 [IEEE-802.11-OCB] when the MIB attribute dot11OCBActivited is 'true'. * Platooning: Moving vehicles can be grouped together to reduce air- resistance for energy efficiency and reduce the number of drivers such that only the leading vehicle has a driver, and the other vehicles are autonomous vehicles without a driver and closely follow the leading vehicle [Truck-Platooning]. * Traffic Control Center (TCC): A system that manages road infrastructure nodes (e.g., IP-RSUs, MAs, traffic signals, and loop detectors), and also maintains vehicular traffic statistics (e.g., average vehicle speed and vehicle inter-arrival time per road segment) and vehicle information (e.g., a vehicle's identifier, position, direction, speed, and trajectory as a navigation path). TCC is part of a vehicular cloud for vehicular networks. Jeong Expires 27 April 2023 [Page 5] Internet-Draft IPWAVE Problem Statement October 2022 * Urban Air Mobility (UAM): It refers to using lower-altitude aircraft to transport passengers or cargo in urban and suburban areas. The carriers used for UAM can be manned or unmanned vehicles, which can include traditional helicopters, electrical vertical-takeoff-and-landing aircraft (eVTOL), and unmanned aerial vehicles (UAV). * Vehicle: A Vehicle in this document is a node that has an IP-OBU for wireless communication with other vehicles and IP-RSUs. It has a GNSS radio navigation receiver for efficient navigation. Any device having an IP-OBU and a GNSS receiver (e.g., smartphone and tablet PC) can be regarded as a vehicle in this document. * Vehicular Ad Hoc Network (VANET): A network that consists of vehicles interconnected by wireless communication. Two vehicles in a VANET can communicate with each other using other vehicles as relays even where they are out of one-hop wireless communication range. * Vehicular Cloud: A cloud infrastructure for vehicular networks, having compute nodes, storage nodes, and network forwarding elements (e.g., switch and router). * V2D: "Vehicle to Device". It is the wireless communication between a vehicle and a device (e.g., smartphone and IoT device). * V2P: "Vehicle to Pedestrian". It is the wireless communication between a vehicle and a pedestrian's device (e.g., smartphone and IoT device). * V2I2V: "Vehicle to Infrastructure to Vehicle". It is the wireless communication between a vehicle and another vehicle via an infrastructure node (e.g., IP-RSU). * V2I2X: "Vehicle to Infrastructure to Everything". It is the wireless communication between a vehicle and another entity (e.g., vehicle, smartphone, and IoT device) via an infrastructure node (e.g., IP-RSU). * V2X: "Vehicle to Everything". It is the wireless communication between a vehicle and any entity (e.g., vehicle, infrastructure node, smartphone, and IoT device), including V2V, V2I, and V2D. * VMM: "Vehicular Mobility Management". It is an IPv6-based mobility management for vehicular networks. * VND: "Vehicular Neighbor Discovery". It is an IPv6 ND extension for vehicular networks. Jeong Expires 27 April 2023 [Page 6] Internet-Draft IPWAVE Problem Statement October 2022 * VSP: "Vehicular Security and Privacy". It is an IPv6-based security and privacy term for vehicular networks. * WAVE: "Wireless Access in Vehicular Environments" [WAVE-1609.0]. 3. Use Cases This section explains use cases of V2V, V2I, and V2X networking. The use cases of the V2X networking exclude the ones of the V2V and V2I networking, but include Vehicle-to-Pedestrian (V2P) and Vehicle-to- Device (V2D). IP is widely used among popular end-user devices (e.g., smartphone and tablet) in the Internet. Applications (e.g., navigator application) for those devices can be extended such that the V2V use cases in this section can work with IPv6 as a network layer protocol and IEEE 802.11-OCB as a link layer protocol. In addition, IPv6 security needs to be extended to support those V2V use cases in a safe, secure, privacy-preserving way. The use cases presented in this section serve as the description and motivation for the need to augment IPv6 and its protocols to facilitate "Vehicular IPv6". Section 5 summarizes the overall problem statement and IPv6 requirements. Note that the adjective "Vehicular" in this document is used to represent extensions of existing protocols such as IPv6 Neighbor Discovery, IPv6 Mobility Management (e.g., PMIPv6 [RFC5213] and DMM [RFC7429]), and IPv6 Security and Privacy Mechanisms rather than new "vehicular-specific" functions. 3.1. V2V The use cases of V2V networking discussed in this section include * Context-aware navigation for safe driving and collision avoidance; * Collision avoidance service of end systems of Urban Air Mobility (UAM); * Cooperative adaptive cruise control in a roadway; * Platooning in a highway; * Cooperative environment sensing. The above use cases are examples for using V2V networking, which can be extended to other terrestrial vehicles, river/sea ships, railed vehicles, or UAM end systems. Jeong Expires 27 April 2023 [Page 7] Internet-Draft IPWAVE Problem Statement October 2022 Context-Aware Safety Driving (CASD) navigator [CASD] can help drivers to drive safely by alerting them to dangerous obstacles and situations. That is, a CASD navigator displays obstacles or neighboring vehicles relevant to possible collisions in real-time through V2V networking. CASD provides vehicles with a class-based automatic safety action plan, which considers three situations, namely, the Line-of-Sight unsafe, Non-Line-of-Sight unsafe, and safe situations. This action plan can be put into action among multiple vehicles using V2V networking. A collision avoidance service of UAM end systems in air can be envisioned as a use case in air vehicular environments [I-D.templin-ipwave-uam-its]. This use case is similar to the context-aware navigator for terrestrial vehicles. Through V2V coordination, those UAM end systems (e.g., drones) can avoid a dangerous situation (e.g., collision) in three-dimensional space rather than two-dimensional space for terrestrial vehicles. Also, UAM end systems (e.g., flying car) with only a few meters off the ground can communicate with terrestrial vehicles with wireless communication technologies (e.g., DSRC, LTE, and C-V2X). Thus, V2V means any vehicle to any vehicle, whether the vehicles are ground- level or not. Cooperative Adaptive Cruise Control (CACC) [CA-Cruise-Control] helps individual vehicles to adapt their speed autonomously through V2V communication among vehicles according to the mobility of their predecessor and successor vehicles in an urban roadway or a highway. Thus, CACC can help adjacent vehicles to efficiently adjust their speed in an interactive way through V2V networking in order to avoid a collision. Platooning [Truck-Platooning] allows a series (or group) of vehicles (e.g., trucks) to follow each other very closely. Trucks can use V2V communication in addition to forward sensors in order to maintain constant clearance between two consecutive vehicles at very short gaps (from 3 meters to 10 meters). Platooning can maximize the throughput of vehicular traffic in a highway and reduce the gas consumption because the leading vehicle can help the following vehicles to experience less air resistance. Cooperative-environment-sensing use cases suggest that vehicles can share environmental information (e.g., air pollution, hazards/ obstacles, slippery areas by snow or rain, road accidents, traffic congestion, and driving behaviors of neighboring vehicles) from various vehicle-mounted sensors, such as radars, LiDARs, and cameras, with other vehicles and pedestrians. [Automotive-Sensing] introduces millimeter-wave vehicular communication for massive automotive sensing. A lot of data can be generated by those sensors, and these Jeong Expires 27 April 2023 [Page 8] Internet-Draft IPWAVE Problem Statement October 2022 data typically need to be routed to different destinations. In addition, from the perspective of driverless vehicles, it is expected that driverless vehicles can be mixed with driver-operated vehicles. Through cooperative environment sensing, driver-operated vehicles can use environmental information sensed by driverless vehicles for better interaction with the other vehicles and environment. Vehicles can also share their intended maneuvering information (e.g., lane change, speed change, ramp in-and-out, cut-in, and abrupt braking) with neighboring vehicles. Thus, this information sharing can help the vehicles behave as more efficient traffic flows and minimize unnecessary acceleration and deceleration to achieve the best ride comfort. To support applications of these V2V use cases, the required functions of IPv6 include IPv6-based packet exchange in both control and data planes, and secure, safe communication between two vehicles. For the support of V2V under multiple radio technologies (e.g., DSRC and 5G V2X), refer to Appendix A. 3.2. V2I The use cases of V2I networking discussed in this section include * Navigation service; * Energy-efficient speed recommendation service; * Accident notification service; * Electric vehicle (EV) charging service; * UAM navigation service with efficient battery charging. A navigation service, for example, the Self-Adaptive Interactive Navigation Tool (SAINT) [SAINT], using V2I networking interacts with a TCC for the large-scale/long-range road traffic optimization and can guide individual vehicles along appropriate navigation paths in real time. The enhanced version of SAINT [SAINTplus] can give fast moving paths to emergency vehicles (e.g., ambulance and fire engine) to let them reach an accident spot while redirecting other vehicles near the accident spot into efficient detour paths. Either a TCC or an ECD can recommend an energy-efficient speed to a vehicle that depends on its traffic environment and traffic signal scheduling [SignalGuru]. For example, when a vehicle approaches an intersection area and a red traffic light for the vehicle becomes turned on, it needs to reduce its speed to save fuel consumption. In this case, either a TCC or an ECD, which has the up-to-date Jeong Expires 27 April 2023 [Page 9] Internet-Draft IPWAVE Problem Statement October 2022 trajectory of the vehicle and the traffic light schedule, can notify the vehicle of an appropriate speed for fuel efficiency. [Fuel-Efficient] studies fuel-efficient route and speed plans for platooned trucks. The emergency communication between accident vehicles (or emergency vehicles) and a TCC can be performed via either IP-RSU, 4G-LTE or 5G networks. The First Responder Network Authority (FirstNet) [FirstNet] is provided by the US government to establish, operate, and maintain an interoperable public safety broadband network for safety and security network services, e.g., emergency calls. The construction of the nationwide FirstNet network requires each state in the US to have a Radio Access Network (RAN) that will connect to the FirstNet's network core. The current RAN is mainly constructed using 4G-LTE for the communication between a vehicle and an infrastructure node (i.e., V2I) [FirstNet-Report], but it is expected that DSRC-based vehicular networks [DSRC] will be available for V2I and V2V in the near future. An equivalent project in Europe is called Public Safety Communications Europe (PSCE) [PSCE], which is developing a network for emergency communications. An EV charging service with V2I can facilitate the efficient battery charging of EVs. In the case where an EV charging station is connected to an IP-RSU, an EV can be guided toward the deck of the EV charging station or be notified that the charging station is out of service through a battery charging server connected to the IP-RSU. In addition to this EV charging service, other value-added services (e.g., firmware/software update over-the-air and media streaming) can be provided to an EV while it is charging its battery at the EV charging station. For a UAM navigation service, an efficient battery charging plan can improve the battery charging schedule of UAM end systems (e.g., drone) for long-distance flying [CBDN]. For this battery charging schedule, a UAM end system can communicate with a cloud server via an infrastructure node (e.g., IP-RSU). This cloud server can coordinate the battery charging schedules of multiple UAM end systems for their efficient navigation path, considering flight time from their current position to a battery charging station, waiting time in a waiting queue at the station, and battery charging time at the station. In some scenarios such as vehicles moving in highways or staying in parking lots, a V2V2I network is necessary for vehicles to access the Internet since some vehicles may not be covered by an IP-RSU. For those vehicles, a few relay vehicles can help to build the Internet access. For the nested NEMO described in [RFC4888], hosts inside a vehicle shown in Figure 3 for the case of V2V2I may have the same issue in the nested NEMO scenario. Jeong Expires 27 April 2023 [Page 10] Internet-Draft IPWAVE Problem Statement October 2022 To better support these use cases, the existing IPv6 protocol must be augmented either through protocol changes or by including a new adaptation layer in the architecture that efficiently maps IPv6 to a diversity of link layer technologies. Augmentation is necessary to support wireless multihop V2I communications in a highway where RSUs are sparsely deployed, so a vehicle can reach the wireless coverage of an IP-RSU through the multihop data forwarding of intermediate vehicles as packet forwarders. Thus, IPv6 needs to be extended for multihop V2I communications. To support applications of these V2I use cases, the required functions of IPv6 include IPv6 communication enablement with neighborhood discovery and IPv6 address management, reachability with adapted network models and routing methods, transport-layer session continuity, and secure, safe communication between a vehicle and an infrastructure node (e.g., IP-RSU) in the vehicular network. 3.3. V2X The use case of V2X networking discussed in this section is for a vulnerable road user (VRU) (e.g., pedestrian and cyclist) protection service. Note that the application area of this use case is currently limited to a specific environment, such as construction sites, plants, and factories, since not every VRU (e.g., children) in a public area (e.g., streets) is equipped with a smart device (e.g., smartphone, smart watch, and tablet). A VRU protection service, such as Safety-Aware Navigation Application (SANA) [SANA], using V2I2P networking can reduce the collision of a vehicle and a pedestrian carrying a smartphone equipped with a network device for wireless communication (e.g., Wi-Fi, DSRC, 4G/5G V2X, and BLE) with an IP-RSU. Vehicles and pedestrians can also communicate with each other via an IP-RSU. An edge computing device behind the IP-RSU can collect the mobility information from vehicles and pedestrians, compute wireless communication scheduling for the sake of them. This scheduling can save the battery of each pedestrian's smartphone by allowing it to work in sleeping mode before the communication with vehicles, considering their mobility. The location information of a VRU from a smart device (e.g., smartphone) is multicasted only to the nearby vehicles. The true identifiers of a VRU's smart device shall be protected, and only the type of the VRU, such as pedestrian, cyclist, and scooter, is disclosed to the nearby vehicles. For Vehicle-to-Pedestrian (V2P), a vehicle can directly communicate with a pedestrian's smartphone by V2X without IP-RSU relaying. Light-weight mobile nodes such as bicycles may also communicate directly with a vehicle for collision avoidance using V2V. Note that Jeong Expires 27 April 2023 [Page 11] Internet-Draft IPWAVE Problem Statement October 2022 it is true that either a pedestrian or a cyclist may have a higher risk of being hit by a vehicle if they are not with a smartphone in the current setting. For this case, other human sensing technologies (e.g., moving object detection in images and wireless signal-based human movement detection [LIFS][DFC]) can be used to provide the motion information of them to vehicles. A vehicle by V2V2I networking can obtain the motion information of a VRU via an IP-RSU that either employs or connects to a human sensing technology. The existing IPv6 protocol must be augmented through protocol changes in order to support wireless multihop V2X or V2I2X communications in an urban road network where RSUs are deployed at intersections, so a vehicle (or a pedestrian's smartphone) can reach the wireless coverage of an IP-RSU through the multihop data forwarding of intermediate vehicles (or pedestrians' smartphones) as packet forwarders. Thus, IPv6 needs to be extended for multihop V2X or V2I2X communications. To support applications of these V2X use cases, the required functions of IPv6 include IPv6-based packet exchange, transport-layer session continuity, and secure, safe communication between a vehicle and a pedestrian either directly or indirectly via an IP-RSU, and the protection of identifiers of either a vehicle or smart device (such as MAC address and IPv6 address), which is discussed in detail in Section 6.3. 4. Vehicular Networks This section describes the context for vehicular networks supporting V2V, V2I, and V2X communications. It describes an internal network within a vehicle or an edge network (called EN). It explains not only the internetworking between the internal networks of a vehicle and an EN via wireless links, but also the internetworking between the internal networks of two vehicles via wireless links. Jeong Expires 27 April 2023 [Page 12] Internet-Draft IPWAVE Problem Statement October 2022 Traffic Control Center in Vehicular Cloud ******************************************* +-------------+ * * |Correspondent| * +-----------------+ * | Node |<->* | Mobility Anchor | * +-------------+ * +-----------------+ * * ^ * * | * * v * ******************************************* ^ ^ ^ | | | | | | v v v +---------+ +---------+ +---------+ | IP-RSU1 |<--------->| IP-RSU2 |<--------->| IP-RSU3 | +---------+ +---------+ +---------+ ^ ^ ^ : : : +-----------------+ +-----------------+ +-----------------+ | : V2I | | : V2I | | : V2I | | v | | v | | v | +--------+ | +--------+ | | +--------+ | | +--------+ | |Vehicle1|===> |Vehicle2|===>| | |Vehicle3|===>| | |Vehicle4|===>| +--------+<...>+--------+<........>+--------+ | | +--------+ | V2V ^ V2V ^ | | ^ | | : V2V | | : V2V | | : V2V | | v | | v | | v | | +--------+ | | +--------+ | | +--------+ | | |Vehicle5|===> | | |Vehicle6|===>| | |Vehicle7|==>| | +--------+ | | +--------+ | | +--------+ | +-----------------+ +-----------------+ +-----------------+ Subnet1 Subnet2 Subnet3 (Prefix1) (Prefix2) (Prefix3) <----> Wired Link <....> Wireless Link ===> Moving Direction Figure 1: An Example Vehicular Network Architecture for V2I and V2V 4.1. Vehicular Network Architecture Figure 1 shows an example vehicular network architecture for V2I and V2V in a road network. The vehicular network architecture contains vehicles (including IP-OBU), IP-RSUs, Mobility Anchor, Traffic Control Center, and Vehicular Cloud as components. These components are not mandatory, and they can be deployed into vehicular networks in various ways. Some of them (e.g., Mobility Anchor, Traffic Control Center, and Vehicular Cloud) may not be needed for the Jeong Expires 27 April 2023 [Page 13] Internet-Draft IPWAVE Problem Statement October 2022 vehicular networks according to target use cases in Section 3. Existing network architectures, such as the network architectures of PMIPv6 [RFC5213], RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) [RFC6550], and AERO/OMNI [I-D.templin-6man-aero][I-D.templin-6man-omni], can be extended to a vehicular network architecture for multihop V2V, V2I, and V2X, as shown in Figure 1. Refer to Appendix B for the detailed discussion on multihop V2X networking by RPL and OMNI. Also, refer to Appendix A for the description of how OMNI is designed to support the use of multiple radio technologies in V2X. Note that though AERO/ OMNI is not actually deployed in the industry, this AERO/OMNI is mentioned as a possible approach for vehicular networks in this document. As shown in Figure 1, IP-RSUs as routers and vehicles with IP-OBU have wireless media interfaces for VANET. The three IP-RSUs (IP- RSU1, IP-RSU2, and IP-RSU3) are deployed in the road network and are connected with each other through the wired networks (e.g., Ethernet). A Traffic Control Center (TCC) is connected to the Vehicular Cloud for the management of IP-RSUs and vehicles in the road network. A Mobility Anchor (MA) may be located in the TCC as a mobility management controller. Vehicle2, Vehicle3, and Vehicle4 are wirelessly connected to IP-RSU1, IP-RSU2, and IP-RSU3, respectively. The three wireless networks of IP-RSU1, IP-RSU2, and IP-RSU3 can belong to three different subnets (i.e., Subnet1, Subnet2, and Subnet3), respectively. Those three subnets use three different prefixes (i.e., Prefix1, Prefix2, and Prefix3). Multiple vehicles under the coverage of an IP-RSU share a prefix just as mobile nodes share a prefix of a Wi-Fi access point in a wireless LAN. This is a natural characteristic in infrastructure-based wireless networks. For example, in Figure 1, two vehicles (i.e., Vehicle2, and Vehicle5) can use Prefix 1 to configure their IPv6 global addresses for V2I communication. Alternatively, mobile nodes can employ a "Bring-Your-Own-Addresses (BYOA)" (or "Bring-Your-Own- Prefix (BYOP)") technique using their own IPv6 Unique Local Addresses (ULAs) [RFC4193] over the wireless network. Jeong Expires 27 April 2023 [Page 14] Internet-Draft IPWAVE Problem Statement October 2022 In wireless subnets in vehicular networks (e.g., Subnet1 and Subnet2 in Figure 1), vehicles can construct a connected VANET (with an arbitrary graph topology) and can communicate with each other via V2V communication. Vehicle1 can communicate with Vehicle2 via V2V communication, and Vehicle2 can communicate with Vehicle3 via V2V communication because they are within the wireless communication range of each other. On the other hand, Vehicle3 can communicate with Vehicle4 via the vehicular infrastructure (i.e., IP-RSU2 and IP- RSU3) by employing V2I (i.e., V2I2V) communication because they are not within the wireless communication range of each other. As a basic definition for IPv6 packets transported over IEEE 802.11-OCB, [RFC8691] specifies several details, including Maximum Transmission Unit (MTU), frame format, link-local address, address mapping for unicast and multicast, stateless autoconfiguration, and subnet structure. An IPv6 mobility solution is needed for the guarantee of communication continuity in vehicular networks so that a vehicle's TCP session can be continued, or UDP packets can be delivered to a vehicle as a destination without loss while it moves from an IP-RSU's wireless coverage to another IP-RSU's wireless coverage. In Figure 1, assuming that Vehicle2 has a TCP session (or a UDP session) with a correspondent node in the vehicular cloud, Vehicle2 can move from IP-RSU1's wireless coverage to IP-RSU2's wireless coverage. In this case, a handover for Vehicle2 needs to be performed by either a host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a network-based mobility management scheme (e.g., PMIPv6 [RFC5213], NEMO [RFC3963] [RFC4885] [RFC4888], and AERO [I-D.templin-6man-aero]). This document describes issues in mobility management for vehicular networks in Section 5.2. For improving TCP session continuity or successful UDP packet delivery, the multi-path TCP (MPTCP) [RFC8684] or QUIC protocol [RFC9000] can also be used. IP-OBUs, however, may still experience more session time-out and re- establishment procedures due to lossy connections among vehicles caused by the high mobility dynamics of them. 4.2. V2I-based Internetworking This section discusses the internetworking between a vehicle's internal network (i.e., mobile network) and an EN's internal network (i.e., fixed network) via V2I communication. The internal network of a vehicle is nowadays constructed with Ethernet by many automotive vendors [In-Car-Network]. Note that an EN can accommodate multiple routers (or switches) and servers (e.g., ECDs, navigation server, and DNS server) in its internal network. Jeong Expires 27 April 2023 [Page 15] Internet-Draft IPWAVE Problem Statement October 2022 A vehicle's internal network often uses Ethernet to interconnect Electronic Control Units (ECUs) in the vehicle. The internal network can support Wi-Fi and Bluetooth to accommodate a driver's and passenger's mobile devices (e.g., smartphone or tablet). The network topology and subnetting depend on each vendor's network configuration for a vehicle and an EN. It is reasonable to consider interactions between the internal network of a vehicle and that of another vehicle or an EN. Note that it is dangerous if the internal network of a vehicle is controlled by a malicious party. These dangers can include unauthorized driving control input and unauthorized driving information disclosure to an unauthorized third party. A malicious party can be a group of hackers, a criminal group, and a competitor for industrial espionage or sabotage. To minimize this kind of risk, an augmented identification and verification protocol, which has an extra means, shall be implemented based on a basic identity verification process. These extra means can be certificate-based, biometric, credit-based, and one-time passcode (OTP) approaches in addition to a used approach [RFC8002]. The parties of the verification protocol can be from a built-in verification protocol in the current vehicle, which is pre-installed by a vehicle vendor. The parties can also be from any verification authorities that have the database of authenticated users. The security properties provided by a verification protocol can be identity-related information, such as the genuineness of an identity, the authenticity of an identity, and the ownership of an identity [RFC7427]. The augmented identification and verification protocol with extra means can support security properties such as the identification and verification of a vehicle, driver, and passenger. First, a credit- based means is to let a vehicle classify the received messages sent by another host to different severity levels for driving safety in order to calculate the credit for the sender. Based on an accumulated credit, a correspondent node can verify the other party to see whether it is genuine or not. Second, a certificate-based means includes a user certificate (e.g., X.509 certificate [RFC5280]) to authenticate a vehicle or its driver. Third, a biometric means includes a fingerprint, face or voice to authenticate a driver or passenger. Lastly, one-time passcode (called OTP) means lets another already-authenticated device (e.g., smartphone and tablet) of a driver or passenger be used to authenticate a driver or passenger. Jeong Expires 27 April 2023 [Page 16] Internet-Draft IPWAVE Problem Statement October 2022 +-----------------+ (*)<........>(*) +----->| Vehicular Cloud | (2001:db8:1:1::/64) | | | +-----------------+ +------------------------------+ +---------------------------------+ | v | | v v | | +-------+ +-------+ | | +-------+ +-------+ | | | Host1 | |IP-OBU1| | | |IP-RSU1| | Host3 | | | +-------+ +-------+ | | +-------+ +-------+ | | ^ ^ | | ^ ^ | | | | | | | | | | v v | | v v | | ---------------------------- | | ------------------------------- | | 2001:db8:10:1::/64 ^ | | ^ 2001:db8:20:1::/64 | | | | | | | | v | | v | | +-------+ +-------+ | | +-------+ +-------+ +-------+ | | | Host2 | |Router1| | | |Router2| |Server1|...|ServerN| | | +-------+ +-------+ | | +-------+ +-------+ +-------+ | | ^ ^ | | ^ ^ ^ | | | | | | | | | | | v v | | v v v | | ---------------------------- | | ------------------------------- | | 2001:db8:10:2::/64 | | 2001:db8:20:2::/64 | +------------------------------+ +---------------------------------+ Vehicle1 (Mobile Network1) EN1 (Fixed Network1) <----> Wired Link <....> Wireless Link (*) Antenna Figure 2: Internetworking between Vehicle and Edge Network As shown in Figure 2, as internal networks, a vehicle's mobile network and an EN's fixed network are self-contained networks having multiple subnets and having an edge router (e.g., IP-OBU and IP-RSU) for the communication with another vehicle or another EN. The internetworking between two internal networks via V2I communication requires the exchange of the network parameters and the network prefixes of the internal networks. For the efficiency, the network prefixes of the internal networks (as a mobile network) in a vehicle need to be delegated and configured automatically. Note that a mobile network's network prefix can be called a Mobile Network Prefix (MNP) [RFC3963]. Figure 2 also shows the internetworking between the vehicle's mobile network and the EN's fixed network. There exists an internal network (Mobile Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and Host2), and two routers (IP-OBU1 and Router1). There exists another internal network (Fixed Network1) inside EN1. EN1 has one host (Host3), two routers (IP-RSU1 and Router2), and the collection of Jeong Expires 27 April 2023 [Page 17] Internet-Draft IPWAVE Problem Statement October 2022 servers (Server1 to ServerN) for various services in the road networks, such as the emergency notification and navigation. Vehicle1's IP-OBU1 (as a mobile router) and EN1's IP-RSU1 (as a fixed router) use 2001:db8:1:1::/64 for an external link (e.g., DSRC) for V2I networking. Thus, a host (Host1) in Vehicle1 can communicate with a server (Server1) in EN1 for a vehicular service through Vehicle1's moving network, a wireless link between IP-OBU1 and IP- RSU1, and EN1's fixed network. For the IPv6 communication between an IP-OBU and an IP-RSU or between two neighboring IP-OBUs, they need to know the network parameters, which include MAC layer and IPv6 layer information. The MAC layer information includes wireless link layer parameters, transmission power level, and the MAC address of an external network interface for the internetworking with another IP-OBU or IP-RSU. The IPv6 layer information includes the IPv6 address and network prefix of an external network interface for the internetworking with another IP- OBU or IP-RSU. Through the mutual knowledge of the network parameters of internal networks, packets can be transmitted between the vehicle's moving network and the EN's fixed network. Thus, V2I requires an efficient protocol for the mutual knowledge of network parameters. Note that from a security point of view, a perimeter-based policy enforcement can be applied to protect parts of the internal network of a vehicle. As shown in Figure 2, the addresses used for IPv6 transmissions over the wireless link interfaces for IP-OBU and IP-RSU can be link-local IPv6 addresses, ULAs, or global IPv6 addresses. When IPv6 addresses are used, wireless interface configuration and control overhead for DAD [RFC4862] and Multicast Listener Discovery (MLD) [RFC2710][RFC3810] should be minimized to support V2I and V2X communications for vehicles moving fast along roadways. Jeong Expires 27 April 2023 [Page 18] Internet-Draft IPWAVE Problem Statement October 2022 Let us consider the upload/download time of a ground vehicle when it passes through the wireless communication coverage of an IP-RSU. For a given typical setting where 1km is the maximum DSRC communication range [DSRC] and 100km/h is the speed limit in highway for ground vehicles, the dwelling time can be calculated to be 72 seconds by dividing the diameter of the 2km (i.e., two times of DSRC communication range where an IP-RSU is located in the center of the circle of wireless communication) by the speed limit of 100km/h (i.e., about 28m/s). For the 72 seconds, a vehicle passing through the coverage of an IP-RSU can upload and download data packets to/ from the IP-RSU. For special cases such as emergency vehicles moving above the speed limit, the dwelling time is relatively shorter than that of other vehicles. For cases of airborne vehicles, considering a higher flying speed and a higher altitude, the dwelling time can be much shorter. 4.3. V2V-based Internetworking This section discusses the internetworking between the moving networks of two neighboring vehicles via V2V communication. (*)<..........>(*) (2001:db8:1:1::/64) | | +------------------------------+ +------------------------------+ | v | | v | | +-------+ +-------+ | | +-------+ +-------+ | | | Host1 | |IP-OBU1| | | |IP-OBU2| | Host3 | | | +-------+ +-------+ | | +-------+ +-------+ | | ^ ^ | | ^ ^ | | | | | | | | | | v v | | v v | | ---------------------------- | | ---------------------------- | | 2001:db8:10:1::/64 ^ | | ^ 2001:db8:30:1::/64 | | | | | | | | v | | v | | +-------+ +-------+ | | +-------+ +-------+ | | | Host2 | |Router1| | | |Router2| | Host4 | | | +-------+ +-------+ | | +-------+ +-------+ | | ^ ^ | | ^ ^ | | | | | | | | | | v v | | v v | | ---------------------------- | | ---------------------------- | | 2001:db8:10:2::/64 | | 2001:db8:30:2::/64 | +------------------------------+ +------------------------------+ Vehicle1 (Mobile Network1) Vehicle2 (Mobile Network2) <----> Wired Link <....> Wireless Link (*) Antenna Jeong Expires 27 April 2023 [Page 19] Internet-Draft IPWAVE Problem Statement October 2022 Figure 3: Internetworking between Two Vehicles Figure 3 shows the internetworking between the mobile networks of two neighboring vehicles. There exists an internal network (Mobile Network1) inside Vehicle1. Vehicle1 has two hosts (Host1 and Host2), and two routers (IP-OBU1 and Router1). There exists another internal network (Mobile Network2) inside Vehicle2. Vehicle2 has two hosts (Host3 and Host4), and two routers (IP-OBU2 and Router2). Vehicle1's IP-OBU1 (as a mobile router) and Vehicle2's IP-OBU2 (as a mobile router) use 2001:db8:1:1::/64 for an external link (e.g., DSRC) for V2V networking. Thus, a host (Host1) in Vehicle1 can communicate with another host (Host3) in Vehicle2 for a vehicular service through Vehicle1's mobile network, a wireless link between IP-OBU1 and IP- OBU2, and Vehicle2's mobile network. As a V2V use case in Section 3.1, Figure 4 shows the linear network topology of platooning vehicles for V2V communications where Vehicle3 is the leading vehicle with a driver, and Vehicle2 and Vehicle1 are the following vehicles without drivers. From a security point of view, before vehicles can be platooned, they shall be mutually authenticated to reduce possible security risks. (*)<..................>(*)<..................>(*) | | | +-----------+ +-----------+ +-----------+ | | | | | | | +-------+ | | +-------+ | | +-------+ | | |IP-OBU1| | | |IP-OBU2| | | |IP-OBU3| | | +-------+ | | +-------+ | | +-------+ | | ^ | | ^ | | ^ | | | |=====> | | |=====> | | |=====> | v | | v | | v | | +-------+ | | +-------+ | | +-------+ | | | Host1 | | | | Host2 | | | | Host3 | | | +-------+ | | +-------+ | | +-------+ | | | | | | | +-----------+ +-----------+ +-----------+ Vehicle1 Vehicle2 Vehicle3 <----> Wired Link <....> Wireless Link ===> Moving Direction (*) Antenna Figure 4: Multihop Internetworking between Two Vehicle Networks Jeong Expires 27 April 2023 [Page 20] Internet-Draft IPWAVE Problem Statement October 2022 As shown in Figure 4, multihop internetworking is feasible among the mobile networks of three vehicles in the same VANET. For example, Host1 in Vehicle1 can communicate with Host3 in Vehicle3 via IP-OBU1 in Vehicle1, IP-OBU2 in Vehicle2, and IP-OBU3 in Vehicle3 in the VANET, as shown in the figure. In this section, the link between two vehicles is assumed to be stable for single-hop wireless communication regardless of the sight relationship such as line of sight and non-line of sight, as shown in Figure 3. Even in Figure 4, the three vehicles are connected to each other with a linear topology, however, multihop V2V communication can accommodate any network topology (i.e., an arbitrary graph) over VANET routing protocols. (*)<..................>(*)<..................>(*) | | | +-----------+ +-----------+ +-----------+ | | | | | | | +-------+ | | +-------+ | | +-------+ | | |IP-OBU1| | | |IP-RSU1| | | |IP-OBU3| | | +-------+ | | +-------+ | | +-------+ | | ^ | | ^ | | ^ | | | |=====> | | | | | |=====> | v | | v | | v | | +-------+ | | +-------+ | | +-------+ | | | Host1 | | | | Host2 | | | | Host3 | | | +-------+ | | +-------+ | | +-------+ | | | | | | | +-----------+ +-----------+ +-----------+ Vehicle1 EN1 Vehicle3 <----> Wired Link <....> Wireless Link ===> Moving Direction (*) Antenna Figure 5: Multihop Internetworking between Two Vehicle Networks via IP-RSU (V2I2V) As shown in Figure 5, multihop internetworking between two vehicles is feasible via an infrastructure node (i.e., IP-RSU) with wireless connectivity among the mobile networks of two vehicles and the fixed network of an edge network (denoted as EN1) in the same VANET. For example, Host1 in Vehicle1 can communicate with Host3 in Vehicle3 via IP-OBU1 in Vehicle1, IP-RSU1 in EN1, and IP-OBU3 in Vehicle3 in the VANET, as shown in the figure. For the reliability required in V2V networking, the ND optimization defined in MANET [RFC6130] [RFC7466] improves the classical IPv6 ND in terms of tracking neighbor information with up to two hops and Jeong Expires 27 April 2023 [Page 21] Internet-Draft IPWAVE Problem Statement October 2022 introducing several extensible Information Bases, which serves the MANET routing protocols such as the different versions of Optimized Link State Routing Protocol (OLSR) [RFC3626] [RFC7181], Open Shortest Path First (OSPF) derivatives (e.g., [RFC5614]), and Dynamic Link Exchange Protocol (DLEP) [RFC8175] with its extensions [RFC8629] [RFC8757]. In short, the MANET ND mainly deals with maintaining extended network neighbors to enhance the link reliability. However, an ND protocol in vehicular networks shall consider more about the geographical mobility information of vehicles as an important resource for serving various purposes to improve the reliability, e.g., vehicle driving safety, intelligent transportation implementations, and advanced mobility services. For a more reliable V2V networking, some redundancy mechanisms should be provided in L3 in cases of the failure of L2. For different use cases, the optimal solution to improve V2V networking reliability may vary. For example, a group of vehicles in platooning may have stabler neighbors than freely moving vehicles, as described in Section 3.1. 5. Problem Statement In order to specify protocols using the architecture mentioned in Section 4.1, IPv6 core protocols have to be adapted to overcome certain challenging aspects of vehicular networking. Since the vehicles are likely to be moving at great speed, protocol exchanges need to be completed in a relatively short time compared to the lifetime of a link between a vehicle and an IP-RSU, or between two vehicles. In these cases, vehicles may not have enough time either to build link-layer connections with each other and may rely more on connections with infrastructure. In other cases, the relative speed between vehicles may be low when vehicles move toward the same direction or are platooned. For those cases, vehicles can have more time to build and maintain connections with each other. For safe driving, vehicles need to exchange application messages every 0.5 second [NHTSA-ACAS-Report] to let drivers take an action to avoid a dangerous situation (e.g., vehicle collision), so the IPv6 control plane (e.g., ND procedure and DAD) needs to support this order of magnitude for application message exchanges. Also, considering the communication range of DSRC (up to 1km) and 100km/h as the speed limit in highway (some countries can have much higher speed limit or even no limit, e.g., Germany), the lifetime of a link between a vehicle and an IP-RSU is in the order of a minute (e.g., about 72 seconds), and the lifetime of a link between two vehicles is about a half minute. Note that if two vehicles are moving in the opposite directions in a roadway, the relative speed of this case is two times the relative speed of a vehicle passing through an IP-RSU. This relative speed leads the half of the link lifetime between the vehicle and the IP-RSU. In reality, the DSRC communication range is Jeong Expires 27 April 2023 [Page 22] Internet-Draft IPWAVE Problem Statement October 2022 around 500m, so the link lifetime will be a half of the maximum time. The time constraint of a wireless link between two nodes (e.g., vehicle and IP-RSU) needs to be considered because it may affect the lifetime of a session involving the link. The lifetime of a session varies depending on the session's type such as a web surfing, voice call over IP, DNS query, and context-aware navigation (in Section 3.1). Regardless of a session's type, to guide all the IPv6 packets to their destination host(s), IP mobility should be supported for the session. In a V2V scenario (e.g., context-aware navigation), the IPv6 packets of a vehicle should be delivered to relevant vehicles efficiently (e.g., multicasting). With this observation, IPv6 protocol exchanges need to be done as short as possible to support the message exchanges of various applications in vehicular networks. Therefore, the time constraint of a wireless link has a major impact on IPv6 Neighbor Discovery (ND). Mobility Management (MM) is also vulnerable to disconnections that occur before the completion of identity verification and tunnel management. This is especially true given the unreliable nature of wireless communication. Meanwhile, the bandwidth of the wireless link determined by the lower layers (i.e., link and PHY layers) can affect the transmission time of control messages of the upper layers (e.g., IPv6) and the continuity of sessions in the higher layers (e.g., IPv6, TCP, and UDP). Hence, the bandwidth selection according to Modulation and Coding Scheme (MCS) also affects the vehicular network connectivity. Note that usually the higher bandwidth gives the shorter communication range and the higher packet error rate at the receiving side, which may reduce the reliability of control message exchanges of the higher layers (e.g., IPv6). This section presents key topics such as neighbor discovery and mobility management for links and sessions in IPv6-based vehicular networks. Note that the detailed discussion on the transport-layer session mobility and usage of available bandwidth to fulfill the use cases is left as potential future work. 5.1. Neighbor Discovery IPv6 ND [RFC4861][RFC4862] is a core part of the IPv6 protocol suite. IPv6 ND is designed for link types including point-to-point, multicast-capable (e.g., Ethernet) and Non-Broadcast Multiple Access (NBMA). It assumes the efficient and reliable support of multicast and unicast from the link layer for various network operations such as MAC Address Resolution (AR), DAD, MLD and Neighbor Unreachability Detection (NUD). Jeong Expires 27 April 2023 [Page 23] Internet-Draft IPWAVE Problem Statement October 2022 Vehicles move quickly within the communication coverage of any particular vehicle or IP-RSU. Before the vehicles can exchange application messages with each other, they need IPv6 addresses to run IPv6 ND. The requirements for IPv6 ND for vehicular networks are efficient DAD and NUD operations. An efficient DAD is required to reduce the overhead of DAD packets during a vehicle's travel in a road network, which can guarantee the uniqueness of a vehicle's global IPv6 address. An efficient NUD is required to reduce the overhead of the NUD packets during a vehicle's travel in a road network, which can guarantee the accurate neighborhood information of a vehicle in terms of adjacent vehicles and RSUs. The legacy DAD assumes that a node with an IPv6 address can reach any other node with the scope of its address at the time it claims its address, and can hear any future claim for that address by another party within the scope of its address for the duration of the address ownership. However, the partitioning and merging of VANETs makes this assumption be not valid frequently in vehicular networks. The merging and partitioning of VANETs frequently occurs in vehicular networks. This merging and partitioning should be considered for the IPv6 ND such as IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862]. SLAAC is not compatible with merging and partitioning, and additional work is needed for ND to operate properly under those circumstances. Due to the merging of VANETs, two IPv6 addresses may conflict with each other though they were unique before the merging. An address lookup operation may be conducted by an MA or IP-RSU (as Registrar in RPL) to check the uniqueness of an IPv6 address that will be configured by a vehicle as DAD. Also, the partitioning of a VANET may make vehicles with the same prefix be physically unreachable. An address lookup operation may be conducted by an MA or IP-RSU (as Registrar in RPL) to check the existence of a vehicle under the network coverage of the MA or IP-RSU as NUD. Thus, SLAAC needs to prevent IPv6 address duplication due to the merging of VANETs, and IPv6 ND needs to detect unreachable neighboring vehicles due to the partitioning of a VANET. According to the merging and partitioning, a destination vehicle (as an IPv6 host) needs to be distinguished as either an on-link host or a not-onlink host even though the source vehicle can use the same prefix as the destination vehicle [I-D.ietf-intarea-ippl]. To efficiently prevent IPv6 address duplication due to the VANET partitioning and merging from happening in vehicular networks, the vehicular networks need to support a vehicular-network-wide DAD by defining a scope that is compatible with the legacy DAD. In this case, two vehicles can communicate with each other when there exists a communication path over VANET or a combination of VANETs and IP- Jeong Expires 27 April 2023 [Page 24] Internet-Draft IPWAVE Problem Statement October 2022 RSUs, as shown in Figure 1. By using the vehicular-network-wide DAD, vehicles can assure that their IPv6 addresses are unique in the vehicular network whenever they are connected to the vehicular infrastructure or become disconnected from it in the form of VANET. For vehicular networks with high mobility and density, DAD needs to be performed efficiently with minimum overhead so that the vehicles can exchange driving safety messages (e.g., collision avoidance and accident notification) with each other with a short interval suggested by NHTSA (National Highway Traffic Safety Administration) [NHTSA-ACAS-Report]. Since the partitioning and merging of vehicular networks may require re-perform DAD process repeatedly, the link scope of vehicles may be limited to a small area, which may delay the exchange of driving safety messages. Driving safety messages can include a vehicle's mobility information (i.e., position, speed, direction, and acceleration/deceleration) that is critical to other vehicles. The exchange interval of this message is recommended to be less than 0.5 second, which is required for a driver to avoid an emergency situation, such as a rear-end crash. ND time-related parameters such as router lifetime and Neighbor Advertisement (NA) interval need to be adjusted for vehicle speed and vehicle density. For example, the NA interval needs to be dynamically adjusted according to a vehicle's speed so that the vehicle can maintain its neighboring vehicles in a stable way, considering the collision probability with the NA messages sent by other vehicles. The ND time-related parameters can be an operational setting or an optimization point particularly for vehicular networks. Note that the link-scope multicast messages in ND protocol may cause the performance issue in vehicular networks. [RFC9119] suggests several optimization approaches for the issue. For IPv6-based safety applications (e.g., context-aware navigation, adaptive cruise control, and platooning) in vehicular networks, the delay-bounded data delivery is critical. IPv6 ND needs to work to support those IPv6-based safety applications efficiently. [I-D.jeong-ipwave-vehicular-neighbor-discovery] introduces a Vehicular Neighbor Discovery (VND) process as an extension of IPv6 ND for IP-based vehicular networks. From the interoperability point of view, in IPv6-based vehicular networking, IPv6 ND should have minimum changes with the legacy IPv6 ND used in the Internet, including DAD and NUD operations, so that IPv6-based vehicular networks can be seamlessly connected to other intelligent transportation elements (e.g., traffic signals, pedestrian wearable devices, electric scooters, and bus stops) that use the standard IPv6 network settings. Jeong Expires 27 April 2023 [Page 25] Internet-Draft IPWAVE Problem Statement October 2022 5.1.1. Link Model A subnet model for a vehicular network needs to facilitate the communication between two vehicles with the same prefix regardless of the vehicular network topology as long as there exist bidirectional E2E paths between them in the vehicular network including VANETs and IP-RSUs. This subnet model allows vehicles with the same prefix to communicate with each other via a combination of multihop V2V and multihop V2I with VANETs and IP-RSUs. [I-D.thubert-6man-ipv6-over-wireless] introduces other issues in an IPv6 subnet model. IPv6 protocols work under certain assumptions that do not necessarily hold for vehicular wireless access link types [VIP-WAVE][RFC5889]. For instance, some IPv6 protocols such as NUD [RFC4861] and MIPv6 [RFC6275] assume symmetry in the connectivity among neighboring interfaces. However, radio interference and different levels of transmission power may cause asymmetric links to appear in vehicular wireless links [RFC6250]. As a result, a new vehicular link model needs to consider the asymmetry of dynamically changing vehicular wireless links. There is a relationship between a link and a prefix, besides the different scopes that are expected from the link-local, unique-local, and global types of IPv6 addresses. In an IPv6 link, it is defined that all interfaces which are configured with the same subnet prefix and with on-link bit set can communicate with each other on an IPv6 link. However, the vehicular link model needs to define the relationship between a link and a prefix, considering the dynamics of wireless links and the characteristics of VANET. A VANET can have a single link between each vehicle pair within wireless communication range, as shown in Figure 4. When two vehicles belong to the same VANET, but they are out of wireless communication range, they cannot communicate directly with each other. Suppose that a global-scope IPv6 prefix (or an IPv6 ULA prefix) is assigned to VANETs in vehicular networks. Considering that two vehicles in the same VANET configure their IPv6 addresses with the same IPv6 prefix, if they are not in one hop (that is, they have the multihop network connectivity between them), then they may not be able to communicate with each other. Thus, in this case, the concept of an on-link IPv6 prefix does not hold because two vehicles with the same on-link IPv6 prefix cannot communicate directly with each other. Also, when two vehicles are located in two different VANETs with the same IPv6 prefix, they cannot communicate with each other. When these two VANETs converge to one VANET, the two vehicles can communicate with each other in a multihop fashion, for example, when they are Vehicle1 and Vehicle3, as shown in Figure 4. Jeong Expires 27 April 2023 [Page 26] Internet-Draft IPWAVE Problem Statement October 2022 From the previous observation, a vehicular link model should consider the frequent partitioning and merging of VANETs due to vehicle mobility. Therefore, the vehicular link model needs to use an on- link prefix and not-onlink prefix according to the network topology of vehicles such as a one-hop reachable network and a multihop reachable network (or partitioned networks). If the vehicles with the same prefix are reachable from each other in one hop, the prefix should be on-link. On the other hand, if some of the vehicles with the same prefix are not reachable from each other in one hop due to either the multihop topology in the VANET or multiple partitions, the prefix should be not-onlink. In most cases in vehicular networks, due to the partitioning and merging of VANETs, and the multihop network topology of VANETS, not-onlink prefixes will be used for vehicles as default. The vehicular link model needs to support multihop routing in a connected VANET where the vehicles with the same global-scope IPv6 prefix (or the same IPv6 ULA prefix) are connected in one hop or multiple hops. It also needs to support the multihop routing in multiple connected VANETs through infrastructure nodes (e.g., IP-RSU) where they are connected to the infrastructure. For example, in Figure 1, suppose that Vehicle1, Vehicle2, and Vehicle3 are configured with their IPv6 addresses based on the same global-scope IPv6 prefix. Vehicle1 and Vehicle3 can also communicate with each other via either multihop V2V or multihop V2I2V. When Vehicle1 and Vehicle3 are connected in a VANET, it will be more efficient for them to communicate with each other directly via VANET rather than indirectly via IP-RSUs. On the other hand, when Vehicle1 and Vehicle3 are far away from direct communication range in separate VANETs and under two different IP-RSUs, they can communicate with each other through the relay of IP-RSUs via V2I2V. Thus, two separate VANETs can merge into one network via IP-RSU(s). Also, newly arriving vehicles can merge two separate VANETs into one VANET if they can play the role of a relay node for those VANETs. Thus, in IPv6-based vehicular networking, the vehicular link model should have minimum changes for interoperability with standard IPv6 links efficiently to support IPv6 DAD, MLD and NUD operations. 5.1.2. MAC Address Pseudonym For the protection of drivers' privacy, a pseudonym of a MAC address of a vehicle's network interface should be used, so that the MAC address can be changed periodically. However, although such a pseudonym of a MAC address can protect to some extent the privacy of a vehicle, it may not be able to resist attacks on vehicle identification by other fingerprint information, for example, the scrambler seed embedded in IEEE 802.11-OCB frames [Scrambler-Attack]. Jeong Expires 27 April 2023 [Page 27] Internet-Draft IPWAVE Problem Statement October 2022 Note that [I-D.ietf-madinas-mac-address-randomization] discusses more about MAC address randomization, and [I-D.ietf-madinas-use-cases] describes several use cases for MAC address randomization. In the ETSI standards, for the sake of security and privacy, an ITS station (e.g., vehicle) can use pseudonyms for its network interface identities (e.g., MAC address) and the corresponding IPv6 addresses [Identity-Management]. Whenever the network interface identifier changes, the IPv6 address based on the network interface identifier needs to be updated, and the uniqueness of the address needs to be checked through DAD procedure. 5.1.3. Routing For multihop V2V communications in either a VANET or VANETs via IP- RSUs, a vehicular Mobile Ad Hoc Networks (MANET) routing protocol may be required to support both unicast and multicast in the links of the subnet with the same IPv6 prefix. However, it will be costly to run both vehicular ND and a vehicular ad hoc routing protocol in terms of control traffic overhead [RFC9119]. A routing protocol for a VANET may cause redundant wireless frames in the air to check the neighborhood of each vehicle and compute the routing information in a VANET with a dynamic network topology because the IPv6 ND is used to check the neighborhood of each vehicle. Thus, the vehicular routing needs to take advantage of the IPv6 ND to minimize its control overhead. RPL [RFC6550] defines a routing protocol for low-power and lossy networks, which constructs and maintains Destination-Oriented Directed Acyclic Graphs (DODAGs) optimized by an Objective Function (OF). A defined OF provides route selection and optimization within an RPL topology. The RPL nodes use an anisotropic Distance Vector (DV) approach to form a DODAG by discovering and aggressively maintaining the upward default route toward the root of the DODAG. Downward routes follow the same DODAG, with lazy maintenance and stretched Peer-to-Peer (P2P) routing in the so-called storing mode. It is well-designed to reduce the topological knowledge and routing state that needs to be exchanged. As a result, the routing protocol overhead is minimized, which allows either highly constrained stable networks or less constrained, highly dynamic networks. Refer to Appendix B for the detailed description of RPL for multihop V2X networking. An address registration extension for 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Network) in [RFC8505] can support light-weight mobility for nodes moving through different parents. [RFC8505], as opposed to [RFC4861], is stateful and proactively installs the ND Jeong Expires 27 April 2023 [Page 28] Internet-Draft IPWAVE Problem Statement October 2022 cache entries, which saves broadcasts and provides deterministic presence information for IPv6 addresses. Mainly it updates the Address Registration Option (ARO) of ND defined in [RFC6775] to include a status field that can indicate the movement of a node and optionally a Transaction ID (TID) field, i.e., a sequence number that can be used to determine the most recent location of a node. Thus, RPL can use the information provided by the Extended ARO (EARO) defined in [RFC8505] to deal with a certain level of node mobility. When a leaf node moves to the coverage of another parent node, it should de-register its addresses to the previous parent node and register itself with a new parent node along with an incremented TID. RPL can be used in IPv6-based vehicular networks, but it is primarily designed for low-power networks, which puts energy efficiency first. For using it in IPv6-based vehicular networks, there have not been actual experiences and practical implementations, though it was tested in IoT low-power and lossy networks (LLN) scenarios. Another concern is that RPL may generate excessive topology discovery messages in a highly moving environment such as vehicular networks. This issue can be an operational or optimization point for a practitioner. Moreover, due to bandwidth and energy constraints, RPL does not suggest using a proactive mechanism (e.g., keepalive) to maintain accurate routing adjacencies such as Bidirectional Forwarding Detection [RFC5881] and MANET Neighborhood Discovery Protocol [RFC6130]. As a result, due to the mobility of vehicles, network fragmentation may not be detected quickly and the routing of packets between vehicles or between a vehicle and an infrastructure node may fail. 5.2. Mobility Management The seamless connectivity and timely data exchange between two end points requires efficient mobility management including location management and handover. Most vehicles are equipped with a GNSS receiver as part of a dedicated navigation system or a corresponding smartphone App. Note that the GNSS receiver may not provide vehicles with accurate location information in adverse environments such as a building area or a tunnel. The location precision can be improved with assistance of the IP-RSUs or a cellular system with a GNSS receiver for location information. With a GNSS navigator, efficient mobility management can be performed with the help of vehicles periodically reporting their current position and trajectory (i.e., navigation path) to the vehicular infrastructure (having IP-RSUs and an MA in TCC). This vehicular infrastructure can predict the future positions of the vehicles from Jeong Expires 27 April 2023 [Page 29] Internet-Draft IPWAVE Problem Statement October 2022 their mobility information (i.e., the current position, speed, direction, and trajectory) for efficient mobility management (e.g., proactive handover). For a better proactive handover, link-layer parameters, such as the signal strength of a link-layer frame (e.g., Received Channel Power Indicator (RCPI) [VIP-WAVE]), can be used to determine the moment of a handover between IP-RSUs along with mobility information. By predicting a vehicle's mobility, the vehicular infrastructure needs to better support IP-RSUs to perform efficient SLAAC, data forwarding, horizontal handover (i.e., handover in wireless links using a homogeneous radio technology), and vertical handover (i.e., handover in wireless links using heterogeneous radio technologies) in advance along with the movement of the vehicle. For example, as shown in Figure 1, when a vehicle (e.g., Vehicle2) is moving from the coverage of an IP-RSU (e.g., IP-RSU1) into the coverage of another IP-RSU (e.g., IP-RSU2) belonging to a different subnet, the IP-RSUs can proactively support the IPv6 mobility of the vehicle, while performing the SLAAC, data forwarding, and handover for the sake of the vehicle. For a mobility management scheme in a domain, where the wireless subnets of multiple IP-RSUs share the same prefix, an efficient vehicular-network-wide DAD is required. On the other hand, for a mobility management scheme with a unique prefix per mobile node (e.g., PMIPv6 [RFC5213]), DAD is not required because the IPv6 address of a vehicle's external wireless interface is guaranteed to be unique. There is a trade-off between the prefix usage efficiency and DAD overhead. Thus, the IPv6 address autoconfiguration for vehicular networks needs to consider this trade-off to support efficient mobility management. Even though the SLAAC with classic ND costs a DAD during mobility management, the SLAAC with [RFC8505] and/or AERO/OMNI do not cost a DAD. SLAAC for vehicular networks needs to consider the minimization of the cost of DAD with the help of an infrastructure node (e.g., IP- RSU and MA). Using an infrastructure prefix over VANET allows direct routability to the Internet through the multihop V2I toward an IP- RSU. On the other hand, a BYOA does not allow such direct routability to the Internet since the BYOA is not topologically correct, that is, not routable in the Internet. In addition, a vehicle configured with a BYOA needs a tunnel home (e.g., IP-RSU) connected to the Internet, and the vehicle needs to know which neighboring vehicle is reachable inside the VANET toward the tunnel home. There is non-negligible control overhead to set up and maintain routes to such a tunnel home [RFC4888] over the VANET. Jeong Expires 27 April 2023 [Page 30] Internet-Draft IPWAVE Problem Statement October 2022 For the case of a multihomed network, a vehicle can follow the first- hop router selection rule described in [RFC8028]. For example, an IP-OBU inside a vehicle may connect to an IP-RSU that has multiple routers behind. In this scenario, because the IP-OBU can have multiple prefixes from those routers, the default router selection, source address selection, and packet redirect process should follow the guidelines in [RFC8028]. That is, the vehicle should select its default router for each prefix by preferring the router that advertised the prefix. Vehicles can use the TCC as their Home Network having a home agent for mobility management as in MIPv6 [RFC6275], PMIPv6 [RFC5213], and NEMO [RFC3963], so the TCC (or an MA inside the TCC) maintains the mobility information of vehicles for location management. Also, in vehicular networks, asymmetric links sometimes exist and must be considered for wireless communications such as V2V and V2I. [I-D.jeong-ipwave-vehicular-mobility-management] discusses a Vehicular Mobility Management (VMM) scheme to proactively do handover for vehicles. Therefore, for the proactive and seamless IPv6 mobility of vehicles, the vehicular infrastructure (including IP-RSUs and MA) needs to efficiently perform the mobility management of the vehicles with their mobility information and link-layer information. Also, in IPv6-based vehicular networking, IPv6 mobility management should have minimum changes for the interoperability with the legacy IPv6 mobility management schemes such as PMIPv6, DMM, LISP, and AERO. 6. Security Considerations This section discusses security and privacy for IPv6-based vehicular networking. Security and privacy are paramount in V2I, V2V, and V2X networking along with neighbor discovery and mobility management. Vehicles and infrastructure must be authenticated to each other by a password, a key, and/or a fingerprint in order to participate in vehicular networking. For the authentication in vehicular networks, vehicular cloud needs to support a Public Key Infrastructure (PKI) efficiently, as either a dedicated or a co-located component inside a TCC. To provide safe interaction between vehicles or between a vehicle and infrastructure, only authenticated nodes (i.e., vehicle and infrastructure node) can participate in vehicular networks. Also, in-vehicle devices (e.g., ECU) and a driver/passenger's mobile devices (e.g., smartphone and tablet PC) in a vehicle need to communicate with other in-vehicle devices and another driver/ passenger's mobile devices in another vehicle, or other servers behind an IP-RSU securely. Even though a vehicle is perfectly authenticated by another entity and legitimate to use the data Jeong Expires 27 April 2023 [Page 31] Internet-Draft IPWAVE Problem Statement October 2022 generated by another vehicle, it may be hacked for running malicious applications to track and collect its and other vehicles' information. In this case, an attack mitigation process may be required to reduce the aftermath of malicious behaviors. Note that when driver/passenger's mobile devices are connected to a vehicle's internal network, the vehicle may be more vulnerable to possible attacks from external networks due to the exposure of its in-flight traffic packets. [I-D.jeong-ipwave-security-privacy] discusses several types of threats for Vehicular Security and Privacy (VSP). For secure V2I communication, a secure channel (e.g., IPsec) between a mobile router (i.e., IP-OBU) in a vehicle and a fixed router (i.e., IP-RSU) in an EN needs to be established, as shown in Figure 2 [RFC4301][RFC4302] [RFC4303][RFC4308] [RFC7296]. Also, for secure V2V communication, a secure channel (e.g., IPsec) between a mobile router (i.e., IP-OBU) in a vehicle and a mobile router (i.e., IP-OBU) in another vehicle needs to be established, as shown in Figure 3. For secure V2I/V2V communication, an element in a vehicle (e.g., an in-vehicle device and a driver/passenger's mobile device) needs to establish a secure connection (e.g., TLS) with another element in another vehicle or another element in a vehicular cloud (e.g., a server). Note that any key management approach can be used for the secure communication, and particularly for IPv6-based vehicular networks, a new or enhanced key management approach resilient to wireless networks is required. IEEE 1609.2 [WAVE-1609.2] specifies security services for applications and management messages, but this WAVE specification is optional. Thus, if the link layer does not support the security of a WAVE frame, either the network layer or the transport layer needs to support security services for the WAVE frames. 6.1. Security Threats in Neighbor Discovery For the classical IPv6 ND (i.e., the legacy ND), DAD is required to ensure the uniqueness of the IPv6 address of a vehicle's wireless interface. This DAD can be used as a flooding attack that uses the DAD-related ND packets disseminated over the VANET or vehicular networks. [RFC6959] introduces threats enabled by IP source address spoofing. This possibility indicates that vehicles and IP-RSUs need to filter out suspicious ND traffic in advance. [RFC8928] introduces a mechanism that protects the ownership of an address for 6loWPAN ND from address theft and impersonation attacks. Based on the SEND [RFC3971] mechanism, the authentication for routers (i.e., IP-RSUs) can be conducted by only selecting an IP-RSU that has a certification path toward trusted parties. For authenticating other vehicles, cryptographically generated addresses (CGA) can be used to verify the Jeong Expires 27 April 2023 [Page 32] Internet-Draft IPWAVE Problem Statement October 2022 true owner of a received ND message, which requires using the CGA ND option in the ND protocol. This CGA can protect vehicles against DAD flooding by DAD filtering based on the verification for the true owner of the received DAD message. For a general protection of the ND mechanism, the RSA Signature ND option can also be used to protect the integrity of the messages by public key signatures. For a more advanced authentication mechanism, a distributed blockchain-based approach [Vehicular-BlockChain] can be used. However, for a scenario where a trustable router or an authentication path cannot be obtained, it is desirable to find a solution in which vehicles and infrastructures can authenticate each other without any support from a third party. When applying the classical IPv6 ND process to VANET, one of the security issues is that an IP-RSU (or an IP-OBU) as a router may receive deliberate or accidental DoS attacks from network scans that probe devices on a VANET. In this scenario, the IP-RSU can be overwhelmed for processing the network scan requests so that the capacity and resources of IP-RSU are exhausted, causing the failure of receiving normal ND messages from other hosts for network address resolution. [RFC6583] describes more about the operational problems in the classical IPv6 ND mechanism that can be vulnerable to deliberate or accidental DoS attacks and suggests several implementation guidelines and operational mitigation techniques for those problems. Nevertheless, for running IPv6 ND in VANET, those issues can be more acute since the movements of vehicles can be so diverse that it leaves a large room for rogue behaviors, and the failure of networking among vehicles may cause grave consequences. Strong security measures shall protect vehicles roaming in road networks from the attacks of malicious nodes, which are controlled by hackers. For safe driving applications (e.g., context-aware navigation, cooperative adaptive cruise control, and platooning), as explained in Section 3.1, the cooperative action among vehicles is assumed. Malicious nodes may disseminate wrong driving information (e.g., location, speed, and direction) for disturbing safe driving. For example, a Sybil attack, which tries to confuse a vehicle with multiple false identities, may disturb a vehicle from taking a safe maneuver. Since cybersecurity issues in vehicular networks may cause physical vehicle safety issues, it may be necessary to consider those physical security concerns when designing protocols in IPWAVE. To identify malicious vehicles among vehicles, an authentication method may be required. A Vehicle Identification Number (VIN) (or a vehicle manufacturer certificate) and a user certificate (e.g., X.509 certificate [RFC5280]) along with an in-vehicle device's identifier generation can be used to efficiently authenticate a vehicle or its driver (having a user certificate) through a road infrastructure node Jeong Expires 27 April 2023 [Page 33] Internet-Draft IPWAVE Problem Statement October 2022 (e.g., IP-RSU) connected to an authentication server in the vehicular cloud. This authentication can be used to identify the vehicle that will communicate with an infrastructure node or another vehicle. In the case where a vehicle has an internal network (called Moving Network) and elements in the network (e.g., in-vehicle devices and a user's mobile devices), as shown in Figure 2, the elements in the network need to be authenticated individually for safe authentication. Also, Transport Layer Security (TLS) certificates [RFC8446][RFC5280] can be used for an element's authentication to allow secure E2E vehicular communications between an element in a vehicle and another element in a server in a vehicular cloud, or between an element in a vehicle and another element in another vehicle. 6.2. Security Threats in Mobility Management For mobility management, a malicious vehicle can construct multiple virtual bogus vehicles, and register them with IP-RSUs and MA. This registration makes the IP-RSUs and MA waste their resources. The IP- RSUs and MA need to determine whether a vehicle is genuine or bogus in mobility management. Also, the confidentiality of control packets and data packets among IP-RSUs and MA, the E2E paths (e.g., tunnels) need to be protected by secure communication channels. In addition, to prevent bogus IP-RSUs and MA from interfering with the IPv6 mobility of vehicles, mutual authentication among them needs to be performed by certificates (e.g., TLS certificate). 6.3. Other Threats For the setup of a secure channel over IPsec or TLS, the multihop V2I communications over DSRC or 5G V2X (or LTE V2X) is required in a highway. In this case, multiple intermediate vehicles as relay nodes can help to forward association and authentication messages toward an IP-RSU (gNodeB or eNodeB) connected to an authentication server in the vehicular cloud. In this kind of process, the authentication messages forwarded by each vehicle can be delayed or lost, which may increase the construction time of a connection or some vehicles may not be able to be authenticated. Even though vehicles can be authenticated with valid certificates by an authentication server in the vehicular cloud, the authenticated vehicles may harm other vehicles. To deal with this kind of security issue, for monitoring suspicious behaviors, vehicles' communication activities can be recorded in either a centralized approach through a logging server (e.g., TCC) in the vehicular cloud or a decentralized approach (e.g., an edge computing device and blockchain [Bitcoin]) by the help of other vehicles and infrastructure. Jeong Expires 27 April 2023 [Page 34] Internet-Draft IPWAVE Problem Statement October 2022 There are trade-offs between centralized and decentralized approaches in logging for vehicles' behaviors (e.g., location, speed, direction, acceleration, deceleration, and lane change) and communication activities (e.g., transmission time, reception time, and packet types such as TCP, UDP, SCTP, QUIC, HTTP, and HTTPS). A centralized approach is more efficient than a decentralized approach in terms of logging data collection and processing in a central server in the vehicular cloud. However, the centralized approach may cause a higher delay than a decentralized approach in terms of the analysis of the logging data and counteraction in a local edge computing device or a distributed database like a blockchain. The centralized approach stores logging data collected from VANET into a remote logging server in a vehicular cloud as a central cloud, so it takes time to deliver the logging data to a remote logging server. On the other hand, the decentralized approach stores the logging data into a nearby edge computing device as a local logging server or a nearby blockchain node, which participates in a blockchain network. On the stored logging data, an analyzer needs to perform a machine learning technique (e.g., Deep Learning) and seek suspicious behaviors of the vehicles. If such an analyzer is located either within or near the edge computing device, it can access the logging data with a short delay, analyze it quickly, and generate feedback to allow for a quick counteraction against such malicious behaviors. On the other hand, if the vehicular cloud with the logging data is far away from a problematic VANET with malicious behaviors, the centralized approach takes a long time with the analysis with the logging data and the decision-making on malicious behaviors than the decentralized approach. If the logging data is encrypted by a secret key, it can be protected from the observation of a hacker. The secret key sharing among legal vehicles, edge computing devices, and vehicular clouds should be supported efficiently. Logging information can release privacy breakage of a vehicle. The logging information can contain the MAC address and IPv6 address for a vehicle's wireless network interface. If the unique MAC address of the wireless network interface is used, a hacker can track the vehicle with that MAC address, so can track the privacy information of the vehicle's driver (e.g., location information). To prevent this privacy breakage, a MAC address pseudonym can be used for the MAC address of the wireless network interface, and the corresponding IPv6 address should be based on such a MAC address pseudonym. By solving a privacy issue of a vehicle's identity in logging, vehicles may observe activities of each other to identify any misbehavior without privacy breakage. Once identifying a misbehavior, a vehicle shall have a way to either isolate itself from others or isolate a suspicious vehicle by informing other vehicles. Jeong Expires 27 April 2023 [Page 35] Internet-Draft IPWAVE Problem Statement October 2022 For completely secure vehicular networks, we shall embrace the concept of "zero-trust" for vehicles in which no vehicle is trustable and verifying every message (such as IPv6 control messages including ND, DAD, NUD, and application layer messages) is necessary. In this way, vehicular networks can defense many possible cyberattacks. Thus, we need to have an efficient zero-trust framework or mechanism for the vehicular networks. For the non-repudiation of the harmful activities from malicious vehicles, which it is difficult for other normal vehicles to identify them, an additional and advanced approach is needed. One possible approach is to use a blockchain-based approach [Bitcoin] as an IPv6 security checking framework. Each IPv6 packet from a vehicle can be treated as a transaction and the neighboring vehicles can play the role of peers in a consensus method of a blockchain [Bitcoin] [Vehicular-BlockChain]. For a blockchain's efficient consensus in vehicular networks having fast moving vehicles, a new consensus algorithm needs to be developed, or an existing consensus algorithm needs to be enhanced. In addition, a consensus-based mechanism for the security of vehicular networks in the IPv6 layer can also be considered. A group of servers as blockchain infrastructure can be part of the security checking process in the IP layer. To prevent an adversary from tracking a vehicle with its MAC address or IPv6 address, especially for a long-living transport-layer session (e.g., voice call over IP and video streaming service), a MAC address pseudonym needs to be provided to each vehicle; that is, each vehicle periodically updates its MAC address and its IPv6 address needs to be updated accordingly by the MAC address change [RFC4086][RFC8981]. Such an update of the MAC and IPv6 addresses should not interrupt the E2E communications between two vehicles (or between a vehicle and an IP-RSU) for a long-living transport-layer session. However, if this pseudonym is performed without strong E2E confidentiality (using either IPsec or TLS), there will be no privacy benefit from changing MAC and IPv6 addresses, because an adversary can observe the change of the MAC and IPv6 addresses and track the vehicle with those addresses. Thus, the MAC address pseudonym and the IPv6 address update should be performed with strong E2E confidentiality. The privacy exposure to the TCC and via V2I is mostly about the location information of vehicles, and may also include other in- vehicle activities such as transactions of credit cards. The assumed, trusted actors are the owner of a vehicle, an authorized vehicle service provider (e.g., navigation service provider), and an authorized vehicle manufacturer for providing after-sales services. In addition, privacy concerns for excessively collecting vehicle activities from roadway operators such as public transportation administrators and private contractors may also pose threats on Jeong Expires 27 April 2023 [Page 36] Internet-Draft IPWAVE Problem Statement October 2022 violating privacy rights of vehicles. It might be interesting to find a solution from a technology point of view along with public policy development for the issue. The "multicasting" of the location information of a VRU's smartphone means IPv6 multicasting. There is a possible security attack related to this multicasting. Attackers can use "fake identifiers" as source IPv6 addresses of their devices to generate IPv6 packets and multicast them to nearby vehicles in order to make a confusion that those vehicles are surrounded by other vehicles or pedestrians. As a result, navigation services (e.g., Google Maps [Google-Maps] and Waze [Waze]) can be confused with fake road traffic by those vehicles or smartphones with "fake identifiers" [Fake-Identifier-Attack]. This attack with "fake identifiers" should be detected and handled by vehicular networks. To cope with this attack, both legal vehicles and legal VRUs' smartphones can be registered with a traffic control center (called TCC) and their locations can be tracked by the TCC. With this tracking, the TCC can tell the road traffic conditions caused by those vehicles and smartphones. In addition, to prevent hackers from tracking the locations of those vehicles and smartphones, either a MAC address pseudonym [I-D.ietf-madinas-mac-address-randomization] or secure IPv6 address generation [RFC7721] can be used to protect the privacy of those vehicles and smartphones. 7. IANA Considerations This document does not require any IANA actions. 8. References 8.1. Normative References [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . Jeong Expires 27 April 2023 [Page 37] Internet-Draft IPWAVE Problem Statement October 2022 [RFC8691] Benamar, N., Härri, J., Lee, J., and T. Ernst, "Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11", RFC 8691, DOI 10.17487/RFC8691, December 2019, . 8.2. Informative References [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, . [RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, DOI 10.17487/RFC3626, October 2003, . [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, . [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, . [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, DOI 10.17487/RFC3963, January 2005, . [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . Jeong Expires 27 April 2023 [Page 38] Internet-Draft IPWAVE Problem Statement October 2022 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, DOI 10.17487/RFC4308, December 2005, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [RFC4885] Ernst, T. and Y. H-Lach, "Network Mobility Support Terminology", RFC 4885, DOI 10.17487/RFC4885, July 2007, . [RFC4888] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, DOI 10.17487/RFC4888, July 2007, . [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, DOI 10.17487/RFC5415, March 2009, . Jeong Expires 27 April 2023 [Page 39] Internet-Draft IPWAVE Problem Statement October 2022 [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, . [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, . [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, September 2010, . [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, DOI 10.17487/RFC6130, April 2011, . [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, DOI 10.17487/RFC6250, May 2011, . [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, DOI 10.17487/RFC6583, March 2012, . [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address Validation Improvement (SAVI) Threat Scope", RFC 6959, DOI 10.17487/RFC6959, May 2013, . Jeong Expires 27 April 2023 [Page 40] Internet-Draft IPWAVE Problem Statement October 2022 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, . [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, DOI 10.17487/RFC7181, April 2014, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, . [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and CJ. Bernardos, "Distributed Mobility Management: Current Practices and Gap Analysis", RFC 7429, DOI 10.17487/RFC7429, January 2015, . [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, DOI 10.17487/RFC7427, January 2015, . [RFC7466] Dearlove, C. and T. Clausen, "An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 7466, DOI 10.17487/RFC7466, March 2015, . [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . [RFC8002] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 8002, DOI 10.17487/RFC8002, October 2016, . Jeong Expires 27 April 2023 [Page 41] Internet-Draft IPWAVE Problem Statement October 2022 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, . [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, DOI 10.17487/RFC8175, June 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, . [RFC8629] Cheng, B. and L. Berger, Ed., "Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension", RFC 8629, DOI 10.17487/RFC8629, July 2019, . [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, . [RFC8757] Cheng, B. and L. Berger, Ed., "Dynamic Link Exchange Protocol (DLEP) Latency Range Extension", RFC 8757, DOI 10.17487/RFC8757, March 2020, . [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, . Jeong Expires 27 April 2023 [Page 42] Internet-Draft IPWAVE Problem Statement October 2022 [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 2020, . [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9119] Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC. Zúñiga, "Multicast Considerations over IEEE 802 Wireless Media", RFC 9119, DOI 10.17487/RFC9119, October 2021, . [I-D.ietf-intarea-ippl] Nordmark, E., "IP over Intentionally Partially Partitioned Links", Work in Progress, Internet-Draft, draft-ietf- intarea-ippl-00, 30 March 2017, . [I-D.ietf-lisp-rfc6830bis] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, "The Locator/ID Separation Protocol (LISP)", Work in Progress, Internet-Draft, draft-ietf-lisp- rfc6830bis-38, 7 May 2022, . [I-D.templin-6man-aero] Templin, F., "Automatic Extended Route Optimization (AERO)", Work in Progress, Internet-Draft, draft-templin- 6man-aero-63, 12 October 2022, . Jeong Expires 27 April 2023 [Page 43] Internet-Draft IPWAVE Problem Statement October 2022 [I-D.templin-6man-omni] Templin, F., "Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces", Work in Progress, Internet-Draft, draft-templin-6man-omni-74, 12 October 2022, . [I-D.templin-ipwave-uam-its] Fred Templin, L., "Urban Air Mobility Implications for Intelligent Transportation Systems", Work in Progress, Internet-Draft, draft-templin-ipwave-uam-its-04, 4 January 2021, . [I-D.templin-intarea-parcels] Templin, F., "IP Parcels", Work in Progress, Internet- Draft, draft-templin-intarea-parcels-16, 6 October 2022, . [I-D.ietf-dmm-fpc-cpdp] Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., Moses, D., and E. Charles Perkins, "Protocol for Forwarding Policy Configuration (FPC) in DMM", Work in Progress, Internet-Draft, draft-ietf-dmm-fpc-cpdp-14, 22 September 2020, . [I-D.thubert-6man-ipv6-over-wireless] Thubert, P., "IPv6 Neighbor Discovery on Wireless Networks", Work in Progress, Internet-Draft, draft- thubert-6man-ipv6-over-wireless-12, 11 October 2022, . [I-D.ietf-madinas-mac-address-randomization] Zúñiga, J. C., Bernardos, C. J., and A. Andersdotter, "MAC address randomization", Work in Progress, Internet-Draft, draft-ietf-madinas-mac-address-randomization-04, 22 October 2022, . [I-D.ietf-madinas-use-cases] Henry, J. and Y. Lee, "Randomized and Changing MAC Address Use Cases", Work in Progress, Internet-Draft, draft-ietf- madinas-use-cases-03, 6 October 2022, . Jeong Expires 27 April 2023 [Page 44] Internet-Draft IPWAVE Problem Statement October 2022 [I-D.jeong-ipwave-vehicular-neighbor-discovery] Jeong, J. P., Shen, Y. C., Kwon, J., and S. Cespedes, "Vehicular Neighbor Discovery for IP-Based Vehicular Networks", Work in Progress, Internet-Draft, draft-jeong- ipwave-vehicular-neighbor-discovery-14, 25 July 2022, . [I-D.jeong-ipwave-vehicular-mobility-management] Jeong, J. P., Mugabarigira, B. A., Shen, Y. C., and H. Jung, "Vehicular Mobility Management for IP-Based Vehicular Networks", Work in Progress, Internet-Draft, draft-jeong-ipwave-vehicular-mobility-management-08, 25 July 2022, . [I-D.jeong-ipwave-security-privacy] Jeong, J. P., Shen, Y. C., Jung, H., Park, J., and T. T. Oh, "Basic Support for Security and Privacy in IP-Based Vehicular Networks", Work in Progress, Internet-Draft, draft-jeong-ipwave-security-privacy-06, 25 July 2022, . [DSRC] ASTM International, "Standard Specification for Telecommunications and Information Exchange Between Roadside and Vehicle Systems - 5 GHz Band Dedicated Short Range Communications (DSRC) Medium Access Control (MAC) and Physical Layer (PHY) Specifications", ASTM E2213-03(2010), October 2010. [EU-2008-671-EC] European Union, "Commission Decision of 5 August 2008 on the Harmonised Use of Radio Spectrum in the 5875 - 5905 MHz Frequency Band for Safety-related Applications of Intelligent Transport Systems (ITS)", EU 2008/671/EC, August 2008. [IEEE-802.11p] "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 6: Wireless Access in Vehicular Environments", IEEE Std 802.11p-2010, June 2010. [IEEE-802.11-OCB] "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2016, December 2016. Jeong Expires 27 April 2023 [Page 45] Internet-Draft IPWAVE Problem Statement October 2022 [WAVE-1609.0] IEEE 1609 Working Group, "IEEE Guide for Wireless Access in Vehicular Environments (WAVE) - Architecture", IEEE Std 1609.0-2013, March 2014. [WAVE-1609.2] IEEE 1609 Working Group, "IEEE Standard for Wireless Access in Vehicular Environments - Security Services for Applications and Management Messages", IEEE Std 1609.2-2016, March 2016. [WAVE-1609.3] IEEE 1609 Working Group, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Networking Services", IEEE Std 1609.3-2016, April 2016. [WAVE-1609.4] IEEE 1609 Working Group, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Multi-Channel Operation", IEEE Std 1609.4-2016, March 2016. [ISO-ITS-IPv6] ISO/TC 204, "Intelligent Transport Systems - Communications Access for Land Mobiles (CALM) - IPv6 Networking", ISO 21210:2012, June 2012. [ISO-ITS-IPv6-AMD1] ISO/TC 204, "Intelligent Transport Systems - Communications Access for Land Mobiles (CALM) - IPv6 Networking - Amendment 1", ISO 21210:2012/AMD 1:2017, September 2017. [TS-23.285-3GPP] 3GPP, "Architecture Enhancements for V2X Services", 3GPP TS 23.285/Version 16.2.0, December 2019. [TR-22.886-3GPP] 3GPP, "Study on Enhancement of 3GPP Support for 5G V2X Services", 3GPP TR 22.886/Version 16.2.0, December 2018. [TS-23.287-3GPP] 3GPP, "Architecture Enhancements for 5G System (5GS) to Support Vehicle-to-Everything (V2X) Services", 3GPP TS 23.287/Version 16.2.0, March 2020. Jeong Expires 27 April 2023 [Page 46] Internet-Draft IPWAVE Problem Statement October 2022 [VIP-WAVE] Cespedes, S., Lu, N., and X. Shen, "VIP-WAVE: On the Feasibility of IP Communications in 802.11p Vehicular Networks", IEEE Transactions on Intelligent Transportation Systems, vol. 14, no. 1, March 2013. [Identity-Management] Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer Identities Management in ITS Stations", The 10th International Conference on ITS Telecommunications, November 2010. [SAINT] Jeong, J., Jeong, H., Lee, E., Oh, T., and D. Du, "SAINT: Self-Adaptive Interactive Navigation Tool for Cloud-Based Vehicular Traffic Optimization", IEEE Transactions on Vehicular Technology, Vol. 65, No. 6, June 2016. [SAINTplus] Shen, Y., Lee, J., Jeong, H., Jeong, J., Lee, E., and D. Du, "SAINT+: Self-Adaptive Interactive Navigation Tool+ for Emergency Service Delivery Optimization", IEEE Transactions on Intelligent Transportation Systems, June 2017. [SANA] Hwang, T. and J. Jeong, "SANA: Safety-Aware Navigation Application for Pedestrian Protection in Vehicular Networks", Springer Lecture Notes in Computer Science (LNCS), Vol. 9502, December 2015. [CASD] Shen, Y., Jeong, J., Oh, T., and S. Son, "CASD: A Framework of Context-Awareness Safety Driving in Vehicular Networks", International Workshop on Device Centric Cloud (DC2), March 2016. [CA-Cruise-Control] California Partners for Advanced Transportation Technology (PATH), "Cooperative Adaptive Cruise Control", Available: https://path.berkeley.edu/research/connected-and- automated-vehicles/cooperative-adaptive-cruise-control, 2022. [Truck-Platooning] California Partners for Advanced Transportation Technology (PATH), "Automated Truck Platooning", Available: https://path.berkeley.edu/research/connected-and- automated-vehicles/truck-platooning, 2022. Jeong Expires 27 April 2023 [Page 47] Internet-Draft IPWAVE Problem Statement October 2022 [FirstNet] U.S. National Telecommunications and Information Administration (NTIA), "First Responder Network Authority (FirstNet)", Available: https://www.firstnet.gov/, 2022. [PSCE] European Commission, "Public Safety Communications Europe (PSCE)", Available: https://www.psc-europe.eu/, 2022. [FirstNet-Report] First Responder Network Authority, "FY 2017: ANNUAL REPORT TO CONGRESS, Advancing Public Safety Broadband Communications", FirstNet FY 2017, December 2017. [SignalGuru] Koukoumidis, E., Peh, L., and M. Martonosi, "SignalGuru: Leveraging Mobile Phones for Collaborative Traffic Signal Schedule Advisory", ACM MobiSys, June 2011. [Fuel-Efficient] van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas, "Fuel-Efficient En Route Formation of Truck Platoons", IEEE Transactions on Intelligent Transportation Systems, January 2018. [Automotive-Sensing] Choi, J., Va, V., Gonzalez-Prelcic, N., Daniels, R., R. Bhat, C., and R. W. Heath, "Millimeter-Wave Vehicular Communication to Support Massive Automotive Sensing", IEEE Communications Magazine, December 2016. [NHTSA-ACAS-Report] National Highway Traffic Safety Administration (NHTSA), "Final Report of Automotive Collision Avoidance Systems (ACAS) Program", DOT HS 809 080, August 2000. [CBDN] Kim, J., Kim, S., Jeong, J., Kim, H., Park, J., and T. Kim, "CBDN: Cloud-Based Drone Navigation for Efficient Battery Charging in Drone Networks", IEEE Transactions on Intelligent Transportation Systems, November 2019. [LIFS] Wang, J., Xiong, J., Jiang, H., Jamieson, K., Chen, X., Fang, D., and C. Wang, "Low Human-Effort, Device-Free Localization with Fine-Grained Subcarrier Information", IEEE Transactions on Mobile Computing, November 2018. [DFC] Jeong, J., Shen, Y., Kim, S., Choe, D., Lee, K., and Y. Kim, "DFC: Device-free human counting through WiFi fine- grained subcarrier information", IET Communications, January 2021. Jeong Expires 27 April 2023 [Page 48] Internet-Draft IPWAVE Problem Statement October 2022 [In-Car-Network] Lim, H., Volker, L., and D. Herrscher, "Challenges in a Future IP/Ethernet-based In-Car Network for Real-Time Applications", ACM/EDAC/IEEE Design Automation Conference (DAC), June 2011. [Scrambler-Attack] Bloessl, B., Sommer, C., Dressier, F., and D. Eckhoff, "The Scrambler Attack: A Robust Physical Layer Attack on Location Privacy in Vehicular Networks", IEEE 2015 International Conference on Computing, Networking and Communications (ICNC), February 2015. [Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash System", URL: https://bitcoin.org/bitcoin.pdf, May 2009. [Vehicular-BlockChain] Dorri, A., Steger, M., Kanhere, S., and R. Jurdak, "BlockChain: A Distributed Solution to Automotive Security and Privacy", IEEE Communications Magazine, Vol. 55, No. 12, December 2017. [FCC-ITS-Modification] Federal Communications Commission, "Use of the 5.850-5.925 GHz Band, First Report and Order, Further Notice of Proposed Rulemaking, and Order of Proposed Modification, FCC 19-138", Available: https://www.fcc.gov/document/fcc- modernizes-59-ghz-band-improve-wi-fi-and-automotive- safety-0, November 2020. [Fake-Identifier-Attack] ABC News, "German man fools Google Maps' traffic algorithm", Available: https://www.abc.net.au/news/2020-02-04/man- creates-fake-traffic-jam-on-google-maps-by-carting- 99-phones/11929136, February 2020. [Google-Maps] Google, "Google Maps", Available: https://www.google.com/maps/, 2022. [Waze] Google, "Google Maps", Available: https://www.waze.com/, 2022. Jeong Expires 27 April 2023 [Page 49] Internet-Draft IPWAVE Problem Statement October 2022 Appendix A. Support of Multiple Radio Technologies for V2V Vehicular networks may consist of multiple radio technologies such as DSRC and 5G V2X. Although a Layer-2 solution can provide support for multihop communications in vehicular networks, the scalability issue related to multihop forwarding still remains when vehicles need to disseminate or forward packets toward multihop-away destinations. In addition, the IPv6-based approach for V2V as a network layer protocol can accommodate multiple radio technologies as MAC protocols, such as DSRC and 5G V2X. Therefore, the existing IPv6 protocol can be augmented through the addition of a virtual interface (e.g., OMNI [I-D.templin-6man-omni] and DLEP [RFC8175]) and/or protocol changes in order to support both wireless single-hop/multihop V2V communications and multiple radio technologies in vehicular networks. In such a way, vehicles can communicate with each other by V2V communications to share either an emergency situation or road hazard information in a highway having multiple kinds of radio technologies. Appendix B. Support of Multihop V2X Networking The multihop V2X networking can be supported by RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) [RFC6550] and Overlay Multilink Network Interface (OMNI) [I-D.templin-6man-omni] with AERO [I-D.templin-6man-aero] . RPL defines an IPv6 routing protocol for low-power and lossy networks (LLN), mostly designed for home automation routing, building automation routing, industrial routing, and urban LLN routing. It uses a Destination-Oriented Directed Acyclic Graph (DODAG) to construct routing paths for hosts (e.g., IoT devices) in a network. The DODAG uses an objective function (OF) for route selection and optimization within the network. A user can use different routing metrics to define an OF for a specific scenario. RPL supports multipoint-to-point, point-to-multipoint, and point-to-point traffic, and the major traffic flow is the multipoint-to-point traffic. For example, in a highway scenario, a vehicle may not access an IP-RSU directly because of the distance of the DSRC coverage (up to 1 km). In this case, the RPL can be extended to support a multihop V2I since a vehicle can take advantage of other vehicles as relay nodes to reach the IP-RSU. Also, RPL can be extended to support both multihop V2V and V2X in the similar way. Jeong Expires 27 April 2023 [Page 50] Internet-Draft IPWAVE Problem Statement October 2022 RPL is primarily designed to minimize the control plane activity, which is the relative amount of routing protocol exchanges versus data traffic; this approach is beneficial for situations where the power and bandwidth are scarce (e.g., an IoT LLN where RPL is typically used today), but also in situations of high relative mobility between the nodes in the network (also known as swarming, e.g., within a variable set of vehicles with a similar global motion, or a variable set of drones flying toward the same direction). To reduce the routing exchanges, RPL leverages a Distance Vector (DV) approach, which does not need a global knowledge of the topology, and only optimizes the routes to and from the root, allowing Peer-to-Peer (P2P) paths to be stretched. Although RPL installs its routes proactively, it only maintains them lazily, that is, in reaction to actual traffic, or as a slow background activity. Additionally, RPL leverages the concept of an objective function (called OF), which allows adapting the activity of the routing protocol to use cases, e.g., type, speed, and quality of the radios. RPL does not need converge, and provides connectivity to most nodes most of the time. The default route toward the root is maintained aggressively and may change while a packet progresses without causing loops, so the packet will still reach the root. There are two modes for routing in RPL such as non-storing mode and storing mode. In non-storing mode, a node inside the mesh/swarm that changes its point(s) of attachment to the graph informs the root with a single unicast packet flowing along the default route, and the connectivity is restored immediately; this mode is preferable for use cases where Internet connectivity is dominant. On the other hand, in storing mode, the routing stretch is reduced, for a better P2P connectivity, while the Internet connectivity is restored more slowly, during the time for the DV operation to operate hop-by-hop. While an RPL topology can quickly scale up and down and fits the needs of mobility of vehicles, the total performance of the system will also depend on how quickly a node can form an address, join the mesh (including Authentication, Authorization, and Accounting (AAA)), and manage its global mobility to become reachable from another node outside the mesh. OMNI defines a protocol for the transmission of IPv6 packets over Overlay Multilink Network Interfaces that are virtual interfaces governing multiple physical network interfaces. OMNI supports multihop V2V communication between vehicles in multiple forwarding hops via intermediate vehicles with OMNI links. It also supports multihop V2I communication between a vehicle and an infrastructure access point by multihop V2V communication. The OMNI interface supports an NBMA link model where multihop V2V and V2I communications use each mobile node's ULAs without need for any DAD or MLD Messaging. Jeong Expires 27 April 2023 [Page 51] Internet-Draft IPWAVE Problem Statement October 2022 In OMNI protocol, an OMNI virtual interface can have a ULA [RFC4193] indeed, but wireless physical interfaces associated with the OMNI virtual interface are using any prefix. The ULA supports both V2V and V2I multihop forwarding within the vehicular network (e.g., via a VANET routing protocol) while each vehicle can communicate with Internet correspondents using global IPv6 addresses via OMNI interface encapsulation over the wireless interface. For the control traffic overhead for running both vehicular ND and a VANET routing protocol, the AERO/OMNI approach may avoid this issue by using MANET routing protocols only (i.e., no multicast of IPv6 ND messaging) in the wireless underlay network while applying efficient unicast IPv6 ND messaging in the OMNI overlay on an as-needed basis for router discovery and NUD. This greatly reduces the overhead for VANET-wide multicasting while providing agile accommodation for dynamic topology changes. Appendix C. Support of Mobility Management for V2I The seamless application communication between two vehicles or between a vehicle and an infrastructure node requires mobility management in vehicular networks. The mobility management schemes include a host-based mobility scheme, network-based mobility scheme, and software-defined networking scheme. In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a role of a home agent. On the other hand, in the network-based mobility scheme (e.g., PMIPv6, an MA plays a role of a mobility management controller such as a Local Mobility Anchor (LMA) in PMIPv6, which also serves vehicles as a home agent, and an IP-RSU plays a role of an access router such as a Mobile Access Gateway (MAG) in PMIPv6 [RFC5213]. The host-based mobility scheme needs client functionality in IPv6 stack of a vehicle as a mobile node for mobility signaling message exchange between the vehicle and home agent. On the other hand, the network-based mobility scheme does not need such a client functionality for a vehicle because the network infrastructure node (e.g., MAG in PMIPv6) as a proxy mobility agent handles the mobility signaling message exchange with the home agent (e.g., LMA in PMIPv6) for the sake of the vehicle. There are a scalability issue and a route optimization issue in the network-based mobility scheme (e.g., PMIPv6) when an MA covers a large vehicular network governing many IP-RSUs. In this case, a distributed mobility scheme (e.g., DMM [RFC7429]) can mitigate the scalability issue by distributing multiple MAs in the vehicular network such that they are positioned closer to vehicles for route optimization and bottleneck mitigation in a central MA in the network-based mobility scheme. All these mobility approaches (i.e., Jeong Expires 27 April 2023 [Page 52] Internet-Draft IPWAVE Problem Statement October 2022 a host-based mobility scheme, network-based mobility scheme, and distributed mobility scheme) and a hybrid approach of a combination of them need to provide an efficient mobility service to vehicles moving fast and moving along with the relatively predictable trajectories along the roadways. In vehicular networks, the control plane can be separated from the data plane for efficient mobility management and data forwarding by using the concept of Software-Defined Networking (SDN) [RFC7149][I-D.ietf-dmm-fpc-cpdp]. Note that Forwarding Policy Configuration (FPC) in [I-D.ietf-dmm-fpc-cpdp], which is a flexible mobility management system, can manage the separation of data-plane and control-plane in DMM. In SDN, the control plane and data plane are separated for the efficient management of forwarding elements (e.g., switches and routers) where an SDN controller configures the forwarding elements in a centralized way and they perform packet forwarding according to their forwarding tables that are configured by the SDN controller. An MA as an SDN controller needs to efficiently configure and monitor its IP-RSUs and vehicles for mobility management, location management, and security services. Appendix D. Support of MTU Diversity for IP-based Vehicular Networks The wireless and/or wired-line links in paths between both mobile nodes and fixed network correspondents may configure a variety of Maximum Transmission Units (MTUs), where all IPv6 links are required to support a minimum MTU of 1280 octets and may support larger MTUs. Unfortunately, determining the path MTU (i.e., the minimum link MTU in the path) has proven to be inefficient and unreliable due to the uncertain nature of the loss-oriented ICMPv6 messaging service used for path MTU discovery. Recent developments have produced a more reliable path MTU determination service for TCP [RFC4821] and UDP [RFC8899] however the MTUs discovered are always limited by the most restrictive link MTU in the path (often 1500 octets or smaller). The AERO/OMNI service addresses the MTU issue by introducing a new layer in the Internet architecture known as the "OMNI Adaptation Layer (OAL)". The OAL allows end systems that configure an OMNI interface to utilize a full 65535 octet MTU by leveraging the IPv6 fragmentation and reassembly service during encapsulation to produce fragment sizes that are assured of traversing the path without loss due to a size restriction. (This allows end systems to send packets that are often much larger than the actual path MTU.) Performance studies over the course of many decades have proven that applications will see greater performance by sending smaller numbers of large packets (as opposed to larger numbers of small packets) even if fragmentation is needed. The OAL further supports even larger Jeong Expires 27 April 2023 [Page 53] Internet-Draft IPWAVE Problem Statement October 2022 packet sizes through the IP Parcels construct [I-D.templin-intarea-parcels] which provides "packets-in-packet" encapsulation for a total size up to 4MB. Together, the OAL and IP Parcels will provide a revolutionary new capability for greater efficiency in both mobile and fixed networks. On the other hand, due to the high dynamics of vehicular networks, a high packet loss may not be able to be avoided. The high packet loss on IP parcels can simultaneously cause multiple TCP sessions to experience packet re- transmissions, session time-out, or re-establishment of the sessions. Other protocols such as MPTCP and QUIC may also experience the similar issue. A mechanism for mitigating this issue in OAL and IP Parcels should be considered. Appendix E. Acknowledgments This work was supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based Security Intelligence Technology Development for the Customized Security Service Provisioning). This work was supported in part by the MSIT, Korea, under the ITRC (Information Technology Research Center) support program (IITP- 2022-2017-0-01633) supervised by the IITP. This work was supported in part by the IITP (2020-0-00395-003, Standard Development of Blockchain based Network Management Automation Technology). This work was supported in part by the French research project DataTweet (ANR-13-INFR-0008) and in part by the HIGHTS project funded by the European Commission I (636537-H2020). This work was supported in part by the Cisco University Research Program Fund, Grant # 2019-199458 (3696), and by ANID Chile Basal Project FB0008. Appendix F. Contributors This document is a group work of IPWAVE working group, greatly benefiting from inputs and texts by Rex Buddenberg (Naval Postgraduate School), Thierry Ernst (YoGoKo), Bokor Laszlo (Budapest University of Technology and Economics), Jose Santa Lozanoi (Universidad of Murcia), Richard Roy (MIT), Francois Simon (Pilot), Sri Gundavelli (Cisco), Erik Nordmark, Dirk von Hugo (Deutsche Telekom), Pascal Thubert (Cisco), Carlos Bernardos (UC3M), Russ Housley (Vigil Security), Suresh Krishnan (Kaloom), Nancy Cam-Winget (Cisco), Fred L. Templin (The Boeing Company), Jung-Soo Park (ETRI), Jeong Expires 27 April 2023 [Page 54] Internet-Draft IPWAVE Problem Statement October 2022 Zeungil (Ben) Kim (Hyundai Motors), Kyoungjae Sun (Soongsil University), Zhiwei Yan (CNNIC), YongJoon Joe (LSware), Peter E. Yee (Akayla), and Erik Kline. The authors sincerely appreciate their contributions. The following are co-authors of this document: Nabil Benamar - Department of Computer Sciences, High School of Technology of Meknes, Moulay Ismail University, Morocco, Phone: +212 6 70 83 22 36, Email: benamar73@gmail.com Sandra Cespedes - NIC Chile Research Labs, Universidad de Chile, Av. Blanco Encalada 1975, Santiago, Chile, Phone: +56 2 29784093, Email: scespede@niclabs.cl Jerome Haerri - Communication Systems Department, EURECOM, Sophia-Antipolis, France, Phone: +33 4 93 00 81 34, Email: jerome.haerri@eurecom.fr Dapeng Liu - Alibaba, Beijing, Beijing 100022, China, Phone: +86 13911788933, Email: max.ldp@alibaba-inc.com Tae (Tom) Oh - Department of Information Sciences and Technologies, Rochester Institute of Technology, One Lomb Memorial Drive, Rochester, NY 14623-5603, USA, Phone: +1 585 475 7642, Email: Tom.Oh@rit.edu Charles E. Perkins - Futurewei Inc., 2330 Central Expressway, Santa Clara, CA 95050, USA, Phone: +1 408 330 4586, Email: charliep@computer.org Alexandre Petrescu - CEA, LIST, CEA Saclay, Gif-sur-Yvette, Ile-de-France 91190, France, Phone: +33169089223, Email: Alexandre.Petrescu@cea.fr Yiwen Chris Shen - Jeong Expires 27 April 2023 [Page 55] Internet-Draft IPWAVE Problem Statement October 2022 Department of Computer Science & Engineering, Sungkyunkwan University, 2066 Seobu-Ro, Jangan-Gu, Suwon, Gyeonggi-Do 16419, Republic of Korea, Phone: +82 31 299 4106, Fax: +82 31 290 7996, Email: chrisshen@skku.edu, URI: https://chrisshen.github.io Michelle Wetterwald - FBConsulting, 21, Route de Luxembourg, Wasserbillig, Luxembourg L-6633, Luxembourg, Email: Michelle.Wetterwald@gmail.com Author's Address Jaehoon Paul Jeong (editor) Department of Computer Science and Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4957 Email: pauljeong@skku.edu URI: http://iotlab.skku.edu/people-jaehoon-jeong.php Jeong Expires 27 April 2023 [Page 56] ./draft-ietf-ace-mqtt-tls-profile-17.txt0000644000764400076440000031477414216561450017651 0ustar iustiniustin ACE Working Group C.S. Sengul Internet-Draft Brunel University Intended status: Standards Track A.K. Kirby Expires: 24 September 2022 Oxbotica 23 March 2022 Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication and Authorization for Constrained Environments (ACE) Framework draft-ietf-ace-mqtt-tls-profile-17 Abstract This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) framework to enable authorization in a Message Queuing Telemetry Transport (MQTT)-based publish-subscribe messaging system. Proof-of-possession keys, bound to OAuth2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 September 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Sengul & Kirby Expires 24 September 2022 [Page 1] Internet-Draft MQTT-TLS profile of ACE March 2022 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. ACE-Related Terminology . . . . . . . . . . . . . . . . . 4 1.3. MQTT-Related Terminology . . . . . . . . . . . . . . . . 5 2. Authorizing Connection Requests . . . . . . . . . . . . . . . 9 2.1. Client Token Request to the Authorization Server (AS) . . 10 2.2. Client Connection Request to the Broker (C) . . . . . . . 11 2.2.1. Overview of Client-RS Authentication Methods over TLS and MQTT . . . . . . . . . . . . . . . . . . . . . . 12 2.2.2. authz-info: The Authorization Information Topic . . . 13 2.2.3. Client Authentication over TLS . . . . . . . . . . . 14 2.2.3.1. Raw Public Key Mode . . . . . . . . . . . . . . . 14 2.2.3.2. Pre-Shared Key Mode . . . . . . . . . . . . . . . 15 2.2.4. Client Authentication over MQTT . . . . . . . . . . . 15 2.2.4.1. Transporting the Access Token Inside the MQTT CONNECT . . . . . . . . . . . . . . . . . . . . . . 15 2.2.4.2. Authentication Using AUTH Property . . . . . . . 18 2.2.5. Broker Token Validation . . . . . . . . . . . . . . . 21 2.3. Token Scope and Authorization . . . . . . . . . . . . . . 22 2.4. Broker Response to Client Connection Request . . . . . . 23 2.4.1. Unauthorized Request and the Optional Authorization Server Discovery . . . . . . . . . . . . . . . . . . 23 2.4.2. Authorization Success . . . . . . . . . . . . . . . . 24 3. Authorizing PUBLISH and SUBSCRIBE Packets . . . . . . . . . . 24 3.1. PUBLISH Packets from the Publisher Client to the Broker . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2. PUBLISH Packets from the Broker to the Subscriber Clients . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3. Authorizing SUBSCRIBE Packets . . . . . . . . . . . . . . 25 4. Token Expiration, Update, and Reauthentication . . . . . . . 26 5. Handling Disconnections and Retained Messages . . . . . . . . 27 6. Reduced Protocol Interactions for MQTT v3.1.1 . . . . . . . . 28 6.1. Token Transport . . . . . . . . . . . . . . . . . . . . . 28 6.2. Handling Authorization Errors . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 7.1. TLS Exporter Label Registration . . . . . . . . . . . . . 31 7.2. Media Type Registration . . . . . . . . . . . . . . . . . 31 7.3. ACE OAuth Profile Registration . . . . . . . . . . . . . 32 7.4. AIF . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 Sengul & Kirby Expires 24 September 2022 [Page 2] Internet-Draft MQTT-TLS profile of ACE March 2022 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.2. Informative References . . . . . . . . . . . . . . . . . 38 Appendix A. Checklist for profile requirements . . . . . . . . . 40 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 40 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 1. Introduction This document specifies a profile for the ACE framework [I-D.ietf-ace-oauth-authz]. In this profile, Clients and Servers (Brokers) use MQTT to exchange Application Messages. The protocol relies on TLS for communication security between entities. The MQTT protocol interactions are described based on the MQTT v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5]. Since it is expected that MQTT deployments will continue to support MQTT v3.1.1 Clients, this document also describes a reduced set of protocol interactions for MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard-v3.1.1]. However, MQTT v5.0 is the RECOMMENDED version as it works more naturally with ACE-style authentication and authorization. MQTT is a publish-subscribe protocol, and after connecting to the MQTT Server (Broker), a Client can publish and subscribe to multiple topics. The Broker, which acts as the Resource Server (RS), is responsible for distributing messages published by the publishers to their subscribers. In the rest of the document, the terms "RS", "MQTT Server" and "Broker" are used interchangeably. Messages are published under a Topic Name, and subscribers subscribe to the Topic Names to receive the corresponding messages. The Broker uses the Topic Name in a published message to determine which subscribers to relay the messages to. In this document, topics, more specifically, Topic Names, are treated as resources. The Clients are assumed to have identified the publish/subscribe topics of interest out-of-band (topic discovery is not a feature of the MQTT protocol). A Resource Owner can pre-configure policies at the Authorization Server (AS) that give Clients publish or subscribe permissions to different topics. Clients prove their permission to publish and subscribe to topics hosted on an MQTT Broker using an access token, bound to a proof-of- possession (PoP) key. This document describes how to authorize the following exchanges between the Clients and the Broker. * Connection requests from the Clients to the Broker * Publish requests from the Clients to the Broker and from the Broker to the Clients Sengul & Kirby Expires 24 September 2022 [Page 3] Internet-Draft MQTT-TLS profile of ACE March 2022 * Subscribe requests from the Clients to the Broker Clients use the MQTT PUBLISH packet to publish to a topic. The mechanisms specified in this document do not protect the payload of the PUBLISH packet from the Broker. Hence, the payload is not signed or encrypted specifically for the subscribers. This functionality may be implemented using the proposal outlined in the ACE Pub-Sub Profile [I-D.ietf-ace-pubsub-profile]. To provide communication confidentiality and Broker authentication to the MQTT Clients, TLS is used, and TLS 1.3 [RFC8446] is RECOMMENDED. This document makes the same assumptions as Section 4 of the ACE framework [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with the AS and setting up the keying material. While the Client-Broker exchanges are only over MQTT, the required Client- AS and RS-AS interactions are described for HTTPS-based communication [I-D.ietf-httpbis-semantics], using "application/ace+json" content type, and unless otherwise specified, using JSON encoding. The token MAY be an opaque reference to authorization information or JSON Web Token (JWT) [RFC7519]. For JWTs, this document follows [RFC7800] for PoP semantics for JWTs, and the mechanisms for providing and verifying PoP are detailed in Section 2.2. The Client-AS and RS-AS exchanges MAY also use protocols other than HTTP, e.g., Constrained Application Protocol (CoAP) [RFC7252] or MQTT. It is recommended that TLS is used to secure these communication channels between Client-AS and RS-AS. To reduce the protocol memory and bandwidth requirements, implementations MAY also use "application/ace+cbor" content type, and CBOR encoding [RFC8949], and CBOR Web Token (CWT) [RFC8392] and associated PoP semantics. For more information, see Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) [RFC8747]. A JWT token uses JOSE, while a CWT token uses COSE [RFC8152] for security protection. 1.1. Requirements Language The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174], when, and only when, they appear in all capitals, as shown here. 1.2. ACE-Related Terminology Certain security-related terms such as "authentication", "authorization", "confidentiality", "(data) integrity", "message authentication code", and "verify" are taken from [RFC4949]. Sengul & Kirby Expires 24 September 2022 [Page 4] Internet-Draft MQTT-TLS profile of ACE March 2022 The terminology for entities in the architecture is defined in OAuth 2.0 [RFC6749] such as "Client" (C), "Resource Server" (RS) and "Authorization Server" (AS). The term "resource" is used to refer to an MQTT Topic Name, which is defined in Section 1.3. Hence, the "Resource Owner" is any entity that can authoritatively speak for the topic. This document also defines a Client Authorization Server for Clients that are not able to support HTTP. Client Authorization Server (CAS) An entity that prepares and endorses authentication and authorization data for a Client, and communicates to the AS using HTTPS. 1.3. MQTT-Related Terminology The document describes message exchanges as MQTT protocol interactions. The Clients are MQTT Clients, which connect to the Broker to publish and subscribe to Application Messages, labelled with their topics. For additional information, please refer to the MQTT v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard-v3.1.1]. Broker The Server in MQTT. It acts as an intermediary between the Clients that publish Application Messages and the Clients that made Subscriptions. The Broker acts as the Resource Server for the Clients. Client A device or program that uses MQTT. Network Connection A construct provided by the underlying transport protocol that is being used by MQTT. It connects the Client to the Server. It provides the means to send an ordered, lossless, stream of bytes in both directions. This document uses TLS as tranport protocol. Session A stateful interaction between a Client and a Broker. Some Sessions last only as long as the Network Connection; others can span multiple Network Connections. Application Message The data carried by the MQTT protocol. The data has an associated Quality-of-Service (QoS) level and Topic Name. Sengul & Kirby Expires 24 September 2022 [Page 5] Internet-Draft MQTT-TLS profile of ACE March 2022 MQTT Control Packet The MQTT protocol operates by exchanging a series of MQTT Control packets. Each packet is composed of a Fixed Header, a Variable Header (depending on the control packet type), and a Payload. UTF-8 encoded string A string prefixed with a two-byte length field that gives the number of bytes in a UTF-8 encoded string itself. Unless stated otherwise, all UTF-8 encoded strings can have any length in the range 0 to 65535 bytes. Binary Data Binary Data is represented by a two-byte length field which indicates the number of data bytes, followed by that number of bytes. Thus, the length of Binary Data is limited to the range of 0 to 65535 Bytes. Variable Byte Integer Variable Byte Integer is encoded using an encoding scheme that uses a single byte for values up to 127. For larger values, the least significant seven bits of each byte encode the data, and the most significant bit is used to indicate whether there are bytes following in the representation. Thus, each byte encodes 128 values and a "continuation bit". The maximum number of bytes in the Variable Byte Integer field is four. QoS level The level of assurance for the delivery of an Application Message. The QoS level can be 0-2, where 0 indicates "At most once delivery", 1 "At least once delivery", and 2 "Exactly once delivery". Property The last field of the Variable Header is a set of properties for several MQTT control packets (e.g. CONNECT, CONNACK). A Property consists of an Identifier that defines its usage and data type, followed by a value. The Identifier is encoded as a Variable Byte Integer. For example, the "Authentication Data" property uses the Identifier 22. Topic Name The label attached to an Application Message, which is matched to a Subscription. Sengul & Kirby Expires 24 September 2022 [Page 6] Internet-Draft MQTT-TLS profile of ACE March 2022 Subscription A Subscription comprises a Topic Filter and a maximum QoS. A Subscription is associated with a single session. Topic Filter An expression that indicates interest in one or more Topic Names. Topic Filters may include wildcards. MQTT sends various control packets across a Network Connection. The following is not an exhaustive list, and the control packets that are not relevant for authorization are not explained. These include, for instance, the PUBREL and PUBCOMP packets used in the 4-step handshake required for QoS level 2. CONNECT Client request to connect to the Broker. This is the first packet sent by a Client. CONNACK The Broker connection acknowledgment. CONNACK packets contain return codes indicating either a success or an error state in response to a Client's CONNECT packet. AUTH Authentication Exchange. An AUTH control packet is sent from the Client to the Broker or from the Broker to the Client as part of an extended authentication exchange. AUTH Properties include Authentication Method and Authentication Data. The Authentication Method is set in the CONNECT packet, and consequent AUTH packets follow the same Authentication Method. The contents of the Authentication Data are defined by the Authentication Method. PUBLISH Publish request sent from a publishing Client to the Broker, or from the Broker to a subscribing Client. PUBACK Response to a PUBLISH request with QoS level 1. A PUBACK can be sent from the Broker to a Client or from a Client to the Broker. PUBREC Response to PUBLISH request with QoS level 2. PUBREC can be sent from the Broker to a Client or from a Client to the Broker. Sengul & Kirby Expires 24 September 2022 [Page 7] Internet-Draft MQTT-TLS profile of ACE March 2022 SUBSCRIBE Subscribe request sent from a Client. SUBACK Subscribe acknowledgment from the Broker to the Client. PINGREQ A ping request sent from a Client to the Broker. It signals to the Broker that the Client is alive and is used to confirm that the Broker is also alive. The "Keep Alive" period is set in the CONNECT packet. PINGRESP Response sent by the Broker to the Client in response to PINGREQ. It indicates the Broker is alive. DISCONNECT The DISCONNECT packet is the final MQTT Control Packet sent from the Client or the Broker. It indicates the reason why the Network Connection is being closed. If the Network Connection is closed without the Client first sending a DISCONNECT packet with Reason Code 0x00 (Normal disconnection) and the Connection has a Will Message, the Will Message is published. Will If the Network Connection is not closed normally, the Broker sends a last Will message for the Client if the Client provided one in its CONNECT packet. Situations in which the Will Message is published include, but are not limited to: * An I/O error or network failure detected by the Broker. * The Client fails to communicate within the Keep Alive period. * The Client closes the Network Connection without first sending a DISCONNECT packet with a Reason Code 0x00 (Normal disconnection). * The Broker closes the Network Connection without first receiving a DISCONNECT packet with a Reason Code 0x00 (Normal disconnection). If the Will Flag is set in the CONNECT flags, then the payload of the CONNECT packet includes information about the Will. The information consists of the Will Properties, Will Topic, and Will Payload fields. Sengul & Kirby Expires 24 September 2022 [Page 8] Internet-Draft MQTT-TLS profile of ACE March 2022 2. Authorizing Connection Requests This section specifies how Client connections are authorized by the AS and verified by the MQTT Broker. Figure 1 shows the basic protocol flow during connection setup. The token request and response use the token endpoint at the AS, specified for HTTP-based interactions in Section 5.8 of the ACE framework [I-D.ietf-ace-oauth-authz]. Steps (D) and (E) are optional and use the introspection endpoint specified in Section 5.9 of the ACE framework. The discussion in this document assumes that the Client and the Broker use HTTPS to communicate with the AS via these endpoints. The Client and the Broker use MQTT to communicate between them. The C-AS and Broker-AS communication MAY be implemented using protocols other than HTTPS, e.g. CoAP or MQTT. Whatever protocol is used for C-AS and Broker-AS communications MUST provide mutual authentication, confidentiality protection, and integrity protection. If the Client is resource-constrained or does not support HTTPS, a separate Client Authorization Server may carry out the token request on behalf of the Client (Figure 1 (A) and (B)), and later, onboard the Client with the token. The interactions between a Client and its Client Authorization Server for token onboarding and support for MQTT-based token requests at the AS are out of the scope of this document. Sengul & Kirby Expires 24 September 2022 [Page 9] Internet-Draft MQTT-TLS profile of ACE March 2022 +---------------------+ | Client | | | +---(A) Token request--| Client - | | | Authorization | | +-(B) Access token-> Server Interface | | | | (HTTPS) | | | |_____________________| | | | | +--v-------------+ | Pub/Sub Interface | | Authorization | | (MQTT over TLS) | | Server | +-----------^---------+ |________________| | | | ^ (C)Connection (F)Connection | | request + response | | access token | | | | | | | +---v--------------+ | | | Broker | | | | (MQTT over TLS) | | | |__________________| | +(D)Introspection-| | | request (optional) | RS-AS interface | | | (HTTPS) | +-(E)Introspection---->|__________________| response (optional) Figure 1: Connection Setup 2.1. Client Token Request to the Authorization Server (AS) The first step in the protocol flow (Figure 1 (A)) is the token acquisition by the Client from the AS. The Client and the AS MUST perform mutual authentication. The Client requests an access token from the AS as described in Section 5.8.1 of the ACE framework [I-D.ietf-ace-oauth-authz]. The document follows the procedures defined in Section 3.2.1 of the DTLS profile [I-D.ietf-ace-dtls-authorize] for RPK (Raw Public Keys [RFC7250]), and in Section 3.3.1 of the same document for PSK (Pre-Shared Keys). However, the content type of the request is set to "application/ ace+json", and the AS uses JSON in the payload of its responses to the Client and the RS. As explained earlier, implementations MAY also use "application/ace+cbor" content type. Sengul & Kirby Expires 24 September 2022 [Page 10] Internet-Draft MQTT-TLS profile of ACE March 2022 On receipt of the token request, the AS verifies the request. If the AS successfully verifies the access token request and authorizes the Client for the indicated audience (i.e., RS) and scopes (i.e., publish/subscribe permissions over topics as described in Section 2.3), the AS issues an access token (Figure 1 (B)). The response includes the parameters described in Section 5.8.2 of the ACE framework [I-D.ietf-ace-oauth-authz]. For RPK, the parameters are as described in Section 3.2.1 of the DTLS profile [I-D.ietf-ace-dtls-authorize]. For PSK, the document follows Section 3.3.1 of the DTLS profile [I-D.ietf-ace-dtls-authorize]. In both cases, if the response contains an "ace_profile" parameter, this parameter is set to "mqtt_tls". The returned token is a Proof-of- Possession (PoP) token by default. This document follows [RFC7800] for PoP semantics for JWTs (CWTs MAY also be used). The AS includes a "cnf" (confirmation) parameter in the PoP token, to declare that the Client possesses a particular key and RS can cryptographically confirm that the Client has possession of that key, as described in [I-D.ietf-ace-oauth-params]. Note that the contents of the web tokens (including the "cnf" parameter) are to be consumed by the RS and not the Client (the Client obtains the key information in a different manner). The RPK case is handled as described in Section 3.2.1 of the DTLS profile [I-D.ietf-ace-dtls-authorize]. For the PSK case, the referenced procedures apply, with the following exceptions to accommodate JWT and JOSE use. In this case, the AS adds a "cnf" parameter to the access information carrying a JWK (JSON Web Key) [RFC7517] object that contains either the symmetric key itself or a key identifier that can be used by the RS to determine the secret key it shares with the Client. The JWT is created as explained in Section 7 of [RFC7519], and the JWT MUST include JWE [RFC7516]. If CWT/COSE is used this information MUST be inside the "COSE_Key" object, and MUST be encrypted using a "COSE_Encrypt0" structure. The AS returns error responses for JSON-based interactions following Section 5.2 of [RFC6749]. When CBOR is used, the interactions MUST implement Section 5.8.3 of the ACE framework [I-D.ietf-ace-oauth-authz]. 2.2. Client Connection Request to the Broker (C) Sengul & Kirby Expires 24 September 2022 [Page 11] Internet-Draft MQTT-TLS profile of ACE March 2022 2.2.1. Overview of Client-RS Authentication Methods over TLS and MQTT Unless the Client publishes and subscribes to only public topics, the Client and the Broker MUST perform mutual authentication. The Client MUST authenticate to the Broker either over MQTT or TLS before performing any other action. For MQTT, the options are "None" and "ace". For TLS, the options are "Anon" for an anonymous client, and "Known(RPK/PSK)" for RPK and PSK, respectively. The "None" and "Anon" options do not provide client authentication but can be used either during authentication or in combination with authentication at the other layer. When the Client uses TLS:Anon,MQTT:None, the Client can only publish or subscribe to public topics. Thus, the client authentication procedures involve the following possible combinations: * TLS:Anon,MQTT:None: This option is used only for the topics that do not require authorization, including the "authz-info" topic. Publishing to the "authz-info" topic is described in Section 2.2.2. * TLS:Anon,MQTT:ace: The token is transported inside the CONNECT packet and MUST be validated using one of the methods described in Section 2.2.2. This option also supports a tokenless connection request for AS discovery. As per the ACE framework [I-D.ietf-ace-oauth-authz], a separate step is needed to determine whether the discovered AS URI is authorized to act as an AS. * TLS:Known(RPK/PSK),MQTT:none: This specification supports client authentication with TLS with RPK and PSK following the procedures described in DTLS profile [I-D.ietf-ace-dtls-authorize]. For the RPK, the Client MUST have published the token to the "authz-info" topic. For the PSK, the token MAY be published to the "authz- info" topic, or MAY be, alternatively, provided as a "PSK identity" (e.g. an "identity" in the "identities" field in the Client's "pre_shared_key" extension in TLS 1.3). * TLS:Known(RPK/PSK),MQTT:ace: This option SHOULD NOT be chosen as the token transported in the CONNECT overwrites any permissions passed during the TLS authentication. It is RECOMMENDED that the Client implements TLS:Anon,MQTT:ace as the first choice when working with protected topics. However, MQTT v3.1.1 Clients that do not prefer to overload username and password fields for ACE (as described in Section 6) MAY implement TLS:Known(RPK/PSK),MQTT:none, and consequently TLS:Anon,MQTT:None to submit their token to "authz-info". Sengul & Kirby Expires 24 September 2022 [Page 12] Internet-Draft MQTT-TLS profile of ACE March 2022 The Broker MUST support TLS:Anon,MQTT:ace. To support Clients with different capabilities, the Broker MAY provide multiple client authentication options, e.g. support TLS:Known(RPK),MQTT:none and TLS:Anon,MQTT:None, to enable RPK-based client authentication. The Client MUST authenticate the Broker during the TLS handshake. If the Client authentication uses TLS:Known(RPK/PSK), then the Broker is authenticated using the respective method. Otherwise, to authenticate the Broker, the Client MUST validate a public key from an X.509 certificate or an RPK from the Broker against the "rs_cnf" parameter in the token response, which contains information about the public key used by the RS to authenticate if the token type is "pop" and asymmetric keys are used as defined in [I-D.ietf-ace-oauth-params]. The AS MAY include the thumbprint of the RS's X.509 certificate in the "rs_cnf" (thumbprint as defined in [I-D.ietf-cose-x509]). In this case, the Client MUST validate the RS certificate against this thumbprint. 2.2.2. authz-info: The Authorization Information Topic In the cases when the Client must transport the token to the Broker first, the Client connects to the Broker to publish its token to the "authz-info" topic. The "authz-info" topic MUST be publish-only (i.e., the Clients are not allowed to subscribe to it). "authz-info" is not protected, and hence, the Client uses the TLS:Anon,MQTT:None option over a TLS connection. After publishing the token, the Client disconnects from the Broker and is expected to reconnect using client authentication over TLS (i.e., TLS:Known(RPK/PSK),MQTT:none). The Broker stores and indexes all tokens received to the "authz-info" topic in its key store (similar to the DTLS profile for ACE [I-D.ietf-ace-dtls-authorize]). This profile follows the recommendation of Section 5.10.1 of the ACE framework [I-D.ietf-ace-oauth-authz] and expects that the Broker stores only one token per PoP key, and any other token linked to the same key overwrites an existing token. The Broker MUST verify the validity of the token (i.e., through local validation or introspection, if the token is a reference) as described in Section 2.2.5. If the token is not valid, the Broker MUST discard the token. Sengul & Kirby Expires 24 September 2022 [Page 13] Internet-Draft MQTT-TLS profile of ACE March 2022 Depending on the QoS level of the PUBLISH packet, the Broker returns the error response as a PUBACK, PUBREC, or DISCONNECT packet. If the QoS level is equal to 0, and the token is not valid, or the claims cannot be obtained in the case of an introspected token, the Broker MUST send a DISCONNECT packet with the reason code 0x87 (Not authorized). If the PUBLISH payload does not parse to a token, the Broker MUST send a DISCONNECT with the reason code 0x99 (Payload format invalid). If the QoS level of the PUBLISH packet is greater than or equal to 1, and the token is not valid, or the claims cannot be obtained in the case of an introspected token, the Broker MUST send the reason code 0x87 (Not authorized) in the PUBACK or PUBREC. If the PUBLISH payload does not parse to a token, the PUBACK/PUBREC reason code is 0x99 (Payload format invalid). It must be noted that when the Broker sends the "Not authorized" response, this corresponds to the token being not valid, and not that the actual PUBLISH packet was not authorized. Given that the "authz- info" is a public topic, this response is not expected to cause confusion. 2.2.3. Client Authentication over TLS This document supports TLS with Raw Public Keys (RPK) [RFC7250] and with Pre-Shared Keys (PSK). The TLS session setup follows the DTLS profile for ACE [I-D.ietf-ace-dtls-authorize], as the profile applies to TLS equally well [I-D.ietf-ace-extend-dtls-authorize]. When there are exceptions to the DTLS profile, these are explicitly stated in the document. If TLS 1.2 is used, [RFC7925] describes how TLS can be used for constrained devices, alongside recommended cipher suites. Additionally, TLS 1.2 implementations MUST use the "Extended Main Secret" extension (terminology adopted from [I-D.ietf-tls-rfc8446bis]) to incorporate the handshake transcript into the main secret [RFC7627]. TLS implementations SHOULD use the SNI (Server Name Indication) [RFC6066] and APLN (Application-Layer Protocol Negotiation) [RFC7301] extensions so the TLS handshake authenticates as much of the protocol context as possible. 2.2.3.1. Raw Public Key Mode This document follows the procedures defined in Section 3.2.2 of the DTLS profile for ACE [I-D.ietf-ace-dtls-authorize] with the following exceptions. The Client MUST upload the access token to the Broker using the method specified in Section 2.2.2 before initiating the handshake. Sengul & Kirby Expires 24 September 2022 [Page 14] Internet-Draft MQTT-TLS profile of ACE March 2022 2.2.3.2. Pre-Shared Key Mode This document follows the procedures defined in Section 3.3.2 of DTLS profile for ACE [I-D.ietf-ace-dtls-authorize] with the following exceptions. To use TLS 1.3 with pre-shared keys, the Client utilizes the PSK key extension specified in [RFC8446] using the key conveyed in the "cnf" parameter of the AS response. The same key is bound to the access token in the "cnf" claim. The Client can upload the token as specified in Section 2.2.2 before initiating the handshake. When using a previously uploaded token, the Client MUST indicate during the handshake which previously uploaded access token it intends to use. To do so, it MUST create a "COSE_Key" or "JWK" structure with the "kid" that was conveyed in the "rs_cnf" claim in the token response from the AS and the key type "symmetric". This structure is then included as the only element in the "cnf" structure and the encoded value of that "cnf" structure used as a PSK identity in TLS. As an alternative to the access token upload, the Client can provide the most recent access token, JWT or CWT, as a PSK identity. In contrast to DTLS profile for ACE [I-D.ietf-ace-dtls-authorize], a Client MAY omit support for the cipher suites TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8. For TLS 1.2, however, a client MUST support TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 for PSK ([RFC8442]) and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for RPK ([RFC8422]), as recommended in [RFC7525] (and adjusted to be a PSK cipher suite as appropriate). 2.2.4. Client Authentication over MQTT 2.2.4.1. Transporting the Access Token Inside the MQTT CONNECT This section describes how the Client transports the token to the Broker inside the CONNECT packet. If this method is used, the Client TLS connection is expected to be anonymous, and the Broker is authenticated during the TLS connection setup. The approach described in this section is similar to an earlier proposal by Fremantle, et al. [fremantle14]. After sending the CONNECT, the Client MUST wait to receive the CONNACK from the Broker. The only packets it is allowed to send are DISCONNECT or AUTH that is in response to the Broker AUTH. Similarly, except for a DISCONNECT and AUTH response from the Client, the Broker MUST NOT process any packets before sending a CONNACK. Sengul & Kirby Expires 24 September 2022 [Page 15] Internet-Draft MQTT-TLS profile of ACE March 2022 Figure 2 shows the structure of the MQTT CONNECT packet used in MQTT v5.0. A CONNECT packet is composed of a fixed header, a variable header, and a payload. The fixed header contains the Control Packet Type (CPT), Reserved, and Remaining Length fields. Remaining Length is a Variable Byte Integer that represents the number of bytes remaining within the current Control Packet, including data in the Variable Header and the Payload. The Variable Header contains the Protocol Name, Protocol Level, Connect Flags, Keep Alive, and Properties fields. The Connect Flags in the variable header specify the properties of the MQTT session. It also indicates the presence or absence of some fields in the Payload. The payload contains one or more encoded fields, namely a unique Client Identifier for the Client, a Will Topic, Will Payload, User Name, and Password. All but the Client Identifier can be omitted depending on the flags in the Variable Header. The Client Identifier identifies the Client to the Broker, and therefore, is unique for each Client. It must be noted that the Client Identifier is an unauthenticated identifier used within the MQTT protocol and so is not bound to the access token. 0 8 16 +---------------------------+ |Protocol name length = 4 | +---------------------------+ | 'M' 'Q' | +---------------------------+ | 'T' 'T' | +---------------------------+ |Proto.level=5|Connect flags| +---------------------------+ | Keep alive | +---------------------------+ | CONNECT Properties Length | | (Upto 4 bytes) | +---------------------------+ | ( ..Other properties..) | +---------------------------+ | Authentication Method | | (0x15) | Len. | | Len | 'a' | | 'c' | 'e' | +---------------------------+ | Authentication Data | | (0x16) | Len | | Len | token | | or token + PoP data | +---------------------------+ Sengul & Kirby Expires 24 September 2022 [Page 16] Internet-Draft MQTT-TLS profile of ACE March 2022 Figure 2: MQTT v5 CONNECT Variable Header with Authentication Method Property for ACE The CONNECT flags are Username, Password, Will retain, Will QoS, Will Flag, Clean Start, and Reserved. Figure 3 shows how the flags MUST be set to use AUTH packets for authentication and authorization, i.e., the username and password flags MUST be set to 0. An MQTT v5.0 Broker MAY also support token transport using Username and Password to provide a security option for MQTT v3.1.1 Clients, as described in Section 6. +-----------------------------------------------------------+ |User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| | Flag |Flag | | | |Start| | +-----------------------------------------------------------+ | 0 | 0 | X | X X | X | X | 0 | +-----------------------------------------------------------+ Figure 3: CONNECT Flags for AUTH The Will Flag indicates that a Will message needs to be sent. The Client MAY set the Will Flag as desired (marked as "X" in Figure 3). If the Will Flag is set to 1, the Broker MUST check that the token allows the publication of the Will message (i.e., the Will Topic filter is in the scope array). The check is performed against the token scope described in Section 2.3. If the Will authorization fails, the connection is refused as described in Section 2.4.1. If the Broker accepts the connection request, the Broker stores the Will message and publishes it when the Network Connection is closed according to Will QoS, and Will retain parameters and MQTT Will management rules. To avoid publishing the Will Messages in the case of temporary network disconnections, the Client specifies a Will Delay Interval in the Will Properties. Section 5 explains how the Broker deals with the retained messages in further detail. In MQTT v5.0, the Client signals a clean session (i.e., that the session does not continue an existing session) by setting the Clean Start Flag to 1 in the CONNECT packet. In this profile, the Client SHOULD always start with a clean session. The Broker MAY also signal that it does not support session continuation by setting Session Expiry Interval to 0 in the CONNACK. If the Broker starts a clean session, the Broker MUST set the Session Present flag to 0 in the CONNACK packet to signal this to the Client. The Broker MAY support session continuation, e.g., if the Broker requires it for QoS reasons. In this case, if a CONNECT packet is received with Clean Start set to 0 and there is a Session associated with the Client Identifier, the Broker MUST resume communications Sengul & Kirby Expires 24 September 2022 [Page 17] Internet-Draft MQTT-TLS profile of ACE March 2022 with the Client based on the state from the existing Session. In its response, the Broker MUST set the Session Present flag to 1 in the CONNACK packet to signal session continuation to the Client. The session state stored by the Client and the Broker is described in Section 5. When reconnecting to a Broker that supports session continuation, the Client MUST still provide a token, in addition to using the same Client Identifier and setting the Clean Start to 0. The Broker MUST still perform PoP validation on the provided token. If the token matches the stored state, the Broker MAY skip introspecting a token- by-reference and use the stored introspection result. The Broker MUST also verify the Client is authorized to receive or send MQTT packets that are pending transmission. When a Client connects with a long Session Expiry Interval, the Broker may need to maintain the Client's MQTT session state after it disconnects for an extended period. Brokers SHOULD implement administrative policies to limit misuse. Note that, according to the MQTT standard, the Broker uses the Client Identifier to identify the session state. In the case of a Client Identifier collision, a Client may take over another Client's session. Given that the Broker MUST associate the Client with a valid token, a Client will only send or receive messages to its authorized topics. Therefore, while this issue is not expected to affect security, it may affect QoS (i.e., PUBLISH or QoS messages saved for Client A may be delivered to a Client B). In addition, if this Client Identifier represents a Client already connected to the Broker, the Broker sends a DISCONNECT packet to the existing Client with Reason Code of 0x8E (Session taken over) and closes the connection to the Client. 2.2.4.2. Authentication Using AUTH Property To use AUTH, the Client MUST set the Authentication Method as a property of a CONNECT packet by using the property identifier 21 (0x15). This is followed by a UTF-8 Encoded String containing the name of the Authentication Method, which MUST be set to "ace". If the Broker does not support this profile, it sends a CONNACK with a Reason Code of 0x8C (Bad authentication method). The Authentication Method is followed by the Authentication Data, which has a property identifier 22 (0x16) and is Binary Data. Based on the Authentication Data, the Broker MUST support both options below: * Proof-of-Possession using a challenge from the TLS session Sengul & Kirby Expires 24 September 2022 [Page 18] Internet-Draft MQTT-TLS profile of ACE March 2022 * Proof-of-Possession via Broker-generated challenge/response 2.2.4.2.1. Proof-of-Possession Using a Challenge from the TLS session +-----------------------------------------------------------------+ |Authentication|Token Length|Token |MAC or Signature | |Data Length | | |(over TLS exporter content) | +-----------------------------------------------------------------+ Figure 4: Authentication Data for PoP Based on TLS Exporter Content For this option, the Authentication Data inside the Client's CONNECT MUST contain the two-byte integer token length, the token, and the keyed message digest (MAC) or the Client signature (as shown in Figure 4). The Proof-of-Possession key in the token is used to calculate the keyed message digest (MAC) or the Client signature based on the content obtained from the TLS exporter ([RFC5705] for TLS 1.2, and Section 7.5 of [RFC8446]) for TLS 1.3. This content is exported from the TLS session using the exporter label "EXPORTER-ACE- MQTT-Sign-Challenge", an empty context, and length of 32 bytes. The token is also validated as described in Section 2.2.5, and the Broker responds with a CONNACK with the appropriate response code. The Client cannot reauthenticate using this method during the same TLS session (see Section 4). 2.2.4.2.2. Proof-of-Possession via Broker-generated Challenge/Response +------------------------------------+ |Authentication|Token Length|Token | |Data Length | | | +------------------------------------+ Figure 5: Authentication Data to Initiate PoP Based on Challenge/ Response +--------------------------+ |Authentication|RS Nonce | |Data Length |(8 bytes) | +--------------------------+ Figure 6: Authentication Data for Broker Challenge Sengul & Kirby Expires 24 September 2022 [Page 19] Internet-Draft MQTT-TLS profile of ACE March 2022 For this option, the Broker follows a Broker-generated challenge/ response protocol. If the Authentication Data inside the Client's CONNECT contains only the two-byte integer token length and the token (as shown in Figure 5), the Broker MUST respond with an AUTH packet, with the Authenticate Reason Code set to 0x18 (Continue Authentication). The Broker also uses this method if the Authentication Data does not contain a token, but the Broker has a token stored for the connecting Client. The Broker continues authentication using an AUTH packet that contains the Authentication Method and the Authentication Data. The Authentication Method MUST be set to "ace", and the Authentication Data MUST NOT be empty and MUST contain an 8-byte RS nonce as a challenge for the Client (Figure 6). +---------------------------------------------------------+ |Authentication|Client Nonce |MAC or Signature | |Data Length |(8 bytes) |(over RS nonce+Client nonce)| +---------------------------------------------------------+ Figure 7: Authentication Data for Client Challenge Response The Client responds to this with an AUTH packet with a reason code 0x18 (Continue Authentication). Similarly, the Client packet sets the Authentication Method to "ace". The Authentication Data in the Client's response is formatted as shown in Figure 7 and includes the 8-byte Client nonce, and the signature or MAC computed over the RS nonce concatenated with the Client nonce using PoP key in the token. Next, the token is validated as described in Section 2.2.5. The success case is illustrated in Figure 8. The Client MAY also re- authenticate using this challenge-response flow, as described in Section 4. Sengul & Kirby Expires 24 September 2022 [Page 20] Internet-Draft MQTT-TLS profile of ACE March 2022 Client Broker | | |<===========>| TLS connection setup | | | | +------------>| CONNECT with Authentication Data | | contains only token | | <-------------+ AUTH 0x18 (Cont. Authentication) | | 8-byte RS nonce as challenge | | |------------>| AUTH 0x18 (Cont. Authentication) | | 8-byte Client nonce + signature/MAC | | | |---+ Token validation | | | (may involve introspection) | |<--+ | | |<------------+ CONNACK 0x00 (Success) Figure 8: PoP Challenge/Response Flow - Success 2.2.5. Broker Token Validation The Broker MUST verify the validity of the token either locally (e.g., in the case of a self-contained token) or MAY send a request to the introspection endpoint of the AS (as described for HTTP-based interactions in Section 5.9 of the ACE framework [I-D.ietf-ace-oauth-authz]). The Broker MUST verify the claims in the access token according to the rules set in Section 5.10.1.1 of the ACE framework [I-D.ietf-ace-oauth-authz]. To authenticate the Client, the Broker validates the signature or the MAC, depending on how the PoP protocol is implemented. For self- contained tokens, the Broker MUST process the security protection of the token first, as specified by the respective token format, i.e. a CWT token uses COSE, while a JWT token uses JOSE. For a token-by- reference, the Broker uses the "cnf" structure returned as a result of token introspection as specified in [RFC7519]. HS256 (HMAC-SHA- 256) [RFC6234] and Ed25519 [RFC8032] are mandatory to implement for the Broker. The Client MUST implement at least one of them depending on the choice of symmetric or asymmetric validation. Validation of the signature or MAC MUST fail if the signature algorithm is set to "none", when the key used for the signature algorithm cannot be determined, or the computed and received signature/MAC do not match. Sengul & Kirby Expires 24 September 2022 [Page 21] Internet-Draft MQTT-TLS profile of ACE March 2022 The Broker MUST check if the access token is still valid, if it is the intended destination (i.e., the audience) of the token, and if the token was issued by an authorized authorization server. If the Client is using TLS RPK mode to authenticate to the Broker, the AS constructs the access token so that the Broker can associate the access token with the Client's public key. The "cnf" claim MUST contain either the Client's RPK or, if the key is already known by the Broker (e.g., from previous communication), a reference to it. 2.3. Token Scope and Authorization The scope field contains the publish and subscribe permissions for the Client. Therefore, the token or its introspection result MUST be cached to allow a Client's future PUBLISH and SUBSCRIBE messages. During the CONNECT, if the Will Flag is set to 1, the Broker MUST also authorize the publication of the Will Topic and message using the token's scope field. The Broker uses the scope to match against the Topic Name in a PUBLISH packet (including Will Topic in the CONNECT) or a Topic Filter in a SUBSCRIBE packet. The scope in the token is a single value. For a JWT, the single scope is base64url encoded string with any padding characters removed, which has an internal structure of a JSON array. For a CWT, this information is represented in CBOR. The internal structure follows the Authorization Information Format (AIF) for ACE [I-D.ietf-ace-aif]. Using the Concise Data Definition Language (CDDL) [RFC8610], the specific data model for MQTT is: AIF-MQTT = AIF-Generic AIF-Generic = [* [Toid, Tperm]] mqtt-topic-filter = tstr ; as per Section 4.7 of MQTT v5.0 mqtt-permissions = [+permission] permission = "pub"/"sub" Figure 9: AIF-MQTT data model Topic filters are implemented according to Section 4.7 of MQTT v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5]. By default, Wildcard Subscriptions are supported, and so, the topic filter may include special wildcard characters. The multi-level wildcard, "#", matches any number of levels within a topic, and the single-level wildcard, "+", matches one topic level. The Broker MAY signal in the CONNACK explicitly whether wildcard subscriptions are supported by returning a CONNACK property "Wildcard Subscription Available". A value of 0 means that Wildcard Subscriptions are not supported. A value of 1 means Wildcard Subscriptions are supported. Following this model, an example scope may contain: Sengul & Kirby Expires 24 September 2022 [Page 22] Internet-Draft MQTT-TLS profile of ACE March 2022 [["topic1",["pub","sub"]],["topic2/#",["pub"]],["+/topic3",["sub"]]] Figure 10: Example scope This access token gives publish ("pub") and subscribe ("sub") permissions to the "topic1", publish permission to all the subtopics of "topic2", and subscribe permission to all "topic3", skipping one level. If the scope is empty, the Broker records no permissions for the Client for any topic. In this case, the Client is not able to publish or subscribe to any protected topics. The non-empty scope is used to authorize the Will Topic, if provided, in the CONNECT packet, during connection setup, and if the connection request succeeds, the Topic Names or Topic Filters requested in the future PUBLISH and SUBSCRIBE packets. For the authorization to succeed, the Broker MUST verify that the topic name or filter in question is either an exact match to or a subset of at least one "topic_filter" in the scope. 2.4. Broker Response to Client Connection Request Based on the validation result (obtained either via local inspection or using the introspection interface of the AS), the Broker MUST send a CONNACK packet to the Client. 2.4.1. Unauthorized Request and the Optional Authorization Server Discovery Authentication can fail for the following reasons: * If the Client does not provide a valid token, * the Client omits the Authentication Data field and the Broker has no token stored for the Client, * the token or Authentication data are malformed, or * if the Will flag is set, the authorization checks for the Will topic fails. The Broker responds with the CONNACK reason code 0x87 (Not Authorized) or any other applicable reason code. The Broker MAY also trigger AS discovery and include a User Property (identified as property type 38 (0x26)) in the CONNACK for the AS Request Creation Hints. The User Property is a UTF-8 string pair, composed of a name and a value. The name of the User Property MUST be set to "ace_as_hint". The value of the user property is a UTF-8 Sengul & Kirby Expires 24 September 2022 [Page 23] Internet-Draft MQTT-TLS profile of ACE March 2022 encoded JSON object containing the mandatory "AS" parameter, and the optional parameters "audience", "kid", "cnonce", and "scope" as defined in Section 5.3 of the ACE framework [I-D.ietf-ace-oauth-authz]. 2.4.2. Authorization Success On success, the reason code of the CONNACK is 0x00 (Success). If the Broker starts a new session, it MUST also set Session Present to 0 in the CONNACK packet to signal a clean session to the Client. Otherwise, it MUST set Session Present to 1. Having accepted the connection, the Broker MUST be prepared to store the token during the connection and after disconnection for future use. If the token is not self-contained and the Broker uses token introspection, it MAY cache the validation result to authorize the subsequent PUBLISH and SUBSCRIBE packets. PUBLISH and SUBSCRIBE packets, which are sent after a connection setup, do not contain access tokens. If the introspection result is not cached, the Broker needs to introspect the saved token for each request. The Broker SHOULD also use a cache timeout to introspect tokens regularly. The timeout value is application-specific and should be chosen to reduce the risk of using stale introspection responses. 3. Authorizing PUBLISH and SUBSCRIBE Packets Using the cached token or its introspection result, the Broker uses the scope field to match against the Topic Name in a PUBLISH packet, or a Topic Filter in a SUBSCRIBE packet. 3.1. PUBLISH Packets from the Publisher Client to the Broker On receiving the PUBLISH packet, the Broker MUST use the type of packet (i.e., PUBLISH) and the Topic name in the packet header to match against the scope array items in the cached token or its introspection result. Following the example in Section 2.3, the Client sending a PUBLISH for "topic2/a" would be allowed, as the scope array includes the ["topic2/#",["pub"]]. If the Client is allowed to publish to the topic, the Broker publishes the message to all valid subscribers of the topic. In the case of an authorization failure, the Broker MUST return an error if the Client has set the QoS level of the PUBLISH packet to greater than or equal to 1. Depending on the QoS level, the Broker responds with either a PUBACK or PUBREC packet with reason code 0x87 (Not authorized). On receiving an acknowledgment with 0x87 (Not authorized), the Client MAY reauthenticate by providing a new token as described in Section 4. Sengul & Kirby Expires 24 September 2022 [Page 24] Internet-Draft MQTT-TLS profile of ACE March 2022 For QoS level 0, the Broker sends a DISCONNECT with reason code 0x87 (Not authorized) and closes the Network Connection. Note that the server-side DISCONNECT is a new feature of MQTT v5.0 (in MQTT v3.1.1, the server needs to drop the connection). For all QoS levels, the Broker MAY return 0x80 Unspecified error if they do not want to leak the topic names to unauthorized clients. 3.2. PUBLISH Packets from the Broker to the Subscriber Clients To forward PUBLISH packets to the subscribing Clients, the Broker identifies all the subscribers that have valid matching topic subscriptions to the Topic name of the PUBLISH packet (i.e., the tokens are valid, and token scopes allow a subscription to this particular Topic name). The Broker forwards the PUBLISH packet to all the valid subscribers. The Broker MUST NOT forward messages to unauthorized subscribers. To avoid silently dropping messages, the Broker MUST close the network connection and SHOULD inform the affected subscribers. The only way to inform a client, in this case, would be sending a DISCONNECT packet. Therefore, the Broker SHOULD send a DISCONNECT packet with the reason code 0x87 (Not authorized) before closing the network connection to these clients. 3.3. Authorizing SUBSCRIBE Packets In MQTT, a SUBSCRIBE packet is sent from a Client to the Broker to create one or more subscriptions to one or more topics. The SUBSCRIBE packet may contain multiple Topic Filters. The Topic Filters may include wildcard characters. On receiving the SUBSCRIBE packet, the Broker MUST use the type of packet (i.e., SUBSCRIBE) and the Topic Filter in the packet header to match against the scope field of the stored token or introspection result. The Topic Filters MUST be an exact match to or be a subset of at least one of the "topic_filter" fields in the scope array found in the Client's token. For example, if the Client sends a subscription request for topic "a/b/*", and has a token that permits "a/*", this is a valid subscription request, as "a/b/*" is a subset of "a/*". (The process is similar to a Broker matching the Topic Name in a PUBLISH packet against the Subscriptions known to the Server.) As a response to the SUBSCRIBE packet, the Broker issues a SUBACK. For each Topic Filter, the SUBACK packet includes a return code matching the QoS level for the corresponding Topic Filter. In the case of failure, the return code is 0x87, indicating that the Client Sengul & Kirby Expires 24 September 2022 [Page 25] Internet-Draft MQTT-TLS profile of ACE March 2022 is not authorized. The Broker MAY return 0x80 Unspecified error if they do not want to leak the topic names to unauthorized clients. A reason code is returned for each Topic Filter. Therefore, the Client may receive success codes for a subset of its Topic Filters while being unauthorized for the rest. 4. Token Expiration, Update, and Reauthentication The Broker MUST check for token expiration whenever a CONNECT, PUBLISH, or SUBSCRIBE is received or sent. The Broker SHOULD check for token expiration on receiving a PINGREQUEST. The Broker MAY also check for token expiration periodically, e.g., every hour. This may allow for early detection of a token expiry. The token expiration is checked by checking the "exp" claim of a JWT or introspection response or via performing an introspection request with the AS as described in Section 5.9 of the ACE framework [I-D.ietf-ace-oauth-authz]. Token expirations may trigger the Broker to send PUBACK, SUBACK and DISCONNECT packets with return code set to "Not authorized". After sending a DISCONNECT, the Network Connection is closed, and no more messages can be sent. The Client MAY reauthenticate as a response to the PUBACK and SUBACK that signal loss of authorization. The Clients MAY also proactively update their tokens, i.e., before they receive a packet with a "Not authorized" return code. To start reauthentication, the Client MUST send an AUTH packet with the reason code 0x19 (Re-authentication). The Client MUST set the Authentication Method as "ace" and transport the new token in the Authentication Data. If re-authenticating during the current TLS session, the Client MUST NOT use the method described in Section 2.2.4.2.1, Proof-of-Possession using a challenge from the TLS session, to avoid re-using the same challenge value from the TLS-Exporter. Note that this means that servers will either need to record in the session ticket or database entry whether the TLS- Exporter-derived challenge was used, or always deny use of the TLS- Exporter-derived challenge for resumed sessions. In TLS 1.3, the resumed connection would have a new exporter value, but the requirement is phrased this way for simplicity. For re- authentications in the same TLS-session, the Client MUST use the challenge-response PoP as defined in Section 2.2.4.2.2. The Broker accepts reauthentication requests if the Client has already submitted a token (may be expired), for which it performed proof-of-possession. Otherwise, the Broker MUST deny the request. If the reauthentication fails, the Broker MUST send a DISCONNECT with the reason code 0x87 (Not Authorized). Sengul & Kirby Expires 24 September 2022 [Page 26] Internet-Draft MQTT-TLS profile of ACE March 2022 5. Handling Disconnections and Retained Messages In the case of a Client DISCONNECT, if the Session Expiry Interval is set to 0, the Broker doesn't maintain session state but MUST keep the retained messages. If the Broker maintains session state, the state MAY include the token and its introspection result (for reference tokens) in addition to the MQTT session state. The MQTT session state is identified by the Client Identifier and includes the following: * Client subscription state, * messages with QoS levels 1 and 2, and which have not been completely acknowledged or are pending transmission to the Client, and * if the Session is currently not connected, the time at which the Session will end and Session State will be discarded. The token/introspection state is not part of the MQTT session state, and PoP validation is required for each new connection, regardless of whether MQTT session continuation is used. The messages to be retained are indicated to the Broker by setting a RETAIN flag in a PUBLISH packet. This way, the publisher signals to the Broker to store the most recent message for the associated topic. Hence, the new subscribers can receive the last sent message from the publisher for that particular topic without waiting for the next PUBLISH packet. The Broker MUST continue publishing the retained messages as long as the associated tokens are valid. In the MQTT standard, if QoS is 0 for the PUBLISH packet, the Broker may discard the retained message any time. For QoS>1, the message expiry interval dictates how long the retained message is kept. However, it is important that the Broker avoids sending messages indefinitely for the Clients that never update their tokens (i.e., the Client connects briefly with a valid token, sends a PUBLISH packet with RETAIN flag set to 1 and QoS>1, disconnects, and never connects again). Therefore, the Broker MUST use the minimum of token expiry and message expiry interval to discard a retained message. In case of disconnections due to network errors or server disconnection due to a protocol error (which includes authorization errors), the Will message is sent if the Client supplied a Will in the CONNECT packet. The Client's token scope array MUST include the Will Topic. The Will message MUST be published to the Will Topic regardless of whether the corresponding token has expired (as it has been validated and accepted during CONNECT). Sengul & Kirby Expires 24 September 2022 [Page 27] Internet-Draft MQTT-TLS profile of ACE March 2022 6. Reduced Protocol Interactions for MQTT v3.1.1 This section describes a reduced set of protocol interactions for the MQTT v3.1.1 Clients. An MQTT v5.0 Broker MAY implement these interactions for the MQTT v3.1.1 Clients; The flows described in this section are NOT RECOMMENDED for use by MQTT v5.0 Clients. Brokers that do not support MQTT v3.1.1 Clients return a CONNACK packet with Reason Code 0x84 (Unsupported Protocol Version) in response to the connection requests. 6.1. Token Transport As in MQTT v5.0, the token MAY either be transported before, by publishing to the "authz-info" topic, or inside the CONNECT packet. If the Client provided the token via the "authz-info" topic and will not update the token in the CONNECT packet, it MUST authenticate over TLS. The Broker SHOULD still be prepared to store the Client access token for future use (regardless of the method of transport). In MQTT v3.1.1, after the Client has published to the "authz-info" topic, the Broker cannot communicate the result of the token validation because PUBACK reason codes or server-side DISCONNECT packets are not supported. In any case, the subsequent TLS handshake would fail without a valid token, which can prompt the Client to obtain a valid token. To transport the token to the Broker inside the CONNECT packet, the Client uses the username and password fields. Figure 11 shows the structure of the MQTT CONNECT packet. Sengul & Kirby Expires 24 September 2022 [Page 28] Internet-Draft MQTT-TLS profile of ACE March 2022 0 8 16 +---------------------------+ |Protocol name length = 4 | +---------------------------+ | 'M' 'Q' | +---------------------------+ | 'T' 'T' | +---------------------------+ |Proto.level=5|Connect flags| +---------------------------+ | Keep alive | +---------------------------+ | Payload | | Client Identifier | | (UTF-8 encoded string) | | Username as access token | | (UTF-8 encoded string) | | Password for signature/MAC| | (Binary Data) | +---------------------------+ Figure 11: MQTT CONNECT Variable Header Using Username and Password for ACE Figure 12 shows how the MQTT connect flags MUST be set to initiate a connection with the Broker. +-----------------------------------------------------------+ |User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| | flag |flag | | | | | | +-----------------------------------------------------------+ | 1 | 1 | X | X X | X | X | 0 | +-----------------------------------------------------------+ Figure 12: MQTT CONNECT Flags (Rsvd=Reserved) The Client SHOULD set the Clean flag to 1 to always start a new session. If the Clean flag is set to 0, the Broker MUST resume communications with the Client based on the state from the current Session (as identified by the Client Identifier). If there is no Session associated with the Client Identifier, the Broker MUST create a new session. The Broker MUST set the Session Present flag in the CONNACK packet accordingly, i.e., 0 to indicate a clean session to the Client and 1 to indicate session continuation. The Broker MUST still perform PoP validation on the provided Client token. MQTT v3.1.1 does not use a Session Expiry Interval, and the Client expects that the Broker maintains the session state after it disconnects. However, stored Session state can be discarded as a result of Sengul & Kirby Expires 24 September 2022 [Page 29] Internet-Draft MQTT-TLS profile of ACE March 2022 administrator action or policies (e.g. defining an automated response based on storage capabilities), and Brokers SHOULD implement administrative policies to limit misuse. The Client MAY set the Will Flag as desired (marked as "X" in Figure 12). Username and Password flags MUST be set to 1 to ensure that the Payload of the CONNECT packet includes both Username and Password fields. The MQTT Username is a UTF-8 encoded string, and the MQTT Password is Binary Data. The CONNECT in MQTT v3.1.1 does not have a field to indicate the authentication method. To signal that the Username field contains an ACE token, this field MUST be prefixed with "ace" keyword, i.e., the Username field is a concatenation of 'a', 'c', 'e' and the access token represented as: 'U+0061'||'U+0063'||'U+0065'||UTF-8(access token) Figure 13: Username in CONNECT To this end, the access token MUST be base64url encoded, omitting the '=' padding characters [RFC4648]. The password field MUST be set to the keyed message digest (MAC) or signature associated with the access token for PoP. The Client MUST apply the PoP key on the challenge derived from the TLS session as described in Section 2.2.4.2.1. 6.2. Handling Authorization Errors Error handling is more primitive in MQTT v3.1.1 due to not having appropriate error fields, error codes, and server-side DISCONNECTs. Therefore, the Broker will disconnect on almost any error and may not keep the session state, necessitating that clients make a greater effort to ensure that tokens remain valid and do not attempt to publish to topics that they do not have permissions for. The following lists how the Broker responds to specific errors. * CONNECT without a token: The tokenless CONNECT attempt MUST fail. This is because the challenge-response based PoP is not possible for MQTT v3.1.1. It is also not possible to support AS discovery since a CONNACK packet in MQTT v3.1.1 does not include a means to provide additional information to the Client. Therefore, AS discovery needs to take place out-of-band. * Client-Broker PUBLISH authorization failure: In the case of a failure, it is not possible to return an error in MQTT v3.1.1. Acknowledgment messages only indicate success. In the case of an Sengul & Kirby Expires 24 September 2022 [Page 30] Internet-Draft MQTT-TLS profile of ACE March 2022 authorization error, the Broker MUST ignore the PUBLISH packet and disconnect the Client. Also, as DISCONNECT packets are only sent from a Client to the Broker, the server disconnection needs to take place below the application layer. * SUBSCRIBE authorization failure: In the SUBACK packet, the return code is 0x80 indicating failure for the unauthorized topic(s). Note that, in both MQTT versions, a reason code is returned for each Topic Filter. * Broker-Client PUBLISH authorization failure: When the Broker is forwarding PUBLISH packets to the subscribed Clients, it may discover that some of the subscribers are no longer authorized due to expired tokens. These token expirations MUST lead to disconnecting the Client rather than silently dropping messages. 7. IANA Considerations Note to RFC Editor: Please replace all occurrences of "[this document]" with the RFC number of this specification and delete this paragraph. 7.1. TLS Exporter Label Registration This document registers "EXPORTER-ACE-MQTT-Sign-Challenge" (introduced in Section 2.2.4.2.1 in this document) in the TLS Exporter Label Registry [RFC8447]. * Recommended: No * DTLS-OK: No * Reference: [This document] 7.2. Media Type Registration This document registers the "application/ace+json" media type for messages of the protocols defined in this document carrying parameters encoded in JSON. * Type name: application * Subtype name: ace+json * Required parameters: N/A * Optional parameters: N/A Sengul & Kirby Expires 24 September 2022 [Page 31] Internet-Draft MQTT-TLS profile of ACE March 2022 * Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type. * Security considerations: Section 8 of [this document] * Interoperability considerations: none * Published specification: [this document] * Applications that use this media type: This media type is intended for authorization server-client and authorization server-resource server communication as part of the ACE framework using JSON encoding as specified in [this document]. * Fragment identifier considerations: none * Additional information: - Deprecated alias names for this type: none - Magic number(s): none - File extension(s): none - Macintosh file type code(s): none * Person & email address to contact for further information: Cigdem Sengul (csengul@acm.org) * Intended usage: COMMON * Restrictions on usage: none * Author: Cigdem Sengul (csengul@acm.org) * Change controller: IETF * Provisional registration? (standards tree only): no 7.3. ACE OAuth Profile Registration The following registrations are done for the ACE OAuth Profile Registry following the procedure specified in [I-D.ietf-ace-oauth-authz]. * Name: mqtt_tls Sengul & Kirby Expires 24 September 2022 [Page 32] Internet-Draft MQTT-TLS profile of ACE March 2022 * Description: Profile for delegating Client authentication and authorization using MQTT for the Client and Broker (RS) interactions, and HTTP for the AS interactions. TLS is used for confidentiality and integrity protection and server authentication. Client authentication can be provided either via TLS or using in-band PoP validation at the MQTT application layer. * CBOR Value: To be assigned by IANA in the (-256, 255) range * Reference: [this document] 7.4. AIF For the media-types application/aif+cbor and application/aif+json defined in Section 5.1 of [I-D.ietf-ace-aif], IANA is requested to register the following entries for the two media-type parameters Toid and Tperm, in the respective sub-registry defined in Section 5.2 of [I-D.ietf-ace-aif] within the "MIME Media Type Sub-Parameter" registry group. For Toid: * Name: mqtt-topic-filter * Description/Specification: Topic Filter as defined in Section 2.3. * Reference: [[This document]] (Section 2.3) For Tperm: * Name: mqtt-permissions * Description/Specification: Permissions for MQTT client as defined in Section 2.3. Tperm is an array of one or more text strings that each have a value of either "pub" or "sub". * Reference: [[This document]] (Section 2.3) 8. Security Considerations This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework [I-D.ietf-ace-oauth-authz]. Therefore, the security considerations outlined in [I-D.ietf-ace-oauth-authz] apply to this work. In addition, the security considerations outlined in MQTT v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] and MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard-v3.1.1] apply. Mainly, this document Sengul & Kirby Expires 24 September 2022 [Page 33] Internet-Draft MQTT-TLS profile of ACE March 2022 provides an authorization solution for MQTT, the responsibility of which is left to the specific implementation in the MQTT standards. In the following, we comment on a few relevant issues based on the current MQTT specifications. After the Broker validates an access token and accepts a connection from a client, it caches the token to authorize a Client's publish and subscribe requests in an ongoing session. The Broker does not cache any tokens that cannot be validated. If a Client's permissions get revoked, but the access token has not expired, the Broker may still grant publish/subscribe to revoked topics. If the Broker caches the token introspection responses, then the Broker SHOULD use a reasonable cache timeout to introspect tokens regularly. The timeout value is application-specific and should be chosen to reduce the risk of using stale introspection responses. When permissions change dynamically, it is expected that AS also follows a reasonable expiration strategy for the access tokens. The Broker may monitor Client behaviour to detect potential security problems, especially those affecting availability. These include repeated token transfer attempts to the public "authz-info" topic, repeated connection attempts, abnormal terminations, and Clients that connect but do not send any data. If the Broker supports the public "authz-info" topic, described in Section 2.2.2, then this may be vulnerable to a DDoS attack, where many Clients use the "authz-info" public topic to transport tokens that are not meant to be used, and which the Broker may need to store until the tokens expire. For MQTT v5.0, when a Client connects with a long Session Expiry Interval, the Broker may need to maintain the Client's MQTT session state after it disconnects for an extended period. For MQTT v3.1.1, the session state may need to be stored indefinitely, as it does not have a Session Expiry Interval feature. The Broker SHOULD implement administrative policies to limit misuse of the session continuation by the Client. 9. Privacy Considerations The privacy considerations outlined in [I-D.ietf-ace-oauth-authz] apply to this work. Sengul & Kirby Expires 24 September 2022 [Page 34] Internet-Draft MQTT-TLS profile of ACE March 2022 In MQTT, the Broker is a central trusted party and may forward potentially sensitive information between Clients. The mechanisms defined in this document do not protect the contents of the PUBLISH packet from the Broker, and hence, the content of the PUBLISH packet is not signed or encrypted separately for the subscribers. This functionality may be implemented using the proposal outlined in the ACE Pub-Sub Profile [I-D.ietf-ace-pubsub-profile]. However, this solution would still not provide privacy for other fields of the packet, such as Topic Name. 10. References 10.1. Normative References [I-D.ietf-ace-aif] Bormann, C., "An Authorization Information Format (AIF) for ACE", Work in Progress, Internet-Draft, draft-ietf- ace-aif-07, 15 March 2022, . [I-D.ietf-ace-dtls-authorize] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and L. Seitz, "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June 2021, . [I-D.ietf-ace-extend-dtls-authorize] Bergmann, O., Mattsson, J. P., and G. Selander, "Extension of the CoAP-DTLS Profile for ACE to TLS", Work in Progress, Internet-Draft, draft-ietf-ace-extend-dtls- authorize-02, 7 March 2022, . [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, draft-ietf-ace-oauth-authz-46, 8 November 2021, . Sengul & Kirby Expires 24 September 2022 [Page 35] Internet-Draft MQTT-TLS profile of ACE March 2022 [I-D.ietf-ace-oauth-params] Seitz, L., "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-oauth-params-16, 7 September 2021, . [I-D.ietf-cose-x509] Schaad, J., "CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates", Work in Progress, Internet-Draft, draft- ietf-cose-x509-08, 14 December 2020, . [I-D.ietf-httpbis-semantics] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Semantics", Work in Progress, Internet-Draft, draft-ietf- httpbis-semantics-19, 12 September 2021, . [MQTT-OASIS-Standard-v3.1.1] Banks, A., Ed. and R. Gupta, Ed., "OASIS Standard MQTT Version 3.1.1 Plus Errata 01", 2015, . [MQTT-OASIS-Standard-v5] Banks, A., Ed., Briggs, E., Ed., Borgendale, K., Ed., and R. Gupta, Ed., "OASIS Standard MQTT Version 5.0", 2017, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, . Sengul & Kirby Expires 24 September 2022 [Page 36] Internet-Draft MQTT-TLS profile of ACE March 2022 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, . [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . Sengul & Kirby Expires 24 September 2022 [Page 37] Internet-Draft MQTT-TLS profile of ACE March 2022 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, . [RFC8442] Mattsson, J. and D. Migault, "ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2", RFC 8442, DOI 10.17487/RFC8442, September 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2020, . 10.2. Informative References [fremantle14] Fremantle, P., Aziz, B., Kopecky, J., and P. Scott, "Federated Identity and Access Management for the Internet of Things", research International Workshop on Secure Internet of Things, September 2014, . Sengul & Kirby Expires 24 September 2022 [Page 38] Internet-Draft MQTT-TLS profile of ACE March 2022 [I-D.ietf-ace-pubsub-profile] Palombini, F. and C. Sengul, "Pub-Sub Profile for Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-pubsub-profile-04, 29 December 2021, . [I-D.ietf-tls-rfc8446bis] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft- ietf-tls-rfc8446bis-04, 7 March 2022, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . Sengul & Kirby Expires 24 September 2022 [Page 39] Internet-Draft MQTT-TLS profile of ACE March 2022 Appendix A. Checklist for profile requirements Based on the requirements on profiles for the ACE framework [I-D.ietf-ace-oauth-authz], this document fulfills the following: * Optional AS discovery: AS discovery is supported with the MQTT v5.0 described in Section 2.2. * The communication protocol between the Client and Broker (RS): MQTT * The security protocol between the Client and RS: TLS * Client and RS mutual authentication: Several options are possible and described in Section 2.2.1. * Proof-of-possession protocols: Specified in Section 2.2.4.2; both symmetric and asymmetric keys supported. * Content format: For the HTTPS interactions with AS, "application/ ace+json". * Unique profile identifier: mqtt_tls * Token introspection: RS uses HTTPS introspect interface of AS. * Token request: Client or its Client AS uses the HTTPS token endpoint of the AS. * authz-info endpoint: It MAY be supported using the method described in Section 2.2.2, but is not protected other than by the TLS channel between Client and RS. * Token transport: Via "authz-info" topic, or TLS with PSK, provided as a PSK identity, or in MQTT CONNECT packet for both versions of MQTT. The AUTH extensions can also be used for authentication and re-authentication for MQTT v5.0, as described in Section 2.2 and Section 4. Appendix B. Document Updates Version 15: Addressing GENART review comments. Version 11 to 15: Addressing AD review comments. Version 10 to 11: Clarified the TLS use between RS-AS and Client-AS. Version 09 to 10: Fixed version issues for references. Sengul & Kirby Expires 24 September 2022 [Page 40] Internet-Draft MQTT-TLS profile of ACE March 2022 Version 08 to 09: Fixed spacing issues and references. Version 07 to 08: * Fixed several nits, typos based on WG reviews. * Added missing references. * Added the definition for Property defined by MQTT, and Client Authorization Server. * Added artwork to show Authorization Data format for various PoP- related message exchange. * Removed all MQTT-related must/should/may. * Made AS discovery optional. * Clarified what the client and server must implement for client authentication; cleaned up TLS 1.3 related language. Version 06 to 07: * Corrected the title. * In Section 2.2.3, added the constraint on which packets the Client can send, and the server can process after CONNECT before CONNACK. * In Section 2.2.3, clarified that session state is identified by Client Identifier, and listed its content. * In Section 2.2.3, clarified the issue of Client Identifier collision, when the Broker supports session continuation. * Corrected the buggy scope example in Section 3.1. Version 05 to 06: * Replace the originally proposed scope format with AIF model. Defined the AIF-MQTT, gave an example with a JSON array. Added a normative reference to the AIF draft. * Clarified client connection after submitting token via "authz- info" topic as TLS:Known(RPK/PSK),MQTT:none. * Expanded acronyms on their first use including the ones in the title. Sengul & Kirby Expires 24 September 2022 [Page 41] Internet-Draft MQTT-TLS profile of ACE March 2022 * Added a definition for "Session". * Corrected "CONNACK" definition, which earlier said it's the first packet sent by the Broker. * Added a statement that the Broker will disconnect on almost any error and may not keep session state. * Clarified that the Broker does not cache tokens that cannot be validated. Version 04 to 05: * Reorganised Section 2 such that "Unauthorized Request: Authorization Server Discovery" is presented under Section 2. * Fixed Figure 2 to remove the "empty" word. * Clarified that MQTT v5.0 Brokers may implement username/password option for transporting the ACE token only for MQTT v.3.1.1 clients. This option is not recommended for MQTT v.5.0 clients. * Changed Clean Session requirement both for MQTT v.5.0 and v.3.1.1. The Broker SHOULD NOT, instead of MUST NOT, continue sessions. Clarified expected behaviour if session continuation is supported. Added to the Security Considerations the potential misuse of session continuation. * Fixed the Authentication Data to include token length for the Challenge/Response PoP. * Added that Authorization Server Discovery is triggered if a token is not valid and not only missing. * Clarified that the Broker should not accept any other packets from Client after CONNECT and before sending CONNACK. * Added that client reauthentication is accepted only for the challenge/response PoP. * Added Ed25519 as mandatory to implement. * Fixed typos. Version 03 to 04: * Linked the terms Broker and MQTT server more at the introduction of the document. Sengul & Kirby Expires 24 September 2022 [Page 42] Internet-Draft MQTT-TLS profile of ACE March 2022 * Clarified support for MQTTv3.1.1 and removed phrases that might be considered as MQTTv5 is backwards compatible with MQTTv3.1.1 * Corrected the Informative and Normative references. * For AS discovery, clarified the CONNECT message omits the Authentication Data field. Specified the User Property MUST be set to "ace_as_hint" for AS Request Creation Hints. * Added that MQTT v5 brokers MAY also implement reduced interactions described for MQTTv3.1.1. * Added to Section 3.1, in case of an authorization failure and QoS level 0, the RS sends a DISCONNECT with reason code 0x87 (Not authorized). * Added a pointer to section 4.7 of MQTTv5 spec for more information on topic names and filters. * Added HS256 and RSA256 are mandatory to implement depending on the choice of symmetric or asymmetric validation. * Added MQTT to the TLS exporter label to make it application specific: 'EXPORTER-ACE-MQTT-Sign-Challenge'. * Added a format for Authentication Data so that length values prefix the token (or client nonce) when Authentication Data contains more than one piece of information. * Clarified clients still connect over TLS (server-side) for the authz-info flow. Version 02 to 03: * Added the option of Broker certificate thumbprint in the 'rs_cnf' sent to the Client. * Clarified the use of a random nonce from the TLS Exporter for PoP, added to the IANA requirements that the label should be registered. * Added a client nonce, when Challenge/Response Authentication is used between Client and Broker. * Clarified the use of the "authz-info" topic and the error response if token validation fails. Sengul & Kirby Expires 24 September 2022 [Page 43] Internet-Draft MQTT-TLS profile of ACE March 2022 * Added clarification on wildcard use in scopes for publish/ subscribe permissions * Reorganised sections so that token authorization for publish/ subscribe messages are better placed. Version 01 to 02: * Clarified protection of Application Message payload as out of scope, and cited draft-palombini-ace-coap-pubsub-profile for a potential solution * Expanded Client connection authorization to capture different options for Client and Broker authentication over TLS and MQTT * Removed Payload (and specifically Client Identifier) from proof- of-possession in favor of using tls-exporter for a TLS-session based challenge. * Moved token transport via "authz-info" topic from the Appendix to the main text. * Clarified Will scope. * Added MQTT AUTH to terminology. * Typo fixes, and simplification of figures. Version 00 to 01: * Present the MQTTv5 as the RECOMMENDED version, and MQTT v3.1.1 for backward compatibility. * Clarified Will message. * Improved consistency in the use of terminology and upper/lower case. * Defined Broker and MQTTS. * Clarified HTTPS use for C-AS and RS-AS communication. Removed reference to actors document, and clarified the use of client authorization server. * Clarified the Connect message payload and Client Identifier. * Presented different methods for passing the token and PoP. Sengul & Kirby Expires 24 September 2022 [Page 44] Internet-Draft MQTT-TLS profile of ACE March 2022 * Added new figures to explain AUTH packets exchange, updated CONNECT message figure. Acknowledgments The authors would like to thank Ludwig Seitz for his review and his input on the authorization information endpoint; Benjamin Kaduk for his review, insightful comments, and contributions to resolving issues; and Carsten Bormann for his review and revisions to the AIF- MQTT data model. The authors would like to thank Paul Fremantle for the initial discussions on MQTT v5.0 support. Authors' Addresses Cigdem Sengul Brunel University Dept. of Computer Science Uxbridge UB8 3PH United Kingdom Email: csengul@acm.org Anthony Kirby Oxbotica 1a Milford House, Mayfield Road, Summertown Oxford OX2 7EL United Kingdom Email: anthony@anthony.org Sengul & Kirby Expires 24 September 2022 [Page 45] ./draft-ietf-sacm-coswid-22.txt0000644000764400076440000053715714266007707016114 0ustar iustiniustin SACM Working Group H. Birkholz Internet-Draft Fraunhofer SIT Intended status: Standards Track J. Fitzgerald-McKay Expires: 20 January 2023 National Security Agency C. Schmidt The MITRE Corporation D. Waltermire NIST 19 July 2022 Concise Software Identification Tags draft-ietf-sacm-coswid-22 Abstract ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a similar set of semantics and features as SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory efficient format. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 20 January 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Birkholz, et al. Expires 20 January 2023 [Page 1] Internet-Draft CoSWID July 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The SWID and CoSWID Tag Lifecycle . . . . . . . . . . . . 4 1.2. Concise SWID Format . . . . . . . . . . . . . . . . . . . 8 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 8 2. Concise SWID Data Definition . . . . . . . . . . . . . . . . 8 2.1. Character Encoding . . . . . . . . . . . . . . . . . . . 10 2.2. Concise SWID Extensions . . . . . . . . . . . . . . . . . 10 2.3. The concise-swid-tag Map . . . . . . . . . . . . . . . . 13 2.4. concise-swid-tag Co-Constraints . . . . . . . . . . . . . 17 2.5. The global-attributes Group . . . . . . . . . . . . . . . 18 2.6. The entity-entry Map . . . . . . . . . . . . . . . . . . 19 2.7. The link-entry Map . . . . . . . . . . . . . . . . . . . 20 2.8. The software-meta-entry Map . . . . . . . . . . . . . . . 25 2.9. The Resource Collection Definition . . . . . . . . . . . 28 2.9.1. The hash-entry Array . . . . . . . . . . . . . . . . 28 2.9.2. The resource-collection Group . . . . . . . . . . . . 28 2.9.3. The payload-entry Map . . . . . . . . . . . . . . . . 32 2.9.4. The evidence-entry Map . . . . . . . . . . . . . . . 32 2.10. Full CDDL Specification . . . . . . . . . . . . . . . . . 33 3. Determining the Type of CoSWID . . . . . . . . . . . . . . . 39 4. CoSWID Indexed Label Values . . . . . . . . . . . . . . . . . 40 4.1. Version Scheme . . . . . . . . . . . . . . . . . . . . . 40 4.2. Entity Role Values . . . . . . . . . . . . . . . . . . . 42 4.3. Link Ownership Values . . . . . . . . . . . . . . . . . . 44 4.4. Link Rel Values . . . . . . . . . . . . . . . . . . . . . 44 4.5. Link Use Values . . . . . . . . . . . . . . . . . . . . . 46 5. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.1. "swid" URI Scheme . . . . . . . . . . . . . . . . . . . . 47 5.2. "swidpath" URI Scheme . . . . . . . . . . . . . . . . . . 48 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 6.1. CoSWID Items Registry . . . . . . . . . . . . . . . . . . 49 6.2. Software ID Values Registries . . . . . . . . . . . . . . 52 6.2.1. Registration Procedures . . . . . . . . . . . . . . . 52 6.2.2. Private Use of Index and Name Values . . . . . . . . 52 6.2.3. Expert Review Criteria . . . . . . . . . . . . . . . 53 6.2.4. Software ID Version Scheme Values Registry . . . . . 53 6.2.5. Software ID Entity Role Values Registry . . . . . . . 55 Birkholz, et al. Expires 20 January 2023 [Page 2] Internet-Draft CoSWID July 2022 6.2.6. Software ID Link Ownership Values Registry . . . . . 56 6.2.7. Software ID Link Relationship Values Registry . . . . 57 6.2.8. Software ID Link Use Values Registry . . . . . . . . 60 6.3. swid+cbor Media Type Registration . . . . . . . . . . . . 61 6.4. CoAP Content-Format Registration . . . . . . . . . . . . 62 6.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 62 6.6. URI Scheme Registrations . . . . . . . . . . . . . . . . 62 6.6.1. URI-scheme swid . . . . . . . . . . . . . . . . . . . 63 6.6.2. URI-scheme swidpath . . . . . . . . . . . . . . . . . 63 6.7. CoSWID Model for use in SWIMA Registration . . . . . . . 64 7. Signed CoSWID Tags . . . . . . . . . . . . . . . . . . . . . 64 8. CBOR-Tagged CoSWID Tags . . . . . . . . . . . . . . . . . . . 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 67 10. Privacy Consideration . . . . . . . . . . . . . . . . . . . . 71 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 77 12.2. Informative References . . . . . . . . . . . . . . . . . 80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 81 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 1. Introduction SWID tags, as defined in ISO-19770-2:2015 [SWID], provide a standardized XML-based record format that identifies and describes a specific release of software, a patch, or an installation bundle, which are referred to as software components in this document. Different software components, and even different releases of a particular software component, each have a different SWID tag record associated with them. SWID tags are meant to be flexible and able to express a broad set of metadata about a software component. SWID tags are used to support a number of processes including but not limited to: * Software Inventory Management, a part of a Software Asset Management [SAM] process, which requires an accurate list of discernible deployed software components. * Vulnerability Assessment, which requires a semantic link between standardized vulnerability descriptions and software components installed on IT-assets [X.1520]. * Remote Attestation, which requires a link between reference integrity measurements (RIM) and Attester-produced event logs that complement attestation evidence [I-D.ietf-rats-architecture]. Birkholz, et al. Expires 20 January 2023 [Page 3] Internet-Draft CoSWID July 2022 While there are very few required fields in SWID tags, there are many optional fields that support different uses. A SWID tag consisting of only required fields might be a few hundred bytes in size; however, a tag containing many of the optional fields can be many orders of magnitude larger. Thus, real-world instances of SWID tags can be fairly large, and the communication of SWID tags in usage scenarios, such as those described earlier, can cause a large amount of data to be transported. This can be larger than acceptable for constrained devices and networks. Concise SWID (CoSWID) tags significantly reduce the amount of data transported as compared to a typical SWID tag through the use of the Concise Binary Object Representation (CBOR) [RFC8949]. Size comparisons between XML SWID and CoSWID mainly depend on domain- specific applications and the complexity of attributes used in instances. While the values stored in CoSWID are often unchanged and therefore not reduced in size compared to an XML SWID, the scaffolding that the CoSWID encoding represents is significantly smaller by taking up 10 percent or less in size. This effect is visible in representation sizes, which in early experiments benefited from a 50 percent to 85 percent reduction in generic usage scenarios. Additional size reduction is enabled with respect to the memory footprint of XML parsing/validation. In a CoSWID, the human-readable labels of SWID data items are replaced with more concise integer labels (indices). This approach allows SWID and CoSWID to share a common implicit information model, with CoSWID providing an alternate data model [RFC3444]. While SWID and CoSWID are intended to share the same implicit information model, this specification does not define this information model, or a mapping between the two data formats. While an attempt to align SWID and CoSWID tags has been made here, future revisions of ISO/IEC 19770-2:2015 or this specification might cause this implicit information model to diverge, since these specifications are maintained by different standards groups. The use of CBOR to express SWID information in CoSWID tags allows both CoSWID and SWID tags to be part of an enterprise security solution for a wider range of endpoints and environments. 1.1. The SWID and CoSWID Tag Lifecycle In addition to defining the format of a SWID tag record, ISO/IEC 19770-2:2015 defines requirements concerning the SWID tag lifecycle. Specifically, when a software component is installed on an endpoint, that software component's SWID tag is also installed. Likewise, when the software component is uninstalled or replaced, the SWID tag is deleted or replaced, as appropriate. As a result, ISO/IEC Birkholz, et al. Expires 20 January 2023 [Page 4] Internet-Draft CoSWID July 2022 19770-2:2015 describes a system wherein there is a correspondence between the set of installed software components on an endpoint, and the presence of the corresponding SWID tags for these components on that endpoint. CoSWIDs share the same lifecycle requirements as a SWID tag. The SWID specification and supporting guidance provided in NIST Internal Report (NISTIR) 8060: Guidelines for the Creation of Interoperable SWID Tags [SWID-GUIDANCE] defines four types of SWID tags: primary, patch, corpus, and supplemental. The following text is paraphrased from these sources. 1. Primary Tag - A SWID or CoSWID tag that identifies and describes an installed software component on an endpoint. A primary tag is intended to be installed on an endpoint along with the corresponding software component. 2. Patch Tag - A SWID or CoSWID tag that identifies and describes an installed patch that has made incremental changes to a software component installed on an endpoint. A patch tag is intended to be installed on an endpoint along with the corresponding software component patch. 3. Corpus Tag - A SWID or CoSWID tag that identifies and describes an installable software component in its pre-installation state. A corpus tag can be used to represent metadata about an installation package or installer for a software component, a software update, or a patch. 4. Supplemental Tag - A SWID or CoSWID tag that allows additional information to be associated with a referenced SWID tag. This allows tools and users to record their own metadata about a software component without modifying CoSWID primary or patch tags created by a software provider. The type of a tag is determined by specific data elements, which are discussed in Section 3, which also provides normative language for CoSWID semantics that implement this lifecycle. The following information helps to explain how these semantics apply to use of a CoSWID tag. Corpus, primary, and patch tags have similar functions in that they describe the existence and/or presence of different types of software components (e.g., software installers, software installations, software patches), and, potentially, different states of these software components. Supplemental tags have the same structure as other tags, but are used to provide information not contained in the referenced corpus, primary, and patch tags. Birkholz, et al. Expires 20 January 2023 [Page 5] Internet-Draft CoSWID July 2022 All four tag types come into play at various points in the software lifecycle and support software management processes that depend on the ability to accurately determine where each software component is in its lifecycle. +------------+ v | Software Software Software Software Software Deployment -> Installation -> Patching -> Upgrading -> Removal Corpus Primary Primary xPrimary xPrimary Supplemental Supplemental Supplemental xSupplemental xSupplemental Patch xPatch Primary Supplemental Figure 1: Use of Tag Types in the Software Lifecycle Figure 1 illustrates the steps in the software lifecycle and the relationships among those lifecycle events supported by the four types of SWID and CoSWID tags. A detailed description of the four tags types is provided in Section 2.3. The figure identifies the types of tags that are used in each lifecycle event. There are many ways in which software tags might be managed for the host the software is installed on. For example, software tags could be made available on the host or to an external software manager when storage is limited on the host. In these cases the host or external software manager is responsible for management of the tags, including deployment and removal of the tags as indicated by the above lifecycle. Tags are deployed and previously deployed tags that are typically removed (indicated by an "x" prefix) at each lifecycle stage, as follows: - Software Deployment. Before the software component is installed (i.e., pre-installation), and while the product is being deployed, a corpus tag provides information about the installation files and distribution media (e.g., CD/DVD, distribution package). Corpus tags are not actually deployed on the target system but are intended to support deployment procedures and their dependencies at install-time, such as to verify the installation media. - Software Installation. A primary tag will be installed with the software component (or subsequently created) to uniquely identify and describe the software component. Supplemental Birkholz, et al. Expires 20 January 2023 [Page 6] Internet-Draft CoSWID July 2022 tags are created to augment primary tags with additional site- specific or extended information. While not illustrated in the figure, patch tags can also be installed during software installation to provide information about software fixes deployed along with the base software installation. - Software Patching. A new patch tag is provided, when a patch is applied to the software component, supplying details about the patch and its dependencies. While not illustrated in the figure, a corpus tag can also provide information about the patch installer and patching dependencies that need to be installed before the patch. - Software Upgrading. As a software component is upgraded to a new version, new primary and supplemental tags replace existing tags, enabling timely and accurate tracking of updates to software inventory. While not illustrated in the figure, a corpus tag can also provide information about the upgrade installer and dependencies that need to be installed before the upgrade. Note: In the context of software tagging software patching and updating differ in an important way. When installing a patch, a set of file modifications are made to pre-installed software which do not alter the version number or the descriptive metadata of an installed software component. An update can also make a set of file modifications, but the version number or the descriptive metadata of an installed software component are changed. - Software Removal. Upon removal of the software component, relevant SWID tags are removed. This removal event can trigger timely updates to software inventory reflecting the removal of the product and any associated patch or supplemental tags. As illustrated in the figure, supplemental tags can be associated with any corpus, primary, or patch tag to provide additional metadata about an installer, installed software, or installed patch respectively. Understanding the use of CoSWIDs in the software lifecycle provides a basis for understanding the information provided in a CoSWID and the associated semantics of this information. Each of the different SWID and CoSWID tag types provide different sets of information. For example, a "corpus tag" is used to describe a software component's installation image on an installation media, while a "patch tag" is meant to describe a patch that modifies some other software component. Birkholz, et al. Expires 20 January 2023 [Page 7] Internet-Draft CoSWID July 2022 1.2. Concise SWID Format This document defines the CoSWID tag format, which is based on CBOR. CBOR-based CoSWID tags offer a more concise representation of SWID information as compared to the XML-based SWID tag representation in ISO-19770-2:2015. The structure of a CoSWID is described via the Concise Data Definition Language (CDDL) [RFC8610]. The resulting CoSWID data definition is aligned to the information able to be expressed with the XML schema definition of ISO-19770-2:2015 [SWID]. This alignment allows both SWID and CoSWID tags to represent a common set of software component information and allows CoSWID tags to support the same uses as a SWID tag. The vocabulary, i.e., the CDDL names of the types and members used in the CoSWID CDDL specification, are mapped to more concise labels represented as small integer values (indices). The names used in the CDDL specification and the mapping to the CBOR representation using integer indices is based on the vocabulary of the XML attribute and element names defined in ISO/IEC 19770-2:2015. 1.3. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Concise SWID Data Definition The following describes the general rules and processes for encoding data using CDDL representation. Prior familiarity with CBOR and CDDL concepts will be helpful in understanding this CoSWID specification. This section describes the conventions by which a CoSWID is represented in the CDDL structure. The CamelCase [CamelCase] notation used in the XML schema definition is changed to a hyphen- separated notation [KebabCase] (e.g., ResourceCollection is named resource-collection) in the CoSWID CDDL specification. This deviation from the original notation used in the XML representation reduces ambiguity when referencing certain attributes in corresponding textual descriptions. An attribute referred to by its name in CamelCase notation explicitly relates to XML SWID tags; an attribute referred to by its name in KebabCase notation explicitly relates to CBOR CoSWID tags. This approach simplifies the composition of further work that reference both XML SWID and CBOR CoSWID documents. Birkholz, et al. Expires 20 January 2023 [Page 8] Internet-Draft CoSWID July 2022 In most cases, mapping attribute names between SWID and CoSWID can be done automatically by converting between CamelCase and KebabCase attribute names. However, some CoSWID CDDL attribute names show greater variation relative to their corresponding SWID XML Schema attributes. This is done when the change improves clarity in the CoSWID specification. For example, the "name" and "version" SWID fields corresponds to the "software-name" and "software-version" CoSWID fields, respectively. As such, it is not always possible to mechanically translate between corresponding attribute names in the two formats. In such cases, a manual mapping will need to be used. XPath expressions [W3C.REC-xpath20-20101214] need to use SWID names, see Section 5.2. The 57 human-readable text labels of the CDDL-based CoSWID vocabulary are mapped to integer indices via a block of rules at the bottom of the definition. This allows a more concise integer-based form to be stored or transported, as compared to the less efficient text-based form of the original vocabulary. Through use of CDDL-based integer labels, CoSWID allows for future expansion in subsequent revisions of this specification and through extensions (see Section 2.2). New constructs can be associated with a new integer index. A deprecated construct can be replaced by a new construct with a new integer index. An implementation can use these integer indexes to identify the construct to parse. The CoSWID Items registry, defined in Section 6.1, is used to ensure that new constructs are assigned a unique index value. This approach avoids the need to have an explicit CoSWID version. In a number of places, the value encoding admits both integer values and text strings. The integer values are defined in a registry specific to the kind of value; the text values are not intended for interchange and exclusively meant for private use as defined in Section 6.2.2. Encoders SHOULD NOT use string values based on the names registered in the registry, as these values are less concise than their index value equivalent; a decoder MUST however be prepared to accept text strings that are not specified in this document (and ignore the construct if that string is unknown). In the rest of the document, we call this an "integer label with text escape". The root of the CDDL specification provided by this document is the rule coswid (as defined in Section 8): start = coswid In CBOR, an array is encoded using bytes that identify the array, and the array's length or stop point (see [RFC8949]). To make items that support 1 or more values, the following CDDL notation is used. Birkholz, et al. Expires 20 January 2023 [Page 9] Internet-Draft CoSWID July 2022 _name_ = (_label_ => _data_ / [ 2* _data_ ]) The CDDL rule above allows either a single data item or an array of 2 or more data values to be provided. When a singleton data value is provided, the CBOR markers for the array, array length, and stop point are not needed, saving bytes. When two or more data values are provided, these values are encoded as an array. This modeling pattern is used frequently in the CoSWID CDDL specification to allow for more efficient encoding of singleton values. Usage of this construct can be simplified using one-or-more = T / [ 2* T ] simplifying the above example to _name_ = (_label_ => one-or-more<_data_>) The following subsections describe the different parts of the CoSWID model. 2.1. Character Encoding The CDDL "text" type is represented in CBOR as a major type 3, which represents "a string of Unicode characters that [are] encoded as UTF-8 [RFC3629]" (see Section 3.1 of [RFC8949]). Thus both SWID and CoSWID use UTF-8 for the encoding of characters in text strings. To ensure that UTF-8 character strings are able to be encoded/decoded and exchanged interoperably, text strings in CoSWID MUST be encoded consistent with the Net-Unicode definition defined in [RFC5198]. All names registered with IANA according to requirements in Section 6.2 also MUST be valid according to the XML Schema NMTOKEN data type (see [W3C.REC-xmlschema-2-20041028], Section 3.3.4) to ensure compatibility with the SWID specification where these names are used. 2.2. Concise SWID Extensions The CoSWID specification contains two features that are not included in the SWID specification on which it is based. These features are: * The explicit definition of types for some attributes in the ISO- 19770-2:2015 XML representation that are typically represented by the "any attribute" in the SWID model. These are covered in Section 2.5. Birkholz, et al. Expires 20 January 2023 [Page 10] Internet-Draft CoSWID July 2022 * The inclusion of extension points in the CoSWID specification using CDDL sockets (see Section 3.9 of [RFC8610]). The use of CDDL sockets allow for well-formed extensions to be defined in supplementary CDDL descriptions that support additional uses of CoSWID tags that go beyond the original scope of ISO-19770-2:2015 tags. The following CDDL sockets (extension points) are defined in this document, which allow the addition of new information structures to their respective CDDL groups. Birkholz, et al. Expires 20 January 2023 [Page 11] Internet-Draft CoSWID July 2022 +=====================+=================================+=========+ | Map Name | CDDL Socket | Defined | | | | in | +=====================+=================================+=========+ | concise-swid-tag | $$coswid-extension | Section | | | | 2.3 | +---------------------+---------------------------------+---------+ | entity-entry | $$entity-extension | Section | | | | 2.6 | +---------------------+---------------------------------+---------+ | link-entry | $$link-extension | Section | | | | 2.7 | +---------------------+---------------------------------+---------+ | software-meta-entry | $$software-meta-extension | Section | | | | 2.8 | +---------------------+---------------------------------+---------+ | resource-collection | $$resource-collection-extension | Section | | | | 2.9.2 | +---------------------+---------------------------------+---------+ | file-entry | $$file-extension | Section | | | | 2.9.2 | +---------------------+---------------------------------+---------+ | directory-entry | $$directory-extension | Section | | | | 2.9.2 | +---------------------+---------------------------------+---------+ | process-entry | $$process-extension | Section | | | | 2.9.2 | +---------------------+---------------------------------+---------+ | resource-entry | $$resource-extension | Section | | | | 2.9.2 | +---------------------+---------------------------------+---------+ | payload-entry | $$payload-extension | Section | | | | 2.9.3 | +---------------------+---------------------------------+---------+ | evidence-entry | $$evidence-extension | Section | | | | 2.9.4 | +---------------------+---------------------------------+---------+ Table 1: CoSWID CDDL Group Extension Points The CoSWID Items Registry defined in Section 6.1 provides a registration mechanism allowing new items, and their associated index values, to be added to the CoSWID model through the use of the CDDL sockets described in the table above. This registration mechanism provides for well-known index values for data items in CoSWID extensions, allowing these index values to be recognized by implementations supporting a given extension. Birkholz, et al. Expires 20 January 2023 [Page 12] Internet-Draft CoSWID July 2022 The following additional CDDL sockets are defined in this document to allow for adding new values to corresponding type-choices (i.e. to represent enumerations) via custom CDDL specifications. +==================+=================+=============+ | Enumeration Name | CDDL Socket | Defined in | +==================+=================+=============+ | version-scheme | $version-scheme | Section 4.1 | +------------------+-----------------+-------------+ | role | $role | Section 4.2 | +------------------+-----------------+-------------+ | ownership | $ownership | Section 4.3 | +------------------+-----------------+-------------+ | rel | $rel | Section 4.4 | +------------------+-----------------+-------------+ | use | $use | Section 4.5 | +------------------+-----------------+-------------+ Table 2: CoSWID CDDL Enumeration Extension Points A number of CoSWID value registries are also defined in Section 6.2 that allow new values to be registered with IANA for the enumerations above. This registration mechanism supports the definition of new well-known index values and names for new enumeration values used by CoSWID, which can also be used by other software tagging specifications. This registration mechanism allows new standardized enumerated values to be shared between multiple tagging specifications (and associated implementations) over time. 2.3. The concise-swid-tag Map The CDDL specification for the root concise-swid-tag map is as follows and this rule and its constraints MUST be followed when creating or validating a CoSWID tag: Birkholz, et al. Expires 20 January 2023 [Page 13] Internet-Draft CoSWID July 2022 concise-swid-tag = { tag-id => text / bstr .size 16, tag-version => integer, ? corpus => bool, ? patch => bool, ? supplemental => bool, software-name => text, ? software-version => text, ? version-scheme => $version-scheme, ? media => text, ? software-meta => one-or-more, entity => one-or-more, ? link => one-or-more, ? payload-or-evidence, * $$coswid-extension, global-attributes, } payload-or-evidence //= ( payload => payload-entry ) payload-or-evidence //= ( evidence => evidence-entry ) tag-id = 0 software-name = 1 entity = 2 evidence = 3 link = 4 software-meta = 5 payload = 6 corpus = 8 patch = 9 media = 10 supplemental = 11 tag-version = 12 software-version = 13 version-scheme = 14 $version-scheme /= multipartnumeric $version-scheme /= multipartnumeric-suffix $version-scheme /= alphanumeric $version-scheme /= decimal $version-scheme /= semver $version-scheme /= int / text multipartnumeric = 1 multipartnumeric-suffix = 2 alphanumeric = 3 decimal = 4 semver = 16384 Birkholz, et al. Expires 20 January 2023 [Page 14] Internet-Draft CoSWID July 2022 The following describes each member of the concise-swid-tag root map. * global-attributes: A list of items including an optional language definition to support the processing of text-string values and an unbounded set of any-attribute items. Described in Section 2.5. * tag-id (index 0): A 16-byte binary string, or a textual identifier, uniquely referencing a software component. The tag identifier MUST be globally unique. Failure to ensure global uniqueness can create ambiguity in tag use since the tag-id serves as the global key for matching and lookups. If represented as a 16-byte binary string, the identifier MUST be a valid universally unique identifier as defined by [RFC4122]. There are no strict guidelines on how the identifier is structured, but examples include a 16-byte GUID (e.g., class 4 UUID) [RFC4122], or a DNS domain name followed by a "/" and a text string, where the domain name serves to ensure uniqueness across organizations. A textual tag-id MUST NOT contain a sequence of two underscores ("__", see Section 6.7). * tag-version (index 12): An integer value that indicate the specific release revision of the tag. Typically, the initial value of this field is set to 0 and the value is increased for subsequent tags produced for the same software component release. This value allows a CoSWID tag producer to correct an incorrect tag previously released without indicating a change to the underlying software component the tag represents. For example, the tag version could be changed to add new metadata, to correct a broken link, to add a missing payload entry, etc. When producing a revised tag, the new tag-version value MUST be greater than the old tag-version value. * corpus (index 8): A boolean value that indicates if the tag identifies and describes an installable software component in its pre-installation state. Installable software includes an installation package or installer for a software component, a software update, or a patch. If the CoSWID tag represents installable software, the corpus item MUST be set to "true". If not provided, the default value MUST be considered "false". * patch (index 9): A boolean value that indicates if the tag identifies and describes an installed patch that has made incremental changes to a software component installed on an endpoint. If a CoSWID tag is for a patch, the patch item MUST be set to "true". If not provided, the default value MUST be considered "false". A patch item's value MUST NOT be set to "true" if the installation of the associated software package changes the version of a software component. Birkholz, et al. Expires 20 January 2023 [Page 15] Internet-Draft CoSWID July 2022 * supplemental (index 11): A boolean value that indicates if the tag is providing additional information to be associated with another referenced SWID or CoSWID tag. This allows tools and users to record their own metadata about a software component without modifying SWID primary or patch tags created by a software provider. If a CoSWID tag is a supplemental tag, the supplemental item MUST be set to "true". If not provided, the default value MUST be considered "false". * software-name (index 1): This textual item provides the software component's name. This name is likely the same name that would appear in a package management tool. This item maps to '/SoftwareIdentity/@name' in [SWID]. * software-version (index 13): A textual value representing the specific release or development version of the software component. This item maps to '/SoftwareIdentity/@version' in [SWID]. * version-scheme (index 14): An integer or textual value representing the versioning scheme used for the software-version item, as an integer label with text escape (Section 2, for the "Version Scheme" registry Section 4.1). If an integer value is used it MUST be an index value in the range -256 to 65535. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see Section 6.2.2). Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software ID Version Scheme Values" registry (see Section 6.2.4). * media (index 10): This text value is a hint to the tag consumer to understand what target platform this tag applies to. This item MUST be formatted as a query as defined by the W3C Media Queries Recommendation (see [W3C.REC-css3-mediaqueries-20120619]). Support for media queries are included here for interoperability with [SWID], which does not provide any further requirements for media query use. Thus, this specification does not clarify how a media query is to be used for a CoSWID. * software-meta (index 5): An open-ended map of key/value data pairs. A number of predefined keys can be used within this item providing for common usage and semantics across the industry. Use of this map allows any additional attribute to be included in the tag. It is expected that industry groups will use a common set of attribute names to allow for interoperability within their communities. Described in Section 2.8. This item maps to '/SoftwareIdentity/Meta' in [SWID]. Birkholz, et al. Expires 20 January 2023 [Page 16] Internet-Draft CoSWID July 2022 * entity (index 2): Provides information about one or more organizations responsible for producing the CoSWID tag, and producing or releasing the software component referenced by this CoSWID tag. Described in Section 2.6. * link (index 4): Provides a means to establish relationship arcs between the tag and another items. A given link can be used to establish the relationship between tags or to reference another resource that is related to the CoSWID tag, e.g., vulnerability database association, ROLIE feed [RFC8322], MUD resource [RFC8520], software download location, etc). This is modeled after the HTML "link" element. Described in Section 2.7. * payload (index 6): This item represents a collection of software artifacts (described by child items) that compose the target software. For example, these artifacts could be the files included with an installer for a corpus tag or installed on an endpoint when the software component is installed for a primary or patch tag. The artifacts listed in a payload may be a superset of the software artifacts that are actually installed. Based on user selections at install time, an installation might not include every artifact that could be created or executed on the endpoint when the software component is installed or run. This item is mutually exclusive to evidence, as payload can only be provided by an external entity. Described in Section 2.9.3. * evidence (index 3): This item can be used to record the results of a software discovery process used to identify untagged software on an endpoint or to represent indicators for why software is believed to be installed on the endpoint. In either case, a CoSWID tag can be created by the tool performing an analysis of the software components installed on the endpoint. This item is mutually exclusive to payload, as evidence is always generated on the target device ad-hoc. Described in Section 2.9.4. * $$coswid-extension: This CDDL socket is used to add new information structures to the concise-swid-tag root map. See Section 2.2. 2.4. concise-swid-tag Co-Constraints The following co-constraints apply to the information provided in the concise-swid-tag group. * The patch and supplemental items MUST NOT both be set to "true". Birkholz, et al. Expires 20 January 2023 [Page 17] Internet-Draft CoSWID July 2022 * If the patch item is set to "true", the tag MUST contain at least one link item (see Section 2.7) with both the rel item value of "patches" and an href item specifying an association with the software that was patched. Without at least one link item the target of the patch cannot be identified and the patch tag cannot be applied without external context. * If all of the corpus, patch, and supplemental items are "false", or if the corpus item is set to "true", then a software-version item MUST be included with a value set to the version of the software component. This ensures that primary and corpus tags have an identifiable software version. 2.5. The global-attributes Group The global-attributes group provides a list of items, including an optional language definition to support the processing of text-string values, and an unbounded set of any-attribute items allowing for additional items to be provided as a general point of extension in the model. The CDDL for the global-attributes follows: global-attributes = ( ? lang => text, * any-attribute, ) any-attribute = ( label => one-or-more / one-or-more ) label = text / int The following describes each child item of this group. * lang (index 15): A textual language tag that conforms with IANA "Language Subtag Registry" [RFC5646]. The context of the specified language applies to all sibling and descendant textual values, unless a descendant object has defined a different language tag. Thus, a new context is established when a descendant object redefines a new language tag. All textual values within a given context MUST be considered expressed in the specified language. Birkholz, et al. Expires 20 January 2023 [Page 18] Internet-Draft CoSWID July 2022 * any-attribute: This sub-group provides a means to include arbitrary information via label/index ("key") value pairs. Labels can be either a single integer or text string. Values can be a single integer, a text string, or an array of integers or text strings. 2.6. The entity-entry Map The CDDL for the entity-entry map follows: entity-entry = { entity-name => text, ? reg-id => any-uri, role => one-or-more<$role>, ? thumbprint => hash-entry, * $$entity-extension, global-attributes, } entity-name = 31 reg-id = 32 role = 33 thumbprint = 34 $role /= tag-creator $role /= software-creator $role /= aggregator $role /= distributor $role /= licensor $role /= maintainer $role /= int / text tag-creator=1 software-creator=2 aggregator=3 distributor=4 licensor=5 maintainer=6 The following describes each child item of this group. * global-attributes: The global-attributes group described in Section 2.5. * entity-name (index 31): The textual name of the organizational entity claiming the roles specified by the role item for the CoSWID tag. This item maps to '/SoftwareIdentity/Entity/@name' in [SWID]. Birkholz, et al. Expires 20 January 2023 [Page 19] Internet-Draft CoSWID July 2022 * reg-id (index 32): The registration id value is intended to uniquely identify a naming authority in a given scope (e.g., global, organization, vendor, customer, administrative domain, etc.) for the referenced entity. The value of a registration ID MUST be a RFC 3986 URI; it is not intended to be dereferenced. The scope will usually be the scope of an organization. * role (index 33): An integer or textual value (integer label with text escape, see Section 2) representing the relationship(s) between the entity, and this tag or the referenced software component. If an integer value is used it MUST be an index value in the range -256 to 255. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see Section 6.2.2). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Software ID Entity Role Values" registry (see Section 6.2.5). The following additional requirements exist for the use of the "role" item: - An entity item MUST be provided with the role of "tag-creator" for every CoSWID tag. This indicates the organization that created the CoSWID tag. - An entity item SHOULD be provided with the role of "software- creator" for every CoSWID tag, if this information is known to the tag creator. This indicates the organization that created the referenced software component. * thumbprint (index 34): The value of the thumbprint item provides a hash (i.e. the thumbprint) of the signing entity's public key certificate. This provides an indicator of which entity signed the CoSWID tag, which will typically be the tag creator. See Section 2.9.1 for more details on the use of the hash-entry data structure. * $$entity-extension: This CDDL socket can be used to extend the entity-entry group model. See Section 2.2. 2.7. The link-entry Map The CDDL for the link-entry map follows: Birkholz, et al. Expires 20 January 2023 [Page 20] Internet-Draft CoSWID July 2022 link-entry = { ? artifact => text, href => any-uri, ? media => text, ? ownership => $ownership, rel => $rel, ? media-type => text, ? use => $use, * $$link-extension, global-attributes, } media = 10 artifact = 37 href = 38 ownership = 39 rel = 40 media-type = 41 use = 42 $ownership /= shared $ownership /= private $ownership /= abandon $ownership /= int / text abandon=1 private=2 shared=3 $rel /= ancestor $rel /= component $rel /= feature $rel /= installationmedia $rel /= packageinstaller $rel /= parent $rel /= patches $rel /= requires $rel /= see-also $rel /= supersedes $rel /= supplemental $rel /= -356..65536 / text ancestor=1 component=2 feature=3 installationmedia=4 packageinstaller=5 parent=6 patches=7 requires=8 Birkholz, et al. Expires 20 January 2023 [Page 21] Internet-Draft CoSWID July 2022 see-also=9 supersedes=10 supplemental=11 $use /= optional $use /= required $use /= recommended $use /= int / text optional=1 required=2 recommended=3 The following describes each member of this map. * global-attributes: The global-attributes group described in Section 2.5. * artifact (index 37): To be used with rel="installationmedia", this item's value provides the absolute filesystem path to the installer executable or script that can be run to launch the referenced installation. Links with the same artifact name MUST be considered mirrors of each other, allowing the installation media to be acquired from any of the described sources. * href (index 38): A URI-reference [RFC3986] for the referenced resource. The "href" item's value can be, but is not limited to, the following (which is a slightly modified excerpt from [SWID]): - If no URI scheme is provided, then the URI-reference is a relative reference relative to the base URI of the CoSWID tag, i.e., the URI under which the CoSWID tag was provided. For example, "./folder/supplemental.coswid". - a physical resource location with any acceptable URI scheme (e.g., file:// http:// https:// ftp://) - a URI with "swid:" as the scheme refers to another SWID or CoSWID by the referenced tag's tag-id. This URI needs to be resolved in the context of the endpoint by software that can lookup other SWID or CoSWID tags. For example, "swid:2df9de35- 0aff-4a86-ace6-f7dddd1ade4c" references the tag with the tag-id value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c". Birkholz, et al. Expires 20 January 2023 [Page 22] Internet-Draft CoSWID July 2022 - a URI with "swidpath:" as the scheme, which refers to another software tag via an XPATH query [W3C.REC-xpath20-20101214] that matches items in that tag (Section 5.2). This scheme is provided for compatibility with [SWID]. This specification does not define how to resolve an XPATH query in the context of CBOR, see Section 5.2. * media (index 10): A hint to the consumer of the link to what target platform the link is applicable to. This item represents a query as defined by the W3C Media Queries Recommendation (see [W3C.REC-css3-mediaqueries-20120619]). As highlighted in media defined in Section 2.3, support for media queries are included here for interoperability with [SWID], which does not provide any further requirements for media query use. Thus, this specification does not clarify how a media query is to be used for a CoSWID. * ownership (index 39): An integer or textual value (integer label with text escape, see Section 2, for the "Software ID Link Ownership Values" registry Section 4.3) used when the "href" item references another software component to indicate the degree of ownership between the software component referenced by the CoSWID tag and the software component referenced by the link. If an integer value is used it MUST be an index value in the range -256 to 255. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see Section 6.2.2). Integer values in the range 0 to 255 correspond to registered entries in the "Software ID Link Ownership Values" registry. Birkholz, et al. Expires 20 January 2023 [Page 23] Internet-Draft CoSWID July 2022 * rel (index 40): An integer or textual value that (integer label with text escape, see Section 2, for the "Software ID Link Link Relationship Values" registry Section 4.3) identifies the relationship between this CoSWID and the target resource identified by the "href" item. If an integer value is used it MUST be an index value in the range -256 to 65535. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see Section 6.2.2). Integer values in the range 0 to 65535 correspond to registered entries in the IANA "Software ID Link Relationship Values" registry (see Section 6.2.7). If a string value is used it MUST be either a private use name as defined in Section 6.2.2 or a "Relation Name" from the IANA "Link Relation Types" registry: https://www.iana.org/assignments/link- relations/link-relations.xhtml as defined by [RFC8288]. When a string value defined in the IANA "Software ID Link Relationship Values" registry matches a Relation Name defined in the IANA "Link Relation Types" registry, the index value in the IANA "Software ID Link Relationship Values" registry MUST be used instead, as this relationship has a specialized meaning in the context of a CoSWID tag. String values correspond to registered entries in the "Software ID Link Relationship Values" registry. * media-type (index 41): A link can point to arbitrary resources on the endpoint, local network, or Internet using the href item. Use of this item supplies the resource consumer with a hint of what type of resource to expect. (This is a _hint_: There is no obligation for the server hosting the target of the URI to use the indicated media type when the URI is dereferenced.) Media types are identified by referencing a "Name" from the IANA "Media Types" registry: http://www.iana.org/assignments/media-types/media- types.xhtml. This item maps to '/SoftwareIdentity/Link/@type' in [SWID]. * use (index 42): An integer or textual value (integer label with text escape, see Section 2, for the "Software ID Link Link Relationship Values" registry Section 4.3) used to determine if the referenced software component has to be installed before installing the software component identified by the COSWID tag. If an integer value is used it MUST be an index value in the range -256 to 255. Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see Section 6.2.2). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Link Use Values" registry (see Section 6.2.8). If a string value is used it MUST be a private use name as defined in Section 6.2.2. String values correspond to registered entries in the "Software ID Link Use Values" registry. Birkholz, et al. Expires 20 January 2023 [Page 24] Internet-Draft CoSWID July 2022 * $$link-extension: This CDDL socket can be used to extend the link- entry map model. See Section 2.2. 2.8. The software-meta-entry Map The CDDL for the software-meta-entry map follows: software-meta-entry = { ? activation-status => text, ? channel-type => text, ? colloquial-version => text, ? description => text, ? edition => text, ? entitlement-data-required => bool, ? entitlement-key => text, ? generator => text / bstr .size 16, ? persistent-id => text, ? product => text, ? product-family => text, ? revision => text, ? summary => text, ? unspsc-code => text, ? unspsc-version => text, * $$software-meta-extension, global-attributes, } activation-status = 43 channel-type = 44 colloquial-version = 45 description = 46 edition = 47 entitlement-data-required = 48 entitlement-key = 49 generator = 50 persistent-id = 51 product = 52 product-family = 53 revision = 54 summary = 55 unspsc-code = 56 unspsc-version = 57 The following describes each child item of this group. * global-attributes: The global-attributes group described in Section 2.5. Birkholz, et al. Expires 20 January 2023 [Page 25] Internet-Draft CoSWID July 2022 * activation-status (index 43): A textual value that identifies how the software component has been activated, which might relate to specific terms and conditions for its use (e.g., Trial, Serialized, Licensed, Unlicensed, etc) and relate to an entitlement. This attribute is typically used in supplemental tags as it contains information that might be selected during a specific install. * channel-type (index 44): A textual value that identifies which sales, licensing, or marketing channel the software component has been targeted for (e.g., Volume, Retail, OEM, Academic, etc). This attribute is typically used in supplemental tags as it contains information that might be selected during a specific install. * colloquial-version (index 45): A textual value for the software component's informal or colloquial version. Examples may include a year value, a major version number, or similar value that are used to identify a group of specific software component releases that are part of the same release/support cycle. This version can be the same through multiple releases of a software component, while the software-version specified in the concise-swid-tag group is much more specific and will change for each software component release. This version is intended to be used for string comparison (byte-by-byte) only and is not intended to be used to determine if a specific value is earlier or later in a sequence. * description (index 46): A textual value that provides a detailed description of the software component. This value MAY be multiple paragraphs separated by CR LF characters as described by [RFC5198]. * edition (index 47): A textual value indicating that the software component represents a functional variation of the code base used to support multiple software components. For example, this item can be used to differentiate enterprise, standard, or professional variants of a software component. * entitlement-data-required (index 48): A boolean value that can be used to determine if accompanying proof of entitlement is needed when a software license reconciliation process is performed. * entitlement-key (index 49): A vendor-specific textual key that can be used to identify and establish a relationship to an entitlement. Examples of an entitlement-key might include a serial number, product key, or license key. For values that relate to a given software component install (i.e., license key), a supplemental tag will typically contain this information. In Birkholz, et al. Expires 20 January 2023 [Page 26] Internet-Draft CoSWID July 2022 other cases, where a general-purpose key can be provided that applies to all possible installs of the software component on different endpoints, a primary tag will typically contain this information. Since CoSWID tags are not intended to contain confidential information, tag authors are advised not to record unprotected, private software license keys in this field. * generator (index 50): The name (or tag-id) of the software component that created the CoSWID tag. If the generating software component has a SWID or CoSWID tag, then the tag-id for the generating software component SHOULD be provided. * persistent-id (index 51): A globally unique identifier used to identify a set of software components that are related. Software components sharing the same persistent-id can be different versions. This item can be used to relate software components, released at different points in time or through different release channels, that may not be able to be related through use of the link item. * product (index 52): A basic name for the software component that can be common across multiple tagged software components (e.g., Apache HTTPD). * product-family (index 53): A textual value indicating the software components overall product family. This should be used when multiple related software components form a larger capability that is installed on multiple different endpoints. For example, some software families may consist of server, client, and shared service components that are part of a larger capability. Email systems, enterprise applications, backup services, web conferencing, and similar capabilities are examples of families. Use of this item is not intended to represent groups of software that are bundled or installed together. The persistent-id or link items SHOULD be used to relate bundled software components. * revision (index 54): A string value indicating an informal or colloquial release version of the software. This value can provide a different version value as compared to the software- version specified in the concise-swid-tag group. This is useful when one or more releases need to have an informal version label that differs from the specific exact version value specified by software-version. Examples can include SP1, RC1, Beta, etc. * summary (index 55): A short description of the software component. This MUST be a single sentence suitable for display in a user interface. Birkholz, et al. Expires 20 January 2023 [Page 27] Internet-Draft CoSWID July 2022 * unspsc-code (index 56): An 8 digit UNSPSC classification code for the software component as defined by the United Nations Standard Products and Services Code (UNSPSC, [UNSPSC]). * unspsc-version (index 57): The version of UNSPSC used to define the unspsc-code value. * $$meta-extension: This CDDL socket can be used to extend the software-meta-entry group model. See Section 2.2. 2.9. The Resource Collection Definition 2.9.1. The hash-entry Array CoSWID adds explicit support for the representation of hash entries using algorithms that are registered in the IANA "Named Information Hash Algorithm Registry" [IANA.named-information] using the hash member (index 7) and the corresponding hash-entry type. This is the equivalent of the namespace qualified "hash" attribute in [SWID]. hash-entry = [ hash-alg-id: int, hash-value: bytes, ] The number used as a value for hash-alg-id is an integer-based hash algorithm identifier who's value MUST refer to an ID in the IANA "Named Information Hash Algorithm Registry" [IANA.named-information] with a Status of "current" (at the time the generator software was built or later); other hash algorithms MUST NOT be used. If the hash-alg-id is not known, then the integer value "0" MUST be used. This allows for conversion from ISO SWID tags [SWID], which do not allow an algorithm to be identified for this field. The hash-value MUST represent the raw hash value as a byte string (as opposed to, e.g., base64 encoded) generated from the representation of the resource using the hash algorithm indicated by hash-alg-id. 2.9.2. The resource-collection Group A list of items both used in evidence (created by a software discovery process) and payload (installed in an endpoint) content of a CoSWID tag document to structure and differentiate the content of specific CoSWID tag types. Potential content includes directories, files, processes, or resources. The CDDL for the resource-collection group follows: Birkholz, et al. Expires 20 January 2023 [Page 28] Internet-Draft CoSWID July 2022 path-elements-group = ( ? directory => one-or-more, ? file => one-or-more, ) resource-collection = ( path-elements-group, ? process => one-or-more, ? resource => one-or-more, * $$resource-collection-extension, ) filesystem-item = ( ? key => bool, ? location => text, fs-name => text, ? root => text, ) file-entry = { filesystem-item, ? size => uint, ? file-version => text, ? hash => hash-entry, * $$file-extension, global-attributes, } directory-entry = { filesystem-item, ? path-elements => { path-elements-group }, * $$directory-extension, global-attributes, } process-entry = { process-name => text, ? pid => integer, * $$process-extension, global-attributes, } resource-entry = { type => text, * $$resource-extension, global-attributes, } directory = 16 Birkholz, et al. Expires 20 January 2023 [Page 29] Internet-Draft CoSWID July 2022 file = 17 process = 18 resource = 19 size = 20 file-version = 21 key = 22 location = 23 fs-name = 24 root = 25 path-elements = 26 process-name = 27 pid = 28 type = 29 The following describes each member of the groups and maps illustrated above. * filesystem-item: A list of common items used for representing the filesystem root, relative location, name, and significance of a file or directory item. * global-attributes: The global-attributes group described in Section 2.5. * directory (index 16): A directory item allows child directory and file items to be defined within a directory hierarchy for the software component. * file (index 17): A file item allows details about a file to be provided for the software component. * process (index 18): A process item allows details to be provided about the runtime behavior of the software component, such as information that will appear in a process listing on an endpoint. * resource (index 19): A resource item can be used to provide details about an artifact or capability expected to be found on an endpoint or evidence collected related to the software component. This can be used to represent concepts not addressed directly by the directory, file, or process items. Examples include: registry keys, bound ports, etc. The equivalent construct in [SWID] is currently under specified. As a result, this item might be further defined through extension in the future. * size (index 20): The file's size in bytes. Birkholz, et al. Expires 20 January 2023 [Page 30] Internet-Draft CoSWID July 2022 * file-version (index 21): The file's version as reported by querying information on the file from the operating system (if available). This item maps to '/SoftwareIdentity/(Payload|Evidence)/File/@version' in [SWID]. * hash (index 7): A hash of the file as described in Section 2.9.1. * key (index 22): A boolean value indicating if a file or directory is significant or required for the software component to execute or function properly. These are files or directories that can be used to affirmatively determine if the software component is installed on an endpoint. * location (index 23): The filesystem path where a file is expected to be located when installed or copied. The location MUST be either relative to the location of the parent directory item (preferred), or relative to the location of the CoSWID tag (as indicated in the location value in the evidence entry map) if no parent is defined. The location MUST NOT include a file's name, which is provided by the fs-name item. * fs-name (index 24): The name of the directory or file without any path information. This aligns with a file "name" in [SWID]. This item maps to '/SoftwareIdentity/(Payload|Evidence)/(File|Directory)/@name' in [SWID]. * root (index 25): A host-specific name for the root of the filesystem. The location item is considered relative to this location if specified. If not provided, the value provided by the location item is expected to be relative to its parent or the location of the CoSWID tag if no parent is provided. * path-elements (index 26): This group allows a hierarchy of directory and file items to be defined in payload or evidence items. This is a construction within the CDDL definition of CoSWID to support shared syntax and does not appear in [SWID]. * process-name (index 27): The software component's process name as it will appear in an endpoint's process list. This aligns with a process "name" in [SWID]. This item maps to '/SoftwareIdentity/(Payload|Evidence)/Process/@name' in [SWID]. * pid (index 28): The process ID identified for a running instance of the software component in the endpoint's process list. This is used as part of the evidence item. Birkholz, et al. Expires 20 January 2023 [Page 31] Internet-Draft CoSWID July 2022 * type (index 29): A human-readable string indicating the type of resource. * $$resource-collection-extension: This CDDL socket can be used to extend the resource-collection group model. This can be used to add new specialized types of resources. See Section 2.2. * $$file-extension: This CDDL socket can be used to extend the file- entry group model. See Section 2.2. * $$directory-extension: This CDDL socket can be used to extend the directory-entry group model. See Section 2.2. * $$process-extension: This CDDL socket can be used to extend the process-entry group model. See Section 2.2. * $$resource-extension: This CDDL socket can be used to extend the resource-entry group model. See Section 2.2. 2.9.3. The payload-entry Map The CDDL for the payload-entry map follows: payload-entry = { resource-collection, * $$payload-extension, global-attributes, } The following describes each child item of this group. * global-attributes: The global-attributes group described in Section 2.5. * resource-collection: The resource-collection group described in Section 2.9.2. * $$payload-extension: This CDDL socket can be used to extend the payload-entry group model. See Section 2.2. 2.9.4. The evidence-entry Map The CDDL for the evidence-entry map follows: Birkholz, et al. Expires 20 January 2023 [Page 32] Internet-Draft CoSWID July 2022 evidence-entry = { resource-collection, ? date => integer-time, ? device-id => text, ? location => text, * $$evidence-extension, global-attributes, } date = 35 device-id = 36 The following describes each child item of this group. * global-attributes: The global-attributes group described in Section 2.5. * resource-collection: The resource-collection group described in Section 2.9.2. * date (index 35): The date and time the information was collected pertaining to the evidence item in Epoch-Based Date/Time format as specified in Section 3.4.2 of [RFC8949]. * device-id (index 36): The endpoint's string identifier from which the evidence was collected. * location (index 23): The absolute filepath of the location of the CoSWID tag generated as evidence. (Location values in filesystem- items in the payload can be expressed relative to this location.) * $$evidence-extension: This CDDL socket can be used to extend the evidence-entry group model. See Section 2.2. 2.10. Full CDDL Specification In order to create a valid CoSWID document the structure of the corresponding CBOR message MUST adhere to the following CDDL specification. concise-swid-tag = { tag-id => text / bstr .size 16, tag-version => integer, ? corpus => bool, ? patch => bool, ? supplemental => bool, software-name => text, Birkholz, et al. Expires 20 January 2023 [Page 33] Internet-Draft CoSWID July 2022 ? software-version => text, ? version-scheme => $version-scheme, ? media => text, ? software-meta => one-or-more, entity => one-or-more, ? link => one-or-more, ? payload-or-evidence, * $$coswid-extension, global-attributes, } payload-or-evidence //= ( payload => payload-entry ) payload-or-evidence //= ( evidence => evidence-entry ) any-uri = uri label = text / int $version-scheme /= multipartnumeric $version-scheme /= multipartnumeric-suffix $version-scheme /= alphanumeric $version-scheme /= decimal $version-scheme /= semver $version-scheme /= int / text any-attribute = ( label => one-or-more / one-or-more ) one-or-more = T / [ 2* T ] global-attributes = ( ? lang => text, * any-attribute, ) hash-entry = [ hash-alg-id: int, hash-value: bytes, ] entity-entry = { entity-name => text, ? reg-id => any-uri, role => one-or-more<$role>, ? thumbprint => hash-entry, * $$entity-extension, global-attributes, } Birkholz, et al. Expires 20 January 2023 [Page 34] Internet-Draft CoSWID July 2022 $role /= tag-creator $role /= software-creator $role /= aggregator $role /= distributor $role /= licensor $role /= maintainer $role /= int / text link-entry = { ? artifact => text, href => any-uri, ? media => text, ? ownership => $ownership, rel => $rel, ? media-type => text, ? use => $use, * $$link-extension, global-attributes, } $ownership /= shared $ownership /= private $ownership /= abandon $ownership /= int / text $rel /= ancestor $rel /= component $rel /= feature $rel /= installationmedia $rel /= packageinstaller $rel /= parent $rel /= patches $rel /= requires $rel /= see-also $rel /= supersedes $rel /= supplemental $rel /= -256..64436 / text $use /= optional $use /= required $use /= recommended $use /= int / text software-meta-entry = { ? activation-status => text, ? channel-type => text, ? colloquial-version => text, ? description => text, Birkholz, et al. Expires 20 January 2023 [Page 35] Internet-Draft CoSWID July 2022 ? edition => text, ? entitlement-data-required => bool, ? entitlement-key => text, ? generator => text / bstr .size 16, ? persistent-id => text, ? product => text, ? product-family => text, ? revision => text, ? summary => text, ? unspsc-code => text, ? unspsc-version => text, * $$software-meta-extension, global-attributes, } path-elements-group = ( ? directory => one-or-more, ? file => one-or-more, ) resource-collection = ( path-elements-group, ? process => one-or-more, ? resource => one-or-more, * $$resource-collection-extension, ) file-entry = { filesystem-item, ? size => uint, ? file-version => text, ? hash => hash-entry, * $$file-extension, global-attributes, } directory-entry = { filesystem-item, ? path-elements => { path-elements-group }, * $$directory-extension, global-attributes, } process-entry = { process-name => text, ? pid => integer, * $$process-extension, global-attributes, } Birkholz, et al. Expires 20 January 2023 [Page 36] Internet-Draft CoSWID July 2022 resource-entry = { type => text, * $$resource-extension, global-attributes, } filesystem-item = ( ? key => bool, ? location => text, fs-name => text, ? root => text, ) payload-entry = { resource-collection, * $$payload-extension, global-attributes, } evidence-entry = { resource-collection, ? date => integer-time, ? device-id => text, ? location => text, * $$evidence-extension, global-attributes, } integer-time = #6.1(int) ; "global map member" integer indexes tag-id = 0 software-name = 1 entity = 2 evidence = 3 link = 4 software-meta = 5 payload = 6 hash = 7 corpus = 8 patch = 9 media = 10 supplemental = 11 tag-version = 12 software-version = 13 version-scheme = 14 lang = 15 directory = 16 Birkholz, et al. Expires 20 January 2023 [Page 37] Internet-Draft CoSWID July 2022 file = 17 process = 18 resource = 19 size = 20 file-version = 21 key = 22 location = 23 fs-name = 24 root = 25 path-elements = 26 process-name = 27 pid = 28 type = 29 entity-name = 31 reg-id = 32 role = 33 thumbprint = 34 date = 35 device-id = 36 artifact = 37 href = 38 ownership = 39 rel = 40 media-type = 41 use = 42 activation-status = 43 channel-type = 44 colloquial-version = 45 description = 46 edition = 47 entitlement-data-required = 48 entitlement-key = 49 generator = 50 persistent-id = 51 product = 52 product-family = 53 revision = 54 summary = 55 unspsc-code = 56 unspsc-version = 57 ; "version-scheme" integer indexes multipartnumeric = 1 multipartnumeric-suffix = 2 alphanumeric = 3 decimal = 4 semver = 16384 Birkholz, et al. Expires 20 January 2023 [Page 38] Internet-Draft CoSWID July 2022 ; "role" integer indexes tag-creator=1 software-creator=2 aggregator=3 distributor=4 licensor=5 maintainer=6 ; "ownership" integer indexes abandon=1 private=2 shared=3 ; "rel" integer indexes ancestor=1 component=2 feature=3 installationmedia=4 packageinstaller=5 parent=6 patches=7 requires=8 see-also=9 supersedes=10 ; supplemental=11 ; this is already defined earlier ; "use" integer indexes optional=1 required=2 recommended=3 3. Determining the Type of CoSWID The operational model for SWID and CoSWID tags was introduced in Section 1.1, which described four different CoSWID tag types. The following additional rules apply to the use of CoSWID tags to ensure that created tags properly identify the tag type. The first matching rule MUST determine the type of the CoSWID tag. 1. Primary Tag: A CoSWID tag MUST be considered a primary tag if the corpus, patch, and supplemental items are "false". 2. Supplemental Tag: A CoSWID tag MUST be considered a supplemental tag if the supplemental item is set to "true". Birkholz, et al. Expires 20 January 2023 [Page 39] Internet-Draft CoSWID July 2022 3. Corpus Tag: A CoSWID tag MUST be considered a corpus tag if the corpus item is "true". 4. Patch Tag: A CoSWID tag MUST be considered a patch tag if the patch item is "true". Note: Multiple of the corpus, patch, and supplemental items can have values set as "true". The rules above provide a means to determine the tag's type in such a case. For example, a SWID or CoSWID tag for a patch installer might have both corpus and patch items set to "true". In such a case, the tag is a "Corpus Tag". The tag installed by this installer would have only the patch item set to "true", making the installed tag type a "Patch Tag". 4. CoSWID Indexed Label Values This section defines a number of kinds of indexed label values that are maintained in a registry each (Section 6). These values are represented as positive integers. In each registry, the value 0 is marked as Reserved. 4.1. Version Scheme The following table contains a set of values for use in the concise- swid-tag group's version-scheme item. Version Scheme Name strings match the version schemes defined in the ISO/IEC 19770-2:2015 [SWID] specification. Index value indicates the value to use as the version-scheme item's value. The Version Scheme Name provides human- readable text for the value. The Definition describes the syntax of allowed values for each entry. Birkholz, et al. Expires 20 January 2023 [Page 40] Internet-Draft CoSWID July 2022 +=======+=========================+===============================+ | Index | Version Scheme Name | Definition | +=======+=========================+===============================+ | 1 | multipartnumeric | Numbers separated by dots, | | | | where the numbers are | | | | interpreted as decimal | | | | integers (e.g., 1.2.3, | | | | 1.2.3.4.5.6.7, 1.4.5, 1.21) | +-------+-------------------------+-------------------------------+ | 2 | multipartnumeric+suffix | Numbers separated by dots, | | | | where the numbers are | | | | interpreted as decimal | | | | integers with an additional | | | | textual suffix (e.g., 1.2.3a) | +-------+-------------------------+-------------------------------+ | 3 | alphanumeric | Strictly a string, no | | | | interpretation as number | +-------+-------------------------+-------------------------------+ | 4 | decimal | A single decimal floating | | | | point number | +-------+-------------------------+-------------------------------+ | 16384 | semver | A semantic version as defined | | | | by [SWID]. Also see the | | | | [SEMVER] specification for | | | | more information | +-------+-------------------------+-------------------------------+ Table 3: Version Scheme Values multipartnumeric and the numbers part of multipartnumeric+suffix are interpreted as a sequence of numbers and are sorted in lexicographical order by these numbers (i.e., not by the digits in the numbers) and then the textual suffix (for multipartnumeric+suffix). Alphanumeric strings are sorted lexicographically as character strings. Decimal version numbers are interpreted as a single floating point number (e.g., 1.25 is less than 1.3). The values above are registered in the IANA "Software ID Version Scheme Values" registry defined in Section 6.2.4. Additional entries will likely be registered over time in this registry. Birkholz, et al. Expires 20 January 2023 [Page 41] Internet-Draft CoSWID July 2022 A CoSWID producer that is aware of the version scheme that has been used to select the version value, SHOULD include the optional version-scheme item to avoid semantic ambiguity. If the CoSWID producer does not have this information, it SHOULD omit the version- scheme item. The following heuristics can be used by a CoSWID consumer, based on the version schemes' partially overlapping value spaces: * "decimal" and "multipartnumeric" partially overlap in their value space when a value matches a decimal number. When a corresponding software-version item's value falls within this overlapping value space, it is expected that the "decimal" version scheme is used. * "multipartnumeric" and "semver" partially overlap in their value space when a "multipartnumeric" value matches the semantic versioning syntax. When a corresponding software-version item's value falls within this overlapping value space, it is expected that the "semver" version scheme is used. * "alphanumeric" and other version schemes might overlap in their value space. When a corresponding software-version item's value falls within this overlapping value space, it is expected that the other version scheme is used and "alphanumeric" is not used. Note that these heuristics are imperfect and can guess wrong, which is the reason the version-scheme item SHOULD be included by the producer. 4.2. Entity Role Values The following table indicates the index value to use for the entity- entry group's role item (see Section 2.6). These values match the entity roles defined in the ISO/IEC 19770-2:2015 [SWID] specification. The "Index" value indicates the value to use as the role item's value. The "Role Name" provides human-readable text for the value. The "Definition" describes the semantic meaning of each entry. Birkholz, et al. Expires 20 January 2023 [Page 42] Internet-Draft CoSWID July 2022 +=======+=================+========================================+ | Index | Role Name | Definition | +=======+=================+========================================+ | 1 | tagCreator | The person or organization that | | | | created the containing SWID or CoSWID | | | | tag | +-------+-----------------+----------------------------------------+ | 2 | softwareCreator | The person or organization entity that | | | | created the software component. | +-------+-----------------+----------------------------------------+ | 3 | aggregator | From [SWID], "An organization or | | | | system that encapsulates software from | | | | their own and/or other organizations | | | | into a different distribution process | | | | (as in the case of virtualization), or | | | | as a completed system to accomplish a | | | | specific task (as in the case of a | | | | value added reseller)." | +-------+-----------------+----------------------------------------+ | 4 | distributor | From [SWID], "An entity that furthers | | | | the marketing, selling and/or | | | | distribution of software from the | | | | original place of manufacture to the | | | | ultimate user without modifying the | | | | software, its packaging or its | | | | labelling." | +-------+-----------------+----------------------------------------+ | 5 | licensor | From [SAM] as "software licensor", a | | | | "person or organization who owns or | | | | holds the rights to issue a software | | | | license for a specific software | | | | [component]" | +-------+-----------------+----------------------------------------+ | 6 | maintainer | The person or organization that is | | | | responsible for coordinating and | | | | making updates to the source code for | | | | the software component. This SHOULD | | | | be used when the "maintainer" is a | | | | different person or organization than | | | | the original "softwareCreator". | +-------+-----------------+----------------------------------------+ Table 4: Entity Role Values The values above are registered in the IANA "Software ID Entity Role Values" registry defined in Section 6.2.5. Additional values will likely be registered over time. Birkholz, et al. Expires 20 January 2023 [Page 43] Internet-Draft CoSWID July 2022 4.3. Link Ownership Values The following table indicates the index value to use for the link- entry group's ownership item (see Section 2.7). These values match the link ownership values defined in the ISO/IEC 19770-2:2015 [SWID] specification. The "Index" value indicates the value to use as the link-entry group ownership item's value. The "Ownership Type" provides human-readable text for the value. The "Definition" describes the semantic meaning of each entry. +=======+===========+===============================================+ | Index | Ownership | Definition | | | Type | | +=======+===========+===============================================+ | 1 | abandon | If the software component referenced by the | | | | CoSWID tag is uninstalled, then the | | | | referenced software SHOULD NOT be | | | | uninstalled | +-------+-----------+-----------------------------------------------+ | 2 | private | If the software component referenced by the | | | | CoSWID tag is uninstalled, then the | | | | referenced software SHOULD be uninstalled as | | | | well. | +-------+-----------+-----------------------------------------------+ | 3 | shared | If the software component referenced by the | | | | CoSWID tag is uninstalled, then the | | | | referenced software SHOULD be uninstalled if | | | | no other components sharing the software. | +-------+-----------+-----------------------------------------------+ Table 5: Link Ownership Values The values above are registered in the IANA "Software ID Link Ownership Values" registry defined in Section 6.2.6. Additional values will likely be registered over time. 4.4. Link Rel Values The following table indicates the index value to use for the link- entry group's rel item (see Section 2.7). These values match the link rel values defined in the ISO/IEC 19770-2:2015 [SWID] specification. The "Index" value indicates the value to use as the link-entry group ownership item's value. The "Relationship Type" provides human-readable text for the value. The "Definition" describes the semantic meaning of each entry. Birkholz, et al. Expires 20 January 2023 [Page 44] Internet-Draft CoSWID July 2022 +=======+===================+=======================================+ | Index | Relationship Type | Definition | +=======+===================+=======================================+ | 1 | ancestor | The link references a software | | | | tag for a previous release of | | | | this software. This can be | | | | useful to define an upgrade path. | +-------+-------------------+---------------------------------------+ | 2 | component | The link references a software | | | | tag for a separate component of | | | | this software. | +-------+-------------------+---------------------------------------+ | 3 | feature | The link references a | | | | configurable feature of this | | | | software that can be enabled or | | | | disabled without changing the | | | | installed files. | +-------+-------------------+---------------------------------------+ | 4 | installationmedia | The link references the | | | | installation package that can be | | | | used to install this software. | +-------+-------------------+---------------------------------------+ | 5 | packageinstaller | The link references the | | | | installation software needed to | | | | install this software. | +-------+-------------------+---------------------------------------+ | 6 | parent | The link references a software | | | | tag that is the parent of the | | | | referencing tag. This | | | | relationship can be used when | | | | multiple software components are | | | | part of a software bundle, where | | | | the "parent" is the software tag | | | | for the bundle, and each child is | | | | a "component". In such a case, | | | | each child component can provide | | | | a "parent" link relationship to | | | | the bundle's software tag, and | | | | the bundle can provide a | | | | "component" link relationship to | | | | each child software component. | +-------+-------------------+---------------------------------------+ | 7 | patches | The link references a software | | | | tag that the referencing software | | | | patches. Typically only used for | | | | patch tags (see Section 1.1). | +-------+-------------------+---------------------------------------+ | 8 | requires | The link references a | Birkholz, et al. Expires 20 January 2023 [Page 45] Internet-Draft CoSWID July 2022 | | | prerequisite for installing this | | | | software. A patch tag (see | | | | Section 1.1) can use this to | | | | represent base software or | | | | another patch that needs to be | | | | installed first. | +-------+-------------------+---------------------------------------+ | 9 | see-also | The link references other | | | | software that may be of interest | | | | that relates to this software. | +-------+-------------------+---------------------------------------+ | 10 | supersedes | The link references another | | | | software that this software | | | | replaces. A patch tag (see | | | | Section 1.1) can use this to | | | | represent another patch that this | | | | patch incorporates or replaces. | +-------+-------------------+---------------------------------------+ | 11 | supplemental | The link references a software | | | | tag that the referencing tag | | | | supplements. Used on | | | | supplemental tags (see | | | | Section 1.1). | +-------+-------------------+---------------------------------------+ Table 6: Link Relationship Values The values above are registered in the IANA "Software ID Link Relationship Values" registry defined in Section 6.2.7. Additional values will likely be registered over time. 4.5. Link Use Values The following table indicates the index value to use for the link- entry group's use item (see Section 2.7). These values match the link use values defined in the ISO/IEC 19770-2:2015 [SWID] specification. The "Index" value indicates the value to use as the link-entry group use item's value. The "Use Type" provides human- readable text for the value. The "Definition" describes the semantic meaning of each entry. Birkholz, et al. Expires 20 January 2023 [Page 46] Internet-Draft CoSWID July 2022 +=======+=============+========================================+ | Index | Use Type | Definition | +=======+=============+========================================+ | 1 | optional | From [SWID], "Not absolutely required; | | | | the [Link]'d software is installed | | | | only when specified." | +-------+-------------+----------------------------------------+ | 2 | required | From [SWID], "The [Link]'d software is | | | | absolutely required for an operation | | | | software installation." | +-------+-------------+----------------------------------------+ | 3 | recommended | From [SWID], "Not absolutely required; | | | | the [Link]'d software is installed | | | | unless specified otherwise." | +-------+-------------+----------------------------------------+ Table 7: Link Use Values The values above are registered in the IANA "Software ID Link Use Values" registry defined in Section 6.2.8. Additional values will likely be registered over time. 5. URI Schemes This specification defines the following URI schemes for use in CoSWID and to provide interoperability with schemes used in [SWID]. Note: These URI schemes are used in [SWID] without an IANA registration. The present specification ensures that these URI schemes are properly defined going forward. // RFC Ed.: throughout this section, please replace RFC-AAAA with the // RFC number of this specification and remove this note. 5.1. "swid" URI Scheme There is a need for a scheme name that can be used in URIs that point to a specific software tag by that tag's tag-id, such as the use of the link entry as described in Section 2.7. Since this scheme is used both in a standards track document and an ISO standard, this scheme needs to be used without fear of conflicts with current or future actual schemes. In Section 6.6.1, the scheme "swid" is registered as a 'permanent' scheme for that purpose. URIs specifying the "swid" scheme are used to reference a software tag by its tag-id. A tag-id referenced in this way can be used to identify the tag resource in the context of where it is referenced Birkholz, et al. Expires 20 January 2023 [Page 47] Internet-Draft CoSWID July 2022 from. For example, when a tag is installed on a given device, that tag can reference related tags on the same device using URIs with this scheme. For URIs that use the "swid" scheme, the scheme specific part MUST consist of a referenced software tag's tag-id. This tag-id MUST be URI encoded according to Section 2.1 of [RFC3986]. The following expression is a valid example: swid:2df9de35-0aff-4a86-ace6-f7dddd1ade4c 5.2. "swidpath" URI Scheme There is a need for a scheme name that can be used in URIs to identify a collection of specific software tags with data elements that match an XPath expression, such as the use of the link entry as described in Section 2.7. The scheme named "swidpath" is used for this purpose in [SWID], but not registered. To enable usage without fear of conflicts with current or future actual schemes, the present document registers it as a 'permanent' scheme for that purpose (see Section 6.6.2). URIs specifying the "swidpath" scheme are used to filter tags out of a base collection, so that matching tags are included in the identified tag collection. The XPath expression [W3C.REC-xpath20-20101214] references the data that must be found in a given software tag out of base collection for that tag to be considered a matching tag. Tags to be evaluated (the base collection) include all tags in the context of where the "swidpath URI" is referenced from. For example, when a tag is installed on a given device, that tag can reference related tags on the same device using a URI with this scheme. For URIs that use the "swidpath" scheme, the following requirements apply: * The scheme specific part MUST be an XPath expression as defined by [W3C.REC-xpath20-20101214]. The included XPath expression will be URI encoded according to Section 2.1 of [RFC3986]. * This XPath is evaluated over SWID tags, or COSWID tags transformed into SWID tags, found on a system. A given tag MUST be considered a match if the XPath evaluation result value has an effective boolean value of "true" according to [W3C.REC-xpath20-20101214], Section 2.4.3. Birkholz, et al. Expires 20 January 2023 [Page 48] Internet-Draft CoSWID July 2022 6. IANA Considerations This document has a number of IANA considerations, as described in the following subsections. In summary, 6 new registries are established with this request, with initial entries provided for each registry. New values for 5 other registries are also requested. 6.1. CoSWID Items Registry This registry uses integer values as index values in CBOR maps. This document defines a new registry titled "CoSWID Items". Future registrations for this registry are to be made based on [BCP26] as follows: +==================+=====================================+ | Range | Registration Procedures | +==================+=====================================+ | 0-32767 | Standards Action with Expert Review | +------------------+-------------------------------------+ | 32768-4294967295 | Specification Required | +------------------+-------------------------------------+ Table 8: CoSWID Items Registration Procedures All negative values are reserved for Private Use. Initial registrations for the "CoSWID Items" registry are provided below. Assignments consist of an integer index value, the item name, and a reference to the defining specification. +===============+===========================+===============+ | Index | Item Name | Specification | +===============+===========================+===============+ | 0 | tag-id | RFC-AAAA | +---------------+---------------------------+---------------+ | 1 | software-name | RFC-AAAA | +---------------+---------------------------+---------------+ | 2 | entity | RFC-AAAA | +---------------+---------------------------+---------------+ | 3 | evidence | RFC-AAAA | +---------------+---------------------------+---------------+ | 4 | link | RFC-AAAA | +---------------+---------------------------+---------------+ | 5 | software-meta | RFC-AAAA | +---------------+---------------------------+---------------+ | 6 | payload | RFC-AAAA | +---------------+---------------------------+---------------+ Birkholz, et al. Expires 20 January 2023 [Page 49] Internet-Draft CoSWID July 2022 | 7 | hash | RFC-AAAA | +---------------+---------------------------+---------------+ | 8 | corpus | RFC-AAAA | +---------------+---------------------------+---------------+ | 9 | patch | RFC-AAAA | +---------------+---------------------------+---------------+ | 10 | media | RFC-AAAA | +---------------+---------------------------+---------------+ | 11 | supplemental | RFC-AAAA | +---------------+---------------------------+---------------+ | 12 | tag-version | RFC-AAAA | +---------------+---------------------------+---------------+ | 13 | software-version | RFC-AAAA | +---------------+---------------------------+---------------+ | 14 | version-scheme | RFC-AAAA | +---------------+---------------------------+---------------+ | 15 | lang | RFC-AAAA | +---------------+---------------------------+---------------+ | 16 | directory | RFC-AAAA | +---------------+---------------------------+---------------+ | 17 | file | RFC-AAAA | +---------------+---------------------------+---------------+ | 18 | process | RFC-AAAA | +---------------+---------------------------+---------------+ | 19 | resource | RFC-AAAA | +---------------+---------------------------+---------------+ | 20 | size | RFC-AAAA | +---------------+---------------------------+---------------+ | 21 | file-version | RFC-AAAA | +---------------+---------------------------+---------------+ | 22 | key | RFC-AAAA | +---------------+---------------------------+---------------+ | 23 | location | RFC-AAAA | +---------------+---------------------------+---------------+ | 24 | fs-name | RFC-AAAA | +---------------+---------------------------+---------------+ | 25 | root | RFC-AAAA | +---------------+---------------------------+---------------+ | 26 | path-elements | RFC-AAAA | +---------------+---------------------------+---------------+ | 27 | process-name | RFC-AAAA | +---------------+---------------------------+---------------+ | 28 | pid | RFC-AAAA | +---------------+---------------------------+---------------+ | 29 | type | RFC-AAAA | +---------------+---------------------------+---------------+ | 30 | Unassigned | | +---------------+---------------------------+---------------+ Birkholz, et al. Expires 20 January 2023 [Page 50] Internet-Draft CoSWID July 2022 | 31 | entity-name | RFC-AAAA | +---------------+---------------------------+---------------+ | 32 | reg-id | RFC-AAAA | +---------------+---------------------------+---------------+ | 33 | role | RFC-AAAA | +---------------+---------------------------+---------------+ | 34 | thumbprint | RFC-AAAA | +---------------+---------------------------+---------------+ | 35 | date | RFC-AAAA | +---------------+---------------------------+---------------+ | 36 | device-id | RFC-AAAA | +---------------+---------------------------+---------------+ | 37 | artifact | RFC-AAAA | +---------------+---------------------------+---------------+ | 38 | href | RFC-AAAA | +---------------+---------------------------+---------------+ | 39 | ownership | RFC-AAAA | +---------------+---------------------------+---------------+ | 40 | rel | RFC-AAAA | +---------------+---------------------------+---------------+ | 41 | media-type | RFC-AAAA | +---------------+---------------------------+---------------+ | 42 | use | RFC-AAAA | +---------------+---------------------------+---------------+ | 43 | activation-status | RFC-AAAA | +---------------+---------------------------+---------------+ | 44 | channel-type | RFC-AAAA | +---------------+---------------------------+---------------+ | 45 | colloquial-version | RFC-AAAA | +---------------+---------------------------+---------------+ | 46 | description | RFC-AAAA | +---------------+---------------------------+---------------+ | 47 | edition | RFC-AAAA | +---------------+---------------------------+---------------+ | 48 | entitlement-data-required | RFC-AAAA | +---------------+---------------------------+---------------+ | 49 | entitlement-key | RFC-AAAA | +---------------+---------------------------+---------------+ | 50 | generator | RFC-AAAA | +---------------+---------------------------+---------------+ | 51 | persistent-id | RFC-AAAA | +---------------+---------------------------+---------------+ | 52 | product | RFC-AAAA | +---------------+---------------------------+---------------+ | 53 | product-family | RFC-AAAA | +---------------+---------------------------+---------------+ | 54 | revision | RFC-AAAA | +---------------+---------------------------+---------------+ Birkholz, et al. Expires 20 January 2023 [Page 51] Internet-Draft CoSWID July 2022 | 55 | summary | RFC-AAAA | +---------------+---------------------------+---------------+ | 56 | unspsc-code | RFC-AAAA | +---------------+---------------------------+---------------+ | 57 | unspsc-version | RFC-AAAA | +---------------+---------------------------+---------------+ | 58-4294967295 | Unassigned | | +---------------+---------------------------+---------------+ Table 9: CoSWID Items Initial Registrations 6.2. Software ID Values Registries The following IANA registries provide a mechanism for new values to be added over time to common enumerations used by SWID and CoSWID. While neither the CoSWID nor SWID specification is subordinate to the other and will evolve as their respective standards group chooses, there is value in supporting alignment between the two standards. Shared use of common code points, as spelled out in these registries, will facilitate this alignment, hence the intent for shared use of these registries and the decision to use "swidsoftware-id" (rather than "swid" or "coswid") in registry names. 6.2.1. Registration Procedures The following registries allow for the registration of index values and names. New registrations will be permitted through either a Standards Action with Expert Review policy or a Specification Required policy [BCP26]. The following registries also reserve the integer-based index values in the range of -1 to -256 for private use as defined by Section 4.1 of [BCP26]. This allows values -1 to -24 to be expressed as a single uint_8t in CBOR, and values -25 to -256 to be expressed using an additional uint_8t in CBOR. 6.2.2. Private Use of Index and Name Values The integer-based index values in the private use range (-1 to -256) are intended for testing purposes and closed environments; values in other ranges SHOULD NOT be assigned for testing. For names that correspond to private use index values, an Internationalized Domain Name prefix MUST be used to prevent name conflicts using the form: domainprefix/name Birkholz, et al. Expires 20 January 2023 [Page 52] Internet-Draft CoSWID July 2022 Where both "domainprefix" and "name" MUST each be either an NR-LDH label or a U-label as defined by [RFC5890], and "name" also MUST be a unique name within the namespace defined by the "domainprefix". Use of a prefix in this way allows for a name to be used in the private use range. This is consistent with the guidance in [BCP178]. 6.2.3. Expert Review Criteria Designated experts MUST ensure that new registration requests meet the following additional criteria: * The requesting specification MUST provide a clear semantic definition for the new entry. This definition MUST clearly differentiate the requested entry from other previously registered entries. * The requesting specification MUST describe the intended use of the entry, including any co-constraints that exist between the use of the entry's index value or name, and other values defined within the SWID/CoSWID model. * Index values and names outside the private use space MUST NOT be used without registration. This is considered squatting and MUST be avoided. Designated experts MUST ensure that reviewed specifications register all appropriate index values and names. * Standards track documents MAY include entries registered in the range reserved for entries under the Specification Required policy. This can occur when a standards track document provides further guidance on the use of index values and names that are in common use, but were not registered with IANA. This situation SHOULD be avoided. * All registered names MUST be valid according to the XML Schema NMTOKEN data type (see [W3C.REC-xmlschema-2-20041028], Section 3.3.4). This ensures that registered names are compatible with the SWID format [SWID] where they are used. * Registration of vanity names SHOULD be discouraged. The requesting specification MUST provide a description of how a requested name will allow for use by multiple stakeholders. 6.2.4. Software ID Version Scheme Values Registry This document establishes a new registry titled "Software ID Version Scheme Values". This registry provides index values for use as version-scheme item values in this document and version scheme names for use in [SWID]. Birkholz, et al. Expires 20 January 2023 [Page 53] Internet-Draft CoSWID July 2022 [TO BE REMOVED: This registration should take place at the following location: https://www.iana.org/assignments/software-id] This registry uses the registration procedures defined in Section 6.2.1 with the following associated ranges: +=============+=====================================+ | Range | Registration Procedures | +=============+=====================================+ | 0-16383 | Standards Action with Expert Review | +-------------+-------------------------------------+ | 16384-65535 | Specification Required | +-------------+-------------------------------------+ Table 10: Software ID Version Scheme Registration Procedures Assignments MUST consist of an integer Index value, the Version Scheme Name, and a reference to the defining specification. Initial registrations for the "Software ID Version Scheme Values" registry are provided below, which are derived from the textual version scheme names defined in [SWID]. +=============+=========================+=================+ | Index | Version Scheme Name | Specification | +=============+=========================+=================+ | 0 | Reserved | | +-------------+-------------------------+-----------------+ | 1 | multipartnumeric | See Section 4.1 | +-------------+-------------------------+-----------------+ | 2 | multipartnumeric+suffix | See Section 4.1 | +-------------+-------------------------+-----------------+ | 3 | alphanumeric | See Section 4.1 | +-------------+-------------------------+-----------------+ | 4 | decimal | See Section 4.1 | +-------------+-------------------------+-----------------+ | 5-16383 | Unassigned | | +-------------+-------------------------+-----------------+ | 16384 | semver | See Section 4.1 | +-------------+-------------------------+-----------------+ | 16385-65535 | Unassigned | | +-------------+-------------------------+-----------------+ Table 11: Software ID Version Scheme Initial Registrations Registrations MUST conform to the expert review criteria defined in Section 6.2.3. Birkholz, et al. Expires 20 January 2023 [Page 54] Internet-Draft CoSWID July 2022 Designated experts MUST also ensure that newly requested entries define a value space for the corresponding version item that is unique from other previously registered entries. Note: The initial registrations violate this requirement, but are included for backwards compatibility with [SWID]. See also Section 4.1. 6.2.5. Software ID Entity Role Values Registry This document establishes a new registry titled "Software ID Entity Role Values". This registry provides index values for use as entity- entry role item values in this document and entity role names for use in [SWID]. [TO BE REMOVED: This registration should take place at the following location: https://www.iana.org/assignments/software-id] This registry uses the registration procedures defined in Section 6.2.1 with the following associated ranges: +=========+=====================================+ | Range | Registration Procedures | +=========+=====================================+ | 0-127 | Standards Action with Expert Review | +---------+-------------------------------------+ | 128-255 | Specification Required | +---------+-------------------------------------+ Table 12: Software ID Entity Role Registration Procedures Assignments consist of an integer Index value, a Role Name, and a reference to the defining specification. Initial registrations for the "Software ID Entity Role Values" registry are provided below, which are derived from the textual entity role names defined in [SWID]. Birkholz, et al. Expires 20 January 2023 [Page 55] Internet-Draft CoSWID July 2022 +=======+=================+=================+ | Index | Role Name | Specification | +=======+=================+=================+ | 0 | Reserved | | +-------+-----------------+-----------------+ | 1 | tagCreator | See Section 4.2 | +-------+-----------------+-----------------+ | 2 | softwareCreator | See Section 4.2 | +-------+-----------------+-----------------+ | 3 | aggregator | See Section 4.2 | +-------+-----------------+-----------------+ | 4 | distributor | See Section 4.2 | +-------+-----------------+-----------------+ | 5 | licensor | See Section 4.2 | +-------+-----------------+-----------------+ | 6 | maintainer | See Section 4.2 | +-------+-----------------+-----------------+ | 7-255 | Unassigned | | +-------+-----------------+-----------------+ Table 13: Software ID Entity Role Initial Registrations Registrations MUST conform to the expert review criteria defined in Section 6.2.3. 6.2.6. Software ID Link Ownership Values Registry This document establishes a new registry titled "Software ID Link Ownership Values". This registry provides index values for use as link-entry ownership item values in this document and link ownership names for use in [SWID]. [TO BE REMOVED: This registration should take place at the following location: https://www.iana.org/assignments/software-id] This registry uses the registration procedures defined in Section 6.2.1 with the following associated ranges: Birkholz, et al. Expires 20 January 2023 [Page 56] Internet-Draft CoSWID July 2022 +=========+=====================================+ | Range | Registration Procedures | +=========+=====================================+ | 0-127 | Standards Action with Expert Review | +---------+-------------------------------------+ | 128-255 | Specification Required | +---------+-------------------------------------+ Table 14: Software ID Link Ownership Registration Procedures Assignments consist of an integer Index value, an Ownership Type Name, and a reference to the defining specification. Initial registrations for the "Software ID Link Ownership Values" registry are provided below, which are derived from the textual entity role names defined in [SWID]. +=======+=====================+=================+ | Index | Ownership Type Name | Definition | +=======+=====================+=================+ | 0 | Reserved | | +-------+---------------------+-----------------+ | 1 | abandon | See Section 4.3 | +-------+---------------------+-----------------+ | 2 | private | See Section 4.3 | +-------+---------------------+-----------------+ | 3 | shared | See Section 4.3 | +-------+---------------------+-----------------+ | 4-255 | Unassigned | | +-------+---------------------+-----------------+ Table 15: Software ID Link Ownership Inital Registrations Registrations MUST conform to the expert review criteria defined in Section 6.2.3. 6.2.7. Software ID Link Relationship Values Registry This document establishes a new registry titled "Software ID Link Relationship Values". This registry provides index values for use as link-entry rel item values in this document and link ownership names for use in [SWID]. [TO BE REMOVED: This registration should take place at the following location: https://www.iana.org/assignments/software-id] Birkholz, et al. Expires 20 January 2023 [Page 57] Internet-Draft CoSWID July 2022 This registry uses the registration procedures defined in Section 6.2.1 with the following associated ranges: +=============+=====================================+ | Range | Registration Procedures | +=============+=====================================+ | 0-32767 | Standards Action with Expert Review | +-------------+-------------------------------------+ | 32768-65535 | Specification Required | +-------------+-------------------------------------+ Table 16: Software ID Link Relationship Registration Procedures Assignments consist of an integer Index value, the Relationship Type Name, and a reference to the defining specification. Initial registrations for the "Software ID Link Relationship Values" registry are provided below, which are derived from the link relationship values defined in [SWID]. Birkholz, et al. Expires 20 January 2023 [Page 58] Internet-Draft CoSWID July 2022 +==========+========================+=================+ | Index | Relationship Type Name | Specification | +==========+========================+=================+ | 0 | Reserved | | +----------+------------------------+-----------------+ | 1 | ancestor | See Section 4.4 | +----------+------------------------+-----------------+ | 2 | component | See Section 4.4 | +----------+------------------------+-----------------+ | 3 | feature | See Section 4.4 | +----------+------------------------+-----------------+ | 4 | installationmedia | See Section 4.4 | +----------+------------------------+-----------------+ | 5 | packageinstaller | See Section 4.4 | +----------+------------------------+-----------------+ | 6 | parent | See Section 4.4 | +----------+------------------------+-----------------+ | 7 | patches | See Section 4.4 | +----------+------------------------+-----------------+ | 8 | requires | See Section 4.4 | +----------+------------------------+-----------------+ | 9 | see-also | See Section 4.4 | +----------+------------------------+-----------------+ | 10 | supersedes | See Section 4.4 | +----------+------------------------+-----------------+ | 11 | supplemental | See Section 4.4 | +----------+------------------------+-----------------+ | 12-65535 | Unassigned | | +----------+------------------------+-----------------+ Table 17: Software ID Link Relationship Initial Registrations Registrations MUST conform to the expert review criteria defined in Section 6.2.3. Designated experts MUST also ensure that a newly requested entry documents the URI schemes allowed to be used in an href associated with the link relationship and the expected resolution behavior of these URI schemes. This will help to ensure that applications processing software tags are able to interoperate when resolving resources referenced by a link of a given type. Birkholz, et al. Expires 20 January 2023 [Page 59] Internet-Draft CoSWID July 2022 6.2.8. Software ID Link Use Values Registry This document establishes a new registry titled "Software ID Link Use Values". This registry provides index values for use as link-entry use item values in this document and link use names for use in [SWID]. [TO BE REMOVED: This registration should take place at the following location: https://www.iana.org/assignments/software-id] This registry uses the registration procedures defined in Section 6.2.1 with the following associated ranges: +=========+=====================================+ | Range | Registration Procedures | +=========+=====================================+ | 0-127 | Standards Action with Expert Review | +---------+-------------------------------------+ | 128-255 | Specification Required | +---------+-------------------------------------+ Table 18: Software ID Link Use Registration Procedures Assignments consist of an integer Index value, the Link Use Type Name, and a reference to the defining specification. Initial registrations for the "Software ID Link Use Values" registry are provided below, which are derived from the link relationship values defined in [SWID]. +=======+====================+=================+ | Index | Link Use Type Name | Specification | +=======+====================+=================+ | 0 | Reserved | | +-------+--------------------+-----------------+ | 1 | optional | See Section 4.5 | +-------+--------------------+-----------------+ | 2 | required | See Section 4.5 | +-------+--------------------+-----------------+ | 3 | recommended | See Section 4.5 | +-------+--------------------+-----------------+ | 4-255 | Unassigned | | +-------+--------------------+-----------------+ Table 19: Software ID Link Use Initial Registrations Birkholz, et al. Expires 20 January 2023 [Page 60] Internet-Draft CoSWID July 2022 Registrations MUST conform to the expert review criteria defined in Section 6.2.3. 6.3. swid+cbor Media Type Registration IANA is requested to add the following to the IANA "Media Types" registry [IANA.media-types]. Type name: application Subtype name: swid+cbor Required parameters: none Optional parameters: none Encoding considerations: Binary (encoded as CBOR [RFC8949]). See RFC-AAAA for details. Security considerations: See Section 9 of RFC-AAAA. Interoperability considerations: Applications MAY ignore any key value pairs that they do not understand. This allows backwards compatible extensions to this specification. Published specification: RFC-AAAA Applications that use this media type: The type is used by software asset management systems, vulnerability assessment systems, and in applications that use remote integrity verification. Fragment Identifier Considerations: The syntax and semantics of fragment identifiers specified for "application/swid+cbor" are as specified for "application/cbor". (At publication of RFC-AAAA, there is no fragment identification syntax defined for "application/cbor".) Additional information: Magic number(s): if tagged, first five bytes in hex: da 53 57 49 44 (see Section 8 in RFC-AAAA) File extension(s): coswid Macintosh file type code(s): none Macintosh Universal Type Identifier code: org.ietf.coswid conforms to public.data Birkholz, et al. Expires 20 January 2023 [Page 61] Internet-Draft CoSWID July 2022 Person & email address to contact for further information: IESG Intended usage: COMMON Restrictions on usage: None Author: Henk Birkholz Change controller: IESG 6.4. CoAP Content-Format Registration IANA is requested to assign a CoAP Content-Format ID for the CoSWID media type in the "CoAP Content-Formats" sub-registry, from the "IETF Review or IESG Approval" space (256..999), within the "CoRE Parameters" registry [RFC7252] [IANA.core-parameters]: +=======================+==========+======+===========+ | Media type | Encoding | ID | Reference | +=======================+==========+======+===========+ | application/swid+cbor | - | TBD1 | RFC-AAAA | +-----------------------+----------+------+-----------+ Table 20: CoAP Content-Format IDs 6.5. CBOR Tag Registration IANA is requested to allocate a tag in the "CBOR Tags" registry [IANA.cbor-tags], preferably with the specific value requested: +============+===========+=============================+ | Tag | Data Item | Semantics | +============+===========+=============================+ | 1398229316 | map | Concise Software Identifier | | | | (CoSWID) [RFC-AAAA] | +------------+-----------+-----------------------------+ Table 21: CoSWID CBOR Tag 6.6. URI Scheme Registrations The ISO 19770-2:2015 SWID specification describes use of the "swid" and "swidpath" URI schemes, which are currently in use in implementations. This document continues this use for CoSWID. The following subsections provide registrations for these schemes in to ensure that a permanent registration exists for these schemes that is suitable for use in the SWID and CoSWID specifications. Birkholz, et al. Expires 20 January 2023 [Page 62] Internet-Draft CoSWID July 2022 URI schemes are registered within the "Uniform Resource Identifier (URI) Schemes" registry maintained at [IANA.uri-schemes]. 6.6.1. URI-scheme swid IANA is requested to register the URI scheme "swid". This registration request complies with [RFC7595]. Scheme name: swid Status: Permanent Applications/protocols that use this scheme name: Applications that require Software-IDs (SWIDs) or Concise Software-IDs (CoSWIDs); see Section 5.1 of RFC-AAAA. Contact: IETF Chair Change controller: IESG Reference: Section 5.1 in RFC-AAAA 6.6.2. URI-scheme swidpath IANA is requested to register the URI scheme "swidpath". This registration request complies with [RFC7595]. Scheme name: swidpath Status: Permanent Applications/protocols that use this scheme name: Applications that require Software-IDs (SWIDs) or Concise Software-IDs (CoSWIDs); see Section 5.2 of RFC-AAAA. Contact: IETF Chair Change controller: IESG Birkholz, et al. Expires 20 January 2023 [Page 63] Internet-Draft CoSWID July 2022 Reference: Section 5.2 in RFC-AAAA 6.7. CoSWID Model for use in SWIMA Registration The Software Inventory Message and Attributes (SWIMA) for PA-TNC specification [RFC8412] defines a standardized method for collecting an endpoint device's software inventory. A CoSWID can provide evidence of software installation which can then be used and exchanged with SWIMA. This registration adds a new entry to the IANA "Software Data Model Types" registry defined by [RFC8412] [IANA.pa-tnc-parameters] to support CoSWID use in SWIMA as follows: Pen: 0 Integer: TBD2 Name: Concise Software Identifier (CoSWID) Reference: RFC-AAAA Deriving Software Identifiers: A Software Identifier generated from a CoSWID tag is expressed as a concatenation of the form in [RFC5234] as follows: TAG_CREATOR_REGID "_" "_" UNIQUE_ID Where TAG_CREATOR_REGID is the reg-id item value of the tag's entity item having the role value of 1 (corresponding to "tag creator"), and the UNIQUE_ID is the same tag's tag-id item. If the tag-id item's value is expressed as a 16-byte binary string, the UNIQUE_ID MUST be represented using the UUID string representation defined in [RFC4122] including the "urn:uuid:" prefix. The TAG_CREATOR_REGID and the UNIQUE_ID are connected with a double underscore (_), without any other connecting character or whitespace. 7. Signed CoSWID Tags SWID tags, as defined in the ISO-19770-2:2015 XML schema, can include cryptographic signatures to protect the integrity of the SWID tag. In general, tags are signed by the tag creator (typically, although not exclusively, the vendor of the software component that the SWID tag identifies). Cryptographic signatures can make any modification of the tag detectable, which is especially important if the integrity of the tag is important, such as when the tag is providing reference integrity measurements for files. The ISO-19770-2:2015 XML schema Birkholz, et al. Expires 20 January 2023 [Page 64] Internet-Draft CoSWID July 2022 uses XML DSIG to support cryptographic signatures. Signing CoSWID tags follows the procedures defined in CBOR Object Signing and Encryption [I-D.ietf-cose-rfc8152bis-struct]. A CoSWID tag MUST be wrapped in a COSE Signature structure, either COSE_Sign1 or COSE_Sign. In the first case, a Single Signer Data Object (COSE_Sign1) contains a single signature and MUST be signed by the tag creator. The following CDDL specification defines a restrictive subset of COSE header parameters that MUST be used in the protected header in this case. COSE-Sign1-coswid = [ protected: bstr .cbor protected-signed-coswid-header, unprotected: unprotected-signed-coswid-header, payload: bstr .cbor payload, signature: bstr, ] cose-label = int / tstr cose-values = any protected-signed-coswid-header = { 1 => int, ; algorithm identifier 3 => "application/swid+cbor", * cose-label => cose-values, } unprotected-signed-coswid-header = { * cose-label => cose-values, } The COSE_Sign structure allows for more than one signature, one of which MUST be issued by the tag creator, to be applied to a CoSWID tag and MAY be used. The corresponding usage scenarios are domain- specific and require well-specified application guidance. Birkholz, et al. Expires 20 January 2023 [Page 65] Internet-Draft CoSWID July 2022 COSE-Sign-coswid = [ protected: bstr .cbor protected-signed-coswid-header1, unprotected: unprotected-signed-coswid-header, payload: bstr .cbor payload, signature: [ * COSE_Signature ], ] protected-signed-coswid-header1 = { 3 => "application/swid+cbor", * cose-label => cose-values, } protected-signature-coswid-header = { 1 => int, ; algorithm identifier * cose-label => cose-values, } unprotected-sign-coswid-header = { * cose-label => cose-values, } COSE_Signature = [ protected: bstr .cbor protected-signature-coswid-header, unprotected: unprotected-sign-coswid-header, signature : bstr ] Additionally, the COSE Header counter signature MAY be used as an attribute in the unprotected header map of the COSE envelope of a CoSWID [I-D.ietf-cose-countersign]. The application of counter signing enables second parties to provide a signature on a signature allowing for a proof that a signature existed at a given time (i.e., a timestamp). A CoSWID MUST be signed, using the above mechanism, to protect the integrity of the CoSWID tag. See the security considerations (in Section 9) for more information on why a signed CoSWID is valuable in most cases. Birkholz, et al. Expires 20 January 2023 [Page 66] Internet-Draft CoSWID July 2022 8. CBOR-Tagged CoSWID Tags This specification allows for tagged and untagged CBOR data items that are CoSWID tags. Consecutively, the CBOR tag for CoSWID tags defined in Table 21 SHOULD be used in conjunction with CBOR data items that are a CoSWID tags. Other CBOR tags MUST NOT be used with a CBOR data item that is a CoSWID tag. If tagged, both signed and unsigned CoSWID tags MUST use the CoSWID CBOR tag. In case a signed CoSWID is tagged, a CoSWID CBOR tag MUST be appended before the COSE envelope whether it is a COSE_Untagged_Message or a COSE_Tagged_Message. In case an unsigned CoSWID is tagged, a CoSWID CBOR tag MUST be appended before the CBOR data item that is the CoSWID tag. coswid = unsigned-coswid / signed-coswid unsigned-coswid = concise-swid-tag / tagged-coswid signed-coswid1 = signed-coswid-for signed-coswid = signed-coswid1 / tagged-coswid tagged-coswid = #6.1398229316(T) signed-coswid-for = #6.18(COSE-Sign1-coswid) / #6.98(COSE-Sign-coswid) This specification allows for a tagged CoSWID tag to reside in a COSE envelope that is also tagged with a CoSWID CBOR tag. In cases where a tag creator is not a signer (e.g., hand-offs between entities in a trusted portion of a supply-chain), retaining CBOR tags attached to unsigned CoSWID tags can be of great use. Nevertheless, redundant use of tags SHOULD be avoided when possible. 9. Security Considerations The following security considerations for use of CoSWID tags focus on: * ensuring the integrity and authenticity of a CoSWID tag * the application of CoSWID tags to address security challenges related to unmanaged or unpatched software * reducing the potential for unintended disclosure of a device's software load Birkholz, et al. Expires 20 January 2023 [Page 67] Internet-Draft CoSWID July 2022 A tag is considered "authoritative" if the CoSWID tag was created by the software provider. An authoritative CoSWID tag contains information about a software component provided by the supplier of the software component, who is expected to be an expert in their own software. Thus, authoritative CoSWID tags can represent authoritative information about the software component. The degree to which this information can be trusted depends on the tag's chain of custody and the ability to verify a signature provided by the supplier if present in the CoSWID tag. The provisioning and validation of CoSWID tags are handled by local policy and is outside the scope of this document. A signed CoSWID tag (see Section 7) whose signature has been validated can be relied upon to be unchanged since it was signed. By contrast, the data contained in unsigned tags can be altered by any user or process with write-access to the tag. To support signature validation, there is the need to associate the right key with the software provider or party originating the signature in a secure way. This operation is application specific and needs to be addressed by the application or a user of the application; a specific approach for which is out-of-scope for this document. When an authoritative tag is signed, the originator of the signature can be verified. A trustworthy association between the signature and the originator of the signature can be established via trust anchors. A certification path between a trust anchor and a certificate including a public key enabling the validation of a tag signature can realize the assessment of trustworthiness of an authoritative tag. Verifying that the software provider is the signer is a different matter. This requires an association between the signature and the tag's entity item associated corresponding to the software provider. No mechanism is defined in this draft to make this association; therefore, this association will need to be handled by local policy. As always, the validity of a signature does not imply veracity of the signed statements: anyone can sign assertions such that the software is from a specific software-creator or that a specific persistent-id applies; policy needs to be applied to evaluate these statements and to determine their suitability for a specific use. Loss of control of signing credentials used to sign CoSWID tags would create doubt about the authenticity and integrity of any CoSWID tags signed using the compromised keys. In such cases, the legitimate tag signer (namely, the software provider for an authoritative CoSWID tag) can employ uncompromised signing credentials to create a new signature on the original tag. The tag version number would not be incremented since the tag itself was not modified. Consumers of CoSWID tags would need to validate the tag using the new credentials and would also need to make use of revocation information available Birkholz, et al. Expires 20 January 2023 [Page 68] Internet-Draft CoSWID July 2022 for the compromised credentials to avoid validating tags signed with them. The process for doing this is beyond the scope of this specification. The CoSWID format allows the use of hash values without an accompanying hash algorithm identifier. This exposes the tags to some risk of cross-algorithm attacks. We believe that this can become a practical problem only if some implementations allow the use of insecure hash algorithms. Since it may not become known immediately when an algorithm becomes insecure, this leads to a strong recommendation to only include support for hash algorithms that are generally considered secure, and not just marginally so. CoSWID tags are intended to contain public information about software components and, as such, the contents of a CoSWID tag (as opposed to the set of tags that apply to the endpoint, see below) does not need to be protected against unintended disclosure on an endpoint. Conversely, generators of CoSWID tags need to ensure that only public information is disclosed. Entitlement Keys are an example for information where particular care is required; tag authors are advised not to record unprotected, private software license keys in this field. CoSWID tags are intended to be easily discoverable by authorized applications and users on an endpoint in order to make it easy to determine the tagged software load. Access to the collection of an endpoint's CoSWID tags needs to be appropriately controlled to authorized applications and users using an appropriate access control mechanism. Since the tag-id of a CoSWID tag can be used as a global index value, failure to ensure the tag-id's uniqueness can cause collisions or ambiguity in CoSWID tags that are retrieved or processed using this identifier. CoSWID is designed to not require a registry of identifiers. As a result, CoSWID requires the tag creator to employ a method of generating a unique tag identifier. Specific methods of generating a unique identifier are beyond the scope of this specification. A collision in tag-ids may result in false positives/ negatives in software integrity checks or mis-identification of installed software, undermining CoSWID use cases such as vulnerability identification, software inventory, etc. If such a collision is detected, then the tag consumer may want to contact the maintainer of the CoSWID to have them issue a correction addressing the collision; however, this also discloses to the maintainer that the consumer has the other tag with the given tag-id in their database. More generally speaking, a tag consumer needs to be robust against such collisions lest the collision become a viable attack vector. Birkholz, et al. Expires 20 January 2023 [Page 69] Internet-Draft CoSWID July 2022 CoSWID tags are designed to be easily added and removed from an endpoint along with the installation or removal of software components. On endpoints where addition or removal of software components is tightly controlled, the addition or removal of CoSWID tags can be similarly controlled. On more open systems, where many users can manage the software inventory, CoSWID tags can be easier to add or remove. On such systems, it can be possible to add or remove CoSWID tags in a way that does not reflect the actual presence or absence of corresponding software components. Similarly, not all software products automatically install CoSWID tags, so products can be present on an endpoint without providing a corresponding CoSWID tag. As such, any collection of CoSWID tags cannot automatically be assumed to represent either a complete or fully accurate representation of the software inventory of the endpoint. However, especially on endpoint devices that more strictly control the ability to add or remove applications, CoSWID tags are an easy way to provide a preliminary understanding of that endpoint's software inventory. As CoSWID tags do not expire, inhibiting new CoSWID tags from reaching an intended consumer would render that consumer stuck with outdated information, potentially leaving associated vulnerabilities or weaknesses unmitigated. Therefore, a CoSWID tag consumer should actively check for updated tag-versions via more than one means. This specification makes use of relative paths (e.g., filesystem paths) in several places. A signed COSWID tag cannot make use of these to derive information that is considered to be covered under the signature. Typically, relative file system paths will be used to identify targets for an installation, not sources of tag information. Birkholz, et al. Expires 20 January 2023 [Page 70] Internet-Draft CoSWID July 2022 Any report of an endpoint's CoSWID tag collection provides information about the software inventory of that endpoint. If such a report is exposed to an attacker, this can tell them which software products and versions thereof are present on the endpoint. By examining this list, the attacker might learn of the presence of applications that are vulnerable to certain types of attacks. As noted earlier, CoSWID tags are designed to be easily discoverable by authorized applications and users on an endpoint, but this does not present a significant risk since an attacker would already need to have access to the endpoint to view that information. However, when the endpoint transmits its software inventory to another party, or that inventory is stored on a server for later analysis, this can potentially expose this information to attackers who do not yet have access to the endpoint. For this reason, it is important to protect the confidentiality of CoSWID tag information that has been collected from an endpoint in transit and at rest, not because those tags individually contain sensitive information, but because the collection of CoSWID tags and their association with an endpoint reveals information about that endpoint's attack surface. Finally, both the ISO-19770-2:2015 XML schema SWID definition and the CoSWID CDDL specification allow for the construction of "infinite" tags with link item loops or tags that contain malicious content with the intent of creating non-deterministic states during validation or processing of those tags. While software providers are unlikely to do this, CoSWID tags can be created by any party and the CoSWID tags collected from an endpoint could contain a mixture of vendor and non- vendor created tags. For this reason, a CoSWID tag might contain potentially malicious content. Input sanitization, loop detection, and signature verification are ways that implementations can address this concern. More generally speaking, the security considerations of [RFC8949], [I-D.ietf-cose-rfc8152bis-struct], and [I-D.ietf-cose-countersign] apply. 10. Privacy Consideration As noted in Section 9, collected information about an endpoint's software load, such as what might be represented by an endpoint's CoSWID tag collection, could be used to identify vulnerable software for attack. Collections of endpoint software information also can have privacy implications for users. The set of application a user installs can give clues to personal matters such as political affiliation, banking and investments, gender, sexual orientation, medical concerns, etc. While the collection of CoSWID tags on an endpoint wouldn't increase the privacy risk (since a party able to view those tags could also view the applications themselves), if Birkholz, et al. Expires 20 January 2023 [Page 71] Internet-Draft CoSWID July 2022 those CoSWID tags are gathered and stored in a repository somewhere, visibility into the repository now also gives visibility into a user's application collection. For this reason, repositories of collected CoSWID tags not only need to be protected against collection by malicious parties, but even authorized parties will need to be vetted and made aware of privacy responsibilities associated with having access to this information. Likewise, users should be made aware that their software inventories are being collected from endpoints. Furthermore, when collected and stored by authorized parties or systems, the inventory data needs to be protected as both security and privacy-sensitive information. 11. Change Log This section is to be removed before publishing as an RFC. [THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] Changes from version 12 to version 14: * Moved key identifier to protected COSE header * Fixed index reference for hash * Removed indirection of CDDL type definition for filesystem-item * Fixed quantity of resource and process * Updated resource-collection * Renamed socket name in software-meta to be consistent in naming * Aligned excerpt examples in I-D text with full CDDL * Fixed titles where title was referring to group instead of map * Added missing date in SEMVER * Fixed root cardinality for file and directory, etc. * Transformed path-elements-entry from map to group for re-usability * Scrubbed IANA Section * Removed redundant supplemental rule * Aligned discrepancy with ISO spec. Birkholz, et al. Expires 20 January 2023 [Page 72] Internet-Draft CoSWID July 2022 * Addressed comments on typos. * Fixed kramdown nits and BCP reference. * Addressed comments from WGLC reviewers. Changes in version 12: * Addressed a bunch of minor editorial issues based on WGLC feedback. * Added text about the use of UTF-8 in CoSWID. * Adjusted tag-id to allow for a UUID to be provided as a bstr. * Cleaned up descriptions of index ranges throughout the document, removing discussion of 8 bit, 16 bit, etc. * Adjusted discussion of private use ranges to use negative integer values and to be more clear throughout the document. * Added discussion around resolving overlapping value spaces for version schemes. * Added a set of expert review criteria for new IANA registries created by this document. * Added new registrations for the "swid" and "swidpath" URI schemes, and for using CoSWID with SWIMA. Changes from version 03 to version 11: * Reduced representation complexity of the media-entry type and removed the Section describing the older data structure. * Added more signature schemes from COSE * Included a minimal required set of normative language * Reordering of attribute name to integer label by priority according to semantics. * Added an IANA registry for CoSWID items supporting future extension. * Cleaned up IANA registrations, fixing some inconsistencies in the table labels. Birkholz, et al. Expires 20 January 2023 [Page 73] Internet-Draft CoSWID July 2022 * Added additional CDDL sockets for resource collection entries providing for additional extension points to address future SWID/ CoSWID extensions. * Updated Section on extension points to address new CDDL sockets and to reference the new IANA registry for items. * Removed unused references and added new references to address placeholder comments. * Added table with semantics for the link ownership item. * Clarified language, made term use more consistent, fixed references, and replacing lowercase RFC2119 keywords. Changes from version 02 to version 03: * Updated core CDDL including the CDDL design pattern according to RFC 8428. Changes from version 01 to version 02: * Enforced a more strict separation between the core CoSWID definition and additional usage by moving content to corresponding appendices. * Removed artifacts inherited from the reference schema provided by ISO (e.g., NMTOKEN(S)) * Simplified the core data definition by removing group and type choices where possible * Minor reordering of map members * Added a first extension point to address requested flexibility for extensions beyond the any-element Changes from version 00 to version 01: * Ambiguity between evidence and payload eliminated by introducing explicit members (while still * allowing for "empty" SWID tags) * Added a relatively restrictive COSE envelope using cose_sign1 to define signed CoSWID (single signer only, at the moment) Birkholz, et al. Expires 20 January 2023 [Page 74] Internet-Draft CoSWID July 2022 * Added a definition how to encode hashes that can be stored in the any-member using existing IANA tables to reference hash-algorithms Changes since adopted as a WG I-D -00: * Removed redundant any-attributes originating from the ISO- 19770-2:2015 XML schema definition * Fixed broken multi-map members * Introduced a more restrictive item (any-element-map) to represent custom maps, increased restriction on types for the any-attribute, accordingly * Fixed X.1520 reference * Minor type changes of some attributes (e.g., NMTOKENS) * Added semantic differentiation of various name types (e,g. fs- name) Changes from version 06 to version 07: * Added type choices/enumerations based on textual definitions in 19770-2:2015 * Added value registry request * Added media type registration request * Added content format registration request * Added CBOR tag registration request * Removed RIM appendix to be addressed in complementary draft * Removed CWT appendix * Flagged firmware resource collection appendix for revision * Made use of terminology more consistent * Better defined use of extension points in the CDDL * Added definitions for indexed values * Added IANA registry for Link use indexed values Birkholz, et al. Expires 20 January 2023 [Page 75] Internet-Draft CoSWID July 2022 Changes from version 05 to version 06: * Improved quantities * Included proposals for implicit enumerations that were NMTOKENS * Added extension points * Improved exemplary firmware-resource extension Changes from version 04 to version 05: * Clarified language around SWID and CoSWID to make more consistent use of these terms. * Added language describing CBOR optimizations for single vs. arrays in the model front matter. * Fixed a number of grammatical, spelling, and wording issues. * Documented extension points that use CDDL sockets. * Converted IANA registration tables to markdown tables, reserving the 0 value for use when a value is not known. * Updated a number of references to their current versions. Changes from version 03 to version 04: * Re-index label values in the CDDL. * Added a Section describing the CoSWID model in detail. * Created IANA registries for entity-role and version-scheme Changes from version 02 to version 03: * Updated CDDL to allow for a choice between a payload or evidence * Re-index label values in the CDDL. * Added item definitions * Updated references for COSE, CBOR Web Token, and CDDL. Changes from version 01 to version 02: Birkholz, et al. Expires 20 January 2023 [Page 76] Internet-Draft CoSWID July 2022 * Added extensions for Firmware and CoSWID use as Reference Integrity Measurements (CoSWID RIM) * Changes meta handling in CDDL from use of an explicit use of items to a more flexible unconstrained collection of items. * Added Sections discussing use of COSE Signatures and CBOR Web Tokens Changes from version 00 to version 01: * Added CWT usage for absolute SWID paths on a device * Fixed cardinality of type-choices including arrays * Included first iteration of firmware resource-collection 12. References 12.1. Normative References [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012, . [BCP26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [I-D.ietf-cose-countersign] Schaad, J. and R. Housley, "CBOR Object Signing and Encryption (COSE): Countersignatures", Work in Progress, Internet-Draft, draft-ietf-cose-countersign-05, 23 June 2021, . [I-D.ietf-cose-rfc8152bis-struct] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", Work in Progress, Internet-Draft, draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, . Birkholz, et al. Expires 20 January 2023 [Page 77] Internet-Draft CoSWID July 2022 [IANA.cbor-tags] IANA, "Concise Binary Object Representation (CBOR) Tags", 19 September 2013, . [IANA.core-parameters] IANA, "Constrained RESTful Environments (CoRE) Parameters", 8 June 2012, . [IANA.media-types] IANA, "Media Types", 13 July 2022, . [IANA.named-information] IANA, "Named Information", 14 August 2012, . [IANA.pa-tnc-parameters] IANA, "Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) Parameters", 13 November 2009, . [IANA.uri-schemes] IANA, "Uniform Resource Identifier (URI) Schemes", 6 July 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, . Birkholz, et al. Expires 20 January 2023 [Page 78] Internet-Draft CoSWID July 2022 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, . [RFC8412] Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and J. Fitzgerald-McKay, "Software Inventory Message and Attributes (SWIMA) for PA-TNC", RFC 8412, DOI 10.17487/RFC8412, July 2018, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [SAM] "Information technology - Software asset management - Part 5: Overview and vocabulary", ISO/IEC 19770-5:2015, 15 November 2013. Birkholz, et al. Expires 20 January 2023 [Page 79] Internet-Draft CoSWID July 2022 [SWID] "Information technology - Software asset management - Part 2: Software identification tag", ISO/IEC 19770-2:2015, 1 October 2015. [UNSPSC] "United Nations Standard Products and Services Code", 26 October 2020, . [W3C.REC-css3-mediaqueries-20120619] Rivoal, F., Ed., "Media Queries", W3C REC REC-css3- mediaqueries-20120619, W3C REC-css3-mediaqueries-20120619, 19 June 2012, . [W3C.REC-xmlschema-2-20041028] Malhotra, A., Ed. and P. V. Biron, Ed., "XML Schema Part 2: Datatypes Second Edition", W3C REC REC-xmlschema- 2-20041028, W3C REC-xmlschema-2-20041028, 28 October 2004, . [W3C.REC-xpath20-20101214] Berglund, A., Ed., Chamberlin, D., Ed., Simeon, J., Ed., Robie, J., Ed., Fernandez, M., Ed., Kay, M., Ed., and S. Boag, Ed., "XML Path Language (XPath) 2.0 (Second Edition)", W3C REC-xpath20-20101214, W3C REC REC- xpath20-20101214, 14 December 2010, . 12.2. Informative References [CamelCase] "UpperCamelCase", 29 August 2014, . [I-D.ietf-rats-architecture] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture", Work in Progress, Internet-Draft, draft-ietf-rats-architecture- 18, 14 June 2022, . [KebabCase] "KebabCase", 18 December 2014, . [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, . Birkholz, et al. Expires 20 January 2023 [Page 80] Internet-Draft CoSWID July 2022 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, . [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- Oriented Lightweight Information Exchange (ROLIE)", RFC 8322, DOI 10.17487/RFC8322, February 2018, . [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Description Specification", RFC 8520, DOI 10.17487/RFC8520, March 2019, . [SEMVER] Preston-Werner, T., "Semantic Versioning 2.0.0", . [SWID-GUIDANCE] Waltermire, D., Cheikes, B. A., Feldman, L., and G. Witte, "Guidelines for the Creation of Interoperable Software Identification (SWID) Tags", NISTIR 8060, April 2016, . [X.1520] "Recommendation ITU-T X.1520 (2014), Common vulnerabilities and exposures", 20 April 2011. Acknowledgments This document draws heavily on the concepts defined in the ISO/IEC 19770-2:2015 specification. The authors of this document are grateful for the prior work of the 19770-2 contributors. We are also grateful for the careful reviews provided by the IESG reviewers. Special thanks go to Benjamin Kaduk. Contributors Carsten Bormann Universität Bremen TZI Postfach 330440 D-28359 Bremen Germany Birkholz, et al. Expires 20 January 2023 [Page 81] Internet-Draft CoSWID July 2022 Phone: +49-421-218-63921 Email: cabo@tzi.org Carsten Bormann contributed to the CDDL specifications and the IANA considerations. Authors' Addresses Henk Birkholz Fraunhofer SIT Rheinstrasse 75 64295 Darmstadt Germany Email: henk.birkholz@sit.fraunhofer.de Jessica Fitzgerald-McKay National Security Agency 9800 Savage Road Ft. Meade, Maryland United States of America Email: jmfitz2@cyber.nsa.gov Charles Schmidt The MITRE Corporation 202 Burlington Road Bedford, Massachusetts 01730 United States of America Email: cmschmidt@mitre.org David Waltermire National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, Maryland 20877 United States of America Email: david.waltermire@nist.gov Birkholz, et al. Expires 20 January 2023 [Page 82] ./draft-ietf-add-ddr-10.txt0000644000764400076440000013267014273262741015165 0ustar iustiniustin ADD T. Pauly Internet-Draft E. Kinnear Intended status: Standards Track Apple Inc. Expires: 6 February 2023 C. A. Wood Cloudflare P. McManus Fastly T. Jensen Microsoft 5 August 2022 Discovery of Designated Resolvers draft-ietf-add-ddr-10 Abstract This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An encrypted DNS resolver discovered in this manner is referred to as a "Designated Resolver". This mechanism can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. This mechanism is designed to be limited to cases where unencrypted DNS resolvers and their designated resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an encrypted DNS resolver is known. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Adaptive DNS Discovery Working Group mailing list (add@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/add/. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-add/draft-ietf-add-ddr. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Pauly, et al. Expires 6 February 2023 [Page 1] Internet-Draft DDR August 2022 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 February 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. DNS Service Binding Records . . . . . . . . . . . . . . . . . 4 4. Discovery Using Resolver IP Addresses . . . . . . . . . . . . 6 4.1. Use of Designated Resolvers . . . . . . . . . . . . . . . 7 4.1.1. Use of Designated Resolvers across network changes . 8 4.2. Verified Discovery . . . . . . . . . . . . . . . . . . . 8 4.3. Opportunistic Discovery . . . . . . . . . . . . . . . . . 9 5. Discovery Using Resolver Names . . . . . . . . . . . . . . . 10 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 11 6.1. Caching Forwarders . . . . . . . . . . . . . . . . . . . 11 6.2. Certificate Management . . . . . . . . . . . . . . . . . 11 6.3. Server Name Handling . . . . . . . . . . . . . . . . . . 11 6.4. Handling non-DDR queries for resolver.arpa . . . . . . . 12 6.5. Interaction with Network-Designated Resolvers . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8.1. Special Use Domain Name "resolver.arpa" . . . . . . . . . 14 8.2. Domain Name Reservation Considerations . . . . . . . . . 14 Pauly, et al. Expires 6 February 2023 [Page 2] Internet-Draft DDR August 2022 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Rationale for using a Special Use Domain Name . . . 18 Appendix B. Rationale for using SVCB records . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction When DNS clients wish to use encrypted DNS protocols such as DNS- over-TLS (DoT) [RFC7858], DNS-over-QUIC (DoQ) [RFC9250], or DNS-over- HTTPS (DoH) [RFC8484], they can require additional information beyond the IP address of the DNS server, such as the resolver's hostname, alternate IP addresses, non-standard ports, or URI templates. However, common configuration mechanisms only provide the resolver's IP address during configuration. Such mechanisms include network provisioning protocols like DHCP [RFC2132] [RFC8415] and IPv6 Router Advertisement (RA) options [RFC8106], as well as manual configuration. This document defines two mechanisms for clients to discover designated resolvers that support these encrypted protocols using DNS server Service Binding (SVCB, [I-D.ietf-dnsop-svcb-https]) records: 1. When only an IP address of an Unencrypted DNS Resolver is known, the client queries a special use domain name (SUDN) [RFC6761] to discover DNS SVCB records associated with one or more Encrypted DNS Resolvers the Unencrypted DNS Resolver has designated for use when support for DNS encryption is requested (Section 4). 2. When the hostname of an Encrypted DNS Resolver is known, the client requests details by sending a query for a DNS SVCB record. This can be used to discover alternate encrypted DNS protocols supported by a known server, or to provide details if a resolver name is provisioned by a network (Section 5). Both of these approaches allow clients to confirm that a discovered Encrypted DNS Resolver is designated by the originally provisioned resolver. "Designated" in this context means that the resolvers are operated by the same entity or cooperating entities; for example, the resolvers are accessible on the same IP address, or there is a certificate that contains the IP address for the original designating resolver. Pauly, et al. Expires 6 February 2023 [Page 3] Internet-Draft DDR August 2022 1.1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology This document defines the following terms: DDR: Discovery of Designated Resolvers. Refers to the mechanisms defined in this document. Designated Resolver: A resolver, presumably an Encrypted DNS Resolver, designated by another resolver for use in its own place. This designation can be verified with TLS certificates. Encrypted DNS Resolver: A DNS resolver using any encrypted DNS transport. This includes current mechanisms such as DoH, DoT, and DoQ, as well as future mechanisms. Unencrypted DNS Resolver: A DNS resolver using a transport without encryption, historically TCP or UDP port 53. 3. DNS Service Binding Records DNS resolvers can advertise one or more Designated Resolvers that may offer support over encrypted channels and are controlled by the same entity. When a client discovers Designated Resolvers, it learns information such as the supported protocols and ports. This information is provided in ServiceMode Service Binding (SVCB) records for DNS Servers, although AliasMode SVCB records can be used to direct clients to the needed ServiceMode SVCB record per [I-D.ietf-dnsop-svcb-https]. The formatting of these records, including the DNS-unique parameters such as "dohpath", are defined by [I-D.ietf-add-svcb-dns]. The following is an example of an SVCB record describing a DoH server discovered by querying for _dns.example.net: _dns.example.net. 7200 IN SVCB 1 example.net. ( alpn=h2 dohpath=/dns-query{?dns} ) Pauly, et al. Expires 6 February 2023 [Page 4] Internet-Draft DDR August 2022 The following is an example of an SVCB record describing a DoT server discovered by querying for _dns.example.net: _dns.example.net. 7200 IN SVCB 1 dot.example.net ( alpn=dot port=8530 ) The following is an example of an SVCB record describing a DoQ server discovered by querying for _dns.example.net: _dns.example.net. 7200 IN SVCB 1 doq.example.net ( alpn=doq port=8530 ) If multiple Designated Resolvers are available, using one or more encrypted DNS protocols, the resolver deployment can indicate a preference using the priority fields in each SVCB record [I-D.ietf-dnsop-svcb-https]. If the client encounters a mandatory parameter in an SVCB record it does not understand, it MUST NOT use that record to discover a Designated Resolver, in accordance with Section 8 of [I-D.ietf-dnsop-svcb-https]. The client can still use other records in the same response if the client can understand all of their mandatory parameters. This allows future encrypted deployments to simultaneously support protocols even if a given client is not aware of all those protocols. For example, if the Unencrypted DNS Resolver returns three SVCB records, one for DoH, one for DoT, and one for a yet-to-exist protocol, a client which only supports DoH and DoT should be able to use those records while safely ignoring the third record. To avoid name lookup deadlock, clients that use Designated Resolvers need to ensure that a specific Encrypted Resolver is not used for any queries that are needed to resolve the name of the resolver itself or to perform certificate revocation checks for the resolver, as described in Section 10 of [RFC8484]. Designated Resolvers need to ensure this deadlock is avoidable as described in Section 10 of [RFC8484]. This document focuses on discovering DoH, DoT, and DoQ Designated Resolvers. Other protocols can also use the format defined by [I-D.ietf-add-svcb-dns]. However, if any such protocol does not involve some form of certificate validation, new validation mechanisms will need to be defined to support validating designation as defined in Section 4.2. Pauly, et al. Expires 6 February 2023 [Page 5] Internet-Draft DDR August 2022 4. Discovery Using Resolver IP Addresses When a DNS client is configured with an Unencrypted DNS Resolver IP address, it SHOULD query the resolver for SVCB records of a service with a scheme of "dns" and an Authority of "resolver.arpa" before making other queries. This allows the client to switch to using Encrypted DNS for all other queries, if possible. Specifically, the client issues a query for _dns.resolver.arpa. with the SVCB resource record type (64) [I-D.ietf-dnsop-svcb-https]. Responses to the SVCB query for the "resolver.arpa" SUDN describe Designated Resolvers. To ensure that different Designated Resolver configurations can be correctly distinguished and associated with A and AAAA records for the resolver, ServiceMode SVCB responses to these queries MUST NOT use the "." or "resolver.arpa" value for the TargetName. Similarly, clients MUST NOT perform A or AAAA queries for "resolver.arpa". The following is an example of an SVCB record describing a DoH server discovered by querying for _dns.resolver.arpa: _dns.resolver.arpa. 7200 IN SVCB 1 doh.example.net ( alpn=h2 dohpath=/dns-query{?dns} ) The following is an example of an SVCB record describing a DoT server discovered by querying for _dns.resolver.arpa: _dns.resolver.arpa. 7200 IN SVCB 1 dot.example.net ( alpn=dot port=8530 ) The following is an example of an SVCB record describing a DoQ server discovered by querying for _dns.resolver.arpa: _dns.resolver.arpa. 7200 IN SVCB 1 doq.example.net ( alpn=doq port=8530 ) If the recursive resolver that receives this query has one or more Designated Resolvers, it will return the corresponding SVCB records. When responding to these special queries for "resolver.arpa", the recursive resolver SHOULD include the A and AAAA records for the name of the Designated Resolver in the Additional Answers section. This will save the DNS client an additional round trip to retrieve the address of the designated resolver; see Section 5 of [I-D.ietf-dnsop-svcb-https]. Designated Resolvers SHOULD be accessible using the IP address families that are supported by their associated Unencrypted DNS Resolvers. If an Unencrypted DNS Resolver is accessible using an Pauly, et al. Expires 6 February 2023 [Page 6] Internet-Draft DDR August 2022 IPv4 address, it ought to provide an A record for an IPv4 address of the Designated Resolver; similarly, if it is accessible using an IPv6 address, it ought to provide a AAAA record for an IPv6 address of the Designated Resolver. The Designated Resolver MAY support more address families than the Unencrypted DNS Resolver, but it SHOULD NOT support fewer. If this is not done, clients that only have connectivity over one address family might not be able to access the Designated Resolver. If the recursive resolver that receives this query has no Designated Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa" zone, to provide a consistent and accurate signal to clients that it does not have a Designated Resolver. 4.1. Use of Designated Resolvers When a client discovers Designated Resolvers from an Unencrypted DNS Resolver IP address, it can choose to use these Designated Resolvers either automatically, or based on some other policy, heuristic, or user choice. This document defines two preferred methods to automatically use Designated Resolvers: * Verified Discovery (Section 4.2), for when a TLS certificate can be used to validate the resolver's identity. * Opportunistic Discovery (Section 4.3), for when a resolver's IP address is a private or local address. A client MAY additionally use a discovered Designated Resolver without either of these methods, based on implementation-specific policy or user input. Details of such policy are out of scope of this document. Clients MUST NOT automatically use a Designated Resolver without some sort of validation, such as the two methods defined in this document or a future mechanism. Use without validation can allow an attacker to direct traffic to an Encrypted Resolver that is unrelated to the original Unencrypted DNS Resolver, as described in Section 7. A client MUST NOT re-use a designation discovered using the IP address of one Unencrypted DNS Resolver in place of any other Unencrypted DNS Resolver. Instead, the client needs to repeat the discovery process to discover the Designated Resolver of the other Unencrypted DNS Resolver. In other words, designations are per- resolver and MUST NOT be used to configure the client's universal DNS behavior. This ensures in all cases that queries are being sent to a party designated by the resolver originally being used. Pauly, et al. Expires 6 February 2023 [Page 7] Internet-Draft DDR August 2022 4.1.1. Use of Designated Resolvers across network changes If a client is configured with the same Unencrypted DNS Resolver IP address on multiple different networks, a Designated Resolver that has been discovered on one network SHOULD NOT be reused on any of the other networks without repeating the discovery process for each network, since the same IP address may be used for different servers on the different networks. 4.2. Verified Discovery Verified Discovery is a mechanism that allows automatic use of a Designated Resolver that supports DNS encryption that performs a TLS handshake. In order to be considered a verified Designated Resolver, the TLS certificate presented by the Designated Resolver needs to pass the following checks made by the client: 1. The client MUST verify the chain of certificates up to a trust anchor as described in Section 6 of [RFC5280]. This SHOULD use the default system or application trust anchors, unless otherwise configured. 2. The client MUST verify that the certificate contains the IP address of the designating Unencrypted DNS Resolver in an iPAddress entry of the subjectAltName extension as described in Section 4.2.1.6 of [RFC5280]. If these checks pass, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the Unencrypted DNS Resolver, so as to prefer Encrypted DNS whenever possible. If these checks fail, the client MUST NOT automatically use the discovered Designated Resolver if this designation was only discovered via a _dns.resolver.arpa. query (if the designation was advertised directly by the network as described in Section 6.5, the server can still be used). Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted DNS Resolver for the length of time indicated by the SVCB record's Time to Live (TTL) in order to avoid excessive queries that will lead to further failed validations. The client MAY issue new queries if the SVCB record's TTL is excessively long (as determined by client policy) to minimize the length of time an intermittent attacker can prevent use of encrypted DNS. Pauly, et al. Expires 6 February 2023 [Page 8] Internet-Draft DDR August 2022 If the Designated Resolver and the Unencrypted DNS Resolver share an IP address, clients MAY choose to opportunistically use the Designated Resolver even without this certificate check (Section 4.3). If the IP address is not shared, opportunistic use allows for attackers to redirect queries to an unrelated Encrypted Resolver, as described in Section 7. Connections to a Designated Resolver can use a different IP address than the IP address of the Unencrypted DNS Resolver, such as if the process of resolving the SVCB service yields additional addresses. Even when a different IP address is used for the connection, the TLS certificate checks described in this section still apply for the original IP address of the Unencrypted DNS Resolver. 4.3. Opportunistic Discovery There are situations where Verified Discovery of encrypted DNS configuration over unencrypted DNS is not possible. This includes Unencrypted DNS Resolvers on private IP addresses [RFC1918], Unique Local Addresses (ULAs) [RFC4193], and Link Local Addresses [RFC3927] [RFC4291], whose identity cannot be safely confirmed using TLS certificates under most conditions. An Opportunistic Privacy Profile is defined for DoT in Section 4.1 of [RFC7858] as a mode in which clients do not validate the name of the resolver presented in the certificate. This Opportunistic Privacy Profile similarly applies to DoQ [RFC9250]. For this profile, Section 4.1 of [RFC7858] explains that clients might or might not validate the resolver; however, even if clients choose to perform some certificate validation checks, they will not be able to validate the names presented in the SubjectAlternativeName field of the certificate for private and local IP addresses. A client MAY use information from the SVCB record for "_dns.resolver.arpa" with this Opportunistic Privacy Profile as long as the IP address of the Encrypted DNS Resolver does not differ from the IP address of the Unencrypted DNS Resolver. Clients SHOULD use this mode only for resolvers using private or local IP addresses, since resolvers that use other addresses are able to provision TLS certificates for their addresses. Pauly, et al. Expires 6 February 2023 [Page 9] Internet-Draft DDR August 2022 5. Discovery Using Resolver Names A DNS client that already knows the name of an Encrypted DNS Resolver can use DDR to discover details about all supported encrypted DNS protocols. This situation can arise if a client has been configured to use a given Encrypted DNS Resolver, or if a network provisioning protocol (such as DHCP or IPv6 Router Advertisements) provides a name for an Encrypted DNS Resolver alongside the resolver IP address, such as by using Discovery of Network Resolvers (DNR) [I-D.ietf-add-dnr]. For these cases, the client simply sends a DNS SVCB query using the known name of the resolver. This query can be issued to the named Encrypted DNS Resolver itself or to any other resolver. Unlike the case of bootstrapping from an Unencrypted DNS Resolver (Section 4), these records SHOULD be available in the public DNS if the same domain name's A or AAAA records are available in the public DNS to allow using any resolver to discover another resolver's Designated Resolvers. When the name can only be resolved in private namespaces, these records SHOULD be available to the same audience as the A and AAAA records. For example, if the client already knows about a DoT server resolver.example.com, it can issue an SVCB query for _dns.resolver.example.com to discover if there are other encrypted DNS protocols available. In the following example, the SVCB answers indicate that resolver.example.com supports both DoH and DoT, and that the DoH server indicates a higher priority than the DoT server. _dns.resolver.example.com. 7200 IN SVCB 1 resolver.example.com. ( alpn=h2 dohpath=/dns-query{?dns} ) _dns.resolver.example.com. 7200 IN SVCB 2 resolver.example.com. ( alpn=dot ) Clients MUST validate that for any Encrypted DNS Resolver discovered using a known resolver name, the TLS certificate of the resolver contains the known name in a subjectAltName extension. In the example above, this means that both servers need to have certificates that cover the name resolver.example.com. Often, the various supported encrypted DNS protocols will be specified such that the SVCB TargetName matches the known name, as is true in the example above. However, even when the TargetName is different (for example, if the DoH server had a TargetName of doh.example.com), the clients still check for the original known resolver name in the certificate. Note that this resolver validation is not related to the DNS resolver that provided the SVCB answer. Pauly, et al. Expires 6 February 2023 [Page 10] Internet-Draft DDR August 2022 As another example, being able to discover a Designated Resolver for a known Encrypted DNS Resolver is useful when a client has a DoT configuration for foo.resolver.example.com but is on a network that blocks DoT traffic. The client can still send a query to any other accessible resolver (either the local network resolver or an accessible DoH server) to discover if there is a designated DoH server for foo.resolver.example.com. 6. Deployment Considerations Resolver deployments that support DDR are advised to consider the following points. 6.1. Caching Forwarders A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" (or any subdomains) upstream. This prevents a client from receiving an SVCB record that will fail to authenticate because the forwarder's IP address is not in the upstream resolver's Designated Resolver's TLS certificate SAN field. A DNS forwarder which already acts as a completely transparent forwarder MAY choose to forward these queries when the operator expects that this does not apply, either because the operator knows that the upstream resolver does have the forwarder's IP address in its TLS certificate's SAN field or that the operator expects clients to validate the connection via some future mechanism. Operators who choose to forward queries for "resolver.arpa" upstream should note that client behavior is never guaranteed and use of DDR by a resolver does not communicate a requirement for clients to use the SVCB record when it cannot be verified. 6.2. Certificate Management Resolver owners that support Verified Discovery will need to list valid referring IP addresses in their TLS certificates. This may pose challenges for resolvers with a large number of referring IP addresses. 6.3. Server Name Handling Clients MUST NOT use "resolver.arpa" as the server name either in the TLS Server Name Indication (SNI) ([RFC8446]) for DoT, DoQ, or DoH connections, or in the URI host for DoH requests. When performing discovery using resolver IP addresses, clients MUST use the original IP address of the Unencrypted DNS Resolver as the URI host for DoH requests. Pauly, et al. Expires 6 February 2023 [Page 11] Internet-Draft DDR August 2022 Note that since IP addresses are not supported by default in the TLS SNI, resolvers that support discovery using IP addresses will need to be configured to present the appropriate TLS certificate when no SNI is present for DoT, DoQ, and DoH. 6.4. Handling non-DDR queries for resolver.arpa DNS resolvers that support DDR by responding to queries for _dns.resolver.arpa MUST treat resolver.arpa as a locally served zone per [RFC6303]. In practice, this means that resolvers SHOULD respond to queries of any type other than SVCB for _dns.resolver.arpa with NODATA and queries of any type for any domain name under resolver.arpa with NODATA. 6.5. Interaction with Network-Designated Resolvers Discovery of network-designated resolvers (DNR, [I-D.ietf-add-dnr]) allows a network to provide designation of resolvers directly through DHCP [RFC2132] [RFC8415] and IPv6 Router Advertisement (RA) [RFC4861] options. When such indications are present, clients can suppress queries for "resolver.arpa" to the unencrypted DNS server indicated by the network over DHCP or RAs, and the DNR indications SHOULD take precedence over those discovered using "resolver.arpa" for the same resolver if there is a conflict, since DNR is considered a more reliable source. The designated resolver information in DNR might not contain a full set of SvcParams needed to connect to an encrypted DNS resolver. In such a case, the client can use an SVCB query using a resolver name, as described in Section 5, to the authentication-domain-name (ADN). 7. Security Considerations Since clients can receive DNS SVCB answers over unencrypted DNS, on- path attackers can prevent successful discovery by dropping SVCB queries or answers, and thus prevent clients from switching to use encrypted DNS. Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated Resolver and such an active attack. To limit the impact of discovery queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. Section 8.2 of [I-D.ietf-add-svcb-dns] describes a second downgrade attack where an attacker can block connections to the encrypted DNS server. For DDR, clients need to validate a Designated Resolver using a connection to the server before trusting it, so attackers that can block these connections can prevent clients from switching to use encrypted DNS. Pauly, et al. Expires 6 February 2023 [Page 12] Internet-Draft DDR August 2022 Encrypted DNS Resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based solely on metadata in the SVCB record, such as the HTTP path or alternate port number, which are parameters that an attacker could modify. For example, if a DoH resolver provides a filtering service for one URI path, and a non-filtered service for another URI path, an attacker could select which of these services is used by modifying the "dohpath" parameter. These attacks can be mitigated by providing separate resolver IP addresses or hostnames. While the IP address of the Unencrypted DNS Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such as via manual configuration, a VPN, or on a network with protections like RA-Guard [RFC6105]. An attacker might try to direct Encrypted DNS traffic to itself by causing the client to think that a discovered Designated Resolver uses a different IP address from the Unencrypted DNS Resolver. Such a Designated Resolver might have a valid certificate, but be operated by an attacker that is trying to observe or modify user queries without the knowledge of the client or network. If the IP address of a Designated Resolver differs from that of an Unencrypted DNS Resolver, clients applying Verified Discovery (Section 4.2) MUST validate that the IP address of the Unencrypted DNS Resolver is covered by the SubjectAlternativeName of the Designated Resolver's TLS certificate. If that validation fails, the client MUST NOT automatically use the discovered Designated Resolver. Clients using Opportunistic Discovery (Section 4.3) MUST be limited to cases where the Unencrypted DNS Resolver and Designated Resolver have the same IP address, which SHOULD be a private or local IP address. Clients which do not follow Opportunistic Discovery (Section 4.3) and instead try to connect without first checking for a designation run the possible risk of being intercepted by an attacker hosting an Encrypted DNS Resolver on an IP address of an Unencrypted DNS Resolver where the attacker has failed to gain control of the Unencrypted DNS Resolver. The constraints on the use of Designated Resolvers specified here apply specifically to the automatic discovery mechanisms defined in this document, which are referred to as Verified Discovery and Opportunistic Discovery. Clients MAY use some other mechanism to verify and use Designated Resolvers discovered using the DNS SVCB record. However, use of such an alternate mechanism needs to take into account the attack scenarios detailed here. 8. IANA Considerations Pauly, et al. Expires 6 February 2023 [Page 13] Internet-Draft DDR August 2022 8.1. Special Use Domain Name "resolver.arpa" This document calls for the addition of "resolver.arpa" to the Special-Use Domain Names (SUDN) registry established by [RFC6761]. IANA is requested to add an entry in "Transport-Independent Locally- Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain", listing this document as the reference. 8.2. Domain Name Reservation Considerations In accordance with Section 5 of [RFC6761], the answers to the following questions are provided relative to this document: 1) Are human users expected to recognize these names as special and use them differently? In what way? No. This name is used automatically by DNS stub resolvers running on client devices on behalf of users, and users will never see this name directly. 2) Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way? No. There is no use case where a non-DNS application (covered by the next question) would need to use this name. 3) Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how? Yes. DNS client implementors are expected to use this name when querying for a resolver's properties instead of records for the name itself. DNS servers are expected to respond to queries for this name with their own properties instead of checking the matching zone as it would for normal domain names. 4) Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how? Yes. Caching domain name servers should not forward queries for this name to avoid causing validation failures due to IP address mismatch. Pauly, et al. Expires 6 February 2023 [Page 14] Internet-Draft DDR August 2022 5) Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how? No. DDR is designed for use by recursive resolvers. Theoretically, an authoritative server could choose to support this name if it wants to advertise support for encrypted DNS protocols over plain-text DNS, but that scenario is covered by other work in the IETF DNSOP working group. 6) Does this reserved Special-Use Domain Name have any potential impact on DNS server operators? If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid? Do DNS server operators need to know about that and understand why? Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware? This name is locally served, and any resolver which supports this name should never forward the query. DNS server operators should be aware that records for this name will be used by clients to modify the way they connect to their resolvers. 7) How should DNS Registries/Registrars treat requests to register this reserved domain name? Should such requests be denied? Should such requests be allowed, but only to a specially-designated entity? IANA should hold the registration for this name. Non-IANA requests to register this name should always be denied by DNS Registries/ Registrars. 9. References 9.1. Normative References [I-D.ietf-add-dnr] Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. Jensen, "DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)", Work in Progress, Internet-Draft, draft-ietf-add-dnr-12, 24 July 2022, . Pauly, et al. Expires 6 February 2023 [Page 15] Internet-Draft DDR August 2022 [I-D.ietf-add-svcb-dns] Schwartz, B., "Service Binding Mapping for DNS Servers", Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns- 06, 5 July 2022, . [I-D.ietf-dnsop-svcb-https] Schwartz, B., Bishop, M., and E. Nygren, "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- dnsop-svcb-https-10, 24 May 2022, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, May 2005, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011, . Pauly, et al. Expires 6 February 2023 [Page 16] Internet-Draft DDR August 2022 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, . 9.2. Informative References [I-D.ietf-tls-esni] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-14, 13 February 2022, . [I-D.schinazi-httpbis-doh-preference-hints] Schinazi, D., Sullivan, N., and J. Kipp, "DoH Preference Hints for HTTP", Work in Progress, Internet-Draft, draft- schinazi-httpbis-doh-preference-hints-02, 13 July 2020, . [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . Pauly, et al. Expires 6 February 2023 [Page 17] Internet-Draft DDR August 2022 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, . [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, . [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8880] Cheshire, S. and D. Schinazi, "Special Use Domain Name 'ipv4only.arpa'", RFC 8880, DOI 10.17487/RFC8880, August 2020, . Appendix A. Rationale for using a Special Use Domain Name The "resolver.arpa" SUDN is similar to "ipv4only.arpa" in that the querying client is not interested in an answer from the authoritative "arpa" name servers. The intent of the SUDN is to allow clients to communicate with the Unencrypted DNS Resolver much like "ipv4only.arpa" allows for client-to-middlebox communication. For more context, see the rationale behind "ipv4only.arpa" in [RFC8880]. Appendix B. Rationale for using SVCB records This mechanism uses SVCB/HTTPS resource records [I-D.ietf-dnsop-svcb-https] to communicate that a given domain designates a particular Designated Resolver for clients to use in place of an Unencrypted DNS Resolver (using a SUDN) or another Encrypted DNS Resolver (using its domain name). There are various other proposals for how to provide similar functionality. There are several reasons that this mechanism has chosen SVCB records: Pauly, et al. Expires 6 February 2023 [Page 18] Internet-Draft DDR August 2022 * Discovering encrypted DNS resolvers using DNS records keeps client logic for DNS self-contained and allows a DNS resolver operator to define which resolver names and IP addresses are related to one another. * Using DNS records also does not rely on bootstrapping with higher- level application operations (such as [I-D.schinazi-httpbis-doh-preference-hints]). * SVCB records are extensible and allow definition of parameter keys. This makes them a superior mechanism for extensibility as compared to approaches such as overloading TXT records. The same keys can be used for discovering Designated Resolvers of different transport types as well as those advertised by Unencrypted DNS Resolvers or another Encrypted DNS Resolver. * Clients and servers that are interested in privacy of names will already need to support SVCB records in order to use Encrypted TLS Client Hello [I-D.ietf-tls-esni]. Without encrypting names in TLS, the value of encrypting DNS is reduced, so pairing the solutions provides the largest benefit. Authors' Addresses Tommy Pauly Apple Inc. One Apple Park Way Cupertino, California 95014, United States of America Email: tpauly@apple.com Eric Kinnear Apple Inc. One Apple Park Way Cupertino, California 95014, United States of America Email: ekinnear@apple.com Christopher A. Wood Cloudflare 101 Townsend St San Francisco, United States of America Email: caw@heapingbits.net Pauly, et al. Expires 6 February 2023 [Page 19] Internet-Draft DDR August 2022 Patrick McManus Fastly Email: mcmanus@ducksong.com Tommy Jensen Microsoft Email: tojens@microsoft.com Pauly, et al. Expires 6 February 2023 [Page 20] ./draft-ietf-sidrops-8210bis-10.txt0000644000764400076440000025462014252746262016441 0ustar iustiniustin Network Working Group R. Bush Internet-Draft IIJ, Arrcus, & DRL Intended status: Standards Track R. Austein Expires: 18 December 2022 Dragon Research Labs 16 June 2022 The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 draft-ietf-sidrops-8210bis-10 Abstract In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. RFC 6810 describes version 0, and RFC 8210 describes version 1. This document is compatible with both. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 18 December 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Bush & Austein Expires 18 December 2022 [Page 1] Internet-Draft RPKI-Router Protocol June 2022 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Changes from RFC 8210 . . . . . . . . . . . . . . . . . . 3 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 5 4. Operational Overview . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 6 5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 7 5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 12 5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 12 5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 14 5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 14 5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 15 5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 16 5.11. Error Report . . . . . . . . . . . . . . . . . . . . . . 17 5.12. ASPA PDU . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Protocol Timing Parameters . . . . . . . . . . . . . . . . . 20 7. Protocol Version Negotiation . . . . . . . . . . . . . . . . 21 8. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . 23 8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 23 8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 24 8.3. No Incremental Update Available . . . . . . . . . . . . . 24 8.4. Cache Has No Data Available . . . . . . . . . . . . . . . 25 9. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 27 9.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 27 9.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 28 9.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . 28 10. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . 29 11. ROA PDU Race Minimization . . . . . . . . . . . . . . . . . . 30 12. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 30 13. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. Security Considerations . . . . . . . . . . . . . . . . . . . 32 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 16.1. Normative References . . . . . . . . . . . . . . . . . . 34 16.2. Informative References . . . . . . . . . . . . . . . . . 37 Bush & Austein Expires 18 December 2022 [Page 2] Internet-Draft RPKI-Router Protocol June 2022 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction In order to verifiably validate the origin Autonomous Systems (ASes) and AS paths of BGP announcements, routers need a simple but reliable mechanism to receive cryptographically validated Resource Public Key Infrastructure (RPKI) [RFC6480] prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. The design is intentionally constrained to be usable on much of the current generation of ISP router platforms. This specification documents version 2 of the RPKI-RTR protocol. Earlier versions are documented in [RFC6810] and [RFC8210]. Though this version is, of course, preferred, the earlier versions are expected to continue to be productively deployed indefinitely, and Section 7 details how to downgrade from this version to earlier versions as needed in order to interoperate. Section 3 describes the deployment structure, and Section 4 then presents an operational overview. The binary payloads of the protocol are formally described in Section 5, and the expected Protocol Data Unit (PDU) sequences are described in Section 8. The transport protocol options are described in Section 9. Section 10 details how routers and caches are configured to connect and authenticate. Section 12 describes likely deployment scenarios. The traditional security and IANA considerations end the document. The protocol is extensible in order to support new PDUs with new semantics, if deployment experience indicates that they are needed. PDUs are versioned should deployment experience call for change. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Changes from RFC 8210 This section summarizes the significant changes between [RFC8210] and the protocol described in this document. Bush & Austein Expires 18 December 2022 [Page 3] Internet-Draft RPKI-Router Protocol June 2022 * A new ASPA (Autonomous System Provider Authorization) PDU type (Section 5.12) has been added to support [I-D.ietf-sidrops-aspa-profile]. * A small Section 11 has been added to handle two possible ROA (Route Origination Authorization) PDU race conditions, Break Before Make and Shorter Prefix First. * The protocol version number incremented from 1 (one) to 2 (two) and Section 7 has been updated accordingly. 2. Glossary The following terms are used with special meaning. Global RPKI: The authoritative data of the RPKI are published in a distributed set of servers at the IANA, Regional Internet Registries (RIRs), National Internet Registries (NIRs), and ISPs; see [RFC6481]. CA: The authoritative data of the RPKI are meant to be published by a distributed set of Certification Authorities (CAs) at the IANA, RIRs, NIRs, and ISPs (see [RFC6481]). Cache: A Cache, AKA Relying Party Cache, is a coalesced copy of the published Global RPKI data, periodically fetched or refreshed, directly or indirectly, using the rsync protocol [RFC5781] or some successor. Relying Party software is used to gather and validate the distributed data of the RPKI into a cache. Trusting this cache further is a matter between the provider of the cache and a Relying Party. Serial Number: "Serial Number" is a 32-bit strictly increasing unsigned integer which wraps from 2^32-1 to 0. It denotes the logical version of a cache. A cache increments the value when it successfully updates its data from a parent cache or from primary RPKI data. While a cache is receiving updates, new incoming data and implicit deletes are associated with the new Serial Number but MUST NOT be sent until the fetch is complete. A Serial Number is not commensurate between different caches or different protocol versions, nor need it be maintained across resets of the cache server. See [RFC1982] on DNS Serial Number Arithmetic for too much detail on the topic. Session ID: When a cache server is started, it generates a Session Bush & Austein Expires 18 December 2022 [Page 4] Internet-Draft RPKI-Router Protocol June 2022 ID to uniquely identify the instance of the cache and to bind it to the sequence of Serial Numbers that cache instance will generate. This allows the router to restart a failed session knowing that the Serial Number it is using is commensurate with that of the cache. Payload PDU: A payload PDU is a protocol message which contains data for use by the router, as opposed to a PDU which conveys the control mechanisms of this protocol. Prefixes and Router Keys are examples of payload PDUs. 3. Deployment Structure Deployment of the RPKI to reach routers has a three-level structure as follows: Global RPKI: The authoritative data of the RPKI are published in a distributed set of servers at the IANA, RIRs, NIRs, and ISPs (see [RFC6481]). Local Caches: Local caches are a local set of one or more collected and verified caches of RPKI data. A Relying Party, e.g., router or other client, MUST have a trust relationship with, and a trusted transport channel to, any cache(s) it uses. Routers: A router fetches data from a local cache using the protocol described in this document. It is said to be a client of the cache. There MAY be mechanisms for the router to assure itself of the authenticity of the cache and to authenticate itself to the cache (see Section 9). 4. Operational Overview A router establishes and keeps open a transport connection to one or more caches with which it has client/server relationships. It is configured with a semi-ordered list of caches and establishes a connection to the most preferred cache, or set of caches, which accept the connections. The router MUST choose the most preferred, by configuration, cache or set of caches so that the operator may control load on their caches and the Global RPKI. Periodically, the router sends a Serial Query to the cache the most recent Serial Number for which it has received data from that cache, i.e., the router's current Serial Number, in the form of a Serial Query. When a router establishes a new session with a cache or wishes to reset a current relationship, it sends a Reset Query. Bush & Austein Expires 18 December 2022 [Page 5] Internet-Draft RPKI-Router Protocol June 2022 The cache responds to the Serial Query with all data changes which took place since the given Serial Number. This may be the null set, in which case the End of Data PDU (Section 5.8) is still sent. Note that the Serial Number comparison used to determine "since the given Serial Number" MUST take wrap-around into account; see [RFC1982]. When the router has received all data records from the cache, it sets its current Serial Number to that of the Serial Number in the received End of Data PDU. When the cache updates its database, it sends a Notify PDU to every currently connected router. This is a hint that now would be a good time for the router to poll for an update, but it is only a hint. The protocol requires the router to poll for updates periodically in any case. Strictly speaking, a router could track a cache simply by asking for a complete data set every time it updates, but this would be very inefficient. The Serial-Number-based incremental update mechanism allows an efficient transfer of just the data records which have changed since the last update. As with any update protocol based on incremental transfers, the router must be prepared to fall back to a full transfer if for any reason the cache is unable to provide the necessary incremental data. Unlike some incremental transfer protocols, this protocol requires the router to make an explicit request to start the fallback process; this is deliberate, as the cache has no way of knowing whether the router has also established sessions with other caches that may be able to provide better service. As a cache server must evaluate certificates and ROAs (Route Origin Authorizations; see [RFC6480]), which are time dependent, servers' clocks MUST be correct to a tolerance of an hour. Barring errors, transport connections remain up as long as the cache and router remain up and the router is not reconfigured to no longer use the cache. Should a transport connection be lost for unknown reasons, the router SHOULD try to reestablish one; being careful to not abuse the cache with two many failed requests. 5. Protocol Data Units (PDUs) The exchanges between the cache and the router are sequences of exchanges of the following PDUs according to the rules described in Section 8. Bush & Austein Expires 18 December 2022 [Page 6] Internet-Draft RPKI-Router Protocol June 2022 Reserved fields (marked "zero" in PDU diagrams) MUST be zero on transmission and MUST be ignored on receipt. 5.1. Fields of a PDU PDUs contain the following data elements: Protocol Version: An 8-bit unsigned integer, currently 2, denoting the version of this protocol. PDU Type: An 8-bit unsigned integer, denoting the type of the PDU, e.g., IPv4 Prefix. Serial Number: A 32-bit unsigned integer serializing the RPKI cache epoch when this set of PDUs was received from an upstream cache server or gathered from the Global RPKI. A cache increments its Serial Number when completing a validated update from a parent cache or the Global RPKI. Session ID: A 16-bit unsigned integer. When a cache server is started, it generates a Session ID to identify the instance of the cache and to bind it to the sequence of Serial Numbers that cache instance will generate. This allows the router to restart a failed session knowing that the Serial Number it is using is commensurate with that of the cache. If, at any time after the protocol version has been negotiated (Section 7), either the router or the cache finds that the value of the Session ID is not the same as the other's, the party which detects the mismatch MUST immediately terminate the session with an Error Report PDU with code 0 ("Corrupt Data"), and the router MUST flush all data learned from that cache. Note that sessions are specific to a particular protocol version. That is, if a cache server supports multiple versions of this protocol, happens to use the same Session ID value for multiple protocol versions, and further happens to use the same Serial Number values for two or more sessions using the same Session ID but different Protocol Version values, the Serial Numbers are not commensurate. The full test for whether Serial Numbers are commensurate requires comparing Protocol Version, Session ID, and Serial Number. To reduce the risk of confusion, cache servers SHOULD NOT use the same Session ID across multiple protocol versions, but even if they do, routers MUST treat sessions with different Protocol Version fields as separate sessions even if they do happen to have the same Session ID. Should a cache erroneously reuse a Session ID so that a router Bush & Austein Expires 18 December 2022 [Page 7] Internet-Draft RPKI-Router Protocol June 2022 does not realize that the session has changed (old Session ID and new Session ID have the same numeric value), the router may become confused as to the content of the cache. The time it takes the router to discover that it is confused will depend on whether the Serial Numbers are also reused. If the Serial Numbers in the old and new sessions are different enough, the cache will respond to the router's Serial Query with a Cache Reset, which will solve the problem. If, however, the Serial Numbers are close, the cache may respond with a Cache Response, which may not be enough to bring the router into sync. In such cases, it's likely but not certain that the router will detect some discrepancy between the state that the cache expects and its own state. For example, the Cache Response may tell the router to drop a record which the router does not hold or may tell the router to add a record which the router already has. In such cases, a router will detect the error and reset the session. The one case in which the router may stay out of sync is when nothing in the Cache Response contradicts any data currently held by the router. Using persistent storage for the Session ID or a clock-based scheme for generating Session IDs should avoid the risk of Session ID collisions. The Session ID might be a pseudorandom value, a strictly increasing value if the cache has reliable storage, et cetera. A seconds-since-epoch timestamp value such as the low order 16 bits of unsigned integer seconds since 1970-01-01T00:00:00Z ignoring leap seconds might make a good Session ID value. Length: A 32-bit unsigned integer which has as its value the count of the bytes in the entire PDU, including the 8 bytes of header which includes the length field. Flags: An 8-bit binary field, with the lowest-order bit being 1 for an announcement and 0 for a withdrawal. For a Prefix PDU (IPv4 or IPv6), the announce/withdraw flag indicates whether this PDU announces a new right to announce the prefix or withdraws a previously announced right; a withdraw effectively deletes one previously announced Prefix PDU with the exact same Prefix, Length, Max-Len, and Autonomous System Number (ASN). Similarly, for a Router Key PDU, the flag indicates whether this PDU announces a new Router Key or deletes one previously announced Router Key PDU with the exact same AS Number, subjectKeyIdentifier, and subjectPublicKeyInfo. The remaining bits in the Flags field are reserved for future use. Bush & Austein Expires 18 December 2022 [Page 8] Internet-Draft RPKI-Router Protocol June 2022 Prefix Length: An 8-bit unsigned integer denoting the shortest prefix allowed by the Prefix element. Max Length: An 8-bit unsigned integer denoting the longest prefix allowed by the Prefix element. This MUST NOT be less than the Prefix Length element. Prefix: The IPv4 or IPv6 prefix of the ROA. Autonomous System Number: A 32-bit unsigned integer representing an ASN allowed to announce a prefix or associated with a router key. Subject Key Identifier: The 20-octet Subject Key Identifier (SKI) value of a router key, as described in [RFC6487]. Subject Public Key Info: A variable length field holding a router key's subjectPublicKeyInfo value, as described in [RFC8608]. This is the full ASN.1 DER encoding of the subjectPublicKeyInfo, including the ASN.1 tag and length values of the subjectPublicKeyInfo SEQUENCE. Refresh Interval: A 32-bit interval in seconds between normal cache polls. See Section 6. Retry Interval: A 32-bit interval in seconds between cache poll retries after a failed cache poll. See Section 6. Expire Interval: A 32-bit interval in seconds during which data fetched from a cache remains valid in the absence of a successful subsequent cache poll. See Section 6. AFI Flags: An 8-bit field of the ASPA PDU where the low order bit denotes whether the AS relationships are for IPv4 (0) or IPv6 (1) AFI. Provider AS Count: A 16-bit count of Provider Autonomous System Numbers in the PDU. Customer Autonomous System Number: The 32-bit AS number of the Autonomous System that authorizes the upstream providers listed in the Provider Autonomous System list to propagate prefixes of the specified address family to other ASes. Provider Autonomous System Numbers: The set of 32-bit AS numbers authorized to propagate prefixes of the specified AFI which were received from the customer AS. Bush & Austein Expires 18 December 2022 [Page 9] Internet-Draft RPKI-Router Protocol June 2022 5.2. Serial Notify The cache notifies the router that the cache has new data. The Session ID reassures the router that the Serial Numbers are commensurate, i.e., the cache session has not been changed. Upon receipt of a Serial Notify PDU, the router MAY issue an immediate Serial Query (Section 5.3) or Reset Query (Section 5.4) without waiting for the Refresh Interval timer (see Section 6) to expire. Serial Notify is the only message that the cache can send that is not in response to a message from the router. If the router receives a Serial Notify PDU during the initial startup period where the router and cache are still negotiating to agree on a protocol version, the router MUST simply ignore the Serial Notify PDU, even if the Serial Notify PDU is for an unexpected protocol version. See Section 7 for details. 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | Session ID | | 2 | 0 | | +-------------------------------------------+ | | | Length=12 | | | +-------------------------------------------+ | | | Serial Number | | | `-------------------------------------------' 5.3. Serial Query The router sends a Serial Query to ask the cache for all announcements and withdrawals which have occurred since the Serial Number specified in the Serial Query. The cache replies to this query with a Cache Response PDU (Section 5.5) if the cache has a (possibly null) record of the changes since the Serial Number specified by the router, followed by zero or more payload PDUs and an End Of Data PDU (Section 5.8). Bush & Austein Expires 18 December 2022 [Page 10] Internet-Draft RPKI-Router Protocol June 2022 When replying to a Serial Query, the cache MUST return the minimum set of changes needed to bring the router into sync with the cache. That is, if a particular prefix or router key underwent multiple changes between the Serial Number specified by the router and the cache's current Serial Number, the cache MUST merge those changes to present the simplest possible view of those changes to the router. In general, this means that, for any particular prefix or router key, the data stream will include at most one withdrawal followed by at most one announcement, and if all of the changes cancel out, the data stream will not mention the prefix or router key at all. The rationale for this approach is that the entire purpose of the RPKI-Router protocol is to offload work from the router to the cache, and it should therefore be the cache's job to simplify the change set, thus reducing work for the router. If the cache does not have the data needed to update the router, perhaps because its records do not go back to the Serial Number in the Serial Query, then it responds with a Cache Reset PDU (Section 5.9). The Session ID tells the cache what instance the router expects to ensure that the Serial Numbers are commensurate, i.e., the cache session has not been changed. 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | Session ID | | 2 | 1 | | +-------------------------------------------+ | | | Length=12 | | | +-------------------------------------------+ | | | Serial Number | | | `-------------------------------------------' 5.4. Reset Query The router tells the cache that it wants to receive the total active, current, non-withdrawn database. The cache responds with a Cache Response PDU (Section 5.5), followed by zero or more payload PDUs and an End of Data PDU (Section 5.8). Bush & Austein Expires 18 December 2022 [Page 11] Internet-Draft RPKI-Router Protocol June 2022 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | zero | | 2 | 2 | | +-------------------------------------------+ | | | Length=8 | | | `-------------------------------------------' 5.5. Cache Response The cache responds to queries with zero or more payload PDUs. When replying to a Serial Query (Section 5.3), the cache sends the set of announcements and withdrawals that have occurred since the Serial Number sent by the client router. When replying to a Reset Query (Section 5.4), the cache sends the set of all data records it has; in this case, the announce/withdraw field in the payload PDUs MUST have the value 1 (announce). In response to a Reset Query, the new value of the Session ID tells the router the instance of the cache session for future confirmation. In response to a Serial Query, the Session ID being the same reassures the router that the Serial Numbers are commensurate, i.e., the cache session has not been changed. 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | Session ID | | 2 | 3 | | +-------------------------------------------+ | | | Length=8 | | | `-------------------------------------------' 5.6. IPv4 Prefix Bush & Austein Expires 18 December 2022 [Page 12] Internet-Draft RPKI-Router Protocol June 2022 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | zero | | 2 | 4 | | +-------------------------------------------+ | | | Length=20 | | | +-------------------------------------------+ | | Prefix | Max | | | Flags | Length | Length | zero | | | 0..32 | 0..32 | | +-------------------------------------------+ | | | IPv4 Prefix | | | +-------------------------------------------+ | | | Autonomous System Number | | | `-------------------------------------------' This PDU carries an [RFC6811] Validated ROA Payload (VRP) for an IPv4 ROA. The lowest-order bit of the Flags field is 1 for an announcement and 0 for a withdrawal. In the RPKI, nothing prevents a signing certificate from issuing two identical ROAs. In this case, there would be no semantic difference between the objects, merely a process redundancy. In the RPKI, there is also an actual need for what might appear to a router as identical IPvX PDUs. This can occur when an upstream certificate is being reissued or there is an address ownership transfer up the validation chain. The ROA would be identical in the router sense, i.e., have the same {Prefix, Len, Max-Len, ASN}, but it would have a different validation path in the RPKI. This is important to the RPKI but not to the router. The cache server MUST ensure that it has told the router client to have one and only one IPvX PDU for a unique {Prefix, Len, Max-Len, ASN} at any one point in time. Should the router client receive an IPvX PDU with a {Prefix, Len, Max-Len, ASN} identical to one it already has active, it SHOULD raise a Duplicate Announcement Received error. Bush & Austein Expires 18 December 2022 [Page 13] Internet-Draft RPKI-Router Protocol June 2022 5.7. IPv6 Prefix 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | zero | | 2 | 6 | | +-------------------------------------------+ | | | Length=32 | | | +-------------------------------------------+ | | Prefix | Max | | | Flags | Length | Length | zero | | | 0..128 | 0..128 | | +-------------------------------------------+ | | +--- ---+ | | +--- IPv6 Prefix ---+ | | +--- ---+ | | +-------------------------------------------+ | | | Autonomous System Number | | | `-------------------------------------------' This PDU carries an [RFC6811] Validated ROA Payload (VRP) for an IPv6 ROA. Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic. 5.8. End of Data The cache tells the router it has no more data for the request. The Session ID and Protocol Version MUST be the same as that of the corresponding Cache Response which began the (possibly null) sequence of payload PDUs. Bush & Austein Expires 18 December 2022 [Page 14] Internet-Draft RPKI-Router Protocol June 2022 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | Session ID | | 2 | 7 | | +-------------------------------------------+ | | | Length=24 | | | +-------------------------------------------+ | | | Serial Number | | | +-------------------------------------------+ | | | Refresh Interval | | | +-------------------------------------------+ | | | Retry Interval | | | +-------------------------------------------+ | | | Expire Interval | | | `-------------------------------------------' The Refresh Interval, Retry Interval, and Expire Interval are all 32-bit elapsed times measured in seconds. They express the timing parameters which the cache expects the router to use in deciding when to send subsequent Serial Query or Reset Query PDUs to the cache. See Section 6 for an explanation of the use and the range of allowed values for these parameters. Note that the End of Data PDU changed significantly between versions 0 and 1. Version 2 End of Data is the same as Version 1. 5.9. Cache Reset The cache may respond to a Serial Query informing the router that the cache cannot provide an incremental update starting from the Serial Number specified by the router. The router must decide whether to issue a Reset Query or switch to a different cache. Bush & Austein Expires 18 December 2022 [Page 15] Internet-Draft RPKI-Router Protocol June 2022 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | zero | | 2 | 8 | | +-------------------------------------------+ | | | Length=8 | | | `-------------------------------------------' 5.10. Router Key 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | | Version | Type | Flags | zero | | 2 | 9 | | | +-------------------------------------------+ | | | Length | | | +-------------------------------------------+ | | +--- ---+ | Subject Key Identifier | +--- ---+ | | +--- ---+ | (20 octets) | +--- ---+ | | +-------------------------------------------+ | | | AS Number | | | +-------------------------------------------+ | | | Subject Public Key Info | | | `-------------------------------------------' The Router Key PDU transports an [RFC8635] Router key. The lowest-order bit of the Flags field is 1 for an announcement and 0 for a withdrawal. Bush & Austein Expires 18 December 2022 [Page 16] Internet-Draft RPKI-Router Protocol June 2022 The cache server MUST ensure that it has told the router client to have one and only one Router Key PDU for a unique {SKI, ASN, Subject Public Key} at any one point in time. Should the router client receive a Router Key PDU with a {SKI, ASN, Subject Public Key} identical to one it already has active, it SHOULD raise a Duplicate Announcement Received error. Note that a particular ASN may appear in multiple Router Key PDUs with different Subject Public Key values, while a particular Subject Public Key value may appear in multiple Router Key PDUs with different ASNs. In the interest of keeping the announcement and withdrawal semantics as simple as possible for the router, this protocol makes no attempt to compress either of these cases. Also note that it is possible, albeit very unlikely, for multiple distinct Subject Public Key values to hash to the same SKI. For this reason, implementations MUST compare Subject Public Key values as well as SKIs when detecting duplicate PDUs. As the Subject Public Key Info is a variable length field, it must be decoded to determine where the PDU terminates. 5.11. Error Report This PDU is used by either party to report an error to the other. Error reports are only sent as responses to other PDUs, not to report errors in Error Report PDUs. Error codes are described in Section 13. The Erroneous PDU field is a binary copy of the PDU causing the error condition, including all fields. If the error is generic (e.g., "Internal Error") and not associated with the PDU to which it is responding, the Erroneous PDU field MUST be empty and the Length of Encapsulated PDU field MUST be zero. An Error Report PDU MUST NOT be sent for an Error Report PDU. If an erroneous Error Report PDU is received, the session SHOULD be dropped. If the error is associated with a PDU of excessive length, i.e., too long to be any legal PDU other than another Error Report, or a possibly corrupt length, the Erroneous PDU field MAY be truncated. Bush & Austein Expires 18 December 2022 [Page 17] Internet-Draft RPKI-Router Protocol June 2022 The Arbitrary Text field is optional; if not present, the Length of Arbitrary text field MUST be zero. If Arbitrary Text is present, it MUST be a string in UTF-8 encoding (see [RFC3629]) in the Queen's English. 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | Error Code | | 2 | 10 | | +-------------------------------------------+ | | | Length | | | +-------------------------------------------+ | | | Length of Encapsulated PDU | | | +-------------------------------------------+ | | ~ Erroneous PDU ~ | | +-------------------------------------------+ | | | Length of Arbitrary Text | | | +-------------------------------------------+ | | | Arbitrary Text | ~ of ~ | Error Diagnostic Message | | | `-------------------------------------------' 5.12. ASPA PDU Bush & Austein Expires 18 December 2022 [Page 18] Internet-Draft RPKI-Router Protocol June 2022 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | zero | | 2 | 11 | | +-------------------------------------------+ | | | Length | | | +-------------------------------------------+ | | | | | Flags | AFI Flags| Provider AS Count | | | | | +-------------------------------------------+ | | | Customer Autonomous System Number | | | +-------------------------------------------+ | | ~ Provider Autonomous System Numbers ~ | | ~-------------------------------------------~ The ASPA PDU supports [I-D.ietf-sidrops-aspa-profile]. An ASPA PDU represents one single customer AS and its provider ASes for a particular Address Family. Receipt of an ASPA PDU announcement (announce/withdraw flag == 1) when the router already has an ASPA PDU with the same Customer Autonomous System Number and the same Address Family (see AFI Flags field), replaces the previous one. The cache MUST deliver the complete data of an ASPA record in a single ASPA PDU. The router MUST see at most one ASPA for a given AFI from a cache for a particular Customer Autonomous System Number active at any time. As a number of conditions in the global RPKI may present multiple valid ASPA RPKI records for a single customer to a particular RP cache, this places a burden on the cache to form the union of multiple ASPA records it has received from the global RPKI into one ASPA PDU. The Flags field is as described in Section 5. For the ASPA PDU, the announce/withdraw Flag is set to 1 to indicate either the announcement of a new ASPA record or a replacement for a previously announced record with the same Customer Autonomous System Number and AFI. Bush & Austein Expires 18 December 2022 [Page 19] Internet-Draft RPKI-Router Protocol June 2022 If the announce/withdraw flag is set to 0, it indicates removal of the entire ASPA record for the specified AFI and Customer AS. Here, the AFI and the customer AS of the ASPA record MUST be provided, the Provider AS Count must be zero, the Provider AS Numbers list MUST be null, and these last two fields MUST be ignored by the router. The AFI Flags field is defined in Section 15. The Provider AS Count is the number of 32-bit Provider Autonomous System Numbers in the PDU. The Customer Autonomous System Number is the 32-bit Autonomous System Number of the customer which authenticated the ASPA RPKI data. For a given AFI, there MUST be one and only one ASPA for a Customer Autonomous System Number active in the router at any time. There are zero or more 32-bit Provider Autonomous System Number fields as indicated in the Provider AS Count; see [I-D.ietf-sidrops-aspa-profile]. 6. Protocol Timing Parameters Since the data the cache distributes via the RPKI-Router protocol are retrieved from the Global RPKI system at intervals which are only known to the cache, only the cache can really know how frequently it makes sense for the router to poll the cache, or how long the data are likely to remain valid (or, at least, unchanged). For this reason, as well as to allow the cache some control over the load placed on it by its client routers, the End Of Data PDU includes three values that allow the cache to communicate timing parameters to the router: Refresh Interval: This parameter tells the router how long to wait before next attempting to poll the cache and between subsequent attempts, using a Serial Query or Reset Query PDU. The router SHOULD NOT poll the cache sooner than indicated by this parameter. Note that receipt of a Serial Notify PDU overrides this interval and suggests that the router issue an immediate query without waiting for the Refresh Interval to expire. Countdown for this timer starts upon receipt of the containing End Of Data PDU. Minimum allowed value: 1 second. Maximum allowed value: 86400 seconds (1 day). Recommended default: 3600 seconds (1 hour). Retry Interval: This parameter tells the router how long to wait Bush & Austein Expires 18 December 2022 [Page 20] Internet-Draft RPKI-Router Protocol June 2022 before retrying a failed Serial Query or Reset Query. The router SHOULD NOT retry sooner than indicated by this parameter. Note that a protocol version mismatch overrides this interval: if the router needs to downgrade to a lower protocol version number, it MAY send the first Serial Query or Reset Query immediately. Countdown for this timer starts upon failure of the query and restarts after each subsequent failure until a query succeeds. Minimum allowed value: 1 second. Maximum allowed value: 7200 seconds (2 hours). Recommended default: 600 seconds (10 minutes). Expire Interval: This parameter tells the router how long it can continue to use the current version of the data while unable to perform a successful subsequent query. The router MUST NOT retain the data past the time indicated by this parameter. Countdown for this timer starts upon receipt of the containing End Of Data PDU. Minimum allowed value: 600 seconds (10 minutes). Maximum allowed value: 172800 seconds (2 days). Recommended default: 7200 seconds (2 hours). If the router has never issued a successful query against a particular cache, it SHOULD retry periodically using the default Retry Interval, above. Caches MUST set Expire Interval to a value larger than both the Refresh Interval and the Retry Interval. 7. Protocol Version Negotiation A router MUST start each transport connection by issuing either a Reset Query or a Serial Query. This query MUST tell the cache the highest version of this protocol the router implements. If a cache which supports version N receives a Reset Query with Version Q < N, the cache MUST downgrade to protocol version Q [RFC6810] or [RFC8210]. If the router's Reset Request was Q > N, the cache MUST send a version 2 Error Report PDU with Error Code 4 ("Unsupported Protocol Version"), and the router MUST send another Reset Query with a lower Version Q. Yjis MAY repeat. If the router requests Q == 0 and it still fails, then the router MUST abort the session, sending a version 2 Error Report PDU with Error Code 4 ("Unsupported Protocol Version"). Bush & Austein Expires 18 December 2022 [Page 21] Internet-Draft RPKI-Router Protocol June 2022 If a router which supports version N sends a query to a cache which only supports version C < N, one of two things will happen: 1. The cache may terminate the connection, perhaps with a version 2 Error Report PDU with Error Code 4 ("Unsupported Protocol Version"). In this case, the router MAY retry the connection using protocol version C. 2. The cache may reply with a version C response. In this case, the router MUST either downgrade to version C or terminate the connection. In any of the downgraded combinations above, the new features of the higher version will not be available, and all PDUs MUST have the negotiated lower version number in their version fields. If either party receives a PDU containing an unrecognized Protocol Version (neither 0, 1, nor 2) during this negotiation, it MUST either downgrade to a known version or terminate the connection, with an Error Report PDU unless the received PDU is itself an Error Report PDU. The router MUST ignore any Serial Notify PDUs it might receive from the cache during this initial startup period, regardless of the Protocol Version field in the Serial Notify PDU. Since Session ID and Serial Number values are specific to a particular protocol version, the values in the notification are not useful to the router. Even if these values were meaningful, the only effect that processing the notification would have would be to trigger exactly the same Reset Query or Serial Query that the router has already sent as part of the not-yet-complete version negotiation process, so there is nothing to be gained by processing notifications until version negotiation completes. Caches SHOULD NOT send Serial Notify PDUs before version negotiation completes. Routers, however, MUST handle such notifications (by ignoring them) for backwards compatibility with caches serving protocol version 0. Once the cache and router have agreed upon a Protocol Version via the negotiation process above, that version is stable for the life of the session. See Section 5.1 for a discussion of the interaction between Protocol Version and Session ID. Bush & Austein Expires 18 December 2022 [Page 22] Internet-Draft RPKI-Router Protocol June 2022 If either party receives a PDU for a different Protocol Version once the above negotiation completes, that party MUST drop the session; unless the PDU containing the unexpected Protocol Version was itself an Error Report PDU, the party dropping the session SHOULD send an Error Report with an error code of 8 ("Unexpected Protocol Version"). 8. Protocol Sequences The sequences of PDU transmissions fall into four conversations as follows: 8.1. Start or Restart Cache Router ~ ~ | <----- Reset Query -------- | R requests data (or Serial Query) | | | ----- Cache Response -----> | C confirms request | ------- Payload PDU ------> | C sends zero or more | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | ------- Payload PDU ------> | ASPA, or Router Key PDUs | ------- End of Data ------> | C sends End of Data | | and sends new serial ~ ~ When a transport connection is first established, the router MUST send either a Reset Query or a Serial Query. A Serial Query would be appropriate if the router has unexpired data from a broken session with the same cache and remembers the Session ID of that session, in which case a Serial Query containing the Session ID from the previous session will allow the router to bring itself up to date while ensuring that the Serial Numbers are commensurate and that the router and cache are speaking compatible versions of the protocol. In all other cases, the router lacks the necessary data for fast resynchronization and therefore MUST fall back to a Reset Query. The Reset Query sequence is also used when the router receives a Cache Reset, chooses a new cache, or fears that it has otherwise lost its way. See Section 7 for details on version negotiation. To limit the length of time a cache must keep the data necessary to generate incremental updates, a router MUST send either a Serial Query or a Reset Query periodically. This also acts as a keep-alive at the application layer. See Section 6 for details on the required polling frequency. Bush & Austein Expires 18 December 2022 [Page 23] Internet-Draft RPKI-Router Protocol June 2022 8.2. Typical Exchange Cache Router ~ ~ | -------- Notify ----------> | (optional) | | | <----- Serial Query ------- | R requests data | | | ----- Cache Response -----> | C confirms request | ------- Payload PDU ------> | C sends zero or more | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | ------- Payload PDU ------> | ASPA. or Router Key PDUs | ------- End of Data ------> | C sends End of Data | | and sends new serial ~ ~ The cache server SHOULD send a Notify PDU with its current Serial Number when the cache's serial changes, with the expectation that the router MAY then issue a Serial Query earlier than it otherwise might. This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST rate- limit Serial Notifies to no more frequently than one per minute. When the transport layer is up and either a timer has gone off in the router or the cache has sent a Notify PDU, the router queries for new data by sending a Serial Query, and the cache sends all data newer than the serial in the Serial Query. To limit the length of time a cache must keep old withdraws, a router MUST send either a Serial Query or a Reset Query periodically. See Section 6 for details on the required polling frequency. 8.3. No Incremental Update Available Cache Router ~ ~ | <------ Serial Query ------ | R requests data | ------- Cache Reset ------> | C cannot supply update | | from specified serial | <------ Reset Query ------- | R requests new data | ----- Cache Response -----> | C confirms request | ------- Payload PDU ------> | C sends zero or more | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | ------- Payload PDU ------> | ASPA, or Router Key PDUs | ------- End of Data ------> | C sends End of Data | | and sends new serial ~ ~ Bush & Austein Expires 18 December 2022 [Page 24] Internet-Draft RPKI-Router Protocol June 2022 The cache may respond to a Serial Query with a Cache Reset, informing the router that the cache cannot supply an incremental update from the Serial Number specified by the router. This might be because the cache has lost state, or because the router has waited too long between polls and the cache has cleaned up old data that it no longer believes it needs, or because the cache has run out of storage space and had to expire some old data early. Regardless of how this state arose, the cache replies with a Cache Reset to tell the router that it cannot honor the request. When a router receives this, the router SHOULD attempt to connect to any more-preferred caches in its cache list. If there are no more-preferred caches, it MUST issue a Reset Query and get an entire new load from the cache. 8.4. Cache Has No Data Available Cache Router ~ ~ | <------ Serial Query ------ | R requests data | ---- Error Report PDU ----> | C No Data Available ~ ~ Cache Router ~ ~ | <------ Reset Query ------- | R requests data | ---- Error Report PDU ----> | C No Data Available ~ ~ The cache may respond to either a Serial Query or a Reset Query informing the router that the cache cannot supply any update at all. The most likely cause is that the cache has lost state, perhaps due to a restart, and has not yet recovered. While it is possible that a cache might go into such a state without dropping any of its active sessions, a router is more likely to see this behavior when it initially connects and issues a Reset Query while the cache is still rebuilding its database. When a router receives this kind of error, the router SHOULD attempt to connect to any other caches in its cache list, in preference order. If no other caches are available, the router MUST issue periodic Reset Queries until it gets a new usable load from the cache; maybe once a minute so as not to DoS the cache. 9. Transport The transport-layer session between a router and a cache carries the binary PDUs in a persistent session. Bush & Austein Expires 18 December 2022 [Page 25] Internet-Draft RPKI-Router Protocol June 2022 To prevent cache spoofing and DoS attacks by illegitimate routers, it is highly desirable that the router and the cache be authenticated to each other. Integrity protection for payloads is also desirable to protect against monkey-in-the-middle (MITM) attacks. Unfortunately, there is no protocol to do so on all currently used platforms. Therefore, as of the writing of this document, there is no mandatory- to-implement transport which provides authentication and integrity protection. To reduce exposure to dropped but non-terminated sessions, both caches and routers SHOULD enable keep-alives when available in the chosen transport protocol. It is expected that, when the TCP Authentication Option (TCP-AO) [RFC5925] is available on all platforms deployed by operators, it will become the mandatory-to-implement transport. Caches and routers MUST implement unprotected transport over TCP using a port, rpki-rtr (323); see Section 15. Operators SHOULD use procedural means, e.g., access control lists (ACLs), to reduce the exposure to authentication issues. If unprotected TCP is the transport, the cache and routers MUST be on the same trusted and controlled network. If available to the operator, caches and routers MUST use one of the following more protected protocols: * Caches and routers SHOULD use TCP-AO transport [RFC5925] over the rpki-rtr port. * Caches and routers MAY use Secure Shell version 2 (SSHv2) transport [RFC4252] using the normal SSH port. For an example, see Section 9.1. * Caches and routers MAY use TCP MD5 transport [RFC2385] using the rpki-rtr port if no other protected transport is available. Note that TCP MD5 has been obsoleted by TCP-AO [RFC5925]. * Caches and routers MAY use TCP over IPsec transport [RFC4301] using the rpki-rtr port. * Caches and routers MAY use Transport Layer Security (TLS) transport [RFC8446] using port rpki-rtr-tls (324); see Section 15. Conformance to [RFC7525] modern cipher suites is REQUIRED. Bush & Austein Expires 18 December 2022 [Page 26] Internet-Draft RPKI-Router Protocol June 2022 9.1. SSH Transport To run over SSH, the client router first establishes an SSH transport connection using the SSHv2 transport protocol, and the client and server exchange keys for message integrity and encryption. The client then invokes the "ssh-userauth" service to authenticate the application, as described in the SSH authentication protocol [RFC4252]. Once the application has been successfully authenticated, the client invokes the "ssh-connection" service, also known as the SSH connection protocol. After the ssh-connection service is established, the client opens a channel of type "session", which results in an SSH session. Once the SSH session has been established, the application invokes the application transport as an SSH subsystem called "rpki-rtr". Subsystem support is a feature of SSHv2 and is not included in SSHv1. Running this protocol as an SSH subsystem avoids the need for the application to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell startup. It is assumed that the router and cache have exchanged keys out of band by some reasonably secured means. Cache servers supporting SSH transport MUST accept RSA authentication and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA) authentication. User authentication "publickey") MUST be supported; host authentication "hostbased") MAY be supported. Implementations MAY support password authentication "password"). "None" authentication MUST NOT be used. Client routers SHOULD verify the public key of the cache to avoid MITM attacks. 9.2. TLS Transport Client routers using TLS transport MUST present client-side certificates to authenticate themselves to the cache in order to allow the cache to manage the load by rejecting connections from unauthorized routers. In principle, any type of certificate and Certification Authority (CA) may be used; however, in general, cache operators will wish to create their own small-scale CA and issue certificates to each authorized router. This simplifies credential rollover; any unrevoked, unexpired certificate from the proper CA may be used. Bush & Austein Expires 18 December 2022 [Page 27] Internet-Draft RPKI-Router Protocol June 2022 Certificates used to authenticate client routers in this protocol MUST include a subjectAltName extension [RFC5280] containing one or more iPAddress identities; when authenticating the router's certificate, the cache MUST check the IP address of the TLS connection against these iPAddress identities and SHOULD reject the connection if none of the iPAddress identities match the connection. Routers MUST also verify the cache's TLS server certificate, using subjectAltName dNSName identities as described in [RFC6125], to avoid MITM attacks. The rules and guidelines defined in [RFC6125] apply here, with the following considerations: * Support for the DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED in rpki-rtr server and client implementations which use TLS. Certification authorities which issue rpki-rtr server certificates MUST support the DNS-ID identifier type, and the DNS-ID identifier type MUST be present in rpki-rtr server certificates. * DNS names in rpki-rtr server certificates SHOULD NOT contain the wildcard character "*". * rpki-rtr implementations which use TLS MUST NOT use Common Name (CN-ID) identifiers; a CN field may be present in the server certificate's subject name but MUST NOT be used for authentication within the rules described in [RFC6125]. * The client router MUST set its "reference identifier" (see Section 6.2 of [RFC6125]) to the DNS name of the rpki-rtr cache. 9.3. TCP MD5 Transport If TCP MD5 is used, implementations MUST support key lengths of at least 80 printable ASCII bytes, per Section 4.5 of [RFC2385]. Implementations MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits. Key rollover with TCP MD5 is problematic. Cache servers SHOULD support [RFC4808]. 9.4. TCP-AO Transport Implementations MUST support key lengths of at least 80 printable ASCII bytes. Implementations MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits. Message Authentication Code (MAC) lengths of at least 96 bits MUST be supported, per Section 5.1 of [RFC5925]. Bush & Austein Expires 18 December 2022 [Page 28] Internet-Draft RPKI-Router Protocol June 2022 The cryptographic algorithms and associated parameters described in [RFC5926] MUST be supported. 10. Router-Cache Setup A cache has the public authentication data for each router it is configured to support. A router may be configured to peer with a selection of caches, and a cache may be configured to support a selection of routers. Each must have the name of, and authentication data for, each peer. In addition, in a router, this list has a non-unique preference value for each cache. This preference is intended to be based on proximity, a la RTT, not trust, preferred belief, et cetera. The client router attempts to establish a session with each potential serving cache in preference order and then starts to load data from the most preferred cache to which it can connect and authenticate. The router's list of caches has the following elements: Preference: An unsigned integer denoting the router's preference to connect to that cache; the lower the value, the more preferred. Name: The IP address or fully qualified domain name of the cache. Cache Credential(s): Any credential (such as a public key) needed to authenticate the cache's identity to the router. Router Credential(s): Any credential (such as a private key or certificate) needed to authenticate the router's identity to the cache. Due to the distributed nature of the RPKI, caches simply cannot be rigorously synchronous. A client may hold data from multiple caches but MUST keep the data marked as to source, as later updates MUST affect the correct data. Just as there may be more than one covering ROA from a single cache, there may be multiple covering ROAs from multiple caches. The results are as described in [RFC6811]. If data from multiple caches are held, implementations MUST NOT distinguish between data sources when performing validation of BGP announcements. When a more-preferred cache becomes available, if resources allow, it would be prudent for the client to start fetching from that cache. Bush & Austein Expires 18 December 2022 [Page 29] Internet-Draft RPKI-Router Protocol June 2022 The client SHOULD attempt to maintain at least one set of data, regardless of whether it has chosen a different cache or established a new connection to the previous cache. A client MAY drop the data from a particular cache when it is fully in sync with one or more other caches. See Section 6 for details on what to do when the client is not able to refresh from a particular cache. If a client loses connectivity to a cache it is using or otherwise decides to switch to a new cache, it SHOULD retain the data from the previous cache until it has a full set of data from one or more other caches. Note that this may already be true at the point of connection loss if the client has connections to more than one cache. 11. ROA PDU Race Minimization When a cache is sending ROA (IPv4 or IPv6) PDUs to a router, especially an initial full load in response to a Reset Query PDU, two undesirable race conditions are possible: Break Before Make: For some prefix P, an AS may announce two (or more) ROAs because they are in the process of changing what provider AS is announcing P. This is a case of "make before break." If a cache is feeding a router and sends the one not yet in service a significant time before sending the one currently in service, then BGP data could be marked invalid during the interval. To minimize that interval, the cache SHOULD announce all ROAs for the same prefix as close to sequentially as possible. Shorter Prefix First: If an AS has issued a ROA for P0, and another AS (likely their customer) has issued a ROA for P1 which is a sub- prefix of P0, a router which receives the ROA for P0 before that for P1 is likely to mark a BGP prefix P1 invalid. Therefore, the cache SHOULD announce the sub-prefix P1 before the covering prefix P0. 12. Deployment Scenarios For illustration, we present three likely deployment scenarios: Small End Site: The small multihomed end site may wish to outsource Bush & Austein Expires 18 December 2022 [Page 30] Internet-Draft RPKI-Router Protocol June 2022 the RPKI cache to one or more of their upstream ISPs. They would exchange authentication material with the ISP using some out-of- band mechanism, and their router(s) would connect to the cache(s) of one or more upstream ISPs. The ISPs would likely deploy caches intended for customer use separately from the caches with which their own BGP speakers peer. Large End Site: A larger multihomed end site might run one or more caches, arranging them in a hierarchy of client caches, each fetching from a serving cache which is closer to the Global RPKI. They might configure fallback peerings to upstream ISP caches. ISP Backbone: A large ISP would likely have one or more redundant caches in each major point of presence (PoP), and these caches would fetch from each other in an ISP-dependent topology so as not to place undue load on the Global RPKI. Experience with large DNS cache deployments has shown that complex topologies are ill-advised, as it is easy to make errors in the graph, e.g., not maintain a loop-free condition. Of course, these are illustrations, and there are other possible deployment strategies. It is expected that minimizing load on the Global RPKI servers will be a major consideration. To keep load on Global RPKI services from unnecessary peaks, it is recommended that caches which fetch from the Global RPKI not do so all at the same times, e.g., on the hour. Choose a random time, perhaps the ISP's AS number modulo 60, and jitter the inter-fetch timing. 13. Error Codes This section describes the meaning of the error codes. There is an IANA registry where valid error codes are listed; see [iana-err]. Errors which are considered fatal MUST cause the session to be dropped. 0: Corrupt Data (fatal): The receiver believes the received PDU to be corrupt in a manner not specified by another error code. 1: Internal Error (fatal): The party reporting the error experienced some kind of internal error unrelated to protocol operation (ran out of memory, a coding assertion failed, et cetera). 2: No Data Available: The cache believes itself to be in good Bush & Austein Expires 18 December 2022 [Page 31] Internet-Draft RPKI-Router Protocol June 2022 working order but is unable to answer either a Serial Query or a Reset Query because it has no useful data available at this time. This is likely to be a temporary error and most likely indicates that the cache has not yet completed pulling down an initial current data set from the Global RPKI system after some kind of event that invalidated whatever data it might have previously held (reboot, network partition, et cetera). 3: Invalid Request (fatal): The cache server believes the client's request to be invalid. 4: Unsupported Protocol Version (fatal): The Protocol Version is not known by the receiver of the PDU. 5: Unsupported PDU Type (fatal): The PDU Type is not known by the receiver of the PDU. 6: Withdrawal of Unknown Record (fatal): The received PDU has Flag=0, but a matching record ({Prefix, Len, Max-Len, ASN} tuple for an IPvX PDU, or {SKI, ASN, Subject Public Key} tuple for a Router Key PDU), or Customer Autonomous System for an ASPA PDU does not exist in the receiver's database. 7: Duplicate Announcement Received (fatal): The received PDU has Flag=1, but a matching record ({Prefix, Len, Max-Len, ASN} tuple for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a Router Key PDU), or Customer Autonomous System for an ASPA PDU is already active in the router. 8: Unexpected Protocol Version (fatal): The received PDU has a Protocol Version field that differs from the protocol version negotiated in Section 7. 14. Security Considerations As this document describes a security protocol, many aspects of security interest are described in the relevant sections. This section points out issues which may not be obvious in other sections. Cache Validation: In order for a collection of caches as described in Section 12 to provide a consistent view, they need to be given consistent trust anchors of the Certification Authorities to use in their internal validation process. Distribution of a consistent trust anchor set to validating caches is assumed to be out of band. Cache Peer Identification: The router initiates a transport Bush & Austein Expires 18 December 2022 [Page 32] Internet-Draft RPKI-Router Protocol June 2022 connection to a cache, which it identifies by either IP address or fully qualified domain name. Be aware that a DNS or address spoofing attack could make the correct cache unreachable. No session would be established, as the authorization keys would not match. Transport Security: The RPKI relies on object, not server or transport, trust. That is, the IANA root trust anchor is distributed to all caches through some out-of-band means and can then be used by each cache to validate certificates and ROAs all the way down the tree. The inter-cache relationships are based on this object security model; hence, the inter-cache transport can be lightly protected. However, this protocol document assumes that the routers cannot do the validation cryptography. Hence, the last link, from cache to router, SHOULD be secured by server authentication and transport- level security to prevent monkey in the middle attacks; though it might not be. Not using transport security is dangerous, as server authentication and transport have very different threat models than object security. So the strength of the trust relationship and the transport between the router(s) and the cache(s) are critical. You're betting your routing on this. While we cannot say the cache must be on the same LAN, if only due to the issue of an enterprise wanting to offload the cache task to their upstream ISP(s), locality, trust, and control are very critical issues here. The cache(s) really SHOULD be as close, in the sense of controlled and protected (against DDoS, MITM) transport, to the router(s) as possible. It also SHOULD be topologically close so that a minimum of validated routing data are needed to bootstrap a router's access to a cache. Authenticating transport protocols (i.e. not raw TCP) will authenticate the identity of the cache server to the router client, and vice versa, before any data are exchanged. Transports which cannot provide the necessary authentication and integrity (see Section 9) must rely on network design and operational controls to provide protection against spoofing/ corruption attacks. As pointed out in Section 9, TCP-AO is the long-term plan. Protocols which provide integrity and authenticity SHOULD be used, and if they cannot, i.e., TCP is used as the transport, the router and cache MUST be on the same trusted, controlled network. Bush & Austein Expires 18 December 2022 [Page 33] Internet-Draft RPKI-Router Protocol June 2022 15. IANA Considerations This section only discusses updates required in the existing IANA protocol registries to accommodate version 2 of this protocol. See [RFC8210] for IANA considerations of the previous (version 1) protocol. All of the PDU types in the IANA "rpki-rtr-pdu" registry [iana-pdu] in protocol versions 0 and 1 are also allowed in protocol version 2, with the addition of the new ASPA PDU. The "rpki-rtr-pdu" registry [iana-pdu] has been updated as follows: Protocol PDU Version Type Description -------- ---- --------------- 0-2 0 Serial Notify 0-2 1 Serial Query 0-2 2 Reset Query 0-2 3 Cache Response 0-2 4 IPv4 Prefix 0-2 6 IPv6 Prefix 0-2 7 End of Data 0-2 8 Cache Reset 0 9 Reserved 1-2 9 Router Key 0-2 10 Error Report 0-1 11 Reserved 2 11 ASPA 0-2 255 Reserved This document requests the IANA to create a registry for ASPA AFI Flags 0 to 7. The name of the registry should be rpki-rtr-afi. The policy for adding to the registry is Expert Review per [RFC8126], where the responsible IESG area director should appoint the Expert Reviewer. The initial entries should be as follows: Bit Bit Name ---- ------------------- 0 AFI (IPv4 == 0, IPv6 == 1) 1-7 Reserved, MUST be zero 16. References 16.1. Normative References Bush & Austein Expires 18 December 2022 [Page 34] Internet-Draft RPKI-Router Protocol June 2022 [I-D.ietf-sidrops-aspa-profile] Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., and R. Housley, "A Profile for Autonomous System Provider Authorization", Work in Progress, Internet-Draft, draft- ietf-sidrops-aspa-profile-07, 31 January 2022, . [iana-err] IANA, "rpki-rtr-error", . [iana-pdu] IANA, "rpki-rtr-pdu", . [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1998, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . Bush & Austein Expires 18 December 2022 [Page 35] Internet-Draft RPKI-Router Protocol June 2022 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, DOI 10.17487/RFC5926, June 2010, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, . [RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, . Bush & Austein Expires 18 December 2022 [Page 36] Internet-Draft RPKI-Router Protocol June 2022 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8608, DOI 10.17487/RFC8608, June 2019, . [RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, . 16.2. Informative References [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, . [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, DOI 10.17487/RFC4808, March 2007, . [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, . Acknowledgements The authors wish to thank Nils Bars, Steve Bellovin, Oliver Borchert, Mohamed Boucadair, Tim Bruijnzeels, Roman Danyliw, Rex Fernando, Richard Hansen, Martin Hoffmann, Paul Hoffman, Fabian Holler, Russ Housley, Pradosh Mohapatra, Keyur Patel, David Mandelberg, Sandy Murphy, Robert Raszuk, Andreas Reuter, Thomas Schmidt, John Scudder, Ruediger Volk, Matthias Waehlisch, and David Ward. Particular thanks go to Hannes Gredler for showing us the dangers of unnecessary fields. Bush & Austein Expires 18 December 2022 [Page 37] Internet-Draft RPKI-Router Protocol June 2022 No doubt this list is incomplete. We apologize to any contributor whose name we missed. Authors' Addresses Randy Bush IIJ, Arrcus, & DRL 5147 Crystal Springs Bainbridge Island, Washington 98110 United States of America Email: randy@psg.com Rob Austein Dragon Research Labs Email: sra@hactrn.net Bush & Austein Expires 18 December 2022 [Page 38] ./draft-ietf-add-dnr-13.txt0000644000764400076440000016251414276101252015172 0ustar iustiniustin ADD M. Boucadair, Ed. Internet-Draft Orange Intended status: Standards Track T. Reddy, Ed. Expires: 14 February 2023 Nokia D. Wing Citrix N. Cook Open-Xchange T. Jensen Microsoft 13 August 2022 DHCP and Router Advertisement Options for the Discovery of Network- designated Resolvers (DNR) draft-ietf-add-dnr-13 Abstract The document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over- TLS, DNS-over-QUIC). Particularly, it allows a host to learn an authentication domain name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 February 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Boucadair, et al. Expires 14 February 2023 [Page 1] Internet-Draft Discovery of Network-designated Resolver August 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Configuration Data for Encrypted DNS . . . . . . . . . . 4 3.1.1. ADN as the Reference Identifier for DNS Authentication . . . . . . . . . . . . . . . . . . . 4 3.1.2. Avoiding Dependency on External Resolvers . . . . . . 4 3.1.3. Single vs. Multiple IP Addresses . . . . . . . . . . 5 3.1.4. Why Not Separate Options for ADN and IP Addresses? . 5 3.1.5. Service Parameters . . . . . . . . . . . . . . . . . 5 3.1.6. ADN Only Mode . . . . . . . . . . . . . . . . . . . . 6 3.1.7. Encrypted DNS Options Ordering . . . . . . . . . . . 6 3.1.8. DNR Validation Checks . . . . . . . . . . . . . . . . 7 3.1.9. DNR Information Using Other Provisioning Mechanisms . . . . . . . . . . . . . . . . . . . . . 7 3.2. Handling Configuration Data Conflicts . . . . . . . . . . 8 3.3. Validating Discovered Resolvers . . . . . . . . . . . . . 8 3.4. Multihoming Considerations . . . . . . . . . . . . . . . 9 4. DHCPv6 Encrypted DNS Option . . . . . . . . . . . . . . . . . 9 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 9 4.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 11 5. DHCPv4 Encrypted DNS Option . . . . . . . . . . . . . . . . . 11 5.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 11 5.2. DHCPv4 Client Behavior . . . . . . . . . . . . . . . . . 14 6. IPv6 RA Encrypted DNS Option . . . . . . . . . . . . . . . . 14 6.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 14 6.2. IPv6 Host Behavior . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7.1. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . 17 7.2. Deletion Attacks . . . . . . . . . . . . . . . . . . . . 18 7.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 18 7.4. Wireless Security - Authentication Attacks . . . . . . . 18 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9.1. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 19 9.2. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . . 20 9.3. Neighbor Discovery Option . . . . . . . . . . . . . . . . 20 Boucadair, et al. Expires 14 February 2023 [Page 2] Internet-Draft Discovery of Network-designated Resolver August 2022 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction This document focuses on the discovery of encrypted DNS such as DNS- over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS- over-QUIC (DoQ) [RFC9250] in local networks. In particular, the document specifies how a local encrypted DNS resolver can be discovered by connected hosts by means of DHCPv4 [RFC2132], DHCPv6 [RFC8415], and IPv6 Router Advertisement (RA) [RFC4861] options. These options are designed to convey the following information: the DNS Authentication Domain Name (ADN), a list of IP addresses, and a set of service parameters. This procedure is called Discovery of Network-designated Resolvers (DNR). The options defined in this document can be deployed in a variety of deployments (e.g., local networks with Customer Premises Equipment (CPEs) that may or may not be managed by an Internet Service Provider (ISP), or local networks with or without DNS forwarders). It is out of the scope of this document to provide an inventory of such deployments. Resolver selection considerations are out of scope. Likewise, policies (including any interactions with users) are out of scope. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in [RFC8499]. The following additional terms are used: Do53: refers to unencrypted DNS. DNR: refers to the Discovery of Network-designated Resolvers procedure. Encrypted DNS: refers to a scheme where DNS exchanges are Boucadair, et al. Expires 14 February 2023 [Page 3] Internet-Draft Discovery of Network-designated Resolver August 2022 transported over an encrypted channel. Examples of encrypted DNS are DoT, DoH, or DoQ. Encrypted DNS resolver: refers to a DNS resolver that supports any encrypted DNS scheme. Encrypted DNS options: refers to the options defined in Sections 4, 5, and 6. DHCP: refers to both DHCPv4 and DHCPv6. 3. Overview This document describes how a DNS client can discover local encrypted DNS resolvers using DHCP (Sections 4 and 5) and Neighbor Discovery protocol (Section 6): Encrypted DNS options. These options configure an authentication domain name, a list of IP addresses, and a set of service parameters of the encrypted DNS resolver. More information about the design of these options is provided in the following subsections. 3.1. Configuration Data for Encrypted DNS 3.1.1. ADN as the Reference Identifier for DNS Authentication In order to allow for PKIX-based authentication between a DNS client and an encrypted DNS resolver, the Encrypted DNS options are designed to always include an authentication domain name. This ADN is presented as a reference identifier for DNS authentication purposes. This design accommodates the current best practices for issuing certificates as per Section 1.7.2 of [RFC6125]: | Some certification authorities issue server certificates based | on IP addresses, but preliminary evidence indicates that such | certificates are a very small percentage (less than 1%) of | issued certificates. 3.1.2. Avoiding Dependency on External Resolvers To avoid adding a dependency on another server to resolve the ADN, the Encrypted DNS options return the IP address(es) to locate the encrypted DNS resolver. These encrypted DNS resolvers may be hosted on the same or distinct IP addresses. Such a decision is deployment specific. Boucadair, et al. Expires 14 February 2023 [Page 4] Internet-Draft Discovery of Network-designated Resolver August 2022 In order to optimize the size of discovery messages when all DNS resolvers terminate on the same IP address, early versions of this document considered relying upon the discovery mechanisms specified in [RFC2132][RFC3646][RFC8106] to retrieve a list of IP addresses to reach their DNS resolvers. Nevertheless, this approach requires a client that supports more than one encrypted DNS protocol (e.g., DoH and DoT) to probe that list of IP addresses. To avoid such a probing, the options defined in Sections 4, 5, and 6 associate an encrypted DNS protocol with an IP address. No probing is required in such a design. 3.1.3. Single vs. Multiple IP Addresses A list of IP addresses to reach an encrypted DNS resolver may be returned in an Encrypted DNS option to accommodate current deployments relying upon primary and backup resolvers. Also, DNR can be used in contexts where other DNS redundancy schemes (e.g., anycast as in BCP 126 [RFC4786]) are used. Whether one or more IP addresses are returned in an Encrypted DNS option is deployment specific. For example, a router embedding a recursive server or a forwarder has to include one single IP address pointing to one of its LAN-facing interfaces. Typically, this IP address can be a private IPv4 address, a link-local address, a Unique Local IPv6 unicast Address (ULA), or a Global Unicast Address (GUA). If multiple IP addresses are to be returned in an Encrypted DNS option, these addresses are ordered in the preference for use by the client. 3.1.4. Why Not Separate Options for ADN and IP Addresses? A single option is used to convey both the ADN and IP addresses. Otherwise a means to correlate an IP address conveyed in an option with an ADN conveyed in another option will be required if, for example, more than one ADN is supported by the network. 3.1.5. Service Parameters Because distinct encrypted DNS protocols (e.g., DoT, DoH, and DoQ) may be provisioned by a network and that some of these protocols may make use of customized port numbers instead of default ones, the Encrypted DNS options are designed to return a set of service parameters. These parameters are encoded following the same rules for encoding SvcParams in Section 2.1 of [I-D.ietf-dnsop-svcb-https]. This encoding approach may increase the size of the options but it has the merit of relying upon an existing IANA registry and, thus, accommodating new encrypted DNS protocols and service parameters that Boucadair, et al. Expires 14 February 2023 [Page 5] Internet-Draft Discovery of Network-designated Resolver August 2022 may be defined in the future. The following service parameters MUST be supported by a DNR implementation: alpn: Used to indicate the set of supported protocols (Section 7.1 of [I-D.ietf-dnsop-svcb-https]). port: Used to indicate the target port number for the encrypted DNS connection (Section 7.2 of [I-D.ietf-dnsop-svcb-https]). In addition, the following service parameters are RECOMMENDED to be supported by a DNR implementation: ech: Used to enable Encrypted ClientHello (ECH) (Section 7.3 of [I-D.ietf-dnsop-svcb-https]). dohpath: Used to supply a relative DoH URI Template (Section 5.1 of [I-D.ietf-add-svcb-dns]). 3.1.6. ADN Only Mode The provisioning mode in which an ADN, a list of IP addresses, and a set of service parameters of the encrypted DNS resolver are supplied to a host SHOULD be used because the Encrypted DNS options are self- contained and do not require any additional DNS queries. The reader may refer to [RFC7969] for an overview of advanced capabilities that are supported by DHCP servers to populate configuration data (e.g., issue DNS queries). In contexts where putting additional complexity on requesting hosts is acceptable, returning an ADN only can be considered. The supplied ADN will be passed to a local resolution library (a DNS client, typically) which will then issue Service Binding (SVCB) queries [I-D.ietf-add-svcb-dns]. These SVCB queries can be sent to the discovered encrypted DNS resolver itself or to the network-designated Do53 resolver. Note that this mode may be subject to active attacks, which can be mitigated by DNSSEC. | How an ADN is passed to a local resolution library is | implementation specific. 3.1.7. Encrypted DNS Options Ordering The DHCP options defined in Sections 4 and 5 follow the option ordering guidelines in Section 17 of [RFC7227]. Boucadair, et al. Expires 14 February 2023 [Page 6] Internet-Draft Discovery of Network-designated Resolver August 2022 Likewise, the RA option (Section 6) adheres to the recommendations in Section 9 of [RFC4861]. 3.1.8. DNR Validation Checks On receipt of an Encrypted DNS option, the DHCP client (or IPv6 host) makes the following validation checks: * The ADN is present and encoded as per Section 10 of [RFC8415]. * If additional data is supplied: - the service parameters are encoded following the rules specified in Section 2.1 of [I-D.ietf-dnsop-svcb-https]. - the option includes at least one valid IP address and the "alpn" service parameter. - the service parameters do not include "ipv4hint" or "ipv6hint" service parameters. If any of the checks fail, the receiver discards the received Encrypted DNS option. 3.1.9. DNR Information Using Other Provisioning Mechanisms The provisioning mechanisms specified in this document may not be available in specific networks (e.g., some cellular networks exclusively use Protocol Configuration Options (PCOs) [TS.24008]) or may not be suitable in some contexts (e.g., need for a secure discovery). Other mechanisms may be considered in these contexts for the provisioning of encrypted DNS resolvers. It is RECOMMENDED that at least the following DNR information is made available to a requesting host: * A service priority whenever the discovery mechanism does not rely on implicit ordering if multiple instances of the encrypted DNS are used. * An authentication domain name. This parameter is mandatory. * A list of IP addresses to locate the encrypted DNS resolver. * A set of service parameters. Boucadair, et al. Expires 14 February 2023 [Page 7] Internet-Draft Discovery of Network-designated Resolver August 2022 3.2. Handling Configuration Data Conflicts If the encrypted DNS is discovered by a host using both RA and DHCP, the rules discussed in Section 5.3.1 of [RFC8106] MUST be followed. DHCP/RA options to discover encrypted DNS resolvers (including, DoH URI Templates) takes precedence over Discovery of Designated Resolvers (DDR) [I-D.ietf-add-ddr] since DDR uses Do53 to an external DNS resolver, which is susceptible to both internal and external attacks whereas DHCP/RA is typically protected using the mechanisms discussed in Section 7.1. If a client learns both Do53 and encrypted DNS resolvers from the same network, and absent explicit configuration otherwise, it is RECOMMENDED that the client uses the encrypted DNS resolvers for that network. If the client cannot establish an authenticated and encrypted connection with the encrypted DNS resolver, it may fallback to using the Do53 resolver. 3.3. Validating Discovered Resolvers This section describes a set of validation checks to confirm that an encrypted DNS resolver matches what is provided using DNR (e.g., DHCP or RA). Such validation checks do not intend to validate the security of the DNR provisioning mechanisms or the user's trust relationship to the network. If the local DNS client supports one of the discovered encrypted DNS protocols identified by Application Layer Protocol Negotiation (ALPN) protocol identifiers, the DNS client establishes an encrypted DNS session following the service priority of the discovered encrypted resolvers. The DNS client verifies the connection based on PKIX validation [RFC5280] of the DNS resolver certificate and uses the validation techniques as described in [RFC6125] to compare the authentication domain name conveyed in the Encrypted DNS options to the certificate provided (see Section 8.1 of [RFC8310] for more details). The DNS client uses the default system or application PKI trust anchors unless configured otherwise to use explicit trust anchors. ALPN- related considerations can be found in Section 6.1 of [I-D.ietf-dnsop-svcb-https]. Operation considerations to check the revocation status of the certificate of an encrypted DNS resolver are discussed in Section 10 of [RFC8484]. Boucadair, et al. Expires 14 February 2023 [Page 8] Internet-Draft Discovery of Network-designated Resolver August 2022 3.4. Multihoming Considerations Devices may be connected to multiple networks; each providing their own DNS configuration using the discovery mechanisms specified in this document. Nevertheless, it is out of the scope of this specification to discuss DNS selection of multi-interface devices. The reader may refer to [RFC6731] for a discussion of issues and an example of DNS resolver selection for multi-interfaced devices. Also, the reader may refer to [I-D.ietf-add-split-horizon-authority] for a discussion on how DNR and Provisioning Domains (PvDs) Key "dnsZones" (Section 4.3 of [RFC8801]) can be used in Split DNS environments (Section 6 of [RFC8499]). 4. DHCPv6 Encrypted DNS Option 4.1. Option Format The format of the DHCPv6 Encrypted DNS option is shown in Figure 1. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_V6_DNR | Option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Priority | ADN Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ authentication-domain-name ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ipv6-address(es) ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ Service Parameters (SvcParams) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: DHCPv6 Encrypted DNS Option The fields of the option shown in Figure 1 are as follows: Option-code: OPTION_V6_DNR (TBA1, see Section 9.1) Option-length: Length of the enclosed data in octets. The option length is ('ADN Length' + 4) when only an ADN is included in the option. Service Priority: The priority of this OPTION_V6_DNR instance Boucadair, et al. Expires 14 February 2023 [Page 9] Internet-Draft Discovery of Network-designated Resolver August 2022 compared to other instances. This 16-bit unsigned integer is interpreted following the rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https]. ADN Length: Length of the authentication-domain-name field in octets. authentication-domain-name (variable length): A fully qualified domain name of the encrypted DNS resolver. This field is formatted as specified in Section 10 of [RFC8415]. An example of the authentication-domain-name encoding is shown in Figure 2. This example conveys the FQDN "doh1.example.com.", and the resulting Option-length field is 18. +------+------+------+------+------+------+------+------+------+ | 0x04 | d | o | h | 1 | 0x07 | e | x | a | +------+------+------+------+------+------+------+------+------+ | m | p | l | e | 0x03 | c | o | m | 0x00 | +------+------+------+------+------+------+------+------+------+ Figure 2: An Example of the DNS authentication-domain-name Encoding Addr Length: Length of enclosed IPv6 addresses in octets. When present, it MUST be a multiple of 16. ipv6-address(es) (variable length): Indicates one or more IPv6 addresses to reach the encrypted DNS resolver. An address can be link-local, ULA, or GUA. The format of this field is shown in Figure 3. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ipv6-address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format of the IPv6 Addresses Field Service Parameters (SvcParams) (variable length): Specifies a set of service parameters that are encoded following the rules in Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters may include, for example, a list of ALPN protocol identifiers or Boucadair, et al. Expires 14 February 2023 [Page 10] Internet-Draft Discovery of Network-designated Resolver August 2022 alternate port numbers. This field MUST include at least "alpn" SvcParam (Section 4.1 of [I-D.ietf-add-svcb-dns]). The service parameters MUST NOT include "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the included IP addresses. If no port service parameter is included, this indicates that default port numbers should be used. As a reminder, the default port number is 853 for DoT, 443 for DoH, and 853 for DoQ. The length of this field is ('Option-length' - 6 - 'ADN Length' - 'Addr Length'). Note that "Addr Length", "ipv6-address(es)", and "Service Parameters (SvcParams)" fields are not present if the ADN-only mode is used (Section 3.1.6). 4.2. DHCPv6 Client Behavior To discover an encrypted DNS resolver, the DHCPv6 client MUST include OPTION_V6_DNR in an Option Request Option (ORO), as in Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of [RFC8415]. The DHCPv6 client MUST be prepared to receive multiple instances of the OPTION_V6_DNR option; each option is to be treated as a separate encrypted DNS resolver. These instances MUST be processed following their service priority (i.e., smaller service priority indicates a higher preference). The DHCPv6 client MUST silently discard any OPTION_V6_DNR that fails to pass the validation steps defined in Section 3.1.8. The DHCPv6 client MUST silently discard multicast and host loopback addresses conveyed in OPTION_V6_DNR. 5. DHCPv4 Encrypted DNS Option 5.1. Option Format The format of the DHCPv4 Encrypted DNS option is illustrated in Figure 4. Boucadair, et al. Expires 14 February 2023 [Page 11] Internet-Draft Discovery of Network-designated Resolver August 2022 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_V4_DNR | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DNR Instance Data #1 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- . ... . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ optional ~ DNR Instance Data #n ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Figure 4: DHCPv4 Encrypted DNS Option The fields of the option shown in Figure 4 are as follows: Code: OPTION_V4_DNR (TBA2, see Section 9.2). Length: Indicates the length of the enclosed data in octets. DNR Instance Data: Includes the configuration data of an encrypted DNS resolver. The format of this field is shown in Figure 5. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DNR Instance Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADN Length | | +-+-+-+-+-+-+-+-+ | ~ authentication-domain-name ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Length | | +-+-+-+-+-+-+-+-+ | ~ IPv4 Address(es) ~ | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ | ~Service Parameters (SvcParams) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: DNR Instance Data Format When several encrypted DNS resolvers are to be included, the "DNR Instance Data" field is repeated. The fields shown in Figure 5 are as follows: Boucadair, et al. Expires 14 February 2023 [Page 12] Internet-Draft Discovery of Network-designated Resolver August 2022 DNR Instance Data Length: Length of all following data in octets. This field is set to ('ADN Length' + 3) when only an ADN is provided for a DNR instance. Service Priority: The priority of this instance compared to other DNR instances. This 16-bit unsigned integer is interpreted following the rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https]. ADN Length: Length of the authentication-domain-name in octets. authentication-domain-name (variable length): The authentication domain name of the encrypted DNS resolver. This field is formatted as specified in Section 10 of [RFC8415]. An example is provided in Figure 2. Addr Length: Length of included IPv4 addresses in octets. When present, it MUST be a multiple of 4. IPv4 Address(es) (variable length): Indicates one or more IPv4 addresses to reach the encrypted DNS resolver. Both private and public IPv4 addresses can be included in this field. The format of this field is shown in Figure 6. This format assumes that an IPv4 address is encoded as a1.a2.a3.a4. 0 8 16 24 32 40 48 +-----+-----+-----+-----+-----+-----+-- | a1 | a2 | a3 | a4 | a1 | a2 | ... +-----+-----+-----+-----+-----+-----+-- IPv4 Address 1 IPv4 Address 2 ... Figure 6: Format of the IPv4 Addresses Field Service Parameters (SvcParams) (variable length): Specifies a set of service parameters that are encoded following the rules in Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters may include, for example, a list of ALPN protocol identifiers or alternate port numbers. This field MUST include at least "alpn" SvcParam (Section 4.1 of [I-D.ietf-add-svcb-dns]). The service parameters MUST NOT include "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the included IP addresses. If no port service parameter is included, this indicates that default port numbers should be used. The length of this field is ('DNR Instance Data Length' - 4 - 'ADN Length' - 'Addr Length'). Boucadair, et al. Expires 14 February 2023 [Page 13] Internet-Draft Discovery of Network-designated Resolver August 2022 Note that "Addr Length", "IPv4 Address(es)", and "Service Parameters (SvcParams)" fields are not present if the ADN-only mode is used (Section 3.1.6). OPTION_V4_DNR is a concatenation-requiring option. As such, the mechanism specified in [RFC3396] MUST be used if OPTION_V4_DNR exceeds the maximum DHCPv4 option size of 255 octets. 5.2. DHCPv4 Client Behavior To discover an encrypted DNS resolver, the DHCPv4 client requests the encrypted DNS resolver by including OPTION_V4_DNR in a Parameter Request List option [RFC2132]. The DHCPv4 client MUST be prepared to receive multiple DNR instance data in the OPTION_V4_DNR option; each instance is to be treated as a separate encrypted DNS resolver. These instances MUST be processed following their service priority (i.e., smaller service priority indicates a higher preference). The DHCPv4 client MUST silently discard any OPTION_V4_DNR that fails to pass the validation steps defined in Section 3.1.8. The DHCPv4 client MUST silently discard multicast and host loopback addresses conveyed in OPTION_V4_DNR. 6. IPv6 RA Encrypted DNS Option 6.1. Option Format This section defines a new Neighbor Discovery option [RFC4861]: IPv6 RA Encrypted DNS option. This option is useful in contexts similar to those discussed in Section 1.1 of [RFC8106]. The format of the IPv6 RA Encrypted DNS option is illustrated in Figure 7. Boucadair, et al. Expires 14 February 2023 [Page 14] Internet-Draft Discovery of Network-designated Resolver August 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBA3 | Length | Service Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADN Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ authentication-domain-name ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ipv6-address(es) ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | SvcParams Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Service Parameters (SvcParams) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: RA Encrypted DNS Option The fields of the option shown in Figure 7 are as follows: Type: 8-bit identifier of the Encrypted DNS option as assigned by IANA (TBA3, see Section 9.3). Length: 8-bit unsigned integer. The length of the option (including the Type and Length fields) is in units of 8 octets. Service Priority: 16-bit unsigned integer. The priority of this Encrypted DNS option instance compared to other instances. This field is interpreted following the rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https]. Lifetime: 32-bit unsigned integer. The maximum time in seconds (relative to the time the packet is received) over which the discovered Authentication Domain Name is valid. The value of Lifetime SHOULD by default be at least 3 * MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA interval as defined in [RFC4861]. A value of all one bits (0xffffffff) represents infinity. A value of zero means that this Authentication Domain Name MUST no longer be used. Boucadair, et al. Expires 14 February 2023 [Page 15] Internet-Draft Discovery of Network-designated Resolver August 2022 ADN Length: 16-bit unsigned integer. This field indicates the length of the authentication-domain-name field in octets. authentication-domain-name (variable length): The authentication domain name of the encrypted DNS resolver. This field is formatted as specified in Section 10 of [RFC8415]. Addr Length: 16-bit unsigned integer. This field indicates the length of enclosed IPv6 addresses in octets. When present, it MUST be a multiple of 16. ipv6-address(es) (variable length): One or more IPv6 addresses of the encrypted DNS resolver. An address can be link-local, ULA, or GUA. All of the addresses share the same Lifetime value. Similar to [RFC8106], if it is desirable to have different Lifetime values per IP address, multiple Encrypted DNS options may be used. The format of this field is shown in Figure 3. SvcParams Length: 16-bit unsigned integer. This field indicates the length of the Service Parameters field in octets. Service Parameters (SvcParams) (variable length): Specifies a set of service parameters that are encoded following the rules in Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Service parameters may include, for example, a list of ALPN protocol identifiers or alternate port numbers. This field MUST include at least "alpn" SvcParam (Section 4.1 of [I-D.ietf-add-svcb-dns]). The service parameters MUST NOT include "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the included IP addresses. If no port service parameter is included, this indicates that default port numbers should be used. Note that "Addr Length", "ipv6-address(es)", and "Service Parameters (SvcParams)" fields are not present if the ADN-only mode is used (Section 3.1.6). The option MUST be padded with zeros so that the full enclosed data is a multiple of 8 octets (Section 4.6 of [RFC4861]). Boucadair, et al. Expires 14 February 2023 [Page 16] Internet-Draft Discovery of Network-designated Resolver August 2022 6.2. IPv6 Host Behavior The procedure for DNS configuration is the same as it is with any other Neighbor Discovery option [RFC4861]. In addition, the host follows the same procedure as the one described in Section 5.3.1 of [RFC8106] for processing received Encrypted DNS options with the formatting requirements in Section 6.1 and validation checks in Section 3.1.8 substituted for the length and fields validation. The host MUST be prepared to receive multiple Encrypted DNS options in RAs. These instances MUST be processed following their service priority (i.e., smaller service priority indicates a higher preference). The host MUST silently discard multicast and host loopback addresses conveyed in the Encrypted DNS options. 7. Security Considerations 7.1. Spoofing Attacks DHCP/RA messages are not encrypted or protected against modification within the LAN. Unless mitigated (described below), the content of DHCP and RA messages can be spoofed or modified by active attackers, such as compromised devices within the local network. An active attacker (Section 3.3 of [RFC3552]) can spoof the DHCP/RA response to provide the attacker's encrypted DNS resolver. Note that such an attacker can launch other attacks as discussed in Section 22 of [RFC8415]. The attacker can get a domain name with a domain- validated public certificate from a CA and host an encrypted DNS resolver. Attacks of spoofed or modified DHCP responses and RA messages by attackers within the local network may be mitigated by making use of the following mechanisms: * DHCPv6-Shield [RFC7610]: the network access node (e.g., a border router, a CPE, an Access Point (AP)) discards DHCP response messages received from any local endpoint. * RA-Guard [RFC7113]: the network access node discards RAs messages received from any local endpoint. * Source Address Validation Improvement (SAVI) solution for DHCP [RFC7513]: the network access node filters packets with forged source IP addresses. Boucadair, et al. Expires 14 February 2023 [Page 17] Internet-Draft Discovery of Network-designated Resolver August 2022 The above mechanisms would ensure that the endpoint receives the correct configuration information of the encrypted DNS resolvers selected by the DHCP server (or RA sender), but cannot provide any information about the DHCP server or the entity hosting the DHCP server (or RA sender). Encrypted DNS sessions with rogue resolvers that spoof the IP address of a DNS resolver will fail because the DNS client will fail to authenticate that rogue resolver based upon PKIX authentication [RFC6125], particularly the authentication domain name in the Encrypted DNS Option. DNS clients that ignore authentication failures and accept spoofed certificates will be subject to attacks (e.g., redirect to malicious resolvers, intercept sensitive data). 7.2. Deletion Attacks If the DHCP responses or RAs are dropped by the attacker, the client can fall back to use a preconfigured encrypted DNS resolver. However, the use of policies to select resolvers is out of the scope of this document. Note that deletion attack is not specific to DHCP/RA. 7.3. Passive Attacks A passive attacker (Section 3.2 of [RFC3552]) can identify a host is using DHCP/RA to discover an encrypted DNS resolver and can infer that host is capable of using DoH/DoT/DoQ to encrypt DNS messages. However, a passive attacker cannot spoof or modify DHCP/RA messages. 7.4. Wireless Security - Authentication Attacks Wireless LAN (WLAN) as frequently deployed in local networks (e.g., home networks) is vulnerable to various attacks (e.g., [Evil-Twin], [Krack], [Dragonblood]). Because of these attacks, only cryptographically authenticated communications are trusted on WLANs. This means that any information (e.g., NTP server, DNS resolver, domain search list) provided by such networks via DHCP, DHCPv6, or RA is untrusted because DHCP and RA messages are not authenticated. If the pre-shared key (PSK) is the same for all clients that connect to the same WLAN (e.g., WPA-PSK), the shared key will be available to all nodes, including attackers. As such, it is possible to mount an active on-path attack. On-path attacks are possible within local networks because such a WLAN authentication lacks peer entity authentication. Boucadair, et al. Expires 14 February 2023 [Page 18] Internet-Draft Discovery of Network-designated Resolver August 2022 This leads to the need for provisioning unique credentials for different clients. Endpoints can be provisioned with unique credentials (username and password, typically) provided by the local network administrator to mutually authenticate to the local WLAN AP (e.g., 802.1x Wireless User Authentication on OpenWRT [dot1x], EAP- pwd [RFC8146]). Not all endpoint devices (e.g., IoT devices) support 802.1x supplicant and need an alternate mechanism to connect to the local network. To address this limitation, unique pre-shared keys can be created for each such devices and WPA-PSK is used (e.g., [IPSK]). 8. Privacy Considerations Privacy considerations that are specific to DNR provisioning mechanisms are discussed in Section 23 of [RFC8415] or [RFC7824]. Anonymity profiles for DHCP clients are discussed in [RFC7844]. The mechanism defined in this document can be used to infer that a DHCP client or IPv6 host support encrypted DNS options, but does not explicitly reveal whether local DNS clients are able to consume these options or infer their encryption capabilities. Other than that, this document does not expose more privacy information compared to Do53 discovery options. As discussed in [RFC9076], the use of encrypted DNS does not reduce the data available in the DNS resolver. For example, the reader may refer to Section 8 of [RFC8484] or Section 7 of [RFC9250] for a discussion on specific privacy considerations to encrypted DNS. 9. IANA Considerations 9.1. DHCPv6 Option IANA is requested to assign the following new DHCPv6 Option Code in the registry maintained in [DHCPV6]. +=======+===============+============+===========+================+ | Value | Description | Client ORO | Singleton | Reference | | | | | Option | | +=======+===============+============+===========+================+ | TBA1 | OPTION_V6_DNR | Yes | No | [ThisDocument] | +-------+---------------+------------+-----------+----------------+ Table 1: DHCPv6 Encrypted DNS Option Boucadair, et al. Expires 14 February 2023 [Page 19] Internet-Draft Discovery of Network-designated Resolver August 2022 9.2. DHCPv4 Option IANA is requested to assign the following new DHCP Option Code in the registry maintained in [BOOTP]. +======+===============+=============+============+================+ | Tag | Name | Data Length | Meaning | Reference | +======+===============+=============+============+================+ | TBA2 | OPTION_V4_DNR | N | Encrypted | [ThisDocument] | | | | | DNS Server | | +------+---------------+-------------+------------+----------------+ Table 2: DHCPv4 Encrypted DNS Option 9.3. Neighbor Discovery Option IANA is requested to assign the following new IPv6 Neighbor Discovery Option type in the "IPv6 Neighbor Discovery Option Formats" sub- registry under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry maintained in [ND]. +======+======================+================+ | Type | Description | Reference | +======+======================+================+ | TBA3 | Encrypted DNS Option | [ThisDocument] | +------+----------------------+----------------+ Table 3: Neighbor Discovery Encrypted DNS Option 10. Acknowledgements Many thanks to Christian Jacquenet and Michael Richardson for the review. Thanks to Stephen Farrell, Martin Thomson, Vittorio Bertola, Stephane Bortzmeyer, Ben Schwartz, Iain Sharp, and Chris Box for the comments. Thanks to Mark Nottingham for the feedback on HTTP redirection that was discussed in previous versions of this specification. The use of DHCP to retrieve an authentication domain name was discussed in Section 7.3.1 of [RFC8310] and [I-D.pusateri-dhc-dns-driu]. Thanks to Bernie Volz for the review of the DHCP part. Boucadair, et al. Expires 14 February 2023 [Page 20] Internet-Draft Discovery of Network-designated Resolver August 2022 Thanks to Andrew Campling for the Shepherd review and Eric Vyncke for the AD review. Thanks to Rich Salz for the secdir review, Joe Clarke for the ops-dir review, and Robert Sparks for the artart review. Thanks to Lars Eggert, Roman Danyliw, Erik Kline, Martin Duke, Robert Wilton, and Paul Wouters for the IESG review. 11. Contributing Authors Nicolai Leymann Deutsche Telekom Germany Email: n.leymann@telekom.de Zhiwei Yan CNNIC No.4 South 4th Street, Zhongguancun Beijing 100190 China Email: yan@cnnic.cn 12. References 12.1. Normative References [I-D.ietf-add-svcb-dns] Schwartz, B., "Service Binding Mapping for DNS Servers", Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns- 07, 11 August 2022, . [I-D.ietf-dnsop-svcb-https] Schwartz, B., Bishop, M., and E. Nygren, "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- dnsop-svcb-https-10, 24 May 2022, . Boucadair, et al. Expires 14 February 2023 [Page 21] Internet-Draft Discovery of Network-designated Resolver August 2022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, . [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, DOI 10.17487/RFC3396, November 2002, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . 12.2. Informative References [BOOTP] "BOOTP Vendor Extensions and DHCP Options", . [DHCPV6] "DHCPv6 Option Codes", . [dot1x] Cisco, "Basic 802.1x Wireless User Authentication", . Boucadair, et al. Expires 14 February 2023 [Page 22] Internet-Draft Discovery of Network-designated Resolver August 2022 [Dragonblood] The Unicode Consortium, "Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd", . [Evil-Twin] The Unicode Consortium, "Evil twin (wireless networks)", . [I-D.ietf-add-ddr] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. Jensen, "Discovery of Designated Resolvers", Work in Progress, Internet-Draft, draft-ietf-add-ddr-10, 5 August 2022, . [I-D.ietf-add-split-horizon-authority] Reddy, T., Wing, D., Smith, K., and B. Schwartz, "Establishing Local DNS Authority in Split-Horizon Environments", Work in Progress, Internet-Draft, draft- ietf-add-split-horizon-authority-00, 25 June 2022, . [I-D.pusateri-dhc-dns-driu] Pusateri, T. and W. Toorop, "DHCPv6 Options for private DNS Discovery", Work in Progress, Internet-Draft, draft- pusateri-dhc-dns-driu-00, 2 July 2018, . [IPSK] Cisco, "Identity PSK Feature Deployment Guide", . [Krack] The Unicode Consortium, "Key Reinstallation Attacks", 2017, . [ND] "IPv6 Neighbor Discovery Option Formats", . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . Boucadair, et al. Expires 14 February 2023 [Page 23] Internet-Draft Discovery of Network-designated Resolver August 2022 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, . [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved Recursive DNS Server Selection for Multi-Interfaced Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, . [RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, DOI 10.17487/RFC7113, February 2014, . [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, . [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, May 2015, . [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers", BCP 199, RFC 7610, DOI 10.17487/RFC7610, August 2015, . Boucadair, et al. Expires 14 February 2023 [Page 24] Internet-Draft Discovery of Network-designated Resolver August 2022 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy Considerations for DHCPv6", RFC 7824, DOI 10.17487/RFC7824, May 2016, . [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP Configuration on the Basis of Network Topology", RFC 7969, DOI 10.17487/RFC7969, October 2016, . [RFC8146] Harkins, D., "Adding Support for Salted Password Databases to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017, . [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles for DNS over TLS and DNS over DTLS", RFC 8310, DOI 10.17487/RFC8310, March 2018, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . [RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. Shao, "Discovering Provisioning Domain Names and Data", RFC 8801, DOI 10.17487/RFC8801, July 2020, . [RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076, DOI 10.17487/RFC9076, July 2021, . Boucadair, et al. Expires 14 February 2023 [Page 25] Internet-Draft Discovery of Network-designated Resolver August 2022 [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, . [TS.24008] 3GPP, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 16)", December 2019, . Authors' Addresses Mohamed Boucadair (editor) Orange 35000 Rennes France Email: mohamed.boucadair@orange.com Tirumaleswar Reddy (editor) Nokia India Email: kondtir@gmail.com Dan Wing Citrix Systems, Inc. United States of America Email: dwing-ietf@fuggles.com Neil Cook Open-Xchange United Kingdom Email: neil.cook@noware.co.uk Tommy Jensen Microsoft United States of America Email: tojens@microsoft.com Boucadair, et al. Expires 14 February 2023 [Page 26] ./draft-ietf-pce-binding-label-sid-15.txt0000644000764400076440000016115214215757111017675 0ustar iustiniustin PCE Working Group S. Sivabalan Internet-Draft Ciena Corporation Intended status: Standards Track C. Filsfils Expires: 21 September 2022 Cisco Systems, Inc. J. Tantsura Microsoft Corporation S. Previdi C. Li, Ed. Huawei Technologies 20 March 2022 Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks. draft-ietf-pce-binding-label-sid-15 Abstract In order to provide greater scalability, network confidentiality, and service independence, Segment Routing (SR) utilizes a Binding Segment Identifier (SID) (called BSID) as described in RFC 8402. It is possible to associate a BSID to an RSVP-TE-signaled Traffic Engineering Label Switched Path or an SR Traffic Engineering path. The BSID can be used by an upstream node for steering traffic into the appropriate TE path to enforce SR policies. This document specifies the concept of binding value, which can be either an MPLS label or Segment Identifier. It further specifies an extension to Path Computation Element (PCE) communication Protocol(PCEP) for reporting the binding value by a Path Computation Client (PCC) to the PCE to support PCE-based Traffic Engineering policies. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 21 September 2022. Sivabalan, et al. Expires 21 September 2022 [Page 1] Internet-Draft Binding Label/SID March 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation and Example . . . . . . . . . . . . . . . . . 4 1.2. Summary of the Extension . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Path Binding TLV . . . . . . . . . . . . . . . . . . . . . . 6 4.1. SRv6 Endpoint Behavior and SID Structure . . . . . . . . 8 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Binding SID in SR-ERO . . . . . . . . . . . . . . . . . . . . 12 7. Binding SID in SRv6-ERO . . . . . . . . . . . . . . . . . . . 12 8. PCE Allocation of Binding label/SID . . . . . . . . . . . . . 12 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 9.1. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Manageability Considerations . . . . . . . . . . . . . . . . 16 11.1. Control of Function and Policy . . . . . . . . . . . . . 17 11.2. Information and Data Models . . . . . . . . . . . . . . 17 11.3. Liveness Detection and Monitoring . . . . . . . . . . . 17 11.4. Verify Correct Operations . . . . . . . . . . . . . . . 17 11.5. Requirements On Other Protocols . . . . . . . . . . . . 17 11.6. Impact On Network Operations . . . . . . . . . . . . . . 17 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 12.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 17 12.1.1. TE-PATH-BINDING TLV . . . . . . . . . . . . . . . . 18 12.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 19 12.3. PCEP Error Type and Value . . . . . . . . . . . . . . . 19 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 14.1. Normative References . . . . . . . . . . . . . . . . . . 20 14.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 24 Sivabalan, et al. Expires 21 September 2022 [Page 2] Internet-Draft Binding Label/SID March 2022 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction A Path Computation Element (PCE) can compute Traffic Engineering paths (TE paths) through a network where those paths are subject to various constraints. Currently, TE paths are set up using either the RSVP-TE signaling protocol or Segment Routing (SR). We refer to such paths as RSVP-TE paths and SR-TE paths respectively in this document. As per [RFC8402] SR allows a head-end node to steer a packet flow along a given path via a Segment Routing Policy (SR Policy). As per [I-D.ietf-spring-segment-routing-policy], an SR Policy is a framework that enables the instantiation of an ordered list of segments on a node for implementing a source routing policy with a specific intent for traffic steering from that node. As described in [RFC8402], a Binding Segment Identifier (BSID) is bound to a Segment Routing (SR) Policy, instantiation of which may involve a list of Segment Identifiers (SIDs). Any packets received with an active segment equal to a BSID are steered onto the bound SR Policy. A BSID may be either a local (SR Local Block (SRLB)) or a global (SR Global Block (SRGB)) SID. As per Section 6.4 of [I-D.ietf-spring-segment-routing-policy] a BSID can also be associated with any type of interface or tunnel to enable the use of a non-SR interface or tunnel as a segment in a SID list. In this document, the term 'binding label/SID' is used to generalize the allocation of binding value for both SR and non-SR paths. [RFC5440] describes the PCEP for communication between a Path Computation Client (PCC) and a PCE or between a pair of PCEs as per [RFC4655]. [RFC8231] specifies extensions to PCEP that allow a PCC to delegate its Label Switched Paths (LSPs) to a stateful PCE. A stateful PCE can then update the state of LSPs delegated to it. [RFC8281] specifies a mechanism allowing a PCE to dynamically instantiate an LSP on a PCC by sending the path and characteristics. This document specifies an extension to PCEP to manage the binding of label/SID that can be applied to SR, RSVP-TE, and other path setup types. [RFC8664] provides a mechanism for a PCE (acting as a network controller) to instantiate SR-TE paths (candidate paths) for an SR Policy onto a head-end node (acting as a PCC) using PCEP. For more information on the SR Policy Architecture, see [I-D.ietf-spring-segment-routing-policy]. Sivabalan, et al. Expires 21 September 2022 [Page 3] Internet-Draft Binding Label/SID March 2022 1.1. Motivation and Example A binding label/SID has local significance to the ingress node of the corresponding TE path. When a stateful PCE is deployed for setting up TE paths, a binding label/SID reported from the PCC to the stateful PCE is useful for the purpose of enforcing end-to-end TE/SR policy. A sample Data Center (DC) and IP/MPLS WAN use-case is illustrated in Figure 1 with a multi-domain PCE. In the IP/MPLS WAN, an SR-TE LSP is set up using the PCE. The list of SIDs of the SR-TE LSP is {A, B, C, D}. The gateway node 1 (which is the PCC) allocates a binding SID X and reports it to the PCE. In the MPLS DC network, an end-to-end SR-TE LSP is established. In order for the access node to steer the traffic towards Node-1 and over the SR-TE path in WAN, the PCE passes the SID stack {Y, X} where Y is the node SID of the gateway node-1 to the access node and X is the BSID. In the absence of the BSID X, the PCE would need to pass the SID stack {Y, A, B, C, D} to the access node. This example also illustrates the additional benefit of using the binding label/SID to reduce the number of SIDs imposed by the access nodes with a limited forwarding capacity. SID stack {Y, X} +--------------+ | Multi-domain | _ _ _ _ _ _ _ _ _ _ _ _ _ _| PCE | | +--------------+ | ^ | | Binding | .-----. | SID (X) .-----. | ( ) | ( ) V .--( )--. | .--( )--. +------+ ( ) +-------+ ( ) +-------+ |Access|_( MPLS DC Network )_|Gateway|_( IP/MPLS WAN )_|Gateway| | Node | ( ==============> ) |Node-1 | ( ================> ) |Node-2 | +------+ ( SR-TE path ) +-------+ ( SR-TE path ) +-------+ '--( )--' Node '--( )--' ( ) SID of ( ) '-----' Node-1 '-----' is Y SIDs for SR-TE LSP: {A, B, C, D} Figure 1: A Sample Use-case of Binding SID Using the extension defined in this document, a PCC could report to the stateful PCE the binding label/SID it allocated via a Path Computation LSP State Report (PCRpt) message. It is also possible for a stateful PCE to request a PCC to allocate a specific binding label/SID by sending a Path Computation LSP Update Request (PCUpd) message. If the PCC can successfully allocate the specified binding Sivabalan, et al. Expires 21 September 2022 [Page 4] Internet-Draft Binding Label/SID March 2022 value, it reports the binding value to the PCE. Otherwise, the PCC sends an error message to the PCE indicating the cause of the failure. A local policy or configuration at the PCC SHOULD dictate if the binding label/SID needs to be assigned. 1.2. Summary of the Extension To implement the needed changes to PCEP, in this document, we introduce a new OPTIONAL TLV that a PCC can use in order to report the binding label/SID associated with a TE LSP, or a PCE to request a PCC to allocate any or a specific binding label/SID value. This TLV is intended for TE LSPs established using RSVP-TE, SR-TE, or any other future method. In the case of SR-TE LSPs, the TLV can carry a binding label (for SR-TE path with MPLS data-plane) or a binding IPv6 SID (e.g., IPv6 address for SR-TE paths with IPv6 data-plane). Throughout this document, the term "binding value" means either an MPLS label or a SID. As another way to use the extension specified in this document, to support the PCE-based central controller [RFC8283] operation where the PCE would take responsibility for managing some part of the MPLS label space for each of the routers that it controls, the PCE could directly make the binding label/SID allocation and inform the PCC. See Section 8 for details. In addition to specifying a new TLV, this document specifies how and when a PCC and PCE can use this TLV, how they can allocate a binding label/SID, and associated error handling. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology The following terminologies are used in this document: BSID: Binding Segment Identifier. binding label/SID: a generic term used for the binding segment for both SR and non-SR paths. binding value: a generic term used for the binding segment as it can be encoded in various formats (as per the binding type(BT)). Sivabalan, et al. Expires 21 September 2022 [Page 5] Internet-Draft Binding Label/SID March 2022 LSP: Label Switched Path. PCC: Path Computation Client. PCEP: Path Computation Element communication Protocol. RSVP-TE: Resource ReserVation Protocol-Traffic Engineering. SID: Segment Identifier. SR: Segment Routing. 4. Path Binding TLV The new optional TLV called "TE-PATH-BINDING TLV" (whose format is shown in Figure 2) is defined to carry the binding label/SID for a TE path. This TLV is associated with the LSP object specified in [RFC8231]. This TLV can also be carried in the PCEP-ERROR object [RFC5440] in case of error. Multiple instances of TE-PATH-BINDING TLVs MAY be present in the LSP and PCEP-ERROR object. The type of this TLV is 55 (early allocated by IANA). The length is variable. [Note to RFC Editor: Please remove "(early allocated by IANA)" before publication] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 55 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Binding Value (variable length) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: TE-PATH-BINDING TLV TE-PATH-BINDING TLV is a generic TLV such that it is able to carry binding label/SID (i.e. MPLS label or SRv6 SID). It is formatted according to the rules specified in [RFC5440]. The value portion of the TLV comprises: Binding Type (BT): A one-octet field that identifies the type of binding included in the TLV. This document specifies the following BT values: Sivabalan, et al. Expires 21 September 2022 [Page 6] Internet-Draft Binding Label/SID March 2022 * BT = 0: The binding value is a 20-bit MPLS label value. The TLV is padded to 4-bytes alignment. The Length MUST be set to 7 (the padding is not included in the length, as per [RFC5440] Section 7.1) and the first 20 bits are used to encode the MPLS label value. * BT = 1: The binding value is a 32-bit MPLS label stack entry as per [RFC3032] with Label, TC [RFC5462], S, and TTL values encoded. Note that the receiver MAY choose to override TC, S, and TTL values according to its local policy. The Length MUST be set to 8. * BT = 2: The binding value is an SRv6 SID with the format of a 16-octet IPv6 address, representing the binding SID for SRv6. The Length MUST be set to 20. * BT = 3: The binding value is a 24 octet field, defined in Section 4.1, that contains the SRv6 SID as well as its Behavior and Structure. The Length MUST be set to 28. Section 12.1.1 defines the IANA registry used to maintain all these binding types as well as any future ones. Note that multiple TE- PATH-BINDING TLVs with same or different Binding Types MAY be present for the same LSP. A PCEP speaker could allocate multiple TE-PATH- BINDING TLVs (of the same BT), and use different binding values in different domains or use-cases based on a local policy. Flags: 1 octet of flags. The following flag is defined in the new registry "TE-PATH-BINDING TLV Flag field" as described in Section 12.1.1: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R| | +-+-+-+-+-+-+-+-+ Figure 3: Flags where: * R (Removal - 1 bit): When set, the requesting PCEP peer requires the removal of the binding value for the LSP. When unset, the PCEP peer indicates that the binding value is added or retained for the LSP. This flag is used in the PCRpt and PCUpd messages. It is ignored in other PCEP messages. Sivabalan, et al. Expires 21 September 2022 [Page 7] Internet-Draft Binding Label/SID March 2022 * The unassigned flags MUST be set to 0 while sending and ignored on receipt. Reserved: MUST be set to 0 while sending and ignored on receipt. Binding Value: A variable-length field, padded with trailing zeros to a 4-octet boundary. When the BT is 0, the 20 bits represent the MPLS label. When the BT is 1, the 32 bits represent the MPLS label stack entry as per [RFC3032]. When the BT is 2, the 128 bits represent the SRv6 SID. When the BT is 3, the Binding Value also contains the SRv6 Endpoint Behavior and SID Structure, defined in Section 4.1. In this document, the TE-PATH-BINDING TLV is considered to be empty if no Binding Value is present. Note that the length of the TLV would be 4 in such a case. 4.1. SRv6 Endpoint Behavior and SID Structure This section specifies the format of the Binding Value in the TE- PATH-BINDING TLV when the BT is set to 3 for the SRv6 Binding SIDs [RFC8986]. The format is shown in Figure 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SRv6 Binding SID (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LB Length | LN Length | Fun. Length | Arg. Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: SRv6 Endpoint Behavior and SID Structure The Binding Value consists of: * SRv6 Binding SID: 16 octets. The 128-bit IPv6 address, representing the binding SID for SRv6. * Reserved: 2 octets. It MUST be set to 0 on transmit and ignored on receipt. Sivabalan, et al. Expires 21 September 2022 [Page 8] Internet-Draft Binding Label/SID March 2022 * Endpoint Behavior: 2 octets. The Endpoint Behavior code point for this SRv6 SID as per the IANA subregistry called "SRv6 Endpoint Behaviors", created by [RFC8986]. When the field is set with the value 0, the endpoint behavior is considered unknown. * [RFC8986] defines an SRv6 SID as consisting of LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). A locator may be represented as B:N where B is the SRv6 SID locator block (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is the identifier of the parent node instantiating the SID called locator node. The following fields are used to advertise the length of each individual part of the SRv6 SID as defined in : - LB Length: 1 octet. SRv6 SID Locator Block length in bits. - LN Length: 1 octet. SRv6 SID Locator Node length in bits. - Function Length: 1 octet. SRv6 SID Function length in bits. - Argument Length: 1 octet. SRv6 SID Arguments length in bits. The total of the locator block, locator node, function, and argument lengths MUST be lower or equal to 128 bits. If this condition is not met, the corresponding TE-PATH-BINDING TLV is considered invalid. Also, if the Endpoint Behavior is found to be unknown or inconsistent, it is considered invalid. A PCErr message with Error- Type = 10 ("Reception of an invalid object") and Error-Value = 37 ("Invalid SRv6 SID Structure") MUST be sent in such cases. The SRv6 SID Structure could be used by the PCE for ease of operations and monitoring. For example, this information could be used for validation of SRv6 SIDs being instantiated in the network and checked for conformance to the SRv6 SID allocation scheme chosen by the operator as described in Section 3.2 of [RFC8986]. In the future, PCE could also be used for verification and the automation for securing the SRv6 domain by provisioning filtering rules at SR domain boundaries as described in Section 5 of [RFC8754]. The details of these potential applications are outside the scope of this document. Sivabalan, et al. Expires 21 September 2022 [Page 9] Internet-Draft Binding Label/SID March 2022 5. Operation The binding value is usually allocated by the PCC and reported to a PCE via a PCRpt message (see Section 8 where PCE does the allocation). If a PCE does not recognize the TE-PATH-BINDING TLV, it would ignore the TLV in accordance with [RFC5440]. If a PCE recognizes the TLV but does not support the TLV, it MUST send a PCErr with Error-Type = 2 (Capability not supported). Multiple TE-PATH-BINDING TLVs are allowed to be present in the same LSP object. This signifies the presence of multiple binding SIDs for the given LSP. In the case of multiple TE-PATH-BINDING TLVs, the existing instances of TE-PATH-BINDING TLVs MAY be included in the LSP object. In case of an error condition, the whole message is rejected and the resulting PCErr message MAY include the offending TE-PATH- BINDING TLV in the PCEP-ERROR object. If a PCE recognizes an invalid binding value (e.g., label value from the reserved MPLS label space), it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error Value = 2 ("Bad label value") as specified in [RFC8664]. For SRv6 BSIDs, it is RECOMMENDED to always explicitly specify the SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV by setting the BT (Binding Type) to 3. This can enable the sender to have control of the SRv6 Endpoint Behavior and SID Structure. A sender MAY choose to set the BT to 2, in which case the receiving implementation chooses how to interpret the SRv6 Endpoint Behavior and SID Structure according to local policy. If a PCC wishes to withdraw a previously reported binding value, it MUST send a PCRpt message with the specific TE-PATH-BINDING TLV with R flag set to 1. If a PCC wishes to modify a previously reported binding, it MUST withdraw the former binding value (with R flag set in the former TE-PATH-BINDING TLV) and include a new TE-PATH-BINDING TLV containing the new binding value. Note that other instances of TE-PATH-BINDING TLVs that are unchanged MAY also be included. If the unchanged instances are not included, they will remain associated with the LSP. If a PCE requires a PCC to allocate a (or several) specific binding value(s), it may do so by sending a PCUpd or PCInitiate message containing a TE-PATH-BINDING TLV(s). If the value(s) can be successfully allocated, the PCC reports the binding value(s) to the PCE. If the PCC considers the binding value specified by the PCE invalid, it MUST send a PCErr message with Error-Type = TBD2 ("Binding label/SID failure") and Error Value = TBD3 ("Invalid SID"). If the binding value is valid, but the PCC is unable to allocate the Sivabalan, et al. Expires 21 September 2022 [Page 10] Internet-Draft Binding Label/SID March 2022 binding value, it MUST send a PCErr message with Error-Type = TBD2 ("Binding label/SID failure") and Error Value = TBD4 ("Unable to allocate the specified binding value"). Note that, in case of an error, the PCC rejects the PCUpd or PCInitiate message in its entirety and can include the offending TE-PATH-BINDING TLV in the PCEP-ERROR object. If a PCE wishes to request the withdrawal of a previously reported binding value, it MUST send a PCUpd message with the specific TE- PATH-BINDING TLV with R flag set to 1. If a PCE wishes to modify a previously requested binding value, it MUST request the withdrawal of the former binding value (with R flag set in the former TE-PATH- BINDING TLV) and include a new TE-PATH-BINDING TLV containing the new binding value. If a PCC receives a PCUpd message with TE-PATH- BINDING TLV where the R flag is set to 1, but either the binding value is missing (empty TE-PATH-BINDING TLV) or the binding value is incorrect, it MUST send a PCErr message with Error-Type = TBD2 ("Binding label/SID failure") and Error Value = TBD6 ("Unable to remove the binding value"). In some cases, a stateful PCE may want to request that the PCC allocate a binding value of the PCC's own choosing. It instructs the PCC by sending a PCUpd message containing an empty TE-PATH-BINDING TLV, i.e., no binding value is specified (bringing the Length field of the TLV to 4). A PCE can also request a PCC to allocate a binding value at the time of initiation by sending a PCInitiate message with an empty TE-PATH-BINDING TLV. Only one such instance of empty TE- PATH-BINDING TLV, per BT, SHOULD be included in the LSP object and others ignored on receipt. If the PCC is unable to allocate a new binding value as per the specified BT, it MUST send a PCErr message with Error-Type = TBD2 ("Binding label/SID failure") and Error-Value = TBD5 ("Unable to allocate a new binding label/SID"). As previously noted, if a message contains an invalid TE-PATH-BINDING TLV that leads to an error condition, the whole message is rejected including any other valid instances of TE-PATH-BINDING TLVs, if any. The resulting error message MAY include the offending TE-PATH-BINDING TLV in the PCEP-ERROR object. If a PCC receives a TE-PATH-BINDING TLV in any message other than PCUpd or PCInitiate, it MUST close the corresponding PCEP session with the reason "Reception of a malformed PCEP message" (according to [RFC5440]). Similarly, if a PCE receives a TE-PATH-BINDING TLV in any message other than a PCRpt or if the TE-PATH-BINDING TLV is associated with any object other than an LSP or PCEP-ERROR object, the PCE MUST close the corresponding PCEP session with the reason "Reception of a malformed PCEP message" (according to [RFC5440]). Sivabalan, et al. Expires 21 September 2022 [Page 11] Internet-Draft Binding Label/SID March 2022 If a TE-PATH-BINDING TLV is absent in the PCRpt message and no binding values were reported before, the PCE MUST assume that the corresponding LSP does not have any binding. Similarly, if TE-PATH- BINDING TLV is absent in the PCUpd message and no binding values were reported before, the PCC's local policy dictates how the binding allocations are made for a given LSP. Note that some binding types have similar information but different binding value formats. For example, BT=(2 or 3) is used for the SRv6 SID and BT=(0 or 1) is used for the MPLS Label. In case a PCEP speaker receives multiple TE-PATH-BINDING TLVs with the same SRv6 SID or MPLS Label but different BT values, it MUST send a PCErr message with Error-Type = TBD2 ("Binding label/SID failure") and Error-Value = TBD7 ("Inconsistent binding types"). 6. Binding SID in SR-ERO In PCEP messages, LSP route information is carried in the Explicit Route Object (ERO), which consists of a sequence of subobjects. [RFC8664] defines the "SR-ERO subobject" capable of carrying a SID as well as the identity of the node/adjacency (NAI) represented by the SID. The NAI Type (NT) field indicates the type and format of the NAI contained in the SR-ERO. In case of binding SID, the NAI MUST NOT be included and NT MUST be set to zero. [RFC8664] Section 5.2.1 specifies bit settings and error handling in the case when NT=0. 7. Binding SID in SRv6-ERO [I-D.ietf-pce-segment-routing-ipv6] defines the "SRv6-ERO subobject" for an SRv6 SID. Similarly to SR-ERO (Section 6), the NAI MUST NOT be included and the NT MUST be set to zero. [RFC8664] Section 5.2.1 specifies bit settings and error handling in the case when NT=0. 8. PCE Allocation of Binding label/SID Section 5 already includes the scenario where a PCE requires a PCC to allocate a specified binding value by sending a PCUpd or PCInitiate message containing a TE-PATH-BINDING TLV. This section specifies an OPTIONAL feature for the PCE to allocate the binding label/SID of its own accord in the case where the PCE also controls the label space of the PCC and can make the label allocation on its own as described in [RFC8283]. Note that the act of requesting a specific binding value (Section 5) is different from the act of allocating a binding label/ SID as described in this section. [RFC8283] introduces the architecture for PCE as a central controller as an extension of the architecture described in [RFC4655] and assumes the continued use of PCEP as the protocol used between PCE Sivabalan, et al. Expires 21 September 2022 [Page 12] Internet-Draft Binding Label/SID March 2022 and PCC. [RFC9050] specifies the procedures and PCEP extensions for using the PCE as the central controller. It assumes that the exclusive label range to be used by a PCE is known and set on both PCEP peers. A future extension could add the capability to advertise this range via a possible PCEP extension as well (see [I-D.li-pce-controlled-id-space]). When PCECC operations are supported as per [RFC9050], the binding label/SID MAY also be allocated by the PCE itself. Both peers need to exchange the PCECC capability as described in [RFC9050] before the PCE can allocate the binding label/SID on its own. A new P flag in the LSP object [RFC8231] is introduced to indicate that the allocation needs to be made by the PCE. Note that the P flag could be used for other types of allocations (such as path segments [I-D.ietf-pce-sr-path-segment]) in future. * P (PCE-allocation): If the bit is set to 1, it indicates that the PCC requests PCE to make allocations for this LSP. The TE-PATH- BINDING TLV in the LSP object identifies that the allocation is for a binding label/SID. A PCC MUST set this bit to 1 and include a TE-PATH-BINDING TLV in the LSP object if it wishes to request for allocation of binding label/SID by the PCE in the PCEP message. A PCE MUST also set this bit to 1 and include a TE-PATH- BINDING TLV to indicate that the binding label/SID is allocated by PCE and encoded in the PCEP message towards the PCC. Further, if the binding label/SID is allocated by the PCC, the PCE MUST set this bit to 0 and follow the procedure described in Section 5. Note that - * A PCE could allocate the binding label/SID of its own accord for a PCE-initiated or delegated LSP, and inform the PCC in the PCInitiate message or PCUpd message by setting P=1 and including TE-PATH-BINDING TLV in the LSP object. * To let the PCC allocate the binding label/SID, a PCE MUST set P=0 and include an empty TE-PATH-BINDING TLV ( i.e., no binding value is specified) in the LSP object in PCInitiate/PCUpd message. * To request that the PCE allocate the binding label/SID, a PCC MUST set P=1, D=1, and include an empty TE-PATH-BINDING TLV in PCRpt message. The PCE will attempt to allocate it and respond to the PCC with PCUpd message including the allocated binding label/SID in the TE-PATH-BINDING TLV and P=1, D=1 in the LSP object. If the PCE is unable to allocate, it MUST send a PCErr message with Error-Type = TBD2 ("Binding label/SID failure") and Error-Value = TBD5 ("Unable to allocate a new binding label/SID"). Sivabalan, et al. Expires 21 September 2022 [Page 13] Internet-Draft Binding Label/SID March 2022 * If one or both speakers (PCE and PCC) have not indicated support and willingness to use the PCEP extensions for the PCECC as per [RFC9050] and a PCEP peer receives P=1 in the LSP object, it MUST: - send a PCErr message with Error-Type=19 (Invalid Operation) and Error-value=16 (Attempted PCECC operations when PCECC capability was not advertised) and - terminate the PCEP session. * A legacy PCEP speaker that does not recognize the P flag in the LSP object would ignore it in accordance with [RFC8231]. It is assumed that the label range to be used by a PCE is known and set on both PCEP peers. The exact mechanism is out of the scope of [RFC9050] or this document. Note that the specific BSID could be from the PCE-controlled or the PCC-controlled label space. The PCE can directly allocate the label from the PCE-controlled label space using P=1 as described above, whereas the PCE can request the allocation of a specific BSID from the PCC-controlled label space with P=0 as described in Section 5. Note that, the P-Flag in the LSP object SHOULD NOT be set to 1 without the presence of TE-PATH-BINDING TLV or any other future TLV defined for PCE allocation. On receipt of such an LSP object, the P-Flag is ignored. The presence of TE-PATH-BINDING TLV with P=1 indicates the allocation is for the binding label/SID. In the future, some other TLV (such as one defined in [I-D.ietf-pce-sr-path-segment]) could also be used alongside P=1 to indicate allocation of a different attribute. A future document should not attempt to assign semantics to P=1 without limiting its scope that both PCEP peers could agree on. 9. Implementation Status [Note to the RFC Editor - remove this section before publication, as well as remove the reference to RFC 7942.] Sivabalan, et al. Expires 21 September 2022 [Page 14] Internet-Draft Binding Label/SID March 2022 This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". 9.1. Huawei * Organization: Huawei * Implementation: Huawei's Router and Controller * Description: An experimental code-point is used and will be modified to the value allocated in this document. * Maturity Level: Production * Coverage: Full * Contact: c.l@huawei.com 9.2. Cisco * Organization: Cisco Systems * Implementation: Head-end and controller. * Description: An experimental code-point is used and will be modified to the value allocated in this document. * Maturity Level: Production * Coverage: Full Sivabalan, et al. Expires 21 September 2022 [Page 15] Internet-Draft Binding Label/SID March 2022 * Contact: mkoldych@cisco.com 10. Security Considerations The security considerations described in [RFC5440], [RFC8231], [RFC8281], [RFC8664], and [RFC9050] are applicable to this specification. No additional security measure is required. As described in [RFC8402] and [RFC8664], SR intrinsically involves an entity (whether head-end or a central network controller) controlling and instantiating paths in the network without the involvement of (other) nodes along those paths. Binding SIDs are in effect shorthand aliases for longer path representations, and the alias expansion is in principle known only by the node that acts on it. In this document, the expansion of the alias is shared between PCC and PCE, and rogue actions by either PCC or PCE could result in shifting or misdirecting traffic in ways that are hard for other nodes to detect. In particular, when a PCE propagates paths of the form {A, B, BSID} to other entities, the BSID values are opaque, and a rogue PCE can substitute a BSID from a different LSP in such paths to move traffic without the recipient of the path knowing the ultimate destination. The case of BT=3 provides additional opportunities for malfeasance, as it purports to convey information about internal SRv6 SID structure. There is no mechanism defined to validate this internal structure information, and mischaracterizing the division of bits into locator block, locator node, function, and argument can result in different interpretation of the bits by PCC and PCE. Most notably, shifting bits into or out of the "argument" is a direct vector for affecting processing, but other attacks are also possible. Thus, as per [RFC8231], it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in BCP195 [RFC7525] (unless explicitly set aside in [RFC8253]). 11. Manageability Considerations All manageability requirements and considerations listed in [RFC5440], [RFC8231], and [RFC8664] apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply. Sivabalan, et al. Expires 21 September 2022 [Page 16] Internet-Draft Binding Label/SID March 2022 11.1. Control of Function and Policy A PCC implementation SHOULD allow the operator to configure the policy the PCC needs to apply when allocating the binding label/SID. If BT is set to 2, the operator needs to have local policy set to decide the SID structure and the SRv6 Endpoint Behavior of the BSID. 11.2. Information and Data Models The PCEP YANG module [I-D.ietf-pce-pcep-yang] will be extended to include policy configuration for binding label/SID allocation. 11.3. Liveness Detection and Monitoring The mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440]. 11.4. Verify Correct Operations The mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440], [RFC8231], and [RFC8664]. 11.5. Requirements On Other Protocols The mechanisms defined in this document do not imply any new requirements on other protocols. 11.6. Impact On Network Operations The mechanisms defined in [RFC5440], [RFC8231], and [RFC8664] also apply to the PCEP extensions defined in this document. 12. IANA Considerations IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry. This document requests IANA actions to allocate code points for the protocol elements defined in this document. 12.1. PCEP TLV Type Indicators This document defines a new PCEP TLV; IANA is requested to confirm the following early allocations from the "PCEP TLV Type Indicators" subregistry of the PCEP Numbers registry, as follows: Sivabalan, et al. Expires 21 September 2022 [Page 17] Internet-Draft Binding Label/SID March 2022 +=======+=================+===============+ | Value | Description | Reference | +=======+=================+===============+ +-------+-----------------+---------------+ | 55 | TE-PATH-BINDING | This document | +-------+-----------------+---------------+ Table 1 12.1.1. TE-PATH-BINDING TLV IANA is requested to create a new subregistry "TE-PATH-BINDING TLV BT field" to manage the value of the Binding Type field in the TE-PATH- BINDING TLV. Initial values for the subregistry are given below. New values are assigned by Standards Action [RFC8126]. +=======+======================================+===============+ | Value | Description | Reference | +=======+======================================+===============+ +-------+--------------------------------------+---------------+ | 0 | MPLS Label | This document | +-------+--------------------------------------+---------------+ | 1 | MPLS Label Stack Entry | This document | +-------+--------------------------------------+---------------+ | 2 | SRv6 SID | This document | +-------+--------------------------------------+---------------+ | 3 | SRv6 SID with Behavior and Structure | This document | +-------+--------------------------------------+---------------+ | 4-255 | Unassigned | This document | +-------+--------------------------------------+---------------+ Table 2 IANA is requested to create a new subregistry "TE-PATH-BINDING TLV Flag field" to manage the Flag field in the TE-PATH-BINDING TLV. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: * Bit number (count from 0 as the most significant bit) * Description * Reference Sivabalan, et al. Expires 21 September 2022 [Page 18] Internet-Draft Binding Label/SID March 2022 +=====+=============+===============+ | Bit | Description | Reference | +=====+=============+===============+ +-----+-------------+---------------+ | 0 | R (Removal) | This document | +-----+-------------+---------------+ | 1-7 | Unassigned | This document | +-----+-------------+---------------+ Table 3 12.2. LSP Object IANA is requested to confirm the early allocation for a new code- point in the "LSP Object Flag Field" sub-registry for the new P flag as follows: +=====+================+===============+ | Bit | Description | Reference | +=====+================+===============+ +-----+----------------+---------------+ | 0 | PCE-allocation | This document | +-----+----------------+---------------+ Table 4 12.3. PCEP Error Type and Value This document defines a new Error-type and associated Error-Values for the PCErr message. IANA is requested to allocate new error-type and error-values within the "PCEP-ERROR Object Error Types and Values" subregistry of the PCEP Numbers registry, as follows: Sivabalan, et al. Expires 21 September 2022 [Page 19] Internet-Draft Binding Label/SID March 2022 +============+================+========================+===========+ | Error-Type | Meaning | Error-value | Reference | +============+================+========================+===========+ +------------+----------------+------------------------+-----------+ | TBD2 | Binding label/ | 0: Unassigned | This | | | SID failure | | document | +------------+----------------+------------------------+-----------+ | | | TBD3: Invalid SID | This | | | | | document | +------------+----------------+------------------------+-----------+ | | | TBD4: Unable to | This | | | | allocate the specified | document | | | | binding value | | +------------+----------------+------------------------+-----------+ | | | TBD5: Unable to | This | | | | allocate a new binding | document | | | | label/SID | | +------------+----------------+------------------------+-----------+ | | | TBD6: Unable to remove | This | | | | the binding value | document | +------------+----------------+------------------------+-----------+ | | | TBD7: Inconsistent | This | | | | binding types | document | +------------+----------------+------------------------+-----------+ Table 5 13. Acknowledgements We would like to thank Milos Fabian, Mrinmoy Das, Andrew Stone, Tom Petch, Aijun Wang, Olivier Dugeon, and Adrian Farrel for their valuable comments. Thanks to Julien Meuric for shepherding. Thanks to John Scudder for the AD review. Thanks to Theresa Enghardt for the GENART review. Thanks to Martin Vigoureux, Benjamin Kaduk, Eric Vyncke, Lars Eggert, Murray Kucherawy, and Erik Kline for the IESG reviews. 14. References 14.1. Normative References Sivabalan, et al. Expires 21 September 2022 [Page 20] Internet-Draft Binding Label/SID March 2022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, . Sivabalan, et al. Expires 21 September 2022 [Page 21] Internet-Draft Binding Label/SID March 2022 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs", RFC 9050, DOI 10.17487/RFC9050, July 2021, . [I-D.ietf-pce-segment-routing-ipv6] Li, C., Negi, M., Sivabalan, S., Koldychev, M., Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment Routing leveraging the IPv6 data plane", Work in Progress, Internet-Draft, draft-ietf-pce-segment-routing-ipv6-12, 6 March 2022, . 14.2. Informative References Sivabalan, et al. Expires 21 September 2022 [Page 22] Internet-Draft Binding Label/SID March 2022 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control", RFC 8283, DOI 10.17487/RFC8283, December 2017, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", Work in Progress, Internet-Draft, draft-ietf-spring-segment- routing-policy-21, 19 March 2022, . [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-yang-18, 25 January 2022, . [I-D.li-pce-controlled-id-space] Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE Controlled ID Space", Work in Progress, Internet-Draft, draft-li-pce-controlled-id-space-10, 24 February 2022, . [I-D.ietf-pce-sr-path-segment] Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, "Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR)", Work in Progress, Internet-Draft, draft-ietf-pce-sr-path- segment-05, 13 February 2022, . Sivabalan, et al. Expires 21 September 2022 [Page 23] Internet-Draft Binding Label/SID March 2022 Appendix A. Contributor Addresses Jonathan Hardwick Microsoft United Kingdom EMail: jonhardwick@microsoft.com Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India EMail: dhruv.ietf@gmail.com Mahendra Singh Negi RtBrick India N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 Bangalore, Karnataka 560102 India EMail: mahend.ietf@gmail.com Mike Koldychev Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: mkoldych@cisco.com Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com Authors' Addresses Siva Sivabalan Ciena Corporation Email: msiva282@gmail.com Sivabalan, et al. Expires 21 September 2022 [Page 24] Internet-Draft Binding Label/SID March 2022 Clarence Filsfils Cisco Systems, Inc. Pegasus Parc BRABANT 1831 De kleetlaan 6a Belgium Email: cfilsfil@cisco.com Jeff Tantsura Microsoft Corporation Email: jefftant.ietf@gmail.com Stefano Previdi Huawei Technologies Email: stefano@previdi.net Cheng Li (editor) Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: c.l@huawei.com Sivabalan, et al. Expires 21 September 2022 [Page 25] ./draft-ietf-add-svcb-dns-07.txt0000644000764400076440000006112614275373562016144 0ustar iustiniustin add B. Schwartz Internet-Draft Google LLC Intended status: Standards Track 12 August 2022 Expires: 13 February 2023 Service Binding Mapping for DNS Servers draft-ietf-add-svcb-dns-07 Abstract The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the ADD Working Group mailing list (add@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/add/. Source for this draft and an issue tracker can be found at https://github.com/bemasc/svcb-dns. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 13 February 2023. Schwartz Expires 13 February 2023 [Page 1] Internet-Draft SVCB for DNS August 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Identities and Names . . . . . . . . . . . . . . . . . . . . 3 3.1. Special case: non-default ports . . . . . . . . . . . . . 4 4. Applicable existing SvcParamKeys . . . . . . . . . . . . . . 4 4.1. alpn . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. port . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Other applicable SvcParamKeys . . . . . . . . . . . . . . 5 5. New SvcParamKeys . . . . . . . . . . . . . . . . . . . . . . 5 5.1. dohpath . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8.1. Adversary on the query path . . . . . . . . . . . . . . . 8 8.1.1. Downgrade attacks . . . . . . . . . . . . . . . . . . 8 8.1.2. Redirection attacks . . . . . . . . . . . . . . . . . 8 8.2. Adversary on the transport path . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Mapping Summary . . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Schwartz Expires 13 February 2023 [Page 2] Internet-Draft SVCB for DNS August 2022 1. Introduction The SVCB resource record type [SVCB] provides clients with information about how to reach alternative endpoints for a service, which may have improved performance or privacy properties. The service is identified by a "scheme" indicating the service type, a hostname, and optionally other information such as a port number. A DNS server is often identified only by its IP address (e.g., in DHCP), but in some contexts it can also be identified by a hostname (e.g., "NS" records, manual resolver configuration) and sometimes also a non-default port number. Use of the SVCB resource record type requires a mapping document for each service type (Section 2.4.3 of [SVCB]), indicating how a client for that service can interpret the contents of the SVCB SvcParams. This document provides the mapping for the "dns" service type, allowing DNS servers to offer alternative endpoints and transports, including encrypted transports like DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) [RFC8484], and DNS over QUIC (DoQ) [RFC9250]. The SVCB mapping described in this document is intended as a general- purpose baseline. Subsequent specifications will adapt this mechanism as needed to support specific configurations (e.g., for communication between stub and recursive resolvers). 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Identities and Names SVCB record names (i.e., QNAMEs) for DNS services are formed using Port-Prefix Naming (Section 2.3 of [SVCB]), with a scheme of "dns". For example, SVCB records for a DNS service identified as dns1.example.com would be queried at _dns.dns1.example.com. In some use cases, the name used for retrieving these DNS records is different from the server identity used to authenticate the secure transport. To distinguish between these, this document uses the following terms: * Binding authority - The service name (Section 1.4 of [SVCB]) and optional port number used as input to Port-Prefix Naming. Schwartz Expires 13 February 2023 [Page 3] Internet-Draft SVCB for DNS August 2022 * Authentication name - The name used for secure transport authentication. This MUST be a DNS hostname or a literal IP address. Unless otherwise specified, this is the service name from the binding authority. 3.1. Special case: non-default ports Normally, a DNS service is identified by an IP address or a domain name. When connecting to the service using unencrypted DNS over UDP or TCP, clients use the default port number for DNS (53). However, in rare cases, a DNS service might be identified by both a name and a port number. For example, the "dns:" URI scheme [DNSURI] optionally includes an authority, comprised of a host and a port number (with a default of 53). DNS URIs normally omit the authority, or specify an IP address, but a hostname and non-default port number are allowed. When the binding authority specifies a non-default port number, Port- Prefix Naming places the port number in an additional prefix on the name. For example, if the binding authority is "dns1.example.com:9953", the client would query for SVCB records at _9953._dns.dns1.example.com. If two DNS services operating on different port numbers provide different behaviors, this arrangement allows them to preserve the distinction when specifying alternative endpoints. 4. Applicable existing SvcParamKeys 4.1. alpn This key indicates the set of supported protocols (Section 6.1 of [SVCB]). There is no default protocol, so the "no-default-alpn" key does not apply, and the "alpn" key MUST be present. If the protocol set contains any HTTP versions (e.g., "h2", "h3"), then the record indicates support for DoH, and the "dohpath" key MUST be present (Section 5.1). All keys specified for use with the HTTPS record are also permissible, and apply to the resulting HTTP connection. If the protocol set contains protocols with different default ports, and no port key is specified, then protocols are contacted separately on their default ports. Note that in this configuration, ALPN negotiation does not defend against cross-protocol downgrade attacks. Schwartz Expires 13 February 2023 [Page 4] Internet-Draft SVCB for DNS August 2022 4.2. port This key is used to indicate the target port for connection (Section 6.2 of [SVCB]). If omitted, the client SHALL use the default port number for each transport protocol (853 for DoT and DoQ, 443 for DoH). This key is automatically mandatory for this binding. This means that a client that does not respect the "port" key MUST ignore any SVCB record that contains this key. (See Section 7 of [SVCB] for the definition of "automatically mandatory".) Support for the "port" key can be unsafe if the client has implicit elevated access to some network service (e.g., a local service that is inaccessible to remote parties) and that service uses a TCP-based protocol other than TLS. A hostile DNS server might be able to manipulate this service by causing the client to send a specially crafted TLS SNI or session ticket that can be misparsed as a command or exploit. To avoid such attacks, clients SHOULD NOT support the "port" key unless one of the following conditions applies: * The client is being used with a DNS server that it trusts not to attempt this attack. * The client is being used in a context where implicit elevated access cannot apply. * The client restricts the set of allowed TCP port values to exclude any ports where a confusion attack is likely to be possible (e.g., the "bad ports" list from the "Port blocking" section of [FETCH]). 4.3. Other applicable SvcParamKeys These SvcParamKeys from [SVCB] apply to the "dns" scheme without modification: * mandatory * ech * ipv4hint * ipv6hint Future SvcParamKeys might also be applicable. 5. New SvcParamKeys Schwartz Expires 13 February 2023 [Page 5] Internet-Draft SVCB for DNS August 2022 5.1. dohpath "dohpath" is a single-valued SvcParamKey whose value (both in presentation and wire format) MUST be a URI Template in relative form ([RFC6570], Section 1.1) encoded in UTF-8 [RFC3629]. If the "alpn" SvcParam indicates support for HTTP, "dohpath" MUST be present. The URI Template MUST contain a "dns" variable, and MUST be chosen such that the result after DoH template expansion (Section 6 of [RFC8484]) is always a valid and functional ":path" value ([RFC9113], Section 8.3.1). When using this SVCB record, the client MUST send any DoH requests to the HTTP origin identified by the "https" scheme, the authentication name, and the port from the "port" SvcParam (if present). HTTP requests MUST be directed to the resource resulting from DoH template expansion of the "dohpath" value. Clients SHOULD NOT query for any "HTTPS" RRs when using "dohpath". Instead, the SvcParams and address records associated with this SVCB record SHOULD be used for the HTTPS connection, with the same semantics as an HTTPS RR. However, for consistency, service operators SHOULD publish an equivalent HTTPS RR, especially if clients might learn about this DoH service through a different channel. 6. Limitations This document is concerned exclusively with the DNS transport, and does not affect or inform the construction or interpretation of DNS messages. For example, nothing in this document indicates whether the service is intended for use as a recursive or authoritative DNS server. Clients need to know the intended use of services based on their context. Not all features of this specification will be applicable or effective in all contexts: * If the authentication name is received over an insecure channel (e.g., a glue NS record), this specification cannot prevent the client from connecting to an attacker. * Different transports might prove to be popular for different purposes (e.g., stub resolution vs. iterative resolution). Implementors are not obligated to implement all the defined transports, although doing so is beneficial for compatibility. Schwartz Expires 13 February 2023 [Page 6] Internet-Draft SVCB for DNS August 2022 * Where resolution speed is a high priority, the SVCB TargetName SHOULD follow the convention described in Section 11.2 of [SVCB], and the use of AliasMode records (Section 2.4.2 of [SVCB]) is NOT RECOMMENDED. 7. Examples * A resolver known as simple.example that supports DNS over TLS on port 853 (implicitly, as this is its default port): _dns.simple.example. 7200 IN SVCB 1 simple.example. alpn=dot * A DoH-only resolver at https://doh.example/dns-query{?dns}. (DNS over TLS is not supported.): _dns.doh.example. 7200 IN SVCB 1 doh.example. ( alpn=h2 dohpath=/dns-query{?dns} ) * A resolver known as resolver.example that supports: - DoT on resolver.example ports 853 (implicit in record 1) and 8530 (explicit in record 2), with "resolver.example" as the Authentication Domain Name, - DoQ on resolver.example port 853 (record 1), - DoH at https://resolver.example/dns-query{?dns} (record 1), and - an experimental protocol on fooexp.resolver.example:5353 (record 3): _dns.resolver.example. 7200 IN SVCB 1 resolver.example. ( alpn=dot,doq,h2,h3 dohpath=/dns-query{?dns} ) _dns.resolver.example. 7200 IN SVCB 2 resolver.example. ( alpn=dot port=8530 ) _dns.resolver.example. 7200 IN SVCB 3 fooexp ( port=5353 alpn=foo foo-info=... ) * A nameserver named ns.example. whose service configuration is published on a different domain: _dns.ns.example. 7200 IN SVCB 0 _dns.ns.nic.example. 8. Security Considerations Schwartz Expires 13 February 2023 [Page 7] Internet-Draft SVCB for DNS August 2022 8.1. Adversary on the query path This section considers an adversary who can add or remove responses to the SVCB query. During secure transport establishment, clients MUST authenticate the server to its authentication name, which is not influenced by the SVCB record contents. Accordingly, this draft does not mandate the use of DNSSEC. This draft also does not specify how clients authenticate the name (e.g., selection of roots of trust), which might vary according to the context. 8.1.1. Downgrade attacks This attacker cannot impersonate the secure endpoint, but it can forge a response indicating that the requested SVCB records do not exist. For a SVCB-reliant client ([SVCB], Section 3) this only results in a denial of service. However, SVCB-optional clients will generally fall back to insecure DNS in this case, exposing all DNS traffic to attacks. 8.1.2. Redirection attacks SVCB-reliant clients always enforce the authentication domain name, but they are still subject to attacks using the transport, port number, and "dohpath" value, which are controlled by this adversary. By changing these values in the SVCB answers, the adversary can direct DNS queries for $HOSTNAME to any port on $HOSTNAME, and any path on "https://$HOSTNAME". If the DNS client uses shared TLS or HTTP state, the client could be correctly authenticated (e.g., using a TLS client certificate or HTTP cookie). This behavior creates a number of possible attacks for certain server configurations. For example, if https://$HOSTNAME/upload accepts any POST request as a public file upload, the adversary could forge a SVCB record containing dohpath=/upload{?dns}. This would cause the client to upload and publish every query, resulting in unexpected storage costs for the server and privacy loss for the client. Similarly, if two DoH endpoints are available on the same origin, and the service has designated one of them for use with this specification, this adversary can cause clients to use the other endpoint instead. To mitigate redirection attacks, a client of this SVCB mapping MUST NOT identify or authenticate itself when performing DNS queries, except to servers that it specifically knows are not vulnerable to such attacks. If an endpoint sends an invalid response to a DNS query, the client SHOULD NOT send more queries to that endpoint. Schwartz Expires 13 February 2023 [Page 8] Internet-Draft SVCB for DNS August 2022 Multiple DNS services MUST NOT share a hostname identifier (Section 3) unless they are so similar that it is safe to allow an attacker to choose which one is used. 8.2. Adversary on the transport path This section considers an adversary who can modify network traffic between the client and the alternative service (identified by the TargetName). For a SVCB-reliant client, this adversary can only cause a denial of service. However, because DNS is unencrypted by default, this adversary can execute a downgrade attack against SVCB-optional clients. Accordingly, when use of this specification is optional, clients SHOULD switch to SVCB-reliant behavior if SVCB resolution succeeds. Specifications making using of this mapping MAY adjust this fallback behavior to suit their requirements. 9. IANA Considerations Per [SVCB] IANA is directed to add the following entry to the SVCB Service Parameters registry. +========+=========+==============================+=================+ | Number | Name | Meaning | Reference | +========+=========+==============================+=================+ | 7 | dohpath | DNS over HTTPS path template | (This | | | | | document) | +--------+---------+------------------------------+-----------------+ Table 1 Per [Attrleaf], IANA is directed to add the following entry to the DNS Underscore Global Scoped Entry Registry: +=========+============+=================+ | RR TYPE | _NODE NAME | Reference | +=========+============+=================+ | SVCB | _dns | (This document) | +---------+------------+-----------------+ Table 2 10. References 10.1. Normative References Schwartz Expires 13 February 2023 [Page 9] Internet-Draft SVCB for DNS August 2022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, . [SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- dnsop-svcb-https-10, 24 May 2022, . 10.2. Informative References [Attrleaf] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, . [DNSURI] Josefsson, S., "Domain Name System Uniform Resource Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006, . [FETCH] "Fetch Living Standard", February 2022, . Schwartz Expires 13 February 2023 [Page 10] Internet-Draft SVCB for DNS August 2022 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, . Appendix A. Mapping Summary This table serves as a non-normative summary of the DNS mapping for SVCB. +=================+====================================+ +=================+====================================+ | *Mapped scheme* | "dns" | +-----------------+------------------------------------+ | *RR type* | SVCB (64) | +-----------------+------------------------------------+ | *Name prefix* | _dns for port 53, else _$PORT._dns | +-----------------+------------------------------------+ | *Required keys* | alpn | +-----------------+------------------------------------+ | *Automatically | port | | Mandatory Keys* | | +-----------------+------------------------------------+ | *Special | Supports all HTTPS RR SvcParamKeys | | behaviors* | | +-----------------+------------------------------------+ | | Overrides the HTTPS RR for DoH | +-----------------+------------------------------------+ | | Default port is per-transport | +-----------------+------------------------------------+ | | No encrypted -> cleartext fallback | +-----------------+------------------------------------+ Table 3 Acknowledgments Thanks to the many reviewers and contributors, including Andrew Campling, Peter van Dijk, Paul Hoffman, Daniel Migault, Matt Norhoff, Eric Rescorla, Andreas Schulze, and Eric Vyncke. Author's Address Schwartz Expires 13 February 2023 [Page 11] Internet-Draft SVCB for DNS August 2022 Benjamin Schwartz Google LLC Email: bemasc@google.com Schwartz Expires 13 February 2023 [Page 12] ./draft-ietf-jmap-blob-18.txt0000644000764400076440000013234014355224233015526 0ustar iustiniustin JMAP B. Gondwana, Ed. Internet-Draft Fastmail Updates: 8620 (if approved) 4 January 2023 Intended status: Standards Track Expires: 8 July 2023 JMAP Blob management extension draft-ietf-jmap-blob-18 Abstract The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data via HTTP POST and GET on defined endpoint. This binary data is called a "blob". This extension adds additional ways to create and access blobs, by making inline method calls within a standard JMAP request. This extension also adds a reverse lookup mechanism to discover where blobs are referenced within other data types. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 July 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Gondwana Expires 8 July 2023 [Page 1] Internet-Draft JMAP Blob January 2023 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 3. Addition to the Capabilities Object . . . . . . . . . . . . . 3 3.1. urn:ietf:params:jmap:blob . . . . . . . . . . . . . . . . 3 3.1.1. Capability Example . . . . . . . . . . . . . . . . . 4 4. Blob Methods . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Blob/upload . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Blob/upload simple example . . . . . . . . . . . . . 8 4.1.2. Blob/upload complex example . . . . . . . . . . . . . 9 4.2. Blob/get . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. Blob/get simple example . . . . . . . . . . . . . . . 13 4.2.2. Blob/get example with range and encoding errors . . . 15 4.3. Blob/lookup . . . . . . . . . . . . . . . . . . . . . . . 20 4.3.1. Blob/lookup example . . . . . . . . . . . . . . . . . 21 5. Security considerations . . . . . . . . . . . . . . . . . . . 23 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 6.1. JMAP Capability registration for "blob" . . . . . . . . . 23 6.2. JMAP Error Codes Registration for "unknownDataType" . . . 24 6.3. Creation of "JMAP Data Types" Registry . . . . . . . . . 24 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 9. Normative References . . . . . . . . . . . . . . . . . . . . 29 10. Informative References . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction Sometimes JMAP ([RFC8620]) interactions require creating a blob and then referencing it. In the same way that IMAP Literals were extended by [RFC7888], embedding small blobs directly into the JMAP method calls array can be an option for reducing roundtrips. Likewise, when fetching an object, it can be useful to also fetch the raw content of that object without a separate roundtrip. Since raw blobs may contain arbitrary binary data, this document defines a use of the base64 coding specified in [RFC4648] for both creating and fetching blob data. Gondwana Expires 8 July 2023 [Page 2] Internet-Draft JMAP Blob January 2023 Where JMAP is being proxied through a system which applies additional access restrictions, it can be useful to know which objects reference any particular blob, and this document defines a way to discover those references. 2. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The definitions of JSON keys and datatypes in the document follow the conventions described in the core JMAP specification [RFC8620]. 3. Addition to the Capabilities Object The capabilities object is returned as part of the JMAP Session object; see [RFC8620], Section 2. This document defines an additional capability URI. 3.1. urn:ietf:params:jmap:blob The capability urn:ietf:params:jmap:blob being present in the "accountCapabilities" property of an account represents support for additional API methods on the Blob datatype. Servers that include the capability in one or more "accountCapabilities" properties MUST also include the property in the "capabilities" property. The value of this property in the JMAP session "capabilities" property MUST be an empty object. The value of this property in an account's "accountCapabilities" property is an object that MUST contain the following information on server capabilities and permissions for that account: * maxSizeBlobSet: UnsignedInt|null This is the maximum size of blob (in octets) that the server will allow to be created (including blobs created by concatenating multiple data sources together). Clients MUST NOT attempt to create blobs larger than this size. Gondwana Expires 8 July 2023 [Page 3] Internet-Draft JMAP Blob January 2023 If this value is null, then clients are not required to limit the size of blob they try to create, though servers can always reject creation of blobs regardless of size; e.g. due to lack of disk space, or per-user rate limits. * maxDataSources: UnsignedInt The maximum number of DataSourceObjects allowed per creation in a Blob/upload. Servers MUST allow at least 64 DataSourceObjects per creation. * supportedTypeNames: String[] An array of data type names that are supported for Blob/lookup. If the server does not support lookups then this will be the empty list. NOTE, the supportedTypeNames list may include private types which are not in the JMAP Types Registry defined by this document. Clients MUST ignore type names they do not recognise. * supportedDigestAlgorithms: String[] An array of supported digest algorithms that are supported for Blob/get. If the server does not support calculating blob digests, then this will be the empty list. Algorithms in this list MUST be present in the HTTP Digest Algorithms registry defined by [RFC3230], and are always lowercased. Clients SHOULD prefer algorithms listed earlier in this list. 3.1.1. Capability Example Gondwana Expires 8 July 2023 [Page 4] Internet-Draft JMAP Blob January 2023 { "capabilities": { ..., "urn:ietf:params:jmap:blob": {} }, "accounts": { "A13842": { ... "accountCapabilities": { "urn:ietf:params:jmap:blob": { "maxSizeBlobSet": 50000000, "maxDataSources": 100, "supportedTypeNames" : [ "Mailbox", "Thread", "Email" ], "supportedDigestAlgorithms" : [ "sha", "sha-256" ] } } } } } 4. Blob Methods A blob is a sequence of zero or more octets. The JMAP base spec [RFC8620] defines the Blob/copy method, which is unchanged by this specification, and is selected by the urn:ietf:params:jmap:core capability. The following JMAP Methods are selected by the urn:ietf:params:jmap:blob capability. 4.1. Blob/upload This is similar to a Foo/set from [RFC8620] in some ways, however blobs can not be updated or deleted, so only create is allowed in the method call, and blobs do not have state, so there is no state field present in the method response. *Parameters* * accountId: Id Gondwana Expires 8 July 2023 [Page 5] Internet-Draft JMAP Blob January 2023 The id of the account in which the blobs will be created. * create: Id[UploadObject] A map of creation id to UploadObjects. *Result* The result is the same as for Foo/set in RFC8620, with created and notCreated objects mapping from the creationId. The created objects contain: * id: Id the blobId which was created * type: String|null the media type as given in the creation (if any); or detected from content by the server; or null * size: UnsignedInt as per RFC8620 - the size of the created blob in octets It will also contain any other properties identical to those that would be returned in the JSON response of the RFC8620 upload endpoint (which may be extended in the future - this document anticipates that implementations will extend both the upload endpoint and the Blob/ upload responses in the same way) Or if there is a problem with a creation, then the server will return a notCreated response with a map from the failed creationId to a SetError object. For each successful upload, servers MUST add an entry to the creationIds map for the request. This allows the blob id to be used via back-reference in subsequent method calls. The created blob will have the same lifetime and same expiry semantics as any other binary object created via the mechanism specified in [!@RFC8620] section 6. Uploads using with this mechanism will be restricted by the maxUploadSize limit for JMAP requests specified by the server, and clients SHOULD consider using the upload mechanism defined by [!@RFC8620] for blobs larger than a megabyte. Gondwana Expires 8 July 2023 [Page 6] Internet-Draft JMAP Blob January 2023 *UploadObject* * data: DataSourceObject[] an array of zero or more octet sources in order (zero to create an empty blob). The result of each of these sources is concatenated together in order to create the blob. * type: String|null (default: null) hint for media type of the data *DataSourceObject* Exactly one of: * data:asText: String|null (raw octets, must be UTF-8) * data:asBase64: String|null (base64 representation of octets) or a blobId source: * blobId: Id * offset: UnsignedInt|null (MAY be zero) * length: UnsignedInt|null (MAY be zero) If null then offset is assumed to be zero. If null then length is the remaining octets in the blob. If the range can not be fully satisfied (i.e. begins or extends past the end of the data in the blob) then the DataSourceObject is invalid and results in a notCreated response for this creation id. If the data properties have any invalid references or invalid data contained in them, the server MUST NOT guess as to the user's intent, and MUST reject the creation and return a notCreated response for that creation id. Likewise, invalid characters in the base64 of data:asBase64, or invalid UTF-8 in data:asText MUST result in a nonCreated response. It is envisaged that the definition for DataSourceObject might be extended in the future, for example to fetch external content. Gondwana Expires 8 July 2023 [Page 7] Internet-Draft JMAP Blob January 2023 A server MUST accept at least 64 DataSourceObjects per create, as described in Section 3.1 of this document. 4.1.1. Blob/upload simple example The data:asBase64 field is set over multiple lines for ease of publication here, however all data:asBase64 would be sent as a continuous string with no whitespace on the wire. Method Call: [ "Blob/upload", { "accountId": "account1", "create": { "1": { "data" : [ { "data:asBase64": "iVBORw0KGgoAAAANSUhEUgAAAAEAAAABAQMAAAAl21bKA AAAA1BMVEX/AAAZ4gk3AAAAAXRSTlN/gFy0ywAAAApJRE FUeJxjYgAAAAYAAzY3fKgAAAAASUVORK5CYII=", } ], "type": "image/png" }, }, }, "R1" ] Response: [ "Blob/upload", { "accountId" : "account1", "created" : { "1": { "id" : "G4c6751edf9dd6903ff54b792e432fba781271beb", "type" : "image/png", "size" : 95 }, }, }, "R1" ] Gondwana Expires 8 July 2023 [Page 8] Internet-Draft JMAP Blob January 2023 4.1.2. Blob/upload complex example Method Calls: [ [ "Blob/upload", { "create": { "b4": { "data": [ { "data:asText": "The quick brown fox jumped over the lazy dog." } ] } } }, "S4" ], [ "Blob/upload", { "create": { "cat": { "data": [ { "data:asText": "How" }, { "blobId": "#b4", "length": 7, "offset": 3 }, { "data:asText": "was t" }, { "blobId": "#b4", "length": 1, "offset": 1 }, { "data:asBase64": "YXQ/" } ] } } Gondwana Expires 8 July 2023 [Page 9] Internet-Draft JMAP Blob January 2023 }, "CAT" ], [ "Blob/get", { "properties": [ "data:asText", "size" ], "ids": [ "#cat" ] }, "G4" ] ] Responses: [ [ "Blob/upload", { "oldState": null, "created": { "b4": { "id": "Gc0854fb9fb03c41cce3802cb0d220529e6eef94e", "size": 45, "type": "application/octet-stream" } }, "notCreated": null, "accountId": "account1" }, "S4" ], [ "Blob/upload", { "oldState": null, "created": { "cat": { "id": "Gcc60576f036321ae6e8037ffc56bdee589bd3e23", "size": 19, "type": "application/octet-stream" } }, Gondwana Expires 8 July 2023 [Page 10] Internet-Draft JMAP Blob January 2023 "notCreated": null, "accountId": "account1" }, "CAT" ], [ "Blob/get", { "list": [ { "id": "Gcc60576f036321ae6e8037ffc56bdee589bd3e23", "data:asText": "How quick was that?", "size": 19 } ], "notFound": [], "accountId": "account1" }, "G4" ] ] 4.2. Blob/get A standard JMAP get, with two additional optional parameters: * offset: UnsignedInt|null start this many octets into the blob data. If null or unspecified, this defaults to zero. * length: UnsignedInt|null return at most this many octets of the blob data. If null or unspecified, then all remaining octets in the blob are returned. This can be considered equivalent to an infinitely large length value, except that the isTruncated warning is not given unless the start offset is past the end of the blob. *Request Properties:* Any of * data:asText * data:asBase64 * data (returns data:asText if the selected octets are valid UTF-8, or data:asBase64) Gondwana Expires 8 July 2023 [Page 11] Internet-Draft JMAP Blob January 2023 * digest: (where is one of the named algorithms in the supportedDigestAlgorithms capability) * size If not given, properties defaults to data and size. *Result Properties:* * data:asText: String|null the raw octets of the selected range if they are valid UTF-8, otherwise null * data:asBase64: String the base64 encoding of the octets in the selected range * digest: String the base64 encoding of the digest of the octets in the selected range, calculated using the named algorithm * isEncodingProblem: Boolean (default: false) * isTruncated: Boolean (default: false) * size: UnsignedInt the number of octets in the entire blob The size value MUST always be the number of octets in the underlying blob, regardless of offset and length. The data fields contain a representation of the octets within the selected range that are present in the blob. If the octets selected are not valid UTF-8 (including truncating in the middle of a multi- octet sequence) and data or data:asText was requested, then the key isEncodingProblem MUST be set to true and the data:asText response value MUST be null. In the case where data was requested and the data is not valid UTF-8, then data:asBase64 MUST be returned. Gondwana Expires 8 July 2023 [Page 12] Internet-Draft JMAP Blob January 2023 If the selected range requests data outside the blob (i.e. the offset+length is larger than the blob) then the result is either just the octets from the offset to the end of the blob, or an empty string if the offset is past the end of the blob. Either way, the isTruncated property in the result MUST be set to true to tell the client that the requested range could not be fully satisfied. If digest was requested, any digest is calculated on the octets that would be returned for a data field. Servers SHOULD store the size for blobs in a format which is efficient to read, and clients SHOULD limit their request to just the size parameter if that is all they need, as fetching blob content could be significantly more expensive and slower for the server. 4.2.1. Blob/get simple example Where a blob containing the string "The quick brown fox jumped over the lazy dog." has blobId Gc0854fb9fb03c41cce3802cb0d220529e6eef94e. The first method call requests just the size for multiple blobs, and the second requests both size and a short range of the data for one of the blobs. Method Calls: [ [ "Blob/get", { "accountId" : "account1", "ids" : [ "Gc0854fb9fb03c41cce3802cb0d220529e6eef94e", "not-a-blob" ], "properties" : [ "data:asText", "digest:sha", "size" ] }, "R1" ], [ "Blob/get", { "accountId" : "account1", "ids" : [ "Gc0854fb9fb03c41cce3802cb0d220529e6eef94e" Gondwana Expires 8 July 2023 [Page 13] Internet-Draft JMAP Blob January 2023 ], "properties" : [ "data:asText", "digest:sha", "digest:sha-256", "size" ], "offset" : 4, "length" : 9 }, "R2" ] ] Responses: [ [ "Blob/get", { "accountId": "account1", "list": [ { "id": "Gc0854fb9fb03c41cce3802cb0d220529e6eef94e", "data:asText": "The quick brown fox jumped over the lazy dog.", "digest:sha": "wIVPufsDxBzOOALLDSIFKebu+U4=", "size": 45 } ], "notFound": [ "not-a-blob" ] }, "R1" ], [ "Blob/get", { "accountId": "account1", "list": [ { "id": "Gc0854fb9fb03c41cce3802cb0d220529e6eef94e", "data:asText": "quick bro", "digest:sha": "QiRAPtfyX8K6tm1iOAtZ87Xj3Ww=", "digest:sha-256": "gdg9INW7lwHK6OQ9u0dwDz2ZY/gubi0En0xlFpKt0OA=", "size": 45 } ] Gondwana Expires 8 July 2023 [Page 14] Internet-Draft JMAP Blob January 2023 }, "R2" ] ] 4.2.2. Blob/get example with range and encoding errors The b1 value is the text: "The quick brown fox jumped over the \x81\x81 fox" which contains an invalid utf8 sequence. The results have the following interesting properties: * G1: defaults to data and size - so b1 returns isEncodingProblem and a base64 value. * G2: since data:asText was explicitly selected, does not attempt to return a value for the data, just isEncodingProblem for b1. * G3: since only data:asBase64 was requested, there is no encoding problem and both values are returned. * G4: since the requested range could be satisfied as text, both blobs are returned as data:asText and there is no encoding problem. * G5: both blobs cannot satisfy the requested range, so isTruncated is true for both. Note: some values have been wrapped for line length - there would be no whitespace in the data:asBase64 values on the wire Method calls: [ [ "Blob/upload", { "create": { "b1": { "data": [ { "data:asBase64": "VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZW Qgb3ZlciB0aGUggYEgZG9nLg==" } ] }, "b2": { "data": [ Gondwana Expires 8 July 2023 [Page 15] Internet-Draft JMAP Blob January 2023 { "data:asText": "hello world" } ], "type" : "text/plain" } } }, "S1" ], [ "Blob/get", { "ids": [ "#b1", "#b2" ] }, "G1" ], [ "Blob/get", { "ids": [ "#b1", "#b2" ], "properties": [ "data:asText", "size" ] }, "G2" ], [ "Blob/get", { "ids": [ "#b1", "#b2" ], "properties": [ "data:asBase64", "size" ] }, "G3" ], Gondwana Expires 8 July 2023 [Page 16] Internet-Draft JMAP Blob January 2023 [ "Blob/get", { "offset": 0, "length": 5, "ids": [ "#b1", "#b2" ] }, "G4" ], [ "Blob/get", { "offset": 20, "length": 100, "ids": [ "#b1", "#b2" ] }, "G5" ] ] Responses: [ [ "Blob/upload", { "oldState": null, "created": { "b2": { "id": "G2aae6c35c94fcfb415dbe95f408b9ce91ee846ed", "size": 11, "type": "application/octet-stream" }, "b1": { "id": "G72cfa4804194563685d9a4b695f7ba20e7739576", "size": 43, "type": "text/plain" } }, "updated": null, "destroyed": null, "notCreated": null, Gondwana Expires 8 July 2023 [Page 17] Internet-Draft JMAP Blob January 2023 "notUpdated": null, "notDestroyed": null, "accountId": "account1" }, "S1" ], [ "Blob/get", { "list": [ { "id": "G72cfa4804194563685d9a4b695f7ba20e7739576", "isEncodingProblem": true, "data:asBase64": "VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZW Qgb3ZlciB0aGUggYEgZG9nLg==", "size": 43 }, { "id": "G2aae6c35c94fcfb415dbe95f408b9ce91ee846ed", "data:asText": "hello world", "size": 11 } ], "notFound": [], "accountId": "account1" }, "G1" ], [ "Blob/get", { "list": [ { "id": "G72cfa4804194563685d9a4b695f7ba20e7739576", "isEncodingProblem": true, "size": 43 }, { "id": "G2aae6c35c94fcfb415dbe95f408b9ce91ee846ed", "data:asText": "hello world", "size": 11 } ], "notFound": [], "accountId": "account1" }, "G2" ], Gondwana Expires 8 July 2023 [Page 18] Internet-Draft JMAP Blob January 2023 [ "Blob/get", { "list": [ { "id": "G72cfa4804194563685d9a4b695f7ba20e7739576", "data:asBase64": "VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZW Qgb3ZlciB0aGUggYEgZG9nLg==", "size": 43 }, { "id": "G2aae6c35c94fcfb415dbe95f408b9ce91ee846ed", "data:asBase64": "aGVsbG8gd29ybGQ=", "size": 11 } ], "notFound": [], "accountId": "account1" }, "G3" ], [ "Blob/get", { "list": [ { "id": "G72cfa4804194563685d9a4b695f7ba20e7739576", "data:asText": "The q", "size": 43 }, { "id": "G2aae6c35c94fcfb415dbe95f408b9ce91ee846ed", "data:asText": "hello", "size": 11 } ], "notFound": [], "accountId": "account1" }, "G4" ], [ "Blob/get", { "list": [ { "id": "G72cfa4804194563685d9a4b695f7ba20e7739576", "isTruncated": true, Gondwana Expires 8 July 2023 [Page 19] Internet-Draft JMAP Blob January 2023 "isEncodingProblem": true, "data:asBase64": "anVtcGVkIG92ZXIgdGhlIIGBIGRvZy4=", "size": 43 }, { "id": "G2aae6c35c94fcfb415dbe95f408b9ce91ee846ed", "isTruncated": true, "data:asText": "", "size": 11 } ], "notFound": [], "accountId": "account1" }, "G5" ] ] 4.3. Blob/lookup Given a list of blobIds, this method does a reverse lookup in each of the provided type names to find the list of Ids within that data type which reference the provided blob. Since different datatypes will have different semantics of "contains", the definition of reference is somewhat loosely defined, but roughly means "you could discover this blobId by looking at this object or at other objects recursively contained within this object". For example with an [RFC8621] server, if checking whether a Mailbox references a blob, then if any Emails within that Mailbox reference the blobId, then the Mailbox references that blobId. For any Thread which references an Email that references a blobId, it can be said that the Thread references the blobId. But this does not mean that if an Email references a Mailbox in its mailboxIds property, then any blobId referenced by other Emails in that Mailbox are also referenced by the initial Email. *Parameters* * accountId: Id The id of the account used for the call. * typeNames: String[] Gondwana Expires 8 July 2023 [Page 20] Internet-Draft JMAP Blob January 2023 A list of names from the "JMAP Data Types" registry, or defined by private extensions which the client has requested. Only names for which "Can reference blobs" is true may be specified, and the capability which defines each type must also be used by the overall JMAP request in which this method is called. If a type name is not known by the server, or the associated capability has not been requested, then the server returns an "unknownDataType" error. * ids: Id[] A list of blobId values to be looked for. *Response* * list: BlobInfo[] A list of BlobInfo objects. *BlobInfo Object* * id: Id The Blob Identifier. * matchedIds: String[Id[]] A map from type name to list of Ids of that data type (e.g. the name "Email" maps to a list of emailIds) If a blob is not visible to a user, or does not exist on the server at all, then the server MUST still return an empty array for each type as this doesn't leak any information about whether the blob is on the server but not visible to the requesting user. 4.3.1. Blob/lookup example Gondwana Expires 8 July 2023 [Page 21] Internet-Draft JMAP Blob January 2023 Method call: [ "Blob/lookup", { "typeNames": [ "Mailbox", "Thread", "Email" ], "ids": [ "Gd2f81008cf07d2425418f7f02a3ca63a8bc82003", "not-a-blob" ] }, "R1" ] Response: [ "Blob/lookup", { "list": [ { "id": "Gd2f81008cf07d2425418f7f02a3ca63a8bc82003", "matchedIds": { "Mailbox": [ "M54e97373", "Mcbe6b662" ], "Thread": [ "T1530616e" ], "Email": [ "E16e70a73eb4", "E84b0930cf16" ] } } ], "notFound": [ "not-a-blob" ] }, "R1" ] Gondwana Expires 8 July 2023 [Page 22] Internet-Draft JMAP Blob January 2023 5. Security considerations All security considerations of JMAP [RFC8620] apply to this specification. Additional considerations specific to the data types and functionality introduced by this document are described here. JSON parsers are not all consistent in handling non-UTF-8 data. JMAP requires that all JSON data be UTF-8 encoded, so servers MUST only return a null value if data:asText is requested for a range of octets which is not valid UTF-8, and set isEncodingProblem: true. Servers MUST apply any access controls, such that if the authenticated user would be unable to discover the blobId by making queries, then this fact can not be discovered via a Blob/lookup. For example, if an Email exists in a Mailbox which the authenticated user does not have access to see, then that emailId MUST NOT be returned in a lookup for a blob which is referenced by that email. The server MUST NOT trust that the data given to a Blob/upload is a well formed instance of the specified media type, and if the server attempts to parse the given blob, only hardened parsers designed to deal with arbitrary untrusted data should be used. The server SHOULD NOT reject data on the grounds that it is not a valid specimen of the stated type. Blob/upload with carefully chosen data sources can be used to recreate dangerous content on the far side of security scanners (anti-virus or exfiltration scanners for example) which may be watching the upload endpoint. Server implementations SHOULD provide a hook to allow security scanners to check the resulting blob after concatenating the data sources in the same way that they do for the upload endpoint. Digest algorithms can be expensive for servers to calculate. Servers which share resources between multiple users should track resource usage by clients, and rate-limit expensive operations to avoid resource starvation. 6. IANA considerations 6.1. JMAP Capability registration for "blob" IANA is requested to register the "blob" JMAP Capability as follows: Capability Name: urn:ietf:params:jmap:blob Specification document: this document Gondwana Expires 8 July 2023 [Page 23] Internet-Draft JMAP Blob January 2023 Intended use: common Change Controller: IETF Security and privacy considerations: this document, Section XXX 6.2. JMAP Error Codes Registration for "unknownDataType" IANA is requested to register the "unknownDataType" JMAP Error Code as follows: JMAP Error Code: unknownDataType Intended use: common Change Controller: IETF Reference: this document Description: The server does not recognise this data type, or the capability to enable it was not present. 6.3. Creation of "JMAP Data Types" Registry IANA is requested to create a new registry "JMAP Data Types" with the initial content: Gondwana Expires 8 July 2023 [Page 24] Internet-Draft JMAP Blob January 2023 +================+=========+======+=====================================+=========+ |Type Name |Can |Can |Capability |Reference| | |reference|use | | | | |blobs |for | | | | | |state | | | | | |change| | | +================+=========+======+=====================================+=========+ |Core |No |No |urn:ietf:params:jmap:core |[RFC8620]| +----------------+---------+------+-------------------------------------+---------+ |PushSubscription|No |No |urn:ietf:params:jmap:core |[RFC8620]| +----------------+---------+------+-------------------------------------+---------+ |Mailbox |Yes |Yes |urn:ietf:params:jmap:mail |[RFC8621]| +----------------+---------+------+-------------------------------------+---------+ |Thread |Yes |Yes |urn:ietf:params:jmap:mail |[RFC8621]| +----------------+---------+------+-------------------------------------+---------+ |Email |Yes |Yes |urn:ietf:params:jmap:mail |[RFC8621]| +----------------+---------+------+-------------------------------------+---------+ |EmailDelivery |No |Yes |urn:ietf:params:jmap:mail |[RFC8621]| +----------------+---------+------+-------------------------------------+---------+ |SearchSnippet |No |No |urn:ietf:params:jmap:mail |[RFC8621]| +----------------+---------+------+-------------------------------------+---------+ |Identity |No |Yes |urn:ietf:params:jmap:submission |[RFC8621]| +----------------+---------+------+-------------------------------------+---------+ |EmailSubmission |No |Yes |urn:ietf:params:jmap:submission |[RFC8621]| +----------------+---------+------+-------------------------------------+---------+ |VacationResponse|No |Yes |urn:ietf:params:jmap:vacationresponse|[RFC8621]| +----------------+---------+------+-------------------------------------+---------+ |MDN |No |No |urn:ietf:params:jmap:mdn |[RFC9007]| +----------------+---------+------+-------------------------------------+---------+ Table 1 This policy for this registry is "Specification required", either an RFC or a similarly stable reference document which defines a JMAP Data Type and associated capability. IANA is asked to appoint designated experts to review requests for additions to this registry, with guidance to allow any registration which provides a stable document describing the capability, and control over the URI namespace where the capability URI points. 7. Changes EDITOR: please remove this section before publication. The source of this document exists on github at: https://github.com/brong/draft-gondwana-jmap-blob/ (https://github.com/brong/draft-gondwana-jmap-blob/) Gondwana Expires 8 July 2023 [Page 25] Internet-Draft JMAP Blob January 2023 *draft-ietf-jmap-blob-18* * add security considerations for Digest algorithm performance (was supposed to be in -13 but I had a commit that never got pushed) * artart review: - clarify that created blobs behave identically to RFC8620 section 6 binary objects. - clearer text about "references a blob" - remove contractions * Roman Danyliw DISCUSS - corrected example text - missing comma and extra data:asBase64. - simplify Blob/lookup to not have multiple ways of saying "not found" for a blob and then need a security considerations around it. - said that clients SHOULD prefer algorithms earlier in the list. - clarified that supportedTypeNames could include private extensions. - editorial/spelling fixes * genart review - editorial/spelling fixes * Robert Winton review - added a suggestion to use the regular upload mechanism for blobs over a megabyte in size. *draft-ietf-jmap-blob-17* * AD review, one more wording nit *draft-ietf-jmap-blob-16* * secdir last-call review changes - nit fixes and security considerations *draft-ietf-jmap-blob-15* * changed capabilities object to MUST contain all specified keys, to align with all other published JMAP extensions. *draft-ietf-jmap-blob-14* * AD review - fixed MUST usage * AD review - added instructions regarding expert review for IANA *draft-ietf-jmap-blob-13* * added examples of digest responses *draft-ietf-jmap-blob-12* Gondwana Expires 8 July 2023 [Page 26] Internet-Draft JMAP Blob January 2023 * updates based on Neil Jenkins' feedback: - fixed [] positions for type specs - documented delta between /upload and /set better - allowed zero-length blobId sources - fixed examples with /set leftovers - documented datatypes registry policy * added optional "digest" support *draft-ietf-jmap-blob-11*: * updates based on IETF113 feedback: - added wording to suggest the a Blob/get of just size might be faster - added an example with just the size field being selected *draft-ietf-jmap-blob-10*: * removed remaining references to catenate. *draft-ietf-jmap-blob-09*: * tidied up introduction text * replaced Blob/set with Blob/upload * made all upload creates take an array of sources to normalise behaviour at the cost of a slightly more complex default case. *draft-ietf-jmap-blob-08*: * Fixed spelling of Neil's name in acknowledgements * Last call review (thanks Jim Fenton) - fixed mmark sillyness causing RFC8620 to be non-normative in the references - clarified the capability object and accountCapability object requirements - made capability keys much more tightly defined, with mandatory minimum catenate limit and default values. - increased use of normative language generally - lowercased 'blob' anywhere it wasn't explicitly the object - lowercased titles of the columns in the registry *draft-ietf-jmap-blob-07*: * more examples to cover the interactions of offset, length and encoding checks. *draft-ietf-jmap-blob-06*: * removed asHex - we only need base64 and text Gondwana Expires 8 July 2023 [Page 27] Internet-Draft JMAP Blob January 2023 * added reference to where base64 is defined * made 'destroy' not be allowed * expanded JSON examples for readability * removed 'expires' from examples *draft-ietf-jmap-blob-05*: * discovered I hadn't actually included typeNames and matchedIds anywhere except the updates section, oops! * added a catenate example * tightened up some text *draft-ieft-jmap-blob-04*: * added security considerations for scanning catenate results *draft-ieft-jmap-blob-03*: * added capabilities object * renamed types to typeNames and matchedIds * added details of how to handle non-UTF8 data and truncation in Blob/get * added isTruncated and isEncodingProblem to Blob/get to tell the client if the request wasn't entirely satisfied. *draft-ieft-jmap-blob-02*: * fixed incorrect RFC number in reference and HTTP PUT -> POST, thanks Ken. * added acknowledgements section * removed all 'datatype' text and changed to 'data type' or 'type name' as appropriate (issue #1 proposal) * expanded security considerations section and moved optional Blob/ lookup empty case into Blob/lookup section *draft-ieft-jmap-blob-01*: * renamed 'datatypes' to 'types' to align with PushSubscription from RFC8620. * added example for Blob/get * specified offset and length precisely *draft-ieft-jmap-blob-00*: * initial adoption as an IETF document, otherwise identical to draft-gondwana-jmap-blob-02 *draft-gondwana-jmap-blob-02* Gondwana Expires 8 July 2023 [Page 28] Internet-Draft JMAP Blob January 2023 * renamed 'objects' to 'datatypes' * specified Blob/lookup * added IANA registry for datatypes *draft-gondwana-jmap-blob-01* * added an example *draft-gondwana-jmap-blob-00* * initial proposal 8. Acknowledgements Joris Baum, Jim Fenton, Neil Jenkins, Alexey Melnikov, Ken Murchison, Robert Stepanek and the JMAP working group at the IETF. 9. Normative References [RFC2119] Bradner, S. and RFC Publisher, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3230] Mogul, J., Van Hoff, A., and RFC Publisher, "Instance Digests in HTTP", RFC 3230, DOI 10.17487/RFC3230, January 2002, . [RFC4648] Josefsson, S. and RFC Publisher, "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC8174] Leiba, B. and RFC Publisher, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8620] Jenkins, N., Newman, C., and RFC Publisher, "The JSON Meta Application Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July 2019, . 10. Informative References [RFC7888] Melnikov, A., Ed. and RFC Publisher, "IMAP4 Non- synchronizing Literals", RFC 7888, DOI 10.17487/RFC7888, May 2016, . Gondwana Expires 8 July 2023 [Page 29] Internet-Draft JMAP Blob January 2023 [RFC8621] Jenkins, N., Newman, C., and RFC Publisher, "The JSON Meta Application Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621, August 2019, . Author's Address Bron Gondwana (editor) Fastmail Level 2, 114 William St Melbourne VIC 3000 Australia Email: brong@fastmailteam.com URI: https://www.fastmail.com Gondwana Expires 8 July 2023 [Page 30] ./index.html0000644000764400076440000021010614363246644012654 0ustar iustiniustin » RFC Editor

The RFC Series

The RFC Series (ISSN 2070-1721) contains technical and organizational documents about the Internet, including the specifications and policy documents produced by five streams: the Internet Engineering Task Force (IETF), the Internet Research Task Force (IRTF), the Internet Architecture Board (IAB), Independent Submissions, and Editorial.

Browse the RFC Index

HTML (ascending) • HTML (descending) • TXT • XML
Note: These files are large.

Browse RFCs by Status

Internet Standard

Draft Standard • Proposed Standard

Best Current Practice

Informational • Experimental • Historic

Uncategorized (Early RFCs)

• • • • •

Official Internet Protocol Standards

RFC Status Changes


./draft-ietf-alto-performance-metrics-28.txt0000644000764400076440000023327714216043154020576 0ustar iustiniustin ALTO Working Group Q. Wu Internet-Draft Huawei Intended status: Standards Track Y. Yang Expires: 22 September 2022 Yale University Y. Lee Samsung D. Dhody Huawei S. Randriamasy Nokia Bell Labs L. Contreras Telefonica 21 March 2022 ALTO Performance Cost Metrics draft-ietf-alto-performance-metrics-28 Abstract The cost metric is a basic concept in Application-Layer Traffic Optimization (ALTO), and different applications may use different types of cost metrics. Since the ALTO base protocol (RFC 7285) defines only a single cost metric (namely, the generic "routingcost" metric), if an application wants to issue a cost map or an endpoint cost request in order to identify a resource provider that offers better performance metrics (e.g., lower delay or loss rate), the base protocol does not define the cost metric to be used. This document addresses this issue by extending the specification to provide a variety of network performance metrics, including network delay, delay variation (a.k.a, jitter), packet loss rate, hop count, and bandwidth. There are multiple sources (e.g., estimation based on measurements or service-level agreement) to derive a performance metric. This document introduces an additional "cost-context" field to the ALTO "cost-type" field to convey the source of a performance metric. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Wu, et al. Expires 22 September 2022 [Page 1] Internet-Draft ALTO Performance Cost Metrics March 2022 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 September 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 3. Performance Metric Attributes . . . . . . . . . . . . . . . . 6 3.1. Performance Metric Context: "cost-context" . . . . . . . 7 3.2. Performance Metric Statistics . . . . . . . . . . . . . . 9 4. Packet Performance Metrics . . . . . . . . . . . . . . . . . 11 4.1. Cost Metric: One-Way Delay (delay-ow) . . . . . . . . . . 11 4.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 11 4.1.2. Value Representation . . . . . . . . . . . . . . . . 12 4.1.3. Intended Semantics and Use . . . . . . . . . . . . . 12 4.1.4. Cost-Context Specification Considerations . . . . . . 14 4.2. Cost Metric: Round-trip Delay (delay-rt) . . . . . . . . 16 4.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 16 4.2.2. Value Representation . . . . . . . . . . . . . . . . 16 4.2.3. Intended Semantics and Use . . . . . . . . . . . . . 16 4.2.4. Cost-Context Specification Considerations . . . . . . 17 4.3. Cost Metric: Delay Variation (delay-variation) . . . . . 18 4.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 18 4.3.2. Value Representation . . . . . . . . . . . . . . . . 18 4.3.3. Intended Semantics and Use . . . . . . . . . . . . . 18 4.3.4. Cost-Context Specification Considerations . . . . . . 19 4.4. Cost Metric: Loss Rate (lossrate) . . . . . . . . . . . . 20 4.4.1. Base Identifier . . . . . . . . . . . . . . . . . . . 20 4.4.2. Value Representation . . . . . . . . . . . . . . . . 20 4.4.3. Intended Semantics and Use . . . . . . . . . . . . . 20 Wu, et al. Expires 22 September 2022 [Page 2] Internet-Draft ALTO Performance Cost Metrics March 2022 4.4.4. Cost-Context Specification Considerations . . . . . . 21 4.5. Cost Metric: Hop Count (hopcount) . . . . . . . . . . . . 22 4.5.1. Base Identifier . . . . . . . . . . . . . . . . . . . 22 4.5.2. Value Representation . . . . . . . . . . . . . . . . 22 4.5.3. Intended Semantics and Use . . . . . . . . . . . . . 22 4.5.4. Cost-Context Specification Considerations . . . . . . 23 5. Throughput/Bandwidth Performance Metrics . . . . . . . . . . 24 5.1. Cost Metric: TCP Throughput (tput) . . . . . . . . . . . 24 5.1.1. Base Identifier . . . . . . . . . . . . . . . . . . . 24 5.1.2. Value Representation . . . . . . . . . . . . . . . . 24 5.1.3. Intended Semantics and Use . . . . . . . . . . . . . 24 5.1.4. Cost-Context Specification Considerations . . . . . . 25 5.2. Cost Metric: Residual Bandwidth (bw-residual) . . . . . . 26 5.2.1. Base Identifier . . . . . . . . . . . . . . . . . . . 26 5.2.2. Value Representation . . . . . . . . . . . . . . . . 26 5.2.3. Intended Semantics and Use . . . . . . . . . . . . . 26 5.2.4. Cost-Context Specification Considerations . . . . . . 28 5.3. Cost Metric: Available Bandwidth (bw-available) . . . . . 28 5.3.1. Base Identifier . . . . . . . . . . . . . . . . . . . 28 5.3.2. Value Representation . . . . . . . . . . . . . . . . 28 5.3.3. Intended Semantics and Use . . . . . . . . . . . . . 29 5.3.4. Cost-Context Specification Considerations . . . . . . 30 6. Operational Considerations . . . . . . . . . . . . . . . . . 30 6.1. Source Considerations . . . . . . . . . . . . . . . . . . 31 6.2. Metric Timestamp Consideration . . . . . . . . . . . . . 31 6.3. Backward Compatibility Considerations . . . . . . . . . . 31 6.4. Computation Considerations . . . . . . . . . . . . . . . 32 6.4.1. Configuration Parameters Considerations . . . . . . . 32 6.4.2. Aggregation Computation Considerations . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.2. Informative References . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction Application-Layer Traffic Optimization (ALTO) provides a means for network applications to obtain network information so that the applications can identify efficient application-layer traffic patterns using the networks. Cost metrics are used in both the ALTO cost map service and the ALTO endpoint cost service in the ALTO base protocol [RFC7285]. Wu, et al. Expires 22 September 2022 [Page 3] Internet-Draft ALTO Performance Cost Metrics March 2022 Since different applications may use different cost metrics, the ALTO base protocol introduces an ALTO Cost Metric Registry (Section 14.2 of [RFC7285]) as a systematic mechanism to allow different metrics to be specified. For example, a delay-sensitive application may want to use latency related metrics, and a bandwidth-sensitive application may want to use bandwidth related metrics. However, the ALTO base protocol has registered only a single cost metric, i.e., the generic "routingcost" metric (Section 14.2 of [RFC7285]); no latency or bandwidth related metrics are defined in the base protocol. This document registers a set of new cost metrics (Table 1) to allow applications to determine "where" to connect based on network performance criteria including delay and bandwidth related metrics. +--------------------+-------------+--------------------------------+ | Metric | Definition | Semantics Based On | | | in this doc | | +--------------------+-------------+--------------------------------+ | One-way Delay | Section 4.1 | Base: [RFC7471,8570,8571] | | | | sum Unidirectional Delay | | Round-trip Delay | Section 4.2 | Base: Sum of two directions | | | | from above | | Delay Variation | Section 4.3 | Base: [RFC7471,8570,8571] | | | | sum of Unidirectional Delay | | | | Variation | | Loss Rate | Section 4.4 | Base: [RFC7471,8570,8571] | | | | aggr Unidirectional Link Loss | | Residual Bandwidth | Section 5.2 | Base: [RFC7471,8570,8571] | | | | min Unidirectional Residual BW| | Available Bandwidth| Section 5.3 | Base: [RFC7471,8570,8571] | | | | min Unidirectional Avail. BW | | | | | | TCP Throughput | Section 5.1 | [I-D.ietf-tcpm-rfc8312bis] | | | | | | Hop Count | Section 4.5 | [RFC7285] | +--------------------+-------------+--------------------------------+ Table 1. Cost Metrics Defined in this Document. The first 6 metrics listed in Table 1 (i.e., One-way Delay, Round- trip Delay, Delay Variation, Loss Rate, Residual Bandwidth, and Available Bandwidth) are derived from the set of traffic engineering performance metrics commonly defined in OSPF [RFC3630], [RFC7471]; IS-IS [RFC5305], [RFC8570]; and BGP-LS [RFC8571]. Deriving ALTO cost performance metrics from existing network-layer traffic engineering performance metrics, to expose to application-layer traffic optimization, can be a typical mechanism by network operators to deploy ALTO [RFC7971], [FlowDirector]. This document defines the base semantics of these metrics by extending them from link metrics Wu, et al. Expires 22 September 2022 [Page 4] Internet-Draft ALTO Performance Cost Metrics March 2022 to end-to-end metrics for ALTO. The "Semantics Based On" column specifies at a high level how the end-to-end metric is computed from link metrics; the details will be specified in the following sections. The common metrics Min/Max Unidirectional Delay defined in [RFC8570][RFC8571] and Max Link Bandwidth defined in [RFC3630,RFC5305] are not listed in Table 1 because they can be handled by applying the statistical operators defined in this document. The metrics related with utilized bandwidth and reservable bandwidth (i.e., Max Reservable BW and Unreserved BW defined in [RFC3630,RFC5305]) are outside the scope of this document. The 7th metric (the estimated TCP-flow throughput metric) provides an estimation of the bandwidth of a TCP flow, using TCP throughput modeling, to support use cases of adaptive applications [Prophet], [G2]. Note that other transport-specific metrics can be defined in the future. For example, QUIC-related metrics [RFC9000] can be considered when the methodology to measure such metrics is more mature (e.g., [I-D.corre-quic-throughput-testing]). The 8th metric (the hop count metric) in Table 1 is mentioned in the ALTO base protocol [RFC7285], but not defined, and this document defines it to be complete. These 8 performance metrics can be classified into two categories: those derived from the performance of individual packets (i.e., One- way Delay, Round-trip Delay, Delay Variation, Loss Rate, and Hop Count), and those related to bandwidth/throughput (Residual bandwidth, and Available Bandwidth, and TCP throughput). These two categories are defined in Sections 4 and 5 respectively. Note that all metrics except Round-trip Delay are unidirectional. An ALTO client will need to query both directions if needed. The purpose of this document is to ensure proper usage of these 8 performance metrics in the context of ALTO. This document follows the guideline defined in Section 14.2 of the ALTO base protocol [RFC7285] on registering ALTO cost metrics. Hence, it specifies the identifier, the intended semantics, and the security considerations of each one of the metrics specified in Table 1. The definitions of the intended semantics of the metrics tend to be coarse-grained, for guidance only, and they may work well for ALTO. On the other hand, a performance measurement framework, such as the IP Performance Measurement (IPPM) framework, may provide more details in defining a performance metric. This document introduces a mechanism called "cost-context" to provide additional details, when they are available; see Section 3. Wu, et al. Expires 22 September 2022 [Page 5] Internet-Draft ALTO Performance Cost Metrics March 2022 Following the ALTO base protocol, this document uses JSON to specify the value type of each defined metric. See [RFC8259] for JSON data type specification. In particular, [RFC7285] specifies that cost values should be assumed by default as JSONNumber. When defining the value representation of each metric in Table 1, this document conforms to [RFC7285], but specifies additional, generic constraints on valid JSONNumbers for each metric. For example, each new metric in Table 1 will be specified as non-negative (>= 0); Hop Count is specified to be an integer. An ALTO server may provide only a subset of the metrics described in this document. For example, those that are subject to privacy concerns should not be provided to unauthorized ALTO clients. Hence, all cost metrics defined in this document are optional; not all of them need to be exposed to a given application. When an ALTO server supports a cost metric defined in this document, it announces the metric in its information resource directory (IRD) as defined in Section 9.2 of [RFC7285]. An ALTO server introducing these metrics should consider related security issues. As a generic security consideration on the reliability and trust in the exposed metric values, applications SHOULD rapidly give up using ALTO-based guidance if they detect that the exposed information does not preserve their performance level or even degrades it. Section 7 discusses security considerations in more detail. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Performance Metric Attributes The definitions of the metrics in this document are coarse-grained, based on network-layer traffic engineering performance metrics, for guidance only. A fine-grained framework specified in [RFC6390] requires that the fine-grained specification of a network performance metric include 6 components: (i) Metric Name, (ii) Metric Description, (iii) Method of Measurement or Calculation, (iv) Units of Measurement, (v) Measurement Points, and (vi) Measurement Timing. Requiring that an ALTO server provides precise, fine-grained values for all 6 components for each metric that it exposes may not be feasible or necessary for all ALTO use cases. For example, an ALTO server computing its metrics from network-layer traffic-engineering Wu, et al. Expires 22 September 2022 [Page 6] Internet-Draft ALTO Performance Cost Metrics March 2022 performance metrics may not have information about the method of measurement or calculation (e.g., measured traffic patterns). To address the issue and realize ALTO use cases, for metrics in Table 1, this document defines performance metric identifiers which can be used in the ALTO protocol with well-defined (i) Metric Name, (ii) Metric Description, (iv) Units of Measurement, and (v) Measurement Points, which are always specified by the specific ALTO services; for example, endpoint cost service is between the two endpoints. Hence, the ALTO performance metric identifiers provide basic metric attributes. To allow the flexibility of allowing an ALTO server to provide fine- grained information such as Method of Measurement or Calculation, according to its policy and use cases, this document introduces context information so that the server can provide these additional details. 3.1. Performance Metric Context: "cost-context" The core additional details of a performance metric specify "how" the metric is obtained. This is referred to as the source of the metric. Specifically, this document defines three types of coarse-grained metric information sources: "nominal", and "sla" (service level agreement), and "estimation". For a given type of source, precise interpretation of a performance metric value can depend on specific measurement and computation parameters. To make it possible to specify the source and the aforementioned parameters, this document introduces an optional "cost-context" field to the "cost-type" field defined by the ALTO base protocol (Section 10.7 of [RFC7285]) as the following: object { CostMetric cost-metric; CostMode cost-mode; [CostContext cost-context;] [JSONString description;] } CostType; object { JSONString cost-source; [JSONValue parameters;] } CostContext; Wu, et al. Expires 22 September 2022 [Page 7] Internet-Draft ALTO Performance Cost Metrics March 2022 "cost-context" will not be used as a key to distinguish among performance metrics. Hence, an ALTO information resource MUST NOT announce multiple CostType with the same "cost-metric", "cost-mode" and "cost-context". They must be placed into different information resources. The "cost-source" field of the "cost-context" field is defined as a string consisting of only US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A). The cost-source is used in this document to indicate a string of this format. As mentioned above, this document defines three values for "cost- source": "nominal", "sla", and "estimation". The "cost-source" field of the "cost-context" field MUST be one registered in "ALTO Cost Source" registry (Section 8). The "nominal" category indicates that the metric value is statically configured by the underlying devices. Not all metrics have reasonable "nominal" values. For example, throughput can have a nominal value, which indicates the configured transmission rate of the involved devices; latency typically does not have a nominal value. The "sla" category indicates that the metric value is derived from some commitment which this document refers to as service-level agreement (SLA). Some operators also use terms such as "target" or "committed" values. For an "sla" metric, it is RECOMMENDED that the "parameters" field provide a link to the SLA definition. The "estimation" category indicates that the metric value is computed through an estimation process. An ALTO server may compute "estimation" values by retrieving and/or aggregating information from routing protocols (e.g., [RFC7471], [RFC8570], [RFC8571]), traffic measurement management tools (e.g., TWAMP [RFC5357]), and measurement frameworks (e.g., IPPM), with corresponding operational issues. An illustration of potential information flows used for estimating these metrics is shown in Figure 1. Section 6 discusses in more detail the operational issues and how a network may address them. Wu, et al. Expires 22 September 2022 [Page 8] Internet-Draft ALTO Performance Cost Metrics March 2022 +--------+ +--------+ +--------+ | Client | | Client | | Client | +----^---+ +---^----+ +---^----+ | | | +-----------|-----------+ North-Bound |ALTO protocol Interface (NBI)| | +--+-----+ retrieval +-----------+ | ALTO |<----------------| Routing | | Server | and aggregation| | | |<-------------+ | Protocols | +--------+ | +-----------+ | | +------------+ | |Performance | ---| Monitoring | | Tools | +------------+ Figure 1. A framework to compute estimation to performance metrics There can be multiple choices in deciding the cost-source category. It is the operator of an ALTO server who chooses the category. If a metric does not include a "cost-source" value, the application MUST assume that the value of "cost-source" is the most generic source, i.e., "estimation". 3.2. Performance Metric Statistics The measurement of a performance metric often yields a set of samples from an observation distribution ([Prometheus]), instead of a single value. A statistical operator is applied to the samples to obtain a value to be reported to the client. Multiple statistical operators (e.g., min, median, and max) are commonly being used. Hence, this document extends the general US-ASCII alphanumeric cost metric strings, formally specified as the CostMetric type defined in Section 10.6 of [RFC7285], as follows: A cost metric string consists of a base metric identifier (or base identifier for short) string, followed by an optional statistical operator string, connected by the ASCII character colon (':', U+003A), if the statistical operator string exists. The total length of the cost metric string MUST NOT exceed 32, as required by [RFC7285]. The statistical operator string MUST be one of the following: Wu, et al. Expires 22 September 2022 [Page 9] Internet-Draft ALTO Performance Cost Metrics March 2022 cur: the instantaneous observation value of the metric from the most recent sample (i.e., the current value). percentile, with letter 'p' followed by a number: gives the percentile specified by the number following the letter 'p'. The number MUST be a non-negative JSON number in the range [0, 100] (i.e., greater than or equal to 0 and less than or equal to 100), followed by an optional decimal part, if a higher precision is needed. The decimal part should start with the '.' separator (U+002E), and followed by a sequence of one or more ASCII numbers between '0' and '9'. Assume this number is y and consider the samples coming from a random variable X. Then the metric returns x, such that the probability of X is less than or equal to x, i.e., Prob(X <= x), = y/100. For example, delay- ow:p99 gives the 99% percentile of observed one-way delay; delay- ow:p99.9 gives the 99.9% percentile. Note that some systems use quantile, which is in the range [0, 1]. When there is a more common form for a given percentile, it is RECOMMENDED that the common form be used; that is, instead of p0, use min; instead of p50, use median; instead of p100, use max. min: the minimal value of the observations. max: the maximal value of the observations. median: the mid-point (i.e., p50) of the observations. mean: the arithmetic mean value of the observations. stddev: the standard deviation of the observations. stdvar: the standard variance of the observations. Wu, et al. Expires 22 September 2022 [Page 10] Internet-Draft ALTO Performance Cost Metrics March 2022 Examples of cost metric strings then include "delay-ow", "delay- ow:min", "delay-ow:p99", where "delay-ow" is the base metric identifier string; "min" and "p99" are example statistical operator strings. If a cost metric string does not have the optional statistical operator string, the statistical operator SHOULD be interpreted as the default statistical operator in the definition of the base metric. If the definition of the base metric does not provide a definition for the default statistical operator, the metric MUST be considered as the median value. Note that RFC 7258 limits the overall cost metric identifier to 32 characters. The cost metric variants with statistical operator suffixes defined by this document are also subject to the same overall 32-character limit, so certain combinations of (long) base metric identifier and statistical operator will not be representable. If such a situation arises, it could be addressed by defining a new base metric identifier that is an "alias" of the desired base metric, with identical semantics and just a shorter name. 4. Packet Performance Metrics This section introduces ALTO network performance metrics on one way delay, round-trip delay, delay variation, packet loss rate, and hop count. They measure the "quality of experience" of the stream of packets sent from a resource provider to a resource consumer. The measures of each individual packet (pkt) can include the delay from the time when the packet enters the network to the time when the packet leaves the network (pkt.delay); whether the packet is dropped before reaching the destination (pkt.dropped); the number of network hops that the packet traverses (pkt.hopcount). The semantics of the performance metrics defined in this section are that they are statistics computed from these measures; for example, the x-percentile of the one-way delay is the x-percentile of the set of delays {pkt.delay} for the packets in the stream. 4.1. Cost Metric: One-Way Delay (delay-ow) 4.1.1. Base Identifier The base identifier for this performance metric is "delay-ow". Wu, et al. Expires 22 September 2022 [Page 11] Internet-Draft ALTO Performance Cost Metrics March 2022 4.1.2. Value Representation The metric value type is a single 'JSONNumber' type value conforming to the number specification of Section 6 of [RFC8259]. The unit is expressed in microseconds. Hence, the number can be a floating point number to express delay that is smaller than microseconds. The number MUST be non-negative. 4.1.3. Intended Semantics and Use Intended Semantics: To specify the temporal and spatial aggregated delay of a stream of packets from the specified source to the specified destination. The base semantics of the metric is the Unidirectional Delay metric defined in [RFC8571,RFC8570,RFC7471], but instead of specifying the delay for a link, it is the (temporal) aggregation of the link delays from the source to the destination. A non-normative reference definition of end-to-end one-way delay is [RFC7679]. The spatial aggregation level is specified in the query context, e.g., provider-defined identifier (PID) to PID, or endpoint to endpoint, where PID is defined in Section 5.1 of [RFC7285]. Use: This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response. Example 1: Delay value on source-destination endpoint pairs POST /endpointcost/lookup HTTP/1.1 Host: alto.example.com Content-Length: 239 Content-Type: application/alto-endpointcostparams+json Accept: application/alto-endpointcost+json,application/alto-error+json { "cost-type": { "cost-mode": "numerical", "cost-metric": "delay-ow" }, "endpoints": { "srcs": [ "ipv4:192.0.2.2" ], "dsts": [ "ipv4:192.0.2.89", "ipv4:198.51.100.34" ] } } Wu, et al. Expires 22 September 2022 [Page 12] Internet-Draft ALTO Performance Cost Metrics March 2022 HTTP/1.1 200 OK Content-Length: 247 Content-Type: application/alto-endpointcost+json { "meta": { "cost-type": { "cost-mode": "numerical", "cost-metric": "delay-ow" } }, "endpoint-cost-map": { "ipv4:192.0.2.2": { "ipv4:192.0.2.89": 10, "ipv4:198.51.100.34": 20 } } } Note that since the "cost-type" does not include the "cost-source" field, the values are based on "estimation". Since the identifier does not include the statistical operator string component, the values will represent median values. Example 1a below shows an example that is similar to Example 1, but for IPv6. Wu, et al. Expires 22 September 2022 [Page 13] Internet-Draft ALTO Performance Cost Metrics March 2022 Example 1a: Delay value on source-destination endpoint pairs for IPv6 POST /endpointcost/lookup HTTP/1.1 Host: alto.example.com Content-Length: 252 Content-Type: application/alto-endpointcostparams+json Accept: application/alto-endpointcost+json,application/alto-error+json { "cost-type": { "cost-mode": "numerical", "cost-metric": "delay-ow" }, "endpoints": { "srcs": [ "ipv6:2001:db8:100::1" ], "dsts": [ "ipv6:2001:db8:100::2", "ipv6:2001:db8:100::3" ] } } HTTP/1.1 200 OK Content-Length: 257 Content-Type: application/alto-endpointcost+json { "meta": { "cost-type": { "cost-mode": "numerical", "cost-metric": "delay-ow" } }, "endpoint-cost-map": { "ipv6:2001:db8:100::1": { "ipv6:2001:db8:100::2": 10, "ipv6:2001:db8:100::3": 20 } } } 4.1.4. Cost-Context Specification Considerations "nominal": Typically network one-way delay does not have a nominal value. Wu, et al. Expires 22 September 2022 [Page 14] Internet-Draft ALTO Performance Cost Metrics March 2022 "sla": Many networks provide delay-related parameters in their application-level SLAs. It is RECOMMENDED that the "parameters" field of an "sla" one-way delay metric include a link (i.e., a field named "link") providing an URI to the specification of SLA details, if available. Such a specification can be either free text for possible presentation to the user, or a formal specification. The format of the specification is out of the scope of this document. "estimation": The exact estimation method is out of the scope of this document. There can be multiple sources to estimate one-way delay. For example, the ALTO server may estimate the end-to-end delay by aggregation of routing protocol link metrics; the server may also estimate the delay using active, end-to-end measurements, for example, using the IPPM framework [RFC2330]. If the estimation is computed by aggregation of routing protocol link metrics (e.g., OSPF [RFC7471], IS-IS [RFC8570], or BGP-LS [RFC8571]) Unidirectional Delay link metrics, it is RECOMMENDED that the "parameters" field of an "estimation" one-way delay metric include the following information: (1) the RFC defining the routing protocol metrics (e.g., https://www.rfc-editor.org/info/rfc7471 for RFC7471 derived metrics); (2) configurations of the routing link metrics such as configured intervals; and (3) the aggregation method from link metrics to end-to-end metrics. During aggregation from link metrics to the end-to-end metric, the server should be cognizant of potential issues when computing an end-to-end summary statistic from link statistics. The default end-to-end average one-way delay is the sum of average link one-way delays. If an ALTO server provides the min and max statistical operators for the one-way delay metric, the values can be computed directly from the routing link metrics, as [RFC7471,RFC8570,RFC8571] provide Min/Max Unidirectional Link Delay. If the estimation is from the IPPM measurement framework, it is RECOMMEDED that the "parameters" field of an "estimation" one-way delay metric includes the following information: the URI to the URI field of the IPPM metric defined in the IPPM performance metric [IANA-IPPM] registry (e.g., https://www.iana.org/assignments/ performance-metrics/OWDelay_Active_IP-UDP-Poisson- Payload250B_RFC8912sec7_Seconds_95Percentile). The IPPM metric MUST be one-way delay (i.e., IPPM OWDelay* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95-th percentile). Wu, et al. Expires 22 September 2022 [Page 15] Internet-Draft ALTO Performance Cost Metrics March 2022 4.2. Cost Metric: Round-trip Delay (delay-rt) 4.2.1. Base Identifier The base identifier for this performance metric is "delay-rt". 4.2.2. Value Representation The metric value type is a single 'JSONNumber' type value conforming to the number specification of Section 6 of [RFC8259]. The number MUST be non-negative. The unit is expressed in microseconds. 4.2.3. Intended Semantics and Use Intended Semantics: To specify temporal and spatial aggregated round- trip delay between the specified source and specified destination. The base semantics is that it is the sum of one-way delay from the source to the destination and the one-way delay from the destination back to the source, where the one-way delay is defined in Section 4.1. A non-normative reference definition of end-to-end round-trip delay is [RFC2681]. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint). Note that it is possible for a client to query two one-way delays (delay-ow) and then compute the round-trip delay. The server should be cognizant of the consistency of values. Use: This metric could be used either as a cost metric constraint attribute or as a returned cost metric in the response. Wu, et al. Expires 22 September 2022 [Page 16] Internet-Draft ALTO Performance Cost Metrics March 2022 Example 2: Round-trip Delay of source-destination endpoint pairs POST /endpointcost/lookup HTTP/1.1 Host: alto.example.com Content-Length: 238 Content-Type: application/alto-endpointcostparams+json Accept: application/alto-endpointcost+json,application/alto-error+json { "cost-type": { "cost-mode": "numerical", "cost-metric": "delay-rt" }, "endpoints": { "srcs": [ "ipv4:192.0.2.2" ], "dsts": [ "ipv4:192.0.2.89", "ipv4:198.51.100.34" ] } } HTTP/1.1 200 OK Content-Length: 245 Content-Type: application/alto-endpointcost+json { "meta": { "cost-type": { "cost-mode": "numerical", "cost-metric": "delay-rt" } }, "endpoint-cost-map": { "ipv4:192.0.2.2": { "ipv4:192.0.2.89": 4, "ipv4:198.51.100.34": 3 } } } 4.2.4. Cost-Context Specification Considerations "nominal": Typically network round-trip delay does not have a nominal value. Wu, et al. Expires 22 September 2022 [Page 17] Internet-Draft ALTO Performance Cost Metrics March 2022 "sla": See the "sla" entry in Section 4.1.4. "estimation": See the "estimation" entry in Section 4.1.4. For estimation by aggregation of routing protocol link metrics, the aggregation should include all links from the source to the destination and then back to the source; for estimation using IPPM, the IPPM metric MUST be round-trip delay (i.e., IPPM RTDelay* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95-th percentile). 4.3. Cost Metric: Delay Variation (delay-variation) 4.3.1. Base Identifier The base identifier for this performance metric is "delay-variation". 4.3.2. Value Representation The metric value type is a single 'JSONNumber' type value conforming to the number specification of Section 6 of [RFC8259]. The number MUST be non-negative. The unit is expressed in microseconds. 4.3.3. Intended Semantics and Use Intended Semantics: To specify temporal and spatial aggregated delay variation (also called delay jitter)) with respect to the minimum delay observed on the stream over the one-way delay from the specified source and destination, where the one-way delay is defined in Section 4.1. A non-normative reference definition of end-to-end one-way delay variation is [RFC3393]. Note that [RFC3393] allows the specification of a generic selection function F to unambiguously define the two packets selected to compute delay variations. This document defines the specific case that F selects as the "first" packet the one with the smallest one-way delay. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint). Note that in statistics, variations are typically evaluated by the distance from samples relative to the mean. In networking context, it is more commonly defined from samples relative to the min. This definition follows the networking convention. Use: This metric could be used either as a cost metric constraint attribute or as a returned cost metric in the response. Wu, et al. Expires 22 September 2022 [Page 18] Internet-Draft ALTO Performance Cost Metrics March 2022 Example 3: Delay variation value on source-destination endpoint pairs POST /endpointcost/lookup HTTP/1.1 Host: alto.example.com Content-Length: 245 Content-Type: application/alto-endpointcostparams+json Accept: application/alto-endpointcost+json,application/alto-error+json { "cost-type": { "cost-mode": "numerical", "cost-metric": "delay-variation" }, "endpoints": { "srcs": [ "ipv4:192.0.2.2" ], "dsts": [ "ipv4:192.0.2.89", "ipv4:198.51.100.34" ] } } HTTP/1.1 200 OK Content-Length: 252 Content-Type: application/alto-endpointcost+json { "meta": { "cost-type": { "cost-mode": "numerical", "cost-metric": "delay-variation" } }, "endpoint-cost-map": { "ipv4:192.0.2.2": { "ipv4:192.0.2.89": 0, "ipv4:198.51.100.34": 1 } } } 4.3.4. Cost-Context Specification Considerations "nominal": Typically network delay variation does not have a nominal value. Wu, et al. Expires 22 September 2022 [Page 19] Internet-Draft ALTO Performance Cost Metrics March 2022 "sla": See the "sla" entry in Section 4.1.4. "estimation": See the "estimation" entry in Section 4.1.4. For estimation by aggregation of routing protocol link metrics, the default aggregation of the average of delay variations is the sum of the link delay variations; for estimation using IPPM, the IPPM metric MUST be delay variation (i.e., IPPM OWPDV* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95-th percentile). 4.4. Cost Metric: Loss Rate (lossrate) 4.4.1. Base Identifier The base identifier for this performance metric is "lossrate". 4.4.2. Value Representation The metric value type is a single 'JSONNumber' type value conforming to the number specification of Section 6 of [RFC8259]. The number MUST be non-negative. The value represents the percentage of packet losses. 4.4.3. Intended Semantics and Use Intended Semantics: To specify temporal and spatial aggregated one- way packet loss rate from the specified source and the specified destination. The base semantics of the metric is the Unidirectional Link Loss metric defined in [RFC8571,RFC8570,RFC7471], but instead of specifying the loss for a link, it is the aggregated loss of all links from the source to the destination. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint). Use: This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response. Wu, et al. Expires 22 September 2022 [Page 20] Internet-Draft ALTO Performance Cost Metrics March 2022 Example 5: Loss rate value on source-destination endpoint pairs POST /endpointcost/lookup HTTP/1.1 Host: alto.example.com Content-Length: 238 Content-Type: application/alto-endpointcostparams+json Accept: application/alto-endpointcost+json,application/alto-error+json { "cost-type": { "cost-mode": "numerical", "cost-metric": "lossrate" }, "endpoints": { "srcs": [ "ipv4:192.0.2.2" ], "dsts": [ "ipv4:192.0.2.89", "ipv4:198.51.100.34" ] } } HTTP/1.1 200 OK Content-Length: 248 Content-Type: application/alto-endpointcost+json { "meta": { "cost-type": { "cost-mode": "numerical", "cost-metric": "lossrate" } }, "endpoint-cost-map": { "ipv4:192.0.2.2": { "ipv4:192.0.2.89": 0, "ipv4:198.51.100.34": 0.01 } } } 4.4.4. Cost-Context Specification Considerations "nominal": Typically packet loss rate does not have a nominal value, although some networks may specify zero losses. Wu, et al. Expires 22 September 2022 [Page 21] Internet-Draft ALTO Performance Cost Metrics March 2022 "sla": See the "sla" entry in Section 4.1.4.. "estimation": See the "estimation" entry in Section 4.1.4. For estimation by aggregation of routing protocol link metrics, the default aggregation of the average of loss rate is the sum of the link link loss rates. But this default aggregation is valid only if two conditions are met: (1) it is valid only when link loss rates are low, and (2) it assumes that each link's loss events are uncorrelated with every other link's loss events. When loss rates at the links are high but independent, the general formula for aggregating loss assuming each link is independent is to compute end-to-end loss as one minus the product of the success rate for each link. Aggregation when losses at links are correlated can be more complex and the ALTO server should be cognizant of correlated loss rates. For estimation using IPPM, the IPPM metric MUST be packet loss (i.e., IPPM OWLoss* metrics). The statistical operator of the ALTO metric MUST be consistent with the IPPM statistical property (e.g., 95-th percentile). 4.5. Cost Metric: Hop Count (hopcount) The hopcount metric is mentioned in Section 9.2.3 of [RFC7285] as an example. This section further clarifies its properties. 4.5.1. Base Identifier The base identifier for this performance metric is "hopcount". 4.5.2. Value Representation The metric value type is a single 'JSONNumber' type value conforming to the number specification of Section 6 of [RFC8259]. The number MUST be a non-negative integer (greater than or equal to 0). The value represents the number of hops. 4.5.3. Intended Semantics and Use Intended Semantics: To specify the number of hops in the path from the specified source to the specified destination. The hop count is a basic measurement of distance in a network and can be exposed as the number of router hops computed from the routing protocols originating this information. A hop, however, may represent other units. The spatial aggregation level is specified in the query context (e.g., PID to PID, or endpoint to endpoint). Use: This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response. Wu, et al. Expires 22 September 2022 [Page 22] Internet-Draft ALTO Performance Cost Metrics March 2022 Example 4: hopcount value on source-destination endpoint pairs POST /endpointcost/lookup HTTP/1.1 Host: alto.example.com Content-Length: 238 Content-Type: application/alto-endpointcostparams+json Accept: application/alto-endpointcost+json,application/alto-error+json { "cost-type": { "cost-mode": "numerical", "cost-metric": "hopcount" }, "endpoints": { "srcs": [ "ipv4:192.0.2.2" ], "dsts": [ "ipv4:192.0.2.89", "ipv4:198.51.100.34" ] } } HTTP/1.1 200 OK Content-Length: 245 Content-Type: application/alto-endpointcost+json { "meta": { "cost-type": { "cost-mode": "numerical", "cost-metric": "hopcount" } }, "endpoint-cost-map": { "ipv4:192.0.2.2": { "ipv4:192.0.2.89": 5, "ipv4:198.51.100.34": 3 } } } 4.5.4. Cost-Context Specification Considerations "nominal": Typically hop count does not have a nominal value. Wu, et al. Expires 22 September 2022 [Page 23] Internet-Draft ALTO Performance Cost Metrics March 2022 "sla": Typically hop count does not have an SLA value. "estimation": The exact estimation method is out of the scope of this document. An example of estimating hopcounts is by importing from IGP routing protocols. It is RECOMMENDED that the "parameters" field of an "estimation" hop count define the meaning of a hop. 5. Throughput/Bandwidth Performance Metrics This section introduces four throughput/bandwidth related metrics. Given a specified source to a specified destination, these metrics reflect the volume of traffic that the network can carry from the source to the destination. 5.1. Cost Metric: TCP Throughput (tput) 5.1.1. Base Identifier The base identifier for this performance metric is "tput". 5.1.2. Value Representation The metric value type is a single 'JSONNumber' type value conforming to the number specification of Section 6 of [RFC8259]. The number MUST be non-negative. The unit is bytes per second. 5.1.3. Intended Semantics and Use Intended Semantics: To give the throughput of a TCP congestion- control conforming flow from the specified source to the specified destination. The throughput SHOULD be interpreted as only an estimation, and the estimation is designed only for bulk flows. Use: This metric could be used as a cost metric constraint attribute or as a returned cost metric in the response. Wu, et al. Expires 22 September 2022 [Page 24] Internet-Draft ALTO Performance Cost Metrics March 2022 Example 5: TCP throughput value on source-destination endpoint pairs POST /endpointcost/lookup HTTP/1.1 Host: alto.example.com Content-Length: 234 Content-Type: application/alto-endpointcostparams+json Accept: application/alto-endpointcost+json,application/alto-error+json { "cost-type": { "cost-mode": "numerical", "cost-metric": "tput" }, "endpoints": { "srcs": [ "ipv4:192.0.2.2" ], "dsts": [ "ipv4:192.0.2.89", "ipv4:198.51.100.34" ] } } HTTP/1.1 200 OK Content-Length: 251 Content-Type: application/alto-endpointcost+json { "meta": { "cost-type": { "cost-mode": "numerical", "cost-metric": "tput" } }, "endpoint-cost-map": { "ipv4:192.0.2.2": { "ipv4:192.0.2.89": 256000, "ipv4:198.51.100.34": 128000 } } } 5.1.4. Cost-Context Specification Considerations "nominal": Typically TCP throughput does not have a nominal value, and SHOULD NOT be generated. Wu, et al. Expires 22 September 2022 [Page 25] Internet-Draft ALTO Performance Cost Metrics March 2022 "sla": Typically TCP throughput does not have an SLA value, and SHOULD NOT be generated. "estimation": The exact estimation method is out of the scope of this document. It is RECOMMENDED that the "parameters" field of an "estimation" TCP throughput metric include the following information: (1) the congestion-control algorithm; and (2) the estimation methodology. To specify (1), it is RECOMMENDED that the "parameters" field (object) include a field named "congestion-control-algorithm", which provides a URI for the specification of the algorithm; for example, for an ALTO server to provide estimation to the throughput of a Cubic Congestion control flow, its "parameters" includes a field "congestion-control-algorithm", with value being set to [I-D.ietf-tcpm-rfc8312bis]; for an ongoing congestion control algorithm such as BBR, a a link to its specification. To specify (2), the "parameters" includes as many details as possible; for example, for TCP Cubic throughout estimation, the "parameters" field specifies that the throughput is estimated by setting _C_ to 0.4, and the Equation in Figure 8 of [I-D.ietf-tcpm-rfc8312bis] is applied; as an alternative, the methodology may be based on the NUM model [Prophet], or the G2 model [G2]. The exact specification of the parameters field is out of the scope of this document. 5.2. Cost Metric: Residual Bandwidth (bw-residual) 5.2.1. Base Identifier The base identifier for this performance metric is "bw-residual". 5.2.2. Value Representation The metric value type is a single 'JSONNumber' type value that is non-negative. The unit of measurement is bytes per second. 5.2.3. Intended Semantics and Use Intended Semantics: To specify temporal and spatial residual bandwidth from the specified source and the specified destination. The base semantics of the metric is the Unidirectional Residual Bandwidth metric defined in [RFC8571,RFC8570,RFC7471], but instead of specifying the residual bandwidth for a link, it is the residual bandwidth of the path from the source to the destination. Hence, it is the minimal residual bandwidth among all links from the source to the destination. When the max statistical operator is defined for the metric, it typically provides the minimum of the link capacities along the path, as the default value of the residual bandwidth of a link is its link capacity [RFC8571,8570,7471]. The spatial aggregation unit is specified in the query context (e.g., PID to PID, Wu, et al. Expires 22 September 2022 [Page 26] Internet-Draft ALTO Performance Cost Metrics March 2022 or endpoint to endpoint). The default statistical operator for residual bandwidth is the current instantaneous sample; that is, the default is assumed to be "cur". Use: This metric could be used either as a cost metric constraint attribute or as a returned cost metric in the response. Example 7: bw-residual value on source-destination endpoint pairs POST /endpointcost/lookup HTTP/1.1 Host: alto.example.com Content-Length: 241 Content-Type: application/alto-endpointcostparams+json Accept: application/alto-endpointcost+json,application/alto-error+json { "cost-type": { "cost-mode": "numerical", "cost-metric": "bw-residual" }, "endpoints": { "srcs": [ "ipv4:192.0.2.2" ], "dsts": [ "ipv4:192.0.2.89", "ipv4:198.51.100.34" ] } } Wu, et al. Expires 22 September 2022 [Page 27] Internet-Draft ALTO Performance Cost Metrics March 2022 HTTP/1.1 200 OK Content-Length: 255 Content-Type: application/alto-endpointcost+json { "meta": { "cost-type": { "cost-mode": "numerical", "cost-metric": "bw-residual" } }, "endpoint-cost-map": { "ipv4:192.0.2.2": { "ipv4:192.0.2.89": 0, "ipv4:198.51.100.34": 2000 } } } 5.2.4. Cost-Context Specification Considerations "nominal": Typically residual bandwidth does not have a nominal value. "sla": Typically residual bandwidth does not have an "sla" value. "estimation": See the "estimation" entry in Section 4.1.4 on aggregation of routing protocol link metrics. The current ("cur") residual bandwidth of a path is the minimal of the residual bandwidth of all links on the path. 5.3. Cost Metric: Available Bandwidth (bw-available) 5.3.1. Base Identifier The base identifier for this performance metric is "bw-available". 5.3.2. Value Representation The metric value type is a single 'JSONNumber' type value that is non-negative. The unit of measurement is bytes per second. Wu, et al. Expires 22 September 2022 [Page 28] Internet-Draft ALTO Performance Cost Metrics March 2022 5.3.3. Intended Semantics and Use Intended Semantics: To specify temporal and spatial available bandwidth from the specified source to the specified destination. The base semantics of the metric is the Unidirectional Available Bandwidth metric defined in [RFC8571,RFC8570,RFC7471], but instead of specifying the available bandwidth for a link, it is the available bandwidth of the path from the source to the destination. Hence, it is the minimal available bandwidth among all links from the source to the destination.The spatial aggregation unit is specified in the query context (e.g., PID to PID, or endpoint to endpoint). The default statistical operator for available bandwidth is the current instantaneous sample; that is, the default is assumed to be "cur". Use: This metric could be used either as a cost metric constraint attribute or as a returned cost metric in the response. Example 8: bw-available value on source-destination endpoint pairs POST /endpointcost/lookup HTTP/1.1 Host: alto.example.com Content-Length: 244 Content-Type: application/alto-endpointcostparams+json Accept: application/alto-endpointcost+json,application/alto-error+json { "cost-type": { "cost-mode": "numerical", "cost-metric": "bw-available" }, "endpoints": { "srcs": [ "ipv4:192.0.2.2" ], "dsts": [ "ipv4:192.0.2.89", "ipv4:198.51.100.34" ] } } Wu, et al. Expires 22 September 2022 [Page 29] Internet-Draft ALTO Performance Cost Metrics March 2022 HTTP/1.1 200 OK Content-Length: 255 Content-Type: application/alto-endpointcost+json { "meta": { "cost-type": { "cost-mode": "numerical", "cost-metric": "bw-available" } }, "endpoint-cost-map": { "ipv4:192.0.2.2": { "ipv4:192.0.2.89": 0, "ipv4:198.51.100.34": 2000 } } } 5.3.4. Cost-Context Specification Considerations "nominal": Typically available bandwidth does not have a nominal value. "sla": Typically available bandwidth does not have an "sla" value. "estimation": See the "estimation" entry in Section 4.1.4 on aggregation of routing protocol link metrics. The current ("cur") available bandwidth of a path is the minimum of the available bandwidth of all links on the path. 6. Operational Considerations The exact measurement infrastructure, measurement condition, and computation algorithms can vary from different networks, and are outside the scope of this document. Both the ALTO server and the ALTO clients, however, need to be cognizant of the operational issues discussed in the following sub-sections. Also, the performance metrics specified in this document are similar, in that they may use similar data sources and have similar issues in their calculation. Hence, this document specifies common issues unless one metric has its unique challenges. Wu, et al. Expires 22 September 2022 [Page 30] Internet-Draft ALTO Performance Cost Metrics March 2022 6.1. Source Considerations The addition of the "cost-source" field is to solve a key issue: An ALTO server needs data sources to compute the cost metrics described in this document, and an ALTO client needs to know the data sources to better interpret the values. To avoid too fine-grained information, this document introduces "cost-source" to indicate only the high-level type of data sources: "estimation", "nominal" or "lsa", where "estimation" is a type of measurement data source, "nominal" is a type of static configuration, and "sla" is a type that is more based on policy. For estimation, for example, the ALTO server may use log servers or the OAM system as its data source as recommended by [RFC7971]. In particular, the cost metrics defined in this document can be computed using routing systems as the data sources. 6.2. Metric Timestamp Consideration Despite the introduction of the additional cost-context information, the metrics do not have a field to indicate the timestamps of the data used to compute the metrics. To indicate this attribute, the ALTO server SHOULD return HTTP "Last-Modified", to indicate the freshness of the data used to compute the performance metrics. If the ALTO client obtains updates through an incremental update mechanism [RFC8895], the client SHOULD assume that the metric is computed using a snapshot at the time that is approximated by the receiving time. 6.3. Backward Compatibility Considerations One potential issue introduced by the optional "cost-source" field is backward compatibility. Consider that an IRD which defines two cost- types with the same "cost-mode" and "cost-metric", but one with "cost-source" being "estimation" and the other being "sla". Then an ALTO client that is not aware of the extension will not be able to distinguish between these two types. A similar issue can arise even with a single cost-type, whose "cost-source" is "sla": an ALTO client that is not aware of this extension will ignore this field and consider the metric estimation. To address the backward-compatibility issue, if a "cost-metric" is "routingcost" and the metric contains a "cost-context" field, then it MUST be "estimation"; if it is not, the client SHOULD reject the information as invalid. Wu, et al. Expires 22 September 2022 [Page 31] Internet-Draft ALTO Performance Cost Metrics March 2022 6.4. Computation Considerations The metric values exposed by an ALTO server may result from additional processing on measurements from data sources to compute exposed metrics. This may involve data processing tasks such as aggregating the results across multiple systems, removing outliers, and creating additional statistics. There are two challenges on the computation of ALTO performance metrics. 6.4.1. Configuration Parameters Considerations Performance metrics often depend on configuration parameters, and exposing such configuration parameters can help an ALTO client to better understand the exposed metrics. In particular, an ALTO server may be configured to compute a TE metric (e.g., packet loss rate) in fixed intervals, say every T seconds. To expose this information, the ALTO server may provide the client with two pieces of additional information: (1) when the metrics are last computed, and (2) when the metrics will be updated (i.e., the validity period of the exposed metric values). The ALTO server can expose these two pieces of information by using the HTTP response headers Last-Modified and Expires. 6.4.2. Aggregation Computation Considerations An ALTO server may not be able to measure the performance metrics to be exposed. The basic issue is that the "source" information can often be link level. For example, routing protocols often measure and report only per link loss, not end-to-end loss; similarly, routing protocols report link level available bandwidth, not end-to- end available bandwidth. The ALTO server then needs to aggregate these data to provide an abstract and unified view that can be more useful to applications. The server should consider that different metrics may use different aggregation computation. For example, the end-to-end latency of a path is the sum of the latency of the links on the path; the end-to-end available bandwidth of a path is the minimum of the available bandwidth of the links on the path; in contrast, aggregating loss values is complicated by the potential for correlated loss events on different links in the path 7. Security Considerations The properties defined in this document present no security considerations beyond those in Section 15 of the base ALTO specification [RFC7285]. Wu, et al. Expires 22 September 2022 [Page 32] Internet-Draft ALTO Performance Cost Metrics March 2022 However, concerns addressed in Sections 15.1, 15.2, and 15.3 of [RFC7285] remain of utmost importance. Indeed, Traffic Engineering (TE) performance is highly sensitive ISP information; therefore, sharing TE metric values in numerical mode requires full mutual confidence between the entities managing the ALTO server and the ALTO client. ALTO servers will most likely distribute numerical TE performance to ALTO clients under strict and formal mutual trust agreements. On the other hand, ALTO clients must be cognizant on the risks attached to such information that they would have acquired outside formal conditions of mutual trust. To mitigate confidentiality risks during information transport of TE performance metrics, the operator should address the risk of ALTO information being leaked to malicious Clients or third parties, through attacks such as the person-in-the-middle (PITM) attacks. As specified in "Protection Strategies" (Section 15.3.2 of [RFC7285]), the ALTO Server should authenticate ALTO Clients when transmitting an ALTO information resource containing sensitive TE performance metrics. "Authentication and Encryption" (Section 8.3.5 of [RFC7285]) specifies that "ALTO Server implementations as well as ALTO Client implementations MUST support the "https" URI scheme of [RFC7230] and Transport Layer Security (TLS) of [RFC8446]". 8. IANA Considerations IANA has created and now maintains the "ALTO Cost Metric" registry, listed in Section 14.2, Table 3 of [RFC7285]. This registry is located at . This document requests to add the following entries to the "ALTO Cost Metric" registry. +-----------------+----------------------------+ | Identifier | Intended Semantics | +-----------------+----------------------------+ | delay-ow | Section 4.1 of [RFCXXX] | | delay-rt | Section 4.2 of [RFCXXX] | | delay-variation | Section 4.3 of [RFCXXX] | | lossrate | Section 4.4 of [RFCXXX] | | hopcount | Section 4.5 of [RFCXXX] | | tput | Section 5.1 of [RFCXXX] | | bw-residual | Section 5.2 of [RFCXXX] | | bw-available | Section 5.3 of [RFCXXX] | +-----------------+----------------------------+ * [Note to the RFC Editor]: Please replace RFCXXX with the RFC number assigned to this document. Wu, et al. Expires 22 September 2022 [Page 33] Internet-Draft ALTO Performance Cost Metrics March 2022 This document requests the creation of the "ALTO Cost Source" registry. This registry serves two purposes. First, it ensures uniqueness of identifiers referring to ALTO cost source types. Second, it provides references to particular semantics of allocated cost source types to be applied by both ALTO servers and applications utilizing ALTO clients. A new ALTO cost source can be added after IETF Review [RFC8126], to ensure that proper documentation regarding the new ALTO cost source and its security considerations have been provided. The RFC(s) documenting the new cost source should be detailed enough to provide guidance to both ALTO service providers and applications utilizing ALTO clients as to how values of the registered ALTO cost source should be interpreted. Updates and deletions of ALTO cost source follow the same procedure. Registered ALTO address type identifiers MUST conform to the syntactical requirements specified in Section 3.1. Identifiers are to be recorded and displayed as strings. Requests to add a new value to the registry MUST include the following information: * Identifier: The name of the desired ALTO cost source type. * Intended Semantics: ALTO cost source type carry with them semantics to guide their usage by ALTO clients. Hence, a document defining a new type should provide guidance to both ALTO service providers and applications utilizing ALTO clients as to how values of the registered ALTO endpoint property should be interpreted. * Security Considerations: ALTO cost source types expose information to ALTO clients. ALTO service providers should be made aware of the security ramifications related to the exposure of a cost source type. This specification requests registration of the identifiers "nominal", "sla", and "estimation" listed in the table below. Semantics for the these are documented in Section 3.1, and security considerations are documented in Section 7. Wu, et al. Expires 22 September 2022 [Page 34] Internet-Draft ALTO Performance Cost Metrics March 2022 +------------+----------------------------------+----------------+ | Identifier | Intended Semantics | Security | | | | Considerations | +------------+----------------------------------+----------------+ | nominal | Values in nominal cases; | Section 7 of | | | Section 3.1 of [RFCXXX] | [RFCXXX] | | sla | Values reflecting service level | Section 7 of | | | agreement; Section 3.1 of | [RFCXXX] | | | [RFCXXXX] | | | estimation | Values by estimation; | Section 7 of | | | Section 3.1 of [RFCXXX] | [RFCXXX] | +------------+----------------------------------+----------------+ 9. Acknowledgments The authors of this document would also like to thank Martin Duke for the highly informative, thorough AD reviews and comments. We thank Christian Amsuess, Elwyn Davies, Haizhou Du, Kai Gao, Geng Li, Lili Liu, Danny Alex Lachos Perez, and Brian Trammell for the reviews and comments. We thank Benjamin Kaduk, Eric Kline, Francesca Palombini, Lars Eggert, Martin Vigoureux, Murrary Kucherawy, Roman Danyliw, Zaheduzzaman Sarker, Eric Vyncke for discussions and comments that improve this document. 10. References 10.1. Normative References [I-D.ietf-tcpm-rfc8312bis] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, "CUBIC for Fast and Long-Distance Networks", Work in Progress, Internet-Draft, draft-ietf-tcpm-rfc8312bis-07, 4 March 2022, . [IANA-IPPM] IANA, "Performance Metrics Registry, https://www.iana.org/assignments/performance-metrics/ performance-metrics.xhtml". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Wu, et al. Expires 22 September 2022 [Page 35] Internet-Draft ALTO Performance Cost Metrics March 2022 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, . [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Wu, et al. Expires 22 September 2022 [Page 36] Internet-Draft ALTO Performance Cost Metrics March 2022 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, . [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, . [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November 2020, . 10.2. Informative References [FlowDirector] Pujol, E., Poese, I., Zerwas, J., Smaragdakis, G., and A. Feldmann, "Steering Hyper-Giants' Traffic at Scale", ACM CoNEXT 2020, 2020. [G2] Ros-Giralt, J., Bohara, A., Yellamraju, S., and et. al., "On the Bottleneck Structure of Congestion-Controlled Networks", ACM SIGMETRICS 2019, 2020. [I-D.corre-quic-throughput-testing] Corre, K., "Framework for QUIC Throughput Testing", Work in Progress, Internet-Draft, draft-corre-quic-throughput- testing-00, 17 September 2021, . [Prometheus] Volz, J. and B. Rabenstein, "Prometheus: A Next-Generation Monitoring System", 2015. [Prophet] Gao, K., Zhang, J., and YR. Yang, "Prophet: Fast, Accurate Throughput Prediction with Reactive Flows", ACM/IEEE Transactions on Networking July, 2020. [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, . Wu, et al. Expires 22 September 2022 [Page 37] Internet-Draft ALTO Performance Cost Metrics March 2022 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, . [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, November 2002, . [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, . [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, . [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and S. Previdi, "Application-Layer Traffic Optimization (ALTO) Deployment Considerations", RFC 7971, DOI 10.17487/RFC7971, October 2016, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . Authors' Addresses Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing Jiangsu, 210012 China Email: bill.wu@huawei.com Y. Richard Yang Yale University 51 Prospect St New Haven, CT 06520 United States of America Email: yry@cs.yale.edu Wu, et al. Expires 22 September 2022 [Page 38] Internet-Draft ALTO Performance Cost Metrics March 2022 Young Lee Samsung Email: young.lee@gmail.com Dhruv Dhody Huawei Leela Palace Bangalore 560008 Karnataka India Email: dhruv.ietf@gmail.com Sabine Randriamasy Nokia Bell Labs Route de Villejust 91460 Nozay France Email: sabine.randriamasy@nokia-bell-labs.com Luis Miguel Contreras Murillo Telefonica Madrid Spain Email: luismiguel.contrerasmurillo@telefonica.com Wu, et al. Expires 22 September 2022 [Page 39] ./draft-ietf-pce-lsp-extended-flags-09.txt0000644000764400076440000005142214325172124020115 0ustar iustiniustin PCE Q. Xiong Internet-Draft ZTE Corporation Intended status: Standards Track 23 October 2022 Expires: 26 April 2023 Label Switched Path (LSP) Object Flag Extension for Stateful PCE draft-ietf-pce-lsp-extended-flags-09 Abstract RFC 8231 describes a set of extensions to Path Computation Element Communication Protocol (PCEP) to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. One of the extensions is the LSP object which includes a Flag field with a length of 12 bits. However, all bits of the Flag field have already been assigned in RFC 8231, RFC 8281, RFC 8623 and I-D.ietf-pce- binding-label-sid. [Note to RFC Editor - Replace I-D.ietf-pce-binding-label-sid to RFC XXXX, once the RFC number is assigned.] This document proposes to define a new LSP-EXTENDED-FLAG TLV for the LSP object for an extended flag field. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Xiong Expires 26 April 2023 [Page 1] Internet-Draft LSP Object Flag Extn October 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 3. PCEP Extension . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. The LSP-EXTENDED-FLAG TLV . . . . . . . . . . . . . . . . 3 3.2. Processing . . . . . . . . . . . . . . . . . . . . . . . 4 4. Advice for Specification of New Flags . . . . . . . . . . . . 5 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6.1. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 5 6.1.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . 5 6.1.2. LSP Extended Flags Field . . . . . . . . . . . . . . 6 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 8. Management Considerations . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 12.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. WG Discussion . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction [RFC5440] describes the Path Computation Element (PCE) Communication Protocol (PCEP) which is used between a PCE and a Path Computation Client (PCC) (or other PCE) to enable computation of Multi-protocol Label Switching for Traffic Engineering (MPLS-TE) Label Switched Path (LSP). PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set of extensions to PCEP to enable active control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. One of the extensions is the LSP object, which contains a flag field; bits in the flag field are used to indicate delegation, synchronization, removal, etc. Xiong Expires 26 April 2023 [Page 2] Internet-Draft LSP Object Flag Extn October 2022 As defined in [RFC8231], the length of the flag field is 12 bits and the values from bit 5 to bit 11 are used for operational, administrative, remove, synchronize and delegate bits respectively. The bit value 4 is assigned in [RFC8281] to identify the PCE- Initiated LSPs. The bits from 1 to 3 are assigned in [RFC8623] for Explicit Route Object (ERO)-compression, fragmentation and Point-to- Multipoint (P2MP) respectively. The bit 0 is assigned in [I-D.ietf-pce-binding-label-sid] to PCE-allocation. All bits of the Flag field have been assigned already. This document extends the flag field of the LSP Object for other use. This document proposes to define a new LSP-EXTENDED-FLAG TLV for an extended flag field in the LSP object. 2. Conventions used in this document 2.1. Terminology The terminology is defined as [RFC5440] and [RFC8231]. 2.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. PCEP Extension The LSP Object is defined in Section 7.3 of [RFC8231]. This document proposes to define a new LSP-EXTENDED-FLAG TLV for an extended flag field in the LSP object. 3.1. The LSP-EXTENDED-FLAG TLV The format of the LSP-EXTENDED-FLAG TLV follows the format of all PCEP TLVs as defined in [RFC5440] and is shown in Figure 1. Xiong Expires 26 April 2023 [Page 3] Internet-Draft LSP Object Flag Extn October 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // LSP Extended Flags // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Figure 1: LSP-EXTENDED-FLAG TLV Format Type (16 bits): TBD1. Length (16 bits): indicates the length of the value portion in bytes. It MUST be in multiples of 4 and greater than 0. LSP Extended Flags: this contains an array of units of 32-bit flags numbered from the most significant as bit zero, where each bit represents one LSP flag (for operation, feature, or state). The LSP Extended Flags field SHOULD use the minimal amount of space needed to encode the flag bits. Currently, no bits are assigned. Unassigned bits MUST be set to zero on transmission and MUST be ignored on receipt. As an example of usage of the LSP-EXTENDED-FLAG TLV, the E-flag is requested for entropy label configuration as proposed in [I-D.peng-pce-entropy-label-position]. 3.2. Processing The LSP Extended Flags field is an array of units of 32 flags, to be allocated starting from the most significant bit. The bits of the LSP Extended Flags field will be assigned by future documents. This document does not define any flags. Flags that an implementation is not supporting MUST be set to zero on transmission. Implementations that do not understand any particular flag MUST ignore the flag. Note that PCEP peers MUST handle varying lengths of the LSP-EXTENDED- FLAG TLV. If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV of a length more than it currently supports or understands, it MUST ignore the bits beyond that length. Xiong Expires 26 April 2023 [Page 4] Internet-Draft LSP Object Flag Extn October 2022 If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV of a length less than the one supported by the implementation, it MUST treat the bits beyond the length to be unset. 4. Advice for Specification of New Flags Following the model provided in [RFC8786] Section 3.1, we provide the following advice for new specifications that define additional flags. Each such specification is expected to describe the interaction between these new flags and any existing flags. In particular, new specifications are expected to explain how to handle the cases when both new and pre-existing flags are set. They are also expected to discuss any security implications of the additional flags (if any) and their interactions with existing flags. 5. Backward Compatibility The LSP-EXTENDED-FLAG TLV defined in this document does not introduce any backward compatibility issues. An implementation that does not understand or support the LSP-EXTENDED-FLAG TLV MUST ignore the TLV as per [RFC5440]. It is expected that future documents that define bits in the LSP-EXTENDED-FLAG TLV will also define the error case handling required for missing LSP-EXTENDED-FLAG TLV if it MUST be present. Further, any additional bits in the LSP-EXTENDED-FLAG TLV that are not understood by an implementation MUST be ignored. It is expected that future documents that define bits in the LSP-EXTENDED-FLAG TLV will take that into consideration. 6. IANA Considerations 6.1. LSP Object 6.1.1. PCEP TLV Type Indicators IANA is requested to allocate the following TLV Type Indicator value within the "PCEP TLV Type Indicators" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry: +=======+===================+=================+ | Value | Description | Reference | +=======+===================+=================+ | TBD1 | LSP-EXTENDED-FLAG | [This document] | +-------+-------------------+-----------------+ Table 1 Xiong Expires 26 April 2023 [Page 5] Internet-Draft LSP Object Flag Extn October 2022 6.1.2. LSP Extended Flags Field IANA is requested to create a new subregistry called "LSP-EXTENDED- FLAG TLV Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the LSP Extended Flags field of the LSP-EXTENDED-FLAG TLV. New values are assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: * Bit number (counting from bit 0 as the most significant bit) * Capability description * Defining RFC No values are currently defined. Bits 0-31 should initially be marked as "Unassigned". Bits with a higher ordinal than 31 will be added to the registry in future documents if necessary. 7. Implementation Status [NOTE TO RFC EDITOR : This whole section and the reference to [RFC7942] is to be removed before publication as an RFC] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". At the time of posting this version of this document, there are no known implementations of this TLV. It is believed that this would be implemented alongside the documents that allocate flags in the TLV. Xiong Expires 26 April 2023 [Page 6] Internet-Draft LSP Object Flag Extn October 2022 8. Management Considerations Implementations receiving set LSP Extended Flags that they do not recognize MAY log this. That could be helpful for diagnosing backward compatibility issues with future features that utilize those flags. 9. Security Considerations [RFC8231] sets out security considerations for PCEP when used for communication with a stateful PCE. This document does not change those considerations. For LSP Object processing, see [RFC8231]. The flags for the LSP object and their associated security considerations are specified in [RFC8231], [RFC8281], [RFC8623], and [I-D.ietf-pce-binding-label-sid]. This document provides for the future addition of flags in the LSP Object. Any future document that specifies new flags must also discuss any associated security implications. No additional security issues are raised in this document beyond those that exist in the referenced documents. Note that the [RFC8231] recommends that the stateful PCEP extension are authenticated and encrypted using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC7525]. Assuming that recommendation is followed, then the flags will be protected by TLS. 10. Acknowledgements The authors would like to thank Loa Andersson, Adrian Farrel, Aijun Wang, and Gyan Mishra for their review, suggestions and comments to this document. 11. Contributors The following people have substantially contributed to this document: Dhruv Dhody Huawei Technologies EMail: dhruv.ietf@gmail.com Greg Mirsky Ericsson Email: gregimirsky@gmail.com 12. References 12.1. Normative References Xiong Expires 26 April 2023 [Page 7] Internet-Draft LSP Object Flag Extn October 2022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . 12.2. Informative References [I-D.ietf-pce-binding-label-sid] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., and C. L. (editor), "Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.", Work in Progress, Internet-Draft, draft-ietf-pce-binding-label- sid-15, 20 March 2022, . [I-D.peng-pce-entropy-label-position] Xiong, Q., Peng, S., and F. Qin, "PCEP Extension for SR- MPLS Entropy Label Position", Work in Progress, Internet- Draft, draft-peng-pce-entropy-label-position-08, 29 August 2022, . [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, . Xiong Expires 26 April 2023 [Page 8] Internet-Draft LSP Object Flag Extn October 2022 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, January 2008, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . [RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019, . [RFC8786] Farrel, A., "Updated Rules for Processing Stateful PCE Request Parameters Flags", RFC 8786, DOI 10.17487/RFC8786, May 2020, . Appendix A. WG Discussion The WG discussed the idea of a fixed length (with 32 bits) for LSP- EXTENDED-FLAG TLV. Though 32 bits would be sufficient for quite a while, the use of variable length with a multiple of 32-bits allows for future extensibility where we would never run out of flags and there would not be a need to define yet another TLV in the future. Further, note that [RFC5088] and [RFC5089] use the same approach for the PCE-CAP-FLAGS Sub-TLV and are found to be useful. Xiong Expires 26 April 2023 [Page 9] Internet-Draft LSP Object Flag Extn October 2022 Author's Address Quan Xiong ZTE Corporation No.6 Huashi Park Rd Wuhan Hubei, 430223 China Email: xiong.quan@zte.com.cn Xiong Expires 26 April 2023 [Page 10] ./draft-ietf-avtcore-cryptex-08.txt0000644000764400076440000011731714272700210017020 0ustar iustiniustin AVTCORE J. Uberti Internet-Draft Clubhouse Updates: 3711 (if approved) C. Jennings Intended status: Standards Track Cisco Expires: 5 February 2023 S. Garcia Murillo Millicast 4 August 2022 Completely Encrypting RTP Header Extensions and Contributing Sources draft-ietf-avtcore-cryptex-08 Abstract While the Secure Real-time Transport Protocol (SRTP) provides confidentiality for the contents of a media packet, a significant amount of metadata is left unprotected, including RTP header extensions and contributing sources (CSRCs). However, this data can be moderately sensitive in many applications. While there have been previous attempts to protect this data, they have had limited deployment, due to complexity as well as technical limitations. This document updates RFC 3711, the SRTP specification, and defines Cryptex as a new mechanism that completely encrypts header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of facilitating deployment. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 February 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Uberti, et al. Expires 5 February 2023 [Page 1] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.2. Previous Solutions . . . . . . . . . . . . . . . . . . . 3 1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. RTP Header Processing . . . . . . . . . . . . . . . . . . . . 6 5.1. Sending . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Receiving . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Encryption and Decryption . . . . . . . . . . . . . . . . . . 8 6.1. Packet Structure . . . . . . . . . . . . . . . . . . . . 8 6.2. Encryption Procedure . . . . . . . . . . . . . . . . . . 8 6.3. Decryption Procedure . . . . . . . . . . . . . . . . . . 10 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9.1. SDP cryptex Attribute . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 14 A.1. AES-CTR . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.1.1. RTP Packet with 1-byte header extension . . . . . . . 14 A.1.2. RTP Packet with 2-byte header extension . . . . . . . 15 A.1.3. RTP Packet with 1-byte header extension and CSRC fields . . . . . . . . . . . . . . . . . . . . . . . 16 A.1.4. RTP Packet with 2-byte header extension and CSRC fields . . . . . . . . . . . . . . . . . . . . . . . 17 A.1.5. RTP Packet with empty 1-byte header extension and CSRC fields . . . . . . . . . . . . . . . . . . . . . . . 17 A.1.6. RTP Packet with empty 2-byte header extension and CSRC fields . . . . . . . . . . . . . . . . . . . . . . . 18 A.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 19 A.2.1. RTP Packet with 1-byte header extension . . . . . . . 19 A.2.2. RTP Packet with 2-byte header extension . . . . . . . 19 Uberti, et al. Expires 5 February 2023 [Page 2] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 A.2.3. RTP Packet with 1-byte header extension and CSRC fields . . . . . . . . . . . . . . . . . . . . . . . 20 A.2.4. RTP Packet with 2-byte header extension and CSRC fields . . . . . . . . . . . . . . . . . . . . . . . 21 A.2.5. RTP Packet with empty 1-byte header extension and CSRC fields . . . . . . . . . . . . . . . . . . . . . . . 22 A.2.6. RTP Packet with empty 2-byte header extension and CSRC fields . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction 1.1. Problem Statement The Secure Real-time Transport Protocol (SRTP) [RFC3711] mechanism provides message authentication for the entire RTP packet, but only encrypts the RTP payload. This has not historically been a problem, as much of the information carried in the header has minimal sensitivity (e.g., RTP timestamp); in addition, certain fields need to remain as cleartext because they are used for key scheduling (e.g., RTP SSRC and sequence number). However, as noted in [RFC6904], the security requirements can be different for information carried in RTP header extensions, including the per-packet sound levels defined in [RFC6464] and [RFC6465], which are specifically noted as being sensitive in the Security Considerations section of those RFCs. In addition to the contents of the header extensions, there are now enough header extensions in active use that the header extension identifiers themselves can provide meaningful information in terms of determining the identity of the endpoint and/or application. Accordingly, these identifiers can be considered a fingerprinting issue. Finally, the CSRCs included in RTP packets can also be sensitive, potentially allowing a network eavesdropper to determine who was speaking and when during an otherwise secure conference call. 1.2. Previous Solutions Encryption of Header Extensions in SRTP [RFC6904] was proposed in 2013 as a solution to the problem of unprotected header extension values. However, it has not seen significant adoption, and has a few technical shortcomings. Uberti, et al. Expires 5 February 2023 [Page 3] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 First, the mechanism is complicated. Since it allows encryption to be negotiated on a per-extension basis, a fair amount of signaling logic is required. And in the SRTP layer, a somewhat complex transform is required to allow only the selected header extension values to be encrypted. One of the most popular SRTP implementations had a significant bug in this area that was not detected for five years. Second, it only protects the header extension values, and not their ids or lengths. It also does not protect the CSRCs. As noted above, this leaves a fair amount of potentially sensitive information exposed. Third, it bloats the header extension space. Because each extension must be offered in both unencrypted and encrypted forms, twice as many header extensions must be offered, which will in many cases push implementations past the 14-extension limit for the use of one-byte extension headers defined in [RFC8285]. Accordingly, implementations will need to use two-byte headers in many cases, which are not supported well by some existing implementations. Finally, the header extension bloat combined with the need for backwards compatibility results in additional wire overhead. Because two-byte extension headers may not be handled well by existing implementations, one-byte extension identifiers will need to be used for the unencrypted (backwards compatible) forms, and two-byte for the encrypted forms. Thus, deployment of [RFC6904] encryption for header extensions will typically result in multiple extra bytes in each RTP packet, compared to the present situation. 1.3. Goals From the previous analysis, the desired properties of a solution are: * Build on existing [RFC3711] SRTP framework (simple to understand) * Build on existing [RFC8285] header extension framework (simple to implement) * Protection of header extension ids, lengths, and values * Protection of CSRCs when present * Simple signaling * Simple crypto transform and SRTP interactions * Backward compatible with unencrypted endpoints, if desired Uberti, et al. Expires 5 February 2023 [Page 4] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 * Backward compatible with existing RTP tooling The last point deserves further discussion. While considering possible solutions that would have encrypted more of the RTP header (e.g., the number of CSRCs), lack of support on current tools was inevitable and the additional complexity outweighed the slight improvement in confidentiality by fixing previous solutions. Hence, a new approach was needed to solve the described problem in Section 1.1. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Design This specification proposes a mechanism to negotiate encryption of all RTP header extensions (ids, lengths, and values) as well as CSRC values. It reuses the existing SRTP framework, is accordingly simple to implement, and is backward compatible with existing RTP packet parsing code, even when support for the mechanism has been negotiated. Except when explicitly stated otherwise, Cryptex reuses all the framework procedures, transforms and considerations described in [RFC3711]. 4. SDP Considerations Cryptex support is indicated via a new "a=cryptex" SDP attribute defined in this specification. The new "a=cryptex" attribute is a property attribute as defined in [RFC8866] section 5.13 and therefore takes no value, and can be used at the session level or media level. The presence of the "a=cryptex" attribute in the SDP (either in an offer or answer) indicates that the endpoint is capable of receiving RTP packets encrypted with Cryptex, as defined below. Once each peer has verified that the other party supports receiving RTP packets encrypted with Cryptex, senders can unilaterally decide whether to use or not the Cryptex mechanism on a per packet basis. Uberti, et al. Expires 5 February 2023 [Page 5] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 If BUNDLE is in use as per [RFC9143] and the "a=cryptex" attribute is present for a media line, it MUST be present for all RTP-based "m=" sections belonging to the same bundle group. This ensures that the encrypted MID header extensions can be processed, allowing to associate RTP streams with the correct "m=" section in each BUNDLE group as specified in [RFC9143] section 9.2. When used with BUNDLE, this attribute is assigned to the TRANSPORT category [RFC8859]. Both endpoints can change the Cryptex support status by modifying the session as specified in [RFC3264] section 8. Generating subsequent SDP offers and answers MUST use the same procedures for including the "a=cryptex" attribute as the ones on the initial offer and answer. 5. RTP Header Processing A General Mechanism for RTP Header Extensions [RFC8285] defines two values for the "defined by profile" field for carrying one-byte and two-byte header extensions. In order to allow a receiver to determine if an incoming RTP packet is using the encryption scheme in this specification, two new values are defined: * 0xC0DE for the encrypted version of the one-byte header extensions (instead of 0xBEDE). * 0xC2DE for the encrypted versions of the two-byte header extensions (instead of 0x100). In the case of using two-byte header extensions, the extension id with value 256 MUST NOT be negotiated, as the value of this id is meant to be contained in the "appbits" of the "defined by profile" field, which are not available when using the values above. Note that as per [RFC8285] it is not possible to mix one-byte and two-byte headers on the same RTP packet. Mixing one-byte and two- byte headers on the same RTP stream requires negotiation of the "extmap-allow-mixed" SDP attribute as defined in [RFC8285] section 4.1.2. Peers MAY negotiate both Cryptex and the Encryption of Header Extensions mechanism defined in [RFC6904] via SDP offer/answer as described in Section 4, and if both mechanisms are supported, either one can be used for any given packet. However, if a packet is encrypted with Cryptex, it MUST NOT also use [RFC6904] header extension encryption, and vice versa. If one of the peers has advertised both the ability to receive cryptex and the ability to receive header extensions encrypted as per [RFC6904] in the SDP exchange, it is RECOMMENDED for the other peer Uberti, et al. Expires 5 February 2023 [Page 6] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 to use Cryptex rather than [RFC6904] when sending RTP packets so all the header extensions and CSRCS are encrypted unless there is a compelling reason to use [RFC6904] (e.g. a need for some header extensions to be sent in the clear so that so they are processable by RTP middleboxes) in which case, it SHOULD use [RFC6904] instead. 5.1. Sending When the mechanism defined by this specification has been negotiated, sending an RTP packet that has any CSRCs or contains any [RFC8285] header extensions follows the steps below. This mechanism MUST NOT be used with header extensions other than the [RFC8285] variety. If the RTP packet contains one-byte headers, the 16-bit RTP header extension tag MUST be set to 0xC0DE to indicate that the encryption has been applied, and the one-byte framing is being used. Otherwise, the header extension tag MUST be set to 0xC2DE to indicate encryption has been applied, and the two-byte framing is being used. If the packet contains CSRCs but no header extensions, an empty extension block consisting of the 0xC0DE tag and a 16-bit length field set to zero (explicitly permitted by [RFC3550]) MUST be appended, and the X bit MUST be set to 1 to indicate an extension block is present. This is necessary to provide the receiver an indication that the CSRCs in the packet are encrypted. The RTP packet MUST then be encrypted as described in Encryption Procedure. 5.2. Receiving When receiving an RTP packet that contains header extensions, the "defined by profile" field MUST be checked to ensure the payload is formatted according to this specification. If the field does not match one of the values defined above, the implementation MUST instead handle it according to the specification that defines that value. Alternatively, if the implementation considers the use of this specification mandatory and the "defined by profile" field does not match one of the values defined above, it MUST stop the processing of the RTP packet and report an error for the RTP stream. If the RTP packet passes this check, it is then decrypted according to Decryption Procedure, and passed to the next layer to process the packet and its extensions. In the event that a zero-length extension block was added as indicated above, it can be left as-is and will be processed normally. Uberti, et al. Expires 5 February 2023 [Page 7] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 6. Encryption and Decryption 6.1. Packet Structure When this mechanism is active, the SRTP packet is protected as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |V=2|P|X| CC |M| PT | sequence number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | timestamp | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | synchronization source (SSRC) identifier | | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | contributing source (CSRC) identifiers | | | | .... | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | X | 0xC0 or 0xC2 | 0xDE | length | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | RFC 8285 header extensions | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | payload ... | | | | +-------------------------------+ | | | | RTP padding | RTP pad count | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | ~ SRTP MKI (OPTIONAL) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : authentication tag (RECOMMENDED) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +- Encrypted Portion* Authenticated Portion ---+ Figure 1 * Note that, as required by [RFC8285], the 4 bytes at the start of the extension block are not encrypted. Specifically, the encrypted portion MUST include any CSRC identifiers, any RTP header extension (except for the first 4 bytes), and the RTP payload. 6.2. Encryption Procedure The encryption procedure is identical to that of [RFC3711] except for the Encrypted Portion of the SRTP packet. The plaintext input to the cipher is as follows: Uberti, et al. Expires 5 February 2023 [Page 8] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 Plaintext = CSRC identifiers (if used) || header extension data || RTP payload || RTP padding (if used) || RTP pad count (if used). Here "header extension data" refers to the content of the RTP extension field, excluding the first four bytes (the RFC 8285 extension header). The first 4 * CSRC count (CC) bytes of the ciphertext are placed in the CSRC field of the RTP header. The remainder of the ciphertext is the RTP payload of the encrypted packet. To minimize changes to surrounding code, the encryption mechanism can choose to replace a "defined by profile" field from [RFC8285] with its counterpart defined in RTP Header Processing above and encrypt at the same time. For AEAD ciphers (e.g., GCM), the 12-byte fixed header and the four- byte header extension header (the "defined by profile" field and the length) are considered AAD, even though they are non-contiguous in the packet if CSRCs are present. Associated Data: fixed header || extension header (if X=1) Here "fixed header" refers to the 12-byte fixed portion of the RTP header, and "extension header" refers to the four-byte RFC 8285 extension header ("defined by profile" and extension length). Implementations can rearrange a packet so that the AAD and plaintext are contiguous by swapping the order of the extension header and the CSRC identifiers, resulting in an intermediate representation of the form shown in Figure 2. After encryption, the CSRCs (now encrypted) and extension header would need to be swapped back to their original positions. A similar operation can be done when decrypting to create contiguous ciphertext and AAD inputs. Uberti, et al. Expires 5 February 2023 [Page 9] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |V=2|P|X| CC |M| PT | sequence number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | timestamp | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | synchronization source (SSRC) identifier | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 0xC0 or 0xC2 | 0xDE | length | | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<+ | | contributing source (CSRC) identifiers | | | | .... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | RFC 8285 header extensions | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | payload ... | | | | +-------------------------------+ | | | | RTP padding | RTP pad count | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +- Plaintext Input AAD Input ---+ Figure 2: An RTP packet transformed to make Cryptex cipher inputs contiguous Note: This intermediate representation is only displayed as reference for implementations and is not meant to be sent on the wire. 6.3. Decryption Procedure The decryption procedure is identical to that of [RFC3711] except for the Encrypted Portion of the SRTP packet, which is as shown in the section above. To minimize changes to surrounding code, the decryption mechanism can choose to replace the "defined by profile" field with its no- encryption counterpart from [RFC8285] and decrypt at the same time. 7. Backwards Compatibility This specification attempts to encrypt as much as possible without interfering with backwards compatibility for systems that expect a certain structure from an RTPv2 packet, including systems that perform demultiplexing based on packet headers. Accordingly, the first two bytes of the RTP packet are not encrypted. Uberti, et al. Expires 5 February 2023 [Page 10] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 This specification also attempts to reuse the key scheduling from SRTP, which depends on the RTP packet sequence number and SSRC identifier. Accordingly, these values are also not encrypted. 8. Security Considerations All security considerations in [RFC3711] section 9 are applicable to this specification, except section 9.4. Confidentiality of the RTP Header which is the purpose of this specification. The risks of using weak or NULL authentication with SRTP, described in Section 9.5 of [RFC3711], apply to encrypted header extensions as well. This specification extends SRTP by expanding the Encrypted Portion of the RTP packet, as shown in Packet Structure. It does not change how SRTP authentication works in any way. Given that more of the packet is being encrypted than before, this is necessarily an improvement. The RTP fields that are left unencrypted (see rationale above) are as follows: * RTP version * padding bit * extension bit * number of CSRCs * marker bit * payload type * sequence number * timestamp * SSRC identifier * number of [RFC8285] header extensions These values contain a fixed set (i.e., one that won't be changed by extensions) of information that, at present, is observed to have low sensitivity. In the event any of these values need to be encrypted, SRTP is likely the wrong protocol to use and a fully-encapsulating protocol such as DTLS is preferred (with its attendant per-packet overhead). Uberti, et al. Expires 5 February 2023 [Page 11] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 9. IANA Considerations 9.1. SDP cryptex Attribute This document updates the "Session Description Protocol Parameters" as specified in Section 8.2.4 of [RFC8866]. Specifically, it adds the SDP "a=cryptex" attribute to the Attribute Names () registry for both media and session level usage. Contact name: IETF AVT Working Group or IESG if AVT is closed Contact email address: avt@ietf.org Attribute name: cryptex Attribute syntax: This attribute takes no values. Attribute semantics: N/A Attribute value: N/A Usage level: session, media Charset dependent: No Purpose: The presence of this attribute in the SDP indicates that the endpoint is capable of receiving RTP packets encrypted with Cryptex as described in this document. O/A procedures: SDP O/A procedures are described in Section 4 of this document. Mux Category: TRANSPORT 10. Acknowledgements The authors wish to thank Lennart Grahl for pointing out many of the issues with the existing header encryption mechanism, as well as suggestions for this proposal. Thanks also to Jonathan Lennox, Inaki Castillo, and Bernard Aboba for their review and suggestions. 11. References 11.1. Normative References Uberti, et al. Expires 5 February 2023 [Page 12] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017, . [RFC8859] Nandakumar, S., "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, January 2021, . [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", RFC 8866, DOI 10.17487/RFC8866, January 2021, . [RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 9143, DOI 10.17487/RFC9143, February 2022, . 11.2. Informative References Uberti, et al. Expires 5 February 2023 [Page 13] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, . [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- time Transport Protocol (RTP) Header Extension for Mixer- to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, December 2011, . [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, . [RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)", RFC 7714, DOI 10.17487/RFC7714, December 2015, . Appendix A. Test Vectors All values are in hexadecimal and represented in network order (big endian). A.1. AES-CTR The following section list the test vectors for using cryptex with AES-CTR as per [RFC3711] Common values are organized as follows: Rollover Counter: 00000000 Master Key: e1f97a0d3e018be0d64fa32c06de4139 Master Salt: 0ec675ad498afeebb6960b3aabe6 Crypto Suite: AES_CM_128_HMAC_SHA1_80 Session Key: c61e7a93744f39ee10734afe3ff7a087 Session Salt: 30cbbc08863d8c85d49db34a9ae1 Authentication Key: cebe321f6ff7716b6fd4ab49af256a156d38baa4 A.1.1. RTP Packet with 1-byte header extension RTP Packet: Uberti, et al. Expires 5 February 2023 [Page 14] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 900f1235 decafbad cafebabe bede0001 51000200 abababab abababab abababab abababab Encrypted RTP Packet: 900f1235 decafbad cafebabe c0de0001 eb923652 51c3e036 f8de27e9 c27ee3e0 b4651d9f bc4218a7 0244522f 34a5 A.1.2. RTP Packet with 2-byte header extension RTP Packet: 900f1236 decafbad cafebabe 10000001 05020002 abababab abababab abababab abababab Encrypted RTP Packet: Uberti, et al. Expires 5 February 2023 [Page 15] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 900f1236 decafbad cafebabe c2de0001 4ed9cc4e 6a712b30 96c5ca77 339d4204 ce0d7739 6cab6958 5fbce381 94a5 A.1.3. RTP Packet with 1-byte header extension and CSRC fields RTP Packet: 920f1238 decafbad cafebabe 0001e240 0000b26e bede0001 51000200 abababab abababab abababab abababab Encrypted RTP Packet: 920f1238 decafbad cafebabe 8bb6e12b 5cff16dd c0de0001 92838c8c 09e58393 e1de3a9a 74734d67 45671338 c3acf11d a2df8423 bee0 Uberti, et al. Expires 5 February 2023 [Page 16] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 A.1.4. RTP Packet with 2-byte header extension and CSRC fields RTP Packet: 920f1239 decafbad cafebabe 0001e240 0000b26e 10000001 05020002 abababab abababab abababab abababab Encrypted RTP Packet: 920f1239 decafbad cafebabe f70e513e b90b9b25 c2de0001 bbed4848 faa64466 5f3d7f34 125914e9 f4d0ae92 3c6f479b 95a0f7b5 3133 A.1.5. RTP Packet with empty 1-byte header extension and CSRC fields RTP Packet: 920f123a decafbad cafebabe 0001e240 0000b26e bede0000 abababab abababab abababab abababab Uberti, et al. Expires 5 February 2023 [Page 17] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 Encrypted RTP Packet: 920f123a decafbad cafebabe 7130b6ab fe2ab0e3 c0de0000 e3d9f64b 25c9e74c b4cf8e43 fb92e378 1c2c0cea b6b3a499 a14c A.1.6. RTP Packet with empty 2-byte header extension and CSRC fields RTP Packet: 920f123b decafbad cafebabe 0001e240 0000b26e 10000000 abababab abababab abababab abababab Encrypted RTP Packet: 920f123b decafbad cafebabe cbf24c12 4330e1c8 c2de0000 599dd45b c9d687b6 03e8b59d 771fd38e 88b170e0 cd31e125 eabe Uberti, et al. Expires 5 February 2023 [Page 18] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 A.2. AES-GCM The following section list the test vectors for using cryptex with AES-GCM as per [RFC7714] Common values are organized as follows: Rollover Counter: 00000000 Master Key: 000102030405060708090a0b0c0d0e0f Master Salt: a0a1a2a3a4a5a6a7a8a9aaab Crypto Suite: AEAD_AES_128_GCM Session Key: 077c6143cb221bc355ff23d5f984a16e Session Salt: 9af3e95364ebac9c99c5a7c4 A.2.1. RTP Packet with 1-byte header extension RTP Packet: 900f1235 decafbad cafebabe bede0001 51000200 abababab abababab abababab abababab Encrypted RTP Packet: 900f1235 decafbad cafebabe c0de0001 39972dc9 572c4d99 e8fc355d e743fb2e 94f9d8ff 54e72f41 93bbc5c7 4ffab0fa 9fa0fbeb A.2.2. RTP Packet with 2-byte header extension RTP Packet: Uberti, et al. Expires 5 February 2023 [Page 19] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 900f1236 decafbad cafebabe 10000001 05020002 abababab abababab abababab abababab Encrypted RTP Packet: 900f1236 decafbad cafebabe c2de0001 bb75a4c5 45cd1f41 3bdb7daa 2b1e3263 de313667 c9632490 81b35a65 f5cb6c88 b394235f A.2.3. RTP Packet with 1-byte header extension and CSRC fields RTP Packet: 920f1238 decafbad cafebabe 0001e240 0000b26e bede0001 51000200 abababab abababab abababab abababab Encrypted RTP Packet: Uberti, et al. Expires 5 February 2023 [Page 20] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 920f1238 decafbad cafebabe 63bbccc4 a7f695c4 c0de0001 8ad7c71f ac70a80c 92866b4c 6ba98546 ef913586 e95ffaaf fe956885 bb0647a8 bc094ac8 A.2.4. RTP Packet with 2-byte header extension and CSRC fields RTP Packet: 920f1239 decafbad cafebabe 0001e240 0000b26e 10000001 05020002 abababab abababab abababab abababab Encrypted RTP Packet: Uberti, et al. Expires 5 February 2023 [Page 21] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 920f1239 decafbad cafebabe 3680524f 8d312b00 c2de0001 c78d1200 38422bc1 11a7187a 18246f98 0c059cc6 bc9df8b6 26394eca 344e4b05 d80fea83 A.2.5. RTP Packet with empty 1-byte header extension and CSRC fields RTP Packet: 920f123a decafbad cafebabe 0001e240 0000b26e bede0000 abababab abababab abababab abababab Encrypted RTP Packet: 920f123a decafbad cafebabe 15b6bb43 37906fff c0de0000 b7b96453 7a2b03ab 7ba5389c e9331712 6b5d974d f30c6884 dcb651c5 e120c1da Uberti, et al. Expires 5 February 2023 [Page 22] Internet-Draft Completely Encrypting RTP Header Extensi August 2022 A.2.6. RTP Packet with empty 2-byte header extension and CSRC fields RTP Packet: 920f123b decafbad cafebabe 0001e240 0000b26e 10000000 abababab abababab abababab abababab Encrypted RTP Packet: 920f123b decafbad cafebabe dcb38c9e 48bf95f4 c2de0000 61ee432c f9203170 76613258 d3ce4236 c06ac429 681ad084 13512dc9 8b5207d8 Authors' Addresses Justin Uberti Clubhouse Email: justin@uberti.name Cullen Jennings Cisco Email: fluffy@iii.ca Sergio Garcia Murillo Millicast Email: sergio.garcia.murillo@cosmosoftware.io Uberti, et al. Expires 5 February 2023 [Page 23] ./draft-ietf-tcpm-yang-tcp-09.txt0000644000764400076440000016302214307427043016350 0ustar iustiniustin TCPM M. Scharf Internet-Draft Hochschule Esslingen Intended status: Standards Track M. Jethanandani Expires: 15 March 2023 Kloud Services V. Murgai Samsung 11 September 2022 A YANG Model for Transmission Control Protocol (TCP) Configuration and State draft-ietf-tcpm-yang-tcp-09 Abstract This document specifies a minimal YANG model for TCP on devices that are configured and managed by network management protocols. The YANG model defines a container for all TCP connections, and groupings of authentication parameters that can be imported and used in TCP implementations or by other models that need to configure TCP parameters. The model also includes basic TCP statistics. The model is compliant with Network Management Datastore Architecture (NMDA) (RFC 8342). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 15 March 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Scharf, et al. Expires 15 March 2023 [Page 1] Internet-Draft YANG Model for TCP September 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2.1. Note to RFC Editor . . . . . . . . . . . . . . . . . . . 4 3. YANG Module Overview . . . . . . . . . . . . . . . . . . . . 4 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Model Design . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6 4. TCP YANG Model . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 19 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Normative References . . . . . . . . . . . . . . . . . . 21 7.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 25 B.1. Keepalive Configuration . . . . . . . . . . . . . . . . . 26 B.2. TCP-AO Configuration . . . . . . . . . . . . . . . . . . 26 Appendix C. Complete Tree Diagram . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction The Transmission Control Protocol (TCP) [RFC9293] is used by many applications in the Internet, including control and management protocols. As such, TCP is implemented on network elements that can be configured and managed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. This document specifies a minimal YANG 1.1 [RFC7950] model for configuring and managing TCP on network elements that support YANG, a TCP connection table, a TCP listener table containing information about a particular TCP listener, and an augmentation of the YANG Data Model for Key Chains [RFC8177] to support authentication. The YANG module specified in this document is compliant with Network Management Datastore Architecture (NMDA) [RFC8342]. Scharf, et al. Expires 15 March 2023 [Page 2] Internet-Draft YANG Model for TCP September 2022 The YANG module has a narrow scope and focuses on a subset of fundamental TCP functions and basic statistics. It defines a container for a list of TCP connections that includes definitions from YANG Groupings for TCP Clients and TCP Servers [I-D.ietf-netconf-tcp-client-server]. The model adheres to the recommendation in BGP/MPLS IP Virtual Private Networks [RFC4364]. Therefore it allows enabling of TCP-AO [RFC5925], and accommodates the installed base that makes use of MD5. The module can be augmented or updated to address more advanced or implementation- specific TCP features in the future. This specification does not deprecate the Management Information Base (MIB) for the Transmission Control Protocol (TCP) [RFC4022]. The basic statistics defined in this document follow the model of the TCP MIB. An TCP Extended Statistics MIB [RFC4898] is also available, but this document does not cover such extended statistics. The YANG module also omits some selected parameters included in TCP MIB, most notably Retransmission Timeout (RTO) configuration and a maximum connection limit. This is a conscious decision as these parameters hardly matter in a state-of-the-art TCP implementation. It would also be possible to translate a MIB into a YANG module, for instance using Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules [RFC6643]. However, this approach is not used in this document, because a translated model would not be up-to-date. There are other existing TCP-related YANG models, which are orthogonal to this specification. Examples are: * TCP header attributes are modeled in other security-related models, such as YANG Data Model for Network Access Control Lists (ACLs) [RFC8519], Distributed Denial-of-Service Open Thread Signaling (DOTS) Data Channel Specification [RFC8783], I2NSF Capability YANG Data Model [I-D.ietf-i2nsf-capability-data-model], or I2NSF Network Security Function-Facing Interface YANG Data Model [I-D.ietf-i2nsf-nsf-facing-interface-dm]. * TCP-related configuration of a NAT (e.g., NAT44, NAT64, Destination NAT) is defined in A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT) [RFC8512] and A YANG Data Model for Dual-Stack Lite (DS-Lite) [RFC8513]. * TCP-AO and TCP MD5 configuration for Layer 3 VPNs is modeled in A Layer 3 VPN Network YANG Model [RFC9182]. This model assumes that TCP-AO specific parameters are preconfigured in addition to the keychain parameters. Scharf, et al. Expires 15 March 2023 [Page 3] Internet-Draft YANG Model for TCP September 2022 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.1. Note to RFC Editor This document uses several placeholder values throughout the document. Please replace them as follows and remove this note before publication. RFC XXXX, where XXXX is the number assigned to this document at the time of publication. 2022-09-11 with the actual date of the publication of this document. 3. YANG Module Overview 3.1. Scope TCP is implemented on different system architectures. As a result, there are many different and often implementation-specific ways to configure parameters of the TCP engine. In addition, in many TCP/IP stacks configuration exists for different scopes: * System-wide configuration: Many TCP implementations have configuration parameters that affect all TCP connections from or to this TCP stack. Typical examples include enabling or disabling optional protocol features. For instance, many implementations can turn on or off use of window scaling Transmission Control Protocol (TCP) Specification [RFC9293] for all TCP connections. * Interface configuration: It can be useful to use different TCP parameters on different interfaces, e.g., different device ports or IP interfaces. In that case, TCP parameters can be part of the interface configuration. Typical examples are the Maximum Segment Size (MSS) or configuration related to hardware offloading. * Connection parameters: Many implementations have means to influence the behavior of each TCP connection, e.g., on the programming interface used by applications. Typical examples are socket options in the socket API, such as disabling the Nagle algorithm Transmission Control Protocol (TCP) Specification [RFC9293] by TCP_NODELAY. If an application uses such an interface, it is possible that the configuration of the Scharf, et al. Expires 15 March 2023 [Page 4] Internet-Draft YANG Model for TCP September 2022 application or application protocol includes TCP-related parameters. An example is the BGP YANG Model for Service Provider Networks [I-D.ietf-idr-bgp-model]. * Application preferences: Setting of TCP parameters can also be part of application preferences, templates, or profiles. An example would be the preferences defined in An Abstract Application Layer Interface to Transport Services [I-D.ietf-taps-interface]. As a result, there is no ground truth for setting certain TCP parameters, and traditionally different TCP implementations have used different modeling approaches. For instance, one implementation may define a given configuration parameter globally, while another one uses per-interface settings, and both approaches work well for the corresponding use cases. Also, different systems may use different default values. In addition, TCP can be implemented in different ways and design choices by the protocol engine often affect configuration options. Nonetheless, a number of TCP stack parameters require configuration by YANG models. This document therefore defines a minimal YANG model with fundamental parameters. An important use case is the TCP configuration on network elements such as routers, which often use YANG data models. The model therefore specifies TCP parameters that are important on such TCP stacks. This in particular applies to the support of TCP-AO [RFC5925] and the corresponding cryptographic algorithms [RFC5926]. TCP Authentication Option (TCP-AO) is used on routers to secure routing protocols such as BGP. In that case, a YANG model for TCP-AO configuration is required. The model defined in this document includes the required parameters for TCP-AO configuration, such as the values of SendID and RecvID. The keychain for TCP-AO can be modeled by the YANG Data Model for Key Chains [RFC8177]. The groupings defined in this document can be imported and used as part of such a preconfiguration. Given an installed base, the model also allows enabling of the legacy TCP MD5 [RFC2385] signature option. The TCP MD5 signature option was obsoleted by TCP-AO in 2010. If current implementations require TCP authentication, it is RECOMMENDED to use TCP-AO [RFC5925]. Similar to the TCP MIB [RFC4022], this document also specifies basic statistics, a TCP connection list, and a TCP listener list. * Statistics: Counters for the number of active/passive opens, sent and received TCP segments, errors, and possibly other detailed debugging information Scharf, et al. Expires 15 March 2023 [Page 5] Internet-Draft YANG Model for TCP September 2022 * TCP connection list: Access to status information for all TCP connections. Note, the connection table is modeled as a list that is read-writeable, even though a connection cannot be created by adding entries to the table. Similarly, deletion of connections from this list is implementation-specific. * TCP listener list: A list containing information about TCP listeners, i.e., applications willing to accept connections. This allows implementations of TCP MIB [RFC4022] to migrate to the YANG model defined in this memo. Note that the TCP MIB does not include means to reset statistics, which are defined in this document. This is not a major addition, as a reset can simply be implemented by storing offset values for the counters. This version of the module does not model details of Multipath TCP [RFC8684]. This could be addressed in a later version of this document. 3.2. Model Design The YANG model defined in this document includes definitions from the YANG Groupings for TCP Clients and TCP Servers [I-D.ietf-netconf-tcp-client-server]. Similar to that model, this specification defines YANG groupings. This allows reuse of these groupings in different YANG data models. It is intended that these groupings will be used either standalone or for TCP-based protocols as part of a stack of protocol-specific configuration models. An example could be the BGP YANG Model for Service Provider Networks [I-D.ietf-idr-bgp-model]. 3.3. Tree Diagram This section provides an abridged tree diagram for the YANG module defined in this document. Annotations used in the diagram are defined in YANG Tree Diagrams [RFC8340]. A complete tree diagram can be found in the Appendix. Scharf, et al. Expires 15 March 2023 [Page 6] Internet-Draft YANG Model for TCP September 2022 module: ietf-tcp +--rw tcp! +--rw connections | ... +--ro tcp-listeners* [type address port] | ... +--ro statistics {statistics}? ... augment /key-chain:key-chains/key-chain:key-chain/key-chain:key: +--rw authentication {authentication}? +--rw keychain? key-chain:key-chain-ref +--rw (authentication)? ... 4. TCP YANG Model This YANG module references The TCP Authentication Option [RFC5925], Protection of BGP Sessions via the TCP MD5 Signature [RFC2385], Transmission Control Protocol (TCP) Specification [RFC9293], and imports Common YANG Data Types [RFC6991], The NETCONF Access Control Model [RFC8341], and YANG Groupings for TCP Clients and TCP Servers [I-D.ietf-netconf-tcp-client-server]. file "ietf-tcp@2022-09-11.yang" module ietf-tcp { yang-version "1.1"; namespace "urn:ietf:params:xml:ns:yang:ietf-tcp"; prefix "tcp"; import ietf-yang-types { prefix "yang"; reference "RFC 6991: Common YANG Data Types."; } import ietf-tcp-common { prefix "tcpcmn"; reference "I-D.ietf-netconf-tcp-client-server: YANG Groupings for TCP Clients and TCP Servers."; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types."; } import ietf-netconf-acm { prefix nacm; Scharf, et al. Expires 15 March 2023 [Page 7] Internet-Draft YANG Model for TCP September 2022 reference "RFC 8341: Network Configuration Access Control Model"; } import ietf-key-chain { prefix key-chain; reference "RFC 8177: YANG Key Chain."; } organization "IETF TCPM Working Group"; contact "WG Web: WG List: Authors: Michael Scharf (michael.scharf at hs-esslingen dot de) Mahesh Jethanandani (mjethanandani at gmail dot com) Vishal Murgai (vmurgai at gmail dot com)"; description "This module focuses on fundamental TCP functions and basic statistics. The model can be augmented to address more advanced or implementation specific TCP features. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision "2022-09-11" { description "Initial Version"; Scharf, et al. Expires 15 March 2023 [Page 8] Internet-Draft YANG Model for TCP September 2022 reference "RFC XXXX, A YANG Model for Transmission Control Protocol (TCP) Configuration and State."; } // Typedefs typedef mss { type uint16; description "Type definition for Maximum Segment Size."; } // Features feature statistics { description "This implementation supports statistics reporting."; } feature authentication { description "This implementation supports authentication."; } // Identities identity aes-128 { base key-chain:crypto-algorithm; description "AES128 authentication algorithm used by TCP-AO."; reference "RFC 5926: Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)."; } // TCP-AO Groupings grouping ao { leaf send-id { type uint8 { range "0..max"; } description "The SendID is inserted as the KeyID of the TCP-AO option of outgoing segments. In a consistent configuration, the SendID matches the RecvID at the other endpoint."; reference "RFC 5925: The TCP Authentication Option, Section 3.1."; } Scharf, et al. Expires 15 March 2023 [Page 9] Internet-Draft YANG Model for TCP September 2022 leaf recv-id { type uint8 { range "0..max"; } description "The RecvID is matched against the TCP-AO KeyID of incoming segments. In a consistent configuration, the RecvID matches the SendID at the other endpoint."; reference "RFC 5925: The TCP Authentication Option, Section 3.1."; } leaf include-tcp-options { type boolean; default true; description "When set to true, TCP options are included in MAC calculation."; reference "RFC 5925: The TCP Authentication Option, Section 3.1."; } leaf accept-key-mismatch { type boolean; description "Accept, when set to true, TCP segments with a Master Key Tuple (MKT) that is not configured."; reference "RFC 5925: The TCP Authentication Option, Section 7.3."; } leaf r-next-key-id { type uint8; config false; description "A field indicating the Master Key Tuple (MKT) that is ready at the sender to be used to authenticate received segments, i.e., the desired 'receive next' key ID."; reference "RFC 5925: The TCP Authentication Option."; } description "Authentication Option (AO) for TCP."; reference "RFC 5925: The TCP Authentication Option."; } Scharf, et al. Expires 15 March 2023 [Page 10] Internet-Draft YANG Model for TCP September 2022 // TCP configuration container tcp { presence "The container for TCP configuration."; description "TCP container."; container connections { list connection { key "local-address remote-address local-port remote-port"; leaf local-address { type inet:ip-address; description "Identifies the address that is used by the local endpoint for the connection, and is one of the four elements that form the connection identifier."; } leaf remote-address { type inet:ip-address; description "Identifies the address that is used by the remote endpoint for the connection, and is one of the four elements that form the connection identifier."; } leaf local-port { type inet:port-number; description "Identifies the local TCP port used for the connection, and is one of the four elements that form the connection identifier."; } leaf remote-port { type inet:port-number; description "Identifies the remote TCP port used for the connection, and is one of the four elements that form the connection identifier."; } leaf mss { type mss; description "Maximum Segment Size (MSS) desired on this connection. Scharf, et al. Expires 15 March 2023 [Page 11] Internet-Draft YANG Model for TCP September 2022 Note, the 'effective send MSS' can be smaller than what is configured here."; reference "RFC 9293: Transmission Control Protocol (TCP) Specification."; } leaf pmtud { type boolean; default false; description "Turns Path Maximum Transmission Unit Discovery (PMTUD) on (true) or off (false)."; reference "RFC 9293: Transmission Control Protocol (TCP) Specification."; } uses tcpcmn:tcp-common-grouping; leaf state { type enumeration { enum closed { value 1; description "Connection is closed. Connections in this state may not appear in this list."; } enum listen { value 2; description "Represents waiting for a connection request from any remote TCP peer and port."; } enum syn-sent { value 3; description "Represents waiting for a matching connection request after having sent a connection request."; } enum syn-received { value 4; description "Represents waiting for a confirming connection request acknowledgment after having both received and sent a connection request."; } enum established { Scharf, et al. Expires 15 March 2023 [Page 12] Internet-Draft YANG Model for TCP September 2022 value 5; description "Represents an open connection, data received can be delivered to the user. The normal state for the data transfer phase of the connection."; } enum fin-wait-1 { value 6; description "Represents waiting for a connection termination request from the remote TCP peer, or an acknowledgment of the connection termination request previously sent."; } enum fin-wait-2 { value 7; description "Represents waiting for a connection termination request from the remote TCP peer."; } enum close-wait { value 8; description "Represents waiting for a connection termination request from the local user."; } enum last-ack { value 9; description "Represents waiting for an acknowledgment of the connection termination request previously sent to the remote TCP peer (this termination request sent to the remote TCP peer already included an acknowledgment of the termination request sent from the remote TCP peer)"; } enum closing { value 10; description "Represents waiting for a connection termination request acknowledgment from the remote TCP peer."; } enum time-wait { value 11; description "Represents waiting for enough time to pass to be sure the remote TCP peer received the acknowledgment of its connection termination request, and to avoid Scharf, et al. Expires 15 March 2023 [Page 13] Internet-Draft YANG Model for TCP September 2022 new connections being impacted by delayed segments from previous connections."; } } config false; description "The state of this TCP connection."; } description "List of TCP connections with their parameters. The list is modeled as writeable even though only some of the nodes are writeable, e.g. keepalive. Connections that are created and match this list SHOULD apply the writeable parameters. At the same time, implementations may not allow creation of new TCP connections simply by adding entries to the list. Furthermore, the behavior upon removal is implementation-specific. Implementations may not support closing or resetting a TCP connection upon an operation that removes the entry from the list. The operational state of this list SHOULD reflect connections that have configured, but not created, and connections that have been created. Connections in CLOSED state are not reflected on this list."; } description "A container of all TCP connections."; } list tcp-listeners { key "type address port"; config false; description "A table containing information about a particular TCP listener."; leaf type { type inet:ip-version; description "The address type of address. The value should be unspecified (0) if connection initiations to all local IP addresses are accepted."; } leaf address { type union { Scharf, et al. Expires 15 March 2023 [Page 14] Internet-Draft YANG Model for TCP September 2022 type inet:ip-address; type string { length 0; } } description "The local IP address for this TCP connection. The value of this node can be represented in three possible ways, depending on the characteristics of the listening application: 1. For an application willing to accept both IPv4 and IPv6 datagrams, the value of this node must be ''h (a zero-length octet-string), with the value of the corresponding 'type' object being unspecified (0). 2. For an application willing to accept only IPv4 or IPv6 datagrams, the value of this node must be '0.0.0.0' or '::' respectively, with 'type' representing the appropriate address type. 3. For an application which is listening for data destined only to a specific IP address, the value of this node is the specific local address, with 'type' representing the appropriate address type."; } leaf port { type inet:port-number; description "The local port number for this TCP connection."; } } container statistics { if-feature statistics; config false; leaf active-opens { type yang:counter64; description "The number of times that TCP connections have made a direct transition to the SYN-SENT state from the CLOSED state."; reference "RFC 9293: Transmission Control Protocol (TCP) Scharf, et al. Expires 15 March 2023 [Page 15] Internet-Draft YANG Model for TCP September 2022 Specification."; } leaf passive-opens { type yang:counter64; description "The number of times TCP connections have made a direct transition to the SYN-RCVD state from the LISTEN state."; reference "RFC 9293: Transmission Control Protocol (TCP) Specification."; } leaf attempt-fails { type yang:counter64; description "The number of times that TCP connections have made a direct transition to the CLOSED state from either the SYN-SENT state or the SYN-RCVD state, plus the number of times that TCP connections have made a direct transition to the LISTEN state from the SYN-RCVD state."; reference "RFC 9293: Transmission Control Protocol (TCP) Specification."; } leaf establish-resets { type yang:counter64; description "The number of times that TCP connections have made a direct transition to the CLOSED state from either the ESTABLISHED state or the CLOSE-WAIT state."; reference "RFC 9293: Transmission Control Protocol (TCP) Specification."; } leaf currently-established { type yang:gauge32; description "The number of TCP connections for which the current state is either ESTABLISHED or CLOSE-WAIT."; reference "RFC 9293: Transmission Control Protocol (TCP) Specification."; } leaf in-segments { Scharf, et al. Expires 15 March 2023 [Page 16] Internet-Draft YANG Model for TCP September 2022 type yang:counter64; description "The total number of TCP segments received, including those received in error. This count includes TCP segments received on currently established connections."; reference "RFC 9293: Transmission Control Protocol (TCP) Specification."; } leaf out-segments { type yang:counter64; description "The total number of TCP segments sent, including those on current connections but excluding those containing only retransmitted octets."; reference "RFC 9293: Transmission Control Protocol (TCP) Specification."; } leaf retransmitted-segments { type yang:counter64; description "The total number of TCP segments retransmitted; that is, the number of TCP segments transmitted containing one or more previously transmitted octets."; reference "RFC 9293: Transmission Control Protocol (TCP) Specification."; } leaf in-errors { type yang:counter64; description "The total number of TCP segments received in error (e.g., bad TCP checksums)."; reference "RFC 9293: Transmission Control Protocol (TCP) Specification."; } leaf out-resets { type yang:counter64; description "The number of TCP segments sent containing the RST flag."; reference "RFC 9293: Transmission Control Protocol (TCP) Scharf, et al. Expires 15 March 2023 [Page 17] Internet-Draft YANG Model for TCP September 2022 Specification."; } leaf auth-failures { if-feature authentication; type yang:counter64; description "The number of times that authentication has failed either with TCP-AO or MD5."; } action reset { nacm:default-deny-all; description "Reset statistics action command."; input { leaf reset-at { type yang:date-and-time; description "Time when the reset action needs to be executed."; } } output { leaf reset-finished-at { type yang:date-and-time; description "Time when the reset action command completed."; } } } description "Statistics across all connections."; } } augment "/key-chain:key-chains/key-chain:key-chain/key-chain:key" { description "Augmentation of the key-chain model to add TCP-AO and TCP-MD5 authentication."; container authentication { if-feature authentication; leaf keychain { type key-chain:key-chain-ref; description "Reference to the key chain that will be used by this model. Applicable for TCP-AO and TCP-MD5 Scharf, et al. Expires 15 March 2023 [Page 18] Internet-Draft YANG Model for TCP September 2022 only"; reference "RFC 8177: YANG Key Chain."; } choice authentication { container ao { presence "Presence container for all TCP-AO related" + " configuration"; uses ao; description "Use TCP-AO to secure the connection."; } container md5 { presence "Presence container for all MD5 related" + " configuration"; description "Use TCP-MD5 to secure the connection. As the TCP MD5 signature option is obsoleted by TCP-AO, it is RECOMMENDED to use TCP-AO instead."; reference "RFC 2385: Protection of BGP Sessions via the TCP MD5 Signature."; } description "Choice of TCP authentication."; } description "Authentication definitions for TCP configuration. This includes parameters such as how to secure the connection, that can be part of either the client or server."; } } } 5. IANA Considerations 5.1. The IETF XML Registry This document registers an URI in the "ns" subregistry of the IETF XML Registry [RFC3688]. Following the format in IETF XML Registry [RFC3688], the following registration is requested: Scharf, et al. Expires 15 March 2023 [Page 19] Internet-Draft YANG Model for TCP September 2022 URI: urn:ietf:params:xml:ns:yang:ietf-tcp Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. 5.2. The YANG Module Names Registry The following entry is requested to be added to the "YANG Module Names" registry created by YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) [RFC6020]: name: ietf-tcp namespace: urn:ietf:params:xml:ns:yang:ietf-tcp prefix: tcp reference: RFC XXXX (this document) The registration is not maintained by IANA. 6. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) described in Using the NETCONF protocol over SSH [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: * Common configuration included from NETCONF Client and Server Models [I-D.ietf-netconf-tcp-client-server]. Unrestricted access to all the nodes, e.g., keepalive idle-timer, can cause connections to fail or to timeout prematurely. Scharf, et al. Expires 15 March 2023 [Page 20] Internet-Draft YANG Model for TCP September 2022 * Authentication configuration. Unrestricted access to the nodes under authentication configuration can prevent the use of authenticated communication and cause connection setups to fail. This can result in massive security vulnerabilities and service disruption for the traffic requiring authentication. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: * Unrestricted access to connection information of the client or server can be used by a malicious user to launch an attack. * Similarly, unrestricted access to statistics of the client or server can be used by a malicious user to exploit any vulnerabilities of the system. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: * The YANG module allows for the statistics to be cleared by executing the reset action. This action should be restricted to users with the right permission. The module specified in this document supports MD5 to basically accommodate the installed BGP base. MD5 suffers from the security weaknesses discussed in Section 2 of RFC 6151 [RFC6151] or Section 2.1 of RFC 6952 [RFC6952]. 7. References 7.1. Normative References [I-D.ietf-netconf-tcp-client-server] Watsen, K. and M. Scharf, "YANG Groupings for TCP Clients and TCP Servers", Work in Progress, Internet-Draft, draft- ietf-netconf-tcp-client-server-13, 24 May 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Scharf, et al. Expires 15 March 2023 [Page 21] Internet-Draft YANG Model for TCP September 2022 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1998, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, DOI 10.17487/RFC5926, June 2010, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Scharf, et al. Expires 15 March 2023 [Page 22] Internet-Draft YANG Model for TCP September 2022 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10.17487/RFC8177, June 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . 7.2. Informative References [I-D.ietf-i2nsf-capability-data-model] Hares, S., Jeong, J. P., Kim, J. T., Moskowitz, R., and Q. Lin, "I2NSF Capability YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-i2nsf-capability-data-model-32, 23 May 2022, . [I-D.ietf-i2nsf-nsf-facing-interface-dm] Kim, J. T., Jeong, J. P., Park, J., Hares, S., and Q. Lin, "I2NSF Network Security Function-Facing Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf- i2nsf-nsf-facing-interface-dm-29, 1 June 2022, . Scharf, et al. Expires 15 March 2023 [Page 23] Internet-Draft YANG Model for TCP September 2022 [I-D.ietf-idr-bgp-model] Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP YANG Model for Service Provider Networks", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-14, 3 July 2022, . [I-D.ietf-taps-interface] Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Kuehlewind, M., Perkins, C., Tiesel, P. S., and T. Pauly, "An Abstract Application Layer Interface to Transport Services", Work in Progress, Internet-Draft, draft-ietf- taps-interface-16, 31 August 2022, . [RFC4022] Raghunarayan, R., Ed., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, DOI 10.17487/RFC4022, March 2005, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP Extended Statistics MIB", RFC 4898, DOI 10.17487/RFC4898, May 2007, . [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, . [RFC6643] Schoenwaelder, J., "Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012, . [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, . Scharf, et al. Expires 15 March 2023 [Page 24] Internet-Draft YANG Model for TCP September 2022 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., Vinapamula, S., and Q. Wu, "A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, . [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, DOI 10.17487/RFC8513, January 2019, . [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, DOI 10.17487/RFC8519, March 2019, . [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, . [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", RFC 8783, DOI 10.17487/RFC8783, May 2020, . [RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, February 2022, . [RFC9235] Touch, J. and J. Kuusisaari, "TCP Authentication Option (TCP-AO) Test Vectors", RFC 9235, DOI 10.17487/RFC9235, May 2022, . Appendix A. Acknowledgements Michael Scharf was supported by the StandICT.eu project, which is funded by the European Commission under the Horizon 2020 Programme. The following persons have contributed to this document by reviews (in alphabetical order): Mohamed Boucadair, Gorry Fairhurst, Jeffrey Haas, and Tom Petch. Appendix B. Examples Scharf, et al. Expires 15 March 2023 [Page 25] Internet-Draft YANG Model for TCP September 2022 B.1. Keepalive Configuration This particular example demonstrates how both a particular connection can be configured for keepalives. NOTE: '\' line wrapping per RFC 8792 192.0.2.1 192.0.2.2 1025 22 1400 true 5 5 10 B.2. TCP-AO Configuration The following example demonstrates how to model a TCP-AO [RFC5925] configuration for the example in TCP-AO Test Vectors [RFC9235]. The IP addresses and other parameters are taken from the test vectors. Scharf, et al. Expires 15 March 2023 [Page 26] Internet-Draft YANG Model for TCP September 2022 NOTE: '\' line wrapping per RFC 8792 ao-config "An example for TCP-AO configuration."\ 55 2017-01-01T00:00:00Z 2017-02-01T00:00:00Z 2016-12-31T23:59:55Z 2017-02-01T00:00:05Z tcp:aes-128 testvector ao-config 61 84 Scharf, et al. Expires 15 March 2023 [Page 27] Internet-Draft YANG Model for TCP September 2022 Appendix C. Complete Tree Diagram Here is the complete tree diagram for the TCP YANG model. module: ietf-tcp +--rw tcp! +--rw connections | +--rw connection* | [local-address remote-address local-port remote-port] | +--rw local-address inet:ip-address | +--rw remote-address inet:ip-address | +--rw local-port inet:port-number | +--rw remote-port inet:port-number | +--rw mss? mss | +--rw pmtud? boolean | +--rw keepalives! {keepalives-supported}? | | +--rw idle-time uint16 | | +--rw max-probes uint16 | | +--rw probe-interval uint16 | +--ro state? enumeration +--ro tcp-listeners* [type address port] | +--ro type inet:ip-version | +--ro address union | +--ro port inet:port-number +--ro statistics {statistics}? +--ro active-opens? yang:counter64 +--ro passive-opens? yang:counter64 +--ro attempt-fails? yang:counter64 +--ro establish-resets? yang:counter64 +--ro currently-established? yang:gauge32 +--ro in-segments? yang:counter64 +--ro out-segments? yang:counter64 +--ro retransmitted-segments? yang:counter64 +--ro in-errors? yang:counter64 +--ro out-resets? yang:counter64 +--ro auth-failures? yang:counter64 | {authentication}? +---x reset +---w input | +---w reset-at? yang:date-and-time +--ro output +--ro reset-finished-at? yang:date-and-time augment /key-chain:key-chains/key-chain:key-chain/key-chain:key: +--rw authentication {authentication}? +--rw keychain? key-chain:key-chain-ref +--rw (authentication)? +--:(ao) Scharf, et al. Expires 15 March 2023 [Page 28] Internet-Draft YANG Model for TCP September 2022 | +--rw ao! | +--rw send-id? uint8 | +--rw recv-id? uint8 | +--rw include-tcp-options? boolean | +--rw accept-key-mismatch? boolean | +--ro r-next-key-id? uint8 +--:(md5) +--rw md5! Authors' Addresses Michael Scharf Hochschule Esslingen - University of Applied Sciences Kanalstr. 33 73728 Esslingen Germany Email: michael.scharf@hs-esslingen.de Mahesh Jethanandani Kloud Services Email: mjethanandani@gmail.com Vishal Murgai Samsung Email: vmurgai@gmail.com Scharf, et al. Expires 15 March 2023 [Page 29] ./draft-ietf-avtext-lrr-07.txt0000644000764400076440000007633613126302536016003 0ustar iustiniustin Payload Working Group J. Lennox Internet-Draft D. Hong Intended status: Standards Track Vidyo Expires: December 31, 2017 J. Uberti S. Holmer M. Flodman Google June 29, 2017 The Layer Refresh Request (LRR) RTCP Feedback Message draft-ietf-avtext-lrr-07 Abstract This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several RTP payloads for scalable media formats. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 31, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Lennox, et al. Expires December 31, 2017 [Page 1] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 2 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Layer Refresh Request . . . . . . . . . . . . . . . . . . . . 5 3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6 3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Usage with specific codecs . . . . . . . . . . . . . . . . . 8 4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. H265 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Usage with different scalability transmission mechanisms . . 11 6. SDP Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction This memo describes an RTCP [RFC3550] Payload-Specific Feedback Message [RFC4585] "Layer Refresh Request" (LRR). It is designed to allow a receiver of a layered media stream to request that one or more of its substreams be refreshed, such that it can then be decoded by an endpoint which previously was not receiving those layers, without requiring that the entire stream be refreshed (as it would be if the receiver sent a Full Intra Request (FIR); [RFC5104] see also [RFC8082]). The feedback message is applicable both to temporally and spatially scaled streams, and to both single-stream and multi-stream scalability modes. 2. Conventions, Definitions and Acronyms 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]. Lennox, et al. Expires December 31, 2017 [Page 2] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 2.1. Terminology A "Layer Refresh Point" is a point in a scalable stream after which a decoder, which previously had been able to decode only some (possibly none) of the available layers of stream, is able to decode a greater number of the layers. For spatial (or quality) layers, in normal encoding, a subpicture can depend both on earlier pictures of that spatial layer and also on lower-layer pictures of the current picture. A layer refresh, however, typically requires that a spatial layer picture be encoded in a way that references only the lower-layer subpictures of the current picture, not any earlier pictures of that spatial layer. Additionally, the encoder must promise that no earlier pictures of that spatial layer will be used as reference in the future. However, even in a layer refresh, layers other than the ones being refreshed may still maintain dependency on earlier content of the stream. This is the difference between a layer refresh and a Full Intra Request [RFC5104]. This minimizes the coding overhead of refresh to only those parts of the stream that actually need to be refreshed at any given time. An illustration of spatial layer refresh of an enhancement layer is shown below. <-- indicates a coding dependency. ... <-- S1 <-- S1 S1 <-- S1 <-- ... | | | | \/ \/ \/ \/ ... <-- S0 <-- S0 <-- S0 <-- S0 <-- ... 1 2 3 4 Figure 1 In Figure 1, frame 3 is a layer refresh point for spatial layer S1; a decoder which had previously only been decoding spatial layer S0 would be able to decode layer S1 starting at frame 3. Lennox, et al. Expires December 31, 2017 [Page 3] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 An illustration of spatial layer refresh of a base layer is shown below. <-- indicates a coding dependency. ... <-- S1 <-- S1 <-- S1 <-- S1 <-- ... | | | | \/ \/ \/ \/ ... <-- S0 <-- S0 S0 <-- S0 <-- ... 1 2 3 4 Figure 2 In Figure 2, frame 3 is a layer refresh point for spatial layer S0; a decoder which had previously not been decoding the stream at all could decode layer S0 starting at frame 3. For temporal layers, while normal encoding allows frames to depend on earlier frames of the same temporal layer, layer refresh requires that the layer be "temporally nested", i.e. use as reference only earlier frames of a lower temporal layer, not any earlier frames of this temporal layer, and also promise that no future frames of this temporal layer will reference frames of this temporal layer before the refresh point. In many cases, the temporal structure of the stream will mean that all frames are temporally nested, in which case decoders will have no need to send LRR messages for the stream. An illustration of temporal layer refresh is shown below. <-- indicates a coding dependency. ... <----- T1 <------ T1 T1 <------ ... / / / |_ |_ |_ ... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... 1 2 3 4 5 6 7 Figure 3 In Figure 3, frame 6 is a layer refresh point for temporal layer T1; a decoder which had previously only been decoding temporal layer T0 would be able to decode layer T1 starting at frame 6. Lennox, et al. Expires December 31, 2017 [Page 4] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 An illustration of an inherently temporally nested stream is shown below. <-- indicates a coding dependency. T1 T1 T1 / / / |_ |_ |_ ... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... 1 2 3 4 5 6 7 Figure 4 In Figure 4, the stream is temporally nested in its ordinary structure; a decoder receiving layer T0 can begin decoding layer T1 at any point. A "Layer Index" is a numeric label for a specific spatial and temporal layer of a scalable stream. It consists of the pair of a "temporal ID" identifying the temporal layer, and a "layer ID" identifying the spatial or quality layer. The details of how layers of a scalable stream are labeled are codec-specific. Details for several codecs are defined in Section 4. 3. Layer Refresh Request A layer refresh frame can be requested by sending a Layer Refresh Request (LRR), which is an RTP Control Protocol (RTCP) [RFC3550] payload-specific feedback message [RFC4585] asking the encoder to encode a frame which makes it possible to upgrade to a higher layer. The LRR contains one or two tuples, indicating the temporal and spatial layer the decoder wants to upgrade to, and (optionally) the currently highest temporal and spatial layer the decoder can decode. The specific format of the tuples, and the mechanism by which a receiver recognizes a refresh frame, is codec-dependent. Usage for several codecs is discussed in Section 4. LRR follows the model of the Full Intra Request (FIR) [RFC5104] (Section 3.5.1) for its retransmission, reliability, and use in multipoint conferences. The LRR message is identified by RTCP packet type value PT=PSFB and FMT=TBD. The FCI field MUST contain one or more LRR entries. Each entry applies to a different media sender, identified by its SSRC. [NOTE TO RFC Editor: Please replace "TBD" with the IANA-assigned payload-specific feedback number.] Lennox, et al. Expires December 31, 2017 [Page 5] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 3.1. Message Format The Feedback Control Information (FCI) for the Layer Refresh Request consists of one or more FCI entries, the content of which is depicted in Figure 5. The length of the LRR feedback message MUST be set to 2+3*N 32-bit words, where N is the number of FCI entries. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq nr. |C| Payload Type| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TTID| TLID | RES | CTID| CLID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 SSRC (32 bits) The SSRC value of the media sender that is requested to send a layer refresh point. Seq nr. (8 bits) Command sequence number. The sequence number space is unique for each pairing of the SSRC of command source and the SSRC of the command target. The sequence number SHALL be increased by 1 for each new command (modulo 256, so the value after 255 is 0). A repetition SHALL NOT increase the sequence number. The initial value is arbitrary. C (1 bit) A flag bit indicating whether the "Current Temporal Layer ID (CTID)" and "Current Layer ID (CLID)" fields are present in the FCI. If this bit is 0, the sender of the LRR message is requesting refresh of all layers up to and including the target layer. Payload Type (7 bits) The RTP payload type for which the LRR is being requested. This gives the context in which the target layer index is to be interpreted. Reserved (RES) (three separate fields, 16 bits / 5 bits / 5 bits) All bits SHALL be set to 0 by the sender and SHALL be ignored on reception. Target Temporal Layer ID (TTID) (3 bits) The temporal ID of the target layer for which the receiver wishes a refresh point. Lennox, et al. Expires December 31, 2017 [Page 6] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 Target Layer ID (TLID) (8 bits) The layer ID of the target spatial or quality layer for which the receiver wishes a refresh point. Its format is dependent on the payload type field. Current Temporal Layer ID (CTID) (3 bits) If C is 1, the ID of the current temporal layer being decoded by the receiver. This message is not requesting refresh of layers at or below this layer. If C is 0, this field SHALL be set to 0 by the sender and SHALL be ignored on reception. Current Layer ID (CLID) (8 bits) If C is 1, the layer ID of the current spatial or quality layer being decoded by the receiver. This message is not requesting refresh of layers at or below this layer. If C is 0, this field SHALL be set to 0 by the sender and SHALL be ignored on reception. When C is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT be less than CLID; at least one of TTID or TLID MUST be greater than CTID or CLID respectively. That is to say, the target layer index MUST be a layer upgrade from the current layer index . A sender MAY request an upgrade in both temporal and spatial/quality layers simultaneously. A receiver receiving an LRR feedback packet which does not satisfy the requirements of the previous paragraph, i.e. one where the C bit is present but TTID is less than CTID or TLID is less than CLID, MUST discard the request. Note: the syntax of the TTID, TLID, CTID, and CLID fields match, by design, the TID and LID fields in [I-D.ietf-avtext-framemarking]. 3.2. Semantics Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of the media senders to which the LRR command applies are in the corresponding FCI entries. A LRR message MAY contain requests to multiple media senders, using one FCI entry per target media sender. Upon reception of LRR, the encoder MUST send a decoder refresh point (see Section 2.1) as soon as possible. The sender MUST respect bandwidth limits provided by the application of congestion control, as described in Section 5 of [RFC5104]. As layer refresh points will often be larger than non-refreshing frames, Lennox, et al. Expires December 31, 2017 [Page 7] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 this may restrict a sender's ability to send a layer refresh point quickly. LRR MUST NOT be sent as a reaction to picture losses due to packet loss or corruption -- it is RECOMMENDED to use PLI [RFC4585] instead. LRR SHOULD be used only in situations where there is an explicit change in decoders' behavior, for example when a receiver will start decoding a layer which it previously had been discarding. 4. Usage with specific codecs In order for LRR to be used with a scalable codec, the format of the temporal and layer ID fields (for both the target and current layer indices) needs to be specified for that codec's RTP packetization. New RTP packetization specifications for scalable codecs SHOULD define how this is done. (The VP9 payload [I-D.ietf-payload-vp9], for instance, has done so.) If the payload also specifies how it is used with the Frame Marking RTP Header Extension [I-D.ietf-avtext-framemarking], the syntax MUST be defined in the same manner as the TID and LID fields in that header. 4.1. H264 SVC H.264 SVC [RFC6190] defines temporal, dependency (spatial), and quality scalability modes. +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TID |R| DID | QID | +---------------+---------------+ Figure 6 Figure 6 shows the format of the layer index fields for H.264 SVC streams. The "R" and "RES" fields MUST be set to 0 on transmission and ignored on reception. See [RFC6190] Section 1.1.3 for details on the DID, QID, and TID fields. A dependency or quality layer refresh of a given layer in H.264 SVC can be identified by the "I" bit (idr_flag) in the extended NAL unit header, present in NAL unit types 14 (prefix NAL unit) and 20 (coded scalable slice). Layer refresh of the base layer can also be identified by its NAL unit type of its coded slices, which is "5" rather than "1". A dependency or quality layer refresh is complete once this bit has been seen on all the appropriate layers (in decoding order) above the current layer index (if any, or beginning from the base layer if not) through the target layer index. Lennox, et al. Expires December 31, 2017 [Page 8] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 Note that as the "I" bit in a PACSI header is set if the corresponding bit is set in any of the aggregated NAL units it describes; thus, it is not sufficient to identify layer refresh when NAL units of multiple dependency or quality layers are aggregated. In H.264 SVC, temporal layer refresh information can be determined from various Supplemental Encoding Information (SEI) messages in the bitstream. Whether an H.264 SVC stream is scalably nested can be determined from the Scalability Information SEI message's temporal_id_nesting flag. If this flag is set in a stream's currently applicable Scalability Information SEI, receivers SHOULD NOT send temporal LRR messages for that stream, as every frame is implicitly a temporal layer refresh point. (The Scalability Information SEI message may also be available in the signaling negotiation of H.264 SVC, as the sprop- scalability-info parameter.) If a stream's temporal_id_nesting flag is not set, the Temporal Level Switching Point SEI message identifies temporal layer switching points. A temporal layer refresh is satisfied when this SEI message is present in a frame with the target layer index, if the message's delta_frame_num refers to a frame with the requested current layer index. (Alternately, temporal layer refresh can also be satisfied by a complete state refresh, such as an IDR.) Senders which support receiving LRR for non-temporally-nested streams MUST insert Temporal Level Switching Point SEI messages as appropriate. 4.2. VP8 The VP8 RTP payload format [RFC7741] defines temporal scalability modes. It does not support spatial scalability. +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TID | RES | +---------------+---------------+ Figure 7 Figure 7 shows the format of the layer index field for VP8 streams. The "RES" fields MUST be set to 0 on transmission and be ignored on reception. See [RFC7741] Section 4.2 for details on the TID field. A VP8 layer refresh point can be identified by the presence of the "Y" bit in the VP8 payload header. When this bit is set, this and all subsequent frames depend only on the current base temporal layer. Lennox, et al. Expires December 31, 2017 [Page 9] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 On receipt of an LRR for a VP8 stream, A sender which supports LRR MUST encode the stream so it can set the Y bit in a packet whose temporal layer is at or below the target layer index. Note that in VP8, not every layer switch point can be identified by the Y bit, since the Y bit implies layer switch of all layers, not just the layer in which it is sent. Thus the use of LRR with VP8 can result in some inefficiency in transmision. However, this is not expected to be a major issue for temporal structures in normal use. 4.3. H265 The initial version of the H.265 payload format [RFC7798] defines temporal scalability, with protocol elements reserved for spatial or other scalability modes (which are expected to be defined in a future version of the specification). +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TID |RES| LayerId | +---------------+---------------+ Figure 8 Figure 8 shows the format of the layer index field for H.265 streams. The "RES" fields MUST be set to 0 on transmission and ignored on reception. See [RFC7798] Section 1.1.4 for details on the LayerId and TID fields. H.265 streams signal whether they are temporally nested, using the vps_temporal_id_nesting_flag in the Video Parameter Set (VPS), and the sps_temporal_id_nesting_flag in the Sequence Parameter Set (SPS). If this flag is set in a stream's currently applicable VPS or SPS, receivers SHOULD NOT send temporal LRR messages for that stream, as every frame is implicitly a temporal layer refresh point. If a stream's sps_temporal_id_nesting_flag is not set, the NAL unit types 2 to 5 inclusively identify temporal layer switching points. A layer refresh to any higher target temporal layer is satisfied when a NAL unit type of 4 or 5 with TID equal to 1 more than current TID is seen. Alternatively, layer refresh to a target temporal layer can be incrementally satisfied with NAL unit type of 2 or 3. In this case, given current TID = TO and target TID = TN, layer refresh to TN is satisfied when NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the way up to TID = TN. During this incremental process, layer refresh to TN can be completely satisfied as soon as a NAL unit type of 2 or 3 is seen. Lennox, et al. Expires December 31, 2017 [Page 10] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 Of course, temporal layer refresh can also be satisfied whenever any Intra Random Access Point (IRAP) NAL unit type (with values 16-23, inclusively) is seen. An IRAP picture is similar to an IDR picture in H.264 (NAL unit type of 5 in H.264) where decoding of the picture can start without any older pictures. In the (future) H.265 payloads that support spatial scalability, a spatial layer refresh of a specific layer can be identified by NAL units with the requested layer ID and NAL unit types between 16 and 21 inclusive. A dependency or quality layer refresh is complete once NAL units of this type have been seen on all the appropriate layers (in decoding order) above the current layer index (if any, or beginning from the base layer if not) through the target layer index. 5. Usage with different scalability transmission mechanisms Several different mechanisms are defined for how scalable streams can be transmitted in RTP. The RTP Taxonomy [RFC7656] Section 3.7 defines three mechanisms: Single RTP Stream on a Single Media Transport (SRST), Multiple RTP Streams on a Single Media Transport (MRST), and Multiple RTP Streams on Multiple Media Transports (MRMT). The LRR message is applicable to all these mechanisms. For MRST and MRMT mechanisms, the "media source" field of the LRR FCI is set to the SSRC of the RTP stream containing the layer indicated by the Current Layer Index (if "C" is 1), or the stream containing the base encoded stream (if "C" is 0). For MRMT, it is sent on the RTP session on which this stream is sent. On receipt, the sender MUST refresh all the layers requested in the stream, simultaneously in decode order. 6. SDP Definitions Section 7 of [RFC5104] defines SDP procedures for indicating and negotiating support for codec control messages (CCM) in SDP. This document extends this with a new codec control command, "lrr", which indicates support of the Layer Refresh Request (LRR). Figure 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] showing this grammar extension, extending the grammar defined in [RFC5104]. rtcp-fb-ccm-param =/ SP "lrr" ; Layer Refresh Request Figure 9: Syntax of the "lrr" ccm The Offer-Answer considerations defined in [RFC5104] Section 7.2 apply. Lennox, et al. Expires December 31, 2017 [Page 11] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 7. Security Considerations All the security considerations of FIR feedback packets [RFC5104] apply to LRR feedback packets as well. Additionally, media senders receiving LRR feedback packets MUST validate that the payload types and layer indices they are receiving are valid for the stream they are currently sending, and discard the requests if not. 8. IANA Considerations This document defines a new entry to the "Codec Control Messages" subregistry of the "Session Description Protocol (SDP) Parameters" registry, according to the following data: Value name: lrr Long name: Layer Refresh Request Command Usable with: ccm Mux: IDENTICAL-PER-PT Reference: RFC XXXX This document also defines a new entry to the "FMT Values for PSFB Payload Types" subregistry of the "Real-Time Transport Protocol (RTP) Parameters" registry, according to the following data: Name: LRR Long Name: Layer Refresh Request Command Value: TBD Reference: RFC XXXX 9. References 9.1. Normative References [I-D.ietf-avtext-framemarking] Berger, E., Nandakumar, S., and M. Zanaty, "Frame Marking RTP Header Extension", draft-ietf-avtext-framemarking-04 (work in progress), March 2017. Lennox, et al. Expires December 31, 2017 [Page 12] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, . [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, . [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Galligan, "RTP Payload Format for VP8 Video", RFC 7741, DOI 10.17487/RFC7741, March 2016, . [RFC7798] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. Hannuksela, "RTP Payload Format for High Efficiency Video Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March 2016, . 9.2. Informative References [I-D.ietf-payload-vp9] Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D. Hong, "RTP Payload Format for VP9 Video", draft-ietf- payload-vp9-03 (work in progress), March 2017. Lennox, et al. Expires December 31, 2017 [Page 13] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . [RFC8082] Wenger, S., Lennox, J., Burman, B., and M. Westerlund, "Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs", RFC 8082, DOI 10.17487/RFC8082, March 2017, . Authors' Addresses Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US Email: jonathan@vidyo.com Danny Hong Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US Email: danny@vidyo.com Justin Uberti Google, Inc. 747 6th Street South Kirkland, WA 98033 USA Email: justin@uberti.name Lennox, et al. Expires December 31, 2017 [Page 14] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 Stefan Holmer Google, Inc. Kungsbron 2 Stockholm 111 22 Sweden Email: holmer@google.com Magnus Flodman Google, Inc. Kungsbron 2 Stockholm 111 22 Sweden Email: mflodman@google.com Lennox, et al. Expires December 31, 2017 [Page 15] ./draft-ietf-pce-vn-association-11.txt0000644000764400076440000007242714325434525017373 0ustar iustiniustin PCE Working Group Y. Lee Internet-Draft Samsung Intended status: Standards Track H. Zheng Expires: 27 April 2023 Huawei Technologies D. Ceccarelli Ericsson 24 October 2022 Path Computation Element Communication Protocol (PCEP) extensions for establishing relationships between sets of Label Switched Paths and Virtual Networks draft-ietf-pce-vn-association-11 Abstract This document describes how to extend the Path Computation Element (PCE) Communication Protocol (PCEP) association mechanism introduced by the PCEP Association Group specification, to further associate sets of Label Switched Paths (LSPs) with a higher-level structure such as a Virtual Network (VN) requested by a customer or application. This extended association mechanism can be used to facilitate control of virtual network using the PCE architecture. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Lee, et al. Expires 27 April 2023 [Page 1] Internet-Draft PCE VN Association October 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . 4 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 6 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 5.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7.1. Association Object Type Indicator . . . . . . . . . . . . 9 7.2. PCEP TLV Type Indicator . . . . . . . . . . . . . . . . . 9 7.3. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . 9 8. Manageability Considerations . . . . . . . . . . . . . . . . 10 8.1. Control of Function and Policy . . . . . . . . . . . . . 10 8.2. Information and Data Models . . . . . . . . . . . . . . . 10 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 10 8.6. Impact On Network Operations . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to requests from Path Computation Clients (PCCs) [RFC5440]. [RFC8051] describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations through a number of use cases. [RFC8231] describes a set of extensions to PCEP to provide stateful control. For its computations, a stateful PCE has access to not only Lee, et al. Expires 27 April 2023 [Page 2] Internet-Draft PCE VN Association October 2022 the information carried by the network's Interior Gateway Protocol (IGP), but also the set of active paths and their reserved resources. The additional state allows the PCE to compute constrained paths while considering individual Label Switched Paths (LSPs) and their interactions. [RFC8281] describes the setup, maintenance and teardown of PCE- initiated LSPs under the stateful PCE model. [RFC8697] introduces a generic mechanism to create a grouping of LSPs. This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes. [RFC8453] introduces a framework for Abstraction and Control of TE Networks (ACTN) and describes various Virtual Network (VN) operations initiated by a customer or application. A VN is a customer view of the TE network. Depending on the agreement between client and provider, various VN operations and VN views are possible. [RFC8637] examines the PCE and ACTN architectures and describes how the PCE architecture is applicable to ACTN. [RFC6805] and [RFC8751] describes a hierarchy of stateful PCEs with Parent PCE coordinating multi-domain path computation function between Child PCEs, and thus making it the base for PCE applicability for ACTN. As [RFC8751] explains, in the context of ACTN, the Child PCE is identified with the Provisioning Network Controller (PNC), and the Parent PCE is identified with the Multi-domain Service Coordinator (MDSC). In this context, there is a need to associate a set of LSPs with a VN "construct" to facilitate VN operations in the PCE architecture. This association allows a PCE to identify which LSPs belong to a certain VN. The PCE could then use this association to optimize all LSPs belonging to the VN at once. The PCE could further take VN- specific actions on the LSPs, such as relaxation of constraints, policy actions, setting default behavior, etc. This document specifies a PCEP extension to associate a set of LSPs based on their Virtual Network (VN). 1.1. Requirement Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Lee, et al. Expires 27 April 2023 [Page 3] Internet-Draft PCE VN Association October 2022 2. Terminology The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8231] and [RFC8453]. 3. Operation Overview As per [RFC8697], LSPs are associated with other LSPs with which they interact by adding them to a common association group. An association group based on VN is useful for various optimizations that should be applied by considering all the LSPs in the association. This includes, but is not limited to - * Path Computation: When computing a path for an LSP, it is useful to analyze the impact of this LSP on the other LSPs belonging to the same VN. The aim would be to optimize all LSPs belonging to the VN rather than a single LSP. Also, the optimization criteria (such as minimizing the load of the most loaded link (MLL) [RFC5541]) could be applied for all the LSPs belonging to the VN identified by the VN association. * Path Re-Optimization: The PCE would like to use advanced path computation algorithms and optimization techniques that consider all the LSPs belonging to a VN, and optimize them all together during the path re-optimization. In this document we define a new association group called the VN Association Group (VNAG). This grouping is used to define the association between a set of LSPs and a virtual network. The Association Object contains a field to identify the type of association, and this document defines a new Association Type value of TBD1 to indicate that the association is a "VN Association". The Association Identifier in the Association Object is the VNAG Identifier and is handled in the same way as the generic association identifier defined in [RFC8697]. In this document, "VNAG object" refers to an Association Object with the Association type set to "VN Association". Local polices on the PCE define the computational and optimization behavior for the LSPs in the VN. An LSP MUST NOT belong to more than one VNAG. If an implementation encounters more than one VNAG object in a PCEP message, it MUST process the first occurrence and it MUST ignore the others. Lee, et al. Expires 27 April 2023 [Page 4] Internet-Draft PCE VN Association October 2022 [RFC8697] specifies the mechanism by which a PCEP speaker can advertise which association types it supports. This is done using the ASSOC-Type-List TLV carried within an OPEN object. A PCEP speaker MUST include the VN Association Type (TBD1) in the ASSOC- Type-List TLV before using the VNAG object in a PCEP message. As per [RFC8697], if the implementation does not support the VN Association Type, it will return a PCErr message with Error-Type 26 "Association Error" and Error-value 1 "Association Type is not supported". The Association IDs (VNAG IDs) for this Association Type are dynamic in nature (and created by the Parent PCE (MDSC) based on the VN operations for the LSPs belonging to the same VN). Operator configuration of VNAG IDs is not supported, so there is no need for an Operator-Configured Association Range to be set. Thus, the VN Association Type (TBD1) MUST NOT be present in the Operator- Configured Association Range TLV if that TLV is present in the OPEN object. If an implementation encounters the VN Association Type (TBD1) in an Operator-Configured Association Range TLV, it MUST ignore the associated Start-Assoc-ID and Range values. This association is useful in a PCEP session between a parent PCE (MDSC) and a child PCE (PNC). When computing the path, the child PCE (PNC) refers to the VN association in the request from the parent PCE (MDSC) and maps the VN to the associated LSPs and network resources. From the perspective of the Parent PCE, it receives a virtual network creation request by its customer, with the VN uniquely identified by the Association parameters (section 6.1.4 of [RFC8697]) in the VNAG or the Virtual Network identifier encoded in the VIRTUAL-NETWORK-TLV. This VN may comprise multiple LSPs in the network in a single domain or across multiple domains. The Parent PCE sends a PCInitiate Message with this association information in the VNAG Object. This in effect binds an LSP that is to be instantiated at the child PCE with the VN. The VN association information MUST be included as a part of the first PCRpt message. Figure 1 shows an example of a typical VN operation using PCEP. It is worth noting that in a multi- domain scenario, the different domains are controlled by different child PCEs. In order to set up the cross-domain tunnel, multiple segments need to be stitched, by the border nodes in each domain who receive the instruction from their child PCE (PNC). Lee, et al. Expires 27 April 2023 [Page 5] Internet-Draft PCE VN Association October 2022 ****** ..........*MDSC*.............................. . ****** .. MPI . . . . PCEP . . . . PCInitiate LSPx . . . . with VNAG . . . . . . . . . . . . . v v v . ****** ****** ****** . *PNC1* *PNC2* *PNC4* . ****** ****** ****** . +---------------+ +---------------+ +---------------+ . | |----| |----| C| . | | | | | | . |DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | . +---------------+ +---------------+ +---------------+ . / . ****** / . *PNC3*<............/...................... ****** / +---------------+/ | | | | |DOMAIN 3 | +---------------+ MDSC -> Parent PCE PNC -> Child PCE MPI -> PCEP Figure 1: Example of VN operations in H-PCE Architecture Whenever changes occur with the instantiated LSP in a domain network, the domain child PCE reports the changes using a PCRpt Message in which the VNAG Object indicates the relationship between the LSP and the VN. Whenever an update occurs with VNs in the Parent PCE (due to the customer's request), the parent PCE sends an PCUpd Message to inform each affected child PCE of this change. 4. Extensions to PCEP The format of VNAG is as per the ASSOCIATION object [RFC8697]. Lee, et al. Expires 27 April 2023 [Page 6] Internet-Draft PCE VN Association October 2022 This document defines one new mandatory TLV "VIRTUAL-NETWORK-TLV". Optionally, the new TLV can be jointly used with the existing "VENDOR-INFORMATION-TLV" specified in [RFC7470] as described below: * VIRTUAL-NETWORK-TLV: Used to communicate the Virtual Network Identifier. * VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor specific behavioral information, described in [RFC7470]. The format of VIRTUAL-NETWORK-TLV is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD2 | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Virtual Network Identifier // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The VIRTUAL-NETWORK-TLV formats Type (16-bits): TBD2 (to be allocated by IANA) Length (16-bits): indicates the length of the value portion of the TLV in octets and MUST be greater than 0. The TLV MUST be zero- padded so that the TLV is 4-octet aligned. Virtual Network Identifier (variable): a symbolic name for the VN that uniquely identifies the VN. It SHOULD be a string of printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E), without a NULL terminator. The Virtual Network Identifier is a human-readable string that identifies a VN, it can be specified with the association information which may be conveyed in a VENDOR-INFORMATION-TLV. An implementation uses the Virtual Network Identifier to maintain a mapping to the VN association group and the LSPs associated with the VN. The Virtual Network Identifier MAY be specified by the customer or set via an operator policy or auto-generated by the PCEP speaker. The VIRTUAL-NETWORK-TLV MUST be included in VNAG object. If a PCEP speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it MUST send a PCErr message with Error-Type=6 (mandatory object missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close the session. The format of VENDOR-INFORMATION-TLV is defined in [RFC7470]. Lee, et al. Expires 27 April 2023 [Page 7] Internet-Draft PCE VN Association October 2022 If a PCEP speaker receives a VN ASSOCIATION object with a TLV that violates the rules specified in this document, the PCEP speaker MUST send a PCErr message with Error-Type = 10 (Reception of an invalid object) and Error-value = 11 (Malformed object) and MUST close the PCEP session. 5. Implementation Status [Note to the RFC Editor - remove this section before publication, as well as remove the reference to RFC 7942.] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". 5.1. Huawei's Proof of Concept based on ONOS The PCE function was developed in the ONOS open source platform. This extension was implemented on a private version as a proof of concept to ACTN. * Organization: Huawei * Implementation: Huawei's PoC based on ONOS * Description: PCEP as a southbound plugin was added to ONOS. To support ACTN, this extension in PCEP is used. Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol * Maturity Level: Prototype * Coverage: Full Lee, et al. Expires 27 April 2023 [Page 8] Internet-Draft PCE VN Association October 2022 * Contact: satishk@huawei.com 6. Security Considerations The security considerations described in [RFC5440], [RFC8231] and [RFC8281] apply to the extensions defined in this document as well. One new Association Type (VN Association) for the ASSOCIATION object is introduced in this document. Additional security considerations related to LSP associations due to a malicious PCEP speaker are described in [RFC8697] and apply to the VN Association type. Hence, securing the PCEP session using Transport Layer Security (TLS) [RFC8253] is RECOMMENDED. 7. IANA Considerations 7.1. Association Object Type Indicator IANA is requested to make the assignment of a new value in the sub- registry "ASSOCIATION Type Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry, as follows: Value Name Reference TBD1 VN Association Type [This I.D.] 7.2. PCEP TLV Type Indicator IANA is requested to make the assignment of a new value for the existing "PCEP TLV Type Indicators" sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry, as follows: Value Name Reference TBD2 VIRTUAL-NETWORK-TLV [This I.D.] 7.3. PCEP Error IANA is requested to allocate new error value within the "PCEP-ERROR Object Error Types and Values" sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry, as follows: Error-Type Meaning 6 Mandatory Object missing Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This I.D.] Lee, et al. Expires 27 April 2023 [Page 9] Internet-Draft PCE VN Association October 2022 8. Manageability Considerations 8.1. Control of Function and Policy An operator MUST be allowed to mark LSPs that belong to the same VN. This could also be done automatically based on the VN configuration. 8.2. Information and Data Models The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the association between LSPs including VN association. 8.3. Liveness Detection and Monitoring Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440]. 8.4. Verify Correct Operations Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440]. 8.5. Requirements On Other Protocols Mechanisms defined in this document do not imply any new requirements on other protocols. 8.6. Impact On Network Operations [RFC8637] describe the network operations when PCE is used for VN operations. Section 3 further specifies the operations when VN associations are used. 9. References 9.1. Normative References [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Lee, et al. Expires 27 April 2023 [Page 10] Internet-Draft PCE VN Association October 2022 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, . 9.2. Informative References [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 10.17487/RFC6805, November 2012, . Lee, et al. Expires 27 April 2023 [Page 11] Internet-Draft PCE VN Association October 2022 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . [RFC8637] Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)", RFC 8637, DOI 10.17487/RFC8637, July 2019, . [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, . [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, . [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, . [RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, "Hierarchical Stateful Path Computation Element (PCE)", RFC 8751, DOI 10.17487/RFC8751, March 2020, . [I-D.ietf-pce-pcep-yang] Dhody, D., Beeram, V. P., Hardwick, J., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-yang-20, 23 October 2022, . Appendix A. Contributors Lee, et al. Expires 27 April 2023 [Page 12] Internet-Draft PCE VN Association October 2022 Dhruv Dhody Huawei Technologies Divyashree Technopark, Whitefield Bangalore, Karnataka 560066 India Email: dhruv.ietf@gmail.com Qin Wu Huawei Technologies China Email: bill.wu@huawei.com Xian Zhang Huawei Technologies China Email: zhang.xian@huawei.com Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Authors' Addresses Young Lee Samsung Seoul South Korea Email: younglee.tx@gmail.com Haomian Zheng Huawei Technologies H1, Huawei Xiliu Beipo Village, Songshan Lake Dongguan Guangdong, 523808 China Email: zhenghaomian@huawei.com Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm Sweden Email: daniele.ceccarelli@ericsson.com Lee, et al. Expires 27 April 2023 [Page 13] ./draft-ietf-babel-yang-model-13.txt0000644000764400076440000024545214122135670016764 0ustar iustiniustin Babel Working Group M. Jethanandani Internet-Draft Kloud Services Intended status: Standards Track B. Stark Expires: 26 March 2022 AT&T 22 September 2021 YANG Data Model for Babel draft-ietf-babel-yang-model-13 Abstract This document defines a data model for the Babel routing protocol. The data model is defined using the YANG data modeling language. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 March 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Jethanandani & Stark Expires 26 March 2022 [Page 1] Internet-Draft Babel YANG model September 2021 Please review these documents carefully, 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 of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Note to RFC Editor . . . . . . . . . . . . . . . . . . . 2 1.2. Tree Diagram Annotations . . . . . . . . . . . . . . . . 3 2. Babel Module . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Information Model . . . . . . . . . . . . . . . . . . . . 3 2.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 5 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 3.1. URI Registrations . . . . . . . . . . . . . . . . . . . . 32 3.2. YANG Module Name Registration . . . . . . . . . . . . . . 32 4. Security Considerations . . . . . . . . . . . . . . . . . . . 32 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.1. Normative References . . . . . . . . . . . . . . . . . . 34 6.2. Informative References . . . . . . . . . . . . . . . . . 35 Appendix A. Tree Diagram and Example Configurations . . . . . . 36 A.1. Complete Tree Diagram . . . . . . . . . . . . . . . . . . 36 A.2. Statistics Gathering Enabled . . . . . . . . . . . . . . 38 A.3. Automatic Detection of Properties . . . . . . . . . . . . 39 A.4. Override Default Properties . . . . . . . . . . . . . . . 41 A.5. Configuring other Properties . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction This document defines a data model for The Babel Routing Protocol [RFC8966]. The data model is defined using YANG 1.1 [RFC7950] and is Network Management Datastore Architecture (NDMA) [RFC8342] compatible. It is based on the Babel Information Model [RFC9046]. The data model only includes data nodes that are useful for managing Babel over IPv6. 1.1. Note to RFC Editor Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements and remove this note before publication. * "XXXX" --> the assigned RFC value for this draft both in this draft and in the YANG models under the revision statement. Jethanandani & Stark Expires 26 March 2022 [Page 2] Internet-Draft Babel YANG model September 2021 * Revision date in model, in the format 2021-09-20 needs to get updated with the date the draft gets approved. The date also needs to get reflected on the line with . 1.2. Tree Diagram Annotations For a reference to the annotations used in tree diagrams included in this draft, please see YANG Tree Diagrams [RFC8340]. 2. Babel Module This document defines a YANG 1.1 [RFC7950] data model for the configuration and management of Babel. The YANG module is based on the Babel Information Model [RFC9046]. 2.1. Information Model There are a few things that should be noted between the Babel Information Model and this data module. The information model mandates the definition of some of the attributes, e.g., 'babel- implementation-version' or the 'babel-self-router-id'. These attributes are marked as read-only objects in the information module as well as in this data module. However, there is no way in the data module to mandate that a read-only attribute be present. It is up to the implementation of this data module to make sure that the attributes that are marked read-only and are mandatory are indeed present. 2.2. Tree Diagram The following diagram illustrates a top level hierarchy of the model. In addition to the version implemented by this device, the model contains subtrees on 'constants', 'interfaces', 'mac-key-set', 'dtls', and 'routes'. Jethanandani & Stark Expires 26 March 2022 [Page 3] Internet-Draft Babel YANG model September 2021 module: ietf-babel augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw babel! +--ro version? string +--rw enable boolean +--ro router-id? binary +--ro seqno? uint16 +--rw statistics-enabled? boolean +--rw constants | ... +--rw interfaces* [reference] | ... +--rw mac-key-set* [name] | ... +--rw dtls* [name] | ... +--ro routes* [prefix] ... The 'interfaces' subtree describes attributes such as the 'interface' object that is being referenced, the type of link, e.g., wired, wireless or tunnel, as enumerated by 'metric-algorithm' and 'split- horizon' and whether the interface is enabled or not. The 'constants' subtree describes the UDP port used for sending and receiving Babel messages, and the multicast group used to send and receive announcements on IPv6. The 'routes' subtree describes objects such as the prefix for which the route is advertised, a reference to the neighboring route, and 'next-hop' address. Finally, for security two subtrees are defined to contain MAC keys and DTLS certificates. The 'mac-key-set' subtree contains keys used with the MAC security mechanism. The boolean flag 'default-apply' indicates whether the set of MAC keys is automatically applied to new interfaces. The 'dtls' subtree contains certificates used with DTLS security mechanism. Similar to the MAC mechanism, the boolean flag 'default-apply' indicates whether the set of DTLS certificates is automatically applied to new interfaces. Jethanandani & Stark Expires 26 March 2022 [Page 4] Internet-Draft Babel YANG model September 2021 2.3. YANG Module This YANG module augments the YANG Routing Management [RFC8349] module to provide a common framework for all routing subsystems. By augmenting the module it provides a common building block for routes, and Routing Information Bases (RIBs). It also has a reference to an interface defined by A YANG Data Model for Interface Management [RFC8343]. A router running Babel routing protocol can sometimes determine the parameters it needs to use for an interface based on the interface name. For example, it can detect that eth0 is a wired interface, and that wlan0 is a wireless interface. This is not true for a tunnel interface, where the link parameters need to be configured explicitly. For a wired interface, it will assume 'two-out-of-three' for 'metric- algorithm', and 'split-horizon' set to true. On the other hand, for a wireless interface it will assume 'etx' for 'metric-algorithm', and 'split-horizon' set to false. However, if the wired link is connected to a wireless radio, the values can be overriden by setting 'metric-algorithm' to 'etx', and 'split-horizon' to false. Similarly, an interface that is a metered 3G link, and used for fallback connectivity needs much higher default time constants, e.g., 'mcast-hello-interval', and 'update-interval', in order to avoid carrying control traffic as much as possible. In addition to the modules used above, this module imports definitions from Common YANG Data Types [RFC6991], and references HMAC: Keyed-Hashing for Message Authentication [RFC2104], Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec [RFC4868], The Datagram Transport Layer Security (DTLS) Version 1.3 [I-D.ietf-tls-dtls13], The Blake2 Cryptographic Hash and Message Authentication Code (MAC) [RFC7693], Babel Information Model [RFC9046], The Babel Routing Protocol [RFC8966], YANG Data Types and Groupings for Cryptography [I-D.ietf-netconf-crypto-types], Network Configuration Access Control Model [RFC8341] and MAC Authentication for Babel [RFC8967]. file "ietf-babel@2021-09-20.yang" module ietf-babel { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-babel"; prefix babel; import ietf-yang-types { prefix yang; reference Jethanandani & Stark Expires 26 March 2022 [Page 5] Internet-Draft Babel YANG model September 2021 "RFC 6991: Common YANG Data Types."; } import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types."; } import ietf-interfaces { prefix if; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-routing { prefix rt; reference "RFC 8349: YANG Routing Management"; } import ietf-crypto-types { prefix ct; reference "I-D.ietf-netconf-crypto-types: YANG Data Types and Groupings for Cryptographay."; } import ietf-netconf-acm { prefix nacm; reference "RFC 8341: Network Configuration Access Control Model"; } organization "IETF Babel routing protocol Working Group"; contact "WG Web: http://tools.ietf.org/wg/babel/ WG List: babel@ietf.org Editor: Mahesh Jethanandani mjethanandani@gmail.com Editor: Barbara Stark bs7652@att.com"; description "This YANG module defines a model for the Babel routing protocol. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as Jethanandani & Stark Expires 26 March 2022 [Page 6] Internet-Draft Babel YANG model September 2021 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; revision 2021-09-20 { description "Initial version."; reference "RFC XXXX: Babel YANG Data Model."; } /* * Features */ feature two-out-of-three-supported { description "This implementation supports the '2-out-of-3' computation algorithm."; } feature etx-supported { description "This implementation supports the Expected Transmission Count (ETX) metric computation algorithm."; } feature mac-supported { description "This implementation supports MAC-based security."; reference "RFC 8967: MAC authentication for Babel Routing Protocol."; } Jethanandani & Stark Expires 26 March 2022 [Page 7] Internet-Draft Babel YANG model September 2021 feature dtls-supported { description "This implementation supports DTLS based security."; reference "RFC 8968: Babel Routing Protocol over Datagram Transport Layer Security."; } feature hmac-sha256-supported { description "This implementation supports the HMAC-SHA256 MAC algorithm."; reference "RFC 8967: MAC authentication for Babel Routing Protocol."; } feature blake2s-supported { description "This implementation supports BLAKE2s MAC algorithms."; reference "RFC 8967: MAC authentication for Babel Routing Protocol."; } feature x-509-supported { description "This implementation supports the X.509 certificate type."; reference "RFC 8968: Babel Routing Protocol over Datagram Transport Layer Security."; } feature raw-public-key-supported { description "This implementation supports the Raw Public Key certificate type."; reference "RFC 8968: Babel Routing Protocol over Datagram Transport Layer Security."; } /* * Identities */ identity metric-comp-algorithms { description "Base identity from which all Babel metric computation Jethanandani & Stark Expires 26 March 2022 [Page 8] Internet-Draft Babel YANG model September 2021 algorithms MUST be derived."; } identity two-out-of-three { if-feature "two-out-of-three-supported"; base metric-comp-algorithms; description "2-out-of-3 algorithm."; reference "RFC 8966: The Babel Routing Protocol, Section A.2.1."; } identity etx { if-feature "etx-supported"; base metric-comp-algorithms; description "Expected Transmission Count (ETX) metric computation algorithm."; reference "RFC 8966: The Babel Routing Protocol, Section A.2.2."; } /* * Babel MAC algorithms identities. */ identity mac-algorithms { description "Base identity for all Babel MAC algorithms."; } identity hmac-sha256 { if-feature "mac-supported"; if-feature "hmac-sha256-supported"; base mac-algorithms; description "HMAC-SHA256 algorithm supported."; reference "RFC 4868: Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec."; } identity blake2s { if-feature "mac-supported"; if-feature "blake2s-supported"; base mac-algorithms; description "BLAKE2s algorithms supported. Specifically, BLAKE2-128 is Jethanandani & Stark Expires 26 March 2022 [Page 9] Internet-Draft Babel YANG model September 2021 supported."; reference "RFC 7693: The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)."; } /* * Babel Cert Types */ identity dtls-cert-types { description "Base identity for Babel DTLS certificate types."; } identity x-509 { if-feature "dtls-supported"; if-feature "x-509-supported"; base dtls-cert-types; description "X.509 certificate type."; } identity raw-public-key { if-feature "dtls-supported"; if-feature "raw-public-key-supported"; base dtls-cert-types; description "Raw Public Key certificate type."; } /* * Babel routing protocol identity. */ identity babel { base rt:routing-protocol; description "Babel routing protocol"; } /* * Groupings */ grouping routes { list routes { key "prefix"; Jethanandani & Stark Expires 26 March 2022 [Page 10] Internet-Draft Babel YANG model September 2021 config false; leaf prefix { type inet:ip-prefix; description "Prefix (expressed in ip-address/prefix-length format) for which this route is advertised."; reference "RFC 9046: Babel Information Model, Section 3.6."; } leaf router-id { type binary { length 8; } description "router-id of the source router for which this route is advertised."; reference "RFC 9046: Babel Information Model, Section 3.6."; } leaf neighbor { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/babel/interfaces/" + "neighbor-objects/neighbor-address"; } description "Reference to the neighbor-objects entry for the neighbor that advertised this route."; reference "RFC 9046: Babel Information Model, Section 3.6."; } leaf received-metric { type union { type enumeration { enum null { description "Route was not received from a neighbor."; } } type uint16; } description "The metric with which this route was advertised by the neighbor, or maximum value (infinity) to indicate the Jethanandani & Stark Expires 26 March 2022 [Page 11] Internet-Draft Babel YANG model September 2021 route was recently retracted and is temporarily unreachable. This metric will be NULL if the route was not received from a neighbor but instead was injected through means external to the Babel routing protocol. At least one of calculated-metric or received-metric MUST be non-NULL."; reference "RFC 9046: Babel Information Model, Section 3.6, RFC 8966: The Babel Routing Protocol, Section 2.1."; } leaf calculated-metric { type union { type enumeration { enum null { description "Route has not been calculated."; } } type uint16; } description "A calculated metric for this route. How the metric is calculated is implementation-specific. Maximum value (infinity) indicates the route was recently retracted and is temporarily unreachable. At least one of calculated-metric or received-metric MUST be non-NULL."; reference "RFC 9046: Babel Information Model, Section 3.6, RFC 8966: The Babel Routing Protocol, Section 2.1."; } leaf seqno { type uint16; description "The sequence number with which this route was advertised."; reference "RFC 9046: Babel Information Model, Section 3.6."; } leaf next-hop { type union { type enumeration { enum null { description "Route has no next-hop address."; } Jethanandani & Stark Expires 26 March 2022 [Page 12] Internet-Draft Babel YANG model September 2021 } type inet:ip-address; } description "The next-hop address of this route. This will be NULL if this route has no next-hop address."; reference "RFC 9046: Babel Information Model, Section 3.6."; } leaf feasible { type boolean; description "A boolean flag indicating whether this route is feasible."; reference "RFC 9046: Babel Information Model, Section 3.6, RFC 8966, The Babel Routing Protocol, Section 3.5.1."; } leaf selected { type boolean; description "A boolean flag indicating whether this route is selected, i.e., whether it is currently being used for forwarding and is being advertised."; reference "RFC 9046: Babel Information Model, Section 3.6."; } description "A set of babel-route-obj objects. Contains routes known to this node."; reference "RFC 9046: Babel Information Model, Section 3.1."; } description "Common grouping for routing used in RIB."; } /* * Data model */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol" { when "derived-from-or-self(rt:type, 'babel')" { description "Augmentation is valid only when the instance of routing type Jethanandani & Stark Expires 26 March 2022 [Page 13] Internet-Draft Babel YANG model September 2021 is of type 'babel'."; } description "Augment the routing module to support a common structure between routing protocols."; reference "YANG Routing Management, RFC 8349, Lhotka & Lindem, March 2018."; container babel { presence "A Babel container."; description "Babel Information Objects."; reference "RFC 9046: Babel Information Model, Section 3."; leaf version { type string; config false; description "The name and version of this implementation of the Babel protocol."; reference "RFC 9046: Babel Information Model, Section 3.1."; } leaf enable { type boolean; mandatory true; description "When written, it configures whether the protocol should be enabled. A read from the or datastore therefore indicates the configured administrative value of whether the protocol is enabled or not. A read from the datastore indicates whether the protocol is actually running or not, i.e. it indicates the operational state of the protocol."; reference "RFC 9046: Babel Information Model, Section 3.1."; } leaf router-id { type binary; must '../enable = "true"'; config false; description "Every Babel speaker is assigned a router-id, which is an Jethanandani & Stark Expires 26 March 2022 [Page 14] Internet-Draft Babel YANG model September 2021 arbitrary string of 8 octets that is assumed to be unique across the routing domain. The router-id is valid only if the protocol is enabled, at which time a non-zero value is assigned."; reference "RFC 9046: Babel Information Model, Section 3.1, RFC 8966: The Babel Routing Protocol, Section 3."; } leaf seqno { type uint16; config false; description "Sequence number included in route updates for routes originated by this node."; reference "RFC 9046: Babel Information Model, Section 3.1."; } leaf statistics-enabled { type boolean; description "Indicates whether statistics collection is enabled (true) or disabled (false) on all interfaces. On transition to enabled, existing statistics values are not cleared and will be incremented as new packets are counted."; } container constants { description "Babel Constants object."; reference "RFC 9046: Babel Information Model, Section 3.1."; leaf udp-port { type inet:port-number; default "6696"; description "UDP port for sending and receiving Babel messages. The default port is 6696."; reference "RFC 9046: Babel Information Model, Section 3.2."; } leaf mcast-group { type inet:ip-address; Jethanandani & Stark Expires 26 March 2022 [Page 15] Internet-Draft Babel YANG model September 2021 default "ff02::1:6"; description "Multicast group for sending and receiving multicast announcements on IPv6."; reference "RFC 9046: Babel Information Model, Section 3.2."; } } list interfaces { key "reference"; description "A set of Babel Interface objects."; reference "RFC 9046: Babel Information Model, Section 3.3."; leaf reference { type if:interface-ref; description "References the name of the interface over which Babel packets are sent and received."; reference "RFC 9046: Babel Information Model, Section 3.3."; } leaf enable { type boolean; default "true"; description "If true, babel sends and receives messages on this interface. If false, babel messages received on this interface are ignored and none are sent."; reference "RFC 9046: Babel Information Model, Section 3.3."; } leaf metric-algorithm { type identityref { base metric-comp-algorithms; } mandatory true; description "Indicates the metric computation algorithm used on this interface. The value MUST be one of those identities based on 'metric-comp-algorithms'."; reference "RFC 9046: Babel Information Model, Section 3.3."; Jethanandani & Stark Expires 26 March 2022 [Page 16] Internet-Draft Babel YANG model September 2021 } leaf split-horizon { type boolean; description "Indicates whether or not the split horizon optimization is used when calculating metrics on this interface. A value of true indicates the split horizon optimization is used."; reference "RFC 9046: Babel Information Model, Section 3.3."; } leaf mcast-hello-seqno { type uint16; config false; description "The current sequence number in use for multicast hellos sent on this interface."; reference "RFC 9046: Babel Information Model, Section 3.3."; } leaf mcast-hello-interval { type uint16; units "centiseconds"; description "The current multicast hello interval in use for hellos sent on this interface."; reference "RFC 9046: Babel Information Model, Section 3.3."; } leaf update-interval { type uint16; units "centiseconds"; description "The current update interval in use for this interface. Units are centiseconds."; reference "RFC 9046: Babel Information Model, Section 3.3."; } leaf mac-enable { type boolean; description "Indicates whether the MAC security mechanism is enabled (true) or disabled (false)."; Jethanandani & Stark Expires 26 March 2022 [Page 17] Internet-Draft Babel YANG model September 2021 reference "RFC 9046: Babel Information Model, Section 3.3."; } leaf-list mac-key-sets { type leafref { path "../../mac-key-set/name"; } description "List of references to the MAC entries that apply to this interface. When an interface instance is created, all MAC instances with default-apply 'true' will be included in this list."; reference "RFC 9046: Babel Information Model, Section 3.3."; } leaf mac-verify { type boolean; description "A Boolean flag indicating whether MACs in incoming Babel packets are required to be present and are verified. If this parameter is 'true', incoming packets are required to have a valid MAC."; reference "RFC 9046: Babel Information Model, Section 3.3."; } leaf dtls-enable { type boolean; description "Indicates whether the DTLS security mechanism is enabled (true) or disabled (false)."; reference "RFC 9046: Babel Information Model, Section 3.3."; } leaf-list dtls-certs { type leafref { path "../../dtls/name"; } description "List of references to the dtls entries that apply to this interface. When an interface instance is created, all dtls instances with default-apply 'true' will be included in this list."; reference "RFC 9046: Babel Information Model, Section 3.3."; Jethanandani & Stark Expires 26 March 2022 [Page 18] Internet-Draft Babel YANG model September 2021 } leaf dtls-cached-info { type boolean; description "Indicates whether the cached_info extension is enabled. The extension is enabled for inclusion in ClientHello and ServerHello messages if the value is 'true'."; reference "RFC 9046: Babel Information Model, Section 3.3. RFC 8968: Babel Routing Protocol over Datagram Transport Layer Security, Appendix A."; } leaf-list dtls-cert-prefer { type leafref { path "../../dtls/certs/type"; } ordered-by user; description "List of supported certificate types, in order of preference. The values MUST be the 'type' attribute in the list 'certs' of the list 'dtls' (../../dtls/certs/type). This list is used to populate the server_certificate_type extension in a ClientHello. Values that are present in at least one instance in the certs object under dtls of a referenced dtls instance and that have a non-empty private-key will be used to populate the client_certificate_type extension in a ClientHello."; reference "RFC 9046: Babel Information Model, Section 3.3 RFC 8968: Babel Routing Protocol over Datagram Transport Layer Security, Appendix A."; } leaf packet-log-enable { type boolean; description "If true, logging of babel packets received on this interface is enabled; if false, babel packets are not logged."; reference "RFC 9046: Babel Information Model, Section 3.3."; } leaf packet-log { type inet:uri; Jethanandani & Stark Expires 26 March 2022 [Page 19] Internet-Draft Babel YANG model September 2021 config false; description "A reference or url link to a file that contains a timestamped log of packets received and sent on udp-port on this interface. The [libpcap] file format with .pcap file extension SHOULD be supported for packet log files. Logging is enabled / disabled by packet-log-enable."; reference "RFC 9046: Babel Information Model, Section 3.3."; } container statistics { config false; description "Statistics collection object for this interface."; reference "RFC 9046: Babel Information Model, Section 3.3."; leaf discontinuity-time { type yang:date-and-time; mandatory true; description "The time on the most recent occasion at which any one or more of counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem re-initialized itself."; } leaf sent-mcast-hello { type yang:counter32; description "A count of the number of multicast Hello packets sent on this interface."; reference "RFC 9046: Babel Information Model, Section 3.4."; } leaf sent-mcast-update { type yang:counter32; description "A count of the number of multicast update packets sent on this interface."; reference "RFC 9046: Babel Information Model, Section 3.4."; } Jethanandani & Stark Expires 26 March 2022 [Page 20] Internet-Draft Babel YANG model September 2021 leaf sent-ucast-hello { type yang:counter32; description "A count of the number of unicast Hello packets sent on this interface."; reference "RFC 9046: Babel Information Model, Section 3.6."; } leaf sent-ucast-update { type yang:counter32; description "A count of the number of unicast update packets sent on this interface."; reference "RFC 9046: Babel Information Model, Section 3.6."; } leaf sent-ihu { type yang:counter32; description "A count of the number of IHU packets sent on this interface."; reference "RFC 9046: Babel Information Model, Section 3.6."; } leaf received-packets { type yang:counter32; description "A count of the number of Babel packets received on this interface."; reference "RFC 9046: Babel Information Model, Section 3.4."; } action reset { description "The information model [RFC 9046] defines reset action as a system-wide reset of Babel statistics. In YANG the reset action is associated with the container where the action is defined. In this case the action is associated with the statistics container inside an interface. The action will therefore reset statistics at an interface level. Implementations that want to support a system-wide reset of Babel statistics need to call this action Jethanandani & Stark Expires 26 March 2022 [Page 21] Internet-Draft Babel YANG model September 2021 for every instance of the interface."; input { leaf reset-at { type yang:date-and-time; description "The time when the reset was issued."; } } output { leaf reset-finished-at { type yang:date-and-time; description "The time when the reset finished."; } } } } list neighbor-objects { key "neighbor-address"; config false; description "A set of Babel Neighbor Object."; reference "RFC 9046: Babel Information Model, Section 3.5."; leaf neighbor-address { type inet:ip-address; description "IPv4 or v6 address the neighbor sends packets from."; reference "RFC 9046: Babel Information Model, Section 3.5."; } leaf hello-mcast-history { type string; description "The multicast Hello history of whether or not the multicast Hello packets prior to exp-mcast- hello-seqno were received, with a '1' for the most recent Hello placed in the most significant bit and prior Hellos shifted right (with '0' bits placed between prior Hellos and most recent Hello for any not-received Hellos); represented as a string of utf-8 encoded hex digits. A bit that is set indicates that the corresponding Hello was received, and a bit Jethanandani & Stark Expires 26 March 2022 [Page 22] Internet-Draft Babel YANG model September 2021 that is cleared indicates that the corresponding Hello was not received."; reference "RFC 9046: Babel Information Model, Section 3.5."; } leaf hello-ucast-history { type string; description "The unicast Hello history of whether or not the unicast Hello packets prior to exp-ucast-hello-seqno were received, with a '1' for the most recent Hello placed in the most significant bit and prior Hellos shifted right (with '0' bits placed between prior Hellos and most recent Hello for any not-received Hellos); represented as a string using utf-8 encoded hex digits where a '1' bit = Hello received and a '0' bit = Hello not received."; reference "RFC 9046: Babel Information Model, Section 3.5."; } leaf txcost { type int32; default "0"; description "Transmission cost value from the last IHU packet received from this neighbor, or maximum value (infinity) to indicate the IHU hold timer for this neighbor has expired description."; reference "RFC 9046: Babel Information Model, Section 3.5."; } leaf exp-mcast-hello-seqno { type union { type enumeration { enum null { description "Multicast Hello packets are not expected, or processing of multicast packets is not enabled."; } } type uint16; } description "Expected multicast Hello sequence number of next Hello Jethanandani & Stark Expires 26 March 2022 [Page 23] Internet-Draft Babel YANG model September 2021 to be received from this neighbor; if multicast Hello packets are not expected, or processing of multicast packets is not enabled, this MUST be NULL."; reference "RFC 9046: Babel Information Model, Section 3.5."; } leaf exp-ucast-hello-seqno { type union { type enumeration { enum null { description "Unicast Hello packets are not expected, or processing of unicast packets is not enabled."; } } type uint16; } default null; description "Expected unicast Hello sequence number of next Hello to be received from this neighbor; if unicast Hello packets are not expected, or processing of unicast packets is not enabled, this MUST be NULL."; reference "RFC 9046: Babel Information Model, Section 3.5."; } leaf ucast-hello-seqno { type union { type enumeration { enum null { description "Unicast Hello packets are not being sent."; } } type uint16; } default null; description "The current sequence number in use for unicast Hellos sent to this neighbor. If unicast Hellos are not being sent, this MUST be NULL."; reference "RFC 9046: Babel Information Model, Section 3.5."; } leaf ucast-hello-interval { Jethanandani & Stark Expires 26 March 2022 [Page 24] Internet-Draft Babel YANG model September 2021 type uint16; units "centiseconds"; description "The current interval in use for unicast hellos sent to this neighbor. Units are centiseconds."; reference "RFC 9046: Babel Information Model, Section 3.5."; } leaf rxcost { type uint16; description "Reception cost calculated for this neighbor. This value is usually derived from the Hello history, which may be combined with other data, such as statistics maintained by the link layer. The rxcost is sent to a neighbor in each IHU."; reference "RFC 9046: Babel Information Model, Section 3.5."; } leaf cost { type int32; description "Link cost is computed from the values maintained in the neighbor table. The statistics kept in the neighbor table about the reception of Hellos, and the txcost computed from received IHU packets."; reference "RFC 9046: Babel Information Model, Section 3.5."; } } } list mac-key-set { key "name"; description "A MAC key set object. If this object is implemented, it provides access to parameters related to the MAC security mechanism."; reference "RFC 9046: Babel Information Model, Section 3.7."; leaf name { type string; description "A string that uniquely identifies the MAC object."; Jethanandani & Stark Expires 26 March 2022 [Page 25] Internet-Draft Babel YANG model September 2021 } leaf default-apply { type boolean; description "A Boolean flag indicating whether this object instance is applied to all new interfaces, by default. If 'true', this instance is applied to new babel- interfaces instances at the time they are created, by including it in the mac-key-sets list under the interface. If 'false', this instance is not applied to new interface instances when they are created."; reference "RFC 9046: Babel Information Model, Section 3.7."; } list keys { key "name"; min-elements 1; description "A set of keys objects."; reference "RFC 9046: Babel Information Model, Section 3.8."; leaf name { type string; description "A unique name for this MAC key that can be used to identify the key in this object instance, since the key value is not allowed to be read. This value can only be provided when this instance is created, and is not subsequently writable."; reference "RFC 9046: Babel Information Model, Section 3.8."; } leaf use-send { type boolean; mandatory true; description "Indicates whether this key value is used to compute a MAC and include that MAC in the sent Babel packet. A MAC for sent packets is computed using this key if the value is 'true'. If the value is 'false', this key is not used to compute a MAC to include in sent Babel packets."; reference "RFC 9046: Babel Information Model, Section 3.8."; Jethanandani & Stark Expires 26 March 2022 [Page 26] Internet-Draft Babel YANG model September 2021 } leaf use-verify { type boolean; mandatory true; description "Indicates whether this key value is used to verify incoming Babel packets. This key is used to verify incoming packets if the value is 'true'. If the value is 'false', no MAC is computed from this key for comparing an incoming packet."; reference "RFC 9046: Babel Information Model, Section 3.8."; } leaf value { nacm:default-deny-all; type binary; mandatory true; description "The value of the MAC key. This value is of a length suitable for the associated babel-mac-key-algorithm. If the algorithm is based on the HMAC construction [RFC2104], the length MUST be between 0 and an upper limit that is at least the size of the output length (where 'HMAC-SHA256' output length is 32 octets as described in [RFC4868]). Longer lengths MAY be supported but are not necessary if the management system has the ability to generate a suitably random value (e.g., by randomly generating a value or by using a key derivation technique as recommended in [RFC8967] Security Considerations). If the algorithm is 'BLAKE2s-128', the length MUST be between 0 and 32 bytes inclusive as specified by [RFC7693]."; reference "RFC 9046: Babel Information Model, Section 3.8, RFC 2104: HMAC: Keyed-Hashing for Message Authentication RFC 4868: Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec, RFC 7693: The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC). RFC 8967: MAC Authentication for Babel."; } leaf algorithm { Jethanandani & Stark Expires 26 March 2022 [Page 27] Internet-Draft Babel YANG model September 2021 type identityref { base mac-algorithms; } mandatory true; description "The MAC algorithm used with this key. The value MUST be one of the identities listed with the base of 'mac-algorithms'."; reference "RFC 9046: Babel Information Model, Section 3.8."; } action test { description "An operation that allows the MAC key and MAC algorithm to be tested to see if they produce an expected outcome. Input to this operation are a binary string and a calculated MAC (also in the format of a binary string) for the binary string. The implementation is expected to create a MAC over the binary string using the value and algorithm. The output of this operation is a binary indication that the calculated MAC matched the input MAC (true) or the MACs did not match (false)."; reference "RFC 9046: Babel Information Model, Section 3.8."; input { leaf test-string { type binary; mandatory true; description "Input to this operation is a binary string. The implementation is expected to create a MAC over this string using the value and the algorithm defined as part of the mac-key-set."; reference "RFC 9046: Babel Information Model, Section 3.8."; } leaf mac { type binary; mandatory true; description "Input to this operation includes a MAC. The implementation is expected to calculate a MAC over the string using the value and algorithm of Jethanandani & Stark Expires 26 March 2022 [Page 28] Internet-Draft Babel YANG model September 2021 this key object and compare its calculated MAC to this input MAC."; reference "RFC 9046: Babel Information Model, Section 3.8."; } } output { leaf indication { type boolean; mandatory true; description "The output of this operation is a binary indication that the calculated MAC matched the input MAC (true) or the MACs did not match (false)."; reference "RFC 9046: Babel Information Model, Section 3.8."; } } } } } list dtls { key "name"; description "A dtls object. If this object is implemented, it provides access to parameters related to the DTLS security mechanism."; reference "RFC 9046: Babel Information Model, Section 3.9"; leaf name { type string; description "A string that uniquely identifies a dtls object."; } leaf default-apply { type boolean; mandatory true; description "A Boolean flag indicating whether this object instance is applied to all new interfaces, by default. If 'true', this instance is applied to new interfaces instances at the time they are created, by including it Jethanandani & Stark Expires 26 March 2022 [Page 29] Internet-Draft Babel YANG model September 2021 in the dtls-certs list under the interface. If 'false', this instance is not applied to new interface instances when they are created."; reference "RFC 9046: Babel Information Model, Section 3.9."; } list certs { key "name"; min-elements 1; description "A set of cert objects. This contains both certificates for this implementation to present for authentication, and to accept from others. Certificates with a non-empty private-key can be presented by this implementation for authentication."; reference "RFC 9046: Babel Information Model, Section 3.10."; leaf name { type string; description "A unique name for this certificate that can be used to identify the certificate in this object instance, since the value is too long to be useful for identification. This value MUST NOT be empty and can only be provided when this instance is created (i.e., it is not subsequently writable)."; reference "RFC 9046: Babel Information Model, Section 3.10."; } leaf value { nacm:default-deny-write; type string; mandatory true; description "The certificate in PEM format [RFC7468]. This value can only be provided when this instance is created, and is not subsequently writable."; reference "RFC 9046: Babel Information Model, Section 3.10."; } leaf type { nacm:default-deny-write; Jethanandani & Stark Expires 26 March 2022 [Page 30] Internet-Draft Babel YANG model September 2021 type identityref { base dtls-cert-types; } mandatory true; description "The certificate type of this object instance. The value MUST be the same as one of the identities listed with the base 'dtls-cert-types'. This value can only be provided when this instance is created, and is not subsequently writable."; reference "RFC 9046: Babel Information Model, Section 3.10."; } leaf private-key { nacm:default-deny-all; type binary; mandatory true; description "The value of the private key. If this is non-empty, this certificate can be used by this implementation to provide a certificate during DTLS handshaking."; reference "RFC 9046: Babel Information Model, Section 3.10."; } leaf algorithm { nacm:default-deny-write; type identityref { base ct:private-key-format; } mandatory true; description "Identifies the algorithm identity with which the private-key has been encoded. This value can only be provided when this instance is created, and is not subsequently writable."; } } } uses routes; } } } Jethanandani & Stark Expires 26 March 2022 [Page 31] Internet-Draft Babel YANG model September 2021 3. IANA Considerations This document registers a URI and a YANG module. 3.1. URI Registrations URI: urn:ietf:params:xml:ns:yang:ietf-babel 3.2. YANG Module Name Registration This document registers a YANG module in the YANG Module Names registry YANG [RFC6020]. Name:ietf-babel Namespace: urn:ietf:params:xml:ns:yang:ietf-babel prefix: babel reference: RFC XXXX 4. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocol such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure transport is SSH [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The NETCONF Access Control Model (NACM [RFC8341]) provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content. The security considerations outlined here are specific to the YANG data model, and do not cover security considerations of the Babel protocol or its security mechanisms in The Babel Routing Protocol [RFC8966], MAC Authentication for the Babel Routing Protocol [RFC8967], and Babel Routing Protocol over Data Transport Layer Security [RFC8968]. Each of these has its own Security Considerations section for considerations that are specific to it. There are a number of data nodes defined in the YANG module which are writable/created/deleted (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., ) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability from a config true perspective: Jethanandani & Stark Expires 26 March 2022 [Page 32] Internet-Draft Babel YANG model September 2021 'babel': This container includes an 'enable' parameter that can be used to enable or disable use of Babel on a router 'babel/constants': This container includes configuration parameters that can prevent reachability if misconfigured. 'babel/interfaces': This leaf-list has configuration parameters that can enable/disable security mechanisms and change performance characteristics of the Babel protocol. For example, enabling logging of packets and giving unintended access to the log files gives an attacker detailed knowledge of the network, and allows it to launch an attack on the traffic traversing the network device. 'babel/hmac' and 'babel/dtls': These contain security credentials that influence whether incoming packets are trusted, and whether outgoing packets are produced in a way such that the receiver will treat them as trusted. Some of the readable data or config false nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability from a config false perpective: 'babel': Access to the information in the various nodes can disclose the network topology. Additionally, the routes used by a network device may be used to mount a subsequent attack on traffic traversing the network device. 'babel/hmac' and 'babel/dtls': These contain security credentials, including private credentials of the router; however it is required that these values not be readable. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability from a RPC operation perspective: This model defines two actions. Resetting the statistics within an interface container would be visible to any monitoring processes, which should be designed to account for the possibility of such a reset. The "test" action allows for validation that a MAC key and MAC algorithm have been properly configured. The MAC key is a sensitive piece of information, and it is important to prevent an attacker that does not know the MAC key from being able to determine the MAC value by trying different input parameters. The "test" Jethanandani & Stark Expires 26 March 2022 [Page 33] Internet-Draft Babel YANG model September 2021 action has been designed to not reveal such information directly. Such information might also be revealed indirectly, due to side channels such as the time it takes to produce a response to the action. Implementations SHOULD use a constant-time comparison between the input mac and the locally generated MAC value for comparison, in order to avoid such side channel leakage. 5. Acknowledgements Juliusz Chroboczek provided most of the example configurations for babel that are shown in the Appendix. 6. References 6.1. Normative References [I-D.ietf-netconf-crypto-types] Watsen, K., "YANG Data Types and Groupings for Cryptography", Work in Progress, Internet-Draft, draft- ietf-netconf-crypto-types-21, 14 September 2021, . [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- dtls13-43, 30 April 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)", RFC 7693, DOI 10.17487/RFC7693, November 2015, . Jethanandani & Stark Expires 26 March 2022 [Page 34] Internet-Draft Babel YANG model September 2021 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . [RFC8966] Chroboczek, J. and D. Schinazi, "The Babel Routing Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021, . [RFC8967] Do, C., Kolodziejak, W., and J. Chroboczek, "MAC Authentication for the Babel Routing Protocol", RFC 8967, DOI 10.17487/RFC8967, January 2021, . [RFC8968] Decimo, A., Schinazi, D., and J. Chroboczek, "Babel Routing Protocol over Datagram Transport Layer Security", RFC 8968, DOI 10.17487/RFC8968, January 2021, . [RFC9046] Stark, B. and M. Jethanandani, "Babel Information Model", RFC 9046, DOI 10.17487/RFC9046, June 2021, . 6.2. Informative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . Jethanandani & Stark Expires 26 March 2022 [Page 35] Internet-Draft Babel YANG model September 2021 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Appendix A. Tree Diagram and Example Configurations This section is devoted to including a complete tree diagram and examples that demonstrate how Babel can be configured. A.1. Complete Tree Diagram This section includes the complete tree diagram for the Babel YANG module. module: ietf-babel augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw babel! +--ro version? string +--rw enable boolean Jethanandani & Stark Expires 26 March 2022 [Page 36] Internet-Draft Babel YANG model September 2021 +--ro router-id? binary +--ro seqno? uint16 +--rw statistics-enabled? boolean +--rw constants | +--rw udp-port? inet:port-number | +--rw mcast-group? inet:ip-address +--rw interfaces* [reference] | +--rw reference if:interface-ref | +--rw enable? boolean | +--rw metric-algorithm identityref | +--rw split-horizon? boolean | +--ro mcast-hello-seqno? uint16 | +--rw mcast-hello-interval? uint16 | +--rw update-interval? uint16 | +--rw mac-enable? boolean | +--rw mac-key-sets* -> ../../mac-key-set/name | +--rw mac-verify? boolean | +--rw dtls-enable? boolean | +--rw dtls-certs* -> ../../dtls/name | +--rw dtls-cached-info? boolean | +--rw dtls-cert-prefer* -> ../../dtls/certs/type | +--rw packet-log-enable? boolean | +--ro packet-log? inet:uri | +--ro statistics | | +--ro discontinuity-time yang:date-and-time | | +--ro sent-mcast-hello? yang:counter32 | | +--ro sent-mcast-update? yang:counter32 | | +--ro sent-ucast-hello? yang:counter32 | | +--ro sent-ucast-update? yang:counter32 | | +--ro sent-ihu? yang:counter32 | | +--ro received-packets? yang:counter32 | | +---x reset | | +---w input | | | +---w reset-at? yang:date-and-time | | +--ro output | | +--ro reset-finished-at? yang:date-and-time | +--ro neighbor-objects* [neighbor-address] | +--ro neighbor-address inet:ip-address | +--ro hello-mcast-history? string | +--ro hello-ucast-history? string | +--ro txcost? int32 | +--ro exp-mcast-hello-seqno? union | +--ro exp-ucast-hello-seqno? union | +--ro ucast-hello-seqno? union | +--ro ucast-hello-interval? uint16 | +--ro rxcost? uint16 | +--ro cost? int32 +--rw mac-key-set* [name] Jethanandani & Stark Expires 26 March 2022 [Page 37] Internet-Draft Babel YANG model September 2021 | +--rw name string | +--rw default-apply? boolean | +--rw keys* [name] | +--rw name string | +--rw use-send boolean | +--rw use-verify boolean | +--rw value binary | +--rw algorithm identityref | +---x test | +---w input | | +---w test-string binary | | +---w mac binary | +--ro output | +--ro indication boolean +--rw dtls* [name] | +--rw name string | +--rw default-apply boolean | +--rw certs* [name] | +--rw name string | +--rw value string | +--rw type identityref | +--rw private-key binary | +--rw algorithm identityref +--ro routes* [prefix] +--ro prefix inet:ip-prefix +--ro router-id? binary +--ro neighbor? leafref +--ro received-metric? union +--ro calculated-metric? union +--ro seqno? uint16 +--ro next-hop? union +--ro feasible? boolean +--ro selected? boolean A.2. Statistics Gathering Enabled In this example, interface eth0 is being configured for routing protocol Babel, and statistics gathering is enabled. For security, HMAC-SHA256 is supported. Every sent Babel packets is signed with the key value provided, and every received Babel packet is verified with the same key value. Jethanandani & Stark Expires 26 March 2022 [Page 38] Internet-Draft Babel YANG model September 2021 eth0 ianaift:ethernetCsmacd true babel:babel name:babel true true eth0 two-out-of-three true hmac-sha256 hmac-sha256-keys true true base64encodedvalue== hmac-sha256 A.3. Automatic Detection of Properties Jethanandani & Stark Expires 26 March 2022 [Page 39] Internet-Draft Babel YANG model September 2021 eth0 ianaift:ethernetCsmacd true wlan0 ianaift:ieee80211 true babel:babel name:babel true eth0 true two-out-of-three true wlan0 true etx false Jethanandani & Stark Expires 26 March 2022 [Page 40] Internet-Draft Babel YANG model September 2021 A.4. Override Default Properties eth0 ianaift:ethernetCsmacd true eth1 ianaift:ethernetCsmacd true tun0 ianaift:tunnel true babel:babel name:babel true eth0 true two-out-of-three true eth1 true etx false tun0 true two-out-of-three true A.5. Configuring other Properties eth0 ianaift:ethernetCsmacd true Jethanandani & Stark Expires 26 March 2022 [Page 42] Internet-Draft Babel YANG model September 2021 ppp0 ianaift:ppp true babel:babel name:babel true eth0 true two-out-of-three true ppp0 true 30 120 two-out-of-three Authors' Addresses Mahesh Jethanandani Kloud Services California United States of America Email: mjethanandani@gmail.com Jethanandani & Stark Expires 26 March 2022 [Page 43] Internet-Draft Babel YANG model September 2021 Barbara Stark AT&T Atlanta, GA United States of America Email: barbara.stark@att.com Jethanandani & Stark Expires 26 March 2022 [Page 44] ./draft-ietf-ipsecme-ikev2-multiple-ke-12.txt0000644000764400076440000025673514342121777020572 0ustar iustiniustin Internet Engineering Task Force (IETF) C. Tjhai Internet-Draft M. Tomlinson Updates: 7296 (if approved) Post-Quantum Intended status: Standards Track G. Bartlett Expires: 4 June 2023 Quantum Secret S. Fluhrer Cisco Systems D. Van Geest ISARA Corporation O. Garcia-Morchon Philips V. Smyslov ELVIS-PLUS 1 December 2022 Multiple Key Exchanges in IKEv2 draft-ietf-ipsecme-ikev2-multiple-ke-12 Abstract This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. The primary application of this feature in IKEv2 is the ability to perform one or more post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman (EC)DH key exchange, so that the resulting shared key is resistant against quantum computer attacks. Since there is currently no post-quantum key exchange that is as well-studied as (EC)DH, performing multiple key exchanges with different post-quantum algorithms along with the well-established classical key exchange algorithms addresses this concern, since the overall security is at least as strong as each individual primitive. Another possible application for this extension is the ability to combine several key exchanges in situations when no single key exchange algorithm is trusted by both initiator and responder. This document utilizes the IKE_INTERMEDIATE exchange, by means of which multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is up (during rekeys or creating additional Child SAs). Tjhai, et al. Expires 4 June 2023 [Page 1] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 This document updates RFC7296 by renaming a transform type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this transform type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3 1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . 4 1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Document Organization . . . . . . . . . . . . . . . . . . 7 2. Multiple Key Exchanges . . . . . . . . . . . . . . . . . . . 8 Tjhai, et al. Expires 4 June 2023 [Page 2] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 2.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 8 2.2. Protocol Details . . . . . . . . . . . . . . . . . . . . 10 2.2.1. IKE_SA_INIT Round: Negotiation . . . . . . . . . . . 10 2.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges . . 15 2.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 16 2.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 16 2.2.5. Interaction with IKEv2 Extensions . . . . . . . . . . 19 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 3.1. Additional Considerations and Changes . . . . . . . . . . 21 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1. Normative References . . . . . . . . . . . . . . . . . . 24 6.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. Sample Multiple Key Exchanges . . . . . . . . . . . 26 A.1. IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange Payloads . . . . . . . . . . . . . . . . . . . . . . . . 26 A.2. No Additional Key Exchange Used . . . . . . . . . . . . . 28 A.3. Additional Key Exchange in the CREATE_CHILD_SA Exchange only . . . . . . . . . . . . . . . . . . . . . . . . . . 29 A.4. No Matching Proposal for Additional Key Exchanges . . . . 31 Appendix B. Design Criteria . . . . . . . . . . . . . . . . . . 31 Appendix C. Alternative Design . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction 1.1. Problem Description Internet Key Exchange Protocol (IKEv2) as specified in [RFC7296] uses the Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) algorithm, which shall be referred to as (EC)DH collectively, to establish a shared secret between an initiator and a responder. The security of the (EC)DH algorithms relies on the difficulty to solve a discrete logarithm problem in multiplicative (and respectively elliptic curve) groups when the order of the group parameter is large enough. While solving such a problem remains infeasible with current computing power, it is believed that general purpose quantum computers will be able to solve this problem, implying that the security of IKEv2 is compromised. There are, however, a number of cryptosystems that are conjectured to be resistant against quantum computer attack. This family of cryptosystems is known as post- quantum cryptography (PQC). It is sometimes also referred to as quantum-safe cryptography (QSC) or quantum-resistant cryptography (QRC). Tjhai, et al. Expires 4 June 2023 [Page 3] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 1.2. Proposed Extension This document describes a method to perform multiple successive key exchanges in IKEv2. It allows integration of PQC in IKEv2, while maintaining backwards compatibility, to derive a set of IKE keys that is resistant to quantum computer attacks. This extension allows the negotiation of one or more PQC algorithm to exchange data, in addition to the existing (EC)DH key exchange data. It is believed that the feature of using more than one post-quantum algorithms is important as many of these algorithms are relatively new and there may be a need to hedge the security risk with multiple key exchange data from several distinct PQC algorithms. IKE peers perform multiple successive key exchanges to establish an IKE Security Association (SA). Each exchange produces a piece of secret and these secrets are combined in a way such that: (a) the final shared secret is computed from all of the component key exchange secret; (b) the shared secret as specified in [RFC7296] is obtained unless both peers support and agree to use the additional key exchanges introduced in this specification; and (c) if any of the component key exchange method is a post-quantum algorithm, the final shared secret is post-quantum secure. Some post-quantum key exchange payloads may have sizes larger than the standard maximum transmission unit (MTU) size, and therefore there could be issues with fragmentation at the IP layer. In order to allow using those larger payload sizes, this mechanism relies on the IKE_INTERMEDIATE exchange as specified in [RFC9242]. With this mechanism, the key exchange is initiated using a smaller, possibly classical primitive, such as (EC)DH. Then, before the IKE_AUTH exchange, one or more IKE_INTERMEDIATE exchanges are carried out, each of which contains an additional key exchange. As the IKE_INTERMEDIATE exchange is encrypted, the IKE fragmentation protocol [RFC7383] can be used. The IKE SK_* values are updated after each exchange as described in Section 2.2.2, and so the final IKE SA keys depend on all the key exchanges, hence they are secure if any of the key exchanges are secure. While this extension is primarily aimed for IKE SAs due to the potential fragmentation issue discussed above, it also applies to CREATE_CHILD_SA exchanges as illustrated in Section 2.2.4 for creating/rekeying of Child SAs and rekeying of IKE SAs. Tjhai, et al. Expires 4 June 2023 [Page 4] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 Note that readers should consider the approach defined in this document as providing a long term solution in upgrading the IKEv2 protocol to support post-quantum algorithms. A short term solution to make IKEv2 key exchange quantum secure is to use post-quantum pre- shared keys as specified in [RFC8784]. Note also that the proposed approach of performing multiple successive key exchanges in such a way that resulting session keys depend on all of them is not limited to only addressing the threat of quantum computer. It can also be used when all of the performed key exchanges are classical (EC)DH primitives, where for some reasons (e.g. policy requirements) it is essential to perform multiple of them. This specification does not attempt to address key exchanges with KE payloads longer than 64 Kbytes; the current IKE payload format does not allow such as possibility. At the time of writing, it appears likely that there are a number of key exchanges available that would not have such a requirement. However, if such a requirement is needed, [I-D.tjhai-ikev2-beyond-64k-limit] discusses approaches that could be taken to exchange huge payloads. 1.3. Changes RFC EDITOR PLEASE DELETE THIS SECTION. Changes in this draft in each version iterations. draft-ietf-ipsecme-ikev2-multiple-ke-07 * Editorial changes. draft-ietf-ipsecme-ikev2-multiple-ke-06 * Updated draft with the allocated IANA values. * Editorial changes following AD review. draft-ietf-ipsecme-ikev2-multiple-ke-05 * Updated the reference to RFC9242. * Editorial changes. draft-ietf-ipsecme-ikev2-multiple-ke-04 * Introduction and initial sections are reorganized. Tjhai, et al. Expires 4 June 2023 [Page 5] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 * More clarifications for error handling added. * ASCII arts displaying SA payload are added. * Clarification for handling multiple round trips key exchange methods added. * DoS concerns added into Security Considerations section. * Explicitly allow scenario when additional key exchanges are performed only after peers are authenticated. draft-ietf-ipsecme-ikev2-multiple-ke-03 * More clarifications added. * Figure illustrating initial exchange added. * Minor editorial changes. draft-ietf-ipsecme-ikev2-multiple-ke-02 * Added a reference on the handling of KE payloads larger than 64KB. draft-ietf-ipsecme-ikev2-multiple-ke-01 * References are updated. draft-ietf-ipsecme-ikev2-multiple-ke-00 * Draft name changed as result of WG adoption and generalization of the approach. * New exchange IKE_FOLLOWUP_KE is defined for additional key exchanges performed after CREATE_CHILD_SA. * Nonces are removed from all additional key exchanges. * Clarification that IKE_INTERMEDIATE must be negotiated is added. draft-tjhai-ipsecme-hybrid-qske-ikev2-04 * Clarification about key derivation in case of multiple key exchanges in CREATE_CHILD_SA is added. * Resolving rekey collisions in case of multiple key exchanges is clarified. Tjhai, et al. Expires 4 June 2023 [Page 6] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 draft-tjhai-ipsecme-hybrid-qske-ikev2-03 * Using multiple key exchanges CREATE_CHILD_SA is defined. draft-tjhai-ipsecme-hybrid-qske-ikev2-02 * Use new transform types to negotiate additional key exchanges, rather than using the KE payloads of IKE SA. draft-tjhai-ipsecme-hybrid-qske-ikev2-01 * Use IKE_INTERMEDIATE to perform multiple key exchanges in succession. * Handle fragmentation by keeping the first key exchange (a standard IKE_SA_INIT with a few extra notifies) small, and encrypting the rest of the key exchanges. * Simplify the negotiation of the 'extra' key exchanges. draft-tjhai-ipsecme-hybrid-qske-ikev2-00 * Added a feature to allow more than one post-quantum key exchange algorithms to be negotiated and used to exchange a post- quantum shared secret. * Instead of relying on TCP encapsulation to deal with IP level fragmentation, a new key exchange payload that can be sent as multiple fragments within IKE_SA_INIT message was introduced. 1.4. Document Organization The remainder of this document is organized as follows. Section 2 describes how multiple key exchanges are performed between two IKE peers and how keying materials are derived for both SAs and Child SAs. Section 3 discusses IANA considerations for the namespaces introduced in this document, and Section 4 discusses security considerations. In the Appendices sections, some examples of multiple key exchanges are illustrated in Appendix A, Appendix B summarizes design criteria and a summary of alternative approaches that have been considered, but later discarded, are described in Appendix C. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Tjhai, et al. Expires 4 June 2023 [Page 7] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 2. Multiple Key Exchanges 2.1. Design Overview Most post-quantum key agreement algorithms are relatively new, and thus are not fully trusted. There are also many proposed algorithms, with different trade-offs and relying on different hard problems. The concern is that some of these hard problems may turn out to be easier to solve than anticipated and thus the key agreement algorithm may not be as secure as expected. A hybrid solution, when multiple key exchanges are performed and the calculated shared key depends on all of them, allows us to deal with this uncertainty by combining a classical key exchange with a post-quantum one, as well as leaving open the possibility of multiple post-quantum key exchanges. In order to be able to use IKE fragmentation [RFC7383] for those key exchanges that may have long public keys, this specification utilizes the IKE_INTERMEDIATE exchange defined in [RFC9242]. The initial IKE_SA_INIT messages do not have any inherent fragmentation support within IKE; however, IKE_SA_INIT messages can include a relatively short KE payload. The additional key exchanges are performed using IKE_INTERMEDIATE messages that follow the IKE_SA_INIT exchange. This is to allow the standard IKE fragmentation mechanisms (which cannot be used in IKE_SA_INIT) to be available for the potentially large Key Exchange payloads with post-quantum algorithm data. Note that this document assumes, that each key exchange method requires one round trip and consumes exactly one IKE_INTERMEDIATE exchange. This assumption is valid for all classic key exchange methods defined so far and for all post-quantum methods currently known. For hypothetical future key exchange methods requiring multiple round trips to complete, a separate document should define how such methods are split into several IKE_INTERMEDIATE exchanges. In order to minimize communication overhead, only the key shares that are agreed to be used are actually exchanged. To negotiate additional key exchanges seven new Transform Types are defined. These transforms and Transform Type 4 share the same Transform IDs. Tjhai, et al. Expires 4 June 2023 [Page 8] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 It is assumed that new Transform Type 4 identifiers will be assigned later for various post-quantum key exchanges [IKEV2TYPE4ID]. This specification does not make a distinction between classical (EC)DH and post-quantum key exchanges, nor post-quantum algorithms which are true key exchanges versus post-quantum algorithms that act as key transport mechanisms; all are treated equivalently by the protocol. This document renames a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)"; the corresponding renaming to the IANA registry is described in Section 3. The fact that newly defined transforms share the same registry for possible Transform IDs with Transform Type 4, allows additional key exchanges to be of any type - either post-quantum or classical (EC)DH one. This approach allows any combination of the defined key exchange methods to take place. This also allows IKE peers to perform a single post-quantum key exchange in the IKE_SA_INIT without additional key exchanges, provided that the IP fragmentation is not an issue and that hybrid key exchange is not needed. The SA payload in the IKE_SA_INIT message includes one or more newly defined transforms which represent the extra key exchange policy required by the initiator. The responder follows the usual IKEv2 negotiation rules: it selects a single transform of each type, and returns all of them in the IKE_SA_INIT response message. Then, provided that additional key exchanges are negotiated, the initiator and the responder perform one or more IKE_INTERMEDIATE exchanges. Following that, the IKE_AUTH exchange authenticates peers and completes IKE SA establishment. Initiator Responder --------------------------------------------------------------------- <-- IKE_SA_INIT (additional key exchanges negotiation) --> <-- {IKE_INTERMEDIATE (additional key exchange)} --> ... <-- {IKE_INTERMEDIATE (additional key exchange)} --> <-- {IKE_AUTH} --> Tjhai, et al. Expires 4 June 2023 [Page 9] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 2.2. Protocol Details In the simplest case, the initiator starts a single key exchange (and has no interest in supporting multiple), and it is not concerned with possible fragmentation of the IKE_SA_INIT messages (either because the key exchange it selects is small enough not to fragment, or the initiator is confident that fragmentation will be handled either by IP fragmentation, or transport via TCP). In this case, the initiator performs the IKE_SA_INIT for a single key exchange using a Transform Type 4 (possibly with a post quantum algorithm), and including the initator KE payload. If the responder accepts the policy, it responds with an IKE_SA_INIT response, and IKE continues as usual. If the initiator desires to negotiate multiple key exchanges, then the initiator uses the protocol behavior listed below. 2.2.1. IKE_SA_INIT Round: Negotiation Multiple key exchanges are negotiated using the standard IKEv2 mechanism, via SA payload. For this purpose seven new transform types, namely Additional Key Exchange 1 (with IANA assigned value 6), Additional Key Exchange 2 (7), Additional Key Exchange 3 (8), Additional Key Exchange 4 (9), Additional Key Exchange 5 (10), Additional Key Exchange 6 (11) and Additional Key Exchange 7 (12) are defined. They are collectively called Additional Key Exchange transforms in this document and have slightly different semantics than the existing IKEv2 transform types. They are interpreted as an indication of additional key exchange methods that peers agree to perform in a series of IKE_INTERMEDIATE exchanges following the IKE_SA_INIT exchange. The allowed transform IDs for these transform types are the same as the IDs for Transform Type 4, so they all share a single IANA registry for transform IDs. Key exchange method negotiated via Transform Type 4 always takes place in the IKE_SA_INIT exchange, as defined in [RFC7296]. Additional key exchanges negotiated via newly defined transforms MUST take place in a series of IKE_INTERMEDIATE exchanges following the IKE_SA_INIT exchange, performed in an order of the values of their transform types, so that key exchange negotiated using Additional Key Exchange i always precedes that of Additional Key Exchange i + 1. Each additional key exchange method MUST be fully completed before the next one is started. Note that with these semantics, Additional Key Exchange transforms are not associated with any particular type of key exchange and do not have any specific per transform type transform IDs IANA registry. Tjhai, et al. Expires 4 June 2023 [Page 10] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 Instead they all share a single registry for transform IDs, namely "Key Exchange Method Transform IDs", which are also shared by Transform Type 4. All key exchange algorithms (both classical or post-quantum) should be added to this registry. This approach gives peers flexibility in defining the ways they want to combine different key exchange methods. When forming a proposal the initiator adds transforms for the IKE_SA_INIT exchange using Transform Type 4. In most cases they will contain classical (EC)DH key exchange methods, however it is not a requirement. Additional key exchange methods are proposed using Additional Key Exchange transform types. All of these transform types are optional, the initiator is free to select any of them for proposing additional key exchange methods. Consequently, if none of the Additional Key Exchange transforms is included in the proposal, then this proposal indicates performing standard IKEv2, as defined in [RFC7296]. On the other hand, if the initiator includes any Additional Key Exchange transform in the proposal, the responder MUST select one of the algorithms proposed using this type. Note that this is not a new requirement, but that this behavior is already specified in Section 2.7 of [RFC7296]. A transform ID NONE MAY be added to those transform types which contain key exchange methods that the initiator believes is optional according to its local policy. The responder performs the negotiation using the standard IKEv2 procedure described in Section 3.3 of [RFC7296]. However, for the Additional Key Exchange types, the responder's choice MUST NOT contain duplicated algorithms (those with identical Transform ID and attributes), except for the transform ID of NONE. An algorithm is represented as a transform, in some cases the transform could include a set of associated attributes that define details of the algorithm. In this case, two transforms can be the same, but the attributes must be different. Additionally, the order of the attributes does not affect the equality of the algorithm, so two transforms (ID=alg1,ATTR1=attr1,ATTR2=attr2) and (ID=alg1,ATTR2=attr2,ATTR1=attr1) define the same algorithm. If the responder is unable to select non-duplicated algorithm for each proposed key exchange (either because the proposal contains too few choices or due to the local policy restrictions on using the proposed algorithms), then the responder MUST reject the message with an error notification of type NO_PROPOSAL_CHOSEN. If the responder's message contains one or more duplicated choices, the initiator should log the error and MUST treat the exchange as failed. The initiator MUST NOT initiate any IKE_INTERMEDIATE (or IKE_FOLLOWUP_KE) exchanges, so that no new SA is created. If this happens in the CREATE_CHILD_SA exchange, then the initiator MAY delete the IKE SA, over which the invalid message was received, by sending a Delete payload. Tjhai, et al. Expires 4 June 2023 [Page 11] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 If the responder selects NONE for some Additional Key Exchange types (provided they are proposed by the initiator), then the corresponding Additional Key Exchange(s) in the IKE_INTERMEDIATE exchange(s) MUST NOT take place. Therefore if the initiator includes NONE in all of the Additional Key Exchange transforms and the responder selects this value for all of them, then no IKE_INTERMEDIATE messages performing additional key exchanges will take place between the peers. Note that the IKE_INTERMEDIATE exchanges may still take place for other purposes. The initiator MAY propose non-consecutive Additional Key Exchange transforms, for example proposing Additional Key Exchange 2 and Additional Key Exchange 5 transforms only. The responder MUST treat all of the omitted Additional Key Exchange transforms as if they are proposed with Transform ID NONE. Below is an example of the SA payload in the initiator's IKE_SA_INIT request message. Here the abbreviation AKEi is used to denote the i-th Additional Key Exchange transform defined in this document, and an abbreviation KE for the Key Exchange transform, that this document renames from the Diffie-Hellman Group transform. Additionally, the notations PQ_KEM_1, PQ_KEM_2 and PQ_KEM_3 are used to represent some not-yet defined Transform IDs of some popular post-quantum key exchange methods. Tjhai, et al. Expires 4 June 2023 [Page 12] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 SA Payload | +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 8, | 9 transforms, SPI = 0x35a1d6f22564f89d ) | +-- Transform ENCR ( ID = ENCR_AES_GCM_16 ) | +-- Attribute ( Key Length = 256 ) | +-- Transform KE ( ID = 4096-bit MODP Group ) | +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 ) | +-- Transform AKE2 ( ID = PQ_KEM_1 ) | +-- Transform AKE2 ( ID = PQ_KEM_2 ) | +-- Transform AKE3 ( ID = PQ_KEM_1 ) | +-- Transform AKE3 ( ID = PQ_KEM_2 ) | +-- Transform AKE5 ( ID = PQ_KEM_3 ) | +-- Transform AKE5 ( ID = NONE ) In this example, the initiator proposes to perform initial key exchange using 4096-bit MODP group followed by two mandatory additional key exchanges (i.e. Transforms AKE2 and AKE3) using PQ_KEM_1 and PQ_KEM_2 methods in any order, then followed by additional key exchange (i.e. Transform AKE5) using PQ_KEM_3 method that may be omitted. The responder might return the following SA payload, indicating that it agrees to perform two additional key exchanges PQ_KEM_2 followed by PQ_KEM_1 and does not want to perform PQ_KEM_3 additionally. Tjhai, et al. Expires 4 June 2023 [Page 13] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 SA Payload | +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 8, | 6 transforms, SPI = 0x8df52b331a196e7b ) | +-- Transform ENCR ( ID = ENCR_AES_GCM_16 ) | +-- Attribute ( Key Length = 256 ) | +-- Transform KE ( ID = 4096-bit MODP Group ) | +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 ) | +-- Transform AKE2 ( ID = PQ_KEM_2 ) | +-- Transform AKE3 ( ID = PQ_KEM_1 ) | +-- Transform AKE5 ( ID = NONE ) If the initiator includes any Additional Key Exchange transform types into the SA payload in the IKE_SA_INIT exchange request message, then it MUST also negotiate the use of the IKE_INTERMEDIATE exchange as described in [RFC9242], by including INTERMEDIATE_EXCHANGE_SUPPORTED notification in the same message. If the responder agrees to use additional key exchanges while establishing initial IKE SA, it MUST also return this notification in the IKE_SA_INIT response message, thus confirming that IKE_INTERMEDIATE exchange is supported and will be used for transferring additional key exchange data. If the IKE_INTERMEDIATE exchange is not negotiated, then the peers MUST treat any Additional Key Exchange transforms in the IKE_SA_INIT exchange messages as unknown transform types and skip the proposals they appear in. If no other proposals are present in the SA payload, the peers will proceed as if no proposal is chosen (i.e. the responder will send NO_PROPOSAL_CHOSEN notification). Initiator Responder --------------------------------------------------------------------- HDR, SAi1(.. AKE*...), KEi, Ni, N(INTERMEDIATE_EXCHANGE_SUPPORTED) ---> HDR, SAr1(.. AKE*...), KEr, Nr, [CERTREQ], <--- N(INTERMEDIATE_EXCHANGE_SUPPORTED) It is possible that an attacker manages to send a response to the initiator's IKE_SA_INIT request before the legitimate responder does. If the initiator continues to create the IKE SA using this response, the attempt will fail. Implementers may wish to consider a possible defense technique described in Section 2.4 of [RFC7296]. Tjhai, et al. Expires 4 June 2023 [Page 14] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 2.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges For each additional key exchange agreed to in the IKE_SA_INIT exchange, the initiator and the responder perform IKE_INTERMEDIATE exchange, as described in [RFC9242]. Initiator Responder --------------------------------------------------------------------- HDR, SK {KEi(n)} --> <-- HDR, SK {KEr(n)} The initiator sends key exchange data in the KEi(n) payload. This message is protected with the current SK_ei/SK_ai keys. The notation KEi(n) denotes the n-th IKE_INTERMEDIATE KE payload from the initiator and the integer n is sequential starting from 1. On receiving this, the responder sends back key exchange payload KEr(n), which denotes the n-th IKE_INTERMEDIATE KE payload from the responder. As before, this message is protected with the current SK_er/SK_ar keys. The former "Diffie-Hellman Group Num" (now called "Key Exchange Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th negotiated additional key exchange. Once this exchange is done, both sides compute an updated keying material: SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr) where SK(n) is the resulting shared secret of this key exchange, Ni and Nr are nonces from the IKE_SA_INIT exchange and SK_d(n-1) is the last generated SK_d, (derived from IKE_SA_INIT for the first use of IKE_INTERMEDIATE, otherwise from the previous IKE_INTERMEDIATE exchange). The other keying materials SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr are generated from the SKEYSEED(n) as follows: {SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) | SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr) Both the initiator and the responder use these updated key values in the next exchange (IKE_INTERMEDIATE or IKE_AUTH). Tjhai, et al. Expires 4 June 2023 [Page 15] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 2.2.3. IKE_AUTH Exchange After all IKE_INTERMEDIATE exchanges have completed, the initiator and the responder perform an IKE_AUTH exchange. This exchange is the standard IKE exchange as described in [RFC7296] with the modification of AUTH payload calculation described in [RFC9242]. 2.2.4. CREATE_CHILD_SA Exchange The CREATE_CHILD_SA exchange is used in IKEv2 for the purposes of creating additional Child SAs, rekeying these and rekeying IKE SA itself. When creating or rekeying Child SAs, the peers may optionally perform a key exchange to add a fresh entropy into the session keys. In case of IKE SA rekey, the key exchange is mandatory. Peers supporting this specification may want to use multiple key exchanges in these situations. Using multiple key exchanges with CREATE_CHILD_SA exchange is negotiated similarly as in the initial IKE exchange, see Section 2.2.1. If the initiator includes any Additional Key Exchange transform in the SA payload (along with Transform Type 4) and the responder agrees to perform additional key exchanges, then the additional key exchanges are performed in a series of new IKE_FOLLOWUP_KE exchanges that follows the CREATE_CHILD_SA exchange. The IKE_FOLLOWUP_KE exchange is introduced as a dedicated exchange for transferring data of additional key exchanges following the key exchange performed in the CREATE_CHILD_SA. Its Exchange Type value is 44. Key exchange negotiated via Transform Type 4 always takes place in the CREATE_CHILD_SA exchange, as per IKEv2 specification. Additional key exchanges are performed in an order of the values of their transform types, so that key exchange negotiated using Transform Type n always precedes key exchange negotiated using Transform Type n + 1. Each additional key exchange method MUST be fully completed before the next one is started. Note, that this document assumes, that each key exchange method consumes exactly one IKE_FOLLOWUP_KE exchange. For the methods requiring multiple round trips, a separate document should define how such methods are split into several IKE_FOLLOWUP_KE exchanges. After an IKE SA is created the window size may be greater than one and multiple concurrent exchanges may be in progress, it is essential to link the IKE_FOLLOWUP_KE exchanges together with the corresponding CREATE_CHILD_SA exchange. Due to the fact that once an IKE SA is created, all IKE exchanges are independent and do not have built-in means to link one with another, a new status type notification ADDITIONAL_KEY_EXCHANGE is introduced for this purpose. Its Notify Tjhai, et al. Expires 4 June 2023 [Page 16] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 Message Type value is 16441, and Protocol ID and SPI Size are both set to 0. The data associated with this notification is a blob meaningful only to the responder, so that the responder can correctly link successive exchanges. For the initiator the content of this notification is an opaque blob. The responder MUST include this notification in a CREATE_CHILD_SA or IKE_FOLLOWUP_KE response message in case the next IKE_FOLLOWUP_KE exchange is expected, filling it with some data that would allow linking the current exchange to the next one. The initiator MUST send back this notification intact in the request message of the next IKE_FOLLOWUP_KE exchange. Below is an example of CREATE_CHILD_SA exchange followed by three additional key exchanges. Initiator Responder --------------------------------------------------------------------- HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, N(ADDITIONAL_KEY_EXCHANGE)(link1)} HDR(IKE_FOLLOWUP_KE), SK {KEi(1), N(ADDITIONAL_KEY_EXCHANGE)(link1)} --> <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(1), N(ADDITIONAL_KEY_EXCHANGE)(link2)} HDR(IKE_FOLLOWUP_KE), SK {KEi(2), N(ADDITIONAL_KEY_EXCHANGE)(link2)} --> <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(2), N(ADDITIONAL_KEY_EXCHANGE)(link3)} HDR(IKE_FOLLOWUP_KE), SK {KEi(3), N(ADDITIONAL_KEY_EXCHANGE)(link3)} --> <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(3)} The former "Diffie-Hellman Group Num" (now called "Key Exchange Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th negotiated additional key exchange. It is possible that due to some unexpected events (e.g. reboot) the initiator may lose its state and forget that it is in the process of performing additional key exchanges and thus never start the remaining IKE_FOLLOWUP_KE exchanges. The responder MUST handle this situation gracefully and delete the associated state if it does not receive the next expected IKE_FOLLOWUP_KE request after some reasonable period of time. Note that due to various factors such as computational resource and key exchange algorithm used, it is not Tjhai, et al. Expires 4 June 2023 [Page 17] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 possible to give a normative guidance on how long this timeout period should be. In general, 5-20 seconds of waiting time should be appropriate in most cases. It is also possible that the initiator may take too long to prepare and send the next IKE_FOLLOWUP_KE request or due to the network conditions, the request is retransmitted. In this case, the message may reach the responder when it has already deleted the associated state following the advice above. If the responder receives an IKE_FOLLOWUP_KE message for which it does not have a key exchange state, it MUST send back a new error type notification STATE_NOT_FOUND. This is a non-fatal error notification, its Notify Message Type is 47, Protocol ID and SPI Size are both set to 0 and the data is empty. If the initiator receives this notification in response to IKE_FOLLOWUP_KE exchange performing additional key exchange, it MUST cancel this exchange and MUST treat the whole series of exchanges started from the CREATE_CHILD_SA exchange as failed. In most cases, the receipt of this notification is caused by premature deletion of the corresponding state on the responder (the time period between IKE_FOLLOWUP_KE exchanges appeared too long from the responder's point of view, e.g. due to a temporary network failure). After receiving this notification the initiator MAY start a new CREATE_CHILD_SA exchange which may eventually be followed by the IKE_FOLLOWUP_KE exchanges, to retry the failed attempt. If the initiator continues to receive STATE_NOT_FOUND notifications after several retries, it MUST treat this situation as a fatal error and delete IKE SA by sending a DELETE payload. When rekeying the IKE SA or the Child SA, it is possible that the peers start doing this at the same time, which is called simultaneous rekeying. Sections 2.8.1 and 2.8.2 of [RFC7296] describe how IKEv2 handles this situation. In a nutshell IKEv2 follows the rule that if in case of simultaneous rekeying, two identical new IKE SAs (or two pairs of Child SAs) are created, then one of them should be deleted. Which one is to be deleted is determined by comparing the values of four nonces that are used in the colliding CREATE_CHILD_SA exchanges. The IKE SA (or pair of Child SAs) that is created by the exchange in which the smallest nonce is used should be deleted by the initiator of this exchange. With multiple key exchanges, the SAs are not yet created when the CREATE_CHILD_SA is completed, they would be created only after the series of IKE_FOLLOWUP_KE exchanges is finished. For this reason, if additional key exchanges are negotiated in the CREATE_CHILD_SA exchange in which the smallest nonce is used, then because there is nothing to delete yet, the initiator of this exchange just stops the rekeying process and it MUST NOT initiate the IKE_FOLLOWUP_KE exchange. Tjhai, et al. Expires 4 June 2023 [Page 18] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 In most cases, rekey collisions are resolved in the CREATE_CHILD_SA exchange. However, a situation may occur when due to packet loss, one of the peers receives the CREATE_CHILD_SA message requesting rekey of SA that is already being rekeyed by this peer (i.e. the CREATE_CHILD_SA exchange initiated by this peer has been already completed and the series of IKE_FOLLOWUP_KE exchanges is in progress). In this case, a TEMPORARY_FAILURE notification MUST be sent in response to such a request. If multiple key exchanges are negotiated in the CREATE_CHILD_SA exchange, then the resulting keys are computed as follows. In case of IKE SA rekey: SKEYSEED = prf(SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n)) In case of Child SA creation or rekey: KEYMAT = prf+ (SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n)) In both cases, SK_d is from the existing IKE SA; SK(0), Ni, Nr are the shared key and nonces from the CREATE_CHILD_SA respectively; SK(1)...SK(n) are the shared keys from additional key exchanges. 2.2.5. Interaction with IKEv2 Extensions It is believed that this specification requires no modification to the IKEv2 extensions defined so far. In particular, IKE SA resumption mechanism defined in [RFC5723] can be used to resume IKE SAs created using this specification. 2.2.5.1. Interaction with Childless IKE SA It is possible to establish IKE SAs with post-quantum algorithms only using additional key exchanges, but without using IKE_INTERMEDIATE exchanges. In this case, the IKE SA created from IKE_SA_INIT exchange can be immediately rekeyed with CREATE_CHILD_SA using additional key exchanges where IKE_FOLLOWUP_KE messages are used to carry the key exchange payload. If classical key exchange method is used in the IKE_SA_INIT message, the very first Child SA created in IKE_AUTH will offer no resistance against the quantum threats. Consequently, if the peers' local policy requires that all Child SAs to be post-quantum secure, then the peers can avoid creating the very first Child SA by adopting [RFC6023]. In this case, the initiator sends two types of proposal in the IKE_SA_INIT request, one with and another one without Additional Key Exchange transform(s). The responder chooses the latter proposal type and includes CHILDLESS_IKEV2_SUPPORTED notification in the IKE_SA_INIT response. Tjhai, et al. Expires 4 June 2023 [Page 19] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 Assuming that the initiator supports childless IKE SA extension, then both peers performs the modified IKE_AUTH exchange described in [RFC6023] and no Child SA is created in this exchange. The peers should then immediately rekey the IKE SA and subsequently create the Child SAs, all with additional key exchanges using CREATE_CHILD_SA exchange. It is also possible for the initiator to send proposals without Additional Key Exchange transform(s) in the IKE_SA_INIT message and in this instance, the responder will have no information whether or not the initiator supports the extension in this specification. This may not be efficient as the responder will have to wait for the subsequent CREATE_CHILD_SA request to determine whether or not the initiator's request is appropriate for its local policy. The support for childless IKE SA is not negotiated, but it is the responder that indicates the support for this mode. As such, the responder cannot enforce the initiator to use this mode and therefore, it is entirely possible that the initiator does not support this extension and sends IKE_AUTH request as per [RFC7296] instead of [RFC6023]. In this case, the responder may respond with non-fatal error such as NO_PROPOSAL_CHOSEN notify message type. Note that if the initial IKE SA is used to transfer sensitive information, then this information will not be protected using the additional key exchanges, which may use post-quantum algorithms. In this arrangement, the peers will have to use post-quantum algorithm in Transform Type 4 in order to mitigate the risk of quantum attack. 3. IANA Considerations This document adds new exchange type into the "IKEv2 Exchange Types" registry: 44 IKE_FOLLOWUP_KE This document renames Transform Type 4 defined in "Transform Type Values" registry from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)". This document renames IKEv2 registry "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". This document adds the following Transform Types to the "Transform Type Values" registry: Tjhai, et al. Expires 4 June 2023 [Page 20] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 Type Description Used In ----------------------------------------------------------------- 6 Additional Key Exchange 1 (optional in IKE, AH, ESP) 7 Additional Key Exchange 2 (optional in IKE, AH, ESP) 8 Additional Key Exchange 3 (optional in IKE, AH, ESP) 9 Additional Key Exchange 4 (optional in IKE, AH, ESP) 10 Additional Key Exchange 5 (optional in IKE, AH, ESP) 11 Additional Key Exchange 6 (optional in IKE, AH, ESP) 12 Additional Key Exchange 7 (optional in IKE, AH, ESP) This document defines a new Notify Message Type in the "Notify Message Types - Status Types" registry: 16441 ADDITIONAL_KEY_EXCHANGE and a new Notify Message Type in the "Notify Message Types - Error Types" registry: 47 STATE_NOT_FOUND 3.1. Additional Considerations and Changes The IANA is requested to add the following instructions for designated experts for Transform Type 4 sub-registry. While adding new KE methods, the following considerations must be applied. A KE method must take exactly one round-trip (one IKE exchange) and at the end of this exchange, both peers must be able to derive the shared secret. In addition, any public value peers exchanged during a KE method must fit into a single IKE message. If these restrictions are not met for a KE method, then there must be documentation on how this KE method is used in IKEv2. The following changes to IANA are also requested. It is assumed that RFCXXXX refers to this specification. * Add a reference to RFCXXXX in the "Transform Type 4 - Diffie- Hellman Group Transform IDs" registry. * Replace the note on "Transform Type 4 - Diffie-Hellman Group Transform IDs" registry with: This registry was originally named "Transform Type 4 - Diffie-Hellman Group Transform IDs" and was renamed to its current name by [RFCXXXX]. It has been referenced in its original name in a number of RFCs prior to [RFCXXXX]. To find out requirement levels for Key Exchange Methods for IKEv2, see [RFC8247]. Tjhai, et al. Expires 4 June 2023 [Page 21] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 * Add this note to "Transform Type Values" registry: Transform Type "Transform Type 4 - Key Exchange Method Transform IDs" was originally named "Transform Type 4 - Diffie-Hellman Group Transform IDs" and was renamed to its current name by [RFCXXXX]. It has been referenced in its original name in a number of RFCs prior to [RFCXXXX]. All "Additional Key Exchange" entries use the same "Transform Type 4 - Key Exchange Method Transform IDs" as the "Key Exchange Method (KE)". * Append RFCXXXX to the Reference column of Transform Type 4 in the Transform Type Values registry. * Append this note to "Transform Type 4 - Diffie-Hellman Group Transform IDs" registry: All "Additional Key Exchange" entries use these values as the "Key Exchange Method (KE)". 4. Security Considerations The extension in this document is intended to mitigate two possible threats in IKEv2, namely the compromise of (EC)DH key exchange using Shor's algorithm while remaining backward compatible; and the potential compromise of existing or future PQC key exchange algorithms. To address the former threat, this extension allows the establishment of a shared secret by using multiple key exchanges, typically one classical (EC)DH and the other one post-quantum algorithm. In order to address the latter threat, multiple key exchanges using a post-quantum algorithm can be composed to form the shared key. Unlike key exchange methods (Transform Type 4), the Encryption Algorithm (Transform Type 1), the Pseudorandom Function (Transform Type 2) and the Integrity Algorithm (Transform Type 3) are not susceptible to Shor's algorithm. However, they are susceptible to Grover's attack [GROVER], which allows a quantum computer to perform a brute force key search using quadratically fewer steps than the classical counterpart. Simply increasing the key length can mitigate this attack. It was previously believed that one needed to double the key length of these algorithms. However, there are a number of factors that suggest that it is quite unlikely to achieve the quadratic speed up using Grover's algorithm. According to NIST [NISTPQCFAQ], current applications can continue using AES algorithm with the minimum key length of 128 bit. Nevertheless, if the data needs to remain secure for many years to come, one may want to consider using a longer key size for the algorithms in Transform Types 1-3. Tjhai, et al. Expires 4 June 2023 [Page 22] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 SKEYSEED is calculated from shared SK(x) using an algorithm defined in Transform Type 2. While a quantum attacker may learn the value of SK(x), if this value is obtained by means of a classical key exchange, other SK(x) values generated by means of a post-quantum algorithm ensure that the final SKEYSEED is not compromised. This assumes that the algorithm defined in the Transform Type 2 is quantum resistant. The ordering of the additional key exchanges should not matter in general, as only the final shared secret is of interest. Nonetheless, because the strength of the running shared secret increases with every additional key exchange, an implementer may want to first perform the most secure method (in some metrics) and followed by less secure one(s). The main focus of this document is to prevent a passive attacker performing a "harvest and decrypt" attack. In other words, an attacker that records messages exchanged today and proceeds to decrypt them once he owns a quantum computer. This attack is prevented due to the hybrid nature of the key exchange. Other attacks involving an active attacker using a quantum-computer are not completely solved by this document. This is for two reasons. The first reason is because the authentication step remains classical. In particular, the authenticity of the SAs established under IKEv2 is protected using a pre-shared key or digital signature algorithms. Whilst the pre-shared key option, provided the key is long enough, is post-quantum secure, the other algorithms are not. Moreover, in implementations where scalability is a requirement, the pre-shared key method may not be suitable. Post-quantum authenticity may be provided by using a post-quantum digital signature. Secondly, it should be noted that the purpose of post-quantum algorithms is to provide resistance to attacks mounted in the future. The current threat is that encrypted sessions are subject to eavesdropping and archived with decryption by quantum computers taking place at some point in the future. Until quantum computers become available there is no point in attacking the authenticity of a connection because there are no possibilities for exploitation. These only occur at the time of the connection, for example by mounting an on-path attack. Consequently there is less urgency for post-quantum authenticity compared to post-quantum confidentiality. Tjhai, et al. Expires 4 June 2023 [Page 23] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 Performing multiple key exchanges while establishing IKE SA increases the responder's susceptibility to DoS attacks, because of an increased amount of resources needed before the initiator is authenticated. This is especially true for post-quantum key exchange methods, where many of them are more memory and/or CPU intensive than the classical counterparts. Responders may consider recommendations from [RFC8019] to deal with increased DoS attack susceptibility. It is also possible that the responder only agrees to create initial IKE SA without performing additional key exchanges, provided the initiator includes such an option in its proposals. Then peers immediately rekey the initial IKE SA with the CREATE_CHILD_SA exchange and additional key exchanges performed via the IKE_FOLLOWUP_KE exchanges. In this case, at the point when resource-intensive operations are required, the peers have already authenticated each other. However, in the context of hybrid post-quantum key exchange this scenario would leave the initial IKE SA (and initial Child SA if it is created) unprotected against quantum computers. Nevertheless the rekeyed IKE SA (and Child SAs that will be created over it) will have a full protection. This is similar to the scenario described in [RFC8784]. Depending on the arrangement and peers' policy, this scenario may or may not be appropriate. For example, in the G-IKEv2 protocol [I-D.ietf-ipsecme-g-ikev2] the cryptographic materials are sent from the group controller to the group members when the initial IKE SA is created. 5. Acknowledgements The authors would like to thank Frederic Detienne and Olivier Pelerin for their comments and suggestions, including the idea to negotiate the post-quantum algorithms using the existing KE payload. The authors are also grateful to Tobias Heider and Tobias Guggemos for valuable comments. Thanks to Paul Wouters for reviewing the document. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Tjhai, et al. Expires 4 June 2023 [Page 24] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9242] Smyslov, V., "Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 9242, DOI 10.17487/RFC9242, May 2022, . 6.2. Informative References [GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for Database Search", Proc. of the Twenty-Eighth Annual ACM Symposium on the Theory of Computing (STOC 1996), 1996. [I-D.ietf-ipsecme-g-ikev2] Smyslov, V. and B. Weis, "Group Key Management using IKEv2", Work in Progress, Internet-Draft, draft-ietf- ipsecme-g-ikev2-07, 6 October 2022, . [I-D.tjhai-ikev2-beyond-64k-limit] Tjhai, C., Heider, T., and V. Smyslov, "Beyond 64KB Limit of IKEv2 Payloads", Work in Progress, Internet-Draft, draft-tjhai-ikev2-beyond-64k-limit-03, 28 July 2022, . [IKEV2TYPE4ID] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters: Transform Type 4 - Diffie-Hellman Group Transform IDs", . [NISTPQCFAQ] NIST, "Post-Quantum Cryptography Standardization: FAQs", . Tjhai, et al. Expires 4 June 2023 [Page 25] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, DOI 10.17487/RFC5723, January 2010, . [RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)", RFC 6023, DOI 10.17487/RFC6023, October 2010, . [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, . [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks", RFC 8019, DOI 10.17487/RFC8019, November 2016, . [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, "Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security", RFC 8784, DOI 10.17487/RFC8784, June 2020, . Appendix A. Sample Multiple Key Exchanges This appendix shows some examples of multiple key exchanges. These examples are non-normative and they describe some message flow scenarios that may occur in establishing an IKE or CHILD SA. Note that some payloads that are not relevant to multiple key exchanges may be omitted for brevity. A.1. IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange Payloads The exchanges below show that the initiator proposes the use of additional key exchanges to establish an IKE SA. The initiator proposes three sets of additional key exchanges and all of which are optional. So the responder can choose NONE for some or all of the additional exchanges if the proposed key exchange methods are not supported or for whatever reasons the responder decides not to perform the additional key exchange. Tjhai, et al. Expires 4 June 2023 [Page 26] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 Initiator Responder --------------------------------------------------------------------- HDR(IKE_SA_INIT), SAi1(.. AKE*...), ---> KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED), N(INTERMEDIATE_EXCHANGE_SUPPORTED) Proposal #1 Transform ECR (ID = ENCR_AES_GCM_16, 256-bit key) Transform PRF (ID = PRF_HMAC_SHA2_512) Transform KE (ID = Curve25519) Transform AKE1 (ID = PQ_KEM_1) Transform AKE1 (ID = PQ_KEM_2) Transform AKE1 (ID = NONE) Transform AKE2 (ID = PQ_KEM_3) Transform AKE2 (ID = PQ_KEM_4) Transform AKE2 (ID = NONE) Transform AKE3 (ID = PQ_KEM_5) Transform AKE3 (ID = PQ_KEM_6) Transform AKE3 (ID = NONE) <--- HDR(IKE_SA_INIT), SAr1(.. AKE*...), KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED), N(INTERMEDIATE_EXCHANGE_SUPPORTED) Proposal #1 Transform ECR (ID = ENCR_AES_GCM_16, 256-bit key) Transform PRF (ID = PRF_HMAC_SHA2_512) Transform KE (ID = Curve25519) Transform AKE1 (ID = PQ_KEM_2) Transform AKE2 (ID = NONE) Transform AKE3 (ID = PQ_KEM_5) HDR(IKE_INTERMEDIATE), SK {KEi(1)(PQ_KEM_2)} --> <--- HDR(IKE_INTERMEDIATE), SK {KEr(1)(PQ_KEM_2)} HDR(IKE_INTERMEDIATE), SK {KEi(2)(PQ_KEM_5)} --> <--- HDR(IKE_INTERMEDIATE), SK {KEr(2)(PQ_KEM_5)} HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } ---> <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2, TSi, TSr } Tjhai, et al. Expires 4 June 2023 [Page 27] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 In this particular example, the responder chooses to perform two additional key exchanges. It selects PQ_KEM_2, NONE and PQ_KEM_5 for the first, second and third additional key exchanges respectively. As per [RFC7296] specification, a set of keying materials are derived, in particular SK_d, SK_a[i/r], SK_e[i/r]. Both peers then perform an IKE_INTERMEDIATE exchange carrying PQ_KEM_2 payload which is protected with SK_e[i/r] and SK_a[i/r] keys. After the completion of this IKE_INTERMEDIATE exchange, the SKEYSEED is updated using SK(1), which is the PQ_KEM_2 shared secret, as follows. SKEYSEED(1) = prf(SK_d, SK(1) | Ni | Nr) The updated SKEYSEED value is then used to derive the following keying materials {SK_d(1) | SK_ai(1) | SK_ar(1) | SK_ei(1) | SK_er(1) | SK_pi(1) | SK_pr(1)} = prf+ (SKEYSEED(1), Ni | Nr | SPIi | SPIr) As per [RFC9242] specification, both peers compute IntAuth_i1 and IntAuth_r1 using the SK_pi(1) and SK_pr(1) keys respectively. These values are required in the IKE_AUTH phase of the exchange. In the next IKE_INTERMEDIATE exchange, the peers use SK_e[i/r](1) and SK_a[i/r](1) keys to protect the PQ_KEM_5 payload. After completing this exchange, keying materials are updated as below SKEYSEED(2) = prf(SK_d(1), SK(2) | Ni | Nr) {SK_d(2) | SK_ai(2) | SK_ar(2) | SK_ei(2) | SK_er(2) | SK_pi(2) | SK_pr(2)} = prf+ (SKEYSEED(2), Ni | Nr | SPIi | SPIr) where SK(2) is the shared secret from the third additional key exchange, i.e. PQ_KEM_5. Both peers then compute the values of IntAuth_[i/r]2 using the SK_p[i/r](2) keys. After the completion of the second IKE_INTERMEDIATE exchange, both peers continue to the IKE_AUTH exchange phase. As defined in [RFC9242], the values IntAuth_[i/r]2 are used to compute IntAuth which in turn is used to calculate the payload to be signed or MACed, i.e. InitiatorSignedOctets and ResponderSignedOctets. A.2. No Additional Key Exchange Used The initiator proposes two sets of optional additional key exchanges, but the responder does not support any of them. The responder chooses NONE for each set and consequently, IKE_INTERMEDIATE exchange does not takes place and the exchange proceeds to IKE_AUTH phase. The resulting keying materials are the same as those derived with [RFC7296]. Tjhai, et al. Expires 4 June 2023 [Page 28] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 Initiator Responder --------------------------------------------------------------------- HDR(IKE_SA_INIT), SAi1(.. AKE*...), ---> KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED), N(INTERMEDIATE_EXCHANGE_SUPPORTED) Proposal #1 Transform ECR (ID = ENCR_AES_GCM_16, 256-bit key) Transform PRF (ID = PRF_HMAC_SHA2_512) Transform KE (ID = Curve25519) Transform AKE1 (ID = PQ_KEM_1) Transform AKE1 (ID = PQ_KEM_2) Transform AKE1 (ID = NONE) Transform AKE2 (ID = PQ_KEM_3) Transform AKE2 (ID = PQ_KEM_4) Transform AKE2 (ID = NONE) <--- HDR(IKE_SA_INIT), SAr1(.. AKE*...), KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED), N(INTERMEDIATE_EXCHANGE_SUPPORTED) Proposal #1 Transform ECR (ID = ENCR_AES_GCM_16, 256-bit key) Transform PRF (ID = PRF_HMAC_SHA2_512) Transform KE (ID = Curve25519) Transform AKE1 (ID = NONE) Transform AKE2 (ID = NONE) HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } ---> <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2, TSi, TSr } A.3. Additional Key Exchange in the CREATE_CHILD_SA Exchange only The exchanges below show that the initiator does not propose the use of additional key exchanges to establish an IKE SA, but they are required in order to establish a Child SA. In order to establish a fully quantum-resistant IPsec SA, the responder includes a CHILDLESS_IKEV2_SUPPORTED notification in their IKE_SA_INIT response message. The initiator understands and supports this notification, then exchanges a modified IKE_AUTH message with the responder and rekeys the IKE SA immediately with additional key exchanges. Any Child SA will have to be created via subsequent CREATED_CHILD_SA exchange. Tjhai, et al. Expires 4 June 2023 [Page 29] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 Initiator Responder --------------------------------------------------------------------- HDR(IKE_SA_INIT), SAi1, ---> KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED) <--- HDR(IKE_SA_INIT), SAr1, KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED), N(CHILDLESS_IKEV2_SUPPORTED) HDR(IKE_AUTH), SK{ IDi, AUTH } ---> <--- HDR(IKE_AUTH), SK{ IDr, AUTH } HDR(CREATE_CHILD_SA), SK{ SAi(.. AKE*...), Ni, KEi(Curve25519) } ---> Proposal #1 Transform ECR (ID = ENCR_AES_GCM_16, 256-bit key) Transform PRF (ID = PRF_HMAC_SHA2_512) Transform KE (ID = Curve25519) Transform AKE1 (ID = PQ_KEM_1) Transform AKE1 (ID = PQ_KEM_2) Transform AKE2 (ID = PQ_KEM_5) Transform AKE2 (ID = PQ_KEM_6) Transform AKE2 (ID = NONE) <--- HDR(CREATE_CHILD_SA), SK{ SAr(.. AKE*...), Nr, KEr(Curve25519), N(ADDITIONAL_KEY_EXCHANGE)(link1) } Proposal #1 Transform ECR (ID = ENCR_AES_GCM_16, 256-bit key) Transform PRF (ID = PRF_HMAC_SHA2_512) Transform KE (ID = Curve25519) Transform AKE1 (ID = PQ_KEM_2) Transform AKE2 (ID = PQ_KEM_5) HDR(IKE_FOLLOWUP_KE), SK{ KEi(1)(PQ_KEM_2), ---> N(ADDITIONAL_KEY_EXCHANGE)(link1) } <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(1)(PQ_KEM_2), N(ADDITIONAL_KEY_EXCHANGE)(link2) } HDR(IKE_FOLLOWUP_KE), SK{ KEi(2)(PQ_KEM_5), ---> N(ADDITIONAL_KEY_EXCHANGE)(link2) } <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(2)(PQ_KEM_5) } Tjhai, et al. Expires 4 June 2023 [Page 30] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 A.4. No Matching Proposal for Additional Key Exchanges The initiator proposes the combination of PQ_KEM_1, PQ_KEM_2, PQ_KEM_3, and PQ_KEM_4 as the additional key exchanges. The initiator indicates that either PQ_KEM_1 or PQ_KEM_2 must be used to establish an IKE SA, but Additional Key Exchange 2 is optional so the responder can either select PQ_KEM_3 or PQ_KEM_4 or omit this key exchange by selecting NONE. The responder, although supports the optional PQ_KEM_3 and PQ_KEM_4 methods, does not support either PQ_KEM_1 or PQ_KEM_2 mandatory method and therefore responds with NO_PROPOSAL_CHOSEN notification. Initiator Responder --------------------------------------------------------------------- HDR(IKE_SA_INIT), SAi1(.. AKE*...), ---> KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED), N(INTERMEDIATE_EXCHANGE_SUPPORTED) Proposal #1 Transform ECR (ID = ENCR_AES_GCM_16, 256-bit key) Transform PRF (ID = PRF_HMAC_SHA2_512) Transform KE (ID = Curve25519) Transform AKE1 (ID = PQ_KEM_1) Transform AKE1 (ID = PQ_KEM_2) Transform AKE2 (ID = PQ_KEM_3) Transform AKE2 (ID = PQ_KEM_4) Transform AKE2 (ID = NONE) <--- HDR(IKE_SA_INIT), N(NO_PROPOSAL_CHOSEN) Appendix B. Design Criteria The design of the extension is driven by the following criteria: 1) Need for PQC in IPsec. Quantum computers, which might become feasible in the near future, pose a threat to our classical public key cryptography. PQC, a family of public key cryptography that is believed to be resistant against these computers, needs to be integrated into the IPsec protocol suite to restore confidentiality and authenticity. 2) Hybrid. There is currently no post-quantum key exchange that is trusted at the level that (EC)DH is trusted for against conventional (non-quantum) adversaries. A hybrid post-quantum algorithm to be introduced along with the well-established primitives addresses this concern, since the overall security is at least as strong as each individual primitive. 3) Focus on post-quantum confidentiality. A passive attacker can Tjhai, et al. Expires 4 June 2023 [Page 31] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 store all monitored encrypted IPsec communication today and decrypt it once a quantum computer is available in the future. This attack can have serious consequences that will not be visible for years to come. On the other hand, an attacker can only perform active attacks such as impersonation of the communicating peers once a quantum computer is available, sometime in the future. Thus, this specification focuses on confidentiality due to the urgency of this problem and presents a defense against the serious attack described above, but it does not address authentication since it is less urgent at this stage. 4) Limit amount of exchanged data. The protocol design should be such that the amount of exchanged data, such as public-keys, is kept as small as possible even if initiator and responder need to agree on a hybrid group or multiple public-keys need to be exchanged. 5) Not post-quantum specific. Any cryptographic algorithm could be potentially broken in the future by currently unknown or impractical attacks: quantum computers are merely the most concrete example of this. The design does not categorize algorithms as "post-quantum" or "non post-quantum" nor does it create assumptions about the properties of the algorithms, meaning that if algorithms with different properties become necessary in the future, this extension can be used unchanged to facilitate migration to those algorithms. 6) Limited amount of changes. A key goal is to limit the number of changes required when enabling a post-quantum handshake. This ensures easier and quicker adoption in existing implementations. 7) Localized changes. Another key requirement is that changes to the protocol are limited in scope, in particular, limiting changes in the exchanged messages and in the state machine, so that they can be easily implemented. 8) Deterministic operation. This requirement means that the hybrid post-quantum exchange, and thus, the computed keys, will be based on algorithms that both client and server wish to support. 9) Fragmentation support. Some PQC algorithms could be relatively bulky and they might require fragmentation. Thus, a design goal is the adaptation and adoption of an existing fragmentation method or the design of a new method that allows for the fragmentation of the key shares. 10) Backwards compatibility and interoperability. This is a Tjhai, et al. Expires 4 June 2023 [Page 32] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 fundamental requirement to ensure that hybrid post-quantum IKEv2 and standard IKEv2 implementations as per [RFC7296] specification are interoperable. 11) USA Federal Information Processing Standards (FIPS) compliance. IPsec is widely used in Federal Information Systems and FIPS certification is an important requirement. However, at the time of writing, none of the algorithms that is believed to be post- quantum is FIPS compliant yet. Nonetheless, it is possible to combine this post-quantum algorithm with a FIPS compliant key establishment method so that the overall design remains FIPS compliant [NISTPQCFAQ]. 12) Ability to use this method with multiple classical (EC)DH key exchanges. In some situations peers have no single mutually trusted key exchange algorithm (e.g., due to local policy restrictions). The ability to combine two (or more) key exchange methods in such a way that the resulting shared key depends on all of them allows peers to communicate in this situation. Appendix C. Alternative Design This section gives an overview on a number of alternative approaches that have been considered, but later discarded. These approaches are: * Sending the classical and post-quantum key exchanges as a single transform A method to combine the various key exchanges into a single large KE payload was considered; this effort is documented in a previous version of this draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This does allow us to cleanly apply hybrid key exchanges during the Child SA; however it does add considerable complexity, and requires an independent fragmentation solution. * Sending post-quantum proposals and policies in KE payload only With the objective of not introducing unnecessary notify payloads, a method to communicate the hybrid post-quantum proposal in the KE payload during the first pass of the protocol exchange was considered. Unfortunately, this design is susceptible to the following downgrade attack. Consider the scenario where there is an on-path attacker sitting between an initiator and a responder. The initiator proposes, through SAi payload, to use a hybrid post- quantum group and as a fallback a Diffie-Hellman group, and through KEi payload, the initiator proposes a list of hybrid post- Tjhai, et al. Expires 4 June 2023 [Page 33] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 quantum proposals and policies. The on-path attacker intercepts this traffic and replies with N(INVALID_KE_PAYLOAD) suggesting to downgrade to the fallback Diffie-Hellman group instead. The initiator then resends the same SAi payload and the KEi payload containing the public value of the fallback Diffie-Hellman group. Note that the attacker may forward the second IKE_SA_INIT message only to the responder, and therefore at this point in time, the responder will not have the information that the initiator prefers the hybrid group. Of course, it is possible for the responder to have a policy to reject an IKE_SA_INIT message that (a) offers a hybrid group but not offering the corresponding public value in the KEi payload; and (b) the responder has not specifically acknowledged that it does not supported the requested hybrid group. However, the checking of this policy introduces unnecessary protocol complexity. Therefore, in order to fully prevent any downgrade attacks, using KE payload alone is not sufficient and that the initiator MUST always indicate its preferred post-quantum proposals and policies in a notify payload in the subsequent IKE_SA_INIT messages following a N(INVALID_KE_PAYLOAD) response. * New payload types to negotiate hybrid proposal and to carry post- quantum public values Semantically, it makes sense to use a new payload type, which mimics the SA payload, to carry a hybrid proposal. Likewise, another new payload type that mimics the KE payload, could be used to transport hybrid public value. Although, in theory a new payload type could be made backwards compatible by not setting its critical flag as per Section 2.5 of [RFC7296], it is believed that it may not be that simple in practice. Since the original release of IKEv2 in RFC4306, no new payload type has ever been proposed and therefore, this creates a potential risk of having a backward compatibility issue from non-conformant IKEv2 implementations. Since there appears to be no other compelling advantages apart from a semantic one, the existing transform type and notify payloads are used instead. * Hybrid public value payload One way to transport the negotiated hybrid public payload, which contains one classical Diffie-Hellman public value and one or more post-quantum public values, is to bundle these into a single KE payload. Alternatively, these could also be transported in a single new hybrid public value payload, but following the same reasoning as above, this may not be a good idea from a backward compatibility perspective. Using a single KE payload would require an encoding or formatting to be defined so that both peers Tjhai, et al. Expires 4 June 2023 [Page 34] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 are able to compose and extract the individual public values. However, it is believed that it is cleaner to send the hybrid public values in multiple KE payloads--one for each group or algorithm. Furthermore, at this point in the protocol exchange, both peers should have indicated support of handling multiple KE payloads. * Fragmentation Handling of large IKE_SA_INIT messages has been one of the most challenging tasks. A number of approaches have been considered and the two prominent ones that have been discarded are outlined as follows. The first approach is to treat the entire IKE_SA_INIT message as a stream of bytes, which is then split it into a number of fragments, each of which is wrapped onto a payload that will fit into the size of the network MTU. The payload that wraps each fragment has a new payload type and it is envisaged that this new payload type will not cause a backward compatibility issue because at this stage of the protocol, both peers should have indicated support of fragmentation in the first pass of the IKE_SA_INIT exchange. The negotiation of fragmentation is performed using a notify payload, which also defines supporting parameters such as the size of fragment in octets and the fragment identifier. The new payload that wraps each fragment of the messages in this exchange is assigned the same fragment identifier. Furthermore, it also has other parameters such as a fragment index and total number of fragments. This approach has been discarded due to its blanket approach to fragmentation. In cases where only a few payloads need to be fragmented, this approach appears to be overly complicated. Another idea that has been discarded was fragmenting an individual payload without introducing a new payload type. The idea is to use the 9-th bit (the bit after the critical flag in the RESERVED field) in the generic payload header as a flag to mark that this payload is fragmented. As an example, if a KE payload is to be fragmented, it may look as follows. Tjhai, et al. Expires 4 June 2023 [Page 35] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C|F| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diffie-Hellman Group Number | Fragment Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Index | Total Fragments | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total KE Payload Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Fragmented KE Payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the flag F is set, this means the current KE payload is a fragment of a larger KE payload. The Payload Length field denotes the size of this payload fragment in octets--including the size of the generic payload header. The two-octet RESERVED field following Diffie-Hellman Group Number was to be used as a fragment identifier to help assembly and disassembly of fragments. The Fragment Index and Total Fragments fields are self-explanatory. The Total KE Payload Data Length indicates the size of the assembled KE payload data in octets. Finally, the actual fragment is carried in Fragment KE Payload field. This approach has been discarded because it is believed that the working group may not want to use the RESERVED field to change the format of a packet and that implementers may not like the added complexity from checking the fragmentation flag in each received payload. More importantly, fragmenting the messages in this way may leave the system to be more prone to denial of service (DoS) attacks. By using IKE_INTERMEDIATE to transport the large post- quantum key exchange payloads, and using the generic IKEv2 fragmentation protocol [RFC7383] solve the issue. * Group sub-identifier Tjhai, et al. Expires 4 June 2023 [Page 36] Internet-Draft Multiple Key Exchanges in IKEv2 December 2022 As discussed before, each group identifier is used to distinguish a post-quantum algorithm. Further classification could be made on a particular post-quantum algorithm by assigning additional value alongside the group identifier. This sub- identifier value may be used to assign different security parameter sets to a given post- quantum algorithm. However, this level of details does not fit the principles of the document where it should deal with generic hybrid key exchange protocol, not a specific ciphersuite. Furthermore, there are enough Diffie- Hellman group identifiers should this be required in the future. Authors' Addresses C. Tjhai Post-Quantum Email: cjt@post-quantum.com M. Tomlinson Post-Quantum Email: mt@post-quantum.com G. Bartlett Quantum Secret Email: graham.ietf@gmail.com S. Fluhrer Cisco Systems Email: sfluhrer@cisco.com D. Van Geest ISARA Corporation Email: daniel.vangeest@isara.com O. Garcia-Morchon Philips Email: oscar.garcia-morchon@philips.com Valery Smyslov ELVIS-PLUS Email: svan@elvis.ru Tjhai, et al. Expires 4 June 2023 [Page 37] ./draft-ietf-bess-evpn-bum-procedure-updates-14.txt0000644000764400076440000013733014145451220021772 0ustar iustiniustin BESS Z. Zhang Internet-Draft W. Lin Updates: 7432 (if approved) Juniper Networks Intended status: Standards Track J. Rabadan Expires: May 22, 2022 Nokia K. Patel Arrcus A. Sajassi Cisco Systems November 18, 2021 Updates on EVPN BUM Procedures draft-ietf-bess-evpn-bum-procedure-updates-14 Abstract This document specifies updated procedures for handling broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation. This document updates RFC 7432. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 22, 2022. Zhang, et al. Expires May 22, 2022 [Page 1] Internet-Draft evpn-bum-procedure-update November 2021 Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, 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 of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Tunnel Segmentation . . . . . . . . . . . . . . . . . . . 4 2.1.1. Reasons for Tunnel Segmentation . . . . . . . . . . . 5 3. Additional Route Types of EVPN NLRI . . . . . . . . . . . . . 6 3.1. Per-Region I-PMSI A-D route . . . . . . . . . . . . . . . 7 3.2. S-PMSI A-D route . . . . . . . . . . . . . . . . . . . . 7 3.3. Leaf A-D route . . . . . . . . . . . . . . . . . . . . . 8 4. Selective Multicast . . . . . . . . . . . . . . . . . . . . . 8 5. Inter-AS Segmentation . . . . . . . . . . . . . . . . . . . . 9 5.1. Differences from Section 7.2.2 of [RFC7117] When Applied to EVPN . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. I-PMSI Leaf Tracking . . . . . . . . . . . . . . . . . . 11 5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 11 5.3.1. Designated ASBR Election . . . . . . . . . . . . . . 13 6. Inter-Region Segmentation . . . . . . . . . . . . . . . . . . 13 6.1. Area/AS vs. Region . . . . . . . . . . . . . . . . . . . 13 6.2. Per-region Aggregation . . . . . . . . . . . . . . . . . 14 6.3. Use of S-NH-EC . . . . . . . . . . . . . . . . . . . . . 15 6.4. Ingress PE's I-PMSI Leaf Tracking . . . . . . . . . . . . 16 7. Multi-homing Support . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Zhang, et al. Expires May 22, 2022 [Page 2] Internet-Draft evpn-bum-procedure-update November 2021 1. Terminology It is expected that audience is familiar with MVPN [RFC6513] [RFC6514], VPLS Multicast [RFC7117] and EVPN [RFC7432] concepts and terminologies. For convenience, the following terms are briefly explained. o PMSI [RFC6513]: P-Multicast Service Interface - a conceptual interface for a PE to send customer multicast traffic to all or some PEs in the same VPN. o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. o I/S-PMSI A-D Route: Auto-Discovery routes used to announce the tunnels that instantiate an I/S-PMSI. o Leaf Auto-Discovery (A-D) routes [RFC6513]: For explicit leaf tracking purpose. Triggered by I/S-PMSI A-D routes and targeted at triggering route's (re-)advertiser. Its NLRI embeds the entire NLRI of the triggering PMSI A-D route. o IMET A-D route [RFC7432]: Inclusive Multicast Ethernet Tag A-D route. The EVPN equivalent of MVPN Intra-AS I-PMSI A-D route used to announce the tunnels that instantiate an I-PMSI. o SMET A-D route [I-D.ietf-bess-evpn-igmp-mld-proxy]: Selective Multicast Ethernet Tag A-D route. The EVPN equivalent of MVPN Leaf A-D route but unsolicited and untargeted. o PMSI Tunnel Attribute (PTA): An optional transitive BGP attribute that may be attached to PMSI/Leaf A-D routes to provide information for a PMSI tunnel. 2. Introduction [RFC7117] specifies procedures for Multicast in Virtual Private LAN Service (VPLS Multicast) using both inclusive tunnels and selective tunnels with or without inter-as segmentation, similar to the Multicast VPN (MVPN) procedures specified in [RFC6513] and [RFC6514]. [RFC7524] specifies inter-area tunnel segmentation procedures for both VPLS Multicast and MVPN. [RFC7432] specifies BGP MPLS-Based Ethernet VPN (EVPN) procedures, including those handling broadcast, unknown unicast, and multicast (BUM) traffic. A lot of details are referred to [RFC7117], yet with Zhang, et al. Expires May 22, 2022 [Page 3] Internet-Draft evpn-bum-procedure-update November 2021 quite some feature gaps like selective tunnel and tunnel segmentation (Section 2.1). This document aims at filling the gaps - cover the use of selective and segmented tunnels in EVPN. It follows the same editorial choice as in RFC7432 and only specifies differences from relevant procedures in [RFC7117] and [RFC7524], instead of repeating the text. Note that these differences are applicable to EVPN only, and are not updates to [RFC7117] or [RFC7524]. MVPN, VPLS and EVPN all have the need to discover other PEs in the same L3/L2 VPN and announce the inclusive tunnels. MVPN introduced the I-PMSI concept and uses I-PMSI A-D route for that. EVPN uses Inclusive Multicast Ethernet Tag Route (IMET) A-D route but VPLS just adds an PMSI Tunnel Attribute (PTA) to the existing VPLS A-D route for that purpose. For selective tunnels, they all do use the same term S-PMSI A-D routes. Many places of this document involve the I-PMSI concept that is all the same for all three technologies. For consistency and convenience, EVPN's IMET and VPLS's VPLS A-D route carrying PTA for BUM traffic purpose may all be referred to as I-PMSI A-D routes depending on the context. 2.1. Tunnel Segmentation MVPN provider tunnels and EVPN/VPLS BUM provider tunnels, which are referred to as MVPN/EVPN/VPLS provider tunnels in this document for simplicity, can be segmented for technical or administrative reasons, which are summarized in Section 2.1.1 of this document. [RFC6513] and [RFC6514] cover MVPN inter-as segmentation, [RFC7117] covers VPLS multicast inter-as segmentation, and [RFC7524] (Seamless MPLS Multicast) covers inter-area segmentation for both MVPN and VPLS. With tunnel segmentation, different segments of an end-to-end tunnel may have different encapsulation overhead. However, the largest overhead of the tunnel caused by an encapsulation method on a particular segment is not different from the case of a non-segmented tunnel with that encapsulation method. This is similar to the case of a network with different link types. There is a difference between MVPN and VPLS multicast inter-as segmentation (the VPLS approach is briefly discribed in Section 5.1). For simplicity, EVPN will use the same procedures as in MVPN. All ASBRs can re-advertise their choice of the best route. Each can become the root of its intra-AS segment and inject traffic it receives from its upstream, while each downstream PE/ASBR will only Zhang, et al. Expires May 22, 2022 [Page 4] Internet-Draft evpn-bum-procedure-update November 2021 pick one of the upstream ASBRs as its upstream. This is also the behavior even for VPLS in case of inter-area segmentation. For inter-area segmentation, [RFC7524] requires the use of Inter-area P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting of "Leaf Information Required" L flag in PTA in certain situations. In the EVPN case, the requirements around S-NH-EC and the PTA "L" flag differ from [RFC7524] to make the segmentation procedures transparent to ingress and egress PEs. [RFC7524] assumes that segmentation happens at area borders. However, it could be at "regional" borders, where a region could be a sub-area, or even an entire AS plus its external links (Section 6.1). That would allow for more flexible deployment scenarios (e.g. for single-area provider networks). This document extends the inter-area segmentation to inter-region segmentation for EVPN. 2.1.1. Reasons for Tunnel Segmentation Tunnel segmentation may be required and/or desired because of administrative and/or technical reasons. For example, an MVPN/VPLS/EVPN network may span multiple providers and the end-to-end provider tunnels have to be segmented at and stitched by the ASBRs. Different providers may use different tunnel technologies (e.g., provider A uses Ingress Replication [RFC7988], provider B uses RSVP-TE P2MP [RFC4875] while provider C uses mLDP [RFC6388]). Even if they use the same tunnel technology like RSVP-TE P2MP, it may be impractical to set up the tunnels across provider boundaries. The same situations may apply between the ASes and/or areas of a single provider. For example, the backbone area may use RSVP-TE P2MP tunnels while non-backbone areas may use mLDP tunnels. Segmentation can also be used to divide an AS/area into smaller regions, so that control plane state and/or forwarding plane state/ burden can be limited to that of individual regions. For example, instead of Ingress Replicating to 100 PEs in the entire AS, with inter-area segmentation [RFC7524] a PE only needs to replicate to local PEs and ABRs. The ABRs will further replicate to their downstream PEs and ABRs. This not only reduces the forwarding plane burden, but also reduces the leaf tracking burden in the control plane. Smaller regions also have the benefit that, in case of tunnel aggregation, it is easier to find congruence among the segments of different constituent (service) tunnels and the resulting aggregation Zhang, et al. Expires May 22, 2022 [Page 5] Internet-Draft evpn-bum-procedure-update November 2021 (base) tunnel in a region. This leads to better bandwidth efficiency, because the more congruent they are, the fewer leaves of the base tunnel need to discard traffic when a service tunnel's segment does not need to receive the traffic (yet it is receiving the traffic due to aggregation). Another advantage of the smaller region is smaller BIER [RFC8279] sub-domains. With BIER, packets carry a BitString, in which the bits correspond to edge routers that needs to receive traffic. Smaller sub-domains means smaller BitStrings can be used without having to send multiple copies of the same packet. 3. Additional Route Types of EVPN NLRI [RFC7432] defines the format of EVPN NLRI as the following: +-----------------------------------+ | Route Type (1 octet) | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | Route Type specific (variable) | +-----------------------------------+ So far eight route types have been defined in [RFC7432], [I-D.ietf-bess-evpn-prefix-advertisement], and [I-D.ietf-bess-evpn-igmp-mld-proxy]: + 1 - Ethernet Auto-Discovery (A-D) route + 2 - MAC/IP Advertisement route + 3 - Inclusive Multicast Ethernet Tag route + 4 - Ethernet Segment route + 5 - IP Prefix Route + 6 - Selective Multicast Ethernet Tag Route + 7 - Multicast Join Synch Route + 8 - Multicast Leave Synch Route This document defines three additional route types: + 9 - Per-Region I-PMSI A-D route + 10 - S-PMSI A-D route + 11 - Leaf A-D route The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs starts with a type 1 RD, whose Administrator sub-field MUST match that of the RD in all current non-Leaf A-D (Section 3.3) EVPN routes from the same advertising router for a given EVI. Zhang, et al. Expires May 22, 2022 [Page 6] Internet-Draft evpn-bum-procedure-update November 2021 3.1. Per-Region I-PMSI A-D route The Per-region I-PMSI A-D route has the following format. Its usage is discussed in Section 6.2. +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Ethernet Tag ID (4 octets) | +-----------------------------------+ | Region ID (8 octets) | +-----------------------------------+ The Region ID identifies the region and is encoded just as how an Extended Community is encoded, as detailed in Section 6.2. 3.2. S-PMSI A-D route The S-PMSI A-D route has the following format: +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Ethernet Tag ID (4 octets) | +-----------------------------------+ | Multicast Source Length (1 octet) | +-----------------------------------+ | Multicast Source (Variable) | +-----------------------------------+ | Multicast Group Length (1 octet) | +-----------------------------------+ | Multicast Group (Variable) | +-----------------------------------+ |Originator's Addr Length (1 octet) | +-----------------------------------+ |Originator's Addr (4 or 16 octets) | +-----------------------------------+ Other than the addition of Ethernet Tag ID and Originator's Addr Length, it is identical to the S-PMSI A-D route as defined in [RFC7117]. The procedures in [RFC7117] also apply (including wildcard functionality), except that the granularity level is per Ethernet Tag. Zhang, et al. Expires May 22, 2022 [Page 7] Internet-Draft evpn-bum-procedure-update November 2021 3.3. Leaf A-D route The Route Type specific field of a Leaf A-D route consists of the following: +-----------------------------------+ | Route Key (variable) | +-----------------------------------+ |Originator's Addr Length (1 octet) | +-----------------------------------+ |Originator's Addr (4 or 16 octets) | +-----------------------------------+ A Leaf A-D route is originated in response to a PMSI route, which could be an Inclusive Multicast Tag route, a per-region I-PMSI A-D route, an S-PMSI A-D route, or some other types of routes that may be defined in the future that triggers Leaf A-D routes. The Route Key is the NLRI of the route for which this Leaf A-D route is generated. The general procedures of Leaf A-D route are first specified in [RFC6514] for MVPN. The principles apply to VPLS and EVPN as well. [RFC7117] has details for VPLS Multicast, and this document points out some specifics for EVPN, e.g. in Section 5. 4. Selective Multicast [I-D.ietf-bess-evpn-igmp-mld-proxy] specifies procedures for EVPN selective forwarding of IP multicast using SMET routes. It assumes selective forwarding is always used with IR for all flows (though the same signaling can also be used for an ingress PE to find out the set of egress PEs for selective forwarding with BIER). An NVE proxies the IGMP/MLD state that it learns on its ACs to (C-S,C-G) or (C-*,C-G) SMET routes that advertises to other NVEs, and a receiving NVE converts the SMET routes back to IGMP/MLD messages and sends them out of its ACs. The receiving NVE also uses the SMET routes to identify which NVEs need to receive traffic for a particular (C-S,C-G) or (C-*,C-G) to achieve selective forwarding using IR or BIER. With the above procedures, selective forwarding is done for all flows and the SMET routes are advertised for all flows. It is possible that an operator may not want to track all those (C-S, C-G) or (C-*,C-G) state on the NVEs, and the multicast traffic pattern allows inclusive forwarding for most flows while selective forwarding is needed only for a few high-rate flows. For that, or for tunnel types other than IR/BIER, S-PMSI/Leaf A-D procedures defined for Selective Multicast for VPLS in [RFC7117] are used. Other than that different route types and formats are specified with EVPN SAFI for S-PMSI A-D Zhang, et al. Expires May 22, 2022 [Page 8] Internet-Draft evpn-bum-procedure-update November 2021 and Leaf A-D routes (Section 3), all procedures in [RFC7117] with respect to Selective Multicast apply to EVPN as well, including wildcard procedures. In a nutshell, a source NVE advertises S-PMSI A-D routes to announce the tunnels used for certain flows, and receiving NVEs either join the announced PIM/mLDP tunnel or respond with Leaf A-D routes if the Leaf Information Required flag is set in the S-PMSI A-D route's PTA (so that the source NVE can include them as tunnel leaves). An optimization to the [RFC7117] procedures may be applied. Even if a source NVE sets the L flag to request Leaf A-D routes, an egress NVE MAY omit the Leaf A-D route if it has already advertised a corresponding SMET route, and the source NVE MUST use that in lieu of the Leaf A-D route. The optional optimizations specified for MVPN in [RFC8534] are also applicable to EVPN when the S-PMSI/Leaf A-D routes procedures are used for EVPN selective multicast forwarding. 5. Inter-AS Segmentation 5.1. Differences from Section 7.2.2 of [RFC7117] When Applied to EVPN The first paragraph of Section 7.2.2.2 of [RFC7117] says: "... The best route procedures ensure that if multiple ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP neighbors, only one of these ASBRs propagates this route in Internal BGP (IBGP). This ASBR becomes the root of the intra-AS segment of the inter-AS tree and ensures that this is the only ASBR that accepts traffic into this AS from the inter-AS tree." The above VPLS behavior requires complicated VPLS specific procedures for the ASBRs to reach agreement. For EVPN, a different approach is used and the above quoted text is not applicable to EVPN. With the different approach for EVPN/MVPN, each ASBR will re- advertise its received Inter-AS A-D route to its IBGP peers and becomes the root of an intra-AS segment of the inter-AS tree. The intra-AS segment rooted at one ASBR is disjoint with another intra-AS segment rooted at another ASBR. This is the same as the procedures for S-PMSI in [RFC7117] itself. The following bullet in Section 7.2.2.2 of [RFC7117] does not apply to EVPN. Zhang, et al. Expires May 22, 2022 [Page 9] Internet-Draft evpn-bum-procedure-update November 2021 + If the ASBR uses ingress replication to instantiate the intra-AS segment of the inter-AS tunnel, the re-advertised route MUST NOT carry the PMSI Tunnel attribute. The following bullet in Section 7.2.2.2 of [RFC7117]: + If the ASBR uses a P-multicast tree to instantiate the intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST contain the identity of the tree that is used to instantiate the segment (note that the ASBR could create the identity of the tree prior to the actual instantiation of the segment). If, in order to instantiate the segment, the ASBR needs to know the leaves of the tree, then the ASBR obtains this information from the A-D routes received from other PEs/ASBRs in the ASBR's own AS. is changed to the following when applied to EVPN: "The PMSI Tunnel attribute MUST specify the tunnel for the segment. If and only if, in order to establish the tunnel, the ASBR needs to know the leaves of the tree, then the ASBR MUST set the L flag to 1 in the PTA to trigger Leaf A-D routes from egress PEs and downstream ASBRs. It MUST be (auto-)configured with an import RT, which controls acceptance of leaf A-D routes by the ASBR." Accordingly, the following paragraph in Section 7.2.2.4 of [RFC7117]: "If the received Inter-AS A-D route carries the PMSI Tunnel attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR that originated the route MUST establish an RSVP-TE P2MP LSP with the local PE/ASBR as a leaf. This LSP MAY have been established before the local PE/ASBR receives the route, or it MAY be established after the local PE receives the route." is changed to the following when applied to EVPN: "If the received Inter-AS A-D route has the L flag set in its PTA, then a receiving PE MUST originate a corresponding Leaf A-D route, while a receiving ASBR MUST originate a corresponding Leaf A-D route if and only if it received and imported one or more corresponding Leaf A-D routes from its downstream IBGP or EBGP peers, or it has non-null downstream forwarding state for the PIM/mLDP tunnel that instantiates its downstream intra-AS segment. The targeted ASBR for the Leaf A-D route, which (re-)advertised the Inter-AS A-D route, MUST establish a tunnel to the leaves discovered by the Leaf A-D routes." Zhang, et al. Expires May 22, 2022 [Page 10] Internet-Draft evpn-bum-procedure-update November 2021 5.2. I-PMSI Leaf Tracking An ingress PE does not set the L flag in its Inclusive Multicast Ethernet Tag (IMET) A-D route's PTA, even with Ingress Replication or RSVP-TE P2MP tunnels. It does not rely on the Leaf A-D routes to discover leaves in its AS, and Section 11.2 of [RFC7432] explicitly states that the L flag must be set to zero. An implementation of [RFC7432] might have used the Originating Router's IP Address field of the IMET A-D routes to determine the leaves, or might have used the Next Hop field instead. Within the same AS, both will lead to the same result. With segmentation, an ingress PE MUST determine the leaves in its AS from the BGP next hops in all its received IMET A-D routes, so it does not have to set the L flag set to request Leaf A-D routes. PEs within the same AS will all have different next hops in their IMET A-D routes (hence will all be considered as leaves), and PEs from other ASes will have the next hop in their IMET A-D routes set to addresses of ASBRs in this local AS, hence only those ASBRs will be considered as leaves (as proxies for those PEs in other ASes). Note that in case of Ingress Replication, when an ASBR re-advertises IMET A-D routes to IBGP peers, it MUST advertise the same label for all those for the same Ethernet Tag ID and the same EVI. Otherwise, duplicated copies will be sent by the ingress PE and received by egress PEs in other regions. For the same reason, when an ingress PE builds its flooding list, if multiple routes have the same (nexthop, label) tuple they MUST only be added as a single branch in the flooding list. 5.3. Backward Compatibility The above procedures assume that all PEs are upgraded to support the segmentation procedures: o An ingress PE uses the Next Hop and not Originating Router's IP Address to determine leaves for the I-PMSI tunnel. o An egress PE sends Leaf A-D routes in response to I-PMSI routes, if the PTA has the L flag set by the re-advertising ASBR. o In case of Ingress Replication, when an ingress PE builds its flooding list, multiple I-PMSI routes may have the same (nexthop, label) tuple and only a single branch for those will be added in the flooding list. If a deployment has legacy PEs that does not support the above, then a legacy ingress PE would include all PEs (including those in remote Zhang, et al. Expires May 22, 2022 [Page 11] Internet-Draft evpn-bum-procedure-update November 2021 ASes) as leaves of the inclusive tunnel and try to send traffic to them directly (no segmentation), which is either undesired or not possible; a legacy egress PE would not send Leaf A-D routes so the ASBRs would not know to send external traffic to them. If this backward compatibility problem needs to be addressed, the following procedure MUST be used (see Section 6.2 for per-PE/AS/ region I-PMSI A-D routes): o An upgraded PE indicates in its per-PE I-PMSI A-D route that it supports the new procedures. This is done by setting a flag bit in the EVPN Multicast Flags Extended Community. o All per-PE I-PMSI A-D routes are restricted to the local AS and not propagated to external peers. o The ASBRs in an AS originate per-region I-PMSI A-D routes and advertise them to their external peers to specify tunnels used to carry traffic from the local AS to other ASes. Depending on the types of tunnels being used, the L flag in the PTA may be set, in which case the downstream ASBRs and upgraded PEs will send Leaf A-D routes to pull traffic from their upstream ASBRs. In a particular downstream AS, one of the ASBRs is elected, based on the per-region I-PMSI A-D routes for a particular source AS, to send traffic from that source AS to legacy PEs in the downstream AS. The traffic arrives at the elected ASBR on the tunnel announced in the best per-region I-PMSI A-D route for the source AS, that the ASBR has selected of all those that it received over EBGP or IBGP sessions. The election procedure is described in Section 5.3.1. o In an ingress/upstream AS, if and only if an ASBR has active downstream receivers (PEs and ASBRs), which are learned either explicitly via Leaf A-D routes or implicitly via PIM join or mLDP label mapping, the ASBR originates a per-PE I-PMSI A-D route (i.e., regular Inclusive Multicast Ethernet Tag route) into the local AS, and stitches incoming per-PE I-PMSI tunnels into its per-region I-PMSI tunnel. With this, it gets traffic from local PEs and send to other ASes via the tunnel announced in its per- region I-PMSI A-D route. Note that, even if there is no backward compatibility issue, the use of per-region I-PMSI has the benefit of keeping all per-PE I-PMSI A-D routes in their local ASes, greatly reducing the flooding of the routes and their corresponding Leaf A-D routes (when needed), and the number of inter-as tunnels. Zhang, et al. Expires May 22, 2022 [Page 12] Internet-Draft evpn-bum-procedure-update November 2021 5.3.1. Designated ASBR Election When an ASBR re-advertises a per-region I-PMSI A-D route into an AS in which a designated ASBR needs to be used to forward traffic to the legacy PEs in the AS, it MUST include a DF Election EC. The EC and its use is specified in [RFC8584]. The AC-DF bit in the DF Election EC MUST be cleared. If it is known that no legacy PEs exist in the AS, the ASBR MUST NOT include the EC and MUST remove the DF Election EC if one is carried in the per-region I-PMSI A-D routes that it receives. Note that this is done for each set of per-region I-PMSI A-D routes with the same NLRI. Based on the procedures in [RFC8584], an election algorithm is determined according to the DF Election ECs carried in the set of per-region I-PMSI routes of the same NLRI re-adverised into the AS. The algorithm is then applied to a candidate list, which is the set of ASBRs that re-advertised the per-region I-PMSI routes of the same NLRI carrying the DF Election EC. 6. Inter-Region Segmentation 6.1. Area/AS vs. Region [RFC7524] is for MVPN/VPLS inter-area segmentation and does not explicitly cover EVPN. However, if "area" is replaced by "region" and "ABR" is replaced by "RBR" (Regional Border Router) then everything still works, and can be applied to EVPN as well. A region can be a sub-area, or can be an entire AS including its external links. Instead of automatic region definition based on IGP areas, a region would be defined as a BGP peer group. In fact, even with IGP area based region definition, a BGP peer group listing the PEs and ABRs in an area is still needed. Consider the following example diagram for inter-as segmentation: --------- ------ --------- / \ / \ / \ / \ / \ / \ | PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 | \ / \ / \ / \ / \ / \ / --------- ------ --------- AS 100 AS 200 AS 300 |-----------|--------|---------|--------|------------| segment1 segment2 segment3 segment4 segment5 Zhang, et al. Expires May 22, 2022 [Page 13] Internet-Draft evpn-bum-procedure-update November 2021 The inter-as segmentation procedures specified so far ([RFC6513] [RFC6514], [RFC7117], and Section 5 of this document) require all ASBRs to be involved, and Ingress Replication is used between two ASBRs in different ASes. In the above diagram, it's possible that ASBR1/4 does not support segmentation, and the provider tunnels in AS 100/300 can actually extend across the external link. In this case, the inter-region segmentation procedures can be used instead - a region is the entire (AS100 + ASBR1-ASBR2 link) or (AS300 + ASBR3-ASBR4 link). ASBR2/3 would be the RBRs, and ASBR1/4 will just be a transit core router with respect to provider tunnels. As illustrated in the diagram below, ASBR2/3 will establish a multihop EBGP session with either a RR or directly with PEs in the neighboring AS. I/S-PMSI A-D routes from ingress PEs will not be processed by ASBR1/4. When ASBR2 re-advertises the routes into AS 200, it changes the next hop to its own address and changes PTA to specify the tunnel type/identification in its own AS. When ASBR3 re- advertises I/S-PMSI A-D routes into the neighboring AS 300, it changes the next hop to its own address and changes PTA to specify the tunnel type/identification in the neighboring region. Now the segment is rooted at ASBR3 and extends across the external link to PEs. --------- ------ --------- / RR....\.mh-ebpg / \ mh-ebgp/....RR \ / : \ `. / \ .' / : \ | PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 | \ / \ / \ / \ / \ / \ / --------- ------ --------- AS 100 AS 200 AS 300 |-------------------|----------|---------------------| segment 1 segment 2 segment 3 6.2. Per-region Aggregation Notice that every I/S-PMSI route from each PE will be propagated throughout all the ASes or regions. They may also trigger corresponding Leaf A-D routes depending on the types of tunnels used in each region. This may become too many - routes and corresponding tunnels. To address this concern, the I-PMSI routes from all PEs in a AS/region can be aggregated into a single I-PMSI route originated from the RBRs, and traffic from all those individual I-PMSI tunnels will be switched into the single I-PMSI tunnel. This is like the MVPN Inter-AS I-PMSI route originated by ASBRs. Zhang, et al. Expires May 22, 2022 [Page 14] Internet-Draft evpn-bum-procedure-update November 2021 The MVPN Inter-AS I-PMSI A-D route can be better called as per-AS I-PMSI A-D route, to be compared against the (per-PE) Intra-AS I-PMSI A-D routes originated by each PE. In this document we will call it as per-region I-PMSI A-D route, in case we want to apply the aggregation at regional level. The per-PE I-PMSI routes will not be propagated to other regions. If multiple RBRs are connected to a region, then each will advertise such a route, with the same Region ID and Ethernet Tag ID (Section 3.1). Similar to the per-PE I-PMSI A-D routes, RBRs/PEs in a downstream region will each select a best one from all those re-advertised by the upstream RBRs, hence will only receive traffic injected by one of them. MVPN does not aggregate S-PMSI routes from all PEs in an AS like it does for I-PMSIs routes, because the number of PEs that will advertise S-PMSI routes for the same (s,g) or (*,g) is small. This is also the case for EVPN, i.e., there is no per-region S-PMSI routes. Notice that per-region I-PMSI routes can also be used to address backwards compatibility issue, as discussed in Section 5.3. The Region ID in the per-region I-PMSI route's NLRI is encoded like an EC. For example, the Region ID can encode an AS number or area ID in the following EC format: o For a two-octet AS number, a Transitive Two-Octet AS-Specific EC of sub-type 0x09 (Source AS), with the Global Administrator sub- field set to the AS number and the Local Administrator sub-field set to 0. o For a four-octet AS number, a Transitive Four-Octet AS-Specific EC of sub-type 0x09 (Source AS), with the Global Administrator sub- field set to the AS number and the Local Administrator sub-field set to 0. o For an area ID, a Transitive IPv4-Address-Specific EC of any sub- type, with the Global Administrator sub-field set to the area ID and the Local Administrator sub-field set to 0. Uses of other EC encoding MAY be allowed as long as it uniquely identifies the region and the RBRs for the same region uses the same Region ID. 6.3. Use of S-NH-EC [RFC7524] specifies the use of S-NH-EC because it does not allow ABRs to change the BGP next hop when they re-advertise I/S-PMSI A-D routes to downstream areas. That is only to be consistent with the MVPN Zhang, et al. Expires May 22, 2022 [Page 15] Internet-Draft evpn-bum-procedure-update November 2021 Inter-AS I-PMSI A-D routes, whose next hop must not be changed when they're re-advertised by the segmenting ABRs for reasons specific to MVPN. For EVPN, it is perfectly fine to change the next hop when RBRs re-advertise the I/S-PMSI A-D routes, instead of relying on S- NH-EC. As a result, this document specifies that RBRs change the BGP next hop when they re-advertise I/S-PMSI A-D routes and do not use S- NH-EC. The advantage of this is that neither ingress nor egress PEs need to understand/use S-NH-EC, and a consistent procedure (based on BGP next hop) is used for both inter-as and inter-region segmentation. If a downstream PE/RBR needs to originate Leaf A-D routes, it constructs an IP-based Route Target Extended Community by placing the IP address carried in the Next Hop of the received I/S-PMSI A-D route in the Global Administrator field of the Community, with the Local Administrator field of this Community set to 0 and setting the Extended Communities attribute of the Leaf A-D route to that Community. Similar to [RFC7524], the upstream RBR MUST (auto-)configure a RT with the Global Administrator field set to the Next Hop in the re- advertised I/S-PMSI A-D route and with the Local Administrator field set to 0. With this, the mechanisms specified in [RFC4684] for constrained BGP route distribution can be used along with this specification to ensure that only the needed PE/ABR will have to process a said Leaf A-D route. 6.4. Ingress PE's I-PMSI Leaf Tracking [RFC7524] specifies that when an ingress PE/ASBR (re-)advertises an VPLS I-PMSI A-D route, it sets the L flag to 1 in the route's PTA. Similar to the inter-as case, this is actually not really needed for EVPN. To be consistent with the inter-as case, the ingress PE does not set the L flag in its originated I-PMSI A-D routes, and determines the leaves based on the BGP next hops in its received I-PMSI A-D routes, as specified in Section 5.2. The same backward compatibility issue exists, and the same solution as in the inter-as case applies, as specified in Section 5.3. 7. Multi-homing Support To support multi-homing with segmentation, ESI labels SHOULD be allocated from "Domain-wide Common Block" (DCB) [I-D.ietf-bess-mvpn-evpn-aggregation-label] for all tunnel types including Ingress Replication. Via means outside the scope of this document, PEs know that ESI labels are from DCB and then existing Zhang, et al. Expires May 22, 2022 [Page 16] Internet-Draft evpn-bum-procedure-update November 2021 multi-homing procedures work as is (whether a multi-homed Ethernet Segment spans across segmentation regions or not). Not using DCB-allocated ESI labels is outside the scope of this document. 8. IANA Considerations IANA has temporarily assigned the following new EVPN route types in the EVPN Route Types registry: o 9 - Per-Region I-PMSI A-D route o 10 - S-PMSI A-D route o 11 - Leaf A-D route This document requests IANA to assign one flag bit from the EVPN Multicast Flags Extended Community Flags registry to be created in [draft-ietf-bess-evpn-igmp-mld-proxy]: o Bit-S - Segmentation Procedure Support 9. Security Considerations The Selective Forwarding procedures via S-PMSI/Leaf A-D routes in this document are based on the same procedures for MVPN [RFC6513] [RFC6514] and VPLS Multicast [RFC7117]. The tunnel segmentation procedures in this document are based on the similar procedures for MVPN inter-AS [RFC6514] and inter-area [RFC7524] tunnel segmentation, and procedures for VPLS Multicast [RFC7117] inter-as tunnel segmentation. When applied to EVPN, they do not introduce new security concerns besides what have been discussed in [RFC6513], [RFC6514], [RFC7117], and [RFC7524]. They also do not introduce new security concerns compared to [RFC7432]. 10. Acknowledgements The authors thank Eric Rosen, John Drake, and Ron Bonica for their comments and suggestions. 11. Contributors The following also contributed to this document through their earlier work in EVPN selective multicast. Zhang, et al. Expires May 22, 2022 [Page 17] Internet-Draft evpn-bum-procedure-update November 2021 Junlin Zhang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: jackey.zhang@huawei.com Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com 12. References 12.1. Normative References [I-D.ietf-bess-evpn-igmp-mld-proxy] Sajassi, A., Thoria, S., Mishra, M., Drake, J., and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn- igmp-mld-proxy-14 (work in progress), October 2021. [I-D.ietf-bess-mvpn-evpn-aggregation-label] Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- ietf-bess-mvpn-evpn-aggregation-label-06 (work in progress), April 2021. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, . [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, . Zhang, et al. Expires May 22, 2022 [Page 18] Internet-Draft evpn-bum-procedure-update November 2021 [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8534] Dolganow, A., Kotalwar, J., Rosen, E., Ed., and Z. Zhang, "Explicit Tracking with Wildcard Routes in Multicast VPN", RFC 8534, DOI 10.17487/RFC8534, February 2019, . [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet VPN Designated Forwarder Election Extensibility", RFC 8584, DOI 10.17487/RFC8584, April 2019, . 12.2. Informative References [I-D.ietf-bess-evpn-prefix-advertisement] Rabadan, J., Henderickx, W., Drake, J. E., Lin, W., and A. Sajassi, "IP Prefix Advertisement in Ethernet VPN (EVPN)", draft-ietf-bess-evpn-prefix-advertisement-11 (work in progress), May 2018. [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, November 2006, . Zhang, et al. Expires May 22, 2022 [Page 19] Internet-Draft evpn-bum-procedure-update November 2021 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, . [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point- to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, . [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress Replication Tunnels in Multicast VPN", RFC 7988, DOI 10.17487/RFC7988, October 2016, . [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, . Authors' Addresses Zhaohui Zhang Juniper Networks EMail: zzhang@juniper.net Wen Lin Juniper Networks EMail: wlin@juniper.net Jorge Rabadan Nokia EMail: jorge.rabadan@nokia.com Keyur Patel Arrcus EMail: keyur@arrcus.com Zhang, et al. Expires May 22, 2022 [Page 20] Internet-Draft evpn-bum-procedure-update November 2021 Ali Sajassi Cisco Systems EMail: sajassi@cisco.com Zhang, et al. Expires May 22, 2022 [Page 21] ./draft-ietf-lamps-cmp-algorithms-15.txt0000644000764400076440000021764514246101571017732 0ustar iustiniustin LAMPS Working Group H. Brockhaus, Ed. Internet-Draft H. Aschauer Updates: 4210 (if approved) Siemens Intended status: Standards Track M. Ounsworth Expires: 4 December 2022 J. Gray Entrust 2 June 2022 Certificate Management Protocol (CMP) Algorithms draft-ietf-lamps-cmp-algorithms-15 Abstract This document describes the conventions for using several cryptographic algorithms with the Certificate Management Protocol (CMP). CMP is used to enroll and further manage the lifecycle of X.509 certificates. This document also updates the algorithm use profile from RFC 4210 Appendix D.2. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 December 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Brockhaus, et al. Expires 4 December 2022 [Page 1] Internet-Draft CMP Algorithms June 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3 2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 3.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Key Management Algorithms . . . . . . . . . . . . . . . . . . 8 4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 8 4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 8 4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 10 4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Symmetric Key-Encryption Algorithms . . . . . . . . . . . 11 4.3.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 11 4.4. Key Derivation Algorithms . . . . . . . . . . . . . . . . 12 4.4.1. PBKDF2 . . . . . . . . . . . . . . . . . . . . . . . 12 5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 13 5.1. AES-CBC . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Message Authentication Code Algorithms . . . . . . . . . . . 14 6.1. Password-Based MAC . . . . . . . . . . . . . . . . . . . 14 6.1.1. PasswordBasedMac . . . . . . . . . . . . . . . . . . 14 6.1.2. PBMAC1 . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Symmetric Key-Based MAC . . . . . . . . . . . . . . . . . 15 6.2.1. SHA2-Based HMAC . . . . . . . . . . . . . . . . . . . 15 6.2.2. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . 16 6.2.3. SHAKE-Based KMAC . . . . . . . . . . . . . . . . . . 16 7. Algorithm Use Profiles . . . . . . . . . . . . . . . . . . . 17 7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles . . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. Algorithm Profile for Lightweight CMP Profile . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 11. Normative References . . . . . . . . . . . . . . . . . . . . 25 Brockhaus, et al. Expires 4 December 2022 [Page 2] Internet-Draft CMP Algorithms June 2022 12. Informative References . . . . . . . . . . . . . . . . . . . 29 Appendix A. History of Changes . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction RFC 4210 Appendix D.2 [RFC4210] contains a set of algorithms, mandatory to be supported by conforming implementations. These algorithms were appropriate at the time CMP was released, but as cryptographic algorithms weaken over time, some of them should not be used anymore. In general, new attacks are emerging due to research cryptoanalysis or increase in computing power. New algorithms were introduced that are more resistant to today's attacks. This document lists current cryptographic algorithms usable with CMP to offer an easier way maintaining the list of suitable algorithms over time. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. In the following sections ASN.1 values and types are used to indicate where algorithm identifier and output values are provided. These ASN.1 values and types are defined in CMP [RFC4210], CRMF [RFC4211], CMP Updates [I-D.ietf-lamps-cmp-updates], or CMS [RFC5652]. 2. Message Digest Algorithms This section provides references to object identifiers and conventions to be employed by CMP implementations that support SHA2 or SHAKE message digest algorithms. Digest algorithm identifiers are located in: * hashAlg field of OOBCertHash and CertStatus * owf field of Challenge, PBMParameter, and DHBMParameter * digestAlgorithms field of SignedData * digestAlgorithm field of SignerInfo Digest values are located in: * hashVal field of OOBCertHash * certHash field of CertStatus Brockhaus, et al. Expires 4 December 2022 [Page 3] Internet-Draft CMP Algorithms June 2022 * witness field of Challenge In addition, digest values are input to signature algorithms. 2.1. SHA2 The SHA2 algorithm family is defined in FIPS Pub 180-4 [NIST.FIPS.180-4]. The message digest algorithms SHA-224, SHA-256, SHA-384, and SHA-512 are identified by the following OIDs: id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 } id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 } id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 } id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 } Specific conventions to be considered are specified in RFC 5754 Section 2 [RFC5754]. 2.2. SHAKE The SHA-3 family of hash functions is defined in FIPS Pub 202 [NIST.FIPS.202] and includes fixed output length variants SHA3-224, SHA3-256, SHA3-384, and SHA3-512, as well as extendable-output functions (SHAKEs) SHAKE128 and SHAKE256. Currently, SHAKE128 and SHAKE256 are the only members of the SHA3-family which are specified for use in X.509 certificates [RFC8692] and CMS [RFC8702] as one-way hash function for use with RSASSA-PSS and ECDSA. SHAKE is an extendable-output function and FIPS Pub 202 [NIST.FIPS.202] prohibits using SHAKE as general-purpose hash function. When SHAKE is used in CMP as a message digest algorithm, the output length MUST be 256 bits for SHAKE128 and 512 bits for SHAKE256. The message digest algorithms SHAKE128 and SHAKE256 are identified by the following OIDs: Brockhaus, et al. Expires 4 December 2022 [Page 4] Internet-Draft CMP Algorithms June 2022 id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashalgs(2) 11 } id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) hashalgs(2) 12 } Specific conventions to be considered are specified in RFC 8702 Section 3.1 [RFC8702]. 3. Signature Algorithms This section provides references to object identifiers and conventions to be employed by CMP implementations that support RSA, ECDSA, or EdDSA signature algorithms. The signature algorithm is referred to as MSG_SIG_ALG in Section 7.2, RFC 4210 Appendix D and E [RFC4210], and in the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. Signature algorithm identifiers are located in: * protectionAlg field of PKIHeader * algorithmIdentifier field of POPOSigningKey * signatureAlgorithm field of CertificationRequest, SignKeyPairTypes, and SignerInfo Signature values are located in: * protection field of PKIMessage * signature field of POPOSigningKey * signature field of CertificationRequest and SignerInfo 3.1. RSA The RSA (RSASSA-PSS and PKCS#1 version 1.5) signature algorithm is defined in RFC 8017 [RFC8017]. The algorithm identifier for RSASAA-PSS signatures used with SHA2 message digest algorithms is identified by the following OID: id-RSASSA-PSS OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 } Specific conventions to be considered are specified in RFC 4056 [RFC4056]. Brockhaus, et al. Expires 4 December 2022 [Page 5] Internet-Draft CMP Algorithms June 2022 The signature algorithm RSASSA-PSS used with SHAKE message digest algorithms are identified by the following OIDs: id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 30 } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 31 } Specific conventions to be considered are specified in RFC 8702 Section 3.2.1 [RFC8702]. The signature algorithm PKCS#1 version 1.5 used with SHA2 message digest algorithms is identified by the following OIDs: sha224WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 14 } sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 } sha384WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 12 } sha512WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 13 } Specific conventions to be considered are specified in RFC 5754 Section 3.2 [RFC5754]. 3.2. ECDSA The ECDSA signature algorithm is defined in FIPS Pub 186-4 [NIST.FIPS.186-4]. The signature algorithm ECDSA used with SHA2 message digest algorithms is identified by the following OIDs: ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 } As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves are identified by the following OIDs: Brockhaus, et al. Expires 4 December 2022 [Page 6] Internet-Draft CMP Algorithms June 2022 secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } secp224r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 33 } secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } secp384r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 34 } secp521r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 35 } Specific conventions to be considered are specified in RFC 5754 Section 3.3 [RFC5754]. The signature algorithm ECDSA used with SHAKE message digest algorithms are identified by the following OIDs: id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 32 } id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) 33 } Specific conventions to be considered are specified in RFC 8702 Section 3.2.2 [RFC8702]. 3.3. EdDSA The EdDSA signature algorithm is defined in RFC 8032 Section 3.3 [RFC8032] and FIPS Pub 186-5 (Draft) [NIST.FIPS.186-5]. The signature algorithm Ed25519 that MUST be used with SHA-512 message digest algorithms is identified by the following OIDs: id-Ed25519 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 112 } The signature algorithm Ed448 that MUST be used with SHAKE256 message digest algorithms is identified by the following OIDs: id-Ed448 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 113 } Specific conventions to be considered are specified in RFC 8419 [RFC8419]. Brockhaus, et al. Expires 4 December 2022 [Page 7] Internet-Draft CMP Algorithms June 2022 Note: The hash algorithm used to calculate the certHash in certConf messages MUST be SHA512 if the certificate to be confirmed has been signed using Ed25519 and SHAKE256 with d=512 if signed using Ed448. 4. Key Management Algorithms CMP utilizes the following general key management techniques: key agreement, key transport, and passwords. CRMF [RFC4211] and CMP Updates [I-D.ietf-lamps-cmp-updates] promotes the use of CMS [RFC5652] EnvelopedData by deprecating the use of EncryptedValue. 4.1. Key Agreement Algorithms The key agreement algorithm is referred to as PROT_ENC_ALG in RFC 4210 Appendix D and E [RFC4210] and as KM_KA_ALG in the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as well as in Section 7. Key agreement algorithms are only used in CMP when using CMS [RFC5652] EnvelopedData together with the key agreement key management technique. When a key agreement algorithm is used, a key- encryption algorithm (Section 4.3) is needed next to the content- encryption algorithm (Section 5). Key agreement algorithm identifiers are located in: * keyEncryptionAlgorithm field of KeyAgreeRecipientInfo Key wrap algorithm identifiers are located in: * KeyWrapAlgorithm parameters within keyEncryptionAlgorithm field of KeyAgreeRecipientInfo Wrapped content-encryption keys are located in: * encryptedKey field of RecipientEncryptedKeys 4.1.1. Diffie-Hellman Diffie-Hellman key agreement is defined in RFC 2631 [RFC2631] and SHALL be used in the ephemeral-static as specified in RFC 3370 [RFC3370]. Static-static variants SHALL NOT be used. The Diffie-Hellman key agreement algorithm is identified by the following OID: Brockhaus, et al. Expires 4 December 2022 [Page 8] Internet-Draft CMP Algorithms June 2022 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } Specific conventions to be considered are specified in RFC 3370 Section 4.1 [RFC3370]. 4.1.2. ECDH Elliptic Curve Diffie-Hellman (ECDH) key agreement is defined in RFC 5753 [RFC5753] and SHALL be used in the ephemeral-static variant as specified in RFC 5753 [RFC5753] or the 1-Pass ECMQV variant as specified in RFC 5753 [RFC5753]. Static-static variants SHALL NOT be used. The ECDH key agreement algorithm used together with NIST-recommended SECP curves are identified by the following OIDs: dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 11(11) 0 } dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 11(11) 1 } dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 11(11) 2 } dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 11(11) 3 } dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 14(14) 0 } dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 14(14) 1 } dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 14(14) 2 } dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 14(14) 3 } mqvSinglePass-sha224kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 15(15) 0 } mqvSinglePass-sha256kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 15(15) 1 } mqvSinglePass-sha384kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 15(15) 2 } mqvSinglePass-sha512kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) 15(15) 3 } As specified in RFC 5480 [RFC5480] the NIST-recommended SECP curves are identified by the following OIDs: Brockhaus, et al. Expires 4 December 2022 [Page 9] Internet-Draft CMP Algorithms June 2022 secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } secp224r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 33 } secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 7 } secp384r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 34 } secp521r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 35 } Specific conventions to be considered are specified in RFC 5753 [RFC5753]. The ECDH key agreement algorithm used together with curve25519 or curve448 are identified by the following OIDs: id-X25519 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 110 } id-X448 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) thawte(101) 111 } Specific conventions to be considered are specified in RFC 8418 [RFC8418]. 4.2. Key Transport Algorithms The key transport algorithm is also referred to as PROT_ENC_ALG in RFC 4210 Appendix D and E [RFC4210] and as KM_KL_ALG in the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], as well as in Section 7. Key transport algorithms are only used in CMP when using CMS [RFC5652] EnvelopedData together with the key transport key management technique. Key transport algorithm identifiers are located in: * keyEncryptionAlgorithm field of KeyTransRecipientInfo Key transport encrypted content-encryption keys are located in: * encryptedKey field of KeyTransRecipientInfo 4.2.1. RSA The RSA key transport algorithm is the RSA encryption scheme defined in RFC 8017 [RFC8017]. Brockhaus, et al. Expires 4 December 2022 [Page 10] Internet-Draft CMP Algorithms June 2022 The algorithm identifier for RSA (PKCS #1 v1.5) is: rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } The algorithm identifier for RSAES-OAEP is: id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } Further conventions to be considered for PKCS #1 v1.5 are specified in RFC 3370 Section 4.2.1 [RFC3370] and for RSAES-OAEP in RFC 3560 [RFC3560]. 4.3. Symmetric Key-Encryption Algorithms The symmetric key-encryption algorithm is also referred to as KM_KW_ALG in Section 7.2 and in the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. As symmetric key-encryption key management technique is not used by CMP, the symmetric key-encryption algorithm is only needed when using the key agreement or password-based key management technique with CMS [RFC5652] EnvelopedData. Key wrap algorithm identifiers are located in: * parameters field of the KeyEncryptionAlgorithmIdentifier of KeyAgreeRecipientInfo and PasswordRecipientInfo Wrapped content-encryption keys are located in: * encryptedKey field of RecipientEncryptedKeys (for key agreement) and PasswordRecipientInfo (for password-based key management) 4.3.1. AES Key Wrap The AES encryption algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and the key wrapping is defined in RFC 3394 [RFC3394]. AES key encryption has the algorithm identifier: Brockhaus, et al. Expires 4 December 2022 [Page 11] Internet-Draft CMP Algorithms June 2022 id-aes128-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 5 } id-aes192-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 25 } id-aes256-wrap OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 45 } The underlying encryption functions for the key wrap and content- encryption algorithms (as specified in Section 5) and the key sizes for the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm with AES-128 content-encryption algorithm), see also RFC 8551 [RFC8551]. Further conventions to be considered for AES key wrap are specified in RFC 3394 Section 2.2 [RFC3394] and RFC 3565 Section 2.3.2 [RFC3565]. 4.4. Key Derivation Algorithms The key derivation algorithm is also referred to as KM_KD_ALG in Section 7.2 and in the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. Key derivation algorithms are only used in CMP when using CMS [RFC5652] EnvelopedData together with password-based key management technique. Key derivation algorithm identifiers are located in: * keyDerivationAlgorithm field of PasswordRecipientInfo When using the password-based key management technique with EnvelopedData as specified in CMP Updates together with message authentication code (MAC)-based PKIProtection, the salt for the password-based MAC and KDF must be chosen independently to ensure usage of independent symmetric keys. 4.4.1. PBKDF2 The password-based key derivation function 2 (PBKDF2) is defined in RFC 8018 [RFC8018]. Password-based key derivation function 2 has the algorithm identifier: Brockhaus, et al. Expires 4 December 2022 [Page 12] Internet-Draft CMP Algorithms June 2022 id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 12 } Further conventions to be considered for PBKDF2 are specified in RFC 3370 Section 4.4.1 [RFC3370] and RFC 8018 Section 5.2 [RFC8018]. 5. Content Encryption Algorithms The content encryption algorithm is also referred to as PROT_SYM_ALG in Section 7, RFC 4210 Appendix D and E [RFC4210], and the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. Content encryption algorithms are only used in CMP when using CMS [RFC5652] EnvelopedData to transport a signed private key package in case of central key generation or key archiving, a certificate to facilitate implicit proof-of-possession, or a revocation passphrase in encrypted form. Content encryption algorithm identifiers are located in: * contentEncryptionAlgorithm field of EncryptedContentInfo Encrypted content is located in: * encryptedContent field of EncryptedContentInfo 5.1. AES-CBC The AES encryption algorithm is defined in FIPS Pub 197 [NIST.FIPS.197]. AES-CBC content encryption has the algorithm identifier: id-aes128-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 2 } id-aes192-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1)22 } id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1)42 } Specific conventions to be considered for AES-CBC content encryption are specified in RFC 3565 [RFC3565]. Brockhaus, et al. Expires 4 December 2022 [Page 13] Internet-Draft CMP Algorithms June 2022 6. Message Authentication Code Algorithms The message authentication code (MAC) is either used for shared secret-based CMP message protection or together with the password- based key derivation function (PBKDF2). The message authentication code algorithm is also referred to as MSG_MAC_ALG in Section 7, RFC 4210 Appendix D and E [RFC4210], and the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 6.1. Password-Based MAC Password-based message authentication code (MAC) algorithms combine the derivation of a symmetric key from a password or other shared secret information and a symmetric key-based MAC function as specified in Section 6.2 using this derived key. Message authentication code algorithm identifiers are located in: * protectionAlg field of PKIHeader Message authentication code values are located in: * PKIProtection field of PKIMessage 6.1.1. PasswordBasedMac The PasswordBasedMac algorithm is defined in RFC 4210 Section 5.1.3.1 [RFC4210], RFC 4211 Section 4.4 [RFC4211], and Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) [RFC9045]. The PasswordBasedMac algorithm is identified by the following OID: id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) nt(113533) nsn(7) algorithms(66) 13 } Further conventions to be considered for password-based MAC are specified in RFC 4210 Section 5.1.3.1 [RFC4210], RFC 4211 Section 4.4 [RFC4211], and Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) [RFC9045]. Brockhaus, et al. Expires 4 December 2022 [Page 14] Internet-Draft CMP Algorithms June 2022 6.1.2. PBMAC1 The Password-Based Message Authentication Code 1 (PBMAC1) is defined in RFC 8018 [RFC8018]. PBMAC1 combines a password-based key derivation function like PBKDF2 (Section 4.4.1) with an underlying symmetric key-based message authentication scheme. PBMAC1 has the following OID: id-PBMAC1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) 14 } Specific conventions to be considered for PBMAC1 are specified in RFC 8018 Section 7.1 and A.5 [RFC8018]. 6.2. Symmetric Key-Based MAC Symmetric key-based message authentication code (MAC) algorithms are used for deriving the symmetric encryption key when using PBKDF2 as described in Section 4.4.1 as well as with Password-based MAC as described in Section 6.1. Message authentication code algorithm identifiers are located in: * protectionAlg field of PKIHeader * messageAuthScheme field of PBMAC1 * mac field of PBMParameter * prf field of PBKDF2-params Message authentication code values are located in: * PKIProtection field of PKIMessage 6.2.1. SHA2-Based HMAC The HMAC algorithm is defined in RFC 2104 [RFC2104] and FIPS Pub 198-1 [NIST.FIPS.198-1]. The HMAC algorithm used with SHA2 message digest algorithms is identified by the following OIDs: Brockhaus, et al. Expires 4 December 2022 [Page 15] Internet-Draft CMP Algorithms June 2022 id-hmacWithSHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 8 } id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 9 } id-hmacWithSHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 10 } id-hmacWithSHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 11 } Specific conventions to be considered for SHA2-based HMAC are specified in RFC 4231 Section 3.1 [RFC4231]. 6.2.2. AES-GMAC The AES-GMAC algorithm is defined in FIPS Pub 197 [NIST.FIPS.197] and NIST SP 800-38d [NIST.SP.800-38d]. Note: AES-GMAC MUST NOT be used twice with the same parameter set, especially the same nonce. Therefore, it MUST NOT be used together with PBKDF2. When using it with PBMAC1 it MUST be ensured that AES- GMAC is only used as message authentication scheme and not for the key derivation function PBKDF2. The AES-GMAC algorithm is identified by the following OIDs: id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 9 } id-aes192-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 29 } id-aes256-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 49 } Specific conventions to be considered for AES-GMAC are specified in RFC 9044 [RFC9044]. 6.2.3. SHAKE-Based KMAC The KMAC algorithm is defined in RFC 8702 [RFC8702] and FIPS SP 800-185 [NIST.SP.800-185]. The SHAKE-based KMAC algorithm is identified by the following OIDs: Brockhaus, et al. Expires 4 December 2022 [Page 16] Internet-Draft CMP Algorithms June 2022 id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 19 } id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 20 } Specific conventions to be considered for KMAC with SHAKE are specified in RFC 8702 Section 3.4 [RFC8702]. 7. Algorithm Use Profiles This section provides profiles of algorithms and respective conventions for different application use cases. Recommendations like NIST SP 800-57 Recommendation for Key Management Table 2 [NIST.SP.800-57pt1r5] and ECRYPT Algorithms, Key Size and Protocols Report (2018) Section 4.6 [ECRYPT.CSA.D5.4] provide general information on current cryptographic algorithms. The overall cryptographic strength of a CMP deployment will depend on several factors, including: * Capabilities of the end entity: What kind of algorithms does the end entity support. The cryptographic strength of the system SHOULD be at least as strong as the algorithms and keys used for the certificate being managed. * Algorithm profile: The overall strength of the profile will be the strength of the weakest algorithm it contains. * Message protection: The overall strength of the CMC message protection - MAC-based protection: The entropy of the shared secret information or password when MAC-based message protection is used (MSG_MAC_ALG). - Signature-based protection: The strength of the key pair and signature algorithm when signature-based protection is used (MSG_SIG_ALG). - Protection of centrally generated keys: The strength of the algorithms used for the key management technique (Section 7.2: PROT_ENC_ALG or Section 7.1: KM_KA_ALG, KM_KT_ALG, KM_KD_ALG) and the encryption of the content-encryption key and private key (Section 7.2: SYM_PENC_ALG, PROT_SYM_ALG or Section 7.1: KM_KW_ALG, PROT_SYM_ALG). Brockhaus, et al. Expires 4 December 2022 [Page 17] Internet-Draft CMP Algorithms June 2022 The following table shows the algorithms listed in this document sorted by their bits of security. If an implementation intends to enroll and manage certificate for keys of a specific security, it SHALL implement and use algorithms of at least that strength for the respective PKI management operation. If one row does not provide a suitable algorithm, the implementer MUST choose one offering more bits of security. +=======+==========+================+==================+============+ | Bits | RSA or | Elliptic | Hash Function or | Symmetric | | of | DH | Curve | XOF with | Encryption | | Secu- | | | Specified Output | | | rity | | | Length (d) | | +=======+==========+================+==================+============+ | 112 | RSA2048, | ECDSA/ECDH | SHA224 | | | | DH(2048) | (secp224r1) | | | +-------+----------+----------------+------------------+------------+ | 128 | RSA3072, | ECDSA/ECDH | SHA256, | AES-128 | | | DH(3072) | (secp256r1), | SHAKE128(d=256) | | | | | Ed25519/ | | | | | | X25519 | | | | | | (Curve25519) | | | +-------+----------+----------------+------------------+------------+ | 192 | | ECDSA/ECDH | SHA384 | AES-192 | | | | (secp384r1) | | | +-------+----------+----------------+------------------+------------+ | 224 | | Ed448/X448 | | | | | | (Curve448) | | | +-------+----------+----------------+------------------+------------+ | 256 | | ECDSA/ECDH | SHA512, | AES-256 | | | | (secp521r1) | SHAKE256(d=512) | | +-------+----------+----------------+------------------+------------+ Table 1: Cryptographic Algorithms Sorted by their Bits of Security The following table shows the cryptographic algorithms sorted by their usage in CMP and with more details. +========+==========+===============+===============+===============+ |Bits of |Key Types |CMP Protection |Key Management | Key-Wrap and | |Security|to Be | |Technique | Symmetric | | |Certified | | | Encryption | +========+==========+===============+===============+===============+ | | |MSG_SIG_ALG, |PROT_ENC_ALG or| PROT_SYM_ALG, | | | |MSG_MAC_ALG |KM_KA_ALG, | SYM_PENC_ALG | | | | |KM_KT_ALG, | or | | | | |KM_KD_ALG | KM_KW_ALG | +--------+----------+---------------+---------------+---------------+ Brockhaus, et al. Expires 4 December 2022 [Page 18] Internet-Draft CMP Algorithms June 2022 |112 |RSA2048, |RSASSA-PSS |DH(2048), | | | |secp224r1 |(2048, SHA224 |RSAES-OAEP | | | | |or SHAKE128 |(2048, SHA224),| | | | |(d=256)), |RSAEncryption | | | | |RSAEncryption |(2048, SHA224),| | | | |(2048, SHA224),|ECDH | | | | |ECDSA |(secp224r1, | | | | |(secp224r1, |SHA224), | | | | |SHA224 or |PBKDF2 (HMAC- | | | | |SHAKE128 |SHA224) | | | | |(d=256)), | | | | | |PBMAC1 (HMAC- | | | | | |SHA224) | | | +--------+----------+---------------+---------------+---------------+ |128 |RSA3072, |RSASSA-PSS |DH(3072), | AES-128 | | |secp256r1,|(3072, SHA256 |RSAES-OAEP | | | |Curve25519|or SHAKE128 |(3072, SHA256),| | | | |(d=256)), |RSAEncryption | | | | |RSAEncryption |(3072, SHA256),| | | | |(3072, SHA256),|ECDH | | | | |ECDSA |(secp256r1, | | | | |(secp256r1, |SHA256), | | | | |SHA256 or |X25519, | | | | |SHAKE128 |PBKDF2 (HMAC- | | | | |(d=256)), |SHA256) | | | | |Ed25519 | | | | | |(SHA512), | | | | | |PBMAC1 (HMAC- | | | | | |SHA256) | | | +--------+----------+---------------+---------------+---------------+ |192 |secp384r1 |ECDSA |ECDH | AES-192 | | | |(secp384r1, |(secp384r1, | | | | |SHA384), |SHA384), | | | | |PBMAC1 (HMAC- |PBKDF2 (HMAC- | | | | |SHA384) |SHA384) | | +--------+----------+---------------+---------------+---------------+ |224 |Curve448 |Ed448 |X448 | | | | |(SHAKE256) | | | +--------+----------+---------------+---------------+---------------+ |256 |secp521r1 |ECDSA |ECDH | AES-256 | | | |(secp521r1, |(secp521r1, | | | | |SHA512 or |SHA512), | | | | |SHAKE256 |PBKDF2 (HMAC- | | | | |(d=512)), |SHA512) | | | | |PBMAC1 (HMAC- | | | | | |SHA512) | | | +--------+----------+---------------+---------------+---------------+ Brockhaus, et al. Expires 4 December 2022 [Page 19] Internet-Draft CMP Algorithms June 2022 Table 2: Cryptographic Algorithms Sorted by their Bits of Security and Usage by CMP To avoid consuming too many computational resources it is recommended to choose a set of algorithms offering roughly the same level of security. Below are provided several algorithm profiles which are balanced, assuming the implementer chooses MAC secrets and/or certificate profiles of at least equivalent strength. 7.1. Algorithm Profile for RFC 4210 PKI Management Message Profiles The following table updates the definitions of algorithms used within PKI Management Message Profiles as defined in CMP Appendix D.2 [RFC4210]. The columns in the table are: Name: An identifier used for message profiles Use: Description of where and for what the algorithm is used Mandatory: Algorithms which MUST be supported by conforming implementations Optional: Algorithms which are OPTIONAL to support Deprecated: Algorithms from RFC 4210 [RFC4210] which SHOULD NOT be used any more Brockhaus, et al. Expires 4 December 2022 [Page 20] Internet-Draft CMP Algorithms June 2022 +============+==============+======+===================+============+ |Name |Use |Manda-| Optional |Deprecated | | | |tory | | | +============+==============+======+===================+============+ |MSG_SIG_ALG |protection of |RSA | ECDSA, EdDSA |DSA, | | |PKI messages | | |combinations| | |using | | |with MD5 and| | |signature | | |SHA-1 | +------------+--------------+------+-------------------+------------+ |MSG_MAC_ALG |protection of |PBMAC1| PasswordBasedMac, |X9.9 | | |PKI messages | | HMAC, KMAC | | | |using MACing | | | | +------------+--------------+------+-------------------+------------+ |SYM_PENC_ALG|symmetric |AES- | |3-DES(3-key-| | |encryption of |wrap | |EDE, CBC | | |an end | | |Mode), RC5, | | |entity's | | |CAST-128 | | |private key | | | | | |where | | | | | |symmetric key | | | | | |is distributed| | | | | |out-of-band | | | | +------------+--------------+------+-------------------+------------+ |PROT_ENC_ALG|asymmetric |DH | ECDH, RSA | | | |algorithm used| | | | | |for encryption| | | | | |of (symmetric | | | | | |keys for | | | | | |encryption of)| | | | | |private keys | | | | | |transported in| | | | | |PKIMessages | | | | +------------+--------------+------+-------------------+------------+ |PROT_SYM_ALG|symmetric |AES- | |3-DES(3-key-| | |encryption |CBC | |EDE, CBC | | |algorithm used| | |Mode), RC5, | | |for encryption| | |CAST-128 | | |of private key| | | | | |bits (a key of| | | | | |this type is | | | | | |encrypted | | | | | |using | | | | | |PROT_ENC_ALG) | | | | +------------+--------------+------+-------------------+------------+ Table 3: Algorithms Used Within RFC 4210 Appendix D.2 Mandatory Algorithm Identifiers and Specifications: Brockhaus, et al. Expires 4 December 2022 [Page 21] Internet-Draft CMP Algorithms June 2022 RSA: sha256WithRSAEncryption with 2048 bit, see Section 3.1 PasswordBasedMac: id-PasswordBasedMac, see Section 6.1 (with id- sha256 as the owf parameter, see Section 2.1 and id-hmacWithSHA256 as the mac parameter, see Section 6.2.1) PBMAC1: id-PBMAC1, see Section 6.1.2 (with id-PBKDF2 as the key derivation function, see Section 4.4.1 and id-hmacWithSHA256 as message authentication scheme, see Section 6.2.1). It is RECOMMENDED to prefer the usage of PBMAC1 instead of PasswordBasedMac. DH: id-alg-ESDH, see Section 4.1.1 AES-wrap: id-aes128-wrap, see Section 4.3.1 AES-CBC: id-aes128-CBC, see Section 5.1 7.2. Algorithm Profile for Lightweight CMP Profile The following table contains definitions of algorithms which MAY be supported by implementations of the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. As the set of algorithms to be used for implementations of the Lightweight CMP Profile heavily depends on the PKI management operations implemented, the certificates used for messages protection, and the certificates to be managed, this document will not specify a specific set that is mandatory to support for conforming implementations. The columns in the table are: Name: An identifier used for message profiles Use: Description of where and for what the algorithm is used Examples: Lists the algorithms as described in this document. The list of algorithms depends on the set of PKI management operations to be implemented. Note: It is RECOMMENDED to prefer the usage of PBMAC1 instead of PasswordBasedMac. Brockhaus, et al. Expires 4 December 2022 [Page 22] Internet-Draft CMP Algorithms June 2022 +==============+================================+==================+ | Name | Use | Examples | +==============+================================+==================+ | MSG_SIG_ALG | protection of PKI messages | RSA, ECDSA, | | | using signature and for | EdDSA | | | SignedData, e.g., a private | | | | key transported in PKIMessages | | +--------------+--------------------------------+------------------+ | MSG_MAC_ALG | protection of PKI messages | PasswordBasedMac | | | using MACing | (see Section 9), | | | | PBMAC1, HMAC, | | | | KMAC | +--------------+--------------------------------+------------------+ | KM_KA_ALG | asymmetric key agreement | DH, ECDH | | | algorithm used for agreement | | | | of a symmetric key for use | | | | with KM_KW_ALG | | +--------------+--------------------------------+------------------+ | KM_KT_ALG | asymmetric key encryption | RSA | | | algorithm used for transport | | | | of a symmetric key for | | | | PROT_SYM_ALG | | +--------------+--------------------------------+------------------+ | KM_KD_ALG | symmetric key derivation | PBKDF2 | | | algorithm used for derivation | | | | of a symmetric key for use | | | | with KM_KW_ALG | | +--------------+--------------------------------+------------------+ | KM_KW_ALG | algorithm to wrap a symmetric | AES-wrap | | | key for PROT_SYM_ALG | | +--------------+--------------------------------+------------------+ | PROT_SYM_ALG | symmetric content encryption | AES-CBC | | | algorithm used for encryption | | | | of EnvelopedData, e.g., a | | | | private key transported in | | | | PKIMessages | | +--------------+--------------------------------+------------------+ Table 4: Algorithms Used Within Lightweight CMP Profile 8. IANA Considerations This document does not request changes to the IANA registry. Brockhaus, et al. Expires 4 December 2022 [Page 23] Internet-Draft CMP Algorithms June 2022 9. Security Considerations This document lists many cryptographic algorithms usable with CMP to offer implementer a more up-to-date choice. Finally, the algorithms to be supported also heavily depend on the certificates and PKI management operations utilized in the target environment. The algorithm with the lowest security strength and the entropy of shared secret information define the security of the overall solution, see Section 7. When using MAC-based message protection the use of PBMAC1 is preferable to that of PasswordBasedMac. First, PBMAC1 is a well- known scrutinized algorithm, which is not true for PasswordBasedMac. Second, the PasswordBasedMac algorithm as specified in RFC 4211 Section 4.4 [RFC4211] is essentially PBKDF1 (as defined in RFC 8018 Section 5.1 [RFC8018]) with an HMAC step at the end. Here we update to use the PBKDF2-HMAC construct defined as PBMAC1 in [RFC8018]. PBKDF2 is superior to PBKDF1 in an improved internal construct for iterated hashing, and in removing PBKDF1's limitation of only being able to derive keys up to the size of the underlying hash function. Additionally, PBKDF1 is not recommended for new applications as stated in Section 5.1 of RFC 8018 [RFC8018] and no longer an approved algorithm by most standards bodies, and therefore presents difficulties to implementer who are submitting their CMP implementations for certification, hence moving to a PBKDF2-based mechanism. This change is in alignment with [RFC9045] which updates [RFC4211] to allow the use of PBMAC1 in CRMF. AES-GMAC MUST NOT be used as the pseudo random function in PBKDF2; the use of AES-GMAC more than once with the same key and the same nonce will break the security. In Section 7 of this document there is also an update to the Appendix D.2 of RFC 4210 [RFC4210] and a set of algorithms that MAY be supported when implementing the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. It is recognized that there may be older CMP implementations in use that conform to the algorithm use profile from Appendix D.2 of RFC 4210 [RFC4210]. For example, the use of AES is now mandatory for PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. Therefore, it is expected that many CMP systems may already support the recommended algorithms in this specification. In such systems the weakened algorithms should be disabled from further use. If critical systems cannot be immediately updated to conform to the recommended algorithm use profile, it is recommended a plan to migrate the infrastructure to conforming profiles be adopted as soon as possible. Brockhaus, et al. Expires 4 December 2022 [Page 24] Internet-Draft CMP Algorithms June 2022 Symmetric key-based MAC algorithms as described in Section 6.2 MAY be used as MSG_MAC_ALG. The implementer MUST choose a suitable PRF and ensure that the key has sufficient entropy to match the overall security level of the algorithm profile. These considerations are outside the scope of the profile. 10. Acknowledgements Thanks to Russ Housley for supporting this draft with submitting [RFC9044] and [RFC9045]. May thanks also to all reviewers like Serge Mister, Mark Ferreira, Yuefei Lu, Tomas Gustavsson, Lijun Liao, David von Oheimb and Steffen Fries for their input and feedback to this document. Apologies to all not mentioned reviewers and supporters. 11. Normative References [I-D.ietf-lamps-cmp-updates] Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate Management Protocol (CMP) Updates", Work in Progress, Internet-Draft, draft-ietf-lamps-cmp-updates-20, 31 May 2022, . [I-D.ietf-lamps-lightweight-cmp-profile] Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight Certificate Management Protocol (CMP) Profile", Work in Progress, Internet-Draft, draft-ietf-lamps-lightweight- cmp-profile-12, 13 May 2022, . [NIST.FIPS.180-4] Dang, Quynh H., "Secure Hash Standard", NIST NIST FIPS 180-4, DOI 10.6028/NIST.FIPS.180-4, July 2015, . [NIST.FIPS.186-4] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", NIST NIST FIPS 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, . Brockhaus, et al. Expires 4 December 2022 [Page 25] Internet-Draft CMP Algorithms June 2022 [NIST.FIPS.186-5] National Institute of Standards and Technology (NIST), "FIPS Pub 186-5 (Draft): Digital Signature Standard (DSS)", October 2019, . [NIST.FIPS.197] National Institute of Standards and Technology (NIST), "Advanced encryption standard (AES)", NIST NIST FIPS 197, DOI 10.6028/NIST.FIPS.197, November 2001, . [NIST.FIPS.198-1] National Institute of Standards and Technology (NIST), "The Keyed-Hash Message Authentication Code (HMAC)", NIST NIST FIPS 198-1, DOI 10.6028/NIST.FIPS.198-1, July 2008, . [NIST.FIPS.202] Dworkin, Morris J., "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", NIST NIST FIPS 202, DOI 10.6028/NIST.FIPS.202, July 2015, . [NIST.SP.800-185] Kelsey, John., Change, Shu-jen., and Ray. Perlner, "SHA-3 derived functions: cSHAKE, KMAC, TupleHash and ParallelHash", NIST NIST SP 800-185, DOI 10.6028/NIST.SP.800-185, December 2016, . [NIST.SP.800-38d] Dworkin, M J., "Recommendation for block cipher modes of operation :GaloisCounter Mode (GCM) and GMAC", NIST NIST SP 800-38d, DOI 10.6028/NIST.SP.800-38d, 2007, . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . Brockhaus, et al. Expires 4 December 2022 [Page 26] Internet-Draft CMP Algorithms June 2022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, DOI 10.17487/RFC2631, June 1999, . [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, . [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, . [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)", RFC 3560, DOI 10.17487/RFC3560, July 2003, . [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, . [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)", RFC 4056, DOI 10.17487/RFC4056, June 2005, . [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, DOI 10.17487/RFC4210, September 2005, . [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, . [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, DOI 10.17487/RFC4231, December 2005, . Brockhaus, et al. Expires 4 December 2022 [Page 27] Internet-Draft CMP Algorithms June 2022 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 2010, . [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: Password-Based Cryptography Specification Version 2.1", RFC 8018, DOI 10.17487/RFC8018, January 2017, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)", RFC 8418, DOI 10.17487/RFC8418, August 2018, . [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 2018, . Brockhaus, et al. Expires 4 December 2022 [Page 28] Internet-Draft CMP Algorithms June 2022 [RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)", RFC 8702, DOI 10.17487/RFC8702, January 2020, . [RFC9044] Housley, R., "Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)", RFC 9044, DOI 10.17487/RFC9044, June 2021, . [RFC9045] Housley, R., "Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 9045, DOI 10.17487/RFC9045, June 2021, . 12. Informative References [ECRYPT.CSA.D5.4] University of Bristol, "Algorithms, Key Size and Protocols Report (2018)", March 2015, . [NIST.SP.800-57pt1r5] Barker, Elaine., "Recommendation for key management:part 1 - general", NIST NIST SP 800-57pt1r5, DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, . [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, . [RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, DOI 10.17487/RFC8692, December 2019, . Appendix A. History of Changes Note: This appendix will be deleted in the final version of the document. From version 14 -> 15: Brockhaus, et al. Expires 4 December 2022 [Page 29] Internet-Draft CMP Algorithms June 2022 * Providing changes addressing comment from Martin Duke and Zaheduzzaman Sarker regarding the introduction From version 13 -> 14: * Providing changes addressing comments from GEN AD review From version 12 -> 13: * Providing changes addressing comments from OPSDIR and GENART last call reviews From version 11 -> 12: * Capitalized all headlines From version 10 -> 11: * Changes on the tables in Section 7 after direct exchange with Quynh From version 09 -> 10: * Removed the pre-RFC5378 work disclaimer after the RFC 4210 authors granted BCP78 rights to the IETF Trust * Implemented the changes proposed by Quynh, (see thread "Quynh Action: draft-ietf-lamps-cmp-algorithms-08.txt") and removed markers for ToDos regarding this review of SHAKE and KMAC usage as well as on the tables in Section 7 From version 08 -> 09: * Updated IPR disclaimer From version 07 -> 08: * Fixing issues from WG and AD review * Adding Note to Section 2.2, 3.3, and 6.2.3 regarding usage of SHAKE and KMAC and added ToDo regarding checking respective notes * Added two tables showing algorithms sorted by their strength to Section 7 and added ToDo regarding checking these tables * Updates the algorithm use profile in Section 7.1 * Updated and added security consideration on SHAKE, PasswordBasedMac, KMAC, and symmetric key-based MAC functions and added ToDo regarding checking the security consideration on SHAKE From version 06 -> 07: Brockhaus, et al. Expires 4 December 2022 [Page 30] Internet-Draft CMP Algorithms June 2022 * Fixing minor formatting nits From version 05 -> 06: * Added text to Section 2 and Section 3.3 to clearly specify the hash algorithm to use for certConf messages for certificates signed with EdDSA (see thread "[CMP Updates] Hash algorithm to us for calculating certHash") * Updated new RFC numbers for I-D.ietf-lamps-cms-aes-gmac-alg and I- D.ietf-lamps-crmf-update-algs From version 04 -> 05: * Minor changes and corrections in wording From version 03 -> 04: * Added John Gray to the list of authors due to his extensive support and valuable feedback * Added some clarification of the use AES-GMAC to Section 6.2.1 * Extended the guidance on how to select a set of algorithms in Section 7 and deleted former Section 7.1 * Deleted the algorithms mandatory to support in Section 7.2 as discussed at IETF 110 * Extended the Security considerations in Section 9 * Minor changes in wording From version 02 -> 03: * Moved former Appendix A to new Section 7 as suggested by Rich and Russ (see thread "I-D Action: draft-ietf-lamps-cmp-algorithms- 02.txt") * Added a column to Table 1 in Section 7.2 to reflect the changes to RFC 4210 * Updated Table 2 in Section 7.3 * Added a paragraph to Section 9 to discuss backward compatibility with RFC 4210 * Minor changes in wording From version 01 -> 02: * Added Hans Aschauer, Mike Ounsworth, and Serge Mister as co-author * Changed to XML V3 * Added SHAKE digest algorithm to Section 2 as discussed at IETF 109 * Deleted DSA from Section 3 as discussed at IETF 109 * Added RSASSA-PSS with SHAKE to Section 3 * Added SECP curves the section on ECDSA with SHA2, ECDSA with SHAKE, and EdDSA to Section 3 as discussed at IETF 109 Brockhaus, et al. Expires 4 December 2022 [Page 31] Internet-Draft CMP Algorithms June 2022 * Deleted static-static D-H and ECDH from Section 4.1 based on the discussion on the mailing list (see thread "[CMP Algorithms] Section 4.1.1 and 4.1.2 drop static-static (EC)DH key agreement algorithms for use in CMP") * Added ECDH OIDs and SECP curves, as well as ECDH with curve25519 and curve448 to Section 4.1 as discussed at IETF 109 * Deleted RSA-OAEP from Section 4.2 first as discussed at IETF 109, but re-added it after discussion on the mailing list (see thread "Mail regarding draft-ietf-lamps-cmp-algorithms") * Added a paragraph to Section 4.3.1 to explain that the algorithms and key length for content encryption and key wrapping must be aligned as discussed on the mailing list (see thread "[CMP Algorithms] Use Key-Wrap with or without padding in Section 4.3 and Section 5") * Deleted AES-CCM and AES-GMC from and added AES-CBC to Section 5 as discussed at IETF 109 * Added Section 6.1.2 to offer PBMAC1 as discusses on the mailing list (see thread "Mail regarding draft-ietf-lamps-crmf-update- algs-02") and restructured text in Section 6 to be easier to differentiate between password- and shared-key-based MAC * Deleted Diffie-Hellmann based MAC from Section 6 as is only relevant when using enrolling Diffie-Hellmann certificates * Added AES-GMAC and SHAKE-based KMAC to Section 6 as discussed at IETF 109 * Extended Section 9 to mention Russ supporting with two additional I-Ds and name further supporters of the draft * Added a first draft of a generic algorithm selection guideline to Appendix A * Added a first proposal for mandatory algorithms for the Lightweight CMP Profile to Appendix A * Minor changes in wording From version 00 -> 01: * Changed sections Symmetric Key-Encryption Algorithms and Content Encryption Algorithms based on the discussion on the mailing list (see thread "[CMP Algorithms] Use Key-Wrap with or without padding in Section 4.3 and Section 5") * Added Appendix A with updated algorithms profile for RDC4210 Appendix D.2 and first proposal for the Lightweight CMP Profile * Minor changes in wording Authors' Addresses Hendrik Brockhaus (editor) Siemens AG Email: hendrik.brockhaus@siemens.com Brockhaus, et al. Expires 4 December 2022 [Page 32] Internet-Draft CMP Algorithms June 2022 Hans Aschauer Siemens AG Email: hans.aschauer@siemens.com Mike Ounsworth Entrust Email: mike.ounsworth@entrust.com John Gray Entrust Email: john.gray@entrust.com Brockhaus, et al. Expires 4 December 2022 [Page 33] ./draft-ietf-bess-evpn-optimized-ir-12.txt0000644000764400076440000024246614173771721020213 0ustar iustiniustin BESS Workgroup J. Rabadan, Ed. Internet-Draft S. Sathappan Intended status: Standards Track Nokia Expires: July 29, 2022 W. Lin Juniper Networks M. Katiyar Versa Networks A. Sajassi Cisco Systems January 25, 2022 Optimized Ingress Replication Solution for Ethernet VPN (EVPN) draft-ietf-bess-evpn-optimized-ir-12 Abstract Network Virtualization Overlay networks using Ethernet VPN (EVPN) as their control plane may use Ingress Replication or PIM (Protocol Independent Multicast)-based trees to convey the overlay Broadcast, Unknown unicast and Multicast (BUM) traffic. PIM provides an efficient solution to avoid sending multiple copies of the same packet over the same physical link, however it may not always be deployed in the Network Virtualization Overlay core network. Ingress Replication avoids the dependency on PIM in the Network Virtualization Overlay network core. While Ingress Replication provides a simple multicast transport, some Network Virtualization Overlay networks with demanding multicast applications require a more efficient solution without PIM in the core. This document describes a solution to optimize the efficiency of Ingress Replication trees. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 29, 2022. Rabadan, et al. Expires July 29, 2022 [Page 1] Internet-Draft EVPN Optimized IR January 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, 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 of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 6 3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 9 4. EVPN BGP Attributes for Optimized Ingress Replication . . . . 9 5. Non-Selective Assisted-Replication (AR) Solution Description 13 5.1. Non-selective AR-REPLICATOR Procedures . . . . . . . . . 15 5.2. Non-Selective AR-LEAF Procedures . . . . . . . . . . . . 17 5.3. RNVE Procedures . . . . . . . . . . . . . . . . . . . . . 19 6. Selective Assisted-Replication (AR) Solution Description . . 20 6.1. Selective AR-REPLICATOR Procedures . . . . . . . . . . . 21 6.2. Selective AR-LEAF Procedures . . . . . . . . . . . . . . 23 7. Pruned-Flood-Lists (PFL) . . . . . . . . . . . . . . . . . . 26 7.1. A Pruned-Flood-List Example . . . . . . . . . . . . . . . 26 8. AR Procedures for Single-IP AR-REPLICATORS . . . . . . . . . 28 9. AR Procedures and EVPN All-Active Multi-homing Split-Horizon 28 9.1. Ethernet Segments on AR-LEAF Nodes . . . . . . . . . . . 29 9.2. Ethernet Segments on AR-REPLICATOR nodes . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 14.1. Normative References . . . . . . . . . . . . . . . . . . 32 14.2. Informative References . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction Ethernet Virtual Private Networks (EVPN) may be used as the control plane for a Network Virtualization Overlay network [RFC8365]. Network Virtualization Edge (NVE) and Provider Edge (PE) devices that Rabadan, et al. Expires July 29, 2022 [Page 2] Internet-Draft EVPN Optimized IR January 2022 are part of the same EVPN Broadcast Domain (BD) use Ingress Replication or PIM-based trees to transport the tenant's Broadcast, Unknown unicast and Multicast (BUM) traffic. In the Ingress Replication approach, the ingress NVE receving a BUM frame from the Tenant System will create as many copies of the frame as remote NVEs/PEs are attached to the BD. Each of those copies will be encapsulated into an IP packet where the outer IP Destination Address (IP DA) identifies the loopback of the egress NVE/PE. The IP fabric core nodes (also known as Spines) will simply route the IP encapsulated BUM frames based on the outer IP DA. If PIM-based trees are used instead of Ingress Replication, the NVEs/PEs attached to the same BD will join a PIM-based tree. The ingress NVE receiving a BUM frame will send a single copy of the frame, encapsulated into an IP packet where the outer IP DA is the multicast address that represents the PIM-based tree. The IP fabric core nodes are part of the PIM tree and keep multicast state for the multicast group, so that IP encapsulated BUM frames can be routed to all the NVEs/PEs that joined the tree. The two approaches are illustrated in Figure 1. On the left-hand side, NVE1 uses Ingress Replication to send a BUM frame (originated from Tenant System TS1) to the remote nodes attached to the BD, i.e., NVE2, NV3, PE1. On the right-hand side of the diagram, the same example is depicted but using a PIM-based tree, i.e., (S1,G1), instead of Ingress Replication. While a single copy of the tunneled BUM frame is generated in the latter approach, all the routers in the fabric need to keep muticast state, e.g., the Spine keeps a PIM multicast routing entry for (S1,G1) with an Incoming Interface (IIF) and three Outgoing Interfaces (OIFs). Rabadan, et al. Expires July 29, 2022 [Page 3] Internet-Draft EVPN Optimized IR January 2022 To-WAN To-WAN ^ ^ | | +-----+ +-----+ +----------| PE1 |-----------+ +----------| PE1 |-----------+ | +--^--+ | | +--^--+ | | | IP Fabric | | | IP Fabric | | PE | | (S1,G1) |OIF to-G | | +----PE->+-----+ No State | | IIF +-----+ OIF to-G | | | +---2->|Spine|------+ | | +------>Spine|------+ | | | | +-3->+-----+ | | | | +-----+ | | | | | | 2 3 | | |PIM |OIF to-G | | | | | |IR | | | | |tree | | | |+-----+ +--v--+ +--v--+ | |+-----+ +--v--+ +--v--+ | +| NVE1|---| NVE2|---| NVE3|-+ +| NVE1|---| NVE2|---| NVE3|-+ +--^--+ +-----+ +-----+ +--^--+ +-----+ +-----+ | | | | | | | v v | v v TS1 TS2 TS3 TS1 TS2 TS3 Figure 1: Ingress Replication vs PIM-based trees in NVO networks In Network Virtualization Overlay networks where PIM-based trees cannot be used, Ingress Replication is the only option. Examples of these situations are Network Virtualization Overlay networks where the core nodes do not support PIM or the network operator does not want to run PIM in the core. In some use-cases, the amount of replication for BUM traffic is kept under control on the NVEs due to the following fairly common assumptions: a. Broadcast is greatly reduced due to the proxy ARP (Address Resolution Protocol) and proxy ND (Neighbor Discovery) capabilities supported by EVPN on the NVEs [I-D.ietf-bess-evpn-proxy-arp-nd]. Some NVEs can even provide Dynamic Host Configuration Protocol (DHCP) server functions for the attached Tenant Systems, reducing the broadcast even further. b. Unknown unicast traffic is greatly reduced in Network Virtualization Overlay networks where all the MAC and IP addresses from the Tenant Systems are learned in the control plane. c. Multicast applications are not used. If the above assumptions are true for a given Network Virtualization Overlay network, then Ingress Replication provides a simple solution Rabadan, et al. Expires July 29, 2022 [Page 4] Internet-Draft EVPN Optimized IR January 2022 for multi-destination traffic. However, the statement c) above is not always true and multicast applications are required in many use- cases. When the multicast sources are attached to NVEs residing in hypervisors or low-performance-replication TORs (Top Of Rack switches), the ingress replication of a large amount of multicast traffic to a significant number of remote NVEs/PEs can seriously degrade the performance of the NVE and impact the application. This document describes a solution that makes use of two Ingress Replication optimizations: 1. Assisted-Replication (AR) 2. Pruned-Flood-Lists (PFL) Assisted-Replication consists of a set of procedures that allows the ingress NVE/PE to send a single copy of a Broadcast or Multicast frame received from a Tenant System to the Broadcast Domain, without the need for PIM in the underlay. Assisted Replication defines the roles of AR-REPLICATOR and AR-LEAF routers. The AR-LEAF is the ingress NVE/PE attached to the Tenant System. The AR-LEAF sends a single copy of a Broadcast or Multicast packet to a selected AR- REPLICATOR that replicates the packet mutiple times to remote AR-LEAF or AR-REPLICATOR routers, and therefore "assisting" the ingress AR- LEAF in delivering the Broadcast or Multicast traffic to the remote NVEs/PEs attached to the same Broadcast Domain. Assisted-Replication can use a single AR-REPLICATOR or two AR-REPLICATOR routers in the path between the ingress AR-LEAF and the remote destination NVE/PEs. The procedures that use a single AR-REPLICATOR (Non-Selective Assisted-Replication Solution) are specified in Section 5, whereas Section 6 describes how multi-staged replication, i.e., two AR- REPLICATOR routers in the path between the ingress AR-LEAF and destination NVEs/PEs, is accomplished (Selective Assisted-Replication Solution). The Assisted-Replication procedures do not impact unknown unicast traffic, which follows the same forwarding procedures as known unicast traffic so that packet re-ordering does not occur. Pruned-Flood-Lists is a method for the ingress NVE/PE to prune or remove certain destination NVEs/PEs from a flood-list, depending on the interest of those NVEs/PEs in receiving Broadcast, Multicast or Unknown unicast. As specified in [RFC8365], an NVE/PE builds a flood-list for BUM traffic based on the Next-Hops of the received EVPN Inclusive Multicast Ethernet Tag routes for the Broadcast Domain. While [RFC8365] states that the flood-list is used for all BUM traffic, this document allows pruning certain Next-Hops from the list. As an example, suppose an ingress NVE creates a flood-list Rabadan, et al. Expires July 29, 2022 [Page 5] Internet-Draft EVPN Optimized IR January 2022 with Next-Hops PE1, PE2 and PE3. If PE2 and PE3 signaled no-interest in receiving Unknown Unicast in their Inclusive Multicast Ethernet Tag routes, when the ingress NVE receives an Unknown Unicast frame from a Tenant System it will replicate it only to PE1. That is, PE2 and PE3 are "pruned" from the NVE's flood-list for Unknown Unicast traffic. Pruned-Flood-Lists can be used with Ingress Replication or Assisted-Replication, and it is described in Section 7. Both optimizations, Assisted-Replication and Pruned-Flood-Lists, may be used together or independently so that the performance and efficiency of the network to transport multicast can be improved. Both solutions require some extensions to the BGP attributes used in [RFC7432], and they are described in Section 4. The Assisted-Replication solution described in this document is focused on Network Virtualization Overlay networks (hence it uses IP tunnels) and MPLS transport networks are out of scope. The Pruned- Flood-Lists solution MAY be used in Network Virtualization Overlay and MPLS transport networks. Section 3 lists the requirements of the combined optimized Ingress Replication solution, whereas Section 5 and Section 6 describe the Assisted-Replication solution (for Non-Selective and Selective procedures, respectively), and Section 7 the Pruned-Flood-Lists solution. 2. Terminology and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terminology is used throughout the document: - Asisted Replication forwarding mode: for an AR-LEAF, it means sending an Attachment Circuit BM packet to a single AR-REPLICATOR with tunnel destination IP AR-IP. For an AR-REPLICATOR, it means sending a BM packet to a selected number or all the overlay tunnels when the packet was previously received from an overlay tunnel. - AR-LEAF: Assisted Replication - LEAF, refers to an NVE/PE that sends all the Broadcast and Multicast traffic to an AR-REPLICATOR that can replicate the traffic further on its behalf. An AR-LEAF is typically an NVE/PE with poor replication performance capabilities. Rabadan, et al. Expires July 29, 2022 [Page 6] Internet-Draft EVPN Optimized IR January 2022 - AR-REPLICATOR: Assisted Replication - REPLICATOR, refers to an NVE/PE that can replicate Broadcast or Multicast traffic received on overlay tunnels to other overlay tunnels and local Attachment Circuits. This document defines the control and data plane procedures that an AR-REPLICATOR needs to follow. - AR-IP: IP address owned by the AR-REPLICATOR and used to differentiate the incoming traffic that must follow the AR procedures. The AR-IP is also used in the Tunnel Identifier and Next-Hop fields of the Replicator-AR route. - AR-VNI: VNI advertised by the AR-REPLICATOR along with the Replicator-AR route. It is used to identify the incoming packets that must follow AR procedures ONLY in the Single-IP AR-REPLICATOR case Section 8. - BM traffic: Refers to Broadcast and Multicast frames (excluding unknown unicast frames). - BD: Broadcast Domain, as defined in [RFC7432]. - BD label: defined as the MPLS label that identifies the Broadcast Domain and is advertised in Regular-IR or Replicator-AR routes, when the encapsulation is MPLSoGRE or MPLSoUDP. - DF and NDF: Designated Forwarder and Non-Designated Forwarder, are roles defined in NVE/PEs attached to Multi-Homed Tenant Systems, as per [RFC7432] and [RFC8365]. - ES and ESI: Ethernet Segment and Ethernet Segment Identifier, as EVPN Multi-Homing concepts specified in [RFC7432]. - EVI: EVPN Instance. A group of Provider Edge (PE) devices participating in the same EVPN service, as specified in [RFC7432]. - GRE: Generic Routing Encapsulation [RFC4023]. - Ingress Replication forwarding mode: it refers to the Ingress Replication behavior explained in [RFC7432]. It means sending an Attachment Circuit BM packet copy to each remote PE/NVE in the BD and sending an overlay BM packet only to the Attachment Circuits and not other overlay tunnels. - IR-IP: local IP address of an NVE/PE that is used for the Ingress Replication signaling and procedures in [RFC7432]. Encapsulated incoming traffic with outer destination IP matching the IR-IP will follow the Ingress Replication procedures and not the Assisted- Rabadan, et al. Expires July 29, 2022 [Page 7] Internet-Draft EVPN Optimized IR January 2022 Replication procedures. The IR-IP is also used in the Tunnel Identifier and Next-hop fields of the Regular-IR route. - IR-VNI: VNI advertised along with the Inclusive Multicast Ethernet Tag route for Ingress Replication Tunnel Type. - MPLS: Multi-Protocol Label Switching. - NVE: Network Virtualization Edge router, used in this document as in [RFC8365]. - NVGRE: Network Virtualization using Generic Routing Encapsulation, as in [RFC7637]. - PE: Provider Edge router. - PMSI: P-Multicast Service Interface - a conceptual interface for a PE to send customer multicast traffic to all or some PEs in the same VPN [RFC6513]. - RD: Route Distinguisher. - Regular-IR route: an EVPN Inclusive Multicast Ethernet Tag route [RFC7432] that uses Ingress Replication Tunnel Type. - RNVE: Regular NVE, refers to an NVE that supports the procedures of [RFC8365] and does not support the procedures in this document. However, this document defines procedures to interoperate with RNVEs. - Replicator-AR route: an EVPN Inclusive Multicast Ethernet Tag route that is advertised by an AR-REPLICATOR to signal its capabilities, as described in Section 4. - TOR: Top Of Rack switch. - TS and VM: Tenant System and Virtual Machine. In this document Tenant Systems and Virtual Machiness are the devices connected to the Attachment Circuits of the PEs and NVEs. - VNI: VXLAN Network Identifier, used in VXLAN tunnels. - VSID: Virtual Segment Identifier, used in NVGRE tunnels. - VXLAN: Virtual Extensible LAN [RFC7348]. Rabadan, et al. Expires July 29, 2022 [Page 8] Internet-Draft EVPN Optimized IR January 2022 3. Solution Requirements The Ingress Replication optimization solution specified in this document meets the following requirements: a. It provides an Ingress Replication optimization for Broadcast and Multicast traffic without the need for PIM, while preserving the packet order for unicast applications, i.e., unknown unicast traffic should follow the same path as known unicast traffic. This optimization is required in low-performance NVEs. b. It reduces the flooded traffic in Network Virtualization Overlay networks where some NVEs do not need broadcast/multicast and/or unknown unicast traffic. c. The solution is compatible with [RFC7432] and [RFC8365] and has no impact on the CE procedures for BM traffic. In particular, the solution supports the following EVPN functions: o All-active multi-homing, including the split-horizon and Designated Forwarder (DF) functions. o Single-active multi-homing, including the DF function. o Handling of multi-destination traffic and processing of broadcast and multicast as per [RFC7432]. d. The solution is backwards compatible with existing NVEs using a non-optimized version of Ingress Replication. A given BD can have NVEs/PEs supporting regular Ingress Replication and optimized Ingress Replication. e. The solution is independent of the Network Virtualization Overlay specific data plane encapsulation and the virtual identifiers being used, e.g.: VXLAN VNIs, NVGRE VSIDs or MPLS labels, as long as the tunnel is IP-based. 4. EVPN BGP Attributes for Optimized Ingress Replication This solution extends the [RFC7432] Inclusive Multicast Ethernet Tag routes and attributes so that an NVE/PE can signal its optimized Ingress Replication capabilities. The NLRI of the Inclusive Multicast Ethernet Tag route as in [RFC7432] is shown in Figure 2 and it is used in this document without any modifications to its format. The PMSI Tunnel Attribute's general format as in [RFC7432] (which takes it from [RFC6514]) is Rabadan, et al. Expires July 29, 2022 [Page 9] Internet-Draft EVPN Optimized IR January 2022 used in this document, only a new Tunnel Type and new flags are specified, as shown in Figure 3: +---------------------------------+ | RD (8 octets) | +---------------------------------+ | Ethernet Tag ID (4 octets) | +---------------------------------+ | IP Address Length (1 octet) | +---------------------------------+ | Originating Router's IP Addr | | (4 or 16 octets) | +---------------------------------+ Figure 2: EVPN Inclusive Multicast Tag route's NLRI 0 1 2 3 4 5 6 7 +---------------------------------+ +--+--+--+--+--+--+--+--+ | Flags (1 octet) | -> |x |E |x | T |BM|U |L | +---------------------------------+ +--+--+--+--+--+--+--+--+ | Tunnel Type (1 octets) | T = Assisted-Replication Type +---------------------------------+ BM = Broadcast and Multicast | MPLS Label (3 octets) | U = Unknown unicast +---------------------------------+ x = unassigned | Tunnel Identifier (variable) | +---------------------------------+ Figure 3: PMSI Tunnel Attribute The Flags field in Figure 3 is 8 bits long as per [RFC7902], where the Extension flag (E) and the Leaf Information Required (L) Flag are already allocated. This document defines the use of 4 bits of this Flags field, and suggests the following allocation to IANA: - bits 3 and 4, forming together the Assisted-Replication Type (T) field - bit 5, called the Broadcast and Multicast (BM) flag - bit 6, called the Unknown (U) flag Bits 5 and 6 are collectively referred to as the Pruned-Flood Lists (PFL) flags. The T field and Pruned-Flood-Lists flags are defined as follows: - T is the Assisted-Replication Type field (2 bits) that defines the AR role of the advertising router: Rabadan, et al. Expires July 29, 2022 [Page 10] Internet-Draft EVPN Optimized IR January 2022 o 00 (decimal 0) = RNVE (non-AR support) o 01 (decimal 1) = AR-REPLICATOR o 10 (decimal 2) = AR-LEAF o 11 (decimal 3) = RESERVED - The Pruned-Flood-Lists flags define the desired behavior of the advertising router for the different types of traffic: o Broadcast and Multicast (BM) flag. BM=1 means "prune-me" from the BM flooding list. BM=0 means regular behavior. o Unknown (U) flag. U=1 means "prune-me" from the Unknown flooding list. U=0 means regular behavior. - Flag L is an existing flag defined in [RFC6514] (L=Leaf Information Required, bit 7) and it will be used only in the Selective AR Solution. Please refer to Section 11 for the IANA considerations related to the PMSI Tunnel Attribute flags. In this document, the above Inclusive Multicast Ethernet Tag route Figure 2 and PMSI Tunnel Attribute Figure 3 can be used in two different modes for the same BD: - Regular-IR route: in this route, Originating Router's IP Address, Tunnel Type (0x06), MPLS Label and Tunnel Identifier MUST be used as described in [RFC7432] when Ingress Replication is in use. The NVE/PE that advertises the route will set the Next-Hop to an IP address that we denominate IR-IP in this document. When advertised by an AR-LEAF node, the Regular-IR route MUST be advertised with type T set to 10 (AR-LEAF). - Replicator-AR route: this route is used by the AR-REPLICATOR to advertise its AR capabilities, with the fields set as follows: o Originating Router's IP Address MUST be set to an IP address of the advertising router that is common to all the EVIs on the PE (usually this is a loopback address of the PE). + The Tunnel Identifier and Next-Hop SHOULD be set to the same IP address as the Originating Router's IP address when the NVE/PE originates the route, that is, when the NVE/PE is not an ASBR as in section 10.2 of [RFC8365]. Irrespective of the values in the Tunnel Identifier and Originating Router's Rabadan, et al. Expires July 29, 2022 [Page 11] Internet-Draft EVPN Optimized IR January 2022 IP Address fields, the ingress NVE/PE will process the received Replicator-AR route and will use the IP Address in the Next-Hop field to create IP tunnels to the AR- REPLICATOR. + The Next-Hop address is referred to as the AR-IP and MUST be different from the IR-IP for a given PE/NVE, unless the procedures in Section 8 are followed. o Tunnel Type MUST be set to Assisted-Replication Tunnel. Section 11 provides the allocated type value. o T (AR role type) MUST be set to 01 (AR-REPLICATOR). o L (Leaf Information Required) MUST be set to 0 (for non- selective AR), and MUST be set to 1 (for selective AR). An NVE/PE configured as AR-REPLICATOR for a BD MUST advertise a Replicator-AR route for the BD and MAY advertise a Regular-IR route. The advertisement of the Replicator-AR route will indicate the AR- LEAFs what outer IP DA, i.e., the AR-IP, they need to use for IP encapsulated BM frames that use Assisted Replication forwarding mode. The AR-REPLICATOR will forward an IP encapsulated BM frame in Assisted Replication forwarding mode if the outer IP DA matches its AR-IP, but will forward in Ingress Replication forwarding mode if the outer IP DA matches its IR-IP. In addition, this document also uses the Leaf Auto-Discovery (Leaf A-D) route defined in [I-D.ietf-bess-evpn-bum-procedure-updates] in case the selective AR mode is used. An AR-LEAF MAY send a Leaf A-D route in response to reception of a Replicator-AR route whose L flag is set. The Leaf Auto-Discovery route is only used for selective AR and the fields of such route are set as follows: o Originating Router's IP Address is set to the advertising router's IP address (same IP used by the AR-LEAF in regular-IR routes). The Next-Hop address is set to the IR-IP, which SHOULD be the same IP address as the advertising router's IP address, when the NVE/PE originates the route, i.e., when the NVE/PE is not an ASBR as in section 10.2 of [RFC8365]. o Route Key is the "Route Type Specific" NLRI of the Replicator- AR route for which this Leaf Auto-Discovery route is generated. o The AR-LEAF constructs an IP-address-specific route-target, analogously to [I-D.ietf-bess-evpn-bum-procedure-updates], by Rabadan, et al. Expires July 29, 2022 [Page 12] Internet-Draft EVPN Optimized IR January 2022 placing the IP address carried in the Next-Hop field of the received Replicator-AR route in the Global Administrator field of the Community, with the Local Administrator field of this Community set to 0, and setting the Extended Communities attribute of the Leaf Auto-Discovery route to that Community. The same IP-address-specific import route-target is auto- configured by the AR-REPLICATOR that sent the Replicator-AR route, in order to control the acceptance of the Leaf Auto- Discovery routes. o The Leaf Auto-Discovery route MUST include the PMSI Tunnel attribute with the Tunnel Type set to AR (Section 11), T (AR role type) set to AR-LEAF and the Tunnel Identifier set to the IP address of the advertising AR-LEAF. The PMSI Tunnel attribute MUST carry a downstream-assigned MPLS label or VNI that is used by the AR-REPLICATOR to send traffic to the AR- LEAF. Each AR-enabled node understands and process the T (Assisted- Replication type) field in the PMSI Tunnel Attribute (Flags field) of the routes, and MUST signal the corresponding type (AR-REPLICATOR or AR-LEAF type) according to its administrative choice. An NVE/PE following this specification is not expected to set the Assisted- Replication Type field to decimal 3 (which is a RESERVED value). If a route with the AR type field set to decimal 3 is received by an AR- REPLICATOR or AR-LEAF, the router will process the route as a Regular-IR route advertised by an RNVE. Each node attached to the BD may understand and process the BM/U flags (Pruned-Flood-Lists flags). Note that these BM/U flags may be used to optimize the delivery of multi-destination traffic and their use SHOULD be an administrative choice, and independent of the AR role. When the Pruned-Flood-List capability is enabled, the BM/U flags can be used with the Regular-IR, Replicator-AR and Leaf Auto- Discovery routes. Non-optimized Ingress Replication NVEs/PEs will be unaware of the new PMSI Tunnel Attribute flag definition as well as the new Tunnel Type (AR), i.e., non-upgraded NVEs/PEs will ignore the information contained in the flags field or an unknown Tunnel Type (type AR in this case) for any Inclusive Multicast Ethernet Tag route. 5. Non-Selective Assisted-Replication (AR) Solution Description Figure 4 illustrates an example Network Virtualization Overlay network where the non-selective AR function is enabled. Three different roles are defined for a given BD: AR-REPLICATOR, AR-LEAF and RNVE (Regular NVE). The solution is called "non-selective" Rabadan, et al. Expires July 29, 2022 [Page 13] Internet-Draft EVPN Optimized IR January 2022 because the chosen AR-REPLICATOR for a given flow MUST replicate the BM traffic to all the NVE/PEs in the BD except for the source NVE/PE. Network Virtualization Overlay tunnels, i.e., IP tunnels, exist among all the PEs and NVEs in the diagram. The PEs and NVEs in the diagram have Tenant Systems or Virtual Machines connected to their Attachment Circuits. ( ) (_ WAN _) +---(_ _)----+ | (_ _) | PE1 | PE2 | +------+----+ +----+------+ TS1--+ (BD-1) | | (BD-1) +--TS2 |REPLICATOR | |REPLICATOR | +--------+--+ +--+--------+ | | +--+----------------+--+ | | | | +----+ VXLAN/nvGRE/MPLSoGRE +----+ | | IP Fabric | | | | | | NVE1 | +-----------+----------+ | NVE3 Hypervisor| TOR | NVE2 |Hypervisor +---------+-+ +-----+-----+ +-+---------+ | (BD-1) | | (BD-1) | | (BD-1) | | LEAF | | RNVE | | LEAF | +--+-----+--+ +--+-----+--+ +--+-----+--+ | | | | | | VM11 VM12 TS3 TS4 VM31 VM32 Figure 4: Non-Selective AR scenario In AR BDs such as BD-1 in the example, BM (Broadcast and Multicast) traffic between two NVEs may follow a different path than unicast traffic. This solution recommends the replication of BM through the AR-REPLICATOR node, whereas unknown/known unicast will be delivered directly from the source node to the destination node without being replicated by any intermediate node. Note that known unicast forwarding is not impacted by this solution, i.e., unknown unicast SHALL follow the same path as known unicast traffic. Rabadan, et al. Expires July 29, 2022 [Page 14] Internet-Draft EVPN Optimized IR January 2022 5.1. Non-selective AR-REPLICATOR Procedures An AR-REPLICATOR is defined as an NVE/PE capable of replicating incoming BM traffic received on an overlay tunnel to other overlay tunnels and local Attachment Circuits. The AR-REPLICATOR signals its role in the control plane and understands where the other roles (AR- LEAF nodes, RNVEs and other AR-REPLICATORs) are located. A given AR- enabled BD service may have zero, one or more AR-REPLICATORs. In our example in Figure 4, PE1 and PE2 are defined as AR-REPLICATORs. The following considerations apply to the AR-REPLICATOR role: a. The AR-REPLICATOR role SHOULD be an administrative choice in any NVE/PE that is part of an AR-enabled BD. This administrative option to enable AR-REPLICATOR capabilities MAY be implemented as a system level option as opposed to as a per-BD option. b. An AR-REPLICATOR MUST advertise a Replicator-AR route and MAY advertise a Regular-IR route. The AR-REPLICATOR MUST NOT generate a Regular-IR route if it does not have local attachment circuits (AC). If the Regular-IR route is advertised, the Assisted-Replication Type field of the Regular-IR route MUST be set to zero. c. The Replicator-AR and Regular-IR routes are generated according to Section 4. The AR-IP and IR-IP are different IP addresses owned by the AR-REPLICATOR. d. When a node defined as AR-REPLICATOR receives a BM packet on an overlay tunnel, it will do a tunnel destination IP address lookup and apply the following procedures: o If the destination IP address is the AR-REPLICATOR IR-IP Address the node will process the packet normally as in [RFC7432]. o If the destination IP address is the AR-REPLICATOR AR-IP Address the node MUST replicate the packet to local Attachment Circuits and overlay tunnels (excluding the overlay tunnel to the source of the packet). When replicating to remote AR- REPLICATORs the tunnel destination IP address will be an IR- IP. That will be an indication for the remote AR-REPLICATOR that it MUST NOT replicate to overlay tunnels. The tunnel source IP address used by the AR-REPLICATOR MUST be its IR-IP when replicating to AR-REPLICATOR or AR-LEAF nodes. An AR-REPLICATOR MUST follow a data path implementation compatible with the following rules: Rabadan, et al. Expires July 29, 2022 [Page 15] Internet-Draft EVPN Optimized IR January 2022 - The AR-REPLICATORs will build a flooding list composed of Attachment Circuits and overlay tunnels to remote nodes in the BD. Some of those overlay tunnels MAY be flagged as non-BM receivers based on the BM flag received from the remote nodes in the BD. - When an AR-REPLICATOR receives a BM packet on an Attachment Circuit, it will forward the BM packet to its flooding list (including local Attachment Circuits and remote NVE/PEs), skipping the non-BM overlay tunnels. - When an AR-REPLICATOR receives a BM packet on an overlay tunnel, it will check the destination IP address of the underlay IP header and: o If the destination IP address matches its IR-IP, the AR- REPLICATOR will skip all the overlay tunnels from the flooding list, i.e. it will only replicate to local Attachment Circuits. This is the regular Ingress Replication behavior described in [RFC7432]. o If the destination IP address matches its AR-IP, the AR- REPLICATOR MUST forward the BM packet to its flooding list (ACs and overlay tunnels) excluding the non-BM overlay tunnels. The AR-REPLICATOR will ensure the traffic is not sent back to the originating AR-LEAF. o If the encapsulation is MPLSoGRE or MPLSoUDP and the received BD label that the AR-REPLICATOR advertised in the Replicator-AR route is not the bottom of the stack, the AR-REPLICATOR MUST copy the all the labels below the BD label and propagate them when forwarding the packet to the egress overlay tunnels. - The AR-REPLICATOR/LEAF nodes will build an Unknown unicast flood- list composed of Attachment Circuits and overlay tunnels to the IR-IP Addresses of the remote nodes in the BD. Some of those overlay tunnels MAY be flagged as non-U (Unknown unicast) receivers based on the U flag received from the remote nodes in the BD. o When an AR-REPLICATOR/LEAF receives an unknown unicast packet on an Attachment Circuit, it will forward the unknown unicast packet to its flood-list, skipping the non-U overlay tunnels. o When an AR-REPLICATOR/LEAF receives an unknown unicast packet on an overlay tunnel, it will forward the unknown unicast packet to its local Attachment Circuits and never to an overlay tunnel. This is the regular Ingress Replication behavior described in [RFC7432]. Rabadan, et al. Expires July 29, 2022 [Page 16] Internet-Draft EVPN Optimized IR January 2022 5.2. Non-Selective AR-LEAF Procedures AR-LEAF is defined as an NVE/PE that - given its poor replication performance - sends all the BM traffic to an AR-REPLICATOR that can replicate the traffic further on its behalf. It MAY signal its AR- LEAF capability in the control plane and understands where the other roles are located (AR-REPLICATOR and RNVEs). A given service can have zero, one or more AR-LEAF nodes. Figure 4 shows NVE1 and NVE3 (both residing in hypervisors) acting as AR-LEAF. The following considerations apply to the AR-LEAF role: a. The AR-LEAF role SHOULD be an administrative choice in any NVE/PE that is part of an AR-enabled BD. This administrative option to enable AR-LEAF capabilities MAY be implemented as a system level option as opposed to as per-BD option. b. In this non-selective AR solution, the AR-LEAF MUST advertise a single Regular-IR inclusive multicast route as in [RFC7432]. The AR-LEAF SHOULD set the Assisted-Replication Type field to AR- LEAF. Note that although this field does not make any difference for the remote nodes when creating an EVPN destination to the AR- LEAF, this field is useful for an easy operation and troubleshooting of the BD. c. In a BD where there are no AR-REPLICATORs due to the AR- REPLICATORs being down or reconfigured, the AR-LEAF MUST use regular Ingress Replication, based on the remote Regular-IR Inclusive Multicast Routes as described in [RFC7432]. This may happen in the following cases: o The AR-LEAF has a list of AR-REPLICATORs for the BD, but it detects that all the AR-REPLICATORs for the BD are down (via next-hop tracking in the IGP or any other detection mechanism). o The AR-LEAF receives updates from all the former AR- REPLICATORs containing a non-REPLICATOR AR type in the Inclusive Multicast Etherner Tag routes. o The AR-LEAF never discovered an AR-REPLICATOR for the BD. d. In a service where there is one or more AR-REPLICATORs (based on the received Replicator-AR routes for the BD), the AR-LEAF can locally select which AR-REPLICATOR it sends the BM traffic to: o A single AR-REPLICATOR MAY be selected for all the BM packets received on the AR-LEAF attachment circuits (ACs) for a given Rabadan, et al. Expires July 29, 2022 [Page 17] Internet-Draft EVPN Optimized IR January 2022 BD. This selection is a local decision and it does not have to match other AR-LEAFs' selections within the same BD. o An AR-LEAF MAY select more than one AR-REPLICATOR and do either per-flow or per-BD load balancing. o In case of a failure of the selected AR-REPLICATOR, another AR-REPLICATOR SHOULD be selected by the AR-LEAF. o When an AR-REPLICATOR is selected for a given flow or BD, the AR-LEAF MUST send all the BM packets targeted to that AR- REPLICATOR using the forwarding information given by the Replicator-AR route for the chosen AR-REPLICATOR, with tunnel type = 0x0A (AR tunnel). The underlay destination IP address MUST be the AR-IP advertised by the AR-REPLICATOR in the Replicator-AR route. o An AR-LEAF MAY change the AR-REPLICATOR(s) selection dynamically, due to an administrative or policy configuration change. o AR-LEAF nodes SHALL send service-level BM control plane packets following regular Ingress Replication procedures. An example would be IGMP, MLD or PIM multicast packets, and in general any packets using link-local scope multicast IPv4 or IPv6 packets. The AR-REPLICATORs MUST NOT replicate these control plane packets to other overlay tunnels since they will use the regular IR-IP Address. e. The use of an AR-REPLICATOR-activation-timer (in seconds, default value is 3) on the AR-LEAF nodes is RECOMMENDED. Upon receiving a new Replicator-AR route where the AR-REPLICATOR is selected, the AR-LEAF will run a timer before programming the new AR- REPLICATOR. In case of a new added AR-REPLICATOR, or in case the AR-REPLICATOR reboots, this timer will give the AR-REPLICATOR some time to program the AR-LEAF nodes before the AR-LEAF sends BM traffic. The AR-REPLICATOR-activation-timer SHOULD be configurable in seconds, and its value account for the time it takes for the AR-LEAF Regular-IR inclusive multicast route to get to the AR-REPLICATOR and be programmed. While the AR-REPLICATOR- activation-time is running, the AR-LEAF node will use regular ingress replication. f. If the AR-LEAF has selected an AR-REPLICATOR, it is a matter of local policy to change to a new preferred AR-REPLICATOR for the existing BM traffic flows. Rabadan, et al. Expires July 29, 2022 [Page 18] Internet-Draft EVPN Optimized IR January 2022 An AR-LEAF MUST follow a data path implementation compatible with the following rules: - The AR-LEAF nodes will build two flood-lists: 1. Flood-list #1 - composed of Attachment Circuits and an AR- REPLICATOR-set of overlay tunnels. The AR-REPLICATOR-set is defined as one or more overlay tunnels to the AR-IP Addresses of the remote AR-REPLICATOR(s) in the BD. The selection of more than one AR-REPLICATOR is described in point d) above and it is a local AR-LEAF decision. 2. Flood-list #2 - composed of Attachment Circuits and overlay tunnels to the remote IR-IP Addresses. - When an AR-LEAF receives a BM packet on an Attachment Circuit, it will check the AR-REPLICATOR-set: o If the AR-REPLICATOR-set is empty, the AR-LEAF MUST send the packet to flood-list #2. o If the AR-REPLICATOR-set is NOT empty, the AR-LEAF MUST send the packet to flood-list #1, where only one of the overlay tunnels of the AR-REPLICATOR-set is used. - When an AR-LEAF receives a BM packet on an overlay tunnel, it will forward the BM packet to its local Attachment Circuits and never to an overlay tunnel. This is the regular Ingress Replication behavior described in [RFC7432]. - AR-LEAF nodes process Unknown unicast traffic in the same way AR- REPLICATORS do, as described in Section 5.1. 5.3. RNVE Procedures RNVE (Regular Network Virtualization Edge node) is defined as an NVE/ PE without AR-REPLICATOR or AR-LEAF capabilities that does Ingress Replication as described in [RFC7432]. The RNVE does not signal any AR role and is unaware of the AR-REPLICATOR/LEAF roles in the BD. The RNVE will ignore the Flags in the Regular-IR routes and will ignore the Replicator-AR routes (due to an unknown tunnel type in the PMSI Tunnel Attribute) and the Leaf Auto-Discovery routes (due to the IP-address-specific route-target). This role provides EVPN with the backwards compatibility required in optimized Ingress Replication BDs. Figure 4 shows NVE2 as RNVE. Rabadan, et al. Expires July 29, 2022 [Page 19] Internet-Draft EVPN Optimized IR January 2022 6. Selective Assisted-Replication (AR) Solution Description Figure 5 is used to describe the selective AR solution. ( ) (_ WAN _) +---(_ _)----+ | (_ _) | PE1 | PE2 | +------+----+ +----+------+ TS1--+ (BD-1) | | (BD-1) +--TS2 |REPLICATOR | |REPLICATOR | +--------+--+ +--+--------+ | | +--+----------------+--+ | | | | +----+ VXLAN/nvGRE/MPLSoGRE +----+ | | IP Fabric | | | | | | NVE1 | +-----------+----------+ | NVE3 Hypervisor| TOR | NVE2 |Hypervisor +---------+-+ +-----+-----+ +-+---------+ | (BD-1) | | (BD-1) | | (BD-1) | | LEAF-set1 | |LEAF-set-1 | |LEAF-set-2 | +--+-----+--+ +--+-----+--+ +--+-----+--+ | | | | | | VM11 VM12 TS3 TS4 VM31 VM32 Figure 5: Selective AR scenario The solution is called "selective" because a given AR-REPLICATOR MUST replicate the BM traffic to only the AR-LEAFs that requested the replication (as opposed to all the AR-LEAF nodes) and MUST replicate the BM traffic to the RNVEs (if there are any). The same AR roles defined in Section 4 are used here, however the procedures are different. The Selective AR procedures create multiple AR-LEAF-sets in the EVPN BD, and build single-hop trees among AR-LEAFs of the same set (AR- LEAF->AR-REPLICATOR->AR-LEAF), and two-hop trees among AR-LEAFs of different sets (AR-LEAF->AR-REPLICATOR->AR-REPLICATOR->AR-LEAF). Compared to the Selective solution, the Non-Selective AR method assumes that all the AR-LEAFs of the BD are in the same set and always creates two-hop trees among AR-LEAFs. While the Selective solution is more efficient than the Non-Selective solution in multi- stage IP fabrics, the trade-off is additional signaling and an additional outer source IP address lookup. Rabadan, et al. Expires July 29, 2022 [Page 20] Internet-Draft EVPN Optimized IR January 2022 The following sub-sections describe the differences in the procedures of AR-REPLICATOR/LEAFs compared to the non-selective AR solution. There is no change on the RNVEs. 6.1. Selective AR-REPLICATOR Procedures In our example in Figure 5, PE1 and PE2 are defined as Selective AR- REPLICATORs. The following considerations apply to the Selective AR- REPLICATOR role: a. The Selective AR-REPLICATOR capability SHOULD be an administrative choice in any NVE/PE that is part of an Assisted- Replication-enabled BD, as the AR role itself. This administrative option MAY be implemented as a system level option as opposed to as a per-BD option. b. Each AR-REPLICATOR will build a list of AR-REPLICATOR, AR-LEAF and RNVE nodes. In spite of the 'Selective' administrative option, an AR-REPLICATOR MUST NOT behave as a Selective AR- REPLICATOR if at least one of the AR-REPLICATORs has the L flag NOT set. If at least one AR-REPLICATOR sends a Replicator-AR route with L=0 (in the BD context), the rest of the AR- REPLICATORs will fall back to non-selective AR mode. c. The Selective AR-REPLICATOR MUST follow the procedures described in Section 5.1, except for the following differences: o The Replicator-AR route MUST include L=1 (Leaf Information Required) in the Replicator-AR route. This flag is used by the AR-REPLICATORs to advertise their 'selective' AR- REPLICATOR capabilities. In addition, the AR-REPLICATOR auto- configures its IP-address-specific import route-target as described in the third bullet of the procedures for Leaf Auto- Discovery route in Section 4. o The AR-REPLICATOR will build a 'selective' AR-LEAF-set with the list of nodes that requested replication to its own AR-IP. For instance, assuming NVE1 and NVE2 advertise a Leaf Auto- Discovery route with PE1's IP-address-specific route-target and NVE3 advertises a Leaf Auto-Discovery route with PE2's IP- address-specific route-target, PE1 will only add NVE1/NVE2 to its selective AR-LEAF-set for BD-1, and exclude NVE3. Likewise, PE2 will only add NVE3 to its selective AR-LEAF-set for BD-1, and exclude NVE1/NVE2. o When a node defined and operating as a Selective AR-REPLICATOR receives a packet on an overlay tunnel, it will do a tunnel destination IP lookup and if the destination IP address is the Rabadan, et al. Expires July 29, 2022 [Page 21] Internet-Draft EVPN Optimized IR January 2022 AR-REPLICATOR AR-IP Address, the node MUST replicate the packet to: + local Attachment Circuits + overlay tunnels in the Selective AR-LEAF-set, excluding the overlay tunnel to the source AR-LEAF. + overlay tunnels to the RNVEs if the tunnel source IP address is the IR-IP of an AR-LEAF. In any other case, the AR-REPLICATOR MUST NOT replicate the BM traffic to remote RNVEs. In other words, only the first-hop selective AR- REPLICATOR will replicate to all the RNVEs. + overlay tunnels to the remote Selective AR-REPLICATORs if the tunnel source IP address (of the encapsulated packet that arrived on the overlay tunnel) is an IR-IP of its own AR-LEAF-set. In any other case, the AR-REPLICATOR MUST NOT replicate the BM traffic to remote AR-REPLICATORs. When doing this replication, the tunnel destination IP address is the AR-IP of the remote Selective AR-REPLICATOR. The tunnel destination IP AR-IP will be an indication for the remote Selective AR-REPLICATOR that the packet needs further replication to its AR-LEAFs. A Selective AR-REPLICATOR data path implementation MUST be compatible with the following rules: - The Selective AR-REPLICATORs will build two flood-lists: 1. Flood-list #1 - composed of Attachment Circuits and overlay tunnels to the remote nodes in the BD, always using the IR-IPs in the tunnel destination IP addresses. 2. Flood-list #2 - composed of Attachment Circuits, a Selective AR-LEAF-set and a Selective AR-REPLICATOR-set, where: + The Selective AR-LEAF-set is composed of the overlay tunnels to the AR-LEAFs that advertise a Leaf Auto- Discovery route for the local AR-REPLICATOR. This set is updated with every Leaf Auto-Discovery route received/ withdrawn from a new AR-LEAF. + The Selective AR-REPLICATOR-set is composed of the overlay tunnels to all the AR-REPLICATORs that send a Replicator-AR route with L=1. The AR-IP addresses are used as tunnel destination IP. Rabadan, et al. Expires July 29, 2022 [Page 22] Internet-Draft EVPN Optimized IR January 2022 - Some of the overlay tunnels in the flood-lists MAY be flagged as non-BM receivers based on the BM flag received from the remote nodes in the routes. - When a Selective AR-REPLICATOR receives a BM packet on an Attachment Circuit, it MUST forward the BM packet to its flood- list #1, skipping the non-BM overlay tunnels. - When a Selective AR-REPLICATOR receives a BM packet on an overlay tunnel, it will check the destination and source IPs of the underlay IP header and: o If the destination IP address matches its AR-IP and the source IP address matches an IP of its own Selective AR-LEAF-set, the AR-REPLICATOR MUST forward the BM packet to its flood-list #2, unless some AR-REPLICATOR within the BD has advertised L=0. In the latter case, the node reverts back to non-selective mode and flood-list #1 MUST be used. Non-BM overlay tunnels are skipped when sending BM packets. o If the destination IP address matches its AR-IP and the source IP address does not match any IP address of its Selective AR- LEAF-set, the AR-REPLICATOR MUST forward the BM packet to flood-list #2 but skipping the AR-REPLICATOR-set. Non-BM overlay tunnels are skipped when sending BM packets. o If the destination IP address matches its IR-IP, the AR- REPLICATOR MUST use flood-list #1 but MUST skip all the overlay tunnels from the flooding list, i.e. it will only replicate to local Attachment Circuits. This is the regular-IR behavior described in [RFC7432]. Non-BM overlay tunnels are skipped when sending BM packets. - In any case, the AR-REPLICATOR ensures the traffic is not sent back to the originating source. If the encapsulation is MPLSoGRE or MPLSoUDP and the received BD label (the label that the AR- REPLICATOR advertised in the Replicator-AR route) is not the bottom of the stack, the AR-REPLICATOR MUST copy the rest of the labels when forwarding them to the egress overlay tunnels. 6.2. Selective AR-LEAF Procedures A Selective AR-LEAF chooses a single Selective AR-REPLICATOR per BD and: - Sends all the BD's BM traffic to that AR-REPLICATOR and Rabadan, et al. Expires July 29, 2022 [Page 23] Internet-Draft EVPN Optimized IR January 2022 - Expects to receive all the BM traffic for a given BD from the same AR-REPLICATOR (except for the BM traffic from the RNVEs, which comes directly from the RNVEs) In the example of Figure 5, we consider NVE1/NVE2/NVE3 as Selective AR-LEAFs. NVE1 selects PE1 as its Selective AR-REPLICATOR. If that is so, NVE1 will send all its BM traffic for BD-1 to PE1. If other AR-LEAF/REPLICATORs send BM traffic, NVE1 will receive that traffic from PE1. These are the differences in the behavior of a Selective AR-LEAF compared to a non-selective AR-LEAF: a. The AR-LEAF role selective capability SHOULD be an administrative choice in any NVE/PE that is part of an Assisted-Replication- enabled BD. This administrative option to enable AR-LEAF capabilities MAY be implemented as a system level option as opposed to as per-BD option. b. The AR-LEAF MAY advertise a Regular-IR route if there are RNVEs in the BD. The Selective AR-LEAF MUST advertise a Leaf Auto- Discovery route after receiving a Replicator-AR route with L=1. It is RECOMMENDED that the Selective AR-LEAF waits for an AR- LEAF-join-wait-timer (in seconds, default value is 3) before sending the Leaf Auto-Discovery route, so that the AR-LEAF can collect all the Replicator-AR routes for the BD before advertising the Leaf Auto-Discovery route. If the Replicator-AR route with L=1 is withdrawn, the corresponding Leaf Auto- Discovery route is withdrawn too. c. In a service where there is more than one Selective AR-REPLICATOR the Selective AR-LEAF MUST locally select a single Selective AR- REPLICATOR for the BD. Once selected: o The Selective AR-LEAF MUST send a Leaf Auto-Discovery route including the Route-key and IP-address-specific route-target of the selected AR-REPLICATOR. o The Selective AR-LEAF MUST send all the BM packets received on the attachment circuits (ACs) for a given BD to that AR- REPLICATOR. o In case of a failure on the selected AR-REPLICATOR (detected when the Replicator-AR route becomes infeasible as the result of any of the underlying BGP mechanisms), another AR- REPLICATOR will be selected and a new Leaf Auto-Discovery update will be issued for the new AR-REPLICATOR. This new route will update the selective list in the new Selective AR- REPLICATOR. In case of failure of the active Selective AR- REPLICATOR, it is RECOMMENDED for the Selective AR-LEAF to Rabadan, et al. Expires July 29, 2022 [Page 24] Internet-Draft EVPN Optimized IR January 2022 revert to Ingress Replication behavior for a timer AR- REPLICATOR-activation-timer (in seconds, default value is 3) to mitigate the traffic impact. When the timer expires, the Selective AR-LEAF will resume its AR mode with the new Selective AR-REPLICATOR. The AR-REPLICATOR-activation-timer MAY be the same configurable parameter as in Section 5.2. o A Selective AR-LEAF MAY change the AR-REPLICATOR(s) selection dynamically, due to an administrative or policy configuration change. All the AR-LEAFs in a BD are expected to be configured as either selective or non-selective. A mix of selective and non-selective AR- LEAFs SHOULD NOT coexist in the same BD. In case there is a non- selective AR-LEAF, its BM traffic sent to a selective AR-REPLICATOR will not be replicated to other AR-LEAFs that are not in its Selective AR-LEAF-set. A Selective AR-LEAF MUST follow a data path implementation compatible with the following rules: - The Selective AR-LEAF nodes will build two flood-lists: 1. Flood-list #1 - composed of Attachment Circuits and the overlay tunnel to the selected AR-REPLICATOR (using the AR-IP as the tunnel destination IP address). 2. Flood-list #2 - composed of Attachment Circuits and overlay tunnels to the remote IR-IP addresses. - Some of the overlay tunnels in the flood-lists MAY be flagged as non-BM receivers based on the BM flag received from the remote nodes in the routes. - When an AR-LEAF receives a BM packet on an Attachment Circuit, it will check if there is any selected AR-REPLICATOR. If there is, flood-list #1 MUST be used. Otherwise, flood-list #2 MUST be used. Non-BM overlay tunnels are skipped when sending BM packets. - When an AR-LEAF receives a BM packet on an overlay tunnel, it MUST forward the BM packet to its local Attachment Circuits and never to an overlay tunnel. This is the regular Ingress Replication behavior described in [RFC7432]. Rabadan, et al. Expires July 29, 2022 [Page 25] Internet-Draft EVPN Optimized IR January 2022 7. Pruned-Flood-Lists (PFL) In addition to AR, the second optimization supported by this solution is the ability for the all the BD nodes to signal Pruned-Flood-Lists (PFL). As described in Section 4, an EVPN node can signal a given value for the BM and U Pruned-Food-Lists flags in the Regular-IR, Replicator-AR or Leaf Auto-Discovery routes, where: - BM is the Broadcast and Multicast flag. BM=1 means "prune-me" from the BM flood-list. BM=0 means regular behavior. - U is the Unknown flag. U=1 means "prune-me" from the Unknown flood-list. U=0 means regular behavior. The ability to signal and process these Pruned-Flood-Lists flags SHOULD be an administrative choice. If a node is configured to process the Pruned-Flood-Lists flags, upon receiving a non-zero Pruned-Flood-Lists flag for a route, the NVE/PE will add the corresponding flag to the created overlay tunnel in the flood-list. When replicating a BM packet in the context of a flood-list, the NVE/ PE will skip the overlay tunnels marked with the flag BM=1, since the NVE/PE at the end of those tunnels are not expecting BM packets. Similarly, when replicating Unknown unicast packets, the NVE/PE will skip the overlay tunnels marked with U=1. An NVE/PE not following this document or not configured for this optimization will ignore any of the received Pruned-Flood-Lists flags. An AR-LEAF or RNVE receiving BUM traffic on an overlay tunnel MUST replicate the traffic to its local Attachment Circuits, regardless of the BM/U flags on the overlay tunnels. This optimization MAY be used along with the Assisted-Replication solution. 7.1. A Pruned-Flood-List Example In order to illustrate the use of the solution described in this document, we will assume that BD-1 in Figure 4 is optimized Ingress Replication enabled and: - PE1 and PE2 are administratively configured as AR-REPLICATORs, due to their high-performance replication capabilities. PE1 and PE2 will send a Replicator-AR route with BM/U flags = 00. - NVE1 and NVE3 are administratively configured as AR-LEAF nodes, due to their low-performance software-based replication capabilities. They will advertise a Regular-IR route with type AR-LEAF. Assuming both NVEs advertise all the attached Virtual Rabadan, et al. Expires July 29, 2022 [Page 26] Internet-Draft EVPN Optimized IR January 2022 Machines MAC and IP addresses in EVPN as soon as they come up, and these NVEs do not have any Virtual Machines interested in multicast applications, they will be configured to signal BM/U flags = 11 for BD-1. That is, neither NVE1 nor NVE3 are interested in receiving BM or Unknown Unicast traffic since: o Their attached VMs (VM11, VM12, VM31, VM32) do not support multicast applications. o Their attached VMs will not receive ARP Requests. Proxy-ARP [I-D.ietf-bess-evpn-proxy-arp-nd] on the remote NVE/PEs will reply ARP Requests locally, and no other Broadcast is expected. o Their attached VMs will not receive unknown unicast traffic, since the VMs' MAC and IP addresses are always advertised by EVPN as long as the VMs are active. - NVE2 is optimized Ingress Replication unaware; therefore it takes on the RNVE role in BD-1. Based on the above assumptions the following forwarding behavior will take place: 1. Any BM packets sent from VM11 will be sent to VM12 and PE1. PE1 will forward further the BM packets to TS1, WAN link, PE2 and NVE2, but not to NVE3. PE2 and NVE2 will replicate the BM packets to their local Attachment Circuits but we will avoid NVE3 having to replicate unnecessarily those BM packets to VM31 and VM32. 2. Any BM packets received on PE2 from the WAN will be sent to PE1 and NVE2, but not to NVE1 and NVE3, sparing the two hypervisors from replicating unnecessarily to their local Virtual Machines. PE1 and NVE2 will replicate to their local Attachment Circuits only. 3. Any Unknown unicast packet sent from VM31 will be forwarded by NVE3 to NVE2, PE1 and PE2 but not NVE1. The solution avoids the unnecessary replication to NVE1, since the destination of the unknown traffic cannot be at NVE1. 4. Any Unknown unicast packet sent from TS1 will be forwarded by PE1 to the WAN link, PE2 and NVE2 but not to NVE1 and NVE3, since the target of the unknown traffic cannot be at those NVEs. Rabadan, et al. Expires July 29, 2022 [Page 27] Internet-Draft EVPN Optimized IR January 2022 8. AR Procedures for Single-IP AR-REPLICATORS The procedures explained in sections Section 5 and Section 6 assume that the AR-REPLICATOR can use two local routable IP addresses to terminate and originate Network Virtualization Overlay tunnels, i.e. IR-IP and AR-IP addresses. This is usually the case for PE-based AR- REPLICATOR nodes. In some cases, the AR-REPLICATOR node does not support more than one IP address to terminate and originate Network Virtualization Overlay tunnels, i.e. the IR-IP and AR-IP are the same IP addresses. This may be the case in some software-based or low-end AR-REPLICATOR nodes. If this is the case, the procedures in sections Section 5 and Section 6 MUST be modified in the following way: - The Replicator-AR routes generated by the AR-REPLICATOR use an AR- IP that will match its IR-IP. In order to differentiate the data plane packets that need to use Ingress Replication from the packets that must use Assisted Replication forwarding mode, the Replicator-AR route MUST advertise a different VNI/VSID than the one used by the Regular-IR route. For instance, the AR-REPLICATOR will advertise AR-VNI along with the Replicator-AR route and IR- VNI along with the Regular-IR route. Since both routes have the same key, different Route Distinguishers are needed in each route. - An AR-REPLICATOR will perform Ingress Replication or Assisted Replication forwarding mode for the incoming Overlay packets based on an ingress VNI lookup, as opposed to the tunnel IP DA lookup. Note that, when replicating to remote AR-REPLICATOR nodes, the use of the IR-VNI or AR-VNI advertised by the egress node will determine the Ingress Replication or Assisted Replication forwarding mode at the subsequent AR-REPLICATOR. The rest of the procedures will follow what is described in sections Section 5 and Section 6. 9. AR Procedures and EVPN All-Active Multi-homing Split-Horizon This section extends the procedures for the cases where two or more AR-LEAF nodes are attached to the same Ethernet Segment, and two or more AR-REPLICATOR nodes are attached to the same Ethernet Segment in the BD. The mixed case, that is, an AR-LEAF node and an AR- REPLICATOR node are attached to the same Ethernet Segment, would require extended procedures and it is out of scope. Rabadan, et al. Expires July 29, 2022 [Page 28] Internet-Draft EVPN Optimized IR January 2022 9.1. Ethernet Segments on AR-LEAF Nodes If VXLAN or NVGRE are used, and if the Split-horizon is based on the tunnel IP Source Address and "Local-Bias" as described in [RFC8365], the Split-horizon check will not work if there is an Ethernet-Segment shared between two AR-LEAF nodes, and the AR-REPLICATOR replaces the tunnel IP Source Address of the packets with its own AR-IP. In order to be compatible with the IP Source Address split-horizon check, the AR-REPLICATOR MAY keep the original received tunnel IP Source Address when replicating packets to a remote AR-LEAF or RNVE. This will allow AR-LEAF nodes to apply Split-horizon check procedures for BM packets, before sending them to the local Ethernet-Segment. Even if the AR-LEAF's IP Source Address is preserved when replicating to AR-LEAFs or RNVEs, the AR-REPLICATOR MUST always use its IR-IP as the IP Source Address when replicating to other AR-REPLICATORs. When EVPN is used for MPLS over GRE (or UDP), the ESI-label based split-horizon procedure as in [RFC7432] will not work for multi-homed Ethernet-Segments defined on AR-LEAF nodes. "Local-Bias" is recommended in this case, as in the case of VXLAN or NVGRE explained above. The "Local-Bias" and tunnel IP Source Address preservation mechanisms provide the required split-horizon behavior in non- selective or selective AR. Note that if the AR-REPLICATOR implementation keeps the received tunnel IP Source Address, the use of uRPF (unicast Reverse Path Forwarding) checks in the IP fabric based on the tunnel IP Source Address MUST be disabled. 9.2. Ethernet Segments on AR-REPLICATOR nodes AR-REPLICATOR nodes attached to the same all-active Ethernet Segment will follow "Local-Bias" procedures [RFC8365], as follows: a. For BUM traffic received on a local AR-REPLICATOR's Attachment Circuit, "Local-Bias" procedures as in [RFC8365] MUST be followed. b. For BUM traffic received on an AR-REPLICATOR overlay tunnel with AR-IP as the IP Destination Address, "Local-Bias" MUST also be followed. That is, traffic received with AR-IP as IP Destination Address will be treated as though it had been received on a local Attachment Circuit that is part of the Ethernet Segment and will be forwarded to all local Ethernet Segments, irrespective of their DF or NDF state. Rabadan, et al. Expires July 29, 2022 [Page 29] Internet-Draft EVPN Optimized IR January 2022 c. BUM traffic received on an AR-REPLICATOR overlay tunnel with IR- IP as the IP Destination Address, will follow regular [RFC8365] "Local-Bias" rules and will not be forwarded to local Ethernet Segments that are shared with the AR-LEAF or AR-REPLICATOR originating the traffic. d. In cases where the AR-REPLICATOR supports a single IP address, the IR-IP and the AR-IP are the same IP address, as discussed in Section 8. The received BUM traffic will be treated as in 'b' above if the received VNI is the AR-VNI, and as in 'c' if the VNI is the IR-VNI. 10. Security Considerations The Security Considerations in [RFC7432] and [RFC8365] apply to this document. The Security Considerations related to the Leaf Auto- Discovery route in [I-D.ietf-bess-evpn-bum-procedure-updates] apply too. In addition, the Assisted-Replication method introduced by this document may bring some new risks for the successful delivery of BM traffic. Unicast traffic is not affected by Assisted-Replication (although Unknown unicast traffic is affected by the Pruned-Flood- Lists procedures). The forwarding of Broadcast and Multicast (BM) traffic is modified, and BM traffic from the AR-LEAF nodes will be attracted by the existence of AR-REPLICATORs in the BD. An AR-LEAF will forward BM traffic to its selected AR-REPLICATOR, therefore an attack on the AR-REPLICATOR could impact the delivery of the BM traffic using that node. Also, an attack on the AR-REPLICATOR and change of the advertised AR type will modify the selection on the AR- LEAF nodes. If no other AR-REPLICATOR is selected, the AR-LEAF nodes will be forced to use Ingress Replication forwarding mode, which will impact on their performance, since the AR-LEAF nodes are usually NVEs/PEs with poor replication performance. This document introduces the ability for the AR-REPLICATOR to forward traffic received on an overlay tunnel to another overlay tunnel. The reader may interpret that this introduces the risk of BM loops. That is, an AR-LEAF receiving a BM encapsulated packet that the AR-LEAF originated in the first place, due to one or two AR-REPLICATORs "looping" the BM traffic back to the AR-LEAF. The procedures in this document prevent these BM loops, since the AR-REPLICATOR will always forward the BM traffic using the correct tunnel IP Destination Address (or correct VNI in case of single-IP AR-REPLICATORs) that instructs the remote nodes how to forward the traffic. This is true in both the Non-Selective and Selective modes defined in this document. However, a wrong implementation of the procedures in this document may lead to those unexpected BM loops. Rabadan, et al. Expires July 29, 2022 [Page 30] Internet-Draft EVPN Optimized IR January 2022 The Selective mode provides a multi-staged replication solution, where a proper configuration of all the AR-REPLICATORs will avoid any issues. A mix of mistakenly configured Selective and Non-Selective AR-REPLICATORs in the same BD could theoretically create packet duplication in some AR-LEAFs, however this document specifies a fall back solution to Non-Selective mode in case the AR-REPLICATORs advertised an inconsistent AR Replication mode. This document allows the AR-REPLICATOR to preserve the tunnel IP Source Address of the AR-LEAF (as an option) when forwarding BM packets from an overlay tunnel to another overlay tunnel. Preserving the AR-LEAF IP Source Address makes the "Local Bias" filtering procedures possible for AR-LEAF nodes that are attached to the same Ethernet Segment. If the AR-REPLICATOR does not preserve the AR-LEAF IP Source Address, AR-LEAF nodes attached to all-active Ethernet Segments will cause packet duplication on the multi-homed CE. The AR-REPLICATOR nodes are, by design, using more bandwidth than [RFC7432] PEs or [RFC8365] NVEs would use. Certain network events or unexpected low performance may exceed the AR-REPLICATOR local bandwidth and cause service disruption. Finally, the use of PFL as in Section 7, should be handled with care. An intentional or unintentional misconfiguration of the BDs on a given leaf node may result in the leaf not receiving the required BM or Unknown unicast traffic. 11. IANA Considerations IANA has allocated the following Border Gateway Protocol (BGP) Parameters: - Allocation in the P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types registry: Value Meaning Reference 0x0A Assisted-Replication Tunnel [This document] - Allocations in the P-Multicast Service Interface (PMSI) Tunnel Attribute Flags registry: Value Name Reference 3-4 Assisted-Replication Type (T) [This document] 5 Broadcast and Multicast (BM) [This document] 6 Unknown (U) [This document] Rabadan, et al. Expires July 29, 2022 [Page 31] Internet-Draft EVPN Optimized IR January 2022 12. Contributors In addition to the names in the front page, the following co-authors also contributed to this document: Wim Henderickx Nokia Kiran Nagaraj Nokia Ravi Shekhar Juniper Networks Nischal Sheth Juniper Networks Aldrin Isaac Juniper Mudassir Tufail Citibank 13. Acknowledgments The authors would like to thank Neil Hart, David Motz, Dai Truong, Thomas Morin, Jeffrey Zhang, Shankar Murthy and Krzysztof Szarkowicz for their valuable feedback and contributions. Also thanks to John Scudder for his thorough review that improved the quality of the document significantly. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, . Rabadan, et al. Expires July 29, 2022 [Page 32] Internet-Draft EVPN Optimized IR January 2022 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [I-D.ietf-bess-evpn-bum-procedure-updates] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- bess-evpn-bum-procedure-updates-14 (work in progress), November 2021. [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags", RFC 7902, DOI 10.17487/RFC7902, June 2016, . [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, . [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, March 2018, . 14.2. Informative References [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, . [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, . Rabadan, et al. Expires July 29, 2022 [Page 33] Internet-Draft EVPN Optimized IR January 2022 [I-D.ietf-bess-evpn-proxy-arp-nd] Rabadan, J., Sathappan, S., Nagaraj, K., Hankins, G., and T. King, "Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks", draft-ietf-bess-evpn-proxy-arp- nd-16 (work in progress), October 2021. Authors' Addresses J. Rabadan (editor) Nokia 777 Middlefield Road Mountain View, CA 94043 USA Email: jorge.rabadan@nokia.com S. Sathappan Nokia Email: senthil.sathappan@nokia.com W. Lin Juniper Networks Email: wlin@juniper.net M. Katiyar Versa Networks Email: mukul@versa-networks.com A. Sajassi Cisco Systems Email: sajassi@cisco.com Rabadan, et al. Expires July 29, 2022 [Page 34] ./draft-ietf-lamps-cmp-updates-23.txt0000644000764400076440000046223114257106354017224 0ustar iustiniustin LAMPS Working Group H. Brockhaus, Ed. Internet-Draft D. von Oheimb Updates: 4210, 5912, 6712 (if approved) Siemens Intended status: Standards Track J. Gray Expires: 31 December 2022 Entrust 29 June 2022 Certificate Management Protocol (CMP) Updates draft-ietf-lamps-cmp-updates-23 Abstract This document contains a set of updates to the syntax and transfer of Certificate Management Protocol (CMP) version 2. This document updates RFC 4210, RFC 5912, and RFC 6712. The aspects of CMP updated in this document are using EnvelopedData instead of EncryptedValue, clarifying the handling of p10cr messages, improving the crypto agility, as well as adding new general message types, extended key usages to identify certificates for use with CMP, and well-known URI path segments. CMP version 3 is introduced to enable signaling support of EnvelopedData instead of EncryptedValue and signaling the use of an explicit hash AlgorithmIdentifier in certConf messages, as far as needed. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 31 December 2022. Brockhaus, et al. Expires 31 December 2022 [Page 1] Internet-Draft CMP Updates June 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Convention and Terminology . . . . . . . . . . . . . . . 4 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. New Section 1.1. - Changes Since RFC 4210 . . . . . . . . 5 2.2. New Section 4.5 - Extended Key Usage . . . . . . . . . . 6 2.3. Update Section 5.1.1. - PKI Message Header . . . . . . . 7 2.4. New Section 5.1.1.3. - CertProfile . . . . . . . . . . . 8 2.5. Update Section 5.1.3.1. - Shared Secret Information . . . 9 2.6. Replace Section 5.1.3.4 - Multiple Protection . . . . . . 9 2.7. Replace Section 5.2.2. - Encrypted Values . . . . . . . . 10 2.8. New Section 5.2.9 - GeneralizedTime . . . . . . . . . . . 12 2.9. Update Section 5.3.4. - Certification Response . . . . . 12 2.10. Update Section 5.3.18. - Certificate Confirmation Content . . . . . . . . . . . . . . . . . . . . . . . . 13 2.11. Update Section 5.3.19.2. - Signing Key Pair Types . . . . 14 2.12. Update Section 5.3.19.3. - Encryption/Key Agreement Key Pair Types . . . . . . . . . . . . . . . . . . . . . . . 14 2.13. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 15 2.14. New Section 5.3.19.14 - CA Certificates . . . . . . . . . 15 2.15. New Section 5.3.19.15 - Root CA Certificate Update . . . 15 2.16. New Section 5.3.19.16 - Certificate Request Template . . 16 2.17. New Section 5.3.19.17 - CRL Update Retrieval . . . . . . 18 2.18. Update Section 5.3.21 - Error Message Content . . . . . . 18 2.19. Replace Section 5.3.22 - Polling Request and Response . . 19 2.20. Update Section 7 - Version Negotiation . . . . . . . . . 24 2.21. Update Section 7.1.1. - Clients Talking to RFC 2510 Servers . . . . . . . . . . . . . . . . . . . . . . . . 25 2.22. Add Section 8.4 - Private Keys for Certificate Signing and CMP Message Protection . . . . . . . . . . . . . . . . . 25 2.23. Add Section 8.5 - Entropy of Random Numbers, Key Pairs, and Shared Secret Information . . . . . . . . . . . . . . . 25 Brockhaus, et al. Expires 31 December 2022 [Page 2] Internet-Draft CMP Updates June 2022 2.24. Add Section 8.6 - Trust Anchor Provisioning Using CMP Messages . . . . . . . . . . . . . . . . . . . . . . . . 26 2.25. Add Section 8.7 - Authorizing requests for certificates with specific EKUs . . . . . . . . . . . . . . . . . . . 27 2.26. Update Appendix B - The Use of Revocation Passphrase . . 27 2.27. Update Appendix C - Request Message Behavioral Clarifications . . . . . . . . . . . . . . . . . . . . . 28 2.28. Update Appendix D.1. - General Rules for Interpretation of These Profiles . . . . . . . . . . . . . . . . . . . . . 29 2.29. Update Appendix D.2. - Algorithm Use Profile . . . . . . 30 2.30. Update Appendix D.4. - Initial Registration/Certification (Basic Authenticated Scheme) . . . . . . . . . . . . . . 30 3. Updates to RFC 6712 - HTTP Transfer for the Certificate Management Protocol (CMP) . . . . . . . . . . . . . . . . 30 3.1. Update Section 1. - Introduction . . . . . . . . . . . . 30 3.2. New Section 1.1. - Changes Since RFC 6712 . . . . . . . . 31 3.3. Replace Section 3.6. - HTTP Request-URI . . . . . . . . . 31 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 5. Security Considerations . . . . . . . . . . . . . . . . . . . 34 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1. Normative References . . . . . . . . . . . . . . . . . . 34 7.2. Informative References . . . . . . . . . . . . . . . . . 36 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 38 A.1. Update to RFC4210 - 1988 ASN.1 Module . . . . . . . . . . 38 A.2. Update to RFC5912 - 2002 ASN.1 Module . . . . . . . . . . 52 Appendix B. History of Changes . . . . . . . . . . . . . . . . . 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 1. Introduction [RFC Editor: Please perform the following substitution. * RFCXXXX --> the assigned numerical RFC value for this draft Please update the following references to associated drafts in progress to reflect their final RFC assignments, if possible: * I-D.ietf-lamps-cmp-algorithms * I-D.ietf-lamps-lightweight-cmp-profile * I-D.ietf-ace-cmpv2-coap-transport ] Brockhaus, et al. Expires 31 December 2022 [Page 3] Internet-Draft CMP Updates June 2022 While using CMP [RFC4210] in industrial and IoT environments and developing the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile] some limitations were identified in the original CMP specification. This document updates RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these limitations. Among others, this document improves the crypto agility of CMP, which means to be flexible to react on future advances in cryptography. This document also introduces new extended key usages to identify CMP endpoints on registration and certification authorities. As the main content of RFC 4210 [RFC4210] and RFC 6712 [RFC6712] stays unchanged, this document lists all sections that are updated, replaced, or added to the current text of the respective RFCs. The authors acknowledge that the style of the document is hard to read because the original RFCs must be read along with this document to get the complete content. The working group decided to use this approach in order to keep the changes to RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to the required minimum. This was meant to speed up the editorial process and to minimize the effort spent on reviewing the whole text of the original documents. 1.1. Convention and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Technical terminology is used in conformance with RFC 4210 [RFC4210], RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words are used: CA: Certification authority, which issues certificates. RA: Registration authority, an optional system component to which a CA delegates certificate management functions such as authorization checks. KGA: Key generation authority, which generates key pairs on behalf of an EE. The KGA could be co-located with an RA or a CA. EE: End entity, a user, device, or service that holds a PKI Brockhaus, et al. Expires 31 December 2022 [Page 4] Internet-Draft CMP Updates June 2022 certificate. An identifier for the EE is given as its subject of the certificate. 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) 2.1. New Section 1.1. - Changes Since RFC 4210 The following subsection describes feature updates to RFC 4210 [RFC4210]. They are always related to the base specification. Hence, references to the original sections in RFC 4210 [RFC4210] are used whenever possible. Insert this section at the end of the current Section 1: 1.1. Changes Since RFC 4210 The following updates are made in this document: * Add new extended key usages for various CMP server types, e.g., registration authority and certification authority, to express the authorization of the entity identified in the certificate containing the respective extended key usage extension to act as the indicated PKI management entity. * Extend the description of multiple protection to cover additional use cases, e.g., batch processing of messages. * Offering EnvelopedData as the preferred choice next to EncryptedValue to better support crypto agility in CMP. Note that according to RFC 4211 [RFC4211] section 2.1. point 9 the use of the EncryptedValue structure has been deprecated in favor of the EnvelopedData structure. RFC 4211 [RFC4211] offers the EncryptedKey structure, a choice of EncryptedValue and EnvelopedData for migration to EnvelopedData. For reasons of completeness and consistency the type EncryptedValue has been exchanged in all occurrences in RFC 4210 [RFC4210]. This includes the protection of centrally generated private keys, encryption of certificates, and protection of revocation passphrases. To properly differentiate the support of EnvelopedData instead of EncryptedValue, the CMP version 3 is introduced in case a transaction is supposed to use EnvelopedData. * Offering an optional hashAlg field in CertStatus supporting confirmation of certificates signed with signature algorithms, e.g., EdDSA, not directly indicating a specific hash algorithm to use to compute the certHash. Brockhaus, et al. Expires 31 December 2022 [Page 5] Internet-Draft CMP Updates June 2022 * Adding new general message types to request CA certificates, a root CA update, a certificate request template, or a CRL update. * Extend the usage of polling to p10cr, certConf, rr, genm, and error messages. * Delete the mandatory algorithm profile in RFC 4210 Appendix D.2 [RFC4210] and refer to CMP Algorithms Section 7 [I-D.ietf-lamps-cmp-algorithms]. 2.2. New Section 4.5 - Extended Key Usage The following subsection introduces a new extended key usage for CMP servers authorized to centrally generate key pairs on behalf of end entities. Insert this section at the end of the current Section 4: 4.5. Extended Key Usage The Extended Key Usage (EKU) extension indicates the purposes for which the certified key pair may be used. It therefore restricts the use of a certificate to specific applications. A CA may want to delegate parts of its duties to other PKI management entities. This section provides a mechanism to both prove this delegation and enable an automated means for checking the authorization of this delegation. Such delegation may also be expressed by other means, e.g., explicit configuration. To offer automatic validation for the delegation of a role by a CA to another entity, the certificates used for CMP message protection or signed data for central key generation MUST be issued by the delegating CA and MUST contain the respective EKUs. This proves the authorization of this entity by the delegating CA to act in the given role as described below. The OIDs to be used for these EKUs are: Brockhaus, et al. Expires 31 December 2022 [Page 6] Internet-Draft CMP Updates June 2022 id-kp-cmcCA OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) 27 } id-kp-cmcRA OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) 28 } id-kp-cmKGA OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) 32 } Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA and a CMC RA. As the functionality of a CA and RA is not specific to using CMC or CMP as the certificate management protocol, these EKUs are re-used by CMP. The meaning of the id-kp-cmKGA EKU is as follows: CMP KGA: CMP Key Generation Authorities are CAs or are identified by the id-kp-cmKGA extended key usage. The CMP KGA knows the private key it generated on behalf of the end entity. This is a very sensitive service and needs specific authorization, which by default is with the CA certificate itself. The CA may delegate its authorization by placing the id-kp-cmKGA extended key usage in the certificate used to authenticate the origin of the generated private key. The authorization may also be determined through local configuration of the end entity. 2.3. Update Section 5.1.1. - PKI Message Header Section 5.1.1 of RFC 4210 [RFC4210] describes the PKI message header. This document introduces the new version 3 indicating support of EnvelopedData as specified in Section 2.7. Replace the ASN.1 Syntax of PKIHeader and the subsequent description of pvno with the following text: Brockhaus, et al. Expires 31 December 2022 [Page 7] Internet-Draft CMP Updates June 2022 PKIHeader ::= SEQUENCE { pvno INTEGER { cmp1999(1), cmp2000(2), cmp2021(3) }, sender GeneralName, recipient GeneralName, messageTime [0] GeneralizedTime OPTIONAL, protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} OPTIONAL, senderKID [2] KeyIdentifier OPTIONAL, recipKID [3] KeyIdentifier OPTIONAL, transactionID [4] OCTET STRING OPTIONAL, senderNonce [5] OCTET STRING OPTIONAL, recipNonce [6] OCTET STRING OPTIONAL, freeText [7] PKIFreeText OPTIONAL, generalInfo [8] SEQUENCE SIZE (1..MAX) OF InfoTypeAndValue OPTIONAL } PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String The usage of pvno values is described in Section 7. 2.4. New Section 5.1.1.3. - CertProfile Section 5.1.1 of RFC 4210 [RFC4210] defines the PKIHeader and id-it OIDs to be used in the generalInfo field. This section introduces id-it-certProfile. Insert this section after Section 5.1.1.2: 5.1.1.3. CertProfile This is used by the EE to indicate specific certificate profiles, e.g., when requesting a new certificate or a certificate request template, see Section 5.3.19.16. id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21} CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF UTF8String When used in an ir/cr/kur/genm, the value MUST NOT contain more elements than the number of CertReqMsg or InfoTypeAndValue elements and the certificate profile names refer to the elements in the given order. When used in a p10cr, the value MUST NOT contain multiple certificate profile names. Brockhaus, et al. Expires 31 December 2022 [Page 8] Internet-Draft CMP Updates June 2022 2.5. Update Section 5.1.3.1. - Shared Secret Information Section 5.1.3.1 of RFC 4210 [RFC4210] describes the MAC based protection of a PKIMessage using the algorithm id-PasswordBasedMac. Replace the first paragraph with the following text: In this case, the sender and recipient share secret information with sufficient entropy (established via out-of-band means or from a previous PKI management operation). PKIProtection will contain a MAC value and the protectionAlg MAY be one of the options described in CMP Algorithms [I-D.ietf-lamps-cmp-algorithms]. The PasswordBasedMac is specified as follows (see also [RFC4211] and [RFC9045]): Replace the last paragraph with the following text (Note: This fixes Errata ID 2616): Note: It is RECOMMENDED that the fields of PBMParameter remain constant throughout the messages of a single transaction (e.g., ir/ip/certConf/pkiConf) to reduce the overhead associated with PasswordBasedMac computation. 2.6. Replace Section 5.1.3.4 - Multiple Protection Section 5.1.3.4 of RFC 4210 [RFC4210] describes the nested message. This document enables using nested messages also for batch-delivery transport of PKI messages between PKI management entities and with mixed body types. Replace the text of the section with the following text: 5.1.3.4. Multiple Protection When receiving a protected PKI message, a PKI management entity such as an RA MAY forward that message adding its own protection (which is a MAC or a signature, depending on the information and certificates shared between the RA and the CA). Additionally, multiple PKI messages MAY be aggregated. There are several use cases for such messages. * The RA confirms having validated and authorized a message and forwards the original message unchanged. * The RA modifies the message(s) in some way (e.g., adds or modifies particular field values or adds new extensions) before forwarding them, then it MAY create its own desired PKIBody. If the changes made by the RA to PKIMessage break the POP of a certificate request, the RA MUST set the popo field to RAVerified. It MAY Brockhaus, et al. Expires 31 December 2022 [Page 9] Internet-Draft CMP Updates June 2022 include the original PKIMessage from the EE in the generalInfo field of PKIHeader of a nested message (to accommodate, for example, cases in which the CA wishes to check POP or other information on the original EE message). The infoType to be used in this situation is {id-it 15} (see Section 5.3.19 for the value of id-it) and the infoValue is PKIMessages (contents MUST be in the same order as the message in PKIBody). * A PKI management entity collects several messages that are to be forwarded in the same direction and forwards them in a batch. Request messages can be transferred as batch upstream (towards the CA); response or announce messages can be transferred as batch downstream (towards an RA, but not to the EE). This can for instance be used when bridging an off-line connection between two PKI management entities. These use cases are accomplished by nesting the messages within a new PKI message. The structure used is as follows: NestedMessageContent ::= PKIMessages 2.7. Replace Section 5.2.2. - Encrypted Values Section 5.2.2 of RFC 4210 [RFC4210] describes the use of EncryptedValue to transport encrypted data. This document extends the encryption of data to preferably use EnvelopedData. Replace the text of the section with the following text: 5.2.2. Encrypted Values Where encrypted data (in this specification, private keys, certificates, or revocation passphrase) are sent in PKI messages, the EncryptedKey data structure is used. EncryptedKey ::= CHOICE { encryptedValue EncryptedValue, -- deprecated envelopedData [0] EnvelopedData } See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and CMS [RFC5652] for EnvelopedData syntax. Using the EncryptedKey data structure offers the choice to either use EncryptedValue (for backward compatibility only) or EnvelopedData. The use of the EncryptedValue structure has been deprecated in favor of the EnvelopedData structure. Therefore, it is RECOMMENDED to use EnvelopedData. Brockhaus, et al. Expires 31 December 2022 [Page 10] Internet-Draft CMP Updates June 2022 Note: The EncryptedKey structure defined in CRMF [RFC4211] is reused here, which makes the update backward compatible. Using the new syntax with the untagged default choice EncryptedValue is bits-on- the-wire compatible with the old syntax. To indicate support for EnvelopedData the pvno cmp2021 has been introduced. Details on the usage of pvno values is described in Section 7. The EncryptedKey data structure is used in CMP to transport a private key, certificate, or revocation passphrase in encrypted form. EnvelopedData is used as follows: * It contains only one RecipientInfo structure because the content is encrypted only for one recipient. * It may contain a private key in the AsymmetricKeyPackage structure as defined in RFC 5958 [RFC5958] wrapped in a SignedData structure as specified in CMS section 5 [RFC5652] and [RFC8933] signed by the Key Generation Authority. * It may contain a certificate or revocation passphrase directly in the encryptedContent field. The content of the EnvelopedData structure, as specified in CMS section 6 [RFC5652], MUST be encrypted using a newly generated symmetric content-encryption key. This content-encryption key MUST be securely provided to the recipient using one of three key management techniques. The choice of the key management technique to be used by the sender depends on the credential available at the recipient: * Recipient's certificate that contains a key usage extension asserting keyAgreement: The content-encryption key will be protected using the key agreement key management technique, as specified in CMS section 6.2.2 [RFC5652]. This is the preferred technique. * Recipient's certificate that contains a key usage extension asserting keyEncipherment: The content-encryption key will be protected using the key transport key management technique, as specified in CMS section 6.2.1 [RFC5652]. * A password or shared secret: The content-encryption key will be protected using the password-based key management technique, as specified in CMS section 6.2.4 [RFC5652]. Brockhaus, et al. Expires 31 December 2022 [Page 11] Internet-Draft CMP Updates June 2022 2.8. New Section 5.2.9 - GeneralizedTime The following subsection point implementers to [RFC5280] regarding usage of GeneralizedTime. Insert this section after Section 5.2.8.4: 5.2.9 GeneralizedTime GeneralizedTime is a standard ASN.1 type and SHALL be used as specified in RFC 5280 Section 4.1.2.5.2 [RFC5280]. 2.9. Update Section 5.3.4. - Certification Response Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification Response. This document updates the syntax by using the parent structure EncryptedKey instead of EncryptedValue as described in Section 2.7 above. Additionally, it clarifies the certReqId to be used in response to a p10cr message. Replace the ASN.1 syntax with the following text (Note: This also fixes Errata ID 3949 and 4078): Brockhaus, et al. Expires 31 December 2022 [Page 12] Internet-Draft CMP Updates June 2022 CertRepMessage ::= SEQUENCE { caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL, response SEQUENCE OF CertResponse } CertResponse ::= SEQUENCE { certReqId INTEGER, status PKIStatusInfo, certifiedKeyPair CertifiedKeyPair OPTIONAL, rspInfo OCTET STRING OPTIONAL -- analogous to the id-regInfo-utf8Pairs string defined -- for regInfo in CertReqMsg [RFC4211] } CertifiedKeyPair ::= SEQUENCE { certOrEncCert CertOrEncCert, privateKey [0] EncryptedKey OPTIONAL, -- see [RFC4211] for comment on encoding publicationInfo [1] PKIPublicationInfo OPTIONAL } CertOrEncCert ::= CHOICE { certificate [0] CMPCertificate, encryptedCert [1] EncryptedKey } Add the following as a new paragraph right after the ASN.1 syntax: A p10cr message contains exactly one CertificationRequestInfo data structure as specified in PKCS#10 [RFC2986] but no certReqId. Therefore, the certReqId in the corresponding certification response (cp) message MUST be set to -1. Add the following as new paragraphs to the end of the section: The use of EncryptedKey is described in Section 5.2.2. Note: To indicate support for EnvelopedData the pvno cmp2021 has been introduced. Details on the usage of different pvno values are described in Section 7. 2.10. Update Section 5.3.18. - Certificate Confirmation Content This section introduces an optional hashAlg field to the CertStatus type used in certConf messages to explicitly specify the hash algorithm for those certificates where no hash algorithm is specified in the signatureAlgorithm field. Brockhaus, et al. Expires 31 December 2022 [Page 13] Internet-Draft CMP Updates June 2022 Replace the ASN.1 Syntax of CertStatus with the following text: CertStatus ::= SEQUENCE { certHash OCTET STRING, certReqId INTEGER, statusInfo PKIStatusInfo OPTIONAL, hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} OPTIONAL } The hashAlg field SHOULD be used only in exceptional cases where the signatureAlgorithm of the certificate to be confirmed does not specify a hash algorithm in the OID or in the parameters. In such cases, e.g., for EdDSA, the hashAlg MUST be used to specify the hash algorithm to be used for calculating the certHash value. Otherwise, the certHash value SHALL be computed using the same hash algorithm as used to create and verify the certificate signature. If hashAlg is used, the CMP version indicated by the certConf message header must be cmp2021(3). 2.11. Update Section 5.3.19.2. - Signing Key Pair Types The following section clarifies the usage of the Signing Key Pair Types on referencing EC curves. Insert this note at the end of Section 5.3.19.2: Note: In case several EC curves are supported, several id-ecPublicKey elements as defined in RFC 5480 [RFC5480] need to be given, one per named curve. 2.12. Update Section 5.3.19.3. - Encryption/Key Agreement Key Pair Types The following section clarifies the use of the Encryption/Key Agreement Key Pair Types on referencing EC curves. Insert this note at the end of Section 5.3.19.3: Note: In case several EC curves are supported, several id-ecPublicKey elements as defined in RFC 5480 [RFC5480]need to be given, one per named curve. Brockhaus, et al. Expires 31 December 2022 [Page 14] Internet-Draft CMP Updates June 2022 2.13. Replace Section 5.3.19.9. - Revocation Passphrase Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of a revocation passphrase for authenticating a later revocation request. This document updates the handling by using the parent structure EncryptedKey instead of EncryptedValue to transport this information as described in Section 2.7 above. Replace the text of the section with the following text: 5.3.19.9. Revocation Passphrase This MAY be used by the EE to send a passphrase to a CA/RA for the purpose of authenticating a later revocation request (in the case that the appropriate signing private key is no longer available to authenticate the request). See Appendix B for further details on the use of this mechanism. GenMsg: {id-it 12}, EncryptedKey GenRep: {id-it 12}, < absent > The use of EncryptedKey is described in Section 5.2.2. 2.14. New Section 5.3.19.14 - CA Certificates The following subsection describes PKI general messages using id-it- caCerts. The intended use is specified in Lightweight CMP Profile Section 4.3 [I-D.ietf-lamps-lightweight-cmp-profile]. Insert this section after Section 5.3.19.13: 2.3.19.14 CA Certificates This MAY be used by the client to get CA certificates. GenMsg: {id-it 17}, < absent > GenRep: {id-it 17}, SEQUENCE SIZE (1..MAX) OF CMPCertificate | < absent > 2.15. New Section 5.3.19.15 - Root CA Certificate Update The following subsection describes PKI general messages using id-it- rootCaCert and id-it-rootCaKeyUpdate. The use is specified in Lightweight CMP Profile Section 4.3 [I-D.ietf-lamps-lightweight-cmp-profile]. Brockhaus, et al. Expires 31 December 2022 [Page 15] Internet-Draft CMP Updates June 2022 Insert this section after new Section 5.3.19.14: 5.3.19.15. Root CA Certificate Update This MAY be used by the client to get an update of a root CA certificate, which is provided in the body of the request message. In contrast to the ckuann message this approach follows the request/ response model. The EE SHOULD reference its current trust anchor in a TrustAnchor structure in the request body, giving the root CA certificate if available, otherwise the public key value of the trust anchor. GenMsg: {id-it 20}, RootCaCertValue | < absent > GenRep: {id-it 18}, RootCaKeyUpdateContent | < absent > RootCaCertValue ::= CMPCertificate RootCaKeyUpdateValue ::= RootCaKeyUpdateContent RootCaKeyUpdateContent ::= SEQUENCE { newWithNew CMPCertificate, newWithOld [0] CMPCertificate OPTIONAL, oldWithNew [1] CMPCertificate OPTIONAL } Note: In contrast to CAKeyUpdAnnContent, this type offers omitting newWithOld and oldWithNew in the GenRep message, depending on the needs of the EE. 2.16. New Section 5.3.19.16 - Certificate Request Template The following subsection introduces the PKI general message using id- it-certReqTemplate. Details are specified in the Lightweight CMP Profile Section 4.3 [I-D.ietf-lamps-lightweight-cmp-profile]. Insert this section after new Section 5.3.19.15: 5.3.19.16. Certificate Request Template This MAY be used by the client to get a template containing requirements for certificate request attributes and extensions. The controls id-regCtrl-algId and id-regCtrl-rsaKeyLen MAY contain details on the types of subject public keys the CA is willing to certify. Brockhaus, et al. Expires 31 December 2022 [Page 16] Internet-Draft CMP Updates June 2022 The id-regCtrl-algId control MAY be used to identify a cryptographic algorithm, see RFC 5280 Section 4.1.2.7 [RFC5280], other than rsaEncryption. The algorithm field SHALL identify a cryptographic algorithm. The contents of the optional parameters field will vary according to the algorithm identified. For example, when the algorithm is set to id-ecPublicKey, the parameters identify the elliptic curve to be used, see [RFC5480]. The id-regCtrl-rsaKeyLen control SHALL be used for algorithm rsaEncryption and SHALL contain the intended modulus bit length of the RSA key. GenMsg: {id-it 19}, < absent > GenRep: {id-it 19}, CertReqTemplateContent | < absent > CertReqTemplateValue ::= CertReqTemplateContent CertReqTemplateContent ::= SEQUENCE { certTemplate CertTemplate, keySpec Controls OPTIONAL } Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue id-regCtrl-algId OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) pkip(5) regCtrl(1) 11 } AlgIdCtrl ::= AlgorithmIdentifier{ALGORITHM, {...}} id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) pkip(5) regCtrl(1) 12 } RsaKeyLenCtrl ::= INTEGER (1..MAX) The CertReqTemplateValue contains the prefilled certTemplate to be used for a future certificate request. The publicKey field in the certTemplate MUST NOT be used. In case the PKI management entity wishes to specify supported public-key algorithms, the keySpec field MUST be used. One AttributeTypeAndValue per supported algorithm or RSA key length MUST be used. Note: The Controls ASN.1 type is defined in CRMF Section 6 [RFC4211] Brockhaus, et al. Expires 31 December 2022 [Page 17] Internet-Draft CMP Updates June 2022 2.17. New Section 5.3.19.17 - CRL Update Retrieval The following subsection introduces the PKI general message using id- it-crlStatusList and id-it-crls. Details are specified in the Lightweight CMP Profile Section 4.3 [I-D.ietf-lamps-lightweight-cmp-profile]. Insert this section after new Section 5.3.19.16: 5.3.19.17. CRL Update Retrieval This MAY be used by the client to get new CRLs, specifying the source of the CRLs and the thisUpdate value of the latest CRL it already has, if available. A CRL source is given either by a DistributionPointName or the GeneralNames of the issuing CA. The DistributionPointName should be treated as an internal pointer to identify a CRL that the server already has and not as a way to ask the server to fetch CRLs from external locations. The server shall provide only those CRLs that are more recent than the ones indicated by the client. GenMsg: {id-it 22}, SEQUENCE SIZE (1..MAX) OF CRLStatus GenRep: {id-it 23}, SEQUENCE SIZE (1..MAX) OF CertificateList | < absent > CRLSource ::= CHOICE { dpn [0] DistributionPointName, issuer [1] GeneralNames } CRLStatus ::= SEQUENCE { source CRLSource, thisUpdate Time OPTIONAL } 2.18. Update Section 5.3.21 - Error Message Content Section 5.3.21 of RFC 4210 [RFC4210] describes the regular use of error messages. This document adds a use by a PKI management entity to initiate delayed delivery in response to certConf, rr, and genm requests and to error messages. Replace the first sentence of the first paragraph with the following one: This data structure MAY be used by EE, CA, or RA to convey error info and by a PKI management entity to initiate delayed delivery of responses. Replace the second paragraph with the following text: Brockhaus, et al. Expires 31 December 2022 [Page 18] Internet-Draft CMP Updates June 2022 This message MAY be generated at any time during a PKI transaction. If the client sends this request, the server MUST respond with a PKIConfirm response, or another ErrorMsg if any part of the header is not valid. In case a PKI management entity sends an error message to the EE with the pKIStatusInfo field containing the status "waiting", the EE will initiate polling as described in Section 5.3.22. Otherwise, both sides MUST treat this message as the end of the transaction (if a transaction is in progress). 2.19. Replace Section 5.3.22 - Polling Request and Response Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling messages are used for ir, cr, and kur messages. This document extends the polling mechanism for outstanding responses to any kind of request message. This update also fixes the inconsistent use of the terms 'rReq' vs. 'pollReq' and 'pRep' vs. 'pollRep'. Replace Section 5.3.22 with following text: This pair of messages is intended to handle scenarios in which the client needs to poll the server to determine the status of an outstanding response (i.e., when the "waiting" PKIStatus has been received). PollReqContent ::= SEQUENCE OF SEQUENCE { certReqId INTEGER } PollRepContent ::= SEQUENCE OF SEQUENCE { certReqId INTEGER, checkAfter INTEGER, -- time in seconds reason PKIFreeText OPTIONAL } In response to an ir, cr, p10cr, or kur request message, polling is initiated with an ip, cp, or kup response message containing status "waiting". For any type of request message, polling can be initiated with an error response messages with status "waiting". The following clauses describe how polling messages are used. It is assumed that multiple certConf messages can be sent during transactions. There will be one sent in response to each ip, cp, or kup that contains a CertStatus for an issued certificate. Brockhaus, et al. Expires 31 December 2022 [Page 19] Internet-Draft CMP Updates June 2022 1 In response to an ip, cp, or kup message, an EE will send a certConf for all issued certificates and expect a PKIconf for each certConf. An EE will send a pollReq message in response to each CertResponse element of an ip, cp, or kup message with status "waiting" and in response to an error message with status "waiting". Its certReqId MUST be either the index of a CertResponse data structure with status "waiting" or -1 referring to the complete response. 2 In response to a pollReq, a CA/RA will return an ip, cp, or kup if one or more of still pending requested certificates are ready or the final response to some other type of request is available; otherwise, it will return a pollRep. 3 If the EE receives a pollRep, it will wait for at least the number of seconds given in the checkAfter field before sending another pollReq. 4 If the EE receives an ip, cp, or kup, then it will be treated in the same way as the initial response; if it receives any other response, then this will be treated as the final response to the original request. The following client-side state machine describes polling for individual CertResponse elements. Brockhaus, et al. Expires 31 December 2022 [Page 20] Internet-Draft CMP Updates June 2022 START | v Send ir | ip v Check status of returned <------------------------+ certs | | | +------------------------>|<------------------+ | | | | | | (issued) v (waiting) | | Add to <----------- Check CertResponse ------> Add to | conf list for each certificate pending list | / | / | (conf list) / (empty conf list) | / ip | / +-----------------+ (empty pending list) / | pollRep END <---- Send certConf Send pollReq---------->Wait | ^ ^ | | | | | +-----------------+ +---------------+ (pending list) In the following exchange, the end entity is enrolling for two certificates in one request. Brockhaus, et al. Expires 31 December 2022 [Page 21] Internet-Draft CMP Updates June 2022 Step End Entity PKI -------------------------------------------------------------------- 1 Format ir 2 -> ir -> 3 Handle ir 4 Manual intervention is required for both certs. 5 <- ip <- 6 Process ip 7 Format pollReq 8 -> pollReq -> 9 Check status of cert requests 10 Certificates not ready 11 Format pollRep 12 <- pollRep <- 13 Wait 14 Format pollReq 15 -> pollReq -> 16 Check status of cert requests 17 One certificate is ready 18 Format ip 19 <- ip <- 20 Handle ip 21 Format certConf 22 -> certConf -> 23 Handle certConf 24 Format ack 25 <- pkiConf <- 26 Format pollReq 27 -> pollReq -> 28 Check status of certificate 29 Certificate is ready 30 Format ip 31 <- ip <- 31 Handle ip 32 Format certConf 33 -> certConf -> 34 Handle certConf 35 Format ack 36 <- pkiConf <- The following client-side state machine describes polling for a complete response message. Brockhaus, et al. Expires 31 December 2022 [Page 22] Internet-Draft CMP Updates June 2022 Start | | Send request | +----------- Receive response ------------+ | | | ip/cp/kup/error with | other | status "waiting" | response | | v | +------> Polling | | | | | | Send pollReq | | | Receive response | | | | | pollRep | other response | +-----------+------------------->+<-------------------+ | v Handle response | v End In the following exchange, the end-entity is sending a general message request, and the response is delayed by the server. Brockhaus, et al. Expires 31 December 2022 [Page 23] Internet-Draft CMP Updates June 2022 Step End Entity PKI -------------------------------------------------------------------- 1 Format genm 2 -> genm -> 3 Handle genm 4 delay in response is necessary 5 Format error message "waiting" with certReqId set to -1 6 <- error <- 7 Process error 8 Format pollReq 9 -> pollReq -> 10 Check status of original request general message response not ready 11 Format pollRep 12 <- pollRep <- 13 Wait 14 Format pollReq 15 -> pollReq -> 16 Check status of original request general message response is ready 17 Format genp 18 <- genp <- 19 Handle genp 2.20. Update Section 7 - Version Negotiation Section 7 of RFC 4210 [RFC4210] describes the use of CMP protocol versions. This document describes the handling of the additional CMP version cmp2021 introduced to indicate support of EnvelopedData and hashAlg. Replace the text of the second paragraph with the following text: If a client knows the protocol version(s) supported by the server (e.g., from a previous PKIMessage exchange or via some out-of-band means), then it MUST send a PKIMessage with the highest version supported by both it and the server. If a client does not know what version(s) the server supports, then it MUST send a PKIMessage using the highest version it supports, with the following exception. Version cmp2021 SHOULD only be used if cmp2021 syntax is needed for the request being sent or for the expected response. Note: Using cmp2000 as the default pvno is done to avoid extra message exchanges for version negotiation and to foster compatibility with cmp2000 implementations. Version cmp2021 syntax is only needed if a message exchange uses hashAlg (in CertStatus) or EnvelopedData. Brockhaus, et al. Expires 31 December 2022 [Page 24] Internet-Draft CMP Updates June 2022 2.21. Update Section 7.1.1. - Clients Talking to RFC 2510 Servers Section 7.1.1 of RFC 4210 [RFC4210] describes the behavior of a client sending a cmp2000 message talking to a cmp1999 server as specified in RFC 2510 [RFC2510]. This document extends the section to clients with any higher version than cmp1999. Replace the first sentence of Section 7.1.1 with the following text: If, after sending a message with a protocol version number higher than cmp1999, a client receives an ErrorMsgContent with a version of cmp1999, then it MUST abort the current transaction. 2.22. Add Section 8.4 - Private Keys for Certificate Signing and CMP Message Protection The following subsection addresses the risk arising from reusing the CA private key for CMP message protection. Insert this section after Section 8.3 (Note: This fixes Errata ID 5731): 8.4. Private Keys for Certificate Signing and CMP Message Protection A CA should not reuse its certificate signing key for other purposes such as protecting CMP responses and TLS connections. This way, exposure to other parts of the system and the number of uses of this particularly critical key is reduced to a minimum. 2.23. Add Section 8.5 - Entropy of Random Numbers, Key Pairs, and Shared Secret Information The following subsection addresses the risk arising from low entropy of random numbers, asymmetric keys, and shared secret information. Insert this section after Section 8.4: 8.5. Entropy of Random Numbers, Key Pairs, and Shared Secret Information Implementations must generate nonces and private keys from random input. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys and to search the resulting small set of possibilities than brute-force searching the whole key space. As an example of predictable random numbers see [CVE-2008-0166]; consequences of low-entropy random numbers are discussed in Mining Brockhaus, et al. Expires 31 December 2022 [Page 25] Internet-Draft CMP Updates June 2022 Your Ps and Qs [MiningPsQs]. The generation of quality random numbers is difficult. ISO/IEC 20543:2019 [ISO.20543-2019], NIST SP 800-90A Rev.1 [NIST.SP.800-90Ar1], BSI AIS 31 V2.0 [AIS31], and others offer valuable guidance in this area. If shared secret information is generated by a cryptographically secure random-number generator (CSRNG) it is safe to assume that the entropy of the shared secret information equals its bit length. If no CSRNG is used, the entropy of a shared secret information depends on the details of the generation process and cannot be measured securely after it has been generated. If user-generated passwords are used as shared secret information, their entropy cannot be measured and are typically insufficient for protected delivery of centrally generated keys or trust anchors. If the entropy of a shared secret information protecting the delivery of a centrally generated key pair is known, it should not be less than the security strength of that key pair; if the shared secret information is re-used for different key pairs, the security of the shared secret information should exceed the security strength of each individual key pair. For the case of a PKI management operation that delivers a new trust anchor (e.g., a root CA certificate) using caPubs or genm (a) that is not concluded in a timely manner or (b) where the shared secret information is re-used for several key management operations, the entropy of the shared secret information, if known, should not be less than the security strength of the trust anchor being managed by the operation. The shared secret information should have an entropy that at least matches the security strength of the key material being managed by the operation. Certain use cases may require shared secret information that may be of a low security strength, e.g., a human generated password. It is RECOMMENDED that such secret information be limited to a single PKI management operation. 2.24. Add Section 8.6 - Trust Anchor Provisioning Using CMP Messages The following subsection addresses the risk arising from in-band provisioning of new trust anchors in a PKI management operation. Insert this section after new Section 8.5: 8.6. Trust Anchor Provisioning Using CMP Messages Brockhaus, et al. Expires 31 December 2022 [Page 26] Internet-Draft CMP Updates June 2022 A provider of trust anchors, which may be an RA involved in configuration management of its clients, MUST NOT include to-be- trusted CA certificates in a CMP message unless the specific deployment scenario can ensure that it is adequate that the receiving EE trusts these certificates, e.g., by loading them into its trust store. Whenever an EE receives in a CMP message, e.g., in the caPubs field of a certificate response or in a general response (genp), a CA certificate for use as a trust anchor, it MUST properly authenticate the message sender with existing trust anchors without requiring new trust anchors included in the message. Additionally, the EE MUST verify that the sender is an authorized source of trust anchors. This authorization is governed by local policy and typically indicated using shared secret information or with a signature-based message protection using a certificate issued by a PKI that is explicitly authorized for this purpose. 2.25. Add Section 8.7 - Authorizing requests for certificates with specific EKUs The following subsection addresses the security considerations to follow when authorizing requests for certificates containing specific EKUs. Insert this section after new Section 8.6: 8.7. Authorizing requests for certificates with specific EKUs When a CA issues a certificate containing extended key usage extensions as defined in Section 4.5, this expresses delegation of an authorization that originally is only with the CA certificate itself. Such delegation is a very sensitive action in a PKI and therefore special care must be taken when approving such certificate requests to ensure that only legitimate entities receive a certificate containing such an EKU. 2.26. Update Appendix B - The Use of Revocation Passphrase Appendix B of RFC 4210 [RFC4210] describes the use of the revocation passphrase. As this document updates RFC 4210 [RFC4210] to utilize the parent structure EncryptedKey instead of EncryptedValue as described in Section 2.7 above, the description is updated accordingly. Replace the first bullet point of this section with the following text: Brockhaus, et al. Expires 31 December 2022 [Page 27] Internet-Draft CMP Updates June 2022 * The OID and value specified in Section 5.3.19.9 MAY be sent in a GenMsg message at any time, or MAY be sent in the generalInfo field of the PKIHeader of any PKIMessage at any time. (In particular, the EncryptedKey structure as described in Section 5.2.2 may be sent in the header of the certConf message that confirms acceptance of certificates requested in an initialization request or certificate request message.) This conveys a revocation passphrase chosen by the entity to the relevant CA/RA. When EnvelopedData is used, this is in the decrypted bytes of encryptedContent field. When EncryptedValue is used, this is in the decrypted bytes of the encValue field. Furthermore, the transfer is accomplished with appropriate confidentiality characteristics. Replace the third bullet point of this section with the following text: * Either the localKeyId attribute of EnvelopedData as specified in RFC 2985 [RFC2985] or the valueHint field of EncryptedValue MAY contain a key identifier (chosen by the entity, along with the passphrase itself) to assist in later retrieval of the correct passphrase (e.g., when the revocation request is constructed by the entity and received by the CA/RA). 2.27. Update Appendix C - Request Message Behavioral Clarifications Appendix C of RFC 4210 [RFC4210] provides clarifications to the request message behavior. As this document updates RFC 4210 [RFC4210] to utilize the parent structure EncryptedKey instead of EncryptedValue as described in Section 2.7 above, the description is updated accordingly. Replace the comment within the ASN.1 syntax coming after the definition of POPOSigningKey with the following text (Note: This fixes Errata ID 2615): Brockhaus, et al. Expires 31 December 2022 [Page 28] Internet-Draft CMP Updates June 2022 -- ********** -- * For the purposes of this specification, the ASN.1 comment -- * given in [RFC4211] pertains not only to certTemplate, but -- * also to the altCertTemplate control. -- ********** -- * The signature (using "algorithmIdentifier") is on the -- * DER-encoded value of poposkInput (i.e., the "value" OCTETs -- * of the POPOSigningKeyInput DER). NOTE: If CertReqMsg -- * certReq certTemplate (or the altCertTemplate control) -- * contains the subject and publicKey values, then poposkInput -- * MUST be omitted and the signature MUST be computed on the -- * DER-encoded value of CertReqMsg certReq (or the DER- -- * encoded value of AltCertTemplate). If -- * certTemplate/altCertTemplate does not contain both the -- * subject and public key values (i.e., if it contains only -- * one of these, or neither), then poposkInput MUST be present -- * and MUST be signed. -- ********** Replace the comment within the ASN.1 syntax coming after the definition of POPOPrivKey with the following text: -- ********** -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with -- * Section 5.2.2 of this specification). Therefore, this -- * document makes the behavioral clarification of specifying -- * that the contents of "thisMessage" MUST be encoded either as -- * "EnvelopedData" or "EncryptedValue" (only for backward -- * compatibility) and then wrapped in a BIT STRING. This -- * allows the necessary conveyance and protection of the -- * private key while maintaining bits-on-the-wire compatibility -- * with RFC4210 and [RFCXXXX]. -- ********** 2.28. Update Appendix D.1. - General Rules for Interpretation of These Profiles Appendix D.1 of RFC 4210 [RFC4210] provides general rules for interpretation of the PKI management messages profiles specified in Appendix D and Appendix E of RFC 4210 [RFC4210]. This document updates a sentence regarding the new protocol version cmp2021. Replace the last sentence of the first paragraph of the section with the following text: Mandatory fields are not mentioned if they have an obvious value (e.g., in this version of these profiles, pvno is always cmp2000). Brockhaus, et al. Expires 31 December 2022 [Page 29] Internet-Draft CMP Updates June 2022 2.29. Update Appendix D.2. - Algorithm Use Profile Appendix D.2 of RFC 4210 [RFC4210] provides a list of algorithms that implementations must support when claiming conformance with PKI Management Message Profiles as specified in CMP Appendix D.2 [RFC4210]. This document redirects to the new algorithm profile as specified in Section 7.1 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms]. Replace the text of the section with the following text: D.2. Algorithm Use Profile For specifications of algorithm identifiers and respective conventions for conforming implementations, please refer to CMP Algorithms Section 7.1 [I-D.ietf-lamps-cmp-algorithms]. 2.30. Update Appendix D.4. - Initial Registration/Certification (Basic Authenticated Scheme) Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ certification scheme. This scheme shall continue using EncryptedValue for backward compatibility reasons. Replace the line specifying protectionAlg of the Initialization Response message with the following text (Note: This fixes Errata ID 5201): protectionAlg MSG_MAC_ALG Replace the comment after the privateKey field of crc[1].certifiedKeyPair in the syntax of the Initialization Response message with the following text: -- see Appendix C, Request Message Behavioral Clarifications -- for backward compatibility reasons, use EncryptedValue 3. Updates to RFC 6712 - HTTP Transfer for the Certificate Management Protocol (CMP) 3.1. Update Section 1. - Introduction To indicate and explain why delayed delivery of all kinds of PKIMessages may be handled at transfer level and/or at CMP level, the introduction of RFC 6712 [RFC6712] is updated. Replace the third paragraph of this section with the following text: Brockhaus, et al. Expires 31 December 2022 [Page 30] Internet-Draft CMP Updates June 2022 In addition to reliable transport, CMP requires connection and error handling from the transfer protocol, which is all covered by HTTP. Additionally, delayed delivery of CMP response messages may be handled at transfer level regardless of the message contents. Since this document extends the polling mechanism specified in the second version of CMP [RFC4210] to cover all types of PKI management transactions, delays detected at application level may also be handled within CMP, using pollReq and pollRep messages. 3.2. New Section 1.1. - Changes Since RFC 6712 The following subsection describes feature updates to RFC 6712 [RFC6712]. They are related to the base specification. Hence, references to the original sections in RFC 6712 [RFC6712] are used whenever possible. Insert this section at the end of the current Section 1: 1.1 Changes Since RFC 6712 The following updates are made in this document: * Introduce the HTTP path '/.well-known/cmp'. * Extend the URI structure. 3.3. Replace Section 3.6. - HTTP Request-URI Section 3.6 of RFC 6712 [RFC6712] specifies the used HTTP URIs. This document introduces the HTTP path '/.well-known/cmp' and extends the URIs. Replace the text of the section with the following text: 3.6. HTTP Request-URI Each CMP server on a PKI management entity supporting HTTP or HTTPS transfer MUST support the use of the path prefix '/.well-known/' as defined in RFC 8615 [RFC8615] and the registered name 'cmp' to ease interworking in a multi-vendor environment. The CMP client needs to be configured with sufficient information to form the CMP server URI. This is at least the authority portion of the URI, e.g., 'www.example.com:80', or the full operation path segment of the PKI management entity. Additionally, OPTIONAL path segments MAY be added after the registered application name as part of the full operation path to provide further distinction. The path segment 'p' followed by an arbitraryLabel could for example Brockhaus, et al. Expires 31 December 2022 [Page 31] Internet-Draft CMP Updates June 2022 support the differentiation of specific CAs or certificate profiles. Further path segments, e.g., as specified in the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile], could indicate PKI management operations using an operationLabel . A valid full CMP URI can look like this: http://www.example.com/.well-known/cmp http://www.example.com/.well-known/cmp/ http://www.example.com/.well-known/cmp/p/ http://www.example.com/.well-known/cmp/p// 4. IANA Considerations This document updates the ASN.1 modules of RFC 4210 Appendix F [RFC4210] and RFC 5912 Section 9 [RFC5912]. The OIDs 99 (id-mod- cmp2021-88) and 100 (id-mod-cmp2021-02) were registered in the SMI Security for PKIX Module Identifier registry to identify the updated ASN.1 modules. This document contains an update to the IANA Consideration sections of [RFC4210] adding this content. In the SMI-numbers registry "SMI Security for PKIX Extended Key Purpose Identifiers (1.3.6.1.5.5.7.3)" (see https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- numbers-1.3.6.1.5.5.7.3) as defined in RFC 7299 [RFC7299] one addition has been performed. One new entry has been added: +=========+=============+============+ | Decimal | Description | References | +=========+=============+============+ | 32 | id-kp-cmKGA | [RFCXXXX] | +---------+-------------+------------+ Table 1: Addition to the PKIX Extended Key Purpose Identifiers Registry In the SMI-numbers registry "SMI Security for PKIX CMP Information Types (1.3.6.1.5.5.7.4)" (see https://www.iana.org/assignments/smi- numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.4) as defined in RFC 7299 [RFC7299] seven additions have been performed. Seven new entries have been added: +=========+=======================+============+ Brockhaus, et al. Expires 31 December 2022 [Page 32] Internet-Draft CMP Updates June 2022 | Decimal | Description | References | +=========+=======================+============+ | 17 | id-it-caCerts | [RFCXXXX] | +---------+-----------------------+------------+ | 18 | id-it-rootCaKeyUpdate | [RFCXXXX] | +---------+-----------------------+------------+ | 19 | id-it-certReqTemplate | [RFCXXXX] | +---------+-----------------------+------------+ | 20 | id-it-rootCaCert | [RFCXXXX] | +---------+-----------------------+------------+ | 21 | id-it-certProfile | [RFCXXXX] | +---------+-----------------------+------------+ | 22 | id-it-crlStatusList | [RFCXXXX] | +---------+-----------------------+------------+ | 23 | id-it-crls | [RFCXXXX] | +---------+-----------------------+------------+ Table 2: Addition to the PKIX CMP Information Types Registry In the SMI-numbers registry "SMI Security for PKIX CRMF Registration Controls (1.3.6.1.5.5.7.5.1)" (see https://www.iana.org/assignments/ smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.5.1) as defined in RFC 7299 [RFC7299] two additions have been performed. Two new entries have been added: +=========+======================+============+ | Decimal | Description | References | +=========+======================+============+ | 11 | id-regCtrl-algId | [RFCXXXX] | +---------+----------------------+------------+ | 12 | id-regCtrl-rsaKeyLen | [RFCXXXX] | +---------+----------------------+------------+ Table 3: Addition to the PKIX CRMF Registration Controls Registry This document contains an update to the IANA Consideration sections of [RFC6712] adding this content. This document defines a new entry with the following content in the "Well-Known URIs" registry (see https://www.iana.org/assignments/ well-known-uris/) as defined in RFC 8615 [RFC8615]. URI Suffix: cmp Change Controller: IETF References: [RFCXXXX] [I-D.ietf-ace-cmpv2-coap-transport] Brockhaus, et al. Expires 31 December 2022 [Page 33] Internet-Draft CMP Updates June 2022 Related Information: CMP has a sub-registry at [https://www.iana.org/assignments/cmp/] This document defines a new protocol registry group entitled "Certificate Management Protocol (CMP)" (at https://www.iana.org/assignments/cmp/) with a new registry "CMP Well- Known URI Path Segments" containing three columns: Path Segment, Description, and Reference. New items can be added using the Specification Required RFC 8615 [RFC8615] process. The initial contents of this registry is: Path Segment: p Description: Indicates that the next path segment specifies, e.g., a CA or certificate profile name References: [RFCXXXX] [I-D.ietf-ace-cmpv2-coap-transport] 5. Security Considerations The security considerations of RFC 4210 [RFC4210] are extended in Section 2.22 to Section 2.24. No security considerations updates of RFC 6712 [RFC6712] were required. 6. Acknowledgements Special thank goes to Jim Schaad for his guidance and the inspiration on structuring and writing this document we got from [RFC6402] which updates CMC. Special thank also goes to Russ Housley, Lijun Liao, Martin Peylo, and Tomas Gustavsson for reviewing and providing valuable suggestions on improving this document. We also thank all reviewers of this document for their valuable feedback. 7. References 7.1. Normative References [I-D.ietf-ace-cmpv2-coap-transport] Sahni, M. and S. Tripathi, "CoAP Transfer for the Certificate Management Protocol", Work in Progress, Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8 November 2021, . [I-D.ietf-lamps-cmp-algorithms] Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, "Certificate Management Protocol (CMP) Algorithms", Work in Progress, Internet-Draft, draft-ietf-lamps-cmp- Brockhaus, et al. Expires 31 December 2022 [Page 34] Internet-Draft CMP Updates June 2022 algorithms-15, 2 June 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure Certificate Management Protocols", RFC 2510, DOI 10.17487/RFC2510, March 1999, . [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, DOI 10.17487/RFC2985, November 2000, . [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, DOI 10.17487/RFC4210, September 2005, . [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . Brockhaus, et al. Expires 31 December 2022 [Page 35] Internet-Draft CMP Updates June 2022 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, . [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, . [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)", RFC 6712, DOI 10.17487/RFC6712, September 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC8933] Housley, R., "Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection", RFC 8933, DOI 10.17487/RFC8933, October 2020, . [RFC9045] Housley, R., "Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 9045, DOI 10.17487/RFC9045, June 2021, . 7.2. Informative References [AIS31] Bundesamt fuer Sicherheit in der Informationstechnik (BSI), Killmann, W., and W. Schindler, "A proposal for: Functionality classes for random number generators, version 2.0", 18 September 2011, Brockhaus, et al. Expires 31 December 2022 [Page 36] Internet-Draft CMP Updates June 2022 . [CVE-2008-0166] National Institute of Science and Technology (NIST), "National Vulnerability Database - CVE-2008-0166", 13 May 2008, . [I-D.ietf-lamps-lightweight-cmp-profile] Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight Certificate Management Protocol (CMP) Profile", Work in Progress, Internet-Draft, draft-ietf-lamps-lightweight- cmp-profile-12, 13 May 2022, . [IEEE.802.1AR_2018] IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE 802.1AR-2018, DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, . [ISO.20543-2019] International Organization for Standardization (ISO), "Information technology -- Security techniques -- Test and analysis methods for random bit generators within ISO/IEC 19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019, October 2019. [MiningPsQs] Security'12: Proceedings of the 21st USENIX conference on Security symposium, Heninger, N., Durumeric, Z., Wustrow, E., and J. A. Halderman, "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", August 2012, . [NIST.SP.800-90Ar1] Barker, Elaine B. and John M. Kelsey, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST NIST SP 800-90Ar1, DOI 10.6028/NIST.SP.800-90Ar1, June 2015, . Brockhaus, et al. Expires 31 December 2022 [Page 37] Internet-Draft CMP Updates June 2022 [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - Cryptographic Token Interface Standard. Version 2.10", December 1999, . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- SHA-1", RFC 2202, DOI 10.17487/RFC2202, September 1997, . [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, . [RFC7299] Housley, R., "Object Identifier Registry for the PKIX Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, . Appendix A. ASN.1 Modules A.1. Update to RFC4210 - 1988 ASN.1 Module This section contains the updated ASN.1 module for [RFC4210]. This module replaces the module in Appendix F of that document. Although a 2002 ASN.1 module is provided, this 1988 ASN.1 module remains the normative module as per the policy of the PKIX working group. PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp2021-88(99)} DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS Certificate, CertificateList, Extensions, Name, Time, AlgorithmIdentifier, id-kp --, UTF8String -- -- if required; otherwise, comment out Brockhaus, et al. Expires 31 December 2022 [Page 38] Internet-Draft CMP Updates June 2022 FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(18)} -- The import of Name is added to define CertificationRequest -- instead of importing it from PKCS#10 [RFC2986] DistributionPointName, GeneralNames, GeneralName, KeyIdentifier FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(19)} CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, CertReqMessages, Controls, AttributeTypeAndValue, id-regCtrl FROM PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005(36)} -- The import of EncryptedKey is added due to the updates made -- in CMP Updates [RFCXXXX]]. EncryptedValue does not need to -- be imported anymore and is therefore removed here. -- see also the behavioral clarifications to CRMF codified in -- Appendix C of this specification EnvelopedData, SignedData, Attribute FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } -- The import of EnvelopedData and SignedData is added due to -- the updates made in CMP Updates [RFCXXXX] -- The import of Attribute is added to define -- CertificationRequest instead of importing it from -- PKCS#10 [RFC2986] ; -- the rest of the module contains locally-defined OIDs and -- constructs CMPCertificate ::= CHOICE { x509v3PKCert Certificate } -- This syntax, while bits-on-the-wire compatible with the -- standard X.509 definition of "Certificate", allows the -- possibility of future certificate types (such as X.509 -- attribute certificates, WAP WTLS certificates, or other kinds -- of certificates) within this certificate management protocol, -- should a need ever arise to support such generality. Those -- implementations that do not foresee a need to ever support Brockhaus, et al. Expires 31 December 2022 [Page 39] Internet-Draft CMP Updates June 2022 -- other certificate types MAY, if they wish, comment out the -- above structure and "un-comment" the following one prior to -- compiling this ASN.1 module. (Note that interoperability -- with implementations that don't do this will be unaffected by -- this change.) -- CMPCertificate ::= Certificate PKIMessage ::= SEQUENCE { header PKIHeader, body PKIBody, protection [0] PKIProtection OPTIONAL, extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL } PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage PKIHeader ::= SEQUENCE { pvno INTEGER { cmp1999(1), cmp2000(2), cmp2021(3) }, sender GeneralName, -- identifies the sender recipient GeneralName, -- identifies the intended recipient messageTime [0] GeneralizedTime OPTIONAL, -- time of production of this message (used when sender -- believes that the transport will be "suitable"; i.e., -- that the time will still be meaningful upon receipt) protectionAlg [1] AlgorithmIdentifier OPTIONAL, -- algorithm used for calculation of protection bits senderKID [2] KeyIdentifier OPTIONAL, recipKID [3] KeyIdentifier OPTIONAL, -- to identify specific keys used for protection transactionID [4] OCTET STRING OPTIONAL, -- identifies the transaction; i.e., this will be the same in -- corresponding request, response, certConf, and PKIConf -- messages senderNonce [5] OCTET STRING OPTIONAL, recipNonce [6] OCTET STRING OPTIONAL, -- nonces used to provide replay protection, senderNonce -- is inserted by the creator of this message; recipNonce -- is a nonce previously inserted in a related message by -- the intended recipient of this message freeText [7] PKIFreeText OPTIONAL, -- this may be used to indicate context-specific instructions -- (this field is intended for human consumption) generalInfo [8] SEQUENCE SIZE (1..MAX) OF Brockhaus, et al. Expires 31 December 2022 [Page 40] Internet-Draft CMP Updates June 2022 InfoTypeAndValue OPTIONAL -- this may be used to convey context-specific information -- (this field not primarily intended for human consumption) } PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String -- text encoded as UTF-8 String [RFC3629] PKIBody ::= CHOICE { -- message-specific body elements ir [0] CertReqMessages, --Initialization Request ip [1] CertRepMessage, --Initialization Response cr [2] CertReqMessages, --Certification Request cp [3] CertRepMessage, --Certification Response p10cr [4] CertificationRequest, --imported from [RFC2986] popdecc [5] POPODecKeyChallContent, --pop Challenge popdecr [6] POPODecKeyRespContent, --pop Response kur [7] CertReqMessages, --Key Update Request kup [8] CertRepMessage, --Key Update Response krr [9] CertReqMessages, --Key Recovery Request krp [10] KeyRecRepContent, --Key Recovery Response rr [11] RevReqContent, --Revocation Request rp [12] RevRepContent, --Revocation Response ccr [13] CertReqMessages, --Cross-Cert. Request ccp [14] CertRepMessage, --Cross-Cert. Response ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. cann [16] CertAnnContent, --Certificate Ann. rann [17] RevAnnContent, --Revocation Ann. crlann [18] CRLAnnContent, --CRL Announcement pkiconf [19] PKIConfirmContent, --Confirmation nested [20] NestedMessageContent, --Nested Message genm [21] GenMsgContent, --General Message genp [22] GenRepContent, --General Response error [23] ErrorMsgContent, --Error Message certConf [24] CertConfirmContent, --Certificate confirm pollReq [25] PollReqContent, --Polling request pollRep [26] PollRepContent --Polling response } PKIProtection ::= BIT STRING ProtectedPart ::= SEQUENCE { header PKIHeader, body PKIBody } id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} PBMParameter ::= SEQUENCE { salt OCTET STRING, Brockhaus, et al. Expires 31 December 2022 [Page 41] Internet-Draft CMP Updates June 2022 -- note: implementations MAY wish to limit acceptable sizes -- of this string to values appropriate for their environment -- in order to reduce the risk of denial-of-service attacks owf AlgorithmIdentifier, -- AlgId for a One-Way Function iterationCount INTEGER, -- number of times the OWF is applied -- note: implementations MAY wish to limit acceptable sizes -- of this integer to values appropriate for their environment -- in order to reduce the risk of denial-of-service attacks mac AlgorithmIdentifier -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], } -- or HMAC [RFC2104, RFC2202]) id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} DHBMParameter ::= SEQUENCE { owf AlgorithmIdentifier, -- AlgId for a One-Way Function mac AlgorithmIdentifier -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], } -- or HMAC [RFC2104, RFC2202]) NestedMessageContent ::= PKIMessages PKIStatus ::= INTEGER { accepted (0), -- you got exactly what you asked for grantedWithMods (1), -- you got something like what you asked for; the -- requester is responsible for ascertaining the differences rejection (2), -- you don't get it, more information elsewhere in the message waiting (3), -- the request body part has not yet been processed; expect to -- hear more later (note: proper handling of this status -- response MAY use the polling req/rep PKIMessages specified -- in Section 5.3.22 of [RFC4210]; alternatively, polling in the -- underlying transport layer MAY have some utility in this -- regard) revocationWarning (4), -- this message contains a warning that a revocation is -- imminent revocationNotification (5), -- notification that a revocation has occurred keyUpdateWarning (6) -- update already done for the oldCertId specified in -- CertReqMsg Brockhaus, et al. Expires 31 December 2022 [Page 42] Internet-Draft CMP Updates June 2022 } PKIFailureInfo ::= BIT STRING { -- since we can fail in more than one way! -- More codes may be added in the future if/when required. badAlg (0), -- unrecognized or unsupported Algorithm Identifier badMessageCheck (1), -- integrity check failed (e.g., signature did not verify) badRequest (2), -- transaction not permitted or supported badTime (3), -- messageTime was not sufficiently close to the system time, -- as defined by local policy badCertId (4), -- no certificate could be found matching the provided criteria badDataFormat (5), -- the data submitted has the wrong format wrongAuthority (6), -- the authority indicated in the request is different from the -- one creating the response token incorrectData (7), -- the requester's data is incorrect (for notary services) missingTimeStamp (8), -- when the timestamp is missing but should be there -- (by policy) badPOP (9), -- the proof-of-possession failed certRevoked (10), -- the certificate has already been revoked certConfirmed (11), -- the certificate has already been confirmed wrongIntegrity (12), -- not valid integrity, password based instead of signature or -- vice versa badRecipientNonce (13), -- not valid recipient nonce, either missing or wrong value timeNotAvailable (14), -- the TSA's time source is not available unacceptedPolicy (15), -- the requested TSA policy is not supported by the TSA. unacceptedExtension (16), -- the requested extension is not supported by the TSA. addInfoNotAvailable (17), -- the additional information requested could not be -- understood or is not available badSenderNonce (18), -- not valid sender nonce, either missing or wrong size Brockhaus, et al. Expires 31 December 2022 [Page 43] Internet-Draft CMP Updates June 2022 badCertTemplate (19), -- not valid cert. template or missing mandatory information signerNotTrusted (20), -- signer of the message unknown or not trusted transactionIdInUse (21), -- the transaction identifier is already in use unsupportedVersion (22), -- the version of the message is not supported notAuthorized (23), -- the sender was not authorized to make the preceding -- request or perform the preceding action systemUnavail (24), -- the request cannot be handled due to system unavailability systemFailure (25), -- the request cannot be handled due to system failure duplicateCertReq (26) -- certificate cannot be issued because a duplicate -- certificate already exists } PKIStatusInfo ::= SEQUENCE { status PKIStatus, statusString PKIFreeText OPTIONAL, failInfo PKIFailureInfo OPTIONAL } OOBCert ::= CMPCertificate OOBCertHash ::= SEQUENCE { hashAlg [0] AlgorithmIdentifier OPTIONAL, certId [1] CertId OPTIONAL, hashVal BIT STRING -- hashVal is calculated over the DER encoding of the -- self-signed certificate with the identifier certID. } POPODecKeyChallContent ::= SEQUENCE OF Challenge -- One Challenge per encryption key certification request (in the -- same order as these requests appear in CertReqMessages). Challenge ::= SEQUENCE { owf AlgorithmIdentifier OPTIONAL, -- MUST be present in the first Challenge; MAY be omitted in -- any subsequent Challenge in POPODecKeyChallContent (if -- omitted, then the owf used in the immediately preceding -- Challenge is to be used). witness OCTET STRING, -- the result of applying the one-way function (owf) to a Brockhaus, et al. Expires 31 December 2022 [Page 44] Internet-Draft CMP Updates June 2022 -- randomly-generated INTEGER, A. [Note that a different -- INTEGER MUST be used for each Challenge.] challenge OCTET STRING -- the encryption (under the public key for which the cert. -- request is being made) of Rand. } -- Added in CMP Updates [RFCXXXX] Rand ::= SEQUENCE { -- Rand is encrypted under the public key to form the challenge -- in POPODecKeyChallContent int INTEGER, -- the randomly-generated INTEGER A (above) sender GeneralName -- the sender's name (as included in PKIHeader) } POPODecKeyRespContent ::= SEQUENCE OF INTEGER -- One INTEGER per encryption key certification request (in the -- same order as these requests appear in CertReqMessages). The -- retrieved INTEGER A (above) is returned to the sender of the -- corresponding Challenge. CertRepMessage ::= SEQUENCE { caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL, response SEQUENCE OF CertResponse } CertificationRequest ::= SEQUENCE { certificationRequestInfo SEQUENCE { version INTEGER, subject Name, subjectPublicKeyInfo SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING }, attributes [0] IMPLICIT SET OF Attribute }, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING } CertResponse ::= SEQUENCE { certReqId INTEGER, -- to match this response with corresponding request (a value -- of -1 is to be used if certReqId is not specified in the -- corresponding request, which can only be a p10cr) status PKIStatusInfo, Brockhaus, et al. Expires 31 December 2022 [Page 45] Internet-Draft CMP Updates June 2022 certifiedKeyPair CertifiedKeyPair OPTIONAL, rspInfo OCTET STRING OPTIONAL -- analogous to the id-regInfo-utf8Pairs string defined -- for regInfo in CertReqMsg [RFC4211] } CertifiedKeyPair ::= SEQUENCE { certOrEncCert CertOrEncCert, privateKey [0] EncryptedKey OPTIONAL, -- see [RFC4211] for comment on encoding -- Changed from Encrypted Value to EncryptedKey as a CHOICE of -- EncryptedValue and EnvelopedData due to the changes made in -- CMP Updates [RFCXXXX] -- Using the choice EncryptedValue is bit-compatible to the -- syntax without this change publicationInfo [1] PKIPublicationInfo OPTIONAL } CertOrEncCert ::= CHOICE { certificate [0] CMPCertificate, encryptedCert [1] EncryptedKey -- Changed from Encrypted Value to EncryptedKey as a CHOICE of -- EncryptedValue and EnvelopedData due to the changes made in -- CMP Updates [RFCXXXX] -- Using the choice EncryptedValue is bit-compatible to the -- syntax without this change } KeyRecRepContent ::= SEQUENCE { status PKIStatusInfo, newSigCert [0] CMPCertificate OPTIONAL, caCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL, keyPairHist [2] SEQUENCE SIZE (1..MAX) OF CertifiedKeyPair OPTIONAL } RevReqContent ::= SEQUENCE OF RevDetails RevDetails ::= SEQUENCE { certDetails CertTemplate, -- allows requester to specify as much as they can about -- the cert. for which revocation is requested -- (e.g., for cases in which serialNumber is not available) crlEntryDetails Extensions OPTIONAL -- requested crlEntryExtensions } Brockhaus, et al. Expires 31 December 2022 [Page 46] Internet-Draft CMP Updates June 2022 RevRepContent ::= SEQUENCE { status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, -- in same order as was sent in RevReqContent revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, -- IDs for which revocation was requested -- (same order as status) crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL -- the resulting CRLs (there may be more than one) } CAKeyUpdAnnContent ::= SEQUENCE { oldWithNew CMPCertificate, -- old pub signed with new priv newWithOld CMPCertificate, -- new pub signed with old priv newWithNew CMPCertificate -- new pub signed with new priv } CertAnnContent ::= CMPCertificate RevAnnContent ::= SEQUENCE { status PKIStatus, certId CertId, willBeRevokedAt GeneralizedTime, badSinceDate GeneralizedTime, crlDetails Extensions OPTIONAL -- extra CRL details (e.g., crl number, reason, location, etc.) } CRLAnnContent ::= SEQUENCE OF CertificateList CertConfirmContent ::= SEQUENCE OF CertStatus CertStatus ::= SEQUENCE { certHash OCTET STRING, -- the hash of the certificate, using the same hash algorithm -- as is used to create and verify the certificate signature certReqId INTEGER, -- to match this confirmation with the corresponding req/rep statusInfo PKIStatusInfo OPTIONAL, hashAlg [0] AlgorithmIdentifier OPTIONAL -- the hash algorithm to use for calculating certHash -- SHOULD NOT be used in all cases where the AlgorithmIdentifier -- of the certificate signature specifies a hash algorithm } PKIConfirmContent ::= NULL Brockhaus, et al. Expires 31 December 2022 [Page 47] Internet-Draft CMP Updates June 2022 -- CertReqTemplateContent, id-regCtrl-algId, id-regCtrl-algId, and -- id-regCtrl-rsaKeyLen were added in CMP Updates [RFCXXXX] CertReqTemplateContent ::= SEQUENCE { certTemplate CertTemplate, -- prefilled certTemplate structure elements -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT -- be used. keySpec Controls OPTIONAL -- MAY be used to specify supported algorithms. -- Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue -- as specified in CRMF (RFC4211) } id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= { id-regCtrl 7 } AltCertTemplate ::= AttributeTypeAndValue -- specifies a template for a certificate other than an X.509v3 -- public-key certificate id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl 11 } AlgIdCtrl ::= AlgorithmIdentifier -- SHALL be used to specify supported algorithms other than RSA id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl 12 } RsaKeyLenCtrl ::= INTEGER (1..MAX) -- SHALL be used to specify supported RSA key lengths -- RootCaKeyUpdateContent, CRLSource, and CRLStatus were added in -- CMP Updates [RFCXXXX] RootCaKeyUpdateContent ::= SEQUENCE { newWithNew CMPCertificate, -- new root CA certificate newWithOld [0] CMPCertificate OPTIONAL, -- X.509 certificate containing the new public root CA key -- signed with the old private root CA key oldWithNew [1] CMPCertificate OPTIONAL -- X.509 certificate containing the old public root CA key -- signed with the new private root CA key } CRLSource ::= CHOICE { dpn [0] DistributionPointName, issuer [1] GeneralNames } CRLStatus ::= SEQUENCE { source CRLSource, thisUpdate Time OPTIONAL } Brockhaus, et al. Expires 31 December 2022 [Page 48] Internet-Draft CMP Updates June 2022 InfoTypeAndValue ::= SEQUENCE { infoType OBJECT IDENTIFIER, infoValue ANY DEFINED BY infoType OPTIONAL } -- Example InfoTypeAndValue contents include, but are not limited -- to, the following (un-comment in this ASN.1 module and use as -- appropriate for a given environment): -- -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} -- CAProtEncCertValue ::= CMPCertificate -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} -- SignKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF -- AlgorithmIdentifier -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} -- EncKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF -- AlgorithmIdentifier -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} -- PreferredSymmAlgValue ::= AlgorithmIdentifier -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} -- CurrentCRLValue ::= CertificateList -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} -- UnsupportedOIDsValue ::= SEQUENCE SIZE (1..MAX) OF -- OBJECT IDENTIFIER -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} -- KeyPairParamReqValue ::= OBJECT IDENTIFIER -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} -- KeyPairParamRepValue ::= AlgorithmIdentifier -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} -- RevPassphraseValue ::= EncryptedKey -- - Changed from Encrypted Value to EncryptedKey as a CHOICE -- - of EncryptedValue and EnvelopedData due to the changes -- - made in CMP Updates [RFCXXXX] -- - Using the choice EncryptedValue is bit-compatible to the -- - syntax without this change -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} -- ImplicitConfirmValue ::= NULL -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} -- ConfirmWaitTimeValue ::= GeneralizedTime -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} -- OrigPKIMessageValue ::= PKIMessages -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} -- SuppLangTagsValue ::= SEQUENCE OF UTF8String -- id-it-caCerts OBJECT IDENTIFIER ::= {id-it 17} -- CaCertsValue ::= SEQUENCE SIZE (1..MAX) OF -- CMPCertificate -- - id-it-caCerts added in CMP Updates [RFCXXXX] Brockhaus, et al. Expires 31 December 2022 [Page 49] Internet-Draft CMP Updates June 2022 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= {id-it 18} -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent -- - id-it-rootCaKeyUpdate added in CMP Updates [RFCXXXX] -- id-it-certReqTemplate OBJECT IDENTIFIER ::= {id-it 19} -- CertReqTemplateValue ::= CertReqTemplateContent -- - id-it-certReqTemplate added in CMP Updates [RFCXXXX] -- id-it-rootCaCert OBJECT IDENTIFIER ::= {id-it 20} -- RootCaCertValue ::= CMPCertificate -- - id-it-rootCaCert added in CMP Updates [RFCXXXX] -- id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21} -- CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF -- UTF8String -- - id-it-certProfile added in CMP Updates [RFCXXXX] -- id-it-crlStatusList OBJECT IDENTIFIER ::= {id-it 22} -- CRLStatusListValue ::= SEQUENCE SIZE (1..MAX) OF -- CRLStatus -- - id-it-crlStatusList added in CMP Updates [RFCXXXX] -- id-it-crls OBJECT IDENTIFIER ::= {id-it 23} -- CRLsValue ::= SEQUENCE SIZE (1..MAX) OF -- CertificateList -- - id-it-crls added in CMP Updates [RFCXXXX] -- -- where -- -- id-pkix OBJECT IDENTIFIER ::= { -- iso(1) identified-organization(3) -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} -- and -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} -- -- -- This construct MAY also be used to define new PKIX Certificate -- Management Protocol request and response messages, or general- -- purpose (e.g., announcement) messages for future needs or for -- specific environments. GenMsgContent ::= SEQUENCE OF InfoTypeAndValue -- May be sent by EE, RA, or CA (depending on message content). -- The OPTIONAL infoValue parameter of InfoTypeAndValue will -- typically be omitted for some of the examples given above. -- The receiver is free to ignore any contained OBJ. IDs that it -- does not recognize. If sent from EE to CA, the empty set -- indicates that the CA may send -- any/all information that it wishes. GenRepContent ::= SEQUENCE OF InfoTypeAndValue -- Receiver MAY ignore any contained OIDs that it does not Brockhaus, et al. Expires 31 December 2022 [Page 50] Internet-Draft CMP Updates June 2022 -- recognize. ErrorMsgContent ::= SEQUENCE { pKIStatusInfo PKIStatusInfo, errorCode INTEGER OPTIONAL, -- implementation-specific error codes errorDetails PKIFreeText OPTIONAL -- implementation-specific error details } PollReqContent ::= SEQUENCE OF SEQUENCE { certReqId INTEGER } PollRepContent ::= SEQUENCE OF SEQUENCE { certReqId INTEGER, checkAfter INTEGER, -- time in seconds reason PKIFreeText OPTIONAL } -- -- Extended Key Usage extension for PKI entities used in CMP -- operations, added due to the changes made in -- CMP Updates [RFCXXXX] -- The EKUs for the CA and RA are reused from CMC as defined in -- [RFC6402] -- -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } -- There is no 1988 ASN.1 module of PKCS#9 available to import the -- syntax of the localKeyId attribute type and value from. Therefore, -- the syntax is added here as needed for the updates made in -- CMP Updates [RFCXXXX] pkcs-9 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9} pkcs-9-at-localKeyId OBJECT IDENTIFIER ::= {pkcs-9 21} LocalKeyIdValue ::= OCTET STRING END -- of CMP module Brockhaus, et al. Expires 31 December 2022 [Page 51] Internet-Draft CMP Updates June 2022 A.2. Update to RFC5912 - 2002 ASN.1 Module This section contains the updated 2002 ASN.1 module for [RFC5912]. This module replaces the module in Section 9 of [RFC5912]. The module contains those changes to the normative ASN.1 module from RFC4210 Appendix F [RFC4210] that were to update to 2002 ASN.1 standard done in [RFC5912] as well as changes made in this document. PKIXCMP-2021 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp2021-02(100) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS AttributeSet{}, SingleAttribute{}, Extensions{}, EXTENSION, ATTRIBUTE FROM PKIX-CommonTypes-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, ALGORITHM, DIGEST-ALGORITHM, MAC-ALGORITHM FROM AlgorithmInformation-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58)} Certificate, CertificateList, Time, id-kp FROM PKIX1Explicit-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} DistributionPointName, GeneralNames, GeneralName, KeyIdentifier FROM PKIX1Implicit-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, CertReqMessages, Controls, RegControlSet, id-regCtrl FROM PKIXCRMF-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005-02(55) } -- The import of EncryptedKey is added due to the updates made -- in CMP Updates [RFCXXXX]. EncryptedValue does not need to -- be imported anymore and is therefore removed here. Brockhaus, et al. Expires 31 December 2022 [Page 52] Internet-Draft CMP Updates June 2022 -- see also the behavioral clarifications to CRMF codified in -- Appendix C of this specification CertificationRequest FROM PKCS-10 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkcs10-2009(69)} -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT -- tags). Alternatively, implementers may directly include -- the [RFC2986] syntax in this module localKeyId FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) modules(0) pkcs-9(1)} -- The import of localKeyId is added due to the updates made in -- CMP Updates [RFCXXXX] EnvelopedData, SignedData FROM CryptographicMessageSyntax-2009 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41)} -- The import of EnvelopedData and SignedData is added due to -- the updates made in CMP Updates [RFCXXXX] ; -- the rest of the module contains locally defined OIDs and -- constructs CMPCertificate ::= CHOICE { x509v3PKCert Certificate, ... } -- This syntax, while bits-on-the-wire compatible with the -- standard X.509 definition of "Certificate", allows the -- possibility of future certificate types (such as X.509 -- attribute certificates, WAP WTLS certificates, or other kinds -- of certificates) within this certificate management protocol, -- should a need ever arise to support such generality. Those -- implementations that do not foresee a need to ever support -- other certificate types MAY, if they wish, comment out the -- above structure and "uncomment" the following one prior to -- compiling this ASN.1 module. (Note that interoperability -- with implementations that don't do this will be unaffected by -- this change.) -- CMPCertificate ::= Certificate PKIMessage ::= SEQUENCE { header PKIHeader, body PKIBody, Brockhaus, et al. Expires 31 December 2022 [Page 53] Internet-Draft CMP Updates June 2022 protection [0] PKIProtection OPTIONAL, extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL } PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage PKIHeader ::= SEQUENCE { pvno INTEGER { cmp1999(1), cmp2000(2), cmp2012(3) }, sender GeneralName, -- identifies the sender recipient GeneralName, -- identifies the intended recipient messageTime [0] GeneralizedTime OPTIONAL, -- time of production of this message (used when sender -- believes that the transport will be "suitable"; i.e., -- that the time will still be meaningful upon receipt) protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} OPTIONAL, -- algorithm used for calculation of protection bits senderKID [2] KeyIdentifier OPTIONAL, recipKID [3] KeyIdentifier OPTIONAL, -- to identify specific keys used for protection transactionID [4] OCTET STRING OPTIONAL, -- identifies the transaction; i.e., this will be the same in -- corresponding request, response, certConf, and PKIConf -- messages senderNonce [5] OCTET STRING OPTIONAL, recipNonce [6] OCTET STRING OPTIONAL, -- nonces used to provide replay protection, senderNonce -- is inserted by the creator of this message; recipNonce -- is a nonce previously inserted in a related message by -- the intended recipient of this message freeText [7] PKIFreeText OPTIONAL, -- this may be used to indicate context-specific instructions -- (this field is intended for human consumption) generalInfo [8] SEQUENCE SIZE (1..MAX) OF InfoTypeAndValue OPTIONAL -- this may be used to convey context-specific information -- (this field not primarily intended for human consumption) } PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String -- text encoded as UTF-8 String [RFC3629] PKIBody ::= CHOICE { -- message-specific body elements ir [0] CertReqMessages, --Initialization Request ip [1] CertRepMessage, --Initialization Response Brockhaus, et al. Expires 31 December 2022 [Page 54] Internet-Draft CMP Updates June 2022 cr [2] CertReqMessages, --Certification Request cp [3] CertRepMessage, --Certification Response p10cr [4] CertificationRequest, --imported from [RFC2986] popdecc [5] POPODecKeyChallContent, --pop Challenge popdecr [6] POPODecKeyRespContent, --pop Response kur [7] CertReqMessages, --Key Update Request kup [8] CertRepMessage, --Key Update Response krr [9] CertReqMessages, --Key Recovery Request krp [10] KeyRecRepContent, --Key Recovery Response rr [11] RevReqContent, --Revocation Request rp [12] RevRepContent, --Revocation Response ccr [13] CertReqMessages, --Cross-Cert. Request ccp [14] CertRepMessage, --Cross-Cert. Response ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. cann [16] CertAnnContent, --Certificate Ann. rann [17] RevAnnContent, --Revocation Ann. crlann [18] CRLAnnContent, --CRL Announcement pkiconf [19] PKIConfirmContent, --Confirmation nested [20] NestedMessageContent, --Nested Message genm [21] GenMsgContent, --General Message genp [22] GenRepContent, --General Response error [23] ErrorMsgContent, --Error Message certConf [24] CertConfirmContent, --Certificate confirm pollReq [25] PollReqContent, --Polling request pollRep [26] PollRepContent --Polling response } PKIProtection ::= BIT STRING ProtectedPart ::= SEQUENCE { header PKIHeader, body PKIBody } id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840) nt(113533) nsn(7) algorithms(66) 13 } PBMParameter ::= SEQUENCE { salt OCTET STRING, -- note: implementations MAY wish to limit acceptable sizes -- of this string to values appropriate for their environment -- in order to reduce the risk of denial-of-service attacks owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, -- AlgId for a One-Way Function iterationCount INTEGER, -- number of times the OWF is applied -- note: implementations MAY wish to limit acceptable sizes -- of this integer to values appropriate for their environment -- in order to reduce the risk of denial-of-service attacks mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} Brockhaus, et al. Expires 31 December 2022 [Page 55] Internet-Draft CMP Updates June 2022 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], -- or HMAC [RFC2104, RFC2202]) } id-DHBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840) nt(113533) nsn(7) algorithms(66) 30 } DHBMParameter ::= SEQUENCE { owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, -- AlgId for a One-Way Function mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], -- or HMAC [RFC2104, RFC2202]) } PKIStatus ::= INTEGER { accepted (0), -- you got exactly what you asked for grantedWithMods (1), -- you got something like what you asked for; the -- requester is responsible for ascertaining the differences rejection (2), -- you don't get it, more information elsewhere in the message waiting (3), -- the request body part has not yet been processed; expect to -- hear more later (note: proper handling of this status -- response MAY use the polling req/rep PKIMessages specified -- in Section 5.3.22 of [RFC4210]; alternatively, polling in the -- underlying transport layer MAY have some utility in this -- regard) revocationWarning (4), -- this message contains a warning that a revocation is -- imminent revocationNotification (5), -- notification that a revocation has occurred keyUpdateWarning (6) -- update already done for the oldCertId specified in -- CertReqMsg } PKIFailureInfo ::= BIT STRING { -- since we can fail in more than one way! -- More codes may be added in the future if/when required. badAlg (0), -- unrecognized or unsupported Algorithm Identifier badMessageCheck (1), -- integrity check failed (e.g., signature did not verify) badRequest (2), -- transaction not permitted or supported Brockhaus, et al. Expires 31 December 2022 [Page 56] Internet-Draft CMP Updates June 2022 badTime (3), -- messageTime was not sufficiently close to the system time, -- as defined by local policy badCertId (4), -- no certificate could be found matching the provided criteria badDataFormat (5), -- the data submitted has the wrong format wrongAuthority (6), -- the authority indicated in the request is different from the -- one creating the response token incorrectData (7), -- the requester's data is incorrect (for notary services) missingTimeStamp (8), -- when the timestamp is missing but should be there -- (by policy) badPOP (9), -- the proof-of-possession failed certRevoked (10), -- the certificate has already been revoked certConfirmed (11), -- the certificate has already been confirmed wrongIntegrity (12), -- not valid integrity, password based instead of signature or -- vice versa badRecipientNonce (13), -- not valid recipient nonce, either missing or wrong value timeNotAvailable (14), -- the TSA's time source is not available unacceptedPolicy (15), -- the requested TSA policy is not supported by the TSA unacceptedExtension (16), -- the requested extension is not supported by the TSA addInfoNotAvailable (17), -- the additional information requested could not be -- understood or is not available badSenderNonce (18), -- not valid sender nonce, either missing or wrong size badCertTemplate (19), -- not valid cert. template or missing mandatory information signerNotTrusted (20), -- signer of the message unknown or not trusted transactionIdInUse (21), -- the transaction identifier is already in use unsupportedVersion (22), -- the version of the message is not supported notAuthorized (23), -- the sender was not authorized to make the preceding -- request or perform the preceding action Brockhaus, et al. Expires 31 December 2022 [Page 57] Internet-Draft CMP Updates June 2022 systemUnavail (24), -- the request cannot be handled due to system unavailability systemFailure (25), -- the request cannot be handled due to system failure duplicateCertReq (26) -- certificate cannot be issued because a duplicate -- certificate already exists } PKIStatusInfo ::= SEQUENCE { status PKIStatus, statusString PKIFreeText OPTIONAL, failInfo PKIFailureInfo OPTIONAL } OOBCert ::= CMPCertificate OOBCertHash ::= SEQUENCE { hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} OPTIONAL, certId [1] CertId OPTIONAL, hashVal BIT STRING -- hashVal is calculated over the DER encoding of the -- self-signed certificate with the identifier certID. } POPODecKeyChallContent ::= SEQUENCE OF Challenge -- One Challenge per encryption key certification request (in the -- same order as these requests appear in CertReqMessages). Challenge ::= SEQUENCE { owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} OPTIONAL, -- MUST be present in the first Challenge; MAY be omitted in -- any subsequent Challenge in POPODecKeyChallContent (if -- omitted, then the owf used in the immediately preceding -- Challenge is to be used). witness OCTET STRING, -- the result of applying the one-way function (owf) to a -- randomly-generated INTEGER, A. [Note that a different -- INTEGER MUST be used for each Challenge.] challenge OCTET STRING -- the encryption (under the public key for which the cert. -- request is being made) of Rand. } -- Added in CMP Updates [RFCXXXX] Rand ::= SEQUENCE { Brockhaus, et al. Expires 31 December 2022 [Page 58] Internet-Draft CMP Updates June 2022 -- Rand is encrypted under the public key to form the challenge -- in POPODecKeyChallContent int INTEGER, -- the randomly-generated INTEGER A (above) sender GeneralName -- the sender's name (as included in PKIHeader) } POPODecKeyRespContent ::= SEQUENCE OF INTEGER -- One INTEGER per encryption key certification request (in the -- same order as these requests appear in CertReqMessages). The -- retrieved INTEGER A (above) is returned to the sender of the -- corresponding Challenge. CertRepMessage ::= SEQUENCE { caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL, response SEQUENCE OF CertResponse } CertResponse ::= SEQUENCE { certReqId INTEGER, -- to match this response with the corresponding request (a value -- of -1 is to be used if certReqId is not specified in the -- corresponding request, which can only be a p10cr) status PKIStatusInfo, certifiedKeyPair CertifiedKeyPair OPTIONAL, rspInfo OCTET STRING OPTIONAL -- analogous to the id-regInfo-utf8Pairs string defined -- for regInfo in CertReqMsg [RFC4211] } CertifiedKeyPair ::= SEQUENCE { certOrEncCert CertOrEncCert, privateKey [0] EncryptedKey OPTIONAL, -- see [RFC4211] for comment on encoding -- Changed from Encrypted Value to EncryptedKey as a CHOICE of -- EncryptedValue and EnvelopedData due to the changes made in -- CMP Updates [RFCXXXX] -- Using the choice EncryptedValue is bit-compatible to the -- syntax without this change publicationInfo [1] PKIPublicationInfo OPTIONAL } CertOrEncCert ::= CHOICE { certificate [0] CMPCertificate, encryptedCert [1] EncryptedKey -- Changed from Encrypted Value to EncryptedKey as a CHOICE of -- EncryptedValue and EnvelopedData due to the changes made in -- CMP Updates [RFCXXXX] Brockhaus, et al. Expires 31 December 2022 [Page 59] Internet-Draft CMP Updates June 2022 -- Using the choice EncryptedValue is bit-compatible to the -- syntax without this change } KeyRecRepContent ::= SEQUENCE { status PKIStatusInfo, newSigCert [0] CMPCertificate OPTIONAL, caCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate OPTIONAL, keyPairHist [2] SEQUENCE SIZE (1..MAX) OF CertifiedKeyPair OPTIONAL } RevReqContent ::= SEQUENCE OF RevDetails RevDetails ::= SEQUENCE { certDetails CertTemplate, -- allows requester to specify as much as they can about -- the cert. for which revocation is requested -- (e.g., for cases in which serialNumber is not available) crlEntryDetails Extensions{{...}} OPTIONAL -- requested crlEntryExtensions } RevRepContent ::= SEQUENCE { status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, -- in same order as was sent in RevReqContent revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, -- IDs for which revocation was requested -- (same order as status) crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL -- the resulting CRLs (there may be more than one) } CAKeyUpdAnnContent ::= SEQUENCE { oldWithNew CMPCertificate, -- old pub signed with new priv newWithOld CMPCertificate, -- new pub signed with old priv newWithNew CMPCertificate -- new pub signed with new priv } CertAnnContent ::= CMPCertificate RevAnnContent ::= SEQUENCE { status PKIStatus, certId CertId, willBeRevokedAt GeneralizedTime, badSinceDate GeneralizedTime, crlDetails Extensions{{...}} OPTIONAL -- extra CRL details (e.g., crl number, reason, location, etc.) Brockhaus, et al. Expires 31 December 2022 [Page 60] Internet-Draft CMP Updates June 2022 } CRLAnnContent ::= SEQUENCE OF CertificateList PKIConfirmContent ::= NULL NestedMessageContent ::= PKIMessages -- CertReqTemplateContent, AttributeTypeAndValue, -- ExpandedRegControlSet, id-regCtrl-altCertTemplate, -- AltCertTemplate, regCtrl-algId, id-regCtrl-algId, AlgIdCtrl, -- regCtrl-rsaKeyLen, id-regCtrl-rsaKeyLen, and RsaKeyLenCtrl -- were added in CMP Updates [RFCXXXX] CertReqTemplateContent ::= SEQUENCE { certTemplate CertTemplate, -- prefilled certTemplate structure elements -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT -- be used. keySpec Controls OPTIONAL -- MAY be used to specify supported algorithms. -- Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue -- as specified in CRMF (RFC4211) } AttributeTypeAndValue ::= SingleAttribute{{ ... }} ExpandedRegControlSet ATTRIBUTE ::= { RegControlSet | regCtrl-altCertTemplate | regCtrl-algId | regCtrl-rsaKeyLen, ... } regCtrl-altCertTemplate ATTRIBUTE ::= { TYPE AltCertTemplate IDENTIFIED BY id-regCtrl-altCertTemplate } id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= { id-regCtrl 7 } AltCertTemplate ::= AttributeTypeAndValue -- specifies a template for a certificate other than an X.509v3 -- public-key certificate regCtrl-algId ATTRIBUTE ::= { TYPE AlgIdCtrl IDENTIFIED BY id-regCtrl-algId } id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl 11 } AlgIdCtrl ::= AlgorithmIdentifier{ALGORITHM, {...}} -- SHALL be used to specify supported algorithms other than RSA regCtrl-rsaKeyLen ATTRIBUTE ::= { TYPE RsaKeyLenCtrl IDENTIFIED BY id-regCtrl-rsaKeyLen } Brockhaus, et al. Expires 31 December 2022 [Page 61] Internet-Draft CMP Updates June 2022 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl 12 } RsaKeyLenCtrl ::= INTEGER (1..MAX) -- SHALL be used to specify supported RSA key lengths -- RootCaKeyUpdateContent, CRLSource, and CRLStatus were added in -- CMP Updates [RFCXXXX] RootCaKeyUpdateContent ::= SEQUENCE { newWithNew CMPCertificate, -- new root CA certificate newWithOld [0] CMPCertificate OPTIONAL, -- X.509 certificate containing the new public root CA key -- signed with the old private root CA key oldWithNew [1] CMPCertificate OPTIONAL -- X.509 certificate containing the old public root CA key -- signed with the new private root CA key } CRLSource ::= CHOICE { dpn [0] DistributionPointName, issuer [1] GeneralNames } CRLStatus ::= SEQUENCE { source CRLSource, thisUpdate Time OPTIONAL } INFO-TYPE-AND-VALUE ::= TYPE-IDENTIFIER InfoTypeAndValue ::= SEQUENCE { infoType INFO-TYPE-AND-VALUE. &id({SupportedInfoSet}), infoValue INFO-TYPE-AND-VALUE. &Type({SupportedInfoSet}{@infoType}) } SupportedInfoSet INFO-TYPE-AND-VALUE ::= { ... } -- Example InfoTypeAndValue contents include, but are not limited -- to, the following (uncomment in this ASN.1 module and use as -- appropriate for a given environment): -- -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} -- CAProtEncCertValue ::= CMPCertificate -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} -- SignKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF -- AlgorithmIdentifier{{...}} -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} -- EncKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF Brockhaus, et al. Expires 31 December 2022 [Page 62] Internet-Draft CMP Updates June 2022 -- AlgorithmIdentifier{{...}} -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} -- PreferredSymmAlgValue ::= AlgorithmIdentifier{{...}} -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} -- CurrentCRLValue ::= CertificateList -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} -- UnsupportedOIDsValue ::= SEQUENCE SIZE (1..MAX) OF -- OBJECT IDENTIFIER -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} -- KeyPairParamReqValue ::= OBJECT IDENTIFIER -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} -- KeyPairParamRepValue ::= AlgorithmIdentifier{{...}} -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} -- RevPassphraseValue ::= EncryptedKey -- - Changed from Encrypted Value to EncryptedKey as a CHOICE -- - of EncryptedValue and EnvelopedData due to the changes -- - made in CMP Updates [RFCXXXX] -- - Using the choice EncryptedValue is bit-compatible to -- - the syntax without this change -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} -- ImplicitConfirmValue ::= NULL -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} -- ConfirmWaitTimeValue ::= GeneralizedTime -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} -- OrigPKIMessageValue ::= PKIMessages -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} -- SuppLangTagsValue ::= SEQUENCE OF UTF8String -- id-it-caCerts OBJECT IDENTIFIER ::= {id-it 17} -- CaCertsValue ::= SEQUENCE SIZE (1..MAX) OF -- CMPCertificate -- - id-it-caCerts added in CMP Updates [RFCXXXX] -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= {id-it 18} -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent -- - id-it-rootCaKeyUpdate added in CMP Updates [RFCXXXX] -- id-it-certReqTemplate OBJECT IDENTIFIER ::= {id-it 19} -- CertReqTemplateValue ::= CertReqTemplateContent -- - id-it-certReqTemplate added in CMP Updates [RFCXXXX] -- id-it-rootCaCert OBJECT IDENTIFIER ::= {id-it 20} -- RootCaCertValue ::= CMPCertificate -- - id-it-rootCaCert added in CMP Updates [RFCXXXX] -- id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21} -- CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF -- UTF8String -- - id-it-certProfile added in CMP Updates [RFCXXXX] -- id-it-crlStatusList OBJECT IDENTIFIER ::= {id-it 22} -- CRLStatusListValue ::= SEQUENCE SIZE (1..MAX) OF Brockhaus, et al. Expires 31 December 2022 [Page 63] Internet-Draft CMP Updates June 2022 -- CRLStatus -- - id-it-crlStatusList added in CMP Updates [RFCXXXX] -- id-it-crls OBJECT IDENTIFIER ::= {id-it 23} -- CRLsValue ::= SEQUENCE SIZE (1..MAX) OF -- CertificateList -- - id-it-crls added in CMP Updates [RFCXXXX] -- -- where -- -- id-pkix OBJECT IDENTIFIER ::= { -- iso(1) identified-organization(3) -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} -- and -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} -- -- -- This construct MAY also be used to define new PKIX Certificate -- Management Protocol request and response messages, or general- -- purpose (e.g., announcement) messages for future needs or for -- specific environments. GenMsgContent ::= SEQUENCE OF InfoTypeAndValue -- May be sent by EE, RA, or CA (depending on message content). -- The OPTIONAL infoValue parameter of InfoTypeAndValue will -- typically be omitted for some of the examples given above. -- The receiver is free to ignore any contained OBJECT IDs that it -- does not recognize. If sent from EE to CA, the empty set -- indicates that the CA may send -- any/all information that it wishes. GenRepContent ::= SEQUENCE OF InfoTypeAndValue -- Receiver MAY ignore any contained OIDs that it does not -- recognize. ErrorMsgContent ::= SEQUENCE { pKIStatusInfo PKIStatusInfo, errorCode INTEGER OPTIONAL, -- implementation-specific error codes errorDetails PKIFreeText OPTIONAL -- implementation-specific error details } CertConfirmContent ::= SEQUENCE OF CertStatus CertStatus ::= SEQUENCE { certHash OCTET STRING, -- the hash of the certificate, using the same hash algorithm Brockhaus, et al. Expires 31 December 2022 [Page 64] Internet-Draft CMP Updates June 2022 -- as is used to create and verify the certificate signature certReqId INTEGER, -- to match this confirmation with the corresponding req/rep statusInfo PKIStatusInfo OPTIONAL, hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} OPTIONAL -- the hash algorithm to use for calculating certHash -- SHOULD NOT be used in all cases where the AlgorithmIdentifier -- of the certificate signature specifies a hash algorithm } PollReqContent ::= SEQUENCE OF SEQUENCE { certReqId INTEGER } PollRepContent ::= SEQUENCE OF SEQUENCE { certReqId INTEGER, checkAfter INTEGER, -- time in seconds reason PKIFreeText OPTIONAL } -- -- Extended Key Usage extension for PKI entities used in CMP -- operations, added due to the changes made in -- CMP Updates [RFCXXXX] -- The EKUs for the CA and RA are reused from CMC as defined in -- [RFC6402] -- -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } END Appendix B. History of Changes [RFC Editor: This appendix must be deleted in the final version of the document.] From version 22 -> 23: * Addressed comments from IESG discussion (see thread "Francesca Palombini's No Objection on draft-ietf-lamps-cmp-updates-22: (with COMMENT)") * Addressed comment from Carl (see thread "Paul Wouters' Discuss on draft-ietf-lamps-cmp-updates-21: (with DISCUSS and COMMENT)") From version 21 -> 22: Brockhaus, et al. Expires 31 December 2022 [Page 65] Internet-Draft CMP Updates June 2022 * Addressed comments from IESG discussion (see thread " Paul Wouters' Discuss on draft-ietf-lamps-cmp-updates-21: (with DISCUSS and COMMENT)") From version 20 -> 21: * Extended Section 1 based on feedback from the IESG telechat * Removed a redundant paragraph from the Abstract From version 19 -> 20: * Addressed comments reported after GEN AD review From version 18 -> 19: * Deleted the Comments on IANA ToDos and changed the decimals TBD1 -> 22 and TBD2 -> 23 * Updated Section 3.4 regarding ToDos updating the well-known URI registration From version 17 -> 18: * Addressed comments from AD Evaluation (see thread "AD Review of draft-ietf-lamps-cmp-updates-17") * Added Section 2.8 to clarify on the usage of GeneralizedTime (see thread "draft-ietf-lamps-cmp-updates: fractional seconds") * Updated Section 3.4 introducing the path segment 'p' to indicate the following arbitrary label according to the discussion during IETF 113 (see thread "/.well-known/brski reference to brski- registry") * Capitalized all headlines From version 16 -> 17: * Removed the pre-RFC5378 work disclaimer after the RFC 4210 authors granted BCP78 rights to the IETF Trust * Removed note on usage of language tags in UTF8String due to reference to references to outdated/historic RFCs * Resolved some nits reported by I-D nit checker tool From version 15 -> 16: * Updated IPR disclaimer From version 14 -> 15: Brockhaus, et al. Expires 31 December 2022 [Page 66] Internet-Draft CMP Updates June 2022 * Updated Section 2.16 clarifying the usage of CRLSource (see thread "CRL update retrieval - WG Last Call for draft-ietf-lamps-cmp- updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08") * Updated Section 2.22 adding further references regarding random number generation (see thread "CMP draft WGLC: measuring entropy, CA certificates") * Fixed some nits From version 13 -> 14: * Extended id-it-caCerts support message to allow transporting to- be-trusted root CA certificates; added respective security consideration (see thread "Generalizing the CMP "Get CA certificates" use case") * Rolled back changes made in previous version regarding root CA update to avoid registration of new OIDs. Yet we sticked to using id-it-rootCaCert in the genm body instead its headers' generalInfo field and removed the ToDos and TBDs on re-arranging id-it OIDs (see thread "Allocation of OIDs for CRL update retrieval (draft- ietf-lamps-cmp-updates-13)") From version 12 -> 13: * Added John Gray to the list of authors due to fruitful discussion and important proposals * Fixed errata no. 2615, 2616, 3949, 4078, and 5201 on RFC 4210 * Added reference on RFC 8933 regarding CMS signedAttrs to Section 2.7 * Updated Section 2.9 and the ASN.1 modules moving the position of the hashAlg field (see thread "[CMP Updates] position of hashAlg in certStatus") * Changed "rootCaCert" from generalInfo to genm body and generalized to "oldTrustAnchor", renaming "rootCaKeyUpdate" to "trustAnchorUpdate" in Sections 2.14, A.1, and A.2, removing former Section 2.4 * Added genm use case "CRL update retrieval" in Section 2.16, A.1, and A.2. (see thread "[CMP Updates] Requesting a current CRL") * Updated Section 2.18 and 2.17 to support polling for all kinds of CMP request messages initiated by an error message with status "waiting" as initially discussed at IETF 111 * Updated Sections 2.19 and 2.20 regarding version handling * Added further OIDs and a TBD regarding reordering of the OIDs * Added Sections 2.21 to 2.23 with new security considerations and updated Section 5 accordingly * Added a ToDo regarding OID registration, renaming, and re-ordering * Added Section 3.1 updating the introduction of RFC 6712 Brockhaus, et al. Expires 31 December 2022 [Page 67] Internet-Draft CMP Updates June 2022 * Fixed some nits in the ASN.1 modules (see thread "draft-ietf- lamps-cmp-updates-12: Comments on A.1. 1988 ASN.1 Module" and "draft-ietf-lamps-cmp-updates-12: Comments on A.2. 2002 ASN.1 Module") * Replaced the term "transport" by "transfer" where appropriate to prevent confusion * Minor editorial changes From version 11 -> 12: * Extended Section 2.5 and the ASN.1 modules in Appendix A to allow a sequence of certificate profiles in CertProfileValue (see thread "id-it-CertProfile in draft-ietf-lamps-cmp-updates") From version 10 -> 11: * Add Section 2.10 to add an additional hashAlg field to the CertStatus type to support certificates signed with a signature algorithm not explicitly indicating a hash algorithm in the AlgorithmIdentifier (see thread "Hash algorithm to us for calculating certHash") * Added newly registered OIDs and temporarily registered URI suffix * Exchanged the import of CertificationRequest from RFC 2986 to the definition from RFC 6402 Appendix A.1 (see thread "CMP Update of CertificationRequest") * Corrected the definition of LocalKeyIdValue in Appendix A.1 * Updated new RFC numbers for draft-lamps-crmf-update-algs From version 9 -> 10: * Added 1988 ASN.1 syntax for localKeyId attribute to Appendix A.1 From version 08 -> 09: * Deleted specific definition of CMP CA and CMP RA in Section 2.2 and only reference RFC 6402 for definition of id-kp-cmcCA and id- kp-cmcRA to resolve the ToDo below based on feedback of Tomas Gustavsson * Added Section 2.4. and 2.5 to define id-it-rootCaCert and id-it- certProfile to be used in Section 2.14 and 2.15 * Added reference to CMP Algorithms in Section 2.8 * Extended Section 2.14 to explicitly indicate the root CA an update is requested for by using id-it-rootCaCert and changing the ASN.1 syntax to require providing the newWithOld certificate in the response message * Extended Section 2.15 to explicitly indicate the certificate request template by using id-it-certProfile and on further details of the newly introduced controls Brockhaus, et al. Expires 31 December 2022 [Page 68] Internet-Draft CMP Updates June 2022 * Deleted the table on id-kp-cmcCA and id-kp-cmcRA and adding id-it- rootCaCert and id-it-certProfile in Section 2.19 * Adding the definition of id-it-rootCaCert and id-it-certProfile in both ASN.1 modules in Appendix A * Minor editorial changes reflecting the above changes From version 07 -> 08: * Added a ToDo to Section 2.2 to reflect a current discussion on the need of an additional CMP-CA role and EKU and differentiation from CMP-RA * Added ToDos to Section 2.12 and 2.13 From version 06 -> 07: * Added David von Oheimb as co-author * Changed to XML V3 * Added Section 2.3 to enable a CMP protocol version number 3 in the PKIHeader for cases where EnvelopedData is to be used (see thread "Mail regarding draft-ietf-lamps-cmp-updates"). * Added Section 2.4 to refer to draft-ietf-lamps-crmf-update-algs for the update of id-PasswordBasedMac for PKI message protection using passwords or shared secrets. * Updated Section 2.6 to introduce the protocol version number 3 to properly indicate support of EnvelopedData instead of EncryptedValue in case a transaction requires use of EnvelopedData (see thread "Mail regarding draft-ietf-lamps-cmp-updates"). * Update Section 2.14 to make the minimal changes to the respective section in CMP more explicit. * Added Sections 2.15 and 2.16 to address the new cmp2021 protocol version in Section 7 Version Negotiation. * Updated Section 2.17 to add new OIDs for id-regCtrl-algId and id- regCtrl-rsaKeyLen for registration at IANA. * Added Section 2.20 to update the general rules of interpretation in Appendix D.1 regarding the new cmp2021 version. * Added Section 2.21 to update the Algorithm Use Profile in Appendix D.2 with the reference to the new CMP Algorithms document as decided at IETF 108. * Updates Section 3.1 to delete the description of a discovery mechanism as decided at IETF 108. * Various changes and corrections in wording. From version 05 -> 06: * Added the update of Appendix D.2 with the reference to the new CMP Algorithms document as decided in IETF 108 * Updated the IANA considerations to register new OIDs for id- regCtrl-algId and d-regCtrl-rsaKeyLen. Brockhaus, et al. Expires 31 December 2022 [Page 69] Internet-Draft CMP Updates June 2022 * Minor changes and corrections From version 04 -> 05: * Added Section 2.11 and Section 2.12 to clarify the usage of these general messages types with EC curves (see thread "AlgorithmIdentifier parameters NULL value - Re: InfoTypeAndValue in CMP headers") * Split former section 2.7 on adding 'CA Certificates', 'Root CA Certificates Update', and 'Certificate Request Template' in three separate sections for easier readability * Changed in Section 2.15 the ASN.1 syntax of CertReqTemplateValue from using rsaKeyLen to usage of controls as specified in CRMF Section 6 [RFC4211] (see thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") * Updated the IANA considerations in Section 4 to introduce new OID for id-regCtrl-algId and id-regCtrl-rsaKeyLen (see thread "dtaft- ietf-lamps-cmp-updates and rsaKeyLen") * Updated the IANA Considerations in and the Appendixes to introduce new OID for the updates ASN.1 modules (see thread "I-D Action: draft-ietf-lamps-cmp-updates-04.txt") * Removed EncryptedValue from and added Controls to the list of types imported from CRMF [RFC4211] in ASN.1 modules (see thread "draft-ietf-lamps-cmp-updates and the ASN.1 modules") * Moved declaration of Rand out of the comment in ASN.1 modules (see thread "draft-ietf-lamps-cmp-updates and the ASN.1 modules") * Minor changes and corrections From version 03 -> 04: * Added Section 2.7 to introduce three new id-it IDs for uses in general messages as discussed (see thread "draft-ietf-lamps-cmp- updates add section to introduce id-it-caCerts, id-it- rootCaKeyUpdate, and id-it-certReqTemplate") * Added the new id-it IDs and the /.well-known/cmp to the IANA Considerations of [RFC4210] in Section 2.9 * Updated the IANA Considerations of [RFC4210] in Section 2.26 * Some changes in wording on Section 3 due to review comments from Martin Peylo From version 02 -> 03: * Added a ToDo on aligning with the CMP Algorithms draft that will be set up as decided in IETF 108 * Updated section on Encrypted Values in Section 2.7 to add the AsymmetricKey Package structure to transport a newly generated private key as decided in IETF 108 * Updated the IANA Considerations of [RFC4210] in Section 2.26 Brockhaus, et al. Expires 31 December 2022 [Page 70] Internet-Draft CMP Updates June 2022 * Added the pre-registered OID in Section 2.26 and the ASN.1 module * Added Section 3 to document the changes to RFC 6712 [RFC6712] regarding URI discovery and using the path-prefix of '/.well- known/' as discussed in IETF 108 * Updated the IANA Considerations section * Added a complete updated ASN.1 module in 1988 syntax to update Appendix F of [RFC4210] and a complete updated ASN.1 module in 2002 syntax to update Section 9 of [RFC5912] * Minor changes in wording From version 01 -> 02: * Updated section on EKU OIDs in Section 2.2 as decided in IETF 107 * Changed from symmetric key-encryption to password-based key management technique in Section 2.7 as discussed with Russ and Jim on the mailing list * Defined the attribute containing the key identifier for the revocation passphrase in Section 2.26 * Moved the change history to the Appendix From version 00 -> 01: * Minor changes in wording From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- updates-00: * Changes required to reflect WG adoption From version 02 -> 03: * Added some clarification in Section 2.1 From version 01 -> 02: * Added clarification to section on multiple protection * Added clarification on new EKUs after some exchange with Tomas Gustavsson * Reused OIDs from RFC 6402 [RFC6402] as suggested by Sean Turner at IETF 106 * Added clarification on the field containing the key identifier for a revocation passphrase * Minor changes in wording From version 00 -> 01: * Added a section describing the new extended key usages Brockhaus, et al. Expires 31 December 2022 [Page 71] Internet-Draft CMP Updates June 2022 * Completed the section on changes to the specification of encrypted values * Added a section on clarification to Appendix D.4 * Minor generalization in RFC 4210 [RFC4210] Sections 5.1.3.4 and 5.3.22 * Minor changes in wording Authors' Addresses Hendrik Brockhaus (editor) Siemens Werner-von-Siemens-Strasse 1 80333 Munich Germany Email: hendrik.brockhaus@siemens.com URI: https://www.siemens.com David von Oheimb Siemens Werner-von-Siemens-Strasse 1 80333 Munich Germany Email: david.von.oheimb@siemens.com URI: https://www.siemens.com John Gray Entrust 1187 Park Place Minneapolis, MN 55379 United States of America Email: john.gray@entrust.com URI: https://www.entrust.com Brockhaus, et al. Expires 31 December 2022 [Page 72] ./draft-ietf-bmwg-ngfw-performance-15.txt0000644000764400076440000043014314325044743020057 0ustar iustiniustin Benchmarking Methodology Working Group B. Balarajah Internet-Draft Obsoletes: 3511 (if approved) C. Rossenhoevel Intended status: Informational EANTC AG Expires: 25 April 2023 B. Monkman NetSecOPEN 22 October 2022 Benchmarking Methodology for Network Security Device Performance draft-ietf-bmwg-ngfw-performance-15 Abstract This document provides benchmarking terminology and methodology for next-generation network security devices including next-generation firewalls (NGFW) and next-generation intrusion prevention systems (NGIPS). The main areas covered in this document are test terminology, test configuration parameters, and benchmarking methodology for NGFW and NGIPS. (It is assumed that readers have a working knowledge of these devices and the security functionality they contain.) This document aims to improve the applicability, reproducibility, and transparency of benchmarks and to align the test methodology with today's increasingly complex layer 7 security- centric network application use cases. As a result, this document makes RFC3511 obsolete. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Balarajah, et al. Expires 25 April 2023 [Page 1] Internet-Draft Benchmarking Network Security Devices October 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Testbed Configuration . . . . . . . . . . . . . . . . . . 5 4.2. DUT/SUT Configuration . . . . . . . . . . . . . . . . . . 6 4.2.1. Security Effectiveness Configuration . . . . . . . . 12 4.3. Test Equipment Configuration . . . . . . . . . . . . . . 12 4.3.1. Client Configuration . . . . . . . . . . . . . . . . 13 4.3.2. Backend Server Configuration . . . . . . . . . . . . 17 4.3.3. Traffic Flow Definition . . . . . . . . . . . . . . . 18 4.3.4. Traffic Load Profile . . . . . . . . . . . . . . . . 19 5. Testbed Considerations . . . . . . . . . . . . . . . . . . . 20 6. Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Detailed Test Results . . . . . . . . . . . . . . . . . . 23 6.3. Benchmarks and Key Performance Indicators . . . . . . . . 23 7. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . 25 7.1. Throughput Performance with Application Traffic Mix . . . 25 7.1.1. Objective . . . . . . . . . . . . . . . . . . . . . . 25 7.1.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 26 7.1.3. Test Parameters . . . . . . . . . . . . . . . . . . . 26 7.1.4. Test Procedures and Expected Results . . . . . . . . 28 7.2. TCP/HTTP Connections Per Second . . . . . . . . . . . . . 29 7.2.1. Objective . . . . . . . . . . . . . . . . . . . . . . 29 7.2.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 29 7.2.3. Test Parameters . . . . . . . . . . . . . . . . . . . 29 7.2.4. Test Procedures and Expected Results . . . . . . . . 31 7.3. HTTP Throughput . . . . . . . . . . . . . . . . . . . . . 32 7.3.1. Objective . . . . . . . . . . . . . . . . . . . . . . 32 7.3.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 32 7.3.3. Test Parameters . . . . . . . . . . . . . . . . . . . 32 7.3.4. Test Procedures and Expected Results . . . . . . . . 35 7.4. HTTP Transaction Latency . . . . . . . . . . . . . . . . 36 7.4.1. Objective . . . . . . . . . . . . . . . . . . . . . . 36 7.4.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 36 7.4.3. Test Parameters . . . . . . . . . . . . . . . . . . . 36 Balarajah, et al. Expires 25 April 2023 [Page 2] Internet-Draft Benchmarking Network Security Devices October 2022 7.4.4. Test Procedures and Expected Results . . . . . . . . 38 7.5. Concurrent TCP/HTTP Connection Capacity . . . . . . . . . 39 7.5.1. Objective . . . . . . . . . . . . . . . . . . . . . . 39 7.5.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 39 7.5.3. Test Parameters . . . . . . . . . . . . . . . . . . . 39 7.5.4. Test Procedures and Expected Results . . . . . . . . 41 7.6. TCP/QUIC Connections per Second with HTTPS Traffic . . . 42 7.6.1. Objective . . . . . . . . . . . . . . . . . . . . . . 43 7.6.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 43 7.6.3. Test Parameters . . . . . . . . . . . . . . . . . . . 43 7.6.4. Test Procedures and Expected Results . . . . . . . . 45 7.7. HTTPS Throughput . . . . . . . . . . . . . . . . . . . . 46 7.7.1. Objective . . . . . . . . . . . . . . . . . . . . . . 46 7.7.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 46 7.7.3. Test Parameters . . . . . . . . . . . . . . . . . . . 46 7.7.4. Test Procedures and Expected Results . . . . . . . . 48 7.8. HTTPS Transaction Latency . . . . . . . . . . . . . . . . 49 7.8.1. Objective . . . . . . . . . . . . . . . . . . . . . . 49 7.8.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 49 7.8.3. Test Parameters . . . . . . . . . . . . . . . . . . . 49 7.8.4. Test Procedures and Expected Results . . . . . . . . 51 7.9. Concurrent TCP/QUIC Connection Capacity with HTTPS Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 52 7.9.1. Objective . . . . . . . . . . . . . . . . . . . . . . 52 7.9.2. Test Setup . . . . . . . . . . . . . . . . . . . . . 52 7.9.3. Test Parameters . . . . . . . . . . . . . . . . . . . 53 7.9.4. Test Procedures and Expected Results . . . . . . . . 55 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 9. Security Considerations . . . . . . . . . . . . . . . . . . . 56 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 57 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 12.1. Normative References . . . . . . . . . . . . . . . . . . 57 12.2. Informative References . . . . . . . . . . . . . . . . . 57 Appendix A. Test Methodology - Security Effectiveness Evaluation . . . . . . . . . . . . . . . . . . . . . . . 59 A.1. Test Objective . . . . . . . . . . . . . . . . . . . . . 59 A.2. Testbed Setup . . . . . . . . . . . . . . . . . . . . . . 60 A.3. Test Parameters . . . . . . . . . . . . . . . . . . . . . 60 A.3.1. DUT/SUT Configuration Parameters . . . . . . . . . . 60 A.3.2. Test Equipment Configuration Parameters . . . . . . . 60 A.4. Test Results Validation Criteria . . . . . . . . . . . . 60 A.5. Measurement . . . . . . . . . . . . . . . . . . . . . . . 61 A.6. Test Procedures and Expected Results . . . . . . . . . . 62 A.6.1. Step 1: Background Traffic . . . . . . . . . . . . . 62 A.6.2. Step 2: CVE Emulation . . . . . . . . . . . . . . . . 62 Appendix B. DUT/SUT Classification . . . . . . . . . . . . . . . 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 Balarajah, et al. Expires 25 April 2023 [Page 3] Internet-Draft Benchmarking Network Security Devices October 2022 1. Introduction 18 years have passed since IETF initially recommended test methodology and terminology for firewalls ([RFC3511]). Firewalls have evolved significantly from the days of simple ACL filters. As the underlying technology progresses and improves, recommending test methodology and terminology for firewalls, requirements, and expectations for network security elements has increased tremendously. Security function implementations have evolved and diversified into intrusion detection and prevention, threat management, analysis of encrypted traffic, and more. In an industry of growing importance, well-defined and reproducible key performance indicators (KPIs) are increasingly needed to enable fair and reasonable comparison of network security functions. These reasons led to the creation of a new next-generation network security device benchmarking document, which makes [RFC3511] obsolete. Measurement of performance for processing of IP fragmented traffic (see Section 5.9 of [RFC3511]) was not included in this document since IP fragmentation does today not commonly occur in traffic anymore, unlike it might have been at the time when [RFC3511] was written. It should also be noted that [RFC2647] retains significant value and has been consulted frequently while creating this document. For a more detailed explanation of what an NGFW is see the Wikipedia article [Wiki-NGFW]. 2. Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119], [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Scope This document provides testing terminology and testing methodology for modern and next-generation network security devices that are configured in Active ("Inline", see Figure 1 and Figure 2) mode. It covers the validation of security effectiveness configurations of network security devices, followed by performance benchmark testing. This document focuses on advanced, realistic, and reproducible testing methods. Additionally, it describes testbed environments, test tool requirements, and test result formats. Balarajah, et al. Expires 25 April 2023 [Page 4] Internet-Draft Benchmarking Network Security Devices October 2022 The performance testing methodology described in this document is not intended for security devices/systems that rely on machine learning or behavioral analysis. If such features are present in a Device Under Test/System Under Test (DUT/SUT), they should be disabled. 4. Test Setup The test setup defined in this document applies to all benchmarking tests described in Section 7. The test setup MUST be contained within an Isolated Test Environment (see Section 3 of [RFC6815]). 4.1. Testbed Configuration Testbed configuration MUST ensure that any performance implications that are discovered during the benchmark testing aren't due to the inherent physical network limitations such as the number of physical links and forwarding performance capabilities (throughput and latency) of the network devices in the testbed. For this reason, this document recommends avoiding external devices such as switches and routers in the testbed wherever possible. In some deployment scenarios, the network security devices (DUT/SUT) are connected to routers and switches, which will reduce the number of entries in MAC or ARP/ND (Address Resolution Protocol/ Neighbor Discovery) tables of the DUT/SUT. If MAC or ARP/ND tables have many entries, this may impact the actual DUT/SUT performance due to MAC and ARP/ND table lookup processes. This document also recommends using test equipment with the capability of emulating layer 3 routing functionality instead of adding external routers in the testbed. The testbed setup Option 1 (Figure 1) is the RECOMMENDED testbed setup for the benchmarking test. +-----------------------+ +-----------------------+ | +-------------------+ | +-----------+ | +-------------------+ | | | Emulated Router(s)| | | | | | Emulated Router(s)| | | | (Optional) | +----- DUT/SUT +-----+ (Optional) | | | +-------------------+ | | | | +-------------------+ | | +-------------------+ | +-----------+ | +-------------------+ | | | Clients | | | | Servers | | | +-------------------+ | | +-------------------+ | | | | | | Test Equipment | | Test Equipment | +-----------------------+ +-----------------------+ Figure 1: Testbed Setup - Option 1 Balarajah, et al. Expires 25 April 2023 [Page 5] Internet-Draft Benchmarking Network Security Devices October 2022 If the test equipment used is not capable of emulating OSI layer 3 routing functionality or if the number of used ports is mismatched between the test equipment and the DUT/SUT (need for test equipment port aggregation), the test setup can be configured as shown in Figure 2. +-------------------+ +-----------+ +--------------------+ |Aggregation Switch/| | | | Aggregation Switch/| | Router +------+ DUT/SUT +------+ Router | | | | | | | +----------+--------+ +-----------+ +--------+-----------+ | | | | +-----------+-----------+ +-----------+-----------+ | | | | | +-------------------+ | | +-------------------+ | | | Emulated Router(s)| | | | Emulated Router(s)| | | | (Optional) | | | | (Optional) | | | +-------------------+ | | +-------------------+ | | +-------------------+ | | +-------------------+ | | | Clients | | | | Servers | | | +-------------------+ | | +-------------------+ | | | | | | Test Equipment | | Test Equipment | +-----------------------+ +-----------------------+ Figure 2: Testbed Setup - Option 2 4.2. DUT/SUT Configuration The same DUT/SUT configuration MUST be used for all benchmarking tests described in Section 7. Since each DUT/SUT will have its own unique configuration, users MUST configure their devices with the same parameters and security features that would be used in the actual deployment of the device or a typical deployment. The DUT/SUT MUST be configured in "Inline" mode so that the traffic is actively inspected by the DUT/SUT. Balarajah, et al. Expires 25 April 2023 [Page 6] Internet-Draft Benchmarking Network Security Devices October 2022 Table 2 and Table 3 below describe the RECOMMENDED and OPTIONAL sets of network security features for NGFW and NGIPS, respectively. If the recommended security features are not enabled in the DUT/SUT for any reason, the reason MUST be reported with the benchmarking test results. For example, one reason for not enabling the anti-virus feature in NGFW may be that this security feature was not required for a particular customer deployment scenario. It MUST be also noted in the benchmarking test report that not enabling the specific recommended security features may impact the performance of the DUT/ SUT. The selected security features MUST be consistently enabled on the DUT/SUT for all benchmarking tests described in Section 7. To improve repeatability, a summary of the DUT/SUT configuration including a description of all enabled DUT/SUT features MUST be published with the benchmarking results. The following table provides a brief description of the security features and these are approximate taxonomies of features commonly found in currently deployed NGFW and NGIDS. The features provided by specific implementations may be named differently and not necessarily have configuration settings that align with the taxonomy. +================+================================================+ | DUT/SUT | Description | | Features | | +================+================================================+ | TLS Inspection | DUT/SUT intercepts and decrypts inbound HTTPS | | | traffic between servers and clients. Once the | | | content inspection has been completed, DUT/SUT | | | encrypts the HTTPS traffic with ciphers and | | | keys used by the clients and servers. For | | | TLS1.3, the DUT works as a middlebox (proxy) | | | and it holds the certificates and Pre-Shared | | | Keys (PSK) that are trusted by the client and | | | represent the identity of the real server. | +----------------+------------------------------------------------+ | IDS/IPS | DUT/SUT detects and blocks exploits targeting | | | known and unknown vulnerabilities across the | | | monitored network. | +----------------+------------------------------------------------+ | Anti-Malware | DUT/SUT detects and prevents the transmission | | | of malicious executable code and any | | | associated communications across the monitored | | | network. This includes data exfiltration as | | | well as command and control channels. | +----------------+------------------------------------------------+ | Anti-Spyware | Anti-Spyware is a subcategory of Anti Malware. | | | Spyware transmits information without the | Balarajah, et al. Expires 25 April 2023 [Page 7] Internet-Draft Benchmarking Network Security Devices October 2022 | | user's knowledge or permission. DUT/SUT | | | detects and blocks initial infection or | | | transmission of data. | +----------------+------------------------------------------------+ | Anti-Botnet | DUT/SUT detects and blocks traffic to or from | | | botnets. | +----------------+------------------------------------------------+ | Anti-Evasion | DUT/SUT detects and mitigates attacks that | | | have been obfuscated in some manner. | +----------------+------------------------------------------------+ | Web Filtering | DUT/SUT detects and blocks malicious websites | | | including defined classifications of websites | | | across the monitored network. | +----------------+------------------------------------------------+ | DLP | DUT/SUT detects and prevents data breaches and | | | data exfiltration, or it detects and blocks | | | the transmission of sensitive data across the | | | monitored network. | +----------------+------------------------------------------------+ | Certificate | DUT/SUT validates certificates used in | | Validation | encrypted communications across the monitored | | | network. | +----------------+------------------------------------------------+ | Logging and | DUT/SUT logs and reports all traffic at the | | Reporting | flow level across the monitored network. | +----------------+------------------------------------------------+ | Application | DUT/SUT detects known applications as defined | | Identification | within the traffic mix selected across the | | | monitored network. | +----------------+------------------------------------------------+ | DPI | DUT/SUT inspects the content of the data | | | packet. | +----------------+------------------------------------------------+ Table 1: Security Feature Description Balarajah, et al. Expires 25 April 2023 [Page 8] Internet-Draft Benchmarking Network Security Devices October 2022 +============================+=============+==========+ | DUT/SUT (NGFW) Features | RECOMMENDED | OPTIONAL | +============================+=============+==========+ | TLS Inspection | x | | +----------------------------+-------------+----------+ | IDS/IPS | x | | +----------------------------+-------------+----------+ | Anti-Spyware | x | | +----------------------------+-------------+----------+ | Anti-Virus | x | | +----------------------------+-------------+----------+ | Anti-Botnet | x | | +----------------------------+-------------+----------+ | Anti-Evasion | x | | +----------------------------+-------------+----------+ | Web Filtering | | x | +----------------------------+-------------+----------+ | Data Loss Protection (DLP) | | x | +----------------------------+-------------+----------+ | DDoS Protection | | x | +----------------------------+-------------+----------+ | Certificate Validation | | x | +----------------------------+-------------+----------+ | Application Identification | x | | +----------------------------+-------------+----------+ Table 2: NGFW Security Features +==============================+=============+==========+ | DUT/SUT (NGIPS) Features | RECOMMENDED | OPTIONAL | +==============================+=============+==========+ | TLS Inspection | x | | +------------------------------+-------------+----------+ | Anti-Malware | x | | +------------------------------+-------------+----------+ | Anti-Spyware | x | | +------------------------------+-------------+----------+ | Anti-Botnet | x | | +------------------------------+-------------+----------+ | Application Identification | x | | +------------------------------+-------------+----------+ | Deep Packet Inspection (DPI) | x | | +------------------------------+-------------+----------+ | Anti-Evasion | x | | +------------------------------+-------------+----------+ Table 3: NGIPS Security Features Balarajah, et al. Expires 25 April 2023 [Page 9] Internet-Draft Benchmarking Network Security Devices October 2022 Note: With respect to TLS Inspection, there are scenarios where it will be optional. Below is a summary of the DUT/SUT configuration: * DUT/SUT MUST be configured in "inline" mode. * "Fail-Open" behavior MUST be disabled. * All RECOMMENDED security features are enabled. * Logging and reporting MUST be enabled. DUT/SUT SHOULD log all traffic at the flow level (5-tuple). If the DUT/SUT is designed to log all traffic at different levels (e.g. IP packet levels), it is acceptable to conduct tests. However, this MUST be noted in the test report. Logging to an external device is permissible. * Geographical location filtering SHOULD be configured. If the DUT/ SUT is not designed to perform geographical location filtering, it is acceptable to conduct tests without this feature. However, this MUST be noted in the test report. * Application Identification and Control MUST be configured to trigger applications from the defined traffic mix. In addition, a realistic number of access control rules (ACL) SHOULD be configured on the DUT/SUT where ACLs are configurable and reasonable based on the deployment scenario. For example, it is acceptable not to configure ACLs in an NGIPS since NGIPS devices do not require the use of ACLs in most deployment scenarios. This document determines the number of access policy rules for four different classes of DUT/SUT: Extra Small (XS), Small (S), Medium (M), and Large (L). A sample DUT/SUT classification is described in Appendix B. The Access Control Rules (ACL) defined in Figure 3 MUST be configured from top to bottom in the correct order as shown in the table. This is due to ACL types listed in specificity decreasing order, with "block" first, followed by "allow", representing a typical ACL-based security policy. The ACL entries MUST be configured with routable IP prefixes by the DUT/SUT, where applicable. (Note: There will be differences between how security vendors implement ACL decision- making.) The configured ACL MUST NOT block the test traffic used for the benchmarking tests. Balarajah, et al. Expires 25 April 2023 [Page 10] Internet-Draft Benchmarking Network Security Devices October 2022 +---------------+ | DUT/SUT | | Classification| | # Rules | +-----------+-----------+--------------------+------+---+---+---+---+ | | Match | | | | | | | | Rules Type| Criteria | Description |Action| XS| S | M | L | +-------------------------------------------------------------------+ |Application|Application| Any application | block| 5 | 10| 20| 50| |layer | | not included in | | | | | | | | | the measurement | | | | | | | | | traffic | | | | | | +-------------------------------------------------------------------+ |Transport |SRC IP and | Any SRC IP prefix | block| 25| 50|100|250| |layer |TCP/UDP | used and any DST | | | | | | | |DST ports | ports not used in | | | | | | | | | the measurement | | | | | | | | | traffic | | | | | | +-------------------------------------------------------------------+ |IP layer |SRC/DST IP | Any SRC/DST IP | block| 25| 50|100|250| | | | subnet not used | | | | | | | | | in the measurement | | | | | | | | | traffic | | | | | | +-------------------------------------------------------------------+ |Application|Application| Half of the | allow| 10| 10| 10| 10| |layer | | applications | | | | | | | | | included in the | | | | | | | | | measurement traffic| | | | | | | | |(see the note below)| | | | | | +-------------------------------------------------------------------+ |Transport |SRC IP and | Half of the SRC | allow| >1| >1| >1| >1| |layer |TCP/UDP | IPs used and any | | | | | | | |DST ports | DST ports used in | | | | | | | | | the measurement | | | | | | | | | traffic | | | | | | | | | (one rule per | | | | | | | | | subnet) | | | | | | +-------------------------------------------------------------------+ |IP layer |SRC IP | The rest of the | allow| >1| >1| >1| >1| | | | SRC IP prefix | | | | | | | | | range used in the | | | | | | | | | measurement | | | | | | | | | traffic | | | | | | | | | (one rule per | | | | | | | | | subnet) | | | | | | +-----------+-----------+--------------------+------+---+---+---+---+ Figure 3: DUT/SUT Access List Balarajah, et al. Expires 25 April 2023 [Page 11] Internet-Draft Benchmarking Network Security Devices October 2022 Note 1: Based on the test customer's specific use case, the testers can increase the number of rules. Note 2: If half of the applications included in the test traffic is less than 10, the missing number of ACL entries (dummy rules) can be configured for any application traffic not included in the test traffic. Note 3: In the event, the DUT/SUT is designed to not use ACLs it is acceptable to conduct tests without them. However, this MUST be noted in the test report. 4.2.1. Security Effectiveness Configuration The selected security features (defined in Table 2 and Table 3) of the DUT/SUT MUST be configured effectively to detect, prevent, and report the defined security vulnerability sets. This section defines the selection of the security vulnerability sets from the Common Vulnerabilities and Exposures (CVE) list for testing. The vulnerability set should reflect a minimum of 500 CVEs from no older than 10 calendar years to the current year. These CVEs should be selected with a focus on in-use software commonly found in business applications, with a Common Vulnerability Scoring System (CVSS) Severity of High (7-10). This document is primarily focused on performance benchmarking. However, it is RECOMMENDED to validate the security features configuration of the DUT/SUT by evaluating the security effectiveness as a prerequisite for performance benchmarking tests defined in section 7. In case the benchmarking tests are performed without evaluating security effectiveness, the test report MUST explain the implications of this. The methodology for evaluating security effectiveness is defined in Appendix A. 4.3. Test Equipment Configuration In general, test equipment allows configuring parameters in different protocol layers. Extensive proof of concept tests conducted to support preparation of this document showed that benchmarking results are strongly affected by the choice of protocol stack parameters; especially OSI layer 4 transport protocol parameters. For more information on how TCP and QUIC parameters will impact performance review [fastly]. To achieve reproducible results that will be representative for real deployment scenarios, careful specification and documentation of the parameters are required. Balarajah, et al. Expires 25 April 2023 [Page 12] Internet-Draft Benchmarking Network Security Devices October 2022 This section specifies common test equipment configuration parameters applicable for all benchmarking tests defined in Section 7. Any benchmarking test specific parameters are described under the test setup section of each benchmarking test individually. 4.3.1. Client Configuration This section specifies which parameters should be considered while configuring emulated client endpoints in the test equipment. Also, this section specifies the RECOMMENDED values for certain parameters. The values are the defaults typically used in most of the client operating system types. Pre-standard evaluations have shown that it is possible to set a wide range of arbitrary parameters for OSI layer 4 transport protocols on test equipment leading to client-specific results optimization; however, only well-defined common parameter sets help to establish meaningful and comparable benchmarking results. For these reasons, this document recommends specific sets of transport protocol parameters to be configured on test equipment used for benchmarking. 4.3.1.1. TCP Stack Attributes The TCP stack of the emulated client endpoints MUST fulfill the TCP requirements defined in [RFC9293] (See Appendix B.). In addition, this section specifies the RECOMMENDED values for TCP parameters configured using the following parameters: The IPv4 and IPv6 Maximum Segment Size (MSS) are set to 1460 bytes and 1440 bytes respectively. TX and RX initial receive window sizes are set to 65535 bytes. The client's initial congestion window should not exceed 10 times the MSS. Delayed ACKs are permitted and the maximum client delayed ACK should not exceed 10 times of the MSS before a forced ACK also, the maximum delayed ACK timer is allowed to be set to 200 ms. Up to three retries are allowed before a timeout event is declared. TCP PSH flag is set to high in all traffic. The source port range is in the range of 1024 - 65535. The clients initiate TCP connections via a three-way handshake (SYN, SYN/ACK, ACK) and close TCP connections via either a TCP three-way close (FIN, FIN/ACK, ACK) or a TCP four-way close (FIN, ACK, FIN, ACK). Balarajah, et al. Expires 25 April 2023 [Page 13] Internet-Draft Benchmarking Network Security Devices October 2022 4.3.1.2. QUIC Specification QUIC stack emulation on the test equipment MUST conform to [RFC9000] and [RFC9001]. This section specifies the RECOMMENDED values for certain QUIC parameters to be configured on test equipment used for benchmarking purposes only. QUIC Stream type (defined in section 2.1 of [RFC9000]) is set to "Client-Initiated, Bidirectional". 0-RTT and early data are Disabled. QUIC Connection termination method is Immediate close (section 10.2 of [RFC9000]. Flow control is enabled. UDP payloads are set to datagram size of 1232 bytes for IPv6 and 1252 bytes for IPv4. In addition, transport parameters and default values defined in section 18.2 of [RFC9000] are RECOMMENDED to configure on test equipment. Also, this document references Appendixes B.1 and B.2 of [RFC9002] for congestion control related constants and variables. Any configured QUIC and UDP parameter(s) MUST be documented in the test report. 4.3.1.3. Client IP Address Space The client IP space contains the following attributes. * If multiple IP blocks are used, they MUST be consist of multiple unique, discontinuous static address blocks. * A default gateway MAY be used. * The DSCP (differentiated services code point) marking should be set to DF (Default Forwarding) '000000' on IPv4 Type of Service (ToS) field and IPv6 traffic class field. * Extension header(s) MAY be used for IPv6 clients. If multiple extension headers are needed for traffic emulation, this document references [RFC8200] to choose the correct order of the extension headers within an IPv6 packet. Testing with extension header(s) may impact the performance of the DUT. The extension headers MUST be documented and reported. The following equation can be used to define the total number of client IP addresses that need to be configured on the test equipment. Desired total number of client IP addresses = Target throughput [Mbit/s] / Average throughput per IP address [Mbit/s] As shown in the example list below, the value for "Average throughput per IP address" can be varied depending on the deployment and use case scenario. Balarajah, et al. Expires 25 April 2023 [Page 14] Internet-Draft Benchmarking Network Security Devices October 2022 (Example 1) DUT/SUT deployment scenario 1 : 6-7 Mbit/s per IP (e.g. 1,400-1,700 IPs per 10Gbit/s of throughput) (Example 2) DUT/SUT deployment scenario 2 : 0.1-0.2 Mbit/s per IP (e.g. 50,000-100,000 IPs per 10Gbit/s of throughput) Client IP addresses MUST be distributed between IPv4 and IPv6 based on deployment and use case scenario. The following options MAY be considered for a selection of ratios for both IP addresses and traffic load distribution. (Option 1) 100 % IPv4, no IPv6 (Option 2) 80 % IPv4, 20% IPv6 (Option 3) 50 % IPv4, 50% IPv6 (Option 4) 20 % IPv4, 80% IPv6 (Option 5) no IPv4, 100% IPv6 Note: IANA has assigned IP address ranges for testing purposes as described in Section 8. If the test scenario requires more IP addresses or subnets than IANA has assigned, this document recommends using private IPv4 address ranges or Unique Local Address (ULA) IPv6 address ranges for the testing. 4.3.1.4. Emulated Web Browser Attributes The client (emulated web browser) contains attributes that will materially affect the traffic load. The objective is to emulate modern, typical browser attributes to improve the relevance of the result set for typical deployment scenarios. The emulated browser MUST negotiate HTTP version 1.1 or higher. The emulated browser SHOULD advertise a User-Agent header. The emulated browser MUST enforce content length validation. HTTP header compression MAY be set to enable. If HTTP header compression is configurable in the test equipment, it MUST be documented if it was enabled or disabled. Depending on test scenarios and chosen HTTP version, the emulated browser MAY open multiple TCP or QUIC connections per Server endpoint IP at any time depending on how many sequential transactions need to be processed. For HTTP/2 traffic emulation, the emulated browser opens multiple concurrent streams per connection (multiplexing). For HTTPS requests, the emulated browser MUST send "h2" protocol identifier using the TLS extension Application Layer Protocol Negotiation Balarajah, et al. Expires 25 April 2023 [Page 15] Internet-Draft Benchmarking Network Security Devices October 2022 (ALPN). The following default values (see [Undertow]) are the RECOMMENDED setting for certain HTTP/2 parameters to be configured on test equipment used for benchmarking purposes only: * Maximum Frame size: 16384 bytes * Initial Window size: 65535 bytes * HPACK Header table size: 4096 bytes * Server PUSH enable: false (Note: in [Undertow] the default setting is true. However, for testing purposes, this document recommends setting the value false for server push.) This document refers to [RFC9113] for further details of HTTP/2. If any additional parameters are used to configure the test equipment, they MUST be documented. For HTTP/3 traffic emulation, the emulated browsers initiate secure QUIC connections using TLS 1.3 ([RFC9001] describes how TLS is used to secure QUIC). This document refers to [RFC9114] for HTTP/3 specifications. The specification for transport protocol parameters is defined in Section 4.3.1.2. QPACK configuration settings such as MAX_TABLE_CAPACITY and QPACK_BLOCKED_STREAMS are set to zero (default) as defined in [RFC9204]. Any HTTP/3 parameters used for test equipment configuration MUST be documented. For encrypted traffic, the following attributes are defined as the negotiated encryption parameters. The test clients MUST use TLS version 1.2 or higher. The TLS record size MAY be optimized for the HTTPS response object size up to a record size of 16 KBytes. If Server Name Indication (SNI) is required (especially if the server is identified by a domain name), the client endpoint MUST send TLS extension Server Name Indication (SNI) information when opening a security tunnel. Each client connection MUST perform a full TLS handshake and session reuse or resumption MUST be disabled. (Note: Real web browsers use session reuse or resumption. However, for testing purposes, this feature must not be used to measure the DUT/ SUT performance in the worst-case scenario.) The following TLS 1.2 supported ciphers and keys are RECOMMENDED for HTTPS based benchmarking tests defined in Section 7. 1. ECDHE-ECDSA-AES128-GCM-SHA256 with Prime256v1 (Signature Hash Algorithm: ecdsa_secp256r1_sha256 and Supported group: secp256r1) 2. ECDHE-RSA-AES128-GCM-SHA256 with RSA 2048 (Signature Hash Algorithm: rsa_pkcs1_sha256 and Supported group: secp256r1) Balarajah, et al. Expires 25 April 2023 [Page 16] Internet-Draft Benchmarking Network Security Devices October 2022 3. ECDHE-ECDSA-AES256-GCM-SHA384 with Secp384r1 (Signature Hash Algorithm: ecdsa_secp384r1_sha384 and Supported group: secp384r1) 4. ECDHE-RSA-AES256-GCM-SHA384 with RSA 4096 (Signature Hash Algorithm: rsa_pkcs1_sha384 and Supported group: secp384r1) Note: The above ciphers and keys were those commonly used for enterprise-grade encryption cipher suites for TLS 1.2 as of the time of publication (2022). Individual certification bodies should use ciphers and keys that reflect evolving use cases. These choices MUST be documented in the resulting test reports with detailed information on the ciphers and keys used along with reasons for the choices. IANA recommends the following cipher suites for use with TLS 1.3 defined in [RFC8446]. 1. TLS_AES_128_GCM_SHA256 2. TLS_AES_256_GCM_SHA384 3. TLS_CHACHA20_POLY1305_SHA256 4. TLS_AES_128_CCM_SHA256 4.3.2. Backend Server Configuration This section specifies which parameters should be considered while configuring emulated backend servers using test equipment. 4.3.2.1. TCP Stack Attributes The TCP stack on the server-side MUST be configured similar to the client-side configuration described in Section 4.3.1.1 4.3.2.2. QUIC Specification The QUIC parameters on the server-side MUST be configured similar to the client-side configuration. Any configured QUIC Parameter(s) MUST be documented in the report. 4.3.2.3. Server Endpoint IP Addressing The sum of the server IP space MUST contain the following attributes. * The server IP blocks MUST consist of unique, discontinuous static address blocks with one IP per server Fully Qualified Domain Name (FQDN) endpoint per test port. Balarajah, et al. Expires 25 April 2023 [Page 17] Internet-Draft Benchmarking Network Security Devices October 2022 * A default gateway is permitted. The DSCP (differentiated services code point) marking is set to DF (Default Forwarding) '000000' on IPv4 Type of Service (ToS) field and IPv6 traffic class field. Extension header(s) for the IPv6 server is permitted. If multiple extension headers are required, this document referenced [RFC8200] to choose the correct order of the extension headers within an IPv6 packet. * The server IP address distribution between IPv4 and IPv6 MUST be identical to the client IP address distribution ratio. Note: The IANA has assigned IP address blocks for the testing purpose as described in Section 8. If the test scenario requires more IP addresses or address blocks than the IANA assigned, this document recommends using private IPv4 address ranges or Unique Local Address (ULA) IPv6 address ranges for the testing. 4.3.2.4. HTTP / HTTPS Server Pool Endpoint Attributes The HTTP 1.1 and HTTP/2 server pools listen on TCP ports 80 and 443 for HTTP and HTTPS. HTTP/3 server pool listens on UDP port 443 or any port. The server MUST emulate the same HTTP version (HTTP 1.1 or HTTP/2 or HTTP/3) and settings chosen by the client (emulated web browser). For the HTTPS server, TLS 1.2 or higher MUST be used with a maximum record size of 16 KByte. Ticket resumption or session ID reuse MUST NOT be used for TLS 1.2 and also session Ticket or session cache MUST NOT be used for TLS 1.3. The server MUST serve a certificate to the client. Cipher suite and key size on the server- side MUST be configured similar to the client-side configuration described in Section 4.3.1.4. 4.3.3. Traffic Flow Definition This section describes the traffic pattern between client and server endpoints. At the beginning of the test, the server endpoint initializes and will be ready to accept connection states including initialization of the TCP or QUIC stack as well as bound HTTP and HTTPS servers. When a client endpoint is needed, it will initialize and be given attributes such as a MAC and IP address. The behavior of the client is to sweep through the given server IP space, generating a recognizable service by the DUT. Sequential and pseudorandom sweep methods are acceptable. The method used MUST be stated in the final report. Thus, a balanced mesh between client endpoints and server endpoints will be generated in a client IP and port to server IP and port combination. Each client endpoint performs the same actions as other endpoints, with the difference being the source IP of the client endpoint and the target server IP pool. The client MUST use the server IP address or FQDN in the host Balarajah, et al. Expires 25 April 2023 [Page 18] Internet-Draft Benchmarking Network Security Devices October 2022 header. 4.3.3.1. Description of Intra-Client Behavior Client endpoints are independent of other clients that are concurrently executing. When a client endpoint initiates traffic, this section describes how the client steps through different services. Once the test is initialized, the client endpoints randomly hold (perform no operation) for a few milliseconds for better randomization of the start of client traffic. Each client (HTTP 1.1 or HTTP/2) will either open a new TCP connection or connect to an HTTP persistent connection still open to that specific server. HTTP/3 clients will open UDP streams within QUIC connections. At any point that the traffic profile may require encryption, a TLS encryption tunnel will form presenting the URL or IP address request to the server. If using SNI, the server MUST then perform an SNI name check with the proposed FQDN compared to the domain embedded in the certificate. Only when correct, will the server process the HTTPS response object. The initial response object to the server is based on benchmarking tests described in Section 7. Multiple additional sub-URLs (response objects on the service page) MAY be requested simultaneously. This MAY be to the same server IP as the initial URL. Each sub-object will also use a canonical FQDN and URL path. 4.3.4. Traffic Load Profile The loading of traffic is described in this section. The loading of a traffic load profile has five phases: Init, ramp up, sustain, ramp down, and collection. 1. Init phase: Testbed devices including the client and server endpoints should negotiate layer 2-3 connectivity such as MAC learning and ARP/ND. Only after successful MAC learning or ARP/ ND SHALL the test iteration move to the next phase. No measurements are made in this phase. The minimum recommended time for the Init phase is 5 seconds. During this phase, the emulated clients MUST NOT initiate any sessions with the DUT/SUT, in contrast, the emulated servers should be ready to accept requests from DUT/SUT or emulated clients. 2. Ramp up phase: The test equipment MUST start to generate the test traffic. It MUST use a set of the approximate number of unique client IP addresses to generate traffic. The traffic MUST ramp up from zero to desired target objective. The target objective is defined for each benchmarking test. The duration for the ramp up phase MUST be configured long enough that the test equipment does not overwhelm the DUT/SUTs stated performance metrics Balarajah, et al. Expires 25 April 2023 [Page 19] Internet-Draft Benchmarking Network Security Devices October 2022 defined in Section 6.3 namely, TCP or QUIC Connections Per Second, Inspected Throughput, Concurrent TCP or QUIC Connections, and Application Transactions Per Second. No measurements are made in this phase. 3. Sustain phase: Starts when all required clients are active and operating at their desired load condition. In the sustain phase, the test equipment MUST continue generating traffic to a constant target value for a constant number of active clients. The minimum RECOMMENDED time duration for sustain phase is 300 seconds. This is the phase where measurements occur. The test equipment MUST measure and record statistics continuously. The sampling interval for collecting the raw results and calculating the statistics MUST be less than 2 seconds. 4. Ramp down phase: The test traffic slows down from the target number to 0, and no measurements are made. 5. Collection phase: The last phase is administrative and will occur when the test equipment merges and collates the report data. 5. Testbed Considerations This section describes steps for a reference test (pre-test) that control the test environment including test equipment, focusing on physical and virtualized environments and as well as test equipment. Below are the RECOMMENDED steps for the reference test. 1. Perform the reference test either by configuring the DUT/SUT in the most trivial setup (fast forwarding) or without the presence of the DUT/SUT. 2. Generate traffic from traffic generator. Choose a traffic profile used for the HTTP or HTTPS throughput performance test with the smallest object size. 3. Ensure that any ancillary switching or routing functions added in the test equipment do not limit the performance by introducing network metrics such as packet loss and latency. This is specifically important for virtualized components (e.g., vSwitches, vRouters). 4. Verify that the generated traffic (performance) of the test equipment matches and reasonably exceeds the expected maximum performance of the DUT/SUT. 5. Record the network performance metrics packet loss and latency introduced by the test environment (without DUT/SUT). Balarajah, et al. Expires 25 April 2023 [Page 20] Internet-Draft Benchmarking Network Security Devices October 2022 6. Assert that the testbed characteristics are stable during the entire test session. Several factors might influence stability specifically, for virtualized testbeds. For example, additional workloads in a virtualized system, load balancing, and movement of virtual machines during the test, or simple issues such as additional heat created by high workloads leading to an emergency CPU performance reduction. The reference test MUST be performed before the benchmarking tests (described in section 7) start. 6. Reporting This section describes how the benchmarking test report should be formatted and presented. It is RECOMMENDED to include two main sections in the report: the introduction and the detailed test results sections. 6.1. Introduction The following attributes should be present in the introduction section of the test report. 1. The time and date of the execution of the tests 2. Summary of testbed software and hardware details a. DUT/SUT hardware/virtual configuration * This section should clearly identify the make and model of the DUT/SUT * The port interfaces, including speed and link information * If the DUT/SUT is a Virtual Network Function (VNF), host (server) hardware and software details, interface acceleration type such as DPDK and SR-IOV, used CPU cores, used RAM, resource sharing (e.g. Pinning details and NUMA Node) configuration details, hypervisor version, virtual switch version * details of any additional hardware relevant to the DUT/SUT such as controllers b. DUT/SUT software * Operating system name Balarajah, et al. Expires 25 April 2023 [Page 21] Internet-Draft Benchmarking Network Security Devices October 2022 * Version * Specific configuration details (if any) c. DUT/SUT enabled features * Configured DUT/SUT features (see Table 2 and Table 3) * Attributes of the above-mentioned features * Any additional relevant information about the features d. Test equipment hardware and software * Test equipment vendor name * Hardware details including model number, interface type * Test equipment firmware and test application software version * If the test equipment is a virtual solution, the host (server) hardware and software details, interface acceleration type such as DPDK and SR-IOV, used CPU cores, used RAM, resource sharing (e.g. Pinning details and NUMA Node) configuration details, hypervisor version, virtual switch version e. Key test parameters * Used cipher suites and keys * IPv4 and IPv6 traffic distribution * Number of configured ACL * TCP, UDP stack parameter if tested * QUIC, HTTP/2, and HTTP/3 parameters if tested f. Details of application traffic mix used in the benchmarking test "Throughput Performance with Application Traffic Mix" (Section 7.1) * Name of applications and layer 7 protocols * Percentage of emulated traffic for each application and layer 7 protocols Balarajah, et al. Expires 25 April 2023 [Page 22] Internet-Draft Benchmarking Network Security Devices October 2022 * Percentage of encrypted traffic and used cipher suites and keys (The RECOMMENDED ciphers and keys are defined in Section 4.3.1.4) * Used object sizes for each application and layer 7 protocols 3. Results Summary / Executive Summary a. Results should be presented with an introduction section documenting the summary of results in a prominent, easy to read block. 6.2. Detailed Test Results In the result section of the test report, the following attributes should be present for each benchmarking test. a. KPIs MUST be documented separately for each benchmarking test. The format of the KPI metrics MUST be presented as described in Section 6.3. b. The next level of detail should be graphs showing each of these metrics over the duration (sustain phase) of the test. This allows the user to see the measured performance stability changes over time. 6.3. Benchmarks and Key Performance Indicators This section lists key performance indicators (KPIs) for overall benchmarking tests. All KPIs MUST be measured during the sustain phase of the traffic load profile described in Section 4.3.4. Also, the KPIs MUST be measured from the result output of test equipment. * Concurrent TCP Connections The aggregate number of simultaneous connections between hosts across the DUT/SUT, or between hosts and the DUT/SUT (defined in [RFC2647]). * Concurrent QUIC Connections The aggregate number of simultaneous connections between hosts across the DUT/SUT. * TCP Connections Per Second Balarajah, et al. Expires 25 April 2023 [Page 23] Internet-Draft Benchmarking Network Security Devices October 2022 The average number of successfully established TCP connections per second between hosts across the DUT/SUT, or between hosts and the DUT/SUT. As described in Section 4.3.1.1, the TCP connections are initiated by clients via a TCP three-way handshake (SYN, SYN/ACK, ACK). Then the TCP session data is sent and then the TCP sessions are closed via either a TCP three-way close (FIN, FIN/ACK, ACK) or a TCP four-way close (FIN, ACK, FIN, ACK). The TCP sessions MUST NOT be closed by RST. * QUIC Connections Per Second The average number of successfully established QUIC connections per second between hosts across the DUT/SUT. As described in Section 4.3.1.2, the QUIC connections are initiated by clients. Then the data is sent and then the QUIC sessions are closed by "immediate close" method. Since QUIC specification defined in Section 4.3.1.2 recommends disabling 0-RTT and early data, this KPI focused on 1-RTT handshake. If required, 0-RTT can be also measured in separate test runs while enabling 0-RTT and early data in the test equipment. * Application Transactions Per Second The average number of successfully completed transactions per second. For a particular transaction to be considered successful, all data MUST have been transferred in its entirety. In case of HTTP(S) transactions, it MUST have a valid status code (200 OK). * TLS Handshake Rate The average number of successfully established TLS connections per second between hosts across the DUT/SUT, or between hosts and the DUT/SUT. For TLS1.3 the handshake rate can be measured with 0-RTT or 1-RTT handshake. The transport protocol can be either TCP or QUIC. * Inspected Throughput The number of bits per second of examined and allowed traffic a network security device is able to transmit to the correct destination interface(s) in response to a specified offered load. The throughput benchmarking tests defined in Section 7 SHOULD measure the average Layer 2 throughput value when the DUT/SUT is "inspecting" traffic. It is also acceptable to measure other OSI Layer throughput. However, the measured layer (e.g. Layer 3 Balarajah, et al. Expires 25 April 2023 [Page 24] Internet-Draft Benchmarking Network Security Devices October 2022 throughput) MUST be noted in the report and the user MUST be aware of the implication while comparing the throughput performance of multiple DUT/SUTs measured in different OSI Layers. This document recommends presenting the inspected throughput value in Gbit/s rounded to two places of precision with a more specific Kbit/s in parenthesis. * Time to First Byte (TTFB) TTFB is the elapsed time between the start of sending the TCP SYN packet or QUIC initial Client Hello from the client and the client receiving the first packet of application data from the server via DUT/SUT. The benchmarking tests HTTP Transaction Latency (Section 7.4) and HTTPS Transaction Latency (Section 7.8) measure the minimum, average and maximum TTFB. The value should be expressed in milliseconds. * URL Response time / Time to Last Byte (TTLB) URL Response time / TTLB is the elapsed time between the start of sending the TCP SYN packet or QUIC initial Client Hello from the client and the client receiving the last packet of application data from the server via DUT/SUT. The benchmarking tests HTTP Transaction Latency (Section 7.4) and HTTPS Transaction Latency (Section 7.8) measure the minimum, average and maximum TTLB. The value should be expressed in milliseconds. 7. Benchmarking Tests This section mainly focuses on the benchmarking tests with HTTP/1.1 or HTTP/2 traffic which uses TCP as the transport protocol. In particular, this section does not define specific benchmarking tests for QUIC or HTTP/3 related KPIs. However, the test methodology defined in the benchmarking tests TCP/QUIC Connections Per Second with HTTPS Traffic (Section 7.6), HTTPS Transaction Latency (Section 7.8), HTTPS Throughput (Section 7.7), and Concurrent TCP/ QUIC Connection Capacity with HTTPS Traffic (Section 7.9) can be used to test QUIC or HTTP/3 related KPIs. The throughput performance test with the application traffic mix defined in Section 7.1 can be performed with any other application traffic including HTTP/3. 7.1. Throughput Performance with Application Traffic Mix 7.1.1. Objective Using a relevant application traffic mix, determine the sustainable inspected throughput supported by the DUT/SUT. Balarajah, et al. Expires 25 April 2023 [Page 25] Internet-Draft Benchmarking Network Security Devices October 2022 Based on the test customer's specific use case, testers can choose the relevant application traffic mix for this test. The details about the traffic mix MUST be documented in the report. At least the following traffic mix details MUST be documented and reported together with the test results: Name of applications and layer 7 protocols Percentage of emulated traffic for each application and layer 7 protocol Percentage of encrypted traffic and used cipher suites and keys (The RECOMMENDED ciphers and keys are defined in Section 4.3.1.4.) Used object sizes for each application and layer 7 protocols 7.1.2. Test Setup Testbed setup MUST be configured as defined in Section 4. Any benchmarking test specific testbed configuration changes MUST be documented. 7.1.3. Test Parameters In this section, the benchmarking test specific parameters are defined. 7.1.3.1. DUT/SUT Configuration Parameters DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented. In case the DUT/SUT is configured without TLS inspection, the test report MUST explain the implications of this to the relevant application traffic mix encrypted traffic. 7.1.3.2. Test Equipment Configuration Parameters Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test: Client IP address ranges defined in Section 4.3.1.3 Server IP address ranges defined in Section 4.3.2.3 Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3 Balarajah, et al. Expires 25 April 2023 [Page 26] Internet-Draft Benchmarking Network Security Devices October 2022 Target inspected throughput: Aggregated line rate of the interface(s) used in the DUT/SUT or the value defined based on the requirement for a specific deployment scenario Initial throughput: 10% of the "Target inspected throughput" Note: Initial throughput is not a KPI to report. This value is configured on the traffic generator and used to perform Step 1: "Test Initialization and Qualification" described under Section 7.1.4. One of the ciphers and keys defined in Section 4.3.1.4 are RECOMMENDED to use for this benchmarking test. 7.1.3.3. Traffic Profile Traffic profile: This test MUST be run with a relevant application traffic mix profile. 7.1.3.4. Test Results Validation Criteria The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile. a. Number of failed application transactions MUST be less than 0.001% (1 out of 100,000 transactions) of total attempted transactions. b. Number of Terminated TCP connections due to unexpected TCP RST sent by DUT/SUT MUST be less than 0.001% (1 out of 100,000 connections) of total initiated TCP connections. c. If HTTP/3 is used, the number of failed QUIC connections due to unexpected HTTP/3 error codes MUST be less than 0.001% (1 out of 100,000 connections) of total initiated QUIC connections. 7.1.3.5. Measurement The following KPI metrics MUST be reported for this benchmarking test: Mandatory KPIs (benchmarks): Inspected Throughput and Application Transactions Per Second Note: TTLB MUST be reported along with the object size used in the traffic profile. Balarajah, et al. Expires 25 April 2023 [Page 27] Internet-Draft Benchmarking Network Security Devices October 2022 Optional TCP stack related KPIs: TCP Connections Per Second, TLS Handshake Rate, TTFB (minimum, average, and maximum), TTLB (minimum, average, and maximum) Optional QUIC stack related KPIs: QUIC connection per second and concurrent QUIC connections 7.1.4. Test Procedures and Expected Results The test procedures are designed to measure the inspected throughput performance of the DUT/SUT at the sustaining period of the traffic load profile. The test procedure consists of three major steps: Step 1 ensures the DUT/SUT is able to reach the performance value (initial throughput) and meets the test results validation criteria when it was very minimally utilized. Step 2 determines whether the DUT/SUT is able to reach the target performance value within the test results validation criteria. Step 3 determines the maximum achievable performance value within the test results validation criteria. This test procedure MAY be repeated multiple times with different IP types: IPv4 only, IPv6 only, and IPv4 and IPv6 mixed traffic distribution. 7.1.4.1. Step 1: Test Initialization and Qualification Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status. Configure the traffic load profile of the test equipment to generate test traffic at the "Initial throughput" rate as described in Section 7.1.3.2. The test equipment MUST follow the traffic load profile definition as described in Section 4.3.4. The DUT/SUT MUST reach the "Initial throughput" during the sustain phase. Measure all KPI as defined in Section 7.1.3.5. The measured KPIs during the sustain phase MUST meet all the test results validation criteria defined in Section 7.1.3.4. If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to step 2. 7.1.4.2. Step 2: Test Run with Target Objective Configure test equipment to generate traffic at the "Target inspected throughput" rate defined in Section 7.1.3.2. The test equipment MUST follow the traffic load profile definition as described in Section 4.3.4. The test equipment MUST start to measure and record all specified KPIs. Continue the test until all traffic profile phases are completed. Balarajah, et al. Expires 25 April 2023 [Page 28] Internet-Draft Benchmarking Network Security Devices October 2022 Within the test results validation criteria, the DUT/SUT is expected to reach the desired value of the target objective ("Target inspected throughput") in the sustain phase. Follow step 3, if the measured value does not meet the target value or does not fulfill the test results validation criteria. 7.1.4.3. Step 3: Test Iteration Determine the achievable average inspected throughput within the test results validation criteria. The final test iteration MUST be performed for the test duration defined in Section 4.3.4. 7.2. TCP/HTTP Connections Per Second 7.2.1. Objective Using HTTP traffic, determine the sustainable TCP connection establishment rate supported by the DUT/SUT under different throughput load conditions. To measure connections per second, test iterations MUST use different fixed HTTP response object sizes (the different load conditions) defined in Section 7.2.3.2. 7.2.2. Test Setup Testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces and interface type, etc.) MUST be documented. 7.2.3. Test Parameters In this section, benchmarking test specific parameters are defined. 7.2.3.1. DUT/SUT Configuration Parameters DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented. 7.2.3.2. Test Equipment Configuration Parameters Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test: Client IP address ranges defined in Section 4.3.1.3 Balarajah, et al. Expires 25 April 2023 [Page 29] Internet-Draft Benchmarking Network Security Devices October 2022 Server IP address ranges defined in Section 4.3.2.3 Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3 Target connections per second: Initial value from product datasheet or the value defined based on the requirement for a specific deployment scenario Initial connections per second: 10% of "Target connections per second" (Note: Initial connections per second is not a KPI to report. This value is configured on the traffic generator and used to perform Step1: "Test Initialization and Qualification" described under Section 7.2.4.) The client MUST negotiate HTTP and close the connection with FIN immediately after the completion of one transaction. In each test iteration, the client MUST send a GET request requesting a fixed HTTP response object size. The RECOMMENDED response object sizes are 1, 2, 4, 16, and 64 KByte. 7.2.3.3. Test Results Validation Criteria The following criteria are the test results validation criteria. The Test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile. a. Number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of total attempted transactions. b. Number of terminated TCP connections due to unexpected TCP RST sent by DUT/SUT MUST be less than 0.001% (1 out of 100,000 connections) of total initiated TCP connections. c. During the sustain phase, traffic MUST be forwarded at a constant rate (considered as a constant rate if any deviation of traffic forwarding rate is less than 5%). d. Concurrent TCP connections MUST be constant during steady state and any deviation of concurrent TCP connections MUST be less than 10%. This confirms the DUT opens and closes TCP connections at approximately the same rate. Balarajah, et al. Expires 25 April 2023 [Page 30] Internet-Draft Benchmarking Network Security Devices October 2022 7.2.3.4. Measurement TCP Connections Per Second MUST be reported for each test iteration (for each object size). 7.2.4. Test Procedures and Expected Results The test procedure is designed to measure the TCP connections per second rate of the DUT/SUT at the sustaining period of the traffic load profile. The test procedure consists of three major steps: Step 1 ensures the DUT/SUT is able to reach the performance value (Initial connections per second) and meets the test results validation criteria when it was very minimally utilized. Step 2 determines whether the DUT/SUT is able to reach the target performance value within the test results validation criteria. Step 3 determines the maximum achievable performance value within the test results validation criteria. This test procedure MAY be repeated multiple times with different IP types: IPv4 only, IPv6 only, and IPv4 and IPv6 mixed traffic distribution. 7.2.4.1. Step 1: Test Initialization and Qualification Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status. Configure the traffic load profile of the test equipment to establish "Initial connections per second" as defined in Section 7.2.3.2. The traffic load profile MUST be defined as described in Section 4.3.4. The DUT/SUT MUST reach the "Initial connections per second" before the sustain phase. The measured KPIs during the sustain phase MUST meet all the test results validation criteria defined in Section 7.2.3.3. If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT continue to "Step 2". 7.2.4.2. Step 2: Test Run with Target Objective Configure test equipment to establish the target objective ("Target connections per second") defined in Section 7.2.3.2. The test equipment MUST follow the traffic load profile definition as described in Section 4.3.4. Balarajah, et al. Expires 25 April 2023 [Page 31] Internet-Draft Benchmarking Network Security Devices October 2022 During the ramp up and sustain phase of each test iteration, other KPIs such as inspected throughput, concurrent TCP connections, and application transactions per second MUST NOT reach the maximum value the DUT/SUT can support. The test results for specific test iterations MUST NOT be reported as valid results if the above mentioned KPI (especially inspected throughput) reaches the maximum value. (Example: If the test iteration with 64 KByte of HTTP response object size reached the maximum inspected throughput limitation of the DUT/SUT, the test iteration MAY be interrupted and the result for 64 KByte must not be reported.) The test equipment MUST start to measure and record all specified KPIs. Continue the test until all traffic profile phases are completed. Within the test results validation criteria, the DUT/SUT is expected to reach the desired value of the target objective ("Target connections per second") in the sustain phase. Follow step 3, if the measured value does not meet the target value or does not fulfill the test results validation criteria. 7.2.4.3. Step 3: Test Iteration Determine the achievable TCP connections per second within the test results validation criteria. 7.3. HTTP Throughput 7.3.1. Objective Determine the sustainable inspected throughput of the DUT/SUT for HTTP transactions varying the HTTP response object size. 7.3.2. Test Setup Testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces and interface type, etc.) MUST be documented. 7.3.3. Test Parameters In this section, benchmarking test specific parameters are defined. 7.3.3.1. DUT/SUT Configuration Parameters DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented. Balarajah, et al. Expires 25 April 2023 [Page 32] Internet-Draft Benchmarking Network Security Devices October 2022 7.3.3.2. Test Equipment Configuration Parameters Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test: Client IP address ranges defined in Section 4.3.1.3 Server IP address ranges defined in Section 4.3.2.3 Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3 Target inspected throughput: Aggregated line rate of the interface(s) used in the DUT/SUT or the value defined based on the requirement for a specific deployment scenario Initial throughput: 10% of "Target inspected throughput" Note: Initial throughput is not a KPI to report. This value is configured on the traffic generator and used to perform Step 1: "Test Initialization and Qualification" described under Section 7.3.4. Number of HTTP response object requests (transactions) per connection: 10 RECOMMENDED HTTP response object size: 1, 16, 64, 256 KByte, and mixed objects defined in Table 4. Balarajah, et al. Expires 25 April 2023 [Page 33] Internet-Draft Benchmarking Network Security Devices October 2022 +=====================+============================+ | Object size (KByte) | Number of requests/ Weight | +=====================+============================+ | 0.2 | 1 | +---------------------+----------------------------+ | 6 | 1 | +---------------------+----------------------------+ | 8 | 1 | +---------------------+----------------------------+ | 9 | 1 | +---------------------+----------------------------+ | 10 | 1 | +---------------------+----------------------------+ | 25 | 1 | +---------------------+----------------------------+ | 26 | 1 | +---------------------+----------------------------+ | 35 | 1 | +---------------------+----------------------------+ | 59 | 1 | +---------------------+----------------------------+ | 347 | 1 | +---------------------+----------------------------+ Table 4: Mixed Objects 7.3.3.3. Test Results Validation Criteria The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile. a. Number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of attempt transactions. b. Traffic MUST be forwarded at a constant rate (considered as a constant rate if any deviation of traffic forwarding rate is less than 5%). c. Concurrent TCP connections MUST be constant during steady state and any deviation of concurrent TCP connections MUST be less than 10%. This confirms the DUT opens and closes TCP connections at approximately the same rate. Balarajah, et al. Expires 25 April 2023 [Page 34] Internet-Draft Benchmarking Network Security Devices October 2022 7.3.3.4. Measurement Inspected Throughput and HTTP Transactions per Second MUST be reported for each object size. 7.3.4. Test Procedures and Expected Results The test procedure is designed to measure HTTP throughput of the DUT/ SUT. The test procedure consists of three major steps: Step 1 ensures the DUT/SUT is able to reach the performance value (Initial throughput) and meets the test results validation criteria when it was very minimal utilized. Step 2 determines whether the DUT/SUT is able to reach the target performance value within the test results validation criteria. Step 3 determines the maximum achievable performance value within the test results validation criteria. This test procedure MAY be repeated multiple times with different IPv4 and IPv6 traffic distribution and HTTP response object sizes. 7.3.4.1. Step 1: Test Initialization and Qualification Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status. Configure the traffic load profile of the test equipment to establish "Initial inspected throughput" as defined in Section 7.3.3.2. The traffic load profile MUST be defined as described in Section 4.3.4. The DUT/SUT MUST reach the "Initial inspected throughput" during the sustain phase. Measure all KPI as defined in Section 7.3.3.4. The measured KPIs during the sustain phase MUST meet the test results validation criteria "a" defined in Section 7.3.3.3. The test results validation criteria "b" and "c" are OPTIONAL for step 1. If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to "Step 2". 7.3.4.2. Step 2: Test Run with Target Objective Configure test equipment to establish the target objective ("Target inspected throughput") defined in Section 7.3.3.2. The test equipment MUST start to measure and record all specified KPIs. Continue the test until all traffic profile phases are completed. Balarajah, et al. Expires 25 April 2023 [Page 35] Internet-Draft Benchmarking Network Security Devices October 2022 Within the test results validation criteria, the DUT/SUT is expected to reach the desired value of the target objective in the sustain phase. Follow step 3, if the measured value does not meet the target value or does not fulfill the test results validation criteria. 7.3.4.3. Step 3: Test Iteration Determine the achievable inspected throughput within the test results validation criteria and measure the KPI metric Transactions per Second. The final test iteration MUST be performed for the test duration defined in Section 4.3.4. 7.4. HTTP Transaction Latency 7.4.1. Objective Using HTTP traffic, determine the HTTP transaction latency when DUT is running with sustainable HTTP transactions per second supported by the DUT/SUT under different HTTP response object sizes. Test iterations MUST be performed with different HTTP response object sizes in two different scenarios. One with a single transaction and the other with multiple transactions within a single TCP connection. For consistency, both the single and multiple transaction tests MUST be configured with the same HTTP version Scenario 1: The client MUST negotiate HTTP and close the connection with FIN immediately after the completion of a single transaction (GET and RESPONSE). Scenario 2: The client MUST negotiate HTTP and close the connection FIN immediately after the completion of 10 transactions (GET and RESPONSE) within a single TCP connection. 7.4.2. Test Setup Testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces and interface type, etc.) MUST be documented. 7.4.3. Test Parameters In this section, benchmarking test specific parameters are defined. Balarajah, et al. Expires 25 April 2023 [Page 36] Internet-Draft Benchmarking Network Security Devices October 2022 7.4.3.1. DUT/SUT Configuration Parameters DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented. 7.4.3.2. Test Equipment Configuration Parameters Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test: Client IP address ranges defined in Section 4.3.1.3 Server IP address ranges defined in Section 4.3.2.3 Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3 Target objective for scenario 1: 50% of the connections per second measured in benchmarking test TCP/HTTP Connections Per Second (Section 7.2) Target objective for scenario 2: 50% of the inspected throughput measured in benchmarking test HTTP Throughput (Section 7.3) Initial objective for scenario 1: 10% of "Target objective for scenario 1" Initial objective for scenario 2: 10% of "Target objective for scenario 2" Note: The Initial objectives are not a KPI to report. These values are configured on the traffic generator and used to perform Step1: "Test Initialization and Qualification" described under Section 7.4.4. HTTP transaction per TCP connection: Test scenario 1 with a single transaction and test scenario 2 with 10 transactions. HTTP with GET request requesting a single object. The RECOMMENDED object sizes are 1, 16, and 64 KByte. For each test iteration, the client MUST request a single HTTP response object size. Balarajah, et al. Expires 25 April 2023 [Page 37] Internet-Draft Benchmarking Network Security Devices October 2022 7.4.3.3. Test Results Validation Criteria The following criteria are the test results validation criteria. The Test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile. a. Number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of attempt transactions. b. Number of terminated TCP connections due to unexpected TCP RST sent by DUT/SUT MUST be less than 0.001% (1 out of 100,000 connections) of total initiated TCP connections. c. During the sustain phase, traffic MUST be forwarded at a constant rate (considered as a constant rate if any deviation of traffic forwarding rate is less than 5%). d. Concurrent TCP connections MUST be constant during steady state and any deviation of concurrent TCP connections MUST be less than 10%. This confirms the DUT opens and closes TCP connections at approximately the same rate. e. After ramp up the DUT MUST achieve the "Target objective" defined in Section 7.4.3.2 and remain in that state for the entire test duration (sustain phase). 7.4.3.4. Measurement TTFB (minimum, average, and maximum) and TTLB (minimum, average, and maximum) MUST be reported for each object size. 7.4.4. Test Procedures and Expected Results The test procedure is designed to measure TTFB or TTLB when the DUT/ SUT is operating close to 50% of its maximum achievable connections per second or inspected throughput. The test procedure consists of two major steps: Step 1 ensures the DUT/SUT is able to reach the initial performance values and meets the test results validation criteria when it was very minimally utilized. Step 2 measures the latency values within the test results validation criteria. This test procedure MAY be repeated multiple times with different IP types (IPv4 only, IPv6 only, and IPv4 and IPv6 mixed traffic distribution), HTTP response object sizes, and single and multiple transactions per connection scenarios. Balarajah, et al. Expires 25 April 2023 [Page 38] Internet-Draft Benchmarking Network Security Devices October 2022 7.4.4.1. Step 1: Test Initialization and Qualification Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status. Configure the traffic load profile of the test equipment to establish the "Initial objective" as defined in Section 7.4.3.2. The traffic load profile MUST be defined as described in Section 4.3.4. The DUT/SUT MUST reach the "Initial objective" before the sustain phase. The measured KPIs during the sustain phase MUST meet all the test results validation criteria defined in Section 7.4.3.3. If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to "Step 2". 7.4.4.2. Step 2: Test Run with Target Objective Configure test equipment to establish the "Target objective" defined in Section 7.4.3.2. The test equipment MUST follow the traffic load profile definition as described in Section 4.3.4. The test equipment MUST start to measure and record all specified KPIs. Continue the test until all traffic profile phases are completed. Within the test results validation criteria, the DUT/SUT MUST reach the desired value of the target objective in the sustain phase. Measure the minimum, average, and maximum values of TTFB and TTLB. 7.5. Concurrent TCP/HTTP Connection Capacity 7.5.1. Objective Determine the number of concurrent TCP connections that the DUT/ SUT sustains when using HTTP traffic. 7.5.2. Test Setup Testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces and interface type, etc.) MUST be documented. 7.5.3. Test Parameters In this section, benchmarking test specific parameters are defined. Balarajah, et al. Expires 25 April 2023 [Page 39] Internet-Draft Benchmarking Network Security Devices October 2022 7.5.3.1. DUT/SUT Configuration Parameters DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented. 7.5.3.2. Test Equipment Configuration Parameters Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be noted for this benchmarking test: Client IP address ranges defined in Section 4.3.1.3 Server IP address ranges defined in Section 4.3.2.3 Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3 Target concurrent connection: Initial value from product datasheet or the value defined based on the requirement for a specific deployment scenario. Initial concurrent connection: 10% of "Target concurrent connection" Note: Initial concurrent connection is not a KPI to report. This value is configured on the traffic generator and used to perform Step1: "Test Initialization and Qualification" described under Section 7.5.4. Maximum connections per second during ramp up phase: 50% of maximum connections per second measured in benchmarking test TCP/ HTTP Connections per second (Section 7.2) Ramp up time (in traffic load profile for "Target concurrent connection"): "Target concurrent connection" / "Maximum connections per second during ramp up phase" Ramp up time (in traffic load profile for "Initial concurrent connection"): "Initial concurrent connection" / "Maximum connections per second during ramp up phase" The client MUST negotiate HTTP and each client MAY open multiple concurrent TCP connections per server endpoint IP. Each client sends 10 GET requests requesting 1 KByte HTTP response object in the same TCP connection (10 transactions/TCP connection) and the delay (think time) between each transaction MUST be X seconds. Balarajah, et al. Expires 25 April 2023 [Page 40] Internet-Draft Benchmarking Network Security Devices October 2022 X = ("Ramp up time" + "steady state time") /10 The established connections MUST remain open until the ramp down phase of the test. During the ramp down phase, all connections MUST be successfully closed with FIN. 7.5.3.3. Test Results Validation Criteria The following criteria are the test results validation criteria. The Test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile. a. Number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of total attempted transactions. b. Number of terminated TCP connections due to unexpected TCP RST sent by DUT/SUT MUST be less than 0.001% (1 out of 100,000 connections) of total initiated TCP connections. c. During the sustain phase, traffic MUST be forwarded at a constant rate (considered as a constant rate if any deviation of traffic forwarding rate is less than 5%). 7.5.3.4. Measurement Average Concurrent TCP Connections MUST be reported for this benchmarking test. 7.5.4. Test Procedures and Expected Results The test procedure is designed to measure the concurrent TCP connection capacity of the DUT/SUT at the sustaining period of the traffic load profile. The test procedure consists of three major steps: Step 1 ensures the DUT/SUT is able to reach the performance value (Initial concurrent connection) and meets the test results validation criteria when it was very minimally utilized. Step 2 determines whether the DUT/SUT is able to reach the target performance value within the test results validation criteria. Step 3 determines the maximum achievable performance value within the test results validation criteria. This test procedure MAY be repeated multiple times with different IPv4 and IPv6 traffic distributions. Balarajah, et al. Expires 25 April 2023 [Page 41] Internet-Draft Benchmarking Network Security Devices October 2022 7.5.4.1. Step 1: Test Initialization and Qualification Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status. Configure test equipment to establish "Initial concurrent TCP connections" defined in Section 7.5.3.2. Except ramp up time, the traffic load profile MUST be defined as described in Section 4.3.4. During the sustain phase, the DUT/SUT MUST reach the "Initial concurrent TCP connections". The measured KPIs during the sustain phase MUST meet all the test results validation criteria defined in Section 7.5.3.3. If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to "Step 2". 7.5.4.2. Step 2: Test Run with Target Objective Configure test equipment to establish the target objective ("Target concurrent TCP connections"). The test equipment MUST follow the traffic load profile definition (except ramp up time) as described in Section 4.3.4. During the ramp up and sustain phase, the other KPIs such as inspected throughput, TCP connections per second, and application transactions per second MUST NOT reach the maximum value the DUT/SUT can support. The test equipment MUST start to measure and record KPIs defined in Section 7.5.3.4. Continue the test until all traffic profile phases are completed. Within the test results validation criteria, the DUT/SUT is expected to reach the desired value of the target objective in the sustain phase. Follow step 3, if the measured value does not meet the target value or does not fulfill the test results validation criteria. 7.5.4.3. Step 3: Test Iteration Determine the achievable concurrent TCP connections capacity within the test results validation criteria. 7.6. TCP/QUIC Connections per Second with HTTPS Traffic Balarajah, et al. Expires 25 April 2023 [Page 42] Internet-Draft Benchmarking Network Security Devices October 2022 7.6.1. Objective Using HTTPS traffic, determine the sustainable TLS session establishment rate supported by the DUT/SUT under different throughput load conditions. Test iterations MUST include common cipher suites and key strengths as well as forward looking stronger keys. Specific test iterations MUST include ciphers and keys defined in Section 7.6.3.2. For each cipher suite and key strengths, test iterations MUST use a single HTTPS response object size defined in Section 7.6.3.2 to measure connections per second performance under a variety of DUT/SUT security inspection load conditions. 7.6.2. Test Setup Testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces and interface type, etc.) MUST be documented. 7.6.3. Test Parameters In this section, benchmarking test specific parameters are defined. 7.6.3.1. DUT/SUT Configuration Parameters DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented. 7.6.3.2. Test Equipment Configuration Parameters Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test: Client IP address ranges defined in Section 4.3.1.3 Server IP address ranges defined in Section 4.3.2.3 Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3 Target connections per second: Initial value from product datasheet or the value defined based on the requirement for a specific deployment scenario. Balarajah, et al. Expires 25 April 2023 [Page 43] Internet-Draft Benchmarking Network Security Devices October 2022 Initial connections per second: 10% of "Target connections per second" (Note: Initial connections per second is not a KPI to report. This value is configured on the traffic generator and used to perform Step1: "Test Initialization and Qualification" described under Section 7.6.4.) RECOMMENDED ciphers and keys defined in Section 4.3.1.4 The client MUST negotiate HTTPS and close the connection without error immediately after the completion of one transaction. In each test iteration, the client MUST send a GET request requesting a fixed HTTPS response object size. The RECOMMENDED object sizes are 1, 2, 4, 16, and 64 KByte. 7.6.3.3. Test Results Validation Criteria The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole test duration. a. Number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of attempt transactions. b. Number of terminated TCP connections due to unexpected TCP RST sent by DUT/SUT MUST be less than 0.001% (1 out of 100,000 connections) of total initiated TCP connections. If HTTP/3 is used, the number of terminated QUIC connections due to unexpected errors MUST be less than 0.001% (1 out of 100,000 connections) of total initiated QUIC connections. c. During the sustain phase, traffic MUST be forwarded at a constant rate (considered as a constant rate if any deviation of traffic forwarding rate is less than 5%). d. Concurrent TCP connections generation rate MUST be constant during steady state and any deviation of concurrent TCP connections MUST be less than 10%. If HTTP/3 is used, the concurrent QUIC connections generation rate MUST be constant during steady state and any deviation of concurrent QUIC connections MUST be less than 10%. This confirms the DUT opens and closes connections at approximately the same rate. 7.6.3.4. Measurement If HTTP 1.1 or HTTP/2 is used, TCP connections per second MUST be reported for each test iteration (for each object size). Balarajah, et al. Expires 25 April 2023 [Page 44] Internet-Draft Benchmarking Network Security Devices October 2022 If HTTP/3 is used, QUIC connections per second MUST be measured and reported for each test iteration (for each object size). The KPI metric TLS Handshake Rate can be measured in the test using 1 KByte object size. 7.6.4. Test Procedures and Expected Results The test procedure is designed to measure the TCP or QUIC connections per second rate of the DUT/SUT at the sustaining period of the traffic load profile. The test procedure consists of three major steps: Step 1 ensures the DUT/SUT is able to reach the performance value (Initial connections per second) and meets the test results validation criteria when it was very minimally utilized. Step 2 determines whether the DUT/SUT is able to reach the target performance value within the test results validation criteria. Step 3 determines the maximum achievable performance value within the test results validation criteria. This test procedure MAY be repeated multiple times with different IPv4 and IPv6 traffic distributions. 7.6.4.1. Step 1: Test Initialization and Qualification Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status. Configure the traffic load profile of the test equipment to establish "Initial connections per second" as defined in Section 7.6.3.2. The traffic load profile MUST be defined as described in Section 4.3.4. The DUT/SUT MUST reach the "Initial connections per second" before the sustain phase. The measured KPIs during the sustain phase MUST meet all the test results validation criteria defined in Section 7.6.3.3. If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to "Step 2". 7.6.4.2. Step 2: Test Run with Target Objective Configure test equipment to establish "Target connections per second" as defined in Section 7.6.3.2. The test equipment MUST follow the traffic load profile definition as described in Section 4.3.4. During the ramp up and sustain phase, other KPIs such as inspected throughput, concurrent TCP/QUIC connections, and application transactions per second MUST NOT reach the maximum value the DUT/SUT Balarajah, et al. Expires 25 April 2023 [Page 45] Internet-Draft Benchmarking Network Security Devices October 2022 can support. The test results for the specific test iteration MUST NOT be reported as valid results, if the above mentioned KPI (especially inspected throughput) reaches the maximum value. (Example: If the test iteration with 64 KByte of HTTPS response object size reached the maximum inspected throughput limitation of the DUT, the test iteration MAY be interrupted, and the result for 64 KByte should not be reported). The test equipment MUST start to measure and record all specified KPIs. Continue the test until all traffic profile phases are completed. Within the test results validation criteria, the DUT/SUT is expected to reach the desired value of the target objective ("Target connections per second") in the sustain phase. Follow step 3, if the measured value does not meet the target value or does not fulfill the test results validation criteria. 7.6.4.3. Step 3: Test Iteration Determine the achievable connections per second within the test results validation criteria. 7.7. HTTPS Throughput 7.7.1. Objective Determine the sustainable inspected throughput of the DUT/SUT for HTTPS transactions varying the HTTPS response object size. Test iterations MUST include common cipher suites and key strengths as well as forward looking stronger keys. Specific test iterations MUST include the ciphers and keys defined in Section 7.7.3.2. 7.7.2. Test Setup Testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces and interface type, etc.) MUST be documented. 7.7.3. Test Parameters In this section, benchmarking test specific parameters are defined. Balarajah, et al. Expires 25 April 2023 [Page 46] Internet-Draft Benchmarking Network Security Devices October 2022 7.7.3.1. DUT/SUT Configuration Parameters DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented. 7.7.3.2. Test Equipment Configuration Parameters Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test: Client IP address ranges defined in Section 4.3.1.3 Server IP address ranges defined in Section 4.3.2.3 Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3 Target inspected throughput: Aggregated line rate of the interface(s) used in the DUT/SUT or the value defined based on the requirement for a specific deployment scenario. Initial throughput: 10% of "Target inspected throughput" Note: Initial throughput is not a KPI to report. This value is configured on the traffic generator and used to perform Step1: "Test Initialization and Qualification" described under Section 7.7.4. Number of HTTPS response object requests (transactions) per connection: 10 RECOMMENDED ciphers and keys defined in Section 4.3.1.4 RECOMMENDED HTTPS response object size: 1, 16, 64, 256 KByte, and mixed objects defined in Table 4 under Section 7.3.3.2. 7.7.3.3. Test Results Validation Criteria The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile. a. Number of failed Application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of attempt transactions. Balarajah, et al. Expires 25 April 2023 [Page 47] Internet-Draft Benchmarking Network Security Devices October 2022 b. Traffic MUST be generated at a constant rate (considered as a constant rate if any deviation of traffic forwarding rate is less than 5%). c. Concurrent generated TCP connections MUST be constant during steady state and any deviation of concurrent TCP connections MUST be less than 10%. If HTTP/3 is used, the concurrent generated QUIC connections MUST be constant during steady state and any deviation of concurrent QUIC connections MUST be less than 10%. This confirms the DUT opens and closes connections at approximately the same rate. 7.7.3.4. Measurement Inspected Throughput and HTTPS Transactions per Second MUST be reported for each object size. 7.7.4. Test Procedures and Expected Results The test procedure consists of three major steps: Step 1 ensures the DUT/SUT is able to reach the performance value (Initial throughput) and meets the test results validation criteria when it was very minimally utilized. Step 2 determines whether the DUT/SUT is able to reach the target performance value within the test results validation criteria. Step 3 determines the maximum achievable performance value within the test results validation criteria. This test procedure MAY be repeated multiple times with different IPv4 and IPv6 traffic distribution and HTTPS response object sizes. 7.7.4.1. Step 1: Test Initialization and Qualification Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status. Configure the traffic load profile of the test equipment to establish "Initial throughput" as defined in Section 7.7.3.2. The traffic load profile MUST be defined as described in Section 4.3.4. The DUT/SUT MUST reach the "Initial throughput" during the sustain phase. Measure all KPI as defined in Section 7.7.3.4. The measured KPIs during the sustain phase MUST meet the test results validation criteria "a" defined in Section 7.7.3.3. The test results validation criteria "b", and "c" are OPTIONAL for step 1. Balarajah, et al. Expires 25 April 2023 [Page 48] Internet-Draft Benchmarking Network Security Devices October 2022 If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to "Step 2". 7.7.4.2. Step 2: Test Run with Target Objective Configure test equipment to establish the target objective ("Target inspected throughput") defined in Section 7.7.3.2. The test equipment MUST start to measure and record all specified KPIs. Continue the test until all traffic profile phases are completed. Within the test results validation criteria, the DUT/SUT is expected to reach the desired value of the target objective in the sustain phase. Follow step 3, if the measured value does not meet the target value or does not fulfill the test results validation criteria. 7.7.4.3. Step 3: Test Iteration Determine the achievable average inspected throughput within the test results validation criteria. The final test iteration MUST be performed for the test duration defined in Section 4.3.4. 7.8. HTTPS Transaction Latency 7.8.1. Objective Using HTTPS traffic, determine the HTTPS transaction latency when DUT/SUT is running with sustainable HTTPS transactions per second supported by the DUT/SUT under different HTTPS response object sizes. Scenario 1: The client MUST negotiate HTTPS and close the connection immediately after the completion of a single transaction (GET and RESPONSE). Scenario 2: The client MUST negotiate HTTPS and close the connection immediately after the completion of 10 transactions (GET and RESPONSE) within a single TCP or QUIC connection. 7.8.2. Test Setup Testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces and interface type, etc.) MUST be documented. 7.8.3. Test Parameters In this section, benchmarking test specific parameters are defined. Balarajah, et al. Expires 25 April 2023 [Page 49] Internet-Draft Benchmarking Network Security Devices October 2022 7.8.3.1. DUT/SUT Configuration Parameters DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented. 7.8.3.2. Test Equipment Configuration Parameters Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test: Client IP address ranges defined in Section 4.3.1.3 Server IP address ranges defined in Section 4.3.2.3 Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3 RECOMMENDED cipher suites and key sizes defined in Section 4.3.1.4 Target objective for scenario 1: 50% of the connections per second measured in benchmarking test TCP/QUIC Connections per Second with HTTPS Traffic (Section 7.6) Target objective for scenario 2: 50% of the inspected throughput measured in benchmarking test HTTPS Throughput (Section 7.7) Initial objective for scenario 1: 10% of "Target objective for scenario 1" Initial objective for scenario 2: 10% of "Target objective for scenario 2" Note: The Initial objectives are not a KPI to report. These values are configured on the traffic generator and used to perform Step1: "Test Initialization and Qualification" described under Section 7.8.4. HTTPS transaction per TCP or QUIC connection: Test scenario 1 with a single transaction and scenario 2 with 10 transactions HTTPS with GET request requesting a single object. The RECOMMENDED object sizes are 1, 16, and 64 KByte. For each test iteration, the client MUST request a single HTTPS response object size. Balarajah, et al. Expires 25 April 2023 [Page 50] Internet-Draft Benchmarking Network Security Devices October 2022 7.8.3.3. Test Results Validation Criteria The following criteria are the test results validation criteria. The Test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile. a. Number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of attempt transactions. b. Number of terminated TCP connections due to unexpected TCP RST sent by DUT/SUT MUST be less than 0.001% (1 out of 100,000 connections) of total initiated TCP connections. If HTTP/3 is used, the number of terminated QUIC connections due to unexpected errors MUST be less than 0.001% (1 out of 100,000 connections) of total initiated QUIC connections. c. During the sustain phase, traffic MUST be forwarded at a constant rate (considered as a constant rate if any deviation of traffic forwarding rate is less than 5%). d. Concurrent TCP or QUIC connections MUST be constant during steady state and any deviation of concurrent TCP connections MUST be less than 10%. If HTTP/3 is used, the concurrent generated QUIC connections MUST be constant during steady state and any deviation of concurrent QUIC connections MUST be less than 10%. This confirms the DUT opens and closes connections at approximately the same rate. e. After ramp up the DUT/SUT MUST achieve the "Target objective" defined in the parameter Section 7.8.3.2 and remain in that state for the entire test duration (sustain phase). 7.8.3.4. Measurement TTFB (minimum, average, and maximum) and TTLB (minimum, average, and maximum) MUST be reported for each object size. 7.8.4. Test Procedures and Expected Results The test procedure is designed to measure TTFB or TTLB when the DUT/ SUT is operating close to 50% of its maximum achievable connections per second or inspected throughput. The test procedure consists of two major steps: Step 1 ensures the DUT/SUT is able to reach the initial performance values and meets the test results validation criteria when it was very minimally utilized. Step 2 measures the latency values within the test results validation criteria. Balarajah, et al. Expires 25 April 2023 [Page 51] Internet-Draft Benchmarking Network Security Devices October 2022 This test procedure MAY be repeated multiple times with different IP types (IPv4 only, IPv6 only, and IPv4 and IPv6 mixed traffic distribution), HTTPS response object sizes, and single, and multiple transactions per connection scenarios. 7.8.4.1. Step 1: Test Initialization and Qualification Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status. Configure the traffic load profile of the test equipment to establish the "Initial objective" as defined in Section 7.8.3.2. The traffic load profile MUST be defined as described in Section 4.3.4. The DUT/SUT MUST reach the "Initial objective" before the sustain phase. The measured KPIs during the sustain phase MUST meet all the test results validation criteria defined in Section 7.8.3.3. If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to "Step 2". 7.8.4.2. Step 2: Test Run with Target Objective Configure test equipment to establish the "Target objective" defined in Section 7.8.3.2. The test equipment MUST follow the traffic load profile definition as described in Section 4.3.4. The test equipment MUST start to measure and record all specified KPIs. Continue the test until all traffic profile phases are completed. Within the test results validation criteria, the DUT/SUT MUST reach the desired value of the target objective in the sustain phase. Measure the minimum, average, and maximum values of TTFB and TTLB. 7.9. Concurrent TCP/QUIC Connection Capacity with HTTPS Traffic 7.9.1. Objective Determine the number of concurrent TCP/QUIC connections the DUT/SUT sustains when using HTTPS traffic. 7.9.2. Test Setup Testbed setup MUST be configured as defined in Section 4. Any specific testbed configuration changes (number of interfaces and interface type, etc.) MUST be documented. Balarajah, et al. Expires 25 April 2023 [Page 52] Internet-Draft Benchmarking Network Security Devices October 2022 7.9.3. Test Parameters In this section, benchmarking test specific parameters are defined. 7.9.3.1. DUT/SUT Configuration Parameters DUT/SUT parameters MUST conform to the requirements defined in Section 4.2. Any configuration changes for this specific benchmarking test MUST be documented. 7.9.3.2. Test Equipment Configuration Parameters Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The following parameters MUST be documented for this benchmarking test: Client IP address ranges defined in Section 4.3.1.3 Server IP address ranges defined in Section 4.3.2.3 Traffic distribution ratio between IPv4 and IPv6 defined in Section 4.3.1.3 RECOMMENDED cipher suites and key sizes defined in Section 4.3.1.4 Target concurrent connections: Initial value from product datasheet or the value defined based on the requirement for a specific deployment scenario. Initial concurrent connections: 10% of "Target concurrent connections" Note: Initial concurrent connection is not a KPI to report. This value is configured on the traffic generator and used to perform Step1: "Test Initialization and Qualification" described under Section 7.9.4. Connections per second during ramp up phase: 50% of maximum connections per second measured in benchmarking test TCP/QUIC Connections per second with HTTPS Traffic (Section 7.6) Ramp up time (in traffic load profile for "Target concurrent connections"): "Target concurrent connections" / "Maximum connections per second during ramp up phase" Ramp up time (in traffic load profile for "Initial concurrent connections"): "Initial concurrent connections" / "Maximum connections per second during ramp up phase" Balarajah, et al. Expires 25 April 2023 [Page 53] Internet-Draft Benchmarking Network Security Devices October 2022 The client MUST perform HTTPS transactions with persistence and each client can open multiple concurrent connections per server endpoint IP. Each client sends 10 GET requests requesting 1 KByte HTTPS response objects in the same TCP/QUIC connections (10 transactions/connection) and the delay (think time) between each transaction MUST be X seconds. X = ("Ramp up time" + "steady state time") /10 The established connections MUST remain open until the ramp down phase of the test. During the ramp down phase, all connections MUST be successfully closed with FIN. 7.9.3.3. Test Results Validation Criteria The following criteria are the test results validation criteria. The Test results validation criteria MUST be monitored during the whole sustain phase of the traffic load profile. a. Number of failed application transactions (receiving any HTTP response code other than 200 OK) MUST be less than 0.001% (1 out of 100,000 transactions) of total attempted transactions. b. Number of terminated TCP connections due to unexpected TCP RST sent by DUT/SUT MUST be less than 0.001% (1 out of 100,000 connections) of total initiated TCP connections. If HTTP/3 is used, the number of terminated QUIC connections due to unexpected errors MUST be less than 0.001% (1 out of 100,000 connections) of total initiated QUIC connections c. During the sustain phase, traffic MUST be forwarded at a constant rate (considered as a constant rate if any deviation of traffic forwarding rate is less than 5%). 7.9.3.4. Measurement Average Concurrent TCP or QUIC Connections MUST be reported for this benchmarking test. Balarajah, et al. Expires 25 April 2023 [Page 54] Internet-Draft Benchmarking Network Security Devices October 2022 7.9.4. Test Procedures and Expected Results The test procedure is designed to measure the concurrent TCP connection capacity of the DUT/SUT at the sustaining period of the traffic load profile. The test procedure consists of three major steps: Step 1 ensures the DUT/SUT is able to reach the performance value (Initial concurrent connection) and meets the test results validation criteria when it was very minimally utilized. Step 2 determines whether the DUT/SUT is able to reach the target performance value within the test results validation criteria. Step 3 determines the maximum achievable performance value within the test results validation criteria. This test procedure MAY be repeated multiple times with different IPv4 and IPv6 traffic distributions. 7.9.4.1. Step 1: Test Initialization and Qualification Verify the link status of all connected physical interfaces. All interfaces are expected to be in "UP" status. Configure test equipment to establish "Initial concurrent TCP connections" defined in Section 7.9.3.2. Except ramp up time, the traffic load profile MUST be defined as described in Section 4.3.4. During the sustain phase, the DUT/SUT MUST reach the "Initial concurrent connections". The measured KPIs during the sustain phase MUST meet the test results validation criteria "a", and "b" defined in Section 7.9.3.3. If the KPI metrics do not meet the test results validation criteria, the test procedure MUST NOT be continued to "Step 2". 7.9.4.2. Step 2: Test Run with Target Objective Configure test equipment to establish the target objective ("Target concurrent connections"). The test equipment MUST follow the traffic load profile definition (except ramp up time) as described in Section 4.3.4. During the ramp up and sustain phase, the other KPIs such as inspected throughput, TCP or QUIC connections per second, and application transactions per second MUST NOT reach the maximum value that the DUT/SUT can support. The test equipment MUST start to measure and record KPIs defined in Section 7.9.3.4. Continue the test until all traffic profile phases are completed. Balarajah, et al. Expires 25 April 2023 [Page 55] Internet-Draft Benchmarking Network Security Devices October 2022 Within the test results validation criteria, the DUT/SUT is expected to reach the desired value of the target objective in the sustain phase. Follow step 3, if the measured value does not meet the target value or does not fulfill the test results validation criteria. 7.9.4.3. Step 3: Test Iteration Determine the achievable concurrent TCP/QUIC connections within the test results validation criteria. 8. IANA Considerations This document makes no specific request of IANA. The IANA has assigned IPv4 and IPv6 address blocks in [RFC6890] that have been registered for special purposes. The IPv6 address block 2001:2::/48 has been allocated for the purpose of IPv6 Benchmarking [RFC5180] and the IPv4 address block 198.18.0.0/15 has been allocated for the purpose of IPv4 Benchmarking [RFC2544]. This assignment was made to minimize the chance of conflict in case a testing device were to be accidentally connected to the part of the Internet. 9. Security Considerations The primary goal of this document is to provide benchmarking terminology and methodology for next-generation network security devices for use in a laboratory isolated test environment. However, readers should be aware that there is some overlap between performance and security issues. Specifically, the optimal configuration for network security device performance may not be the most secure, and vice-versa. Testing security platforms with working exploits and malware carries risks. Ensure proper access controls are implemented to prevent unintended exposure to vulnerable networks or systems. The cipher suites recommended in this document are for test purposes only. The cipher suite recommendation for a real deployment is outside the scope of this document. Security assessment of an NGFW/NGIPS product could also include an analysis whether any type of uncommon traffic characteristics would have a significant impact on performance. Such performance impacts would allow an attacker to use such specifically crafted traffic as a DoS attack to reduce the remaining performance available to other traffic through the NGFW/NGIPS. Such uncommon traffic characteristics might include for example IP fragmented traffic, specific type of application traffic, or uncommonly high HTTP transaction rate traffic. Balarajah, et al. Expires 25 April 2023 [Page 56] Internet-Draft Benchmarking Network Security Devices October 2022 10. Contributors The following individuals contributed significantly to the creation of this document: Alex Samonte, Amritam Putatunda, Aria Eslambolchizadeh, Chao Guo, Chris Brown, Cory Ford, David DeSanto, Jurrie Van Den Breekel, Michelle Rhines, Mike Jack, Ryan Liles, Samaresh Nair, Stephen Goudreault, Tim Carlin, and Tim Otto. 11. Acknowledgements The authors wish to acknowledge the members of NetSecOPEN for their participation in the creation of this document. Additionally, the following members need to be acknowledged: Anand Vijayan, Chris Marshall, Jay Lindenauer, Michael Shannon, Mike Deichman, Ryan Riese, and Toulnay Orkun. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informative References [fastly] Oku, K. and J. Iyengar, "Can QUIC match TCP's computational efficiency?", 30 April 2020, . [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, . [RFC2647] Newman, D., "Benchmarking Terminology for Firewall Performance", RFC 2647, DOI 10.17487/RFC2647, August 1999, . Balarajah, et al. Expires 25 April 2023 [Page 57] Internet-Draft Benchmarking Network Security Devices October 2022 [RFC3511] Hickman, B., Newman, D., Tadjudin, S., and T. Martin, "Benchmarking Methodology for Firewall Performance", RFC 3511, DOI 10.17487/RFC3511, April 2003, . [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 2008, . [RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton, "Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful", RFC 6815, DOI 10.17487/RFC6815, November 2012, . [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, . [RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, . Balarajah, et al. Expires 25 April 2023 [Page 58] Internet-Draft Benchmarking Network Security Devices October 2022 [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, . [RFC9204] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: Field Compression for HTTP/3", RFC 9204, DOI 10.17487/RFC9204, June 2022, . [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . [Undertow] "An in depth overview of HTTP/2", . [Wiki-NGFW] "", . Appendix A. Test Methodology - Security Effectiveness Evaluation A.1. Test Objective This test methodology verifies the DUT/SUT is able to detect, prevent, and report the vulnerabilities. In this test, background test traffic will be generated to utilize the DUT/SUT. In parallel, a number of malicious traffic will be sent to the DUT/SUT as encrypted and as well as clear text payload formats using a traffic generator. Section 4.2.1 defines the selection of the malicious traffic from the Common Vulnerabilities and Exposures (CVE) list for testing. The following KPIs are measured in this test: * Number of blocked CVEs * Number of bypassed (nonblocked) CVEs * Background traffic performance (verify if the background traffic is impacted while sending CVE toward DUT/SUT) * Accuracy of DUT/SUT statistics in terms of vulnerabilities reporting Balarajah, et al. Expires 25 April 2023 [Page 59] Internet-Draft Benchmarking Network Security Devices October 2022 A.2. Testbed Setup The same testbed MUST be used for security effectiveness tests and as well as for benchmarking test cases defined in Section 7. A.3. Test Parameters In this section, the benchmarking test specific parameters are defined. A.3.1. DUT/SUT Configuration Parameters DUT/SUT configuration parameters MUST conform to the requirements defined in Section 4.2. The same DUT configuration MUST be used for the security effectiveness test and as well as for benchmarking test cases defined in Section 7. The DUT/SUT MUST be configured in inline mode and all detected attack traffic MUST be dropped and the session MUST be reset A.3.2. Test Equipment Configuration Parameters Test equipment configuration parameters MUST conform to the requirements defined in Section 4.3. The same client and server IP ranges MUST be configured as used in the benchmarking test cases. In addition, the following parameters MUST be documented for this benchmarking test: * Background Traffic: 45% of maximum HTTP throughput and 45% of Maximum HTTPS throughput supported by the DUT/SUT (measured with object size 64 KByte in the benchmarking tests "HTTP(S) Throughput" defined in Section 7.3 and Section 7.7). * RECOMMENDED CVE traffic transmission Rate: 10 CVEs per second * It is RECOMMENDED to generate each CVE multiple times (sequentially) at 10 CVEs per second * Ciphers and keys for the encrypted CVE traffic MUST use the same cipher configured for HTTPS traffic related benchmarking tests (Section 7.6 - Section 7.9) A.4. Test Results Validation Criteria The following criteria are the test results validation criteria. The test results validation criteria MUST be monitored during the whole test duration. Balarajah, et al. Expires 25 April 2023 [Page 60] Internet-Draft Benchmarking Network Security Devices October 2022 a. Number of failed application transactions in the background traffic MUST be less than 0.01% of attempted transactions. b. Number of terminated TCP or QUIC connections of the background traffic (due to unexpected errors) MUST be less than 0.01% of total initiated TCP connections in the background traffic. c. During the sustain phase, traffic MUST be forwarded at a constant rate (considered as a constant rate if any deviation of traffic forwarding rate is less than 5%). d. False positive MUST NOT occur in the background traffic. A.5. Measurement The following KPI metrics MUST be reported for this test scenario: Mandatory KPIs: * Blocked CVEs: They MUST be represented in the following ways: - Number of blocked CVEs out of total CVEs - Percentage of blocked CVEs * Unblocked CVEs: They MUST be represented in the following ways: - Number of unblocked CVEs out of total CVEs - Percentage of unblocked CVEs * Background traffic behavior: It MUST be represented in one of the followings ways: - No impact: Considered as "no impact'" if any deviation of traffic forwarding rate is less than or equal to 5 % (constant rate) - Minor impact: Considered as "minor impact" if any deviation of traffic forwarding rate is greater than 5% and less than or equal to10% (i.e. small spikes) - Heavily impacted: Considered as "Heavily impacted" if any deviation of traffic forwarding rate is greater than 10% (i.e. large spikes) or reduced the background HTTP(S) throughput greater than 10% Balarajah, et al. Expires 25 April 2023 [Page 61] Internet-Draft Benchmarking Network Security Devices October 2022 * DUT/SUT reporting accuracy: DUT/SUT MUST report all detected vulnerabilities. Optional KPIs: * List of unblocked CVEs A.6. Test Procedures and Expected Results The test procedure is designed to measure the security effectiveness of the DUT/SUT at the sustaining period of the traffic load profile. The test procedure consists of two major steps. This test procedure MAY be repeated multiple times with different IPv4 and IPv6 traffic distributions. A.6.1. Step 1: Background Traffic Generate background traffic at the transmission rate defined in Appendix A.3.2. The DUT/SUT MUST reach the target objective (HTTP(S) throughput) in sustain phase. The measured KPIs during the sustain phase MUST meet all the test results validation criteria defined in Appendix A.4. If the KPI metrics do not meet the acceptance criteria, the test procedure MUST NOT be continued to "Step 2". A.6.2. Step 2: CVE Emulation While generating background traffic (in sustain phase), send the CVE traffic as defined in the parameter section. The test equipment MUST start to measure and record all specified KPIs. Continue the test until all CVEs are sent. The measured KPIs MUST meet all the test results validation criteria defined in Appendix A.4. In addition, the DUT/SUT should either report the detected vulnerabilities in the log correctly or if, for example, a different naming convention is used, there MUST be reference material available that will allow for verification that the correct vulnerability was detected. This reference material MUST be cited in the report. Balarajah, et al. Expires 25 April 2023 [Page 62] Internet-Draft Benchmarking Network Security Devices October 2022 Appendix B. DUT/SUT Classification This document aims to classify the DUT/SUT into four different categories based on its maximum supported firewall throughput performance number defined in the vendor datasheet. This classification MAY help users to determine specific configuration scales (e.g., number of ACL entries), traffic profiles, and attack traffic profiles, scaling those proportionally to DUT/SUT sizing category. The four different categories are Extra Small (XS), Small (S), Medium (M), and Large (L). The RECOMMENDED throughput values for the following categories are: Extra Small (XS) - Supported throughput less than or equal to1Gbit/s Small (S) - Supported throughput greater than 1Gbit/s and less than or equal to 5Gbit/s Medium (M) - Supported throughput greater than 5Gbit/s and less than or equal to 10Gbit/s Large (L) - Supported throughput greater than 10Gbit/s Authors' Addresses Balamuhunthan Balarajah Berlin Germany Email: bm.balarajah@gmail.com Carsten Rossenhoevel EANTC AG Salzufer 14 10587 Berlin Germany Email: cross@eantc.de Brian Monkman NetSecOPEN 417 Independence Court Mechanicsburg, PA 17050 United States of America Email: bmonkman@netsecopen.org Balarajah, et al. Expires 25 April 2023 [Page 63] ./draft-ietf-ipsecme-ikev1-algo-to-historic-09.txt0000644000764400076440000004065114350125163021507 0ustar iustiniustin Network P. Wouters, Ed. Internet-Draft Aiven Updates: 8221, 8247 (if approved) 19 December 2022 Intended status: Standards Track Expires: 22 June 2023 Deprecation of IKEv1 and obsoleted algorithms draft-ietf-ipsecme-ikev1-algo-to-historic-09 Abstract Internet Key Exchange version 1 (IKEv1) has been deprecated and its specification in RFC2407, RFC2408 and RFC2409 have been moved to Historic status. This document updates RFC 8221 and RFC 8247 to reflect the usage guidelines of old algorithms that are associated with IKEv1, and are not specified or commonly implemented for IKEv2. This document further updates the IANA IKEv2 Transform Type registries to add a Status column where deprecation status can be listed. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Wouters Expires 22 June 2023 [Page 1] Internet-Draft Deprecation of IKEv1 and some algorithms December 2022 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. RFC2407, RFC2408 and RFC2409 are Historic . . . . . . . . . . 3 4. IKEv1 feature equivalents for IKEv2 . . . . . . . . . . . . . 4 4.1. IKEv2 postquantum support . . . . . . . . . . . . . . . . 4 4.2. IKEv2 Labeled IPsec support . . . . . . . . . . . . . . . 4 4.3. IKEv2 Group SA / Multicast support . . . . . . . . . . . 4 5. Deprecating obsolete algorithms . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction IKEv1 has been moved to Historic status. IKEv1 [RFC2409] and its related documents for ISAKMP [RFC2408] and IPsec DOI [RFC2407] were obsoleted by IKEv2 [RFC4306] in December 2005. The latest version of IKEv2 at the time of writing was published in 2014 in [RFC7296]. The Internet Key Exchange (IKE) version 2 has replaced version 1 over 15 years ago. IKEv2 has now seen wide deployment and provides a full replacement for all IKEv1 functionality. No new modifications or new algorithms have been accepted for IKEv1 for at least a decade. IKEv2 addresses various issues present in IKEv1, such as IKEv1 being vulnerable to amplification attacks. Algorithm implementation requirements and usage guidelines for IKEv2 [RFC8247] and ESP/AH [RFC8221] gives guidance to implementors but limits that guidance to avoid broken or weak algorithms. These two RFCs do not deprecate algorithms that have aged and are not in use, but leave these algorithms in a state of "MAY be used" by not mentioning them. This document deprecates those unmentioned algorithms that are no longer advised but for which there are no known attacks resulting in their earlier deprecation. Wouters Expires 22 June 2023 [Page 2] Internet-Draft Deprecation of IKEv1 and some algorithms December 2022 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. RFC2407, RFC2408 and RFC2409 are Historic IKEv1 is deprecated. Systems running IKEv1 should be upgraded and reconfigured to run IKEv2. Systems that support IKEv1 but not IKEv2 are most likely also unsuitable candidates for continued operation: * IKEv1 development ceased over a decade ago and no new work will happen. This poses the risk of unmaintained code in an otherwise supported product which can result in security vulnerabilities. * A number of IKEv1 systems have reached their End of Life and therefor will never be patched by the vendor if a vulnerability is found. * There are vendors that still provide updates for their equipment that supports IKEv1 and IKEv2, but have "frozen" their IKEv1 implementation. Such users might not be aware that they are running unmaintained code with its associated security risks. * IKEv1 systems can be abused for packet amplification attacks, as documented in the Security Bulletin [CVE-2016-5361]. * Great strides have been made in cryptography since IKEv1 development ceased. While some modern cryptographic algorithms were added to IKEv1, interoperability concerns mean that the defacto algorithms negotiated by IKEv1 will consist of dated or deprecated algorithms like AES-CBC, SHA1, and Diffie-Hellman groups 1 or 2. IKEv2 provides state-of-the-art suite of cryptographic algorithms that IKEv1 lacks. IKEv2 is a more secure protocol than IKEv1. For example, IKEv2 offers more modern cryptographic primitives, proper defense against denial of service attacks, improved authentication via EAP methods, PAKE support and is actively worked on with respect to defending against quantum computer attacks. IKEv1-only systems should be upgraded or replaced by systems supporting IKEv2. IKEv2 implementations SHOULD NOT directly import IKEv1 configurations without updating the cryptographic algorithms used. Wouters Expires 22 June 2023 [Page 3] Internet-Draft Deprecation of IKEv1 and some algorithms December 2022 4. IKEv1 feature equivalents for IKEv2 A few notable IKEv1 features are not present in the IKEv2 core specification [RFC7296] but are available for IKEv2 via an additional specification: 4.1. IKEv2 postquantum support IKEv1 and its way of using Preshared Keys (PSKs) protects against quantum computer based attacks. IKEv2 updated its use of PSK to improve the error reporting, but at the expense of post-quantum security. If post-quantum security is required, these systems should be migrated to use IKEv2 Postquantum Preshared Keys (PPK) [RFC8784] 4.2. IKEv2 Labeled IPsec support Some IKEv1 implementations support Labeled IPsec, a method to negotiate an additional Security Context selector to the SPD, but this method was never standardized in IKEv1. Those IKEv1 systems that require Labeled IPsec should migrate to an IKEv2 system supporting Labeled IPsec as specified in [draft-ietf-ipsecme-labeled-ipsec]. 4.3. IKEv2 Group SA / Multicast support The Group Domain of Interpretation (GDOI, [RFC6407]) protocol, based on IKEv1 defines the support for Multicast Group SAs. For IKEv2, this work is currently in progress via [draft-ietf-ipsecme-g-ikev2] 5. Deprecating obsolete algorithms This document deprecates the following algorithms: * Encryption Algorithms: RC5, IDEA, CAST, Blowfish, and the unspecified 3IDEA, ENCR_DES_IV64 and ENCR_DES_IV32 * PRF Algorithms: the unspecified PRF_HMAC_TIGER * Integrity Algorithms: HMAC-MD5-128 * Diffie-Hellman groups: none 6. Security Considerations There are only security benefits by deprecating IKEv1 for IKEv2. Wouters Expires 22 June 2023 [Page 4] Internet-Draft Deprecation of IKEv1 and some algorithms December 2022 The deprecated algorithms have long been in disuse and are no longer actively deployed or researched. It presents an unknown security risk that is best avoided. Additionally, these algorithms not being supported in implementations simplifies those implementations and reduces the accidental use of these deprecated algorithms through misconfiguration or downgrade attacks. 7. IANA Considerations This document instructs IANA to insert the following line at the top of the Notes section of the 'Internet Key Exchange (IKE) Attributes' registry and the '"Magic Numbers" for ISAKMP Protocol' registry: All registries listed below have been closed, see RFCxxxx. [Note to RFC Editor: change RFCxxx to this document's RFC number] This document further instructs IANA to add an additional Status column to the IKEv2 Transform Type registries and mark the following entries as DEPRECATED: Transform Type 1 - Encryption Algorithm IDs Number Name Status ------ --------------- ------ 1 ENCR_DES_IV64 DEPRECATED [this document] 2 ENCR_DES DEPRECATED [RFC8247] 4 ENCR_RC5 DEPRECATED [this document] 5 ENCR_IDEA DEPRECATED [this document] 6 ENCR_CAST DEPRECATED [this document] 7 ENCR_BLOWFISH DEPRECATED [this document] 8 ENCR_3IDEA DEPRECATED [this document] 9 ENCR_DES_IV32 DEPRECATED [this document] Figure 1 Transform Type 2 - Pseudorandom Function Transform IDs Number Name Status ------ ------------ ---------- 1 PRF_HMAC_MD5 DEPRECATED [RFC8247] 3 PRF_HMAC_TIGER DEPRECATED [this document] Figure 2 Wouters Expires 22 June 2023 [Page 5] Internet-Draft Deprecation of IKEv1 and some algorithms December 2022 Transform Type 3 - Integrity Algorithm Transform IDs Number Name Status ------ ----------------- ---------- 1 AUTH_HMAC_MD5_96 DEPRECATED [RFC8247] 3 AUTH_DES_MAC DEPRECATED [RFC8247] 4 AUTH_KPDK_MD5 DEPRECATED [RFC8247] 6 AUTH_HMAC_MD5_128 DEPRECATED [this document] 7 AUTH_HMAC_SHA1_160 DEPRECATED [this document] Figure 3 Transform Type 4 - Diffie Hellman Group Transform IDs Number Name Status ------ ---------------------------- ---------- 1 768-bit MODP Group DEPRECATED [RFC8247] 22 1024-bit MODP Group with 160-bit Prime Order Subgroup DEPRECATED [RFC8247] Figure 4 All entries not mentioned here should receive no value in the new Status field. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, "Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 8247, DOI 10.17487/RFC8247, September 2017, . 8.2. Informative References Wouters Expires 22 June 2023 [Page 6] Internet-Draft Deprecation of IKEv1 and some algorithms December 2022 [CVE-2016-5361] National Institute of Science and Technology (NIST), "National Vulnerability Database - CVE-2016-5361", 16 June 2016, . [draft-ietf-ipsecme-g-ikev2] Smyslov, V. and B. Weis, "Group Key Management using IKEv2", Work in Progress, Internet-Draft, draft-ietf- ipsecme-g-ikev2, 11 January 2021, . [draft-ietf-ipsecme-labeled-ipsec] Wouters, P. and S. Prasad, "Labeled IPsec Traffic Selector support for IKEv2", Work in Progress, Internet-Draft, draft-ietf-ipsecme-labeled-ipsec, 25 October 2021, . [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, DOI 10.17487/RFC2407, November 1998, . [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998, . [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, . [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005, . [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 2011, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . Wouters Expires 22 June 2023 [Page 7] Internet-Draft Deprecation of IKEv1 and some algorithms December 2022 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, October 2017, . [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, "Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security", RFC 8784, DOI 10.17487/RFC8784, June 2020, . Author's Address Paul Wouters (editor) Aiven Email: paul.wouters@aiven.io Wouters Expires 22 June 2023 [Page 8] ./draft-ietf-ccamp-gmpls-otn-b100g-applicability-15.txt0000644000764400076440000010507614336054045022323 0ustar iustiniustin Internet Engineering Task Force Q. Wang, Ed. Internet-Draft ZTE Corporation Intended status: Informational R. Valiveti, Ed. Expires: 22 May 2023 Infinera Corp H. Zheng, Ed. Huawei H. Helvoort Hai Gaoming B.V S. Belotti Nokia 18 November 2022 Applicability of GMPLS for Beyond 100G Optical Transport Network draft-ietf-ccamp-gmpls-otn-b100g-applicability-15 Abstract This document examines the applicability of using existing GMPLS routing and signalling mechanisms to set up Optical Data Unit-k (ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in the 2020 version of G.709. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 May 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Wang, et al. Expires 22 May 2023 [Page 1] Internet-Draft B100G Extensions November 2022 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. OTN terminology used in this document . . . . . . . . . . . . 3 3. Overview of the OTUCn/ODUCn in G.709 . . . . . . . . . . . . 5 3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Tributary Slot Granularity . . . . . . . . . . . . . . . 8 3.4. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 8 3.5. Client Signal Mappings . . . . . . . . . . . . . . . . . 9 4. GMPLS Implications and Applicability . . . . . . . . . . . . 10 4.1. TE-Link Representation . . . . . . . . . . . . . . . . . 10 4.2. Implications and Applicability for GMPLS Signalling . . . 11 4.3. Implications and Applicability for GMPLS Routing . . . . 12 5. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 13 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Possible Future Work . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The current GMPLS routing [RFC7138] and signalling [RFC7139] extensions support the control of Optical Transport Network (OTN) signals and capabilities that were defined in the 2012 version of G.709 [ITU-T_G709_2012]. In 2016 a further version of G.709 was published: [ITU-T_G709_2016]. This version introduced higher rate Optical Transport Unit (OTU) and Optical Data Unit (ODU) signals, termed OTUCn and ODUCn respectively, which have a nominal rate of n x 100 Gbit/s. According to the definition in [ITU-T_G709_2016], OTUCn and ODUCn perform only the digital section layer role and ODUCn supports only ODUk clients. This document focuses on the use of existing GMPLS mechanisms to set up ODUk (e.g., ODUflex) Label Switched Paths (LSPs) over ODUCn links, independently from how these links have been set up. Wang, et al. Expires 22 May 2023 [Page 2] Internet-Draft B100G Extensions November 2022 Because [ITU-T_G709_2020] does not introduce any new features to OTUCn and ODUCn compared to [ITU-T_G709_2016], this document starts with [ITU-T_G709_2020] by first presenting an overview of the OTUCn and ODUCn signals, and then analyzing how the current GMPLS routing and signalling mechanisms can be utilized to set up ODUk (e.g., ODUflex) LSPs over ODUCn links. This document assumes that the reader is familiar with OTN, GMPLS, and how GMPLS is applied in OTN networks. As such, this document doesn't provide any background pertaining to OTN networks that included links with capacities of 100G or less; this background could be found in documents such as [RFC7062] and [RFC7096]. This document provides an overview of the dataplane primitives that enable links with capacities greater than 100G, and analyses the extensions that would be required in the current GMPLS routing & signaling mechanisms to support the evolution in OTN networks. 2. OTN terminology used in this document * FlexO: Flexible OTN information structure. This information structure is usually with a specific bit rate and frame format, consisting of overhead and payload, which is used as a group for the transport of an OTUCn signal. * LSP: Label Switched Path. * ODU: Optical Data Unit. An ODU has the frame structure and overhead, as defined in Figure 12-1 of [ITU-T_G709_2020]. ODUs can be formed in two ways: a) by encapsulating a single non-OTN client (such as SONET/SDH, Ethernet) b) multiplexing lower-rate ODUs. In general, the ODU layer represents the path layer in OTN networks. The only exception is the ODUCn signal (defined below) which is defined to be a section layer signal. In the classification based on bitrates of the ODU signals, ODUs are of two types: Fixed rate, and flexible rate. Flexible rate ODU(s), called "ODUFlex" have a rate that is 239/238 times the bit rate of the client signal it encapsulates. * ODUk: Optical Data Unit-k, where k is one of {0, 1, 2, 2e, 3, 4}. The term ODUk references to an ODU whose bit rate is fully specified by the index k. The bit rates of the ODUk signal for k = {0, 1, 2, 2e, 3, 4} are approximately 1.25G, 2.5G, 10G, 10.3G, 40G, 100G respectively. Wang, et al. Expires 22 May 2023 [Page 3] Internet-Draft B100G Extensions November 2022 * ODUflex: Optical Data Unit - flexible rate. An ODUflex has the same frame structure as a "generic" ODU, but with rate that is a fixed multiple of the bitrate of the client signal it encapsulates. ITU-T defines specific ODUflex containers that are required to transport specific clients such as 50GE, 200GE, 400GE, etc. * ODUC: Optical Data Unit -C; this signal has a bandwidth of approximately 100G, and is of a slightly higher bit rate than the fixed rate ODU4 signal. This signal has the format defined in Figure 12-1 of [ITU-T_G709_2020]. This signal represents the building block for constructing a higher rate signal called ODUCn (defined below). * ODUCn: Optical Data Unit-Cn; Cn indicates the bit rate of approximately n*100G. This frame structure consists of "n" interleaved, frame and multi-frame synchronous instances of the ODUC signal, each of which has the format defined in Figure 12-1 of [ITU-T_G709_2020]. * OPUC: Optical Payload Unit -C; with a payload of approximately 100G. This structure represents the payload area of the ODUC signal. * OPUCn: Optical Payload Unit-Cn. Where Cn indicates that the bit rate is approximately n*100G. This structure represents the payload area of the ODUCn signal. * OTUC: Optical Transport Unit -C; with a bandwidth of approximately 100G. This signal forms the building block of the OTUCn signal defined below, which has a bandwidth of approximately n*100G. * OTUCn: Fully standardized Optical Transport Unit-Cn. This frame structure is realized by extending the ODUCn signal with the OTU layer overhead. The structure of this signal is illustrated in Figure 11-1 of [ITU-T_G709_2020]. Note that the term "fully standardized" is defined by ITU-T in [ITU-T_G709_2020]:Section 6.1.1. * OTUCn-M: This signal is an extension of the OTUCn signal introduced above. This signal contains the same amount of overhead as the OTUCn signal, but contains a reduced amount of payload area. Specifically, the payload area consists of M 5 Gbit/s tributary slots - where M is less than 20*n, which is the number of tributary slots in the OTUCn signal. * OTN: Optical Transport Network. Wang, et al. Expires 22 May 2023 [Page 4] Internet-Draft B100G Extensions November 2022 * PSI: OPU Payload Structure Indicator. This is a 256-byte signal that describes the composition of the OPU signal. This field is a concatenation of the Payload type (PT) and the Multiplex Structure Indicator (MSI) defined below. * MSI: Multiplex Structure Indicator. This structure indicates the grouping of the tributary slots in an OPU payload area that realizes a client signal which is multiplexed into an OPU. The individual clients multiplexed into the OPU payload area are distinguished by the Tributary Port Number (TPN). * TPN: Tributary Port Number. The tributary port number is used to indicate the port number of the client signal that is being transported in one specific tributary slot. Detailed descriptions of these terms can be found in [ITU-T_G709_2020]. 3. Overview of the OTUCn/ODUCn in G.709 This section provides an overview of OTUCn/ODUCn signals defined in [ITU-T_G709_2020]. The text in this section is purely descriptive and is not normative. For a full description of OTUCn/ODUCn signals please refer to [ITU-T_G709_2020]. In the event of any discrepancy between this text and [ITU-T_G709_2020], that other document is definitive. 3.1. OTUCn In order to carry client signals with rates greater than 100 Gbit/s, [ITU-T_G709_2020] takes a general and scalable approach that decouples the rates of OTU signals from the client rate. The new OTU signal is called OTUCn, and this signal is defined to have a rate of (approximately) n*100G. The following are the key characteristics of the OTUCn signal: * The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals perform digital section roles only (see [ITU-T_G709_2020]:Section 6.1.1) * The OTUCn signals can be viewed as being formed by interleaving n synchronous OTUC signals (which are labeled 1, 2, ..., n). * Each of the OTUC instances has the same overhead as the standard OTUk signal in [ITU-T_G709_2020]. Note that the OTUC signal doesn't include the FEC columns illustrated in [ITU-T_G709_2020]:Figure 11-1. The OTUC signal includes an ODUC. Wang, et al. Expires 22 May 2023 [Page 5] Internet-Draft B100G Extensions November 2022 * The OTUC signal has a slightly higher rate compared to the OTU4 signal (without FEC); this is to ensure that the OPUC payload area can carry an ODU4 signal. * The combined signal OTUCn has n instances of OTUC overhead, and n instances of ODUC overhead. The OTUCn, ODUCn and OPUCn signal structures are presented in a (physical) interface independent manner, by means of n OTUC, ODUC and OPUC instances that are marked #1 to #n. OTUCn interfaces can be categorized as follows, based on the type of peer network element: * inter-domain interfaces: These types of interfaces are used for connecting OTN edge nodes to (a) client equipment (e.g. routers) or (b) hand-off points from other OTN networks. ITU-T Recommendation [ITU-T_G709.1] specifies a flexible interoperable short-reach OTN interface over which an OTUCn (n >=1) is transferred, using bonded Flexible OTN information structure (FlexO) interfaces which belong to a FlexO group. * intra-domain interfaces: In these cases, the OTUCn is transported using a proprietary (vendor specific) encapsulation, FEC etc. It is also possible to transport OTUCn for intra-domain links using FlexO. 3.1.1. OTUCn-M The standard OTUCn signal has the same rate as that of the ODUCn signal. This implies that the OTUCn signal can only be transported over wavelength groups which have a total capacity of multiples of (approximately) 100G. Modern optical interfaces support a variety of bit rates per wavelength, depending on the reach requirements for the optical path. If the total rate of the ODUk LSPs planned to be carried over an ODUCn link is smaller than n*100G, it is possible to "crunch" the OTUCn not to transmit the unused tributary slots. ITU-T supports the notion of a reduced rate OTUCn signal, termed the OTUCn- M. The OTUCn-M signal is derived from the OTUCn signal by retaining all the n instances of overhead (one per OTUC instance) but with only M (M is less than 20*n) OPUCn tributary slots available to carry ODUk LSPs. Wang, et al. Expires 22 May 2023 [Page 6] Internet-Draft B100G Extensions November 2022 3.2. ODUCn The ODUCn signal defined in [ITU-T_G709_2020] can be viewed as being formed by the appropriate interleaving of content from n ODUC signal instances. The ODUC frames have the same structure as a standard ODU in the sense that it has the same overhead and payload areas, but has a higher rate since its payload area can embed an ODU4 signal. The ODUCn is a multiplex section ODU signal, and is mapped into an OTUCn signal which provides the regenerator section layer. In some scenarios, the ODUCn, and OTUCn signals will be co-terminated, i.e. they will have identical source/sink locations (see Figure 1). In this figure, the term "OTN Switch" has the same meaning as that used in [RFC7138]:Section 3. [ITU-T_G709_2020] allows for the ODUCn signal to pass through one or more digital regenerator nodes (shown as Nodes B, C in Figure 2) which will terminate the OTUCn layer, but will pass the regenerated (but otherwise untouched) ODUCn towards a different OTUCn interface where a fresh OTUCn layer will be initiated. This process is termed as "ODUCn regeneration" in [ITU-T_G872]:Section 7.1. In this example, the ODUCn is carried by 3 OTUCn segments. Specifically, the OPUCn signal flows through these regenerators unchanged. That is, the set of client signals, their TPNs, tributary-slot allocation remains unchanged. +--------+ +--------+ | +-----------+ | | OTN |-----------| OTN | | Switch +-----------+ Switch | | A | | B | | +-----------+ | +--------+ +--------+ <--------ODUCn-------> <-------OTUCn------> Figure 1: ODUCn signal Wang, et al. Expires 22 May 2023 [Page 7] Internet-Draft B100G Extensions November 2022 +---------+ +--------+ +--------+ +--------+ | +--------+ | | +----------+ | | OTN |--------| OTN | | OTN |----------| OTN | | Switch +--------+ Regen +--------+ Regen +----------+ Switch | | A | | B | | C | | D | | +--------+ | | +----------+ | +---------+ +--------+ +--------+ +--------+ <-------------------------ODUCn--------------------------> <---------------><-----------------><------------------> OTUCn OTUCn OTUCn Figure 2: ODUCn signal - multihop 3.3. Tributary Slot Granularity [ITU-T_G709_2012] introduced the support for 1.25 Gbit/s granular tributary slots in OPU2, OPU3, and OPU4 signals. [ITU-T_G709_2020] defined the OPUC with a 5 Gbit/s tributary slot granularity. This means that the ODUCn signal has 20*n tributary slots (of 5 Gbit/s capacity). The range of tributary port number (TPN) is 10*n instead of 20*n, which restricts the maximum client signals that could be carried over one single ODUC1. 3.4. Structure of OPUCn MSI with Payload type 0x22 As mentioned above, the OPUCn signal has 20*n 5 Gbit/s tributary slots (TSs). The OPUCn MSI field has a fixed length of 40*n bytes and indicates the availability and occupation of each TS. Two bytes are used for each of the 20*n tributary slots, and each such information structure has the following format ([ITU-T_G709_2020]:Section 20.4.1): * The TS availability bit indicates if the tributary slot is available or unavailable * The TS occupation bit indicates if the tributary slot is allocated or unallocated * The tributary port number (14 bits) of the client signal that is being carried in this specific TS. A flexible assignment of tributary port to tributary slots is possible. Numbering of tributary ports is from 1 to 10*n. The concatenation of the OPUCn payload type (PT) and the MSI field is carried over the overhead byte designated as PSI in [ITU-T_G709_2020]:Figure 15-6. Wang, et al. Expires 22 May 2023 [Page 8] Internet-Draft B100G Extensions November 2022 3.5. Client Signal Mappings The approach taken by the ITU-T to map non-OTN client signals to the appropriate ODU containers is as follows: * All client signals are mapped into an ODUj, or ODUk (e.g., ODUflex) as specified in clause 17 of [ITU-T_G709_2020]. * The terms ODUj & ODUk are used in a multiplexing scenario, with ODUj being a low-order ODU which is multiplexed into ODUk, a high- order ODU. As Figure 3 illustrates, the ODUCn is also a high- order ODU into which other ODUs can be multiplexed; the ODUCn itself cannot be multiplexed into any higher rate ODU signal; it is defined to be a section level signal. * ODUflex signals are low-order signals only. If the ODUflex entities have rates of 100G or less, they can be transported over either an ODUk (k=1..4) or an ODUCn. For ODUflex connections with rates greater than 100G, ODUCn is required. * ODU Virtual Concatenation has been deprecated. This simplifies the network, and the supporting hardware since multiple different mappings for the same client are no longer necessary. Note that legacy implementations that transported sub-100G clients using ODU VCAT shall continue to be supported. Wang, et al. Expires 22 May 2023 [Page 9] Internet-Draft B100G Extensions November 2022 Clients (e.g. SONET/SDH, Ethernet) | | | | | | | | | | | | | | | | | | +---+---+---+----+ | | | | OPUj | | | | +----------------+ | | | | ODUj | | | | +----------------+----------------------+---+---+----------+ | | | OPUk | +----------------------------------------------------------+ | | | ODUk k in {0,1,2,2e,3,4,flex}| +-------------------------+-----+--------------------------+ | | | | | OTUk, OTUk-SC, OTUk-V | | OPUCn | +-------------------------+ +--------------------------+ | | | ODUCn | +--------------------------+ | | | OTUCn | +--------------------------+ Figure 3: Digital Structure of OTN interfaces (from G.709:Figure 6-1) 4. GMPLS Implications and Applicability 4.1. TE-Link Representation Section 3 of RFC7138 describes how to represent G.709 OTUk/ODUk with TE-Links in GMPLS. In the same manner, OTUCn links can also be represented as TE-links. Figure 4 below provides an illustration of a one-hop OTUCn TE link. +----------+ +---------+ | OTN | | OTN | | Switch +-------------------+ Switch | | A | | B | +----------+ +---------+ |<---------OTUCn Link---------->| |<---------TE-Link------------->| Figure 4: OTUCn TE-Links Wang, et al. Expires 22 May 2023 [Page 10] Internet-Draft B100G Extensions November 2022 It is possible to create TE-links that span more than one hop by creating forward adjacencies (FA) between non-adjacent nodes (see Figure 5). In this illustration, the nodes B and C are performing the ODUCn regeneration function described in [ITU-T_G872]:Section 7.1, and are not electrically switching the ODUCn signal from one interface to another. As in the one-hop case, Multiple-hop TE-links advertise the ODU switching capability. +--------+ +--------+ +--------+ +---------+ | OTN | | OTN | | OTN | | OTN | | Switch |<------->| regen |<-------->| regen |<------->| Switch | | A | OTUCn | B | OTUCn | C | OTUCn | D | +--------+ Link +--------+ Link +--------+ Link +---------+ |<-------------------- ODUCn Link -------------------->| |<---------------------- TE-Link --------------------->| Figure 5: Multiple-hop ODUCn TE-Link The two endpoints of a TE-Link are configured with the supported resource information, which may include whether the TE-Link is supported by an ODUCn or an ODUk or an OTUk, as well as the link attribute information (e.g., slot granularity, list of available tributary slot). 4.2. Implications and Applicability for GMPLS Signalling Once the ODUCn TE-Link is configured, the GMPLS mechanisms defined in [RFC7139] can be reused to set up ODUk/ODUflex LSPs with no changes. As the resource on the ODUCn link which can be seen by the client ODUk/ODUflex is a set of 5 Gbit/s slots, the label defined in [RFC7139] is able to accommodate the requirement of the setup of ODUk/ODUflex over ODUCn link. In [RFC7139], the OTN-TDM GENERALIZED_LABEL object is used to indicate how the lower order (LO) ODUj signal is multiplexed into the higher order (HO) ODUk link. In a similar manner, the OTN-TDM GENERALIZED_LABEL object is used to indicate how the ODUk signal is multiplexed into the ODUCn link. The ODUk Signal Type is indicated by Traffic Parameters. The IF_ID RSVP_HOP object provides a pointer to the interface associated with TE-Link and therefore the two nodes terminating the TE-link know (by internal/local configuration) the attributes of the ODUCn TE Link. Since the TPN defined in [ITU-T_G709_2020] for an ODUCn link has 14 bits, while this field in [RFC7139] only has 12 bits, some extension work will eventually be needed. Given that a 12-bit TPN field can support ODUCn links with up to n=400 (i.e. 40Tbit/s links), this need is not urgent. Wang, et al. Expires 22 May 2023 [Page 11] Internet-Draft B100G Extensions November 2022 An example is given in Figure 6 to illustrate the label format defined in [RFC7139] for multiplexing ODU4 onto ODUC10. One ODUC10 has 200 5 Gbit/s slots, and twenty of them are allocated to the ODU4. With this label encoding, only 20 out of the 200 bits mask are non- zero, and is very inefficient. The inefficiency grows for larger values of "n" and an optimized label format may be desirable. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TPN = 3 | Reserved | Length = 200 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0| Padding Bits(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Label format 4.3. Implications and Applicability for GMPLS Routing For routing, it is deemed that no extension to current mechanisms defined in [RFC7138] is needed. Because, once an ODUCn link is up, the resources that need to be advertised are the resources that are exposed by this ODUCn link and the multiplexing hierarchy on this link. Since the ODUCn link is the lowest layer of the ODU multiplexing hierarchy involving multiple ODU layers, and there is a 1:1 correspondence with the OTUCn signal, there is no need to explicitly define a new value to represent the ODUCn signal type in the OSPF-TE routing protocol. The OSPF-TE extension defined in section 4 of [RFC7138] can be reused to advertise the resource information on the ODUCn link to help finish the setup of ODUk/ODUflex. Wang, et al. Expires 22 May 2023 [Page 12] Internet-Draft B100G Extensions November 2022 5. Authors (Full List) Qilei Wang (editor) ZTE Nanjing, China Email: wang.qilei@zte.com.cn Radha Valiveti (editor) Infinera Corp Sunnyvale, CA, USA Email: rvaliveti@infinera.com Haomian Zheng (editor) Huawei CN EMail: zhenghaomian@huawei.com Huub van Helvoort Hai Gaoming B.V EMail: huubatwork@gmail.com Sergio Belotti Nokia EMail: sergio.belotti@nokia.com 6. Contributors Iftekhar Hussain, Infinera Corp, Sunnyvale, CA, USA, IHussain@infinera.com Daniele Ceccarelli, Ericsson, daniele.ceccarelli@ericsson.com Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com Fatai Zhang, Huawei,zhangfatai@huawei.com Wang, et al. Expires 22 May 2023 [Page 13] Internet-Draft B100G Extensions November 2022 Italo Busi, Huawei,italo.busi@huawei.com Dieter Beller, Nokia, Dieter.Beller@nokia.com Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn Zafar Ali, Cisco Systems, zali@cisco.com Daniel King, d.king@lancaster.ac.uk Manoj Kumar, Cisco Systems, manojk2@cisco.com Antonello Bonfanti, Cisco Systems, abonfant@cisco.com Yuji Tochio, Fujitsu, tochio@fujitsu.com 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations This document analyzed the applicability of protocol extensions in [RFC7138] and [RFC7139] for use in the 2020 version of G.709 [ITU- T_G709_2020] and found that no new extensions are needed. Therefore, this document introduced no new security considerations to the existing signaling and routing protocols beyond those already described in [RFC7138] and [RFC7139]. Please refer to [RFC7138] and [RFC7139] for further details of the specific security measures. Additionally, [RFC5920] addresses the security aspects that are relevant in the context of GMPLS. 9. References 9.1. Normative References [ITU-T_G709_2020] ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 06/2020", June 2020. [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . Wang, et al. Expires 22 May 2023 [Page 14] Internet-Draft B100G Extensions November 2022 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and J. Drake, "Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, . [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., and K. Pithewan, "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks", RFC 7139, DOI 10.17487/RFC7139, March 2014, . 9.2. Informative References [ITU-T_G709.1] ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface; 2018", 2018. [ITU-T_G709_2012] ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 02/2012", February 2012. [ITU-T_G709_2016] ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 07/2016", July 2016. [ITU-T_G872] ITU-T, "ITU-T G.872: Architecture of Optical Transport Networks; 12/2019", December 2019. [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", RFC 7062, DOI 10.17487/RFC7062, November 2013, . [RFC7096] Belotti, S., Ed., Grandi, P., Ceccarelli, D., Ed., Caviglia, D., Zhang, F., and D. Li, "Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)", RFC 7096, DOI 10.17487/RFC7096, January 2014, . Wang, et al. Expires 22 May 2023 [Page 15] Internet-Draft B100G Extensions November 2022 Appendix A. Possible Future Work As noted in Section Section 4.2, the GMPLS TPN field in Section 6.1 of [RFC7139] is only 12 bits whereas an ODUCn link could require up to 14 bits. Although the need is not urgent, future work could extend the TPN field in GMPLS to use the Reserved bits immediately adjacent. This would need to be done in a backward compatible way. Section Section 4.2 further notes that the current encoding of GMPLS labels can be inefficient for larger values of n in ODUCn. Future work might examine a more compact, yet generalized label encoding to address this issue should it be felt, after analysis of the operational aspects, that the current encoding is causing problems. Introduction of a new label encoding would need to be done using a new LSP Encoding Type / G-PID pairing to ensure correct interoperability. Authors' Addresses Qilei Wang (editor) ZTE Corporation Nanjing China Email: wang.qilei@zte.com.cn Radha Valiveti (editor) Infinera Corp Sunnyvale USA Email: rvaliveti@infinera.com Haomian Zheng (editor) Huawei China Email: zhenghaomian@huawei.com Huub van Helvoort Hai Gaoming B.V Almere Netherlands Email: huubatwork@gmail.com Sergio Belotti Nokia Wang, et al. Expires 22 May 2023 [Page 16] Internet-Draft B100G Extensions November 2022 Email: sergio.belotti@nokia.com Wang, et al. Expires 22 May 2023 [Page 17] ./draft-ietf-teep-architecture-19.txt0000644000764400076440000027527214325551710017315 0ustar iustiniustin TEEP M. Pei Internet-Draft Broadcom Intended status: Informational H. Tschofenig Expires: 27 April 2023 Arm Limited D. Thaler Microsoft D. Wheeler Amazon 24 October 2022 Trusted Execution Environment Provisioning (TEEP) Architecture draft-ietf-teep-architecture-19 Abstract A Trusted Execution Environment (TEE) is an environment that enforces that any code within that environment cannot be tampered with, and that any data used by such code cannot be read or tampered with by any code outside that environment. This architecture document motivates the design and standardization of a protocol for managing the lifecycle of trusted applications running inside such a TEE. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Pei, et al. Expires 27 April 2023 [Page 1] Internet-Draft TEEP Architecture October 2022 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 8 3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 8 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 9 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. System Components . . . . . . . . . . . . . . . . . . . . 9 4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 12 4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 14 4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 16 4.4.1. Example: Application Delivery Mechanisms in Intel SGX . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4.2. Example: Application Delivery Mechanisms in Arm TrustZone . . . . . . . . . . . . . . . . . . . . . . 18 4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 18 5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 20 5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 22 5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 22 5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 22 5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 23 5.5. Message Security . . . . . . . . . . . . . . . . . . . . 23 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 24 6.2. TEEP Broker Implementation Consideration . . . . . . . . 24 6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 25 6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 26 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 29 9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 30 9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 31 9.4. CA Compromise or Expiry of CA Certificate . . . . . . . . 32 9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 32 9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 33 9.7. TEE Certificate Expiry and Renewal . . . . . . . . . . . 34 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 34 9.9. REE Privacy . . . . . . . . . . . . . . . . . . . . . . . 35 Pei, et al. Expires 27 April 2023 [Page 2] Internet-Draft TEEP Architecture October 2022 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 13. Informative References . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction Applications executing in a device are exposed to many different attacks intended to compromise the execution of the application or reveal the data upon which those applications are operating. These attacks increase with the number of other applications on the device, with such other applications coming from potentially untrustworthy sources. The potential for attacks further increases with the complexity of features and applications on devices, and the unintended interactions among those features and applications. The risk of attacks on a system increases as the sensitivity of the applications or data on the device increases. As an example, exposure of emails from a mail client is likely to be of concern to its owner, but a compromise of a banking application raises even greater concerns. The Trusted Execution Environment (TEE) concept is designed to let applications execute in a protected environment that enforces that any code within that environment cannot be tampered with, and that any data used by such code cannot be read or tampered with by any code outside that environment, including by a commodity operating system (if present). In a system with multiple TEEs, this also means that code in one TEE cannot be read or tampered with by code in another TEE. This separation reduces the possibility of a successful attack on application components and the data contained inside the TEE. Typically, application components are chosen to execute inside a TEE because those application components perform security sensitive operations or operate on sensitive data. An application component running inside a TEE is commonly referred to (e.g., in [GPTEE], [OP-TEE], etc.) as a Trusted Application (TA), while an application running outside any TEE, i.e., in the Rich Execution Environment (REE), is referred to as an Untrusted Application (UA). In the example of a banking application, code that relates to the authentication protocol could reside in a TA while the application logic including HTTP protocol parsing could be contained in the Untrusted Application. In addition, processing of credit card numbers or account balances could be done in a TA as it is sensitive data. The precise code split is ultimately a decision of the developer based on the assets the person wants to protect according to the threat model. Pei, et al. Expires 27 April 2023 [Page 3] Internet-Draft TEEP Architecture October 2022 TEEs are typically used in cases where software or data assets need to be protected from unauthorized access where threat actors may have physical or administrative access to a device. This situation arises for example in gaming consoles where anti-cheat protection is a concern, devices such as ATMs or IoT devices placed in locations where attackers might have physical access, cell phones or other devices used for mobile payments, and hosted cloud environments. Such environments can be thought of as hybrid devices where one user or administrator controls the REE and a different (remote) user or administrator controls a TEE in the same physical device. It may also be the case in some constrained devices that there is no REE (only a TEE) and there may be no local "user" per se, only a remote TEE administrator. For further discussion of such confidential computing use cases and threat model, see [CC-Overview] and [CC-Technical-Analysis]. TEEs use hardware enforcement combined with software protection to secure TAs and their data. TEEs typically offer a more limited set of services to TAs than is normally available to Untrusted Applications. Not all TEEs are the same, however, and different vendors may have different implementations of TEEs with different security properties, different features, and different control mechanisms to operate on TAs. Some vendors may themselves market multiple different TEEs with different properties attuned to different markets. A device vendor may integrate one or more TEEs into their devices depending on market needs. To simplify the life of TA developers interacting with TAs in a TEE, an interoperable protocol for managing TAs running in different TEEs of various devices is needed. This software update protocol needs to make sure that compatible trusted and untrusted components (if any) of an application are installed on the correct device. In this TEE ecosystem, there often arises a need for an external trusted party to verify the identity, claims, and permissions of TA developers, devices, and their TEEs. This external trusted party is the Trusted Application Manager (TAM). The Trusted Execution Environment Provisioning (TEEP) protocol addresses the following problems: * An installer of an Untrusted Application that depends on a given TA wants to request installation of that TA in the device's TEE so that the installation of Untrusted Application can complete, but the TEE needs to verify whether such a TA is actually authorized to run in the TEE and consume potentially scarce TEE resources. Pei, et al. Expires 27 April 2023 [Page 4] Internet-Draft TEEP Architecture October 2022 * A TA developer providing a TA whose code itself is considered confidential wants to determine security-relevant information of a device before allowing their TA to be provisioned to the TEE within the device. An example is the verification of the type of TEE included in a device and that it is capable of providing the security protections required. * A TEE in a device needs to determine whether an entity that wants to manage a TA in the device is authorized to manage TAs in the TEE, and what TAs the entity is permitted to manage. * A Device Administrator wants to determine if a TA exists (is installed) on a device (in the TEE), and if not, install the TA in the TEE. * A Device Administrator wants to check whether a TA in a device's TEE is the most up-to-date version, and if not, update the TA in the TEE. * A Device Administrator wants to remove a TA from a device's TEE if the TA developer is no longer maintaining that TA, when the TA has been revoked, or is not used for other reasons anymore (e.g., due to an expired subscription). For TEEs that simply verify and load signed TA's from an untrusted filesystem, classic application distribution protocols can be used without modification. The problems in the bullets above, on the other hand, require a new protocol, i.e., the TEEP protocol. The TEEP protocol is a solution for TEEs that can install and enumerate TAs in a TEE-secured location where another domain-specific protocol standard (e.g., [GSMA], [OTRP]) that meets the needs is not already in use. 2. Terminology The following terms are used: * App Store: An online location from which Untrusted Applications can be downloaded. * Device: A physical piece of hardware that hosts one or more TEEs, often along with an REE. * Device Administrator: An entity that is responsible for administration of a device, which could be the Device Owner. A Device Administrator has privileges on the device to install and remove Untrusted Applications and TAs, approve or reject Trust Anchors, and approve or reject TA developers, among possibly other Pei, et al. Expires 27 April 2023 [Page 5] Internet-Draft TEEP Architecture October 2022 privileges on the device. A Device Administrator can manage the list of allowed TAMs by modifying the list of Trust Anchors on the device. Although a Device Administrator may have privileges and device-specific controls to locally administer a device, the Device Administrator may choose to remotely administer a device through a TAM. * Device Owner: A device is always owned by someone. In some cases, it is common for the (primary) device user to also own the device, making the device user/owner also the Device Administrator. In enterprise environments it is more common for the enterprise to own the device, and for any device user to have no or limited administration rights. In this case, the enterprise appoints a Device Administrator that is not the device owner. * Device User: A human being that uses a device. Many devices have a single device user. Some devices have a primary device user with other human beings as secondary device users (e.g., a parent allowing children to use their tablet or laptop). Other devices are not used by a human being and hence have no device user. * Personalization Data: A set of configuration data that is specific to the device or user. The Personalization Data may depend on the type of TEE, a particular TEE instance, the TA, and even the user of the device; an example of Personalization Data might be a secret symmetric key used by a TA to communicate with some service. * Raw Public Key: A raw public key consists of only the algorithm identifier (type) of the key and the cryptographic public key material, such as the SubjectPublicKeyInfo structure of a PKIX certificate [RFC5280]. Other serialization formats that do not rely on ASN.1 may also be used. * Rich Execution Environment (REE): An environment that is provided and governed by a typical OS (e.g., Linux, Windows, Android, iOS), potentially in conjunction with other supporting operating systems and hypervisors; it is outside of the TEE(s) managed by the TEEP protocol. This environment and applications running on it are considered untrusted (or more precisely, less trusted than a TEE). Pei, et al. Expires 27 April 2023 [Page 6] Internet-Draft TEEP Architecture October 2022 * Trust Anchor: As defined in [RFC6024] and [RFC9019], "A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative." The Trust Anchor may be a certificate, a raw public key or other structure, as appropriate. It can be a non-root certificate when it is a certificate. * Trust Anchor Store: As defined in [RFC6024], "A trust anchor store is a set of one or more trust anchors stored in a device... A device may have more than one trust anchor store, each of which may be used by one or more applications." As noted in [RFC9019], a Trust Anchor Store must resist modification against unauthorized insertion, deletion, and modification. * Trusted Application (TA): An application (or, in some implementations, an application component) that runs in a TEE. * Trusted Application Manager (TAM): An entity that manages Trusted Applications and other Trusted Components running in TEEs of various devices. * Trusted Component: A set of code and/or data in a TEE managed as a unit by a Trusted Application Manager. Trusted Applications and Personalization Data are thus managed by being included in Trusted Components. Trusted OS code or trusted firmware can also be expressed as Trusted Components that a Trusted Component depends on. * Trusted Component Developer: An entity that develops one or more Trusted Components. * Trusted Component Signer: An entity that signs a Trusted Component with a key that a TEE will trust. The signer might or might not be the same entity as the Trusted Component Developer. For example, a Trusted Component might be signed (or re-signed) by a Device Administrator if the TEE will only trust the Device Administrator. A Trusted Component might also be encrypted, if the code is considered confidential, for example, when a developer wants to provide a TA without revealing its code to others. * Trusted Execution Environment (TEE): An execution environment that enforces that only authorized code can execute within the TEE, and data used by that code cannot be read or tampered with by code outside the TEE. A TEE also generally has a device unique credential that cannot be cloned. There are multiple technologies that can be used to implement a TEE, and the level of security Pei, et al. Expires 27 April 2023 [Page 7] Internet-Draft TEEP Architecture October 2022 achieved varies accordingly. In addition, TEEs typically use an isolation mechanism between Trusted Applications to ensure that one TA cannot read, modify or delete the data and code of another TA. * Untrusted Application (UA): An application running in an REE. An Untrusted Application might depend on one or more TAs. 3. Use Cases 3.1. Payment A payment application in a mobile device requires high security and trust in the hosting device. Payments initiated from a mobile device can use a Trusted Application to provide strong identification and proof of transaction. For a mobile payment application, some biometric identification information could also be stored in a TEE. The mobile payment application can use such information for unlocking the device and for local identification of the user. A trusted user interface (UI) may be used in a mobile device or point-of-sale device to prevent malicious software from stealing sensitive user input data. Such an implementation often relies on a TEE for providing access to peripherals, such as PIN input or a trusted display, so that the REE cannot observe or tamper with the user input or output. 3.2. Authentication For better security of authentication, a device may store its keys and cryptographic libraries inside a TEE limiting access to cryptographic functions via a well-defined interface and thereby reducing access to keying material. 3.3. Internet of Things Weak security in Internet of Things (IoT) devices has been posing threats to critical infrastructure, i.e., assets that are essential for the functioning of a society and economy. It is desirable that IoT devices can prevent malware from manipulating actuators (e.g., unlocking a door), or stealing or modifying sensitive data, such as authentication credentials in the device. A TEE can be one of the best ways to implement such IoT security functions. For example, [GPTEE] uses the term "trusted peripheral" to refer to such things being accessible only from the TEE, and this concept is used, and this concept is used in some GlobalPlatform-compliant devices today. Pei, et al. Expires 27 April 2023 [Page 8] Internet-Draft TEEP Architecture October 2022 3.4. Confidential Cloud Computing A tenant can store sensitive data, such as customer details or credit card numbers, in a TEE in a cloud computing server such that only the tenant can access the data, preventing the cloud hosting provider from accessing the data. A tenant can run TAs inside a server TEE for secure operation and enhanced data security. This provides benefits not only to tenants with better data security but also to cloud hosting providers for reduced liability and increased cloud adoption. 4. Architecture 4.1. System Components Figure 1 shows the main components in a typical device with an REE and a TEE. Full descriptions of components not previously defined are provided below. Interactions of all components are further explained in the following paragraphs. +---------------------------------------------+ | Device | Trusted Component | +--------+ | Signer | +---------------+ | |--------------+ | | | TEE-1 | | TEEP |-----------+ | | | | +--------+ | +--| Broker | | | | +-------+ | | | | TEEP | | | | |<-----+ | | +-->| |<-+ | | | Agent |<------+ | | | | | +-| TAM-1 | | | +--------+ | | |<---+ | | +--->| | |<-+ | | | +--------+ | | | | +-------+ | | | +----+ +----+ | | | | | TAM-2 | | | +-->|TA-1| |TA-2| | +-------+ | | | +-------+ | | | | | | | |<---------| UA-2 |--+ | | | | | | +----+ +----+ | +-------+ | | | Device | | +---------------+ | UA-1 | | | | Administrator | | | | | | | | +--------------------| |-----+ | | | | |----------+ | | +-------+ | +---------------------------------------------+ Figure 1: Notional Architecture of TEEP * Trusted Component Signers and Device Administrators utilize the services of a TAM to manage TAs on devices. Trusted Component Signers do not directly interact with devices. Device Administrators may elect to use a TAM for remote administration of TAs instead of managing each device directly. Pei, et al. Expires 27 April 2023 [Page 9] Internet-Draft TEEP Architecture October 2022 * Trusted Application Manager (TAM): A TAM is responsible for performing lifecycle management activity on Trusted Components on behalf of Trusted Component Signers and Device Administrators. This includes installation and deletion of Trusted Components, and may include, for example, over-the-air updates to keep Trusted Components up-to-date and clean up when Trusted Components should be removed. TAMs may provide services that make it easier for Trusted Component Signers or Device Administrators to use the TAM's service to manage multiple devices, although that is not required of a TAM. The TAM performs its management of Trusted Components on the device through interactions with a device's TEEP Broker, which relays messages between a TAM and a TEEP Agent running inside the TEE. TEEP authentication is performed between a TAM and a TEEP Agent. When the TEEP Agent runs in a user or enterprise device, network and application firewalls normally protect user and enterprise devices from arbitrary connections from external network entities. In such a deployment, a TAM outside that network might not be able to directly contact a TEEP Agent, but needs to wait for the TEEP Broker to contact it. The architecture in Figure 1 accommodates this case as well as other less restrictive cases by leaving such details to an appropriate TEEP transport protocol (e.g., [I-D.ietf-teep-otrp-over-http], though other transport protocols can be defined under the TEEP protocol for other cases). A TAM may be publicly available for use by many Trusted Component Signers, or a TAM may be private, and accessible by only one or a limited number of Trusted Component Signers. It is expected that many enterprises, manufacturers, and network carriers will run their own private TAM. A Trusted Component Signer or Device Administrator chooses a particular TAM based on whether the TAM is trusted by a device or set of devices. The TAM is trusted by a device if the TAM's public key is, or chains up to, an authorized Trust Anchor in the device, and conforms with all constraints defined in the Trust Anchor. A Trusted Component Signer or Device Administrator may run their own TAM, but the devices they wish to manage must include this TAM's public key or certificate, or a certificate it chains up to, in the Trust Anchor Store. A Trusted Component Signer or Device Administrator is free to utilize multiple TAMs. This may be required for managing Trusted Components on multiple different types of devices from different manufacturers, or mobile devices on different network carriers, Pei, et al. Expires 27 April 2023 [Page 10] Internet-Draft TEEP Architecture October 2022 since the Trust Anchor Store on these different devices may contain keys for different TAMs. A Device Administrator may be able to add their own TAM's public key or certificate, or a certificate it chains up to, to the Trust Anchor Store on all their devices, overcoming this limitation. Any entity is free to operate a TAM. For a TAM to be successful, it must have its public key or certificate installed in a device's Trust Anchor Store. A TAM may set up a relationship with device manufacturers or network carriers to have them install the TAM's keys in their device's Trust Anchor Store. Alternatively, a TAM may publish its certificate and allow Device Administrators to install the TAM's certificate in their devices as an after-market action. * TEEP Broker: A TEEP Broker is an application component running in a Rich Execution Environment (REE) that enables the message protocol exchange between a TAM and a TEE in a device. A TEEP Broker does not process messages on behalf of a TEE, but merely is responsible for relaying messages from the TAM to the TEE, and for returning the TEE's responses to the TAM. In devices with no REE (e.g., a microcontroller where all code runs in an environment that meets the definition of a Trusted Execution Environment in Section 2), the TEEP Broker would be absent and instead the TEEP protocol transport would be implemented inside the TEE itself. * TEEP Agent: The TEEP Agent is a processing module running inside a TEE that receives TAM requests (typically relayed via a TEEP Broker that runs in an REE). A TEEP Agent in the TEE may parse requests or forward requests to other processing modules in a TEE, which is up to a TEE provider's implementation. A response message corresponding to a TAM request is sent back to the TAM, again typically relayed via a TEEP Broker. * Certification Authority (CA): A CA is an entity that issues digital certificates (especially X.509 certificates) and vouches for the binding between the data items in a certificate [RFC4949]. Certificates are then used for authenticating a device, a TAM, or a Trusted Component Signer, as discussed in Section 5. The CAs do not need to be the same; different CAs can be chosen by each TAM, and different device CAs can be used by different device manufacturers. Pei, et al. Expires 27 April 2023 [Page 11] Internet-Draft TEEP Architecture October 2022 4.2. Multiple TEEs in a Device Some devices might implement multiple TEEs. In these cases, there might be one shared TEEP Broker that interacts with all the TEEs in the device. However, some TEEs (for example, SGX [SGX]) present themselves as separate containers within memory without a controlling manager within the TEE. As such, there might be multiple TEEP Brokers in the REE, where each TEEP Broker communicates with one or more TEEs associated with it. It is up to the REE and the Untrusted Applications how they select the correct TEEP Broker. Verification that the correct TA has been reached then becomes a matter of properly verifying TA attestations, which are unforgeable. The multiple TEEP Broker approach is shown in the diagram below. For brevity, TEEP Broker 2 is shown interacting with only one TAM and Untrusted Application and only one TEE, but no such limitations are intended to be implied in the architecture. Pei, et al. Expires 27 April 2023 [Page 12] Internet-Draft TEEP Architecture October 2022 +-------------------------------------------+ | Device | Trusted Component | | Signer | +---------------+ | | | | TEE-1 | | | | | +-------+ | +--------+ | +--------+ | | | | TEEP | | | TEEP |------------->| |<-+ | | | Agent |<----------| Broker | | | | TA | | | 1 | | | 1 |---------+ | | | | +-------+ | | | | | | | | | | | |<---+ | | | | | | +----+ +----+ | | | | | | +-| TAM-1 | Policy | | |TA-1| |TA-2| | | |<-+ | | +->| | |<-+ | +-->| | | |<---+ +--------+ | | | | +--------+ | | | | +----+ +----+ | | | | | | TAM-2 | | | | | | | +-------+ | | | +--------+ | | | +---------------+ +---| UA-2 |--+ | | ^ | | | +-------+ | | | | Device | +--------------------| UA-1 | | | | | Administrator | +------| | | | | | | +-----------|---+ | |---+ | | | | | TEE-2 | | | |--------+ | | | | +------+ | | | |-------+ | | | | | TEEP | | | +-------+ | | | | | | Agent|<-------+ | | | | | | 2 | | | | | | | | | +------+ | | | | | | | | | | | | | | | | +----+ | | | | | | | | |TA-3|<---+ | | +---------+ | | | | | | | | | | TEEP |<-+ | | | | +----+ | +---| Broker | | | | | | | 2 |--------------+ | +---------------+ +---------+ | | | +-------------------------------------------+ Figure 2: Notional Architecture of TEEP with multiple TEEs In the diagram above, TEEP Broker 1 controls interactions with the TAs in TEE-1, and TEEP Broker 2 controls interactions with the TAs in TEE-2. This presents some challenges for a TAM in completely managing the device, since a TAM may not interact with all the TEEP Brokers on a particular platform. In addition, since TEEs may be physically separated, with wholly different resources, there may be no need for TEEP Brokers to share information on installed Trusted Components or resource usage. Pei, et al. Expires 27 April 2023 [Page 13] Internet-Draft TEEP Architecture October 2022 4.3. Multiple TAMs and Relationship to TAs As shown in Figure 2, a TEEP Broker provides communication between one or more TEEP Agents and one or more TAMs. The selection of which TAM to interact with might be made with or without input from an Untrusted Application, but is ultimately the decision of a TEEP Agent. A TEEP Agent is assumed to be able to determine, for any given Trusted Component, whether that Trusted Component is installed (or minimally, is running) in a TEE with which the TEEP Agent is associated. Each Trusted Component is digitally signed, protecting its integrity, and linking the Trusted Component back to the Trusted Component Signer. The Trusted Component Signer is often the Trusted Component Developer, but in some cases might be another party such as a Device Administrator or other party to whom the code has been licensed (in which case the same code might be signed by multiple licensees and distributed as if it were different TAs). A Trusted Component Signer selects one or more TAMs and communicates the Trusted Component(s) to the TAM. For example, the Trusted Component Signer might choose TAMs based upon the markets into which the TAM can provide access. There may be TAMs that provide services to specific types of devices, or device operating systems, or specific geographical regions or network carriers. A Trusted Component Signer may be motivated to utilize multiple TAMs in order to maximize market penetration and availability on multiple types of devices. This means that the same Trusted Component will often be available through multiple TAMs. When the developer of an Untrusted Application that depends on a Trusted Component publishes the Untrusted Application to an app store or other app repository, the developer optionally binds the Untrusted Application with a manifest that identifies what TAMs can be contacted for the Trusted Component. In some situations, a Trusted Component may only be available via a single TAM - this is likely the case for enterprise applications or Trusted Component Signers serving a closed community. For broad public apps, there will likely be multiple TAMs in the Untrusted Application's manifest - one servicing one brand of mobile device and another servicing a different manufacturer, etc. Because different devices and different manufacturers trust different TAMs, the manifest can include multiple TAMs that support the required Trusted Component. Pei, et al. Expires 27 April 2023 [Page 14] Internet-Draft TEEP Architecture October 2022 When a TEEP Broker receives a request (see the RequestTA API in Section 6.2.1) from an Untrusted Application to install a Trusted Component, a list of TAM URIs may be provided for that Trusted Component, and the request is passed to the TEEP Agent. If the TEEP Agent decides that the Trusted Component needs to be installed, the TEEP Agent selects a single TAM URI that is consistent with the list of trusted TAMs provisioned in the TEEP Agent, invokes the HTTP transport for TEEP to connect to the TAM URI, and begins a TEEP protocol exchange. When the TEEP Agent subsequently receives the Trusted Component to install and the Trusted Component's manifest indicates dependencies on any other trusted components, each dependency can include a list of TAM URIs for the relevant dependency. If such dependencies exist that are prerequisites to install the Trusted Component, then the TEEP Agent recursively follows the same procedure for each dependency that needs to be installed or updated, including selecting a TAM URI that is consistent with the list of trusted TAMs provisioned on the device, and beginning a TEEP exchange. If multiple TAM URIs are considered trusted, only one needs to be contacted and they can be attempted in some order until one responds. Separate from the Untrusted Application's manifest, this framework relies on the use of the manifest format in [I-D.ietf-suit-manifest] for expressing how to install a Trusted Component, as well as any dependencies on other TEE components and versions. That is, dependencies from Trusted Components on other Trusted Components can be expressed in a SUIT manifest, including dependencies on any other TAs, trusted OS code (if any), or trusted firmware. Installation steps can also be expressed in a SUIT manifest. For example, TEEs compliant with GlobalPlatform [GPTEE] may have a notion of a "security domain" (which is a grouping of one or more TAs installed on a device, that can share information within such a group) that must be created and into which one or more TAs can then be installed. It is thus up to the SUIT manifest to express a dependency on having such a security domain existing or being created first, as appropriate. Updating a Trusted Component may cause compatibility issues with any Untrusted Applications or other components that depend on the updated Trusted Component, just like updating the OS or a shared library could impact an Untrusted Application. Thus, an implementation needs to take into account such issues. Pei, et al. Expires 27 April 2023 [Page 15] Internet-Draft TEEP Architecture October 2022 4.4. Untrusted Apps, Trusted Apps, and Personalization Data In TEEP, there is an explicit relationship and dependence between an Untrusted Application in an REE and one or more TAs in a TEE, as shown in Figure 2. For most purposes, an Untrusted Application that uses one or more TAs in a TEE appears no different from any other Untrusted Application in the REE. However, the way the Untrusted Application and its corresponding TAs are packaged, delivered, and installed on the device can vary. The variations depend on whether the Untrusted Application and TA are bundled together or are provided separately, and this has implications to the management of the TAs in a TEE. In addition to the Untrusted Application and TA(s), the TA(s) and/or TEE may also require additional data to personalize the TA to the device or a user. Implementations of the TEEP protocol must support encryption to preserve the confidentiality of such Personalization Data, which may potentially contain sensitive data. The encryption is used to ensure that no personalization data is sent in the clear. Implementations must also support mechanisms for integrity protection of such Personalization Data. Other than the requirement to support confidentiality and integrity protection, the TEEP architecture places no limitations or requirements on the Personalization Data. There are multiple possible cases for bundling of an Untrusted Application, TA(s), and Personalization Data. Such cases include (possibly among others): 1. The Untrusted Application, TA(s), and Personalization Data are all bundled together in a single package by a Trusted Component Signer and either provided to the TEEP Broker through the TAM, or provided separately (with encrypted Personalization Data), with key material needed to decrypt and install the Personalization Data and TA provided by a TAM. 2. The Untrusted Application and the TA(s) are bundled together in a single package, which a TAM or a publicly accessible app store maintains, and the Personalization Data is separately provided by the Personalization Data provider's TAM. 3. All components are independent packages. The Untrusted Application is installed through some independent or device- specific mechanism, and one or more TAMs provide (directly or indirectly by reference) the TA(s) and Personalization Data. 4. The TA(s) and Personalization Data are bundled together into a package provided by a TAM, while the Untrusted Application is installed through some independent or device-specific mechanism such as an app store. Pei, et al. Expires 27 April 2023 [Page 16] Internet-Draft TEEP Architecture October 2022 5. Encrypted Personalization Data is bundled into a package distributed with the Untrusted Application, while the TA(s) and key material needed to decrypt and install the Personalization Data are in a separate package provided by a TAM. Personalization Data is encrypted with a key unique to that specific TEE, as discussed in Section 5. The TEEP protocol can treat each TA, any dependencies the TA has, and Personalization Data as separate Trusted Components with separate installation steps that are expressed in SUIT manifests, and a SUIT manifest might contain or reference multiple binaries (see [I-D.ietf-suit-manifest] for more details). The TEEP Agent is responsible for handling any installation steps that need to be performed inside the TEE, such as decryption of private TA binaries or Personalization Data. In order to better understand these cases, it is helpful to review actual implementations of TEEs and their application delivery mechanisms. 4.4.1. Example: Application Delivery Mechanisms in Intel SGX In Intel Software Guard Extensions (SGX), the Untrusted Application and TA are typically bundled into the same package (Case 2). The TA exists in the package as a shared library (.so or .dll). The Untrusted Application loads the TA into an SGX enclave when the Untrusted Application needs the TA. This organization makes it easy to maintain compatibility between the Untrusted Application and the TA, since they are updated together. It is entirely possible to create an Untrusted Application that loads an external TA into an SGX enclave, and use that TA (Cases 3-5). In this case, the Untrusted Application would require a reference to an external file or download such a file dynamically, place the contents of the file into memory, and load that as a TA. Obviously, such file or downloaded content must be properly formatted and signed for it to be accepted by the SGX TEE. In SGX, any Personalization Data is normally loaded into the SGX enclave (the TA) after the TA has started. Although it is possible with SGX to include the Untrusted Application in an encrypted package along with Personalization Data (Cases 1 and 5), there are no instances of this known to be in use at this time, since such a construction would require a special installation program and SGX TA (which might or might not be the TEEP Agent itself based on the implementation) to receive the encrypted package, decrypt it, separate it into the different elements, and then install each one. This installation is complex because the Untrusted Application decrypted inside the TEE must be passed out of the TEE to an Pei, et al. Expires 27 April 2023 [Page 17] Internet-Draft TEEP Architecture October 2022 installer in the REE which would install the Untrusted Application. Finally, the Personalization Data would need to be sent out of the TEE (encrypted in an SGX enclave-to-enclave manner) to the REE's installation app, which would pass this data to the installed Untrusted Application, which would in turn send this data to the SGX enclave (TA). This complexity is due to the fact that each SGX enclave is separate and does not have direct communication to other SGX enclaves. As long as signed files (TAs and/or Personalization Data) are installed into an untrusted filesystem and trust is verified by the TEE at load time, classic distribution mechanisms can be used. Some uses of SGX, however, allow a model where a TA can be dynamically installed into an SGX enclave that provides a runtime platform. The TEEP protocol can be used in such cases, where the runtime platform could include a TEEP Agent. 4.4.2. Example: Application Delivery Mechanisms in Arm TrustZone In Arm TrustZone [TrustZone] for A-class devices, the Untrusted Application and TA may or may not be bundled together. This differs from SGX since in TrustZone the TA lifetime is not inherently tied to a specific Untrusted Application process lifetime as occurs in SGX. A TA is loaded by a trusted OS running in the TEE such as a GlobalPlatform [GPTEE] compliant TEE, where the trusted OS is separate from the OS in the REE. Thus Cases 2-4 are equally applicable. In addition, it is possible for TAs to communicate with each other without involving any Untrusted Application, and so the complexity of Cases 1 and 5 are lower than in the SGX example, though still more complex than Cases 2-4. A trusted OS running in the TEE (e.g., OP-TEE [OP-TEE]) that supports loading and verifying signed TAs from an untrusted filesystem can, like SGX, use classic file distribution mechanisms. If secure TA storage is used (e.g., a Replay-Protected Memory Block device) on the other hand, the TEEP protocol can be used to manage such storage. 4.5. Entity Relations This architecture leverages asymmetric cryptography to authenticate a device to a TAM. Additionally, a TEEP Agent in a device authenticates a TAM. The provisioning of Trust Anchors to a device may be different from one use case to the other. A Device Administrator may want to have the capability to control what TAs are allowed. A device manufacturer enables verification by one or more TAMs and by Trusted Component Signers; it may embed a list of default Trust Anchors into the TEEP Agent and TEE for TAM trust verification and TA signature verification. Pei, et al. Expires 27 April 2023 [Page 18] Internet-Draft TEEP Architecture October 2022 (App Developers) (App Store) (TAM) (Device with TEE) (CAs) | | | | | | | | (Embedded TEE cert) <--| | | | | | | <--- Get an app cert -----------------------------------| | | | | | | | | <-- Get a TAM cert ---------| | | | | | 1. Build two apps: | | | | | | | | (a) Untrusted | | | | App - 2a. Supply --> | | | | | | | | (b) TA -- 2b. Supply ----------> | | | | | | | | --- 3. Install ------> | | | | | | | | 4. Messaging-->| | Figure 3: Example Developer Experience Figure 3 shows an example where the same developer builds and signs two applications: (a) an Untrusted Application; (b) a TA that provides some security functions to be run inside a TEE. This example assumes that the developer, the TEE, and the TAM have previously been provisioned with certificates. At step 1, the developer authors the two applications. At step 2, the developer uploads the Untrusted Application (2a) to an Application Store. In this example, the developer is also the Trusted Component Signer, and so generates a signed TA. The developer can then either bundle the signed TA with the Untrusted Application, or the developer can provide a signed Trusted Component containing the TA to a TAM that will be managing the TA in various devices. At step 3, a user will go to an Application Store to download the Untrusted Application (where the arrow indicates the direction of data transfer). At step 4, since the Untrusted Application depends on the TA, installing the Untrusted Application will trigger TA installation via communication with a TAM. The TEEP Agent will interact with the TAM via a TEEP Broker that facilitates communications between the TAM and the TEEP Agent. Pei, et al. Expires 27 April 2023 [Page 19] Internet-Draft TEEP Architecture October 2022 Some Trusted Component installation implementations might ask for a user's consent. In other implementations, a Device Administrator might choose what Untrusted Applications and related Trusted Components to be installed. A user consent flow is out of scope of the TEEP architecture. The main components of the TEEP protocol consist of a set of standard messages created by a TAM to deliver Trusted Component management commands to a device, and device attestation and response messages created by a TEE that responds to a TAM's message. It should be noted that network communication capability is generally not available in TAs in today's TEE-powered devices. Consequently, Trusted Applications generally rely on a broker in the REE to provide access to network functionality in the REE. A broker does not need to know the actual content of messages to facilitate such access. Similarly, since the TEEP Agent runs inside a TEE, the TEEP Agent generally relies on a TEEP Broker in the REE to provide network access, and relay TAM requests to the TEEP Agent and relay the responses back to the TAM. 5. Keys and Certificate Types This architecture leverages the following credentials, which allow achieving end-to-end security between a TAM and a TEEP Agent. Figure 4 summarizes the relationships between various keys and where they are stored. Each public/private key identifies a Trusted Component Signer, TAM, or TEE, and gets a certificate that chains up to some trust anchor. A list of trusted certificates is used to check a presented certificate against. Different CAs can be used for different types of certificates. TEEP messages are always signed, where the signer key is the message originator's private key, such as that of a TAM or a TEE. In addition to the keys shown in Figure 4, there may be additional keys used for attestation or encryption. Refer to the RATS Architecture [I-D.ietf-rats-architecture] for more discussion. Pei, et al. Expires 27 April 2023 [Page 20] Internet-Draft TEEP Architecture October 2022 Cardinality & Location of Location of Private Key Trust Anchor Purpose Private Key Signs Store ------------------ ----------- ------------- ------------- Authenticating 1 per TEE TEEP responses TAM TEEP Agent Authenticating TAM 1 per TAM TEEP requests TEEP Agent Code Signing 1 per Trusted TA binary TEE Component Signer Figure 4: Signature Keys Note that Personalization Data is not included in the table above. The use of Personalization Data is dependent on how TAs are used and what their security requirements are. TEEP requests from a TAM to a TEEP Agent are signed with the TAM private key (for authentication and integrity protection). Personalization Data and TA binaries can be encrypted with a key unique to that specific TEE, established with a content-encryption key established with the TEE public key (to provide confidentiality). Conversely, TEEP responses from a TEEP Agent to a TAM can be signed with the TEE private key. The TEE key pair and certificate are thus used for authenticating the TEE to a remote TAM, and for sending private data to the TEE. Often, the key pair is burned into the TEE by the TEE manufacturer and the key pair and its certificate are valid for the expected lifetime of the TEE. A TAM provider is responsible for configuring the TAM's Trust Anchor Store with the manufacturer certificates or CAs that are used to sign TEE keys. This is discussed further in Section 5.3 below. Typically, the same key TEE pair is used for both signing and encryption, though separate key pairs might also be used in the future, as the joint security of encryption and signature with a single key remains to some extent an open question in academic cryptography. The TAM key pair and certificate are used for authenticating a TAM to a remote TEE, and for sending private data to the TAM (separate key pairs for authentication vs. encryption could also be used in the future). A TAM provider is responsible for acquiring a certificate from a CA that is trusted by the TEEs it manages. This is discussed further in Section 5.1 below. Pei, et al. Expires 27 April 2023 [Page 21] Internet-Draft TEEP Architecture October 2022 The Trusted Component Signer key pair and certificate are used to sign Trusted Components that the TEE will consider authorized to execute. TEEs must be configured with the certificates or keys that it considers authorized to sign TAs that it will execute. This is discussed further in Section 5.2 below. 5.1. Trust Anchors in a TEEP Agent A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors, which are typically CA certificates that sign various TAM certificates. The list is typically preloaded at manufacturing time, and can be updated using the TEEP protocol if the TEE has some form of "Trust Anchor Manager TA" that has Trust Anchors in its configuration data. Thus, Trust Anchors can be updated similarly to the Personalization Data for any other TA. When Trust Anchor update is carried out, it is imperative that any update must maintain integrity where only an authentic Trust Anchor list from a device manufacturer or a Device Administrator is accepted. Details are out of scope of the architecture and can be addressed in a protocol document. Before a TAM can begin operation in the marketplace to support a device with a particular TEE, it must be able to get its raw public key, or its certificate, or a certificate it chains up to, listed in the Trust Anchor Store of the TEEP Agent. 5.2. Trust Anchors in a TEE The Trust Anchor Store in a TEE contains a list of Trust Anchors (raw public keys or certificates) that are used to determine whether TA binaries are allowed to execute by checking if their signatures can be verified. The list is typically preloaded at manufacturing time, and can be updated using the TEEP protocol if the TEE has some form of "Trust Anchor Manager TA" that has Trust Anchors in its configuration data. Thus, Trust Anchors can be updated similarly to the Personalization Data for any other TA, as discussed in Section 5.1. 5.3. Trust Anchors in a TAM The Trust Anchor Store in a TAM consists of a list of Trust Anchors, which are certificates that sign various device TEE certificates. A TAM will accept a device for Trusted Component management if the TEE in the device uses a TEE certificate that is chained to a certificate or raw public key that the TAM trusts, is contained in an allow list, is not found on a block list, and/or fulfills any other policy criteria. Pei, et al. Expires 27 April 2023 [Page 22] Internet-Draft TEEP Architecture October 2022 5.4. Scalability This architecture uses a PKI (including self-signed certificates). Trust Anchors exist on the devices to enable the TEEP Agent to authenticate TAMs and the TEE to authenticate Trusted Component Signers, and TAMs use Trust Anchors to authenticate TEEP Agents. When a PKI is used, many intermediate CA certificates can chain to a root certificate, each of which can issue many certificates. This makes the protocol highly scalable. New factories that produce TEEs can join the ecosystem. In this case, such a factory can get an intermediate CA certificate from one of the existing roots without requiring that TAMs are updated with information about the new device factory. Likewise, new TAMs can join the ecosystem, providing they are issued a TAM certificate that chains to an existing root whereby existing TAs in the TEE will be allowed to be personalized by the TAM without requiring changes to the TEE itself. This enables the ecosystem to scale, and avoids the need for centralized databases of all TEEs produced or all TAMs that exist or all Trusted Component Signers that exist. 5.5. Message Security Messages created by a TAM are used to deliver Trusted Component management commands to a device, and device attestation and messages are created by the device TEE to respond to TAM messages. These messages are signed end-to-end between a TEEP Agent and a TAM. Confidentiality is provided by encrypting sensitive payloads (such as Personalization Data and attestation evidence), rather than encrypting the messages themselves. Using encrypted payloads is important to ensure that only the targeted device TEE or TAM is able to decrypt and view the actual content. 6. TEEP Broker A TEE and TAs often do not have the capability to directly communicate outside of the hosting device. For example, GlobalPlatform [GPTEE] specifies one such architecture. This calls for a software module in the REE world to handle network communication with a TAM. A TEEP Broker is an application component running in the REE of the device or an SDK that facilitates communication between a TAM and a TEE. It also provides interfaces for Untrusted Applications to query and trigger installation of Trusted Components that the application needs to use. Pei, et al. Expires 27 April 2023 [Page 23] Internet-Draft TEEP Architecture October 2022 An Untrusted Application might communicate with a TEEP Broker at runtime to trigger Trusted Component installation itself, or an Untrusted Application might simply have a metadata file that describes the Trusted Components it depends on and the associated TAM(s) for each Trusted Component, and an REE Application Installer can inspect this application metadata file and invoke the TEEP Broker to trigger Trusted Component installation on behalf of the Untrusted Application without requiring the Untrusted Application to run first. 6.1. Role of the TEEP Broker A TEEP Broker interacts with a TEEP Agent inside a TEE, relaying messages between the TEEP Agent and the TAM, and may also interact with one or more Untrusted Applications (see Section 6.2.1). The Broker cannot parse encrypted TEEP messages between a TAM and a TEEP agent but merely relays them. When a device has more than one TEE, one TEEP Broker per TEE could be present in the REE or a common TEEP Broker could be used by multiple TEEs where the transport protocol (e.g., [I-D.ietf-teep-otrp-over-http]) allows the TEEP Broker to distinguish which TEE is relevant for each message from a TAM. The Broker only needs to return a (transport) error message to the TAM if the TEE is not reachable for some reason. Other errors are represented as TEEP response messages returned from the TEE which will then be passed to the TAM. 6.2. TEEP Broker Implementation Consideration As depicted in Figure 5, there are multiple ways in which a TEEP Broker can be implemented, with more or fewer layers being inside the TEE. For example, in model A, the model with the smallest TEE footprint, only the TEEP implementation is inside the TEE, whereas the TEEP/HTTP implementation is in the TEEP Broker outside the TEE. Pei, et al. Expires 27 April 2023 [Page 24] Internet-Draft TEEP Architecture October 2022 Model: A B C TEE TEE TEE +----------------+ | | | | TEEP | Agent | | | Agent | implementation | | | | +----------------+ v | | | | | +----------------+ ^ | | | TEEP/HTTP | Broker | | | | implementation | | | | +----------------+ | v | | | | +----------------+ | ^ | | HTTP(S) | | | | | implementation | | | | +----------------+ | | v | | | +----------------+ | | ^ | TCP or QUIC | | | | Broker | implementation | | | | +----------------+ | | | REE REE REE Figure 5: TEEP Broker Models In other models, additional layers are moved into the TEE, increasing the TEE footprint, with the Broker either containing or calling the topmost protocol layer outside of the TEE. An implementation is free to choose any of these models. TEEP Broker implementers should consider methods of distribution, scope and concurrency on devices and runtime options. 6.2.1. TEEP Broker APIs The following conceptual APIs exist from a TEEP Broker to a TEEP Agent: 1. RequestTA: A notification from an REE application (e.g., an installer, or an Untrusted Application) that it depends on a given Trusted Component, which may or may not already be installed in the TEE. Pei, et al. Expires 27 April 2023 [Page 25] Internet-Draft TEEP Architecture October 2022 2. UnrequestTA: A notification from an REE application (e.g., an installer, or an Untrusted Application) that it no longer depends on a given Trusted Component, which may or may not already be installed in the TEE. For example, if the Untrusted Application is uninstalled, the uninstaller might invoke this conceptual API. 3. ProcessTeepMessage: A message arriving from the network, to be delivered to the TEEP Agent for processing. 4. RequestPolicyCheck: A hint (e.g., based on a timer) that the TEEP Agent may wish to contact the TAM for any changes, without the device itself needing any particular change. 5. ProcessError: A notification that the TEEP Broker could not deliver an outbound TEEP message to a TAM. For comparison, similar APIs may exist on the TAM side, where a Broker may or may not exist, depending on whether the TAM uses a TEE or not: 1. ProcessConnect: A notification that a new TEEP session is being requested by a TEEP Agent. 2. ProcessTeepMessage: A message arriving at an existing TEEP session, to be delivered to the TAM for processing. For further discussion on these APIs, see [I-D.ietf-teep-otrp-over-http]. 6.2.2. TEEP Broker Distribution The Broker installation is commonly carried out at device manufacturing time. A user may also dynamically download and install a Broker on-demand. 7. Attestation Attestation is the process through which one entity (an Attester) presents "evidence", in the form of a series of claims, to another entity (a Verifier), and provides sufficient proof that the claims are true. Different Verifiers may require different degrees of confidence in attestation proofs and not all attestations are acceptable to every Verifier. A third entity (a Relying Party) can then use "attestation results", in the form of another series of claims, from a Verifier to make authorization decisions. (See [I-D.ietf-rats-architecture] for more discussion.) Pei, et al. Expires 27 April 2023 [Page 26] Internet-Draft TEEP Architecture October 2022 In TEEP, as depicted in Figure 6, the primary purpose of an attestation is to allow a device (the Attester) to prove to a TAM (the Relying Party) that a TEE in the device has particular properties, was built by a particular manufacturer, and/or is executing a particular TA. Other claims are possible; TEEP does not limit the claims that may appear in evidence or attestation results, but defines a minimal set of attestation result claims required for TEEP to operate properly. Extensions to these claims are possible. Other standards or groups may define the format and semantics of extended claims. +----------------+ | Device | +----------+ | +------------+ | Evidence | TAM | Evidence +----------+ | | TEE |------------->| (Relying |-------------->| Verifier | | | (Attester) | | | Party) |<--------------| | | +------------+ | +----------+ Attestation +----------+ +----------------+ Result Figure 6: TEEP Attestation Roles As of the writing of this specification, device and TEE attestations have not been standardized across the market. Different devices, manufacturers, and TEEs support different attestation protocols. In order for TEEP to be inclusive, it is agnostic to the format of evidence, allowing proprietary or standardized formats to be used between a TEE and a Verifier (which may or may not be colocated in the TAM), as long as the format supports encryption of any information that is considered sensitive. However, it should be recognized that not all Verifiers may be able to process all proprietary forms of attestation evidence. Similarly, the TEEP protocol is agnostic as to the format of attestation results, and the protocol (if any) used between the TAM and a Verifier, as long as they convey at least the required set of claims in some format. Note that the respective attestation algorithms are not defined in the TEEP protocol itself; see [I-D.ietf-rats-architecture] and [I-D.ietf-teep-protocol] for more discussion. There are a number of considerations that need to be considered when appraising evidence provided by a TEE, including: * What security measures a manufacturer takes when provisioning keys into devices/TEEs; * What hardware and software components have access to the attestation keys of the TEE; Pei, et al. Expires 27 April 2023 [Page 27] Internet-Draft TEEP Architecture October 2022 * The source or local verification of claims within an attestation prior to a TEE signing a set of claims; * The level of protection afforded to attestation keys against exfiltration, modification, and side channel attacks; * The limitations of use applied to TEE attestation keys; * The processes in place to discover or detect TEE breaches; and * The revocation and recovery process of TEE attestation keys. Some TAMs may require additional claims in order to properly authorize a device or TEE. The specific format for these additional claims are outside the scope of this specification, but the TEEP protocol allows these additional claims to be included in the attestation messages. For more discussion of the attestation and appraisal process, see the RATS Architecture [I-D.ietf-rats-architecture]. The following information is required for TEEP attestation: * Device Identifying Information: Attestation information may need to uniquely identify a device to the TAM. Unique device identification allows the TAM to provide services to the device, such as managing installed TAs, and providing subscriptions to services, and locating device-specific keying material to communicate with or authenticate the device. In some use cases it may be sufficient to identify only the model or class of the device, for example, a DAA Issuer's group public key ID when the attestation uses DAA, see [I-D.ietf-rats-daa]. Another example of models is the hwmodel (Hardware Model) as defined in [I-D.ietf-rats-eat]. The security and privacy requirements regarding device identification will vary with the type of TA provisioned to the TEE. * TEE Identifying Information: The type of TEE that generated this attestation must be identified. This includes version identification information for hardware, firmware, and software version of the TEE, as applicable by the TEE type. TEE manufacturer information for the TEE is required in order to disambiguate the same TEE type created by different manufacturers and address considerations around manufacturer provisioning, keying and support for the TEE. * Freshness Proof: A claim that includes freshness information must be included, such as a nonce or timestamp. Pei, et al. Expires 27 April 2023 [Page 28] Internet-Draft TEEP Architecture October 2022 8. Algorithm and Attestation Agility [RFC7696] outlines the requirements to migrate from one mandatory-to- implement cryptographic algorithm suite to another over time. This feature is also known as crypto agility. Protocol evolution is greatly simplified when crypto agility is considered during the design of the protocol. In the case of the TEEP protocol the diverse range of use cases, from trusted app updates for smartphones and tablets to updates of code on higher-end IoT devices, creates the need for different mandatory-to-implement algorithms already from the start. Crypto agility in TEEP concerns the use of symmetric as well as asymmetric algorithms. In the context of TEEP, symmetric algorithms are used for encryption and integrity protection of TA binaries and Personalization Data whereas the asymmetric algorithms are used for signing messages and managing symmetric keys. In addition to the use of cryptographic algorithms in TEEP, there is also the need to make use of different attestation technologies. A device must provide techniques to inform a TAM about the attestation technology it supports. For many deployment cases it is more likely for the TAM to support one or more attestation techniques whereas the device may only support one. 9. Security Considerations 9.1. Broker Trust Model The architecture enables the TAM to communicate, via a TEEP Broker, with the device's TEE to manage Trusted Components. Since the TEEP Broker runs in a potentially vulnerable REE, the TEEP Broker could, however, be (or be infected by) malware. As such, all TAM messages are signed and sensitive data is encrypted such that the TEEP Broker cannot modify or capture sensitive data, but the TEEP Broker can still conduct DoS attacks as discussed in Section 9.3. A TEEP Agent in a TEE is responsible for protecting against potential attacks from a compromised TEEP Broker or rogue malware in the REE. A rogue TEEP Broker might send corrupted data to the TEEP Agent, or launch a DoS attack by sending a flood of TEEP protocol requests, or simply drop or delay notifications to a TEE. The TEEP Agent validates the signature of each TEEP protocol request and checks the signing certificate against its Trust Anchors. To mitigate DoS attacks, it might also add some protection scheme such as a threshold on repeated requests or number of TAs that can be installed. Pei, et al. Expires 27 April 2023 [Page 29] Internet-Draft TEEP Architecture October 2022 Some implementations might rely on (due to lack of any available alternative) the use of an untrusted timer or other event to call the RequestPolicyCheck API (Section 6.2.1), which means that a compromised REE can cause a TEE to not receive policy changes and thus be out of date with respect to policy. The same can potentially be done by any other manipulator-in-the-middle simply by blocking communication with a TAM. Ultimately such outdated compliance could be addressed by using attestation in secure communication, where the attestation evidence reveals what state the TEE is in, so that communication (other than remediation such as via TEEP) from an out- of-compliance TEE can be rejected. Similarly, in most implementations the REE is involved in the mechanics of installing new TAs. However, the authority for what TAs are running in a given TEE is between the TEEP Agent and the TAM. While a TEEP Broker can in effect make suggestions as discussed in Section Section 6.2.1, it cannot decide or enforce what runs where. The TEEP Broker can also control which TEE a given installation request is directed at, but a TEEP Agent will only accept TAs that are actually applicable to it and where installation instructions are received by a TAM that it trusts. The authorization model for the UnrequestTA operation is, however, weaker in that it expresses the removal of a dependency from an application that was untrusted to begin with. This means that a compromised REE could remove a valid dependency from an Untrusted Application on a TA. Normal REE security mechanisms should be used to protect the REE and Untrusted Applications. 9.2. Data Protection It is the responsibility of the TAM to protect data on its servers. Similarly, it is the responsibility of the TEE implementation to provide protection of data against integrity and confidentiality attacks from outside the TEE. TEEs that provide isolation among TAs within the TEE are likewise responsible for protecting TA data against the REE and other TAs. For example, this can be used to protect one user's or tenant's data from compromise by another user or tenant, even if the attacker has TAs. The protocol between TEEP Agents and TAMs similarly is responsible for securely providing integrity and confidentiality protection against adversaries between them. It is a design choice at what layers to best provide protection against network adversaries. As discussed in Section 6, the transport protocol and any security mechanism associated with it (e.g., the Transport Layer Security protocol) under the TEEP protocol may terminate outside a TEE. If it does, the TEEP protocol itself must provide integrity protection and Pei, et al. Expires 27 April 2023 [Page 30] Internet-Draft TEEP Architecture October 2022 confidentiality protection to secure data end-to-end. For example, confidentiality protection for payloads may be provided by utilizing encrypted TA binaries and encrypted attestation information. See [I-D.ietf-teep-protocol] for how a specific solution addresses the design question of how to provide integrity and confidentiality protection. 9.3. Compromised REE It is possible that the REE of a device is compromised. We have already seen examples of attacks on the public Internet with a large number of compromised devices being used to mount DDoS attacks. A compromised REE can be used for such an attack but it cannot tamper with the TEE's code or data in doing so. A compromised REE can, however, launch DoS attacks against the TEE. The compromised REE may terminate the TEEP Broker such that TEEP transactions cannot reach the TEE, or might drop, replay, or delay messages between a TAM and a TEEP Agent. However, while a DoS attack cannot be prevented, the REE cannot access anything in the TEE if the TEE is implemented correctly. Some TEEs may have some watchdog scheme to observe REE state and mitigate DoS attacks against it but most TEEs don't have such a capability. In some other scenarios, the compromised REE may ask a TEEP Broker to make repeated requests to a TEEP Agent in a TEE to install or uninstall a Trusted Component. An installation or uninstallation request constructed by the TEEP Broker or REE will be rejected by the TEEP Agent because the request won't have the correct signature from a TAM to pass the request signature validation. This can become a DoS attack by exhausting resources in a TEE with repeated requests. In general, a DoS attack threat exists when the REE is compromised, and a DoS attack can happen to other resources. The TEEP architecture doesn't change this. A compromised REE might also request initiating the full flow of installation of Trusted Components that are not necessary. It may also repeat a prior legitimate Trusted Component installation request. A TEEP Agent implementation is responsible for ensuring that it can recognize and decline such repeated requests. It is also responsible for protecting the resource usage allocated for Trusted Component management. Pei, et al. Expires 27 April 2023 [Page 31] Internet-Draft TEEP Architecture October 2022 9.4. CA Compromise or Expiry of CA Certificate A root CA for TAM certificates might get compromised, or its certificate might expire, or a Trust Anchor other than a root CA certificate may also expire or be compromised. TEEs are responsible for validating the entire TAM certificate path, including the TAM certificate and any intermediate certificates up to the root certificate. See Section 6 of [RFC5280] for details. Such validation generally includes checking for certificate revocation, but certificate status check protocols may not scale down to constrained devices that use TEEP. To address the above issues, a certificate path update mechanism is expected from TAM operators, so that the TAM can get a new certificate path that can be validated by a TEEP Agent. In addition, the Trust Anchor in the TEEP Agent's Trust Anchor Store may need to be updated. To address this, some TEE Trust Anchor update mechanism is expected from device OEMs, such as using the TEEP protocol to distribute new Trust Anchors. Similarly, a root CA for TEE certificates might get compromised, or its certificate might expire, or a Trust Anchor other than a root CA certificate may also expire or be compromised. TAMs are responsible for validating the entire TEE certificate path, including the TEE certificate and any intermediate certificates up to the root certificate. Such validation includes checking for certificate revocation. If a TEE certificate path validation fails, the TEE might be rejected by a TAM, subject to the TAM's policy. To address this, some certificate path update mechanism is expected from device OEMs, so that the TEE can get a new certificate path that can be validated by a TAM. In addition, the Trust Anchor in the TAM's Trust Anchor Store may need to be updated. 9.5. Compromised TAM Device TEEs are responsible for validating the supplied TAM certificates. A compromised TAM may bring multiple threats and damage to user devices that it can manage and thus to the Device Owners. Information on devices that the TAM manages may be leaked to a bad actor. A compromised TAM can also install many TAs to launch a DoS attack on devices, for example, by filling up a device's TEE resources reserved for TAs such that other TAs may not get resources to be installed or properly function. It may also install malicious TAs to potentially many devices under the condition that it also has a Trusted Component signer key that is trusted by the TEEs. This makes TAMs high value targets. A TAM could be compromised without Pei, et al. Expires 27 April 2023 [Page 32] Internet-Draft TEEP Architecture October 2022 impacting its certificate or raising concern from the TAM's operator. To mitigate this threat, TEEP Agents and Device Owners have several options, including but potentially not limited to those listed below, for detecting and mitigating a compromised TAM: 1. Apply an ACL to the TAM key, limiting which Trusted Components the TAM is permitted to install or update. 2. Use a transparency log to expose a TAM compromise: TAMs publish an out-of-band record of Trusted Component releases, allowing a TEE to cross-check the Trusted Components delivered against the Trusted Component installs in order to detect a TAM compromise. 3. Use remote attestation of the TAM to prove trustworthiness. 9.6. Malicious TA Removal It is possible that a rogue developer distributes a malicious Untrusted Application and intends to get a malicious TA installed. Such a TA might be able to escape from malware detection by the REE, or access trusted resources within the TEE (but could not access other TEEs, or access other TA's if the TEE provides isolation between TAs). It is the responsibility of the TAM to not install malicious TAs in the first place. The TEEP architecture allows a TEEP Agent to decide which TAMs it trusts via Trust Anchors, and delegates the TA authenticity check to the TAMs it trusts. It may happen that a TA was previously considered trustworthy but is later found to be buggy or compromised. In this case, the TAM can initiate the removal of the TA by notifying devices to remove the TA (and potentially the REE or Device Owner to remove any Untrusted Application that depend on the TA). If the TAM does not currently have a connection to the TEEP Agent on a device, such a notification would occur the next time connectivity does exist. That is, to recover, the TEEP Agent must be able to reach out to the TAM, for example whenever the RequestPolicyCheck API (Section 6.2.1) is invoked by a timer or other event. Furthermore, the policy in the Verifier in an attestation process can be updated so that any evidence that includes the malicious TA would result in an attestation failure. There is, however, a time window during which a malicious TA might be able to operate successfully, which is the validity time of the previous attestation result. For example, if the Verifier in Figure 6 is updated to treat a previously valid TA as no longer trustworthy, any attestation result it Pei, et al. Expires 27 April 2023 [Page 33] Internet-Draft TEEP Architecture October 2022 previously generated saying that the TA is valid will continue to be used until the attestation result expires. As such, the TAM's Verifier should take into account the acceptable time window when generating attestation results. See [I-D.ietf-rats-architecture] for further discussion. 9.7. TEE Certificate Expiry and Renewal TEE device certificates are expected to be long-lived, longer than the lifetime of a device. A TAM certificate usually has a moderate lifetime of 1 to 5 years. A TAM should get renewed or rekeyed certificates. The root CA certificates for a TAM, which are embedded into the Trust Anchor Store in a device, should have long lifetimes that don't require device Trust Anchor updates. On the other hand, it is imperative that OEMs or device providers plan for support of Trust Anchor update in their shipped devices. For those cases where TEE devices are given certificates for which no good expiration date can be assigned the recommendations in Section 4.1.2.5 of [RFC5280] are applicable. 9.8. Keeping Secrets from the TAM In some scenarios, it is desirable to protect the TA binary or Personalization Data from being disclosed to the TAM that distributes them. In such a scenario, the files can be encrypted end-to-end between a Trusted Component Signer and a TEE. However, there must be some means of provisioning the decryption key into the TEE and/or some means of the Trusted Component Signer securely learning a public key of the TEE that it can use to encrypt. The Trusted Component Signer cannot necessarily even trust the TAM to report the correct public key of a TEE for use with encryption, since the TAM might instead provide the public key of a TEE that it controls. One way to solve this is for the Trusted Component Signer to run its own TAM that is only used to distribute the decryption key via the TEEP protocol, and the key file can be a dependency in the manifest of the encrypted TA. Thus, the TEEP Agent would look at the Trusted Component manifest, determine there is a dependency with a TAM URI of the Trusted Component Signer's TAM. The Agent would then install the dependency, and then continue with the Trusted Component installation steps, including decrypting the TA binary with the relevant key. Pei, et al. Expires 27 April 2023 [Page 34] Internet-Draft TEEP Architecture October 2022 9.9. REE Privacy The TEEP architecture is applicable to cases where devices have a TEE that protects data and code from the REE administrator. In such cases, the TAM administrator, not the REE administrator, controls the TEE in the devices. As some examples: * a cloud hoster may be the REE administrator where a customer administrator controls the TEE hosted in the cloud. * a device manufacturer might control the TEE in a device purchased by a customer The privacy risk is that data in the REE might be susceptible to disclosure to the TEE administrator. This risk is not introduced by the TEEP architecture, but is inherent in most uses of TEEs. This risk can be mitigated by making sure the REE administrator is aware of and explicitly chooses to have a TEE that is managed by another party. In the cloud hoster example, this choice is made by explicitly offering a service to customers to provide TEEs for them to administer. In the device manufacturer example, this choice is made by the customer choosing to buy a device made by a given manufacturer. 10. IANA Considerations This document does not require actions by IANA. 11. Contributors * Andrew Atyeo, Intercede (andrew.atyeo@intercede.com) * Liu Dapeng, Alibaba Group (maxpassion@gmail.com) 12. Acknowledgements We would like to thank Nick Cook, Minho Yoo, Brian Witten, Tyler Kim, Alin Mutu, Juergen Schoenwaelder, Nicolae Paladi, Sorin Faibish, Ned Smith, Russ Housley, Jeremy O'Donoghue, Anders Rundgren, and Brendan Moran for their feedback. 13. Informative References Pei, et al. Expires 27 April 2023 [Page 35] Internet-Draft TEEP Architecture October 2022 [CC-Overview] Confidential Computing Consortium, "Confidential Computing: Hardware-Based Trusted Execution for Applications and Data", January 2021, . [CC-Technical-Analysis] Confidential Computing Consortium, "A Technical Analysis of Confidential Computing, v1.2", October 2021, . [GPTEE] GlobalPlatform, "GlobalPlatform Device Technology: TEE System Architecture, v1.3", GlobalPlatform GPD_SPE_009, May 2022, . [GSMA] GSM Association, "GP.22 RSP Technical Specification, Version 2.2.2", June 2020, . [I-D.ietf-rats-architecture] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture", Work in Progress, Internet-Draft, draft-ietf-rats-architecture- 22, 28 September 2022, . [I-D.ietf-rats-daa] Birkholz, H., Newton, C., Chen, L., and D. Thaler, "Direct Anonymous Attestation for the Remote Attestation Procedures Architecture", Work in Progress, Internet- Draft, draft-ietf-rats-daa-02, 7 September 2022, . [I-D.ietf-rats-eat] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", Work in Progress, Internet-Draft, draft-ietf-rats-eat-17, 22 October 2022, . Pei, et al. Expires 27 April 2023 [Page 36] Internet-Draft TEEP Architecture October 2022 [I-D.ietf-suit-manifest] Moran, B., Tschofenig, H., Birkholz, H., Zandberg, K., and O. Rønningstad, "A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest", Work in Progress, Internet-Draft, draft-ietf-suit-manifest-20, 7 October 2022, . [I-D.ietf-teep-otrp-over-http] Thaler, D., "HTTP Transport for Trusted Execution Environment Provisioning: Agent Initiated Communication", Work in Progress, Internet-Draft, draft-ietf-teep-otrp- over-http-14, 14 October 2022, . [I-D.ietf-teep-protocol] Tschofenig, H., Pei, M., Wheeler, D. M., Thaler, D., and A. Tsukamoto, "Trusted Execution Environment Provisioning (TEEP) Protocol", Work in Progress, Internet-Draft, draft- ietf-teep-protocol-10, 28 July 2022, . [OP-TEE] TrustedFirmware.org, "OP-TEE Documentation", 2022, . [OTRP] GlobalPlatform, "Open Trust Protocol (OTrP) Profile v1.1", GlobalPlatform GPD_SPE_123, July 2020, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", RFC 6024, DOI 10.17487/RFC6024, October 2010, . Pei, et al. Expires 27 April 2023 [Page 37] Internet-Draft TEEP Architecture October 2022 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, . [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A Firmware Update Architecture for Internet of Things", RFC 9019, DOI 10.17487/RFC9019, April 2021, . [SGX] Intel, "Intel(R) Software Guard Extensions (Intel (R) SGX)", n.d., . [TrustZone] Arm, "Arm TrustZone Technology", n.d., . Authors' Addresses Mingliang Pei Broadcom Email: mingliang.pei@broadcom.com Hannes Tschofenig Arm Limited Email: hannes.tschofenig@arm.com Dave Thaler Microsoft Email: dthaler@microsoft.com David Wheeler Amazon Email: davewhee@amazon.com Pei, et al. Expires 27 April 2023 [Page 38] ./draft-ietf-cose-x509-09.txt0000644000764400076440000007761614243471575015346 0ustar iustiniustin Network Working Group J. Schaad Internet-Draft August Cellars Intended status: Standards Track 25 May 2022 Expires: 26 November 2022 CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates draft-ietf-cose-x509-09 Abstract The CBOR Signing And Encrypted Message (COSE) structure uses references to keys in general. For some algorithms, additional properties are defined which carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. Contributing to this document This note is to be removed before publishing as an RFC. The source for this draft is being maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/ cose-wg/X509. Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantial issues need to be discussed on the COSE mailing list. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 November 2022. Schaad Expires 26 November 2022 [Page 1] Internet-Draft COSE X.509 May 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, 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 of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 2. X.509 COSE Header Parameters . . . . . . . . . . . . . . . . 3 3. X.509 certificates and static-static ECDH . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4.1. COSE Header Parameter Registry . . . . . . . . . . . . . 9 4.2. COSE Header Algorithm Parameter Registry . . . . . . . . 9 4.3. Media Type application/cose-x509 . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction In the process of writing [RFC8152], the working group discussed X.509 certificates [RFC5280] and decided that no use cases were presented that showed a need to support certificates. Since that time, a number of cases have been defined in which X.509 certificate support is necessary, and by implication, applications will need a documented and consistent way to handle such certificates. This document defines a set of attributes that will allow applications to transport and refer to X.509 certificates in a consistent manner. In some of these cases, a constrained device is being deployed in the context of an existing X.509 PKI: for example, [I-D.ietf-anima-constrained-voucher] describes a device enrollment solution that relies on the presence of a factory-installed certificate on the device. The [I-D.ietf-lake-edhoc] draft was also written with the idea that long term certificates could be used to Schaad Expires 26 November 2022 [Page 2] Internet-Draft COSE X.509 May 2022 provide for authentication of devices, and uses them to establish session keys. Another possible scenario is the use of COSE as the basis for a secure messaging application. This scenario assumes the presence of long term keys and a central authentication authority. Basing such an application on public key certificates allows it to make use of well established key management disciplines. 1.1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. X.509 COSE Header Parameters The use of X.509 certificates allows for an existing trust infrastructure to be used with COSE. This includes the full suite of enrollment protocols, trust anchors, trust chaining and revocation checking that have been defined over time by the IETF and other organizations. The key structures that have been defined in COSE currently do not support all of these properties, although some may be found in COSE Web Tokens (CWT) [RFC8392]. It is not necessarily expected that constrained devices themselves will evaluate and process X.509 certificates: it is perfectly reasonable for a constrained device to be provisioned with a certificate that it subsequently provides to a relying party - along with a signature or encrypted message - on the assumption that the relying party is not a constrained device, and is capable of performing the required certificate evaluation and processing. It is also reasonable that a constrained device would have the hash of a certificate associated with a public key and be configured to use a public key for that thumbprint, but without performing the certificate evaluation or even having the entire certificate. In any case, there still needs to be an entity that is responsible for handling the possible certificate revocation. Schaad Expires 26 November 2022 [Page 3] Internet-Draft COSE X.509 May 2022 Parties that intend to rely on the assertions made by a certificate obtained from any of these methods still need to validate it. This validation can be done according to the PKIX rules in [RFC5280] or by using a different trust structure, such as a trusted certificate distributor for self-signed certificates. The PKIX validation includes matching against the trust anchors configured for the application. These rules apply when the validation succeeds in a single step as well as when certificate chains need to be built. If the application cannot establish trust in the certificate, the public key contained in the certificate cannot be used for cryptographic operations. The header parameters defined in this document are: x5bag: This header parameter contains a bag of X.509 certificates. The set of certificates in this header parameter is unordered and may contain self-signed certificates. Note that there could be duplicate certificates. The certificate bag can contain certificates which are completely extraneous to the message. (An example of this would be where a signed message is being used to transport a certificate containing a key agreement key.) As the certificates are unordered, the party evaluating the signature will need to be capable of building the certificate path as necessary. That party will also have to take into account that the bag may not contain the full set of certificates needed to build any particular chain. The trust mechanism MUST process any certificates in this parameter as untrusted input. The presence of a self-signed certificate in the parameter MUST NOT cause the update of the set of trust anchors without some out-of-band confirmation. As the contents of this header parameter are untrusted input, the header parameter can be in either the protected or unprotected header bucket. Sending the header parameter in the unprotected header bucket allows an intermediary to remove or add certificates. The end-entity certificate MUST be integrity protected by COSE. This can e.g. be done by sending the header parameter in the protected header, sending a x5bag in the unprotected header combined with a x5t in the protected header, or including the end- entity certificate in the external_aad. This header parameter allows for a single X.509 certificate or a bag of X.509 certificates to be carried in the message. * If a single certificate is conveyed, it is placed in a CBOR byte string. Schaad Expires 26 November 2022 [Page 4] Internet-Draft COSE X.509 May 2022 * If multiple certificates are conveyed, a CBOR array of byte strings is used, with each certificate being in its own byte string. x5chain: This header parameter contains an ordered array of X.509 certificates. The certificates are to be ordered starting with the certificate containing the end-entity key followed by the certificate which signed it and so on. There is no requirement for the entire chain to be present in the element if there is reason to believe that the relying party already has, or can locate the missing certificates. This means that the relying party is still required to do path building, but that a candidate path is proposed in this header parameter. The trust mechanism MUST process any certificates in this parameter as untrusted input. The presence of a self-signed certificate in the parameter MUST NOT cause the update of the set of trust anchors without some out-of-band confirmation. As the contents of this header parameter are untrusted input, the header parameter can be in either the protected or unprotected header bucket. Sending the header parameter in the unprotected header bucket allows an intermediary to remove or add certificates. The end-entity certificate MUST be integrity protected by COSE. This can e.g. be done by sending the header parameter in the protected header, sending a x5chain in the unprotected header combined with a x5t in the protected header, or including the end- entity certificate in the external_aad as. This header parameter allows for a single X.509 certificate or a chain of X.509 certificates to be carried in the message. * If a single certificate is conveyed, it is placed in a CBOR byte string. * If multiple certificates are conveyed, a CBOR array of byte strings is used, with each certificate being in its own byte string. x5t: This header parameter identifies the end-entity X.509 Schaad Expires 26 November 2022 [Page 5] Internet-Draft COSE X.509 May 2022 certificate by a hash value (a thumbprint). The 'x5t' header parameter is represented as an array of two elements. The first element is an algorithm identifier which is an integer or a string containing the hash algorithm identifier corresponding to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry https://www.iana.org/assignments/cose/cose.xhtml#algorithms. The second element is a binary string containing the hash value computed over the DER encoded certificate. As this header parameter does not provide any trust, the header parameter can be in either a protected or unprotected header bucket. The identification of the end-entity certificate MUST be integrity protected by COSE. This can be done by sending the header parameter in the protected header or including the end-entity certificate in the external_aad. The 'x5t' header parameter can be used alone or together with the 'x5bag', 'x5chain', or 'x5u' header parameters to provide integrity protection of the end-entity certificate. For interoperability, applications which use this header parameter MUST support the hash algorithm 'SHA-256', but can use other hash algorithms. This requirement allows for different implementations to be configured to use an interoperable algorithm, but does not preclude the use (by prior agreement) of other algorithms. RFC Editor please remove the following two paragraphs: During AD review, a question was raised about how effective the previous statement is in terms of dealing with a MTI algorithm. There needs to be some type of arrangement between the parties to agree that a specific hash algorithm is going to be used in computing the thumbprint. Making it a MUST use would make that true, but it then means that agility is going to be very difficult. The worry is that while SHA-256 may be mandatory, if a sender supports SHA-256 but only sends SHA-512 then the recipient which only does SHA-256 would not be able to use the thumbprint. In that case both applications would conform to the specification, but still not be able to inter-operate. x5u: This header parameter provides the ability to identify an X.509 certificate by a URI [RFC3986]. It contains a CBOR text string. The referenced resource can be any of the following media types: Schaad Expires 26 November 2022 [Page 6] Internet-Draft COSE X.509 May 2022 * application/pkix-cert [RFC2585] * application/pkcs7-mime; smime-type="certs-only" [RFC8551] * application/cose-x509 Section 4.3 * application/cose-x509; usage=chain Section 4.3 When the application/cose-x509 media type is used, the data is a CBOR sequence of single-entry COSE_X509 structures (encoding "bstr"). If the parameter "usage" is set to "chain", this sequence indicates a certificate chain. The end-entity certificate MUST be integrity protected by COSE. This can e.g. be done by sending the x5u in the unprotected or protected header combined with a x5t in the protected header, or including the end-entity certificate in the external_aad. As the end-entity certificate is integrity protected by COSE, the URI does not need to provide any protection. If a retrieved certificate does not chain to an existing trust anchor, that certificate MUST NOT be trusted unless the URI provided integrity protection and server authentication and the server is configured as trusted to provide new trust anchors or if an out-of-band confirmation can be received for trusting the retrieved certificate. In case an HTTP or CoAP GET request is used to retrieve a certificate, TLS [RFC8446], DTLS [I-D.ietf-tls-dtls13] or OSCORE [RFC8613] SHOULD be used. The header parameters are used in the following locations: * COSE_Signature and COSE_Sign1 objects: in these objects they identify the certificate to be used for validating the signature. * COSE_recipient objects: in this location they identify the certificate for the recipient of the message. The labels assigned to each header parameter can be found in the following table. Schaad Expires 26 November 2022 [Page 7] Internet-Draft COSE X.509 May 2022 +=========+=======+===============+=====================+ | Name | Label | Value Type | Description | +=========+=======+===============+=====================+ | x5bag | 32 | COSE_X509 | An unordered bag of | | | | | X.509 certificates | +---------+-------+---------------+---------------------+ | x5chain | 33 | COSE_X509 | An ordered chain of | | | | | X.509 certificates | +---------+-------+---------------+---------------------+ | x5t | 34 | COSE_CertHash | Hash of an X.509 | | | | | certificate | +---------+-------+---------------+---------------------+ | x5u | 35 | uri | URI pointing to an | | | | | X.509 certificate | +---------+-------+---------------+---------------------+ Table 1: X.509 COSE Header Parameters Below is an equivalent CDDL [RFC8610] description of the text above. COSE_X509 = bstr / [ 2*certs: bstr ] COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ] The content of the bstr are the bytes of a DER encoded certificate. 3. X.509 certificates and static-static ECDH The header parameters defined in the previous section are used to identify the recipient certificates for the ECDH key agreement algorithms. In this section we define the algorithm specific parameters that are used for identifying or transporting the sender's key for static-static key agreement algorithms. These attributes are defined analogously to those in the previous section. There is no definition for the certificate bag, as the same attribute would be used for both the sender and recipient certificates. x5chain-sender: This header parameter contains the chain of certificates starting with the sender's key exchange certificate. The structure is the same as 'x5chain'. x5t-sender: This header parameter contains the hash value for the sender's key exchange certificate. The structure is the same as 'x5t'. x5u-sender: This header parameter contains a URI for the sender's Schaad Expires 26 November 2022 [Page 8] Internet-Draft COSE X.509 May 2022 key exchange certificate. The structure and processing are the same as 'x5u'. +===============+=====+=============+===================+===========+ |Name |Label|Type | Algorithm |Description| +===============+=====+=============+===================+===========+ |x5t-sender |TBD |COSE_CertHash| ECDH-SS+HKDF-256, |Thumbprint | | | | | ECDH-SS+HKDF-512, |for the | | | | | ECDH-SS+A128KW, |sender's | | | | | ECDH-SS+A192KW, |X.509 | | | | | ECDH-SS+A256KW |certificate| +---------------+-----+-------------+-------------------+-----------+ |x5u-sender |TBD |uri | ECDH-SS+HKDF-256, |URI for the| | | | | ECDH-SS+HKDF-512, |sender's | | | | | ECDH-SS+A128KW, |X.509 | | | | | ECDH-SS+A192KW, |certificate| | | | | ECDH-SS+A256KW | | +---------------+-----+-------------+-------------------+-----------+ |x5chain-sender |TBD |COSE_X509 | ECDH-SS+HKDF-256, |static key | | | | | ECDH-SS+HKDF-512, |X.509 | | | | | ECDH-SS+A128KW, |certificate| | | | | ECDH-SS+A192KW, |chain | | | | | ECDH-SS+A256KW | | +---------------+-----+-------------+-------------------+-----------+ Table 2: Static ECDH Algorithm Values 4. IANA Considerations 4.1. COSE Header Parameter Registry IANA is requested to register the new COSE Header parameters in Table 1 in the "COSE Header Parameters" registry. The "Value Registry" field is empty for all of the items. For each item, the 'Reference' field points to this document. 4.2. COSE Header Algorithm Parameter Registry IANA is requested to register the new COSE Header Algorithm parameters in Table 2 in the "COSE Header Algorithm Parameters" registry. For each item, the 'Reference' field points to this document. Schaad Expires 26 November 2022 [Page 9] Internet-Draft COSE X.509 May 2022 4.3. Media Type application/cose-x509 When the application/cose-x509 media type is used, the data is a CBOR sequence of single-entry COSE_X509 structures (encoding "bstr"). If the parameter "usage" is set to "chain", this sequence indicates a certificate chain. IANA is requested to register the following media type [RFC6838]: Type name: application Subtype name: cose-x509 Required parameters: N/A Optional parameters: usage * Can be absent to provide no further information about the intended meaning of the order in the CBOR sequence of certificates. * Can be set to "chain" to indicate that the sequence of data items is to be interpreted as a certificate chain. Encoding considerations: binary Security considerations: See the Security Considerations section of RFCthis. Interoperability considerations: N/A Published specification: RFCthis Applications that use this media type: Applications that employ COSE and use X.509 as a certificate type. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A Person & email address to contact for further information: iesg@ietf.org Schaad Expires 26 November 2022 [Page 10] Internet-Draft COSE X.509 May 2022 Intended usage: COMMON Restrictions on usage: N/A Author: COSE WG Change controller: IESG Provisional registration? (standards tree only): no 5. Security Considerations Establishing trust in a certificate is a vital part of processing. A major component of establishing trust is determining what the set of trust anchors are for the process. A new self-signed certificate appearing on the client cannot be a trigger to modify the set of trust anchors, because a well-defined trust-establishment process is required. One common way for a new trust anchor to be added (or removed) from a device is by doing a new firmware upgrade. In constrained systems, there is a trade-off between the order of checking the signature and checking the certificate for validity. Validating certificates can require that network resources be accessed in order to get revocation information or retrieve certificates during path building. The resulting network access can consume power and network bandwidth. On the other hand, if the certificates are validated after the signature is validated, an oracle can potentially be built based on detecting the network resources which is only done if the signature validation passes. In any event, both the signature and certificate validation MUST be completed successfully before acting on any requests. Unless it is known that the CA required proof-of-possession of the subject's private key to issue an end-entity certificate, the end- entity certificate MUST be integrity protected by COSE. Without proof-of-possession, an attacker can trick the CA to issue an identity-misbinding certificate with someone else's "borrowed" public-key but with a different subject. A MITM attacker can then perform an identity-misbinding attack by replacing the real end- entity certificate in COSE with such an identity-misbinding certificate. Schaad Expires 26 November 2022 [Page 11] Internet-Draft COSE X.509 May 2022 End-entity X.509 certificates contain identities that a passive on- path attacker eavesdropping on the conversation can use to identify and track the subject. COSE does not provide identity protection by itself and the x5t and x5u header parameters are just alternative permanent identifiers and can also be used to track the subject. To provide identity protection, COSE can be sent inside another security protocol providing confidentiality. Before using the key in a certificate, the key MUST be checked against the algorithm to be used and any algorithm specific checks need to be made. These checks can include validating that points are on curves for elliptical curve algorithms, and that sizes of RSA keys are of an acceptable size. The use of unvalidated keys can lead either to loss of security or excessive consumption of resources (for example using a 200K RSA key). When processing the x5u header parameter the security considerations of [RFC3986] and specifically those defined in Section 7.1 of [RFC3986] also apply. Regardless of the source, certification path validation is an important part of establishing trust in a certificate. Section 6 of [RFC5280] provides guidance for the path validation. The security considerations of [RFC5280] are also important for the correct usage of this document. Protecting the integrity of the x5bag, x5chain and x5t contents by placing them in the protected header bucket can help mitigate some risks of a misbehaving certificate authority (cf. Section 5.1 of [RFC2634]). The security of the algorithm used for 'x5t' does not affect the security of the system as this header parameter selects which certificate that is already present on the system should be used, but it does not provide any trust. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Schaad Expires 26 November 2022 [Page 12] Internet-Draft COSE X.509 May 2022 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . 6.2. Informative References [I-D.ietf-anima-constrained-voucher] Richardson, M., Stok, P. V. D., Kampanakis, P., and E. Dijk, "Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI)", Work in Progress, Internet-Draft, draft-ietf-anima-constrained-voucher-17, 7 April 2022, . [I-D.ietf-lake-edhoc] Selander, G., Mattsson, J. P., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in Progress, Internet-Draft, draft-ietf-lake-edhoc-14, 18 May 2022, . [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- dtls13-43, 30 April 2021, . [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999, . Schaad Expires 26 November 2022 [Page 13] Internet-Draft COSE X.509 May 2022 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, DOI 10.17487/RFC2634, June 1999, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . Appendix A. Acknowledgements Author's Address Jim Schaad August Cellars Email: ietf@augustcellars.com Schaad Expires 26 November 2022 [Page 14] ./draft-ietf-lamps-rfc3709bis-10.txt0000644000764400076440000032027514345516775016604 0ustar iustiniustin Network Working Group S. Santesson Internet-Draft IDsec Solutions Obsoletes: 3709, 6170 (if approved) R. Housley Intended status: Standards Track Vigil Security Expires: 14 June 2023 T. Freeman Amazon Web Services L. Rosenthol Adobe 11 December 2022 Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates draft-ietf-lamps-rfc3709bis-10 Abstract This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. This document obsoletes RFC 3709 and RFC 6170. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Santesson, et al. Expires 14 June 2023 [Page 1] Internet-Draft Logotypes in X.509 Certificates December 2022 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Certificate-based Identification . . . . . . . . . . . . 4 1.2. Selection of Certificates . . . . . . . . . . . . . . . . 5 1.3. Combination of Verification Techniques . . . . . . . . . 5 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. Different Types of Logotypes in Certificates . . . . . . . . 6 3. Logotype Data . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Logotype Extension . . . . . . . . . . . . . . . . . . . . . 8 4.1. Extension Format . . . . . . . . . . . . . . . . . . . . 8 4.2. Conventions for LogotypeImageInfo . . . . . . . . . . . . 12 4.3. Embedded Images . . . . . . . . . . . . . . . . . . . . . 13 4.4. Other Logotypes . . . . . . . . . . . . . . . . . . . . . 13 4.4.1. Loyalty Logotype . . . . . . . . . . . . . . . . . . 14 4.4.2. Certificate Background Logotype . . . . . . . . . . . 14 4.4.3. Certificate Image Logotype . . . . . . . . . . . . . 14 5. Type of Certificates . . . . . . . . . . . . . . . . . . . . 16 6. Use in Clients . . . . . . . . . . . . . . . . . . . . . . . 16 7. Image Formats . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Audio Formats . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 12.1. Acknowledgments from RFC 3709 . . . . . . . . . . . . . 25 12.2. Acknowledgments from RFC 6170 . . . . . . . . . . . . . 25 12.3. Additional Acknowledgments . . . . . . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . 27 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 29 A.1. ASN.1 Modules with 1988 Syntax . . . . . . . . . . . . . 29 A.2. ASN.1 Module with 2002 Syntax . . . . . . . . . . . . . . 32 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 35 B.1. Example from RFC 3709 . . . . . . . . . . . . . . . . . . 35 B.2. Issuer Logotype Example . . . . . . . . . . . . . . . . . 36 B.3. Embedded Image Example . . . . . . . . . . . . . . . . . 37 B.4. Embedded Certificate Image Example . . . . . . . . . . . 39 B.5. Full Certificate Example . . . . . . . . . . . . . . . . 42 Appendix C. Changes Since RFC 3709 and RFC 6170 . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Santesson, et al. Expires 14 June 2023 [Page 2] Internet-Draft Logotypes in X.509 Certificates December 2022 1. Introduction This specification supplements [RFC5280], which profiles public-key certificates and certificate revocation lists (CRLs) for use in the Internet, and it supplements [RFC5755] which profiles attribute certificates for use in the Internet. This document obsoletes RFC 3709 [RFC3709] and RFC 6170 [RFC6170]. Appendix C provides a summary of the changes since the publication of RFC 3709 and RFC 6170. The basic function of a certificate is to bind a public key to the identity of an entity (the subject). From a strictly technical viewpoint, this goal could be achieved by signing the identity of the subject together with its public key. However, the art of Public Key Infrastructure (PKI) has developed certificates far beyond this functionality in order to meet the needs of modern global networks and heterogeneous information and operational technology structures. Certificate users must be able to determine certificate policies, appropriate key usage, assurance level, and name form constraints. Before a relying party can make an informed decision whether a particular certificate is trustworthy and relevant for its intended usage, a certificate may be examined from several different perspectives. Systematic processing is necessary to determine whether a particular certificate meets the predefined prerequisites for an intended usage. Much of the information contained in certificates is appropriate and effective for machine processing; however, this information is not suitable for a corresponding human trust and recognition process. Humans prefer to structure information into categories and symbols. Most humans associate complex structures of reality with easily recognizable logotypes and marks. Humans tend to trust things that they recognize from previous experiences. Humans may examine information to confirm their initial reaction. Very few consumers actually read all terms and conditions they agree to in accepting a service, rather they commonly act on trust derived from previous experience and recognition. A big part of this process is branding. Service providers and product vendors invest a lot of money and resources into creating a strong relation between positive user experiences and easily recognizable trademarks, servicemarks, and logotypes. Santesson, et al. Expires 14 June 2023 [Page 3] Internet-Draft Logotypes in X.509 Certificates December 2022 Branding is also pervasive in identification instruments, including identification cards, passports, driver's licenses, credit cards, gasoline cards, and loyalty cards. Identification instruments are intended to identify the holder as a particular person or as a member of the community. The community may represent the subscribers of a service or any other group. Identification instruments, in physical form, commonly use logotypes and symbols, solely to enhance human recognition and trust in the identification instrument itself. They may also include a registered trademark to allow legal recourse for unauthorized duplication. Since certificates play an equivalent role in electronic exchanges, we examine the inclusion of logotypes in certificates. We consider certificate-based identification and certificate selection. 1.1. Certificate-based Identification The need for human recognition depends on the manner in which certificates are used and whether certificates need to be visible to human users. If certificates are to be used in open environments and in applications that bring the user in conscious contact with the result of a certificate-based identification process, then human recognition is highly relevant, and may be a necessity. Examples of such applications include: * Web server identification where a user identifies the owner of the website. * Peer e-mail exchange in business-to-business (B2B), business-to- consumer (B2C), and private communications. * Exchange of medical records, and system for medical prescriptions. * Unstructured e-business applications (i.e., non-EDI applications). * Wireless client authenticating to a service provider. Most applications provide the human user with an opportunity to view the results of a successful certificate-based identification process. When the user takes the steps necessary to view these results, the user is presented with a view of a certificate. This solution has two major problems. First, the function to view a certificate is often rather hard to find for a non-technical user. Second, the presentation of the certificate is too technical and is not user friendly. It contains no graphic symbols or logotypes to enhance human recognition. Santesson, et al. Expires 14 June 2023 [Page 4] Internet-Draft Logotypes in X.509 Certificates December 2022 Many investigations have shown that users of today's applications do not take the steps necessary to view certificates. This could be due to poor user interfaces. Further, many applications are structured to hide certificates from users. The application designers do not want to expose certificates to users at all. 1.2. Selection of Certificates One situation where software applications must expose human users to certificates is when the user must select a single certificate from a portfolio of certificates. In some cases, the software application can use information within the certificates to filter the list for suitability; however, the user must be queried if more than one certificate is suitable. The human user must select one of them. This situation is comparable to a person selecting a suitable plastic card from his wallet. In this situation, substantial assistance is provided by card color, location, and branding. In order to provide similar support for certificate selection, the users need tools to easily recognize and distinguish certificates. Introduction of logotypes into certificates provides the necessary graphic. 1.3. Combination of Verification Techniques The use of logotypes will, in many cases, affect the users decision to trust and use a certificate. It is therefore important that there be a distinct and clear architectural and functional distinction between the processes and objectives of the automated certificate verification and human recognition. Since logotypes are only aimed for human interpretation and contain data that is inappropriate for computer based verification schemes, the logotype extension MUST NOT be an active component in automated certification path validation as specified in Section 6 of [RFC5280]. Automated certification path verification determines whether the end- entity certificate can be verified according to defined policy. The algorithm for this verification is specified in [RFC5280]. The automated processing provides assurance that the certificate is valid. It does not indicate whether the subject is entitled to any particular information, or whether the subject ought to be trusted to perform a particular service. These are authorization decisions. Automatic processing will make some authorization decisions, but others, depending on the application context, involve the human user. Santesson, et al. Expires 14 June 2023 [Page 5] Internet-Draft Logotypes in X.509 Certificates December 2022 In some situations, where automated procedures have failed to establish the suitability of the certificate to the task, the human user is the final arbitrator of the post certificate verification authorization decisions. In the end, the human will decide whether or not to accept an executable email attachment, to release personal information, or follow the instructions displayed by a web browser. This decision will often be based on recognition and previous experience. The distinction between systematic processing and human processing is rather straightforward. They can be complementary. While the systematic process is focused on certification path construction and verification, the human acceptance process is focused on recognition and related previous experience. There are some situations where systematic processing and human processing interfere with each other. These issues are discussed in the Section 9. 1.4. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Different Types of Logotypes in Certificates This specification defines the inclusion of three standard logotype types: * Community logotype * Issuer organization logotype * Subject organization logotype The community logotype is the general mark for a community. It identifies a service concept for entity identification and certificate issuance. Many issuers may use a community logotype to co-brand with a global community in order to gain global recognition of its local service provision. This type of community branding is very common in the credit card business, where local independent card issuers include a globally recognized brand (such as VISA and MasterCard). Certificate issuers may include more than one community logotype to indicate participation in more than one global community. Santesson, et al. Expires 14 June 2023 [Page 6] Internet-Draft Logotypes in X.509 Certificates December 2022 Issuer organization logotype is a logotype representing the organization identified as part of the issuer name in the certificate. Subject organization logotype is a logotype representing the organization identified in the subject name in the certificate. In addition to the standard logotype types, this specification accommodates inclusion of other logotype types where each class of logotype is defined by an object identifier. The object identifier can be either locally defined or an identifier defined in Section 4.4 of this document. 3. Logotype Data This specification defines two types of logotype data: image data and audio data. Implementations MUST support image data; however, support for audio data is OPTIONAL. Image and audio data for logotypes can be provided by reference by including a URI that identifies the location to the logotype data and a one-way hash of the referenced data in the certificate. The privacy-related properties for remote logotype data depend on four parties: the certificate relying parties that use the information in the certificate extension to fetch the logotype data, the certificate issuers that populate the certificate extension, certificate subscribers that request certificates that include the certificate extension, and server operators that provide the logotype data. Alternatively, embedding the logotype data in the certificate with direct addressing (as defined in Section 4.3) provides improved privacy properties and depends upon fewer parties. However, this approach can significantly increase the size of the certificate. Several image objects, representing the same visual content in different formats, sizes, and color palates, may represent each logotype image. At least one of the image objects representing a logotype SHOULD contain an image with a width between 60 pixels and 200 pixels and a height between 45 pixels and 150 pixels. Several instances of audio data may further represent the same audio sequence in different formats, resolutions, and languages. At least one of the audio objects representing a logotype SHOULD provide text- based audio data suitable for processing by text-to-speech software. Santesson, et al. Expires 14 June 2023 [Page 7] Internet-Draft Logotypes in X.509 Certificates December 2022 A typical use of text based audio data is inclusion in web applications where the audio text is placed as the "alt" atttribute value of an HTML image (img) element and the language value obtained from LogotypeAudioInfo is included as the "lang" attribute of that image. If a logotype of a certain type (as defined in Section 2) is represented by more than one image object, then each image object MUST contain variants of roughly the same visual content. Likewise, if a logotype of a certain type is represented by more than one audio object, then the audio objects MUST contain variants of the same audio information. A spoken message in different languages is considered a variation of the same audio information. When more than one image object or more than one audio object for the same logotype type is included in the certificate, the certificate issuer is responsible for ensuring that the objects contain roughly the same content. Compliant applications MUST NOT display more than one of the image objects and MUST NOT play more than one of the audio objects for any logotype type (see Section 2) at the same time. A client MAY simultaneously display multiple logotypes of different logotype types. For example, it may display one subject organization logotype while also displaying a community logotype, but it MUST NOT display multiple image variants of the same community logotype. Each logotype present in a certificate MUST be represented by at least one image data object. Client applications SHOULD enhance processing and off-line functionality by caching logotype data. 4. Logotype Extension This section specifies the syntax and semantics of the logotype certificate extension. 4.1. Extension Format The logotype extension MAY be included in public key certificates [RFC5280] or attribute certificates [RFC5755]. The logotype extension MUST be identified by the following object identifier: id-pe-logotype OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-pe(1) 12 } This extension MUST NOT be marked critical. Santesson, et al. Expires 14 June 2023 [Page 8] Internet-Draft Logotypes in X.509 Certificates December 2022 Logotype data may be referenced through either direct or indirect addressing. Client applications SHOULD support both direct and indirect addressing. Certificate issuing applications MUST support direct addressing, and certificate issuing applications SHOULD support indirect addressing. The direct addressing includes information about each logotype in the certificate, and URIs point to the image and audio data object. Multiple URIs MAY be included for locations for obtaining the same logotype object. Multiple hash values MAY be included, each computed with a different one-way hash function. Direct addressing supports cases where just one or a few alternative images and audio objects are referenced. The indirect addressing includes one or more references to an external hashed data structure that contains information on the type, content, and location of each image and audio object. Indirect addressing supports cases where each logotype is represented by many alternative audio or image objects. Both direct and indirect addressing accommodate alternative URIs to obtain exactly the same logotype data. This opportunity for replication is intended to improve availability. Therefore, if a client is unable to fetch the item from one URI, the client SHOULD try another URI in the sequence. All direct addressing URIs SHOULD use the HTTPS scheme (https://...) or the HTTP scheme (http://...) or the DATA scheme (data://...) [RFC3986]. However, the "data" URI scheme MUST NOT be used with the indirect addressing. Clients MUST support retrieval of referenced LogoTypeData with the HTTP [RFC9110] and the HTTP with TLS [RFC8446], or subsequent versions of these protocols. Client applications SHOULD also support the "data" URI scheme [RFC2397] for direct addressing with embedded logotype data within the extension. Note that the HTTPS scheme (https://...) requires the validation of other certificates to establish a secure connection. For this reason, the HTTP scheme (http://...) may be easier for a client to handle. Also, the hash of the logotype data provides data integrity. The logotype extension MUST have the following syntax: LogotypeExtn ::= SEQUENCE { communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL, issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL, subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL, otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL } Santesson, et al. Expires 14 June 2023 [Page 9] Internet-Draft Logotypes in X.509 Certificates December 2022 LogotypeInfo ::= CHOICE { direct [0] LogotypeData, indirect [1] LogotypeReference } LogotypeData ::= SEQUENCE { image SEQUENCE OF LogotypeImage OPTIONAL, audio [1] SEQUENCE OF LogotypeAudio OPTIONAL } LogotypeImage ::= SEQUENCE { imageDetails LogotypeDetails, imageInfo LogotypeImageInfo OPTIONAL } LogotypeAudio ::= SEQUENCE { audioDetails LogotypeDetails, audioInfo LogotypeAudioInfo OPTIONAL } LogotypeDetails ::= SEQUENCE { mediaType IA5String, -- MIME media type name and optional -- parameters logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String } LogotypeImageInfo ::= SEQUENCE { type [0] LogotypeImageType DEFAULT color, fileSize INTEGER, -- In octets, 0=unspecified xSize INTEGER, -- Horizontal size in pixels ySize INTEGER, -- Vertical size in pixels resolution LogotypeImageResolution OPTIONAL, language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag LogotypeImageType ::= INTEGER { grayScale(0), color(1) } LogotypeImageResolution ::= CHOICE { numBits [1] INTEGER, -- Resolution in bits per pixel tableSize [2] INTEGER } -- Number of colors or grey tones LogotypeAudioInfo ::= SEQUENCE { fileSize INTEGER, -- In octets, 0=unspecified playTime INTEGER, -- In milliseconds, 0=unspecified channels INTEGER, -- 0=unspecified, -- 1=mono, 2=stereo, 4=quad sampleRate [3] INTEGER OPTIONAL, -- Samples per second language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag OtherLogotypeInfo ::= SEQUENCE { logotypeType OBJECT IDENTIFIER, info LogotypeInfo } Santesson, et al. Expires 14 June 2023 [Page 10] Internet-Draft Logotypes in X.509 Certificates December 2022 LogotypeReference ::= SEQUENCE { refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, refStructURI SEQUENCE SIZE (1..MAX) OF IA5String } -- Places to get the same LogotypeData -- image or audio object HashAlgAndValue ::= SEQUENCE { hashAlg AlgorithmIdentifier, hashValue OCTET STRING } When using indirect addressing, the URI (refStructURI) pointing to the external data structure MUST point to a resource that contains the DER-encoded data with the syntax LogotypeData. At least one of the optional elements in the LogotypeExtn structure MUST be present. When using direct addressing, at least one of the optional elements in the LogotypeData structure MUST be present. The LogotypeReference and LogotypeDetails structures explicitly identify one or more one-way hash functions employed to authenticate referenced image or audio objects. CAs MUST include a hash value for each referenced object, calculated on the whole object. CAs MUST use the one-way hash function that is associated with the certificate signature to compute one hash value, and CAs MAY include other hash values. Clients MUST compute a one-way hash value using one of the identified functions, and clients MUST discard the logotype data if the computed hash value does not match the hash value in the certificate extension. A MIME type is used to specify the format of the image or audio object containing the logotype data. The mediaType field MUST contain a string that is constructed according to the ABNF [RFC5234] provided in Section 4.2 of [RFC6838]. MIME types MAY include parameters. Image format requirements are specified in Section 7, and audio format requirements are specified in Section 8. When language is specified, the language tag MUST use the [RFC5646] syntax. Logotype types defined in this specification are: Community Logotype: If communityLogos is present, the logotypes MUST represent one or more communities with which the certificate issuer is affiliated. The communityLogos MAY be present in an end Santesson, et al. Expires 14 June 2023 [Page 11] Internet-Draft Logotypes in X.509 Certificates December 2022 entity certificate, a CA certificate, or an attribute certificate. The communityLogos contains a sequence of Community Logotypes, each representing a different community. If more than one Community logotype is present, they MUST be placed in order of preferred appearance. Some clients MAY choose to display a subset of the present community logos; therefore the placement within the sequence aids the client selection. The most preferred logotype MUST be first in the sequence, and the least preferred logotype MUST be last in the sequence. Issuer Organization Logotype: If issuerLogo is present, the logotype MUST represent the issuer's organization. The logotype MUST be consistent with, and require the presence of, an organization name stored in the organization attribute in the issuer field (for either a public key certificate or attribute certificate). The issuerLogo MAY be present in an end entity certificate, a CA certificate, or an attribute certificate. Subject Organization Logotype: If subjectLogo is present, the logotype MUST represent the subject's organization. The logotype MUST be consistent with, and require the presence of, an organization name stored in the organization attribute in the subject field (for either a public key certificate or attribute certificate). The subjectLogo MAY be present in an end entity certificate, a CA certificate, or an attribute certificate. The relationship between the subject organization and the subject organization logotype, and the relationship between the issuer and either the issuer organization logotype or the community logotype, are relationships asserted by the issuer. The policies and practices employed by the issuer to check subject organization logotypes or claims its issuer and community logotypes is outside the scope of this document. 4.2. Conventions for LogotypeImageInfo When the optional LogotypeImageInfo is included with a logotype image, the parameters MUST be used with the following semantics and restrictions. The xSize and ySize fields represent the recommended display size for the logotype image. When a value of 0 (zero) is present, no recommended display size is specified. When non-zero values are present and these values differ from corresponding size values in the referenced image object, then the referenced image SHOULD be scaled to fit within the size parameters of LogotypeImageInfo, while preserving the x and y ratio. Dithering may produce a more appropriate image than linear scaling. Santesson, et al. Expires 14 June 2023 [Page 12] Internet-Draft Logotypes in X.509 Certificates December 2022 The resolution field is redundant for all logotype image formats listed in Section 7. The optional resolution field SHOULD be omitted when the image format already contains this information. 4.3. Embedded Images If the logotype image is provided through direct addressing, then the image MAY be stored within the logotype certificate extension using the "data" scheme [RFC2397]. The syntax of the "data" URI scheme defined is included here for convenience: dataurl := "data:" [ mediatype ] [ ";base64" ] "," data mediatype := [ type "/" subtype ] *( ";" parameter ) data := *urlchar parameter := attribute "=" value When including the image data in the logotype extension using the "data" URI scheme, the following conventions apply: * The value of mediaType in LogotypeDetails MUST be identical to the media type value in the "data" URL. * The hash of the image MUST be included in logotypeHash and MUST be calculated over the same data as it would have been, had the image been referenced through a link to an external resource. NOTE: As the "data" URI scheme is processed as a data source rather than as a URL, the image data is typically not limited by any URL length limit settings that otherwise apply to URLs in general. NOTE: Implementations need to be cautious about the size of images included in a certificate in order to ensure that the size of the certificate does not prevent the certificate from being used as intended. 4.4. Other Logotypes Logotypes identified by otherLogos (as defined in Section 4.1) can be used to enhance the display of logotypes and marks that represent partners, products, services, or any other characteristic associated with the certificate or its intended application environment when the standard logotype types are insufficient. The conditions and contexts of the intended use of these logotypes are defined at the discretion of the local client application. Three other logotype types are defined in the follow subsections. Santesson, et al. Expires 14 June 2023 [Page 13] Internet-Draft Logotypes in X.509 Certificates December 2022 4.4.1. Loyalty Logotype When a loyalty logotype appears in the otherLogos, it MUST be identified by the id-logo-loyalty object identifier. id-logo OBJECT IDENTIFIER ::= { id-pkix 20 } id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 } A loyalty logotype, if present, MUST contain a logotype associated with a loyalty program related to the certificate or its use. The relation between the certificate and the identified loyalty program is beyond the scope of this document. The logotype extension MAY contain more than one Loyalty logotype. If more than one loyalty logotype is present, they MUST be placed in order of preferred appearance. Some clients MAY choose to display a subset of the present loyalty logotype data; therefore the placement within the sequence aids the client selection. The most preferred loyalty logotype data MUST be first in the sequence, and the least preferred loyalty logotype data MUST be last in the sequence. 4.4.2. Certificate Background Logotype When a certificate background logotype appears in the otherLogos, it MUST be identified by the id-logo-background object identifier. id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 } The certificate background logotype, if present, MUST contain a graphical image intended as a background image for the certificate, and/or a general audio sequence for the certificate. The background image MUST allow black text to be clearly read when placed on top of the background image. The logotype extension MUST NOT contain more than one certificate background logotype. 4.4.3. Certificate Image Logotype When a certificate image logotype appears in the otherLogos, it MUST be identified by the id-logo-certImage object identifier. id-logo-certImage OBJECT IDENTIFIER ::= { id-logo 3 } The certificate image logotype, if present, aids human interpretation of a certificate by providing meaningful visual information to the user interface (UI). The logotype extension MUST NOT contain more than one certificate image logotype. Santesson, et al. Expires 14 June 2023 [Page 14] Internet-Draft Logotypes in X.509 Certificates December 2022 Typical situations when a human needs to examine the visual representation of a certificate are: * A person establishes a secured channel with an authenticated service. The person needs to determine the identity of the service based on the authenticated credentials. * A person validates the signature on critical information, such as signed executable code, and needs to determine the identity of the signer based on the signer's certificate. * A person is required to select an appropriate certificate to be used when authenticating to a service or Identity Management infrastructure. The person needs to see the available certificates in order to distinguish between them in the selection process. The display of certificate information to humans is challenging due to lack of well-defined semantics for critical identity attributes. Unless the application has out-of-band knowledge about a particular certificate, the application will not know the exact nature of the data stored in common identification attributes such as serialNumber, organizationName, country, etc. Consequently, the application can display the actual data, but faces the problem of labeling that data in the UI and informing the human about the exact nature (semantics) of that data. It is also challenging for the application to determine which identification attributes are important to display and how to organize them in a logical order. When present, the certificate image MUST be a complete visual representation of the certificate. This means that the display of this certificate image represents all information about the certificate that the issuer subjectively defines as relevant to show to a typical human user within the typical intended use of the certificate, giving adequate information about at least the following three aspects of the certificate: * Certificate Context * Certificate Issuer * Certificate Subject Certificate Context information is visual marks and/or textual information that helps the typical user to understand the typical usage and/or purpose of the certificate. Santesson, et al. Expires 14 June 2023 [Page 15] Internet-Draft Logotypes in X.509 Certificates December 2022 It is up to the issuer to decide what information -- in the form of text, graphical symbols, and elements -- represents a complete visual representation of the certificate. However, the visual representation of Certificate Subject and Certificate Issuer information from the certificate MUST have the same meaning as the textual representation of that information in the certificate itself. Applications providing a Graphical User Interface (GUI) to the certificate user MAY present a certificate image as the only visual representation of a certificate; however, the certificate user SHOULD be able to easily obtain the details of the certificate content. 5. Type of Certificates Logotypes MAY be included in public key certificates and attribute certificates at the discretion of the certificate issuer; however, the relying party MUST NOT use the logotypes as part of certification path validation or automated trust decision. The sole purpose of logotypes is to enhance the display of a particular certificate, regardless of its position in a certification path. 6. Use in Clients All PKI implementations require relying party software to have some mechanism to determine whether a trusted CA issues a particular certificate. This is an issue for certification path validation, including consistent policy and name checking. After a certification path is successfully validated, the replying party trusts the information that the CA includes in the certificate, including any certificate extensions. The client software can choose to make use of such information, or the client software can ignore it. If the client is unable to support a provided logotype, the client MUST NOT report an error, rather the client MUST behave as though no logotype extension was included in the certificate. Current standards do not provide any mechanism for cross-certifying CAs to constrain subordinate CAs from including private extensions (see Section 9). Santesson, et al. Expires 14 June 2023 [Page 16] Internet-Draft Logotypes in X.509 Certificates December 2022 Consequently, if relying party software accepts a CA, then it should be prepared to (unquestioningly) display the associated logotypes to its human user, given that it is configured to do so. Information about the logotypes is provided so that the replying party software can select the one that will best meet the needs of the human user. This choice depends on the abilities of the human user, as well as the capabilities of the platform on which the replaying party software is running. If none of the provided logotypes meets the needs of the human user or matches the capabilities of the platform, then the logotypes can be ignored. A client MAY, subject to local policy, choose to display none, one, or any number of the logotypes in the logotype extension. In many cases, a client will be used in an environment with a good network connection and also used in an environment with little or no network connectivity. For example, a laptop computer can be docked with a high-speed LAN connection, or it can be disconnected from the network altogether. In recognition of this situation, the client MUST include the ability to disable the fetching of logotypes. However, locally cached logotypes can still be displayed when the user disables the fetching of additional logotypes. A client MAY, subject to local policy, choose any combination of audio and image presentation for each logotype. That is, the client MAY display an image with or without playing a sound, and it MAY play a sound with or without displaying an image. A client MUST NOT play more than one logotype audio sequence at the same time. The logotype is to be displayed in conjunction with other identity information contained in the certificate. The logotype is not a replacement for this identity information. Care is needed when designing replying party software to ensure that an appropriate context of logotype information is provided. This is especially difficult with audio logotypes. It is important that the human user be able to recognize the context of the logotype, even if other audio streams are being played. If the relying party software is unable to successfully validate a particular certificate, then it MUST NOT display any logotype data associated with that certificate. 7. Image Formats Animated images SHOULD NOT be used. Santesson, et al. Expires 14 June 2023 [Page 17] Internet-Draft Logotypes in X.509 Certificates December 2022 The following table lists many common image formats and the corresponding MIME type. The table also indicates the support requirements for these image formats. The filename extensions commonly used for each of these formats is also provided. Implementations MAY support other image formats. +========+==============+===========+============+============+ | Format | MIME Type | Extension | References | Implement? | +========+==============+===========+============+============+ | JPEG | image/jpeg | .jpg | [JPEG] | MUST | | | | .jpeg | [RFC2046] | support | +--------+--------------+-----------+------------+------------+ | GIF | image/gif | .gif | [GIF] | MUST | | | | | [RFC2046] | support | +--------+--------------+-----------+------------+------------+ | SVG | image/ | .svg | [SVGT] | SHOULD | | | svg+xml | | [SVGR] | support | +--------+--------------+-----------+------------+------------+ | SVG + | image/ | .svgz | [SVGT] | MUST | | GZIP | svg+xml+gzip | .svg.gz | [SVGZR] | support | +--------+--------------+-----------+------------+------------+ | PNG | image/png | .png | [ISO15948] | SHOULD | | | | | [PNGR] | support | +--------+--------------+-----------+------------+------------+ | PDF | application/ | .pdf | [ISO32000] | MAY | | | pdf | | [ISO19005] | support | | | | | [RFC8118] | | +--------+--------------+-----------+------------+------------+ Table 1: Image Formats NOTE: The image/svg+xml-compressed media type is widely implemented, but it has not yet been registered with IANA. When a Scalable Vector Graphics (SVG) image is used, whether the image is compressed or not, the SVG Tiny profile [SVGT] MUST be followed, with these additional restrictions: * The SVG image MUST NOT contain any Internationalized Resource Identifier (IRI) references to information stored outside of the SVG image of type B, C, or D, according to Section 14.1.4 of [SVGT]. * The SVG image MUST NOT contain any 'script' element, according to Section 15.2 of [SVGT]. Santesson, et al. Expires 14 June 2023 [Page 18] Internet-Draft Logotypes in X.509 Certificates December 2022 * The XML structure in the SVG file MUST use linefeed (0x0A) as the end-of-line (EOL) character when calculating a hash over the SVG image. When a GZIP-compressed SVG image is fetched with HTTP, the client will receive a response that includes these headers: Content-Type: image/svg+xml Content-Encoding: gzip In this case, the octet stream of type image/svg+xml is compressed with GZIP [RFC1952] as specified in [SVGR]. When an uncompressed SVG image is fetched with HTTP, the client will receive a response with the same Content-Type header, but no Content- Encoding header. Whether the SVG image is GZIP-compressed or uncompressed, the hash value for the SVG image is calculated over the uncompressed SVG content with canonicalized EOL characters as specified above. When an SVG image is embedded in the certificate extension using the "data" URL scheme, the SVG image data MUST be provided in GZIP- compressed form, and the XML structure, prior to compression, SHOULD use linefeed (0x0A) as the end-of-line (EOL) character. When a bitmap image is used, the PNG [ISO15948] format SHOULD be used. When a Portable Document Format (PDF) document according to [ISO32000] is used, it MUST also be formatted according to the profile PDF/A [ISO19005]. 8. Audio Formats Implementations that support audio MUST support the MP3 audio format [MP3] with a MIME type of "audio/mpeg" [RFC3003]. Implementations SHOULD support text-based audio data with a MIME type of "text/ plain;charset=UTF-8". Implementations MAY support other audio formats. Text-based audio data using the MIME type of "text/plain;charset=UTF- 8" is intended to be used by text-to-speech software. When this audio type is used, the following requirements apply: * LogotypeAudioInfo MUST be present and specify the language of the text. Santesson, et al. Expires 14 June 2023 [Page 19] Internet-Draft Logotypes in X.509 Certificates December 2022 * The fileSize, playTime, and channels elements of LogotypeAudioInfo MUST have the value of 0. * The sampleRate element of LogotypeAudioInfo MUST be absent. 9. Security Considerations Implementations that simultaneously display multiple logotype types (subject organization, issuer, community, or other), MUST ensure that there is no ambiguity as to the binding between the image and the type of logotype that the image represents. "Logotype type" is defined in Section 1.1, and it refers to the type of entity or affiliation represented by the logotype, not the of binary format of the image or audio. Logotypes are very difficult to securely and accurately define. Names are also difficult in this regard, but logotypes are even worse. It is quite difficult to specify what is, and what is not, a legitimate logotype of an organization. There is an entire legal structure around this issue, and it will not be repeated here. However, issuers should be aware of the implications of including images associated with a trademark or servicemark before doing so. As logotypes can be difficult (and sometimes expensive) to verify, the possibility of errors related to assigning wrong logotypes to organizations is increased. This is not a new issue for electronic identification instruments. It is already dealt with in a number of similar situations in the physical world, including physical employee identification cards. In addition, there are situations where identification of logotypes is rather simple and straightforward, such as logotypes for well-known industries and institutes. These issues should not stop those service providers who want to issue logotypes from doing so, where relevant. It is impossible to prevent fraudulent creation of certificates by dishonest or badly performing issuers, containing names and logotypes that the issuer has no claim to or has failed to check correctly. Such certificates could be created in an attempt to socially engineer a user into accepting a certificate. The premise used for the logotype work is thus that logotype graphics in a certificate are trusted only if the certificate is successfully validated within a valid path. It is thus imperative that the representation of any certificate that fails to validate is not enhanced in any way by using the logotype data. Santesson, et al. Expires 14 June 2023 [Page 20] Internet-Draft Logotypes in X.509 Certificates December 2022 This underlines the necessity for CAs to provide reliable services, and the relying party's responsibility and need to carefully select which CAs are trusted to provide public key certificates. This also underlines the general necessity for relying parties to use up-to-date software libraries to render or dereference data from external sources, including logotype data in certificates, to minimize risks related to processing potentially malicious data before it has been adequately verified and validated. Implementers should review the guidance in Section 7 of [RFC3986]. Referenced image objects are hashed in order to bind the image to the signature of the certificate. Some image types, such as SVG, allow part of the image to be collected from an external source by incorporating a reference to an external file that contains the image. If this feature were used within a logotype image, the hash of the image would only cover the URI reference to the external image file, but not the referenced image data. Clients SHOULD verify that SVG images meet all requirements listed in Section 7 and reject images that contain references to external data. CAs issuing certificates with embedded logotype images should be cautious when accepting graphics from the certificate requestor for inclusion in the certificate if the hash algorithm used to sign the certificate is vulnerable to collision attacks such as [RFC6151]. In such a case, the accepted image may contain data that could help an attacker to obtain colliding certificates with identical certificate signatures. Certification paths may also impose name constraints that are systematically checked during certification path processing, which, in theory, may be circumvented by logotypes. Certificate path processing as defined in [RFC5280] does not constrain the inclusion of logotype data in certificates. A parent CA can constrain certification path validation such that subordinate CAs cannot issue valid certificates to end-entities outside a limited name space or outside specific certificate polices. A malicious CA can comply with these name and policy requirements and still include inappropriate logotypes in the certificates that it issues. These certificates will pass the certification path validation algorithm, which means the client will trust the logotypes in the certificates. Since there is no technical mechanism to prevent or control subordinate CAs from including the logotype extension or its contents, where appropriate, a parent CA could employ a legal agreement to impose a suitable restriction on the subordinate CA. This situation is not unique to the logotype extension. Santesson, et al. Expires 14 June 2023 [Page 21] Internet-Draft Logotypes in X.509 Certificates December 2022 When a relying party fetches remote logotype data, a mismatch between the media type provided in the mediaType field of the LogotypeDetails and the Content-Type HTTP header of the retrieved object MUST be treated as a failure and the fetched logotype data should not be presented to the user. However, if more than one location for the remote logotype data is provided in the certificate extension, the relying party MAY try to fetch the remote logotype data from an alternate location to resolve the failure. When a subscriber requests the inclusion of remote logotype data in a certificate, the CA cannot be sure that any logotype data will be available at the provided URI for the entire validity period of the certificate. To mitigate this concern, the CA may provide the logotype data from a server under its control, rather than a subscriber-controlled server. The controls available to a parent CA to protect itself from rogue subordinate CAs are non-technical. They include: * Contractual agreements of suitable behavior, including terms of liability in case of material breach. * Control mechanisms and procedures to monitor and follow the behavior of subordinate CAs, including Certificate Transparency [RFC9162]. * Use of certificate policies to declare an assurance level of logotype data, as well as to guide applications on how to treat and display logotypes. * Use of revocation functions to revoke any misbehaving CA. There is not a simple, straightforward, and absolute technical solution. Rather, involved parties must settle some aspects of PKI outside the scope of technical controls. As such, issuers need to clearly identify and communicate the associated risks. 10. Privacy Considerations Certificates are commonly public objects, so the inclusion of privacy-sensitive information in certificates should be avoided. The more information that is included in a certificate, the greater the likelihood that the certificate will reveal privacy-sensitive information. The inclusion of logotype data needs to be considered in this context. Santesson, et al. Expires 14 June 2023 [Page 22] Internet-Draft Logotypes in X.509 Certificates December 2022 Logotype data might be fetched from a server when it is needed. By watching activity on the network, an observer can determine which clients are making use of certificates that contain particular logotype data. Since clients are expected to locally cache logotype data, network traffic to the server containing the logotype data will not be generated every time the certificate is used. Further, when logotype data is not cached, activity on the network might reveal certificate usage frequency. Even when logotype data is cached, regardless of whether direct or indirect addressing is employed, network traffic monitoring could reveal when logotype data is fetched for the first time. Implementations MAY encrypt fetches of logotype data using HTTPS, padding the data to a common size to reduce visibility into the data that is being fetched. Likewise, servers MAY reduce visibility into the data that is being returned by encrypting with HTTPS and padding to a few common sizes. Similarly, when fetching logotype data from a server, the server operator can determine which clients are making use of certificates that contain particular logotype data. As above, locally caching logotype data will eliminate the need to fetch the logotype data each time the certificate is used, and lack of caching would reveal usage frequency. Even when implementations cache logotype data, regardless of whether direct or indirect addressing is employed, the server operator could observe when logotype data is fetched for the first time. In addition, the use of an encrypted DNS mechanism, such as DoT [RFC7858] or DoH [RFC9230], hides the name resolution traffic associated fetching remote logotype objects from third parties. When the "data" URI scheme is used with direct addressing, there is no network traffic to fetch logotype data, which avoids the observations of network traffic or server operations described above. To obtain this benefit, the certificate will be larger than one that contains a URL. Due to the improved privacy posture, the "data" URI scheme with direct addressing will be the only one that is supported by some CAs. Privacy-aware certificate subscribers MAY wish to insist that logotype data is embedded in the certificate with the "data" URI scheme with direct addressing. Santesson, et al. Expires 14 June 2023 [Page 23] Internet-Draft Logotypes in X.509 Certificates December 2022 In cases where logotype data is cached by the relying party, the cache index should include the hash values of the associated logotype data with the goal of fetching the logotype data only once, even when it is referenced by multiple URIs. The index should include hash values for all supported hash algorithms. The cached data should include the media type as well as the logotype data. Implementations should give preference to logotype data that is already in the cache when multiple alternatives are offered in the LogotypeExtn certificate extension. When the "data" URI scheme is used, the relying party MAY add the embedded logotype data to the local cache, which could avoid the need to fetch the logotype data if it is referenced by a URL in another certificate. When fetching remote logotype data, relying parties should use the most privacy-preserving options that are available to minimize the opportunities for servers to "fingerprint" clients. For example, avoid cookies, e-tags, and client certificates. When a relying party encounters a new certificate, the lack of network traffic to fetch logotype data might indicate that a certificate with references to the same logotype data has been previously processed and cached. TLS 1.3 [RFC8446] includes the ability to encrypt the server's certificate in the TLS handshake, which helps hide the server's identity from anyone that is watching activity on the network. If the server's certificate includes remote logotype data, the client fetching that data might disclose the otherwise protected server identity. 11. IANA Considerations For the new ASN.1 Module in Appendix A.2, IANA is requested to assign an object identifier (OID) for the module identifier. The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). For the existing entries in the Structure of Management Information (SMI) Numbers registry that refer to RFC 3709 or RFC 6170, IANA is requested update the entries to refer to this document. These entries are: Santesson, et al. Expires 14 June 2023 [Page 24] Internet-Draft Logotypes in X.509 Certificates December 2022 1.3.6.1.5.5.7.0.22 id-mod-logotype 1.3.6.1.5.5.7.0.68 id-mod-logotype-certimage 1.3.6.1.5.5.7.1.12 id-pe-logotype 1.3.6.1.5.5.7.20.1 id-logo-loyalty 1.3.6.1.5.5.7.20.2 id-logo-background 1.3.6.1.5.5.7.20.3 id-logo-certImage 12. Acknowledgments 12.1. Acknowledgments from RFC 3709 This document is the result of contributions from many professionals. The authors appreciate contributions from all members of the IETF PKIX Working Group. We extend a special thanks to Al Arsenault, David Cross, Tim Polk, Russel Weiser, Terry Hayes, Alex Deacon, Andrew Hoag, Randy Sabett, Denis Pinkas, Magnus Nystrom, Ryan Hurst, and Phil Griffin for their efforts and support. Russ Housley thanks the management at RSA Laboratories, especially Burt Kaliski, who supported the development of this specification. The vast majority of the work on this specification was done while Russ was employed at RSA Laboratories. 12.2. Acknowledgments from RFC 6170 The authors recognize valuable contributions from members of the PKIX working group, the CA Browser Forum, and James Manger, for their review and sample data. 12.3. Additional Acknowledgments Combining RFC 3709 and RFC 6170 has produced an improved specification. The authors appreciate contributions from all members of the IETF LAMPS Working Group. We extend a special thanks to Alexey Melnikov for his guidance on media types. We extend a special thanks to Tim Geiser for his careful checking of the new examples in Appendix B.4 and B.5. We extend a special thanks to Corey Bonnell, Daniel Kahn Gillmor, Roman Danyliw, Paul Wouters, Paul Kyzivat, Shuping Peng, Sheng Jiang, Rob Wilton, Eric Vyncke, Donald Eastlake, and Dan Harkins for their careful review and helpful comments. 13. References 13.1. Normative References [GIF] CompuServe Incorporated, "Graphics Interchange Format", Version 89a, 31 July 1990, . Santesson, et al. Expires 14 June 2023 [Page 25] Internet-Draft Logotypes in X.509 Certificates December 2022 [ISO15948] ISO/IEC, "Information technology -- Computer graphics and image processing -- Portable Network Graphics (PNG): Functional specification", ISO/IEC 15948:2004, 2004. [JPEG] ITU-T, "Information technology -- Digital compression and coding of continuous-tone still images: JPEG File Interchange Format (JFIF)", ITU-T Recommendation T.871, ISO/IEC 10918-5:2013, May 2011. [MP3] ISO/IEC, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 3: Audio", ISO/IEC 13818-3:1998, 1998. [NEW-ASN1] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1:2021, February 2021, . [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, . [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, DOI 10.17487/RFC2397, August 1998, . [RFC3003] Nilsson, M., "The audio/mpeg Media Type", RFC 3003, DOI 10.17487/RFC3003, November 2000, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . Santesson, et al. Expires 14 June 2023 [Page 26] Internet-Draft Logotypes in X.509 Certificates December 2022 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, DOI 10.17487/RFC5755, January 2010, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [SVGT] World Wide Web Consortium, "Scalable Vector Graphics (SVG) Tiny 1.2 Specification", W3C PR-SVGTiny12-20081117, 17 November 2008, . 13.2. Informative References [ISO19005] ISO, "Document management -- Electronic document file format for long-term preservation -- Part 1: Use of PDF 1.4 (PDF/A-1)", ISO 19005-1:2005, 2005. Santesson, et al. Expires 14 June 2023 [Page 27] Internet-Draft Logotypes in X.509 Certificates December 2022 [ISO32000] ISO, "Document management -- Portable document format -- Part 1: PDF 1.7", ISO 32000-1:2008, 2008. [OLD-ASN1] CCITT, "Specification of Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.208, November 1988, . [PNGR] World Wide Web Consortium, "Media Type Registration for image/png", . [RFC3709] Santesson, S., Housley, R., and T. Freeman, "Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates", RFC 3709, DOI 10.17487/RFC3709, February 2004, . [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, . [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, . [RFC6170] Santesson, S., Housley, R., Bajaj, S., and L. Rosenthol, "Internet X.509 Public Key Infrastructure -- Certificate Image", RFC 6170, DOI 10.17487/RFC6170, May 2011, . [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC8118] Hardy, M., Masinter, L., Markovic, D., Johnson, D., and M. Bailey, "The application/pdf Media Type", RFC 8118, DOI 10.17487/RFC8118, March 2017, . Santesson, et al. Expires 14 June 2023 [Page 28] Internet-Draft Logotypes in X.509 Certificates December 2022 [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [RFC9216] Gillmor, D. K., Ed., "S/MIME Example Keys and Certificates", RFC 9216, DOI 10.17487/RFC9216, April 2022, . [RFC9230] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A. Wood, "Oblivious DNS over HTTPS", RFC 9230, DOI 10.17487/RFC9230, June 2022, . [SVGR] World Wide Web Consortium, "Media Type Registration for image/svg+xml", . [SVGZR] "A separate MIME type for svgz files is needed", . Appendix A. ASN.1 Modules A.1. ASN.1 Modules with 1988 Syntax This appendix contains two ASN.1 modules, both using the old syntax [OLD-ASN1]. The first ASN.1 module provides the syntax for the Logotype certificate extension. Only comments have changed in the module from RFC 3709, and the IMPORTS now come from [RFC5280]. The second ASN.1 module provides the Certificate Image object identifier. The module is unchanged from RFC 6170. LogotypeCertExtn { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-logotype(22) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS AlgorithmIdentifier FROM PKIX1Explicit88 -- RFC 5280 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }; Santesson, et al. Expires 14 June 2023 [Page 29] Internet-Draft Logotypes in X.509 Certificates December 2022 -- Logotype Extension OID id-pe-logotype OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-pe(1) 12 } -- Logotype Extension Syntax LogotypeExtn ::= SEQUENCE { communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL, issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL, subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL, otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL } -- Note: At least one of the OPTIONAL components MUST be present LogotypeInfo ::= CHOICE { direct [0] LogotypeData, indirect [1] LogotypeReference } LogotypeData ::= SEQUENCE { image SEQUENCE OF LogotypeImage OPTIONAL, audio [1] SEQUENCE OF LogotypeAudio OPTIONAL } -- Note: At least one of the OPTIONAL components MUST be present LogotypeImage ::= SEQUENCE { imageDetails LogotypeDetails, imageInfo LogotypeImageInfo OPTIONAL } LogotypeAudio ::= SEQUENCE { audioDetails LogotypeDetails, audioInfo LogotypeAudioInfo OPTIONAL } LogotypeDetails ::= SEQUENCE { mediaType IA5String, -- MIME media type name and optional -- parameters logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String } LogotypeImageInfo ::= SEQUENCE { type [0] LogotypeImageType DEFAULT color, fileSize INTEGER, -- In octets, 0=unspecified xSize INTEGER, -- Horizontal size in pixels ySize INTEGER, -- Vertical size in pixels resolution LogotypeImageResolution OPTIONAL, Santesson, et al. Expires 14 June 2023 [Page 30] Internet-Draft Logotypes in X.509 Certificates December 2022 language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag LogotypeImageType ::= INTEGER { grayScale(0), color(1) } LogotypeImageResolution ::= CHOICE { numBits [1] INTEGER, -- Resolution in bits per pixel tableSize [2] INTEGER } -- Number of colors or grey tones LogotypeAudioInfo ::= SEQUENCE { fileSize INTEGER, -- In octets, 0=unspecified playTime INTEGER, -- In milliseconds, 0=unspecified channels INTEGER, -- 0=unspecified, -- 1=mono, 2=stereo, 4=quad sampleRate [3] INTEGER OPTIONAL, -- Samples per second language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag OtherLogotypeInfo ::= SEQUENCE { logotypeType OBJECT IDENTIFIER, info LogotypeInfo } LogotypeReference ::= SEQUENCE { refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, refStructURI SEQUENCE SIZE (1..MAX) OF IA5String } -- Places to get the same LogotypeData -- image or audio object -- Note: The referenced LogotypeData binary file contains a -- DER-encoded LogotypeData type HashAlgAndValue ::= SEQUENCE { hashAlg AlgorithmIdentifier, hashValue OCTET STRING } -- Other logotype type OIDs id-logo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 20 } id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 } id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 } END CERT-IMAGE-MODULE { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-logotype-certimage(68) } Santesson, et al. Expires 14 June 2023 [Page 31] Internet-Draft Logotypes in X.509 Certificates December 2022 DEFINITIONS EXPLICIT TAGS ::= BEGIN EXPORTS ALL; -- export all items from this module id-logo-certImage OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-logo(20) 3 } END A.2. ASN.1 Module with 2002 Syntax Some developers like to use the latest version of ASN.1 standards. This appendix provides an ASN.1 module to assist in that goal. It uses the ASN.1 syntax defined in [NEW-ASN1], and it follows the conventions established in [RFC5912] and [RFC6268]. This ASN.1 module incorporates the module from RFC 3709 and the module from RFC 6170. Note that [NEW-ASN1] was published in 2021, and all of the features used in this module are backward compatible with the specification that was published in 2002. LogotypeCertExtn { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-logotype(TBD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS EXTENSION FROM PKIX-CommonTypes-2009 -- RFC 5912 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } AlgorithmIdentifier{}, DIGEST-ALGORITHM FROM AlgorithmInformation-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } ; Santesson, et al. Expires 14 June 2023 [Page 32] Internet-Draft Logotypes in X.509 Certificates December 2022 -- Logotype Extension ext-logotype EXTENSION ::= { SYNTAX LogotypeExtn IDENTIFIED BY id-pe-logotype } -- Logotype Extension OID id-pe-logotype OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-pe(1) 12 } -- Logotype Extension Syntax LogotypeExtn ::= SEQUENCE { communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL, issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL, subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL, otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL } -- At least one of the OPTIONAL components MUST be present ( WITH COMPONENTS { ..., communityLogos PRESENT } | WITH COMPONENTS { ..., issuerLogo PRESENT } | WITH COMPONENTS { ..., subjectLogo PRESENT } | WITH COMPONENTS { ..., otherLogos PRESENT } ) LogotypeInfo ::= CHOICE { direct [0] LogotypeData, indirect [1] LogotypeReference } LogotypeData ::= SEQUENCE { image SEQUENCE OF LogotypeImage OPTIONAL, audio [1] SEQUENCE OF LogotypeAudio OPTIONAL } -- At least one image component MUST be present ( WITH COMPONENTS { ..., image PRESENT } ) LogotypeImage ::= SEQUENCE { imageDetails LogotypeDetails, imageInfo LogotypeImageInfo OPTIONAL } LogotypeAudio ::= SEQUENCE { audioDetails LogotypeDetails, audioInfo LogotypeAudioInfo OPTIONAL } LogotypeDetails ::= SEQUENCE { mediaType IA5String, -- MIME media type name and optional -- parameters logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, Santesson, et al. Expires 14 June 2023 [Page 33] Internet-Draft Logotypes in X.509 Certificates December 2022 logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String } LogotypeImageInfo ::= SEQUENCE { type [0] LogotypeImageType DEFAULT color, fileSize INTEGER, -- In octets, 0=unspecified xSize INTEGER, -- Horizontal size in pixels ySize INTEGER, -- Vertical size in pixels resolution LogotypeImageResolution OPTIONAL, language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag LogotypeImageType ::= INTEGER { grayScale(0), color(1) } LogotypeImageResolution ::= CHOICE { numBits [1] INTEGER, -- Resolution in bits tableSize [2] INTEGER } -- Number of colors or grey tones LogotypeAudioInfo ::= SEQUENCE { fileSize INTEGER, -- In octets, 0=unspecified playTime INTEGER, -- In milliseconds, 0=unspecified channels INTEGER, -- 0=unspecified -- 1=mono, 2=stereo, 4=quad sampleRate [3] INTEGER OPTIONAL, -- Samples per second language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag OtherLogotypeInfo ::= SEQUENCE { logotypeType OBJECT IDENTIFIER, info LogotypeInfo } LogotypeReference ::= SEQUENCE { refStructHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, refStructURI SEQUENCE SIZE (1..MAX) OF IA5String } -- Places to get the same LogotypeData -- image or audio object -- Note: The referenced LogotypeData binary file contains a -- DER-encoded LogotypeData type HashAlgAndValue ::= SEQUENCE { hashAlg AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, hashValue OCTET STRING } -- Other logotype type OIDs id-logo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 20 } id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 } Santesson, et al. Expires 14 June 2023 [Page 34] Internet-Draft Logotypes in X.509 Certificates December 2022 id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 } id-logo-certImage OBJECT IDENTIFIER ::= { id-logo 3 } END Appendix B. Examples B.1. Example from RFC 3709 The following example displays a logotype extension containing one Issuer logotype using direct addressing. The issuer logotype image is of the type image/gif. The logotype image is referenced through one URI and the image is hashed with SHA-256. This example is changed from RFC 3709 to use SHA-256 instead of SHA-1. The values on the left are the ASN.1 tag (in hexadecimal) and the length (in decimal). Santesson, et al. Expires 14 June 2023 [Page 35] Internet-Draft Logotypes in X.509 Certificates December 2022 30 122: SEQUENCE { 06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12) 04 110: OCTET STRING, encapsulates { 30 108: SEQUENCE { A1 106: [1] { A0 104: [0] { 30 102: SEQUENCE { 30 100: SEQUENCE { 30 98: SEQUENCE { 16 9: IA5String 'image/gif' 30 49: SEQUENCE { 30 47: SEQUENCE { 30 11: SEQUENCE { 06 9: OBJECT IDENTIFIER : sha-256 (2 16 840 1 101 3 4 2 1) : } 04 32: OCTET STRING : 6A 58 50 2E 59 67 F9 DD D1 8A FE BD 0D B1 FE 60 : A5 13 1B DF 0F B2 BE F0 B5 73 45 50 BA 1B BF 19 : } : } 30 34: SEQUENCE { 16 32: IA5String 'http://logo.example.com/logo.gif' : } : } : } : } : } : } : } : } : } B.2. Issuer Logotype Example The following example displays a logotype extension containing one Issuer logotype using direct addressing. The issuer logotype image is of the type image/jpeg. The logotype image is referenced through one URI and the image is hashed with SHA-256. The values on the left are the ASN.1 tag (in hexadecimal) and the length (in decimal). Santesson, et al. Expires 14 June 2023 [Page 36] Internet-Draft Logotypes in X.509 Certificates December 2022 30 124: SEQUENCE { 06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12) 04 112: OCTET STRING, encapsulates { 30 110: SEQUENCE { A1 108: [1] { A0 106: [0] { 30 104: SEQUENCE { 30 102: SEQUENCE { 30 100: SEQUENCE { 16 10: IA5String 'image/jpeg' 30 49: SEQUENCE { 30 47: SEQUENCE { 30 11: SEQUENCE { 06 9: OBJECT IDENTIFIER : sha-256 (2 16 840 1 101 3 4 2 1) : } 04 32: OCTET STRING : 1E 8F 96 FD D3 50 53 EF C6 1C 9F FC F0 00 2E 53 : B4 9C 24 9A 32 C5 E9 0C 2C 39 39 D3 AD 6D A9 09 : } : } 30 35: SEQUENCE { 16 33: IA5String 'http://logo.example.com/logo.jpeg' : } : } : } : } : } : } : } : } : } B.3. Embedded Image Example The following example displays a logotype extension containing one Subject logotype using direct addressing. The subject logotype image uses image/svg+xml-compressed. The logotype image is embedded in the certificate extension with a "data:" URI and the image is hashed by SHA-256. This technique produces a large certificate extension, but offers reduced latency and improved privacy. The values on the left are the ASN.1 tag (in hexadecimal) and the length (in decimal). Santesson, et al. Expires 14 June 2023 [Page 37] Internet-Draft Logotypes in X.509 Certificates December 2022 30 2160: SEQUENCE { 06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12) 04 2146: OCTET STRING, encapsulates { 30 2142: SEQUENCE { A2 2138: [2] { A0 2134: [0] { 30 2130: SEQUENCE { 30 2126: SEQUENCE { 30 2122: SEQUENCE { 16 24: IA5String 'image/svg+xml-compressed' 30 49: SEQUENCE { 30 47: SEQUENCE { 30 11: SEQUENCE { 06 9: OBJECT IDENTIFIER : sha-256 (2 16 840 1 101 3 4 2 1) : } 04 32: OCTET STRING : C5 AC 94 1A 0A 25 1F B3 16 6F 97 C5 52 40 9B 49 : 9E 7B 92 61 5A B0 A2 6C 19 BF B9 D8 09 C5 D9 E7 : } : } 30 2041: SEQUENCE { 16 2037: IA5String : 'data:image/svg+xml-compressed;base64,H4sICIGpy2E' : 'AA2xvZ28tY29weS5zdmcApVbbbhs3EH3nV0y3Lw2Q9fK2JLe' : 'wHDROUBRo2iBxW+RRlTa2UFkypIWV5ut7zlB2UqF9cuLlUkt' : 'yLmfOzPD8xafbtdyPu/1qu5k17sw2sp/mm+V8vd2Ms2azbV5' : 'cmPNvXv16efXh7WvZ31/L299e/vzTpTRt1/0RLrvu1dUref/' : '7j+KtdXawsete/9IYaW6m6e77rjscDmeHcLbdXXdX7zpu6t6' : '9vmxxon08AREdRDt7tpyWDRRSz7+tgp2b/ew/hEKI5WGoPKy' : 'W082s8SmeWf13NzVyM66ub6ZZk+xXH+9X4+Hl9tOssWLly35' : '53ARpd7txP+7uxx/2d+NiejefVttZ8+nNavkBj9yO40RLb8d' : 'pvpxP8wtzuRvn07iUP/+Wu+20my9GcWfOPpfDbjVN44YLb8d' : 'p3Mn7cb3aXGNCAICCc+a8+yLo/FpwfLP/uN3dzhqdriH5uwf' : 'bnj9a+Uz2i/maK66utA+zZ435uFqvZ823R38Q1t32Lw3pZqT' : 'hd/PpRpaz5o2LNkocvCzaIm0vrQvSpog359lLy3my0ga+e3H' : 'p+B4InjVFPD9awdhnrGEFW30Sl/Pnpvta2QBVxUEVxFbJ2VU' : 'FfYC01pUs+O4GK84V/k6CHUFyhvhiDVQF8Y5aPDbmnsrXbS7' : '4DANjguwgENZLPwjUYVTRJQgEpiLR0ctiWj+Ig8rCvZAArxK' : 'ExEEWMJLqMA1F+ggnsQDXgpQeomJPCVhtCRycNrAWxgAI+g1' : 'Qsr6IUxlomBswjydYBEgOeVCDoRreBjiFjX2SdSA60BP5DgQ' : 'M63xoPlWHbNq+egAEeAzxyNAdCQz+sDEMOhaGisKJdSlS6gt' : 'WWm4M1rQwP0egEBIhhFLoXuCJhR4mT5RJBaiLKqqFROUEzYr' : '1idG0gahwCzEnk+AMJLdp0FevQQ6VZ+SKOwGlOIJOh1MVjo0' : 'eB6DRA10SRpSY6il/eFFKAm+MKSIWNFqSo4OFnORfwH5wJHC' : 'MNM0qlDRlcIwUEkDlgiSBhiEpBgMKOx5FdAYqI3KYewKKkAI' : 'tTABTkp5khI86kgbOgRywEBR0VGcwAjf8t9wqvdUMG6gLAbI' : '0QQ8CbzCTtCSn/DEhCbm++duQaiRG1mQkdWHnminHA+r5wpL' Santesson, et al. Expires 14 June 2023 [Page 38] Internet-Draft Logotypes in X.509 Certificates December 2022 : 'vsJbCALUKsDW5NAj43J+AD5vpfamUzJqiRJACmCWwIMhQq4H' : 'mYGKaiiJPmIvpS80UzTtAjdSraApQZogslgFcJHw0y5WoEXD' : 'Yr/aTqfxk2qhcg3z6ETQL+S18llvHOZQvlEOVEVpzqCozE9V' : '6JZhh/lCslg7mUFY4AR7IlcApmgV6gz3DCSDe56fQ0SRS7el' : '0NJWO8mQ6mkc6ylPpaL7QUZ5IR/M/dEwoJiEp+L6iT4cdSyI' : 'p4ljDkoaZpQlgMoz0ApahjTiTWbZYu9v+MUqVjY61j2Bxr68' : 'bPF3uS1232qAyAQDMhr4MRyVZq5l2QcuwgY/oTozbgoIKycH' : '+yQxhzQsPJQ/ne9OmRKvYH1AeKA/EQRtzrmaYUiHUhpJOW4b' : 'reSaxZ/TVc3ZAQJKOagAJiw6pRHVkBMIBa5E+SUMWi0ZNW1R' : 'fn/xQXywHXyMHN5G8WF6gZ2IVjANHMIJQ1lAJQE8MJjZHJiU' : 'tQZAWzmkisDywTVWSqLkkQG2NNB3wwyaerqRGLNKpvwUOhaQ' : 'FiYcqviSjvp1n8WnRRzXFs9IXDxiiDd8HU/ROoAGn9+QgTPE' : 'Vu6HaN6i0VPuv1SCzwyZeHwBA1EjFYoAk2jJ3OFeJ5Gp1E+3' : 'Dlf3Aj70bbvmag5oyKHunVyGPq6+EnvTua/JUn3iadMHlqUa' : 'psK2T8SwCBJUF1JnEmhu0ntBthJoQpZqumsBk5mA1hRc0LR5' : 'ZFerdjksaCqt3IUWXcXW16vb6xdWyHLTgCaKXWKUKK1kOp9H' : 'K5B3ELjSdXb0loB5RYtS01L6h9yTPW51Wpqwgosr5I927aw6' : '401+YfwDria4WoQwAAA==' : } : } : } : } : } : } : } : } : } B.4. Embedded Certificate Image Example The following example displays a logotype extension containing one Certificate Image logotype using direct addressing. The Certificate Image logotype uses image/svg+xml-compressed. The logotype image is embedded in the certificate extension with a "data:" URI and the image is hashed by SHA-256. This example contains the image from Appendix B of RFC 6170, however, the media type used here is explicit about the use of GZIP compression [RFC1952]. The values on the left are the ASN.1 tag (in hexadecimal) and the length (in decimal). 30 2914: SEQUENCE { 06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12) 04 2900: OCTET STRING, encapsulates { 30 2896: SEQUENCE { A3 2892: [3] { 30 2888: SEQUENCE { 30 2884: SEQUENCE { Santesson, et al. Expires 14 June 2023 [Page 39] Internet-Draft Logotypes in X.509 Certificates December 2022 06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 20 3' A0 2870: [0] { 30 2866: SEQUENCE { 30 2862: SEQUENCE { 30 2858: SEQUENCE { 16 24: IA5String 'image/svg+xml-compressed' 30 49: SEQUENCE { 30 47: SEQUENCE { 30 11: SEQUENCE { 06 9: OBJECT IDENTIFIER : sha-256 (2 16 840 1 101 3 4 2 1) : } 04 32: OCTET STRING : 83 14 B3 26 9B D3 8B 0B 2A E6 6E 42 74 E2 A7 57 : 7A 40 B7 E1 2E 53 42 44 CC 7C AE 14 68 1B 0E B6 : } : } 30 2777: SEQUENCE { 16 2773: IA5String : 'data:image/svg+xml-compressed;base64,H4sICLXutU0' : 'AA0NlcnRJbWFnZURlbW8uc3ZnANVaW2/bOBZ+n19BqBigwdo' : 'S7xK9jmeapB0EWHQHzez2WZZoR1tZMiQ5jvvr95CSL7Gl1Em' : '8C9d9iERSPOd85+O5EB3+9jhL0YMuyiTPLh3iYgfpLMrjJJt' : 'eOv/661M/cFBZhVkcpnmmL50sd34b/TIsH6YoiS+da11UySS' : 'Jwkqj21k41Q6CDbNyUMSTS+e+quYDz1sul+6SuXkx9YhSysP' : 'Uo7QPK/rlKqvCx35Wvmu+a/uGYow9EOigh0Qvr/LHSwcjjDj' : 'GiGHQ914n0/sKlMf4Vwctk7i6X7/sGEYdNA5L/WeRT5IUDKm' : 'SbLVWNoo2cqNCh1XyoKN8Nsuz0iqwVW8Qb1fOF0Vqp+PI06m' : 'e6awqPeISzxn9goYzXYVxWIUWpfWLCMwcGoLpgy83n8wzGkb' : 'R4GtefENmMBznC7DEroKpOBpM8mIWVqPEYGtA+BvoMfS2E5u' : 'F1Wqu7R6FLvNFEelWReNolpiV3l2VpGntMW9nk6RKdf0+9Br' : 'FrMbeVuWhtzbHvMR6UlobPyVpBWjXBk7six2vH5nCwY6nXCo' : '5xb7YusvFVPqCOGh16fSxSxglmPkScLfvmDDmC4FlDc1wov8' : 'IF2WZhNlVumgEPRliimDD3PhGPyTgUUMC6lKqKAjxaptq1bo' : 'UJvQFsvi+LOJyxZkPE/vCwHuAmXmoj1AarnRBatzqkbv7cK5' : 'Ls2ORfwM/vsOG5lURZqXxOnDXPKZw5t5jVzIhFKO0B6D6hAR' : 'SXDR6Fzqq7H7mQeJAOQiUSPvFIrUHOfuui3zrFI5dYVeAmpc' : 'OcOb9u63vLjae4kYX4yRifYPrTa2SlMigYdO+cEWeGADMLZL' : 'H96SH4R9xRYApl6q3Y02f+NzlRAl+cZSKhB6qSIVa80fsqMn' : 'WOqZJpmsXwAPoyNaQ95uNIGasKPwhxGzQzOXzMIIzBKabmLI' : 'il470zfSjWWn+kvpvLQ9g1l3yRIc8gukz0uysEcakcDfy3KM' : 'k+l0SOXlOopltJL7EPtUlzZfP4tnM70k8xkKCySt92MwfIXP' : 'oTe0pnu4dYbp7hJ/kxWySN0ey0o/1qbiCsxDXJMWWo37QekB' : 'cAUFPSGkPCnUJF5wwBacDK5cGlEp4BC2lYoJcrNNGVc7DzIq' : 'xT4CKsPlrAG8mL8whRejiQe9EmImIAoz3sds9NxP4RZEzugq' : 'zb7c3Q89u3WQKY9aegbsA/AUJB/bJs6pfJt9BHFEuk5DWITz' : 'OH5uZSThLUsDjQ5GE6RMsyihMTaQLfA6BIiAQMAhnHHN1sd6' : '1WtUhDVJiuhkrdBXd740+hLB9Vm1HjQe4ywLOBLWOMMiyQAX' Santesson, et al. Expires 14 June 2023 [Page 40] Internet-Draft Logotypes in X.509 Certificates December 2022 : 'NB8sm9Gx2qdGgGkMG6wY8aLfqgH4dfnmrVc+pPrE/Z/QnZOs' : '8C1Okb2/ggwLdxlDC1D6DFPZDD98txv8xQf5TEc7Ax6ZyaDf' : '6BC4SylWKCMqtizp80+UMchATal63qHq0M3ZTs83Ob/XO6LY' : 'sFzpGVY5+iLxdWvwY+NaKoR/0iJIXL3dBjT2hG+wO+NXm53X' : 'StSh1eogfeojV35BTOaqh/cmPUe2Mdp91pQp2CjWOO2k7Oam' : 'hjU1HB3DLGm66n6iajz4bqn2oICmNFxDR/x2mC5s+rKhlkUA' : '3Ne3P8lgP0qJfjf9uvu+HWXSfFwNoH4uqGUmTadYMtOc7yjE' : 'Ed9EUhkwEEOcDSHKQ+yhnSvUYRH8miQo2FK5TCjWZZGWKB8i' : 'HPud16wApnCvTOzjIFAj9TQdCxa+ddOTizaa1xJvD0qMrKx+' : 'Ydaj6iwJQG0vaSdYWpTv4HwVRAP3Z6ONjOJunEIeKRVmhujp' : 'A2+wPmQR9WFQAFhh9bGQzFEXX+WwOnXq8pV35P2Acdn0pGeb' : 'cMg7OgQKaEdOKEAkFlk/9HuEKGBVwucc4AjnJ/LBYU09hVwW' : 'Y1F0HlBUC2lbyIuYF58O8p+adMwUt9YAoX/IwRtAC9NAdBAy' : 'GuEB3VR59u8/TGYx9/Xjz8bPB/Z/F9B0SghBK+4xxfiwtr0G' : 'XECqedQQ9PRVpEAQ+26MidbGSmPm8RwRzcQsT17EPSmoorH3' : '+av4Jcj78O/vIp/uzMEkHKAE6/F7VHHSj8HddR0Q3ymcGZfR' : 'VjwfmOnNn3GuWR+FzhcPmPqiptHcayacT28T8j3Cs0/LQCwo' : '6J2iYxP4R58AsobjFegusoJhuq7VNS2evRPcqASvQki+gbkB' : 'YwETNPt/1A2pT6UErR1zMzUITZRvF5Lp5basO1fk2U4aBSjk' : 'ji8quL3cDyW7TpI3unxezMcSTNhQJhfpGctKgKN2Amo7/7Sh' : 'Sev4oXicPSYS+6GkCm9a1Qw3VEchCUA+z5HtTcbQhK6F14YF' : 'Up+Yn7WgmzwpZCDf5DDiXT9B7U6RdHAHpdb7IqmLVjqZSLnT' : 'W61zjQ7/G7D3hm9E846uTDZoNMADmLlm7IG2ieXfUtu1US9T' : 'eNGUHibE9Nv//2jRJGZfQmK3v7ykJJOv1IXjBsDCPpmgWppe' : '6sHxR3KVSQKqp+WIqammuJbtqkxZmMHry4oS/9pLhdCXKq8u' : 'R0R+LDEqCKRxqc5VXdvPvIP+ggwR0RkyBfO9iKZvrWGAKVdz' : '31cuocvoO/qemClFMYEFEH7oI+vpkek4s4bCMBqK+5mHQUlD' : 'pE/oylpy+2/6pWXK31PEYagP04epV1cE50UMy6IQZeQM7+Ol' : '74Z+eHfpHNc7OjffQ/HeV0X8BopoDkGEkAAA=' : } : } : } : } : } : } : } : } : } : } : } Santesson, et al. Expires 14 June 2023 [Page 41] Internet-Draft Logotypes in X.509 Certificates December 2022 B.5. Full Certificate Example The following example contains a certificate for Alice; it is essentially a renewal of the certificate that appears in [RFC9216]. Of course, the serial number and issue dates are different. In addition, Alice's certificate now has a logotype extension. The extension contains URLs for two community logotype images, both at fictional URLs. The extension also contains URLs for two subject logotype images, both at fictional URLs. An implementation would display at most three of these images, both of the community logotype images and one of the subject logotype images. Direct addressing is used for all of the images, and the images are hashed by SHA-256. -----BEGIN CERTIFICATE----- MIIFpTCCBI2gAwIBAgITN0EFee11f0Kpolw69Phqzpqx1zANBgkqhkiG9w0BAQ0F ADBVMQ0wCwYDVQQKEwRJRVRGMREwDwYDVQQLEwhMQU1QUyBXRzExMC8GA1UEAxMo U2FtcGxlIExBTVBTIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAgFw0yMjA2 MTUxODE4MThaGA8yMDUyMDkyNzA2NTQxOFowOzENMAsGA1UEChMESUVURjERMA8G A1UECxMITEFNUFMgV0cxFzAVBgNVBAMTDkFsaWNlIExvdmVsYWNlMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtPSJ6Fg4Fj5Nmn9PkrYo0jTkfCv4TfA/ pdO/KLpZbJOAEr0sI7AjaO7B1GuMUFJeSTulamNfCwDcDkY63PQWl+DILs7GxVwX urhYdZlaV5hcUqVAckPvedDBc/3rz4D/esFfs+E7QMFtmd+K04s+A8TCNO12DRVB DpbP4JFD9hsc8prDtpGmFk7rd0q8gqnhxBW2RZAeLqzJOMayCQtws1q7ktkNBR2w ZX5ICjecF1YJFhX4jrnHwp/iELGqqaNXd3/Y0pG7QFecN7836IPPdfTMSiPR+peC rhJZwLSewbWXLJe3VMvbvQjoBMpEYlaJBUIKkO1zQ1Pq90njlsJLOwIDAQABo4IC hDCCAoAwDAYDVR0TAQH/BAIwADAXBgNVHSAEEDAOMAwGCmCGSAFlAwIBMAEwHgYD VR0RBBcwFYETYWxpY2VAc21pbWUuZXhhbXBsZTATBgNVHSUEDDAKBggrBgEFBQcD BDAOBgNVHQ8BAf8EBAMCBsAwHQYDVR0OBBYEFLv2zLItHQYSHJeuKWqQENMgZmZz MB8GA1UdIwQYMBaAFJEwjnwHFwyn8QkoZTYaZxxodvRZMIIB0AYIKwYBBQUHAQwE ggHCMIIBvqCB4zCB4KBvMG0wazBpFgppbWFnZS9qcGVnMDEwLzALBglghkgBZQME AgEEIK/8EBZGy1YltJl95Yk+rjqEb1oC04LW2o7U7vh8vR3tMCgWJmh0dHA6Ly93 d3cuZXhhbXBsZS5uZXQvaW1hZ2VzL2xvZ28uanBnoG0wazBpMGcWCWltYWdlL2dp ZjAxMC8wCwYJYIZIAWUDBAIBBCCIkIGBrftmri9m0EmgTY6g7E6oZEI4WzZKvyyL 0unpZjAnFiVodHRwOi8vd3d3LmV4YW1wbGUub3JnL2xvZ28taW1hZ2UuZ2lmooHV oIHSMIHPMGUwYxYJaW1hZ2UvZ2lmMDEwLzALBglghkgBZQMEAgEEIGpYUC5ZZ/nd 0Yr+vQ2x/mClExvfD7K+8LVzRVC6G78ZMCMWIWh0dHA6Ly93d3cuc21pbWUuZXhh bXBsZS9sb2dvLmdpZjBmMGQWCmltYWdlL2pwZWcwMTAvMAsGCWCGSAFlAwQCAQQg vct7dXJtjBszpCzerHly2krZ8nmEClhYas4vAoDq16UwIxYhaHR0cDovL3d3dy5z bWltZS5leGFtcGxlL2xvZ28uanBnMA0GCSqGSIb3DQEBDQUAA4IBAQBbjdCNVFA/ emCc5uKX5WSPrdvRFZSs57SEhE0odxvhTrOs13VM8Om0TxhNJ0Pl6d9CJdbUxtFw SSnSu9fnghDO7OZDJnPiIYLNY5eTTzY6sx85mde9TLaBTE7RZf0W7NV0hqDqcfM+ 9HnQrU4TtPSvtPS5rr5SvqkaMM0k89bpbkgZlh9HH14+x+DIeT0dLythiXJvkVod qEfyZTcdplQHQ4szWO7lsjmvHrUIbS1tdAJnah8AZRZfqiJEFeiUp06hvAWnPc3y 1TMwYI8onfwPIVzyT6YLgjiT6PuLwSB/wtlhI+vWfdINaHdotegjawLm/3jZ+ceN tu39FvbV0uKJ -----END CERTIFICATE----- Santesson, et al. Expires 14 June 2023 [Page 42] Internet-Draft Logotypes in X.509 Certificates December 2022 The following displays the logotype extension from Alice's certificate. The values on the left are the ASN.1 tag (in hexadecimal) and the length (in decimal). 30 464: SEQUENCE { 06 8: OBJECT IDENTIFIER logotype (1 3 6 1 5 5 7 1 12) 04 450: OCTET STRING, encapsulates { 30 446: SEQUENCE { A0 227: [0] { 30 224: SEQUENCE { A0 111: [0] { 30 109: SEQUENCE { 30 107: SEQUENCE { 30 105: SEQUENCE { 16 10: IA5String 'image/jpeg' 30 49: SEQUENCE { 30 47: SEQUENCE { 30 11: SEQUENCE { 06 9: OBJECT IDENTIFIER : sha-256 (2 16 840 1 101 3 4 2 1) : } 04 32: OCTET STRING : AF FC 10 16 46 CB 56 25 B4 99 7D E5 89 3E AE 3A : 84 6F 5A 02 D3 82 D6 DA 8E D4 EE F8 7C BD 1D ED : } : } 30 40: SEQUENCE { 16 38: IA5String 'http://www.example.net/images/logo.jpg' : } : } : } : } : } A0 109: [0] { 30 107: SEQUENCE { 30 105: SEQUENCE { 30 103: SEQUENCE { 16 9: IA5String 'image/gif' 30 49: SEQUENCE { 30 47: SEQUENCE { 30 11: SEQUENCE { 06 9: OBJECT IDENTIFIER : sha-256 (2 16 840 1 101 3 4 2 1) : } 04 32: OCTET STRING : 88 90 81 81 AD FB 66 AE 2F 66 D0 49 A0 4D 8E A0 : EC 4E A8 64 42 38 5B 36 4A BF 2C 8B D2 E9 E9 66 : } Santesson, et al. Expires 14 June 2023 [Page 43] Internet-Draft Logotypes in X.509 Certificates December 2022 : } 30 39: SEQUENCE { 16 37: IA5String 'http://www.example.org/logo-image.gif' : } : } : } : } : } : } : } A2 213: [2] { A0 210: [0] { 30 207: SEQUENCE { 30 101: SEQUENCE { 30 99: SEQUENCE { 16 9: IA5String 'image/gif' 30 49: SEQUENCE { 30 47: SEQUENCE { 30 11: SEQUENCE { 06 9: OBJECT IDENTIFIER : sha-256 (2 16 840 1 101 3 4 2 1) : } 04 32: OCTET STRING : 6A 58 50 2E 59 67 F9 DD D1 8A FE BD 0D B1 FE 60 : A5 13 1B DF 0F B2 BE F0 B5 73 45 50 BA 1B BF 19 : } : } 30 35: SEQUENCE { 16 33: IA5String 'http://www.smime.example/logo.gif' : } : } : } 30 102: SEQUENCE { 30 100: SEQUENCE { 16 10: IA5String 'image/jpeg' 30 49: SEQUENCE { 30 47: SEQUENCE { 30 11: SEQUENCE { 06 9: OBJECT IDENTIFIER : sha-256 (2 16 840 1 101 3 4 2 1) : } 04 32: OCTET STRING : BD CB 7B 75 72 6D 8C 1B 33 A4 2C DE AC 79 72 DA : 4A D9 F2 79 84 0A 58 58 6A CE 2F 02 80 EA D7 A5 : } : } 30 35: SEQUENCE { 16 33: IA5String 'http://www.smime.example/logo.jpg' Santesson, et al. Expires 14 June 2023 [Page 44] Internet-Draft Logotypes in X.509 Certificates December 2022 : } : } : } : } : } : } : } : } : } Appendix C. Changes Since RFC 3709 and RFC 6170 This appendix summarizes the changes since RFC 3709. The changes are: * Combine RFC 3709 and RFC 6170 into one document, and encourage implementers to support the "data" URI scheme (data:...) that was originally specified in RFC 6170. Merging RFC 3709 and RFC 6170 lead to many editoral changes throughout the document. * Drop SHA-1 as the mandatory-to-implement hash algorithm, and encourage use of the one-way hash function that is employed by the certificate signature algorithm. * RFC 3709 required client applications to support both direct and indirect addressing. This requirement is changed to SHOULD support both direct and indirect addressing to allow implementations to be more privacy preserving. * Update the reference for language tags to be RFC 5646 instead of the now obsolete RFC 3066. * Update the reference for the URI Generic Syntax to be RFC 3986 instead of the now obsolete RFC 2396. * Update the reference for the application/pdf media type to be RFC 8118 instead of the now obsolete RFC 3778. * No longer require support for the FTP scheme (ftp://...) URI. * Require support for the HTTP scheme (http://...) URI and the HTTPS scheme (https://...) URI. * Require support for the compressed SVG image format with the image/svg+xml+gzip media type. * Media types MUST follow the ABNF [RFC5234] that is provided in Section 4.2 of [RFC6838]. This change resolves Errata ID 2679. Santesson, et al. Expires 14 June 2023 [Page 45] Internet-Draft Logotypes in X.509 Certificates December 2022 * Remove the requirement that the LogotypeData file name have a file extension of ".LTD". This change resolves Errata ID 2325. * Encourage, instead of requiring, each logotype to be represented by at least one image. * Encourage the inclusion of text-based audio data suitable for processing by a text-to-speech software using the MIME type of "text/plain;charset=UTF-8". * Encourage the use of dithering if an image needs to be scaled. * Require that the logotype extension not contain more than one certificate image logotype. * Privacy-related topics that were previously discussed in the Security Considerations section are now covered in a separate Privacy Considerations section. Additional topics are covered in both sections. * Provide ASN.1 modules for both the older syntax [OLD-ASN1] and the most recent ASN.1 syntax [NEW-ASN1]. * Provide additional references. * Provide additional examples. * Several editorial changes to improve clarity. * The example in Appendix B.1 was changed to use SHA-256 instead of SHA-1. Authors' Addresses Stefan Santesson IDsec Solutions AB Forskningsbyn Ideon SE-223 70 Lund Sweden Email: sts@aaa-sec.com Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA, 20170 United States of America Email: housley@vigilsec.com Santesson, et al. Expires 14 June 2023 [Page 46] Internet-Draft Logotypes in X.509 Certificates December 2022 Trevor Freeman Amazon Web Services 1918 8th Ave Seattle, WA, 98101 United States of America Email: frtrevor@amazon.com Leonard Rosenthol Adobe 345 Park Avenue San Jose, CA, 95110 United States of America Email: lrosenth@adobe.com Santesson, et al. Expires 14 June 2023 [Page 47] ./draft-ietf-dime-group-signaling-14.txt0000644000764400076440000017200114272507014017675 0ustar iustiniustin Diameter Maintenance and Extensions (DIME) M. Jones Internet-Draft Individual Intended status: Standards Track M. Liebsch Expires: February 4, 2023 NEC L. Morand Orange August 3, 2022 Diameter Group Signaling draft-ietf-dime-group-signaling-14.txt Abstract In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. In some use cases, Diameter nodes need to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 4, 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Jones, et al. Expires February 4, 2023 [Page 1] Internet-Draft Diameter Group Signaling August 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, 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 of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Building and Modifying Session Groups . . . . . . . . . . 4 3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . 4 3.3. Permission Considerations . . . . . . . . . . . . . . . . 5 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 4.1. Session Grouping Capability Discovery . . . . . . . . . . 5 4.1.1. Capability Discovery based on the Application Id . . 5 4.1.2. Capability Discovery based on AVP Presence . . . . . 6 4.2. Session Grouping . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Group assignment at session initiation . . . . . . . 7 4.2.2. Removing a session from a session group . . . . . . . 9 4.2.3. Mid-session group assignment modifications . . . . . 11 4.3. Deleting a Session Group . . . . . . . . . . . . . . . . 12 4.4. Performing Group Operations . . . . . . . . . . . . . . . 12 4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 12 4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 13 4.4.3. Error Handling for Group Commands . . . . . . . . . . 13 4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 14 5. Operation with Proxy Agents . . . . . . . . . . . . . . . . . 14 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 15 6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 15 7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 16 7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 16 7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 17 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 17 7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 18 7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 18 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 12. Normative References . . . . . . . . . . . . . . . . . . . . 20 Jones, et al. Expires February 4, 2023 [Page 2] Internet-Draft Diameter Group Signaling August 2022 Appendix A. Session Management -- Exemplary Session State Machine . . . . . . . . . . . . . . . . . . . . . . 21 A.1. Use of groups for the Authorization Session State Machine 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. In some use cases, Diameter nodes need to apply the same operation to a large group of Diameter sessions concurrently. For example, a policy decision point may need to modify the authorized quality of service for all active users having the same type of subscription. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges. This document describes mechanisms for grouping Diameter sessions and applying Diameter commands, such as performing re-authentication, re- authorization, termination and abortion of sessions to a group of sessions. This document does not define a new Diameter application. Instead it defines mechanisms, commands and AVPs that may be used by any Diameter application that requires management of groups of sessions. These mechanisms take the following design goals and features into account: o Minimal impact to existing applications o Extension of existing commands' Command Code Format (CCF) with optional AVPs to enable grouping and group operations o Fallback to single session operation o Implicit discovery of capability to support grouping and group operations in case no external mechanism is available to discover a Diameter peer's capability to support session grouping and session group operations 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP Jones, et al. Expires February 4, 2023 [Page 3] Internet-Draft Diameter Group Signaling August 2022 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses terminology defined in [RFC6733]. 3. Protocol Overview 3.1. Building and Modifying Session Groups In order to accommodate bulk operations on Diameter sessions, the concept of session groups is introduced. Once sessions are added to a group, a command acting on the group will affect all the member sessions. Client and Server can assign a new Diameter session to a group, e.g., in case the subscription profile of the associated user has similar characteristics as the profile of other users whose Diameter session has been assigned to one or multiple groups. A single command can be issued and applied to all sessions associated with such group(s), e.g., to adjust common profile or policy settings. The assignment of a Diameter session to a group can be changed during an ongoing session (mid-session). For example, if a user's subscription profile changes mid-session, a Diameter server may remove a session from an existing group and assign this session to a different group that is more appropriate for the new subscription profile. In the case of mobile users, the user's session may get transferred mid-session to a new Diameter client during handover and assigned to a different group, which is maintained at the new Diameter client. It may be required to delete a session group, e.g. at the expiry of a promotional period that applied to multiple subscriber profiles. Deletion of such group requires subsequent individual treatment of each of the assigned sessions. A node may decide to assign some of these sessions to any other existing or new group. 3.2. Issuing Group Commands Changes in the network condition may result in the Diameter server's decision to close all sessions in a given group. As example, the server issues a single Session Termination Request (STR) command, including the identifier of the group of sessions which are to be terminated. The Diameter client treats the STR as group command and initiates the termination of all sessions associated with the identified group. Subsequently, the client confirms the successful termination of these sessions to the server by sending a single Jones, et al. Expires February 4, 2023 [Page 4] Internet-Draft Diameter Group Signaling August 2022 Session Termination Answer (STA) command, which includes the identifier of the group. 3.3. Permission Considerations Permission considerations in the context of this draft apply to the permission of Diameter nodes to build new session groups, to assign/ remove a session to/from a session group and to delete an existing session group. When a client or a server decides to create a new session group, e.g., to group all sessions which share certain characteristics, this node builds a session group identifier according to the rules described in Section 7.3 and becomes the owner of the group. After the creation of a session group, a session can be added to this session group by either the client or the server. However, a session can only be removed from a session group by the Diameter node (client or server) that has assigned this session to the session group. A session group can only be deleted by the owner of the session group, resulting in individual treatment of the sessions that were assigned to this session group. Diameter applications with implicit support for session groups MAY define a more constrained permission model. For example, a more constrained model could require that a client must not remove a session from a group which is owned by the server. Details about enforcing a more constrained permission model are out of scope of this specification. 4. Protocol Description 4.1. Session Grouping Capability Discovery Diameter nodes SHOULD NOT perform group operations with peer nodes unless the node has advertised support for session grouping and group operations. 4.1.1. Capability Discovery based on the Application Id Newly defined Diameter applications may natively support Diameter session grouping and group operations. Such applications provide intrinsic discovery for the support of session grouping capability using the assigned Application Id advertised during the capability exchange phase described in Section 5.3 of [RFC6733]. Jones, et al. Expires February 4, 2023 [Page 5] Internet-Draft Diameter Group Signaling August 2022 System- and deployment-specific means, as well as out-of-band mechanisms for capability discovery can be used to announce nodes' support for session grouping and session group operations. In such case, the optional Session-Group-Capability-Vector AVP, as described in Section 4.1.2 can be omitted in Diameter messages being exchanged between nodes. 4.1.2. Capability Discovery based on AVP Presence If no other mechanism for capability discovery is deployed to enable Diameter nodes to learn about nodes' capability to support session grouping and group commands for a given application, a Diameter node SHOULD append the Session-Group-Capability-Vector AVP to any Diameter application messages exchanged with the other Diameter nodes to announce its capability to support session grouping and session group operations for the advertised application. Implementations following the specification as per this document MUST set the BASE_SESSION_GROUP_CAPABILITY flag of the Session-Group-Capability- Vector AVP. When a Diameter node receives at least one Session-Group-Capability- Vector AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag set, the receiving Diameter node discovers the supported session grouping capability of the sending Diameter node for the advertised application and MUST cache this information for the lifetime of the routing table entry associated with the peer identity/Application Id pair (see Section 2.7 of [RFC6733]). 4.2. Session Grouping This specification does not limit the number of session groups to which a single session is assigned. It is left to the implementation of an application to determine such limitations. If an application facilitates a session to belong to multiple session groups, the application MUST maintain consistency of associated application session states for these multiple session groups. Either Diameter node (client or server) can initiate the assignment of a session to a single or multiple session groups. Modification of a group by removing or adding a single or multiple user sessions can be initiated and performed mid-session by either Diameter node responsible for the session assignment to this group. Although Diameter is a peer-to-peer protocol, Diameter AAA applications typically assign the role of a "Diameter client" to the Diameter node initiating the Diameter session and the role of "Diameter server" to the node authorizing the Diameter session. This specification does not restrict group creation, assignment or deletion actions to a specific role. In the following sections, "Diameter node" is used to Jones, et al. Expires February 4, 2023 [Page 6] Internet-Draft Diameter Group Signaling August 2022 refer to either role. Section 5 describes particularities about session grouping and performing group commands when relay agents or proxies are deployed. Any Diameter node that has advertised support of session grouping and group operations MUST store and maintain the group assignment as part of the session's state. A list of all known session groups is locally maintained on each node, each group pointing to individual sessions being assigned to the group. Each Diameter node MUST also keep a record about sessions that it has assigned to a session group. 4.2.1. Group assignment at session initiation To assign a session to a group at session initiation, a Diameter client sends a service specific request, e.g., NASREQ AA-Request [RFC7155], containing one or more session group identifiers. Each of these groups MUST be identified by a unique Session-Group-Id contained in a separate Session-Group-Info AVP as specified in Section 7. The client may choose one or multiple session groups from a list of existing session groups. Alternatively, the client may decide to create a new group to which the session is assigned and identify itself in the portion of the Session-Group-Id AVP as per Section 7.3. For all assignments of a session to an active session group made by the client or the server, the SESSION_GROUP_STATUS flag in the Session-Group-Info AVP, which identifies the session group, MUST be set. A set SESSION_GROUP_STATUS flag indicates that the identified session group has just been created or is still active. The client MUST set the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-Vector AVP in each appended Session-Group-Info AVP to indicate that the session contained in the request should be assigned to the identified session group. The client may also indicate in the request that it supports assignment of the session to one or more groups by the server. In such a case, the client MUST include the Session-Group-Info AVP in the request including the Session-Group-Control-Vector AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP. If the Diameter server receives a command request from a Diameter client and the command includes at least one Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group- Control-Vector AVP set, the server can accept or reject the request for group assignment. Reasons for rejection may be e.g., lack of Jones, et al. Expires February 4, 2023 [Page 7] Internet-Draft Diameter Group Signaling August 2022 resources for managing additional groups. When rejected, the session MUST NOT be assigned to any session group. If the Diameter server accepts the client's request for a group assignment, the server MUST assign the new session to each of the one or multiple identified session groups when present in the Session- Group-Info AVP. If one or multiple identified session groups are not already stored by the server, the server MUST store the newly identified group(s) to its local list of known session groups. When sending the response to the client, e.g., a service-specific auth response as per NASREQ AA-Answer [RFC7155], the server MUST include all Session-Group-Info AVPs as received in the client's request. In addition to the one or multiple session groups identified in the client's request, the server may decide to assign the new session to one or multiple additional groups. In such a case, the server MUST add to the response the additional Session-Group-Info AVPs, each identifying a session group to which the new session is assigned by the server. Each of the Session-Group-Info AVP added by the server MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the Session-Group-Control-Vector AVP. If the Diameter server rejects the client's request for a group assignment, the server sends the response to the client, e.g., a service-specific auth response as per NASREQ AA-Answer [RFC7155], and MUST include all Session-Group-Info AVPs as received in the client's request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-Vector AVP. The server MAY still accept the client's request for the identified session to proceed despite rejecting the group assignment. The response sent to the client will then indicate success in the result code. In this case, the session is treated as single session without assignment to any session group by the Diameter nodes. If the assignment of the session to one or some of the multiple identified session groups fails, the session group assignment is treated as failure. In such case the session is treated as single session without assignment to any session group by the Diameter nodes. The server sends the response to the client and MAY include those Session-Group-Info AVPs for which the group assignment failed. The SESSION_GROUP_ALLOCATION_ACTION flag of included Session-Group- Info AVPs MUST be cleared. If the Diameter server receives a command request from a Diameter client and the command includes a Session-Group-Info AVP which does not include a Session-Group-Id AVP, the server MAY decide to assign the session to one or multiple session groups. For each session group, to which the server assigns the new session, the server Jones, et al. Expires February 4, 2023 [Page 8] Internet-Draft Diameter Group Signaling August 2022 includes a Session-Group-Info AVP with the Session-Group-Id AVP identifying a session group in the response sent to the client. Each of the Session-Group-Info AVPs included by the server MUST have the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- Vector AVP set. If the Diameter server receives a command request from a Diameter client and the command does not contain any Session-Group-Info AVP, the server MUST NOT assign the new session to any session group but treat the request as for a single session. The server MUST NOT return any Session-Group-Info AVP in the command response. If the Diameter client receives a response to its previously issued request from the server and the response includes at least one Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION flag of the associated Session-Group-Control-Vector AVP set, the client MUST add the new session to all session groups as identified in the one or multiple Session-Group-Info AVPs. If the Diameter client fails to add the session to one or more session groups as identified in the one or multiple Session-Group-info AVPs, the client MUST terminate the session. The client MAY send a subsequent request for session initiation to the server without requesting the assignment of the session to a session group. If the Diameter client receives a response to its previously issued request from the server and the one or more Session-Group-Info AVPs have the SESSION_GROUP_ALLOCATION_ACTION flag of the associated Session-Group-Control-Vector AVP cleared, the client MUST terminate the assignment of the session to the one or multiple groups. If the response from the server indicates success in the result code but only the assignment of the session to a session group has been rejected by the server, the client treats the session as single session without group assignment. If a Diameter client sends a request for session initiation containing one or more Session-Group-Info AVPs but the response from the Diameter server does not contain a Session-Group-Info AVP, the Diameter client MUST proceed as if the request was processed without group assignments. The Diameter client MUST NOT retry to request group assignment for this session, but MAY try to request group assignment for other new sessions. 4.2.2. Removing a session from a session group When a Diameter client decides to remove a session from a particular session group, the client sends a service-specific re-authorization request to the server and adds one Session-Group-Info AVP to the request for each session group, from which the client wants to remove Jones, et al. Expires February 4, 2023 [Page 9] Internet-Draft Diameter Group Signaling August 2022 the session. The session that is to be removed from a group is identified in the Session-Id AVP of the command request. The SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- Vector AVP in each Session-Group-Info AVP MUST be cleared to indicate removal of the session from the session group identified in the associated Session-Group-id AVP. When a Diameter client decides to remove a session from all session groups to which the session has been previously assigned, the client sends a service-specific re-authorization request to the server and adds a single Session-Group-Info AVP to the request which has the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP omitted. The Session-Id AVP in the re-authorization request identifies the session that is to be removed from all groups to which it had been previously assigned. If the Diameter server receives a request from the client which has at least one Session-Group-Info AVP appended with the SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server MUST remove the session from the session group identified in the associated Session-Group-Id AVP. If the request includes at least one Session- Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Id AVP present, the server MUST remove the session from all session groups to which the session has been previously assigned. The server MUST include in its response to the requesting client all Session-Group-Id AVPs as received in the request. When the Diameter server decides to remove a session from one or multiple particular session groups or from all session groups to which the session has been assigned beforehand, the server sends a Re-Authorization Request (RAR) or a service-specific server-initiated request to the client, indicating the session in the Session-Id AVP of the request. The client sends a Re-Authorization Answer (RAA) or a service-specific answer to respond to the server's request. The client subsequently sends service-specific re-authorization request containing one or multiple Session-Group-Info AVPs, each indicating a session group, to which the session had been previously assigned. To indicate removal of the indicated session from one or multiple session groups, the server sends a service-specific auth response to the client, containing a list of Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP identifying the session group, from which the session should be removed. The server MAY include to the service-specific auth response a list of Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP identifying session groups to which the session remains subscribed. If the server decides to remove the identified session from all session groups, to which the session has been previously assigned, Jones, et al. Expires February 4, 2023 [Page 10] Internet-Draft Diameter Group Signaling August 2022 the server includes in the service-specific auth response at least one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and Session-Group-Id AVP absent. 4.2.3. Mid-session group assignment modifications Either Diameter node (client or server) can modify the group membership of an active Diameter session according to the specified permission considerations. To update an assigned group mid-session, a Diameter client sends a service-specific re-authorization request to the server, containing one or multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP present, identifying the session group to which the session should be assigned. With the same message, the client MAY send one or multiple Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP identifying the session group from which the identified session is to be removed. To remove the session from all previously assigned session groups, the client includes at least one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id AVP present. When the server received the service-specific re- authorization request, it MUST update its locally maintained view of the session groups for the identified session according to the appended Session-Group-Info AVPs. The server sends a service- specific auth response to the client containing one or multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP identifying the new session group to which the identified session has been assigned. When a Diameter server decides to update assigned groups mid-session, it sends a Re-Authorization Request (RAR) message or a service- specific request to the client identifying the session, for which the session group lists are to be updated. The client responds with a Re-Authorization Answer (RAA) message or a service-specific answer. The client subsequently sends a service-specific re-authorization request containing one or multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP identifying the session group to which the session had been previously assigned. The server responds with a service-specific auth response and includes one or multiple Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and the Session- Group-Id AVP identifying the session group, to which the identified session is to be assigned. With the same response message, the server MAY send one or multiple Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id AVP identifying the session groups from which the identified session Jones, et al. Expires February 4, 2023 [Page 11] Internet-Draft Diameter Group Signaling August 2022 is to be removed. When a server wants to remove the session from all previously assigned session groups, it sends at least one Session- Group-Info AVP with the response having the SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id AVP present. 4.3. Deleting a Session Group To explicitly delete a session group and release the associated Session-Group-Id value, the owner of a session group appends a single Session-Group-Info AVP having the SESSION_GROUP_STATUS flag cleared and the Session-Group-Id AVP identifying the session group, which is to be deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated Session-Group-Control-Vector AVP MUST be cleared. A session group is implicitly deleted and its identifier released after the last session has been removed from this session group. 4.4. Performing Group Operations 4.4.1. Sending Group Commands Either Diameter node (client or server) can request the recipient of a request to process an associated command for all sessions assigned to one or multiple groups by identifying these groups in the request. The sender of the request appends for each group, to which the command applies, a Session-Group-Info AVP including the Session- Group-Id AVP to identify the associated session group. Both, the SESSION_GROUP_ALLOCATION_ACTION flag as well as the SESSION_GROUP_STATUS flag MUST be set. If the Command Code Format (CCF) of the request mandates a Session-Id AVP, the Session-Id AVP MUST identify one of the single sessions which is assigned to at least one of the groups being identified in the appended Session-Group-Id AVPs. The sender of the request MUST indicate to the receiver how multiple resulting transactions associated with a group command are to be treated by appending a single instance of a Group-Response-Action AVP. For example, when a server sends a Re-Authorization Request (RAR) or a service-specific server-initiated request to the client, it indicates to the client to follow the request according to one of three possible procedures. When the server sets the Group-Response- Action AVP to ALL_GROUPS (1), the client sends a single RAR message for all identified groups. When the server sets the Group-Response- Action AVP to PER_GROUP (2), the client sends a single RAR message for each identified group individually. When the server sets the Group-Response-Action AVP to PER_SESSION (3), the client follows-up Jones, et al. Expires February 4, 2023 [Page 12] Internet-Draft Diameter Group Signaling August 2022 with a single RAR message per impacted session. If a session is included in more than one of the identified session groups, the client sends only one RAR message for that session. If the sender sends a request including the Group-Response-Action AVP set to ALL_GROUPS (1) or PER_GROUP (2), it has to expect some delay before receiving the corresponding answer(s) as the answer(s) will only be sent back when the request is processed for all the sessions or all the session of a session group. If the processing of the request is delay-sensitive, the sender SHOULD NOT set the Group- Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2). If the answer can be sent before the complete process of the request for all the sessions or if the request timeout timer is high enough, the sender MAY set the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2). If the sender wants the receiver of the request to process the associated command solely for a single session, the sender does not append any group identifier, but identifies the relevant session in the Session-Id AVP. 4.4.2. Receiving Group Commands A Diameter node receiving a request to process a command for a group of sessions, identifies the relevant groups according to the included Session-Group-Id AVP in the Session-Group-Info AVP and processes the group command according to the included Group-Response-Action AVP. If the received request identifies multiple groups in multiple included Session-Group-Id AVPs, the receiver SHOULD process the associated command for each of these groups. If a session has been assigned to more than one of the identified groups, the receiver MUST process the associated command only once per session. 4.4.3. Error Handling for Group Commands When a Diameter node receives a request to process a command for one or more session groups and the result of processing the command is an error that applies to all sessions in the identified groups, an associated protocol error MUST be returned to the source of the request. In such case, the sender of the request MUST fall back to single-session processing and the session groups, which have been identified in the group command, MUST be deleted according to the procedure described in Section 4.3. When a Diameter node receives a request to process a command for one or more session groups and the result of processing the command succeeds for some sessions identified in one or multiple session groups, but fails for one or more sessions, the Result-Code AVP in Jones, et al. Expires February 4, 2023 [Page 13] Internet-Draft Diameter Group Signaling August 2022 the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per Section 7.1.2 of [RFC6733]. In the case of limited success, the sessions, for which the processing of the group command failed, MUST be identified by including their Session-Id AVP in the Failed-AVP AVP as per Section 7.5 of [RFC6733]. The sender of the request MUST fall back to single-session operation for each of the identified sessions, for which the group command failed. In addition, each of these sessions MUST be removed from all session groups to which the group command applied. To remove sessions from a session group, the Diameter client performs the procedure described in Section 4.2.2. 4.4.4. Single-Session Fallback Either Diameter node can fall back to single session operation by ignoring and omitting the optional group session-specific AVPs. Fallback to single-session operation is performed by processing the Diameter command solely for the session identified in the mandatory Session-Id AVP. In such case, the response to the group command MUST NOT identify any group but identify solely the single session for which the command has been processed. 5. Operation with Proxy Agents In the case of a present stateful Proxy Agent between a Diameter client and a Diameter server, the Proxy Agent MUST perform the same mechanisms per this specification to advertise session grouping and group operations capability towards the client and the server respectively. The Proxy MUST update and maintain consistency of its local session states as per the result of the group commands which are operated between a Diameter client and a server. In such case, the Proxy Agent MUST act as a Diameter server in front of the Diameter client and MUST act as a Diameter client in front of the Diameter server. Therefore, the client and server behavior described in Section 4 applies respectively to the stateful Proxy Agent. If a stateful Proxy Agent manipulates session groups, it MUST maintain consistency of session groups between a client and a server. This applies to a deployment where the Proxy Agent utilizes session grouping and performs group operations with, for example, a Diameter server, whereas the Diameter client is not aware of session groups. In such case the Proxy Agent must reflect the states associated with the session groups as individual session operations towards the client and ensure the client has a consistent view of each session. The same applies to a deployment where all nodes, the Diameter client and server, as well as the Proxy Agent are group-aware but the Proxy Jones, et al. Expires February 4, 2023 [Page 14] Internet-Draft Diameter Group Signaling August 2022 Agent manipulates groups, e.g., to adopt different administrative policies that apply to the client's domain and the server's domain. Stateless Proxy Agents do not maintain any session state (only transaction state are maintained). Consequently, the notion of session group is transparent for any stateless Proxy Agent present between a Diameter client and a Diameter server handling session groups. Session group related AVPs being defined as optional AVP are ignored by stateless Proxy Agents and should not be removed from the Diameter commands. If they are removed by the Proxy Agent for any reason, the Diameter client and Diameter server will discover the absence the related session group AVPs and will fall back to single- session processing, as described in Section 4. 6. Commands Formatting This document does not specify new Diameter commands to enable group operations, but relies on command extensibility capability provided by the Diameter Base protocol. This section provides the guidelines to extend the CCF of existing Diameter commands with optional AVPs to enable the recipient of the command applying the command to all sessions associated with the identified group(s). 6.1. Formatting Example: Group Re-Auth-Request A request for re-authentication of one or more groups of users is issued by appending one or multiple Session-Group-Id AVP(s), as well as a single instance of a Group-Response-Action AVP to the Re-Auth- Request (RAR). The one or multiple Session-Group-Id AVP(s) identify the associated group(s) for which the group re-authentication has been requested. The Group-Response-Action AVP identifies the expected means to perform and respond to the group command. The recipient of the group command initiates re-authentication for all users associated with the identified group(s). Furthermore, the sender of the group re-authentication request appends a Group- Response-Action AVP to provide more information to the receiver of the command about how to accomplish the group operation. The value of the mandatory Session-Id AVP MUST identify a session associated with a single user, which is assigned to at least one of the groups being identified in the appended Session-Group-Id AVPs. Jones, et al. Expires February 4, 2023 [Page 15] Internet-Draft Diameter Group Signaling August 2022 ::= < Diameter Header: 258, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } { Re-Auth-Request-Type } [ User-Name ] [ Origin-State-Id ] * [ Proxy-Info ] * [ Route-Record ] [ Session-Group-Capability-Vector ] * [ Session-Group-Info ] [ Group-Response-Action ] * [ AVP ] 7. Attribute-Value-Pairs (AVP) +--------------------+ | AVP Flag rules | +----+---+------+----+ AVP | | |SHOULD|MUST| Attribute Name Code Value Type |MUST|MAY| NOT | NOT| +-------------------------------------------------+----+---+------+----+ |Session-Group-Info TBD1 Grouped | | P | | V | |Session-Group-Control-Vector TBD2 Unsigned32 | | P | | V | |Session-Group-Id TBD3 UTF8String | | P | | V | |Group-Response-Action TBD4 Unsigned32 | | P | | V | |Session-Group-Capability-Vector TBD5 Unsigned32 | | P | | V | +-------------------------------------------------+----+---+------+----+ AVPs for the Diameter Group Signaling 7.1. Session-Group-Info AVP The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It contains the identifier of the session group as well as an indication of the node responsible for session group identifier assignment. Session-Group-Info ::= < AVP Header: TBD1 > < Session-Group-Control-Vector > [ Session-Group-Id ] * [ AVP ] Jones, et al. Expires February 4, 2023 [Page 16] Internet-Draft Diameter Group Signaling August 2022 7.2. Session-Group-Control-Vector AVP The Session-Group-Control-Vector AVP (AVP Code TBD2) is of type Unsigned32 and contains a 32-bit flags field to control the group assignment at session-group aware nodes. For defined flags only numeric values that are 2^x (power of two, where 0<=x<32) are allowed. The following control flags are defined in this document: SESSION_GROUP_ALLOCATION_ACTION (0x00000001) This flag indicates the action to be performed for the identified session. When this flag is set, it indicates that the identified Diameter session is to be assigned to the session group as identified by the Session-Group-Id AVP or the session's assignment to the session group identified in the Session-Group-Id AVP is still valid. When the flag is cleared, the identified Diameter session is to be removed from at least one session group. When the flag is cleared and the Session-Group-Info AVP identifies a particular session group in the associated Session-Group-Id AVP, the session is to be removed solely from the identified session group. When the flag is cleared and the Session-Group-Info AVP does not identify a particular session group (Session-Group-Id AVP is absent), the identified Diameter session is to be removed from all session groups to which it has been previously assigned. SESSION_GROUP_STATUS (0x00000010) This flag indicates the status of the session group identified in the associated Session-Group-Id AVP. The flag is set when the identified session group has just been created or is still active. If the flag is cleared, the identified session group is deleted and the associated Session-Group-Id is released. If the Session- Group-Info AVP does not include a Session-Group-Id AVP, this flag is meaningless and MUST be ignored by the receiver. 7.3. Session-Group-Id AVP The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and identifies a group of Diameter sessions. The Session-Group-Id MUST be globally unique. The Session-Group-Id includes a mandatory portion and an implementation-defined portion delimited by the ";" character. The Session-Group-Id MUST begin with the identity of the Diameter node that owns the session group. The remainder of the Session-Group-Id is implementation-defined and MAY Jones, et al. Expires February 4, 2023 [Page 17] Internet-Draft Diameter Group Signaling August 2022 follow the format recommended for the implementation-defined portion of the Session-Id AVP in section 8.8 of [RFC6733]. 7.4. Group-Response-Action AVP The Group-Response-Action AVP (AVP Code TBD4) is of type Unsigned32 and contains a 32-bit address space representing values indicating how the node SHOULD issue follow up exchanges in response to a command which impacts multiple sessions. The following values are defined by this document: ALL_GROUPS (1) Follow up message exchanges associated with a group command should be performed with a single message exchange for all impacted groups. PER_GROUP (2) Follow up message exchanges associated with a group command should be performed with a separate message exchange for each impacted group. PER_SESSION (3) Follow up message exchanges associated with a group command should be performed with a separate message exchange for each impacted session. 7.5. Session-Group-Capability-Vector AVP The Session-Group-Capability-Vector AVP (AVP Code TBD5) is of type Unsigned32 and contains a 32-bit flags field to indicate capabilities in the context of session-group assignment and group operations. For defined flags only numeric values that are 2^x (power of two, where 0<=x<32) are allowed. The value of (0) is reserved. The following capabilities are defined in this document: BASE_SESSION_GROUP_CAPABILITY (0x00000001) This flag indicates the capability to support session grouping and session group operations according to this specification. 8. Result-Code AVP Values This document does not define new Result-Code [RFC6733] values for existing applications, which are extended to support group commands. Specification documents of new applications, which will have intrinsic support for group commands, may specify new Result-Codes. Jones, et al. Expires February 4, 2023 [Page 18] Internet-Draft Diameter Group Signaling August 2022 9. IANA Considerations This section contains the namespaces that have either been created in this specification or had their values assigned to existing namespaces managed by IANA. 9.1. AVP Codes This specification requires IANA to register the following new AVPs from the AVP Code namespace defined in [RFC6733]. o Session-Group-Info o Session-Group-Control-Vector o Session-Group-Id o Group-Response-Action o Session-Group-Capability-Vector The AVPs are defined in Section 7. 9.2. New Registries This specification requires IANA to create two registries: o Session-Group-Control-Vector AVP registry for control bits with two initial assignments, which are described in Section 7.2. The future registration assignment policy is proposed to be Specification Required. o Session-Group-Capability-Vector AVP with one initial assignment, which is described in Section 7.5. The future registration assignment policy is proposed to be Standards Action. The AVP names can be used as registry names. 10. Security Considerations The security considerations of the Diameter protocol itself are discussed in [RFC6733]. Use of the AVPs defined in this document MUST take into consideration the security issues and requirements of the Diameter base protocol. In particular, the Session-Group-Info AVP (including the Session-Group-Control-Vector and the Session- Group-Id AVPs) should be considered as a security-sensitive AVPs in the same manner than the Session-Id AVP in the Diameter base protocol [RFC6733]. Jones, et al. Expires February 4, 2023 [Page 19] Internet-Draft Diameter Group Signaling August 2022 The management of session groups relies upon the existing trust relationship between the Diameter client and the Diameter server managing the groups of sessions. This document defines a mechanism that allows a client or a server to act on multiple sessions at the same time using only one command. If the Diameter client or server is compromised, an attacker could launch DoS attacks by terminating or applying change operations to a large number of sessions with a limited set of commands using the session group management concept. According to the Diameter base protocol [RFC6733], transport connections between Diameter peers are protected by TLS/TCP, DTLS/ SCTP or alternative security mechanisms that are independent of Diameter, such as IPsec. However, the lack of end-to-end security features makes it difficult to establish trust in the session group related information received from non-adjacent nodes. Any Diameter agent in the message path can potentially modify the content of the message and therefore the information sent by the Diameter client or the server. There is ongoing work on the specification of end-to-end security features for Diameter. Such features would enable the establishment of trust relationship between non-adjacent nodes and the security required for session group management would normally rely on this end-to-end security. However, there is no assumption in this document that such end-to-end security mechanism will be available. It is only assumed that the solution defined on this document relies on the security framework provided by the Diameter based protocol. In some cases, a Diameter Proxy agent can act on behalf of a client or server. In such a case, the security requirements that normally apply to a client (or a server) apply equally to the Proxy agent. 11. Acknowledgments The authors of this document want to thank Ben Campbell and Eric McMurry for their valuable comments to early versions of this draft. Furthermore, authors thank Steve Donovan and Mark Bales for the thorough review and comments on advanced versions of the WG document, which helped a lot to improve this specification. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Jones, et al. Expires February 4, 2023 [Page 20] Internet-Draft Diameter Group Signaling August 2022 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, . [RFC7155] Zorn, G., Ed., "Diameter Network Access Server Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, . Appendix A. Session Management -- Exemplary Session State Machine A.1. Use of groups for the Authorization Session State Machine Section 8.1 in [RFC6733] defines a set of finite state machines, representing the life cycle of Diameter sessions, and which must be observed by all Diameter implementations that make use of the authentication and/or authorization portion of a Diameter application. This section defines, as example, additional state transitions related to the processing of the group commands which may impact multiple sessions. The group membership is session state and therefore only those state machines from [RFC6733] in which the server is maintaining session state are relevant in this document. As in [RFC6733], the term Service-Specific below refers to a message defined in a Diameter application (e.g., Mobile IPv4, NASREQ). The following state machine is observed by a client when state is maintained on the server. State transitions which are unmodified from [RFC6733] are not repeated here. The Diameter group command in the following tables is differentiated from a single-session related command by a preceding 'G' (Group). A Group Re-Auth Request, which applies to one or multiple session groups, has been exemplarily described in Section 6.1. Such Group RAR command is denoted as 'GRAR' in the following table. The same notation applies to other commands as per [RFC6733]. CLIENT, STATEFUL State Event Action New State --------------------------------------------------------------- Idle Client or Device Requests Send Pending access service specific Jones, et al. Expires February 4, 2023 [Page 21] Internet-Draft Diameter Group Signaling August 2022 auth req optionally including groups Open GASR received with Send GASA Discon Group-Response-Action with = ALL_GROUPS, Result-Code session is assigned to = SUCCESS, received group(s) and Send GSTR. client will comply with request to end the session Open GASR received with Send GASA Discon Group-Response-Action with = PER_GROUPS, Result-Code session is assigned to = SUCCESS, received group(s) and Send GSTR client will comply with per group request to end the session Open GASR received with Send GASA Discon Group-Response-Action with = PER_SESSION, Result-Code session is assigned to = SUCCESS, received group(s) and Send STR client will comply with per session request to end the session Open GASR received, Send GASA Open client will not comply with with request to end all session Result-Code in received group(s) != SUCCESS Discon GSTA Received Discon. Idle user/device Open GRAR received with Send GRAA, Pending Group-Response-Action Send = ALL_GROUPS, service session is assigned to specific received group(s) and group client will perform re-auth req subsequent re-auth Open GRAR received with Send GRAA, Pending Group-Response-Action Send = PER_GROUP, service session is assigned to specific Jones, et al. Expires February 4, 2023 [Page 22] Internet-Draft Diameter Group Signaling August 2022 received group(s) and group client will perform re-auth req subsequent re-auth per group Open GRAR received with Send GRAA, Pending Group-Response-Action Send = PER_SESSION, service session is assigned to specific received group(s) and re-auth req client will perform per session subsequent re-auth Open GRAR received and client will Send GRAA Idle not perform subsequent with re-auth Result-Code != SUCCESS, Discon. user/device Pending Successful service-specific Provide Open group re-authorization answer service received. Pending Failed service-specific Discon. Idle group re-authorization answer user/device received. The following state machine is observed by a server when it is maintaining state for the session. State transitions which are unmodified from [RFC6733] are not repeated here. Jones, et al. Expires February 4, 2023 [Page 23] Internet-Draft Diameter Group Signaling August 2022 SERVER, STATEFUL State Event Action New State --------------------------------------------------------------- Idle Service-specific authorization Send Open request received, and user successful is authorized service specific answer optionally including groups Open Server wants to terminate Send GASR Discon group(s) Discon GASA received Cleanup Idle Any GSTR received Send GSTA, Idle Cleanup Open Server wants to reauth Send GRAR Pending group(s) Pending GRAA received with Result-Code Update Open = SUCCESS session(s) Pending GRAA received with Result-Code Cleanup Idle != SUCCESS session(s) Open Service-specific group Send Open re-authoization request successful received and user is service authorized specific group re-auth answer Open Service-specific group Send Idle re-authorization request failed received and user is service not authorized specific group re-auth answer, cleanup Jones, et al. Expires February 4, 2023 [Page 24] Internet-Draft Diameter Group Signaling August 2022 Authors' Addresses Mark Jones Individual Email: mark@azu.ca Marco Liebsch NEC Laboratories Europe GmbH Kurfuersten-Anlage 36 D-69115 Heidelberg Germany Email: marco.liebsch@neclab.eu Lionel Morand Orange Labs 38/40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France Email: lionel.morand@orange.com Jones, et al. Expires February 4, 2023 [Page 25] ./draft-ietf-pim-igmp-mld-proxy-yang-10.txt0000644000764400076440000011263114355702016020260 0ustar iustiniustinPIM Working Group H. Zhao Internet Draft Ericsson Intended status: Standards Track X. Liu Expires: July 04, 2023 IBM Corporation Y. Liu China Mobile M. Panchanathan Cisco Systems M. Sivakumar Juniper January 05, 2023 A YANG Data Model for IGMP/MLD Proxy draft-ietf-pim-igmp-mld-proxy-yang-10 Abstract This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) proxy devices. The YANG module in this document conforms to Network Management Datastore Architecture (NMDA). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt Zhao & Liu, etc Expires July 04, 2023 [Page 1] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 04, 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction...................................................3 1.1. Terminology...............................................3 1.2. Tree Diagrams.............................................3 1.3. Prefixes in Data Node Names...............................3 2. Design of Data Model...........................................4 2.1. Overview..................................................4 2.2. Optional Features.........................................4 2.3. Position of Address Family in Hierarchy...................4 3. Module Structure...............................................5 3.1. IGMP Proxy Configuration and Operational State............5 3.2. MLD Proxy Configuration and Operational State.............6 4. IGMP/MLD Proxy YANG Module.....................................7 5. Security Considerations.......................................14 6. IANA Considerations...........................................16 6.1. XML Registry.............................................16 6.2. YANG Module Names Registry...............................16 7. References....................................................16 7.1. Normative References.....................................16 7.2. Informative References...................................18 Appendix. Data Tree Example......................................19 Authors' Addresses...............................................22 Zhao & Liu, etc Expires July 04, 2023 [Page 2] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 1. Introduction This document defines a YANG [RFC7950] data model for the management of Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) Proxy [RFC4605] devices. The YANG module in this document conforms to the Network Management Datastore Architecture defined in [RFC8342]. 1.1. Terminology The terminology for describing YANG data models is found in [RFC6020] and [RFC7950], including: * augment * data model * data node * identity * module The following abbreviations are used in this document and defined model: IGMP: Internet Group Management Protocol [RFC3376]. MLD: Multicast Listener Discovery [RFC3810]. PIM: Protocol Independent Multicast [RFC7761]. 1.2. Tree Diagrams Tree diagrams used in this document follow the notation defined in [RFC8340]. 1.3. Prefixes in Data Node Names In this document, names of data nodes, and other data model objects are often used without a prefix, as long as it is clear from the context in which YANG module each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1. +----------+-----------------------+---------------------------------+ | Prefix | YANG module | Reference | +==========+=======================+=================================+ Zhao & Liu, etc Expires July 04, 2023 [Page 3] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 | inet | ietf-inet-types | [RFC6991] | +----------+-----------------------+---------------------------------+ | if | ietf-interfaces | [RFC8343] | +----------+-----------------------+---------------------------------+ | rt | ietf-routing | [RFC8349] | +----------+-----------------------+---------------------------------+ | rt-types | ietf-routing-types | [RFC8294] | +----------+-----------------------+---------------------------------+ | pim-base | ietf-pim-base | [RFC9128] | +----------+-----------------------+---------------------------------+ Table 1: Prefixes and Corresponding YANG Modules 2. Design of Data Model The model covers Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD) - Based Multicast Forwarding ("IGMP/MLD Proxying") [RFC4605]. The goal of this document is to define a data model that provides a common user interface to IGMP/MLD Proxy. 2.1. Overview The model defined in this document has all the common building blocks for the IGMP/MLD Proxy devices. It can be used to configure IGMP/MLD Proxy. The operational state data and statistics can also be retrieved by it. 2.2. Optional Features This model is designed to represent the basic capability subsets of IGMP / MLD Proxy. The main design goals of this document are that the basic capabilities described in the model are supported by any major now- existing implementation, and that the configuration of all implementations meeting the specifications is easy to express through some combination of the optional features in the model and simple vendor augmentations. This model declares two features representing capabilities that not all deployed devices support. One feature is igmp-proxy, and the other feature is mld-proxy. Either or both features could be implemented, which could provide more choices for vendors. 2.3. Position of Address Family in Hierarchy IGMP Proxy only supports IPv4, while MLD Proxy only supports IPv6. The data model defined in this document can be used for both IPv4 and IPv6 address families. Zhao & Liu, etc Expires July 04, 2023 [Page 4] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 This document defines IGMP Proxy and MLD Proxy as separate schema branches in the structure. The benefits are: * The model can support IGMP Proxy (IPv4), MLD Proxy (IPv6), or both optionally and independently. Such flexibility cannot be achieved cleanly with a combined branch. * The structure is consistent with other YANG data models such as [RFC8652], which uses separate branches for IPv4 and IPv6. * Having separate branches for IGMP Proxy and MLD Proxy allows minor differences in their behavior to be modelled more simply and cleanly. The two branches can better support different features and node types. 3. Module Structure This model augments the core routing data model specified in [RFC8349]. +--rw routing +--rw router-id? +--rw control-plane-protocols | +--rw control-plane-protocol* [type name] | +--rw type | +--rw name | +--rw igmp-proxy <= Augmented by this Model ... | +--rw mld-proxy <= Augmented by this Model The "igmp-proxy" container instantiates IGMP Proxy. The "mld-proxy" container instantiates MLD Proxy. 3.1. IGMP Proxy Configuration and Operational State The YANG module augments /rt:routing/rt:control-plane- protocols/rt:control-plane-protocol to add the igmp-proxy container. All the IGMP Proxy related attributes are defined in the igmp-proxy container. The read-write attributes represent configurable data. The read-only attributes represent state data. The igmp-version represents the version of IGMP protocol, and the default value is 2. If the value of enabled is true, it means IGMP Proxy is enabled. The interface list under igmp-proxy contains upstream interfaces for IGMP proxy. There is also a constraint to make sure the upstream interface for IGMP proxy is not configured to use PIM. To configure a downstream interface for IGMP proxy, it is needed to enable IGMP on that interface. This is defined in the YANG Data Model Zhao & Liu, etc Expires July 04, 2023 [Page 5] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) [RFC8652]. augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw igmp-proxy! {igmp-proxy}? +--rw interfaces +--rw interface* [name] +--rw name if:interface-ref +--rw igmp-version? uint8 +--rw enabled? boolean +--rw sender-source-address? inet:ipv4-address-no-zone +--ro group* [group-address] +--ro group-address | rt-types:ipv4-multicast-group-address +--ro up-time? uint32 +--ro filter-mode enumeration +--ro source* [source-address] +--ro source-address | inet:ipv4-address-no-zone +--ro up-time? uint32 +--ro downstream-interface* [name] +--ro name if:interface-ref 3.2. MLD Proxy Configuration and Operational State The YANG module augments /rt:routing/rt:control-plane- protocols/rt:control-plane-protocol to add the mld-proxy container. All the MLD Proxy related attributes are defined in the mld-proxy container. The read-write attributes represent configurable data. The read-only attributes represent state data. The mld-version represents the version of MLD protocol, and default value is 2. If the value of enabled is true, it means MLD Proxy is enabled. The interface list under mld-proxy contains upstream interfaces for MLD proxy. There is also a constraint to make sure the upstream interface for MLD proxy is not configured to use PIM. To configure a downstream interface for MLD proxy, enable MLD on that interface. This is defined in the YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) [RFC8652]. augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw mld-proxy! {mld-proxy}? +--rw interfaces +--rw interface* [name] Zhao & Liu, etc Expires July 04, 2023 [Page 6] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 +--rw name if:interface-ref +--rw mld-version? uint8 +--rw enabled? boolean +--rw sender-source-address? inet:ipv6-address-no-zone +--ro group* [group-address] +--ro group-address | rt-types:ipv6-multicast-group-address +--ro up-time? uint32 +--ro filter-mode enumeration +--ro source* [source-address] +--ro source-address | inet:ipv6-address-no-zone +--ro up-time? uint32 +--ro downstream-interface* [name] +--ro name if:interface-ref 4. IGMP/MLD Proxy YANG Module This module references [RFC4605], [RFC6991], [RFC8294], [RFC8343], [RFC8349] and [RFC9128]. file ietf-igmp-mld-proxy@2022-12-07.yang module ietf-igmp-mld-proxy { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy"; // replace with IANA namespace when assigned prefix igmp-mld-proxy; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; } import ietf-interfaces { prefix if; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-routing { prefix rt; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; } import ietf-routing-types { prefix rt-types; reference "RFC 8294: Common YANG Data Types for the Routing Area"; } import ietf-pim-base { prefix pim-base; Zhao & Liu, etc Expires July 04, 2023 [Page 7] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 reference "RFC 9128: A YANG Data Model for Protocol Independent Multicast (PIM)"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: Editors: Hongji Zhao Xufeng Liu Yisong Liu Mani Panchanathan Mahesh Sivakumar "; description "The module defines a collection of YANG definitions common for all Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy devices. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2022-12-07 { description "Initial revision."; reference Zhao & Liu, etc Expires July 04, 2023 [Page 8] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 "RFC XXXX: A YANG Data Model for IGMP and MLD Proxy"; } /* * Features */ feature igmp-proxy { description "Support IGMP Proxy protocol."; reference "RFC 4605"; } feature mld-proxy { description "Support MLD Proxy protocol."; reference "RFC 4605"; } /* * Identities */ identity igmp-proxy { base rt:control-plane-protocol; description "IGMP Proxy protocol"; } identity mld-proxy { base rt:control-plane-protocol; description "MLD Proxy protocol"; } /* * Groupings */ grouping per-interface-config-attributes { description "Config attributes under interface view"; leaf enabled { type boolean; default true; description "Set the value to true to enable IGMP/MLD proxy"; } } // per-interface-config-attributes Zhao & Liu, etc Expires July 04, 2023 [Page 9] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 grouping state-group-attributes { description "State group attributes"; leaf up-time { type uint32; units seconds; description "The elapsed time for (S,G) or (*,G)."; } leaf filter-mode { type enumeration { enum "include" { description "In include mode, reception of packets sent to the specified multicast address is requested only from those IP source addresses listed in the source-list parameter"; } enum "exclude" { description "In exclude mode, reception of packets sent to the given multicast address is requested from all IP source addresses except those listed in the source-list parameter."; } } mandatory true; description "Filter mode for a multicast group, may be either include or exclude."; } } // state-group-attributes /* augments */ augment "/rt:routing/rt:control-plane-protocols"+ "/rt:control-plane-protocol" { when "derived-from-or-self(rt:type, 'igmp-mld-proxy:igmp-proxy')" { description "This augmentation is only valid for IGMP Proxy."; } description "IGMP Proxy augmentation to routing control plane protocol configuration and state."; container igmp-proxy { if-feature "igmp-proxy"; presence "IGMP Proxy configuration."; description "IGMP Proxy instance configuration."; container interfaces { Zhao & Liu, etc Expires July 04, 2023 [Page 10] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 description "Containing a list of upstream interfaces."; list interface { key "name"; description "List of upstream interfaces."; leaf name { type if:interface-ref; must "not( current() = /rt:routing"+ "/rt:control-plane-protocols/pim-base:pim"+ "/pim-base:interfaces/pim-base:interface"+ "/pim-base:name )" { description "The upstream interface for IGMP proxy must not be configured to use PIM."; } description "The upstream interface name."; } leaf igmp-version { type uint8 { range "1..3"; } default 2; description "IGMP version."; } uses per-interface-config-attributes; leaf sender-source-address { type inet:ipv4-address-no-zone; description "The sender source address of IGMP membership report message or leave message."; } list group { key "group-address"; config false; description "Multicast group membership information that joined on the interface."; leaf group-address { type rt-types:ipv4-multicast-group-address; description "Multicast group address."; } uses state-group-attributes; list source { key "source-address"; description "List of multicast source information of the multicast group."; leaf source-address { type inet:ipv4-address-no-zone; Zhao & Liu, etc Expires July 04, 2023 [Page 11] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 description "Multicast source address"; } leaf up-time { type uint32; units seconds; description "The elapsed time for (S,G) or (*,G)."; } list downstream-interface { key "name"; description "The downstream interfaces list."; leaf name { type if:interface-ref; description "Downstream interfaces for each upstream-interface"; } } } // list source } // list group } // interface } // interfaces } } augment "/rt:routing/rt:control-plane-protocols"+ "/rt:control-plane-protocol" { when "derived-from-or-self(rt:type, 'igmp-mld-proxy:mld-proxy')" { description "This augmentation is only valid for MLD Proxy."; } description "MLD Proxy augmentation to routing control plane protocol configuration and state."; container mld-proxy { if-feature "mld-proxy"; presence "MLD Proxy configuration."; description "MLD Proxy instance configuration."; container interfaces { description "Containing a list of upstream interfaces."; list interface { key "name"; description "List of upstream interfaces."; leaf name { type if:interface-ref; must "not( current() = /rt:routing"+ "/rt:control-plane-protocols/pim-base:pim"+ Zhao & Liu, etc Expires July 04, 2023 [Page 12] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 "/pim-base:interfaces/pim-base:interface"+ "/pim-base:name )" { description "The upstream interface for MLD proxy must not be configured to use PIM."; } description "The upstream interface name."; } leaf mld-version { type uint8 { range "1..2"; } default 2; description "MLD version."; } uses per-interface-config-attributes; leaf sender-source-address { type inet:ipv6-address-no-zone; description "The sender source address of MLD membership report message or leave message."; } list group { key "group-address"; config false; description "Multicast group membership information that joined on the interface."; leaf group-address { type rt-types:ipv6-multicast-group-address; description "Multicast group address."; } uses state-group-attributes; list source { key "source-address"; description "List of multicast source information of the multicast group."; leaf source-address { type inet:ipv6-address-no-zone; description "Multicast source address"; } leaf up-time { type uint32; units seconds; description "The elapsed time for (S,G) or (*,G)."; } list downstream-interface { Zhao & Liu, etc Expires July 04, 2023 [Page 13] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 key "name"; description "The downstream interfaces list."; leaf name { type if:interface-ref; description "Downstream interfaces for each upstream-interface"; } } } // list source } // list group } // interface } // interfaces } } } 5. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ igmp-mld-proxy:igmp-proxy, igmp-mld-proxy:interfaces This subtree specifies the interface list for IGMP Proxy. Modifying the configuration may cause IGMP Proxy interface to be deleted or changed. Zhao & Liu, etc Expires July 04, 2023 [Page 14] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 igmp-mld-proxy:interfaces/interface This subtree specifies the configuration for the IGMP Proxy attributes at the interface level. Modifying the configuration may cause IGMP Proxy to be deleted or changed on a specific interface. Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ igmp-mld-proxy:mld-proxy, igmp-mld-proxy:interfaces This subtree specifies the interface list for MLD Proxy. Modifying the configuration may cause MLD Proxy interface to be deleted or changed. igmp-mld-proxy:interfaces/interface This subtree specifies the configuration for the MLD Proxy attributes at the interface level. Modifying the configuration may cause MLD Proxy to be deleted or changed on a specific interface. Unauthorized access to any data node of these subtrees can adversely affect the IGMP / MLD Proxy subsystem of both the local device and the network. This may lead to network malfunctions, delivery of packets to inappropriate destinations, and other problems. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ igmp-mld-proxy:igmp-proxy igmp-mld-proxy:mld-proxy Unauthorized access to any data node of these subtrees can disclose the operational state information of IGMP / MLD Proxy on this device. The group/source information may expose multicast group memberships. Zhao & Liu, etc Expires July 04, 2023 [Page 15] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 6. IANA Considerations RFC Ed.: In this section, replace all occurrences of 'XXXX' with the actual RFC number (and remove this note). 6.1. XML Registry This document registers the following namespace URIs in the IETF XML registry [RFC3688]: -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- 6.2. YANG Module Names Registry This document registers the following YANG modules in the YANG Module Names registry [RFC7950]: -------------------------------------------------------------------- name: ietf-igmp-mld-proxy namespace: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy prefix: igmp-mld-proxy reference: RFC XXXX -------------------------------------------------------------------- 7. References 7.1. Normative References [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4605] B. Fenner, H. He, B. Haberman and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD) - Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. Zhao & Liu, etc Expires July 04, 2023 [Page 16] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6241] R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, June 2011. [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, July 2013. [RFC7950] M. Bjorklund, Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, August 2016. [RFC8040] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol", RFC 8040, January 2017. [RFC8294] X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, December 2017. [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", RFC 8341, March 2018. [RFC8342] M. Bjorklund and J. Schoenwaelder, "Network Management Datastore Architecture (NMDA)", RFC 8342, March 2018. [RFC8343] M. Bjorklund, "A YANG Data Model for Interface Management", RFC 8343, March 2018. [RFC8349] L. Lhotka, A. Lindem, Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, March 2018. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018. [RFC8652] X. Liu, F. Guo, M. Sivakumar, P. McAllister, A. Peter, "A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD)", RFC 8652, November 2019. [RFC9128] X. Liu, P. McAllister, A. Peter, M. Sivakumar, Y. Liu, F. Hu, "A YANG Data Model for Protocol Independent Multicast (PIM)", RFC 9128, May 2018. Zhao & Liu, etc Expires July 04, 2023 [Page 17] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 7.2. Informative References [RFC7761] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, R. Parekh, Z. Zhang, L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 7761, March 2016. [RFC7951] L. Lhotka, "JSON Encoding of Data Modeled with YANG", RFC 7951, August 2016. [RFC8340] M. Bjorklund, and L. Berger, Ed., "YANG Tree Diagrams", RFC 8340, March 2018. [RFC8407] A. Bierman, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", RFC 8407, October 2018. Zhao & Liu, etc Expires July 04, 2023 [Page 18] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 Appendix. Data Tree Example This section contains an example for IGMP Proxy in the JSON encoding [RFC7951], containing both configuration and state data. In the example IGMP Proxy is enabled on interface eth1/1. It is also needed to enable IGMP on eth1/2 and eth1/3. The configuration details are omitted here because this document is focused on IGMP/MLD Proxy. +-----------+ + Source + +-----+-----+ | -----------------+---------------------------- |eth1/1 +---+----+ + R1 + +-+----+-+ eth1/2 | \ eth1/3 | \ | \ | \ ---------------+---------+------------------- | \ | \ +--------+--+ +---+--------+ + Receiver1 + + Receiver2 + +-----------+ +------------+ The configuration data for R1 in the above figure could be as follows: { "ietf-interfaces:interfaces": { "interface": [ { "name": "eth1/1", "type": "iana-if-type:ipForward", "ietf-ip:ipv4": { "address": [ { "ip": "203.0.113.1", "prefix-length": 24 } ] } } ] }, Zhao & Liu, etc Expires July 04, 2023 [Page 19] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 "ietf-routing:routing": { "control-plane-protocols": { "control-plane-protocol": [ { "type": "ietf-igmp-mld-proxy:igmp-proxy", "name": "proxy1", "ietf-igmp-mld-proxy:igmp-proxy": { "interfaces": { "interface": [ { "name": "eth1/1", "igmp-version": 3, "enabled": true } ] } } } ] } } } The corresponding operational state data for R1 could be as follows: { "ietf-interfaces:interfaces": { "interface": [ { "name": "eth1/1", "type": "iana-if-type:ipForward", "admin-status": "up", "oper-status": "up", "if-index": 25678136, "statistics": { "discontinuity-time": "2021-05-23T10:34:56-06:00" }, "ietf-ip:ipv4": { "address": [ { "ip": "203.0.113.1", "prefix-length": 24 } ] } } ] }, "ietf-routing:routing": { "control-plane-protocols": { Zhao & Liu, etc Expires July 04, 2023 [Page 20] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 "control-plane-protocol": [ { "type": "ietf-igmp-mld-proxy:igmp-proxy", "name": "proxy1", "ietf-igmp-mld-proxy:igmp-proxy": { "interfaces": { "interface": [ { "name": "eth1/1", "igmp-version": 3, "enabled": true, "group": [ { "group-address": "233.252.0.23", "filter-mode": "include", "source": [ { "source-address": "192.0.2.1", "downstream-interface": [ { "name": "eth1/2" }, { "name": "eth1/3" } ] } ] } ] } ] } } } ] } } } Zhao & Liu, etc Expires July 04, 2023 [Page 21] Internet-Draft IGMP/MLD Proxy YANG Module January 05, 2023 Authors' Addresses Hongji Zhao Ericsson (China) Communications Company Ltd. Ericsson Tower, No. 5 Lize East Street, ChaoYANG District Beijing 100102, China Email: hongji.zhao@ericsson.com Xufeng Liu IBM Corporation 2300 Dulles Station Blvd. Herndon, VA 20171 United States of America EMail: Xufeng.liu.ietf@gmail.com Yisong Liu China Mobile China Email: liuyisong@chinamobile.com Mani Panchanathan Cisco Systems India Email: mapancha@cisco.com Mahesh Sivakumar Juniper Networks 1133 Innovation Way Sunnyvale, California USA EMail: sivakumar.mahesh@gmail.com Zhao & Liu, etc Expires July 04, 2023 [Page 22] ./draft-ietf-dnsop-dnssec-bcp-06.txt0000644000764400076440000006106214325526275017034 0ustar iustiniustin Network Working Group P. Hoffman Internet-Draft ICANN Intended status: Best Current Practice 24 October 2022 Expires: 27 April 2023 DNS Security Extensions (DNSSEC) draft-ietf-dnsop-dnssec-bcp-06 Abstract This document describes the DNS security extensions (commonly called "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. This document is currently maintained at https://github.com/paulehoffman/draft-hoffman-dnssec. Issues and pull requests are welcomed. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Hoffman Expires 27 April 2023 [Page 1] Internet-Draft DNSSEC October 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. DNSSEC as a Best Current Practice . . . . . . . . . . . . 3 1.2. Implementing DNSSEC . . . . . . . . . . . . . . . . . . . 3 2. DNSSEC Core Documents . . . . . . . . . . . . . . . . . . . . 3 2.1. Addition to the DNSSEC Core . . . . . . . . . . . . . . . 4 3. Additional Cryptographic Algorithms and DNSSEC . . . . . . . 4 4. Extensions to DNSSEC . . . . . . . . . . . . . . . . . . . . 5 5. Additional Documents of Interest . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The core specification for what we know as DNSSEC (the combination of [RFC4033], [RFC4034], and [RFC4035]) describes a set of protocols that provide origin authentication of DNS data. [RFC6840] updates and extends those core RFCs, but does not fundamentally change the way that DNSSEC works. This document lists RFCs that should be considered by someone creating an implementation of, or someone deploying, DNSSEC as it is currently standardized. Although an effort was made to be thorough, the reader should not assume this list is comprehensive. It uses terminology from those documents without defining that terminology. It also points to the relevant IANA registry groups that relate to DNSSEC. It does not, however, point to standards that rely on zones needing to be signed by DNSSEC such as DANE [RFC6698]. Hoffman Expires 27 April 2023 [Page 2] Internet-Draft DNSSEC October 2022 1.1. DNSSEC as a Best Current Practice Using the DNSSEC set of protocols is the best current practice for adding origin authentication of DNS data. To date, no standards- track RFCs offer any other method for such origin authentication of data in the DNS. More than 15 years after the DNSSEC specification was published, it is still not widely deployed. Recent estimates are that fewer than 10% of the domain names used for web sites are signed, and only around a third of queries to recursive resolvers are validated. However, this low level of deployment does not affect whether using DNSSEC is a best current practice; it just indicates that the value of deploying DNSSEC is often considered lower than the cost. Nonetheless, the significant deployment of DNSSEC beneath some top- level domains (TLDs), and the near-universal deployment of DNSSEC for the TLDs in the DNS root zone, demonstrate that DNSSEC is applicable for implementation by both ordinary and highly sophisticated domain owners. 1.2. Implementing DNSSEC Developers of validating resolvers and authoritative servers, as well as operators of validating resolvers and authoritative servers, need to know the parts of the DNSSEC protocol that would affect them. They should read the DNSSEC core documents, and probably at least be familiar with the extensions. Developers will probably need to be very familiar with the algorithm documents as well. As a side note, some of the DNSSEC-related RFCs have significant errata, so reading the RFCs should also include looking for the related errata. 2. DNSSEC Core Documents What we refer to as "DNSSEC" is the third iteration of the DNSSEC specification; [RFC2065] was the first, and [RFC2535] was the second. Earlier iterations have not been deployed on a significant scale. Throughout this document, "DNSSEC" means the protocol initially defined in [RFC4033], [RFC4034], and [RFC4035]. The three initial core documents generally cover different topics: * [RFC4033] is an overview of DNSSEC, including how it might change the resolution of DNS queries. * [RFC4034] specifies the DNS resource records used in DNSSEC. It obsoletes many RFCs for earlier versions of DNSSEC. Hoffman Expires 27 April 2023 [Page 3] Internet-Draft DNSSEC October 2022 * [RFC4035] covers the modifications to the DNS protocol incurred by DNSSEC. These include signing zones, serving signed zones, resolving in light of DNSSEC, and authenticating DNSSEC-signed data. At the time this set of core documents was published, someone could create a DNSSEC implementation of signing software, of an DNSSEC- aware authoritative server, and/or a DNSSEC-aware recursive resolver from the three core documents, plus a few older RFCs specifying the cryptography used. Those two older documents are: * [RFC2536] defines how to use the DSA signature algorithm (although it refers to other documents for the details). DSA was thinly implemented and can safely be ignored by DNSSEC implementations. * [RFC3110] defines how to use the RSA signature algorithm (although refers to other documents for the details). RSA is still among the most popular signing algorithm for DNSSEC. It is important to note that later RFCs update the core documents. As just one example, [RFC9077] changes how TTL values are calculated in DNSSEC processing. 2.1. Addition to the DNSSEC Core As with any major protocol, developers and operators discovered issues with the original core documents over the years. [RFC6840] is an omnibus update to the original core documents and thus itself has become a core document. In addition to covering new requirements from new DNSSEC RFCs, it describes many important security and interoperability issues that arose during the deployment of the initial specifications, particularly after the DNS root was signed in 2010. It also lists some errors in the examples of the core specifications. [RFC6840] brings a few additions into the core of DNSSEC. It makes NSEC3 [RFC5155] as much a part of DNSSEC as NSEC is. It also makes the SHA-2 hash function defined in [RFC4509] and [RFC5702] part of the core. 3. Additional Cryptographic Algorithms and DNSSEC Current cryptographic algorithms typically weaken over time as computing power improves and new cryptoanalysis emerges. Two new signing algorithms have been adopted by the DNSSEC community: ECDSA [RFC6605] and EdDSA [RFC8080]. ECDSA and EdDSA have become very popular signing algorithms in recent years. The GOST signing algorithm [I-D.ietf-dnsop-rfc5933-bis] was also adopted, but has seen Hoffman Expires 27 April 2023 [Page 4] Internet-Draft DNSSEC October 2022 very limited use, likely because it is a national algorithm specific to a very small number of countries. Implementation developers who want to know which algorithms to implement in DNSSEC software should refer to [RFC8624]. Note that this specification is only about what algorithms should and should not be included in implementations: it is not advice for which algorithms that zone operators should and should not sign with, nor which algorithms recursive resolver operators should or should not be used for validation. 4. Extensions to DNSSEC The DNSSEC community has extended the DNSSEC core and the cryptographic algorithms both in terms of describing good operational practices and in new protocols. Some of the RFCs that describe these extensions include: * [RFC5011] describes a method to help resolvers update their DNSSEC trust anchors in an automated fashion. This method was used in 2018 to update the DNS root trust anchor. * [RFC6781] is a compendium of operational practices that may not be obvious from reading just the core specifications. * [RFC7344] describes using the CDS and CDNSKEY resource records to help automate the maintenance of DS records in the parents of signed zones. * [RFC8078] extends [RFC7344] by showing how to do initial setup of trusted relationships between signed parent and child zones. * [RFC8198] describes how a validating resolver can emit fewer queries in signed zones that use NSEC and NSEC3 for negative caching. * [RFC9077] updates [RFC8198] with respect to the time-to-live (TTL) fields in signed records. 5. Additional Documents of Interest The documents listed above constitute the core of DNSSEC, the additional cryptographic algorithms, and the major extensions to DNSSEC. This section lists some additional documents that someone interested in implementing or operating DNSSEC might find of value. Hoffman Expires 27 April 2023 [Page 5] Internet-Draft DNSSEC October 2022 * [RFC4470] "describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by [RFC4034]. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone.". * [RFC6975] "specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support". * [RFC7129] "provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses". This background is particularly important for understanding NSEC and NSEC3 usage. * [RFC7583] "describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone". * [RFC7646] "defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains". * [RFC7958] "describes the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors". * [RFC8027] "describes problems that a Validating DNS resolver, stub-resolver, or application might run into within a non- compliant infrastructure". * [RFC8145] "specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust". * [RFC8499] is a list of terminology used when talking about the DNS; sections 10 and 11 cover DNSSEC. * [RFC8509] "specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries". * [RFC8901] "presents deployment models that accommodate this scenario [when each DNS provider independently signs zone data with their own keys] and describes these key-management requirements". Hoffman Expires 27 April 2023 [Page 6] Internet-Draft DNSSEC October 2022 * [RFC9276] "provides guidance on setting NSEC3 parameters based on recent operational deployment experience". There will certainly be other RFCs related to DNSSEC that are published after this one. 6. IANA Considerations IANA already has three registry groups that relate to DNSSEC: * DNSSEC algorithm numbers (https://www.iana.org/assignments/dns- sec-alg-numbers) * DNSSEC NSEC3 parameters (https://www.iana.org/assignments/dnssec- nsec3-parameters) * DNSSEC DS RRtype digest algorithms (https://www.iana.org/assignments/ds-rr-types) The rules for the DNSSEC algorithm registry were set in the core RFCs and updated by [RFC6014], [RFC6725], and [RFC9157]. This document does not update or create any registry groups or registries. 7. Security Considerations All of the security considerations from all of the RFCs referenced in this document apply here. 8. References 8.1. Normative References [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110, May 2001, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . Hoffman Expires 27 April 2023 [Page 7] Internet-Draft DNSSEC October 2022 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, DOI 10.17487/RFC4509, May 2006, . [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, . [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, DOI 10.17487/RFC5702, October 2009, . [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, DOI 10.17487/RFC6840, February 2013, . 8.2. Informative References [I-D.ietf-dnsop-rfc5933-bis] Belyavsky, D., Dolmatov, V., and B. Makarenko, "Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", Work in Progress, Internet- Draft, draft-ietf-dnsop-rfc5933-bis-12, 23 October 2022, . [RFC2065] Eastlake 3rd, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, DOI 10.17487/RFC2065, January 1997, . [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999, . [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, DOI 10.17487/RFC2536, March 1999, . Hoffman Expires 27 April 2023 [Page 8] Internet-Draft DNSSEC October 2022 [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, DOI 10.17487/RFC4470, April 2006, . [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, . [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014, November 2010, . [RFC6605] Hoffman, P. and W.C.A. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 10.17487/RFC6605, April 2012, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC6725] Rose, S., "DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates", RFC 6725, DOI 10.17487/RFC6725, August 2012, . [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, . [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, . [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, February 2014, . [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014, . Hoffman Expires 27 April 2023 [Page 9] Internet-Draft DNSSEC October 2022 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, "DNSSEC Key Rollover Timing Considerations", RFC 7583, DOI 10.17487/RFC7583, October 2015, . [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., and R. Weber, "Definition and Use of DNSSEC Negative Trust Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, . [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman, "DNSSEC Trust Anchor Publication for the Root Zone", RFC 7958, DOI 10.17487/RFC7958, August 2016, . [RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy, "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027, DOI 10.17487/RFC8027, November 2016, . [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/RFC8078, March 2017, . [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC", RFC 8080, DOI 10.17487/RFC8080, February 2017, . [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)", RFC 8145, DOI 10.17487/RFC8145, April 2017, . [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, July 2017, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . [RFC8509] Huston, G., Damas, J., and W. Kumari, "A Root Key Trust Anchor Sentinel for DNSSEC", RFC 8509, DOI 10.17487/RFC8509, December 2018, . Hoffman Expires 27 April 2023 [Page 10] Internet-Draft DNSSEC October 2022 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation Requirements and Usage Guidance for DNSSEC", RFC 8624, DOI 10.17487/RFC8624, June 2019, . [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. Blacka, "Multi-Signer DNSSEC Models", RFC 8901, DOI 10.17487/RFC8901, September 2020, . [RFC9077] van Dijk, P., "NSEC and NSEC3: TTLs and Aggressive Use", RFC 9077, DOI 10.17487/RFC9077, July 2021, . [RFC9157] Hoffman, P., "Revised IANA Considerations for DNSSEC", RFC 9157, DOI 10.17487/RFC9157, December 2021, . [RFC9276] Hardaker, W. and V. Dukhovni, "Guidance for NSEC3 Parameter Settings", BCP 236, RFC 9276, DOI 10.17487/RFC9276, August 2022, . Appendix A. Acknowledgements The DNS world owes a depth of gratitude to the authors and other contributors to the core DNSSEC documents, and to the notable DNSSEC extensions. In addition, the following people made significant contributions to early versions of this document: Ben Schwartz and Duane Wessels. Author's Address Paul Hoffman ICANN Email: paul.hoffman@icann.org Hoffman Expires 27 April 2023 [Page 11] ./draft-ietf-quic-v2-10.txt0000644000764400076440000010455414346663327015162 0ustar iustiniustin QUIC M. Duke Internet-Draft Google LLC Intended status: Standards Track 15 December 2022 Expires: 18 June 2023 QUIC Version 2 draft-ietf-quic-v2-10 Abstract This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC. Note that "version 2" is an informal name for this proposal that indicates it is the second standards-track QUIC version. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risk. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://quicwg.org/ quic-v2/draft-ietf-quic-v2.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf- quic-v2/. Discussion of this document takes place on the QUIC Working Group mailing list (mailto:quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Subscribe at https://www.ietf.org/mailman/listinfo/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/quic-v2. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Duke Expires 18 June 2023 [Page 1] Internet-Draft QUICv2 December 2022 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 18 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Differences with QUIC Version 1 . . . . . . . . . . . . . . . 4 3.1. Version Field . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Long Header Packet Types . . . . . . . . . . . . . . . . 4 3.3. Cryptography changes . . . . . . . . . . . . . . . . . . 5 3.3.1. Initial Salt . . . . . . . . . . . . . . . . . . . . 5 3.3.2. HKDF Labels . . . . . . . . . . . . . . . . . . . . . 5 3.3.3. Retry Integrity Tag . . . . . . . . . . . . . . . . . 5 4. Version Negotiation Considerations . . . . . . . . . . . . . 6 4.1. Compatible Negotiation Requirements . . . . . . . . . . . 6 5. TLS Resumption and NEW_TOKEN Tokens . . . . . . . . . . . . . 7 6. Ossification Considerations . . . . . . . . . . . . . . . . . 8 7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 10 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 10 A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 11 A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 13 A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.5. ChaCha20-Poly1305 Short Header Packet . . . . . . . . . . 14 Duke Expires 18 June 2023 [Page 2] Internet-Draft QUICv2 December 2022 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 16 Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 16 C.1. since draft-ietf-quic-v2-09 . . . . . . . . . . . . . . . 16 C.2. since draft-ietf-quic-v2-08 . . . . . . . . . . . . . . . 16 C.3. since draft-ietf-quic-v2-07 . . . . . . . . . . . . . . . 16 C.4. since draft-ietf-quic-v2-06 . . . . . . . . . . . . . . . 16 C.5. since draft-ietf-quic-v2-05 . . . . . . . . . . . . . . . 16 C.6. since draft-ietf-quic-v2-04 . . . . . . . . . . . . . . . 16 C.7. since draft-ietf-quic-v2-03 . . . . . . . . . . . . . . . 17 C.8. since draft-ietf-quic-v2-02 . . . . . . . . . . . . . . . 17 C.9. since draft-ietf-quic-v2-01 . . . . . . . . . . . . . . . 17 C.10. since draft-ietf-quic-v2-00 . . . . . . . . . . . . . . . 17 C.11. since draft-duke-quic-v2-02 . . . . . . . . . . . . . . . 17 C.12. since draft-duke-quic-v2-01 . . . . . . . . . . . . . . . 17 C.13. since draft-duke-quic-v2-00 . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction QUIC version 1[QUIC] has numerous extension points, including the version number that occupies the second through fifth bytes of every long header (see [QUIC-INVARIANTS]). If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being 0x00000001. In QUIC version 1, Initial packets are encrypted with the version- specific salt as described in Section 5.2 of [QUIC-TLS]. Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Client Hello or Server Hello messages. Again, there is the potential for middleboxes to ossify on the version 1 key derivation and packet formats. Finally, [QUIC-VN] provides two mechanisms for endpoints to negotiate the QUIC version to use. The "incompatible" version negotiation method can support switching from any QUIC version to any other version with full generality, at the cost of an additional round-trip at the start of the connection. "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically. Duke Expires 18 June 2023 [Page 3] Internet-Draft QUICv2 December 2022 QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms. The changes provide an example of the minimum set of changes necessary to specify a new QUIC version. However, note that the choice of the version number on the wire is randomly chosen instead of "2", and the two bits that identify each long header packet type are different from version 1; both of these properties are meant to combat ossification and are not strictly required of a new QUIC version. Any endpoint that supports two versions needs to implement version negotiation to protect against downgrade attacks. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Differences with QUIC Version 1 Except for a few differences, QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in [QUIC], [QUIC-TLS], and [QUIC-RECOVERY]. The remainder of this section lists the differences. 3.1. Version Field The Version field of long headers is 0x6b3343cf. This was generated by taking the first four bytes of the sha256sum of "QUICv2 version number". *RFC Editor's Note:* Please remove the sentence below prior to publication of a final version of this document. This version number will not change in subsequent versions of this draft, unless there is a behavior change that breaks compatibility. 3.2. Long Header Packet Types All version 2 long header packet types are different. The Type field values are: * Initial: 0b01 * 0-RTT: 0b10 Duke Expires 18 June 2023 [Page 4] Internet-Draft QUICv2 December 2022 * Handshake: 0b11 * Retry: 0b00 3.3. Cryptography changes The values below were chosen randomly. 3.3.1. Initial Salt The salt used to derive Initial keys in Section 5.2 of [QUIC-TLS] changes to: initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9 This is the first 20 bytes of the sha256sum of "QUICv2 salt". 3.3.2. HKDF Labels *RFC Editor's Note:* Please ensure that the strings in quotes are not split up in a line break in this section. The labels used in [QUIC-TLS] to derive packet protection keys (Section 5.1), header protection keys (Section 5.4), Retry Integrity Tag keys (Section 5.8), and key updates (Section 6.1) change from "quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku", to meet the guidance for new versions in Section 9.6 of that document. 3.3.3. Retry Integrity Tag The key and nonce used for the Retry Integrity Tag (Section 5.8 of [QUIC-TLS]) change to: secret = 0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9f key = 0x8fb4b01b56ac48e260fbcbcead7ccc92 nonce = 0xd86969bc2d7c6d9990efb04a The secret is the sha256sum of "QUICv2 retry secret". The key and nonce are derived from this secret with the labels "quicv2 key" and "quicv2 iv", respectively. Duke Expires 18 June 2023 [Page 5] Internet-Draft QUICv2 December 2022 4. Version Negotiation Considerations QUIC version 2 is not intended to deprecate version 1. Endpoints that support version 2 might continue support for version 1 to maximize compatibility with other endpoints. In particular, HTTP clients often use Alt-Svc [RFC7838] to discover QUIC support. As this mechanism does not currently distinguish between QUIC versions, HTTP servers SHOULD support multiple versions to reduce the probability of incompatibility and the cost associated with QUIC version negotiation or TCP fallback. For example, an origin advertising support for "h3" in Alt-Svc should support QUIC version 1 as it was the original QUIC version used by HTTP/3, and therefore some clients will only support that version. Any QUIC endpoint that supports QUIC version 2 MUST send, process, and validate the version_information transport parameter specified in [QUIC-VN] to prevent version downgrade attacks. Note that version 2 meets the [QUIC-VN] definition of a compatible version with version 1, and version 1 is compatible with version 2. Therefore, servers can use compatible negotiation to switch a connection between the two versions. Endpoints that support both versions SHOULD support compatible version negotiation to avoid a round trip. 4.1. Compatible Negotiation Requirements Compatible version negotiation between versions 1 and 2 follow the same requirements in either direction. This section uses the terms "original version" and "negotiated version" from [QUIC-VN]. If the server sends a Retry packet, it MUST use the original version. The client ignores Retry packets using other versions. The client MUST NOT use a different version in the subsequent Initial packet that contains the Retry token. The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched, to enforce client compliance. QUIC version 2 uses the same transport parameters to authenticate the Retry as QUIC version 1. After switching to a negotiated version after a Retry, the server MUST include the relevant transport parameters to validate that the server sent the Retry and the connection IDs used in the exchange, as described in Section 7.3 of [QUIC]. Duke Expires 18 June 2023 [Page 6] Internet-Draft QUICv2 December 2022 The server cannot send CRYPTO frames until it has processed the client's transport parameters. The server MUST send all CRYPTO frames using the negotiated version. The client learns the negotiated version by observing the first long header Version field that differs from the original version. If the client receives a CRYPTO frame from the server in the original version, that indicates that the negotiated version is equal to the original version. Before the server is able to process transport parameters from the client, it might need to respond to Initial packets from the client. For these packets, the server uses the original version. Once the client has learned the negotiated version, it SHOULD send subsequent Initial packets using that version. The server MUST NOT discard its original version Initial receive keys until it successfully processes a Handshake packet with the negotiated version. Both endpoints MUST send Handshake and 1-RTT packets using the negotiated version. An endpoint MUST drop packets using any other version. Endpoints have no need to generate the keying material that would allow them to decrypt or authenticate such packets. The client MUST NOT send 0-RTT packets using the negotiated version, even after processing a packet of that version from the server. Servers can accept 0-RTT and then process 0-RTT packets from the original version. 5. TLS Resumption and NEW_TOKEN Tokens TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version of the connection that provided them. Clients MUST NOT use a session ticket or token from a QUIC version 1 connection to initiate a QUIC version 2 connection, or vice versa. Servers MUST validate the originating version of any session ticket or token and not accept one issued from a different version. A rejected ticket results in falling back to a full TLS handshake, without 0-RTT. A rejected token results in the client address remaining unverified, which limits the amount of data the server can send. After compatible version negotiation, any resulting session ticket maps to the negotiated version rather than original one. Duke Expires 18 June 2023 [Page 7] Internet-Draft QUICv2 December 2022 6. Ossification Considerations QUIC version 2 provides protection against some forms of ossification. Devices that assume that all long headers will encode version 1, or that the version 1 Initial key derivation formula will remain version-invariant, will not correctly process version 2 packets. However, many middleboxes, such as firewalls, focus on the first packet in a connection, which will often remain in the version 1 format due to the considerations above. Clients interested in combating middlebox ossification can initiate a connection using version 2 if they are either reasonably certain the server supports it, or are willing to suffer a round-trip penalty if they are incorrect. In particular, a server that issues a session ticket for version 2 indicates an intent to maintain version 2 support while the ticket remains valid, even if support cannot be guaranteed. 7. Applicability This version of QUIC provides no change from QUIC version 1 relating to the capabilities available to applications. Therefore, all Application Layer Protocol Negotiation (ALPN) ([RFC7301]) codepoints specified to operate over QUIC version 1 can also operate over this version of QUIC. In particular, both the "h3" [HTTP/3] and "doq" [RFC9250] ALPNs can operate over QUIC version 2. Unless otherwise stated, all QUIC extensions defined to work with version 1 also work with version 2. 8. Security Considerations QUIC version 2 introduces no changes to the security or privacy properties of QUIC version 1. The mandatory version negotiation mechanism guards against downgrade attacks, but downgrades have no security implications, as the version properties are identical. Support for QUIC version 2 can help an observer to fingerprint both client and server devices. Duke Expires 18 June 2023 [Page 8] Internet-Draft QUICv2 December 2022 9. IANA Considerations This document requests that IANA add the following entry to the QUIC version registry maintained at . Value: 0x6b3343cf Status: permanent Specification: This Document Change Controller: IETF Contact: QUIC WG Value: 0x709a50c4 Status: provisional Specification: This Document Change Controller: IETF Contact: QUIC WG Note: QUIC v2 draft codepoint 10. References 10.1. Normative References [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [QUIC-RECOVERY] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, . [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . [QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version Negotiation for QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-version-negotiation-13, 6 November 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Duke Expires 18 June 2023 [Page 9] Internet-Draft QUICv2 December 2022 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, . [QUIC-INVARIANTS] Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, . [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, . Appendix A. Sample Packet Protection This section shows examples of packet protection so that implementations can be verified incrementally. Samples of Initial packets from both client and server plus a Retry packet are defined. These packets use an 8-byte client-chosen Destination Connection ID of 0x8394c8f03e515708. Some intermediate values are included. All values are shown in hexadecimal. A.1. Keys The labels generated during the execution of the HKDF-Expand-Label function (that is, HkdfLabel.label) and part of the value given to the HKDF-Expand function in order to produce its output are: client in: 00200f746c73313320636c69656e7420696e00 server in: 00200f746c7331332073657276657220696e00 quicv2 key: 001010746c73313320717569637632206b657900 Duke Expires 18 June 2023 [Page 10] Internet-Draft QUICv2 December 2022 quicv2 iv: 000c0f746c7331332071756963763220697600 quicv2 hp: 00100f746c7331332071756963763220687000 The initial secret is common: initial_secret = HKDF-Extract(initial_salt, cid) = 2062e8b3cd8d52092614b8071d0aa1fb 7c2e3ac193f78b280e72d8f5751f6aba The secrets for protecting client packets are: client_initial_secret = HKDF-Expand-Label(initial_secret, "client in", "", 32) = 14ec9d6eb9fd7af83bf5a668bc17a7e2 83766aade7ecd0891f70f9ff7f4bf47b key = HKDF-Expand-Label(client_initial_secret, "quicv2 key", "", 16) = 8b1a0bc121284290a29e0971b5cd045d iv = HKDF-Expand-Label(client_initial_secret, "quicv2 iv", "", 12) = 91f73e2351d8fa91660e909f hp = HKDF-Expand-Label(client_initial_secret, "quicv2 hp", "", 16) = 45b95e15235d6f45a6b19cbcb0294ba9 The secrets for protecting server packets are: server_initial_secret = HKDF-Expand-Label(initial_secret, "server in", "", 32) = 0263db1782731bf4588e7e4d93b74639 07cb8cd8200b5da55a8bd488eafc37c1 key = HKDF-Expand-Label(server_initial_secret, "quicv2 key", "", 16) = 82db637861d55e1d011f19ea71d5d2a7 iv = HKDF-Expand-Label(server_initial_secret, "quicv2 iv", "", 12) = dd13c276499c0249d3310652 hp = HKDF-Expand-Label(server_initial_secret, "quicv2 hp", "", 16) = edf6d05c83121201b436e16877593c3a A.2. Client Initial The client sends an Initial packet. The unprotected payload of this packet contains the following CRYPTO frame, plus enough PADDING frames to make a 1162-byte payload: Duke Expires 18 June 2023 [Page 11] Internet-Draft QUICv2 December 2022 060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868 04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578 616d706c652e636f6dff01000100000a 00080006001d00170018001000070005 04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400 0d0010000e0403050306030203080408 050806002d00020101001c0002400100 3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000 75300901100f088394c8f03e51570806 048000ffff The unprotected header indicates a length of 1182 bytes: the 4-byte packet number, 1162 bytes of frames, and the 16-byte authentication tag. The header includes the connection ID and a packet number of 2: d36b3343cf088394c8f03e5157080000449e00000002 Protecting the payload produces output that is sampled for header protection. Because the header uses a 4-byte packet number encoding, the first 16 bytes of the protected payload is sampled and then applied to the header as follows: sample = ffe67b6abcdb4298b485dd04de806071 mask = AES-ECB(hp, sample)[0..4] = 94a0c95e80 header[0] ^= mask[0] & 0x0f = d7 header[18..21] ^= mask[1..4] = a0c95e82 header = d76b3343cf088394c8f03e5157080000449ea0c95e82 The resulting protected packet is: Duke Expires 18 June 2023 [Page 12] Internet-Draft QUICv2 December 2022 d76b3343cf088394c8f03e5157080000 449ea0c95e82ffe67b6abcdb4298b485 dd04de806071bf03dceebfa162e75d6c 96058bdbfb127cdfcbf903388e99ad04 9f9a3dd4425ae4d0992cfff18ecf0fdb 5a842d09747052f17ac2053d21f57c5d 250f2c4f0e0202b70785b7946e992e58 a59ac52dea6774d4f03b55545243cf1a 12834e3f249a78d395e0d18f4d766004 f1a2674802a747eaa901c3f10cda5500 cb9122faa9f1df66c392079a1b40f0de 1c6054196a11cbea40afb6ef5253cd68 18f6625efce3b6def6ba7e4b37a40f77 32e093daa7d52190935b8da58976ff33 12ae50b187c1433c0f028edcc4c2838b 6a9bfc226ca4b4530e7a4ccee1bfa2a3 d396ae5a3fb512384b2fdd851f784a65 e03f2c4fbe11a53c7777c023462239dd 6f7521a3f6c7d5dd3ec9b3f233773d4b 46d23cc375eb198c63301c21801f6520 bcfb7966fc49b393f0061d974a2706df 8c4a9449f11d7f3d2dcbb90c6b877045 636e7c0c0fe4eb0f697545460c806910 d2c355f1d253bc9d2452aaa549e27a1f ac7cf4ed77f322e8fa894b6a83810a34 b361901751a6f5eb65a0326e07de7c12 16ccce2d0193f958bb3850a833f7ae43 2b65bc5a53975c155aa4bcb4f7b2c4e5 4df16efaf6ddea94e2c50b4cd1dfe060 17e0e9d02900cffe1935e0491d77ffb4 fdf85290fdd893d577b1131a610ef6a5 c32b2ee0293617a37cbb08b847741c3b 8017c25ca9052ca1079d8b78aebd4787 6d330a30f6a8c6d61dd1ab5589329de7 14d19d61370f8149748c72f132f0fc99 f34d766c6938597040d8f9e2bb522ff9 9c63a344d6a2ae8aa8e51b7b90a4a806 105fcbca31506c446151adfeceb51b91 abfe43960977c87471cf9ad4074d30e1 0d6a7f03c63bd5d4317f68ff325ba3bd 80bf4dc8b52a0ba031758022eb025cdd 770b44d6d6cf0670f4e990b22347a7db 848265e3e5eb72dfe8299ad7481a4083 22cac55786e52f633b2fb6b614eaed18 d703dd84045a274ae8bfa73379661388 d6991fe39b0d93debb41700b41f90a15 c4d526250235ddcd6776fc77bc97e7a4 17ebcb31600d01e57f32162a8560cacc 7e27a096d37a1a86952ec71bd89a3e9a 30a2a26162984d7740f81193e8238e61 f6b5b984d4d3dfa033c1bb7e4f0037fe bf406d91c0dccf32acf423cfa1e70710 10d3f270121b493ce85054ef58bada42 310138fe081adb04e2bd901f2f13458b 3d6758158197107c14ebb193230cd115 7380aa79cae1374a7c1e5bbcb80ee23e 06ebfde206bfb0fcbc0edc4ebec30966 1bdd908d532eb0c6adc38b7ca7331dce 8dfce39ab71e7c32d318d136b6100671 a1ae6a6600e3899f31f0eed19e3417d1 34b90c9058f8632c798d4490da498730 7cba922d61c39805d072b589bd52fdf1 e86215c2d54e6670e07383a27bbffb5a ddf47d66aa85a0c6f9f32e59d85a44dd 5d3b22dc2be80919b490437ae4f36a0a e55edf1d0b5cb4e9a3ecabee93dfc6e3 8d209d0fa6536d27a5d6fbb17641cde2 7525d61093f1b28072d111b2b4ae5f89 d5974ee12e5cf7d5da4d6a31123041f3 3e61407e76cffcdcfd7e19ba58cf4b53 6f4c4938ae79324dc402894b44faf8af bab35282ab659d13c93f70412e85cb19 9a37ddec600545473cfb5a05e08d0b20 9973b2172b4d21fb69745a262ccde96b a18b2faa745b6fe189cf772a9f84cbfc A.3. Server Initial The server sends the following payload in response, including an ACK frame, a CRYPTO frame, and no PADDING frames: 02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739 88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94 0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00 020304 Duke Expires 18 June 2023 [Page 13] Internet-Draft QUICv2 December 2022 The header from the server includes a new connection ID and a 2-byte packet number encoding for a packet number of 1: d16b3343cf0008f067a5502a4262b50040750001 As a result, after protection, the header protection sample is taken starting from the third protected byte: sample = 6f05d8a4398c47089698baeea26b91eb mask = 4dd92e91ea header = dc6b3343cf0008f067a5502a4262b5004075d92f The final protected packet is then: dc6b3343cf0008f067a5502a4262b500 4075d92faaf16f05d8a4398c47089698 baeea26b91eb761d9b89237bbf872630 17915358230035f7fd3945d88965cf17 f9af6e16886c61bfc703106fbaf3cb4c fa52382dd16a393e42757507698075b2 c984c707f0a0812d8cd5a6881eaf21ce da98f4bd23f6fe1a3e2c43edd9ce7ca8 4bed8521e2e140 A.4. Retry This shows a Retry packet that might be sent in response to the Initial packet in Appendix A.2. The integrity check includes the client-chosen connection ID value of 0x8394c8f03e515708, but that value is not included in the final Retry packet: cf6b3343cf0008f067a5502a4262b574 6f6b656ec8646ce8bfe33952d9555436 65dcc7b6 A.5. ChaCha20-Poly1305 Short Header Packet This example shows some of the steps required to protect a packet with a short header. This example uses AEAD_CHACHA20_POLY1305. In this example, TLS produces an application write secret from which a server uses HKDF-Expand-Label to produce four values: a key, an IV, a header protection key, and the secret that will be used after keys are updated (this last value is not used further in this example). Duke Expires 18 June 2023 [Page 14] Internet-Draft QUICv2 December 2022 secret = 9ac312a7f877468ebe69422748ad00a1 5443f18203a07d6060f688f30f21632b key = HKDF-Expand-Label(secret, "quicv2 key", "", 32) = 3bfcddd72bcf02541d7fa0dd1f5f9eee a817e09a6963a0e6c7df0f9a1bab90f2 iv = HKDF-Expand-Label(secret, "quicv2 iv", "", 12) = a6b5bc6ab7dafce30ffff5dd hp = HKDF-Expand-Label(secret, "quicv2 hp", "", 32) = d659760d2ba434a226fd37b35c69e2da 8211d10c4f12538787d65645d5d1b8e2 ku = HKDF-Expand-Label(secret, "quicv2 ku", "", 32) = c69374c49e3d2a9466fa689e49d476db 5d0dfbc87d32ceeaa6343fd0ae4c7d88 The following shows the steps involved in protecting a minimal packet with an empty Destination Connection ID. This packet contains a single PING frame (that is, a payload of just 0x01) and has a packet number of 654360564. In this example, using a packet number of length 3 (that is, 49140 is encoded) avoids having to pad the payload of the packet; PADDING frames would be needed if the packet number is encoded on fewer bytes. pn = 654360564 (decimal) nonce = a6b5bc6ab7dafce328ff4a29 unprotected header = 4200bff4 payload plaintext = 01 payload ciphertext = 0ae7b6b932bc27d786f4bc2bb20f2162ba The resulting ciphertext is the minimum size possible. One byte is skipped to produce the sample for header protection. sample = e7b6b932bc27d786f4bc2bb20f2162ba mask = 97580e32bf header = 5558b1c6 The protected packet is the smallest possible packet size of 21 bytes. packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba Duke Expires 18 June 2023 [Page 15] Internet-Draft QUICv2 December 2022 Appendix B. Acknowledgments The author would like to thank Christian Huitema, Lucas Pardue, Kyle Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro Tsujikawa, and Martin Thomson for their helpful suggestions. Appendix C. Changelog *RFC Editor's Note:* Please remove this section prior to publication of a final version of this document. C.1. since draft-ietf-quic-v2-09 * Added note for provisional IANA registration C.2. since draft-ietf-quic-v2-08 * Updated IANA considerations in accordance with new constants C.3. since draft-ietf-quic-v2-07 * Generated new constants and test vectors C.4. since draft-ietf-quic-v2-06 * Clients MUST NOT use TLS resumption tickets across versions * Servers SHOULD support multiple versions * Clients SHOULD check path support for QUIC independently by version * Minor editorial changes C.5. since draft-ietf-quic-v2-05 * Servers MUST use the negotiated version in Initials with CRYPTO frames. * Clarified when clients "learn" the negotiated version as required in the VN draft. * Comments from SECDIR review. C.6. since draft-ietf-quic-v2-04 * Clarified 0-RTT handling Duke Expires 18 June 2023 [Page 16] Internet-Draft QUICv2 December 2022 * Editorial comments from Zahed Sarker. C.7. since draft-ietf-quic-v2-03 * a v2 session ticket is an indication of v2 support * a v1-only extension is theoretically possible * editorial fixes C.8. since draft-ietf-quic-v2-02 * Editorial comments from Lucas Pardue C.9. since draft-ietf-quic-v2-01 * Ban use of NEW_TOKEN tokens across versions * version-info transport parameter required for all v2 endpoints * Explicitly list known ALPN compatibility C.10. since draft-ietf-quic-v2-00 * Expanded requirements for compatible version negotiation * Added test vectors * Greased the packet type codepoints * Random version number * Clarified requirement to use QUIC-VN * Banned use of resumption tokens across versions C.11. since draft-duke-quic-v2-02 * Converted to adopted draft * Deleted references to QUIC improvements * Clarified status of QUIC extensions C.12. since draft-duke-quic-v2-01 * Made the final version number TBD. Duke Expires 18 June 2023 [Page 17] Internet-Draft QUICv2 December 2022 * Added ALPN considerations C.13. since draft-duke-quic-v2-00 * Added provisional versions for interop * Change the v1 Retry Tag secret * Change labels to create full key separation Author's Address Martin Duke Google LLC Email: martin.h.duke@gmail.com Duke Expires 18 June 2023 [Page 18] ./draft-ietf-dnsop-svcb-https-11.txt0000644000764400076440000041247114321113651017072 0ustar iustiniustin DNSOP Working Group B. Schwartz Internet-Draft Google Intended status: Standards Track M. Bishop Expires: 13 April 2023 E. Nygren Akamai Technologies 10 October 2022 Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) draft-ietf-dnsop-svcb-https-11 Abstract This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 13 April 2023. Schwartz, et al. Expires 13 April 2023 [Page 1] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Goals of the SVCB RR . . . . . . . . . . . . . . . . . . 5 1.2. Overview of the SVCB RR . . . . . . . . . . . . . . . . . 6 1.3. Parameter for Encrypted ClientHello . . . . . . . . . . . 7 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2. The SVCB record type . . . . . . . . . . . . . . . . . . . . 7 2.1. Zone file presentation format . . . . . . . . . . . . . . 8 2.2. RDATA wire format . . . . . . . . . . . . . . . . . . . . 9 2.3. SVCB query names . . . . . . . . . . . . . . . . . . . . 10 2.4. Interpretation . . . . . . . . . . . . . . . . . . . . . 11 2.4.1. SvcPriority . . . . . . . . . . . . . . . . . . . . . 11 2.4.2. AliasMode . . . . . . . . . . . . . . . . . . . . . . 11 2.4.3. ServiceMode . . . . . . . . . . . . . . . . . . . . . 13 2.5. Special handling of "." in TargetName . . . . . . . . . . 13 2.5.1. AliasMode . . . . . . . . . . . . . . . . . . . . . . 13 2.5.2. ServiceMode . . . . . . . . . . . . . . . . . . . . . 13 3. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Handling resolution failures . . . . . . . . . . . . . . 15 3.2. Clients using a Proxy . . . . . . . . . . . . . . . . . . 16 4. DNS Server Behavior . . . . . . . . . . . . . . . . . . . . . 17 4.1. Authoritative servers . . . . . . . . . . . . . . . . . . 17 4.2. Recursive resolvers . . . . . . . . . . . . . . . . . . . 17 4.2.1. DNS64 . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. General requirements . . . . . . . . . . . . . . . . . . 18 4.4. EDNS Client Subnet (ECS) . . . . . . . . . . . . . . . . 19 5. Performance optimizations . . . . . . . . . . . . . . . . . . 19 5.1. Optimistic pre-connection and connection reuse . . . . . 20 5.2. Generating and using incomplete responses . . . . . . . . 20 6. SVCB-compatible . . . . . . . . . . . . . . . . . . . . . . . 21 7. Initial SvcParamKeys . . . . . . . . . . . . . . . . . . . . 21 7.1. "alpn" and "no-default-alpn" . . . . . . . . . . . . . . 22 7.1.1. Representation . . . . . . . . . . . . . . . . . . . 22 Schwartz, et al. Expires 13 April 2023 [Page 2] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 7.1.2. Use . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.2. "port" . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. "ech" . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.4. "ipv4hint" and "ipv6hint" . . . . . . . . . . . . . . . . 25 7.5. "mandatory" . . . . . . . . . . . . . . . . . . . . . . . 26 8. ServiceMode RR compatibility and mandatory keys . . . . . . . 26 9. Using Service Bindings with HTTP . . . . . . . . . . . . . . 27 9.1. Query names for HTTPS RRs . . . . . . . . . . . . . . . . 27 9.2. Comparison with Alt-Svc . . . . . . . . . . . . . . . . . 28 9.2.1. ALPN usage . . . . . . . . . . . . . . . . . . . . . 28 9.2.2. Untrusted channel . . . . . . . . . . . . . . . . . . 28 9.2.3. Cache lifetime . . . . . . . . . . . . . . . . . . . 28 9.2.4. Granularity . . . . . . . . . . . . . . . . . . . . . 29 9.3. Interaction with Alt-Svc . . . . . . . . . . . . . . . . 29 9.4. Requiring Server Name Indication . . . . . . . . . . . . 30 9.5. HTTP Strict Transport Security . . . . . . . . . . . . . 30 9.6. Use of HTTPS RRs in other protocols . . . . . . . . . . . 31 10. SVCB/HTTPS RR parameter for ECH configuration . . . . . . . . 32 10.1. Client behavior . . . . . . . . . . . . . . . . . . . . 32 10.2. Deployment considerations . . . . . . . . . . . . . . . 32 11. Zone Structures . . . . . . . . . . . . . . . . . . . . . . . 33 11.1. Structuring zones for flexibility . . . . . . . . . . . 33 11.2. Structuring zones for performance . . . . . . . . . . . 33 11.3. Operational considerations . . . . . . . . . . . . . . . 34 11.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 34 11.4.1. Protocol enhancements . . . . . . . . . . . . . . . 34 11.4.2. Apex aliasing . . . . . . . . . . . . . . . . . . . 34 11.4.3. Parameter binding . . . . . . . . . . . . . . . . . 35 11.4.4. Multi-CDN . . . . . . . . . . . . . . . . . . . . . 36 11.4.5. Non-HTTP uses . . . . . . . . . . . . . . . . . . . 38 12. Interaction with other standards . . . . . . . . . . . . . . 38 13. Security Considerations . . . . . . . . . . . . . . . . . . . 38 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 39 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 15.1. SVCB RRType . . . . . . . . . . . . . . . . . . . . . . 40 15.2. HTTPS RRType . . . . . . . . . . . . . . . . . . . . . . 40 15.3. New registry for Service Parameters . . . . . . . . . . 40 15.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . 40 15.3.2. Initial contents . . . . . . . . . . . . . . . . . . 41 15.4. Other registry updates . . . . . . . . . . . . . . . . . 43 16. Acknowledgments and Related Proposals . . . . . . . . . . . . 43 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 17.1. Normative References . . . . . . . . . . . . . . . . . . 43 17.2. Informative References . . . . . . . . . . . . . . . . . 46 Appendix A. Decoding text in zone files . . . . . . . . . . . . 47 A.1. Decoding a comma-separated list . . . . . . . . . . . . . 48 Appendix B. HTTP Mapping Summary . . . . . . . . . . . . . . . . 49 Appendix C. Comparison with alternatives . . . . . . . . . . . . 50 Schwartz, et al. Expires 13 April 2023 [Page 3] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 C.1. Differences from the SRV RR type . . . . . . . . . . . . 50 C.2. Differences from the proposed HTTP record . . . . . . . . 50 C.3. Differences from the proposed ANAME record . . . . . . . 50 C.4. Comparison with separate RR types for AliasMode and ServiceMode . . . . . . . . . . . . . . . . . . . . . . . 51 Appendix D. Test vectors . . . . . . . . . . . . . . . . . . . . 51 D.1. AliasMode . . . . . . . . . . . . . . . . . . . . . . . . 51 D.2. ServiceMode . . . . . . . . . . . . . . . . . . . . . . . 51 D.3. Failure cases . . . . . . . . . . . . . . . . . . . . . . 56 Appendix E. Change history . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 1. Introduction The SVCB ("Service Binding") and HTTPS RRs provide clients with complete instructions for access to a service. This information enables improved performance and privacy by avoiding transient connections to a suboptimal default server, negotiating a preferred protocol, and providing relevant public keys. For example, HTTP clients currently resolve only A and/or AAAA records for the origin hostname, learning only its IP addresses. If an HTTP client learns more about the origin before connecting, it may be able to upgrade "http" URLs to "https", enable HTTP/3 or Encrypted ClientHello [ECH], or switch to an operationally preferable endpoint. It is highly desirable to minimize the number of round-trips and lookups required to learn this additional information. The SVCB and HTTPS RRs also help when the operator of a service wishes to delegate operational control to one or more other domains, e.g. delegating the origin "https://example.com" to a service operator endpoint at "svc.example.net". While this case can sometimes be handled by a CNAME, that does not cover all use-cases. CNAME is also inadequate when the service operator needs to provide a bound collection of consistent configuration parameters through the DNS (such as network location, protocol, and keying information). This document first describes the SVCB RR as a general-purpose resource record that can be applied directly and efficiently to a wide range of services (Section 2). It also describes the rules for defining other SVCB-compatible RR types (Section 6), starting with the HTTPS RR type (Section 9), which provides improved efficiency and convenience with HTTP by avoiding the need for an Attrleaf label [Attrleaf] (Section 9.1). Schwartz, et al. Expires 13 April 2023 [Page 4] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 The SVCB RR has two modes: 1) "AliasMode", which simply delegates operational control for a resource; 2) "ServiceMode", which binds together configuration information for a service endpoint. ServiceMode provides additional key=value parameters within each RDATA set. 1.1. Goals of the SVCB RR The goal of the SVCB RR is to allow clients to resolve a single additional DNS RR in a way that: * Provides alternative endpoints that are authoritative for the service, along with parameters associated with each of these endpoints. * Does not assume that all alternative endpoints have the same parameters or capabilities, or are even operated by the same entity. This is important, as DNS does not provide any way to tie together multiple RRSets for the same name. For example, if www.example.com is a CNAME alias that switches between one of three CDNs or hosting environments, successive queries for that name may return records that correspond to different environments. * Enables CNAME-like functionality at a zone apex (such as "example.com") for participating protocols, and generally enables delegation of operational authority for an origin within the DNS to an alternate name. Additional goals specific to HTTPS RRs and the HTTP use-cases include: * Connect directly to HTTP/3 (QUIC transport) alternative endpoints [HTTP3] * Obtain the Encrypted ClientHello [ECH] keys associated with an alternative endpoint * Support non-default TCP and UDP ports * Enable SRV-like benefits (e.g. apex delegation, as mentioned above) for HTTP, where SRV [SRV] has not been widely adopted * Provide an HSTS-like indication [HSTS] signaling that the "https" scheme should be used instead of "http" for all HTTP requests to this host and port (see Section 9.5). Schwartz, et al. Expires 13 April 2023 [Page 5] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 1.2. Overview of the SVCB RR This subsection briefly describes the SVCB RR with forward references to the full exposition of each component. (As mentioned above, this all applies equally to the HTTPS RR which shares the same encoding, format, and high-level semantics.) The SVCB RR has two modes: AliasMode (Section 2.4.2), which aliases a name to another name, and ServiceMode (Section 2.4.3), which provides connection information bound to a service endpoint domain. Placing both forms in a single RR type allows clients to fetch the relevant information with a single query (Section 2.3). The SVCB RR has two required fields and one optional field. The fields are: 1. SvcPriority (Section 2.4.1): The priority of this record (relative to others, with lower values preferred). A value of 0 indicates AliasMode. 2. TargetName: The domain name of either the alias target (for AliasMode) or the alternative endpoint (for ServiceMode). 3. SvcParams (optional): A list of key=value pairs describing the alternative endpoint at TargetName (only used in ServiceMode and otherwise ignored). Described in Section 2.1. Cooperating DNS recursive resolvers will perform subsequent record resolution (for SVCB, A, and AAAA records) and return them in the Additional Section of the response (Section 4.2). Clients either use responses included in the additional section returned by the recursive resolver or perform necessary SVCB, A, and AAAA record resolutions (Section 3). DNS authoritative servers can attach in- bailiwick SVCB, A, AAAA, and CNAME records in the Additional Section to responses for a SVCB query (Section 4.1). In ServiceMode, the SvcParams of the SVCB RR provide an extensible data model for describing alternative endpoints that are authoritative for a service, along with parameters associated with each of these alternative endpoints (Section 7). For HTTP use-cases, the HTTPS RR (Section 9) enables many of the benefits of Alt-Svc [AltSvc] without waiting for a full HTTP connection initiation (multiple roundtrips) before learning of the preferred alternative, and without necessarily revealing the user's intended destination to all entities along the network path. Schwartz, et al. Expires 13 April 2023 [Page 6] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 1.3. Parameter for Encrypted ClientHello This document also defines a parameter for Encrypted ClientHello [ECH] keys. See Section 10. 1.4. Terminology Our terminology is based on the common case where the SVCB record is used to access a resource identified by a URI whose authority field contains a DNS hostname as the host. * The "service" is the information source identified by the authority and scheme of the URI, capable of providing access to the resource. For "https" URIs, the "service" corresponds to an "origin" [RFC6454]. * The "service name" is the host portion of the authority. * The "authority endpoint" is the authority's hostname and a port number implied by the scheme or specified in the URI. * An "alternative endpoint" is a hostname, port number, and other associated instructions to the client on how to reach an instance of service. Additional DNS terminology intends to be consistent with [DNSTerm]. SVCB is a contraction of "service binding". The SVCB RR, HTTPS RR, and future RR types that share SVCB's formats and registry are collectively known as SVCB-compatible RR types. The contraction "SVCB" is also used to refer to this system as a whole. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. The SVCB record type The SVCB DNS resource record (RR) type (RR type 64) is used to locate alternative endpoints for a service. The algorithm for resolving SVCB records and associated address records is specified in Section 3. Schwartz, et al. Expires 13 April 2023 [Page 7] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 Other SVCB-compatible resource record types can also be defined as- needed (see Section 6). In particular, the HTTPS RR (RR type 65) provides special handling for the case of "https" origins as described in Section 9. SVCB RRs are extensible by a list of SvcParams, which are pairs consisting of a SvcParamKey and a SvcParamValue. Each SvcParamKey has a presentation name and a registered number. Values are in a format specific to the SvcParamKey. Each SvcParam has a specified presentation format (used in zone files) and wire encoding (e.g., domain names, binary data, or numeric values). The initial SvcParamKeys and their formats are defined in Section 7. 2.1. Zone file presentation format The presentation format of the record ([RFC1035], Section 5.1) has the form: SvcPriority TargetName SvcParams The SVCB record is defined specifically within the Internet ("IN") Class ([RFC1035], Section 3.2.4). SvcPriority is a number in the range 0-65535, TargetName is a ([RFC1035], Section 5.1), and the SvcParams are a whitespace-separated list, with each SvcParam consisting of a SvcParamKey=SvcParamValue pair or a standalone SvcParamKey. SvcParamKeys are subject to IANA control (Section 15.3). Each SvcParamKey SHALL appear at most once in the SvcParams. In presentation format, SvcParamKeys are lower-case alphanumeric strings. Key names contain 1-63 characters from the ranges "a"-"z", "0"-"9", and "-". In ABNF [RFC5234], alpha-lc = %x61-7A ; a-z SvcParamKey = 1*63(alpha-lc / DIGIT / "-") SvcParam = SvcParamKey ["=" SvcParamValue] SvcParamValue = char-string ; See Appendix A value = *OCTET ; Value before key-specific parsing The SvcParamValue is parsed using the character-string decoding algorithm (Appendix A), producing a value. The value is then validated and converted into wire-format in a manner specific to each key. When the optional "=" and SvcParamValue are omitted, the value is interpreted as empty. Schwartz, et al. Expires 13 April 2023 [Page 8] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 Arbitrary keys can be represented using the unknown-key presentation format "keyNNNNN" where NNNNN is the numeric value of the key type without leading zeros. A SvcParam in this form SHALL be parsed as specified above, and the decoded value SHALL be used as its wire format encoding. For some SvcParamKeys, the value corresponds to a list or set of items. Presentation formats for such keys SHOULD use a comma- separated list (Appendix A.1). SvcParams in presentation format MAY appear in any order, but keys MUST NOT be repeated. 2.2. RDATA wire format The RDATA for the SVCB RR consists of: * a 2-octet field for SvcPriority as an integer in network byte order. * the uncompressed, fully-qualified TargetName, represented as a sequence of length-prefixed labels as in Section 3.1 of [RFC1035]. * the SvcParams, consuming the remainder of the record (so smaller than 65535 octets and constrained by the RDATA and DNS message sizes). When the list of SvcParams is non-empty, it contains a series of SvcParamKey=SvcParamValue pairs, represented as: * a 2-octet field containing the SvcParamKey as an integer in network byte order. (See Section 15.3.2 for the defined values.) * a 2-octet field containing the length of the SvcParamValue as an integer between 0 and 65535 in network byte order. * an octet string of this length whose contents are the SvcParamValue in a format determined by the SvcParamKey. SvcParamKeys SHALL appear in increasing numeric order. Clients MUST consider an RR malformed if: * the end of the RDATA occurs within a SvcParam. * SvcParamKeys are not in strictly increasing numeric order. Schwartz, et al. Expires 13 April 2023 [Page 9] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 * the SvcParamValue for an SvcParamKey does not have the expected format. Note that the second condition implies that there are no duplicate SvcParamKeys. If any RRs are malformed, the client MUST reject the entire RRSet and fall back to non-SVCB connection establishment. 2.3. SVCB query names When querying the SVCB RR, a service is translated into a QNAME by prepending the service name with a label indicating the scheme, prefixed with an underscore, resulting in a domain name like "_examplescheme.api.example.com.". This follows the Attrleaf naming pattern [Attrleaf], so the scheme MUST be registered appropriately with IANA (see Section 12). Protocol mapping documents MAY specify additional underscore-prefixed labels to be prepended. For schemes that specify a port (Section 3.2.3 of [URI]), one reasonable possibility is to prepend the indicated port number if a non-default port number is specified. We term this behavior "Port Prefix Naming", and use it in the examples throughout this document. See Section 9.1 for the HTTPS RR behavior. When a prior CNAME or SVCB record has aliased to a SVCB record, each RR SHALL be returned under its own owner name, as in ordinary CNAME processing ([RFC1034], Section 3.6.2). For details, see the recommendations regarding aliases for clients (Section 3), servers (Section 4), and zones (Section 11). Note that none of these forms alter the origin or authority for validation purposes. For example, TLS clients MUST continue to validate TLS certificates for the original service name. As an example, the owner of example.com could publish this record: _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net. to indicate that "foo://api.example.com:8443" is aliased to "svc4.example.net". The owner of example.net, in turn, could publish this record: svc4.example.net. 7200 IN SVCB 3 svc4.example.net. ( alpn="bar" port="8004" ech="..." ) Schwartz, et al. Expires 13 April 2023 [Page 10] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 to indicate that these services are served on port number 8004, which supports the protocol "bar" and its associated transport in addition to the default transport protocol for "foo://". (Parentheses are used to ignore a line break in DNS zone file presentation format ([RFC1035], Section 5.1).) 2.4. Interpretation 2.4.1. SvcPriority When SvcPriority is 0 the SVCB record is in AliasMode (Section 2.4.2). Otherwise, it is in ServiceMode (Section 2.4.3). Within a SVCB RRSet, all RRs SHOULD have the same Mode. If an RRSet contains a record in AliasMode, the recipient MUST ignore any ServiceMode records in the set. RRSets are explicitly unordered collections, so the SvcPriority field is used to impose an ordering on SVCB RRs. A smaller SvcPriority indicates that the domain owner recommends use of this record over ServiceMode RRs with a larger SvcPriority value. When receiving an RRSet containing multiple SVCB records with the same SvcPriority value, clients SHOULD apply a random shuffle within a priority level to the records before using them, to ensure uniform load-balancing. 2.4.2. AliasMode In AliasMode, the SVCB record aliases a service to a TargetName. SVCB RRSets SHOULD only have a single resource record in AliasMode. If multiple are present, clients or recursive resolvers SHOULD pick one at random. The primary purpose of AliasMode is to allow aliasing at the zone apex, where CNAME is not allowed (see e.g. [RFC1912], Section 2.4). In AliasMode, the TargetName will be the name of a domain that resolves to SVCB, AAAA, and/or A records. (See Section 6 for aliasing of SVCB-compatible RR types.) Unlike CNAME, AliasMode records do not affect the resolution of other RR types, and apply only to a specific service, not an entire domain name. Schwartz, et al. Expires 13 April 2023 [Page 11] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 The AliasMode TargetName SHOULD NOT be equal to the owner name, as this would result in a loop. In AliasMode, recipients MUST ignore any SvcParams that are present. Zone-file parsers MAY emit a warning if an AliasMode record has SvcParams. The use of SvcParams in AliasMode records is currently not defined, but a future specification could extend AliasMode records to include SvcParams. For example, the operator of foo://example.com:8080 could point requests to a service operating at foosvc.example.net by publishing: _8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net. Using AliasMode maintains a separation of concerns: the owner of foosvc.example.net can add or remove ServiceMode SVCB records without requiring a corresponding change to example.com. Note that if foosvc.example.net promises to always publish a SVCB record, this AliasMode record can be replaced by a CNAME at the same owner name, which would likely improve performance. AliasMode is especially useful for SVCB-compatible RR types that do not require an underscore prefix, such as the HTTPS RR type. For example, the operator of https://example.com could point requests to a server at svc.example.net by publishing this record at the zone apex: example.com. 3600 IN HTTPS 0 svc.example.net. Note that the SVCB record's owner name MAY be the canonical name of a CNAME record, and the TargetName MAY be the owner of a CNAME record. Clients and recursive resolvers MUST follow CNAMEs as normal. To avoid unbounded alias chains, clients and recursive resolvers MUST impose a limit on the total number of SVCB aliases they will follow for each resolution request. This limit MUST NOT be zero, i.e. implementations MUST be able to follow at least one AliasMode record. The exact value of this limit is left to implementations. Zones that require following multiple AliasMode records could encounter compatibility and performance issues. As legacy clients will not know to use this record, service operators will likely need to retain fallback AAAA and A records alongside this SVCB record, although in a common case the target of the SVCB record might offer better performance, and therefore would be preferable for clients implementing this specification to use. Schwartz, et al. Expires 13 April 2023 [Page 12] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 AliasMode records only apply to queries for the specific RR type. For example, a SVCB record cannot alias to an HTTPS record, nor vice- versa. 2.4.3. ServiceMode In ServiceMode, the TargetName and SvcParams within each resource record associate an alternative endpoint for the service with its connection parameters. Each protocol scheme that uses SVCB MUST define a protocol mapping that explains how SvcParams are applied for connections of that scheme. Unless specified otherwise by the protocol mapping, clients MUST ignore any SvcParam that they do not recognize. Some SvcParams impose requirements on other SvcParams in the RR. A ServiceMode RR is called "self-consistent" if its SvcParams all comply with each other's requirements. Clients MUST reject any RR whose recognized SvcParams are not self-consistent, and MAY reject the entire RRSet. To help zone operators avoid this condition, zone- file implementations SHOULD enforce self-consistency as well. 2.5. Special handling of "." in TargetName If TargetName has the value "." (represented in the wire format as a zero-length label), special rules apply. 2.5.1. AliasMode For AliasMode SVCB RRs, a TargetName of "." indicates that the service is not available or does not exist. This indication is advisory: clients encountering this indication MAY ignore it and attempt to connect without the use of SVCB. 2.5.2. ServiceMode For ServiceMode SVCB RRs, if TargetName has the value ".", then the owner name of this record MUST be used as the effective TargetName. If the record has a wildcard owner name in the zone file, the recipient SHALL use the response's synthesized owner name as the effective TargetName. For example, in the following example "svc2.example.net" is the effective TargetName: Schwartz, et al. Expires 13 April 2023 [Page 13] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 example.com. 7200 IN HTTPS 0 svc.example.net. svc.example.net. 7200 IN CNAME svc2.example.net. svc2.example.net. 7200 IN HTTPS 1 . port=8002 ech="..." svc2.example.net. 300 IN A 192.0.2.2 svc2.example.net. 300 IN AAAA 2001:db8::2 3. Client behavior "SVCB resolution" is the process of enumerating the priority-ordered endpoints for a service, as performed by the client. SVCB resolution is implemented as follows: 1. Let $QNAME be the service name plus appropriate prefixes for the scheme (see Section 2.3). 2. Issue a SVCB query for $QNAME. 3. If an AliasMode SVCB record is returned for $QNAME (after following CNAMEs as normal), set $QNAME to its TargetName (without additional prefixes) and loop back to step 2, subject to chain length limits and loop detection heuristics (see Section 3.1). 4. If one or more "compatible" (Section 8) ServiceMode records are returned, these represent the alternative endpoints. 5. Otherwise, SVCB resolution has failed, and the list of known endpoints is empty. This procedure does not rely on any recursive or authoritative DNS server to comply with this specification or have any awareness of SVCB. A client is called "SVCB-optional" if it can connect without the use of ServiceMode records, and "SVCB-reliant" otherwise. Clients for pre-existing protocols (e.g. HTTP) SHALL implement SVCB-optional behavior (except as noted in Section 3.1 and Section 10.1). SVCB-optional clients SHOULD issue in parallel any other DNS queries that might be needed for connection establishment if the SVCB record is absent, in order to minimize delay in that case and enable the optimizations discussed in Section 5. Once SVCB resolution has concluded, whether successful or not, if at least one AliasMode record was processed, SVCB-optional clients SHALL append to the priority list an endpoint consisting of the final value of $QNAME, the authority endpoint's port number, and no SvcParams. (This endpoint will be attempted before falling back to non-SVCB Schwartz, et al. Expires 13 April 2023 [Page 14] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 connection modes. This ensures that SVCB-optional clients will make use of an AliasMode record whose TargetName has A and/or AAAA records but no SVCB records.) The client proceeds with connection establishment using the resolved list of endpoints. Clients SHOULD try higher-priority alternatives first, with fallback to lower-priority alternatives. Clients resolve AAAA and/or A records for the selected TargetName, and MAY choose between them using an approach such as Happy Eyeballs [HappyEyeballsV2]. If the client is SVCB-optional, and connecting using this list of endpoints has failed, the client now attempts to use non-SVCB connection modes. Some important optimizations are discussed in Section 5 to avoid additional latency in comparison to ordinary AAAA/A lookups. 3.1. Handling resolution failures If DNS responses are cryptographically protected (e.g. using DNSSEC or TLS [DoT][DoH]), and SVCB resolution fails due to an authentication error, SERVFAIL response, transport error, or timeout, the client SHOULD abandon its attempt to reach the service, even if the client is SVCB-optional. Otherwise, an active attacker could mount a downgrade attack by denying the user access to the SvcParams. A SERVFAIL error can occur if the domain is DNSSEC-signed, the recursive resolver is DNSSEC-validating, and the attacker is between the recursive resolver and the authoritative DNS server. A transport error or timeout can occur if an active attacker between the client and the recursive resolver is selectively dropping SVCB queries or responses, based on their size or other observable patterns. If the client enforces DNSSEC validation on A/AAAA responses, it SHOULD apply the same validation policy to SVCB. Otherwise, an attacker could defeat the A/AAAA protection by forging SVCB responses that direct the client to other IP addresses. If DNS responses are not cryptographically protected, clients MAY treat SVCB resolution failure as fatal or nonfatal. If the client is unable to complete SVCB resolution due to its chain length limit, the client MUST fall back to the authority endpoint, as if the origin's SVCB record did not exist. Schwartz, et al. Expires 13 April 2023 [Page 15] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 3.2. Clients using a Proxy Clients using a domain-oriented transport proxy like HTTP CONNECT ([RFC7231], Section 4.3.6) or SOCKS5 ([RFC1928]) have the option to use named destinations, in which case the client does not perform any A or AAAA queries for destination domains. If the client is configured to use named destinations with a proxy that does not provide SVCB query capability (e.g. through an affiliated DNS resolver), the client would have to perform SVCB resolution separately, likely disclosing the destinations to additional parties than just the proxy. Clients in this configuration SHOULD arrange for a separate SVCB resolution procedure with appropriate privacy properties. If this is not possible, SVCB-optional clients MUST disable SVCB resolution entirely, and SVCB-required clients MUST treat the configuration as invalid. If the client does use SVCB and named destinations, the client SHOULD follow the standard SVCB resolution process, selecting the smallest- SvcPriority option that is compatible with the client and the proxy. When connecting using a SVCB record, clients MUST provide the final TargetName and port to the proxy, which will perform any required A and AAAA lookups. This arrangement has several benefits: * Compared to disabling SVCB: - It allows the client to use the SvcParams, if present, which are only usable with a specific TargetName. The SvcParams may include information that enhances performance (e.g. alpn) and privacy (e.g. ech). - It allows the service to delegate the apex domain. * Compared to providing the proxy with an IP address: - It allows the proxy to select between IPv4 and IPv6 addresses for the server according to its configuration. - It ensures that the proxy receives addresses based on its network geolocation, not the client's. - It enables faster fallback for TCP destinations with multiple addresses of the same family. Schwartz, et al. Expires 13 April 2023 [Page 16] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 4. DNS Server Behavior 4.1. Authoritative servers When replying to a SVCB query, authoritative DNS servers SHOULD return A, AAAA, and SVCB records in the Additional Section for any TargetNames that are in the zone. If the zone is signed, the server SHOULD also include positive or negative DNSSEC responses for these records in the Additional section. See Section 4.4 for exceptions. 4.2. Recursive resolvers Whether the recursive resolver is aware of SVCB or not, the normal response construction process (i.e. unknown RR type resolution under [RFC3597]) generates the Answer section of the response. Recursive resolvers that are aware of SVCB SHOULD help the client to execute the procedure in Section 3 with minimum overall latency by incorporating additional useful information into the Additional section of the response as follows: 1. Incorporate the results of SVCB resolution. If the recursive resolver's local chain length limit (which may be different from the client's limit) has been reached, terminate. 2. If any of the resolved SVCB records are in AliasMode, choose one of them at random, and resolve SVCB, A, and AAAA records for its TargetName. * If any SVCB records are resolved, go to step 1. * Otherwise, incorporate the results of A and AAAA resolution, and terminate. 3. All the resolved SVCB records are in ServiceMode. Resolve A and AAAA queries for each TargetName (or for the owner name if TargetName is "."), incorporate all the results, and terminate. In this procedure, "resolve" means the resolver's ordinary recursive resolution procedure, as if processing a query for that RRSet. This includes following any aliases that the resolver would ordinarily follow (e.g. CNAME, DNAME [DNAME]). Errors or anomalies in obtaining additional records MAY cause this process to terminate, but MUST NOT themselves cause the resolver to send a failure response. See Section 2.4.2 for additional safeguards for recursive resolvers to implement to mitigate loops. Schwartz, et al. Expires 13 April 2023 [Page 17] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 See Section 5.2 for possible optimizations of this procedure. 4.2.1. DNS64 DNS64 resolvers synthesize responses to AAAA queries for names that only have an A record (Section 5.1.7 of [RFC6147]). SVCB-aware DNS64 resolvers SHOULD apply the same synthesis logic when resolving AAAA records for the TargetName for inclusion as Additionals (Step 2 in Section 4.2), and MAY omit the Additional A records. DNS64 resolvers MUST NOT extrapolate the AAAA synthesis logic to the IP hints in the SvcParams (Section 7.4). Modifying the IP hints would break DNSSEC validation for the SVCB record and would not improve performance when the above recommendation is implemented. 4.3. General requirements Recursive resolvers MUST be able to convey SVCB records with unrecognized SvcParamKeys, and MAY treat the entire SvcParams portion of the record as opaque, even if the contents are invalid. Alternatively, recursive resolvers MAY report an error such as SERVFAIL to avoid returning a SvcParamValue that is invalid according to the SvcParam's specification. For complex value types whose interpretation might differ between implementations or have additional future allowed values added (e.g. URIs or "alpn"), resolvers SHOULD limit validation to specified constraints. When responding to a query that includes the DNSSEC OK bit ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers MUST accompany each RRSet in the Additional section with the same DNSSEC-related records that they would send when providing that RRSet as an Answer (e.g. RRSIG, NSEC, NSEC3). According to Section 5.4.1 of [RFC2181], "Unauthenticated RRs received and cached from ... the additional data section ... should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate.". Recursive resolvers therefore MAY cache records from the Additional section for use in populating Additional section responses, and MAY cache them for general use if they are authenticated by DNSSEC. Schwartz, et al. Expires 13 April 2023 [Page 18] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 4.4. EDNS Client Subnet (ECS) The EDNS Client Subnet option (ECS, [RFC7871]) allows recursive resolvers to request IP addresses that are suitable for a particular client IP range. SVCB records may contain IP addresses (in ipv*hint SvcParams), or direct users to a subnet-specific TargetName, so recursive resolvers SHOULD include the same ECS option in SVCB queries as in A/AAAA queries. According to Section 7.3.1 of [RFC7871], "Any records from [the Additional section] MUST NOT be tied to a network". Accordingly, when processing a response whose QTYPE is SVCB-compatible, resolvers SHOULD treat any records in the Additional section as having SOURCE PREFIX-LENGTH zero and SCOPE PREFIX-LENGTH as specified in the ECS option. Authoritative servers MUST omit such records if they are not suitable for use by any stub resolvers that set SOURCE PREFIX-LENGTH to zero. This will cause the resolver to perform a follow-up query that can receive properly tailored ECS. (This is similar to the usage of CNAME with ECS discussed in [RFC7871], Section 7.2.1.) Authoritative servers that omit Additional records can avoid the added latency of a follow-up query by following the advice in Section 11.2. 5. Performance optimizations For optimal performance (i.e. minimum connection setup time), clients SHOULD implement a client-side DNS cache. Responses in the Additional section of a SVCB response SHOULD be placed in cache before performing any follow-up queries. With this behavior, and conforming DNS servers, using SVCB does not add network latency to connection setup. To improve performance when using a non-conforming recursive resolver, clients SHOULD issue speculative A and/or AAAA queries in parallel with each SVCB query, based on a predicted value of TargetName (see Section 11.2). After a ServiceMode RRSet is received, clients MAY try more than one option in parallel, and MAY prefetch A and AAAA records for multiple TargetNames. Schwartz, et al. Expires 13 April 2023 [Page 19] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 5.1. Optimistic pre-connection and connection reuse If an address response arrives before the corresponding SVCB response, the client MAY initiate a connection as if the SVCB query returned NODATA, but MUST NOT transmit any information that could be altered by the SVCB response until it arrives. For example, a TLS ClientHello can be altered by the "ech" value of a SVCB response (Section 7.3). Clients implementing this optimization SHOULD wait for 50 milliseconds before starting optimistic pre-connection, as per the guidance in [HappyEyeballsV2]. A SVCB record is consistent with a connection if the client would attempt an equivalent connection when making use of that record. If a SVCB record is consistent with an active or in-progress connection C, the client MAY prefer that record and use C as its connection. For example, suppose the client receives this SVCB RRSet for a protocol that uses TLS over TCP: _1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. ( ech="111..." ipv6hint=2001:db8::1 port=1234 ) SVCB 2 svc2.example.net. ( ech="222..." ipv6hint=2001:db8::2 port=1234 ) If the client has an in-progress TCP connection to [2001:db8::2]:1234, it MAY proceed with TLS on that connection using ech="222...", even though the other record in the RRSet has higher priority. If none of the SVCB records are consistent with any active or in- progress connection, clients proceed with connection establishment as described in Section 3. 5.2. Generating and using incomplete responses When following the procedure in Section 4.2, recursive resolvers MAY terminate the procedure early and produce a reply that omits some of the associated RRSets. This is REQUIRED when the chain length limit is reached (Section 4.2 step 1), but might also be appropriate when the maximum response size is reached, or when responding before fully chasing dependencies would improve performance. When omitting certain RRSets, recursive resolvers SHOULD prioritize information for smaller-SvcPriority records. Schwartz, et al. Expires 13 April 2023 [Page 20] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 As discussed in Section 3, clients MUST be able to fetch additional information that is required to use a SVCB record, if it is not included in the initial response. As a performance optimization, if some of the SVCB records in the response can be used without requiring additional DNS queries, the client MAY prefer those records, regardless of their priorities. 6. SVCB-compatible An RR type is called "SVCB-compatible" if it permits an implementation that is identical to SVCB in its: * RDATA presentation format * RDATA wire format * IANA registry used for SvcParamKeys * Authoritative server Additional Section processing * Recursive resolution process * Relevant Class (i.e. Internet ("IN") [RFC1035]) This allows authoritative and recursive DNS servers to apply identical processing to all SVCB-compatible RR types. All other behaviors described as applying to the SVCB RR also apply to all SVCB-compatible RR types unless explicitly stated otherwise. When following an AliasMode record (Section 2.4.2) of RR type $T , the followup query to the TargetName MUST also be for type $T. This document defines one SVCB-compatible RR type (other than SVCB itself): the HTTPS RR type (Section 9), which avoids Attrleaf label prefixes [Attrleaf] in order to improve compatibility with wildcards and CNAMEs, which are widely used with HTTP. Standards authors should consider carefully whether to use SVCB or define a new SVCB-compatible RR type, as this choice cannot easily be reversed after deployment. 7. Initial SvcParamKeys A few initial SvcParamKeys are defined here. These keys are useful for the "https" scheme, and most are expected to be generally applicable to other schemes as well. Schwartz, et al. Expires 13 April 2023 [Page 21] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 Each new protocol mapping document MUST specify which keys are applicable and safe to use. Protocol mappings MAY alter the interpretation of SvcParamKeys but MUST NOT alter their presentation or wire formats. 7.1. "alpn" and "no-default-alpn" The "alpn" and "no-default-alpn" SvcParamKeys together indicate the set of Application Layer Protocol Negotiation (ALPN) protocol identifiers [ALPN] and associated transport protocols supported by this service endpoint (the "SVCB ALPN set"). As with Alt-Svc [AltSvc], each ALPN protocol identifier is used to identify the application protocol and associated suite of protocols supported by the endpoint (the "protocol suite"). The presence of an ALPN protocol identifier in the SVCB ALPN set indicates that this service endpoint, described by TargetName and the other parameters (e.g. "port") offers service with the protocol suite associated with this ALPN identifier. Clients filter the set of ALPN identifiers to match the protocol suites they support, and this informs the underlying transport protocol used (such as QUIC-over-UDP or TLS-over-TCP). ALPN protocol identifiers that do not uniquely identify a protocol suite (e.g. an Identification Sequence that can be used with both TLS and DTLS) are not compatible with this SvcParamKey and MUST NOT be included in the SVCB ALPN set. 7.1.1. Representation ALPNs are identified by their registered "Identification Sequence" (alpn-id), which is a sequence of 1-255 octets. alpn-id = 1*255OCTET For "alpn", the presentation value SHALL be a comma-separated list (Appendix A.1) of one or more alpn-ids. Zone file implementations MAY disallow the "," and "\" characters instead of implementing the value-list escaping procedure, relying on the opaque key format (e.g. key1=\002h2) in the event that these characters are needed. The wire format value for "alpn" consists of at least one alpn-id prefixed by its length as a single octet, and these length-value pairs are concatenated to form the SvcParamValue. These pairs MUST exactly fill the SvcParamValue; otherwise, the SvcParamValue is malformed. Schwartz, et al. Expires 13 April 2023 [Page 22] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 For "no-default-alpn", the presentation and wire format values MUST be empty. When "no-default-alpn" is specified in an RR, "alpn" must also be specified in order for the RR to be "self-consistent" (Section 2.4.3). Each scheme that uses this SvcParamKey defines a "default set" of ALPNs that are supported by nearly all clients and servers, which MAY be empty. To determine the SVCB ALPN set, the client starts with the list of alpn-ids from the "alpn" SvcParamKey, and adds the default set unless the "no-default-alpn" SvcParamKey is present. 7.1.2. Use To establish a connection to the endpoint, clients MUST 1. Let SVCB-ALPN-Intersection be the set of protocols in the SVCB ALPN set that the client supports. 2. Let Intersection-Transports be the set of transports (e.g. TLS, DTLS, QUIC) implied by the protocols in SVCB-ALPN-Intersection. 3. For each transport in Intersection-Transports, construct a ProtocolNameList containing the Identification Sequences of all the client's supported ALPN protocols for that transport, without regard to the SVCB ALPN set. For example, if the SVCB ALPN set is ["http/1.1", "h3"], and the client supports HTTP/1.1, HTTP/2, and HTTP/3, the client could attempt to connect using TLS over TCP with a ProtocolNameList of ["http/1.1", "h2"], and could also attempt a connection using QUIC, with a ProtocolNameList of ["h3"]. Once the client has constructed a ClientHello, protocol negotiation in that handshake proceeds as specified in [ALPN], without regard to the SVCB ALPN set. Clients MAY implement a fallback procedure, using a less-preferred transport if more-preferred transports fail to connect. This fallback behavior is vulnerable to manipulation by a network attacker who blocks the more-preferred transports, but it may be necessary for compatibility with existing networks. With this procedure in place, an attacker who can modify DNS and network traffic can prevent a successful transport connection, but cannot otherwise interfere with ALPN protocol selection. This procedure also ensures that each ProtocolNameList includes at least one protocol from the SVCB ALPN set. Schwartz, et al. Expires 13 April 2023 [Page 23] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 Clients SHOULD NOT attempt connection to a service endpoint whose SVCB ALPN set does not contain any supported protocols. To ensure consistency of behavior, clients MAY reject the entire SVCB RRSet and fall back to basic connection establishment if all of the compatible RRs indicate "no-default-alpn", even if connection could have succeeded using a non-default alpn. Zone operators SHOULD ensure that at least one RR in each RRSet supports the default transports. This enables compatibility with the greatest number of clients. 7.2. "port" The "port" SvcParamKey defines the TCP or UDP port that should be used to reach this alternative endpoint. If this key is not present, clients SHALL use the authority endpoint's port number. The presentation value of the SvcParamValue is a single decimal integer between 0 and 65535 in ASCII. Any other value (e.g. an empty value) is a syntax error. To enable simpler parsing, this SvcParam MUST NOT contain escape sequences. The wire format of the SvcParamValue is the corresponding 2 octet numeric value in network byte order. If a port-restricting firewall is in place between some client and the service endpoint, changing the port number might cause that client to lose access to the service, so operators should exercise caution when using this SvcParamKey to specify a non-default port. 7.3. "ech" The SvcParamKey to enable Encrypted ClientHello (ECH) is "ech". Its value is defined in Section 10. It is applicable to most TLS-based protocols. Schwartz, et al. Expires 13 April 2023 [Page 24] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 When publishing a record containing an "ech" parameter, the publisher MUST ensure that all IP addresses of TargetName correspond to servers that have access to the corresponding private key or are authoritative for the public name. (See Section 7.2.2 of [ECH] for more details about the public name.) This yields an anonymity set of cardinality equal to the number of ECH-enabled server domains supported by a given client-facing server. Thus, even with an encrypted ClientHello, an attacker who can enumerate the set of ECH- enabled domains supported by a client-facing server can guess the correct SNI with probability at least 1/K, where K is the size of this ECH-enabled server anonymity set. This probability may be increased via traffic analysis or other mechanisms. 7.4. "ipv4hint" and "ipv6hint" The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY use to reach the service. If A and AAAA records for TargetName are locally available, the client SHOULD ignore these hints. Otherwise, clients SHOULD perform A and/or AAAA queries for TargetName as in Section 3, and clients SHOULD use the IP address in those responses for future connections. Clients MAY opt to terminate any connections using the addresses in hints and instead switch to the addresses in response to the TargetName query. Failure to use A and/or AAAA response addresses could negatively impact load balancing or other geo-aware features and thereby degrade client performance. The presentation value SHALL be a comma-separated list (Appendix A.1) of one or more IP addresses of the appropriate family in standard textual format [RFC5952][RFC4001]. To enable simpler parsing, this SvcParamValue MUST NOT contain escape sequences. The wire format for each parameter is a sequence of IP addresses in network byte order (for the respective address-family). Like an A or AAAA RRSet, the list of addresses represents an unordered collection, and clients SHOULD pick addresses to use in a random order. An empty list of addresses is invalid. When selecting between IPv4 and IPv6 addresses to use, clients may use an approach such as Happy Eyeballs [HappyEyeballsV2]. When only "ipv4hint" is present, NAT64 clients may synthesize IPv6 addresses as specified in [RFC7050] or ignore the "ipv4hint" key and wait for AAAA resolution (Section 3). For best performance, server operators SHOULD include an "ipv6hint" parameter whenever they include an "ipv4hint" parameter. These parameters are intended to minimize additional connection latency when a recursive resolver is not compliant with the requirements in Section 4, and SHOULD NOT be included if most clients Schwartz, et al. Expires 13 April 2023 [Page 25] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 are using compliant recursive resolvers. When TargetName is the origin hostname or the owner name (which can be written as "."), server operators SHOULD NOT include these hints, because they are unlikely to convey any performance benefit. 7.5. "mandatory" See Section 8. 8. ServiceMode RR compatibility and mandatory keys In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the RR will not function correctly for clients that ignore this SvcParamKey. Each SVCB protocol mapping SHOULD specify a set of keys that are "automatically mandatory", i.e. mandatory if they are present in an RR. The SvcParamKey "mandatory" is used to indicate any mandatory keys for this RR, in addition to any automatically mandatory keys that are present. A ServiceMode RR is considered "compatible" by a client if the client recognizes all the mandatory keys, and their values indicate that successful connection establishment is possible. If the SVCB RRSet contains no compatible RRs, the client will generally act as if the RRSet is empty. The presentation value SHALL be a comma-separated list (Appendix A.1) of one or more valid SvcParamKeys, either by their registered name or in the unknown-key format (Section 2.1). Keys MAY appear in any order, but MUST NOT appear more than once. For self-consistency (Section 2.4.3), listed keys MUST also appear in the SvcParams. To enable simpler parsing, this SvcParamValue MUST NOT contain escape sequences. For example, the following is a valid list of SvcParams: ech=... key65333=ex1 key65444=ex2 mandatory=key65444,ech In wire format, the keys are represented by their numeric values in network byte order, concatenated in strictly increasing numeric order. This SvcParamKey is always automatically mandatory, and MUST NOT appear in its own value-list. Other automatically mandatory keys SHOULD NOT appear in the list either. (Including them wastes space and otherwise has no effect.) Schwartz, et al. Expires 13 April 2023 [Page 26] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 9. Using Service Bindings with HTTP Use of any protocol with SVCB requires a protocol-specific mapping specification. This section specifies the mapping for the "http" and "https" URI schemes [HTTP]. To enable special handling for HTTP use-cases, the HTTPS RR type is defined as a SVCB-compatible RR type, specific to the "https" and "http" schemes. Clients MUST NOT perform SVCB queries or accept SVCB responses for "https" or "http" schemes. The presentation format of the record is: Name TTL IN HTTPS SvcPriority TargetName SvcParams All the SvcParamKeys defined in Section 7 are permitted for use in HTTPS RRs. The default set of ALPN IDs is the single value "http/1.1". The "automatically mandatory" keys (Section 8) are "port" and "no-default-alpn". (As described in Section 8, clients must either implement these keys or ignore any RR in which they appear.) Clients that restrict the destination port in "https" URIs (e.g. using the "bad ports" list from [FETCH]) SHOULD apply the same restriction to the "port" SvcParam. The presence of an HTTPS RR for an origin also indicates that clients should connect securely and use the "https" scheme, as discussed in Section 9.5. This allows HTTPS RRs to apply to pre-existing "http" scheme URLs, while ensuring that the client uses a secure and authenticated connection. The HTTPS RR parallels the concepts introduced in the HTTP Alternative Services proposed standard [AltSvc]. Clients and servers that implement HTTPS RRs are not required to implement Alt-Svc. 9.1. Query names for HTTPS RRs The HTTPS RR uses Port Prefix Naming (Section 2.3), with one modification: if the scheme is "https" and the port is 443, then the client's original QNAME is equal to the service name (i.e. the origin's hostname), without any prefix labels. By removing the Attrleaf labels [Attrleaf] used in SVCB, this construction enables offline DNSSEC signing of wildcard domains, which are commonly used with HTTP. Using the service name as the owner name of the HTTPS record, without prefixes, also allows the targets of existing CNAME chains (e.g. CDN hosts) to start returning HTTPS RR responses without requiring origin domains to configure and maintain an additional delegation. Schwartz, et al. Expires 13 April 2023 [Page 27] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 Following of HTTPS AliasMode RRs and CNAME aliases is unchanged from SVCB. Clients always convert "http" URLs to "https" before performing an HTTPS RR query using the process described in Section 9.5, so domain owners MUST NOT publish HTTPS RRs with a prefix of "_http". Note that none of these forms alter the HTTPS origin or authority. For example, clients MUST continue to validate TLS certificate hostnames based on the origin. 9.2. Comparison with Alt-Svc Publishing a ServiceMode HTTPS RR in DNS is intended to be similar to transmitting an Alt-Svc field value over HTTP, and receiving an HTTPS RR is intended to be similar to receiving that field value over HTTP. However, there are some differences in the intended client and server behavior. 9.2.1. ALPN usage Unlike Alt-Svc Field Values, HTTPS RRs can contain multiple ALPN IDs. The meaning and use of these IDs is discussed in Section 7.1.2. 9.2.2. Untrusted channel HTTPS records do not require or provide any assurance of authenticity. (DNSSEC signing and verification, which would provide such assurance, are OPTIONAL.) The DNS resolution process is modeled as an untrusted channel that might be controlled by an attacker, so Alt-Svc parameters that cannot be safely received in this model MUST NOT have a corresponding defined SvcParamKey. For example, there is no SvcParamKey corresponding to the Alt-Svc "persist" parameter, because this parameter is not safe to accept over an untrusted channel. 9.2.3. Cache lifetime There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age) parameter. Instead, server operators encode the expiration time in the DNS TTL. The appropriate TTL value might be different from the "ma" value used for Alt-Svc, depending on the desired efficiency and agility. Some DNS caches incorrectly extend the lifetime of DNS records beyond the stated TTL, so server operators cannot rely on HTTPS RRs expiring on time. Shortening the TTL to compensate for incorrect caching is NOT RECOMMENDED, as this practice impairs the performance of correctly Schwartz, et al. Expires 13 April 2023 [Page 28] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 functioning caches and does not guarantee faster expiration from incorrect caches. Instead, server operators SHOULD maintain compatibility with expired records until they observe that nearly all connections have migrated to the new configuration. 9.2.4. Granularity Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc Field Value specifically to the client. When using an HTTPS RR, groups of clients will necessarily receive the same SvcParams. Therefore, HTTPS RRs are not suitable for uses that require single- client granularity. 9.3. Interaction with Alt-Svc Clients that implement support for both Alt-Svc and HTTPS records and are making a connection based on a cached Alt-Svc response SHOULD retrieve any HTTPS records for the Alt-Svc alt-authority, and ensure that their connection attempts are consistent with both the Alt-Svc parameters and any received HTTPS SvcParams. If present, the HTTPS record's TargetName and port are used for connection establishment (as in Section 3). For example, suppose that "https://example.com" sends an Alt-Svc field value of: Alt-Svc: h2="alt.example:443", h2="alt2.example:443", h3=":8443" The client would retrieve the following HTTPS records: alt.example. IN HTTPS 1 . alpn=h2,h3 ech=... alt2.example. IN HTTPS 1 alt2b.example. alpn=h3 ech=... _8443._https.example.com. IN HTTPS 1 alt3.example. ( port=9443 alpn=h2,h3 ech=... ) Based on these inputs, the following connection attempts would always be allowed: * HTTP/2 to alt.example:443 * HTTP/3 to alt3.example:9443 * Fallback to the client's non-Alt-Svc connection behavior ECH-capable clients would use ECH when establishing any of these connections. The following connection attempts would not be allowed: * HTTP/3 to alt.example:443 (not consistent with Alt-Svc) Schwartz, et al. Expires 13 April 2023 [Page 29] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 * Any connection to alt2b.example (no ALPN consistent with both the HTTPS record and Alt-Svc) * HTTPS over TCP to any port on alt3.example (not consistent with Alt-Svc) The following Alt-Svc-only connection attempts would be allowed only if the client does not support ECH, as they rely on SVCB-optional fallback behavior that the client will disable if it implements support for ECH and the "ech" SvcParam is present (Section 10.1): * HTTP/2 to alt2.example:443 * HTTP/3 to example.com:8443 Origins that publish an "ech" SvcParam in their HTTPS record SHOULD also publish an HTTPS record with the "ech" SvcParam for every alt- authority offered in its Alt-Svc Field Values. Otherwise, clients might reveal the name of the server in an unencrypted ClientHello. Similar consistency considerations could apply to future SvcParamKeys, so alt-authorities SHOULD carry the same SvcParams as the origin unless a deviation is specifically known to be safe. As noted in Section 2.4 of [AltSvc], clients MAY disallow any Alt-Svc connection according to their own criteria, e.g. disallowing Alt-Svc connections that lack ECH support when there is an active ECH- protected connection for this origin. 9.4. Requiring Server Name Indication Clients MUST NOT use an HTTPS RR response unless the client supports TLS Server Name Indication (SNI) and indicates the origin name in the TLS ClientHello (which might be encrypted). This supports the conservation of IP addresses. Note that the TLS SNI (and also the HTTP "Host" or ":authority") will indicate the origin, not the TargetName. 9.5. HTTP Strict Transport Security An HTTPS RR directs the client to communicate with this host only over a secure transport, similar to HTTP Strict Transport Security [HSTS]. Prior to making an "http" scheme request, the client SHOULD perform a lookup to determine if any HTTPS RRs exist for that origin. To do so, the client SHOULD construct a corresponding "https" URL as follows: 1. Replace the "http" scheme with "https". Schwartz, et al. Expires 13 April 2023 [Page 30] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 2. If the "http" URL explicitly specifies port 80, specify port 443. 3. Do not alter any other aspect of the URL. This construction is equivalent to Section 8.3 of [HSTS], point 5. If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS RRs, or any compatible ServiceMode HTTPS RRs (see Section 8), the client SHOULD behave as if it has received an HTTP 307 (Temporary Redirect) status code with this "https" URL in the "Location" field. (Receipt of an incompatible ServiceMode RR does not trigger the redirect behavior.) Because HTTPS RRs are received over an often- insecure channel (DNS), clients MUST NOT place any more trust in this signal than if they had received a 307 (Temporary Redirect) response over cleartext HTTP. Publishing an HTTPS RR has the potential to have unexpected results or a loss in functionality in cases where the "http" resource neither redirects to the "https" resource nor references the same underlying resource. When an "https" connection fails due to an error in the underlying secure transport, such as an error in certificate validation, some clients currently offer a "user recourse" that allows the user to bypass the security error and connect anyway. When making an "https" scheme request to an origin with an HTTPS RR, either directly or via the above redirect, such a client MAY remove the user recourse option. Origins that publish HTTPS RRs therefore MUST NOT rely on user recourse for access. For more information, see Section 8.4 and Section 12.1 of [HSTS]. 9.6. Use of HTTPS RRs in other protocols All HTTP connections to named origins are eligible to use HTTPS RRs, even when HTTP is used as part of another protocol or without an explicit HTTP URL. For example, clients that support HTTPS RRs and implement the altered WebSocket [WebSocket] opening handshake from the W3C Fetch specification [FETCH] SHOULD use HTTPS RRs for the requestURL. When HTTP is used in a context where URLs or redirects are not applicable (e.g. connections to an HTTP proxy), clients that find a corresponding HTTPS RR SHOULD implement a security upgrade behavior equivalent to the one specified in Section 9.5. Such protocols MAY define their own SVCB mappings, which MAY be defined to take precedence over HTTPS RRs. Schwartz, et al. Expires 13 April 2023 [Page 31] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 10. SVCB/HTTPS RR parameter for ECH configuration The SVCB "ech" parameter is defined for conveying the ECH configuration of an alternative endpoint. In wire format, the value of the parameter is an ECHConfigList (Section 4 of [ECH]), including the redundant length prefix. In presentation format, the value is the ECHConfigList in Base 64 Encoding (Section 4 of [RFC4648]). Base 64 is used here to simplify integration with TLS server software. To enable simpler parsing, this SvcParam MUST NOT contain escape sequences. When ECH is in use, the TLS ClientHello is divided into an unencrypted "outer" and an encrypted "inner" ClientHello. The outer ClientHello is an implementation detail of ECH, and its contents are controlled by the ECHConfig in accordance with [ECH]. The inner ClientHello is used for establishing a connection to the service, so its contents may be influenced by other SVCB parameters. For example, the requirements on the ALPN protocol identifiers in Section 7.1 apply only to the inner ClientHello. Similarly, it is the inner ClientHello whose Server Name Indication identifies the desired service. 10.1. Client behavior The SVCB-optional client behavior specified in Section 3 permits clients to fall back to a direct connection if all SVCB options fail. This behavior is not suitable for ECH, because fallback would negate the privacy benefits of ECH. Accordingly, ECH-capable SVCB-optional clients MUST switch to SVCB-reliant connection establishment if SVCB resolution succeeded (following Section 3) and all alternative endpoints have an "ech" key. As a latency optimization, clients MAY prefetch DNS records that will only be used in SVCB-optional mode. 10.2. Deployment considerations An HTTPS RRSet containing some RRs with "ech" and some without is vulnerable to a downgrade attack. This configuration is NOT RECOMMENDED. Zone owners who do use such a mixed configuration SHOULD mark the RRs with "ech" as more preferred (i.e. lower SvcPriority value) than those without, in order to maximize the likelihood that ECH will be used in the absence of an active adversary. Schwartz, et al. Expires 13 April 2023 [Page 32] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 11. Zone Structures 11.1. Structuring zones for flexibility Each ServiceMode RRSet can only serve a single scheme. The scheme is indicated by the owner name and the RR type. For the generic SVCB RR type, this means that each owner name can only be used for a single scheme. The underscore prefixing requirement (Section 2.3) ensures that this is true for the initial query, but it is the responsibility of zone owners to choose names that satisfy this constraint when using aliases, including CNAME and AliasMode records. When using the generic SVCB RR type with aliasing, zone owners SHOULD choose alias target names that indicate the scheme in use (e.g. foosvc.example.net for foo:// schemes). This will help to avoid confusion when another scheme needs to be added to the configuration. When multiple port numbers are in use, it may be helpful to repeat the prefix labels in the alias target name (e.g. _1234._foo.svc.example.net). 11.2. Structuring zones for performance To avoid a delay for clients using a nonconforming recursive resolver, domain owners SHOULD minimize the use of AliasMode records, and SHOULD choose TargetName according to a predictable convention that is known to the client, so that clients can issue A and/or AAAA queries for TargetName in advance (see Section 5). Unless otherwise specified, the convention is to set TargetName to the service name for an initial ServiceMode record, or to "." if it is reached via an alias. $ORIGIN example.com. ; Origin foo 3600 IN CNAME foosvc.example.net. _8080._foo.foo 3600 IN CNAME foosvc.example.net. bar 300 IN AAAA 2001:db8::2 _9090._bar.bar 3600 IN SVCB 1 bar key65444=... $ORIGIN example.net. ; Service provider zone foosvc 3600 IN SVCB 1 . key65333=... foosvc 300 IN AAAA 2001:db8::1 Figure 1: foo://foo.example.com:8080 is delegated to foosvc.example.net, but bar://bar.example.com:9090 is served locally. Schwartz, et al. Expires 13 April 2023 [Page 33] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 Domain owners SHOULD avoid using a TargetName that is below a DNAME, as this is likely unnecessary and makes responses slower and larger. Also, zone structures that require following more than 8 aliases (counting both AliasMode and CNAME records) are NOT RECOMMENDED. 11.3. Operational considerations Note that some implementations may not allow A or AAAA records on names starting with an underscore due to various interpretations of RFCs. This could be an operational issue when the TargetName contains an attrleaf label, as well as using an TargetName of "." when the owner name contains an attrleaf label. 11.4. Examples 11.4.1. Protocol enhancements Consider a simple zone of the form: $ORIGIN simple.example. ; Simple example zone @ 300 IN A 192.0.2.1 AAAA 2001:db8::1 The domain owner could add this record: @ 7200 IN HTTPS 1 . alpn=h3 to indicate that https://simple.example supports QUIC in addition to HTTP/1.1 over TLS over TCP (the implicit default). The record could also include other information (e.g. non-standard port, ECH configuration). For https://simple.example:8443, the record would be: _8443._https 7200 IN HTTPS 1 . alpn=h3 These records also respectively tell clients to replace the scheme with "https" when loading http://simple.example or http://simple.example:8443. 11.4.2. Apex aliasing Consider a zone that is using CNAME aliasing: Schwartz, et al. Expires 13 April 2023 [Page 34] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 $ORIGIN aliased.example. ; A zone that is using a hosting service ; Subdomain aliased to a high-performance server pool www 7200 IN CNAME pool.svc.example. ; Apex domain on fixed IPs because CNAME is not allowed at the apex @ 300 IN A 192.0.2.1 IN AAAA 2001:db8::1 With HTTPS RRs, the owner of aliased.example could alias the apex by adding one additional record: @ 7200 IN HTTPS 0 pool.svc.example. With this record in place, HTTPS-RR-aware clients will use the same server pool for aliased.example and www.aliased.example. (They will also upgrade "http://aliased.example/..." to "https".) Non-HTTPS-RR- aware clients will just ignore the new record. Similar to CNAME, HTTPS RRs have no impact on the origin name. When connecting, clients will continue to treat the authoritative origins as "https://www.aliased.example" and "https://aliased.example", respectively, and will validate TLS server certificates accordingly. 11.4.3. Parameter binding Suppose that svc.example's primary server pool supports HTTP/3, but its backup server pool does not. This can be expressed in the following form: $ORIGIN svc.example. ; A hosting provider. pool 7200 IN HTTPS 1 . alpn=h2,h3 ech="123..." HTTPS 2 backup alpn=h2 ech="abc..." pool 300 IN A 192.0.2.2 AAAA 2001:db8::2 backup 300 IN A 192.0.2.3 AAAA 2001:db8::3 This configuration is entirely compatible with the "Apex aliasing" example, whether the client supports HTTPS RRs or not. If the client does support HTTPS RRs, all connections will be upgraded to HTTPS, and clients will use HTTP/3 if they can. Parameters are "bound" to each server pool, so each server pool can have its own protocol, ECH configuration, etc. Schwartz, et al. Expires 13 April 2023 [Page 35] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 11.4.4. Multi-CDN The HTTPS RR is intended to support HTTPS services operated by multiple independent entities, such as different Content Delivery Networks (CDNs) or different hosting providers. This includes the case where a service is migrated from one operator to another, as well as the case where the service is multiplexed between multiple operators for performance, redundancy, etc. This example shows such a configuration, with www.customer.example having different DNS responses to different queries, either over time or due to logic within the authoritative DNS server: ; This zone contains/returns different CNAME records ; at different points-in-time. The RRset for "www" can ; only ever contain a single CNAME. ; Sometimes the zone has: $ORIGIN customer.example. ; A Multi-CDN customer domain www 900 IN CNAME cdn1.svc1.example. ; and other times it contains: $ORIGIN customer.example. www 900 IN CNAME customer.svc2.example. ; and yet other times it contains: $ORIGIN customer.example. www 900 IN CNAME cdn3.svc3.example. ; With the following remaining constant and always included: $ORIGIN customer.example. ; A Multi-CDN customer domain ; The apex is also aliased to www to match its configuration @ 7200 IN HTTPS 0 www ; Non-HTTPS-aware clients use non-CDN IPs A 203.0.113.82 AAAA 2001:db8:203::2 ; Resolutions following the cdn1.svc1.example ; path use these records. ; This CDN uses a different alternative service for HTTP/3. $ORIGIN svc1.example. ; domain for CDN 1 cdn1 1800 IN HTTPS 1 h3pool alpn=h3 ech="123..." HTTPS 2 . alpn=h2 ech="123..." A 192.0.2.2 AAAA 2001:db8:192::4 h3pool 300 IN A 192.0.2.3 AAAA 2001:db8:192:7::3 Schwartz, et al. Expires 13 April 2023 [Page 36] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 ; Resolutions following the customer.svc2.example ; path use these records. ; Note that this CDN only supports HTTP/2. $ORIGIN svc2.example. ; domain operated by CDN 2 customer 300 IN HTTPS 1 . alpn=h2 ech="xyz..." 60 IN A 198.51.100.2 A 198.51.100.3 A 198.51.100.4 AAAA 2001:db8:198::7 AAAA 2001:db8:198::12 ; Resolutions following the cdn3.svc3.example ; path use these records. ; Note that this CDN has no HTTPS records ; and thus no ECH support. $ORIGIN svc3.example. ; domain operated by CDN 3 cdn3 60 IN A 203.0.113.8 AAAA 2001:db8:113::8 Note that in the above example, the different CDNs have different ECH configurations and different capabilities, but clients will use HTTPS RRs as a bound-together unit. Domain owners should be cautious when using a multi-CDN configuration, as it introduces a number of complexities highlighted by this example: * If CDN 1 supports ECH, and CDN 2 does not, the client is vulnerable to ECH downgrade by a network adversary who forces clients to get CDN 2 records. * Aliasing the apex to its subdomain simplifies the zone file but likely increases resolution latency, especially when using a non- HTTPS-aware recursive resolver. An alternative would be to alias the zone apex directly to a name managed by a CDN. * The A, AAAA, and HTTPS resolutions are independent lookups, so resolvers may observe and follow different CNAMEs to different CDNs. Clients may thus find that the A and AAAA responses do not correspond to the TargetName in the HTTPS response, and will need to perform additional queries to retrieve the correct IP addresses. Including ipv6hint and ipv4hint will reduce the performance impact of this case. Schwartz, et al. Expires 13 April 2023 [Page 37] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 * If not all CDNs publish HTTPS records, clients will sometimes receive NODATA for HTTPS queries (as with cdn3.svc3.example above), and thus no "ech" SvcParam, but could receive A/AAAA records from a different CDN which does support ECH. Clients will be unable to use ECH in this case. 11.4.5. Non-HTTP uses For protocols other than HTTP, the SVCB RR and an Attrleaf label [Attrleaf] will be used. For example, to reach an example resource of "baz://api.example.com:8765", the following SVCB record would be used to alias it to "svc4-baz.example.net." which in-turn could return AAAA/A records and/or SVCB records in ServiceMode: _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net. HTTPS RRs use similar Attrleaf labels if the origin contains a non- default port. 12. Interaction with other standards This standard is intended to reduce connection latency and improve user privacy. Server operators implementing this standard SHOULD also implement TLS 1.3 [RFC8446] and OCSP Stapling [RFC6066], both of which confer substantial performance and privacy benefits when used in combination with SVCB records. To realize the greatest privacy benefits, this proposal is intended for use over a privacy-preserving DNS transport (like DNS over TLS [DoT] or DNS over HTTPS [DoH]). However, performance improvements, and some modest privacy improvements, are possible without the use of those standards. Any specification for use of SVCB with a protocol MUST have an entry for its scheme under the SVCB RR type in the IANA DNS Underscore Global Scoped Entry Registry [Attrleaf]. The scheme MUST have an entry in the IANA URI Schemes Registry [RFC7595], and MUST have a defined specification for use with SVCB. 13. Security Considerations SVCB/HTTPS RRs permit distribution over untrusted channels, and clients are REQUIRED to verify that the alternative endpoint is authoritative for the service (similar to Section 2.1 of [AltSvc]). Therefore, DNSSEC signing and validation are OPTIONAL for publishing and using SVCB and HTTPS RRs. Schwartz, et al. Expires 13 April 2023 [Page 38] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 Clients MUST ensure that their DNS cache is partitioned for each local network, or flushed on network changes, to prevent a local adversary in one network from implanting a forged DNS record that allows them to track users or hinder their connections after they leave that network. An attacker who can prevent SVCB resolution can deny clients any associated security benefits. A hostile recursive resolver can always deny service to SVCB queries, but network intermediaries can often prevent resolution as well, even when the client and recursive resolver validate DNSSEC and use a secure transport. These downgrade attacks can prevent the "https" upgrade provided by the HTTPS RR (Section 9.5), and disable the encryption enabled by the "ech" SvcParamKey (Section 10). To prevent downgrades, Section 3.1 recommends that clients abandon the connection attempt when such an attack is detected. A hostile DNS intermediary might forge AliasMode "." records (Section 2.5.1) as a way to block clients from accessing particular services. Such an adversary could already block entire domains by forging erroneous responses, but this mechanism allows them to target particular protocols or ports within a domain. Clients that might be subject to such attacks SHOULD ignore AliasMode "." records. A hostile DNS intermediary or origin can return SVCB records indicating any IP address and port number, including IP addresses inside the local network and port numbers assigned to internal services. If the attacker can influence the client's payload (e.g. TLS session ticket contents), and an internal service has a sufficiently lax parser, it's possible that the attacker could gain unintended access. (The same concerns apply to SRV records, HTTP Alt-Svc, and HTTP redirects.) As a mitigation, SVCB mapping documents SHOULD indicate any port number restrictions that are appropriate for the supported transports. 14. Privacy Considerations Standard address queries reveal the user's intent to access a particular domain. This information is visible to the recursive resolver, and to many other parties when plaintext DNS transport is used. SVCB queries, like queries for SRV records and other specific RR types, additionally reveal the user's intent to use a particular protocol. This is not normally sensitive information, but it should be considered when adding SVCB support in a new context. Schwartz, et al. Expires 13 April 2023 [Page 39] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 15. IANA Considerations 15.1. SVCB RRType This document defines a new DNS RR type, SVCB, whose value 64 has been allocated by IANA from the "Resource Record (RR) TYPEs" registry on the "Domain Name System (DNS) Parameters" page: * Type: SVCB * Value: 64 * Meaning: General Purpose Service Binding * Reference: This document 15.2. HTTPS RRType This document defines a new DNS RR type, "HTTPS", whose value 65 has been allocated by IANA from the "Resource Record (RR) TYPEs" registry on the "Domain Name System (DNS) Parameters" page: * Type: HTTPS * Value: 65 * Meaning: Service Binding type for use with HTTP * Reference: This document 15.3. New registry for Service Parameters IANA is requested to create a new registry, entitled "Service Parameter Keys (SvcParamKeys)". This registry defines the namespace for parameters, including string representations and numeric SvcParamKey values. This registry is shared with other SVCB- compatible RR types, such as the HTTPS RR. ACTION: create this registry, on a new page entitled "DNS Service Bindings (SVCB)" under the "Domain Name System (DNS) Parameters" category. 15.3.1. Procedure A registration MUST include the following fields: * Number: wire format numeric identifier (range 0-65535) Schwartz, et al. Expires 13 April 2023 [Page 40] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 * Name: unique presentation name * Meaning: a short description * Format Reference: pointer to specification text * Change Controller: Person or entity, with contact information if appropriate. The characters in the registered Name MUST be lower-case alphanumeric or "-" (Section 2.1). The name MUST NOT start with "key" or "invalid". New entries in this registry are subject to an Expert Review registration policy ([RFC8126], Section 4.5). The designated expert MUST ensure that the Format Reference is stable and publicly available, and that it specifies how to convert the SvcParamValue's presentation format to wire format. The Format Reference MAY be any individual's Internet-Draft, or a document from any other source with similar assurances of stability and availability. An entry MAY specify a Format Reference of the form "Same as (other key Name)" if it uses the same presentation and wire formats as an existing key. This arrangement supports the development of new parameters while ensuring that zone files can be made interoperable. 15.3.2. Initial contents The "Service Binding (SVCB) Parameter Registry" shall initially be populated with the registrations below: Schwartz, et al. Expires 13 April 2023 [Page 41] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 +=============+=================+=============+=========+===========+ | Number | Name |Meaning |Format |Change | | | | |Reference|Controller | +=============+=================+=============+=========+===========+ | 0 | mandatory |Mandatory |(This |IETF | | | |keys in this |document)| | | | |RR |Section 8| | +-------------+-----------------+-------------+---------+-----------+ | 1 | alpn |Additional |(This |IETF | | | |supported |document)| | | | |protocols |Section | | | | | |7.1 | | +-------------+-----------------+-------------+---------+-----------+ | 2 | no-default-alpn |No support |(This |IETF | | | |for default |document)| | | | |protocol |Section | | | | | |7.1 | | +-------------+-----------------+-------------+---------+-----------+ | 3 | port |Port for |(This |IETF | | | |alternative |document)| | | | |endpoint |Section | | | | | |7.2 | | +-------------+-----------------+-------------+---------+-----------+ | 4 | ipv4hint |IPv4 address |(This |IETF | | | |hints |document)| | | | | |Section | | | | | |7.4 | | +-------------+-----------------+-------------+---------+-----------+ | 5 | ech |Encrypted |(This |IETF | | | |ClientHello |document)| | | | |info |Section | | | | | |7.3 | | +-------------+-----------------+-------------+---------+-----------+ | 6 | ipv6hint |IPv6 address |(This |IETF | | | |hints |document)| | | | | |Section | | | | | |7.4 | | +-------------+-----------------+-------------+---------+-----------+ | 65280-65534 | N/A |Private Use |(This |IETF | | | | |document)| | +-------------+-----------------+-------------+---------+-----------+ | 65535 | N/A |Reserved |(This |IETF | | | |("Invalid |document)| | | | |key") | | | +-------------+-----------------+-------------+---------+-----------+ Table 1 Schwartz, et al. Expires 13 April 2023 [Page 42] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 15.4. Other registry updates Per [Attrleaf], please add the following entry to the DNS Underscore Global Scoped Entry Registry: +=========+============+=================+=================+ | RR TYPE | _NODE NAME | Meaning | Reference | +=========+============+=================+=================+ | HTTPS | _https | HTTPS SVCB info | (This document) | +---------+------------+-----------------+-----------------+ Table 2 16. Acknowledgments and Related Proposals There have been a wide range of proposed solutions over the years to the "CNAME at the Zone Apex" challenge proposed. These include [I-D.bellis-dnsop-http-record], [I-D.ietf-dnsop-aname], and others. Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David Benjamin, Mark Andrews, Emily Stark, Eric Orth, Kyle Rose, Craig Taylor, Dan McArdle, Brian Dickson, Willem Toorop, Pieter Lexis, Puneet Sood, Olivier Poitrey, Mashooq Muhaimen, Tom Carpay, and many others for their feedback and suggestions on this draft. 17. References 17.1. Normative References [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . [Attrleaf] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, . [DoH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [DoT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . Schwartz, et al. Expires 13 April 2023 [Page 43] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-15, 3 October 2022, . [HappyEyeballsV2] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Semantics", Work in Progress, Internet-Draft, draft-ietf- httpbis-semantics-19, 12 September 2021, . [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, DOI 10.17487/RFC1928, March 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, DOI 10.17487/RFC3225, December 2001, . [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, . Schwartz, et al. Expires 13 April 2023 [Page 44] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, . [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, . Schwartz, et al. Expires 13 April 2023 [Page 45] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [WebSocket] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, . 17.2. Informative References [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, . [DNAME] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, . [DNSTerm] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . [FETCH] "Fetch Living Standard", May 2020, . [HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, DOI 10.17487/RFC6797, November 2012, . Schwartz, et al. Expires 13 April 2023 [Page 46] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 [HTTP3] Bishop, M., "HTTP/3", Work in Progress, Internet-Draft, draft-ietf-quic-http-34, 2 February 2021, . [I-D.bellis-dnsop-http-record] Bellis, R., "A DNS Resource Record for HTTP", Work in Progress, Internet-Draft, draft-bellis-dnsop-http-record- 00, 3 November 2018, . [I-D.ietf-dnsop-aname] Finch, T., Hunt, E., van Dijk, P., Eden, A., and W. M. Mekking, "Address-specific DNS aliases (ANAME)", Work in Progress, Internet-Draft, draft-ietf-dnsop-aname-04, 8 July 2019, . [RFC1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996, . [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, . [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, . [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . Appendix A. Decoding text in zone files DNS zone files are capable of representing arbitrary octet sequences in basic ASCII text, using various delimiters and encodings. The algorithm for decoding these character-strings is defined in Section 5.1 of [RFC1035]. Here we summarize the allowed input to that algorithm, using ABNF: Schwartz, et al. Expires 13 April 2023 [Page 47] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 ; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\". non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E ; non-digit is VCHAR minus DIGIT non-digit = %x21-2F / %x3A-7E ; dec-octet is a number 0-255 as a three-digit decimal number. dec-octet = ( "0" / "1" ) 2DIGIT / "2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) ) escaped = "\" ( non-digit / dec-octet ) contiguous = 1*( non-special / escaped ) quoted = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE char-string = contiguous / quoted The decoding algorithm allows char-string to represent any *OCTET, using quoting to group values (e.g., those with internal whitespace), and escaping to represent each non-printable octet as a single escaped sequence. In this document, this algorithm is referred to as "character-string decoding". The algorithm is the same as used by in RFC 1035, although the output length in this document is not limited to 255 octets. A.1. Decoding a comma-separated list In order to represent lists of items in zone files, this specification uses comma-separated lists. When the allowed items in the list cannot contain "," or "\", this is trivial. (For simplicity, empty items are not allowed.) A value-list parser that splits on "," and prohibits items containing "\" is sufficient to comply with all requirements in this document. This corresponds to the simple-comma-separated syntax: ; item-allowed is OCTET minus "," and "\". item-allowed = %x00-2B / %x2D-5B / %x5D-FF simple-item = 1*item-allowed simple-comma-separated = [simple-item *("," simple-item)] For implementations that allow "," and "\" in item values, the following escaping syntax applies: item = 1*OCTET escaped-item = 1*(item-allowed / "\," / "\\") comma-separated = [escaped-item *("," escaped-item)] Decoding of value-lists happens after character-string decoding. For example, consider these char-string SvcParamValues: "part1,part2,part3\\,part4\\\\" part1\,\p\a\r\t2\044part3\092,part4\092\\ Schwartz, et al. Expires 13 April 2023 [Page 48] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 These inputs are equivalent: character-string decoding either of them would produce the same value: part1,part2,part3\,part4\\ Applying comma-separated list decoding to this value would produce a list of three items: part1 part2 part3,part4\ Appendix B. HTTP Mapping Summary This table serves as a non-normative summary of the HTTP mapping for SVCB (Section 9). Future protocol mappings may provide a similar summary table. +==========================+======================+ +==========================+======================+ | *Mapped scheme* | "https" | +--------------------------+----------------------+ | *Other affected schemes* | "http", "wss", "ws", | | | (other HTTP-based) | +--------------------------+----------------------+ | *RR type* | HTTPS (65) | +--------------------------+----------------------+ | *Name prefix* | None for port 443, | | | else _$PORT._https | +--------------------------+----------------------+ | *Automatically Mandatory | port, no-default- | | Keys* | alpn | +--------------------------+----------------------+ | *SvcParam defaults* | alpn: ["http/1.1"] | +--------------------------+----------------------+ | *Special behaviors* | HTTP to HTTPS | | | upgrade | +--------------------------+----------------------+ | *Keys that records must | None | | include* | | +--------------------------+----------------------+ Table 3 Schwartz, et al. Expires 13 April 2023 [Page 49] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 Appendix C. Comparison with alternatives The SVCB and HTTPS RR types closely resemble, and are inspired by, some existing record types and proposals. A complaint with all of the alternatives is that web clients have seemed unenthusiastic about implementing them. The hope here is that by providing an extensible solution that solves multiple problems we will overcome the inertia and have a path to achieve client implementation. C.1. Differences from the SRV RR type An SRV record [SRV] can perform a similar function to the SVCB record, informing a client to look in a different location for a service. However, there are several differences: * SRV records are typically mandatory, whereas SVCB is intended to be optional when used with pre-existing protocols. * SRV records cannot instruct the client to switch or upgrade protocols, whereas SVCB can signal such an upgrade (e.g. to HTTP/2). * SRV records are not extensible, whereas SVCB and HTTPS RRs can be extended with new parameters. * SRV records specify a "weight" for unbalanced randomized load- balancing. SVCB only supports balanced randomized load-balancing, although weights could be added via a future SvcParam. C.2. Differences from the proposed HTTP record Unlike [I-D.bellis-dnsop-http-record], this approach is extensible to cover Alt-Svc and Encrypted ClientHello use-cases. Like that proposal, this addresses the zone apex CNAME challenge. Like that proposal, it remains necessary to continue to include address records at the zone apex for legacy clients. C.3. Differences from the proposed ANAME record Unlike [I-D.ietf-dnsop-aname], this approach is extensible to cover Alt-Svc and ECH use-cases. This approach also does not require any changes or special handling on either authoritative or primary servers, beyond optionally returning in-bailiwick additional records. Like that proposal, this addresses the zone apex CNAME challenge for clients that implement this. Schwartz, et al. Expires 13 April 2023 [Page 50] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 However, with this SVCB proposal, it remains necessary to continue to include address records at the zone apex for legacy clients. If deployment of this standard is successful, the number of legacy clients will fall over time. As the number of legacy clients declines, the operational effort required to serve these users without the benefit of SVCB indirection should fall. Server operators can easily observe how much traffic reaches this legacy endpoint, and may remove the apex's address records if the observed legacy traffic has fallen to negligible levels. C.4. Comparison with separate RR types for AliasMode and ServiceMode Abstractly, functions of AliasMode and ServiceMode are independent, so it might be tempting to specify them as separate RR types. However, this would result in a serious performance impairment, because clients cannot rely on their recursive resolver to follow SVCB aliases (unlike CNAME). Thus, clients would have to issue queries for both RR types in parallel, potentially at each step of the alias chain. Recursive resolvers that implement the specification would, upon receipt of a ServiceMode query, emit both a ServiceMode and an AliasMode query to the authoritative. Thus, splitting the RR type would double, or in some cases triple, the load on clients and servers, and would not reduce implementation complexity. Appendix D. Test vectors These test vectors only contain the RDATA portion of SVCB/HTTPS records in presentation format, generic format ([RFC3597]) and wire format. The wire format uses hexadecimal (\xNN) for each non-ascii byte. As the wireformat is long, it is broken into several lines. D.1. AliasMode example.com. HTTPS 0 foo.example.com. \# 19 ( 00 00 ; priority 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target ) \x00\x00 # priority \x03foo\x07example\x03com\x00 # target Figure 2: AliasMode D.2. ServiceMode Schwartz, et al. Expires 13 April 2023 [Page 51] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 example.com. SVCB 1 . \# 3 ( 00 01 ; priority 00 ; target (root label) ) \x00\x01 # priority \x00 # target, root label Figure 3: TargetName is "." example.com. SVCB 16 foo.example.com. port=53 \# 25 ( 00 10 ; priority 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 00 03 ; key 3 00 02 ; length 2 00 35 ; value ) \x00\x10 # priority \x03foo\x07example\x03com\x00 # target \x00\x03 # key 3 \x00\x02 # length: 2 bytes \x00\x35 # value Figure 4: Specifies a port example.com. SVCB 1 foo.example.com. key667=hello \# 28 ( 00 01 ; priority 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 02 9b ; key 667 00 05 ; length 5 68 65 6c 6c 6f ; value ) \x00\x01 # priority \x03foo\x07example\x03com\x00 # target \x02\x9b # key 667 \x00\x05 # length 5 hello # value Figure 5: A generic key and unquoted value Schwartz, et al. Expires 13 April 2023 [Page 52] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 example.com. SVCB 1 foo.example.com. key667="hello\210qoo" \# 32 ( 00 01 ; priority 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 02 9b ; key 667 00 09 ; length 9 68 65 6c 6c 6f d2 71 6f 6f ; value ) \x00\x01 # priority \x03foo\x07example\x03com\x00 # target \x02\x9b # key 667 \x00\x09 # length 9 hello\xd2qoo # value Figure 6: A generic key and quoted value with a decimal escape example.com. SVCB 1 foo.example.com. ( ipv6hint="2001:db8::1,2001:db8::53:1" ) \# 55 ( 00 01 ; priority 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 00 06 ; key 6 00 20 ; length 32 20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01 ; first address 20 01 0d b8 00 00 00 00 00 00 00 00 00 53 00 01 ; second address ) \x00\x01 # priority \x03foo\x07example\x03com\x00 # target \x00\x06 # key 6 \x00\x20 # length 32 \x20\x01\x0d\xb8\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x01 # first address \x20\x01\x0d\xb8\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x53\x00\x01 # second address Figure 7: Two quoted IPv6 hints Schwartz, et al. Expires 13 April 2023 [Page 53] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 example.com. SVCB 1 example.com. ipv6hint="2001:db8:122:344::192.0.2.33" \# 35 ( 00 01 ; priority 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 00 06 ; key 6 00 10 ; length 16 20 01 0d b8 01 22 03 44 00 00 00 00 c0 00 02 21 ; address ) \x00\x01 # priority \x07example\x03com\x00 # target \x00\x06 # key 6 \x00\x10 # length 16 \x20\x01\x0d\xb8\x01\x22\x03\x44 \x00\x00\x00\x00\xc0\x00\x02\x21 # address Figure 8: An IPv6 hint using the embedded IPv4 syntax Schwartz, et al. Expires 13 April 2023 [Page 54] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 example.com. SVCB 16 foo.example.org. ( alpn=h2,h3-19 mandatory=ipv4hint,alpn ipv4hint=192.0.2.1 ) \# 48 ( 00 10 ; priority 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target 00 00 ; key 0 00 04 ; param length 4 00 01 ; value: key 1 00 04 ; value: key 4 00 01 ; key 1 00 09 ; param length 9 02 ; alpn length 2 68 32 ; alpn value 05 ; alpn length 5 68 33 2d 31 39 ; alpn value 00 04 ; key 4 00 04 ; param length 4 c0 00 02 01 ; param value ) \x00\x10 # priority \x03foo\x07example\x03org\x00 # target \x00\x00 # key 0 \x00\x04 # param length 4 \x00\x01 # value: key 1 \x00\x04 # value: key 4 \x00\x01 # key 1 \x00\x09 # param length 9 \x02 # alpn length 2 h2 # alpn value \x05 # alpn length 5 h3-19 # alpn value \x00\x04 # key 4 \x00\x04 # param length 4 \xc0\x00\x02\x01 # param value Figure 9: SvcParamKey ordering is arbitrary in presentation format but sorted in wire format Schwartz, et al. Expires 13 April 2023 [Page 55] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 example.com. SVCB 16 foo.example.org. alpn="f\\\\oo\\,bar,h2" example.com. SVCB 16 foo.example.org. alpn=f\\\092oo\092,bar,h2 \# 35 ( 00 10 ; priority 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target 00 01 ; key 1 00 0c ; param length 12 08 ; alpn length 8 66 5c 6f 6f 2c 62 61 72 ; alpn value 02 ; alpn length 2 68 32 ; alpn value ) \x00\x10 # priority \x03foo\x07example\x03org\x00 # target \x00\x01 # key 1 \x00\x0c # param length 12 \x08 # alpn length 8 f\oo,bar # alpn value \x02 # alpn length 2 h2 # alpn value Figure 10: An alpn value with an escaped comma and an escaped backslash in two presentation formats D.3. Failure cases This subsection contains test vectors which are not compliant with this document. The various reasons for non-compliance are explained with each example. example.com. SVCB 1 foo.example.com. ( key123=abc key123=def ) Figure 11: Multiple instances of the same SvcParamKey example.com. SVCB 1 foo.example.com. mandatory example.com. SVCB 1 foo.example.com. alpn example.com. SVCB 1 foo.example.com. port example.com. SVCB 1 foo.example.com. ipv4hint example.com. SVCB 1 foo.example.com. ipv6hint Figure 12: Missing SvcParamValues that must be nonempty example.com. SVCB 1 foo.example.com. no-default-alpn=abc Schwartz, et al. Expires 13 April 2023 [Page 56] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 Figure 13: The "no-default-alpn" SvcParamKey value must be empty example.com. SVCB 1 foo.example.com. mandatory=key123 Figure 14: A mandatory SvcParam is missing example.com. SVCB 1 foo.example.com. mandatory=mandatory Figure 15: The "mandatory" SvcParamKey must not be included in the mandatory list example.com. SVCB 1 foo.example.com. ( mandatory=key123,key123 key123=abc ) Figure 16: Multiple instances of the same SvcParamKey in the mandatory list Appendix E. Change history (This section to be removed by the RFC editor.) * draft-ietf-dnsop-svcb-https-11 - Narrow set of post-IESG clarifications: o Clarify that that the fallback addition of the QNAME was for the AliasMode case o Note that some implementations may not allow A/AAAA records on names starting with an underscore * draft-ietf-dnsop-svcb-https-10 - Clarify rationale for two recommendations * draft-ietf-dnsop-svcb-https-09 - Extensive adjustments based on IESG reviews, including: o IANA registry changed to Expert Review policy o Adjustments to the use of normative language o Revised and expanded description of HSTS behavior o Expanded discussion of CNAME handling Schwartz, et al. Expires 13 April 2023 [Page 57] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 o Discussion of SvcParams in AliasMode records o Restructured ABNF for comma-separated lists o Additional references and many other minor clarifications - Other changes include: o New section on interaction with DNS64 o New text on the interpretation of wildcard owner names o Adjusted guidance on default ALPN enforcement o Removed mention of IPv4-mapped IPv6 * draft-ietf-dnsop-svcb-https-08 - Extensive structural and editorial adjustments based on area reviews, including: o A new section on SVCB-compatible record types o Reorganized description of client behavior o Test vectors are now in titled figures o Adjusted mapping summary o Improve description of rules for resolver handling of invalid SvcParamValues. - New text on cross-transport fallback (e.g. QUIC vs. TCP) - Improved explanation of use with domain-oriented transport proxies - HTTP terminology adjusted to match draft-ietf-httpbis-semantics - Improved and corrected IANA instructions * draft-ietf-dnsop-svcb-https-07 - Editorial improvements following AD review. * draft-ietf-dnsop-svcb-https-06 - Add requirements for HTTPS origins that also use Alt-Svc Schwartz, et al. Expires 13 April 2023 [Page 58] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 - Remove requirement for comma-escaping related to unusual ALPN values - Allow resolvers to reject invalid SvcParamValues, with additional guidance * draft-ietf-dnsop-svcb-https-05 - Specify interaction with EDNS Client Subnet and Additional section caching - Rename "echconfig" to "ech" - Add a suite of test vectors (both valid and invalid) and more examples - Clarify requirements for resolvers' (non-)use of SvcParams - Clarify guidance regarding default ALPN values * draft-ietf-dnsop-svcb-https-04 - Simplify the IANA instructions (pure First Come First Served) - Recommend against publishing chains of >8 aliases - Clarify requirements for using SVCB with a transport proxy - Adjust guidance for Port Prefix Naming - Minor editorial updates * draft-ietf-dnsop-svcb-https-03 - Simplified escaping of comma-separated values - Reorganized client requirements - Added a warning about port filtering for cross-protocol attacks - Clarified self-consistency rules for SvcParams - Added a non-normative mapping summary table for HTTPS * draft-ietf-dnsop-svcb-https-02 - Added a Privacy Considerations section Schwartz, et al. Expires 13 April 2023 [Page 59] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 - Adjusted resolution fallback description - Clarified status of SvcParams in AliasMode - Improved advice on zone structuring and use with Alt-Svc - Improved examples, including a new Multi-CDN example - Reorganized text on value-list parsing and SvcPriority - Improved phrasing and other editorial improvements throughout * draft-ietf-dnsop-svcb-https-01 - Added a "mandatory" SvcParamKey - Added the ability to indicate that a service does not exist - Adjusted resolution and ALPN algorithms - Major terminology revisions for "origin" and CamelCase names - Revised ABNF - Include allocated RR type numbers - Various corrections, explanations, and recommendations * draft-ietf-dnsop-svcb-https-00 - Rename HTTPSSVC RR to HTTPS RR - Rename "an SVCB" to "a SVCB" - Removed "design considerations and open issues" section and some other "to be removed" text * draft-ietf-dnsop-svcb-httpssvc-03 - Revised chain length limit requirements - Revised IANA registry rules for SvcParamKeys - Require HTTPS clients to implement SNI - Update terminology for Encrypted ClientHello Schwartz, et al. Expires 13 April 2023 [Page 60] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 - Clarifications: non-default ports, transport proxies, HSTS procedure, WebSocket behavior, wire format, IP hints, inner/ outer ClientHello with ECH - Various textual and ABNF corrections * draft-ietf-dnsop-svcb-httpssvc-02 - All changes to Alt-Svc have been removed - Expanded and reorganized examples - Priority zero is now the definition of AliasForm - Repeated SvcParamKeys are no longer allowed - The "=" sign may be omitted in a key=value pair if the value is also empty - In the wire format, SvcParamKeys must be in sorted order - New text regarding how to handle resolution timeouts - Expanded description of recursive resolver behavior - Much more precise description of the intended ALPN behavior - Match the HSTS specification's language on HTTPS enforcement - Removed 'esniconfig=""' mechanism and simplified ESNI connection logic * draft-ietf-dnsop-svcb-httpssvc-01 - Reduce the emphasis on conversion between HTTPSSVC and Alt-Svc - Make the "untrusted channel" concept more precise. - Make SvcFieldPriority = 0 the definition of AliasForm, instead of a requirement. * draft-ietf-dnsop-svcb-httpssvc-00 - Document an optimization for optimistic pre-connection. (Chris Wood) - Relax IP hint handling requirements. (Eric Rescorla) Schwartz, et al. Expires 13 April 2023 [Page 61] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 * draft-nygren-dnsop-svcb-httpssvc-00 - Generalize to an SVCB record, with special-case handling for Alt-Svc and HTTPS separated out to dedicated sections. - Split out a separate HTTPSSVC record for the HTTPS use-case. - Remove the explicit SvcRecordType=0/1 and instead make the AliasForm vs ServiceForm be implicit. This was based on feedback recommending against subtyping RR type. - Remove one optimization. * draft-nygren-httpbis-httpssvc-03 - Change redirect type for HSTS-style behavior from 302 to 307 to reduce ambiguities. * draft-nygren-httpbis-httpssvc-02 - Remove the redundant length fields from the wire format. - Define a SvcDomainName of "." for SvcRecordType=1 as being the HTTPSSVC RRNAME. - Replace "hq" with "h3". * draft-nygren-httpbis-httpssvc-01 - Fixes of record name. Replace references to "HTTPSVC" with "HTTPSSVC". * draft-nygren-httpbis-httpssvc-00 - Initial version Authors' Addresses Ben Schwartz Google Email: bemasc@google.com Mike Bishop Akamai Technologies Email: mbishop@evequefou.be Schwartz, et al. Expires 13 April 2023 [Page 62] Internet-Draft SVCB and HTTPS RRs for DNS October 2022 Erik Nygren Akamai Technologies Email: erik+ietf@nygren.org Schwartz, et al. Expires 13 April 2023 [Page 63] ./draft-ietf-quic-version-negotiation-14.txt0000644000764400076440000012513214350144644020624 0ustar iustiniustin QUIC D. Schinazi Internet-Draft Google LLC Updates: 8999 (if approved) E. Rescorla Intended status: Standards Track Mozilla Expires: 22 June 2023 19 December 2022 Compatible Version Negotiation for QUIC draft-ietf-quic-version-negotiation-14 Abstract QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client chose is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. This document updates RFC 8999. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://quicwg.github.io/version-negotiation/draft-ietf-quic-version- negotiation.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-quic-version- negotiation/. Discussion of this document takes place on the QUIC Working Group mailing list (mailto:quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Subscribe at https://www.ietf.org/mailman/listinfo/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/version-negotiation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Schinazi & Rescorla Expires 22 June 2023 [Page 1] Internet-Draft QUIC Compatible VN December 2022 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Version Negotiation Mechanism . . . . . . . . . . . . . . . . 4 2.1. Incompatible Version Negotiation . . . . . . . . . . . . 5 2.2. Compatible Versions . . . . . . . . . . . . . . . . . . . 5 2.3. Compatible Version Negotiation . . . . . . . . . . . . . 6 2.4. Connections and Version Negotiation . . . . . . . . . . . 8 2.5. Client Choice of Original Version . . . . . . . . . . . . 8 3. Version Information . . . . . . . . . . . . . . . . . . . . . 9 4. Version Downgrade Prevention . . . . . . . . . . . . . . . . 10 5. Server Deployments of QUIC . . . . . . . . . . . . . . . . . 12 6. Application Layer Protocol Considerations . . . . . . . . . . 14 7. Considerations for Future Versions . . . . . . . . . . . . . 14 7.1. Interaction with Retry . . . . . . . . . . . . . . . . . 15 7.2. Interaction with TLS resumption . . . . . . . . . . . . . 15 7.3. Interaction with 0-RTT . . . . . . . . . . . . . . . . . 15 8. Special Handling for QUIC Version 1 . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10.1. QUIC Transport Parameter . . . . . . . . . . . . . . . . 16 10.2. QUIC Transport Error Code . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 17 Schinazi & Rescorla Expires 22 June 2023 [Page 2] Internet-Draft QUIC Compatible VN December 2022 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The version-invariant properties of QUIC [QUIC-INVARIANTS] define a Version Negotiation packet but do not specify how an endpoint reacts when it receives one. QUIC version 1 [QUIC] allows the server to use a Version Negotiation packet to indicate that the version the client chose is unacceptable, but doesn't allow the client to safely make use of that information to create a new connection with a mutually supported version. This document updates [QUIC-INVARIANTS] by defining version negotiation mechanisms that leverage the Version Negotiation packet. With proper safety mechanisms in place, the Version Negotiation packet can be part of a mechanism to allow two QUIC implementations to negotiate between two totally disjoint versions of QUIC. This document specifies version negotiation using Version Negotiation packets, which adds an extra round trip to connection establishment if needed. It is beneficial to avoid additional round trips whenever possible, especially given that most incremental versions are broadly similar to the previous version. This specification also defines a simple version negotiation mechanism which leverages similarities between versions and can negotiate between "compatible" versions without additional round trips. 1.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Definitions The document uses the following terms: * In the context of a given QUIC connection, the "first flight" of packets refers to the set of packets the client creates and sends to initiate the connection before it has heard back from the server. * In the context of a given QUIC connection, the "client's chosen version" is the QUIC version of the connection's first flight. Schinazi & Rescorla Expires 22 June 2023 [Page 3] Internet-Draft QUIC Compatible VN December 2022 * The "original version" is the QUIC version of the very first packet the client sends to the server. If version negotiation spans multiple connections (see Section 2.4), the original version is equal to the client's chosen version of the first QUIC connection. * The "negotiated version" is the QUIC version in use on the connection once the version negotiation process completes. * The "Maximum Segment Lifetime" (MSL) represents the time a QUIC packet can exist in the network. Implementations can make this configurable, and a RECOMMENDED value is one minute. Note that the term "segment" here originated in Section 3.4.1 of [TCP]. 2. Version Negotiation Mechanism This document specifies two means of performing version negotiation: one "incompatible" which requires a round trip and is applicable to all versions, and one "compatible" that allows saving the round trip but only applies when the versions are compatible (see Section 2.2). The client initiates a QUIC connection by choosing an original version and sending a first flight of QUIC packets with a long header to the server [QUIC-INVARIANTS]. The client's first flight includes Version Information (see Section 3) which will be used to optionally enable compatible version negotiation (see Section 2.3), and to prevent version downgrade attacks (see Section 4). Upon receiving this first flight, the server verifies whether it knows how to parse first flights from the original version. If it does not, then it starts incompatible version negotiation, see Section 2.1, which causes the client to initiate a new connection with a different version. For instance, if the client initiates a connection with version A and the server starts incompatible version negotiation and the client then initiates a new connection with version B, we say that the first connection's client chosen version is A, the second connection's client chosen version is B, and the original version for the entire sequence is A. If the server can parse the first flight, it can either establish the connection using the client's chosen version, or it MAY select any other compatible version, as described in Section 2.3. Note that it is possible for a server to have the ability to parse the first flight of a given version without fully supporting it, in the sense that it implements enough of the version's specification to parse first flight packets but not enough to fully establish a connection using that version. Schinazi & Rescorla Expires 22 June 2023 [Page 4] Internet-Draft QUIC Compatible VN December 2022 2.1. Incompatible Version Negotiation The server starts incompatible version negotiation by sending a Version Negotiation packet. This packet SHALL include each entry from the server's set of Offered Versions (see Section 5) in a Supported Version field. The server MAY add reserved versions (as defined in Section 6.3 of [QUIC]) in Supported Version fields. Clients will ignore a Version Negotiation packet if it contains the original version attempted by the client; see Section 4. The client also ignores a Version Negotiation packet that contains incorrect connection ID fields; see Section 6 of [QUIC-INVARIANTS]. Upon receiving the Version Negotiation packet, the client SHALL search for a version it supports in the list provided by the server. If it doesn't find one, it SHALL abort the connection attempt. Otherwise, it SHALL select a mutually supported version and send a new first flight with that version - this version is now the negotiated version. The new first flight will allow the endpoints to establish a connection using the negotiated version. The handshake of the negotiated version will exchange version information (see Section 3) required to ensure that version negotiation was genuine, i.e. that no attacker injected packets in order to influence the version negotiation process, see Section 4. Only servers can start incompatible version negotiation: clients MUST NOT send Version Negotiation packets and servers MUST ignore all received Version Negotiation packets. 2.2. Compatible Versions If A and B are two distinct versions of QUIC, A is said to be "compatible" with B if it is possible to take a first flight of packets from version A and convert it into a first flight of packets from version B. As an example, if versions A and B are absolutely equal in their wire image and behavior during the handshake but differ after the handshake, then A is compatible with B and B is compatible with A. Note that the conversion of the first flight can be lossy: some data such as QUIC version 1 0-RTT packets could be ignored during conversion and retransmitted later. Schinazi & Rescorla Expires 22 June 2023 [Page 5] Internet-Draft QUIC Compatible VN December 2022 Version compatibility is not symmetric: it is possible for version A to be compatible with version B and for B not to be compatible with A. This could happen for example if version B is a strict superset of version A: if version A includes the concept of streams and STREAM frames, and version B includes the concept of streams and the hypothetical concept of tubes along with STREAM and TUBE frames, then A would be compatible with B but B would not be compatible with A. Note that version compatibility does not mean that every single possible instance of a first flight will succeed in conversion to the other version. A first flight using version A is said to be "compatible" with version B if two conditions are met: first that version A is compatible with version B, and second that the conversion of this first flight to version B is well-defined. For example, if version B is equal to A in all aspects except it introduced a new frame in its first flight that version A cannot parse or even ignore, then B could still be compatible with A as conversions would succeed for connections where that frame is not used. In this example, first flights using version B that carry this new frame would not be compatible with version A. When a new version of QUIC is defined, it is assumed to not be compatible with any other version unless otherwise specified. Similarly, no other version is compatible with the new version unless otherwise specified. Implementations MUST NOT assume compatibility between versions unless explicitly specified. Note that both endpoints might disagree on whether two versions are compatible or not. For example, two versions could have been defined concurrently and then specified as compatible in a third document much later - in that scenario one endpoint might be aware of the compatibility document while the other may not. 2.3. Compatible Version Negotiation When the server can parse the client's first flight using the client's chosen version, it can extract the client's Version Information structure (see Section 3). This contains the list of versions that the client knows its first flight is compatible with. In order to perform compatible version negotiation, the server MUST select one of these versions that (1) it supports and (2) it knows the client's chosen version to be compatible with. This selected version is now the negotiated version. After selecting it, the server attempts to convert the client's first flight into that version, and replies to the client as if it had received the converted first flight. Schinazi & Rescorla Expires 22 June 2023 [Page 6] Internet-Draft QUIC Compatible VN December 2022 If those formats are identical, as in cases where the negotiated version is the same as the client's chosen version, then this will be the identity transform. If the first flight is correctly formatted, then this conversion process cannot fail by definition of the first flight being compatible; if the server is unable to convert the first flight, it MUST abort the handshake. If a document specifies that a QUIC version is compatible with another, that document MUST specify the mechanism by which clients are made aware of the negotiated version. An example of such a mechanism is to have the client determine the server's negotiated version by examining the QUIC long header Version field. Note that, in this example mechanism, it is possible for the server to initially send packets with the client's chosen version before switching to the negotiated version (this can happen when the client's Version Information structure spans multiple packets; in that case the server might acknowledge the first packet in the client's chosen version and later switch to a different negotiated version). Mutually compatible versions SHOULD use the same mechanism. Note that, after the first flight is converted to the negotiated version, the handshake completes in the negotiated version. If the negotiated version has requirements that apply during the handshake, those requirements apply to the entire handshake, including the converted first flight. In particular, if the negotiated version mandates that endpoints perform validations on handshake packets, endpoints MUST also perform such validations on the converted first flight. For instance, if the negotiated version requires that the 5-tuple remain stable for the entire handshake (as QUIC version 1 does), then both endpoints need to validate the 5-tuple of all handshake packets, including the converted first flight. Note also that the client can disable compatible version negotiation by only including the Chosen Version in the Available Versions field of the Version Information; see Section 3. If the server does not find a compatible version (including the client's chosen version), it will perform incompatible version negotiation instead, see Section 2.1. Note that it is possible to have incompatible version negotiation followed by compatible version negotiation. For instance, if version A is compatible with B and C is compatible with D, the following scenario could occur: Schinazi & Rescorla Expires 22 June 2023 [Page 7] Internet-Draft QUIC Compatible VN December 2022 Client Server Chosen = A, Available Versions = (A, B) -------------> <------------------------ Version Negotiation = (D, C) Chosen = C, Available Versions = (C, D) -------------> <------------- Chosen = D, Available Versions = (D, C) Figure 1: Combined Negotiation Example In this example, the client selected C from the server's Version Negotiation packet, but the server preferred D and then selected it from the client's offer. 2.4. Connections and Version Negotiation QUIC connections are shared state between a client and a server [QUIC-INVARIANTS]. The compatible version negotiation mechanism defined in this document (see Section 2.3) is performed as part of a single QUIC connection; that is, the packets with the client's chosen version are part of the same connection as the packets with the negotiated version. In comparison, the incompatible version negotiation mechanism, which leverages QUIC Version Negotiation packets (see Section 2.1) conceptually operates across two QUIC connections: the connection attempt prior to receiving the Version Negotiation packet is distinct from the connection with the incompatible version that follows. Note that this separation across two connections is conceptual: it applies to normative requirements on QUIC connections, but does not require implementations to internally use two distinct connection objects. 2.5. Client Choice of Original Version When the client picks its original version, it will try to avoid incompatible version negotiation to save a round trip. Therefore, the client SHOULD pick an original version to maximize the combined probability that both: * The server knows how to parse first flights from the original version. * The original version is compatible with the client's preferred version. Schinazi & Rescorla Expires 22 June 2023 [Page 8] Internet-Draft QUIC Compatible VN December 2022 Without additional information, this could mean selecting the oldest version that the client supports, while advertising newer compatible versions in the client's first flight. 3. Version Information During the handshake, endpoints will exchange Version Information, which consists of a chosen version and a list of available versions. Any version of QUIC that supports this mechanism MUST provide a mechanism to exchange Version Information in both directions during the handshake, such that this data is authenticated. In QUIC version 1, the Version Information is transmitted using a new "version_information" transport parameter; see Section 7.4 of [QUIC]. The contents of Version Information are shown below (using the notation from the "Notational Conventions" section of [QUIC]): Version Information { Chosen Version (32), Available Versions (32) ..., } Figure 2: Version Information Format The content of each field is described below: Chosen Version: The version that the sender has chosen to use for this connection. In most cases, this field will be equal to the value of the Version field in the long header that carries this data; however future versions or extensions can choose to set different values in the long header Version field. The contents of the Available Versions field depends on whether it is sent by the client or by the server. Client-Sent Available Versions: When sent by a client, the Available Versions field lists all the versions that this first flight is compatible with, ordered by descending preference. Note that the version in the Chosen Version field MUST be included in this list to allow the client to communicate the chosen version's preference. Note that this preference is only advisory, servers MAY choose to use their own preference instead. Server-Sent Available Versions: When sent by a server, the Available Schinazi & Rescorla Expires 22 June 2023 [Page 9] Internet-Draft QUIC Compatible VN December 2022 Versions field lists all the Fully-Deployed Versions of this server deployment, see Section 5. The ordering of the versions in this field does not carry any semantics. Note that the version in the Chosen Version field is not necessarily included in this list, because the server operator could be in the process of removing support for this version. For the same reason, the Available Versions field MAY be empty. Clients and servers MAY both include versions following the pattern 0x?a?a?a?a in their Available Versions list. Those versions are reserved to exercise version negotiation (see the Versions section of [QUIC]), and will never be selected when choosing a version to use. 4. Version Downgrade Prevention A version downgrade is an attack where a malicious entity manages to make the QUIC endpoints negotiate a QUIC version different from the one they would have negotiated in the absence of the attack. The mechanism described in this document is designed to prevent downgrade attacks. Clients MUST ignore any received Version Negotiation packets that contain the original version. A client that makes a connection attempt based on information received from a Version Negotiation packet MUST ignore any Version Negotiation packets it receives in response to that connection attempt. Both endpoints MUST parse their peer's Version Information during the handshake. If that leads to a parsing failure (for example, if it is too short or if its length is not divisible by four), then the endpoint MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type TRANSPORT_PARAMETER_ERROR. If an endpoint receives a Chosen Version equal to zero, or any Available Version equal to zero, it MUST treat it as a parsing failure. If a server receives a Version Information where the Chosen Version is not included in Available Versions, it MUST treat it as a parsing failure. Every QUIC version that supports version negotiation MUST define a method for closing the connection with a version negotiation error. For QUIC version 1, version negotiation errors are signaled using a transport error of type VERSION_NEGOTIATION_ERROR; see Section 10.2. When a server receives a client's first flight, the server will first establish which QUIC version is in use for this connection in order to properly parse the first flight. For example, the server determines that QUIC version 1 is in use by observing that the Version field of the first Long Header packet it receives is set to Schinazi & Rescorla Expires 22 June 2023 [Page 10] Internet-Draft QUIC Compatible VN December 2022 0x00000001. When the server then processes the client's Version Information, the server MUST validate that the client's Chosen Version matches the version in use for the connection. If the two differ, the server MUST close the connection with a version negotiation error. For example, if a server receives the client's Version Information over QUIC version 1 (as indicated by the Version field of the Long Header packets that carried the transport parameters) and the client's Chosen Version is not set to 0x00000001, the server will close the connection with a version negotiation error. If a client receives a Version Information where the server's Chosen Version was not sent by the client as part of its Available Versions, the client MUST close the connection with a version negotiation error. If the Version Information was missing, the endpoints MAY complete the handshake. However, if a client has reacted to a Version Negotiation packet and the Version Information was missing, the client MUST close the connection with a version negotiation error. If the client received and acted on a Version Negotiation packet, the client MUST validate the server's Available Versions field. The Available Versions field is validated by confirming that the client would have attempted the same version with knowledge of the versions the server supports. That is, the client would have selected the same version if it received a Version Negotiation packet that listed the versions in the server's Available Versions field, plus the negotiated version. If the client would have selected a different version, the client MUST close the connection with a version negotiation error. In particular, if the client reacted to a Version Negotiation packet and the server's Available Versions field is empty, the client MUST close the connection with a version negotiation error. These connection closures prevent an attacker from being able to use forged Version Negotiation packets to force a version downgrade. As an example, let's assume a client supports hypothetical QUIC versions 10, 12, and 14 with a preference for higher versions. The client initiates a connection attempt with version 12. Let's explore two independent example scenarios: * In the first scenario, the server supports versions 10, 13, and 14 but only 13 and 14 are Fully-Deployed (see Section 5). The server sends a Version Negotiation packet with versions 10, 13, and 14. This triggers an incompatible version negotiation and the client initiates a new connection with version 14. Then the server's Available Versions field contains 13 and 14. In that scenario, Schinazi & Rescorla Expires 22 June 2023 [Page 11] Internet-Draft QUIC Compatible VN December 2022 the client would have also picked 14 if it had received a Version Negotiation packet with versions 13 and 14, therefore the handshake succeeds using negotiated version 14. * In the second scenario, the server supports versions 10, 13, and 14 and they are all Fully-Deployed. However, the attacker forges a Version Negotiation packet with versions 10 and 13. This triggers an incompatible version negotiation and the client initiates a new connection with version 10. Then the server's Available Versions field contains 10, 13 and 14. In that scenario, the client would have picked 14 instead of 10 if it had received a Version Negotiation packet with versions 10, 13 and 14, therefore the client aborts the handshake with a version negotiation error. This validation of Available Versions is not sufficient to prevent downgrade. Downgrade prevention also depends on the client ignoring Version Negotiation packets that contain the original version; see Section 2.1. After the process of version negotiation in this document completes, the version in use for the connection is the version that the server sent in the Chosen Version field of its Version Information. That remains true even if other versions were used in the Version field of long headers at any point in the lifetime of the connection. In particular, since during compatible version negotiation the client is made aware of the negotiated version by the QUIC long header version (see Section 2.3), clients MUST validate that the server's Chosen Version is equal to the negotiated version; if they do not match, the client MUST close the connection with a version negotiation error. This prevents an attacker's ability to influence version negotiation by forging the Version long header field. 5. Server Deployments of QUIC While this document mainly discusses a single QUIC server, it is common for deployments of QUIC servers to include a fleet of multiple server instances. We therefore define the following terms: Acceptable Versions: This is the set of versions supported by a given server instance. More specifically, these are the versions that a given server instance will use if a client sends a first flight using them. Offered Versions: This is the set of versions that a given server instance will send in a Version Negotiation packet if it receives a first flight from an unknown version. This set will most often be equal to the Acceptable Versions set, except during short transitions while versions are added or removed (see below). Schinazi & Rescorla Expires 22 June 2023 [Page 12] Internet-Draft QUIC Compatible VN December 2022 Fully-Deployed Versions: This is the set of QUIC versions that is supported and negotiated by every single QUIC server instance in this deployment. If a deployment only contains a single server instance, then this set is equal to the Offered Versions set, except during short transitions while versions are added or removed (see below). If a deployment contains multiple server instances, software updates may not happen at exactly the same time on all server instances. Because of this, a client might receive a Version Negotiation packet from a server instance that has already been updated and the client's resulting connection attempt might reach a different server instance which hasn't been updated yet. However, even when there is only a single server instance, it is still possible to receive a stale Version Negotiation packet if the server performs its software update while the Version Negotiation packet is in flight. This could cause the version downgrade prevention mechanism described in Section 4 to falsely detect a downgrade attack. To avoid that, server operators SHOULD perform a three-step process when they wish to add or remove support for a version: When adding support for a new version: * The first step is to progressively add support for the new version to all server instances. This step updates the Acceptable Versions but not the Offered Versions nor the Fully-Deployed Versions. Once all server instances have been updated, operators wait for at least one MSL to allow any in-flight Version Negotiation packets to arrive. * Then, the second step is to progressively add the new version to Offered Versions on all server instances. Once complete, operators wait for at least another MSL. * Finally, the third step is to progressively add the new version to Fully-Deployed Versions on all server instances. When removing support for a version: * The first step is to progressively remove the version from Fully- Deployed Versions on all server instances. Once it has been removed on all server instances, operators wait for at least one MSL to allow any in-flight Version Negotiation packets to arrive. Schinazi & Rescorla Expires 22 June 2023 [Page 13] Internet-Draft QUIC Compatible VN December 2022 * Then, the second step is to progressively remove the version from Offered Versions on all server instances. Once complete, operators wait for at least another MSL. * Finally, the third step is to progressively remove support for the version from all server instances. That step updates the Acceptable Versions. Note that, during the update window, connections are vulnerable to downgrade attacks for partially-deployed versions. This is because a client cannot distinguish such a downgrade attack from legitimate exchanges with both updated and non-updated server instances. 6. Application Layer Protocol Considerations When a client creates a QUIC connection, its goal is to use an application layer protocol. Therefore, when considering which versions are compatible, clients will only consider versions that support one of the intended application layer protocols. If the client's first flight advertises multiple Application Layer Protocol Negotiation (ALPN) [ALPN] tokens and multiple compatible versions, it is possible for some application layer protocols to not be able to run over some of the offered compatible versions. It is the server's responsibility to only select an ALPN token that can run over the compatible QUIC version that it selects. A given ALPN token MUST NOT be used with a new QUIC version different from the version for which the ALPN token was originally defined, unless all the following requirements are met: * The new QUIC version supports the transport features required by the application protocol. * The new QUIC version supports ALPN. * The version of QUIC for which the ALPN token was originally defined is compatible with the new QUIC version. When incompatible version negotiation is in use, the second connection which is created in response to the received version negotiation packet MUST restart its application layer protocol negotiation process without taking into account the original version. 7. Considerations for Future Versions In order to facilitate the deployment of future versions of QUIC, designers of future versions SHOULD attempt to design their new version such that commonly deployed versions are compatible with it. Schinazi & Rescorla Expires 22 June 2023 [Page 14] Internet-Draft QUIC Compatible VN December 2022 QUIC version 1 defines multiple features which are not documented in the QUIC invariants. Since, at the time of writing, QUIC version 1 is widely deployed, this section discusses considerations for future versions to help with compatibility with QUIC version 1. 7.1. Interaction with Retry QUIC version 1 features Retry packets, which the server can send to validate the client's IP address before parsing the client's first flight. A server that sends a Retry packet can do so before parsing the client's first flight. A server that sends a Retry packet therefore might not have processed the client's Version Information before doing so. If a future document wishes to define compatibility between two versions that support retry, that document MUST specify how version negotiation (both compatible and incompatible) interacts with retry during a handshake that requires both. For example, that could be accomplished by having the server first send a Retry packet in the original version thereby validating the client's IP address before attempting compatible version negotiation. If both versions support authenticating Retry packets, the compatibility definition needs to define how to authenticate the Retry in the negotiated version handshake even though the Retry itself was sent using the client's chosen version. 7.2. Interaction with TLS resumption QUIC version 1 uses TLS 1.3, which supports session resumption by sending session tickets in one connection that can be used in a later connection; see Section 2.2 of [TLS]. New versions that also use TLS 1.3 SHOULD mandate that their session tickets are tightly scoped to one version of QUIC; i.e., require that clients not use them across multiple version and that servers validate this client requirement. This helps mitigate cross-protocol attacks. 7.3. Interaction with 0-RTT QUIC version 1 allows sending data from the client to the server during the handshake, by using 0-RTT packets. If a future document wishes to define compatibility between two versions that support 0-RTT, that document MUST address the scenario where there are 0-RTT packets in the client's first flight. For example, this could be accomplished by defining which transformations are applied to 0-RTT packets. That document could specify that compatible version negotiation causes 0-RTT data to be rejected by the server. Schinazi & Rescorla Expires 22 June 2023 [Page 15] Internet-Draft QUIC Compatible VN December 2022 8. Special Handling for QUIC Version 1 Because QUIC version 1 was the only IETF Standards Track version of QUIC published before this document, it is handled specially as follows: if a client is starting a QUIC version 1 connection in response to a received Version Negotiation packet, and the version_information transport parameter is missing from the server's transport parameters, then the client SHALL proceed as if the server's transport parameters contained a version_information transport parameter with a Chosen Version set to 0x00000001 and an Available Version list containing exactly one version set to 0x00000001. This allows version negotiation to work with servers that only support QUIC version 1. Note that implementations which wish to use version negotiation to negotiate versions other than QUIC version 1 will need to implement the version negotiation mechanism defined in this document. 9. Security Considerations The security of this version negotiation mechanism relies on the authenticity of the Version Information exchanged during the handshake. In QUIC version 1, transport parameters are authenticated ensuring the security of this mechanism. Negotiation between compatible versions will have the security of the weakest common version. The requirement that versions not be assumed compatible mitigates the possibility of cross-protocol attacks, but more analysis is still needed here. That analysis is out of scope for this document. 10. IANA Considerations 10.1. QUIC Transport Parameter IANA has registered the following value in the "QUIC Transport Parameters" registry maintained at . Value: 0x11 Parameter Name: version_information Status: permanent Specification: This document 10.2. QUIC Transport Error Code IANA has registered the following value in the "QUIC Transport Error Codes" registry maintained at . Schinazi & Rescorla Expires 22 June 2023 [Page 16] Internet-Draft QUIC Compatible VN December 2022 Value: 0x11 Code: VERSION_NEGOTIATION_ERROR Description: Error negotiating version Status: permanent Specification: This document 11. References 11.1. Normative References [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [QUIC-INVARIANTS] Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 11.2. Informative References [TCP] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . Schinazi & Rescorla Expires 22 June 2023 [Page 17] Internet-Draft QUIC Compatible VN December 2022 Acknowledgments The authors would like to thank Nick Banks, Mike Bishop, Martin Duke, Ryan Hamilton, Roberto Peon, Anthony Rossi, and Martin Thomson for their input and contributions. Authors' Addresses David Schinazi Google LLC 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America Email: dschinazi.ietf@gmail.com Eric Rescorla Mozilla Email: ekr@rtfm.com Schinazi & Rescorla Expires 22 June 2023 [Page 18] ./draft-ietf-dots-robust-blocks-06.txt0000644000764400076440000012703614317535143017431 0ustar iustiniustin DOTS M. Boucadair Internet-Draft Orange Intended status: Standards Track J. Shallow Expires: 9 April 2023 6 October 2022 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission draft-ietf-dots-robust-blocks-06 Abstract This document specifies new DDoS Open Threat Signaling (DOTS) signal channel configuration parameters that can be negotiated between DOTS peers to enable the use of Q-Block1 and Q-Block2 CoAP options. These options enable robust and faster transmission rates for large amounts of data with less packet interchanges as well as supporting faster recovery should any of the blocks get lost in transmission (especially, during DDoS attacks). Also, this document defines a YANG data model for representing these new DOTS signal channel configuration parameters. This model augments the DOTS signal YANG module ("ietf-dots-signal-channel") defined in RFC 9132. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 9 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Boucadair & Shallow Expires 9 April 2023 [Page 1] Internet-Draft DOTS Robust Block Transmission October 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. DOTS Attributes for Robust Block Transmission . . . . . . . . 4 4. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 10 5. DOTS Robust Block Transmission YANG Module . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 18 6.2. DOTS Robust Block Transmission YANG Module . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction The Constrained Application Protocol (CoAP) [RFC7252], although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. The block- wise transfer [RFC7959] introduced the CoAP Block1 and Block2 options to handle data records that cannot fit in a single IP packet, so not having to rely on IP fragmentation. The block-wise transfer was further updated by [RFC8323] for use over TCP, TLS, and WebSockets. The CoAP Block1 and Block2 options work well in environments where there are no or minimal packet losses. These options operate synchronously where each individual block has to be requested and can only ask for (or send) the next block when the request for the previous block has completed. Packet, and hence block transmission rate, is controlled by Round-Trip Times (RTTs). There is a requirement for these blocks of data to be transmitted at higher rates under network conditions where there may be asymmetrical transient packet loss (e.g., responses may get dropped). An example is when a network is subject to a Distributed Denial of Service Boucadair & Shallow Expires 9 April 2023 [Page 2] Internet-Draft DOTS Robust Block Transmission October 2022 (DDoS) attack and there is a need for DDoS mitigation agents relying upon CoAP to communicate with each other (e.g., [RFC9244]). As a reminder, [RFC7959] recommends the use of Confirmable (CON) responses to handle potential packet loss. However, such a recommendation does not work with a flooded pipe DDoS situation because the returning ACK packets may not get through. The block-wise transfer specified in [RFC7959] covers the general case, but falls short in situations where packet loss is highly asymmetrical. The mechanism specified in [RFC9177] provides roughly similar features to the Block1/Block2 options, but provides additional properties that are tailored towards the intended DDoS Open Threat Signaling (DOTS) transmission. Concretely, [RFC9177] primarily targets applications such as DOTS that can't use Confirmable responses to handle potential packet loss and that support application-specific mechanisms to assess whether the remote peer is able to handle the messages sent by a CoAP endpoint (e.g., DOTS heartbeats in Section 4.7 of [RFC9132]). [RFC9177] includes guards to prevent a CoAP agent from overloading the network by adopting an aggressive sending rate. These guards are followed in addition to the existing CoAP congestion control as specified in Section 4.7 of [RFC7252] (mainly, PROBING_RATE). Table 1 lists the additional CoAP parameters that are used for the guards (Section 7.2 of [RFC9177]). Note that NON in this table refers to Non-confirmable. +---------------------+-------------------+ | Parameter Name | Default Value | +=====================+===================+ | MAX_PAYLOADS | 10 | | NON_MAX_RETRANSMIT | 4 | | NON_TIMEOUT | 2 s | | NON_TIMEOUT_RANDOM | between 2-3 s | | NON_RECEIVE_TIMEOUT | 4 s | | NON_PROBING_WAIT | between 247-248 s | | NON_PARTIAL_TIMEOUT | 247 s | +---------------------+-------------------+ Table 1: Congestion Control Parameters PROBING_RATE and other transmission parameters are negotiated between DOTS peers as discussed in Section 4.5.2 of [RFC9132]. Nevertheless, negotiating the parameters listed in Table 1 is not supported in [RFC9132]. This document defines new DOTS signal channel attributes, corresponding to the parameters in Table 1, that are used to customize the configuration of robust block transmission in a DOTS context. Boucadair & Shallow Expires 9 April 2023 [Page 3] Internet-Draft DOTS Robust Block Transmission October 2022 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Readers should be familiar with the terms and concepts defined in [RFC7252] and [RFC8612]. The terms "payload" and "body" are defined in [RFC7959]. The term "payload" is thus used for the content of a single CoAP message (i.e., a single block being transferred), while the term "body" is used for the entire resource representation that is being transferred in a block-wise fashion. The meaning of the symbols in YANG tree diagrams are defined in [RFC8340] and [RFC8791]. 3. DOTS Attributes for Robust Block Transmission Section 7.2 of [RFC9177] defines the following parameters that are used for congestion control purposes: MAX_PAYLOADS: is the maximum number of payloads that can be transmitted at any one time. NON_MAX_RETRANSMIT: is the maximum number of times a request for the retransmission of missing payloads can occur without a response from the remote peer. By default, NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8 of [RFC7252]). NON_TIMEOUT: is the maximum period of delay between sending sets of MAX_PAYLOADS payloads for the same body. NON_TIMEOUT has the same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). NON_TIMEOUT_RANDOM: is the initial actual delay between sending the first two MAX_PAYLOADS_SETs of the same body. It is a random duration between NON_TIMEOUT and (NON_TIMEOUT * ACK_RANDOM_FACTOR). NON_RECEIVE_TIMEOUT: is the maximum time to wait for a missing payload before requesting retransmission. By default, NON_RECEIVE_TIMEOUT has a value of twice NON_TIMEOUT. NON_PROBING_WAIT: is used to limit the potential wait needed when using PROBING_RATE. Boucadair & Shallow Expires 9 April 2023 [Page 4] Internet-Draft DOTS Robust Block Transmission October 2022 NON_PARTIAL_TIMEOUT: is used for expiring partially received bodies. These parameters are used together with PROBING_RATE parameter which in CoAP indicates the average data rate that must not be exceeded by a CoAP endpoint in sending to a peer endpoint that does not respond. The single body of blocks will be subjected to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets. If the wait time between sending bodies that are not being responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time is limited to NON_PROBING_WAIT. This document augments the "ietf-dots-signal-channel" DOTS signal YANG module defined in Section 5.3 of [RFC9132] with the following additional attributes that can be negotiated between DOTS peers to enable robust and faster transmission: max-payloads: This attribute echoes the MAX_PAYLOADS parameter in [RFC9177]. This is an optional attribute. If the attribute is supplied in both 'idle-config' and 'mitigating-config', then it MUST convey the same value. If the attribute is only provided as part of 'idle-config' (or 'mitigating-config'), then the other definition (i.e., 'mitigating-config' (or 'idle-config')) MUST be updated to the same value. non-max-retransmit: This attribute echoes the NON_MAX_RETRANSMIT parameter in [RFC9177]. The default value of this attribute is 'max-retransmit'. Note that DOTS uses a default value of '3' instead of '4' used for the generic CoAP use (Section 4.5.2 of [RFC9132]) for max-transmit. This is an optional attribute. non-timeout: This attribute, expressed in seconds, echoes the NON_TIMEOUT parameter in [RFC9177]. The default value of this attribute is 'ack-timeout'. This attribute is also used to compute the NON_TIMEOUT_RANDOM parameter. This is an optional attribute. non-receive-timeout: This attribute, expressed in seconds, echoes the NON_RECEIVE_TIMEOUT parameter in [RFC9177]. The default value of this attribute is twice 'non-timeout'. This is an optional attribute. Boucadair & Shallow Expires 9 April 2023 [Page 5] Internet-Draft DOTS Robust Block Transmission October 2022 non-probing-wait: This attribute, expressed in seconds, echoes the NON_PROBING_WAIT parameter in [RFC9177]. This is an optional attribute. non-partial-timeout: This attribute, expressed in seconds, echoes the NON_PARTIAL_TIMEOUT parameter in [RFC9177]. The default value of this attribute is 247 seconds. This is an optional attribute. The tree structure of the "ietf-dots-robust-trans" module (Section 5) is shown in Figure 1. module: ietf-dots-robust-trans augment-structure /dots-signal:dots-signal/dots-signal:message-type /dots-signal:signal-config /dots-signal:mitigating-config: +-- max-payloads | +-- (direction)? | | +--:(server-to-client-only) | | +-- max-value? uint16 | | +-- min-value? uint16 | +-- current-value? uint16 +-- non-max-retransmit | +-- (direction)? | | +--:(server-to-client-only) | | +-- max-value? uint16 | | +-- min-value? uint16 | +-- current-value? uint16 +-- non-timeout | +-- (direction)? | | +--:(server-to-client-only) | | +-- max-value-decimal? decimal64 | | +-- min-value-decimal? decimal64 | +-- current-value-decimal? decimal64 +-- non-receive-timeout | +-- (direction)? | | +--:(server-to-client-only) | | +-- max-value-decimal? decimal64 | | +-- min-value-decimal? decimal64 | +-- current-value-decimal? decimal64 +-- non-probing-wait | +-- (direction)? | | +--:(server-to-client-only) | | +-- max-value-decimal? decimal64 | | +-- min-value-decimal? decimal64 Boucadair & Shallow Expires 9 April 2023 [Page 6] Internet-Draft DOTS Robust Block Transmission October 2022 | +-- current-value-decimal? decimal64 +-- non-partial-wait: +-- (direction)? | +--:(server-to-client-only) | +-- max-value-decimal? decimal64 | +-- min-value-decimal? decimal64 +-- current-value-decimal? decimal64 augment-structure /dots-signal:dots-signal/dots-signal:message-type /dots-signal:signal-config/dots-signal:idle-config: +-- max-payloads | +-- (direction)? | | +--:(server-to-client-only) | | +-- max-value? uint16 | | +-- min-value? uint16 | +-- current-value? uint16 +-- non-max-retransmit | +-- (direction)? | | +--:(server-to-client-only) | | +-- max-value? uint16 | | +-- min-value? uint16 | +-- current-value? uint16 +-- non-timeout | +-- (direction)? | | +--:(server-to-client-only) | | +-- max-value-decimal? decimal64 | | +-- min-value-decimal? decimal64 | +-- current-value-decimal? decimal64 +-- non-receive-timeout | +-- (direction)? | | +--:(server-to-client-only) | | +-- max-value-decimal? decimal64 | | +-- min-value-decimal? decimal64 | +-- current-value-decimal? decimal64 +-- non-probing-wait | +-- (direction)? | | +--:(server-to-client-only) | | +-- max-value-decimal? decimal64 | | +-- min-value-decimal? decimal64 | +-- current-value-decimal? decimal64 +-- non-partial-wait: +-- (direction)? | +--:(server-to-client-only) | +-- max-value-decimal? decimal64 | +-- min-value-decimal? decimal64 +-- current-value-decimal? decimal64 Figure 1: DOTS Fast Block Transmission Tree Structure Boucadair & Shallow Expires 9 April 2023 [Page 7] Internet-Draft DOTS Robust Block Transmission October 2022 These attributes are mapped to CBOR types as specified in Section 4 and Section 6 of [RFC9132]. DOTS clients follow the procedure specified in Section 4.5 of [RFC9132] to negotiate, configure, and retrieve the DOTS signal channel session behavior (including Q-Block parameters) with DOTS peers. Implementation Note 1: 'non-probing-wait' ideally should be left having some jitter and so should not be hard-coded with an explicit value. It is suggested to use a base value (using NON_TIMEOUT instead of NON_TIMEOUT_RANDOM) and, then, the jitter (ACK_RANDOM_FACTOR - 1) is added to each time the value is checked. Implementation Note 2: If any of the signal channel session configuration parameters is updated, the 'non-probing-wait' and 'non-partial-timeout' values should be recalculated according to the definition algorithms in Section 7.2 of [RFC9177] unless explicit values are provided as part of the negotiated configuration. An example of a PUT message to configure Q-Block parameters is depicted in Figure 2. In this example, a non-default value is configured for the 'max-payloads' attribute, while default values are used for 'non-max-retransmit', 'non-timeout', and 'non-receive- timeout' in both idle and mitigation times. Given that 'non-probing- wait' and 'non-partial-wait' are not explicitly configured in this example, these attributes will be computed following the algorithms in Section 7.2 of [RFC9177]. The meaning of the other attributes is detailed in Section 4.5 of [RFC9132]. Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "config" Uri-Path: "sid=123" Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:signal-config": { "mitigating-config": { "heartbeat-interval": { "current-value": 30 }, "missing-hb-allowed": { "current-value": 15 }, Boucadair & Shallow Expires 9 April 2023 [Page 8] Internet-Draft DOTS Robust Block Transmission October 2022 "probing-rate": { "current-value": 15 }, "max-retransmit": { "current-value": 3 }, "ack-timeout": { "current-value-decimal": "2.00" }, "ack-random-factor": { "current-value-decimal": "1.50" }, "ietf-dots-robust-trans:max-payloads": { "current-value": 15 }, "ietf-dots-robust-trans:non-max-retransmit": { "current-value": 3 }, "ietf-dots-robust-trans:non-timeout": { "current-value-decimal": "2.00" }, "ietf-dots-robust-trans:non-receive-timeout": { "current-value-decimal": "4.00" } }, "idle-config": { "heartbeat-interval": { "current-value": 0 }, "max-retransmit": { "current-value": 3 }, "ack-timeout": { "current-value-decimal": "2.00" }, "ack-random-factor": { "current-value-decimal": "1.50" }, "ietf-dots-robust-trans:max-payloads": { "current-value": 15 }, "ietf-dots-robust-trans:non-max-retransmit": { "current-value": 3 }, "ietf-dots-robust-trans:non-timeout": { "current-value-decimal": "2.00" }, "ietf-dots-robust-trans:non-receive-timeout": { Boucadair & Shallow Expires 9 April 2023 [Page 9] Internet-Draft DOTS Robust Block Transmission October 2022 "current-value-decimal": "4.00" } } } } Figure 2: Example of PUT to Convey the Configuration Parameters The payload of the message depicted in Figure 2 is CBOR-encoded as indicated by the Content-Format set to "application/dots+cbor" (Section 10.3 of [RFC9132]). However, and for the sake of better readability, the example uses JSON encoding of YANG-modeled data following the mapping table in Section 4 and Section 6 of [RFC9132]: use the JSON names and types defined in Section 4. These conventions are inherited from [RFC9132]. 4. YANG/JSON Mapping Parameters to CBOR The YANG/JSON mapping parameters to CBOR are listed in Table 2. * Note: Implementers must check that the mapping output provided by their YANG-to-CBOR encoding schemes is aligned with the content of Table 2. Boucadair & Shallow Expires 9 April 2023 [Page 10] Internet-Draft DOTS Robust Block Transmission October 2022 +----------------------+------------+------+---------------+--------+ | Parameter Name | YANG | CBOR | CBOR Major | JSON | | | Type | Key | Type & | Type | | | | | Information | | +======================+============+======+===============+========+ | ietf-dots-robust- | container | TBA1 | 5 map | Object | | trans:max-payloads | | | | | +----------------------+------------+------+---------------+--------+ | ietf-dots-robust- | container | TBA2 | 5 map | Object | | trans:non-max- | | | | | | retransmit | | | | | +----------------------+------------+------+---------------+--------+ | ietf-dots-robust- | container | TBA3 | 5 map | Object | | trans:non-timeout | | | | | +----------------------+------------+------+---------------+--------+ | ietf-dots-robust- | container | TBA4 | 5 map | Object | | trans:non-receive- | | | | | | timeout | | | | | +----------------------+------------+------+---------------+--------+ | ietf-dots-robust- | container | TBA5 | 5 map | Object | | trans:non-probing- | | | | | | wait | | | | | +----------------------+------------+------+---------------+--------+ | ietf-dots-robust- | container | TBA6 | 5 map | Object | | trans:non-partial- | | | | | | wait | | | | | +----------------------+------------+------+---------------+--------+ Table 2: YANG/JSON Mapping Parameters to CBOR 5. DOTS Robust Block Transmission YANG Module This module uses the data structure extension defined in [RFC8791]. file "ietf-dots-robust-trans@2022-01-04.yang" module ietf-dots-robust-trans { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans"; prefix dots-robust; import ietf-dots-signal-channel { prefix dots-signal; reference "RFC 9132: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"; } import ietf-yang-structure-ext { Boucadair & Shallow Expires 9 April 2023 [Page 11] Internet-Draft DOTS Robust Block Transmission October 2022 prefix sx; reference "RFC 8791: YANG Data Structure Extensions"; } organization "IETF DDoS Open Threat Signaling (DOTS) Working Group"; contact "WG Web: WG List: Author: Mohamed Boucadair ; Author: Jon Shallow "; description "This module contains YANG definitions for the configuration of parameters that can be negotiated between a DOTS client and a DOTS server for robust block transmission. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2022-01-04 { description "Initial revision."; reference "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Configuration Attributes for Robust Block Transmission"; } grouping robust-transmission-attributes { description "A set of DOTS signal channel session configuration that are negotiated between DOTS agents when making use of Q-Block1 and Q-Block2 options."; Boucadair & Shallow Expires 9 April 2023 [Page 12] Internet-Draft DOTS Robust Block Transmission October 2022 container max-payloads { description "Indicates the maximum number of payloads that can be transmitted at any one time."; choice direction { description "Indicates the communication direction in which the data nodes can be included."; case server-to-client-only { description "These data nodes appear only in a message sent from the server to the client."; leaf max-value { type uint16; description "Maximum acceptable max-payloads value."; } leaf min-value { type uint16; description "Minimum acceptable max-payloads value."; } } } leaf current-value { type uint16; default "10"; description "Current max-payloads value."; reference "RFC 9177: Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission, Section 7.2"; } } container non-max-retransmit { description "Indicates the maximum number of times a request for the retransmission of missing payloads can occur without a response from the remote peer."; choice direction { description "Indicates the communication direction in which the data nodes can be included."; case server-to-client-only { description "These data nodes appear only in a message sent from the server to the client."; Boucadair & Shallow Expires 9 April 2023 [Page 13] Internet-Draft DOTS Robust Block Transmission October 2022 leaf max-value { type uint16; description "Maximum acceptable non-max-retransmit value."; } leaf min-value { type uint16; description "Minimum acceptable non-max-retransmit value."; } } } leaf current-value { type uint16; default "3"; description "Current non-max-retransmit value."; reference "RFC 9177: Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission, Section 7.2"; } } container non-timeout { description "Indicates the maximum period of delay between sending sets of MAX_PAYLOADS payloads for the same body."; choice direction { description "Indicates the communication direction in which the data nodes can be included."; case server-to-client-only { description "These data nodes appear only in a message sent from the server to the client."; leaf max-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; description "Maximum ack-timeout value."; } leaf min-value-decimal { type decimal64 { fraction-digits 2; } Boucadair & Shallow Expires 9 April 2023 [Page 14] Internet-Draft DOTS Robust Block Transmission October 2022 units "seconds"; description "Minimum ack-timeout value."; } } } leaf current-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; default "2.00"; description "Current ack-timeout value."; reference "RFC 9177: Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission, Section 7.2"; } } container non-receive-timeout { description "Indicates the time to wait for a missing payload before requesting retransmission."; choice direction { description "Indicates the communication direction in which the data nodes can be included."; case server-to-client-only { description "These data nodes appear only in a message sent from the server to the client."; leaf max-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; description "Maximum non-receive-timeout value."; } leaf min-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; description "Minimum non-receive-timeout value."; } Boucadair & Shallow Expires 9 April 2023 [Page 15] Internet-Draft DOTS Robust Block Transmission October 2022 } } leaf current-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; default "4.00"; description "Current non-receive-timeout value."; reference "RFC 9177: Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission, Section 7.2"; } } container non-probing-wait { description "Is used to limit the potential wait needed when using probing-rate."; choice direction { description "Indicates the communication direction in which the data nodes can be included."; case server-to-client-only { description "These data nodes appear only in a message sent from the server to the client."; leaf max-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; description "Maximum non-probing-wait value."; } leaf min-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; description "Minimum non-probing-wait value."; } } } leaf current-value-decimal { type decimal64 { Boucadair & Shallow Expires 9 April 2023 [Page 16] Internet-Draft DOTS Robust Block Transmission October 2022 fraction-digits 2; } units "seconds"; description "Current non-probing-wait value."; reference "RFC 9177: Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission, Section 7.2"; } } container non-partial-wait { description "Is used for expiring partially received bodies."; choice direction { description "Indicates the communication direction in which the data nodes can be included."; case server-to-client-only { description "These data nodes appear only in a message sent from the server to the client."; leaf max-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; description "Maximum non-partial-wait value."; } leaf min-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; description "Minimum non-partial-wait value."; } } } leaf current-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; default "247.00"; description "Current non-partial-wait value."; Boucadair & Shallow Expires 9 April 2023 [Page 17] Internet-Draft DOTS Robust Block Transmission October 2022 reference "RFC 9177: Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission, Section 7.2"; } } } sx:augment-structure "/dots-signal:dots-signal" + "/dots-signal:message-type" + "/dots-signal:signal-config" + "/dots-signal:mitigating-config" { description "Indicates DOTS configuration attributes to use for robust transmission when a mitigation is active."; uses robust-transmission-attributes; } sx:augment-structure "/dots-signal:dots-signal" + "/dots-signal:message-type" + "/dots-signal:signal-config" + "/dots-signal:idle-config" { description "Indicates DOTS configuration parameters to use for robust transmission when no mitigation is active."; uses robust-transmission-attributes; } } 6. IANA Considerations 6.1. DOTS Signal Channel CBOR Mappings Registry This specification registers the following parameters in the IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map]. * Note to the RFC Editor: Please replace TBA1-TBA6 with the CBOR keys that are assigned from the 32768-49151 range. Please update Table 2 accordingly. Boucadair & Shallow Expires 9 April 2023 [Page 18] Internet-Draft DOTS Robust Block Transmission October 2022 +------------------------+-------+-------+------------+---------------+ | Parameter Name | CBOR | CBOR | Change | Specification | | | Key | Major | Controller | Document(s) | | | Value | Type | | | +========================+=======+=======+============+===============+ | ietf-dots-robust-trans:| TBA1 | 5 | IESG | [RFCXXXX] | | max-payloads | | | | | +------------------------+-------+-------+------------+---------------+ | ietf-dots-robust-trans:| TBA2 | 5 | IESG | [RFCXXXX] | | non-max-retransmit | | | | | +------------------------+-------+-------+------------+---------------+ | ietf-dots-robust-trans:| TBA3 | 5 | IESG | [RFCXXXX] | | non-timeout | | | | | +------------------------+-------+-------+------------+---------------+ | ietf-dots-robust-trans:| TBA4 | 5 | IESG | [RFCXXXX] | | non-receive-timeout | | | | | +------------------------+-------+-------+------------+---------------+ | ietf-dots-robust-trans:| TBA5 | 5 | IESG | [RFCXXXX] | | non-probing-wait | | | | | +------------------------+-------+-------+------------+---------------+ | ietf-dots-robust-trans:| TBA6 | 5 | IESG | [RFCXXXX] | | non-partial-wait | | | | | +------------------------+-------+-------+------------+---------------+ 6.2. DOTS Robust Block Transmission YANG Module This document requests IANA to register the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document requests IANA to register the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. Name: ietf-dots-robust-trans Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans Maintained by IANA? N Prefix: dots-robust Reference: RFC XXXX 7. Security Considerations The security considerations for the DOTS signal channel protocol are discussed in Section 11 of [RFC9132]. Boucadair & Shallow Expires 9 April 2023 [Page 19] Internet-Draft DOTS Robust Block Transmission October 2022 CoAP-specific security considerations are discussed in Section 11 of [RFC9177]. Consistent with Section 5 of [RFC9132], the "ietf-dots-robust-trans" module is not intended to be used via NETCONF/RESTCONF. It serves as an abstract representation in DOTS signal channel messages. The "ietf-dots-robust-trans" module does not introduce any new vulnerabilities beyond those specified above. 8. Acknowledgements Thanks to Tiru Reddy, Meiling Chen, and Kaname Nishizuka for the review. Thanks to Michal Vasko for the yangdoctors review. Thanks to Valery Smyslov for shepherding the document, Paul Wouters for the AD review, Paul Kyzivat for the artart directorate review, Tim Evens for the Gen-ART review, and Jean-Michel Combes for the int- dir review. Thanks to John Scudder, Lars Eggert, Eric Vyncke, Roman Danyliw, Rob Wilton, and Martin Duke for the comments during the IESG review. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . Boucadair & Shallow Expires 9 April 2023 [Page 20] Internet-Draft DOTS Robust Block Transmission October 2022 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, . [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, June 2020, . [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 9132, DOI 10.17487/RFC9132, September 2021, . [RFC9177] Boucadair, M. and J. Shallow, "Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission", RFC 9177, DOI 10.17487/RFC9177, March 2022, . 9.2. Informative References [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open Threat Signaling (DOTS) Requirements", RFC 8612, DOI 10.17487/RFC8612, May 2019, . Boucadair & Shallow Expires 9 April 2023 [Page 21] Internet-Draft DOTS Robust Block Transmission October 2022 [RFC9244] Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M., and J. Shallow, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry", RFC 9244, DOI 10.17487/RFC9244, June 2022, . Authors' Addresses Mohamed Boucadair Orange 35000 Rennes France Email: mohamed.boucadair@orange.com Jon Shallow United Kingdom Email: supjps-ietf@jpshallow.com Boucadair & Shallow Expires 9 April 2023 [Page 22] ./draft-ietf-lpwan-schc-over-nbiot-15.txt0000644000764400076440000015707214346557024020021 0ustar iustiniustin lpwan Working Group E. Ramos Internet-Draft Ericsson Intended status: Standards Track A. Minaburo Expires: 18 June 2023 Acklio 15 December 2022 Static Context Header Compression over Narrowband Internet of Things draft-ietf-lpwan-schc-over-nbiot-15 Abstract This document describes Static Context Header Compression and Fragmentation (SCHC) specifications, RFC 8724 and RFC 8824, combination with the 3rd Generation Partnership Project (3GPP) and the Narrowband Internet of Things (NB-IoT). This document has two parts. One normative to specify the use of SCHC over NB-IoT. And one informational, which recommends some values if 3GPP wanted to use SCHC inside their architectures. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 18 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Ramos & Minaburo Expires 18 June 2023 [Page 1] Internet-Draft LPWAN SCHC NB-IoT December 2022 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. NB-IoT Architecture . . . . . . . . . . . . . . . . . . . . . 5 5. Data Transmission in the 3GPP Architecture . . . . . . . . . 6 5.1. Normative Part. . . . . . . . . . . . . . . . . . . . . . 7 5.1.1. SCHC over Non-IP Data Delivery (NIDD) . . . . . . . . 7 5.2. Informational Part. . . . . . . . . . . . . . . . . . . . 10 5.2.1. Use of SCHC over the Radio link . . . . . . . . . . . 11 5.2.2. Use of SCHC over the Non-Access Stratum (NAS) . . . . 12 5.2.3. Parameters for Static Context Header Compression and Fragmentation (SCHC) for the Radio link and DONAS use-cases. . . . . . . . . . . . . . . . . . . . . . 13 6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Security considerations . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. NB-IoT User Plane protocol architecture . . . . . . 17 A.1. Packet Data Convergence Protocol (PDCP) TS36323 . . . . . 18 A.2. Radio Link Protocol (RLC) TS36322 . . . . . . . . . . . . 18 A.3. Medium Access Control (MAC) TR36321 . . . . . . . . . . . 19 Appendix B. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . 20 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction This document defines the scenarios where the Static Context Header Compression and fragmentation (SCHC) [RFC8724] and [RFC8824] are suitable for 3rd Generation Partnership Project (3GPP) and Narrowband Internet of Things (NB-IoT) protocol stacks. In the 3GPP and the NB-IoT networks, header compression efficiently brings Internet connectivity to the Device-User Equipment (Dev-UE), the radio (RGW-eNB) and network (NGW-MME) gateways, and the Application Server. This document describes the SCHC parameters supporting static context header compression and fragmentation over the NB-IoT architecture. Ramos & Minaburo Expires 18 June 2023 [Page 2] Internet-Draft LPWAN SCHC NB-IoT December 2022 This document assumes functionality for NB-IoT of 3GPP release 15 [_3GPPR15]. Otherwise, the text explicitly mentions other versions' functionality. This document has two parts, a standard end-to-end scenario describing how any application must use SCHC over the 3GPP public service. And informational scenarios about how 3GPP could use SCHC in their protocol stack network. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology This document will follow the terms defined in [RFC8724], in [RFC8376], and the [TR23720]. * Capillary Gateway. A capillary gateway facilitates seamless integration because it has wide area connectivity through cellular and provides wide area access as a proxy to other devices using LAN technologies (BT, Wi-Fi, Zigbee, or others.) * CIoT EPS. Cellular IoT Evolved Packet System. It is a functionality to improve the support of small data transfers. * Dev-UE. Device - User Equipment. * DoNAS. Data over Non-Access Stratum. * EPC. Evolved Packet Connectivity. Core network of 3GPP LTE systems. * EUTRAN. Evolved Universal Terrestrial Radio Access Network. Radio access network of LTE-based systems. * HARQ. Hybrid Automatic Repeat Request. * HSS. Home Subscriber Server. It is a database that contains users' subscription data, including data needed for mobility management. * IP address. IPv6 or IPv4 address used. Ramos & Minaburo Expires 18 June 2023 [Page 3] Internet-Draft LPWAN SCHC NB-IoT December 2022 * IWK-SCEF. InterWorking Service Capabilities Exposure Function. It is used in roaming scenarios, it is located in the Visited PLMN and serves for interconnection with the SCEF of the Home PLMN. * L2. Layer-2 in the 3GPP architectures it includes MAC, RLC and PDCP layers see Appendix A. * LCID. Logical Channel ID. Is the logical channel instance of the corresponding MAC SDU. * MAC. Medium Access Control protocol, part of L2. * NAS. Non-Access Stratum. * NB-IoT. Narrowband IoT. A 3GPP LPWAN technology based on the LTE architecture but with additional optimization for IoT and using a Narrowband spectrum frequency. * NGW-CSGN. Network Gateway - CIoT Serving Gateway Node. * NGW-CSGW. Network Gateway - Cellular Serving Gateway. It routes and forwards the user data packets through the access network. * NGW-MME. Network Gateway - Mobility Management Entity. An entity in charge of handling mobility of the Dev-UE. * NGW-PGW. Network Gateway - Packet Data Network Gateway. An interface between the internal with the external network. * NGW-SCEF. Network Gateway - Service Capability Exposure Function. EPC node for exposure of 3GPP network service capabilities to 3rd party applications. * NIDD. Non-IP Data Delivery. * PDCP. Packet Data Convergence Protocol part of L2. * PLMN. Public Land Mobile Network. Combination of wireless communication services offered by a specific operator. * PDU. Protocol Data Unit. A data packet including headers that are transmitted between entities through a protocol. * RLC. Radio Link Protocol part of L2. * RGW-eNB. Radio Gateway - evolved Node B. Base Station that controls the UE. Ramos & Minaburo Expires 18 June 2023 [Page 4] Internet-Draft LPWAN SCHC NB-IoT December 2022 * SDU. Service Data Unit. A data packet (PDU) from higher layer protocols used by lower layer protocols as a payload of their own PDUs. 4. NB-IoT Architecture The Narrowband Internet of Things (NB-IoT) architecture has a complex structure. It relies on different NGWs from different providers. It can send data via different paths, each with different characteristics in terms of bandwidth, acknowledgments, and layer-2 reliability and segmentation. Figure 1 shows this architecture, where the Network Gateway Cellular Internet of Things Serving Gateway Node (NGW-CSGN) optimizes co- locating entities in different paths. For example, a Dev-UE using the path formed by the Network Gateway Mobility Management Entity (NGW-MME), the NGW-CSGW, and Network Gateway Packet Data Network Gateway (NGW-PGW) may get a limited bandwidth transmission from a few bytes/s to one thousand bytes/s only. Another node introduced in the NB-IoT architecture is the Network Gateway Service Capability Exposure Function (NGW-SCEF), which securely exposes service and network capabilities to entities external to the network operator. The Open Mobile Alliance (OMA) [OMA0116] and the One Machine to Machine (OneM2M) [TR-0024] define the northbound APIs. [TS23222] defines architecture for the common API framework for 3GPP northbound APIs and [TS33122] defines security aspects for common API framework for 3GPP northbound APIs. In this case, the path is small for data transmission. The main functions of the NGW-SCEF are Connectivity path and Device Monitoring. +---+ +---------+ +------+ |Dev| \ | +-----+ | ---| HSS | |-UE| \ | | NGW | | +------+ +---+ | | |-MME |\__ \ / +-----+ | \ +---+ \+-----+ /| | | +------+ |Dev| ----| RGW |- | | | | NGW- | |-UE| |-eNB | | | | | SCEF |---------+ +---+ /+-----+ \| | | +------+ | / \ +------+| | / |\| NGW- || +-----+ +-----------+ +---+ / | | CSGW |--| NGW-|---|Application| |Dev| | | || | PGW | | Server | |-UE| | +------+| +-----+ +-----------+ +---+ | | |NGW-CSGN | +---------+ Ramos & Minaburo Expires 18 June 2023 [Page 5] Internet-Draft LPWAN SCHC NB-IoT December 2022 Figure 1: 3GPP network architecture 5. Data Transmission in the 3GPP Architecture NB-IoT networks deal with end-to-end user data and in-band signaling between the nodes and functions to configure, control, and monitor the system functions and behaviors. The signaling uses a different path with specific protocols, handling processes, and entities but can transport end-to-end user data for IoT services. In contrast, the end-to-end application only transports end-to-end data. The recommended 3GPP MTU size is 1358 bytes. The radio network protocols limit the packet sizes over the air, including radio protocol overhead, to 1600 bytes, see Section 5.2.3. However, the recommended 3GPP MTU is smaller to avoid fragmentation in the network backbone due to the payload encryption size (multiple of 16) and the additional core transport overhead handling. 3GPP standardizes NB-IoT and, in general, the cellular technologies interfaces and functions. Therefore, the introduction of SCHC entities to Dev-UE, RGW-eNB, and NGW-CSGN needs to be specified in the NB-IoT standard. This document identifies the use cases of SCHC over the NB-IoT architecture. First, the radio transmission where, see Section 5.2.1, the Dev-UE and the RGW-eNB can use the SCHC functionalities. Second, the packets transmitted over the control path can also use SCHC when the transmission goes over the NGW-MME or NGW-SCEF. See Section 5.2.2. These two use cases are also valid for any 3GPP architecture and not only for NB-IoT. And as the 3GPP internal network is involved, they have been put in the informational part of this section. And third, over the SCHC over Non-IP Data Delivery (NIDD) connection or at least up to the operator network edge, see Section 5.1.1. In this case, SCHC functionalities are available in the application layer of the Dev-UE and the Application Servers or a broker function at the edge of the operator network. NGW-PGW or NGW-SCEF transmit the packets which are non-IP traffic, using IP tunneling or API calls. It is also possible to benefit legacy devices with SCHC by using the non-IP transmission features of the operator network. A non-IP transmission refers to other layer-2 transport different from NB-IoT. Ramos & Minaburo Expires 18 June 2023 [Page 6] Internet-Draft LPWAN SCHC NB-IoT December 2022 5.1. Normative Part. This scenarios does not modify the 3GPP architecture or any of its components, it only use it as a layer-2 transmission. 5.1.1. SCHC over Non-IP Data Delivery (NIDD) This section specifies the use of SCHC over Non-IP Data Delivery (NIDD) services of 3GPP. The NIDD services of 3GPP enable the transmission of SCHC packets compressed by the application layer. The packets can be delivered between the NGW-PGW and the Application Server or between the NGW-SCEF and the Application Server, using IP- tunnels or API calls. In both cases, as compression occurs before transmission, the network will not understand the packet, and the network does not have context information of this compression. Therefore, the network will treat the packet as Non-IP traffic and deliver it to the other side without any other protocol stack element, directly over the layer-2. 5.1.1.1. SCHC Entities Placing over NIDD In the two scenarios using NIDD compression, SCHC entities are located almost on top of the stack. The NB-IoT connectivity services implement SCHC in the Dev-UE, an in the Application Server. The IP tunneling scenario requires that the Application Server send the compressed packet over an IP connection terminated by the 3GPP core network. If the transmission uses the NGW-SCEF services, it is possible to utilize an API call to transfer the SCHC packets between the core network and the Application Server. Also, an IP tunnel could be established by the Application Server if negotiated with the NGW-SCEF. +---------+ XXXXXXXXXXXXXXXXXXXXXXXX +--------+ | SCHC | XXX XXX | SCHC | |(Non-IP) +-----XX........................XX....+--*---+(Non-IP)| +---------+ XX +----+ XX | | +--------+ | | XX |SCEF+-------+ | | | | | XXX 3GPP RAN & +----+ XXX +---+ UDP | | | XXX CORE NETWORK XXX | | | | L2 +---+XX +------------+ | +--------+ | | XX |IP TUNNELING+--+ | | | | XXX +------------+ +---+ IP | +---------+ XXXX XXXX | +--------+ | PHY +------+ XXXXXXXXXXXXXXXXXXXXXXX +---+ PHY | +---------+ +--------+ Dev-UE Application Server Ramos & Minaburo Expires 18 June 2023 [Page 7] Internet-Draft LPWAN SCHC NB-IoT December 2022 Figure 2: End-to End Compression. SCHC entities placed when using Non-IP Delivery (NIDD) 3GPP Services 5.1.1.2. Parameters for Static Context Header Compression and Fragmentation (SCHC) These scenarios MAY use SCHC header compression capability to improve the transmission of IPv6 packets. * SCHC Context initialization. The application layer handles the static context; consequently, the context distribution MUST be according to the application's capabilities, perhaps utilizing IP data transmissions up to context initialization. Also, the static contexts delivery may use the same IP tunneling or NGW-SCEF services used later for the SCHC packets transport. * SCHC Rules. For devices acting as a capillary gateway, several rules match the diversity of devices and protocols used by the devices associated with the gateway. Meanwhile, simpler devices may have predetermined protocols and fixed parameters. * Rule ID. This scenario can dynamically set the RuleID size before the context delivery. For example, negotiate between the applications when choosing a profile according to the type of traffic and application deployed. Transmission optimization may require only one physical layer transmission. SCHC overhead SHOULD NOT exceed the available number of effective bits of the smallest physical TB available to optimize the transmission. The packets handled by 3GPP networks are byte-aligned. Thus, to use the smallest TB, the maximum SCHC header size is 12 bits. On the other hand, more complex NB-IoT devices (such as a capillary gateway) might require additional bits to handle the variety and multiple parameters of higher-layer protocols deployed. The configuration may be part of the agreed operation profile and content distribution. The RuleID field size may range from 2 bits, resulting in 4 rules to an 8-bit value that would yield up to 256 rules that can be used with the operators and seems quite a reasonable maximum limit even for a device acting as a NAT. An application may use a larger RuleID, but it should consider the byte alignment of the expected Compression Residue. In the minimum TB size case, 2 bits of RuleID leave only 6 bits available for Compression Residue. Ramos & Minaburo Expires 18 June 2023 [Page 8] Internet-Draft LPWAN SCHC NB-IoT December 2022 * SCHC MAX_PACKET_SIZE. In these scenarios, the maximum RECOMMENDED MTU size is 1358 bytes since the SCHC packets (and fragments) are traversing the whole 3GPP network infrastructure (core and radio), not only the radio as the IP transmissions case. * Fragmentation. Packets larger than 1358 bytes need the SCHC fragmentation function. Since the 3GPP uses reliability functions, the No-ACK fragmentation mode MAY be enough in point-to-point connections. Nevertheless, additional considerations are described below for more complex cases. * Fragmentation modes. A global service assigns a QoS to the packets e.g. depending on the billing. Packets with very low QoS may get lost before arriving in the 3GPP radio network transmission, for example, in between the links of a capillary gateway or due to buffer overflow handling in a backhaul connection. The use of SCHC fragmentation with the ACK-on- Error mode is RECOMMENDED to secure additional reliability on the packets transmitted with a small trade-off on further transmissions to signal the end-to-end arrival of the packets if no transport protocol takes care of retransmission. Also, the ACK-on-Error mode could be desirable to keep track of all the SCHC packets delivered. In that case, the fragmentation function could be activated for all packets transmitted by the applications. SCHC ACK-on-Error fragmentation MAY be activated in transmitting non- IP packets on the NGW-MME. A non-IP packet will use SCHC reserved RuleID for non-compressing packets as [RFC8724] allows it. * Fragmentation Parameters. SCHC profile will have specific Rules for the fragmentation modes. The rule will identify, which fragmentation mode is in use, and section Section 5.2.3 defines the RuleID size. SCHC parametrization considers that NBIoT aligns the bit and uses padding and the size of the Transfer Block. SCHC will try to reduce padding to optimize the compression of the information. The Header size needs to be multiple of 4, and the Tiles MAY keep a fixed value of 4 or 8 bits to avoid padding except for transfer block equals 16 bits where Tiles may be 2 bits. The transfer block size has a wide range of values. Two configurations are RECOMMENDED for the fragmentation parameters. Ramos & Minaburo Expires 18 June 2023 [Page 9] Internet-Draft LPWAN SCHC NB-IoT December 2022 * For Transfer Blocks smaller or equal to 304 bits using an 8-bit Header_size configuration, with the size of the header fields as follows: - RuleID from 1 - 3 bits, - DTag 1 bit, - FCN 3 bits, - W 1 bits. * For Transfer Blocks bigger than 304 bits using a 16-bit Header_size configuration, with the size of the header fields as follows: - RulesID from 8 - 10 bits, - DTag 1 or 2 bits, - FCN 3 bits, - W 2 or 3 bits. * WINDOW_SIZE of 2^N-1 is RECOMMENDED. * RCS will follow the default size defined in section 8.2.3 of the [RFC8724], with a length equal to the L2 Word. * MAX_ACK_REQ is RECOMMENDED to be 2, but applications MAY change this value based on transmission conditions. The IoT devices communicate with small data transfer and use the Power Save Mode and the Idle Mode DRX, which govern how often the device wakes up, stays up, and is reachable. The use of the different modes allows the battery to last ten years. Table 10.5.163a in [TS24008] specifies a range for the radio timers as N to 3N in increments of one where the units of N can be 1 hour or 10 hours. The Inactivity Timer and the Retransmission Timer be set based on these limits. 5.2. Informational Part. These scenarios shows how 3GPP could use SCHC for their transmissions. Ramos & Minaburo Expires 18 June 2023 [Page 10] Internet-Draft LPWAN SCHC NB-IoT December 2022 5.2.1. Use of SCHC over the Radio link Deploying SCHC over the radio link only would require placing it as part of the protocol stack for data transfer between the Dev-UE and the RGW-eNB. This stack is the functional layer responsible for transporting data over the wireless connection and managing radio resources. There is support for features such as reliability, segmentation, and concatenation. The transmissions use link adaptation, meaning that the system will optimize the transport format used according to the radio conditions, the number of bits to transmit, and the power and interference constraints. That means that the number of bits transmitted over the air depends on the selected Modulation and Coding Schemes (MCS). Transport Block (TB) transmissions happen in the physical layer at network-synchronized intervals called Transmission Time Interval (TTI). Each Transport Block has a different MCS and number of bits available to transmit. The MAC layer [TR36321] defines the Transport Blocks' characteristics. The Radio link stack shown in Figure 3 comprises the Packet Data Convergence Protocol (PDCP) [TS36323], Radio Link Protocol (RLC) [TS36322], Medium Access Control protocol (MAC) [TR36321], and the Physical Layer [TS36201]. The Appendix A gives more details about these protocols. +---------+ +---------+ | |IP/non-IP+------------------------------+IP/non-IP+->+ +---------+ | +---------------+ | +---------+ | | PDCP +-------+ PDCP | GTP|U +------+ GTP-U |->+ | (SCHC) + + (SCHC)| + + | | +---------+ | +---------------+ | +---------+ | | RLC +-------+ RLC |UDP/IP +------+ UDP/IP +->+ +---------+ | +---------------+ | +---------+ | | MAC +-------+ MAC | L2 +------+ L2 +->+ +---------+ | +---------------+ | +---------+ | | PHY +-------+ PHY | PHY +------+ PHY +->+ +---------+ +---------------+ +---------+ | C-Uu/ S1-U SGi Dev-UE RGW-eNB NGW-CSGN Radio Link Figure 3: SCHC over the Radio link 5.2.1.1. SCHC Entities Placing over the Radio Link The 3GPP architecture supports Robust Header Compression (ROHC) [RFC5795] in the PDCP layer. Therefore, the architecture can deploy SCHC header compression entities similarly without the need for significant changes in the 3GPP specifications. Ramos & Minaburo Expires 18 June 2023 [Page 11] Internet-Draft LPWAN SCHC NB-IoT December 2022 The RLC layer has three functional modes Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). The mode of operation controls the functionalities of the RLC layer. TM only applies to signaling packets, while AM or UM carry signaling and data packets. The RLC layer takes care of fragmentation unless for the Transparent Mode. In AM or UM modes, the SCHC fragmentation is unnecessary and SHOULD NOT be used. While sending IP packets, the Radio link does not commonly use the RLC Transparent Mode. However, if other protocol overhead optimizations are targeted for NB-IoT traffic, SCHC fragmentation may be used for TM transmission mode in the future. 5.2.2. Use of SCHC over the Non-Access Stratum (NAS) This section consists of IETF suggestions to the 3GPP. The NGW-MME conveys mainly signaling between the Dev-UE and the cellular network [TR24301]. The network transports this traffic on top of the radio link. This kind of flow supports data transmissions to reduce the overhead when transmitting infrequent small quantities of data. This transmission is known as Data over Non-Access Stratum (DoNAS) or Control Plane Cellular Internet of Things (CIoT) evolved packet system (EPS) optimizations. In DoNAS, the Dev-UE uses the pre- established security and can piggyback small uplink data into the initial uplink message and uses an additional message to receive a downlink small data response. The NGW-MME performs the data encryption from the network side in a DoNAS PDU. Depending on the data type signaled indication (IP or non-IP data), the network allocates an IP address or establishes a direct forwarding path. DoNAS is regulated under rate control upon previous agreement, meaning that a maximum number of bits per unit of time is agreed upon per device subscription beforehand and configured in the device. The system will use DoNAS when a terminal in a power-saving state requires a short transmission and receives an acknowledgment or short feedback from the network. Depending on the size of buffered data to transmit, the Dev-UE might deploy the connected mode transmissions instead, limiting and controlling the DoNAS transmissions to predefined thresholds and a good resource optimization balance for the terminal and the network. The support for mobility of DoNAS is present but produces additional overhead. The Appendix B gives additional details of DoNAS. Ramos & Minaburo Expires 18 June 2023 [Page 12] Internet-Draft LPWAN SCHC NB-IoT December 2022 5.2.2.1. SCHC Entities Placing over DoNAS SCHC resides in this scenario's Non-Access Stratum (NAS) protocol layer. The same principles as for the section Section 5.2.1 apply here as well. Because the NAS protocol already uses ROHC [RFC5795], it can also adapt SCHC for header compression. The main difference compared to the radio link, section Section 5.2.1, is the physical placing of the SCHC entities. On the network side, the NGW-MME resides in the core network and is the terminating node for NAS instead of the RGW-eNB. +--------+ +--------+--------+ + +--------+ | IP/ +--+-----------------+--+ IP/ | IP/ +-----+ IP/ | | Non-IP | | | | Non-IP | Non-IP | | | Non-IP | +--------+ | | +-----------------+ | +--------+ | NAS +-----------------------+ NAS |GTP-C/U +-----+GTP-C/U | |(SCHC) | | | | (SCHC) | | | | | +--------+ | +-----------+ | +-----------------+ | +--------+ | RRC +-----+RRC |S1|AP+-----+ S1|AP | | | | | +--------+ | +-----------+ | +--------+ UDP +-----+ UDP | | PDCP* +-----+PDCP*|SCTP +-----+ SCTP | | | | | +--------+ | +-----------+ | +-----------------+ | +--------+ | RLC +-----+ RLC | IP +-----+ IP | IP +-----+ IP | +--------+ | +-----------+ | +-----------------+ | +--------+ | MAC +-----+ MAC | L2 +-----+ L2 | L2 +-----+ L2 | +--------+ | +-----------+ | +-----------------+ | +--------+ | PHY +--+--+ PHY | PHY +--+--+ PHY | PHY +-----+ PHY | +--------+ +-----+-----+ +--------+--------+ | +--------+ C-Uu/ S1 SGi Dev-UE RGW-eNB NGW-MME NGW-PGW *PDCP is bypassed until AS security is activated TGPP36300. Figure 4: SCHC entities placement in the 3GPP CIOT radio protocol architecture for DoNAS transmissions 5.2.3. Parameters for Static Context Header Compression and Fragmentation (SCHC) for the Radio link and DONAS use-cases. If 3GPP incorporates SCHC, it is recommended that these scenarios use SCHC header compression [RFC8724] capability to optimize the data transmission. * SCHC Context initialization. Ramos & Minaburo Expires 18 June 2023 [Page 13] Internet-Draft LPWAN SCHC NB-IoT December 2022 The RRC (Radio Resource Control) protocol is the main tool used to configure the parameters of the Radio link. It will configure SCHC and the static context distribution as it has made for ROHC [RFC5795] operation [TS36323]. * SCHC Rules. The network operator in these scenarios defines the number of rules. For this, the network operator must know the IP traffic the device will carry. The operator might supply rules compatible with the device's use case. For devices acting as a capillary gateway, several rules match the diversity of devices and protocols used by the devices associated with the gateway. Meanwhile, simpler devices may have predetermined protocols and fixed parameters. The use of IPv6 and IPv4 may force to get more rules to deal with each case. * RuleID. There is a reasonable assumption of 9 bytes of radio protocol overhead for these transmission scenarios in NB-IoT, where PDCP uses 5 bytes due to header and integrity protection, and RLC and MAC use 4 bytes. The minimum physical Transport Blocks (TB) that can withhold this overhead value according to 3GPP Release 15 specifications are 88, 104, 120, and 144 bits. As for Section 5.1.1.2, these scenarios must optimize the physical layer where the smallest TB is 12 bits. These 12 bits must include the Compression Residue in addition to the RuleID. On the other hand, more complex NB-IoT devices (such as a capillary gateway) might require additional bits to handle the variety and multiple parameters of higher-layer protocols deployed. In that sense, the operator may want flexibility on the number and type of rules independently supported by each device; consequently, these scenarios require a configurable value. The configuration may be part of the agreed operation profile with the content distribution. The RuleID field size may range from 2 bits, resulting in 4 rules to an 8-bit value that would yield up to 256 rules that can be used with the operators and seems quite a reasonable maximum limit even for a device acting as a NAT. An application may use a larger RuleID, but it should consider the byte alignment of the expected Compression Residue. In the minimum TB size case, 2 bits of RuleID leave only 6 bits available for Compression Residue. * SCHC MAX_PACKET_SIZE. The Radio Link can handle the fragmentation of SCHC packets if needed, including reliability. Hence, the packet size is limited by the MTU handled by the radio protocols, which corresponds to 1600 bytes for 3GPP Release 15. Ramos & Minaburo Expires 18 June 2023 [Page 14] Internet-Draft LPWAN SCHC NB-IoT December 2022 * Fragmentation. For the Radio link Section 5.2.1 and DoNAS' Section 5.2.2 scenarios, the SCHC fragmentation functions are disabled. The RLC layer of NB- IoT can segment packets into suitable units that fit the selected transport blocks for transmissions of the physical layer. The block selection is made according to the link adaptation input function in the MAC layer and the quantity of data in the buffer. The link adaptation layer may produce different results at each Time Transmission Interval (TTI), resulting in varying physical transport blocks that depend on the network load, interference, number of bits transmitted, and QoS. Even if setting a value that allows the construction of data units following the SCHC tiles principle, the protocol overhead may be greater or equal to allowing the Radio link protocols to take care of the fragmentation intrinsically. * Fragmentation in RLC Transparent Mode. The RLC Transparent Mode mostly applies to control signaling transmissions. When RLC operates in Transparent Mode, the MAC layer mechanisms ensure reliability and generate overhead. This additional reliability implies sending repetitions or automatic retransmissions. The ACK-Always fragmentation mode of SCHC may reduce this overhead in future operations when data transmissions may use this mode. ACK- Always mode may transmit compressed data with fewer possible transmissions by using fixed or limited transport blocks compatible with the tiling SCHC fragmentation handling. For SCHC fragmentation parameters see Section 5.1.1.2. 6. Padding NB-IoT and 3GPP wireless access, in general, assumes byte-aligned payload. Therefore, the layer 2 word for NB-IoT MUST be considered 8 bits, and the padding treatment should use this value accordingly. 7. IANA considerations This document has no IANA actions. 8. Security considerations This document does not add any security considerations and follows the [RFC8724] and the 3GPP access security document specified in [TS33122]. 9. References Ramos & Minaburo Expires 18 June 2023 [Page 15] Internet-Draft LPWAN SCHC NB-IoT December 2022 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, . [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", RFC 8824, DOI 10.17487/RFC8824, June 2021, . 9.2. Informative References [OMA0116] OMA, "Common definitions for RESTful Network APIs", 2018, . [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, DOI 10.17487/RFC5795, March 2010, . [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, . [TR-0024] OneM2M, "3GPP_Interworking", 2020, . [TR23720] 3GPP, "Study on architecture enhancements for Cellular Internet of Things", 2015, . Ramos & Minaburo Expires 18 June 2023 [Page 16] Internet-Draft LPWAN SCHC NB-IoT December 2022 [TR24301] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification", 2019, . [TR36321] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification", 2016, . [TS23222] 3GPP, "Common API Framework for 3GPP Northbound APIs", 2022, . [TS24008] 3GPP, "Mobile radio interface layer 3 specification.", 2018, . [TS33122] 3GPP, "Security aspects of Common API Framework (CAPIF) for 3GPP northbound APIs", 2018, . [TS36201] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); LTE physical layer; General description", 2018, . [TS36322] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification", 2018, . [TS36323] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification", 2016, . [TS36331] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification", 2018, . [_3GPPR15] 3GPP, "The Mobile Broadband Standard", 2019, . Appendix A. NB-IoT User Plane protocol architecture Ramos & Minaburo Expires 18 June 2023 [Page 17] Internet-Draft LPWAN SCHC NB-IoT December 2022 A.1. Packet Data Convergence Protocol (PDCP) [TS36323] Each of the Radio Bearers (RB) is associated with one PDCP entity. Moreover, a PDCP entity is associated with one or two RLC entities depending on the unidirectional or bi-directional characteristics of the RB and RLC mode used. A PDCP entity is associated with either a control plane or a user plane with independent configuration and functions. The maximum supported size for NB-IoT of a PDCP SDU is 1600 octets. The primary services and functions of the PDCP sublayer for NB-IoT for the user plane include: * Header compression and decompression using ROHC [RFC5795] * Transfer of user and control data to higher and lower layers * Duplicate detection of lower layer SDUs when re-establishing connection (when RLC with Acknowledge Mode in use for User Plane only) * Ciphering and deciphering * Timer-based SDU discard in uplink A.2. Radio Link Protocol (RLC) [TS36322] RLC is a layer-2 protocol that operates between the UE and the base station (eNB). It supports the packet delivery from higher layers to MAC, creating packets transmitted over the air, optimizing the Transport Block utilization. RLC flow of data packets is unidirectional, and it is composed of a transmitter located in the transmission device and a receiver located in the destination device. Therefore, to configure bi-directional flows, two sets of entities, one in each direction (downlink and uplink), must be configured and effectively peered to each other. The peering allows the transmission of control packets (ex., status reports) between entities. RLC can be configured for data transfer in one of the following modes: * Transparent Mode (TM). RLC does not segment or concatenate SDUs from higher layers in this mode and does not include any header to the payload. RLC receives SDUs from upper layers when acting as a transmitter and transmits directly to its flow RLC receiver via lower layers. Similarly, a TM RLC receiver would only deliver without processing the packets to higher layers upon reception. * Unacknowledged Mode (UM). This mode provides support for segmentation and concatenation of payload. The RLC packet's size depends on the indication given at a particular transmission Ramos & Minaburo Expires 18 June 2023 [Page 18] Internet-Draft LPWAN SCHC NB-IoT December 2022 opportunity by the lower layer (MAC) and is octet-aligned. The packet delivery to the receiver does not include reliability support, and the loss of a segment from a packet means a complete packet loss. Also, in the case of lower layer retransmissions, there is no support for re-segmentation in case of change of the radio conditions triggering the selection of a smaller transport block. Additionally, it provides PDU duplication detection and discards, reordering of out-of-sequence, and loss detection. * Acknowledged Mode (AM). In addition to the same functions supported by UM, this mode also adds a moving windows-based reliability service on top of the lower layer services. It also supports re-segmentation, and it requires bidirectional communication to exchange acknowledgment reports called RLC Status Report and trigger retransmissions. This model also supports protocol error detection. The mode used depends on the operator configuration for the type of data to be transmitted. For example, data transmissions supporting mobility or requiring high reliability would be most likely configured using AM. Meanwhile, streaming and real-time data would be mapped to a UM configuration. A.3. Medium Access Control (MAC) [TR36321] MAC provides a mapping between the higher layers abstraction called Logical Channels comprised by the previously described protocols to the Physical layer channels (transport channels). Additionally, MAC may multiplex packets from different Logical Channels and prioritize what to fit into one Transport Block if there is data and space available to maximize data transmission efficiency. MAC also provides error correction and reliability support through Hybrid Automatic Repeat reQuest (HARQ), transport format selection, and scheduling information reporting from the terminal to the network. MAC also adds the necessary padding and piggyback control elements when possible and the higher layers data. Ramos & Minaburo Expires 18 June 2023 [Page 19] Internet-Draft LPWAN SCHC NB-IoT December 2022 +---+ +---+ +------+ Application |AP1| |AP1| | AP2 | (IP/non-IP) |PDU| |PDU| | PDU | +---+ +---+ +------+ | | | | | | PDCP +--------+ +-------- +-----------+ |PDCP|AP1| |PDCP|AP1| |PDCP| AP2 | |Head|PDU| |Head|PDU| |Head| PDU | +--------+ +--------+ +--------+--\ | | | | | | | | |\ `--------\ +---------------------------+ | |(1)| `-------\(2)\ RLC |RLC |PDCP|AP1|RLC |PDCP|AP1| +-------------+ +----|---+ |Head|Head|PDU|Head|Head|PDU| |RLC |PDCP|AP2| |RLC |AP2| +-------------|-------------+ |Head|Head|PDU| |Head|PDU| | | | | | +---------|---+ +--------+ | | | LCID1 | | / / / / / / / / _/ _// _/ _/ / LCID2 / | | | | | / _/ _/ / ___/ | | | | || | | / / +------------------------------------------+ +-----------+---+ MAC |MAC|RLC|PDCP|AP1|RLC|PDCP|AP1|RLC|PDCP|AP2| |MAC|RLC|AP2|Pad| |Hea|Hea|Hea |PDU|Hea|Hea |PDU|Hea|Hea |PDU| |Hea|Hea|PDU|din| |der|der|der | |der|der | |der|der | | |der|der| |g | +------------------------------------------+ +-----------+---+ TB1 TB2 (1) Segment One (2) Segment Two Figure 5: Example of User Plane packet encapsulation for two transport blocks Appendix B. NB-IoT Data over NAS (DoNAS) The Access Stratum (AS) protocol stack used by DoNAS is specific because the radio network still needs to establish the security associations and reduce the protocol overhead, so the PDCP (Packet Data Convergence Protocol) is bypassed until AS security is activated. RLC (Radio Link Control protocol) uses, by default, the AM mode, but depending on the network's features and the terminal, it may change to other modes by the network operator. For example, the transparent mode does not add any header or process the payload to reduce the overhead, but the MTU would be limited by the transport block used to transmit the data, which is a couple of thousand bits maximum. If UM (only Release 15 compatible terminals) is used, the RLC mechanisms of reliability are disabled, and only the reliability provided by the MAC layer by HARQ is available. In this case, the Ramos & Minaburo Expires 18 June 2023 [Page 20] Internet-Draft LPWAN SCHC NB-IoT December 2022 protocol overhead might be smaller than the AM case because of the lack of status reporting but with the same support for segmentation up to 1600 bytes. NAS packets are encapsulated within an RRC (Radio Resource Control) [TS36331] message. Depending on the data type indication signaled (IP or non-IP data), the network allocates an IP address or establishes a direct forwarding path. DoNAS is regulated under rate control upon previous agreement, meaning that a maximum number of bits per unit of time is agreed upon per device subscription beforehand and configured in the device. The use of DoNAS is typically expected when a terminal in a power-saving state requires a short transmission and receiving an acknowledgment or short feedback from the network. Depending on the size of buffered data to transmit, the UE might be instructed to deploy the connected mode transmissions instead, limiting and controlling the DoNAS transmissions to predefined thresholds and a good resource optimization balance for the terminal the network. The support for mobility of DoNAS is present but produces additional overhead. Ramos & Minaburo Expires 18 June 2023 [Page 21] Internet-Draft LPWAN SCHC NB-IoT December 2022 +--------+ +--------+ +--------+ | | | | | | +-----------------+ | UE | | C-BS | | C-SGN | |Roaming Scenarios| +----|---+ +--------+ +--------+ | +--------+ | | | | | | | | +----------------|------------|+ | | P-GW | | | Attach | | +--------+ | +------------------------------+ | | | | | | | | | +------|------------|--------+ | | | | |RRC Connection Establishment| | | | | |with NAS PDU transmission | | | | | |& Ack Rsp | | | | | +----------------------------+ | | | | | | | | | | | |Initial UE | | | | | |message | | | | | |----------->| | | | | | | | | | | | +---------------------+| | | | | |Checks Integrity || | | | | |protection, decrypts || | | | | |data || | | | | +---------------------+| | | | | | Small data packet | | | |-------------------------------> | | | Small data packet | | | |<------------------------------- | | +----------|---------+ | | | | | Integrity protection,| | | | | | encrypts data | | | | | | +--------------------+ | | | | | | | | | | |Downlink NAS| | | | | |message | | | | | |<-----------| | | | +-----------------------+ | | | | |Small Data Delivery, | | | | | |RRC connection release | | | | | +-----------------------+ | | | | | | | | +-----------------+ Figure 6: DoNAS transmission sequence from an Uplink initiated access Ramos & Minaburo Expires 18 June 2023 [Page 22] Internet-Draft LPWAN SCHC NB-IoT December 2022 +---+ +---+ +---+ +----+ Application |AP1| |AP1| |AP2| |AP2 | (IP/non-IP) |PDU| |PDU| |PDU| ............... |PDU | +---+ +---+ +---+ +----+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |/ / | \ | | NAS /RRC +--------+---|---+----+ +---------+ |NAS/|AP1|AP1|AP2|NAS/| |NAS/|AP2 | |RRC |PDU|PDU|PDU|RRC | |RRC |PDU | +--------+-|-+---+----+ +---------| | | | | | | |\ | | | |<--Max. 1600 bytes-->|__ |_ | | | \__ \___ \_ \ | | \ \ \__ \ | | \ | | \_ +---------------|+-----|----------+ \ \ RLC |RLC | NAS/RRC ||RLC | NAS/RRC | +----|-------+ |Head| PDU(1/2)||Head | PDU (2/2)| |RLC |NAS/RRC| +---------------++----------------+ |Head|PDU | | | | \ | +------------+ | | LCID1 | \ | | / | | | \ \ | | | | | \ \ | | | | | \ \ \ | +----+----+----------++-----|----+---------++----+---------|---+ MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad| |Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | | +----+----+----------++-----+----+---------++----+---------+---+ TB1 TB2 TB3 Figure 7: Example of User Plane packet encapsulation for Data over NAS Appendix C. Acknowledgements The authors would like to thank (in alphabetic order): Carles Gomez, Antti Ratilainen, Tuomas Tirronen, Pascal Thubert, Eric Vyncke. Authors' Addresses Ramos & Minaburo Expires 18 June 2023 [Page 23] Internet-Draft LPWAN SCHC NB-IoT December 2022 Edgar Ramos Ericsson Hirsalantie 11 FI- 02420 Jorvas, Kirkkonummi Finland Email: edgar.ramos@ericsson.com Ana Minaburo Acklio 1137A Avenue des Champs Blancs 35510 Cesson-Sevigne Cedex France Email: ana@ackl.io Ramos & Minaburo Expires 18 June 2023 [Page 24] ./draft-ietf-dots-telemetry-use-cases-15.txt0000644000764400076440000014565514325172570020547 0ustar iustiniustin DOTS Y. Hayashi Internet-Draft NTT Intended status: Informational M. Chen Expires: 26 April 2023 Li. Su CMCC 23 October 2022 Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry draft-ietf-dots-telemetry-use-cases-15 Abstract DDoS Open Threat Signaling (DOTS) Telemetry enriches the base DOTS protocols to assist the mitigator in using efficient DDoS attack mitigation techniques in a network. This document presents sample use cases for DOTS Telemetry. It discusses what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use these techniques. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Hayashi, et al. Expires 26 April 2023 [Page 1] Internet-Draft DOTS Telemetry Use Cases October 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Telemetry Use Cases . . . . . . . . . . . . . . . . . . . . . 3 3.1. Mitigation Resources Assignment . . . . . . . . . . . . . 3 3.1.1. Mitigating Attack Flow of Top-talker Preferentially . . . . . . . . . . . . . . . . . . . 4 3.1.2. DMS Selection for Mitigation . . . . . . . . . . . . 6 3.1.3. Path Selection for Redirection . . . . . . . . . . . 9 3.1.4. Short but Extreme Volumetric Attack Mitigation . . . 11 3.1.5. Selecting Mitigation Technique Based on Attack Type . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Detailed DDoS Mitigation Report . . . . . . . . . . . . . 18 3.3. Tuning Mitigation Resources . . . . . . . . . . . . . . . 21 3.3.1. Supervised Machine Learning of Flow Collector . . . . 21 3.3.2. Unsupervised Machine Learning of Flow Collector . . . 24 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Normative References . . . . . . . . . . . . . . . . . . 26 7.2. Informative References . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction Distributed Denial-of-Service (DDoS) attacks, such as volumetric attacks and resource-consumption attacks, are critical threats to be handled by service providers. When such DDoS attacks occur, service providers have to mitigate them immediately to protect or recover their services. Therefore, for service providers to immediately protect their network services from DDoS attacks, DDoS mitigation needs to be highly automated. To that aim, multivendor components involved in DDoS attack detection and mitigation should cooperate and support standard interfaces. Hayashi, et al. Expires 26 April 2023 [Page 2] Internet-Draft DOTS Telemetry Use Cases October 2022 DDoS Open Threat Signaling (DOTS) is a set of protocols for real-time signaling, threat-handling requests, and data filtering between the multivendor elements [RFC9132][RFC8783]. DOTS Telemetry enriches the DOTS protocols with various telemetry attributes allowing optimal DDoS attack mitigation [RFC9244]. This document presents sample use cases for DOTS Telemetry which makes concrete overview and purpose described in [RFC9244]. This document also presents what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use attack-mitigation techniques. 2. Terminology The readers should be familiar with the terms defined in [RFC8612], [RFC8903] and [RFC9244]. In addition, this document uses the following terms: Top-talker: A list of attack sources that are involved in an attack and which are generating an important part of the attack traffic. Supervised Machine Learning: A machine-learning technique in which labeled data is used to train the algorithms (the input and output data are known). Unsupervised Machine Learning: A machine learning technique in which unlabeled data is used to train the algorithms (the data has no historical labels). 3. Telemetry Use Cases This section describes DOTS telemetry use cases that use attributes included in the DOTS telemetry specification [RFC9244]. The following subsections assume that once the DOTS signal channel is established, DOTS clients proceed with the telemetry setup configuration as detailed in Section 7 of [RFC9244]. The following telemetry parameters are used: * 'measurement-interval' to define the period during which percentiles are computed. * 'measurement-sample' to define the time distribution for measuring values that are used to compute percentiles. 3.1. Mitigation Resources Assignment Hayashi, et al. Expires 26 April 2023 [Page 3] Internet-Draft DOTS Telemetry Use Cases October 2022 3.1.1. Mitigating Attack Flow of Top-talker Preferentially Some transit providers have to mitigate large-scale DDoS attacks by using DDoS Mitigation Systems (DMSes) with limited resources, which are already deployed in their network. For example, recently reported large DDoS attacks exceeded several Tbps. [DOTS_Overview] This use case enables transit providers to use their DMS efficiently under volume-based DDoS attacks whose volume is more than the available capacity of the DMS. To enable this, the attack traffic of top-talkers is redirected to the DMS preferentially by cooperation among forwarding nodes, flow collectors, and orchestrators. Figure 1 gives an overview of this use case. Figure 2 provides an example of a DOTS telemetry message body that is used to signal top- talkers (2001:db8:1::/48 and 2001:db8:2::/48). (Internet Transit Provider) +-----------+ +--------------+ SNMP or YANG/NETCONF IPFIX +-----------+| DOTS | |<--- --->| Flow ||C<-->S| Orchestrator | BGP Flowspec | collector |+ | |---> (Redirect) +-----------+ +--------------+ +-------------+ IPFIX +-------------+| BGP Flowspec (Redirect) <---| Forwarding ||<--- | nodes || | || DDoS Attack [ Target(s) ]<========================================== | ++=========================[top-talker] | || ++======================[top-talker] +----|| ||---+ || || || || |/ |/ +----x--x----+ | DDoS | SNMP or YANG/NETCONF | mitigation |<--- | system | +------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 1: Mitigating DDoS Attack Flow of Top-talkers Preferentially Hayashi, et al. Expires 26 April 2023 [Page 4] Internet-Draft DOTS Telemetry Use Cases October 2022 { "ietf-dots-telemetry:telemetry": { "pre-or-ongoing-mitigation": [ { "target": { "target-prefix": [ "2001:db8::1/128" ] }, "total-attack-traffic-protocol": [ { "protocol": 17, "unit": "megabit-ps", "mid-percentile-g": "900" } ], "attack-detail": [ { "vendor-id": 32473, "attack-id": 77, "start-time": "1645057211", "attack-severity": "high", "top-talker":{ "talker": [ { "source-prefix": "2001:db8:1::/48", "total-attack-traffic": [ { "unit": "megabit-ps", "mid-percentile-g": "100" } ] }, { "source-prefix": "2001:db8:2::/48", "total-attack-traffic": [ { "unit": "megabit-ps", "mid-percentile-g": "90" } ] } ] } } ] } ] Hayashi, et al. Expires 26 April 2023 [Page 5] Internet-Draft DOTS Telemetry Use Cases October 2022 } } Figure 2: An Example of Message Body to Signal Top-Talkers The forwarding nodes send traffic statistics to the flow collectors, e.g., using IP Flow Information Export (IPFIX) [RFC7011]. When DDoS attacks occur, the flow collectors identify the attack traffic and send information about the top-talkers to the orchestrator using the "target-prefix" and "top-talkers" DOTS telemetry attributes. The orchestrator then checks the available capacity of the DMSes by using a network management protocol, such as Simple Network Management Protocol (SNMP) [RFC3413] or YANG with Network Configuration Protocol (YANG/NETCONF) [RFC7950]. After that, the orchestrator orders the forwarding nodes to redirect as much of the top-talker's traffic to each DMS as that DMS can handle by dissemination of Flow Specifications using tools such as Border Gateway Protocol Dissemination of Flow Specification Rules (BGP Flowspec) [RFC8955]. The flow collector implements a DOTS client while the orchestrator implements a DOTS server. 3.1.2. DMS Selection for Mitigation Transit providers can deploy their DMSes in clusters. Then, they can select the DMS to be used to mitigate a DDoS attack at the time of an attack. This use case enables transit providers to select a DMS with sufficient capacity for mitigation based on the volume of the attack traffic and the capacity of a DMS. Figure 3 gives an overview of this use case. Figure 4 provides an example of a DOTS telemetry message body that is used to signal various attack traffic percentiles. Hayashi, et al. Expires 26 April 2023 [Page 6] Internet-Draft DOTS Telemetry Use Cases October 2022 (Internet Transit Provider) +-----------+ +--------------+ SNMP or YANG/NETCONF IPFIX +-----------+| DOTS | |<--- --->| Flow ||C<-->S| Orchestrator | BGP (Redirect) | collector |+ | |---> +-----------+ +--------------+ +------------+ IPFIX +------------+| BGP (Redirect) <---| Forwarding ||<--- | nodes || | || DDoS Attack [Target A] | ++=================== [Destined for Target A] [Target B] | || ++=============== [Destined for Target B] +-||--||-----+ || || ++====++ || (congested DMS) || || +-----------+ || |/ | DMS3 | || +-----x------+ |<--- SNMP or YANG/NETCONF |/ | DMS2 |--------+ +--x---------+ |<--- SNMP or YANG/NETCONF | DMS1 |------+ | |<--- SNMP or YANG/NETCONF +------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 3: DMS Selection for Mitigation Hayashi, et al. Expires 26 April 2023 [Page 7] Internet-Draft DOTS Telemetry Use Cases October 2022 { "ietf-dots-telemetry:telemetry": { "pre-or-ongoing-mitigation": [ { "target": { "target-prefix": [ "192.0.2.3/32" ] }, "total-attack-traffic": [ { "unit": "megabit-ps", "low-percentile-g": "600", "mid-percentile-g": "800", "high-percentile-g": "1000", "peak-g":"1100", "current-g":"700" } ] } ] } } Figure 4: Example of Message Body with Total Attack Traffic The forwarding nodes send traffic statistics to the flow collectors, e.g., using IPFIX. When DDoS attacks occur, the flow collectors identify the attack traffic and send information about the attack traffic volume to the orchestrator by using the "target-prefix" and "total-attack-traffic" DOTS telemetry attributes. The orchestrator then checks the available capacity of the DMSes by using a network management protocol, such as Simple Network Management Protocol (SNMP) [RFC3413] or YANG with Network Configuration Protocol (YANG/ NETCONF) [RFC7950]. After that, the orchestrator selects a DMS with sufficient capacity to which attack traffic should be redirected. For example, a simple DMS selection algorithm is to choose a DMS whose available capacity is greater than the "peak-g" attribute indicated in the DOTS telemetry message. The orchestrator orders the appropriate forwarding nodes to redirect the attack traffic to the DMS relying upon routing policies, such as BGP [RFC4271]. The detailed DMS selection algorithm is out of the scope of this document. The flow collector implements a DOTS client while the orchestrator implements a DOTS server. Hayashi, et al. Expires 26 April 2023 [Page 8] Internet-Draft DOTS Telemetry Use Cases October 2022 3.1.3. Path Selection for Redirection A transit provider network has multiple paths to convey attack traffic to a DMS. In such a network, the attack traffic can be conveyed while avoiding congested links by adequately selecting an available path. This use case enables transit providers to select a path with sufficient bandwidth for redirecting attack traffic to a DMS according to the bandwidth of the attack traffic and total traffic. Figure 5 gives an overview of this use case. Figure 6 provides an example of a DOTS telemetry message body that is used to signal various attack traffic percentiles and total traffic percentiles. (Internet Transit Provider) +-----------+ +--------------+ DOTS +-----------+| | |S<--- IPFIX | Flow || DOTS | Orchestrator | -->| collector ||C<-->S| | BGP Flowspec (Redirect) | |+ | |---> +-----------+ +--------------+ DOTS +------------+ DOTS +------------+ IPFIX --->C| Forwarding | --->C| Forwarding |---> BGP Flowspec | node | | node | (Redirect) --->| | | | DDoS Attack [Target] | ++==================================== +-------||---+ +------------+ || / || / (congested link) || / DOTS +-||----------------+ BGP Flowspec (Redirect) --->C| || Forwarding |<--- | ++=== node | +----||-------------+ |/ +--x-----------+ | DMS | +--------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 5: Path Selection for Redirection Hayashi, et al. Expires 26 April 2023 [Page 9] Internet-Draft DOTS Telemetry Use Cases October 2022 { "ietf-dots-telemetry:telemetry": { "pre-or-ongoing-mitigation": [ { "target": { "target-prefix": [ "2001:db8::1/128" ] }, "total-traffic": [ { "unit": "megabit-ps", "mid-percentile-g": "1300", "peak-g": "800" } ], "total-attack-traffic": [ { "unit": "megabit-ps", "low-percentile-g": "600", "mid-percentile-g": "800", "high-percentile-g": "1000", "peak-g": "1100", "current-g": "700" } ] } ] } } Figure 6: An Example of Message Body with Total Attack Traffic and Total Traffic Hayashi, et al. Expires 26 April 2023 [Page 10] Internet-Draft DOTS Telemetry Use Cases October 2022 The forwarding nodes send traffic statistics to the flow collectors, e.g., using IPFIX. When DDoS attacks occur, the flow collectors identify attack traffic and send information about the attack traffic volume to the orchestrator by using "target-prefix" and "total- attack-traffic" DOTS telemetry attributes. The underlying forwarding nodes send the volume on the total traffic passing the node to the orchestrator by using "total-traffic" telemetry attributes. The orchestrator then selects a path with sufficient bandwidth to which attack-traffic flow should be redirected. For example, the simple algorithm of the selection is to choose a path whose available capacity is greater than the "peak-g" attribute that was indicated in a DOTS telemetry message. After that, the orchestrator orders the appropriate forwarding nodes to redirect the attack traffic to the DMS by dissemination of Flow Specifications using tools such as Border Gateway Protocol Dissemination of Flow Specification Rules (BGP Flowspec) [RFC8955]. The detailed path selection algorithm is out of the scope of this document. The flow collector and forwarding nodes implement a DOTS client while the orchestrator implements a DOTS server. 3.1.4. Short but Extreme Volumetric Attack Mitigation Short but extreme volumetric attacks, such as pulse wave DDoS attacks, are threats to Internet transit provider networks. These attacks start from zero and go to maximum values in a very short time span, then go back to zero, and then back to maximum, repeating in continuous cycles at short intervals. It is difficult for the transit providers to mitigate such an attack with their DMSes using a redirecting attack flows because this may cause route flapping in the network. The practical way to mitigate short but extreme volumetric attacks is to offload mitigation actions to a forwarding node. This use case enables transit providers to mitigate short but extreme volumetric attacks. Furthermore, the aim is to estimate the network- access success rate based on the bandwidth of the attack traffic. Figure 7 gives an overview of this use case. Figure 8 provides an example of a DOTS telemetry message body that is used to signal total pipe capacity. Figure 9 provides an example of a DOTS telemetry message body that is used to signal various attack traffic percentiles and total traffic percentiles. Hayashi, et al. Expires 26 April 2023 [Page 11] Internet-Draft DOTS Telemetry Use Cases October 2022 (Internet Transit Provider) +------------+ +----------------+ | Network | DOTS | Administrative | Alert ----->| Management |C<--->S| System | BGP Flowspec (Rate-Limit) | System | | |---> +------------+ +----------------+ +------------+ +------------+ BGP Flowspec (Rate-Limit X bps) | Forwarding | | Forwarding |<--- | node | | node | Link1 | | | | DDoS & Normal traffic [Target]<------------------------------------================ Pipe +------------+ +------------+ Attack Traffic Capability Bandwidth X bps Y bps Network access success rate X / (X + Y) * C is for DOTS client functionality * S is for DOTS server functionality Figure 7: Short but Extreme Volumetric Attack Mitigation { "ietf-dots-telemetry:telemetry-setup": { "telemetry": [ { "total-pipe-capacity": [ { "link-id": "link1", "capacity": "1000", "unit": "megabit-ps" } ] } ] } } Figure 8: Example of Message Body with Total Pipe Capacity Hayashi, et al. Expires 26 April 2023 [Page 12] Internet-Draft DOTS Telemetry Use Cases October 2022 { "ietf-dots-telemetry:telemetry": { "pre-or-ongoing-mitigation": [ { "target": { "target-prefix": [ "2001:db8::1/128" ] }, "total-traffic": [ { "unit": "megabit-ps", "mid-percentile-g": "800", "peak-g": "1300" } ], "total-attack-traffic": [ { "unit": "megabit-ps", "low-percentile-g": "200", "mid-percentile-g": "400", "high-percentile-g": "500", "peak-g": "600", "current-g": "400" } ] } ] } } Figure 9: Example of Message Body with Total Attack Traffic, and Total Traffic When DDoS attacks occur, the network management system receives alerts. Then, it sends the target IP address(es) and volume of the DDoS attack traffic to the administrative system by using the "target-prefix" and "total-attack-traffic" DOTS telemetry attributes. After that, the administrative system orders relevant forwarding nodes to carry out rate-limiting of all traffic destined to the target based on the pipe capability by the dissemination of the Flow Specifications using tools such as Border Gateway Protocol Dissemination of Flow Specification Rules (BGP Flowspec) [RFC8955]. In addition, the administrative system estimates the network-access success rate of the target, which is calculated by (total-pipe- capability / (total-pipe-capability + total-attack-traffic)). Hayashi, et al. Expires 26 April 2023 [Page 13] Internet-Draft DOTS Telemetry Use Cases October 2022 Note that total pipe capability information can be gathered by telemetry setup in advance (Section 7.2 of [RFC9244]). The network management system implements a DOTS client while the administrative system implements a DOTS server. 3.1.5. Selecting Mitigation Technique Based on Attack Type Some volumetric attacks, such as DNS amplification attacks, can be detected with high accuracy by checking the Layer 3 or Layer 4 information of attack packets. These attacks can be detected and mitigated through cooperation among forwarding nodes and flow collectors by using IPFIX. It may also be necessary to inspect the Layer 7 information of suspicious packets to detect attacks such as DNS Water Torture Attacks [DNS_Water_Torture_Attack]. To carry out the DNS water torture attack, an attacker commands a botnet to make thousands of DNS requests for fake subdomains against an Authoritative Name Server. Such attack traffic should be detected and mitigated at the DMS. This use case enables transit providers to select a mitigation technique based on the type of attack traffic: amplification attack or not. To use such a technique, the attack traffic is blocked by forwarding nodes or redirected to a DMS based on the attack type through cooperation among forwarding nodes, flow collectors, and an orchestrator. Figure 10 gives an overview of this use case. Figure 11 provides an example of attack mappings that are shared by using the DOTS data channel in advance. Figure 12 provides an example of a DOTS telemetry message body that is used to signal various attack traffic percentiles, total traffic percentiles, total attack connection, and attack type. The example in Figure 11 uses the folding defined in [RFC8792] for long lines. Hayashi, et al. Expires 26 April 2023 [Page 14] Internet-Draft DOTS Telemetry Use Cases October 2022 (Internet Transit Provider) +-----------+ DOTS +--------------+ +-----------+|<---->| | BGP (Redirect) IPFIX | Flow ||C S| Orchestrator | BGP Flowspec (Drop) --->| collector |+ | |---> +-----------+ +--------------+ +------------+ BGP (Redirect) IPFIX +------------+| BGP Flowspec (Drop) <---| Forwarding ||<--- | nodes || DDoS Attack | ++=====||================ | || ||x<==============[DNS Amp] | || |+x<==============[NTP Amp] +-----||-----+ || |/ +-----x------+ | DDoS | | mitigation | | system | +------------+ * C is for DOTS client functionality * S is for DOTS server functionality * DNS Amp: DNS Amplification * NTP Amp: NTP Amplification Figure 10: DDoS Mitigation Based on Attack Type Hayashi, et al. Expires 26 April 2023 [Page 15] Internet-Draft DOTS Telemetry Use Cases October 2022 =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-dots-mapping:vendor-mapping": { "vendor": [ { "vendor-id": 32473, "vendor-name": "mitigator-c", "last-updated": "1629898958", "attack-mapping": [ { "attack-id": 77, "attack-description": "DNS amplification Attack: \ This attack is a type of reflection attack in which attackers \ spoof a target's IP address. The attackers abuse vulnerabilities \ in DNS servers to turn small queries into larger payloads." }, { "attack-id": 92, "attack-description":"NTP amplification Attack: \ This attack is a type of reflection attack in which attackers \ spoof a target's IP address. The attackers abuse vulnerabilities \ in NTP servers to turn small queries into larger payloads." } ] } ] } } Figure 11: Example of Message Body with Attack Mappings { "ietf-dots-telemetry:telemetry": { "pre-or-ongoing-mitigation": [ { "target": { "target-prefix": [ "2001:db8::1/128" ] }, "total-attack-traffic": [ { "unit": "megabit-ps", "low-percentile-g": "600", "mid-percentile-g": "800", "high-percentile-g": "1000", "peak-g": "1100", Hayashi, et al. Expires 26 April 2023 [Page 16] Internet-Draft DOTS Telemetry Use Cases October 2022 "current-g": "700" } ], "total-attack-traffic-protocol": [ { "protocol": 17, "unit": "megabit-ps", "mid-percentile-g": "500" }, { "protocol": 15, "unit": "megabit-ps", "mid-percentile-g": "200" } ], "total-attack-connection": [ { "mid-percentile-l": [ { "protocol": 15, "connection": 200 } ], "high-percentile-l": [ { "protocol": 17, "connection": 300 } ] } ], "attack-detail": [ { "vendor-id": 32473, "attack-id": 77, "start-time": "1641169211", "attack-severity": "high" }, { "vendor-id": 32473, "attack-id": 92, "start-time": "1641172809", "attack-severity": "high" } ] } ] } Hayashi, et al. Expires 26 April 2023 [Page 17] Internet-Draft DOTS Telemetry Use Cases October 2022 } Figure 12: Example of Message Body with Total Attack Traffic, Total Attack Traffic Protocol, Total Attack Connection and Attack Type Attack mappings are shared by using the DOTS data channel in advance (Section 8.1.6 of [RFC9244]). The forwarding nodes send traffic statistics to the flow collectors, e.g., using IPFIX. When DDoS attacks occur, the flow collectors identify attack traffic and send attack type information to the orchestrator by using "vendor-id" and "attack-id" telemetry attributes. The orchestrator then resolves abused port numbers and orders relevant forwarding nodes to block the amplification attack traffic flow by dissemination of Flow Specifications using tools such as Border Gateway Protocol Dissemination of Flow Specification Rules (BGP Flowspec) [RFC8955]. Also, the orchestrator orders relevant forwarding nodes to redirect other traffic than the amplification attack traffic by using a routing protocol, such as BGP [RFC4271]. The flow collector implements a DOTS client while the orchestrator implements a DOTS server. 3.2. Detailed DDoS Mitigation Report It is possible for the transit provider to add value to the DDoS mitigation service by reporting ongoing and detailed DDoS countermeasure status to the enterprise network. In addition, it is possible for the transit provider to know whether the DDoS countermeasure is effective or not by receiving reports from the enterprise network. This use case enables sharing of information about ongoing DDoS countermeasures between the transit provider and the enterprise network mutually. Figure 13 gives an overview of this use case. Figure 14 provides an example of a DOTS telemetry message body that is used to signal total pipe capacity from the enterprise network administrator to the orchestrator in the ISP. Figure 15 provides an example of a DOTS telemetry message body that is used to signal various total traffic percentiles, total attack traffic percentiles, and attack details from the orchestrator to the network. Hayashi, et al. Expires 26 April 2023 [Page 18] Internet-Draft DOTS Telemetry Use Cases October 2022 +------------------+ +------------------------+ | Enterprise | | Upstream | | Network | | Internet Transit | | +------------+ | | Provider | | | Network |C | | S+--------------+ | | | admini- |<-----DOTS---->| Orchestrator | | | | strator | | | +--------------+ | | +------------+ | | C ^ | | | | | DOTS | | | | S v | | | | +---------------+ DDoS Attack | | | | DMS |+======= | | | +---------------+ | | | | || Clean | | | | |/ Traffic | | +---------+ | | +---------------+ | | | DDoS | | | | Forwarding | Normal Traffic | | Target |<================| Node |======== | +---------+ | Link1 | +---------------+ | +------------------+ +------------------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 13: Detailed DDoS Mitigation Report { "ietf-dots-telemetry:telemetry-setup": { "telemetry": [ { "total-pipe-capacity": [ { "link-id": "link1", "capacity": "1000", "unit": "megabit-ps" } ] } ] } } Figure 14: An Example of Message Body with Total Pipe Capacity Hayashi, et al. Expires 26 April 2023 [Page 19] Internet-Draft DOTS Telemetry Use Cases October 2022 { "ietf-dots-telemetry:telemetry": { "pre-or-ongoing-mitigation": [ { "tmid": 567, "target": { "target-prefix": [ "2001:db8::1/128" ] }, "target-protocol": [ 17 ], "total-traffic": [ { "unit": "megabit-ps", "mid-percentile-g": "800" } ], "total-attack-traffic": [ { "unit": "megabit-ps", "mid-percentile-g": "100" } ], "attack-detail": [ { "vendor-id": 32473, "attack-id": 77, "start-time": "1644819611", "attack-severity": "high" } ] } ] } } Figure 15: An Example of Message Body with Total Traffic, Total Attack Traffic Protocol, and Attack Detail The network management system in the enterprise network reports limits of incoming traffic volume from the transit provider to the orchestrator in the transit provider in advance. It is reported by using the "total-pipe-capacity" telemetry attribute in the DOTS telemetry setup. Hayashi, et al. Expires 26 April 2023 [Page 20] Internet-Draft DOTS Telemetry Use Cases October 2022 When DDoS attacks occur, DDoS mitigation orchestration [RFC8903] is carried out in the transit provider. Then, the DDoS mitigation systems report the status of DDoS countermeasures to the orchestrator by sending "attack-detail" telemetry attributes. After that, the orchestrator integrates the reports from the DDoS mitigation systems, while removing duplicate contents, and sends the integrated report to a network administrator by using DOTS telemetry periodically. During the DDoS mitigation, the orchestrator in the transit provider retrieves link congestion status from the network manager in the enterprise network by using "total-traffic" telemetry attributes. Then, the orchestrator checks whether the DDoS countermeasures are effective or not by comparing the "total-traffic" and the "total- pipe-capacity" attributes. The DMS implements a DOTS server while the orchestrator behaves as a DOTS client and a server in the transit provider. In addition, the network administrator implements a DOTS client. 3.3. Tuning Mitigation Resources 3.3.1. Supervised Machine Learning of Flow Collector DDoS detection based on tools, such as IPFIX, is a lighter weight method of detecting DDoS attacks than DMSes in Internet transit provider networks. DDoS detection based on the DMSes is a more accurate method for detecting attack traffic than flow monitoring. The aim of this use case is to increase flow collectors' detection accuracy by carrying out supervised machine-learning techniques according to attack detail reported by the DMSes. To use such a technique, forwarding nodes, flow collectors, and a DMS should cooperate. Figure 16 gives an overview of this use case. Figure 17 provides an example of a DOTS telemetry message body that is used to signal various total attack traffic percentiles and attack detail. Hayashi, et al. Expires 26 April 2023 [Page 21] Internet-Draft DOTS Telemetry Use Cases October 2022 +-----------+ +-----------+| DOTS IPFIX | Flow ||S<--- --->| collector || +-----------++ +------------+ IPFIX +------------+| <---| Forwarding || | nodes || DDoS Attack [ Target ] | ++============================== | || ++=========================== | || || ++======================== +---||-|| ||-+ || || || |/ |/ |/ DOTS +---X--X--X--+ --->C| DDoS | | mitigation | | system | +------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 16: Training Supervised Machine Learning of Flow Collectors Hayashi, et al. Expires 26 April 2023 [Page 22] Internet-Draft DOTS Telemetry Use Cases October 2022 { "ietf-dots-telemetry:telemetry": { "pre-or-ongoing-mitigation": [ { "target": { "target-prefix": [ "2001:db8::1/128" ] }, "attack-detail": [ { "vendor-id": 32473, "attack-id": 77, "start-time": "1634192411", "attack-severity": "high", "top-talker": { "talker": [ { "source-prefix": "2001:db8::2/127" } ] } } ] } ] } } Figure 17: An Example of Message Body with Attack Type and top-talkers The forwarding nodes send traffic statistics to the flow collectors, e.g., using IPFIX. When DDoS attacks occur, DDoS mitigation orchestration is carried out (as per Section 3.3 of [RFC8903]) and the DMS mitigates all attack traffic destined for a target. The DDoS mitigation system reports the "vendor-id", "attack-id", and "top- talker" telemetry attributes to a flow collector. After mitigating a DDoS attack, the flow collector attaches outputs of the DMS as labels to the statistics of traffic flow of top- talkers. The outputs, for example, are the "attack-id" telemetry attributes. The flow collector then carries out supervised machine learning to increase its detection accuracy, setting the statistics as an explanatory variable and setting the labels as an objective variable. Hayashi, et al. Expires 26 April 2023 [Page 23] Internet-Draft DOTS Telemetry Use Cases October 2022 The DMS implements a DOTS client while the flow collector implements a DOTS server. 3.3.2. Unsupervised Machine Learning of Flow Collector DMSes can detect DDoS attack traffic, which means DMSes can also identify clean traffic. This use case supports unsupervised machine- learning for anomaly detection according to a baseline reported by the DMSes. To use such a technique, forwarding nodes, flow collectors, and a DMS should cooperate. Figure 18 gives an overview of this use case. Figure 19 provides an example of a DOTS telemetry message body that is used to signal baseline. +-----------+ +-----------+| DOTS | Flow || --->S| collector || +-----------++ +------------+ +------------+| | Forwarding || | nodes || Traffic [ Destination ] <== =============++============================== | || || | || |+ +---||-------+ || |/ DOTS +---X--------+ --->C| DDoS | | mitigation | | system | +------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 18: Training Unsupervised Machine Learning of Flow Collectors Hayashi, et al. Expires 26 April 2023 [Page 24] Internet-Draft DOTS Telemetry Use Cases October 2022 { "ietf-dots-telemetry:telemetry-setup": { "telemetry": [ { "baseline": [ { "id": 1, "target-prefix": [ "2001:db8:6401::1/128" ], "target-port-range": [ { "lower-port": "53" } ], "target-protocol": [ 17 ], "total-traffic-normal": [ { "unit": "megabit-ps", "low-percentile-g": "30", "mid-percentile-g": "50", "high-percentile-g": "60", "peak-g": "70" } ] } ] } ] } } Figure 19: An Example of Message Body with Traffic Baseline The forwarding nodes carry out traffic mirroring to copy the traffic destined an IP address and to monitor the traffic by a DMS. The DMS then identifies "clean" traffic and reports the baseline attributes to the flow collector by using DOTS telemetry. The flow collector then carries out unsupervised machine learning to be able to carry out anomaly detection. The DMS implements a DOTS client while the flow collector implements a DOTS server. Hayashi, et al. Expires 26 April 2023 [Page 25] Internet-Draft DOTS Telemetry Use Cases October 2022 4. Security Considerations DOTS telemetry security considerations are discussed in Section 14 of [RFC9244]. These considerations apply for the communication interfaces where DOTS is used. Some use cases involve controllers, orchestrators, and programmable interfaces. These interfaces can be misused by misbehaving nodes to further exacerbate DDoS attacks. The considerations are for end-to- end systems for DoS mitigation, so the mechanics are outside the scope of DOTS protocols. Section 5 of [RFC7149] discusses some generic security considerations to take into account in such contexts (e.g., reliable access control). Specific security measures depend on the actual mechanism used to control underlying forwarding nodes and other controlled elements. For example, Section 13 of [RFC8955] discusses security considerations that are relevant to BGP Flowspec. IPFIX-specific considerations are discussed in Section 11 of [RFC7011]. 5. IANA Considerations This document does not require any action from IANA. 6. Acknowledgement The authors would like to thank Mohamed Boucadair and Valery Smyslov for their valuable feedback. Thanks to Paul Wouters for the detailed AD review. Many thanks to Donald Eastlake, Phillip Hallam-Baker, Sean Turner, and Peter Yee for the AD review. Thanks to Lars Eggert, Murray Kucherawy, Roman Danyliw, Robert Wiltonm, and Eric Vyncke for the IESG review. 7. References 7.1. Normative References [RFC9244] Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M., and J. Shallow, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry", RFC 9244, DOI 10.17487/RFC9244, June 2022, . 7.2. Informative References Hayashi, et al. Expires 26 April 2023 [Page 26] Internet-Draft DOTS Telemetry Use Cases October 2022 [DNS_Water_Torture_Attack] Xi, L., "A Large Scale Analysis of DNS Water Torture Attack", DOI 10.1145/3297156.3297272, December 2018, . [DOTS_Overview] Reddy, T. and M. Boucadair, "DOTS Overview (RFCs 8782, 8783)", July 2020, . [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, DOI 10.17487/RFC3413, December 2002, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open Threat Signaling (DOTS) Requirements", RFC 8612, DOI 10.17487/RFC8612, May 2019, . [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", RFC 8783, DOI 10.17487/RFC8783, May 2020, . Hayashi, et al. Expires 26 April 2023 [Page 27] Internet-Draft DOTS Telemetry Use Cases October 2022 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, . [RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use Cases for DDoS Open Threat Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021, . [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, . [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 9132, DOI 10.17487/RFC9132, September 2021, . Authors' Addresses Yuhei Hayashi NTT 3-9-11, Midori-cho, Tokyo 180-8585 Japan Email: yuuhei.hayashi@gmail.com Meiling Chen CMCC 32, Xuanwumen West BeiJing BeiJing, 100053 China Email: chenmeiling@chinamobile.com Li Su CMCC 32, Xuanwumen West BeiJing, BeiJing 100053 China Email: suli@chinamobile.com Hayashi, et al. Expires 26 April 2023 [Page 28] ./draft-ietf-tls-subcerts-15.txt0000644000764400076440000011640014252473120016306 0ustar iustiniustin Network Working Group R. Barnes Internet-Draft Cisco Intended status: Standards Track S. Iyengar Expires: 17 December 2022 Facebook N. Sullivan Cloudflare E. Rescorla Mozilla 15 June 2022 Delegated Credentials for (D)TLS draft-ietf-tls-subcerts-15 Abstract The organizational separation between operators of TLS and DTLS endpoints and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism to to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility with peers that do not support this specification. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/tls-subcerts (https://github.com/tlswg/tls- subcerts). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 17 December 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 2. Conventions and Terminology 2.1. Change Log 3. Solution Overview 3.1. Rationale 3.2. Related Work 4. Delegated Credentials 4.1. Client and Server Behavior 4.1.1. Server Authentication 4.1.2. Client Authentication 4.1.3. Validating a Delegated Credential 4.2. Certificate Requirements 5. Operational Considerations 5.1. Client Clock Skew 6. IANA Considerations 7. Security Considerations 7.1. Security of Delegated Credential's Private Key 7.2. Re-use of Delegated Credentials in Multiple Contexts 7.3. Revocation of Delegated Credentials 7.4. Interactions with Session Resumption 7.5. Privacy Considerations 7.6. The Impact of Signature Forgery Attacks 8. Acknowledgements 9. References 9.1. Normative References 9.2. Informative References Appendix A. ASN.1 Module Appendix B. Example Certificate Authors' Addresses 1. Introduction Server operators often deploy (D)TLS termination to act as the server for inbound TLS connections. These termination services can be in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect compromises of private key material corresponding to TLS certificates. Short-lived certificates may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently than long-lived certificates. If an external Certification Authority (CA) is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the TLS-fronted service. Typically, a (D)TLS server uses a certificate provided by some entity other than the operator of the server (a CA) [RFC8446] [RFC5280]. This organizational separation makes the (D)TLS server operator dependent on the CA for some aspects of its operations, for example: * Whenever the server operator wants to deploy a new certificate, it has to interact with the CA. * The CA might only issue credentials containing certain types of public key, which can limit the set of (D)TLS signature schemes usable by the server operator. To reduce the dependency on external CAs, this document specifies a limited delegation mechanism that allows a (D)TLS peer to issue its own credentials within the scope of a certificate issued by an external CA. These credentials only enable the recipient of the delegation to terminate connections for names that the CA has authorized. Furthermore, this mechanism allows the server to use modern signature algorithms such as Ed25519 [RFC8032] even if their CA does not support them. This document refers to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential" or "DC". Client Front-End Back-End | |<--DC distribution->| |----ClientHello--->| | |<---ServerHello----| | |<---Certificate----| | |<---CertVerify-----| | | ... | | Legend: Client: (D)TLS client Front-End: (D)TLS server (could be a TLS-termination service like a CDN) Back-End: Service with access to private key 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.1. Change Log RFC EDITOR PLEASE DELETE THIS SECTION. (*) indicates changes to the wire protocol. draft-11 * Editorial changes based on AD comments * Add support for DTLS * Address address ambiguity in cert expiry draft-10 * Address superficial comments * Add example certificate draft-09 * Address case nits * Fix section bullets in 4.1.3. * Add operational considerations section for clock skew * Add text around using an oracle to forge DCs in the future and past * Add text about certificate extension vs EKU draft-08 * Include details about the impact of signature forgery attacks * Copy edits * Fix section about DC reuse * Incorporate feedback from Jonathan Hammell and Kevin Jacobs on the list draft-07 * Minor text improvements draft-06 * Modified IANA section, fixed nits draft-05 * Removed support for PKCS 1.5 RSA signature algorithms. * Additional security considerations. draft-04 * Add support for client certificates. draft-03 * Remove protocol version from the Credential structure. (*) draft-02 * Change public key type. (*) * Change DelegationUsage extension to be NULL and define its object identifier. * Drop support for TLS 1.2. * Add the protocol version and credential signature algorithm to the Credential structure. (*) * Specify undefined behavior in a few cases: when the client receives a DC without indicated support; when the client indicates the extension in an non-valid protocol version; and when DCs are sent as extensions to certificates other than the end-entity certificate. 3. Solution Overview A delegated credential (DC) is a digitally signed data structure with two semantic fields: a validity interval and a public key (along with its associated signature algorithm). The signature on the delegated credential indicates a delegation from the certificate that is issued to the peer. The private key used to sign a credential corresponds to the public key of the peer's X.509 end-entity certificate [RFC5280]. A (D)TLS handshake that uses delegated credentials differs from a standard handshake in a few important ways: * The initiating peer provides an extension in its ClientHello or CertificateRequest that indicates support for this mechanism. * The peer sending the Certificate message provides both the certificate chain terminating in its certificate as well as the delegated credential. * The initiator uses information from the peer's certificate to verify the delegated credential and that the peer is asserting an expected identity, determining an authentication result for the peer. * Peers accepting the delegated credential use it as the certificate key for the (D)TLS handshake. As detailed in Section 4, the delegated credential is cryptographically bound to the end-entity certificate with which the credential may be used. This document specifies the use of delegated credentials in (D)TLS 1.3 or later; their use in prior versions of the protocol is not allowed. Delegated credentials allow a peer to terminate (D)TLS connections on behalf of the certificate owner. If a credential is stolen, there is no mechanism for revoking it without revoking the certificate itself. To limit exposure in case of the compromise of a delegated credential's private key, delegated credentials have a maximum validity period. In the absence of an application profile standard specifying otherwise, the maximum validity period is set to 7 days. Peers MUST NOT issue credentials with a validity period longer than the maximum validity period or that extends beyond the validity period of the delegation certificate. This mechanism is described in detail in Section 4.1. It was noted in [XPROT] that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge signatures for certificates that contain the keyEncipherment KeyUsage ([RFC5280] section 4.2.1.3). In order to reduce the risk of cross- protocol attacks on certificates that are not intended to be used with DC-capable TLS stacks, we define a new DelegationUsage extension to X.509 that permits use of delegated credentials. (See Section 4.2.) 3.1. Rationale Delegated credentials present a better alternative than other delegation mechanisms like proxy certificates [RFC3820] for several reasons: * There is no change needed to certificate validation at the PKI layer. * X.509 semantics are very rich. This can cause unintended consequences if a service owner creates a proxy certificate where the properties differ from the leaf certificate. Proxy certificates can be useful in controlled environments, but remain a risk in scenarios where the additional flexibility they provide is not necessary. For this reason, delegated credentials have very restricted semantics that should not conflict with X.509 semantics. * Proxy certificates rely on the certificate path building process to establish a binding between the proxy certificate and the end- entity certificate. Since the certificate path building process is not cryptographically protected, it is possible that a proxy certificate could be bound to another certificate with the same public key, with different X.509 parameters. Delegated credentials, which rely on a cryptographic binding between the entire certificate and the delegated credential, cannot. * Each delegated credential is bound to a specific signature algorithm for use in the (D)TLS handshake ([RFC8446] section 4.2.3). This prevents them from being used with other, perhaps unintended, signature algorithms. The signature algorithm bound to the delegated credential can be chosen independently of the set of signature algorithms supported by the end-entity certificate. 3.2. Related Work Many of the use cases for delegated credentials can also be addressed using purely server-side mechanisms that do not require changes to client behavior (e.g., a PKCS#11 interface or a remote signing mechanism, [KEYLESS] being one example). These mechanisms, however, incur per-transaction latency, since the front-end server has to interact with a back-end server that holds a private key. The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency. The figure below compares the message flows for these two mechanisms with (D)TLS 1.3 [RFC8446] [I-D.ietf-tls-dtls13]. Remote key signing: Client Front-End Back-End |----ClientHello--->| | |<---ServerHello----| | |<---Certificate----| | | |<---remote sign---->| |<---CertVerify-----| | | ... | | Delegated Credential: Client Front-End Back-End | |<--DC distribution->| |----ClientHello--->| | |<---ServerHello----| | |<---Certificate----| | |<---CertVerify-----| | | ... | | Legend: Client: (D)TLS client Front-End: (D)TLS server (could be a TLS-termination service like a CDN) Back-End: Service with access to private key These two mechanisms can be complementary. A server could use delegated credentials for clients that support them, while using a server-side mechanism to support legacy clients. Both mechanisms require a trusted relationship between the Front-End and Back-End -- the delegated credential can be used in place of a certificate private key. Use of short-lived certificates with automated certificate issuance, e.g., with Automated Certificate Management Environment (ACME) [RFC8555], reduces the risk of key compromise, but has several limitations. Specifically, it introduces an operationally-critical dependency on an external party (the CA). It also limits the types of algorithms supported for (D)TLS authentication to those the CA is willing to issue a certificate for. Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning delegated credentials. 4. Delegated Credentials While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is valid to use them to issue other signed objects as long as the certificate contains the digitalSignature KeyUsage ([RFC5280] section 4.2.1.3). (All certificates compatible with TLS 1.3 are required to contain the digitalSignature KeyUsage.) This document defines a new signed object format that would encode only the semantics that are needed for this application. The Credential has the following structure: struct { uint32 valid_time; SignatureScheme dc_cert_verify_algorithm; opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; } Credential; valid_time: Time, in seconds relative to the delegation certificate's notBefore value, after which the delegated credential is no longer valid. By default, unless set to an alternative value by an application profile (see Section Section 3), endpoints will reject delegated credentials that expire more than 7 days from the current time (as described in Section 4.1.3). dc_cert_verify_algorithm: The signature algorithm of the Credential key pair, where the type SignatureScheme is as defined in [RFC8446]. This is expected to be the same as the sender's CertificateVerify.algorithm (as described in Section 4.1.3). Only signature algorithms allowed for use in CertificateVerify messages are allowed (as described in [RFC8446] Section 11). When using RSA, the public key MUST NOT use the rsaEncryption OID. As a result, the following algorithms are not allowed for use with delegated credentials: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512. ASN1_subjectPublicKeyInfo: The Credential's public key, a DER- encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280]. The DelegatedCredential has the following structure: struct { Credential cred; SignatureScheme algorithm; opaque signature<0..2^16-1>; } DelegatedCredential; cred: The Credential structure as previously defined. algorithm: The signature algorithm used to create DelegatedCredential.signature. signature: The delegation, a signature that binds the credential to the end-entity certificate's public key as specified below. The signature scheme is specified by DelegatedCredential.algorithm. The signature of the DelegatedCredential is computed over the concatenation of: 1. An octet stream that consists of octet 32 (0x20) repeated 64 times. 2. The non-null terminated context string "TLS, server delegated credentials" for server authentication and "TLS, client delegated credentials" for client authentication. 3. A single octet 0x00, which serves as the separator. 4. The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential. 5. DelegatedCredential.cred. 6. DelegatedCredential.algorithm. The signature is computed by using the private key of the peer's end- entity certificate, with the algorithm indicated by DelegatedCredential.algorithm. The signature effectively binds the credential to the parameters of the handshake in which it is used. In particular, it ensures that credentials are only used with the certificate and signature algorithm chosen by the delegator. The code changes required in order to create and verify delegated credentials, and the implementation complexity this entails, are localized to the (D)TLS stack. This has the advantage of avoiding changes to the often-delicate security-critical PKI code. 4.1. Client and Server Behavior This document defines the following (D)TLS extension code point. enum { ... delegated_credential(34), (65535) } ExtensionType; 4.1.1. Server Authentication A client that is willing to use delegated credentials in a connection SHALL send a "delegated_credential" extension in its ClientHello. The body of the extension consists of a SignatureSchemeList (defined in [RFC8446]): struct { SignatureScheme supported_signature_algorithm<2..2^16-2>; } SignatureSchemeList; If the client receives a delegated credential without having indicated support in its ClientHello, then the client MUST abort the handshake with an "unexpected_message" alert. If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send a delegated credential. When a (D)TLS version negotiated is less than 1.3, the server MUST ignore this extension. An example of when a server could choose not to send a delegated credential is when the SignatureSchemes listed only contain signature schemes for which a corresponding delegated credential does not exist or are otherwise unsuitable for the connection. The server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions to any other certificate. The algorithm field MUST be of a type advertised by the client in the "signature_algorithms" extension of the ClientHello message and the dc_cert_verify_algorithm field MUST be of a type advertised by the client in the SignatureSchemeList and is considered not valid otherwise. Clients that receive non-valid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. 4.1.2. Client Authentication A server that supports this specification SHALL send a "delegated_credential" extension in the CertificateRequest message when requesting client authentication. The body of the extension consists of a SignatureSchemeList. If the server receives a delegated credential without having indicated support in its CertificateRequest, then the server MUST abort with an "unexpected_message" alert. If the extension is present, the client MAY send a delegated credential; if the extension is not present, the client MUST NOT send a delegated credential. When a (D)TLS version negotiated is less than 1.3, the client MUST ignore this extension. The client MUST send the DC as an extension in the CertificateEntry of its end-entity certificate; the server SHOULD ignore delegated credentials sent as extensions to any other certificate. The algorithm field MUST be of a type advertised by the server in the "signature_algorithms" extension of the CertificateRequest message and the dc_cert_verify_algorithm field MUST be of a type advertised by the server in the SignatureSchemeList and is considered not valid otherwise. Servers that receive non-valid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. 4.1.3. Validating a Delegated Credential On receiving a delegated credential and certificate chain, the peer validates the certificate chain and matches the end-entity certificate to the peer's expected identity in the same way that it is done when delegated credentials are not in use. It then performs the following checks with expiry time set to the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time: 1. Verify that the current time is within the validity interval of the credential. This is done by asserting that the current time does not exceed the expiry time. (The start time of the credential is implicitly validated as part of certificate validation.) 2. Verify that the delegated credential's remaining validity period is no more than the maximum validity period. This is done by asserting that the expiry time does not exceed the current time plus the maximum validity period (7 days by default). 3. Verify that dc_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the algorithm is allowed for use with delegated credentials. 4. Verify that the end-entity certificate satisfies the conditions in Section 4.2. 5. Use the public key in the peer's end-entity certificate to verify the signature of the credential using the algorithm indicated by DelegatedCredential.algorithm. If one or more of these checks fail, then the delegated credential is deemed not valid. Clients and servers that receive non-valid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. If successful, the participant receiving the Certificate message uses the public key in DelegatedCredential.cred to verify the signature in the peer's CertificateVerify message. 4.2. Certificate Requirements This document defines a new X.509 extension, DelegationUsage, to be used in the certificate when the certificate permits the usage of delegated credentials. What follows is the ASN.1 [X.680] for the DelegationUsage certificate extension. ext-delegationUsage EXTENSION ::= { SYNTAX DelegationUsage IDENTIFIED BY id-pe-delegationUsage } DelegationUsage ::= NULL id-pe-delegationUsage OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) id-cloudflare(44363) 44 } The extension MUST be marked non-critical. (See Section 4.2 of [RFC5280].) An endpoint MUST NOT accept a delegated credential unless the peer's end-entity certificate satisfies the following criteria: * It has the DelegationUsage extension. * It has the digitalSignature KeyUsage (see the KeyUsage extension defined in [RFC5280]). A new extension was chosen instead of adding a new Extended Key Usage (EKU) to be compatible with deployed (D)TLS and PKI software stacks without requiring CAs to issue new intermediate certificates. 5. Operational Considerations The operational consideration documented in this section should be taken into consideration when using Delegated Certificates. 5.1. Client Clock Skew One of the risks of deploying a short-lived credential system based on absolute time is client clock skew. If a client's clock is sufficiently ahead or behind of the server's clock, then clients will reject delegated credentials that are valid from the server's perspective. Clock skew also affects the validity of the original certificates. The lifetime of the delegated credential should be set taking clock skew into account. Clock skew may affect a delegated credential at the beginning and end of its validity periods, which should also be taken into account. 6. IANA Considerations This document registers the "delegated_credential" extension in the "TLS ExtensionType Values" registry. The "delegated_credential" extension has been assigned a code point of 34. The IANA registry lists this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in (D)TLS 1.3 [RFC8446] [I-D.ietf-tls-dtls13]. Additionally, the "DTLS-Only" column is assigned the value "N". This document also defines an ASN.1 module for the DelegationUsage certificate extension in Appendix A. IANA has registered value 95 for "id-mod-delegated-credential-extn" in the "SMI Security for PKIX Module Identifier" (1.3.5.1.5.5.7.0) registry. An OID for the DelegationUsage certificate extension is not needed as it is already assigned to the extension from Cloudflare's IANA Private Enterprise Number (PEN) arc. 7. Security Considerations The security consideration documented in this section should be taken into consideration when using Delegated Certificates. 7.1. Security of Delegated Credential's Private Key Delegated credentials limit the exposure of the private key used in a (D)TLS connection by limiting its validity period. An attacker who compromises the private key of a delegated credential cannot create new delegated credentials, but they can impersonate the compromised party in new TLS connections until the delegated credential expires. Thus, delegated credentials should not be used to send a delegation to an untrusted party, but are meant to be used between parties that have some trust relationship with each other. The secrecy of the delegated credential's private key is thus important, and access control mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules. 7.2. Re-use of Delegated Credentials in Multiple Contexts It is not possible to use the same delegated credential for both client and server authentication because issuing parties compute the corresponding signature using a context string unique to the intended role (client or server). 7.3. Revocation of Delegated Credentials Delegated credentials do not provide any additional form of early revocation. Since it is short-lived, the expiry of the delegated credential revokes the credential. Revocation of the long term private key that signs the delegated credential (from the end-entity certificate) also implicitly revokes the delegated credential. 7.4. Interactions with Session Resumption If a peer decides to cache the certificate chain and re-validate it when resuming a connection, they SHOULD also cache the associated delegated credential and re-validate it. Failing to do so may result in resuming connections for which the DC has expired. 7.5. Privacy Considerations Delegated credentials can be valid for 7 days (by default) and it is much easier for a service to create delegated credentials than a certificate signed by a CA. A service could determine the client time and clock skew by creating several delegated credentials with different expiry timestamps and observing whether the client would accept it. Client time could be unique and thus privacy-sensitive clients, such as browsers in incognito mode, who do not trust the service might not want to advertise support for delegated credentials or limit the number of probes that a server can perform. 7.6. The Impact of Signature Forgery Attacks Delegated credentials are only used in (D)TLS 1.3 connections. However, the certificate that signs a delegated credential may be used in other contexts such as (D)TLS 1.2. Using a certificate in multiple contexts opens up a potential cross-protocol attack against delegated credentials in (D)TLS 1.3. When (D)TLS 1.2 servers support RSA key exchange, they may be vulnerable to attacks that allow forging an RSA signature over an arbitrary message [BLEI]. TLS 1.2 [RFC5246] (Section 7.4.7.1.) describes a mitigation strategy requiring careful implementation of timing resistant countermeasures for preventing these attacks. Experience shows that in practice, server implementations may fail to fully stop these attacks due to the complexity of this mitigation [ROBOT]. For (D)TLS 1.2 servers that support RSA key exchange using a DC-enabled end-entity certificate, a hypothetical signature forgery attack would allow forging a signature over a delegated credential. The forged delegated credential could then be used by the attacker as the equivalent of a on-path-attacker, valid for a maximum of 7 days (if the default valid_time is used). Server operators should therefore minimize the risk of using DC- enabled end-entity certificates where a signature forgery oracle may be present. If possible, server operators may choose to use DC- enabled certificates only for signing credentials, and not for serving non-DC (D)TLS traffic. Furthermore, server operators may use elliptic curve certificates for DC-enabled traffic, while using RSA certificates without the DelegationUsage certificate extension for non-DC traffic; this completely prevents such attacks. Note that if a signature can be forged over an arbitrary credential, the attacker can choose any value for the valid_time field. Repeated signature forgeries therefore allow the attacker to create multiple delegated credentials that can cover the entire validity period of the certificate. Temporary exposure of the key or a signing oracle may allow the attacker to impersonate a server for the lifetime of the certificate. 8. Acknowledgements Thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh Ramachandran, Benjamin Kaduk, Kazuho Oku, Daniel Kahn Gillmor, Watson Ladd, Robert Merget, Juraj Somorovsky, Nimrod Aviram for their discussions, ideas, and bugs they have found. 9. References 9.1. Normative References [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- dtls13-43, 30 April 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [X.680] ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ISO/ IEC 8824-1:2015, November 2015. [X.690] ITU-T, "Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8825-1:2015, November 2015. 9.2. Informative References [BLEI] Bleichenbacher, D., "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1", Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: 1-12 , 1998. [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake Proxying", IEEE Trustcom/BigDataSE/ISPA 2015 , 2015. [RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. Thompson, "Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile", RFC 3820, DOI 10.17487/RFC3820, June 2004, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . [ROBOT] Boeck, H., Somorovsky, J., and C. Young, "Return Of Bleichenbacher's Oracle Threat (ROBOT)", 27th USENIX Security Symposium , 2018. [XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security , 2015. Appendix A. ASN.1 Module The following ASN.1 module provides the complete definition of the DelegationUsage certificate extension. The ASN.1 module makes imports from [RFC5912]. DelegatedCredentialExtn { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-delegated-credential-extn(95) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORT ALL IMPORTS EXTENSION FROM PKIX-CommonTypes-2009 -- From RFC 5912 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; -- OID id-cloudflare OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 44363 } -- EXTENSION ext-delegationUsage EXTENSION ::= { SYNTAX DelegationUsage IDENTIFIED BY id-pe-delegationUsage } id-pe-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 } DelegationUsage ::= NULL END Appendix B. Example Certificate The following is an example of a delegation certificate which satisfies the requirements described in Section 4.2 (i.e., uses the DelegationUsage extension and has the digitalSignature KeyUsage). -----BEGIN CERTIFICATE----- MIIFRjCCBMugAwIBAgIQDGevB+lY0o/OecHFSJ6YnTAKBggqhkjOPQQDAzBMMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdp Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xOTAzMjYwMDAwMDBaFw0yMTAz MzAxMjAwMDBaMGoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYw FAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZGZsYXJlLCBJbmMu MRMwEQYDVQQDEwprYzJrZG0uY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE d4azI83Bw0fcPgfoeiZpZZnwGuxjBjv++wzE0zAj8vNiUkKxOWSQiGNLn+xlWUpL lw9djRN1rLmVmn2gb9GgdKOCA28wggNrMB8GA1UdIwQYMBaAFKOd5h/52jlPwG7o kcuVpdox4gqfMB0GA1UdDgQWBBSfcb7fS3fUFAyB91fRcwoDPtgtJjAjBgNVHREE HDAaggprYzJrZG0uY29tggwqLmtjMmtkbS5jb20wDgYDVR0PAQH/BAQDAgeAMB0G A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBpBgNVHR8EYjBgMC6gLKAqhiho dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMC6gLKAqhiho dHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMEwGA1UdIARF MEMwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2lj ZXJ0LmNvbS9DUFMwCAYGZ4EMAQICMHsGCCsGAQUFBwEBBG8wbTAkBggrBgEFBQcw AYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEUGCCsGAQUFBzAChjlodHRwOi8v Y2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRFQ0NTZWN1cmVTZXJ2ZXJDQS5j cnQwDAYDVR0TAQH/BAIwADAPBgkrBgEEAYLaSywEAgUAMIIBfgYKKwYBBAHWeQIE AgSCAW4EggFqAWgAdgC72d+8H4pxtZOUI5eqkntHOFeVCqtS6BqQlmQ2jh7RhQAA AWm5hYJ5AAAEAwBHMEUCICiGfq+hSThRL2m8H0awoDR8OpnEHNkF0nI6nL5yYL/j AiEAxwebGs/T6Es0YarPzoQJrVZqk+sHH/t+jrSrKd5TDjcAdgCHdb/nWXz4jEOZ X73zbv9WjUdWNv9KtWDBtOr/XqCDDwAAAWm5hYNgAAAEAwBHMEUCIQD9OWA8KGL6 bxDKfgIleHJWB0iWieRs88VgJyfAg/aFDgIgQ/OsdSF9XOy1foqge0DTDM2FExuw 0JR0AGZWXoNtJzMAdgBElGUusO7Or8RAB9io/ijA2uaCvtjLMbU/0zOWtbaBqAAA AWm5hYHgAAAEAwBHMEUCIQC4vua1n3BqthEqpA/VBTcsNwMtAwpCuac2IhJ9wx6X /AIgb+o00k28JQo9TMpP4vzJ3BD3HXWSNc2Zizbq7mkUQYMwCgYIKoZIzj0EAwMD aQAwZgIxAJsX7d0SuA8ddf/m7IWfNfs3MQfJyGkEezMJX1t6sRso5z50SS12LpXe muGa1FE2ZgIxAL+CDUF5pz7mhrAEIjQ1MqlpF9tH40dJGvYZZQ3W23cMzSkDfvlt y5S4RfWHIIPjbw== -----END CERTIFICATE----- Authors' Addresses Richard Barnes Cisco Email: rlb@ipv.sx Subodh Iyengar Facebook Email: subodh@fb.com Nick Sullivan Cloudflare Email: nick@cloudflare.com Eric Rescorla Mozilla Email: ekr@rtfm.com ./draft-ietf-drip-rid-37.txt0000644000764400076440000023705514342377533015417 0ustar iustiniustin DRIP R. Moskowitz Internet-Draft HTT Consulting Updates: 7401, 7343 (if approved) S. Card Intended status: Standards Track A. Wiethuechter Expires: 5 June 2023 AX Enterprize, LLC A. Gurtov Linköping University 2 December 2022 DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID) draft-ietf-drip-rid-37 Abstract This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses and thereby a trustable identifier for use as the Unmanned Aircraft System Remote Identification and tracking (UAS RID). This document updates RFC7401 and RFC7343. Within the context of RID, HHITs will be called DRIP Entity Tags (DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, e.g., DNS, RDAP) discovery for 3rd-party identifier endorsement. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Moskowitz, et al. Expires 5 June 2023 [Page 1] Internet-Draft DRIP Entity Tag (DET) December 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. HHIT Statistical Uniqueness different from UUID or X.509 Subject . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 3. The Hierarchical Host Identity Tag (HHIT) . . . . . . . . . . 6 3.1. HHIT Prefix for RID Purposes . . . . . . . . . . . . . . 7 3.2. HHIT Suite IDs . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. HDA custom HIT Suite IDs . . . . . . . . . . . . . . 8 3.3. The Hierarchy ID (HID) . . . . . . . . . . . . . . . . . 8 3.3.1. The Registered Assigning Authority (RAA) . . . . . . 9 3.3.2. The Hierarchical HIT Domain Authority (HDA) . . . . . 9 3.4. Edwards-Curve Digital Signature Algorithm for HHITs . . . 10 3.4.1. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.2. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 11 3.5. ORCHIDs for Hierarchical HITs . . . . . . . . . . . . . . 12 3.5.1. Adding Additional Information to the ORCHID . . . . . 13 3.5.2. ORCHID Encoding . . . . . . . . . . . . . . . . . . . 14 3.5.3. ORCHID Decoding . . . . . . . . . . . . . . . . . . . 16 3.5.4. Decoding ORCHIDs for HIPv2 . . . . . . . . . . . . . 16 4. Hierarchical HITs as DRIP Entity Tags . . . . . . . . . . . . 16 4.1. Nontransferablity of DETs . . . . . . . . . . . . . . . . 17 4.2. Encoding HHITs in CTA 2063-A Serial Numbers . . . . . . . 17 4.3. Remote ID DET as one Class of Hierarchical HITs . . . . . 18 4.4. Hierarchy in ORCHID Generation . . . . . . . . . . . . . 18 4.5. DRIP Entity Tag (DET) Registry . . . . . . . . . . . . . 19 4.6. Remote ID Authentication using DETs . . . . . . . . . . . 19 5. DRIP Entity Tags (DETs) in DNS . . . . . . . . . . . . . . . 20 6. Other UAS Traffic Management (UTM) Uses of HHITs Beyond DET . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Summary of Addressed DRIP Requirements . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8.1. New Well-Known IPv6 prefix for DETs . . . . . . . . . . . 21 8.2. New IANA DRIP Registry . . . . . . . . . . . . . . . . . 22 8.3. IANA CGA Registry Update . . . . . . . . . . . . . . . . 23 Moskowitz, et al. Expires 5 June 2023 [Page 2] Internet-Draft DRIP Entity Tag (DET) December 2022 8.4. IANA HIP Registry Updates . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9.1. Post Quantum Computing out of scope . . . . . . . . . . . 26 9.2. DET Trust in ASTM messaging . . . . . . . . . . . . . . . 26 9.3. DET Revocation . . . . . . . . . . . . . . . . . . . . . 27 9.4. Privacy Considerations . . . . . . . . . . . . . . . . . 27 9.5. Collision Risks with DETs . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . 30 Appendix A. EU U-Space RID Privacy Considerations . . . . . . . 32 Appendix B. The 14/14 HID split . . . . . . . . . . . . . . . . 33 B.1. DET Encoding Example . . . . . . . . . . . . . . . . . . 34 Appendix C. Base32 Alphabet . . . . . . . . . . . . . . . . . . 35 Appendix D. Calculating Collision Probabilities . . . . . . . . 35 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction Drone Remote ID Protocol (DRIP) Requirements [RFC9153] describe an Unmanned Aircraft System Remote ID (UAS ID) as unique (ID-4), non- spoofable (ID-5), and identify a registry where the ID is listed (ID- 2); all within a 19-character identifier (ID-1). This DRIP foundational document (i.e., all else in DRIP enables or uses it) describes (per Section 3 of [drip-architecture]) the use of Hierarchical Host Identity Tags (HHITs) (Section 3) as self-asserting IPv6 addresses and thereby a trustable identifier for use as the UAS Remote ID. HHITs add explicit hierarchy to the 128-bit HITs, enabling DNS HHIT queries (Host ID for authentication, e.g., [drip-authentication]) and for use with a Differentiated Access Control (e.g. Registration Data Access Protocol (RDAP) [RFC9224]) for 3rd-party identification endorsement (e.g., [drip-authentication]). This addition of hierarchy to HITs is an extension to [RFC7401] and requires an update to [RFC7343]. As this document also adds EdDSA (Section 3.4) for Host Identities (HIs), a number of Host Identity Protocol (HIP) parameters in [RFC7401] are updated, but these should not be needed in a DRIP implementation that does not use HIP. HHITs as used within the context of Unmanned Aircraft System (UAS) are labeled as DRIP Entity Tags (DETs). Throughout this document HHIT and DET will be used appropriately. HHIT will be used when covering the technology, and DET for their context within UAS RID. Moskowitz, et al. Expires 5 June 2023 [Page 3] Internet-Draft DRIP Entity Tag (DET) December 2022 Hierarchical HITs provide self-claims of the HHIT registry. A HHIT can only be in a single registry within a registry system (e.g. DNS). Hierarchical HITs are valid, though non-routable, IPv6 addresses [RFC8200]. As such, they fit in many ways within various IETF technologies. 1.1. HHIT Statistical Uniqueness different from UUID or X.509 Subject HHITs are statistically unique through the cryptographic hash feature of second-preimage resistance. The cryptographically-bound addition of the hierarchy and a HHIT registration process [drip-registries] provide complete, global HHIT uniqueness. If the HHITs cannot be looked up with services provided by the DRIP Identity Management Entity (DIME) identified via the embedded hierarchical information or its registration validated by registration endorsement messages [drip-authentication], then the HHIT is either fraudulent or revoked/ expired. In-depth discussion of these processes are out of scope for this document. This contrasts with using general identifiers (e.g., a Universally Unique IDentifiers (UUID) [RFC4122] or device serial numbers as the subject in an X.509 [RFC5280] certificate. In either case, there can be no unique proof of ownership/registration. For example, in a multi-Certificate Authority (multi-CA) PKI alternative to HHITs, a Remote ID as the Subject (Section 4.1.2.6 of [RFC5280]) can occur in multiple CAs, possibly fraudulently. CAs within the PKI would need to implement an approach to enforce assurance of the uniqueness achieved with HHITs. 2. Terms and Definitions 2.1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The document includes a set of algorithms with a guidance on the ones that are recommended to be supported by implementations. The following term is used for that purpose: RECOMMENDED. Moskowitz, et al. Expires 5 June 2023 [Page 4] Internet-Draft DRIP Entity Tag (DET) December 2022 2.2. Notations | Signifies concatenation of information - e.g., X | Y is the concatenation of X and Y. 2.3. Definitions This document uses the terms defined in Section 2.2 of [RFC9153] and in Section 2 of [drip-architecture]. The following new terms are used in the document: cSHAKE (The customizable SHAKE function [NIST.SP.800-185]): Extends the SHAKE [NIST.FIPS.202] scheme to allow users to customize their use of the SHAKE function. HDA (HHIT Domain Authority): The 14-bit field that identifies the HHIT Domain Authority under a Registered Assigning Authority (RAA). See Figure 1. HHIT Hierarchical Host Identity Tag. A HIT with extra hierarchical information not found in a standard HIT [RFC7401]. HI Host Identity. The public key portion of an asymmetric key pair as defined in [RFC9063]. HID (Hierarchy ID): The 28-bit field providing the HIT Hierarchy ID. See Figure 1. HIP (Host Identity Protocol) The origin [RFC7401] of HI, HIT, and HHIT. HIT Host Identity Tag. A 128-bit handle on the HI. HITs are valid IPv6 addresses. Keccak (KECCAK Message Authentication Code): The family of all sponge functions with a KECCAK-f permutation as the underlying function and multi-rate padding as the padding rule. It refers in particular to all the functions referenced from [NIST.FIPS.202] and [NIST.SP.800-185]. KMAC (KECCAK Message Authentication Code [NIST.SP.800-185]): A Pseudo Random Function (PRF) and keyed hash function based on KECCAK. Moskowitz, et al. Expires 5 June 2023 [Page 5] Internet-Draft DRIP Entity Tag (DET) December 2022 RAA (Registered Assigning Authority): The 14-bit field identifying the business or organization that manages a registry of HDAs. See Figure 1. RVS (Rendezvous Server): A Rendezvous Server such as the HIP Rendezvous Server for enabling mobility, as defined in [RFC8004]. SHAKE (Secure Hash Algorithm KECCAK [NIST.FIPS.202]): A secure hash that allows for an arbitrary output length. XOF (eXtendable-Output Function [NIST.FIPS.202]): A function on bit strings (also called messages) in which the output can be extended to any desired length. 3. The Hierarchical Host Identity Tag (HHIT) The Hierarchical HIT (HHIT) is a small but important enhancement over the flat Host Identity Tag (HIT) space, constructed as an Overlay Routable Cryptographic Hash IDentifier (ORCHID) [RFC7343]. By adding two levels of hierarchical administration control, the HHIT provides for device registration/ownership, thereby enhancing the trust framework for HITs. The 128-bit HHITs represent the HI in only a 64-bit hash, rather than the 96 bits in HITs. 4 of these 32 freed up bits expand the Suite ID to 8 bits, and the other 28 bits are used to create a hierarchical administration organization for HIT domains. Hierarchical HIT construction is defined in Section 3.5. The input values for the Encoding rules are described in Section 3.5.1. A HHIT is built from the following fields (Figure 1): * p = an IPV6 prefix (max 28 bit) * 28-bit Hierarchy ID (HID) which provides the structure to organize HITs into administrative domains. HIDs are further divided into two fields: - 14-bit Registered Assigning Authority (RAA) (Section 3.3.1) - 14-bit Hierarchical HIT Domain Authority (HDA) (Section 3.3.2) * 8-bit HHIT Suite ID (HHSI) * ORCHID hash (92 - prefix length, e.g., 64) See Section 3.5 for more details. Moskowitz, et al. Expires 5 June 2023 [Page 6] Internet-Draft DRIP Entity Tag (DET) December 2022 14 bits| 14 bits 8 bits +-------+-------+ +--------------+ | RAA | HDA | |HHIT Suite ID | +-------+-------+ +--------------+ \ | ____/ ___________/ \ \ _/ ___/ \ \/ / | p bits | 28 bits |8bits| o=92-p bits | +--------------+------------+-----+------------------------+ | IPV6 Prefix | HID |HHSI | ORCHID hash | +--------------+------------+-----+------------------------+ Figure 1: HHIT Format The Context ID (generated with openssl rand) for the ORCHID hash is: Context ID := 0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40 Context IDs are allocated out of the namespace introduced for Cryptographically Generated Addresses (CGA) Type Tags [RFC3972]. 3.1. HHIT Prefix for RID Purposes The IPv6 HHIT prefix MUST be distinct from that used in the flat- space HIT as allocated in [RFC7343]. Without this distinct prefix, the first 4 bits of the RAA would be interpreted as the HIT Suite ID per HIPv2 [RFC7401]. Initially, for DET use, one 28-bit prefix should be assigned out of the IANA IPv6 Special Purpose Address Block ([RFC6890]). HHIT Use Bits Value DET 28 TBD6 (suggested value 2001:30::/28) Other prefixes may be added in the future either for DET use or other applications of HHITs. For a prefix to be added to the registry in Section 8.2, its usage and HID allocation process have to be publicly available. 3.2. HHIT Suite IDs The HHIT Suite IDs specify the HI and hash algorithms. These are a superset of the 4/8-bit HIT Suite ID as defined in Section 5.2.10 of [RFC7401]. The HHIT values of 1 - 15 map to the basic 4-bit HIT Suite IDs. HHIT values of 17 - 31 map to the extended 8-bit HIT Suite IDs. HHIT values unique to HHIT will start with value 32. Moskowitz, et al. Expires 5 June 2023 [Page 7] Internet-Draft DRIP Entity Tag (DET) December 2022 As HHIT introduces a new Suite ID, EdDSA/cSHAKE128, and since this is of value to HIPv2, it will be allocated out of the 4-bit HIT space and result in an update to HIT Suite IDs. Future HHIT Suite IDs may be allocated similarly, or may come out of the additional space made available by going to 8 bits. The following HHIT Suite IDs are defined: HHIT Suite Value RESERVED 0 RSA,DSA/SHA-256 1 [RFC7401] ECDSA/SHA-384 2 [RFC7401] ECDSA_LOW/SHA-1 3 [RFC7401] EdDSA/cSHAKE128 TBD3 (suggested value 5) 3.2.1. HDA custom HIT Suite IDs Support for 8-bit HHIT Suite IDs allows for HDA custom HIT Suite IDs. These will be assigned values greater than 15 as follows: HHIT Suite Value HDA Private Use 1 TBD4 (suggested value 254) HDA Private Use 2 TBD5 (suggested value 255) These custom HIT Suite IDs, for example, may be used for large-scale experimenting with post quantum computing hashes or similar domain specific needs. Note that currently there is no support for domain- specific HI algorithms. They should not be used to create a "de facto standardization". Section 8.2 states that additional Suite IDs can be made through IETF Review. 3.3. The Hierarchy ID (HID) The Hierarchy ID (HID) provides the structure to organize HITs into administrative domains. HIDs are further divided into two fields: * 14-bit Registered Assigning Authority (RAA) * 14-bit Hierarchical HIT Domain Authority (HDA) The rationale for the 14/14 HID split is described in Appendix B. Moskowitz, et al. Expires 5 June 2023 [Page 8] Internet-Draft DRIP Entity Tag (DET) December 2022 The two levels of hierarchy allows for Civil Aviation Authorities (CAAs) to have it least one RAA for their National Air Space (NAS). Within its RAA(s), the CAAs can delegate HDAs as needed. There may be other RAAs allowed to operate within a given NAS; this is a policy decision of each CAA. 3.3.1. The Registered Assigning Authority (RAA) An RAA is a business or organization that manages a registry of HDAs. For example, the Federal Aviation Authority (FAA) or Japan Civil Aviation Bureau (JCAB) could be an RAA. The RAA is a 14-bit field (16,384 RAAs). The management of this space is further elaborated in [drip-registries]. An RAA MUST provide a set of services to allocate HDAs to organizations. It SHOULD have a public policy on what is necessary to obtain an HDA. The RAA need not maintain any HIP related services. It MUST maintain a DNS zone minimally for the HDA zone delegation for discovering HIP RVS servers [RFC8004] for the HID. The zone delegation is covered in [drip-registries]. As DETs under an administrative control may be used in many different domains (e.g., commercial, recreation, military), RAAs should be allocated in blocks (e.g. 16-19) with consideration on the likely size of a particular usage. Alternatively, different prefixes can be used to separate different domains of use of HHITs. The RAA DNS zone within the UAS DNS tree may be a PTR for its RAA. It may be a zone in an HHIT specific DNS zone. Assume that the RAA is decimal 100. The PTR record could be constructed as follows (where 20010030 is the DET prefix): 100.20010030.hhit.arpa. IN PTR raa.example.com. Note that if the zone 20010030.hhit.arpa is ultimately used, some registrar will need to manage this for all HHIT applications. Thus further thought will be needed in the actual zone tree and registration process [drip-registries]. 3.3.2. The Hierarchical HIT Domain Authority (HDA) An HDA may be an Internet Service Provider (ISP), UAS Service Supplier (USS), or any third party that takes on the business to provide UAS services management, HIP RVSs or other needed services such as those required for HHIT and/or HIP-enabled devices. Moskowitz, et al. Expires 5 June 2023 [Page 9] Internet-Draft DRIP Entity Tag (DET) December 2022 The HDA is a 14-bit field (16,384 HDAs per RAA) assigned by an RAA is further elaborated in [drip-registries]. An HDA must maintain public and private UAS registration information and should maintain a set of RVS servers for UAS clients that may use HIP. How this is done and scales to the potentially millions of customers are outside the scope of this document, though covered in [drip-registries]. This service should be discoverable through the DNS zone maintained by the HDA's RAA. An RAA may assign a block of values to an individual organization. This is completely up to the individual RAA's published policy for delegation. Such policy is out of scope. 3.4. Edwards-Curve Digital Signature Algorithm for HHITs The Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032] is specified here for use as HIs per HIPv2 [RFC7401]. The intent in this document is to add EdDSA as a HI algorithm for DETs, but doing so impacts the HIP parameters used in a HIP exchange. The subsections of this section document the required updates of HIP parameters. Other than the HIP DNS RR (Resource Record) [RFC8005], these should not be needed in a DRIP implementation that does not use HIP. See Section 3.2 for use of the HIT Suite in the context of DRIP. 3.4.1. HOST_ID The HOST_ID parameter specifies the public key algorithm, and for elliptic curves, a name. The HOST_ID parameter is defined in Section 5.2.9 of [RFC7401]. Algorithm profile Value EdDSA TBD1 (suggested value 13) [RFC8032] 3.4.1.1. HIP Parameter support for EdDSA The addition of EdDSA as a HI algorithm requires a subfield in the HIP HOST_ID parameter (Section 5.2.9 of [RFC7401]) as was done for ECDSA when used in a HIP exchange. For HIP hosts that implement EdDSA as the algorithm, the following EdDSA curves are represented by the following fields: Moskowitz, et al. Expires 5 June 2023 [Page 10] Internet-Draft DRIP Entity Tag (DET) December 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EdDSA Curve | NULL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EdDSA Curve Curve label Public Key Represented in Octet-string format [RFC8032] Figure 2 For hosts that implement EdDSA as a HIP algorithm the following EdDSA curves are defined; recommended curves are tagged accordingly: Algorithm Curve Values EdDSA RESERVED 0 EdDSA EdDSA25519 1 [RFC8032] (RECOMMENDED) EdDSA EdDSA25519ph 2 [RFC8032] EdDSA EdDSA448 3 [RFC8032] (RECOMMENDED) EdDSA EdDSA448ph 4 [RFC8032] 3.4.1.2. HIP DNS RR support for EdDSA The HIP DNS RR is defined in [RFC8005]. It uses the values defined for the 'Algorithm Type' of the IPSECKEY RR [RFC4025] for its PK Algorithm field. The new EdDSA HI uses [ipseckey-eddsa] for the IPSECKEY RR encoding. 3.4.2. HIT_SUITE_LIST The HIT_SUITE_LIST parameter contains a list of the supported HIT suite IDs of the HIP Responder. Based on the HIT_SUITE_LIST, the HIP Initiator can determine which source HIT Suite IDs are supported by the Responder. The HIT_SUITE_LIST parameter is defined in Section 5.2.10 of [RFC7401]. The following HIT Suite ID is defined: HIT Suite Value EdDSA/cSHAKE128 TBD3 (suggested value 5) Table 1 provides more detail on the above HIT Suite combination. Moskowitz, et al. Expires 5 June 2023 [Page 11] Internet-Draft DRIP Entity Tag (DET) December 2022 The output of cSHAKE128 is variable per the needs of a specific ORCHID construction. It is at most 96 bits long and is directly used in the ORCHID (without truncation). +=======+===========+=========+===========+====================+ | Index | Hash | HMAC | Signature | Description | | | function | | algorithm | | | | | | family | | +=======+===========+=========+===========+====================+ | 5 | cSHAKE128 | KMAC128 | EdDSA | EdDSA HI hashed | | | | | | with cSHAKE128, | | | | | | output is variable | +-------+-----------+---------+-----------+--------------------+ Table 1: HIT Suites 3.5. ORCHIDs for Hierarchical HITs This section improves on ORCHIDv2 [RFC7343] with three enhancements: * Optional "Info" field between the Prefix and ORCHID Generation Algorithm (OGA) ID. * Increased flexibility on the length of each component in the ORCHID construction, provided the resulting ORCHID is 128 bits. * Use of cSHAKE, NIST SP 800-185 [NIST.SP.800-185], for the hashing function. The Keccak [Keccak] based cSHAKE XOF hash function is a variable output length hash function. As such it does not use the truncation operation that other hashes need. The invocation of cSHAKE specifies the desired number of bits in the hash output. Further, cSHAKE has a parameter 'S' as a customization bit string. This parameter will be used for including the ORCHID Context Identifier in a standard fashion. This ORCHID construction includes the fields in the ORCHID in the hash to protect them against substitution attacks. It also provides for inclusion of additional information, in particular the hierarchical bits of the Hierarchical HIT, in the ORCHID generation. This should be viewed as an update to ORCHIDv2 [RFC7343], as it can produce ORCHIDv2 output. Moskowitz, et al. Expires 5 June 2023 [Page 12] Internet-Draft DRIP Entity Tag (DET) December 2022 The follow sub-sections define the general, new, ORCHID construct with the specific application here for HHITs. Thus items like the hash size is only discussed as it impacts HHIT's 64-bit hash. Other hash sizes should be discussed in any other specific use of this new ORCHID construct. 3.5.1. Adding Additional Information to the ORCHID ORCHIDv2 [RFC7343] is defined as consisting of three components: ORCHID := Prefix | OGA ID | Encode_96( Hash ) where: Prefix : A constant 28-bit-long bitstring value (IPV6 prefix) OGA ID : A 4-bit long identifier for the Hash_function in use within the specific usage context. When used for HIT generation this is the HIT Suite ID. Encode_96( ) : An extraction function in which output is obtained by extracting the middle 96-bit-long bitstring from the argument bitstring. The new ORCHID function is as follows: Moskowitz, et al. Expires 5 June 2023 [Page 13] Internet-Draft DRIP Entity Tag (DET) December 2022 ORCHID := Prefix (p) | Info (n) | OGA ID (o) | Hash (m) where: Prefix (p) : An IPv6 prefix of length p (max 28-bit-long). Info (n) : n bits of information that define a use of the ORCHID. 'n' can be zero, that is no additional information. OGA ID (o) : A 4- or 8-bit long identifier for the Hash_function in use within the specific usage context. When used for HIT generation this is the HIT Suite ID [IANA-HIP]. When used for HHIT generation this is the HHIT Suite ID [TBC_DRIP_REGISTRY]. Note to the RFC Editor: Please replace [TBC_DRIP_REGISTRY] with the pointer to the IANA registry created in Section 8.2. Hash (m) : An extraction function in which output is 'm' bits. Sizeof(p + n + o + m) 128 bits The ORCHID length MUST be 128 bits. For HHITs with a 28-bit IPv6 prefix, there are 100 bits remaining to be divided in any manner between the additional information ("Info"), OGA ID, and the hash output. Consideration must be given to the size of the hash portion, taking into account risks like pre-image attacks. 64 bits, as used here for HHITs, may be as small as is acceptable. The size of 'n', for the HID, is then determined as what is left; in the case of the 8-bit OGA used for HHIT, this is 28 bits. 3.5.2. ORCHID Encoding This update adds a different encoding process to that currently used in ORCHIDv2. The input to the hash function explicitly includes all the header content plus the Context ID. The header content consists of the Prefix, the Additional Information ("Info"), and OGA ID (HIT Suite ID). Secondly, the length of the resulting hash is set by sum of the length of the ORCHID header fields. For example, a 28-bit prefix with 28 bits for the HID and 8 bits for the OGA ID leaves 64 bits for the hash length. To achieve the variable length output in a consistent manner, the cSHAKE hash is used. For this purpose, cSHAKE128 is appropriate. The cSHAKE function call for this update is: Moskowitz, et al. Expires 5 June 2023 [Page 14] Internet-Draft DRIP Entity Tag (DET) December 2022 cSHAKE128(Input, L, "", Context ID) Input := Prefix | Additional Information | OGA ID | HOST_ID L := Length in bits of hash portion of ORCHID For full Suite ID support (those that use fixed length hashes like SHA256), the following hashing can be used (Note: this does not produce output Identical to ORCHIDv2 for a /28 prefix and Additional Information of zero-length): Hash[L](Context ID | Input) Input := Prefix | Additional Information | OGA ID | HOST_ID L := Length in bits of hash portion of ORCHID Hash[L] := An extraction function in which output is obtained by extracting the middle L-bit-long bitstring from the argument bitstring. The middle L-bits are those bits from the source number where either there is an equal number of bits before and after these bits, or there is one more bit prior (when the difference between hash size and L is odd). Hierarchical HITs use the Context ID defined in Section 3. 3.5.2.1. Encoding ORCHIDs for HIPv2 This section discusses how to provide backwards compatibility for ORCHIDv2 [RFC7343] as used in HIPv2 [RFC7401]. For HIPv2, the Prefix is 2001:20::/28 (Section 6 of [RFC7343]). 'Info' is zero-length (i.e., not included), and OGA ID is 4-bit. Thus, the HI Hash is 96-bit length. Further, the Prefix and OGA ID are not included in the hash calculation. Thus, the following ORCHID calculations for fixed output length hashes are used: Hash[L](Context ID | Input) Input := HOST_ID L := 96 Context ID := 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA Hash[L] := An extraction function in which output is obtained by extracting the middle L-bit-long bitstring from the argument bitstring. For variable output length hashes use: Moskowitz, et al. Expires 5 June 2023 [Page 15] Internet-Draft DRIP Entity Tag (DET) December 2022 Hash[L](Context ID | Input) Input := HOST_ID L := 96 Context ID := 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA Hash[L] := The L-bit output from the hash function Then, the ORCHID is constructed as follows: Prefix | OGA ID | Hash Output 3.5.3. ORCHID Decoding With this update, the decoding of an ORCHID is determined by the Prefix and OGA ID. ORCHIDv2 [RFC7343] decoding is selected when the Prefix is: 2001:20::/28. For Hierarchical HITs, the decoding is determined by the presence of the HHIT Prefix as specified in Section 8.2. 3.5.4. Decoding ORCHIDs for HIPv2 This section is included to provide backwards compatibility for ORCHIDv2 [RFC7343] as used for HIPv2 [RFC7401]. HITs are identified by a Prefix of 2001:20::/28. The next 4 bits are the OGA ID. The remaining 96 bits are the HI Hash. 4. Hierarchical HITs as DRIP Entity Tags HHITs for UAS ID (called, DETs) use the new EdDSA/SHAKE128 HIT suite defined in Section 3.4 (GEN-2 in [RFC9153]). This hierarchy, cryptographically bound within the HHIT, provides the information for finding the UA's HHIT registry (ID-3 in [RFC9153]). The ASTM Standard Specification for Remote ID and Tracking [F3411-22a] adds support for DETs. This is only available via the new UAS ID type 4, "Specific Session ID (SSI)". This new SSI uses the first byte of the 20-byte UAS ID for the SSI Type, thus restricting the UAS ID of this type to a maximum of 19 bytes. The SSI Types initially assigned are: SSI 1 IETF - DRIP Drone Remote ID Protocol (DRIP) entity ID. SSI 2 3GPP - IEEE 1609.2-2016 HashedID8 Moskowitz, et al. Expires 5 June 2023 [Page 16] Internet-Draft DRIP Entity Tag (DET) December 2022 4.1. Nontransferablity of DETs A HI and its DET SHOULD NOT be transferable between UA or even between replacement electronics (e.g., replacement of damaged controller CPU) for a UA. The private key for the HI SHOULD be held in a cryptographically secure component. 4.2. Encoding HHITs in CTA 2063-A Serial Numbers In some cases, it is advantageous to encode HHITs as a CTA 2063-A Serial Number [CTA2063A]. For example, the FAA Remote ID Rules [FAA_RID] state that a Remote ID Module (i.e., not integrated with UA controller) must only use "the serial number of the unmanned aircraft"; CTA 2063-A meets this requirement. Encoding an HHIT within the CTA 2063-A format is not simple. The CTA 2063-A format is defined as follows: Serial Number := MFR Code | Length Code | MFR SN where: MFR Code : 4 character code assigned by ICAO (International Civil Aviation Organization, a UN Agency). Length Code : 1 character Hex encoding of MFR SN length (1-F). MFR SN : US-ASCII alphanumeric code (0-9, A-Z except O and I). Maximum length of 15 characters. There is no place for the HID; there will need to be a mapping service from Manufacturer Code to HID. The HHIT Suite ID and ORCHID hash will take the full 15 characters (as described below) of the MFR SN field. A character in a CTA 2063-A Serial Number "shall include any combination of digits and uppercase letters, except the letters O and I, but may include all digits". This would allow for a Base34 encoding of the binary HHIT Suite ID and ORCHID hash in 15 characters. Although, programmatically, such a conversion is not hard, other technologies (e.g., credit card payment systems) that have used such odd base encoding have had performance challenges. Thus, here a Base32 encoding will be used by also excluding the letters Z and S (too similar to the digits 2 and 5). See Appendix C for the encoding scheme. Moskowitz, et al. Expires 5 June 2023 [Page 17] Internet-Draft DRIP Entity Tag (DET) December 2022 The low-order 72 bits (HHIT Suite ID | ORCHID hash) of the HHIT SHALL be left-padded with 3 bits of zeros. This 75-bit number will be encoded into the 15-character MFR SN field using the digit/letters above. The manufacturer MUST use a Length Code of F (15). Note: The manufacturer MAY use the same Manufacturer Code with a Length Code of 1 - E (1 - 14) for other types of serial numbers. Using the sample DET from Section 5 that is for HDA=20 under RAA=10 and having the ICAO CTA MFR Code of 8653, the 20-character CTA 2063-A Serial Number would be: 8653F02T7B8RA85D19LX A mapping service (e.g., DNS) MUST provide a trusted (e.g., via DNSSEC [RFC4034]) conversion of the 4-character Manufacturer Code to high-order 58 bits (Prefix | HID) of the HHIT. That is, given a Manufacturer Code, a returned Prefix|HID value is reliable. Definition of this mapping service is out of scope of this document. It should be noted that this encoding would only be used in the Basic ID Message (Section 2.2 of [RFC9153]). The DET is used in the Authentication Messages (i.e., the messages that provide framing for authentication data only). 4.3. Remote ID DET as one Class of Hierarchical HITs UAS Remote ID DET may be one of a number of uses of HHITs. However, it is out of the scope of the document to elaborate on other uses of HHITs. As such these follow-on uses need to be considered in allocating the RAAs (Section 3.3.1) or HHIT prefix assignments (Section 8). 4.4. Hierarchy in ORCHID Generation ORCHIDS, as defined in [RFC7343], do not cryptographically bind an IPv6 prefix nor the OGA ID (the HIT Suite ID) to the hash of the HI. The rationale at the time of developing ORCHID was attacks against these fields are Denial-of-Service (DoS) attacks against protocols using ORCHIDs and thus up to those protocols to address the issue. HHITs, as defined in Section 3.5, cryptographically bind all content in the ORCHID through the hashing function. A recipient of a DET that has the underlying HI can directly trust and act on all content in the HHIT. This provides a strong, self-claim for using the hierarchy to find the DET Registry based on the HID (Section 4.5). Moskowitz, et al. Expires 5 June 2023 [Page 18] Internet-Draft DRIP Entity Tag (DET) December 2022 4.5. DRIP Entity Tag (DET) Registry DETs are registered to HDAs. A registration process, [drip-registries], ensures DET global uniqueness (ID-4 in [RFC9153]). It also provides the mechanism to create UAS public/private data that are associated with the DET (REG-1 and REG-2 in [RFC9153]). 4.6. Remote ID Authentication using DETs The EdDSA25519 HI (Section 3.4) underlying the DET can be used in an 88-byte self-proof evidence (timestamp, HHIT, and signature of these) to provide proof to Observers of Remote ID ownership (GEN-1 in [RFC9153]). In practice, the Wrapper and Manifest authentication formats (Sections 6.3.3 and 6.3.4 of [drip-authentication]) implicitly provide this self-evidence. A lookup service like DNS can provide the HI and registration proof (GEN-3 in [RFC9153]). Similarly, for Observers without Internet access, a 200-byte offline self-endorsement (Section 3.1.2 of [drip-authentication]) could provide the same Remote ID ownership proof. This endorsement would contain the HDA's signing of the UA's HHIT, itself signed by the UA's HI. Only a small cache (also Section 3.1.2 of [drip-authentication]) that contains the HDA's HI/HHIT and HDA meta-data is needed by the Observer. However, such an object would just fit in the ASTM Authentication Message (Section 2.2 of [RFC9153]) with no room for growth. In practice, [drip-authentication] provides this offline self-endorsement in two authentication messages: the HDA's endorsement of the UA's HHIT registration in a Link authentication message whose hash is sent in a Manifest authentication message. Hashes of any previously sent ASTM messages can be placed in a Manifest authentication message (GEN-2 in [RFC9153]). When a Location/Vector Message (i.e., a message that provides UA location, altitude, heading, speed, and status) hash along with the hash of the HDA's UA HHIT endorsement are sent in a Manifest authentication message and the Observer can visually see a UA at the claimed location, the Observer has a very strong proof of the UA's Remote ID. All this behavior and how to mix these authentication messages into the flow of UA operation messages are detailed in [drip-authentication]. Moskowitz, et al. Expires 5 June 2023 [Page 19] Internet-Draft DRIP Entity Tag (DET) December 2022 5. DRIP Entity Tags (DETs) in DNS There are two approaches for storing and retrieving DETs using DNS. The following are examples of how this may be done. This will serve as guidance to the actual deployment of DETs in DNS. However, this document does not provide a recommendation. Further DNS-related considerations are covered in [drip-registries]. * As FQDNs, for example, "20010030.hhit.arpa.". * Reverse DNS lookups as IPv6 addresses per [RFC8005]. A DET can be used to construct an FQDN that points to the USS that has the public/private information for the UA (REG-1 and REG-2 in [RFC9153]). For example, the USS for the HHIT could be found via the following: assume the RAA is decimal 100 and the HDA is decimal 50. The PTR record is constructed as follows: 100.50.20010030.hhit.arpa. IN PTR foo.uss.example.org. The HDA SHOULD provide DNS service for its zone and provide the HHIT detail response. The DET reverse lookup can be a standard IPv6 reverse look up, or it can leverage off the HHIT structure. Using the allocated prefix for HHITs TBD6 [suggested value 2001:30::/28] (See Section 3.1), the RAA is decimal 10 and the HDA is decimal 20, the DET is: 2001:30:280:1405:a3ad:1952:ad0:a69e See Appendix B.1 for how the upper 64 bits, above, are constructed. A DET reverse lookup could be to: a69e.0ad0.1952.a3ad.1405.0280.20.10.20010030.hhit.arpa.. or: a3ad19520ad0a69e.5.20.10.20010030.hhit.arpa. A 'standard' ip6.arpa RR has the advantage of only one Registry service supported. $ORIGIN 5.0.4.1.0.8.2.0.0.3.0.0.1.0.0.2.ip6.arpa. e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a IN PTR a3ad1952ad0a69e.20.10.20010030.hhit.arpa. Moskowitz, et al. Expires 5 June 2023 [Page 20] Internet-Draft DRIP Entity Tag (DET) December 2022 This DNS entry for the DET can also provide a revocation service. For example, instead of returning the HI RR it may return some record showing that the HI (and thus DET) has been revoked. Guidance on revocation service will be provided in [drip-registries]. 6. Other UAS Traffic Management (UTM) Uses of HHITs Beyond DET HHITs will be used within the UTM architecture beyond DET (and USS in UA ID registration and authentication), for example, as a Ground Control Station (GCS) HHIT ID. Some GCS will use its HHIT for securing its Network Remote ID (to USS HHIT) and Command and Control (C2, Section 2.2.2 of [RFC9153]) transports. Observers may have their own HHITs to facilitate UAS information retrieval (e.g., for authorization to private UAS data). They could also use their HHIT for establishing a HIP connection with the UA Pilot for direct communications per authorization. Details about such issues are out of the scope of this document). 7. Summary of Addressed DRIP Requirements This document provides the details to solutions for GEN 1 - 3, ID 1 - 5, and REG 1 - 2 requirements that are described in [RFC9153]. 8. IANA Considerations 8.1. New Well-Known IPv6 prefix for DETs Since the DET format is not compatible with [RFC7343], IANA is requested to allocate a new prefix following this template for the IPv6 Special-Purpose Address Registry. Address Block: IANA is requested to allocate a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely 2001::/23, as per [RFC6890] (TBD6, suggested: 2001:30::/28). Name: This block should be named "DRIP Entity Tags (DETs) Prefix". RFC: This document. Allocation Date: Date this document published. Termination Date: Forever. Moskowitz, et al. Expires 5 June 2023 [Page 21] Internet-Draft DRIP Entity Tag (DET) December 2022 Source: False. Destination: False. Forwardable: False. Globally Reachable: False. Reserved-by-Protocol: False. 8.2. New IANA DRIP Registry This document requests IANA to create a new registry titled "Drone Remote ID Protocol" registry. It is suggested that multiple designated experts be appointed for registry change requests. Criteria that should be applied by the designated experts include determining whether the proposed registration duplicates existing functionality and whether the registration description is clear and fits the purpose of this registry. Registration requests MUST be sent to drip-reg-review@ietf.org and are evaluated within a three-week review period on the advice of one or more designated experts. Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 28 days can be brought to the IESG's attention for resolution. The following two subregistries should be created under that registry. Hierarchical HIT (HHIT) Prefixes: Initially, for DET use, one 28-bit prefix should be assigned out of the IANA IPv6 Special Purpose Address Block, namely 2001::/23, as per [RFC6890]. Future additions to this subregistry are to be made through Expert Review (Section 4.5 of [RFC8126]). Entries with network-specific prefixes may be present in the registry. Moskowitz, et al. Expires 5 June 2023 [Page 22] Internet-Draft DRIP Entity Tag (DET) December 2022 HHIT Use Bits Value Reference DET 28 TBD6 (suggested value 2001:30::/28) [This] Hierarchical HIT (HHIT) Suite ID: This 8-bit valued subregistry is a superset of the 4/8-bit "HIT Suite ID" subregistry of the "Host Identity Protocol (HIP) Parameters" registry in [IANA-HIP]. Future additions to this subregistry are to be made through IETF Review (Section 4.8 of [RFC8126]). The following HHIT Suite IDs are defined: HHIT Suite Value Reference RESERVED 0 RSA,DSA/SHA-256 1 [RFC7401] ECDSA/SHA-384 2 [RFC7401] ECDSA_LOW/SHA-1 3 [RFC7401] EdDSA/cSHAKE128 TBD3 (suggested value 5) [This] HDA Private Use 1 TBD4 (suggested value 254) [This] HDA Private Use 2 TBD5 (suggested value 255) [This] The HHIT Suite ID values 1 - 31 are reserved for IDs that MUST be replicated as HIT Suite IDs (Section 8.4) as is TBD3 here. Higher values (32 - 255) are for those Suite IDs that need not or cannot be accommodated as a HIT Suite ID. 8.3. IANA CGA Registry Update This document requests that this document be added to the reference field for the "CGA Extension Type Tags" registry [IANA-CGA], where IANA registers the following Context ID: Context ID: The Context ID (Section 3) shares the namespace introduced for CGA Type Tags. Defining new Context IDs follow the rules in Section 8 of [RFC3972]: Context ID := 0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40 [This] 8.4. IANA HIP Registry Updates This document requests IANA to make the following changes to the IANA "Host Identity Protocol (HIP) Parameters" [IANA-HIP] registry: Moskowitz, et al. Expires 5 June 2023 [Page 23] Internet-Draft DRIP Entity Tag (DET) December 2022 Host ID: This document defines the new EdDSA Host ID with value TBD1 (suggested: 13) (Section 3.4.1) in the "HI Algorithm" subregistry of the "Host Identity Protocol (HIP) Parameters" registry. Algorithm profile Value Reference EdDSA TBD1 (suggested value 13) [RFC8032] EdDSA Curve Label: This document specifies a new algorithm-specific subregistry named "EdDSA Curve Label". The values for this subregistry are defined in Section 3.4.1.1. Future additions to this subregistry are to be made through IETF Review (Section 4.8 of [RFC8126]). Algorithm Curve Values Reference EdDSA RESERVED 0 EdDSA EdDSA25519 1 [RFC8032] EdDSA EdDSA25519ph 2 [RFC8032] EdDSA EdDSA448 3 [RFC8032] EdDSA EdDSA448ph 4 [RFC8032] 5-65535 Unassigned HIT Suite ID: This document defines the new HIT Suite of EdDSA/cSHAKE with value TBD3 (suggested: 5) (Section 3.4.2) in the "HIT Suite ID" subregistry of the "Host Identity Protocol (HIP) Parameters" registry. HIT Suite Value Reference EdDSA/cSHAKE128 TBD3 (suggested value 5) [This] The HIT Suite ID 4-bit values 1 - 15 and 8-bit values 0x00 - 0x0F MUST be replicated as HHIT Suite IDs (Section 8.2) as is TBD3 here. 9. Security Considerations The 64-bit hash in HHITs presents a real risk of second pre-image cryptographic hash attack Section 9.5. There are no known (to the authors) studies of hash size to cryptographic hash attacks. Moskowitz, et al. Expires 5 June 2023 [Page 24] Internet-Draft DRIP Entity Tag (DET) December 2022 However, with today's computing power, producing 2^64 EdDSA keypairs and then generating the corresponding HHIT is economically feasible. Consider that a *single* bitcoin mining ASIC can do on the order of 2^46 sha256 hashes a second or about 2^62 hashes in a single day. The point being, 2^64 is not prohibitive, especially as this can be done in parallel. Now it should be noted that the 2^64 attempts is for stealing a specific HHIT. Consider a scenario of a street photography company with 1,024 UAs (each with its own HHIT); an attacker may well be satisfied stealing any one of them. Then rather than needing to satisfy a 64-bit condition on the cSHAKE128 output, an attacker needs only to satisfy what is equivalent to a 54-bit condition (since there are 2^10 more opportunities for success). Thus, although the probability of a collision or pre-image attack is low in a collection of 1,024 HHITs out of a total population of 2^64, per Section 9.5, it is computationally and economically feasible. Therefore, the HHIT registration is a MUST and HHIT/HI registration validation SHOULD be performed by Observers either through registry lookups or via broadcasted registration proofs (Section 3.1.2 of [drip-authentication]). The DET Registry services effectively block attempts to "take over" or "hijack" a DET. It does not stop a rogue attempting to impersonate a known DET. This attack can be mitigated by the receiver of messages containing DETs using DNS to find the HI for the DET. As such, use of DNSSEC by the DET registries is recommended to provide trust in HI retrieval. Another mitigation of HHIT hijacking is if the HI owner (UA) supplies an object containing the HHIT and signed by the HI private key of the HDA such as detailed in [drip-authentication]. The two risks with hierarchical HITs are the use of an invalid HID and forced HIT collisions. The use of a DNS zone (e.g., "det.arpa.") is a strong protection against invalid HIDs. Querying an HDA's RVS for a HIT under the HDA protects against talking to unregistered clients. The Registry service [drip-registries], through its HHIT uniqueness enforcement, provides against forced or accidental HHIT hash collisions. Moskowitz, et al. Expires 5 June 2023 [Page 25] Internet-Draft DRIP Entity Tag (DET) December 2022 Cryptographically Generated Addresses (CGAs) provide an assurance of uniqueness. This is two-fold. The address (in this case the UAS ID) is a hash of a public key and a Registry hierarchy naming. Collision resistance (more important that it implied second-preimage resistance) makes it statistically challenging to attacks. A registration process [drip-registries] within the HDA provides a level of assured uniqueness unattainable without mirroring this approach. The second aspect of assured uniqueness is the digital signing (evidence) process of the DET by the HI private key and the further signing (evidence) of the HI public key by the Registry's key. This completes the ownership process. The observer at this point does not know what owns the DET, but is assured, other than the risk of theft of the HI private key, that this UAS ID is owned by something and is properly registered. 9.1. Post Quantum Computing out of scope As stated in Section 8.1 of [drip-architecture], there has been no effort, at this time, to address post quantum computing cryptography. UAs and Broadcast Remote ID communications are so constrained that current post quantum computing cryptography is not applicable. Plus since a UA may use a unique DET for each operation, the attack window could be limited to the duration of the operation. HHITs contain the ID for the cryptographic suite used in its creation, a future post quantum computing safe algorithm that fits the Remote ID constraints may readily be added. 9.2. DET Trust in ASTM messaging The DET in the ASTM Basic ID Message (Msg Type 0x0, the actual Remote ID message) does not provide any assertion of trust. The best that might be done within this Basic ID Message is 4 bytes truncated from a HI signing of the HHIT (the UA ID field is 20 bytes and a HHIT is 16). This is not trustable; that is, too open to a hash attack. Minimally, it takes 84 bytes (Section 4.6) to prove ownership of a DET with a full EdDSA signature. Thus, no attempt has been made to add DET trust directly within the very small Basic ID Message. The ASTM Authentication Message (Msg Type 0x2) as shown in Section 4.6 can provide practical actual ownership proofs. These endorsements and evidences include timestamps to defend against replay attacks. But in themselves, they do not prove which UA sent the message. They could have been sent by a dog running down the street with a Broadcast Remote ID module strapped to its back. Moskowitz, et al. Expires 5 June 2023 [Page 26] Internet-Draft DRIP Entity Tag (DET) December 2022 Proof of UA transmission comes when the Authentication Message includes proofs for the ASTM Location/Vector Message (Msg Type 0x1) and the observer can see the UA or that information is validated by ground multilateration. Only then does an observer gain full trust in the DET of the UA. DETs obtained via the Network RID path provides a different approach to trust. Here the UAS SHOULD be securely communicating to the USS, thus asserting DET trust. 9.3. DET Revocation The DNS entry for the DET can also provide a revocation service. For example, instead of returning the HI RR it may return some record showing that the HI (and thus DET) has been revoked. Guidance on revocation service will be provided in [drip-registries]. 9.4. Privacy Considerations There is no expectation of privacy for DETs; it is not part of the privacy normative requirements listed in, Section 4.3.1, of [RFC9153]. DETs are broadcast in the clear over the open air via Bluetooth and Wi-Fi. They will be collected and collated with other public information about the UAS. This will include DET registration information and location and times of operations for a DET. A DET can be for the life of a UA if there is no concern about DET/UA activity harvesting. Further, the MAC address of the wireless interface used for Remote ID broadcasts are a target for UA operation aggregation that may not be mitigated through MAC address randomization. For Bluetooth 4 Remote ID messaging, the MAC address is used by observers to link the Basic ID Message that contains the RID with other Remote ID messages, thus must be constant for a UA operation. This message linkage use of MAC addresses may not be needed with the Bluetooth 5 or Wi-Fi PHYs. These PHYs provide for a larger message payload and can use the Message Pack (Msg Type 0xF) and the Authentication Message to transmit the RID with other Remote ID messages. However, it is not mandatory to send the RID in a Message Pack or Authentication Message, so allowance for using the MAC address for UA message linking must be maintained. That is, the MAC address should be stable for at least a UA operation. Finally, it is not adequate to simply change the DET and MAC for a UA per operation to defeat historically tracking a UA's activity. Moskowitz, et al. Expires 5 June 2023 [Page 27] Internet-Draft DRIP Entity Tag (DET) December 2022 Any changes to the UA MAC may have impacts to C2 setup and use. A constant GCS MAC may well defeat any privacy gains in UA MAC and RID changes. UA/GCS binding is complicated with changing MAC addresses; historically UAS design assumed these to be "forever" and made setup a one-time process. Additionally, if IP is used for C2, a changing MAC may mean a changing IP address to further impact the UAS bindings. Finally, an encryption wrapper's identifier (such as ESP [RFC4303] SPI) would need to change per operation to insure operation tracking separation. Creating and maintaining UAS operational privacy is a multifaceted problem. Many communication pieces need to be considered to truly create a separation between UA operations. Simply changing the DET only starts the changes that need to be implemented. These privacy realities may present challenges for the EU U-space (Appendix A) program. 9.5. Collision Risks with DETs The 64-bit hash size here for DETs does have an increased risk of collisions over the 96-bit hash size used for the ORCHID [RFC7343] construct. There is a 0.01% probability of a collision in a population of 66 million. The probability goes up to 1% for a population of 663 million. See Appendix D for the collision probability formula. However, this risk of collision is within a single "Additional Information" value, i.e., a RAA/HDA domain. The UAS/USS registration process should include registering the DET and MUST reject a collision, forcing the UAS to generate a new HI and thus HHIT and reapplying to the DET registration process (Section 6 of [drip-registries]). Thus an adversary trying to generate a collision and 'steal' the DET would run afoul of this registration process and associated validation process mentioned in Section 1.1. 10. References 10.1. Normative References [ipseckey-eddsa] Moskowitz, R., Kivinen, T., and M. Richardson, "EdDSA value for IPSECKEY", Work in Progress, Internet-Draft, draft-moskowitz-ipsecme-ipseckey-eddsa-06, 23 November 2022, . Moskowitz, et al. Expires 5 June 2023 [Page 28] Internet-Draft DRIP Entity Tag (DET) December 2022 [NIST.FIPS.202] Dworkin, M. J. and National Institute of Standards and Technology, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", DOI 10.6028/nist.fips.202, July 2015, . [NIST.SP.800-185] Kelsey, J., Change, S., Perlner, R., and National Institute of Standards and Technology, "SHA-3 derived functions: cSHAKE, KMAC, TupleHash and ParallelHash", DOI 10.6028/nist.sp.800-185, December 2016, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, . [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 2014, . [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, October 2016, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Moskowitz, et al. Expires 5 June 2023 [Page 29] Internet-Draft DRIP Entity Tag (DET) December 2022 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [cfrg-comment] "A CFRG review of draft-ietf-drip-rid", September 2021, . [corus] CORUS, "U-space Concept of Operations", September 2019, . [CTA2063A] ANSI/CTA, "Small Unmanned Aerial Systems Serial Numbers", September 2019, . [drip-architecture] Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Architecture", Work in Progress, Internet-Draft, draft-ietf-drip-arch-29, 16 August 2022, . [drip-authentication] Wiethuechter, A., Card, S. W., and R. Moskowitz, "DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID", Work in Progress, Internet-Draft, draft-ietf-drip-auth-26, 14 October 2022, . [drip-registries] Wiethuechter, A. and J. Reid, "DRIP Entity Tag (DET) Identity Management Architecture", Work in Progress, Internet-Draft, draft-ietf-drip-registries-06, 17 November 2022, . [F3411-22a] ASTM International, "Standard Specification for Remote ID and Tracking - F3411−22a", July 2022, . Moskowitz, et al. Expires 5 June 2023 [Page 30] Internet-Draft DRIP Entity Tag (DET) December 2022 [FAA_RID] United States Federal Aviation Administration (FAA), "Remote Identification of Unmanned Aircraft", 2021, . [IANA-CGA] IANA, "Cryptographically Generated Addresses (CGA) Message Type Name Space", . [IANA-HIP] IANA, "Host Identity Protocol (HIP) Parameters", . [Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and R. Van Keer, "The Keccak Function", . [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, . [RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, October 2016, . Moskowitz, et al. Expires 5 June 2023 [Page 31] Internet-Draft DRIP Entity Tag (DET) December 2022 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC9063] Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021, . [RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Requirements and Terminology", RFC 9153, DOI 10.17487/RFC9153, February 2022, . [RFC9224] Blanchet, M., "Finding the Authoritative Registration Data Access Protocol (RDAP) Service", STD 95, RFC 9224, DOI 10.17487/RFC9224, March 2022, . Appendix A. EU U-Space RID Privacy Considerations The EU is defining a future of airspace management known as U-space within the Single European Sky ATM Research (SESAR) undertaking. Concept of Operation for EuRopean UTM Systems (CORUS) project proposed low-level Concept of Operations [corus] for UAS in the EU. It introduces strong requirements for UAS privacy based on European GDPR regulations. It suggests that UAs are identified with agnostic IDs, with no information about UA type, the operators or flight trajectory. Only authorized persons should be able to query the details of the flight with a record of access. Due to the high privacy requirements, a casual observer can only query U-space if it is aware of a UA seen in a certain area. A general observer can use a public U-space portal to query UA details based on the UA transmitted "Remote identification" signal. Direct remote identification (DRID) is based on a signal transmitted by the UA directly. Network remote identification (NRID) is only possible for UAs being tracked by U-Space and is based on the matching the current UA position to one of the tracks. This is potentially a contrary expectation as that presented in Section 9.4. U-space will have to deal with this reality within the GDPR regulations. Still, DETs as defined here present a large step in the right direction for agnostic IDs. Moskowitz, et al. Expires 5 June 2023 [Page 32] Internet-Draft DRIP Entity Tag (DET) December 2022 The project lists "E-Identification" and "E-Registrations" services as to be developed. These services can use DETs and follow the privacy considerations outlined in this document for DETs. If an "agnostic ID" above refers to a completely random identifier, it creates a problem with identity resolution and detection of misuse. On the other hand, a classical HIT has a flat structure which makes its resolution difficult. The DET (Hierarchical HIT) provides a balanced solution by associating a registry with the UA identifier. This is not likely to cause a major conflict with U-space privacy requirements, as the registries are typically few at a country level (e.g., civil personal, military, law enforcement, or commercial). Appendix B. The 14/14 HID split The following explains the logic behind selecting to divide the 28 bits of the HID into 2 14-bit components. At this writing ICAO has 273 member "States", each may want to control RID assignment within its National Air Space (NAS). Some members may want separate RAAs to use for Civil, general Government, and Military use. They may also want allowances for competing Civil RAA operations. It is reasonable to plan for 8 RAAs per ICAO member (plus regional aviation organizations like in the European Union). Thus at a start a 4,096 RAA space is advised. There will be requests by commercial entities for their own, RAA allotments. Examples could include international organizations that will be using UAS and international delivery service associations. These may be smaller than the RAA space needed by ICAO member States and could be met with a 2,048 space allotment, but as will be seen, might as well be 4,096 as well. This may well cover currently understood RAA entities. There will be future new applications, branching off into new areas. So yet another space allocation should be set aside. If this is equal to all that has been reserved, we should allow for 16,384 (2^14) RAAs. The HDA allocation follows a different logic from that of RAAs. Per Appendix D, an HDA should be able to easily assign 63M RIDs and even manage 663M with a "first come, first assigned" registration process. For most HDAs this is more than enough, and a single HDA assignment within their RAA will suffice. Most RAAs will only delegate to a couple HDAs for their operational needs. But there are major exceptions that point to some RAAs needing large numbers of HDA assignments. Moskowitz, et al. Expires 5 June 2023 [Page 33] Internet-Draft DRIP Entity Tag (DET) December 2022 Delivery service operators like Amazon (est. 30K delivery vans) and UPS (est. 500K delivery vans) may choose, for anti-tracking reasons, to use unique RIDs per day or even per operation. 30K delivery UA could need 11M upwards to 44M RIDs. Anti-tracking would be hard to provide if the HID were the same for a delivery service fleet, so such a company may turn to an HDA that provides this service to multiple companies so that who's UA is who's is not evident in the HID. A USS providing this service could well use multiple HDA assignments per year, depending on strategy. Perhaps a single RAA providing HDAs for delivery service (or similar behaving) UAS could 'get by' with a 2048 HDA space (11-bits). So the HDA space could well be served with only 12 bits allocated out of the 28-bit HID space. But as this is speculation, and it will take years of deployment experience, a 14-bit HDA space has been selected. There may also be 'small' ICAO member States that opt for a single RAA and allocate their HDAs for all UA that are permitted in their NAS. The HDA space is large enough that some to use part for government needs as stated above and for small commercial needs. Or the State may use a separate, consecutive RAA for commercial users. Thus it would be 'easy' to recognize State-approved UA by HID high- order bits. B.1. DET Encoding Example The DET upper 64 bits appear to be oddly constructed from nibbled fields, when typically seen in 8-bit representations. The following works out the construction of the example in Section 5. In that example the prefix is 2001:30::/28, the RAA is decimal 10 and the HDA is decimal 20. Below is the RAA and HDA in 14-bit format: RAA 10 = 00000000001010 HDA 20 = 00000000010100 The left most 4 bits of the RAA, all zeros, combine with the prefix to form 2001:0030:, leaving remaining RAA and HDA combined to: 0000|0010|1000|0000|0001|0100| Which, combined with the OGA of x05 is: 0280:1405, thus the whole upper 64 bits are 2001:0030:0280:1405. Moskowitz, et al. Expires 5 June 2023 [Page 34] Internet-Draft DRIP Entity Tag (DET) December 2022 Appendix C. Base32 Alphabet The alphabet used in CTA 2063-A Serial Number does not lend to using any published Base32 encoding scheme. Thus the following Base32 Alphabet is used. Each 5-bit group is used as an index into an array of 32 printable characters. The character referenced by the index is placed in the output string. These characters, identified below, are selected from US-ASCII digits and uppercase letters. +=====+========+=====+==========+=====+==========+=====+==========+ |Value|Encoding|Value| Encoding |Value| Encoding |Value| Encoding | +=====+========+=====+==========+=====+==========+=====+==========+ | 0|0 | 8| 8 | 16| G | 24| Q | +-----+--------+-----+----------+-----+----------+-----+----------+ | 1|1 | 9| 9 | 17| H | 25| R | +-----+--------+-----+----------+-----+----------+-----+----------+ | 2|2 | 10| A | 18| J | 26| T | +-----+--------+-----+----------+-----+----------+-----+----------+ | 3|3 | 11| B | 19| K | 27| U | +-----+--------+-----+----------+-----+----------+-----+----------+ | 4|4 | 12| C | 20| L | 28| V | +-----+--------+-----+----------+-----+----------+-----+----------+ | 5|5 | 13| D | 21| M | 29| W | +-----+--------+-----+----------+-----+----------+-----+----------+ | 6|6 | 14| E | 22| N | 30| X | +-----+--------+-----+----------+-----+----------+-----+----------+ | 7|7 | 15| F | 23| P | 31| Y | +-----+--------+-----+----------+-----+----------+-----+----------+ Table 2: The Base 32 Alphabet Appendix D. Calculating Collision Probabilities The accepted formula for calculating the probability of a collision is: p = 1 - e^{-k^2/(2n)} P Collision Probability n Total possible population k Actual population The following table provides the approximate population size for a collision for a given total population. Moskowitz, et al. Expires 5 June 2023 [Page 35] Internet-Draft DRIP Entity Tag (DET) December 2022 Deployed Population Total With Collision Risk of Population .01% 1% 2^96 4T 42T 2^72 1B 10B 2^68 250M 2.5B 2^64 66M 663M 2^60 16M 160M Acknowledgments Dr. Gurtov is an adviser on Cybersecurity to the Swedish Civil Aviation Administration. Quynh Dang of NIST gave considerable guidance on using Keccak and the NIST supporting documents. Joan Deamen of the Keccak team was especially helpful in many aspects of using Keccak. Nicholas Gajcowski [cfrg-comment] provided a concise hash pre-image security assessment via the CFRG list. Many thanks to Michael Richardson and Brian Haberman for the iotdir review, Magnus Nystrom for the secdir review, Elwyn Davies for genart review and DRIP co-chair and draft shepherd, Mohamed Boucadair for his extensive comments and help on document clarity. And finally, many thanks to area directors: Roman Danyliw, Erik Kline, Murray Kucherawy, Warren Kumari, John Scudder, Paul Wouters, and Sarker Zaheduzzaman, for the IESG review. Authors' Addresses Robert Moskowitz HTT Consulting Oak Park, MI 48237 United States of America Email: rgm@labs.htt-consult.com Stuart W. Card AX Enterprize, LLC 4947 Commercial Drive Yorkville, NY 13495 United States of America Email: stu.card@axenterprize.com Moskowitz, et al. Expires 5 June 2023 [Page 36] Internet-Draft DRIP Entity Tag (DET) December 2022 Adam Wiethuechter AX Enterprize, LLC 4947 Commercial Drive Yorkville, NY 13495 United States of America Email: adam.wiethuechter@axenterprize.com Andrei Gurtov Linköping University IDA SE-58183 Linköping Sweden Email: gurtov@acm.org Moskowitz, et al. Expires 5 June 2023 [Page 37] ./draft-ietf-lpwan-schc-yang-data-model-21.txt0000644000764400076440000030374214320560446020664 0ustar iustiniustin lpwan Working Group A. Minaburo Internet-Draft Acklio Intended status: Standards Track L. Toutain Expires: 12 April 2023 Institut MINES TELECOM; IMT Atlantique 9 October 2022 Data Model for Static Context Header Compression (SCHC) draft-ietf-lpwan-schc-yang-data-model-21 Abstract This document describes a YANG data model for the SCHC (Static Context Header Compression) compression and fragmentation rules. This document formalizes the description of the rules for better interoperability between SCHC instances either to exchange a set of rules or to modify some rules parameters. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Minaburo & Toutain Expires 12 April 2023 [Page 1] Internet-Draft LPWAN SCHC YANG module October 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. SCHC rules . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 5 4.2. Identifier generation . . . . . . . . . . . . . . . . . . 6 4.3. Convention for Field Identifier . . . . . . . . . . . . . 7 4.4. Convention for Field length . . . . . . . . . . . . . . . 8 4.5. Convention for Field position . . . . . . . . . . . . . . 8 4.6. Convention for Direction Indicator . . . . . . . . . . . 8 4.7. Convention for Target Value . . . . . . . . . . . . . . . 9 4.8. Convention for Matching Operator . . . . . . . . . . . . 9 4.8.1. Matching Operator arguments . . . . . . . . . . . . . 9 4.9. Convention for Compression Decompression Actions . . . . 9 4.9.1. Compression Decompression Action arguments . . . . . 9 4.10. Fragmentation rule . . . . . . . . . . . . . . . . . . . 9 4.10.1. Fragmentation mode . . . . . . . . . . . . . . . . . 10 4.10.2. Fragmentation Header . . . . . . . . . . . . . . . . 10 4.10.3. Last fragment format . . . . . . . . . . . . . . . . 11 4.10.4. Acknowledgment behavior . . . . . . . . . . . . . . 11 4.10.5. Timer values . . . . . . . . . . . . . . . . . . . . 12 4.10.6. Fragmentation Parameter . . . . . . . . . . . . . . 12 4.10.7. Layer 2 parameters . . . . . . . . . . . . . . . . . 12 5. Rule definition . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Compression rule . . . . . . . . . . . . . . . . . . . . 13 5.2. Fragmentation rule . . . . . . . . . . . . . . . . . . . 14 5.3. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 14 6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 45 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 8.1. URI Registration . . . . . . . . . . . . . . . . . . . 46 8.2. YANG Module Name Registration . . . . . . . . . . . . . 46 9. Security Considerations . . . . . . . . . . . . . . . . . . . 47 10. Annex A : Example . . . . . . . . . . . . . . . . . . . . . . 48 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 12.1. Normative References . . . . . . . . . . . . . . . . . . 51 Minaburo & Toutain Expires 12 April 2023 [Page 2] Internet-Draft LPWAN SCHC YANG module October 2022 12.2. Informative References . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 1. Introduction SCHC is a compression and fragmentation mechanism for constrained networks defined in [RFC8724]. It is based on a static context shared by two entities at the boundary of the constrained network. [RFC8724] provides an informal representation of the rules used either for compression/decompression (or C/D) or fragmentation/ reassembly (or F/R). The goal of this document is to formalize the description of the rules to offer: * the same definition on both ends, even if the internal representation is different; * an update of the other end to set up some specific values (e.g. IPv6 prefix, destination address,...). [I-D.ietf-lpwan-architecture] illustrates the exchange of rules using the YANG data model. This document defines a YANG module [RFC7950] to represent both compression and fragmentation rules, which leads to common representation for values for all the rules elements. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology This section defines the terminology and acronyms used in this document. It extends the terminology of [RFC8376]. * App: LPWAN Application, as defined by [RFC8376]. An application sending/receiving packets to/from the Dev. * Bi: Bidirectional. Characterizes a Field Descriptor that applies to headers of packets traveling in either direction (Up and Dw, see this glossary). Minaburo & Toutain Expires 12 April 2023 [Page 3] Internet-Draft LPWAN SCHC YANG module October 2022 * CDA: Compression/Decompression Action. Describes the pair of actions that are performed at the compressor to compress a header field and at the decompressor to recover the original value of the header field. * Context: A set of Rules used to compress/decompress headers. * Dev: Device, as defined by [RFC8376]. * DevIID: Device Interface Identifier. The IID that identifies the Dev interface. * DI: Direction Indicator. This field tells which direction of packet travel (Up, Dw or Bi) a Field Description applies to. This allows for asymmetric processing, using the same Rule. * Dw: Downlink direction for compression/decompression, from SCHC C/ D in the network to SCHC C/D in the Dev. * FID: Field Identifier. This identifies the protocol and field a Field Description applies to. * FL: Field Length is the length of the original packet header field. It is expressed as a number of bits for header fields of fixed lengths or as a type (e.g., variable, token length, ...) for field lengths that are unknown at the time of Rule creation. The length of a header field is defined in the corresponding protocol specification (such as IPv6 or UDP). * FP: when a Field is expected to appear multiple times in a header, Field Position specifies the occurrence this Field Description applies to (for example, first uri-path option, second uri-path, etc. in a CoAP header), counting from 1. The value 0 is special and means "don't care", see [RFC8724] Section 7.2. * IID: Interface Identifier. See the IPv6 addressing architecture [RFC7136]. * L2 Word: this is the minimum subdivision of payload data that the L2 will carry. In most L2 technologies, the L2 Word is an octet. In bit-oriented radio technologies, the L2 Word might be a single bit. The L2 Word size is assumed to be constant over time for each device. * MO: Matching Operator. An operator used to match a value contained in a header field with a value contained in a Rule. Minaburo & Toutain Expires 12 April 2023 [Page 4] Internet-Draft LPWAN SCHC YANG module October 2022 * Rule ID (Rule Identifier): An identifier for a Rule. SCHC C/D on both sides share the same Rule ID for a given packet. A set of Rule IDs are used to support SCHC F/R functionality. * TV: Target value. A value contained in a Rule that will be matched with the value of a header field. * Up: Uplink direction for compression/decompression, from the Dev SCHC C/D to the network SCHC C/D. 4. SCHC rules SCHC compression is generic, the main mechanism does not refer to a specific protocol. Any header field is abstracted through an Field Identifier (FID), a position (FP), a direction (DI), and a value that can be a numerical value or a string. [RFC8724] and [RFC8824] specify fields for IPv6 [RFC8200], UDP[RFC0768], CoAP [RFC7252] including options defined for no server response [RFC7967] and OSCORE [RFC8613]. For the latter [RFC8824] splits this field into sub- fields. SCHC fragmentation requires a set of common parameters that are included in a rule. These parameters are defined in [RFC8724]. The YANG data model enables the compression and the fragmentation selection using the feature statement. 4.1. Compression Rules [RFC8724] proposes an informal representation of the compression rule. A compression context for a device is composed of a set of rules. Each rule contains information to describe a specific field in the header to be compressed. Minaburo & Toutain Expires 12 April 2023 [Page 5] Internet-Draft LPWAN SCHC YANG module October 2022 +-----------------------------------------------------------------+ | Rule N | +-----------------------------------------------------------------+| | Rule i || +-----------------------------------------------------------------+|| | (FID) Rule 1 ||| |+-------+--+--+--+------------+-----------------+---------------+||| ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| |+-------+--+--+--+------------+-----------------+---------------+||| ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| |+-------+--+--+--+------------+-----------------+---------------+||| ||... |..|..|..| ... | ... | ... |||| |+-------+--+--+--+------------+-----------------+---------------+||/ ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| |+-------+--+--+--+------------+-----------------+---------------+|/ | | \-----------------------------------------------------------------/ Figure 1: Compression Decompression Context 4.2. Identifier generation Identifiers used in the SCHC YANG data model are from the identityref statement to ensure global uniqueness and easy augmentation if needed. The principle to define a new type based on a group of identityref is the following: * define a main identity ending with the keyword base-type. * derive all the identities used in the Data Model from this base type. * create a typedef from this base type. The example (Figure 2) shows how an identityref is created for RCS (Reassembly Check Sequence) algorithms used during SCHC fragmentation. Minaburo & Toutain Expires 12 April 2023 [Page 6] Internet-Draft LPWAN SCHC YANG module October 2022 identity rcs-algorithm-base-type { description "Identify which algorithm is used to compute RCS. The algorithm also defines the size of the RCS field."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } identity rcs-crc32 { base rcs-algorithm-base-type; description "CRC 32 defined as default RCS in RFC8724. This RCS is 4 bytes long."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } typedef rcs-algorithm-type { type identityref { base rcs-algorithm-base-type; } description "Define the type for RCS algorithm in rules."; } Figure 2: Principle to define a type based on identityref. 4.3. Convention for Field Identifier In the process of compression, the headers of the original packet are first parsed to create a list of fields. This list of fields is matched against the rules to find the appropriate rule and apply compression. [RFC8724] does not state how the field ID value is constructed. In examples, identification is done through a string indexed by the protocol name (e.g. IPv6.version, CoAP.version,...). The current YANG data model includes fields definitions found in [RFC8724], [RFC8824]. Minaburo & Toutain Expires 12 April 2023 [Page 7] Internet-Draft LPWAN SCHC YANG module October 2022 Using the YANG data model, each field MUST be identified through a global YANG identityref. A YANG field ID for the protocol is always derived from the fid-base- type. Then an identity for each protocol is specified using the naming convention fid-<>-base-type. All possible fields for this protocol MUST derive from the protocol identity. The naming convention is "fid-" followed by the protocol name and the field name. If a field has to be divided into sub-fields, the field identity serves as a base. The full field-id definition is found in Section 6. A type is defined for IPv6 protocol, and each field is based on it. Note that the DiffServ bits derive from the Traffic Class identity. 4.4. Convention for Field length Field length is either an integer giving the size of a field in bits or a specific function. [RFC8724] defines the "var" function which allows variable length fields (whose length is expressed in bytes) and [RFC8824] defines the "tkl" function for managing the CoAP Token length field. The naming convention is "fl-" followed by the function name. The field length function can be defined as an identityref as described in Section 6. Therefore, the type for field length is a union between an integer giving the size of the length in bits and the identityref. 4.5. Convention for Field position Field position is a positive integer which gives the occurrence times of a specific field from the header start. The default value is 1, and incremented at each repetition. Value 0 indicates that the position is not important and is not considered during the rule selection process. Field position is a positive integer. The type is uint8. 4.6. Convention for Direction Indicator The Direction Indicator (di) is used to tell if a field appears in both directions (Bi) or only uplink (Up) or Downlink (Dw). The naming convention is "di" followed by the Direction Indicator name. The type is "di-type". Minaburo & Toutain Expires 12 April 2023 [Page 8] Internet-Draft LPWAN SCHC YANG module October 2022 4.7. Convention for Target Value The Target Value is a list of binary sequences of any length, aligned to the left. In the rule, the structure will be used as a list, with index as a key. The highest index value is used to compute the size of the index sent in residue for the match-mapping CDA (Compression Decompression Action). The index can specify several values: * For Equal and MSB, Target Value contains a single element. Therefore, the index is set to 0. * For match-mapping, Target Value can contain several elements. Index values MUST start from 0 and MUST be contiguous. If the header field contains text, the binary sequence uses the same encoding. 4.8. Convention for Matching Operator Matching Operator (MO) is a function applied between a field value provided by the parsed header and the target value. [RFC8724] defines 4 MO. The naming convention is "mo-" followed by the MO name. The type is "mo-type" 4.8.1. Matching Operator arguments They are viewed as a list, built with a tv-struct (see Section 4.7). 4.9. Convention for Compression Decompression Actions Compression Decompression Action (CDA) identifies the function to use for compression or decompression. [RFC8724] defines 6 CDA. The naming convention is "cda-" followed by the CDA name. 4.9.1. Compression Decompression Action arguments Currently no CDA requires arguments, but in the future some CDA may require one or several arguments. They are viewed as a list, of target-value type. 4.10. Fragmentation rule Fragmentation is optional in the data model and depends on the presence of the "fragmentation" feature. Minaburo & Toutain Expires 12 April 2023 [Page 9] Internet-Draft LPWAN SCHC YANG module October 2022 Most of the fragmentation parameters are listed in Annex D of [RFC8724]. Since fragmentation rules work for a specific direction, they MUST contain a mandatory direction indicator. The type is the same as the one used in compression entries, but bidirectional MUST NOT be used. 4.10.1. Fragmentation mode [RFC8724] defines 3 fragmentation modes: * No Ack: this mode is unidirectional, no acknowledgment is sent back. * Ack Always: each fragmentation window must be explicitly acknowledged before going to the next. * Ack on Error: A window is acknowledged only when the receiver detects some missing fragments. The type is "fragmentation-mode-type". The naming convention is "fragmentation-mode-" followed by the fragmentation mode name. 4.10.2. Fragmentation Header A data fragment header, starting with the rule ID, can be sent in the fragmentation direction. [RFC8724] indicates that the SCHC header may be composed of (cf. Figure 3): * a Datagram Tag (Dtag) identifying the datagram being fragmented if the fragmentation applies concurrently on several datagrams. This field is optional and its length is defined by the rule. * a Window (W) used in Ack-Always and Ack-on-Error modes. In Ack- Always, its size is 1. In Ack-on-Error, it depends on the rule. This field is not needed in No-Ack mode. * a Fragment Compressed Number (FCN) indicating the fragment/tile position within the window. This field is mandatory on all modes defined in [RFC8724], its size is defined by the rule. |-- SCHC Fragment Header ----| |-- T --|-M-|-- N --| +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~ | RuleID | DTag | W | FCN | Fragment Payload | padding (as needed) +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~ Figure 3: Data fragment header from RFC8724 Minaburo & Toutain Expires 12 April 2023 [Page 10] Internet-Draft LPWAN SCHC YANG module October 2022 4.10.3. Last fragment format The last fragment of a datagram is sent with an RCS (Reassembly Check Sequence) field to detect residual transmission error and possible losses in the last window. [RFC8724] defines a single algorithm based on Ethernet CRC computation. The naming convention is "rcs-" followed by the algorithm name. For Ack-on-Error mode, the All-1 fragment may just contain the RCS or can include a tile. The parameters define the behavior: * all-1-data-no: the last fragment contains no data, just the RCS * all-1-data-yes: the last fragment includes a single tile and the RCS * all-1-data-sender-choice: the last fragment may or may not contain a single tile. The receiver can detect if a tile is present. The naming convention is "all-1-data-" followed by the behavior identifier. 4.10.4. Acknowledgment behavior The acknowledgment fragment header goes in the opposite direction of data. [RFC8724] defines the header, composed of (see Figure 4): * a Dtag (if present). * a mandatory window as in the data fragment. * a C bit giving the status of RCS validation. In case of failure, a bitmap follows, indicating the received tile. |--- SCHC ACK Header ----| |-- T --|-M-| 1 | +-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ | RuleID | DTag | W |C=1| padding as needed (success) +-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~ +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ | RuleID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure) +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~ Figure 4: Acknowledgment fragment header for RFC8724 Minaburo & Toutain Expires 12 April 2023 [Page 11] Internet-Draft LPWAN SCHC YANG module October 2022 For Ack-on-Error, SCHC defines when an acknowledgment can be sent. This can be at any time defined by the layer 2, at the end of a window (FCN all-0) or as a response to receiving the last fragment (FCN all-1). The naming convention is "ack-behavior" followed by the algorithm name. 4.10.5. Timer values The state machine requires some common values to handle fragmentation correctly. * retransmission-timer gives the duration before sending an ack request (cf. section 8.2.2.4. of [RFC8724]). If specified, value MUST be strictly positive. * inactivity-timer gives the duration before aborting a fragmentation session (cf. section 8.2.2.4. of [RFC8724]). The value 0 explicitly indicates that this timer is disabled. [RFC8724] do not specify any range for these timers. [RFC9011] recommends a duration of 12 hours. In fact, the value range should be between milliseconds for real time systems to several days. To allow a large range of applications, two parameters must be specified: * the duration of a tick. It is computed by this formula 2^tick- duration/10^6. When tick-duration is set to 0, the unit is the microsecond. The default value of 20 leads to a unit of 1.048575 second. A value of 32 leads to a tick duration of about 1 hour 11 minutes. * the number of ticks in the predefined unit. With the default tick-duration value of 20, the timers can cover a range between 1.0 sec and 19 hours covering [RFC9011] recommendation. 4.10.6. Fragmentation Parameter The SCHC fragmentation protocol specifies the number of attempts before aborting through the parameter: * max-ack-requests (cf. section 8.2.2.4. of [RFC8724]). 4.10.7. Layer 2 parameters The data model includes two parameters needed for fragmentation: Minaburo & Toutain Expires 12 April 2023 [Page 12] Internet-Draft LPWAN SCHC YANG module October 2022 * l2-word-size: [RFC8724] base fragmentation, in bits, on a layer 2 word which can be of any length. The default value is 8 and correspond to the default value for byte aligned layer 2. A value of 1 will indicate that there is no alignment and no need for padding. * maximum-packet-size: defines the maximum size of an uncompressed datagram. By default, the value is set to 1280 bytes. They are defined as unsigned integers, see Section 6. 5. Rule definition A rule is identified by a unique rule identifier (rule ID) comprising both a Rule ID value and a Rule ID length. The YANG grouping rule- id-type defines the structure used to represent a rule ID. A length of 0 is allowed to represent an implicit rule. Three natures of rules are defined in [RFC8724]: * Compression: a compression rule is associated with the rule ID. * No compression: this identifies the default rule used to send a packet integrally when no compression rule was found (see [RFC8724] section 6). * Fragmentation: fragmentation parameters are associated with the rule ID. Fragmentation is optional and feature "fragmentation" should be set. The YANG data model introduces respectively these three identities : * nature-compression * nature-no-compression * nature-fragmentation The naming convention is "nature-" followed by the nature identifier. To access a specific rule, the rule ID length and value are used as a key. The rule is either a compression or a fragmentation rule. 5.1. Compression rule A compression rule is composed of entries describing its processing. An entry contains all the information defined in Figure 1 with the types defined above. Minaburo & Toutain Expires 12 April 2023 [Page 13] Internet-Draft LPWAN SCHC YANG module October 2022 The compression rule described Figure 1 is defined by compression- content. It defines a list of compression-rule-entry, indexed by their field id, position and direction. The compression-rule-entry element represent a line of the table Figure 1. Their type reflects the identifier types defined in Section 4.1 Some checks are performed on the values: * target value MUST be present for MO different from ignore. * when MSB MO is specified, the matching-operator-value must be present 5.2. Fragmentation rule A Fragmentation rule is composed of entries describing the protocol behavior. Some on them are numerical entries, others are identifiers defined in Section 4.10. 5.3. YANG Tree The YANG data model described in this document conforms to the Network Management Datastore Architecture defined in [RFC8342]. module: ietf-schc +--rw schc +--rw rule* [rule-id-value rule-id-length] +--rw rule-id-value uint32 +--rw rule-id-length uint8 +--rw rule-nature nature-type +--rw (nature)? +--:(fragmentation) {fragmentation}? | +--rw fragmentation-mode | | schc:fragmentation-mode-type | +--rw l2-word-size? uint8 | +--rw direction schc:di-type | +--rw dtag-size? uint8 | +--rw w-size? uint8 | +--rw fcn-size uint8 | +--rw rcs-algorithm? rcs-algorithm-type | +--rw maximum-packet-size? uint16 | +--rw window-size? uint16 | +--rw max-interleaved-frames? uint8 | +--rw inactivity-timer | | +--rw ticks-duration? uint8 | | +--rw ticks-numbers? uint16 | +--rw retransmission-timer | | +--rw ticks-duration? uint8 Minaburo & Toutain Expires 12 April 2023 [Page 14] Internet-Draft LPWAN SCHC YANG module October 2022 | | +--rw ticks-numbers? uint16 | +--rw max-ack-requests? uint8 | +--rw (mode)? | +--:(no-ack) | +--:(ack-always) | +--:(ack-on-error) | +--rw tile-size? uint8 | +--rw tile-in-all-1? schc:all-1-data-type | +--rw ack-behavior? schc:ack-behavior-type +--:(compression) {compression}? +--rw entry* [field-id field-position direction-indicator] +--rw field-id schc:fid-type +--rw field-length schc:fl-type +--rw field-position uint8 +--rw direction-indicator schc:di-type +--rw target-value* [index] | +--rw index uint16 | +--rw value? binary +--rw matching-operator schc:mo-type +--rw matching-operator-value* [index] | +--rw index uint16 | +--rw value? binary +--rw comp-decomp-action schc:cda-type +--rw comp-decomp-action-value* [index] +--rw index uint16 +--rw value? binary Figure 5: Overview of SCHC data model 6. YANG Module file "ietf-schc@2022-10-09.yang" module ietf-schc { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-schc"; prefix schc; organization "IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group"; contact "WG Web: WG List: Editor: Laurent Toutain Editor: Ana Minaburo "; Minaburo & Toutain Expires 12 April 2023 [Page 15] Internet-Draft LPWAN SCHC YANG module October 2022 description " Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. *************************************************************** Generic Data model for Static Context Header Compression Rule for SCHC, based on RFC 8724 and RFC8824. Include compression, no compression and fragmentation rules. This module is a YANG model for SCHC rules (RFC 8724 and RFC8824). RFC 8724 describes compression rules in a abstract way through a table. |-----------------------------------------------------------------| | (FID) Rule 1 | |+-------+--+--+--+------------+-----------------+---------------+| ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| |+-------+--+--+--+------------+-----------------+---------------+| ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| |+-------+--+--+--+------------+-----------------+---------------+| ||... |..|..|..| ... | ... | ... || |+-------+--+--+--+------------+-----------------+---------------+| ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|| |+-------+--+--+--+------------+-----------------+---------------+| |-----------------------------------------------------------------| This module specifies a global data model that can be used for rule exchanges or modification. It specifies both the data model format and the global identifiers used to describe some Minaburo & Toutain Expires 12 April 2023 [Page 16] Internet-Draft LPWAN SCHC YANG module October 2022 operations in fields. This data model applies to both compression and fragmentation."; revision 2022-10-09 { description "Initial version from RFC XXXX."; reference "RFC XXX: Data Model for Static Context Header Compression (SCHC)"; } feature compression { description "SCHC compression capabilities are taken into account."; } feature fragmentation { description "SCHC fragmentation capabilities are taken into account."; } // ------------------------- // Field ID type definition //-------------------------- // generic value TV definition identity fid-base-type { description "Field ID base type for all fields."; } identity fid-ipv6-base-type { base fid-base-type; description "Field ID base type for IPv6 headers described in RFC 8200."; reference "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification"; } identity fid-ipv6-version { base fid-ipv6-base-type; description "IPv6 version field."; reference "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification"; } identity fid-ipv6-trafficclass { Minaburo & Toutain Expires 12 April 2023 [Page 17] Internet-Draft LPWAN SCHC YANG module October 2022 base fid-ipv6-base-type; description "IPv6 Traffic Class field."; reference "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification"; } identity fid-ipv6-trafficclass-ds { base fid-ipv6-trafficclass; description "IPv6 Traffic Class field: DiffServ field."; reference "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification, RFC 3168 The Addition of Explicit Congestion Notification (ECN) to IP"; } identity fid-ipv6-trafficclass-ecn { base fid-ipv6-trafficclass; description "IPv6 Traffic Class field: ECN field."; reference "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification, RFC 3168 The Addition of Explicit Congestion Notification (ECN) to IP"; } identity fid-ipv6-flowlabel { base fid-ipv6-base-type; description "IPv6 Flow Label field."; reference "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification"; } identity fid-ipv6-payload-length { base fid-ipv6-base-type; description "IPv6 Payload Length field."; reference "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification"; } identity fid-ipv6-nextheader { base fid-ipv6-base-type; description "IPv6 Next Header field."; reference Minaburo & Toutain Expires 12 April 2023 [Page 18] Internet-Draft LPWAN SCHC YANG module October 2022 "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification"; } identity fid-ipv6-hoplimit { base fid-ipv6-base-type; description "IPv6 Next Header field."; reference "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification"; } identity fid-ipv6-devprefix { base fid-ipv6-base-type; description "Corresponds to either the source address or the destination address prefix of RFC 8200 depending on whether it is an uplink or a downlink message."; reference "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification"; } identity fid-ipv6-deviid { base fid-ipv6-base-type; description "Corresponds to either the source address or the destination address IID of RFC 8200 depending on whether it is an uplink or a downlink message."; reference "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification"; } identity fid-ipv6-appprefix { base fid-ipv6-base-type; description "Corresponds to either the source address or the destination address prefix of RFC 8200 depending on whether it is an uplink or a downlink message."; reference "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification"; } identity fid-ipv6-appiid { base fid-ipv6-base-type; description "Corresponds to either the source address or the destination address IID of RFC 8200 depending on whether it is an uplink or a downlink message."; reference Minaburo & Toutain Expires 12 April 2023 [Page 19] Internet-Draft LPWAN SCHC YANG module October 2022 "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification"; } identity fid-udp-base-type { base fid-base-type; description "Field ID base type for UDP headers described in RFC 768."; reference "RFC 768 User Datagram Protocol"; } identity fid-udp-dev-port { base fid-udp-base-type; description "UDP source or destination port, if uplink or downlink communication, respectively."; reference "RFC 768 User Datagram Protocol"; } identity fid-udp-app-port { base fid-udp-base-type; description "UDP destination or source port, if uplink or downlink communication, respectively."; reference "RFC 768 User Datagram Protocol"; } identity fid-udp-length { base fid-udp-base-type; description "UDP length."; reference "RFC 768 User Datagram Protocol"; } identity fid-udp-checksum { base fid-udp-base-type; description "UDP length."; reference "RFC 768 User Datagram Protocol"; } identity fid-coap-base-type { base fid-base-type; description Minaburo & Toutain Expires 12 April 2023 [Page 20] Internet-Draft LPWAN SCHC YANG module October 2022 "Field ID base type for UDP headers described."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-version { base fid-coap-base-type; description "CoAP version."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-type { base fid-coap-base-type; description "CoAP type."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-tkl { base fid-coap-base-type; description "CoAP token length."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-code { base fid-coap-base-type; description "CoAP code."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-code-class { base fid-coap-code; description "CoAP code class."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-code-detail { base fid-coap-code; description Minaburo & Toutain Expires 12 April 2023 [Page 21] Internet-Draft LPWAN SCHC YANG module October 2022 "CoAP code detail."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-mid { base fid-coap-base-type; description "CoAP message ID."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-token { base fid-coap-base-type; description "CoAP token."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-if-match { base fid-coap-base-type; description "CoAP option If-Match."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-uri-host { base fid-coap-base-type; description "CoAP option URI-Host."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-etag { base fid-coap-base-type; description "CoAP option Etag."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-if-none-match { base fid-coap-base-type; description Minaburo & Toutain Expires 12 April 2023 [Page 22] Internet-Draft LPWAN SCHC YANG module October 2022 "CoAP option if-none-match."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-observe { base fid-coap-base-type; description "CoAP option Observe."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-uri-port { base fid-coap-base-type; description "CoAP option Uri-Port."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-location-path { base fid-coap-base-type; description "CoAP option Location-Path."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-uri-path { base fid-coap-base-type; description "CoAP option Uri-Path."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-content-format { base fid-coap-base-type; description "CoAP option Content Format."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-max-age { base fid-coap-base-type; description Minaburo & Toutain Expires 12 April 2023 [Page 23] Internet-Draft LPWAN SCHC YANG module October 2022 "CoAP option Max-Age."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-uri-query { base fid-coap-base-type; description "CoAP option Uri-Query."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-accept { base fid-coap-base-type; description "CoAP option Accept."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-location-query { base fid-coap-base-type; description "CoAP option Location-Query."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-block2 { base fid-coap-base-type; description "CoAP option Block2."; reference "RFC 7959 Block-Wise Transfers in the Constrained Application Protocol (CoAP)"; } identity fid-coap-option-block1 { base fid-coap-base-type; description "CoAP option Block1."; reference "RFC 7959 Block-Wise Transfers in the Constrained Application Protocol (CoAP)"; } identity fid-coap-option-size2 { Minaburo & Toutain Expires 12 April 2023 [Page 24] Internet-Draft LPWAN SCHC YANG module October 2022 base fid-coap-base-type; description "CoAP option size2."; reference "RFC 7959 Block-Wise Transfers in the Constrained Application Protocol (CoAP)"; } identity fid-coap-option-proxy-uri { base fid-coap-base-type; description "CoAP option Proxy-Uri."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-proxy-scheme { base fid-coap-base-type; description "CoAP option Proxy-scheme."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-size1 { base fid-coap-base-type; description "CoAP option Size1."; reference "RFC 7252 The Constrained Application Protocol (CoAP)"; } identity fid-coap-option-no-response { base fid-coap-base-type; description "CoAP option No response."; reference "RFC 7967 Constrained Application Protocol (CoAP) Option for No Server Response"; } identity fid-oscore-base-type { base fid-coap-type; description "OSCORE options (RFC8613) split in sub options."; reference "RFC 8824 Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)"; Minaburo & Toutain Expires 12 April 2023 [Page 25] Internet-Draft LPWAN SCHC YANG module October 2022 } identity fid-coap-option-oscore-flags { base fid-oscore-base-type; description "CoAP option oscore flags."; reference "RFC 8824 Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) (see section 6.4)"; } identity fid-coap-option-oscore-piv { base fid-oscore-base-type; description "CoAP option oscore flags."; reference "RFC 8824 Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) (see section 6.4)"; } identity fid-coap-option-oscore-kid { base fid-oscore-base-type; description "CoAP option oscore flags."; reference "RFC 8824 Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) (see section 6.4)"; } identity fid-coap-option-oscore-kidctx { base fid-oscore-base-type; description "CoAP option oscore flags."; reference "RFC 8824 Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)(see section 6.4)"; } //---------------------------------- // Field Length type definition //---------------------------------- identity fl-base-type { description Minaburo & Toutain Expires 12 April 2023 [Page 26] Internet-Draft LPWAN SCHC YANG module October 2022 "Used to extend field length functions."; } identity fl-variable { base fl-base-type; description "Residue length in Byte is sent as defined for CoAP."; reference "RFC 8824 Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) (see section 5.3)"; } identity fl-token-length { base fl-base-type; description "Residue length in Byte is sent as defined for CoAP."; reference "RFC 8824 Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) (see section 4.5)"; } //--------------------------------- // Direction Indicator type //--------------------------------- identity di-base-type { description "Used to extend direction indicators."; } identity di-bidirectional { base di-base-type; description "Direction Indication of bidirectionality."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.1.)"; } identity di-up { base di-base-type; description "Direction Indication of uplink."; reference "RFC 8724 SCHC: Generic Framework for Static Context Minaburo & Toutain Expires 12 April 2023 [Page 27] Internet-Draft LPWAN SCHC YANG module October 2022 Header Compression and Fragmentation (see section 7.1)."; } identity di-down { base di-base-type; description "Direction Indication of downlink."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.1)."; } //---------------------------------- // Matching Operator type definition //---------------------------------- identity mo-base-type { description "Matching Operator: used in the rule selection process to check is a Target Value matches the field's value."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see* section 7.2)."; } identity mo-equal { base mo-base-type; description "equal MO."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.3)."; } identity mo-ignore { base mo-base-type; description "ignore MO."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.3)."; } Minaburo & Toutain Expires 12 April 2023 [Page 28] Internet-Draft LPWAN SCHC YANG module October 2022 identity mo-msb { base mo-base-type; description "MSB MO."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.3)."; } identity mo-match-mapping { base mo-base-type; description "match-mapping MO."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.3)."; } //------------------------------ // CDA type definition //------------------------------ identity cda-base-type { description "Compression Decompression Actions. Specify the action to be applied to the field's value in a specific rule."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.2)."; } identity cda-not-sent { base cda-base-type; description "not-sent CDA."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.4)."; } identity cda-value-sent { base cda-base-type; description "value-sent CDA."; Minaburo & Toutain Expires 12 April 2023 [Page 29] Internet-Draft LPWAN SCHC YANG module October 2022 reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.4)."; } identity cda-lsb { base cda-base-type; description "LSB CDA."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.4)."; } identity cda-mapping-sent { base cda-base-type; description "mapping-sent CDA."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.4)."; } identity cda-compute { base cda-base-type; description "compute-* CDA."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.4)."; } identity cda-deviid { base cda-base-type; description "DevIID CDA."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.4)."; } identity cda-appiid { base cda-base-type; Minaburo & Toutain Expires 12 April 2023 [Page 30] Internet-Draft LPWAN SCHC YANG module October 2022 description "AppIID CDA."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.4)."; } // -- type definition typedef fid-type { type identityref { base fid-base-type; } description "Field ID generic type."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } typedef fl-type { type union { type uint64 { range 1..max; } type identityref { base fl-base-type; } } description "Field length either a positive integer expressing the size in bits or a function defined through an identityref."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } typedef di-type { type identityref { base di-base-type; } description "Direction in LPWAN network, up when emitted by the device, down when received by the device, bi when emitted or received by the device."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Minaburo & Toutain Expires 12 April 2023 [Page 31] Internet-Draft LPWAN SCHC YANG module October 2022 Compression and Fragmentation"; } typedef mo-type { type identityref { base mo-base-type; } description "Matching Operator (MO) to compare fields values with target values."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } typedef cda-type { type identityref { base cda-base-type; } description "Compression Decompression Action to compression or decompress a field."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } // -- FRAGMENTATION TYPE // -- fragmentation modes identity fragmentation-mode-base-type { description "Define the fragmentation mode."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } identity fragmentation-mode-no-ack { base fragmentation-mode-base-type; description "No-ACK mode."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } identity fragmentation-mode-ack-always { Minaburo & Toutain Expires 12 April 2023 [Page 32] Internet-Draft LPWAN SCHC YANG module October 2022 base fragmentation-mode-base-type; description "ACK-Always mode."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } identity fragmentation-mode-ack-on-error { base fragmentation-mode-base-type; description "ACK-on-Error mode."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } typedef fragmentation-mode-type { type identityref { base fragmentation-mode-base-type; } description "Define the type used for fragmentation mode in rules."; } // -- Ack behavior identity ack-behavior-base-type { description "Define when to send an Acknowledgment ."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } identity ack-behavior-after-all-0 { base ack-behavior-base-type; description "Fragmentation expects Ack after sending All-0 fragment."; } identity ack-behavior-after-all-1 { base ack-behavior-base-type; description "Fragmentation expects Ack after sending All-1 fragment."; } identity ack-behavior-by-layer2 { Minaburo & Toutain Expires 12 April 2023 [Page 33] Internet-Draft LPWAN SCHC YANG module October 2022 base ack-behavior-base-type; description "Layer 2 defines when to send an Ack."; } typedef ack-behavior-type { type identityref { base ack-behavior-base-type; } description "Define the type used for Ack behavior in rules."; } // -- All-1 with data types identity all-1-data-base-type { description "Type to define when to send an Acknowledgment message."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } identity all-1-data-no { base all-1-data-base-type; description "All-1 contains no tiles."; } identity all-1-data-yes { base all-1-data-base-type; description "All-1 MUST contain a tile."; } identity all-1-data-sender-choice { base all-1-data-base-type; description "Fragmentation process chooses to send tiles or not in All-1."; } typedef all-1-data-type { type identityref { base all-1-data-base-type; } description "Define the type used for All-1 format in rules."; } Minaburo & Toutain Expires 12 April 2023 [Page 34] Internet-Draft LPWAN SCHC YANG module October 2022 // -- RCS algorithm types identity rcs-algorithm-base-type { description "Identify which algorithm is used to compute RCS. The algorithm also defines the size of the RCS field."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } identity rcs-crc32 { base rcs-algorithm-base-type; description "CRC 32 defined as default RCS in RFC8724. This RCS is 4 bytes long."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } typedef rcs-algorithm-type { type identityref { base rcs-algorithm-base-type; } description "Define the type for RCS algorithm in rules."; } // -------- RULE ENTRY DEFINITION ------------ grouping tv-struct { description "Defines the target value element. If the header field contains a text, the binary sequence uses the same encoding. field-id allows the conversion to the appropriate type."; leaf index { type uint16; description "Index gives the position in the matching-list. If only one element is present, index is 0. Otherwise, index is the the order in the matching list, starting at 0."; } leaf value { type binary; description "Target Value content as an untyped binary value."; } Minaburo & Toutain Expires 12 April 2023 [Page 35] Internet-Draft LPWAN SCHC YANG module October 2022 reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } grouping compression-rule-entry { description "These entries defines a compression entry (i.e. a line) as defined in RFC 8724. +-------+--+--+--+------------+-----------------+---------------+ |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act| +-------+--+--+--+------------+-----------------+---------------+ An entry in a compression rule is composed of 7 elements: - Field ID: The header field to be compressed. - Field Length : Either a positive integer of a function. - Field Position: A positive (and possibly equal to 0) integer. - Direction Indicator: An indication in which direction compression and decompression process is effective. - Target value: A value against which the header Field is compared. - Matching Operator: The comparison operation and optional associate parameters. - Comp./Decomp. Action: The compression or decompression action, and optional parameters. "; leaf field-id { type schc:fid-type; mandatory true; description "Field ID, identify a field in the header with a YANG identity reference."; } leaf field-length { type schc:fl-type; mandatory true; description "Field Length, expressed in number of bits if the length is known when the Rule is created or through a specific function if the length is variable."; } leaf field-position { type uint8; mandatory true; description "Field position in the header is an integer. Position 1 Minaburo & Toutain Expires 12 April 2023 [Page 36] Internet-Draft LPWAN SCHC YANG module October 2022 matches the first occurrence of a field in the header, while incremented position values match subsequent occurrences. Position 0 means that this entry matches a field irrespective of its position of occurrence in the header. Be aware that the decompressed header may have position-0 fields ordered differently than they appeared in the original packet."; } leaf direction-indicator { type schc:di-type; mandatory true; description "Direction Indicator, indicate if this field must be considered for rule selection or ignored based on the direction (bi directionnal, only uplink, or only downlink)."; } list target-value { key "index"; uses tv-struct; description "A list of value to compare with the header field value. If target value is a singleton, position must be 0. For use as a matching list for the mo-match-mapping matching operator, index should take consecutive values starting from 0."; } leaf matching-operator { type schc:mo-type; must "../target-value or derived-from-or-self(., 'mo-ignore')" { error-message "mo-equal, mo-msb and mo-match-mapping need target-value"; description "target-value is not required for mo-ignore."; } must "not (derived-from-or-self(., 'mo-msb')) or ../matching-operator-value" { error-message "mo-msb requires length value"; } mandatory true; description "MO: Matching Operator."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see Section 7.3)."; Minaburo & Toutain Expires 12 April 2023 [Page 37] Internet-Draft LPWAN SCHC YANG module October 2022 } list matching-operator-value { key "index"; uses tv-struct; description "Matching Operator Arguments, based on TV structure to allow several arguments. In RFC 8724, only the MSB matching operator needs arguments (a single argument, which is the number of most significant bits to be matched)."; } leaf comp-decomp-action { type schc:cda-type; must "../target-value or derived-from-or-self(., 'cda-value-sent') or derived-from-or-self(., 'cda-compute') or derived-from-or-self(., 'cda-appiid') or derived-from-or-self(., 'cda-deviid')" { error-message "cda-not-sent, cda-lsb, cda-mapping-sent need target-value"; description "target-value is not required for some CDA."; } mandatory true; description "CDA: Compression Decompression Action."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 7.4)"; } list comp-decomp-action-value { key "index"; uses tv-struct; description "CDA arguments, based on a TV structure, in order to allow for several arguments. The CDAs specified in RFC 8724 require no argument."; } } // --Rule nature identity nature-base-type { description "A rule, identified by its RuleID, are used for a single purpose. RFC 8724 defines 2 natures: Minaburo & Toutain Expires 12 April 2023 [Page 38] Internet-Draft LPWAN SCHC YANG module October 2022 compression, no compression and fragmentation."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 6)."; } identity nature-compression { base nature-base-type; description "Identify a compression rule."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 6)."; } identity nature-no-compression { base nature-base-type; description "Identify a no compression rule."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 6)."; } identity nature-fragmentation { base nature-base-type; description "Identify a fragmentation rule."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation (see section 6)."; } typedef nature-type { type identityref { base nature-base-type; } description "defines the type to indicate the nature of the rule."; } grouping compression-content { list entry { must "derived-from-or-self(../rule-nature, 'nature-compression')" { error-message "Rule nature must be compression"; } key "field-id field-position direction-indicator"; Minaburo & Toutain Expires 12 April 2023 [Page 39] Internet-Draft LPWAN SCHC YANG module October 2022 uses compression-rule-entry; description "A compression rule is a list of rule entries, each describing a header field. An entry is identified through a field-id, its position in the packet, and its direction."; } description "Define a compression rule composed of a list of entries."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } grouping fragmentation-content { description "This grouping defines the fragmentation parameters for all the modes (No-ACK, ACK-Always and ACK-on-Error) specified in RFC 8724."; leaf fragmentation-mode { type schc:fragmentation-mode-type; must "derived-from-or-self(../rule-nature, 'nature-fragmentation')" { error-message "Rule nature must be fragmentation"; } mandatory true; description "Which fragmentation mode is used (No-Ack, ACK-Always, ACK-on-Error)."; } leaf l2-word-size { type uint8; default "8"; description "Size, in bits, of the layer 2 word."; } leaf direction { type schc:di-type; must "derived-from-or-self(., 'di-up') or derived-from-or-self(., 'di-down')" { error-message "Direction for fragmentation rules are up or down."; } mandatory true; description "MUST be up or down, bidirectional MUST NOT be used."; } // SCHC Frag header format Minaburo & Toutain Expires 12 April 2023 [Page 40] Internet-Draft LPWAN SCHC YANG module October 2022 leaf dtag-size { type uint8; default "0"; description "Size, in bits, of the DTag field (T variable from RFC8724)."; } leaf w-size { when "derived-from-or-self(../fragmentation-mode, 'fragmentation-mode-ack-on-error') or derived-from-or-self(../fragmentation-mode, 'fragmentation-mode-ack-always') "; type uint8; description "Size, in bits, of the window field (M variable from RFC8724)."; } leaf fcn-size { type uint8; mandatory true; description "Size, in bits, of the FCN field (N variable from RFC8724)."; } leaf rcs-algorithm { type rcs-algorithm-type; default "schc:rcs-crc32"; description "Algorithm used for RCS. The algorithm specifies the RCS size."; } // SCHC fragmentation protocol parameters leaf maximum-packet-size { type uint16; default "1280"; description "When decompression is done, packet size must not strictly exceed this limit, expressed in bytes."; } leaf window-size { type uint16; description "By default, if not specified 2^w-size - 1. Should not exceed this value. Possible FCN values are between 0 and window-size - 1."; } leaf max-interleaved-frames { type uint8; Minaburo & Toutain Expires 12 April 2023 [Page 41] Internet-Draft LPWAN SCHC YANG module October 2022 default "1"; description "Maximum of simultaneously fragmented frames. Maximum value is 2^dtag-size. All DTAG values can be used, but more than max-interleaved-frames MUST NOT be active at any time"; } container inactivity-timer { leaf ticks-duration { type uint8; default "20"; description "Duration of one tick in micro-seconds: 2^ticks-duration/10^6 = 1.048s."; } leaf ticks-numbers { type uint16 { range "0..max"; } description "Timer duration = ticks-numbers*2^ticks-duration / 10^6."; } description "Duration is seconds of the inactivity timer, 0 indicates that the timer is disabled. Allows a precision from micro-second to year by sending the tick-duration value. For instance: tick-duration / smallest value highest value v 20: 00y 000d 00h 00m 01s.048575<->00y 000d 19h 05m 18s.428159 21: 00y 000d 00h 00m 02s.097151<->00y 001d 14h 10m 36s.856319 22: 00y 000d 00h 00m 04s.194303<->00y 003d 04h 21m 13s.712639 23: 00y 000d 00h 00m 08s.388607<->00y 006d 08h 42m 27s.425279 24: 00y 000d 00h 00m 16s.777215<->00y 012d 17h 24m 54s.850559 25: 00y 000d 00h 00m 33s.554431<->00y 025d 10h 49m 49s.701119 Note that the smallest value is also the incrementation step, so the timer precision."; } container retransmission-timer { leaf ticks-duration { type uint8; default "20"; description "Duration of one tick in micro-seconds: 2^ticks-duration/10^6 = 1.048s."; Minaburo & Toutain Expires 12 April 2023 [Page 42] Internet-Draft LPWAN SCHC YANG module October 2022 } leaf ticks-numbers { type uint16 { range "1..max"; } description "Timer duration = ticks-numbers*2^ticks-duration / 10^6."; } when "derived-from-or-self(../fragmentation-mode, 'fragmentation-mode-ack-on-error') or derived-from-or-self(../fragmentation-mode, 'fragmentation-mode-ack-always') "; description "Duration in seconds of the retransmission timer. See inactivity timer."; } leaf max-ack-requests { when "derived-from-or-self(../fragmentation-mode, 'fragmentation-mode-ack-on-error') or derived-from-or-self(../fragmentation-mode, 'fragmentation-mode-ack-always') "; type uint8 { range "1..max"; } description "The maximum number of retries for a specific SCHC ACK."; } choice mode { case no-ack; case ack-always; case ack-on-error { leaf tile-size { when "derived-from-or-self(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; type uint8; description "Size, in bits, of tiles. If not specified or set to 0, tiles fill the fragment."; } leaf tile-in-all-1 { when "derived-from-or-self(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; type schc:all-1-data-type; description "Defines whether the sender and receiver expect a tile in Minaburo & Toutain Expires 12 April 2023 [Page 43] Internet-Draft LPWAN SCHC YANG module October 2022 All-1 fragments or not, or if it is left to the sender's choice."; } leaf ack-behavior { when "derived-from-or-self(../fragmentation-mode, 'fragmentation-mode-ack-on-error')"; type schc:ack-behavior-type; description "Sender behavior to acknowledge, after All-0, All-1 or when the LPWAN allows it."; } } description "RFC 8724 defines 3 fragmentation modes."; } reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } // Define rule ID. Rule ID is composed of a RuleID value and a // Rule ID Length grouping rule-id-type { leaf rule-id-value { type uint32; description "Rule ID value, this value must be unique, considering its length."; } leaf rule-id-length { type uint8 { range "0..32"; } description "Rule ID length, in bits. The value 0 is for implicit rules."; } description "A rule ID is composed of a value and a length, expressed in bits."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } // SCHC table for a specific device. Minaburo & Toutain Expires 12 April 2023 [Page 44] Internet-Draft LPWAN SCHC YANG module October 2022 container schc { list rule { key "rule-id-value rule-id-length"; uses rule-id-type; leaf rule-nature { type nature-type; mandatory true; description "Specify the rule's nature."; } choice nature { case fragmentation { if-feature "fragmentation"; uses fragmentation-content; } case compression { if-feature "compression"; uses compression-content; } description "A rule is for compression, for no-compression or for fragmentation."; } description "Set of rules compression, no compression or fragmentation rules identified by their rule-id."; } description "A SCHC set of rules is composed of a list of rules which are used for compression, no-compression or fragmentation."; reference "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation"; } } Figure 6 7. Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort Minaburo & Toutain Expires 12 April 2023 [Page 45] Internet-Draft LPWAN SCHC YANG module October 2022 has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". * Openschc is implementing the conversion between the local rule representation and the representation conforming to the data model in JSON and CBOR (following -08 draft). 8. IANA Considerations This document registers one URI and one YANG modules. 8.1. URI Registration This document requests IANA to register the following URI in the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-schc Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. 8.2. YANG Module Name Registration This document registers the following one YANG modules in the "YANG Module Names" registry [RFC6020]. name: ietf-schc namespace: urn:ietf:params:xml:ns:yang:ietf-schc prefix: schc reference: RFC XXXX Data Model for Static Context Header Compression (SCHC) Minaburo & Toutain Expires 12 April 2023 [Page 46] Internet-Draft LPWAN SCHC YANG module October 2022 9. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This data model formalizes the rules elements described in [RFC8724] for compression, and fragmentation. As explained in the architecture document [I-D.ietf-lpwan-architecture], a rule can be read, created, updated or deleted in response to a management request. These actions can be done between two instances of SCHC or between a SCHC instance and a rule repository. create (-------) read +=======+ * ( rules )<------->|Rule |<--|--------> (-------) update |Manager| NETCONF, RESTCONF,... . read delete +=======+ request . +-------+ <===| R & D |<=== ===>| C & F |===> +-------+ The rule contains sensitive information such as the application IPv6 address where the device's data will be sent after decompression. A device may try to modify other devices' rules by changing the application address and may block communication or allows traffic eavesdropping. Therefore, a device must be allowed to modify only its own rules on the remote SCHC instance. The identity of the requester must be validated. This can be done through certificates or access lists. By reading a module, an attacker may know the traffic a device can generate and learn about application addresses or REST API. The full tree is sensitive, since it represents all the elements that can be managed. This module aims to be encapsulated into a YANG module including access controls and identities. Minaburo & Toutain Expires 12 April 2023 [Page 47] Internet-Draft LPWAN SCHC YANG module October 2022 10. Annex A : Example The informal rules given Figure 7 will represented in XML as shown in Figure 8. /-------------------------\ |Rule 6/3 110 | |---------------+---+--+--+----------------+-------+----------------\ |IPV6.VER | 4| 1|BI| 6|EQUAL |NOT-SENT | |IPV6.TC | 8| 1|BI| 0|EQUAL |NOT-SENT | |IPV6.FL | 20| 1|BI| 0|IGNORE |NOT-SENT | |IPV6.LEN | 16| 1|BI| |IGNORE |COMPUTE-LENGTH | |IPV6.NXT | 8| 1|BI| 58|EQUAL |NOT-SENT | |IPV6.HOP_LMT | 8| 1|BI| 255|IGNORE |NOT-SENT | |IPV6.DEV_PREFIX| 64| 1|BI|200104701f2101d2|EQUAL |NOT-SENT | |IPV6.DEV_IID | 64| 1|BI|0000000000000003|EQUAL |NOT-SENT | |IPV6.APP_PREFIX| 64| 1|BI| |IGNORE |VALUE-SENT | |IPV6.APP_IID | 64| 1|BI| |IGNORE |VALUE-SENT | \---------------+---+--+--+----------------+-------+----------------/ /-------------------------\ |Rule 12/11 00001100 | !=========================+=========================================\ !^ Fragmentation mode : NoAck header dtag 2 Window 0 FCN 3 UP ^! !^ No Tile size specified ^! !^ RCS Algorithm: RCS_CRC32 ^! \===================================================================/ /-------------------------\ |Rule 100/8 01100100 | | NO COMPRESSION RULE | \-------------------------/ Figure 7: Rules example 6 3 nature-compression fid-ipv6-version 4 1 di-bidirectional mo-equal cda-not-sent 0 Minaburo & Toutain Expires 12 April 2023 [Page 48] Internet-Draft LPWAN SCHC YANG module October 2022 AAY= fid-ipv6-trafficclass 8 1 di-bidirectional mo-equal cda-not-sent 0 AA== fid-ipv6-flowlabel 20 1 di-bidirectional mo-ignore cda-not-sent 0 AA== fid-ipv6-payload-length 16 1 di-bidirectional mo-ignore cda-compute fid-ipv6-nextheader 8 1 di-bidirectional mo-equal cda-not-sent 0 ADo= Minaburo & Toutain Expires 12 April 2023 [Page 49] Internet-Draft LPWAN SCHC YANG module October 2022 fid-ipv6-hoplimit 8 1 di-bidirectional mo-ignore cda-not-sent 0 AP8= fid-ipv6-devprefix 64 1 di-bidirectional mo-equal cda-not-sent 0 IAEEcB8hAdI= fid-ipv6-deviid 64 1 di-bidirectional mo-equal cda-not-sent 0 AAAAAAAAAAM= fid-ipv6-appprefix 64 1 di-bidirectional mo-ignore cda-value-sent fid-ipv6-appiid 64 1 di-bidirectional Minaburo & Toutain Expires 12 April 2023 [Page 50] Internet-Draft LPWAN SCHC YANG module October 2022 mo-ignore cda-value-sent 12 11 nature-fragmentation di-up rcs-crc32 2 3 fragmentation-mode-no-ack 100 8 nature-no-compression Figure 8: XML representation of the rules. 11. Acknowledgements The authors would like to thank Dominique Barthel, Carsten Bormann, Ivan Martinez, Alexander Pelov for their careful reading and valuable inputs. A special thanks for Joe Clarke, Carl Moberg, Tom Petch, Martin Thomson, and Eric Vyncke for their explanations and wise advices when building the model. 12. References 12.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . Minaburo & Toutain Expires 12 April 2023 [Page 51] Internet-Draft LPWAN SCHC YANG module October 2022 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . Minaburo & Toutain Expires 12 April 2023 [Page 52] Internet-Draft LPWAN SCHC YANG module October 2022 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, . [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", RFC 8824, DOI 10.17487/RFC8824, June 2021, . 12.2. Informative References [I-D.ietf-lpwan-architecture] Pelov, A., Thubert, P., and A. Minaburo, "LPWAN Static Context Header Compression (SCHC) Architecture", Work in Progress, Internet-Draft, draft-ietf-lpwan-architecture- 02, 30 June 2022, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. Bose, "Constrained Application Protocol (CoAP) Option for No Server Response", RFC 7967, DOI 10.17487/RFC7967, August 2016, . [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, . Minaburo & Toutain Expires 12 April 2023 [Page 53] Internet-Draft LPWAN SCHC YANG module October 2022 [RFC9011] Gimenez, O., Ed. and I. Petrov, Ed., "Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN", RFC 9011, DOI 10.17487/RFC9011, April 2021, . Authors' Addresses Ana Minaburo Acklio 1137A avenue des Champs Blancs 35510 Cesson-Sevigne Cedex France Email: ana@ackl.io Laurent Toutain Institut MINES TELECOM; IMT Atlantique 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Email: Laurent.Toutain@imt-atlantique.fr Minaburo & Toutain Expires 12 April 2023 [Page 54] ./draft-ietf-ecrit-similar-location-19.txt0000644000764400076440000011446614210515726020247 0ustar iustiniustin ECRIT B. Rosen Internet-Draft Updates: 5222 (if approved) R. Marshall Intended status: Standards Track J. Martin Expires: 5 September 2022 Comtech TCS 4 March 2022 A LoST extension to return complete and similar location info draft-ietf-ecrit-similar-location-19 Abstract This document describes an extension to the LoST protocol of RFC 5222 that allows additional civic location information to be returned in a . This extension supports two use cases: First, when the input location is valid but lacks some Civic Address elements, the LoST server can provide a completed form. Second, when the input location is invalid, the LoST server can identify one or more feasible ("similar") locations. This extension is applicable when the location information in the request uses the Basic Civic profile as described in RFC 5222 or another profile whose definition provides instructions concerning its use with this extension. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 September 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Rosen, et al. Expires 5 September 2022 [Page 1] Internet-Draft Returned Location Extensions to LoST March 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Returned Location Information . . . . . . . . . . 4 4. Returned Location Information . . . . . . . . . . . . . . . . 8 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Complete Location returned for Valid Location . . . . . . 10 5.2. Similar Location returned for Invalid Location . . . . . 12 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8.1. XML Schema Registration . . . . . . . . . . . . . . . . . 16 8.2. LoST-RLI Namespace Registration . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The LoST protocol [RFC5222] supports the validation of civic location information sent in a request, by providing a set of validation result status indicators in the response. The current usefulness of the supported XML elements , , and is limited. They each provide an indication of validity for any one location element as a part of the whole civic address, but this is insufficient in providing either the complete set of civic address elements that the LoST server contains, or of providing alternate suggestions (hints) as to which civic address is intended for use. Whether the queried civic location is valid but missing information, or invalid due to missing or wrong information, this document provides a mechanism to return a complete set of civic address elements. Rosen, et al. Expires 5 September 2022 [Page 2] Internet-Draft Returned Location Extensions to LoST March 2022 This enhancement to the validation feature within LoST is required by systems that rely on accurate location for processing. Use of this enhancement increases the likelihood that incorrect or incomplete civic location will be updated. One such use case is that of location-based emergency calling. The use of this protocol extension facilitates the timely correction of errors, and allows LoST clients to be more easily provisioned with complete address information. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terms are defined in this document: Location: The term Location is in general used to refer to either a civic location or a geodetic location. In the context of this document, location is restricted to civic locations. Geodetic Location: a geographic coordinate set of values that describes a point within a defined geographic datum. For example, a referenced latitude/longitude coordinate pair (2D), or latitude, longitude, and altitude (3D). Note: geodetic location is defined here for context, but is not used elsewhere within this document. Civic Location: A set of Civic Address Elements as defined in [RFC5139] that are used in conjunction with each other, and in accordance with a known ruleset to designate a specific place within a country. Civic Address: The term Civic Address is used interchangeably with the term Civic Location within this document. Civic Address Element: The term Civic Address Element is used within this document to indicate any individual XML element used within the type defined in [RFC5139], including elements used at the extension point therein such as those defined in [RFC6848] and elsewhere. This term also includes the reference to such elements by qualified name as defined within the element in [RFC5222]. Invalid Location: A Civic Location that, when included in a LoST query with 'validateLocation' set, will receive a response having one or more Civic Address Elements in the list. Note that it is also possible that the location information submitted Rosen, et al. Expires 5 September 2022 [Page 3] Internet-Draft Returned Location Extensions to LoST March 2022 is so inaccurate that location validation cannot be performed, and the LoST server may return a or error. In this document, the term Invalid Location only refers to a case where the LoST server returns one or more elements in the list; the error conditions are not considered. Valid Location: A Civic Location that, when included in a LoST query with 'validateLocation' set, will receive a response having all Civic Address Elements in the or lists. Incomplete Location: "A Civic Location that the LoST server considers valid but which omits one or more Civic Address Elements that the LoST server considers necessary or helpful. Complete Location: A Civic Location that was considered by the LoST server to be an Incomplete Location but that with the addition of one or more Civic Address Elements is considered complete by the LoST server. Similar Location: A suggested civic location that is similar to an Invalid Location which was used in a LoST query, but which has one or more elements added, modified, or removed such that the suggested location is a Valid Location. Similar Location may be returned when the input location is invalid. Returned Location Information: A set of civic locations returned in a LoST response. 3. Overview of Returned Location Information This document describes an extension to LoST [RFC5222] that allows additional location information to be returned in the element of a . This extension has two different use cases: First, when the input location is incomplete but the LoST server can identify the intended unique address, and second, when the input location is invalid and the LoST server can identify one or more likely intended locations. This extension is applicable when the location information in the request is in the Basic Civic profile as described in [RFC5222] or in another profile whose definition provides instructions concerning its use with this extension. As of this document's publication, no such additional location profiles have been defined, so this document describes the returned location extension using the Basic Civic profile. In addition, the following restriction is imposed: A server MUST NOT include Returned Location Information using a location profile that differs from the profile of the location used to answer the query and, by extension, MUST NOT include Returned Location Information using a location profile that Rosen, et al. Expires 5 September 2022 [Page 4] Internet-Draft Returned Location Extensions to LoST March 2022 was not used by the client in the request. When a LoST server is asked to validate a civic location, its goal is to take the set of Civic Address Elements provided as the location information in the LoST request, and find a unique location in its database that matches the information in the request. Uniqueness might not require values for all possible elements in the Civic Address that the database might hold. Further, the input location information might not represent the form of location the users of the LoST service prefer to have. As an example, there are LoST Civic Address Elements that could be used to define a postal location, suitable for delivery of mail as well as a municipal location suitable for responding to an emergency call. While the LoST server might be able to determine the location from the postal elements provided, the emergency services would prefer that the municipal location be used for any subsequent emergency call. Since validation is often performed well in advance of an end user placing an emergency call, if the LoST server could return the preferred form of location (or more properly in this example, the municipal elements in addition to the postal elements), those elements could be stored in a client application such as a Location Information Server (LIS) and used in a later emergency call. In addition, this document describes the reuse of the same mechanism, but for a different purpose: to supply similar location information in the case where a LoST server response includes one or more Civic Address Elements marked as invalid, indicating an Invalid Location used in the query. In this case, the response contains one or more suggested alternative Valid Locations. In a LoST indicating a Valid Location (Section 2) i.e., containing the element with no elements listed as invalid, the LoST server can use this extension to include additional location information in a element. As an example, a query contains (house number), (road name) (city), (state/province) but not (Post- Directional). In this example, there is no street with just the street name, all streets have a post-directional. However, the LoST server is able to uniquely locate the intended address and thus consider the queried location Valid, as there is only one street with the street name and house number in the city that it could be. As the queried location is missing the post-directional element, a more strict entity might consider it Invalid (e.g., during a subsequent query) or worse, the lack of a Post-Directional element might cause confusion and delay an emergency response. The server can use this extension to supply the missing post-directional element in a element within the element. Rosen, et al. Expires 5 September 2022 [Page 5] Internet-Draft Returned Location Extensions to LoST March 2022 In another example, the civic location in a request might lack (county) and (Postal Code) Civic Address Elements. In this example, too, the LoST server is able to uniquely locate the intended address and consider the location , but other entities involved in a subsequent emergency call might find it helpful to have the additional Civic Address Elements. The LoST server can use this extension to supply the missing and Civic Address Elements. Since [RFC5222] does not have a way for this additional location information to be returned in the , this document extends the LoST protocol so that it can include a element within the element of the message, allowing for the representation of complete location information. An example showing complete location information supplied: Input address: 6000 15th Avenue Leets, WA US Complete Location: 6000 15th Avenue Northwest Leets, WA 98105 US The information provided in the request may be enough to identify a unique location in the LoST server, but that may not be the location intended by the end user. The information may alert the user to a mismatch between the provided location information and the unique location the server interpreted that information to identify. The other use case for this extension is when the request contains an Invalid Location. When a LoST server returns a response to a request that contains a set of Civic Address Elements with one or more listed as invalid, this extension allows the server to include in the element one or more locations that might be the intended location. Rosen, et al. Expires 5 September 2022 [Page 6] Internet-Draft Returned Location Extensions to LoST March 2022 In the example cited above, policy at the LoST server might deem a missing element as being invalid, even if the location information in the request is sufficient to identify a unique address. In this case, the missing element is listed in the list, and a element could be returned in the response showing a complete civic location that includes the missing element, just as in the above example the missing element is included in a element. As another example of the use of , consider the results based on a similar data set as used above, but where the , , , , and Civic Address Elements are not sufficient to locate a unique address, resulting in an invalid location response. Because the LoST server contains additional civic address elements which, had they been included in the query, would have resulted in a uniquely identifiable location, the server can include one or more elements containing the supplied Civic Address Elements plus the omitted ones. Since [RFC5222] does not have a way for this additional location information to be returned in the , this document extends [RFC5222] so that the LoST element of the can include one or more elements representing similar civic locations. To show this, suppose that a slightly modified version of the above address is sent within a Lost request: Input address: 6000 15th Avenue North Leets, WA US This time we make the assumption that the address is deemed invalid by the LoST server because there is no such thing as "15th Avenue North" within the LoST server's data for the city of Leets. However, we also happen to know for this example that there are two addresses within the address dataset that are "similar", when all parts of the address are taken as a whole. These similar addresses that could be returned to the client are as follows: Similar address #1: 6000 15th Avenue Northwest Leets, WA 98107 US Similar address #2: 6000 15th Avenue Northeast Rosen, et al. Expires 5 September 2022 [Page 7] Internet-Draft Returned Location Extensions to LoST March 2022 Leets, WA 98105 US This extension allows the LoST server to include the above similar addresses in the response to a request with 'validateLocaton' set to true. Section 5 shows examples of the LoST request and response XML message fragments for the above valid and invalid scenarios, returning the complete or similar addresses respectively. 4. Returned Location Information A LoST server implementing this extension MAY include or elements within the portion of the . The and elements are of type "locationInformation" as defined by the LoST schema in [RFC5222]. These elements MAY contain location information either in the Basic Civic profile defined in [RFC5222] or in another profile whose definition provides instructions concerning its use with this extension; this MUST be the same profile as the location in the query. When used with the Basic Civic profile, these elements contain a element as defined in [RFC5139]. If there is at least one Civic Address Element in the list, the LoST server MAY include one or more element in the response. If there are too many possible locations, the server MAY return none, or it MAY return a subset considered most likely. How many to return is left to the implementation of the LoST server. The server is unable to know what the intended location information was supposed to be; it is guessing. Therefore, the correct location may or may not be one of the elements the server provides, and the client cannot assume that any one of them is the correct location. Rosen, et al. Expires 5 September 2022 [Page 8] Internet-Draft Returned Location Extensions to LoST March 2022 Where a LoST server contains additional location information relating to the Civic Address used in a request, the message MAY include a element containing additional location information along with the original validated Civic Address Elements; the additional Civic Address Elements may be deemed by local policy as necessary to form a Complete Location. The element MUST NOT be returned in response messages where any Civic Address Elements occur in the invalid list of the response, or where the set of Civic Address Elements in the request do not identify a unique location. The Complete Location MUST NOT contain any elements that would be marked as invalid, or cause an error, if a recipient of that location performs a subsequent request using the Complete Location. However, if a subsequent request includes the Complete Location, the corresponding response MAY include elements in the unchecked list. Clients can control the return of additional location information by including the optional 'returnAdditionalLocation' attribute with possible values 'none', 'similar', 'complete' or 'any'. The value 'none' means to not return additional location information, 'similar' and 'complete' mean to only return the respective type of additional location information (if the server could send any) and 'any' means to include Similar and/or Complete Location (if the server could send any). If the request includes this attribute, the server MUST NOT send location information contravening the client's request. Omitting this attribute in the request is equivalent to including it with the value 'none'. The server may determine that there are many possible Similar Locations and decide not to send them all. The number of Similar Locations sent is entirely up to the server. The server MAY include a 'similarLocationsOmitted' attribute which contains a non-zero integer indicating the minimum number of Similar Locations not included in the response. There may be more than the indicated similar locations available in the data held by the server, but no mechanism to request more Similar Locations is provided. Clients MAY ignore the location information this extension defines. The information is optional to send, and optional to use. In the case where the location information in the request was valid, this extension does not change the validity. In the case where the location information in the request is invalid, but alternate location information is returned, the original location remains invalid, and the LoST server does not change the mapping response other than optionally including the information defined by this extension. Rosen, et al. Expires 5 September 2022 [Page 9] Internet-Draft Returned Location Extensions to LoST March 2022 The and elements use the element from [RFC5222] updated by [I-D.ietf-ecrit-lost-planned-changes], including the 'profile' attribute, which is useful if the request contains location information in a profile other than the 'civic' profile. The 'profile' attribute MUST be included in both the request and the response and MUST be the same profile in both. 5. Examples 5.1. Complete Location returned for Valid Location This example is based on the example request above; the LoST server considered the location in the query to be valid but missing some Civic Address elements, so in the Returned Location Information in the , the server includes a element supplying the omitted Civic Address elements , , and . US WA Leets 15th Avenue Northwest 6000 urn:service:sos Rosen, et al. Expires 5 September 2022 [Page 10] Internet-Draft Returned Location Extensions to LoST March 2022 Leets 911 urn:service:sos sip:leets-911@example.com 911 ca:country ca:A1 ca:A3 ca:RD ca:STS ca:POD ca:HNO US WA SHOWAK COUNTY LEETS 15TH AVENUE NORTHWEST 6000 98106 LEETS Rosen, et al. Expires 5 September 2022 [Page 11] Internet-Draft Returned Location Extensions to LoST March 2022 5.2. Similar Location returned for Invalid Location The following example shows two Similar Locations returned in a message when the original input address is considered invalid, in this example because the LoST server needed the omitted POD data to match a unique address. AU QLD PIMPANA SHIRLEY STREET 98 4209 PIMPANA urn:service:sos Rosen, et al. Expires 5 September 2022 [Page 12] Internet-Draft Returned Location Extensions to LoST March 2022 Australian 000 urn:service:sos sip:000@example.com 000 ca:country ca:A1 ca:A3 ca:STS ca:RD ca:POD ca:HNO ca:PC ca:PCN AU QLD PIMPANA SHIRLEY STREET NORTH 98 4209 PIMPANAS AU QLD PIMPANA SHIRLEY STREET SOUTH 98 4209 PIMPANAS Rosen, et al. Expires 5 September 2022 [Page 13] Internet-Draft Returned Location Extensions to LoST March 2022 6. XML Schema This section provides the schema of the LoST extensions, based on the schema in [I-D.ietf-ecrit-lost-planned-changes] Rosen, et al. Expires 5 September 2022 [Page 14] Internet-Draft Returned Location Extensions to LoST March 2022 Rosen, et al. Expires 5 September 2022 [Page 15] Internet-Draft Returned Location Extensions to LoST March 2022 7. Security Considerations As this document defines extensions to [RFC5222], the Security Considerations of that document apply here. Whether the input to the LoST server is a Valid or Invalid Location, the LoST server ultimately determines what it considers to be a Valid Location. Even in the case where the input location is valid, the requester still might not actually understand where that location is. For this kind of Valid Location use case, this extension will typically return more location information than what the requester started with, which might reveal to the requester additional information (additional CAtypes) about the location. While this is very desirable in some scenarios such as supporting an emergency call, it might not be as desirable for other services. Individual LoST server implementations should consider the risk of releasing more detail versus the value in doing so. Generally, supplying more information (CAtypes) is not considered to be a significant problem because the requester has to already have enough information for the location to be considered valid, which in most cases is enough to uniquely locate the address. Providing more CAtypes generally doesn't actually reveal anything more. When Invalid Locations are submitted, this extension allows the LoST response to include locations that are similar to what was input, again resulting in more information provided in the response than was sent in the request. LoST server implementations should evaluate the particular use cases where this extension is supported, and weigh the risks around its use. Many services available today via the Internet offer similar features, such as "did you mean" or address completion, so this capability is not introducing any fundamentally new security concern. The similar location service could be misused to attempt to enumerate the entire database by running a high volume of invalid or partial queries. The LoST server can limit the volume of similar locations it returns. It can also authenticate queries and limit the service to known queriers 8. IANA Considerations 8.1. XML Schema Registration IANA is requested to register the following in the "schema" sub- registry of the IETF XML Registry per [RFC3688]. Rosen, et al. Expires 5 September 2022 [Page 16] Internet-Draft Returned Location Extensions to LoST March 2022 URI: urn:ietf:params:xml:schema:lost-rli1 Registrant Contact: IETF ECRIT Working Group, Brian Rosen (br@brianrosen.net). XML Schema: The XML schema to be registered is contained in Section 6. 8.2. LoST-RLI Namespace Registration IANA is requested to register the following in the "ns" sub-registry of the IETF XML registry per [RFC3553]. URI: urn:ietf:params:xml:ns:lost-rli1 Registrant Contact: IETF ECRIT Working Group, Brian Rosen (br@brianrosen.net). XML: BEGIN LoST Returned Location Information Namespace

Namespace for LoST Returned Location Information extension

urn:ietf:params:xml:ns:lost-rli1

See RFC????.

END 9. References 9.1. Normative References Rosen, et al. Expires 5 September 2022 [Page 17] Internet-Draft Returned Location Extensions to LoST March 2022 [I-D.ietf-ecrit-lost-planned-changes] Rosen, B., "Validation of Locations Around a Planned Change", Work in Progress, Internet-Draft, draft-ietf- ecrit-lost-planned-changes-05, 11 October 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139, February 2008, . [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and R. George, "Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF- LO)", RFC 6848, DOI 10.17487/RFC6848, January 2013, . Authors' Addresses Rosen, et al. Expires 5 September 2022 [Page 18] Internet-Draft Returned Location Extensions to LoST March 2022 Brian Rosen 470 Conrad Dr Mars, PA 16046 United States of America Email: br@brianrosen.net Roger Marshall Comtech TCS 2401 Elliott Avenue 2nd Floor Seattle, WA 98121 United States of America Email: roger.marshall@comtechtel.com Jeff Martin Comtech TCS 2401 Elliott Avenue 2nd Floor Seattle, WA 98121 United States of America Email: jeff.martin@comtechtel.com Rosen, et al. Expires 5 September 2022 [Page 19] ./draft-ietf-rats-yang-tpm-charra-21.txt0000644000764400076440000033310614241177604017624 0ustar iustiniustin RATS Working Group H. Birkholz Internet-Draft M. Eckel Intended status: Standards Track Fraunhofer SIT Expires: 19 November 2022 S. Bhandari ThoughtSpot E. Voit B. Sulzen Cisco L. Xia Huawei T. Laffey HPE G. Fedorkow Juniper 18 May 2022 A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs draft-ietf-rats-yang-tpm-charra-21 Abstract This document defines YANG RPCs and a few configuration nodes required to retrieve attestation evidence about integrity measurements from a device, following the operational context defined in TPM-based Network Device Remote Integrity Verification. Complementary measurement logs are also provided by the YANG RPCs, originating from one or more roots of trust for measurement (RTMs). The module defined requires at least one TPM 1.2 or TPM 2.0 as well as a corresponding TPM Software Stack (TSS), or equivalent hardware implementations that include the protected capabilities as provided by TPMs as well as a corresponding software stack, included in the device components of the composite device the YANG server is running on. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Birkholz, et al. Expires 19 November 2022 [Page 1] Internet-Draft YANG-CHARRA for TPMs May 2022 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 19 November 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. The YANG Module for Basic Remote Attestation Procedures . . . 3 2.1. YANG Modules . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. 'ietf-tpm-remote-attestation' . . . . . . . . . . . . 4 2.1.2. 'ietf-tcg-algs' . . . . . . . . . . . . . . . . . . . 33 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 4. Security Considerations . . . . . . . . . . . . . . . . . . . 49 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.1. Normative References . . . . . . . . . . . . . . . . . . 51 5.2. Informative References . . . . . . . . . . . . . . . . . 56 Appendix A. Integrity Measurement Architecture (IMA) . . . . . . 56 Appendix B. IMA for Network Equipment Boot Logs . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 1. Introduction This document is based on the general terminology defined in the [I-D.ietf-rats-architecture] and uses the operational context defined in [I-D.ietf-rats-tpm-based-network-device-attest] as well as the interaction model and information elements defined in [I-D.ietf-rats-reference-interaction-models]. The currently supported hardware security modules (HSMs) are the Trusted Platform Modules (TPMs) [TPM1.2] and [TPM2.0] as specified by the Trusted Computing Group (TCG). One TPM, or multiple TPMs in the case of a Birkholz, et al. Expires 19 November 2022 [Page 2] Internet-Draft YANG-CHARRA for TPMs May 2022 Composite Device, are required in order to use the YANG module defined in this document. Each TPM is used as a root of trust for storage (RTS) in order to store system security measurement Evidence. And each TPM is used as a root of trust for reporting (RTR) in order to retrieve attestation Evidence. This is done by using a YANG RPC to request a quote which exposes a rolling hash of the security measurements held internally within the TPM. Specific terms imported from [I-D.ietf-rats-architecture] and used in this document include: Attester, Composite Device, Evidence. Specific terms imported from [TPM2.0-Key] and used in this document include: Endorsement Key (EK), Initial Attestation Key (IAK), Attestation Identity Key (AIK), Local Attestation Key (LAK). 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. The YANG Module for Basic Remote Attestation Procedures One or more TPMs MUST be embedded in a Composite Device that provides attestation evidence via the YANG module defined in this document. The ietf-tpm-remote-attestation YANG module enables a composite device to take on the role of an Attester, in accordance with the Remote Attestation Procedures (RATS) architecture [I-D.ietf-rats-architecture], and the corresponding challenge- response interaction model defined in the [I-D.ietf-rats-reference-interaction-models] document. A fresh nonce with an appropriate amount of entropy [NIST-915121] MUST be supplied by the YANG client in order to enable a proof-of-freshness with respect to the attestation Evidence provided by the Attester running the YANG datastore. Further, this nonce is used to prevent replay attacks. The method for communicating the relationship of each individual TPM to specific measured component within the Composite Device is out of the scope of this document. 2.1. YANG Modules In this section the several YANG modules are defined. Birkholz, et al. Expires 19 November 2022 [Page 3] Internet-Draft YANG-CHARRA for TPMs May 2022 2.1.1. 'ietf-tpm-remote-attestation' This YANG module imports modules from [RFC6991] with prefix 'yang', [RFC8348] with prefix 'hw', [I-D.ietf-netconf-keystore] with prefix 'ks', and 'ietf-tcg-algs.yang' Section 2.1.2.3 with prefix 'taa'. Additionally, references are made to [RFC8032], [RFC8017], [RFC6933], [TPM1.2-Commands], [TPM2.0-Arch], [TPM2.0-Structures], [TPM2.0-Key], [TPM1.2-Structures], [bios-log], [BIOS-Log-Event-Type], as well as Appendix A and Appendix B. 2.1.1.1. Features This module supports the following features: * 'mtpm': Indicates that multiple TPMs on the device can support remote attestation. For example, this feature could be used in cases where multiple line cards are present, each with its own TPM. * 'bios': Indicates that the device supports the retrieval of BIOS/ UEFI event logs. [bios-log] * 'ima': Indicates that the device supports the retrieval of event logs from the Linux Integrity Measurement Architecture (IMA, see Appendix A). * 'netequip_boot': Indicates that the device supports the retrieval of netequip boot event logs. See Appendix A and Appendix B. 2.1.1.2. Identities This module supports the following types of attestation event logs: 'bios', 'ima', and 'netequip_boot'. 2.1.1.3. Remote Procedure Calls (RPCs) In the following, RPCs for both TPM 1.2 and TPM 2.0 attestation procedures are defined. 2.1.1.3.1. 'tpm12-challenge-response-attestation' This RPC allows a Verifier to request signed TPM PCRs (_TPM Quote_ operation) from a TPM 1.2 compliant cryptoprocessor. Where the feature 'mtpm' is active, and one or more 'certificate-name' is not provided, all TPM 1.2 compliant cryptoprocessors will respond. A YANG tree diagram of this RPC is as follows: Birkholz, et al. Expires 19 November 2022 [Page 4] Internet-Draft YANG-CHARRA for TPMs May 2022 +---x tpm12-challenge-response-attestation {taa:tpm12}? +---w input | +---w tpm12-attestation-challenge | +---w pcr-index* pcr | +---w nonce-value binary | +---w certificate-name* certificate-name-ref | {tpm:mtpm}? +--ro output +--ro tpm12-attestation-response* [] +--ro certificate-name certificate-name-ref +--ro up-time? uint32 +--ro TPM_QUOTE2? binary 2.1.1.3.2. 'tpm20-challenge-response-attestation' This RPC allows a Verifier to request signed TPM PCRs (_TPM Quote_ operation) from a TPM 2.0 compliant cryptoprocessor. Where the feature 'mtpm' is active, and one or more 'certificate-name' is not provided, all TPM 2.0 compliant cryptoprocessors will respond. A YANG tree diagram of this RPC is as follows: +---x tpm20-challenge-response-attestation {taa:tpm20}? +---w input | +---w tpm20-attestation-challenge | +---w nonce-value binary | +---w tpm20-pcr-selection* [] | | +---w tpm20-hash-algo? identityref | | +---w pcr-index* pcr | +---w certificate-name* certificate-name-ref | {tpm:mtpm}? +--ro output +--ro tpm20-attestation-response* [] +--ro certificate-name certificate-name-ref +--ro TPMS_QUOTE_INFO binary +--ro quote-signature? binary +--ro up-time? uint32 +--ro unsigned-pcr-values* [] +--ro tpm20-hash-algo? identityref +--ro pcr-values* [pcr-index] +--ro pcr-index pcr +--ro pcr-value? binary An example of an RPC challenge requesting PCRs 0-7 from a SHA-256 bank could look like the following: Birkholz, et al. Expires 19 November 2022 [Page 5] Internet-Draft YANG-CHARRA for TPMs May 2022 xmlns="urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation"> (identifier of a TPM signature key with which the Verifier is supposed to sign the attestation data) 0xe041307208d9f78f5b1bbecd19e2d152ad49de2fc5a7d8dbf769f6b8ffdeab9 TPM_ALG_SHA256 0 1 2 3 4 5 6 7 A successful response could be formatted as follows: (instance of Certificate name in the Keystore) (raw attestation data, i.e. the TPM quote; this includes a composite digest of requested PCRs, the nonce, and TPM 2.0 time information.) (signature over attestation-data using the TPM key identified by sig-key-id) Birkholz, et al. Expires 19 November 2022 [Page 6] Internet-Draft YANG-CHARRA for TPMs May 2022 2.1.1.4. 'log-retrieval' This RPC allows a Verifier to acquire the evidence which was extended into specific TPM PCRs. A YANG tree diagram of this RPC is as follows: +---x log-retrieval +---w input | +---w log-type identityref | +---w log-selector* [] | +---w name* string | +---w (index-type)? | | +--:(last-entry) | | | +---w last-entry-value? binary | | +--:(index) | | | +---w last-index-number? uint64 | | +--:(timestamp) | | +---w timestamp? yang:date-and-time | +---w log-entry-quantity? uint16 +--ro output +--ro system-event-logs +--ro node-data* [] +--ro name? string +--ro up-time? uint32 +--ro log-result +--ro (attested_event_log_type) +--:(bios) {bios}? | +--ro bios-event-logs | +--ro bios-event-entry* [event-number] | +--ro event-number uint32 | +--ro event-type? uint32 | +--ro pcr-index? pcr | +--ro digest-list* [] | | +--ro hash-algo? identityref | | +--ro digest* binary | +--ro event-size? uint32 | +--ro event-data* binary +--:(ima) {ima}? | +--ro ima-event-logs | +--ro ima-event-entry* [event-number] | +--ro event-number uint64 | +--ro ima-template? string | +--ro filename-hint? string | +--ro filedata-hash? binary | +--ro filedata-hash-algorithm? string | +--ro template-hash-algorithm? string | +--ro template-hash? binary | +--ro pcr-index? pcr Birkholz, et al. Expires 19 November 2022 [Page 7] Internet-Draft YANG-CHARRA for TPMs May 2022 | +--ro signature? binary +--:(netequip_boot) {netequip_boot}? +--ro boot-event-logs +--ro boot-event-entry* [event-number] +--ro event-number uint64 +--ro ima-template? string +--ro filename-hint? string +--ro filedata-hash? binary +--ro filedata-hash-algorithm? string +--ro template-hash-algorithm? string +--ro template-hash? binary +--ro pcr-index? pcr +--ro signature? binary 2.1.1.5. Data Nodes This section provides a high level description of the data nodes containing the configuration and operational objects with the YANG model. For more details, please see the YANG model itself in Figure 1. Container 'rats-support-structures': This houses the set of information relating to remote attestation for a device. This includes specific device TPM(s), the compute nodes (such as line cards) on which the TPM(s) reside, and the algorithms supported across the platform. Container 'tpms': Provides configuration and operational details for each supported TPM, including the tpm-firmware-version, PCRs which may be quoted, certificates which are associated with that TPM, and the current operational status. Of note are the certificates which are associated with that TPM. As a certificate is associated with a particular TPM attestation key, knowledge of the certificate allows a specific TPM to be identified. Birkholz, et al. Expires 19 November 2022 [Page 8] Internet-Draft YANG-CHARRA for TPMs May 2022 +--rw tpms +--rw tpm* [name] +--rw name string +--ro hardware-based boolean +--ro physical-index? int32 {hw:entity-mib}? +--ro path? string +--ro compute-node compute-node-ref {tpm:mtpm}? +--ro manufacturer? string +--rw firmware-version identityref +--rw tpm12-hash-algo? identityref {taa:tpm12}? +--rw tpm12-pcrs* pcr +--rw tpm20-pcr-bank* [tpm20-hash-algo] {taa:tpm20}? | +--rw tpm20-hash-algo identityref | +--rw pcr-index* tpm:pcr +--ro status enumeration +--rw certificates +--rw certificate* [name] +--rw name string +--rw keystore-ref? leafref {ks:asymmetric-keys}? +--rw type? enumeration container 'attester-supported-algos' - Identifies which TCG hash algorithms are available for use on the Attesting platform. An operator will use this information to limit algorithms available for use by RPCs to just a desired set from the universe of all allowed hash algorithms by the TCG. +--rw attester-supported-algos +--rw tpm12-asymmetric-signing* identityref {taa:tpm12}? +--rw tpm12-hash* identityref {taa:tpm12}? +--rw tpm20-asymmetric-signing* identityref {taa:tpm20}? +--rw tpm20-hash* identityref {taa:tpm20}? container 'compute-nodes' - When there is more than one TPM supported, this container maintains the set of information related to the compute node associated with a specific TPM. This allows each specific TPM to identify to which 'compute-node' it belongs. +--rw compute-nodes {tpm:mtpm}? +--ro compute-node* [node-id] +--ro node-id string +--ro node-physical-index? int32 {hw:entity-mib}? +--ro node-name? string +--ro node-location? string 2.1.1.6. YANG Module Birkholz, et al. Expires 19 November 2022 [Page 9] Internet-Draft YANG-CHARRA for TPMs May 2022 file "ietf-tpm-remote-attestation@2022-05-17.yang" module ietf-tpm-remote-attestation { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation"; prefix tpm; import ietf-yang-types { prefix yang; } import ietf-hardware { prefix hw; } import ietf-keystore { prefix ks; } import ietf-tcg-algs { prefix taa; } organization "IETF RATS (Remote ATtestation procedureS) Working Group"; contact "WG Web : WG List : Author : Eric Voit Author : Henk Birkholz Author : Michael Eckel Author : Shwetha Bhandari Author : Bill Sulzen Author : Liang Xia (Frank) Author : Tom Laffey Author : Guy Fedorkow "; description "A YANG module to enable a TPM 1.2 and TPM 2.0 based remote attestation procedure using a challenge-response interaction model and the TPM 1.2 and TPM 2.0 Quote primitive operations. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX Birkholz, et al. Expires 19 November 2022 [Page 10] Internet-Draft YANG-CHARRA for TPMs May 2022 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2022-05-17 { description "Initial version"; reference "RFC XXXX: A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs"; } /*****************/ /* Features */ /*****************/ feature mtpm { description "The device supports the remote attestation of multiple TPM based cryptoprocessors."; } feature bios { description "The device supports the bios logs."; reference "bios-log: https://trustedcomputinggroup.org/wp-content/uploads/ PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf Section 9.4.5.2"; } feature ima { description "The device supports Integrity Measurement Architecture logs. Many variants of IMA logs exist in the deployment. Each encodes the log entry contents as the specific measurements which get hashed into a PCRs as Evidence. See the reference below for one example of such an encoding."; reference "ima-log: https://www.trustedcomputinggroup.org/wp-content/uploads/ TCG_IWG_CEL_v1_r0p41_pub.pdf Section 5.1.6"; Birkholz, et al. Expires 19 November 2022 [Page 11] Internet-Draft YANG-CHARRA for TPMs May 2022 } feature netequip_boot { description "The device supports the netequip_boot logs."; reference "netequip-boot-log: RFC XXXX Appendix B"; } /*****************/ /* Typedefs */ /*****************/ typedef pcr { type uint8 { range "0..31"; } description "Valid index number for a PCR. A {{TPM2.0}} compliant PCR index extends from 0-31. At this time a typical TPM would have no more than 32 PCRS."; } typedef compute-node-ref { type leafref { path "/tpm:rats-support-structures/tpm:compute-nodes" + "/tpm:compute-node/tpm:node-id"; } description "This type is used to reference a hardware node. Note that an implementer might include an alternative leafref pointing to a different YANG module node specifying hardware structures."; } typedef certificate-name-ref { type leafref { path "/tpm:rats-support-structures/tpm:tpms/tpm:tpm" + "/tpm:certificates/tpm:certificate/tpm:name"; } description "A type which allows identification of a TPM based certificate."; } /******************/ /* Identities */ /******************/ Birkholz, et al. Expires 19 November 2022 [Page 12] Internet-Draft YANG-CHARRA for TPMs May 2022 identity attested_event_log_type { description "Base identity allowing categorization of the reasons why an attested measurement has been taken on an Attester."; } identity ima { base attested_event_log_type; description "An event type recorded in IMA."; } identity bios { base attested_event_log_type; description "An event type associated with BIOS/UEFI."; } identity netequip_boot { base attested_event_log_type; description "An event type associated with Network Equipment Boot."; } /*****************/ /* Groupings */ /*****************/ grouping tpm20-hash-algo { description "The cryptographic algorithm used to hash the TPM2 PCRs. This must be from the list of platform supported options."; leaf tpm20-hash-algo { type identityref { base taa:hash; } must '. = /tpm:rats-support-structures' + '/tpm:attester-supported-algos/tpm:tpm20-hash' { error-message "This platform does not support tpm20-hash-algo"; } description "The hash scheme that is used to hash a TPM2.0 PCR. This must be one of those supported by a platform. Where this object does not appear, the default value of 'taa:TPM_ALG_SHA256' will apply."; } } Birkholz, et al. Expires 19 November 2022 [Page 13] Internet-Draft YANG-CHARRA for TPMs May 2022 grouping tpm12-hash-algo { description "The cryptographic algorithm used to hash the TPM1.2 PCRs."; leaf tpm12-hash-algo { type identityref { base taa:hash; } must '. = /tpm:rats-support-structures' + '/tpm:attester-supported-algos/tpm:tpm12-hash' { error-message "This platform does not support tpm12-hash-algo"; } description "The hash scheme that is used to hash a TPM1.2 PCR. This MUST be one of those supported by a platform. Where this object does not appear, the default value of 'taa:TPM_ALG_SHA1' will apply."; } } grouping nonce { description "A random number intended to guarantee freshness and for use as part of a replay-detection mechanism."; leaf nonce-value { type binary; mandatory true; description "A cryptographically generated random number which should not be predictable prior to its issuance from a random number generation function. The random number MUST be derived from an entropy source external to the Attester. Note that a nonce sent into a TPM will typically be 160 or 256 binary digits long. (This is 20 or 32 bytes.) So if fewer binary digits are sent, this nonce object will be padded with leading zeros within Quotes returned from the TPM. Additionally if more bytes are sent, the nonce will be trimmed to the most significant binary digits."; } } grouping tpm12-pcr-selection { description "A Verifier can request one or more PCR values using its individually created Attestation Key Certificate (AC). The corresponding selection filter is represented in this grouping."; leaf-list pcr-index { Birkholz, et al. Expires 19 November 2022 [Page 14] Internet-Draft YANG-CHARRA for TPMs May 2022 type pcr; description "The numbers/indexes of the PCRs. In addition, any selection of PCRs MUST verify that the set of PCRs requested are a subset the set of PCRs exposed by in the leaf-list /tpm:rats-support-structures /tpm:tpms/tpm:tpm[name=current()]/tpm:tpm12-pcrs"; } } grouping tpm20-pcr-selection { description "A Verifier can acquire one or more PCR values, which are hashed together in a TPM2B_DIGEST coming from the TPM2. The selection list of desired PCRs and the Hash Algorithm is represented in this grouping."; list tpm20-pcr-selection { unique "tpm20-hash-algo"; description "Specifies the list of PCRs and Hash Algorithms that can be returned within a TPM2B_DIGEST."; reference "TPM2.0-Structures: https://www.trustedcomputinggroup.org/wp-content/uploads/ TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.9.7"; uses tpm20-hash-algo; leaf-list pcr-index { type pcr; description "The numbers of the PCRs that which are being tracked with a hash based on the tpm20-hash-algo. In addition, any selection of PCRs MUST verify that the set of PCRs requested are a subset the set of PCR indexes selected are available for that specific TPM."; } } } grouping certificate-name-ref { description "Identifies a certificate in a keystore."; leaf certificate-name { type certificate-name-ref; mandatory true; description "Identifies a certificate in a keystore."; } } Birkholz, et al. Expires 19 November 2022 [Page 15] Internet-Draft YANG-CHARRA for TPMs May 2022 grouping tpm-name { description "A unique TPM on a device."; leaf name { type string; description "Unique system generated name for a TPM on a device."; } } grouping node-uptime { description "Uptime in seconds of the node."; leaf up-time { type uint32; description "Uptime in seconds of this node reporting its data"; } } grouping tpm12-attestation { description "Contains an instance of TPM1.2 style signed cryptoprocessor measurements. It is supplemented by unsigned Attester information."; uses node-uptime; leaf TPM_QUOTE2 { type binary; description "Result of a TPM1.2 Quote2 operation. This includes PCRs, signatures, locality, the provided nonce and other data which can be further parsed to appraise the Attester."; reference "TPM1.2-Commands: TPM1.2 commands rev116 July 2007, Section 16.5 https://trustedcomputinggroup.org/wp-content/uploads /TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf"; } } grouping tpm20-attestation { description "Contains an instance of TPM2 style signed cryptoprocessor measurements. It is supplemented by unsigned Attester information."; leaf TPMS_QUOTE_INFO { type binary; mandatory true; Birkholz, et al. Expires 19 November 2022 [Page 16] Internet-Draft YANG-CHARRA for TPMs May 2022 description "A hash of the latest PCR values (and the hash algorithm used) which have been returned from a Verifier for the selected PCRs and Hash Algorithms."; reference "TPM2.0-Structures: https://www.trustedcomputinggroup.org/wp-content/uploads/ TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.12.1"; } leaf quote-signature { type binary; description "Quote signature returned by TPM Quote. The signature was generated using the key associated with the certificate 'name'."; reference "TPM2.0-Structures: https://www.trustedcomputinggroup.org/wp-content/uploads/ TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 11.2.1"; } uses node-uptime; list unsigned-pcr-values { description "PCR values in each PCR bank. This might appear redundant with the TPM2B_DIGEST, but that digest is calculated across multiple PCRs. Having to verify across multiple PCRs does not necessarily make it easy for a Verifier to appraise just the minimum set of PCR information which has changed since the last received TPM2B_DIGEST. Put another way, why should a Verifier reconstruct the proper value of all PCR Quotes when only a single PCR has changed? To help this happen, if the Attester does know specific PCR values, the Attester can provide these individual values via 'unsigned-pcr-values'. By comparing this information to what has previously been validated, it is possible for a Verifier to confirm the Attester's signature while eliminating significant processing. Note that there should never be a result where an unsigned PCR value differs from what may be reconstructed from the within the PCR quote and the event logs. If there is a difference, a signed result which has been verified from retrieved logs is considered definitive."; uses tpm20-hash-algo; list pcr-values { key "pcr-index"; description "List of one PCR bank."; leaf pcr-index { Birkholz, et al. Expires 19 November 2022 [Page 17] Internet-Draft YANG-CHARRA for TPMs May 2022 type pcr; description "PCR index number."; } leaf pcr-value { type binary; description "PCR value."; reference "TPM2.0-Structures: https://www.trustedcomputinggroup.org/wp-content/uploads/ TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.9.7"; } } } } grouping log-identifier { description "Identifier for type of log to be retrieved."; leaf log-type { type identityref { base attested_event_log_type; } mandatory true; description "The corresponding measurement log type identity."; } } grouping boot-event-log { description "Defines a specific instance of an event log entry and corresponding to the information used to extend the PCR"; leaf event-number { type uint32; description "Unique event number of this event which monotonically increases within a given event log. The maximum event number should not be reached, nor is wrapping back to an earlier number supported."; } leaf event-type { type uint32; description "BIOS Log Event Type: https://trustedcomputinggroup.org/wp-content/uploads/ Birkholz, et al. Expires 19 November 2022 [Page 18] Internet-Draft YANG-CHARRA for TPMs May 2022 TCG_PCClient_PFP_r1p05_v23_pub.pdf Section 10.4.1"; } leaf pcr-index { type pcr; description "Defines the PCR index that this event extended"; } list digest-list { description "Hash of event data"; leaf hash-algo { type identityref { base taa:hash; } description "The hash scheme that is used to compress the event data in each of the leaf-list digest items."; } leaf-list digest { type binary; description "The hash of the event data using the algorithm of the 'hash-algo' against 'event data'."; } } leaf event-size { type uint32; description "Size of the event data"; } leaf-list event-data { type binary; description "The event data. This is a binary structure of size 'event-size'. For more on what might be recorded within this object see [bios-log] Section 9 which details viable events which might be recorded."; } } grouping bios-event-log { description "Measurement log created by the BIOS/UEFI."; list bios-event-entry { key "event-number"; description "Ordered list of TCG described event log Birkholz, et al. Expires 19 November 2022 [Page 19] Internet-Draft YANG-CHARRA for TPMs May 2022 that extended the PCRs in the order they were logged"; uses boot-event-log; } } grouping ima-event { description "Defines a hash log extend event for IMA measurements"; reference "ima-log: https://www.trustedcomputinggroup.org/wp-content/uploads/ TCG_IWG_CEL_v1_r0p41_pub.pdf Section 4.3"; leaf event-number { type uint64; description "Unique event number of this event which monotonically increases. The maximum event number should not be reached, nor is wrapping back to an earlier number supported."; } leaf ima-template { type string; description "Name of the template used for event logs for e.g. ima, ima-ng, ima-sig"; } leaf filename-hint { type string; description "File name (including the path) that was measured."; } leaf filedata-hash { type binary; description "Hash of filedata as updated based upon the filedata-hash-algorithm"; } leaf filedata-hash-algorithm { type string; description "Algorithm used for filedata-hash"; } leaf template-hash-algorithm { type string; description "Algorithm used for template-hash"; } Birkholz, et al. Expires 19 November 2022 [Page 20] Internet-Draft YANG-CHARRA for TPMs May 2022 leaf template-hash { type binary; description "hash(filedata-hash, filename-hint)"; } leaf pcr-index { type pcr; description "Defines the PCR index that this event extended"; } leaf signature { type binary; description "Digital file signature which provides a fingerprint for the file being measured."; } } grouping ima-event-log { description "Measurement log created by IMA."; list ima-event-entry { key "event-number"; description "Ordered list of ima event logs by event-number"; uses ima-event; } } grouping network-equipment-boot-event-log { description "Measurement log created by Network Equipment Boot. The Network Equipment Boot format is identical to the IMA format. In contrast to the IMA log, the Network Equipment Boot log includes every measurable event from an Attester, including the boot stages of BIOS, Bootloader, etc. In essence, the scope of events represented in this format combines the scope of BIOS events and IMA events."; list boot-event-entry { key "event-number"; description "Ordered list of Network Equipment Boot event logs by event-number, using the IMA event format."; uses ima-event; } } grouping event-logs { Birkholz, et al. Expires 19 November 2022 [Page 21] Internet-Draft YANG-CHARRA for TPMs May 2022 description "A selector for the log and its type."; choice attested_event_log_type { mandatory true; description "Event log type determines the event logs content."; case bios { if-feature "bios"; description "BIOS/UEFI event logs"; container bios-event-logs { description "BIOS/UEFI event logs"; uses bios-event-log; } } case ima { if-feature "ima"; description "IMA event logs."; container ima-event-logs { description "IMA event logs."; uses ima-event-log; } } case netequip_boot { if-feature "netequip_boot"; description "Network Equipment Boot event logs"; container boot-event-logs { description "Network equipment boot event logs."; uses network-equipment-boot-event-log; } } } } /**********************/ /* RPC operations */ /**********************/ rpc tpm12-challenge-response-attestation { if-feature "taa:tpm12"; description "This RPC accepts the input for TSS TPM 1.2 commands made to the attesting device."; Birkholz, et al. Expires 19 November 2022 [Page 22] Internet-Draft YANG-CHARRA for TPMs May 2022 input { container tpm12-attestation-challenge { description "This container includes every information element defined in the reference challenge-response interaction model for remote attestation. Corresponding values are based on TPM 1.2 structure definitions"; uses tpm12-pcr-selection; uses nonce; leaf-list certificate-name { if-feature "tpm:mtpm"; type certificate-name-ref; must "/tpm:rats-support-structures/tpm:tpms" + "/tpm:tpm[tpm:firmware-version='taa:tpm12']" + "/tpm:certificates/" + "/tpm:certificate[name=current()]" { error-message "Not an available TPM1.2 AIK certificate."; } description "When populated, the RPC will only get a Quote for the TPMs associated with these certificate(s)."; } } } output { list tpm12-attestation-response { unique "certificate-name"; description "The binary output of TPM 1.2 TPM_Quote/TPM_Quote2, including the PCR selection and other associated attestation evidence metadata"; uses certificate-name-ref { description "Certificate associated with this tpm12-attestation."; } uses tpm12-attestation; } } } rpc tpm20-challenge-response-attestation { if-feature "taa:tpm20"; description "This RPC accepts the input for TSS TPM 2.0 commands of the managed device. ComponentIndex from the hardware manager YANG module is used to refer to dedicated TPM in composite devices, e.g. smart NICs, is not covered."; input { Birkholz, et al. Expires 19 November 2022 [Page 23] Internet-Draft YANG-CHARRA for TPMs May 2022 container tpm20-attestation-challenge { description "This container includes every information element defined in the reference challenge-response interaction model for remote attestation. Corresponding values are based on TPM 2.0 structure definitions"; uses nonce; uses tpm20-pcr-selection; leaf-list certificate-name { if-feature "tpm:mtpm"; type certificate-name-ref; must "/tpm:rats-support-structures/tpm:tpms" + "/tpm:tpm[tpm:firmware-version='taa:tpm20']" + "/tpm:certificates/" + "/tpm:certificate[name=current()]" { error-message "Not an available TPM2.0 AIK certificate."; } description "When populated, the RPC will only get a Quote for the TPMs associated with the certificates."; } } } output { list tpm20-attestation-response { unique "certificate-name"; description "The binary output of TPM2b_Quote from one TPM of the node which identified by node-id. An TPMS_ATTEST structure including a length, encapsulated in a signature"; uses certificate-name-ref { description "Certificate associated with this tpm20-attestation."; } uses tpm20-attestation; } } } rpc log-retrieval { description "Logs Entries are either identified via indices or via providing the last line received. The number of lines returned can be limited. The type of log is a choice that can be augmented."; input { uses log-identifier; list log-selector { description Birkholz, et al. Expires 19 November 2022 [Page 24] Internet-Draft YANG-CHARRA for TPMs May 2022 "Only log entries which meet all the selection criteria provided are to be returned by the RPC output."; leaf-list name { type string; description "Name of one or more unique TPMs on a device. If this object exists, a selection should pull only the objects related to these TPM(s). If it does not exist, all qualifying TPMs that are 'hardware-based' equals true on the device are selected. When this selection criteria is provided, it will be considered as a logical AND with any other selection criteria provided."; } choice index-type { description "Last log entry received, log index number, or timestamp."; case last-entry { description "The last entry of the log already retrieved."; leaf last-entry-value { type binary; description "Content of a log event which matches 1:1 with a unique event record contained within the log. Log entries after this will be passed to the requester. Note: if log entry values are not unique, this MUST return an error."; } } case index { description "Numeric index of the last log entry retrieved, or zero."; leaf last-index-number { type uint64; description "The last numeric index number of a log entry. Zero means to start at the beginning of the log. Entries after this will be passed to the requester."; } } case timestamp { leaf timestamp { type yang:date-and-time; description "Timestamp from which to start the extraction. The next log entry after this timestamp is to Birkholz, et al. Expires 19 November 2022 [Page 25] Internet-Draft YANG-CHARRA for TPMs May 2022 be sent."; } description "Timestamp from which to start the extraction."; } } leaf log-entry-quantity { type uint16; description "The number of log entries to be returned. If omitted, it means all of them."; } } } output { container system-event-logs { description "The requested data of the measurement event logs"; list node-data { unique "name"; description "Event logs of a node in a distributed system identified by the node name"; uses tpm-name; uses node-uptime; container log-result { description "The requested entries of the corresponding log."; uses event-logs; } } } } } /**************************************/ /* Config & Oper accessible nodes */ /**************************************/ container rats-support-structures { description "The datastore definition enabling verifiers or relying parties to discover the information necessary to use the remote attestation RPCs appropriately."; container compute-nodes { if-feature "tpm:mtpm"; description "Holds the set of device subsystems/components in this Birkholz, et al. Expires 19 November 2022 [Page 26] Internet-Draft YANG-CHARRA for TPMs May 2022 composite device that support TPM operations."; list compute-node { key "node-id"; unique "node-name"; config false; min-elements 2; description "A component within this composite device which supports TPM operations."; leaf node-id { type string; description "ID of the compute node, such as Board Serial Number."; } leaf node-physical-index { if-feature "hw:entity-mib"; type int32 { range "1..2147483647"; } config false; description "The entPhysicalIndex for the compute node."; reference "RFC 6933: Entity MIB (Version 4) - entPhysicalIndex"; } leaf node-name { type string; description "Name of the compute node."; } leaf node-location { type string; description "Location of the compute node, such as slot number."; } } } container tpms { description "Holds the set of TPMs within an Attester."; list tpm { key "name"; unique "path"; description "A list of TPMs in this composite device that RATS can be conducted with."; uses tpm-name; leaf hardware-based { Birkholz, et al. Expires 19 November 2022 [Page 27] Internet-Draft YANG-CHARRA for TPMs May 2022 type boolean; config false; mandatory true; description "System generated indication of whether this is a hardware based TPM."; } leaf physical-index { if-feature "hw:entity-mib"; type int32 { range "1..2147483647"; } config false; description "The entPhysicalIndex for the TPM."; reference "RFC 6933: Entity MIB (Version 4) - entPhysicalIndex"; } leaf path { type string; config false; description "Device path to a unique TPM on a device. This can change across reboots."; } leaf compute-node { if-feature "tpm:mtpm"; type compute-node-ref; config false; mandatory true; description "Indicates the compute node measured by this TPM."; } leaf manufacturer { type string; config false; description "TPM manufacturer name."; } leaf firmware-version { type identityref { base taa:cryptoprocessor; } mandatory true; description "Identifies the cryptoprocessor API set supported. This is automatically configured by the device and should not be changed."; Birkholz, et al. Expires 19 November 2022 [Page 28] Internet-Draft YANG-CHARRA for TPMs May 2022 } uses tpm12-hash-algo { when "derived-from-or-self(firmware-version, 'taa:tpm12')"; if-feature "taa:tpm12"; refine "tpm12-hash-algo" { description "The hash algorithm overwrites the default used for PCRs on this TPM1.2 compliant cryptoprocessor."; } } leaf-list tpm12-pcrs { when "derived-from-or-self(../firmware-version, 'taa:tpm12')"; if-feature "taa:tpm12"; type pcr; description "The PCRs which may be extracted from this TPM1.2 compliant cryptoprocessor."; } list tpm20-pcr-bank { when "derived-from-or-self(../firmware-version, 'taa:tpm20')"; if-feature "taa:tpm20"; key "tpm20-hash-algo"; description "Specifies the list of PCRs that may be extracted for a specific Hash Algorithm on this TPM2 compliant cryptoprocessor. A bank is a set of PCRs which are extended using a particular hash algorithm."; reference "TPM2.0-Structures: https://www.trustedcomputinggroup.org/wp-content/uploads/ TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.9.7"; leaf tpm20-hash-algo { type identityref { base taa:hash; } must '/tpm:rats-support-structures' + '/tpm:attester-supported-algos' + '/tpm:tpm20-hash' { error-message "This platform does not support tpm20-hash-algo"; } description "The hash scheme actively being used to hash a one or more TPM2.0 PCRs."; } leaf-list pcr-index { type tpm:pcr; Birkholz, et al. Expires 19 November 2022 [Page 29] Internet-Draft YANG-CHARRA for TPMs May 2022 description "Defines what TPM2 PCRs are available to be extracted."; } } leaf status { type enumeration { enum operational { value 0; description "The TPM currently is running normally and is ready to accept and process TPM quotes."; reference "TPM2.0-Arch: https://trustedcomputinggroup.org/wp-content/uploads/ TCG_TPM2_r1p59_Part1_Architecture_pub.pdf Section 12"; } enum non-operational { value 1; description "TPM is in a state such as startup or shutdown which precludes the processing of TPM quotes."; } } config false; mandatory true; description "TPM chip self-test status."; } container certificates { description "The TPM's certificates, including EK certificates and Attestation Key certificates."; list certificate { key "name"; description "Three types of certificates can be accessed via this statement, including Initial Attestation Key Certificate, Local Attestation Key Certificate or Endorsement Key Certificate."; leaf name { type string; description "An arbitrary name uniquely identifying a certificate associated within key within a TPM."; } leaf keystore-ref { if-feature "ks:asymmetric-keys"; Birkholz, et al. Expires 19 November 2022 [Page 30] Internet-Draft YANG-CHARRA for TPMs May 2022 type leafref { path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key" + "/ks:name"; } description "A reference to a specific certificate of an asymmetric key in the Keystore."; } leaf type { type enumeration { enum endorsement-certificate { value 0; description "Endorsement Key (EK) Certificate type."; reference "TPM2.0-Key: https://trustedcomputinggroup.org/wp-content/ uploads/TPM-2p0-Keys-for-Device-Identity- and-Attestation_v1_r12_pub10082021.pdf Section 3.11"; } enum initial-attestation-certificate { value 1; description "Initial Attestation key (IAK) Certificate type."; reference "TPM2.0-Key: https://trustedcomputinggroup.org/wp-content/ uploads/TPM-2p0-Keys-for-Device-Identity- and-Attestation_v1_r12_pub10082021.pdf Section 3.2"; } enum local-attestation-certificate { value 2; description "Local Attestation Key (LAK) Certificate type."; reference "TPM2.0-Key: https://trustedcomputinggroup.org/wp-content/ uploads/TPM-2p0-Keys-for-Device-Identity- and-Attestation_v1_r12_pub10082021.pdf Section 3.2"; } } description "Function supported by this certificate from within the TPM."; } Birkholz, et al. Expires 19 November 2022 [Page 31] Internet-Draft YANG-CHARRA for TPMs May 2022 } } } } container attester-supported-algos { description "Identifies which TPM algorithms are available for use on an attesting platform."; leaf-list tpm12-asymmetric-signing { when "../../tpm:tpms" + "/tpm:tpm[tpm:firmware-version='taa:tpm12']"; if-feature "taa:tpm12"; type identityref { base taa:asymmetric; } description "Platform Supported TPM12 asymmetric algorithms."; } leaf-list tpm12-hash { when "../../tpm:tpms" + "/tpm:tpm[tpm:firmware-version='taa:tpm12']"; if-feature "taa:tpm12"; type identityref { base taa:hash; } description "Platform supported TPM12 hash algorithms."; } leaf-list tpm20-asymmetric-signing { when "../../tpm:tpms" + "/tpm:tpm[tpm:firmware-version='taa:tpm20']"; if-feature "taa:tpm20"; type identityref { base taa:asymmetric; } description "Platform Supported TPM20 asymmetric algorithms."; } leaf-list tpm20-hash { when "../../tpm:tpms" + "/tpm:tpm[tpm:firmware-version='taa:tpm20']"; if-feature "taa:tpm20"; type identityref { base taa:hash; } description "Platform supported TPM20 hash algorithms."; } Birkholz, et al. Expires 19 November 2022 [Page 32] Internet-Draft YANG-CHARRA for TPMs May 2022 } } } Figure 1 2.1.2. 'ietf-tcg-algs' This document has encoded the TCG Algorithm definitions of [TCG-Algos], revision 1.32. By including this full table as a separate YANG file within this document, it is possible for other YANG models to leverage the contents of this model. Specific references to [RFC2104], [RFC8017], [ISO-IEC-9797-1], [ISO-IEC-9797-2], [ISO-IEC-10116], [ISO-IEC-10118-3], [ISO-IEC-14888-3], [ISO-IEC-15946-1], [ISO-IEC-18033-3], [IEEE-Std-1363-2000], [IEEE-Std-1363a-2004], [NIST-PUB-FIPS-202], [NIST-SP800-38C], [NIST-SP800-38D], [NIST-SP800-38F], [NIST-SP800-56A], [NIST-SP800-108], [bios-log], as well as Appendix A and Appendix B exist within the YANG Model. 2.1.2.1. Features There are two types of features supported: 'TPM12' and 'TPM20'. Support for either of these features indicates that a cryptoprocessor supporting the corresponding type of TCG TPM API is present on an Attester. Most commonly, only one type of cryptoprocessor will be available on an Attester. 2.1.2.2. Identities There are three types of identities in this model: 1. Cryptographic functions supported by a TPM algorithm; these include: 'asymmetric', 'symmetric', 'hash', 'signing', 'anonymous_signing', 'encryption_mode', 'method', and 'object_type'. The definitions of each of these are in Table 2 of [TCG-Algos]. 2. API specifications for TPM types: 'tpm12' and 'tpm20' 3. Specific algorithm types: Each algorithm type defines what cryptographic functions may be supported, and on which type of API specification. It is not required that an implementation of a specific TPM will support all algorithm types. The contents of each specific algorithm mirrors what is in Table 3 of [TCG-Algos]. Birkholz, et al. Expires 19 November 2022 [Page 33] Internet-Draft YANG-CHARRA for TPMs May 2022 2.1.2.3. YANG Module file "ietf-tcg-algs@2022-03-23.yang" module ietf-tcg-algs { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-tcg-algs"; prefix taa; organization "IETF RATS (Remote ATtestation procedureS) Working Group"; contact "WG Web: WG List: Author: Eric Voit "; description "This module defines identities for asymmetric algorithms. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2022-03-23 { description "Initial version"; reference "RFC XXXX: A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs"; } /*****************/ /* Features */ /*****************/ Birkholz, et al. Expires 19 November 2022 [Page 34] Internet-Draft YANG-CHARRA for TPMs May 2022 feature tpm12 { description "This feature indicates algorithm support for the TPM 1.2 API as per Section 4.8 of TPM1.2-Structures: TPM Main Part 2 TPM Structures https://trustedcomputinggroup.org/wp-content/uploads/TPM- Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf"; } feature tpm20 { description "This feature indicates algorithm support for the TPM 2.0 API as per Section 11.4 of Trusted Platform Module Library Part 1: Architecture. See TPM2.0-Arch: https://trustedcomputinggroup.org/wp-content/uploads/ TCG_TPM2_r1p59_Part1_Architecture_pub.pdf"; } /*****************/ /* Identities */ /*****************/ identity asymmetric { description "A TCG recognized asymmetric algorithm with a public and private key."; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 2, https://trustedcomputinggroup.org/resource/ tcg-algorithm-registry/TCG-_Algorithm_Registry_r1p32_pub"; } identity symmetric { description "A TCG recognized symmetric algorithm with only a private key."; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 2"; } identity hash { description "A TCG recognized hash algorithm that compresses input data to a digest value or indicates a method that uses a hash."; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 2"; } identity signing { Birkholz, et al. Expires 19 November 2022 [Page 35] Internet-Draft YANG-CHARRA for TPMs May 2022 description "A TCG recognized signing algorithm"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 2"; } identity anonymous_signing { description "A TCG recognized anonymous signing algorithm."; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 2"; } identity encryption_mode { description "A TCG recognized encryption mode."; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 2"; } identity method { description "A TCG recognized method such as a mask generation function."; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 2"; } identity object_type { description "A TCG recognized object type."; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 2"; } identity cryptoprocessor { description "Base identity identifying a crytoprocessor."; } identity tpm12 { if-feature "tpm12"; base cryptoprocessor; description "Supportable by a TPM1.2."; reference "TPM1.2-Structures: https://trustedcomputinggroup.org/wp-content/uploads/ TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf Birkholz, et al. Expires 19 November 2022 [Page 36] Internet-Draft YANG-CHARRA for TPMs May 2022 TPM_ALGORITHM_ID values, Section 4.8"; } identity tpm20 { if-feature "tpm20"; base cryptoprocessor; description "Supportable by a TPM2."; reference "TPM2.0-Structures: https://trustedcomputinggroup.org/wp-content/uploads/ TPM-Rev-2.0-Part-2-Structures-01.38.pdf"; } identity TPM_ALG_RSA { if-feature "tpm12 or tpm20"; base tpm12; base tpm20; base asymmetric; base object_type; description "RSA algorithm"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and RFC 8017. ALG_ID: 0x0001"; } identity TPM_ALG_TDES { if-feature "tpm12"; base tpm12; base symmetric; description "Block cipher with various key sizes (Triple Data Encryption Algorithm, commonly called Triple Data Encryption Standard) Note: was banned in TPM1.2 v94"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 18033-3. ALG_ID: 0x0003"; } identity TPM_ALG_SHA1 { if-feature "tpm12 or tpm20"; base hash; base tpm12; base tpm20; description "SHA1 algorithm - Deprecated due to insufficient cryptographic protection. However, it is still useful for hash algorithms Birkholz, et al. Expires 19 November 2022 [Page 37] Internet-Draft YANG-CHARRA for TPMs May 2022 where protection is not required."; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 10118-3. ALG_ID: 0x0004"; } identity TPM_ALG_HMAC { if-feature "tpm12 or tpm20"; base tpm12; base tpm20; base hash; base signing; description "Hash Message Authentication Code (HMAC) algorithm"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3, ISO/IEC 9797-2 and RFC2104. ALG_ID: 0x0005"; } identity TPM_ALG_AES { if-feature "tpm12"; base tpm12; base symmetric; description "The AES algorithm with various key sizes"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3, ISO/IEC 18033-3. ALG_ID: 0x0006"; } identity TPM_ALG_MGF1 { if-feature "tpm20"; base tpm20; base hash; base method; description "hash-based mask-generation function"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3, IEEE Std 1363-2000 and IEEE Std 1363a-2004. ALG_ID: 0x0007"; } identity TPM_ALG_KEYEDHASH { if-feature "tpm20"; base tpm20; base hash; base object_type; Birkholz, et al. Expires 19 November 2022 [Page 38] Internet-Draft YANG-CHARRA for TPMs May 2022 description "An encryption or signing algorithm using a keyed hash. These may use XOR for encryption or an HMAC for signing and may also refer to a data object that is neither signing nor encrypting."; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3, ALG_ID: 0x0008"; } identity TPM_ALG_XOR { if-feature "tpm12 or tpm20"; base tpm12; base tpm20; base hash; base symmetric; description "The XOR encryption algorithm."; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3. ALG_ID: 0x000A"; } identity TPM_ALG_SHA256 { if-feature "tpm20"; base tpm20; base hash; description "The SHA 256 algorithm"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 10118-3. ALG_ID: 0x000B"; } identity TPM_ALG_SHA384 { if-feature "tpm20"; base tpm20; base hash; description "The SHA 384 algorithm"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 10118-3. ALG_ID: 0x000C"; } identity TPM_ALG_SHA512 { if-feature "tpm20"; base tpm20; Birkholz, et al. Expires 19 November 2022 [Page 39] Internet-Draft YANG-CHARRA for TPMs May 2022 base hash; description "The SHA 512 algorithm"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 10118-3. ALG_ID: 0x000D"; } identity TPM_ALG_NULL { if-feature "tpm20"; base tpm20; description "NULL algorithm"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3. ALG_ID: 0x0010"; } identity TPM_ALG_SM3_256 { if-feature "tpm20"; base tpm20; base hash; description "The SM3 hash algorithm."; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 10118-3:2018. ALG_ID: 0x0012"; } identity TPM_ALG_SM4 { if-feature "tpm20"; base tpm20; base symmetric; description "SM4 symmetric block cipher"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3. ALG_ID: 0x0013"; } identity TPM_ALG_RSASSA { if-feature "tpm20"; base tpm20; base asymmetric; base signing; description "RFC 8017 Signature algorithm defined in section 8.2 (RSASSAPKCS1-v1_5)"; Birkholz, et al. Expires 19 November 2022 [Page 40] Internet-Draft YANG-CHARRA for TPMs May 2022 reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and RFC 8017. ALG_ID: 0x0014"; } identity TPM_ALG_RSAES { if-feature "tpm20"; base tpm20; base asymmetric; base encryption_mode; description "RFC 8017 Signature algorithm defined in section 7.2 (RSAES-PKCS1-v1_5)"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and RFC 8017. ALG_ID: 0x0015"; } identity TPM_ALG_RSAPSS { if-feature "tpm20"; base tpm20; base asymmetric; base signing; description "Padding algorithm defined in section 8.1 (RSASSA PSS)"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and RFC 8017. ALG_ID: 0x0016"; } identity TPM_ALG_OAEP { if-feature "tpm20"; base tpm20; base asymmetric; base encryption_mode; description "Padding algorithm defined in section 7.1 (RSASSA OAEP)"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and RFC 8017. ALG_ID: 0x0017"; } identity TPM_ALG_ECDSA { if-feature "tpm20"; base tpm20; base asymmetric; base signing; description Birkholz, et al. Expires 19 November 2022 [Page 41] Internet-Draft YANG-CHARRA for TPMs May 2022 "Signature algorithm using elliptic curve cryptography (ECC)"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 14888-3. ALG_ID: 0x0018"; } identity TPM_ALG_ECDH { if-feature "tpm20"; base tpm20; base asymmetric; base method; description "Secret sharing using ECC"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and NIST SP800-56A. ALG_ID: 0x0019"; } identity TPM_ALG_ECDAA { if-feature "tpm20"; base tpm20; base asymmetric; base signing; base anonymous_signing; description "Elliptic-curve based anonymous signing scheme"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and TCG TPM 2.0 library specification. ALG_ID: 0x001A"; } identity TPM_ALG_SM2 { if-feature "tpm20"; base tpm20; base asymmetric; base signing; base encryption_mode; base method; description "SM2 - depending on context, either an elliptic-curve based, signature algorithm, an encryption scheme, or a key exchange protocol"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3. ALG_ID: 0x001B"; } identity TPM_ALG_ECSCHNORR { Birkholz, et al. Expires 19 November 2022 [Page 42] Internet-Draft YANG-CHARRA for TPMs May 2022 if-feature "tpm20"; base tpm20; base asymmetric; base signing; description "Elliptic-curve based Schnorr signature"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3. ALG_ID: 0x001C"; } identity TPM_ALG_ECMQV { if-feature "tpm20"; base tpm20; base asymmetric; base method; description "Two-phase elliptic-curve key"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and NIST SP800-56A. ALG_ID: 0x001D"; } identity TPM_ALG_KDF1_SP800_56A { if-feature "tpm20"; base tpm20; base hash; base method; description "Concatenation key derivation function"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and NIST SP800-56A (approved alternative1) section 5.8.1. ALG_ID: 0x0020"; } identity TPM_ALG_KDF2 { if-feature "tpm20"; base tpm20; base hash; base method; description "Key derivation function"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and IEEE 1363a-2004 KDF2 section 13.2. ALG_ID: 0x0021"; } Birkholz, et al. Expires 19 November 2022 [Page 43] Internet-Draft YANG-CHARRA for TPMs May 2022 identity TPM_ALG_KDF1_SP800_108 { base TPM_ALG_KDF2; description "A key derivation method"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and NIST SP800-108 - Section 5.1 KDF. ALG_ID: 0x0022"; } identity TPM_ALG_ECC { if-feature "tpm20"; base tpm20; base asymmetric; base object_type; description "Prime field ECC"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 15946-1. ALG_ID: 0x0023"; } identity TPM_ALG_SYMCIPHER { if-feature "tpm20"; base tpm20; base symmetric; base object_type; description "Object type for a symmetric block cipher"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and TCG TPM 2.0 library specification. ALG_ID: 0x0025"; } identity TPM_ALG_CAMELLIA { if-feature "tpm20"; base tpm20; base symmetric; description "The Camellia algorithm"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 18033-3. ALG_ID: 0x0026"; } identity TPM_ALG_SHA3_256 { if-feature "tpm20"; base tpm20; base hash; Birkholz, et al. Expires 19 November 2022 [Page 44] Internet-Draft YANG-CHARRA for TPMs May 2022 description "ISO/IEC 10118-3 - the SHA 256 algorithm"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and NIST PUB FIPS 202. ALG_ID: 0x0027"; } identity TPM_ALG_SHA3_384 { if-feature "tpm20"; base tpm20; base hash; description "The SHA 384 algorithm"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and NIST PUB FIPS 202. ALG_ID: 0x0028"; } identity TPM_ALG_SHA3_512 { if-feature "tpm20"; base tpm20; base hash; description "The SHA 512 algorithm"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and NIST PUB FIPS 202. ALG_ID: 0x0029"; } identity TPM_ALG_CMAC { if-feature "tpm20"; base tpm20; base symmetric; base signing; description "block Cipher-based Message Authentication Code (CMAC)"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 9797-1:2011 Algorithm 5. ALG_ID: 0x003F"; } identity TPM_ALG_CTR { if-feature "tpm20"; base tpm20; base symmetric; base encryption_mode; description "Counter mode"; Birkholz, et al. Expires 19 November 2022 [Page 45] Internet-Draft YANG-CHARRA for TPMs May 2022 reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 10116. ALG_ID: 0x0040"; } identity TPM_ALG_OFB { base tpm20; base symmetric; base encryption_mode; description "Output Feedback mode"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 10116. ALG_ID: 0x0041"; } identity TPM_ALG_CBC { if-feature "tpm20"; base tpm20; base symmetric; base encryption_mode; description "Cipher Block Chaining mode"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 10116. ALG_ID: 0x0042"; } identity TPM_ALG_CFB { if-feature "tpm20"; base tpm20; base symmetric; base encryption_mode; description "Cipher Feedback mode"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 10116. ALG_ID: 0x0043"; } identity TPM_ALG_ECB { if-feature "tpm20"; base tpm20; base symmetric; base encryption_mode; description "Electronic Codebook mode"; reference Birkholz, et al. Expires 19 November 2022 [Page 46] Internet-Draft YANG-CHARRA for TPMs May 2022 "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and ISO/IEC 10116. ALG_ID: 0x0044"; } identity TPM_ALG_CCM { if-feature "tpm20"; base tpm20; base symmetric; base signing; base encryption_mode; description "Counter with Cipher Block Chaining-Message Authentication Code (CCM)"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and NIST SP800-38C. ALG_ID: 0x0050"; } identity TPM_ALG_GCM { if-feature "tpm20"; base tpm20; base symmetric; base signing; base encryption_mode; description "Galois/Counter Mode (GCM)"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and NIST SP800-38D. ALG_ID: 0x0051"; } identity TPM_ALG_KW { if-feature "tpm20"; base tpm20; base symmetric; base signing; base encryption_mode; description "AES Key Wrap (KW)"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and NIST SP800-38F. ALG_ID: 0x0052"; } identity TPM_ALG_KWP { if-feature "tpm20"; base tpm20; base symmetric; Birkholz, et al. Expires 19 November 2022 [Page 47] Internet-Draft YANG-CHARRA for TPMs May 2022 base signing; base encryption_mode; description "AES Key Wrap with Padding (KWP)"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and NIST SP800-38F. ALG_ID: 0x0053"; } identity TPM_ALG_EAX { if-feature "tpm20"; base tpm20; base symmetric; base signing; base encryption_mode; description "Authenticated-Encryption Mode"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and NIST SP800-38F. ALG_ID: 0x0054"; } identity TPM_ALG_EDDSA { if-feature "tpm20"; base tpm20; base asymmetric; base signing; description "Edwards-curve Digital Signature Algorithm (PureEdDSA)"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and RFC 8032. ALG_ID: 0x0060"; } } Note that not all cryptographic functions are required for use by ietf-tpm-remote-attestation.yang. However the full definition of Table 3 of [TCG-Algos] will allow use by additional YANG specifications. 3. IANA Considerations This document registers the following namespace URIs in the [xml-registry] as per [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation Birkholz, et al. Expires 19 November 2022 [Page 48] Internet-Draft YANG-CHARRA for TPMs May 2022 Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-tcg-algs Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document registers the following YANG modules in the registry [yang-parameters] as per Section 14 of [RFC6020]: Name: ietf-tpm-remote-attestation Namespace: urn:ietf:params:xml:ns:yang:ietf-tpm-remote- attestation Prefix: tpm Reference: draft-ietf-rats-yang-tpm-charra (RFC form) Name: ietf-tcg-algs Namespace: urn:ietf:params:xml:ns:yang:ietf-tcg-algs Prefix: taa Reference: draft-ietf-rats-yang-tpm-charra (RFC form) 4. Security Considerations The YANG module ietf-tpm-remote-attestation.yang specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., _config true_, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., _edit-config_) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes as well as their sensitivity/vulnerability: Birkholz, et al. Expires 19 November 2022 [Page 49] Internet-Draft YANG-CHARRA for TPMs May 2022 Container '/rats-support-structures/attester-supported-algos': 'tpm1 2-asymmetric-signing', 'tpm12-hash', 'tpm20-asymmetric-signing', and 'tpm20-hash'. All could be populated with algorithms that are not supported by the underlying physical TPM installed by the equipment vendor. A vendor should restrict the ability to configure unsupported algorithms. Container: '/rats-support-structures/tpms': 'name': Although shown as 'rw', it is system generated. Therefore, it should not be possible for an operator to add or remove a TPM from the configuration. 'tpm20-pcr-bank': It is possible to configure PCRs for extraction which are not being extended by system software. This could unnecessarily use TPM resources. 'certificates': It is possible to provision a certificate which does not correspond to an Attestation Identity Key (AIK) within the TPM 1.2, or an Attestation Key (AK) within the TPM 2.0 respectively. In such a case, calls to an RPC requesting this specific certificate could result in either no response or a response for an unexpected TPM. RPC 'tpm12-challenge-response-attestation': The receiver of the RPC response must verify that the certificate is for an active AIK, i.e., the certificate has been confirmed by a third party as being able to support Attestation on the targeted TPM 1.2. RPC 'tpm20-challenge-response-attestation': The receiver of the RPC response must verify that the certificate is for an active AK, i.e., the private key confirmation of the quote signature within the RPC response has been confirmed by a third party to belong to an entity legitimately able to perform Attestation on the targeted TPM 2.0. RPC 'log-retrieval': Requesting a large volume of logs from the attester could require significant system resources and create a denial of service. Information collected through the RPCs above could reveal that specific versions of software and configurations of endpoints that could identify vulnerabilities on those systems. Therefore, RPCs should be protected by NACM [RFC8341] with a default setting of deny- all to limit the extraction of attestation data by only authorized Verifiers. Birkholz, et al. Expires 19 November 2022 [Page 50] Internet-Draft YANG-CHARRA for TPMs May 2022 For the YANG module ietf-tcg-algs.yang, please use care when selecting specific algorithms. The introductory section of [TCG-Algos] highlights that some algorithms should be considered legacy, and recommends implementers and adopters diligently evaluate available information such as governmental, industrial, and academic research before selecting an algorithm for use. 5. References 5.1. Normative References [bios-log] "TCG PC Client Platform Firmware Profile Specification, Section 9.4.5.2", n.d., . [BIOS-Log-Event-Type] "TCG PC Client Platform Firmware Profile Specification", n.d., . [cel] "Canonical Event Log Format, Section 4.3", n.d., . [I-D.ietf-netconf-keystore] Watsen, K., "A YANG Data Model for a Keystore", Work in Progress, Internet-Draft, draft-ietf-netconf-keystore-24, 7 March 2022, . [I-D.ietf-rats-architecture] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture", Work in Progress, Internet-Draft, draft-ietf-rats-architecture- 15, 8 February 2022, . [I-D.ietf-rats-tpm-based-network-device-attest] Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- based Network Device Remote Integrity Verification", Work in Progress, Internet-Draft, draft-ietf-rats-tpm-based- network-device-attest-14, 22 March 2022, . Birkholz, et al. Expires 19 November 2022 [Page 51] Internet-Draft YANG-CHARRA for TPMs May 2022 [IEEE-Std-1363-2000] "IEEE 1363-2000 - IEEE Standard Specifications for Public- Key Cryptography", n.d., . [IEEE-Std-1363a-2004] "1363a-2004 - IEEE Standard Specifications for Public-Key Cryptography - Amendment 1: Additional Techniques", n.d., . [ISO-IEC-10116] "ISO/IEC 10116:2017 - Information technology", n.d., . [ISO-IEC-10118-3] "Dedicated hash-functions - ISO/IEC 10118-3:2018", n.d., . [ISO-IEC-14888-3] "ISO/IEC 14888-3:2018 - Digital signatures with appendix", n.d., . [ISO-IEC-15946-1] "ISO/IEC 15946-1:2016 - Information technology", n.d., . [ISO-IEC-18033-3] "ISO/IEC 18033-3:2010 - Encryption algorithms", n.d., . [ISO-IEC-9797-1] "Message Authentication Codes (MACs) - ISO/IEC 9797-1:2011", n.d., . [ISO-IEC-9797-2] "Message Authentication Codes (MACs) - ISO/IEC 9797-2:2011", n.d., . [NIST-PUB-FIPS-202] "SHA-3 Standard: Permutation-Based Hash and Extendable- Output Functions", n.d., . Birkholz, et al. Expires 19 November 2022 [Page 52] Internet-Draft YANG-CHARRA for TPMs May 2022 [NIST-SP800-108] "Recommendation for Key Derivation Using Pseudorandom Functions", n.d., . [NIST-SP800-38C] "Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality", n.d., . [NIST-SP800-38D] "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", n.d., . [NIST-SP800-38F] "Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping", n.d., . [NIST-SP800-56A] "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography", n.d., . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . Birkholz, et al. Expires 19 November 2022 [Page 53] Internet-Draft YANG-CHARRA for TPMs May 2022 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. Chandramouli, "Entity MIB (Version 4)", RFC 6933, DOI 10.17487/RFC6933, May 2013, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A YANG Data Model for Hardware Management", RFC 8348, DOI 10.17487/RFC8348, March 2018, . Birkholz, et al. Expires 19 November 2022 [Page 54] Internet-Draft YANG-CHARRA for TPMs May 2022 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [TCG-Algos] "TCG Algorithm Registry", n.d., . [TPM1.2] TCG, "TPM 1.2 Main Specification", 2 October 2003, . [TPM1.2-Commands] "TPM Main Part 3 Commands", n.d., . [TPM1.2-Structures] "TPM Main Part 2 TPM Structures", n.d., . [TPM2.0] TCG, "TPM 2.0 Library Specification", 15 March 2013, . [TPM2.0-Arch] "Trusted Platform Module Library - Part 1: Architecture", n.d., . [TPM2.0-Key] TCG, "TPM 2.0 Keys for Device Identity and Attestation, Rev12", 8 October 2021, . [TPM2.0-Structures] "Trusted Platform Module Library - Part 2: Structures", n.d., . [UEFI-Secure-Boot] "Unified Extensible Firmware Interface (UEFI) Specification Version 2.9 (March 2021), Section 32.1 Birkholz, et al. Expires 19 November 2022 [Page 55] Internet-Draft YANG-CHARRA for TPMs May 2022 (Secure Boot)", n.d., . 5.2. Informative References [I-D.ietf-rats-reference-interaction-models] Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference Interaction Models for Remote Attestation Procedures", Work in Progress, Internet-Draft, draft-ietf-rats- reference-interaction-models-05, 26 January 2022, . [IMA-Kernel-Source] "Linux Integrity Measurement Architecture (IMA): Kernel Sourcecode", n.d., . [NIST-915121] "True Randomness Can't be Left to Chance: Why entropy is important for information security", n.d., . [xml-registry] "IETF XML Registry", n.d., . [yang-parameters] "YANG Parameters", n.d., . Appendix A. Integrity Measurement Architecture (IMA) IMA extends the principles of Measured Boot [TPM2.0-Arch] and Secure Boot [UEFI-Secure-Boot] to the Linux operating system, applying it to operating system applications and files. IMA has been part of the Linux integrity subsystem of the Linux kernel since 2009 (kernel version 2.6.30). The IMA mechanism represented by the YANG module in this specification is rooted in the kernel version 5.16 [IMA-Kernel-Source]. IMA enables the protection of system integrity by collecting (commonly referred to as measuring) and storing measurements (called Claims in the context of IETF RATS) of files before execution so that these measurements can be used later, at Birkholz, et al. Expires 19 November 2022 [Page 56] Internet-Draft YANG-CHARRA for TPMs May 2022 system runtime, in remote attestation procedures. IMA acts in support of the appraisal of Evidence (which includes measurement Claims) by leveraging reference integrity measurements stored in extended file attributes. In support of the appraisal of Evidence, IMA maintains an ordered list of measurements in kernel-space, the Stored Measurement Log (SML), for all files that have been measured before execution since the operating system was started. Although IMA can be used without a TPM, it is typically used in conjunction with a TPM to anchor the integrity of the SML in a hardware-protected secure storage location, i.e., Platform Configuration Registers (PCRs) provided by TPMs. IMA provides the SML in both binary and ASCII representations in the Linux security file system _securityfs_ (/sys/kernel/security/ima/). IMA templates define the format of the SML, i.e., which fields are included in a log record. Examples are file path, file hash, user ID, group ID, file signature, and extended file attributes. IMA comes with a set of predefined template formats and also allows a custom format, i.e., a format consisting of template fields supported by IMA. Template usage is typically determined by boot arguments passed to the kernel. Alternatively, the format can also be hard- coded into custom kernels. IMA templates and fields are extensible in the kernel source code. As a result, more template fields can be added in the future. IMA policies define which files are measured using the IMA policy language. Built-in policies can be passed as boot arguments to the kernel. Custom IMA policies can be defined once during runtime or be hard-coded into a custom kernel. If no policy is defined, no measurements are taken and IMA is effectively disabled. A comprehensive description of the content fields ins in native Linux IMA TLV format can be found in Table 16 of the Canonical Event Log (CEL) specification [cel]. The CEL specification also illustrates the use of templates to enable extended or customized IMA TLV formats in Section 5.1.6. Appendix B. IMA for Network Equipment Boot Logs Network equipment can generally implement similar IMA-protected functions to generate measurements (Claims) about the boot process of a device and enable corresponding remote attestation. Network Equipment Boot Logs combine the measurement and logging of boot components and operating system components (executables and files) into a single log file in a format identical to the IMA format. Note that the format used for logging measurement of boot components in this scheme differs from the boot logging strategy described Birkholz, et al. Expires 19 November 2022 [Page 57] Internet-Draft YANG-CHARRA for TPMs May 2022 elsewhere in this document. During the boot process of the network device, i.e., from BIOS to the end of the operating system and user-space, all files executed can be measured and logged in the order of their execution. When the Verifier initiates a remote attestation process (e.g., challenge- response remote attestation as defined in this document), the network equipment takes on the role of an Attester and can convey to the Verifier Claims that comprise the measurement log as well as the corresponding PCR values (Evidence) of a TPM. The verifier can appraise the integrity (compliance with the Reference Values) of each executed file by comparing its measured value with the Reference Value. Based on the execution order, the Verifier can compute a PCR reference value (by replaying the log) and compare it to the Measurement Log Claims obtained in conjunction with the PCR Evidence to assess their trustworthiness with respect to an intended operational state. Network equipment usually executes multiple components in parallel. This holds not only during the operating system loading phase, but also even during the BIOS boot phase. With this measurement log mechanism, network equipment can take on the role of an Attester, proving to the Verifier the trustworthiness of its boot process. Using the measurement log, Verifiers can precisely identify mismatching log entries to infer potentially tampered components. This mechanism also supports scenarios that modify files on the Attester that are subsequently executed during the boot phase (e.g., updating/patching) by simply updating the appropriate Reference Values in Reference Integrity Manifests that inform Verifiers about how an Attester is composed. Authors' Addresses Henk Birkholz Fraunhofer SIT Rheinstrasse 75 64295 Darmstadt Germany Email: henk.birkholz@sit.fraunhofer.de Michael Eckel Fraunhofer SIT Rheinstrasse 75 64295 Darmstadt Germany Birkholz, et al. Expires 19 November 2022 [Page 58] Internet-Draft YANG-CHARRA for TPMs May 2022 Email: michael.eckel@sit.fraunhofer.de Shwetha Bhandari ThoughtSpot Email: shwetha.bhandari@thoughtspot.com Eric Voit Cisco Systems Email: evoit@cisco.com Bill Sulzen Cisco Systems Email: bsulzen@cisco.com Liang Xia (Frank) Huawei Technologies 101 Software Avenue, Yuhuatai District Nanjing Jiangsu, 210012 China Email: Frank.Xialiang@huawei.com Tom Laffey Hewlett Packard Enterprise Email: tom.laffey@hpe.com Guy C. Fedorkow Juniper Networks 10 Technology Park Drive Westford Email: gfedorkow@juniper.net Birkholz, et al. Expires 19 November 2022 [Page 59] ./draft-ietf-extra-imap-partial-04.txt0000644000764400076440000005137314350571572017373 0ustar iustiniustin Network Working Group A. Melnikov Internet-Draft Isode Updates: 5267, 4731 (if approved) A. P. Achuthan Intended status: Standards Track V. Nagulakonda Expires: 24 June 2023 Yahoo! L. Alves 21 December 2022 IMAP Paged SEARCH & FETCH Extension draft-ietf-extra-imap-partial-04 Abstract The PARTIAL extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) allows clients to limit the number of search results returned, as well as to perform incremental (paged) searches. This also helps servers to optimize resource usage when performing searches. This document extends PARTIAL SEARCH return option originally specified in RFC 5267. It also clarifies some interactions between RFC 5267 and RFC 4731/RFC 9051. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Melnikov, et al. Expires 24 June 2023 [Page 1] Internet-Draft IMAP PARTIAL December 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications 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 outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 3. The PARTIAL extension . . . . . . . . . . . . . . . . . . . . 3 3.1. Incremental SEARCH and partial results . . . . . . . . . 3 3.2. Interaction between PARTIAL, MIN, MAX and SAVE SEARCH return options . . . . . . . . . . . . . . . . . . . . . 5 3.3. Extension to UID FETCH . . . . . . . . . . . . . . . . . 6 3.4. Use of PARTIAL and CONDSTORE IMAP extensions together . . 7 4. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.1. Changes/additions to the IMAP4 capabilities registry . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction and Overview This document defines an extension to the Internet Message Access Protocol [RFC3501] for performing incremental searches and fetches. This extension is compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. Melnikov, et al. Expires 24 June 2023 [Page 2] Internet-Draft IMAP PARTIAL December 2022 The PARTIAL extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) allows clients to limit the number of search results returned, as well as to perform incremental (paged) searches. This also helps servers to optimize resource usage when performing searches. This document extends PARTIAL SEARCH return option originally specified in RFC 5267. It also clarifies some interactions between RFC 5267 and RFC 4731/RFC 9051. 2. Document Conventions In protocol examples, this document uses a prefix of "C: " to denote lines sent by the client to the server, and "S: " for lines sent by the server to the client. Lines prefixed with "// " are comments explaining the previous protocol line. These prefixes and comments are not part of the protocol. Lines without any of these prefixes are continuations of the previous line, and no line break is present in the protocol unless specifically mentioned. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Other capitalised words are IMAP keywords [RFC3501][RFC9051] or keywords from this document. 3. The PARTIAL extension An IMAP server advertises support for the PARTIAL extension by including the "PARTIAL" capability in the CAPABILITY response/ response code. 3.1. Incremental SEARCH and partial results The PARTIAL SEARCH return option causes the server to provide in an ESEARCH [RFC4731][RFC9051] response a subset of the results denoted by the sequence range given as the mandatory argument. The first result (message with the lowest matching UID) is 1; thus, the first 500 results would be obtained by a return option of "PARTIAL 1:500", and the second 500 by "PARTIAL 501:1000". This intentionally mirrors message sequence numbers. Melnikov, et al. Expires 24 June 2023 [Page 3] Internet-Draft IMAP PARTIAL December 2022 It is also possible to direct the server to start SEARCH from the latest matching (with the highest UID) message. This can be done by prepending "-" to the index. For example -1 is the last message, -2 is next to the last and so on. Using this syntax helps server implementations to optimize their SEARCHes. A single command MUST NOT contain more than one PARTIAL or ALL search return option -- that is, either one PARTIAL, one ALL, or neither PARTIAL nor ALL is allowed. For SEARCH results, the entire result list MUST be ordered in mailbox order, that is, in UID or message sequence number order. Where a PARTIAL SEARCH return option references results that do not exist, by using a range which starts or ends higher (or lower) than the current number of results, then the server returns the results that are in the set. This yields a PARTIAL return data item that has, as payload, the original range and a potentially missing set of results that may be shorter than the extent of the range. If the whole range references results that do not exist, a special value "NIL" is returned by the server instead of the sequence set. Clients need not request PARTIAL results in any particular order. Because mailboxes may change, clients might wish to use PARTIAL in combination with UPDATE (see [RFC5267]) if the server also advertises CONTEXT=SEARCH capability, especially if the intent is to walk a large set of results; however, these return options do not interact -- the UPDATE will provide notifications for all matching results. // Let's assume that the A01 SEARCH without PARTIAL would return // 23764 results. C: A01 UID SEARCH RETURN (PARTIAL -1:-100) UNDELETED UNKEYWORD $Junk S: * ESEARCH (TAG "A01") UID PARTIAL (-1:-100 ...) // 100 most recent results in set syntax elided. S: A01 OK Completed. Melnikov, et al. Expires 24 June 2023 [Page 4] Internet-Draft IMAP PARTIAL December 2022 // Let's assume that the A02 SEARCH without PARTIAL would return // 23764 results. C: A02 UID SEARCH RETURN (PARTIAL 23500:24000) UNDELETED UNKEYWORD $Junk C: A03 UID SEARCH RETURN (PARTIAL 1:500) UNDELETED UNKEYWORD $Junk C: A04 UID SEARCH RETURN (PARTIAL 24000:24500) UNDELETED UNKEYWORD $Junk S: * ESEARCH (TAG "A02") UID PARTIAL (23500:24000 ...) // 264 results in set syntax elided, // this spans the end of the results. S: A02 OK Completed. S: * ESEARCH (TAG "A03") UID PARTIAL (1:500 ...) // 500 results in set syntax elided. S: A03 OK Completed. S: * ESEARCH (TAG "A04") UID PARTIAL (24000:24500 NIL) // No results are present, this is beyond the end of the results. S: A04 OK Completed. 3.2. Interaction between PARTIAL, MIN, MAX and SAVE SEARCH return options This section only applies if the server advertises PARTIAL IMAP capability or CONTEXT=SEARCH [RFC5267], together with ESEARCH [RFC4731] and/or IMAP4rev2 [RFC9051]. The SAVE result option doesn't change whether the server would return items corresponding to PARTIAL SEARCH result options. As specified in Section 3.1, it is an error to specify both PARTIAL and ALL result options in the same SEARCH command. When the SAVE result option is combined with the PARTIAL result option, and none of MIN/MAX/COUNT result options is present, the corresponding PARTIAL is returned, and the "$" marker would contain all messages returned by the PARTIAL result option. When the SAVE and PARTIAL result options are combined with the MIN or the MAX result option, and the COUNT result option is absent, the corresponding PARTIAL result and MIN/MAX is returned (if the search result is not empty), and the "$" marker would contain all messages returned by the PARTIAL result option together with the corresponding MIN/MAX message. Melnikov, et al. Expires 24 June 2023 [Page 5] Internet-Draft IMAP PARTIAL December 2022 If the SAVE and PARTIAL result options are combined with both MIN and MAX result options, and the COUNT result options is absent, the PARTIAL, MIN and MAX are returned (if the search result is not empty), and the "$" marker would contain all messages returned by the PARTIAL result option together with the MIN and the MAX messages. If the SAVE and PARTIAL result options are combined with the COUNT result option, the PARTIAL and COUNT are returned, and the "$" marker would always contain all messages found by the SEARCH or UID SEARCH command. The following table summarizes the additional requirement on ESEARCH server implementations described in this section. +==============================+=====================+ | Combination of Result option | "$" marker value | +==============================+=====================+ | SAVE PARTIAL | PARTIAL | +------------------------------+---------------------+ | SAVE PARTIAL MIN | PARTIAL & MIN | +------------------------------+---------------------+ | SAVE PARTIAL MAX | PARTIAL & MAX | +------------------------------+---------------------+ | SAVE PARTIAL MIN MAX | PARTIAL & MIN & MAX | +------------------------------+---------------------+ | SAVE PARTIAL COUNT [m] | all found messages | +------------------------------+---------------------+ Table 1 Note for the table: '[m]' means optional "MIN" and/or "MAX" 3.3. Extension to UID FETCH The PARTIAL extension also extends the UID FETCH command with a PARTIAL FETCH modifier. The PARTIAL FETCH modifier has the same syntax as the PARTIAL SEARCH result option. Presence of the PARTIAL FETCH modifier instructs the server to only return FETCH results for messages in the specified range. It is useful when the sequence-set (first) parameter to the UID FETCH command includes unknown number of messages. // Returning information for the last 3 messages in the UID range C: 10 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL -1:-3) S: * 12888 FETCH (FLAGS (\Seen) UID 25996) S: * 12889 FETCH (FLAGS (\Flagged \Answered) UID 25997) S: * 12890 FETCH (FLAGS () UID 26600) S: 10 OK FETCH completed Melnikov, et al. Expires 24 June 2023 [Page 6] Internet-Draft IMAP PARTIAL December 2022 // Returning information for the first 5 messages in the UID range C: 11 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL 1:5) S: * 12591 FETCH (FLAGS (\Seen) UID 25900) S: * 12592 FETCH (FLAGS (\Flagged) UID 25902) S: * 12593 FETCH (FLAGS (\Answered) UID 26310) S: * 12594 FETCH (FLAGS () UID 26311) S: * 12595 FETCH (FLAGS (\Answered) UID 26498) S: 11 OK FETCH completed 3.4. Use of PARTIAL and CONDSTORE IMAP extensions together This section is informative. The PARTIAL FETCH modifier can be combined with the CHANGEDSINCE FETCH modifier. // Returning information for the last 30 messages in the UID range // that have any flag/keyword modified since modseq 98305 C: 101 UID FETCH 25900:26600 (UID FLAGS) (PARTIAL -1:-30 CHANGEDSINCE 98305) S: * 12888 FETCH (FLAGS (\Flagged \Answered) MODSEQ (98306) UID 25997) S: * 12890 FETCH (FLAGS () MODSEQ (98312) UID 26600) S: 101 OK FETCH completed The above example causes the server to first select the last 30 messages and then only return flag changes for subset of these messages which have MODSEQ higher than 98305. Note that the order of PARTIAL and CHANGEDSINCE FETCH modifiers in the UID FETCH command is not important, i.e. the above example can also use "UID FETCH 25900:26600 (UID FLAGS) (CHANGEDSINCE 98305 PARTIAL -1:-30)" command and it would result in the same responses. 4. Formal syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. Non-terminals referenced but not defined below are as defined by IMAP4rev1 [RFC3501] or IMAP4rev2 [RFC9051]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. Melnikov, et al. Expires 24 June 2023 [Page 7] Internet-Draft IMAP PARTIAL December 2022 SP = MINUS = "-" capability =/ "PARTIAL" ;; from [RFC3501] modifier-partial = "PARTIAL" SP partial-range partial-range-first = nz-number ":" nz-number ;; Request to search from oldest (lowest UIDs) to ;; more recent messages. ;; A range 500:400 is the same as 400:500. ;; This is similar to from [RFC3501], ;; but cannot contain "*". partial-range-last = MINUS nz-number ":" MINUS nz-number ;; Request to search from newest (highest UIDs) to ;; oldest messages. ;; A range -500:-400 is the same as -400:-500. partial-range = partial-range-first / partial-range-last search-return-opt =/ modifier-partial ;; All conform to , from [IMAP-ABNF]/[RFC9051] search-return-data =/ ret-data-partial ret-data-partial = "PARTIAL" SP "(" partial-range SP partial-results ")" ;; is the requested range. partial-results = sequence-set / "NIL" ;; from [RFC3501]. ;; NIL indicates no results correspond to the requested range. tagged-ext-simple =/ partial-range-last fetch-modifier =/ modifier-partial 5. Security Considerations This document defines an additional IMAP4 capability. As such, it does not change the underlying security considerations of [RFC3501] and IMAP4rev2 [RFC9051]. The authors and reviewers believe that no new security issues are introduced with these additional IMAP4 capabilities. Melnikov, et al. Expires 24 June 2023 [Page 8] Internet-Draft IMAP PARTIAL December 2022 This document defines an optimization that can both reduce the amount of work performed by the server, as well at the amount of data returned to the client. Use of this extension is likely to cause the server and the client to use less memory than when the extension is not used. However, as this is going to be new code in both the client and the server, rigorous testing of such code is required in order to avoid introducing of new implementation bugs. 6. IANA Considerations 6.1. Changes/additions to the IMAP4 capabilities registry IMAP4 capabilities are registered by publishing a standards track or IESG approved Informational or Experimental RFC. The registry is currently located at: https://www.iana.org/assignments/imap4-capabilities IANA is requested to add definition of the PARTIAL extension with RFC XXXX as the reference. 7. Acknowledgments This document was motivated by Yahoo! team and their questions about best client practices for dealing with large mailboxes. Editor of this document would like to thank the following people who provided useful comments or participated in discussions of this document: Timo Sirainen and Barry Leiba. This document uses lots of text from RFC 5267. Thus work of the RFC 5267 authors Dave Cridland and Curtis King is appreciated. 8. Normative References [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, . Melnikov, et al. Expires 24 June 2023 [Page 9] Internet-Draft IMAP PARTIAL December 2022 [RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, DOI 10.17487/RFC4731, November 2006, . [RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, DOI 10.17487/RFC5267, July 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message Access Protocol (IMAP) - Version 4rev2", RFC 9051, DOI 10.17487/RFC9051, August 2021, . Authors' Addresses Alexey Melnikov Isode Limited Email: alexey.melnikov@isode.com URI: https://www.isode.com Arun Prakash Achuthan Yahoo! Email: arunprakash@myyahoo.com Vikram Nagulakonda Yahoo! Email: nvikram_imap@yahoo.com Luis Alves Email: luis.alves@lafaspot.com Melnikov, et al. Expires 24 June 2023 [Page 10] ./draft-ietf-lsr-ospf-bfd-strict-mode-10.txt0000644000764400076440000006143614317563460020416 0ustar iustiniustin Link State Routing K. Talaulikar, Ed. Internet-Draft P. Psenak Updates: 2328 (if approved) Cisco Systems, Inc. Intended status: Standards Track A. Fu Expires: 9 April 2023 Bloomberg M. Rajesh Juniper Networks 6 October 2022 OSPF BFD Strict-Mode draft-ietf-lsr-ospf-bfd-strict-mode-10 Abstract This document specifies the extensions to OSPF that enable an OSPF router to signal the requirement for a Bidirectional Forwarding Detection (BFD) session prior to adjacency formation. Link-Local Signaling (LLS) is used to advertise the requirement for strict-mode BFD session establishment for an OSPF adjacency. If both OSPF neighbors advertise BFD strict-mode, adjacency formation will be blocked until a BFD session has been successfully established. This document updates RFC2328 by augmenting the OSPF neighbor state machine with a check for BFD session up before progression from Init to Two-Way state when operating in OSPF BFD strict-mode. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 9 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Talaulikar, et al. Expires 9 April 2023 [Page 1] Internet-Draft OSPF BFD Strict-Mode October 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. LLS B-bit Flag . . . . . . . . . . . . . . . . . . . . . . . 4 3. Local Interface IPv4 Address TLV . . . . . . . . . . . . . . 4 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. OSPFv3 IPv4 Address-Family Specifics . . . . . . . . . . 6 4.2. Graceful Restart Considerations . . . . . . . . . . . . . 7 5. Operations & Management Considerations . . . . . . . . . . . 7 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Bidirectional Forwarding Detection (BFD) [RFC5880] enables routers to monitor data-plane connectivity and to detect faults in the bidirectional path between them. BFD is leveraged by routing protocols like OSPFv2 [RFC2328] and OSPFv3 [RFC5340] to detect connectivity failures for established adjacencies faster than the OSPF hello dead timer detection and trigger rerouting of traffic around the failure. The use of BFD for monitoring routing protocol adjacencies is described in [RFC5882]. When BFD monitoring is enabled for OSPF adjacencies by the network operator, the BFD session is bootstrapped based on the neighbor address information discovered by the exchange of OSPF Hello packets. Faults in the bidirectional forwarding detected via BFD then result in the OSPF adjacency being brought down. A degraded or poor quality link may result in intermittent packet drops. In such scenarios, in implementations prior to the extensions specified in this document, an OSPF adjacency may still get established over such a link but given the more aggressive monitoring intervals supported by BFD, a Talaulikar, et al. Expires 9 April 2023 [Page 2] Internet-Draft OSPF BFD Strict-Mode October 2022 BFD session may not get established and/or may flap over it. The traffic that gets forwarded over such a link would experience packet drops and the failure of the BFD session establishment would not enable fast routing convergence. OSPF adjacency flaps may occur over such links as OSPF brings up the adjacency only for it to be brought down again by BFD. To avoid the routing churn associated with these scenarios, it would be beneficial to not allow OSPF to establish an adjacency until a BFD session is successfully established and has stabilized. However, this would preclude the OSPF operation in an environment where not all OSPF routers both support BFD and have it enabled on the link. A solution is to block OSPF adjacency establishment until a BFD session is established as long as both neighbors advertise such a requirement. Such a mode of OSPF BFD usage is referred to as "strict-mode". It introduces the signaling support in OSPF to achieve the blocking of adjacency formation until BFD session establishment as described in section 4.1 of [RFC5882]. This document specifies the OSPF protocol extensions using Link-Local Signaling (LLS) [RFC5613] for a router to indicate to its neighbor the willingness to require BFD strict-mode for OSPF adjacency establishment (refer to Section 2). It also introduces an extension for OSPFv3 Link-Local Signalling (LLS) of the interface IPv4 address (refer to Section 3) to be used for the BFD session setup when OSPFv3 is used for an IPv4 address-family (AF) instance. This document updates [RFC2328] by augmenting the OSPF neighbor state machine with a check for BFD session up before progression from Init to Two-Way state when operating in OSPF BFD strict-mode. The extensions and procedures for OSPF BFD strict-mode also apply for adjacency over virtual links using BFD multi-hop [RFC5883] procedures. A similar functionality for IS-IS is specified [RFC6213]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Talaulikar, et al. Expires 9 April 2023 [Page 3] Internet-Draft OSPF BFD Strict-Mode October 2022 2. LLS B-bit Flag This document defines the B-bit in the LLS Type 1 Extended Options and Flags field. This bit is defined for the LLS block included in Hello and Database Description (DD) packets and indicates that BFD is enabled on the link and that the router requests OSPF BFD strict- mode. Section 7 describes the position of the B-bit. A router MUST include the LLS block with the B-bit set in the LLS Type 1 Extended Options and Flags TLV in its Hello and DD packets when OSPF BFD strict-mode is enabled on the link. 3. Local Interface IPv4 Address TLV The Local Interface IPv4 Address TLV is an LLS TLV defined for OSPFv3 IPv4 AF instance [RFC5838] protocol operation as described in Section 4.1. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Interface IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 21 Length: 4 octets Local Interface IPv4 Address: The primary IPv4 address of the local interface. 4. Procedures A router supporting OSPF BFD strict-mode advertises this capability through its Hello packets as described in Section 2. When a router supporting OSPF BFD strict-mode discovers a new neighbor router that also supports OSPF BFD strict-mode, it will establish a BFD session first with that neighbor before bringing up the OSPF adjacency as described further in this section. Talaulikar, et al. Expires 9 April 2023 [Page 4] Internet-Draft OSPF BFD Strict-Mode October 2022 This document updates the OSPF neighbor state machine as described in [RFC2328]. Specifically, the operations related to the Init state are modified as below when OSPF BFD strict-mode is used: Init (without OSPF BFD strict-mode) In this state, a Hello packet has recently been received from the neighbor. However, bidirectional communication has not yet been established with the neighbor (i.e., the router itself did not appear in the neighbor's Hello packet). All neighbors in this state (or higher) are listed in the Hello packets sent from the associated interface. Init (with OSPF BFD strict-mode) In this state, a Hello packet has recently been received from the neighbor. However, bidirectional communication has not yet been established with the neighbor (i.e., the router itself did not appear in the neighbor's Hello packet). BFD session establishment with the neighbor is requested, if not already completed (e.g., in the event of transition from 2-way state). Neighbors in Init state or higher will be listed in Hello packets associated with the interface if they either have a corresponding BFD session established or have not advertised OSPF BFD strict-mode in the Hello packet LLS Extended Options and Flags. Whenever the neighbor state transitions to Down state, the removal of the BFD session associated with that neighbor is requested by OSPF and subsequent BFD session establishment is similarly requested by OSPF upon transitioning into Init state. This may result in the deletion and creation of the BFD session respectively when OSPF is the only client interested in the BFD session with the neighbor address. An implementation MUST NOT wait for BFD session establishment in Init state unless OSPF BFD strict-mode is enabled by the operator on the interface and the specific neighbor indicates OSPF BFD strict-mode capability via its Hello LLS options. When BFD is enabled, but OSPF BFD strict-mode has not been signaled by both neighbors, an implementation SHOULD start BFD session establishment only in 2-Way state or greater state. This makes it possible for an OSPF router to support BFD operation in both strict-mode and normal mode across different interfaces or even different neighbors on the same multi- access interface. Once the OSPF state machine has moved beyond the Init state, any change in the B-bit advertised in subsequent Hello packets MUST NOT result in any trigger in either the OSPF adjacency or the BFD session Talaulikar, et al. Expires 9 April 2023 [Page 5] Internet-Draft OSPF BFD Strict-Mode October 2022 management (i.e., the B-bit is considered only when in Init state). Disabling BFD (or OSPF BFD strict-mode) on an OSPF interface would result in it not setting the B-bit in its subsequent Hello LLS options. Disabling OSPF BFD strict-mode has no effect on BFD operations and would not result in bringing down of any established BFD sessions. Disabling BFD would result in the BFD session being brought down due to Admin reason [RFC5882] and hence would not bring down the OSPF adjacency. When BFD is enabled on an interface over which we already have an existing OSPF adjacency, it would result in the router setting the B-bit in its subsequent Hello packets and initiation of BFD session establishment to the neighbor. If the adjacency is already up (i.e., in its terminal state of Full or 2-way with non-DR routers on a multi-access interface) with a neighbor that also supports OSPF BFD strict-mode, then an implementation SHOULD NOT bring this adjacency down into the Init state to avoid disruption to routing operations and instead use the OSPF BFD strict-mode wait only after a transition to Init state. However, if the adjacency is not up, then an implementation MAY bring such an adjacency down so it can use the OSPF BFD strict-mode for its adjacency establishment. 4.1. OSPFv3 IPv4 Address-Family Specifics Multiple AF support in OSPFv3 [RFC5838] requires the use of an IPv6 link-local address as the source address for Hello packets even when forming adjacencies for IPv4 AF instances. In most deployments of OSPFv3 IPv4 AF, it is required that BFD is used to monitor and verify IPv4 data plane connectivity between the routers on the link and, hence, the BFD session is setup using IPv4 neighbor addresses. The IPv4 neighbor address on the interface is learned only later in the adjacency formation process when the neighbor's Link-LSA is received. This results in the setup of the BFD IPv4 session either after the adjacency is established or later in the adjacency formation sequence. To operate in OSPF BFD strict-mode, it is necessary for an OSPF router to learn its neighbor's IPv4 link address during the Init state of adjacency formation (ideally when it receives the first hello). The use of the Local Interface IPv4 Address TLV (as defined in Section 3) in the LLS block of OSPFv3 Hello packets for IPv4 AF instances makes this possible. Implementations that support OSPF BFD strict-mode for OSPFv3 IPv4 AF instances MUST include the Local Interface IPv4 Address TLV in the LLS block of their Hello packets whenever the B-bit is also set in the LLS Options and Flags field. A receiver MUST ignore the B-bit (i.e., not operate in strict mode for BFD) when the Local Interface IPv4 Address TLV is not present in OSPFv3 Hello messages for IPv4 AF OSPFv3 instances. Talaulikar, et al. Expires 9 April 2023 [Page 6] Internet-Draft OSPF BFD Strict-Mode October 2022 4.2. Graceful Restart Considerations An implementation needs to handle scenarios where both graceful restart (GR) and the OSPF BFD strict-mode are deployed together. The GR aspects discussed in section 3.3 of [RFC5882] also apply with OSPF BFD strict-mode. Additionally, in OSPF BFD strict-mode, since the OSPF adjacency formation is delayed until the BFD session establishment, the resultant delay in adjacency formation may affect or break the GR-based recovery. In such cases, it is RECOMMENDED that the GR timers are set such that they provide sufficient time to allow for normal BFD session establishment delays. 5. Operations & Management Considerations An implementation SHOULD report the BFD session status along with the OSPF Init adjacency state when OSPF BFD strict-mode is enabled and support logging operations on neighbor state transitions that include the BFD events. This allows an operator to detect scenarios where an OSPF adjacency may be stuck waiting for BFD session establishment. In network deployments with noisy or degraded links with intermittent packet loss, BFD sessions may flap resulting in OSPF adjacency flaps. This in turn may cause routing churn. The use of OSPF BFD strict- mode along with mechanisms such as hold-down (a delay in the initial OSPF adjacency bringup following BFD session establishment) and/or dampening (a delay in the OSPF adjacency bringup following failure detected by BFD) may help reduce the frequency of adjacency flaps and therefore reduce the associated routing churn. The details of these mechanisms are outside the scope of this document. [I-D.ietf-ospf-yang] specifies the base OSPF YANG model. The required configuration and operational elements for this feature are expected to be introduce as augmentation to this base OSPF YANG model. 6. Backward Compatibility An implementation MUST support OSPF adjacency formation and operations with a neighbor router that does not advertise the OSPF BFD strict-mode capability - both when that neighbor router does not support BFD and when it does support BFD but does not signal the OSPF BFD strict-mode as described in this document. Implementations MAY provide a local configuration option to force BFD operation only in OSPF BFD strict-mode (i.e, adjacency will not come up unless BFD session is established). In this case, an OSPF adjacency with a neighbor that does not support OSPF BFD strict-mode would not be established successfully. Implementations MAY provide a local configuration option to enable BFD without the OSPF BFD strict-mode Talaulikar, et al. Expires 9 April 2023 [Page 7] Internet-Draft OSPF BFD Strict-Mode October 2022 which results in the router not advertising the B-bit and BFD operation being performed in the same way as prior to this specification. The signaling specified in this document happens at a link-local level between routers on that link. A router that does not support this specification would ignore the B-bit in the LLS block of Hello packets from its neighbors and continue to establish BFD sessions, if enabled, without delaying the OSPF adjacency formation. Since a router that does not support this specification would not have set the B-bit in the LLS block of its own Hello packets, its neighbor routers supporting this specification would not use OSPF BFD strict- mode with such OSPF routers. As a result, the behavior would be the same as without this specification. Therefore, there are no backward compatibility issues or implementations considerations beyond what is specified herein. 7. IANA Considerations This specification makes the following updates under the "Open Shortest Path First (OSPF) Link Local Signaling (LLS) - Type/Length/ Value Identifiers (TLV)" parameters. IANA is requested to make permanent the following values that have been assigned via early allocation: o In the "LLS Type 1 Extended Options and Flags" registry, the B-bit is assigned the bit position 0x00000010 o In the "Link Local Signaling TLV Identifiers (LLS Types)" registry, the Type 21 is assigned to the Local Interface IPv4 Address TLV 8. Security Considerations The security considerations for "OSPF Link-Local Signaling" [RFC5613] also apply to the extension described in this document. Inappropriate use of the B-bit in the LLS block of an OSPF hello message could prevent an OSPF adjacency from forming or lead to failure to detect bidirectional forwarding failures. If authentication is being used in the OSPF routing domain [RFC5709][RFC7474], then the Cryptographic Authentication TLV [RFC5613] MUST also be used to protect the contents of the LLS block. Talaulikar, et al. Expires 9 April 2023 [Page 8] Internet-Draft OSPF BFD Strict-Mode October 2022 9. Acknowledgements The authors would like to acknowledge the review and inputs from Acee Lindem, Manish Gupta, Balaji Ganesh, Les Ginsberg, Robert Raszuk, Gyan Mishra, Muthu Arul Mozhi Perumal, Russ Housley, and Wes Hardaker. The authors would like to acknowledge Dylan van Oudheusden for highlighting the problems in using OSPF BFD strict-mode for BFD session for IPv4 AF instance with OSPFv3 and Baalajee S for his suggestions on the approach to address it. The authors would like to thank John Scudder for his AD review and suggestions to improve the document. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, DOI 10.17487/RFC5613, August 2009, . [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, DOI 10.17487/RFC5838, April 2010, . [RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, DOI 10.17487/RFC5882, June 2010, . Talaulikar, et al. Expires 9 April 2023 [Page 9] Internet-Draft OSPF BFD Strict-Mode October 2022 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [I-D.ietf-ospf-yang] Yeung, D., Qu, Y., Zhang, J., Chen, I., and A. Lindem, "YANG Data Model for OSPF Protocol", Work in Progress, Internet-Draft, draft-ietf-ospf-yang-29, 17 October 2019, . [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, DOI 10.17487/RFC5709, October 2009, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, June 2010, . [RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 6213, DOI 10.17487/RFC6213, April 2011, . [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, . Authors' Addresses Ketan Talaulikar (editor) Cisco Systems, Inc. India Email: ketant.ietf@gmail.com Talaulikar, et al. Expires 9 April 2023 [Page 10] Internet-Draft OSPF BFD Strict-Mode October 2022 Peter Psenak Cisco Systems, Inc. Apollo Business Center Mlynske nivy 43 821 09 Bratislava Slovakia Email: ppsenak@cisco.com Albert Fu Bloomberg United States of America Email: afu14@bloomberg.net Rajesh M Juniper Networks India Email: mrajesh@juniper.net Talaulikar, et al. Expires 9 April 2023 [Page 11] ./draft-ietf-i2nsf-applicability-18.txt0000644000764400076440000020666513537631242017547 0ustar iustiniustin I2NSF Working Group J. Jeong Internet-Draft Sungkyunkwan University Intended status: Informational S. Hyun Expires: March 18, 2020 Myongji University T. Ahn Korea Telecom S. Hares Huawei D. Lopez Telefonica I+D September 15, 2019 Applicability of Interfaces to Network Security Functions to Network- Based Security Services draft-ietf-i2nsf-applicability-18 Abstract This document describes the applicability of Interface to Network Security Functions (I2NSF) to network-based security services in Network Functions Virtualization (NFV) environments, such as firewall, deep packet inspection, or attack mitigation engines. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 18, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Jeong, et al. Expires March 18, 2020 [Page 1] Internet-Draft I2NSF Applicability September 2019 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, 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 of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 5 4. Time-dependent Web Access Control Service . . . . . . . . . . 8 5. Intent-based Security Services . . . . . . . . . . . . . . . 13 6. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 15 7. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 17 7.1. Firewall: Centralized Firewall System . . . . . . . . . . 19 7.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security System . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.3. Attack Mitigation: Centralized DDoS-attack Mitigation System . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . 26 Appendix A. Changes from draft-ietf-i2nsf-applicability-17 . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction Interface to Network Security Functions (I2NSF) defines a framework and interfaces for interacting with Network Security Functions (NSFs). Note that an NSF is defined as software that provides a set of security-related services, such as (i) detecting unwanted activity, (ii) blocking or mitigating the effect of such unwanted activity in order to fulfill service requirements, and (iii) supporting communication stream integrity and confidentiality [i2nsf-terminology]. The I2NSF framework allows heterogeneous NSFs developed by different security solution vendors to be used in the Network Functions Virtualization (NFV) environment [ETSI-NFV] by utilizing the capabilities of such NSFs through I2NSF interfaces such as Customer- Facing Interface [consumer-facing-inf-dm] and NSF-Facing Interface Jeong, et al. Expires March 18, 2020 [Page 2] Internet-Draft I2NSF Applicability September 2019 [nsf-facing-inf-dm]. In the I2NSF framework, each NSF initially registers the profile of its own capabilities with the Security Controller (i.e., network operator management system [RFC8329]) of the I2NSF system via the Registration Interface [registration-inf-dm]. This registration enables an I2NSF User (i.e., network security administrator) to select and use the NSF to enforce a given security policy. Note that Developer's Management System (DMS) is management software that provides a vendor's security service software as a Virtual Network Function (VNF) in an NFV environment (or middlebox in the legacy network) as an NSF, and registers the capabilities of an NSF into Security Controller via Registration Interface for a security service [RFC8329]. Security Controller maintains the mapping between a capability and an NSF, so it can perform to translate a high-level security policy received from I2NSF User to a low-level security policy configured and enforced in an NSF [policy-translation]. Security Controller can monitor the states and security attacks in NSFs through NSF monitoring [nsf-monitoring-dm]. This document illustrates the applicability of the I2NSF framework with five different scenarios: 1. The enforcement of time-dependent web access control. 2. The support of intent-based security services through I2NSF and Security Policy Translator [policy-translation]. 3. The application of I2NSF to a Service Function Chaining (SFC) environment [RFC7665]. 4. The integration of the I2NSF framework with Software-Defined Networking (SDN) [RFC7149] to provide different security functionality such as firewalls [opsawg-firewalls], Deep Packet Inspection (DPI), and Distributed Denial of Service (DDoS) attack mitigation. 5. The use of Network Functions Virtualization (NFV) [ETSI-NFV] as a supporting technology. The implementation of I2NSF in these scenarios has allowed us to verify the applicability and effectiveness of the I2NSF framework for a variety of use cases. Jeong, et al. Expires March 18, 2020 [Page 3] Internet-Draft I2NSF Applicability September 2019 2. Terminology This document uses the terminology described in [RFC7665], [RFC7149], [ITU-T.Y.3300], [ONF-SDN-Architecture], [ITU-T.X.800], [NFV-Terminology], [RFC8329], and [i2nsf-terminology]. In addition, the following terms are defined below: o Centralized DDoS-attack Mitigation System: A centralized mitigator that can establish and distribute access control policy rules into network resources for efficient DDoS-attack mitigation. o Centralized Firewall System: A centralized firewall that can establish and distribute policy rules into network resources for efficient firewall management. o Centralized VoIP Security System: A centralized security system that handles the security functions required for VoIP and VoLTE services. o Firewall: A service function at the junction of two network segments that inspects some suspicious packets that attempt to cross the boundary. It also rejects any packet that does not satisfy certain criteria for, for example, disallowed port numbers or IP addresses. o Network Function: A functional block within a network infrastructure that has well-defined external interfaces and well- defined functional behavior [NFV-Terminology]. o Network Functions Virtualization (NFV): A principle of separating network functions (or network security functions) from the hardware they run on by using virtual hardware abstraction [NFV-Terminology]. o Network Security Function (NSF): Software that provides a set of security-related services. Examples include detecting unwanted activity and blocking or mitigating the effect of such unwanted activity in order to fulfill service requirements. The NSF can also help in supporting communication stream integrity and confidentiality [i2nsf-terminology]. o Security Policy Translator (SPT): Software that translates a high- level security policy for the Consumer-Facing Interface into a low-level security policy for the NSF-Facing Interface [policy-translation]. The SPT is a core part of the Security Controller in the I2NSF system. Jeong, et al. Expires March 18, 2020 [Page 4] Internet-Draft I2NSF Applicability September 2019 o Service Function Chaining (SFC): The execution of an ordered set of abstract service functions (i.e., network functions) according to ordering constraints that must be applied to packets, frames, and flows selected as a result of classification. The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied [RFC7665]. o Software-Defined Networking (SDN): A set of techniques that enables to directly program, orchestrate, control, and manage network resources, which facilitates the design, delivery and operation of network services in a dynamic and scalable manner [ITU-T.Y.3300]. +------------+ | I2NSF User | +------------+ ^ | Consumer-Facing Interface v +-------------------+ Registration +-----------------------+ |Security Controller|<-------------------->|Developer's Mgmt System| +-------------------+ Interface +-----------------------+ ^ | NSF-Facing Interface v +----------------+ +---------------+ +-----------------------+ | NSF-1 |-| NSF-2 |...| NSF-n | | (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)| +----------------+ +---------------+ +-----------------------+ Figure 1: I2NSF Framework 3. I2NSF Framework This section summarizes the I2NSF framework as defined in [RFC8329]. As shown in Figure 1, an I2NSF User can use security functions by delivering high-level security policies, which specify security requirements that the I2NSF user wants to enforce, to the Security Controller via the Consumer-Facing Interface (CFI) [consumer-facing-inf-dm]. The Security Controller receives and analyzes the high-level security policies from an I2NSF User, and identifies what types of security capabilities are required to meet these high-level security policies. The Security Controller then identifies NSFs that have the required security capabilities, and generates low-level security policies for Jeong, et al. Expires March 18, 2020 [Page 5] Internet-Draft I2NSF Applicability September 2019 each of the NSFs so that the high-level security policies are eventually enforced by those NSFs [policy-translation]. Finally, the Security Controller sends the generated low-level security policies to the NSFs via the NSF-Facing Interface (NFI) [nsf-facing-inf-dm]. As shown in Figure 1, with a Developer's Management System (called DMS), developers (or vendors) inform the Security Controller of the capabilities of the NSFs through the Registration Interface (RI) [registration-inf-dm] for registering (or deregistering) the corresponding NSFs. Note that the lifecycle management of NSF code from DMS (e.g., downloading of NSF modules and testing of NSF code) is out of scope for I2NSF. The Consumer-Facing Interface can be implemented with the Consumer- Facing Interface YANG data model [consumer-facing-inf-dm] using RESTCONF [RFC8040] which befits a web-based user interface for an I2NSF User to send a Security Controller a high-level security policy. Data models specified by YANG [RFC6020] describe high-level security policies to be specified by an I2NSF User. The data model defined in [consumer-facing-inf-dm] can be used for the I2NSF Consumer-Facing Interface. Note that an inside attacker at the I2NSF User can misuse the I2NSF system so that the network system under the I2NSF system is vulnerable to security attacks. To handle this type of threat, the Security Controller needs to monitor the activities of all the I2NSF Users as well as the NSFs through the I2NSF NSF monitoring functionality [nsf-monitoring-dm]. Note that the monitoring of the I2NSF Users is out of scope for I2NSF. The NSF-Facing Interface can be implemented with the NSF-Facing Interface YANG data model [nsf-facing-inf-dm] using NETCONF [RFC6241] which befits a command-line-based remote-procedure call for a Security Controller to configure an NSF with a low-level security policy. Data models specified by YANG [RFC6020] describe low-level security policies for the sake of NSFs, which are translated from the high-level security policies by the Security Controller. The data model defined in [nsf-facing-inf-dm] can be used for the I2NSF NSF- Facing Interface. The Registration Interface can be implemented with the Registration Interface YANG data model [registration-inf-dm] using NETCONF [RFC6241] which befits a command-line-based remote-procedure call for a DMS to send a Security Controller an NSF's capability information. Data models specified by YANG [RFC6020] describe the registration of an NSF's capabilities to enforce security services at the NSF. The data model defined in [registration-inf-dm] can be used for the I2NSF Registration Interface. Jeong, et al. Expires March 18, 2020 [Page 6] Internet-Draft I2NSF Applicability September 2019 The I2NSF framework can chain multiple NSFs to implement low-level security policies with the SFC architecture [RFC7665]. The following sections describe different security service scenarios illustrating the applicability of the I2NSF framework. block_website block_website_during_working_hours 09:00 18:00 Staff_Members'_PCs SNS_Websites drop Figure 2: A High-level Security Policy XML File for Time-based Web Filter Jeong, et al. Expires March 18, 2020 [Page 7] Internet-Draft I2NSF Applicability September 2019 block_website block_website_during_working_hours 09:00 18:00 2001:DB8:10:1::10 2001:DB8:10:1::20 2001:DB8:10:1::30 example1.com example2.com example3.com example4.com drop Figure 3: A Low-level Security Policy XML File for Time-based Web Filter 4. Time-dependent Web Access Control Service This service scenario assumes that an enterprise network administrator wants to control the staff members' access to a particular Internet service (e.g., social networking service (SNS)) during business hours. The following is an example high-level Jeong, et al. Expires March 18, 2020 [Page 8] Internet-Draft I2NSF Applicability September 2019 security policy rule for a web filter that the administrator requests: Block the staff members' access to SNS websites from 9 AM (i.e., 09:00) to 6 PM (i.e., 18:00) by dropping their packets. Figure 2 is a high-level security policy XML code for the web filter that is sent from the I2NSF User to the Security Controller via the Consumer-Facing Interface [consumer-facing-inf-dm]. The security policy name is "block_website" with the tag "policy- name", and the security policy rule name is "block_website_during_working_hours" with the tag "rule-name". The filtering event has the time span where the filtering begin time is the time "09:00" (i.e., 9:00AM) with the tag "begin-time", and the filtering end time is the time "18:00" (i.e., 6:00PM) with the tag "end-time". The filtering condition has the source target of "Staff_Members'_PCs" with the tag "src-target", and the destination target of "SNS_Websites" with the tag "dest-target". Assume that "Staff_Members'_PCs" are 2001:DB8:10:1::10, 2001:DB8:10:1::20, and 2001:DB8:10:1::30, and that "SNS_Websites" are example1.com, example2.com, example3.com, and example4.com, as shown in Figure 3. Note that Figure 3 is a low-level security policy XML code for the web filter that is sent from the Security Controller to an NSF via the NSF-Facing Interface [nsf-facing-inf-dm]. The source target can by translated by the Security Policy Translator (SPT) in the Security Controller to the IP addresses of computers (or mobile devices) used by the staff members. Refer to Section 5 for the detailed description of the SPT. The destination target can also be translated by the SPT to the actual websites corresponding to the symbolic website name "SNS_Websites", and then either each website's URL or the corresponding IP address(es) can be used by both firewall and web filter. The action is to "drop" the packets satisfying the above event and condition with the tag "primary-action". After receiving the high-level security policy, the Security Controller identifies required security capabilities, e.g., IP address and port number inspection capabilities and URL inspection capability. In this scenario, it is assumed that the IP address and port number inspection capabilities are required to check whether a received packet is an HTTP-session packet from a staff member, which is part of an HTTP session generated by the staff member. The URL inspection capability is required to check whether the target URL of a received packet is one of the target websites (i.e., example1.com, example2.com, example3.com, and example4.com) or not. The Security Controller maintains the security capabilities of each active NSF in the I2NSF system, which have been reported by the Developer's Management System via the Registration interface. Based Jeong, et al. Expires March 18, 2020 [Page 9] Internet-Draft I2NSF Applicability September 2019 on this information, the Security Controller identifies NSFs that can perform the IP address and port number inspection and URL inspection through the security policy translation in Section 5. In this scenario, it is assumed that a firewall NSF has the IP address and port number inspection capabilities and a web filter NSF has URL inspection capability. The Security Controller generates a low-level security policy for the NSFs to perform IP address and port number inspection, URL inspection, and time checking, which is shown in Figure 3. Specifically, the Security Controller may interoperate with an access control server in the enterprise network in order to retrieve the information (e.g., IP address in use, company identifier (ID), and role) of each employee that is currently using the network. Based on the retrieved information, the Security Controller generates a low- level security policy to check whether the source IP address of a received packet matches any one being used by a staff member. In addition, the low-level security policy's rule (shortly, low-level security rule) should be able to determine that a received packet uses either the HTTP protocol without Transport Layer Security (TLS) [RFC8446] or the HTTP protocol with TLS as HTTPS. The low-level security rule for web filter checks that the target URL field of a received packet is equal to one of the target SNS websites (i.e., example1.com, example2.com, example3.com, and example4.com), or that the destination IP address of a received packet is an IP address corresponding to one of the SNS websites. Note that if HTTPS is used for an HTTP-session packet, the HTTP protocol header is encrypted, so the URL information may not be seen from the packet for the web filtering. Thus, the IP address(es) corresponding to the target URL needs to be obtained from the certificate in TLS versions prior to 1.3 [RFC8446] or the Server Name Indication (SNI) in a TCP-session packet in TLS versions without the encrypted SNI [tls-esni]. Also, to obtain IP address(es) corresponding to a target URL, the DNS name resolution process can be observed through a packet capturing tool because the DNS name resolution will translate the target URL into IP address(es). The IP addresses obtained through either TLS or DNS can be used by both firewall and web filter for whitelisting or blacklisting the TCP five-tuples of HTTP sessions. Finally, the Security Controller sends the low-level security policy of the IP address and port number inspection to the firewall NSF and the low-level security policy for URL inspection to the web filter NSF. The following describes how the time-dependent web access control service is enforced by the NSFs of firewall and web filter. Jeong, et al. Expires March 18, 2020 [Page 10] Internet-Draft I2NSF Applicability September 2019 1. A staff member tries to access one of the target SNS websites (i.e., example1.com, example2.com, example3.com, and example4.com) during business hours, e.g., 10 AM. 2. The packet is forwarded from the staff member's device to the firewall, and the firewall checks the source IP address and port number. Now the firewall identifies the received packet is an HTTP-session packet from the staff member. 3. The firewall triggers the web filter to further inspect the packet, and the packet is forwarded from the firewall to the web filter. The SFC architecture [RFC7665] can be utilized to support such packet forwarding in the I2NSF framework. 4. The web filter checks the received packet's target URL field or its destination IP address corresponding to the target URL, and detects that the packet is being sent to the server for example1.com. The web filter then checks that the current time is within business hours. If so, the web filter drops the packet, and consequently the staff member's access to one of the SNS websites (i.e., example1.com, example2.com, example3.com, and example4.com) during business hours is blocked. Jeong, et al. Expires March 18, 2020 [Page 11] Internet-Draft I2NSF Applicability September 2019 +------------------------+-------------------------+ | | | I2NSF User | | | +------------------------+-------------------------+ | Consumer-Facing Interface | High-level Security Policy Security | Controller V +------------------------+-------------------------+ | Security Policy | | | Translator | | | +---------------------+----------------------+ | | | | | | | | +-------+--------+ | | | | | Data Extractor | | | | | +-------+--------+ | | | | | Extracted Data from | | | | V High-level Policy | | | | +-------+--------+ +------+ | | | | | Data Converter |<-->|NSF DB| | | | | +-------+--------+ +------+ | | | | | Required Data for | | | | V Target NSFs | | | | +-------+--------+ | | | | |Policy Generator| | | | | +-------+--------+ | | | | | | | | +---------------------+----------------------+ | | | | +------------------------+-------------------------+ | NSF-Facing Interface | Low-level Security Policy | V +------------------------+-------------------------+ | | | NSF(s) | | | +------------------------+-------------------------+ Figure 4: Security Policy Translation and Enforcement in I2NSF System Jeong, et al. Expires March 18, 2020 [Page 12] Internet-Draft I2NSF Applicability September 2019 5. Intent-based Security Services I2NSF aims at providing intent-based security services to configure specific security policies into NSFs with customer-friendly secuirty policies at a high level. For example, when an I2NSF User submits a high-level security policy (e.g., web filtering as shown in Figure 2) to the Security Controller, the Security Policy Tranlator (SPT) in the Security Controller will translate it into the correspondong low- level security policy as shown in Figure 3 [policy-translation]. A security administrator using the I2NSF User can describe a security policy without the knowledge of the detailed information about subjects (e.g., source and destination) and objects (e.g., web traffic) of the security policy's rule(s). Figure 4 shows the security policy translation and enforcement in the I2NSF system [policy-translation]. As shown in Figure 4, an I2NSF User delivers a high-level security policy to the Security Controller using the Consumer-Facing Interface (denoted as CFI). The high-level security policy is translated by the SPT in the Security Controller into the corresponding low-level security policy which is understandable by target NSF(s). The Security Controller delivers the low-level security policy to the appropriate NSF(s) to enforce the policy's rules. The SPT consists of three modules for security policy translations such as Data Extractor, Data Converter, and Policy Generator, as shown in Figure 4. The Data Extractor extracts data from a high- level security policy delivered by the I2NSF User. The data correspond to the leaf nodes in the YANG data model for the Consumer- Facing Interface. In the high-level policy in Figure 2, the data are the tag values of policy-name, rule-name, begin-time, end-time, src- target, dest-target, and primary-action. That is, the tag values are "block_website", "block_website_during_working_hours", "09:00", "18:00", "Staff_Members'_PCs", "SNS_Websites", and "drop." The Data Converter converts the extracted high-level policy data received from the Data Extractor into the corresponding low-level policy data. The low-level policy data have the capability information of NSFs to be selected as target NSFs for the required security service enforcement specified by the high-level security policy. The tag values in the extracted high-level policy data are replaced with the tag values in the low-level policy data, which are the leaf nodes of the YANG data model for the NSF-Facing Interface (denoted as NFI). The value of each leaf node in CFI is translated into the value of the corresponding leaf node in NFI. For example, "block_website" of policy-name in CFI (in Figure 2) is translated into "block_website" of system-policy-name in NFI (in Figure 3). The tag values of rule-name, begin-time, end-time, and primary-action in Jeong, et al. Expires March 18, 2020 [Page 13] Internet-Draft I2NSF Applicability September 2019 CFI are mapped into the same values of rule-name, begin-time, end- time, and egress-action in NFI. However, the tag values of src- target and dest-target in CFI are translated into IP addresses and URLs, respectively, for the sake of NFI. That is, "Staff_Members'_PCs" of CFI is translated into three IPv6 addresses such as "2001:DB8:10:1::10", "2001:DB8:10:1::20", and "2001:DB8:10:1::30" for the sake of NFI. Also, "SNS_Websites" of CFI is translated into four URLs such as "example1.com", "example2.com", "example3.com", and "example4.com" for the sake of NFI. In addition to the data conversion, the Data Converter searches for appropriate NSFs having capabilities corresponding to the leaf nodes of the YANG data model for NFI. For the data conversion and NSF search, an NSF database (denoted as NSF DB) can be consulted, as shown in Figure 4, because the NSF DB has the capability information of NSFs that the DMS(s) registered with the Security Controller using the Registration Interface. The Policy Generator generates a low-level security policy corresponding to the low-level policy data made by the Data Converter per a target NSF. That is, the Policy Generator can build such a low-level security policy XML file like Figure 3 with the NSF DB because the NSF DB has the mapping information between the CFI YANG data model and the NFI YANG data model. Therefore, by allowing the I2NSF User to express its security policy without knowing the detailed information of entities for security policies, the I2NSF can efficiently support the intent-based security services with the help of the security policy translator along with the NSF DB. Jeong, et al. Expires March 18, 2020 [Page 14] Internet-Draft I2NSF Applicability September 2019 +------------+ | I2NSF User | +------------+ ^ | Consumer-Facing Interface v +-------------------+ Registration +-----------------------+ |Security Controller|<-------------------->|Developer's Mgmt System| +-------------------+ Interface +-----------------------+ ^ ^ | | NSF-Facing Interface | |------------------------- | | | NSF-Facing Interface | +-----v-----------+ +------v-------+ | +-----------+ | ------>| NSF-1 | | |Classifier | | | | (Firewall) | | +-----------+ | | +--------------+ | +-----+ |<-----| +--------------+ | | SFF | | |----->| NSF-2 | | +-----+ | | | (DPI) | +-----------------+ | +--------------+ | . | . | . | +-----------------------+ ------>| NSF-n | |(DDoS-Attack Mitigator)| +-----------------------+ Figure 5: An I2NSF Framework with SFC 6. I2NSF Framework with SFC In the I2NSF architecture, an NSF can trigger an advanced security action (e.g., DPI or DDoS attack mitigation) on a packet based on the result of its own security inspection of the packet. For example, a firewall triggers further inspection of a suspicious packet with DPI. For this advanced security action to be fulfilled, the suspicious packet should be forwarded from the current NSF to the successor NSF. SFC [RFC7665] is a technology that enables this advanced security action by steering a packet with multiple service functions (e.g., NSFs), and this technology can be utilized by the I2NSF architecture to support the advanced security action. Figure 5 shows an I2NSF framework with the support of SFC. As shown in the figure, SFC generally requires classifiers and service function forwarders (SFFs); classifiers are responsible for Jeong, et al. Expires March 18, 2020 [Page 15] Internet-Draft I2NSF Applicability September 2019 determining which service function path (SFP) (i.e., an ordered sequence of service functions) a given packet should pass through, according to pre-configured classification rules, and SFFs perform forwarding the given packet to the next service function (e.g., NSF) on the SFP of the packet by referring to their forwarding tables. In the I2NSF architecture with SFC, the Security Controller can take responsibilities of generating classification rules for classifiers and forwarding tables for SFFs. By analyzing high-level security policies from I2NSF users, the Security Controller can construct SFPs that are required to meet the high-level security policies, generates classification rules of the SFPs, and then configures classifiers with the classification rules over NSF-Facing Interface so that relevant traffic packets can follow the SFPs. Also, based on the global view of NSF instances available in the system, the Security Controller constructs forwarding tables, which are required for SFFs to forward a given packet to the next NSF over the SFP, and configures SFFs with those forwarding tables over NSF-Facing Interface. To trigger an advanced security action in the I2NSF architecture, the current NSF appends metadata describing the security capability required to the suspicious packet via a network service header (NSH) [RFC8300]. It then sends the packet to the classifier. Based on the metadata information, the classifier searches an SFP which includes an NSF with the required security capability, changes the SFP-related information (e.g., service path identifier and service index [RFC8300]) of the packet with the new SFP that has been found, and then forwards the packet to the SFF. When receiving the packet, the SFF checks the SFP-related information such as the service path identifier and service index contained in the packet and forwards the packet to the next NSF on the SFP of the packet, according to its forwarding table. Jeong, et al. Expires March 18, 2020 [Page 16] Internet-Draft I2NSF Applicability September 2019 +------------+ | I2NSF User | +------------+ ^ | Consumer-Facing Interface v +-------------------+ Registration +-----------------------+ |Security Controller|<-------------------->|Developer's Mgmt System| +-------------------+ Interface +-----------------------+ ^ ^ | | NSF-Facing Interface | v | +----------------+ +---------------+ +-----------------------+ | | NSF-1 |-| NSF-2 |...| NSF-n | | | (Firewall) | | (DPI) | |(DDoS-Attack Mitigator)| | +----------------+ +---------------+ +-----------------------+ | | | SDN Network +--|----------------------------------------------------------------+ | V NSF-Facing Interface | | +----------------+ | | | SDN Controller | | | +----------------+ | | ^ | | | SDN Southbound Interface | | v | | +--------+ +------------+ +--------+ +--------+ | | |Switch-1|-| Switch-2 |-|Switch-3|.......|Switch-m| | | | | |(Classifier)| | (SFF) | | | | | +--------+ +------------+ +--------+ +--------+ | +-------------------------------------------------------------------+ Figure 6: An I2NSF Framework with SDN Network 7. I2NSF Framework with SDN This section describes an I2NSF framework with SDN for I2NSF applicability and use cases, such as firewall, deep packet inspection, and DDoS-attack mitigation functions. SDN enables some packet filtering rules to be enforced in network forwarding elements (e.g., switch) by controlling their packet forwarding rules. By taking advantage of this capability of SDN, it is possible to optimize the process of security service enforcement in the I2NSF system. For example, for efficient firewall services, simple packet filtering can be performed by SDN forwarding elements (e.g., switches), and complicated packet filtering based on packet payloads can be performed by a firewall NSF. This optimized firewall using Jeong, et al. Expires March 18, 2020 [Page 17] Internet-Draft I2NSF Applicability September 2019 both SDN forwarding elements and a firewall NSF is more efficient than a firewall where SDN forwarding elements forward all the packets to a firewall NSF for packet filtering. This is because packets to be filtered out can be early dropped by SDN forwarding elements without consuming further network bandwidth due to the forwarding of the packets to the firewall NSF. Figure 6 shows an I2NSF framework [RFC8329] with SDN networks to support network-based security services. In this system, the enforcement of security policy rules is divided into the SDN forwarding elements (e.g., a switch running as either a hardware middle box or a software virtual switch) and NSFs (e.g., a firewall running in a form of a VNF [ETSI-NFV]). Note that NSFs are created or removed by the NFV Management and Orchestration (MANO) [ETSI-NFV-MANO], performing the lifecycle management of NSFs as VNFs. Refer to Section 8 for the detailed discussion of the NSF lifecycle management in the NFV MANO for I2NSF. For security policy enforcement (e.g., packet filtering), the Security Controller instructs the SDN Controller via NSF-Facing Interface so that SDN forwarding elements can perform the required security services with flow tables under the supervision of the SDN Controller. As an example, let us consider two different types of security rules: Rule A is a simple packet filtering rule that checks only the IP address and port number of a given packet, whereas rule B is a time- consuming packet inspection rule for analyzing whether an attached file being transmitted over a flow of packets contains malware. Rule A can be translated into packet forwarding rules of SDN forwarding elements and thus be enforced by these elements. In contrast, rule B cannot be enforced by forwarding elements, but it has to be enforced by NSFs with anti-malware capability. Specifically, a flow of packets is forwarded to and reassembled by an NSF to reconstruct the attached file stored in the flow of packets. The NSF then analyzes the file to check the existence of malware. If the file contains malware, the NSF drops the packets. In an I2NSF framework with SDN, the Security Controller can analyze given security policy rules and automatically determine which of the given security policy rules should be enforced by SDN forwarding elements and which should be enforced by NSFs. If some of the given rules requires security capabilities that can be provided by SDN forwarding elements, then the Security Controller instructs the SDN Controller via NSF-Facing Interface so that SDN forwarding elements can enforce those security policy rules with flow tables under the supervision of the SDN Controller. Or if some rules require security capabilities that cannot be provided by SDN forwarding elements but by NSFs, then the Security Controller instructs relevant NSFs to enforce those rules. Jeong, et al. Expires March 18, 2020 [Page 18] Internet-Draft I2NSF Applicability September 2019 The distinction between software-based SDN forwarding elements and NSFs, which can both run as VNFs, may be necessary for some management purposes in this system. Note that an SDN forwarding element (i.e., switch) is a specific type of VNF rather than an NSF because an NSF is for security services rather than for packet forwarding. For this distinction, we can take advantage of the NFV MANO where there is a subsystem that maintains the descriptions of the capabilities each VNF can offer [ETSI-NFV-MANO]. This subsystem can determine whether a given software element (VNF instance) is an NSF or a virtualized SDN switch. For example, if a VNF instance has anti-malware capability according to the description of the VNF, it could be considered as an NSF. A VNF onboarding system [VNF-ONBOARDING] can be used as such a subsystem that maintains the descriptions of each VNF to tell whether a VNF instance is for an NSF or for a virtualized SDN switch. For the support of SFC in the I2NSF framework with SDN, as shown in Figure 6, network forwarding elements (e.g., switch) can play the role of either SFC Classifier or SFF, which are explained in Section 6. Classifier and SFF have an NSF-Facing Interface with Security Controller. This interface is used to update security service function chaining information for traffic flows. For example, when it needs to update an SFP for a traffic flow in an SDN network, as shown in Figure 6, SFF (denoted as Switch-3) asks Security Controller to update the SFP for the traffic flow (needing another security service as an NSF) via NSF-Facing Interface. This update lets Security Controller ask Classifier (denoted as Switch-2) to update the mapping between the traffic flow and SFP in Classifier via NSF-Facing Interface. The following subsections introduce three use cases from [RFC8192] for cloud-based security services: (i) firewall system, (ii) deep packet inspection system, and (iii) attack mitigation system. 7.1. Firewall: Centralized Firewall System A centralized network firewall can manage each network resource and apply common rules to individual network elements (e.g., switch). The centralized network firewall controls each forwarding element, and firewall rules can be added or deleted dynamically. A time-based firewall can be enforced with packet filtering rules and a time span (e.g., work hours). With this time-based firewall, a time-based security policy can be enforced, as explained in Section 4. For example, employees at a company are allowed to access social networking service websites during lunch time or after work hours. Jeong, et al. Expires March 18, 2020 [Page 19] Internet-Draft I2NSF Applicability September 2019 7.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security System A centralized VoIP/VoLTE security system can monitor each VoIP/VoLTE flow and manage VoIP/VoLTE security rules, according to the configuration of a VoIP/VoLTE security service called VoIP Intrusion Prevention System (IPS). This centralized VoIP/VoLTE security system controls each switch for the VoIP/VoLTE call flow management by manipulating the rules that can be added, deleted or modified dynamically. The centralized VoIP/VoLTE security system can cooperate with a network firewall to realize VoIP/VoLTE security service. Specifically, a network firewall performs the basic security check of an unknown flow's packet observed by a switch. If the network firewall detects that the packet is an unknown VoIP call flow's packet that exhibits some suspicious patterns, then it triggers the VoIP/VoLTE security system for more specialized security analysis of the suspicious VoIP call packet. 7.3. Attack Mitigation: Centralized DDoS-attack Mitigation System A centralized DDoS-attack mitigation can manage each network resource and configure rules to each switch for DDoS-attack mitigation (called DDoS-attack Mitigator) on a common server. The centralized DDoS- attack mitigation system defends servers against DDoS attacks outside the private network, that is, from public networks [RFC8612][dots-architecture]. Servers are categorized into stateless servers (e.g., DNS servers) and stateful servers (e.g., web servers). For DDoS-attack mitigation, the forwarding of traffic flows in switches can be dynamically configured such that malicious traffic flows are handled by the paths separated from normal traffic flows in order to minimize the impact of those malicious traffic on the servers. This flow path separation can be done by a flow forwarding path management scheme [dots-architecture][AVANT-GUARD]. This management should consider the load balance among the switches for the defense against DDoS attacks. So far this section has described the three use cases for network- based security services using the I2NSF framework with SDN networks. To support these use cases in the proposed data-driven security service framework, YANG data models described in [consumer-facing-inf-dm], [nsf-facing-inf-dm], and [registration-inf-dm] can be used as Consumer-Facing Interface, NSF- Facing Interface, and Registration Interface, respectively, along with RESTCONF [RFC8040] and NETCONF [RFC6241]. Jeong, et al. Expires March 18, 2020 [Page 20] Internet-Draft I2NSF Applicability September 2019 +--------------------+ +-------------------------------------------+ | ---------------- | | I2NSF User (OSS/BSS) | | | NFV | | +------+------------------------------------+ | | Orchestrator +-+ | | Consumer-Facing Interface | -----+---------- | | +------|------------------------------------+ | | | | | -----+---------- (a) ----------------- | | ----+----- | | | | Security +-------+ Developer's | | | | | | | | |Controller(EM)| |Mgmt System(EM)| +-(b)-+ VNFM(s)| | | | -----+---------- ----------------- | | | | | | | | NSF-Facing Interface | | ----+----- | | | ----+----- ----+----- ----+----- | | | | | | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| | | | | | | ----+----- ----+----- ----+----- | | | | | | | | | | | | | | +------|-------------|-------------|--------+ | | | | | | | | | | | +------+-------------+-------------+--------+ | | | | | NFV Infrastructure (NFVI) | | | | | | ----------- ----------- ----------- | | | | | | | Virtual | | Virtual | | Virtual | | | | | | | | Compute | | Storage | | Network | | | | | | | ----------- ----------- ----------- | | ----+----- | | | +---------------------------------------+ | | | | | | | | Virtualization Layer | +-----+ VIM(s) +------+ | | +---------------------------------------+ | | | | | | +---------------------------------------+ | | ---------- | | | ----------- ----------- ----------- | | | | | | | Compute | | Storage | | Network | | | | | | | | Hardware| | Hardware| | Hardware| | | | | | | ----------- ----------- ----------- | | | | | | Hardware Resources | | | NFV Management | | +---------------------------------------+ | | and Orchestration | | | | (MANO) | +-------------------------------------------+ +--------------------+ (a) = Registration Interface (b) = Ve-Vnfm Interface Figure 7: I2NSF Framework Implementation with respect to the NFV Reference Architectural Framework 8. I2NSF Framework with NFV This section discusses the implementation of the I2NSF framework using Network Functions Virtualization (NFV). NFV is a promising technology for improving the elasticity and efficiency of network resource utilization. In NFV environments, Jeong, et al. Expires March 18, 2020 [Page 21] Internet-Draft I2NSF Applicability September 2019 NSFs can be deployed in the forms of software-based virtual instances rather than physical appliances. Virtualizing NSFs makes it possible to rapidly and flexibly respond to the amount of service requests by dynamically increasing or decreasing the number of NSF instances. Moreover, NFV technology facilitates flexibly including or excluding NSFs from multiple security solution vendors according to the changes on security requirements. In order to take advantages of the NFV technology, the I2NSF framework can be implemented on top of an NFV infrastructure as show in Figure 7. Figure 7 shows an I2NSF framework implementation based on the NFV reference architecture that the European Telecommunications Standards Institute (ETSI) defines [ETSI-NFV]. The NSFs are deployed as VNFs in Figure 7. The Developer's Management System (DMS) in the I2NSF framework is responsible for registering capability information of NSFs into the Security Controller. However, those NSFs are created or removed by a virtual network function manager (VNFM) in the NFV MANO that performs the lifecycle management of VNFs. Note that the lifecycle management of VNFs is out of scope for I2NSF. The Security Controller controls and monitors the configurations (e.g., function parameters and security policy rules) of VNFs via the NSF-Facing Interface along with the NSF monitoring capability [nsf-facing-inf-dm][nsf-monitoring-dm]. Both the DMS and Security Controller can be implemented as the Element Managements (EMs) in the NFV architecture. Finally, the I2NSF User can be implemented as OSS/ BSS (Operational Support Systems/Business Support Systems) in the NFV architecture that provides interfaces for users in the NFV system. The operation procedure in the I2NSF framework based on the NFV architecture is as follows: 1. The VNFM has a set of virtual machine (VM) images of NSFs, and each VM image can be used to create an NSF instance that provides a set of security capabilities. The DMS initially registers a mapping table of the ID of each VM image and the set of capabilities that can be provided by an NSF instance created from the VM image into the Security Controller. 2. If the Security Controller does not have any instantiated NSF that has the set of capabilities required to meet the security requirements from users, it searches the mapping table (registered by the DMS) for the VM image ID corresponding to the required set of capabilities. 3. The Security Controller requests the DMS to instantiate an NSF with the VM image ID via VNFM. Jeong, et al. Expires March 18, 2020 [Page 22] Internet-Draft I2NSF Applicability September 2019 4. When receiving the instantiation request, the VNFM first asks the NFV orchestrator for the permission required to create the NSF instance, requests the VIM to allocate resources for the NSF instance, and finally creates the NSF instance based on the allocated resources. 5. Once the NSF instance has been created by the VNFM, the DMS performs the initial configurations of the NSF instance and then notifies the Security Controller of the NSF instance. 6. After being notified of the created NSF instance, the Security Controller delivers low-level security policy rules to the NSF instance for policy enforcement. We can conclude that the I2NSF framework can be implemented based on the NFV architecture framework. Note that the registration of the capabilities of NSFs is performed through the Registration Interface and the lifecycle management for NSFs (VNFs) is performed through the Ve-Vnfm interface between the DMS and VNFM, as shown in Figure 7. 9. Security Considerations The same security considerations for the I2NSF framework [RFC8329] are applicable to this document. This document shares all the security issues of SDN that are specified in the "Security Considerations" section of [ITU-T.Y.3300]. The role of the DMS is to provide an I2NSF system with the software packages or images for NSF execution. The DMS must not access NSFs in activated status. An inside attacker or a supply chain attacker at the DMS can seriously weaken the I2NSF system's security. A malicious DMS is relevant to an insider attack, and a compromised DMS is relevant to a supply chain attack. A malicious (or compromised) DMS could register an NSF of its choice in response to a capability request by the Security Controller. As a result, a malicious DMS can attack the I2NSF system by providing malicious NSFs with arbitrary capabilities to include potentially controlling those NSFs in real time. An unwitting DMS could be compromised and the infrastructure of the DMS could be coerced into distributing modified NSFs as well. To deal with these types of threats, an I2NSF system should not use NSFs from an untrusted DMS or without prior testing. The practices by which these packages are downloaded and loaded into the system are out of scope for I2NSF. I2NSF system operators should audit and monitor interactions with DMSs. Additionally, the operators should monitor the running NSFs Jeong, et al. Expires March 18, 2020 [Page 23] Internet-Draft I2NSF Applicability September 2019 through the I2NSF NSF Monitoring Interface [nsf-monitoring-dm] as part of the I2NSF NSF-Facing Interface. Note that the mechanics for monitoring the DMSs are out of scope for I2NSF. 10. Acknowledgments This work was supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based Security Intelligence Technology Development for the Customized Security Service Provisioning). This work has been partially supported by the European Commission under Horizon 2020 grant agreement no. 700199 "Securing against intruders and other threats through a NFV-enabled environment (SHIELD)". This support does not imply endorsement. 11. Contributors I2NSF is a group effort. I2NSF has had a number of contributing authors. The following are considered co-authors: o Hyoungshick Kim (Sungkyunkwan University) o Jinyong Tim Kim (Sungkyunkwan University) o Hyunsik Yang (Soongsil University) o Younghan Kim (Soongsil University) o Jung-Soo Park (ETRI) o Se-Hui Lee (Korea Telecom) o Mohamed Boucadair (Orange) 12. References 12.1. Normative References [AVANT-GUARD] Shin, S., Yegneswaran, V., Porras, P., and G. Gu, "AVANT- GUARD: Scalable and Vigilant Switch Flow Management in Software-Defined Networks", ACM CCS, November 2013. Jeong, et al. Expires March 18, 2020 [Page 24] Internet-Draft I2NSF Applicability September 2019 [consumer-facing-inf-dm] Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, "I2NSF Consumer-Facing Interface YANG Data Model", draft- ietf-i2nsf-consumer-facing-interface-dm-06 (work in progress), July 2019. [dots-architecture] Mortensen, A., Reddy, T., Andreasen, F., Teague, N., and R. Compton, "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", draft-ietf-dots- architecture-14 (work in progress), May 2019. [ETSI-NFV] "Network Functions Virtualisation (NFV); Architectural Framework", Available: https://www.etsi.org/deliver/etsi_gs/ nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf, October 2013. [ITU-T.Y.3300] "Framework of Software-Defined Networking", Available: https://www.itu.int/rec/T-REC-Y.3300-201406-I, June 2014. [NFV-Terminology] "Network Functions Virtualisation (NFV); Terminology for Main Concepts in NFV", Available: https://www.etsi.org/deliver/etsi_gs/ NFV/001_099/003/01.02.01_60/gs_nfv003v010201p.pdf, December 2014. [nsf-facing-inf-dm] Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, "I2NSF Network Security Function-Facing Interface YANG Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-07 (work in progress), July 2019. [nsf-monitoring-dm] Jeong, J., Chung, C., Hares, S., Xia, L., and H. Birkholz, "I2NSF NSF Monitoring YANG Data Model", draft-ietf-i2nsf- nsf-monitoring-data-model-01 (work in progress), July 2019. [ONF-SDN-Architecture] "SDN Architecture (Issue 1.1)", Available: https://www.opennetworking.org/wp- content/uploads/2014/10/TR- 521_SDN_Architecture_issue_1.1.pdf, June 2016. Jeong, et al. Expires March 18, 2020 [Page 25] Internet-Draft I2NSF Applicability September 2019 [registration-inf-dm] Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF Registration Interface YANG Data Model", draft-ietf-i2nsf- registration-interface-dm-05 (work in progress), July 2019. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, March 2014. [RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, October 2015. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, January 2017. [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., and J. Jeong, "Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases", RFC 8192, July 2017. [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service Header (NSH)", RFC 8300, January 2018. [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, February 2018. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018. [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open Threat Signaling (DOTS) Requirements", RFC 8612, May 2019. 12.2. Informative References Jeong, et al. Expires March 18, 2020 [Page 26] Internet-Draft I2NSF Applicability September 2019 [ETSI-NFV-MANO] "Network Functions Virtualisation (NFV); Management and Orchestration", Available: https://www.etsi.org/deliver/etsi_gs/nfv- man/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf, December 2014. [i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Birkholz, "Interface to Network Security Functions (I2NSF) Terminology", draft-ietf-i2nsf-terminology-08 (work in progress), July 2019. [ITU-T.X.800] "Security Architecture for Open Systems Interconnection for CCITT Applications", March 1991. [opsawg-firewalls] Baker, F. and P. Hoffman, "On Firewalls in Internet Security", draft-ietf-opsawg-firewalls-01 (work in progress), October 2012. [policy-translation] Jeong, J., Yang, J., Chung, C., and J. Kim, "Security Policy Translation in Interface to Network Security Functions", draft-yang-i2nsf-security-policy- translation-04 (work in progress), July 2019. [tls-esni] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "Encrypted Server Name Indication for TLS 1.3", draft- ietf-tls-esni-04 (work in progress), July 2019. [VNF-ONBOARDING] "VNF Onboarding", Available: https://wiki.opnfv.org/display/mano/VNF+Onboarding, November 2016. Jeong, et al. Expires March 18, 2020 [Page 27] Internet-Draft I2NSF Applicability September 2019 Appendix A. Changes from draft-ietf-i2nsf-applicability-17 The following changes have been made from draft-ietf-i2nsf- applicability-17: o In Section 4, a high-level security policy XML file in Figure 2 and the corresponding low-level security policy XML file Figure 3 are constructed using the Consumer-Facing Interface data model and the NSF-Facing data model, respectively. o For the applicability of I2NSF to the real world, Section 5 is added to support the Intent-based Security Services using I2NSF. This section explains the security policy translation based on an I2NSF User's intents on the required security services. Figure 4 shows the archiecture and procedure of the I2NSF security policy translator. Authors' Addresses Jaehoon Paul Jeong Department of Computer Science and Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4957 Fax: +82 31 290 7996 EMail: pauljeong@skku.edu URI: http://iotlab.skku.edu/people-jaehoon-jeong.php Sangwon Hyun Department of Computer Engineering Myongji University 116 Myongji-ro, Cheoin-gu Yongin 17058 Republic of Korea Phone: +82 62 230 7473 EMail: shyun@chosun.ac.kr Jeong, et al. Expires March 18, 2020 [Page 28] Internet-Draft I2NSF Applicability September 2019 Tae-Jin Ahn Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon 305-811 Republic of Korea Phone: +82 42 870 8409 EMail: taejin.ahn@kt.com Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA Phone: +1-734-604-0332 EMail: shares@ndzh.com Diego R. Lopez Telefonica I+D Jose Manuel Lara, 9 Seville 41013 Spain Phone: +34 682 051 091 EMail: diego.r.lopez@telefonica.com Jeong, et al. Expires March 18, 2020 [Page 29] ./draft-ietf-ipsecme-iptfs-19.txt0000644000764400076440000024526514305111365016443 0ustar iustiniustin Network Working Group C. Hopps Internet-Draft LabN Consulting, L.L.C. Intended status: Standards Track 4 September 2022 Expires: 8 March 2023 IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security draft-ietf-ipsecme-iptfs-19 Abstract This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in ESP payloads. This new payload type can be used for various purposes such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IPsec traffic flow security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well as non- constant send-rate usage. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 March 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Hopps Expires 8 March 2023 [Page 1] Internet-Draft IP Traffic Flow Security September 2022 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology & Concepts . . . . . . . . . . . . . . . . . 4 2. The AGGFRAG Tunnel . . . . . . . . . . . . . . . . . . . . . 4 2.1. Tunnel Content . . . . . . . . . . . . . . . . . . . . . 5 2.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. End Padding . . . . . . . . . . . . . . . . . . . . . 7 2.2.3. Fragmentation, Sequence Numbers and All-Pad Payloads . . . . . . . . . . . . . . . . . . . . . . 7 2.2.4. Empty Payload . . . . . . . . . . . . . . . . . . . . 9 2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 9 2.2.6. IPv4 Time-To-Live (TTL), IPv6 Hop Limit, and ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 10 2.2.7. Effective MTU of the Tunnel . . . . . . . . . . . . . 11 2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 11 2.4. Modes of Operation . . . . . . . . . . . . . . . . . . . 11 2.4.1. Non-Congestion-Controlled Mode . . . . . . . . . . . 11 2.4.2. Congestion-Controlled Mode . . . . . . . . . . . . . 12 2.5. Summary of Receiver Processing . . . . . . . . . . . . . 14 3. Congestion Information . . . . . . . . . . . . . . . . . . . 15 3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 16 4. Configuration of AGGFRAG Tunnels for IP-TFS . . . . . . . . . 16 4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 17 4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 17 5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. USE_AGGFRAG Notification Message . . . . . . . . . . . . 17 6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 18 6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 18 6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format . . . . . . . . . . . . . . . . . . . . . . . 18 6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 19 6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 21 6.1.4. IKEv2 USE_AGGFRAG Notification Message . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7.1. ESP Next Header Value . . . . . . . . . . . . . . . . . . 24 7.2. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 24 7.3. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 25 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 8.1. Reference Implementation - VPP + Strongswan . . . . . . . 26 Hopps Expires 8 March 2023 [Page 2] Internet-Draft IP Traffic Flow Security September 2022 8.2. In Progress Linux Kernel Implementation. . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . 28 Appendix A. Example of An Encapsulated IP Packet Flow . . . . . 30 Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 31 Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 32 C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 32 C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 32 C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 33 C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 33 C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 34 C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 34 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 36 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction Traffic Analysis ([RFC4301], [AppCrypt]) is the act of extracting information about data being sent through a network. While directly obscuring the data with encryption [RFC4303], the patterns in the message traffic may expose information due to variations in its shape and timing ([RFC8546], [AppCrypt]). Hiding the size and frequency of traffic is referred to as Traffic Flow Confidentiality (TFC) per [RFC4303]. [RFC4303] provides for TFC by allowing padding to be added to encrypted IP packets and allowing for transmission of all-pad packets (indicated using protocol 59). This method has the major limitation that it can significantly under-utilize the available bandwidth. This document defines an aggregation and fragmentation (AGGFRAG) mode for ESP, and its use for IP Traffic Flow Security (IP-TFS). This solution provides for full TFC without the aforementioned bandwidth limitation. This is accomplished by using a constant-send-rate IPsec [RFC4303] tunnel with fixed-sized encapsulating packets; however, these fixed-sized packets can contain partial, whole or multiple IP packets to maximize the bandwidth of the tunnel. A non-constant send-rate is allowed, but the confidentiality properties of its use are outside the scope of this document. For a comparison of the overhead of IP-TFS with the RFC4303 prescribed TFC solution see Appendix C. Hopps Expires 8 March 2023 [Page 3] Internet-Draft IP Traffic Flow Security September 2022 Additionally, IP-TFS provides for operating fairly within congested networks [RFC2914]. This is important for when the IP-TFS user is not in full control of the domain through which the IP-TFS tunnel path flows. The mechanisms, such as the AGGFRAG mode, defined in this document are generic with the intent of allowing for non-TFS uses, but such uses are outside the scope of this document. 1.1. Terminology & Concepts The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document assumes familiarity with IP security concepts including TFC as described in [RFC4301]. 2. The AGGFRAG Tunnel As mentioned in Section 1, AGGFRAG mode utilizes an IPsec [RFC4303] tunnel as its transport. For the purpose of IP-TFS, fixed-sized encapsulating packets are sent at a constant rate on the AGGFRAG tunnel. The primary input to the tunnel algorithm is the requested bandwidth to be used by the tunnel. Two values are then required to provide for this bandwidth use, the fixed size of the encapsulating packets, and rate at which to send them. The fixed packet size MAY either be specified manually or be determined through other methods such as the Packetization Layer MTU Discovery (PLMTUD) ([RFC4821], [RFC8899]) or Path MTU discovery (PMTUD) ([RFC1191], [RFC8201]). PMTUD is known to have issues so PLMTUD is considered the more robust option. For PLMTUD, congestion control payloads can be used as in-band probes (see Section 6.1.2 and [RFC8899]). Given the encapsulating packet size and the requested bandwidth to be used, the corresponding packet send rate can be calculated. The packet send rate is the requested bandwidth to be used divided by the size of the encapsulating packet. Hopps Expires 8 March 2023 [Page 4] Internet-Draft IP Traffic Flow Security September 2022 The egress (receiving) side of the AGGFRAG tunnel MUST allow for and expect the ingress (sending) side of the AGGFRAG tunnel to vary the size and rate of sent encapsulating packets, unless constrained by other policy. 2.1. Tunnel Content As previously mentioned, one issue with the TFC padding solution in [RFC4303] is the large amount of wasted bandwidth as only one IP packet can be sent per encapsulating packet. In order to maximize bandwidth, IP-TFS breaks this one-to-one association by introducing an AGGFRAG mode for ESP. AGGFRAG mode aggregates as well as fragments the inner IP traffic flow into encapsulating IPsec tunnel packets. For IP-TFS, the IPsec encapsulating tunnel packets are a fixed size. Padding is only added to the tunnel packets if there is no data available to be sent at the time of tunnel packet transmission, or if fragmentation has been disabled by the receiver. This is accomplished using a new Encapsulating Security Payload (ESP, [RFC4303]) Next Header field value AGGFRAG_PAYLOAD (Section 6.1). Other non-IP-TFS uses of this AGGFRAG mode have been suggested, such as increased performance through packet aggregation, as well as handling MTU issues using fragmentation. These uses are not defined here, but are also not restricted by this document. 2.2. Payload Content The AGGFRAG_PAYLOAD payload content defined in this document consists of a 4 or 24 octet header followed by either a partial datablock, a full datablock, or multiple partial or full datablocks. The following diagram illustrates this payload within the ESP packet. See Section 6.1 for the exact formats of the AGGFRAG_PAYLOAD payload. Hopps Expires 8 March 2023 [Page 5] Internet-Draft IP Traffic Flow Security September 2022 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outer Encapsulating Header ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ESP Header... . +---------------------------------------------------------------+ | [AGGFRAG sub-type/flags] : BlockOffset | +---------------------------------------------------------------+ : [Optional Congestion Info] : +---------------------------------------------------------------+ | DataBlocks ... ~ ~ ~ ~ | +---------------------------------------------------------------| . ESP Trailer... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 1: Layout of an AGGFRAG mode IPsec Packet The BlockOffset value is either zero or some offset into or past the end of the DataBlocks data. If the BlockOffset value is zero it means that the DataBlocks data begins with a new data block. Conversely, if the BlockOffset value is non-zero it points to the start of the new data block, and the initial DataBlocks data belongs to the data block that is still being re-assembled. If the BlockOffset points past the end of the DataBlocks data then the next data block occurs in a subsequent encapsulating packet. Having the BlockOffset always point at the next available data block allows for recovering the next inner packet in the presence of outer encapsulating packet loss. An example AGGFRAG mode packet flow can be found in Appendix A. 2.2.1. Data Blocks +---------------------------------------------------------------+ | Type | rest of IPv4, IPv6 or pad. +-------- Figure 2: Layout of a DataBlock A data block is defined by a 4-bit type code followed by the data block data. The type values have been carefully chosen to coincide with the IPv4/IPv6 version field values so that no per-data block Hopps Expires 8 March 2023 [Page 6] Internet-Draft IP Traffic Flow Security September 2022 type overhead is required to encapsulate an IP packet. Likewise, the length of the data block is extracted from the encapsulated IPv4's Total Length or IPv6's Payload Length fields. 2.2.2. End Padding Since a data block's type is identified in its first 4-bits, the only time padding is required is when there is no data to encapsulate. For this end padding a Pad Data Block is used. 2.2.3. Fragmentation, Sequence Numbers and All-Pad Payloads In order for a receiver to reassemble fragmented inner packets, the sender MUST send the inner packet fragments back-to-back in the logical outer packet stream (i.e., using consecutive ESP sequence numbers). However, the sender is allowed to insert "all-pad" payloads (i.e., payloads with a BlockOffset of zero and a single pad DataBlock) in between the packets carrying the inner packet fragment payloads. This interleaving of all-pad payloads allows the sender to always send a tunnel packet, regardless of the encapsulation computational requirements. When a receiver is reassembling an inner packet, and it receives an "all-pad" payload, it increments the expected sequence number that the next inner packet fragment is expected to arrive in. Given the above, the receiver will need to handle out-of-order arrival of outer ESP packets prior to reassembly processing. ESP already provides for optionally detecting replay attacks. Detecting replay attacks normally utilizes a window method. A similar sequence number based sliding window can be used to correct re-ordering of the outer packet stream. Receiving a larger (newer) sequence number packet advances the window, and received older ESP packets whose sequence numbers the window has passed by are dropped. A good choice for the size of this window depends on the amount of misordering the user is experiencing; however, a value of 3 has been suggested as a default when no more informed choice exists. As the amount of misordering that may be present is hard to predict, the window size SHOULD be configurable by the user. Implementations MAY also dynamically adjust the reordering window based on actual misordering seen in arriving packets. Please note, when IP-TFS sends a continuous stream of packets, there is no requirement for an explicit lost packet timer; however, using a lost packet timer is RECOMMENDED. If an implementation does not use a lost packet timer and only considers an outer packet lost when the reorder window moves by it, the inner traffic can be delayed by up to Hopps Expires 8 March 2023 [Page 7] Internet-Draft IP Traffic Flow Security September 2022 the reorder window size times the per packet send rate. This delay could be significant for slower send rates or when larger reorder window sizes are in use. As the lost packet timer affects delay of inner packet delivery, an implementation or user could choose to set it proportionate to the tunnel rate. While ESP guarantees an increasing sequence number with subsequently sent packets, it does not actually require the sequence numbers to be generated consecutively (e.g., sending only even numbered sequence numbers would be allowed as long as they are always increasing). Gaps in the sequence numbers will not work for this document so the sequence number stream MUST increase monotonically by 1 for each subsequent packet. When using the AGGFRAG_PAYLOAD in conjunction with replay detection, the window size for both MAY be reduced to the smaller of the two window sizes. This is because packets outside of the smaller window but inside the larger would still be dropped by the mechanism with the smaller window size. However, there is also no requirement to make these values the same. Indeed, in some cases, such as slow tunnels where a very small or zero reorder window size is appropriate, the user may still want a large replay detection window to log replayed packets. Additionally, large replay windows can be implemented with very little overhead compared to large reorder windows. Finally, as sequence numbers are reset when switching SAs (e.g., when re-keying a child SA), senders MUST NOT send initial fragments of an inner packet using one SA and subsequent fragments in a different SA. A note on BlockOffset values, senders MUST encode the BlockOffset consistent with the immediately preceding non-all-pad payload packet. Specifically, if the immediately preceding non-all-pad payload packet ended with a Pad Data Block, this BlockOffset MUST be zero, as Pad Data Blocks are never fragmented. The BlockOffset MUST be consistent with the remaining size implied by the native length encoding of the fragmented inner packet. 2.2.3.1. Optional Extra Padding When the tunnel bandwidth is not being fully utilized, a sender MAY pad-out the current encapsulating packet in order to deliver an inner packet un-fragmented in the following outer packet. The benefit would be to avoid inner packet fragmentation in the presence of a bursty offered load (non-bursty traffic will naturally not fragment). Senders MAY also choose to allow for a minimum fragment size to be configured (e.g., as a percentage of the AGGFRAG_PAYLOAD payload size) to avoid fragmentation at the cost of tunnel bandwidth. The Hopps Expires 8 March 2023 [Page 8] Internet-Draft IP Traffic Flow Security September 2022 cost with these methods is complexity and added delay of inner traffic. The main advantage to avoiding fragmentation is to minimize inner packet loss in the presence of outer packet loss. When this is worthwhile (e.g., how much loss and what type of loss is required, given different inner traffic shapes and utilization, for this to make sense), and what values to use for the allowable/added delay may be worth researching but is outside the scope of this document. While use of padding to avoid fragmentation does not impact interoperability, used inappropriately it can reduce the effective throughput of a tunnel. Senders implementing either of the above approaches will need to take care to not reduce the effective capacity, and overall utility, of the tunnel through the overuse of padding. 2.2.4. Empty Payload To support reporting of congestion control information (described later) using a non-AGGFRAG_PAYLOAD-enabled SA, it is allowed to send an AGGFRAG_PAYLOAD payload with no data blocks (i.e., the ESP payload length is equal to the AGGFRAG_PAYLOAD header length). This special payload is called an empty payload. Currently this situation is only applicable in non-IKEv2 use cases. 2.2.5. IP Header Value Mapping [RFC4301] provides some direction on when and how to map various values from an inner IP header to the outer encapsulating header, namely the Don't-Fragment (DF) bit ([RFC0791] and [RFC8200]), the Differentiated Services (DS) field [RFC2474] and the Explicit Congestion Notification (ECN) field [RFC3168]. Unlike [RFC4301], AGGFRAG mode may and often will be encapsulating more than one IP packet per ESP packet. To deal with this, these mappings are restricted further. 2.2.5.1. DF bit AGGFRAG mode never maps the inner DF bit as it is unrelated to the AGGFRAG tunnel functionality; AGGFRAG mode never needs to IP fragment the inner packets and the inner packets will not affect the fragmentation of the outer encapsulation packets. Hopps Expires 8 March 2023 [Page 9] Internet-Draft IP Traffic Flow Security September 2022 2.2.5.2. ECN value The ECN value need not be mapped as any congestion related to the constant-send-rate IP-TFS tunnel is unrelated (by design) to the inner traffic flow. The sender MAY still set the ECN value of inner packets based on the normal ECN specification [RFC3168], [RFC4301] and [RFC6040]. 2.2.5.3. DS field By default, the DS field SHOULD NOT be copied, although a sender MAY choose to allow for configuration to override this behavior. A sender SHOULD also allow the DS value to be set by configuration. 2.2.6. IPv4 Time-To-Live (TTL), IPv6 Hop Limit, and ICMP Messages [RFC4301] specifies how to modify the inner packet IPv4 TTL [RFC0791] or IPv6 Hop Limit [RFC8200]. [RFC4301] also specifies how to apply policy to authenticated and unauthenticated ICMP error packets (e.g., Destination Unreachable) arriving at or being forwarded through the endpoint. In particular, whether to process, ignore or forward said packets. With one exception this document does not change the handling of these packets, they should be handled as specified in [RFC4301]. The one way in which an AGGFRAG tunnel differs in ICMP error packet mechanics is with PMTU. When fragmentation is enabled on the AGGFRAG tunnel, then no ICMP "too-big" errors need to be generated for arriving ingress traffic as the arriving inner packets will be naturally fragmented by the AGGFRAG encapsultation. Otherwise, when fragmentation has been disabled on the AGGFRAG tunnel, then the treatment of arriving inner traffic exactly maps to that of a non-AGGFRAG ESP tunnel. Explicitly, IPv4 with DF set and IPv6 packets which cannot fit in it's own outer packet payload will generate the appropriate ICMP "too-big" error as directed by [RFC4301], and IPv4 packets without DF set will be IP fragmented as directed by [RFC4301]. Packets egressing the tunnel continue to be handled as specified in [RFC4301]. All other aspects of PMTU and the handling of ICMP "Too Big" messages (i.e., with regards to the outer AGGFRAG/ESP tunnel packet size) also remain unchanged from [RFC4301]. Hopps Expires 8 March 2023 [Page 10] Internet-Draft IP Traffic Flow Security September 2022 2.2.7. Effective MTU of the Tunnel Unlike [RFC4301], there is normally no effective MTU (EMTU) on an AGGFRAG tunnel as all IP packet sizes are properly transmitted without requiring IP fragmentation prior to tunnel ingress. That said, a sender MAY allow for explicitly configuring an MTU for the tunnel. If fragmentation has been disabled on the AGGFRAG tunnel, then the tunnel's EMTU and behaviors are the same as normal IPsec tunnels [RFC4301]. 2.3. Exclusive SA Use This document does not specify mixed use of an AGGFRAG_PAYLOAD- enabled SA. A sender MUST only send AGGFRAG_PAYLOAD payloads over an SA configured for AGGFRAG mode. 2.4. Modes of Operation Just as with normal IPsec/ESP SAs, AGGFRAG SAs are unidirectional. Bidirectional IP-TFS functionality is achieved by setting up 2 AGGFRAG SAs, one in either direction. An AGGFRAG tunnel used for IP-TFS can operate in 2 modes, a non- congestion-controlled mode and congestion-controlled mode. 2.4.1. Non-Congestion-Controlled Mode In the non-congestion-controlled mode, IP-TFS sends fixed-sized packets over an AGGFRAG tunnel at a constant rate. The packet send rate is constant and is not automatically adjusted regardless of any network congestion (e.g., packet loss). For similar reasons as given in [RFC7510] the non-congestion- controlled mode MUST only be used where the user has full administrative control over any path the tunnel will take, and MUST NOT be used if this is not the case. This is required so the user can guarantee the bandwidth and also be sure as to not be negatively affecting network congestion [RFC2914]. In this case, packet loss should be reported to the administrator (e.g., via syslog, YANG notification, SNMP traps, etc.) so that any failures due to a lack of bandwidth can be corrected. The use of circuit breakers is also RECOMMENDED (Section 2.4.2.1). Users that choose the non-congestion-controlled mode need to understand that this mode will send packets at a constant rate utilizing a constant fixed bandwidth and will not adjust based on Hopps Expires 8 March 2023 [Page 11] Internet-Draft IP Traffic Flow Security September 2022 congestion. Thus, if they do not guarantee the bandwidth required by the tunnel, the tunnel's operation, as well as the rest of their network, may be negatively impacted. One expected use case for non-congestion-controlled mode is to guarantee the full tunnel bandwidth is available and preferred over other non-tunnel traffic. In fact, a typical site-to-site use case might have all of the user traffic utilizing the IP-TFS tunnel. Non-congestion-controlled mode is also appropriate if ESP over TCP is in use [RFC8229]. However, the use of TCP is considered a highly non-preferred, and a fall-back only solution for IPsec. This is also one of the reasons that TCP was not chosen as the encapsulation for IP-TFS instead of AGGFRAG. 2.4.2. Congestion-Controlled Mode With the congestion-controlled mode, IP-TFS adapts to network congestion by lowering the packet send rate to accommodate the congestion, as well as raising the rate when congestion subsides. Since overhead is per packet, by allowing for maximal fixed-size packets and varying the send rate, transport overhead is minimized. The output of the congestion control algorithm will adjust the rate at which the ingress sends packets. While this document does not require a specific congestion control algorithm, best current practice RECOMMENDS that the algorithm conform to [RFC5348]. Congestion control principles are documented in [RFC2914] as well. [RFC4342] provides an example of the [RFC5348] algorithm which matches the requirements of IP-TFS (i.e., designed for fixed-size packets and send rate varied based on congestion). The required inputs for the TCP friendly rate control algorithm described in [RFC5348] are the receiver's loss event rate and the sender's estimated round-trip time (RTT). These values are provided by IP-TFS using the congestion information header fields described in Section 3. In particular, these values are sufficient to implement the algorithm described in [RFC5348]. Hopps Expires 8 March 2023 [Page 12] Internet-Draft IP Traffic Flow Security September 2022 At a minimum, the congestion information MUST be sent, from the receiver and from the sender, at least once per RTT. Prior to establishing an RTT the information SHOULD be sent constantly from the sender and the receiver so that an RTT estimate can be established. Not receiving this information over multiple consecutive RTT intervals should be considered a congestion event that causes the sender to adjust its sending rate lower. For example, [RFC4342] calls this the "no feedback timeout" and it is equal to 4 RTT intervals. When a "no feedback timeout" has occurred [RFC4342] halves the sending rate. An implementation MAY choose to always include the congestion information in its AGGFRAG payload header if sending on an IP-TFS- enabled SA. Since IP-TFS normally will operate with a large packet size, the congestion information should represent a small portion of the available tunnel bandwidth. An implementation choosing to always send the data MAY also choose to only update the LossEventRate and RTT header field values it sends every RTT though. When choosing a congestion control algorithm (or a selection of algorithms), note that IP-TFS is not providing for reliable delivery of IP traffic, and so per packet ACKs are not required and are not provided. It is worth noting that the variable send-rate of a congestion- controlled AGGFRAG tunnel, is not private; however, this send-rate is being driven by network congestion, and as long as the encapsulated (inner) traffic flow shape and timing are not directly affecting the (outer) network congestion, the variations in the tunnel rate will not weaken the provided inner traffic flow confidentiality. 2.4.2.1. Circuit Breakers In additional to congestion control, implementations that support non-congestion control mode SHOULD implement circuit breakers [RFC8084] as a recovery method of last resort. When circuit breakers are enabled an implementation SHOULD also enable congestion control reports so that circuit breakers have information to act on. The pseudowire congestion considerations [RFC7893] are equally applicable to the mechanisms defined in this document, notably the text on inellastic traffic. One example of a simple slow-trip circuit breaker (CB) an implementation may provide would utilize 2 values, the amount of persistent loss rate required to trip the CB, and the required length of time this persistent loss rate must be seen to trip the CB. These 2 value are required configuration from the user. When the CB is Hopps Expires 8 March 2023 [Page 13] Internet-Draft IP Traffic Flow Security September 2022 tripped the tunnel traffic is disabled, and an appropriate log message or other management type alarm is triggered indicating operate intervention is required. 2.5. Summary of Receiver Processing An AGGFRAG-enabled SA receiver has a few tasks to perform. The receiver MAY process incoming AGGFRAG_PAYLOAD payloads as soon as they arrive as much as it can. I.e., if the incoming AGGFRAG_PAYLOAD packet contains complete inner packet(s), the receiver should extract and transmit them immediately. For partial packets, the receiver needs to keep the partial packets in the memory until they fall out from the reordering window, or until the missing parts of the packets are received, in which case it will reassemble and transmit them. If the AGGFRAG_PAYLOAD payload contains multiple packets they SHOULD be sent out in the order they are in the AGGFRAG_PAYLOAD (i.e., keep the original order they were received on the other end). The cost of using this method is that an amplification of out-of-order delivery of inner packets can occur due to inner packet aggregation. Instead of the method described in the previous paragraph, the receiver MAY reorder out-of-order AGGFRAG_PAYLOAD payloads received into in-sequence-order AGGFRAG_PAYLOAD payloads (Section 2.2.3), and only after it has an in-order AGGFRAG_PAYLOAD payload stream would the receiver transmits the inner packets. Using this method will ensure the inner packets are sent in order. The cost of this method is that a lost packet will cause a delay of up to the lost packet timer interval (or the full reorder window if no lost packet timer is used). Additionally, there can be extra burstiness in the output stream. This burstiness can happen when a lost packet is dropped from the re-order window, and the remaining outer packets in the re- order window are immediately processed and sent out back to back. Additionally, if congestion control is enabled, the receiver sends congestion control data (Section 6.1.2) back to the sender as described in Section 2.4.2 and Section 3. Finally, a note on receiving incorrect BlockOffset values. To account for misbehaving senders, a receiver SHOULD gracefully handle the case where the BlockOffset of consecutive packets, and/or the inner packet they share, do not agree. It MAY drop the inner packet, or one or both of the outer packets. Hopps Expires 8 March 2023 [Page 14] Internet-Draft IP Traffic Flow Security September 2022 3. Congestion Information In order to support the congestion-controlled mode, the sender needs to know the loss event rate and to approximate the RTT [RFC5348]. In order to obtain these values, the receiver sends congestion control information on its SA back to the sender. Thus, to support congestion control the receiver MUST have a paired SA back to the sender (this is always the case when the tunnel was created using IKEv2). If the SA back to the sender is a non-AGGFRAG_PAYLOAD enabled SA then an AGGFRAG_PAYLOAD empty payload (i.e., header only) is used to convey the information. In order to calculate a loss event rate compatible with [RFC5348], the receiver needs to have a round-trip time estimate. Thus the sender communicates this estimate in the RTT header field. On startup this value will be zero as no RTT estimate is yet known. In order for the sender to estimate its RTT value, the sender places a timestamp value in the TVal header field. On first receipt of this TVal, the receiver records the new TVal value along with the time it arrived locally. Subsequent receipt of the same TVal MUST NOT update the recorded time. When the receiver sends its congestion control header it places this latest recorded TVal in the TEcho header field, along with 2 delay values, Echo Delay and Transmit Delay. The Echo Delay value is the time delta from the recorded arrival time of TVal and the current clock in microseconds. The second value, Transmit Delay, is the receiver's current transmission delay on the tunnel (i.e., the average time between sending packets on its half of the AGGFRAG tunnel). When the sender receives back its TVal in the TEcho header field it calculates 2 RTT estimates. The first is the actual delay found by subtracting the TEcho value from its current clock and then subtracting Echo Delay as well. The second RTT estimate is found by adding the received Transmit Delay header value to the sender's own transmission delay (i.e., the average time between sending packets on its half of the AGGFRAG tunnel). The larger of these 2 RTT estimates SHOULD be used as the RTT value. The two RTT estimates are required to handle different combinations of faster or slower tunnel packet paths with faster or slower fixed tunnel rates. Choosing the larger of the two values guarantees that the RTT is never considered faster than the aggregate transmission delay based on the IP-TFS send rate (the second estimate), as well as never being considered faster than the actual RTT along the tunnel packet path (the first estimate). Hopps Expires 8 March 2023 [Page 15] Internet-Draft IP Traffic Flow Security September 2022 The receiver also calculates, and communicates in the LossEventRate header field, the loss event rate for use by the sender. This is slightly different from [RFC4342] which periodically sends all the loss interval data back to the sender so that it can do the calculation. See Appendix B for a suggested way to calculate the loss event rate value. Initially this value will be zero (indicating no loss) until enough data has been collected by the receiver to update it. 3.1. ECN Support In addition to normal packet loss information, AGGFRAG mode supports use of the ECN bits in the encapsulating IP header [RFC3168] for identifying congestion. If ECN use is enabled and a packet arrives at the egress (receiving) side with the Congestion Experienced (CE) value set, then the receiver considers that packet as being dropped, although it does not drop it. The receiver MUST set the E bit in any AGGFRAG_PAYLOAD payload header containing a LossEventRate value derived from a CE value being considered. [RFC3168] and [RFC4301], updated by [RFC6040] defines behaviors for marking the outer ECN field value based on the ECN field of the inner packet. As AGGFRAG mode may have multiple inner packets present in a single outer packet, and there is no obvious correct way to map these multiple values to the single outer packet ECN field value, the tunnel ingress endpoint SHOULD operate in the "compatibility" mode rather than the "default" mode from RFC6040. In particular this means that the ingress (sending) endpoint of the tunnel always sets the newly constructed outer encapsulating packet header ECN field to Not-ECT [RFC6040]. 4. Configuration of AGGFRAG Tunnels for IP-TFS IP-TFS is meant to be deployable with a minimal amount of configuration. All IP-TFS specific configuration should be specified at the unidirectional tunnel ingress (sending) side. It is intended that non-IKEv2 operation is supported, at least, with local static configuration. YANG and MIB documents have been defined for IP-TFS in [I-D.ietf-ipsecme-yang-iptfs] and [I-D.ietf-ipsecme-mib-iptfs]. Hopps Expires 8 March 2023 [Page 16] Internet-Draft IP Traffic Flow Security September 2022 4.1. Bandwidth Bandwidth is a local configuration option. For non-congestion- controlled mode, the bandwidth SHOULD be configured. For congestion- controlled mode, the bandwidth can be configured or the congestion control algorithm discovers and uses the maximum bandwidth available. No standardized configuration method is required. 4.2. Fixed Packet Size The fixed packet size to be used for the tunnel encapsulation packets MAY be configured manually or can be automatically determined using other methods such as PLMTUD ([RFC4821], [RFC8899]) or PMTUD ([RFC1191], [RFC8201]). As PMTUD is known to have issues, PLMTUD is considered the more robust option. No standardized configuration method is required. 4.3. Congestion Control Congestion control is a local configuration option. No standardized configuration method is required. 5. IKEv2 5.1. USE_AGGFRAG Notification Message As mentioned previously AGGFRAG tunnels utilize ESP payloads of type AGGFRAG_PAYLOAD. When using IKEv2, a new "USE_AGGFRAG" Notification Message enables the AGGFRAG_PAYLOAD payload on a child SA pair. The method used is similar to how USE_TRANSPORT_MODE is negotiated, as described in [RFC7296]. To request use of the AGGFRAG_PAYLOAD payload on the Child SA pair, the initiator includes the USE_AGGFRAG notification in an SA payload requesting a new Child SA (either during the initial IKE_AUTH or during CREATE_CHILD_SA exchanges). If the request is accepted then the response MUST also include a notification of type USE_AGGFRAG. If the responder declines the request the child SA will be established without AGGFRAG_PAYLOAD payload use enabled. If this is unacceptable to the initiator, the initiator MUST delete the child SA. As the use of the AGGFRAG_PAYLOAD payload is currently only defined for non-transport mode tunnels, the USE_AGGFRAG notification MUST NOT be combined with USE_TRANSPORT notification. Hopps Expires 8 March 2023 [Page 17] Internet-Draft IP Traffic Flow Security September 2022 The USE_AGGFRAG notification contains a 1 octet payload of flags that specify requirements from the sender of the notification. If any requirement flags are not understood or cannot be supported by the receiver then the receiver SHOULD NOT enable use of AGGFRAG_PAYLOAD (either by not responding with the USE_AGGFRAG notification, or in the case of the initiator, by deleting the child SA if the now established non-AGGFRAG_PAYLOAD using SA is unacceptable). The notification type and payload flag values are defined in Section 6.1.4. 6. Packet and Data Formats The packet and data formats defined below are generic with the intent of allowing for non-IP-TFS uses, but such uses are outside the scope of this document. 6.1. AGGFRAG_PAYLOAD Payload ESP Next Header value: 144 An AGGFRAG payload is identified by the ESP Next Header value AGGFRAG_PAYLOAD which has the value 144, which has been reserved in the IP protocol numbers space. The first octet of the payload indicates the format of the remaining payload data. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+- | Sub-type | ... +-+-+-+-+-+-+-+-+-+-+- Figure 3: AGGFRAG_PAYLOAD payload format Sub-type: An 8-bit value indicating the payload format. This document defines 2 payload sub-types. These payload formats are defined in the following sections. 6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format The non-congestion control AGGFRAG_PAYLOAD payload consists of a 4-octet header followed by a variable amount of DataBlocks data as shown below. Hopps Expires 8 March 2023 [Page 18] Internet-Draft IP Traffic Flow Security September 2022 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type (0) | Reserved | BlockOffset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DataBlocks ... +-+-+-+-+-+-+-+-+-+-+- Figure 4: Non-congestion control payload format Sub-type: An octet indicating the payload format. For this non-congestion control format, the value is 0. Reserved: An octet set to 0 on generation and ignored on receipt. BlockOffset: A 16-bit unsigned integer counting the number of octets of DataBlocks data before the start of a new data block. If the start of a new data block occurs in a subsequent payload the BlockOffset will point past the end of the DataBlocks data. In this case all the DataBlocks data belongs to the current data block being assembled. When the BlockOffset extends into subsequent payloads it continues to only count DataBlocks data (i.e., it does not count subsequent packets non-DataBlocks data such as header octets). DataBlocks: Variable number of octets that begins with the start of a data block, or the continuation of a previous data block, followed by zero or more additional data blocks. 6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format The congestion control AGGFRAG_PAYLOAD payload consists of a 24 octet header followed by a variable amount of DataBlocks data as shown below. Hopps Expires 8 March 2023 [Page 19] Internet-Draft IP Traffic Flow Security September 2022 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-type (1) | Reserved |P|E| BlockOffset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LossEventRate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTT | Echo Delay ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Echo Delay | Transmit Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TVal | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TEcho | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DataBlocks ... +-+-+-+-+-+-+-+-+-+-+- Figure 5: Congestion control payload format Sub-type: An octet indicating the payload format. For this congestion control format, the value is 1. Reserved: A 6-bit field set to 0 on generation and ignored on receipt. P: A 1-bit value that if set indicates that PLMTUD probing is in progress. This information can be used to avoid treating missing packets as loss events by the CC algorithm when running the PLMTUD probe algorithm. E: A 1-bit value that if set indicates that Congestion Experienced (CE) ECN bits were received and used in deriving the reported LossEventRate. BlockOffset: The same value as the non-congestion-controlled payload format value. LossEventRate: A 32-bit value specifying the inverse of the current loss event rate as calculated by the receiver. A value of zero indicates no loss. Otherwise the loss event rate is 1/LossEventRate. Hopps Expires 8 March 2023 [Page 20] Internet-Draft IP Traffic Flow Security September 2022 RTT: A 22-bit value specifying the sender's current round-trip time estimate in microseconds. The value MAY be zero prior to the sender having calculated a round-trip time estimate. The value SHOULD be set to zero on non-AGGFRAG_PAYLOAD-enabled SAs. If the RTT is equal to or larger than 0x3FFFFF the value MUST be set to 0x3FFFFF. Echo Delay: A 21-bit value specifying the delay in microseconds incurred between the receiver first receiving the TVal value which it is sending back in TEcho. If the delay is equal to or larger than 0x1FFFFF the value MUST be set to 0x1FFFFF. Transmit Delay: A 21-bit value specifying the transmission delay in microseconds. This is the fixed (or average) delay on the receiver between it sending packets on the IPTFS tunnel. If the delay is equal to or larger than 0x1FFFFF the value MUST be set to 0x1FFFFF. TVal: An opaque 32-bit value that will be echoed back by the receiver in later packets in the TEcho field, along with an Echo Delay value of how long that echo took. TEcho: The opaque 32-bit value from a received packet's TVal field. The received TVal is placed in TEcho along with an Echo Delay value indicating how long it has been since receiving the TVal value. DataBlocks: Variable number of octets that begins with the start of a data block, or the continuation of a previous data block, followed by zero or more additional data blocks. For the special case of sending congestion control information on a non-IP-TFS enabled SA this field MUST be empty (i.e., be zero octets long). 6.1.3. Data Blocks 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | IPv4, IPv6 or pad... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 6: Data Block format Hopps Expires 8 March 2023 [Page 21] Internet-Draft IP Traffic Flow Security September 2022 Type: A 4-bit field where 0x0 identifies a pad data block, 0x4 indicates an IPv4 data block, and 0x6 indicates an IPv6 data block. 6.1.3.1. IPv4 Data Block 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x4 | IHL | TypeOfService | TotalLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rest of the inner packet ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 7: IPv4 Data Block format These values are the actual values within the encapsulated IPv4 header. In other words, the start of this data block is the start of the encapsulated IP packet. Type: A 4-bit value of 0x4 indicating IPv4 (i.e., first nibble of the IPv4 packet). TotalLength: The 16-bit unsigned integer "Total Length" field of the IPv4 inner packet. 6.1.3.2. IPv6 Data Block 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x6 | TrafficClass | FlowLabel | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PayloadLength | Rest of the inner packet ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 8: IPv6 Data Block format These values are the actual values within the encapsulated IPv6 header. In other words, the start of this data block is the start of the encapsulated IP packet. Type: A 4-bit value of 0x6 indicating IPv6 (i.e., first nibble of the IPv6 packet). Hopps Expires 8 March 2023 [Page 22] Internet-Draft IP Traffic Flow Security September 2022 PayloadLength: The 16-bit unsigned integer "Payload Length" field of the inner IPv6 inner packet. 6.1.3.3. Pad Data Block 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0 | Padding ... +-+-+-+-+-+-+-+-+-+-+- Figure 9: Pad Data Block format Type: A 4-bit value of 0x0 indicating a padding data block. Padding: Extends to end of the encapsulating packet. 6.1.4. IKEv2 USE_AGGFRAG Notification Message As discussed in Section 5.1, a notification message USE_AGGFRAG is used to negotiate use of the ESP AGGFRAG_PAYLOAD Next Header value. The USE_AGGFRAG Notification Message State Type is 16442 The notification payload contains 1 octet of requirement flags. There are currently 2 requirement flags defined. This may be revised by later specifications. +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|C|D| +-+-+-+-+-+-+-+-+ Figure 10: USE_AGGFRAG requirement flags 0: 6 bits - Reserved MUST be zero on send, unless defined by later specifications. C: Congestion Control bit. If set, then the sender is requiring that congestion control information MUST be returned to it periodically as defined in Section 3. Hopps Expires 8 March 2023 [Page 23] Internet-Draft IP Traffic Flow Security September 2022 D: Don't Fragment bit. If set, indicates the sender of the notify message does not support receiving packet fragments (i.e., inner packets MUST be sent using a single Data Block). This value only applies to what the sender is capable of receiving; the sender MAY still send packet fragments unless similarly restricted by the receiver in its USE_AGGFRAG notification. 7. IANA Considerations 7.1. ESP Next Header Value Per the INT area directors direction, this document requests IANA allocate an IP protocol number from "Protocol Numbers - Assigned Internet Protocol Numbers" registry Decimal: 144 Keyword: AGGFRAG Protocol: AGGFRAG encapsulation payload for ESP (TEMPORARY - registered 2022-08-26, document sent to IESG Evaluation 2022-07-14) Reference: This document 7.2. AGGFRAG_PAYLOAD Sub-Type Registry This document requests IANA create a registry called "AGGFRAG_PAYLOAD Sub-Type Registry" under a new category named "ESP AGGFRAG_PAYLOAD Parameters". The registration policy for this registry is "Expert Review" ([RFC8126] and [RFC7120]). Name: AGGFRAG_PAYLOAD Sub-Type Registry Description: AGGFRAG_PAYLOAD Payload Formats. Reference: This document This initial content for this registry is as follows: Hopps Expires 8 March 2023 [Page 24] Internet-Draft IP Traffic Flow Security September 2022 Sub-Type Name Reference -------------------------------------------------------- 0 Non-Congestion Control Format This document 1 Congestion Control Format This document 3-255 Reserved 7.3. USE_AGGFRAG Notify Message Status Type This document requests a status type USE_AGGFRAG be allocated from the "IKEv2 Notify Message Types - Status Types" registry. Decimal: 16442 Name: USE_AGGFRAG Reference: This document 8. Implementation Status [ RFC Ed.: please remove this entire section as well as the reference to RFC7942 prior to publication. ] [Section added during IESG review to help with evaluation] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". Currently the author and contributors are aware of 1 full and completed implementation and 1 underway implementation of IP-TFS as defined in this document. These 2 are described below. Hopps Expires 8 March 2023 [Page 25] Internet-Draft IP Traffic Flow Security September 2022 8.1. Reference Implementation - VPP + Strongswan The entire IP-TFS protocol including congestion control mode has been implemented in VPP (Vector Packet Processor), and published to github with an Open Source (Apache 2) License. VPP is a highly efficient forwarding plane implemented in user-space utlizing direct control and polling of physical devices to provide high speed low-latency forwarding in Linux. By pinning packet processing threads directly to CPU cores for their exclusive use a high degree of control is given to the protocol designer. The IKEv2 additions were implemented in Strongswan and are licensed using the GNU public license used by the Strongswan project. Finally, an extensive automation suite was also created and is included with the open source implementation, which tests the functionality as well as the performance of the implementation, and most importantly verifies, through precise timing tracing and time- stamping, the decoupling of the users offered load from the tunnel packets (i.e., the Traffic Flow Security). The verification process utilized the TREX (https://trex- tgn.cisco.com/) packet generator for high bandwidth testing as well as other tools such as iperf. The test hardware included large servers with 10GE, 40GE and 100GE network interfaces, as well as small SoC (system on a chip) network appliances, and also cloud deployments. Tested IP-TFS tunnel rates ranged from 10M all the way to 10GE on the small network appliance, for the large servers multiple 10GE tunnel rates were tested as well. Offered loads included partial, full and oversubscribed bandwidths from various flow types consisting of small packets, large packets, random sized packets, sequential sized packets, and multiple IMIX variations sized flows. Timing analysis was done with variable rate traffic, impulse traffic and random bursty traffic. The quality of the reference implementation should be considered production level as it underwent extensive testing and verification. The organization responsible for this implementation is LabN Consulting, L.L.C. URLs to the implementation follow. Hopps Expires 8 March 2023 [Page 26] Internet-Draft IP Traffic Flow Security September 2022 * VPP+IPTFS (https://github.com/LabNConsulting/vpp/tree/labn- stable/2009-public), iptfs plugin (https://github.com/LabNConsulting/vpp/tree/labn-stable/2009- public/src/plugins/iptfs) * Strongswan IKEv2 (https://github.com/LabNConsulting/strongswan/tree/labn- 5.8-public) The implementation was last updated April, 2021. 8.2. In Progress Linux Kernel Implementation. A second open source implementation has begun by LabN Consulting L.L.C., within the Linux IPsec xfrm stack. Development has also been coordinated with the Linux IPsec community, and was being worked by the same during the most recent IETF 114 hackathon. Currently the quality is alpha level with aggregation-only complete and fragmentation support underway with congestion control to follow. This implementation is licensed under the GNU public license and can be found at the following URLs * development environment: https://github.com/LabNConsulting/iptfs- dev * linux kernel source: https://github.com/LabNConsulting/iptfs-linux * iproute2 source: https://github.com/LabNConsulting/iptfs-iproute2 9. Security Considerations This document describes an aggregation and fragmentation mechanism to efficiently implement TFC for IP traffic. This approach is expected to reduce the efficacy of traffic analysis on IPsec communication. Other than the additional security afforded by using this mechanism, IP-TFS utilizes the security protocols [RFC4303] and [RFC7296] and so their security considerations apply to IP-TFS as well. As noted in Section 3.1, the ECN bits are not protected by IPsec and thus may constitute a covert channel. For this reason, ECN use SHOULD NOT be enabled by default. As noted previously in Section 2.4.2, for TFC to be maintained, the encapsulated traffic flow should not be affecting network congestion in a predictable way, and if it would be, then non-congestion- controlled mode use should be considered instead. Hopps Expires 8 March 2023 [Page 27] Internet-Draft IP Traffic Flow Security September 2022 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [AppCrypt] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", 1 November 2017. [I-D.ietf-ipsecme-mib-iptfs] Fedyk, D. and E. Kinzie, "Definitions of Managed Objects for IP Traffic Flow Security", Work in Progress, Internet- Draft, draft-ietf-ipsecme-mib-iptfs-03, 18 November 2021, . [I-D.ietf-ipsecme-yang-iptfs] Fedyk, D. and C. Hopps, "A YANG Data Model for IP Traffic Flow Security", Work in Progress, Internet-Draft, draft- ietf-ipsecme-yang-iptfs-10, 31 August 2022, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . Hopps Expires 8 March 2023 [Page 28] Internet-Draft IP Traffic Flow Security September 2022 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, . [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, . [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, . [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, . Hopps Expires 8 March 2023 [Page 29] Internet-Draft IP Traffic Flow Security September 2022 [RFC7893] Stein, Y(J)., Black, D., and B. Briscoe, "Pseudowire Congestion Considerations", RFC 7893, DOI 10.17487/RFC7893, June 2016, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, . [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, August 2017, . [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 2019, . [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, . Appendix A. Example of An Encapsulated IP Packet Flow Below, an example inner IP packet flow within the encapsulating tunnel packet stream is shown. Notice how encapsulated IP packets can start and end anywhere, and more than one or less than 1 may occur in a single encapsulating packet. Hopps Expires 8 March 2023 [Page 30] Internet-Draft IP Traffic Flow Security September 2022 Offset: 0 Offset: 100 Offset: 2000 Offset: 600 [ ESP1 (1404) ][ ESP2 (1404) ][ ESP3 (1404) ][ ESP4 (1404) ] [--750--][--750--][60][-240-][--3000----------------------][pad] Figure 11: Inner and outer packet flow Each outer encapsulating ESPupayload space is a fixed-size of 1404 octets the first 4 octets of which contains the AGGFRAG header. The encapsulated IP packet flow (lengths include IP header and payload) is as follows: a 750-octet packet, a 750-octet packet, a 60-octet packet, a 240-octet packet, a 3000-octet packet. The BlockOffset values in the 4 AGGFRAG payload headers for this packet flow would thus be: 0, 100, 2000, 600 respectively. The first encapsulating packet (ESP1) has a zero BlockOffset which points at the IP data block immediately following the AGGFRAG header. The following packet's (ESP2) BlockOffset points inward 100 octets to the start of the 60-octet data block. The third encapsulating packet (ESP3) contains the middle portion of the 3000-octet data block so the offset points past its end and into the fourth encapsulating packet. The fourth packet's (ESP4) offset is 600, pointing at the padding which follows the completion of the continued 3000-octet packet. Appendix B. A Send and Loss Event Rate Calculation The current best practice indicates that congestion control SHOULD be done in a TCP-friendly way. A TCP-friendly congestion control algorithm is described in [RFC5348]. For this IP-TFS use case (as with [RFC4342]), the (fixed) packet size is used as the segment size for the algorithm. The main formula in the algorithm for the send rate is then as follows: 1 X = ----------------------------------------------- R * (sqrt(2*p/3) + 12*sqrt(3*p/8)*p*(1+32*p^2)) Where X is the send rate in packets per second, R is the round trip time estimate and p is the loss event rate (the inverse of which is provided by the receiver). In addition, the algorithm in [RFC5348] also uses an X_recv value (the receiver's receive rate). For IP-TFS one MAY set this value according to the sender's current tunnel send-rate (X). The IP-TFS receiver, having the RTT estimate from the sender can use the same method as described in [RFC5348] and [RFC4342] to collect the loss intervals and calculate the loss event rate value using the Hopps Expires 8 March 2023 [Page 31] Internet-Draft IP Traffic Flow Security September 2022 weighted average as indicated. The receiver communicates the inverse of this value back to the sender in the AGGFRAG_PAYLOAD payload header field LossEventRate. The IP-TFS sender now has both the R and p values and can calculate the correct sending rate. If following [RFC5348], the sender should also use the slow start mechanism described therein when the IP-TFS SA is first established. Appendix C. Comparisons of IP-TFS C.1. Comparing Overhead For comparing overhead, the overhead of ESP for both normal and AGGFRAG tunnel packets must be calculated, and so an algorithm for encryption and authentication must be chosen. For the data below AES-GCM-256 was selected. This leads to an IP+ESP overhead of 54. 54 = 20 (IP) + 8 (ESPH) + 2 (ESPF) + 8 (IV) + 16 (ICV) Additionally, for IP-TFS, non-congestion control AGGFRAG_PAYLOAD headers were chosen which adds 4 octets for a total overhead of 58. C.1.1. IP-TFS Overhead For comparison, the overhead of an AGGFRAG payload is 58 octets per outer packet. Therefore, the octet overhead per inner packet is 58 divided by the number of outer packets required (fractions allowed). The overhead as a percentage of inner packet size is a constant based on the Outer MTU size. OH = 58 / Outer Payload Size / Inner Packet Size OH % of Inner Packet Size = 100 * OH / Inner Packet Size OH % of Inner Packet Size = 5800 / Outer Payload Size Type IP-TFS IP-TFS IP-TFS MTU 576 1500 9000 PSize 518 1442 8942 ------------------------------- 40 11.20% 4.02% 0.65% 576 11.20% 4.02% 0.65% 1500 11.20% 4.02% 0.65% 9000 11.20% 4.02% 0.65% Figure 12: IP-TFS Overhead as Percentage of Inner Packet Size Hopps Expires 8 March 2023 [Page 32] Internet-Draft IP Traffic Flow Security September 2022 C.1.2. ESP with Padding Overhead The overhead per inner packet for constant-send-rate padded ESP (i.e., traditional IPsec TFC) is 36 octets plus any padding, unless fragmentation is required. When fragmentation of the inner packet is required to fit in the outer IPsec packet, overhead is the number of outer packets required to carry the fragmented inner packet times both the inner IP overhead (20) and the outer packet overhead (54) minus the initial inner IP overhead plus any required tail padding in the last encapsulation packet. The required tail padding is the number of required packets times the difference of the Outer Payload Size and the IP Overhead minus the Inner Payload Size. So: Inner Payload Size = IP Packet Size - IP Overhead Outer Payload Size = MTU - IPsec Overhead Inner Payload Size NF0 = ---------------------------------- Outer Payload Size - IP Overhead NF = CEILING(NF0) OH = NF * (IP Overhead + IPsec Overhead) - IP Overhead + NF * (Outer Payload Size - IP Overhead) - Inner Payload Size OH = NF * (IPsec Overhead + Outer Payload Size) - (IP Overhead + Inner Payload Size) OH = NF * (IPsec Overhead + Outer Payload Size) - Inner Packet Size C.2. Overhead Comparison The following tables collect the overhead values for some common L3 MTU sizes in order to compare them. The first table is the number of octets of overhead for a given L3 MTU sized packet. The second table is the percentage of overhead in the same MTU sized packet. Hopps Expires 8 March 2023 [Page 33] Internet-Draft IP Traffic Flow Security September 2022 Type ESP+Pad ESP+Pad ESP+Pad IP-TFS IP-TFS IP-TFS L3 MTU 576 1500 9000 576 1500 9000 PSize 522 1446 8946 518 1442 8942 ----------------------------------------------------------- 40 482 1406 8906 4.5 1.6 0.3 128 394 1318 8818 14.3 5.1 0.8 256 266 1190 8690 28.7 10.3 1.7 518 4 928 8428 58.0 20.8 3.4 576 576 870 8370 64.5 23.2 3.7 1442 286 4 7504 161.5 58.0 9.4 1500 228 1500 7446 168.0 60.3 9.7 8942 1426 1558 4 1001.2 359.7 58.0 9000 1368 1500 9000 1007.7 362.0 58.4 Figure 13: Overhead comparison in octets Type ESP+Pad ESP+Pad ESP+Pad IP-TFS IP-TFS IP-TFS MTU 576 1500 9000 576 1500 9000 PSize 522 1446 8946 518 1442 8942 ----------------------------------------------------------- 40 1205.0% 3515.0% 22265.0% 11.20% 4.02% 0.65% 128 307.8% 1029.7% 6889.1% 11.20% 4.02% 0.65% 256 103.9% 464.8% 3394.5% 11.20% 4.02% 0.65% 518 0.8% 179.2% 1627.0% 11.20% 4.02% 0.65% 576 100.0% 151.0% 1453.1% 11.20% 4.02% 0.65% 1442 19.8% 0.3% 520.4% 11.20% 4.02% 0.65% 1500 15.2% 100.0% 496.4% 11.20% 4.02% 0.65% 8942 15.9% 17.4% 0.0% 11.20% 4.02% 0.65% 9000 15.2% 16.7% 100.0% 11.20% 4.02% 0.65% Figure 14: Overhead as Percentage of Inner Packet Size C.3. Comparing Available Bandwidth Another way to compare the two solutions is to look at the amount of available bandwidth each solution provides. The following sections consider and compare the percentage of available bandwidth. For the sake of providing a well-understood baseline normal (unencrypted) Ethernet as well as normal ESP values are included. C.3.1. Ethernet In order to calculate the available bandwidth the per packet overhead is calculated first. The total overhead of Ethernet is 14+4 octets of header and CRC plus an additional 20 octets of framing (preamble, start, and inter-packet gap), for a total of 38 octets. Additionally, the minimum payload is 46 octets. Hopps Expires 8 March 2023 [Page 34] Internet-Draft IP Traffic Flow Security September 2022 Size E + P E + P E + P IPTFS IPTFS IPTFS Enet ESP MTU 590 1514 9014 590 1514 9014 any any OH 92 92 92 96 96 96 38 74 ------------------------------------------------------------ 40 614 1538 9038 47 42 40 84 114 128 614 1538 9038 151 136 129 166 202 256 614 1538 9038 303 273 258 294 330 518 614 1538 9038 614 552 523 574 610 576 1228 1538 9038 682 614 582 614 650 1442 1842 1538 9038 1709 1538 1457 1498 1534 1500 1842 3076 9038 1777 1599 1516 1538 1574 8942 11052 10766 9038 10599 9537 9038 8998 9034 9000 11052 10766 18076 10667 9599 9096 9038 9074 Figure 15: L2 Octets Per Packet Size E + P E + P E + P IPTFS IPTFS IPTFS Enet ESP MTU 590 1514 9014 590 1514 9014 any any OH 92 92 92 96 96 96 38 74 -------------------------------------------------------------- 40 2.0M 0.8M 0.1M 26.4M 29.3M 30.9M 14.9M 11.0M 128 2.0M 0.8M 0.1M 8.2M 9.2M 9.7M 7.5M 6.2M 256 2.0M 0.8M 0.1M 4.1M 4.6M 4.8M 4.3M 3.8M 518 2.0M 0.8M 0.1M 2.0M 2.3M 2.4M 2.2M 2.1M 576 1.0M 0.8M 0.1M 1.8M 2.0M 2.1M 2.0M 1.9M 1442 678K 812K 138K 731K 812K 857K 844K 824K 1500 678K 406K 138K 703K 781K 824K 812K 794K 8942 113K 116K 138K 117K 131K 138K 139K 138K 9000 113K 116K 69K 117K 130K 137K 138K 137K Figure 16: Packets Per Second on 10G Ethernet Size E + P E + P E + P IPTFS IPTFS IPTFS Enet ESP 590 1514 9014 590 1514 9014 any any 92 92 92 96 96 96 38 74 ---------------------------------------------------------------------- 40 6.51% 2.60% 0.44% 84.36% 93.76% 98.94% 47.62% 35.09% 128 20.85% 8.32% 1.42% 84.36% 93.76% 98.94% 77.11% 63.37% 256 41.69% 16.64% 2.83% 84.36% 93.76% 98.94% 87.07% 77.58% 518 84.36% 33.68% 5.73% 84.36% 93.76% 98.94% 93.17% 87.50% 576 46.91% 37.45% 6.37% 84.36% 93.76% 98.94% 93.81% 88.62% 1442 78.28% 93.76% 15.95% 84.36% 93.76% 98.94% 97.43% 95.12% 1500 81.43% 48.76% 16.60% 84.36% 93.76% 98.94% 97.53% 95.30% 8942 80.91% 83.06% 98.94% 84.36% 93.76% 98.94% 99.58% 99.18% 9000 81.43% 83.60% 49.79% 84.36% 93.76% 98.94% 99.58% 99.18% Figure 17: Percentage of Bandwidth on 10G Ethernet Hopps Expires 8 March 2023 [Page 35] Internet-Draft IP Traffic Flow Security September 2022 A sometimes unexpected result of using an AGGFRAG tunnel (or any packet aggregating tunnel) is that, for small- to medium-sized packets, the available bandwidth is actually greater than native Ethernet. This is due to the reduction in Ethernet framing overhead. This increased bandwidth is paid for with an increase in latency. This latency is the time to send the unrelated octets in the outer tunnel frame. The following table illustrates the latency for some common values on a 10G Ethernet link. The table also includes latency introduced by padding if using ESP with padding. ESP+Pad ESP+Pad IP-TFS IP-TFS 1500 9000 1500 9000 ------------------------------------------ 40 1.12 us 7.12 us 1.17 us 7.17 us 128 1.05 us 7.05 us 1.10 us 7.10 us 256 0.95 us 6.95 us 1.00 us 7.00 us 518 0.74 us 6.74 us 0.79 us 6.79 us 576 0.70 us 6.70 us 0.74 us 6.74 us 1442 0.00 us 6.00 us 0.05 us 6.05 us 1500 1.20 us 5.96 us 0.00 us 6.00 us Figure 18: Added Latency Notice that the latency values are very similar between the two solutions; however, whereas IP-TFS provides for constant high bandwidth, in some cases even exceeding native Ethernet, ESP with padding often greatly reduces available bandwidth. Appendix D. Acknowledgements We would like to thank Don Fedyk for help in reviewing and editing this work. We would also like to thank Michael Richardson, Sean Turner, Valery Smyslov and Tero Kivinen for reviews and many suggestions for improvements, as well as Joseph Touch for the transport area review and suggested improvements. Appendix E. Contributors The following people made significant contributions to this document. Lou Berger LabN Consulting, L.L.C. Email: lberger@labn.net Author's Address Hopps Expires 8 March 2023 [Page 36] Internet-Draft IP Traffic Flow Security September 2022 Christian Hopps LabN Consulting, L.L.C. Email: chopps@chopps.org Hopps Expires 8 March 2023 [Page 37] ./queue.html0000644000764400076440000027643114363246643012705 0ustar iustiniustin Current Queue » RFC Editor

Publication Queue

[About this page]  [Summary statistics]  [List of all active clusters]

Found 88 records

Current stateWeeks in stateWeeks in queueDraft name (Authors) ClusterPagesSubmitted
EDIT*R		13.444.0draft-bar-cfrg-spake2plus-08
T. Taubert, C.A. Wood		C450262022-03-20
EDIT		13.416.0draft-irtf-cfrg-hash-to-curve-16
A. Faz-Hernández, S. Scott, N. Sullivan, R. Wahby, C. A. Wood		C4501752022-10-02
EDIT		11.611.6draft-ietf-sipcore-multiple-reasons-01
R. Sparks		42022-11-02
EDIT		10.610.6draft-ietf-ipwave-vehicular-networking-30
J. Jeong, Ed.		562022-11-09
EDIT		7.910.4draft-ietf-dime-group-signaling-14
M. Jones, M. Liebsch, L. Morand		252022-11-10
EDIT		9.310.3draft-ietf-opsawg-yang-vpn-service-pm-15
B. Wu, Ed., Q. Wu, Ed., M. Boucadair, Ed., O. Gonzalez de Dios, B. Wen		442022-11-11
EDIT		9.99.9draft-ietf-bmwg-ngfw-performance-15
B. Balarajah, C. Rossenhoevel, B. Monkman		632022-11-14
EDIT		6.97.3draft-ietf-raw-ldacs-14
N. Mäurer, Ed., T. Gräupl, Ed., C. Schmitt, Ed.		412022-12-02
EDIT		6.97.3draft-ietf-v6ops-ipv6-deployment-10
G. Fioccola, P. Volpato, J. Martinez, G. Mishra, C. Xie		442022-12-02
EDIT*R		2.37.3draft-irtf-cfrg-vrf-15
S. Goldberg, L. Reyzin, D. Papadopoulos, J. Včelák		C450562022-12-02
EDIT*R		1.97.3draft-ietf-drip-rid-37
R. Moskowitz, S. Card, A. Wiethuechter, A. Gurtov		C469372022-12-02
EDIT		6.96.9draft-ietf-ccamp-gmpls-otn-b100g-applicability-15
Q. Wang, Ed., R. Valiveti, Ed., H. Zheng, Ed., H. Helvoort, S. Belotti		172022-12-05
EDIT		6.46.7draft-smyslov-ike2-gost-15
V. Smyslov		1512022-12-06
EDIT		4.96.7draft-ietf-lsr-isis-flood-reflection-12
T. Przygienda, Ed., C. Bowers, Y. Lee, A. Sharma, R. White		222022-12-06
EDIT		6.36.3draft-ietf-dots-telemetry-use-cases-15
Y. Hayashi, M. Chen, L. Su		282022-12-09
EDIT		3.66.3draft-ietf-ipsecme-ikev2-multiple-ke-12
C. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D. Van Geest, O. Garcia-Morchon, V. Smyslov		372022-12-09
EDIT*A		4.35.3draft-ietf-lamps-rfc3709bis-10
S. Santesson, R. Housley, T. Freeman, L. Rosenthol		472022-12-16
EDIT		4.45.3draft-pti-pen-registration-10
A. Baber, P. Hoffman		62022-12-16
EDIT		4.44.6draft-ietf-lpwan-schc-over-nbiot-15
E. Ramos, A. Minaburo		242022-12-21
EDIT		4.44.4draft-ietf-teep-architecture-19
M. Pei, H. Tschofenig, D. Thaler, D. Wheeler		382022-12-22
EDIT		4.44.4draft-ietf-rmcat-rtp-cc-feedback-12
C. Perkins		202022-12-22
EDIT		2.43.4draft-ietf-oauth-rar-22
T. Lodderstedt, J. Richer, B. Campbell		452022-12-29
EDIT		2.62.7draft-ietf-ipsecme-ikev1-algo-to-historic-09
P. Wouters		82023-01-03
EDIT		0.72.6draft-ietf-extra-imap-partial-04
A. Melnikov, A. Achuthan, V. Nagulakonda, L. Alves		102023-01-04
EDIT		1.62.3draft-ietf-pim-igmp-mld-proxy-yang-10
H. Zhao, X. Liu, Y. Liu, M. Panchanathan, M. Sivakumar		222023-01-06
EDIT		1.91.9draft-ietf-shmoo-online-meeting-05
M. Kühlewind, M. Duke		102023-01-09
EDIT		0.71.9draft-davies-int-historic-05
K. Davies, A. Baber		52023-01-09
EDIT		1.61.9draft-moskowitz-ipsecme-ipseckey-eddsa-09
R. Moskowitz, T. Kivinen, M. Richardson		C46952023-01-09
EDIT		0.61.4draft-ietf-idr-bfd-subcode-05
J. Haas		52023-01-12
EDIT		0.61.4draft-zern-webp-12
J. Zern, P. Massimino, J. Alakuijala		512023-01-12
EDIT		0.70.7draft-ietf-ippm-ioam-deployment-05
F. Brockners, Ed., S. Bhandari, Ed., D. Bernier, T. Mizrahi, Ed.		242023-01-17
EDIT*A		0.60.7draft-ietf-jmap-blob-18
B. Gondwana, Ed.		302023-01-17
RFC-EDITOR*R		8.965.6draft-ietf-lsr-isis-srv6-extensions-19
P. Psenak, Ed., C. Filsfils, A. Bashandy, B. Decraene, Z. Hu		C447292021-10-20
RFC-EDITOR		10.615.9draft-ietf-tls-subcerts-15
R. Barnes, S. Iyengar, N. Sullivan, E. Rescorla		172022-10-03
RFC-EDITOR		4.615.3draft-irtf-icnrg-ccninfo-15
H. Asaeda, A. Ooka, X. Shao		402022-10-07
RFC-EDITOR		6.914.9draft-ietf-lpwan-schc-yang-data-model-21
A. Minaburo, L. Toutain		542022-10-10
RFC-EDITOR*A		5.714.7draft-ietf-regext-tmch-func-spec-15
G. Lozano		642022-10-11
RFC-EDITOR		1.314.4draft-ietf-cose-x509-09
J. Schaad		C442142022-10-13
RFC-EDITOR		5.714.4draft-ietf-dots-robust-blocks-06
M. Boucadair, J. Shallow		222022-10-13
RFC-EDITOR		6.312.9draft-ietf-pce-vn-association-11
Y. Lee, H. Zheng, D. Ceccarelli		132022-10-24
RFC-EDITOR		4.412.9draft-smyshlyaev-tls13-gost-suites-08
S. Smyshlyaev, Ed., E. Alekseev, E. Griboedova, A. Babueva, L. Nikiforova		852022-10-24
RFC-EDITOR		0.612.6draft-ietf-dnsop-dnssec-bcp-06
P. Hoffman		112022-10-26
RFC-EDITOR*R		1.310.4draft-ietf-quic-v2-10
M. Duke		C468182022-11-10
RFC-EDITOR		1.310.4draft-ietf-quic-version-negotiation-14
D. Schinazi, E. Rescorla		C468182022-11-10
RFC-EDITOR		1.98.6draft-ietf-ippm-ioam-conf-state-10
X. Min, G. Mirsky, L. Bo		192022-11-23
AUTH48		10.716.6draft-ietf-avtcore-cryptex-08
J. Uberti, C. Jennings, S. Murillo		232022-09-28
AUTH48		5.316.6draft-ietf-lsr-isis-rfc5316bis-07
M. Chen, L. Ginsberg, S. Previdi, D. Xiaodong		212022-09-28
AUTH48		4.615.6draft-irtf-qirg-principles-11
W. Kozlowski, S. Wehner, R. Van Meter, B. Rijsman, A. S. Cacciapuoti, M. Caleffi, S. Nagayama		462022-10-05
AUTH48		0.315.4draft-ietf-lsr-ospf-bfd-strict-mode-10
K. Talaulikar, Ed., P. Psenak, A. Fu, M. Rajesh		112022-10-06
AUTH48*R		4.415.3draft-ietf-lsr-flex-algo-26
P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, A. Gulko		C447512022-10-07
AUTH48*R		1.913.3draft-ietf-ipsecme-mib-iptfs-11
D. Fedyk, E. Kinzie		C464222022-10-21
AUTH48		1.612.9draft-ietf-pce-lsp-extended-flags-09
Q. Xiong		102022-10-24
AUTH48-DONE		0.320.9draft-ietf-idr-bgp-ls-flex-algo-12
K. Talaulikar, Ed., P. Psenak, S. Zandi, G. Dawra		C447162022-08-29
AUTH48-DONE		1.717.4draft-ietf-ipsecme-iptfs-19
C. Hopps		C464362022-09-22
AUTH48-DONE*R		0.717.3draft-ietf-ipsecme-yang-iptfs-11
D. Fedyk, C. Hopps		C464282022-09-23
AUTH48-DONE		0.315.3draft-ietf-lsr-ospf-l2bundles-10
K. Talaulikar, Ed., P. Psenak		122022-10-07
MISSREF*R(1G)		288.7289.3draft-ietf-avtext-lrr-07
J. Lennox, D. Hong, J. Uberti, S. Holmer, M. Flodman		C324152017-07-07
MISSREF*R(1G)		253.6253.9draft-ietf-trill-ecn-support-07
D. Eastlake 3rd, B. Briscoe		C350202018-03-12
MISSREF*R(1G)		161.9161.9draft-ietf-i2nsf-applicability-18
J. Jeong, S. Hyun, T. Ahn, S. Hares, D. Lopez		C405292019-12-16
MISSREF*R(1G)		95.698.3draft-ietf-mpls-rfc6374-sfl-10
S. Bryant, Ed., G. Swallow, M. Chen, G. Fioccola, G. Mirsky		C436212021-03-05
MISSREF*R(1G)		71.671.9draft-ietf-oauth-jwt-introspection-response-12
T. Lodderstedt, Ed., V. Dzhuvinov		C444192021-09-06
MISSREF*R(1G)		69.669.9draft-ietf-babel-yang-model-13
M. Jethanandani, B. Stark		C321432021-09-20
MISSREF*R(1G)		42.654.7draft-ietf-bess-evpn-bum-procedure-updates-14
Z. Zhang, W. Lin, J. Rabadan, K. Patel, A. Sajassi		C448212022-01-04
MISSREF*R(1G)		45.746.4draft-ietf-netconf-sztp-csr-14
K. Watsen, R. Housley, S. Turner		C321362022-03-03
MISSREF*R(1G)		44.945.9draft-ietf-ecrit-similar-location-19
B. Rosen, R. Marshall, J. Martin		C452192022-03-07
MISSREF*R(1G)		42.443.9draft-ietf-pce-binding-label-sid-15
S. Sivabalan, C. Filsfils, J. Tantsura, S. Previdi, C. Li, Ed.		C454242022-03-21
MISSREF*R(1G)		40.943.9draft-ietf-alto-performance-metrics-28
Q. Wu, Y. Yang, Y. Lee, D. Dhody, S. Randriamasy, L. Contreras		C453392022-03-21
MISSREF*R(1G)		41.943.6draft-ietf-ace-mqtt-tls-profile-17
C. Sengul, A. Kirby		C442442022-03-23
MISSREF*R(1G)		35.936.6draft-briscoe-docsis-q-protection-06
B. Briscoe, Ed., G. White		C350322022-05-11
MISSREF*R(1G)		34.435.9draft-ietf-i2nsf-capability-data-model-32
S. Hares, Ed., J. Jeong, Ed., J. Kim, R. Moskowitz, Q. Lin		C405732022-05-16
MISSREF*R(1G)		33.434.9draft-ietf-rats-yang-tpm-charra-21
H. Birkholz, M. Eckel, S. Bhandari, E. Voit, B. Sulzen, L. Xia, T. Laffey, G. Fedorkow		C455592022-05-23
MISSREF*R(1G)		33.734.6draft-ietf-dnsop-svcb-https-11
B. Schwartz, M. Bishop, E. Nygren		C461622022-05-25
MISSREF*R(1G)		32.432.4draft-ietf-lamps-cmp-algorithms-15
H. Brockhaus, H. Aschauer, M. Ounsworth, J. Gray		C458332022-06-09
MISSREF*R(1G)		29.930.7draft-ietf-sidrops-8210bis-10
R. Bush, R. Austein		C460382022-06-21
MISSREF*R(1G)		25.426.6draft-ietf-lamps-cmp-updates-23
H. Brockhaus, Ed., D. von Oheimb, J. Gray		C458722022-07-20
MISSREF*R(1G)		17.918.9draft-ietf-tcpm-yang-tcp-09
M. Scharf, M. Jethanandani, V. Murgai		C463292022-09-12
MISSREF*R(1G)		4.95.1draft-irtf-pearg-numeric-ids-history-11
F. Gont, I. Arce		C470322022-12-17
MISSREF*R(1G)		4.95.1draft-irtf-pearg-numeric-ids-generation-12
F. Gont, I. Arce		C470432022-12-17
MISSREF*R(2G)		83.984.4draft-ietf-payload-vp9-16
J. Uberti, S. Holmer, M. Flodman, D. Hong, J. Lennox		C324252021-06-10
MISSREF*R(2G)		51.451.7draft-ietf-bess-evpn-optimized-ir-12
J. Rabadan, Ed., S. Sathappan, W. Lin, M. Katiyar, A. Sajassi		C448342022-01-25
MISSREF*R(2G)		16.643.7draft-ietf-rats-tpm-based-network-device-attest-14
G. Fedorkow, Ed., E. Voit, J. Fitzgerald-McKay		C455442022-03-22
MISSREF*R(2G)		34.435.9draft-ietf-i2nsf-nsf-facing-interface-dm-29
J. Kim, Ed., J. Jeong, Ed., J. Park, S. Hares, Q. Lin		C405812022-05-16
MISSREF*R(2G)		34.435.6draft-ietf-i2nsf-nsf-monitoring-data-model-20
J. Jeong, P. Lingga, S. Hares, L. Xia, H. Birkholz		C405992022-05-18
MISSREF*R(2G)		20.321.9draft-ietf-add-ddr-10
T. Pauly, E. Kinnear, C. Wood, P. McManus, T. Jensen		C461202022-08-22
MISSREF*R(2G)		21.321.9draft-ietf-add-svcb-dns-07
B. Schwartz		C461122022-08-22
MISSREF*R(2G)		19.621.9draft-ietf-add-dnr-13
M. Boucadair, Ed., T. Reddy, Ed., D. Wing, N. Cook, T. Jensen		C461262022-08-22
REF*R		12.748.9draft-irtf-cfrg-spake2-26
W. Ladd, B. Kaduk, Ed.		C450172022-02-14
IANA		5.626.6draft-ietf-sacm-coswid-22
H. Birkholz, J. Fitzgerald-McKay, C. Schmidt, D. Waltermire		C455822022-07-20


./draft-ietf-i2nsf-capability-data-model-32.txt0000644000764400076440000043225514242644521021035 0ustar iustiniustin I2NSF Working Group S. Hares, Ed. Internet-Draft Huawei Intended status: Standards Track J. Jeong, Ed. Expires: 24 November 2022 J. Kim Sungkyunkwan University R. Moskowitz HTT Consulting Q. Lin Huawei 23 May 2022 I2NSF Capability YANG Data Model draft-ietf-i2nsf-capability-data-model-32 Abstract This document defines an information model and the corresponding YANG data model for the capabilities of various Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework to centrally manage the capabilities of the various NSFs. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 November 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Hares, et al. Expires 24 November 2022 [Page 1] Internet-Draft I2NSF Capability YANG Data Model May 2022 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements of I2NSF NSF Capability . . . . . . . . . . . . 4 3.1. Design Principles and ECA Policy Model . . . . . . . . . 5 3.2. Conflict, Resolution Strategy and Default Action . . . . 9 4. Overview of YANG Data Model . . . . . . . . . . . . . . . . . 11 5. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Network Security Function (NSF) Capabilities . . . . . . 13 6. YANG Data Model of I2NSF NSF Capability . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 54 9. Security Considerations . . . . . . . . . . . . . . . . . . . 55 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 10.1. Normative References . . . . . . . . . . . . . . . . . . 56 10.2. Informative References . . . . . . . . . . . . . . . . . 62 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 63 A.1. Example 1: Registration for the Capabilities of a General Firewall . . . . . . . . . . . . . . . . . . . . . . . . 63 A.2. Example 2: Registration for the Capabilities of a Time-based Firewall . . . . . . . . . . . . . . . . . . . 65 A.3. Example 3: Registration for the Capabilities of a Web Filter . . . . . . . . . . . . . . . . . . . . . . . . . 67 A.4. Example 4: Registration for the Capabilities of a VoIP/VoCN Filter . . . . . . . . . . . . . . . . . . . . . . . . . 68 A.5. Example 5: Registration for the Capabilities of an HTTP and HTTPS Flood Mitigator . . . . . . . . . . . . . . . . . . 69 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 70 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 71 Appendix D. Changes from draft-ietf-i2nsf-capability-data-model-31 . . . . . . . . 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 1. Introduction As the industry becomes more sophisticated and network devices (e.g., Internet-of-Things (IoT) devices, autonomous vehicles, and smartphones using Voice over Internet Protocol (VoIP) and Voice over Cellular Network, such as LTE and 5G (VoCN)) require advanced security protection in various scenarios, security service providers have a lot of problems described in [RFC8192] to provide such network devices with efficient and reliable security services in network Hares, et al. Expires 24 November 2022 [Page 2] Internet-Draft I2NSF Capability YANG Data Model May 2022 infrastructure. To resolve these problems, this document specifies the information and data models of the capabilities of Network Security Functions (NSFs) in a framework of the Interface to Network Security Functions (I2NSF) [RFC8329]. NSFs produced by multiple security vendors provide various security capabilities to customers. Multiple NSFs can be combined to provide security services over the given network traffic, regardless of whether the NSFs are implemented as physical or virtual functions. Security Capabilities describe the functions that Network Security Functions (NSFs) can provide for security policy enforcement. Security Capabilities are independent of the actual security policy that will implement the functionality of the NSF. Every NSF should be described with the set of capabilities it offers. Security Capabilities enable security functionality to be described in a vendor-neutral manner. Security Capabilities are a market enabler, providing a way to define customized security protection by unambiguously describing the security features offered by a given NSF. Note that this YANG data model forms the basis of the NSF Monitoring Interface YANG data model [I-D.ietf-i2nsf-nsf-monitoring-data-model] and the NSF-Facing Interface YANG data model [I-D.ietf-i2nsf-nsf-facing-interface-dm]. This document provides an information model and the corresponding YANG data model [RFC6020][RFC7950] that defines the capabilities of NSFs to centrally manage the capabilities of those NSFs. The NSFs can register their own capabilities into a Network Operator Management (Mgmt) System (i.e., Security Controller) with this YANG data model through the registration interface [RFC8329]. With the database of the capabilities of those NSFs that are maintained centrally, those NSFs can be more easily managed [RFC8329]. This YANG data model uses an "Event-Condition-Action" (ECA) policy model that is used as the basis for the design of I2NSF Policy as described in [RFC8329] and Section 3.1. This policy model is not entirely perfect in which a conflict may happen between the configured policies, thus the YANG data model also provides an additional element of conflict resolution as described in Section 3.2. The "ietf-i2nsf-capability" YANG module defined in this document provides the following features: * Definition for event capabilities of network security functions. * Definition for condition capabilities of network security functions. * Definition for action capabilities of network security functions. Hares, et al. Expires 24 November 2022 [Page 3] Internet-Draft I2NSF Capability YANG Data Model May 2022 * Definition for resolution strategy capabilities of network security functions. * Definition for default action capabilities of network security functions. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the terminology described in [RFC8329]. This document follows the guidelines of [RFC8407], uses the common YANG types defined in [RFC6991], and adopts the Network Management Datastore Architecture (NMDA) [RFC8342]. The meaning of the symbols in tree diagrams is defined in [RFC8340]. 3. Requirements of I2NSF NSF Capability This section provides the I2NSF Capability Information Model (CapIM). A CapIM is a formalization of the functionality that an NSF advertises. This enables the precise specification of what an NSF can do in terms of security policy enforcement, so that computer- based tasks can unambiguously refer to, use, configure, and manage NSFs. Capabilities are defined in a vendor- and technology- independent manner (i.e., regardless of the differences among vendors and individual products). Network security experts can refer to categories of security controls and understand each other. For instance, network security experts agree on what is meant by the terms "NAT", "filtering", and "VPN concentrator". As a further example, network security experts unequivocally refer to "packet filters" as devices that allow or deny packet forwarding based on various conditions (e.g., source and destination IP addresses, source and destination ports, and IP protocol type fields) [Alshaer]. However, more information is required in case of other devices, like stateful firewalls or application layer filters. These devices filter packets or communications, but there are differences in the packets and communications that they can categorize and the states they maintain. Network engineers deal with these differences by asking more questions to determine the specific category and functionality of the device. Machines can follow a similar approach, Hares, et al. Expires 24 November 2022 [Page 4] Internet-Draft I2NSF Capability YANG Data Model May 2022 which is commonly referred to as question-answering [Hirschman]. In this context, the CapIM and the derived data model can provide important and rich information sources. Analogous considerations can be applied for channel protection protocols, where we all understand that they will protect packets by means of symmetric algorithms whose keys could have been negotiated with asymmetric cryptography, but they may work at different layers and support different algorithms and protocols. To ensure protection, these protocols apply integrity, optionally confidentiality, anti-reply protections, and authentication. The CapIM is intended to clarify these ambiguities by providing a formal description of NSF functionality. The set of functions that are advertised MAY be restricted according to the privileges of the user or application that is viewing those functions. I2NSF Capabilities enable unambiguous specification of the security capabilities available in a (virtualized) networking environment, and their automatic processing by means of computer-based techniques. This CapIM enables a security controller in an I2NSF framework [RFC8329] to properly identify and manage NSFs, and allow NSFs to properly declare their functionality through a Developer's Management System (DMS) [RFC8329], so that they can be used in the correct way. 3.1. Design Principles and ECA Policy Model This document defines an information model for representing NSF capabilities. Some basic design principles for security capabilities and the systems that manage them are: * Independence: Each security capability (e.g., events, conditions, and actions) SHOULD be an independent function, with minimum overlap or dependency on other capabilities. This enables each security capability to be utilized and assembled with other security capabilities together freely. More importantly, changes to one capability SHOULD NOT affect other capabilities. This follows the Single Responsibility Principle [Martin] [OODSRP]. * Abstraction: Each capability MUST be defined in a vendor- independent manner. * Advertisement: The Registration Interface [I-D.ietf-i2nsf-registration-interface-dm] MUST be used to advertise and register the capabilities of each NSF. This same interface MUST be used by other I2NSF Components to determine what Capabilities are currently available to them. Hares, et al. Expires 24 November 2022 [Page 5] Internet-Draft I2NSF Capability YANG Data Model May 2022 * Execution: The NSF-Facing Interface [I-D.ietf-i2nsf-nsf-facing-interface-dm] and NSF Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model] MUST be used to configure the use of a capability into an NSF and monitor the NSF, respectively. These provide a standardized ability to describe its functionality, and report its processing results, respectively. These facilitate multivendor interoperability. * Automation: The system MUST have the ability to auto-discover, auto-negotiate, and auto-update the information of an NSF's registered security capabilities without human intervention. These features are especially useful for the management of a large number of NSFs. They are essential for adding smart services (e.g., refinement, analysis, capability reasoning, and optimization) to the security scheme employed. These features are supported by many design patterns, including the Observer Pattern [OODOP], the Mediator Pattern [OODMP], and a set of Message Exchange Patterns [Hohpe]. The Registration Interface [I-D.ietf-i2nsf-registration-interface-dm] can register the capabilities of NSFs with the security controller from the request of a Developer's Management System, providing a list of available NSFs, the corresponding security capabilities, and access information to the security controller. Also, this interface can send a query to Developer's Management System in order to find an NSF to satisfy the requested security capability from the security controller that receives a security policy. * Scalability: The management system SHOULD have the capability to scale up/down or scale in/out. Thus, it can meet various performance requirements derived from changeable network traffic or service requests. In addition, security capabilities that are affected by scalability changes SHOULD support reporting statistics to the security controller to assist its decision on whether it needs to invoke scaling or not. The NSF Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model] can observe the performance of NSFs to let the security controller decide scalability changes of the NSFs. Based on the above principles, this document defines a capability model that enables an NSF to register (and hence advertise) its set of capabilities that other I2NSF Components can use. These capabilities MUST have their access control restricted by a policy and the mechanism of access control is RECOMMENDED to follow the mechanism described in Network Configuration Access Control Model (NACM) [RFC8341]; the policy that determines which components are granted which access is out of scope for this document. The set of capabilities provided by a given set of NSFs defines the security services offered by the set of NSFs used. The security controller Hares, et al. Expires 24 November 2022 [Page 6] Internet-Draft I2NSF Capability YANG Data Model May 2022 can compare the requirements of users and applications with the set of capabilities that are currently available in order to choose which capabilities of which NSFs are needed to meet those requirements. Note that this choice is independent of vendor, and instead relies specifically on the capabilities (i.e., the description) of the functions provided. Furthermore, NSFs are subject to the updates of security capabilities and software to cope with newly found security attacks or threats, hence new capabilities may be created, and/or existing capabilities may be updated (e.g., by updating its signature and algorithm). New capabilities may be sent to and stored in a centralized repository, or stored separately in a vendor's local repository. In either case, the Registration Interface can facilitate this update process so the Developer's Management System can let the security controller update its repository for NSFs and their security capabilities. The "Event-Condition-Action" (ECA) policy model in [RFC8329] is used as the basis for the design of the capability model; The following three terms define the structure and behavior of an I2NSF imperative policy rule: * Event: An Event is defined as any important occurrence in time of a change in the system being managed, and/or in the environment of the system being managed. When used in the context of I2NSF Policy Rules, it is used to determine whether the condition clause of an I2NSF Policy Rule can be evaluated or not. Examples of an I2NSF Event include time and user actions (e.g., logon, logoff, and actions that violate an ACL). * Condition: A condition is defined as a set of attributes, features, and/or values that are to be compared with a set of known attributes, features, and/or values in order to determine whether the set of actions in that (imperative) I2NSF Policy Rule can be executed or not. Examples of I2NSF conditions include matching attributes of a packet or flow, and comparing the internal state of an NSF with a desired state. * Action: An action is used to control and monitor aspects of NSFs to handle packets or flows when the event and condition clauses are satisfied. NSFs provide security functions by executing various Actions. Examples of I2NSF actions include providing intrusion detection and/or protection, web filtering (i.e., URL filtering) and flow filtering, and deep packet inspection for packets and flows. Hares, et al. Expires 24 November 2022 [Page 7] Internet-Draft I2NSF Capability YANG Data Model May 2022 An I2NSF Policy Rule is made up of three clauses: an Event clause, a Condition clause, and an Action clause. This structure is also called an ECA (Event-Condition-Action) Policy Rule. A Boolean clause is a logical statement that evaluates to either TRUE or FALSE. It may be made up of one or more terms; if more than one term is present, then each term in the Boolean clause is combined using logical connectives (i.e., AND, OR, and NOT). An I2NSF ECA Policy Rule has the following semantics: IF is TRUE IF is TRUE THEN execute [constrained by metadata] END-IF END-IF Technically, the "Policy Rule" is really a container that aggregates the above three clauses, as well as metadata which describe the characteristics and behaviors of a capability (or an NSF). One example of metadata that has been well-associated with a network access control list is priority. Priority information is usually given to a rule as a numerical value to control the execution order of the rules. Associating a priority value an ECA policy enables a business logic to be used to prescribe a behavior. For example, suppose that a particular ECA Policy Rule contains three actions (A1, A2, and A3 in order). Action A2 has a priority of 10; actions A1 and A3 have no priority specified. Then, metadata may be used to restrict the set of actions that can be executed when the event and condition clauses of this ECA Policy Rule are evaluated to be TRUE; two examples are: (1) only the first action (A1) is executed, and then the policy rule returns to its caller, or (2) all actions are executed, starting with the highest priority. The above ECA policy model is very general and easily extensible. For example, when an NSF has both url filtering capability and packet filtering capability for protocol headers, it means that it can match the URL as well as the Ethernet header, IP header, and Transport header for packet filtering. The condition capability for url filtering and packet filtering is not tightly linked to the action capability due to the independence of our ECA design principle. The action capability only lists the type of action that the NSF can take to handle the matched packets. Hares, et al. Expires 24 November 2022 [Page 8] Internet-Draft I2NSF Capability YANG Data Model May 2022 3.2. Conflict, Resolution Strategy and Default Action Formally, two I2NSF Policy Rules conflict with each other if: * the Event Clauses of each evaluate to TRUE; * the Condition Clauses of each evaluate to TRUE; * the Action Clauses affect the same object in different ways. For example, if we have two Policy Rules called R1 and R2 in the same Policy: R1: During 8am-6pm, if traffic is external, then run through firewall R2: During 7am-8pm, run antivirus There is no conflict between the two policy rules R1 and R2, since the policy rules act on different conditions, where firewall verifies the packet header while antivirus verifies the contents. However, consider these two rules called R3 and R4: R3: During 9am-6pm, allow John to access social networking service websites R4: During 9am-6pm, disallow all users to access social networking service websites The two policy rules R3 and R4 are now in conflict, between the hours of 9am and 6pm, because the actions of R3 and R4 are different and apply to the same user (i.e., John). Conflicts theoretically compromise the correct functioning of devices. However, NSFs have been designed to cope with these issues. Since conflicts are originated by simultaneously matching rules, an additional process decides the action to be applied, e.g., among the actions which the matching rule would have enforced. This process is described by means of a resolution strategy for conflicts. The finding and handling of conflicted matching rules is performed by resolution strategies. Some concrete examples of a resolution strategy are: * First Matching Rule (FMR) * Last Matching Rule (LMR) Hares, et al. Expires 24 November 2022 [Page 9] Internet-Draft I2NSF Capability YANG Data Model May 2022 * Prioritized Matching Rule (PMR) with Errors (PMRE) * Prioritized Matching Rule with No Errors (PMRN) In the above, a PMR strategy is defined as follows: 1. Order all actions by their Priority (highest is first, no priority is last); actions that have the same priority may be appear in any order in their relative location. 2. For PMRE: if any action fails to execute properly, temporarily stop the execution of all actions. Invoke the error handler of the failed action. If the error handler is able to recover from the error, then continue the execution of any remaining actions; else, terminate the execution of the ECA Policy Rule having those all actions. 3. For PMRN: if any action fails to execute properly, stop the execution of all actions. Invoke the error handler of the failed action, but regardless of the result, the execution of the ECA Policy Rule having those all actions MUST be terminated. On the other hand, it may happen that, if an event is caught, none of the policy rules matches the condition. Note that a packet or flow is handled only when it matches both the event and condition of a policy rule according to the ECA policy model. As a simple case, no condition in the rules may match a packet arriving at the border firewall. In this case, the packet is usually dropped, that is, the firewall has a default behavior of packet dropping in order to manage the cases that are not covered by specific rules. Therefore, this document introduces two further capabilities for an NSF to handle security policy conflicts with resolution strategies and enforce a default action if no rules match. * Resolution Strategies: They can be used to specify how to resolve conflicts that occur between the actions of the similar or different policy rules that are matched and contained in this particular NSF; note that a badly written policy rule may cause a conflict of actions with another similar policy rule. * Default Action: It provides the default behavior to be executed when there are no other alternatives. This action can be either an explicit action or a set of actions. Hares, et al. Expires 24 November 2022 [Page 10] Internet-Draft I2NSF Capability YANG Data Model May 2022 4. Overview of YANG Data Model This section provides an overview of how the YANG data model can be used in the I2NSF framework described in [RFC8329]. Figure 1 shows the capabilities (e.g., firewall and web filter) of NSFs in the I2NSF Framework. As shown in this figure, a Developer's Management System (DMS) can register NSFs and their capabilities with a Security Controller. To register NSFs in this way, the DMS utilizes the standardized capability YANG data model in this document through the I2NSF Registration Interface [RFC8329]. That is, this Registration Interface uses the YANG module described in this document to describe the capabilities of an NSF that is registered with the Security Controller. As described in [RFC8192], with the usage of the Registration Interface and the YANG module in this document, the capabilities registration of NSFs manufactured by multiple vendors can be done together by the Security Controller in a centralized way, and the information of the registered Capabilities in the Security Controller information should be updated dynamically by each vendor as the NSF may have software or hardware updates. In Figure 1, a new NSF at a Developer's Management System has capabilities of Firewall (FW) and Web Filter (WF), which are denoted as (Cap = {FW, WF}), to support Event-Condition-Action (ECA) policy rules where 'E', 'C', and 'A' mean "Event", "Condition", and "Action", respectively. The condition involves IPv4 or IPv6 datagrams, and the action includes "Allow" and "Deny" for those datagrams. Note that "E = {}" means that the event boolean will always evaluate to true. Note that the NSF-Facing Interface [RFC8329] is used by the Security Controller to configure the security policy rules of NSFs (e.g., firewall and Distributed Denial-of-Service (DDoS) attack mitigator) with the capabilities of the NSFs registered with the Security Controller. Hares, et al. Expires 24 November 2022 [Page 11] Internet-Draft I2NSF Capability YANG Data Model May 2022 +------------------------------------------------------+ | I2NSF User (e.g., Overlay Network Mgmt, Enterprise | | Network Mgmt, another network domain's mgmt, etc.) | +--------------------+---------------------------------+ I2NSF ^ Consumer-Facing Interface| | v I2NSF +-----------------+------------+ Registration +-------------+ | Network Operator Mgmt System | Interface | Developer's | | (i.e., Security Controller) |<------------>| Mgmt System | +-----------------+------------+ +-------------+ ^ New NSF | Cap = {FW, WF} I2NSF | E = {} NSF-Facing Interface | C = {IPv4, IPv6} | A = {Allow, Deny} v +---------------+----+------------+-----------------+ | | | | +---+---+ +---+---+ +---+---+ +---+---+ | NSF-1 | ... | NSF-m | | NSF-1 | ... | NSF-n | +-------+ +-------+ +-------+ +-------+ NSF-1 NSF-m NSF-1 NSF-n Cap = {FW, WF} Cap = {FW, WF} Cap = {FW, WF} Cap = {FW, WF} E = {} E = {user} E = {dev} E = {} C = {IPv4} C = {IPv6} C = {IPv4, IPv6} C = {IPv4, time} A = {Allow,Deny} A = {Allow,Deny} A = {Allow,Deny} A = {Allow,Deny} Developer's Mgmt System A Developer's Mgmt System B Figure 1: Capabilities of NSFs in I2NSF Framework A use case of an NSF with the capabilities of firewall and web filter is described as follows. * If a network administrator wants to apply security policy rules to block malicious users with firewall and web filter, it is a tremendous burden for a network administrator to apply all of the needed rules to NSFs one by one. This problem can be resolved by managing the capabilities of NSFs as described in this document. * If a network administrator wants to block IPv4 or IPv6 packets from malicious users, the network administrator sends a security policy rule to the Network Operator Management System (i.e., Security Controller) using the I2NSF Consumer-Facing Interface, directing the system to block the users in question. Hares, et al. Expires 24 November 2022 [Page 12] Internet-Draft I2NSF Capability YANG Data Model May 2022 * When the Network Operator Management System receives the security policy rule, it automatically sends that security policy rule to appropriate NSFs (i.e., NSF-m in Developer's Management System A and NSF-1 in Developer's Management System B) which can support the capabilities (i.e., IPv6). This lets an I2NSF User not consider which specific NSF(s) will work for the security policy rule. * If NSFs encounter the suspicious IPv4 or IPv6 packets of malicious users, they can filter the packets out according to the configured security policy rule. Therefore, the security policy rule against the malicious users' packets can be automatically applied to appropriate NSFs without human intervention. 5. YANG Tree Diagram This section shows a YANG tree diagram of capabilities of network security functions, as defined in the Section 3. 5.1. Network Security Function (NSF) Capabilities This section explains a YANG tree diagram of NSF capabilities and its features. Figure 2 shows a YANG tree diagram of NSF capabilities. The NSF capabilities in the tree include directional capabilities, event capabilities, condition capabilities, action capabilities, resolution strategy capabilities, and default action capabilities. Those capabilities can be tailored or extended according to a vendor's specific requirements. Refer to the NSF capabilities information model for detailed discussion in Section 3. Hares, et al. Expires 24 November 2022 [Page 13] Internet-Draft I2NSF Capability YANG Data Model May 2022 module: ietf-i2nsf-capability +--rw nsf* [nsf-name] +--rw nsf-name string +--rw directional-capabilities* identityref +--rw event-capabilities | +--rw system-event-capability* identityref | +--rw system-alarm-capability* identityref +--rw condition-capabilities | +--rw generic-nsf-capabilities | | +--rw ethernet-capability* identityref | | +--rw ipv4-capability* identityref | | +--rw ipv6-capability* identityref | | +--rw icmpv4-capability* identityref | | +--rw icmpv6-capability* identityref | | +--rw tcp-capability* identityref | | +--rw udp-capability* identityref | | +--rw sctp-capability* identityref | | +--rw dccp-capability* identityref | +--rw advanced-nsf-capabilities | | +--rw anti-ddos-capability* identityref | | +--rw ips-capability* identityref | | +--rw anti-virus-capability* identityref | | +--rw url-filtering-capability* identityref | | +--rw voip-vocn-filtering-capability* identityref | +--rw context-capabilities | +--rw time-capabilities* identityref | +--rw application-filter-capabilities* identityref | +--rw device-type-capabilities* identityref | +--rw user-condition-capabilities* identityref | +--rw geographic-capabilities* identityref +--rw action-capabilities | +--rw ingress-action-capability* identityref | +--rw egress-action-capability* identityref | +--rw log-action-capability* identityref +--rw resolution-strategy-capabilities* identityref +--rw default-action-capabilities* identityref Figure 2: YANG Tree Diagram of Capabilities of Network Security Functions The data model in this document provides identities for the capabilities of NSFs. Every identity in the data model represents the capability of an NSF. Each identity is explained in the description of the identity. Hares, et al. Expires 24 November 2022 [Page 14] Internet-Draft I2NSF Capability YANG Data Model May 2022 Event capabilities are used to specify the capabilities that describe an event that would trigger the evaluation of the condition clause of the I2NSF Policy Rule. The defined event capabilities are system event and system alarm. Condition capabilities are used to specify capabilities of a set of attributes, features, and/or values that are to be compared with a set of known attributes, features, and/or values in order to determine whether a set of actions needs to be executed or not so that an imperative I2NSF policy rule can be executed. In this document, two kinds of condition capabilities are used to classify different capabilities of NSFs such as generic-nsf-capabilities and advanced-nsf-capabilities. First, the generic-nsf-capabilities define NSFs that operate on packet header for layer 2 (i.e., Ethernet capability), layer 3 (i.e., IPv4 capability, IPv6 capability, ICMPv4 capability, and ICMPv6 capability.), and layer 4 (i.e., TCP capability, UDP capability, SCTP capability, and DCCP capability). Second, the advanced-nsf-capabilities define NSFs that operate on features different from the generic-nsf-capabilities, e.g., the payload, cross flow state, application layer, traffic statistics, network behavior, etc. This document defines the advanced-nsf into two categories such as content-security-control and attack- mitigation-control. * Content security control is an NSF that evaluates the payload of a packet, such as Intrusion Prevention System (IPS), URL-Filtering, Antivirus, and VoIP (Voice over Internet Protocol) / VoCN (Voice over Cellular Network) Filter. * Attack mitigation control is an NSF that mitigates an attack such as anti-DDoS (DDoS-mitigator). The advanced-nsf can be extended with other types of NSFs. This document only provides five advanced-nsf capabilities, i.e., IPS capability, URL-Filtering capability, Antivirus capability, VoIP/VoCN Filter capability, and Anti-DDoS capability. Note that VoIP and VoCN are merged into a single capability in this document because VoIP and VoCN use the Session Initiation Protocol (SIP) [RFC3261] for a call setup. See Section 3.1 for more information about the condition in the ECA policy model. Also note that QUIC protocol [RFC9000] is excluded in the data model as it is not considered in the initial I2NSF documents [RFC8329]. The QUIC traffic should not be treated as UDP traffic and will be considered in the future I2NSF documents. The context capabilities provide extra information for the condition. The given context conditions are application filter, target, user condition, and geographic location. Time capabilities are used to specify the capabilities which describe when to execute the I2NSF Hares, et al. Expires 24 November 2022 [Page 15] Internet-Draft I2NSF Capability YANG Data Model May 2022 policy rule. The time capabilities are defined in terms of absolute time and periodic time, where the absolute time means the exact time to start or end, and the periodic time means repeated time like day, week, month, or year. The application filter capability is the capability for matching the packet based on the application protocol, such as HTTP, HTTPS, FTP, etc. The device type capability is the capability for matching the type of the destination devices, such as PC, IoT, Network Infrastructure devices, etc. The user condition is the capability for matching the users of the network by mapping each user ID to an IP address. Users can be combined into groups. The geographic location capability is the capability for matching the geographical location of a source or destination of a packet. Note that due to the exclusion of QUIC protocol in the I2NSF documents, HTTP/3 is also excluded in the document and will be considered in the future I2NSF documents along with the QUIC protocol. HTTP/3 should not be interpreted as either HTTP/1.1 or HTTP/2. Action capabilities are used to specify the capabilities that describe the control and monitoring aspects of flow-based NSFs when the event and condition clauses are satisfied. The action capabilities are defined as ingress-action capability, egress-action capability, and log-action capability. See Section 3.1 for more information about the action in the ECA policy model. Also, see Section 7.2 (NSF-Facing Flow Security Policy Structure) in [RFC8329] for more information about the ingress and egress actions. In addition, see Section 9.1 (Flow-Based NSF Capability Characterization) in [RFC8329] and Section 6.5 (NSF Logs) in [I-D.ietf-i2nsf-nsf-monitoring-data-model] for more information about logging at NSFs. Resolution strategy capabilities are used to specify the capabilities that describe conflicts that occur between the actions of the similar or different policy rules that are matched and contained in this particular NSF; note that a badly written policy rule may cause a conflict of actions with another similar policy rule. The resolution strategy capabilities are defined as First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized Matching Rule with Error (PMRE), and Prioritized Matching with No Errors (PMRN). See Section 3.2 for more information about the resolution strategy. Default action capabilities are used to specify the capabilities that describe how to execute I2NSF policy rules when no rule matches a packet. The default action capabilities are defined as pass, drop, reject, rate-limit, and mirror. See Section 3.2 for more information about the default action. Hares, et al. Expires 24 November 2022 [Page 16] Internet-Draft I2NSF Capability YANG Data Model May 2022 6. YANG Data Model of I2NSF NSF Capability This section introduces a YANG module for NSFs' capabilities, as defined in the Section 3. It makes references to * [RFC0768] * [RFC0791] * [RFC0792] * [RFC0854] * [RFC0959] * [RFC1939] * [RFC2474] * [RFC2595] * [RFC3022] * [RFC3168] * [RFC3261] * [RFC4250] * [RFC4340] * [RFC4443] * [RFC4766] * [RFC5103] * [RFC5321] * [RFC5595] * [RFC6335] * [RFC6437] * [RFC6691] Hares, et al. Expires 24 November 2022 [Page 17] Internet-Draft I2NSF Capability YANG Data Model May 2022 * [RFC6864] * [RFC7323] * [RFC8075] * [RFC8200] * [RFC8311] * [RFC8329] * [RFC8805] * [RFC9051] * [IEEE802.3-2018] * [IANA-Protocol-Numbers] * [I-D.ietf-httpbis-http2bis] * [I-D.ietf-httpbis-messaging] * [I-D.ietf-httpbis-semantics] * [I-D.ietf-tcpm-rfc793bis] * [I-D.ietf-tcpm-accurate-ecn] * [I-D.ietf-tsvwg-rfc4960-bis] * [I-D.ietf-tsvwg-udp-options] * [I-D.ietf-i2nsf-nsf-monitoring-data-model] file "ietf-i2nsf-capability@2022-05-23.yang" module ietf-i2nsf-capability { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; prefix i2nsfcap; organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; Hares, et al. Expires 24 November 2022 [Page 18] Internet-Draft I2NSF Capability YANG Data Model May 2022 contact "WG Web: WG List: Editor: Susan Hares Editor: Jaehoon (Paul) Jeong Editor: Jinyong (Tim) Kim Editor: Robert Moskowitz Editor: Qiushi Lin Editor: Patrick Lingga "; description "This module is a YANG module for I2NSF Network Security Functions (NSFs)'s Capabilities. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with an actual RFC number and remove // this note. revision "2022-05-23"{ description "Initial revision."; reference "RFC XXXX: I2NSF Capability YANG Data Model"; Hares, et al. Expires 24 November 2022 [Page 19] Internet-Draft I2NSF Capability YANG Data Model May 2022 // RFC Ed.: replace XXXX with an actual RFC number and remove // this note. } /* * Identities */ identity event { description "Base identity for I2NSF events."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-19: I2NSF NSF Monitoring Interface YANG Data Model - Event"; } identity system-event { base event; description "Base identity for system event. System event (also called alert) is defined as a warning about any changes of configuration, any access violation, the information of sessions and traffic flows."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-19: I2NSF NSF Monitoring Interface YANG Data Model - System event"; } identity system-alarm { base event; description "Base identity for system alarm. System alarm is defined as a warning related to service degradation in system hardware."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-19: I2NSF NSF Monitoring Interface YANG Data Model - System alarm"; } identity access-violation { base system-event; description "Identity for access violation event. Access-violation system event is an event when a user tries to access (read, write, create, or delete) any information or execute commands above their privilege (i.e., not-conformant with the access profile)."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-19: I2NSF NSF Hares, et al. Expires 24 November 2022 [Page 20] Internet-Draft I2NSF Capability YANG Data Model May 2022 Monitoring Interface YANG Data Model - System event for access violation"; } identity configuration-change { base system-event; description "Identity for configuration change event. Configuration change is a system event when a new configuration is added or an existing configuration is modified."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-19: I2NSF NSF Monitoring Interface YANG Data Model - System event for configuration change"; } identity memory-alarm { base system-alarm; description "Memory is the hardware to store information temporarily or for a short period, i.e., Random Access Memory (RAM). A memory-alarm is emitted when the memory usage is exceeding the threshold."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-19: I2NSF NSF Monitoring Interface YANG Data Model - System alarm for memory"; } identity cpu-alarm { base system-alarm; description "CPU is the Central Processing Unit that executes basic operations of the system. A cpu-alarm is emitted when the CPU usage is exceeding a threshold."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-19: I2NSF NSF Monitoring Interface YANG Data Model - System alarm for CPU"; } identity disk-alarm { base system-alarm; description "Disk or storage is the hardware to store information for a long period, i.e., Hard Disk and Solid-State Drive. A disk-alarm is emitted when the disk usage is exceeding a threshold."; reference Hares, et al. Expires 24 November 2022 [Page 21] Internet-Draft I2NSF Capability YANG Data Model May 2022 "draft-ietf-i2nsf-nsf-monitoring-data-model-19: I2NSF NSF Monitoring Interface YANG Data Model - System alarm for disk"; } identity hardware-alarm { base system-alarm; description "A hardware alarm is emitted when a hardware failure (e.g., CPU, memory, disk, or interface) is detected. A hardware failure is a malfunction within the electronic circuits or electromechanical components of the hardware that makes it unusable."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-19: I2NSF NSF Monitoring Interface YANG Data Model - System alarm for hardware"; } identity interface-alarm { base system-alarm; description "Interface is the network interface for connecting a device with the network. The interface-alarm is emitted when the state of the interface is changed."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-19: I2NSF NSF Monitoring Interface YANG Data Model - System alarm for interface"; } identity time { description "Base identity for time capabilities"; } identity absolute-time { base time; description "absolute time capabilities. If a network security function has the absolute time capability, the network security function supports rule execution according to absolute time."; } identity periodic-time { base time; description "periodic time capabilities. Hares, et al. Expires 24 November 2022 [Page 22] Internet-Draft I2NSF Capability YANG Data Model May 2022 If a network security function has the periodic time capability, the network security function supports rule execution according to periodic time."; } identity device-type { description "Base identity for device type condition capability. The capability for matching the source or destination device type."; } identity computer { base device-type; description "Identity for computer such as personal computer (PC) and server"; } identity mobile-phone { base device-type; description "Identity for mobile-phone such as smartphone and cellphone"; } identity voip-vocn-phone { base device-type; description "Identity for VoIP (Voice over Internet Protocol) or VoCN (Voice over Cellular Network, such as Voice over LTE or 5G) phone"; } identity tablet { base device-type; description "Identity for tablet"; } identity network-infrastructure-device { base device-type; description "Identity for network infrastructure devices such as switch, router, and access point"; } identity iot { Hares, et al. Expires 24 November 2022 [Page 23] Internet-Draft I2NSF Capability YANG Data Model May 2022 base device-type; description "Identity for Internet of Things (IoT) devices such as sensors, actuators, and low-power low-capacity computing devices"; } identity ot { base device-type; description "Identity for Operational Technology (OT) devices (also known as industrial control systems) that interact with the physical environment and detect or cause direct change through the monitoring and control of devices, processes, and events such as programmable logic controllers (PLCs), digital oscilloscopes, building management systems (BMS), and fire control systems"; } identity vehicle { base device-type; description "Identity for transportation vehicles that connect to and share data through the Internet over Vehicle-to-Everything (V2X) communications."; } identity user-condition { description "Base identity for user condition capability. This is the capability of mapping user(s) into their corresponding IP address"; } identity user { base user-condition; description "Identity for user condition capability. A user (e.g., employee) can be mapped to an IP address of a computing device (e.g., computer, laptop, and virtual machine) which the user is using."; } identity group { base user-condition; description "Identity for group condition capability. A group (e.g., employees) can be mapped to multiple IP Hares, et al. Expires 24 November 2022 [Page 24] Internet-Draft I2NSF Capability YANG Data Model May 2022 addresses of computing devices (e.g., computers, laptops, and virtual machines) which the group is using."; } identity geographic-location { description "Base identity for geographic location condition capability"; reference "RFC 8805: A Format for Self-Published IP Geolocation Feeds - An access control for a geographical location (i.e., geolocation) that has the corresponding IP prefix."; } identity source-location { base geographic-location; description "Identity for source geographic location condition capability"; reference "RFC 8805: A Format for Self-Published IP Geolocation Feeds - An access control for a geographical location (i.e., geolocation) that has the corresponding IP prefix."; } identity destination-location { base geographic-location; description "Identity for destination geographic location condition capability"; reference "RFC 8805: A Format for Self-Published IP Geolocation Feeds - An access control for a geographical location (i.e., geolocation) that has the corresponding IP prefix."; } identity directional { description "Base identity for directional traffic flow export capability"; reference "RFC 5103: Bidirectional Flow Export Using IP Flow Information Export (IPFIX) - Terminology Unidirectional and Bidirectional Flow"; } identity unidirectional { base directional; description "Identity for unidirectional traffic flow export."; reference Hares, et al. Expires 24 November 2022 [Page 25] Internet-Draft I2NSF Capability YANG Data Model May 2022 "RFC 5103: Bidirectional Flow Export Using IP Flow Information Export (IPFIX) - Terminology Unidirectional Flow"; } identity bidirectional { base directional; description "Identity for bidirectional traffic flow export."; reference "RFC 5103: Bidirectional Flow Export Using IP Flow Information Export (IPFIX) - Terminology Bidirectional Flow"; } identity protocol { description "Base identity for protocols"; } identity ethernet { base protocol; description "Base identity for Ethernet protocol."; } identity source-mac-address { base ethernet; description "Identity for the capability of matching Media Access Control (MAC) source address(es) condition capability."; reference "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; } identity destination-mac-address { base ethernet; description "Identity for the capability of matching Media Access Control (MAC) destination address(es) condition capability."; reference "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; } identity ether-type { base ethernet; description "Identity for the capability of matching the EtherType in Ethernet II and Length in Ethernet 802.3 of a packet."; reference Hares, et al. Expires 24 November 2022 [Page 26] Internet-Draft I2NSF Capability YANG Data Model May 2022 "IEEE 802.3 - 2018: IEEE Standard for Ethernet"; } identity ip { base protocol; description "Base identity for internet/network layer protocol, e.g., IPv4, IPv6, and ICMP."; } identity ipv4 { base ip; description "Base identity for IPv4 condition capability"; reference "RFC 791: Internet Protocol"; } identity ipv6 { base ip; description "Base identity for IPv6 condition capabilities"; reference "RFC 8200: Internet Protocol, Version 6 (IPv6) Specification"; } identity dscp { base ipv4; base ipv6; description "Identity for the capability of matching IPv4 annd IPv6 Differentiated Services Codepoint (DSCP) condition"; reference "RFC 791: Internet Protocol - Type of Service RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Traffic Class"; } identity ecn { base ipv4; base ipv6; description "Identity for the capability of matching IPv4 annd IPv6 Explicit Congestion Notification (ECN) condition"; Hares, et al. Expires 24 November 2022 [Page 27] Internet-Draft I2NSF Capability YANG Data Model May 2022 reference "RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP. RFC 8311: Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation"; } identity total-length { base ipv4; base ipv6; description "Identity for the capability of matching IPv4 Total Length header field or IPv6 Payload Length header field. IPv4 Total Length is the length of datagram, measured in octets, including internet header and data. IPv6 Payload Length is the length of the IPv6 payload, i.e., the rest of the packet following the IPv6 header, measured in octets."; reference "RFC 791: Internet Protocol - Total Length RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Payload Length"; } identity ttl { base ipv4; base ipv6; description "Identity for the capability of matching IPv4 Time-To-Live (TTL) or IPv6 Hop Limit."; reference "RFC 791: Internet Protocol - Time To Live (TTL) RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Hop Limit"; } identity next-header { base ipv4; base ipv6; description "Identity for the capability of matching IPv4 Protocol field and IPv6 Next Header field. Note that IPv4 Protocol field is equivalent to IPv6 Next Header field."; reference "IANA Website: Assigned Internet Protocol Numbers - Protocol Numbers Hares, et al. Expires 24 November 2022 [Page 28] Internet-Draft I2NSF Capability YANG Data Model May 2022 RFC 791: Internet Protocol - Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Next Header"; } identity source-address { base ipv4; base ipv6; description "Identity for the capability of matching IPv4 or IPv6 source address(es) condition capability."; reference "RFC 791: Internet Protocol - Address RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Source Address"; } identity destination-address { base ipv4; base ipv6; description "Identity for the capability of matching IPv4 or IPv6 destination address(es) condition capability."; reference "RFC 791: Internet Protocol - Address RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Destination Address"; } identity flow-direction { base ipv4; base ipv6; description "Identity for flow direction of matching IPv4/IPv6 source or destination address(es) condition capability where a flow's direction is either unidirectional or bidirectional"; reference "RFC 791: Internet Protocol RFC 8200: Internet Protocol, Version 6 (IPv6) Specification"; } identity ihl { base ipv4; description "Identity for matching IPv4 header-length (IHL) condition capability"; reference Hares, et al. Expires 24 November 2022 [Page 29] Internet-Draft I2NSF Capability YANG Data Model May 2022 "RFC 791: Internet Protocol - Header Length"; } identity identification { base ipv4; description "Identity for IPv4 identification condition capability. IPv4 ID field is used for fragmentation and reassembly."; reference "RFC 791: Internet Protocol - Identification RFC 6864: Updated Specification of the IPv4 ID Field - Fragmentation and Reassembly"; } identity fragment-offset { base ipv4; description "Identity for matching IPv4 fragment offset condition capability"; reference "RFC 791: Internet Protocol - Fragmentation Offset"; } identity flow-label { base ipv6; description "Identity for matching IPv6 flow label condition capability"; reference "RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - Flow Label RFC 6437: IPv6 Flow Label Specification"; } identity transport-protocol { base protocol; description "Base identity for Layer 4 protocol condition capabilities, e.g., TCP, UDP, SCTP, and DCCP"; } identity tcp { base transport-protocol; description "Base identity for TCP condition capabilities"; reference "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification"; Hares, et al. Expires 24 November 2022 [Page 30] Internet-Draft I2NSF Capability YANG Data Model May 2022 } identity udp { base transport-protocol; description "Base identity for UDP condition capabilities"; reference "RFC 768: User Datagram Protocol"; } identity sctp { base transport-protocol; description "Base identity for SCTP condition capabilities"; reference "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission Protocol"; } identity dccp { base transport-protocol; description "Base identity for DCCP condition capabilities"; reference "RFC 4340: Datagram Congestion Control Protocol"; } identity source-port-number { base tcp; base udp; base sctp; base dccp; description "Identity for matching TCP, UDP, SCTP, and DCCP source port number condition capability"; reference "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification RFC 768: User Datagram Protocol draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission Protocol RFC 4340: Datagram Congestion Control Protocol"; } identity destination-port-number { base tcp; base udp; base sctp; Hares, et al. Expires 24 November 2022 [Page 31] Internet-Draft I2NSF Capability YANG Data Model May 2022 base dccp; description "Identity for matching TCP, UDP, SCTP, and DCCP destination port number condition capability"; reference "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification"; } identity flags { base ipv4; base tcp; description "Identity for IPv4 flags and TCP control bits (flags) condition capability. Note that this should not be interpreted such that IPv4 flags and TCP flags are similar. If this identity is used under 'ipv4-capability', it indicates the support of matching the IPv4 flags header. If this identity is used under 'tcp-capability', it indicates the support of matching the TCP control bits (flags) header. The IPv4 flags is the three-bit field in IPv4 header to control and identify fragments. The TCP flags is the multiple one-bit fields after the reserved field in TCP header that indicates the connection states or provides additional information."; reference "RFC 791: Internet Protocol - Flags draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification - TCP Header Flags RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP - ECN-Echo (ECE) Flag and Congestion Window Reduced (CWR) Flag draft-ietf-tcpm-accurate-ecn-15: More Accurate ECN Feedback in TCP - ECN-Echo (ECE) Flag and Congestion Window Reduced (CWR) Flag"; } identity options { base tcp; description "Identity for matching TCP options header field condition capability. When an NSF claims to have this capability, the NSF should be able to match the TCP options header field in binary."; reference "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification RFC 6691: TCP Options and Maximum Segment Size Hares, et al. Expires 24 November 2022 [Page 32] Internet-Draft I2NSF Capability YANG Data Model May 2022 RFC 7323: TCP Extensions for High Performance"; } identity data-offset { base tcp; base dccp; description "Identity for matching TCP and DCCP Data Offset condition capability. If this identity is used under 'tcp-capability', it indicates the support of matching the TCP data offset header. If this identity is used under 'sctp-capability', it indicates the support of matching the DCCP data offset header. The TCP Data Offset header field represents the size of the TCP header, expressed in 32-bit words. The DCCP Data Offset is the offset from the start of the packet's DCCP header to the start of its application data area, in 32-bit words."; reference "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification - Data Offset RFC 4340: Datagram Congestion Control Protocol"; } identity reserved { base tcp; description "Identity for TCP header reserved field condition capability. The set of control bits reserved for future used. The control bits are also known as flags. Must be zero in generated segments and must be ignored in received segments, if corresponding future features are unimplemented by the sending or receiving host."; reference "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification"; } identity window-size { base tcp; description "Identity for TCP header Window field condition capability. The number of data octets beginning with the one indicated in the acknowledgment field that the sender of this segment is willing to accept."; reference "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification"; Hares, et al. Expires 24 November 2022 [Page 33] Internet-Draft I2NSF Capability YANG Data Model May 2022 } identity urgent-pointer { base tcp; description "Identity for TCP Urgent Pointer header field condition capability. The Urgent Pointer field in TCP describes the current value of urgent pointer as a positive offset from the sequence number in this segment. The urgent pointer points to the sequence number of the octet following the urgent data. This field is only be interpreted in segments with the URG control bit set."; reference "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification"; } identity length { base udp; base sctp; description "Identity for matching UDP length and SCTP chunk length condition capability. If this identity is used under 'udp-capability', it indicates the support of matching the UDP length header. If this identity is used under 'sctp-capability', it indicates the support of matching the SCTP chunk length header. The UDP length is the length in octets of this user datagram including this header and the datagram. The UDP length can be smaller than the IP transport length for UDP transport layer options. The SCTP chunk length represents the size of the chunk in bytes including the SCTP Chunk type, Chunk flags, Chunk flags, and Chunk Value fields."; reference "RFC 768: User Datagram Protocol - Length draft-ietf-tsvwg-udp-options: Transport Options for UDP draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission Protocol - Chunk Length"; } identity chunk-type { base sctp; description "Identity for SCTP chunk type condition capability"; reference "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission Protocol - Chunk Type"; Hares, et al. Expires 24 November 2022 [Page 34] Internet-Draft I2NSF Capability YANG Data Model May 2022 } identity service-code { base dccp; description "Identity for DCCP Service Code condition capability"; reference "RFC 4340: Datagram Congestion Control Protocol RFC 5595: The Datagram Congestion Control Protocol (DCCP) Service Codes RFC 6335: Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry - Service Code"; } identity icmp { base protocol; description "Base identity for ICMPv4 and ICMPv6 condition capability"; reference "RFC 792: Internet Control Message Protocol RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification - ICMPv6"; } identity icmpv4 { base icmp; description "Base identity for ICMPv4 condition capability"; reference "RFC 792: Internet Control Message Protocol"; } identity icmpv6 { base icmp; description "Base identity for ICMPv6 condition capability"; reference "RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Ver sion 6 (IPv6) Specification - ICMPv6"; } identity type { base icmpv4; base icmpv6; base dccp; Hares, et al. Expires 24 November 2022 [Page 35] Internet-Draft I2NSF Capability YANG Data Model May 2022 description "Identity for ICMPv4, ICMPv6, and DCCP type condition capability"; reference "RFC 792: Internet Control Message Protocol RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification - ICMPv6 RFC 4340: Datagram Congestion Control Protocol"; } identity code { base icmpv4; base icmpv6; description "Identity for ICMPv4 and ICMPv6 code condition capability"; reference "RFC 792: Internet Control Message Protocol RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification - ICMPv6"; } identity application-protocol { base protocol; description "Base identity for Application protocol. Note that a subset of application protocols (e.g., HTTP, HTTPS, FTP, POP3, and IMAP) are handled in this YANG module, rather than all the existing application protocols."; } identity http { base application-protocol; description "The identity for Hypertext Transfer Protocol version 1.1 (HTTP/1.1)."; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics draft-ietf-httpbis-messaging-19: HTTP/1.1"; } identity https { base application-protocol; description "The identity for Hypertext Transfer Protocol version 1.1 (HTTP/1.1) over TLS."; reference Hares, et al. Expires 24 November 2022 [Page 36] Internet-Draft I2NSF Capability YANG Data Model May 2022 "draft-ietf-httpbis-semantics-19: HTTP Semantics draft-ietf-httpbis-messaging-19: HTTP/1.1"; } identity http2 { base application-protocol; description "The identity for Hypertext Transfer Protocol version 2 (HTTP/2)."; reference "draft-ietf-httpbis-http2bis-07: HTTP/2"; } identity https2 { base application-protocol; description "The identity for Hypertext Transfer Protocol version 2 (HTTP/2) over TLS."; reference "draft-ietf-httpbis-http2bis-07: HTTP/2"; } identity ftp { base application-protocol; description "The identity for File Transfer Protocol."; reference "RFC 959: File Transfer Protocol (FTP)"; } identity ssh { base application-protocol; description "The identity for Secure Shell (SSH) protocol."; reference "RFC 4250: The Secure Shell (SSH) Protocol"; } identity telnet { base application-protocol; description "The identity for telnet."; reference "RFC 854: Telnet Protocol"; } identity smtp { base application-protocol; Hares, et al. Expires 24 November 2022 [Page 37] Internet-Draft I2NSF Capability YANG Data Model May 2022 description "The identity for Simple Mail Transfer Protocol."; reference "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; } identity pop3 { base application-protocol; description "The identity for Post Office Protocol 3 (POP3)."; reference "RFC 1939: Post Office Protocol - Version 3 (POP3)"; } identity pop3s { base application-protocol; description "The identity for Post Office Protocol 3 (POP3) over TLS"; reference "RFC 1939: Post Office Protocol - Version 3 (POP3) RFC 2595: Using TLS with IMAP, POP3 and ACAP"; } identity imap { base application-protocol; description "The identity for Internet Message Access Protocol (IMAP)."; reference "RFC 9051: Internet Message Access Protocol (IMAP) - Version 4rev2"; } identity imaps { base application-protocol; description "The identity for Internet Message Access Protocol (IMAP) over TLS"; reference "RFC 9051: Internet Message Access Protocol (IMAP) - Version 4rev2 RFC 2595: Using TLS with IMAP, POP3 and ACAP"; } identity action { description "Base identity for action capability"; } Hares, et al. Expires 24 November 2022 [Page 38] Internet-Draft I2NSF Capability YANG Data Model May 2022 identity log-action { base action; description "Base identity for log-action capability"; } identity ingress-action { base action; description "Base identity for ingress-action capability"; reference "RFC 8329: Framework for Interface to Network Security Functions - Section 7.2"; } identity egress-action { base action; description "Base identity for egress-action capability"; reference "RFC 8329: Framework for Interface to Network Security Functions - Section 7.2"; } identity default-action { base action; description "Base identity for default-action capability"; } identity rule-log { base log-action; description "Identity for rule log. Log the policy rule that has been triggered."; } identity session-log { base log-action; description "Identity for session log. A session is a connection (i.e., traffic flow) of a data plane that includes source and destination of IP addresses and transport port numbers with the protocol used. Log the session that triggered a policy rule."; } identity pass { Hares, et al. Expires 24 November 2022 [Page 39] Internet-Draft I2NSF Capability YANG Data Model May 2022 base ingress-action; base egress-action; base default-action; description "Identity for pass action capability. The pass action allows packet or flow to go through the NSF entering or exiting the internal network."; } identity drop { base ingress-action; base egress-action; base default-action; description "Identity for drop action capability. The drop action denies a packet to go through the NSF entering or exiting the internal network without sending any response back to the source."; } identity reject { base ingress-action; base egress-action; base default-action; description "Identity for reject action capability. The reject action denies a packet to go through the NSF entering or exiting the internal network and sends a response back to the source. The response depends on the packet and implementation. For example, a TCP packet is rejected with TCP RST response or a UDP packet may be rejected with an ICMPv4 response message with Type 3 Code 3 or ICMPv6 response message Type 1 Code 4 (i.e., Destination Unreachable: Destination port unreachable) "; } identity mirror { base ingress-action; base egress-action; base default-action; description "Identity for mirror action capability. The mirror action copies packet and send it to the monitoring entity while still allow the packet or flow to go through the NSF."; } identity rate-limit { base ingress-action; Hares, et al. Expires 24 November 2022 [Page 40] Internet-Draft I2NSF Capability YANG Data Model May 2022 base egress-action; base default-action; description "Identity for rate limiting action capability. The rate limit action limits the number of packets or flows that can go through the NSF by dropping packets or flows (randomly or systematically)."; } identity invoke-signaling { base egress-action; description "Identity for invoke signaling action capability. The invoke signaling action is used to convey information of the event triggering this action to a monitoring entity"; } identity tunnel-encapsulation { base egress-action; description "Identity for tunnel encapsulation action capability. The tunnel encapsulation action is used to encapsulate the packet to be tunneled across the network to enable a secure connection."; } identity forwarding { base egress-action; description "Identity for forwarding action capability. The forwarding action is used to relay the packet from one network segment to another node in the network."; } identity transformation { base egress-action; description "Identity for transformation action capability. The transformation action is used to transform a packet by modifying it (e.g., HTTP-to-CoAP packet translation). Note that a subset of transformation (e.g., HTTP-to-CoAP and Network Address Translator (NAT)) is handled in this YANG module, rather than all the existing transformations. Specific algorithmic transformations can be executed by a middlebox (e.g., NSF) for a given transformation name."; reference "RFC 8075: Guidelines for Mapping Implementations: HTTP to the Hares, et al. Expires 24 November 2022 [Page 41] Internet-Draft I2NSF Capability YANG Data Model May 2022 Constrained Application Protocol (CoAP) - Translation between HTTP and CoAP RFC 3022: Traditional IP Network Address Translator (Traditional NAT)"; } identity http-to-coap { base transformation; description "Identity for HTTP-to-CoAP transformation action capability. This indicates the support of HTTP-to-CoAP packet translation."; reference "RFC 8075: Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) - Translation between HTTP and CoAP."; } identity nat { base transformation; description "Identity for Network Address Translation (NAT) transformation action capability. This indicates the support of NAT for network address mapping."; reference "RFC 3022: Traditional IP Network Address Translator (Traditional NAT)"; } identity resolution-strategy { description "Base identity for resolution strategy capability"; } identity fmr { base resolution-strategy; description "Identity for First Matching Rule (FMR) resolution strategy capability"; } identity lmr { base resolution-strategy; description "Identity for Last Matching Rule (LMR) resolution strategy capability"; } Hares, et al. Expires 24 November 2022 [Page 42] Internet-Draft I2NSF Capability YANG Data Model May 2022 identity pmre { base resolution-strategy; description "Identity for Prioritized Matching Rule with Errors (PMRE) resolution strategy capability"; } identity pmrn { base resolution-strategy; description "Identity for Prioritized Matching Rule with No Errors (PMRN) resolution strategy capability"; } identity advanced-nsf { description "Base identity for advanced Network Security Function (NSF) capability."; } identity content-security-control { base advanced-nsf; description "Base identity for content security control. Content security control is an NSF that evaluates a packet's payload such as Intrusion Prevention System (IPS), URL-Filtering, Antivirus, and VoIP/CN Filter."; } identity attack-mitigation-control { base advanced-nsf; description "Base identity for attack mitigation control. Attack mitigation control is an NSF that mitigates an attack such as anti-DDoS or DDoS-mitigator."; } identity ips { base content-security-control; description "Base identity for IPS (Intrusion Prevention System) capability that prevents malicious activity within a network"; } identity url-filtering { base content-security-control; description "Base identity for url filtering capability that limits access Hares, et al. Expires 24 November 2022 [Page 43] Internet-Draft I2NSF Capability YANG Data Model May 2022 by comparing the web traffic's URL with the URLs for web filtering in a database"; } identity anti-virus { base content-security-control; description "Base identity for antivirus capability to protect the network by detecting and removing viruses."; } identity voip-vocn-filtering { base content-security-control; description "Base identity for an advanced NSF for VoIP (Voice over Internet Protocol) and VoCN (Voice over Cellular Network, such as Voice over LTE or 5G) Security Service capability to filter the VoIP/VoCN packets or flows."; reference "RFC 3261: SIP: Session Initiation Protocol"; } identity anti-ddos { base attack-mitigation-control; description "Base identity for advanced NSF Anti-DDoS Attack or DDoS Mitigator capability."; } identity packet-rate { base anti-ddos; description "Identity for advanced NSF Anti-DDoS detecting Packet Rate Capability where a packet rate is defined as the arrival rate of Packets toward a victim destination node. The NSF with this capability can detect the incoming packet rate and create an alert if the rate exceeds the threshold."; } identity flow-rate { base anti-ddos; description "Identity for advanced NSF Anti-DDoS detecting Flow Rate Capability where a flow rate is defined as the arrival rate of flows towards a victim destination node. The NSF with this capability can detect the incoming flow rate and create an alert if the rate exceeds the threshold."; Hares, et al. Expires 24 November 2022 [Page 44] Internet-Draft I2NSF Capability YANG Data Model May 2022 } identity byte-rate { base anti-ddos; description "Identity for advanced NSF Anti-DDoS detecting Byte Rate Capability where a byte rate is defined as the arrival rate of Bytes toward a victim destination node. The NSF with this capability can detect the incoming byte rate and create an alert if the rate exceeds the threshold."; } identity signature-set { base ips; description "Identity for the capability of IPS to set the signature. Signature is a set of rules to detect an intrusive activity."; reference "RFC 4766: Intrusion Detection Message Exchange Requirements - Section 2.2.13"; } identity exception-signature { base ips; description "Identity for the capability of IPS to exclude signatures from detecting the intrusion."; reference "RFC 4766: Intrusion Detection Message Exchange Requirements - Section 2.2.13"; } identity detect { base anti-virus; description "Identity for advanced NSF Antivirus capability to detect viruses using a security profile. The security profile is used to scan threats, such as virus, malware, and spyware. The NSF should be able to update the security profile."; } identity exception-files { base anti-virus; description "Identity for advanced NSF Antivirus capability to exclude a certain file type or name from detection."; } Hares, et al. Expires 24 November 2022 [Page 45] Internet-Draft I2NSF Capability YANG Data Model May 2022 identity pre-defined { base url-filtering; description "Identity for pre-defined URL Database condition capability where URL database is a public database for URL filtering."; } identity user-defined { base url-filtering; description "Identity for user-defined URL Database condition capability that allows a user's manual addition of URLs for URL filtering."; } identity call-id { base voip-vocn-filtering; description "Identity for advanced NSF VoIP/VoCN Call Identifier (ID) capability."; } identity user-agent { base voip-vocn-filtering; description "Identity for advanced NSF VoIP/VoCN User Agent capability."; } /* * Grouping */ grouping nsf-capabilities { description "Network Security Function (NSF) Capabilities"; reference "RFC 8329: Framework for Interface to Network Security Functions - I2NSF Flow Security Policy Structure."; leaf-list directional-capabilities { type identityref { base directional; } description "The capability of an NSF for handling directional traffic flow (i.e., unidirectional or bidirectional traffic flow)."; } Hares, et al. Expires 24 November 2022 [Page 46] Internet-Draft I2NSF Capability YANG Data Model May 2022 container event-capabilities { description "Capabilities of events. If a network security function has the event capabilities, the network security function supports rule execution according to system event and system alarm."; reference "RFC 8329: Framework for Interface to Network Security Functions - Section 7. draft-ietf-i2nsf-nsf-monitoring-data-model-19: I2NSF NSF Monitoring Interface YANG Data Model - System Alarm and System Events."; leaf-list system-event-capability { type identityref { base system-event; } description "System event capabilities"; } leaf-list system-alarm-capability { type identityref { base system-alarm; } description "System alarm capabilities"; } } container condition-capabilities { description "Conditions capabilities."; container generic-nsf-capabilities { description "Conditions capabilities. If a network security function has the condition capabilities, the network security function supports rule execution according to conditions of IPv4, IPv6, TCP, UDP, SCTP, DCCP, ICMP, or ICMPv6."; reference "RFC 768: User Datagram Protocol - UDP. RFC 791: Internet Protocol - IPv4. RFC 792: Internet Control Message Protocol - ICMP. RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification - ICMPv6. Hares, et al. Expires 24 November 2022 [Page 47] Internet-Draft I2NSF Capability YANG Data Model May 2022 draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission Protocol - SCTP. RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - IPv6. RFC 8329: Framework for Interface to Network Security Functions - I2NSF Flow Security Policy Structure. draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification"; leaf-list ethernet-capability { type identityref { base ethernet; } description "Media Access Control (MAC) capabilities"; reference "IEEE 802.3: IEEE Standard for Ethernet"; } leaf-list ipv4-capability { type identityref { base ipv4; } description "IPv4 packet capabilities"; reference "RFC 791: Internet Protocol"; } leaf-list ipv6-capability { type identityref { base ipv6; } description "IPv6 packet capabilities"; reference "RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - IPv6"; } leaf-list icmpv4-capability { type identityref { base icmpv4; } description "ICMPv4 packet capabilities"; reference "RFC 792: Internet Control Message Protocol - ICMP"; Hares, et al. Expires 24 November 2022 [Page 48] Internet-Draft I2NSF Capability YANG Data Model May 2022 } leaf-list icmpv6-capability { type identityref { base icmpv6; } description "ICMPv6 packet capabilities"; reference "RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification - ICMPv6"; } leaf-list tcp-capability { type identityref { base tcp; } description "TCP packet capabilities"; reference "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification"; } leaf-list udp-capability { type identityref { base udp; } description "UDP packet capabilities"; reference "RFC 768: User Datagram Protocol - UDP"; } leaf-list sctp-capability { type identityref { base sctp; } description "SCTP packet capabilities"; reference "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission Protocol - SCTP"; } leaf-list dccp-capability { type identityref { Hares, et al. Expires 24 November 2022 [Page 49] Internet-Draft I2NSF Capability YANG Data Model May 2022 base dccp; } description "DCCP packet capabilities"; reference "RFC 4340: Datagram Congestion Control Protocol - DCCP"; } } container advanced-nsf-capabilities { description "Advanced Network Security Function (NSF) capabilities, such as Anti-DDoS, IPS, and VoIP/VoCN. This container contains the leaf-lists of advanced NSF capabilities"; leaf-list anti-ddos-capability { type identityref { base anti-ddos; } description "Anti-DDoS Attack capabilities"; } leaf-list ips-capability { type identityref { base ips; } description "IPS capabilities"; } leaf-list anti-virus-capability { type identityref { base anti-virus; } description "Antivirus capabilities"; } leaf-list url-filtering-capability { type identityref { base url-filtering; } description "URL Filtering capabilities"; } Hares, et al. Expires 24 November 2022 [Page 50] Internet-Draft I2NSF Capability YANG Data Model May 2022 leaf-list voip-vocn-filtering-capability { type identityref { base voip-vocn-filtering; } description "VoIP/VoCN capabilities"; } } container context-capabilities { description "Security context capabilities"; leaf-list time-capabilities { type identityref { base time; } description "The capabilities for activating the policy within a specific time."; } leaf-list application-filter-capabilities{ type identityref { base application-protocol; } description "Context capabilities based on the application protocol"; } leaf-list device-type-capabilities { type identityref { base device-type; } description "Context capabilities based on the device attribute that can identify a device type (i.e., router, switch, pc, ios, or android)."; } leaf-list user-condition-capabilities { type identityref { base user-condition; } description "Context capabilities based on user condition, such as user-id and user-name. The users can be collected into a user group (i.e., a group of users) and identified with Hares, et al. Expires 24 November 2022 [Page 51] Internet-Draft I2NSF Capability YANG Data Model May 2022 group-id or group-name. An NSF is aware of the IP address of the user provided by a unified user management system via network. Based on name-address association, an NSF is able to enforce the security functions over the given user (or user group)"; } leaf-list geographic-capabilities { type identityref { base geographic-location; } description "Context condition capabilities based on the geographical location of the source or destination"; } } } container action-capabilities { description "Action capabilities. If a network security function has the action capabilities, the network security function supports the attendant actions for policy rules."; leaf-list ingress-action-capability { type identityref { base ingress-action; } description "Ingress-action capabilities"; } leaf-list egress-action-capability { type identityref { base egress-action; } description "Egress-action capabilities"; } leaf-list log-action-capability { type identityref { base log-action; } description "Log-action capabilities"; } Hares, et al. Expires 24 November 2022 [Page 52] Internet-Draft I2NSF Capability YANG Data Model May 2022 } leaf-list resolution-strategy-capabilities { type identityref { base resolution-strategy; } description "Resolution strategy capabilities. The resolution strategies can be used to specify how to resolve conflicts that occur between the actions of the similar or different policy rules that are matched for the same packet and by particular NSF; note that a badly written policy rule may cause a conflict of actions with another similar policy rule."; } leaf-list default-action-capabilities { type identityref { base default-action; } description "Default action capabilities. A default action is used to execute I2NSF policy rules when no rule matches a packet. The default action is defined as pass, drop, reject, rate-limit, or mirror."; } } /* * Data nodes */ list nsf { key "nsf-name"; description "The list of Network Security Functions (NSFs)"; leaf nsf-name { type string; mandatory true; description "The name of Network Security Function (NSF)"; } uses nsf-capabilities; } } Figure 3: YANG Data Module of I2NSF Capability Hares, et al. Expires 24 November 2022 [Page 53] Internet-Draft I2NSF Capability YANG Data Model May 2022 7. IANA Considerations This document requests IANA to register the following URI in the "IETF XML Registry" [RFC3688]: ID: yang:ietf-i2nsf-capability URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950][RFC8525]: Name: ietf-i2nsf-capability Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability Prefix: i2nsfcap Module: Reference: [ RFC-to-be ] 8. Privacy Considerations This YANG module specifies the capabilities of NSFs. These capabilities are consistent with the diverse set of network security functions in common use in enterprise security operations. The configuration of the capabilities may entail privacy-sensitive information as explicitly outlined in Section 9. The NSFs implementing these capabilities may inspect, alter or drop user traffic; and be capable of attributing user traffic to individual users. Due to the sensitivity of these capabilities, notice must be provided to and consent must be received from the users of the network. Additionally, the collected data and associated infrastructure must be secured to prevent the leakage or unauthorized disclosure of this private data. Hares, et al. Expires 24 November 2022 [Page 54] Internet-Draft I2NSF Capability YANG Data Model May 2022 9. Security Considerations The YANG module specified in this document defines a data schema designed to be accessed through network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest layer of NETCONF protocol layers MUST use Secure Shell (SSH) [RFC4254][RFC6242] as a secure transport layer. The lowest layer of RESTCONF protocol layers MUST use HTTP over Transport Layer Security (TLS) [RFC8446], that is, HTTPS as a secure transport layer. The Network Configuration Access Control Model (NACM) [RFC8341] provides a means of restricting access to specific NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and contents. Thus, NACM SHOULD be used to restrict the NSF registration from unauthorized users. There are a number of data nodes defined in this YANG module that are writable, creatable, and deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations to these data nodes could have a negative effect on network and security operations. These data nodes are collected into a single list node. This list node is defined by list nsf with the following sensitivity/ vulnerability: * list nsf: An attacker could alter the security capabilities associated with an NSF in the database maintained by the security controller. Such changes could result in security functionality going unused due to the controller not having a record of it, and could also result in falsely claiming security capabilities that the controller would then attempt to use but would not actually be provided. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes with their sensitivity/vulnerability: * list nsf: The leak of this node to an attacker could reveal the specific configuration of security controls to an attacker. An attacker can craft an attack path that avoids observation or mitigations by getting the information of available security capabilities in a victim network. Hares, et al. Expires 24 November 2022 [Page 55] Internet-Draft I2NSF Capability YANG Data Model May 2022 Some of the capability indicators (i.e., identities) defined in this document are highly sensitive and/or privileged operations that inherently require access to individuals' private data. These are subtrees and data nodes that are considered privacy-sensitive: * url-filtering-capability: URLs themselves often contain sensitive information [CAPABILITY-URLS], and access to URLs typically comes hand-in-hand with access to request and response content, which is also often sensitive. * voip-vocn-filtering-capability: The NSF that is able to filter VoIP/VoCN calls might identify certain individual identification. * user-condition-capabilities: The capability uses a set of IP addresses mapped to users. * geographic-capabilities: The IP address used in this capability can identify a user's geographical location. It is noted that some private information is made accessible in this manner. Thus, the nodes/entities given access to this data MUST be tightly secured, monitored, and audited to prevent leakage or other unauthorized disclosure of private data. Refer to [RFC6973] for the description of privacy aspects that protocol designers (including YANG data model designers) should consider along with regular security and privacy analysis. 10. References 10.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1983, . Hares, et al. Expires 24 November 2022 [Page 56] Internet-Draft I2NSF Capability YANG Data Model May 2022 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, . [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, DOI 10.17487/RFC2595, June 1999, . [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, . Hares, et al. Expires 24 November 2022 [Page 57] Internet-Draft I2NSF Capability YANG Data Model May 2022 [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, January 2006, . [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC4766] Wood, M. and M. Erlinger, "Intrusion Detection Message Exchange Requirements", RFC 4766, DOI 10.17487/RFC4766, March 2007, . [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, DOI 10.17487/RFC5103, January 2008, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, September 2009, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . Hares, et al. Expires 24 November 2022 [Page 58] Internet-Draft I2NSF Capability YANG Data Model May 2022 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, . [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", RFC 6691, DOI 10.17487/RFC6691, July 2012, . [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, DOI 10.17487/RFC6864, February 2013, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)", RFC 8075, DOI 10.17487/RFC8075, February 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Hares, et al. Expires 24 November 2022 [Page 59] Internet-Draft I2NSF Capability YANG Data Model May 2022 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, January 2018, . [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, "YANG Library", RFC 8525, DOI 10.17487/RFC8525, March 2019, . [RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W. Kumari, "A Format for Self-Published IP Geolocation Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020, . Hares, et al. Expires 24 November 2022 [Page 60] Internet-Draft I2NSF Capability YANG Data Model May 2022 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message Access Protocol (IMAP) - Version 4rev2", RFC 9051, DOI 10.17487/RFC9051, August 2021, . [I-D.ietf-httpbis-http2bis] Thomson, M. and C. Benfield, "HTTP/2", Work in Progress, Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January 2022, . [I-D.ietf-httpbis-messaging] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- httpbis-messaging-19, 12 September 2021, . [I-D.ietf-httpbis-semantics] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Semantics", Work in Progress, Internet-Draft, draft-ietf- httpbis-semantics-19, 12 September 2021, . [I-D.ietf-i2nsf-nsf-facing-interface-dm] Kim, J. T., Jeong, J. P., Park, J., Hares, S., and Q. Lin, "I2NSF Network Security Function-Facing Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf- i2nsf-nsf-facing-interface-dm-27, 14 May 2022, . [I-D.ietf-i2nsf-nsf-monitoring-data-model] Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. Birkholz, "I2NSF NSF Monitoring Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf- i2nsf-nsf-monitoring-data-model-18, 19 April 2022, . [I-D.ietf-i2nsf-registration-interface-dm] Hyun, S., Jeong, J. (., Roh, T., Wi, S., and J. Park, "I2NSF Registration Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-i2nsf-registration- interface-dm-16, 13 April 2022, . Hares, et al. Expires 24 November 2022 [Page 61] Internet-Draft I2NSF Capability YANG Data Model May 2022 [I-D.ietf-tcpm-rfc793bis] Eddy, W. M., "Transmission Control Protocol (TCP) Specification", Work in Progress, Internet-Draft, draft- ietf-tcpm-rfc793bis-28, 7 March 2022, . [I-D.ietf-tcpm-accurate-ecn] Briscoe, B., Kühlewind, M., and R. Scheffenegger, "More Accurate ECN Feedback in TCP", Work in Progress, Internet- Draft, draft-ietf-tcpm-accurate-ecn-18, 22 March 2022, . [I-D.ietf-tsvwg-rfc4960-bis] Stewart, R. R., Tüxen, M., and K. E. E. Nielsen, "Stream Control Transmission Protocol", Work in Progress, Internet-Draft, draft-ietf-tsvwg-rfc4960-bis-19, 5 February 2022, . [I-D.ietf-tsvwg-udp-options] Touch, J., "Transport Options for UDP", Work in Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-18, 26 March 2022, . 10.2. Informative References [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., and J. Jeong, "Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases", RFC 8192, DOI 10.17487/RFC8192, July 2017, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . Hares, et al. Expires 24 November 2022 [Page 62] Internet-Draft I2NSF Capability YANG Data Model May 2022 [IANA-Protocol-Numbers] "Assigned Internet Protocol Numbers", Available: https://www.iana.org/assignments/protocol- numbers/protocol-numbers.xhtml, September 2020. [IEEE802.3-2018] Committee, I. S., "IEEE 802.3-2018 - IEEE Standard for Ethernet", August 2018, . [Alshaer] Shaer, Al., Hamed, E., and H. Hamed, "Modeling and management of firewall policies", 2004. [Hirschman] Hirschman, L. and R. Gaizauskas, "Natural Language Question Answering: The View from Here", Natural Language Engineering 7:4, pgs 275-300, Cambridge University Press , November 2001. [Hohpe] Hohpe, G. and B. Woolf, "Enterprise Integration Patterns", ISBN 0-32-120068-3 , 2003. [Martin] Martin, R.C., "Agile Software Development, Principles, Patterns, and Practices", Prentice-Hall , ISBN: 0-13-597444-5 , 2002. [OODMP] "https://www.oodesign.com/mediator-pattern.html". [OODOP] "https://www.oodesign.com/observer-pattern.html". [OODSRP] "https://www.oodesign.com/single-responsibility- principle.html". [CAPABILITY-URLS] Tennison, J., "Good Practices for Capability URLs", October 2014, . Appendix A. Configuration Examples This section shows configuration examples of "ietf-i2nsf-capability" module for capabilities registration of general firewall. A.1. Example 1: Registration for the Capabilities of a General Firewall This section shows a configuration example for the capabilities registration of a general firewall in either an IPv4 network or an IPv6 network. Hares, et al. Expires 24 November 2022 [Page 63] Internet-Draft I2NSF Capability YANG Data Model May 2022 general_firewall next-header flow-direction source-address destination-address source-port-number destination-port-number source-port-number destination-port-number pass drop mirror pass drop mirror Figure 4: Configuration XML for the Capabilities Registration of a General Firewall in an IPv4 Network Figure 4 shows the configuration XML for the capabilities registration of a general firewall as an NSF in an IPv4 network. Its capabilities are as follows. 1. The name of the NSF is general_firewall. 2. The NSF can inspect the IPv4 protocol header field, flow direction, source address(es), and destination address(es) 3. The NSF can inspect the port number(s) and flow direction for the transport layer protocol, i.e., TCP and UDP. 4. The NSF can control whether the packets are allowed to pass, drop, or mirror. Hares, et al. Expires 24 November 2022 [Page 64] Internet-Draft I2NSF Capability YANG Data Model May 2022 general_firewall next-header flow-direction source-address destination-address source-port-number destination-port-number source-port-number destination-port-number pass drop mirror pass drop mirror Figure 5: Configuration XML for the Capabilities Registration of a General Firewall in an IPv6 Network In addition, Figure 5 shows the configuration XML for the capabilities registration of a general firewall as an NSF in an IPv6 network. Its capabilities are as follows. 1. The name of the NSF is general_firewall. 2. The NSF can inspect IPv6 next header, flow direction, source address(es), and destination address(es) 3. The NSF can inspect the port number(s) and flow direction for the transport layer protocol, i.e., TCP and UDP. 4. The NSF can control whether the packets are allowed to pass, drop, or mirror. A.2. Example 2: Registration for the Capabilities of a Time-based Firewall This section shows a configuration example for the capabilities registration of a time-based firewall in either an IPv4 network or an IPv6 network. Hares, et al. Expires 24 November 2022 [Page 65] Internet-Draft I2NSF Capability YANG Data Model May 2022 time_based_firewall next-header flow-direction source-address destination-address absolute-time periodic-time pass drop mirror pass drop mirror Figure 6: Configuration XML for the Capabilities Registration of a Time-based Firewall in an IPv4 Network Figure 6 shows the configuration XML for the capabilities registration of a time-based firewall as an NSF in an IPv4 network. Its capabilities are as follows. 1. The name of the NSF is time_based_firewall. 2. The NSF can execute the security policy rule according to absolute time and periodic time. 3. The NSF can inspect the IPv4 protocol header field, flow direction, source address(es), and destination address(es). 4. The NSF can control whether the packets are allowed to pass, drop, or mirror. Hares, et al. Expires 24 November 2022 [Page 66] Internet-Draft I2NSF Capability YANG Data Model May 2022 time_based_firewall next-header flow-direction source-address destination-address absolute-time periodic-time pass drop mirror pass drop mirror Figure 7: Configuration XML for the Capabilities Registration of a Time-based Firewall in an IPv6 Network In addition, Figure 7 shows the configuration XML for the capabilities registration of a time-based firewall as an NSF in an IPv6 network. Its capabilities are as follows. 1. The name of the NSF is time_based_firewall. 2. The NSF can execute the security policy rule according to absolute time and periodic time. 3. The NSF can inspect the IPv6 protocol header field, flow direction, source address(es), and destination address(es). 4. The NSF can control whether the packets are allowed to pass, drop, or mirror. A.3. Example 3: Registration for the Capabilities of a Web Filter This section shows a configuration example for the capabilities registration of a web filter. Hares, et al. Expires 24 November 2022 [Page 67] Internet-Draft I2NSF Capability YANG Data Model May 2022 web_filter user-defined pass drop mirror pass drop mirror Figure 8: Configuration XML for the Capabilities Registration of a Web Filter Figure 8 shows the configuration XML for the capabilities registration of a web filter as an NSF. Its capabilities are as follows. 1. The name of the NSF is web_filter. 2. The NSF can inspect a URL matched from a user-defined URL. User can specify their own URL. 3. The NSF can control whether the packets are allowed to pass, drop, or mirror. 4. Overall, the NSF can compare the URL of a packet to a user- defined database. The matched packet can be passed, dropped, or mirrored. A.4. Example 4: Registration for the Capabilities of a VoIP/VoCN Filter This section shows a configuration example for the capabilities registration of a VoIP/VoCN filter. Hares, et al. Expires 24 November 2022 [Page 68] Internet-Draft I2NSF Capability YANG Data Model May 2022 voip_vocn_filter call-id pass drop mirror pass drop mirror Figure 9: Configuration XML for the Capabilities Registration of a VoIP/VoCN Filter Figure 9 shows the configuration XML for the capabilities registration of a VoIP/VoCN filter as an NSF. Its capabilities are as follows. 1. The name of the NSF is voip_vocn_filter. 2. The NSF can inspect a voice call id for VoIP/VoCN packets. 3. The NSF can control whether the packets are allowed to pass, drop, or mirror. A.5. Example 5: Registration for the Capabilities of an HTTP and HTTPS Flood Mitigator This section shows a configuration example for the capabilities registration of a HTTP and HTTPS flood mitigator. Hares, et al. Expires 24 November 2022 [Page 69] Internet-Draft I2NSF Capability YANG Data Model May 2022 DDoS_mitigator packet-rate byte-rate flow-rate pass drop mirror pass drop mirror Figure 10: Configuration XML for the Capabilities Registration of a HTTP and HTTPS Flood Mitigator Figure 10 shows the configuration XML for the capabilities registration of a HTTP and HTTPS flood mitigator as an NSF. Its capabilities are as follows. 1. The name of the NSF is DDoS_mitigator. 2. The NSF can detect the amount of packet, flow, and byte rate in the network for potential DDoS Attack. 3. The NSF can control whether the packets are allowed to pass, drop, or mirror. Appendix B. Acknowledgments This document is a product by the I2NSF Working Group (WG) including WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This document took advantage of the review and comments from the following experts: Roman Danyliw, Acee Lindem, Paul Wouters (SecDir), Michael Scharf (TSVART), Dan Romascanu (GenART), and Tom Petch. The authors sincerely appreciate their sincere efforts and kind help. Hares, et al. Expires 24 November 2022 [Page 70] Internet-Draft I2NSF Capability YANG Data Model May 2022 This work was supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based Security Intelligence Technology Development for the Customized Security Service Provisioning). This work was supported in part by the IITP grant funded by the MSIT (2020-0-00395, Standard Development of Blockchain based Network Management Automation Technology). Appendix C. Contributors The following are co-authors of this document: Patrick Lingga - Department of Electrical and Computer Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 16419, Republic of Korea, EMail: patricklink@skku.edu Liang Xia - Huawei, 101 Software Avenue, Nanjing, Jiangsu 210012, China, EMail: Frank.Xialiang@huawei.com Cataldo Basile - Politecnico di Torino, Corso Duca degli Abruzzi, 34, Torino, 10129, Italy, EMail: cataldo.basile@polito.it John Strassner - Huawei, 2330 Central Expressway, Santa Clara, CA 95050, USA, EMail: John.sc.Strassner@huawei.com Diego R. Lopez - Telefonica I+D, Zurbaran, 12, Madrid, 28010, Spain, Email: diego.r.lopez@telefonica.com Hyoungshick Kim - Department of Computer Science and Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 16419, Republic of Korea, EMail: hyoung@skku.edu Daeyoung Hyun - Department of Computer Science and Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 16419, Republic of Korea, EMail: dyhyun@skku.edu Dongjin Hong - Department of Electronic, Electrical and Computer Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 16419, Republic of Korea, EMail: dong.jin@skku.edu Jung-Soo Park - Electronics and Telecommunications Research Institute, 218 Gajeong-Ro, Yuseong-Gu, Daejeon, 34129, Republic of Korea, EMail: pjs@etri.re.kr Tae-Jin Ahn - Korea Telecom, 70 Yuseong-Ro, Yuseong-Gu, Daejeon, 305-811, Republic of Korea, EMail: taejin.ahn@kt.com Hares, et al. Expires 24 November 2022 [Page 71] Internet-Draft I2NSF Capability YANG Data Model May 2022 Se-Hui Lee - Korea Telecom, 70 Yuseong-Ro, Yuseong-Gu, Daejeon, 305-811, Republic of Korea, EMail: sehuilee@kt.com Appendix D. Changes from draft-ietf-i2nsf-capability-data-model-31 The following changes are made from draft-ietf-i2nsf-capability-data- model-31: * The YANG module's prefix is updated from 'nsfcap' to 'i2nsfcap'. Authors' Addresses Susan Hares (editor) Huawei 7453 Hickory Hill Saline, MI 48176 United States of America Phone: +1-734-604-0332 Email: shares@ndzh.com Jaehoon Paul Jeong (editor) Department of Computer Science and Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4957 Email: pauljeong@skku.edu URI: http://iotlab.skku.edu/people-jaehoon-jeong.php Jinyong Tim Kim Department of Electronic, Electrical and Computer Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419 Republic of Korea Phone: +82 10 8273 0930 Email: timkim@skku.edu Hares, et al. Expires 24 November 2022 [Page 72] Internet-Draft I2NSF Capability YANG Data Model May 2022 Robert Moskowitz HTT Consulting Oak Park, MI United States of America Phone: +1-248-968-9809 Email: rgm@htt-consult.com Qiushi Lin Huawei Huawei Industrial Base Shenzhen Guangdong 518129, China Email: linqiushi@huawei.com Hares, et al. Expires 24 November 2022 [Page 73] ./draft-ietf-lsr-isis-srv6-extensions-19.txt0000644000764400076440000016274314334440104020530 0ustar iustiniustin Networking Working Group P. Psenak, Ed. Internet-Draft C. Filsfils Updates: 7370 (if approved) A. Bashandy Intended status: Standards Track Cisco Systems Expires: 18 May 2023 B. Decraene Orange Z. Hu Huawei Technologies 14 November 2022 IS-IS Extensions to Support Segment Routing over IPv6 Dataplane draft-ietf-lsr-isis-srv6-extensions-19 Abstract The Segment Routing (SR) architecture allows flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support Segment Routing over the IPv6 data plane. This document updates RFC 7370 by modifying an existing registry. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 18 May 2023. Psenak, et al. Expires 18 May 2023 [Page 1] Internet-Draft ISIS Srv6 Extensions November 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SRv6 Capabilities sub-TLV . . . . . . . . . . . . . . . . . . 4 3. Advertising Supported Algorithms . . . . . . . . . . . . . . 4 4. Advertising Maximum SRv6 SID Depths . . . . . . . . . . . . . 5 4.1. Maximum Segments Left MSD Type . . . . . . . . . . . . . 5 4.2. Maximum End Pop MSD Type . . . . . . . . . . . . . . . . 5 4.3. Maximum H.Encaps MSD Type . . . . . . . . . . . . . . . . 5 4.4. Maximum End D MSD Type . . . . . . . . . . . . . . . . . 6 5. SRv6 SIDs and Reachability . . . . . . . . . . . . . . . . . 6 6. Advertising Anycast Property . . . . . . . . . . . . . . . . 7 7. Advertising Locators and End SIDs . . . . . . . . . . . . . . 8 7.1. SRv6 Locator TLV Format . . . . . . . . . . . . . . . . . 9 7.2. SRv6 End SID sub-TLV . . . . . . . . . . . . . . . . . . 10 8. Advertising SRv6 Adjacency SIDs . . . . . . . . . . . . . . . 12 8.1. SRv6 End.X SID sub-TLV . . . . . . . . . . . . . . . . . 12 8.2. SRv6 LAN End.X SID sub-TLV . . . . . . . . . . . . . . . 14 9. SRv6 SID Structure Sub-Sub-TLV . . . . . . . . . . . . . . . 16 10. Advertising Endpoint Behaviors . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11.1. SRv6 Locator TLV . . . . . . . . . . . . . . . . . . . . 18 11.1.1. SRv6 End SID sub-TLV . . . . . . . . . . . . . . . . 18 11.1.2. Revised sub-TLV table . . . . . . . . . . . . . . . 19 11.2. SRv6 Capabilities sub-TLV . . . . . . . . . . . . . . . 19 11.3. Sub-Sub-TLVs of the SRv6 Capability sub-TLV . . . . . . 19 11.4. SRv6 End.X SID and SRv6 LAN End.X SID sub-TLVs . . . . . 20 11.5. MSD Types . . . . . . . . . . . . . . . . . . . . . . . 20 11.6. Sub-Sub-TLVs for SID Sub-TLVs . . . . . . . . . . . . . 21 11.7. Prefix Attribute Flags Sub-TLV . . . . . . . . . . . . . 21 11.8. IS-IS SRv6 Capabilities sub-TLV Flags Registry . . . . . 22 11.9. IS-IS SRv6 Locator TLV Flags Registry . . . . . . . . . 22 11.10. IS-IS SRv6 End SID sub-TLV Flags Registry . . . . . . . 23 11.11. IS-IS SRv6 Adjacency SID sub-TLVs Flags Registry . . . . 23 Psenak, et al. Expires 18 May 2023 [Page 2] Internet-Draft ISIS Srv6 Extensions November 2022 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 15.1. Normative References . . . . . . . . . . . . . . . . . . 26 15.2. Informative References . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction With Segment Routing (SR) [RFC8402], a node steers a packet through an ordered list of instructions, called segments. Segments are identified through Segment Identifiers (SIDs). Segment Routing can be directly instantiated on the IPv6 data plane through the use of the Segment Routing Header defined in [RFC8754]. SRv6 refers to this SR instantiation on the IPv6 dataplane. The network programming paradigm [RFC8986] is central to SRv6. It describes how any behavior can be bound to a SID and how any network program can be expressed as a combination of SIDs. This document specifies IS-IS extensions that allow the IS-IS protocol to encode some of these SIDs and their behaviors. Familiarity with the network programming paradigm [RFC8986] is necessary to understand the extensions specified in this document. The new SRv6 Locator top level TLV announces SRv6 locators - a form of summary address for the set of topology/algorithm-specific SIDs instantiated at the node. The SRv6 Capabilities sub-TLV announces the ability to support SRv6. Several new sub-TLVs are defined to advertise various SRv6 Maximum SID Depths. The SRv6 End SID sub-TLV, the SRv6 End.X SID sub-TLV, and the SRv6 LAN End.X SID sub-TLV are used to advertise which SIDs are instantiated at a node and what Endpoint behavior is bound to each instantiated SID. This document updates [RFC7370] by modifying an existing registry (Section 11.1.2). Psenak, et al. Expires 18 May 2023 [Page 3] Internet-Draft ISIS Srv6 Extensions November 2022 2. SRv6 Capabilities sub-TLV A node indicates that it supports the SR Segment Endpoint Node functionality as specified in [RFC8754] by advertising a new SRv6 Capabilities sub-TLV of the router capabilities TLV [RFC7981]. The SRv6 Capabilities sub-TLV may contain optional sub-sub-TLVs. No sub-sub-TLVs are currently defined. The SRv6 Capabilities sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional sub-sub-TLVs... Type: 25. Single octet as defined in section 9 of [ISO10589]. Length: Single octet as defined in section 9 of [ISO10589]. The length value is 2 + length of sub-sub-TLVs. Flags: 2 octets The following flags are defined: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: O-flag: If set, the router supports use of the O-bit in the Segment Routing Header (SRH) as defined in [I-D.ietf-6man-spring-srv6-oam]. The remaining bits, including bit 0, are reserved for future use. They MUST be set to zero on transmission and MUST be ignored on receipt. 3. Advertising Supported Algorithms An SRv6 capable router indicates supported algorithm(s) by advertising the Segment Routing Algorithm sub-TLV as defined in [RFC8667]. Psenak, et al. Expires 18 May 2023 [Page 4] Internet-Draft ISIS Srv6 Extensions November 2022 4. Advertising Maximum SRv6 SID Depths [RFC8491] defines the means to advertise node/link specific values for Maximum SID Depths (MSD) of various types. Node MSDs are advertised in a sub-TLV of the Router Capabilities TLV [RFC7981]. Link MSDs are advertised in a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223. This document defines the relevant SRv6 MSDs and requests MSD type assignments in the MSD Types registry created by [RFC8491]. 4.1. Maximum Segments Left MSD Type The Maximum Segments Left MSD Type signals the maximum value of the "Segments Left" field [RFC8754] in the SRH of a received packet before applying the Endpoint behavior associated with a SID. SRH Max Segments Left Type: 41 If no value is advertised, the supported value is 0. 4.2. Maximum End Pop MSD Type The Maximum End Pop MSD Type signals the maximum number of SIDs in the SRH to which the router can apply "Penultimate Segment Pop of the SRH" or "Ultimate Segment Pop of the SRH" behavior, as defined in [RFC8986] flavors. SRH Max End Pop Type: 42 If the advertised value is zero or no value is advertised, then the router cannot apply PSP or USP flavors. 4.3. Maximum H.Encaps MSD Type The Maximum H.Encaps MSD Type signals the maximum number of SIDs that can be added to the Segment List of an SRH as part of the "H.Encaps" behavior as defined in [RFC8986]. SRH Max H.encaps Type: 44 If the advertised value is zero or no value is advertised, then the headend can apply an SR Policy that only contains one segment, without inserting any SRH header. A non-zero SRH Max H.encaps MSD indicates that the headend can insert an SRH up to the advertised number of SIDs. Psenak, et al. Expires 18 May 2023 [Page 5] Internet-Draft ISIS Srv6 Extensions November 2022 4.4. Maximum End D MSD Type The Maximum End D MSD Type specifies the maximum number of SIDs present in an SRH when performing decapsulation. As specified in [RFC8986] the permitted SID types include, but are not limited to End.DX6, End.DT4, End.DT46, End with USD, End.X with USD. SRH Max End D Type: 45 If the advertised value is zero or no value is advertised then the router cannot apply any behavior that results in decapsulation and forwarding of the inner packet if the outer IPv6 header contains an SRH. 5. SRv6 SIDs and Reachability As discussed in [RFC8986], an SRv6 Segment Identifier (SID) is 128 bits and consists of Locator, Function and Argument parts. A node is provisioned with topology/algorithm specific locators for each of the topology/algorithm pairs supported by that node. Each locator is a covering prefix for all SIDs provisioned on that node which have the matching topology/algorithm. Locators MUST be advertised in the SRv6 Locator TLV (see Section 7.1). Forwarding entries for the locators advertised in the SRv6 Locator TLV MUST be installed in the forwarding plane of receiving SRv6 capable routers when the associated topology/algorithm is supported by the receiving node. The processing of the prefix advertised in the SRv6 Locator TLV, the calculation of its reachability and the installation in the forwarding plane follows the process defined for the Prefix Reachability TLV 236 [RFC5308], or TLV 237 [RFC5120]. Locators associated with algorithm 0 and 1 (for all supported topologies) SHOULD be advertised in a Prefix Reachability TLV (236 or 237) so that legacy routers (i.e., routers which do not support SRv6) will install a forwarding entry for algorithm 0 and 1 SRv6 traffic. In cases where the same prefix, with the same prefix-length, Multi Topology ID (MT ID), and algorithm is received in both a Prefix Reachability TLV and an SRv6 Locator TLV, the Prefix Reachability advertisement MUST be preferred when installing entries in the forwarding plane. This is to prevent inconsistent forwarding entries between SRv6 capable and SRv6 incapable routers. Such preference of Prefix Reachability advertisement does not have any impact on the rest of the data advertised in the SRv6 Locator TLV. Psenak, et al. Expires 18 May 2023 [Page 6] Internet-Draft ISIS Srv6 Extensions November 2022 Locators associated with Flexible Algorithms (see Section 4 of [I-D.ietf-lsr-flex-algo]) SHOULD NOT be advertised in Prefix Reachability TLVs (236 or 237). Advertising the Flexible Algorithm locator in regular Prefix Reachability TLV (236 or 237) would make the forwarding for it to follow algo 0 path. SRv6 SIDs are advertised as sub-TLVs in the SRv6 Locator TLV except for SRv6 SIDs which are associated with a specific Neighbor/Link and are therefore advertised as sub-TLVs in TLVs 22, 23, 25, 141, 222, and 223. SRv6 SIDs received from other nodes are not directly routable and MUST NOT be installed in the forwarding plane. Reachability to SRv6 SIDs depends upon the existence of a covering locator. Adherence to the rules defined in this section will assure that SRv6 SIDs associated with a supported topology/algorithm pair will be forwarded correctly, while SRv6 SIDs associated with an unsupported topology/algorithm pair will be dropped. NOTE: The drop behavior depends on the absence of a default/summary route covering a given locator. In order for forwarding to work correctly, the locator associated with SRv6 SID advertisements must be the longest match prefix installed in the forwarding plane for those SIDs. In order to ensure correct forwarding, network operators should take steps to make sure that this requirement is not compromised. For example, the following situations should be avoided: * Another locator associated with a different topology/algorithm is the longest match * Another prefix advertisement (i.e., from TLV 236 or 237) is the longest match 6. Advertising Anycast Property Both prefixes and SRv6 Locators may be configured as anycast and as such the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast identifier. A new flag in Prefix Attribute Flags Sub-TLV [RFC7794] is defined to advertise the anycast property: Psenak, et al. Expires 18 May 2023 [Page 7] Internet-Draft ISIS Srv6 Extensions November 2022 Bit #: 4 Name: Anycast Flag (A-flag) When the prefix/SRv6 locator is configured as anycast, the A-flag SHOULD be set. Otherwise, this flag MUST be clear. The A-flag MUST be preserved when the advertisement is leaked between levels. The A-flag and the N-flag MUST NOT both be set. If both N-flag and A-flag are set in the prefix/SRv6 Locator advertisement, the receiving routers MUST ignore the N-flag. The same prefix/SRv6 Locator can be advertised by multiple routers. If at least one of them sets the A-Flag in its advertisement, the prefix/SRv6 Locator SHOULD be considered as anycast. A prefix/SRv6 Locator that is advertised by a single node and without an A-Flag is considered node specific. All the nodes advertising the same anycast locator MUST instantiate the exact same set of SIDs under that anycast locator. Failure to do so may result in traffic being black-holed or mis-routed. The Prefix Attribute Flags Sub-TLV can be carried in the SRv6 Locator TLV as well as the Prefix Reachability TLVs. When a router originates both the Prefix Reachability TLV and the SRv6 Locator TLV for a given prefix, and the router is originating the Prefix Attribute Flags Sub-TLV in one of the TLVs, the router SHOULD advertise the same flags in the Prefix Attribute Flags Sub-TLV in both TLVs. However, unlike TLVs 236 [RFC5308] and 237 [RFC5120] the X-flag in the Prefix Attributes Flags sub-TLV is valid when sent in the SRv6 Locator TLV. The state of the X-flag in the Prefix Attributes Flags sub-TLV when included in the Locator TLV MUST match the setting of the embedded "X-bit" in any advertisement for the same prefix in TLVs 236 [RFC5308] and 237 [RFC5120]. In case of any inconsistency between the Prefix Attribute Flags advertised in the Locator TLV and in the Prefix Reachability TLV, the ones advertised in Prefix Reachability TLV MUST be preferred. 7. Advertising Locators and End SIDs The SRv6 Locator TLV is introduced to advertise SRv6 Locators and End SIDs associated with each locator. This new TLV shares the sub-TLV space defined for TLVs 135, 235, 236 and 237. Psenak, et al. Expires 18 May 2023 [Page 8] Internet-Draft ISIS Srv6 Extensions November 2022 7.1. SRv6 Locator TLV Format The SRv6 Locator TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |R|R|R|R| MT ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Entries . . . | Type: 27. Single octet as defined in section 9 of [ISO10589]. Length: Single octet as defined in section 9 of [ISO10589]. The length value is variable. R bits: reserved for future use. They MUST be set to zero on transmission and MUST be ignored on receipt. MT ID: Multitopology Identifier as defined in [RFC5120]. Note that the value 0 is legal. Followed by one or more locator entries of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Algorithm | Loc Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Locator (continued, variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV-len | Sub-TLVs (variable) . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Metric: 4 octets. As described in Section 4 of [RFC5305]. Flags: 1 octet. The following flags are defined: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |D| Reserved | +-+-+-+-+-+-+-+-+ Psenak, et al. Expires 18 May 2023 [Page 9] Internet-Draft ISIS Srv6 Extensions November 2022 D-flag: Same as described in section 4.1. of [RFC5305]. The remaining bits are reserved for future use. They MUST be set to zero on transmission and MUST be ignored on receipt. Algorithm: 1 octet. As defined in IGP Algorithm Types registry [RFC8665]. Loc-Size: 1 octet. Number of bits in the SRv6 Locator field. MUST be from the range (1 - 128). The TLV MUST be ignored if the Loc-Size is outside this range. Locator: 1-16 octets. This field encodes the advertised SRv6 Locator. The Locator is encoded in the minimal number of octets for the given number of bits. Trailing bits MUST be set to zero and ignored when received. Sub-TLV-length: 1 octet. Number of octets used by sub-TLVs. Optional sub-TLVs: Supported sub-TLVs are specified in Section 11.1.2. Any Sub-TLV that is not allowed in the SRv6 Locator TLV MUST be ignored. Prefix Attribute Flags Sub-TLV [RFC7794] SHOULD be included in the Locator TLV. Prefix Attribute Flags Sub-TLV MUST be included in the the Locator TLV when it is leaked upwards in the hierarchy or originated as a result of the redistribution from another protocol or another ISIS instance. If the Prefix Attribute Flags Sub-TLV is not included in these cases, receivers will be unable to determine the correct source of the advertisement. The receivers will be unable to detect the violation. 7.2. SRv6 End SID sub-TLV The SRv6 End SID sub-TLV is introduced to advertise SRv6 Segment Identifiers (SID) with Endpoint behaviors which do not require a particular neighbor in order to be correctly applied. SRv6 SIDs associated with a neighbor are advertised using the sub-TLVs defined in Section 8. Supported behavior values, together with parent TLVs in which they are advertised, are specified in Section 10 of this document. Please note that not all behaviors defined in [RFC8986] are defined in this document, e.g. END.T is not. Psenak, et al. Expires 18 May 2023 [Page 10] Internet-Draft ISIS Srv6 Extensions November 2022 This new sub-TLV is advertised in the SRv6 Locator TLV defined in the previous section. SRv6 End SIDs inherit the topology/algorithm from the parent locator. The SRv6 End SID sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (128 bits) . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont . . .) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont . . .) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont . . .) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-sub-TLV-len| Sub-sub-TLVs (variable) . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 5. Single octet as defined in section 9 of [ISO10589]. Length: Single octet as defined in section 9 of [ISO10589]. The length value is variable. Flags: 1 octet. No flags are currently defined. All bits are reserved for future use. They MUST be set to zero on transmission and MUST be ignored on receipt. Endpoint Behavior: 2 octets, as defined in [RFC8986]. Supported behavior values for this sub-TLV are defined in Section 10 of this document. Unsupported or unrecognized behavior values are ignored by the receiver. SID: 16 octets. This field encodes the advertised SRv6 SID. Sub-sub-TLV-length: 1 octet. Number of octets used by sub-sub- TLVs. Optional Sub-sub-TLVs: Supported Sub-sub-TLVs are specified in Section 11.6. Any Sub-sub-TLV that is not allowed in SRv6 End SID sub-TLV MUST be ignored. Psenak, et al. Expires 18 May 2023 [Page 11] Internet-Draft ISIS Srv6 Extensions November 2022 The SRv6 End SID MUST be allocated from its associated locator. SRv6 End SIDs that are not allocated from the associated locator MUST be ignored. Multiple SRv6 End SIDs MAY be associated with the same locator. In cases where the number of SRv6 End SID sub-TLVs exceeds the capacity of a single TLV, multiple Locator TLVs for the same locator MAY be advertised. For a given MTID/Locator the algorithm MUST be the same in all TLVs. If this restriction is not met all TLVs for that MTID/ Locator MUST be ignored. 8. Advertising SRv6 Adjacency SIDs Certain SRv6 Endpoint behaviors [RFC8986] are associated with a particular adjacency. This document defines two new sub-TLVs of TLV 22, 23, 25, 141, 222, and 223 - namely "SRv6 End.X SID sub-TLVs" and "SRv6 LAN End.X SID sub-TLVs". IS-IS Neighbor advertisements are topology specific - but not algorithm specific. SIDs advertised in SRv6 End.X SID and SRv6 LAN End.X SID sub-TLVs therefore inherit the topology from the associated neighbor advertisement, but the algorithm is specified in the individual SID. All SIDs advertised in SRv6 End.X SID and SRv6 LAN End.X SID sub-TLVs MUST be a subnet of a Locator with matching topology and algorithm which is advertised by the same node in an SRv6 Locator TLV. SIDs that do not meet this requirement MUST be ignored. This ensures that the node advertising these SIDs is also advertising its corresponding Locator with the algorithm that will be used for computing paths destined to the SID. 8.1. SRv6 End.X SID sub-TLV This sub-TLV is used to advertise an SRv6 SID associated with a point to point adjacency. Multiple SRv6 End.X SID sub-TLVs MAY be associated with the same adjacency. The SRv6 End.X SID sub-TLV has the following format: Psenak, et al. Expires 18 May 2023 [Page 12] Internet-Draft ISIS Srv6 Extensions November 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Weight | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (128 bits) . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont . . .) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont . . .) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont . . .) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-sub-tlv-len| Sub-sub-TLVs (variable) . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 43. Single octet as defined in section 9 of [ISO10589]. Length: Single octet as defined in section 9 of [ISO10589]. The length value is variable. Flags: 1 octet. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |B|S|P|Reserved | +-+-+-+-+-+-+-+-+ where: B-Flag: Backup flag. If set, the SID is eligible for protection, e.g., using IP Fast Re-route (IPFRR) [RFC5286], as described in [RFC8355]. S-Flag. Set flag. When set, the S-Flag indicates that the SID refers to a set of adjacencies (and therefore MAY be assigned to other adjacencies as well). P-Flag. Persistent flag. When set, the P-Flag indicates that the SID is persistently allocated, i.e., the SID value remains consistent across router restart and/or interface flap. Reserved bits: MUST be zero when originated and MUST be ignored Psenak, et al. Expires 18 May 2023 [Page 13] Internet-Draft ISIS Srv6 Extensions November 2022 when received. Algorithm: 1 octet. As defined in IGP Algorithm Types registry [RFC8665]. Weight: 1 octet. The value represents the weight of the SID for the purpose of load balancing. The use of the weight is defined in [RFC8402]. Endpoint Behavior: 2 octets. As defined in [RFC8986]. Supported behavior values for this sub-TLV are defined in Section 10 of this document. Unsupported or unrecognized behavior values are ignored by the receiver. SID: 16 octets. This field encodes the advertised SRv6 SID. Sub-sub-TLV-length: 1 octet. Number of octets used by sub-sub- TLVs. Optional Sub-sub-TLVs: Supported Sub-sub-TLVs are specified in Section 11.6. Any Sub-sub-TLV that is not allowed in SRv6 End.X SID sub-TLV MUST be ignored. Note that multiple TLVs for the same neighbor may be required in order to advertise all the SRv6 SIDs associated with that neighbor. 8.2. SRv6 LAN End.X SID sub-TLV This sub-TLV is used to advertise an SRv6 SID associated with a LAN adjacency. Since the parent TLV is advertising an adjacency to the Designated Intermediate System (DIS) for the LAN, it is necessary to include the System ID of the physical neighbor on the LAN with which the SRv6 SID is associated. Given that many neighbors may exist on a given LAN, multiple SRv6 LAN END.X SID sub-TLVs may be associated with the same LAN. Note that multiple TLVs for the same DIS neighbor may be required in order to advertise all the SRv6 SIDs associated with that neighbor. The SRv6 LAN End.X SID sub-TLV has the following format: Psenak, et al. Expires 18 May 2023 [Page 14] Internet-Draft ISIS Srv6 Extensions November 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Neighbor System-ID (ID length octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Algorithm | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (128 bits) . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont . . .) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont . . .) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (cont . . .) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-sub-TLV-len| sub-sub-TLVs (variable) . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 44. Single octet as defined in section 9 of [ISO10589]. Length: Single octet as defined in section 9 of [ISO10589]. The length value is variable. Neighbor System-ID: IS-IS System-ID of length "ID Length" as defined in [ISO10589]. Flags: 1 octet. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |B|S|P|Reserved | +-+-+-+-+-+-+-+-+ where B,S, and P flags are as described in Section 8.1. Reserved bits MUST be zero when originated and MUST be ignored when received. Algorithm: 1 octet. As defined in IGP Algorithm Types registry [RFC8665]. Psenak, et al. Expires 18 May 2023 [Page 15] Internet-Draft ISIS Srv6 Extensions November 2022 Weight: 1 octet. The value represents the weight of the SID for the purpose of load balancing. The use of the weight is defined in [RFC8402]. Endpoint Behavior: 2 octets. As defined in [RFC8986]. Supported behavior values for this sub-TLV are defined in Section 10 of this document. Unsupported or unrecognized behavior values are ignored by the receiver. SID: 16 octets. This field encodes the advertised SRv6 SID. Sub-sub-TLV-length: 1 octet. Number of octets used by sub-sub- TLVs. Optional Sub-sub-TLVs: Supported Sub-sub-TLVs are specified in Section 11.6. Any Sub-sub-TLV that is not allowed in SRv6 LAN End.X SID sub-TLV MUST be ignored. Note that multiple TLVs for the same neighbor, on the same LAN, may be required in order to advertise all the SRv6 SIDs associated with that neighbor. 9. SRv6 SID Structure Sub-Sub-TLV SRv6 SID Structure Sub-Sub-TLV is an optional Sub-Sub-TLV of: SRv6 End SID Sub-TLV (Section 7.2) SRv6 End.X SID Sub-TLV (Section 8.1) SRv6 LAN End.X SID Sub-TLV (Section 8.2) SRv6 SID Structure Sub-Sub-TLV is used to advertise the structure of the SRv6 SID as defined in [RFC8986]. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LB Length | LN Length | Fun. Length | Arg. Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 1. Single octet as defined in section 9 of [ISO10589]. Psenak, et al. Expires 18 May 2023 [Page 16] Internet-Draft ISIS Srv6 Extensions November 2022 Length: Single octet as defined in section 9 of [ISO10589]. The length value is 4 octets. LB Length: 1 octet. SRv6 SID Locator Block length in bits. LN Length: 1 octet. SRv6 SID Locator Node length in bits. Fun. Length: 1 octet. SRv6 SID Function length in bits. Arg. Length: 1 octet. SRv6 SID Arguments length in bits. ISIS SRv6 SID Structure Sub-Sub-TLV MUST NOT appear more than once in its parent Sub-TLV. If it appears more than once in its parent Sub- TLV, the parent Sub-TLV MUST be ignored by the receiver. The sum of all four sizes advertised in ISIS SRv6 SID Structure Sub- Sub-TLV MUST be less than or equal to 128 bits. If the sum of all four sizes advertised in the ISIS SRv6 SID Structure Sub-Sub-TLV is larger than 128 bits, the parent Sub-TLV MUST be ignored by the receiver. The SRv6 SID Structure Sub-Sub-TLV is intended for informational use by the control and management planes. It MUST NOT be used at a transit node (as defined in [RFC8754]) for forwarding packets. As an example, this information could be used for: * validation of SRv6 SIDs being instantiated in the network and advertised via ISIS. These can be learnt by controllers via BGP- LS and then be monitored for conformance to the SRv6 SID allocation scheme chosen by the operator as described in Section 3.2 of [RFC8986]. * verification and the automation for securing the SRv6 domain by provisioning filtering rules at SR domain boundaries as described in Section 5 of [RFC8754]. The details of these potential applications are outside the scope of this document. 10. Advertising Endpoint Behaviors Endpoint behaviors are defined in [RFC8986]. The codepoints for the Endpoint behaviors are defined in the "SRv6 Endpoint Behaviors" registry defined in [RFC8986]. If a behavior is advertised it MUST only be advertised in the TLV[s] marked with "Y" in the table below, and MUST NOT be advertised in the TLV[s] marked with "N" in the table below. Psenak, et al. Expires 18 May 2023 [Page 17] Internet-Draft ISIS Srv6 Extensions November 2022 Endpoint |Endpoint | End | End.X | Lan End.X | Behavior |Behavior Codepoint| SID | SID | SID | ----------------------|------------------|-----|-------|-----------| End (PSP, USP, USD)| 1-4, 28-31 | Y | N | N | ----------------------|------------------|-----|-------|-----------| End.X (PSP, USP, USD)| 5-8, 32-35 | N | Y | Y | ----------------------|------------------|-----|-------|-----------| End.DX6 | 16 | N | Y | Y | ----------------------|------------------|-----|-------|-----------| End.DX4 | 17 | N | Y | Y | ----------------------|------------------|-----|-------|-----------| End.DT6 | 18 | Y | N | N | ----------------------|------------------|-----|-------|-----------| End.DT4 | 19 | Y | N | N | ----------------------|------------------|-----|-------|-----------| End.DT46 | 20 | Y | N | N | 11. IANA Considerations This document requests allocation for the following TLVs, sub-TLVs, and sub-sub-TLVs by updating the existing registries and defining new registries under the IS-IS TLV Codepoints registry. 11.1. SRv6 Locator TLV This document makes the following registrations in the "IS-IS Top- Level TLV Codepoints" registry: Type Description IIH LSP SNP Purge ---- --------------------- --- --- --- ----- 27 SRv6 Locator TLV n y n n 11.1.1. SRv6 End SID sub-TLV The SRv6 Locator TLV shares sub-TLV space with TLVs advertising prefix reachability. This document updates the "IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability" registry initially defined in [RFC7370]. IANA is asked to add this document as a reference to "IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability" registry and update the description of that registry to include the SRv6 Locator TLV (27). This document makes the following registrations in the "IS-IS Sub- TLVs for TLVs Advertising Prefix Reachability" registry: Type: 5 Psenak, et al. Expires 18 May 2023 [Page 18] Internet-Draft ISIS Srv6 Extensions November 2022 Description: SRv6 End SID. Reference: This document (Section 7.2). 11.1.2. Revised sub-TLV table The revised table of sub-TLVs for the "IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability" registry is shown below: Type 27 135 235 236 237 1 y y y y y 2 y y y y y 3 n y y y y 4 y y y y y 5 y n n n n 6 n y y y y 11 y y y y y 12 y y y y y 32 n y y y y 11.2. SRv6 Capabilities sub-TLV This document makes the following registrations in the "IS-IS Sub- TLVs for IS-IS Router CAPABILITY TLV": Type: 25 Description: SRv6 Capabilities. Reference: This document (Section 2). 11.3. Sub-Sub-TLVs of the SRv6 Capability sub-TLV This document requests a new IANA registry be created under the IS-IS TLV Codepoints registry to control the assignment of sub-TLV types for the SRv6 Capability sub-TLV specified in this document - Section 2: Name: IS-IS Sub-Sub-TLVs for SRv6 Capability Sub-TLV Description: This registry defines sub-sub-TLVs for the SRv6 Capability Sub-TLV (25) advertised in the IS-IS Router Capabilities TLV (242). Psenak, et al. Expires 18 May 2023 [Page 19] Internet-Draft ISIS Srv6 Extensions November 2022 The registration procedure is "Expert Review" as defined in [RFC8126]. Guidance for the Designated Experts is provided in the [RFC7370]. No sub-sub-TLVs are defined by this document except for the reserved type 0. Type Description Encoding Reference --------------------------------------------------------- 0 Reserved 1-255 Unassigned 11.4. SRv6 End.X SID and SRv6 LAN End.X SID sub-TLVs This document makes the following registrations in the "IS-IS Sub- TLVs for TLVs Advertising Neighbor Information" registry: Type: 43 Description: SRv6 End.X SID. Reference: This document (Section 8.1). Type: 44 Description: SRv6 LAN End.X SID. Reference: This document (Section 8.2). Type 22 23 25 141 222 223 43 y y y y y y 44 y y y y y y 11.5. MSD Types This document makes the following registrations in the IGP MSD-Types registry: Value Name Reference ------------------ 41 SRH Max SL [This Document] 42 SRH Max End Pop [This Document] 44 SRH Max H.encaps [This Document] 45 SRH Max End D [This Document] Psenak, et al. Expires 18 May 2023 [Page 20] Internet-Draft ISIS Srv6 Extensions November 2022 11.6. Sub-Sub-TLVs for SID Sub-TLVs This document requests a new IANA registry be created under the IS-IS TLV Codepoints registry to control the assignment of sub-TLV types for the SID Sub-TLVs specified in this document - Section 7.2, Section 8.1, Section 8.2: Name: IS-IS Sub-Sub-TLVs for SRv6 SID Sub-TLVs Description: This registry defines Sub-Sub-TLVs for SRv6 SID Sub- TLVs. This includes the following sub-TLVs: SRv6 End SID (5) (Advertised in SRv6 Locator TLV (27) SRv6 End.X SID (43) (Advertised in TLVs advertising neighbor information) SRv6 LAN End.X SID (44) (Advertised in TLVs advertising neighbor information) The registration procedure is "Expert Review" as defined in [RFC8126]. Guidance for the Designated Experts is provided in [RFC7370]. The following assignments are made by this document: Type Description Encoding Reference --------------------------------------------------------- 0 Reserved 1 SRv6 SID Structure [This Document] 2-255 Unassigned Type 5 43 44 1 y y y 11.7. Prefix Attribute Flags Sub-TLV This document adds a new bit in the "IS-IS Bit Values for Prefix Attribute Flags Sub-TLV" registry: Bit #: 4 Description: Anycast Flag (A-flag) Reference: This document (Section 6). Psenak, et al. Expires 18 May 2023 [Page 21] Internet-Draft ISIS Srv6 Extensions November 2022 11.8. IS-IS SRv6 Capabilities sub-TLV Flags Registry This document requests a new IANA registry be created under the IS-IS TLV Codepoints registry to control the assignment of bits 0 to 15 in the Flags field of the ISIS SRv6 Capabilities sub-TLV specified in this document (Section 2): Name: IS-IS SRv6 Capabilities Sub-TLV Flags Description: This registry defines bit values advertised in the flags field of the SRv6 Capabilities sub-TLV (25). This sub-TLV is advertised in the IS-IS Router CAPABILITY TLV (242). The registration procedure is "Expert Review" as defined in [RFC8126]. Guidance for the Designated Experts is provided in [RFC7370]. The following assignments are made by this document: Bit #: 1 Description: O-flag Reference: This document (Section 2). Bit #: 0, 2-15 Description: Unassigned 11.9. IS-IS SRv6 Locator TLV Flags Registry This document requests a new IANA registry be created under the IS-IS TLV Codepoints registry to control the assignment of bits 0 to 7 in the Flags field of the SRv6 Locator TLV specified in this document (Section 7.1): Name: IS-IS SRv6 Locator TLV Flags Description: This registry defines bit values advertised in the flags field of the SRv6 Locator TLV (27). The registration procedure is "Expert Review" as defined in [RFC8126]. Guidance for the Designated Experts is provided in [RFC7370]. The following assignments are made by this document: Bit #: 0 Description: D-flag Reference: This document (Section 7.1). Psenak, et al. Expires 18 May 2023 [Page 22] Internet-Draft ISIS Srv6 Extensions November 2022 Bit #: 1-7 Description: Unassigned 11.10. IS-IS SRv6 End SID sub-TLV Flags Registry This document requests a new IANA registry be created under the IS-IS TLV Codepoints registry to control the assignment of bits 0 to 7 in the Flags field of the ISIS SRv6 End SID sub-TLV specified in this document (Section 7.2): Name: IS-IS SRv6 End SID Sub-TLV Flags Description: This registry defines bit values advertised in the flags field of the SRv6 End SID sub-TLV, which is advertised in the SRv6 Locator TLV (27). The registration procedure is "Expert Review" as defined in [RFC8126]. Guidance for the Designated Experts is provided in [RFC7370]. No assignments are made by this document. Bit #: 0-7 Description: Unassigned 11.11. IS-IS SRv6 Adjacency SID sub-TLVs Flags Registry This document requests a new IANA registry be created under the IS-IS TLV Codepoints registry to control the assignment of bits 0 to 7 in the Flags field of the ISIS SRv6 End.X SID and LAN End.X SID sub-TLVs (Section 8.1 and Section 8.2): Name: IS-IS SRv6 Adjacency SID Sub-TLVs Flags. Description: This registry defines bit values advertised in the flags field of SRv6 SID sub-TLVs associated with adjacencies. These sub-TLVs are advertised in TLVs advertising neighbor information. The list of sub-TLVs includes: SRv6 End.X SID (43) SRv6 LAN End.X SID (44) The registration procedure is "Expert Review" as defined in [RFC8126]. Guidance for the Designated Experts is provided in [RFC7370]. The following assignments are made by this document: Bit #: 0 Psenak, et al. Expires 18 May 2023 [Page 23] Internet-Draft ISIS Srv6 Extensions November 2022 Description: B-flag Reference: This document (Section 8.1). Bit #: 1 Description: S-flag Reference: This document (Section 8.1). Bit #: 2 Description: P-flag Reference: This document (Section 8.1). Bit #: 3-7 Description: Unassigned 12. Security Considerations Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], and [RFC5310]. While IS-IS is deployed under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the IS-IS routing domain. In these deployments, the stronger authentication mechanisms defined in the aforementioned documents SHOULD be used. This document describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane. The security considerations for Segment Routing are discussed in [RFC8402]. [RFC8986] defines the SRv6 Network Programming concept and specifies the main Segment Routing behaviors to enable the creation of interoperable overlays; the security considerations from that document apply too. The advertisement for an incorrect MSD value may have negative consequences, see [RFC8491] for additional considerations. Security concerns associated with the setting of the O-flag are described in [I-D.ietf-6man-spring-srv6-oam]. Security concerns associated with the usage of Flex-Algorithms are described in [I-D.ietf-lsr-flex-algo]). Psenak, et al. Expires 18 May 2023 [Page 24] Internet-Draft ISIS Srv6 Extensions November 2022 13. Contributors The following people gave a substantial contribution to the content of this document and should be considered as co-authors: Stefano Previdi Huawei Technologies Email: stefano@previdi.net Paul Wells Cisco Systems Saint Paul, Minnesota United States Email: pauwells@cisco.com Daniel Voyer Email: daniel.voyer@bell.ca Satoru Matsushima Email: satoru.matsushima@g.softbank.co.jp Bart Peirens Email: bart.peirens@proximus.com Hani Elmalky Email: hani.elmalky@ericsson.com Prem Jonnalagadda Email: prem@barefootnetworks.com Milad Sharif Email: msharif@barefootnetworks.com> Robert Hanzl Cisco Systems Millenium Plaza Building, V Celnici 10, Prague 1, Prague, Czech Republic Email rhanzl@cisco.com Ketan Talaulikar Cisco Systems, Inc. Email: ketant@cisco.com 14. Acknowledgments Thanks to Christian Hopps for his review comments and shepherd work. Psenak, et al. Expires 18 May 2023 [Page 25] Internet-Draft ISIS Srv6 Extensions November 2022 Thanks to Alvaro Retana and John Scudder for AD review and comments. 15. References 15.1. Normative References [I-D.ietf-6man-spring-srv6-oam] Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. Chen, "Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)", Work in Progress, Internet-Draft, draft-ietf-6man-spring- srv6-oam-13, 23 January 2022, . [I-D.ietf-lsr-flex-algo] Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", Work in Progress, Internet-Draft, draft-ietf-lsr-flex-algo-26, 17 October 2022, . [ISO10589] ISO, "Intermediate system to Intermediate system intra- domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", November 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, . Psenak, et al. Expires 18 May 2023 [Page 26] Internet-Draft ISIS Srv6 Extensions November 2022 [RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014, . [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, . [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, DOI 10.17487/RFC8491, November 2018, . [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, . [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, . Psenak, et al. Expires 18 May 2023 [Page 27] Internet-Draft ISIS Srv6 Extensions November 2022 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . 15.2. Informative References [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, . [RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. Shakir, "Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks", RFC 8355, DOI 10.17487/RFC8355, March 2018, . Authors' Addresses Peter Psenak (editor) Cisco Systems Pribinova Street 10 Bratislava 81109 Slovakia Email: ppsenak@cisco.com Clarence Filsfils Cisco Systems Brussels Belgium Email: cfilsfil@cisco.com Psenak, et al. Expires 18 May 2023 [Page 28] Internet-Draft ISIS Srv6 Extensions November 2022 Ahmed Bashandy Cisco Systems Milpitas, United States of America Email: bashandy@cisco.com Bruno Decraene Orange Issy-les-Moulineaux France Email: bruno.decraene@orange.com Zhibo Hu Huawei Technologies Email: huzhibo@huawei.com Psenak, et al. Expires 18 May 2023 [Page 29] ./draft-ietf-i2nsf-nsf-facing-interface-dm-29.txt0000644000764400076440000047672614245671205021301 0ustar iustiniustin I2NSF Working Group J. Kim, Ed. Internet-Draft J. Jeong, Ed. Intended status: Standards Track Sungkyunkwan University Expires: 3 December 2022 J. Park ETRI S. Hares Q. Lin Huawei 1 June 2022 I2NSF Network Security Function-Facing Interface YANG Data Model draft-ietf-i2nsf-nsf-facing-interface-dm-29 Abstract This document defines a YANG data model for configuring security policy rules on Network Security Functions (NSF) in the Interface to Network Security Functions (I2NSF) framework. The YANG data model in this document is for the NSF-Facing Interface between a Security Controller and NSFs in the I2NSF framework. It is built on the basis of the YANG data model in the I2NSF Capability YANG Data Model document for the I2NSF framework. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 December 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Kim, et al. Expires 3 December 2022 [Page 1] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 3.1. General I2NSF Security Policy Rule . . . . . . . . . . . 3 3.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 6 3.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 12 4. YANG Data Model of NSF-Facing Interface . . . . . . . . . . . 14 4.1. YANG Module of NSF-Facing Interface . . . . . . . . . . . 14 5. XML Configuration Examples of Low-Level Security Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.1. Example Security Requirement 1: Block Social Networking Service (SNS) Access during Business Hours . . . . . . . 62 5.2. Example Security Requirement 2: Block Malicious VoIP/VoCN Packets Coming to a Company . . . . . . . . . . . . . . . 66 5.3. Example Security Requirement 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web Server . . . . . . . . . . 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 73 8.2. Informative References . . . . . . . . . . . . . . . . . 78 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 79 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 79 Appendix C. Changes from draft-ietf-i2nsf-nsf-facing-interface-dm-28 . . . . . . . 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 1. Introduction This document defines a YANG [RFC6020][RFC7950] data model for security policy rule configuration of Network Security Functions (NSF). The YANG data model in this document is based on the data model described in [I-D.ietf-i2nsf-capability-data-model] for the NSF-Facing Interface in the Interface to Network Security Functions (I2NSF) architecture [RFC8329]. The YANG data model in this document focuses on security policy configuration for the NSFs discussed in Kim, et al. Expires 3 December 2022 [Page 2] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 [I-D.ietf-i2nsf-capability-data-model], i.e., generic NSF (operate on packet header for layer 2, layer3, and layer 4) and advanced NSF (Intrusion Prevention System, URL-Filtering, anti-DDoS, Antivirus, and VoIP/VoCN Filter). Note: VoIP is an abbreviation for Voice over Internet Protocol and VoCN is an abbreviation for Voice over Cellular Network, such as Voice over LTE or 5G. This YANG data model uses an "Event-Condition-Action" (ECA) policy model that is used as the basis for the design of I2NSF Policy described in [RFC8329] and [I-D.ietf-i2nsf-capability-data-model]. The "ietf-i2nsf-nsf-facing-interface" YANG module defined in this document provides the configuration of the following features. * A security policy rule of a network security function. * An event clause of a generic network security function. * A condition clause of a generic network security function. * An action clause of a generic network security function. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the terminology described in [RFC8329]. This document follows the guidelines of [RFC8407], uses the common YANG types defined in [RFC6991], and adopts the Network Management Datastore Architecture (NMDA) [RFC8342]. The meaning of the symbols in tree diagrams is defined in [RFC8340]. 3. YANG Tree Diagram This section shows a YANG tree diagram of policy for network security functions. 3.1. General I2NSF Security Policy Rule This section shows a YANG tree diagram for a general I2NSF security policy rule for generic network security functions. Kim, et al. Expires 3 December 2022 [Page 3] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 module: ietf-i2nsf-nsf-facing-interface +--rw i2nsf-security-policy* [name] +--rw name string +--rw language? string +--rw priority-usage? identityref +--rw resolution-strategy? identityref +--rw default-action? identityref +--rw rules* [name] | +--rw name string | +--rw description? string | +--rw priority? uint8 | +--rw enable? boolean | +--rw long-connection | | +--rw enable? boolean | | +--rw duration? uint32 | +--rw event | | ... | +--rw condition | | ... | +--rw action | ... +--rw rule-group +--rw groups* [group-name] +--rw group-name string +--rw rule-name* -> ../../../rules/name +--rw enable? boolean +--rw description? string Figure 1: YANG Tree Diagram for Network Security Policy A security policy is used by one virtual instance of an NSF/device as a set of security rules to protect assets from major risk factors that threaten the system. There can be multiple security policies in a single NSF to provide the necessary protection. The security policy includes its name, language tag, priority usage, resolution strategy, default action, and rules. The language field indicates the language tag that is used for the natural language text that is included in all of the 'description' attributes. The language field is encoded following the rules in Section 2.1 of [RFC5646]. The default language tag is "en-US". A resolution strategy is used to decide how to resolve conflicts that occur between the actions of the same or different policy rules that are matched and contained in a particular NSF. The resolution strategy is defined as First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized Matching Rule (PMR) with Errors (PMRE), and Prioritized Matching Rule with No Errors (PMRN). The resolution Kim, et al. Expires 3 December 2022 [Page 4] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 strategy can be extended according to specific vendor action features. The resolution strategy is described in detail in [I-D.ietf-i2nsf-capability-data-model]. A default action is used to execute I2NSF policy rule when no rule matches a packet. The default action can be pass, drop, reject, rate-limit, or mirror actions. The default action can be extended according to specific vendor action features. The default action is described in detail in [I-D.ietf-i2nsf-capability-data-model]. The rules include rule name, rule description, rule priority, rule enable, event, condition, and action. 3.2. Event Clause This section shows a YANG tree diagram for an event clause for a general I2NSF security policy rule for generic network security functions. module: ietf-i2nsf-nsf-facing-interface +--rw i2nsf-security-policy* [name] ... +--rw rules* [name] | ... | +--rw event | | +--rw description? string | | +--rw system-event* identityref | | +--rw system-alarm* identityref | +--rw condition | | ... | +--rw action | ... +--rw rule-group ... Figure 2: YANG Tree Diagram for an Event Clause An event clause is any important occurrence at a specific time of a change in the system being managed, and/or in the environment of the system being managed. An event clause is used to trigger the evaluation of the condition clause of the I2NSF Policy Rule. The event clause is defined as a system event, system alarm [I-D.ietf-i2nsf-nsf-monitoring-data-model], and time. The event clause can be extended according to specific vendor event features. The event clause is described in detail in [I-D.ietf-i2nsf-capability-data-model]. Kim, et al. Expires 3 December 2022 [Page 5] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 3.3. Condition Clause This section shows a YANG tree diagram for a condition clause for a general I2NSF security policy rule for generic network security functions. module: ietf-i2nsf-nsf-facing-interface +--rw i2nsf-security-policy* [name] ... +--rw rules* [name] | ... | +--rw event | | ... | +--rw condition | | +--rw description? string | | +--rw layer-2* [destination-mac-address source-mac-address ethertype] | | | +--rw description? string | | | +--rw destination-mac-address yang:mac-address | | | +--rw destination-mac-address-mask? yang:mac-address | | | +--rw source-mac-address yang:mac-address | | | +--rw source-mac-address-mask? yang:mac-address | | | +--rw ethertype eth:ethertype | | +--rw (layer-3)? | | | +--:(ipv4) | | | | +--rw ipv4 | | | | +--rw description? string | | | | +--rw dscp? inet:dscp | | | | +--rw ecn? uint8 | | | | +--rw length? uint16 | | | | +--rw ttl? uint8 | | | | +--rw protocol? uint8 | | | | +--rw ihl? uint8 | | | | +--rw flags? bits | | | | +--rw offset? uint16 | | | | +--rw identification? uint16 | | | | +--rw (destination-network)? | | | | | +--:(destination-ipv4-network) | | | | | | +--rw destination-ipv4-network? inet:ipv4-prefix | | | | | +--:(destination-ipv4-range) | | | | | +--rw destination-ipv4-range* [start end] | | | | | +--rw start inet:ipv4-address-no-zone | | | | | +--rw end inet:ipv4-address-no-zone | | | | +--rw (source-network)? | | | | +--:(source-ipv4-network) | | | | | +--rw source-ipv4-network? inet:ipv4-prefix Kim, et al. Expires 3 December 2022 [Page 6] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 | | | | +--:(source-ipv4-range) | | | | +--rw source-ipv4-range* [start end] | | | | +--rw start inet:ipv4-address-no-zone | | | | +--rw end inet:ipv4-address-no-zone | | | +--:(ipv6) | | | +--rw ipv6 | | | +--rw description? string | | | +--rw dscp? inet:dscp | | | +--rw ecn? uint8 | | | +--rw length? uint16 | | | +--rw ttl? uint8 | | | +--rw protocol? uint8 | | | +--rw (destination-network)? | | | | +--:(destination-ipv6-network) | | | | | +--rw destination-ipv6-network? inet:ipv6-prefix | | | | +--:(destination-ipv6-range) | | | | +--rw destination-ipv6-range* [start end] | | | | +--rw start inet:ipv6-address-no-zone | | | | +--rw end inet:ipv6-address-no-zone | | | +--rw (source-network)? | | | | +--:(source-ipv6-network) | | | | | +--rw source-ipv6-network? inet:ipv6-prefix | | | | +--:(source-ipv6-range) | | | | +--rw source-ipv6-range* [start end] | | | | +--rw start inet:ipv6-address-no-zone | | | | +--rw end inet:ipv6-address-no-zone | | | +--rw flow-label? inet:ipv6-flow-label | | +--rw (layer-4)? | | | +--:(tcp) | | | | +--rw tcp | | | | +--rw description? string | | | | +--rw source-port-number | | | | | +--rw (source-port)? | | | | | +--:(range-or-operator) | | | | | | +--rw (port-range-or-operator)? | | | | | | +--:(range) | | | | | | | +--rw lower-port inet:port-number | | | | | | | +--rw upper-port inet:port-number | | | | | | +--:(operator) | | | | | | +--rw operator? operator | | | | | | +--rw port inet:port-number | | | | | +--:(port-list) | | | | | +--rw port-numbers* [start end] | | | | | +--rw start inet:port-number | | | | | +--rw end inet:port-number | | | | +--rw destination-port-number | | | | | +--rw (destination-port)? Kim, et al. Expires 3 December 2022 [Page 7] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 | | | | | +--:(range-or-operator) | | | | | | +--rw (port-range-or-operator)? | | | | | | +--:(range) | | | | | | | +--rw lower-port inet:port-number | | | | | | | +--rw upper-port inet:port-number | | | | | | +--:(operator) | | | | | | +--rw operator? operator | | | | | | +--rw port inet:port-number | | | | | +--:(port-list) | | | | | +--rw port-numbers* [start end] | | | | | +--rw start inet:port-number | | | | | +--rw end inet:port-number | | | | +--rw sequence-number? uint32 | | | | +--rw acknowledgement-number? uint32 | | | | +--rw data-offset? uint8 | | | | +--rw reserved? uint8 | | | | +--rw flags? bits | | | | +--rw window-size? uint16 | | | | +--rw urgent-pointer? uint16 | | | | +--rw options? binary | | | +--:(udp) | | | | +--rw udp | | | | +--rw description? string | | | | +--rw source-port-number | | | | | +--rw (source-port)? | | | | | +--:(range-or-operator) | | | | | | +--rw (port-range-or-operator)? | | | | | | +--:(range) | | | | | | | +--rw lower-port inet:port-number | | | | | | | +--rw upper-port inet:port-number | | | | | | +--:(operator) | | | | | | +--rw operator? operator | | | | | | +--rw port inet:port-number | | | | | +--:(port-list) | | | | | +--rw port-numbers* [start end] | | | | | +--rw start inet:port-number | | | | | +--rw end inet:port-number | | | | +--rw destination-port-number | | | | | +--rw (destination-port)? | | | | | +--:(range-or-operator) | | | | | | +--rw (port-range-or-operator)? | | | | | | +--:(range) | | | | | | | +--rw lower-port inet:port-number | | | | | | | +--rw upper-port inet:port-number | | | | | | +--:(operator) | | | | | | +--rw operator? operator | | | | | | +--rw port inet:port-number | | | | | +--:(port-list) Kim, et al. Expires 3 December 2022 [Page 8] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 | | | | | +--rw port-numbers* [start end] | | | | | +--rw start inet:port-number | | | | | +--rw end inet:port-number | | | | +--rw length? uint16 | | | +--:(sctp) | | | | +--rw sctp | | | | +--rw description? string | | | | +--rw source-port-number | | | | | +--rw (source-port)? | | | | | +--:(range-or-operator) | | | | | | +--rw (port-range-or-operator)? | | | | | | +--:(range) | | | | | | | +--rw lower-port inet:port-number | | | | | | | +--rw upper-port inet:port-number | | | | | | +--:(operator) | | | | | | +--rw operator? operator | | | | | | +--rw port inet:port-number | | | | | +--:(port-list) | | | | | +--rw port-numbers* [start end] | | | | | +--rw start inet:port-number | | | | | +--rw end inet:port-number | | | | +--rw destination-port-number | | | | | +--rw (destination-port)? | | | | | +--:(range-or-operator) | | | | | | +--rw (port-range-or-operator)? | | | | | | +--:(range) | | | | | | | +--rw lower-port inet:port-number | | | | | | | +--rw upper-port inet:port-number | | | | | | +--:(operator) | | | | | | +--rw operator? operator | | | | | | +--rw port inet:port-number | | | | | +--:(port-list) | | | | | +--rw port-numbers* [start end] | | | | | +--rw start inet:port-number | | | | | +--rw end inet:port-number | | | | +--rw chunk-type* uint8 | | | | +--rw chunk-length? uint16 | | | +--:(dccp) | | | | +--rw dccp | | | | +--rw description? string | | | | +--rw source-port-number | | | | | +--rw (source-port)? | | | | | +--:(range-or-operator) | | | | | | +--rw (port-range-or-operator)? | | | | | | +--:(range) | | | | | | | +--rw lower-port inet:port-number | | | | | | | +--rw upper-port inet:port-number | | | | | | +--:(operator) Kim, et al. Expires 3 December 2022 [Page 9] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 | | | | | | +--rw operator? operator | | | | | | +--rw port inet:port-number | | | | | +--:(port-list) | | | | | +--rw port-numbers* [start end] | | | | | +--rw start inet:port-number | | | | | +--rw end inet:port-number | | | | +--rw destination-port-number | | | | | +--rw (destination-port)? | | | | | +--:(range-or-operator) | | | | | | +--rw (port-range-or-operator)? | | | | | | +--:(range) | | | | | | | +--rw lower-port inet:port-number | | | | | | | +--rw upper-port inet:port-number | | | | | | +--:(operator) | | | | | | +--rw operator? operator | | | | | | +--rw port inet:port-number | | | | | +--:(port-list) | | | | | +--rw port-numbers* [start end] | | | | | +--rw start inet:port-number | | | | | +--rw end inet:port-number | | | | +--rw service-code* uint32 | | | | +--rw type* uint8 | | | | +--rw data-offset? uint8 | | | +--:(icmp) | | | +--rw icmp | | | +--rw description? string | | | +--rw version? enumeration | | | +--rw type? uint8 | | | +--rw code? uint8 | | | +--rw rest-of-header? binary | | +--rw url-category | | | +--rw description? string | | | +--rw pre-defined* string | | | +--rw user-defined* string | | +--rw voice | | | +--rw description? string | | | +--rw source-voice-id* string | | | +--rw destination-voice-id* string | | | +--rw user-agent* string | | +--rw ddos | | | +--rw description? string | | | +--rw alert-packet-rate? uint32 | | | +--rw alert-flow-rate? uint32 | | | +--rw alert-byte-rate? uint32 | | +--rw anti-virus | | | +--rw profile* string | | | +--rw exception-files* string | | +--rw payload Kim, et al. Expires 3 December 2022 [Page 10] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 | | | +--rw description? string | | | +--rw content* binary | | +--rw context | | +--rw description? string | | +--rw time | | | +--rw start-date-time? yang:date-and-time | | | +--rw end-date-time? yang:date-and-time | | | +--rw period | | | | +--rw start-time? time | | | | +--rw end-time? time | | | | +--rw day* day | | | | +--rw date* int8 | | | | +--rw month* string | | | +--rw frequency? enumeration | | +--rw application | | | +--rw description? string | | | +--rw protocol* identityref | | +--rw device-type | | | +--rw description? string | | | +--rw device* identityref | | +--rw users | | | +--rw description? string | | | +--rw user* [id] | | | | +--rw id uint32 | | | | +--rw name? string | | | +--rw group* [id] | | | +--rw id uint32 | | | +--rw name? string | | +--rw geographic-location | | +--rw description? string | | +--rw source* string | | +--rw destination* string | +--rw action | ... +--rw rule-group ... Figure 3: YANG Tree Diagram for a Condition Clause A condition clause is defined as a set of attributes, features, and/ or values that are to be compared with a set of known attributes, features, and/or values in order to determine whether the set of actions in that (imperative) I2NSF policy rule can be executed or not. A condition clause works with 'AND' logic, where all fields set in the condition MUST match the packet or flow for the condition to be evaluated as 'TRUE'. A condition clause is classified as a Kim, et al. Expires 3 December 2022 [Page 11] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 condition of generic network security functions, advanced network security functions, or context. A condition clause of generic network security functions is defined as IPv4 condition, IPv6 condition, TCP condition, UDP condition, SCTP condition, DCCP condition, or ICMP (ICMPv4 and ICMPv6) condition. Note that the data model in this document does not focus on only IP addresses, but focuses on all the fields of IPv4 and IPv6 headers. The IPv4 and IPv6 headers have similarity with some different fields. In this case, it is better to handle separately the IPv4 and IPv6 headers such that the different fields can be used to handle IPv4 and IPv6 packets. Also, note that the YANG data model in this document is based on the YANG Data Model for Network Access Control Lists (ACLs) [RFC8519] that does not support IPv6 extension headers including various options, the support of IPv6 extension headers is left as future work. The data model provides transport layer condition for TCP, UDP, SCTP, and DCCP. With ICMPv4 and ICMPv6 are included as a choice for layer 4 as the header fields in ICMP are above the network layer. Note that QUIC protocol [RFC9000] is excluded in the data model as it is not considered in the initial I2NSF documents [RFC8329]. The QUIC traffic should not be treated as UDP traffic and will be considered in the future I2NSF documents. A condition clause of advanced network security functions is defined as url category condition, voice condition, DDoS condition, or payload condition. A condition clause of context is defined as application condition, target condition, users condition, and geography condition. Note that this document deals only with conditions of several advanced network security functions such as url filter (i.e., web filter), VoIP/VoCN security, and DDoS-attack mitigator. A condition clause of other advanced network security functions such as Intrusion Prevention System (IPS) and Data Loss Prevention (DLP) can be defined as an extension in future. A condition clause can be extended according to specific vendor condition features. A condition clause is described in detail in [I-D.ietf-i2nsf-capability-data-model]. 3.4. Action Clause This section shows a YANG tree diagram for an action clause for a general I2NSF security policy rule for generic network security functions. Kim, et al. Expires 3 December 2022 [Page 12] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 module: ietf-i2nsf-nsf-facing-interface +--rw i2nsf-security-policy* [name] ... +--rw rules* [name] | ... | +--rw event | ... | +--rw condition | ... | +--rw action | +--rw description? string | +--rw packet-action | | +--rw ingress-action? identityref | | +--rw egress-action? identityref | | +--rw log-action? identityref | +--rw flow-action | | +--rw ingress-action? identityref | | +--rw egress-action? identityref | | +--rw log-action? identityref | +--rw advanced-action | +--rw content-security-control* identityref | +--rw attack-mitigation-control* identityref +--rw rule-group ... Figure 4: YANG Tree Diagram for an Action Clause An action is used to control and monitor aspects of flow-based NSFs when the policy rule event and condition clauses are satisfied. NSFs provide security services by executing various actions. The action clause is defined as ingress action, egress action, or log action for packet action, flow action, and advanced action for additional inspection. The packet action is an action for an individual packet such as an IP datagram as a stateless process that uses the packet's header and payload. The flow action is an action of a traffic flow such as the packets of a TCP session (e.g., an HTTP/HTTPS session) as a stateful process that uses the traffic flow information such as 5-tuple information, packet counts, and byte counts. The advanced action is an action for an advanced security service (e.g., url filter, DDoS-attack mitigator, and VoIP/VoCN filter) for either a packet or a traffic flow according to the intention of such an advanced security service. The action clause can be extended according to specific vendor action features. The action clause is described in detail in [I-D.ietf-i2nsf-capability-data-model]. Kim, et al. Expires 3 December 2022 [Page 13] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 Note that an empty event clause means that the event boolean will always evaluate to true and starts the evaluation of the condition clause, while an empty condition clause means that the condition boolean will always evaluate to false. 4. YANG Data Model of NSF-Facing Interface The main objective of this document is to provide the YANG data model of the I2NSF NSF-Facing Interface. This interface can be used to deliver control and management messages between a Security Controller and NSFs for the I2NSF low-level security policies. This data model is designed to support the I2NSF framework that can be extended according to the security needs. In other words, the model design is independent of the content and meaning of specific policies as well as the implementation approach. With the YANG data model of I2NSF NSF-Facing Interface, this document suggests use cases for security policy rules such as time-based firewall, web filter, VoIP/VoCN security service, and DDoS-attack mitigation in Section 5. 4.1. YANG Module of NSF-Facing Interface This section describes a YANG module of NSF-Facing Interface. This document provides identities in the data model for the configuration of an NSF. The identity has the same concept with the corresponding identity in [I-D.ietf-i2nsf-consumer-facing-interface-dm]. This YANG module imports from [RFC6991] and [RFC8519]. It makes references to [RFC0768] [RFC0791] [RFC0792] [RFC0854] [RFC0959] [RFC1939] [RFC2132] [RFC2595] [RFC3261] [RFC3986] [RFC4250] [RFC4340] [RFC4443] [RFC4732] [RFC4987] [RFC5321] [RFC5595] [RFC5646] [RFC6335] [RFC8075] [RFC8200] [RFC8329] [RFC8335] [RFC9051] [RFC9179] [GLOB] [IEEE-802.3] [ISO-3166] [I-D.ietf-httpbis-http2bis] [I-D.ietf-httpbis-messaging] [I-D.ietf-httpbis-semantics] [I-D.ietf-i2nsf-capability-data-model] [I-D.ietf-i2nsf-nsf-monitoring-data-model] [I-D.ietf-tcpm-rfc793bis] [I-D.ietf-tsvwg-rfc4960-bis] file "ietf-i2nsf-nsf-facing-interface@2022-06-01.yang" module ietf-i2nsf-nsf-facing-interface { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-facing-interface"; prefix i2nsfnfi; import ietf-inet-types { prefix inet; Kim, et al. Expires 3 December 2022 [Page 14] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 reference "Section 4 of RFC 6991"; } import ietf-yang-types { prefix yang; reference "Section 3 of RFC 6991"; } import ietf-packet-fields { prefix packet-fields; reference "Section 4.2 of RFC 8519"; } organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact "WG Web: WG List: Editor: Jinyong Tim Kim Editor: Jaehoon Paul Jeong "; description "This module is a YANG module for Network Security Functions (NSF)-Facing Interface. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). Kim, et al. Expires 3 December 2022 [Page 15] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; revision "2022-06-01"{ description "The latest revision."; reference "RFC XXXX: I2NSF Network Security Function-Facing Interface YANG Data Model"; } /* * Identities */ identity priority-usage { description "Base identity for priority usage type to define the type of priority to be implemented in a security policy rule, such as priority by order and priority by number."; } identity priority-by-order { base priority-usage; description "This indicates that the priority of a security policy rule follows the order of the configuration. The earlier the configuration is, the higher the priority is."; } identity priority-by-number { base priority-usage; description "This indicates the priority of a security policy rule follows the number or value of the configuration. The higher the value is, the higher the priority is."; } identity event { description "Base identity for policy events."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF Monitoring Interface YANG Data Model - Event"; } identity system-event { base event; Kim, et al. Expires 3 December 2022 [Page 16] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 description "Base Identity for system events. System event (also called alert) is defined as a warning about any changes of configuration, any access violation, the information of sessions and traffic flows."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF Monitoring Interface YANG Data Model - System event"; } identity system-alarm { base event; description "Base identity for system alarms. System alarm is defined as a warning related to service degradation in system hardware."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF Monitoring Interface YANG Data Model - System alarm"; } identity access-violation { base system-event; description "Access-violation system event is an event when a user tries to access (read, write, create, or delete) any information or execute commands above their privilege (i.e., not-conformant with the access profile)."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF Monitoring Interface YANG Data Model - System event for access violation"; } identity configuration-change { base system-event; description "The configuration-change system event is an event when a user adds a new configuration or modify an existing configuration (write configuration)."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF Monitoring Interface YANG Data Model - System event for configuration change"; } identity memory-alarm { base system-alarm; description Kim, et al. Expires 3 December 2022 [Page 17] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 "Memory is the hardware to store information temporarily or for a short period, i.e., Random Access Memory (RAM). A memory-alarm is emitted when the memory usage is exceeding the threshold."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF Monitoring Interface YANG Data Model - System alarm for memory"; } identity cpu-alarm { base system-alarm; description "CPU is the Central Processing Unit that executes basic operations of the system. A cpu-alarm is emitted when the CPU usage is exceeding a threshold."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF Monitoring Interface YANG Data Model - System alarm for CPU"; } identity disk-alarm { base system-alarm; description "Disk or storage is the hardware to store information for a long period, i.e., Hard Disk and Solid-State Drive. A disk-alarm is emitted when the disk usage is exceeding a threshold."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF Monitoring Interface YANG Data Model - System alarm for disk"; } identity hardware-alarm { base system-alarm; description "A hardware alarm is emitted when a hardware failure (e.g., CPU, memory, disk, or interface) is detected. A hardware failure is a malfunction within the electronic circuits or electromechanical components of the hardware that makes it unusable."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF Monitoring Interface YANG Data Model - System alarm for hardware"; } identity interface-alarm { Kim, et al. Expires 3 December 2022 [Page 18] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 base system-alarm; description "Interface is the network interface for connecting a device with the network. The interface-alarm is emitted when the state of the interface is changed."; reference "draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF Monitoring Interface YANG Data Model - System alarm for interface"; } identity device-type { description "Base identity for types of device. This identity is used for type of the device for the source or destination of a packet or traffic flow. Note that the device type of either a source or destination can be known with the help of DHCP Fingerprinting and the interaction between an NSF and a DHCP server."; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model RFC 2132: DHCP Options and BOOTP Vendor Extensions - Vendor Specific Information including device type, manufacturer, and operating system as DHCP fingerprinting information"; } identity computer { base device-type; description "Identity for computer such as personal computer (PC) and server."; } identity mobile-phone { base device-type; description "Identity for mobile-phone such as smartphone and cellphone"; } identity voip-vocn-phone { base device-type; description "Identity for VoIP (Voice over Internet Protocol) or VoCN (Voice over Cellular Network, such as Voice over LTE or 5G) phone"; Kim, et al. Expires 3 December 2022 [Page 19] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 } identity tablet { base device-type; description "Identity for tablet devices"; } identity network-infrastructure-device { base device-type; description "Identity for network infrastructure devices such as switch, router, and access point"; } identity iot-device { base device-type; description "Identity for Internet of Things (IoT) devices such as sensors, actuators, and low-power low-capacity computing devices"; } identity ot { base device-type; description "Identity for Operational Technology (OT) devices (also known as industrial control systems) that interact with the physical environment and detect or cause direct change through the monitoring and control of devices, processes, and events such as programmable logic controllers (PLCs), digital oscilloscopes, building management systems (BMS), and fire control systems"; } identity vehicle { base device-type; description "Identity for transportation vehicles that connect to and share data through the Internet over Vehicle-to-Everything (V2X) communications."; } identity advanced-nsf { description "Base identity for advanced Network Security Function (NSF) capability. This can be used for advanced NSFs such as Anti-DDoS Attack, IPS, URL-Filtering, Antivirus, Kim, et al. Expires 3 December 2022 [Page 20] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 and VoIP/VoCN Filter."; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model"; } identity content-security-control { base advanced-nsf; description "Base identity for content security control. Content security control is an NSF that evaluates the payload of a packet, such as Intrusion Prevention System (IPS), URL Filter, Antivirus, and VoIP/VoCN Filter."; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model"; } identity ips { base content-security-control; description "IPS (Intrusion Prevention System) prevents malicious activity within a network"; } identity url-filtering { base content-security-control; description "URL filtering limits access by comparing the web traffic's URL with the URLs for web filtering in a database"; } identity anti-virus { base content-security-control; description "Antivirus to protect the network by detecting and removing viruses or malwares."; } identity voip-vocn-filtering { base content-security-control; description "VoIP (Voice over Internet Protocol) and VoCN (Voice over Cellular Network, such as Voice over LTE or 5G) security service that filters out the packets or flows of malicious users with a deny-list of malicious users in a database"; } Kim, et al. Expires 3 December 2022 [Page 21] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 identity attack-mitigation-control { base advanced-nsf; description "Base identity for attack mitigation control. Attack mitigation control is an NSF that mitigates an attack such as anti-DDoS (i.e., DDoS-mitigator)."; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model"; } identity anti-ddos { base attack-mitigation-control; description "Anti-DDoS or DDoS Mitigator to protect a server or network from a DDoS attack. The mitigation approach is up to the implementation."; reference "RFC 4732: Internet Denial-of-Service Considerations - DoS Mitigation Strategies RFC 4987: TCP SYN Flooding Attacks and Common Mitigations - Common Defenses"; } identity action { description "Base identity for action."; } identity ingress-action { base action; description "Base identity for ingress action. The action to handle the network traffic that is entering the secured network."; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Ingress Action"; } identity egress-action { base action; description "Base identity for egress action. The action to handle the network traffic that is exiting the secured network."; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Egress Action"; } Kim, et al. Expires 3 December 2022 [Page 22] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 identity default-action { base action; description "Base identity for default action. The default action of the NSF when no rule matches the packet or flow."; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Default Action"; } identity pass { base ingress-action; base egress-action; base default-action; description "The pass action allows traffic that matches the rule to proceed through the NSF to reach the destination."; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Actions and Default Action"; } identity drop { base ingress-action; base egress-action; base default-action; description "The drop action denies the traffic that matches the rule. The drop action should do a silent drop, which does not give any response to the source."; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Actions and Default Action"; } identity reject { base ingress-action; base egress-action; base default-action; description "The reject action denies a packet to go through the NSF entering or exiting the internal network and sends a response back to the source. The response depends on the packet and implementation. For example, a TCP packet is rejected with TCP RST response or a UDP packet may be rejected with an Kim, et al. Expires 3 December 2022 [Page 23] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 ICMPv4 response message with Type 3 Code 3 or ICMPv6 response message Type 1 Code 4 (i.e., Destination Unreachable: Destination port unreachable)."; } identity mirror { base ingress-action; base egress-action; base default-action; description "The mirror action copies a packet and sends the packet's copy to the monitoring entity while still allowing the packet or flow to go through the NSF."; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Actions and Default Action"; } identity rate-limit { base ingress-action; base egress-action; base default-action; description "The rate limit action limits the number of packets or flows that can go through the NSF by dropping packets or flows (randomly or systematically). The drop mechanism, e.g., silent drop and unreachable drop (i.e., reject), is up to the implementation"; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Actions and Default Action"; } identity log-action { base action; description "Base identity for log action"; } identity rule-log { base log-action; description "Log the policy rule that has been triggered by a packet or flow."; } Kim, et al. Expires 3 December 2022 [Page 24] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 identity session-log { base log-action; description "A session is a connection (i.e., traffic flow) of a data plane that includes source and destination information of IP addresses and transport port numbers with the protocol used. Log the session that triggered a policy rule."; } identity invoke-signaling { base egress-action; description "The invoke-signaling action is used to convey information of the event triggering this action to a monitoring entity."; } identity tunnel-encapsulation { base egress-action; description "The tunnel encapsulation action is used to encapsulate the packet to be tunneled across the network to enable a secure connection."; } identity forwarding { base egress-action; description "The forwarding action is used to relay the packet from one network segment to another node in the network."; } identity transformation { base egress-action; description "The transformation action is used to transform a packet by modifying it (e.g., HTTP-to-CoAP packet translation). Note that a subset of transformation (e.g., HTTP-to-CoAP) is handled in this YANG module, rather than all the existing transformations. Specific algorithmic transformations can be executed by a middlebox (e.g., NSF) for a given transformation name."; reference "RFC 8075: Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) - Translation between HTTP and CoAP."; } identity resolution-strategy { Kim, et al. Expires 3 December 2022 [Page 25] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 description "Base identity for resolution strategy"; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Resolution Strategy"; } identity fmr { base resolution-strategy; description "Conflict resolution with First Matching Rule (FMR)."; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Resolution Strategy"; } identity lmr { base resolution-strategy; description "Conflict resolution with Last Matching Rule (LMR)"; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Resolution Strategy"; } identity pmre { base resolution-strategy; description "Conflict resolution with Prioritized Matching Rule with Errors (PMRE)"; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Resolution Strategy"; } identity pmrn { base resolution-strategy; description "Conflict resolution with Prioritized Matching Rule with No Errors (PMRN)"; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Resolution Strategy"; } identity application-protocol { description "Base identity for Application protocol. Note that a subset of Kim, et al. Expires 3 December 2022 [Page 26] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 application protocols (e.g., HTTP, HTTPS, FTP, POP3, and IMAP) are handled in this YANG module, rather than all the existing application protocols."; } identity http { base application-protocol; description "The identity for Hypertext Transfer Protocol version 1.1 (HTTP/1.1)."; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics draft-ietf-httpbis-messaging-19: HTTP/1.1"; } identity https { base application-protocol; description "The identity for Hypertext Transfer Protocol version 1.1 (HTTP/1.1) over TLS."; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics draft-ietf-httpbis-messaging-19: HTTP/1.1"; } identity http2 { base application-protocol; description "The identity for Hypertext Transfer Protocol version 2 (HTTP/2)."; reference "draft-ietf-httpbis-http2bis-07: HTTP/2"; } identity https2 { base application-protocol; description "The identity for Hypertext Transfer Protocol version 2 (HTTP/2) over TLS."; reference "draft-ietf-httpbis-http2bis-07: HTTP/2"; } identity ftp { base application-protocol; description "The identity for File Transfer Protocol."; reference Kim, et al. Expires 3 December 2022 [Page 27] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 "RFC 959: File Transfer Protocol (FTP)"; } identity ssh { base application-protocol; description "The identity for Secure Shell (SSH) protocol."; reference "RFC 4250: The Secure Shell (SSH) Protocol"; } identity telnet { base application-protocol; description "The identity for telnet."; reference "RFC 854: Telnet Protocol"; } identity smtp { base application-protocol; description "The identity for Simple Mail Transfer Protocol."; reference "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; } identity pop3 { base application-protocol; description "The identity for Post Office Protocol 3 (POP3)."; reference "RFC 1939: Post Office Protocol - Version 3 (POP3)"; } identity pop3s { base application-protocol; description "The identity for Post Office Protocol 3 (POP3) over TLS"; reference "RFC 1939: Post Office Protocol - Version 3 (POP3) RFC 2595: Using TLS with IMAP, POP3 and ACAP"; } identity imap { base application-protocol; description "The identity for Internet Message Access Protocol (IMAP)."; Kim, et al. Expires 3 December 2022 [Page 28] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 reference "RFC 9051: Internet Message Access Protocol (IMAP) - Version 4rev2"; } identity imaps { base application-protocol; description "The identity for Internet Message Access Protocol (IMAP) over TLS"; reference "RFC 9051: Internet Message Access Protocol (IMAP) - Version 4rev2"; } /* * Typedefs */ typedef time { type string { pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?' + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; } description "The time type represents an instance of time of zero-duration in the specified timezone that recurs every day."; } typedef day { type enumeration { enum monday { description "This represents Monday."; } enum tuesday { description "This represents Tuesday."; } enum wednesday { description "This represents Wednesday"; } enum thursday { description "This represents Thursday."; } enum friday { Kim, et al. Expires 3 December 2022 [Page 29] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 description "This represents Friday."; } enum saturday { description "This represents Saturday."; } enum sunday { description "This represents Sunday."; } } description "The type for representing the day of the week."; } /* * Groupings */ grouping port-range { leaf start { type inet:port-number; description "A start port number for a range match."; } leaf end { type inet:port-number; must '. >= ../start' { error-message "An end port number MUST be equal to or greater than a start port number."; } description "An end port number for a range match."; } description "A range match for port numbers. If only one value is needed, then set both start and end to the same value."; reference "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification - Port Number RFC 768: User Datagram Protocol - Port Number draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission Protocol - Port Number RFC 4340: Datagram Congestion Control Protocol (DCCP) - Port Number"; } Kim, et al. Expires 3 December 2022 [Page 30] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 grouping ipv4-range { description "A range match for IPv4 addresses. If only one value is needed, then set both start and end to the same value. The end IPv4 address MUST be equal to or greater than the start IPv4 address."; leaf start { type inet:ipv4-address-no-zone; description "A start IPv4 address for a range match."; } leaf end { type inet:ipv4-address-no-zone; description "An end IPv4 address for a range match."; } reference "RFC 791: Internet Protocol - IPv4 address"; } grouping ipv6-range { description "A range match for IPv6 addresses. If only one value is needed, then set both start and end to the same value. The end IPv6 address MUST be equal to or greater than the start IPv6 address."; leaf start { type inet:ipv6-address-no-zone; description "A start IPv6 address for a range match."; } leaf end { type inet:ipv6-address-no-zone; description "An end IPv6 address for a range match."; } reference "RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - IPv6 address"; } /* * Data nodes */ list i2nsf-security-policy { Kim, et al. Expires 3 December 2022 [Page 31] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 key "name"; description "Container for security policy including a set of security rules according to certain logic, i.e., their similarity or mutual relations, etc. The network security policy can be applied to both the unidirectional and bidirectional traffic across the NSF. The I2NSF security policies use the Event-Condition-Action (ECA) policy model "; reference "RFC 8329: Framework for Interface to Network Security Functions - I2NSF Flow Security Policy Structure draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Design Principles and ECA Policy Model Overview"; leaf name { type string; description "The name of the security policy. This must be unique."; } leaf language { type string { pattern '((([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})' + '{0,2})?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})?' + '(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}' + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WYZa-wyz]' + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]' + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|' + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-' + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-' + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-' + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]' + '|[Ii]-[Hh][Aa][Kk]|' + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|' + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|' + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|' + '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|' + '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|' + '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-' + '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-' + '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-' + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|' + '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-' Kim, et al. Expires 3 December 2022 [Page 32] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 + '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|' + '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-' + '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-' + '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))'; } default "en-US"; description "The value in this field indicates the language tag used for all of the 'leaf description' described in the 'i2nsf-security-policy'. This field is mandatory only when one or more of the 'leaf description' is used. The attribute is encoded following the rules in Section 2.1 in RFC 5646. The default language tag is 'en-US'"; reference "RFC 5646: Tags for Identifying Languages"; } leaf priority-usage { type identityref { base priority-usage; } default priority-by-order; description "Priority usage type for security policy rule: priority by order and priority by number"; } leaf resolution-strategy { type identityref { base resolution-strategy; } default fmr; description "The resolution strategies that can be used to specify how to resolve conflicts that occur between actions of the same or different policy rules that are matched and contained in this particular NSF"; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Resolution strategy"; } leaf default-action { type identityref { base default-action; } Kim, et al. Expires 3 December 2022 [Page 33] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 default mirror; description "This default action can be used to specify a predefined action when no other alternative action was matched by the currently executing I2NSF Policy Rule. An analogy is the use of a default statement in a C switch statement."; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Default Action"; } list rules { key "name"; description "This is a rule for network security functions."; leaf name { type string; description "The name of the rule."; } leaf description { type string; description "This description gives more information about rules."; } leaf priority { type uint8 { range "1..255"; } description "The priority for the rule comes with a mandatory numeric value which can range from 1 up to 255. Note that a higher number means a higher priority"; } leaf enable { type boolean; description "If true, the rule is enabled and enforced. If false, the rule is configured but disabled and not enforced."; } container long-connection { Kim, et al. Expires 3 December 2022 [Page 34] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 description "A container for long connection. A long connection is a connection that is maintained after the socket connection is established, regardless of whether it is used for data traffic or not."; leaf enable { type boolean; description "If true, the rule is enabled and enforced. If false, the rule is configured but disabled and not enforced."; } leaf duration { when "../enable = 'true'"; type uint32; units "second"; description "This is the maximum inactive connection duration of a long connection before a connection is declared as expired."; } } container event { description "An event is defined as any important occurrence in time of a change in the system being managed, and/or in the environment of the system being managed. When used in the context of policy rules for a flow-based NSF, it is used to determine whether the Condition clause of the Policy Rule can be evaluated or not. Examples of an I2NSF event include time and user actions (e.g., logon, logoff, and actions that violate any ACL.)."; reference "RFC 8329: Framework for Interface to Network Security Functions - I2NSF Flow Security Policy Structure draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Design Principles and ECA Policy Model Overview draft-ietf-i2nsf-nsf-monitoring-data-model-20: I2NSF NSF Monitoring Interface YANG Data Model - Alarms, Events, Logs, and Counters"; leaf description { Kim, et al. Expires 3 December 2022 [Page 35] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 type string; description "Description for an event clause"; } leaf-list system-event { type identityref { base system-event; } description "The security policy rule according to system events."; } leaf-list system-alarm { type identityref { base system-alarm; } description "The security policy rule according to system alarms."; } } container condition { description "A condition is defined as a set of attributes, features, and/or values that are to be compared with a set of known attributes, features, and/or values in order to determine whether the set of Actions in that (imperative) I2NSF Policy Rule can be executed or not. Examples of I2NSF Conditions include matching attributes of a packet or flow, and comparing the internal state of an NSF to a desired state. The condition works with 'AND' logic, where all fields set in a condition MUST match the packet or flow for the condition to be evaluated as 'TRUE'"; reference "RFC 8329: Framework for Interface to Network Security Functions - I2NSF Flow Security Policy Structure draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Design Principles and ECA Policy Model Overview"; leaf description { type string; description Kim, et al. Expires 3 December 2022 [Page 36] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 "Description for a condition clause."; } list layer-2 { key "destination-mac-address source-mac-address ethertype"; description "The purpose of this container is to represent layer 2 packet header information to determine the set of policy actions in this ECA policy rule should be executed or not."; reference "IEEE 802.3: IEEE Standard for Ethernet"; leaf description { type string; description "The ethernet condition description"; } uses packet-fields:acl-eth-header-fields; } choice layer-3 { case ipv4 { container ipv4 { description "The purpose of this container is to represent IPv4 packet header information to determine if the set of policy actions in this ECA policy rule should be executed or not."; reference "RFC 791: Internet Protocol"; leaf description { type string; description "This is description for IPv4 condition."; } uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv4-header-fields { augment destination-network { case destination-ipv4-range { list destination-ipv4-range { key "start end"; uses ipv4-range; description "The list of IPv4 addresses specified with Kim, et al. Expires 3 December 2022 [Page 37] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 a start IPv4 address and an end IPv4 address. If only one value is needed, then set both start and end to the same value. Note that the 'end' IPv4 address MUST be equal to or greater than the 'start' IPv4 address."; } } description "IPv4 destination network denoted as IPv4 addresses"; } augment source-network { case source-ipv4-range { list source-ipv4-range { key "start end"; uses ipv4-range; description "The list of IPv4 addresses specified with a start IPv4 address and an end IPv4 address. If only one value is needed, then set both start and end to the same value. Note that the 'end' IPv4 address MUST be equal or greater than the 'start' IPv4 address."; } } description "IPv4 source network denoted as IPv4 addresses"; } } } } case ipv6 { container ipv6 { description "The purpose of this container is to represent IPv6 packet header information to determine if the set of policy actions in this ECA policy rule should be executed or not."; reference "RFC 8200: Internet Protocol, Version 6 (IPv6) Specification"; leaf description { type string; Kim, et al. Expires 3 December 2022 [Page 38] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 description "This is description for IPv6 condition."; } uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv6-header-fields { augment destination-network { case destination-ipv6-range { list destination-ipv6-range { key "start end"; uses ipv6-range; description "The list of IPv6 addresses specified with a start IPv6 address and an end IPv6 address. If only one value is needed, then set both start and end to the same value. Note that the 'end' IPv6 address MUST be equal to or greater than the 'start' IPv6 address."; } } description "IPv6 destination network denoted as IPv6 addresses"; } augment source-network { case source-ipv6-range { list source-ipv6-range { key "start end"; uses ipv6-range; description "The list of IPv6 addresses specified with a start IPv6 address and an end IPv6 address. If only one value is needed, then set both start and end to the same value. Note that the 'end' IPv6 address MUST be equal to or greater than the 'start' IPv6 address."; } } description "IPv6 source network denoted as IPv6 addresses"; } } } } description Kim, et al. Expires 3 December 2022 [Page 39] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 "Choice of either IPv4 or IPv6 as layer-3 protocol"; } choice layer-4 { case tcp { container tcp { description "The purpose of this container is to represent TCP packet header information to determine if the set of policy actions in this ECA policy rule should be executed or not."; reference "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification"; leaf description { type string; description "This is description for tcp condition."; } container source-port-number { choice source-port { case range-or-operator { uses packet-fields:port-range-or-operator; description "Source port definition from range or operator. Can be used when a single port range to be specified."; } case port-list { list port-numbers { key "start end"; uses port-range; description "List of source port numbers."; } description "Source port definition from list of port numbers. In the case of multiple port ranges needed to be specified."; } description "The choice of source port definition using range/operator or a choice to use list of port numbers."; } Kim, et al. Expires 3 December 2022 [Page 40] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 description "The security policy rule according to tcp source port number."; reference "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification - Port Number"; } container destination-port-number { choice destination-port { case range-or-operator { uses packet-fields:port-range-or-operator; description "Destination port definition from range or operator. Can be used when a single port range to be specified."; } case port-list { list port-numbers { key "start end"; uses port-range; description "List of destination port numbers."; } description "Destination port definition from list of port numbers. In the case of multiple port ranges needed to be specified."; } description "The choice of destination port definition using range/operator or a choice to use list of port numbers."; } description "The security policy rule according to tcp destination port number."; reference "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification - Port Number"; } uses packet-fields:acl-tcp-header-fields; } } Kim, et al. Expires 3 December 2022 [Page 41] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 case udp { container udp { description "The purpose of this container is to represent UDP packet header information to determine if the set of policy actions in this ECA policy rule should be executed or not."; reference "RFC 768: User Datagram Protocol"; leaf description { type string; description "This is description for udp condition."; } container source-port-number { choice source-port { case range-or-operator { uses packet-fields:port-range-or-operator; description "Source port definition from range or operator. Can be used when a single port range to be specified."; } case port-list { list port-numbers { key "start end"; uses port-range; description "List of source port numbers."; } description "Source port definition from list of port numbers. In the case of multiple port ranges needed to be specified."; } description "The choice of source port definition using range/operator or a choice to use list of port numbers."; } description "The security policy rule according to udp source port number."; reference "RFC 768: User Datagram Protocol - Port Number"; } Kim, et al. Expires 3 December 2022 [Page 42] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 container destination-port-number { choice destination-port { case range-or-operator { uses packet-fields:port-range-or-operator; description "Destination port definition from range or operator. Can be used when a single port range to be specified."; } case port-list { list port-numbers { key "start end"; uses port-range; description "List of destination port numbers."; } description "Destination port definition from list of port numbers. In the case of multiple port ranges needed to be specified."; } description "The choice of destination port definition using range/operator or a choice to use list of port numbers."; } description "The security policy rule according to udp destination port number."; reference "RFC 768: User Datagram Protocol - Port Number"; } uses packet-fields:acl-udp-header-fields; } } case sctp { container sctp { description "The purpose of this container is to represent SCTP packet header information to determine if the set of policy actions in this ECA policy rule should be executed or not."; leaf description { Kim, et al. Expires 3 December 2022 [Page 43] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 type string; description "This is description for sctp condition."; } container source-port-number { choice source-port { case range-or-operator { uses packet-fields:port-range-or-operator; description "Source port definition from range or operator. Can be used when a single port range to be specified."; } case port-list { list port-numbers { key "start end"; uses port-range; description "List of source port numbers."; } description "Source port definition from list of port numbers. In the case of multiple port ranges needed to be specified."; } description "The choice of source port definition using range/operator or a choice to use list of port numbers."; } description "The security policy rule according to sctp source port number."; reference "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission Protocol - Port number"; } container destination-port-number { choice destination-port { case range-or-operator { uses packet-fields:port-range-or-operator; description "Destination port definition from range or operator. Can be used when a single port range to be specified."; Kim, et al. Expires 3 December 2022 [Page 44] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 } case port-list { list port-numbers { key "start end"; uses port-range; description "List of destination port numbers."; } description "Destination port definition from list of port numbers. In the case of multiple port ranges needed to be specified."; } description "The choice of destination port definition using range/operator or a choice to use list of port numbers."; } description "The security policy rule according to sctp destination port number."; reference "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission Protocol - Port Number"; } leaf-list chunk-type { type uint8; description "The security policy rule according to sctp chunk type ID Value."; reference "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission Protocol - Chunk Type"; } leaf chunk-length { type uint16 { range "4..max"; } description "The security policy rule according to the length of the chunk in sctp. This value represents the size of the chunk in bytes, including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields."; reference Kim, et al. Expires 3 December 2022 [Page 45] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission Protocol - Chunk Length"; } } } case dccp { container dccp { description "The purpose of this container is to represent DCCP packet header information to determine if the set of policy actions in this ECA policy rule should be executed or not."; leaf description { type string; description "This is description for dccp condition."; } container source-port-number { choice source-port { case range-or-operator { uses packet-fields:port-range-or-operator; description "Source port definition from range or operator. Can be used when a single port range to be specified."; } case port-list { list port-numbers { key "start end"; uses port-range; description "List of source port numbers."; } description "Source port definition from list of port numbers. In the case of multiple port ranges needed to be specified."; } description "The choice of source port definition using range/operator or a choice to use list of port numbers."; } description "The security policy rule according to dccp source port number."; Kim, et al. Expires 3 December 2022 [Page 46] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 reference "RFC 4340: Datagram Congestion Control Protocol (DCCP) - Port number"; } container destination-port-number { choice destination-port { case range-or-operator { uses packet-fields:port-range-or-operator; description "Destination port definition from range or operator. Can be used when a single port range to be specified."; } case port-list { list port-numbers { key "start end"; uses port-range; description "List of destination port numbers."; } description "Destination port definition from list of port numbers. In the case of multiple port ranges needed to be specified."; } description "The choice of destination port definition using range/operator or a choice to use list of port numbers."; } description "The security policy rule according to dccp destination port number."; reference "RFC 4340: Datagram Congestion Control Protocol (DCCP) - Port number"; } leaf-list service-code { type uint32; description "The security policy rule according to dccp service code."; reference "RFC 4340: Datagram Congestion Control Protocol (DCCP) - Service Codes Kim, et al. Expires 3 December 2022 [Page 47] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 RFC 5595: The Datagram Congestion Control Protocol (DCCP) Service Codes RFC 6335: Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry - Service Code"; } leaf-list type { type uint8 { range "0..15"; } description "The security policy rule according to the 4 bits of dccp type header field for dccp packet types such as DCCP-Request, DCCP-Response, DCCP-Data, DCCP-Ack, and DCCP-DataAck."; reference "RFC 4340: Datagram Congestion Control Protocol (DCCP) - Packet Types"; } leaf data-offset { type uint8; description "The security policy rule according to the offset from the start of the packet's DCCP header to the start of its application data area, in 32-bit word."; reference "RFC 4340: Datagram Congestion Control Protocol (DCCP) - Data Offset"; } } } case icmp { container icmp { description "The purpose of this container is to represent ICMPv4 and ICMPv6 packet header information to determine if the set of policy actions in this ECA policy rule should be executed or not."; reference "RFC 792: Internet Control Message Protocol RFC 8335: PROBE: A Utility for Probing Interfaces"; leaf description { type string; Kim, et al. Expires 3 December 2022 [Page 48] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 description "This is description for icmp condition."; } leaf version { type enumeration { enum icmpv4 { value "1"; description "The ICMPv4 Protocol as defined in RFC 792"; } enum icmpv6 { value "2"; description "The ICMPv6 Protocol as defined in RFC 4443"; } } description "The ICMP version to be matched. This value affected the type and code values."; reference "RFC 792: Internet Control Message Protocol RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"; } uses packet-fields:acl-icmp-header-fields; } } description "Choice of TCP, UDP, SCTP, DCCP, and ICMP as a layer-4 protocol."; } container url-category { description "Condition for url category"; leaf description { type string; description "This is description for the condition of a URL's category such as SNS sites, game sites, ecommerce sites, company sites, and university sites."; } leaf-list pre-defined { type string; Kim, et al. Expires 3 December 2022 [Page 49] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 description "This is pre-defined-category. To specify the name of URL database."; } leaf-list user-defined { type string; description "This user-defined-category. To allow a user's manual addition of URLs for URL filtering."; reference "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax"; } } container voice { description "For the VoIP/VoCN security system, a VoIP/ VoCN security system can monitor each VoIP/VoCN flow and manage VoIP/VoCN security rules controlled by a centralized server for VoIP/VoCN security service (called VoIP IPS). The VoIP/VoCN security system controls each switch for the VoIP/VoCN call flow management by manipulating the rules that can be added, deleted, or modified dynamically."; reference "RFC 3261: SIP: Session Initiation Protocol"; leaf description { type string; description "This is description for voice condition."; } leaf-list source-voice-id { type string; description "The security policy rule according to a source voice ID for VoIP and VoCN."; } leaf-list destination-voice-id { type string; description "The security policy rule according to a destination voice ID for VoIP and VoCN."; Kim, et al. Expires 3 December 2022 [Page 50] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 } leaf-list user-agent { type string; description "The security policy rule according to a user agent for VoIP and VoCN."; } } container ddos { description "Condition for DDoS attack."; leaf description { type string; description "This is description for ddos condition."; } leaf alert-packet-rate { type uint32; units "pps"; description "The alert rate of flood detection for packets per second (PPS) of an IP address. If the PPS of an IP address exceeds the alert rate threshold, an alert will be generated."; } leaf alert-flow-rate { type uint32; description "The alert rate of flood detection for the flow creating requests (e.g., new TCP connection establishment) per second of an IP address as either a source node or a destination node. If the flows per second of an IP address exceeds the alert rate threshold, an alert will be generated."; } leaf alert-byte-rate { type uint32; units "Bps"; description "The alert rate of flood detection for Kim, et al. Expires 3 December 2022 [Page 51] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 bytes per second (Bps) of an IP address. If the bytes per second of an IP address exceeds the alert rate threshold, an alert will be generated."; } } container anti-virus { description "Condition for antivirus"; leaf-list profile { type string; description "The security profile for antivirus. This is used to update the security profile for improving the security. The security profile is used to scan the viruses."; } leaf-list exception-files { type string; description "The type or name of the files to be excluded by the antivirus. This can be used to keep the known harmless files. Absolute paths are filenames/paths to be excluded and relative ones are interpreted as globs."; reference "GLOB: Linux Programmer's Manual - GLOB"; } } container payload { description "Condition for packet payload"; leaf description { type string; description "This is description for payload condition."; } leaf-list content { type binary; description "This is a condition for packet payload content. The payload content is the binary stream contained by a security attack such as backdoor attack. It is usually used for Deep Packet Inspection (DPI)."; Kim, et al. Expires 3 December 2022 [Page 52] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 } } container context { description "Condition for context"; leaf description { type string; description "This is description for context condition."; } container time { description "Time to determine when the policy should be applied"; leaf start-date-time { type yang:date-and-time; description "This is the start date and time for a security policy rule."; } leaf end-date-time { type yang:date-and-time; description "This is the end date and time for a policy rule. The policy rule will stop working after the specified end-date-time."; } container period { when "../frequency!='only-once'"; description "This represents the repetition time. In the case where the frequency is weekly, the days can be set."; leaf start-time { type time; description "This is a period's start time for an event."; } leaf end-time { type time; description "This is a period's end time for an event."; } leaf-list day { Kim, et al. Expires 3 December 2022 [Page 53] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 when "../../frequency='weekly'"; type day; min-elements 1; description "This represents the repeated day of every week (e.g., Monday and Tuesday). More than one day can be specified."; } leaf-list date { when "../../frequency='monthly'"; type int8 { range "1..31"; } min-elements 1; description "This represents the repeated date of every month. More than one date can be specified."; } leaf-list month { when "../../frequency='yearly'"; type string{ pattern '\d{2}-\d{2}'; } min-elements 1; description "This represents the repeated date and month of every year. More than one can be specified. A pattern used here is Month and Date (MM-DD)."; } } leaf frequency { type enumeration { enum only-once { description "This represents that the rule is immediately enforced only once and not repeated. The policy will continuously be active from the start-time to the end-time."; } enum daily { description "This represents that the rule is enforced on a daily basis. The policy will be repeated daily until the end-date."; Kim, et al. Expires 3 December 2022 [Page 54] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 } enum weekly { description "This represents that the rule is enforced on a weekly basis. The policy will be repeated weekly until the end-date. The repeated days can be specified."; } enum monthly { description "This represents that the rule is enforced on a monthly basis. The policy will be repeated monthly until the end-date."; } enum yearly { description "This represents that the rule is enforced on a yearly basis. The policy will be repeated yearly until the end-date."; } } default only-once; description "This represents how frequently the rule should be enforced."; } } container application { description "Condition for application"; leaf description { type string; description "This is description for application condition."; } leaf-list protocol { type identityref { base application-protocol; } description "The condition based on the application layer protocol"; } } container device-type { description Kim, et al. Expires 3 December 2022 [Page 55] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 "Condition for type of the destination device"; leaf description { type string; description "This is description for destination device type condition. Vendors can write instructions for the condition that vendor made"; } leaf-list device { type identityref { base device-type; } description "The device attribute that can identify a device, including the device type (i.e., router, switch, pc, ios, or android) and the device's owner as well."; } } container users { description "Condition for users"; leaf description { type string; description "This is the description for users' condition."; } list user { key "id"; description "The user with which the traffic flow is associated can be identified by either a user ID or username. The user-to-IP address mapping is assumed to be provided by the unified user management system via network."; leaf id { type uint32; description "The ID of the user."; } leaf name { type string; description "The name of the user."; } } Kim, et al. Expires 3 December 2022 [Page 56] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 list group { key "id"; description "The user group with which the traffic flow is associated can be identified by either a group ID or group name. The group-to-IP address and user-to-group mappings are assumed to be provided by the unified user management system via network."; leaf id { type uint32; description "The ID of the group."; } leaf name { type string; description "The name of the group."; } } } container geographic-location { description "The location which network traffic flow is associated with. The region can be the geographic location such as country, province, and city, as well as the logical network location such as IP address, network section, and network domain."; reference "RFC 9179: A YANG Grouping for Geographic Locations"; leaf description { type string; description "This is the description for the geographic location condition. It is used to describe the conditions and instructions that should be implemented."; } leaf-list source { type string; description "The source is a geographic location mapped into an IP address. It matches the mapped IP address to the source IP address of the traffic flow."; reference "ISO 3166: Codes for the representation of names of countries and their subdivisions Kim, et al. Expires 3 December 2022 [Page 57] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 RFC 9179: A YANG Grouping for Geographic Locations"; } leaf-list destination { type string; description "The destination is a geographic location mapped into an IP address. It matches the mapped IP address to the destination IP address of the traffic flow."; reference "ISO 3166: Codes for the representation of names of countries and their subdivisions RFC 9179: A YANG Grouping for Geographic Locations"; } } } } container action { description "An action is used to control and monitor aspects of flow-based NSFs when the event and condition clauses are satisfied. NSFs provide security functions by executing various Actions. Examples of I2NSF Actions include providing intrusion detection and/or protection, web and flow filtering, and deep packet inspection for packets and flows."; reference "RFC 8329: Framework for Interface to Network Security Functions - I2NSF Flow Security Policy Structure draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Design Principles and ECA Policy Model Overview"; leaf description { type string; description "Description for an action clause."; } container packet-action { description "Action for packets"; reference "RFC 8329: Framework for Interface to Network Security Functions - I2NSF Flow Security Policy Structure draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Design Principles and Kim, et al. Expires 3 December 2022 [Page 58] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 ECA Policy Model Overview"; leaf ingress-action { type identityref { base ingress-action; } description "Ingress Action: pass, drop, reject, rate-limit, and mirror."; } leaf egress-action { type identityref { base egress-action; } description "Egress action: pass, drop, reject, rate-limit, mirror, invoke-signaling, tunnel-encapsulation, forwarding, redirection, and transformation."; } leaf log-action { type identityref { base log-action; } description "Log action: rule log and session log"; } } container flow-action { description "Action for flows"; reference "RFC 8329: Framework for Interface to Network Security Functions - I2NSF Flow Security Policy Structure draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - Design Principles and ECA Policy Model Overview"; leaf ingress-action { type identityref { base ingress-action; } description "Action: pass, drop, reject, rate-limit, and mirror."; } Kim, et al. Expires 3 December 2022 [Page 59] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 leaf egress-action { type identityref { base egress-action; } description "Egress action: pass, drop, reject, rate-limit, mirror, invoke-signaling, tunnel-encapsulation, forwarding, redirection, and transformation."; } leaf log-action { type identityref { base log-action; } description "Log action: rule log and session log"; } } container advanced-action { description "If the packet needs to be additionally inspected, the packet is passed to advanced network security functions according to the profile. The profile means the types of NSFs where the packet will be forwarded in order to additionally inspect the packet. The advanced action activates Service Function Chaining (SFC) for further inspection of a packet."; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - YANG Tree Diagram"; leaf-list content-security-control { type identityref { base content-security-control; } description "Content-security-control is the NSFs that inspect the payload of the packet. The profile for the types of NSFs for mitigation is divided into content security control and attack-mitigation-control. Content security control: ips, url filtering, antivirus, and voip-vocn-filter. This can be extended according to the provided NSFs."; reference Kim, et al. Expires 3 December 2022 [Page 60] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - YANG Tree Diagram"; } leaf-list attack-mitigation-control { type identityref { base attack-mitigation-control; } description "Attack-mitigation-control is the NSFs that weaken the attacks related to a denial-of-service (DoS) and reconnaissance. The profile for the types of NSFs for mitigation is divided into content security control and attack-mitigation-control. Attack mitigation control: Anti-DDoS or DDoS mitigator. This can be extended according to the provided NSFs such as mitigators for ip sweep, port scanning, ping of death, teardrop, oversized icmp, and tracert."; reference "draft-ietf-i2nsf-capability-data-model-32: I2NSF Capability YANG Data Model - YANG Tree Diagram"; } } } } container rule-group { description "This is rule group"; list groups { key "group-name"; description "This is a group for rules"; leaf group-name { type string; description "This is the name of the group for rules"; } leaf-list rule-name { type leafref { path "../../../rules/name"; } description Kim, et al. Expires 3 December 2022 [Page 61] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 "The names of the rules to be grouped."; } leaf enable { type boolean; description "If true, the rule is enabled and enforced. If false, the rule is configured but disabled and not enforced."; } leaf description { type string; description "This is a description for rule-group"; } } } } } Figure 5: YANG Data Module of I2NSF NSF-Facing-Interface 5. XML Configuration Examples of Low-Level Security Policy Rules This section shows XML configuration examples of low-level security policy rules that are delivered from the Security Controller to NSFs over the NSF-Facing Interface. For security requirements, we assume that the NSFs (i.e., General firewall, Time-based firewall, URL filter, VoIP/VoCN filter, and HTTP and HTTPS flood mitigation) described in Appendix A of [I-D.ietf-i2nsf-capability-data-model] are registered with the I2NSF framework. With the registered NSFs, we show configuration examples for security policy rules of network security functions according to the following three security requirements: (i) Block Social Networking Service (SNS) access during business hours, (ii) Block malicious VoIP/VoCN packets coming to the company, and (iii) Mitigate HTTP and HTTPS flood attacks on company web server. 5.1. Example Security Requirement 1: Block Social Networking Service (SNS) Access during Business Hours This section shows a configuration example for blocking SNS access during business hours in IPv4 networks or IPv6 networks. Kim, et al. Expires 3 December 2022 [Page 62] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 sns_access block_sns_access_during_operation_time_for_ipv4 192.0.2.0/24 url-filtering Figure 6: Configuration XML for Time-based Firewall to Block SNS Access during Business Hours in IPv4 Networks Kim, et al. Expires 3 December 2022 [Page 63] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 sns_access block_sns_access_during_operation_time_for_ipv6 2001:db8:1::/60 url-filtering Figure 7: Configuration XML for Time-based Firewall to Block SNS Access during Business Hours in IPv6 Networks Kim, et al. Expires 3 December 2022 [Page 64] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 sns_access block_sns_access_during_operation_time SNS_1 SNS_2 drop Figure 8: Configuration XML for Web Filter to Block SNS Access during Business Hours Figure 6 and Figure 7 show the configuration XML documents for a time-based firewall for IPv4 and IPv6, respectively. Figure 8 shows the configuration XML document for a web filter. The two NSFs combined to block SNS access during business hours in IPv4 networks (or IPv6 networks). For the security requirement, two NSFs (i.e., a time-based firewall and a web filter) were used because one NSF cannot meet the security requirement. The instances of XML documents for the time-based firewall and the web filter are as follows: Note that a detailed data model for the configuration of the advanced network security function (i.e., web filter) can be defined as an extension in future. Time-based Firewall is as follows: 1. The name of the security policy is sns_access. 2. The name of the rule is block_sns_access_during_operation_time_for_ipv4 and block_sns_access_during_operation_time_for_ipv6. 3. The rule is started from 2021-03-11 at 9 a.m. to 2021-12-31 at 6 p.m. 4. The rule is operated weekly every weekday (i.e., Monday, Tuesday, Wednesday, Thursday, and Friday) during the business hours (i.e., from 9 a.m. to 6 p.m.). Kim, et al. Expires 3 December 2022 [Page 65] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 5. The rule inspects a source IPv4 address (i.e., 192.0.2.0/24). For the case of IPv6 networks, the rule inspects a source IPv6 address (i.e., from 2001:db8:1::/60). 6. If the outgoing packets match the rules above, the time-based firewall sends the packets to url filtering for additional inspection because the time-based firewall can not inspect contents of the packets for the SNS URL. Web Filter is as follows: 1. The name of the security policy is sns_access. 2. The name of the rule is block_SNS_1_and_SNS_2. 3. The rule inspects URL address to block the access packets to the SNS_1 or the SNS_2. 4. If the outgoing packets match the rules above, the packets are blocked. 5.2. Example Security Requirement 2: Block Malicious VoIP/VoCN Packets Coming to a Company This section shows a configuration example for blocking malicious VoIP/VoCN packets coming to a company. Kim, et al. Expires 3 December 2022 [Page 66] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 voip_vocn_inspection block_malicious_voice_id 192.0.2.0/24 5060 5061 voip-vocn-filtering Figure 9: Configuration XML for General Firewall to Block Malicious VoIP/VoCN Packets Coming to a Company Kim, et al. Expires 3 December 2022 [Page 67] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 voip_vocn_inspection block_malicious_voice_id user1@voip.malicious.example.com user2@voip.malicious.example.com drop Figure 10: Configuration XML for VoIP/VoCN Filter to Block Malicious VoIP/VoCN Packets Coming to a Company Figure 9 and Figure 10 show the configuration XML documents for general firewall and VoIP/VoCN filter to block malicious VoIP/VoCN packets coming to a company. For the security requirement, two NSFs (i.e., a general firewall and a VoIP/VoCN filter) were used because one NSF can not meet the security requirement. The instances of XML documents for the general firewall and the VoIP/VoCN filter are as follows: Note that a detailed data model for the configuration of the advanced network security function (i.e., VoIP/VoCN filter) can be described as an extension in future. General Firewall is as follows: 1. The name of the security policy is voip_vocn_inspection. 2. The name of the rule is block_malicious_voice_id. 3. The rule inspects a destination IPv4 address (i.e., from 192.0.2.0/24). 4. The rule inspects a port number (i.e., 5060 and 5061) to inspect VoIP/VoCN packet. Kim, et al. Expires 3 December 2022 [Page 68] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 5. If the incoming packets match the rules above, the general firewall sends the packets to VoIP/VoCN filter for additional inspection because the general firewall can not inspect contents of the VoIP/VoCN packets. VoIP/VoCN Filter is as follows: 1. The name of the security policy is malicious_voice_id. 2. The name of the rule is block_malicious_voice_id. 3. The rule inspects the voice ID of the VoIP/VoCN packets to block the malicious VoIP/VoCN packets (i.e., user1@voip.malicious.example.com and user2@voip.malicious.example.com). 4. If the incoming packets match the rules above, the packets are blocked. 5.3. Example Security Requirement 3: Mitigate HTTP and HTTPS Flood Attacks on a Company Web Server This section shows a configuration example for mitigating HTTP and HTTPS flood attacks on a company web server. Kim, et al. Expires 3 December 2022 [Page 69] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 flood_attack_mitigation mitigate_http_and_https_flood_attack 192.0.2.0/24 80 80 443 443 anti-ddos Figure 11: Configuration XML for General Firewall to Mitigate HTTP and HTTPS Flood Attacks on a Company Web Server Kim, et al. Expires 3 December 2022 [Page 70] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 flood_attack_mitigation mitigate_http_and_https_flood_attack 1000 drop Figure 12: Configuration XML for Anti-DDoS to Mitigate HTTP and HTTPS Flood Attacks on a Company Web Server Figure 11 and Figure 12 show the configuration XML documents for general firewall and HTTP and HTTPS flood attack mitigation to mitigate HTTP and HTTPS flood attacks on a company web server. For the security requirement, two NSFs (i.e., a general firewall and a HTTP and HTTPS flood attack mitigation) were used because one NSF can not meet the security requirement. The instances of XML documents for the general firewall and HTTP and HTTPS flood attack mitigation are as follows: Note that a detailed data model for the configuration of the advanced network security function (i.e., HTTP and HTTPS flood attack mitigation) can be defined as an extension in future. General Firewall is as follows: 1. The name of the security policy is flood_attack_mitigation. 2. The name of the rule is mitigate_http_and_https_flood_attack. 3. The rule inspects a destination IPv4 address (i.e., 192.0.2.0/24) to inspect the access packets coming into the company web server. 4. The rule inspects a port number (i.e., 80 and 443) to inspect HTTP and HTTPS packet. 5. If the packets match the rules above, the general firewall sends the packets to anti-DDoS for additional inspection because the general firewall can not control the amount of packets for HTTP and HTTPS packets. Kim, et al. Expires 3 December 2022 [Page 71] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 Anti DDoS for HTTP and HTTPS Flood Attack Mitigation is as follows: 1. The name of the security policy is flood_attack_mitigation. 2. The name of the rule is mitigate_http_and_https_flood_attack. 3. The rule controls the HTTTP and HTTPS packets according to the amount of incoming packets (1000 packets per second). 4. If the incoming packets match the rules above, the packets are blocked. 6. IANA Considerations This document requests IANA to register the following URI in the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-facing-interface Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950][RFC8525]: name: ietf-i2nsf-nsf-facing-interface namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-facing-interface prefix: i2nsfnfi reference: RFC XXXX 7. Security Considerations The YANG module specified in this document defines a data schema designed to be accessed through network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the required secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the required secure transport is TLS [RFC8446]. The NETCONF access control model [RFC8341] provides a means of restricting access to specific NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable Kim, et al. Expires 3 December 2022 [Page 72] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: * ietf-i2nsf-nsf-facing-interface: Writing to almost any element of this YANG module would directly impact on the configuration of NSFs, e.g., completely turning off security monitoring and mitigation capabilities; altering the scope of this monitoring and mitigation; creating an overwhelming logging volume to overwhelm downstream analytics or storage capacity; creating logging patterns which are confusing; or rendering useless trained statistics or artificial intelligence models. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: * ietf-i2nsf-nsf-facing-interface: The attacker may gather the security policy information of any target NSFs and misuse the security policy information for subsequent attacks. Policy rules identifying the specified users and user groups can be specified with "rules/condition/context/users". As with other data in this YANG module, this user information is provided by the Security Controller to the NSFs and is protected via the transport and access control mechanisms described above. 8. References 8.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . Kim, et al. Expires 3 December 2022 [Page 73] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1983, . [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, . [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, . [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, DOI 10.17487/RFC2595, June 1999, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, . Kim, et al. Expires 3 December 2022 [Page 74] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, September 2009, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . Kim, et al. Expires 3 December 2022 [Page 75] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)", RFC 8075, DOI 10.17487/RFC8075, February 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, . [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. Boucadair, "PROBE: A Utility for Probing Interfaces", RFC 8335, DOI 10.17487/RFC8335, February 2018, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . Kim, et al. Expires 3 December 2022 [Page 76] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, DOI 10.17487/RFC8519, March 2019, . [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, "YANG Library", RFC 8525, DOI 10.17487/RFC8525, March 2019, . [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message Access Protocol (IMAP) - Version 4rev2", RFC 9051, DOI 10.17487/RFC9051, August 2021, . [I-D.ietf-httpbis-http2bis] Thomson, M. and C. Benfield, "HTTP/2", Work in Progress, Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January 2022, . [I-D.ietf-httpbis-messaging] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- httpbis-messaging-19, 12 September 2021, . [I-D.ietf-httpbis-semantics] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Semantics", Work in Progress, Internet-Draft, draft-ietf- httpbis-semantics-19, 12 September 2021, . Kim, et al. Expires 3 December 2022 [Page 77] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 [I-D.ietf-i2nsf-capability-data-model] Hares, S., Jeong, J. P., Kim, J. T., Moskowitz, R., and Q. Lin, "I2NSF Capability YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-i2nsf-capability-data-model-32, 23 May 2022, . [I-D.ietf-i2nsf-nsf-monitoring-data-model] Jeong, J. P., Lingga, P., Hares, S., Xia, L. F., and H. Birkholz, "I2NSF NSF Monitoring Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf- i2nsf-nsf-monitoring-data-model-19, 23 May 2022, . [I-D.ietf-tcpm-rfc793bis] Eddy, W. M., "Transmission Control Protocol (TCP) Specification", Work in Progress, Internet-Draft, draft- ietf-tcpm-rfc793bis-28, 7 March 2022, . [I-D.ietf-tsvwg-rfc4960-bis] Stewart, R. R., Tüxen, M., and K. E. E. Nielsen, "Stream Control Transmission Protocol", Work in Progress, Internet-Draft, draft-ietf-tsvwg-rfc4960-bis-19, 5 February 2022, . 8.2. Informative References [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, . [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9179] Hopps, C., "A YANG Grouping for Geographic Locations", RFC 9179, DOI 10.17487/RFC9179, February 2022, . Kim, et al. Expires 3 December 2022 [Page 78] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 [I-D.ietf-i2nsf-consumer-facing-interface-dm] Jeong, J. P., Chung, C., Ahn, T., Kumar, R., and S. Hares, "I2NSF Consumer-Facing Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-i2nsf-consumer- facing-interface-dm-20, 23 May 2022, . [GLOB] "Linux Programmer's Manual - GLOB", 13 August 2020, . [ISO-3166] "Codes for the representation of names of countries and their subdivisions", ISO 3166, September 2018, . [IEEE-802.3] Institute of Electrical and Electronics Engineers, "IEEE Standard for Ethernet", 2018, . Appendix A. Acknowledgments This document is a product by the I2NSF Working Group (WG) including WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This document took advantage of the review and comments from the following people: Roman Danyliw, Acee Lindem, Dan Romascanu (GenART), Yoshifumi Nishida (TSVART), Kyle Rose (SecDir), Joe Clarke (OpsDir), and Tom Petch. The authors sincerely appreciate their sincere efforts and kind help. This work was supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based Security Intelligence Technology Development for the Customized Security Service Provisioning). This work was supported in part by the IITP (2020-0-00395, Standard Development of Blockchain based Network Management Automation Technology). Appendix B. Contributors The following are co-authors of this document: Patrick Lingga - Department of Electrical and Computer Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 16419, Republic of Korea, EMail: patricklink@skku.edu Kim, et al. Expires 3 December 2022 [Page 79] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 Hyoungshick Kim - Department of Computer Science and Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 16419, Republic of Korea, EMail: hyoung@skku.edu Daeyoung Hyun - Department of Computer Science and Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 16419, Republic of Korea, EMail: dyhyun@skku.edu Dongjin Hong - Department of Electronic, Electrical and Computer Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 16419, Republic of Korea, EMail: dong.jin@skku.edu Liang Xia - Huawei, 101 Software Avenue, Nanjing, Jiangsu 210012, China, EMail: Frank.Xialiang@huawei.com Tae-Jin Ahn - Korea Telecom, 70 Yuseong-Ro, Yuseong-Gu, Daejeon, 305-811, Republic of Korea, EMail: taejin.ahn@kt.com Se-Hui Lee - Korea Telecom, 70 Yuseong-Ro, Yuseong-Gu, Daejeon, 305-811, Republic of Korea, EMail: sehuilee@kt.com Appendix C. Changes from draft-ietf-i2nsf-nsf-facing-interface-dm-28 The following changes are made from draft-ietf-i2nsf-nsf-facing- interface-dm-28: * This version updated a 'leaf language' pattern by adding extra parentheses around "[A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za- z]{3}){0,2})?" and removing a range character '-' between characters 'Y' and 'Z' in "|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WY-Za- wy-z]" as 'Y' is alphabetically adjacent to 'Z'. Authors' Addresses Jinyong Tim Kim (editor) Department of Electronic, Electrical and Computer Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419 Republic of Korea Phone: +82 10 8273 0930 Email: timkim@skku.edu Kim, et al. Expires 3 December 2022 [Page 80] Internet-Draft NSF-Facing Interface YANG Data Model June 2022 Jaehoon Paul Jeong (editor) Department of Computer Science and Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4957 Email: pauljeong@skku.edu URI: http://iotlab.skku.edu/people-jaehoon-jeong.php Jung-Soo Park Electronics and Telecommunications Research Institute 218 Gajeong-Ro, Yuseong-Gu Daejeon 34129 Republic of Korea Phone: +82 42 860 6514 Email: pjs@etri.re.kr Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 United States of America Phone: +1-734-604-0332 Email: shares@ndzh.com Qiushi Lin Huawei Huawei Industrial Base Shenzhen Guangdong 518129, China Email: linqiushi@huawei.com Kim, et al. Expires 3 December 2022 [Page 81] ./draft-ietf-ipsecme-mib-iptfs-11.txt0000644000764400076440000012541214324527544017202 0ustar iustiniustin Network Working Group D. Fedyk Internet-Draft E. Kinzie Intended status: Standards Track LabN Consulting, L.L.C. Expires: 24 April 2023 21 October 2022 Definitions of Managed Objects for IP Traffic Flow Security draft-ietf-ipsecme-mib-iptfs-11 Abstract This document describes managed objects for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. This document provides a read only version of the objects defined in the YANG module for the same purpose. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Fedyk & Kinzie Expires 24 April 2023 [Page 1] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology & Concepts . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Management Objects . . . . . . . . . . . . . . . . . . . . . 3 4.1. MIB Tree . . . . . . . . . . . . . . . . . . . . . . . . 3 4.2. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. Traffic Flow Security (IP-TFS) extensions as defined in [I-D.ietf-ipsecme-iptfs] are enhancements to an IPsec tunnel Security Association to provide improved traffic confidentiality. For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580]. The objects defined here are the same as [I-D.ietf-ipsecme-yang-iptfs] with the exception that only operational or state data is supported. By making operational data accessible via SNMP existing network management systems can monitor IP-TFS. This data is listed in the MIB tree in Section 4.1. This module uses the YANG model as a reference point for managed objects. Note an IETF MIB model for IPsec was never standardized however the structures here could be adapted to existing proprietary MIB implementations where SNMP is used to manage networks. Fedyk & Kinzie Expires 24 April 2023 [Page 2] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 2. Terminology & Concepts The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Overview This document defines the MIB for access to operational parameters of IP traffic flow security (IP-TFS). IP-TFS, defined in [I-D.ietf-ipsecme-iptfs], configures a security association for tunnel mode IPsec with characteristics that improve traffic confidentiality and reduce bandwidth efficiency loss. This document is based on the concepts and management model defined in [I-D.ietf-ipsecme-yang-iptfs]. This document assumes familiarity with IP security concepts described in [RFC4301], IP-TFS as described in [I-D.ietf-ipsecme-iptfs] and the IP-TFS management model described in [I-D.ietf-ipsecme-yang-iptfs]. This document specifies an extensible operational model for IP-TFS. It reuses the management model defined in [I-D.ietf-ipsecme-yang-iptfs]. It allows SNMP systems to read operational objects (which includes configured objects) from IP-TFS. 4. Management Objects 4.1. MIB Tree The following is the MIB registration tree diagram for the IP-TFS extensions. # IP-TRAFFIC-FLOW-SECURITY-MIB registration tree --iptfsMIB(1.3.6.1.2.1.500) +--iptfsMIBObjects(1) | +--iptfsGroup(1) | | +--iptfsConfigTable(1) | | +--iptfsConfigTableEntry(1) [iptfsConfigSaIndex] | | | | | +-- --- Integer32 iptfsConfigSaIndex(1) | | +-- r-n TruthValue congestionControl(2) | | +-- r-n TruthValue usePathMtuDiscovery(3) | | +-- r-n UnsignedShort outerPacketSize(4) | | +-- r-n CounterBasedGauge64 l2FixedRate(5) | | +-- r-n CounterBasedGauge64 l3FixedRate(6) Fedyk & Kinzie Expires 24 April 2023 [Page 3] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 | | +-- r-n TruthValue dontFragment(7) | | +-- r-n NanoSeconds maxAggregationTime(8) | | +-- r-n UnsignedShort windowSize(9) | | +-- r-n TruthValue sendImmediately(10) | | +-- r-n NanoSeconds lostPacketTimerInterval(11) | +--ipsecStatsGroup(2) | | +--ipsecStatsTable(1) | | +--ipsecStatsTableEntry(1) [ipsecSaIndex] | | +-- --- Integer32 ipsecSaIndex(1) | | +-- r-n Counter64 txPkts(2) | | +-- r-n Counter64 txOctets(3) | | +-- r-n Counter64 txDropPkts(4) | | +-- r-n Counter64 rxPkts(5) | | +-- r-n Counter64 rxOctets(6) | | +-- r-n Counter64 rxDropPkts(7) | +--iptfsInnerStatsGroup(3) | | +--iptfsInnerStatsTable(1) | | +--iptfsInnerStatsTableEntry(1) [iptfsInnerSaIndex] | | +-- --- Integer32 iptfsInnerSaIndex(1) | | +-- r-n Counter64 txInnerPkts(2) | | +-- r-n Counter64 txInnerOctets(3) | | +-- r-n Counter64 rxInnerPkts(4) | | +-- r-n Counter64 rxInnerOctets(5) | | +-- r-n Counter64 rxIncompleteInnerPkts(6) | +--iptfsOuterStatsGroup(4) | +--iptfsOuterStatsTable(1) | +--iptfsOuterStatsTableEntry(1) [iptfsSaIndex] | +-- --- Integer32 iptfsSaIndex(1) | +-- r-n Counter64 txExtraPadPkts(2) | +-- r-n Counter64 txExtraPadOctets(3) | +-- r-n Counter64 txAllPadPkts(4) | +-- r-n Counter64 txAllPadOctets(5) | +-- r-n Counter64 rxExtraPadPkts(6) | +-- r-n Counter64 rxExtraPadOctets(7) | +-- r-n Counter64 rxAllPadPkts(8) | +-- r-n Counter64 rxAllPadOctets(9) | +-- r-n Counter64 rxErroredPkts(10) | +-- r-n Counter64 rxMissedPkts(11) +--iptfsMIBConformance(2) +--iptfsMIBConformances(1) | +--iptfsMIBCompliance(1) +--iptfsMIBGroups(2) +--iptfsMIBConfGroup(1) +--ipsecStatsConfGroup(2) +--iptfsInnerStatsConfGroup(3) +--iptfsOuterStatsConfGroup(4) Fedyk & Kinzie Expires 24 April 2023 [Page 4] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 4.2. SNMP The following is the MIB for IP-TFS. The Congestion control algorithm in [RFC5348] is referenced in the MIB text. file "iptfs-mib.mib" =--> -- *---------------------------------------------------------------- -- * IP-TRAFFIC-FLOW-SECURITY-MIB Module -- *---------------------------------------------------------------- IP-TRAFFIC-FLOW-SECURITY-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, Counter64, mib-2 FROM SNMPv2-SMI CounterBasedGauge64 FROM HCNUM-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, TruthValue FROM SNMPv2-TC; iptfsMIB MODULE-IDENTITY LAST-UPDATED "202210210000Z" ORGANIZATION "IETF IPsecme Working Group" CONTACT-INFO " Author: Don Fedyk Author: Eric Kinzie " -- RFC Ed.: replace XXXX with actual RFC number, update mib-2 -- entry and remove this note. DESCRIPTION "This module defines the configuration and operational state for managing the IP Traffic Flow Security functionality [RFC XXXX]. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, Fedyk & Kinzie Expires 24 April 2023 [Page 5] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this SNMP MIB module is part of RFC XXXX (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for full legal notices." REVISION "202210210000Z" DESCRIPTION "Initial revision. Derived from the IP-TFS Yang Model." ::= { mib-2 500} -- -- Textual Conventions -- UnsignedShort ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "xs:unsignedShort" SYNTAX Unsigned32 (0 .. 65535) NanoSeconds ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-6" STATUS current DESCRIPTION "Represents time unit value in nanoseconds." SYNTAX Integer32 -- Objects, Notifications & Conformances iptfsMIBObjects OBJECT IDENTIFIER ::= { iptfsMIB 1 } iptfsMIBConformance OBJECT IDENTIFIER ::= { iptfsMIB 2} -- -- IP-TFS MIB Object Groups -- iptfsGroup OBJECT IDENTIFIER ::= { iptfsMIBObjects 1 } ipsecStatsGroup OBJECT IDENTIFIER ::= { iptfsMIBObjects 2 } Fedyk & Kinzie Expires 24 April 2023 [Page 6] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 iptfsInnerStatsGroup OBJECT IDENTIFIER ::= { iptfsMIBObjects 3 } iptfsOuterStatsGroup OBJECT IDENTIFIER ::= { iptfsMIBObjects 4 } iptfsConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF IptfsConfigTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing configuration information for IP-TFS." ::= { iptfsGroup 1 } iptfsConfigTableEntry OBJECT-TYPE SYNTAX IptfsConfigTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular IP-TFS SA." INDEX { iptfsConfigSaIndex } ::= { iptfsConfigTable 1 } IptfsConfigTableEntry ::= SEQUENCE { iptfsConfigSaIndex Integer32, -- identifier information congestionControl TruthValue, usePathMtuDiscovery TruthValue, outerPacketSize UnsignedShort, l2FixedRate CounterBasedGauge64, l3FixedRate CounterBasedGauge64, dontFragment TruthValue, maxAggregationTime NanoSeconds, windowSize UnsignedShort, sendImmediately TruthValue, lostPacketTimerInterval NanoSeconds } iptfsConfigSaIndex OBJECT-TYPE SYNTAX Integer32 (1..16777215) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, greater than zero, for each SA. It is recommended that values are assigned contiguously Fedyk & Kinzie Expires 24 April 2023 [Page 7] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 starting from 1. The value for each entry must remain constant at least from one re-initialization of entity's network management system to the next re-initialization." ::= { iptfsConfigTableEntry 1 } congestionControl OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "When set to true, the default, this enables the congestion control on-the-wire exchange of data that is required by congestion control algorithms as defined by RFC 5348. When set to false, IP-TFS sends fixed-sized packets over an IP-TFS tunnel at a constant rate." ::= { iptfsConfigTableEntry 2 } usePathMtuDiscovery OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Packet size is either auto-discovered or manually configured. If usePathMtuDiscovery is true the system utilizes path-mtu to determine maximum IP-TFS packet size. If the packet size is explicitly configured then it will only be adjusted downward if use-path-mtu is set." ::= { iptfsConfigTableEntry 3 } outerPacketSize OBJECT-TYPE SYNTAX UnsignedShort MAX-ACCESS read-only STATUS current DESCRIPTION "On Transmission, the size of the outer encapsulating tunnel packet (i.e., the IP packet containing the ESP payload)." ::= { iptfsConfigTableEntry 4 } l2FixedRate OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "IP-TFS bit rate may be specified as a layer 2 wire rate. Fedyk & Kinzie Expires 24 April 2023 [Page 8] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 On transmission, target bandwidth/bit rate in bps for IP-TFS tunnel. This rate is the nominal timing for the fixed size packet. If congestion control is enabled the rate may be adjusted down." ::= { iptfsConfigTableEntry 5 } l3FixedRate OBJECT-TYPE SYNTAX CounterBasedGauge64 MAX-ACCESS read-only STATUS current DESCRIPTION "IP-TFS bit rate may be specified as a layer 3 packet rate. On Transmission, target bandwidth/bit rate in bps for IP-TFS tunnel. This rate is the nominal timing for the fixed size packet. If congestion control is enabled the rate may be adjusted down." ::= { iptfsConfigTableEntry 6 } dontFragment OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "On transmission, disable packet fragmentation across consecutive IP-TFS tunnel packets; inner packets larger than what can be transmitted in outer packets will be dropped." ::= { iptfsConfigTableEntry 7 } maxAggregationTime OBJECT-TYPE SYNTAX NanoSeconds MAX-ACCESS read-only STATUS current DESCRIPTION "On transmission, maximum aggregation time is the maximum length of time a received inner packet can be held prior to transmission in the IP-TFS tunnel. Inner packets that would be held longer than this time, based on the current tunnel configuration will be dropped rather than be queued for transmission." ::= { iptfsConfigTableEntry 8 } windowSize OBJECT-TYPE SYNTAX UnsignedShort MAX-ACCESS read-only STATUS current DESCRIPTION "On reception, the maximum number of out-of-order Fedyk & Kinzie Expires 24 April 2023 [Page 9] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 packets that will be reordered by an IP-TFS receiver while performing the reordering operation. The value 0 disables any reordering." ::= { iptfsConfigTableEntry 9 } sendImmediately OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "On reception, send inner packets as soon as possible, do not wait for lost or misordered outer packets. Selecting this option reduces the inner (user) packet delay but can amplify out-of-order delivery of the inner packet stream in the presence of packet aggregation and any reordering." ::= { iptfsConfigTableEntry 10 } lostPacketTimerInterval OBJECT-TYPE SYNTAX NanoSeconds MAX-ACCESS read-only STATUS current DESCRIPTION "On reception, this interval defines the length of time an IP-TFS receiver will wait for a missing packet before considering it lost. If not using send-immediately, then each lost packet will delay inner (user) packets until this timer expires. Setting this value too low can impact reordering and reassembly." ::= { iptfsConfigTableEntry 11 } ipsecStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsecStatsTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing basic statistics on IPsec." ::= { ipsecStatsGroup 1 } ipsecStatsTableEntry OBJECT-TYPE SYNTAX IpsecStatsTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular IKE SA." INDEX { ipsecSaIndex } Fedyk & Kinzie Expires 24 April 2023 [Page 10] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 ::= { ipsecStatsTable 1 } IpsecStatsTableEntry ::= SEQUENCE { ipsecSaIndex Integer32, -- packet statistics information txPkts Counter64, txOctets Counter64, txDropPkts Counter64, rxPkts Counter64, rxOctets Counter64, rxDropPkts Counter64 } ipsecSaIndex OBJECT-TYPE SYNTAX Integer32 (1..16777215) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, greater than zero, for each SA. It is recommended that values are assigned contiguously starting from 1. The value for each entry must remain constant at least from one re-initialization of entity's network management system to the next re-initialization." ::= { ipsecStatsTableEntry 1 } txPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Outbound Packet count." ::= { ipsecStatsTableEntry 2 } txOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Outbound Packet bytes." ::= { ipsecStatsTableEntry 3 } txDropPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current Fedyk & Kinzie Expires 24 April 2023 [Page 11] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 DESCRIPTION "Outbound dropped packets count." ::= { ipsecStatsTableEntry 4 } rxPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Inbound Packet count." ::= { ipsecStatsTableEntry 5 } rxOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Inbound Packet bytes." ::= { ipsecStatsTableEntry 6 } rxDropPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Inbound Dropped packets" ::= { ipsecStatsTableEntry 7 } iptfsInnerStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IptfsInnerSaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing information on IP-TFS Inner Packets." ::= { iptfsInnerStatsGroup 1 } iptfsInnerStatsTableEntry OBJECT-TYPE SYNTAX IptfsInnerSaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing the information on a particular IP-TFS SA." INDEX { iptfsInnerSaIndex } ::= { iptfsInnerStatsTable 1 } IptfsInnerSaEntry ::= SEQUENCE { Fedyk & Kinzie Expires 24 April 2023 [Page 12] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 iptfsInnerSaIndex Integer32, txInnerPkts Counter64, txInnerOctets Counter64, rxInnerPkts Counter64, rxInnerOctets Counter64, rxIncompleteInnerPkts Counter64 } iptfsInnerSaIndex OBJECT-TYPE SYNTAX Integer32 (1..16777215) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, greater than zero, for each SA. It is recommended that values are assigned contiguously starting from 1. The value for each entry must remain constant at least from one re-initialization of entity's network management system to the next re-initialization." ::= { iptfsInnerStatsTableEntry 1 } txInnerPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP-TFS inner packets sent. This count is whole packets only. A fragmented packet counts as one packet." ::= { iptfsInnerStatsTableEntry 2 } txInnerOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP-TFS inner octets sent. This is inner packet octets only. Does not count padding." ::= { iptfsInnerStatsTableEntry 3 } rxInnerPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP-TFS inner packets received." Fedyk & Kinzie Expires 24 April 2023 [Page 13] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 ::= { iptfsInnerStatsTableEntry 4 } rxInnerOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP-TFS inner octets received. Does not include padding or overhead." ::= { iptfsInnerStatsTableEntry 5 } rxIncompleteInnerPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP-TFS inner packets that were incomplete. Usually this is due to fragments not received. Also, this may be due to misordering or errors in received outer packets." ::= { iptfsInnerStatsTableEntry 6 } iptfsOuterStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF IptfsOuterSaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing information on IP-TFS." ::= { iptfsOuterStatsGroup 1 } iptfsOuterStatsTableEntry OBJECT-TYPE SYNTAX IptfsOuterSaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing the information on a particular IP-TFS SA." INDEX { iptfsSaIndex } ::= { iptfsOuterStatsTable 1 } IptfsOuterSaEntry ::= SEQUENCE { iptfsSaIndex Integer32, -- iptfs packet statistics information txExtraPadPkts Counter64, txExtraPadOctets Counter64, txAllPadPkts Counter64, txAllPadOctets Counter64, Fedyk & Kinzie Expires 24 April 2023 [Page 14] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 rxExtraPadPkts Counter64, rxExtraPadOctets Counter64, rxAllPadPkts Counter64, rxAllPadOctets Counter64, rxErroredPkts Counter64, rxMissedPkts Counter64 } iptfsSaIndex OBJECT-TYPE SYNTAX Integer32 (1..16777215) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, greater than zero, for each SA. It is recommended that values are assigned contiguously starting from 1. The value for each entry must remain constant at least from one re-initialization of entity's network management system to the next re-initialization." ::= { iptfsOuterStatsTableEntry 1 } txExtraPadPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of transmitted outer IP-TFS packets that included some padding." ::= { iptfsOuterStatsTableEntry 2 } txExtraPadOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of transmitted octets of padding added to outer IP-TFS packets with data." ::= { iptfsOuterStatsTableEntry 3 } txAllPadPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of transmitted IP-TFS packets that were all padding with no inner packet data." Fedyk & Kinzie Expires 24 April 2023 [Page 15] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 ::= { iptfsOuterStatsTableEntry 4 } txAllPadOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number transmitted octets of padding added to IP-TFS packets with no inner packet data." ::= { iptfsOuterStatsTableEntry 5 } rxExtraPadPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of received outer IP-TFS packets that included some padding." ::= { iptfsOuterStatsTableEntry 6 } rxExtraPadOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of received octets of padding added to outer IP-TFS packets with data." ::= { iptfsOuterStatsTableEntry 7 } rxAllPadPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of received IP-TFS packets that were all padding with no inner packet data." ::= { iptfsOuterStatsTableEntry 8 } rxAllPadOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number received octets of padding added to IP-TFS packets with no inner packet data." ::= { iptfsOuterStatsTableEntry 9 } rxErroredPkts OBJECT-TYPE Fedyk & Kinzie Expires 24 April 2023 [Page 16] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP-TFS outer packets dropped due to errors." ::= { iptfsOuterStatsTableEntry 10 } rxMissedPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of IP-TFS outer packets missing indicated by missing sequence number." ::= { iptfsOuterStatsTableEntry 11 } -- -- Iptfs Module Compliance -- iptfsMIBConformances OBJECT IDENTIFIER ::= { iptfsMIBConformance 1 } iptfsMIBGroups OBJECT IDENTIFIER ::= { iptfsMIBConformance 2 } iptfsMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the IP-TFS MIB" MODULE -- this module MANDATORY-GROUPS { iptfsMIBConfGroup, ipsecStatsConfGroup, iptfsInnerStatsConfGroup, iptfsOuterStatsConfGroup } ::= { iptfsMIBConformances 1 } -- -- MIB Groups (Units of Conformance) -- iptfsMIBConfGroup OBJECT-GROUP OBJECTS { Fedyk & Kinzie Expires 24 April 2023 [Page 17] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 congestionControl, usePathMtuDiscovery, outerPacketSize , l2FixedRate , l3FixedRate , dontFragment, maxAggregationTime, windowSize, sendImmediately, lostPacketTimerInterval } STATUS current DESCRIPTION "A collection of objects providing per SA IP-TFS Configuration." ::= { iptfsMIBGroups 1 } ipsecStatsConfGroup OBJECT-GROUP OBJECTS { txPkts, txOctets, txDropPkts, rxPkts, rxOctets, rxDropPkts } STATUS current DESCRIPTION "A collection of objects providing per SA Basic Stats." ::= { iptfsMIBGroups 2 } iptfsInnerStatsConfGroup OBJECT-GROUP OBJECTS { txInnerPkts, txInnerOctets, rxInnerPkts, rxInnerOctets, rxIncompleteInnerPkts } STATUS current DESCRIPTION "A collection of objects providing per SA IP-TFS Inner Packet Statistics." ::= { iptfsMIBGroups 3 } iptfsOuterStatsConfGroup OBJECT-GROUP Fedyk & Kinzie Expires 24 April 2023 [Page 18] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 OBJECTS { txExtraPadPkts, txExtraPadOctets, txAllPadPkts, txAllPadOctets, rxExtraPadPkts, rxExtraPadOctets, rxAllPadPkts, rxAllPadOctets, rxErroredPkts, rxMissedPkts } STATUS current DESCRIPTION "A collection of objects providing per SA IP-TFS Outer Packet Statistics." ::= { iptfsMIBGroups 4 } END 5. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value, recorded in the SMI Network Management MGMT Codes Internet-standard MIB - registry: Name Description OBJECT IDENTIFIER value ------- --------------------------------- ---------------------- iptfsMIB IP-TRAFFIC-FLOW-SECURITY-MIB { mib-2 TBA-IANA } 6. Security Considerations The MIB specified in this document can read the operational behavior of IP traffic flow security. For the implications regarding write configuration consult the [I-D.ietf-ipsecme-iptfs] which defines the functionality. There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. Some of the objects in this MIB module may be considered sensitive or vulnerable in some network environments. This includes INDEX objects with a MAX-ACCESS of not-accessible, and any indices from other Fedyk & Kinzie Expires 24 April 2023 [Page 19] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 modules exposed via AUGMENTS. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: * iptfsInnerStatsTable and iptfsOuterStatsTable- Access to IP inner and outer traffic flow security statistics can provide information that IP traffic flow security obscures such as the true activity of the flows using IP traffic flow security. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET (read) the objects in this MIB module. To prevent unauthorized access to SNMP including access to IP-TFS sensitive objects: * Implementations SHOULD provide the security features described by the SNMPv3 framework (see [RFC3410]), and implementations claiming compliance to the SNMPv3 standard MUST include full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. * Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. Acknowledgements The authors would like to thank Chris Hopps, Lou Berger and Tero Kivinen for their help and feedback on the MIB model. 8. References 8.1. Normative References Fedyk & Kinzie Expires 24 April 2023 [Page 20] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 [I-D.ietf-ipsecme-iptfs] Hopps, C., "IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security", Work in Progress, Internet-Draft, draft-ietf-ipsecme-iptfs-19, 4 September 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/RFC2578, April 1999, . [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, . [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, DOI 10.17487/RFC3414, December 2002, . [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model", RFC 3826, DOI 10.17487/RFC3826, June 2004, . [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, . [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June 2009, . Fedyk & Kinzie Expires 24 April 2023 [Page 21] Internet-Draft draft-ietf-ipsecme-mib-iptfs-11 October 2022 [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [I-D.ietf-ipsecme-yang-iptfs] Fedyk, D. and C. Hopps, "A YANG Data Model for IP Traffic Flow Security", Work in Progress, Internet-Draft, draft- ietf-ipsecme-yang-iptfs-11, 31 August 2022, . [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Conformance Statements for SMIv2", STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, . [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, DOI 10.17487/RFC3410, December 2002, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, . Authors' Addresses Don Fedyk LabN Consulting, L.L.C. Email: dfedyk@labn.net Eric Kinzie LabN Consulting, L.L.C. Email: ekinzie@labn.net Fedyk & Kinzie Expires 24 April 2023 [Page 22] ./queue2.xml0000644000764400076440000012474514363120042012603 0ustar iustiniustin
draft-ietf-avtext-lrr-07.txt 2017-07-07 MISSREF*R(1G) draft-ietf-avtext-framemarking NOT-RECEIVED J. Lennox, D. Hong, J. Uberti, S. Holmer, M. Flodman The Layer Refresh Request (LRR) RTCP Feedback Message 31966 Audio/Video Transport Extensions yes draft-ietf-trill-ecn-support-07.txt 2018-03-12 MISSREF*R(1G) draft-ietf-tsvwg-ecn-encap-guidelines NOT-RECEIVED D. Eastlake 3rd, B. Briscoe TRILL (TRansparent Interconnection of Lots of Links): ECN (Explicit Congestion Notification) Support 33826 Transparent Interconnection of Lots of Links yes draft-ietf-mpls-rfc6374-sfl-10.txt 2021-03-05 MISSREF*R(1G) draft-ietf-mpls-sfl-control NOT-RECEIVED S. Bryant, Ed., G. Swallow, M. Chen, G. Fioccola, G. Mirsky RFC6374 Synonymous Flow Labels 46974 Multiprotocol Label Switching yes draft-ietf-payload-vp9-16.txt 2021-06-10 MISSREF*R(2G) draft-ietf-avtext-lrr IN-QUEUE J. Uberti, S. Holmer, M. Flodman, D. Hong, J. Lennox RTP Payload Format for VP9 Video 57070 Audio/Video Transport Core Maintenance yes draft-ietf-oauth-jwt-introspection-response-12.txt 2021-09-06 MISSREF*R(1G) draft-ietf-oauth-security-topics NOT-RECEIVED T. Lodderstedt, Ed., V. Dzhuvinov JWT Response for OAuth Token Introspection 37589 Web Authorization Protocol yes draft-ietf-babel-yang-model-13.txt 2021-09-20 MISSREF*R(1G) draft-ietf-netconf-crypto-types NOT-RECEIVED M. Jethanandani, B. Stark YANG Data Model for Babel 84778 Babel routing protocol yes draft-ietf-lsr-isis-srv6-extensions-19.txt 2021-10-20 RFC-EDITOR*R draft-ietf-lsr-flex-algo IN-QUEUE P. Psenak, Ed., C. Filsfils, A. Bashandy, B. Decraene, Z. Hu IS-IS Extensions to Support Segment Routing over IPv6 Dataplane 58434 Link State Routing yes draft-ietf-bess-evpn-bum-procedure-updates-14.txt 2022-01-04 MISSREF*R(1G) draft-ietf-bess-mvpn-evpn-aggregation-label NOT-RECEIVED Z. Zhang, W. Lin, J. Rabadan, K. Patel, A. Sajassi Updates on EVPN BUM Procedures 48856 BGP Enabled ServiceS yes draft-ietf-bess-evpn-optimized-ir-12.txt 2022-01-25 MISSREF*R(2G) draft-ietf-bess-evpn-bum-procedure-updates IN-QUEUE J. Rabadan, Ed., S. Sathappan, W. Lin, M. Katiyar, A. Sajassi Optimized Ingress Replication Solution for Ethernet VPN (EVPN) 83254 BGP Enabled ServiceS yes draft-ietf-netconf-sztp-csr-14.txt 2022-03-03 MISSREF*R(1G) draft-ietf-netconf-crypto-types NOT-RECEIVED K. Watsen, R. Housley, S. Turner Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request 75063 Network Configuration yes draft-ietf-ecrit-similar-location-19.txt 2022-03-07 MISSREF*R(1G) draft-ietf-ecrit-lost-planned-changes NOT-RECEIVED B. Rosen, R. Marshall, J. Martin A LoST extension to return complete and similar location info 39222 Emergency Context Resolution with Internet Technologies yes draft-ietf-alto-performance-metrics-28.txt 2022-03-21 MISSREF*R(1G) draft-ietf-tcpm-rfc8312bis NOT-RECEIVED Q. Wu, Y. Yang, Y. Lee, D. Dhody, S. Randriamasy, L. Contreras ALTO Performance Cost Metrics 79551 Application-Layer Traffic Optimization yes draft-ietf-pce-binding-label-sid-15.txt 2022-03-21 MISSREF*R(1G) draft-ietf-pce-segment-routing-ipv6 NOT-RECEIVED S. Sivabalan, C. Filsfils, J. Tantsura, S. Previdi, C. Li, Ed. Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks. 57962 Path Computation Element yes draft-ietf-ace-mqtt-tls-profile-17.txt 2022-03-23 MISSREF*R(1G) draft-ietf-ace-extend-dtls-authorize NOT-RECEIVED draft-ietf-cose-x509 IN-QUEUE C. Sengul, A. Kirby Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication and Authorization for Constrained Environments (ACE) Framework 104956 Authentication and Authorization for Constrained Environments yes draft-ietf-i2nsf-nsf-facing-interface-dm-29.txt 2022-05-16 MISSREF*R(2G) draft-ietf-i2nsf-capability-data-model IN-QUEUE draft-ietf-i2nsf-nsf-monitoring-data-model IN-QUEUE J. Kim, Ed., J. Jeong, Ed., J. Park, S. Hares, Q. Lin I2NSF Network Security Function-Facing Interface YANG Data Model 163771 Interface to Network Security Functions yes draft-ietf-i2nsf-capability-data-model-32.txt 2022-05-16 MISSREF*R(1G) draft-ietf-i2nsf-nsf-facing-interface-dm IN-QUEUE draft-ietf-i2nsf-nsf-monitoring-data-model IN-QUEUE draft-ietf-i2nsf-registration-interface-dm NOT-RECEIVED draft-ietf-tcpm-accurate-ecn NOT-RECEIVED draft-ietf-tsvwg-udp-options NOT-RECEIVED S. Hares, Ed., J. Jeong, Ed., J. Kim, R. Moskowitz, Q. Lin I2NSF Capability YANG Data Model 144719 Interface to Network Security Functions yes draft-ietf-i2nsf-nsf-monitoring-data-model-20.txt 2022-05-18 MISSREF*R(2G) draft-ietf-i2nsf-capability-data-model IN-QUEUE draft-ietf-i2nsf-nsf-facing-interface-dm IN-QUEUE J. Jeong, P. Lingga, S. Hares, L. Xia, H. Birkholz I2NSF NSF Monitoring Interface YANG Data Model 198846 Interface to Network Security Functions yes draft-ietf-rats-yang-tpm-charra-21.txt 2022-05-23 MISSREF*R(1G) draft-ietf-netconf-keystore NOT-RECEIVED draft-ietf-rats-tpm-based-network-device-attest IN-QUEUE H. Birkholz, M. Eckel, S. Bhandari, E. Voit, B. Sulzen, L. Xia, T. Laffey, G. Fedorkow A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs 112198 Remote ATtestation ProcedureS yes draft-ietf-dnsop-svcb-https-11.txt 2022-05-25 MISSREF*R(1G) draft-ietf-tls-esni NOT-RECEIVED B. Schwartz, M. Bishop, E. Nygren Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) 135581 Domain Name System Operations yes draft-ietf-lamps-cmp-algorithms-15.txt 2022-06-09 MISSREF*R(1G) draft-ietf-lamps-cmp-updates IN-QUEUE draft-ietf-lamps-lightweight-cmp-profile NOT-RECEIVED H. Brockhaus, H. Aschauer, M. Ounsworth, J. Gray Certificate Management Protocol (CMP) Algorithms 73637 Limited Additional Mechanisms for PKIX and SMIME yes draft-ietf-sidrops-8210bis-10.txt 2022-06-21 MISSREF*R(1G) draft-ietf-sidrops-aspa-profile NOT-RECEIVED R. Bush, R. Austein The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 88464 SIDR Operations yes draft-ietf-lamps-cmp-updates-23.txt 2022-07-20 MISSREF*R(1G) draft-ietf-ace-cmpv2-coap-transport NOT-RECEIVED draft-ietf-lamps-cmp-algorithms IN-QUEUE H. Brockhaus, Ed., D. von Oheimb, J. Gray Certificate Management Protocol (CMP) Updates 156825 Limited Additional Mechanisms for PKIX and SMIME yes draft-ietf-sacm-coswid-22.txt 2022-07-20 IANA H. Birkholz, J. Fitzgerald-McKay, C. Schmidt, D. Waltermire Concise Software Identification Tags 179823 Security Automation and Continuous Monitoring yes draft-ietf-add-ddr-10.txt 2022-08-22 MISSREF*R(2G) draft-ietf-add-dnr IN-QUEUE draft-ietf-add-svcb-dns IN-QUEUE draft-ietf-dnsop-svcb-https IN-QUEUE T. Pauly, E. Kinnear, C. Wood, P. McManus, T. Jensen Discovery of Designated Resolvers 46520 Adaptive DNS Discovery yes draft-ietf-add-dnr-13.txt 2022-08-22 MISSREF*R(2G) draft-ietf-add-svcb-dns IN-QUEUE draft-ietf-dnsop-svcb-https IN-QUEUE M. Boucadair, Ed., T. Reddy, Ed., D. Wing, N. Cook, T. Jensen DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) 58700 Adaptive DNS Discovery yes draft-ietf-add-svcb-dns-07.txt 2022-08-22 MISSREF*R(2G) draft-ietf-dnsop-svcb-https IN-QUEUE B. Schwartz Service Binding Mapping for DNS Servers 25174 Adaptive DNS Discovery yes draft-ietf-idr-bgp-ls-flex-algo-12.txt 2022-08-29 AUTH48-DONE https://www.rfc-editor.org/auth48/rfc9351 K. Talaulikar, Ed., P. Psenak, S. Zandi, G. Dawra Flexible Algorithm Advertisement using BGP Link-State 34170 Inter-Domain Routing yes no draft-ietf-tcpm-yang-tcp-09.txt 2022-09-12 MISSREF*R(1G) draft-ietf-netconf-tcp-client-server NOT-RECEIVED M. Scharf, M. Jethanandani, V. Murgai A YANG Model for Transmission Control Protocol (TCP) Configuration and State 58898 TCP Maintenance and Minor Extensions yes draft-ietf-ipsecme-iptfs-19.txt 2022-09-22 AUTH48-DONE https://www.rfc-editor.org/auth48/rfc9347 C. Hopps IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security 84661 IP Security Maintenance and Extensions yes no draft-ietf-ipsecme-yang-iptfs-11.txt 2022-09-23 AUTH48-DONE*R https://www.rfc-editor.org/auth48/rfc9348 draft-ietf-ipsecme-iptfs IN-QUEUE D. Fedyk, C. Hopps A YANG Data Model for IP Traffic Flow Security 53045 IP Security Maintenance and Extensions yes no draft-ietf-avtcore-cryptex-08.txt 2022-09-28 AUTH48 https://www.rfc-editor.org/auth48/rfc9335 J. Uberti, C. Jennings, S. Murillo Completely Encrypting RTP Header Extensions and Contributing Sources 40655 Audio/Video Transport Core Maintenance yes no draft-ietf-lsr-isis-rfc5316bis-07.txt 2022-09-28 AUTH48 https://www.rfc-editor.org/auth48/rfc9346 M. Chen, L. Ginsberg, S. Previdi, D. Xiaodong IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering 50716 Link State Routing yes no draft-ietf-tls-subcerts-15.txt 2022-10-03 RFC-EDITOR R. Barnes, S. Iyengar, N. Sullivan, E. Rescorla Delegated Credentials for (D)TLS 40192 Transport Layer Security yes draft-ietf-lsr-ospf-bfd-strict-mode-10.txt 2022-10-06 AUTH48 https://www.rfc-editor.org/auth48/rfc9355 K. Talaulikar, Ed., P. Psenak, A. Fu, M. Rajesh OSPF BFD Strict-Mode 25374 Link State Routing yes no draft-ietf-lsr-flex-algo-26.txt 2022-10-07 AUTH48*R https://www.rfc-editor.org/auth48/rfc9350 draft-ietf-lsr-isis-srv6-extensions IN-QUEUE P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, A. Gulko IGP Flexible Algorithm 113141 Link State Routing yes yes draft-ietf-lsr-ospf-l2bundles-10.txt 2022-10-07 AUTH48-DONE https://www.rfc-editor.org/auth48/rfc9356 K. Talaulikar, Ed., P. Psenak Advertising Layer 2 Bundle Member Link Attributes in OSPF 25222 Link State Routing yes no draft-ietf-lpwan-schc-yang-data-model-21.txt 2022-10-10 RFC-EDITOR A. Minaburo, L. Toutain Data Model for Static Context Header Compression (SCHC) 100322 IPv6 over Low Power Wide-Area Networks yes draft-ietf-dots-robust-blocks-06.txt 2022-10-13 RFC-EDITOR M. Boucadair, J. Shallow Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission 44574 DDoS Open Threat Signaling yes draft-ietf-cose-x509-09.txt 2022-10-13 RFC-EDITOR J. Schaad CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates 32654 CBOR Object Signing and Encryption yes draft-ietf-ipsecme-mib-iptfs-11.txt 2022-10-21 AUTH48*R https://www.rfc-editor.org/auth48/rfc9349 draft-ietf-ipsecme-iptfs IN-QUEUE D. Fedyk, E. Kinzie Definitions of Managed Objects for IP Traffic Flow Security 43786 IP Security Maintenance and Extensions yes no draft-ietf-pce-vn-association-11.txt 2022-10-24 RFC-EDITOR Y. Lee, H. Zheng, D. Ceccarelli Path Computation Element Communication Protocol (PCEP) extensions for establishing relationships between sets of Label Switched Paths and Virtual Networks 29975 Path Computation Element yes draft-ietf-pce-lsp-extended-flags-09.txt 2022-10-24 AUTH48 https://www.rfc-editor.org/auth48/rfc9357 Q. Xiong Label Switched Path (LSP) Object Flag Extension for Stateful PCE 21266 Path Computation Element yes no draft-ietf-sipcore-multiple-reasons-01.txt 2022-11-02 EDIT R. Sparks Multiple SIP Reason Header Field Values 7657 Session Initiation Protocol Core yes draft-ietf-dime-group-signaling-14.txt 2022-11-10 EDIT M. Jones, M. Liebsch, L. Morand Diameter Group Signaling 62465 Diameter Maintenance and Extensions yes draft-ietf-quic-v2-10.txt 2022-11-10 RFC-EDITOR*R draft-ietf-quic-version-negotiation IN-QUEUE M. Duke QUIC Version 2 34308 QUIC yes draft-ietf-quic-version-negotiation-14.txt 2022-11-10 RFC-EDITOR D. Schinazi, E. Rescorla Compatible Version Negotiation for QUIC 43935 QUIC yes draft-ietf-opsawg-yang-vpn-service-pm-15.txt 2022-11-11 EDIT B. Wu, Ed., Q. Wu, Ed., M. Boucadair, Ed., O. Gonzalez de Dios, B. Wen A YANG Model for Network and VPN Service Performance Monitoring 85601 Operations and Management Area Working Group yes draft-ietf-ippm-ioam-conf-state-10.txt 2022-11-23 RFC-EDITOR X. Min, G. Mirsky, L. Bo Echo Request/Reply for Enabled In-situ OAM Capabilities 43138 IP Performance Measurement yes draft-ietf-drip-rid-37.txt 2022-12-02 EDIT*R draft-moskowitz-ipsecme-ipseckey-eddsa IN-QUEUE R. Moskowitz, S. Card, A. Wiethuechter, A. Gurtov DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID) 81453 Drone Remote ID Protocol yes draft-ietf-ipsecme-ikev2-multiple-ke-12.txt 2022-12-09 EDIT C. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D. Van Geest, O. Garcia-Morchon, V. Smyslov Multiple Key Exchanges in IKEv2 89565 IP Security Maintenance and Extensions yes draft-ietf-lamps-rfc3709bis-10.txt 2022-12-16 EDIT*A S. Santesson, R. Housley, T. Freeman, L. Rosenthol Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates 106685 Limited Additional Mechanisms for PKIX and SMIME yes draft-ietf-lpwan-schc-over-nbiot-15.txt 2022-12-21 EDIT E. Ramos, A. Minaburo Static Context Header Compression over Narrowband Internet of Things 56890 IPv6 over Low Power Wide-Area Networks yes draft-ietf-oauth-rar-22.txt 2022-12-29 EDIT T. Lodderstedt, J. Richer, B. Campbell OAuth 2.0 Rich Authorization Requests 79274 Web Authorization Protocol yes draft-ietf-ipsecme-ikev1-algo-to-historic-09.txt 2023-01-03 EDIT P. Wouters Deprecation of IKEv1 and obsoleted algorithms 16809 IP Security Maintenance and Extensions yes draft-ietf-extra-imap-partial-04.txt 2023-01-04 EDIT A. Melnikov, A. Achuthan, V. Nagulakonda, L. Alves IMAP Paged SEARCH & FETCH Extension 21243 Email mailstore and eXtensions To Revise or Amend yes draft-ietf-pim-igmp-mld-proxy-yang-10.txt 2023-01-06 EDIT H. Zhao, X. Liu, Y. Liu, M. Panchanathan, M. Sivakumar A YANG Data Model for IGMP/MLD Proxy 38297 Protocols for IP Multicast yes draft-ietf-idr-bfd-subcode-05.txt 2023-01-12 EDIT J. Haas A BGP Cease Notification Subcode For Bidirectional Forwarding Detection (BFD) 11295 Inter-Domain Routing yes draft-ietf-jmap-blob-18.txt 2023-01-17 EDIT*A B. Gondwana, Ed. JMAP Blob management extension 46304 JSON Mail Access Protocol yes
draft-moskowitz-ipsecme-ipseckey-eddsa-09.txt 2023-01-09 EDIT R. Moskowitz, T. Kivinen, M. Richardson EdDSA value for IPSECKEY 7912 IETF - NON WORKING GROUP yes
draft-ietf-i2nsf-applicability-18.txt 2019-12-16 MISSREF*R(1G) draft-ietf-i2nsf-consumer-facing-interface-dm NOT-RECEIVED draft-ietf-i2nsf-nsf-facing-interface-dm IN-QUEUE draft-ietf-i2nsf-nsf-monitoring-data-model IN-QUEUE draft-ietf-i2nsf-registration-interface-dm NOT-RECEIVED J. Jeong, S. Hyun, T. Ahn, S. Hares, D. Lopez Applicability of Interfaces to Network Security Functions to Network-Based Security Services 69045 Interface to Network Security Functions yes draft-ietf-rats-tpm-based-network-device-attest-14.txt 2022-03-22 MISSREF*R(2G) draft-ietf-rats-yang-tpm-charra IN-QUEUE draft-ietf-sacm-coswid IN-QUEUE G. Fedorkow, Ed., E. Voit, J. Fitzgerald-McKay TPM-based Network Device Remote Integrity Verification 111136 Remote ATtestation ProcedureS yes draft-ietf-dnsop-dnssec-bcp-06.txt 2022-10-26 RFC-EDITOR P. Hoffman DNS Security Extensions (DNSSEC) 25138 Domain Name System Operations yes draft-ietf-ipwave-vehicular-networking-30.txt 2022-11-09 EDIT J. Jeong, Ed. IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases 151772 IP Wireless Access in Vehicular Environments yes draft-ietf-bmwg-ngfw-performance-15.txt 2022-11-14 EDIT B. Balarajah, C. Rossenhoevel, B. Monkman Benchmarking Methodology for Network Security Device Performance 143459 Benchmarking Methodology yes draft-ietf-raw-ldacs-14.txt 2022-12-02 EDIT N. Mäurer, Ed., T. Gräupl, Ed., C. Schmitt, Ed. L-band Digital Aeronautical Communications System (LDACS) 103204 Reliable and Available Wireless yes draft-ietf-v6ops-ipv6-deployment-10.txt 2022-12-02 EDIT G. Fioccola, P. Volpato, J. Martinez, G. Mishra, C. Xie IPv6 Deployment Status 108761 IPv6 Operations yes draft-ietf-ccamp-gmpls-otn-b100g-applicability-15.txt 2022-12-05 EDIT Q. Wang, Ed., R. Valiveti, Ed., H. Zheng, Ed., H. Helvoort, S. Belotti Applicability of GMPLS for Beyond 100G Optical Transport Network 35390 Common Control and Measurement Plane yes draft-ietf-lsr-isis-flood-reflection-12.txt 2022-12-06 EDIT T. Przygienda, Ed., C. Bowers, Y. Lee, A. Sharma, R. White IS-IS Flood Reflection 53564 Link State Routing yes draft-ietf-dots-telemetry-use-cases-15.txt 2022-12-09 EDIT Y. Hayashi, M. Chen, L. Su Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry 52141 DDoS Open Threat Signaling yes draft-ietf-teep-architecture-19.txt 2022-12-22 EDIT M. Pei, H. Tschofenig, D. Thaler, D. Wheeler Trusted Execution Environment Provisioning (TEEP) Architecture 96954 Trusted Execution Environment Provisioning yes draft-ietf-rmcat-rtp-cc-feedback-12.txt 2022-12-22 EDIT C. Perkins Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences 50007 RTP Media Congestion Avoidance Techniques yes draft-ietf-shmoo-online-meeting-05.txt 2023-01-09 EDIT M. Kühlewind, M. Duke Guidelines for the Organization of Fully Online Meetings 24309 Stay Home Meet Occasionally Online yes draft-ietf-ippm-ioam-deployment-05.txt 2023-01-17 EDIT F. Brockners, Ed., S. Bhandari, Ed., D. Bernier, T. Mizrahi, Ed. In-situ OAM Deployment 61033 IP Performance Measurement yes
draft-pti-pen-registration-10.txt 2022-12-16 EDIT A. Baber, P. Hoffman Registration Procedures for Private Enterprise Numbers (PENs) 12445 IETF - NON WORKING GROUP yes draft-davies-int-historic-05.txt 2023-01-09 EDIT K. Davies, A. Baber Deprecating infrastructure "int" domains 11685 IETF - NON WORKING GROUP yes draft-zern-webp-12.txt 2023-01-12 EDIT J. Zern, P. Massimino, J. Alakuijala WebP Image Format 101705 IETF - NON WORKING GROUP yes
draft-irtf-cfrg-spake2-26.txt 2022-02-14 REF*R draft-irtf-cfrg-hash-to-curve IN-QUEUE W. Ladd, B. Kaduk, Ed. SPAKE2, a PAKE 40130 Crypto Forum Research Group no draft-irtf-cfrg-hash-to-curve-16.txt 2022-10-02 EDIT A. Faz-Hernández, S. Scott, N. Sullivan, R. Wahby, C. A. Wood Hashing to Elliptic Curves 391878 Crypto Forum Research Group yes draft-irtf-qirg-principles-11.txt 2022-10-05 AUTH48 https://www.rfc-editor.org/auth48/rfc9340 W. Kozlowski, S. Wehner, R. Van Meter, B. Rijsman, A. S. Cacciapuoti, M. Caleffi, S. Nagayama Architectural Principles for a Quantum Internet 116744 Quantum Internet Research Group yes no draft-irtf-icnrg-ccninfo-15.txt 2022-10-07 RFC-EDITOR H. Asaeda, A. Ooka, X. Shao CCNinfo: Discovering Content and Network Information in Content-Centric Networks 92629 Information-Centric Networking Research Group yes draft-irtf-cfrg-vrf-15.txt 2022-12-02 EDIT*R draft-irtf-cfrg-hash-to-curve IN-QUEUE S. Goldberg, L. Reyzin, D. Papadopoulos, J. Včelák Verifiable Random Functions (VRFs) 121765 Crypto Forum Research Group yes draft-irtf-pearg-numeric-ids-generation-12.txt 2022-12-17 MISSREF*R(1G) draft-gont-numeric-ids-sec-considerations NOT-RECEIVED F. Gont, I. Arce On the Generation of Transient Numeric Identifiers 100515 Privacy Enhancements and Assessments Research Group yes draft-irtf-pearg-numeric-ids-history-11.txt 2022-12-17 MISSREF*R(1G) draft-gont-numeric-ids-sec-considerations NOT-RECEIVED F. Gont, I. Arce Unfortunate History of Transient Numeric Identifiers 78921 Privacy Enhancements and Assessments Research Group yes
draft-bar-cfrg-spake2plus-08.txt 2022-03-20 EDIT*R draft-irtf-cfrg-spake2 IN-QUEUE T. Taubert, C.A. Wood SPAKE2+, an Augmented PAKE 63491 INDEPENDENT N/A draft-briscoe-docsis-q-protection-06.txt 2022-05-11 MISSREF*R(1G) draft-ietf-tsvwg-nqb NOT-RECEIVED B. Briscoe, Ed., G. White The DOCSIS(r) Queue Protection Algorithm to Preserve Low Latency 73799 INDEPENDENT N/A draft-ietf-regext-tmch-func-spec-15.txt 2022-10-11 RFC-EDITOR*A G. Lozano ICANN TMCH functional specifications 127771 INDEPENDENT N/A draft-smyshlyaev-tls13-gost-suites-08.txt 2022-10-24 RFC-EDITOR S. Smyshlyaev, Ed., E. Alekseev, E. Griboedova, A. Babueva, L. Nikiforova GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3 178796 INDEPENDENT N/A draft-smyslov-ike2-gost-15.txt 2022-12-06 EDIT V. Smyslov Using GOST Cryptographic Algorithms in the Internet Key Exchange Protocol Version 2 (IKEv2) 310538 INDEPENDENT yes
./draft-ietf-i2nsf-nsf-monitoring-data-model-20.txt0000644000764400076440000060426614245671660021674 0ustar iustiniustin Network Working Group J. Jeong, Ed. Internet-Draft P. Lingga Intended status: Standards Track Sungkyunkwan University Expires: 3 December 2022 S. Hares L. Xia Huawei H. Birkholz Fraunhofer SIT 1 June 2022 I2NSF NSF Monitoring Interface YANG Data Model draft-ietf-i2nsf-nsf-monitoring-data-model-20 Abstract This document proposes an information model and the corresponding YANG data model of an interface for monitoring Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework. If the monitoring of NSFs is performed with the NSF monitoring interface in a standard way, it is possible to detect the indication of malicious activity, anomalous behavior, the potential sign of denial-of-service attacks, or system overload in a timely manner. This monitoring functionality is based on the monitoring information that is generated by NSFs. Thus, this document describes not only an information model for the NSF monitoring interface along with a YANG tree diagram, but also the corresponding YANG data model. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 December 2022. Jeong, et al. Expires 3 December 2022 [Page 1] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases for NSF Monitoring Data . . . . . . . . . . . . . . 5 4. Classification of NSF Monitoring Data . . . . . . . . . . . . 5 4.1. Retention and Emission from NSFs . . . . . . . . . . . . 6 4.2. Notifications for Events and Records . . . . . . . . . . 8 4.3. Push and Pull for the retrieval of monitoring data from NSFs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Basic Information Model for Monitoring Data . . . . . . . . . 9 6. Extended Information Model for Monitoring Data . . . . . . . 10 6.1. System Alarms . . . . . . . . . . . . . . . . . . . . . . 11 6.1.1. Memory Alarm . . . . . . . . . . . . . . . . . . . . 11 6.1.2. CPU Alarm . . . . . . . . . . . . . . . . . . . . . . 11 6.1.3. Disk (Storage) Alarm . . . . . . . . . . . . . . . . 12 6.1.4. Hardware Alarm . . . . . . . . . . . . . . . . . . . 12 6.1.5. Interface Alarm . . . . . . . . . . . . . . . . . . . 13 6.2. System Events . . . . . . . . . . . . . . . . . . . . . . 13 6.2.1. Access Violation . . . . . . . . . . . . . . . . . . 13 6.2.2. Configuration Change . . . . . . . . . . . . . . . . 14 6.2.3. Session Table Event . . . . . . . . . . . . . . . . . 15 6.2.4. Traffic Flows . . . . . . . . . . . . . . . . . . . . 15 6.3. NSF Events . . . . . . . . . . . . . . . . . . . . . . . 16 6.3.1. DDoS Detection . . . . . . . . . . . . . . . . . . . 17 6.3.2. Virus Event . . . . . . . . . . . . . . . . . . . . . 18 6.3.3. Intrusion Event . . . . . . . . . . . . . . . . . . . 19 6.3.4. Web Attack Event . . . . . . . . . . . . . . . . . . 19 6.3.5. VoIP/VoCN Event . . . . . . . . . . . . . . . . . . . 20 6.4. System Logs . . . . . . . . . . . . . . . . . . . . . . . 21 6.4.1. Access Log . . . . . . . . . . . . . . . . . . . . . 21 6.4.2. Resource Utilization Log . . . . . . . . . . . . . . 22 6.4.3. User Activity Log . . . . . . . . . . . . . . . . . . 23 6.5. NSF Logs . . . . . . . . . . . . . . . . . . . . . . . . 24 Jeong, et al. Expires 3 December 2022 [Page 2] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 6.5.1. Deep Packet Inspection Log . . . . . . . . . . . . . 24 6.6. System Counter . . . . . . . . . . . . . . . . . . . . . 24 6.6.1. Interface Counter . . . . . . . . . . . . . . . . . . 24 6.7. NSF Counters . . . . . . . . . . . . . . . . . . . . . . 26 6.7.1. Firewall Counter . . . . . . . . . . . . . . . . . . 26 6.7.2. Policy Hit Counter . . . . . . . . . . . . . . . . . 27 7. YANG Tree Structure of NSF Monitoring YANG Module . . . . . . 28 8. YANG Data Model of NSF Monitoring YANG Module . . . . . . . . 34 9. I2NSF Event Stream . . . . . . . . . . . . . . . . . . . . . 85 10. XML Examples for I2NSF NSF Monitoring . . . . . . . . . . . . 86 10.1. I2NSF System Detection Alarm . . . . . . . . . . . . . . 86 10.2. I2NSF Interface Counters . . . . . . . . . . . . . . . . 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 90 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 92 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 92 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 15.1. Normative References . . . . . . . . . . . . . . . . . . 93 15.2. Informative References . . . . . . . . . . . . . . . . . 97 Appendix A. Changes from draft-ietf-i2nsf-nsf-monitoring-data-model-19 . . . . . . 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 98 1. Introduction According to [RFC8329], the interface provided by a Network Security Function (NSF) (e.g., Firewall, IPS, or Anti-DDoS function) to enable the collection of monitoring information is referred to as an I2NSF Monitoring Interface. This interface enables the sharing of vital data from the NSFs (e.g., events, records, and counters) to an NSF data collector (e.g., Security Controller) through a variety of mechanisms (e.g., queries and notifications). The monitoring of NSF plays an important role in an overall security framework, if it is done in a timely way. The monitoring information generated by an NSF can be a good, early indication of anomalous behavior or malicious activity, such as denial-of-service (DoS) attacks. This document defines an information model of an NSF monitoring interface that provides visibility into an NSF for the NSF data collector (note that an NSF data collector is defined as an entity to collect NSF monitoring data from an NSF, such as Security Controller). It specifies the information and illustrates the methods that enable an NSF to provide the information required in order to be monitored in a scalable and efficient way via the NSF Monitoring Interface. The information model for the NSF monitoring interface presented in this document is complementary for the security policy provisioning functionality of the NSF-Facing Interface specified in [I-D.ietf-i2nsf-nsf-facing-interface-dm]. Jeong, et al. Expires 3 December 2022 [Page 3] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 This document also defines a YANG [RFC7950] data model for the NSF monitoring interface, which is derived from the information model for the NSF monitoring interface. Note that this document covers a subset of monitoring data for systems and NSFs, which are related to security. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the terminology described in [RFC8329]. In addition, the following terms are defined in this document: * I2NSF User: An entity that delivers a high-level security policy to the Security Controller and may request monitoring information via the NSF data collector. * Monitoring Information: Relevant data that can be processed to know the status and performance of the network and the NSF. The monitoring information in an I2NSF environment consists of I2NSF Events, I2NSF Records, and I2NSF Counters (see Section 4.1 for the detailed definition). This information is to be delivered to the NSF data collector. * Notification: Unsolicited transmission of monitoring information. * NSF Data Collector: An entity that collects NSF monitoring information from NSFs, such as Security Controller. * Subscription: An agreement initialized by the NSF data collector to receive monitoring information from an NSF. The method to subscribe follows the method by either NETCONF or RESTCONF, explained in [RFC5277] and [RFC8650], respectively. This document follows the guidelines of [RFC8407], uses the common YANG types defined in [RFC6991], and adopts the Network Management Datastore Architecture (NMDA) [RFC8342]. The meaning of the symbols in tree diagrams is defined in [RFC8340]. Jeong, et al. Expires 3 December 2022 [Page 4] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 3. Use Cases for NSF Monitoring Data As mentioned earlier, monitoring plays a critical role in an overall security framework. The monitoring of the NSF provides very valuable information to an NSF data collector (e.g., Security Controller) in maintaining the provisioned security posture. Besides this, there are various other reasons to monitor the NSF as listed below: * The I2NSF User that is the security administrator can configure a policy that is triggered on a specific event occurring in the NSF or the network [RFC8329] [I-D.ietf-i2nsf-consumer-facing-interface-dm]. If an NSF data collector (e.g., Security Controller) detects the specified event, it can configure additional security functions as defined by policies. * The events triggered by an NSF as a result of security policy violation can be used by Security Information and Event Management (SIEM) to detect any suspicious activity in a larger correlation context. * The information (i.e., events, records, and counters) from an NSF can be used to build advanced analytics, such as behavior and predictive models to improve security posture in large deployments. * The NSF data collector can use events from the NSF for achieving high availability. It can take corrective actions such as restarting a failed NSF and horizontally scaling up the NSF. * The information (i.e., events, records, and counters) from the NSF can aid in the root cause analysis of an operational issue, so it can improve debugging. * The records from the NSF can be used to build historical data for operation and business reasons. 4. Classification of NSF Monitoring Data In order to maintain a strong security posture, it is not only necessary to configure an NSF's security policies but also to continuously monitor the NSF by checking acquirable and observable data. This enables security administrators to assess the state of the networks in a timely fashion. It is not possible to block all the internal and external threats based on static security posture. A more practical approach is supported by enabling dynamic security measures, for which continuous visibility is required. This document defines a set of monitoring elements and their scopes that can be Jeong, et al. Expires 3 December 2022 [Page 5] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 acquired from an NSF and can be used as NSF monitoring data. In essence, this monitoring data can be leveraged to support constant visibility on multiple levels of granularity and can be consumed by the corresponding functions. Three basic domains of monitoring data originating from a system entity [RFC4949], i.e., an NSF, are discussed in this document. * Retention and Emission from NSFs * Notifications for Events and Records * Push and Pull for the retrieval of monitoring data from NSFs Every system entity creates information about some context with defined I2NSF monitoring data, and so every system entity that provides such information can be an I2NSF component. This information is intended to be consumed by other I2NSF components, which deals with NSF monitoring data in an automated fashion. 4.1. Retention and Emission from NSFs A system entity (e.g., NSF) first retains I2NSF monitoring data inside its own system before emitting the information to another I2NSF component (e.g., NSF Data Collector). The I2NSF monitoring information consist of I2NSF Events, I2NSF Records, and I2NSF Counters as follows: I2NSF Event: I2NSF Event is defined as an important occurrence at a particular time, that is, a change in the system being managed or a change in the environment of the system being managed. An I2NSF Event requires immediate attention and should be notified as soon as possible. When used in the context of an (imperative) I2NSF Policy Rule, an I2NSF Event is used to determine whether the Condition clause of that Policy Rule can be evaluated or not. The Alarm Management Framework in [RFC3877] defines an event as something that happens which may be of interest. Examples of an event are a fault, a change in status, crossing a threshold, or an external input to the system. In the I2NSF domain, I2NSF events are created following the definition of an event in the Alarm Management Framework. I2NSF Record: A record is defined as an item of information that is kept to be looked at and used in the future. Typically, records are the information, which is based on operational and informational data (i.e., various changes in system characteristics). They are generated by a system entity (e.g., NSF) at particular instants to be kept without any changes Jeong, et al. Expires 3 December 2022 [Page 6] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 afterward. A set of records has an ordering in time based on when they are generated. Unlike I2NSF Events, records do not require immediate attention but may be useful for visibility and retroactive cyber forensics. Records are typically stored in log- files or databases on a system entity or NSF. The examples of records include user activities, device performance, and network status. They are important for debugging, auditing, and security forensic of a system entity or the network having the system entity. I2NSF Counter: An I2NSF Counter is defined as a specific representation of an information element whose value changes very frequently. Prominent examples are network interface counters for protocol data unit (PDU) amount, byte amount, drop counters, and error counters. Counters are useful in debugging and visibility into operational behavior of a system entity (e.g., NSF). When an NSF data collector asks for the value of a counter, a system entity MUST update the counter information and emit the latest information to the NSF data collector. Retention is defined as the storing of monitoring data in NSFs. The retention of I2NSF monitoring information may be affected by the importance of the data. The importance of the data could be context- dependent, where it may not just be based on the type of data, but may also depend on where it is deployed, e.g., a test lab and testbed. The local policy and configuration will dictate the policies and procedures to review, archive, or purge the collected monitoring data. Emission is defined as the delivery of monitoring data in NSFs to an NSF data collector. The I2NSF monitoring information retained on a system entity (e.g., NSF) may be delivered to a corresponding I2NSF User via an NSF data collector. The information consists of the aggregated records, typically in the form of log-files or databases. For the NSF Monitoring Interface to deliver the information to the NSF data collector, the NSF needs to accommodate standardized delivery protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. The NSF data collector can forward the information to the I2NSF User through standardized delivery protocols (e.g., RESTCONF and NETCONF). The interface for the delivery of Monitoring Data from the NSF data collector to the I2NSF User is out of the scope of this document. Jeong, et al. Expires 3 December 2022 [Page 7] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 4.2. Notifications for Events and Records A specific task of an I2NSF User is to provide I2NSF Policy Rules. The rules of a policy are composed of three clauses: Event, Condition, and Action clauses. In consequence, an I2NSF Event is specified to trigger the evaluation of the Condition clause of the I2NSF Policy Rule. Such an I2NSF Event is defined as an important occurrence at a particular time in the system being managed, and/or in the environment of the system being managed whose concept aligns well with the generic definition of Event from [RFC3877]. Another role of the I2NSF Event is to trigger a notification for monitoring the status of an NSF. A notification is defined in [RFC3877] as an unsolicited transmission of management information. System alarm (called alarm) is defined as a warning related to service degradation in system hardware in Section 6.1. System event (called alert) is defined as a warning about any changes of configuration, any access violation, information about sessions and traffic flows in Section 6.2. Both an alarm and an alert are I2NSF Events that can be delivered as a notification. The model illustrated in this document introduces a complementary type of information that can be a conveyed notification. In I2NSF monitoring, a notification is used to deliver either an event or a record via the I2NSF Monitoring Interface. The difference between the event and record is the timing by which the notifications are emitted. An event is emitted as soon as it happens in order to notify an NSF Data Collector of the problem that needs immediate attention. A record is not emitted immediately to the NSF Data Collector, and it can be emitted periodically to the NSF Data Collector. It is important to note that an NSF Data Collector as a consumer (i.e., observer) of a notification assesses the importance of the notification rather than an NSF as a producer. The producer can include metadata in a notification that supports the observer in assessing its importance (e.g., severity). 4.3. Push and Pull for the retrieval of monitoring data from NSFs An important aspect of monitoring information is the freshness of the information. From the perspective of security, it is important to notice changes in the current status of the network. The I2NSF Monitoring Interface provides the means of sending monitored information from the NSFs to an NSF data collector in a timely manner. Monitoring information can be acquired by a client (i.e., NSF data collector) from a server (i.e., NSF) using push [RFC5277] [RFC8641] or pull methods [RFC6241] [RFC8040]. Jeong, et al. Expires 3 December 2022 [Page 8] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 The pull is a query-based method to obtain information from the NSF. In this method, the NSF will remain passive until the information is requested from the NSF data collector. Once a request is accepted (with proper authentication), the NSF MUST update the information before sending it to the NSF data collector. The push is a report-based method to obtain information from the NSF. The report-based method ensures the information can be delivered immediately without any requests. This method is used by the NSF to actively provide information to the NSF data collector. To receive the information, the NSF data collector subscribes to the NSF for the information. These acquisition methods are used for different types of monitoring information. The information that has a high level of urgency (i.e., I2NSF Event) should be provided with the push method, while information that has a lower level of urgency (i.e., I2NSF Record and I2NSF Counter) can be provided with either the pull method or push method. 5. Basic Information Model for Monitoring Data As explained in the above section, there is a wealth of data available from NSFs that can be monitored. Firstly, there must be some general information with each monitoring message sent from an NSF that helps a consumer to identify metadata with that message, which are listed as below: * message: The extra detailed description of NSF monitoring data to give an NSF data collector the context information as metadata. * vendor-name: The vendor's name of the NSF that generates the message. * device-model: The model of the device, can be represented by the device model name or serial number. This field is used to identify the model of the device that provides the security service. * software-version: The version of the software used to provide the security service. * nsf-name: The name or IP address of the NSF generating the message. If the given nsf-name is not an IP address, the name can be an arbitrary string including a FQDN (Fully Qualified Domain Name). The name MUST be unique in the scope of management domain for a different NSF to identify the NSF that generates the message. Jeong, et al. Expires 3 December 2022 [Page 9] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 * timestamp: The time when the message was generated. For the notification operations (i.e., System Alarms, System Events, NSF Events, System Logs, and NSF Logs), this is represented by the eventTime of NETCONF event notification [RFC5277] For other operations (i.e., System Counter and NSF Counter), the timestamp MUST be provided separately. The time format used is following the rules in Section 5.6 of [RFC3339]. * language: describes the human language intended for the user, so that it allows a user to verify the language that is used in the notification (i.e., '../message', '/i2nsf-log/i2nsf-nsf-system- access-log/output', and '/i2nsf-log/i2nsf-system-user-activity- log/additional-info/cause'). The attribute is encoded following the rules in Section 2.1 of [RFC5646]. The default language tag is "en-US". 6. Extended Information Model for Monitoring Data The extended information model is the specific monitoring data that covers the additional information associated with the detailed information of status and performance of the network and the NSF over the basic information model. The extended information combined with the basic information creates the monitoring information (i.e., I2NSF Event, Record, and Counter). The extended monitoring information has settable characteristics for data collection as follows: * Acquisition method: The method to obtain the message. It can be a "query" or a "subscription". A "query" is a request-based method to acquire the solicited information. A "subscription" is a report-based method that pushes information to the subscriber. * Emission type: The cause type for the message to be emitted. This attribute is used only when the acquisition method is a "subscription" method. The emission type can be either "on- change" or "periodic". An "on-change" message is emitted when an important event happens in the NSF. A "periodic" message is emitted at a certain time interval. The time to periodically emit the message is configurable. * Dampening type: The type of message dampening to stop the rapid transmission of messages. The dampening types are "on-repetition" and "no-dampening". The "on-repetition" type limits the transmitted "on-change" message to one message at a certain interval (e.g., 100 centiseconds). This interval is defined as dampening-period in [RFC8641]. The dampening-period is configurable in the unit of centiseconds. The "no-dampening" type Jeong, et al. Expires 3 December 2022 [Page 10] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 does not limit the transmission for the messages of the same type. In short, "on-repetition" means that the dampening is active and "no-dampening" is inactive. Activating the dampening for an "on- change" type of message is RECOMMENDED to reduce the number of messages generated. Note that the characteristic information is not mandatory to be included in a monitoring message. The information is expected to be stored and may or may not be useful in some ways in the future. In any case, the inclusion of the characteristic information is up to the implementation. 6.1. System Alarms System alarms have the following characteristics: * acquisition-method: subscription * emission-type: on-change * dampening-type: on-repetition or no-dampening 6.1.1. Memory Alarm The memory is the hardware to store information temporarily or for a short period, i.e., Random Access Memory (RAM). The memory-alarm is emitted when the memory usage exceeds the threshold. The following information should be included in a Memory Alarm: * event-name: memory-alarm. * usage: specifies the amount of memory used in percentage. * threshold: The threshold triggering the alarm in percentage. * severity: The severity level of the message. There are four levels, i.e., critical, high, middle, and low. * message: Simple information as a human readable text string such as "The memory usage exceeded the threshold" or with extra information. 6.1.2. CPU Alarm CPU is the Central Processing Unit that executes basic operations of the system. The cpu-alarm is emitted when the CPU usage exceeds the threshold. The following information should be included in a CPU Alarm: Jeong, et al. Expires 3 December 2022 [Page 11] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 * event-name: cpu-alarm. * usage: Specifies the CPU utilization in percentage. * threshold: The threshold triggering the event in percentage. * severity: The severity level of the message. There are four levels, i.e., critical, high, middle, and low. * message: Simple information as a human readable text string such as "The CPU usage exceeded the threshold" or with extra information. 6.1.3. Disk (Storage) Alarm Disk or storage is the hardware to store information for a long time, i.e., Hard Disk or Solid-State Drive. The disk-alarm is emitted when the Disk usage exceeds the threshold. The following information should be included in a Disk Alarm: * event-name: disk-alarm. * usage: Specifies the ratio of the used disk space to the whole disk space in terms of percentage. * threshold: The threshold triggering the event in percentage. * severity: The severity level of the message. There are four levels, i.e., critical, high, middle, and low. * message: Simple information as a human readable text string such as "The disk usage exceeded the threshold" or with extra information. 6.1.4. Hardware Alarm The hardware-alarm is emitted when a hardware, e.g., CPU, memory, disk, or interface, problem is detected. The following information should be included in a Hardware Alarm: * event-name: hardware-alarm. * component-name: It indicates the hardware component responsible for generating this alarm. * severity: The severity level of the message. There are four levels, i.e., critical, high, middle, and low. Jeong, et al. Expires 3 December 2022 [Page 12] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 * message: Simple information as a human readable text string such as "The hardware component has failed or degraded" or with extra information. 6.1.5. Interface Alarm Interface is the network interface for connecting a device with the network. The interface-alarm is emitted when the state of the interface is changed. The following information should be included in an Interface Alarm: * event-name: interface-alarm. * interface-name: The name of the interface. * interface-state: The status of the interface, i.e., down, up (not congested), congested (up but congested), testing, unknown, dormant, not-present, and lower-layer-down. * severity: The severity level of the message. There are four levels, i.e., critical, high, middle, and low. * message: Simple information as a human readable text string such as "The interface is 'interface-state'" or with extra information. 6.2. System Events System events (as alerts) have the following characteristics: * acquisition-method: subscription * emission-type: on-change * dampening-type: on-repetition or no-dampening 6.2.1. Access Violation The access-violation system event is an event when a user tries to access (read, write, create, or delete) any information or execute commands above their privilege. The following information should be included in this event: * event-name: access-violation. * identity: The information to identify the attempted access violation. The minimum information (extensible) that should be included: Jeong, et al. Expires 3 December 2022 [Page 13] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 1. user: The unique username that attempted access violation. 2. group: Group(s) to which a user belongs. A user can belong to multiple groups. 3. ip-address: The IP address of the user that triggered the event. 4. l4-port-number: The transport layer port number used by the user. * authentication: The method to verify the valid user, i.e., pre- configured-key and certificate-authority. * message: The message as a human readable text string to give the context of the event, such as "Access is denied". 6.2.2. Configuration Change A configuration change is a system event when a new configuration is added or an existing configuration is modified. The following information should be included in this event: * event-name: configuration-change. * identity: The information to identify the user that updated the configuration. The minimum information (extensible) that should be included: 1. user: The unique username that changes the configuration. 2. group: Group(s) to which a user belongs. A user can belong to multiple groups. 3. ip-address: The IP address of the user that triggered the event. 4. l4-port-number: The transport layer port number used by the user. * authentication: The method to verify the valid user, i.e., pre- configured-key and certificate-authority. * message: The message as a human readable text string to give the context of the event, such as "Configuration is modified", "New configuration is added", or "A configuration has been removed". Jeong, et al. Expires 3 December 2022 [Page 14] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 * changes: Describes the modification that was made to the configuration. The minimum information that must be provided is the name of the policy that has been altered (added, modified, or removed). Other detailed information about the configuration changes is up to the implementation. 6.2.3. Session Table Event A session is defined as a connection (i.e., traffic flow) of a data plane (e.g., TCP, UDP, and SCTP). Session Table Event is the event triggered by the session table of an NSF. A session table holds the information of the currently active sessions. The following information should be included in a Session Table Event: * event-name: detection-session-table. * current-session: The number of concurrent sessions. * maximum-session: The maximum number of sessions that the session table can support. * threshold: The threshold (in terms of an allowed number of sessions) triggering the event. * message: The message as a human readable text string to give the context of the event, such as "The number of sessions exceeded the table threshold". 6.2.4. Traffic Flows Traffic flows need to be monitored because they might be used for security attacks to the network. The following information should be included in this event: * event-name: traffic-flows. * interface-name: The mnemonic name of the network interface * interface-type: The type of a network interface such as an ingress or egress interface. * src-mac: The source MAC address of the traffic flow. This information may or may not be included depending on the type of traffic flow. For example, the information will be useful and should be included if the traffic flows are traffic flows of Link Layer Discovery Protocol (LLDP) [IEEE-802.1AB], Address Resolution Protocol (ARP) for IPv4 [RFC0826], and Neighbor Discovery Protocol (ND) for IPv6 [RFC4861]. Jeong, et al. Expires 3 December 2022 [Page 15] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 * dst-mac: The destination MAC address of the traffic flow. This information may or may not be included depending on the type of traffic flow. For example, the information will be useful and should be included if the traffic flows are LLDP, ARP for IPv4, or ND for IPv6 traffic flows. * src-ip: The source IPv4 or IPv6 address of the traffic flow. * dst-ip: The destination IPv4 or IPv6 address of the traffic flow. * src-port: The transport layer source port number of the traffic flow. * dst-port: The transport layer destination port number of the traffic flow. * protocol: The protocol of the traffic flow. * measurement-time: The duration of the measurement in seconds for the arrival rate and arrival throughput of packets of a traffic flow. These two metrics (i.e., arrival rate and arrival throughput) are measured over the past measurement duration before now. * arrival-rate: Arrival rate of packets of the traffic flow in packets per second measured over the past "measurement-time". * arrival-throughput: Arrival rate of packets of the traffic flow in bytes per second measured over the past "measurement-time". Note that the NSF Monitoring Interface data model is focused on a generic method to collect the monitoring information of systems and NSFs including traffic flows related to security attacks and system resource usages. On the other hand, IPFIX [RFC7011] is a standard method to collect general information on traffic flows rather than security. 6.3. NSF Events The NSF events provide the event that is detected by a specific NSF that supported a certain capability. This section only discusses the monitoring data for the advanced NSFs discussed in [I-D.ietf-i2nsf-capability-data-model]. The NSF events information can be extended to support other types of NSF. NSF events have the following characteristics: * acquisition-method: subscription Jeong, et al. Expires 3 December 2022 [Page 16] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 * emission-type: on-change * dampening-type: on-repetition or no-dampening 6.3.1. DDoS Detection The following information should be included in a Denial-of-Service (DoS) or Distributed Denial-of-Service (DDoS) Event: * event-name: detection-ddos. * attack-type: The type of DoS or DDoS Attack, i.e., SYN flood, ACK flood, SYN-ACK flood, FIN/RST flood, TCP Connection flood, UDP flood, ICMP flood, HTTPS flood, HTTP flood, DNS query flood, DNS reply flood, SIP flood, TLS flood, and NTP amplification flood. This can be extended with additional types of DoS or DDoS attack. * attack-src-ip: The IP addresses of the source of the DDoS attack. Note that not all IP addresses should be included but only limited IP addresses are included to conserve the server resources. The listed attacking IP addresses can be an arbitrary sampling of the "top talkers", i.e., the attackers that send the highest amount of traffic. * attack-dst-ip: The destination IPv4 or IPv6 addresses of attack traffic. It can hold multiple IPv4 or IPv6 addresses. * attack-src-port: The transport layer source port numbers of the attack traffic. Note that not all ports will have been seen on all the corresponding source IP addresses. * attack-dst-port: The transport layer destination port numbers that the attack traffic aims at. Note that not all ports will have been seen on all the corresponding destination IP addresses. * start-time: The time stamp indicating when the attack started. The time format used is following the rules in Section 5.6 of [RFC3339]. * end-time: The time stamp indicating when the attack ended. If the attack is still ongoing when sending out the notification, this field can be empty. The time format used is following the rules in Section 5.6 of [RFC3339]. * attack-rate: The packets per second of attack traffic. * attack-throughput: The bytes per second of attack traffic. Jeong, et al. Expires 3 December 2022 [Page 17] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 * rule-name: The name of the I2NSF Policy Rule being triggered. Note that rule-name is used to match a detected NSF event with a policy rule in [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 6.3.2. Virus Event This information is used when a virus is detected within a traffic flow or inside a host. Note that "malware" is a more generic word for malicious software, including virus and worm. In the document, "virus" is used to represent "malware" such that they are interchangeable. The following information should be included in a Virus Event: * event-name: detection-virus. * virus-name: Name of the virus. * virus-type: Type of the virus. e.g., trojan, worm, and macro virus. * The following information is used only when the virus is detected within the traffic flow and not yet attacking the host: - dst-ip: The destination IP address of the flow where the virus is found. - src-ip: The source IP address of the flow where the virus is found. - src-port: The source port of the flow where the virus is found. - dst-port: The destination port of the flow where the virus is found. * The following information is used only when the virus is detected within a host system: - host: The name or IP address of the host/device that is infected by the virus. If the given name is not an IP address, the name can be an arbitrary string including a FQDN (Fully Qualified Domain Name). The name MUST be unique in the scope of management domain for identifying the device that has been infected with a virus. - os: The operating system of the host that has the virus. - file-type: The type of file (indicated by the file's suffix, e.g., .exe) virus code is found in (if applicable). Jeong, et al. Expires 3 December 2022 [Page 18] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 - file-name: The name of the file where the virus is hidden. * rule-name: The name of the rule being triggered. Note "host" is used only when the virus is detected within a host itself. Thus, the traffic flow information such as the source and destination IP addresses is not important, so the elements of the traffic flow (i.e., dst-ip, src-ip, src-port, and dst-port) are not specified above. On the other hand, when the virus is detected within a traffic flow and not yet attacking a host, the element of "host" is not specified above. 6.3.3. Intrusion Event The following information should be included in an Intrusion Event: * event-name: detection-intrusion. * attack-type: Attack type, e.g., brutal force or buffer overflow. * src-ip: The source IP address of the flow. * dst-ip: The destination IP address of the flow. * src-port: The source port number of the flow. * dst-port: The destination port number of the flow * protocol: The employed transport layer protocol. e.g., TCP or UDP. Note that QUIC protocol [RFC9000] is excluded in the data model as it is not considered in the initial I2NSF documents [RFC8329]. The QUIC traffic should not be treated as generic UDP traffic and will be considered in the future I2NSF documents. * app: The employed application layer protocol. e.g., HTTP or FTP. * rule-name: The name of the I2NSF Policy Rule being triggered. 6.3.4. Web Attack Event The following information should be included in a Web Attack Alarm: * event-name: detection-web-attack. * attack-type: Concrete web attack type. e.g., SQL injection, command injection, XSS, or CSRF. * src-ip: The source IP address of the packet. Jeong, et al. Expires 3 December 2022 [Page 19] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 * dst-ip: The destination IP address of the packet. * src-port: The source port number of the packet. * dst-port: The destination port number of the packet. * req-method: The HTTP method of the request. For instance, "PUT" and "GET" in HTTP. * req-target: The HTTP Request Target. * response-code: The HTTP Response status code. * cookies: The HTTP Cookie header field of the request from the user agent. Note that though cookies have many historical infelicities that degrade security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet [RFC6265]. Thus, the cookies information needs to be kept confidential and is NOT RECOMMENDED to be included in the monitoring data unless the information is absolutely necessary to help to enhance the security of the network. * req-host: The HTTP Host header field of the request. * filtering-type: URL filtering type. e.g., deny-list, allow-list, and unknown. * rule-name: The name of the I2NSF Policy Rule being triggered. 6.3.5. VoIP/VoCN Event The following information should be included in a VoIP (Voice over Internet Protocol) and VoCN (Voice over Cellular Network, such as Voice over LTE or 5G) Event: * event-name: detection-voip-vocn * source-voice-id: The detected source voice Call ID for VoIP and VoCN that violates the policy. * destination-voice-id: The destination voice Call ID for VoIP and VoCN that violates the policy. * user-agent: The user agent for VoIP and VoCN that violates the policy. * src-ip: The source IP address of the VoIP/VoCN. Jeong, et al. Expires 3 December 2022 [Page 20] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 * dst-ip: The destination IP address of the VoIP/VoCN. * src-port: The source port number of the VoIP/VoCN. * dst-port: The destination port number of VoIP/VoCN. * rule-name: The name of the I2NSF Policy Rule being triggered. 6.4. System Logs System log is a record that is used to monitor the activity of the user on the NSF and the status of the NSF. System logs have the following characteristics: * acquisition-method: subscription or query * emission-type: on-change or periodic * dampening-type: on-repetition or no-dampening 6.4.1. Access Log Access logs record administrators' login, logout, and operations on a device. By analyzing them, some security vulnerabilities can be identified. The following information should be included in an operation report: * identity: The information to identify the user. The minimum information (extensible) that should be included: 1. user: The unique username that attempted access violation. 2. group: Group(s) to which a user belongs. A user can belong to multiple groups. 3. ip-address: The IP address of the user that triggered the event. 4. l4-port-number: The transport layer port number used by the user. * authentication: The method to verify the valid user, i.e., pre- configured-key and certificate-authority. * operation-type: The operation type that the administrator executed, e.g., login, logout, configuration, and other. Jeong, et al. Expires 3 December 2022 [Page 21] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 * input: The operation performed by a user after login. The operation is a command given by a user. * output: The result after executing the input. 6.4.2. Resource Utilization Log Running reports record the device system's running status, which is useful for device monitoring. The following information should be included in running report: * system-status: The current system's running status. * cpu-usage: Specifies the aggregated CPU usage in percentage. * memory-usage: Specifies the memory usage in percentage. * disk-id: Specifies the disk ID to identify the storage disk. * disk-usage: Specifies the disk usage of disk-id in percentage. * disk-space-left: Specifies the available disk space left of disk- id in percentage. * session-number: Specifies total concurrent sessions. * process-number: Specifies total number of systems processes. * interface-id: Specifies the interface ID to identify the network interface. * in-traffic-rate: The total inbound data plane traffic rate in packets per second. * out-traffic-rate: The total outbound data plane traffic rate in packets per second. * in-traffic-throughput: The total inbound data plane traffic throughput in bytes per second. * out-traffic-throughput: The total outbound data plane traffic throughput in bytes per second. Note that "traffic" includes only the data plane since the monitoring interface focuses on the monitoring of traffic flows for applications, rather than the control plane. In the document, "packet" includes a layer-2 frame, so "packet" and "frame" are interchangeable. Also, note that system resources (e.g., CPU, Jeong, et al. Expires 3 December 2022 [Page 22] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 memory, disk, and interface) are monitored for the sake of security in NSFs even though they are common ones to be monitored by a generic Operations, Administration and Maintenance (OAM) protocol (or module). 6.4.3. User Activity Log User activity logs provide visibility into users' online records (such as login time, online/lockout duration, and login IP addresses) and the actions that users perform. User activity reports are helpful to identify exceptions during a user's login and network access activities. This information should be included in a user's activity report: * identity: The information to identify the user. The minimum information (extensible) that should be included is as follows: 1. user: The unique username that attempted access violation. 2. group: Group(s) to which a user belongs. A user can belong to multiple groups. 3. ip-address: The IP address of the user that triggered the event. 4. l4-port-number: The transport layer port number used by the user. * authentication: The method to verify the valid user, i.e., pre- configured-key and certificate-authority. * online-duration: The duration of a user's activeness (stays in login) during a session. * logout-duration: The duration of a user's inactiveness (not in login) from the last session. * additional-info: Additional Information for login: 1. type: User activities. e.g., Successful User Login, Failed Login attempts, User Logout, Successful User Password Change, Failed User Password Change, User Lockout, and User Unlocking. 2. cause: Cause of a failed user activity. Jeong, et al. Expires 3 December 2022 [Page 23] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 6.5. NSF Logs NSF logs have the folowing characteristics: * acquisition-method: subscription or query * emission-type: on-change * dampening-type: on-repetition or no-dampening 6.5.1. Deep Packet Inspection Log Deep Packet Inspection (DPI) Logs provide statistics of transit traffic at an NSF such that the traffic includes uploaded and downloaded files/data, sent/received emails, and blocking/alert records on websites. It is helpful to learn risky user behaviors and why access to some URLs is blocked or allowed with an alert record. * attack-type: DPI action types. e.g., File Blocking, Data Filtering, and Application Behavior Control. * src-ip: The source IP address of the flow. * dst-ip: The destination IP address of the flow. * src-port: The source port number of the flow. * dst-port: The destination port number of the flow * rule-name: The name of the I2NSF Policy Rule being triggered. * action: Action defined in the file blocking rule, data filtering rule, or application behavior control rule that traffic matches. 6.6. System Counter System counter has the following characteristics: * acquisition-method: subscription or query * emission-type: periodic * dampening-type: no-dampening 6.6.1. Interface Counter Interface counters provide visibility into traffic into and out of an NSF, and bandwidth usage. Jeong, et al. Expires 3 December 2022 [Page 24] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 * interface-name: Network interface name configured in NSF. * protocol: The type of network protocol (e.g., IPv4, IPv6, TCP, and UDP). If this field is empty, then the counter is used for all protocols. * measurement-time: The duration of the measurement in seconds for the calculation of statistics such as traffic rate and throughput. The statistic attributes are measured over the past measurement duration before now. * in-total-traffic-pkts: Total inbound packets. * out-total-traffic-pkts: Total outbound packets. * in-total-traffic-bytes: Total inbound bytes. * out-total-traffic-bytes: Total outbound bytes. * in-drop-traffic-pkts: Total inbound drop packets caused by a policy or hardware/resource error. * out-drop-traffic-pkts: Total outbound drop packets caused by a policy or hardware/resource error. * in-drop-traffic-bytes: Total inbound drop bytes caused by a policy or hardware/resource error. * out-drop-traffic-bytes: Total outbound drop bytes caused by a policy or hardware/resource error. * total-traffic: The total number of traffic packets (in and out) in the NSF. * in-traffic-average-rate: Inbound traffic average rate in packets per second. * in-traffic-peak-rate: Inbound traffic peak rate in packets per second. * in-traffic-average-throughput: Inbound traffic average throughput in bytes per second. * in-traffic-peak-throughput: Inbound traffic peak throughput in bytes per second. * out-traffic-average-rate: Outbound traffic average rate in packets per second. Jeong, et al. Expires 3 December 2022 [Page 25] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 * out-traffic-peak-rate: Outbound traffic peak rate in packets per second. * out-traffic-average-throughput: Outbound traffic average throughput in bytes per second. * out-traffic-peak-throughput: Outbound traffic peak throughput in bytes per second. * discontinuity-time: The time of the most recent occasion at which any one or more of the counters suffered a discontinuity. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this node contains the time the local management subsystem was re- initialized. The time format used is following the rules in Section 5.6 of [RFC3339]. 6.7. NSF Counters NSF counters have the following characteristics: * acquisition-method: subscription or query * emission-type: periodic * dampening-type: no-dampening 6.7.1. Firewall Counter Firewall counters provide visibility into traffic signatures and bandwidth usage that correspond to the policy that is configured in a firewall. * policy-name: Security policy name that traffic matches. * measurement-time: The duration of the measurement in seconds for the calculation of statistics such as traffic rate and throughput. The statistic attributes are measured over the past measurement duration before now. * in-interface: Inbound interface of traffic. * out-interface: Outbound interface of traffic. * total-traffic: The total number of traffic packets (in and out) in the firewall. Jeong, et al. Expires 3 December 2022 [Page 26] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 * in-traffic-average-rate: Inbound traffic average rate in packets per second. * in-traffic-peak-rate: Inbound traffic peak rate in packets per second. * in-traffic-average-throughput: Inbound traffic average throughput in bytes per second. * in-traffic-peak-throughput: Inbound traffic peak throughput in bytes per second. * out-traffic-average-rate: Outbound traffic average rate in packets per second. * out-traffic-peak-rate: Outbound traffic peak rate in packets per second. * out-traffic-average-throughput: Outbound traffic average throughput in bytes per second. * out-traffic-peak-throughput: Outbound traffic peak throughput in bytes per second. * discontinuity-time: The time on the most recent occasion at which any one or more of the counters suffered a discontinuity. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this node contains the time the local management subsystem was re- initialized. The time format used is following the rules in Section 5.6 of [RFC3339]. 6.7.2. Policy Hit Counter Policy hit counters record the security policy that traffic matches and its hit count. That is, when a packet actually matches a policy, it should be added to the statistics of a "policy hit counter" of the policy. The "policy hit counter" provides the "policy-name" that matches the policy's name in the NSF-Facing Interface YANG data model [I-D.ietf-i2nsf-nsf-facing-interface-dm]. It can check if policy configurations are correct or not. * policy-name: Security policy name that traffic matches. * hit-times: The number of times that the security policy matches the specified traffic. Jeong, et al. Expires 3 December 2022 [Page 27] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 * discontinuity-time: The time on the most recent occasion at which any one or more of the counters suffered a discontinuity. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this node contains the time the local management subsystem was re- initialized. The time format used is following the rules in Section 5.6 of [RFC3339]. 7. YANG Tree Structure of NSF Monitoring YANG Module The tree structure of the NSF monitoring YANG module is provided below: module: ietf-i2nsf-monitoring-interface +--ro i2nsf-counters | +--ro vendor-name? string | +--ro device-model? string | +--ro software-version? string | +--ro nsf-name union | +--ro timestamp? yang:date-and-time | +--ro acquisition-method? identityref | +--ro emission-type? identityref | +--ro system-interface* [interface-name] | | +--ro interface-name if:interface-ref | | +--ro protocol? identityref | | +--ro in-total-traffic-pkts? yang:counter64 | | +--ro out-total-traffic-pkts? yang:counter64 | | +--ro in-total-traffic-bytes? uint64 | | +--ro out-total-traffic-bytes? uint64 | | +--ro in-drop-traffic-pkts? yang:counter64 | | +--ro out-drop-traffic-pkts? yang:counter64 | | +--ro in-drop-traffic-bytes? uint64 | | +--ro out-drop-traffic-bytes? uint64 | | +--ro discontinuity-time yang:date-and-time | | +--ro measurement-time? uint32 | | +--ro total-traffic? yang:counter64 | | +--ro in-traffic-average-rate? uint64 | | +--ro in-traffic-peak-rate? uint64 | | +--ro in-traffic-average-throughput? uint64 | | +--ro in-traffic-peak-throughput? uint64 | | +--ro out-traffic-average-rate? uint64 | | +--ro out-traffic-peak-rate? uint64 | | +--ro out-traffic-average-throughput? uint64 | | +--ro out-traffic-peak-throughput? uint64 | +--ro nsf-firewall* [policy-name] | | +--ro in-interface? if:interface-ref | | +--ro out-interface? if:interface-ref | | +--ro policy-name -> /i2nsfnfi:i2nsf-security-policy/name Jeong, et al. Expires 3 December 2022 [Page 28] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 | | +--ro discontinuity-time yang:date-and-time | | +--ro measurement-time? uint32 | | +--ro total-traffic? yang:counter64 | | +--ro in-traffic-average-rate? uint64 | | +--ro in-traffic-peak-rate? uint64 | | +--ro in-traffic-average-throughput? uint64 | | +--ro in-traffic-peak-throughput? uint64 | | +--ro out-traffic-average-rate? uint64 | | +--ro out-traffic-peak-rate? uint64 | | +--ro out-traffic-average-throughput? uint64 | | +--ro out-traffic-peak-throughput? uint64 | +--ro nsf-policy-hits* [policy-name] | +--ro policy-name -> /i2nsfnfi:i2nsf-security-policy/name | +--ro discontinuity-time yang:date-and-time | +--ro hit-times? yang:counter64 +--rw i2nsf-monitoring-configuration +--rw i2nsf-system-detection-alarm | +--rw enabled? boolean | +--rw system-alarm* [alarm-type] | +--rw alarm-type enumeration | +--rw threshold? uint8 | +--rw dampening-period? centiseconds +--rw i2nsf-system-detection-event | +--rw enabled? boolean | +--rw dampening-period? centiseconds +--rw i2nsf-traffic-flows | +--rw dampening-period? centiseconds | +--rw enabled? boolean +--rw i2nsf-nsf-detection-ddos {i2nsf-nsf-detection-ddos}? | +--rw enabled? boolean | +--rw dampening-period? centiseconds +--rw i2nsf-nsf-detection-virus {i2nsf-nsf-detection-virus}? | +--rw enabled? boolean | +--rw dampening-period? centiseconds +--rw i2nsf-nsf-detection-session-table | +--rw enabled? boolean | +--rw dampening-period? centiseconds +--rw i2nsf-nsf-detection-intrusion {i2nsf-nsf-detection-intrusion}? | +--rw enabled? boolean | +--rw dampening-period? centiseconds +--rw i2nsf-nsf-detection-web-attack {i2nsf-nsf-detection-web-attack}? | +--rw enabled? boolean | +--rw dampening-period? centiseconds +--rw i2nsf-nsf-detection-voip-vocn {i2nsf-nsf-detection-voip-vocn}? | +--rw enabled? boolean Jeong, et al. Expires 3 December 2022 [Page 29] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 | +--rw dampening-period? centiseconds +--rw i2nsf-nsf-system-access-log | +--rw enabled? boolean | +--rw dampening-period? centiseconds +--rw i2nsf-system-res-util-log | +--rw enabled? boolean | +--rw dampening-period? centiseconds +--rw i2nsf-system-user-activity-log | +--rw enabled? boolean | +--rw dampening-period? centiseconds +--rw i2nsf-nsf-log-dpi {i2nsf-nsf-log-dpi}? | +--rw enabled? boolean | +--rw dampening-period? centiseconds +--rw i2nsf-counter +--rw period? uint16 notifications: +---n i2nsf-event | +--ro vendor-name? string | +--ro device-model? string | +--ro software-version? string | +--ro nsf-name union | +--ro message? string | +--ro language? string | +--ro acquisition-method? identityref | +--ro emission-type? identityref | +--ro dampening-type? identityref | +--ro (sub-event-type)? | +--:(i2nsf-system-detection-alarm) | | +--ro i2nsf-system-detection-alarm | | +--ro alarm-category? identityref | | +--ro component-name? string | | +--ro interface-name? if:interface-ref | | +--ro interface-state? enumeration | | +--ro severity? severity | | +--ro usage? uint8 | | +--ro threshold? uint8 | +--:(i2nsf-system-detection-event) | | +--ro i2nsf-system-detection-event | | +--ro event-category? identityref | | +--ro user string | | +--ro group* string | | +--ro ip-address inet:ip-address-no-zone | | +--ro l4-port-number inet:port-number | | +--ro authentication? identityref | | +--ro changes* [policy-name] | | +--ro policy-name -> /i2nsfnfi:i2nsf-security-policy/name Jeong, et al. Expires 3 December 2022 [Page 30] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 | +--:(i2nsf-traffic-flows) | | +--ro i2nsf-traffic-flows | | +--ro interface-name? if:interface-ref | | +--ro interface-type? enumeration | | +--ro src-mac? yang:mac-address | | +--ro dst-mac? yang:mac-address | | +--ro src-ip? inet:ip-address-no-zone | | +--ro dst-ip? inet:ip-address-no-zone | | +--ro protocol? identityref | | +--ro src-port? inet:port-number | | +--ro dst-port? inet:port-number | | +--ro measurement-time? uint32 | | +--ro arrival-rate? uint64 | | +--ro arrival-throughput? uint64 | +--:(i2nsf-nsf-detection-session-table) | +--ro i2nsf-nsf-detection-session-table | +--ro current-session? uint32 | +--ro maximum-session? uint32 | +--ro threshold? uint32 +---n i2nsf-log | +--ro vendor-name? string | +--ro device-model? string | +--ro software-version? string | +--ro nsf-name union | +--ro message? string | +--ro language? string | +--ro acquisition-method? identityref | +--ro emission-type? identityref | +--ro dampening-type? identityref | +--ro (sub-logs-type)? | +--:(i2nsf-nsf-system-access-log) | | +--ro i2nsf-nsf-system-access-log | | +--ro user string | | +--ro group* string | | +--ro ip-address inet:ip-address-no-zone | | +--ro l4-port-number inet:port-number | | +--ro authentication? identityref | | +--ro operation-type? operation-type | | +--ro input? string | | +--ro output? string | +--:(i2nsf-system-res-util-log) | | +--ro i2nsf-system-res-util-log | | +--ro system-status? enumeration | | +--ro cpu-usage? uint8 | | +--ro memory-usage? uint8 | | +--ro disks* [disk-id] | | | +--ro disk-id string | | | +--ro disk-usage? uint8 Jeong, et al. Expires 3 December 2022 [Page 31] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 | | | +--ro disk-space-left? uint8 | | +--ro session-num? uint32 | | +--ro process-num? uint32 | | +--ro interface* [interface-id] | | +--ro interface-id string | | +--ro in-traffic-rate? uint64 | | +--ro out-traffic-rate? uint64 | | +--ro in-traffic-throughput? uint64 | | +--ro out-traffic-throughput? uint64 | +--:(i2nsf-system-user-activity-log) | | +--ro i2nsf-system-user-activity-log | | +--ro user string | | +--ro group* string | | +--ro ip-address inet:ip-address-no-zone | | +--ro l4-port-number inet:port-number | | +--ro authentication? identityref | | +--ro online-duration? uint32 | | +--ro logout-duration? uint32 | | +--ro additional-info | | +--ro type? enumeration | | +--ro cause? string | +--:(i2nsf-nsf-log-dpi) {i2nsf-nsf-log-dpi}? | +--ro i2nsf-nsf-log-dpi | +--ro attack-type? identityref | +--ro src-ip? inet:ip-address-no-zone | +--ro src-port? inet:port-number | +--ro dst-ip? inet:ip-address-no-zone | +--ro dst-port? inet:port-number | +--ro rule-name -> /i2nsfnfi:i2nsf-security-policy/rules/name | +--ro action* identityref +---n i2nsf-nsf-event +--ro vendor-name? string +--ro device-model? string +--ro software-version? string +--ro nsf-name union +--ro message? string +--ro language? string +--ro acquisition-method? identityref +--ro emission-type? identityref +--ro dampening-type? identityref +--ro (sub-event-type)? +--:(i2nsf-nsf-detection-ddos) {i2nsf-nsf-detection-ddos}? | +--ro i2nsf-nsf-detection-ddos | +--ro attack-type? identityref | +--ro start-time yang:date-and-time | +--ro end-time? yang:date-and-time | +--ro attack-src-ip* inet:ip-address-no-zone Jeong, et al. Expires 3 December 2022 [Page 32] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 | +--ro attack-dst-ip* inet:ip-address-no-zone | +--ro attack-src-port* inet:port-number | +--ro attack-dst-port* inet:port-number | +--ro rule-name -> /i2nsfnfi:i2nsf-security-policy/rules/name | +--ro attack-rate? uint64 | +--ro attack-throughput? uint64 +--:(i2nsf-nsf-detection-virus) {i2nsf-nsf-detection-virus}? | +--ro i2nsf-nsf-detection-virus | +--ro src-ip? inet:ip-address-no-zone | +--ro src-port? inet:port-number | +--ro dst-ip? inet:ip-address-no-zone | +--ro dst-port? inet:port-number | +--ro rule-name -> /i2nsfnfi:i2nsf-security-policy/rules/name | +--ro virus-name? string | +--ro virus-type? identityref | +--ro host? union | +--ro file-type? string | +--ro file-name? string | +--ro os? string +--:(i2nsf-nsf-detection-intrusion) {i2nsf-nsf-detection-intrusion}? | +--ro i2nsf-nsf-detection-intrusion | +--ro src-ip? inet:ip-address-no-zone | +--ro src-port? inet:port-number | +--ro dst-ip? inet:ip-address-no-zone | +--ro dst-port? inet:port-number | +--ro rule-name -> /i2nsfnfi:i2nsf-security-policy/rules/name | +--ro protocol? identityref | +--ro app? identityref | +--ro attack-type? identityref +--:(i2nsf-nsf-detection-web-attack) {i2nsf-nsf-detection-web-attack}? | +--ro i2nsf-nsf-detection-web-attack | +--ro src-ip? inet:ip-address-no-zone | +--ro src-port? inet:port-number | +--ro dst-ip? inet:ip-address-no-zone | +--ro dst-port? inet:port-number | +--ro rule-name -> /i2nsfnfi:i2nsf-security-policy/rules/name | +--ro attack-type? identityref | +--ro req-method? identityref | +--ro req-target? string | +--ro filtering-type* identityref | +--ro cookies? string Jeong, et al. Expires 3 December 2022 [Page 33] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 | +--ro req-host? string | +--ro response-code? string +--:(i2nsf-nsf-detection-voip-vocn) {i2nsf-nsf-detection-voip-vocn}? +--ro i2nsf-nsf-detection-voip-vocn +--ro src-ip? inet:ip-address-no-zone +--ro src-port? inet:port-number +--ro dst-ip? inet:ip-address-no-zone +--ro dst-port? inet:port-number +--ro rule-name -> /i2nsfnfi:i2nsf-security-policy/rules/name +--ro source-voice-id* string +--ro destination-voice-id* string +--ro user-agent* string Figure 1: NSF Monitoring YANG Module Tree 8. YANG Data Model of NSF Monitoring YANG Module This section describes a YANG module of I2NSF NSF Monitoring. The data model provided in this document uses identities to be used to get information of the monitored of an NSF's monitoring data. Every identity used in the document gives information or status about the current situation of an NSF. This YANG module imports from [RFC6991], [RFC8343], and [I-D.ietf-i2nsf-nsf-facing-interface-dm], and makes references to [RFC0768] [RFC0791] [RFC0792] [RFC0826] [RFC0854] [RFC1939] [RFC0959] [RFC2595] [RFC4340] [RFC4443] [RFC4861] [RFC5321] [RFC5646] [RFC6242] [RFC6265] [RFC8200] [RFC8641] [RFC9051] [I-D.ietf-httpbis-http2bis] [I-D.ietf-httpbis-messaging] [I-D.ietf-httpbis-semantics] [I-D.ietf-tcpm-rfc793bis] [I-D.ietf-tsvwg-rfc4960-bis] [IANA-HTTP-Status-Code] [IEEE-802.1AB] file "ietf-i2nsf-monitoring-interface@2022-06-01.yang" module ietf-i2nsf-monitoring-interface { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-monitoring-interface"; prefix i2nsfmi; import ietf-inet-types { prefix inet; reference "Section 4 of RFC 6991"; } import ietf-yang-types { prefix yang; reference Jeong, et al. Expires 3 December 2022 [Page 34] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 "Section 3 of RFC 6991"; } import ietf-i2nsf-nsf-facing-interface { prefix i2nsfnfi; reference "Section 4.1 of draft-ietf-i2nsf-nsf-facing-interface-dm-29"; } import ietf-interfaces { prefix if; reference "Section 5 of RFC 8343"; } organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact "WG Web: WG List: Editor: Jaehoon Paul Jeong Editor: Patrick Lingga "; description "This module is a YANG module for I2NSF NSF Monitoring. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; Jeong, et al. Expires 3 December 2022 [Page 35] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 revision "2022-06-01" { description "Latest revision"; reference "RFC XXXX: I2NSF NSF Monitoring Interface YANG Data Model"; // RFC Ed.: replace XXXX with an actual RFC number and remove // this note. } /* * Typedefs */ typedef severity { type enumeration { enum critical { description "The 'critical' severity level indicates that an immediate corrective action is required. A 'critical' severity is reported when a service becomes totally out of service and must be restored."; } enum high { description "The 'high' severity level indicates that an urgent corrective action is required. A 'high' severity is reported when there is a severe degradation in the capability of the service and its full capability must be restored."; } enum middle { description "The 'middle' severity level indicates the existence of a non-service-affecting fault condition and corrective action should be done to prevent a more serious fault. The 'middle' severity is reported when the detected problem is not degrading the capability of the service, but some service degradation might happen if not prevented."; } enum low { description "The 'low' severity level indicates the detection of a potential fault before any effect is observed. The 'low' severity is reported when an action should be done before a fault happen."; } Jeong, et al. Expires 3 December 2022 [Page 36] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 } description "An indicator representing severity levels. The severity levels starting from the highest are critical, high, middle, and low."; } typedef operation-type { type enumeration { enum login { description "The operation type is Login."; } enum logout { description "The operation type is Logout."; } enum configuration { description "The operation type is Configuration. The configuration operation includes the command for writing a new configuration and modifying an existing configuration."; } enum other { description "The operation type is Other operation. This other includes all operations done by a user except login, logout, and configuration."; } } description "The type of operation done by a user during a session. The user operation is not considering their privileges."; } typedef login-role { type enumeration { enum administrator { description "Administrator (i.e., Superuser)'s login role. Non-restricted role."; } enum user { description "User login role. Semi-restricted role, some data and configurations are available but confidential or important data and configuration are restricted."; } Jeong, et al. Expires 3 December 2022 [Page 37] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 enum guest { description "Guest login role. Restricted role, only few read data are available and write configurations are restricted."; } } description "The privilege level of the user account."; } typedef centiseconds { type uint32; description "A period of time, measured in units of 0.01 seconds."; } /* * Identity */ identity characteristics { description "Base identity for monitoring information characteristics"; } identity acquisition-method { base characteristics; description "The type of acquisition-method. It can be multiple types at once."; } identity subscription { base acquisition-method; description "The acquisition-method type is subscription."; } identity query { base acquisition-method; description "The acquisition-method type is query."; } identity emission-type { base characteristics; description "The type of emission-type."; } identity periodic { base emission-type; Jeong, et al. Expires 3 December 2022 [Page 38] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 description "The emission-type type is periodic."; } identity on-change { base emission-type; description "The emission-type type is on-change."; } identity dampening-type { base characteristics; description "The type of message dampening to stop the rapid transmission of messages, such as on-repetition and no-dampening."; } identity no-dampening { base dampening-type; description "The dampening-type is no-dampening. No-dampening type does not limit the transmission for the messages of the same type."; } identity on-repetition { base dampening-type; description "The dampening-type is on-repetition. On-repetition type limits the transmitted on-change message to one message at a certain interval."; } identity authentication-mode { description "The authentication mode for a user to connect to the NSF, e.g., pre-configured-key and certificate-authority"; } identity pre-configured-key { base authentication-mode; description "The pre-configured-key is an authentication using a key authentication."; } identity certificate-authority { base authentication-mode; description "The certificate-authority (CA) is an authentication using a digital certificate."; } identity event { Jeong, et al. Expires 3 December 2022 [Page 39] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 description "Base identity for I2NSF events."; } identity system-event { base event; description "Identity for system event"; } identity system-alarm { base event; description "Base identity for detectable system alarm types"; } identity memory-alarm { base system-alarm; description "Memory is the hardware to store information temporarily or for a short period, i.e., Random Access Memory (RAM). A memory-alarm is emitted when the memory usage is exceeding the threshold."; } identity cpu-alarm { base system-alarm; description "CPU is the Central Processing Unit that executes basic operations of the system. A cpu-alarm is emitted when the CPU usage is exceeding a threshold."; } identity disk-alarm { base system-alarm; description "Disk or storage is the hardware to store information for a long period, i.e., Hard Disk and Solid-State Drive. A disk-alarm is emitted when the disk usage is exceeding a threshold."; } identity hardware-alarm { base system-alarm; description "A hardware alarm is emitted when a hardware failure (e.g., CPU, memory, disk, or interface) is detected. A hardware failure is a malfunction within the electronic circuits or electromechanical components of the hardware that makes it unusable."; } Jeong, et al. Expires 3 December 2022 [Page 40] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 identity interface-alarm { base system-alarm; description "Interface is the network interface for connecting a device with the network. The interface-alarm is emitted when the state of the interface is changed."; } identity access-violation { base system-event; description "Access-violation system event is an event when a user tries to access (read, write, create, or delete) any information or execute commands above their privilege (i.e., not-conformant with the access profile)."; } identity configuration-change { base system-event; description "The configuration-change system event is an event when a user adds a new configuration or modify an existing configuration (write configuration)."; } identity attack-type { description "The root ID of attack-based notification in the notification taxonomy"; } identity nsf-attack-type { base attack-type; description "This ID is intended to be used in the context of NSF event."; } identity virus-type { base nsf-attack-type; description "The type of virus. It can be multiple types at once. This attack type is associated with a detected system-log virus-attack."; } identity trojan { base virus-type; description "The virus type is a trojan. Trojan is able to disguise the intent of the files or programs to misleads the users."; Jeong, et al. Expires 3 December 2022 [Page 41] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 } identity worm { base virus-type; description "The virus type is a worm. Worm can self-replicate and spread through the network automatically."; } identity macro { base virus-type; description "The virus type is a macro virus. Macro causes a series of threats automatically after the program is executed."; } identity boot-sector { base virus-type; description "The virus type is a boot sector virus. Boot sector is a virus that infects the core of the computer, affecting the startup process."; } identity polymorphic { base virus-type; description "The virus type is a polymorphic virus. Polymorphic can modify its version when it replicates, making it hard to detect."; } identity overwrite { base virus-type; description "The virus type is an overwrite virus. Overwrite can remove existing software and replace it with malicious code by overwriting it."; } identity resident { base virus-type; description "The virus-type is a resident virus. Resident saves itself in the computer's memory and infects other files and software."; } identity non-resident { base virus-type; description "The virus-type is a non-resident virus. Non-resident attaches directly to an executable file and enters the device when executed."; } identity multipartite { Jeong, et al. Expires 3 December 2022 [Page 42] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 base virus-type; description "The virus-type is a multipartite virus. Multipartite attacks both the boot sector and executables files of a computer."; } identity spacefiller { base virus-type; description "The virus-type is a spacefiller virus. Spacefiller fills empty spaces of a file or software with malicious code."; } identity intrusion-attack-type { base nsf-attack-type; description "The attack type is associated with a detected system-log intrusion."; } identity brute-force { base intrusion-attack-type; description "The intrusion type is brute-force."; } identity buffer-overflow { base intrusion-attack-type; description "The intrusion type is buffer-overflow."; } identity web-attack-type { base nsf-attack-type; description "The attack type is associated with a detected system-log web-attack."; } identity command-injection { base web-attack-type; description "The detected web attack type is command injection."; } identity xss { base web-attack-type; description "The detected web attack type is Cross Site Scripting (XSS)."; } identity csrf { base web-attack-type; description "The detected web attack type is Cross Site Request Forgery."; Jeong, et al. Expires 3 December 2022 [Page 43] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 } identity ddos-type { base nsf-attack-type; description "Base identity for detectable flood types"; } identity syn-flood { base ddos-type; description "A SYN flood is detected."; } identity ack-flood { base ddos-type; description "An ACK flood is detected."; } identity syn-ack-flood { base ddos-type; description "A SYN-ACK flood is detected."; } identity fin-rst-flood { base ddos-type; description "A FIN-RST flood is detected."; } identity tcp-con-flood { base ddos-type; description "A TCP connection flood is detected."; } identity udp-flood { base ddos-type; description "A UDP flood is detected."; } identity icmpv4-flood { base ddos-type; description "An ICMPv4 flood is detected."; } identity icmpv6-flood { base ddos-type; description "An ICMPv6 flood is detected."; } identity http-flood { Jeong, et al. Expires 3 December 2022 [Page 44] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 base ddos-type; description "An HTTP flood is detected."; } identity https-flood { base ddos-type; description "An HTTPS flood is detected."; } identity dns-query-flood { base ddos-type; description "A Domain Name System (DNS) query flood is detected."; } identity dns-reply-flood { base ddos-type; description "A Domain Name System (DNS) reply flood is detected."; } identity sip-flood { base ddos-type; description "A Session Initiation Protocol (SIP) flood is detected."; } identity tls-flood { base ddos-type; description "A Transport Layer Security (TLS) flood is detected"; } identity ntp-amp-flood { base ddos-type; description "A Network Time Protocol (NTP) amplification is detected"; } identity req-method { description "A set of request types in HTTP (if applicable)."; } identity put { base req-method; description "The detected request type is PUT."; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics - Request Method PUT"; } identity post { Jeong, et al. Expires 3 December 2022 [Page 45] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 base req-method; description "The detected request type is POST."; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics - Request Method POST"; } identity get { base req-method; description "The detected request type is GET."; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics - Request Method GET"; } identity head { base req-method; description "The detected request type is HEAD."; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics - Request Method HEAD"; } identity delete { base req-method; description "The detected request type is DELETE."; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics - Request Method DELETE"; } identity connect { base req-method; description "The detected request type is CONNECT."; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics - Request Method CONNECT"; } identity options { base req-method; description "The detected request type is OPTIONS."; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics - Request Method OPTIONS"; } identity trace { Jeong, et al. Expires 3 December 2022 [Page 46] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 base req-method; description "The detected request type is TRACE."; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics - Request Method TRACE"; } identity filter-type { description "The type of filter used to detect an attack, for example, a web-attack. It can be applicable to more than web-attacks."; } identity allow-list { base filter-type; description "The applied filter type is an allow list. This filter blocks all connection except the specified list."; } identity deny-list { base filter-type; description "The applied filter type is a deny list. This filter opens all connection except the specified list."; } identity unknown-filter { base filter-type; description "The applied filter is unknown."; } identity dpi-type { description "Base identity for the type of Deep Packet Inspection (DPI)."; } identity file-blocking { base dpi-type; description "DPI for preventing the specified file types from flowing in the network."; } identity data-filtering { base dpi-type; description "DPI for preventing sensitive information (e.g., Credit Card Number or Social Security Numbers) leaving a protected network."; Jeong, et al. Expires 3 December 2022 [Page 47] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 } identity application-behavior-control { base dpi-type; description "DPI for filtering packet based on the application or network behavior analysis to identify malicious or unusual activity."; } identity protocol { description "An identity used to enable type choices in leaves and leaf-lists with respect to protocol metadata. This is used to identify the type of protocol that goes through the NSF."; } identity ip { base protocol; description "General IP protocol type."; reference "RFC 791: Internet Protocol RFC 8200: Internet Protocol, Version 6 (IPv6)"; } identity ipv4 { base ip; description "IPv4 protocol type."; reference "RFC 791: Internet Protocol"; } identity ipv6 { base ip; description "IPv6 protocol type."; reference "RFC 8200: Internet Protocol, Version 6 (IPv6)"; } identity icmp { base protocol; description "Base identity for ICMPv4 and ICMPv6 condition capability"; reference "RFC 792: Internet Control Message Protocol RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification - ICMPv6"; } identity icmpv4 { Jeong, et al. Expires 3 December 2022 [Page 48] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 base icmp; description "ICMPv4 protocol type."; reference "RFC 791: Internet Protocol RFC 792: Internet Control Message Protocol"; } identity icmpv6 { base icmp; description "ICMPv6 protocol type."; reference "RFC 8200: Internet Protocol, Version 6 (IPv6) RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"; } identity transport-protocol { base protocol; description "Base identity for Layer 4 protocol condition capabilities, e.g., TCP, UDP, SCTP, DCCP, and ICMP"; } identity tcp { base transport-protocol; description "TCP protocol type."; reference "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol (TCP) Specification"; } identity udp { base transport-protocol; description "UDP protocol type."; reference "RFC 768: User Datagram Protocol"; } identity sctp { base transport-protocol; description "Identity for SCTP condition capabilities"; reference "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission Protocol"; } identity dccp { base transport-protocol; Jeong, et al. Expires 3 December 2022 [Page 49] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 description "Identity for DCCP condition capabilities"; reference "RFC 4340: Datagram Congestion Control Protocol"; } identity application-protocol { base protocol; description "Base identity for Application protocol. Note that a subset of application protocols (e.g., HTTP, HTTPS, FTP, POP3, and IMAP) are handled in this YANG module, rather than all the existing application protocols."; } identity http { base application-protocol; description "The identity for Hypertext Transfer Protocol version 1.1 (HTTP/1.1)."; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics draft-ietf-httpbis-messaging-19: HTTP/1.1"; } identity https { base application-protocol; description "The identity for Hypertext Transfer Protocol version 1.1 (HTTP/1.1) over TLS."; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics draft-ietf-httpbis-messaging-19: HTTP/1.1"; } identity http2 { base application-protocol; description "The identity for Hypertext Transfer Protocol version 2 (HTTP/2)."; reference "draft-ietf-httpbis-http2bis-07: HTTP/2"; } identity https2 { base application-protocol; description "The identity for Hypertext Transfer Protocol version 2 (HTTP/2) over TLS."; reference "draft-ietf-httpbis-http2bis-07: HTTP/2"; } identity ftp { Jeong, et al. Expires 3 December 2022 [Page 50] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 base application-protocol; description "FTP protocol type."; reference "RFC 959: File Transfer Protocol"; } identity ssh { base application-protocol; description "SSH protocol type."; reference "RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)"; } identity telnet { base application-protocol; description "The identity for telnet."; reference "RFC 854: Telnet Protocol"; } identity smtp { base application-protocol; description "The identity for smtp."; reference "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; } identity pop3 { base application-protocol; description "The identity for Post Office Protocol 3 (POP3)."; reference "RFC 1939: Post Office Protocol - Version 3 (POP3)"; } identity pop3s { base application-protocol; description "The identity for Post Office Protocol 3 (POP3) over TLS"; reference "RFC 1939: Post Office Protocol - Version 3 (POP3) RFC 2595: Using TLS with IMAP, POP3 and ACAP"; } identity imap { base application-protocol; description "The identity for Internet Message Access Protocol (IMAP)."; reference "RFC 9051: Internet Message Access Protocol (IMAP) - Version Jeong, et al. Expires 3 December 2022 [Page 51] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 4rev2"; } identity imaps { base application-protocol; description "The identity for Internet Message Access Protocol (IMAP) over TLS"; reference "RFC 9051: Internet Message Access Protocol (IMAP) - Version 4rev2 RFC 2595: Using TLS with IMAP, POP3 and ACAP"; } /* * Grouping */ grouping timestamp { description "Grouping for identifying the time of the message."; leaf timestamp { type yang:date-and-time; description "Specify the time of a message being delivered."; } } grouping message { description "A set of common monitoring data that is needed as the basic information."; leaf message { type string; description "This is a freetext annotation for monitoring a notification's content."; } leaf language { type string { pattern '((([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})' + '{0,2})?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})?' + '(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}' + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WYZa-wyz]' + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]' + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|' + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-' + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-' + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-' Jeong, et al. Expires 3 December 2022 [Page 52] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]' + '|[Ii]-[Hh][Aa][Kk]|' + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|' + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|' + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|' + '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|' + '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|' + '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-' + '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-' + '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-' + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|' + '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-' + '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|' + '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-' + '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-' + '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))'; } default "en-US"; description "The value in this field indicates the language tag used for the human readable fields (i.e., '../message', '/i2nsf-log/i2nsf-nsf-system-access-log/output', and '/i2nsf-log/i2nsf-system-user-activity-log/additional-info /cause'). The attribute is encoded following the rules in Section 2.1 in RFC 5646. The default language tag is 'en-US'"; reference "RFC 5646: Tags for Identifying Languages"; } } grouping common-monitoring-data { description "A set of common monitoring data that is needed as the basic information."; leaf vendor-name { type string; description "The name of the NSF vendor. The string is unrestricted to identify the provider or vendor of the NSF."; } leaf device-model { type string; description "The model of the device, can be represented by the device model name or serial number. This field is used to identify the model of the device that provides the security Jeong, et al. Expires 3 December 2022 [Page 53] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 service."; } leaf software-version { type string; description "The version of the software used to provide the security service"; } leaf nsf-name { type union { type string; type inet:ip-address-no-zone; } mandatory true; description "The name or IP address of the NSF generating the message. If the given nsf-name is not an IP address, the name can be an arbitrary string including a FQDN (Fully Qualified Domain Name). The name MUST be unique in the scope of management domain for a different NSF to identify the NSF that generates the message."; } } grouping characteristics { description "A set of characteristics of a monitoring information."; leaf acquisition-method { type identityref { base acquisition-method; } description "The acquisition-method for characteristics"; } leaf emission-type { when "derived-from-or-self(../acquisition-method, " + "'i2nsfmi:subscription')"; type identityref { base emission-type; } description "The emission-type for characteristics. This attribute is used only when the acquisition-method is a 'subscription'"; } } grouping characteristics-extended { description "An extended characteristics for the monitoring information."; uses characteristics; Jeong, et al. Expires 3 December 2022 [Page 54] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 leaf dampening-type { type identityref { base dampening-type; } description "The dampening-type for characteristics"; } } grouping i2nsf-system-alarm-type-content { description "A set of contents for alarm type notification."; leaf usage { type uint8 { range "0..100"; } units "percent"; description "Specifies the used percentage"; } leaf threshold { type uint8 { range "0..100"; } units "percent"; description "The threshold percentage triggering the alarm or the event"; } } grouping i2nsf-system-event-type-content { description "System event metadata associated with system events caused by user activity. This can be extended to provide additional information."; leaf user { type string; mandatory true; description "The name of a user"; } leaf-list group { type string; min-elements 1; description "The group(s) to which a user belongs."; } leaf ip-address { type inet:ip-address-no-zone; Jeong, et al. Expires 3 December 2022 [Page 55] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 mandatory true; description "The IPv4 or IPv6 address of a user that trigger the event."; } leaf l4-port-number { type inet:port-number; mandatory true; description "The transport layer port number used by the user."; } leaf authentication { type identityref { base authentication-mode; } description "The authentication-mode of a user."; } } grouping i2nsf-nsf-event-type-content { description "A set of common IPv4 or IPv6-related NSF event content elements"; leaf dst-ip { type inet:ip-address-no-zone; description "The destination IPv4 or IPv6 address of the packet"; } leaf dst-port { type inet:port-number; description "The destination port of the packet"; } leaf rule-name { type leafref { path "/i2nsfnfi:i2nsf-security-policy" +"/i2nsfnfi:rules/i2nsfnfi:name"; } mandatory true; description "The name of the I2NSF Policy Rule being triggered"; } } grouping i2nsf-nsf-event-type-content-extend { description "A set of extended common IPv4 or IPv6 related NSF event content elements"; Jeong, et al. Expires 3 December 2022 [Page 56] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 leaf src-ip { type inet:ip-address-no-zone; description "The source IPv4 or IPv6 address of the packet or flow"; } leaf src-port { type inet:port-number; description "The source port of the packet or flow"; } uses i2nsf-nsf-event-type-content; } grouping action { description "A grouping for action."; leaf-list action { type identityref { base i2nsfnfi:ingress-action; } description "Action type: pass, drop, reject, mirror, or rate limit"; } } grouping attack-rates { description "A set of traffic rates for monitoring attack traffic data"; leaf attack-rate { type uint64; units "pps"; description "The average packets per second (pps) rate of attack traffic"; } leaf attack-throughput { type uint64; units "Bps"; description "The average bytes per second (Bps) throughput of attack traffic"; } } grouping traffic-rates { description "A set of traffic rates for statistics data"; leaf discontinuity-time { type yang:date-and-time; mandatory true; Jeong, et al. Expires 3 December 2022 [Page 57] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 description "The time on the most recent occasion at which any one or more of the counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem was re-initialized."; } leaf measurement-time { type uint32; units "seconds"; description "The time of the measurement in seconds for the calculation of statistics such as traffic rate and throughput. The statistic attributes are measured over the past measurement duration before now."; } leaf total-traffic { type yang:counter64; units "packets"; description "The total number of traffic packets (in and out) in the NSF."; } leaf in-traffic-average-rate { type uint64; units "pps"; description "Inbound traffic average rate in packets per second (pps). The average is calculated from the start of the NSF service until the generation of this record."; } leaf in-traffic-peak-rate { type uint64; units "pps"; description "Inbound traffic peak rate in packets per second (pps)."; } leaf in-traffic-average-throughput { type uint64; units "Bps"; description "Inbound traffic average throughput in bytes per second (Bps). The average is calculated from the start of the NSF service until the generation of this record."; } leaf in-traffic-peak-throughput { type uint64; Jeong, et al. Expires 3 December 2022 [Page 58] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 units "Bps"; description "Inbound traffic peak throughput in bytes per second (Bps)."; } leaf out-traffic-average-rate { type uint64; units "pps"; description "Outbound traffic average rate in packets per second (pps). The average is calculated from the start of the NSF service until the generation of this record."; } leaf out-traffic-peak-rate { type uint64; units "pps"; description "Outbound traffic peak rate in packets per second (pps)."; } leaf out-traffic-average-throughput { type uint64; units "Bps"; description "Outbound traffic average throughput in bytes per second (Bps). The average is calculated from the start of the NSF service until the generation of this record."; } leaf out-traffic-peak-throughput { type uint64; units "Bps"; description "Outbound traffic peak throughput in bytes per second (Bps)."; } } grouping i2nsf-system-counter-type-content { description "A set of counters for an interface traffic data."; leaf interface-name { type if:interface-ref; description "Network interface name configured in an NSF"; reference "RFC 8343: A YANG Data Model for Interface Management"; } leaf protocol { type identityref { base protocol; } Jeong, et al. Expires 3 December 2022 [Page 59] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 description "The type of network protocol for the interface counter. If this field is empty, then the counter includes all protocols (e.g., IPv4, IPv6, TCP, and UDP)"; } leaf in-total-traffic-pkts { type yang:counter64; description "Total inbound packets"; } leaf out-total-traffic-pkts { type yang:counter64; description "Total outbound packets"; } leaf in-total-traffic-bytes { type uint64; units "bytes"; description "Total inbound bytes"; } leaf out-total-traffic-bytes { type uint64; units "bytes"; description "Total outbound bytes"; } leaf in-drop-traffic-pkts { type yang:counter64; description "Total inbound drop packets"; } leaf out-drop-traffic-pkts { type yang:counter64; description "Total outbound drop packets"; } leaf in-drop-traffic-bytes { type uint64; units "bytes"; description "Total inbound drop bytes"; } leaf out-drop-traffic-bytes { type uint64; units "bytes"; description "Total outbound drop bytes"; Jeong, et al. Expires 3 December 2022 [Page 60] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 } uses traffic-rates; } grouping i2nsf-nsf-counters-type-content { description "A set of contents of a policy in an NSF."; leaf policy-name { type leafref { path "/i2nsfnfi:i2nsf-security-policy" +"/i2nsfnfi:name"; } mandatory true; description "The name of the policy being triggered"; } } grouping enable-notification { description "A grouping for enabling or disabling notification"; leaf enabled { type boolean; default "true"; description "Enables or Disables the notification. If 'true', then the notification is enabled. If 'false, then the notification is disabled."; } } grouping dampening { description "A grouping for dampening period of notification."; leaf dampening-period { type centiseconds; default "0"; description "Specifies the minimum interval between the assembly of successive update records for a single receiver of a subscription. Whenever subscribed objects change and a dampening-period interval (which may be zero) has elapsed since the previous update record creation for a receiver, any subscribed objects and properties that have changed since the previous update record will have their current values marshalled and placed in a new update record. But if the subscribed objects change Jeong, et al. Expires 3 December 2022 [Page 61] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 when the dampening-period is active, it should update the record without sending the notification until the dampening- period is finished. If multiple changes happen during the active dampening-period, it should update the record with the latest data. And at the end of the dampening-period, it should send the record as a notification with the latest updated record and restart the countdown."; reference "RFC 8641: Subscription to YANG Notifications for Datastore Updates - Section 5."; } } /* * Feature Nodes */ feature i2nsf-nsf-detection-ddos { description "This feature means it supports I2NSF nsf-detection-ddos notification"; } feature i2nsf-nsf-detection-virus { description "This feature means it supports I2NSF nsf-detection-virus notification"; } feature i2nsf-nsf-detection-intrusion { description "This feature means it supports I2NSF nsf-detection-intrusion notification"; } feature i2nsf-nsf-detection-web-attack { description "This feature means it supports I2NSF nsf-detection-web-attack notification"; } feature i2nsf-nsf-detection-voip-vocn { description "This feature means it supports I2NSF nsf-detection-voip-vocn notification"; } feature i2nsf-nsf-log-dpi { description "This feature means it supports I2NSF nsf-log-dpi notification"; } Jeong, et al. Expires 3 December 2022 [Page 62] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 /* * Notification nodes */ notification i2nsf-event { description "Notification for I2NSF Event. This notification provides general information that can be supported by most types of NSFs."; uses common-monitoring-data; uses message; uses characteristics-extended; choice sub-event-type { description "This choice must be augmented with cases for each allowed sub-event. Only 1 sub-event will be instantiated in each i2nsf-event message. Each case is expected to define one container with all the sub-event fields."; case i2nsf-system-detection-alarm { container i2nsf-system-detection-alarm { description "This notification is sent, when a system alarm is detected."; leaf alarm-category { type identityref { base system-alarm; } description "The alarm category for system-detection-alarm notification"; } leaf component-name { type string; description "The hardware component responsible for generating the message. Applicable for Hardware Failure Alarm."; } leaf interface-name { when "derived-from-or-self(../alarm-category, " + "'i2nsfmi:interface-alarm')"; type if:interface-ref; description "The interface name responsible for generating the message. Applicable for Network Interface Failure Alarm."; Jeong, et al. Expires 3 December 2022 [Page 63] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 reference "RFC 8343: A YANG Data Model for Interface Management"; } leaf interface-state { when "derived-from-or-self(../alarm-category, " + "'i2nsfmi:interface-alarm')"; type enumeration { enum up { value 1; description "The interface state is up and not congested. The interface is ready to pass packets."; } enum down { value 2; description "The interface state is down, i.e., does not pass any packets."; } enum congested { value 3; description "The interface state is up but congested."; } enum testing { value 4; description "In some test mode. No operational packets can be passed."; } enum unknown { value 5; description "Status cannot be determined for some reason."; } enum dormant { value 6; description "Waiting for some external event."; } enum not-present { value 7; description "Some component (typically hardware) is missing."; } enum lower-layer-down { value 8; description Jeong, et al. Expires 3 December 2022 [Page 64] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 "Down due to state of lower-layer interface(s)."; } } description "The state of the interface. Applicable for Network Interface Failure Alarm."; reference "RFC 8343: A YANG Data Model for Interface Management - Operational States"; } leaf severity { type severity; description "The severity of the alarm such as critical, high, middle, and low."; } uses i2nsf-system-alarm-type-content; } } case i2nsf-system-detection-event { container i2nsf-system-detection-event { description "This notification is sent when an event in the system is detected, such as access violation and configuration change"; leaf event-category { type identityref { base system-event; } description "The event category for system-detection-event"; } uses i2nsf-system-event-type-content; list changes { when "derived-from-or-self(../event-category, " + "'i2nsfmi:configuration-change')"; key policy-name; description "Describes the modification that was made to the configuration. This list is only applicable when the event is 'configuration-change'. The minimum information that must be provided is the name of the policy that has been altered (added, modified, or removed). This list can be extended with the detailed information about the specific changes made to the configuration based on the implementation."; Jeong, et al. Expires 3 December 2022 [Page 65] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 leaf policy-name { type leafref { path "/i2nsfnfi:i2nsf-security-policy" +"/i2nsfnfi:name"; } description "The name of the policy configuration that has been added, modified, or removed."; } } } } case i2nsf-traffic-flows { container i2nsf-traffic-flows { description "This notification is sent to inform about the traffic flows."; leaf interface-name { type if:interface-ref; description "The mnemonic name of the network interface"; } leaf interface-type { type enumeration { enum ingress { description "The corresponding interface-name indicates an ingress interface."; } enum egress { description "The corresponding interface-name indicates an egress interface."; } } description "The type of a network interface such as an ingress or egress interface."; } leaf src-mac { type yang:mac-address; description "The source MAC address of the traffic flow. This information may or may not be included depending on the type of traffic flow. For example, the information will be useful and should be included if the traffic Jeong, et al. Expires 3 December 2022 [Page 66] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 flows are traffic flows of Link Layer Discovery Protocol (LLDP), Address Resolution Protocol (ARP) for IPv4, and Neighbor Discovery Protocol (ND) for IPv6."; reference "IEEE-802.1AB: IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery - Link Layer Discovery Protocol (LLDP) RFC 826: An Ethernet Address Resolution Protocol - Address Resolution Protocol (ARP) RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - Neighbor Discovery Protocol (ND)"; } leaf dst-mac { type yang:mac-address; description "The destination MAC address of the traffic flow. This information may or may not be included depending on the type of traffic flow. For example, the information will be useful and should be included if the traffic flows are traffic flows of Link Layer Discovery Protocol (LLDP), Address Resolution Protocol (ARP) for IPv4, and Neighbor Discovery Protocol (ND) for IPv6."; reference "IEEE-802.1AB: IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery - Link Layer Discovery Protocol (LLDP) RFC 826: An Ethernet Address Resolution Protocol - Address Resolution Protocol (ARP) RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - Neighbor Discovery Protocol (ND)"; } leaf src-ip { type inet:ip-address-no-zone; description "The source IPv4 or IPv6 address of the traffic flow"; } leaf dst-ip { type inet:ip-address-no-zone; description "The destination IPv4 or IPv6 address of the traffic flow"; } leaf protocol { type identityref { base protocol; } Jeong, et al. Expires 3 December 2022 [Page 67] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 description "The protocol type of a traffic flow"; } leaf src-port { type inet:port-number; description "The transport layer source port number of the flow"; } leaf dst-port { type inet:port-number; description "The transport layer destination port number of the flow"; } leaf measurement-time { type uint32; units "seconds"; description "The duration of the measurement in seconds for the arrival rate and arrival throughput of packets of a traffic flow. These two metrics (i.e., arrival rate and arrival throughput) are measured over the past measurement duration before now."; } leaf arrival-rate { type uint64; units "pps"; description "The arrival rate of packets of the traffic flow in packets per second measured over the past 'measurement-time'."; } leaf arrival-throughput { type uint64; units "Bps"; description "The arrival rate of packets of the traffic flow in bytes per second measured over the past 'measurement-time'."; } } } case i2nsf-nsf-detection-session-table { container i2nsf-nsf-detection-session-table { description "This notification is sent, when a session table event is detected."; Jeong, et al. Expires 3 December 2022 [Page 68] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 leaf current-session { type uint32; description "The number of concurrent sessions"; } leaf maximum-session { type uint32; description "The maximum number of sessions that the session table can support"; } leaf threshold { type uint32; description "The threshold triggering the event"; } } } } } notification i2nsf-log { description "Notification for I2NSF log. The notification is generated from the logs of the NSF."; uses common-monitoring-data; uses message; uses characteristics-extended; choice sub-logs-type { description "This choice must be augmented with cases for each allowed sub-logs. Only 1 sub-event will be instantiated in each i2nsf-logs message. Each case is expected to define one container with all the sub-logs fields."; case i2nsf-nsf-system-access-log { container i2nsf-nsf-system-access-log { description "The notification is sent, if there is a new system log entry about a system access event."; uses i2nsf-system-event-type-content; leaf operation-type { type operation-type; description "The operation type that the user executes"; } leaf input { Jeong, et al. Expires 3 December 2022 [Page 69] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 type string; description "The operation performed by a user after login. The operation is a command given by a user."; } leaf output { type string; description "The result in text format after executing the input."; } } } case i2nsf-system-res-util-log { container i2nsf-system-res-util-log { description "This notification is sent, if there is a new log entry representing resource utilization updates."; leaf system-status { type enumeration { enum running { description "The system is active and running the security service."; } enum waiting { description "The system is active but waiting for an event to provide the security service."; } enum inactive { description "The system is inactive and not running the security service."; } } description "The current system's running status"; } leaf cpu-usage { type uint8; units "percent"; description "Specifies the relative percentage of CPU utilization with respect to platform resources"; } leaf memory-usage { Jeong, et al. Expires 3 December 2022 [Page 70] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 type uint8; units "percent"; description "Specifies the percentage of memory usage."; } list disks { key disk-id; description "Disk is the hardware to store information for a long period, i.e., Hard Disk or Solid-State Drive."; leaf disk-id { type string; description "The ID of the storage disk. It is a free form identifier to identify the storage disk."; } leaf disk-usage { type uint8; units "percent"; description "Specifies the percentage of disk usage"; } leaf disk-space-left { type uint8; units "percent"; description "Specifies the percentage of disk space left"; } } leaf session-num { type uint32; description "The total number of sessions"; } leaf process-num { type uint32; description "The total number of processes"; } list interface { key interface-id; description "The network interface for connecting a device with the network."; leaf interface-id { type string; description "The ID of the network interface. It is a free form Jeong, et al. Expires 3 December 2022 [Page 71] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 identifier to identify the network interface."; } leaf in-traffic-rate { type uint64; units "pps"; description "The total inbound traffic rate in packets per second"; } leaf out-traffic-rate { type uint64; units "pps"; description "The total outbound traffic rate in packets per second"; } leaf in-traffic-throughput { type uint64; units "Bps"; description "The total inbound traffic throughput in bytes per second"; } leaf out-traffic-throughput { type uint64; units "Bps"; description "The total outbound traffic throughput in bytes per second"; } } } } case i2nsf-system-user-activity-log { container i2nsf-system-user-activity-log { description "This notification is sent, if there is a new user activity log entry."; uses i2nsf-system-event-type-content; leaf online-duration { type uint32; units "seconds"; description "The duration of a user's activeness (stays in login) during a session."; } leaf logout-duration { Jeong, et al. Expires 3 December 2022 [Page 72] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 type uint32; units "seconds"; description "The duration of a user's inactiveness (not in login) from the last session."; } container additional-info { leaf type { type enumeration { enum successful-login { description "The user has succeeded in login."; } enum failed-login { description "The user has failed in login (e.g., wrong password)"; } enum logout { description "The user has succeeded in logout"; } enum successful-password-changed { description "The password has been changed successfully"; } enum failed-password-changed { description "The attempt to change password has failed"; } enum lock { description "The user has been locked. A locked user cannot login."; } enum unlock { description "The user has been unlocked."; } } description "User activities, e.g., Successful User Login, Failed Login attempts, User Logout, Successful User Password Change, Failed User Password Change, User Lockout, User Unlocking, and Unknown."; } leaf cause { type string; Jeong, et al. Expires 3 December 2022 [Page 73] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 description "The cause of a failed user activity related to the type of user activity. For example, when the 'type' is failed-login, the value of this attribute can be 'Failed login attempt due to wrong password entry'."; } description "The additional information about user activity."; } } } case i2nsf-nsf-log-dpi { if-feature "i2nsf-nsf-log-dpi"; container i2nsf-nsf-log-dpi { description "This notification is sent, if there is a new DPI event in the NSF log."; leaf attack-type { type identityref { base dpi-type; } description "The type of the DPI"; } uses i2nsf-nsf-event-type-content-extend; uses action; } } } } notification i2nsf-nsf-event { description "Notification for I2NSF NSF Event. This notification provides specific information that can only be provided by an NSF that supports additional features (e.g., DDoS attack detection)."; uses common-monitoring-data; uses message; uses characteristics-extended; choice sub-event-type { description "This choice must be augmented with cases for each allowed sub-event. Only 1 sub-event will be instantiated in each i2nsf-event message. Each case is expected to define one Jeong, et al. Expires 3 December 2022 [Page 74] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 container with all the sub-event fields."; case i2nsf-nsf-detection-ddos { if-feature "i2nsf-nsf-detection-ddos"; container i2nsf-nsf-detection-ddos { description "This notification is sent, when a specific flood type is detected."; leaf attack-type { type identityref { base ddos-type; } description "Any one of Syn flood, ACK flood, SYN-ACK flood, FIN/RST flood, TCP Connection flood, UDP flood, ICMP (i.e., ICMPv4 or ICMPv6) flood, HTTP flood, HTTPS flood, DNS query flood, DNS reply flood, SIP flood, etc."; } leaf start-time { type yang:date-and-time; mandatory true; description "The time stamp indicating when the attack started"; } leaf end-time { type yang:date-and-time; description "The time stamp indicating when the attack ended. If the attack is still undergoing when sending out the notification, this field can be omitted."; } leaf-list attack-src-ip { type inet:ip-address-no-zone; description "The source IPv4 or IPv6 addresses of attack traffic. It can hold multiple IPv4 or IPv6 addresses. Note that all IP addresses should not be included, but only limited IP addresses are included to conserve the server resources. The listed attacking IP addresses can be an arbitrary sampling of the 'top talkers', i.e., the attackers that send the highest amount of traffic."; } leaf-list attack-dst-ip { type inet:ip-address-no-zone; description "The destination IPv4 or IPv6 addresses of attack traffic. It can hold multiple IPv4 or IPv6 Jeong, et al. Expires 3 December 2022 [Page 75] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 addresses."; } leaf-list attack-src-port { type inet:port-number; description "The transport-layer source ports of the DDoS attack. Note that not all ports will have been seen on all the corresponding source IP addresses."; } leaf-list attack-dst-port { type inet:port-number; description "The transport-layer destination ports of the DDoS attack. Note that not all ports will have been seen on all the corresponding destination IP addresses."; } leaf rule-name { type leafref { path "/i2nsfnfi:i2nsf-security-policy" +"/i2nsfnfi:rules/i2nsfnfi:name"; } mandatory true; description "The name of the I2NSF Policy Rule being triggered"; } uses attack-rates; } } case i2nsf-nsf-detection-virus { if-feature "i2nsf-nsf-detection-virus"; container i2nsf-nsf-detection-virus { description "This notification is sent, when a virus is detected."; uses i2nsf-nsf-event-type-content-extend; leaf virus-name { type string; description "The name of the detected virus"; } leaf virus-type { type identityref { base virus-type; } description "The virus type of the detected virus"; } Jeong, et al. Expires 3 December 2022 [Page 76] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 leaf host { type union { type string; type inet:ip-address-no-zone; } description "The name or IP address of the host/device. This is used to identify the host/device that is infected by the virus. If the given name is not an IP address, the name can be an arbitrary string including a FQDN (Fully Qualified Domain Name). The name MUST be unique in the scope of management domain for identifying the device that has been infected with a virus."; } leaf file-type { type string; description "The type of a file (indicated by the file's suffix, e.g., .exe) where virus code is found (if applicable)."; } leaf file-name { type string; description "The name of file virus code is found in (if applicable)."; } leaf os { type string; description "The operating system of the device."; } } } case i2nsf-nsf-detection-intrusion { if-feature "i2nsf-nsf-detection-intrusion"; container i2nsf-nsf-detection-intrusion { description "This notification is sent, when an intrusion event is detected."; uses i2nsf-nsf-event-type-content-extend; leaf protocol { type identityref { base transport-protocol; } description "The transport protocol type for nsf-detection-intrusion notification"; Jeong, et al. Expires 3 December 2022 [Page 77] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 } leaf app { type identityref { base application-protocol; } description "The employed application layer protocol"; } leaf attack-type { type identityref { base intrusion-attack-type; } description "The sub attack type for intrusion attack"; } } } case i2nsf-nsf-detection-web-attack { if-feature "i2nsf-nsf-detection-web-attack"; container i2nsf-nsf-detection-web-attack { description "This notification is sent, when an attack event is detected."; uses i2nsf-nsf-event-type-content-extend; leaf attack-type { type identityref { base web-attack-type; } description "Concrete web attack type, e.g., SQL injection, command injection, XSS, and CSRF."; } leaf req-method { type identityref { base req-method; } description "The HTTP method of the request, e.g., PUT or GET."; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics - Request Methods"; } leaf req-target { type string; description "The HTTP Request Target. This field can be filled in the format of origin-form, absolute-form, authority-form, or asterisk-form"; Jeong, et al. Expires 3 December 2022 [Page 78] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 reference "draft-ietf-httpbis-messaging-19: HTTP/1.1 - Request Target"; } leaf-list filtering-type { type identityref { base filter-type; } description "URL filtering type, e.g., deny-list, allow-list, and Unknown"; } leaf cookies { type string; description "The HTTP Cookies header field of the request from the user agent. Note that though cookies have many historical infelicities that degrade security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. Thus, the cookie information needs to be kept confidential and is NOT RECOMMENDED to be included in the monitoring data unless the information is absolutely necessary to help to enhance the security of the network."; reference "RFC 6265: HTTP State Management Mechanism - Cookie"; } leaf req-host { type string; description "The HTTP Host header field of the request"; reference "draft-ietf-httpbis-semantics-19: HTTP Semantics - Host"; } leaf response-code { type string; description "The HTTP Response status code"; reference "IANA Website: Hypertext Transfer Protocol (HTTP) Status Code Registry"; } } } case i2nsf-nsf-detection-voip-vocn { if-feature "i2nsf-nsf-detection-voip-vocn"; container i2nsf-nsf-detection-voip-vocn { description Jeong, et al. Expires 3 December 2022 [Page 79] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 "This notification is sent, when a VoIP/VoCN violation is detected."; uses i2nsf-nsf-event-type-content-extend; leaf-list source-voice-id { type string; description "The detected source voice ID for VoIP and VoCN that violates the security policy."; } leaf-list destination-voice-id { type string; description "The detected destination voice ID for VoIP and VoCN that violates the security policy."; } leaf-list user-agent { type string; description "The detected user-agent for VoIP and VoCN that violates the security policy."; } } } } } /* * Data nodes */ container i2nsf-counters { config false; description "The state data representing continuous value changes of information elements that occur very frequently. The value should be calculated from the start of the service of the NSF."; uses common-monitoring-data; uses timestamp; uses characteristics; list system-interface { key interface-name; description "Interface counters provide the visibility of traffic into and out of an NSF, and bandwidth usage."; uses i2nsf-system-counter-type-content; } list nsf-firewall { Jeong, et al. Expires 3 December 2022 [Page 80] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 key policy-name; description "Firewall counters provide visibility into traffic signatures and bandwidth usage that correspond to the policy that is configured in a firewall."; leaf in-interface { type if:interface-ref; description "Inbound interface of the traffic"; } leaf out-interface { type if:interface-ref; description "Outbound interface of the traffic"; } uses i2nsf-nsf-counters-type-content; uses traffic-rates; } list nsf-policy-hits { key policy-name; description "Policy hit counters record the number of hits that traffic packets match a security policy. It can check if policy configurations are correct or not."; uses i2nsf-nsf-counters-type-content; leaf discontinuity-time { type yang:date-and-time; mandatory true; description "The time on the most recent occasion at which any one or more of the counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem was re-initialized."; } leaf hit-times { type yang:counter64; description "The number of times that the security policy matches the specified traffic."; } } } container i2nsf-monitoring-configuration { description "The container for configuring I2NSF monitoring."; Jeong, et al. Expires 3 December 2022 [Page 81] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 container i2nsf-system-detection-alarm { description "The container for configuring I2NSF system-detection-alarm notification"; uses enable-notification; list system-alarm { key alarm-type; description "Configuration for system alarm (i.e., CPU, Memory, and Disk Usage)"; leaf alarm-type { type enumeration { enum cpu { description "To configure the CPU usage threshold to trigger the cpu-alarm"; } enum memory { description "To configure the Memory usage threshold to trigger the memory-alarm"; } enum disk { description "To configure the Disk (storage) usage threshold to trigger the disk-alarm"; } } description "Type of alarm to be configured. The three alarm-types defined here are used to configure the threshold of the monitoring notification. The threshold is used to determine when the notification should be sent. The other two alarms defined in the module (i.e., hardware-alarm and interface-alarm) do not use any threshold value to create a notification. These alarms detect a failure or a change of state to create a notification."; } leaf threshold { type uint8 { range "1..100"; } units "percent"; description "The configuration for threshold percentage to trigger the alarm. The alarm will be triggered if the usage is exceeded the threshold."; Jeong, et al. Expires 3 December 2022 [Page 82] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 } uses dampening; } } container i2nsf-system-detection-event { description "The container for configuring I2NSF system-detection-event notification"; uses enable-notification; uses dampening; } container i2nsf-traffic-flows { description "The container for configuring I2NSF traffic-flows notification"; uses dampening; uses enable-notification; } container i2nsf-nsf-detection-ddos { if-feature "i2nsf-nsf-detection-ddos"; description "The container for configuring I2NSF nsf-detection-ddos notification"; uses enable-notification; uses dampening; } container i2nsf-nsf-detection-virus { if-feature "i2nsf-nsf-detection-virus"; description "The container for configuring I2NSF nsf-detection-virus notification"; uses enable-notification; uses dampening; } container i2nsf-nsf-detection-session-table { description "The container for configuring I2NSF nsf-detection-session- table notification"; uses enable-notification; uses dampening; } container i2nsf-nsf-detection-intrusion { if-feature "i2nsf-nsf-detection-intrusion"; description "The container for configuring I2NSF nsf-detection-intrusion notification"; uses enable-notification; uses dampening; Jeong, et al. Expires 3 December 2022 [Page 83] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 } container i2nsf-nsf-detection-web-attack { if-feature "i2nsf-nsf-detection-web-attack"; description "The container for configuring I2NSF nsf-detection-web-attack notification"; uses enable-notification; uses dampening; } container i2nsf-nsf-detection-voip-vocn { if-feature "i2nsf-nsf-detection-voip-vocn"; description "The container for configuring I2NSF nsf-detection-voip-vocn notification"; uses enable-notification; uses dampening; } container i2nsf-nsf-system-access-log { description "The container for configuring I2NSF system-access-log notification"; uses enable-notification; uses dampening; } container i2nsf-system-res-util-log { description "The container for configuring I2NSF system-res-util-log notification"; uses enable-notification; uses dampening; } container i2nsf-system-user-activity-log { description "The container for configuring I2NSF system-user-activity-log notification"; uses enable-notification; uses dampening; } container i2nsf-nsf-log-dpi { if-feature "i2nsf-nsf-log-dpi"; description "The container for configuring I2NSF nsf-log-dpi notification"; uses enable-notification; uses dampening; } container i2nsf-counter { description Jeong, et al. Expires 3 December 2022 [Page 84] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 "This is used to configure the counters for monitoring an NSF"; leaf period { type uint16; units "minutes"; default 0; description "The configuration for the period interval of reporting the counter. If 0, then the counter period is disabled. If value is not 0, then the counter will be reported following the period value."; } } } } Figure 2: Data Model of Monitoring 9. I2NSF Event Stream This section discusses the NETCONF event stream for an I2NSF NSF Monitoring subscription. The YANG module in this document supports "ietf-subscribed-notifications" YANG module [RFC8639] for subscription. The reserved event stream name for this document is "I2NSF-Monitoring". The NETCONF Server (e.g., an NSF) MUST support "I2NSF-Monitoring" event stream for an NSF data collector (e.g., Security Controller). The "I2NSF-Monitoring" event stream contains all I2NSF events described in this document. The following XML example shows the capabilities of the event streams generated by an NSF (e.g., "NETCONF" and "I2NSF-Monitoring" event streams) for the subscription of an NSF data collector. Refer to [RFC5277] for more detailed explanation of Event Streams. The XML examples in this document follow the line breaks as per [RFC8792]. Jeong, et al. Expires 3 December 2022 [Page 85] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 NETCONF Default NETCONF Event Stream false I2NSF-Monitoring I2NSF Monitoring Event Stream true 2021-04-29T09:37:39+00:00 Figure 3: Example of NETCONF Server supporting I2NSF-Monitoring Event Stream 10. XML Examples for I2NSF NSF Monitoring This section shows XML examples of I2NSF NSF Monitoring data delivered via Monitoring Interface from an NSF. The XML examples are following the guidelines from [RFC6241] [RFC7950]. 10.1. I2NSF System Detection Alarm The following example shows an alarm triggered by Memory Usage on the server; this example XML file is delivered by an NSF to an NSF data collector: Jeong, et al. Expires 3 December 2022 [Page 86] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 2021-04-29T07:43:52.181088+00:00 subscription on-change on-repetition en-US memory-alarm 91 90 Memory Usage Exceeded the Threshold time_based_firewall high Figure 4: Example of I2NSF System Detection Alarm triggered by Memory Usage The XML data above shows: 1. The NSF that sends the information is named "time_based_firewall". 2. The memory usage of the NSF triggered the alarm. 3. The monitoring information is received by subscription method. 4. The monitoring information is emitted "on-change". 5. The monitoring information is dampened "on-repetition". 6. The memory usage of the NSF is 91 percent. 7. The memory threshold to trigger the alarm is 90 percent. 8. The severity level of the notification is high. Jeong, et al. Expires 3 December 2022 [Page 87] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 10.2. I2NSF Interface Counters To get the I2NSF system interface counters information by query, NETCONF Client (e.g., NSF data collector) needs to initiate GET connection with NETCONF Server (e.g., NSF). The following XML file can be used to get the state data and filter the information. Figure 5: XML Example for NETCONF GET with System Interface Filter The following XML file shows the reply from the NETCONF Server (e.g., NSF): Jeong, et al. Expires 3 December 2022 [Page 88] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 query 2021-04-29T08:43:52.181088+00:00 ens3 549050 814956 0 5078 time_based_firewall 2021-04-29T08:43:52.181088+00:00 lo 48487 48487 0 0 time_based_firewall Figure 6: Example of I2NSF System Interface Counters XML Information 11. IANA Considerations This document requests IANA to register the following URI in the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-monitoring-interface Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950][RFC8525]: Jeong, et al. Expires 3 December 2022 [Page 89] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 name: ietf-i2nsf-monitoring-interface namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-monitoring-interface prefix: i2nsfmi reference: RFC XXXX // RFC Ed.: replace XXXX with an actual RFC number and remove // this note. 12. Security Considerations The YANG module described in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the required secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the required secure transport is TLS [RFC8446]. The NETCONF access control model [RFC8341] provides a means of restricting access by specific NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. All data nodes defined in the YANG module which can be created, modified and deleted (i.e., config true, which is the default) are considered sensitive as they all could potentially impact security monitoring and mitigation activities. Write operations (e.g., edit- config) applied to these data nodes without proper protection could result in missed alarms or incorrect alarms information being returned to the NSF data collector. The following are threats that need to be considered and mitigated: Compromised NSF with valid credentials: It can send falsified information to the NSF data collector to mislead detection or mitigation activities; and/or to hide activity. Currently, there is no in-framework mechanism to mitigate this and it is an issue for all monitoring infrastructures. It is important to keep confidential information from unauthorized persons to mitigate the possibility of compromising the NSF with this information. Compromised NSF data collector with valid credentials: It has visibility to all collected security alarms; the entire detection and mitigation infrastructure may be suspect. It is important to keep confidential information from unauthorized persons to mitigate the possibility of compromising the NSF with this information. Impersonating NSF: This involves a system trying to send false Jeong, et al. Expires 3 December 2022 [Page 90] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 information while imitating an NSF; client authentication would help the NSF data collector to identify this invalid NSF in the "push" model (NSF-to-collector), while the "pull" model (collector-to-NSF) should already be addressed with the authentication. Impersonating NSF data collector: This is a rogue NSF data collector with which a legitimate NSF is tricked into communicating; for "push" model (NSF-to-collector), it is important to have valid credentials, without which it should not work; for "pull" model (collector-to-NSF), mutual authentication should be used to mitigate the threat. In addition, to defend against the DDoS attack caused by a lot of NSFs sending massive notifications to the NSF data collector, the rate limiting or similar mechanisms should be considered in both an NSF and NSF data collector, whether in advance or just in the process of DDoS attack. All of the readable data nodes in this YANG module may be considered sensitive in some network environments. These data nodes represent information consistent with the logging commonly performed in network and security operations. They may reveal the specific configuration of a network; vulnerabilities in specific systems; and the deployed security controls and their relative efficacy in detecting or mitigating an attack. To an attacker, this information could inform how to (further) compromise the network, evade detection, or confirm whether they have been observed by the network operator. Additionally, many of the data nodes in this YANG module such as containers "i2nsf-system-user-activity-log", "i2nsf-system-detection- event", and "i2nsf-nsf-detection-voip-vocn" are privacy sensitive. They may describe specific or aggregate user activity including associating user names with specific IP addresses; or users with specific network usage. They may also describe the specific commands that were run by users and the resulting output. Any sensitive information in that command input or output will be visible to the NSF data collector and potentially other entities, and care must be taken to protect the confidentiality of such data from unauthorized parties. Jeong, et al. Expires 3 December 2022 [Page 91] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 13. Acknowledgments This document is a product by the I2NSF Working Group (WG) including WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This document took advantage of the review and comments from the following people: Roman Danyliw, Tim Bray (IANA), Kyle Rose (TSV-ART), Dale R. Worley (Gen-ART), Melinda Shore (SecDir), Valery Smyslov (ART-ART), and Tom Petch. The authors sincerely appreciate their sincere efforts and kind help. This work was supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based Security Intelligence Technology Development for the Customized Security Service Provisioning). This work was supported in part by the IITP (2020-0-00395, Standard Development of Blockchain based Network Management Automation Technology). This work was supported in part by the MSIT under the Information Technology Research Center (ITRC) support program (IITP-2021-2017-0-01633) supervised by the IITP. 14. Contributors The following are co-authors of this document: Chaehong Chung - Department of Electronic, Electrical and Computer Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 16419, Republic of Korea, Email: darkhong@skku.edu Jinyong (Tim) Kim - Department of Electronic, Electrical and Computer Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 16419, Republic of Korea, Email: timkim@skku.edu Dongjin Hong - Department of Electronic, Electrical and Computer Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 16419, Republic of Korea, Email: dong.jin@skku.edu Dacheng Zhang - Huawei, Email: dacheng.zhang@huawei.com Yi Wu - Aliababa Group, Email: anren.wy@alibaba-inc.com Rakesh Kumar - Juniper Networks, 1133 Innovation Way, Sunnyvale, CA 94089, USA, Email: rkkumar@juniper.net Anil Lohiya - Juniper Networks, Email: alohiya@juniper.net 15. References Jeong, et al. Expires 3 December 2022 [Page 92] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 15.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1983, . [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, . [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, DOI 10.17487/RFC2595, June 1999, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, DOI 10.17487/RFC3877, September 2004, . Jeong, et al. Expires 3 December 2022 [Page 93] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . Jeong, et al. Expires 3 December 2022 [Page 94] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Jeong, et al. Expires 3 December 2022 [Page 95] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, "YANG Library", RFC 8525, DOI 10.17487/RFC8525, March 2019, . [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, . [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, . [RFC8650] Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and A. Bierman, "Dynamic Subscription to YANG Events and Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, November 2019, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message Access Protocol (IMAP) - Version 4rev2", RFC 9051, DOI 10.17487/RFC9051, August 2021, . [I-D.ietf-httpbis-http2bis] Thomson, M. and C. Benfield, "HTTP/2", Work in Progress, Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January 2022, . [I-D.ietf-httpbis-messaging] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- httpbis-messaging-19, 12 September 2021, . [I-D.ietf-httpbis-semantics] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Semantics", Work in Progress, Internet-Draft, draft-ietf- httpbis-semantics-19, 12 September 2021, . Jeong, et al. Expires 3 December 2022 [Page 96] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 [I-D.ietf-i2nsf-capability-data-model] Hares, S., Jeong, J. P., Kim, J. T., Moskowitz, R., and Q. Lin, "I2NSF Capability YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-i2nsf-capability-data-model-32, 23 May 2022, . [I-D.ietf-i2nsf-nsf-facing-interface-dm] Kim, J. T., Jeong, J. P., Park, J., Hares, S., and Q. Lin, "I2NSF Network Security Function-Facing Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf- i2nsf-nsf-facing-interface-dm-28, 23 May 2022, . [I-D.ietf-tcpm-rfc793bis] Eddy, W. M., "Transmission Control Protocol (TCP) Specification", Work in Progress, Internet-Draft, draft- ietf-tcpm-rfc793bis-28, 7 March 2022, . [I-D.ietf-tsvwg-rfc4960-bis] Stewart, R. R., Tüxen, M., and K. E. E. Nielsen, "Stream Control Transmission Protocol", Work in Progress, Internet-Draft, draft-ietf-tsvwg-rfc4960-bis-19, 5 February 2022, . 15.2. Informative References [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . Jeong, et al. Expires 3 December 2022 [Page 97] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, . [I-D.ietf-i2nsf-consumer-facing-interface-dm] Jeong, J. P., Chung, C., Ahn, T., Kumar, R., and S. Hares, "I2NSF Consumer-Facing Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-i2nsf-consumer- facing-interface-dm-20, 23 May 2022, . [IANA-HTTP-Status-Code] Internet Assigned Numbers Authority (IANA), "Hypertext Transfer Protocol (HTTP) Status Code Registry", September 2018, . [IEEE-802.1AB] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery", March 2016, . Appendix A. Changes from draft-ietf-i2nsf-nsf-monitoring-data-model-19 The following changes are made from draft-ietf-i2nsf-nsf-monitoring- data-model-19: * This version updated a 'leaf language' pattern by adding extra parentheses around "[A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za- z]{3}){0,2})?" and removing a range character '-' between characters 'Y' and 'Z' in "|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WY-Za- wy-z]" as 'Y' is alphabetically adjacent to 'Z'. Authors' Addresses Jaehoon Paul Jeong (editor) Department of Computer Science and Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4957 Jeong, et al. Expires 3 December 2022 [Page 98] Internet-Draft NSF Monitoring Interface YANG Data Model June 2022 Email: pauljeong@skku.edu URI: http://iotlab.skku.edu/people-jaehoon-jeong.php Patrick Lingga Department of Electrical and Computer Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4957 Email: patricklink@skku.edu Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 United States of America Phone: +1-734-604-0332 Email: shares@ndzh.com Liang Frank Xia Huawei 101 Software Avenue, Yuhuatai District Nanjing Jiangsu, China Email: Frank.xialiang@huawei.com Henk Birkholz Fraunhofer Institute for Secure Information Technology Rheinstrasse 75 64295 Darmstadt Germany Email: henk.birkholz@sit.fraunhofer.de Jeong, et al. Expires 3 December 2022 [Page 99] ./draft-ietf-raw-ldacs-14.txt0000644000764400076440000031144414342333271015537 0ustar iustiniustin RAW N. Mäurer, Ed. Internet-Draft T. Gräupl, Ed. Intended status: Informational German Aerospace Center (DLR) Expires: 5 June 2023 C. Schmitt, Ed. Research Institute CODE, UniBwM 2 December 2022 L-band Digital Aeronautical Communications System (LDACS) draft-ietf-raw-ldacs-14 Abstract This document gives an overview of the architecture of the L-band Digital Aeronautical Communications System (LDACS), which provides a secure, scalable and spectrum efficient terrestrial data link for civil aviation. LDACS is a scheduled, reliable multi-application cellular broadband system with support for IPv6. It is part of a larger shift of flight guidance communication moving to IP-based communication. High reliability and availability of IP connectivity over LDACS, as well as security, are therefore essential. The intent of this document is to introduce LDACS to the IETF community, raise awareness on related activities inside and outside of the IETF, and to seek expertise in shaping the shift of aeronautics to IP. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Mäurer, et al. Expires 5 June 2023 [Page 1] Internet-Draft LDACS December 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Motivation and Use Cases . . . . . . . . . . . . . . . . . . 7 3.1. Voice Communications Today . . . . . . . . . . . . . . . 7 3.2. Data Communications Today . . . . . . . . . . . . . . . . 8 4. Provenance and Documents . . . . . . . . . . . . . . . . . . 8 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Advances Beyond the State-of-the-Art . . . . . . . . . . 10 5.1.1. Priorities . . . . . . . . . . . . . . . . . . . . . 10 5.1.2. Security . . . . . . . . . . . . . . . . . . . . . . 10 5.1.3. High Data Rates . . . . . . . . . . . . . . . . . . . 10 5.2. Application . . . . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Air/Ground Multilink . . . . . . . . . . . . . . . . 11 5.2.2. Air/Air Extension for LDACS . . . . . . . . . . . . . 11 5.2.3. Flight Guidance . . . . . . . . . . . . . . . . . . . 12 5.2.4. Business Communications of Airlines . . . . . . . . . 13 5.2.5. LDACS-based Navigation . . . . . . . . . . . . . . . 13 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Characteristics . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. LDACS Access Network . . . . . . . . . . . . . . . . . . 16 7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 16 7.3. LDACS Protocol Stack . . . . . . . . . . . . . . . . . . 17 7.3.1. LDACS Physical Layer . . . . . . . . . . . . . . . . 18 7.3.2. LDACS Data Link Layer . . . . . . . . . . . . . . . . 19 7.3.3. LDACS Sub-Network Layer and Protocol Services . . . . 20 7.4. LDACS Mobility . . . . . . . . . . . . . . . . . . . . . 21 7.5. LDACS Management - Interfaces and Protocols . . . . . . . 21 8. Reliability and Availability . . . . . . . . . . . . . . . . 21 8.1. Below Layer 1 . . . . . . . . . . . . . . . . . . . . . . 22 8.2. Layer 1 and 2 . . . . . . . . . . . . . . . . . . . . . . 22 8.3. Beyond Layer 2 . . . . . . . . . . . . . . . . . . . . . 25 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Security in Wireless Digital Aeronautical Communications . . . . . . . . . . . . . . . . . . . . . 26 9.2. Security in Depth . . . . . . . . . . . . . . . . . . . . 27 9.3. LDACS Security Requirements . . . . . . . . . . . . . . . 27 9.4. LDACS Security Objectives . . . . . . . . . . . . . . . . 28 Mäurer, et al. Expires 5 June 2023 [Page 2] Internet-Draft LDACS December 2022 9.5. LDACS Security Functions . . . . . . . . . . . . . . . . 28 9.6. LDACS Security Architecture . . . . . . . . . . . . . . . 28 9.6.1. Entities . . . . . . . . . . . . . . . . . . . . . . 29 9.6.2. Entity Identification . . . . . . . . . . . . . . . . 29 9.6.3. Entity Authentication and Key Establishment . . . . . 29 9.6.4. Message-in-transit Confidentiality, Integrity and Authenticity . . . . . . . . . . . . . . . . . . . . 30 9.7. Considerations on LDACS Security Impact on IPv6 Operational Security . . . . . . . . . . . . . . . . . . . . . . . . 30 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 12. Normative References . . . . . . . . . . . . . . . . . . . . 31 13. Informative References . . . . . . . . . . . . . . . . . . . 31 Appendix A. Selected Information from DO-350A . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction One of the main pillars of the modern Air Traffic Management (ATM) system is the existence of a communications infrastructure that enables efficient aircraft control and safe aircraft separation in all phases of flight. Current systems are technically mature but suffering from the Very High Frequency (VHF) band's increasing saturation in high-density areas and the limitations posed by analogue radio communications. Therefore, aviation strives for a sustainable modernization of the aeronautical communications infrastructure on the basis of IP. This modernization is realized in two steps: (1) the transition of communications datalinks from analogue to digital technologies and, (2) the introduction of IPv6 based networking protocols [RFC8200] in aeronautical networks [ICAO2015]. Step (1) is realized via ATM communications transitioning from analogue VHF voice [KAMA2010] to more spectrum efficient digital data communication. For terrestrial communications the International Civil Aviation Organization (ICAO)'s Global Air Navigation Plan (GANP) foresees this transition to be realized by the development of the L-band Digital Aeronautical Communications System (LDACS). Since Central Europe has been identified as the area of the world that suffers the most from increased saturation of the VHF band, the initial roll-out of LDACS will likely start there, and continue to other increasingly saturated zones as the East and West Coast of the US and parts of Asia [ICAO2018]. Technically LDACS enables IPv6-based air-ground communication related to aviation safety and regularity of flight [ICAO2015]. Passenger communication and similar services are not supported, since only Mäurer, et al. Expires 5 June 2023 [Page 3] Internet-Draft LDACS December 2022 communications related to "safety and regularity of flight" are permitted in protected aviation frequency bands. The particular challenge is that no additional frequencies can be made available for terrestrial aeronautical communication. It was thus necessary to develop co-existence mechanism/procedures to enable the interference free operation of LDACS in parallel with other aeronautical services/ systems in the protected frequency band. Since LDACS will be used for aircraft guidance, high reliability and availability for IP connectivity over LDACS are essential. LDACS is standardized in ICAO and European Organization for Civil Aviation Equipment (EUROCAE). This document provides information to the IETF community about the aviation industry transition of flight guidance systems from analog to digital, provides context for LDACS relative to related IETF activities [I-D.haindl-lisp-gb-atn], and seeks expertise on realizing reliable IPv6 over LDACS for step (1). This document does not intend to advance LDACS as an IETF standards-track document. Step (2) is a strategy for the worldwide roll-out of IPv6 capable digital aeronautical inter-networking. This is called the Aeronautical Telecommunications Network (ATN)/Internet Protocol Suite (IPS) (hence, ATN/IPS). It is specified in the International Civil Aviation Organization (ICAO) document Doc 9896 [ICAO2015], the Radio Technical Commission for Aeronautics (RTCA) document DO-379 [RTCA2019], the EUROCAE document ED-262 [EURO2019], and the Aeronautical Radio Incorporated (ARINC) document P858 [ARI2021]. LDACS is subject to these regulations since it provides an "access network" - link-layer datalink - to the ATN/IPS. ICAO has chosen IPv6 as basis for the ATN/IPS mostly for historical reasons, since a previous architecture based on ISO/OSI protocols, the ATN/OSI, failed in the marketplace. In the context of safety-related communications, LDACS will play a major role in future ATM. ATN/IPS datalinks will provide diversified terrestrial and space-based connectivity in a multilink concept, called the Future Communications Infrastructure (FCI) [VIR2021]. From a technical point of view the FCI will realize airborne multi- homed IPv6 networks connected to a global ground network via at least two independent communication technologies. This is considered in more detail in related IETF work in progress [I-D.haindl-lisp-gb-atn] [I-D.ietf-rtgwg-atn-bgp]. As such, ICAO has actively sought out the support of IETF to define a mobility solution for step (2), which is currently the Locator/ID Separation Protocol (LISP). Mäurer, et al. Expires 5 June 2023 [Page 4] Internet-Draft LDACS December 2022 In the context of the Reliable and Available Wireless (RAW) working group, developing options, such as intelligent switching between datalinks, for reliably delivering content from and to endpoints, is foreseen. As LDACS is part of such a concept, the work of RAW is immediately applicable. In general, with the aeronautical communications system transitioning to ATN/IPS, and data being transported via IPv6, closer cooperation and collaboration between the aeronautical and IETF community is desirable. LDACS standardization within the framework of ICAO started in December 2016. The ICAO standardization group has produced the final Standards and Recommended Practices (SARPS) document as of 2022 [ICAO2022]. It defines the general characteristics of LDACS. By the end of 2023, the ICAO standardization group plans to have developed an ICAO technical manual - the ICAO equivalent to a technical standard. As such LDACS standardization is not finished yet, and therefore this document is a snapshot of current status. The physical characteristics of an LDACS installation (form, fit, and function) will be standardized by EUROCAE. Generally, the group is open to input from all sources and encourages cooperation between the aeronautical and the IETF community. 2. Acronyms The following terms are used in the context of RAW in this document: A/A Air/Air A/G Air/Ground A2G Air-to-Ground ACARS Aircraft Communications Addressing and Reporting System AC-R Access Router ADS-B Automatic Dependent Surveillance - Broadcast ADS-C Automatic Dependent Surveillance - Contract AeroMACS Aeronautical Mobile Airport Communications System ANSP Air Traffic Network Service Provider AOC Aeronautical Operational Control ARINC Aeronautical Radio, Incorporated ARQ Automatic Repeat reQuest AS Aircraft Station ATC Air Traffic Control ATM Air Traffic Management ATN Aeronautical Telecommunication Network ATS Air Traffic Service BCCH Broadcast Channel CCCH Common Control Channel CM Context Management CNS Communication Navigation Surveillance COTS Commercial Off-The-Shelf Mäurer, et al. Expires 5 June 2023 [Page 5] Internet-Draft LDACS December 2022 CPDLC Controller Pilot Data Link Communications CRL Certificate Revocation List CSP Communications Service Provider DCCH Dedicated Control Channel DCH Data Channel DiffServ Differentiated Services DLL Data Link Layer DLS Data Link Service DME Distance Measuring Equipment DSB-AM Double Side-Band Amplitude Modulation DTLS Datagram Transport Layer Security EUROCAE European Organization for Civil Aviation Equipment FAA Federal Aviation Administration FCI Future Communications Infrastructure FDD Frequency Division Duplex FL Forward Link GANP Global Air Navigation Plan GBAS Ground Based Augmentation System GNSS Global Navigation Satellite System GS Ground-Station G2A Ground-to-Air HF High Frequency ICAO International Civil Aviation Organization IP Internet Protocol IPS Internet Protocol Suite kbit/s kilobit per second LDACS L-band Digital Aeronautical Communications System LISP Locator/ID Separation Protocol LLC Logical Link Control LME LDACS Management Entity MAC Medium Access Control MF Multi Frame NETCONF NETCONF Network Configuration Protocol OFDM Orthogonal Frequency-Division Multiplexing OFDMA Orthogonal Frequency-Division Multiplexing Access OSI Open Systems Interconnection PHY Physical Layer QPSK Quadrature Phase-Shift Keying RACH Random-Access Channel RL Reverse Link RTCA Radio Technical Commission for Aeronautics SARPS Standards and Recommended Practices SDR Software Defined Radio SESAR Single European Sky ATM Research SF Super-Frame SNMP Simple Network Management Protocol SNP Sub-Network Protocol VDLm2 VHF Data Link mode 2 Mäurer, et al. Expires 5 June 2023 [Page 6] Internet-Draft LDACS December 2022 VHF Very High Frequency VI Voice Interface 3. Motivation and Use Cases Aircraft are currently connected to Air Traffic Control (ATC) and Aeronautical Operational Control (AOC) services via voice and data communications systems through all phases of flight. ATC refers to communication for flight guidance. AOC is a generic term referring to the business communication of airlines. It refers to the mostly proprietary exchange of data between the aircraft of the airline and the airline's operation centers and service partners. The ARINC document 633 was developed and first released in 2007 [ARI2019] with the goal to standardize these messages for interoperability, e.g., messages between the airline and fueling or de-icing companies. Within the airport and terminal area, connectivity is focused on high bandwidth communications. In the En-Route domain, however, high reliability, robustness, and range are the main foci. Voice communications may use the same or different equipment as data communications systems. In the following, the main differences between voice and data communications capabilities are summarized. The assumed list of use cases for LDACS complements the list of use cases stated in [RAW-USE-CASES] and the list of reliable and available wireless technologies presented in [RAW-TECHNOS]. 3.1. Voice Communications Today Voice links are used for Air/Ground (A/G) and Air/Air (A/A) communications. The communications equipment can be installed on ground or in the aircraft, in which cases the High Frequency (HF) or VHF frequency band is used. For remote domains voice communications can also be satellite-based. All VHF and HF voice communications are operated via open broadcast channels without authentication, encryption or other protective measures. The use of well-proven communications procedures via broadcast channels, such as phraseology or read-backs, requiring well-trained personnel, help to enhance the safety of communications, but does not replace necessary cryptographical security mechanisms. The main voice communications media is still the analogue VHF Double Side-Band Amplitude Modulation (DSB-AM) communications technique, supplemented by HF single side- band amplitude modulation and satellite communications for remote and oceanic regions. DSB-AM has been in use since 1948, works reliably and safely, and uses low-cost communication equipment. These are the main reasons why VHF DSB-AM communications are still in use, and it is likely that this technology will remain in service for many more years. This however, results in current operational limitations and impediments in deploying new ATM applications, such as flight-centric Mäurer, et al. Expires 5 June 2023 [Page 7] Internet-Draft LDACS December 2022 operation with point-to-point communications between pilots and air traffic control officers. [BOE2019] 3.2. Data Communications Today Like for voice, data communications into the cockpit, are currently provided by ground-based equipment operating either on HF or VHF radio bands or by legacy satellite systems. All these communication systems use narrowband radio channels with a data throughput capacity in the order of kbit/s. While the aircraft is on the ground, some additional communications systems are available, like the Aeronautical Mobile Airport Communications System (AeroMACS) or public cellular networks, operating in the Airport (APT) domain and able to deliver broadband communications capability. [BOE2019] For regulatory reasons, the data communications networks, used for the transmission of data relating to the safety and regularity of flight, must be strictly isolated from those providing entertainment services to passengers. This leads to a situation that the flight crews are supported by narrowband services during flight while passengers have access to inflight broadband services. The current HF and VHF data links cannot provide broadband services now or in the future, due to the lack of available spectrum. This technical shortcoming is becoming a limitation to enhanced ATM operations, such as trajectory-based operations and 4D trajectory negotiations. [BOE2019] Satellite-based communications are currently under investigation and enhanced capabilities are under development which will be able to provide inflight broadband services and communications supporting the safety and regularity of flight. In parallel the ground-based broadband data link technology LDACS is being standardized by ICAO and has recently shown its maturity during flight tests [MAE20211] [BEL2021]. The LDACS technology is scalable, secure and spectrum efficient and provides significant advantages to the users and service providers. It is expected that both - satellite systems and LDACS - will be deployed to support the future aeronautical communication needs as envisaged by the ICAO Global Air Navigation Plan (GNAP). [BOE2019] 4. Provenance and Documents The development of LDACS has already made substantial progress in the Single European Sky ATM Research (SESAR) framework and is currently being continued in the follow-up program SESAR2020 [RIH2018]. A key objective of these activities is to develop, implement and validate a modern aeronautical data link able to evolve with aviation needs over the long term. To this end, an LDACS specification has been produced Mäurer, et al. Expires 5 June 2023 [Page 8] Internet-Draft LDACS December 2022 [GRA2020] and is continuously updated; transmitter demonstrators were developed to test the spectrum compatibility of LDACS with legacy systems operating in the L-band [SAJ2014]; and the overall system performance was analyzed by computer simulations, indicating that LDACS can fulfil the identified requirements [GRA2011]. Up to now LDACS standardization has been focused on the development of the physical layer and the data link layer. Only recently have higher layers have come into the focus of the LDACS development activities. Currently no "IPv6 over LDACS" specification is defined; however, SESAR2020 has started experimenting with IPv6-based LDACS and ICAO plans to seek guidance from IETF to develop IPv6 over LDACS. As of May 2022, LDACS defines 1536 Byte user-data packets [GRA2020] in which IPv6 traffic shall be encapsulated. Additionally, Robust Header Compression (ROHC) is considered on LDACS Sub-Network Protocol (SNP) layer (cf. Section 7.3.3.) [RFC5795]. The IPv6 architecture for the aeronautical telecommunication network is called the ATN/IPS. Link-layer technologies within the ATN/IPS encompass LDACS [GRA2020], AeroMACS [KAMA2018] and several SatCOM candidates and combined with the ATN/IPS, are called the FCI. The FCI will support quality of service, link diversity, and mobility under the umbrella of the "multilink concept". The "multilink concept" describing the idea that depending on link quality, communication can be switched seamlessly from one datalink technology to another. This work is led by ICAO Communication Panel working group WG-I. In addition to standardization activities several industrial LDACS prototypes have been built. One set of LDACS prototypes has been evaluated in flight trials confirming the theoretical results predicting the system performance [GRA2018] [MAE20211] [BEL2021]. 5. Applicability LDACS is a multi-application cellular broadband system capable of simultaneously providing various kinds of Air Traffic Services (ATS) including ATS-B3, and AOC communications services from deployed Ground-Stations (GS). The physical layer and data link layer of LDACS are optimized for controller-pilot data link communications, but the system also supports digital air-ground voice communications. LDACS supports communications in all airspaces (airport, terminal maneuvering area, and en-route), and on the airport surface. The physical LDACS cell coverage is effectively de-coupled from the operational coverage required for a particular service. This is new in aeronautical communications. Services requiring wide-area coverage can be installed at several adjacent LDACS cells. The Mäurer, et al. Expires 5 June 2023 [Page 9] Internet-Draft LDACS December 2022 handover between the involved LDACS cells is seamless, automatic, and transparent to the user. Therefore, the LDACS communications concept enables the aeronautical communication infrastructure to support future dynamic airspace management concepts. 5.1. Advances Beyond the State-of-the-Art LDACS will offer several capabilities, not yet provided in contemporarily deployed aeronautical communications systems. All these were already tested and confirmed in lab or flight trials with available LDACS prototype hardware [BEL2021] [MAE20211]. 5.1.1. Priorities LDACS is able to manage service priorities, an important feature not available in some of the current data link deployments. Thus, LDACS guarantees bandwidth availability, low latency, and high continuity of service for safety critical ATS applications while simultaneously accommodating less safety-critical AOC services. 5.1.2. Security LDACS is a secure data link with built-in security mechanisms. It enables secure data communications for ATS and AOC services, including secured private communications for aircraft operators and Air traffic Network Service Providers (ANSP). This includes concepts for key and trust management, mutual authentication and key establishment protocols, key derivation measures, user and control message-in-transit protection, secure logging and availability and robustness measures [MAE20182] [MAE2021]. 5.1.3. High Data Rates The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the Forward Link (FL) for the Ground-to-Air (G2A) connection, and 294 kbit/s to 1390 kbit/s on the Reverse Link (RL) for the Air-to-Ground (A2G) connection, depending on coding and modulation. This is up to two orders of magnitude greater than current terrestrial digital aeronautical communications systems, such as the VHF Data Link mode 2 (VDLm2), provide [ICAO2019] [GRA2020]. Mäurer, et al. Expires 5 June 2023 [Page 10] Internet-Draft LDACS December 2022 5.2. Application LDACS will be used by several aeronautical applications ranging from enhanced communications protocol stacks (multi-homed mobile IPv6 networks in the aircraft and potentially ad-hoc networks between aircraft) to broadcast communication applications (GNSS correction data) and integration with other service domains (using the communications signal for navigation) [MAE20211]. Also, a digital voice service offering better quality and service than current HF and VHF systems is foreseen. 5.2.1. Air/Ground Multilink It is expected that LDACS, together with upgraded satellite-based communications systems, will be deployed within the FCI and constitute one of the main components of the multilink concept within the FCI. Both technologies, LDACS and satellite systems, have their specific benefits and technical capabilities which complement each other. Especially, satellite systems are well-suited for large coverage areas with less dense air traffic, e.g. oceanic regions. LDACS is well-suited for dense air traffic areas, e.g., continental areas or hot-spots around airports and terminal airspace. In addition, both technologies offer comparable data link capacity and, thus, are well- suited for redundancy, mutual back-up, or load balancing. Technically the FCI multilink concept will be realized by multi-homed mobile IPv6 networks in the aircraft. The related protocol stack is currently under development by ICAO, within SESAR, and the IETF. Currently two layers of mobility are foreseen. Local mobility within the LDACS access network is realized through PMIPv6, global mobility between "multi-link" access networks (which need not be LDACS) is implemented on top of LISP [I-D.haindl-lisp-gb-atn] [I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6833bis]. 5.2.2. Air/Air Extension for LDACS A potential extension of the multilink concept is its extension to the integration of ad-hoc networks between aircraft. Mäurer, et al. Expires 5 June 2023 [Page 11] Internet-Draft LDACS December 2022 Direct A/A communication between aircraft in terms of ad-hoc data networks are currently considered a research topic since there is no immediate operational need for it, although several possible use cases are discussed (Automatic Dependent Surveillance - Broadcast (ADS-B), digital voice, wake vortex warnings, and trajectory negotiation) [BEL2019]. It should also be noted, that currently deployed analog VHF voice radios support direct voice communication between aircraft, making a similar use case for digital voice plausible. LDACS A/A is currently not part of the standardization process and will not be covered within this document. However, it is planned that LDACS A/A will be rolled out after the initial deployment of LDACS A/G, then being seamlessly integrated in the existing LDACS ground-based system. 5.2.3. Flight Guidance The FCI (and therefore LDACS) is used to provide flight guidance. This is realized using three applications: 1. Context Management (CM): The CM application manages the automatic logical connection to the ATC center currently responsible to guide the aircraft. Currently, this is done by the air crew manually changing VHF voice frequencies manually according to the progress of the flight. The CM application automatically sets up equivalent sessions. 2. Controller Pilot Data Link Communications (CPDLC): The CPDLC application provides the air crew with the ability to exchange data messages similar to text messages with the currently responsible ATC center. The CPDLC application takes over most of the communication currently performed over VHF voice and enables new services that do not lend themselves to voice communication (i.e., trajectory negotiation). 3. Automatic Dependent Surveillance - Contract (ADS-C): ADS-C reports the position of the aircraft to the currently active ATC center. Reporting is bound to "contracts", i.e., pre-defined events related to the progress of the flight (i.e., the trajectory). ADS-C and CPDLC are the primary applications used for implementing in-flight trajectory management. CM, CPDLC, and ADS-C are available on legacy datalinks, but are not widely deployed and with limited functionality. Further ATC applications may be ported to use the FCI or LDACS as well. A notable application is GBAS for secure, automated landings: The Global Navigation Satellite System (GNSS) based GBAS is used to improve the accuracy of GNSS to allow GNSS based instrument landings. Mäurer, et al. Expires 5 June 2023 [Page 12] Internet-Draft LDACS December 2022 This is realized by sending GNSS correction data (e.g., compensating ionospheric errors in the GNSS signal) to the aircraft's GNSS receiver via a separate data link. Currently, the VDB data link is used. VDB is a narrowband single-purpose datalink without advanced security only used to transmit GBAS correction data. This makes VDB a natural candidate for replacement by LDACS [MAE20211]. 5.2.4. Business Communications of Airlines In addition to air traffic services, AOC services are transmitted over LDACS. AOC is a generic term referring to the business communication of airlines, between the airlines and service partners on the ground and their own aircraft in the air. Regulatory-wise, this is considered related to safety and regularity of flight and may therefore, be transmitted over LDACS. AOC communication is considered the main business case for LDACS communications service providers since modern aircraft generate significant amounts of data (e.g., engine maintenance data). 5.2.5. LDACS-based Navigation Beyond communications, radio signals can always also be used for navigation. This fact is used for the LDACS navigation concept. For future aeronautical navigation, ICAO recommends the further development of GNSS based technologies as primary means for navigation. Due to the large separation between navigational satellites and aircraft, the power of the GNSS signals received by the aircraft is, however, very low. As a result, GNSS disruptions might occasionally occur due to unintentional interference, or intentional jamming. Yet the navigation services must be available with sufficient performance for all phases of flight. Therefore, during GNSS outages, or blockages, an alternative solution is needed. This is commonly referred to as Alternative Positioning, Navigation, and Timing (APNT). One such APNT solution is based on exploiting the built-in navigation capabilities of LDACS operation. That is, the normal operation of LDACS for ATC and AOC communications would also directly enable the aircraft to navigate and obtain a reliable timing reference from the LDACS GSs. Current cell planning for Europe shows 84 LDACS cells to be sufficient [MOST2018] to cover the continent at sufficient service level. If more than three Ground Stations (GS) are visible by the aircraft, via knowing the exact positions of these and having a good channel estimation (which LDACS does due to numerous works mapping the L-band channel characteristics [SCHN2018] ) it is possible to calculate the position of the aircraft via measuring signal propagation times to each GS. In flight trials in 2019 with one Mäurer, et al. Expires 5 June 2023 [Page 13] Internet-Draft LDACS December 2022 aircraft (and airborne radio inside it) and just four GS, navigation feasibility was demonstrated within the footprint of all four GS with a 95th percentile position-domain error of 171.1m [OSE2019] [BEL2021] [MAE20211]. As such, LDACS can be used independently of GNSS as a navigation alternative. Positioning errors will decrease markedly as more GSes are deployed. [OSE2019] [BEL2021] [MAE20211] LDACS navigation has already been demonstrated in practice in two flight measurement campaigns [SHU2013] [BEL2021] [MAE20211]. 6. Requirements The requirements for LDACS are mostly defined by its application area: Communications related to safety and regularity of flight. A particularity of the current aeronautical communication landscape is that it is heavily regulated. Aeronautical data links (for applications related to safety and regularity of flight) may only use spectrum licensed to aviation and data links endorsed by ICAO. Nation states can change this locally; however, due to the global scale of the air transportation system, adherence to these practices is to be expected. Aeronautical data links for the ATN are therefore expected to remain in service for decades. The VDLm2 data link currently used for digital terrestrial internetworking was developed in the 1990s (the use of the Open Systems Interconnection (OSI) stack indicates that as well). VDLm2 is expected to be used at least for several decades to come. In this respect aeronautical communications (for applications related to safety and regularity of flight) is more comparable to industrial applications than to the open Internet. Internetwork technology is already installed in current aircraft. Current ATS applications use either Aircraft Communications Addressing and Reporting System (ACARS) or the OSI stack. The objective of the development effort of LDACS, as part of the FCI, is to replace legacy OSI stack and proprietary ACARS internetwork technologies with industry standard IP technology. It is anticipated that the use of Commercial Off-The-Shelf (COTS) IP technology mostly applies to the ground network. The avionics networks on the aircraft will likely be heavily modified versions of Ethernet or proprietary. AOC applications currently mostly use the same stack (although some applications, like the graphical weather service may use the commercial passenger network). This creates capacity problems (resulting in excessive amounts of timeouts) since the underlying terrestrial data links do not provide sufficient bandwidth (i.e., with VDLm2 currently in the order of 10 kbit/s). The use of non- Mäurer, et al. Expires 5 June 2023 [Page 14] Internet-Draft LDACS December 2022 aviation specific data links is considered a security problem. Ideally the aeronautical IP internetwork, hence the ATN over which only communications related to safety and regularity of flight is handled, and the Internet should be completely separated at Layer 3. The objective of LDACS is to provide a next generation terrestrial data link designed to support IP addressing and provide much higher bandwidth to avoid the currently experienced operational problems. The requirement for LDACS is therefore to provide a terrestrial high- throughput data link for IP internetworking in the aircraft. In order to fulfil the above requirement LDACS needs to be interoperable with IP (and IP-based services like Voice-over-IP) at the gateway connecting the LDACS network to other aeronautical ground networks (i.e., the ATN). On the avionics side, in the aircraft, aviation specific solutions are to be expected. In addition to these functional requirements, LDACS and its IP stack need to fulfil the requirements defined in RTCA DO-350A/EUROCAE ED- 228A [DO350A]. This document defines continuity, availability, and integrity requirements at different scopes for each air traffic management application (CPDLC, CM, and ADS-C). The scope most relevant to IP over LDACS is the Communications Service Provider (CSP) scope. Continuity, availability, and integrity requirements are defined in [DO350A] volume 1 Table 5-14, and Table 6-13. Appendix A presents the required information. In a similar vein, requirements to fault management are defined in the same tables. 7. Characteristics LDACS will become one of several wireless access networks connecting aircraft to the ATN implemented by the FCI. The current LDACS design is focused on the specification of layer one and two. However, for the purpose of this work, only layer two details are discussed here. Mäurer, et al. Expires 5 June 2023 [Page 15] Internet-Draft LDACS December 2022 Achieving the stringent continuity, availability, and integrity requirements defined in [DO350A] will require the specification of layer 3 and above mechanisms (e.g., reliable crossover at the IP layer). Fault management mechanisms are similarly unspecified as of November 2022. Current regulatory documents do not fully specify the above mechanism yet. However, a short overview of the current state shall be given throughout each section here. 7.1. LDACS Access Network An LDACS access network contains an Access Router (AC-R) and several GS, each of them providing one LDACS radio cell. User plane interconnection to the ATN is facilitated by the AC-R peering with an A/G Router connected to the ATN. The internal control plane of an LDACS access network interconnects the GSs. An LDACS access network is illustrated in Figure 1. wireless user link plane AS-------------GS---------------AC-R---A/G-----ATN .............. | Router control . | plane . | . | GS----------------| . | . | GS----------------+ Figure 1: LDACS access network with three GSs and one AS. dashes denotes the user plane and points the control plane 7.2. Topology LDACS is a cellular point-to-multipoint system. It assumes a star- topology in each cell where Aircraft Stations (AS) belonging to aircraft within a certain volume of space (the LDACS cell) are connected to the controlling GS. The LDACS GS is a centralized instance that controls LDACS A/G communications within its cell. The LDACS GS can simultaneously support multiple bidirectional communications to the ASs under its control. LDACS's GSs themselves Mäurer, et al. Expires 5 June 2023 [Page 16] Internet-Draft LDACS December 2022 are connected to each other and the AC-R. Prior to utilizing the system an aircraft has to register with the controlling GS to establish dedicated logical channels for user and control data. Control channels have statically allocated resources, while user channels have dynamically assigned resources according to the current demand. Logical channels exist only between the GS and the AS. 7.3. LDACS Protocol Stack The protocol stack of LDACS is implemented in the AS and GS: It consists of the Physical Layer (PHY) with five major, functional blocks above it. Four are placed in the Data Link Layer (DLL) of the AS and GS: (1) Medium Access Control (MAC) Layer, (2) Voice Interface (VI), (3) Data Link Service (DLS), and (4) LDACS Management Entity (LME). The fifth entity resides within the sub-network layer: (5) the Sub-Network Protocol (SNP). The LDACS radio is externally connected to a voice unit, radio control unit, and via the AC-R to the ATN network. LDACS is considered an ATN/IPS radio access technology, from the view of ICAO's regulatory framework. Hence, the interface between ATN and LDACS must be IPv6 based, as regulatory documents, such as ICAO Doc 9896 [ICAO2015] and DO-379 [RTCA2019] clearly foresee that. The translation between IPv6 layer and SNP layer is currently the subject of ongoing standardization efforts and at the time of writing not finished yet. Figure 2 shows the protocol stack of LDACS as implemented in the AS and GS. Acronyms used here are introduced throughout the upcoming sections. Mäurer, et al. Expires 5 June 2023 [Page 17] Internet-Draft LDACS December 2022 IPv6 Network Layer | Airborne Voice | Interface (AVI)/ | Radio Control Unit (RCU) Voice Unit (VU) | | | | +------------------+ +----+ | | SNP |--| | Sub-Network | | | | | Layer | +------------------+ | | | | | LME| +-----+ +------------------+ | | | VI | | DLS | | | LLC Layer +-----+ +------------------+ +----+ | | | DCH DCH DCCH/CCCH | RACH/BCCH | | +-------------------------------------+ | MAC | Medium Access | | Layer +-------------------------------------+ | +-------------------------------------+ | PHY | Physical Layer +-------------------------------------+ | | ((*)) FL/RL radio channels separated by FDD Figure 2: LDACS protocol stack in AS and GS 7.3.1. LDACS Physical Layer The physical layer provides the means to transfer data over the radio channel. The LDACS GS supports bidirectional links to multiple aircraft under its control. The FL direction at the G2A connection and the RL direction at the A2G connection are separated by Frequency Division Duplex (FDD). FL and RL use a 500 kHz channel each. The GS transmits a continuous stream of Orthogonal Frequency-Division Multiplexing Access (OFDM) symbols on the FL. In the RL different aircraft are separated in time and frequency using Orthogonal Frequency-Division Multiple Access (OFDMA). Aircraft thus transmit discontinuously on the RL via short radio bursts sent in precisely Mäurer, et al. Expires 5 June 2023 [Page 18] Internet-Draft LDACS December 2022 defined transmission opportunities allocated by the GS. 7.3.2. LDACS Data Link Layer The data-link layer provides the necessary protocols to facilitate concurrent and reliable data transfer for multiple users. The LDACS data link layer is organized in two sub-layers: The medium access sub-layer and the Logical Link Control (LLC) sub-layer. The medium access sub-layer manages the organization of transmission opportunities in slots of time and frequency. The LLC sub-layer provides acknowledged point-to-point logical channels between the aircraft and the GS using an Automatic Repeat reQuest (ARQ) protocol. LDACS also supports unacknowledged point-to-point channels and G2A Broadcast transmission. 7.3.2.1. Medium Access Control (MAC) Services The MAC time framing service provides the frame structure necessary to realize slot-based time-division multiplex-access on the physical link. It provides the functions for the synchronization of the MAC framing structure and the PHY Layer framing. The MAC time framing provides a dedicated time slot for each logical channel. The MAC sub-layer offers access to the physical channel to its service users. Channel access is provided through transparent logical channels. The MAC sub-layer maps logical channels onto the appropriate slots and manages the access to these channels. Logical channels are used as interface between the MAC and LLC sub-layers. 7.3.2.2. Data Link Service (DLS) Services The DLS provides acknowledged and unacknowledged (including broadcast and packet mode voice) bidirectional exchange of user data. If user data is transmitted using the acknowledged DLS, the sending DLS entity will wait for an acknowledgement from the receiver. If no acknowledgement is received within a specified time frame, the sender may automatically try to retransmit its data. However, after a certain number of failed retries, the sender will suspend further retransmission attempts and inform its client of the failure. The DLS uses the logical channels provided by the MAC: 1. A GS announces its existence and access parameters in the Broadcast Channel (BCCH). 2. The Random-Access Channel (RACH) enables AS to request access to an LDACS cell. 3. In the FL the Common Control Channel (CCCH) is used by the GS to grant access to data channel resources. Mäurer, et al. Expires 5 June 2023 [Page 19] Internet-Draft LDACS December 2022 4. The reverse direction is covered by the RL, where ASs need to request resources before sending. This happens via the Dedicated Control Channel (DCCH). 5. User data itself is communicated in the Data Channel (DCH) on the FL and RL. Access to the FL and RL data channel is granted by the scheduling mechanism implemented in the LME discussed below. 7.3.2.3. Voice Interface (VI) Services The VI provides support for virtual voice circuits. Voice circuits may either be set-up permanently by the GS (e.g., to emulate voice party line) or may be created on demand. 7.3.2.4. LDACS Management Entity (LME) Services The mobility management service in the LME provides support for registration and de-registration (cell entry and cell exit), scanning RF channels of neighboring cells and handover between cells. In addition, it manages the addressing of aircraft within cells. The resource management service provides link maintenance (power, frequency and time adjustments), support for adaptive coding and modulation, and resource allocation. The resource management service accepts resource requests from/for different AS and issues resource allocations accordingly. While the scheduling algorithm is not specified and a point of possible vendor differentiation, it is subject to the following requirements: 1. Resource scheduling must provide channel access according to the priority of the request 2. Resource scheduling must support "one-time" requests. 3. Resource scheduling must support "permanent" requests that reserve a resource until the request is canceled e.g. for digital voice circuits. 7.3.3. LDACS Sub-Network Layer and Protocol Services Lastly, the SNP layer of LDACS directly interacts with IPv6 traffic. Incoming ATN/IPS IPv6 packets are forwarded over LDACS from and to the aircraft. The final IP addressing structure in an LDACS subnet still needs to be defined; however, the current layout is considered to consist of the five network segments: Air Core Net, Air Management Net, Ground Core Net, Ground Management Net, Ground Net. Any protocols that the ATN/IPS [ICAO2015] defines as mandatory will reach the aircraft, however listing these here is out of scope. For more Mäurer, et al. Expires 5 June 2023 [Page 20] Internet-Draft LDACS December 2022 information on the technicalities of the above ATN/IPS layer, please refer to [ICAO2015] [RTCA2019] [ARI2021]. The DLS provides functions required for the transfer of user plane data and control plane data over the LDACS access network. The security service provides functions for secure user data communication over the LDACS access network. Note that the SNP security service applies cryptographic measures as configured by the GS. 7.4. LDACS Mobility LDACS supports layer 2 handovers to different LDACS cells. Handovers may be initiated by the aircraft (break-before-make) or by the GS (make-before-break). Make-before-break handovers are only supported between GSs connected to each other, usually GS operated by the same service provider. When a handover between AS and two interconnected GS takes place, it can be triggered by AS or GS. Once that is done, new security information is exchanged between AS, GS1 and GS2, before the "old" connection is terminated between AS and GS1 and a "new" connection is set up between AS and GS2. As a last step, accumulated user-data at GS1 is forwarded to GS2 via a ground connection, before that is sent via GS2 to the AS. While some information for handover is transmitted in the LDACS DCH, the information remains in the "control-plane" part of LDACS and is exchanged between LMEs in AS, GS1 and GS2. As such, local mobility takes place entirely within the LDACS network, utilizing the PMIPv6 protocol [RFC5213]. The use of PMIPv6 is currently not mandated by standardization, and may be vendor-specific. External handovers between non-connected LDACS access networks or different aeronautical data links are handled by the FCI multi-link concept. External handovers between non-connected LDACS access networks or different aeronautical data links are handled by the FCI multi- link concept. 7.5. LDACS Management - Interfaces and Protocols LDACS management interfaces and protocols are currently not be mandated by standardization. The implementations currently available use SNMP for management and Radius for AAA. Link state (link up, link down) is reported using the ATN/IPS Aircraft Protocol (AIAP) mandated by ICAO WG-I for multi-link. 8. Reliability and Availability Mäurer, et al. Expires 5 June 2023 [Page 21] Internet-Draft LDACS December 2022 8.1. Below Layer 1 Below Layer 2, aeronautics usually relies on hardware redundancy. To protect availability of the LDACS link, an aircraft equipped with LDACS will have access to two L-band antennae with triple redundant radio systems as required for any safety relevant aeronautical systems by ICAO. 8.2. Layer 1 and 2 LDACS has been designed with applications related to the safety and regularity of flight in mind. It has therefore been designed as a deterministic wireless data link (as far as this is possible). Based on channel measurements of the L-band channel LDACS was designed from the PHY layer up with robustness in mind. Channel measurements of the L-band channel [SCH2016] confirmed LDACS to be well adapted to its channel. In order to maximize the capacity per channel and to optimally use the available spectrum, LDACS was designed as an OFDM-based FDD system, supporting simultaneous transmissions in FL in the G2A connection and RL in the A2G connection. The legacy systems already deployed in the L-band limit the bandwidth of both channels to approximately 500 kHz. The LDACS physical layer design includes propagation guard times sufficient for operation at a maximum distance of 200 nautical miles from the GS. In actual deployment, LDACS can be configured for any range up to this maximum range. The LDACS physical layer supports adaptive coding and modulation for user data. Control data is always encoded with the most robust coding and modulation (FL: Quadrature Phase-Shift Keying (QPSK), coding rate 1/2, RL: QPSK, coding rate 1/3). LDACS medium access layer on top of the physical layer uses a static frame structure to support deterministic timer management. As shown in Figure 3 and Figure 4, LDACS framing structure is based on Super- Frames (SF) of 240ms duration corresponding to 2000 OFDM symbols. OFDM symbol time is 120 microseconds, sampling time 1.6 microseconds and a guard time of 4.8 microseconds. The structure of a SF is depicted in Figure 3 along with its structure and timings of each part. FL and RL boundaries are aligned in time (from the GS perspective) allowing for deterministic slots for control and data channels. This initial AS time synchronization and time synchronization maintenance is based on observing the synchronization symbol pairs that repetitively occur within the FL stream, being sent Mäurer, et al. Expires 5 June 2023 [Page 22] Internet-Draft LDACS December 2022 by the controlling GS [GRA2020]. As already mentioned, LDACS data transmission is split into user-data (DCH) and control (BCCH, CCCH in FL; RACH, DCCH in RL) as depicted with corresponding timings in Figure 4. ^ | +--------+------------+------------+------------+------------+ | FL | BCCH | MF | MF | MF | MF | | | 6.72ms | 58.32ms | 58.32ms | 58.32ms | 58.32ms | F +--------+------------+------------+------------+------------+ r <----------------- Super-Frame (SF) - 240ms -----------------> e q +--------+------------+------------+------------+------------+ u RL | RACH | MF | MF | MF | MF | e | 6.72ms | 58.32ms | 58.32ms | 58.32ms | 58.32ms | n +--------+------------+------------+------------+------------+ c <----------------- Super-Frame (SF) - 240ms -----------------> y ------------------------------ Time -------------------------------> | Figure 3: SF structure for LDACS ^ | +-------------+----------------+-----------------+ | FL | DCH | CCCH | DCH | | | 25.92ms | 2.16 - 17.28ms | 15.12 - 30.24ms | F +-------------+----------------+-----------------+ r <----------- Multi-Frame (MF) - 58.32ms ---------> e q +--------------+---------------------------------+ u RL | DCCH | DCH | e | 2.8 - 24.4ms | 33.84 - 55.44ms | n +--------------+---------------------------------+ c <----------- Multi-Frame (MF) - 58.32ms ---------> y ----------------------------- Time --------------------> | Figure 4: MF structure for LDACS LDACS cell entry is conducted with an initial control message exchange via the RACH and the BCCH. Mäurer, et al. Expires 5 June 2023 [Page 23] Internet-Draft LDACS December 2022 After cell entry, LDACS medium access is always under the control of the GS of a radio cell. Any medium access for the transmission of user data on a DCH has to be requested with a resource request message stating the requested amount of resources and class of service. The GS performs resource scheduling on the basis of these requests and grants resources with resource allocation messages. Resource request and allocation messages are exchanged over dedicated contention-free control channels (DCCH and CCCH). The purpose of quality-of-service in LDACS medium access is to provide prioritized medium access at the bottleneck (the wireless link). Signaling of higher layer quality-of-service requests to LDACS is implemented on the basis of Differentiated Services-(DiffServ) classes CS01 (lowest priority) to CS07 (highest priority). In addition to having full control over resource scheduling, the GS can send forced handover commands for off-loading or channel management, e.g., when the signal quality declines and a more suitable GS is in the AS's reach. With robust resource management of the capacities of the radio channel, reliability and robustness measures are therefore also anchored in the LME. In addition to radio resource management, the LDACS control channels are also used to send keep-alive messages, when they are not otherwise used. Since the framing of the control channels is deterministic, missing keep-alive messages can thus be immediately detected. This information is made available to the multilink protocols for fault management. The protocol used to communicate faults is not defined in the LDACS specification. It is assumed that vendors would use industry standard protocols like the Simple Network Management Protocol or the Network Configuration Protocol, where security permits. The LDACS data link layer protocol, running on top of the medium access sub-layer, uses ARQ to provide reliable data transmission on the data channel. It employs selective repeat ARQ with transparent fragmentation and reassembly to the resource allocation size to minimize latency and overhead without losing reliability. It ensures correct order of packet delivery without duplicates. In case of transmission errors, it identifies lost fragments with deterministic timers synced to the medium access frame structure and initiates retransmission. Mäurer, et al. Expires 5 June 2023 [Page 24] Internet-Draft LDACS December 2022 8.3. Beyond Layer 2 LDACS availability can be increased by appropriately deploying LDACS infrastructure: This means proliferating the number of terrestrial ground stations. However, there are four aspects that need to be taken into consideration: (1) scarcity of aeronautical spectrum for data link communication (in the case of LDACS: tens of MHz in the L-band), (2) an increase in the amount of ground stations also increases the individual bandwidth for aircraft in the cell, as fewer aircraft have to share the spectrum, (3) to cover worldwide terrestrial ATM via LDACS is also a question of cost and the possible reuse of spectrum which makes it not always possible to decrease cell sizes and (4) the Distance Measuring Equipment (DME) is the primary user of the aeronautical L-band, which means any LDACS deployment has to take DME frequency planning into account. While aspect (2) provides a good reason, alongside increasing redundancy, for smaller cells than the maximum range LDACS was developed for (200 Nautical Miles (NM)), the other three need to be respected when doing so. There are preliminary works on LDACS cell planning, such as [MOST2018], where the authors reach the conclusion that 84 LDACS cells in Europe would be sufficient to serve European air traffic for the next 20 years. For redundancy reasons, the aeronautical community has decided not to rely on a single communication system or frequency band. It is envisioned to have multiple independent data link technologies in the aircraft (e.g., terrestrial and satellite communications) in addition to legacy VHF voice. However, as of now, no reliability and availability mechanisms that could utilize the multilink architecture, have been specified on Layer 3 and above. Even if LDACS has been designed for reliability, the wireless medium presents significant challenges to achieve deterministic properties such as low packet error rate, bounded consecutive losses, and bounded latency. Support for high reliability and availability for IP connectivity over LDACS is certainly highly desirable but needs to be adapted to the specific use case. 9. Security The goal of this Section is to inform the reader about the state of security in aeronautical communications, state security considerations applicable for all ATN/IPS traffic and to provide an overview of the LDACS link-layer security capabilities. Mäurer, et al. Expires 5 June 2023 [Page 25] Internet-Draft LDACS December 2022 9.1. Security in Wireless Digital Aeronautical Communications Aviation will require secure exchanges of data and voice messages for managing the air traffic flow safely through the airspaces all over the world. Historically Communication Navigation Surveillance (CNS) wireless communications technology emerged from the military and a threat landscape where inferior technological and financial capabilities of adversaries were assumed [STR2016]. The main communications method for ATC today is still an open analogue voice broadcast within the aeronautical VHF band. Currently, information security is mainly procedural, based by using well-trained personnel and proven communications procedures. This communication method has been in service since 1948. However, since the emergence of civil aeronautical CNS applications in the 70s, and today, the world has changed. CCivil applications have significant lower spectrum available than military applications. This means several military defense mechanisms, such as frequency hopping or pilot symbol scrambling and, thus, a defense-in-depth approach starting at the physical layer, is infeasible for civil systems. With the rise of cheap Software Defined Radios (SDR), the previously existing financial barrier is almost gone and open source projects such as GNU radio [GNU2021] allow a new type of unsophisticated listeners and possible attackers. Most CNS technology developed in ICAO relies on open standards, thus syntax and semantics of wireless digital aeronautical communications should be expected to be common knowledge for attackers. With increased digitization and automation of civil aviation, the human as control instance, is being taken gradually out of the loop. Autonomous transport drones or single piloted aircraft demonstrate this trend. However, without profound cybersecurity measures such as authenticity and integrity checks of messages in-transit on the wireless link or mutual entity authentication, this lack of a control instance can prove disastrous. Thus, future digital communications will need additional embedded security features to fulfill modern information security requirements like authentication and integrity. These security features require sufficient bandwidth which is beyond the capabilities of currently deployed VHF narrowband communications systems. For voice and data communications, sufficient data throughput capability is needed to support the security functions while not degrading performance. LDACS is a data link technology with sufficient bandwidth to incorporate security without losing too much user data throughput. Mäurer, et al. Expires 5 June 2023 [Page 26] Internet-Draft LDACS December 2022 9.2. Security in Depth ICAO Doc 9896 foresees transport layer security [ICAO2015] for all aeronautical data transmitted via the ATN/IPS, as described in ARINC P858 [ARI2021]. This is realized via Datagram Transport Layer Security (DTLS) 1.3 [RFC9147]. LDACS also needs to comply with in-depth security requirements, stated in ARINC 858, for the radio access technologies transporting ATN/IPS data. These requirements imply that LDACS must provide layer 2 security in addition to any higher layer mechanisms. Specifically, ARINC 858 states that [datalinks within the FCI need to provide] "a secure channel between the airborne radio systems and the peer radio access endpoints on the ground [...] to ensure authentication and integrity of air-ground message exchanges in support of an overall defense-in-depth security strategy." [ARI2021] 9.3. LDACS Security Requirements Overall, cybersecurity for CNS technology shall protect the following business goals [MAE20181]: 1. Safety: The system must sufficiently mitigate attacks, which contribute to safety hazards. 2. Flight regularity: The system must sufficiently mitigate attacks, which contribute to delays, diversions, or cancellations of flights. 3. Protection of business interests: The system must sufficiently mitigate attacks which result in financial loss, reputation damage, disclosure of sensitive proprietary information, or disclosure of personal information. To further analyze assets and derive threats and thus protection scenarios several threat-and risk analyses were performed for LDACS [MAE20181] , [MAE20191]. These results allowed the derivation of security scope and objectives from the requirements and the conducted threat-and risk analysis. Note, IPv6 security considerations are briefly discussed in Section 9.7 while a summary of security requirements for link-layer candidates in the ATN/IPS is given in [ARI2021], which states: "Since the communication radios connect to local airborne networks in the aircraft control domain, [...] the airborne radio systems represent the first point of entry for an external threat to the aircraft. Consequently, a secure channel between the airborne radio systems and the peer radio access endpoints on the ground is necessary to ensure authentication and integrity of air-ground message exchanges in support of an overall defense-in-depth security strategy". Mäurer, et al. Expires 5 June 2023 [Page 27] Internet-Draft LDACS December 2022 9.4. LDACS Security Objectives Security considerations for LDACS are defined by the official SARPS document by ICAO [ICAO2022]: 1. LDACS shall provide a capability to protect the availability and continuity of the system. 2. LDACS shall provide a capability including cryptographic mechanisms to protect the integrity of messages in transit. 3. LDACS shall provide a capability to ensure the authenticity of messages in transit. 4. LDACS should provide a capability for nonrepudiation of origin for messages in transit. 5. LDACS should provide a capability to protect the confidentiality of messages in transit. 6. LDACS shall provide an authentication capability. 7. LDACS shall provide a capability to authorize the permitted actions of users of the system and to deny actions that are not explicitly authorized. 8. If LDACS provides interfaces to multiple domains, LDACS shall provide capability to prevent the propagation of intrusions within LDACS domains and towards external domains. Work in 2022 includes a change request for these SARPS aims to limit the "non-repudiation of origin of messages in transit" requirement only to the authentication and key establishment messages at the beginning of every session. 9.5. LDACS Security Functions These objectives were used to derive several security functions for LDACS required to be integrated in the LDACS cybersecurity architecture: Identification, Authentication, Authorization, Confidentiality, System Integrity, Data Integrity, Robustness, Reliability, Availability, and Key and Trust Management. Several works investigated possible measures to implement these security functions [BIL2017], [MAE20181], [MAE20191]. 9.6. LDACS Security Architecture The requirements lead to a LDACS security model, including different entities for identification, authentication and authorization purposes, ensuring integrity, authenticity and confidentiality of data. A draft of the cybersecurity architecture of LDACS can be found in [ICAO2022] and [MAE20182] and respective updates in [MAE20191], [MAE20192], [MAE2020], [MAE2021]. Mäurer, et al. Expires 5 June 2023 [Page 28] Internet-Draft LDACS December 2022 9.6.1. Entities A simplified LDACS architectural model requires the following entities: Network operators such as the Societe Internationale de Telecommunications Aeronautiques (SITA) [SIT2020] and ARINC [ARI2020] are providing access to the ground IPS network via an A/G LDACS router. This router is attached to an internal LDACS access network, which connects via further access routers to the different LDACS cell ranges, each controlled by a GS (serving one LDACS cell), with several interconnected GS spanning a local LDACS access network. Via the A/G wireless LDACS data link AS the aircraft is connected to the ground network and via the aircraft's VI and aircraft's network interface, aircraft's data can be sent via the AS back to the GS, then to the LDACS local access network, access routers, LDACS access network, A/G LDACS router and finally to the ground IPS network [ICAO2015]. 9.6.2. Entity Identification LDACS needs specific identities for the AS, the GS, and the network operator. The aircraft itself can be identified using the 24-bit ICAO identifier of an aircraft [ICAO2022], the call sign of that aircraft or the recently founded privacy ICAO address of the Federal Aviation Administration (FAA) program with the same name [FAA2020]. It is conceivable that the LDACS AS will use a combination of aircraft identification, radio component identification and even operator feature identification to create a unique AS LDACS identification tag. Similar to a 4G's eNodeB serving network identification tag, a GS could be identified using a similar field. The identification of the network operator is again similar to 4G (e.g., E-Plus, AT&T, and TELUS), in the way that the aeronautical network operators are listed (e.g., ARINC [ARI2020] and SITA [SIT2020]). 9.6.3. Entity Authentication and Key Establishment In order to anchor trust within the system, all LDACS entities connected to the ground IPS network will be rooted in an LDACS specific chain-of-trust and PKI solution, quite similar to AeroMACS's approach [CRO2016]. These certificates, residing at the entities and incorporated in the LDACS PKI, providing proof the ownership of their respective public key, include information about the identity of the owner and the digital signature of the entity that has verified the certificate's content. First, all ground infrastructures must mutually authenticate to each other, negotiate and derive keys and, thus, secure all ground connections. How this process is handled in detail is still an ongoing discussion. However, established methods to secure user plane by IPSec [RFC4301] and IKEv2 [RFC7296] or the Mäurer, et al. Expires 5 June 2023 [Page 29] Internet-Draft LDACS December 2022 application layer via TLS 1.3 [RFC8446] are conceivable. The LDACS PKI with its chain-of-trust approach, digital certificates and public entity keys lay the groundwork for this step. In a second step, the AS with the LDACS radio aboard, approaches an LDACS cell and performs a cell-attachment procedure with the corresponding GS. This procedure consists of (1) the basic cell entry [GRA2020] and (2) a Mutual Authentication and Key Establishment (MAKE) procedure [MAE2021]. Note that LDACS will foresee multiple security levels. To address the issue of the long service life of LDACS (i.e., possibly >30 years) and the security of current pre-quantum cryptography, these security levels include pre- and post-quantum cryptographic solutions. Limiting security data on the LDACS datalink as much as possible, to reserve as much space for actual user data transmission, is key in the LDACS security architecture, this is also reflected in the underlying cryptography: Pre-quantum solutions will rely on elliptic curves [NIST2013], while post-quantum solutions consider Falcon [SON2021] [MAE2021] or similar lightweight PQC signature schemes, and CRYSTALS-KYBER or SABER as key establishment options [AVA2021] [ROY2020]. 9.6.4. Message-in-transit Confidentiality, Integrity and Authenticity The key material from the previous step can then be used to protect LDACS Layer 2 communications via applying encryption and integrity protection measures on the SNP layer of the LDACS protocol stack. As LDACS transports AOC and ATS data, the integrity of that data is most important, while confidentiality only needs to be applied to AOC data to protect business interests [ICAO2022]. This possibility of providing low layered confidentiality and integrity protection ensures a secure delivery of user data over the wireless link. Furthermore, it ensures integrity protection of LDACS control data. 9.7. Considerations on LDACS Security Impact on IPv6 Operational Security In this part, considerations on IPv6 operational security in [RFC9099] and interrelations with the LDACS security additions are compared and evaluated to identify further protection demands. As IPv6 heavily relies on the Neighbor Discovery Protocol (NDP) [RFC4861], integrity and authenticity protection on the link-layer, as provided by LDACS, already help mitigate spoofing and redirection attacks. However, to also mitigate the threat of remote DDoS attacks, neighbor solicitation rate-limiting is recommended by RFC 9099. To prevent the threat of (D)DoS attacks in general on the LDACS access network, rate-limiting needs to be performed on each network node in the LDACS access network. One approach is to filter Mäurer, et al. Expires 5 June 2023 [Page 30] Internet-Draft LDACS December 2022 for the total amount of possible LDACS AS-GS traffic per cell - i.e., of up to 1.4 Mbps user-data per cell and up to the amount of GS per service provider network times 1.4 Mbps. 10. IANA Considerations This memo includes no request to IANA. 11. Acknowledgements Thanks to all contributors to the development of LDACS and ICAO PT-T, as well as to all in the RAW Working Group for deep discussions and feedback. Thanks to Klaus-Peter Hauf, Bart Van Den Einden, and Pierluigi Fantappie for their comments to this draft. Thanks to the Chair for Network Security and the research institute CODE for their comments and improvements. Thanks to the colleagues of the Research Institute CODE at the UniBwM working in the AMIUS project funded under the Bavarian Aerospace Program by the Bavarian State Ministry of Economics, Regional Development and Energy with the GA ROB-2-3410.20-04-11-15/HAMI- 2109-0015 for fruitful discussions on aeronautical communications and relevant security incentives for the target market. Thanks to SBA Research Vienna for continuous discussions on security infrastructure issues in quick developing markets such the air space and potential economic spillovers to used technologies and protocols. Thanks to the Aeronautical Communications group at the Institute of Communications and Navigation of the German Aerospace Center (DLR). With that, the authors would like to explicitly thank Miguel Angel Bellido-Manganell and Lukas Marcel Schalk for their thorough feedback. 12. Normative References 13. Informative References [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . Mäurer, et al. Expires 5 June 2023 [Page 31] Internet-Draft LDACS December 2022 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . [RFC5795] Sandlund, K., Pelletier, G., and L. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, DOI 10.17487/RFC5795, March 2010, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, "Operational Security Considerations for IPv6 Networks", RFC 9099, DOI 10.17487/RFC9099, August 2021, . [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, . [GRA2020] Gräupl, T., Rihacek, C., and B. Haindl, "LDACS A/G Specification", SESAR2020 PJ14-02-01 D3.3.030 , 2020, . Mäurer, et al. Expires 5 June 2023 [Page 32] Internet-Draft LDACS December 2022 [ARI2021] ARINC, "Internet Protocol Suite (IPS) For Aeronautical Safety Services Part 1- Airborne IP System Technical Requirements, ARINC SPECIFICATION 858 P1", June 2021, . [EURO2019] European Organization for Civil Aviation Equipment (EUROCAE), "Technical Standard of Aviation Profiles for ATN/IPS, ED-262", September 2019, . [ICAO2015] International Civil Aviation Organization (ICAO), "Manual on the Aeronautical Telecommunication Network (ATN) using Internet Protocol Suite (IPS) Standards and Protocols, Doc 9896", January 2015, . [RTCA2019] Radio Technical Commission for Aeronautics (RTCA), "Internet Protocol Suite Profiles, DO-379", September 2019, . [SCH2016] Schneckenburger, N., Jost, T., Shutin, D., Walter, M., Thiasiriphet, T., Schnell, M., and U.C. Fiebig, "Measurement of the L-band Air-to-Ground Channel for Positioning Applications", IEEE Transactions on Aerospace and Electronic Systems, 52(5), pp.2281-229 , 2016. [OSE2019] Osechas, O., Narayanan, S., Crespillo, O.G., Zampieri, G., Battista, G., Kumar, R., Schneckenburger, N., Lay, E., Belabbas, B., and M. Meurer, "Feasibility Demonstration of Terrestrial RNP with LDACS", 32nd International Technical Meeting of the Satellite Division of The Institute of Navigation, pp.1-12 , 2019. [SCHN2018] Schneckenburger, N., "A Wide-Band Air-Ground Channel Mode", Dissertation, Technische Universitaet Ilmenau, Ilmenau, Germany , 2018. [MOST2018] Mostafa, M., Bellido-Manganell, M.A.., and T. Gräupl, "Feasibility of Cell Planning for the L-Band Digital Aeronautical Communications System Under the Constraint of Secondary Spectrum Usage", IEEE Transactions on Vehicular Technology, vol. 67, no. 10, pp. 9721-9733 , 2018. [MAE20191] Mäurer, N., Gräupl, T., and C. Schmitt, "Evaluation of the LDACS Cybersecurity Implementation", IEEE 38th Digital Avionics Systems Conference (DACS), pp. 1-10, San Diego, CA, USA , 2019. Mäurer, et al. Expires 5 June 2023 [Page 33] Internet-Draft LDACS December 2022 [MAE20192] Mäurer, N. and C. Schmitt, "Towards Successful Realization of the LDACS Cybersecurity Architecture: An Updated Datalink Security Threat- and Risk Analysis", IEEE Integrated Communications, Navigation and Surveillance Conference (ICNS), pp. 1-13, Herndon, VA, USA , 2019. [MAE20182] Mäurer, N. and A. Bilzhause, "A Cybersecurity Architecture for the L-band Digital Aeronautical Communications System (LDACS)", IEEE 37th Digital Avionics Systems Conference (DASC), pp. 1-10, London, UK , 2017. [GRA2011] Gräupl, T. and M. Ehammer, "L-DACS1 Data Link Layer Evolution of ATN/IPS", 30th IEEE/AIAA Digital Avionics Systems Conference (DASC), pp. 1-28, Seattle, WA, USA , 2011. [GRA2018] Gräupl, T., Schneckenburger, N., Jost, T., Schnell, M., Filip, A., Bellido-Manganell, M.A., Mielke, D.M., Mäurer, N., Kumar, R., Osechas, O., and G. Battista, "L-band Digital Aeronautical Communications System (LDACS) flight trials in the national German project MICONAV", Integrated Communications, Navigation, Surveillance Conference (ICNS), pp. 1-7, Herndon, VA, USA , 2018. [ICAO2022] International Civil Aviation Organization (ICAO), "L-Band Digital Aeronautical Communication System (LDACS", International Standards and Recommended Practices Annex 10 - Aeronautical Telecommunications, Vol. III - Communication Systems, 2022 , 2022. [SAJ2014] Haindl, B., Meser, J., Sajatovic, M., Müller, S., Arthaber, H., Faseth, T., and M. Zaisberger, "LDACS1 Conformance and Compatibility Assessment", IEEE/AIAA 33rd Digital Avionics Systems Conference (DASC), pp. 1-11, Colorado Springs, CO, USA , 2014. [RIH2018] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S., Gräupl, T., Schnell, M., and N. Fistas, "L-band Digital Aeronautical Communications System (LDACS) Activities in SESAR2020", Integrated Communications Navigation and Surveillance Conference (ICNS), pp. 1-8, Herndon, VA, USA , 2018. [BEL2019] Bellido-Manganell, M. A. and M. Schnell, "Towards Modern Air-to-Air Communications: the LDACS A2A Mode", IEEE/AIAA 38th Digital Avionics Systems Conference (DASC), pp. 1-10, San Diego, CA, USA , 2019. Mäurer, et al. Expires 5 June 2023 [Page 34] Internet-Draft LDACS December 2022 [CRO2016] Crowe, B., "Proposed AeroMACS PKI Specification is a Model for Global and National Aeronautical PKI Deployments", WiMAX Forum at 16th Integrated Communications, Navigation and Surveillance Conference (ICNS), pp. 1-19, New York, NY, USA , 2016. [MAE2020] Mäurer, N., Gräupl, T., and C. Schmitt, "Comparing Different Diffie-Hellman Key Exchange Flavors for LDACS", IEEE/AIAA 39th Digital Avionics Systems Conference (DASC), pp. 1-10, San Antonio, TX, USA , 2020. [STR2016] Strohmeier, M., Schäfer, M., Pinheiro, R., Lenders, V., and I. Martinovic, "On Perception and Reality in Wireless Air Traffic Communication Security", IEEE Transactions on Intelligent Transportation Systems, 18(6), pp. 1338-1357, New York, NY, USA , 2016. [BIL2017] Bilzhause, A., Belgacem, B., Mostafa, M., and T. Gräupl, "Datalink Security in the L-band Digital Aeronautical Communications System (LDACS) for Air Traffic Management", IEEE Aerospace and Electronic Systems Magazine, 32(11), pp. 22-33, New York, NY, USA , 2017. [MAE20181] Mäurer, N. and A. Bilzhause, "Paving the Way for an IT Security Architecture for LDACS: A Datalink Security Threat and Risk Analysis", IEEE Integrated Communications, Navigation, Surveillance Conference (ICNS), pp. 1-11, New York, NY, USA , 2018. [FAA2020] FAA, "Federal Aviation Administration. ADS-B Privacy.", August 2020, . [GNU2021] GNU Radio project, "GNU radio", October 2021, . [SIT2020] SITA, "Societe Internationale de Telecommunications Aeronautiques", August 2020, . [ARI2020] ARINC, "Aeronautical Radio Incorporated", August 2020, . [DO350A] RTCA SC-214, "Safety and Performance Standard for Baseline 2 ATS Data Communications (Baseline 2 SPR Standard)", May 2016, . Mäurer, et al. Expires 5 June 2023 [Page 35] Internet-Draft LDACS December 2022 [ICAO2019] International Civil Aviation Organization (ICAO), "Manual on VHF Digital Link (VDL) Mode 2, Doc 9776", January 2019, . [KAMA2010] Kamali, B., "An Overview of VHF Civil Radio Network and the Resolution of Spectrum Depletion", Integrated Communications, Navigation, and Surveillance Conference, pp. F4-1-F4-8 , May 2010. [KAMA2018] Kamali, B., "AeroMACS: An IEEE 802.16 Standard-based Technology for the Next Generation of Air Transportation Systems", John Wiley and Sons, DOI: 10.1002/9781119281139 , September 2018. [NIST2013] Barker, E., "Digital Signature Standard (DSS)", National Institute of Standards and Technology (NIST), FIPS.186-4, DOI: 10.6028/NIST.FIPS.186-4 , 2013. [SON2021] Soni, D., Basu, K., Nabeel, M., Aaraj, N., Manzano, M., and R. Karri, "FALCON", Hardware Architectures for Post- Quantum Digital Signature Schemes, pp. 31-41 , November 2021. [AVA2021] Avanzi, R., Bos, J., Ducas, L., Kiltz, E., Lepoint, T., Lyubashevsky, C., Schanck, J.M., Schwabe, P., Seiler, G., and D. Stehle, "CRYSTALS-KYBER - Algorithm Specification and Supporting Documentation (version 3.02)", August 2021, . [ROY2020] Roy, S.S.. and A. Basso, "High-Speed Instruction-Set Coprocessor For Lattice-Based Key Encapsulation Mechanism: Saber In Hardware", IACR Transactions on Cryptographic Hardware and Embedded Systems, 443-466. , August 2020. [RAW-TECHNOS] Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., and J. Farkas, "Reliable and Available Wireless Technologies", Work in Progress, Internet-Draft, draft- ietf-raw-technologies-06, 30 November 2022, . Mäurer, et al. Expires 5 June 2023 [Page 36] Internet-Draft LDACS December 2022 [RAW-USE-CASES] Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F. Theoleyre, "RAW Use-Cases", Work in Progress, Internet- Draft, draft-ietf-raw-use-cases-08, 22 October 2022, . [I-D.haindl-lisp-gb-atn] Haindl, B., Lindner, M., Moreno, V., Portoles-Comeras, M., Maino, F., and B. Venkatachalapathy, "Ground-Based LISP for the Aeronautical Telecommunications Network", Work in Progress, Internet-Draft, draft-haindl-lisp-gb-atn-08, 23 September 2022, . [I-D.ietf-rtgwg-atn-bgp] Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. Moreno, "A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network", Work in Progress, Internet-Draft, draft-ietf-rtgwg-atn-bgp-19, 6 November 2022, . [I-D.ietf-lisp-rfc6830bis] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos-Aparicio, "The Locator/ID Separation Protocol (LISP)", Work in Progress, Internet-Draft, draft-ietf- lisp-rfc6830bis-38, 7 May 2022, . [I-D.ietf-lisp-rfc6833bis] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- Aparicio, "Locator/ID Separation Protocol (LISP) Control Plane", Work in Progress, Internet-Draft, draft-ietf-lisp- rfc6833bis-31, 2 May 2022, . [ICAO2018] International Civil Aviation Organization (ICAO), "Handbook on Radio Frequency Spectrum Requirements for Civil Aviation, Doc 9718, Volume 1, ICAO Spectrum Strategy, Policy Statements and Related Information", July 2018, . Mäurer, et al. Expires 5 June 2023 [Page 37] Internet-Draft LDACS December 2022 [ARI2019] ARINC, "AOC Air-Ground Data And Message Exchange Format, ARINC 633", January 2019, . [VIR2021] Virdia, A., Stea, G., and G. Dini, "SAPIENT: Enabling Real-Time Monitoring and Control in the Future Communication Infrastructure of Air Traffic Management", IEEE Transactions on Intelligent Transportation Systems, 22(8):4864-4875 , August 2021. [SHU2013] Shutin, D., Schneckenburger, N., Walter, M., and M. Schnell, "LDACS1 Ranging Performance - An Analysis Of Flight Measurement Results", IEEE 32nd Digital Avionics Systems Conference (DASC), pp. 1-10, East Syracuse, NY, USA , October 2013. [BEL2021] Bellido-Manganell, M.A., Gräupl, T., Heirich, O., Mäurer, N., Filip-Dhaubhadel, A., Mielke, D.M., Schalk, L.M., Becker, D., Schneckenburger, N., and M. Schnell, "LDACS Flight Trials: Demonstration and Performance Analysis of the Future Aeronautical Communications System", IEEE Transactions on Aerospace and Electronic Systems, pp. 1-19 , September 2021. [MAE2021] Mäurer, N., Gräupl, T., Gentsch, C., Guggemos, T., Tiepelt, M., Schmitt, C., and G. Dreo Rodosek, "A Secure Cell-Attachment Procedure for LDACS", 1st Workshop on Secure and Reliable Communication and Navigation in the Aerospace Domain (SRCNAS), pp. 1-10, Vienna, Austria , September 2021. [MAE20211] Mäurer, N., Gräupl, T., Bellido-Manganell, M.A., Mielke, D.M., Filip-Dhaubhadel, A., Heirich, O., Gerberth, D., Flux, M., Schalk, L.M., Becker, D., Schneckenburger, N., and M. Schnell, "Flight Trial Demonstration of Secure GBAS via the L-band Digital Aeronautical Communications System (LDACS)", IEEE Aerospace and Electronic Systems Magazine, 36(4), pp. 8-17 , April 2021. [BOE2019] Boegl, T., Rautenberg, M., Haindl, R., Rihacek, C., Meser, J., Fantappie, P., Pringvanich, N., Micallef, J., Klauspeter, H., MacBride, J., Sacre, P., v.d. Eiden, B., Gräupl, T., and M. Schnell, "LDACS White Paper - A Roll- out Scenario", International Civil Aviation Organization, Communications Panel - Data Communications Infrastructure Working Group - Third Meeting, pp. 1-8, Montreal, Canada , October 2019. Mäurer, et al. Expires 5 June 2023 [Page 38] Internet-Draft LDACS December 2022 Appendix A. Selected Information from DO-350A This appendix includes the continuity, availability, and integrity requirements applicable for LDACS defined in [DO350A]. The following terms are used here: CPDLC Controller Pilot Data Link Communication DT Delivery Time (nominal) value for RSP ET Expiration Time value for RCP FH Flight Hour MA Monitoring and Alerting criteria OT Overdue Delivery Time value for RSP RCP Required Communication Performance RSP Required Surveillance Performance TT Transaction Time (nominal) value for RCP +========================+=============+=============+ | | RCP 130 | RCP 130 | +========================+=============+=============+ | Parameter | ET | TT95% | +------------------------+-------------+-------------+ | Transaction Time (sec) | 130 | 67 | +------------------------+-------------+-------------+ | Continuity | 0.999 | 0.95 | +------------------------+-------------+-------------+ | Availability | 0.989 | 0.989 | +------------------------+-------------+-------------+ | Integrity | 1E-5 per FH | 1E-5 per FH | +------------------------+-------------+-------------+ Table 1: CPDLC Requirements for RCP 130 Mäurer, et al. Expires 5 June 2023 [Page 39] Internet-Draft LDACS December 2022 +========================+=========+=========+=========+=========+ | | RCP 240 | RCP 240 | RCP 400 | RCP 400 | +========================+=========+=========+=========+=========+ | Parameter | ET | TT95% | ET | TT95% | +------------------------+---------+---------+---------+---------+ | Transaction Time (sec) | 240 | 210 | 400 | 350 | +------------------------+---------+---------+---------+---------+ | Continuity | 0.999 | 0.95 | 0.999 | 0.95 | +------------------------+---------+---------+---------+---------+ | Availability | 0.989 | 0.989 | 0.989 | 0.989 | +------------------------+---------+---------+---------+---------+ | Integrity | 1E-5 | 1E-5 | 1E-5 | 1E-5 | | | per FH | per FH | per FH | per FH | +------------------------+---------+---------+---------+---------+ Table 2: CPDLC Requirements for RCP 240/400 RCP Monitoring and Alerting Criteria in case of CPDLC: - MA-1: The system shall be capable of detecting failures and configuration changes that would cause the communication service no longer meet the RCP specification for the intended use. - MA-2: When the communication service can no longer meet the RCP specification for the intended function, the flight crew and/or the controller shall take appropriate action. +==============+========+========+========+========+========+=======+ | | RSP | RSP | RSP | RSP | RSP | RSP | | | 160 | 160 | 180 | 180 | 400 | 400 | +==============+========+========+========+========+========+=======+ | Parameter | OT | DT95% | OT | DT95% | OT | DT95% | +--------------+--------+--------+--------+--------+--------+-------+ | Transaction | 160 | 90 | 180 | 90 | 400 | 300 | | Time (sec) | | | | | | | +--------------+--------+--------+--------+--------+--------+-------+ | Continuity | 0.999 | 0.95 | 0.999 | 0.95 | 0.999 | 0.95 | +--------------+--------+--------+--------+--------+--------+-------+ | Availability | 0.989 | 0.989 | 0.989 | 0.989 | 0.989 | 0.989 | +--------------+--------+--------+--------+--------+--------+-------+ | Integrity | 1E-5 | 1E-5 | 1E-5 | 1E-5 | 1E-5 | 1E-5 | | | per FH | per FH | per FH | per FH | per | per | | | | | | | FH | FH | +--------------+--------+--------+--------+--------+--------+-------+ Table 3: ADS-C Requirements RCP Monitoring and Alerting Criteria: Mäurer, et al. Expires 5 June 2023 [Page 40] Internet-Draft LDACS December 2022 - MA-1: The system shall be capable of detecting failures and configuration changes that would cause the ADS-C service no longer meet the RSP specification for the intended function. - MA-2: When the ADS-C service can no longer meet the RSP specification for the intended function, the flight crew and/or the controller shall take appropriate action. Authors' Addresses Nils Mäurer (editor) German Aerospace Center (DLR) Münchner Strasse 20 82234 Wessling Germany Email: Nils.Maeurer@dlr.de Thomas Gräupl (editor) German Aerospace Center (DLR) Münchner Strasse 20 82234 Wessling Germany Email: Thomas.Graeupl@dlr.de Corinna Schmitt (editor) Research Institute CODE, UniBwM Werner-Heisenberg-Weg 39 85577 Neubiberg Germany Email: corinna.schmitt@unibw.de Mäurer, et al. Expires 5 June 2023 [Page 41] ./draft-ietf-idr-bfd-subcode-05.txt0000644000764400076440000002603714352673535016627 0ustar iustiniustin Inter-Domain Routing J. Haas Internet-Draft Juniper Networks Intended status: Standards Track 27 December 2022 Expires: 30 June 2023 A BGP Cease Notification Subcode For Bidirectional Forwarding Detection (BFD) draft-ietf-idr-bfd-subcode-05 Abstract The Bidirectional Forwarding Detection (BFD) protocol [RFC 5880] is used to detect loss of connectivity between two forwarding engines, typically with low latency. BFD is leveraged by routing protocols, including the Border Gateway Protocol (BGP), to bring down routing protocol connections faster than the native protocol timers. This document defines a Subcode for the BGP Cease NOTIFICATION message [RFC4271], Section 6.7, for when a BGP connection is being closed due to a BFD session going down. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 June 2023. Haas Expires 30 June 2023 [Page 1] Internet-Draft BGP Cease Notification Subcode for BFD December 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. BFD Cease NOTIFICATION Subcode . . . . . . . . . . . . . . . 3 3. Operational Considerations . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] is used to detect loss of connectivity between two forwarding engines, typically with low latency. BFD is utilized as a service for various clients, including routing protocols, to provide an advisory mechanism for those clients to take appropriate actions when a BFD session goes down [RFC5882]. This is typically used by the clients to trigger closure of their connections more quickly than the native protocol timers might allow. The Border Gateway Protocol, Version 4 (BGP) [RFC4271] terminates its connections upon Hold Timer expiration when the speaker does not receive a BGP message within the negotiated Hold Time interval. As per Section 4.2 and Section 4.4 of [RFC4271], the minimum Hold Time interval is at least three seconds, unless KEEPALIVE processing has been disabled by negotiating the distinguished Hold Time of zero. If a BGP speaker desires to have its connections terminate more quickly than the negotiated BGP Hold Timer can accommodate upon loss of connectivity with a neighbor, the BFD protocol can be relied upon Haas Expires 30 June 2023 [Page 2] Internet-Draft BGP Cease Notification Subcode for BFD December 2022 by BGP speakers to supply that faster detection. When the BFD session state changes to Down, the BGP speaker terminates the connection with a Cease NOTIFICATION message sent to the neighbor, if possible, and then closes the TCP connection for the session. This document defines a subcode, "BFD Down", to be sent with the Cease NOTIFICATION message that indicates the reason for this type of connection termination. 2. BFD Cease NOTIFICATION Subcode The value 10 has been allocated by IANA for the "BFD Down" Cease NOTIFICATION message Subcode. When a BGP connection is terminated due to a BFD session going into the Down state, the BGP speaker SHOULD send a NOTIFICATION message with the Error Code Cease and the Error Subcode "BFD Down". 3. Operational Considerations A BFD session may go Down when there is only a partial loss of connectivity between two BGP speakers. Operators using BFD for their BGP connections make choices for what BFD timers are used based upon a variety of criteria; for example, stability vs. fast failure. In the event of a BGP connection being terminated due to a BFD Down event from partial loss of connectivity as detected by BFD, the remote BGP speaker might be able to receive a BGP Cease NOTIFICATION message with the BFD Down Subcode. The receiving BGP speaker will then have an understanding that the connection is being terminated because of a BFD-detected issue and not an issue with the BGP speaker. When there is a total loss of connectivity between two BGP speakers, it may not have been possible for the Cease NOTIFICATION message to have been sent. Even so, BGP speakers SHOULD provide this reason as part of their operational state. Examples include bgpPeerLastError in the BGP MIB [RFC4273], and "last-error" in [I-D.ietf-idr-bgp-model]. When the procedures in [RFC8538] for sending a NOTIFICATION message with a Cease Code and Hard Reset Subcode are required, and the BGP connection is being terminated because BFD has gone Down, the BFD Down Subcode SHOULD be encapsulated in the Hard Reset's data portion of the NOTIFICATION message. Haas Expires 30 June 2023 [Page 3] Internet-Draft BGP Cease Notification Subcode for BFD December 2022 4. Security Considerations Similar to [RFC4486], this document defines a subcode for the BGP Cease NOTIFICATION message that provides information to aid network operators in correlating network events and diagnosing BGP peering issues. This subcode is purely informational and has no impact on the BGP Finite State Machine beyond that already documented by [RFC4271], Section 6.7. 5. IANA Considerations NOTE TO IANA and the RFC Editor: IANA is requested to make the temporary allocation below permanent. The RFC Editor is requested to delete this note to IANA prior to publication. IANA has assigned the value 10 from the BGP Cease NOTIFICATION message subcodes registry (https://www.iana.org/assignments/bgp- parameters/bgp-parameters.xhtml#bgp-parameters-8) with the Name "BFD Down", and a Reference to this document. 6. Acknowledgments Thanks to Jeff Tantsura, and Dale Carder for their comments on the draft. Mohamed Boucadair provided feedback as part of Routing Directorate review of this document. Bruno Rijsman had a substantively similar proposal to this document in 2006; draft-rijsman-bfd-down-subcode. That draft did not progress in IDR at that time. The author of this draft was unaware of Bruno's prior work when creating this proposal. 7. References 7.1. Normative References [RFC2119] Bradner, S. and RFC Publisher, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., Hares, S., Ed., and RFC Publisher, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . Haas Expires 30 June 2023 [Page 4] Internet-Draft BGP Cease Notification Subcode for BFD December 2022 [RFC5880] Katz, D., Ward, D., and RFC Publisher, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5882] Katz, D., Ward, D., and RFC Publisher, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, DOI 10.17487/RFC5882, June 2010, . [RFC8174] Leiba, B. and RFC Publisher, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8538] Patel, K., Fernando, R., Scudder, J., Haas, J., and RFC Publisher, "Notification Message Support for BGP Graceful Restart", RFC 8538, DOI 10.17487/RFC8538, March 2019, . 7.2. Informative References [I-D.ietf-idr-bgp-model] Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP YANG Model for Service Provider Networks", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-15, 13 October 2022, . [RFC4273] Haas, J., Ed., Hares, S., Ed., and RFC Publisher, "Definitions of Managed Objects for BGP-4", RFC 4273, DOI 10.17487/RFC4273, January 2006, . [RFC4486] Chen, E., Gillet, V., and RFC Publisher, "Subcodes for BGP Cease Notification Message", RFC 4486, DOI 10.17487/RFC4486, April 2006, . Author's Address Jeffrey Haas Juniper Networks Email: jhaas@juniper.net Haas Expires 30 June 2023 [Page 5] ./draft-ietf-lsr-ospf-l2bundles-10.txt0000644000764400076440000006120614320067601017306 0ustar iustiniustin Link State Routing K. Talaulikar, Ed. Internet-Draft P. Psenak Updates: 9085 (if approved) Cisco Systems Intended status: Standards Track 7 October 2022 Expires: 10 April 2023 Advertising Layer 2 Bundle Member Link Attributes in OSPF draft-ietf-lsr-ospf-l2bundles-10 Abstract There are deployments where the Layer 3 (L3) interface on which OSPF operates is a Layer 2 (L2) interface bundle. Existing OSPF advertisements only support advertising link attributes of the Layer 3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links which comprise the Layer 2 interface bundle, link attribute information for the bundle members is required. This document defines the protocol extensions for OSPF to advertise the link attributes of L2 bundle members. The document also specifies the advertisment of these OSPF extensions via BGP Link State protocol and thereby updates RFC9085. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 10 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Talaulikar & Psenak Expires 10 April 2023 [Page 1] Internet-Draft OSPF L2 Bundle Member Link Attributes October 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. L2 Bundle Member Attributes . . . . . . . . . . . . . . . . . 4 3. BGP-LS Advertisement . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Operational Considerations . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informational References . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction There are deployments where the Layer 3 interface on which an OSPF adjacency is established is a Layer 2 interface bundle, for instance a Link Aggregation Group (LAG) [IEEE802.1AX]. This reduces the number of adjacencies that need to be maintained by the OSPF protocol in cases where there are parallel links between the neighbors. Entities external to OSPF such as Path Computation Elements (PCE) [RFC4655] may wish to control traffic flows on individual Layer 2 member links of the underlying bundle (e.g., LAG) interface. To do so, link attribute information for individual bundle members is required. The protocol extensions defined in this document provide the means to advertise this information. This document defines sub-TLVs to advertise link attribute information for each of the L2 bundle members which comprise the Layer 3 interface on which OSPF operates. Similar capabilities were introduced in IS-IS via [RFC8668]. Talaulikar & Psenak Expires 10 April 2023 [Page 2] Internet-Draft OSPF L2 Bundle Member Link Attributes October 2022 [RFC8665] and [RFC8666] introduced the adjacency segment identifier (Adj-SID) link attribute for OSPFv2 and OSPFv3 respectively which can be used as an instruction to forwarding to send traffic over a specific link [RFC8402]. This document enables the advertisement of the Adj-SIDs using the same Adjacency SID Sub-TLV at the granularity level of each L2 bundle member link so that traffic may be steered over that specific member link. Note that the advertisements at the L2 bundle member link-level defined in this document are intended to be provided to external (to OSPF) entities and do not alter or change the OSPF route computation. The following items are intentionally not defined and are outside the scope of this document: * What link attributes will be advertised. This is determined by the needs of the external entities. * A minimum or default set of link attributes. * How these attributes are configured. * How the advertisements are used. * What impact the use of these advertisements may have on traffic flow in the network. * How the advertisements are passed to external entities. The BGP Link State (BGP-LS) [RFC7752] was extended for the advertisement of Layer 2 bundle members and their attributes by [RFC9085] which covered only IS-IS. This document updates [RFC9085] by specifying the advertisement from OSPF (refer Section 3). 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Talaulikar & Psenak Expires 10 April 2023 [Page 3] Internet-Draft OSPF L2 Bundle Member Link Attributes October 2022 2. L2 Bundle Member Attributes A new L2 Bundle Member Attributes Sub-TLV is introduced to advertise L2 bundle member attributes in both OSPFv2 and OSPFv3. In the case of OSPFv2, this sub-TLV is an optional sub-TLV of the OSPFv2 Extended Link TLV that is used to describe link attributes via the OSPFv2 Extended Link Opaque LSA [RFC7684]. In the case of OSPFv3, this sub- TLV is an optional sub-TLV of the Router Link TLV of the OSPFv3 E- Router-LSA [RFC8362]. When the OSPF adjacency is associated with an L2 bundle interface, this sub-TLV is used to advertise the underlying L2 bundle member links along with their respective link attributes. The inclusion of this information implies that the identified link is a member of the L2 bundle associated with an OSPF L3 link and that the member link is operationally up. Therefore, advertisements of member links MUST NOT be done when the member link becomes operationally down or it is no longer a member of the identified L2 bundle. The advertisement of the L2 Bundle Member Attributes Sub-TLV may be asymmetric for an OSPF link depending on the underlying layer 2 connectivity i.e., advertised by the router on only one end. The L2 Bundle Member Attributes Sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2 Bundle Member Descriptor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Member Link Attribute sub-TLVs (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: L2 Bundle Member Attributes sub-TLV Format Where: Type: 24 for OSPFv2 and 29 for OSPFv3 Length: The total length (in octets) of the value portion of the TLV including nested Sub-TLVs. L2 Bundle Member Descriptor: A 4 octet Link Local Identifier as described in [RFC4202] and used in [RFC8510] for the member link. Talaulikar & Psenak Expires 10 April 2023 [Page 4] Internet-Draft OSPF L2 Bundle Member Link Attributes October 2022 Link attributes for L2 bundle member links are advertised as sub-TLVs of the L2 Bundle Member Attribute Sub-TLV. In the case of OSPFv2, the L2 Bundle Member Attributes Sub-TLV shares the sub-TLV space of the Extended Link TLV and the sub-TLVs of the Extended Link TLV MAY be used to describe the attributes of the member link. Figure 2 below lists sub-TLVs and their applicability for L2 bundle member links. The sub-TLVs that are not applicable MUST NOT be used as sub-TLVs for the L2 Bundle Member Attributes Sub- TLV. Specifications that introduce new sub-TLVs of the Extended Link TLV MUST indicate their applicability for the L2 Bundle Member Attributes Sub-TLV. Typically, attributes that have Layer 3 semantics would not be applicable while Layer 2 attributes would apply. An implementation MUST ignore any sub-TLVs received that are not applicable in the context of the L2 Bundle Member Attribute Sub- TLV. Y - applicable N - not-applicable 1 SID/Label (N) 2 Adj-SID (Y) 3 LAN Adj-SID/Label (Y) 4 Network-to-Router Metric (N) 5 RTM Capability (N) 6 OSPFv2 Link MSD (N) 7 Graceful-Link-Shutdown (N) 8 Remote IPv4 Address (N) 9 Local/Remote Interface ID (N) 10 Application Specific Link Attributes (Y) 11 Shared Risk Link Group (Y) 12 Unidirectional Link Delay (Y) 13 Min/Max Unidirectional Link Delay (Y) 14 Unidirectional Delay Variation (Y) 15 Unidirectional Link Loss (Y) 16 Unidirectional Residual Bandwidth (Y) 17 Unidirectional Available Bandwidth (Y) 18 Unidirectional Utilized Bandwidth (Y) 19 Administrative Group (Y) 20 Extended Administrative Group (Y) 21 OSPFv2 Link Attributes Bits (N) 22 TE Metric (Y) 23 Maximum Link Bandwidth (Y) 24 L2 Bundle Member Attributes (N) Figure 2: Applicability of OSPFv2 Link Attribute Sub-TLVs for L2 Bundle Members Talaulikar & Psenak Expires 10 April 2023 [Page 5] Internet-Draft OSPF L2 Bundle Member Link Attributes October 2022 In the case of OSPFv3, the L2 Bundle Member Attributes Sub-TLV shares the sub-TLV space of the Router Link TLV and the sub-TLVs of the Router Link TLV MAY be used to describe the attributes of the member link. Figure 3 below lists sub-TLVs that are applicable to the Router Link TLV and their applicability for L2 bundle member links. The sub-TLVs that are not applicable MUST NOT be used as sub-TLVs for the L2 Bundle Member Attributes Sub-TLV. Specifications that introduce new sub-TLVs of the Router Link TLV MUST indicate their applicability for the L2 Bundle Member Attributes Sub-TLV. An implementation MUST ignore any sub-TLVs received that are not applicable in the context of the L2 Bundle Member Attribute Sub-TLV. Y - applicable N - not-applicable X - not Router Link Sub-TLV 1 IPv6-Forwarding-Address (X) 2 IPv4-Forwarding-Address (X) 3 Route-Tag (X) 4 Prefix SID (X) 5 Adj-SID (Y) 6 LAN Adj-SID (Y) 7 SID/Label (N) 8 Graceful-Link-Shutdown (N) 9 OSPFv3 Link MSD (N) 10 OSPFv3 Link Attribute Bits (N) 11 Application Specific Link Attributes (Y) 12 Shared Risk Link Group (Y) 13 Unidirectional Link Delay (Y) 14 Min/Max Unidirectional Link Delay (Y) 15 Unidirectional Delay Variation (Y) 16 Unidirectional Link Loss (Y) 17 Unidirectional Residual Bandwidth (Y) 18 Unidirectional Available Bandwidth (Y) 19 Unidirectional Utilized Bandwidth (Y) 20 Administrative Group (Y) 21 Extended Administrative Group (Y) 22 Traffic Engineering Metric (Y) 23 Maximum Link Bandwidth (Y) 24 Local Interface IPv6 Address (N) 25 Remote Interface IPv6 Address (N) 26 Flex-Algorithm Prefix Metric (X) 27 Prefix Source OSPF Router-ID (X) 28 Prefix Source Router Address (X) 29 L2 Bundle Member Attributes (N) 30 SRv6 SID Structure (Y) 31 SRv6 End.X SID Structure (Y) 32 SRv6 End.X SID Structure (Y) Talaulikar & Psenak Expires 10 April 2023 [Page 6] Internet-Draft OSPF L2 Bundle Member Link Attributes October 2022 Figure 3: Applicability of OSPFv3 Link Attribute Sub-TLVs for L2 Bundle Members 3. BGP-LS Advertisement The BGP-LS extensions for the advertisment of Layer 2 bundle members and their attributes was specified in [RFC9085]. Using the OSPF L2 Bundle Member Attributes sub-TLV defined in this document, the L2 bundle member information can now be advertised from OSPF into BGP-LS on the same lines as discussed for IS-IS in section 2.2.3 of [RFC9085]. 4. IANA Considerations IANA has allocated the following code point via early allocation in the "OSPFv2 Extended Link TLV Sub-TLVs" registry under the "OSPFv2 Parameters" registry that needs to be made permanent: Value: 24 Name: L2 Bundle Member Attributes IANA has allocated the following code point via early allocation in the "OSPFv3 Extended LSA Sub-TLVs" registry under the "OSPFv3 Parameters" registry that needs to be made permanent: Value: 29 Name: L2 Bundle Member Attributes IANA is requested to introduce a column "Applicability to L2 Bundle Member sub-TLV" (abbreviated as L2BM) in the registry tables for the "OSPFv2 Extended Link TLV Sub-TLVs" registry with the initial updates (Y/N) against allocations as indicated in Figure 2. An explanatory note is also to be added to this registry as follows: The column for the Applicability to L2 Bundle Member sub-TLV (L2BM) may be marked as follows: Y - sub-TLV MAY appear in L2 Bundle Member sub-TLV N - sub-TLV MUST NOT appear in L2 Bundle Member sub-TLV Similarly, IANA is requested to introduce a column "Applicability to L2 Bundle Member sub-TLV" (abbreviated as L2BM) in the registry tables for the "OSPFv3 Extended LSA Sub-TLVs" registry with the initial updates (Y/N/X) against allocations as indicated in Figure 3. Talaulikar & Psenak Expires 10 April 2023 [Page 7] Internet-Draft OSPF L2 Bundle Member Link Attributes October 2022 The column for the Applicability to L2 Bundle Member sub-TLV (L2BM) may be marked as follows: Y - sub-TLV MAY appear in L2 Bundle Member sub-TLV N - sub-TLV MUST NOT appear in L2 Bundle Member sub-TLV X - sub-TLV is not a Router Link sub-TLV; it MUST NOT appear in L2 Bundle Member sub-TLV Further allocations from these two registries are required to indicate the applicability of the introduced sub-TLV to the L2 Bundle Member sub-TLV that would get updated in these registries. 5. Operational Considerations Implementations MUST NOT enable the advertisement of Layer 2 bundle member links and their attributes in OSPF LSAs by default and MUST provide a configuration option to enable their advertisement on specific links. [I-D.ietf-ospf-yang] specifies the base OSPF YANG model. The required configuration and operational elements for this feature are expected to be introduce as augmentation to this base OSPF YANG model. 6. Security Considerations The OSPF protocol has supported the advertisement of link attribute information, including link identifiers, for many years. The advertisements defined in this document are identical to existing advertisements defined in [RFC3630], [RFC4203], [RFC5329], [RFC7471], [RFC8665], and [RFC8666] - but are associated with L2 links which are part of a bundle interface on which the OSPF protocol operates. Therefore, the security considerations of these documents are applicable and there are no new security issues introduced by the extensions in this document. As always, if the protocol is used in an environment where unauthorized access to the physical links on which OSPF packets are sent occurs then attacks are possible. The use of authentication as defined in [RFC5709], [RFC7474], [RFC4552], and [RFC7166] is recommended for preventing such attacks. 7. Acknowledgements This document leverages the similar work done for IS-IS and the authors of this document would like to acknowledge the contributions of the authors of [RFC8668]. Talaulikar & Psenak Expires 10 April 2023 [Page 8] Internet-Draft OSPF L2 Bundle Member Link Attributes October 2022 The authors would like to thank Anoop Ghanwani, Paul Kyzivat, Dan Romascanu, and Russ Mundy for their review and feedback on this document. The authors would also like to thank Acee Lindem for his detailed shepherd review of this document. The authors would also like to thank John Scudder for his AD review and the discussion related to the applicability of TLVs/sub-TLVs to the L2 Bundle Member TLV. 8. References 8.1. Normative References [IEEE802.1AX] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation IEEE Std 802.1AX-2020 (Revision of IEEE Std 802.1AX-2014)", 30 January 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, . Talaulikar & Psenak Expires 10 April 2023 [Page 9] Internet-Draft OSPF L2 Bundle Member Link Attributes October 2022 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, December 2019, . [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, H., and M. Chen, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing", RFC 9085, DOI 10.17487/RFC9085, August 2021, . 8.2. Informational References [I-D.ietf-ospf-yang] Yeung, D., Qu, Y., Zhang, J., Chen, I., and A. Lindem, "YANG Data Model for OSPF Protocol", Work in Progress, Internet-Draft, draft-ietf-ospf-yang-29, 17 October 2019, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, . [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, . [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, . [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, DOI 10.17487/RFC5709, October 2009, . Talaulikar & Psenak Expires 10 April 2023 [Page 10] Internet-Draft OSPF L2 Bundle Member Link Attributes October 2022 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, . [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8510] Psenak, P., Ed., Talaulikar, K., Henderickx, W., and P. Pillay-Esnault, "OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement", RFC 8510, DOI 10.17487/RFC8510, January 2019, . [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, "Advertising Layer 2 Bundle Member Link Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, December 2019, . Authors' Addresses Ketan Talaulikar (editor) Cisco Systems India Email: ketant.ietf@gmail.com Peter Psenak Cisco Systems Apollo Business Center Talaulikar & Psenak Expires 10 April 2023 [Page 11] Internet-Draft OSPF L2 Bundle Member Link Attributes October 2022 Mlynske nivy 43 821 09 Bratislava Slovakia Email: ppsenak@cisco.com Talaulikar & Psenak Expires 10 April 2023 [Page 12] ./draft-ietf-idr-bgp-ls-flex-algo-12.txt0000644000764400076440000010257214301553366017500 0ustar iustiniustin Inter-Domain Routing K. Talaulikar, Ed. Internet-Draft Arrcus, Inc Intended status: Standards Track P. Psenak Expires: 26 February 2023 Cisco Systems S. Zandi G. Dawra LinkedIn 25 August 2022 Flexible Algorithm Advertisement using BGP Link-State draft-ietf-idr-bgp-ls-flex-algo-12 Abstract Flexible Algorithm is a solution that allows some routing protocols (e.g., OSPF and IS-IS) to compute paths over a network based on user- defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition. This Definition is provisioned on one or more routers and propagated through the network by OSPF and IS-IS flooding. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. This document defines extensions to the BGP-LS address family to advertise the Flexible Algorithm Definition as a part of the topology information from the network. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 February 2023. Talaulikar, et al. Expires 26 February 2023 [Page 1] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Overview of BGP-LS Extensions for Flexible Algorithm . . . . 4 3. Flexible Algorithm Definition TLV . . . . . . . . . . . . . . 4 3.1. Flexible Algorithm Exclude Any Affinity Sub-TLV . . . . . 6 3.2. Flexible Algorithm Include Any Affinity Sub-TLV . . . . . 6 3.3. Flexible Algorithm Include All Affinity Sub-TLV . . . . . 7 3.4. Flexible Algorithm Definition Flags Sub-TLV . . . . . . . 8 3.5. Flexible Algorithm Exclude SRLG Sub-TLV . . . . . . . . . 9 3.6. Flexible Algorithm Unsupported Sub-TLV . . . . . . . . . 10 4. Flexible Algorithm Prefix Metric TLV . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Manageability Considerations . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The classical IGP (e.g., OSPF and IS-IS) computation of best paths over the network is based on the IGP metric assigned to the links in the network. Many network deployments use RSVP-TE-based [RFC3209] or Segment Routing (SR) Policy-based [RFC8402] solutions to enforce traffic over a path that is computed using different metrics or constraints than the shortest IGP path. [I-D.ietf-lsr-flex-algo] defines the Flexible Algorithm solution that allows IGPs themselves to compute constraint based paths over the network. Talaulikar, et al. Expires 26 February 2023 [Page 2] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 Flexible Algorithm is so called because it allows a user the flexibility to define * the type of calculation to be used (e.g., shortest path) * the metric type to be used (e.g., IGP metric or TE metric) * the set of constraints to be used (e.g., inclusion or exclusion of certain links using affinities) The operations of the IGP flexible algorithm solution are described in detail in [I-D.ietf-lsr-flex-algo]. The BGP-LS extensions for SR are defined in [RFC9085] and [I-D.ietf-idr-bgpls-srv6-ext] for SR-MPLS and Segment Routing over IPv6 (SRv6), respectively. They include the extensions for advertisement of SR information including various types of Segment Identifiers (SIDs) as below: * SR Algorithm TLV to indicate the participation of a node in a flexible algorithm computation * Prefix-SID TLV to indicate the association of the Prefix-SIDs to a specific flexible algorithm for SR-MPLS forwarding * SRv6 Locator TLV to indicate the Locator for specific flexible algorithm for SRv6 forwarding This document defines extensions to BGP-LS for the advertisement of the Flexible Algorithm Definition (FAD) information to enable learning of the mapping of the flexible algorithm number to its Definition in each area/domain of the underlying IGP. This Definition indicates the type of computation used and the constraints for a given flexible algorithm. This information can then be used for setting up SR Policy paths end to end across domains by using the appropriate flexible algorithm-specific SIDs in its Segment List [RFC9256]. For example, picking the flexible algorithm Prefix SID (in case of SR-MPLS) or End SID (in case of SRv6) of Area Border Routers (ABRs) or Autonomous System Border Routers (ASBRs) corresponding to a Definition that optimizes on the delay metric enables the building of an end to end low latency path across IGP domains with minimal SIDs in the SID list. Talaulikar, et al. Expires 26 February 2023 [Page 3] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Overview of BGP-LS Extensions for Flexible Algorithm BGP-LS [RFC7752] specifies the Node Network Layer Reachability Information (NLRI) for the advertisement of nodes along with their attributes using the BGP-LS Attribute, the Link NLRI for the advertisement of links along with their attributes using the BGP-LS Attribute and the Prefix NLRI for the advertisement of prefixes along with their attributes using the BGP-LS Attribute. The FADs advertised by a node are considered as a node-level attribute and advertised as specified in Section 3. Various link attributes like affinities and Shared Risk Link Group (SRLG) that are used during the Flexible Algorithm route calculations in IS-IS and OSPF are advertised in those protocols using the Application Specific Link Attribute (ASLA) advertisements as described in [RFC8919], [RFC8920], and [I-D.ietf-lsr-flex-algo]. The BGP-LS extensions for ASLA advertisements are specified in [RFC9294]. The Flexible Algorithm Prefix Metric (FAPM) is considered as a prefix attribute and advertised as specified in Section 4. 3. Flexible Algorithm Definition TLV This document defines a new optional BGP-LS Attribute TLV associated with the Node NLRI called the Flexible Algorithm Definition (FAD) TLV and its format is as follows: Talaulikar, et al. Expires 26 February 2023 [Page 4] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flex Algo | Metric-Type | Calc-Type | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs ... // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Flexible Algorithm Definition TLV where: * Type: 1039 * Length: The total length of the value field (including any sub- TLVs) in octets. The length value MUST be 4 or larger. * Flexible Algorithm (Flex Algo): Single octet value carrying the flexible algorithm number between 128 and 255 inclusive, as defined in [I-D.ietf-lsr-flex-algo]. * Metric-Type: Single octet value carrying the metric type, as defined in [I-D.ietf-lsr-flex-algo]. * Calc-Type: Single octet value carrying the calculation type, as defined in [I-D.ietf-lsr-flex-algo]. * Priority: Single octet value carrying the priority of the FAD advertisement, as defined in [I-D.ietf-lsr-flex-algo]. * sub-TLVs: zero or more sub-TLVs may be included as described further in this section. The FAD TLV that is advertised in the BGP-LS Attribute along with the Node NLRI of a node is derived from the following IGP protocol- specific advertisements: * In the case of IS-IS, from the IS-IS Flexible Algorithm Definition sub-TLV in [I-D.ietf-lsr-flex-algo]. * In the case of OSPFv2/OSPFv3, from the OSPF Flexible Algorithm Definition TLV in [I-D.ietf-lsr-flex-algo]. The BGP-LS Attribute associated with a Node NLRI may include one or more FAD TLVs corresponding to the FAD for each algorithm that the particular node is advertising. Talaulikar, et al. Expires 26 February 2023 [Page 5] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 The following sub-sections define sub-TLVs of the FAD TLV. 3.1. Flexible Algorithm Exclude Any Affinity Sub-TLV The Flexible Algorithm Exclude Any Affinity sub-TLV is an optional sub-TLV that is used to carry the affinity constraints associated with the FAD and enable the exclusion of links carrying any of the specified affinities from the computation of the specific algorithm as described in [I-D.ietf-lsr-flex-algo]. The affinity is expressed in terms of Extended Admin Group (EAG) as defined in [RFC7308]. The sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclude-Any EAG (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Flexible Algorithm Exclude Any Affinity sub-TLV where: * Type: 1040 * Length: The total length of the value field in octets dependent on the size of the EAG. It MUST be a non-zero value and a multiple of 4. * Exclude-Any EAG: the EAG value as defined in [I-D.ietf-lsr-flex-algo]. The information in the Flexible Algorithm Exclude Any Affinity sub- TLV is derived from the IS-IS and OSPF protocol-specific Flexible Algorithm Exclude Admin Group sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 3.2. Flexible Algorithm Include Any Affinity Sub-TLV The Flexible Algorithm Include Any Affinity sub-TLV is an optional sub-TLV that is used to carry the affinity constraints associated with the FAD and enable the inclusion of links carrying any of the specified affinities in the computation of the specific algorithm as described in [I-D.ietf-lsr-flex-algo]. The affinity is expressed in terms of Extended Admin Group (EAG) as defined in [RFC7308]. Talaulikar, et al. Expires 26 February 2023 [Page 6] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 The sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include-Any EAG (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Flexible Algorithm Include Any Affinity sub-TLV where: * Type: 1041 * Length: The total length of the value field in octets dependent on the size of the EAG. It MUST be a non-zero value and a multiple of 4. * Include-Any EAG: the EAG value as defined in [I-D.ietf-lsr-flex-algo]. The information in the Flexible Algorithm Include Any Affinity sub- TLV is derived from the IS-IS and OSPF protocol-specific Flexible Algorithm Include-Any Admin Group sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 3.3. Flexible Algorithm Include All Affinity Sub-TLV The Flexible Algorithm Include All Affinity sub-TLV is an optional sub-TLV that is used to carry the affinity constraints associated with the FAD and enable the inclusion of links carrying all of the specified affinities in the computation of the specific algorithm as described in [I-D.ietf-lsr-flex-algo]. The affinity is expressed in terms of Extended Admin Group (EAG) as defined in [RFC7308]. The sub-TLV has the following format: Talaulikar, et al. Expires 26 February 2023 [Page 7] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include-All EAG (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Flexible Algorithm Include All Affinity sub-TLV where: * Type: 1042 * Length: The total length of the value field in octets dependent on the size of the EAG. It MUST be a non-zero value and a multiple of 4. * Include-All EAG: the EAG value as defined in [I-D.ietf-lsr-flex-algo]. The information in the Flexible Algorithm Include All Affinity sub- TLV is derived from the IS-IS and OSPF protocol-specific Flexible Algorithm Include-All Admin Group sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 3.4. Flexible Algorithm Definition Flags Sub-TLV The Flexible Algorithm Definition Flags sub-TLV is an optional sub- TLV that is used to carry the flags associated with the FAD that are used in the computation of the specific algorithm as described in [I-D.ietf-lsr-flex-algo]. The sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Flexible Algorithm Definition Flags sub-TLV where: * Type: 1043 Talaulikar, et al. Expires 26 February 2023 [Page 8] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 * Length: The total length of the value field in octets dependent on the size of the Flags. It MUST be a non-zero value and a multiple of 4. * Flags: the bitmask used to represent the flags for the FAD, as defined in [I-D.ietf-lsr-flex-algo]. The information in the Flexible Algorithm Definition Flags sub-TLV is derived from the IS-IS and OSPF protocol-specific Flexible Algorithm Definition Flags sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 3.5. Flexible Algorithm Exclude SRLG Sub-TLV The Flexible Algorithm Exclude SRLG sub-TLV is an optional sub-TLV that is used to carry the Shared Risk Link Group (SRLG) information associated with the FAD and enable the exclusion of links that are associated with any of the specified SRLG in the computation of the specific algorithm as described in [I-D.ietf-lsr-flex-algo]. The SRLGs associated with a link are carried in the BGP-LS Shared Link Risk Group (TLV 1096) [RFC7752]. The sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Risk Link Group Values (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Flexible Algorithm Exclude SRLG sub-TLV where: * Type: 1045 * Length: The total length of the value field in octets dependent on the number of SRLG values carried. It MUST be a non-zero value and a multiple of 4. * Shared Risk Link Group Values: One or more SRLG values, each of 4 octet size, as defined in [I-D.ietf-lsr-flex-algo]. The information in the Flexible Algorithm SRLG Exclude sub-TLV is derived from the IS-IS and OSPF protocol-specific Flexible Algorithm Exclude SRLG sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. Talaulikar, et al. Expires 26 February 2023 [Page 9] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 3.6. Flexible Algorithm Unsupported Sub-TLV The OSPF and IS-IS signaling for FAD allows for extensions via new sub-TLVs under the respective IGP's Flexible Algorithm Definition TLV. As specified in section 5.3 of [I-D.ietf-lsr-flex-algo], it is important that the entire FAD be understood by anyone using it for computation purpose. Therefore, the FAD is different from most other protocol extensions where the skipping or ignoring of unsupported sub-TLV information does not affect the base behavior. The Flexible Algorithm Unsupported sub-TLV is an optional sub-TLV that is used to indicate the presence of unsupported FAD sub-TLVs. The need for this sub-TLV arises when the BGP-LS implementation on the advertising node does not support one or more of the FAD sub-TLVs present in the IGP advertisement. The sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol-ID | sub-TLV types (variable) ... // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Flexible Algorithm Unsupported sub-TLV where: * Type: TBD (Note to Editor: The code point allocation, once made by IANA, needs to be updated here - refer to Section 5) * Length: The total length of the value field in octets (including any included sub-TLV types). * Protocol-ID: Indicates the BGP-LS Protocol-ID of the protocol from which the FAD is being advertised via BGP-LS. The values are from the "BGP-LS Protocol-IDs" registry under the IANA BGP-LS Parameters registry. Talaulikar, et al. Expires 26 February 2023 [Page 10] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 * sub-TLV types: Zero or more sub-TLV types that are not supported by the node originating the BGP-LS advertisement. The size of each sub-TLV type depends on the protocol indicated by the Protocol-ID field. For example, for IS-IS each sub-TLV type would be of size 1 octet while for OSPF each sub-TLV type would be of size 2 octets. The node originating the advertisement MUST include the Flexible Algorithm Unsupported sub-TLV when it comes across an unsupported sub-TLV in the corresponding FAD in the IS-IS and OSPF advertisement. When advertising the Flexible Algorithm Unsupported sub-TLV, the protocol-specific sub-TLV types that are not supported SHOULD be included. This information serves as a diagnostic aid. The discussion on the use of the FAD information by the consumers of the BGP-LS information is beyond the scope of this document. However, it is RECOMMENDED that the choice of the node used for originating the IGP topology information into BGP-LS be made such that the advertising node supports all the FAD extensions in use in its part of the network. This avoids the scenario where an incomplete FAD gets advertised via BGP-LS. 4. Flexible Algorithm Prefix Metric TLV This document defines a new optional BGP-LS Attribute TLV associated with the Prefix NLRI called the Flexible Algorithm Prefix Metric (FAPM) TLV and its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flex Algo | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Flexible Algorithm Prefix Metric TLV where: * Type: 1044 * Length: 8 octets. Talaulikar, et al. Expires 26 February 2023 [Page 11] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 * Flexible Algorithm (Flex Algo): Single octet value carrying the flexible algorithm number between 128 and 255 inclusive, as defined in [I-D.ietf-lsr-flex-algo]. * Flags: single octet value and only applicable for OSPF as defined in [I-D.ietf-lsr-flex-algo]. The value MUST be set to 0 for IS- IS. * Reserved: 2 octet value that MUST be set to 0 by the originator and MUST be ignored by the receiver. * Metric: 4 octets field to carry the metric information. The FAPM TLV that is advertised in the BGP-LS Attribute along with the Prefix NLRI from a node is derived from the following IGP protocol-specific advertisements: * In the case of IS-IS, from the IS-IS Flexible Algorithm Prefix Metric sub-TLV in [I-D.ietf-lsr-flex-algo]. * In the case of OSPFv2/OSPFv3, from the OSPF Flexible Algorithm Prefix Metric sub-TLV in [I-D.ietf-lsr-flex-algo]. The BGP-LS Attribute associated with a Prefix NLRI may include one or more FAPM TLVs corresponding to the Flexible Algorithm Prefix Metric for each algorithm associated with that particular prefix. 5. IANA Considerations IANA has allocated code points from the registry "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" based on the table below for the TLVs/sub-TLVs introduced by this document. This document requests IANA to allocate the pending code point for the Flexible Algorithm Unsupported sub-TLV as suggested below. The column "IS-IS TLV/Sub-TLV" defined in the registry does not require any value and should be left empty. Talaulikar, et al. Expires 26 February 2023 [Page 12] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 +------------+-----------------------------------------+ | Code Point | Description | +------------+-----------------------------------------+ | 1039 | Flexible Algorithm Definition | | 1040 | Flexible Algorithm Exclude Any Affinity | | 1041 | Flexible Algorithm Include Any Affinity | | 1042 | Flexible Algorithm Include All Affinity | | 1043 | Flexible Algorithm Definition Flags | | 1044 | Flexible Algorithm Prefix Metric | | 1045 | Flexible Algorithm Exclude SRLG | | 1046 (Sugg)| Flexible Algorithm Unsupported | +------------+-----------------------------------------+ Table 1: Flexible Algorithm Code Points 6. Manageability Considerations The new protocol extensions introduced in this document augment the existing IGP topology information that can be distributed via [RFC7752]. Procedures and protocol extensions defined in this document do not affect the BGP protocol operations and management other than as discussed in the Manageability Considerations section of [RFC7752]. Specifically, the malformed NLRIs attribute tests in the Fault Management section of [RFC7752] now encompass the new TLVs for the BGP-LS NLRI in this document. The extensions specified in this document do not specify any new configuration or monitoring aspects in BGP or BGP-LS. The specification of BGP models is an ongoing work based on [I-D.ietf-idr-bgp-model]. 7. Security Considerations Security considerations for acquiring and distributing BGP-LS information are discussed in [RFC7752]. The TLVs introduced in this document are used to propagate the IGP Flexible Algorithm extensions defined in [I-D.ietf-lsr-flex-algo]. It is assumed that the IGP instances originating these TLVs will support all the required security (as described in [I-D.ietf-lsr-flex-algo]) for Flexible Algorithm deployment. Talaulikar, et al. Expires 26 February 2023 [Page 13] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 This document specifies extensions for the advertisement of node and prefix related flexible algorithm information. Tampering with this flexible algorithm-related information may affect applications using it, including impacting route calculation and programming. As the advertisements defined in this document are related to a specific flexible algorithm topology, the impact of tampering is similarly limited in scope. 8. Acknowledgements The authors would like to thank Les Ginsberg, Amalesh Maity, Y F Siu, Vijay Gurbani, and Donald Eastlake III for their reviews and contributions to this work. The authors would like to thank Jie Dong for his shepherd review. The authors would like to thank Alvaro Retana for his detailed AD review and suggestions for improving this document. 9. References 9.1. Normative References [I-D.ietf-lsr-flex-algo] Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", Work in Progress, Internet-Draft, draft-ietf-lsr-flex-algo-20, 18 May 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)", RFC 7308, DOI 10.17487/RFC7308, July 2014, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Talaulikar, et al. Expires 26 February 2023 [Page 14] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 9.2. Informative References [I-D.ietf-idr-bgp-model] Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP YANG Model for Service Provider Networks", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-14, 3 July 2022, . [I-D.ietf-idr-bgpls-srv6-ext] Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., Bernier, D., and B. Decraene, "BGP Link State Extensions for SRv6", Work in Progress, Internet-Draft, draft-ietf- idr-bgpls-srv6-ext-09, 10 November 2021, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, "IS-IS Application-Specific Link Attributes", RFC 8919, DOI 10.17487/RFC8919, October 2020, . [RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, J., and J. Drake, "OSPF Application-Specific Link Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020, . [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, H., and M. Chen, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing", RFC 9085, DOI 10.17487/RFC9085, August 2021, . [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, . Talaulikar, et al. Expires 26 February 2023 [Page 15] Internet-Draft BGP-LS Extensions for Flexible Algorithm August 2022 [RFC9294] Talaulikar, K., Ed., Psenak, P., and J. Tantsura, "Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS)", RFC 9294, DOI 10.17487/RFC9294, August 2022, . Authors' Addresses Ketan Talaulikar (editor) Arrcus, Inc India Email: ketant.ietf@gmail.com Peter Psenak Cisco Systems Slovakia Email: ppsenak@cisco.com Shawn Zandi LinkedIn United States of America Email: szandi@linkedin.com Gaurav Dawra LinkedIn United States of America Email: gdawra.ietf@gmail.com Talaulikar, et al. Expires 26 February 2023 [Page 16] ./draft-ietf-mpls-rfc6374-sfl-10.txt0000644000764400076440000013357614020551055016512 0ustar iustiniustin MPLS Working Group S. Bryant (Ed) Internet-Draft Futurewei Technologies Inc. Intended status: Standards Track G. Swallow Expires: September 6, 2021 Southend Technical Center M. Chen Huawei G. Fioccola Huawei Technologies G. Mirsky ZTE Corp. March 05, 2021 RFC6374 Synonymous Flow Labels draft-ietf-mpls-rfc6374-sfl-10 Abstract RFC 6374 describes methods of making loss and delay measurements on Label Switched Paths (LSPs) primarily as used in MPLS Transport Profile (MPLS-TP) networks. This document describes a method of extending RFC 6374 performance measurements from flows carried over MPLS-TP to flows carried over generic MPLS LSPs. In particular, it extends the technique to allow loss and delay measurements to be made on multi-point to point LSPs and introduces some additional techniques to allow more sophisticated measurements to be made in both MPLS-TP and generic MPLS networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2021. Bryant (Ed), et al. Expires September 6, 2021 [Page 1] Internet-Draft RFC6374-SFL March 2021 Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, 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 of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. RFC6374 Packet Loss Measurement with SFL . . . . . . . . . . 4 4. RFC6374 Single Packet Delay Measurement . . . . . . . . . . . 4 5. Data Service Packet Delay Measurement . . . . . . . . . . . . 5 6. Some Simplifying Rules . . . . . . . . . . . . . . . . . . . 6 7. Multiple Packet Delay Characteristics . . . . . . . . . . . . 7 7.1. Method 1: Time Buckets . . . . . . . . . . . . . . . . . 7 7.2. Method 2 Classic Standard Deviation . . . . . . . . . . . 9 7.2.1. Multi-Packet Delay Measurement Message Format . . . . 10 7.3. Per Packet Delay Measurement . . . . . . . . . . . . . . 11 7.4. Average Delay . . . . . . . . . . . . . . . . . . . . . . 11 8. Sampled Measurement . . . . . . . . . . . . . . . . . . . . . 13 9. Carrying RFC6374 Packets over an LSP using an SFL . . . . . . 13 9.1. RFC6374 SFL TLV . . . . . . . . . . . . . . . . . . . . . 15 10. RFC6374 Combined Loss-Delay Measurement . . . . . . . . . . . 16 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 13.1. Allocation of MPLS Generalized Associated Channel (G-ACh) Types . . . . . . . . . . . . . . . . . . . . . 17 13.2. Allocation of MPLS Loss/Delay TLV Object . . . . . . . . 18 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 15. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 16.1. Normative References . . . . . . . . . . . . . . . . . . 18 16.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Bryant (Ed), et al. Expires September 6, 2021 [Page 2] Internet-Draft RFC6374-SFL March 2021 1. Introduction [RFC6374] was originally designed for use as an Operations, Administration, and Maintenance (OAM) protocol for use with MPLS Transport Profile (MPLS-TP) [RFC5921] LSPs. MPLS-TP only supports point-to-point and point-to-multi-point LSPs. This document describes how to use RFC6374 in the generic MPLS case, and also introduces a number of more sophisticated measurements of applicability to both cases. [RFC8372] describes the requirement for introducing flow identities when using RFC6374 [RFC6374] packet Loss Measurements (LM). In summary RFC6374 uses the loss-measurement (LM) packet as the packet accounting demarcation point. Unfortunately this gives rise to a number of problems that may lead to significant packet accounting errors in certain situations. For example: 1. Where a flow is subjected to Equal Cost Multi-Path (ECMP) treatment packets can arrive out of order with respect to the LM packet. 2. Where a flow is subjected to ECMP treatment, packets can arrive at different hardware interfaces, thus requiring reception of an LM packet on one interface to trigger a packet accounting action on a different interface which may not be co-located with it. This is a difficult technical problem to address with the required degree of accuracy. 3. Even where there is no ECMP (for example on RSVP-TE, MPLS-TP LSPs and pseudowires(PWs)) local processing may be distributed over a number of processor cores, leading to synchronization problems. 4. Link aggregation techniques [RFC7190] may also lead to synchronization issues. 5. Some forwarder implementations have a long pipeline between processing a packet and incrementing the associated counter, again leading to synchronization difficulties. An approach to mitigating these synchronization issue is described in [RFC8321] in which packets are batched by the sender and each batch is marked in some way such that adjacent batches can be easily recognized by the receiver. An additional problem arises where the LSP is a multi-point to point LSP, since MPLS does not include a source address in the packet. Network management operations require the measurement of packet loss between a source and destination. It is thus necessary to introduce Bryant (Ed), et al. Expires September 6, 2021 [Page 3] Internet-Draft RFC6374-SFL March 2021 some source specific information into the packet to identify packet batches from a specific source. [RFC8957] describes a method of encoding per flow instructions in an MPLS label stack using a technique called Synonymous Flow Labels (SFL) in which labels which mimic the behavior of other labels provide the packet batch identifiers and enable the per batch packet accounting. This memo specifies how SFLs are used to perform RFC6374 packet loss and RFC6374 delay measurements. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. RFC6374 Packet Loss Measurement with SFL The data service packets of the flow being instrumented are grouped into batches, and all the packets within a batch are marked with the SFL [RFC8372] corresponding to that batch. The sender counts the number of packets in the batch. When the batch has completed and the sender is confident that all of the packets in that batch will have been received, the sender issues an RFC6374 Query message to determine the number actually received and hence the number of packets lost. The RFC6374 Query message is sent using the same SFL as the corresponding batch of data service packets. The format of the Query and Response packets is described in Section 9. 4. RFC6374 Single Packet Delay Measurement RFC6374 describes how to measure the packet delay by measuring the transit time of an RFC6374 packet over an LSP. Such a packet may not need to be carried over an SFL since the delay over a particular LSP should be a function of the Traffic Class (TC) bits. However, where SFLs are being used to monitor packet loss or where label inferred scheduling is used [RFC3270] then the SFL would be REQUIRED to ensure that the RFC6374 packet which was being used as a proxy for a data service packet experienced a representative delay. The format of an RFC6374 packet carried over the LSP using an SFL is shown in Section 9. Bryant (Ed), et al. Expires September 6, 2021 [Page 4] Internet-Draft RFC6374-SFL March 2021 5. Data Service Packet Delay Measurement Where it is desired to more thoroughly instrument a packet flow and to determine the delay of a number of packets it is undesirable to send a large number of RFC6374 packets acting as a proxy data service packets (see Section 4). A method of directly measuring the delay characteristics of a batch of packets is therefore needed. Given the long intervals over which it is necessary to measure packet loss, it is not necessarily the case that the batch times for the two measurement types would be identical. Thus, we use a technique that permits the two measurements are made concurrently and yet relatively independent from each other. The notion that they are relatively independent arises from the potential for the two batches to overlap in time, in which case either the delay batch time will need to be cut short or the loss time will need to be extended to allow correct reconciliation of the various counters. The problem is illustrated in Figure 1 below: (1) AAAAAAAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB SFL Marking of a packet batch for loss measurement (2) AADDDDAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB SFL Marking of a subset of the packets for delay (3) AAAAAAAADDDDBBBBBBBBAAAAAAAAAABBBBBBBBBB SFL Marking of a subset of the packets across a packet loss measurement boundary (4) AACDCDCDAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB The case of multiple delay measurements within a packet loss measurement A & B are packets where loss is being measured C & D are pacekts where loss and delay is being measured Figure 1: RFC6734 Query Packet with SFL In case 1 of Figure 1 we show the case where loss measurement alone is being carried out on the flow under analysis. For illustrative purposes consider that 10 packets are used in each flow in the time interval being analyzed. Bryant (Ed), et al. Expires September 6, 2021 [Page 5] Internet-Draft RFC6374-SFL March 2021 Now consider case 2 of Figure 1 where a small batch of packets need to be analyzed for delay. These are marked with a different SFL type indicating that they are to be monitored for both loss and delay. The SFL=A indicates loss batch A, SFL=D indicates a batch of packets that are to be instrumented for delay, but SFL D is synonymous with SFL A, which in turn is synonymous with the underlying Forwarding Equivalence Class (FEC). Thus, a packet marked D will be accumulated into the A loss batch, into the delay statistics and will be forwarded as normal. Whether the packet is actually counted twice (for loss and delay) or whether the two counters are reconciled during reporting is a local matter. Now consider case 3 of Figure 1 where a small batch of packets are marked for delay across a loss batch boundary. These packets need to be considered as part of batch A or a part of batch B, and any RFC6374 Query needs to take place after all the packets A or D (whichever option is chosen) have arrived at the receiving LSR. Now consider case 4 of Figure 1. Here we have a case where it is required to take a number of delay measurements within a batch of packets that we are measuring for loss. To do this we need two SFLs for delay (C and D) and alternate between them (on a delay batch by delay batch basis) for the purposes of measuring the delay characteristics of the different batches of packets. 6. Some Simplifying Rules It is possible to construct a large set of overlapping measurement types, in terms of loss, delay, loss and delay and batch overlap. If we allow all combinations of cases, this leads to configuration, testing and implementation complexity and hence increased costs. The following simplifying rules represent the default case: 1. Any system that needs to measure delay MUST be able to measure loss. 2. Any system that is to measure delay MUST be configured to measure loss. Whether the loss statistics are collected or not is a local matter. 3. A delay measurement MAY start at any point during a loss measurement batch, subject to rule 4. 4. A delay measurement interval MUST be short enough that it will complete before the enclosing loss batch completes. 5. The duration of a second delay (D in Figure 1 batch must be such that all packets from the packets belonging to a first delay Bryant (Ed), et al. Expires September 6, 2021 [Page 6] Internet-Draft RFC6374-SFL March 2021 batch (C in Figure 1)will have been received before the second delay batch completes. This condition is satisfied when the time to send a batch is long compared to the network propagation time, and is a parameter that can be established by the network operator. Given that the sender controls both the start and duration of a loss and a delay packet batch, these rules are readily implemented in the control plane. 7. Multiple Packet Delay Characteristics A number of methods are described which add to the set of measurements originally specified in [RFC6374]. Each of these methods has different characteristics and different processing demands on the packet forwarder. The choice of method will depend on the type of diagnostic that the operator seeks. Three Methods are discussed: 1. Time Buckets 2. Classic Standard Deviation 3. Average Delay 7.1. Method 1: Time Buckets In this method the receiving LSR measures the inter-packet gap, classifies the delay into a number of delay buckets and records the number of packets in each bucket. As an example, if the operator were concerned about packets with a delay of up to 1us, 2us, 4us, 8us, and over 8us then there would be five buckets and packets that arrived up to 1us would cause the 1us bucket counter to increase, between 1us and 2us the 2us bucket counter would increase etc. In practice it might be better in terms of processing and potential parallelism if, when a packet had a delay relative to its predecessor of 2us, then both the up to 1us and the 2us counter were incremented, and any more detailed information was calculated in the analytics system. This method allows the operator to see more structure in the jitter characteristics than simply measuring the average jitter, and avoids the complication of needing to perform a per packet multiply, but will probably need the time intervals between buckets to be programmable by the operator. Bryant (Ed), et al. Expires September 6, 2021 [Page 7] Internet-Draft RFC6374-SFL March 2021 The packet format of a Time Bucket Jitter Measurement Message is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Control Code | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QTF | RTF | RPTF | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Identifier | DS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of | Reserved 1 | | Buckets | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interval in 10ns units | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number pkts in Bucket | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ TLV Block ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Time Bucket Jitter Measurement Message Format The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF, Session Identifier, Reserved and DS Fields are as defined in section 3.2 of RFC6374. The remaining fields, which are unsigned integers, are as follows: o Number of Buckets in the measurement o Reserved 1 must be sent as zero and ignored on receipt o Interval in 10ns units is the inter-packet interval for this bucket o Number Pkts in Bucket is the number of packets found in this bucket. There will be a number of Interval/Number pairs depending on the number of buckets being specified by the Querier. If an RFC6374 message is being used to configure the buckets, (i.e. the responder Bryant (Ed), et al. Expires September 6, 2021 [Page 8] Internet-Draft RFC6374-SFL March 2021 is creating or modifying the buckets according to the intervals in the Query message), then the Responder MUST respond with 0 packets in each bucket until it has been configured for a full measurement period. This indicates that it was configured at the time of the last response message, and thus the response is valid for the whole interval. As per the [RFC6374] convention the Number of pkts in Bucket fields are included in the Query message and set to zero. Out of band configuration is permitted by this mode of operation. Note this is a departure from the normal fixed format used in RFC6374. The time bucket jitter measurement message is carried over an LSP in the way described in [RFC6374] and over an LSP with an SFL as described in Section 9. 7.2. Method 2 Classic Standard Deviation In this method, provision is made for reporting the following delay characteristics: 1. Number of packets in the batch (n). 2. Sum of delays in a batch (S) 3. Maximum Delay. 4. Minimum Delay. 5. Sum of squares of Inter-packet delay (SS). Characteristics 1 and 2 give the mean delay. Measuring the delay of each pair in the batch is discussed in Section 7.3. Characteristics 3 and 4 give the outliers. Characteristics 1, 2 and 5 can be used to calculate the variance of the inter-packet gap and hence the standard deviation giving a view of the distribution of packet delays and hence the jitter. The equation for the variance (var) is given by: var = (SS - S*S/n)/(n-1) There is some concern over the use of this algorithm for measuring variance, because SS and S*S/n can be similar numbers, particularly where variance is low. However the method commends it self by not requiring a division in the hardware. Bryant (Ed), et al. Expires September 6, 2021 [Page 9] Internet-Draft RFC6374-SFL March 2021 7.2.1. Multi-Packet Delay Measurement Message Format The packet format of a Multi-Packet Delay Measurement Message is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Control Code | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QTF | RTF | RPTF | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Identifier | DS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Packets | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sum of Delays for Batch | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Delay | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Delay | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sum of squares of Inter-packet delay | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ TLV Block ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Multi-packet Delay Measurement Message Format The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF, Session Identifier, Reserved and DS Fields are as defined in section 3.2 of RFC6374. The remaining fields are as follows: Bryant (Ed), et al. Expires September 6, 2021 [Page 10] Internet-Draft RFC6374-SFL March 2021 o Number of Packets is the number of packets in this batch o Sum of Delays for Batch is the duration of the batch in the time measurement format specified in the RTF field. o Minimum Delay is the minimum inter-packet gap observed during the batch in the time format specified in the RTF field. o Maximum Delay is the maximum inter-packet gap observed during the batch in the time format specified in the RTF field. The multi-packet delay measurement message is carried over an LSP in the way described in [RFC6374] and over an LSP with an SFL as described in Section 9. 7.3. Per Packet Delay Measurement If detailed packet delay measurement is required then it might be possible to record the inter-packet gap for each packet pair. In other than exception cases of slow flows or small batch sizes, this would create a large (per packet) demand on storage in the instrumentation system, a large bandwidth to such a storage system and large bandwidth to the analytics system. Such a measurement technique is outside the scope of this document. 7.4. Average Delay Introduced in [RFC8321] is the concept of a one way delay measurement in which the average time of arrival of a set of packets is measured. In this approach the packet is time-stamped at arrival and the Responder returns the sum of the time-stamps and the number of times- tamps. From this the analytics engine can determine the mean delay. An alternative model is that the Responder returns the time stamp of the first and last packet and the number of packets. This later method has the advantage of allowing the average delay to be determined at a number of points along the packet path and allowing the components of the delay to be characterized. Unless specifically configured otherwise, the responder may return either or both types of response and the analytics engine should process the response appropriately. The packet format of an Average Delay Measurement Message is shown below: Bryant (Ed), et al. Expires September 6, 2021 [Page 11] Internet-Draft RFC6374-SFL March 2021 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Control Code | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QTF | RTF | RPTF | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Identifier | DS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Packets | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time of First Packet | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time of Last Packet | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sum of Timestamps of Batch | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ TLV Block ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Average Delay Measurement Message Format The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF, Session Identifier, and DS Fields are as defined in section 3.2 of RFC6374. The remaining fields are as follows: o Number of Packets is the number of packets in this batch. o Time of First Packet is the time of arrival of the first packet in the batch. o Time of Last Packet is the time of arrival of the last packet in the batch. o Sum of Timestamps of Batch. The average delay measurement message is carried over an LSP in the way described in [RFC6374] and over an LSP with an SFL as described in Section 9. As is the convention with RFC6374, the Query message contains placeholders for the Response message. The placeholders are sent as zero. Bryant (Ed), et al. Expires September 6, 2021 [Page 12] Internet-Draft RFC6374-SFL March 2021 8. Sampled Measurement In the discussion so far it has been assumed that we would measure the delay characteristics of every packet in a delay measurement interval defined by an SFL of constant color. In [RFC8321] the concept of a sampled measurement is considered. That is the Responder only measures a packet at the start of a group of packets being marked for delay measurement by a particular color, rather than every packet in the marked batch. A measurement interval is not defined by the duration of a marked batch of packets but the interval between a pair of RFC6374 packets taking a readout of the delay characteristic. This approach has the advantage that the measurement is not impacted by ECMP effects. This sampled approach may be used if supported by the Responder and configured by the opertor. 9. Carrying RFC6374 Packets over an LSP using an SFL We illustrate the packet format of an RFC6374 Query message using SFLs for the case of an MPLS direct loss measurement in Figure 5. Bryant (Ed), et al. Expires September 6, 2021 [Page 13] Internet-Draft RFC6374-SFL March 2021 +-------------------------------+ | | | LSP | | Label | +-------------------------------+ | | | Synonymous Flow | | Label | +-------------------------------+ | | | GAL | | | +-------------------------------+ | | | ACH Type = 0xA | | | +-------------------------------+ | | | RFC6374 Measurement Message | | | | +-------------------------+ | | | | | | | Fixed-format | | | | portion of msg | | | | | | | +-------------------------+ | | | | | | | Optional SFL TLV | | | | | | | +-------------------------+ | | | | | | | Optional Return | | | | Information | | | | | | | +-------------------------+ | | | +-------------------------------+ Figure 5: RFC6734 Query Packet with SFL The MPLS label stack is exactly the same as that used for the user data service packets being instrumented except for the inclusion of the Generic Associated Channel Label (GAL) [RFC5586] to allow the receiver to distinguish between normal data packets and OAM packets. Since the packet loss measurements are being made on the data service packets, an RFC6374 direct loss measurement is being made, and which is indicated by the type field in the ACH (Type = 0x000A). Bryant (Ed), et al. Expires September 6, 2021 [Page 14] Internet-Draft RFC6374-SFL March 2021 The RFC6374 measurement message consists of the three components, the RFC6374 fixed-format portion of the message as specified in [RFC6374] carried over the ACH channel type specified the type of measurement being made (currently: loss, delay or loss and delay) as specified in RFC6374. Two optional TLVs MAY also be carried if needed. The first is the SFL TLV specified in Section 9.1. This is used to provide the implementation with a reminder of the SFL that was used to carry the RFC6374 message. This is needed because a number of MPLS implementations do not provide the MPLS label stack to the MPLS OAM handler. This TLV is required if RFC6374 messages are sent over UDP [RFC7876]. This TLV MUST be included unless, by some method outside the scope of this document, it is known that this information is not needed by the RFC6374 Responder. The second set of information that may be needed is the return information that allows the responder send the RFC6374 response to the Querier. This is not needed if the response is requested in-band and the MPLS construct being measured is a point to point LSP, but otherwise MUST be carried. The return address TLV is defined in [RFC6374] and the optional UDP Return Object is defined in [RFC7876]. Where a measurement other than an MPLS direct loss measurement is to be made, the appropriate RFC6374 measurement message is used (for example, one of the new types defined in this document) and this is indicated to the receiver by the use of the corresponding ACH type. 9.1. RFC6374 SFL TLV The RFC6374 SFL TLV is shown in Figure 6. This contains the SFL that was carried in the label stack, the FEC that was used to allocate the SFL and the index into the batch of SLs that were allocated for the FEC that corresponds to this SFL. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |MBZ| SFL Batch | SFL Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SFL | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: SFL TLV Bryant (Ed), et al. Expires September 6, 2021 [Page 15] Internet-Draft RFC6374-SFL March 2021 Where: Type Type is set to Synonymous Flow Label (SFL-TLV). Length The length of the TLV as specified in RFC6374. MBZ MUST be sent as zero and ignored on receive. SFL Batch The SFL batch that this SFL was allocated as part of see [I-D.bryant-mpls-sfl-control] SPL Index The index into the list of SFLs that were assigned against the FEC that corresponds to the SFL. Multiple SFLs can be assigned to a FEC each with different actions. This index is an optional convenience for use in mapping between the TLV and the associated data structures in the LSRs. The use of this feature is agreed between the two parties during configuration. It is not required, but is a convenience for the receiver if both parties support the facility, SFL The SFL used to deliver this packet. This is an MPLS label which is a component of a label stack entry as defined in Section 2.1 of [RFC3032]. Reserved MUST be sent as zero and ignored on receive. FEC The Forwarding Equivalence Class that was used to request this SFL. This is encoded as per Section 3.4.1 of [RFC5036] This information is needed to allow for operation with hardware that discards the MPLS label stack before passing the remainder of the stack to the OAM handler. By providing both the SFL and the FEC plus index into the array of allocated SFLs a number of implementation types are supported. 10. RFC6374 Combined Loss-Delay Measurement This mode of operation is not currently supported by this specification. Bryant (Ed), et al. Expires September 6, 2021 [Page 16] Internet-Draft RFC6374-SFL March 2021 11. Privacy Considerations The inclusion of originating and/or flow information in a packet provides more identity information and hence potentially degrades the privacy of the communication. Whilst the inclusion of the additional granularity does allow greater insight into the flow characteristics it does not specifically identify which node originated the packet other than by inspection of the network at the point of ingress, or inspection of the control protocol packets. This privacy threat may be mitigated by encrypting the control protocol packets, regularly changing the synonymous labels and by concurrently using a number of such labels. 12. Security Considerations The security considerations documented in [RFC6374] and [RFC8372] (which in turn calls up [RFC7258] and [RFC5920]) are applicable to this protocol. The issue noted in Section 11 is a security consideration. There are no other new security issues associated with the MPLS dataplane. Any control protocol used to request SFLs will need to ensure the legitimacy of the request. An attacker that manages to corrupt the RFC6374 SFL TLV Section 9.1 could disrupt the measurements in a way that the RFC6374 responder is unable to detect. However, the network opertator is likely to notice the anomalous network performance measurements, and in any case normal MPLS network security proceedures make this type of attack extremely unlikley. 13. IANA Considerations 13.1. Allocation of MPLS Generalized Associated Channel (G-ACh) Types As per the IANA considerations in [RFC5586] updated by [RFC7026] and [RFC7214], IANA is requested to allocate the following codeponts in the "MPLS Generalized Associated Channel (G-ACh) Type" registry, in the "Generic Associated Channel (G-ACh) Parameters" name space: Bryant (Ed), et al. Expires September 6, 2021 [Page 17] Internet-Draft RFC6374-SFL March 2021 Value Description Reference ----- --------------------------------- ----------- TBD RFC6374 Time Bucket Jitter Measurement This TBD RFC6374 Multi-Packet Delay This Measurement TBD RFC6374 Average Delay Measurement This 13.2. Allocation of MPLS Loss/Delay TLV Object IANA is requested to allocate a new TLV from the 0-127 range of the MPLS Loss/Delay Measurement TLV Object Registry in the "Generic Associated Channel (G-ACh) Parameters" namespace: Type Description Reference ---- --------------------------------- --------- TBD Synonymous Flow Label This A value of 4 is recommended. RFC Editor please delete this para [RFC3032][I-D.bryant-mpls-sfl-control][RFC5036] 14. Acknowledgments The authors thank Benjamin Kaduk and Elwyn Davies for their thorough and thoughtful review of this document. 15. Contributing Authors Zhenbin Li Huawei Email: lizhenbin@huawei.com Siva Sivabalan Ciena Corporation Email: ssivabal@ciena.com 16. References 16.1. Normative References [I-D.bryant-mpls-sfl-control] Bryant, S., Swallow, G., and S. Sivabalan, "A Simple Control Protocol for MPLS SFLs", draft-bryant-mpls-sfl- control-09 (work in progress), December 2020. Bryant (Ed), et al. Expires September 6, 2021 [Page 18] Internet-Draft RFC6374-SFL March 2021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, . [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, . [RFC7026] Farrel, A. and S. Bryant, "Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel", RFC 7026, DOI 10.17487/RFC7026, September 2013, . [RFC7214] Andersson, L. and C. Pignataro, "Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry", RFC 7214, DOI 10.17487/RFC7214, May 2014, . [RFC7876] Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks", RFC 7876, DOI 10.17487/RFC7876, July 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8957] Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G. Mirsky, "Synonymous Flow Label Framework", RFC 8957, DOI 10.17487/RFC8957, January 2021, . Bryant (Ed), et al. Expires September 6, 2021 [Page 19] Internet-Draft RFC6374-SFL March 2021 16.2. Informative References [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, . [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, . [RFC7190] Villamizar, C., "Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)", RFC 7190, DOI 10.17487/RFC7190, March 2014, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, January 2018, . [RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. Mirsky, "MPLS Flow Identification Considerations", RFC 8372, DOI 10.17487/RFC8372, May 2018, . Authors' Addresses Stewart Bryant Futurewei Technologies Inc. Email: sb@stewartbryant.com Bryant (Ed), et al. Expires September 6, 2021 [Page 20] Internet-Draft RFC6374-SFL March 2021 George Swallow Southend Technical Center Email: swallow.ietf@gmail.com Mach Chen Huawei Email: mach.chen@huawei.com Giuseppe Fioccola Huawei Technologies Email: giuseppe.fioccola@huawei.com Gregory Mirsky ZTE Corp. Email: gregimirsky@gmail.com Bryant (Ed), et al. Expires September 6, 2021 [Page 21] ./draft-ietf-ippm-ioam-conf-state-10.txt0000644000764400076440000012420214337033717017607 0ustar iustiniustin IPPM Working Group X. Min Internet-Draft ZTE Corp. Intended status: Standards Track G. Mirsky Expires: 25 May 2023 Ericsson L. Bo China Telecom 21 November 2022 Echo Request/Reply for Enabled In-situ OAM Capabilities draft-ietf-ippm-ioam-conf-state-10 Abstract This document describes a generic format for use in echo request/ reply mechanisms, which can be used within an In situ Operations, Administration, and Maintenance (IOAM) domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. The generic format is intended to be used with a variety of data planes such as IPv6, MPLS, Service Function Chain (SFC) and Bit Index Explicit Replication (BIER). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 May 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Min, et al. Expires 25 May 2023 [Page 1] Internet-Draft Ping Enabled IOAM Capabilities November 2022 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 3. IOAM Capabilities Formats . . . . . . . . . . . . . . . . . . 6 3.1. IOAM Capabilities Query Container . . . . . . . . . . . . 6 3.2. IOAM Capabilities Response Container . . . . . . . . . . 7 3.2.1. IOAM Pre-allocated Tracing Capabilities Object . . . 8 3.2.2. IOAM Incremental Tracing Capabilities Object . . . . 9 3.2.3. IOAM Proof-of-Transit Capabilities Object . . . . . . 10 3.2.4. IOAM Edge-to-Edge Capabilities Object . . . . . . . . 11 3.2.5. IOAM DEX Capabilities Object . . . . . . . . . . . . 12 3.2.6. IOAM End-of-Domain Object . . . . . . . . . . . . . . 12 4. Operational Guide . . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5.1. IOAM SoP Capability Registry . . . . . . . . . . . . . . 14 5.2. IOAM TSF Capability Registry . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction In situ Operations, Administration, and Maintenance (IOAM) ([RFC9197] [RFC9326]) defines data fields that record OAM information within the packet while the packet traverses a particular network domain, called an IOAM domain. IOAM can complement or replace other OAM mechanisms, such as ICMP or other types of probe packets. As specified in [RFC9197], within the IOAM domain, the IOAM data may be updated by network nodes that the packet traverses. The device which adds an IOAM header to the packet is called an "IOAM encapsulating node". In contrast, the device which removes an IOAM header is referred to as an "IOAM decapsulating node". Nodes within the domain that are aware of IOAM data and read and/or write and/or process IOAM data are called "IOAM transit nodes". IOAM encapsulating or decapsulating nodes can also serve as IOAM transit Min, et al. Expires 25 May 2023 [Page 2] Internet-Draft Ping Enabled IOAM Capabilities November 2022 nodes at the same time. IOAM encapsulating or decapsulating nodes are also referred to as IOAM domain edge devices, which can be hosts or network devices. [RFC9197] defines four IOAM option types, and [RFC9326] introduces a new IOAM option type called the Direct Export (DEX) Option-Type, which is different from the other four IOAM option types defined in [RFC9197] on how to collect the operational and telemetry information defined in [RFC9197]. As specified in [RFC9197], IOAM is focused on "limited domains" as defined in [RFC8799]. In a limited domain, a control entity that has control over every IOAM device may be deployed. If that's the case, the control entity can provision both the explicit transport path and the IOAM header applied to data packet at every IOAM encapsulating node. In a case when a control entity that has control over every IOAM device is not deployed in the IOAM domain, the IOAM encapsulating node needs to discover the enabled IOAM capabilities at the IOAM transit and decapsulating nodes. For example, what types of IOAM tracing data can be added or exported by the transit nodes along the transport path of the data packet IOAM is applied to. The IOAM encapsulating node can then add the correct IOAM header to the data packet according to the discovered IOAM capabilities. Specifically, the IOAM encapsulating node first identifies the types and lengths of IOAM options included in the IOAM data fields according to the discovered IOAM capabilities. Then the IOAM encapsulating node can add the IOAM header to the data packet based on the identified types and lengths of IOAM options included in the IOAM data fields. The IOAM encapsulating node may use NETCONF/YANG or IGP to discover these IOAM capabilities. However, NETCONF/YANG or IGP has some limitations: * When NETCONF/YANG is used in this scenario, each IOAM encapsulating node (including the host when it takes the role of an IOAM encapsulating node) needs to implement a NETCONF Client, each IOAM transit and IOAM decapsulating node (including the host when it takes the role of an IOAM decapsulating node) needs to implement a NETCONF Server, the complexity can be an issue. Furthermore, each IOAM encapsulating node needs to establish NETCONF Connection with each IOAM transit and IOAM decapsulating node, the scalability can be an issue. Min, et al. Expires 25 May 2023 [Page 3] Internet-Draft Ping Enabled IOAM Capabilities November 2022 * When IGP is used in this scenario, the IGP and IOAM domains don't always have the same coverage. For example, when the IOAM encapsulating node or the IOAM decapsulating node is a host, the availability can be an issue. Furthermore, it might be too challenging to reflect enabled IOAM capabilities at the IOAM transit and IOAM decapsulating node if these are controlled by a local policy depending on the identity of the IOAM encapsulating node. This document specifies formats and objects that can be used in the extension of echo request/reply mechanisms used in IPv6 (including Segment Routing with IPv6 data plane (SRv6)), MPLS (including Segment Routing with MPLS data plane (SR-MPLS)), SFC and BIER environments, which can be used within the IOAM domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. The following documents contain references to the echo request/reply mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS), SFC and BIER environments: * [RFC4443] ("Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"), [RFC4620] ("IPv6 Node Information Queries"), [RFC4884] ("Extended ICMP to Support Multi-Part Messages") and [RFC8335] ("PROBE: A Utility for Probing Interfaces") * [RFC8029] ("Detecting Multiprotocol Label Switched (MPLS) Data- Plane Failures") * [I-D.ietf-sfc-multi-layer-oam] ("Active OAM for Service Function Chaining (SFC)") * [I-D.ietf-bier-ping] ("BIER Ping and Trace") It is expected that the specification of the instantiation of each of these extensions will be done in the form of an RFC jointly designed by the working group that develops or maintains the echo request/ reply protocol and the IETF IP Performance Measurement (IPPM) Working Group. Note that in this document the echo request/reply mechanism used in IPv6 does not mean ICMPv6 Echo Request/Reply [RFC4443], but means IPv6 Node Information Query/Reply [RFC4620]. Fate sharing is a common requirement for all kinds of active OAM packets, echo request is among them, in this document that means echo request is required to traverse a path of IOAM data packet. This Min, et al. Expires 25 May 2023 [Page 4] Internet-Draft Ping Enabled IOAM Capabilities November 2022 requirement can be achieved by, e.g., applying same explicit path or ECMP processing to both echo request and IOAM data packet. Specific to apply same ECMP processing to both echo request and IOAM data packet, one possible way is to populate the same value(s) of ECMP affecting field(s) in the echo request. 2. Conventions 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.2. Abbreviations BIER: Bit Index Explicit Replication BGP: Border Gateway Protocol DEX: Direct Export ECMP: Equal-Cost Multipath E2E: Edge to Edge ICMP: Internet Control Message Protocol IGP: Interior Gateway Protocol IOAM: In situ Operations, Administration, and Maintenance LSP: Label Switched Path MPLS: Multi-Protocol Label Switching MTU: Maximum Transmission Unit NTP: Network Time Protocol OAM: Operations, Administration, and Maintenance PCEP: Path Computation Element (PCE) Communication Protocol POSIX: Portable Operating System Interface Min, et al. Expires 25 May 2023 [Page 5] Internet-Draft Ping Enabled IOAM Capabilities November 2022 POT: Proof of Transit PTP: Precision Time Protocol SR-MPLS: Segment Routing with MPLS data plane SRv6: Segment Routing with IPv6 data plane SFC: Service Function Chain TTL: Time to Live, this is also the Hop Limit field in the IPv6 header 3. IOAM Capabilities Formats 3.1. IOAM Capabilities Query Container For echo request, IOAM Capabilities Query uses a container which has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IOAM Capabilities Query Container Header . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . List of IOAM Namespace-IDs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IOAM Capabilities Query Container of Echo Request When this container is present in the echo request sent by an IOAM encapsulating node, that means the IOAM encapsulating node requests the receiving node to reply with its enabled IOAM capabilities. If there is no IOAM capability to be reported by the receiving node, then this container MUST be ignored by the receiving node, which means the receiving node MUST send an echo reply without IOAM capabilities or no echo reply, in the light of whether the echo request includes other containers than the IOAM Capabilities Query Container. A list of IOAM Namespace-IDs (one or more Namespace-IDs) MUST be included in this container in the echo request, and if present, the Default-Namespace-ID 0x0000 MUST be placed at the beginning of the list of IOAM Namespace-IDs. The IOAM encapsulating node requests only the enabled IOAM capabilities that match one of the Namespace-IDs. Inclusion of the Default-Namespace-ID 0x0000 Min, et al. Expires 25 May 2023 [Page 6] Internet-Draft Ping Enabled IOAM Capabilities November 2022 elicits replies only for capabilities that are configured with the Default-Namespace-ID 0x0000.The Namespace-ID has the same definition as what's specified in Section 4.3 of [RFC9197]. The IOAM Capabilities Query Container has a container header that is used to identify the type and optionally length of the container payload, and the container payload (List of IOAM Namespace-IDs) is zero-padded to align to a 4-octet boundary. Since the Default- Namespace-ID of 0x0000 is mandated to appear first in the list, any other occurrences of 0x0000 MUST be disregarded. The length, structure, and definition of the IOAM Capabilities Query Container Header depends on the specific deployment environment. 3.2. IOAM Capabilities Response Container For echo reply, IOAM Capabilities Response uses a container which has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IOAM Capabilities Response Container Header . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . List of IOAM Capabilities Objects . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IOAM Capabilities Response Container of Echo Reply When this container is present in the echo reply sent by an IOAM transit node or IOAM decapsulating node, that means the IOAM function is enabled at this node, and this container contains the enabled IOAM capabilities of the sender. A list of IOAM capabilities objects (one or more objects) which contains the enabled IOAM capabilities MUST be included in this container of echo reply except the sender encounters an error (e.g., no matched Namespace-ID). The IOAM Capabilities Response Container has a container header that is used to identify the type and optionally length of the container payload. The container header MUST be defined such that it falls on a four-octet boundary. Min, et al. Expires 25 May 2023 [Page 7] Internet-Draft Ping Enabled IOAM Capabilities November 2022 The length, structure, and definition of the IOAM Capabilities Response Container Header depends on the specific deployment environment. Based on the IOAM data fields defined in [RFC9197] and [RFC9326], six types of objects are defined in this document. The same type of object MAY be present in the IOAM Capabilities Response Container more than once, only if with a different Namespace-ID. Similar to the container, each object has an object header that is used to identify the type and length of the object payload. The object payload MUST be defined such that it falls on a four-octet boundary. The length, structure, and definition of Object Header depends on the specific deployment environment. 3.2.1. IOAM Pre-allocated Tracing Capabilities Object 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IOAM Pre-allocated Tracing Capabilities Object Header . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IOAM-Trace-Type | Reserved |W| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace-ID | Ingress_MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress_if_id (short or wide format) ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IOAM Pre-allocated Tracing Capabilities Object When this Object is present in the IOAM Capabilities Response Container, that means the sending node is an IOAM transit node and the IOAM pre-allocated tracing function is enabled at this IOAM transit node. IOAM-Trace-Type field has the same definition as what's specified in Section 4.4 of [RFC9197]. Reserved field is reserved for future use and MUST be set to zero, and MUST be ignored when non-zero. Min, et al. Expires 25 May 2023 [Page 8] Internet-Draft Ping Enabled IOAM Capabilities November 2022 W flag indicates whether Ingress_if_id is in short or wide format. The W-bit is set if the Ingress_if_id is in wide format. The W-bit is clear if the Ingress_if_id is in short format. Namespace-ID field has the same definition as what's specified in Section 4.3 of [RFC9197], it MUST be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request. Ingress_MTU field has 16 bits and specifies the MTU (in octets) of the ingress interface from which the sending node received echo request. Ingress_if_id field has 16 bits (in short format) or 32 bits (in wide format) and specifies the identifier of the ingress interface from which the sending node received echo request. If the W-bit is cleared that indicates Ingress_if_id field has 16 bits, then the 16 bits following the Ingress_if_id field are reserved for future use and MUST be set to zero, and MUST be ignored when non-zero. 3.2.2. IOAM Incremental Tracing Capabilities Object 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IOAM Incremental Tracing Capabilities Object Header . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IOAM-Trace-Type | Reserved |W| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace-ID | Ingress_MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress_if_id (short or wide format) ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: IOAM Incremental Tracing Capabilities Object When this Object is present in the IOAM Capabilities Response Container, that means the sending node is an IOAM transit node and the IOAM incremental tracing function is enabled at this IOAM transit node. IOAM-Trace-Type field has the same definition as what's specified in Section 4.4 of [RFC9197]. Reserved field is reserved for future use and MUST be set to zero, and MUST be ignored when non-zero. Min, et al. Expires 25 May 2023 [Page 9] Internet-Draft Ping Enabled IOAM Capabilities November 2022 W flag indicates whether Ingress_if_id is in short or wide format. The W-bit is set if the Ingress_if_id is in wide format. The W-bit is clear if the Ingress_if_id is in short format. Namespace-ID field has the same definition as what's specified in Section 4.3 of [RFC9197], it MUST be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request. Ingress_MTU field has 16 bits and specifies the MTU (in octets) of the ingress interface from which the sending node received echo request. Ingress_if_id field has 16 bits (in short format) or 32 bits (in wide format) and specifies the identifier of the ingress interface from which the sending node received echo request. If the W-bit is cleared that indicates Ingress_if_id field has 16 bits, then the 16 bits following the Ingress_if_id field are reserved for future use and MUST be set to zero, and MUST be ignored when non-zero. 3.2.3. IOAM Proof-of-Transit Capabilities Object 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IOAM Proof-of-Transit Capabilities Object Header . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace-ID | IOAM-POT-Type |SoP| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: IOAM Proof-of-Transit Capabilities Object When this Object is present in the IOAM Capabilities Response Container, that means the sending node is an IOAM transit node and the IOAM Proof of Transit function is enabled at this IOAM transit node. Namespace-ID field has the same definition as what's specified in Section 4.3 of [RFC9197], it MUST be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request. IOAM-POT-Type field has the same definition as what's specified in Section 4.5 of [RFC9197]. SoP (Size of POT) field has two bits, which means the size of "PktID" and "Cumulative" data that are specified in Section 4.5 of [RFC9197]. This document defines SoP as follows: Min, et al. Expires 25 May 2023 [Page 10] Internet-Draft Ping Enabled IOAM Capabilities November 2022 0b00 means 64-bit "PktID" and 64-bit "Cumulative" data. 0b01~0b11: Reserved for future standardization Reserved field is reserved for future use and MUST be set to zero, and MUST be ignored when non-zero. 3.2.4. IOAM Edge-to-Edge Capabilities Object 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IOAM Edge-to-Edge Capabilities Object Header . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace-ID | IOAM-E2E-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TSF| Reserved | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: IOAM Edge-to-Edge Capabilities Object When this Object is present in the IOAM Capabilities Response Container, that means the sending node is an IOAM decapsulating node and IOAM edge-to-edge function is enabled at this IOAM decapsulating node. Namespace-ID field has the same definition as what's specified in Section 4.3 of [RFC9197], it MUST be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request. IOAM-E2E-Type field has the same definition as what's specified in Section 4.6 of [RFC9197]. TSF field specifies the timestamp format used by the sending node. Aligned with three possible timestamp formats specified in Section 5 of [RFC9197], this document defines TSF as follows: 0b00: PTP truncated timestamp format 0b01: NTP 64-bit timestamp format 0b10: POSIX-based timestamp format 0b11: Reserved for future standardization Min, et al. Expires 25 May 2023 [Page 11] Internet-Draft Ping Enabled IOAM Capabilities November 2022 Reserved field is reserved for future use and MUST be set to zero, and MUST be ignored when non-zero. 3.2.5. IOAM DEX Capabilities Object 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IOAM DEX Capabilities Object Header . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IOAM-Trace-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace-ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: IOAM DEX Capabilities Object When this Object is present in the IOAM Capabilities Response Container, that means the sending node is an IOAM transit node and the IOAM direct exporting function is enabled at this IOAM transit node. IOAM-Trace-Type field has the same definition as what's specified in Section 3.2 of [RFC9326]. Namespace-ID field has the same definition as what's specified in Section 4.3 of [RFC9197], it MUST be one of the Namespace-IDs listed in the IOAM Capabilities Query Object of the echo request. Reserved field is reserved for future use and MUST be set to zero, and MUST be ignored when non-zero. 3.2.6. IOAM End-of-Domain Object 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IOAM End-of-Domain Object Header . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace-ID | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: IOAM End-of-Domain Object Min, et al. Expires 25 May 2023 [Page 12] Internet-Draft Ping Enabled IOAM Capabilities November 2022 When this Object is present in the IOAM Capabilities Response Container, that means the sending node is an IOAM decapsulating node. Unless the IOAM Edge-to-Edge Capabilities Object is present, which also indicates that the sending node is an IOAM decapsulating node, the End-of-Domain Object MUST be present in the IOAM Capabilities Response Container sent by an IOAM decapsulating node. When the IOAM edge-to-edge function is enabled at the IOAM decapsulating node, it's RECOMMENDED to include only the IOAM Edge-to-Edge Capabilities Object but not the IOAM End-of-Domain Object. Namespace-ID field has the same definition as what's specified in Section 4.3 of [RFC9197], it MUST be one of the Namespace-IDs listed in the IOAM Capabilities Query Container. 4. Operational Guide Once the IOAM encapsulating node is triggered to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node, the IOAM encapsulating node will send echo requests that include the IOAM Capabilities Query Container. First, with TTL equal to 1 to reach the closest node, which may be an IOAM transit node or not. Then with TTL equal to 2 to reach the second-nearest node, which also may be an IOAM transit node or not. And further, increasing by 1 the TTL every time the IOAM encapsulating node sends a new echo request, until the IOAM encapsulating node receives an echo reply sent by the IOAM decapsulating node, which contains the IOAM Capabilities Response Container including the IOAM Edge-to-Edge Capabilities Object or the IOAM End-of-Domain Object. As a result, the echo requests sent by the IOAM encapsulating node will reach all nodes one by one along the transport path of IOAM data packet. Alternatively, if the IOAM encapsulating node knows precisely all the IOAM transit and IOAM decapsulating nodes beforehand, once the IOAM encapsulating node is triggered to discover the enabled IOAM capabilities, it can send an echo request to each IOAM transit and IOAM decapsulating node directly, without TTL expiration. The IOAM encapsulating node may be triggered by the device administrator, the network management system, the network controller, or data traffic. The specific triggering mechanisms are outside the scope of this document. Each IOAM transit and IOAM decapsulating node that receives an echo request containing the IOAM Capabilities Query Container will send an echo reply to the IOAM encapsulating node. For the echo reply, there is an IOAM Capabilities Response Container containing one or more Objects. The IOAM Capabilities Query Container of the echo request would be ignored by the receiving node unaware of IOAM. Min, et al. Expires 25 May 2023 [Page 13] Internet-Draft Ping Enabled IOAM Capabilities November 2022 Note that the mechanism defined in this document applies to all kinds of IOAM option types, whether the four types of IOAM option defined in [RFC9197] or the DEX type of IOAM option defined in [RFC9326], specifically, when applied to the IOAM DEX option, it allows the IOAM encapsulating node to discover which nodes along the transport path support IOAM direct exporting and which trace data types are supported to be directly exported at these nodes. 5. IANA Considerations This document requests the following IANA Actions. IANA is requested to create a registry group named "In-Situ OAM (IOAM) Capabilities Parameters". This group will include the following registries: * IOAM SoP Capability * IOAM TSF Capability New registries in this group can be created via RFC Required process as per [RFC8126]. The subsequent subsections detail the registries herein contained. Considering the Containers/Objects defined in this document would be carried in different types of Echo Request/Reply messages, such as ICMPv6 or LSP Ping, it is intended that the registries for Container/ Object Type would be requested in subsequent documents. 5.1. IOAM SoP Capability Registry This registry defines 4 code points for the IOAM SoP Capability field for identifying the size of "PktID" and "Cumulative" data as explained in Section 4.5 of [RFC9197]. A new entry in this registry requires the following fields: * SoP: size of POT; a two-bit binary field as defined in Section 3.2.3 * Description: a terse description of the meaning of this SoP value The registry initially contains the following value: Min, et al. Expires 25 May 2023 [Page 14] Internet-Draft Ping Enabled IOAM Capabilities November 2022 SoP Description ---- ----------- 0b00 64-bit "PktID" and 64-bit "Cumulative" data 0b01 - 0b11 are available for assignment via IETF Review process as per [RFC8126]. 5.2. IOAM TSF Capability Registry This registry defines 4 code points for the IOAM TSF Capability field for identifying the timestamp format as explained in Section 5 of [RFC9197]. A new entry in this registry requires the following fields: * TSF: timestamp format; a two-bit binary field as defined in Section 3.2.4 * Description: a terse description of the meaning of this TSF value The registry initially contains the following values: TSF Description ---- ----------- 0b00 PTP Truncated Timestamp Format 0b01 NTP 64-bit Timestamp Format 0b10 POSIX-based Timestamp Format 0b11 is available for assignment via IETF Review process as per [RFC8126]. 6. Security Considerations Overall, the security needs for IOAM capabilities query mechanisms used in different environments are similar. To avoid potential Denial-of-Service (DoS) attacks, it is RECOMMENDED that implementations apply rate-limiting to incoming echo requests and replies. To protect against unauthorized sources using echo request messages to obtain IOAM Capabilities information, implementations MUST provide a means of checking the source addresses of echo request messages against an access list before accepting the message. Min, et al. Expires 25 May 2023 [Page 15] Internet-Draft Ping Enabled IOAM Capabilities November 2022 A deployment MUST ensure that border filtering drops inbound echo requests with an IOAM Capabilities Container Header from outside of the domain, and drops outbound echo request/replies with IOAM Capabilities Headers leaving the domain. A deployment MUST support the configuration option to enable/disable the IOAM Capabilities Discovery feature defined in this document. By default, the IOAM Capabilities Discovery feature MUST be disabled. The integrity protection on IOAM Capabilities information carried in echo reply messages can be achieved by the underlying transport. For example, if the environment is an IPv6 network, the IP Authentication Header [RFC4302] or IP Encapsulating Security Payload Header [RFC4303] can be used. The collected IOAM Capabilities information by queries may be considered confidential. An implementation can use secure underlying transport of echo request/reply to provide privacy protection. For example, if the environment is an IPv6 network, confidentiality can be achieved by using the IP Encapsulating Security Payload Header [RFC4303]. An implementation can also directly secure the data carried in echo requests and replies if needed, the specific mechanism on how to secure the data is beyond the scope of this document. An implementation can also check whether the fields in received echo requests and replies strictly conform to the specifications, e.g., whether the list of IOAM Namespace-IDs includes duplicate entries, whether the received Namespace-ID is an operator-assigned or IANA- assigned one, once a check fails, an exception event indicating the checked field should be reported to the management. Except for what's described above, the security issues discussed in [RFC9197] provide a good guidance on implementation of this specification. 7. Acknowledgements The authors would like to acknowledge Tianran Zhou, Dhruv Dhody, Frank Brockners, Cheng Li, Gyan Mishra, Marcus Ihlar, Martin Duke, Chris Lonvick, Eric Vyncke, Alvaro Retana, Paul Wouters, Roman Danyliw, Lars Eggert, Warren Kumari, John Scudder, Robert Wilton, Erik Kline, Zaheduzzaman Sarker and Murray Kucherawy for their careful review and helpful comments. The authors appreciate the f2f discussion with Frank Brockners on this document. Min, et al. Expires 25 May 2023 [Page 16] Internet-Draft Ping Enabled IOAM Capabilities November 2022 The authors would like to acknowledge Tommy Pauly and Ian Swett for their good suggestion and guidance. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . [RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T. Mizrahi, "In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting", RFC 9326, DOI 10.17487/RFC9326, November 2022, . 8.2. Informative References [I-D.ietf-bier-ping] Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., and G. Mirsky, "BIER Ping and Trace", Work in Progress, Internet-Draft, draft-ietf-bier-ping-07, 11 May 2020, . [I-D.ietf-sfc-multi-layer-oam] Mirsky, G., Meng, W., Ao, T., Khasnabish, B., Leung, K., and G. Mishra, "Active OAM for Service Function Chaining (SFC)", Work in Progress, Internet-Draft, draft-ietf-sfc- multi-layer-oam-22, 25 July 2022, . Min, et al. Expires 25 May 2023 [Page 17] Internet-Draft Ping Enabled IOAM Capabilities November 2022 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node Information Queries", RFC 4620, DOI 10.17487/RFC4620, August 2006, . [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, April 2007, . [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., Chen, M., and RFC Publisher, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, . [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. Boucadair, "PROBE: A Utility for Probing Interfaces", RFC 8335, DOI 10.17487/RFC8335, February 2018, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . Authors' Addresses Xiao Min ZTE Corp. Nanjing China Phone: +86 25 88013062 Email: xiao.min2@zte.com.cn Min, et al. Expires 25 May 2023 [Page 18] Internet-Draft Ping Enabled IOAM Capabilities November 2022 Greg Mirsky Ericsson United States of America Email: gregimirsky@gmail.com Lei Bo China Telecom Beijing China Phone: +86 10 50902903 Email: leibo@chinatelecom.cn Min, et al. Expires 25 May 2023 [Page 19] ./draft-ietf-netconf-sztp-csr-14.txt0000644000764400076440000022246714210015073017076 0ustar iustiniustin NETCONF Working Group K. Watsen Internet-Draft Watsen Networks Updates: 8572 (if approved) R. Housley Intended status: Standards Track Vigil Security, LLC Expires: 3 September 2022 S. Turner sn3rd 2 March 2022 Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request draft-ietf-netconf-sztp-csr-14 Abstract This draft extends the input to the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * XXXX --> the assigned numerical RFC value for this draft * AAAA --> the assigned RFC value for I-D.ietf-netconf-crypto-types Artwork in this document contains a placeholder value for the publication date of this draft. Please apply the following replacement: * 2022-03-02 --> the publication date of this draft This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: * I-D.ietf-netconf-crypto-types Watsen, et al. Expires 3 September 2022 [Page 1] Internet-Draft Conveying a CSR in an SZTP Request March 2022 * I-D.ietf-netconf-keystore * I-D.ietf-netconf-trust-anchors Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 September 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2. The "ietf-sztp-csr" Module . . . . . . . . . . . . . . . . . 4 2.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 5 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 8 2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 14 3. The "ietf-ztp-types" Module . . . . . . . . . . . . . . . . . 17 3.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 17 Watsen, et al. Expires 3 September 2022 [Page 2] Internet-Draft Conveying a CSR in an SZTP Request March 2022 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 4.1. SZTP-Client Considerations . . . . . . . . . . . . . . . 27 4.1.1. Ensuring the Integrity of Asymmetric Private Keys . . 27 4.1.2. Reuse of a Manufacturer-generated Private Key . . . . 28 4.1.3. Replay Attack Protection . . . . . . . . . . . . . . 29 4.1.4. Connecting to an Untrusted Bootstrap Server . . . . . 29 4.1.5. Selecting the Best Origin Authentication Mechanism . 30 4.1.6. Clearing the Private Key and Associated Certificate . . . . . . . . . . . . . . . . . . . . . 30 4.2. SZTP-Server Considerations . . . . . . . . . . . . . . . 30 4.2.1. Verifying Proof of Possession . . . . . . . . . . . . 30 4.2.2. Verifying Proof of Origin . . . . . . . . . . . . . . 31 4.2.3. Supporting SZTP-Clients that don't trust the SZTP-Server . . . . . . . . . . . . . . . . . . . . . 31 4.3. Security Considerations for the "ietf-sztp-csr" YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.4. Security Considerations for the "ietf-ztp-types" YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 32 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 5.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 32 5.2. The "YANG Module Names" Registry . . . . . . . . . . . . 32 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.1. Normative References . . . . . . . . . . . . . . . . . . 32 6.2. Informative References . . . . . . . . . . . . . . . . . 34 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction 1.1. Overview This draft extends the input to the "get-bootstrapping-data" RPC defined in [RFC8572] to include an optional certificate signing request (CSR) [RFC2986], enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of the "onboarding information" response provided in the RPC-reply. The ability to provision an identity certificate that is purpose- built for a production environment during the bootstrapping process removes reliance on the manufacturer CA, and it also enables the bootstrapped device to join the production environment with an appropriate identity and other attributes in its identity certificate (e.g., an LDevID). Watsen, et al. Expires 3 September 2022 [Page 3] Internet-Draft Conveying a CSR in an SZTP Request March 2022 Two YANG [RFC7950] modules are defined. The "ietf-ztp-types" module defines three YANG groupings for the various messages defined in this document. The "ietf-sztp-csr" module augments two groupings into the "get-bootstrapping-data" RPC and defines a YANG Data Structure [RFC8791] around the third grouping. 1.2. Terminology This document uses the following terms from [RFC8572]: * Bootstrap Server * Bootstrapping Data * Conveyed Information * Device * Manufacturer * Onboarding Information * Signed Data This document defines the following new terms: SZTP-client The term "SZTP-client" refers to a "device" that is using a "bootstrap server" as a source of "bootstrapping data". SZTP-server The term "SZTP-server" is an alternative term for "bootstrap server" that is symmetric with the "SZTP-client" term. 1.3. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.4. Conventions Various examples used in this document use a placeholder value for binary data that has been base64 encoded (e.g., "BASE64VALUE="). This placeholder value is used as real base64 encoded structures are often many lines long and hence distracting to the example being presented. 2. The "ietf-sztp-csr" Module The "ietf-sztp-csr" module is a YANG 1.1 [RFC7950] module that augments the "ietf-sztp-bootstrap-server" module defined in [RFC8572] and defines a YANG "structure" that is to be conveyed in the "error- info" node defined in Section 7.1 of [RFC8040]. Watsen, et al. Expires 3 September 2022 [Page 4] Internet-Draft Conveying a CSR in an SZTP Request March 2022 2.1. Data Model Overview The following tree diagram [RFC8340] illustrates the "ietf-sztp-csr" module. module: ietf-sztp-csr augment /sztp-svr:get-bootstrapping-data/sztp-svr:input: +---w (msg-type)? +--:(csr-support) | +---w csr-support | +---w key-generation! | | +---w supported-algorithms | | +---w algorithm-identifier* binary | +---w csr-generation | +---w supported-formats | +---w format-identifier* identityref +--:(csr) +---w (csr-type) +--:(p10-csr) | +---w p10-csr? ct:csr +--:(cmc-csr) | +---w cmc-csr? binary +--:(cmp-csr) +---w cmp-csr? binary structure csr-request: +-- key-generation! | +-- selected-algorithm | +-- algorithm-identifier binary +-- csr-generation | +-- selected-format | +-- format-identifier identityref +-- cert-req-info? ct:csr-info The augmentation defines two kinds of parameters that an SZTP-client can send to an SZTP-server. The YANG structure defines one collection of parameters that an SZTP-server can send to an SZTP- client. In the order of their intended use: * The "csr-support" node is used by the SZTP-client to signal to the SZTP-server that it supports the ability to generate CSRs. This parameter conveys if the SZTP-client is able to generate a new asymmetric key and, if so, which key algorithms it supports, as well as conveys what kinds of CSR structures the SZTP-client is able to generate. Watsen, et al. Expires 3 September 2022 [Page 5] Internet-Draft Conveying a CSR in an SZTP Request March 2022 * The "csr-request" structure is used by the SZTP-server to request the SZTP-client to generate a CSR. This structure is used to select the key algorithm the SZTP-client should use to generate a new asymmetric key, if supported, the kind of CSR structure the SZTP-client should generate and, optionally, the content for the CSR itself. * The various "csr" nodes are used by the SZTP-client to communicate a CSR to the SZTP-server. | No data model is defined enabling an SZTP-server to communicate | the signed certificate to the SZTP-client. How to do this is | discussed in Section 2.2. To further illustrate how the augmentation and structure defined by the "ietf-sztp-csr" module are used, below are two additional tree diagrams showing these nodes placed where they are used. The following tree diagram [RFC8340] illustrates SZTP's "get- bootstrapping-data" RPC with the augmentation in place. Watsen, et al. Expires 3 September 2022 [Page 6] Internet-Draft Conveying a CSR in an SZTP Request March 2022 =============== NOTE: '\' line wrapping per RFC 8792 ================ module: ietf-sztp-bootstrap-server rpcs: +---x get-bootstrapping-data +---w input | +---w signed-data-preferred? empty | +---w hw-model? string | +---w os-name? string | +---w os-version? string | +---w nonce? binary | +---w (sztp-csr:msg-type)? | +--:(sztp-csr:csr-support) | | +---w sztp-csr:csr-support | | +---w sztp-csr:key-generation! | | | +---w sztp-csr:supported-algorithms | | | +---w sztp-csr:algorithm-identifier* bina\ ry | | +---w sztp-csr:csr-generation | | +---w sztp-csr:supported-formats | | +---w sztp-csr:format-identifier* identit\ yref | +--:(sztp-csr:csr) | +---w (sztp-csr:csr-type) | +--:(sztp-csr:p10-csr) | | +---w sztp-csr:p10-csr? ct:csr | +--:(sztp-csr:cmc-csr) | | +---w sztp-csr:cmc-csr? binary | +--:(sztp-csr:cmp-csr) | +---w sztp-csr:cmp-csr? binary +--ro output +--ro reporting-level? enumeration {onboarding-server}? +--ro conveyed-information cms +--ro owner-certificate? cms +--ro ownership-voucher? cms The following tree diagram [RFC8340] illustrates RESTCONF's "errors" RPC-reply message with the "csr-request" structure in place. Watsen, et al. Expires 3 September 2022 [Page 7] Internet-Draft Conveying a CSR in an SZTP Request March 2022 module: ietf-restconf +--ro errors +--ro error* [] +--ro error-type enumeration +--ro error-tag string +--ro error-app-tag? string +--ro error-path? instance-identifier +--ro error-message? string +--ro error-info +--ro sztp-csr:csr-request +--ro sztp-csr:key-generation! | +--ro sztp-csr:selected-algorithm | +--ro sztp-csr:algorithm-identifier binary +--ro sztp-csr:csr-generation | +--ro sztp-csr:selected-format | +--ro sztp-csr:format-identifier identityref +--ro sztp-csr:cert-req-info? ct:csr-info 2.2. Example Usage | The examples below are encoded using JSON, but they could | equally well be encoded using XML, as is supported by SZTP. An SZTP-client implementing this specification would signal to the bootstrap server its willingness to generate a CSR by including the "csr-support" node in its "get-bootstrapping-data" RPC. In the example below, the SZTP-client additionally indicates that it is able to generate keys and provides a list of key algorithms it supports, as well as provide a list of certificate formats it supports. REQUEST Watsen, et al. Expires 3 September 2022 [Page 8] Internet-Draft Conveying a CSR in an SZTP Request March 2022 =============== NOTE: '\' line wrapping per RFC 8792 ================ POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ ng-data HTTP/1.1 HOST: example.com Content-Type: application/yang-data+json { "ietf-sztp-bootstrap-server:input" : { "hw-model": "model-x", "os-name": "vendor-os", "os-version": "17.3R2.1", "nonce": "extralongbase64encodedvalue=", "ietf-sztp-csr:csr-support": { "key-generation": { "supported-algorithms": { "algorithm-identifier": [ "BASE64VALUE1", "BASE64VALUE2", "BASE64VALUE3" ] } }, "csr-generation": { "supported-formats": { "format-identifier": [ "ietf-ztp-types:p10-csr", "ietf-ztp-types:cmc-csr", "ietf-ztp-types:cmp-csr" ] } } } } } Assuming the SZTP-server wishes to prompt the SZTP-client to provide a CSR, then it would respond with an HTTP 400 Bad Request error code. In the example below, the SZTP-server specifies that it wishes the SZTP-client to generate a key using a specific algorithm and generate a PKCS#10-based CSR containing specific content. RESPONSE Watsen, et al. Expires 3 September 2022 [Page 9] Internet-Draft Conveying a CSR in an SZTP Request March 2022 HTTP/1.1 400 Bad Request Date: Sat, 31 Oct 2021 17:02:40 GMT Server: example-server Content-Type: application/yang-data+json { "ietf-restconf:errors" : { "error" : [ { "error-type": "application", "error-tag": "missing-attribute", "error-message": "Missing input parameter", "error-info": { "ietf-sztp-csr:csr-request": { "key-generation": { "selected-algorithm": { "algorithm-identifier": "BASE64VALUE=" } }, "csr-generation": { "selected-format": { "format-identifier": "ietf-ztp-types:p10-csr" } }, "cert-req-info": "BASE64VALUE=" } } } ] } } Upon being prompted to provide a CSR, the SZTP-client would POST another "get-bootstrapping-data" request, but this time including one of the "csr" nodes to convey its CSR to the SZTP-server: REQUEST Watsen, et al. Expires 3 September 2022 [Page 10] Internet-Draft Conveying a CSR in an SZTP Request March 2022 =============== NOTE: '\' line wrapping per RFC 8792 ================ POST /restconf/operations/ietf-sztp-bootstrap-server:get-bootstrappi\ ng-data HTTP/1.1 HOST: example.com Content-Type: application/yang-data+json { "ietf-sztp-bootstrap-server:input" : { "hw-model": "model-x", "os-name": "vendor-os", "os-version": "17.3R2.1", "nonce": "extralongbase64encodedvalue=", "ietf-sztp-csr:p10-csr": "BASE64VALUE=" } } At this point, it is expected that the SZTP-server, perhaps in conjunction with other systems, such as a backend CA or RA, will validate the CSR's origin and proof-of-possession and, assuming the CSR is approved, issue a signed certificate for the bootstrapping device. The SZTP-server responds with "onboarding-information" (encoded inside the "conveyed-information" node, shown below) containing a signed identity certificate for the CSR provided by the SZTP-client: RESPONSE HTTP/1.1 200 OK Date: Sat, 31 Oct 2021 17:02:40 GMT Server: example-server Content-Type: application/yang-data+json { "ietf-sztp-bootstrap-server:output" : { "reporting-level": "verbose", "conveyed-information": "BASE64VALUE=" } } How the signed certificate is conveyed inside the onboarding information is outside the scope of this document. Some implementations may choose to convey it inside a script (e.g., SZTP's "pre-configuration-script"), while other implementations may choose to convey it inside the SZTP "configuration" node. SZTP onboarding information is described in Section 2.2 of [RFC8572]. Watsen, et al. Expires 3 September 2022 [Page 11] Internet-Draft Conveying a CSR in an SZTP Request March 2022 Below are two examples of conveying the signed certificate inside the "configuration" node. Both examples assume that the SZTP-client understands the "ietf-keystore" module defined in [I-D.ietf-netconf-keystore]. This first example illustrates the case where the signed certificate is for the same asymmetric key used by the SZTP-client's manufacturer-generated identity certificate (e.g., an IDevID, from [Std-802.1AR-2018]). As such, the configuration needs to associate the newly signed certificate with the existing asymmetric key: =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-keystore:keystore": { "asymmetric-keys": { "asymmetric-key": [ { "name": "Manufacturer-Generated Hidden Key", "public-key-format": "ietf-crypto-types:subject-public-key\ -info-format", "public-key": "BASE64VALUE=", "hidden-private-key": [null], "certificates": { "certificate": [ { "name": "Manufacturer-Generated IDevID Cert", "cert-data": "BASE64VALUE=" }, { "name": "Newly-Generated LDevID Cert", "cert-data": "BASE64VALUE=" } ] } } ] } } } This second example illustrates the case where the signed certificate is for a newly generated asymmetric key. As such, the configuration needs to associate the newly signed certificate with the newly generated asymmetric key: Watsen, et al. Expires 3 September 2022 [Page 12] Internet-Draft Conveying a CSR in an SZTP Request March 2022 =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-keystore:keystore": { "asymmetric-keys": { "asymmetric-key": [ { "name": "Manufacturer-Generated Hidden Key", "public-key-format": "ietf-crypto-types:subject-public-key\ -info-format", "public-key": "BASE64VALUE=", "hidden-private-key": [null], "certificates": { "certificate": [ { "name": "Manufacturer-Generated IDevID Cert", "cert-data": "BASE64VALUE=" } ] } }, { "name": "Newly-Generated Hidden Key", "public-key-format": "ietf-crypto-types:subject-public-key\ -info-format", "public-key": "BASE64VALUE=", "hidden-private-key": [null], "certificates": { "certificate": [ { "name": "Newly-Generated LDevID Cert", "cert-data": "BASE64VALUE=" } ] } } ] } } } In addition to configuring the signed certificate, it is often necessary to also configure the Issuer's signing certificate so that the device (i.e., STZP-client) can authenticate certificates presented by peer devices signed by the same issuer as its own. While outside the scope of this document, one way to do this would be to use the "ietf-truststore" module defined in [I-D.ietf-netconf-trust-anchors]. Watsen, et al. Expires 3 September 2022 [Page 13] Internet-Draft Conveying a CSR in an SZTP Request March 2022 2.3. YANG Module This module augments an RPC defined in [RFC8572]. The module uses a data types and groupings defined in [RFC8572], [RFC8791], and [I-D.ietf-netconf-crypto-types]. The module also has an informative reference to [Std-802.1AR-2018]. file "ietf-sztp-csr@2022-03-02.yang" module ietf-sztp-csr { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-sztp-csr"; prefix sztp-csr; import ietf-sztp-bootstrap-server { prefix sztp-svr; reference "RFC 8572: Secure Zero Touch Provisioning (SZTP)"; } import ietf-yang-structure-ext { prefix sx; reference "RFC 8791: YANG Data Structure Extensions"; } import ietf-ztp-types { prefix zt; reference "RFC XXXX: Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request"; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: https://datatracker.ietf.org/wg/netconf WG List: NETCONF WG list Authors: Kent Watsen Russ Housley Sean Turner "; description "This module augments the 'get-bootstrapping-data' RPC, defined in the 'ietf-sztp-bootstrap-server' module from SZTP (RFC 8572), enabling the SZTP-client to obtain a Watsen, et al. Expires 3 September 2022 [Page 14] Internet-Draft Conveying a CSR in an SZTP Request March 2022 signed identity certificate (e.g., an LDevID from IEEE 802.1AR) as part of the SZTP onboarding information response. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2022-03-02 { description "Initial version"; reference "RFC XXXX: Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request"; } // Protocol-accessible nodes augment "/sztp-svr:get-bootstrapping-data/sztp-svr:input" { description "This augmentation adds the 'csr-support' and 'csr' nodes to the SZTP (RFC 8572) 'get-bootstrapping-data' request message, enabling the SZTP-client to obtain an identity certificate (e.g., an LDevID from IEEE 802.1AR) as part of the onboarding information response provided by the SZTP-server. The 'csr-support' node enables the SZTP-client to indicate that it supports generating certificate signing requests (CSRs), and to provide details around the CSRs it is able to generate. Watsen, et al. Expires 3 September 2022 [Page 15] Internet-Draft Conveying a CSR in an SZTP Request March 2022 The 'csr' node enables the SZTP-client to relay a CSR to the SZTP-server."; reference "IEEE 802.1AR: IEEE Standard for Local and metropolitan area networks - Secure Device Identity RFC 8572: Secure Zero Touch Provisioning (SZTP)"; choice msg-type { description "Messages are mutually exclusive."; case csr-support { description "Indicates how the SZTP-client supports generating CSRs. If present and a SZTP-server wishes to request the SZTP-client generate a CSR, the SZTP-server MUST respond with HTTP code 400 Bad Request with an 'ietf-restconf:errors' message having the 'error-tag' value 'missing-attribute' and the 'error-info' node containing the 'csr-request' structure described in this module."; uses zt:csr-support-grouping; } case csr { description "Provides the CSR generated by the SZTP-client. When present, the SZTP-server SHOULD respond with an SZTP onboarding information message containing a signed certificate for the conveyed CSR. The SZTP-server MAY alternatively respond with another HTTP error containing another 'csr-request', in which case the SZTP-client MUST delete any key generated for the previously generated CSR."; uses zt:csr-grouping; } } } sx:structure csr-request { description "A YANG data structure, per RFC 8791, that specifies details for the CSR that the ZTP-client is to generate."; reference "RFC 8791: YANG Data Structure Extensions"; uses zt:csr-request-grouping; } } Watsen, et al. Expires 3 September 2022 [Page 16] Internet-Draft Conveying a CSR in an SZTP Request March 2022 3. The "ietf-ztp-types" Module This section defines a YANG 1.1 [RFC7950] module that defines three YANG groupings, one each for messages sent between a ZTP-client and ZTP-server. This module is defined independently of the "ietf-sztp- csr" module so that it's groupings may be used by bootstrapping protocols other than SZTP [RFC8572]. 3.1. Data Model Overview The following tree diagram [RFC8340] illustrates the three groupings defined in the "ietf-ztp-types" module. module: ietf-ztp-types grouping csr-support-grouping +-- csr-support +-- key-generation! | +-- supported-algorithms | +-- algorithm-identifier* binary +-- csr-generation +-- supported-formats +-- format-identifier* identityref grouping csr-request-grouping +-- key-generation! | +-- selected-algorithm | +-- algorithm-identifier binary +-- csr-generation | +-- selected-format | +-- format-identifier identityref +-- cert-req-info? ct:csr-info grouping csr-grouping +-- (csr-type) +--:(p10-csr) | +-- p10-csr? ct:csr +--:(cmc-csr) | +-- cmc-csr? binary +--:(cmp-csr) +-- cmp-csr? binary 3.2. YANG Module This module uses a data types and groupings [RFC8791] and [I-D.ietf-netconf-crypto-types]. The module has additional normative references to [RFC2986], [RFC4210], [RFC5272], and [ITU.X690.2015], and an informative reference to [Std-802.1AR-2018]. Watsen, et al. Expires 3 September 2022 [Page 17] Internet-Draft Conveying a CSR in an SZTP Request March 2022 file "ietf-ztp-types@2022-03-02.yang" module ietf-ztp-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ztp-types"; prefix zt; import ietf-crypto-types { prefix ct; reference "RFC AAAA: YANG Data Types and Groupings for Cryptography"; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: https://datatracker.ietf.org/wg/netconf WG List: NETCONF WG list Authors: Kent Watsen Russ Housley Sean Turner "; description "This module defines three groupings that enable bootstrapping devices to 1) indicate if and how they support generating CSRs, 2) obtain a request to generate a CSR, and 3) communicate the requested CSR. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear Watsen, et al. Expires 3 September 2022 [Page 18] Internet-Draft Conveying a CSR in an SZTP Request March 2022 in all capitals, as shown here."; revision 2022-03-02 { description "Initial version"; reference "RFC XXXX: Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request"; } identity certificate-request-format { description "A base identity for the request formats supported by the ZTP-client. Additional derived identities MAY be defined by future efforts."; } identity p10-csr { base certificate-request-format; description "Indicates that the ZTP-client supports generating requests using the 'CertificationRequest' structure defined in RFC 2986."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification Version 1.7"; } identity cmp-csr { base certificate-request-format; description "Indicates that the ZTP-client supports generating requests using a profiled version of the PKIMessage that MUST contain a PKIHeader followed by a PKIBody containing only the ir, cr, kur, or p10cr structure defined in RFC 4210."; reference "RFC 4210: Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)"; } identity cmc-csr { base certificate-request-format; description "Indicates that the ZTP-client supports generating Watsen, et al. Expires 3 September 2022 [Page 19] Internet-Draft Conveying a CSR in an SZTP Request March 2022 requests using a profiled version of the 'Full PKI Request' structure defined in RFC 5272."; reference "RFC 5272: Certificate Management over CMS (CMC)"; } // Protocol-accessible nodes grouping csr-support-grouping { description "A grouping enabling use by other efforts."; container csr-support { description "Enables a ZTP-client to indicate that it supports generating certificate signing requests (CSRs) and provides details about the CSRs it is able to generate."; container key-generation { presence "Indicates that the ZTP-client is capable of generating a new asymmetric key pair. If this node is not present, the ZTP-server MAY request a CSR using the asymmetric key associated with the device's existing identity certificate (e.g., an IDevID from IEEE 802.1AR)."; description "Specifies details for the ZTP-client's ability to generate a new asymmetric key pair."; container supported-algorithms { description "A list of public key algorithms supported by the ZTP-client for generating a new asymmetric key."; leaf-list algorithm-identifier { type binary; min-elements 1; description "An AlgorithmIdentifier, as defined in RFC 2986, encoded using ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification Version 1.7 ITU-T X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)."; Watsen, et al. Expires 3 September 2022 [Page 20] Internet-Draft Conveying a CSR in an SZTP Request March 2022 } } } container csr-generation { description "Specifies details for the ZTP-client's ability to generate a certificate signing requests."; container supported-formats { description "A list of certificate request formats supported by the ZTP-client for generating a new key."; leaf-list format-identifier { type identityref { base zt:certificate-request-format; } min-elements 1; description "A certificate request format supported by the ZTP-client."; } } } } } grouping csr-request-grouping { description "A grouping enabling use by other efforts."; container key-generation { presence "Provided by a ZTP-server to indicate that it wishes the ZTP-client to generate a new asymmetric key. This statement is present so the mandatory descendant nodes do not imply that this node must be configured."; description "The key generation parameters selected by the ZTP-server. This leaf MUST only appear if the ZTP-client's 'csr-support' included the 'key-generation' node."; container selected-algorithm { description "The key algorithm selected by the ZTP-server. The algorithm MUST be one of the algorithms specified by the 'supported-algorithms' node in the ZTP-client's message containing the 'csr-support' structure."; leaf algorithm-identifier { type binary; Watsen, et al. Expires 3 September 2022 [Page 21] Internet-Draft Conveying a CSR in an SZTP Request March 2022 mandatory true; description "An AlgorithmIdentifier, as defined in RFC 2986, encoded using ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification Version 1.7 ITU-T X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)."; } } } container csr-generation { description "Specifies details for the CSR that the ZTP-client is to generate."; container selected-format { description "The CSR format selected by the ZTP-server. The format MUST be one of the formats specified by the 'supported-formats' node in the ZTP-client's request message."; leaf format-identifier { type identityref { base zt:certificate-request-format; } mandatory true; description "A certificate request format to be used by the ZTP-client."; } } } leaf cert-req-info { type ct:csr-info; description "A CertificationRequestInfo structure, as defined in RFC 2986, and modeled via a 'typedef' statement by RFC AAAA. Enables the ZTP-server to provide a fully-populated CertificationRequestInfo structure that the ZTP-client only needs to sign in order to generate the complete 'CertificationRequest' structure to send to ZTP-server Watsen, et al. Expires 3 September 2022 [Page 22] Internet-Draft Conveying a CSR in an SZTP Request March 2022 in its next 'get-bootstrapping-data' request message. When provided, the ZTP-client MUST use this structure to generate its CSR; failure to do so will result in a 400 Bad Request response containing another 'csr-request' structure. When not provided, the ZTP-client SHOULD generate a CSR using the same structure defined in its existing identity certificate (e.g., an IDevID from IEEE 802.1AR). If the 'AlgorithmIdentifier' field contained inside the certificate 'SubjectPublicKeyInfo' field does not match the algorithm identified by the 'selected-algorithm' node, then the client MUST reject the certificate and raise an error."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification RFC AAAA: YANG Data Types and Groupings for Cryptography"; } } grouping csr-grouping { description "Enables a ZTP-client to convey a certificate signing request, using the encoding format selected by a ZTP-server's 'csr-request' response to the ZTP-client's previously sent request containing the 'csr-support' node."; choice csr-type { mandatory true; description "A choice amongst certificate signing request formats. Additional formats MAY be augmented into this 'choice' statement by future efforts."; case p10-csr { leaf p10-csr { type ct:csr; description "A CertificationRequest structure, per RFC 2986. Encoding details are defined in the 'ct:csr' typedef defined in RFC AAAA. A raw P10 does not support origin authentication in Watsen, et al. Expires 3 September 2022 [Page 23] Internet-Draft Conveying a CSR in an SZTP Request March 2022 the CSR structure. External origin authentication may be provided via the ZTP-client's authentication to the ZTP-server at the transport layer (e.g., TLS)."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification RFC AAAA: YANG Data Types and Groupings for Cryptography"; } } case cmc-csr { leaf cmc-csr { type binary; description "A profiled version of the 'Full PKI Request' message defined in RFC 5272, encoded using ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690. For asymmetric key-based origin authentication of a CSR based on the initial device identity certificate's private key for the associated identity certificate's public key, the PKIData contains one reqSequence element and no cmsSequence or otherMsgSequence elements. The reqSequence is the TaggedRequest and it is the tcr CHOICE branch. The tcr is the TaggedCertificationRequest and it is the bodyPartId and the certificateRequest elements. The certificateRequest is signed with the initial device identity certificate's private key. The initial device identity certificate and optionally its certificate chain is included in the SignedData certificates that encapsulates the PKIData. For asymmetric key-based origin authentication based on the initial device identity certificate's private key that signs the encapsulated CSR signed by the local device identity certificate's private key, the PKIData contains one cmsSequence element and no reqSequence or otherMsgSequence elements. The cmsSequence is the TaggedContentInfo and it includes a bodyPartID element and a contentInfo. The contentInfo is a SignedData encapsulating a PKIData with one reqSequence element and no cmsSequence or otherMsgSequence elements. The reqSequence is the TaggedRequest and it is the tcr CHOICE. The tcr is the TaggedCertificationRequest and it is the bodyPartId and the certificateRequest elements. PKIData contains one Watsen, et al. Expires 3 September 2022 [Page 24] Internet-Draft Conveying a CSR in an SZTP Request March 2022 cmsSequence element and no controlSequence, reqSequence, or otherMsgSequence elements. The certificateRequest is signed with the local device identity certificate's private key. The initial device identity certificate and optionally its certificate chain is included in the SignedData certificates that encapsulates the PKIData. For shared secret-based origin authentication of a CSR signed by the local device identity certificate's private key, the PKIData contains one cmsSequence element and no reqSequence or otherMsgSequence elements. The cmsSequence is the TaggedContentInfo and it includes a bodyPartID element and a contentInfo. The contentInfo is an AuthenticatedData encapsulating a PKIData with one reqSequence element and no cmsSequences or otherMsgSequence elements. The reqSequence is the TaggedRequest and it is the tcr CHOICE. The tcr is the TaggedCertificationRequest and it is the bodyPartId and the certificateRequest elements. The certificateRequest is signed with the local device identity certificate's private key. The initial device identity certificate and optionally its certificate chain is included in the SignedData certificates that encapsulates the PKIData."; reference "RFC 5272: Certificate Management over CMS (CMC) ITU-T X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)."; } } case cmp-csr { leaf cmp-csr { type binary; description "A PKIMessage structure, as defined in RFC 4210, encoded using ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690. For asymmetric key-based origin authentication of a CSR based on the initial device identity certificate's private key for the associated initial device identity certificate's public key, PKIMessages contains one PKIMessage with the header and body elements, no protection element, and SHOULD contain the extraCerts element. The header element contains the pvno, sender, Watsen, et al. Expires 3 September 2022 [Page 25] Internet-Draft Conveying a CSR in an SZTP Request March 2022 and recipient elements. The pvno contains cmp2000, and the sender contains the subject of the initial device identity certificate. The body element contains an ir, cr, kur, or p10cr CHOICE of type CertificationRequest. It is signed with the initial device identity certificate's private key. The extraCerts element contains the initial device identity certificate, optionally followed by its certificate chain excluding the trust anchor. For asymmetric key-based origin authentication based on the initial device identity certificate's private key that signs the encapsulated CSR signed by the local device identity certificate's private key, PKIMessages contains one PKIMessage with the header, body, and protection elements, and SHOULD contain the extraCerts element. The header element contains the pvno, sender, recipient, protectionAlg, and optionally senderKID elements. The pvno contains cmp2000, the sender contains the subject of the initial device identity certificate, the protectionAlg contains the AlgorithmIdentifier of the used signature algorithm, and the senderKID contains the subject key identifier of the initial device identity certificate. The body element contains an ir, cr, kur, or p10cr CHOICE of type CertificationRequest. It is signed with the local device identity certificate's private key. The protection element contains the digital signature generated with the initial device identity certificate's private key. The extraCerts element contains the initial device identity certificate, optionally followed by its certificate chain excluding the trust anchor. For shared secret-based origin authentication of a CSR signed by the local device identity certificate's private key, PKIMessages contains one PKIMessage with the header, body, and protection element, and no extraCerts element. The header element contains the pvno, sender, recipient, protectionAlg, and senderKID elements. The pvno contains cmp2000, the protectionAlg contains the AlgorithmIdentifier of the used MAC algorithm, and the senderKID contains a reference the recipient can use to identify the shared secret. The body element contains an ir, cr, kur, or p10cr CHOICE of type CertificationRequest. It is signed with the local device identity certificate's private key. The protection element contains the MAC value generated Watsen, et al. Expires 3 September 2022 [Page 26] Internet-Draft Conveying a CSR in an SZTP Request March 2022 with the shared secret."; reference "RFC 4210: Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) ITU-T X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)."; } } } } } 4. Security Considerations This document builds on top of the solution presented in [RFC8572] and therefore all the Security Considerations discussed in RFC 8572 apply here as well. For the various CSR formats, when using PKCS#10, the security considerations in [RFC2986] apply, when using CMP, the security considerations in [RFC4210] apply and, when using CMC, the security considerations in [RFC5272] apply. For the various authentication mechanisms, when using TLS-level authentication, the security considerations in [RFC8446] apply and, when using HTTP-level authentication, the security considerations in [RFC7235] apply. 4.1. SZTP-Client Considerations 4.1.1. Ensuring the Integrity of Asymmetric Private Keys The private key the SZTP-client uses for the dynamically-generated identity certificate MUST be protected from inadvertent disclosure in order to prevent identity fraud. The security of this private key is essential in order to ensure the associated identity certificate can be used to authenticate the device it is issued to. Watsen, et al. Expires 3 September 2022 [Page 27] Internet-Draft Conveying a CSR in an SZTP Request March 2022 It is RECOMMENDED that devices are manufactured with an HSM (hardware security module), such as a TPM (trusted platform module), to generate and contain the private key within the security perimeter of the HSM. In such cases, the private key, and its associated certificates, MAY have long validity periods. In cases where the SZTP-client does not possess an HSM, or is unable to use an HSM to protect the private key, it is RECOMMENDED to periodically reset the private key (and associated identity certificates) in order to minimize the lifetime of unprotected private keys. For instance, an NMS controller/orchestrator application could periodically prompt the SZTP-client to generate a new private key and provide a certificate signing request (CSR) or, alternatively, push both the key and an identity certificate to the SZTP-client using, e.g., a PKCS #12 message [RFC7292]. In another example, the SZTP-client could be configured to periodically reset the configuration to its factory default, thus causing removal of the private key and associated identity certificates and re-execution of the SZTP protocol. 4.1.2. Reuse of a Manufacturer-generated Private Key It is RECOMMENDED that a new private key is generated for each CSR described in this document. Implementations must randomly generate nonces and private keys. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. As an example of predictable random numbers see CVE-2008-0166 [CVE-2008-0166], and some consequences of low-entropy random numbers are discussed in Mining Your Ps and Qs [MiningPsQs]. The generation of quality random numbers is difficult. [ISO.20543-2019], [NIST.SP.800-90Ar1], BSI AIS 31 [AIS31], BCP 106 [RFC4086], and others offer valuable guidance in this area. This private key SHOULD be protected as well as the built-in private key associated with the SZTP-client's initial device identity certificate (e.g., the IDevID, from [Std-802.1AR-2018]). In cases where it is not possible to generate a new private key that is protected as well as the built-in private key, it is RECOMMENDED to reuse the built-in private key rather than generate a new private key that is not as well protected. Watsen, et al. Expires 3 September 2022 [Page 28] Internet-Draft Conveying a CSR in an SZTP Request March 2022 4.1.3. Replay Attack Protection This RFC enables an SZTP-client to announce an ability to generate a new key to use for its CSR. When the SZTP-server responds with a request for the SZTP-client to generate a new key, it is essential that the SZTP-client actually generates a new key. Generating a new key each time enables the random bytes used to create the key to also serve the dual-purpose of acting like a "nonce" used in other mechanisms to detect replay attacks. When a fresh public/private key pair is generated for the request, confirmation to the SZTP-client that the response has not been replayed is enabled by the SZTP-client's fresh public key appearing in the signed certificate provided by the SZTP-server. When a public/private key pair associated with the manufacturer- generated identity certificate (e.g., IDevID) is used for the request, there may not be confirmation to the SZTP-client that the response has not been replayed; however, the worst case result is a lost certificate that is associated to the private key known only to the SZTP-client. Protection of the private-key information is vital to public-key cryptography. Disclosure of the private-key material to another entity can lead to masquerades. 4.1.4. Connecting to an Untrusted Bootstrap Server [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, by blindly authenticating the SZTP-server's TLS end-entity certificate. As is discussed in Section 9.5 of [RFC8572], in such cases the SZTP- client MUST assert that the bootstrapping data returned is signed, if the SZTP-client is to trust it. However, the HTTP error message used in this document cannot be signed data, as described in RFC 8572. Therefore, the solution presented in this document cannot be used when the SZTP-client connects to an untrusted SZTP-server. Consistent with the recommendation presented in Section 9.6 of [RFC8572], SZTP-clients SHOULD NOT pass the "csr-support" input parameter to an untrusted SZTP-server. SZTP-clients SHOULD pass instead the "signed-data-preferred" input parameter, as discussed in Appendix B of [RFC8572]. Watsen, et al. Expires 3 September 2022 [Page 29] Internet-Draft Conveying a CSR in an SZTP Request March 2022 4.1.5. Selecting the Best Origin Authentication Mechanism The origin of the CSR must be verified before a certificate is issued. When generating a new key, it is important that the SZTP-client be able to provide additional proof that it was the entity that generated the key. The CMP and CMC certificate request formats defined in this document support origin authentication. A raw PKCS#10 CSR does not support origin authentication. The CMP and CMC request formats support origin authentication using both PKI and shared secret. Typically, only one possible origin authentication mechanism can possibly be used but, in the case that the SZTP-client authenticates itself using both TLS-level (e.g., IDevID) and HTTP-level credentials (e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the SZTP-client may need to choose between the two options. In the case that the SZTP-client must choose between an asymmetric key option versus a shared secret for origin authentication, it is RECOMMENDED that the SZTP-client choose using the asymmetric key. 4.1.6. Clearing the Private Key and Associated Certificate Unlike a manufacturer-generated identity certificate (e.g., IDevID), the deployment-generated identity certificate (e.g., LDevID) and the associated private key (assuming a new private key was generated for the purpose), are considered user data and SHOULD be cleared whenever the SZTP-client is reset to its factory default state, such as by the "factory-reset" RPC defined in [RFC8808]. 4.2. SZTP-Server Considerations 4.2.1. Verifying Proof of Possession Regardless if using a new asymmetric key or the bootstrapping device's manufacturer-generated key (e.g., the IDevID key), the public key is placed in the CSR and the CSR is signed by that private key. Proof-of-possession of the private key is verified by ensuring the signature over the CSR using the public key placed in the CSR. Watsen, et al. Expires 3 September 2022 [Page 30] Internet-Draft Conveying a CSR in an SZTP Request March 2022 4.2.2. Verifying Proof of Origin When the bootstrapping device's manufacturer-generated private key (e.g., the IDevID key) is reused for the CSR, proof-of-origin is verified by validating the IDevID-issuer cert and ensuring that the CSR uses the same key pair. When the bootstrapping device's manufacturer-generated private key (e.g., an IDevID key from IEEE 802.1AR) is reused for the CSR, proof- of-origin is verified by validating the IDevID certification path and ensuring that the CSR uses the same key pair. When a fresh asymmetric key is used with the CMP or CMC formats, the authentication is part of the protocols, which could employ either the manufacturer-generated private key or a shared secret. In addition, CMP and CMC support processing by a RA before the request is passed to the CA, which allows for more robust handling of errors. 4.2.3. Supporting SZTP-Clients that don't trust the SZTP-Server [RFC8572] allows SZTP-clients to connect to untrusted SZTP-servers, by blindly authenticating the SZTP-server's TLS end-entity certificate. As is recommended in Section 4.1.4 in this document, in such cases, SZTP-clients SHOULD pass the "signed-data-preferred" input parameter. The reciprocal of this statement is that SZTP-servers, wanting to support SZTP-clients that don't trust them, SHOULD support the "signed-data-preferred" input parameter, as discussed in Appendix B of [RFC8572]. 4.3. Security Considerations for the "ietf-sztp-csr" YANG Module The recommended format for documenting the Security Considerations for YANG modules is described in Section 3.7 of [RFC8407]. However, this module only augments two input parameters into the "get- bootstrapping-data" RPC in [RFC8572], and therefore only needs to point to the relevant Security Considerations sections in that RFC. * Security considerations for the "get-bootstrapping-data" RPC are described in Section 9.16 of [RFC8572]. * Security considerations for the "input" parameters passed inside the "get-bootstrapping-data" RPC are described in Section 9.6 of [RFC8572]. Watsen, et al. Expires 3 September 2022 [Page 31] Internet-Draft Conveying a CSR in an SZTP Request March 2022 4.4. Security Considerations for the "ietf-ztp-types" YANG Module The recommended format for documenting the Security Considerations for YANG modules is described in Section 3.7 of [RFC8407]. However, this module does not define any protocol-accessible nodes (it only defines "identity" and "grouping" statements) and therefore there are no Security considerations to report. 5. IANA Considerations 5.1. The "IETF XML" Registry This document registers two URIs in the "ns" subregistry of the IETF XML Registry [RFC3688] maintained at https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. Following the format in [RFC3688], the following registrations are requested: URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr Registrant Contact: The NETCONF WG of the IETF. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-ztp-types Registrant Contact: The NETCONF WG of the IETF. XML: N/A, the requested URI is an XML namespace. 5.2. The "YANG Module Names" Registry This document registers two YANG modules in the YANG Module Names registry [RFC6020] maintained at https://www.iana.org/assignments/ yang-parameters/yang-parameters.xhtml. Following the format defined in [RFC6020], the below registrations are requested: name: ietf-sztp-csr namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-csr prefix: sztp-csr reference: RFC XXXX name: ietf-ztp-types namespace: urn:ietf:params:xml:ns:yang:ietf-ztp-types prefix: ztp-types reference: RFC XXXX 6. References 6.1. Normative References Watsen, et al. Expires 3 September 2022 [Page 32] Internet-Draft Conveying a CSR in an SZTP Request March 2022 [I-D.ietf-netconf-crypto-types] Watsen, K., "YANG Data Types and Groupings for Cryptography", Work in Progress, Internet-Draft, draft- ietf-netconf-crypto-types-21, 14 September 2021, . [ITU.X690.2015] International Telecommunication Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, DOI 10.17487/RFC4210, September 2005, . [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, . Watsen, et al. Expires 3 September 2022 [Page 33] Internet-Draft Conveying a CSR in an SZTP Request March 2022 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero Touch Provisioning (SZTP)", RFC 8572, DOI 10.17487/RFC8572, April 2019, . [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, June 2020, . 6.2. Informative References [AIS31] Bundesamt für Sicherheit in der Informationstechnik (BSI), Killmann, W., and W. Schindler, "A proposal for: Functionality classes for random number generators, version 2.0", 18 September 2011, . [CVE-2008-0166] National Institute of Science and Technology (NIST), "National Vulnerability Database - CVE-2008-0166", 13 May 2008, . [I-D.ietf-netconf-keystore] Watsen, K., "A YANG Data Model for a Keystore", Work in Progress, Internet-Draft, draft-ietf-netconf-keystore-23, 14 December 2021, . Watsen, et al. Expires 3 September 2022 [Page 34] Internet-Draft Conveying a CSR in an SZTP Request March 2022 [I-D.ietf-netconf-trust-anchors] Watsen, K., "A YANG Data Model for a Truststore", Work in Progress, Internet-Draft, draft-ietf-netconf-trust- anchors-16, 14 December 2021, . [ISO.20543-2019] International Organization for Standardization (ISO), "Information technology -- Security techniques -- Test and analysis methods for random bit generators within ISO/IEC 19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019, October 2019. [MiningPsQs] Security'12: Proceedings of the 21st USENIX conference on Security symposium, Heninger, N., Durumeric, Z., Wustrow, E., and J. A. Halderman, "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", August 2012, . [NIST.SP.800-90Ar1] Barker, Elaine B. and John M. Kelsey, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", DOI 10.6028/NIST.SP.800-90Ar1, NIST NIST SP 800-90Ar1, June 2015, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., and M. Scott, "PKCS #12: Personal Information Exchange Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, . Watsen, et al. Expires 3 September 2022 [Page 35] Internet-Draft Conveying a CSR in an SZTP Request March 2022 [RFC8808] Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for Factory Default Settings", RFC 8808, DOI 10.17487/RFC8808, August 2020, . [Std-802.1AR-2018] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", 14 June 2018, . Acknowledgements The authors would like to thank for following for lively discussions on list and in the halls (ordered by first name): Benjamin Kaduk, David von Oheimb, Dan Romascanu, Eric Vyncke, Hendrik Brockhaus, Guy Fedorkow, Joe Clarke, Meral Shirazipour, Murray Kucherawy, Rich Salz, Rob Wilton, Roman Danyliw, Qin Wu, Yaron Sheffer, and Zaheduzzaman Sarkar. Contributors Special thanks go to David von Oheimb and Hendrik Brockhaus for helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes. Authors' Addresses Kent Watsen Watsen Networks Email: kent+ietf@watsen.net Russ Housley Vigil Security, LLC Email: housley@vigilsec.com Sean Turner sn3rd Email: sean@sn3rd.com Watsen, et al. Expires 3 September 2022 [Page 36] ./draft-ietf-ippm-ioam-deployment-05.txt0000644000764400076440000016715114355251746017746 0ustar iustiniustin ippm F. Brockners, Ed. Internet-Draft Cisco Intended status: Informational S. Bhandari, Ed. Expires: 8 July 2023 Thoughtspot D. Bernier Bell Canada T. Mizrahi, Ed. Huawei 4 January 2023 In-situ OAM Deployment draft-ietf-ippm-ioam-deployment-05 Abstract In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document provides a framework for IOAM deployment and provides IOAM deployment considerations and guidance. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 July 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Brockners, et al. Expires 8 July 2023 [Page 1] Internet-Draft In-situ OAM Deployment January 2023 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IOAM Deployment: Domains And Nodes . . . . . . . . . . . . . 3 4. Types of IOAM . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Per-hop Tracing IOAM . . . . . . . . . . . . . . . . . . 6 4.2. Proof of Transit IOAM . . . . . . . . . . . . . . . . . . 8 4.3. Edge to Edge IOAM . . . . . . . . . . . . . . . . . . . . 8 4.4. Direct Export IOAM . . . . . . . . . . . . . . . . . . . 8 5. IOAM Encapsulations . . . . . . . . . . . . . . . . . . . . . 8 5.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. NSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. BIER . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. GRE . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.5. Geneve . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.6. Segment Routing . . . . . . . . . . . . . . . . . . . . . 9 5.7. Segment Routing for IPv6 . . . . . . . . . . . . . . . . 9 5.8. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 9 7. IOAM Deployment Considerations . . . . . . . . . . . . . . . 11 7.1. IOAM Namespaces . . . . . . . . . . . . . . . . . . . . . 11 7.2. IOAM Layering . . . . . . . . . . . . . . . . . . . . . . 12 7.3. IOAM Trace Option Types . . . . . . . . . . . . . . . . . 13 7.4. Traffic-sets that IOAM Is Applied To . . . . . . . . . . 15 7.5. IOAM Loopback Mode . . . . . . . . . . . . . . . . . . . 15 7.6. IOAM Active Mode . . . . . . . . . . . . . . . . . . . . 16 7.7. Brown Field Deployments: IOAM Unaware Nodes . . . . . . . 17 8. IOAM Manageability . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 12. Informative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction "In-situ" Operations, Administration, and Maintenance (IOAM) collects OAM information within the packet while the packet traverses a particular network domain. The term "in-situ" refers to the fact that the OAM data is added to the data packets rather than is being sent within packets specifically dedicated to OAM. IOAM is to complement mechanisms such as Ping, Traceroute, or other active Brockners, et al. Expires 8 July 2023 [Page 2] Internet-Draft In-situ OAM Deployment January 2023 probing mechanisms. In terms of "active" or "passive" OAM, "in-situ" OAM can be considered a hybrid OAM type. "In-situ" mechanisms do not require extra packets to be sent. IOAM adds information to the already available data packets and therefore cannot be considered passive. In terms of the classification given in [RFC7799] IOAM could be portrayed as Hybrid Type I. IOAM mechanisms can be leveraged where mechanisms using e.g., ICMP do not apply or do not offer the desired results, such as proving that a certain traffic flow takes a pre-defined path, SLA verification for the live data traffic, detailed statistics on traffic distribution paths in networks that distribute traffic across multiple paths, or scenarios in which probe traffic is potentially handled differently from regular data traffic by the network devices. 2. Conventions Abbreviations used in this document: BIER: Bit Index Explicit Replication [RFC8279] Geneve: Generic Network Virtualization Encapsulation [RFC8926] GRE: Generic Routing Encapsulation [RFC2784] IOAM: In-situ Operations, Administration, and Maintenance MTU: Maximum Transmit Unit NSH: Network Service Header [RFC8300] OAM: Operations, Administration, and Maintenance POT: Proof of Transit VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol Extension [I-D.ietf-nvo3-vxlan-gpe] 3. IOAM Deployment: Domains And Nodes IOAM is focused on "limited domains" as defined in [RFC8799]. IOAM is not targeted for a deployment on the global Internet. The part of the network which employs IOAM is referred to as the "IOAM-Domain". For example, an IOAM-domain can include an enterprise campus using physical connections between devices or an overlay network using virtual connections / tunnels for connectivity between said devices. An IOAM-domain is defined by its perimeter or edge. The operator of an IOAM-domain is expected to put provisions in place to ensure that packets which contain IOAM data fields do not leak beyond the edge of Brockners, et al. Expires 8 July 2023 [Page 3] Internet-Draft In-situ OAM Deployment January 2023 an IOAM domain, e.g., using for example packet filtering methods. The operator should consider the potential operational impact of IOAM to mechanisms such as ECMP load-balancing schemes (e.g., load- balancing schemes based on packet length could be impacted by the increased packet size due to IOAM), path MTU (i.e., ensure that the MTU of all links within a domain is sufficiently large to support the increased packet size due to IOAM) and ICMP message handling. An IOAM-Domain consists of "IOAM encapsulating nodes", "IOAM decapsulating nodes" and "IOAM transit nodes". The role of a node (i.e., encapsulating, transit, decapsulating) is defined within an IOAM-Namespace (see below). A node can have different roles in different IOAM-Namespaces. An "IOAM encapsulating node" incorporates one or more IOAM-Option- Types into packets that IOAM is enabled for. If IOAM is enabled for a selected subset of the traffic, the IOAM encapsulating node is responsible for applying the IOAM functionality to the selected subset. An "IOAM transit node" updates one or more of the IOAM-Data-Fields. If both the Pre-allocated and the Incremental Trace Option-Types are present in the packet, each IOAM transit node will update at most one of these Option-Types. Note that in case both Trace Option-Types are present in a packet, it is up to the IOAM data processing systems (see Section 6) to integrate the data from the two Trace Option-Types to form a view of the entire journey of the packet. A transit node does not add new IOAM-Option-Types to a packet, and does not change the IOAM-Data-Fields of an IOAM Edge-to-Edge Option-Type. An "IOAM decapsulating node" removes IOAM-Option-Type(s) from packets. The role of an IOAM-encapsulating, IOAM-transit or IOAM-decapsulating node is always performed within a specific IOAM-Namespace. This means that an IOAM node which is e.g., an IOAM-decapsulating node for IOAM-Namespace "A" but not for IOAM-Namespace "B" will only remove the IOAM-Option-Types for IOAM-Namespace "A" from the packet. An IOAM decapsulating node situated at the edge of an IOAM domain removes all IOAM-Option-Types and associated encapsulation headers for all IOAM-Namespaces from the packet. IOAM-Namespaces allow for a namespace-specific definition and interpretation of IOAM-Data-Fields. Please refer to Section 7.1 for a discussion of IOAM-Namespaces. Brockners, et al. Expires 8 July 2023 [Page 4] Internet-Draft In-situ OAM Deployment January 2023 Export of Export of Export of Export of IOAM data IOAM data IOAM data IOAM data (optional) (optional) (optional) (optional) ^ ^ ^ ^ | | | | | | | | User +---+----+ +---+----+ +---+----+ +---+----+ packets |Encapsu-| | Transit| | Transit| |Decapsu-| -------->|lating |====>| Node |====>| Node |====>|lating |--> |Node | | A | | B | |Node | +--------+ +--------+ +--------+ +--------+ Figure 1: Roles of IOAM nodes IOAM nodes which add or remove the IOAM-Data-Fields can also update the IOAM-Data-Fields at the same time. Or in other words, IOAM encapsulating or decapsulating nodes can also serve as IOAM transit nodes at the same time. Note that not every node in an IOAM domain needs to be an IOAM transit node. For example, a deployment might require that packets traverse a set of firewalls which support IOAM. In that case, only the set of firewall nodes would be IOAM transit nodes rather than all nodes. 4. Types of IOAM IOAM supports different modes of operation, which are differentiated by the type of IOAM data fields being carried in the packet, the data being collected, the type of nodes which collect or update data as well as whether and how nodes export IOAM information. * Per-hop tracing: OAM information about each IOAM node a packet traverses is collected and stored within the user data packet as the packet progresses through the IOAM domain. Potential uses of IOAM per-hop tracing include: - Understand the different paths different packets traverse between an IOAM encapsulating and an IOAM decapsulating node in a network that uses load balancing such as Equal Cost Multi- Path (ECMP). This information could be used to tune the algorithm for ECMP for optimized network resource usage. - Operations/Troubleshooting: Understand which path a particular packet or set of packets take as well as what amount of jitter and delay different IOAM nodes in the path contribute to the overall delay and jitter between the IOAM encapsulating node and the IOAM decapsulating node. Brockners, et al. Expires 8 July 2023 [Page 5] Internet-Draft In-situ OAM Deployment January 2023 * Proof-of-transit: Information that a verifier node can use to verify whether a packet has traversed all nodes that is supposed to traverse is stored within the user data packet. Proof-of- transit could for example be used to verify that a packet indeed passes through all services of a service function chain (e.g., verify whether a packet indeed traversed the set of firewalls that it is expected to traverse), or whether a packet indeed took the expected path. * Edge-to-edge: OAM information which is specific to the edges of an IOAM domain is collected and stored within the user data packet. Edge-to-Edge OAM could be used to gather operational information about a particular network domain, such as the delay and jitter incurred by that network domain or the traffic matrix of the network domain. * Direct export: OAM information about each IOAM node a packet traverses is collected and immediately exported to a collector. Direct export could be used in situations where per-hop tracing information is desired, but gathering the information within the packet - as with per-hop tracing - is not feasible. Rather than automatically correlating the per-hop tracing information, as done with per-hop tracing, direct export requires a collector to correlate the information from the individual nodes. In addition, all nodes enabled for direct export need to be capable to export the IOAM information to the collector. 4.1. Per-hop Tracing IOAM "IOAM tracing data" is expected to be collected at every IOAM transit node that a packet traverses to ensure visibility into the entire path a packet takes within an IOAM-Domain. I.e., in a typical deployment all nodes in an IOAM-Domain would participate in IOAM and thus be IOAM transit nodes, IOAM encapsulating or IOAM decapsulating nodes. If not all nodes within a domain are IOAM capable, IOAM tracing information (i.e., node data, see below) will only be collected on those nodes which are IOAM capable. Nodes which are not IOAM capable will forward the packet without any changes to the IOAM- Data-Fields. The maximum number of hops and the minimum path MTU of the IOAM domain is assumed to be known. IOAM offers two different trace Option-Types, the "incremental" Option-Type as well as the "pre-allocated" Option-Type. For a discussion which of the two option types is the most suitable for an implementation and/or deployment, see Section 7.3. Brockners, et al. Expires 8 July 2023 [Page 6] Internet-Draft In-situ OAM Deployment January 2023 Every node data entry holds information for a particular IOAM transit node that is traversed by a packet. The IOAM decapsulating node removes the IOAM-Option-Type(s) and processes and/or exports the associated data. All IOAM-Data-Fields are defined in the context of an IOAM-Namespace. IOAM tracing can for example collect the following types of information: * Identification of the IOAM node. An IOAM node identifier can match to a device identifier or a particular control point or subsystem within a device. * Identification of the interface that a packet was received on, i.e. ingress interface. * Identification of the interface that a packet was sent out on, i.e. egress interface. * Time of day when the packet was processed by the node as well as the transit delay. Different definitions of processing time are feasible and expected, though it is important that all devices of an in-situ OAM domain follow the same definition. * Generic data: Format-free information where syntax and semantic of the information is defined by the operator in a specific deployment. For a specific IOAM-Namespace, all IOAM nodes should interpret the generic data the same way. Examples for generic IOAM data include geolocation information (location of the node at the time the packet was processed), buffer queue fill level or cache fill level at the time the packet was processed, or even a battery charge level. * Information to detect whether IOAM trace data was added at every hop or whether certain hops in the domain weren't IOAM transit nodes. * Data that relates to how the packet traversed a node (transit delay, buffer occupancy in case the packet was buffered, queue depth in case the packet was queued) The Option-Types of incremental tracing and pre-allocated tracing are defined in [RFC9197]. Brockners, et al. Expires 8 July 2023 [Page 7] Internet-Draft In-situ OAM Deployment January 2023 4.2. Proof of Transit IOAM IOAM Proof of Transit Option-Type is to support path or service function chain [RFC7665] verification use cases. Proof-of-transit could use methods like nested hashing or nested encryption of the IOAM data. The IOAM Proof of Transit Option-Type consist of a fixed size "IOAM proof of transit option header" and "IOAM proof of transit option data fields". For details see [RFC9197]. 4.3. Edge to Edge IOAM The IOAM Edge-to-Edge Option-Type is to carry data that is added by the IOAM encapsulating node and interpreted by IOAM decapsulating node. The IOAM transit nodes may process the data but must not modify it. The IOAM Edge-to-Edge Option-Type consist of a fixed size "IOAM Edge- to-Edge Option-Type header" and "IOAM Edge-to-Edge Option-Type data fields". For details see [RFC9197]. 4.4. Direct Export IOAM Direct Export is an IOAM mode of operation within which IOAM data to be directly exported to a collector rather than being collected within the data packets. The IOAM Direct Export Option-Type consist of a fixed size "IOAM direct export option header". Direct Export for IOAM is defined in [RFC9326]. 5. IOAM Encapsulations IOAM data fields and associated data types for in-situ OAM are defined in [RFC9197]. The in-situ OAM data field can be transported by a variety of transport protocols, including NSH, Segment Routing, Geneve, BIER, IPv6, etc. 5.1. IPv6 IOAM encapsulation for IPv6 is defined in [I-D.ietf-ippm-ioam-ipv6-options], which also discussed IOAM deployment considerations for IPv6 networks 5.2. NSH IOAM encapsulation for NSH is defined in [I-D.ietf-sfc-ioam-nsh]. Brockners, et al. Expires 8 July 2023 [Page 8] Internet-Draft In-situ OAM Deployment January 2023 5.3. BIER IOAM encapsulation for BIER is defined in [I-D.xzlnp-bier-ioam]. 5.4. GRE IOAM encapsulation for GRE is outlined as part of the "EtherType Protocol Identification of In-situ OAM Data" in [I-D.weis-ippm-ioam-eth]. 5.5. Geneve IOAM encapsulation for Geneve is defined in [I-D.brockners-ippm-ioam-geneve]. 5.6. Segment Routing IOAM encapsulation for Segment Routing is defined in [I-D.gandhi-spring-ioam-sr-mpls]. 5.7. Segment Routing for IPv6 IOAM encapsulation for Segment Routing over IPv6 is defined in [I-D.ali-spring-ioam-srv6]. 5.8. VXLAN-GPE IOAM encapsulation for VXLAN-GPE is defined in [I-D.brockners-ippm-ioam-vxlan-gpe]. 6. IOAM Data Export IOAM nodes collect information for packets traversing a domain that supports IOAM. IOAM decapsulating nodes as well as IOAM transit nodes can choose to retrieve IOAM information from the packet, process the information further and export the information using e.g., IPFIX. Raw data export of IOAM data using IPFIX is discussed in [I-D.spiegel-ippm-ioam-rawexport]. "Raw export of IOAM data" refers to a mode of operation where a node exports the IOAM data as it is received in the packet. The exporting node neither interprets, aggregates nor reformats the IOAM data before it is exported. Raw export of IOAM data is to support an operational model where the processing and interpretation of IOAM data is decoupled from the operation of encapsulating/updating/decapsulating IOAM data, which is also referred to as IOAM data-plane operation. The figure below shows the separation of concerns for IOAM export: Exporting IOAM data Brockners, et al. Expires 8 July 2023 [Page 9] Internet-Draft In-situ OAM Deployment January 2023 is performed by the "IOAM node" which performs IOAM data-plane operation, whereas the interpretation of IOAM data is performed by one or several IOAM data processing systems. The separation of concerns is to off-load interpretation, aggregation and formatting of IOAM data from the node which performs data-plane operations. In other words, a node which is focused on data-plane operations, i.e. forwarding of packets and handling IOAM data will not be tasked to also interpret the IOAM data, but can leave this task to another system or a set of systems. For scalability reasons, a single IOAM node could choose to export IOAM data to several IOAM data processing systems. Similarly, there several monitoring systems or analytics systems can be used to further process the data received from the IOAM preprocessing systems. Figure 2 shows an overview of IOAM export, including IOAM data processing systems and monitoring/ analytics systems. +--------------+ +-------------+ | | Monitoring/ | | | Analytics | | | system(s) |-+ +-------------+ ^ | Processed/interpreted/ | aggregated IOAM data | +--------------+ +-------------+ | | IOAM data | | | processing | | | system(s) |-+ +-------------+ ^ | Raw export of | IOAM data | +--------------+-------+------+--------------+ | | | | | | | | User +---+----+ +---+----+ +---+----+ +---+----+ packets |Encapsu-| | Transit| | Transit| |Decapsu-| -------->|lating |====>| Node |====>| Node |====>|lating |--> |Node | | A | | B | |Node | +--------+ +--------+ +--------+ +--------+ Figure 2: IOAM framework with data export Brockners, et al. Expires 8 July 2023 [Page 10] Internet-Draft In-situ OAM Deployment January 2023 7. IOAM Deployment Considerations This section describes several concepts of IOAM, and provides considerations that need to be taken to account when implementing IOAM in a network domain. This includes concepts like IOAM Namespaces, IOAM Layering, traffic-sets that IOAM is applied to and IOAM loopback mode. For a definition of IOAM Namespaces and IOAM layering, please refer to [RFC9197]. IOAM loopback mode is defined in [RFC9322]. 7.1. IOAM Namespaces IOAM-Namespaces add further context to IOAM-Option-Types and associated IOAM-Data-Fields. IOAM-Namespaces are defined in Section 4.3 of [RFC9197]. The Namespace-ID is part of the IOAM Option-Type definition, see e.g., Section 4.4 of [RFC9197] for IOAM Trace Option-Types or Section 4.6 of [RFC9197] for the IOAM Edge-to- Edge Option-Type. IOAM-Namespaces support several uses: * IOAM-Namespaces can be used by an operator to distinguish different operational domains. Devices at domain edges can filter on Namespace-IDs to provide for proper IOAM-Domain isolation. * IOAM-Namespaces provide additional context for IOAM-Data-Fields and thus ensure that IOAM-Data-Fields are unique and can be interpreted properly by management stations or network controllers. While, for example, the node identifier field does not need to be unique in a deployment (e.g., an operator may wish to use different node identifiers for different IOAM layers, even within the same device; or node identifiers might not be unique for other organizational reasons, such as after a merger of two formerly separated organizations), the combination of node_id and Namespace-ID should always be unique. Similarly, IOAM-Namespaces can be used to define how certain IOAM-Data-Fields are interpreted: IOAM offers three different timestamp format options. The Namespace-ID can be used to determine the timestamp format. IOAM-Data-Fields (e.g., buffer occupancy) which do not have a unit associated are to be interpreted within the context of a IOAM- Namespace. The Namespace-ID could also be used to distinguish between different types of interfaces: An interface-id could for example point to a physical interface (e.g., to understand which physical interface of an aggregated link is used when receiving or transmitting a packet) whereas in another case it could refer to a logical interface (e.g., in case of tunnels). Namespace-IDs could be used to distinguish between the different types of interfaces. Brockners, et al. Expires 8 July 2023 [Page 11] Internet-Draft In-situ OAM Deployment January 2023 * IOAM-Namespaces can be used to identify different sets of devices (e.g., different types of devices) in a deployment: If an operator desires to insert different IOAM-Data-Fields based on the device, the devices could be grouped into multiple IOAM-Namespaces. This could be due to the fact that the IOAM feature set differs between different sets of devices, or it could be for reasons of optimized space usage in the packet header. It could also stem from hardware or operational limitations on the size of the trace data that can be added and processed, preventing collection of a full trace for a flow. - Assigning different IOAM Namespace-IDs to different sets of nodes or network partitions and using the Namespace-ID as a selector at the IOAM encapsulating node, a full trace for a flow could be collected and constructed via partial traces in different packets of the same flow. Example: An operator could choose to group the devices of a domain into two IOAM- Namespaces, in a way that at average, only every second hop would be recorded by any device. To retrieve a full view of the deployment, the captured IOAM-Data-Fields of the two IOAM- Namespaces need to be correlated. - Assigning different IOAM Namespace-IDs to different sets of nodes or network partitions and using a separate instance of an IOAM-Option-Type for each Namespace-ID, a full trace for a flow could be collected and constructed via partial traces from each IOAM-Option-Type in each of the packets in the flow. Example: An operator could choose to group the devices of a domain into two IOAM-Namespaces, in a way that each IOAM-Namespace is represented by one of two IOAM-Option-Types in the packet. Each node would record data only for the IOAM-Namespace that it belongs to, ignoring the other IOAM-Option-Type with a IOAM- Namespace to which it doesn't belong. To retrieve a full view of the deployment, the captured IOAM-Data-Fields of the two IOAM-Namespaces need to be correlated. 7.2. IOAM Layering If several encapsulation protocols (e.g., in case of tunneling) are stacked on top of each other, IOAM-Data-Fields could be present in different protocol fields at different layers. Layering allows operators to instrument the protocol layer they want to measure. The behavior follows the ships-in-the-night model, i.e., IOAM-Data-Fields in one layer are independent of IOAM-Data-Fields in another layer. Or in other words: Even though the term "layering" often implies some form of hierarchy and relationship, in IOAM, layers are independent of each other and don't assume any relationship among them. The different layers could, but do not have to share the same IOAM Brockners, et al. Expires 8 July 2023 [Page 12] Internet-Draft In-situ OAM Deployment January 2023 encapsulation mechanisms. Similarly, the semantics of the IOAM-Data- Fields, can, but do not have to be associated to cross different layers. For example, a node which inserts node-id information into two different layers could use "node-id=10" for one layer and "node- id=1000" for the second layer. Figure 3 shows an example of IOAM layering. The figure shows a Geneve tunnel carried over IPv6 which starts at node A and ends at node D. IOAM information is encapsulated in IPv6 as well as in Geneve. At the IPv6 layer, node A is the IOAM encapsulating node (into IPv6), node D is the IOAM decapsulating node and node B and node C are IOAM transit nodes. At the Geneve layer, node A is the IOAM encapsulating node (into Geneve) and node D is the IOAM decapsulating node (from Geneve). The use of IOAM at both layers as shown in the example here could be used to reveal which nodes of an underlay (here the IPv6 network) are traversed by tunneled packet in an overlay (here the Geneve network) - which assumes that the IOAM information encapsulated by nodes A and D into Geneve and IPv6 is associated to each other. +---+----+ +---+----+ User |Geneve | |Geneve | packets |Encapsu-| |Decapsu-| -------->|lating |==================================>|lating |--> | Node | | Node | | A | | D | +--------+ +--------+ ^ ^ | | v v +--------+ +--------+ +--------+ +--------+ |IPv6 | | IPv6 | | IPv6 | |IPv6 | |Encapsu-| | Transit| | Transit| |Decapsu-| |lating |====>| Node |====>| Node |====>|lating | | Node | | | | | | Node | | A | | B | | C | | D | +--------+ +--------+ +--------+ +--------+ Figure 3: IOAM layering example 7.3. IOAM Trace Option Types IOAM offers two different IOAM Option-Types for tracing: "Incremental" Trace-Option-Type and "Pre-allocated" Trace-Option- Type. "Incremental" refers to a mode of operation where the packet is expanded at every IOAM node that adds IOAM-Data-Fields. "Pre- Allocated" describes a mode of operation where the IOAM encapsulating node allocates room for all IOAM-Data-Fields in the entire IOAM Brockners, et al. Expires 8 July 2023 [Page 13] Internet-Draft In-situ OAM Deployment January 2023 domain. More specifically: Pre-allocated Trace-Option: This trace option is defined as a container of node data fields with pre-allocated space for each node to populate its information. This option is useful for implementations where it is efficient to allocate the space once and index into the array to populate the data during transit (e.g., software forwarders often fall into this class). Incremental Trace-Option: This trace option is defined as a container of node data fields where each node allocates and pushes its node data immediately following the option header. Which IOAM Trace-Option-Types can be supported is not only a function of operator-defined configuration, but may also be limited by protocol constraints unique to a given encapsulating protocol. For encapsulating protocols which support both IOAM Trace-Option-Types, the operator decides by means of configuration which Trace-Option- Type(s) will be used for a particular domain. In this case, deployments can mix devices which include either the Incremental Trace-Option-Type or the Pre-allocated Trace-Option-Type. If for example different types of packet forwarders and associated different types of IOAM implementations exist in a deployment and the encapsulating protocol supports both IOAM Trace-Option-Types, a deployment can mix devices which include either the Incremental Trace-Option-Type or the Pre-allocated Trace-Option-Type. As a result, both Option-Types can be present in a packet. IOAM decapsulating nodes remove both types of Trace-Option-Types from the packet. The two different Option-Types cater to different packet forwarding infrastructures and are to allow an optimized implementation of IOAM tracing: Pre-allocated Trace-Option: For some implementations of packet Brockners, et al. Expires 8 July 2023 [Page 14] Internet-Draft In-situ OAM Deployment January 2023 forwarders it is efficient to allocate the space for the maximum number of nodes that IOAM Trace Data-Fields should be collected from and insert/update information in the packet at flexible locations, based on a pointer retrieved from a field in the packet. The IOAM encapsulating node allocates an array of the size of the maximum number of nodes that IOAM Trace Data-Fields should be collected from. IOAM transit nodes index into the array to populate the data during transit. Software forwarders often fall into this class of packet forwarder implementations. The maximum number of nodes that IOAM information could be collected from is configured by the operator on the IOAM encapsulating node. The operator has to ensure that the packet with the pre-allocated array that carries the IOAM Data-Fields does not exceed the MTU of any of the links in the IOAM domain. Incremental Trace-Option: Looking up a pointer contained in the packet and inserting/updating information at a flexible location in the packet as a result of the pointer lookup is costly for some forwarding infrastructures. Hardware-based packet forwarding infrastructures often fall into this category. Consequently, hardware-based packet forwarders could choose to support the incremental IOAM-Trace-Option-Type. The incremental IOAM-Trace- Option-Type eliminates the need for the IOAM transit nodes to read the full array in the Trace-Option-Type and allows packets to grow to the size of the MTU of the IOAM domain. IOAM transit nodes will expand the packet and insert the IOAM-Data-Fields as long as there is space available in the packet, i.e. as long as the size of the packet stays within the bounds of the MTU of the links in the IOAM domain. There is no need for the operator to configure the IOAM encapsulation node with the maximum number of nodes that IOAM information could be collected from. The operator has to ensure that the minimum MTU of the links in the IOAM domain is known to all IOAM transit nodes. 7.4. Traffic-sets that IOAM Is Applied To IOAM can be deployed on all or only on subsets of the live user traffic, e.g., per interface, based on an access control list or flow specification defining a specific set of traffic, etc. 7.5. IOAM Loopback Mode IOAM Loopback is used to trigger each transit device along the path of a packet to send a copy of the data packet back to the source. Loopback allows an IOAM encapsulating node to trace the path to a given destination, and to receive per-hop data about both the forward and the return path. Loopback is enabled by the encapsulating node setting the loopback flag. Looped-back packets use the source Brockners, et al. Expires 8 July 2023 [Page 15] Internet-Draft In-situ OAM Deployment January 2023 address of the original packet as destination address and the address of the node which performs the loopback operation as source address. Nodes which loop back a packet clear the loopback flag before sending the copy back towards the source. Loopack applies to IOAM deployments where the encapsulating node is either a host or the start of a tunnel: For details on IOAM loopback, please refer to [RFC9322]. 7.6. IOAM Active Mode The IOAM active mode flag indicates that a packet is an active OAM packet as opposed to regular user data traffic. Active mode is expected to be used for active measurement using IOAM. For details on IOAM active mode, please refer to [RFC9322]. Example use-cases for IOAM Active Mode include: * Endpoint detailed active measurement: Synthetic probe packets are sent between the source and destination. These probe packets include a Trace Option-Type (i.e., either incremental or pre- allocated). Since the probe packets are sent between the endpoints, these packets are treated as data packets by the IOAM domain, and do not require special treatment at the IOAM layer. The source, which is also the IOAM encapsulating node can choose to set the Active flag, providing an explicit indication that these probe packets are meant for telemetry collection. * IOAM active measurement using probe packets: Probe packets are generated and transmitted by an IOAM encapsulating node towards a destination which is also the IOAM decapsulating node. Probe packets include a Trace Option-Type (i.e., either incremental or pre-allocated) which has its Active flag set. * IOAM active measurement using replicated data packets: Probe packets are created by an IOAM encapsulating node by selecting some or all of the en route data packets and replicating them. A selected data packet that is replicated, and its (possibly truncated) copy is forwarded with one or more IOAM option, while the original packet is forwarded normally, without IOAM options. To the extent possible, the original data packet and its replica are forwarded through the same path. The replica includes a Trace Option-Type that has its Active flag set, indicating that the IOAM decapsulating node should terminate it. In this case the IOAM Active flag ensures that the replicated traffic is not forwarded beyond the IOAM domain. Brockners, et al. Expires 8 July 2023 [Page 16] Internet-Draft In-situ OAM Deployment January 2023 7.7. Brown Field Deployments: IOAM Unaware Nodes A network can consist of a mix of IOAM aware and IOAM unaware nodes. The encapsulation of IOAM-Data-Fields into different protocols (see also Section 5) are defined such that data packets that include IOAM- Data-Fields do not get dropped by IOAM unaware nodes. For example, packets which contain the IOAM-Trace-Option-Types in IPv6 Hop by Hop extension headers are defined with bits to indicate "00 - skip over this option and continue processing the header". This will ensure that when a node that is IOAM unaware receives a packet with IOAM- Data-Fields included, does not drop the packet. Deployments which leverage the IOAM-Trace-Option-Type(s) could benefit from the ability to detect the presence of IOAM unaware nodes, i.e. nodes which forward the packet but do not update/add IOAM-Data-Fields in IOAM-Trace-Option-Type(s). The node data that is defined as part of the IOAM-Trace-Option-Type(s) includes a Hop_Lim field associated to the node identifier to detect missed nodes, i.e. "holes" in the trace. Monitoring/Analytics system(s) could utilize this information to account for the presence of IOAM unaware nodes in the network. 8. IOAM Manageability The YANG model for configuring IOAM in network nodes which support IOAM is defined in [I-D.zhou-ippm-ioam-yang]. A deployment can leverage IOAM profiles to limit the scope of IOAM features, allowing simpler implementation, verification, and interoperability testing in the context of specific use cases that do not require the full functionality of IOAM. An IOAM profile defines a use case or a set of use cases for IOAM, and an associated set of rules that restrict the scope and features of the IOAM specification, thereby limiting it to a subset of the full functionality. IOAM profiles are defined in [I-D.mizrahi-ippm-ioam-profile]. For deployments where the IOAM capabilities of a node are unknown, [I-D.ietf-ippm-ioam-conf-state] could be used to discover the enabled IOAM capabilities of nodes. 9. IANA Considerations This document does not request any IANA actions. Brockners, et al. Expires 8 July 2023 [Page 17] Internet-Draft In-situ OAM Deployment January 2023 10. Security Considerations As discussed in [RFC7276], a successful attack on an OAM protocol in general, and specifically on IOAM, can prevent the detection of failures or anomalies, or create a false illusion of nonexistent ones. The Proof of Transit Option-Type (Section 4.2) is used for verifying the path of data packets. The security considerations of POT are further discussed in [I-D.ietf-sfc-proof-of-transit]. Security considerations related to the use of IOAM flags, in particular the loopback flag are found in [RFC9322]. IOAM data can be subject to eavesdropping. Although the confidentiality of the user data is not at risk in this context, the IOAM data elements can be used for network reconnaissance, allowing attackers to collect information about network paths, performance, queue states, buffer occupancy and other information. Recon is an improbable security threat in an IOAM deployment that is within a confined physical domain. However, in deployments that are not confined to a single LAN, but span multiple interconnected sites (for example, using an overlay network), the inter-site links are expected to be secured (e.g., by IPsec) in order to avoid external eavesdropping and introduction of malicious or false data. Another possible mitigation approach is to use the "direct exporting" mode [RFC9326]. In this case the IOAM related trace information would not be available in the customer data packets, but would trigger exporting of (secured) packet-related IOAM information at every node. IOAM data export and securing IOAM data export is outside the scope of this document. IOAM can be used as a means for implementing Denial of Service (DoS) attacks, or for amplifying them. For example, a malicious attacker can add an IOAM header to packets or modify an IOAM header in en route packets in order to consume the resources of network devices that take part in IOAM or collectors that analyze the IOAM data. Another example is a packet length attack, in which an attacker pushes headers associated with IOAM Option-Types into data packets, causing these packets to be increased beyond the MTU size, resulting in fragmentation or in packet drops. Such DoS attacks can be mitigated by deploying IOAM in confined administrative domains, and by limiting the rate and/or the percentage of packets that an IOAM encapsulating node adds IOAM information to, as well as limiting rate and/or percentage of packets that an IOAM transit or an IOAM decapsulating node creates to export IOAM information extracted from the data packets that carry IOAM information. Brockners, et al. Expires 8 July 2023 [Page 18] Internet-Draft In-situ OAM Deployment January 2023 Even though IOAM focused on limited domains [RFC8799], there might be deployments for which it is important for IOAM transit nodes and IOAM decapsulating nodes to know that the data received hadn't been tampered with. In those cases, the IOAM data should be integrity protected. Integrity protection of IOAM data fields is described in [I-D.ietf-ippm-ioam-data-integrity]. In addition, since IOAM options may include timestamps, if network devices use synchronization protocols then any attack on the time protocol [RFC7384] can compromise the integrity of the timestamp-related data fields. Synchronization attacks can be mitigated by combining a secured time distribution scheme, e.g., [RFC8915], and by using redundant clock sources [RFC5905] and/or redundant network paths for the time distribution protocol [RFC8039]. At the management plane, attacks may be implemented by misconfiguring or by maliciously configuring IOAM-enabled nodes in a way that enables other attacks. Thus, IOAM configuration should be secured in a way that authenticates authorized users and verifies the integrity of configuration procedures. Notably, IOAM is expected to be deployed in limited network domains ([RFC8799]), thus confining the potential attack vectors to within the limited domain. Indeed, in order to limit the scope of threats to within the current network domain the network operator is expected to enforce policies that prevent IOAM traffic from leaking outside the IOAM domain, and prevent an attacker from introducing malicious or false IOAM data to be processed and used within the IOAM domain. IOAM data leakage could lead to privacy issues. Consider an IOAM encapsulating node that is a home gateway in an operator's network. A home gateway is often identified with an individual, and revealing IOAM data such as "IOAM node identifier" or geolocation information outside of the limited domain could be harmful for that user. Note that the Direct Export mode [RFC9326] can mitigate the potential threat of IOAM data leaking through data packets. 11. Acknowledgements The authors would like to thank Tal Mizrahi, Eric Vyncke, Nalini Elkins, Srihari Raghavan, Ranganathan T S, Barak Gafni, Karthik Babu Harichandra Babu, Akshaya Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, Andrew Yourtchenko, Aviv Kfir, Tianran Zhou, Zhenbin (Robin), Joe Clarke, Al Morton, Tom Herbet, Haoyu song, and Mickey Spiegel for the comments and advice on IOAM. 12. Informative References Brockners, et al. Expires 8 July 2023 [Page 19] Internet-Draft In-situ OAM Deployment January 2023 [I-D.ali-spring-ioam-srv6] Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Nainar, N. K., Pignataro, C., Li, C., Chen, M., and G. Dawra, "Segment Routing Header encapsulation for In-situ OAM Data", Work in Progress, Internet-Draft, draft-ali-spring- ioam-srv6-06, 10 July 2022, . [I-D.brockners-ippm-ioam-geneve] Brockners, F., Bhandari, S., Govindan, V. P., Pignataro, C., Nainar, N. K., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Lapukhov, P., Gafni, B., Kfir, A., and M. Spiegel, "Geneve encapsulation for In-situ OAM Data", Work in Progress, Internet-Draft, draft-brockners-ippm-ioam- geneve-05, 19 November 2020, . [I-D.brockners-ippm-ioam-vxlan-gpe] Brockners, F., Bhandari, S., Govindan, V. P., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE Encapsulation for In-situ OAM Data", Work in Progress, Internet-Draft, draft-brockners-ippm-ioam-vxlan-gpe-03, 4 November 2019, . [I-D.gandhi-spring-ioam-sr-mpls] Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., and V. Kozak, "Segment Routing with MPLS Data Plane Encapsulation for In-situ OAM Data", Work in Progress, Internet-Draft, draft-gandhi-spring-ioam-sr-mpls-02, 22 August 2019, . [I-D.ietf-ippm-ioam-conf-state] Min, X., Mirsky, G., and L. Bo, "Echo Request/Reply for Enabled In-situ OAM Capabilities", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-conf-state-10, 21 November 2022, . Brockners, et al. Expires 8 July 2023 [Page 20] Internet-Draft In-situ OAM Deployment January 2023 [I-D.ietf-ippm-ioam-data-integrity] Brockners, F., Bhandari, S., Mizrahi, T., and J. Iurman, "Integrity of In-situ OAM Data Fields", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-data-integrity-03, 24 November 2022, . [I-D.ietf-ippm-ioam-ipv6-options] Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam- ipv6-options-09, 11 October 2022, . [I-D.ietf-nvo3-vxlan-gpe] Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Work in Progress, Internet-Draft, draft-ietf-nvo3-vxlan-gpe-12, 22 September 2021, . [I-D.ietf-sfc-ioam-nsh] Brockners, F. and S. Bhandari, "Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data", Work in Progress, Internet-Draft, draft-ietf-sfc-ioam-nsh-11, 30 September 2022, . [I-D.ietf-sfc-proof-of-transit] Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. Youell, "Proof of Transit", Work in Progress, Internet- Draft, draft-ietf-sfc-proof-of-transit-08, 1 November 2020, . [I-D.mizrahi-ippm-ioam-profile] Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and T. Zhou, "In Situ OAM Profiles", Work in Progress, Internet- Draft, draft-mizrahi-ippm-ioam-profile-06, 17 February 2022, . Brockners, et al. Expires 8 July 2023 [Page 21] Internet-Draft In-situ OAM Deployment January 2023 [I-D.spiegel-ippm-ioam-rawexport] Spiegel, M., Brockners, F., Bhandari, S., and R. Sivakolundu, "In-situ OAM raw data export with IPFIX", Work in Progress, Internet-Draft, draft-spiegel-ippm-ioam- rawexport-06, 21 February 2022, . [I-D.weis-ippm-ioam-eth] Weis, B., Brockners, F., Hill, C., Bhandari, S., Govindan, V. P., Pignataro, C., Nainar, N. K., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., and M. Spiegel, "EtherType Protocol Identification of In-situ OAM Data", Work in Progress, Internet-Draft, draft-weis-ippm-ioam-eth-05, 21 February 2022, . [I-D.xzlnp-bier-ioam] Min, X., Zhang, Z., Liu, Y., Nainar, N. K., and C. Pignataro, "Bit Index Explicit Replication (BIER) Encapsulation for In-situ OAM (IOAM) Data", Work in Progress, Internet-Draft, draft-xzlnp-bier-ioam-04, 25 July 2022, . [I-D.zhou-ippm-ioam-yang] Zhou, T., Guichard, J., Brockners, F., and S. Raghavan, "A YANG Data Model for In-Situ OAM", Work in Progress, Internet-Draft, draft-zhou-ippm-ioam-yang-08, 30 July 2020, . [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina, P., and RFC Publisher, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., Kasch, W., and RFC Publisher, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . Brockners, et al. Expires 8 July 2023 [Page 22] Internet-Draft In-situ OAM Deployment January 2023 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., Weingarten, Y., and RFC Publisher, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, June 2014, . [RFC7384] Mizrahi, T. and RFC Publisher, "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, . [RFC7665] Halpern, J., Ed., Pignataro, C., Ed., and RFC Publisher, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . [RFC7799] Morton, A. and RFC Publisher, "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, . [RFC8039] Shpiner, A., Tse, R., Schelp, C., Mizrahi, T., and RFC Publisher, "Multipath Time Synchronization", RFC 8039, DOI 10.17487/RFC8039, December 2016, . [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., Aldrin, S., and RFC Publisher, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, . [RFC8300] Quinn, P., Ed., Elzur, U., Ed., Pignataro, C., Ed., and RFC Publisher, "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, . [RFC8799] Carpenter, B., Liu, B., and RFC Publisher, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., Sundblad, R., and RFC Publisher, "Network Time Security for the Network Time Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, . Brockners, et al. Expires 8 July 2023 [Page 23] Internet-Draft In-situ OAM Deployment January 2023 [RFC8926] Gross, J., Ed., Ganga, I., Ed., Sridhar, T., Ed., and RFC Publisher, "Geneve: Generic Network Virtualization Encapsulation", RFC 8926, DOI 10.17487/RFC8926, November 2020, . [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., Mizrahi, T., Ed., and RFC Publisher, "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . [RFC9322] Mizrahi, T., Brockners, F., Bhandari, S., Gafni, B., Spiegel, M., and RFC Publisher, "In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags", RFC 9322, DOI 10.17487/RFC9322, November 2022, . [RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., Mizrahi, T., and RFC Publisher, "In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting", RFC 9326, DOI 10.17487/RFC9326, November 2022, . Authors' Addresses Frank Brockners (editor) Cisco Systems, Inc. Hansaallee 249, 3rd Floor 40549 DUESSELDORF Germany Email: fbrockne@cisco.com Shwetha Bhandari (editor) Thoughtspot 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout Bangalore, KARNATAKA 560 102 India Email: shwetha.bhandari@thoughtspot.com Daniel Bernier Bell Canada Canada Email: daniel.bernier@bell.ca Brockners, et al. Expires 8 July 2023 [Page 24] Internet-Draft In-situ OAM Deployment January 2023 Tal Mizrahi (editor) Huawei 8-2 Matam Haifa 3190501 Israel Email: tal.mizrahi.phd@gmail.com Brockners, et al. Expires 8 July 2023 [Page 25] ./draft-ietf-lsr-flex-algo-26.txt0000644000764400076440000033524314323212050016332 0ustar iustiniustin Network Working Group P. Psenak, Ed. Internet-Draft Cisco Systems, Inc. Intended status: Standards Track S. Hegde Expires: 20 April 2023 Juniper Networks, Inc. C. Filsfils Cisco Systems, Inc. K. Talaulikar Cisco Systems, Inc A. Gulko Edward Jones 17 October 2022 IGP Flexible Algorithm draft-ietf-lsr-flex-algo-26 Abstract IGP protocols historically compute best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE based or Segment Routing based Traffic Engineering to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 20 April 2023. Psenak, et al. Expires 20 April 2023 [Page 1] Internet-Draft IGP Flexible Algorithm October 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Flexible Algorithm . . . . . . . . . . . . . . . . . . . . . 5 5. Flexible Algorithm Definition Advertisement . . . . . . . . . 6 5.1. IS-IS Flexible Algorithm Definition Sub-TLV . . . . . . . 6 5.2. OSPF Flexible Algorithm Definition TLV . . . . . . . . . 8 5.3. Common Handling of Flexible Algorithm Definition TLV . . 10 6. Sub-TLVs of IS-IS FAD Sub-TLV . . . . . . . . . . . . . . . . 11 6.1. IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV . . 11 6.2. IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3. IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.4. IS-IS Flexible Algorithm Definition Flags Sub-TLV . . . . 14 6.5. IS-IS Flexible Algorithm Exclude SRLG Sub-TLV . . . . . . 16 7. Sub-TLVs of OSPF FAD TLV . . . . . . . . . . . . . . . . . . 17 7.1. OSPF Flexible Algorithm Exclude Admin Group Sub-TLV . . . 17 7.2. OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.3. OSPF Flexible Algorithm Include-All Admin Group Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.4. OSPF Flexible Algorithm Definition Flags Sub-TLV . . . . 19 7.5. OSPF Flexible Algorithm Exclude SRLG Sub-TLV . . . . . . 20 8. IS-IS Flexible Algorithm Prefix Metric Sub-TLV . . . . . . . 21 9. OSPF Flexible Algorithm Prefix Metric Sub-TLV . . . . . . . . 22 10. OSPF Flexible Algorithm ASBR Reachability Advertisement . . . 23 10.1. OSPFv2 Extended Inter-Area ASBR LSA . . . . . . . . . . 23 10.1.1. OSPFv2 Extended Inter-Area ASBR TLV . . . . . . . . 25 10.2. OSPF Flexible Algorithm ASBR Metric Sub-TLV . . . . . . 26 11. Advertisement of Node Participation in a Flex-Algorithm . . . 28 Psenak, et al. Expires 20 April 2023 [Page 2] Internet-Draft IGP Flexible Algorithm October 2022 11.1. Advertisement of Node Participation for Segment Routing . . . . . . . . . . . . . . . . . . . . . . . . 28 11.2. Advertisement of Node Participation for Other Data-planes . . . . . . . . . . . . . . . . . . . . . . 28 12. Advertisement of Link Attributes for Flex-Algorithm . . . . . 29 13. Calculation of Flexible Algorithm Paths . . . . . . . . . . . 30 13.1. Multi-area and Multi-domain Considerations . . . . . . . 31 14. Flex-Algorithm and Forwarding Plane . . . . . . . . . . . . . 34 14.1. Segment Routing MPLS Forwarding for Flex-Algorithm . . . 34 14.2. SRv6 Forwarding for Flex-Algorithm . . . . . . . . . . . 35 14.3. Other Data-planes' Forwarding for Flex-Algorithm . . . . 36 15. Operational Considerations . . . . . . . . . . . . . . . . . 36 15.1. Inter-area Considerations . . . . . . . . . . . . . . . 36 15.2. Usage of SRLG Exclude Rule with Flex-Algorithm . . . . . 37 15.3. Max-metric consideration . . . . . . . . . . . . . . . . 37 15.4. FAD Definition and Changes . . . . . . . . . . . . . . . 38 15.5. Number of Flex-Algorithms . . . . . . . . . . . . . . . 38 16. Backward Compatibility . . . . . . . . . . . . . . . . . . . 38 17. Security Considerations . . . . . . . . . . . . . . . . . . . 38 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 18.1. IGP IANA Considerations . . . . . . . . . . . . . . . . 39 18.1.1. IGP Algorithm Types Registry . . . . . . . . . . . . 39 18.1.2. IGP Metric-Type Registry . . . . . . . . . . . . . . 39 18.2. Flexible Algorithm Definition Flags Registry . . . . . . 40 18.3. IS-IS IANA Considerations . . . . . . . . . . . . . . . 40 18.3.1. IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV . . . 40 18.3.2. IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability . . . . . . . . . . . . . . . . . . . . 41 18.3.3. Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 41 18.4. OSPF IANA Considerations . . . . . . . . . . . . . . . . 42 18.4.1. OSPF Router Information (RI) TLVs Registry . . . . . 42 18.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs . . . . . . . . 42 18.4.3. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . 42 18.4.4. OSPF Flex-Algorithm Prefix Metric Bits . . . . . . . 43 18.4.5. OSPFv2 Opaque LSA Option Types . . . . . . . . . . . 43 18.4.6. OSPFv2 Extended Inter-Area ASBR TLVs . . . . . . . . 44 18.4.7. OSPFv2 Inter-Area ASBR Sub-TLVs . . . . . . . . . . 44 18.4.8. OSPF Flexible Algorithm Definition TLV Sub-TLV Registry . . . . . . . . . . . . . . . . . . . . . . 44 18.4.9. Link Attribute Applications Registry . . . . . . . . 46 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 20.1. Normative References . . . . . . . . . . . . . . . . . . 46 20.2. Informative References . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 Psenak, et al. Expires 20 April 2023 [Page 3] Internet-Draft IGP Flexible Algorithm October 2022 1. Introduction An IGP-computed path based on the shortest IGP metric is often replaced by a traffic-engineered path due to requirements which are not reflected by the IGP metric. Some networks engineer the IGP metric assignments in a way that the IGP metric reflects the link bandwidth or delay. If, for example, the IGP metric reflects the bandwidth on the link and user traffic is delay sensitive, the best IGP path may not reflect the best path from such a user's perspective. To overcome this limitation, various sorts of traffic engineering have been deployed, including RSVP-TE and SR-TE, in which case the TE component is responsible for computing paths based on additional metrics and/or constraints. Such paths need to be installed in the forwarding tables in addition to, or as a replacement for, the original paths computed by IGPs. Tunnels are often used to represent the engineered paths and mechanisms like the one described in [RFC3906] are used to replace the original IGP paths with such tunnel paths. This document specifies a set of extensions to IS-IS, OSPFv2, and OSPFv3 that enable a router to advertise TLVs that (a) identify calculation-type, (b) specify a metric-type, and (c) describe a set of constraints on the topology, that are to be used to compute the best paths along the constrained topology. A given combination of calculation-type, metric-type, and constraints is known as a "Flexible Algorithm Definition". A router that sends such a set of TLVs also assigns a Flex-Algorithm value to the specified combination of calculation-type, metric-type, and constraints. This document also specifies a way for a router to use IGPs to associate one or more "Segment Routing with the MPLS Data Plane (SR- MPLS)" Prefix-SIDs [RFC8660], or "Segment Routing over IPv6 (SRv6)" locators [RFC8986] with a particular Flex-Algorithm. Each such Prefix-SID or SRv6 locator then represents a path that is computed according to the identified Flex-Algorithm. In SRv6 it is the locator, not the SID, that holds the binding to the algorithm. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Psenak, et al. Expires 20 April 2023 [Page 4] Internet-Draft IGP Flexible Algorithm October 2022 3. Terminology This section defines terms that are often used in this document. Flexible Algorithm Definition (FAD) - the set consisting of (a) calculation-type, (b) metric-type, and (c) a set of constraints. Flex-Algorithm - a numeric identifier in the range 128-255 that is associated via configuration with the Flexible Algorithm Definition. Local Flexible Algorithm Definition - Flexible Algorithm Definition defined locally on the node. Remote Flexible Algorithm Definition - Flexible Algorithm Definition received from other nodes via IGP flooding. Flexible Algorithm Participation - per data-plane configuration state that expresses whether the node is participating in a particular Flexible Algorithm. Not all routers in a given network need to participate in a given Flexible Algorithm. The Flexible Algorithm(s) a given router participates in is determined by configuration. IGP Algorithm - value from the "IGP Algorithm Types" registry defined under "Interior Gateway Protocol (IGP) Parameters" IANA registry grouping. IGP Algorithms represents the triplet (calculation-type, metric-type, constraints), where the second and third elements of the triple MAY be unspecified. ABR - Area Border Router. In IS-IS terminology it is also known as L1/L2 router. ASBR - Autonomous System Border Router. 4. Flexible Algorithm Many possible constraints may be used to compute a path over a network. Some networks are deployed as multiple planes. A simple form of constraint may be to use a particular plane. A more sophisticated form of constraint can include some extended metric as described in [RFC8570]. Constraints which restrict paths to links with specific affinities or avoid links with specific affinities are also possible. Combinations of these are also possible. To provide maximum flexibility, a mechanism is provided that allows a router to (a) identify a particular calculation-type and (b) metric- type, (c) describe a particular set of constraints, and (d) assign a numeric identifier, referred to as Flex-Algorithm, to the combination of that calculation-type, metric-type, and those constraints. The Psenak, et al. Expires 20 April 2023 [Page 5] Internet-Draft IGP Flexible Algorithm October 2022 mapping between the Flex-Algorithm and its meaning is flexible and defined by the user. As long as all routers in the domain have a common understanding as to what a particular Flex-Algorithm represents, the resulting routing computation is consistent and traffic is not subject to any looping. The set consisting of (a) calculation-type, (b) metric-type, and (c) a set of constraints is referred to as a Flexible Algorithm Definition. Flex-Algorithm is a numeric identifier in the range 128-255 that is associated via configuration with the Flexible Algorithm Definition. The IANA "IGP Algorithm Types" registry defines the set of values for IGP Algorithms. The following values area allocated by IANA from this registry for Flex-Algorithms: 128-255 - Flex-Algorithms 5. Flexible Algorithm Definition Advertisement To guarantee loop-free forwarding for paths computed for a particular Flex-Algorithm, all routers that (a) are configured to participate in a particular Flex-Algorithm, and (b) are in the same Flex-Algorithm definition advertisement scope MUST agree on the definition of the Flex-Algorithm. The following procedures ensure this condition is fulfilled. 5.1. IS-IS Flexible Algorithm Definition Sub-TLV The IS-IS Flexible Algorithm Definition Sub-TLV (FAD Sub-TLV) is used to advertise the definition of the Flex-Algorithm. The IS-IS FAD Sub-TLV is advertised as a Sub-TLV of the IS-IS Router Capability TLV-242 that is defined in [RFC7981]. IS-IS FAD Sub-TLV has the following format: Psenak, et al. Expires 20 April 2023 [Page 6] Internet-Draft IGP Flexible Algorithm October 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Flex-Algorithm | Metric-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Calc-Type | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs | + + | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 26 Length: variable number of octets, dependent on the included Sub- TLVs Flex-Algorithm: Flexible Algorithm number. Single octet value between 128 and 255 inclusive. Metric-Type: Type of metric from the "IGP Metric-Type Registry" (Section 18.1.2) to be used during the calculation. The following values are defined: 0: IGP Metric 1: Min Unidirectional Link Delay as defined in [RFC8570], section 4.2, encoded as application specific link attribute as specified in [RFC8919] and Section 12 of this document. 2: Traffic Engineering Default Metric as defined in [RFC5305], section 3.7, encoded as application specific link attribute as specified in [RFC8919] and Section 12 of this document. Calc-Type: calculation-type, value from 0 to 127 inclusive from the "IGP Algorithm Types" registry defined under "Interior Gateway Protocol (IGP) Parameters" IANA registries. IGP algorithms in the range of 0-127 have a defined triplet (calculation-type, metric- type, constraints). When used to specify the calculation-type in the FAD Sub-TLV, only the calculation-type defined for the specified IGP Algorithm is used. The Metric/Constraints MUST NOT be inherited. If the required calculation-type is Shortest Path First, the value 0 MUST appear in this field. Psenak, et al. Expires 20 April 2023 [Page 7] Internet-Draft IGP Flexible Algorithm October 2022 Priority: Value between 0 and 255 inclusive that specifies the priority of the advertisement. Numerically greater values are preferred. Usage fo the priority is described in Section 5.3. Sub-TLVs - optional sub-TLVs. The IS-IS FAD Sub-TLV MAY be advertised in an LSP of any number. IS- IS router MAY advertise more than one IS-IS FAD Sub-TLV for a given Flexible Algorithm (see Section 6). The IS-IS FAD Sub-TLV has an area scope. The Router Capability TLV in which the FAD Sub-TLV is present MUST have the S-bit clear. An IS-IS L1/L2 router MAY be configured to re-generate the winning FAD from level 2, without any modification to it, to the level 1 area. The re-generation of the FAD Sub-TLV from level 2 to level 1 is determined by the L1/L2 router, not by the originator of the FAD advertisement in the level 2. In such a case, the re-generated FAD Sub-TLV will be advertised in the level 1 Router Capability TLV originated by the L1/L2 router. An L1/L2 router MUST NOT re-generate any FAD Sub-TLV from level 1 to level 2. 5.2. OSPF Flexible Algorithm Definition TLV The OSPF FAD TLV is advertised as a top-level TLV of the Router Information (RI) LSA that is defined in [RFC7770]. The OSPF FAD TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Flex-Algorithm | Metric-Type | Calc-Type | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs | + + | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Psenak, et al. Expires 20 April 2023 [Page 8] Internet-Draft IGP Flexible Algorithm October 2022 Type: 16 Length: variable number of octets, dependent on the included Sub- TLVs Flex-Algorithm: Flexible Algorithm number. Single octet value between 128 and 255 inclusive. Metric-Type: Type of metric from the "IGP Metric-Type Registry" (Section 18.1.2) to be used during the calculation. The following values are defined: 0: IGP Metric 1: Min Unidirectional Link Delay as defined in [RFC7471], section 4.2, encoded as application specific link attribute as specified in [RFC8920] and Section 12 of this document. 2: Traffic Engineering metric as defined in [RFC3630], section 2.5.5, encoded as application specific link attribute as specified in [RFC8920] and Section 12 of this document. Calc-Type: as described in Section 5.1 Priority: as described in Section 5.1 Sub-TLVs - optional sub-TLVs. When multiple OSPF FAD TLVs, for the same Flexible Algorithm, are received from a given router, the receiver MUST use the first occurrence of the TLV in the Router Information LSA. If the OSPF FAD TLV, for the same Flex-Algorithm, appears in multiple Router Information LSAs that have different flooding scopes, the OSPF FAD TLV in the Router Information LSA with the area-scoped flooding scope MUST be used. If the OSPF FAD TLV, for the same algorithm, appears in multiple Router Information LSAs that have the same flooding scope, the OSPF FAD TLV in the Router Information (RI) LSA with the numerically smallest Instance ID MUST be used and subsequent instances of the OSPF FAD TLV MUST be ignored. The RI LSA can be advertised at any of the defined opaque flooding scopes (link, area, or Autonomous System (AS)). For the purpose of OSPF FAD TLV advertisement, area-scoped flooding is REQUIRED. The Autonomous System flooding scope SHOULD NOT be used unless local configuration policy on the originating router indicates domain wide flooding. Psenak, et al. Expires 20 April 2023 [Page 9] Internet-Draft IGP Flexible Algorithm October 2022 5.3. Common Handling of Flexible Algorithm Definition TLV This section describes the protocol-independent handling of the FAD TLV (OSPF) or FAD Sub-TLV (IS-IS). We will refer to it as FAD TLV in this section, even though in the case of IS-IS it is a Sub-TLV. The value of the Flex-Algorithm MUST be between 128 and 255 inclusive. If it is not, the FAD TLV MUST be ignored. Only a subset of the routers participating in the particular Flex- Algorithm need to advertise the definition of the Flex-Algorithm. Every router, that is configured to participate in a particular Flex- Algorithm, MUST select the Flex-Algorithm definition based on the following ordered rules. This allows for the consistent Flex- Algorithm definition selection in cases where different routers advertise different definitions for a given Flex-Algorithm: 1. From the advertisements of the FAD in the area (including both locally generated advertisements and received advertisements) select the one(s) with the numerically greatest priority value. 2. If there are multiple advertisements of the FAD with the same numerically greatest priority, select the one that is originated from the router with the numerically greatest System-ID, in the case of IS-IS, or Router ID, in the case of OSPFv2 and OSPFv3. For IS-IS, the System-ID is described in [ISO10589]. For OSPFv2 and OSPFv3, standard Router ID is described in [RFC2328] and [RFC5340] respectively. The FAD selected according to these rules is also known as the "winning FAD". A router that is not configured to participate in a particular Flex- Algorithm MUST ignore FAD Sub-TLVs advertisements for such Flex- Algorithm. A router that is not participating in a particular Flex-Algorithm MAY advertise FAD for such Flex-Algorithm. Receiving routers MUST consider a received FAD advertisement regardless of the Flex- Algorithm participation of that FAD advertisement's originator. Any change in the Flex-Algorithm definition may result in temporary disruption of traffic that is forwarded based on such Flex-Algorithm paths. The impact is similar to any other event that requires network-wide convergence. Psenak, et al. Expires 20 April 2023 [Page 10] Internet-Draft IGP Flexible Algorithm October 2022 If a node is configured to participate in a particular Flexible Algorithm, but there is no valid Flex-Algorithm definition available for it, or the selected Flex-Algorithm definition includes calculation-type, metric-type, constraint, flag, or Sub-TLV that is not supported by the node, it MUST stop participating in such Flexible Algorithm. That implies that it MUST NOT announce participation for such Flexible Algorithm as specified in Section 11 and it MUST remove any forwarding state associated with it. Flex-Algorithm definition is topology independent. It applies to all topologies that a router participates in. 6. Sub-TLVs of IS-IS FAD Sub-TLV One of the limitations of IS-IS [ISO10589] is that the length of a TLV/sub-TLV is limited to a maximum of 255 octets. For the FAD sub- TLV, there are a number of sub-sub-TLVs (defined below) which are supported. For a given Flex-Algorithm, it is possible that the total number of octets required to completely define a FAD exceeds the maximum length supported by a single FAD sub-TLV. In such cases, the FAD MAY be split into multiple such sub-TLVs and the content of the multiple FAD sub-TLVs combined to provide a complete FAD for the Flex-Algorithm. In such a case, the fixed portion of the FAD (see Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex- Algorithm from a given IS. In case the fixed portion of such FAD Sub-TLVs differ, the values in the fixed portion in the FAD sub-TLV in the first occurrence in the lowest numbered LSP from a given IS MUST be used. Any specification that introduces a new IS-IS FAD sub-sub-TLV MUST specify whether the FAD sub-TLV may appear multiple times in the set of FAD sub-TLVs for a given Flex-Algorithm from a given IS and how to handle them if multiple are allowed. 6.1. IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV The Flexible Algorithm definition can specify 'colors' that are used by the operator to exclude links during the Flex-Algorithm path computation. The IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV is used to advertise the exclude rule that is used during the Flex-Algorithm path calculation as specified in Section 13. The IS-IS Flexible Algorithm Exclude Admin Group Sub-TLV (FAEAG Sub- TLV) is a Sub-TLV of the IS-IS FAD Sub-TLV. It has the following format: Psenak, et al. Expires 20 April 2023 [Page 11] Internet-Draft IGP Flexible Algorithm October 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Admin Group | +- -+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 1 Length: variable, dependent on the size of the Extended Admin Group. MUST be a multiple of 4 octets. Extended Administrative Group: Extended Administrative Group as defined in [RFC7308]. The IS-IS FAEAG Sub-TLV MUST NOT appear more than once in a single IS-IS FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub- TLV MUST be ignored by the receiver. The IS-IS FAEAG Sub-TLV MUST NOT appear more than once in the set of FAD sub-TLVs for a given Flex-Algorithm from a given IS. If it appears more than once in such a set, the IS-IS FAEAG Sub-TLV in the first occurrence in the lowest numbered LSP from a given IS MUST be used and any other occurrences MUST be ignored. 6.2. IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV The Flexible Algorithm definition can specify 'colors' that are used by the operator to include links during the Flex-Algorithm path computation. The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV is used to advertise the include-any rule that is used during the Flex- Algorithm path calculation as specified in Section 13. The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV is a Sub-TLV of the IS-IS FAD Sub-TLV. It has the following format: Psenak, et al. Expires 20 April 2023 [Page 12] Internet-Draft IGP Flexible Algorithm October 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Admin Group | +- -+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 2 Length: variable, dependent on the size of the Extended Admin Group. MUST be a multiple of 4 octets. Extended Administrative Group: Extended Administrative Group as defined in [RFC7308]. The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV MUST NOT appear more than once in a single IS-IS FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub-TLV MUST be ignored by the receiver. The IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV MUST NOT appear more than once in the set of FAD sub-TLVs for a given Flex- Algorithm from a given IS. If it appears more than once in such a set, the IS-IS Flexible Algorithm Include-Any Admin Group Sub-TLV in the first occurrence in the lowest numbered LSP from a given IS MUST be used and any other occurrences MUST be ignored. 6.3. IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV The Flexible Algorithm definition can specify 'colors' that are used by the operator to include links during the Flex-Algorithm path computation. The IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV is used to advertise the include-all rule that is used during the Flex- Algorithm path calculation as specified in Section 13. The IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV is is a Sub-TLV of the IS-IS FAD Sub-TLV. It has the following format: Psenak, et al. Expires 20 April 2023 [Page 13] Internet-Draft IGP Flexible Algorithm October 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Admin Group | +- -+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 3 Length: variable, dependent on the size of the Extended Admin Group. MUST be a multiple of 4 octets. Extended Administrative Group: Extended Administrative Group as defined in [RFC7308]. The IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV MUST NOT appear more than once in a single IS-IS FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub-TLV MUST be ignored by the receiver. The IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV MUST NOT appear more than once in the set of FAD sub-TLVs for a given Flex- Algorithm from a given IS. If it appears more than once in such a set, the IS-IS Flexible Algorithm Include-All Admin Group Sub-TLV in the first occurrence in the lowest numbered LSP from a given IS MUST be used and any other occurrences MUST be ignored. 6.4. IS-IS Flexible Algorithm Definition Flags Sub-TLV The IS-IS Flexible Algorithm Definition Flags Sub-TLV (FADF Sub-TLV) is a Sub-TLV of the IS-IS FAD Sub-TLV. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +- -+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Psenak, et al. Expires 20 April 2023 [Page 14] Internet-Draft IGP Flexible Algorithm October 2022 Type: 4 Length: variable, number of octets of the Flags field Flags: 0 1 2 3 4 5 6 7... +-+-+-+-+-+-+-+-+... |M| | | ... +-+-+-+-+-+-+-+-+... M-flag: when set, the Flex-Algorithm specific prefix metric MUST be used for inter-area and external prefix calculation. This flag is not applicable to prefixes advertised as SRv6 locators. A new IANA "IGP Flexible Algorithm Definition Flags Registry" is defined for allocation of bits in the Flags field - see Section 18.2. Bits are defined/sent starting with Bit 0 defined above. Additional bit definitions that may be defined in the future SHOULD be assigned in ascending bit order so as to minimize the number of bits that will need to be transmitted. Undefined bits MUST be transmitted as 0. Bits that are not transmitted MUST be treated as if they are set to 0 on receipt. The IS-IS FADF Sub-TLV MUST NOT appear more than once in a single IS- IS FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub-TLV MUST be ignored by the receiver. The IS-IS FADF Sub-TLV MUST NOT appear more than once in the set of FAD sub-TLVs for a given Flex-Algorithm from a given IS. If it appears more than once in such a set, the IS-IS FADF Sub-TLV in the first occurrence in the lowest numbered LSP from a given IS MUST be used and any other occurrences MUST be ignored. If the IS-IS FADF Sub-TLV is not present inside the IS-IS FAD Sub- TLV, all the bits are assumed to be set to 0. If a node is configured to participate in a particular Flexible Algorithm, but the selected Flex-Algorithm definition includes a bit in the IS-IS FADF Sub-TLV that is not supported by the node, it MUST stop participating in such Flexible Algorithm. Psenak, et al. Expires 20 April 2023 [Page 15] Internet-Draft IGP Flexible Algorithm October 2022 New flag bits may be defined in the future. Implementations MUST check all advertised flag bits in the received IS-IS FADF Sub-TLV - not just the subset currently defined. M-flag MUST not be used when calculating prefix reachability for SRv6 Locator prefix. 6.5. IS-IS Flexible Algorithm Exclude SRLG Sub-TLV The Flexible Algorithm definition can specify Shared Risk Link Groups (SRLGs) that the operator wants to exclude during the Flex-Algorithm path computation. The IS-IS Flexible Algorithm Exclude SRLG Sub-TLV (FAESRLG) is used to advertise the exclude rule that is used during the Flex-Algorithm path calculation as specified in Section 13. The IS-IS FAESRLG Sub-TLV is a Sub-TLV of the IS-IS FAD Sub-TLV. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Risk Link Group Value | +- -+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 5 Length: variable, dependent on number of SRLG values. MUST be a multiple of 4 octets. Shared Risk Link Group Value: SRLG value as defined in [RFC5307]. The IS-IS FAESRLG Sub-TLV MUST NOT appear more than once in a single IS-IS FAD Sub-TLV. If it appears more than once, the IS-IS FAD Sub- TLV MUST be ignored by the receiver. Psenak, et al. Expires 20 April 2023 [Page 16] Internet-Draft IGP Flexible Algorithm October 2022 The IS-IS FAESRLG Sub-TLV MAY appear more than once in the set of FAD sub-TLVs for a given Flex-Algorithm from a given IS. This may be necessary in cases where the total number of SRLG values which are specified cause the FAD sub-TLV to exceed the maximum length of a single FAD sub-TLV. In such a case the receiver MUST use the union of all values across all IS-IS FAESRLG Sub-TLVs from such set. 7. Sub-TLVs of OSPF FAD TLV 7.1. OSPF Flexible Algorithm Exclude Admin Group Sub-TLV The Flexible Algorithm Exclude Admin Group Sub-TLV (FAEAG Sub-TLV) is a Sub-TLV of the OSPF FAD TLV. Its usage is described in Section 6.1. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Admin Group | +- -+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 1 Length: variable, dependent on the size of the Extended Admin Group. MUST be a multiple of 4 octets. Extended Administrative Group: Extended Administrative Group as defined in [RFC7308]. The OSPF FAEAG Sub-TLV MUST NOT appear more than once in an OSPF FAD TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored by the receiver. 7.2. OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV The OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV is a Sub- TLV of the OSPF FAD TLV. The usage of this Sub-TLVs is described in Section 6.2. It has the following format: Psenak, et al. Expires 20 April 2023 [Page 17] Internet-Draft IGP Flexible Algorithm October 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Admin Group | +- -+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 2 Length: variable, dependent on the size of the Extended Admin Group. MUST be a multiple of 4 octets. Extended Administrative Group: Extended Administrative Group as defined in [RFC7308]. The OSPF Flexible Algorithm Include-Any Admin Group Sub-TLV MUST NOT appear more than once in an OSPF FAD TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored by the receiver. 7.3. OSPF Flexible Algorithm Include-All Admin Group Sub-TLV The OSPF Flexible Algorithm Include-All Admin Group Sub-TLV is a Sub- TLV of the OSPF FAD TLV. The usage of this Sub-TLVs is described in Section 6.3. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Admin Group | +- -+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 3 Length: variable, dependent on the size of the Extended Admin Group. MUST be a multiple of 4 octets. Extended Administrative Group: Extended Administrative Group as defined in [RFC7308]. Psenak, et al. Expires 20 April 2023 [Page 18] Internet-Draft IGP Flexible Algorithm October 2022 The OSPF Flexible Algorithm Include-All Admin Group Sub-TLV MUST NOT appear more than once in an OSPF FAD TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored by the receiver. 7.4. OSPF Flexible Algorithm Definition Flags Sub-TLV The OSPF Flexible Algorithm Definition Flags Sub-TLV (FADF Sub-TLV) is a Sub-TLV of the OSPF FAD TLV. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +- -+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 4 Length: variable, dependent on the size of the Flags field. MUST be a multiple of 4 octets. Flags: 0 1 2 3 4 5 6 7... +-+-+-+-+-+-+-+-+... |M| | | ... +-+-+-+-+-+-+-+-+... M-flag: when set, the Flex-Algorithm specific prefix and ASBR metric MUST be used for inter-area and external prefix calculation. This flag is not applicable to prefixes advertised as SRv6 locators. A new IANA "IGP Flexible Algorithm Definition Flags Registry" is defined for allocation of bits in the Flags field - see Section 18.2. Bits are defined/sent starting with Bit 0 defined above. Additional bit definitions that may be defined in the future SHOULD be assigned in ascending bit order so as to minimize the number of bits that will need to be transmitted. Undefined bits MUST be transmitted as 0. Psenak, et al. Expires 20 April 2023 [Page 19] Internet-Draft IGP Flexible Algorithm October 2022 Bits that are not transmitted MUST be treated as if they are set to 0 on receipt. The OSPF FADF Sub-TLV MUST NOT appear more than once in an OSPF FAD TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored by the receiver. If the OSPF FADF Sub-TLV is not present inside the OSPF FAD TLV, all the bits are assumed to be set to 0. If a node is configured to participate in a particular Flexible Algorithm, but the selected Flex-Algorithm definition includes a bit in the OSPF FADF Sub-TLV that is not supported by the node, it MUST stop participating in such Flexible Algorithm. New flag bits may be defined in the future. Implementations MUST check all advertised flag bits in the received OSPF FADF Sub-TLV - not just the subset currently defined. M-flag MUST not be used when calculating prefix reachability for SRv6 Locator prefix. 7.5. OSPF Flexible Algorithm Exclude SRLG Sub-TLV The OSPF Flexible Algorithm Exclude SRLG Sub-TLV (FAESRLG Sub-TLV) is a Sub-TLV of the OSPF FAD TLV. Its usage is described in Section 6.5. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Risk Link Group Value | +- -+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 5 Length: variable, dependent on the number of SRLGs. MUST be a multiple of 4 octets. Shared Risk Link Group Value: SRLG value as defined in [RFC4203]. Psenak, et al. Expires 20 April 2023 [Page 20] Internet-Draft IGP Flexible Algorithm October 2022 The OSPF FAESRLG Sub-TLV MUST NOT appear more than once in an OSPF FAD TLV. If it appears more than once, the OSPF FAD TLV MUST be ignored by the receiver. 8. IS-IS Flexible Algorithm Prefix Metric Sub-TLV The IS-IS Flexible Algorithm Prefix Metric (FAPM) Sub-TLV supports the advertisement of a Flex-Algorithm specific prefix metric associated with a given prefix advertisement. The IS-IS FAPM Sub-TLV is a sub-TLV of TLVs 135, 235, 236, and 237 and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Flex-Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 6 Length: 5 octets Flex-Algorithm: Single octet value between 128 and 255 inclusive. Metric: 4 octets of metric information The IS-IS FAPM Sub-TLV MAY appear multiple times in its parent TLV. If it appears more than once with the same Flex-Algorithm value, the first instance MUST be used and any subsequent instances MUST be ignored. If a prefix is advertised with a Flex-Algorithm prefix metric larger than MAX_PATH_METRIC as defined in [RFC5305] this prefix MUST NOT be considered during the Flexible Algorithm computation. The usage of the Flex-Algorithm prefix metric is described in Section 13. Psenak, et al. Expires 20 April 2023 [Page 21] Internet-Draft IGP Flexible Algorithm October 2022 The IS-IS FAPM Sub-TLV MUST NOT be advertised as a sub-TLV of the IS- IS SRv6 Locator TLV [I-D.ietf-lsr-isis-srv6-extensions]. The IS-IS SRv6 Locator TLV includes the Algorithm and Metric fields which MUST be used instead. If the FAPM Sub-TLV is present as a sub-TLV of the IS-IS SRv6 Locator TLV in the received LSP, such FAPM Sub-TLV MUST be ignored. 9. OSPF Flexible Algorithm Prefix Metric Sub-TLV The OSPF Flexible Algorithm Prefix Metric (FAPM) Sub-TLV supports the advertisement of a Flex-Algorithm specific prefix metric associated with a given prefix advertisement. The OSPF Flex-Algorithm Prefix Metric (FAPM) Sub-TLV is a Sub-TLV of the: - OSPFv2 Extended Prefix TLV [RFC7684] - Following OSPFv3 TLVs as defined in [RFC8362]: Inter-Area Prefix TLV External Prefix TLV OSPF FAPM Sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Flex-Algorithm | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 3 for OSPFv2, 26 for OSPFv3 Length: 8 octets Flex-Algorithm: Single octet value between 128 and 255 inclusive. Flags: One octet value Psenak, et al. Expires 20 April 2023 [Page 22] Internet-Draft IGP Flexible Algorithm October 2022 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |E| | +-+-+-+-+-+-+-+-+ E bit : position 0: The type of external metric. If bit is set, the metric specified is a Type 2 external metric. This bit is applicable only to OSPF External and NSSA external prefixes. This is semantically the same as the E bit in section A.4.5 of [RFC2328] and section A.4.7 of [RFC5340] for OSPFv2 and OSPFv3 respectively. Bits 1 through 7: MUST be cleared by originator and ignored by receiver. Reserved: MUST be set to 0, ignored at reception. Metric: 4 octets of metric information The OSPF FAPM Sub-TLV MAY appear multiple times in its parent TLV. If it appears more than once with the same Flex-Algorithm value, the first instance MUST be used and any subsequent instances MUST be ignored. The usage of the Flex-Algorithm prefix metric is described in Section 13. 10. OSPF Flexible Algorithm ASBR Reachability Advertisement An OSPF ABR advertises the reachability of ASBRs in its attached areas to enable routers within those areas to perform route calculations for external prefixes advertised by the ASBRs. OSPF extensions for advertisement of Flex-Algorithm specific reachability and metric for ASBRs is similarly required for Flex-Algorithm external prefix computations as described further in Section 13.1. 10.1. OSPFv2 Extended Inter-Area ASBR LSA The OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) LSA is an OSPF Opaque LSA [RFC5250] that is used to advertise additional attributes related to the reachability of the OSPFv2 ASBR that is external to the area yet internal to the OSPF domain. Semantically, the OSPFv2 EIA-ASBR LSA is equivalent to the fixed format Type 4 Summary LSA [RFC2328]. Unlike the Type 4 Summary LSA, the LSID of the EIA-ASBR LSA does not carry the ASBR Router-ID - the ASBR Router-ID is carried in the body of the LSA. The OSPFv2 EIA-ASBR LSA is advertised by an OSPFv2 ABR and its flooding is defined to be area-scoped only. Psenak, et al. Expires 20 April 2023 [Page 23] Internet-Draft IGP Flexible Algorithm October 2022 An OSPFv2 ABR generates the EIA-ASBR LSA for an ASBR when it is advertising the Type-4 Summary LSA for it and has the need for advertising additional attributes for that ASBR beyond what is conveyed in the fixed format Type-4 Summary LSA. An OSPFv2 ABR MUST NOT advertise the EIA-ASBR LSA for an ASBR for which it is not advertising the Type 4 Summary LSA. This ensures that the ABR does not generate the EIA-ASBR LSA for an ASBR to which it does not have reachability in the base OSPFv2 topology calculation. The OSPFv2 ABR SHOULD NOT advertise the EIA-ASBR LSA for an ASBR when it does not have additional attributes to advertise for that ASBR. The OSPFv2 EIA-ASBR LSA has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | LS Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- TLVs -+ | ... | LS age and Options fields are as defined in Section A.4.1. of [RFC2328]. The LS Type MUST be 10, indicating that the Opaque LSA flooding scope is area-local [RFC5250]. The Opaque Type used by the OSPFv2 EIA-ASBR LSA is 11. The Opaque Type is used to differentiate the various types of OSPFv2 Opaque LSAs and is described in Section 3 of [RFC5250]. The Opaque ID field is an arbitrary value used to maintain multiple OSPFv2 EIA-ASBR LSAs. For OSPFv2 EIA-ASBR LSAs, the Opaque ID has no semantic significance other than to differentiate OSPFv2 EIA-ASBR LSAs originated by the same OSPFv2 ABR. If multiple OSPFv2 EIA-ASBR LSAs specify the same ASBR, the attributes from the Opaque LSA with the lowest Opaque ID SHOULD be used. Psenak, et al. Expires 20 April 2023 [Page 24] Internet-Draft IGP Flexible Algorithm October 2022 Advertising Router, LS sequence number, and LS checksum fields are as defined in Section A.4.1. of [RFC2328]. The Length field is as defined in Section A.4.1. of [RFC5250]. It represents the total length (in octets) of the Opaque LSA, including the LSA header and all TLVs (including padding). The format of the TLVs within the body of the OSPFv2 EIA-ASBR LSA is the same as the format used by the Traffic Engineering Extensions to OSPFv2 [RFC3630]. The variable TLV section consists of one or more nested TLV tuples. Nested TLVs are also referred to as sub- TLVs. The TLV Length field defines the length of the value portion in octets (thus, a TLV with no value portion would have a length of 0). The TLV is padded to 4-octet alignment; padding is not included in the Length field (so a 3-octet value would have a length of 3, but the total size of the TLV would be 8 octets). Nested TLVs are also 32-bit aligned. For example, a 1-octet value would have the Length field set to 1, and 3 octets of padding would be added to the end of the value portion of the TLV. The padding is composed of zeros. 10.1.1. OSPFv2 Extended Inter-Area ASBR TLV The OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) TLV is a top-level TLV of the OSPFv2 EIA-ASBR LSA and is used to advertise additional attributes associated with the reachability of an ASBR. The OSPFv2 EIA-ASBR TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASBR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 1 Length: variable number of octets ASBR Router ID: four octets carrying the OSPF Router ID of the ASBR whose information is being carried. Psenak, et al. Expires 20 April 2023 [Page 25] Internet-Draft IGP Flexible Algorithm October 2022 Sub-TLVs : variable Only a single OSPFv2 EIA-ASBR TLV MUST be advertised in each OSPFv2 EIA-ASBR LSA and the receiver MUST ignore all instances of this TLV other than the first one in an LSA. OSPFv2 EIA-ASBR TLV MUST be present inside an OSPFv2 EIA-ASBR LSA and MUST include at least a single sub-TLV, otherwise the OSPFv2 EIA-ASBR LSA MUST be ignored by the receiver. 10.2. OSPF Flexible Algorithm ASBR Metric Sub-TLV The OSPF Flexible Algorithm ASBR Metric (FAAM) Sub-TLV supports the advertisement of a Flex-Algorithm specific metric associated with a given ASBR reachability advertisement by an ABR. The OSPF Flex-Algorithm ASBR Metric (FAAM) Sub-TLV is a Sub-TLV of the: - OSPFv2 Extended Inter-Area ASBR TLV as defined in Section 10.1.1 - OSPFv3 Inter-Area-Router TLV defined in [RFC8362] OSPF FAAM Sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Flex-Algorithm | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 1 for OSPFv2, 33 for OSPFv3 Length: 8 octets Flex-Algorithm: Single octet value between 128 and 255 inclusive. Reserved: Three octets. MUST be set to 0, ignored at reception. Metric: 4 octets of metric information Psenak, et al. Expires 20 April 2023 [Page 26] Internet-Draft IGP Flexible Algorithm October 2022 The OSPF FAAM Sub-TLV MAY appear multiple times in its parent TLV. If it appears more than once with the same Flex-Algorithm value, the first instance MUST be used and any subsequent instances MUST be ignored. The advertisement of the ASBR reachability using the OSPF FAAM Sub- TLV inside the OSPFv2 EIA-ASBR LSA follows Section 12.4.3 of [RFC2328] and inside the OSPFv3 E-Inter-Area-Router LSA follows Section 4.8.5 of [RFC5340]. The reachability of the ASBR is evaluated in the context of the specific Flex-Algorithm. The FAAM computed by the ABR will be equal to the metric to reach the ASBR for a given Flex-Algorithm in a source area or the cumulative metric via other ABR(s) when the ASBR is in a remote area. This is similar in nature to how the metric is set when the ASBR reachability metric is computed in the default algorithm for the metric in the OSPFv2 Type 4 ASBR Summary LSA and the OSPFv3 Inter-Area-Router LSA. An OSPF ABR MUST NOT include the OSPF FAAM Sub-TLV with a specific Flex-Algorithm in its reachability advertisement for an ASBR between areas unless that ASBR is reachable for it in the context of that specific Flex-Algorithm. An OSPF ABR MUST include the OSPF FAAM Sub-TLVs as part of the ASBR reachability advertisement between areas for any Flex-Algorithm for which the winning FAD includes the M-flag and the ASBR is reachable in the context of that specific Flex-Algorithm. OSPF routers MUST use the OSPF FAAM Sub-TLV to calculate the reachability of the ASBRs if the winning FAD for the specific Flex- Algorithm includes the M-flag. OSPF routers MUST NOT use the OSPF FAAM Sub-TLV to calculate the reachability of the ASBRs for the specific Flex-Algorithm if the winning FAD for such Flex-Algorithm does not include the M-flag. Instead, the OSPFv2 Type 4 Summary LSAs or the OSPFv3 Inter-Area-Router-LSAs MUST be used instead as specified in section 16.2 of [RFC2328] and section 4.8.5 of [RFC5340] for OSPFv2 and OSPFv3 respectively. The processing of a new or changed OSPF FAAM Sub-TLV triggers the processing of External routes similar to what is described in section 16.5 of the [RFC2328] for OSPFv2 and section 4.8.5 of [RFC5340] for OSPFv3 for the specific Flex-Algorithm. The External and NSSA External route calculation should be limited to Flex-Algorithm(s) for which the winning FAD(s) includes the M-flag. Psenak, et al. Expires 20 April 2023 [Page 27] Internet-Draft IGP Flexible Algorithm October 2022 Processing of the OSPF FAAM Sub-TLV does not require the existence of the equivalent OSPFv2 Type 4 Summary LSA or the OSPFv3 Inter-Area- Router-LSA that is advertised by the same ABR inside the area. The presence of the base LSA is not mandatory for the usage of the extended LSA with the OSPF FAAM Sub-TLV. 11. Advertisement of Node Participation in a Flex-Algorithm When a router is configured to participate in a particular Flex- Algorithm and is advertising such participation, it is participating in that Flex-Algorithm. Paths for various data-planes MAY be computed for a specific Flex- Algorithm. Each data-plane uses its own specific forwarding over such Flex-Algorithm paths. To guarantee the presence of the data- plane specific forwarding, associated with a particular Flex- Algorithm, a router MUST advertise its participation for a particular Flex-Algorithm for each data-plane. Some data-planes may share a common participation advertisement (e.g. SR-MPLS and SRv6). Advertisement of the participation for any particular Flex-Algorithm in any data-plane is subject to the condition specified in Section 5.3. 11.1. Advertisement of Node Participation for Segment Routing [RFC8667], [RFC8665], and [RFC8666] (IGP Segment Routing extensions) describe how the SR-Algorithm is used to compute the IGP best path. Routers advertise support for the SR-Algorithm as a node capability as described in the above-mentioned IGP Segment Routing extensions. To advertise participation for a particular Flex-Algorithm for Segment Routing, including both SR-MPLS and SRv6, the Flex-Algorithm value MUST be advertised in the SR-Algorithm TLV (OSPF) or sub-TLV (IS-IS). Segment Routing Flex-Algorithm participation advertisement is topology independent. When a router advertises participation in an SR-Algorithm, the participation applies to all topologies in which the advertising node participates. 11.2. Advertisement of Node Participation for Other Data-planes This section describes considerations related to how other data- planes can advertise their participation in a specific Flex- Algorithm. Psenak, et al. Expires 20 April 2023 [Page 28] Internet-Draft IGP Flexible Algorithm October 2022 Data-plane specific Flex-Algorithm participation advertisements MAY be topology specific or MAY be topology independent, depending on the data-plane itself. Data-plane specific advertisement for Flex-Algorithm participation MUST be defined for each data-plane and is outside the scope of this document. 12. Advertisement of Link Attributes for Flex-Algorithm Various link attributes may be used during the Flex-Algorithm path calculation. For example, include or exclude rules based on link affinities can be part of the Flex-Algorithm definition as defined in Section 6 and Section 7. Application-specific link attributes, as specified in [RFC8919] or [RFC8920], that are to be used during Flex-Algorithm calculation MUST use the Application-Specific Link Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920], unless, in the case of IS-IS, the L-Flag is set in the ASLA advertisement. When the L-Flag is set, then legacy advertisements MUST be used, subject to the procedures and constraints defined in [[RFC8919] Section 4.2 and Section 6. The mandatory use of ASLA advertisements applies to link attributes specifically mentioned in this document (Min Unidirectional Link Delay, TE Default Metric, Administrative Group, Extended Administrative Group and Shared Risk Link Group) and any other link attributes that may be used in support of Flex-Algorithm in the future. A new Application Identifier Bit is defined to indicate that the ASLA advertisement is associated with the Flex-Algorithm application. This bit is set in the Standard Application Bit Mask (SABM) defined in [RFC8919] or [RFC8920]: Bit-3: Flexible Algorithm (X-bit) ASLA Admin Group Advertisements to be used by the Flexible Algorithm application MAY use either the Administrative Group or Extended Administrative Group encodings. A receiver supporting this specification MUST accept both ASLA Administrative Group and Extended Administrative Group TLVs as defined in [RFC8919] or [RFC8920]. In the case of IS-IS, if the L-Flag is set in ASLA advertisement, as defined in [RFC8919] Section 4.2, then the receiver MUST be able to accept both Administrative Group TLV as defined in [RFC5305] and Extended Administrative Group TLV as defined in [RFC7308]. Psenak, et al. Expires 20 April 2023 [Page 29] Internet-Draft IGP Flexible Algorithm October 2022 13. Calculation of Flexible Algorithm Paths A router MUST be configured to participate in a given Flex-Algorithm K and MUST select the FAD based on the rules defined in Section 5.3 before it can compute any path for that Flex-Algorithm. No specific two-way connectivity check is performed during the Flex- Algorithm path computation. The result of the existing, Flex- Algorithm agnostic, two-way connectivity check is used during the Flex-Algorithm path computation. As described in Section 11, participation for any particular Flex- Algorithm MUST be advertised on a per data-plane basis. Calculation of the paths for any particular Flex-Algorithm is data-plane specific. Multiple data-planes MAY use the same Flex-Algorithm value at the same time, and as such, share the FAD for it. Traffic for each data- plane will be forwarded based on the data-plane specific forwarding entries. Flex-Algorithm definition is data-plane independent and is used by all Flex-Algorithm data-planes. The way various data-planes handle nodes that do not participate in Flexible Algorithm is data-plane specific. If the data-plane only wants to consider participating nodes during the Flex-Algorithm calculation, then when computing paths for a given Flex-Algorithm, all nodes that do not advertise participation for that Flex-Algorithm in their data-plane specific advertisements MUST be pruned from the topology. Segment Routing, including both SR-MPLS and SRv6, are data-planes that MUST use such pruning when computing Flex-Algorithm paths. When computing the path for a given Flex-Algorithm, the metric-type that is part of the Flex-Algorithm definition (Section 5) MUST be used. When computing the path for a given Flex-Algorithm, the calculation- type that is part of the Flex-Algorithm definition (Section 5) MUST be used. Various link include or exclude rules can be part of the Flex- Algorithm definition. To refer to a particular bit within an Admin Group or Extended Admin Group we use the term 'color'. Rules, in the order as specified below, MUST be used to prune links from the topology during the Flex-Algorithm computation. Psenak, et al. Expires 20 April 2023 [Page 30] Internet-Draft IGP Flexible Algorithm October 2022 For all links in the topology: 1. Check if any exclude AG rule is part of the Flex-Algorithm definition. If such exclude rule exists, check if any color that is part of the exclude rule is also set on the link. If such a color is set, the link MUST be pruned from the computation. 2. Check if any exclude SRLG rule is part of the Flex-Algorithm definition. If such exclude rule exists, check if the link is part of any SRLG that is also part of the SRLG exclude rule. If the link is part of such SRLG, the link MUST be pruned from the computation. 3. Check if any include-any AG rule is part of the Flex-Algorithm definition. If such include-any rule exists, check if any color that is part of the include-any rule is also set on the link. If no such color is set, the link MUST be pruned from the computation. 4. Check if any include-all AG rule is part of the Flex-Algorithm definition. If such include-all rule exists, check if all colors that are part of the include-all rule are also set on the link. If all such colors are not set on the link, the link MUST be pruned from the computation. 5. If the Flex-Algorithm definition uses other than IGP metric (Section 5), and such metric is not advertised for the particular link in a topology for which the computation is done, such link MUST be pruned from the computation. A metric of value 0 MUST NOT be assumed in such a case. 13.1. Multi-area and Multi-domain Considerations Any IGP Shortest Path Tree calculation is limited to a single area. This applies to Flex-Algorithm calculations as well. Given that the computing router does not have visibility of the topology of the next areas or domain, the Flex-Algorithm specific path to an inter-area or inter-domain prefix will be computed for the local area only. The egress L1/L2 router (ABR in OSPF), or ASBR for inter-domain case, will be selected based on the best path for the given Flex-Algorithm in the local area and such egress ABR or ASBR router will be responsible to compute the best Flex-Algorithm specific path over the next area or domain. This may produce an end-to-end path, which is suboptimal based on Flex-Algorithm constraints. In cases where the ABR or ASBR has no reachability to a prefix for a given Flex- Algorithm in the next area or domain, the traffic could be dropped by the ABR/ASBR. Psenak, et al. Expires 20 April 2023 [Page 31] Internet-Draft IGP Flexible Algorithm October 2022 To allow the optimal end-to-end path for an inter-area or inter- domain prefix for any Flex-Algorithm to be computed, the FAPM has been defined in Section 8 and Section 9. For external route calculation for prefixes originated by ASBRs in remote areas in OSPF, the FAAM has been defined in Section 10.2 for the ABR to indicate its ASBR reachability along with the metric for the specific Flex- Algorithm. If the FAD selected based on the rules defined in Section 5.3 includes the M-flag, an ABR or ASBR MUST include the FAPM (Section 8, Section 9) when advertising the prefix, that is reachable in a given Flex-Algorithm, between areas or domains. Such metric will be equal to the metric to reach the prefix for that Flex-Algorithm in its source area or domain. This is similar in nature to how the metric is set when prefixes are advertised between areas or domains for the default algorithm. When a prefix is unreachable in its source area or domain in a specific Flex-Algorithm, then an ABR or ASBR MUST NOT include the FAPM for that Flex-Algorithm when advertising the prefix between areas or domains. If the FAD selected based on the rules defined in Section 5.3 includes the M-flag, the FAPM MUST be used during the calculation of prefix reachability for the inter-area and external prefixes. If the FAPM for the Flex-Algorithm is not advertised with the inter-area or external prefix reachability advertisement, the prefix MUST be considered as unreachable for that Flex-Algorithm. Similarly, in the case of OSPF, for ASBRs in remote areas, if the FAAM is not advertised by the local ABR(s), the ASBR MUST be considered as unreachable for that Flex-Algorithm and the external prefix advertisements from such an ASBR are not considered for that Flex- Algorithm. Flex-Algorithm prefix metrics and the OSPF Flex-Algorithm ASBR metrics MUST NOT be used during the Flex-Algorithm computation unless the FAD selected based on the rules defined in Section 5.3 includes the M-Flag, as described in (Section 6.4 or Section 7.4). In the case of OSPF, when calculating external routes in a Flex- Algorithm, if the winning FAD includes the M-Flag, and where the advertising ASBR is in a remote area, the metric will be the sum of the following: * the FAPM for that Flex-Algorithm advertised with the external route by the ASBR * the metric to reach the ASBR for that Flex-Algorithm from the local ABR i.e., the FAAM for that Flex-Algorithm advertised by the ABR in the local area for that ASBR Psenak, et al. Expires 20 April 2023 [Page 32] Internet-Draft IGP Flexible Algorithm October 2022 * the Flex-Algorithm specific metric to reach the local ABR This is similar in nature to how the metric is calculated for routes learned from remote ASBRs in the default algorithm using the OSPFv2 Type 4 ASBR Summary LSA and the OSPFv3 Inter-Area-Router LSA. If the FAD selected based on the rules defined in Section 5.3 does not include the M-flag, then the IGP metrics associated with the prefix reachability advertisements used by the base IS-IS and OSPF protocol MUST be used for the Flex-Algorithm route computation. Similarly, in the case of external route calculations in OSPF, the ASBR reachability is determined based on the base OSPFv2 Type 4 Summary LSA and the OSFPv3 Inter-Area-Router LSA. It is NOT RECOMMENDED to use the Flex-Algorithm for inter-area or inter-domain prefix reachability without the M-flag set. The reason is that without the explicit Flex-Algorithm Prefix Metric advertisement (and the Flex-Algorithm ASBR metric advertisement in the case of OSPF external route calculation), it is not possible to conclude whether the ABR or ASBR has reachability to the inter-area or inter-domain prefix for a given Flex-Algorithm in the next area or domain. Sending the Flex-Algorithm traffic for such a prefix towards the ABR or ASBR may result in traffic looping or persistent traffic drop. During the route computation, it is possible for the Flex-Algorithm specific metric to exceed the maximum value that can be stored in an unsigned 32-bit variable. In such scenarios, the value MUST be considered to be of value 0xFFFFFFFF during the computation and advertised as such. The FAPM MUST NOT be advertised with IS-IS L1 or L2 intra-area, OSPFv2 intra-area, or OSPFv3 intra-area routes. If the FAPM is advertised for these route-types, it MUST be ignored during the prefix reachability calculation. The M-flag in the FAD is not applicable to prefixes advertised as SRv6 locators. The IS-IS SRv6 Locator TLV [I-D.ietf-lsr-isis-srv6-extensions] includes the Algorithm and Metric fields. When the SRv6 Locator is advertised between areas or domains, the metric field in the Locator TLV of IS-IS MUST be used irrespective of the M-flag in the FAD advertisement. OSPF external and NSSA external prefix advertisements MAY include a non-zero forwarding address in the prefix advertisements in the base protocol. In such a scenario, the Flex-Algorithm specific reachability of the external prefix is determined by Flex-Algorithm specific reachability of the forwarding address. Psenak, et al. Expires 20 April 2023 [Page 33] Internet-Draft IGP Flexible Algorithm October 2022 In OSPF, the procedures for translation of NSSA external prefix advertisements into external prefix advertisements performed by an NSSA ABR [RFC3101] remain unchanged for Flex-Algorithm. An NSSA translator MUST include the OSPF FAPM Sub-TLVs for all Flex- Algorithms that are in the original NSSA external prefix advertisement from the NSSA ASBR in the translated external prefix advertisement generated by it regardless of its participation in those Flex-Algorithms or its having reachability to the NSSA ASBR in those Flex-Algorithms. An area could become partitioned from the perspective of the Flex- Algorithm due to the constraints and/or metric being used for it, while maintaining the continuity in the base algorithm. When that happens, some destinations inside that area could become unreachable in that Flex-Algorithm. These destinations will not be able to use an inter-area path. This is the consequence of the fact that the inter-area prefix reachability advertisement would not be available for these intra-area destinations within the area. It is RECOMMENDED to minimize the risk of such partitioning by providing enough redundancy inside the area for each Flex-Algorithm being used. 14. Flex-Algorithm and Forwarding Plane This section describes how Flex-Algorithm paths are used in forwarding. 14.1. Segment Routing MPLS Forwarding for Flex-Algorithm This section describes how Flex-Algorithm paths are used with SR MPLS forwarding. Prefix SID advertisements include an SR-Algorithm value and, as such, are associated with the specified SR-Algorithm. Prefix-SIDs are also associated with a specific topology which is inherited from the associated prefix reachability advertisement. When the algorithm value advertised is a Flex-Algorithm value, the Prefix SID is associated with paths calculated using that Flex-Algorithm in the associated topology. A Flex-Algorithm path MUST be installed in the MPLS forwarding plane using the MPLS label that corresponds to the Prefix-SID that was advertised for that Flex-algorithm. If the Prefix SID for a given Flex-algorithm is not known, the Flex-Algorithm specific path cannot be installed in the MPLS forwarding plane. Traffic that is supposed to be routed via Flex-Algorithm specific paths MUST be dropped when there are no such paths available. Psenak, et al. Expires 20 April 2023 [Page 34] Internet-Draft IGP Flexible Algorithm October 2022 Loop Free Alternate (LFA) paths ([RFC6571] or its variants) for a given Flex-Algorithm MUST be computed using the same constraints as the calculation of the primary paths for that Flex-Algorithm. LFA paths MUST only use Prefix-SIDs advertised specifically for the given algorithm. LFA paths MUST NOT use an Adjacency-SID that belongs to a link that has been pruned from the Flex-Algorithm computation. If LFA protection is being used to protect a given Flex-Algorithm paths, all routers in the area participating in the given Flex- Algorithm SHOULD advertise at least one Flex-Algorithm specific Node- SID. These Node-SIDs are used to steer traffic over the LFA computed backup path. 14.2. SRv6 Forwarding for Flex-Algorithm This section describes how Flex-Algorithm paths are used with SRv6 forwarding. In SRv6 a node is provisioned with a (topology, algorithm) specific locator for each of the topology/algorithm pairs supported by that node. Each locator is an aggregate prefix for all SIDs provisioned on that node which have the matching topology/algorithm. The SRv6 locator advertisement in IS-IS [I-D.ietf-lsr-isis-srv6-extensions] includes the MTID value that associates the locator with a specific topology. SRv6 locator advertisements also includes an Algorithm value that explicitly associates the locator with a specific algorithm. When the algorithm value advertised with a locator represents a Flex-Algorithm, the paths to the locator prefix MUST be calculated using the specified Flex-Algorithm in the associated topology. Forwarding entries for the locator prefixes advertised in IS-IS MUST be installed in the forwarding plane of the receiving SRv6 capable routers when the associated topology/algorithm is participating in them. Forwarding entries for locators associated with Flex- Algorithms in which the node is not participating MUST NOT be installed in the forwarding plane. When the locator is associated with a Flex-Algorithm, LFA paths to the locator prefix MUST be calculated using such Flex-Algorithm in the associated topology, to guarantee that they follow the same constraints as the calculation of the primary paths. LFA paths MUST only use SRv6 SIDs advertised specifically for the given Flex- Algorithm. Psenak, et al. Expires 20 April 2023 [Page 35] Internet-Draft IGP Flexible Algorithm October 2022 If LFA protection is being used to protect locators associated with a given Flex-Algorithm, all routers in the area participating in the given Flex-Algorithm SHOULD advertise at least one Flex-Algorithm specific locator and END SID per node and one END.X SID for every link that has not been pruned from such Flex-Algorithm computation. These locators and SIDs are used to steer traffic over the LFA- computed backup path. 14.3. Other Data-planes' Forwarding for Flex-Algorithm Any data-plane that wants to use Flex-Algorithm specific forwarding needs to install some form of Flex-Algorithm specific forwarding entries. Data-plane specific forwarding for Flex-Algorithm MUST be defined for each data-plane and is outside the scope of this document. 15. Operational Considerations 15.1. Inter-area Considerations The scope of the Flex-Algorithm computation is an area, so is the scope of the FAD. In IS-IS, the Router Capability TLV in which the FAD Sub-TLV is advertised MUST have the S-bit clear, which prevents it from being flooded outside the level in which it was originated. Even though in OSPF the FAD Sub-TLV can be flooded in an RI LSA that has AS flooding scope, the FAD selection is performed for each individual area in which it is being used. There is no requirement for the FAD for a particular Flex-Algorithm to be identical in all areas in the network. For example, traffic for the same Flex-Algorithm may be optimized for minimal delay (e.g., using delay metric) in one area or level, while being optimized for available bandwidth (e.g., using IGP metric) in another area or level. As described in Section 5.1, IS-IS allows the re-generation of the winning FAD from level 2, without any modification to it, into a level 1 area. This allows the operator to configure the FAD in one or multiple routers in the level 2, without the need to repeat the same task in each level 1 area, if the intent is to have the same FAD for the particular Flex-Algorithm across all levels. This can similarly be achieved in OSPF by using the AS flooding scope of the RI LSA in which the FAD Sub-TLV for the particular Flex-Algoritm is advertised. Psenak, et al. Expires 20 April 2023 [Page 36] Internet-Draft IGP Flexible Algorithm October 2022 Re-generation of the FAD from a level 1 area to the level 2 area is not supported in IS-IS, so if the intent is to regenerate the FAD between IS-IS levels, the FAD MUST be defined on router(s) that are in level 2. In OSPF, the FAD definition can be done in any area and be propagated to all routers in the OSPF routing domain by using the AS flooding scope of the RI LSA. 15.2. Usage of SRLG Exclude Rule with Flex-Algorithm There are two different ways in which SRLG information can be used with Flex-Algorithm: In a context of a single Flex-Algorithm, it can be used for computation of backup paths, as described in [I-D.ietf-rtgwg-segment-routing-ti-lfa]. This usage does not require association of any specific SRLG constraint with the given Flex-Algorithm definition. In the context of multiple Flex-Algorithms, it can be used for creating disjoint sets of paths by pruning the links belonging to a specific SRLG from the topology on which a specific Flex- Algorithm computes its paths. This usage: Facilitates the usage of already deployed SRLG configurations for setup of disjoint paths between two or more Flex- Algorithms. Requires explicit association of a given Flex-Algorithm with a specific set of SRLG constraints as defined in Section 6.5 and Section 7.5. The two usages mentioned above are orthogonal. 15.3. Max-metric consideration Both IS-IS and OSPF have a mechanism to set the IGP metric on a link to a value that would make the link either non-reachable or to serve as the link of last resort. Similar functionality would be needed for the Min Unidirectional Link Delay and TE metric, as these can be used to compute Flex-Algorithm paths. The link can be made un-reachable for all Flex-Algorithms that use Min Unidirectional Link Delay as metric, as described in Section 5.1, by removing the Flex-Algorithm ASLA Min Unidirectional Link Delay advertisement for the link. The link can be made the link of last resort by setting the delay value in the Flex-Algorithm ASLA delay advertisement for the link to the value of 16,777,215 (2^24 - 1). Psenak, et al. Expires 20 April 2023 [Page 37] Internet-Draft IGP Flexible Algorithm October 2022 The link can be made un-reachable for all Flex-Algorithms that use TE metric, as described in Section 5.1, by removing the Flex-Algorithm ASLA TE metric advertisement for the link. The link can be made the link of last resort by setting the TE metric value in the Flex- Algorithm ASLA delay advertisement for the link to the value of (2^24 - 1) in IS-IS and (2^32 - 1) in OSPF. 15.4. FAD Definition and Changes When configuring a node to participate in a specific Flex-Algorithm, the components of the FAD (calculation-type, metric-type, constraints) should be considered carefully. The configuration of participation in a particular Flex-Algorithm doesn't guarantee that the node will actively participate in it, because it may not support the calculation-type, metric type or some constraint advertised by the winning FAD (see Section 5.3). Changes in the FAD configuration should also be considered in light of the capabilities of the participating routers in the scope of the FAD advertisement. As Section 5.3 notes, a change in the Flex-Algorithm definition may require network-wide SPF re-computation and network re-convergence. This potential for disruption should be taken into consideration when planning and making changes to the FAD. 15.5. Number of Flex-Algorithms The maximum number of Flex-Algorithms is determined by the algorithm range that is (128-255), as specified in Section 4. Although possible, it is not expected that all of them will be used simultaneously. Typically, only a limited subset of Flex-Algorithms is expected to be deployed in the network. 16. Backward Compatibility This extension brings no new backward compatibility issues. IS-IS, OSPFv2 and OSPFv3 all have well-defined handling of unrecognized TLVs and sub-TLVs that allows the introduction of new extensions, similar to those defined here, without introducing any interoperability issues. 17. Security Considerations This draft adds two new ways to disrupt IGP networks: An attacker can hijack a particular Flex-Algorithm by advertising a FAD with a priority of 255 (or any priority higher than that of the legitimate nodes). Psenak, et al. Expires 20 April 2023 [Page 38] Internet-Draft IGP Flexible Algorithm October 2022 An attacker could make it look like a router supports a particular Flex-Algorithm when it actually doesn't, or vice versa. Both of these attacks can be addressed by the existing security extensions as described in [RFC5304] and [RFC5310] for IS-IS, in [RFC2328] and [RFC7474] for OSPFv2, and in [RFC5340] and [RFC4552] for OSPFv3. If the node that is authenticated is taken over by an attacker, such rogue node can advertise the FAD for any Flex-Algorithm. Doing so may result in traffic for such Flex-Algorithm to be misrouted, or not being delivered at all, for example, by using an unsupported metric- type, calculation-type, or constraint. Such attack is not preventable through authentication, and it is not different from advertising any other incorrect information through IS-IS or OSPF. 18. IANA Considerations 18.1. IGP IANA Considerations 18.1.1. IGP Algorithm Types Registry This document makes the following registrations in the "IGP Algorithm Types" registry: Type: 128-255. Description: Flexible Algorithms. Reference: This document (Section 4). 18.1.2. IGP Metric-Type Registry IANA is requested to set up a registry called "IGP Metric-Type Registry" under the "Interior Gateway Protocol (IGP) Parameters" IANA grouping. The registration policy for this registry is "Standards Action" ([RFC8126] and [RFC7120]). Values in this registry come from the range 0-255. This document registers following values in the "IGP Metric-Type Registry": Type: 0 Description: IGP metric Reference: This document (Section 5.1) Psenak, et al. Expires 20 April 2023 [Page 39] Internet-Draft IGP Flexible Algorithm October 2022 Type: 1 Description: Min Unidirectional Link Delay as defined in [RFC8570], section 4.2, and [RFC7471], section 4.2. Reference: This document (Section 5.1) Type: 2 Description: Traffic Engineering Default Metric as defined in [RFC5305], section 3.7, and Traffic engineering metric as defined in [RFC3630], section 2.5.5 Reference: This document (Section 5.1) 18.2. Flexible Algorithm Definition Flags Registry IANA is requested to set up a registry called "IGP Flexible Algorithm Definition Flags Registry" under the "Interior Gateway Protocol (IGP) Parameters" IANA grouping. The registration policy for this registry is "Standards Action" ([RFC8126] and [RFC7120]). New registrations should be assigned in ascending bit order (see Section 6.4). This document defines the following single bit in Flexible Algorithm Definition Flags registry: Bit # Name ----- ------------------------------ 0 Prefix Metric Flag (M-flag) Reference: This document (Section 6.4, Section 7.4). 18.3. IS-IS IANA Considerations 18.3.1. IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV This document makes the following registrations in the "IS-IS Sub- TLVs for IS-IS Router CAPABILITY TLV" registry. Type: 26. Description: Flexible Algorithm Definition (FAD) Reference: This document (Section 5.1). Psenak, et al. Expires 20 April 2023 [Page 40] Internet-Draft IGP Flexible Algorithm October 2022 18.3.2. IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability This document makes the following registrations in the "IS-IS Sub- TLVs for TLVs Advertising Prefix Reachability" registry. Type: 6 Description: Flexible Algorithm Prefix Metric (FAPM). Reference: This document (Section 8). 18.3.3. Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV This document creates the following Sub-Sub-TLV Registry, under the IS-IS TLV Codepoints grouping. Registry: Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV Registration Procedure: Expert review. (Note that the IS-IS TLV Codepoints grouping includes Expert Review guidance that applies to all registries thereunder.) Reference: This document (Section 5.1) This document defines the following Sub-Sub-TLVs in the "Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV" registry: Type: 0 Description: Reserved Reference: This document. Type: 1 Description: Flexible Algorithm Exclude Admin Group Reference: This document (Section 6.1). Type: 2 Description: Flexible Algorithm Include-Any Admin Group Reference: This document (Section 6.2). Type: 3 Description: Flexible Algorithm Include-All Admin Group Psenak, et al. Expires 20 April 2023 [Page 41] Internet-Draft IGP Flexible Algorithm October 2022 Reference: This document (Section 6.3). Type: 4 Description: Flexible Algorithm Definition Flags Reference: This document (Section 6.4). Type: 5 Description: Flexible Algorithm Exclude SRLG Reference: This document (Section 6.5). Type: 6-255 Description: Unassigned Reference: This document. 18.4. OSPF IANA Considerations 18.4.1. OSPF Router Information (RI) TLVs Registry This specification makes the following registration in the OSPF Router Information (RI) TLVs Registry. Type: 16 Description: Flexible Algorithm Definition (FAD) TLV. Reference: This document (Section 5.2). 18.4.2. OSPFv2 Extended Prefix TLV Sub-TLVs This document makes the following registrations in the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry. Type: 3 Description: Flexible Algorithm Prefix Metric (FAPM). Reference: This document (Section 9). 18.4.3. OSPFv3 Extended-LSA Sub-TLVs This document makes the following registrations in the "OSPFv3 Extended-LSA Sub-TLVs" registry. Psenak, et al. Expires 20 April 2023 [Page 42] Internet-Draft IGP Flexible Algorithm October 2022 Type: 26 Description: Flexible Algorithm Prefix Metric (FAPM). Reference: This document (Section 9). Type: 33 Description: OSPF Flexible Algorithm ASBR Metric Reference: This document (Section 10.2). For both of these sub-TLVs the column L2BN in the registry is set to "X" - meaning "sub-TLV is not a Router Link sub-TLV; it MUST NOT appear in L2 Bundle Member sub-TLV". 18.4.4. OSPF Flex-Algorithm Prefix Metric Bits This specification requests creation of the "OSPF Flex-Algorithm Prefix Metric Bits" registry under the "Open Shortest Path First (OSPF) Parameters" with the following initial values: Bit Number: 0 Description: E bit - External Type Reference: this document (Section 9). The bits 1-7 are unassigned and the registration procedure to be followed for this registry is IETF Review. 18.4.5. OSPFv2 Opaque LSA Option Types This document makes the following registrations in the "Opaque Link- State Advertisements (LSA) Option Types" registry under the "Open Shortest Path First (OSPF) Opaque Link-State Advertisements (LSA) Option Types" grouping. Value: 11 Description: OSPFv2 Extended Inter-Area ASBR (EIA-ASBR) LSA Reference: This document (Section 10.1). Psenak, et al. Expires 20 April 2023 [Page 43] Internet-Draft IGP Flexible Algorithm October 2022 18.4.6. OSPFv2 Extended Inter-Area ASBR TLVs This specification requests creation of "OSPFv2 Extended Inter-Area ASBR TLVs" registry under the OSPFv2 Parameters Registry with the following initial values. Value: 1 Description : Extended Inter-Area ASBR Reference: this document The values 2 to 32767 are unassigned, values 32768 to 33023 are reserved for experimental use while the values 0 and 33024 to 65535 are reserved. The registration procedure to be followed for this registry is IETF Review or IESG Approval. 18.4.7. OSPFv2 Inter-Area ASBR Sub-TLVs This specification requests creation of "OSPFv2 Extended Inter-Area ASBR Sub-TLVs" registry under the "Open Shortest Path First v2 (OSPFv2) Parameters" grouping, with the following initial values. Value: 1 Description : OSPF Flexible Algorithm ASBR Metric Reference: this document The values 2 to 32767 are unassigned, values 32768 to 33023 are reserved for experimental use while the values 0 and 33024 to 65535 are reserved. The registration procedure to be followed for this registry is IETF Review or IESG Approval. 18.4.8. OSPF Flexible Algorithm Definition TLV Sub-TLV Registry This document creates the following registry under the "Open Shortest Path First (OSPF) Parameters" grouping: Registry: OSPF Flexible Algorithm Definition TLV sub-TLVs Registration Procedure: IETF Review or IESG Approval Reference: This document (Section 5.2) The "OSPF Flexible Algorithm Definition TLV sub-TLV" registry will define sub-TLVs at any level of nesting for the Flexible Algorithm TLV New values can be allocated via IETF Review or IESG Approval. Psenak, et al. Expires 20 April 2023 [Page 44] Internet-Draft IGP Flexible Algorithm October 2022 This document registers following Sub-TLVs in the "OSPF Flexible Algorithm Definition TLV sub-TLV" registry: Type: 0 Description: Reserved Reference: This document (Section 7.1). Type: 1 Description: Flexible Algorithm Exclude Admin Group Reference: This document (Section 7.1). Type: 2 Description: Flexible Algorithm Include-Any Admin Group Reference: This document (Section 7.2). Type: 3 Description: Flexible Algorithm Include-All Admin Group Reference: This document (Section 7.3). Type: 4 Description: Flexible Algorithm Definition Flags Reference: This document (Section 7.4). Type: 5 Description: Flexible Algorithm Exclude SRLG Reference: This document (Section 7.5). The values 6 to 32767 are unassigned, values 32768-33023 are for experimental use; these will not be registered with IANA. Types in the range 33024-65535 are not to be assigned at this time. Before any assignments can be made in the 33024-65535 range, there MUST be an IETF specification that specifies IANA Considerations that covers the range being assigned. Psenak, et al. Expires 20 April 2023 [Page 45] Internet-Draft IGP Flexible Algorithm October 2022 18.4.9. Link Attribute Applications Registry This document registers following bit in the Link Attribute Applications Registry: Bit-3 Description: Flexible Algorithm (X-bit) Reference: This document (Section 12). 19. Acknowledgements This draft, among other things, is also addressing the problem that the [I-D.gulkohegde-routing-planes-using-sr] was trying to solve. All authors of that draft agreed to join this draft. Thanks to Eric Rosen, Tony Przygienda, William Britto A J, Gunter Van De Velde, Dirk Goethals, Manju Sivaji and, Baalajee S for their detailed review and excellent comments. Thanks to Cengiz Halit for his review and feedback during initial phase of the solution definition. Thanks to Kenji Kumaki for his comments. Thanks to Acee Lindem for editorial comments. 20. References 20.1. Normative References [I-D.ietf-lsr-isis-srv6-extensions] Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extensions to Support Segment Routing over IPv6 Dataplane", Work in Progress, Internet-Draft, draft- ietf-lsr-isis-srv6-extensions-18, 20 October 2021, . [ISO10589] ISO, "Intermediate system to Intermediate system intra- domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/ IEC 10589:2002, Second Edition, November 2002. Psenak, et al. Expires 20 April 2023 [Page 46] Internet-Draft IGP Flexible Algorithm October 2022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, . [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, July 2008, . [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, . [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)", RFC 7308, DOI 10.17487/RFC7308, July 2014, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, . [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . Psenak, et al. Expires 20 April 2023 [Page 47] Internet-Draft IGP Flexible Algorithm October 2022 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, . [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, . [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, December 2019, . [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, . [RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, "IS-IS Application-Specific Link Attributes", RFC 8919, DOI 10.17487/RFC8919, October 2020, . [RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, J., and J. Drake, "OSPF Application-Specific Link Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020, . 20.2. Informative References [I-D.gulkohegde-routing-planes-using-sr] Hegde, S. and A. Gulko, "Separating Routing Planes using Segment Routing", Work in Progress, Internet-Draft, draft- gulkohegde-routing-planes-using-sr-00, 13 March 2017, . [I-D.ietf-rtgwg-segment-routing-ti-lfa] Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, "Topology Independent Fast Reroute using Segment Routing", Work in Progress, Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- 08, 21 January 2022, . Psenak, et al. Expires 20 April 2023 [Page 48] Internet-Draft IGP Flexible Algorithm October 2022 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, DOI 10.17487/RFC3101, January 2003, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels", RFC 3906, DOI 10.17487/RFC3906, October 2004, . [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012, . [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, . Psenak, et al. Expires 20 April 2023 [Page 49] Internet-Draft IGP Flexible Algorithm October 2022 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . Authors' Addresses Peter Psenak (editor) Cisco Systems, Inc. Apollo Business Center Mlynske nivy 43 Bratislava Slovakia Email: ppsenak@cisco.com Shraddha Hegde Juniper Networks, Inc. Embassy Business Park Bangalore, KA 560093 India Email: shraddha@juniper.net Psenak, et al. Expires 20 April 2023 [Page 50] Internet-Draft IGP Flexible Algorithm October 2022 Clarence Filsfils Cisco Systems, Inc. Brussels Belgium Email: cfilsfil@cisco.com Ketan Talaulikar Cisco Systems, Inc India Email: ketant.ietf@gmail.com Arkadiy Gulko Edward Jones Email: arkadiy.gulko@edwardjones.com Psenak, et al. Expires 20 April 2023 [Page 51] ./draft-ietf-oauth-jwt-introspection-response-12.txt0000644000764400076440000011132514114677377022347 0ustar iustiniustin Open Authentication Protocol T. Lodderstedt, Ed. Internet-Draft yes.com AG Intended status: Standards Track V. Dzhuvinov Expires: 8 March 2022 Connect2id Ltd. 4 September 2021 JWT Response for OAuth Token Introspection draft-ietf-oauth-jwt-introspection-response-12 Abstract This specification proposes an additional JSON Web Token (JWT) secured response for OAuth 2.0 Token Introspection. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 March 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, 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 of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 1] Internet-Draft JWT Response September 2021 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation and Conventions . . . . . . . . . . . . 3 3. Resource Server Management . . . . . . . . . . . . . . . . . 3 4. Requesting a JWT Response . . . . . . . . . . . . . . . . . . 4 5. JWT Response . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 7 7. Authorization Server Metadata . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8.1. Cross-JWT Confusion . . . . . . . . . . . . . . . . . . . 9 8.2. Token Data Leakage . . . . . . . . . . . . . . . . . . . 9 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11.1. OAuth Dynamic Client Registration Metadata Registration . . . . . . . . . . . . . . . . . . . . . . 10 11.1.1. Registry Contents . . . . . . . . . . . . . . . . . 10 11.2. OAuth Authorization Server Metadata Registration . . . . 11 11.2.1. Registry Contents . . . . . . . . . . . . . . . . . 11 11.3. Media Type Registration . . . . . . . . . . . . . . . . 12 11.3.1. Registry Contents . . . . . . . . . . . . . . . . . 12 11.4. JWT Claim Registration . . . . . . . . . . . . . . . . . 13 11.4.1. Registry Contents . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Document History . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction OAuth 2.0 Token Introspection [RFC7662] specifies a method for a protected resource to query an OAuth 2.0 authorization server to determine the state of an access token and obtain data associated with the access token. This enables deployments to implement opaque access tokens in an interoperable way. The introspection response, as specified in OAuth 2.0 Token Introspection [RFC7662], is a plain JSON object. However, there are use cases where the resource server requires stronger assurance that the authorization server issued the token introspection response for an access token, including cases where the authorization server assumes liability for the content of the token introspection response. An example is a resource server using verified person data to create certificates, which in turn are used to create qualified electronic signatures. Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 2] Internet-Draft JWT Response September 2021 In such use cases it may be useful or even required to return a signed JWT [RFC7519] as the introspection response. This specification extends the token introspection endpoint with the capability to return responses as JWTs. 2. Requirements Notation and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Resource Server Management The authorization server (AS) and the resource server (RS) maintain a strong two-way trust relationship. The resource server relies on the authorization server to obtain authorization, user and other data as input to its access control decisions and service delivery. The authorization server relies on the resource server to handle the provided data appropriately. In the context of this specification, the token introspection endpoint is used to convey such security data and potentially also privacy sensitive data related to an access token. In order to process the introspection requests in a secure and privacy-preserving manner, the authorization server MUST be able to identify, authenticate and authorize resource servers. The authorization server MAY additionally encrypt the token introspection response JWTs. If encryption is used the authorization server is provisioned with encryption keys and algorithms for the RS. The authorization server MUST be able to determine whether an RS is the audience for a particular access token and what data it is entitled to receive, otherwise the RS is not authorized to obtain data for the access token. The AS has the discretion how to fulfil this requirement. The AS could, for example, maintain a mapping between scope values and resource servers. The requirements given above imply that the authorization server maintains credentials and other configuration data for each RS. One way is by utilizing dynamic client registration [RFC7591] and treating every RS as an OAuth client. In this case, the authorization server is assumed to at least maintain a "client_id" and a "token_endpoint_auth_method" with complementary authentication Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 3] Internet-Draft JWT Response September 2021 method metadata, such as "jwks" or "client_secret". In cases where the AS needs to acquire consent to transmit data to a RS, the following client metadata fields are recommended: "client_name", "client_uri", "contacts", "tos_uri", "policy_uri". The AS MUST restrict the use of client credentials by a RS to the calls it requires, e.g. the AS MAY restrict such a client to call the token introspection endpoint only. How the AS implements this restriction is beyond the scope of this specification. This specification further introduces client metadata to manage the configuration options required to sign and encrypt token introspection response JWTs. 4. Requesting a JWT Response A resource server requests a JWT introspection response by sending an introspection request with an "Accept" HTTP header field set to "application/token-introspection+jwt". The AS MUST authenticate the caller at the token introspection endpoint. Authentication can utilize client authentication methods or a separate access token issued to the resource server and identifying it as subject. The following is a non-normative example request, with the resource server authenticating with a private key JWT: POST /introspect HTTP/1.1 Host: as.example.com Accept: application/token-introspection+jwt Content-Type: application/x-www-form-urlencoded token=2YotnFZFEjr1zCsicMWpAA& client_assertion_type= urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer& client_assertion=PHNhbWxwOl[...omitted for brevity...]ZT 5. JWT Response The introspection endpoint responds with a JWT, setting the "Content- Type" HTTP header field to "application/token-introspection+jwt" and the JWT "typ" ("type") header parameter to "token-introspection+jwt". The JWT MUST include the following top-level claims: iss MUST be set to the issuer URL of the authorization server. Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 4] Internet-Draft JWT Response September 2021 aud MUST identify the resource server receiving the token introspection response. iat MUST be set to the time when the introspection response was created by the authorization server. token_introspection A JSON object containing the members of the token introspection response as specified in [RFC7662], section 2.2. The separation of the introspection response members into a dedicated containing JWT claim is intended to prevent conflict and confusion with top-level JWT claims that may bear the same name. If the access token is invalid, expired, revoked, or not intended for the calling resource server (audience), the authorization server MUST set the value of the "active" member in the "token_introspection" claim to "false" and MUST NOT include other members. Otherwise, the "active" member is set to "true". The AS SHOULD narrow down the "scope" value to the scopes relevant to the particular RS. As specified in section 2.2 of [RFC7662], implementations MAY extend the token introspection response with service-specific claims. In the context of this specification, such claims will be added as top-level members of the "token_introspection" claim. Token introspection response parameter names intended to be used across domains MUST be registered in the OAuth Token Introspection Response registry [IANA.OAuth.Token.Introspection] defined by [RFC7662]. When the AS acts as a provider of resource owner identity claims to the RS, the AS determines based on its RS-specific policy what identity claims to return in the token introspection response. The AS MUST ensure the release of any privacy-sensitive data is legally based (see Section 9). Further content of the introspection response is determined by the RS-specific policy at the AS. The JWT MAY include other claims, including those from the "JSON Web Token Claims" registry established by [RFC7519]. The JWT SHOULD NOT include the "sub" and "exp" claims, as an additional prevention against misuse of the JWT as an access token (see Section 8.1). Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 5] Internet-Draft JWT Response September 2021 Note: Although the JWT format is widely used as an access token format, the JWT returned in the introspection response is not an alternative representation of the introspected access token and is not intended to be used as an access token. This specification registers the "application/token- introspection+jwt" media type, which is used as value of the "typ" ("type") header parameter of the JWT to indicate that the payload is a token introspection response. The JWT is cryptographically secured as specified in [RFC7519]. Depending on the specific resource server policy the JWT is either signed, or signed and encrypted. If the JWT is signed and encrypted it MUST be a Nested JWT, as defined in JWT [RFC7519]. Note: An AS compliant with this specification MUST refuse to serve introspection requests that don't authenticate the caller, and return an HTTP status code 400. This is done to ensure token data is released to legitimate recipients only and prevent downgrading to [RFC7662] behavior (see Section 8.2). The following is a non-normative example response (with line breaks for display purposes only): HTTP/1.1 200 OK Content-Type: application/token-introspection+jwt eyJraWQiOiJ3RzZEIiwidHlwIjoidG9rZW4taW50cm9zcGVjdGlvbitqd3QiLCJhbGc iOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL2FzLmV4YW1wbGUuY29tLyIsImF1ZCI6I mh0dHBzOi8vcnMuZXhhbXBsZS5jb20vcmVzb3VyY2UiLCJpYXQiOjE1MTQ3OTc4OTIs InRva2VuX2ludHJvc3BlY3Rpb24iOnsiYWN0aXZlIjp0cnVlLCJpc3MiOiJodHRwczo vL2FzLmV4YW1wbGUuY29tLyIsImF1ZCI6Imh0dHBzOi8vcnMuZXhhbXBsZS5jb20vcm Vzb3VyY2UiLCJpYXQiOjE1MTQ3OTc4MjIsImV4cCI6MTUxNDc5Nzk0MiwiY2xpZW50X 2lkIjoicGFpQjJnb28wYSIsInNjb3BlIjoicmVhZCB3cml0ZSBkb2xwaGluIiwic3Vi IjoiWjVPM3VwUEM4OFFyQWp4MDBkaXMiLCJiaXJ0aGRhdGUiOiIxOTgyLTAyLTAxIiw iZ2l2ZW5fbmFtZSI6IkpvaG4iLCJmYW1pbHlfbmFtZSI6IkRvZSIsImp0aSI6InQxRm 9DQ2FaZDRYdjRPUkpVV1ZVZVRaZnNLaFczMENRQ3JXRERqd1h5NncifX0.przJMU5Gh mNzvwtt1Sr-xa9xTkpiAg5IshbQsRiRVP_7eGR1GHYrNwQh84kxOkHCyje2g5WSRcYo sGEVIiC-eoPJJ-qBwqwSlgx9JEeCDw2W5DjrblOI_N0Jvsq_dUeOyoWVMqlOydOBhKN Y0smBrI4NZvEExucOm9WUJXMuJtvq1gBes-0go5j4TEv9sOP9uu81gqWTr_LOo6pgT0 tFFyZfWC4kbXPXiQ2YT6mxCiQRRNM-l9cBdF6Jx6IOrsfFhBuYdYQ_mlL19HgDDOFal eyqmru6lKlASOsaE8dmLSeKcX91FbG79FKN8un24iwIDCbKT9xlUFl54xWVShNDFA The example response JWT header contains the following JSON document: Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 6] Internet-Draft JWT Response September 2021 { "typ": "token-introspection+jwt", "alg": "RS256", "kid": "wG6D" } The example response JWT payload contains the following JSON document: { "iss":"https://as.example.com/", "aud":"https://rs.example.com/resource", "iat":1514797892, "token_introspection": { "active":true, "iss":"https://as.example.com/", "aud":"https://rs.example.com/resource", "iat":1514797822, "exp":1514797942, "client_id":"paiB2goo0a", "scope":"read write dolphin", "sub":"Z5O3upPC88QrAjx00dis", "birthdate":"1982-02-01", "given_name":"John", "family_name":"Doe", "jti":"t1FoCCaZd4Xv4ORJUWVUeTZfsKhW30CQCrWDDjwXy6w" } } 6. Client Metadata The authorization server determines the algorithm to secure the JWT for a particular introspection response. This decision can be based on registered metadata parameters for the resource server, supplied via dynamic client registration [RFC7591] with the resource server acting as a client, as specified below. The parameter names follow the pattern established by OpenID Connect Dynamic Client Registration [OpenID.Registration] for configuring signing and encryption algorithms for JWT responses at the UserInfo endpoint. The following client metadata parameters are introduced by this specification: introspection_signed_response_alg OPTIONAL. JWS [RFC7515] algorithm Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 7] Internet-Draft JWT Response September 2021 ("alg" value) as defined in JWA [RFC7518] for signing introspection responses. If this is specified, the response will be signed using JWS and the configured algorithm. The default, if omitted, is "RS256". introspection_encrypted_response_alg OPTIONAL. JWE [RFC7516] algorithm ("alg" value) as defined in JWA [RFC7518] for content key encryption. If this is specified, the response will be encrypted using JWE and the configured content encryption algorithm ("introspection_encrypted_response_enc"). The default, if omitted, is that no encryption is performed. If both signing and encryption are requested, the response will be signed then encrypted, with the result being a Nested JWT, as defined in JWT [RFC7519]. introspection_encrypted_response_enc OPTIONAL. JWE [RFC7516] algorithm ("enc" value) as defined in JWA [RFC7518] for content encryption of introspection responses. The default, if omitted, is "A128CBC-HS256". Note: This parameter MUST NOT be specified without setting "introspection_encrypted_response_alg". Resource servers may register their public encryption keys using the "jwks_uri" or "jwks" metadata parameters. 7. Authorization Server Metadata Authorization servers SHOULD publish the supported algorithms for signing and encrypting the JWT of an introspection response by utilizing OAuth 2.0 Authorization Server Metadata [RFC8414] parameters. Resource servers use this data to parametrize their client registration requests. The following parameters are introduced by this specification: introspection_signing_alg_values_supported OPTIONAL. JSON array containing a list of the JWS [RFC7515] signing algorithms ("alg" values) as defined in JWA [RFC7518] supported by the introspection endpoint to sign the response. introspection_encryption_alg_values_supported OPTIONAL. JSON array containing a list of the JWE [RFC7516] encryption algorithms ("alg" values) as defined in JWA [RFC7518] supported by the introspection endpoint to encrypt the content encryption key for introspection responses (content key encryption). introspection_encryption_enc_values_supported OPTIONAL. JSON array Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 8] Internet-Draft JWT Response September 2021 containing a list of the JWE [RFC7516] encryption algorithms ("enc" values) as defined in JWA [RFC7518] supported by the introspection endpoint to encrypt the response (content encryption). 8. Security Considerations 8.1. Cross-JWT Confusion The "iss" and potentially the "aud" claim of a token introspection JWT can resemble those of a JWT-encoded access token. An attacker could try to exploit this and pass a JWT token introspection response as an access token to the resource server. The "typ" ("type") JWT header "token-introspection+jwt" and the encapsulation of the token introspection members such as "sub" and "scope" in the "token_introspection" claim is intended to prevent such substitution attacks. Resource servers MUST therefore check the "typ" JWT header value of received JWT-encoded access tokens and ensure all minimally required claims for a valid access token are present. Resource servers MUST additionally apply the countermeasures against replay as described in [I-D.ietf-oauth-security-topics], section 3.2. JWT Confusion and other attacks involving JWTs are discussed in [I-D.ietf-oauth-jwt-bcp]. 8.2. Token Data Leakage The authorization server MUST use Transport Layer Security (TLS) 1.2 (or higher) per BCP 195 [RFC7525] in order to prevent token data leakage. Section 2.1 of [RFC7662] permits requests to the introspection endpoint to be authorized with an access token which doesn't identify the caller. To prevent introspection of tokens by parties that are not the intended consumer the authorization server MUST require all requests to the token introspection endpoint to be authenticated. 9. Privacy Considerations The token introspection response can be used to transfer personal identifiable information (PII) from the AS to the RS. The AS MUST conform to legal and jurisdictional constraints for the data transfer before any data is released to a particular RS. The details and determining of these constraints varies by jurisdiction and is outside the scope of this document. Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 9] Internet-Draft JWT Response September 2021 A commonly found way to establish the legal basis for releasing PII is by explicit user consent gathered from the resource owner by the AS during the authorization flow. It is also possible that the legal basis is established out of band, for example in an explicit contract or by the client gathering the resource owner's consent. If the AS and the RS belong to the same legal entity (1st party scenario), there is potentially no need for an explicit user consent but the terms of service and policy of the respective service provider MUST be enforced at all times. In any case, the AS MUST ensure that the scope of the legal basis is enforced throughout the whole process. The AS MUST retain the scope of the legal basis with the access token, e.g. in the scope value, it MUST authenticate the RS, and the AS MUST determine the data a resource server is allowed to receive based on the resource server's identity and suitable token data, e.g. the scope value. Implementers should be aware that a token introspection request lets the AS know when the client (and potentially the user) is accessing the RS, which is also an indication of when the user is using the client. If this implication is not acceptable, implementers MUST use other means to relay access token data, for example by directly transferring the data needed by the RS within the access token. 10. Acknowledgements We would like to thank Petteri Stenius, Neil Madden, Filip Skokan, Tony Nadalin, Remco Schaar, Justin Richer, Takahiko Kawasaki, Benjamin Kaduk, Robert Wilton and Roman Danyliw for their valuable feedback. 11. IANA Considerations 11.1. OAuth Dynamic Client Registration Metadata Registration This specification requests registration of the following client metadata definitions in the IANA "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]: 11.1.1. Registry Contents * Client Metadata Name: "introspection_signed_response_alg" * Client Metadata Description: String value indicating the client's desired introspection response signing algorithm. Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 10] Internet-Draft JWT Response September 2021 * Change Controller: IESG * Specification Document(s): Section 6 of [[ this specification ]] * Client Metadata Name: "introspection_encrypted_response_alg" * Client Metadata Description: String value specifying the desired introspection response content key encryption algorithm (alg value). * Change Controller: IESG * Specification Document(s): Section 6 of [[ this specification ]] * Client Metadata Name: "introspection_encrypted_response_enc" * Client Metadata Description: String value specifying the desired introspection response content encryption algorithm (enc value). * Change Controller: IESG * Specification Document(s): Section 6 of [[ this specification ]] 11.2. OAuth Authorization Server Metadata Registration This specification requests registration of the following values in the IANA "OAuth Authorization Server Metadata" registry [IANA.OAuth.Parameters] established by [RFC8414]. 11.2.1. Registry Contents * Metadata Name: "introspection_signing_alg_values_supported" * Metadata Description: JSON array containing a list of algorithms supported by the authorization server for introspection response signing. * Change Controller: IESG * Specification Document(s): Section 7 of [[ this specification ]] * Metadata Name: "introspection_encryption_alg_values_supported" * Metadata Description: JSON array containing a list of algorithms supported by the authorization server for introspection response content key encryption (alg value). * Change Controller: IESG Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 11] Internet-Draft JWT Response September 2021 * Specification Document(s): Section 7 of [[ this specification ]] * Metadata Name: "introspection_encryption_enc_values_supported" * Metadata Description: JSON array containing a list of algorithms supported by the authorization server for introspection response content encryption (enc value). * Change Controller: IESG * Specification Document(s): Section 7 of [[ this specification ]] 11.3. Media Type Registration This section registers the "application/token-introspection+jwt" media type in the "Media Types" registry [IANA.MediaTypes] in the manner described in [RFC6838], which can be used to indicate that the content is a token introspection response in JWT format. 11.3.1. Registry Contents * Type name: application * Subtype name: token-introspection+jwt * Required parameters: N/A * Optional parameters: N/A * Encoding considerations: binary; A token introspection response is a JWT; JWT values are encoded as a series of base64url-encoded values (with trailing '=' characters removed), some of which may be the empty string, separated by period ('.') characters. * Security considerations: See Section 7 of this specification * Interoperability considerations: N/A * Published specification: Section 4 of this specification * Applications that use this media type: Applications that produce and consume OAuth Token Introspection Responses in JWT format * Fragment identifier considerations: N/A * Additional information: - Magic number(s): N/A Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 12] Internet-Draft JWT Response September 2021 - File extension(s): N/A - Macintosh file type code(s): N/A * Person & email address to contact for further information: Torsten Lodderstedt, torsten@lodderstedt.net * Intended usage: COMMON * Restrictions on usage: none * Author: Torsten Lodderstedt, torsten@lodderstedt.net * Change controller: IESG * Provisional registration? No 11.4. JWT Claim Registration This section registers the "token_introspection" claim in the JSON Web Token (JWT) IANA registry [IANA.JWT] in the manner described in [RFC7519]. 11.4.1. Registry Contents * Claim name: token_introspection * Claim description: Token introspection response * Change Controller: IESG * Specification Document(s): Section 5 of [[this specification]] 12. References 12.1. Normative References [I-D.ietf-oauth-jwt-bcp] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", Work in Progress, Internet-Draft, draft-ietf-oauth-jwt-bcp-06, 7 June 2019, . Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 13] Internet-Draft JWT Response September 2021 [I-D.ietf-oauth-security-topics] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "OAuth 2.0 Security Best Current Practice", Work in Progress, Internet-Draft, draft-ietf-oauth-security- topics-13, 8 July 2019, . [IANA.JWT] IANA, "JSON Web Token (JWT) claims registry", . [IANA.MediaTypes] IANA, "Media Types", . [IANA.OAuth.Token.Introspection] IANA, "OAuth Token Introspection Response registry", . [OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1", 8 November 2014, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 14] Internet-Draft JWT Response September 2021 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . 12.2. Informative References [IANA.OAuth.Parameters] IANA, "OAuth Parameters", . Appendix A. Document History [[ To be removed from the final specification ]] -12 * made registration of response parameters intended for cross domain use a MUST ( in RFC 7662) -11 * consistent normative language that the AS must authenticate all callers to the token introspection endpoint when complying with this specification Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 15] Internet-Draft JWT Response September 2021 * removes text that claims from the JSON Web Token Claims registry may be included in the token_introspection claim * updates the privacy considerations section * fixes the example BASE64URL encoded JWT payload -10 * added requirement to authenticate RS if privacy sensitive data is released * reworked text on claims from different registries * added forward reference to privacy considerations to section 5 * added text in privacy considerations regarding client/user tracking -09 * changes the Accept and Content-Type HTTP headers from "application/json" to "application/token-introspection+jwt" so they match the registered media type * moves the token introspection response members into a JSON object claim named "token_introspection" to provide isolation from the top-level JWT-specific claims * "iss", "aud" and "iat" MUST be present as top-level JWT claims * the "sub" and "exp" claims SHOULD NOT be used as top-level JWT claims as additional prevention against JWT access token substitution attacks -08 * made difference between introspected access token and introspection response clearer * defined semantics of JWT claims overlapping between introspected access token and introspection response as JWT * added section about RS management * added text about user claims including a privacy considerations section Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 16] Internet-Draft JWT Response September 2021 * removed registration of OpenID Connect claims to "Token Introspection Response" registry and refer to "JWT Claims" registry instead * added registration of "application/token-introspection+jwt" media type as type identifier of token introspection responses in JWT format * more changed to incorporate IESG review feedback -07 * fixed wrong description of "locale" * added references for ISO and ITU specifications -06 * replaced reference to RFC 7159 with reference to RFC 8259 -05 * improved wording for TLS requirement * added RFC 2119 boilerplate * fixed and updated some references -04 * reworked definition of parameters in section 4 * added text on data minimization to security considerations section * added statement regarding TLS to security considerations section -03 * added registration for OpenID Connect Standard Claims to OAuth Token Introspection Response registry -02 * updated references -01 Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 17] Internet-Draft JWT Response September 2021 * adapted wording to preclude any accept header except "application/ jwt" if encrypted responses are required * use registered alg value RS256 for default signing algorithm * added text on claims in the token introspection response -00 * initial version of the WG draft * defined default signing algorithm * changed behavior in case resource server is set up for encryption * Added text on token data leakage prevention to the security considerations * moved Security Considerations section forward WG draft -01 * fixed typos in client meta data field names * added OAuth Server Metadata parameters to publish algorithms supported for signing and encrypting the introspection response * added registration of new parameters for OAuth Server Metadata and Client Registration * added explicit request for JWT introspection response * made iss and aud claims mandatory in introspection response * Stylistic and clarifying edits, updates references -00 * initial version Authors' Addresses Torsten Lodderstedt (editor) yes.com AG Email: torsten@lodderstedt.net Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 18] Internet-Draft JWT Response September 2021 Vladimir Dzhuvinov Connect2id Ltd. Email: vladimir@connect2id.com Lodderstedt & Dzhuvinov Expires 8 March 2022 [Page 19] ./draft-ietf-lsr-isis-flood-reflection-12.txt0000644000764400076440000015047414343444450020665 0ustar iustiniustin Network Working Group A. Przygienda, Ed. Internet-Draft C. Bowers Intended status: Experimental Juniper Expires: 8 June 2023 Y. Lee Comcast A. Sharma Individual R. White Akamai 5 December 2022 IS-IS Flood Reflection draft-ietf-lsr-isis-flood-reflection-12 Abstract This document describes a backward-compatible, optional IS-IS extension that allows the creation of IS-IS flood reflection topologies. Flood reflection permits topologies in which L1 areas provide transit forwarding for L2 using all available L1 nodes internally. It accomplishes this by creating L2 flood reflection adjacencies within each L1 area. Those adjacencies are used to flood L2 LSPDUs and are used in the L2 SPF computation. However, they are not ordinarily utilized for forwarding within the flood reflection cluster. This arrangement gives the L2 topology significantly better scaling properties than traditionally used flat designs. As an additional benefit, only those routers directly participating in flood reflection are required to support the feature. This allows for incremental deployment of scalable L1 transit areas in an existing, previously flat network design, without the necessity of upgrading all routers in the network. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Przygienda, et al. Expires 8 June 2023 [Page 1] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Further Details . . . . . . . . . . . . . . . . . . . . . . . 9 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Flood Reflection TLV . . . . . . . . . . . . . . . . . . 10 4.2. Flood Reflection Discovery Sub-TLV . . . . . . . . . . . 11 4.3. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV . . . 12 4.4. Flood Reflection Adjacency Sub-TLV . . . . . . . . . . . 14 4.5. Flood Reflection Discovery . . . . . . . . . . . . . . . 15 4.6. Flood Reflection Adjacency Formation . . . . . . . . . . 16 5. Route Computation . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Tunnel-Based Deployment . . . . . . . . . . . . . . . . . 17 5.2. No-Tunnel Deployment . . . . . . . . . . . . . . . . . . 17 6. Redistribution of Prefixes . . . . . . . . . . . . . . . . . 17 7. Special Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8.1. New IS-IS TLV Codepoint . . . . . . . . . . . . . . . . . 19 8.2. Sub TLVs for IS-IS Router CAPABILITY TLV . . . . . . . . 19 8.3. Sub-sub TLVs for Flood Reflection Discovery sub-TLV . . . 19 8.4. Sub TLVs for TLVs Advertising Neighbor Information . . . 19 Przygienda, et al. Expires 8 June 2023 [Page 2] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Informative References . . . . . . . . . . . . . . . . . 20 11.2. Normative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction This section introduces the problem space and outlines the solution. Some of the terms may be unfamiliar to readers without extensive IS- IS background; for such readers a glossary is provided in Section 2. Due to the inherent properties of link-state protocols the number of IS-IS routers within a flooding domain is limited by processing and flooding overhead on each node. While that number can be maximized by well-written implementations and techniques such as exponential back-offs, IS-IS will still reach a saturation point where no further routers can be added to a single flooding domain. In some L2 backbone deployment scenarios, this limit presents a significant challenge. The traditional approach to increasing the scale of an IS-IS deployment is to break it up into multiple L1 flooding domains and a single L2 backbone. This works well for designs where an L2 backbone connects L1 access topologies, but it is limiting where a single, flat L2 domain is supposed to span large number of routers. In such scenarios, an alternative approach could be to consider multiple L2 flooding domains connected together via L1 flooding domains. In other words, L2 flooding domains are connected by "L1/L2 lanes" through the L1 areas to form a single L2 backbone again. Unfortunately, in its simplest implementation, this requires the inclusion of most, or all, of the transit L1 routers as L1/L2 to allow traffic to flow along optimal paths through those transit areas. Consequently, such an approach fails to reduce the number of L2 routers involved and with that fails to increase the scalability of the L2 backbone as well. Figure 1 is an example of a network where a topologically rich L1 area is used to provide transit between six different L2-only routers (R1-R6). Note that the six L2-only routers do not have connectivity to one another over L2 links. To take advantage of the abundance of paths in the L1 transit area, all the intermediate systems could be placed into both L1 and L2, but this essentially combines the separate L2 flooding domains into a single one, triggering again the maximum L2 scale limitation we try to address in first place. Przygienda, et al. Expires 8 June 2023 [Page 3] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 +====+ +=======+ +=======+ +======-+ +====+ I R1 I I R10 +-------------+ R20 +---------------+ R30 I I R4 I I L2 +--+ L1/L2 I I L1 I I L1/L2 +--+ L2 I I I I + +--+ I +------------+ I I I +====+ ++====+=+ | +===+===+ | +=+==+=++ +====+ | | | | | | | | | | | | +-----------+ | | +-------+ | | | | | | | | | | | | | | | | | | | | | | | | | | +====+ ++=====-+ | | +===+===+--+ | +======++ +====+ I R2 I I R11 I | | I R21 I | I R31 I I R5 I I L2 +--+ L1/L2 +-------------+ L1 +---------------+ L1/L2 +--+ L2 I I I I I | | I I | +-------+ I I I +====+ ++=====-+ | | ++==+==++ | | +======++ +====+ | | | | | | | | | | +---------------+ | | | | | | | | | | | | | | | | | +----------------+ | +-----------------+ | | | | | | | | | | +====+ ++=+==+=+ +-------+===+===+-----+ | ++=====++ +====+ I R3 I I R12 I I R22 I | + R32 I I R6 I I L2 +--+ L1/L2 I I L1 +-------+ I L1/L2 +--+ L2 I I I I +-------------+ +---------------+ I I I +====+ +=======+ +=======+ +=======+ +====+ Figure 1: Example Topology of L1 with L2 Borders A more effective solution would allow to reduce the number of links and routers exposed in L2, while still utilizing the full L1 topology when forwarding through the network. [RFC8099] describes Topology Transparent Zones (TTZ) for OSPF. The TTZ mechanism represents a group of OSPF routers as a full mesh of adjacencies between the routers at the edge of the group. A similar mechanism could be applied to IS-IS as well. However, a full mesh of adjacencies between edge routers (or L1/L2 nodes) significantly limits the practically achievable scale of the resulting topology. The topology in Figure 1 has 6 L1/L2 nodes. Figure 2 illustrates a full mesh of L2 adjacencies between the 6 L1/L2 nodes, resulting in (5 * 6)/2 = 15 L2 adjacencies. In a somewhat larger topology containing 20 L1/L2 nodes, the number of L2 adjacencies in a full mesh rises to 190. Przygienda, et al. Expires 8 June 2023 [Page 4] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 +----+ +-------+ +-------------------------------+-------+ +----+ | R1 | | R10 | | | R30 | | R4 | | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | | | | | | | | | | +----+ ++-+-+--+-+ | +-+--+---++ +----+ | | | | | | | | | +----------------------------------------------+ | | | | | | | | | | +-----------------------------------+ | | | | | | | | | | | | | +----------------------------------------+ | | | | | | | | | | +----+ ++-----+- | | | | -----+-++ +----+ | R2 | | R11 | | | | | | R31 | | R5 | | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | | | | | | | | | | | | | +----+ ++------+------------------------------+ | | +----+-++ +----+ | | | | | | | | | | | | | | | | | +-------------------------------------------+ | | | | | | | | | | | | | +----------+ | | | | | | | | | | | | | +-----+ | | | | | | | | | | +----+ ++----+-+-+ | +-+-+--+-++ +----+ | R3 | | R12 | | L2 adjacency | R32 | | R6 | | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | | | | | | | | | | +----+ +-------+----+ +-------+ +----+ Figure 2: Example topology represented in L2 with a full mesh of L2 adjacencies between L1/L2 nodes BGP, as specified in [RFC4271], faced a similar scaling problem, which has been solved in many networks by deploying BGP route reflectors [RFC4456]. We note that BGP route reflectors do not necessarily have to be in the forwarding path of the traffic. This non-congruity of forwarding and control path for BGP route reflectors allows the control plane to scale independently of the forwarding plane and represents an interesting degree of freedom in network architecture. We propose in this document a similar solution for IS-IS and call it "flood reflection" in fashion analogous to "route reflection". A simple example of what a flood reflector control plane approach would look like is shown in Figure 3, where router R21 plays the role of a Przygienda, et al. Expires 8 June 2023 [Page 5] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 flood reflector. Each L1/L2 ingress/egress router builds a tunnel to the flood reflector, and an L2 adjacency is built over each tunnel. In this solution, we need only 6 L2 adjacencies, instead of the 15 needed for a full mesh. In a somewhat larger topology containing 20 L1/L2 nodes, this solution requires only 20 L2 adjacencies, instead of the 190 needed for a full mesh. Multiple flood reflectors can be used, allowing the network operator to balance between resilience, path utilization, and state in the control plane. The resulting L2 adjacency scale is R*n, where R is the number of flood reflectors used and n is the number of L1/L2 nodes. This compares quite favorably with n*(n-1)/2 L2 adjacencies required in a topologically fully meshed L2 solution. +----+ +-------+ +-------+ +----+ | R1 | | R10 | | R30 | | R4 | | L2 +--+ L1/L2 +--------------+ +-----------------+ L1/L2 +--+ L2 | | | | | L2 adj | | L2 adj | | | | +----+ +-------+ over | | over +-------+ +----+ tunnel | | tunnel +----+ +-------+ +--+---+--+ +-------+ +----+ | R2 | | R11 | | R21 | | R31 | | R5 | | L2 +--+ L1/L2 +-----------+ L1/L2 +--------------+ L1/L2 +--+ L2 | | | | | L2 adj | flood | L2 adj | | | | +----+ +-------+ over |reflector| over +-------+ +----+ tunnel +--+---+--+ tunnel +----+ +-------+ | | +-------+ +----+ | R3 | | R12 +--------------+ +-----------------+ R32 | | R6 | | L2 +--+ L1/L2 | L2 adj L2 adj | L1/L2 +--+ L2 | | | | | over over | | | | +----+ +-------+ tunnel tunnel +-------+ +----+ Figure 3: Example topology represented in L2 with L2 adjacencies from each L1/ L2 node to a single flood reflector As illustrated in Figure 3, when R21 plays the role of flood reflector, it provides L2 connectivity among all of the previously disconnected L2 islands by reflooding all L2 LSPDUs. At the same time, R20 and R22 in Figure 1 remain L1-only routers. L1-only routers and L1-only links are not visible in L2. In this manner, the flood reflector allows us provide L2 control plane connectivity in a manner more scalable than a flat L2 domain. Przygienda, et al. Expires 8 June 2023 [Page 6] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 As described so far, the solution illustrated in Figure 3 relies only on currently standardized IS-IS functionality. Without new functionality, however, the data traffic will traverse only R21. This will unnecessarily create a bottleneck at R21 since there is still available capacity in the paths crossing the L1-only routers R20 and R22 in Figure 1. Hence, additional functionality is compulsory to allow the L1/L2 edge nodes (R10-12 and R30-32 in Figure 3) to recognize that the L2 adjacency to R21 should not be used for forwarding. The L1/L2 edge nodes should forward traffic that would normally be forwarded over the L2 adjacency to R21 over L1 links instead. This would allow the forwarding within the L1 area to use the L1-only nodes and links shown in Figure 1 as well. It allows networks to be built that use the entire forwarding capacity of the L1 areas, while at the same time introducing control plane scaling benefits provided by L2 flood reflectors. It is expected that deployment at scale, and suitable time in operation, will provide sufficient evidence to either make this extension a standard, or suggest necessary modifications to accomplish this. The remainder of this document defines the remaining extensions necessary for a complete flood reflection solution: * It defines a special 'flood reflector adjacency' built for the purpose of reflecting flooding information. These adjacencies allow 'flood reflectors' to participate in the IS-IS control plane without necessarily being used in the forwarding plane. Maintenance of such adjacencies is a purely local operation on the L1/L2 ingress and flood reflectors; it does not require replacing or modifying any routers not involved in the reflection process. In practical deployments, it is far less tricky to just upgrade the routers involved in flood reflection rather than have a flag day for the whole IS-IS domain. * It specifies an (optional) full mesh of tunnels between the L1/L2 ingress routers, ideally load-balancing across all available L1 links. This harnesses all forwarding paths between the L1/L2 edge nodes without injecting unneeded state into the L2 flooding domain or creating 'choke points' at the 'flood reflectors' themselves. The specification is agnostic as to the tunneling technology used but provides enough information for automatic establishment of such tunnels if desired. The discussion of IS-IS adjacency formation and/or liveness discovery on such tunnels is outside the scope of this specification and is largely a choice of the underlying implementation. A solution without tunnels is also Przygienda, et al. Expires 8 June 2023 [Page 7] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 possible by introducing the correct scoping of reachability information between the levels. This is described in more detail later. * Finally, the document defines support of reflector redundancy and an (optional) way to auto-discover and annotate flood reflector adjacencies on advertisements. Such additional information in link advertisements allows L2 nodes outside the L1 area to recognize a flood reflection cluster and its adjacencies. 2. Glossary The following terms are used in this document. ISIS Level-1 and Level-2 areas, mostly abbreviated as L1 and L2: Traditional ISIS concepts whereas a routing domain has two "levels" with a single L2 area being the "backbone" that connects multiple L1 areas for scaling and reliability purposes. In traditional ISIS L2 can be used as transit for L1-L1 traffic but L1 areas cannot be used for that purpose since L2 level must be "connected" and all traffic flows along L2 routers until it arrives at the destination L1 area. Flood Reflector: Node configured to connect in L2 only to flood reflector clients and reflect (reflood) IS-IS L2 LSPs amongst them. Flood Reflector Client: Node configured to build Flood Reflector Adjacencies to Flood Reflectors, and normal adjacencies to other clients and L2 nodes not participating in flood reflection. Flood Reflector Adjacency: IS-IS L2 adjacency where one end is a Flood Reflector Client and the other a Flood Reflector, and the two have the same Flood Reflector Cluster ID. Flood Reflector Cluster: Collection of clients and flood reflectors configured with the same cluster identifier. Tunnel-Based Deployment: Deployment where Flood Reflector Clients build a partial or full mesh of tunnels in L1 to "shortcut" forwarding of L2 traffic through the cluster. Przygienda, et al. Expires 8 June 2023 [Page 8] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 No-Tunnel Deployment: Deployment where Flood Reflector Clients redistribute L2 reachability into L1 to allow forwarding through the cluster without underlying tunnels. Tunnel Endpoint: An endpoint that allows the establishment of a bi-directional tunnel carrying IS-IS control traffic or alternately, serves as the origin of such a tunnel. L1 shortcut: A tunnel between two clients visible in L1 only that is used as a next-hop, i.e. to carry data traffic in tunnel-based deployment mode. Hot-Potato Routing: In context of this document, a routing paradigm where L2->L1 routes are less preferred than L2 routes [RFC5302]. 3. Further Details Several considerations should be noted in relation to such a flood reflection mechanism. First, this allows multi-area IS-IS deployments to scale without any major modifications in the IS-IS implementation on most of the nodes deployed in the network. Unmodified (traditional) L2 routers will compute reachability across the transit L1 area using the flood reflector adjacencies. Second, the flood reflectors are not required to participate in forwarding traffic through the L1 transit area. These flood reflectors can be hosted on virtual devices outside the forwarding topology. Third, astute readers will realize that flooding reflection may cause the use of suboptimal paths. This is similar to the BGP route reflection suboptimal routing problem described in [ID.draft-ietf-idr-bgp-optimal-route-reflection-28]. The L2 computation determines the egress L1/L2 and with that can create illusions of ECMP where there is none, and in certain scenarios lead to an L1/L2 egress which is not globally optimal. This represents a straightforward instance of the trade-off between the amount of control plane state and the optimal use of paths through the network often encountered when aggregating routing information. Przygienda, et al. Expires 8 June 2023 [Page 9] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 One possible solution to this problem is to expose additional topology information into the L2 flooding domains. In the example network given, links from router R10 to router R11 can be exposed into L2 even when R10 and R11 are participating in flood reflection. This information would allow the L2 nodes to build 'shortcuts' when the L2 flood reflected part of the topology looks more expensive to cross distance wise. Another possible variation is for an implementation to approximate with the tunnel cost the cost of the underlying topology. Redundancy can be achieved by configuring multiple flood reflectors in a L1 area. Multiple flood reflectors do not need any synchronization mechanisms amongst themselves, except standard IS-IS flooding and database maintenance procedures. 4. Encodings 4.1. Flood Reflection TLV The Flood Reflection TLV is a top-level TLV that MUST appear in L2 IIHs on all Flood Reflection Adjacencies. The Flood Reflection TLV indicates the flood reflector cluster (based on Flood Reflection Cluster ID) that a given router is configured to participate in. It also indicates whether the router is configured to play the role of either flood reflector or flood reflector client. The Flood Reflection Cluster ID and flood reflector roles advertised in the IIHs are used to ensure that flood reflector adjacencies are only formed between a flood reflector and flood reflector client, and that the Flood Reflection Cluster IDs match. The Flood Reflection TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |C| RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flood Reflection Cluster ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 161 Length: The length, in octets, of the following fields. C (Client): This bit is set to indicate that the router acts as a Przygienda, et al. Expires 8 June 2023 [Page 10] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 flood reflector client. When this bit is NOT set, the router acts as a flood reflector. On a given router, the same value of the C-bit MUST be advertised across all interfaces advertising the Flood Reflection TLV in IIHs. RESERVED: This field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received. Flood Reflection Cluster ID: Flood Reflection Cluster Identifier. The same arbitrary 32-bit value MUST be assigned to all of the flood reflectors and flood reflector clients in the same L1 area. The value MUST be unique across different L1 areas within the IGP domain. In case of violation of those rules multiple L1 areas may become a single cluster or a single area may split in flood reflection sense and several mechanisms such as auto-discovery of tunnels may not work correctly. On a given router, the same value of the Flood Reflection Cluster ID MUST be advertised across all interfaces advertising the Flood Reflection TLV in IIHs. When a router discovers that a node is using more than a single Cluster IDs based on its advertised TLVs and IIHs, the node MAY log such violations subject to rate limiting. This implies that a flood reflector MUST NOT participate in more than a single L1 area. In case of Cluster ID value of 0, the TLV containing it MUST be ignored. Sub-TLVs: Optional sub-TLVs. For future extensibility, the format of the Flood Reflection TLV allows for the possibility of including optional sub-TLVs. No sub-TLVs of the Flood Reflection TLV are defined in this document. The Flood Reflection TLV SHOULD NOT appear more than once in an IIH. A router receiving one or more Flood Reflection TLVs in the same IIH MUST use the values in the first TLV and it SHOULD log such violations subject to rate limiting. 4.2. Flood Reflection Discovery Sub-TLV The Flood Reflection Discovery sub-TLV is advertised as a sub-TLV of the IS-IS Router Capability TLV-242, defined in [RFC7981]. The Flood Reflection Discovery sub-TLV is advertised in L1 and L2 LSPs with area flooding scope in order to enable the auto-discovery of flood reflection capabilities. The Flood Reflection Discovery sub-TLV has the following format: Przygienda, et al. Expires 8 June 2023 [Page 11] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |C| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flood Reflection Cluster ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 161 Length: The length, in octets, of the following fields. C (Client): This bit is set to indicate that the router acts as a flood reflector client. When this bit is NOT set, the router acts as a flood reflector. RESERVED: This field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received. Flood Reflection Cluster ID: The Flood Reflection Cluster Identifier is the same as that defined in the Flood Reflection TLV and obeys the same rules. The Flood Reflection Discovery sub-TLV SHOULD NOT appear more than once in TLV 242. A router receiving one or more Flood Reflection Discovery sub-TLVs in TLV 242 MUST use the values in the first sub- TLV of the lowest numbered fragment and it SHOULD log such violations subject to rate limiting. 4.3. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV Flood Reflection Discovery Tunnel Type sub-sub-TLV is advertised optionally as a sub-sub-TLV of the Flood Reflection Discovery Sub- TLV, defined in Section 4.2. It allows the automatic creation of L2 tunnels to be used as flood reflector adjacencies and L1 shortcut tunnels. The Flood Reflection Tunnel Type sub-sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+-+ | Type | Length | Reserved |F| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Encapsulation Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 161 Przygienda, et al. Expires 8 June 2023 [Page 12] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 Length: The length, in octets, of zero or more of the following fields. Reserved: SHOULD be 0 on transmission and MUST be ignored on reception. F Flag: When set indicates flood reflection tunnel endpoint, when clear, indicates possible L1 shortcut tunnel endpoint. Tunnel Encapsulation Attribute: Carries encapsulation type and further attributes necessary for tunnel establishment as defined in [RFC9012]. In context of this attribute the protocol Type sub- TLV as defined in [RFC9012] MAY be included to ensure proper encapsulation of IS-IS frames. In case such a sub-TLV is included and the F flag is set (i.e. the resulting tunnel is a flood reflector adjacency) this sub-TLV MUST include a type that allows to carry encapsulated IS-IS frames. Furthermore, such tunnel type MUST be able to transport IS-IS frames of size up to `originatingL2LSPBufferSize`. A flood reflector receiving Flood Reflection Discovery Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub-TLV with F flag set (i.e. the resulting tunnel is a flood reflector adjacency) SHOULD use one or more of the specified tunnel endpoints to automatically establish one or more tunnels that will serve as flood reflection adjacency(-ies) to the clients advertising the endpoints. A flood reflection client receiving one or more Flood Reflection Discovery Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub- TLV with F flag clear (i.e. the resulting tunnel is used to support tunnel-based mode) from other leaves MAY use one or more of the specified tunnel endpoints to automatically establish one or more tunnels that will serve as L1 tunnel shortcuts to the clients advertising the endpoints. In case of automatic flood reflection adjacency tunnels and in case IS-IS adjacencies are being formed across L1 shortcuts all the aforementioned rules in Section 4.5 apply as well. Optional address validation procedures as defined in [RFC9012] MUST be disregarded. It remains to be observed that automatic tunnel discovery is an optional part of the specification and can be replaced or mixed with statically configured tunnels for either flood reflector adjacencies and/or tunnel-based shortcuts. Specific implementation details how both mechanisms interact are specific to an implementation and mode of operation and are outside the scope of this document. Przygienda, et al. Expires 8 June 2023 [Page 13] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 Flood reflector adjacencies rely on IS-IS L2 liveliness procedures. In case of L1 shortcuts the mechanism used to ensure liveliness and tunnel integrity are outside the scope of this document. 4.4. Flood Reflection Adjacency Sub-TLV The Flood Reflection Adjacency sub-TLV is advertised as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 (the "TLVs Advertising Neighbor Information"). Its presence indicates that a given adjacency is a flood reflector adjacency. It is included in L2 area scope flooded LSPs. The Flood Reflection Adjacency sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |C| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flood Reflection Cluster ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 161 Length: The length, in octets, of the following fields. C (Client): This bit is set to indicate that the router advertising this adjacency is a flood reflector client. When this bit is NOT set, the router advertising this adjacency is a flood reflector. RESERVED: This field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received. Flood Reflection Cluster ID: The Flood Reflection Cluster Identifier is the same as that defined in the Flood Reflection TLV and obeys the same rules. The Flood Reflection Adjacency sub-TLV SHOULD NOT appear more than once in a given TLV. A router receiving one or more Flood Reflection Adjacency sub-TLVs in a TLV MUST use the values in the first sub-TLV of the lowest numbered fragment and it SHOULD log such violations subject to rate limiting. Przygienda, et al. Expires 8 June 2023 [Page 14] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 4.5. Flood Reflection Discovery A router participating in flood reflection as client or reflector MUST be configured as an L1/L2 router. It MAY originate the Flood Reflection Discovery sub-TLV with area flooding scope in L1 and L2. Normally, all routers on the edge of the L1 area (those having traditional L2 adjacencies) will advertise themselves as flood reflector clients. Therefore, a flood reflector client will have both traditional L2 adjacencies and flood reflector L2 adjacencies. A router acting as a flood reflector MUST NOT form any traditional L2 adjacencies except with flood reflector clients. It will be an L1/L2 router only by virtue of having flood reflector L2 adjacencies. A router desiring to act as a flood reflector MAY advertise itself as such using the Flood Reflection Discovery sub-TLV in L1 and L2. A given flood reflector or flood reflector client can only participate in a single cluster, as determined by the value of its Flood Reflection Cluster ID and should disregard other routers' TLVs for flood reflection purposes if the cluster ID is not matching. Upon reception of Flood Reflection Discovery sub-TLVs, a router acting as flood reflector SHOULD initiate a tunnel towards each flood reflector client with which it shares a Flood Reflection Cluster ID using one or more of the tunnel encapsulations provided with F flag is set. The L2 adjacencies formed over such tunnels MUST be marked as flood reflector adjacencies. If the client or reflector has a direct L2 adjacency with the according remote side it SHOULD use it instead of instantiating a tunnel. In case the optional auto-discovery mechanism is not implemented or enabled a deployment MAY use statically configured tunnels to create flood reflection adjacencies. The IS-IS metrics for all flood reflection adjacencies in a cluster SHOULD be identical. Upon reception of Flood Reflection Discovery TLVs, a router acting as a flood reflector client MAY initiate tunnels with L1-only adjacencies towards any of the other flood reflector clients with lower router IDs in its cluster using encapsulations with F flag clear. These tunnels MAY be used for forwarding to improve the load- balancing characteristics of the L1 area. If the clients have a direct L2 adjacency they SHOULD use it instead of instantiating a new tunnel. Przygienda, et al. Expires 8 June 2023 [Page 15] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 4.6. Flood Reflection Adjacency Formation In order to simplify implementation complexity, this document does not allow the formation of complex hierarchies of flood reflectors and clients or allow multiple clusters in a single L1 area. Consequently, all flood reflectors and flood reflector clients in the same L1 area MUST share the same Flood Reflector Cluster ID. Deployment of multiple cluster IDs in the same L1 area are outside the scope of this document. A flood reflector MUST NOT form flood reflection adjacencies with flood reflector clients with a different Cluster ID. A flood reflector MUST NOT form any traditional L2 adjacencies. Flood reflector clients MUST NOT form flood reflection adjacencies with flood reflectors with a different Cluster ID. Flood reflector clients MAY form traditional L2 adjacencies with flood reflector clients or nodes not participating in flood reflection. When two flood reflector clients form a traditional L2 adjacency the Cluster IDs are disregarded. The Flood Reflector Cluster ID and flood reflector roles advertised in the Flood Reflection TLVs in IIHs are used to ensure that flood reflection adjacencies that are established meet the above criteria. On change in either flood reflection role or cluster ID on IIH on the local or remote side the adjacency has to be reset. It is then re- established if possible. Once a flood reflection adjacency is established, the flood reflector and the flood reflector client MUST advertise the adjacency by including the Flood Reflection Adjacency Sub-TLV in the Extended IS reachability TLV or MT-ISN TLV. 5. Route Computation To ensure loop-free routing, the flood reflection client MUST follow the normal L2 computation to determine L2 routes. This is because nodes outside the L1 area will generally not be aware that flood reflection is being performed. The flood reflection clients need to produce the same result for the L2 route computation as a router not participating in flood reflection. Przygienda, et al. Expires 8 June 2023 [Page 16] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 5.1. Tunnel-Based Deployment In the tunnel-based option the reflection client, after L2 and L1 computation, MUST examine all L2 routes with flood reflector next-hop adjacencies. Such next-hops must be replaced by the corresponding tunnel next-hops to the correct egress nodes of the flood reflection cluster. 5.2. No-Tunnel Deployment In case of deployment without underlying tunnels, the necessary L2 routes are distributed into the area, normally as L2->L1 routes. Due to the rules in Section 4.6 the computation in the resulting topology is relatively simple, the L2 SPF from a flood reflector client is guaranteed to reach the Flood Reflector within a single hop, and in the following hop the L2 egress to which it has a forwarding tunnel. All the flood reflector tunnel nexthops in the according L2 route can hence be removed and if the L2 route has no other ECMP L2 nexthops, the L2 route MUST be suppressed in the RIB by some means to allow the less preferred L2->L1 route to be used to forward traffic towards the advertising egress. In the particular case the client has L2 routes which are not flood reflected, those will be naturally preferred (such routes normally "hot-potato" packets out of the L1 area). However in the case the L2 route through the flood reflector egress is "shorter" than such present non flood reflected L2 routes, the node SHOULD ensure that such routes are suppressed so the L2->L1 towards the egress still takes preference. Observe that operationally this can be resolved in a relatively simple way by configuring flood reflector adjacencies to have a high metric, i.e. the flood reflector topology becomes "last resort" and the leaves will try to "hot-potato" out the area as fast as possible which is normally the desirable behavior. In No-tunnel deployment all L1/L2 edge nodes MUST be flood reflection clients. 6. Redistribution of Prefixes In case of no-tunnel deployment per Section 5.2 a client that does not have any L2 flood reflector adjacencies MUST NOT redistribute L2 routes into the cluster. The L2 prefix advertisements redistributed into an L1 that contains flood reflectors SHOULD be normally limited to L2 intra-area routes (as defined in [RFC7775]), if the information exists to distinguish them from other L2 prefix advertisements. Przygienda, et al. Expires 8 June 2023 [Page 17] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 On the other hand, in topologies that make use of flood reflection to hide the structure of L1 areas while still providing transit forwarding across them using tunnels, we generally do not need to redistribute L1 prefix advertisements into L2. 7. Special Considerations In pathological cases setting the overload bit in L1 (but not in L2) can partition L1 forwarding, while allowing L2 reachability through flood reflector adjacencies to exist. In such a case a node cannot replace a route through a flood reflector adjacency with a L1 shortcut and the client MAY use the L2 tunnel to the flood reflector for forwarding but in any case it MUST initiate an alarm and declare misconfiguration. A flood reflector with directly L2 attached prefixes should advertise those in L1 as well since based on preference of L1 routes the clients will not try to use the L2 flood reflector adjacency to route the packet towards them. A very unlikely corner case can occur when the flood reflector is reachable via L2 flood reflector adjacency (due to underlying L1 partition) exclusively, in which case the client can use the L2 tunnel to the flood reflector for forwarding towards those prefixes while it MUST initiate an alarm and declare misconfiguration. A flood reflector MUST NOT set the attached bit on its LSPs. In certain cases where reflectors are attached to same broadcast medium, and where some other L2 router, which is neither a flood reflector nor a flood reflector client (a "non-FR router"), attaches to the same broadcast medium, flooding between the reflectors in question might not succeed, potentially partitioning the flood reflection domain. This could happen specifically in the event that the non-FR router is chosen as the designated intermediate system ("DIS", the designated router). Since, per Section 4.6, a flood reflector MUST NOT form an adjacency with a non-FR router, the flood reflector(s) will not be represented in the pseudo-node. To avoid this situation, it is RECOMMENDED that flood reflectors not be deployed on the same broadcast medium as non-FR routers. A router discovering such condition MUST initiate an alarm and declare misconfiguration. 8. IANA Considerations This document requests allocation for the following IS-IS TLVs and Sub-TLVs, and requests creation of a new registry. Przygienda, et al. Expires 8 June 2023 [Page 18] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 8.1. New IS-IS TLV Codepoint This document requests the following IS-IS TLV under the IS-IS Top- Level TLV Codepoints registry:: Value Name IIH LSP SNP Purge ----- --------------------------------- --- --- --- ----- 161 Flood Reflection y n n n 8.2. Sub TLVs for IS-IS Router CAPABILITY TLV This document request the following registration in the "sub-TLVs for IS-IS Router CAPABILITY TLV" registry. Type Description ---- ----------- 161 Flood Reflection Discovery 8.3. Sub-sub TLVs for Flood Reflection Discovery sub-TLV This document requests creation of a new registry named "Sub-sub TLVs for Flood Reflection Discovery sub-TLV" under the "IS-IS TLV Codepoints" grouping. The Registration Procedures for this registry are Expert Review, following the common expert review guidance given for the grouping. The range of values in this registry is 0-255. The registry should be seeded with the following initial registration: Type Description ---- ----------- 161 Flood Reflection Discovery Tunnel Encapsulation Attribute 8.4. Sub TLVs for TLVs Advertising Neighbor Information This document requests the following registration in the "IS-IS Sub- TLVs for TLVs Advertising Neighbor Information" registry. Type Description 22 23 25 141 222 223 ---- -------------------------------- --- --- --- --- --- --- 161 Flood Reflector Adjacency y y n y y y Przygienda, et al. Expires 8 June 2023 [Page 19] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 9. Security Considerations This document uses flood reflection tunnels to carry IS-IS control traffic. If an attacker can inject traffic into such a tunnel, the consequences could be in the most extreme case the complete subversion of the IS-IS level 2 information. Therefore, a mechanism inherent to the tunnel technology should be taken to prevent such injection. Since the available security procedures will vary by deployment and tunnel type, the details of securing tunnels are beyond the scope of this document. This document specifies information used to form dynamically discovered shortcut tunnels. If an attacker were able to hijack the endpoint of such a tunnel and form an adjacency, it could divert short-cut traffic to itself, placing itself on-path and facilitating on-path attacks or could even completely subvert the IS-IS level 2 routing. Therefore, steps should be taken to prevent such capture by using mechanism inherent to the tunnel type used. Since the available security procedures will vary by deployment and tunnel type, the details of securing tunnels are beyond the scope of this document. Additionally, the usual IS-IS security mechanisms [RFC5304] SHOULD be deployed to prevent misrepresentation of routing information by an attacker in case a tunnel is compromised if the tunnel itself does not provide mechanisms strong enough guaranteeing the integrity of the messages exchanged. 10. Acknowledgements The authors thank Shraddha Hegde, Peter Psenak, Acee Lindem, Robert Raszuk and Les Ginsberg for their thorough review and detailed discussions. Thanks are also extended to Michael Richardson for an excellent routing directorate review. John Scudder ultimately spent significant time helping to make the document more comprehensible and coherent. 11. References 11.1. Informative References [ID.draft-ietf-idr-bgp-optimal-route-reflection-28] Raszuk et al., R., "BGP Optimal Route Reflection", July 2019, . Przygienda, et al. Expires 8 June 2023 [Page 20] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, . [RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF Topology-Transparent Zone", RFC 8099, DOI 10.17487/RFC8099, February 2017, . 11.2. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix Distribution with Two-Level IS-IS", RFC 5302, DOI 10.17487/RFC5302, October 2008, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [RFC7775] Ginsberg, L., Litkowski, S., and S. Previdi, "IS-IS Route Preference for Extended IP and IPv6 Reachability", RFC 7775, DOI 10.17487/RFC7775, February 2016, . [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Przygienda, et al. Expires 8 June 2023 [Page 21] Internet-Draft draft-ietf-lsr-isis-flood-reflection December 2022 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021, . Authors' Addresses Tony Przygienda (editor) Juniper 1137 Innovation Way Sunnyvale, CA United States of America Email: prz@juniper.net Chris Bowers Juniper 1137 Innovation Way Sunnyvale, CA United States of America Email: cbowers@juniper.net Yiu Lee Comcast 1800 Bishops Gate Blvd Mount Laurel, NJ 08054 United States of America Email: Yiu_Lee@comcast.com Alankar Sharma Individual Email: as3957@gmail.com Russ White Akamai Email: russ@riw.us Przygienda, et al. Expires 8 June 2023 [Page 22] ./draft-ietf-oauth-rar-22.txt0000644000764400076440000023265214351162125015564 0ustar iustiniustin Web Authorization Protocol T. Lodderstedt Internet-Draft yes.com Intended status: Standards Track J. Richer Expires: 25 June 2023 Bespoke Engineering B. Campbell Ping Identity 22 December 2022 OAuth 2.0 Rich Authorization Requests draft-ietf-oauth-rar-22 Abstract This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Lodderstedt, et al. Expires 25 June 2023 [Page 1] Internet-Draft oauth-rar December 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 2. Request parameter "authorization_details" . . . . . . . . . . 4 2.1. Authorization Details Types . . . . . . . . . . . . . . . 7 2.2. Common data fields . . . . . . . . . . . . . . . . . . . 8 3. Authorization Request . . . . . . . . . . . . . . . . . . . . 11 3.1. Relationship to "scope" parameter . . . . . . . . . . . . 13 3.2. Relationship to "resource" parameter . . . . . . . . . . 14 4. Authorization Response . . . . . . . . . . . . . . . . . . . 14 5. Authorization Error Response . . . . . . . . . . . . . . . . 14 6. Token Request . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Comparing authorization details . . . . . . . . . . . . . 15 7. Token Response . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Enriched authorization details in Token Response . . . . 19 8. Token Error Response . . . . . . . . . . . . . . . . . . . . 22 9. Resource Servers . . . . . . . . . . . . . . . . . . . . . . 23 9.1. JWT-based Access Tokens . . . . . . . . . . . . . . . . . 23 9.2. Token Introspection . . . . . . . . . . . . . . . . . . . 25 10. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Implementation Considerations . . . . . . . . . . . . . . . . 27 11.1. Using authorization details in a certain deployment . . 27 11.2. Minimal implementation support . . . . . . . . . . . . . 28 11.3. Use of Machine-readable Type Schemas . . . . . . . . . . 28 11.4. Large requests . . . . . . . . . . . . . . . . . . . . . 29 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 15.1. OAuth Parameters Registration . . . . . . . . . . . . . 31 15.2. JSON Web Token Claims Registration . . . . . . . . . . . 31 15.3. OAuth Token Introspection Response Registration . . . . 32 15.4. OAuth Authorization Server Metadata Registration . . . . 32 15.5. OAuth Dynamic Client Registration Metadata Registration . . . . . . . . . . . . . . . . . . . . . . 32 15.6. OAuth Extensions Error Registration . . . . . . . . . . 32 16. Normative References . . . . . . . . . . . . . . . . . . . . 33 17. Informative References . . . . . . . . . . . . . . . . . . . 33 Appendix A. Additional Examples . . . . . . . . . . . . . . . . 35 A.1. OpenID Connect . . . . . . . . . . . . . . . . . . . . . 35 A.2. Remote Electronic Signing . . . . . . . . . . . . . . . . 37 A.3. Access to Tax Data . . . . . . . . . . . . . . . . . . . 38 A.4. eHealth . . . . . . . . . . . . . . . . . . . . . . . . . 39 Appendix B. Document History . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Lodderstedt, et al. Expires 25 June 2023 [Page 2] Internet-Draft oauth-rar December 2022 1. Introduction The OAuth 2.0 authorization framework [RFC6749] defines the scope parameter that allows OAuth clients to specify the requested scope, i.e., the limited capability, of an access token. This mechanism is sufficient to implement static scenarios and coarse-grained authorization requests, such as "give me read access to the resource owner's profile" but it is not sufficient to specify fine-grained authorization requirements, such as "please let me transfer an amount of 45 Euros to Merchant A" or "please give me read access to directory A and write access to file X". This specification introduces a new parameter authorization_details that allows clients to specify their fine-grained authorization requirements using the expressiveness of JSON [RFC8259] data structures. For example, an authorization request for a credit transfer (designated as "payment initiation" in several open banking initiatives) can be represented using a JSON object like this: { "type": "payment_initiation", "locations": [ "https://example.com/payments" ], "instructedAmount": { "currency": "EUR", "amount": "123.50" }, "creditorName": "Merchant A", "creditorAccount": { "bic":"ABCIDEFFXXX", "iban": "DE02100100109307118603" }, "remittanceInformationUnstructured": "Ref Number Merchant" } Figure 1: Example authorization request for a credit transfer. This object contains detailed information about the intended payment, such as amount, currency, and creditor, that are required to inform the user and obtain their consent. The authorization server (AS) and the respective resource server (RS) (providing the payment initiation API) will together enforce this consent. Lodderstedt, et al. Expires 25 June 2023 [Page 3] Internet-Draft oauth-rar December 2022 For a comprehensive discussion of the challenges arising from new use cases in the open banking and electronic signing spaces see [transaction-authorization]. In addition to facilitating custom authorization requests, this specification also introduces a set of common data type fields for use across different APIs. 1.1. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This specification uses the terms "access token", "refresh token", "authorization server", "resource server", "authorization endpoint", "authorization request", "authorization response", "token endpoint", "grant type", "access token request", "access token response", and "client" defined by The OAuth 2.0 Authorization Framework [RFC6749]. 2. Request parameter "authorization_details" The request parameter authorization_details contains, in JSON notation, an array of objects. Each JSON object contains the data to specify the authorization requirements for a certain type of resource. The type of resource or access requirement is determined by the type field, which is defined as follows: type: An identifier for the authorization details type as a string. The value of the type field determines the allowable contents of the object which contains it and is unique for the described API in the context of the AS. This field is REQUIRED. An authorization_details array MAY contain multiple entries of the same type. This example shows an authorization_details of type payment_initiation using the example data shown above: Lodderstedt, et al. Expires 25 June 2023 [Page 4] Internet-Draft oauth-rar December 2022 [ { "type": "payment_initiation", "actions": [ "initiate", "status", "cancel" ], "locations": [ "https://example.com/payments" ], "instructedAmount": { "currency": "EUR", "amount": "123.50" }, "creditorName": "Merchant A", "creditorAccount": { "iban": "DE02100100109307118603" }, "remittanceInformationUnstructured": "Ref Number Merchant" } ] Figure 2: Example authorization_details for a credit transfer. This example shows a combined request asking for access to account information and permission to initiate a payment: Lodderstedt, et al. Expires 25 June 2023 [Page 5] Internet-Draft oauth-rar December 2022 [ { "type": "account_information", "actions": [ "list_accounts", "read_balances", "read_transactions" ], "locations": [ "https://example.com/accounts" ] }, { "type": "payment_initiation", "actions": [ "initiate", "status", "cancel" ], "locations": [ "https://example.com/payments" ], "instructedAmount": { "currency": "EUR", "amount": "123.50" }, "creditorName": "Merchant A", "creditorAccount": { "iban": "DE02100100109307118603" }, "remittanceInformationUnstructured": "Ref Number Merchant" } ] Figure 3: Example authorization_details for a combined request. The JSON objects with type fields of account_information and payment_initiation represent the different authorization_details to be used by the AS to ask for consent. Note: The AS will make this data subsequently available to the respective resource servers (see Section 9). Lodderstedt, et al. Expires 25 June 2023 [Page 6] Internet-Draft oauth-rar December 2022 2.1. Authorization Details Types Interpretation of the value of the type parameter, and the object fields that the type parameter allows, is under the control of the AS. However, the value of the type parameter is also generally documented and intended to be used by developers, it is RECOMMENDED that API designers choose type values that are easily copied without ambiguity. For example, some glyphs have multiple Unicode code points for the same visual character, and a developer could potentially type a different character than what the AS has defined. Possible means of reducing potential confusion are limiting the value to ASCII [RFC0020] characters, providing a machine-readable listing of data type values, or instructing developers to copy and paste directly from the documentation. If an application or API is expected to be deployed across different servers, such as the case in an open standard, the API designer is RECOMMENDED to use a collision-resistant namespace under their control, such as a URI that the API designer controls. The following example shows how an implementation could utilize the namespace https://scheme.example.org/ to ensure collision-resistant type values. { "type": "https://scheme.example.org/files", "locations": [ "https://example.com/files" ], "permissions": [ { "path": "/myfiles/A", "access": [ "read" ] }, { "path": "/myfiles/A/X", "access": [ "read", "write" ] } ] } Figure 4: Example for authorization_details with a URL as type identifier. Lodderstedt, et al. Expires 25 June 2023 [Page 7] Internet-Draft oauth-rar December 2022 2.2. Common data fields This specification defines a set of common data fields that are designed to be usable across different types of APIs. This specification does not require the use of these common fields by an API definition, but instead provides them as reusable generic components for API designers to make use of. The allowable values of all fields are determined by the API being protected, as defined by a particular "type" value. locations: An array of strings representing the location of the resource or resource server. These strings are typically URIs identifying the location of the RS. This field can allow a client to specify a particular RS, as discussed in Section 12. actions: An array of strings representing the kinds of actions to be taken at the resource. datatypes: An array of strings representing the kinds of data being requested from the resource. identifier: A string identifier indicating a specific resource available at the API. privileges: An array of strings representing the types or levels of privilege being requested at the resource. When different common data fields are used in combination, the permissions the client requests are the product of all the values. The object represents a request for all action values listed within the object to be used at all locations values listed within the object for all datatype values listed within the object. In the following example, the client is requesting read and write access to both the contacts and photos belonging to customers in a customer_information API. If this request is granted, the client would assume it would be able to use any combination of rights defined by the API, such as reading the photos and writing the contacts. Lodderstedt, et al. Expires 25 June 2023 [Page 8] Internet-Draft oauth-rar December 2022 [ { "type": "customer_information", "locations": [ "https://example.com/customers" ], "actions": [ "read", "write" ], "datatypes": [ "contacts", "photos" ] } ] Figure 5: Example for authorization_details with common data fields. If the client wishes to have finer control over its access, it can send multiple objects. In this example, the client is asking for read access to the contacts and write access to the photos in the same API endpoint. If this request is granted, the client would not be able to write to the contacts. Lodderstedt, et al. Expires 25 June 2023 [Page 9] Internet-Draft oauth-rar December 2022 [ { "type": "customer_information", "locations": [ "https://example.com/customers" ], "actions": [ "read" ], "datatypes": [ "contacts" ] }, { "type": "customer_information", "locations": [ "https://example.com/customers" ], "actions": [ "write" ], "datatypes": [ "photos" ] } ] Figure 6: Example for authorization_details with common data fields in multiple objects. An API MAY define its own extensions, subject to the type of the respective authorization object. It is anticipated that API designers will use a combination of common data fields defined in this specification as well as fields specific to the API itself. The following non-normative example shows the use of both common and API- specific fields as part of two different fictitious API type values. The first access request includes the actions, locations, and datatypes fields specified here as well as the API-specific geolocation field, indicating access to photos taken at the given coordinates. The second access request includes the actions and identifier fields specified here as well as the API-specific currency fields. Lodderstedt, et al. Expires 25 June 2023 [Page 10] Internet-Draft oauth-rar December 2022 [ { "type":"photo-api", "actions":[ "read", "write" ], "locations":[ "https://server.example.net/", "https://resource.local/other" ], "datatypes":[ "metadata", "images" ], "geolocation":[ { "lat":-32.364, "lng":153.207 }, { "lat":-35.364, "lng":158.207 } ] }, { "type":"financial-transaction", "actions":[ "withdraw" ], "identifier":"account-14-32-32-3", "currency":"USD" } ] Figure 7: Example for authorization_details using common and extension data fields. If this request is approved, the resulting access token's access rights will be the union of the requested types of access for each of the two APIs, just as above. 3. Authorization Request The authorization_details authorization request parameter can be used to specify authorization requirements in all places where the scope parameter is used for the same purpose, examples include: Lodderstedt, et al. Expires 25 June 2023 [Page 11] Internet-Draft oauth-rar December 2022 * Authorization requests as specified in [RFC6749], * Device Authorization Request as specified in [RFC8628], * Backchannel Authentication Requests as defined in [OpenID.CIBA]. In case of authorization requests as defined in [RFC6749], implementors MAY consider using pushed authorization requests [RFC9126] to improve the security, privacy, and reliability of the flow. See Section 12, Section 13, and Section 11.4 for details. Parameter encoding is determined by the respective context. In the context of an authorization request according to [RFC6749], the parameter is encoded using the application/x-www-form-urlencoded format of the serialized JSON as shown in the following using the example from Section 2 (line breaks for display purposes only): GET /authorize?response_type=code &client_id=s6BhdRkqt3 &state=af0ifjsldkj &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &code_challenge_method=S256 &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bwc-uCHaoeK1t8U &authorization_details=%5B%7B%22type%22%3A%22account%5Finfo rmation%22%2C%22actions%22%3A%5B%22list%5Faccounts%22%2C%22 read%5Fbalances%22%2C%22read%5Ftransactions%22%5D%2C%22loca tions%22%3A%5B%22https%3A%2F%2Fexample%2Ecom%2Faccounts%22% 5D%7D%2C%7B%22type%22%3A%22payment%5Finitiation%22%2C%22act ions%22%3A%5B%22initiate%22%2C%22status%22%2C%22cancel%22%5 D%2C%22locations%22%3A%5B%22https%3A%2F%2Fexample%2Ecom%2Fp ayments%22%5D%2C%22instructedAmount%22%3A%7B%22currency%22% 3A%22EUR%22%2C%22amount%22%3A%22123%2E50%22%7D%2C%22credito rName%22%3A%22Merchant%20A%22%2C%22creditorAccount%22%3A%7B% 22iban%22%3A%22DE02100100109307118603%22%7D%2C%22remittance InformationUnstructured%22%3A%22RefNumberMerchant%22%7D%5D HTTP/1.1 Host: server.example.com Figure 8: Example authorization request with authorization_details. Based on the data provided in the authorization_details parameter the AS will ask the user for consent to the requested access permissions. Note: the user may also grant a subset of the requested authorization details. In this example, the client wants to get access to account information and initiate a payment: Lodderstedt, et al. Expires 25 June 2023 [Page 12] Internet-Draft oauth-rar December 2022 [ { "type": "account_information", "actions": [ "list_accounts", "read_balances", "read_transactions" ], "locations": [ "https://example.com/accounts" ] }, { "type": "payment_initiation", "actions": [ "initiate", "status", "cancel" ], "locations": [ "https://example.com/payments" ], "instructedAmount": { "currency": "EUR", "amount": "123.50" }, "creditorName": "Merchant A", "creditorAccount": { "iban": "DE02100100109307118603" }, "remittanceInformationUnstructured": "Ref Number Merchant" } ] Figure 9: URL decoded authorization_details. 3.1. Relationship to "scope" parameter authorization_details and scope can be used in the same authorization request for carrying independent authorization requirements. Combined use of authorization_details and scope is supported by this specification in part to allow existing OAuth-based applications to incrementally migrate towards using authorization_details exclusively. It is RECOMMENDED that a given API use only one form of requirement specification. Lodderstedt, et al. Expires 25 June 2023 [Page 13] Internet-Draft oauth-rar December 2022 The AS MUST process both sets of requirements in combination with each other for the given authorization request. The details of how the AS combines these parameters are specific to the APIs being protected and outside the scope of this specification. When gathering user consent, the AS MUST present the merged set of requirements represented by the authorization request. If the resource owner grants the client the requested access, the AS will issue tokens to the client that are associated with the respective authorization_details (and scope values, if applicable). 3.2. Relationship to "resource" parameter The resource authorization request parameter as defined in [RFC8707] can be used to further determine the resources where the requested scope can be applied. The resource parameter does not have any impact on the way the AS processes the authorization_details authorization request parameter. 4. Authorization Response This specification does not define extensions to the authorization response. 5. Authorization Error Response The AS MUST refuse to process any unknown authorization details type or authorization details not conforming to the respective type definition. The AS MUST abort processing and respond with an error invalid_authorization_details to the client if any of the following are true of the objects in authorization_details structure: * Contains an unknown authorization details type value, * An object of known type but containing unknown fields, * Contains fields of the wrong type for the authorization details type, * Contains fields with invalid values for the authorization details type, or * Missing required fields for the authorization details type. Lodderstedt, et al. Expires 25 June 2023 [Page 14] Internet-Draft oauth-rar December 2022 6. Token Request The authorization_details token request parameter can be used to specify the authorization details a client wants the AS to assign to an access token. The AS checks whether the underlying grant (in case of grant types authorization_code, refresh_token, ...) or the client's policy (in case of grant type client_credential) allows the issuance of an access token with the requested authorization details. Otherwise, the AS refuses the request with the error code invalid_authorization_details (similar to invalid_scope). 6.1. Comparing authorization details Many actions in the OAuth protocol allow the AS and RS to make security decisions based on whether the request is asking for "more" or "less" than a previous, existing request. For example, upon refreshing a token, the client can ask for a new access token with "fewer permissions" than had been previously authorized by the resource owner. The requested access token will convey the reduced permissions but the resource owner's previous authorization is unchanged by such requests. Since the semantics of the fields in the authorization_details will be implementation specific to a given API or set of APIs, there is no standardized mechanism to compare two arbitrary authorization detail requests. Authorization servers should not rely on simple object comparison in most cases, as the intersection of some fields within a request could have side effects on the access rights granted, depending on how the API has been designed and deployed. This is a similar effect to the scope values used with some APIs. When comparing a new request to an existing request, authorization servers can use the same processing techniques as used in granting the request in the first place to determine if a resource owner needs to authorize the request. The details of this comparison are dependent on the definition of the type of authorization request and outside the scope of this specification, but common patterns can be applied. This shall be illustrated using our running example. The example authorization request in Section 3, if approved by the user, resulted in the issuance of an authorization code associated with the privileges to * list accounts * access the balance of one or more accounts, * access the transactions of one or more accounts, and * to initiate, check the status of, and cancel a payment. Lodderstedt, et al. Expires 25 June 2023 [Page 15] Internet-Draft oauth-rar December 2022 The client could now request the AS to issue an access token assigned with the privilege to just access a list of accounts as follows: [ { "type": "account_information", "actions": [ "list_accounts" ], "locations": [ "https://example.com/accounts" ] } ] Figure 10: Example for authorization_details reduced privileges. The example API is designed such that each field used by the account_information type contains additive rights, with each value within the actions and locations arrays specifying a different element of access. To make a comparison in this instance, the AS would perform the following steps: * compare that the authorization code issued in the previous step contains an authorization details object of type account_information * compare whether the approved list of actions contains list_account, and * whether the locations value includes only previously-approved locations. If all checks succeed, the AS would issue the requested access token with the reduced set of access. Note that this comparison is relevant to this specific API type definition. A different API type definition could have different processing rules. For example, the value of an action could subsume the rights associated with another action value. For example, if a client initially asks for a token with write access, which implies both read and write access to this API: Lodderstedt, et al. Expires 25 June 2023 [Page 16] Internet-Draft oauth-rar December 2022 [ { "type": "example_api", "actions": [ "write" ] } ] Figure 11: Example for authorization_details requesting "write" access to an API. Later that same client makes a refresh request for read access: [ { "type": "example_api", "actions": [ "read" ] } ] Figure 12: Example for authorization_details requesting "read" access to an API. The AS would compare the type value and the action value to determine that the read access is already covered by the write access previously granted to the client. This same API could be designed with a possible value for privileges of admin, used in this example to denote that the resulting token is allowed to perform any functions on the resources. If that client is then granted such admin privileges to the API: [ { "type": "example_api", "privileges": [ "admin" ] } ] Figure 13: Example for authorization_details requesting "admin" access to an API. Lodderstedt, et al. Expires 25 June 2023 [Page 17] Internet-Draft oauth-rar December 2022 The AS would compare the type value and find the privileges value subsumes any aspects of read or write access that had been granted to the client previously. Note that other API definitions can use privileges such that values do not subsume one another. The next example shows how the client can use the common data element locations (see Section 2.2) to request the issuance of an access token restricted to a certain resource server. In our running example, the client may ask for all permissions of the approved grant of type payment_iniation applicable to the resource server residing at https://example.com/payments as follows: [ { "type": "payment_initiation", "locations": [ "https://example.com/payments" ] } ] Figure 14: Example for authorization_details requesting an audience restricted access token. 7. Token Response In addition to the token response parameters as defined in [RFC6749], the authorization server MUST also return the authorization_details as granted by the resource owner and assigned to the respective access token. The authorization details assigned to the access token issued in a token response are determined by the authorization_details parameter of the corresponding token request. If the client does not specify the authorization_details token request parameters, the AS determines the resulting authorization_details at its discretion. The AS MAY omit values in the authorization_details to the client. For our running example, this would look like this: Lodderstedt, et al. Expires 25 June 2023 [Page 18] Internet-Draft oauth-rar December 2022 HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token": "2YotnFZFEjr1zCsicMWpAA", "token_type": "example", "expires_in": 3600, "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA", "authorization_details": [ { "type": "payment_initiation", "actions": [ "initiate", "status", "cancel" ], "locations": [ "https://example.com/payments" ], "instructedAmount": { "currency": "EUR", "amount": "123.50" }, "creditorName": "Merchant A", "creditorAccount": { "iban": "DE02100100109307118603" }, "remittanceInformationUnstructured": "Ref Number Merchant" } ] } Figure 15: Example token response. 7.1. Enriched authorization details in Token Response The authorization details attached to the access token MAY differ from what the client requests. In addition to the user authorizing less than what the client requested, there are some use cases where the authorization server enriches the data in an authorization details object. Whether enrichment is allowed and specifics of how it works are necessarily part of the definition of the respective authorization details type. As one example, a client may ask for access to account information but leave the decision about the specific accounts it will be able to access to the user. The user would, during the course of the Lodderstedt, et al. Expires 25 June 2023 [Page 19] Internet-Draft oauth-rar December 2022 authorization process, select the subset of their accounts that they want to allow the client to access. As one design option to convey the selected accounts, the authorization server could add this information to the respective authorization details object. In that example, the requested authorization detail parameter might look like the following. In this example the empty arrays serve as placeholders for where data will be added during enrichment by the AS. This example is illustrative only and is not intended to suggest a preference for designing the specifics of any authorization details type this way. "authorization_details": [ { "type": "account_information", "access": { "accounts": [], "balances": [], "transactions": [] }, "recurringIndicator":true } ] Figure 16: Example for requested authorization_details. The authorization server then would expand the authorization details object and add the respective account identifiers. Lodderstedt, et al. Expires 25 June 2023 [Page 20] Internet-Draft oauth-rar December 2022 HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JokF0XG5Qx2TlKWIA", "authorization_details":[ { "type":"account_information", "access":{ "accounts":[ { "iban":"DE2310010010123456789" }, { "maskedPan":"123456xxxxxx1234" } ], "balances":[ { "iban":"DE2310010010123456789" } ], "transactions":[ { "iban":"DE2310010010123456789" }, { "maskedPan":"123456xxxxxx1234" } ] }, "recurringIndicator":true } ] } Figure 17: Example for enriched authorization_details. For another example, the client is asking for access to a medical record but does not know the record number at request time. In this example, the client specifies the type of access it wants but doesn't specify the location or identifier of that access. Lodderstedt, et al. Expires 25 June 2023 [Page 21] Internet-Draft oauth-rar December 2022 { "authorization_details": [ { "type": "medical_record", "sens": [ "HIV", "ETH", "MART" ], "actions": [ "read" ], "datatypes": [ "Patient", "Observation", "Appointment" ] } ]} Figure 18: Example for requested authorization_details. When the user interacts with the AS, they select which of the medical records they are responsible for giving to the client. This information gets returned with the access token. { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JokF0XG5Qx2TlKWIA", "authorization_details":[ { "type": "medical_record", "sens": [ "HIV", "ETH", "MART" ], "actions": [ "read" ], "datatypes": [ "Patient", "Observation", "Appointment" ], "identifier": "patient-541235", "locations": [ "https://records.example.com/" ] } ] } Figure 19: Example for enriched authorization_details. Note: the client needs to be aware upfront of the possibility that a certain authorization details object can be enriched. It is assumed that this property is part of the definition of the respective authorization details type. 8. Token Error Response The Token Error Response MUST conform to the rules given in Section 5. Lodderstedt, et al. Expires 25 June 2023 [Page 22] Internet-Draft oauth-rar December 2022 9. Resource Servers In order to enable the RS to enforce the authorization details as approved in the authorization process, the AS MUST make this data available to the RS. The AS MAY add the authorization_details field to access tokens in JWT format or to Token Introspection responses. 9.1. JWT-based Access Tokens If the access token is a JWT [RFC7519], the AS is RECOMMENDED to add the authorization_details object, filtered to the specific audience, as a top-level claim. The AS will typically also add further claims to the JWT the RS requires for request processing, e.g., user id, roles, and transaction-specific data. What claims the particular RS requires is defined by the RS-specific policy with the AS. The following shows the contents of an example JWT for the payment initiation example above: Lodderstedt, et al. Expires 25 June 2023 [Page 23] Internet-Draft oauth-rar December 2022 { "iss": "https://as.example.com", "sub": "24400320", "aud": "a7AfcPcsl2", "exp": 1311281970, "acr": "psd2_sca", "txn": "8b4729cc-32e4-4370-8cf0-5796154d1296", "authorization_details": [ { "type": "https://scheme.example.com/payment_initiation", "actions": [ "initiate", "status", "cancel" ], "locations": [ "https://example.com/payments" ], "instructedAmount": { "currency": "EUR", "amount": "123.50" }, "creditorName": "Merchant A", "creditorAccount": { "iban": "DE02100100109307118603" }, "remittanceInformationUnstructured": "Ref Number Merchant" } ], "debtorAccount": { "iban": "DE40100100103307118608", "user_role": "owner" } } Figure 20: Example for authorization_details in JWT-based access token. In this case, the AS added the following example claims to the JWT- based access token: * sub: conveys the user on which behalf the client is asking for payment initiation * txn: transaction id used to trace the transaction across the services of provider example.com * debtorAccount: API-specific field containing the debtor account. In the example, this account was not passed in the authorization_details but selected by the user during the Lodderstedt, et al. Expires 25 June 2023 [Page 24] Internet-Draft oauth-rar December 2022 authorization process. The field user_role conveys the role the user has with respect to this particular account. In this case, they are the owner. This data is used for access control at the payment API (the RS). 9.2. Token Introspection Token introspection [RFC7662] provides a means for an RS to query the AS to determine information about an access token. If the AS includes authorization detail information for the token in its response, the information MUST be conveyed with authorization_details as a top-level member of the introspection response JSON object. The authorization_details member MUST contain the same structure defined in Section 2, potentially filtered and extended for the RS making the introspection request. Here is an example introspection response for the payment initiation example: Lodderstedt, et al. Expires 25 June 2023 [Page 25] Internet-Draft oauth-rar December 2022 { "active": true, "sub": "24400320", "aud": "s6BhdRkqt3", "exp": 1311281970, "acr": "psd2_sca", "txn": "8b4729cc-32e4-4370-8cf0-5796154d1296", "authorization_details": [ { "type": "https://scheme.example.com/payment_initiation", "actions": [ "initiate", "status", "cancel" ], "locations": [ "https://example.com/payments" ], "instructedAmount": { "currency": "EUR", "amount": "123.50" }, "creditorName": "Merchant123", "creditorAccount": { "iban": "DE02100100109307118603" }, "remittanceInformationUnstructured": "Ref Number Merchant" } ], "debtorAccount": { "iban": "DE40100100103307118608", "user_role": "owner" } } Figure 21: Example for authorization_details in introspection response. 10. Metadata To advertise its support for this feature, the supported list of authorization details types is included in the AS metadata response [RFC8414] using the metadata parameter authorization_details_types_supported, which is a JSON array. This is illustrated by the following example: Lodderstedt, et al. Expires 25 June 2023 [Page 26] Internet-Draft oauth-rar December 2022 { ... "authorization_details_types_supported":[ "payment_initiation", "account_information" ] } Figure 22: Example for server metadata about the supported authorization details. Clients MAY indicate the authorization details types they will use when requesting authorization with the client registration metadata parameter authorization_details_types, which is a JSON array. This is illustrated by the following example: { ... "authorization_details_types":[ "payment_initiation" ] } Figure 23: Example for server metadata about authorization details. The registration of authorization details types with the AS is out of scope of this specification. 11. Implementation Considerations 11.1. Using authorization details in a certain deployment Using authorization details in a certain deployment will require the following steps: * Define authorization details types * Publish authorization details types in the OAuth server metadata * Determine how authorization details are shown to the user in the user consent prompt * (if needed) Enrich authorization details in the user consent process (e.g. add selected accounts or set expirations) * (if needed) Determine how authorization details are reflected in access token content or introspection responses * Determine how the resource server(s) process(s) the authorization details or token data derived from authorization details * (if needed) Entitle clients to use certain authorization details types Lodderstedt, et al. Expires 25 June 2023 [Page 27] Internet-Draft oauth-rar December 2022 11.2. Minimal implementation support General authorization server implementations supporting this specification should provide the following basic functions: * Support advertisement of supported authorization details types in OAuth server metadata * Accept authorization_details parameter in authorization requests in conformance with this specification * Support storage of consented authorization details as part of a grant * Implement default behavior for adding authorization details to access tokens and token introspection responses in order to make them available to resource servers (similar to scope values). This should work with any grant type, especially authorization_code and refresh_token. Processing and presentation of authorization details will vary significantly among different authorization details types. Implementations should therefore support customization of the respective behavior. In particular, implementations should: * allow deployments to determine presentation of the authorization details * allow deployments to modify requested authorization details in the user consent process, e.g. adding fields * allow deployments to merge requested and pre-existing authorization details One approach to supporting such customization would be to have a mechanism allowing the registration of extension modules, each of them responsible for rendering the respective user consent and any transformation needed to provide the data needed to the resource server by way of structured access tokens or token introspection responses. 11.3. Use of Machine-readable Type Schemas Implementations might allow deployments to use machine-readable schema languages for defining authorization details types to facilitate creating and validating authorization details objects against such schemas. For example, if an authorization details type were defined using JSON Schemas [JSON.Schema], the JSON Schema identifier could be used as type value in the respective authorization details objects. Lodderstedt, et al. Expires 25 June 2023 [Page 28] Internet-Draft oauth-rar December 2022 Note however that type values are identifiers understood by the AS and, to the extent necessary, the client and RS. This specification makes no assumption that a type value point to a machine-readable schema format, or that any party in the system (such as the client, AS, or RS) dereference or process the contents of the type field in any specific way. 11.4. Large requests Authorization request URIs containing authorization_details in a request parameter or a request object can become very long. Implementers should therefore consider using the request_uri parameter as defined in [RFC9101] in combination with the pushed request object mechanism as defined in [RFC9126] to pass authorization_details in a reliable and secure manner. Here is an example of such a pushed authorization request that sends the authorization request data directly to the AS via an HTTPS-protected connection: POST /as/par HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 response_type=code& client_id=s6BhdRkqt3 &state=af0ifjsldkj &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &code_challenge_method=S256 &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bwc-uCHaoeK1t8U &authorization_details=%5B%7B%22type%22%3A%22account_information%22 %2C%22actions%22%3A%5B%22list_accounts%22%2C%22read_balances%22%2C% 22read_transactions%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fe xample.com%2Faccounts%22%5D%7D%2C%7B%22type%22%3A%22payment_initiat ion%22%2C%22actions%22%3A%5B%22initiate%22%2C%22status%22%2C%22canc el%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fexample.com%2Fpaym ents%22%5D%2C%22instructedAmount%22%3A%7B%22currency%22%3A%22EUR%22 %2C%22amount%22%3A%22123.50%22%7D%2C%22creditorName%22%3A%22Merchan t123%22%2C%22creditorAccount%22%3A%7B%22iban%22%3A%22DE021001001093 07118603%22%7D%2C%22remittanceInformationUnstructured%22%3A%22Ref%2 0Number%20Merchant%22%7D%5D Figure 24: Example for large request including authorization_details. Lodderstedt, et al. Expires 25 June 2023 [Page 29] Internet-Draft oauth-rar December 2022 12. Security Considerations The authorization_details parameter is sent through the user agent in case of an OAuth authorization request, which makes them vulnerable to modifications by the user. If integrity of the authorization_details is a concern, clients MUST protect authorization_details against tampering and swapping. This can be achieved by signing the request using signed request objects as defined in [RFC9101] or using the request_uri authorization request parameter as defined in [RFC9101] in conjunction with [RFC9126] to pass the URI of the request object to the authorization server. All string comparisons in an authorization_details parameter are to be done as defined by [RFC8259]. No additional transformation or normalization is to be done in evaluating equivalence of string values. The common data field locations allows a client to specify where it intends to use a certain authorization, i.e., it is possible to unambiguously assign permissions to resource servers. In situations with multiple resource servers, this prevents unintended client authorizations (e.g. a read scope value potentially applicable for an email as well as a cloud service) through audience restriction. The AS MUST properly sanitized and handle the data passed in the authorization_details in order to prevent injection attacks. The Security Considerations of [RFC6749], [RFC7662], and [RFC8414] also apply. 13. Privacy Considerations It is especially important for implementers to design and use authorization details in a privacy-preserving manner. Any sensitive personal data included in authorization_details must be prevented from leaking, e.g., through referrer headers. Implementation options include encrypted request objects as defined in [RFC9101] or transmission of authorization_details via end-to-end encrypted connections between client and authorization server by utilizing [RFC9126] and the request_uri authorization request parameter as defined in [RFC9101]. The latter does not require application level encryption but it requires another message exchange between client and AS. Even if the request data is encrypted, an attacker could use the authorization server to learn the user's data by injecting the encrypted request data into an authorization request on a device Lodderstedt, et al. Expires 25 June 2023 [Page 30] Internet-Draft oauth-rar December 2022 under their control and use the authorization server's user consent screens to show the (decrypted) user data in the clear. Implementations need to consider this attack vector and implement appropriate countermeasures, e.g. by only showing portions of the data or, if possible, determining whether the assumed user context is still the same (after user authentication). The AS needs to take into consideration the privacy implications when sharing authorization_details with the client or resource servers. The AS should share this data with those parties on a "need to know" basis as determined by local policy. 14. Acknowledgements We would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback during the preparation of this specification. We would also like to thank Vladimir Dzhuvinov, Takahiko Kawasaki, Daniel Fett, Dave Tonge, Travis Spencer, Joergen Binningsboe, Aamund Bremer, Steinar Noem, Francis Pouatcha, Jacob Ideskog, Hannes Tschofenig, and Aaron Parecki for their valuable feedback to this specification. 15. IANA Considerations 15.1. OAuth Parameters Registration This specification requests registration of the following parameter in the "OAuth Parameters" registry [IANA.OAuth.Parameters] established by [RFC6749]. Name: authorization_details Parameter Usage Location: authorization request, token request, token response Change Controller: IETF Specification Document(s): [[ this document ]] 15.2. JSON Web Token Claims Registration This specification requests registration of the following value in the IANA "JSON Web Token Claims" registry established by [RFC7519]. Claim Name: authorization_details Claim Description: The claim authorization_details contains a JSON array of JSON objects representing the rights of the access token. Each JSON object contains the data to specify the authorization requirements for a certain type of resource. Lodderstedt, et al. Expires 25 June 2023 [Page 31] Internet-Draft oauth-rar December 2022 Change Controller: IETF Specification Document(s): Section 9.1 of [[ this document ]] 15.3. OAuth Token Introspection Response Registration This specification requests registration of the following value in the IANA "OAuth Token Introspection Response" registry established by [RFC7662]. Name: authorization_details Description: The member authorization_details contains a JSON array of JSON objects representing the rights of the access token. Each JSON object contains the data to specify the authorization requirements for a certain type of resource. Change Controller: IETF Specification Document(s): Section 9.2 of [[ this document ]] 15.4. OAuth Authorization Server Metadata Registration This specification requests registration of the following values in the IANA "OAuth Authorization Server Metadata" registry of [IANA.OAuth.Parameters] established by [RFC8414]. Metadata Name: authorization_details_types_supported Metadata Description: JSON array containing the authorization details types the AS supports Change Controller: IETF Specification Document(s): Section 10 of [[ this document ]] 15.5. OAuth Dynamic Client Registration Metadata Registration This specification requests registration of the following value in the IANA "OAuth Dynamic Client Registration Metadata" registry of [IANA.OAuth.Parameters] established by [RFC7591]. Metadata Name: authorization_details_types Metadata Description: Indicates what authorization details types the client uses. Change Controller: IETF Specification Document(s): Section 10 of [[ this document ]] 15.6. OAuth Extensions Error Registration This specification requests registration of the following value in the IANA "OAuth Extensions Error" registry of [IANA.OAuth.Parameters] established by [RFC6749]. Error name: invalid_authorization_details Lodderstedt, et al. Expires 25 June 2023 [Page 32] Internet-Draft oauth-rar December 2022 Error usage location: token endpoint, authorization endpoint Related protocol extension: OAuth 2.0 Rich Authorization Requests Change Controller: IETF Reference: Section 5 of [[ this document ]] 16. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, August 2019, . [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, . 17. Informative References [CSC] Consortium, C. S., "Architectures and protocols for remote signature applications", 1 June 2019, . [ETSI] ETSI, "ETSI TS 119 432, Electronic Signatures and Infrastructures (ESI); Protocols for remote digital signature creation", 20 March 2019, Lodderstedt, et al. Expires 25 June 2023 [Page 33] Internet-Draft oauth-rar December 2022 . [IANA.OAuth.Parameters] IANA, "OAuth Parameters", . [JSON.Schema] json-schema.org, "JSON Schema", . [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 1", 8 November 2014, . [OpenID.CIBA] Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B. Campbell, "OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0", 16 January 2019, . [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC9101] Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021, . Lodderstedt, et al. Expires 25 June 2023 [Page 34] Internet-Draft oauth-rar December 2022 [RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, . [transaction-authorization] Lodderstedt, T., "Transaction Authorization or why we need to re-think OAuth scopes", 20 April 2019, . Appendix A. Additional Examples A.1. OpenID Connect OpenID Connect [OIDC] specifies the JSON-based claims request parameter that can be used to specify the claims a client (acting as OpenID Connect Relying Party) wishes to receive in a fine-grained and privacy-preserving way as well as assign those claims to certain delivery mechanisms, i.e. ID Token or userinfo response. The combination of the scope value openid and the additional parameter claims can be used beside authorization_details in the same way as every non-OIDC scope value. Alternatively, there could be an authorization details type for OpenID Connect. This section gives an example of what such an authorization details type could look like, but defining this authorization details type is outside the scope of this specification. These hypothetical examples try to encapsulate all details specific to the OpenID Connect part of an authorization process into an authorization JSON object. The top-level field are based on the definitions given in [OIDC]: * claim_sets: names of predefined claim sets, replacement for respective scope values, such as profile * max_age: Maximum Authentication Age * acr_values: requested Authentication Context Class Reference (ACR) values. * claims: the claims JSON structure as defined in [OIDC] This is a simple request for some claim sets. Lodderstedt, et al. Expires 25 June 2023 [Page 35] Internet-Draft oauth-rar December 2022 [ { "type": "openid", "locations": [ "https://op.example.com/userinfo" ], "claim_sets": [ "email", "profile" ] } ] Figure 25: Example for OpenID Connect request utilizing authorization_details. Note: locations specifies the location of the userinfo endpoint since this is the only place where an access token is used by a client (RP) in OpenID Connect to obtain claims. A more sophisticated example is shown in the following Lodderstedt, et al. Expires 25 June 2023 [Page 36] Internet-Draft oauth-rar December 2022 [ { "type": "openid", "locations": [ "https://op.example.com/userinfo" ], "max_age": 86400, "acr_values": "urn:mace:incommon:iap:silver", "claims": { "userinfo": { "given_name": { "essential": true }, "nickname": null, "email": { "essential": true }, "email_verified": { "essential": true }, "picture": null, "http://example.com/claims/groups": null }, "id_token": { "auth_time": { "essential": true } } } } ] Figure 26: Advanced example for OpenID Connect request utilizing authorization_details. A.2. Remote Electronic Signing The following example is based on the concept laid out for remote electronic signing in ETSI TS 119 432 [ETSI] and the CSC API for remote signature creation [CSC]. Lodderstedt, et al. Expires 25 June 2023 [Page 37] Internet-Draft oauth-rar December 2022 [ { "type": "sign", "locations": [ "https://signing.example.com/signdoc" ], "credentialID": "60916d31-932e-4820-ba82-1fcead1c9ea3", "documentDigests": [ { "hash": "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=", "label": "Credit Contract" }, { "hash": "HZQzZmMAIWekfGH0/ZKW1nsdt0xg3H6bZYztgsMTLw0=", "label": "Contract Payment Protection Insurance" } ], "hashAlgorithmOID": "2.16.840.1.101.3.4.2.1" } ] Figure 27: Example for electronic signing. The top-level fields have the following meaning: * credentialID: identifier of the certificate to be used for signing * documentDigests: array containing the hash of every document to be signed (hash fields). Additionally, the corresponding label field identifies the respective document to the user, e.g. to be used in user consent. * hashAlgorithm: algorithm that was used to calculate the hash values. The AS is supposed to ask the user for consent for the creation of signatures for the documents listed in the structure. The client uses the access token issued as a result of the process to call the sign doc endpoint at the respective signing service to actually create the signature. This access token is bound to the client, the user id and the hashes (and signature algorithm) as consented by the user. A.3. Access to Tax Data This example is inspired by an API allowing third parties to access citizen's tax declarations and income statements, for example, to determine their creditworthiness. Lodderstedt, et al. Expires 25 June 2023 [Page 38] Internet-Draft oauth-rar December 2022 [ { "type": "tax_data", "locations": [ "https://taxservice.govehub.no.example.com" ], "actions":"read_tax_declaration", "periods": ["2018"], "duration_of_access": 30, "tax_payer_id": "23674185438934" } ] Figure 28: Example for tax data access. The top-level fields have the following meaning: * periods: determines the periods the client wants to access * duration_of_access: how long does the client intend to access the data in days * tax_payer_id: identifier of the taxpayer (if known to the client) A.4. eHealth These two examples are inspired by requirements for APIs used in the Norwegian eHealth system. In this use case, the physical therapist sits in front of their computer using a local Electronic Health Records (EHR) system. They want to look at the electronic patient records of a certain patient and they also want to fetch the patients journal entries in another system, perhaps at another institution or a national service. Access to this data is provided by an API. The information necessary to authorize the request at the API is only known by the EHR system, and must be presented to the API. In the first example, the authorization details object contains the identifier of an organization. In this case, the API needs to know if the given organization has the lawful basis for processing personal health information to give access to sensitive data. Lodderstedt, et al. Expires 25 June 2023 [Page 39] Internet-Draft oauth-rar December 2022 "authorization_details": { "type": "patient_record", "requesting_entity": { "type": "Practitioner", "identifier": [ { "system": "urn:oid:2.16.578.1.12.4.1.4.4", "value": "1234567" }], "practitioner_role": { "organization": { "identifier": { "system": "urn:oid:2.16.578.1.12.4.1.2.101", "type": "ENH", "value": "[organizational number]" } } } } } Figure 29: eHealth Example. In the second example, the API requires more information to authorize the request. In this case, the authorization details object contains additional information about the health institution and the current profession the user has at the time of the request. The additional level of detail could be used for both authorization and data minimization. [ { "type": "patient_record", "location": "https://fhir.example.com/patient", "actions": [ "read" ], "patient_identifier": [ { "system": "urn:oid:2.16.578.1.12.4.1.4.1", "value": "12345678901" } ], "reason_for_request": "Clinical treatment", "requesting_entity": { "type": "Practitioner", "identifier": [ { Lodderstedt, et al. Expires 25 June 2023 [Page 40] Internet-Draft oauth-rar December 2022 "system": "urn:oid:2.16.578.1.12.4.1.4.4", "value": "1234567" } ], "practitioner_role": { "organization": { "identifier": [ { "system": "urn:oid:2.16.578.1.12.4.1.2.101", "type": "ENH", "value": "" } ], "type": { "coding": [ { "system": "http://hl7.example.org/fhir/org-type", "code": "dept", "display": "Hospital Department" } ] }, "name": "Akuttmottak" }, "profession": { "coding": [ { "system": "http://snomed.example.org/sct", "code": "36682004", "display": "Physical therapist" } ] } } } } ] Figure 30: Advanced eHealth example. Description of the fields: * patient_identifier: the identifier of the patient composed of a system identifier in OID format (namespace) and the actual value within this namespace. * reason_for_request: the reason why the user wants to access a certain API Lodderstedt, et al. Expires 25 June 2023 [Page 41] Internet-Draft oauth-rar December 2022 * requesting_entity: specification of the requester by means of identity, role and organizational context. This data is provided to facilitate authorization and for auditing purposes. In this use case, the AS authenticates the requester, who is not the patient, and approves access based on policies. Appendix B. Document History [[ To be removed from the final specification ]] -22 * Add clarifying language around the geolocation example and Section 6.1 per Paul Wouters' ballot comment -21 * incorporated feedback from Robert Wilton and É (U+00C9)ric Vyncke -20 * incorporated feedback from Murray Kucherawy -19 * incorporated feedback from Lars Eggert -18 * IANA Considerations cleanup -17 * incorporated feedback from Genart review -16 * incorporated feedback from Sec Dir review -15 * Editorial updates from Roman Danyliw's AD review * Other editorial updates -14 * Added clarification regarding authorization details types matching Lodderstedt, et al. Expires 25 June 2023 [Page 42] Internet-Draft oauth-rar December 2022 * Removed duplicate text on use of "scope" and "resource" parameters alongside "authorization_details" * Replaced duplicate error response description in Section 8 with reference to Section 5 -13 * Editorial updates from Roman Danyliw's AD review * Removed normative language from field definitions. -12 * Clarify introspection response. * Editorial updates -11 * Updated IANA registrations adding authorization_details parameter -10 * Updated IANA registrations -09 * Incorporated feedback by Hannes as document shepherd -08 * formatting in authorization details type section * added example for privileges common data element -07 * incorporated review feedback from WGLC * fixed wording in token introspection section * added privacy considerations re authorization details in token response -06 * removed use of resource indicators to filter authorization details in token response -05 * added authorization_details token request parameter and discussion on authorization details comparison Lodderstedt, et al. Expires 25 June 2023 [Page 43] Internet-Draft oauth-rar December 2022 * added privileges field to authorization details (to align with GNAP) * added IANA text and changed metadata parameter names * added text about use of machine-readable type schemas, e.g. JSON Schema * added text on how authorization details are determined for access token issued with token response * added token error response and further error conditions to authorization error response -04 * restructured draft for better readability * simplified normative text about use of the resource parameter with authorization_details * added implementation considerations for deployments and products * added type union language from GNAP * added recommendation to use PAR to cope with large requests and for request protection -03 * Updated references to current revisions or RFC numbers * Added section about enrichment of authorization details objects by the AS * Clarified processing of unknown authorization details parameters * clarified dependencies between resource and authorization_details parameters -02 * Clarify "type" parameter processing -01 * Minor fix-up in a few examples -00 (WG draft) * initial WG revision -03 * Reworked examples to illustrate privacy preserving use of authorization_details * Added text on audience restriction * Added description of relationship between scope and authorization_details Lodderstedt, et al. Expires 25 June 2023 [Page 44] Internet-Draft oauth-rar December 2022 * Added text on token request & response and authorization_details * Added text on how authorization details are conveyed to RSs by JWTs or token introspection endpoint response * Added description of relationship between claims and authorization_details * Added more example from different sectors * Clarified string comparison to be byte-exact without collation -02 * Added Security Considerations * Added Privacy Considerations * Added notes on URI size and authorization details * Added requirement to return the effective authorization details granted by the resource owner in the token response * changed authorization_details structure from object to array * added Justin Richer & Brian Campbell as Co-Authors -00 / -01 * first draft Authors' Addresses Torsten Lodderstedt yes.com Email: torsten@lodderstedt.net Justin Richer Bespoke Engineering Email: ietf@justin.richer.org Brian Campbell Ping Identity Email: bcampbell@pingidentity.com Lodderstedt, et al. Expires 25 June 2023 [Page 45] ./draft-ietf-lsr-isis-rfc5316bis-07.txt0000644000764400076440000014303414315050767017222 0ustar iustiniustin Internet Engineering Task Force M. Chen Internet-Draft Huawei Obsoletes: 5316 (if approved) L. Ginsberg Intended status: Standards Track Cisco Systems Expires: 1 April 2023 S. Previdi Huawei Technologies D. Xiaodong China Mobile 28 September 2022 IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering draft-ietf-lsr-isis-rfc5316bis-07 Abstract This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASs). It defines IS-IS extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. This document builds on RFC 5316 by adding support for IPv6-only operation. This document obsoletes RFC 5316. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Chen, et al. Expires 1 April 2023 [Page 1] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2.1. A Note on Non-Objectives . . . . . . . . . . . . . . . . 4 2.2. Per-Domain Path Determination . . . . . . . . . . . . . . 5 2.3. Backward Recursive Path Computation . . . . . . . . . . . 6 3. Extensions to ISIS-TE . . . . . . . . . . . . . . . . . . . . 7 3.1. Choosing the TE Router ID Value . . . . . . . . . . . . . 8 3.2. Inter-AS Reachability TLV . . . . . . . . . . . . . . . . 9 3.3. TE Router ID . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Sub-TLVs for Inter-AS Reachability TLV . . . . . . . . . 11 3.4.1. Remote AS Number Sub-TLV . . . . . . . . . . . . . . 11 3.4.2. IPv4 Remote ASBR ID Sub-TLV . . . . . . . . . . . . . 12 3.4.3. IPv6 Remote ASBR ID Sub-TLV . . . . . . . . . . . . . 12 3.4.4. IPv6 Local ASBR ID sub-TLV . . . . . . . . . . . . . 13 3.5. Sub-TLVs for IS-IS Router Capability TLV . . . . . . . . 14 3.5.1. IPv4 TE Router ID sub-TLV . . . . . . . . . . . . . . 14 3.5.2. IPv6 TE Router ID sub-TLV . . . . . . . . . . . . . . 14 4. Procedure for Inter-AS TE Links . . . . . . . . . . . . . . . 15 4.1. Origin of Proxied TE Information . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 Chen, et al. Expires 1 April 2023 [Page 2] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6.1. Inter-AS Reachability TLV . . . . . . . . . . . . . . . . 17 6.2. Sub-TLVs for the Inter-AS Reachability TLV . . . . . . . 18 6.3. Sub-TLVs for the IS-IS Router Capability TLV . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. Changes to RFC 5316 . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction [RFC5305] defines extensions to the IS-IS protocol [RFC1195] to support intra-area Traffic Engineering (TE). The extensions provide a way of encoding the TE information for TE-enabled links within the network (TE links) and flooding this information within an area. The extended IS reachability TLV and traffic engineering router ID TLV, which are defined in [RFC5305], are used to carry such TE information. The extended IS reachability TLV has several nested sub-TLVs that describe the TE attributes for a TE link. [RFC6119] and [RFC5307] define similar extensions to IS-IS in support of IPv6 and Generalized Multiprotocol Label Switching (GMPLS) TE respectively. Requirements for establishing Multiprotocol Label Switching (MPLS) TE Label Switched Paths (LSPs) that cross multiple Autonomous Systems (ASes) are described in [RFC4216]. As described in [RFC4216], a method SHOULD provide the ability to compute a path spanning multiple ASes. So a path computation entity that may be the head-end Label Switching Router (LSR), an AS Border Router (ASBR), or a Path Computation Element (PCE) [RFC4655] needs to know the TE information not only of the links within an AS, but also of the links that connect to other ASes. In this document, a new TLV, which is referred to as the inter-AS reachability TLV, is defined to advertise inter-AS TE information, and three new sub-TLVs are defined for inclusion in the inter-AS reachability TLV to carry the information about the remote AS number and remote ASBR ID. The sub-TLVs defined in [RFC5305][RFC6119] and other documents for inclusion in the extended IS reachability TLV for describing the TE properties of a TE link are applicable to be included in the Inter-AS Reachability TLV for describing the TE properties of an inter-AS TE link as well. Also, two more new sub- TLVs are defined for inclusion in the IS-IS router capability TLV to carry the TE Router ID when the TE Router ID is needed to reach all routers within an entire IS-IS routing domain. The extensions are Chen, et al. Expires 1 April 2023 [Page 3] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 equally applicable to IPv4 and IPv6 as identical extensions to [RFC5305] and [RFC6119]. Detailed definitions and procedures are discussed in the following sections. This document does not propose or define any mechanisms to advertise any other extra-AS TE information within IS-IS. See Section 2.1 for a full list of non-objectives for this work. 2. Problem Statement As described in [RFC4216], in the case of establishing an inter-AS TE LSP that traverses multiple ASes, the Path message [RFC3209] may include the following elements in the Explicit Route Object (ERO) in order to describe the path of the LSP: * a set of AS numbers as loose hops; and/or * a set of LSRs including ASBRs as loose hops. Two methods for determining inter-AS paths have been described elsewhere. The per-domain method [RFC5152] determines the path one domain at a time. The backward recursive method [RFC5441] uses cooperation between PCEs to determine an optimum inter-domain path. The sections that follow examine how inter-AS TE link information could be useful in both cases. 2.1. A Note on Non-Objectives It is important to note that this document does not make any change to the confidentiality and scaling assumptions surrounding the use of ASes in the Internet. In particular, this document is conformant to the requirements set out in [RFC4216]. The following features are explicitly excluded: * There is no attempt to distribute TE information from within one AS to another AS. * There is no mechanism proposed to distribute any form of TE reachability information for destinations outside the AS. * There is no proposed change to the PCE architecture or usage. * TE aggregation is not supported or recommended. * There is no exchange of private information between ASes. * No IS-IS adjacencies are formed on the inter-AS link. Chen, et al. Expires 1 April 2023 [Page 4] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 2.2. Per-Domain Path Determination In the per-domain method of determining an inter-AS path for an MPLS- TE LSP, when an LSR that is an entry-point to an AS receives a Path message from an upstream AS with an ERO containing a next hop that is an AS number, it needs to find which LSRs (ASBRs) within the local AS are connected to the downstream AS. That way, it can compute a TE LSP segment across the local AS to one of those LSRs and forward the Path message to that LSR and hence into the next AS. See Figure 1 for an example. R1------R3----R5-----R7------R9-----R11 | | \ | / | | | \ | ---- | | | \ | / | R2------R4----R6 --R8------R10----R12 : : <-- AS1 -->:<---- AS2 --->:<--- AS3 ---> Figure 1: Inter-AS Reference Model The figure shows three ASes (AS1, AS2, and AS3) and twelve LSRs (R1 through R12). R3 and R4 are ASBRs in AS1. R5, R6, R7, and R8 are ASBRs in AS2. R9 and R10 are ASBRs in AS3. If an inter-AS TE LSP is planned to be established from R1 to R12, the AS sequence will be: AS1, AS2, AS3. Suppose that the Path message enters AS2 from R3. The next hop in the ERO shows AS3, and R5 must determine a path segment across AS2 to reach AS3. It has a choice of three exit points from AS2 (R6, R7, and R8), and it needs to know which of these provide TE connectivity to AS3, and whether the TE connectivity (for example, available bandwidth) is adequate for the requested LSP. Alternatively, if the next hop in the ERO is an entry ASBR for AS3 (say R9), R5 needs to know which of its exit ASBRs has a TE link that connects to R9. Since there may be multiple ASBRs that are connected to R9 (both R7 and R8 in this example), R5 also needs to know the TE properties of the inter-AS TE links so that it can select the correct exit ASBR. Once the Path message reaches the exit ASBR, any choice of inter-AS TE link can be made by the ASBR if not already made by the entry ASBR that computed the segment. More details can be found in Section 4 of [RFC5152], which clearly points out why advertising of inter-AS links is desired. Chen, et al. Expires 1 April 2023 [Page 5] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 To enable R5 to make the correct choice of exit ASBR, the following information is needed: * List of all inter-AS TE links for the local AS. * TE properties of each inter-AS TE link. * AS number of the neighboring AS connected to by each inter-AS TE link. * Identity (TE Router ID) of the neighboring ASBR connected to by each inter-AS TE link. In GMPLS networks, further information may also be required to select the correct TE links as defined in [RFC5307]. The example above shows how this information is needed at the entry- point ASBRs for each AS (or the PCEs that provide computation services for the ASBRs). However, this information is also needed throughout the local AS if path computation functionality is fully distributed among LSRs in the local AS, for example to support LSPs that have start points (ingress nodes) within the AS. 2.3. Backward Recursive Path Computation Another scenario using PCE techniques has the same problem. [RFC5441] defines a PCE-based TE LSP computation method (called Backward Recursive Path Computation) to compute optimal inter-domain constrained MPLS-TE or GMPLS LSPs. In this path computation method, a specific set of traversed domains (ASes) are assumed to be selected before computation starts. Each downstream PCE in domain(i) returns to its upstream neighbor PCE in domain(i-1) a multipoint-to-point tree of potential paths. Each tree consists of the set of paths from all boundary nodes located in domain(i) to the destination where each path satisfies the set of required constraints for the TE LSP (bandwidth, affinities, etc.). So a PCE needs to select boundary nodes (that is, ASBRs) that provide connectivity from the upstream AS. In order for the tree of paths provided by one PCE to its neighbor to be correlated, the identities of the ASBRs for each path need to be referenced. Thus, the PCE must know the identities of the ASBRs in the remote AS that are reached by any inter-AS TE link, and, in order to provide only suitable paths in the tree, the PCE must know the TE properties of the inter-AS TE links. See the following figure as an example. Chen, et al. Expires 1 April 2023 [Page 6] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 PCE1<------>PCE2<-------->PCE3 / : : / : : R1------R3----R5-----R7------R9-----R11 | | \ | / | | | \ | ---- | | | \ | / | R2------R4----R6 --R8------R10----R12 : : <-- AS1 -->:<---- AS2 --->:<--- AS3 ---> Figure 2: BRPC for Inter-AS Reference Model The figure shows three ASes (AS1, AS2, and AS3), three PCEs (PCE1, PCE2, and PCE3), and twelve LSRs (R1 through R12). R3 and R4 are ASBRs in AS1. R5, R6, R7, and R8 are ASBRs in AS2. R9 and R10 are ASBRs in AS3. PCE1, PCE2, and PCE3 cooperate to perform inter-AS path computation and are responsible for path segment computation within their own domain(s). If an inter-AS TE LSP is planned to be established from R1 to R12, the traversed domains are assumed to be selected: AS1->AS2->AS3, and the PCE chain is: PCE1->PCE2->PCE3. First, the path computation request originated from the PCC (R1) is relayed by PCE1 and PCE2 along the PCE chain to PCE3. Then, PCE3 begins to compute the path segments from the entry boundary nodes that provide connection from AS2 to the destination (R12). But, to provide suitable path segments, PCE3 must determine which entry boundary nodes provide connectivity to its upstream neighbor AS (identified by its AS number), and must know the TE properties of the inter-AS TE links. In the same way, PCE2 also needs to determine the entry boundary nodes according to its upstream neighbor AS and the inter-AS TE link capabilities. Thus, to support Backward Recursive Path Computation, the same information listed in Section 2.2 is required. The AS number of the neighboring AS connected to by each inter-AS TE link is particularly important. 3. Extensions to ISIS-TE Note that this document does not define mechanisms for distribution of TE information from one AS to another, does not distribute any form of TE reachability information for destinations outside the AS, does not change the PCE architecture or usage, does not suggest or recommend any form of TE aggregation, and does not feed private information between ASes. See Section 2.1. Chen, et al. Expires 1 April 2023 [Page 7] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 In this document, for the advertisement of inter-AS TE links, a new TLV, which is referred to as the inter-AS reachability TLV, is defined. Three new sub-TLVs are also defined for inclusion in the inter-AS reachability TLV to carry the information about the neighboring AS number and the remote ASBR ID of an inter-AS link. The sub-TLVs defined in [RFC5305], [RFC6119], and other documents for inclusion in the extended IS reachability TLV are applicable to be included in the inter-AS reachability TLV for inter-AS TE links advertisement. This document also defines two new sub-TLVs for inclusion in the IS- IS router capability TLV to carry the TE Router ID when the TE Router ID is needed to reach all routers within an entire IS-IS routing domain. While some of the TE information of an inter-AS TE link may be available within the AS from other protocols, in order to avoid any dependency on where such protocols are processed, this mechanism carries all the information needed for the required TE operations. 3.1. Choosing the TE Router ID Value Subsequent sections specify advertisement of a TE Router ID value for IPv4 and/or IPv6. This section defines how this value is chosen. A TE Router ID MUST be an address which is unique within the IS-IS domain and stable i.e., it can always be referenced in a path that will be reachable from multiple hops away, regardless of the state of the node's interfaces. When advertising an IPv4 address as a TE Router ID, if the Traffic Engineering Router ID TLV [RFC5305] is being advertised, then the address SHOULD be identical to the address in the Traffic Engineering Router ID TLV. The TE Router ID MAY be identical to an IP Interface Address [RFC1195] advertised by the originating IS so long as the address meets the requirements specified above. When advertising an IPv6 address as a TE Router ID, if the IPv6 TE Router ID TLV [RFC6119] is being advertised, then the address SHOULD be identical to the address in the IPv6 TE Router ID TLV. The TE Router ID MAY be identical to a non-link-local IPv6 Interface Address advertised by the originating IS in a Link State PDU using the IPv6 Intf. Addr TLV [RFC5308] so long as the address meets the requirements specified above. Chen, et al. Expires 1 April 2023 [Page 8] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 3.2. Inter-AS Reachability TLV The inter-AS reachability TLV has type 141 (see Section 6.1) and contains a data structure consisting of: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | default metric | (3 octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (1 octet) +-+-+-+-+-+-+-+-+ |sub-TLVs length| (1 octet) +-+-+-+-+-+-+-+-+-+-+-+- | sub-TLVs ... (0-246 octets) +-+-+-+-+-+-+-+-+-+-+-+- Flags consists of the following: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S|D| Rsvd | +-+-+-+-+-+-+-+-+ where: S bit: If the S bit is set(1), the Inter-AS Reachability TLV MUST be flooded across the entire routing domain. If the S bit is not set(0), the TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking. D bit: When the Inter-AS Reachability TLV is leaked from Level 2 (L2) to Level 1 (L1), the D bit MUST be set. Otherwise, this bit MUST be clear. Inter-AS Reachability TLVs with the D bit set MUST NOT be leaked from Level 1 to Level 2. This is to prevent TLV looping. Reserved(Rsvd) bits MUST be zero when originated and ignored when received. Compared to the extended reachability TLV which is defined in [RFC5305], the inter-AS reachability TLV replaces the "7 octets of System ID and Pseudonode Number" field with a "4 octets of Router ID" field and introduces an extra "control information" field, which consists of a flooding-scope bit (S bit), an up/down bit (D bit), and 6 reserved bits. Chen, et al. Expires 1 April 2023 [Page 9] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 The Router ID field of the inter-AS reachability TLV is 4 octets in length and has a value as defined in Section 3.1. If the originating node does not support IPv4, then the reserved value 0.0.0.0 MUST be used in the Router ID field and the IPv6 Router ID sub-TLV MUST be present in the inter-AS reachability TLV. The Router ID could be used to indicate the source of the inter-AS reachability TLV. The flooding procedures for inter-AS reachability TLV are identical to the flooding procedures for the GENINFO TLV, which are defined in Section 4 of [RFC6823]. These procedures have been previously discussed in [RFC7981]. The flooding-scope bit (S bit) SHOULD be set to 0 if the flooding scope is to be limited to within the single IGP area to which the ASBR belongs. It MAY be set to 1 if the information is intended to reach all routers (including area border routers, ASBRs, and PCEs) in the entire IS-IS routing domain. The choice between the use of 0 or 1 is an AS-wide policy choice, and configuration control SHOULD be provided in ASBR implementations that support the advertisement of inter-AS TE links. The sub-TLVs defined in [RFC5305], [RFC6119], and other documents for describing the TE properties of a TE link are also applicable to the inter-AS reachability TLV for describing the TE properties of an Inter-AS TE link. Apart from these sub-TLVs, four new sub-TLVs are defined for inclusion in the inter-AS reachability TLV defined in this document: Sub-TLV type Length Name ------------ ------ --------------------------- 24 4 remote AS number 25 4 IPv4 remote ASBR identifier 26 16 IPv6 remote ASBR identifier TBD1 16 IPv6 local ASBR identifier Detailed definitions of the four new sub-TLVs are described in Sections 3.3.1, 3.3.2, 3.3.3, and 3.3.4. 3.3. TE Router ID The Traffic Engineering router ID TLV and IPv6 TE Router ID TLV, which are defined in [RFC5305] and [RFC6119] respectively, only have area flooding-scope. When performing inter-AS TE, the TE Router ID MAY be needed to reach all routers within an entire IS-IS routing domain and it MUST have the same flooding scope as the Inter-AS Reachability TLV does. Chen, et al. Expires 1 April 2023 [Page 10] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 [RFC7981] defines a generic advertisement mechanism for IS-IS which allows a router to advertise its capabilities within an IS-IS area or an entire IS-IS routing domain. [RFC7981] also points out that the TE Router ID is a candidate to be carried in the IS-IS router capability TLV when performing inter-area TE. This document uses such mechanism for TE Router ID advertisement when the TE Router ID is needed to reach all routers within an entire IS- IS Routing domain. Two new sub-TLVs are defined for inclusion in the IS-IS Router Capability TLV to carry the TE Router IDs. Sub-TLV type Length Name ------------ ------ ----------------- 11 4 IPv4 TE Router ID 12 16 IPv6 TE Router ID Detailed definitions of the new sub-TLVs are described in Section 3.4.1 and 3.4.2. 3.4. Sub-TLVs for Inter-AS Reachability TLV 3.4.1. Remote AS Number Sub-TLV A new sub-TLV, the remote AS number sub-TLV, is defined for inclusion in the inter-AS reachability TLV when advertising inter-AS links. The remote AS number sub-TLV specifies the AS number of the neighboring AS to which the advertised link connects. The remote AS number sub-TLV is TLV type 24 (see Section 6.2) and is 4 octets in length. The format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The remote AS number field has 4 octets. When only 2 octets are used for the AS number, the left (high-order) 2 octets MUST be set to 0. The remote AS number sub-TLV MUST be included when a router advertises an inter-AS TE link. Chen, et al. Expires 1 April 2023 [Page 11] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 3.4.2. IPv4 Remote ASBR ID Sub-TLV A new sub-TLV, which is referred to as the IPv4 remote ASBR ID sub- TLV, is defined for inclusion in the inter-AS reachability TLV when advertising inter-AS links. The IPv4 remote ASBR ID sub-TLV specifies the IPv4 identifier of the remote ASBR to which the advertised inter-AS link connects. The value advertised is selected as defined in Section 3.1. The IPv4 remote ASBR ID sub-TLV is TLV type 25 (see Section 6.2) and is 4 octets in length. The format of the IPv4 remote ASBR ID sub-TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote ASBR ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The IPv4 remote ASBR ID sub-TLV MUST be included if the neighboring ASBR has an IPv4 address. The value advertised is selected as defined in Section 3.1. If the neighboring ASBR does not have an IPv4 address, the IPv6 remote ASBR ID sub-TLV MUST be included instead. An IPv4 remote ASBR ID sub-TLV and IPv6 remote ASBR ID sub- TLV MAY both be present in an extended IS reachability TLV. 3.4.3. IPv6 Remote ASBR ID Sub-TLV A new sub-TLV, which is referred to as the IPv6 remote ASBR ID sub- TLV, is defined for inclusion in the inter-AS reachability TLV when advertising inter-AS links. The IPv6 remote ASBR ID sub-TLV specifies the IPv6 identifier of the remote ASBR to which the advertised inter-AS link connects. The value advertised is selected as defined in Section 3.1. The IPv6 remote ASBR ID sub-TLV is TLV type 26 (see Section 6.2) and is 16 octets in length. The format of the IPv6 remote ASBR ID sub- TLV is as follows: Chen, et al. Expires 1 April 2023 [Page 12] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote ASBR ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote ASBR ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote ASBR ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote ASBR ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The IPv6 remote ASBR ID sub-TLV MUST be included if the neighboring ASBR has an IPv6 address. If the neighboring ASBR does not have an IPv6 address, the IPv4 remote ASBR ID sub-TLV MUST be included instead. An IPv4 remote ASBR ID sub-TLV and IPv6 remote ASBR ID sub- TLV MAY both be present in an extended IS reachability TLV. 3.4.4. IPv6 Local ASBR ID sub-TLV The IPv6 Local ASBR ID sub-TLV is TLV type TBD1 (see Section 6.3) and is 16 octets in length. The format of the IPv6 Local ASBR ID sub-TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local ASBR ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local ASBR ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local ASBR ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local ASBR ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value advertised is selected as defined in Section 3.1. If the originating node does not support IPv4, the IPv6 Local ASBR ID sub-TLV MUST be present in the inter-AS reachability TLV. Inter-AS reachability TLVs which have a Router ID of 0.0.0.0 and do not have the IPv6 Local ASBR ID sub-TLV present MUST be ignored. Chen, et al. Expires 1 April 2023 [Page 13] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 3.5. Sub-TLVs for IS-IS Router Capability TLV 3.5.1. IPv4 TE Router ID sub-TLV The IPv4 TE Router ID sub-TLV is TLV type 11 (see Section 6.3) and is 4 octets in length. The format of the IPv4 TE Router ID sub-TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value advertised is selected as defined in Section 3.1. When the TE Router ID is needed to reach all routers within an entire IS-IS routing domain, the IS-IS Router capability TLV MUST be included in its LSP. If an ASBR supports Traffic Engineering for IPv4 and if the ASBR has an IPv4 TE Router ID, the IPv4 TE Router ID sub-TLV MUST be included. If the ASBR does not have an IPv4 TE Router ID, the IPv6 TE Router sub-TLV MUST be included instead. An IPv4 TE Router ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be present in an IS-IS router capability TLV. 3.5.2. IPv6 TE Router ID sub-TLV The IPv6 TE Router ID sub-TLV is TLV type 12 (see Section 6.3) and is 16 octets in length. The format of the IPv6 TE Router ID sub-TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Router ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Router ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Router ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value advertised is selected as defined in Section 3.1. Chen, et al. Expires 1 April 2023 [Page 14] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 When the TE Router ID is needed to reach all routers within an entire IS-IS routing domain, the IS-IS router capability TLV MUST be included in its LSP. If an ASBR supports Traffic Engineering for IPv6 and if the ASBR has an IPv6 TE Router ID, the IPv6 TE Router ID sub-TLV MUST be included. If the ASBR does not have an IPv6 TE Router ID, the IPv4 TE Router sub-TLV MUST be included instead. An IPv4 TE Router ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be present in an IS-IS router capability TLV. 4. Procedure for Inter-AS TE Links When TE is enabled on an inter-AS link and the link is up, the ASBR SHOULD advertise this link using the normal procedures for [RFC5305]. When either the link is down or TE is disabled on the link, the ASBR SHOULD withdraw the advertisement. When there are changes to the TE parameters for the link (for example, when the available bandwidth changes), the ASBR SHOULD re-advertise the link but MUST take precautions against excessive re-advertisements. Hellos MUST NOT be exchanged over the inter-AS link, and consequently, an IS-IS adjacency MUST NOT be formed. The information advertised comes from the ASBR's knowledge of the TE capabilities of the link, the ASBR's knowledge of the current status and usage of the link, and configuration at the ASBR of the remote AS number and remote ASBR TE Router ID. Legacy routers receiving an advertisement for an inter-AS TE link are able to ignore it because they do not know the new TLV and sub-TLVs that are defined in Section 3 of this document. They will continue to flood the LSP, but will not attempt to use the information received. In the current operation of ISIS-TE, the LSRs at each end of a TE link emit LSPs describing the link. The databases in the LSRs then have two entries (one locally generated, the other from the peer) that describe the different 'directions' of the link. This enables Constrained Shortest Path First (CSPF) to do a two-way check on the link when performing path computation and eliminate it from consideration unless both directions of the link satisfy the required constraints. In the case we are considering here (i.e., of a TE link to another AS), there is, by definition, no IGP peering and hence no bidirectional TE link information. In order for the CSPF route computation entity to include the link as a candidate path, we have to find a way to get LSPs describing its (bidirectional) TE properties into the TE database. Chen, et al. Expires 1 April 2023 [Page 15] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 This is achieved by the ASBR advertising, internally to its AS, information about both directions of the TE link to the next AS. The ASBR will normally generate an LSP describing its own side of a link; here we have it 'proxy' for the ASBR at the edge of the other AS and generate an additional LSP that describes that device's 'view' of the link. Only some essential TE information for the link needs to be advertised; i.e., the Interface Address, the remote AS number, and the remote ASBR ID of an inter-AS TE link. Routers or PCEs that are capable of processing advertisements of inter-AS TE links SHOULD NOT use such links to compute paths that exit an AS to a remote ASBR and then immediately re-enter the AS through another TE link. Such paths would constitute extremely rare occurrences and SHOULD NOT be allowed except as the result of specific policy configurations at the router or PCE computing the path. 4.1. Origin of Proxied TE Information Section 4 describes how an ASBR advertises TE link information as a proxy for its neighbor ASBR, but does not describe where this information comes from. Although the source of the information described in Section 4 is outside the scope of this document, it is possible that it will be a configuration requirement at the ASBR, as are other local properties of the TE link. Further, where BGP is used to exchange IP routing information between the ASBRs, a certain amount of additional local configuration about the link and the remote ASBR is likely to be available. We note further that it is possible, and may be operationally advantageous, to obtain some of the required configuration information from BGP. Whether and how to utilize these possibilities is an implementation matter. 5. Security Considerations The protocol extensions defined in this document are relatively minor and can be secured within the AS in which they are used by the existing IS-IS security mechanisms (e.g., using the cleartext passwords or Hashed Message Authentication Codes, which are defined in [RFC1195], [RFC5304], and [RFC5310] separately). Chen, et al. Expires 1 April 2023 [Page 16] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 There is no exchange of information between ASes, and no change to the IS-IS security relationship between the ASes. In particular, since no IS-IS adjacency is formed on the inter-AS links, there is no requirement for IS-IS security between the ASes. Some of the information included in these new advertisements (e.g., the remote AS number and the remote ASBR ID) is obtained manually from a neighboring administration as part of a commercial relationship. The source and content of this information should be carefully checked before it is entered as configuration information at the ASBR responsible for advertising the inter-AS TE links. It is worth noting that in the scenario we are considering, a Border Gateway Protocol (BGP) peering may exist between the two ASBRs and that this could be used to detect inconsistencies in configuration (e.g., the administration that originally supplied the information may provide incorrect information, or some manual mis-configurations or mistakes may be made by the operators). For example, if a different remote AS number is received in a BGP OPEN [RFC4271] from that locally configured to ISIS-TE, as we describe here, then local policy SHOULD be applied to determine whether to alert the operator to a potential mis-configuration or to suppress the IS-IS advertisement of the inter-AS TE link. Advertisement of incorrect information could result in an inter-AS TE LSP that traverses an unintended AS. Note further that if BGP is used to exchange TE information as described in Section 4.1, the inter-AS BGP session SHOULD be secured using mechanisms such as described in [RFC5925] to provide authentication and integrity checks. For a discussion of general security considerations for IS-IS, see [RFC5304]. 6. IANA Considerations IANA is requested to make the following allocations from registries under its control. 6.1. Inter-AS Reachability TLV This document defines the following new IS-IS TLV type, described in Section 3.1, which has been registered in the IS-IS TLV codepoint registry: Type Description IIH LSP SNP Purge Reference ---- ---------------------- --- --- --- ----- --------- 141 inter-AS reachability n y n n [This.I-D] information Chen, et al. Expires 1 April 2023 [Page 17] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 6.2. Sub-TLVs for the Inter-AS Reachability TLV This document defines the following new sub-TLV types (described in Sections 3.3.1, 3.3.2, 3.3.3, and, 3.3.4) of top-level TLV 141 (see Section 6.1 above). Three of these sub-TLVs have been registered in the IS-IS Sub-TLVs for TLVs Advertising Neighbor Information registry by [RFC5316]. One additional sub-TLV (IPv6 local ASBR identifier) is introduced by this document and needs to be added to the same registry. Type Description 22 23 25 141 222 223 Reference ---- ----------------------------- --- --- --- --- --- --- --------- 24 remote AS number n n n y n n [This.I-D] 25 IPv4 remote ASBR identifier n n n y n n [This.I-D] 26 IPv6 remote ASBR identifier n n n y n n [This.I-D] TBD1 IPv6 local ASBR identifier n n n y n n [This.I-D] As described above in Section 3.1, the sub-TLVs which are defined in [RFC5305], [RFC6119] and other documents for describing the TE properties of a TE link are applicable to describe an inter-AS TE link and MAY be included in the inter-AS reachability TLV when adverting inter-AS TE links. 6.3. Sub-TLVs for the IS-IS Router Capability TLV This document defines the following new sub-TLV types, described in Sections 3.4.1 and 3.4.2, of top-level TLV 242 (which is defined in [RFC7981]) that have been registered in the IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV registry: Type Description Reference ---- ------------------------------ --------- 11 IPv4 TE Router ID [This.I-D] 12 IPv6 TE Router ID [This.I-D] 7. Acknowledgements For the original version of [RFC5316] the authors thanked Adrian Farrel, Jean-Louis Le Roux, Christian Hopps, and Hannes Gredler for their review and comments on this document. 8. References 8.1. Normative References [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, . Chen, et al. Expires 1 April 2023 [Page 18] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, . [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC4216] Zhang, R., Ed. and J.-P. Vasseur, Ed., "MPLS Inter- Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, DOI 10.17487/RFC4216, November 2005, . Chen, et al. Expires 1 April 2023 [Page 19] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter- Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, . [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, . [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, December 2008, . [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, April 2009, . [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising Generic Information in IS-IS", RFC 6823, DOI 10.17487/RFC6823, December 2012, . Appendix A. Changes to RFC 5316 The following is a summary of the substantive changes this document makes to RFC 5316. Some editorial changes were also made. Chen, et al. Expires 1 April 2023 [Page 20] Internet-Draft ISIS Extensions for Inter-AS TE September 2022 RFC 5316 only allowed a 32 bit Router ID in the fixed header of TLV 141. This is problematic in an IPv6-only deployment where an IPv4 address may not be available. This document specifies: 1. The Router ID should be identical to the value advertised in the Traffic Engineering Router ID TLV (134) if available. 2. If no Traffic Engineering Router ID is assigned the Router ID should be identical to an IP Interface Address [RFC1195] advertised by the originating IS. 3. If the originating node does not support IPv4, then the reserved value 0.0.0.0 must be used in the Router ID field and the new IPv6 Local ASBR identifier sub-TLV must be present in the TLV. Authors' Addresses Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com Les Ginsberg Cisco Systems Email: ginsberg@cisco.com Stefano Previdi Huawei Technologies Italy Email: stefano@previdi.net Xiaodong Duan China Mobile Email: duanxiaodong@chinamobile.com Chen, et al. Expires 1 April 2023 [Page 21] ./draft-irtf-icnrg-ccninfo-15.txt0000644000764400076440000026472414353224432016427 0ustar iustiniustin ICN Research Group H. Asaeda Internet-Draft A. Ooka Intended status: Experimental NICT Expires: 1 July 2023 X. Shao Toyohashi University of Technology 28 December 2022 CCNinfo: Discovering Content and Network Information in Content-Centric Networks draft-irtf-icnrg-ccninfo-15 Abstract This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache in Content-Centric Networks (CCN). CCNinfo investigates: 1) the CCN routing path information per name prefix, 2) the Round-Trip Time (RTT) between the content forwarder and consumer, and 3) the states of in-network cache per name prefix. CCNinfo is useful to understand and debug the behavior of testbed networks and other experimental deployments of CCN systems. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). This document represents the consensus view of ICNRG and has been reviewed extensively by several members of the ICN community and the RG. The authors and RG chairs approve of the contents. The document is sponsored under the IRTF and is not issued by the IETF and is not an IETF standard. This is an experimental protocol and the specification may change in the future. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 July 2023. Asaeda, et al. Expires 1 July 2023 [Page 1] Internet-Draft CCNinfo December 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. CCNinfo as an Experimental Tool . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 3. CCNinfo Message Formats . . . . . . . . . . . . . . . . . . . 9 3.1. Request Message . . . . . . . . . . . . . . . . . . . . . 10 3.1.1. Request Header Block and Request Block . . . . . . . 12 3.1.2. Report Block TLV . . . . . . . . . . . . . . . . . . 16 3.1.3. Content Name Specification . . . . . . . . . . . . . 16 3.2. Reply Message . . . . . . . . . . . . . . . . . . . . . . 17 3.2.1. Reply Block TLV . . . . . . . . . . . . . . . . . . . 18 3.2.1.1. Reply Sub-Block TLV . . . . . . . . . . . . . . . 19 4. CCNinfo User Behavior . . . . . . . . . . . . . . . . . . . . 22 4.1. Sending CCNinfo Request . . . . . . . . . . . . . . . . . 22 4.1.1. Routing Path Information . . . . . . . . . . . . . . 23 4.1.2. In-Network Cache Information . . . . . . . . . . . . 23 4.2. Receiving CCNinfo Reply . . . . . . . . . . . . . . . . . 23 5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 23 5.1. User and Neighbor Verification . . . . . . . . . . . . . 23 5.2. Receiving CCNinfo Request . . . . . . . . . . . . . . . . 24 5.3. Forwarding CCNinfo Request . . . . . . . . . . . . . . . 25 5.3.1. Regular Request . . . . . . . . . . . . . . . . . . . 25 5.3.2. Full Discovery Request . . . . . . . . . . . . . . . 26 5.4. Sending CCNinfo Reply . . . . . . . . . . . . . . . . . . 27 5.5. Forwarding CCNinfo Reply . . . . . . . . . . . . . . . . 27 5.6. PIT Entry Management for Multipath Support . . . . . . . 28 6. CCNinfo Termination . . . . . . . . . . . . . . . . . . . . . 29 6.1. Arriving at First-hop Router . . . . . . . . . . . . . . 29 6.2. Arriving at Router Having Cache . . . . . . . . . . . . . 29 6.3. Arriving at Last Router . . . . . . . . . . . . . . . . . 29 6.4. Invalid Request . . . . . . . . . . . . . . . . . . . . . 30 6.5. No Route . . . . . . . . . . . . . . . . . . . . . . . . 30 Asaeda, et al. Expires 1 July 2023 [Page 2] Internet-Draft CCNinfo December 2022 6.6. No Information . . . . . . . . . . . . . . . . . . . . . 30 6.7. No Space . . . . . . . . . . . . . . . . . . . . . . . . 30 6.8. Fatal Error . . . . . . . . . . . . . . . . . . . . . . . 30 6.9. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 31 6.10. Non-Supported Node . . . . . . . . . . . . . . . . . . . 31 6.11. Administratively Prohibited . . . . . . . . . . . . . . . 31 7. Configurations . . . . . . . . . . . . . . . . . . . . . . . 31 7.1. CCNinfo Reply Timeout . . . . . . . . . . . . . . . . . . 31 7.2. HopLimit in Fixed Header . . . . . . . . . . . . . . . . 31 7.3. Access Control . . . . . . . . . . . . . . . . . . . . . 31 8. Diagnosis and Analysis . . . . . . . . . . . . . . . . . . . 31 8.1. Number of Hops and RTT . . . . . . . . . . . . . . . . . 32 8.2. Caching Router Identification . . . . . . . . . . . . . . 32 8.3. TTL or Hop Limit . . . . . . . . . . . . . . . . . . . . 32 8.4. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 32 8.5. Path Stretch . . . . . . . . . . . . . . . . . . . . . . 32 8.6. Cache Hit Probability . . . . . . . . . . . . . . . . . . 32 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9.1. Packet Type Registry . . . . . . . . . . . . . . . . . . 33 9.2. Top-Level Type Registry . . . . . . . . . . . . . . . . . 33 9.3. Hop-by-Hop Type Registry . . . . . . . . . . . . . . . . 33 9.4. Message Type Registry . . . . . . . . . . . . . . . . . . 33 9.5. Reply Type Registry . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10.1. Policy-Based Information Provisioning for Request . . . 34 10.2. Filtering CCNinfo Users Located in Invalid Networks . . 34 10.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 35 10.4. Characteristics of Content . . . . . . . . . . . . . . . 35 10.5. Computational Attacks . . . . . . . . . . . . . . . . . 35 10.6. Longer or Shorter CCNinfo Reply Timeout . . . . . . . . 35 10.7. Limiting Request Rates . . . . . . . . . . . . . . . . . 36 10.8. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 36 10.9. Adjacency Verification . . . . . . . . . . . . . . . . . 36 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 12.1. Normative References . . . . . . . . . . . . . . . . . . 36 12.2. Informative References . . . . . . . . . . . . . . . . . 37 Appendix A. ccninfo Command and Options . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction In Content-Centric Networks (CCN), publishers provide the content through the network, and receivers retrieve it by name. In this network architecture, routers forward content requests through their Forwarding Information Bases (FIBs), which are populated by name- based routing protocols. CCN also enables receivers to retrieve content from an in-network cache. Asaeda, et al. Expires 1 July 2023 [Page 3] Internet-Draft CCNinfo December 2022 In CCN, while consumers do not generally need to know the content forwarder that is transmitting the content to them, the operators and developers may want to identify the content forwarder and observe the routing path information per name prefix for troubleshooting or investigating the network conditions. IP traceroute is a useful tool for discovering the routing conditions in IP networks because it provides intermediate router addresses along the path between the source and destination and the Round-Trip Time (RTT) for the path. However, this IP-based network tool cannot trace the name prefix paths used in CCN. Moreover, such IP-based network tools do not obtain the states of the in-network cache to be discovered. Contrace [7] enables end users (i.e., consumers) to investigate path and in-network cache conditions in CCN. Contrace is implemented as an external daemon process running over TCP/IP that can interact with a previous CCNx forwarding daemon (CCNx-0.8.2) to retrieve the caching information on the forwarding daemon. This solution is flexible, but it requires defining the common APIs used for global deployment in TCP/IP networks. ICN ping [8] and traceroute [9] are lightweight operational tools that enable a user to explore the path(s) that reach a publisher or a cache storing the named content. ICN ping and traceroute, however, do not expose detailed information about the forwarders deployed by a network operator. This document describes the specifications of "CCNinfo", an active networking tool for discovering the path and content caching information in CCN. CCNinfo defines the protocol messages to investigate path and in-network cache conditions in CCN. It is embedded in the CCNx forwarding process and can facilitate with non- IP networks as with the basic CCN concept. The two message types, Request and Reply messages, are encoded in the CCNx TLV format [1]. The request-reply message flow, walking up the tree from a consumer toward a publisher, is similar to the behavior of the IP multicast traceroute facility [10]. CCNinfo facilitates the tracing of a routing path and provides: 1) the RTT between the content forwarder (i.e., caching router or first- hop router) and consumer, 2) the states of the in-network cache per name prefix, and 3) the routing path information per name prefix. In addition, CCNinfo identifies the states of the cache, such as the following metrics for Content Store (CS) in the content forwarder: 1) size of cached content objects, 2) number of cached content objects, 3) number of accesses (i.e., received Interests) per content, and 4) elapsed cache time and remaining cache lifetime of content. Asaeda, et al. Expires 1 July 2023 [Page 4] Internet-Draft CCNinfo December 2022 CCNinfo supports multipath forwarding. The Request messages can be forwarded to multiple neighbor routers. When the Request messages are forwarded to multiple routers, the different Reply messages are forwarded from different routers or publishers. Furthermore, CCNinfo implements policy-based information provisioning that enables administrators to "hide" secure or private information but does not disrupt message forwarding. This policy-based information provisioning reduces the deployment barrier faced by operators in installing and running CCNinfo on their routers. The document represents the consensus of the Information-Centric Networking Research Group (ICNRG). This document was read and reviewed by the active research group members. It is not an IETF product and is not a standard. 1.1. CCNinfo as an Experimental Tool In order to carry out meaningful experimentation with CCNx protocols, comprehensive instrumentation and management information is needed to take measurements and explore both the performance and robustness characteristics of the protocols and of the applications using them. CCNinfo's primary goal is to gather and report this information. As experience is gained with both the CCNx protocols and CCNinfo itself, we can refine the instrumentation capabilities and discover what additional capabilities might be needed in CCNinfo and conversely which features wind up not being of sufficient value to justify the implementation complexity and execution overhead. CCNinfo is intended as a comprehensive experimental tool for CCNx- based networks. It provides a wealth of information from forwarders, including on-path in-network cache conditions as well as forwarding path instrumentation of multiple paths toward content forwarders. As an experimental capability that exposes detailed information about the forwarders deployed by a network operator, CCNinfo employs more granular authorization policies than those required of ICN ping or ICN traceroute. CCNinfo uses two message types: Request and Reply. A CCNinfo user, e.g., consumer, initiates a CCNinfo Request message when s/he wants to obtain routing path and cache information. When an adjacent neighbor router receives the Request message, it examines its own cache information. If the router does not cache the specified content, it inserts its Report block into the hop-by-hop header of the Request message and forwards the message to its upstream neighbor router(s) decided by its FIB. In Figure 1, CCNinfo user and routers (Router A, B, C) insert their own Report blocks into the Request message and forward the message toward the content forwarder. Asaeda, et al. Expires 1 July 2023 [Page 5] Internet-Draft CCNinfo December 2022 1. Request 2. Request 3. Request (U) (U+A) (U+A+B) +----+ +----+ +----+ | | | | | | | v | v | v +--------+ +--------+ +--------+ +--------+ +---------+ | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| | user | | A | | B | | C | | | +--------+ +--------+ +--------+ +--------+ +---------+ \ \ +-------+ 3. Request \ | Cache | (U+A+B) \ +---------+ | v| Caching |----+ | router | +---------+ Figure 1: Request message invoked by CCNinfo user and forwarded by routers. When the Request message reaches the content forwarder, the content forwarder forms the Reply message; it inserts its own Reply block TLV and Reply sub-block TLV(s) to the Request message. The Reply message is then forwarded back toward the user in a hop-by-hop manner along the Pending Interest Table (PIT) entries. In Figure 2, each router (Router C, B, and A) forwards the Reply message along its PIT entry and finally, the CCNinfo user receives a Reply message from Router C, which is the first-hop router for the Publisher. Another Reply message from the Caching router (i.e., Reply(C)) is discarded at Router B if the other Reply message (i.e., Reply(P)) was already forwarded by Router B. 3. Reply(P) 2. Reply(P) 1. Reply(P) +----+ +----+ +----+ | | | | | | v | v | v | +--------+ +--------+ +--------+ +--------+ +---------+ | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| | user | | A | | B | | C | | | +--------+ +--------+ +--------+ +--------+ +---------+ ^ \ +-------+ 1. Reply(C) \ | Cache | \ +---------+ | \| Caching |----+ | router | +---------+ Asaeda, et al. Expires 1 July 2023 [Page 6] Internet-Draft CCNinfo December 2022 Figure 2: Reply messages forwarded by routers, and one Reply message is received by CCNinfo user. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 (RFC2119 [3] and RFC8174 [4]) when, and only when, they appear in all capitals, as shown here. 2.1. Definitions This document follows the basic terminologies and definitions described in [1]. Although CCNinfo requests flow in the opposite direction to the data flow, we refer to "upstream" and "downstream" with respect to data, unless explicitly specified. Scheme name It indicates a URI and protocol. This document only considers "ccnx:/" as the scheme name. Prefix name A prefix name, which is defined in [2], is a name that does not uniquely identify a single content object, but rather a namespace or prefix of an existing content object name. Exact name An exact name, which is defined in [2], is one that uniquely identifies the name of a content object. Node A node within a CCN network can fulfill the role of a data publisher, a data consumer, and/or a forwarder for interest and content object as given in [6]. Consumer A node that requests content objects by generating and sending out interests. It is a same definition of ICN Consumer as given in [6]. Publisher A node that creates content objects and makes them available for retrieval. It is a same definition of ICN Producer as given in [6]. Asaeda, et al. Expires 1 July 2023 [Page 7] Internet-Draft CCNinfo December 2022 Router A node that implements stateful forwarding in the path between consumer and publisher. Caching router A node that temporarily stores and potentially carries interests or content objects before forwarding it to next node. Content forwarder It is either a caching router or a first-hop router that forwards content objects to consumers. CCNinfo user A node that initiates the CCNinfo Request, which is consumer or router that invokes the CCNinfo user program with the name prefix of the content. The CCNinfo user program, such as "ccninfo" command described in Appendix A or other similar commands, initiates the Request message to obtain routing path and cache information. Incoming face The face on which data are expected to arrive from the specified name prefix. Outgoing face The face to which data from the publisher or router are expected to transmit for the specified name prefix. It is also the face on which the Request messages are received. Upstream router The router that connects to an Incoming face of a router. Downstream router The router that connects to an Outgoing face of a router. First-hop router (FHR) The router that matches a FIB entry with an Outgoing face referring to a local application or a publisher. Last-hop router (LHR) The router that is directly connected to a consumer. Asaeda, et al. Expires 1 July 2023 [Page 8] Internet-Draft CCNinfo December 2022 3. CCNinfo Message Formats CCNinfo Request and Reply messages are encoded in the CCNx TLV format ([1], Figure 3). The Request message consists of a fixed header, Request block TLV (Figure 7), and Report block TLV(s) (Figure 12). The Reply message consists of a fixed header, Request block TLV, Report block TLV(s), Reply block TLV (Figure 14), and Reply sub-block TLV(s) (Figure 15). 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Version | PacketType | PacketLength | +---------------+---------------+---------------+---------------+ | PacketType specific fields | HeaderLength | +---------------+---------------+---------------+---------------+ / Optional Hop-by-hop header TLVs / +---------------+---------------+---------------+---------------+ / PacketPayload TLVs / +---------------+---------------+---------------+---------------+ / Optional CCNx ValidationAlgorithm TLV / +---------------+---------------+---------------+---------------+ / Optional CCNx ValidationPayload TLV (ValidationAlg required) / +---------------+---------------+---------------+---------------+ Figure 3: Packet format [1] The PacketType values in the fixed header shown in Figure 3 are PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, respectively (Figure 4). CCNinfo Request and Reply messages are forwarded in a hop-by-hop manner. When the Request message reaches the content forwarder, the content forwarder turns it into a Reply message by changing the Type field value in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards it back toward the node that initiated the Request message. Code Type name ======== ===================== %x00 PT_INTEREST [1] %x01 PT_CONTENT [1] %x02 PT_RETURN [1] %x03 PT_CCNINFO_REQUEST %x04 PT_CCNINFO_REPLY Figure 4: Packet Type Namespace Asaeda, et al. Expires 1 July 2023 [Page 9] Internet-Draft CCNinfo December 2022 Following a fixed header, there can be a sequence of optional hop-by- hop header TLV(s) for a Request message. In the case of a Request message, it is followed by a sequence of Report blocks, each from a router on the path toward the publisher or caching router. At the beginning of PacketPayload TLVs, a top-level TLV type, T_DISCOVERY (Figure 5), exists at the outermost level of a CCNx protocol message. This TLV indicates that the Name segment TLV(s) and Reply block TLV(s) would follow in the Request or Reply message. Code Type name ============= ========================= %x0000 Reserved [1] %x0001 T_INTEREST [1] %x0002 T_OBJECT [1] %x0003 T_VALIDATION_ALG [1] %x0004 T_VALIDATION_PAYLOAD [1] %x0005 T_DISCOVERY Figure 5: Top-Level Type Namespace 3.1. Request Message When a CCNinfo user initiates a discovery request (e.g., via the ccninfo command described in Appendix A), a CCNinfo Request message is created and forwarded to its upstream router through the Incoming face(s) determined by its FIB. The Request message format is shown in Figure 6. It consists of a fixed header, Request header block TLV (Figure 7), Report block TLV(s) (Figure 12), Name TLV, and Request block TLV. Request header block TLV and Report block TLV(s) are contained in the hop-by-hop header, as those might change from hop to hop. Request block TLV is encoded in the PacketPayload TLV by content forwarder as the protocol message itself. The PacketType value of the Request message is PT_CCNINFO_REQUEST (Figure 4). The Type value of the Top-Level type namespace is T_DISCOVERY (Figure 5). Asaeda, et al. Expires 1 July 2023 [Page 10] Internet-Draft CCNinfo December 2022 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Version | PacketType | PacketLength | +---------------+---------------+---------------+---------------+ | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | +===============+===============+===============+===============+ / Request header block TLV / +---------------+---------------+---------------+---------------+ / Report block TLV 1 / +---------------+---------------+---------------+---------------+ / Report block TLV 2 / +---------------+---------------+---------------+---------------+ / . / / . / +---------------+---------------+---------------+---------------+ / Report block TLV n / +===============+===============+===============+===============+ | Type (=T_DISCOVERY) | MessageLength | +---------------+---------------+---------------+---------------+ | T_NAME | Length | +---------------+---------------+---------------+---------------+ / Name segment TLVs (name prefix specified by CCNinfo user) / +---------------+---------------+---------------+---------------+ / Request block TLV / +---------------+---------------+---------------+---------------+ / Optional CCNx ValidationAlgorithm TLV / +---------------+---------------+---------------+---------------+ / Optional CCNx ValidationPayload TLV (ValidationAlg required) / +---------------+---------------+---------------+---------------+ Figure 6: Request message consists of a fixed header, Request block TLV, Report block TLV(s), and Name TLV HopLimit: 8 bits HopLimit is a counter that is decremented with each hop whenever a Request packet is forwarded. It is specified by the CCNinfo user program. The HopLimit value MUST be decremented by 1 prior to forwarding the Request packet. The packet is discarded if HopLimit is decremented to zero. HopLimit limits the distance that a Request may travel on the network. Only the specified number of hops from the CCNinfo user traces the Request. The last router stops the trace and sends the Reply message back to the CCNinfo user. ReturnCode: 8 bits Asaeda, et al. Expires 1 July 2023 [Page 11] Internet-Draft CCNinfo December 2022 ReturnCode is used for the Reply message. This value is replaced by the content forwarder when the Request message is returned as the Reply message (see Section 3.2). Until then, this field MUST be transmitted as zeros and ignored on receipt. Value Name Description ----- --------------- ---------------------------------------------- %x00 NO_ERROR No error %x01 WRONG_IF CCNinfo Request arrived on an interface to which this router would not forward for the specified name/function toward the publisher. %x02 INVALID_REQUEST Invalid CCNinfo Request is received. %x03 NO_ROUTE This router has no route for the name prefix and no way to determine a route. %x04 NO_INFO This router has no cache information for the specified name prefix. %x05 NO_SPACE There was not enough room to insert another Report block in the packet. %x06 INFO_HIDDEN Information is hidden from this discovery owing to some policy. %x0E ADMIN_PROHIB CCNinfo Request is administratively prohibited. %x0F UNKNOWN_REQUEST This router does not support/recognize the Request message. %x80 FATAL_ERROR In a fatal error, the router may know the upstream router but cannot forward the message to it. Reserved (MBZ): 8 bits The reserved fields in the Value field MUST be transmitted as zeros and ignored on receipt. 3.1.1. Request Header Block and Request Block When a CCNinfo user transmits the Request message, s/he MUST insert her/his Request header block TLV (Figure 7) into the hop-by-hop header and Request block TLV (Figure 10) into the message before sending it through the Incoming face(s). 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Type (=T_DISC_REQHDR) | Length | +---------------+---------------+-------+-------+-------+-+-+-+-+ | Request ID |SkipHop| Flags |V|F|O|C| +---------------+---------------+-------+-------+-------+-+-+-+-+ Asaeda, et al. Expires 1 July 2023 [Page 12] Internet-Draft CCNinfo December 2022 Figure 7: Request header block TLV (hop-by-hop header) Code Type name ============= ========================= %x0000 Reserved [1] %x0001 T_INTLIFE [1] %x0002 T_CACHETIME [1] %x0003 T_MSGHASH [1] %x0004-%x0007 Reserved [1] %x0008 T_DISC_REQHDR %x0009 T_DISC_REPORT %x0FFE T_PAD [1] %x0FFF T_ORG [1] %x1000-%x1FFF Reserved [1] Figure 8: Hop-by-Hop Type Namespace Type: 16 bits Format of the Value field. For the type value of the Request block TLV MUST be T_DISC_REQHDR. Length: 16 bits Length of Value field in octets. Request ID: 16 bits This field is used as a unique identifier for the CCNinfo Request so that the duplicate or delayed Reply messages can be detected. SkipHop (Skip Hop Count): 4 bits Number of skipped routers for a Request. It is specified by the CCNinfo user program. The number of routers corresponding to the value specified in this field are skipped and the CCNinfo Request messages are forwarded to the next router without the addition of Report blocks; the next upstream router then starts the trace. The maximum value of this parameter is 15. This value MUST be lower than that of HopLimit at the fixed header. Flags: 12 bits The Flags field is used to indicate the types of the content or path discoveries. Currently, as shown in Figure 9, four bits, "C", "O", "F", and "V" are assigned, and the other 8 bits are reserved (MBZ) for the future use. Each flag can be mutually specified with other flags. These flags are set by the CCNinfo Asaeda, et al. Expires 1 July 2023 [Page 13] Internet-Draft CCNinfo December 2022 user program when they initiate Requests (see Appendix A), and the routers that receive the Requests deal with the flags and change the behaviors (see Section 5 for details). The Flag values defined in this Flags field correspond to the Reply sub-blocks. Flag Value Description ----- ----- ----------------------------------------------------- C 0 Path discovery (i.e., no cache information retrieved) (default) C 1 Path and cache information retrieval O 0 Request to any content forwarder (default) O 1 Publisher discovery (i.e., only FHR can reply) F 0 Request based on FIB's forwarding strategy (default) F 1 Full discovery request. Request to possible multiple upstream routers specified in FIB simultaneously V 0 No reply validation (default) V 1 Reply sender validates Reply message Figure 9: Codes and types specified in Flags field 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Type (=T_DISC_REQ) | Length | +---------------+---------------+---------------+---------------+ | Request Arrival Time | +---------------+---------------+---------------+---------------+ / Node Identifier / +---------------+---------------+---------------+---------------+ Figure 10: Request block TLV (packet payload) Code Type name ============== =================== %x0000 T_NAME [1] %x0001 T_PAYLOAD [1] %x0002 T_KEYIDRESTR [1] %x0003 T_OBJHASHRESTR [1] %x0005 T_PAYLDTYPE [1] %x0006 T_EXPIRY [1] %x0007-%x000C Reserved [1] %x000D T_DISC_REQ %x000E T_DISC_REPLY %x0FFE T_PAD [1] %x0FFF T_ORG [1] %x1000-%x1FFF Reserved [1] Figure 11: CCNx Message Type Namespace Asaeda, et al. Expires 1 July 2023 [Page 14] Internet-Draft CCNinfo December 2022 Type: 16 bits Format of the Value field. For the Request block TLV, the type value(s) MUST be T_DISC_REQ (see Figure 11) in the current specification. Length: 16 bits Length of Value field in octets. Request Arrival Time: 32 bits The Request Arrival Time is a 32-bit NTP timestamp specifying the arrival time of the CCNinfo Request message at the router. The 32-bit form of an NTP timestamp consists of the middle 32 bits of the full 64-bit form; that is, the low 16 bits of the integer part and the high 16 bits of the fractional part. The following formula converts from a timespec (fractional part in nanoseconds) to a 32-bit NTP timestamp: request_arrival_time = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) The constant 32384 is the number of seconds from Jan 1, 1900 to Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125) is a reduction of ((tv.tv_nsec / 1000000000) << 16), where "<<" denotes a logical left shift. Note that it is RECOMMENDED for all the routers on the path to have synchronized clocks to measure one-way latency per hop; however, even if they do not have synchronized clocks, CCNinfo measures the RTT between the content forwarder and consumer. Node Identifier: variable length This field specifies the node identifier (e.g., node name or hash- based self-certifying name [11]) or all-zeros if unknown. This document assumes that the Name TLV defined in the CCNx TLV format [1] can be used for this field and the node identifier is specified in it. Asaeda, et al. Expires 1 July 2023 [Page 15] Internet-Draft CCNinfo December 2022 3.1.2. Report Block TLV A CCNinfo user and each upstream router along the path would insert their own Report block TLV without changing the Type field of the fixed header of the Request message until one of these routers is ready to send a Reply. In the Report block TLV (Figure 12), the Request Arrival Time and Node Identifier MUST be inserted. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Type (=T_DISC_REPORT) | Length | +---------------+---------------+---------------+---------------+ | Request Arrival Time | +---------------+---------------+---------------+---------------+ / Node Identifier / +---------------+---------------+---------------+---------------+ Figure 12: Report block TLV (hop-by-hop header) Type: 16 bits Format of the Value field. For the Report block TLV, the type value(s) MUST be T_DISC_REPORT in the current specification. For all the available types for hop-by-hop type namespace, please see Figure 8. Length: 16 bits Length of Value field in octets. Request Arrival Time: 32 bits Same definition as given in Section 3.1.1. Node Identifier: variable length Same definition as given in Section 3.1.1. 3.1.3. Content Name Specification Specifications of the Name TLV (whose type value is T_NAME) and the Name Segment TLVs are described in [1], which are followed by CCNinfo. CCNinfo enables to specification of the content name either with a prefix name without chunk number (such as "ccnx:/news/today") or an exact name (such as "ccnx:/news/today/Chunk=10"). When a CCNinfo user specifies a prefix name, s/he will obtain the summary information of the matched content objects in the content forwarder. Asaeda, et al. Expires 1 July 2023 [Page 16] Internet-Draft CCNinfo December 2022 In contrast, when a CCNinfo user specifies an exact name, s/he will obtain only about the specified content object in the content forwarder. A CCNinfo Request message MUST NOT be sent only with a scheme name, ccnx:/. It will be rejected and discarded by routers. 3.2. Reply Message When a content forwarder receives a CCNinfo Request message from an appropriate adjacent neighbor router, it inserts its own Reply block TLV and Reply sub-block TLV(s) to the Request message and turns the Request into the Reply by changing the Type field of the fixed header of the Request message from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY. The Reply message (see Figure 13) is then forwarded back toward the CCNinfo user in a hop-by-hop manner. Asaeda, et al. Expires 1 July 2023 [Page 17] Internet-Draft CCNinfo December 2022 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Version | PacketType | PacketLength | +---------------+---------------+-------------+-+---------------+ | HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength | +===============+===============+=============+=+===============+ / Request header block TLV / +---------------+---------------+---------------+---------------+ / . / / . / / n Report block TLVs / / . / / . / +===============+===============+===============+===============+ | Type (=T_DISCOVERY) | MessageLength | +---------------+---------------+---------------+---------------+ | T_NAME | Length | +---------------+---------------+---------------+---------------+ / Name segment TLVs (name prefix specified by CCNinfo user) / +---------------+---------------+---------------+---------------+ / Request block TLV / +---------------+---------------+---------------+---------------+ / Reply block TLV / +---------------+---------------+---------------+---------------+ / Reply sub-block TLV 1 / +---------------+---------------+---------------+---------------+ / . / / . / +---------------+---------------+---------------+---------------+ / Reply sub-block TLV k / +---------------+---------------+---------------+---------------+ / Optional CCNx ValidationAlgorithm TLV / +---------------+---------------+---------------+---------------+ / Optional CCNx ValidationPayload TLV (ValidationAlg required) / +---------------+---------------+---------------+---------------+ Figure 13: Reply message consists of a fixed header, Request block TLV, Report block TLV(s), Name TLV, and Reply block/sub- block TLV(s) 3.2.1. Reply Block TLV The Reply block TLV is an envelope for the Reply sub-block TLV(s) (explained from the next section). Asaeda, et al. Expires 1 July 2023 [Page 18] Internet-Draft CCNinfo December 2022 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Type (=T_DISC_REPLY) | Length | +---------------+---------------+---------------+---------------+ | Request Arrival Time | +---------------+---------------+---------------+---------------+ / Node Identifier / +---------------+---------------+---------------+---------------+ Figure 14: Reply block TLV (packet payload) Type: 16 bits Format of the Value field. For the Reply block TLV, the type value MUST be T_DISC_REPLY shown in Figure 11 in the current specification. Length: 16 bits Length of the Value field in octets. This length is the total length of Reply sub-block(s). Request Arrival Time: 32 bits Same definition as given in Section 3.1.1. Node Identifier: variable length Same definition as given in Section 3.1.1. 3.2.1.1. Reply Sub-Block TLV The router on the traced path will add one or multiple Reply sub- blocks followed by the Reply block TLV before sending the Reply to its neighbor router. This section describes the Reply sub-block TLV for informing various cache states and conditions as shown in Figure 15. (Other Reply sub-block TLVs will be discussed in separate document(s).) Asaeda, et al. Expires 1 July 2023 [Page 19] Internet-Draft CCNinfo December 2022 Note that some routers may not be capable of reporting the following values, such as Object Size, Object Count, # Received Interest, First Seqnum, Last Seqnum, Elapsed Cache Time, and Remain Cache Lifetime, shown in Figure 15, or do not report these values due to their policy. In that case, the routers set these fields to a value of all ones (i.e., %xFFFFFFFF). The value of each field will be also all- one when the value is equal to or bigger than the maximum size expressed by the 32-bit field. The CCNinfo user program MUST inform that these values are not valid if the fields received are set to the value of all ones. If the cache is refreshed after reboot, the value in each field MUST be refreshed (i.e., MUST be set to 0). If the cache remains after reboot, the value MUST NOT be refreshed (i.e., MUST be reflected as it is). 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | Object Size | +---------------+---------------+---------------+---------------+ | Object Count | +---------------+---------------+---------------+---------------+ | # Received Interest | +---------------+---------------+---------------+---------------+ | First Seqnum | +---------------+---------------+---------------+---------------+ | Last Seqnum | +---------------+---------------+---------------+---------------+ | Elapsed Cache Time | +---------------+---------------+---------------+---------------+ | Remain Cache Lifetime | +---------------+---------------+---------------+---------------+ | T_NAME | Length | +---------------+---------------+---------------+---------------+ / Name Segment TLVs / +---------------+---------------+---------------+---------------+ Figure 15: Reply sub-block TLV for T_DISC_CONTENT and T_DISC_CONTENT_PUBLISHER (packet payload) Asaeda, et al. Expires 1 July 2023 [Page 20] Internet-Draft CCNinfo December 2022 Code Type name ============= =========================== %x0000 T_DISC_CONTENT %x0001 T_DISC_CONTENT_PUBLISHER %x0FFF T_ORG %x1000-%x1FFF Reserved (Experimental Use) Figure 16: CCNinfo Reply Type Namespace Type: 16 bits Format of the Value field. For the Reply sub-block TLV, the type value MUST be either T_DISC_CONTENT or T_DISC_CONTENT_PUBLISHER defined in the CCNinfo Reply Type Namespace (Figure 16). T_DISC_CONTENT is specified when the cache information is replied from a caching router. T_DISC_CONTENT_PUBLISHER is specified when the content information is replied from a FHR attached to a publisher. Length: 16 bits Length of the Value field in octets. Object Size: 32 bits The total size (KB) of the unexpired content objects. Values less than 1 KB are truncated. Note that the maximum size expressed by the 32-bit field is approximately 4.29 TB. Object Count: 32 bits The number of the unexpired content objects. Note that the maximum count expressed by the 32-bit field is approximately 4.29 billion. # Received Interest: 32 bits The total number of the received Interest messages to retrieve the cached content objects. First Seqnum: 32 bits The first sequential number of the unexpired content objects. Last Seqnum: 32 bits Asaeda, et al. Expires 1 July 2023 [Page 21] Internet-Draft CCNinfo December 2022 The last sequential number of the unexpired content objects. The First Seqnum and Last Seqnum do not guarantee the consecutiveness of the cached content objects; however, knowing these values may help in the analysis of consecutive or discontinuous chunks such as [12]. Elapsed Cache Time: 32 bits The elapsed time (seconds) after the oldest content object of the content is cached. Remain Cache Lifetime: 32 bits The lifetime (seconds) of a content object, which is lastly cached. 4. CCNinfo User Behavior 4.1. Sending CCNinfo Request A CCNinfo user invokes a CCNinfo user program (e.g., ccninfo command) that initiates a CCNinfo Request message and sends it to the user's adjacent neighbor router(s) of interest. The user later obtains both the routing path information and in-network cache information in the single Reply. When the CCNinfo user program initiates a Request message, it MUST insert the necessary values, i.e., the "Request ID" and the "Node Identifier", in the Request block. The Request ID MUST be unique for the CCNinfo user until s/he receives the corresponding Reply message(s) or the Request is timed out. Owing to some policies, a router may want to validate the CCNinfo Requests using the CCNx ValidationPayload TLV (whether it accepts the Request or not) especially when the router receives the "full discovery request" (see Section 5.3.2). Accordingly, the CCNinfo user program MAY require validating the Request message and appending the user's signature into the CCNx ValidationPayload TLV. The router then forwards the Request message. If the router does not approve the Request, it rejects the Request message as described in Section 6.11. After the CCNinfo user program sends the Request message, until the Reply is timed out or the expected numbers of Replies or a Reply message with a non-zero ReturnCode in the fixed header is received, the CCNinfo user program MUST keep the following information: HopLimit, specified in the fixed header, Request ID, Flags, Node Identifier, and Request Arrival Time, specified in the Request block. Asaeda, et al. Expires 1 July 2023 [Page 22] Internet-Draft CCNinfo December 2022 4.1.1. Routing Path Information A CCNinfo user can send a CCNinfo Request for investigating the routing path information for the specified named content. Using the Request, a legitimate user can obtain 1) the node identifiers of the intermediate routers, 2) node identifier of the content forwarder, 3) number of hops between the content forwarder and consumer, and 4) RTT between the content forwarder and consumer, per name prefix. This CCNinfo Request is terminated when it reaches the content forwarder. 4.1.2. In-Network Cache Information A CCNinfo user can send a CCNinfo Request for investigating in- network cache information. Using the Request, a legitimate user can obtain 1) the size of cached content objects, 2) number of cached content objects, 3) number of accesses (i.e., received Interests) per content, and 4) lifetime and expiration time of the cached content objects, for Content Store (CS) in the content forwarder, unless the content forwarder is capable of reporting them (see Section 3.2.1.1). This CCNinfo Request is terminated when it reaches the content forwarder. 4.2. Receiving CCNinfo Reply A CCNinfo user program will receive one or multiple CCNinfo Reply messages from the adjacent neighbor router(s). When the program receives the Reply, it MUST compare the kept Request ID and Node Identifier to identify the Request and Reply pair. If they do not match, the Reply message MUST be silently discarded. If the number of Report blocks in the received Reply is more than the initial HopLimit value (which was inserted in the original Request), the Reply MUST be silently ignored. After the CCNinfo user has determined that s/he has traced the whole path or the maximum path that s/he can be expected to, s/he might collect statistics by waiting for a timeout. Useful statistics provided by CCNinfo are stated in Section 8. 5. Router Behavior 5.1. User and Neighbor Verification Upon receiving a CCNinfo Request message, a router MAY examine whether a valid CCNinfo user has sent the message. If the router recognizes that the Request sender's signature specified in the Request is invalid, it SHOULD terminate the Request, as defined in Section 6.4. Asaeda, et al. Expires 1 July 2023 [Page 23] Internet-Draft CCNinfo December 2022 Upon receiving a CCNinfo Request/Reply message, a router MAY examine whether the message comes from a valid adjacent neighbor node. If the router recognizes that the Request/Reply sender is invalid, it SHOULD silently ignore the Request/Reply message, as specified in Section 10.9. 5.2. Receiving CCNinfo Request After a router accepts the CCNinfo Request message, it performs the following steps. 1. The value of "HopLimit" in the fixed header and that of "SkipHop (Skip Hop Count)" in the Request block are counters that are decremented with each hop. If the HopLimit value is zero, the router terminates the Request, as defined in Section 6.5. If the SkipHop value is equal to or more than the HopLimit value, the router terminates the Request, as defined in Section 6.4. Otherwise, until the SkipHop value becomes zero, the router forwards the Request message to the upstream router(s) without adding its own Report block and without replying to the Request. If the router does not know the upstream router(s) regarding the specified name prefix, it terminates the Request, as defined in Section 6.5. It should be noted that the Request messages are terminated at the FHR; therefore, although the maximum value for the HopLimit is 255 and that for SkipHop is 15, if the Request messages reach the FHR before the HopLimit or SkipHop value becomes 0, the FHR silently discards the Request message and the Request is timed out. 2. The router examines the Flags field (specified in Figure 9) in the Request block of the received CCNinfo Request. If the "C" flag is not set, it is categorized as the "routing path information discovery". If the "C" flag is set, it is the "cache information discovery". If the "O" flag is set, it is the "publisher discovery". 3. If the Request is either "cache information discovery" or "routing path information discovery", the router examines its FIB and CS. If the router caches the specified content, it sends the Reply message with its own Reply block and sub-block(s). If the router cannot insert its own Reply block or sub-block(s) because of no space, it terminates the Request, as specified in Section 6.7. If the router does not cache the specified content but knows the upstream neighbor router(s) for the specified name prefix, it creates the PIT entry, and inserts its own Report block in the hop-by-hop header and forwards the Request to the upstream neighbor(s). If the router cannot insert its own Report block because of no space, or if the router does not cache the Asaeda, et al. Expires 1 July 2023 [Page 24] Internet-Draft CCNinfo December 2022 specified content and does not know the upstream neighbor router(s) for the specified name prefix, it terminates the Request, as defined in Section 6.5. 4. If the Request is the "publisher discovery", the router examines whether it is the FHR for the requested content. If the router is the FHR, it sends the Reply message with its own Report block and sub-blocks (in the case of cache information discovery) or the Reply message with its own Report block without adding any Reply sub-blocks (in the case of routing path information discovery). If the router is not the FHR but knows the upstream neighbor router(s) for the specified name prefix, it creates the PIT entry, and inserts its own Report block and forwards the Request to the upstream neighbor(s). If the router cannot insert its own Report block in the hop-by-hop header because of no space, it terminates the Request, as specified in Section 6.7. If the router is not the FHR and does not know the upstream neighbor router(s) for the specified name prefix, it terminates the Request, as defined in Section 6.5. Note that in Cefore [14], there is an API by which a publisher informs the application prefix to the FHR and the FHR registers it into the FIB. The prefix entry then can be statically configured on other routers or announced by a routing protocol. 5.3. Forwarding CCNinfo Request 5.3.1. Regular Request When a router decides to forward a Request message with its Report block to its upstream router(s), it specifies the Request Arrival Time and Node Identifier in the Report block of the Request message. The router then forwards the Request message upstream toward the publisher or caching router based on the FIB entry like the ordinary Interest-Data exchanges in CCN. When the router forwards the Request message, it MUST record the F flag and Request ID in the Request block of the Request message and exploiting path labels (specified in Section 1) at the corresponding PIT entry. The router can later check the PIT entry to correctly forward the Reply message(s) back. Asaeda, et al. Expires 1 July 2023 [Page 25] Internet-Draft CCNinfo December 2022 CCNinfo supports multipath forwarding. The Request messages can be forwarded to multiple neighbor routers. Some routers may have a strategy for multipath forwarding; when a router sends Interest messages to multiple neighbor routers, it may delay or prioritize to send the message to the upstream routers. The CCNinfo Request, as the default, complies with such strategies; a CCNinfo user could trace the actual forwarding path based on the forwarding strategy and will receive a single Reply message such as a content object. 5.3.2. Full Discovery Request There may be a case wherein a CCNinfo user wants to discover all possible forwarding paths and content forwarders based on the routers' FIBs. The "full discovery request" enables this functionality. If a CCNinfo user sets the F flag in the Request block of the Request message (as seen in Figure 9) to request the full discovery, the upstream routers simultaneously forward the Requests to all multiple upstream routers based on the FIBs. Then, the CCNinfo user can trace all possible forwarding paths. As seen in Figure 17, each router forwards the Reply message along its PIT entry and finally, the CCNinfo user receives two Reply messages: one from the FHR (Router C) and the other from the Caching router. 3. Reply(C) 2. Reply(C) 3. Reply(P) 2. Reply(P) 1. Reply(P) +----+ +----+ +----+ | | | | | | v | v | v | +--------+ +--------+ +--------+ +--------+ +---------+ | CCNinfo|----| Router |----| Router |----| Router |----|Publisher| | user | | A | | B | | C | | | +--------+ +--------+ +--------+ +--------+ +---------+ ^ \ +-------+ 1. Reply(C) \ | Cache | \ +---------+ | \| Caching |----+ | router | +---------+ Figure 17: Full discovery request. Reply messages forwarded by publisher and routers. Asaeda, et al. Expires 1 July 2023 [Page 26] Internet-Draft CCNinfo December 2022 To receive different Reply messages forwarded from different routers, the PIT entries initiated by CCNinfo remain until the configured CCNinfo Reply Timeout (Section 7.1) is expired. In other words, unlike the ordinary Interest-Data exchanges in CCN, if routers that accept the full discovery request receive the full discovery request, the routers SHOULD NOT remove the PIT entry created by the full discovery request until the CCNinfo Reply Timeout value expires. Note that the full discovery request is an OPTIONAL implementation of CCNinfo; it may not be implemented on routers. Even if it is implemented on a router, it may not accept the full discovery request from non-validated CCNinfo users or routers or because of its policy. If a router does not accept the full discovery request, it rejects the full discovery request as described in Section 6.11. Routers that enable the full discovery request MAY rate-limit Replies, as described in Section 10.8 as well. 5.4. Sending CCNinfo Reply If there is a caching router or FHR for the specified content within the specified hop count along the path, the caching router or FHR sends back the Reply message toward the CCNinfo user and terminates the Request. When a router decides to send a Reply message to its downstream neighbor router or the CCNinfo user with NO_ERROR return code, it inserts a Report block with the Request Arrival Time and Node Identifier to the Request message. Then, the router inserts the corresponding Reply sub-block(s) (Figure 15) to the payload. The router finally changes the Type field in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards the message back as the Reply toward the CCNinfo user in a hop-by-hop manner. If a router cannot continue the Request, the router MUST put an appropriate ReturnCode in the Request message, change the Type field value in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY, and forward the Reply message back toward the CCNinfo user to terminate the Request (see Section 6). 5.5. Forwarding CCNinfo Reply When a router receives a CCNinfo Reply whose Request ID and Node Identifier match those in the PIT entry, sent from a valid adjacent neighbor router, it forwards the CCNinfo Reply back toward the CCNinfo user. If the router does not receive the corresponding Reply within the [CCNinfo Reply Timeout] period, then it removes the corresponding PIT entry and terminates the trace. Asaeda, et al. Expires 1 July 2023 [Page 27] Internet-Draft CCNinfo December 2022 The Flags field in the Request block TLV is used to indicate whether the router keeps the PIT entry during the CCNinfo Reply Timeout even after one or more corresponding Reply messages are forwarded. When the CCNinfo user does not set the F flag (i.e., "0"), the intermediate routers immediately remove the PIT entry whenever they forward the corresponding Reply message. When the CCNinfo user sets the F flag (i.e., "1"), which means the CCNinfo user chooses the "full discovery request" (see Section 5.3.2), the intermediate routers keep the PIT entry within the [CCNinfo Reply Timeout] period. After this timeout, the PIT entry is removed. CCNinfo Replies MUST NOT be cached in routers upon the transmission of Reply messages. 5.6. PIT Entry Management for Multipath Support Within a network with multipath condition, there is a case (Figure 18) wherein a single CCNinfo Request is split into multiple Requests (e.g., at Router A), which are injected into a single router (Router D). In this case, multiple Replies with the same Request ID and Node Identifier including different Report blocks are received by the router (Router D). +--------+ | Router | | B | +--------+ / \ / \ +--------+ +--------+ +--------+ +---------+ | CCNinfo|----| Router | | Router | ... |Publisher| | user | | A | | D | | | +--------+ +--------+ +--------+ +---------+ \ / \ / +--------+ | Router | | C | +--------+ Figure 18 To recognize different CCNinfo Reply messages, the routers MUST distinguish the PIT entries by the Request ID and exploiting path labels, which could be a hash value of the concatenation information of the cumulate Node Identifiers in the hop-by-hop header and the specified content name. For example, when Router D in Figure 18 receives a CCNinfo Request from Router B, its PIT includes the Asaeda, et al. Expires 1 July 2023 [Page 28] Internet-Draft CCNinfo December 2022 Request ID and value such as H((Router_A|Router_B)|content_name), where "H" indicates some hash function and "|" indicates concatenation. When Router D receives a CCNinfo Request from Router C, its PIT includes the same Request ID and value of H((Router_A|Router_C)|content_name). Two different Replies are later received on Router D and each Reply is appropriately forwarded to Router B and Router C, respectively. Note that two Reply messages coming from Router B and Router C are reached at Router A, but the CCNinfo user can only receive the first Reply message either from Router B or Router C as Router A removes the corresponding PIT entry after it forwards the first Reply. To avoid routing loops, when a router seeks the cumulate Node Identifiers of the Report blocks in the hop-by-hop header, it MUST examine whether its own Node Identifier is not previously inserted. If a router detects its own Node Identifier in the hop-by-hop header, the router inserts its Report block and terminates the Request as will be described in Section 6.8. 6. CCNinfo Termination When performing a hop-by-hop trace, it is necessary to determine when to stop the trace. There are several cases when an intermediate router might return a Reply before a Request reaches the caching router or the FHR. 6.1. Arriving at First-hop Router A CCNinfo Request can be determined to have arrived at the FHR. To ensure that a router recognizes that it is the FHR for the specified content, it needs to have a FIB entry (or attach) to the corresponding publisher or the content. 6.2. Arriving at Router Having Cache A CCNinfo Request can be determined to have arrived at the router having the specified content cache within the specified HopLimit. 6.3. Arriving at Last Router A CCNinfo Request can be determined to have arrived at the last router of the specified HopLimit. If the last router does not have the corresponding cache, it MUST insert its Report block and send the Reply message with NO_INFO return code without appending any Reply (sub-)block TLVs. Asaeda, et al. Expires 1 July 2023 [Page 29] Internet-Draft CCNinfo December 2022 6.4. Invalid Request If the router does not validate the Request or the Reply even it is required, the router MUST note a ReturnCode of INVALID_REQUEST in the fixed header of the message, insert its Report block, and forward the message as the Reply back to the CCNinfo user. The router MAY, however, randomly ignore the received invalid messages. (See Section 10.7.) 6.5. No Route If the router cannot determine the routing paths or neighbor routers for the specified name prefix within the specified HopLimit, it MUST note a ReturnCode of NO_ROUTE in the fixed header of the message, insert its Report block, and forward the message as the Reply back to the CCNinfo user. 6.6. No Information If the router does not have any information about the specified name prefix within the specified HopLimit, it MUST note a ReturnCode of NO_INFO in the fixed header of the message, insert its Report block, and forward the message as the Reply back to the CCNinfo user. 6.7. No Space If appending the Report block or the Reply (sub-)block would make the hop-by-hop header longer than 247 bytes or the Request packet longer than the MTU of the Incoming face, the router MUST note a ReturnCode of NO_SPACE in the fixed header of the message and forward the message as the Reply back to the CCNinfo user. 6.8. Fatal Error If a CCNinfo Request has encountered a fatal error, the router MUST note a ReturnCode of FATAL_ERROR in the fixed header of the message and forward the message as the Reply back to the CCNinfo user. This may happen, for example, when the router detects some routing loop in the Request blocks (see Section 1). The fatal error can be encoded with another error: if a router detects routing loop but cannot insert its Report block, it MUST note NO_SPACE and FATAL_ERROR ReturnCodes (i.e., %x85) in the fixed header and forward the message back to the CCNinfo user. Asaeda, et al. Expires 1 July 2023 [Page 30] Internet-Draft CCNinfo December 2022 6.9. CCNinfo Reply Timeout If a router receives the Request or Reply message that expires its own [CCNinfo Reply Timeout] value (Section 7.1), the router will silently discard the Request or Reply message. 6.10. Non-Supported Node Cases will arise in which a router or a FHR along the path does not support CCNinfo. In such cases, a CCNinfo user and routers that forward the CCNinfo Request will time out the CCNinfo request. 6.11. Administratively Prohibited If CCNinfo is administratively prohibited, the router rejects the Request message and MUST send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB. The router MAY, however, randomly ignore the Request messages to be rejected (see Section 10.7). 7. Configurations 7.1. CCNinfo Reply Timeout The [CCNinfo Reply Timeout] value is used to time out a CCNinfo Reply. The value for a router can be statically configured by the router's administrators/operators. The default value is 3 (seconds). The [CCNinfo Reply Timeout] value SHOULD NOT be larger than 4 (seconds) and SHOULD NOT be lower than 2 (seconds). 7.2. HopLimit in Fixed Header If a CCNinfo user does not specify the HopLimit value in the fixed header for a Request message as the HopLimit, the HopLimit is set to 32. Note that 0 HopLimit is an invalid Request; hence, the router in this case follows the way defined in Section 6.4. 7.3. Access Control A router MAY configure the valid or invalid networks to enable an access control. The access control MAY be defined per name prefix, such as "who can retrieve which name prefix" (see Section 10.2). 8. Diagnosis and Analysis Asaeda, et al. Expires 1 July 2023 [Page 31] Internet-Draft CCNinfo December 2022 8.1. Number of Hops and RTT A CCNinfo Request message is forwarded in a hop-by-hop manner and each forwarding router appends its own Report block. We can then verify the number of hops to reach the content forwarder or publisher and the RTT between the content forwarder or publisher. 8.2. Caching Router Identification While some routers may hide their node identifiers with all-zeros in the Report blocks (as seen in Section 10.1), the routers in the path from the CCNinfo user to the content forwarder can be identified. 8.3. TTL or Hop Limit By taking the HopLimit from the content forwarder and forwarding the TTL threshold over all hops, it is possible to discover the TTL or hop limit required for the content forwarder to reach the CCNinfo user. 8.4. Time Delay If the routers have synchronized clocks, it is possible to estimate the propagation and queuing delays from the differences between the timestamps at the successive hops. However, this delay includes the control processing overhead; therefore, it is not necessarily indicative of the delay that would be experienced by the data traffic. 8.5. Path Stretch By obtaining the path stretch "d / P", where "d" is the hop count of the data and "P" is the hop count from the consumer to the publisher, we can measure the improvements in path stretch in various cases, such as in different caching and routing algorithms. We can then facilitate the investigation of the performance of the protocol. 8.6. Cache Hit Probability CCNinfo can show the number of received interests per cache or chunk on a router. Accordingly, CCNinfo measures the content popularity (i.e., the number of accesses for each content/cache), thereby enabling the investigation of the routing/caching strategy in networks. Asaeda, et al. Expires 1 July 2023 [Page 32] Internet-Draft CCNinfo December 2022 9. IANA Considerations This section details each kind of CCNx protocol value that can be registered. As per [5], this section makes assignments in four existing registries and creates a new Reply Type registry in the "Content-Centric Networking (CCNx)" registry group. The registration procedure is "RFC Required", which requires only that this document be published as an RFC. 9.1. Packet Type Registry As shown in Figure 4, CCNinfo defines two packet types, PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, whose suggested values are %x03 and %x04, respectively. 9.2. Top-Level Type Registry As shown in Figure 5, CCNinfo defines one top-level type, T_DISCOVERY, whose suggested value is %x0005. 9.3. Hop-by-Hop Type Registry As shown in Figure 8, CCNinfo defines two hop-by-hop types, T_DISC_REQHDR and T_DISC_REPORT, whose suggested values are %x0008 and %x0009, respectively. 9.4. Message Type Registry As shown in Figure 11, CCNinfo defines two message types, T_DISC_REQ and T_DISC_REPLY, whose suggested values are %x000D and %x000E, respectively. 9.5. Reply Type Registry IANA has created the "CCNx Reply Types" registry and allocated the reply types. The Type value is 2 octets. The range is %x0000-%xFFFF. As shown in Figure 16, CCNinfo defines three reply types, T_DISC_CONTENT, T_DISC_CONTENT_PUBLISHER, and T_ORG, whose suggested values are %x0000, %x0001, and %x0FFF, respectively. 10. Security Considerations This section addresses some of the security considerations. Asaeda, et al. Expires 1 July 2023 [Page 33] Internet-Draft CCNinfo December 2022 10.1. Policy-Based Information Provisioning for Request Although CCNinfo gives excellent troubleshooting cues, some network administrators or operators may not want to disclose everything about their network to the public or may wish to securely transmit private information to specific members of their networks. CCNinfo provides policy-based information provisioning, thereby allowing network administrators to specify their response policy for each router. The access policy regarding "who is allowed to retrieve" and/or "what kind of cache information" can be defined for each router. For the former type of access policy, routers with the specified content MAY examine the signature enclosed in the Request message and decide whether they should notify the content information in the Reply. If the routers decide to not notify the content information, they MUST send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB without appending any Reply (sub-)block TLVs. For the latter type of policy, the permission, whether (1) All (all cache information is disclosed), (2) Partial (cache information with a particular name prefix can (or cannot) be disclosed), or (3) Deny (no cache information is disclosed), is defined at the routers. In contrast, we entail that each router does not disrupt the forwarding of CCNinfo Request and Reply messages. When a Request message is received, the router SHOULD insert the Report block if the ReturnCode is NO_ERROR. Here, according to the policy configuration, the Node Identifier field in the Report block MAY be null (i.e., all- zeros), but the Request Arrival Time field SHOULD NOT be null. Finally, the router SHOULD forward the Request message to the upstream router toward the content forwarder if the ReturnCode is kept with NO_ERROR. 10.2. Filtering CCNinfo Users Located in Invalid Networks A router MAY support an access control mechanism to filter out Requests from invalid CCNinfo users. To accomplish this, invalid networks (or domains) could, for example, be configured via a list of allowed/disallowed networks (as observed in Section 7.3). If a Request is received from a disallowed network (according to the Node Identifier in the Request block), the Request MUST NOT be processed and the Reply with the ReturnCode of INFO_HIDDEN SHOULD be used to note that. The router MAY, however, perform rate limited logging of such events. Asaeda, et al. Expires 1 July 2023 [Page 34] Internet-Draft CCNinfo December 2022 10.3. Topology Discovery CCNinfo can be used to discover actively used topologies. If a network topology is not disclosed, CCNinfo Requests SHOULD be restricted at the border of the domain using the ADMIN_PROHIB return code. 10.4. Characteristics of Content CCNinfo can be used to discover the type of content being sent by publishers. If this information is a secret, CCNinfo Requests SHOULD be restricted at the border of the domain, using the ADMIN_PROHIB return code. 10.5. Computational Attacks CCNinfo may impose heavy tasks at content forwarders because it makes content forwarders seek their internal cache states reported in the Reply messages whenever they form the Reply messages. The current CCNinfo specification allows to return null values for several fields, such as First/Last Seqnum or Elapsed Cache Time fields in the Reply sub-block. As mentioned in Section 3.2.1.1, these values MAY be null. This means that the content forwarder can not only hide these values owing to privacy/security policies, but also skip the implementations of the complex functions to report these values. 10.6. Longer or Shorter CCNinfo Reply Timeout Routers can configure CCNinfo Reply Timeout (Section 7.1), which is the allowable timeout value to keep the PIT entry. If routers configure a longer timeout value, there may be an attractive attack vector against the PIT memory. Moreover, especially when the full discovery request option (Section 5.3) is specified for the CCNinfo Request, several Reply messages may be returned and cause a response storm. (See Section 10.8 for rate-limiting to avoid the storm). To avoid DoS attacks, routers MAY configure the timeout value, which is shorter than the user-configured CCNinfo timeout value. However, if it is too short, the Request may be timed out and the CCNinfo user does not receive all Replies; s/he only retrieves the partial path information (i.e., information about a part of the tree). There may be a way to enable incremental exploration (i.e., to explore the part of the tree that was not explored by the previous operation); however, discussing such mechanisms is out of scope of this document. Asaeda, et al. Expires 1 July 2023 [Page 35] Internet-Draft CCNinfo December 2022 10.7. Limiting Request Rates A router MAY rate-limit CCNinfo Requests by ignoring some of the consecutive messages. The router MAY randomly ignore the received messages to minimize the processing overhead, i.e., to keep fairness in processing requests, or prevent traffic amplification. In such a case, no error message is returned. The rate limit function is left to the router's implementation. 10.8. Limiting Reply Rates CCNinfo supporting multipath forwarding may result in one Request returning multiple Reply messages. To prevent abuse, the routers in the traced path MAY need to rate-limit the Replies. In such a case, no error message is returned. The rate limit function is left to the router's implementation. 10.9. Adjacency Verification It is assumed that the CCNinfo Request and Reply messages are forwarded by adjacent neighbor nodes or routers. The CCNx message format or semantics do not define a secure way to verify the node/ router adjacency, while HopAuth [11] provides a possible method for an adjacency verification and defines the corresponding message format for adjacency verification as well as the router behaviors. CCNinfo MAY use a similar method for node adjacency verification. 11. Acknowledgements The authors would like to thank Jerome Francois, Erik Kline, Spyridon Mastorakis, Paulo Mendes, Ilya Moiseenko, David Oran, and Thierry Turletti for their valuable comments and suggestions on this document. 12. References 12.1. Normative References [1] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV Format", RFC 8609, July 2019, . [2] Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", RFC 8569, July 2019, . Asaeda, et al. Expires 1 July 2023 [Page 36] Internet-Draft CCNinfo December 2022 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [4] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", May 2017, . [5] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . 12.2. Informative References [6] Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C. Tschudin, "Information-Centric Networking (ICN): Content- Centric Networking (CCNx) and Named Data Networking (NDN) Terminology", RFC 8793, June 2020, . [7] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A Tool for Measuring and Tracing Content-Centric Networks", IEEE Communications Magazine, Vol.53, No.3, pp.182-188, March 2015. [8] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and D. Oran, "ICN Ping Protocol Specification", draft-irtf- icnrg-icnping-06 (work in progress), May 2022. [9] Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and D. Oran, "ICN Traceroute Protocol Specification", draft- irtf-icnrg-icntraceroute-06 (work in progress), May 2022. [10] Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2: Traceroute Facility for IP Multicast", RFC 8487, October 2018, . [11] Li, R. and H. Asaeda, "Hop-by-Hop Authentication in Content-Centric Networking/Named Data Networking", draft- li-icnrg-hopauth-02 (work in progress), February 2020. [12] Li, R., Matsuzono, K., Asaeda, H., and X. Fu, "Consecutive Caching and Adaptive Retrieval for In-Network Big Data Sharing", Proc. IEEE ICC, Kansas City, USA, May 2018. Asaeda, et al. Expires 1 July 2023 [Page 37] Internet-Draft CCNinfo December 2022 [13] Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore: Software Platform Enabling Content-Centric Networking and Beyond", IEICE Transaction on Communications, Vol.E102-B, No.9, pp.1792-1803, September 2019. [14] "Cefore Home Page", . Appendix A. ccninfo Command and Options CCNinfo is implemented in Cefore [13][14]. The command invoked by the CCNinfo user (e.g., consumer) is named "ccninfo". The ccninfo command sends the Request message and receives the Reply message(s). There are several options that can be specified with ccninfo, while the content name prefix (e.g., ccnx:/news/today) is the mandatory parameter. The usage of ccninfo command is as follows: Usage: ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count] [-v algo] name_prefix name_prefix Prefix name of content (e.g., ccnx:/news/today) or exact name of content (e.g., ccnx:/news/today/Chunk=10) the CCNinfo user wants to trace. c option This option can be specified if a CCNinfo user needs the cache information as well as the routing path information for the specified content/cache and RTT between the CCNinfo user and content forwarder. f option This option enables the "full discovery request"; routers send CCNinfo Requests to multiple upstream faces based on their FIBs simultaneously. The CCNinfo user can then trace all possible forwarding paths. o option This option enables to trace the path to the content publisher. Each router along the path to the publisher inserts each Report block and forwards the Request message. It does not send Reply even if it caches the specified content. FHR that attaches the publisher (who has the complete set of content and is not a caching router) sends the Reply message. Asaeda, et al. Expires 1 July 2023 [Page 38] Internet-Draft CCNinfo December 2022 V option This option requests the Reply sender to validate the Reply message with the Reply sender's signature. The Reply message will then include the CCNx ValidationPayload TLV. The validation algorithm is selected by the Reply sender. r option Number of traced routers. This value is set in the "HopLimit" field located in the fixed header of the Request. For example, when the CCNinfo user invokes the CCNinfo command with this option, such as "-r 3", only three routers along the path examine their path and cache information. s option Number of skipped routers. This value is set in the "SkipHop" field located in the Request block TLV. For example, when the CCNinfo user invokes the CCNinfo command with this option, such as "-s 3", three upstream routers along the path only forward the Request message but do not append their Report blocks in the hop- by-hop header and do not send Reply messages despite having the corresponding cache. v option This option enables the CCNinfo user to validate the Request message with his/her signature. The Request message will include the CCNx ValidationPayload TLV. The validation algorithm is specified by the CCNinfo user. Authors' Addresses Hitoshi Asaeda National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi, Koganei, Tokyo 184-8795 Japan Email: asaeda@nict.go.jp Atsushi Ooka National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi, Koganei, Tokyo 184-8795 Japan Email: a-ooka@nict.go.jp Asaeda, et al. Expires 1 July 2023 [Page 39] Internet-Draft CCNinfo December 2022 Xun Shao Toyohashi University of Technology 1-1 Hibarigaoka Tempaku-cho, Toyohashi, Aichi 441-8580 Japan Email: shao.xun.ls@tut.jp Asaeda, et al. Expires 1 July 2023 [Page 40] ./draft-irtf-cfrg-vrf-15.txt0000644000764400076440000035564514274360105015427 0ustar iustiniustin CFRG S. Goldberg Internet-Draft Boston University Intended status: Informational L. Reyzin Expires: 10 February 2023 Boston University and Algorand D. Papadopoulos Hong Kong University of Science and Technology J. Vcelak NS1 9 August 2022 Verifiable Random Functions (VRFs) draft-irtf-cfrg-vrf-15 Abstract A Verifiable Random Function (VRF) is the public-key version of a keyed cryptographic hash. Only the holder of the secret key can compute the hash, but anyone with the public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures. This document specifies VRF constructions based on RSA and elliptic curves that are secure in the cryptographic random oracle model. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 10 February 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Goldberg, et al. Expires 10 February 2023 [Page 1] Internet-Draft VRF August 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. VRF Algorithms . . . . . . . . . . . . . . . . . . . . . . . 4 3. VRF Security Properties . . . . . . . . . . . . . . . . . . . 5 3.1. Full Uniqueness . . . . . . . . . . . . . . . . . . . . . 5 3.2. Full Collison Resistance . . . . . . . . . . . . . . . . 6 3.3. Trusted Uniqueness and Trusted Collision Resistance . . . 6 3.4. Full Pseudorandomness or Selective Pseudorandomness . . . 7 3.5. Unpredictability Under Malicious Key Generation . . . . . 8 4. RSA Full Domain Hash VRF (RSA-FDH-VRF) . . . . . . . . . . . 8 4.1. RSA-FDH-VRF Proving . . . . . . . . . . . . . . . . . . . 10 4.2. RSA-FDH-VRF Proof to Hash . . . . . . . . . . . . . . . . 10 4.3. RSA-FDH-VRF Verifying . . . . . . . . . . . . . . . . . . 11 4.4. RSA-FDH-VRF Ciphersuites . . . . . . . . . . . . . . . . 12 5. Elliptic Curve VRF (ECVRF) . . . . . . . . . . . . . . . . . 12 5.1. ECVRF Proving . . . . . . . . . . . . . . . . . . . . . . 15 5.2. ECVRF Proof to Hash . . . . . . . . . . . . . . . . . . . 16 5.3. ECVRF Verifying . . . . . . . . . . . . . . . . . . . . . 16 5.4. ECVRF Auxiliary Functions . . . . . . . . . . . . . . . . 18 5.4.1. ECVRF Encode to Curve . . . . . . . . . . . . . . . . 18 5.4.2. ECVRF Nonce Generation . . . . . . . . . . . . . . . 20 5.4.3. ECVRF Challenge Generation . . . . . . . . . . . . . 22 5.4.4. ECVRF Decode Proof . . . . . . . . . . . . . . . . . 22 5.4.5. ECVRF Validate Key . . . . . . . . . . . . . . . . . 23 5.5. ECVRF Ciphersuites . . . . . . . . . . . . . . . . . . . 25 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7.1. Key Generation . . . . . . . . . . . . . . . . . . . . . 29 7.1.1. Uniqueness and collision resistance under malicious key generation . . . . . . . . . . . . . . . . . . . . . 29 7.1.2. Pseudorandomness under malicious key generation . . . 29 7.1.3. Unpredictability under malicious key generation . . . 30 7.2. Security Levels . . . . . . . . . . . . . . . . . . . . . 30 7.3. Selective vs. Full Pseudorandomness . . . . . . . . . . . 31 7.4. Proper pseudorandom nonce for ECVRF . . . . . . . . . . . 31 7.5. Side-channel attacks . . . . . . . . . . . . . . . . . . 32 Goldberg, et al. Expires 10 February 2023 [Page 2] Internet-Draft VRF August 2022 7.6. Proofs provide no secrecy for the VRF input . . . . . . . 32 7.7. Prehashing . . . . . . . . . . . . . . . . . . . . . . . 33 7.8. Hash function domain separation . . . . . . . . . . . . . 33 7.9. Hash function salting . . . . . . . . . . . . . . . . . . 34 7.10. Futureproofing . . . . . . . . . . . . . . . . . . . . . 34 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 10.2. Informative References . . . . . . . . . . . . . . . . . 38 Appendix A. Test Vectors for the RSA-FDH-VRF ciphersuites . . . 39 A.1. RSA-FDH-VRF-SHA256 . . . . . . . . . . . . . . . . . . . 41 A.2. RSA-FDH-VRF-SHA384 . . . . . . . . . . . . . . . . . . . 43 A.3. RSA-FDH-VRF-SHA512 . . . . . . . . . . . . . . . . . . . 45 Appendix B. Test Vectors for the ECVRF ciphersuites . . . . . . 47 B.1. ECVRF-P256-SHA256-TAI . . . . . . . . . . . . . . . . . . 47 B.2. ECVRF-P256-SHA256-SSWU . . . . . . . . . . . . . . . . . 49 B.3. ECVRF-EDWARDS25519-SHA512-TAI . . . . . . . . . . . . . . 51 B.4. ECVRF-EDWARDS25519-SHA512-ELL2 . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 1. Introduction A Verifiable Random Function (VRF) [MRV99] is the public-key version of a keyed cryptographic hash. Only the holder of the VRF secret key can compute the hash, but anyone with the corresponding public key can verify the correctness of the hash. A key application of the VRF is to provide privacy against offline dictionary attacks (also known as enumeration attacks) on data stored in a hash-based data structure. In this application, a Prover holds the VRF secret key and uses the VRF hashing to construct a hash-based data structure on the input data. Due to the nature of the VRF, only the Prover can answer queries about whether or not some data is stored in the data structure. Anyone who knows the VRF public key can verify that the Prover has answered the queries correctly. However, no offline inferences (i.e. inferences without querying the Prover) can be made about the data stored in the data structure. This document defines VRFs based on RSA and elliptic curves. The choices of VRFs for inclusion into this document were based, in part, on synergy with existing RFCs and commonly available implementations of individual components that are used within the VRFs. Goldberg, et al. Expires 10 February 2023 [Page 3] Internet-Draft VRF August 2022 The particular choice of the VRF for a given application depends on the desired security properties, the availability of cryptographically strong implementations, efficiency constraints, and the trust one places in RSA and elliptic curve Diffie-Hellman assumptions (and the trust in a particular choice of curve in case of elliptic curves). Differences in the security properties provided by the different options are discussed in Section 3 and Section 7. This document represents the consensus of the Crypto Forum Research Group (CFRG). 1.1. Requirements 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 [RFC8174]. 1.2. Terminology The following terminology is used through this document: SK: The secret key for the VRF. (Note: the secret key is also sometimes called "private key".) PK: The public key for the VRF. alpha or alpha_string: The input to be hashed by the VRF. beta or beta_string: The VRF hash output. pi or pi_string: The VRF proof. Prover: The Prover holds the VRF secret key SK and public key PK. Verifier: The Verifier holds the VRF public key PK. Adversary: Potential attacker; often used to define a security property. Malicious (or adversarial): Performed by an adversary. 2. VRF Algorithms A VRF comes with a key generation algorithm that generates a VRF public key PK and secret key SK. The prover hashes an input alpha using the VRF secret key SK to obtain a VRF hash output beta Goldberg, et al. Expires 10 February 2023 [Page 4] Internet-Draft VRF August 2022 beta = VRF_hash(SK, alpha) The VRF_hash algorithm is deterministic, in the sense that it always produces the same output beta given the same pair of inputs (SK, alpha). The prover also uses the secret key SK to construct a proof pi that beta is the correct hash output pi = VRF_prove(SK, alpha) The VRFs defined in this document allow anyone to deterministically obtain the VRF hash output beta directly from the proof value pi by using the function VRF_proof_to_hash: beta = VRF_proof_to_hash(pi) Thus, for VRFs defined in this document, VRF_hash is defined as VRF_hash(SK, alpha) = VRF_proof_to_hash(VRF_prove(SK, alpha)), and therefore this document will specify VRF_prove and VRF_proof_to_hash rather than VRF_hash. The proof pi allows a Verifier holding the public key PK to verify that beta is the correct VRF hash of input alpha under key PK. Thus, the VRFs defined in this document also come with an algorithm VRF_verify(PK, alpha, pi) that outputs (VALID, beta = VRF_proof_to_hash(pi)) if pi is valid, and INVALID otherwise. 3. VRF Security Properties VRFs are designed to ensure the following security properties: uniqueness (full or trusted), collision resistance (full or trusted), and pseudorandomness (full or selective). Some are designed to also ensure unpredictability under malicious key generation. We now describe these properties. 3.1. Full Uniqueness Uniqueness means that, for any fixed VRF public key and for any input alpha, it is infeasible to find proofs for more than one VRF output beta. More precisely, "full uniqueness" means that an adversary cannot find Goldberg, et al. Expires 10 February 2023 [Page 5] Internet-Draft VRF August 2022 * a VRF public key PK, * a VRF input alpha, * and two proofs pi1 and pi2 such that * VRF_verify(PK, alpha, pi1) outputs (VALID, beta1), * VRF_verify(PK, alpha, pi2) outputs (VALID, beta2), * and beta1 is not equal to beta2. 3.2. Full Collison Resistance Like cryptographic hash functions, VRFs are collision resistant. Collison resistance means that it is infeasible to find two different inputs alpha1 and alpha2 with the same output beta. More precisely, "full collision resistance" means that an adversary cannot find * a VRF public key PK, * two VRF inputs alpha1 and alpha2 that are not equal to each other, * and two proofs pi1 and pi2 such that * VRF_verify(PK, alpha1, pi1) outputs (VALID, beta1), * VRF_verify(PK, alpha2, pi2) outputs (VALID, beta2), * and beta1 is equal to beta2. 3.3. Trusted Uniqueness and Trusted Collision Resistance Full uniqueness and full collision resistance hold even if the VRF keys are generated maliciously. For some applications, it is sufficient for a VRF to possess weaker security properties than full uniqueness and full collision resistance, called "trusted uniqueness" and "trusted collision resistance". These properties are the same as full uniqueness and full collision resistance, respectively, but are not guaranteed to hold if the adversary gets to choose the VRF public key PK. Instead, they are guaranteed to hold only if the VRF keys PK and SK are generated as specified by the VRF key generation algorithm Goldberg, et al. Expires 10 February 2023 [Page 6] Internet-Draft VRF August 2022 and then given to the adversary. In other words, they are guaranteed to hold even if the adversary has the knowledge of SK and PK, but not guaranteed to hold if the adversary has the ability to choose SK and PK. As further discussed in Section 7.1.1, some VRFs specified in this document satisfy only trusted uniqueness and trusted collision resistance. VRFs in this document that satisfy only trusted uniqueness and trusted collision resistance MUST NOT be used in applications that need protection against adversarial VRF key generation. 3.4. Full Pseudorandomness or Selective Pseudorandomness Pseudorandomness ensures that when someone who does not know SK sees a VRF hash output beta without its corresponding VRF proof pi, then beta is indistinguishable from a random value. More precisely, suppose the public and secret VRF keys (PK, SK) were generated correctly. Pseudorandomness ensures that the VRF hash output beta (without its corresponding VRF proof pi) on any adversarially chosen "target" VRF input alpha looks indistinguishable from random for any adversary who does not know the VRF secret key SK. This holds even if the adversary sees VRF hash outputs beta' and proofs pi' for multiple other inputs alpha' (and even if those other inputs alpha' are chosen by the adversary). "Full pseudorandomness" security property holds even against an adversary who is allowed to choose the "target" VRF input alpha at any time, even after it observes VRF outputs beta' and proofs pi' on a variety of chosen inputs alpha'. "Selective pseudorandomness" is a weaker security property that suffices in many applications. This security property holds against an adversary who chooses the target VRF input alpha first, before it learns the VRF public key PK and obtains VRF outputs beta' and proofs pi' on other inputs alpha' of its choice. As further discussed in Section 7.3, VRFs specified in this document satisfy both full pseudorandomness and selective pseudorandomness, but their quantitative security against the selective pseudorandomness attack is stronger. It is important to remember that the VRF output beta is always distinguishable from random by the Prover, or by any other party that knows the VRF secret key SK. Such a party can easily distinguish beta from a random value by comparing beta to the result of VRF_hash(SK, alpha). Goldberg, et al. Expires 10 February 2023 [Page 7] Internet-Draft VRF August 2022 Similarly, the VRF output beta is always distinguishable from random by any party that knows a valid VRF proof pi corresponding to the VRF input alpha, even if this party does not know the VRF secret key SK. Such a party can easily distinguish beta from a random value by checking whether VRF_verify(PK, alpha, pi) returns (VALID, beta). Additionally, the VRF output beta may be distinguishable from random if VRF key generation was not done correctly. (For example, if VRF keys were generated with bad randomness.) 3.5. Unpredictability Under Malicious Key Generation As explained in Section 3.4, pseudorandomness cannot hold against malicious key generation. For instance, if an adversary outputs VRF keys that are deterministically generated (or hard-coded and publicly known), then the outputs are easily derived by anyone and are therefore not pseudorandom. There is, however, a different type of unpredictability that is desirable in certain VRF applications (such as leader selection in the consensus protocols of [GHMVZ17] and [DGKR18]), called "unpredictability under malicious key generation". This property is similar to the unpredictability achieved by an (ordinary, unkeyed) cryptographic hash function: if the input has enough entropy (i.e., cannot be predicted), then the correct output is indistinguishable from uniformly random, no matter how the VRF keys are generated. A formal definition of this property appears in Section 3.2 of [DGKR18]. As further discussed in Section 7.1.3, only some VRFs specified in this document satisfy this property. 4. RSA Full Domain Hash VRF (RSA-FDH-VRF) The RSA Full Domain Hash VRF (RSA-FDH-VRF) is a VRF that, for suitable key lengths, satisfies the "trusted uniqueness", "trusted collision resistance", and "full pseudorandomness" properties defined in Section 3, as further discussed in Section 7. Its security follows from the standard RSA assumption in the random oracle model. Formal security proofs are in [PWHVNRG17]. The VRF computes the proof pi as a deterministic RSA signature on input alpha using the RSA Full Domain Hash Algorithm [RFC8017] parametrized with the selected hash algorithm. RSA signature verification is used to verify the correctness of the proof. The VRF hash output beta is simply obtained by hashing the proof pi with the selected hash algorithm. Goldberg, et al. Expires 10 February 2023 [Page 8] Internet-Draft VRF August 2022 The key pair for RSA-FDH-VRF MUST be generated in a way that it satisfies the conditions specified in Section 3 of [RFC8017]. In this section, the notation from [RFC8017] is used. Parameters used: (n, e) - RSA public key K - RSA private key (its representation is implementation- dependent) k - length in octets of the RSA modulus n (k must be less than 2^32) Fixed options (specified in Section 4.4): Hash - cryptographic hash function hLen - output length in octets of hash function Hash suite_string - an octet string specifying the RSA-FDH-VRF ciphersuite, which determines the above options Primitives used: I2OSP - Conversion of a nonnegative integer to an octet string as defined in Section 4.1 of [RFC8017] (given an integer and a length in octets, produces a big-endian representation of the integer, zero-padded to the desired length) OS2IP - Conversion of an octet string to a nonnegative integer as defined in Section 4.2 of [RFC8017] (given a big-endian encoding of an integer, produces the integer) RSASP1 - RSA signature primitive as defined in Section 5.2.1 of [RFC8017] (given a private key and an input, raises the input to the private RSA exponent modulo n) RSAVP1 - RSA verification primitive as defined in Section 5.2.2 of [RFC8017] (given a public key and an input, raises the input to the public RSA exponent modulo n) MGF1 - Mask Generation Function based on the hash function Hash as defined in Section B.2.1 of [RFC8017] (given an input, produces a random-oracle-like output of desired length) || - octet string concatenation Goldberg, et al. Expires 10 February 2023 [Page 9] Internet-Draft VRF August 2022 4.1. RSA-FDH-VRF Proving RSAFDHVRF_prove(K, alpha_string[, MGF_salt]) Input: K - RSA private key alpha_string - VRF hash input, an octet string Optional Input: MGF_salt - a public octet string used as a hash function salt; this input is not used when MGF_salt is specified as part of the ciphersuite Output: pi_string - proof, an octet string of length k Steps: 1. mgf_domain_separator = 0x01 2. EM = MGF1(suite_string || mgf_domain_separator || MGF_salt || alpha_string, k - 1) 3. m = OS2IP(EM) 4. s = RSASP1(K, m) 5. pi_string = I2OSP(s, k) 6. Output pi_string 4.2. RSA-FDH-VRF Proof to Hash RSAFDHVRF_proof_to_hash(pi_string) Input: pi_string - proof, an octet string of length k Output: beta_string - VRF hash output, an octet string of length hLen Important note: Goldberg, et al. Expires 10 February 2023 [Page 10] Internet-Draft VRF August 2022 RSAFDHVRF_proof_to_hash should be run only on pi_string that is known to have been produced by RSAFDHVRF_prove, or from within RSAFDHVRF_verify as specified in Section 4.3. Steps: 1. proof_to_hash_domain_separator = 0x02 2. beta_string = Hash(suite_string || proof_to_hash_domain_separator || pi_string) 3. Output beta_string 4.3. RSA-FDH-VRF Verifying RSAFDHVRF_verify((n, e), alpha_string, pi_string[, MGF_salt]) Input: (n, e) - RSA public key alpha_string - VRF hash input, an octet string pi_string - proof to be verified, an octet string of length k Optional Input: MGF_salt - a public octet string used as a hash function salt; this input is not used when MGF_salt is specified as part of the ciphersuite Output: Output: ("VALID", beta_string), where beta_string is the VRF hash output, an octet string of length hLen; or "INVALID" Steps: 1. s = OS2IP(pi_string) 2. m = RSAVP1((n, e), s); if RSAVP1 returns "signature representative out of range", output "INVALID" and stop. 3. mgf_domain_separator = 0x01 Goldberg, et al. Expires 10 February 2023 [Page 11] Internet-Draft VRF August 2022 4. EM' = MGF1(suite_string || mgf_domain_separator || MGF_salt || alpha_string, k - 1) 5. m' = OS2IP(EM') 6. If m and m' are equal, output ("VALID", RSAFDHVRF_proof_to_hash(pi_string)); else output "INVALID". 4.4. RSA-FDH-VRF Ciphersuites This document defines RSA-FDH-VRF-SHA256 as follows: * suite_string = 0x01 * The hash function Hash is SHA-256 as specified in [RFC6234], with hLen = 32 * MGF_salt = I2OSP(k, 4) || I2OSP(n, k) This document defines RSA-FDH-VRF-SHA384 as follows: * suite_string = 0x02 * The hash function Hash is SHA-384 as specified in [RFC6234], with hLen = 48 * MGF_salt = I2OSP(k, 4) || I2OSP(n, k) This document defines RSA-FDH-VRF-SHA512 as follows: * suite_string = 0x03 * The hash function Hash is SHA-512 as specified in [RFC6234], with hLen = 64 * MGF_salt = I2OSP(k, 4) || I2OSP(n, k) 5. Elliptic Curve VRF (ECVRF) The Elliptic Curve Verifiable Random Function (ECVRF) is a VRF that, for suitable parameter choices, satisfies the "full uniqueness", "trusted collision resistance", and "full pseudorandomness properties" defined in Section 3. If validate_key parameter given to the ECVRF_verify is TRUE, then the ECVRF additionally satisfies "full collision resistance" and "unpredictability under malicious key generation". See Section 7 for further discussion. Formal security proofs are in [PWHVNRG17]. Goldberg, et al. Expires 10 February 2023 [Page 12] Internet-Draft VRF August 2022 Notation used: Elliptic curve operations are written in additive notation, with P+Q denoting point addition and x*P denoting scalar multiplication of a point P by a scalar x x^y - x raised to the power y x*y - x multiplied by y s || t - concatenation of octet strings s and t 0xMN (where M and N are hexadecimal digits) - a single octet with value M*16+N; equivalently, int_to_string(M*16+N, 1), where int_to_string is as defined below. Fixed options (specified in Section 5.5): F - finite field fLen - length, in octets, of an element in F encoded as an octet string E - elliptic curve (EC) defined over F ptLen - length, in octets, of a point on E encoded as an octet string G - subgroup of E of large prime order q - prime order of group G qLen - length of q in octets, i.e., smallest integer such that 2^(8qLen)>q cLen - length, in octets, of a challenge value used by the VRF (note that in the typical case, cLen is qLen/2 or close to it) cofactor - number of points on E divided by q B - generator of group G Hash - cryptographic hash function hLen - output length in octets of Hash (hLen must be at least cLen; in the typical case, it is at least qLen) Goldberg, et al. Expires 10 February 2023 [Page 13] Internet-Draft VRF August 2022 ECVRF_encode_to_curve - a function that hashes strings to points on E. ECVRF_nonce_generation - a function that derives a pseudorandom nonce from SK and the input as part of ECVRF proving. suite_string - an octet string specifying the ECVRF ciphersuite, which determines the above options as well as type conversions and parameter generation Type conversions (specified in Section 5.5): int_to_string(a, len) - conversion of nonnegative integer a to octet string of length len string_to_int(a_string) - conversion of an octet string a_string to a nonnegative integer point_to_string - conversion of a point on E to an ptLen-octet string string_to_point - conversion of an ptLen-octet string to a point on E. string_to_point returns INVALID if the octet string does not convert to a valid EC point on the curve E. Note that with certain software libraries (for big integer and elliptic curve arithmetic), the int_to_string and point_to_string conversions are not needed, when the libraries encode integers and EC points in the same way as required by the ciphersuites. For example, in some implementations, EC point operations will take octet strings as inputs and produce octet strings as outputs, without introducing a separate elliptic curve point type. Parameters used (the generation of these parameters is specified in Section 5.5): SK - VRF secret key x - VRF secret scalar, an integer. Note: depending on the ciphersuite used, the VRF secret scalar may be equal to SK; else, it is derived from SK Y = x*B - VRF public key, an point on E PK_string = point_to_string(Y) - VRF public key represented as an octet string encode_to_curve_salt - a public value used as a hash function salt Goldberg, et al. Expires 10 February 2023 [Page 14] Internet-Draft VRF August 2022 5.1. ECVRF Proving ECVRF_prove(SK, alpha_string[, encode_to_curve_salt]) Input: SK - VRF secret key alpha_string - input alpha, an octet string Optional input: encode_to_curve_salt - a public salt value, an octet string; this input is not used when encode_to_curve_salt is specified as part of the ciphersuite Output: pi_string - VRF proof, octet string of length ptLen+cLen+qLen Steps: 1. Use SK to derive the VRF secret scalar x and the VRF public key Y = x*B (this derivation depends on the ciphersuite, as per Section 5.5; these values can be cached, for example, after key generation, and need not be rederived each time) 2. H = ECVRF_encode_to_curve(encode_to_curve_salt, alpha_string) (see Section 5.4.1) 3. h_string = point_to_string(H) 4. Gamma = x*H 5. k = ECVRF_nonce_generation(SK, h_string) (see Section 5.4.2) 6. c = ECVRF_challenge_generation(Y, H, Gamma, k*B, k*H) (see Section 5.4.3) 7. s = (k + c*x) mod q 8. pi_string = point_to_string(Gamma) || int_to_string(c, cLen) || int_to_string(s, qLen) 9. Output pi_string Goldberg, et al. Expires 10 February 2023 [Page 15] Internet-Draft VRF August 2022 5.2. ECVRF Proof to Hash ECVRF_proof_to_hash(pi_string) Input: pi_string - VRF proof, octet string of length ptLen+cLen+qLen Output: "INVALID", or beta_string - VRF hash output, octet string of length hLen Important note: ECVRF_proof_to_hash should be run only on pi_string that is known to have been produced by ECVRF_prove, or from within ECVRF_verify as specified in Section 5.3. Steps: 1. D = ECVRF_decode_proof(pi_string) (see Section 5.4.4) 2. If D is "INVALID", output "INVALID" and stop 3. (Gamma, c, s) = D 4. proof_to_hash_domain_separator_front = 0x03 5. proof_to_hash_domain_separator_back = 0x00 6. beta_string = Hash(suite_string || proof_to_hash_domain_separator_front || point_to_string(cofactor * Gamma) || proof_to_hash_domain_separator_back) 7. Output beta_string 5.3. ECVRF Verifying ECVRF_verify(PK_string, alpha_string, pi_string[, encode_to_curve_salt, validate_key]) Input: PK_string - public key, an octet string alpha_string - VRF input, octet string Goldberg, et al. Expires 10 February 2023 [Page 16] Internet-Draft VRF August 2022 pi_string - VRF proof, octet string of length ptLen+cLen+qLen Optional input: encode_to_curve_salt - a public salt value, an octet string; this input is not used when encode_to_curve_salt is specified as part of the ciphersuite validate_key - a boolean. An implementation MAY support only the option of validate_key = TRUE, or only the option of validate_key = FALSE, in which case this input is not needed. If an implementation supports only one option, it MUST specify which option is supports. Output: ("VALID", beta_string), where beta_string is the VRF hash output, octet string of length hLen; or "INVALID" Steps: 1. Y = string_to_point(PK_string) 2. If Y is "INVALID", output "INVALID" and stop 3. If validate_key, run ECVRF_validate_key(Y) (Section 5.4.5); if it outputs "INVALID", output "INVALID" and stop 4. D = ECVRF_decode_proof(pi_string) (see Section 5.4.4) 5. If D is "INVALID", output "INVALID" and stop 6. (Gamma, c, s) = D 7. H = ECVRF_encode_to_curve(encode_to_curve_salt, alpha_string) (see Section 5.4.1) 8. U = s*B - c*Y 9. V = s*H - c*Gamma 10. c' = ECVRF_challenge_generation(Y, H, Gamma, U, V) (see Section 5.4.3) 11. If c and c' are equal, output ("VALID", ECVRF_proof_to_hash(pi_string)); else output "INVALID" Goldberg, et al. Expires 10 February 2023 [Page 17] Internet-Draft VRF August 2022 Note that the first three steps need to be performed only once for a given public key. 5.4. ECVRF Auxiliary Functions 5.4.1. ECVRF Encode to Curve The ECVRF_encode_to_curve algorithm takes a public salt (see Section 7.9) and the VRF input alpha and converts it to H, an EC point in G. This algorithm is the only place the VRF input alpha is used for proving and verifying. See Section 7.7 for further discussion. This section specifies a number of such algorithms, which are not compatible with each other and are intended to use with various ciphersuites specified in Section 5.5. Input: encode_to_curve_salt - public salt value, an octet string alpha_string - value to be hashed, an octet string Output: H - hashed value, a point in G 5.4.1.1. ECVRF_encode_to_curve_try_and_increment The following ECVRF_encode_to_curve_try_and_increment(encode_to_curve_salt, alpha_string) algorithm implements ECVRF_encode_to_curve in a simple and generic way that works for any elliptic curve. To use this algorithm, hLen MUST be at least fLen. The running time of this algorithm depends on alpha_string. For the ciphersuites specified in Section 5.5, this algorithm is expected to find a valid curve point after approximately two attempts (i.e., when ctr=1) on average. However, because the running time of algorithm depends on alpha_string, this algorithm SHOULD be avoided in applications where it is important that the VRF input alpha remain secret. ECVRF_encode_to_curve_try_and_increment(encode_to_curve_salt, alpha_string) Fixed option (specified in Section 5.5): Goldberg, et al. Expires 10 February 2023 [Page 18] Internet-Draft VRF August 2022 interpret_hash_value_as_a_point - a function that attempts to convert a cryptographic hash value to a point on E; may output INVALID. Steps: 1. ctr = 0 2. encode_to_curve_domain_separator_front = 0x01 3. encode_to_curve_domain_separator_back = 0x00 4. H = "INVALID" 5. While H is "INVALID" or H is the identity element of the elliptic curve group: a. ctr_string = int_to_string(ctr, 1) b. hash_string = Hash(suite_string || encode_to_curve_domain_separator_front || encode_to_curve_salt || alpha_string || ctr_string || encode_to_curve_domain_separator_back) c. H = interpret_hash_value_as_a_point(hash_string) d. If H is not "INVALID" and cofactor > 1, set H = cofactor * H e. ctr = ctr + 1 6. Output H Note even though the loop is infinite as written, and int_to_string(ctr,1) may fail when ctr reaches 256, interpret_hash_value_as_a_point functions specified in Section 5.5 will succeed on roughly half hash_string values. Thus the loop is expected to stop after two iterations, and ctr is overwhelmingly unlikely (probability about 2^-256) to reach 256. 5.4.1.2. ECVRF_encode_to_curve_h2c_suite The ECVRF_encode_to_curve_h2c_suite(encode_to_curve_salt, alpha_string) algorithm implements ECVRF_encode_to_curve using one of the several hash-to-curve options defined in [I-D.irtf-cfrg-hash-to-curve]. The specific choice of the hash-to- curve option (called Suite ID in [I-D.irtf-cfrg-hash-to-curve]) is given by the h2c_suite_ID_string parameter. Goldberg, et al. Expires 10 February 2023 [Page 19] Internet-Draft VRF August 2022 ECVRF_encode_to_curve_h2c_suite(encode_to_curve_salt, alpha_string) Fixed option (specified in Section 5.5): h2c_suite_ID_string - a hash-to-curve suite ID, encoded in ASCII (see discussion below) Steps: 1. string_to_be_hashed = encode_to_curve_salt || alpha_string 2. H = encode(string_to_be_hashed) (the encode function is discussed below) 3. Output H The encode function is provided by the hash-to-curve suite whose ID is h2c_suite_ID_string, as specified in [I-D.irtf-cfrg-hash-to-curve], Section 8. The domain separation tag DST, a parameter to the hash-to-curve suite, SHALL be set to "ECVRF_" || h2c_suite_ID_string || suite_string where "ECVRF_" is represented as a 6-byte ASCII encoding (in hexadecimal, octets 45 43 56 52 46 5F). 5.4.2. ECVRF Nonce Generation The following algorithms generate the nonce value k in a deterministic pseudorandom fashion. This section specifies a number of such algorithms, which are not compatible with each other. The choice of a particular algorithm from the options specified in this section depends on the ciphersuite, as specified in Section 5.5. 5.4.2.1. ECVRF Nonce Generation from RFC 6979 ECVRF_nonce_generation_RFC6979(SK, h_string) Input: SK - an ECVRF secret key h_string - an octet string Output: k - an integer nonce between 1 and q-1 Goldberg, et al. Expires 10 February 2023 [Page 20] Internet-Draft VRF August 2022 The ECVRF_nonce_generation function is as specified in [RFC6979] Section 3.2 where Input m is set equal to h_string The "suitable for DSA or ECDSA" check in step h.3 is omitted The hash function H is Hash and its output length hlen (in bits) is set as hLen*8 The secret key x is set equal to the VRF secret scalar x The prime q is the same as in this specification qlen is the binary length of q, i.e., the smallest integer such that 2^qlen > q (this qlen is not to be confused with qLen in this document, which is the length of q in octets) All the other values and primitives as defined in [RFC6979] 5.4.2.2. ECVRF Nonce Generation from RFC 8032 The following is from Steps 2-3 of Section 5.1.6 in [RFC8032]. To use this algorithm, hLen MUST be at least 64. ECVRF_nonce_generation_RFC8032(SK, h_string) Input: SK - an ECVRF secret key h_string - an octet string Output: k - an integer nonce between 0 and q-1 Steps: 1. hashed_sk_string = Hash(SK) 2. truncated_hashed_sk_string = hashed_sk_string[32]...hashed_sk_string[63] 3. k_string = Hash(truncated_hashed_sk_string || h_string) 4. k = string_to_int(k_string) mod q Goldberg, et al. Expires 10 February 2023 [Page 21] Internet-Draft VRF August 2022 5.4.3. ECVRF Challenge Generation ECVRF_challenge_generation(P1, P2, P3, P4, P5) Input: P1, P2, P3, P4, P5 - EC points Output: c - challenge value, integer between 0 and 2^(8*cLen)-1 Steps: 1. challenge_generation_domain_separator_front = 0x02 2. Initialize str = suite_string || challenge_generation_domain_separator_front 3. for PJ in [P1, P2, P3, P4, P5]: str = str || point_to_string(PJ) 4. challenge_generation_domain_separator_back = 0x00 5. str = str || challenge_generation_domain_separator_back 6. c_string = Hash(str) 7. truncated_c_string = c_string[0]...c_string[cLen-1] 8. c = string_to_int(truncated_c_string) 9. Output c 5.4.4. ECVRF Decode Proof ECVRF_decode_proof(pi_string) Input: pi_string - VRF proof, octet string (ptLen+cLen+qLen octets) Output: "INVALID", or Gamma - a point on E Goldberg, et al. Expires 10 February 2023 [Page 22] Internet-Draft VRF August 2022 c - integer between 0 and 2^(8*cLen)-1 s - integer between 0 and q-1 Steps: 1. gamma_string = pi_string[0]...pi_string[ptLen-1] 2. c_string = pi_string[ptLen]...pi_string[ptLen+cLen-1] 3. s_string = pi_string[ptLen+cLen]...pi_string[ptLen+cLen+qLen-1] 4. Gamma = string_to_point(gamma_string) 5. if Gamma = "INVALID" output "INVALID" and stop 6. c = string_to_int(c_string) 7. s = string_to_int(s_string) 8. if s >= q output "INVALID" and stop 9. Output Gamma, c, and s 5.4.5. ECVRF Validate Key ECVRF_validate_key(Y) Input: Y - public key, a point on E Output: "VALID" or "INVALID" Important note: the public key Y given to this procedure MUST be a valid point on E. Steps: 1. Let Y' = cofactor*Y 2. If Y' is the identity element of the elliptic curve group, output "INVALID" and stop 3. Output "VALID" Goldberg, et al. Expires 10 February 2023 [Page 23] Internet-Draft VRF August 2022 Note that if the cofactor = 1, then Step 1 simply sets Y'=Y. In particular, for the P-256 curve, ECVRF_validate_key simply ensures that Y is not the point at infinity. Any algorithm with identical input-output behavior MAY be used in place of the above steps. For example, if the total number of Y values that could cause Step 2 to output "INVALID" is small, it may be more efficient to simply check Y against a fixed list of such values. For example, the following algorithm MAY be used for the edwards25519 curve: 1. PK_string = point_to_string(Y) 2. oneTwentySeven_string = 0x7F 3. y_string[31] = y_string[31] & oneTwentySeven_string (this step clears the high-order bit of octet 31) 4. bad_pk[0] = int_to_string(0, 32) 5. bad_pk[1] = int_to_string(1, 32) 6. bad_y2 = 2707385501144840649318225287225658788936804267575313519 463743609750303402022 7. bad_pk[2] = int_to_string(bad_y2, 32) 8. bad_pk[3] = int_to_string(p-bad_y2, 32) 9. bad_pk[4] = int_to_string(p-1, 32) 10. bad_pk[5] = int_to_string(p, 32) 11. bad_pk[6] = int_to_string(p+1, 32) 12. If y_string is in the list [bad_pk[0],...,bad_pk[6]], output "INVALID" and stop 13. Output "VALID" (This algorithm works for the following reason. Note that there are 8 bad points -- namely, the points whose order is 1, 2, 4, or 8 -- on the edwards25519 curve. Their y coordinates happen to be 0 (two points of order 4), 1 (one point of order 1), bad_y2 (two points of order 8), p-bad_y2 (two points of order 8), and p-1 (one point of order 2). They can obtained by converting the points specified in [X25519] to Edwards coordinates. Thus, bad_pk[0] (of order 4), Goldberg, et al. Expires 10 February 2023 [Page 24] Internet-Draft VRF August 2022 bad_pk[2] (of order 8), and bad_pk[3] (of order 8) each match two bad points, depending on the sign of the x-coordinate, which was cleared in step 3, in order to make sure that it does not affect the comparison. bad_pk[1] (of order 1) and bad_pk[4] (of order 2) each match one bad point, because x-coordinate is 0 for these two points. Note that the first 5 list elements cover the 8 bad points. However, in case the y-coordinate of the public key Y had not been modular reduced by p, the list also includes bad_pk[5] and bad_pk[6], which are simply bad_pk[0] and bad_pk[1] shifted by p. There is no need to shift the other bad_pk values by p (or any bad_pk values by a larger multiple of p), because their y coordinate would exceed 2^255; and we ensure that y_string corresponds to an integer less than 2^255 in step 3.) 5.5. ECVRF Ciphersuites This document defines ECVRF-P256-SHA256-TAI as follows: * suite_string = 0x01. * The EC group G is the NIST P-256 elliptic curve, with curve parameters as specified in [FIPS-186-4] (Section D.1.2.3) and [RFC5114] (Section 2.6). For this group, fLen = qLen = 32 and cofactor = 1. * cLen = 16. * The key pair generation primitive is specified in Section 3.2.1 of [SECG1] (q, B, SK, and Y in this document correspond to n, G, d, and Q in Section 3.2.1 of [SECG1]). In this ciphersuite, the secret scalar x is equal to the secret key SK. * encode_to_curve_salt = PK_string * The ECVRF_nonce_generation function is as specified in Section 5.4.2.1. * The int_to_string function is the I2OSP function specified in Section 4.1 of [RFC8017]. (This is big-endian representation.) * The string_to_int function is the OS2IP function specified in Section 4.2 of [RFC8017]. (This is big-endian representation.) * The point_to_string function converts a point on E to an octet string according to the encoding specified in Section 2.3.3 of [SECG1] with point compression on. This implies ptLen = fLen + 1 = 33. (Note that certain software implementations do not introduce a separate elliptic curve point type and instead Goldberg, et al. Expires 10 February 2023 [Page 25] Internet-Draft VRF August 2022 directly treat the EC point as an octet string per above encoding. When using such an implementation, the point_to_string function can be treated as the identity function.) * The string_to_point function converts an octet string to an a point on E according to the encoding specified in Section 2.3.4 of [SECG1]. This function MUST output INVALID if the octet string does not decode to a point on the curve E. * The hash function Hash is SHA-256 as specified in [RFC6234], with hLen = 32. * The ECVRF_encode_to_curve function is as specified in Section 5.4.1.1, with interpret_hash_value_as_a_point(s) = string_to_point(0x02 || s). This document defines ECVRF-P256-SHA256-SSWU as identical to ECVRF- P256-SHA256-TAI, except that: * suite_string = 0x02. * the ECVRF_encode_to_curve function is as specified in Section 5.4.1.2 with h2c_suite_ID_string = P256_XMD:SHA- 256_SSWU_NU_ (the suite is defined in [I-D.irtf-cfrg-hash-to-curve] Section 8.2) This document defines ECVRF-EDWARDS25519-SHA512-TAI as follows: * suite_string = 0x03. * The EC group G is the edwards25519 elliptic curve with parameters defined in Table 1 of [RFC8032]. For this group, fLen = qLen = 32 and cofactor = 8. * cLen = 16. * The secret key and generation of the secret scalar and the public key are specified in Section 5.1.5 of [RFC8032]. * encode_to_curve_salt = PK_string * The ECVRF_nonce_generation function is as specified in Section 5.4.2.2. * The int_to_string function as specified in the first paragraph of Section 5.1.2 of [RFC8032]. (This is little-endian representation.) Goldberg, et al. Expires 10 February 2023 [Page 26] Internet-Draft VRF August 2022 * The string_to_int function interprets the string as an integer in little-endian representation. * The point_to_string function converts an point on E to an octet string according to the encoding specified in Section 5.1.2 of [RFC8032]. This implies ptLen = fLen = 32. (Note that certain software implementations do not introduce a separate elliptic curve point type and instead directly treat the EC point as an octet string per above encoding. When using such and implementation, the point_to_string function can be treated as the identity function.) * The string_to_point function converts an octet string to a point on E according to the encoding specified in Section 5.1.3 of [RFC8032]. This function MUST output INVALID if the octet string does not decode to a point on the curve E. * The hash function Hash is SHA-512 as specified in [RFC6234], with hLen = 64. * The ECVRF_encode_to_curve function is as specified in Section 5.4.1.1, with interpret_hash_value_as_a_point(s) = string_to_point(s[0]...s[31]). This document defines ECVRF-EDWARDS25519-SHA512-ELL2 as identical to ECVRF-EDWARDS25519-SHA512-TAI, except: * suite_string = 0x04. * the ECVRF_encode_to_curve function is as specified in Section 5.4.1.2 with h2c_suite_ID_string = edwards25519_XMD:SHA- 512_ELL2_NU_ (the suite is defined in [I-D.irtf-cfrg-hash-to-curve] Section 8.5). 6. Implementation Status Note to RFC editor: Remove before publication A reference C++ implementation of ECVRF-P256-SHA256-TAI, ECVRF- P256-SHA256-SSWU, ECVRF-EDWARDS25519-SHA512-TAI, and ECVRF- EDWARDS25519-SHA512-ELL2 is available at https://github.com/reyzin/ ecvrf. This implementation is neither secure nor especially efficient, but can be used to generate test vectors. A Python implementation of an older version of ECVRF- EDWARDS25519-SHA512-ELL2 from the -05 version of this draft is available at https://github.com/integritychain/draft-irtf-cfrg-vrf- 05. Goldberg, et al. Expires 10 February 2023 [Page 27] Internet-Draft VRF August 2022 A C implementation of an older version of ECVRF- EDWARDS25519-SHA512-ELL2 from the -03 version of this draft is available at https://github.com/algorand/libsodium/tree/draft-irtf- cfrg-vrf-03/src/libsodium/crypto_vrf/ietfdraft03. A Rust implementation of an older version of ECVRF-P256-SHA256-TAI from the -05 version of this draft, as well as variants for the sect163k1 and secp256k1 curves, is available at https://crates.io/crates/vrf. A C implementation of a variant of ECVRF-P256-SHA256-TAI from the -05 version of this draft adapted for the secp256k1 curve is available at https://github.com/aergoio/secp256k1-vrf. An implementation of an earlier version of RSA-FDH-VRF (SHA-256) and ECVRF-P256-SHA256-TAI was first developed as a part of the NSEC5 project [I-D.vcelak-nsec5] and is available at http://github.com/fcelda/nsec5-crypto. The Key Transparency project at Google uses a VRF implementation that is similar to the ECVRF-P256-SHA256-TAI, with a few changes including the use of SHA-512 instead of SHA-256. Its implementation is available at https://github.com/google/keytransparency/blob/master/core/crypto/ vrf/ An implementation by Ryuji Ishiguro following an older version of ECVRF-EDWARDS25519-SHA512-TAI from the -00 version of this draft is available at https://github.com/r2ishiguro/vrf. An implementation similar to ECVRF-EDWARDS25519-SHA512-ELL2 (with some changes, including the use of SHA-3) is available as part of the CONIKS implementation in Golang at https://github.com/coniks-sys/ coniks-go/tree/master/crypto/vrf. Open Whisper Systems also uses a VRF similar to ECVRF- EDWARDS25519-SHA512-ELL2, called VXEdDSA, and specified here https://whispersystems.org/docs/specifications/xeddsa/ and here https://moderncrypto.org/mail-archive/curves/2017/000925.html. Implementations in C and Java are available at https://github.com/signalapp/curve25519-java and https://github.com/wavesplatform/curve25519-java. 7. Security Considerations Goldberg, et al. Expires 10 February 2023 [Page 28] Internet-Draft VRF August 2022 7.1. Key Generation Implementations of VRFs defined in this document MUST ensure that they generate VRF keys correctly and using good randomness. However, in some applications keys may be generated by an adversary who does not necessarily implement this document. We now discuss the implications of this possibility. 7.1.1. Uniqueness and collision resistance under malicious key generation See Section 3 for definitions of uniqueness and collision resistance properties. The RSA-FDH-VRF satisfies only the "trusted" variants of uniqueness and collision resistance. Thus, for RSA-FDH-VRF, uniqueness and collision resistance may not hold if the keys are generated adversarially (specifically, if the RSA function specified in the public key is not bijective because the modulus n or the exponent e are chosen not in compliance with [RFC8017]); thus, RSA-FDH-VRF defined in this document does not have "full uniqueness" and "full collision resistance". Therefore, if malicious key generation is a concern, the RSA-FDH-VRF has to be enhanced by additional cryptographic checks (such as zero-knowledge proofs) that its public key has the right form. These enhancements are left for future specification. For the ECVRF, the Verifier MUST obtain E and B from a trusted source, such as a ciphersuite specification, rather than from the prover. If the verifier does so, then the ECVRF satisfies the "full uniqueness", ensuring uniqueness even under malicious key generation. The ECVRF also satisfies "trusted collision resistance". It additionally satisfies "full collision resistance" if validate_key parameter given to the ECVRF_verify is TRUE. This setting of ECVRF_verify ensures collision resistance under malicious key generation. 7.1.2. Pseudorandomness under malicious key generation Without good randomness, the "pseudorandomness" properties of the VRF (defined in Section 3.4) may not hold. Note that it is not possible to guarantee pseudorandomness in the face of adversarially generated VRF keys. This is because an adversary can always use bad randomness to generate the VRF keys, and thus, the VRF output may not be pseudorandom. Goldberg, et al. Expires 10 February 2023 [Page 29] Internet-Draft VRF August 2022 7.1.3. Unpredictability under malicious key generation Unpredictability under malicious key generation (defined in Section 3.5) does not hold for the RSA-FDH-VRF. (Specifically, the VRF output may be predictable if the RSA function specified in the public key is far from bijective because the modulus n or the exponent e are chosen not in compliance with [RFC8017].) If unpredictability under malicious key generation is desired, the RSA- FDH-VRF has to be enhanced by additional cryptographic checks (such as zero-knowledge proofs) that its public key has the right form. These enhancements are left for future specification. Unpredictability under malicious key generation holds for the ECVRF if validate_key parameter given to the ECVRF_verify is TRUE. 7.2. Security Levels As shown in [PWHVNRG17], RSA-FDH-VRF satisfies the trusted uniqueness property unconditionally. The security level of the RSA-FDH-VRF, measured in bits, for the other two properties is as follows (in the random oracle model for the functions MGF1 and Hash): * For trusted collision resistance: approximately 8*min(k/2, hLen/2) (as shown in [PWHVNRG17]). * For selective pseudorandomness: approximately as strong as the security, in bits, of the RSA problem for the key (n, e) (as shown in [GNPRVZ15]). As shown in [PWHVNRG17], the security level of the ECVRF, measured in bits, is as follows (in the random oracle model for the functions Hash and ECVRF_encode_to_curve): * For uniqueness (both trusted and full): approximately 8*min(qLen, cLen). * For collision resistance (trusted or full, depending on whether validation is performed as explained in Section 7.1.1): approximately 8*min(qLen/2, hLen/2). * For the selective pseudorandomness property: approximately as strong as the security, in bits, of the decisional Diffie-Hellman problem in the group G (which is at most 8*qLen/2). See Section 3 for the definitions of these security properties. See Section 7.3 for the discussion of full pseudorandomness. Goldberg, et al. Expires 10 February 2023 [Page 30] Internet-Draft VRF August 2022 7.3. Selective vs. Full Pseudorandomness [PWHVNRG17] presents cryptographic reductions to an underlying hard problem (namely, the RSA problem for RSA-FDH-VRF and the Decisional Diffie-Hellman problem for the ECVRF) to prove that the VRFs specified in this document possess not only selective pseudorandomness, but also full pseudorandomness (see Section 3.4 for an explanation of these notions). However, the cryptographic reductions are tighter for selective pseudorandomness than for full pseudorandomness. Specifically, the approximate provable security level, measured in bits, for full pseudorandomness may be obtained from the provable security level for selective pseudorandomness (given in Section 7.2) by subtracting the binary logarithm of the number of proofs produced for a given secret key. This holds for both the RSA-FDH-VRF and the ECVRF. While no known attacks against full pseudorandomness are stronger than similar attacks against selective pseudorandomness, some applications may be concerned about tightness of cryptographic reductions to ensure specific levels of provable security. Such applications may consider the following three options: * They may limit the number of proofs produced for a given secret key, to reduce the loss in the provable security level. * They may work to ensure that selective pseudorandomness is sufficient for the application. That is, they may design the application in such a way that pseudorandomness of outputs matters only for inputs that are chosen independently of the VRF key. * They may increase security parameters to make up for the loose security reduction. For RSA-FDH-VRF, this means increasing the RSA key length. For ECVRF, this means increasing the cryptographic strength of the EC group G by specifying a new ciphersuite. 7.4. Proper pseudorandom nonce for ECVRF The security of the ECVRF defined in this document relies on the fact that the nonce k used in the ECVRF_prove algorithm is chosen uniformly and pseudorandomly modulo q, and is unknown to the adversary. Otherwise, an adversary may be able to recover the VRF secret scalar x (and thus break pseudorandomness of the VRF) after observing several valid VRF proofs pi, using, for example, techniques described in [BreHen19]. The nonce generation methods specified in the ECVRF ciphersuites of Section 5.5 are designed with this requirement in mind. Goldberg, et al. Expires 10 February 2023 [Page 31] Internet-Draft VRF August 2022 7.5. Side-channel attacks Side channel attacks on cryptographic primitives are an important issue. Implementers should take care to avoid side-channel attacks that leak information about the VRF secret key SK (and the nonce k used in the ECVRF), which is used in VRF_prove. In most applications, VRF_proof_to_hash and VRF_verify algorithms take only inputs that are public, and thus side channel attacks are typically not a concern for these algorithms. The VRF input alpha may be also a sensitive input to VRF_prove and may need to be protected against side channel attacks. Below we discuss one particular class of such attacks: timing attacks that can be used to leak information about the VRF input alpha. The ECVRF_encode_to_curve_try_and_increment algorithm defined in Section 5.4.1.1 SHOULD NOT be used in applications where the VRF input alpha is secret and is hashed by the VRF on-the-fly. This is because the algorithm's running time depends on the VRF input alpha, and thus creates a timing channel that can be used to learn information about alpha. That said, for most inputs the amount of information obtained from such a timing attack is likely to be small (1 bit, on average), since the algorithm is expected to find a valid curve point after only two attempts. However, there might be inputs which cause the algorithm to make many attempts before it finds a valid curve point; for such inputs, the information leaked in a timing attack will be more than 1 bit. ECVRF-P256-SHA256-SSWU and ECVRF-EDWARDS25519-SHA512-ELL2 can be made to run in time independent of alpha, following recommendations in [I-D.irtf-cfrg-hash-to-curve]. 7.6. Proofs provide no secrecy for the VRF input The VRF proof pi is not designed to provide secrecy and, in general, may reveal the VRF input alpha. Anyone who knows PK and pi is able to perform an offline dictionary attack to search for alpha, by verifying guesses for alpha using VRF_verify. This is in contrast to the VRF hash output beta which, without the proof, is pseudorandom and thus is designed to reveal no information about alpha. Goldberg, et al. Expires 10 February 2023 [Page 32] Internet-Draft VRF August 2022 7.7. Prehashing The VRFs specified in this document allow for read-once access to the input alpha for both signing and verifying. Thus, additional prehashing of alpha (as specified, for example, in [RFC8032] for EdDSA signatures) is not needed, even for applications that need to handle long alpha or to support the Initialize-Update-Finalize (IUF) interface (in such an interface, alpha is not supplied all at once, but rather in pieces by a sequence of calls to Update). The ECVRF, in particular, uses alpha only in ECVRF_encode_to_curve. The curve point H becomes the representative of alpha thereafter. 7.8. Hash function domain separation Hashing is used for different purposes in the two VRFs. Specifically, in the RSA-FDH-VRF, hashing is used in MGF1 and in proof_to_hash; in the ECVRF, hashing is used in encode_to_curve, nonce_generation, challenge_generation, and proof_to_hash. The theoretical analysis treats each of these functions as a separate hash function, modeled as a random oracle. This analysis still holds even if the same hash function is used, as long as the four inputs given to the hash function for a given SK and alpha are overwhelmingly unlikely to equal each other or to any inputs given to the hash function for the same SK and different alpha. This is indeed the case for the RSA-FDH-VRF defined in this document, because the second octets of the input to the hash function used in MGF1 and in proof_to_hash are different. This is also the case for the ECVRF ciphersuites defined in this document, because: * inputs to the hash function used during nonce_generation are unlikely to equal inputs used in encode_to_curve, proof_to_hash, and challenge_generation. This follows since nonce_generation inputs a secret to the hash function that is not used by honest parties as input to any other hash function, and is not available to the adversary. * the second octets of the inputs to the hash function used in proof_to_hash, challenge_generation, and encode_to_curve_try_and_increment are all different. Goldberg, et al. Expires 10 February 2023 [Page 33] Internet-Draft VRF August 2022 * the last octet of the input to the hash function used in proof_to_hash, challenge_generation, and encode_to_curve_try_and_increment is always zero, and therefore different from the last octet of the input to the hash function used in ECVRF_encode_to_curve_h2c_suite, which is set equal to the nonzero length of the domain separation tag by [I-D.irtf-cfrg-hash-to-curve]. 7.9. Hash function salting In case a hash collision is found, in order to make it more difficult for the adversary to exploit such a collision, the MGF1 function for the RSA-FDH-VRF and ECVRF_encode_to_curve function for the ECVRF use a public value in addition to alpha (as a so-called salt). This value is determined by the ciphersuite. For the ciphersuites defined in this document, it is set equal to the string representation of the RSA modulus and EC public key, respectively. Implementations that do not use one of the ciphersuites (see Section 7.10) MAY use a different salt. For example, if a group of public keys to share the same salt, then the hash of the VRF input alpha will be the same for the entire group of public keys, which may aid in some protocol that uses the VRF. 7.10. Futureproofing If future designs need to specify variants (e.g., additional ciphersuites) of the RSA-FDH-VRF or the ECVRF in this document, then, to avoid the possibility that an adversary can obtain a VRF output under one variant, and then claim it was obtained under another variant, they should specify a different suite_string constant. The suite_string constants in this document are all single octets; if a future suite_string constant is longer than one octet, then it should start with a different octet than the suite_string constants in this document. Then, for the RSA-FDH-VRF, the inputs to the hash function used in MGF1 and proof_to_hash will be different from other ciphersuites. For the ECVRF, the inputs ECVRF_encode_to_curve hash function used in producing H are then guaranteed to be different from other ciphersuites; since all the other hashing done by the prover depends on H, inputs to all the hash functions used by the prover will also be different from other ciphersuites as long as ECVRF_encode_to_curve is collision resistant. 8. Change Log Note to RFC Editor: if this document does not obsolete an existing RFC, please remove this appendix before publication as an RFC. 00 - Forked this document from draft-goldbe-vrf-01. Goldberg, et al. Expires 10 February 2023 [Page 34] Internet-Draft VRF August 2022 01 - Minor updates, mostly highlighting TODO items. 02 - Added specification of elligator2 for Curve25519, along with ciphersuites for ECVRF-ED25519-SHA512-Elligator. Changed ECVRF- ED25519-SHA256 suite_string to ECVRF-ED25519-SHA512. (This change made because Ed25519 in [RFC8032] signatures use SHA512 and not SHA256.) Made ECVRF nonce generation a separate component, so that nonces are deterministic. In ECVRF proving, changed + to - (and made corresponding verification changes) in order to be consistent with EdDSA and ECDSA. Highlighted that ECVRF_hash_to_curve acts like a prehash. Added "suites" variable to ECVRF for futureproofing. Ensured domain separation for hash functions by modifying hash_points and added discussion about domain separation. Updated todos in the "additional pseudorandomness property" section. Added a discussion of secrecy into security considerations. Removed B and PK=Y from ECVRF_hash_points because they are already present via H, which is computed via hash_to_curve using the suite_string (which identifies B) and Y. 03 - Changed Ed25519 conversions to little-endian, to match RFC 8032; added simple key validation for Ed25519; added Simple SWU cipher suite; clarified Elligator and removed the extra x0 bit, to make Montgomery and Edwards Elligator the same; added domain separation for RSA VRF; improved notation throughout; added nonce generation as a section; changed counter in try-and-increment from four bytes to one, to avoid endian issues; renamed try-and- increment ciphersuites to -TAI; added qLen as a separate parameter; changed output length to hLen for ECVRF, to match RSAVRF; made Verify return beta so unverified proofs don't end up in proof_to_hash; added test vectors. 04 - Clarified handling of optional arguments x and PK in ECVRF_prove. Edited implementation status to bring it up to date. 05 - Renamed ed25519 into the more commonly used edwards25519. Corrected ECVRF_nonce_generation_RFC6979 (thanks to Gorka Irazoqui Apecechea and Mario Cao Cueto for finding the problem) and corresponding test vectors for the P256 suites. Added a reference to the Rust implementation. 06 - Made some variable names more descriptive. Added a few implementation references. 07 - Incorporated hash-to-curve draft by reference to replace our own Elligator2 and Simple SWU. Clarified discussion of EC parameters and functions. Added a 0 octet to all hashing to enforce domain separation from hashing done inside hash-to-curve. Goldberg, et al. Expires 10 February 2023 [Page 35] Internet-Draft VRF August 2022 08 - Incorporated suggestions from crypto panel review by Chloe Martindale. Changed Reyzin's affiliation. Updated references. 09 - Added a note to remove the implementation page before publication. 10 - Added a check in ECVRF_decode_proof to ensure that s is reduced mod q. Connected security properties (Section 3) and security considerations (Section 7) with more cross-references. 11 - Processed last call comments. Clarified various notation, including lengths of various parameters for ECVRF; added error handling to RSA-FDH-VRF; added security levels section; clarified full vs trusted uniqueness and full vs selective pseudorandomness; added RSA ciphersuites; made key validation clearer; renamed hash_to_curve to encode_to_curve to be consistent with the hash_to_curve draft; allowed a more general salt in hashing, added the public key as input to ECVRF_challenge_generation, and added an explanation about the salt. 12 - Added k_string to edwards25519 test vectors 13 - Clarified key validation for edwards25519 and addressed IRTF Chair comments 14 - Addressed IRSG review comments, which resulted in a substantial reworking of section 3. 15 - Added RSA-FDH-VRF test vectors. 9. Contributors This document would not be possible without the work of Moni Naor, Sachin Vasant, and Asaf Ziv. Chloe Martindale provided a thorough cryptographer's review. Liliya Akhmetzyanova, Tony Arcieri, Gary Belvin, Mario Cao Cueto, Brian Chen, Sergey Gorbunov, Shumon Huque, Gorka Irazoqui Apecechea, Marek Jankowski, Burt Kaliski, Mallory Knodel, David C. Lawerence, Derek Ting-Haye Leung, Antonio Marcedone, Piotr Nojszewski, Chris Peikert, Colin Perkins, Trevor Perrin, Sam Scott, Stanislav Smyshlyaev, Adam Suhl, Nick Sullivan, Christopher Wood, Jiayu Xu, and Annie Yousar provided valuable input to this draft. Christopher Wood, Malte Thomsen, Marcus Rasmussen, and Tobias Vestergaard provided independent verification of the test vectors. Riad Wahby helped this document align with draft-irtf-cfrg- hash-to-curve. 10. References Goldberg, et al. Expires 10 February 2023 [Page 36] Internet-Draft VRF August 2022 10.1. Normative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, DOI 10.17487/RFC5114, January 2008, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, . [I-D.irtf-cfrg-hash-to-curve] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S., and C. A. Wood, "Hashing to Elliptic Curves", Work in Progress, Internet-Draft, draft-irtf-cfrg-hash-to-curve- 16, 15 June 2022, . [FIPS-186-4] National Institute for Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, July 2013, . [SECG1] Standards for Efficient Cryptography Group (SECG), "SEC 1: Elliptic Curve Cryptography", Version 2.0, May 2009, . Goldberg, et al. Expires 10 February 2023 [Page 37] Internet-Draft VRF August 2022 10.2. Informative References [ANSI.X9-62-2005] "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, 2005. [BreHen19] Breitner, J. and N. Heninger, "Biased Nonce Sense: Lattice Attacks against Weak ECDSA Signatures in Cryptocurrencies", in Financial Cryptography, 2019, . [DGKR18] David, B., Gazi, P., Kiayias, A., and A. Russell, "Ouroboros Praos: An adaptively-secure, semi-synchronous proof-of-stake protocol", in Advances in Cryptology - EUROCRYPT, 2018, . [GHMVZ17] Gilad, Y., Hemo, R., Micali, Y., Vlachos, Y., and Y. Zeldovich, "Algorand: Scaling Byzantine Agreements for Cryptocurrencies", in Proceedings of the 26th Symposium on Operating Systems Principles (SOSP), 2017, . [GNPRVZ15] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L., Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC Zone Enumeration", in NDSS, 2015, . [I-D.vcelak-nsec5] Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and D. C. Lawrence, "NSEC5, DNSSEC Authenticated Denial of Existence", Work in Progress, Internet-Draft, draft- vcelak-nsec5-08, 29 December 2018, . [MRV99] Micali, S., Rabin, M., and S. Vadhan, "Verifiable Random Functions", in FOCS, 1999, . [PWHVNRG17] Papadopoulos, D., Wessels, D., Huque, S., Vcelak, J., Naor, M., Reyzin, L., and S. Goldberg, "Making NSEC5 Practical for DNSSEC", in ePrint Cryptology Archive 2017/099, February 2017, . Goldberg, et al. Expires 10 February 2023 [Page 38] Internet-Draft VRF August 2022 [X25519] Bernstein, D.J., "How do I validate Curve25519 public keys?", 2006, . Appendix A. Test Vectors for the RSA-FDH-VRF ciphersuites The test vectors in this section were generated using code at https://github.com/reyzin/rsa-fdh-vrf. There are three keys used in the nine examples below. First, we provide the keys. They are shown in hexadecimal big-endian notation. 2048-bit key: p = efb52a568fa3038fffb853e2183791c6bc81ceee86d20e8f9b6401dc79a8f1 f6248d3a25fdb3f99245fce41667da038f59745b87cc1aed8b4a9c1d74e7d5c16c f7343f2b12f1b5055337369bf018fa07adc0d16f2164a516e80d2b4734f0c6563d 6ee6d4a9e1a54e300cfe9ee679afc3d14a152dfb49b6cfb208bbf921f764af q = ecbca5ee88bbc635d8263aaba84f6502fdb2b4998a40f7c149133d840b6b1b d9a972fe2a981c770272b78fda213f76a062dd865dd116d4c8980975ee9347fe0f 500567e51d78dbee4a34e626051cf018d7feb72f19189525d4f70b6467d0cef514 633ab08a9e7a9ec632064b7b5e3e82128fe563757a614092fc5cf624d10e1b n = ddaba77202bafb796b85bcec98958aa58ae2d117cbc66a6e75c4c2af983985 a3064eaef93e2b03393256d94d75d6a6656b2956524ed8711898a0c3abae84371d a0283bc5f433fc384d810a3c118ed302c0b03da16bee70b80ba3480e7acc1eb358 b3f20fbe90cc4c8a7e2ba9e28b2a3800a5efbaa3c264f79b231f7cdc9577818df1 bac60ef7a3f78a44f046fd29b0689556da7a7f61eefe67427f3f691aee0a4b1efe 2ee2e0e6091143ebb7d69254c9d8ab01ff5e0ad7329f566082f9251e64f436c547 e68de75351ea3a09746ceb7efed2d234121088aaed01696583c172ec88bc173a0d 4d8ec43f4dcc18ff8379317e83ef9685536283368c9c6deb783075 e = 010001 d = d5c5ceab929a841e2a654536de4788f7f0a2a086d44bbb245f8aab3df00db9 24e8d644c3b502820f4cce98adacf09e73bc0e9762b50ae2b697aaa24914fa08b5 1758f59c07cf827341bb2a0597e126f9c69db031d60692c9cadf62842444696f08 223154a1b0be752a325725748644e6d12935b1c66f983379773bcc8c65d06262e9 3b5bb774dd2784265c23e9a7fc5e8871eb6bcc9968a6bc360a98874b623ec59f41 af0a9ecec6af095cb7e5aca11472363950dcbbfcf678fe003358b4ff0060a391da a45a1bd81c166b6221fb07e4f5da75e27d8d5fdbbf87ecbd7f5a4d804597070faa ed22f197511b218788816689375245ddf7fa12337f3e7e898fb9d9 3072-bit key: p = ee5adea28491084e6635bd73fd95649915a11da410d3f361c8eccc90a4b834 25146da7b9e9d3994fd37d5fad7fb759ae451eb99b1102d4671ead23a2925133d1 9df49cf9d7e9dcb69fd7555ca095338d0d2a84abb6825050eaf5fffaeff17ccb08 33c6079081dfcbd98ced36a593557d29d64b0e0253ce2ee4e07fe2a06269dfe5ca 230fad221a593a69d9534b2521c1b41d116cafdee02106228ff41433605453e237 777626953e79b46a84f50069e25b4f50496a928708abce30559eb183cf Goldberg, et al. Expires 10 February 2023 [Page 39] Internet-Draft VRF August 2022 q = fb585bbc12f5695951f70a25e27682dc568acf56115ad749709b2a6e915cdd 66dfa06db09b390c00b7c7ebeea00845f73c999d8ea9352b1128bdf10113c7500b 76a03f6b38d0920b5589961549be3d841ccc306f3edd600a53b4b9d4fa1249af87 af58dfb3ed694289477e853f7d062f58911f7bdb98033b001ee90f11b78f031cff ac2b5a07e11b01a2a6c1cda059a728f8253a5ff87267623253fc022d3993b27e2f 344b99eb6072ff7c7ee160724f8fbca562be49247ffae42b55ea79dad5 n = ea055cef495dec2d8fb3aef519ca87bd1575fa0ae15dd433f4a5f6c40d34ed 6ba2388172ab7d2183ed970a669d427dc2774ced66a3f082b8e23e94e7de7532f4 f30bb4a5bbf2e1db2cba0752858a7c7a9bb892c5d6af7e90a7cee8f0097d14498c 8b482f86348640af61b66640538e834f23ba8f906048db0e57b6fdc162ba2a8a0e aedd5423f23d8f89413223d89f473029cba11a211eb59e41fb8f0b8ddc651d115d 9f07ac30296485a9adbd71cc5d9e4a448bd6d70785e838a978b2e66513eb897c96 2e85f00a36cc0a3a613183d8bd1572f895901eb8155af9797dbd4aa14726f41571 2bf0eb29fa0a9e938cf5325def05d3af7e686227456d903233e316c8cc50341615 e59b665f0a4a2c32cfccbf9469bdf89564481fb7afc27a7127741f79424e0a35cd c466dd33ef5a2067f75c86e06af9c03c68c6e78be5f1a4f49ea03569cd9f74c3a0 ff290ca4ce2c2fa5b770ef8032b26a517c257b7b1c424622c5c04cf20f2290a268 939e0cc79dfbac71842f94727b07bfafaded7db6c7f13b e = 010001 d = 6e68e957dbfd7c1862dc1b87780b9dcf0ff9016770bc9c09873b66194941d7 6218bf2013c1e4df9326dd4402f5df110656d2ec8ea87a28b2a1cb74e590872aeb 765fe772ea21c57d6ab4ba0fad019189273f05c061719afd14af02277dd28d67c5 ef50b75b521ca51819b9bcb44cb7c82be66776a45f490050dc0171e77374f1ed00 d06f8beb09b711a9682107d8840d4a23edf6ac25441fdbf2b584dfa6a67cee21eb 51c484f09416e11914e774713f1a17600fb9e4e99fbbd83fdcba4b09145dd98094 49a1713777161c912d5d595362314b0ea9d1199e97780e8b3293a39af4019fcc74 6aaf78dbb7db06852c3358a9ed02ab1d15831a148b27b932c117445a4a6f5114ed fa3ccc9a9862df714b78a5362aab5e30501b4a729af73e3cdcabe19aac4928b668 969780ad33d9df206d904b978a055f4abbc64987744526856e16ef55962453e3ed 7a8055b0d79d051c50c94584ec7501dbd4856d7a21e43f25d8749e683cca2f53f5 75af1d80f39d8e6932ffdf201d179cbf98314c4048c6c1 4096-bit key: p = ac803464c8b2082153e15d5a0698d0a2990397fa01c1edd6171a5315e743c9 9feb7acd31c37529d4f83405e657c390488d19f7da9ef9d9f9cff4b460d2a26eb1 0f90cf4aaf55a19e21dc3bb697723a673e12bbc6580adc7bb72adaddf4682d656f f5b992e62379bc7b0ac977f2bfbcfac634e04ed597ef302684be72c6bf7db10b80 f452d412d09e63e017acba378ccc6ea58e683e5641d1e72248f3201a5632f4af75 25e91f9e0733731d264fe36802f416cb3e182b21e67a12e3bfba9a9cf40a45ff32 addfae78063933120238ac61fbb995300a8602aa84f993bed375d6ccba86ad0c8e fa5f0950aa2c92779febce9d05fa7a1f0d6e5c0d785de93c108297 Goldberg, et al. Expires 10 February 2023 [Page 40] Internet-Draft VRF August 2022 q = feb39bb6ee78adfa524e9c0821f60c20d3cff74f8b49731d67ea27d218bcb2 0c87498d30dfd398bc23daff7b33dc330db93e6c0e5e6196e035446c6db7cfdb98 68b9518d94670b31f9c4d2109cf32c9cc8ac2fc4a6c2e1078510522c81610a81a7 07997933ee24030b572a76ee51aa683312ecaa51d8558b3b19cccf65fc867354ae 193fd5c4f5d5a7180c5ca1e90fcc42f6915dff69a3d1e49046f6c3ef841b262ba8 9ddcfde2ed3caeb5bd594181a76f6f1ce01fc65c6f925f6d5b77037c2cbf7b6047 e19f7b9c846c80238f1c8284c33bfd90c79de91381bb883b0de568aaf4b4a3c3f9 c98f92e9f6a51f010bcc1dacfd72bfdfda29f527d7f4913153bef7 n = aba03a8d8527bfc0cbea1cb9a100f4ee7870aedd74a6406f108f7a07f37433 6025357e256d655b342d73369102d03c7dcf3c14ed70aac7ebb62498c570068f71 f1f165e14527f96d946ba839412252eacea604e7d6fd47a0bb9de776679fa9ad64 85a076fda04a2015322626dcd2eb91d6b6248802e6d453eb4cbf5e1bfebed02d6a b36cfe3dd1e8b9749d4853a029940a0bed3aa3128fd8e2e6cd1115db15405bb383 7012f56bdc5a6895ec5cc6bca52f7952cfe3c7d5d81d4d3d1c9a29a429eeedfbf5 8da0a5b17480875b8071f49eb568fc8d8c023c83b3ed870c3775aaf0578485d757 b4ab18d8e5fdb30c2b5586047e6203ab1636e376f1c7031f171e2807a2058ece89 0cc8fae29ba819df76b45ddb514caee63db1c5e7a3af7468febff82bfe2eb79e3c 5d1383b7ebee86f02e9cc1853f0f4486f7eb8fee23a2f794317ffd1c39471086df bfc0e3c0f412f917225f5c551557f38c11f172eca257e4b5908a571e4daa7c7434 903701f21937df87d10de9b50ada97e65855d5e786db8f3f86248b55d999ec3153 8bd1a409f3e13de46dccc05325774e89016708f8a96240ae1c16641e8b12ab0725 7e88aa50d3546e7a91073d85ed601775a3c08e9b7c242d20664dfd4e70a05218d9 f2c7d760fab3cd772d9362527917cf5b51817e8c2aef51cb3b0dd8cb838097e513 537f1d9c3c4708f44ed270db963c7d72cf11b1 e = 010001 d = 1efd8dd524282b4deb04592f83cd226d353e53b5156d37d15652321ce16f28 1fc258487105b1f9a81054ef937bc89243bd7a01e56624d078d5a9021514c77a7b 7eceb230dd45fc9a36e4c1b9a4f347b9b29af3e3d14466fcb5242c398b389f70f9 e7cf33ed54564e38c597720909e513ae8bb149060d1c6612e506e13d78e087c2cb b39e88c22cf73315c598dbd0ddf1276743ed04a943644c84949ef32d5e4702c805 81e54a7fb18879be28b21008dc63182b45f2c190f1b748cd322efc39f2807c64b4 d06023cb49583418e7b6ac0f447eb2abf48e2ad335583cbc8dff2760c2cce14623 46326708336f7e374253ed213e990044927c52d29591f414571e509afc2396a6af 9843303a19673bcdec1e3fc7c0d6c3f43b4bf88ce83e2bdcfb5e39069fe32800cf 3f6f6d9917b8083a66ce23a9ab5b0c95bbcc6dfc21d38dadecc20725b13ce2954b a1bd45ec151a8877fed317cac60b2afaa96c826df6d1c48e7c10649dccc75bdf90 5c362c6934da06c3ce30f5befc1cf776d7fda673625147b1108ecb5473f7f58827 9533eb184d748230443694b9761b01532ba707563ffa4962321e44fdb710025e8a 6e00d29bf01ea040618ee111b5d79ac860083f91aa614777cc99d739458f7c53d6 3cea7155b118068e0b30b35ed6d0cfc75672f18d075157a3ed31bfa1ce2cea2343 57ec76117cc687c274636077abc437cb70a029 A.1. RSA-FDH-VRF-SHA256 Example 1, using the 2048-bit key above: alpha = (the empty string) Goldberg, et al. Expires 10 February 2023 [Page 41] Internet-Draft VRF August 2022 EM = 092ea69ca4f5630d4bd1012805ad23528a5f44c040829b4a0208491913ee3 9711889bce5347765072efb0b7f8ad9798c830085d9babe10c29f1a649dbb9a64c 93a8cdaa325d37814faa15a1071ba81c39275f3cd66ce70fd21ee3acc7ac127c5d e8f2a816b05aff19e4e63451cfe51fef059b2547302387449b4df1ab8eaa5bfc84 dbbc5edf3b07eb8fe3fe2a93858bd0d55d6f0686f2eb449ed4c609b3083de04b49 d409a425509d89d282de806a6ce66892edc30337f780b15c7695b26383516f1fc1 8f7eab52557c654467600e2e272ef41e7e4a060b42f7533bae603a7fa50f497a64 a1508b93826d99643a2001d1c958a7a06da0370668634d678a5de pi = 14234ff8a9487e1b36a23086e258135b8a8a7ff2e23f19c0dfeca0c0a943f 119ebd336fdc292ef67b56e32ba06f9941893754a8b97c82f68974b2b34c17f6d4 3bfd55eb110cd7ea3452d59a24e4ddb8d4cdf040c814e22e3537ca09c2e2dc5dd8 ea281e6492ad335378f9f437eed30c51eeeee66ef14efb4000c75c802e9c5a6bb8 039c0258d4347981159d0ef6990b5e9c8ac2fb03915d7ff1ffa0626e2e11714a63 342e59124c1fcea8e2816c1d9a7751feaaa66cf6c82cd3c58ffde66460d98246ab 358cc33baefae4dfb0d191e9b6d6c0e3f92c35200408925dc8bef39b78d1259f81 63a5003a693555f05290ef2e68345f27c6e2a8847c5c919d92e7505 beta = 79f0615d4677fb72571889453644013f1a31b08d222e3cee349d64ce1c41045a Example 2, using the 3072-bit key above: alpha = 74657374 (4 bytes; ASCII "test") EM = 20a059b7f7034d0d7696c63328cbbd4b40f7c656a632b4129915018fe6c5d ee8b5bde68ec2a5a78b1ca8483386e3a1a0fa07b4d329ea55facc3145c663ca90d f5ae46c903211a21bf908dc9a33bd09410cc09c7b4de5fbc79de3413bc80bccf2d 3aca2fc9c60c776619849ed3e704057ac3d5deacff845d5bc8084ac730c19a1466 8e53b5b8b90446b2272eaf59cdf985a7804c7b91cea1ce2582099b7b0f20163b11 d23110939dd62081b5aa46c62db76b2ac28473d2488970d480bdd8bef8cae9e812 74fe3f9925b012c1b55cba8c4291ec7433223cb872e422bb9e0d3775670d587e40 3660ff440a9c11a18a488abc716ae36840b2ef5b0db4a90d88f91d79536cef378b f8e76d173288e26241df522a3cf6bece49c960e43a2d93e7bed10b90580c5b3aff 056507b4ef27368579832cb4aeecc99c2d8ba402117457df5ae0ed28068ef8b2e0 d4582f8edacfcad02c83bfab778460b979e9e984827bbefe2b544c0f3ed715dde6 dc1d7fc7c0f1f87d78aed8e148004b9f62e0321214c7c pi = 69f6042d400dfad4bdb9974fb73d12ec7823c6632df6b0a97ebc14d8a443f 74e1eb1a99b37204ba5c7e53bdaf7e3e3fae9efe47cc01d0b061585c8d757ecf00 663b3e1bd447d55b6ebd066b814a8d9c4434b224e9cb053a1fd038a58f3bf6b0c7 5b6f48f3c8d1ca398a730c133f86f244655f24c445324fdacd291d6d907f93efb2 4b59e509f2f370392f5e262fc106292792352d93800f0a1e3a389786619a622f60 05cab78ea5f0b5b7ca91ad2a9c6c34fc4a3f9b0332b99e907ffa7f750cdc8342e1 2da78f13ad49953bae1751c983ce3cd3335288ac856f85057a7f05acba6465a1c6 901ba30bc65b79fb7a847c42a5b4942d600ef316030f2ccafbc6f2e1ff0b46fb5c 8517cd98c93f81acf370cfdab559bb4270d07db5466e2342d56c476089f4738404 34cbcdbd1853b487a6df346208d12c17a48fe50b73b96f640a9761f570a516f615 7432b83dd18a1d05cc27b6f283a02fcfda147cf1471772e469961004bde7fa1585 7e7bf97b5a83c33fddbd9f4b2e2488f4ed5f7463c93f30b beta = bfe966f3fabde6f38a2792ad59bc836bbca39de6eff64f15a42886deff6dfcc5 Goldberg, et al. Expires 10 February 2023 [Page 42] Internet-Draft VRF August 2022 Example 3, using the 4096-bit key above: alpha = 73616d706c65 (6 bytes; ASCII "sample") EM = 17524fa1710b2f8a04e55da403b9b287b99a47afe9b81d3421482e3959b73 b4d4d4f4b52243ff2bfd2d29b1f030b521d0699065faa2b8903cca2b24cff42956 1234fcbd7bcccdac61b7dcb7bc61cd857287b4b42357adbd2fc83ecfc0d5bc199e 1f6e298b5e470bfc540bc85e933b02035792d65d861096dc03f048cae51c9adc6c 1ec09e7f5e595681b3d3976d94ba1a65c83c7e82503db5478d3d91b2e00a0f24e7 ffee1faed68aa62ad7ba4b2912ceb636064766f0535d3ca1369760d8edebc3c8d7 f5b4de784b644b59e44e24e436298cc33a3cd0f676d6fa0b76ca3b9b11aa68e078 9e83bd27b3af08518b9a5eb5f34f4953a79dc25c1285b20fa73e558dd99638eb51 bf89c80d7989f6e925d8ca5ed1d3f29cc1e1065400e4abbdbcf898791be12c5ae2 5661bf7de58a4cb6608c9a4dcc18150638068bb6452b25589ae0a943a67f024dd4 b5d9e7940c01886f798316156e5771c19457f9104618e271ae7863b65fd07f87fc d7862690115ce2d963eeac60f78b47c037d6ed3000b43d8149cee08df10a97158e e1daaf0a3963d23fb6ab0615891734e3039417d8ce03bfc18920c832a40385de95 d99b546b4bd24ecbfb2e75e9158ae1769bcff444990f54aa40e6a14e0aca52df00 062afbf81f6ce8193c53f8d26ac71324fc1db878379178abd695cf04a0fae3432d 1efffa73bba15b4e81fbaf598146a0c3edafc pi = 745cc4b6cb75b925194374cdf91b498e8d687c5d9cae1eb5352446c554c2c 43ac4aa3e2db5cf5e366df635ce156a277ebdbe78c5598588c98257069253127e5 7c9735b498f2939f14e1d019795cbd74cee2693acda2666624f174e8f666494aa1 2641bce0677acd20e5552d2690117bddb38678a18acdc380bd9d93f3b10960f9be 0c141fc14f5f30da324ff14020cb5b8aed9fbca3fc44b4973d8e5527bd81f5ae5d a67e5cc995abd1f7f9cdd3fa89b243fd4d5d5086ddb4eed77a2851fda1d4463f5e e037a4015aa40c420c2e609d5d0da4ef4a1622131022bdd9c9dc26d177b392663e a42050ef485fe9d53a8d28d84b82a21101bed5b213c82b578ce7c9c6f7c1bf9eca 3c248ace9f8835f3850158749111ce1a3bdf5766add72a95a47c8866a4817c42c5 cbd85d7bef52afab567e564f6625be9e04be6f7da012af68e6623ce4f29c692ba0 b5f7665bb435a2168bd3b88aae0c6168bb87ea6977f35bb5ad833d96dd14d340f2 a67b241b01fd8caf415842fd0a9dd5f4ccf4e70f15efdb85332e1df2bb186be15f 7195176435e01bfd00592710023c3a88ac0eea7189b32296f865a310375111a5f1 1b74d0c74b98dfe4c41ccbe695ea801ba47f37b878c1ed0fff8302705b63c89120 9ea63defa892969e015a86d97945189444524e5fb660f2b9d1dce337a12e0d003e a6262ca3194515cc3aa10b1a03ac9dd6995b54d beta = b663c5f90da1c12cd5d0e6d049679459e6f79f9fe16bc8b8e7e4d64d66500bd9 A.2. RSA-FDH-VRF-SHA384 Example 4, using the 2048-bit key above: alpha = (the empty string) EM = 1fa5c0079423d46edb63a833abb2e6ecfd5f39d1f2bd68fc666274d9e8ed8 ea8a13411126861167a4ba1d014d5ae213372de6bb4227b12e68e16e13ce108536 acb25f7219c49388f757219716fcb74eb0245b826c7e47ca793864885684b7673e 2f8579f26e78d63a940eacb23bf7619290cb5cd20859482c410fbd6d83a61f8940 866f512be7ac041fc23c3ee71d918ec994f3efa62f4f1f44eaa29f5b37a1e93e24 Goldberg, et al. Expires 10 February 2023 [Page 43] Internet-Draft VRF August 2022 73d8677fcbec312838379a3e05899ce44227c0c428fbd7d4f2d0b46cfde7254e39 67b220f8661f5dfbce7a3bf19364f522914478cead3eff0f0e02d166c251319bcf 86701af1c48436f49ceac990f52940f7da6ac6f5fdafa5c55dc77 pi = cffe6067bd9a1285dc1e8e543e8582c1250407cbfbcb2d01c4ddbc0d4ecb5 edeb721fb33147cf95f3084f7ce611f9877814770b14b8a671abc7ff085cf5cbe9 1e72d17f076d62db478d4758412a4e4b77a5591dc32b764a501d27e34e56189ba7 347a96f141ed1290f8ef7c4ce4009a9aba0715cbd0148721ea72bce00a22e59460 421a21e4d121fc0b4eda62479d93724afae7556abe66326487be38cfb795ac1968 c33a3890f2d8c0f7dfbe88bc76f16cbfd2b0f7ee8663abfd7b789caa5f6c77dd1c a991c9a9cc532f7550ad6184c8ece12ca4bea7e67f32405416a1f83245b09d06e7 b4214157fb444be12a2eddc4381678f2b862fb240fcedd2da7ffcb3 beta = dc37e83f8de0e990abada5096a05ca74754cfe7fe8e46b831e241009194 15415dcd5a305f5fb8195713cebc78649c8d1 Example 5, using the 3072-bit key above: alpha = 74657374 (4 bytes; ASCII "test") EM = fa2fd7c735c961b43b01c005faefc4e39505ede3914076d4dee40d52acf72 7de1782386ad6e9e07faf7666c8f45fde93b024d97c40651b957cfcccc42b8596a 68a5495c02313ed9ecbb705ab0689c38b9e57af035189e377ad50b4704004c2a97 3d9f7554204b03e8b925a973d41a9c3432246eb2eab2f729f03d3a63c9c38c0cc2 baa440ed5e2d61644405e4b5c1acaac85d8de75a4de00419a478e6c44a97b3e898 75c318400ce8d75b84c416ffd501ba78dd3203f21c6610fcaa4d8fc94f45e80dc6 5b7e48967199e7acdb18d82413b7018192a6fa2da5d6838adb8e6139f8d12abcce 7d5fd20cfa031c4971e563d4863d498591dc652a937db5e0bfd68535e3c9db9611 8874287c2291a5d3b29aa142795e60f1ade2c8c4d627ee678b652f5fded61f9a60 d2fa9cf5fb5e6a7fd63d81c91ea2269388f0a96fae77da0957695779385c757489 56972ab1cb5e19ad3cc6a357b9ffd368ca985dd9c0e53dd42aff5985f7a234af96 ad9e34e459a958b808e858f6d7be2e964c33cefad9660 pi = 22c9278e7171183cf6a3ce108f0400e308a9177c39a171f77777c106c966e b041824ce43fa56c5c77576646dd110e0b5d7f838bd5b1d1bf2c1feb1520397dd5 2d3cea6dbb49d786aa3bf3f5235e7692e583d290c7192102a6e0cb64f5229a326d 4d00267fd75aae9687167ea0d3d450b2d63519ad605e64c77438728a190a129b11 63939a5b7b0721b8d81efbf99a96944f63bf80ecc932fe40402d67c3e099a317cd 1d13ac6947096308050ea6dad18fdb0958ae565d07d29e619673798f52b8d1dfdb f29b4641324ea6db5b9f35870acde7bf68e0829534d1c1f43ca9a16861efd82fb8 83e35d581f613d2dfbc89d01a84fdf081a3a850f2e865188cd995857222160c547 80dc310a6ec100b9bac30f3af92e641360cad8dc255b56fa28e88ffcbef8ebe6ba 8557e4ec44a7d0ebef882ade36db0d89be71ecaa2b35026c9d328d2384b54ae68d e2ea70160ddde9aced5a8d896590fc185b408732cc04a249eff27501594902bf3a f4a3743c4da50c5d62a74746007dedb8358ecfef78c75ab beta = 5bdf742667ad10080f4ca573ec66f751e82e4077d0db1b281df421af68d 39412e70362dc5101b4b46e1e453eea7e0989 Example 6, using the 4096-bit key above: alpha = 73616d706c65 (6 bytes; ASCII "sample") Goldberg, et al. Expires 10 February 2023 [Page 44] Internet-Draft VRF August 2022 EM = 1b1d2f330ee20b9b1754f5e6ee4126cf03ea2c7f4e8c52d96111da7f99509 042428ec2f2eafdf41716c04a9976a26df77b3d4cea8b10b216e7786fb49e923d9 84a2ee13ad82b95783b68fcf3444b65d1353619602ae06e392dc030be105d4cebc 6ff8a647b79115357833bd5312b9d3f0df1a307e782ff4db8de0eb16259d6bff2f 57b3dd60a57693d607c42013cbcfc140a77d4a651492854afbacca377ed6729d1c be72999a62a96190fb630e5abc54d5cbe93254426df4e2315dbc777360ffb2401b 3dedbed1acacf4b3a63b5ff8e5ab6c0f8ffd9e2a34fffd68a8a593c64de2660dce daaab13cd42ebf5720d49f3120b01f45f29d1f465e995b148c9266aa97793a9da2 f38831d00f95f9688b1c50b52a4cbcc14f8287db822381cdddf609c9c178286b1b c2f94d7ef4d5ceb1293dd7b0fac16d1b3a8b2a7fcc454e52efd2de5a799397fd55 a909641fa775463f4808b520c3ebe0f94e2765f8538d91a4f53bb746e7d5eaf55b 3876503760f5c015f9e52bc54bdfc9632028db5e88b7dc0b1e9f1661d0a9b3574e 46311de8ef6278c4c14f68375763e5df0d4cf221a4c3e84493ed0c36984c172d87 b513857af4b6c10174dea9db6464e2bab210aa492987f0255d2c5588b1c79769da 03b62f691d5c4e5fac65505c317bf96b4f70e97c002aa0a032b02e48ee3aead570 3bde3186ce138f29ba36219fd3558af417945 pi = 89d801e364fd48c3b8672e7d7abd8a2a1e5bd36bb1e38af5aaefa2f01cde6 86fa2e33f88fdcc8eb3babcf1c66cbbf7dcddb614041813990787be5feabe86bbe c373d2cbf7c080caa0e37a339d5de1d1455de28f9bef76cd72500c669e9cab4599 b55dc155d9dd5810174c170f646d3b0b459347c17347c0281eecf5055cf887d6bd 0a2c962c77d5ff9355a53cea64c34ea0888110ec4eb32da69022e293a8843d4c06 c9d6e020c594335720467a8337c6a939fb2c5d710f7bdab48a52f4e7483dae062c 1b9f66f7c9038ba9ceef3d61cb4cc004319c94a267a2425b5f042cd7f1a17922d6 596a88a6fefaef41fc87742f2badee7d7613179589b4d02611ac8fd7895d926f48 4f79542cdf7f034dd536c9596da2f588ac9840f6bb05875bd17107e7458cc5ea36 8a7699fd60c35b54253a718c26cf518712be9d86213b2c6bddd0b7dd169f9240e7 7bfc44223675454f9c5596ad2e6e607ea65011a721ecbfa993172ae372ae874377 9b33278d25e11ced77b14bc481fce60e4fc10a8a211d8b359906509d6830c653d9 1c1a86865219db43f62c70ac6780644d2bd73c5c256527a3eaefaebaf1f2207324 17e17dbf598636616f70f2088969ac796a853dc8a5f270a1c505797e83d1675e4f 40b59c150ca06c49bb0967a2e0c7e74eff9e182d0f7bb6f54f68fe788b89d2191c 87bbf7f3927978449c2174baa581dc64a9c58ed beta = 8ec4d150788513c85eea3490d1a1ee1b7a397602d3f9c8b467527f09fab 5252e539f82e8002825608295ebbba19644dd A.3. RSA-FDH-VRF-SHA512 Example 7, using the 2048-bit key above: alpha = (the empty string) EM = 7b08a7fff4e5d8fd4978ac5a0ddf48537a2bb3f952dcdc00affb25d747b40 85c29c68dddaa87378db32396219ce784acebe70699286318f42794927f546de5d 85bbefd80a02c3aa714fc17090baa0d0f7fb504e1af0b79ea02d41dc0bf576b8f2 1472dd4c55f96bd64772d3ebd0347abe74b9fdf35b754d0405e42ceb0e290fdd91 ef766a3e27ff59cd86572d15274f6fd49400ec4d126145f3cae200d67d5d108999 61658ece7dcbf41f1cca63f8b50399955416a1f55e0af116fac2a9fd1f2dc0085e 6ad6c1c4bc12d9308d9a030c3e2ea7f037d1c98beb23d43d67a97e5bf52382b8e8 90c5967ab42f2010cac985d3a52fe726045746d4ffef901127646 Goldberg, et al. Expires 10 February 2023 [Page 45] Internet-Draft VRF August 2022 pi = a280db108df5ad6ac1bed67efbc5c6fc6da0d301b9c0b41d26e379cd223c6 13c59d52c987e4baaa6de4de2103284ddd56aa0b662dfe8faa8f6a503b83b7c81f 481e23a08761d49a151ada1d9daa132138bbd6f80204c7fa87716b120df957224f 92b32a3a0f96c3b209080c408618a92382ab5575f10a57c24ee0ffd01d6b822dc3 6b27600bf36aafadf0a01e65aa6a0f2fc1a9dcd207d9bf5181a9ca69120e154108 00a26efd3ce619349592eeff7b1851737bd033a83f88744ddd3d3e782efb6d2438 ffda22ddcaa32c821c6730a05d5bdab88c354809d615884744ff10276496bee70b 62feb6ed07a3948823e9ee2a453dbcd4450192c9de0128adfc7e147 beta = 808ca1f8f66a48118aacb011394bd4e5f0011c89ca913943d467b81cc5c 43086e588abdde061c3ee30f4c15b2a6b51ad0ada42c0737fd7b2206fb43d35c8e d22 Example 8, using the 3072-bit key above: alpha = 74657374 (4 bytes; ASCII "test") EM = 803b6618f0ad47da2db309b1f57807a286500020c9e2b1427ebd9fff1104e 3aa8a69210441cd58344bd810c4900825c84b1e5e36825f1e397df54c4419f8525 d9a09a49e7fedc18b8d906cbd9ea831c55f2aaa0461e19ddd6ec9d14dafa1fcf49 b77458a65427b7f060bc7425538e5d3af1813752cb452d0b098514110399734d1f 55870c65ea3e799e6d9024a9e2fb95883e580578811a8c7d34b18f8fabc6c05fb9 697335fcf2cb1b7576ee7a39dcff129e1f142106c45f30a8ae62370f576d1d1d8c 6307fccfe25cb431f348dea81b6b7e6307bbefda2a0b23036653a612226392a573 b7d62e28f9fecc7f4be0bf0a3049ce8ed276b34130faa943aeeedf962b42a3fc6c 881bbf9a62039e9c0850f1393a2a02c6848d06c3520e086541d8af99ea3ef9f9da 2e3b2bd3172682a47e5965899bc576b66e29a0b8dcf06871202a1a4e7f2ff19bdd 9eac2241129a73d7d01303b80372ac62a0d5b6bfd1d7119e561ace229cd53d2c99 63d6127b9ade16dce4b07d1cd89247ffc438811dc8b3c pi = 1aa828e0a751074fed2fa776fd29336a84987c064eeebcd3a8129fb688b47 eb7109987d01db0c3624ba7cc75e2f1ad60f5e204a250a329048bc34df34d41bfe ea6651774d249ff9fc29aeabdf524400527aa1c4100b1af86b2dcc2e7aecc77f38 6b80f29ccd807cb705b5057431832dafe56733a1e7bfcba1d052a26d1a8512f297 b5abad5afd64fbcf21b57531a9b2c8217c0d9f1c875c196d998f61e8017f6b6ebe 7317545ed390e18305bc96abb1514ec271963d02bed91ccf029d022189f84bac8c fa216da54e39919118348dfea6f4f6532b49da7820ee2a21f42b762e107722ad0a bf62271e0640d6b1c4d1a39b94ebd74b4283de2d6550cbdb1f29cac51671e9c8fc 0ea0fdbb082a14a221e0531615f2bcfba0d70e99e4997cb00f81fcab2b95566322 0234a5e90f29bd08e6fa50dd92770d9e514e0f9eb27aee634877bcea681ffd7da2 b5be2f80c1dde1243b17ac726401cf961c5ce06640eb93352402c1ebc59c92188c 511b375d63124846b46017fe36dc13fc2d34dbd80b312e0 beta = 9202b6715b7921c5eb35572ed9ebb85848d3345efadd665049ce889be46 322586d4177864c9179468473518c6b6ac2e9c85ae5ee5fcd3c0d8e6d4d8f18be6 238 Example 9, using the 4096-bit key above: alpha = 73616d706c65 (6 bytes; ASCII "sample") Goldberg, et al. Expires 10 February 2023 [Page 46] Internet-Draft VRF August 2022 EM = 289607894786ccf223b1e758232f3402aa50cd48bca3d2bd64b2ea9b4a69d c91756a42b2c1feaaa777763b9b7c91888c580433ac85f5fbb360f129ecee739f6 9b560657687d38f7d43c84f6605005c38f56c91310eff27bae49b14d8a36542d69 b70efca8637b845be0f029c085a7b6aad6ca0eb65fffdf8d55d9538d3b54044ebb c26e092b2f3ddaece7aa5b4b234ec848bfdc72a4ecdc10c66fb845cfc5ad39756e 7f26007cea0ebf1e878636f4e39308fe7a317a9b7e90051536ac028bc1a2ec200a 5dad0e3b74717bd9e7ea620919e315799e0fea7b0895fcbc0b95686b2495dc23e3 cd56a16652b0df0dbd3ca8a6c96b13973a0c31a5541e211229da8a56e588a616c7 21baab8e2d30313008c2374887f147598468b378bf8949ab1165b9348245d0a6a5 f795918fce05f0d072f81f78c7224e7f1c4684877d714f231d5775c88759086121 2eae2d174761158ac7d653b18f0d4b71362c0eb8a67bed1a48a4e7dc739b2b4469 4514cae7f192d236afb1ab2409f24dfa94a2d705d0087860d844ba04564bb6733c a20089417d74eaed86d7e68ced681e9d88a9c3d7e6a33927592820cb9a38d45393 32e509296489e54cd6b8495f100c36debe1f719578b15e8a99cc8febc3212e8147 8aeca616a5230ae84e7079f52aefb2ec2a97157fb5d60e1ddcf03b134be2c93ffb a41d5d068750adc8df07e5a264640f7e586bd pi = 17d7635cac33b0b72ea1c0afb1f681d1a96c5073ed9f88ed8bb54eb428d7b 2db4ee3355eee512ddc7af50694b37fd389f990278e22095b2582c78c4ed6070b0 c7382b0308b6d546141a9b0d6ebb3af97abd93c16a5d34a2d805d8aa444fed2297 d017571a693d221fda094d40500ab9b203d397a7543e72b26b06e561d49696e01d eebfed58b46611dd5a346e227d7519f8ffd1dc76a172c9f7f355c3e7e5ee7773ed ab00a22af5c39367f3779da68ce6da9f8a594f5f6149012501181653572fe5549a 9c2bf36148b3bdc94feaedd600727fe5c11b7dcbfd73002ae08061cb4b84ba47f1 bf8c5d46bc2acb7cb4964a6dca7eedc396e663a64121d93dade8b83cea09d76653 cca1a8d20d6b7323a890651dc575025ba1be02d08c5946f50cde438339b06e8633 198da0d467d2cac7d98ae62dd71353f6fb19aa9daac851d0ce237b21db93b91e51 8d5c1ac36cdf874975deb7aab3942acc3980f221f33ad1254eb8ac3138e087d045 c4746e0b7eedcaf2a1a173559783eba8691555c1b0e468f8efe6501679b760038e d6fc9ce6aa5ae24b3f1178713793c8e5ee96035a2f0ee02e2d10ac098613358d3c ff10f4dff3437f2a48252c5d6805288fbd7ee05356f80db12aaeabf6638677abf5 b8eb2376fb76861cf1b817d5a0b878dae6beac44f078f37d982d941a77582a7778 4fabd632e28d664d9f705f31e24d1ca623dfac7 beta = 6026f6defaf534cc79ce7c1b0370fb53e4825d2d44f549f696e06d693c3 9e852e21a5e3b6ff093618dd277b40678957e1b90e8e6ca742efed30dc309b3b24 2b8 Appendix B. Test Vectors for the ECVRF ciphersuites The test vectors in this section were generated using code at https://github.com/reyzin/ecvrf. B.1. ECVRF-P256-SHA256-TAI The example secret keys and messages in Examples 10 and 11 are taken from Appendix A.2.5 of [RFC6979]. Example 10: Goldberg, et al. Expires 10 February 2023 [Page 47] Internet-Draft VRF August 2022 SK = x = c9afa9d845ba75166b5c215767b1d6934e50c3db36e89b127b8a622b120f6721 PK = 0360fed4ba255a9d31c961eb74c6356d68c049b8923b61fa6ce669622e60f29fb6 alpha = 73616d706c65 (6 bytes; ASCII "sample") try_and_increment succeeded on ctr = 1 H = 0272a877532e9ac193aff4401234266f59900a4a9e3fc3cfc6a4b7e467a15d06d4 k = 0d90591273453d2dc67312d39914e3a93e194ab47a58cd598886897076986f77 U = k*B = 02bb6a034f67643c6183c10f8b41dc4babf88bff154b674e377d90bde009c21672 V = k*H = 02893ebee7af9a0faa6da810da8a91f9d50e1dc071240c9706726820ff919e8394 pi = 035b5c726e8c0e2c488a107c600578ee75cb702343c153cb1eb8dec77f4b5 071b4a53f0a46f018bc2c56e58d383f2305e0975972c26feea0eb122fe7893c15a f376b33edf7de17c6ea056d4d82de6bc02f beta = a3ad7b0ef73d8fc6655053ea22f9bede8c743f08bbed3d38821f0e16474b505e Example 11: SK = x = c9afa9d845ba75166b5c215767b1d6934e50c3db36e89b127b8a622b120f6721 PK = 0360fed4ba255a9d31c961eb74c6356d68c049b8923b61fa6ce669622e60f29fb6 alpha = 74657374 (4 bytes; ASCII "test") try_and_increment succeeded on ctr = 3 H = 02173119b4fff5e6f8afed4868a29fe8920f1b54c2cf89cc7b301d0d473de6b974 k = 5852353a868bdce26938cde1826723e58bf8cb06dd2fed475213ea6f3b12e961 U = k*B = 022779a2cafcb65414c4a04a4b4d2adf4c50395f57995e89e6de823250d91bc48e V = k*H = 033b4a14731672e82339f03b45ff6b5b13dee7ada38c9bf1d6f8f61e2ce5921119 pi = 034dac60aba508ba0c01aa9be80377ebd7562c4a52d74722e0abae7dc3080 ddb56c19e067b15a8a8174905b13617804534214f935b94c2287f797e393eb0816 969d864f37625b443f30f1a5a33f2b3c854 beta = a284f94ceec2ff4b3794629da7cbafa49121972671b466cab4ce170aa365f26d The example secret key in Example 12 is taken from Appendix L.4.2 of [ANSI.X9-62-2005]. Example 12: Goldberg, et al. Expires 10 February 2023 [Page 48] Internet-Draft VRF August 2022 SK = x = 2ca1411a41b17b24cc8c3b089cfd033f1920202a6c0de8abb97df1498d50d2c8 PK = 03596375e6ce57e0f20294fc46bdfcfd19a39f8161b58695b3ec5b3d16427c274d alpha = 4578616d706c65207573696e67204543445341206b65792066726f6d20 417070656e646978204c2e342e32206f6620414e53492e58392d36322d32303035 (62 bytes; ASCII "Example using ECDSA key from Appendix L.4.2 of ANSI.X9-62-2005") try_and_increment succeeded on ctr = 1 H = 0258055c26c4b01d01c00fb57567955f7d39cd6f6e85fd37c58f696cc6b7aa761d k = 5689e2e08e1110b4dda293ac21667eac6db5de4a46a519c73d533f69be2f4da3 U = k*B = 020f465cd0ec74d2e23af0abde4c07e866ae4e5138bded5dd1196b8843f380db84 V = k*H = 036cb6f811428fc4904370b86c488f60c280fa5b496d2f34ff8772f60ed24b2d1d pi = 03d03398bf53aa23831d7d1b2937e005fb0062cbefa06796579f2a1fc7e7b 8c667d091c00b0f5c3619d10ecea44363b5a599cadc5b2957e223fec62e81f7b48 25fc799a771a3d7334b9186bdbee87316b1 beta = 90871e06da5caa39a3c61578ebb844de8635e27ac0b13e829997d0d95dd98c19 B.2. ECVRF-P256-SHA256-SSWU The example secret keys and messages in Examples 13 and 14 are taken from Appendix A.2.5 of [RFC6979]. Example 13: SK = x = c9afa9d845ba75166b5c215767b1d6934e50c3db36e89b127b8a622b120f6721 PK = 0360fed4ba255a9d31c961eb74c6356d68c049b8923b61fa6ce669622e60f29fb6 alpha = 73616d706c65 (6 bytes; ASCII "sample") In SSWU: uniform_bytes = 5024e98d6067dec313af09ff0cbe78218324a645c 2a4b0aae2453f6fe91aa3bd9471f7b4a5fbf128e4b53f0c59603f7e In SSWU: u = df565615a2372e8b31b8771f7503bafc144e48b05688b97958cc27ce29a8d810 In SSWU: x1 = e7e39eb8a4c982426fcff629e55a3e13516cfeb62c02c369b1e750316f5e94eb In SSWU: gx1 is a nonsquare H = 02b31973e872d4a097e2cfae9f37af9f9d73428fde74ac537dda93b5f18dbc5842 k = e92820035a0a8afe132826c6312662b6ea733fc1a0d33737945016de54d02dd8 U = k*B = 031490f49d0355ffcdf66e40df788bee93861917ee713acff79be40d20cc91a30a Goldberg, et al. Expires 10 February 2023 [Page 49] Internet-Draft VRF August 2022 V = k*H = 03701df0228138fa3d16612c0d720389326b3265151bc7ac696ea4d0591cd053e3 pi = 0331d984ca8fece9cbb9a144c0d53df3c4c7a33080c1e02ddb1a96a365394 c7888782fffde7b842c38c20c08de6ec6c2e7027a97000f2c9fa4425d5c03e639f b48fde58114d755985498d7eb234cf4aed9 beta = 21e66dc9747430f17ed9efeda054cf4a264b097b9e8956a1787526ed00dc664b Example 14: SK = x = c9afa9d845ba75166b5c215767b1d6934e50c3db36e89b127b8a622b120f6721 PK = 0360fed4ba255a9d31c961eb74c6356d68c049b8923b61fa6ce669622e60f29fb6 alpha = 74657374 (4 bytes; ASCII "test") In SSWU: uniform_bytes = 910cc66d84a57985a1d15843dad83fd9138a109af b243b7fa5d64d766ec9ca3894fdcf46ebeb21a3972eb452a4232fd3 In SSWU: u = d8b0107f7e7aa36390240d834852f8703a6dc407019d6196bda5861b8fc00181 In SSWU: x1 = ccc747fa7318b9486ce4044adbbecaa084c27be6eda88eb7b7f3d688fd0968c7 In SSWU: gx1 is a square H = 03ccc747fa7318b9486ce4044adbbecaa084c27be6eda88eb7b7f3d688fd0968c7 k = febc3451ea7639fde2cf41ffd03f463124ecb3b5a79913db1ed069147c8a7dea U = k*B = 031200f9900e96f811d1247d353573f47e0d9da601fc992566234fc1a5b37749ae V = k*H = 02d3715dcfee136c7ae50e95ffca76f4ca6c29ddfb92a39c31a0d48e75c6605cd1 pi = 03f814c0455d32dbc75ad3aea08c7e2db31748e12802db23640203aebf1fa 8db2743aad348a3006dc1caad7da28687320740bf7dd78fe13c298867321ce3b36 b79ec3093b7083ac5e4daf3465f9f43c627 beta = 8e7185d2b420e4f4681f44ce313a26d05613323837da09a69f00491a83ad25dd The example secret key in Example 15 is taken from Appendix L.4.2 of [ANSI.X9-62-2005]. Example 15: SK = x = 2ca1411a41b17b24cc8c3b089cfd033f1920202a6c0de8abb97df1498d50d2c8 PK = 03596375e6ce57e0f20294fc46bdfcfd19a39f8161b58695b3ec5b3d16427c274d Goldberg, et al. Expires 10 February 2023 [Page 50] Internet-Draft VRF August 2022 alpha = 4578616d706c65207573696e67204543445341206b65792066726f6d20 417070656e646978204c2e342e32206f6620414e53492e58392d36322d32303035 (62 bytes; ASCII "Example using ECDSA key from Appendix L.4.2 of ANSI.X9-62-2005") In SSWU: uniform_bytes = 9b81d55a242d3e8438d3bcfb1bee985a87fd14480 2c9268cf9adeee160e6e9ff765569797a0f701cb4316018de2e7dd4 In SSWU: u = e43c98c2ae06d13839fedb0303e5ee815896beda39be83fb11325b97976efdce In SSWU: x1 = be9e195a50f175d3563aed8dc2d9f513a5536c1e9aee1757d86c08d32d582a86 In SSWU: gx1 is a nonsquare H = 022dd5150e5a2a24c66feab2f68532be1486e28e07f1b9a055cf38ccc16f6595ff k = 8e29221f33564f3f66f858ba2b0c14766e1057adbd422c3e7d0d99d5e142b613 U = k*B = 03a8823ff9fd16bf879261c740b9c7792b77fee0830f21314117e441784667958d V = k*H = 02d48fbb45921c755b73b25be2f23379e3ce69294f6cee9279815f57f4b422659d pi = 039f8d9cdc162c89be2871cbcb1435144739431db7fab437ab7bc4e2651a9 e99d5488405a11a6c7fc8defddd9e1573a563b7333aab4effe73ae9803274174c6 59269fd39b53e133dcd9e0d24f01288de9a beta = 4fbadf33b42a5f42f23a6f89952d2e634a6e3810f15878b46ef1bb85a04fe95a B.3. ECVRF-EDWARDS25519-SHA512-TAI The example secret keys and messages in Examples 16, 17, and 18 are taken from Section 7.1 of [RFC8032]. Example 16: SK = 9d61b19deffd5a60ba844af492ec2cc44449c5697b326919703bac031cae7f60 PK = d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a alpha = (the empty string) x = 307c83864f2833cb427a2ef1c00a013cfdff2768d980c0a3a520f006904de94f try_and_increment succeeded on ctr = 0 H = 91bbed02a99461df1ad4c6564a5f5d829d0b90cfc7903e7a5797bd658abf3318 k_string = 7100f3d9eadb6dc4743b029736ff283f5be494128df128df2817106 f345b8594b6d6da2d6fb0b4c0257eb337675d96eab49cf39e66cc2c9547c2bf8b2 a6afae4 k = 8a49edbd1492a8ee09766befe50a7d563051bf3406cbffc20a88def030730f0f Goldberg, et al. Expires 10 February 2023 [Page 51] Internet-Draft VRF August 2022 U = k*B = aef27c725be964c6a9bf4c45ca8e35df258c1878b838f37d9975523f09034071 V = k*H = 5016572f71466c646c119443455d6cb9b952f07d060ec8286d678615d55f954f pi = 8657106690b5526245a92b003bb079ccd1a92130477671f6fc01ad16f26f7 23f26f8a57ccaed74ee1b190bed1f479d9727d2d0f9b005a6e456a35d4fb0daab1 268a1b0db10836d9826a528ca76567805 beta = 90cf1df3b703cce59e2a35b925d411164068269d7b2d29f3301c03dd757 876ff66b71dda49d2de59d03450451af026798e8f81cd2e333de5cdf4f3e140fdd 8ae Example 17: SK = 4ccd089b28ff96da9db6c346ec114e0f5b8a319f35aba624da8cf6ed4fb8a6fb PK = 3d4017c3e843895a92b70aa74d1b7ebc9c982ccf2ec4968cc0cd55f12af4660c alpha = 72 (1 byte) x = 68bd9ed75882d52815a97585caf4790a7f6c6b3b7f821c5e259a24b02e502e51 try_and_increment succeeded on ctr = 1 H = 5b659fc3d4e9263fd9a4ed1d022d75eaacc20df5e09f9ea937502396598dc551 k_string = 42589bbf0c485c3c91c1621bb4bfe04aed7be76ee48f9b00793b234 2acb9c167cab856f9f9d4febc311330c20b0a8afd3743d05433e8be8d32522ecdc 16cc5ce k = d8c3a66921444cb3427d5d989f9b315aa8ca3375e9ec4d52207711a1fdb44107 U = k*B = 1dcb0a4821a2c48bf53548228b7f170962988f6d12f5439f31987ef41f034ab3 V = k*H = fd03c0bf498c752161bae4719105a074630a2aa5f200ff7b3995f7bfb1513423 pi = f3141cd382dc42909d19ec5110469e4feae18300e94f304590abdced48aed 5933bf0864a62558b3ed7f2fea45c92a465301b3bbf5e3e54ddf2d935be3b67926 da3ef39226bbc355bdc9850112c8f4b02 beta = eb4440665d3891d668e7e0fcaf587f1b4bd7fbfe99d0eb2211ccec90496 310eb5e33821bc613efb94db5e5b54c70a848a0bef4553a41befc57663b56373a5 031 Example 18: SK = c5aa8df43f9f837bedb7442f31dcb7b166d38535076f094b85ce3a2e0b4458f7 PK = fc51cd8e6218a1a38da47ed00230f0580816ed13ba3303ac5deb911548908025 alpha = af82 (2 bytes) x = 909a8b755ed902849023a55b15c23d11ba4d7f4ec5c2f51b1325a181991ea95c Goldberg, et al. Expires 10 February 2023 [Page 52] Internet-Draft VRF August 2022 try_and_increment succeeded on ctr = 0 H = bf4339376f5542811de615e3313d2b36f6f53c0acfebb482159711201192576a k_string = 38b868c335ccda94a088428cbf3ec8bc7955bfaffe1f3bd2aa2c59f c31a0febc59d0e1af3715773ce11b3bbdd7aba8e3505d4b9de6f7e4a96e67e0d6b b6d6c3a k = 5ffdbc72135d936014e8ab708585fda379405542b07e3bd2c0bd48437fbac60a U = k*B = 2bae73e15a64042fcebf062abe7e432b2eca6744f3e8265bc38e009cd577ecd5 V = k*H = 88cba1cb0d4f9b649d9a86026b69de076724a93a65c349c988954f0961c5d506 pi = 9bc0f79119cc5604bf02d23b4caede71393cedfbb191434dd016d30177ccb f8096bb474e53895c362d8628ee9f9ea3c0e52c7a5c691b6c18c9979866568add7 a2d41b00b05081ed0f58ee5e31b3a970e beta = 645427e5d00c62a23fb703732fa5d892940935942101e456ecca7bb217c 61c452118fec1219202a0edcf038bb6373241578be7217ba85a2687f7a0310b2df 19f B.4. ECVRF-EDWARDS25519-SHA512-ELL2 The example secret keys and messages in Examples 19, 20, and 21 are taken from Section 7.1 of [RFC8032]. Example 19: SK = 9d61b19deffd5a60ba844af492ec2cc44449c5697b326919703bac031cae7f60 PK = d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a alpha = (the empty string) x = 307c83864f2833cb427a2ef1c00a013cfdff2768d980c0a3a520f006904de94f In Elligator2: uniform_bytes = d620782a206d9de584b74e23ae5ee1db5ca 5298b3fc527c4867f049dee6dd419b3674967bd614890f621c128d72269ae In Elligator2: u = 30f037b9745a57a9a2b8a68da81f397c39d46dee9d047f86c427c53f8b29a55c In Elligator2: gx1 = 8cb66318fb2cea01672d6c27a5ab662ae33220961607f69276080a56477b4a08 In Elligator2: gx1 is a square H = b8066ebbb706c72b64390324e4a3276f129569eab100c26b9f05011200c1bad9 k_string = b5682049fee54fe2d519c9afff73bbfad724e69a82d5051496a4245 8f817bed7a386f96b1a78e5736756192aeb1818a20efb336a205ffede351cfe88d ab8d41c k = 55cbb247af9b8372259a97b2cfec656d78868deb33b203d51b9961c364522400 Goldberg, et al. Expires 10 February 2023 [Page 53] Internet-Draft VRF August 2022 U = k*B = 762f5c178b68f0cddcc1157918edf45ec334ac8e8286601a3256c3bbf858edd9 V = k*H = 4652eba1c4612e6fce762977a59420b451e12964adbe4fbecd58a7aeff5860af pi = 7d9c633ffeee27349264cf5c667579fc583b4bda63ab71d001f89c10003ab 46f14adf9a3cd8b8412d9038531e865c341cafa73589b023d14311c331a9ad15ff 2fb37831e00f0acaa6d73bc9997b06501 beta = 9d574bf9b8302ec0fc1e21c3ec5368269527b87b462ce36dab2d14ccf80 c53cccf6758f058c5b1c856b116388152bbe509ee3b9ecfe63d93c3b4346c1fbc6 c54 Example 20: SK = 4ccd089b28ff96da9db6c346ec114e0f5b8a319f35aba624da8cf6ed4fb8a6fb PK = 3d4017c3e843895a92b70aa74d1b7ebc9c982ccf2ec4968cc0cd55f12af4660c alpha = 72 (1 byte) x = 68bd9ed75882d52815a97585caf4790a7f6c6b3b7f821c5e259a24b02e502e51 In Elligator2: uniform_bytes = 04ae20a9ad2a2330fb33318e376a2448bd7 7bb99e81d126f47952b156590444a9225b84128b66a2f15b41294fa2f2f6d In Elligator2: u = 3092f033b16d4d5f74a3f7dc7091fe434b449065152b95476f121de899bb773d In Elligator2: gx1 = 25d7fe7f82456e7078e99fdb24ef2582b4608357cdba9c39a8d535a3fd98464d In Elligator2: gx1 is a nonsquare H = 76ac3ccb86158a9104dff819b1ca293426d305fd76b39b13c9356d9b58c08e57 k_string = 88bf479281fd29a6cbdffd67e2c5ec0024d92f14eaed58f43f22f37 c4c37f1d41e65c036fbf01f9fba11d554c07494d0c02e7e5c9d64be88ef78cab75 44e444d k = 9565956daeedf376cad61b829b2a4d21ba1b52e9b3e2457477a64630a9711003 U = k*B = 8ec26e77b8cb3114dd2265fe1564a4efb40d109aa3312536d93dfe3d8d80a061 V = k*H = fe799eb5770b4e3a5a27d22518bb631db183c8316bb552155f442c62a47d1c8b pi = 47b327393ff2dd81336f8a2ef10339112401253b3c714eeda879f12c50907 2ef055b48372bb82efbdce8e10c8cb9a2f9d60e93908f93df1623ad78a86a028d6 bc064dbfc75a6a57379ef855dc6733801 beta = 38561d6b77b71d30eb97a062168ae12b667ce5c28caccdf76bc88e093e4 635987cd96814ce55b4689b3dd2947f80e59aac7b7675f8083865b46c89b2ce9cc 735 Example 21: Goldberg, et al. Expires 10 February 2023 [Page 54] Internet-Draft VRF August 2022 SK = c5aa8df43f9f837bedb7442f31dcb7b166d38535076f094b85ce3a2e0b4458f7 PK = fc51cd8e6218a1a38da47ed00230f0580816ed13ba3303ac5deb911548908025 alpha = af82 (2 bytes) x = 909a8b755ed902849023a55b15c23d11ba4d7f4ec5c2f51b1325a181991ea95c In Elligator2: uniform_bytes = be0aed556e36cdfddf8f1eeddbb7356a24f ad64cf95a922a098038f215588b216beabbfe6acf20256188e883292b7a3a In Elligator2: u = f6675dc6d17fc790d4b3f1c6acf689a13d8b5815f23880092a925af94cd6fa24 In Elligator2: gx1 = a63d48e3247c903e22fdfb88fd9295e396712a5fe576af335dbe16f99f0af26c In Elligator2: gx1 is a square H = 13d2a8b5ca32db7e98094a61f656a08c6c964344e058879a386a947a4e189ed1 k_string = a7ddd74a3a7d165d511b02fa268710ddbb3b939282d276fa2efcfa5 aaf79cf576087299ca9234aacd7cd674d912deba00f4e291733ef189a51e36c861 b3d683b k = 1fda4077f737098b3f361c33a36cccafd7e9e9b720e1f84011254e25f37eed02 U = k*B = a012f35433df219a88ab0f9481f4e0065d00422c3285f3d34a8b0202f20bac60 V = k*H = fb613986d171b3e98319c7ca4dc44c5dd8314a6e5616c1a4f16ce72bd7a0c25a pi = 926e895d308f5e328e7aa159c06eddbe56d06846abf5d98c2512235eaa57f dce35b46edfc655bc828d44ad09d1150f31374e7ef73027e14760d42e77341fe05 467bb286cc2c9d7fde29120a0b2320d04 beta = 121b7f9b9aaaa29099fc04a94ba52784d44eac976dd1a3cca458733be5c d090a7b5fbd148444f17f8daf1fb55cb04b1ae85a626e30a54b4b0f8abf4a43314 a58 Authors' Addresses Sharon Goldberg Boston University 111 Cummington Mall Boston, MA 02215 United States of America Email: goldbe@cs.bu.edu Goldberg, et al. Expires 10 February 2023 [Page 55] Internet-Draft VRF August 2022 Leonid Reyzin Boston University and Algorand 111 Cummington Mall Boston, MA 02215 United States of America Email: reyzin@bu.edu Dimitrios Papadopoulos Hong Kong University of Science and Technology Clearwater Bay Hong Kong Email: dipapado@cse.ust.hk Jan Vcelak NS1 16 Beaver St New York, NY 10004 United States of America Email: jvcelak@ns1.com Goldberg, et al. Expires 10 February 2023 [Page 56] ./draft-ietf-rats-tpm-based-network-device-attest-14.txt0000644000764400076440000033104014216342500022720 0ustar iustiniustin RATS Working Group G. C. Fedorkow, Ed. Internet-Draft Juniper Networks, Inc. Intended status: Informational E. Voit Expires: 23 September 2022 Cisco J. Fitzgerald-McKay National Security Agency 22 March 2022 TPM-based Network Device Remote Integrity Verification draft-ietf-rats-tpm-based-network-device-attest-14 Abstract This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by the Trusted Computing Group (TCG)), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 23 September 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Fedorkow, et al. Expires 23 September 2022 [Page 1] Internet-Draft Network Device RIV March 2022 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Document Organization . . . . . . . . . . . . . . . . . . 5 1.4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Description of Remote Integrity Verification (RIV) . . . 6 1.6. Solution Requirements . . . . . . . . . . . . . . . . . . 8 1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.7.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 9 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9 2.1. RIV Software Configuration Attestation using TPM . . . . 9 2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 11 2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 13 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 15 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 16 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 18 2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 18 2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 20 3. Standards Components . . . . . . . . . . . . . . . . . . . . 20 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 20 3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 20 3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 21 3.2. Reference Model for Challenge-Response . . . . . . . . . 21 3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 23 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 24 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 26 5.2. Prevention of Spoofing and Person-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 29 5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 30 5.5. Other Factors for Trustworthy Operation . . . . . . . . . 30 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 32 9.2. Root of Trust for Measurement . . . . . . . . . . . . . . 34 9.3. Layering Model for Network Equipment Attester and Verifier . . . . . . . . . . . . . . . . . . . . . . . . 35 Fedorkow, et al. Expires 23 September 2022 [Page 2] Internet-Draft Network Device RIV March 2022 9.4. Implementation Notes . . . . . . . . . . . . . . . . . . 37 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.1. Normative References . . . . . . . . . . . . . . . . . . 38 10.2. Informative References . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction There are many aspects to consider in fielding a trusted computing device, from operating systems to applications. Mechanisms to prove that a device installed at a customer's site is authentic (i.e., not counterfeit) and has been configured with authorized software, all as part of a trusted supply chain, are just a few of the many aspects which need to be considered concurrently to have confidence that a device is truly trustworthy. A generic architecture for remote attestation has been defined in [I-D.ietf-rats-architecture]. Additionally, use cases for remotely attesting networking devices are discussed within Section 6 of [I-D.richardson-rats-usecases]. However, these documents do not provide sufficient guidance for network equipment vendors and operators to design, build, and deploy interoperable devices. The intent of this document is to provide such guidance. It does this by outlining the Remote Integrity Verification (RIV) problem, and then identifies elements that are necessary to get the complete, scalable attestation procedure working with commercial networking products such as routers, switches and firewalls. An underlying assumption will be the availability within the device of a Trusted Platform Module [TPM1.2], [TPM2.0] compatible cryptoprocessor to enable the trustworthy remote assessment of the device's software and hardware. 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology A number of terms are reused from [I-D.ietf-rats-architecture]. These include: Appraisal Policy for Evidence, Attestation Result, Attester, Evidence, Reference Value, Relying Party, Verifier, and Verifier Owner. Fedorkow, et al. Expires 23 September 2022 [Page 3] Internet-Draft Network Device RIV March 2022 Additionally, this document defines the following term: Attestation: the process of generating, conveying and appraising claims, backed by evidence, about device trustworthiness characteristics, including supply chain trust, identity, device provenance, software configuration, device composition, compliance to test suites, functional and assurance evaluations, etc. The goal of attestation is simply to assure an administrator or auditor that the device configuration and software that was launched when the device was last started is authentic and untampered-with. The determination of software authenticity is not prescribed in this document, but it's typically taken to mean a software image generated by an authority trusted by the administrator, such as the device manufacturer. Within the Trusted Computing Group (TCG) context, the scope of attestation is typically narrowed to describe the process by which an independent Verifier can obtain cryptographic proof as to the identity of the device in question, and evidence of the integrity of software loaded on that device when it started up, and then verify that what's there matches the intended configuration. For network equipment, a Verifier capability can be embedded in a Network Management Station (NMS), a posture collection server, or other network analytics tool (such as a software asset management solution, or a threat detection and mitigation tool, etc.). While informally referred to as attestation, this document focuses on a specific subset of attestation tasks, defined here as Remote Integrity Verification (RIV). RIV in this document takes a network-equipment- centric perspective that includes a set of protocols and procedures for determining whether a particular device was launched with authentic software, starting from Roots of Trust. While there are many ways to accomplish attestation, RIV sets out a specific set of protocols and tools that work in environments commonly found in network equipment. RIV does not cover other device characteristics that could be attested (e.g., geographic location, connectivity; see [I-D.richardson-rats-usecases]), although it does provide evidence of a secure infrastructure to increase the level of trust in other device characteristics attested by other means (e.g., by Entity Attestation Tokens [I-D.ietf-rats-eat]). In line with [I-D.ietf-rats-architecture] definitions, this document uses the term Endorser to refer to the role that signs identity and attestation certificates used by the Attester, while Reference Values are signed by a Reference Value Provider. Typically, the manufacturer of a network device would be accepted as both the Endorser and Reference Value Provider, although the choice is ultimately up to the Verifier Owner. Fedorkow, et al. Expires 23 September 2022 [Page 4] Internet-Draft Network Device RIV March 2022 1.3. Document Organization The remainder of this document is organized into several sections: * The remainder of this section covers goals and requirements, plus a top-level description of RIV. * The Solution Overview section outlines how Remote Integrity Verification works. * The Standards Components section links components of RIV to normative standards. * Privacy and Security shows how specific features of RIV contribute to the trustworthiness of the Attestation Result. * Supporting material is in an appendix at the end. 1.4. Goals Network operators benefit from a trustworthy attestation mechanism that provides assurance that their network comprises authentic equipment, and has loaded software free of known vulnerabilities and unauthorized tampering. In line with the overall goal of assuring integrity, attestation can be used to assist in asset management, vulnerability and compliance assessment, plus configuration management. The RIV attestation workflow outlined in this document is intended to meet the following high-level goals: * Provable Device Identity - This specification requires that an Attester (i.e., the attesting device) includes a cryptographic identifier unique to each device. Effectively this means that the device's TPM must be so provisioned during the manufacturing cycle. * Software Inventory - A key goal is to identify the software release(s) installed on the Attester, and to provide evidence that the software stored within hasn't been altered without authorization. * Verifiability - Verification of software and configuration of the device shows that the software that the administrator authorized for use was actually launched. Fedorkow, et al. Expires 23 September 2022 [Page 5] Internet-Draft Network Device RIV March 2022 In addition, RIV is designed to operate either in a centralized environment, such as with a central authority that manages and configures a number of network devices, or 'peer-to-peer', where network devices independently verify one another to establish a trust relationship. (See Section 3.3 below) 1.5. Description of Remote Integrity Verification (RIV) Attestation requires two interlocking mechanisms between the Attester network device and the Verifier: * Device Identity, the mechanism providing trusted identity, can reassure network managers that the specific devices they ordered from authorized manufacturers for attachment to their network are those that were installed, and that they continue to be present in their network. As part of the mechanism for Device Identity, cryptographic proof of the identity of the manufacturer is also provided. * Software Measurement is the mechanism that reports the state of mutable software components on the device, and can assure administrators that they have known, authentic software configured to run in their network. Using these two interlocking mechanisms, RIV is a component in a chain of procedures that can assure a network operator that the equipment in their network can be reliably identified, and that authentic software of a known version is installed on each device. Equipment in the network includes devices that make up the network itself, such as routers, switches and firewalls. Software used to boot a device can be identified by a chain of measurements, anchored at the start by a Root of Trust for Measurement (see Section 9.2), each measuring the next stage and recording the result in tamper-resistant storage, normally ending when the system software is fully loaded. A measurement signifies the identity, integrity and version of each software component registered with an Attester's TPM [TPM1.2], [TPM2.0], so that a subsequent verification stage can determine if the software installed is authentic, up-to-date, and free of tampering. RIV includes several major processes, split between the Attester and Verifier: 1. Generation of Evidence is the process whereby an Attester generates cryptographic proof (Evidence) of claims about device properties. In particular, the device identity and its software configuration are both of critical importance. Fedorkow, et al. Expires 23 September 2022 [Page 6] Internet-Draft Network Device RIV March 2022 2. Device Identification refers to the mechanism assuring the Relying Party (ultimately, a network administrator) of the identity of devices that make up their network, and that their manufacturers are known. 3. Conveyance of Evidence reliably transports the collected Evidence from Attester to a Verifier to allow a management station to perform a meaningful appraisal in Step 4. The transport is typically carried out via a management network. While not required for reliable attestation, an encrypted channel may be used to provide integrity, authenticity, or confidentiality once attestation is complete. It should be noted that critical attestation evidence from the TPM is signed by a key known only to TPM, and is not dependent on encyption carried out as part of a reliable transport. 4. Finally, Appraisal of Evidence occurs. This is the process of verifying the Evidence received by a Verifier from the Attester, and using an Appraisal Policy to develop an Attestation Result, used to inform decision-making. In practice, this means comparing the Attester's measurements reported as Evidence with the device configuration expected by the Verifier. Subsequently, the Appraisal Policy for Evidence might match Evidence found against Reference Values (aka Golden Measurements), which represent the intended configured state of the connected device. All implementations supporting this RIV specification require the support of the following three technologies: 1. Identity: Device identity in RIV is based on IEEE 802.1AR Device Identity (DevID) [IEEE-802-1AR], coupled with careful supply- chain management by the manufacturer. The Initial DevID (IDevID) certificate contains a statement by the manufacturer that establishes the identity of the device as it left the factory. Some applications with a more-complex post-manufacture supply chain (e.g., Value Added Resellers), or with different privacy concerns, may want to use alternative mechanisms for platform authentication (for example, TCG Platform Certificates [Platform-Certificates], or post-manufacture installation of Local Device ID (LDevID)). 2. Platform Attestation provides evidence of configuration of software elements present in the device. This form of attestation can be implemented with TPM Platform Configuration Registers (PCRs), Quote and Log mechanisms, which provide cryptographically authenticated evidence to report what software was started on the device through the boot cycle. Successful attestation requires an unbroken chain from a boot-time root of Fedorkow, et al. Expires 23 September 2022 [Page 7] Internet-Draft Network Device RIV March 2022 trust through all layers of software needed to bring the device to an operational state, in which each stage computes the hash of components of the next stage, then updates the attestation log and the TPM. The TPM can then report the hashes of all the measured hashes as signed evidence called a Quote (see Section 9.1 for an overview of TPM operation, or [TPM1.2] and [TPM2.0] for many more details). 3. Signed Reference Values (aka Reference Integrity Measurements) must be conveyed from the Reference Value Provider (the entity accepted as the software authority, often the manufacturer of the network device) to the Verifier. 1.6. Solution Requirements Remote Integrity Verification must address the "Lying Endpoint" problem, in which malicious software on an endpoint may subvert the intended function, and also prevent the endpoint from reporting its compromised status. (See Section 5 for further Security Considerations.) RIV attestation is designed to be simple to deploy at scale. RIV should work "out of the box" as far as possible, that is, with the fewest possible provisioning steps or configuration databases needed at the end-user's site. Network equipment is often required to "self-configure", to reliably reach out without manual intervention to prove its identity and operating posture, then download its own configuration, a process which precludes pre-installation configuration. See [RFC8572] for an example of Secure Zero Touch Provisioning. 1.7. Scope The need for assurance of software integrity, addressed by Remote Attestation, is a very general problem that could apply to most network-connected computing devices. However, this document includes several assumptions that limit the scope to network equipment (e.g., routers, switches and firewalls): * This solution is for use in non-privacy-preserving applications (for example, networking, Industrial IoT), avoiding the need for a Privacy Certificate Authority (also called an Attestation CA) for attestation keys [AK-Enrollment] or TCG Platform Certificates [Platform-Certificates]. * This document assumes network protocols that are common in network equipment such as YANG [RFC7950] and NETCONF [RFC6241], but not generally used in other applications. Fedorkow, et al. Expires 23 September 2022 [Page 8] Internet-Draft Network Device RIV March 2022 * The approach outlined in this document mandates the use of a TPM [TPM1.2], [TPM2.0], or a compatible cryptoprocessor. 1.7.1. Out of Scope * Run-Time Attestation: The Linux Integrity Measurement Architecture [IMA] attests each process launched after a device is started (and is in scope for RIV in general), but continuous run-time attestation of Linux or other multi-threaded operating system processes after the OS has started considerably expands the scope of the problem. Many researchers are working on that problem, but this document defers the problem of continuous, in-memory run-time attestation. * Multi-Vendor Embedded Systems: Additional coordination would be needed for devices that themselves comprise hardware and software from multiple vendors, integrated by the end user. Although out of scope for this document, these issues are accommodated in [I-D.ietf-rats-architecture]. * Processor Sleep Modes: Network equipment typically does not "sleep", so sleep and hibernate modes are not considered. Although out of scope for RIV in this document, Trusted Computing Group specifications do encompass sleep and hibernate states, which could be incorporated into remote attestation for network equipment in the future, given a compelling need. * Virtualization and Containerization: In a non-virtualized system, the host OS is responsible for measuring each User Space file or process throughout the operational lifetime of the system. For virtualized systems, the host OS must verify the hypervisor, but then the hypervisor must manage its own chain of trust through the virtual machine. Virtualization and containerization technologies are increasingly used in network equipment, but are not considered in this document. 2. Solution Overview 2.1. RIV Software Configuration Attestation using TPM RIV Attestation is a process which can be used to determine the identity of software running on a specifically-identified device. The Remote Attestation steps of Section 1.5 are broken into two phases, shown in Figure 1: * During system startup, or boot phase, each distinct software object is "measured" by the Attester. The object's identity, hash (i.e., cryptographic digest) and version information are recorded Fedorkow, et al. Expires 23 September 2022 [Page 9] Internet-Draft Network Device RIV March 2022 in a log. Hashes are also extended into the TPM (see Section 9.1 for more on 'extending hashes'), in a way that can be used to validate the log entries. The measurement process generally follows the layered chain-of-trust model used in Measured Boot, where each stage of the system measures the next one, and extends its measurement into the TPM, before launching it. See [I-D.ietf-rats-architecture], section "Layered Attestation Environments," for an architectural definition of this model. * Once the device is running and has operational network connectivity, verification can take place. A separate Verifier, running in its own trusted environment, will interrogate the network device to retrieve the logs and a copy of the digests collected by hashing each software object, signed by an attestation private key secured by, but never released by, the TPM. The YANG model described in [I-D.ietf-rats-yang-tpm-charra] facilitates this operation. The result is that the Verifier can verify the device's identity by checking the subject[RFC5280] and signature of the certificate containing the TPM's attestation public key, and can validate the software that was launched by verifying the correctness of the logs by comparing with the signed digests from the TPM, and comparing digests in the log with Reference Values. It should be noted that attestation and identity are inextricably linked; signed Evidence that a particular version of software was loaded is of little value without cryptographic proof of the identity of the Attester producing the Evidence. Fedorkow, et al. Expires 23 September 2022 [Page 10] Internet-Draft Network Device RIV March 2022 +-------------------------------------------------------+ | +---------+ +--------+ +--------+ +---------+ | | |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | | | +---------+ +--------+ +--------+ +---------+ | | | | | | | | | | | | +------------+-----------+-+ | | Boot Phase | | | V | | +--------+ | | | TPM | | | +--------+ | | Router | | +--------------------------------|----------------------+ | | Verification Phase | +-----------+ +--->| Verifier | +-----------+ Reset---------------flow-of-time-during-boot...---------> Figure 1: Layered RIV Attestation Model In the Boot phase, measurements are "extended", or hashed, into the TPM as processes start, with the result that the TPM ends up containing hashes of all the measured hashes. Later, once the system is operational, during the Verification phase, signed digests are retrieved from the TPM for off-box analysis. 2.1.1. What Does RIV Attest? TPM attestation is focused on Platform Configuration Registers (PCRs), but those registers are only vehicles for certifying accompanying Evidence, conveyed in log entries. It is the hashes in log entries that are extended into PCRs, where the final PCR values can be retrieved in the form of a structure called a Quote, signed by an Attestation key known only to the TPM. The use of multiple PCRs serves only to provide some independence between different classes of object, so that one class of objects can be updated without changing the extended hash for other classes. Although PCRs can be used for any purpose, this section outlines the objects within the scope of this document which may be extended into the TPM. In general, assignment of measurements to PCRs is a policy choice made by the device manufacturer, selected to independently attest three classes of object: Fedorkow, et al. Expires 23 September 2022 [Page 11] Internet-Draft Network Device RIV March 2022 * Code, (i.e., instructions) to be executed by a CPU. * Configuration - Many devices offer numerous options controlled by non-volatile configuration variables which can impact the device's security posture. These settings may have vendor defaults, but often can be changed by administrators, who may want to verify via attestation that the operational state of the settings match their intended state. * Credentials - Administrators may wish to verify via attestation that public keys and credentials outside the Root of Trust have not been subject to unauthorized tampering. (By definition, keys protecting the root of trust can't be verified independently.) The TCG PC Client Platform Firmware Profile Specification [PC-Client-BIOS-TPM-2.0] gives considerable detail on what is to be measured during the boot phase of platform startup using a UEFI BIOS (www.uefi.org), but the goal is simply to measure every bit of code executed in the process of starting the device, along with any configuration information related to security posture, leaving no gap for unmeasured code to remain undetected, potentially subverting the chain. For devices using a UEFI BIOS, [PC-Client-BIOS-TPM-2.0] and [PC-Client-EFI-TPM-1.2] give detailed normative requirements for PCR usage. For other platform architectures, where TCG normative requirements currently do not exist, the table in Figure 2 gives non- normative guidance for PCR assignment that generalizes the specific details of [PC-Client-BIOS-TPM-2.0]. By convention, most PCRs are assigned in pairs, which the even- numbered PCR used to measure executable code, and the odd-numbered PCR used to measure whatever data and configuration are associated with that code. It is important to note that each PCR may contain results from dozens (or even thousands) of individual measurements. Fedorkow, et al. Expires 23 September 2022 [Page 12] Internet-Draft Network Device RIV March 2022 +------------------------------------------------------------------+ | | Assigned PCR # | | Function | Code | Configuration| -------------------------------------------------------------------- | Firmware Static Root of Trust, (i.e., | 0 | 1 | | initial boot firmware and drivers) | | | -------------------------------------------------------------------- | Drivers and initialization for optional | 2 | 3 | | or add-in devices | | | -------------------------------------------------------------------- | OS Loader code and configuration, (i.e., | 4 | 5 | | the code launched by firmware) to load an | | | | operating system kernel. These PCRs record | | | | each boot attempt, and an identifier for | | | | where the loader was found | | | -------------------------------------------------------------------- | Vendor Specific Measurements during boot | 6 | 6 | -------------------------------------------------------------------- | Secure Boot Policy. This PCR records keys | | 7 | | and configuration used to validate the OS | | | | loader | | | -------------------------------------------------------------------- | Measurements made by the OS Loader | 8 | 9 | | (e.g. GRUB2 for Linux) | | | -------------------------------------------------------------------- | Measurements made by OS (e.g., Linux IMA) | 10 | 10 | +------------------------------------------------------------------+ Figure 2: Attested Objects 2.1.2. Notes on PCR Allocations It is important to recognize that PCR[0] is critical. The first measurement into PCR[0] is taken by the Root of Trust for Measurement, code which, by definition, cannot be verified by measurement. This measurement establishes the chain of trust for all subsequent measurements. If the PCR[0] measurement cannot be trusted, the validity of the entire chain is put into question. Distinctions Between PCR[0], PCR[2], PCR[4] and PCR[8] are summarized below: * PCR[0] typically represents a consistent view of rarely-changed Host Platform boot components, allowing Attestation policies to be defined using the less changeable components of the transitive trust chain. This PCR typically provides a consistent view of the platform regardless of user selected options. Fedorkow, et al. Expires 23 September 2022 [Page 13] Internet-Draft Network Device RIV March 2022 * PCR[2] is intended to represent a "user configurable" environment where the user has the ability to alter the components that are measured into PCR[2]. This is typically done by adding adapter cards, etc., into user-accessible PCI or other slots. In UEFI systems these devices may be configured by Option ROMs measured into PCR[2] and executed by the UEFI BIOS. * PCR[4] is intended to represent the software that manages the transition between the platform's Pre-Operating System start and the state of a system with the Operating System present. This PCR, along with PCR[5], identifies the initial operating system loader (e.g., GRUB for Linux). * PCR[8] is used by the OS loader (e.g. GRUB) to record measurements of the various components of the operating system. Although the TCG PC Client document specifies the use of the first eight PCRs very carefully to ensure interoperability among multiple UEFI BIOS vendors, it should be noted that embedded software vendors may have considerably more flexibility. Verifiers typically need to know which log entries are consequential and which are not (possibly controlled by local policies) but the Verifier may not need to know what each log entry means or why it was assigned to a particular PCR. Designers must recognize that some PCRs may cover log entries that a particular Verifier considers critical and other log entries that are not considered important, so differing PCR values may not on their own constitute a check for authenticity. For example, in a UEFI system, some administrators may consider booting an image from a removable drive, something recorded in a PCR, to be a security violation, while others might consider that operation an authorized recovery procedure. Designers may allocate particular events to specific PCRs in order to achieve a particular objective with local attestation, (e.g., allowing a procedure to execute, or releasing a particular decryption key, only if a given PCR is in a given state). It may also be important to designers to consider whether streaming notification of PCR updates is required (see [I-D.birkholz-rats-network-device-subscription]). Specific log entries can only be validated if the Verifier receives every log entry affecting the relevant PCR, so (for example) a designer might want to separate rare, high-value events such as configuration changes, from high-volume, routine measurements such as IMA [IMA] logs. Fedorkow, et al. Expires 23 September 2022 [Page 14] Internet-Draft Network Device RIV March 2022 2.2. RIV Keying RIV attestation relies on two credentials: * An identity key pair and matching certificate is required to certify the identity of the Attester itself. RIV specifies the use of an IEEE 802.1AR Device Identity (DevID) [IEEE-802-1AR], signed by the device manufacturer, containing the device serial number. This requirement goes slightly beyond 802.1AR; see Section 2.4 for notes. * An Attestation key pair and matching certificate is required to sign the Quote generated by the TPM to report evidence of software configuration. In a TPM application, both the Attestation private key and the DevID private key MUST be protected by the TPM. Depending on other TPM configuration procedures, the two keys are likely to be different; some of the considerations are outlined in TCG "TPM 2.0 Keys for Device Identity and Attestation" [Platform-DevID-TPM-2.0]. The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies further conventions for these keys: * When separate Identity and Attestation keys are used, the Attestation Key (AK) and its X.509 certificate should parallel the DevID, with the same unique device identification as the DevID certificate (that is, the same subject and subjectAltName (if present), even though the key pairs are different). This allows a quote from the device, signed by an AK, to be linked directly to the device that provided it, by examining the corresponding AK certificate. If the subject in the AK certificate doesn't match the corresponding DevID certificate, or they're signed by differing authorities the Verifier may signal the detection of an Asokan-style person-in-the-middle attack (see Section 5.2). * Network devices that are expected to use secure zero touch provisioning as specified in [RFC8572] MUST be shipped by the manufacturer with pre-provisioned keys (Initial DevID and Initial AK, called IDevID and IAK). IDevID and IAK certificates MUST both be signed by the Endorser (typically the device manufacturer). Inclusion of an IDevID and IAK by a vendor does not preclude a mechanism whereby an administrator can define Local Identity and Attestation Keys (LDevID and LAK) if desired. Fedorkow, et al. Expires 23 September 2022 [Page 15] Internet-Draft Network Device RIV March 2022 2.3. RIV Information Flow RIV workflow for network equipment is organized around a simple use case where a network operator wishes to verify the integrity of software installed in specific, fielded devices. A normative taxonomy of terms is given in [I-D.ietf-rats-architecture], but as a reminder, this use case implies several roles and objects: 1. The Attester, the device which the network operator wants to examine. 2. A Verifier (which might be a network management station) somewhere separate from the Device that will retrieve the signed evidence and measurement logs, and analyze them to pass judgment on the security posture of the device. 3. A Relying Party, which can act on Attestation Results. Interaction between the Relying Party and the Verifier is considered out of scope for RIV. 4. Signed Reference Integrity Manifests (RIMs), containing Reference Values, can either be created by the device manufacturer and shipped along with the device as part of its software image, or alternatively, could be obtained several other ways (direct to the Verifier from the manufacturer, from a third party, from the owner's observation of what's thought to be a "known good system", etc.). Retrieving RIMs from the device itself allows attestation to be done in systems that may not have access to the public internet, or by other devices that are not management stations per se (e.g., a peer device; see Section 3.1.3). If Reference Values are obtained from multiple sources, the Verifier may need to evaluate the relative level of trust to be placed in each source in case of a discrepancy. These components are illustrated in Figure 3. +----------------+ +-------------+ +---------+--------+ |Reference Value | | Attester | Step 1 | Verifier| | |Provider | | (Device |<-------| (Network| Relying| |(Device | | under |------->| Mngmt | Party | |Manufacturer | | attestation)| Step 2 | Station)| | |or other | | | | | | |authority) | | | | | | +----------------+ +-------------+ +---------+--------+ | /\ | Step 0 | ----------------------------------------------- Fedorkow, et al. Expires 23 September 2022 [Page 16] Internet-Draft Network Device RIV March 2022 Figure 3: RIV Reference Configuration for Network Equipment * In Step 0, The Reference Value Provider (the device manufacturer or other authority) makes one or more Reference Integrity Manifests (RIMs), corresponding to the software image expected to be found on the device, signed by the Reference Value Provider, available to the Verifier (see Section 3.1.3 for "in-band" and "out of band" ways to make this happen). * In Step 1, the Verifier (Network Management Station), on behalf of a Relying Party, requests Identity, Measurement Values, and possibly RIMs, from the Attester. * In Step 2, the Attester responds to the request by providing a DevID, quotes (measured values, signed by the Attester), and optionally RIMs. Use of the following standards components allows for interoperability: 1. TPM Keys MUST be configured according to [Platform-DevID-TPM-2.0], or [Platform-ID-TPM-1.2]. 2. For devices using UEFI and Linux, measurements of firmware and bootable modules MUST be taken according to TCG PC Client [PC-Client-EFI-TPM-1.2] or [PC-Client-BIOS-TPM-2.0], and Linux IMA [IMA]. 3. Device Identity MUST be managed as specified in IEEE 802.1AR Device Identity certificates [IEEE-802-1AR], with keys protected by TPMs. 4. Attestation logs from Linux-based systems MUST be formatted according to the Canonical Event Log format [Canonical-Event-Log]. UEFI-based systems MUST use the TCG UEFI BIOS event log [PC-Client-EFI-TPM-1.2] for TPM1.2 systems, and TCG PC Client Platform Firmware Profile [PC-Client-BIOS-TPM-2.0] for TPM2.0. 5. Quotes MUST be retrieved from the TPM according to TCG TAP Information Model [TAP] and the CHARRA YANG model [I-D.ietf-rats-yang-tpm-charra]. While the TAP IM gives a protocol-independent description of the data elements involved, it's important to note that quotes from the TPM are signed inside the TPM, and MUST be retrieved in a way that does not invalidate the signature, to preserve the trust model. The [I-D.ietf-rats-yang-tpm-charra] is used for this purpose. (See Section 5 Security Considerations). Fedorkow, et al. Expires 23 September 2022 [Page 17] Internet-Draft Network Device RIV March 2022 6. Reference Values MUST be encoded as defined in the TCG RIM document [RIM], typically using SWID [SWID], [NIST-IR-8060] or CoSWID tags [I-D.ietf-sacm-coswid]. 2.4. RIV Simplifying Assumptions This document makes the following simplifying assumptions to reduce complexity: * The product to be attested MUST be shipped by the equipment vendor with both an IEEE 802.1AR Device Identity and an Initial Attestation Key (IAK), with certificates in place. The IAK certificate must contain the same identity information as the DevID (specifically, the same subject and subjectAltName (if used), signed by the manufacturer). The IAK is a type of key that can be used to sign a TPM Quote, but not other objects (i.e., it's marked as a TCG "Restricted" key; this convention is described in "TPM 2.0 Keys for Device Identity and Attestation" [Platform-DevID-TPM-2.0]). For network equipment, which is generally non-privacy-sensitive, shipping a device with both an IDevID and an IAK already provisioned substantially simplifies initial startup. * IEEE 802.1AR does not require a product serial number as part of the subject, but RIV-compliant devices MUST include their serial numbers in the DevID/IAK certificates to simplify tracking logistics for network equipment users. All other optional 802.1AR fields remain optional in RIV. It should be noted that 802.1AR use of X.509 certificate fields is not identical to those descsribed in [RFC6125] for representation of application service identity. * The product MUST be equipped with a Root of Trust for Measurement (RTM), Root of Trust for Storage and Root of Trust for Reporting (as defined in [SP800-155]) which together are capable of conforming to TCG Trusted Attestation Protocol Information Model [TAP]. * The authorized software supplier MUST make available Reference Values in the form of signed SWID or CoSWID tags. 2.4.1. Reference Integrity Manifests (RIMs) [I-D.ietf-rats-yang-tpm-charra] focuses on collecting and transmitting evidence in the form of PCR measurements and attestation logs. But the critical part of the process is enabling the Verifier to decide whether the measurements are "the right ones" or not. Fedorkow, et al. Expires 23 September 2022 [Page 18] Internet-Draft Network Device RIV March 2022 While it must be up to network administrators to decide what they want on their networks, the software supplier should supply the Reference Values, in signed Reference Integrity Manifests, that may be used by a Verifier to determine if evidence shows known good, known bad or unknown software configurations. In general, there are two kinds of reference measurements: 1. Measurements of early system startup (e.g., BIOS, boot loader, OS kernel) are essentially single-threaded, and executed exactly once, in a known sequence, before any results could be reported. In this case, while the method for computing the hash and extending relevant PCRs may be complicated, the net result is that the software (more likely, firmware) vendor will have one known good PCR value that "should" be present in the relevant PCRs after the box has booted. In this case, the signed reference measurement could simply list the expected hashes for the given version. However, a RIM that contains the intermediate hashes can be useful in debugging cases where the expected final hash is not the one reported. 2. Measurements taken later in operation of the system, once an OS has started (for example, Linux IMA [IMA]), may be more complex, with unpredictable "final" PCR values. In this case, the Verifier must have enough information to reconstruct the expected PCR values from logs and signed reference measurements from a trusted authority. In both cases, the expected values can be expressed as signed SWID or CoSWID tags, but the SWID structure in the second case is somewhat more complex, as reconstruction of the extended hash in a PCR may involve thousands of files and other objects. TCG has published an information model defining elements of Reference Integrity Manifests under the title TCG Reference Integrity Manifest Information Model [RIM]. This information model outlines how SWID tags should be structured to allow attestation, and defines "bundles" of SWID tags that may be needed to describe a complete software release. The RIM contains metadata relating to the software release it belongs to, plus hashes for each individual file or other object that could be attested. Many network equipment vendors use a UEFI BIOS to launch their network operating system. These vendors may want to also use the TCG PC Client Reference Integrity Measurement specification [PC-Client-RIM], which focuses specifically on a SWID-compatible format suitable for expressing measurement values expected from a UEFI BIOS. Fedorkow, et al. Expires 23 September 2022 [Page 19] Internet-Draft Network Device RIV March 2022 2.4.2. Attestation Logs Quotes from a TPM can provide evidence of the state of a device up to the time the evidence was recorded, but to make sense of the quote in cases where several events are extended into one PCR an event log that identifies which software modules contributed which values to the quote during startup must also be provided. When required, the log MUST contain enough information to demonstrate its integrity by allowing exact reconstruction of the digest conveyed in the signed quote (that is, calculating the hash of all the hashes in the log should produce the same values as contained in the PCRs; if they don't match, the log may have been tampered with. See Section 9.1). There are multiple event log formats which may be supported as viable formats of Evidence between the Attester and Verifier, but to simplify interoperability, RIV focuses on just three: * TCG UEFI BIOS event log for TPM 2.0 (TCG PC Client Platform Firmware Profile) [PC-Client-BIOS-TPM-2.0] * TCG UEFI BIOS event log for TPM 1.2 (TCG EFI Platform Specification for TPM Family 1.1 or 1.2, Section 7) [PC-Client-EFI-TPM-1.2] * TCG Canonical Event Log [Canonical-Event-Log] 3. Standards Components 3.1. Prerequisites for RIV The Reference Interaction Model for Challenge-Response-based Remote Attestation ([I-D.birkholz-rats-reference-interaction-model]) is based on the standard roles defined in [I-D.ietf-rats-architecture]. However, additional prerequisites have been established to allow for interoperable RIV use case implementations. These prerequisites are intended to provide sufficient context information so that the Verifier can acquire and evaluate measurements collected by the Attester. 3.1.1. Unique Device Identity A secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID certificate [IEEE-802-1AR] must be provisioned in the Attester's TPMs. Fedorkow, et al. Expires 23 September 2022 [Page 20] Internet-Draft Network Device RIV March 2022 3.1.2. Keys The Attestation Key (AK) and certificate must also be provisioned on the Attester according to [Platform-DevID-TPM-2.0], or [Platform-ID-TPM-1.2]. It MUST be possible for the Verifier to determine that the Attester's Attestation keys are resident in the same TPM as its DevID keys (see Section 2.2 and Section 5 Security Considerations). 3.1.3. Appraisal Policy for Evidence As noted in Section 2.3, the Verifier may obtain Reference Values from several sources. In addition, administrators may make authorized, site-specific changes (e.g. keys in key databases) that could impact attestation results. As such, there could be conflicts, omissions or ambiguities between some Reference Values and collected Evidence. The Verifier MUST have an Appraisal Policy for Evidence to evaluate the significance of any discrepancies between different reference sources, or between reference values and evidence from logs and quotes. While there must be an Appraisal Policy, this document does not specify the format or mechanism to convey the intended policy, nor does RIV specify mechanisms by which the results of applying the policy are communicated to the Relying Party. 3.2. Reference Model for Challenge-Response Once the prerequisites for RIV are met, a Verifier is able to acquire Evidence from an Attester. The following diagram illustrates a RIV information flow between a Verifier and an Attester, derived from Section 7.1 of [I-D.birkholz-rats-reference-interaction-model]. In this diagram, each event with its input and output parameters is shown as "Event(input-params)=>(outputs)". Event times shown correspond to the time types described within Appendix A of [I-D.ietf-rats-architecture]: Fedorkow, et al. Expires 23 September 2022 [Page 21] Internet-Draft Network Device RIV March 2022 .----------. .-----------------------. | Attester | | Relying Party/Verifier | '----------' '------------------------' time(VG) | generateClaims(attestingEnvironment) | | => claims, eventLogs | | | | time(NS) | <-- requestAttestation(handle, authSecIDs, claimSelection) | | | time(EG) | collectClaims(claims, claimSelection) | | => collectedClaims | | | generateEvidence(handle, authSecIDs, collectedClaims) | | => evidence | | time(RG,RA) | evidence, eventLogs -------------------------------------> | | | | appraiseEvidence(evidence, eventLogs, refValues) | attestationResult <= | | | ~ ~ | time(RX) Figure 4: IETF Attestation Information Flow * Step 1 (time(VG)): One or more Attesting Network Device PCRs are extended with measurements. RIV provides no direct link between the time at which the event takes place and the time that it's attested, although streaming attestation as in [I-D.birkholz-rats-network-device-subscription] could. * Step 2 (time(NS)): The Verifier generates a unique random nonce ("number used once"), and makes a request for one or more PCRs from an Attester. For interoperability, this must be accomplished as specified in the YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs [I-D.ietf-rats-yang-tpm-charra]. TPM1.2 and TPM2.0 both allow nonces as large as the operative digest size (i.e., 20 or 32 bytes; see [TPM1.2] Part 2, Section 5.5 and [TPM2.0] Part 2, Section 10.4.4). * Step 3 (time(EG)): On the Attester, measured values are retrieved from the Attester's TPM. This requested PCR evidence, along with the Verifier's nonce, called a Quote, is signed by the Attestation Key (AK) associated with the DevID. Quotes are retrieved according to CHARRA YANG model [I-D.ietf-rats-yang-tpm-charra]. Fedorkow, et al. Expires 23 September 2022 [Page 22] Internet-Draft Network Device RIV March 2022 At the same time, the Attester collects log evidence showing the values have been extended into that PCR. Section 9.1 gives more detail on how this works, including references to the structure and contents of quotes in TPM documents. * Step 4: Collected Evidence is passed from the Attester to the Verifier * Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes action as needed. As the interaction between Relying Party and Verifier is out of scope for RIV, this can be described as one step. - If the signature covering TPM Evidence is not correct, the device SHOULD NOT be trusted. - If the nonce in the response doesn't match the Verifier's nonce, the response may be a replay, and device SHOULD NOT be trusted. - If the signed PCR values do not match the set of log entries which have extended a particular PCR, the device SHOULD NOT be trusted. - If the log entries that the Verifier considers important do not match known good values, the device SHOULD NOT be trusted. We note that the process of collecting and analyzing the log can be omitted if the value in the relevant PCR is already a known- good value. - If the set of log entries are not seen as acceptable by the Appraisal Policy for Evidence, the device SHOULD NOT be trusted. - If time(RG)-time(NS) is greater than the Appraisal Policy for Evidence's threshold for assessing freshness, the Evidence is considered stale and SHOULD NOT be trusted. 3.2.1. Transport and Encoding Network Management systems may retrieve signed PCR based Evidence using NETCONF or RESTCONF with [I-D.ietf-rats-yang-tpm-charra]. In either case, implementatations must do so using a secure tunnel. Log Evidence MUST be retrieved via log interfaces specified in [I-D.ietf-rats-yang-tpm-charra]. Fedorkow, et al. Expires 23 September 2022 [Page 23] Internet-Draft Network Device RIV March 2022 3.3. Centralized vs Peer-to-Peer Figure 4 above assumes that the Verifier is trusted, while the Attester is not. In a Peer-to-Peer application such as two routers negotiating a trust relationship, the two peers can each ask the other to prove software integrity. In this application, the information flow is the same, but each side plays a role both as an Attester and a Verifier. Each device issues a challenge, and each device responds to the other's challenge, as shown in Figure 5. Peer-to-peer challenges, particularly if used to establish a trust relationship between routers, require devices to carry their own signed reference measurements (RIMs). Devices may also have to carry Appraisal Policy for Evidence for each possible peer device so that each device has everything needed for remote attestation, without having to resort to a central authority. +---------------+ +---------------+ | RefVal | | RefVal | | Provider A | | Provider B | | Firmware | | Firmware | | Configuration | | Configuration | | Authority | | Authority | | | | | +---------------+ +---------------+ | | | |Step 0B | +------------+ +------------+ | | | | Step 1 | | | \ | | Attester |<------>| Verifier | | | | | |<------>| | | | Router B +------>| | Step 2 | | | |- Challenges Step 0A| | | | | | Router A | |------->| | | | |- Router A -| Step 3 |- Router B -| | / | | | | | | | | | | | | Step 1 | | | \ | Verifier |<------>| Attester |<-+ | Router A | |<------>| | |- Challenges | | Step 2 | | | Router B | | | | | | |<-------| | | +------------+ Step 3 +------------+ / Figure 5: Peer-to-Peer Attestation Information Flow Fedorkow, et al. Expires 23 September 2022 [Page 24] Internet-Draft Network Device RIV March 2022 In this application, each device may need to be equipped with signed RIMs to act as an Attester, and also an Appraisal Policy for Evidence and a selection of trusted X.509 root certificates, to allow the device to act as a Verifier. An existing link layer protocol such as 802.1X [IEEE-802.1X] or 802.1AE [IEEE-802.1AE], with Evidence being enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable methods for such an exchange. Details of peer-to-peer operation are out of scope for this document. 4. Privacy Considerations Network equipment, such as routers, switches and firewalls, has a key role to play in guarding the privacy of individuals using the network. Network equipment generally adheres to several rules to protect privacy: * Packets passing through the device must not be sent to unauthorized destinations. For example: - Routers often act as Policy Enforcement Points, where individual subscribers may be checked for authorization to access a network. Subscriber login information must not be released to unauthorized parties. - Network equipment is often called upon to block access to protected resources from unauthorized users. * Routing information, such as the identity of a router's peers, must not be leaked to unauthorized neighbors. * If configured, encryption and decryption of traffic must be carried out reliably, while protecting keys and credentials. Functions that protect privacy are implemented as part of each layer of hardware and software that makes up the networking device. In light of these requirements for protecting the privacy of users of the network, the network equipment must identify itself, and its boot configuration and measured device state (for example, PCR values), to the equipment's administrator, so there's no uncertainty as to what function each device and configuration is configured to carry out. Attestation is a component that allows the administrator to ensure that the network provides individual and peer privacy guarantees, even though the device itself may not have a right to keep its identity secret. See [NetEq] for more context on privacy in networking devices. Fedorkow, et al. Expires 23 September 2022 [Page 25] Internet-Draft Network Device RIV March 2022 While attestation information from network devices is not likely to contain privacy-sensitive content regarding network users, administrators may want to keep attestation records confidential to avoid disclosing versions of software loaded on the device, information which could facilitate attacks against known vulnerabilities. 5. Security Considerations Specifications such as [RFC8446] (TLS) and [RFC7950] (YANG) contain considerable advice on keeping network-connected systems secure. This section outlines specific risks and mitigations related to attestation. Attestation Evidence obtained by the RIV procedure is subject to a number of attacks: * Keys may be compromised. * A counterfeit device may attempt to impersonate (spoof) a known authentic device. * Person-in-the-middle attacks may be used by a compromised device to attempt to deliver responses that originate in an authentic device. * Replay attacks may be attempted by a compromised device. 5.1. Keys Used in RIV Trustworthiness of RIV attestation depends strongly on the validity of keys used for identity and attestation reports. RIV takes full advantage of TPM capabilities to ensure that evidence can be trusted. Two sets of key-pairs are relevant to RIV attestation: * A DevID key-pair is used to certify the identity of the device in which the TPM is installed. * An Attestation Key-pair (AK) key is used to certify attestation Evidence (called 'quotes' in TCG documents), used to provide evidence for integrity of the software on the device TPM practices usually require that these keys be different, as a way of ensuring that a general-purpose signing key cannot be used to spoof an attestation quote. Fedorkow, et al. Expires 23 September 2022 [Page 26] Internet-Draft Network Device RIV March 2022 In each case, the private half of the key is known only to the TPM, and cannot be retrieved externally, even by a trusted party. To ensure that's the case, specification-compliant private/public key- pairs are generated inside the TPM, where they are never exposed, and cannot be extracted (See [Platform-DevID-TPM-2.0]). Keeping keys safe is a critical enabler of trustworthiness, but it's just part of attestation security; knowing which keys are bound to the device in question is just as important in an environment where private keys are never exposed. While there are many ways to manage keys in a TPM (see [Platform-DevID-TPM-2.0]), RIV includes support for "zero touch" provisioning (also known as zero-touch onboarding) of fielded devices (e.g., Secure ZTP, [RFC8572]), where keys which have predictable trust properties are provisioned by the device vendor. Device identity in RIV is based on IEEE 802.1AR Device Identity (DevID). This specification provides several elements: * A DevID requires a unique key pair for each device, accompanied by an X.509 certificate, * The private portion of the DevID key is to be stored in the device, in a manner that provides confidentiality (Section 6.2.5 [IEEE-802-1AR]) The X.509 certificate contains several components: * The public part of the unique DevID key assigned to that device allows a challenge of identity. * An identifying string that's unique to the manufacturer of the device. This is normally the serial number of the unit, which might also be printed on a label on the device. * The certificate must be signed by a key traceable to the manufacturer's root key. With these elements, the device's manufacturer and serial number can be identified by analyzing the DevID certificate plus the chain of intermediate certificates leading back to the manufacturer's root certificate. As is conventional in TLS or SSH connections, a random nonce must be signed by the device in response to a challenge, proving possession of its DevID private key. Fedorkow, et al. Expires 23 September 2022 [Page 27] Internet-Draft Network Device RIV March 2022 RIV uses the DevID to validate a TLS or SSH connection to the device as the attestation session begins. Security of this process derives from TLS or SSH security, with the DevID, containing a device serial number, providing proof that the session terminates on the intended device. See [RFC8446], [RFC4253]. Evidence of software integrity is delivered in the form of a quote signed by the TPM itself, accompanied by an IAK certificate containing the same identity information as the DevID. Because the contents of the quote are signed inside the TPM, any external modification (including reformatting to a different data format) after measurements have been taken will be detected as tampering. An unbroken chain of trust is essential to ensuring that blocks of code that are taking measurements have been verified before execution (see Figure 1). Requiring measurements of the operating software to be signed by a key known only to the TPM also removes the need to trust the device's operating software (beyond the first measurement in the RTM; see below); any changes to the quote, generated and signed by the TPM itself, made by malicious device software, or in the path back to the Verifier, will invalidate the signature on the quote. A critical feature of the YANG model described in [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data structures in their TCG-defined format, without requiring any changes to the structures as they were signed and delivered by the TPM. While alternate methods of conveying TPM quotes could compress out redundant information, or add another layer of signing using external keys, the implementation MUST preserve the TPM signing, so that tampering anywhere in the path between the TPM itself and the Verifier can be detected. 5.2. Prevention of Spoofing and Person-in-the-Middle Attacks Prevention of spoofing attacks against attestation systems is also important. There are several cases to consider: * The entire device could be spoofed. If the Verifier goes to appraise a specific Attester, it might be redirected to a different Attester. * A compromised device could have a valid DevID, but substitute a quote from a knonwn-good device, instead of returning its own, as described in [RFC6813]. * A device with a compromised OS could return a fabricated quote providing spoofed attestation Evidence. Fedorkow, et al. Expires 23 September 2022 [Page 28] Internet-Draft Network Device RIV March 2022 Use of the 802.1AR Device Identity (DevID) in the TPM provides protection against the case of a spoofed device, by ensuring that the Verifier's TLS or SSH session is in fact terminating on the right device. Protection against spoofed quotes from a device with valid identity is a bit more complex. An identity key must be available to sign any kind of nonce or hash offered by the Verifier, and consequently, could be used to sign a fabricated quote. To block a spoofed Attestation Result, the quote generated inside the TPM must be signed by a key that's different from the DevID, called an Attestation Key (AK). Given separate Attestation and DevID keys, the binding between the AK and the same device must also be proven to prevent a person-in-the- middle attack (e.g., the 'Asokan Attack' [RFC6813]). This is accomplished in RIV through use of an AK certificate with the same elements as the DevID (same manufacturer's serial number, signed by the same manufacturer's key), but containing the device's unique AK public key instead of the DevID public key. This binding between DevID and AK certificates is critical to reliable attestation. The TCG document TPM 2.0 Keys for Device Identity and Attestation [Platform-DevID-TPM-2.0] specifies OIDs for Attestation Certificates that allow the CA to mark a key as specifically known to be an Attestation key. These two key-pairs and certificates are used together: * The DevID is used to validate a TLS connection terminating on the device with a known serial number. * The AK is used to sign attestation quotes, providing proof that the attestation evidence comes from the same device. 5.3. Replay Attacks Replay attacks, where results of a previous attestation are submitted in response to subsequent requests, are usually prevented by inclusion of a random nonce in the request to the TPM for a quote. Each request from the Verifier includes a new random number (a nonce). The resulting quote signed by the TPM contains the same nonce, allowing the Verifier to determine freshness, (i.e., that the resulting quote was generated in response to the Verifier's specific request). Time-Based Uni-directional Attestation [I-D.birkholz-rats-tuda] provides an alternate mechanism to verify freshness without requiring a request/response cycle. Fedorkow, et al. Expires 23 September 2022 [Page 29] Internet-Draft Network Device RIV March 2022 5.4. Owner-Signed Keys Although device manufacturers must pre-provision devices with easily verified DevID and AK certificates if zero-touch provisioning such as described in [RFC8572] is to be supported, use of those credentials is not mandatory. IEEE 802.1AR incorporates the idea of an Initial Device ID (IDevID), provisioned by the manufacturer, and a Local Device ID (LDevID) provisioned by the owner of the device. RIV and [Platform-DevID-TPM-2.0] extends that concept by defining an Initial Attestation Key (IAK) and Local Attestation Key (LAK) with the same properties. Device owners can use any method to provision the Local credentials. * TCG document [Platform-DevID-TPM-2.0] shows how the initial Attestation keys can be used to certify LDevID and LAK keys. Use of the LDevID and LAK allows the device owner to use a uniform identity structure across device types from multiple manufacturers (in the same way that an "Asset Tag" is used by many enterprises to identify devices they own). TCG document [Provisioning-TPM-2.0] also contains guidance on provisioning Local identity keys in TPM 2.0. Owners should follow the same practice of binding Local DevID and Local AK as the manufacturer would for IDevID and IAK. See Section Section 2.2. * Device owners, however, can use any other mechanism they want to assure themselves that local identity certificates are inserted into the intended device, including physical inspection and programming in a secure location, if they prefer to avoid placing trust in the manufacturer-provided keys. Clearly, local keys can't be used for secure Zero Touch provisioning; installation of the local keys can only be done by some process that runs before the device is installed for network operation, or using procedures such as those outlined in Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]. On the other end of the device life cycle, provision should be made to wipe local keys when a device is decommissioned, to indicate that the device is no longer owned by the enterprise. The manufacturer's Initial identity keys must be preserved, as they contain no information that's not already printed on the device's serial number plate. 5.5. Other Factors for Trustworthy Operation In addition to trustworthy provisioning of keys, RIV depends on a number of other factors for trustworthy operation. Fedorkow, et al. Expires 23 September 2022 [Page 30] Internet-Draft Network Device RIV March 2022 * Secure identity depends on mechanisms to prevent per-device secret keys from being compromised. The TPM provides this capability as a Root of Trust for Storage. * Attestation depends on an unbroken chain of measurements, starting from the very first measurement. See Section 9.1 for background on TPM practices. * That first measurement is made by code called the Root of Trust for Measurement, typically done by trusted firmware stored in boot flash. Mechanisms for maintaining the trustworthiness of the RTM are out of scope for RIV, but could include immutable firmware, signed updates, or a vendor-specific hardware verification technique. See Section 9.2 for background on roots of trust. * The device owner SHOULD provide some level of physical defense for the device. If a TPM that has already been programmed with an authentic DevID is stolen and inserted into a counterfeit device, attestation of that counterfeit device may become indistinguishable from an authentic device. RIV also depends on reliable Reference Values, as expressed by the RIM [RIM]. The definition of trust procedures for RIMs is out of scope for RIV, and the device owner is free to use any policy to validate a set of reference measurements. It should also be noted that, while RIV can provide a reliable indication that a known software package is in use by the device, and that the package has not been tampered, it is the device owner's responsibility to determine that it's the correct package for the application. RIMs may be conveyed out-of-band or in-band, as part of the attestation process (see Section 3.1.3). But for network devices, where software is usually shipped as a self-contained package, RIMs signed by the manufacturer and delivered in-band may be more convenient for the device owner. The validity of RIV attestation results is also influenced by procedures used to create Reference Values: * While the RIM itself is signed, supply-chains SHOULD be carefully scrutinized to ensure that the values are not subject to unexpected manipulation prior to signing. Insider-attacks against code bases and build chains are particularly hard to spot. * Designers SHOULD guard against hash collision attacks. Reference Integrity Manifests often give hashes for large objects of indeterminate size; if one of the measured objects can be replaced with an implant engineered to produce the same hash, RIV will be Fedorkow, et al. Expires 23 September 2022 [Page 31] Internet-Draft Network Device RIV March 2022 unable to detect the substitution. TPM1.2 uses SHA-1 hashes only, which have been shown to be susceptible to collision attack. TPM2.0 will produce quotes with SHA-256, which so far has resisted such attacks. Consequently, RIV implementations SHOULD use TPM2.0. 6. IANA Considerations This document has no IANA actions. 7. Conclusion TCG technologies can play an important part in the implementation of Remote Integrity Verification. Standards for many of the components needed for implementation of RIV already exist: * Platform identity can be based on IEEE 802.1AR Device Identity, coupled with careful supply-chain management by the manufacturer. * Complex supply chains can be certified using TCG Platform Certificates [Platform-Certificates]. * The TCG TAP mechanism coupled with [I-D.ietf-rats-yang-tpm-charra] can be used to retrieve attestation evidence. * Reference Values must be conveyed from the software authority (e.g., the manufacturer) in Reference Integrity Manifests, to the system in which verification will take place. IETF and TCG SWID and CoSWID work ([I-D.ietf-sacm-coswid], [RIM]) forms the basis for this function. 8. Acknowledgements The authors wish to thank numerous reviewers for generous assistance, including William Bellingrath, Mark Baushke, Ned Smith, Henk Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas Hardjono, Bill Sulzen, Willard (Monty) Wiseman, Kathleen Moriarty, Nancy Cam-Winget and Shwetha Bhandari 9. Appendix 9.1. Using a TPM for Attestation The Trusted Platform Module and surrounding ecosystem provide three interlocking capabilities to enable secure collection of evidence from a remote device, Platform Configuration Registers (PCRs), a Quote mechanism, and a standardized Event Log. Fedorkow, et al. Expires 23 September 2022 [Page 32] Internet-Draft Network Device RIV March 2022 Each TPM has at least eight and at most twenty-four PCRs (depending on the profile and vendor choices), each one large enough to hold one hash value (SHA-1, SHA-256, and other hash algorithms can be used, depending on TPM version). PCRs can't be accessed directly from outside the chip, but the TPM interface provides a way to "extend" a new security measurement hash into any PCR, a process by which the existing value in the PCR is hashed with the new security measurement hash, and the result placed back into the same PCR. The result is a composite fingerprint comprising the hash of all the security measurements extended into each PCR since the system was reset. Every time a PCR is extended, an entry should be added to the corresponding Event Log. Logs contain the security measurement hash plus informative fields offering hints as to which event generated the security measurement. The Event Log itself is protected against accidental manipulation, but it is implicitly tamper-evident - any verification process can read the security measurement hash from the log events, compute the composite value and compare that to what ended up in the PCR. If there's no discrepancy, the logs do provide an accurate view of what was placed into the PCR. Note that the composite hash-of-hashes recorded in PCRs is order- dependent, resulting in different PCR values for different ordering of the same set of events (e.g. Event A followed by Event B yields a different PCR value than B followed by A). For single-threaded code, where both the events and their order are fixed, a Verifier may validate a single PCR value, and use the log only to diagnose a mismatch from Reference Values. However, operating system code is usually non-deterministic, meaning that there may never be a single "known good" PCR value. In this case, the Verifier may have to verify that the log is correct, and then analyze each item in the log to determine if it represents an authorized event. In a conventional TPM Attestation environment, the first measurement must be made and extended into the TPM by trusted device code (called the Root of Trust for Measurement, RTM). That first measurement should cover the segment of code that is run immediately after the RTM, which then measures the next code segment before running it, and so on, forming an unbroken chain of trust. See [TCGRoT] for more on Mutable vs Immutable roots of trust. The TPM provides another mechanism called a Quote that can read the current value of the PCRs and package them, along with the Verifier's nonce, into a TPM-specific data structure signed by an Attestation private key, known only to the TPM. Fedorkow, et al. Expires 23 September 2022 [Page 33] Internet-Draft Network Device RIV March 2022 As noted above in Section 5 Security Considerations, it's important to note that the Quote data structure is signed inside the TPM. The trust model is preserved by retrieving the Quote in a way that does not invalidate the signature, as specified in [I-D.ietf-rats-yang-tpm-charra]. The structure of the command and response for a quote, including its signature, as generated by the TPM, can be seen in [TPM1.2] Part 3, Section 16.5, and [TPM2.0] Section 18.4.2. The Verifier uses the Quote and Log together. The Quote contains the composite hash of the complete sequence of security measurement hashes, signed by the TPM's private Attestation Key. The Log contains a record of each measurement extended into the TPM's PCRs. By computing the composite hash of all the measurements, the Verifier can verify the integrity of the Event Log, even though the Event Log itself is not signed. Each hash in the validated Event Log can then be compared to corresponding expected values in the set of Reference Values to validate overall system integrity. A summary of information exchanged in obtaining quotes from TPM1.2 and TPM2.0 can be found in [TAP], Section 4. Detailed information about PCRs and Quote data structures can be found in [TPM1.2], [TPM2.0]. Recommended log formats include [PC-Client-BIOS-TPM-2.0], and [Canonical-Event-Log]. 9.2. Root of Trust for Measurement The measurements needed for attestation require that the device being attested is equipped with a Root of Trust for Measurement, that is, some trustworthy mechanism that can compute the first measurement in the chain of trust required to attest that each stage of system startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs) to record the results, and a Root of Trust for Reporting to report the results. While there are many complex aspects of Roots of Trust ( [TCGRoT], [SP800-155], [SP800-193]), two aspects that are important in the case of attestation are: * The first measurement computed by the Root of Trust for Measurement, and stored in the TPM's Root of Trust for Storage, must be assumed to be correct. * There must not be a way to reset the Root of Trust for Storage without re-entering the Root of Trust for Measurement code. Fedorkow, et al. Expires 23 September 2022 [Page 34] Internet-Draft Network Device RIV March 2022 The first measurement must be computed by code that is implicitly trusted; if that first measurement can be subverted, none of the remaining measurements can be trusted. (See [SP800-155]) It's important to note that the trustworthiness of the RTM code cannot be assured by the TPM or TPM supplier - code or procedures external to the TPM must guarantee the security of the RTM. 9.3. Layering Model for Network Equipment Attester and Verifier Retrieval of identity and attestation state uses one protocol stack, while retrieval of Reference Values uses a different set of protocols. Figure 5 shows the components involved. Fedorkow, et al. Expires 23 September 2022 [Page 35] Internet-Draft Network Device RIV March 2022 +-----------------------+ +-------------------------+ | | | | | Attester |<-------------| Verifier | | (Device) |------------->| (Management Station) | | | | | | +-----------------------+ | +-------------------------+ | -------------------- -------------------- | | ------------------------------- --------------------------------- |Reference Values | | Attestation | ------------------------------- --------------------------------- ******************************************************************** * IETF Attestation Reference Interaction Diagram * ******************************************************************** ......................... ......................... . Reference Integrity . . TAP (PTS2.0) Info . . Manifest . . Model and Canonical . . . . Log Format . ......................... ......................... ************************* ************************* * YANG SWID Module * * YANG Attestation * * I-D.ietf-sacm-coswid * * Module * * * * I-D.ietf-rats- * * * * yang-tpm-charra * ************************* ************************* ************************* ************************* * XML, JSON, CBOR (etc) * * XML, JSON, CBOR (etc) * ************************* ************************* ************************* ************************* * RESTCONF/NETCONF * * RESTCONF/NETCONF * ************************* ************************* ************************* ************************* * TLS, SSH * * TLS, SSH * ************************* ************************* Figure 6: RIV Protocol Stacks IETF documents are captured in boxes surrounded by asterisks. TCG documents are shown in boxes surrounded by dots. Fedorkow, et al. Expires 23 September 2022 [Page 36] Internet-Draft Network Device RIV March 2022 9.4. Implementation Notes Figure 7 summarizes many of the actions needed to complete an Attestation system, with links to relevant documents. While documents are controlled by several standards organizations, the implied actions required for implementation are all the responsibility of the manufacturer of the device, unless otherwise noted. As noted, SWID tags can be generated many ways, but one possible tool is [SWID-Gen] +------------------------------------------------------------------+ | Component | Controlling | | | Specification | -------------------------------------------------------------------- | Make a Secure execution environment | TCG RoT | | o Attestation depends on a secure root of | UEFI.org | | trust for measurement outside the TPM, as | | | well as roots for storage and reporting | | | inside the TPM. | | | o Refer to TCG Root of Trust for Measurement.| | | o NIST SP 800-193 also provides guidelines | | | on Roots of Trust | | -------------------------------------------------------------------- | Provision the TPM as described in |[Platform-DevID-TPM-2.0]| | TCG documents. | TCG Platform | | | Certificate | -------------------------------------------------------------------- | Put a DevID or Platform Cert in the TPM | TCG TPM DevID | | o Install an Initial Attestation Key at the | TCG Platform | | same time so that Attestation can work out | Certificate | | of the box |----------------- | o Equipment suppliers and owners may want to | IEEE 802.1AR | | implement Local Device ID as well as | | | Initial Device ID | | -------------------------------------------------------------------- | Connect the TPM to the TLS stack | Vendor TLS | | o Use the DevID in the TPM to authenticate | stack (This | | TAP connections, identifying the device | action is | | | configuring TLS| | | to use the DevID | | | as its client | | | certificate) | -------------------------------------------------------------------- | Make CoSWID tags for BIOS/Loader/Kernel objects | IETF CoSWID | | o Add reference measurements into SWID tags | ISO/IEC 19770-2| | o Manufacturer should sign the SWID tags | NIST IR 8060 | Fedorkow, et al. Expires 23 September 2022 [Page 37] Internet-Draft Network Device RIV March 2022 | o The TCG RIM-IM identifies further | | | procedures to create signed RIM | | | documents that provide the necessary | | | reference information | | -------------------------------------------------------------------- | Package the SWID tags with a vendor software | Retrieve tags | | release | with | | o A tag-generator plugin such | I-D.ietf-sacm-coswid| | as [SWID-Gen] can be used |----------------| | | TCG PC Client | | | RIM | -------------------------------------------------------------------- | Use PC Client measurement definitions | TCG PC Client | | to define the use of PCRs | BIOS | | (although Windows OS is rare on Networking | | | Equipment, UEFI BIOS is not) | | -------------------------------------------------------------------- | Use TAP to retrieve measurements | | | o Map to YANG | YANG Module for| | Use Canonical Log Format | Basic | | | Attestation | | | TCG Canonical | | | Log Format | -------------------------------------------------------------------- | Posture Collection Server (as described in IETF | | | SACMs ECP) should request the | | | attestation and analyze the result | | | The Management application might be broken down | | | to several more components: | | | o A Posture Manager Server | | | which collects reports and stores them in | | | a database | | | o One or more Analyzers that can look at the| | | results and figure out what it means. | | -------------------------------------------------------------------- Figure 7: Component Status 10. References 10.1. Normative References [Canonical-Event-Log] Trusted Computing Group, "Canonical Event Log Format Version 1.0 Revision .41, February 25, 2022", December 2020, . Fedorkow, et al. Expires 23 September 2022 [Page 38] Internet-Draft Network Device RIV March 2022 [I-D.ietf-rats-architecture] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture", Work in Progress, Internet-Draft, draft-ietf-rats-architecture- 15, 8 February 2022, . [I-D.ietf-rats-yang-tpm-charra] Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen, B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs", Work in Progress, Internet-Draft, draft-ietf-rats-yang-tpm-charra-18, 20 March 2022, . [I-D.ietf-sacm-coswid] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Waltermire, "Concise Software Identification Tags", Work in Progress, Internet-Draft, draft-ietf-sacm-coswid-21, 7 March 2022, . [IEEE-802-1AR] Seaman, M., "802.1AR-2018 - IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity, IEEE Computer Society", August 2018. [IMA] dsafford, kds_etu, mzohar, reinersailer, and serge_hallyn, "Integrity Measurement Architecture", June 2019, . [PC-Client-BIOS-TPM-2.0] Trusted Computing Group, "PC Client Specific Platform Firmware Profile Specification Family "2.0", Level 00 Revision 1.05 Revision 23, May 7, 2021", May 2021, . [PC-Client-EFI-TPM-1.2] Trusted Computing Group, "TCG EFI Platform Specification for TPM Family 1.1 or 1.2, Specification Version 1.22, Revision 15", January 2014, . Fedorkow, et al. Expires 23 September 2022 [Page 39] Internet-Draft Network Device RIV March 2022 [PC-Client-RIM] Trusted Computing Group, "TCG PC Client Reference Integrity Manifest Specification, v1.04, Nov 4, 2020", December 2019, . [Platform-DevID-TPM-2.0] Trusted Computing Group, "TPM 2.0 Keys for Device Identity and Attestation, Specification Version 1.0, Revision 2", September 2020, . [Platform-ID-TPM-1.2] Trusted Computing Group, "TPM Keys for Platform Identity for TPM 1.2, Specification Version 1.0, Revision 3", August 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Fedorkow, et al. Expires 23 September 2022 [Page 40] Internet-Draft Network Device RIV March 2022 [RIM] Trusted Computing Group, "TCG Reference Integrity Manifest (RIM) Information Model, v1.0, Revision 0.16, Nov 12, 2020", June 2019, . [SWID] The International Organization for Standardization/ International Electrotechnical Commission, "Information Technology Software Asset Management Part 2: Software Identification Tag, ISO/IEC 19770-2", October 2015, . [TAP] Trusted Computing Group, "TCG Trusted Attestation Protocol (TAP) Information Model for TPM Families 1.2 and 2.0 and DICE Family 1.0, Version 1.0, Revision 0.36", October 2018, . 10.2. Informative References [AK-Enrollment] Trusted Computing Group, "TCG Infrastructure Working Group - A CMC Profile for AIK Certificate Enrollment Version 1.0, Revision 7", March 2011, . [I-D.birkholz-rats-network-device-subscription] Birkholz, H., Voit, E., and W. Pan, "Attestation Event Stream Subscription", Work in Progress, Internet-Draft, draft-birkholz-rats-network-device-subscription-03, 17 August 2021, . [I-D.birkholz-rats-reference-interaction-model] Birkholz, H., Eckel, M., Newton, C., and L. Chen, "Reference Interaction Models for Remote Attestation Procedures", Work in Progress, Internet-Draft, draft- birkholz-rats-reference-interaction-model-03, 7 July 2020, . Fedorkow, et al. Expires 23 September 2022 [Page 41] Internet-Draft Network Device RIV March 2022 [I-D.birkholz-rats-tuda] Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann, "Time-Based Uni-Directional Attestation", Work in Progress, Internet-Draft, draft-birkholz-rats-tuda-06, 12 January 2022, . [I-D.ietf-rats-eat] Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity Attestation Token (EAT)", Work in Progress, Internet- Draft, draft-ietf-rats-eat-12, 24 February 2022, . [I-D.richardson-rats-usecases] Richardson, M., Wallace, C., and W. Pan, "Use cases for Remote Attestation common encodings", Work in Progress, Internet-Draft, draft-richardson-rats-usecases-08, 2 November 2020, . [IEEE-802.1AE] Seaman, M., "802.1AE MAC Security (MACsec)", 2018, . [IEEE-802.1X] IEEE Computer Society, "802.1X-2020 - IEEE Standard for Local and Metropolitan Area Networks--Port-Based Network Access Control", February 2020, . [LLDP] IEEE Computer Society, "802.1AB-2016 - IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery", March 2016, . [NetEq] Trusted Computing Group, "TCG Guidance for Securing Network Equipment, Version 1.0, Revision 29", January 2018, . [NIST-IR-8060] National Institute for Standards and Technology, "Guidelines for the Creation of Interoperable Software Identification (SWID) Tags", April 2016, . Fedorkow, et al. Expires 23 September 2022 [Page 42] Internet-Draft Network Device RIV March 2022 [Platform-Certificates] Trusted Computing Group, "TCG Platform Attribute Credential Profile, Specification Version 1.0, Revision 16", January 2018, . [Provisioning-TPM-2.0] Trusted Computing Group, "TCG TPM v2.0 Provisioning Guidance, Version 1.0, Revision 1.0", March 2015, . [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . [RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment (NEA) Asokan Attack Analysis", RFC 6813, DOI 10.17487/RFC6813, December 2012, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero Touch Provisioning (SZTP)", RFC 8572, DOI 10.17487/RFC8572, April 2019, . [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, May 2021, . Fedorkow, et al. Expires 23 September 2022 [Page 43] Internet-Draft Network Device RIV March 2022 [SP800-155] National Institute of Standards and Technology, "BIOS Integrity Measurement Guidelines (Draft)", December 2011, . [SP800-193] National Institute for Standards and Technology, "NIST Special Publication 800-193: Platform Firmware Resiliency Guidelines", April 2018, . [SWID-Gen] Labs64, Munich, Germany, "SoftWare IDentification (SWID) Tags Generator (Maven Plugin)", n.d., . [TCGRoT] Trusted Computing Group, "DRAFT: TCG Roots of Trust Specification", October 2018, . [TPM1.2] Trusted Computing Group, "TPM Main Specification Level 2 Version 1.2, Revision 116", March 2011, . [TPM2.0] Trusted Computing Group, "Trusted Platform Module Library Specification, Family "2.0", Level 00, Revision 01.59", November 2019, . Authors' Addresses Guy Fedorkow (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America Email: gfedorkow@juniper.net Eric Voit Cisco Systems Email: evoit@cisco.com Fedorkow, et al. Expires 23 September 2022 [Page 44] Internet-Draft Network Device RIV March 2022 Jessica Fitzgerald-McKay National Security Agency 9800 Savage Road Ft. Meade, Maryland 20755 United States of America Email: jmfitz2@nsa.gov Fedorkow, et al. Expires 23 September 2022 [Page 45] ./draft-ietf-regext-tmch-func-spec-15.txt0000644000764400076440000037143314301263263017775 0ustar iustiniustin Internet Engineering Task Force G. Lozano Internet-Draft ICANN Intended status: Informational 23 August 2022 Expires: 24 February 2023 ICANN TMCH functional specifications draft-ietf-regext-tmch-func-spec-15 Abstract This document describes the requirements, the architecture and the interfaces between the ICANN Trademark Clearinghouse (TMCH) and Domain Name Registries as well as between the ICANN TMCH and Domain Name Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 February 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Lozano Expires 24 February 2023 [Page 1] Internet-Draft ICANN-TMCH August 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Sunrise Period . . . . . . . . . . . . . . . . . . . . . 9 4.2. Trademark Claims Period . . . . . . . . . . . . . . . . . 10 4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. hv . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.2. vd . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.3. dy . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.4. tr . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.5. ry . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.6. dr . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.7. yd . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.8. dv . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.9. vh . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.10. vs . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.11. sy . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.12. sr . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.13. vc . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.14. cy . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.15. cr . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Process Descriptions . . . . . . . . . . . . . . . . . . . . 13 5.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. Bootstrapping for Registries . . . . . . . . . . . . 13 5.1.1.1. Credentials . . . . . . . . . . . . . . . . . . . 13 5.1.1.2. IP Addresses for Access Control . . . . . . . . . 14 5.1.1.3. ICANN TMCH Trust Anchor . . . . . . . . . . . . . 14 5.1.1.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . 14 5.1.2. Bootstrapping for Registrars . . . . . . . . . . . . 15 5.1.2.1. Credentials . . . . . . . . . . . . . . . . . . . 15 5.1.2.2. IP Addresses for Access Control . . . . . . . . . 15 5.1.2.3. ICANN TMCH Trust Anchor . . . . . . . . . . . . . 15 5.1.2.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . 16 5.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . 16 5.2.1. Domain Name registration . . . . . . . . . . . . . . 16 5.2.2. Sunrise Domain Name registration by Registries . . . 18 5.2.3. TMDB Sunrise Services for Registries . . . . . . . . 19 5.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 19 5.2.3.2. TMV Certificate Revocation List (CRL) . . . . . . 20 5.2.3.3. Notice of Registered Domain Names (NORN) . . . . 20 5.2.4. Sunrise Domain Name registration by Registrars . . . 23 5.2.5. TMDB Sunrise Services for Registrars . . . . . . . . 23 5.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 23 5.3.1. Domain Registration . . . . . . . . . . . . . . . . . 23 Lozano Expires 24 February 2023 [Page 2] Internet-Draft ICANN-TMCH August 2022 5.3.2. Trademark Claims Domain Name registration by Registries . . . . . . . . . . . . . . . . . . . . . 24 5.3.3. TMBD Trademark Claims Services for Registries . . . . 26 5.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . 26 5.3.3.2. Notice of Registered Domain Names (NORN) . . . . 27 5.3.4. Trademark Claims Domain Name registration by Registrars . . . . . . . . . . . . . . . . . . . . . 27 5.3.5. TMBD Trademark Claims Services for Registrars . . . . 28 5.3.5.1. Claims Notice Information Service (CNIS) . . . . 28 5.4. Qualified Launch Program (QLP) Period . . . . . . . . . . 29 5.4.1. Domain Registration . . . . . . . . . . . . . . . . . 29 5.4.2. TMBD QLP Services for Registries . . . . . . . . . . 31 5.4.2.1. Sunrise List (SURL) . . . . . . . . . . . . . . . 31 6. Data Format Descriptions . . . . . . . . . . . . . . . . . . 32 6.1. Domain Name Label (DNL) List . . . . . . . . . . . . . . 32 6.2. SMD Revocation List . . . . . . . . . . . . . . . . . . . 34 6.3. List of Registered Domain Names (LORDN) file . . . . . . 35 6.3.1. LORDN Log file . . . . . . . . . . . . . . . . . . . 39 6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . 42 6.4. Signed Mark Data (SMD) File . . . . . . . . . . . . . . . 46 6.5. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 47 6.6. Sunrise List (SURL) . . . . . . . . . . . . . . . . . . . 54 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 55 7.1. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 55 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 58 9.1. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 58 9.2. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 58 9.3. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 58 9.4. Version 07 . . . . . . . . . . . . . . . . . . . . . . . 58 9.5. Version 08 . . . . . . . . . . . . . . . . . . . . . . . 58 9.6. Version 09 . . . . . . . . . . . . . . . . . . . . . . . 59 9.7. Version 10 . . . . . . . . . . . . . . . . . . . . . . . 59 9.8. Version 11 . . . . . . . . . . . . . . . . . . . . . . . 59 9.9. Version 12 . . . . . . . . . . . . . . . . . . . . . . . 59 9.10. Version 13 . . . . . . . . . . . . . . . . . . . . . . . 59 9.11. Version 14 . . . . . . . . . . . . . . . . . . . . . . . 59 9.12. Version 15 . . . . . . . . . . . . . . . . . . . . . . . 59 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 11. Security Considerations . . . . . . . . . . . . . . . . . . . 60 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 60 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 13.1. Normative References . . . . . . . . . . . . . . . . . . 61 13.2. Informative References . . . . . . . . . . . . . . . . . 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 63 Lozano Expires 24 February 2023 [Page 3] Internet-Draft ICANN-TMCH August 2022 1. Introduction Domain Name Registries (DNRs) may operate in special modes for certain periods of time enabling trademark holders to protect their rights during the introduction of a Top Level Domain (TLD). Along with the introduction of new generic TLDs (gTLD), two special modes came into effect: * Sunrise Period, the Sunrise Period allows trademark holders an advance opportunity to register domain names corresponding to their marks before names are generally available to the public. * Trademark Claims Period, the Trademark Claims Period follows the Sunrise Period and runs for at least the first 90 days of an initial operating period of general registration. During the Trademark Claims Period, anyone attempting to register a domain name matching a mark that is recorded in the ICANN Trademark Clearinghouse (TMCH) will receive a notification displaying the relevant mark information. This document describes the requirements, the architecture and the interfaces between the ICANN TMCH and Domain Name Registries (called Registries in the rest of the document) as well as between the ICANN TMCH and Domain Name Registrars (called Registrars in the rest of the document) for the provisioning and management of domain names during the Sunrise and Trademark Claims Periods. For any date and/or time indications, Coordinated Universal Time (UTC) applies. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation. Lozano Expires 24 February 2023 [Page 4] Internet-Draft ICANN-TMCH August 2022 "tmNotice-1.0" is used as an abbreviation for "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix "tmNotice" is used, but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. Extensible Markup Language (XML) 1.0 as described in [W3C.REC-xml-20081126] and XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028] are used in this specification. 3. Glossary In the following section, the most common terms are briefly explained: * Backend Registry Operator: Entity that manages (a part of) the technical infrastructure for a Registry Operator. The Registry Operator may also be the Backend Registry Operator. * CA: Certificate Authority, see [RFC5280]. * CNIS, Claims Notice Information Service: This service provides Trademark Claims Notices (TCN) to Registrars. * CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. * CRL: Certificate Revocation List, see [RFC5280]. * CSV: Comma-Separated Values, see [RFC4180] * Date and time, datetime: Date and time are specified following the standard "Date and Time on the Internet specification", see [RFC3339]. * DN, Domain Name, domain name: see definition of Domain name in [RFC8499]. * DNROID, DN Repository Object IDentifier: an identifier assigned by the Registry to each DN object that unequivocally identifies said DN object. For example, if a new DN object is created for a name that existed in the past, the DN objects will have different DNROIDs. * DNL, Domain Name Label, the DNL is an A-label or NR-LDH label (see [RFC5890]). Lozano Expires 24 February 2023 [Page 5] Internet-Draft ICANN-TMCH August 2022 * DNL List: A list of DNLs that are covered by a PRM. * DNS: Domain Name System, see [RFC8499]. * Effective allocation: A DN is considered effectively allocated when the DN object for the DN has been created in the SRS of the Registry and has been assigned to the effective user. A DN object in status "pendingCreate" or any other status that precedes the first time a DN is assigned to an end-user is not considered an effective allocation. A DN object created internally by the Registry for subsequent delegation to another Registrant is not considered an effective allocation. * EPP: The Extensible Provisioning Protocol, see definition of EPP in [RFC8499]. * FQDN: Fully-Qualified Domain Name, see definition of FQDN in [RFC8499]. * HTTP: Hypertext Transfer Protocol, see [RFC7230] and [RFC7231]. * HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]. * IDN: Internationalized Domain Name, see definition of IDN in [RFC8499]. * Lookup Key: A random string of up to 51 chars from the set [a-zA- Z0-9/] to be used as the lookup key by Registrars to obtain the TCN using the CNIS. Lookup Keys are unique and are related to one DNL only. * LORDN, List of Registered Domain Names: This is the list of effectively allocated DNs matching a DNL of a PRM. Registries will upload this list to the TMDB (during the NORDN process). * Matching Rules: Some trademarks entitled to inclusion in the TMDB include characters that are impermissible in the domain name system (DNS) as a DNL. The TMV changes ( using the ICANN TMCH Matching Rules [MatchingRules]) certain DNS-impermissible characters in a trademark into DNS-permissible equivalent characters * NORDN, Notification of Registered Domain Names: The process by which Registries upload their recent LORDN to the TMDB. * PGP: Pretty Good Privacy, see [RFC4880] * PKI: Public Key Infrastructure, see [RFC5280]. Lozano Expires 24 February 2023 [Page 6] Internet-Draft ICANN-TMCH August 2022 * PRM, Pre-registered mark: Mark that has been pre-registered with the ICANN TMCH. * QLP Period, Qualified Launch Program Period: During this optional period, a special process applies to DNs matching the Sunrise List (SURL) and/or the DNL List, to ensure that TMHs are informed of a DN matching their PRM. * Registrant: see definition of Registrant in [RFC8499]. * Registrar, Domain Name Registrar: see definition of Registrar in [RFC8499]. * Registry, Domain Name Registry, Registry Operator: see definition of Registry in [RFC8499]. A Registry Operator is the contracting party with ICANN for the TLD. * SMD, Signed Mark Data: A cryptographically signed token issued by the TMV to the TMH to be used in the Sunrise Period to apply for a DN that matches a DNL of a PRM; see also [RFC7848]. An SMD generated by an ICANN-approved trademark validator (TMV) contains both the signed token and the TMV's PKIX certificate. * SMD File: A file containing the SMD (see above) and some human readable data. The latter is usually ignored in the processing of the SMD File. See also Section 6.4. * SMD Revocation List: The SMD Revocation List is used by Registries (and optionally by Registrars) during the Sunrise Period to ensure that an SMD is still valid (i.e. not revoked). The SMD Revocation List has a similar function as CRLs used in PKI. * SRS: Shared Registration System, see also [ICANN-GTLD-AGB-20120604]. * SURL, Sunrise List: The list of DNLs that are covered by a PRM and eligible for Sunrise. * Sunrise Period: During this period DNs matching a DNL of a PRM can be exclusively obtained by the respective TMHs. For DNs matching a PRM, a special process applies to ensure that TMHs are informed on the effective allocation of a DN matching their PRM. * TLD: Top-Level Domain Name, see definition of TLD in [RFC8499]. Lozano Expires 24 February 2023 [Page 7] Internet-Draft ICANN-TMCH August 2022 * ICANN TMCH: a central repository for information to be authenticated, stored, and disseminated, pertaining to the rights of TMHs. The ICANN TMCH is split into two functions TMV and TMDB (see below). There could be several entities performing the TMV function, but only one entity performing the TMDB function. * ICANN TMCH-CA: The Certificate Authority (CA) for the ICANN TMCH. This CA is operated by ICANN. The public key for this CA is the trust anchor used to validate the identity of each TMV. * TMDB, Trademark Clearinghouse Database: Serves as a database of the ICANN TMCH to provide information to the gTLD Registries and Registrars to support Sunrise or Trademark Claims services. There is only one TMDB in the ICANN TMCH that concentrates the information about the "verified" Trademark records from the TMVs. * TMH, Trademark Holder: The person or organization owning rights on a mark. * TMV, Trademark Validator, Trademark validation organization: An entity authorized by ICANN to authenticate and validate registrations in the TMDB ensuring the marks qualify as registered or are court-validated marks or marks that are protected by statute or treaty. This entity would also be asked to ensure that proof of use of marks is provided, which can be demonstrated by furnishing a signed declaration and one specimen of current use. * Trademark, mark: Marks are used to claim exclusive properties of products or services. A mark is typically a name, word, phrase, logo, symbol, design, image, or a combination of these elements. For the scope of this document only textual marks are relevant. * Trademark Claims, Claims: Provides information to enhance the understanding of the Trademark rights being claimed by the TMH. * TCN, Trademark Claims Notice, Claims Notice, Trademark Notice: A Trademark Claims Notice consist of one or more Trademark Claims and are provided to prospective Registrants of DNs. * TCNID, Trademark Claims Notice Identifier: An element of the Trademark Claims Notice (see above), identifying said TCN. The Trademark Claims Notice Identifier is specified in the element . Lozano Expires 24 February 2023 [Page 8] Internet-Draft ICANN-TMCH August 2022 * Trademark Claims Period: During this period, a special process applies to DNs matching the DNL List, to ensure that TMHs are informed of a DN matching their PRM. For DNs matching the DNL List, Registrars show a TCN to prospective Registrants that has to be acknowledged before effective allocation of the DN. * UTC: Coordinated Universal Time, as maintained by the Bureau International des Poids et Mesures (BIPM); see also [RFC3339]. 4. Architecture 4.1. Sunrise Period Architecture of the Sunrise Period SMD hand over (out-of-band) .............................................. : : : .'''''''''''''''''''. : : . ICANN TMCH . : : ..................... : v . . : .------------. . .-------------. . hv .-----. | Registrant | . | TMV |<---------->| TMH | '------------' . '-------------' . vh '-----' | . | ^ \ . | . | | \. tr | . vs | | dv \ | . | vd | .\ v . v v . \ .-----------. sr . .---------. . \ .->| Registrar |<..........| | . \ : '-----------' . | | . \ : | sy . | T | . \ : ry | .------------| M | . vc \ : | | . | D | . \ : v v . | B | . v : .-----------. . yd | | . .---------------. : | Registry |---------->| | . | ICANN TMCH-CA | : '-----------' . '---------' . '---------------' : ^ . . | : : | ''''''''''''''''''' | : : | cy | : : cr '-----------------------------------------' : :......................................................: Lozano Expires 24 February 2023 [Page 9] Internet-Draft ICANN-TMCH August 2022 Figure 1 Figure 1 depicts the architecture of the Sunrise Period, including all the actors and interfaces. 4.2. Trademark Claims Period Architecture of the Trademark Claims Period .''''''''''''''. . ICANN TMCH . ................ . . .------------. . .-------. . hv .-----. | Registrant | . | TMV |<----------->| TMH | '------------' . '-------' . vh '-----' | . ^ . | . | dv . tr | . vd | . v . v . .-----------. dr . .-------. . | Registrar |<--------| | . '-----------' . | T | . ry | . | M | . v . | D | . .----------. dy . | B | . | Registry |<------->| | . '----------' yd . '-------' . . . '''''''''''''' Figure 2 Figure 2 depicts the architecture of the Trademark Claims Period, including all the actors and interfaces. 4.3. Interfaces In the sub-sections below follows a short description of each interface to provide an overview of the architecture. More detailed descriptions of the relevant interfaces follow further below (Section 5). Lozano Expires 24 February 2023 [Page 10] Internet-Draft ICANN-TMCH August 2022 4.3.1. hv The TMH registers a mark with a TMV via the hv interface. After the successful registration of the mark, the TMV makes available a SMD File (see also Section 6.4) to the TMH to be used during the Sunrise Period. The specifics of the hv interface are beyond the scope of this document. 4.3.2. vd After successful mark registration, the TMV ensures the TMDB inserts the corresponding DNLs and mark information into the database via the vd interface. The specifics of the vd interface are beyond the scope of this document. 4.3.3. dy During the Trademark Claims Period the Registry fetches the latest DNL List from the TMDB via the dy interface at regular intervals. The protocol used on the dy interface is HTTPS. Not relevant during the Sunrise Period. 4.3.4. tr The Registrant communicates with the Registrar via the tr interface. The specifics of the tr interface are beyond the scope of this document. 4.3.5. ry The Registrar communicate with the Registry via the ry interface. The ry interfaces is typically implemented in EPP. 4.3.6. dr During the Trademark Claims Period, the Registrar fetches the TCN from the TMDB (to be displayed to the Registrant via the tr interface) via the dr interface. The protocol used for fetching the TCN is HTTPS. Not relevant during the Sunrise Period. Lozano Expires 24 February 2023 [Page 11] Internet-Draft ICANN-TMCH August 2022 4.3.7. yd During the Sunrise Period the Registry notifies the TMDB via the yd interface of all DNs effectively allocated. During the Trademark Claims Period, the Registry notifies the TMDB via the yd interface of all DNs effectively allocated that matched an entry in the Registry previously downloaded DNL List during the creation of the DN. The protocol used on the yd interface is HTTPS. 4.3.8. dv The TMDB notifies via the dv interface to the TMV of all DNs effectively allocated that match a mark registered by that TMV. The specifics of the dv interface are beyond the scope of this document. 4.3.9. vh The TMV notifies the TMH via the vh interface after a DN has been effectively allocated that matches a PRM of this TMH. The specifics of the vh interface are beyond the scope of this document. 4.3.10. vs The TMV requests to add a revoked SMD to the SMD Revocation List at the TMDB. The specifics of the vs interface are beyond the scope of this document. Not relevant during the Trademark Claims Period. 4.3.11. sy During the Sunrise Period the Registry fetches the most recent SMD Revocation List from the TMDB via the sy interface in regular intervals. The protocol used on the sy interface is HTTPS. Not relevant during the Trademark Claims Period. Lozano Expires 24 February 2023 [Page 12] Internet-Draft ICANN-TMCH August 2022 4.3.12. sr During the Sunrise Period the Registrar may fetch the most recent SMD Revocation List from the TMDB via the sr interface. The protocol used on the sr interface is the same as on the sy interface (s. above), i.e. HTTPS. Not relevant during the Trademark Claims Period. 4.3.13. vc The TMV registers its public key, and requests to revoke an existing key, with the ICANN TMCH-CA over the vc interface. The specifics of the vc interface are beyond the scope of this document, but it involves personal communication between the operators of the TMV and the operators of the ICANN TMCH-CA. Not relevant during the Trademark Claims Period. 4.3.14. cy During the Sunrise Period the Registry fetches the most recent TMV CRL file from the ICANN TMCH-CA via the cy interface at regular intervals. The TMV CRL is used for validation of TMV certificates. The protocol used on the cy interface is HTTPS. Not relevant during the Trademark Claims Period. 4.3.15. cr During the Sunrise Period the Registrar optionally fetches the most recent TMV CRL file from the ICANN TMCH-CA via the cr interface at regular intervals. The TMV CRL is used for validation of TMV certificates. The protocol used on the cr interface is HTTPS. Not relevant during the Trademark Claims Period. 5. Process Descriptions 5.1. Bootstrapping 5.1.1. Bootstrapping for Registries 5.1.1.1. Credentials Each Registry Operator will receive authentication credentials from the TMDB to be used: Lozano Expires 24 February 2023 [Page 13] Internet-Draft ICANN-TMCH August 2022 * During the Sunrise Period to fetch the SMD Revocation List from the TMBD via the sy interface (Section 4.3.11). * During the Trademark Claims Period to fetch the DNL List from the TMDB via the dy interface (Section 4.3.3). * During the NORDN process to notify the LORDN to the TMDB via the yd interface (Section 4.3.7). Note: credentials are created per TLD and provided to the Registry Operator. 5.1.1.2. IP Addresses for Access Control Each Registry Operator MUST provide to the TMDB all IP addresses that will be used to: * Fetch the SMD Revocation List via the sy interface (Section 4.3.11). * Fetch the DNL List from the TMDB via the dy interface (Section 4.3.3). * Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). This access restriction MAY be applied by the TMDB in addition to HTTP Basic access authentication (see [RFC7235]). For credentials to be used, see Section 5.1.1.1. The TMDB MAY limit the number of IP addresses to be accepted per Registry Operator. 5.1.1.3. ICANN TMCH Trust Anchor Each Registry Operator MUST fetch the PKIX certificate ([RFC5280]) of the ICANN TMCH-CA (Trust Anchor) from < https://ca.icann.org/ tmch.crt > to be used: * During the Sunrise Period to validate the TMV certificates and the TMV CRL. 5.1.1.4. TMDB PGP Key The TMDB MUST provide each Registry Operator with the public portion of the PGP Key used by TMDB, to be used: Lozano Expires 24 February 2023 [Page 14] Internet-Draft ICANN-TMCH August 2022 * During the Sunrise Period to perform integrity checking of the SMD Revocation List fetched from the TMDB via the sy interface (Section 4.3.11). * During the Trademark Claims Period to perform integrity checking of the DNL List fetched from the TMDB via the dy interface (Section 4.3.3). 5.1.2. Bootstrapping for Registrars 5.1.2.1. Credentials Each ICANN-accredited Registrar will receive authentication credentials from the TMDB to be used: * During the Sunrise Period to (optionally) fetch the SMD Revocation List from the TMDB via the sr interface (Section 4.3.12). * During the Trademark Claims Period to fetch TCNs from the TMDB via the dr interface (Section 4.3.6). 5.1.2.2. IP Addresses for Access Control Each Registrar MUST provide to the TMDB all IP addresses, which will be used to: * Fetch the SMD Revocation List via the sr interface (Section 4.3.12). * Fetch TCNs via the dr interface (Section 4.3.6). This access restriction MAY be applied by the TMDB in addition to HTTP Basic access authentication (for credentials to be used, see Section 5.1.2.1). The TMDB MAY limit the number of IP addresses to be accepted per Registrar. 5.1.2.3. ICANN TMCH Trust Anchor Registrars MAY fetch the PKIX certificate of the ICANN TMCH-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to be used: * During the Sunrise Period to (optionally) validate the TMV certificates and TMV CRL. Lozano Expires 24 February 2023 [Page 15] Internet-Draft ICANN-TMCH August 2022 5.1.2.4. TMDB PGP Key Registrars MUST receive the public portion of the PGP Key used by TMDB from the TMDB administrator to be used: * During the Sunrise Period to (optionally) perform integrity checking of the SMD Revocation List fetched from the TMDB via the sr interface (Section 4.3.12). 5.2. Sunrise Period 5.2.1. Domain Name registration Domain Name registration during the Sunrise Period Lozano Expires 24 February 2023 [Page 16] Internet-Draft ICANN-TMCH August 2022 .------------. .-----------. .----------. | Registrant | | Registrar | | Registry | '------------' '-----------' '----------' | | | | Request DN | | | registration | | | (with SMD) | | |---------------->| Check DN availability | | |---------------------------->| | | | | | DN unavailable .-------------. | DN unavailable |<--------------------( DN available? ) |<----------------| no '-------------' | | | yes | | DN available | | |<----------------------------| | | | | | Request DN registration | | | (with SMD) | | |---------------------------->| | | | | | .------------------------------. | | | DN registration validation / | | | | SMD validation | | | '------------------------------' | | | | Registration |.-----------. Error .----------------------. | error || TRY AGAIN |<-----( Validation successful? ) |<----------------|| / ABORT | no '----------------------' | |'-----------' | yes | | | | | DN registered | | DN registered |<----------------------------| |<----------------| | | | | Figure 3 Figure 3 represents a synchronous DN registration workflow (usually called first come first served). Lozano Expires 24 February 2023 [Page 17] Internet-Draft ICANN-TMCH August 2022 5.2.2. Sunrise Domain Name registration by Registries Registries MUST perform a minimum set of checks for verifying each DN registration during the Sunrise Period upon reception of a registration request over the ry interface (Section 4.3.5). If any of these checks fails the Registry MUST abort the registration. Each of these checks MUST be performed before the DN is effectively allocated. In case of asynchronous registrations (e.g. auctions), the minimum set of checks MAY be performed when creating the intermediate object (e.g. a DN application) used for DN registration. If the minimum set of checks is performed when creating the intermediate object (e.g. a DN application) a Registry MAY effectively allocate the DN without performing the minimum set of checks again. Performing the minimum set of checks Registries MUST verify that: 1. An SMD has been received from the Registrar along with the DN registration. 2. The certificate of the TMV has been correctly signed by the ICANN TMCH-CA. (The certificate of the TMV is contained within the SMD.) 3. The datetime when the validation is done is within the validity period of the TMV certificate. 4. The certificate of the TMV is not listed in the TMV CRL file specified in the CRL distribution point of the TMV certificate. 5. The signature of the SMD (signed with the TMV certificate) is valid. 6. The datetime when the validation is done is within the validity period of the SMD based on and elements. 7. The SMD has not been revoked, i.e., is not contained in the SMD Revocation List. 8. The leftmost DNL of the DN being effectively allocated matches one of the labels () elements in the SMD. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, the leftmost DNL would be "xn--mgbachtv". Lozano Expires 24 February 2023 [Page 18] Internet-Draft ICANN-TMCH August 2022 These procedure apply to all DN effective allocations at the second level as well as to all other levels subordinate to the TLD that the Registry accepts registrations for. 5.2.3. TMDB Sunrise Services for Registries 5.2.3.1. SMD Revocation List A new SMD Revocation List MUST be published by the TMDB twice a day, by 00:00:00 and 12:00:00 UTC. Registries MUST refresh the latest version of the SMD Revocation List at least once every 24 hours. Note: the SMD Revocation List will be the same regardless of the TLD. If a Backend Registry Operator manages the infrastructure of several TLDs, the Backend Registry Operator could refresh the SMD Revocation List once every 24 hours, the SMD Revocation List could be used for all the TLDs managed by the Backend Registry Operator. Update of the SMD Revocation List .----------. .------. | Registry | | TMDB | '----------' '------' | | .----------------. | | Periodically, | | | at least | | | every 24 hours | | '----------------' | | | |----------------------------------------------------->| | Download the latest SMD Revocation List | |<-----------------------------------------------------| | | | | Figure 4 Figure 4 depicts the process of downloading the latest SMD Revocation List initiated by the Registry. Lozano Expires 24 February 2023 [Page 19] Internet-Draft ICANN-TMCH August 2022 5.2.3.2. TMV Certificate Revocation List (CRL) Registries MUST refresh their local copy of the TMV CRL file at least every 24 hours using the CRL distribution point specified in the TMV certificate. Operationally, the TMV CRL file and CRL distribution point is the same for all TMVs and (at publication of this document) located at < http://crl.icann.org/tmch.crl >. Note: the TMV CRL file will be the same regardless of the TLD. If a Backend Registry Operator manages the infrastructure of several TLDs, the Backend Registry Operator could refresh the TMV CRL file once every 24 hours, the TMV CRL file could be used for all the TLDs managed by the Backend Registry Operator. Update of the TMV CRL file .----------. .---------------. | Registry | | ICANN TMCH-CA | '----------' '---------------' | | .----------------. | | Periodically, | | | at least | | | every 24 hours | | '----------------' | | | |-------------------------------------------->| | Download the latest TMV CRL file | |<--------------------------------------------| | | | | Figure 5 Figure 5 depicts the process of downloading the latest TMV CRL file initiated by the Registry. 5.2.3.3. Notice of Registered Domain Names (NORN) The Registry MUST send a LORDN file containing DNs effectively allocated to the TMDB (over the yd interface, Section 4.3.7). The effective allocation of a DN MUST be reported by the Registry to the TMDB within 26 hours of the effective allocation of such DN. Lozano Expires 24 February 2023 [Page 20] Internet-Draft ICANN-TMCH August 2022 The Registry MUST create and upload a LORDN file in case there are effective allocations in the SRS, that have not been successfully reported to the TMDB in a previous LORDN file. Based on the timers used by TMVs and the TMDB, the RECOMMENDED maximum frequency to upload LORDN files from the Registries to the TMDB is every 3 hours. It is RECOMMENDED that Registries try to upload at least two LORDN files per day to the TMDB with enough time in between, in order to have time to fix problems reported in the LORDN file. The Registry SHOULD upload a LORDN file only when the previous LORDN file has been processed by the TMDB and the related LORDN Log file has been downloaded and processed by the Registry. The Registry MUST upload LORDN files for DNs effectively allocated during the Sunrise or Trademark Claims Period (same applies to DNs effectively allocated using applications created during the Sunrise or Trademark Claims Period in case of using asynchronous registrations). The yd interface (Section 4.3.7) MUST support at least one (1) and MAY support up to ten (10) concurrent connections from each IP address registered by a Registry Operator to access the service. The TMDB MUST process each uploaded LORDN file and make the related log file available for Registry download within 30 minutes of the finalization of the upload. Notification of Registered Domain Name Lozano Expires 24 February 2023 [Page 21] Internet-Draft ICANN-TMCH August 2022 .----------. .------. .-----. .-----. | Registry | | TMDB | | TMV | | TMH | '----------' '------' '-----' '-----' | | | | .------------------. | | | | Periodically | | | | | upload LORDN | | | | | file | | | | '------------------' | | | | | | | .--------->| Upload LORDN | | | | |-------------------->| | | | | | | | | | .-------------------------. | | | | | Verify each domain name | | | | | | in the uploaded file | | | | | | (within 30') | | | | | '-------------------------' | | | | | ._____.| | | | Download Log file | | END || | | |<--------------------| '-----'| | | | | ^ | | | .-----------------. .---------------. | | | | | Check whether | / everything fine \ no | | | | | Log file | ( (i.e. no errors )---' | | | | contains errors | \ in Log file )? / | | | '-----------------' '---------------' | | | | | yes | | | .---------------. | | | | / everything fine \ yes | | | |( (i.e. no errors )-----. | Notify TMVs | | | \ in Log file )? / | | on the LORDN | | | '---------------' | | pre-registered | | | | no v | with said TMV | | | .----------------. .------. |--------------->| | '-| Correct Errors | | DONE | | | | '----------------' '------' | | Notify each | | | | affected TMH | | | |-------------->| | | | | Figure 6 Figure 6 depicts the process to notify the TMH of Registered Domain Names. The format used for the LORDN is described in Section 6.3 Lozano Expires 24 February 2023 [Page 22] Internet-Draft ICANN-TMCH August 2022 5.2.4. Sunrise Domain Name registration by Registrars Registrars MAY choose to perform the checks for verifying DN registrations as performed by the Registries (see Section 5.2.2) before sending the command to register a DN. 5.2.5. TMDB Sunrise Services for Registrars The processes described in Section 5.2.3.1 and Section 5.2.3.2 are also available for Registrars to optionally validate the SMDs received. 5.3. Trademark Claims Period 5.3.1. Domain Registration Domain Name registration during the Trademark Claims Period Lozano Expires 24 February 2023 [Page 23] Internet-Draft ICANN-TMCH August 2022 .------------. .-----------. .----------. .------. | Registrant | | Registrar | | Registry | | TMDB | '------------' '-----------' '----------' '------' | Request DN | | | | registration | | | |--------------->| Check DN availability | | | |--------------------------->| | | | DN unavailable .-------------. | | DN unavailable |<-------------------( DN available? ) | |<---------------| no '-------------' | | | DN available | yes | | |<---------------------------| | | | Request Lookup key | | | |--------------------------->| | | |.__________. .---------. | | || CONTINUE | / Does DN \ | | || NORMALLY |<--------( match DNL ) | | |'----------' no \ of PRM? / | | | '---------' | | | Lookup key | yes | | |<----------------------------' | | | | .-----. | | Request TCN | |ABORT| | Display |---------------------------------------->| '-----' | Claims | Return TCN | ^ | Notice |<----------------------------------------| | no |<---------------| | | .------. yes | | '-( Ack? )----------->| Register DN (with TCNID) | | '------' |--------------------------->| | | Registration | Error .----------------------. | | error |<-------------( Validation successful? ) | |<---------------| no '----------------------' | | | | yes | | | DN registered | | | DN registered |<---------------------------| | |<---------------| | | Figure 7 Figure 7 represents a synchronous DN registration workflow (usually called first come first served). 5.3.2. Trademark Claims Domain Name registration by Registries During the Trademark Claims Period, Registries perform two main functions: Lozano Expires 24 February 2023 [Page 24] Internet-Draft ICANN-TMCH August 2022 * Registries MUST provide Registrars (over the ry interface, Section 4.3.5) the Lookup Key used to retrieve the TCNs for DNs that match the DNL List. * Registries MUST provide the Lookup Key only when queried about a specific DN. * For each DN matching a DNL of a PRM, Registries MUST perform a minimum set of checks for verifying DN registrations during the Trademark Claims Period upon reception of a registration request over the ry interface (Section 4.3.5). If any of these checks fails the Registry MUST abort the registration. Each of these checks MUST be performed before the DN is effectively allocated. * In case of asynchronous registrations (e.g. auctions), the minimum set of checks MAY be performed when creating the intermediate object (e.g. a DN application) used for DN effective allocation. If the minimum set of checks is performed when creating the intermediate object (e.g. a DN application) a Registry MAY effectively allocate the DN without performing the minimum set of checks again. * Performing the minimum set of checks Registries MUST verify that: 1. The TCNID (), expiration datetime () and acceptance datetime of the TCN, have been received from the Registrar along with the DN registration. If the three elements mentioned above are not provided by the Registrar for a DN matching a DNL of a PRM, but the DNL was inserted (or re-inserted) for the first time into DNL List less than 24 hours ago, the registration MAY continue without this data and the tests listed below are not required to be performed. 2. The TCN has not expired (according to the expiration datetime sent by the Registrar). 3. The acceptance datetime is within the window of time defined by ICANN policy. In the gTLD round of 2012, Registrars verified that the acceptance datetime was less than or equal to 48 hours in the past, as there were no defined ICANN policies at that time. Implementers should be aware that ICANN policy may define this value in the future. Lozano Expires 24 February 2023 [Page 25] Internet-Draft ICANN-TMCH August 2022 4. Using the leftmost DNL of the DN being effectively allocated, the expiration datetime provided by the Registrar, and the TMDB Notice Identifier extracted from the TCNID provided by the Registrar compute the TCN Checksum. Verify that the computed TCN Checksum match the TCN Checksum present in the TCNID. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, the leftmost DNL would be "xn-- mgbachtv". These procedures apply to all DN registrations at the second level as well as to all other levels subordinate to the TLD that the Registry accepts registrations for. 5.3.3. TMBD Trademark Claims Services for Registries 5.3.3.1. Domain Name Label (DNL) List A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 and 12:00:00 UTC. Registries MUST refresh the latest version of the DNL List at least once every 24 hours. Update of the DNL List .----------. .------. | Registry | | TMDB | '----------' '------' | | .----------------. | | Periodically, | | | at least | | | every 24 hours | | '----------------' | | | |-------------------------------->| | Download the latest DNL List | |<--------------------------------| | | | | Figure 8 Figure 8 depicts the process of downloading the latest DNL list initiated by the Registry. Lozano Expires 24 February 2023 [Page 26] Internet-Draft ICANN-TMCH August 2022 Note: the DNL List will be the same regardless of the TLD. If a Backend Registry Operator manages the infrastructure of several TLDs, the Backend Registry Operator could refresh the DNL List once every 24 hours, the DNL List could be used for all the TLDs managed by the Backend Registry Operator. 5.3.3.2. Notice of Registered Domain Names (NORN) The NORDN process during the Trademark Claims Period is almost the same as during Sunrise Period as defined in Section 5.2.3.3 with the difference that only registrations subject to a Trademark Claim (i.e., at registration time the name appeared in the current DNL List downloaded by the Registry Operator) are included in the LORDN. 5.3.4. Trademark Claims Domain Name registration by Registrars For each DN matching a DNL of a PRM, Registrars MUST perform the following steps: 1. Use the Lookup Key received from the Registry to obtain the TCN from the TMDB using the dr interface (Section 4.3.6) Registrars MUST only query for the Lookup Key of a DN that is available for registration. 2. Present the TCN to the Registrant as described in Exhibit A, [RPM-Requirements]. 3. Ask Registrant for acknowledgement, i.e. the Registrant MUST consent with the TCN, before any further processing. (The transmission of a TCNID to the Registry over the ry interface, Section 4.3.5 implies that the Registrant has expressed his/her consent with the TCN.) 4. Perform the minimum set of checks for verifying DN registrations. If any of these checks fails the Registrar MUST abort the DN registration. Each of these checks MUST be performed before the registration is sent to the Registry. Performing the minimum set of checks Registrars MUST verify that: 1. The datetime when the validation is done is within the TCN validity based on the and elements. 2. The leftmost DNL of the DN being effectively allocated matches the label () element in the TCN. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, the leftmost DNL would be "xn-- mgbachtv". Lozano Expires 24 February 2023 [Page 27] Internet-Draft ICANN-TMCH August 2022 3. The Registrant has acknowledged (expressed his/her consent with) the TCN. 5. Record the date and time when the registrant acknowledged the TCN. 6. Send the registration to the Registry (ry interface, Section 4.3.5) and include the following information: * TCNID () * Expiration date of the TCN () * Acceptance datetime of the TCN. Currently TCNs are generated twice a day by the TMDB. The expiration date () of each TCN MUST be set to a value defined by ICANN policy. In the gTLD round of 2012, the TMDB set the expiration value to 48 hours in to the future as there were no defined ICANN policies at that time. Implementers should be aware that ICANN policy may define this value in the future. Registrars SHOULD implement a cache of TCNs to minimize the number of queries sent to the TMDB. A cached TCN MUST be removed from the cache after the expiration date of the TCN as defined by . The TMDB MAY implement rate-limiting as one of the protection mechanisms to mitigate the risk of performance degradation. 5.3.5. TMBD Trademark Claims Services for Registrars 5.3.5.1. Claims Notice Information Service (CNIS) The TCNs are provided by the TMDB online and are fetched by the Registrar via the dr interface (Section 4.3.6). To get access to the TCNs, the Registrar needs the credentials provided by the TMDB (Section 5.1.2.1) and the Lookup Key received from the Registry via the ry interface (Section 4.3.5). The dr interface (Section 4.3.6) uses HTTPS with Basic access authentication. The dr interface (Section 4.3.6) MAY support up to ten (10) concurrent connections from each Registrar. The URL of the dr interface (Section 4.3.6) is: Lozano Expires 24 February 2023 [Page 28] Internet-Draft ICANN-TMCH August 2022 < https:///cnis/.xml > Note that the "lookupkey" may contain SLASH characters ("/"). The SLASH character is part of the URL path and MUST NOT be escaped when requesting the TCN. The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) MUST be signed by a well-know public CA. Registrars MUST perform the Certification Path Validation described in Section 6 of [RFC5280]. Registrars will be authenticated in the dr interface using HTTP Basic access authentication. The dr (Section 4.3.6) interface MUST support HTTPS keep-alive and MUST maintain the connection for up to 30 minutes. 5.4. Qualified Launch Program (QLP) Period 5.4.1. Domain Registration During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program (QLP) Period effective allocations of DNs to third parties could require that Registries and Registrars provide Sunrise and/or Trademark Claims services. If required, Registries and Registrars MUST provide Sunrise and/or Trademark Claims services as described in Section 5.2 and Section 5.3. The effective allocation scenarios are: * If the leftmost DNL of the DN being effectively allocated (QLP Name in this section) matches a DNL in the SURL, and an SMD is provided, then Registries MUST provide Sunrise Services (see Section 5.2) and the DN MUST be reported in a Sunrise LORDN file during the QLP Period. For example, if the DN "xn--mgbachtv.xn-- mgbh0fb" is being effectively allocated, the leftmost DNL would be "xn--mgbachtv". * If the QLP Name matches a DNL in the SURL but does not match a DNL in the DNL List, and an SMD is NOT provided (see section 2.2 of [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN file using the special SMD-id "99999-99999" during the QLP Period. * If the QLP Name matches a DNL in the SURL and also matches a DNL in the DNL List, and an SMD is NOT provided (see section 2.2 of [QLP-Addendum]), then Registries MUST provide Trademark Claims services (see Section 5.3) and the DN MUST be reported in a Trademark Claims LORDN file during the QLP Period. Lozano Expires 24 February 2023 [Page 29] Internet-Draft ICANN-TMCH August 2022 * If the QLP Name matches a DNL in the DNL List but does not match a DNL in the SURL, then Registries MUST provide Trademark Claims services (see Section 5.2) and the DN MUST be reported in a Trademark Claims LORDN file during the QLP Period. The following table lists all the effective allocation scenarios during a QLP Period: +========+==========+=================+==============+==============+ | QLP | QLP | SMD was | Registry | Registry | | Name | Name | provided by the | MUST provide | MUST report | | match | match | potential | Sunrise or | DN | | in the | in the | Registrant | Trademark | registration | | SURL | DNL | | Claims | in | | | List | | Services | LORDN file | +========+==========+=================+==============+==============+ | Y | Y | Y | Sunrise | Sunrise | +--------+----------+-----------------+--------------+--------------+ | Y | N | Y | Sunrise | Sunrise | +--------+----------+-----------------+--------------+--------------+ | N | Y | -- | Trademark | Trademark | | | | | Claims | Claims | +--------+----------+-----------------+--------------+--------------+ | N | N | -- | -- | -- | +--------+----------+-----------------+--------------+--------------+ | Y | Y | N (see section | Trademark | Trademark | | | | 2.2 of | Claims | Claims | | | | [QLP-Addendum]) | | | +--------+----------+-----------------+--------------+--------------+ | Y | N | N (see section | -- | Sunrise | | | | 2.2 of | | (using | | | | [QLP-Addendum]) | | special SMD- | | | | | | id) | +--------+----------+-----------------+--------------+--------------+ Table 1: QLP Effective Allocation Scenarios The TMDB MUST provide the following services to Registries during a QLP Period: * SMD Revocation List (see Section 5.2.3.1) * NORN (see Section 5.2.3.3) * DNL List (see Section 5.3.3.1) * Sunrise List (SURL) (see Section 5.4.2.1 Lozano Expires 24 February 2023 [Page 30] Internet-Draft ICANN-TMCH August 2022 The TMDB MUST provide the following services to Registrars during a QLP Period: * SMD Revocation List (see Section 5.2.3.1) * CNIS (see Section 5.3.5.1) 5.4.2. TMBD QLP Services for Registries 5.4.2.1. Sunrise List (SURL) A new Sunrise List (SURL) MUST be published by the TMDB twice a day, by 00:00:00 and 12:00:00 UTC. Registries offering the OPTIONAL QLP Period MUST refresh the latest version of the SURL at least once every 24 hours. Update of the SURL .----------. .------. | Registry | | TMDB | '----------' '------' | | .----------------. | | Periodically, | | | at least | | | every 24 hours | | '----------------' | | | |------------------------------->| | Download the latest SURL | |<-------------------------------| | | | | Figure 9 Figure 9 depicts the process of downloading the latest SURL initiated by the Registry. Note: the SURL will be the same regardless of the TLD. If a Backend Registry Operator manages the infrastructure of several TLDs, the Backend Registry Operator could refresh the SURL once every 24 hours, the SURL could be used for all the TLDs managed by the Backend Registry Operator. Lozano Expires 24 February 2023 [Page 31] Internet-Draft ICANN-TMCH August 2022 6. Data Format Descriptions 6.1. Domain Name Label (DNL) List This section defines the format of the list containing every Domain Name Label (DNL) that matches a Pre-Registered Mark (PRM). The list is maintained by the TMDB and downloaded by Registries in regular intervals (see Section 5.3.3.1). The Registries use the DNL List during the Trademark Claims Period to check whether a requested DN matches a DNL of a PRM. The DNL List contains all the DNLs covered by a PRM present in the TMDB at the datetime it is generated. The DNL List is contained in a CSV formatted file that has the following structure: * first line: , Where: o , version of the file, this field MUST be 1. o , date and time in UTC that the DNL List was created. * second line: a header line as specified in [RFC4180] With the header names as follows: DNL,lookup-key,insertion-datetime * One or more lines with: ,, Where: o , a Domain Name Label covered by a PRM. o , lookup key that the Registry MUST provide to the Registrar. The lookup key has the following format:
////, where: + YYYY: year that the TCN was generated. + MM: zero-padded month that the TCN was generated. Lozano Expires 24 February 2023 [Page 32] Internet-Draft ICANN-TMCH August 2022 + DD: zero-padded day that the TCN was generated. + vv: version of the TCN, possible values are 00 and 01. + X: one hex character. This is the first, second and third hex character of encoding the in base16 as specified in [RFC4648]. + Random bits: 144 random bits encoded in base64url as specified in [RFC4648]. + Sequential number: zero-padded natural number in the range 0000000001 to 2147483647. o , datetime in UTC that the DNL was first inserted into the DNL List. The possible two values of time for inserting a DNL to the DNL List are 00:00:00 and 12:00:00 UTC. Example of a DNL List: 1,2012-08-16T00:00:00.0Z DNL,lookup-key,insertion-datetime example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\ 2010-07-14T00:00:00.0Z another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\ 2012-08-16T00:00:00.0Z anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\ 2011-08-16T12:00:00.0Z To provide authentication and integrity protection, the DNL List will be PGP [RFC4880] signed by the TMDB (see also Section 5.1.1.4). The PGP signature of the DNL List can be found in the similar URI but with extension .sig as shown below. The URL of the dy interface (Section 4.3.3) is: * < https:///dnl/dnl-latest.csv > * < https:///dnl/dnl-latest.sig > Lozano Expires 24 February 2023 [Page 33] Internet-Draft ICANN-TMCH August 2022 6.2. SMD Revocation List This section defines the format of the list of SMDs that have been revoked. The list is maintained by the TMDB and downloaded by Registries (and optionally by Registrars) in regular intervals (see Section 5.2.3.1). The SMD Revocation List is used during the Sunrise Period to validate SMDs received. The SMD Revocation List has a similar function as CRLs used in PKI [RFC5280]. The SMD Revocation List contains all the revoked SMDs present in the TMDB at the datetime it is generated. The SMD Revocation List is contained in a CSV formatted file that has the following structure: * first line: , Where: o , version of the file, this field MUST be 1. o , datetime in UTC that the SMD Revocation List was created. * second line: a header line as specified in [RFC4180] With the header names as follows: smd-id,insertion-datetime * One or more lines with: , Where: o , identifier of the SMD that was revoked. o , revocation datetime in UTC of the SMD. The possible two values of time for inserting an SMD to the SMD Revocation List are 00:00:00 and 12:00:00 UTC. To provide integrity protection, the SMD Revocation List is PGP signed by the TMDB (see also Section 5.1.1.4). The SMD Revocation List is provided by the TMDB with extension .csv. The PGP signature of the SMD Revocation List can be found in the similar URI but with extension .sig as shown below. The URL of the sr interface (Section 4.3.12) and sy interface (Section 4.3.11) is: Lozano Expires 24 February 2023 [Page 34] Internet-Draft ICANN-TMCH August 2022 * < https:///smdrl/smdrl-latest.csv > * < https:///smdrl/smdrl-latest.sig > Example of an SMD Revocation List: 1,2012-08-16T00:00:00.0Z smd-id,insertion-datetime 2-2,2012-08-15T00:00:00.0Z 3-2,2012-08-15T00:00:00.0Z 1-2,2012-08-15T00:00:00.0Z 6.3. List of Registered Domain Names (LORDN) file This section defines the format of the List of Registered Domain Names (LORDN), which is maintained by each Registry and uploaded at least daily to the TMDB. Every time a DN matching a DNL of a PRM said DN is added to the LORDN along with further information related to its registration. The URIs of the yd interface (Section 4.3.7) used to upload the LORDN file is: * Sunrise LORDN file: < https:///LORDN//sunrise > * Trademark Claims LORDN file: < https:///LORDN//claims > During a QLP Period, Registries MAY be required to upload Sunrise or Trademark Claims LORDN files. The URIs of the yd interface used to upload LORDN files during a QLP Period is: * Sunrise LORDN file (during QLP Period): < https:///LORDN//sunrise/qlp > * Trademark Claims LORDN file (during a QLP Period): < https:///LORDN//claims/qlp > The yd interface (Section 4.3.7) returns the following HTTP status codes after a HTTP POST request method is received: Lozano Expires 24 February 2023 [Page 35] Internet-Draft ICANN-TMCH August 2022 * The interface provides a HTTP/202 status code if the interface was able to receive the LORDN file and the syntax of the LORDN file is correct. The interface provides the LORDN Transaction Identifier in the HTTP Entity-body that would be used by the Registry to download the LORDN Log file. The LORDN Transaction Identifier is a natural number zero-padded in the range 0000000000000000001 to 9223372036854775807. The TMDB uses the element of the LORDN file as a unique client-side identifier. If a LORDN file with the same of a previously sent LORDN file is received by the TMDB, the LORDN Transaction Identifier of the previously sent LORDN file MUST be provided to the Registry. The TMDB MUST ignore the DN Lines present in the LORDN file if a LORDN file with the same was previously sent. The HTTP Location header field contains the URI where the LORDN Log file could be retrieved later, for example: 202 Accepted Location: https:///LORDN/example/sunrise/0000000000000000001/result * The interface provides a HTTP/400 if the request is incorrect or the syntax of the LORDN file is incorrect. The TMDB MUST return a human readable message in the HTTP Entity-body regarding the incorrect syntax of the LORDN file. * The interface provides a HTTP/401 status code if the credentials provided does not authorize the Registry Operator to upload a LORDN file. * The TMDB MUST return a HTTP/404 status code when trying to upload a LORDN file using the https:///LORDN//sunrise/qlp or https:///LORDN//claims/qlp interface outside of a QLP Period plus 26 hours. * The interface provides a HTTP/500 status code if the system is experiencing a general failure. For example, to upload the Sunrise LORDN file for TLD "example", the URI would be: Lozano Expires 24 February 2023 [Page 36] Internet-Draft ICANN-TMCH August 2022 < https:///LORDN/example/sunrise > The LORDN is contained in a CSV formatted file that has the following structure: * For Sunrise Period: - first line: ,, Where: + , version of the file, this field MUST be 1. + , date and time in UTC that the LORDN was created. + , number of DN Lines present in the LORDN file. - second line: a header line as specified in [RFC4180] With the header names as follows: roid,domain-name,SMD-id,registrar-id,registration- datetime,application-datetime - One or more lines with: ,,,,, Where: + , DN Repository Object IDentifier (DNROID) in the SRS. + , DN that was effectively allocated. For IDNs, the A-label form is used. + , SMD ID used for registration. + , IANA Registrar ID. + , date and time in UTC that the domain was effectively allocated. Lozano Expires 24 February 2023 [Page 37] Internet-Draft ICANN-TMCH August 2022 + OPTIONAL , date and time in UTC that the application was created. The MUST be provided in case of a DN effective allocation based on an asynchronous registration (e.g., when using auctions). Example of a Sunrise LORDN file: 1,2012-08-16T00:00:00.0Z,3 roid,domain-name,SMD-id,registrar-id,registration-datetime,\ application-datetime SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\ 2012-07-15T00:50:00.0Z EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z * For Trademark Claims Period: - first line: ,, Where: + , version of the file, this field MUST be 1. + , date and time in UTC that the LORDN was created. + , number of DN Lines present in the LORDN file. - second line: a header line as specified in [RFC4180] With the header names as follows: roid,domain-name,notice-id,registrar-id,registration- datetime,ack-datetime,application-datetime - One or more lines with: ,,,,,, Where: + , DN Repository Object IDentifier (DNROID) in the SRS. Lozano Expires 24 February 2023 [Page 38] Internet-Draft ICANN-TMCH August 2022 + , DN that was effectively allocated. For IDNs, the A-label form is used. + , Trademark Claims Notice Identifier as specified in . + , IANA Registrar ID. + , date and time in UTC that the domain was effectively allocated. + , date and time in UTC that the TCN was acknowledged. + OPTIONAL , date and time in UTC that the application was created. The MUST be provided in case of a DN effective allocation based on an asynchronous registration (e.g., when using auctions). For a DN matching a DNL of a PRM at the moment of registration, created without the TCNID, expiration datetime and acceptance datetime, because DNL was inserted (or re- inserted) for the first time into DNL List less than 24 hours ago, the string "recent-dnl-insertion" MAY be specified in and . Example of a Trademark Claims LORDN file: 1,2012-08-16T00:00:00.0Z,3 roid,domain-name,notice-id,registrar-id,registration-datetime,\ ack-datetime,application-datetime SH8013-REP,example1.gtld,a76716ed9223352036854775808,\ 9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z EK77-REP,example2.gtld,a7b786ed9223372036856775808,\ 9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z HB800-REP,example3.gtld,recent-dnl-insertion,\ 9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion 6.3.1. LORDN Log file After reception of the LORDN file, the TMDB verifies its content for syntactical and semantical correctness. The output of the LORDN file verification is retrieved using the yd interface (Section 4.3.7). Lozano Expires 24 February 2023 [Page 39] Internet-Draft ICANN-TMCH August 2022 The URI of the yd interface (Section 4.3.7) used to retrieve the LORDN Log file is: * Sunrise LORDN Log file: < https:///LORDN//sunrise//result > * Trademark Claims LORDN Log file: < https:///LORDN//claims//result > A Registry Operator MUST NOT send more than one request per minute per TLD to download a LORDN Log file. The yd interface (Section 4.3.7) returns the following HTTP status codes after a HTTP GET request method is received: * The interface provides a HTTP/200 status code if the interface was able to provide the LORDN Log file. The LORDN Log file is contained in the HTTP Entity-body. * The interface provides a HTTP/204 status code if the LORDN Transaction Identifier is correct, but the server has not finalized processing the LORDN file. * The interface provides a HTTP/400 status code if the request is incorrect. * The interface provides a HTTP/401 status code if the credentials provided does not authorize the Registry Operator to download the LORDN Log file. * The interface provides a HTTP/404 status code if the LORDN Transaction Identifier is incorrect. * The interface provides a HTTP/500 status code if the system is experiencing a general failure. For example, to obtain the LORDN Log file in case of a Sunrise LORDN file with LORDN Transaction Identifier 0000000000000000001 and TLD "example" the URI would be: < https:///LORDN/example/sunrise/0000000000000000001/result > Lozano Expires 24 February 2023 [Page 40] Internet-Draft ICANN-TMCH August 2022 The LORDN Log file is contained in a CSV formatted file that has the following structure: * first line: ,,,,,, Where: o , version of the file, this field MUST be 1. o , date and time in UTC that the LORDN Log was created. o , date and time in UTC of creation for the LORDN file that this log file is referring to. o , unique identifier of the LORDN Log provided by the TMDB. This identifier could be used by the Registry Operator to unequivocally identify the LORDN Log. The identified will be a string of a maximum LENGTH of 60 characters from the Base 64 alphabet. o , whether the LORDN file has been accepted for processing by the TMDB. Possible values are "accepted" or "rejected". o , whether the LORDN Log has any warning result codes. Possible values are "no-warnings" or "warnings- present". o , number of DNs effective allocations processed in the LORDN file. A Registry Operator is not required to process a LORDN Log with a ="accepted" and ="no-warnings". * second line: a header line as specified in [RFC4180] With the header names as follows: roid,result-code * One or more lines with: , Where: Lozano Expires 24 February 2023 [Page 41] Internet-Draft ICANN-TMCH August 2022 o , DN Repository Object IDentifier (DNROID) in the SRS. o , result code as described in Section 6.3.1.1. Example of a LORDN Log file: 1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\ 0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\ accepted,no-warnings,1 roid,result-code SH8013-REP,2000 6.3.1.1. LORDN Log Result Codes The classes of result codes (rc) are listed below. Those classes in square brackets are not used at this time, but may come into use at some later stage. The first two digits of a result code denote the result code class, which defines the outcome at the TMDB: * ok: Success, DN Line accepted by the TMDB. * warn: a warning is issued, DN Line accepted by the TMDB. * err: an error is issued, LORDN file rejected by the TMDB. In case that after processing a DN Line, the error result code is 45xx or 46xx for that DN Line, the LORDN file MUST be rejected by the TMDB. If the LORDN file is rejected, DN Lines that are syntactically valid will be reported with a 2001 result code. A 2001 result code means that the DN Line is syntactically valid, however the DN Line was not processed because the LORDN file was rejected. All DNs reported in a rejected LORDN file MUST be reported again by the Registry because none of the DN Lines present in the LORDN file have been processed by the TMDB. LORDN Log Result Code Classes: Lozano Expires 24 February 2023 [Page 42] Internet-Draft ICANN-TMCH August 2022 code Class outcome ---- ----- ------- 20xx Success ok 35xx [ DN Line syntax warning ] warn 36xx DN Line semantic warning warn 45xx DN Line syntax error err 46xx DN Line semantic error err In the following, the LORDN Log result codes used by the TMDB are described: LORDN Log Result Codes: rc Short Description Long Description ---- ------------------------------------------------------------- 2000 OK DN Line successfully processed. 2001 OK but not processed DN Line is syntactically correct but was not processed because the LORDN file was rejected. 3601 TCN Acceptance Date after Registration Date TCN Acceptance Date in DN Line is newer than the Registration Date. 3602 Duplicate DN Line This DN Line is an exact duplicate of another DN Line in same file, DN Line ignored. 3603 DNROID Notified Earlier Same DNROID has been notified earlier, DN Line ignored. 3604 TCN Checksum invalid Based on the DN effectively allocated, the TCNID and the expiration date of the linked TCN, the TCN Checksum is invalid. 3605 TCN Expired The TCN was already expired (based on the field of the TCN) at the datetime of acknowledgement. Lozano Expires 24 February 2023 [Page 43] Internet-Draft ICANN-TMCH August 2022 3606 Wrong TCNID used The TCNID used for the registration does not match the related DN. 3609 Invalid SMD used The SMD used for registration was not valid at the moment of registration based on the and elements. In case of an asynchronous registration, this refer to the . 3610 DN reported outside of the time window The DN was reported outside of the required 26 hours reporting window. 3611 DN does not match the labels in SMD The DN does not match the labels included in the SMD. 3612 SMDID does not exist The SMDID has never existed in the central repository. 3613 SMD was revoked when used The SMD used for registration was revoked more than 24 hours ago of the . In case of an asynchronous registration, the is used when validating the DN Line. 3614 TCNID does not exist The TCNID has never existed in the central repository. 3615 Recent-dnl-insertion outside of the time window The DN registration is reported as a recent-dnl-insertion, but the (re) insertion into the DNL occurred more than 24 hours ago. 3616 Registration Date of DN in Claims before the end of Sunrise Period The registration date of the DN is before the end of the Sunrise Period and the DN was reported in a Trademark Claims LORDN file. 3617 Registrar has not been approved by the TMDB Registrar ID in DN Line has not completed Trademark Claims integration testing with the TMDB. 3618 Registration Date of DN in QLP LORDN file out of the QLP Period The registration date of the DN in a QLP LORDN file is outside of the QLP Period. Lozano Expires 24 February 2023 [Page 44] Internet-Draft ICANN-TMCH August 2022 3619 TCN was not valid The TCN was not valid (based on the field of the TCN) at the datetime of acknowledgement. 4501 Syntax Error in DN Line Syntax Error in DN Line. 4601 Invalid TLD used The TLD in the DN Line does not match what is expected for this LORDN. 4602 Registrar ID Invalid Registrar ID in DN Line is not a valid ICANN-Accredited Registrar. 4603 Registration Date in the future The in the DN Line is in the future. 4606 TLD not in Sunrise or Trademark Claims Period The was reported when the TLD was not in Sunrise or Trademark Claims Periods. In case of an asynchronous registration, the is used when validating the DN Line. 4607 Application Date in the future The in the DN Line is in the future. 4608 Application Date is later than Registration Date The in the DN Line is later than the . 4609 TCNID wrong syntax The syntax of the TCNID is invalid. 4610 TCN Acceptance Date is in the future The is in the future. 4611 Label has never existed in the TMDB The label in the registered DN has never existed in the TMDB. Lozano Expires 24 February 2023 [Page 45] Internet-Draft ICANN-TMCH August 2022 6.4. Signed Mark Data (SMD) File This section defines the format of the Signed Mark Data (SMD) File. After a successful registration of a mark, the TMV returns an SMD File to the TMH. The SMD File can then be used for registration of one or more DNs covered by the PRM during the Sunrise Period of a TLD. Two encapsulation boundaries are defined for delimiting the encapsulated base64 encoded SMD: i.e. "-----BEGIN ENCODED SMD-----" and "-----END ENCODED SMD-----". Only data inside the encapsulation boundaries MUST be used by Registries and Registrars for validation purposes, i.e. any data outside these boundaries as well as the boundaries themselves MUST be ignored for validation purposes. The structure of the SMD File is as follows, all the elements are REQUIRED, and MUST appear in the specified order. 1. Marks: 2. smdID: 3. U-labels: 4. notBefore: 5. notAfter: 6. -----BEGIN ENCODED SMD----- 7. 8. -----END ENCODED SMD----- Example of an SMD File: Lozano Expires 24 February 2023 [Page 46] Internet-Draft ICANN-TMCH August 2022 Marks: Example One smdID: 1-2 U-labels: example-one, exampleone notBefore: 2011-08-16 09:00 notAfter: 2012-08-16 09:00 -----BEGIN ENCODED SMD----- PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN ... (base64 data elided for brevity) ... dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo= -----END ENCODED SMD----- 6.5. Trademark Claims Notice (TCN) The TMDB MUST provide the TCN to Registrars in XML format as specified below. An enclosing element that describes the Trademark Notice to a given label. The child elements of the element include: * A element that contains the unique identifier of the Trademark Notice. This element contains the the TCNID. The TCNID is a string concatenation of a TCN Checksum and the TMDB Notice Identifier. The first 8 characters of the TCNID is a TCN Checksum. The rest is the TMDB Notice Identifier, which is a zero-padded natural number in the range of 0000000000000000001 to 9223372036854775807. Example of a TCNID: 370d0b7c9223372036854775807. Where: o TCN Checksum=370d0b7c o TMDB Notice Identifier=9223372036854775807 The TCN Checksum is a 8 characters long Base16 encoded output of computing the CRC32 of the string concatenation of: label + unix_timestamp() + TMDB Notice Identifier Lozano Expires 24 February 2023 [Page 47] Internet-Draft ICANN-TMCH August 2022 TMDB MUST use the Unix time conversion of the in UTC to calculate the TCN Checksum. Unix time is defined as the number of seconds that have elapsed since 1970-01-01T00:00:00Z not counting leap seconds. For example, the conversion to Unix time of 2010-08-16T09:00:00.0Z is shown: unix_time(2010-08-16T09:00:00.0Z)=1281949200 The TMDB uses the and elements from the TCN along with the TMDB Notice Identifier to compute the TCN Checksum. A Registry MUST use the leftmost DNL of the DN being effectively allocated, the expiration datetime of the TCN (provided by the Registrar) and the TMDB Notice Identifier extracted from the TCNID (provided by the Registrar) to compute the TCN Checksum. For example, if the DN "xn--mgbachtv.xn-- mgbh0fb" is being effectively allocated, the leftmost DNL would be "xn--mgbachtv". Example of computation of the TCN Checksum: CRC32(example-one12819492009223372036854775807)=370d0b7c * A element that contains the start of the validity date and time of the TCN. * A element that contains the expiration date and time of the TCN. * A element that contains the DNL covered by a PRM. * One or more elements that contain the Trademark Claim. The element contains the following child elements: - A element that contains the mark text string. - One or more elements that contains the information of the holder of the mark. An "entitlement" attribute is used to identify the entitlement of the holder, possible values are: owner, assignee or licensee. The child elements of include: Lozano Expires 24 February 2023 [Page 48] Internet-Draft ICANN-TMCH August 2022 o An OPTIONAL element that contains the name of the holder. A MUST be specified if is not specified. o An OPTIONAL element that contains the name of the organization holder of the mark. A MUST be specified if is not specified. o A element that contains the address information of the holder of a mark. A contains the following child elements: + One, two or three OPTIONAL elements that contains the organization's street address. + A element that contains the organization's city. + An OPTIONAL element that contains the organization's state or province. + An OPTIONAL element that contains the organization's postal code. + A element that contains the organization's country code. This a two-character code from [ISO3166-2]. o An OPTIONAL element that contains the organization's voice telephone number. o An OPTIONAL element that contains the organization's facsimile telephone number. o An OPTIONAL element that contains the email address of the holder. - Zero or more OPTIONAL elements that contains the information of the representative of the mark registration. A "type" attribute is used to identify the type of contact, possible values are: owner, agent or thirdparty. The child elements of include: o A element that contains name of the responsible person. o An OPTIONAL element that contains the name of the organization of the contact. Lozano Expires 24 February 2023 [Page 49] Internet-Draft ICANN-TMCH August 2022 o A element that contains the address information of the contact. A contains the following child elements: + One, two or three OPTIONAL elements that contains the contact's street address. + A element that contains the contact's city. + An OPTIONAL element that contains the contact's state or province. + An OPTIONAL element that contains the contact's postal code. + A element that contains the contact's country code. This a two-character code from [ISO3166-2]. o A element that contains the contact's voice telephone number. o An OPTIONAL element that contains the contact's facsimile telephone number. o A element that contains the contact's email address. - A element that contains the name (in English) of the jurisdiction where the mark is protected. A jurCC attribute contains the two-character code of the jurisdiction where the mark was registered. This is a two- character code from [WIPO.ST3]. - Zero or more OPTIONAL element that contains the description (in English) of the Nice Classification as defined in [WIPO-NICE-CLASSES]. A classNum attribute contains the class number. - A element that contains the full description of the goods and services mentioned in the mark registration document. - An OPTIONAL element signals that the claim notice was added to the TCN based on other rule (e.g. [Claims50] ) than exact match (defined in [MatchingRules]). The contains one or more: Lozano Expires 24 February 2023 [Page 50] Internet-Draft ICANN-TMCH August 2022 o An OPTIONAL element that signals that the claim notice was added because of a previously abused name included in an UDRP case. The contains: + A element that contains the UDRP case number used to validate the previously abused name. + A element that contains the name of the UDRP provider. o An OPTIONAL element that signals that the claim notice was added because of a previously abused name included in a court's resolution. The contains: + A element that contains the reference number of the court's resolution used to validate the previously abused name. + A element that contains the two-character code from [ISO3166-2] of the jurisdiction of the court. + A element that contains the name of the court. Example of a object: 370d0b7c9223372036854775807 2010-08-14T09:00:00.0Z 2010-08-16T09:00:00.0Z example-one Example One Example Inc. 123 Example Dr. Suite 100 Reston VA 20190 US Joe Doe Lozano Expires 24 February 2023 [Page 51] Internet-Draft ICANN-TMCH August 2022 Example Inc. 123 Example Dr. Suite 100 Reston VA 20190 US +1.7035555555 jdoe@example.com USA Advertising; business management; business administration. Insurance; financial affairs; monetary affairs; real estate. Bardus populorum circumdabit se cum captiosus populum. Smert populorum circumdabit se cum captiosus populum. Example-One Example S.A. de C.V. Calle conocida #343 Conocida SP 82140 BR BRAZIL Bardus populorum circumdabit se cum captiosus populum. Smert populorum circumdabit se cum captiosus populum. One One Corporation Otra calle Lozano Expires 24 February 2023 [Page 52] Internet-Draft ICANN-TMCH August 2022 Otra ciudad OT 383742 CR COSTA RICA Bardus populorum circumdabit se cum captiosus populum. Smert populorum circumdabit se cum captiosus populum. 234235 CR Supreme Court of Spain One Inc One SA de CV La calle La ciudad CD 34323 AR ARGENTINA Bardus populorum circumdabit se cum captiosus populum. Smert populorum circumdabit se cum captiosus populum. D2003-0499 WIPO For the formal syntax of the TCN please refer to Section 7.1. Lozano Expires 24 February 2023 [Page 53] Internet-Draft ICANN-TMCH August 2022 6.6. Sunrise List (SURL) This section defines the format of the list containing every Domain Name Label (DNL) that matches a PRM eligible for Sunrise. The list is maintained by the TMDB and downloaded by Registries in regular intervals (see Section 5.4.2.1). The Registries use the Sunrise List during the Qualified Launch Program Period to check whether a requested DN matches a DNL of a PRM eligible for Sunrise. The Sunrise List contains all the DNLs covered by a PRM eligible for Sunrise present in the TMDB at the datetime it is generated. The Sunrise List is contained in a CSV formatted file that has the following structure: * first line: , Where: o , version of the file, this field MUST be 1. o , date and time in UTC that the Sunrise List was created. * second line: a header line as specified in [RFC4180] With the header names as follows: DNL,insertion-datetime * One or more lines with: , Where: o , a Domain Name Label covered by a PRM eligible for Sunrise. o , datetime in UTC that the DNL was first inserted into the Sunrise List. The possible two values of time for inserting a DNL to the Sunrise List are 00:00:00 and 12:00:00 UTC. Example of a Sunrise List: Lozano Expires 24 February 2023 [Page 54] Internet-Draft ICANN-TMCH August 2022 1,2012-08-16T00:00:00.0Z DNL,insertion-datetime example,2010-07-14T00:00:00.0Z another-example,2012-08-16T00:00:00.0Z anotherexample,2011-08-16T12:00:00.0Z To provide authentication and integrity protection, the Sunrise List will be PGP signed by the TMDB (see also Section 5.1.1.4). The PGP signature of the Sunrise List can be found in the similar URI but with extension .sig as shown below. The URL of the dy interface (Section 4.3.3) is: * < https:///dnl/surl-latest.csv > * < https:///dnl/surl-latest.sig > 7. Formal Syntax 7.1. Trademark Claims Notice (TCN) The schema presented here is for a Trademark Claims Notice. The CODE BEGINS and CODE ENDS tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes. Schema for representing a Trademark Claim Notice. Lozano Expires 24 February 2023 [Page 55] Internet-Draft ICANN-TMCH August 2022 Lozano Expires 24 February 2023 [Page 56] Internet-Draft ICANN-TMCH August 2022 Lozano Expires 24 February 2023 [Page 57] Internet-Draft ICANN-TMCH August 2022 8. Acknowledgements This specification is a collaborative effort from several participants in the ICANN community. Bernie Hoeneisen participated as co-author until version 02 providing invaluable support for this document. This specification is based on a model spearheaded by: Chris Wright, Jeff Neuman, Jeff Eckhaus and Will Shorter. The author would also like to thank the thoughtful feedbak provided by many in the tmch-tech mailing list, but particularly the extensive help provided by James Gould, James Mitchell and Francisco Arias. This document includes feedback received from the following individuals: Paul Hoffman. 9. Change History [[RFC Editor: Please remove this section.]] 9.1. Version 04 1. Ping update. 9.2. Version 05 1. Ping update. 9.3. Version 06 1. Updated the terminology text to reflect the text in RFC8174. 2. Updated the reference of RFC7719 to RFC8499. 3. Updated the matching rules document reference to link to the latest version. 9.4. Version 07 1. Changes based on the feedback provided here: https://mailarchive.ietf.org/arch/msg/regext/ xcZPOAajlUJzgPgZBuqlIWRcFZg/ 2. Changes based on the feedback provided here: https://mailarchive.ietf.org/arch/msg/regext/ MdOhSomd6_djLcthfw5mxWZkbWY 9.5. Version 08 1. Fixed issues detected by idnits tool. Lozano Expires 24 February 2023 [Page 58] Internet-Draft ICANN-TMCH August 2022 9.6. Version 09 1. Ping update. 9.7. Version 10 1. Ping update. 9.8. Version 11 1. Editorial updates. 2. Added Privacy section. 9.9. Version 12 1. Editorial updates. 9.10. Version 13 1. Editorial updates. 9.11. Version 14 1. Editorial updates. 9.12. Version 15 1. Ping update. 10. IANA Considerations The code point assigned in support of this document is taken from the wrong point in the registration tree. Unfortunately, the code point has already been deployed in the field without following the proper registration review process. The Designated Experts for the registry have considered the issues that correcting this action would cause for deployed implementations and have consented to the continued use of the code point. This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. IANA is requested to register two URI assignments. Registration request for the Trademark Claims Notice namespace: URI: urn:ietf:params:xml:ns:tmNotice-1.0 Lozano Expires 24 February 2023 [Page 59] Internet-Draft ICANN-TMCH August 2022 Registrant Contact: IETF ICANN XML: None. Namespace URIs do not represent an XML specification. Note: Note that this assignment is made from the wrong point in the tree in order to be consistent with deployed implementations. Registration request for the Trademark Claims Notice XML schema: URI: urn:ietf:params:xml:schema:tmNotice-1.0 Registrant Contact: IETF ICANN XML: See Section 7.1 of this document. Note: Note that this assignment is made from the wrong point in the tree in order to be consistent with deployed implementations. 11. Security Considerations This specification uses HTTP Basic Authentication to provide a simple application-layer authentication service. HTTPS is used in all interfaces in order to protect against most common attacks. In addition, the client identifier is tied to a set of IP addresses that are allowed to connect to the interfaces described in this document, providing an extra security measure. The TMDB MUST provide credentials to the appropriate Registries and Registrars. The TMDB MUST require the use of strong passwords by Registries and Registrars. The TMDB, Registries and Registrars MUST use the best practices described in [RFC7525] or its successors. 12. Privacy Considerations This specification defines the interfaces to support the [RPM-Requirements]. Legal documents govern the interactions between the different parties, and such legal documents must ensure that privacy-sensitive and/or personal data receives the required protection. 13. References Lozano Expires 24 February 2023 [Page 60] Internet-Draft ICANN-TMCH August 2022 13.1. Normative References [Claims50] ICANN, "Implementation Notes: Trademark Claims Protection for Previously Abused Names", 16 July 2013, . [MatchingRules] ICANN, "Memorandum on Implementing Matching Rules", 14 July 2016, . [QLP-Addendum] ICANN, "Qualified Launch Program Addendum", 10 April 2014, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", RFC 7848, DOI 10.17487/RFC7848, June 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RPM-Requirements] ICANN, "Rights Protection Mechanism Requirements", 30 September 2013, . Lozano Expires 24 February 2023 [Page 61] Internet-Draft ICANN-TMCH August 2022 [W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition) REC-xml-20081126", November 2008, . [W3C.REC-xmlschema-1-20041028] Thompson, H. S., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition REC-xmlschema-1-20041028", October 2004, . [W3C.REC-xmlschema-2-20041028] Biron, P. V. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition REC-xmlschema-2-20041028", October 2004, . 13.2. Informative References [ICANN-GTLD-AGB-20120604] ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 4 June 2012, . [ISO3166-2] ISO, "International Standard for country codes and codes for their subdivisions", 2006, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- Separated Values (CSV) Files", RFC 4180, DOI 10.17487/RFC4180, October 2005, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . Lozano Expires 24 February 2023 [Page 62] Internet-Draft ICANN-TMCH August 2022 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . [WIPO-NICE-CLASSES] WIPO, "WIPO Nice Classification", 2015, . [WIPO.ST3] WIPO, "Recommended standard on two-letter codes for the representation of states, other entities and intergovernmental organizations", March 2007, . Author's Address Lozano Expires 24 February 2023 [Page 63] Internet-Draft ICANN-TMCH August 2022 Gustavo Lozano ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, 90292 United States of America Phone: +1.3103015800 Email: gustavo.lozano@icann.org Lozano Expires 24 February 2023 [Page 64] ./draft-ietf-rmcat-rtp-cc-feedback-12.txt0000644000764400076440000014152714351022335017675 0ustar iustiniustin Network Working Group C. S. Perkins Internet-Draft University of Glasgow Intended status: Informational 21 December 2022 Expires: 24 June 2023 Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences draft-ietf-rmcat-rtp-cc-feedback-12 Abstract This memo discusses the rate at which congestion control feedback can be sent using the RTP Control Protocol (RTCP) and its suitability for implementing congestion control for unicast multimedia applications. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Perkins Expires 24 June 2023 [Page 1] Internet-Draft RTCP Feedback for Congestion Control December 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Considerations for RTCP Feedback . . . . . . . . . . . . . . 3 3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 5 3.1. Scenario 1: Voice Telephony . . . . . . . . . . . . . . . 5 3.2. Scenario 2: Point-to-Point Video Conference . . . . . . . 10 4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 8. Normative References . . . . . . . . . . . . . . . . . . . . 17 9. Informative References . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The deployment of WebRTC systems [RFC8825] has resulted in high- quality video conferencing seeing extremely wide use. To ensure the stability of the network in the face of this use, WebRTC systems need to use some form of congestion control for their RTP-based media traffic [RFC2914], [RFC8085], [RFC8083], [RFC8834], allowing them to adapt and adjust the media data they send to match changes in the available network capacity. In addition to ensuring the stable operation of the network, such adaptation is critical to ensuring a good user experience, since it allows the sender to match the media to the network capacity, rather than forcing the receiver to compensate for uncontrolled packet loss when the available capacity is exceeded. To develop such congestion control, it is necessary to understand the sort of congestion feedback that can be provided within the framework of RTP [RFC3550] and the RTP Control Protocol (RTCP). It then becomes possible to determine if this is sufficient for congestion control, or if some form of RTP extension is needed. As this memo will show, if it is desired to use RTCP in something close to its current form for congestion feedback, the multimedia congestion control algorithm needs to be designed to work with detailed feedback sent every few frames, rather than per-frame acknowledgement, to match the constraints of RTCP. This memo considers unicast congestion feedback that can be sent using RTCP under the RTP/SAVPF profile [RFC5124] (the secure version of the RTP/AVPF profile [RFC4585]). This profile was chosen as it forms the basis for media transport in WebRTC [RFC8834] systems. Nothing in this memo is specific to the secure version of the profile, or to WebRTC, however. It is also assumed that the Perkins Expires 24 June 2023 [Page 2] Internet-Draft RTCP Feedback for Congestion Control December 2022 congestion control feedback mechanism described in [RFC8888], and common RTCP extensions for efficient feedback [RFC5506], [RFC8108], [RFC8861], and [RFC8872] are used. 2. Considerations for RTCP Feedback Several questions need to be answered when providing RTCP feedback for congestion control purposes. These include: * How often is feedback needed? * How much overhead is acceptable? * How much, and what, data does each report contain? The key question is how often does the receiver need to send feedback on the reception quality it is experiencing and hence the congestion state of the network? Widely used transport protocols, such as TCP, send acknowledgements frequently. For example, a TCP receiver will send an acknowledgement at least once every 0.5 seconds or when new data equal to twice the maximum segment size has been received [RFC9293]). That has relatively low overhead when traffic is bidirectional and acknowledgements can be piggybacked onto return path data packets. It can also be acceptable, and can have reasonable overhead, to send separate acknowledgement packets when those packets are much smaller than data packets. Frequent acknowledgements can become a problem, however, when there is no return traffic on which to piggyback feedback, or if separate feedback and data packets are sent and the feedback is similar in size to the data being acknowledged. This can be the case for some forms of media traffic, especially for voice over IP flows, leading to high overhead when using a transport protocol that sends frequent feedback. Approaches like in-network filtering of acknowledgements that have been proposed to reduce acknowledgement overheads on highly asymmetric links (e.g., as mentioned in [RFC3449]) can also reduce the feedback frequency and overhead for multimedia traffic, but this so-called "stretch-ACK" behaviour is non-standard and not guaranteed. Accordingly, when implementing congestion control for RTP-based multimedia traffic, it might make sense to give the option of sending congestion feedback less often than TCP does. For example, it might be possible to send a feedback packet once per video frame, or every few frames, or once per network round trip time (RTT). This could still give sufficiently frequent feedback for the congestion control loop to be stable and responsive while keeping the overhead Perkins Expires 24 June 2023 [Page 3] Internet-Draft RTCP Feedback for Congestion Control December 2022 reasonable when the feedback cannot be piggybacked onto returning data. In this case, it is important to note that RTCP can send much more detailed feedback than simple acknowledgements. For example, if it were useful, it could be possible to use an RTCP extended report (XR) packet [RFC3611] to send feedback once per RTT comprising a bitmap of lost and received packets, with reception times, over that RTT. As long as feedback is sent frequently enough that the control loop is stable, and the sender is kept informed when data leaves the network (to provide an equivalent to ACK clocking in TCP), it is not necessary to report on every packet at the instant it is received. Indeed, it is unlikely that a video codec can react instantly to a rate change, and there is little point in providing feedback more often than the codec can adapt. This suggests that an RTP receiver needs to be configured to provide feedback at a rate that matches the rate of adaptation of the sender. In the best case, this will match the media frame rate, but might often be slower. Reducing the feedback frequency compared to TCP will reduce feedback overhead but will lead multimedia flows to adapt to congestion more slowly than TCP, raising concerns about inter-flow fairness. Similar concerns are noted in [RFC5348], and accordingly the congestion control algorithm described therein aims for "reasonable" fairness and a sending rate that is "generally within a factor of two" of that TCP would achieve under the same conditions. It is to be noted, however, that TCP exhibits inter-flow unfairness when flows with differing round-trip times compete, and stretch acknowledgements due to in-network traffic manipulation are not uncommon and also raise fairness concerns. Implementations need to balance potential unfairness against feedback overhead. Generating and processing feedback consumes resources at the sender and receiver. The feedback packets also incur forwarding costs, contribute to link utilization, and can affect the timing of other traffic on the network. This can affect performance on some types of network, that can be impacted by the rate, timing, and size of feedback packets, as well as by the overall volume of feedback bytes. The amount of overhead due to congestion control feedback that is considered acceptable has to be determined. RTCP feedback is sent in separate packets to RTP data, and this has some cost in terms of additional header overhead compared to protocols that piggyback feedback on return path data packets. The RTP standards have long said that a 5% overhead for RTCP traffic is generally acceptable, while providing the ability to change this fraction. Is this still the case for congestion control feedback? Is there a desire to provide more responsive feedback and congestion control, possibly with a higher overhead? Or is lower overhead wanted, accepting that this might reduce responsiveness of the congestion control algorithm? Perkins Expires 24 June 2023 [Page 4] Internet-Draft RTCP Feedback for Congestion Control December 2022 Finally, the details of how much, and what, data is to be sent in each report will affect the frequency and/or overhead of feedback. There is a fundamental trade-off that the more frequently feedback packets are sent, the less data can be included in each packet to keep the overhead constant. Does the congestion control need high rate but simple feedback (e.g., like TCP acknowledgements), or is it acceptable to send more complex feedback less often? Is it useful for the congestion control to receive frequent feedback, perhaps to provide more accurate round-trip time estimates, or to provide robustness in case feedback packets are lost, even if the media sending rate cannot quickly be changed? Or is low-rate feedback, resulting in slowly responsive changes to the sending rate, acceptable? Different combinations of congestion control algorithm and media codec might require different trade-offs, and the correct trade-off for interactive, self-paced, real-time multimedia traffic might not be the same as that for TCP congestion control. 3. What Feedback is Achievable With RTCP? The following sections illustrate how the RTCP congestion control feedback report [RFC8888] can be used in different scenarios, and illustrate the overheads of this approach. 3.1. Scenario 1: Voice Telephony In many ways, point-to-point voice telephony is the simplest scenario for congestion control, since there is only a single media stream to control. It's complicated, however, by severe bandwidth constraints on the feedback, to keep the overhead manageable. Assume a two-party point-to-point voice-over-IP call, using RTP over UDP/IP. A rate adaptive speech codec, such as Opus, is used, encoded into RTP packets in frames of duration Tf seconds (Tf = 0.020s in many cases, but values up to 0.060s are not uncommon). The congestion control algorithm requires feedback every Nr frames, i.e., every Nr * Tf seconds, to ensure effective control. Both parties in the call send speech data or comfort noise with sufficient frequency that they are counted as senders for the purpose of the RTCP reporting interval calculation. RTCP feedback packets can be full, compound, RTCP feedback packets, or reduced-size RTCP packets [RFC5506]. A compound RTCP packet is sent once for every Nrs reduced-size RTCP packets. Perkins Expires 24 June 2023 [Page 5] Internet-Draft RTCP Feedback for Congestion Control December 2022 Compound RTCP packets contain a Sender Report (SR) packet, a Source Description (SDES) packet, and an RTP Congestion Control Feedback (CCFB) packet [RFC8888]. Reduced-size RTCP packets contain only the CCFB packet. Since each participant sends only a single RTP media stream, the extensions for RTCP report aggregation [RFC8108] and reporting group optimisation [RFC8861] are not used. Within each compound RTCP packet, the SR packet will contain a sender information block (28 octets) and a single reception report block (24 octets), for a total of 52 octets. A minimal SDES packet will contain a header (4 octets) and a single chunk containing an SSRC (4 octets) and a CNAME item, and if the recommendations for choosing the CNAME [RFC7022] are followed, the CNAME item will comprise a 2-octet header, 16 octets of data, and 2 octets of padding, for a total SDES packet size of 28 octets. The CCFB packets contain an RTCP header and SSRC (8 octets), a report timestamp (4 octets), the SSRC, beginning and ending sequence numbers (8 octets), and 2*Nr octets of reports, for a total of 20 + 2*Nr octets. The compound Secure RTCP packet will include 4 octets of trailer followed by an 80 bit (10 octet) authentication tag if HMAC-SHA1 authentication is used. If IPv4 is used, with no IP options, the UDP/IP header will be 28 octets in size. This gives a total compound RTCP packet size of Sc = 142 + 2*Nr octets. The reduced-size RTCP packets will comprise just the CCFB packet, SRTCP trailer and authentication tag, and a UDP/IP header. It can be seen that these packets will be Srs = 62 + 2*Nr octets in size. The RTCP reporting interval calculation ([RFC3550], Section 6.2) for a two-party session where both participants are senders, reduces to: | Trtcp = n * Srtcp / Brtcp where Srtcp = (Sc + Nrs * Srs)/(1 + Nrs) is the average RTCP packet size in octets, Brtcp is the bandwidth allocated to RTCP in octets per second, and n is the number of participants in the RTP session (in this scenario, n = 2). To ensure an RTCP report containing congestion control feedback is sent after every Nr frames of audio, it is necessary to set the RTCP reporting interval Trtcp = Nr * Tf, which when substituted into the previous gives Nr * Tf = n * Srtcp/Brtcp. Solving this to give the RTCP bandwidth, Brtcp, and expanding the definition of Srtcp gives: | Brtcp = (n * (Sc + Nrs * Srs))/(Nr * Tf * (1 + Nrs)). Perkins Expires 24 June 2023 [Page 6] Internet-Draft RTCP Feedback for Congestion Control December 2022 If we assume every report is a compound RTCP packet (i.e., Nrs = 0), the frame duration Tf = 20ms, and an RTCP report is sent for every second frame (i.e., 25 RTCP reports per second), this gives an RTCP feedback bandwidth, Brtcp = 57kbps. Increasing the frame duration, or reducing the frequency of reports, will reduce the RTCP bandwidth as shown in Table 1. +--------------+-------------+----------------+ | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | +--------------+-------------+----------------+ | 0.020 | 2 | 57.0 | +--------------+-------------+----------------+ | 0.020 | 4 | 29.3 | +--------------+-------------+----------------+ | 0.020 | 8 | 15.4 | +--------------+-------------+----------------+ | 0.020 | 16 | 8.5 | +--------------+-------------+----------------+ | 0.060 | 2 | 19.0 | +--------------+-------------+----------------+ | 0.060 | 4 | 9.8 | +--------------+-------------+----------------+ | 0.060 | 8 | 5.1 | +--------------+-------------+----------------+ | 0.060 | 16 | 2.8 | +--------------+-------------+----------------+ Table 1: RTCP bandwidth needed for VoIP feedback (compound reports only) The final row of Table 1 (60ms frames, report every 16 frames) sends RTCP reports once per second, giving an RTCP bandwidth overhead of 2.8kbps. The overhead can be reduced by sending some reports in reduced-size RTCP packets [RFC5506]. For example, if we alternate compound and reduced-size RTCP packets, i.e., Nrs = 1, the calculation gives the results shown in Table 2. Perkins Expires 24 June 2023 [Page 7] Internet-Draft RTCP Feedback for Congestion Control December 2022 +--------------+-------------+----------------+ | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | +--------------+-------------+----------------+ | 0.020 | 2 | 41.4 | +--------------+-------------+----------------+ | 0.020 | 4 | 21.5 | +--------------+-------------+----------------+ | 0.020 | 8 | 11.5 | +--------------+-------------+----------------+ | 0.020 | 16 | 6.5 | +--------------+-------------+----------------+ | 0.060 | 2 | 13.8 | +--------------+-------------+----------------+ | 0.060 | 4 | 7.2 | +--------------+-------------+----------------+ | 0.060 | 8 | 3.8 | +--------------+-------------+----------------+ | 0.060 | 16 | 2.2 | +--------------+-------------+----------------+ Table 2: Required RTCP bandwidth for VoIP feedback (alternating compound and reduced- size reports) The RTCP bandwidth needed for 60ms frames, reporting every 16 frames (once per second), can be seen to drop to 2.2kbps. This calculation can be repeated for other patterns of compound and reduced-size RTCP packets, feedback frequency, and frame duration, as needed. Note: To achieve the RTCP transmission intervals above the RTP/SAVPF profile with T_rr_interval=0 is used, since even when using the reduced minimal transmission interval, the RTP/SAVP profile would only allow sending RTCP at most every 0.11s (every third frame of video). Using RTP/SAVPF with T_rr_interval=0 however is capable of fully utilizing the configured 5% RTCP bandwidth fraction. The use of IPv6 will increase the overhead by 20 octets per packet, due to the increased size of the IPv6 header compared to IPv4, assuming no IP options in either case. This increases the size of compound packets to Sc = 162 + 2*Nr octets and reduced size packets to Srs = 82 + 2*Nr. Re-running the calculations from Table 1 with these packet sizes gives the results shown in Table 3. As can be seen, there is a significant increase in overhead due to the use of IPv6. Perkins Expires 24 June 2023 [Page 8] Internet-Draft RTCP Feedback for Congestion Control December 2022 +--------------+-------------+----------------+ | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | +--------------+-------------+----------------+ | 0.020 | 2 | 64.8 | +--------------+-------------+----------------+ | 0.020 | 4 | 33.2 | +--------------+-------------+----------------+ | 0.020 | 8 | 17.4 | +--------------+-------------+----------------+ | 0.020 | 16 | 9.5 | +--------------+-------------+----------------+ | 0.060 | 2 | 21.6 | +--------------+-------------+----------------+ | 0.060 | 4 | 11.1 | +--------------+-------------+----------------+ | 0.060 | 8 | 5.8 | +--------------+-------------+----------------+ | 0.060 | 16 | 3.2 | +--------------+-------------+----------------+ Table 3: RTCP bandwidth needed for VoIP feedback (compound reports only) using IPv6 Repeating the calculations from Table 2 using IPv6 gives the results shown in Table 4. As can be seen, the overhead still increases with IPv6 when a mix of compound and reduced-size reports is used, but the effect is less pronounced than with compound reports only. Perkins Expires 24 June 2023 [Page 9] Internet-Draft RTCP Feedback for Congestion Control December 2022 +--------------+-------------+----------------+ | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | +--------------+-------------+----------------+ | 0.020 | 2 | 49.2 | +--------------+-------------+----------------+ | 0.020 | 4 | 25.4 | +--------------+-------------+----------------+ | 0.020 | 8 | 13.5 | +--------------+-------------+----------------+ | 0.020 | 16 | 7.5 | +--------------+-------------+----------------+ | 0.060 | 2 | 16.4 | +--------------+-------------+----------------+ | 0.060 | 4 | 8.5 | +--------------+-------------+----------------+ | 0.060 | 8 | 4.5 | +--------------+-------------+----------------+ | 0.060 | 16 | 2.5 | +--------------+-------------+----------------+ Table 4: Required RTCP bandwidth for VoIP feedback (alternating compound and reduced- size reports) using IPv6 3.2. Scenario 2: Point-to-Point Video Conference Consider a point-to-point video call between two end systems. There will be four RTP flows in this scenario, two audio and two video, with all four flows being active for essentially all the time (the audio flows will likely use voice activity detection and comfort noise to reduce the packet rate during silent periods, but this does not cause the transmissions to stop). Assume all four flows are sent in a single RTP session, each using a separate SSRC. The RTCP reports from the co-located audio and video SSRCs at each end point are aggregated [RFC8108], the optimisations in [RFC8861] are used, and RTCP congestion control feedback is sent [RFC8888]. As in Section 3.1, when all members are senders the RTCP reporting interval calculation in Section 6.2 and 6.3 of [RFC3550] and [RFC4585] reduces to: | Trtcp = n * Srtcp / Brtcp where n is the number of members in the session, Srtcp is the average RTCP packet size in octets, and the Brtcp is the RTCP bandwidth in octets per second. Perkins Expires 24 June 2023 [Page 10] Internet-Draft RTCP Feedback for Congestion Control December 2022 The average RTCP packet size, Srtcp, depends on the amount of feedback sent in each RTCP packet, on the number of members in the session, on the size of source description (RTCP SDES) information sent, and on the amount of congestion control feedback sent in each packet. As a baseline, each RTCP packet will be a compound RTCP packet that contains an aggregate of a compound RTCP packet generated by the video SSRC and a compound RTCP packet generated by the audio SSRC. When the RTCP reporting group extensions are used, one of these SSRCs will be a reporting SSRC, to which the other SSRC will have delegated its reports. No reduced-size RTCP packets are sent. The aggregated compound RTCP packet from the non-reporting SSRC will contain an RTCP SR packet, an RTCP SDES packet, and an RTCP RGRS packet. The RTCP SR packet contains the 28 octet UDP/IP header (assuming IPv4 with no options) and sender information, but no report blocks (since the reporting is delegated). The RTCP SDES packet will comprise a header (4 octets), originating SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding. If the CNAME follows [RFC7022] and [RFC8834] the CNAME chunk will be 18 octets in size, and will be followed by one octet of padding and one terminating null octet to align the SDES packet to a 32-bit boundary ([RFC3550], section 6.5), making the SDES packet 28 octets in size. The RTCP RGRS packet will be 12 octets in size. This gives a total of 28 + 28 + 12 = 68 octets. The aggregated compound RTCP packet from the reporting SSRC will contain an RTCP SR packet, an RTCP SDES packet, and an RTCP congestion control feedback packet. The RTCP SR packet will contain two report blocks, one for each of the remote SSRCs (the report for the other local SSRC is suppressed by the reporting group extension), for a total of 28 + (2 * 24) = 76 octets. The RTCP SDES packet will comprise a header (4 octets), originating SSRC (4 octets), a CNAME chunk, an RGRP chunk, a terminating chunk, and any padding. If the CNAME follows [RFC7022] and [RFC8834] it will be 18 octets in size. The RGRP chunk similarly comprises 18 octets, and 3 octets of padding are needed, for a total of 48 octets. The RTCP congestion control feedback (CCFB) report comprises an 8-octet RTCP header and SSRC, a 4-octet report timestamp, and for each of the remote audio and video SSRCs, an 8-octet report header, and 2 octets per packet reported upon, and padding to a 4-octet boundary if needed; that is 8 + 4 + 8 + (2 * Nv) + 8 + (2 * Na) where Nv is the number of video packets per report, and Na is the number of audio packets per report. The complete compound RTCP packet contains the RTCP packets from both the reporting and non-reporting SSRCs, an SRTCP trailer and authentication tag, and a UDP/IPv4 header. The size of this RTCP Perkins Expires 24 June 2023 [Page 11] Internet-Draft RTCP Feedback for Congestion Control December 2022 packet is therefore: 262 + (2 * Nv) + (2 * Na) octets. Since the aggregate RTCP packet contains reports from two SSRCs, the RTCP packet size is halved before use [RFC8108]. Accordingly, the size of the RTCP packets is: | Srtcp = (262 + (2 * Nv) + (2 * Na)) / 2 How many RTP packets does the RTCP XR congestion control feedback packet, included in these compound RTCP packets, report on? That is, what are the values of Nv and Na? This depends on the RTCP reporting interval, Trtcp, the video bit rate and frame rate, Rf, the audio bit rate and framing interval, and whether the receiver chooses to send congestion control feedback in each RTCP packet it sends. To simplify the calculation, assume it is desired to send one RTCP report for each frame of video received (i.e., Trtcp = 1 / Rf) and to include a congestion control feedback packet in each report. Assume that video has constant bit rate and frame rate, and that each frame of video has to fit into a 1500 octet MTU. Further, assume that the audio takes negligible bandwidth, and that the audio framing interval can be varied within reasonable bounds, so that an integral number of audio frames align with video frame boundaries. Table 5 shows the resulting values of Nv and Na, the number of video and audio packets covered by each congestion control feedback report, for a range of data rates and video frame rates, assuming congestion control feedback is sent once per video frame. The table also shows the result of inverting the RTCP reporting interval calculation to find the corresponding RTCP bandwidth, Brtcp. The RTCP bandwidth is given in kbps and as a fraction of the data rate. It can be seen that, for example, with a date rate of 1024 kbps and video sent at 30 frames-per-second, the RTCP congestion control feedback report sent for each video frame will include reports on 3 video packets and 2 audio packets. The RTCP bandwidth needed to sustain this reporting rate is 127.5kbps (12% of the data rate). This assumes an audio framing interval of 16.67ms, so that two audio packets are sent for each video frame. Perkins Expires 24 June 2023 [Page 12] Internet-Draft RTCP Feedback for Congestion Control December 2022 +-----------+----------+-------------+-------------+---------------+ | Data Rate | Video | Video | Audio | Required RTCP | | (kbps) | Frame | Packets per | Packets per | bandwidth: | | | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) | +-----------+----------+-------------+-------------+---------------+ | 100 | 8 | 1 | 6 | 34.5 (34%) | +-----------+----------+-------------+-------------+---------------+ | 200 | 16 | 1 | 3 | 67.5 (33%) | +-----------+----------+-------------+-------------+---------------+ | 350 | 30 | 1 | 2 | 125.6 (35%) | +-----------+----------+-------------+-------------+---------------+ | 700 | 30 | 2 | 2 | 126.6 (18%) | +-----------+----------+-------------+-------------+---------------+ | 700 | 60 | 1 | 1 | 249.4 (35%) | +-----------+----------+-------------+-------------+---------------+ | 1024 | 30 | 3 | 2 | 127.5 (12%) | +-----------+----------+-------------+-------------+---------------+ | 1400 | 60 | 2 | 1 | 251.2 (17%) | +-----------+----------+-------------+-------------+---------------+ | 2048 | 30 | 6 | 2 | 130.3 ( 6%) | +-----------+----------+-------------+-------------+---------------+ | 2048 | 60 | 3 | 1 | 253.1 (12%) | +-----------+----------+-------------+-------------+---------------+ | 4096 | 30 | 12 | 2 | 135.9 ( 3%) | +-----------+----------+-------------+-------------+---------------+ | 4096 | 60 | 6 | 1 | 258.8 ( 6%) | +-----------+----------+-------------+-------------+---------------+ Table 5: Required RTCP bandwidth, reporting on every frame Use of reduced size RTCP [RFC5506] would allow the SR and SDES packets to be omitted from some reports. These "reduced-size" RTCP packets would contain an RTCP RGRS packet from the non-reporting SSRC, and an RTCP SDES RGRP packet and a congestion control feedback packet from the reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv + 8 + 2*Na octets, plus the SRTCP trailer and authentication tag, and a UDP/IP header. That is, the size of the reduced-size packets would be (110 + 2*Nv + 2*Na)/2 octets. Repeating the analysis above, but alternating compound and reduced-size reports gives results as shown in Table 6. Perkins Expires 24 June 2023 [Page 13] Internet-Draft RTCP Feedback for Congestion Control December 2022 +-----------+----------+-------------+-------------+---------------+ | Data Rate | Video | Video | Audio | Required RTCP | | (kbps) | Frame | Packets per | Packets per | bandwidth: | | | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) | +-----------+----------+-------------+-------------+---------------+ | 100 | 8 | 1 | 6 | 25.0 (25%) | +-----------+----------+-------------+-------------+---------------+ | 200 | 16 | 1 | 3 | 48.5 (24%) | +-----------+----------+-------------+-------------+---------------+ | 350 | 30 | 1 | 2 | 90.0 (25%) | +-----------+----------+-------------+-------------+---------------+ | 700 | 30 | 2 | 2 | 90.9 (12%) | +-----------+----------+-------------+-------------+---------------+ | 700 | 60 | 1 | 1 | 178.1 (25%) | +-----------+----------+-------------+-------------+---------------+ | 1024 | 30 | 3 | 2 | 91.9 ( 8%) | +-----------+----------+-------------+-------------+---------------+ | 1400 | 60 | 2 | 1 | 180.0 (12%) | +-----------+----------+-------------+-------------+---------------+ | 2048 | 30 | 6 | 2 | 94.7 ( 4%) | +-----------+----------+-------------+-------------+---------------+ | 2048 | 60 | 3 | 1 | 181.9 ( 8%) | +-----------+----------+-------------+-------------+---------------+ | 4096 | 30 | 12 | 2 | 100.3 ( 2%) | +-----------+----------+-------------+-------------+---------------+ | 4096 | 60 | 6 | 1 | 187.5 ( 4%) | +-----------+----------+-------------+-------------+---------------+ Table 6: Required RTCP bandwidth, reporting on every frame, with reduced-size reports The use of reduced-size RTCP gives a noticeable reduction in the needed RTCP bandwidth, and can be combined with reporting every few frames rather than every frame. Overall, it is clear that the RTCP overhead can be reasonable across the range of data and frame rates, if RTCP is configured carefully. As discussed in Section 3.1, the reporting overhead will increase if IPv6 is used, due to the increased size of the IPv6 header. Table 7 shows the overhead in this case, compared to Table 6. As can be seen, the increase in overhead due to IPv6 rapidly becomes less significant as the data rate increases. Perkins Expires 24 June 2023 [Page 14] Internet-Draft RTCP Feedback for Congestion Control December 2022 +-----------+----------+-------------+-------------+---------------+ | Data Rate | Video | Video | Audio | Required RTCP | | (kbps) | Frame | Packets per | Packets per | bandwidth: | | | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) | +-----------+----------+-------------+-------------+---------------+ | 100 | 8 | 1 | 6 | 27.5 (27%) | +-----------+----------+-------------+-------------+---------------+ | 200 | 16 | 1 | 3 | 53.5 (26%) | +-----------+----------+-------------+-------------+---------------+ | 350 | 30 | 1 | 2 | 99.4 (28%) | +-----------+----------+-------------+-------------+---------------+ | 700 | 30 | 2 | 2 | 100.3 (14%) | +-----------+----------+-------------+-------------+---------------+ | 700 | 60 | 1 | 1 | 196.9 (28%) | +-----------+----------+-------------+-------------+---------------+ | 1024 | 30 | 3 | 2 | 101.2 ( 9%) | +-----------+----------+-------------+-------------+---------------+ | 1400 | 60 | 2 | 1 | 198.8 (14%) | +-----------+----------+-------------+-------------+---------------+ | 2048 | 30 | 6 | 2 | 104.1 ( 5%) | +-----------+----------+-------------+-------------+---------------+ | 2048 | 60 | 3 | 1 | 200.6 ( 9%) | +-----------+----------+-------------+-------------+---------------+ | 4096 | 30 | 12 | 2 | 109.7 ( 2%) | +-----------+----------+-------------+-------------+---------------+ | 4096 | 60 | 6 | 1 | 206.2 ( 5%) | +-----------+----------+-------------+-------------+---------------+ Table 7: Required RTCP bandwidth, reporting on every frame, with reduced-size reports, using IPv6 4. Discussion and Conclusions Practical systems will generally send some non-media traffic on the same path as the media traffic. This can include STUN/TURN packets to keep-alive NAT bindings [RFC8445], WebRTC Data Channel packets [RFC8831], etc. Such traffic also needs congestion control, but the means by which this is achieved is out of scope of this memo. RTCP as it is currently specified cannot be used to send per-packet congestion feedback with reasonable overhead. RTCP can, however, be used to send congestion feedback on each frame of video sent, provided the session bandwidth exceeds a couple of megabits per second (the exact rate depending on the number of session participants, the RTCP bandwidth fraction, and what RTCP extensions are enabled, and how much detail of feedback is needed). For lower rate sessions, the overhead of reporting on every frame Perkins Expires 24 June 2023 [Page 15] Internet-Draft RTCP Feedback for Congestion Control December 2022 becomes high, but can be reduced to something reasonable by sending reports once per N frames (e.g., every second frame), or by sending reduced-size RTCP reports in between the regular reports. The improved compression of new video codecs exacerbates the reporting overhead for a given video quality level, although this is to some extent countered by the use of higher quality video over time. If it is desired to use RTCP in something close to its current form for congestion feedback in WebRTC, the multimedia congestion control algorithm needs to be designed to work with feedback sent every few frames, since that fits within the limitations of RTCP. The provided feedback will be more detailed than just an acknowledgement, however, and will provide a loss bitmap, relative arrival time, and received ECN marks, for each packet sent. This will allow congestion control that is effective, if slowly responsive, to be implemented (there is guidance on providing effective congestion control in Section 3.1 of [RFC8085]). The format described in [RFC8888] seems sufficient for the needs of congestion control feedback. There is little point optimising this format: the main overhead comes from the UDP/IP headers and the other RTCP packets included in the compound packets, and can be lowered by using the [RFC5506] extensions and sending reports less frequently. The use of header compression [RFC2508], [RFC3545], [RFC5795] can also be beneficial. Further study of the scenarios of interest is needed, to ensure that the analysis presented is applicable to other media topologies [RFC7667], and to sessions with different data rates and sizes of membership. 5. Security Considerations An attacker that can modify or spoof RTCP congestion control feedback packets can manipulate the sender behaviour to cause denial of service. This can be prevented by authentication and integrity protection of RTCP packets, for example using the secure RTP profile [RFC3711][RFC5124], or by other means as discussed in [RFC7201]. 6. IANA Considerations There are no actions for IANA. Perkins Expires 24 June 2023 [Page 16] Internet-Draft RTCP Feedback for Congestion Control December 2022 7. Acknowledgements Thanks to Bernard Aboba, Martin Duke, Linda Dunbar, Gorry Fairhurst, Ingemar Johansson, Shuping Peng, Alvaro Retana, Zahed Sarker, John Scudder, Éric Vyncke, Magnus Westerlund, and the members of the RMCAT feedback design team for their feedback. 8. Normative References [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, . [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . Perkins Expires 24 June 2023 [Page 17] Internet-Draft RTCP Feedback for Congestion Control December 2022 [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", RFC 8108, DOI 10.17487/RFC8108, March 2017, . [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for Browser-Based Applications", RFC 8825, DOI 10.17487/RFC8825, January 2021, . [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, January 2021, . [RFC8861] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback", RFC 8861, DOI 10.17487/RFC8861, January 2021, . [RFC8872] Westerlund, M., Burman, B., Perkins, C., Alvestrand, H., and R. Even, "Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams", RFC 8872, DOI 10.17487/RFC8872, January 2021, . [RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP Control Protocol (RTCP) Feedback for Congestion Control", RFC 8888, DOI 10.17487/RFC8888, January 2021, . 9. Informative References [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, DOI 10.17487/RFC2508, February 1999, . Perkins Expires 24 June 2023 [Page 18] Internet-Draft RTCP Feedback for Congestion Control December 2022 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, December 2002, . [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, DOI 10.17487/RFC3545, July 2003, . [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, . [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, DOI 10.17487/RFC5795, March 2010, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, . [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . Author's Address Perkins Expires 24 June 2023 [Page 19] Internet-Draft RTCP Feedback for Congestion Control December 2022 Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org Perkins Expires 24 June 2023 [Page 20] ./draft-ietf-shmoo-online-meeting-05.txt0000644000764400076440000005736514346624231017733 0ustar iustiniustin Network Working Group M. Kühlewind Internet-Draft Ericsson Intended status: Informational M. Duke Expires: 18 June 2023 Google 15 December 2022 Guidelines for the Organization of Fully Online Meetings draft-ietf-shmoo-online-meeting-05 Abstract This document provides guidelines for the planning and organization of fully online meetings, regarding the number, length, and composition of sessions on the meeting agenda. These guidelines are based on the experience with online meetings during the COVID-19 pandemic in 2020 and 2021. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Stay Home Meet Only Online Working Group mailing list (manycouches@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/manycouches/. Source for this draft and an issue tracker can be found at https://github.com/mirjak/draft-shmoo-online-meeting. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 18 June 2023. Kühlewind & Duke Expires 18 June 2023 [Page 1] Internet-Draft Organization Online Meetings December 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Some History . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Guidelines for Online Meeting Planning . . . . . . . . . . . 4 3.1. Time Zone Selection . . . . . . . . . . . . . . . . . . . 4 3.1.1. Guidelines for selection . . . . . . . . . . . . . . 5 3.2. Number of Days and Total Hours per Day . . . . . . . . . 6 3.3. Session/Break Length . . . . . . . . . . . . . . . . . . 6 3.4. Number of Parallel Tracks . . . . . . . . . . . . . . . . 7 4. Additional Considerations and Recommendations . . . . . . . . 7 4.1. Full vs. Limited Agenda (and interim meetings) . . . . . 7 4.2. Flexibility of Time Usage . . . . . . . . . . . . . . . . 8 4.3. Inclusivity and Socializing . . . . . . . . . . . . . . . 8 4.4. Experiments . . . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction In 2020, the COVID-19 pandemic forced the IETF to convert all its plenary meetings to online-only events. This document records the experience gained by holding plenary meetings fully online and proposes guidelines based on this experience. In general, participant surveys indicated satisfaction with the organization of these meetings. Although these guidelines reflect lessons learned in 2020 and 2021, the IETF is encouraged to continue to experiment with the format and agenda of fully online meetings, using this document as a baseline. Kühlewind & Duke Expires 18 June 2023 [Page 2] Internet-Draft Organization Online Meetings December 2022 Hybrid meetings (meaning meetings that have large remote participation but also onsite participation) are out of scope. However, some of the experience gained from fully online meetings might also provide input for decisions regarding the organization of hybrid meetings. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the term "plenary meeting" for the whole IETF meeting that covers the IETF meeting week; this term is used to distinguish the plenary meeting from other IETF meetings like "interim meetings". The term "administrative plenary" is used for the respective session during the IETF meeting week that is usually hosted on Wednesday. 2. Some History When the World Health Organization (WHO) declared a world-wide pandemic in March 2020, the IETF canceled its plenary meeting and organized an online replacement in less than two weeks. For this first online-only meeting, the agenda was reduced to a set of sessions that benefitted most from cross-area participation, like BoFs, first-time meetings of new working groups, and dispatch sessions. It also included the administrative plenary to preserve the official hand-over procedures that occur at the March meeting, as described in [RFC8713]. With a reduced agenda, the meeting format was 2 sessions (about 4 hours) per day with a maximum of two parallel tracks. Other working group meetings were scheduled as interims over the following six weeks. The IESG published a purely advisory recommended schedule [INTERIM-SCHEDULE] to reduce conflicts among those interims. While satisfaction was high right after the meetinng [_107-FEEDBACK], some participants later indicated in mailing list discussion that the period of intensive interims had a greater impact on their calendar than a single plenary meeting week, and in some meetings participation was reduced. Those interims tended to occur at times convenient for the bulk of participants, which was convenient for most but could exclude those in less common time zones. Kühlewind & Duke Expires 18 June 2023 [Page 3] Internet-Draft Organization Online Meetings December 2022 For the remainder of 2020 and 2021, the online schedule was switched back to be similar to an in-person meeting (1-2 hour slots and 8-9 parallel tracks). However, each day was limited to 5-6 hours in recognition that remote participation is more tiring. All fully online meetings followed the time zone of the planned in- person meeting location. As a six-hour agenda has some flexibility regarding the start time while still fitting within a previously used 8-hour in-person agenda, the start time was approximately noon, with adjustments of an hour or so to mitigate the impact of early morning hours in time zones with many participants. As selection of in- person meeting sites was consistent with the 1-1-1 guideline as documented in [RFC8719], this approach was intended to share the burden across all common geographies roughly equally. 3. Guidelines for Online Meeting Planning 3.1. Time Zone Selection The following algorithm was not used in 2020 or 2021, but enables most participants to avoid late-night sessions in 2 out of every 3 fully online IETF plenary meetings. Basically, every fully online meeting is for two regions of the three regions described in [RFC8179], with one being roughly after sunrise and the other around sundown. This has the tradeoff that the third region is in the middle of night. The times are also seasonally adjusted to leverage differentials in Daylight Saving Time. These time slots are as follows, in UTC, based on the Daylight Saving Practices at the time of publication: +===============+=========================+=========================+ | Name | Times (Northern Summer) | Times (Northern | | | | Winter) | +===============+=========================+=========================+ | North America | 0500-1100 UTC | 0600-1200 UTC | | Night | | | +---------------+-------------------------+-------------------------+ | Asia Night | 1300-1900 UTC | 1400-2000 UTC | +---------------+-------------------------+-------------------------+ | Europe Night | 2200-0400 UTC | 2200-0400 UTC | +---------------+-------------------------+-------------------------+ Table 1 Note that the "European Night" slot covers the "Early Morning" slot for Asia where most countries do not have Daylight Saving Time. Kühlewind & Duke Expires 18 June 2023 [Page 4] Internet-Draft Organization Online Meetings December 2022 If Daylight Saving Practices change, which is under consideration in multiple countries at the time of publication, this table may need adjustment. The intent of rotating between these three slots is to scatter meetings throughout the course of the global day, to maximize the ease of participants so that no attendee has to be consistently inconvenienced, regardless of their location and what time of day is optimal for their schedule. However, as participation is distributed globally, it needs to be acknowledged that restricting the scheme to three regions observes the intent of [RFC8179] but does not achieve the goal of 2 non-late-night sessions for all participants equally. 3.1.1. Guidelines for selection The IETF SHOULD select a start time from these three choices based on the prior three meetings. The following table covers all permutations of previous meetings held in-person in Region A, B, or C; or remotely in the nights of one of those regions. +================+================+==============+==================+ | 3 meetings ago | 2 meetings ago | Last Meeting | Online | | | | | Selection | +================+================+==============+==================+ | Any | Any | In-Person A | A Night | +----------------+----------------+--------------+------------------+ | Any | Online A Night | Online B | C Night | | | | Night | | +----------------+----------------+--------------+------------------+ | Online A Night | In-Person B | Online B | C Night | | | | Night | | +----------------+----------------+--------------+------------------+ | In-Person A | In-Person B | Online B | A Night | | | | Night | | +----------------+----------------+--------------+------------------+ | In-Person A | In-Person A | Online A | see below | | | | Night | | +----------------+----------------+--------------+------------------+ | Online A Night | Online B Night | Online C | A Night | | | | Night | | +----------------+----------------+--------------+------------------+ Table 2 Kühlewind & Duke Expires 18 June 2023 [Page 5] Internet-Draft Organization Online Meetings December 2022 This table follows two basic guidelines: 1) Whenever a fully online meeting follows an in-person meeting, the online meeting time is used that most disadvantages most the participants in the time zone where the in-person meeting was held. 2) If multiple fully online meetings follow each other, the time zone selection should be rotated based on the most recent time zones that the in-person meetings were held in. The final case occurs in the rare event that back-to-back in-person plenary meetings occur in the same region. In this case, find the most recent meeting that was neither in 'A' (if in-person) nor in 'A' night (if fully online). If this meeting was in-person in region 'B', then the next meeting should be in 'B' Night. If it was remote in 'B' Night, the next meeting should be in 'C' Night. 3.2. Number of Days and Total Hours per Day By 2021, fully online meetings were consistently held over 5 days with roughly 6-hour meeting days. The day with the administrative plenary, which concludes with multiple open mic sessions, sometimes exceeded this limit. Six hours of online meetings, with two 30-minute breaks, was a compromise between the physical limits of attending an online meeting in an inconvenient time zone, and the demand for many sessions with a manageable number of conflicts. The IETF 109 feedback [_109-SURVEY] indicated broad satisfaction with a 5-day meeting but only medium satisfaction with the overall length of each day. The IETF did not seriously consider extending sessions into the weekend before or after the main meeting week, although the Hackathon occupied the entire week before (see [RFC9311]). 3.3. Session/Break Length For fully online meetings there are typically fewer sessions per day than for in-person meetings, to keep the overall meeting day to roughly 6 hours. With fewer sessions, chairs were offered only two options for session length (instead of three). IETF-108, based on an indicated preference of the community, scheduled 50- and 100-minute slots, with 10-minute breaks, in order to keep the overall day length at 5 hours. This resulted in many sessions going over time, which indicated that 10 minutes for breaks is not practical. The survey after IETF-109 [_109-SURVEY] showed high satisfaction with 60/120-minute session lengths and 30-minute breaks, and a significant improvement in satisfaction over IETF-108. Kühlewind & Duke Expires 18 June 2023 [Page 6] Internet-Draft Organization Online Meetings December 2022 The longer breaks, while extending the day, provided adequate time for meals, exercise, and "hallway" conversations using online tools. 3.4. Number of Parallel Tracks In-person meetings are limited in the number of parallel tracks by the number of meeting rooms, but online meetings are not. However, more parallel tracks increases the number of possible agenda conflicts. If the total number of requested sessions exceeds the capacity of the usual 8 parallel tracks, it is possible for a fully online meeting to simply use more tracks. If the number and length of meeting days is seen as fixed, this decision is implicitly made by the working group chairs requesting a certain number of sessions and length. IETF-111 used 9 parallel tracks for some of the sessions, and experienced slightly more conflicts in the agenda scheduling process, though there was no statistically significant increase in dissatisfaction about conflicts in the survey [_111-SURVEY]. The IESG encouraged working group chairs to limit their session requests and use interim meetings aggressively for focused work. 4. Additional Considerations and Recommendations 4.1. Full vs. Limited Agenda (and interim meetings) The IETF-108 meeting survey [_108-SURVEY] asked about the structure of that meeting (full meeting) compared to that of IETF 107, which hosted only a limited set of sessions followed by interims in the weeks after. The structure of IETF 108 was preferred by 82%. Respondents valued cross-participation and an intensive meeting week for maintaining project momentum. Furthermore, a well-defined meeting time, rather than spreading many interims over the whole year, can make deconflicting with other non- IETF meetings easier. However, interim meetings can also help to reduce scheduling conflicts during an IETF week and allow for a more optimal time slot for the key participants. While interim meetings are less likely to attract people with casual interest, they provide a good opportunity for the most active participants of a group to have detailed technical discussions and solve recorded issues efficiently. Kühlewind & Duke Expires 18 June 2023 [Page 7] Internet-Draft Organization Online Meetings December 2022 4.2. Flexibility of Time Usage This document recommends further experiments with reducing conflicts by leveraging the increased flexibility of the online format. An in-person meeting must fit all sessions into an acceptable length for international travel (usually roughly a week), but online meetings do not have that constraint. Therefore, it would be possible to keep most regular working group sessions within the usual five main meeting days but have some of the more conflicted sessions in other dedicated time slots. As the Hackathon for fully online meetings is usually held in the week before the online plenary meeting [RFC9311], that week is already a highly active week for many IETF participants and might provide an opportunity to schedule a few selected sessions. This might work especially well for sessions that are of high interest to a large part of community, such as BoFs and dispatch meetings, and therefore hard to schedule during the main IETF week. At IETF 112, the IESG ran an experiment where the administrative plenary was scheduled on the Wednesday before the official session week. The experiment report [_112-EXPERIMENT] found that it led to a reduction in scheduling conflicts but also a slight drop in attendance of the administrative plenary, partly due to insufficient awareness. 4.3. Inclusivity and Socializing Participation in the fully online meetings in 2021 was high and had a stable per-country distribution, even though time zones were rotated. This indicates that online meetings support a more consistent geographic distribution of participants than in-person meetings, where participation often fluctuates based on the location. However, online meetings do not provide an equivalent opportunity to socialize. Despite significant investment in tools to foster hallway conversations, many did not use those tools, whether due to ignorance of them, dislike of the tools, or a preference for the other activities at home (including sleep and food) over hallway interactions. There was a decrease in submission of new (-00) drafts during 2020 and 2021, although the overall number of draft submissions remained stable, which might result from the loss of these interactions. Informal conversations might be important to inspire new work. Kühlewind & Duke Expires 18 June 2023 [Page 8] Internet-Draft Organization Online Meetings December 2022 4.4. Experiments This document recommends further experiments with the meeting structure. Often, only practical experience can answer open questions. A given meeting SHOULD only experiment with one major change at a time in order to be able to assess the outcome correctly. Furthermore, the IESG SHOULD announce any such experiment well in advance, so people can adjust to changes and potentially provide feedback. 5. Acknowledgments Thanks to Brian Carpenter, Lars Eggert, Toerless Eckert, Charles Eckel, Jason Livingood, Sanjeev Gupta, Dale Worley, and Mark Nottingham for their reviews and many from more for their input and suggestions on the time zone discussion! 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, DOI 10.17487/RFC8179, May 2017, . 6.2. Informative References [INTERIM-SCHEDULE] Cooper, A., "Post-IETF-107 Recommended Virtual Interim Schedule", 13 March 2020, . Kühlewind & Duke Expires 18 June 2023 [Page 9] Internet-Draft Organization Online Meetings December 2022 [RFC8713] Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood, Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees", BCP 10, RFC 8713, DOI 10.17487/RFC8713, February 2020, . [RFC8719] Krishnan, S., "High-Level Guidance for the Meeting Policy of the IETF", BCP 226, RFC 8719, DOI 10.17487/RFC8719, February 2020, . [RFC9311] Eckel, C., "Running an IETF Hackathon", RFC 9311, DOI 10.17487/RFC9311, September 2022, . [_107-FEEDBACK] Daley, J., "IETF 107 Virtual Meeting Survey Report", 17 April 2020, . [_108-SURVEY] Daley, J., "IETF 108 Meeting Survey", 13 August 2020, . [_109-SURVEY] Daley, J., "IETF 109 Post-Meeting Survey", 7 December 2020, . [_111-SURVEY] Daley, J., "IETF 111 Post-Meeting Survey", 23 August 2021, . [_112-EXPERIMENT] IESG, "IETF 112 Plenary Experiment Evaluation", 4 February 2022, . Authors' Addresses Mirja Kühlewind Ericsson Email: mirja.kuehlewind@ericsson.com Martin Duke Google Email: martin.h.duke@gmail.com Kühlewind & Duke Expires 18 June 2023 [Page 10] ./draft-ietf-sipcore-multiple-reasons-01.txt0000644000764400076440000001675114301212573020622 0ustar iustiniustin SIPCORE Working Group R. Sparks Internet-Draft 23 August 2022 Updates: 3326 (if approved) Intended status: Standards Track Expires: 24 February 2023 Multiple SIP Reason Header Field Values draft-ietf-sipcore-multiple-reasons-01 Abstract The SIP Reason Header Field as defined in RFC 3326 allows only one Reason value per protocol value. Experience with more recently defined protocols shows it is useful to allow multiple values with the same protocol value. This update to RFC 3326 allows multiple values for an indicated registered protocol when that protocol defines what the presence of multiple values means. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 February 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Sparks Expires 24 February 2023 [Page 1] Internet-Draft Multiple reasons August 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 3. Update to RFC3326 . . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 6.1. Normative References . . . . . . . . . . . . . . . . . . 3 6.2. Informative References . . . . . . . . . . . . . . . . . 4 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 4 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 4 B.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 B.2. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction The SIP Reason Header Field as defined in RFC 3326 allows only one Reason value per protocol value. Experience with more recently defined protocols shows it is useful to allow multiple values with the same protocol value [STIRREASONS]. This update to RFC 3326 allows multiple values for an indicated registered protocol when that protocol defines what the presence of multiple values means. It does not change the requirement in RFC 3326 restricting the header field contents to one value per protocol for those protocols that do not define what multiple values mean. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Sparks Expires 24 February 2023 [Page 2] Internet-Draft Multiple reasons August 2022 3. Update to RFC3326 The last paragraph of section 2 of [RFC3326] is replaced as follows: OLD: A SIP message MAY contain more than one Reason value (i.e., multiple Reason lines), but all of them MUST have different protocol values (e.g., one SIP and another Q.850). An implementation is free to ignore Reason values that it does not understand. NEW: A SIP message MAY contain more than one Reason value (i.e., multiple Reason lines). If the registered protocol for the Reason value specifies what it means for multiple values to occur in one message, more than one value for that protocol MAY be present. Otherwise, there MUST be only one value per protocol provided (e.g., one SIP and another Q.850). An implementation is free to ignore Reason values that it does not understand. 4. Security Considerations This document adds no security considerations to the use of SIP. The security considerations in [RFC3326] and those in any registered protocols used in Reason header field values should be considered. 5. IANA Considerations This document has no IANA actions. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, DOI 10.17487/RFC3326, December 2002, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Sparks Expires 24 February 2023 [Page 3] Internet-Draft Multiple reasons August 2022 6.2. Informative References [STIRREASONS] Wendt, C., "Identity Header Errors Handling", Work in Progress, Internet-Draft, draft-ietf-stir-identity-header- errors-handling-03, 19 August 2022, . Appendix A. Acknowledgments This text is based on discussions at a STIR working group interim meeting. Jean Mahoney and Russ Housley provided suggestions that vastly improved the first attempts at assembling these words. Christer Holmberg, Dale Worley, Brian Rosen, Chris Wendt, and Paul Kyzivat provided constructive discussion during SIPCORE working group adoption. Appendix B. Changelog (This section to be removed by the RFC editor.) B.1. 00 * rename draft-sparks to draft-ietf. Add changelog. B.2. 01 * expand a little on "Practice shows", referring to [STIRREASONS] Author's Address Robert Sparks Email: rjsparks@nostrum.com Sparks Expires 24 February 2023 [Page 4] ./draft-ietf-trill-ecn-support-07.txt0000644000764400076440000010204213244635507017266 0ustar iustiniustin TRILL Working Group Donald Eastlake INTERNET-DRAFT Huawei Intended status: Proposed Standard Bob Briscoe CableLabs Expires: August 24, 2018 February 25, 2018 TRILL (TRansparent Interconnection of Lots of Links): ECN (Explicit Congestion Notification) Support Abstract Explicit congestion notification (ECN) allows a forwarding element to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This can improve network efficiency through better congestion control without packet drops. This document extends ECN to TRILL (TRansparent Interconnection of Lots of Links) switches, including integration with IP ECN, and provides for ECN marking in the TRILL Header Extension Flags Word (see RFC 7179). Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Distribution of this document is unlimited. Comments should be sent to the TRILL working group mailing list . Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. D. Eastlake & B. Briscoe [Page 1] INTERNET-DRAFT TRILL ECN Support Table of Contents 1. Introduction............................................3 1.1 Conventions used in this document......................4 2. The ECN Specific Extended Header Flags..................6 3. ECN Support.............................................7 3.1 Ingress ECN Support....................................7 3.2 Transit ECN Support....................................7 3.3 Egress ECN Support.....................................8 3.3.1 Non-ECN Egress RBridges..............................8 3.3.2 ECN Egress RBridges..................................8 4. TRILL Support for ECN Variants.........................11 4.1 Pre-Congestion Notification (PCN).....................11 4.2 Low Latency, Low Loss, Scalable Throughput (L4S)......12 5. IANA Considerations....................................13 6. Security Considerations................................14 7. Acknowledgements.......................................14 Normative References......................................15 Informative References....................................16 Appendix A. TRILL Transit RBridge Behavior to Support L4S.17 Authors' Addresses........................................19 D. Eastlake & B. Briscoe [Page 2] INTERNET-DRAFT TRILL ECN Support 1. Introduction Explicit congestion notification (ECN [RFC3168] [RFC8311]) allows a forwarding element (such as a router) to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This can improve network efficiency through better congestion control without packet drops. The forwarding element can explicitly mark a proportion of packets in an ECN field instead of dropping the packet. For example, a two-bit field is available for ECN marking in IP headers. ............................. . . +---------+ . +------+ | Ingress | . |Source| +->| RBridge | . +----------+ +---+--+ | | RB1 | . |Forwarding| | | +------+--+ +----------+ . | Element | v | . | | Transit | . | Y | +-------+--+ . +---->| RBridges | . +--------+-+ |Forwarding| . | RBn | . ^ | | Element | . +-------+--+ +---------+ | v | X | . | | Egress | | +-----------+ +----------+ . +---->| RBridge +-+ |Destination| . | RB9 | +-----------+ . TRILL +---------+ . campus . ............................. Figure 1. Example Path Forwarding Nodes In [RFC3168], it was recognized that tunnels and lower layer protocols would need to support ECN, and ECN markings would need to be propagated, as headers were encapsulated and decapsulated. [ECNencapGuide] gives guidelines on the addition of ECN to protocols like TRILL (TRansparent Interconnection of Lots of Links) that often encapsulate IP packets, including propagation of ECN from and to IP. In the figure above, assuming IP traffic, RB1 is an encapsulator and RB9 a decapsulator. Traffic from Source to RB1 might or might not get marked as having experienced congestion in forwarding elements, such as X, before being encapsulated at ingress RB1. Any such ECN marking is encapsulated with a TRILL Header [RFC6325]. This document specifies how ECN marking in traffic at the ingress is copied into the TRILL Extension Header Flags Word and requires such copying for IP traffic. It also enables congestion marking by a congested RBridge such as RBn or RB1 above in the TRILL Header Extension Flags Word [RFC7179]. D. Eastlake & B. Briscoe [Page 3] INTERNET-DRAFT TRILL ECN Support At RB9, the TRILL egress, it specifies how any ECN markings in the TRILL Header Flags Word and in the encapsulated traffic are combined so that subsequent forwarding elements, such as Y and the Destination, can see if congestion was experienced at any previous point in the path from Source. A large part of the guidelines for adding ECN to lower layer protocols [ECNencapGuide] concerns safe propagation of congestion notifications in scenarios where some of the nodes do not support or understand ECN. Such ECN ignorance is not a major problem with RBridges using this specification because the method specified assures that, if an egress RBridge is ECN ignorant (so it cannot further propagate ECN) and congestion has been encountered, the egress RBridge will at least drop the packet and this drop will itself indicate congestion to end stations. 1.1 Conventions used in this document The terminology and acronyms defined in [RFC6325] are used herein with the same meaning. In this documents, "IP" refers to both IPv4 and IPv6. 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] [RFC8174] when, and only when, they appear in all capitals, as shown here. Acronyms: AQM - Active Queue Management CCE - Critical Congestion Experienced CE - Congestion Experienced CItE - Critical Ingress-to-Egress ECN - Explicit Congestion Notification ECT - ECN Capable Transport L4S - Low Latency, Low Loss, Scalable throughput NCHbH - Non-Critical Hop-by-Hop NCCE - Non-Critical Congestion Experienced D. Eastlake & B. Briscoe [Page 4] INTERNET-DRAFT TRILL ECN Support Not-ECT - Not ECN-Capable Transport PCN - Pre-Congestion Notification D. Eastlake & B. Briscoe [Page 5] INTERNET-DRAFT TRILL ECN Support 2. The ECN Specific Extended Header Flags The extension header fields for explicit congestion notification (ECN) in TRILL are defined as a two-bit TRILL-ECN field and a one-bit Critical Congestion Experienced (CCE) field in the 32-bit TRILL Header Extension Flags Word [RFC7780]. These fields are shown in Figure 2 as "ECN" and "CCE". The TRILL-ECN field consists of bits 12 and 13, which are in the range reserved for non-critical hop-by-hop (NCHbH) bits. The CCE field consists of bit 26, which is in the range reserved for Critical Ingress-to-Egress (CItE) bits. The CRItE bit is the critical Ingress-to-Egress summary bit and will be one if and only if any of the bits in the CItE range (21-26) are one or there is a critical feature invoked in some further extension of the TRILL Header after the Extension Flags Word. The other bits and fields shown in Figure 2 are not relevant to ECN. See [RFC7780], [RFC7179], and [IANAthFlags] for the meaning of these other bits and fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE | |.....|.........|...........|.....|.......|...........|.........| |C|C|C| |C|N| | | | | | | | | |R|R|R| |R|C| |ECN| Ext | | |C|Ext| | |H|I|R| |C|C| | | Hop | | |C|Clr| | |b|t|s| |A|A| | | Cnt | | |E| | | |H|E|v| |F|F| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. The TRILL-ECN and CCE TRILL Header Extension Flags Word Fields Table 1 shows the meaning of the codepoints in the TRILL-ECN field. The first three have the same meaning as the corresponding ECN field codepoints in the IP header as defined in [RFC3168]. However, codepoint 0b11 is called Non-Critical Congestion Experienced (NCCE) to distinguish it from Congestion Experienced in IP. Binary Name Meaning ------ ------- ----------------------------------- 00 Not-ECT Not ECN-Capable Transport 01 ECT(1) ECN-Capable Transport (1) 10 ECT(0) ECN-Capable Transport (0) 11 NCCE Non-Critical Congestion Experienced Table 1. TRILL-ECN Field Codepoints D. Eastlake & B. Briscoe [Page 6] INTERNET-DRAFT TRILL ECN Support 3. ECN Support This section specifies interworking between TRILL and the original standardized form of ECN in IP [RFC3168]. The subsections below describe the required behavior to support ECN at TRILL ingress, transit, and egress. The ingress behavior occurs as a native frame is encapsulated with a TRILL Header to produce a TRILL Data packet. The transit behavior occurs in all RBridges where TRILL Data packets are queued, usually at the output port. The egress behavior occurs where a TRILL Data packet is decapsulated and output as a native frame through an RBridge port. An RBridge that supports ECN MUST behave as described in the relevant subsections below, which correspond to the recommended provisions in Section 3 and Sections 5.1-5.4 of [ECNencapGuide]. Nonetheless, the scheme is designed to safely propagate some form of congestion notification even if some RBridges in the path followed by a TRILL Data packet support ECN and others do not. 3.1 Ingress ECN Support The behavior at an ingress RBridge is as follows: o When encapsulating an IP frame, the ingress RBridge MUST: + set the F flag in the main TRILL header [RFC7780]; + create a Flags Word as part of the TRILL Header; + copy the two ECN bits from the IP header into the TRILL-ECN field (Flags Word bits 12 and 13) + ensure the CCE flag is set to zero (Flags Word bit 26). o When encapsulating a frame for a non-IP protocol, where that protocol has a means of indicating ECN that is understood by the ingress RBridge, it MUST follow the guidelines in Section 5.3 of [ECNencapGuide] to add a Flags Word to the TRILL Header. For a non-IP protocol with a similar ECN field to IP, this would be achieved by copying into the TRILL-ECN field from the encapsulated native frame. 3.2 Transit ECN Support The transit behavior, shown below, is required at all RBridges where TRILL Data packets are queued, usually at the output port. o An RBridge that supports ECN MUST implement some form of active D. Eastlake & B. Briscoe [Page 7] INTERNET-DRAFT TRILL ECN Support queue management (AQM) according to the guidelines of [RFC7567]. The RBridge detects congestion either by monitoring its own queue depth or by participating in a link-specific protocol. o If the TRILL Header Flags Word is present, whenever the AQM algorithm decides to indicate congestion on a TRILL Data packet it MUST set the CCE flag (Flags Word bit 26). o If the TRILL header Flags Word is not present, to indicate congestion the RBridge will either drop the packet or it MAY do all of the following instead: + set the F flag in the main TRILL header; + add a Flags Word to the TRILL Header; + set the TRILL-ECN field to Not-ECT (00); + and set the CCE flag and the Ingress-to-Egress critical summary bit (CRIbE). Note that a transit RBridge that supports ECN does not refer to the TRILL-ECN field before signaling CCE in a packet. It signals CCE irrespective of whether the packet indicates that the transport is ECN-capable. The egress/decapsulation behavior (described next) ensures that a CCE indication is converted to a drop if the transport is not ECN-capable. 3.3 Egress ECN Support 3.3.1 Non-ECN Egress RBridges If the egress RBridge does not support ECN, that RBridge will ignore bits 12 and 13 of any Flags Word that is present, because it does not contain any special ECN logic. Nonetheless, if a transit RBridge has set the CCE flag, the egress will drop the packet. This is because drop is the default behavior for an RBridge decapsulating a Critical Ingress-to-Egress flag when it has no specific logic to understand it. Drop is the intended behavior for such a packet, as required by Section 5.4 of [ECNencapGuide]. 3.3.2 ECN Egress RBridges If an RBridge supports ECN, for the two cases of an IP and a non-IP inner packet, the egress behavior is as follows: Decapsulating an inner IP packet: The RBridge sets the ECN field D. Eastlake & B. Briscoe [Page 8] INTERNET-DRAFT TRILL ECN Support of the outgoing native IP packet using Table 3. It MUST set the ECN field of the outgoing IP packet to the codepoint at the intersection of the row for the arriving encapsulated IP packet and the column for 3-bit ECN codepoint in the arriving outer TRILL Data packet TRILL Header. If no TRILL Header Extension Flags Word is present, the 3-bit ECN codepoint is assumed to be all zero bits. The name of the TRILL 3-bit ECN codepoint is defined using the combination of the TRILL-ECN and CCE fields in Table 2. Specifically, the TRILL 3-bit ECN codepoint is called CE if either NCCE or CCE is set in the TRILL Header Extension Flags Word. Otherwise it has the same name as the 2-bit TRILL-ECN codepoint. In the case where the TRILL 3-bit ECN codepoint indicates congestion experienced (CE) but the encapsulated native IP frame indicates a not ECN-capable transport (Not-ECT), it can be seen that the RBridge MUST drop the packet. Such packet dropping is necessary because a transport above the IP layer that is not ECN-capable will have no ECN logic, so it will only understand dropped packets as an indication of congestion. Decapsulating a non-IP protocol frame: If the frame has a means of indicating ECN that is understood by the RBridge, it MUST follow the guidelines in Section 5.4 of [ECNencapGuide] when setting the ECN information in the decapsulated native frame. For a non-IP protocol with a similar ECN field to IP, this would be achieved by combining the information in the TRILL Header Flags Word with the encapsulated non-IP native frame, as specified in Table 3. +------------+-----+---------------------+ | TRILL-ECN | CCE | Arriving TRILL 3-bit| | | | ECN codepoint name | +------------+-----+---------------------+ | Not-ECT 00 | 0 | Not-ECT | | ECT(1) 01 | 0 | ECT(1) | | ECT(0) 10 | 0 | ECT(0) | | NCCE 11 | 0 | CE | | Not-ECT 00 | 1 | CE | | ECT(1) 01 | 1 | CE | | ECT(0) 10 | 1 | CE | | NCCE 11 | 1 | CE | +------------+-----+---------------------+ Table 2. Mapping of TRILL-ECN and CCE Fields to the TRILL 3-bit ECN Codepoint Name D. Eastlake & B. Briscoe [Page 9] INTERNET-DRAFT TRILL ECN Support +---------+----------------------------------------------+ | Inner | Arriving TRILL 3-bit ECN Codepoint Name | | Native +---------+------------+------------+----------+ | Header | Not-ECT | ECT(0) | ECT(1) | CE | +---------+---------+------------+------------+----------+ | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | | | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | | ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE | | CE | CE | CE | CE(*) | CE | +---------+---------+------------+------------+----------+ Table 3. Egress ECN Behavior An asterisk in the above table indicates a combination that is currently unused in all variants of ECN marking (see Section 4) and therefore SHOULD be logged. With one exception, the mappings in Table 3 are consistent with those for IP-in-IP tunnels [RFC6040], which ensures backward compatibility with all current and past variants of ECN marking (see Section 4). It also ensures forward compatibility with any future form of ECN marking that complies with the guidelines in [ECNencapGuide], including cases where ECT(1) represents a second level of marking severity below CE. The one exception is that the drop condition in Table 3 need not be logged because, with TRILL, it is the result of a valid combination of events. D. Eastlake & B. Briscoe [Page 10] INTERNET-DRAFT TRILL ECN Support 4. TRILL Support for ECN Variants This section is informative, not normative; it discusses interworking between TRILL and variants of the standardized form of ECN in IP [RFC3168]. See also [RFC8311]. The ECN wire protocol for TRILL (Section 2) and the ingress (Section 3.1) and egress (Section 3.3) ECN behaviors have been designed to support the other known variants of ECN, as detailed below. New variants of ECN will have to comply with the guidelines for defining alternative ECN semantics [RFC4774]. It is expected that the TRILL ECN wire protocol is generic enough to support such potential future variants. 4.1 Pre-Congestion Notification (PCN) The PCN wire protocol [RFC6660] is recognized by the use of a PCN- compatible Diffserv codepoint in the IP header and a non-zero IP-ECN field. For TRILL or any lower layer protocol, equivalent traffic classification codepoints would have to be defined, but that is outside the scope of the current document. The PCN wire protocol is similar to ECN, except it indicates congestion with two levels of severity. It uses: o 11 (CE) as the most severe, termed the Excess-traffic-marked (ETM) codepoint o 01 ECT(1) as a lesser severity level, termed the Threshold-Marked (ThM) codepoint. (This difference between ECT(1) and ECT(0) only applies to PCN, not to the classic ECN support specified for TRILL in this document before Section 4.) To implement PCN on a transit RBridge would require a detailed specification. But in brief: o the TRILL Critical Congestion Experienced (CCE) flag would be used for the Excess-Traffic-Marked (ETM) codepoint; o ECT(1) in the TRILL-ECN field would be used for the Threshold- Marked codepoint. Then the ingress and egress behaviors defined in Section 3 would not need to be altered to ensure support for PCN as well as ECN. D. Eastlake & B. Briscoe [Page 11] INTERNET-DRAFT TRILL ECN Support 4.2 Low Latency, Low Loss, Scalable Throughput (L4S) L4S is currently on the IETF's experimental track. An outline of how a transit TRILL RBridge would support L4S [ECNL4S] is given in Appendix A. D. Eastlake & B. Briscoe [Page 12] INTERNET-DRAFT TRILL ECN Support 5. IANA Considerations IANA is requested to update the TRILL Extended Header Flags registry by replacing the lines for bits 9-13 and for bits 21-26 with the following: Bits Purpose Reference ----- ------- --------- 9-11 available non-critical hop-by-hop flags 12-13 TRILL-ECN (Explicit Congestion Notification) [this doc] 21-25 available critical ingress-to-egress flags 26 Critical Congestion Experienced (CCE) [this doc] D. Eastlake & B. Briscoe [Page 13] INTERNET-DRAFT TRILL ECN Support 6. Security Considerations TRILL support of ECN is a straightforward combination of previously specified ECN and TRILL with no significant new security considerations. For ECN tunneling security considerations, see [RFC6040]. For general TRILL protocol security considerations, see [RFC6325]. 7. Acknowledgements The helpful comments of Loa Andersson and Adam Roach are hereby acknowledged. This document was prepared with basic NROFF. All macros used were defined in the source file. D. Eastlake & B. Briscoe [Page 14] INTERNET-DRAFT TRILL ECN Support Normative References [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC4774] - Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, . [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, . [RFC7179] - Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 2014, . [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, . [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, [RFC8311] - Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, January 2018, . [ECNencapGuide] - B. Briscoe, J. Kaippallimalil, P. Thaler, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-encap-guidelines, work in progress. D. Eastlake & B. Briscoe [Page 15] INTERNET-DRAFT TRILL ECN Support Informative References [ECNL4S] - K. De Schepper, B. Briscoe, "Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queueing Delay", draft-ietf-tsvwg-ecn-l4s-id, work in progress. [IANAthFlags] - IANA TRILL Extended Header word flags: http://www.iana.org/assignments/trill-parameters/trill- parameters.xhtml#extended-header-flags [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, . [RFC6660] - Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 10.17487/RFC6660, July 2012, . D. Eastlake & B. Briscoe [Page 16] INTERNET-DRAFT TRILL ECN Support Appendix A. TRILL Transit RBridge Behavior to Support L4S The specification of the Low Latency, Low Loss, Scalable throughput (L4S) wire protocol for IP is given in [ECNL4S]. L4S is one example of the ways TRILL ECN handling may evolve [RFC8311]. It is similar to the original ECN wire protocol for IP [RFC3168], except: o An AQM that supports L4S classifies packets with ECT(1) or CE in the IP header into an L4S queue and a "Classic" queue otherwise. o The meaning of CE markings applied by an L4S queue is not the same as the meaning of a drop by a "Classic" queue (contrary to the original requirement for ECN [RFC3168]). Instead, the likelihood that the Classic queue drops packets is defined as the square of the likelihood that the L4S queue marks packets (e.g., when there is a drop probability of 0.0009 (0.09%) the L4S marking probability will be 0.03 (3%)). This seems to present a problem for the way that a transit TRILL RBridge defers the choice between marking and dropping to the egress. Nonetheless, the following pseudocode outlines how a transit TRILL RBridge can implement L4S marking in such a way that the egress behavior already described in Section 3.3 for Classic ECN [RFC3168] will produce the desired outcome. /* p is an internal variable calculated by any L4S AQM * dependent on the delay being experienced in the Classic queue. * bit13 is the least significant bit of the TRILL-ECN field */ % On TRILL transit if (bit13 == 0 ) { % Classic Queue if (p > max(random(), random()) ) mark(CCE) % likelihood: p^2 } else { % L4S Queue if (p > random() ) { if (p > random() ) mark(CCE) % likelihood: p^2 else mark(NCCE) % likelihood: p - p^2 } } With the above transit behavior, an egress that supports ECN (Section 3.3) will drop packets or propagate their ECN markings depending on whether the arriving inner header is from a non-ECN-capable or ECN- capable transport. D. Eastlake & B. Briscoe [Page 17] INTERNET-DRAFT TRILL ECN Support Even if an egress has no L4S-specific logic of its own, it will drop packets with the square of the probability that an egress would if it did support ECN, for the following reasons: o Egress with ECN support: + L4S: propagates both the Critical and Non-Critical CE marks (CCE & NCCE) as a CE mark. Likelihood: p^2 + p - p^2 = p + Classic: Propagates CCE marks as CE or drop, depending on inner. Likelihood: p^2 o Egress without ECN support: + L4S: does not propagate NCCE as a CE mark, but drops CCE marks. Likelihood: p^2 + Classic: drops CCE marks. Likelihood: p^2 D. Eastlake & B. Briscoe [Page 18] INTERNET-DRAFT TRILL ECN Support Authors' Addresses Donald E. Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Tel: +1-508-333-2270 Email: d3e3e3@gmail.com Bob Briscoe CableLabs UK Email: ietf@bobbriscoe.net URI: http://bobbriscoe.net/ D. Eastlake & B. Briscoe [Page 19] INTERNET-DRAFT TRILL ECN Support Copyright and IPR Provisions Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, 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 of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. D. Eastlake & B. Briscoe [Page 20] ./draft-ietf-v6ops-ipv6-deployment-10.txt0000644000764400076440000032433114342163020017763 0ustar iustiniustin V6OPS G. Fioccola Internet-Draft P. Volpato Obsoletes: 6036 (if approved) Huawei Technologies Intended status: Informational J. Palet Martinez Expires: 4 June 2023 The IPv6 Company G. Mishra Verizon Inc. C. Xie China Telecom 1 December 2022 IPv6 Deployment Status draft-ietf-v6ops-ipv6-deployment-10 Abstract This document provides an overview of IPv6 deployment status in 2022. Specifically, it looks at the degree of adoption of IPv6 in the industry, analyzes the remaining challenges and proposes further investigations in areas where the industry has not yet taken a clear and unified approach in the transition to IPv6. It obsoletes RFC 6036. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Fioccola, et al. Expires 4 June 2023 [Page 1] Internet-Draft IPv6 Deployment Status December 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. IPv6: The Global Picture . . . . . . . . . . . . . . . . . . 6 2.1. IPv4 Address Exhaustion . . . . . . . . . . . . . . . . . 6 2.1.1. IPv4 addresses per capita and IPv6 status . . . . . . 7 2.2. IPv6 Users . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. IPv6 Web Content . . . . . . . . . . . . . . . . . . . . 10 2.4. IPv6 public actions and policies . . . . . . . . . . . . 11 3. A Survey on IPv6 Deployments . . . . . . . . . . . . . . . . 12 3.1. IPv6 Allocations . . . . . . . . . . . . . . . . . . . . 12 3.2. IPv6 among Internet Service Providers . . . . . . . . . . 14 3.3. IPv6 among Enterprises . . . . . . . . . . . . . . . . . 14 3.3.1. Government and Universities . . . . . . . . . . . . . 15 4. IPv6 deployment scenarios . . . . . . . . . . . . . . . . . . 17 4.1. Dual-Stack . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. IPv6-only Overlay . . . . . . . . . . . . . . . . . . . . 18 4.3. IPv6-only Underlay . . . . . . . . . . . . . . . . . . . 19 4.4. IPv4 as a Service . . . . . . . . . . . . . . . . . . . . 19 4.5. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Common IPv6 Challenges . . . . . . . . . . . . . . . . . . . 21 5.1. Transition Choices . . . . . . . . . . . . . . . . . . . 21 5.1.1. Service Providers . . . . . . . . . . . . . . . . . . 21 5.1.2. Enterprises . . . . . . . . . . . . . . . . . . . . . 22 5.1.3. Industrial Internet . . . . . . . . . . . . . . . . . 23 5.1.4. Content and Cloud Service Providers . . . . . . . . . 24 5.1.5. CPEs and user devices . . . . . . . . . . . . . . . . 24 5.1.6. Software Applications . . . . . . . . . . . . . . . . 25 5.2. Network Management and Operations . . . . . . . . . . . . 25 5.3. Performance . . . . . . . . . . . . . . . . . . . . . . . 26 5.3.1. IPv6 packet loss and latency . . . . . . . . . . . . 26 5.3.2. Customer Experience . . . . . . . . . . . . . . . . . 27 5.4. IPv6 security and privacy . . . . . . . . . . . . . . . . 27 5.4.1. Protocols security issues . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 Fioccola, et al. Expires 4 June 2023 [Page 2] Internet-Draft IPv6 Deployment Status December 2022 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . 33 Appendix A. Summary of Questionnaire and Replies for network operators . . . . . . . . . . . . . . . . . . . . . . . . 41 Appendix B. Summary of Questionnaire and Replies for enterprises . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction [RFC6036] described IPv6 deployment scenarios adopted or foreseen by a number of Internet Service Providers (ISPs) who responded to a technical questionnaire in early 2010. In doing that, [RFC6036] provided practices and plans expected to take place in the following years. Since the publication of [RFC6036], several other documents have contributed to the IPv6 transition discussion in operational environments. To name a few: - [RFC6180] discussed IPv6 deployment models and transition mechanisms, recommending those proven to be effective in operational networks. - [RFC6883] provided guidance and suggestions for Internet content providers and Application Service Providers (ASPs). - [RFC7381] introduced the guidelines of IPv6 deployment for enterprises. [RFC6540] recommended the support of IPv6 to all IP-capable nodes. It was referenced in the IAB Statement on IPv6 [IAB], which represented a major step in driving the IETF as well as other Standard Developing Organizations (SDOs) towards using IPv6 in their works. In more recent times, organizations such as ETSI provided more contributions to the use of IPv6 in operational environments, targeting IPv6 in different industry segments. As a result, [ETSI-IP6-WhitePaper], was published to provide an updated view on the IPv6 best practices adopted so far, in particular in the ISP domain. Considering all of the above, and after more than ten years since the publication of [RFC6036] it is useful to assess the status of the transition to IPv6. Some reasons include: Fioccola, et al. Expires 4 June 2023 [Page 3] Internet-Draft IPv6 Deployment Status December 2022 - In some areas, the lack of IPv4 addresses forced both carriers and content providers to shift to IPv6 to support the introduction of new applications, in particular in wireless networks. - Some governmental actions took place to encourage or even enforce the adoption of IPv6 in certain countries. - Looking at the global adoption of IPv6, this seems to have reached a threshold that justifies speaking of end-to-end IPv6 connectivity, at least at the IPv6 service layer. This document aims to provide a survey of the status of IPv6 deployment and highlight both the achievements and remaining obstacles in the transition to IPv6 networks (and its coexistence with continued IPv4 services). The target is to give an updated view of the practices and plans already described in [RFC6036], to encourage further actions and more investigations in those areas that are still under discussion, and to present the main incentives for the adoption of IPv6. This document is intended for a general audience interested to understand the status of IPv6 in different industries and network domains. People who provide or use network services may find it useful for the transition to IPv6. Also, people developing plans for IPv6 adoption in an organization or in an industry may find information and references for their analysis. Attention is given to the different stages of the transition to IPv6 networks and services. In particular, a terminology on the use of "IPv6-only" is provided, considering IPv6-only networks and services as the final stage of such transition. The topics discussed in this document are organized into four main chapters. Section 2 reports data and analytics about the status of IPv6. Section 3 provides a survey of IPv6 deployments in different environments, including ISPs, enterprises and universities. Section 4 describes the IPv6 deployment approaches for Mobile BroadBand (MBB), Fixed BroadBand (FBB) and Enterprises. Section 5 analyzes the general challenges to be solved in the IPv6 transition. Specific attention is given to operations, performance and security issues. Fioccola, et al. Expires 4 June 2023 [Page 4] Internet-Draft IPv6 Deployment Status December 2022 1.1. Terminology This section defines the terminology regarding the usage of IPv6-only expressions within this document. The term IPv6-only is defined in relation to the specific scope it is referring to. In this regard, it may happen that only part of a service, of a network or even part of a node is in an IPv6-only scope and the rest is not. Below are listed the most used terms in relation to the different scopes: IPv6-only interface: It means that the interface of a node is configured to forward only IPv6. This denotes that just part of the node can be IPv6-only since the rest of the interfaces of the same node may work with IPv4 as well. A Dual-Stack interface is not an IPv6-only interface. IPv6-only node: It means that the node uses only IPv6. All interfaces of the host only have IPv6 addresses. IPv6-only service: It is used if between the host's interface and the interface of the content server, all packet headers of the service session are IPv6. IPv6-only overlay: It is used if between the end points of the tunnels, all inner packet headers of the tunnels are IPv6. For example, IPv6-only overlay in fixed network means that the encapsulation is only IPv6 between the interfaces of the Provider Edge (PE) nodes or between the Customer Provider Edge (CPE) node and the Broadband Network Gateway (BNG). IPv6-only underlay: It is used if the data plane and control plane are IPv6, but not necessarily management plane. For example, IPv6-only underlay in fixed network means that the underlay network protocol is only IPv6 between any Provider Edge (PE) nodes but they can be Dual-Stack in overlay. SRv6 is an example of IPv6-only underlay. IPv6-only network: It is used if every node in this network is IPv6-only. No IPv4 should exist in an IPv6-only network. In particular, IPv6-only network's data plane, control plane, and management plane must be IPv6. All PEs must be IPv6-only. Therefore, if tunnels exist among PEs, both inner and outer headers must be IPv6. For example, IPv6-only access network means that every node in this access network must be IPv6-only and similarly IPv6-only backbone network means that every nodes in this backbone network must be IPv6-only. Fioccola, et al. Expires 4 June 2023 [Page 5] Internet-Draft IPv6 Deployment Status December 2022 IPv4 as a Service (IPv4aaS): It means that IPv4 service support is provided by means of transition mechanism, therefore there is a combination of encapsulation/translation + IPv6-only underlay + decapsulation/translation. For an IPv6-only network, connectivity to legacy IPv4 is either non-existent or provided by IPv4aaS mechanisms. Note that IPv6-only definitions are also discussed in [I-D.palet-v6ops-ipv6-only]. 2. IPv6: The Global Picture This section deals with some key questions related to IPv6 namely: (1) the status of IPv4 exhaustion, often considered as one of the triggers to switch to IPv6, (2) the number of IPv6 end users, a primary measure to sense IPv6 adoption, (3) the percentage of websites reachable over IPv6 and (4) a report on IPv6 public actions and policies. These parameters are monitored by the Regional internet Registries (RIRs) and other institutions worldwide as they provide a first-order indication on the adoption of IPv6. 2.1. IPv4 Address Exhaustion According to [CAIR] there will be 29.3 billion networked devices by 2023, up from 18.4 billion in 2018. This poses the question on whether the IPv4 address space can sustain such a number of allocations and, consequently, if this may affect the process of its exhaustion. The answer is not straightforward as many aspects have to be considered. On one hand, the RIRs are reporting scarcity of available and still reserved addresses. Table 3 of [POTAROO1] (January 2022) shows that the available pool of the five RIRs at the end of 2021 counted 5.2 million IPv4 addresses, while the reserved pool included another 12 million, for a total of 17.3 million IPv4 addresses (-5.5% year over year, comparing 2021 against 2020). The same reference, in table 1, shows that the total IPv4 allocated pool equaled to 3.685 billion addresses (+0.027% year over year). The ratio between the available addresses and the total allocated brought to 0.469% of the remaining IPv4 address space (from 0.474% at the end of 2020). On the other, [POTAROO1] again highlights the role of both address transfer and Network Address Translation (NAT) to counter the IPv4 exhaustion. The transfer of IPv4 addresses can be done under the control or registration of a RIR or on the so-called grey market where third parties operate to enable the buy/sell of IPv4 addresses. Fioccola, et al. Expires 4 June 2023 [Page 6] Internet-Draft IPv6 Deployment Status December 2022 In all cases, a set of IPv4 addresses is "transferred" to a different holder that has the need to expand their address range. As an example, [IGP-GT] and [NRO] show the amount of transfers to recipient organizations in the different regions. Cloud Service Providers (CSPs) appear to be the most active in buying IPv4 addresses to satisfy their need of providing IPv4 connectivity to their tenants. NAT systems provide a means to absorb at least a portion of the demand of public IPv4 addresses as they enable the use of private addressing in internal networks while limiting the use of public addresses on their WAN-facing side. In the case of NAT, architectural and operational issues remain. Private address space cannot provide adequate address span, especially for large organizations, and the reuse of addresses may make the network more complex. In addition, multiple levels of address translation may coexist in a network, e.g. Carrier-Grade NAT (CGN) [RFC6264] based on two stages of translation. This comes with an economic and operational burden, as discussed later in this document. 2.1.1. IPv4 addresses per capita and IPv6 status The IPv4 addresses per capita ratio measures the quantity of IPv4 addresses allocated to a given country divided by the population of that country. It provides an indication of the imbalanced distribution of the IPv4 addresses worldwide. It clearly derives from the allocation of addresses made in the early days of the Internet. The sources for measuring the IPv4 addresses per capita ratio are the allocations done by the RIRs and the statistics about the world population. In this regard, [POTAROO2] provides distribution files. The next tables compare the number of IPv4 addresses available per person in a certain country (IPv4 address per capita) against the relative adoption of IPv6 in the same country (expressed as the number of IPv6 capable users in the considered country). The table shows just a subset of the data available from [POTAROO2]. In particular, the following table provides the data for the 25 most populated countries in the world. The table is ordered based on the IPv4 addresses per capita ratio and the data refer to the 1st of January 2022. +----------------------------+---------------+---------------+ |Country |IPv4 per capita|IPv6 deployment| +----------------------------+---------------+---------------+ |United States of America | 4.89| 47.1%| +----------------------------+---------------+---------------+ |United Kingdom | 1.65| 33.2%| +----------------------------+---------------+---------------+ |Japan | 1.50| 36.7%| Fioccola, et al. Expires 4 June 2023 [Page 7] Internet-Draft IPv6 Deployment Status December 2022 +----------------------------+---------------+---------------+ |Germany | 1.48| 53.0%| +----------------------------+---------------+---------------+ |France | 1.27| 42.1%| +----------------------------+---------------+---------------+ |Italy | 0.91| 4.7%| +----------------------------+---------------+---------------+ |South Africa | 0.46| 2.4%| +----------------------------+---------------+---------------+ |Brazil | 0.41| 38.7%| +----------------------------+---------------+---------------+ |Russian Federation | 0.31| 9.7%| +----------------------------+---------------+---------------+ |China | 0.24| 60.1%(*)| +----------------------------+---------------+---------------+ |Egypt | 0.24| 4.3%| +----------------------------+---------------+---------------+ |Mexico | 0.23| 41.8%| +----------------------------+---------------+---------------+ |Turkey | 0.20| 0.2%| +----------------------------+---------------+---------------+ |Vietnam | 0.17| 48.0%| +----------------------------+---------------+---------------+ |Iran (Islamic Republic) | 0.15| 0.1%| +----------------------------+---------------+---------------+ |Thailand | 0.13| 40.8%| +----------------------------+---------------+---------------+ |Indonesia | 0.07| 5.0%| +----------------------------+---------------+---------------+ |Philippines | 0.05| 13.8%| +----------------------------+---------------+---------------+ |India | 0.03| 76.9%| +----------------------------+---------------+---------------+ |Pakistan | 0.03| 2.1%| +----------------------------+---------------+---------------+ |United Republic of Tanzania | 0.02| 0.0%| +----------------------------+---------------+---------------+ |Nigeria | 0.02| 0.2%| +----------------------------+---------------+---------------+ |Bangladesh | 0.01| 0.3%| +----------------------------+---------------+---------------+ |Ethiopia | 0.00| 0.0%| +----------------------------+---------------+---------------+ |Democratic Republic of Congo| 0.00| 0.1%| +----------------------------+---------------+---------------+ Figure 1: IPv4 per capita and IPv6 deployment for the top 25 most populated countries in the world, 1st of January 2022 Fioccola, et al. Expires 4 June 2023 [Page 8] Internet-Draft IPv6 Deployment Status December 2022 (*) The IPv6 deployment information in China is derived from [CN-IPv6]. A direct correlation between low IPv4 per capita and high IPv6 adoption is not immediate, yet some indications emerge. For example, countries such as Brazil, China, and India have clearly moved towards IPv6 adoption. As discussed later, this appears related to several factors in addition to the lack of IPv4 addresses, including local regulation and market-driven actions. The 5 countries at the top of the table, with relative high availability of IPv4 addresses, have also shown a good level of IPv6 adoption. In other cases, a relative scarcity of IPv4 addresses has not meant a clear move towards IPv6, as several countries listed in the table still have low or very low IPv6 adoption. 2.2. IPv6 Users The count of the IPv6 users is the key parameter to get an immediate understanding of the adoption of IPv6. Some organizations constantly track the usage of IPv6 by aggregating data from several sources. As an example, the Internet Society constantly monitors the volume of IPv6 traffic for the networks that joined the WorldIPv6Launch initiative [WIPv6L]. The measurement aggregates statistics from organizations such as [Akm-stats] that provides data down to the single network level measuring the number of hits to their content delivery platform. For the scope of this document, the approach used by APNIC to quantify the adoption of IPv6 by means of a script that runs on a user's device [CAIDA] is considered. To give a rough estimation of the relative growth of IPv6, the next table aggregates the total number of estimated IPv6-capable users at 1st of January 2022, and compares it against the total Internet users, as measured by [POTAROO2]. +--------+--------+--------+--------+--------+--------+--------+ | | Jan | Jan | Jan | Jan | Jan | CAGR | | | 2018 | 2019 | 2020 | 2021 | 2022 | | +--------+--------+--------+--------+--------+--------+--------+ | IPv6 | 513.07| 574.02| 989.25|1,136.28|1,207.61| 23.9% | +--------+--------+--------+--------+--------+--------+--------+ | World |3,410.27|3,470.36|4,065.00|4,091.62|4,093.69| 4.7% | +--------+--------+--------+--------+--------+--------+--------+ | Ratio | 15.0%| 16.5%| 24.3%| 27.8%| 29.5%| 18.4% | +--------+--------+--------+--------+--------+--------+--------+ Figure 2: IPv6-capable users against total (in millions) as of 1st of January 2022 Fioccola, et al. Expires 4 June 2023 [Page 9] Internet-Draft IPv6 Deployment Status December 2022 Two figures appear: first, the IPv6 Internet population is growing with a two-digits Compound Annual Growth Rate (CAGR), and second, the ratio IPv6 over total is also growing steadily. 2.3. IPv6 Web Content [W3Techs] keeps track of the use of several technical components of websites worldwide through different analytical engines. The utilization of IPv6 for websites is shown in the next table, where the percentages refer to the websites which are accessible over IPv6. +------------+-------+-------+-------+-------+-------+------+ | Worldwide | Jan | Jan | Jan | Jan | Jan | CAGR | | Websites | 2018 | 2019 | 2020 | 2021 | 2022 | | +------------+-------+-------+-------+-------+-------+------+ |% of IPv6 | 11.4% | 13.3% | 15.0% | 17.5% | 20.6% | 15.9%| +------------+-------+-------+-------+-------+-------+------+ Figure 3: Usage of IPv6 in websites, January 2022 Looking at the growth rate, it may appear not particularly high. It has to be noted, though, that not all websites are equal. The largest content providers, which already support IPv6, generate a lot more content than small websites. [Csc6lab] measured at the beginning of January 2022 that out of the world top 500 sites ranked by [Alx], 203 are IPv6-enabled (+3.6% from January 2021 to January 2022). If we consider that the big content providers (such as Google, Facebook, Netflix) generate more than 50% of the total mobile traffic [SNDVN], and in some cases even more up to 65% ([ISOC1] [HxBld]), the percentage of content accessible over IPv6 is clearly more relevant than the number of enabled IPv6 websites. It would be interesting to know what percentage of that 50% of all mobile traffic is IPv6. Unfortunately, this information is not available. Related to that, a question that sometimes arises is whether the content stored by content providers would be all accessible on IPv6 in the hypothetical case of a sudden IPv4 switch-off. Even if this is pure speculation, the numbers above may bring to state that this is likely the case. This would reinforce the common thought that, in quantitative terms, most of the content is accessible via IPv6. Fioccola, et al. Expires 4 June 2023 [Page 10] Internet-Draft IPv6 Deployment Status December 2022 2.4. IPv6 public actions and policies As previously noted, the worldwide deployment of IPv6 is not uniform [G_stats], [APNIC1]. It is worth noticing that, in some cases, higher IPv6 adoption in certain countries has been achieved as a consequence of actions taken by the local governments through regulation or incentive to the market. Looking at the European Union area, countries such as Belgium, France and Germany are well ahead in terms of IPv6 adoption. In the case of Belgium, the Belgian Institute for Postal services and Telecommunications (BIPT) acted to mediate an agreement between the local ISPs and the government to limit the use of Carrier-Grade NAT (CGN) systems and of public IPv4 addresses for lawful investigations in 2012 [BIPT]. The agreement limited the use of one IPv4 address per 16 customers behind NAT. The economic burden sustained by the ISPs for the unoptimized use of NAT induced the shift to IPv6 and its increased adoption in the latest years. In France, the National Regulator (Autoritee de regulation des communications electroniques, or Arcep) introduced an obligation for the mobile carriers awarded with a license to use 5G frequencies (3.4-3.8GHz) in Metropolitan France to be IPv6 compatible [ARCEP]. As stated, "the goal is to ensure that services are interoperable and to remove obstacles to using services that are only available in IPv6, as the number of devices in use continues to soar, and because the RIPE NCC has run out of IPv4 addresses". A slow adoption of IPv6 could prevent new Internet services to widespread or create a barrier to entry for newcomers to the market. "IPv6 can help to increase competition in the telecom industry, and help to industrialize a country for specific vertical sectors". Increased IPv6 adoption in Germany depended on a mix of industry and public actions. Specifically, the Federal Office for Information Technology (under the Federal Ministry of the Interior) issued over the years a few recommendations on the use of IPv6 in the German public administration. The latest guideline in 2019 constitutes a high-level road map for mandatory IPv6 introduction in the federal administration networks [GFA]. In the United States, the Office of Management and Budget is also calling for IPv6 adoption [US-FR], [US-CIO]. These documents define a plan to have the 80% of the US Federal IP-capable networks based on IPv6-only by the year 2025. China is another example of government which is supporting a country-wide IPv6 adoption [CN]. In India, the high adoption of IPv6 took origin from the decision of Reliance Jio to move to IPv6 in their networks [RelJio]. In addition, the Department of Telecommunications (under the Ministry of Fioccola, et al. Expires 4 June 2023 [Page 11] Internet-Draft IPv6 Deployment Status December 2022 Communications and Information Technology) issued guidelines for the progressive adoption of IPv6 in public and private networks. The latest one dates 2021 [IDT] and fosters further moves to IPv6 connection services. 3. A Survey on IPv6 Deployments This section discusses the status of IPv6 adoption in service providers and enterprises' networks. 3.1. IPv6 Allocations RIRs are responsible for allocating IPv6 address blocks to ISPs, LIRs (Local Internet Registries) as well as enterprises or other organizations. An ISP/LIR will use the allocated block to assign addresses to their end users. The following table shows the amount of individual allocations, per RIR, in the time period 2017-2021 [APNIC2]. +---------+-------+-------+-------+-------+-------+---------+------+ | Registry| Dec | Dec | Dec | Dec | Dec |Cumulated| CAGR | | | 2017 | 2018 | 2019 | 2020 | 2021 | | | +---------+-------+-------+-------+-------+-------+---------+------+ | AFRINIC | 112 | 110 | 115 | 109 | 136 | 582 | 51% | | APNIC | 1,369 | 1,474 | 1,484 | 1,498 | 1,392 | 7,217 | 52% | | ARIN | 684 | 659 | 605 | 644 | 671 | 3,263 | 48% | | LACNIC | 1,549 | 1,448 | 1,614 | 1,801 | 730 | 7,142 | 47% | | RIPE NCC| 2,051 | 2,620 | 3,104 | 1,403 | 2,542 | 11,720 | 55% | | | | | | | | | | | Total | 5,765 | 6,311 | 6,922 | 5,455 | 5,471 | 29,924 | 51% | +---------+-------+-------+-------+-------+-------+---------+------+ Figure 4: IPv6 allocations worldwide in the period 2017-2021 (January 2022) The trend shows the steady progress of IPv6. The decline of IPv6 allocations in 2020 and 2021 may be due to COVID-19 pandemic. It also happens to IPv4 allocations. [APNIC2] also compares the number of allocations for both address families. The CAGR looks quite similar in 2021 but a little higher for the IPv4 allocations in comparison to the IPv6 allocations (53.6% versus 50.9%). Fioccola, et al. Expires 4 June 2023 [Page 12] Internet-Draft IPv6 Deployment Status December 2022 +--------+-------+-------+-------+-------+-------+----------+------+ | Address| Dec | Dec | Dec | Dec | Dec | Cumulated| CAGR | | family | 2017 | 2018 | 2019 | 2020 | 2021 | | | +--------+-------+-------+-------+-------+-------+----------+------+ | IPv6 | 5,765 | 6,311 | 6,922 | 5,455 | 5,471 | 29,924 | 50.9%| | | | | | | | | | | IPv4 | 8,091 | 9,707 |13,112 | 6,263 | 7,829 | 45,002 | 53.6%| | | | | | | | | | +--------+-------+-------+-------+-------+-------+----------+------+ Figure 5: Allocations per address family The reason may be that the IPv4 allocations in 2021 include many allocations of small address ranges (e.g. /24) [APNIC2]. On the contrary, a single IPv6 allocation is large enough to cope with the need of an operator for long period. After an operator receives an IPv6 /30 or /32 allocation it is unlikely that a new request of addresses is repeated in the short term. The next table is based on [APNIC3], [APNIC4] and shows the percentage of Autonomous Systems (AS) supporting IPv6 compared to the total ASes worldwide. The number of IPv6-capable ASes increased from 24.3% in January 2018 to 38.7% in January 2022. This equals to 18% CAGR for IPv6-enabled networks. In comparison, the CAGR for the total of IPv6 and IPv4 networks is just 5%. +------------+-------+-------+-------+-------+-------+------+ | Advertised | Jan | Jan | Jan | Jan | Jan | CAGR | | ASN | 2018 | 2019 | 2020 | 2021 | 2022 | | +------------+-------+-------+-------+-------+-------+------+ |IPv6-capable| 14,500| 16,470| 18,650| 21,400| 28,140| 18% | | | | | | | | | | Total ASN | 59,700| 63,100| 66,800| 70,400| 72,800| 5% | | | | | | | | | | Ratio | 24.3% | 26.1% | 27.9% | 30.4% | 38.7% | | +------------+-------+-------+-------+-------+-------+------+ Figure 6: Percentage of IPv6-capable ASes The tables above provide an aggregated view of the allocations dynamic. The next subsections will zoom into each specific domain to highlight its relative status. Fioccola, et al. Expires 4 June 2023 [Page 13] Internet-Draft IPv6 Deployment Status December 2022 3.2. IPv6 among Internet Service Providers As it was proposed at the time of [RFC6036], also in the case of this document a survey was submitted to a group of service providers in Europe during the third quarter of 2020 (see Appendix A for the complete poll), to understand their plans about IPv6 and their technical preferences towards its adoption. Although such poll does not give an exhaustive view on the IPv6 status, it provides some insights that are relevant to the discussion. The poll revealed that the majority of the ISPs interviewed had plans concerning IPv6 (79%). Of them, 60% had already ongoing activities, while 33% was expected to start activities in a 12-months time-frame. The transition to IPv6 involved all business segments: mobile (63%), fixed (63%), and enterprises (50%). The reasons to move to IPv6 varied. Global IPv4 address depletion and the run out of private address space recommended in [RFC1918] were reported as the important drivers for IPv6 deployment (48%). In a few cases, respondents cited the requirement of national IPv6 policies and the launch of 5G as the reasons (13%). Enterprise customers demand was also a reason to introduce IPv6 (13%). From a technical preference standpoint, Dual-Stack [RFC4213] was the most adopted solution, in both wireline (59%) and cellular networks (39%). In wireline, the second most adopted mechanism was Dual-Stack Lite (DS-Lite) [RFC6333] (19%). In cellular networks, the second preference was 464XLAT [RFC6877] (21%). More details about the answers received can be found in Appendix A. 3.3. IPv6 among Enterprises As described in [RFC7381], enterprises face different challenges than ISPs. Publicly available reports show how the enterprise deployment of IPv6 lags behind ISP deployment [cmpwr]. [NST_1] provides estimations on deployment status of IPv6 for domains such as example.com, example.net or example.org in the United States. The measurement encompasses many industries, including telecommunications, so the term "enterprises" is a bit loose in this context. In any case, it provides a first indication of IPv6 adoption in several US industry sectors. The analysis tries to infer whether IPv6 is supported by looking from "outside" a company's network. It takes into consideration the support of IPv6 to external services such as Domain Name System (DNS), mail and website. [BGR_1] has similar data for China while [CNLABS_1] provides the status in India. Fioccola, et al. Expires 4 June 2023 [Page 14] Internet-Draft IPv6 Deployment Status December 2022 +--------------+----------+---------+---------+---------+ |Country | Domains | DNS | Mail | Website | | | analyzed | | | | +--------------+----------+---------+---------+---------+ |China | 478 | 74.7% | 0.0% | 19.7% | | | | | | | +--------------+----------+---------+---------+---------+ |India | 104 | 51.9% | 15.4% | 16.3% | | | | | | | +--------------+----------+---------+---------+---------+ |United States | 1070 | 66.8% | 21.2% | 6.3% | |of America | | | | | +--------------+----------+---------+---------+---------+ Figure 7: IPv6 support for external-facing services across enterprises (January 2022) A poll submitted to a group of large enterprises in North America in early 2021 (see Appendix B) shows that the operational issues are even more critical than for ISPs. Looking at current implementations, almost one third has dual-stacked networks, while 20% declares that portions of their networks are IPv6-only. 35% of the enterprises are stuck at the training phase. In no case is the network fully IPv6-based. Speaking of training, the most critical needs are in the field of IPv6 security and IPv6 troubleshooting (both highlighted by the two thirds of respondents), followed by IPv6 fundamentals (57.41%). Coming to implementation, the three areas of concern are IPv6 security (31.48%), training (27.78%), application conversion (25.93%). 33.33% of respondents think that all three areas are all simultaneously of concern. The full poll is reported in Appendix B. 3.3.1. Government and Universities This section focuses specifically on the IPv6 adoption of governments and academia. Fioccola, et al. Expires 4 June 2023 [Page 15] Internet-Draft IPv6 Deployment Status December 2022 As far as governmental agencies are concerned, [NST_2] provides analytics on the degree of IPv6 support for DNS, mail and websites across second level domains associated with the US federal agencies. These domains are in the form of example.gov or example.fed. The script used by [NST_2] has also been employed to measure the same analytics in other countries: China [BGR_2], India [CNLABS_2] and the European Union [IPv6Forum]. For this latter analytic some post- processing is necessary to filter out the non-European domains. +--------------+----------+---------+---------+---------+ |Country | Domains | DNS | Mail | Website | | | analyzed | | | | +--------------+----------+---------+---------+---------+ |China | 52 | 0.0% | 0.0% | 98.1% | | | | | | | +--------------+----------+---------+---------+---------+ |European | 19 | 47.4% | 0.0% | 21.1% | |Union (*) | | | | | +--------------+----------+---------+---------+---------+ |India | 618 | 7.6% | 6.5% | 7.1% | | | | | | | +--------------+----------+---------+---------+---------+ |United States | 1283 | 87.1% | 14.0% | 51.7% | |of America | | | | | +--------------+----------+---------+---------+---------+ Figure 8: IPv6 support for external-facing services across governmental institutions (January 2022) (*) Both EU and country specific domains are considered. USA's IPv6 support is higher than other countries. This is likely due to the IPv6 mandate set by [US-CIO]. In the case of India, the degree of support seems still quite low. This is also true for China, with the notable exception of high percentage of IPv6-enabled websites for government-related organizations. Similar statistics are also available for higher education. [NST_3] measures the data from second level domains of universities in the US, such as example.edu. [BGR_3] looks at Chinese education-related domains. [CNLABS_1] analyzes domains in India (mostly third level), while [IPv6Forum] lists universities in the European Union (second level), again after filtering the non-European domains. Fioccola, et al. Expires 4 June 2023 [Page 16] Internet-Draft IPv6 Deployment Status December 2022 +--------------+----------+---------+---------+---------+ |Country | Domains | DNS | Mail | Website | | | analyzed | | | | +--------------+----------+---------+---------+---------+ |China | 111 | 36.9% | 0.0% | 77.5% | | | | | | | +--------------+----------+---------+---------+---------+ |European | 118 | 83.9% | 43.2% | 35.6% | |Union | | | | | +--------------+----------+---------+---------+---------+ |India | 100 | 31.0% | 54.0% | 5.0% | | | | | | | +--------------+----------+---------+---------+---------+ |United States | 346 | 49.1% | 19.4% | 21.7% | |of America | | | | | +--------------+----------+---------+---------+---------+ Figure 9: IPv6 support for external-facing services across universities (January 2022) Overall, the universities have wider support of IPv6-based services compared to the other sectors. Apart from a couple of exceptions (e.g. the support of IPv6 mail in China and IPv6 websites in India), the numbers shown in the table above indicate a good support of IPv6 in academia. 4. IPv6 deployment scenarios The scope of this section is to discuss the network and service scenarios applicable for the transition to IPv6. Most of the related definitions have been provided in Section 1.1. This clause is intended to focus on the technical and operational characteristics. The sequence of scenarios described here does not have necessarily to be intended as a road map for the IPv6 transition. Depending on their specific plans and requirements, service providers may either adopt the scenarios proposed in a sequence or jump directly to a specific one. 4.1. Dual-Stack Based on the answers provided by network operators to the poll (Appendix A), Dual-Stack [RFC4213] appears to be currently the most widely deployed IPv6 solution (about 50%, see both Appendix A and the statistics reported in [ETSI-IP6-WhitePaper]). With Dual-Stack, IPv6 can be introduced together with other network upgrades and many parts of network management and IT systems can still work in IPv4. This avoids major upgrade of such systems to Fioccola, et al. Expires 4 June 2023 [Page 17] Internet-Draft IPv6 Deployment Status December 2022 support IPv6, which is possibly the most difficult task in the IPv6 transition. The cost and effort on the network management and IT systems upgrade are moderate. The benefits are to start using IPv6 and save NAT costs. Although Dual-Stack may provide advantages in the introductory stage, it does have a few disadvantages in the long run, like the duplication of the network resources and states. It also requires more IPv4 addresses, thus increasing both Capital Expenses (CAPEX) and Operating Expenses (OPEX). For example, even if private addresses are used with Carrier-Grade NAT (CGN), there is extra investment in the CGN devices, logs storage and help-desk to track CGN-related issues. For this reason, when IPv6 usage exceeds certain threshold, it may be advantageous to start a transition to a next scenario. For example, the process may start with the IPv4aaS stage, as described hereinafter. It is difficult to establish the criterion for switching (e.g. to properly identify the upper bound of the IPv4 decrease or the lower bound of the IPv6 increase). In addition to the technical factors, the switch to the next scenarios may also cause a loss of customers. Based on the feedback of network operators participating in World IPv6 Launch [WIPv6L] in June 2021, 108 out of 346 operators exceed 50% of IPv6 traffic volume (31.2%), 72 exceed 60% (20.8%), while 37 exceed 75% (10.7%). The consensus to move to IPv6-only might be reasonable when IPv6 traffic volume is between 50% and 60%. 4.2. IPv6-only Overlay As defined in Section 1.1, IPv6-only is generally associated with a scope, e.g. IPv6-only overlay or IPv6-only underlay. The IPv6-only overlay denotes that the overlay tunnel between the end points of a network is based only on IPv6. Tunneling provides a way to use an existing IPv4 infrastructure to carry IPv6 traffic. IPv6 or IPv4 hosts and routers can tunnel IPv6 packets over IPv4 regions by encapsulating them within IPv4 packets. The approach with IPv6-only overlay helps to maintain compatibility with the existing base of IPv4, but it is not a long-term solution. As a matter of fact, IPv4 reachability must be provided for a long time to come over IPv6 for IPv6-only hosts. Most ISPs are leveraging CGN to extend the life of IPv4 instead of going with IPv6-only solutions. Fioccola, et al. Expires 4 June 2023 [Page 18] Internet-Draft IPv6 Deployment Status December 2022 4.3. IPv6-only Underlay IPv6-only underlay network uses IPv6 as the network protocol for all traffic delivery. Both the control and data planes are IPv6-based. The definition of IPv6-only underlay needs to be associated with a scope in order to identify the domain where it is applicable, such as IPv6-only access network or IPv6-only backbone network. When both enterprises and service providers begin to transit from an IPv4/MPLS backbone to introduce IPv6 in the underlay, they do not necessarily need to dual-stack the underlay. Forwarding plane complexity on the Provider (P) nodes of the ISP core should be kept simple as a single protocol only backbone. Hence, when operators decide to transit to an IPv6 underlay, the ISP backbone should be IPv6-only while Dual-Stack is not the best choice. The underlay could be IPv6-only and allows IPv4 packets to be tunneled using VPN over an IPv6-only backbone and leveraging [RFC8950], which specifies the extensions necessary to allow advertising IPv4 Network Layer Routing Information (NLRI) with an IPv6 Next Hop. IPv6-only underlay network deployment for access and backbone network, seems not the first option and the current trend is to keep IPv4/MPLS Data Plane and run IPv4/IPv6 Dual-Stack to edge nodes. As ISPs do the transition in the future to an IPv6-only access network or backbone network, e.g. Segment Routing over IPv6 data plane (SRv6), they start the elimination of IPv4 from the underlay transport network while continuing to provide IPv4 services. Basically, as also showed by the poll among network operators, from a network architecture perspective, it is not recommended to apply Dual-Stack to the transport network per reasons mentioned above related to the forwarding plane complexities. 4.4. IPv4 as a Service IPv4aaS can be used to ensure IPv4 support and it can be a complex decision that depends on several factors, such as economic aspects, policy and government regulation. [RFC9313] compares the merits of the most common transition solutions for IPv4aaS, i.e. 464XLAT [RFC6877], DS-lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596], MAP-E [RFC7597], and MAP-T [RFC7599], but does not provide an explicit recommendation. However, the poll in Appendix A indicates that the most widely deployed IPv6 transition solution in the Mobile Broadband (MBB) domain is 464XLAT while in the Fixed Broadband (FBB) domain is DS-Lite. Fioccola, et al. Expires 4 June 2023 [Page 19] Internet-Draft IPv6 Deployment Status December 2022 Both are IPv4aaS solutions by leveraging IPv6-only underlay. IPv4aaS offers Dual-Stack service to users and allows an ISP to run IPv6-only in the network, typically the access network. While it may not always be the case, IPv6-only transition technologies such as 464XLAT require far fewer IPv4 addresses [RFC9313], because they make a more efficient usage without restricting the number of ports per subscriber. This helps to reduce troubleshooting costs and to remove some operational issues related to permanent block-listing of IPv4 address blocks when used via CGN in some services. IPv4aaS may be facilitated by the natural upgrade or replacement of CPEs because of newer technologies (tripe-play, higher bandwidth WAN links, better Wi-Fi technologies, etc.). The CAPEX and OPEX of other parts of the network may be lowered (for example CGN and associated logs) due to the operational simplification of the network. For deployments with a large number of users (e.g. large mobile operators) or a large number of hosts (e.g. large DCs), even the full private address space [RFC1918] is not enough. Also, Dual-Stack will likely lead to duplication of network resources and operations to support both IPv6 and IPv4, which increases the amount of state information in the network. This suggests that for scenarios such as MBB or large DCs, IPv4aaS could be more efficient from the start of the IPv6 introduction. So, in general, when the Dual-Stack disadvantages outweigh the IPv6-only complexity, it makes sense to transit to IPv4aaS. Some network operators already started this process, as in the case of [TMus], [RelJio] and [EE]. 4.5. IPv6-only IPv6-only is the final stage of the IPv6 transition and it happens when a complete network, end-to-end, no longer has IPv4. No IPv4 address is configured for network management or anything. Since IPv6-only means that both underlay network and overlay services are only IPv6, it will take longer to happen. Fioccola, et al. Expires 4 June 2023 [Page 20] Internet-Draft IPv6 Deployment Status December 2022 5. Common IPv6 Challenges This section lists common IPv6 challenges, which have been validated and discussed during several meetings and public events. The scope is to encourage more investigations. Despite IPv6 has already been well-proven in production, there are some challenges to consider. In this regard, it is worth noting that [ETSI-GR-IPE-001] also discusses gaps that still exist in IPv6 related use cases. 5.1. Transition Choices A service provider, an enterprise or a CSP may perceive quite a complex task the transition to IPv6, due to the many technical alternatives available and the changes required in management and operations. Moreover, the choice of the method to support the transition is an important challenge and may depend on factors specific to the context, such as the IPv6 network design that fits the service requirements, the network operations and the deployment strategy. This section briefly highlights the approaches that the different parties may take and the related challenges. 5.1.1. Service Providers For fixed operators, the massive software upgrade of CPEs to support Dual-Stack already started in most of the service provider networks. On average, looking at the global statistics, the IPv6 traffic percentage is currently around 40% [G_stats]. As highlighted in section 3.2, all major content providers have already implemented Dual-Stack access to their services and most of them have implemented IPv6-only in their Data Centers. This aspect could affect the decision on the IPv6 adoption for an operator, but there are also other factors like the current IPv4 address shortage, CPE costs, CGN costs and so on. Fixed Operators with a Dual-Stack architecture, can start defining and apply a new strategy when reaching the limit in terms of number of IPv4 addresses available. This may be done through CGN or with an IPv4aaS approach. Most of the fixed operators remain attached to a Dual-Stack architecture and many have already employed CGN. In this case it is likely that CGN boosts their ability to supply IPv4 connectivity to CPEs for more years to come. Indeed, only few fixed operators have chosen to move to an IPv6-only scenario. Fioccola, et al. Expires 4 June 2023 [Page 21] Internet-Draft IPv6 Deployment Status December 2022 For mobile operators, the situation is quite different since, in some cases, mobile operators are already stretching their IPv4 address space. The reason is that CGN translation limits have been reached and no more IPv4 public pool addresses are available. Some mobile operators choose to implement Dual-Stack as first and immediate mitigation solution. Other mobile operators prefer to move to IPv4aaS solutions (e.g. 464XLAT) since Dual-Stack only mitigates and does not solve completely the IPv4 address scarcity issue. For both fixed and mobile operators the approach for the transition is not unique and this brings different challenges in relation to the network architecture and related costs. So each operator needs to do own evaluations for the transition based on the specific situation. 5.1.2. Enterprises At present, the usage of IPv6 for enterprises often relies on upstream service providers, since the enterprise connectivity depends on the services provided by their upstream provider. Regarding the enterprises internal infrastructure, IPv6 shows its advantages in the case of merger and acquisition, because it can be avoided the overlapping of the two address spaces, which is common in case of IPv4 private addresses. In addition, since several governments are introducing IPv6 policy, all the enterprises providing consulting service to governments are also required to support IPv6. However, enterprises face some challenges. They are shielded from IPv4 address depletion issues due to their prevalent use of Proxy and private addressing [RFC1918], thus do not have the business requirement or technical justification to transit to IPv6. Enterprises need to find a business case and a strong motivation for IPv6 transition to justify additional CAPEX and OPEX. Also, since Information and Communication Technologies (ICT) is not the core business for most of the enterprises, ICT budget is often constrained and cannot expand considerably. But, there are examples of big enterprises that are considering IPv6 to achieve business targets through a more efficient IPv6 network and to introduce newer services which require IPv6 network architecture. Enterprises worldwide, in particular small and medium-sized, are quite late to adopt IPv6, especially on internal networks. In most cases, the enterprise engineers and technicians do not have a great experience with IPv6 and the problem of application porting to IPv6 looks quite difficult. As highlighted in the relevant poll, the technicians may need to get trained but the management do not see a Fioccola, et al. Expires 4 June 2023 [Page 22] Internet-Draft IPv6 Deployment Status December 2022 business need for adoption. This creates an unfortunate cycle where the perceived complexity of the IPv6 protocol and concerns about security and manageability combine with the lack of urgent business needs to prevent adoption of IPv6. In 2019 and 2020, there has been a concerted effort by some ARIN and APNIC initiatives to provide training [ARIN-CG] [ISIF-ASIA-G]. 5.1.3. Industrial Internet In an industrial environment, OT (Operational technology) refers to the systems used to monitor and control processes within a factory or production environment, while IT (Information technology) refers to anything related to computer technology and networking connectivity. IPv6 is frequently mentioned in relation to Industry 4.0 and Internet of Things (IoT), affecting both OT and IT evolution. There are potential advantages for using IPv6 for Industrial Internet of Things (IIoT), in particular the large IPv6 address space, the automatic IPv6 address configuration and resource discovery. However, its industrial adoption, in particular in smart manufacturing systems, has been much slower than expected. There are still many obstacles and challenges that prevent its pervasive use. The key problems identified are the incomplete or underdeveloped tool support, the dependency on manual configuration and the poor knowledge of the IPv6 protocols. To promote the use of IPv6 for smart manufacturing systems and IIoT applications a generic approach to remove these pain points is highly desirable. Indeed, as for enterprises, it is important to provide an easy way to familiarize system architects and software developers with the IPv6 protocol. Advances in cloud-based platforms and developments in artificial intelligence (AI) and machine learning (ML) allow OT and IT systems to integrate and migrate to a centralized analytical, processing, and integrated platform, which must act in real-time. The limitation is that manufacturing companies have diverse corporate cultures and the adoption of new technologies may lag as a result. For Industrial Internet and related IIoT applications, it would be desirable to leverage the configuration-less characteristic of IPv6 to automatically manage and control the IoT devices. In addition, it could be interesting to have the ability to use IP based communication and standard application protocols at every point in the production process and further reduce the use of specialized communication systems. Fioccola, et al. Expires 4 June 2023 [Page 23] Internet-Draft IPv6 Deployment Status December 2022 5.1.4. Content and Cloud Service Providers The high number of addresses required to connect the virtual and physical elements in a Data Center and the necessity to overcome the limitation posed by [RFC1918] have been the drivers to the adoption of IPv6 in several CSP networks. Most CSPs have adopted IPv6 in their internal infrastructure but are also active in gathering IPv4 addresses on the transfer market to serve the current business needs of IPv4 connectivity. As noted in the previous section, most enterprises do not consider the transition to IPv6 as a priority. To this extent, the use of IPv4-based network services by the CSPs will last. Several public references, as reported hereinafter, discuss how most of the major players find themselves at different stages in the transition to IPv6-only in their Data Center (DC) infrastructure. In some cases, the transition already happened and the DC infrastructure of these hyperscalers is completely based on IPv6. It is interesting to look at how much traffic in a network is going to Caches and Content Delivery Networks (CDNs). The response is expected to be a high percentage, at least higher than 50% in most of the cases, since all the key Caches and CDNs are IPv6-ready [Cldflr], [Ggl], [Ntflx], [Amzn], [Mcrsft], [Vrzn]. So the percentage of traffic going to the key Caches/CDNs is a good approximation of the potential IPv6 traffic in a network. The challenges for CSPs are mainly related to the continuous support of IPv4 to be guaranteed, since most CSPs already completed the transition to IPv6-only. If, in the next years, the scarcity of IPv4 addresses becomes more evident, it is likely that the cost of buying an IPv4 address by a CSP could be charged to their customers. 5.1.5. CPEs and user devices It can be noted that most of the user devices (e.g. smartphones) are already IPv6-enabled since many years. But there are exceptions, for example, smartTVs typically had IPv6 support since few years ago, however not all the economies replace them at the same pace. As already mentioned, ISPs who historically provided public IPv4 addresses to their customers generally still have those IPv4 addresses (unless they chose to transfer them). Some have chosen to put new customers on CGN but without touching existing customers. Because of the extreme small number of customers who notice that IPv4 is done via NAT444 (i.e. the preferred CGN solution for carriers), it could be less likely to run out of IPv4 addresses and private IPv4 Fioccola, et al. Expires 4 June 2023 [Page 24] Internet-Draft IPv6 Deployment Status December 2022 space. But as IPv4-only devices and traffic reduce, then the need to support private and public IPv4 become less. So the complete support of CPEs to IPv6 is also an important challenge and incentive to overcome Dual-Stack towards IPv4aaS solution [ANSI]. 5.1.6. Software Applications The transition to IPv6 requires that the application software is adapted for use in IPv6-based networks ([ARIN-SW] provides an example). The use of transition mechanisms like 464XLAT is essential to support IPv4-only applications while they evolve to IPv6. Depending on the transition mechanism employed some issues may remain. For example, in the case of NAT64/DNS64 the use of literal IPv4 addresses, instead of DNS names, will fail, unless mechanisms such as Application Level Gateways (ALG) are used. This issue is not present in 464XLAT (see [RFC8683]). It is worth mentioning Happy Eyeballs [RFC8305] as a relevant aspect of application transition to IPv6. 5.2. Network Management and Operations There are important IPv6 complementary solutions related to Operations, Administration and Maintenance (OAM) that look less mature compared to IPv4. Network Management System (NMS) has a central role in the modern networks for both network operators and enterprises and its transition is a fundamental issue. This is because some IPv6 products are not as field-proven as for IPv4 even if conventional protocols (e.g. SNMP, RADIUS) already support IPv6. In addition, incompatible vendor road map for the development of new NMS features affects the confidence of network operators or enterprises. An important factor is represented by the need for training the network operations workforce. Deploying IPv6 requires that policies and procedures have to be adjusted in order to successfully plan and complete an IPv6 transition. Staff has to be aware of the best practices for managing IPv4 and IPv6 assets. In addition to network nodes, network management applications and equipment need to be properly configured and in some cases also replaced. This may introduce more complexity and costs for the transition. Fioccola, et al. Expires 4 June 2023 [Page 25] Internet-Draft IPv6 Deployment Status December 2022 Availability of both systems and training is necessary in areas such as IPv6 addressing. IPv6 addresses can be assigned to an interface through different means, such as Stateless Auto-Configuration (SLAAC) [RFC4862], or by using stateful Dynamic Host Control Protocol (DHCP) [RFC8415]. IP Address Management (IPAM) systems may contribute to handle the technical differences and automate some of the configuration tasks, such as the address assignment or the management of DHCP services. 5.3. Performance People tend to compare the performance of IPv6 versus IPv4 to argue or motivate the IPv6 transition. In some cases, IPv6 behaving "worse" than IPv4 may be used as an argument for avoiding the full adoption of IPv6. However, there are some aspects where IPv6 has already filled (or is filling) the gap to IPv4. This position is supported when looking at available analytics on two critical parameters: packet loss and latency. These parameters have been constantly monitored over time, but only a few comprehensive measurement campaigns are providing up-to-date information. While performance is undoubtedly an important issue to consider and worth further investigation, reality is that a definitive answer cannot be found on what IP version performs better. Depending on the specific use case and application, IPv6 is better; in others the same applies to IPv4. 5.3.1. IPv6 packet loss and latency [APNIC5] provides a measurement of both the failure rate and Round Trip Time (RTT) of IPv6 compared against IPv4. Both measures are based on scripts that employs the three-way handshake of TCP. As such, the measurement of the failure rate does not provide a direct measurement of packet loss (that would need an Internet-wide measurement campaign). Said that, despite IPv4 is still performing better, the difference seems to have decreased in recent years. Two reports, namely [RIPE1] and [APRICOT], discussed the associated trend, showing how the average worldwide failure rate of IPv6 is still a bit worse than IPv4. Reasons for this effect may be found in endpoints with an unreachable IPv6 address, routing instability or firewall behavior. Yet, this worsening effect may appear as disturbing for a plain transition to IPv6. [APNIC5] also compares the latency of both address families. Currently, the worldwide average is slightly in favor of IPv6. Zooming at the country or even at the operator level, it is possible to get more detailed information and appreciate that cases exist where IPv6 is faster than IPv4. Regions (e.g. Western Europe, Northern America, Southern Asia) and Countries (e.g. US, India, Fioccola, et al. Expires 4 June 2023 [Page 26] Internet-Draft IPv6 Deployment Status December 2022 Germany) with an advanced deployment of IPv6 (e.g. >45%) are showing that IPv6 has better performance than IPv4. [APRICOT] highlights how when a difference in performance exists it is often related to asymmetric routing issues. Other possible explanations for a relative latency difference lies on the specificity of the IPv6 header which allows packet fragmentation. In turn, this means that hardware needs to spend cycles to analyze all of the header sections and when it is not capable of handling one of them it drops the packet. A few measurement campaigns on the behavior of IPv6 in CDNs are also available [MAPRG], [INFOCOM]. The TCP connect time is still higher for IPv6 in both cases, even if the gap has reduced over the analysis time window. 5.3.2. Customer Experience It is not totally clear if the Customer Experience is in some way perceived as better when IPv6 is used instead of IPv4. In some cases it has been publicly reported by IPv6 content providers, that users have a better experience when using IPv6-only compared to IPv4 [ISOC2]. This could be explained because in the case of an IPv6 user connecting to an application hosted in an IPv6-only Data Centers, the connection is end-to-end, without translations. Instead, when using IPv4 there is a NAT translation either in the CPE or in the service provider's network, in addition to IPv4 to IPv6 (and back to IPv4) translation in the IPv6-only content provider Data Center. [ISOC2], [FB] provide reasons in favor of IPv6. In other cases, the result seems to be still slightly in favor of IPv4 [INFOCOM], [MAPRG], even if the difference between IPv4 and IPv6 tends to vanish over time. 5.4. IPv6 security and privacy An important point that is sometimes considered as a challenge when discussing the transition to IPv6 is related to the security and privacy. [RFC9099] analyzes the operational security issues in several places of a network (enterprises, service providers and residential users). It is also worth considering the additional security issues brought by the applied IPv6 transition technologies used to implement IPv4aaS (e.g. 464XLAT, DS-Lite) [ComputSecur]. The security aspects have to be considered to keep at least the same or even a better level of security as it exists nowadays in an IPv4 network environment. The autoconfiguration features of IPv6 will require some more attention. Router discovery and address autoconfiguration may produce unexpected results and security holes. IPsec protects IPv6 traffic at least as well as it does IPv4, and the security protocols for constrained devices (IoT) are designed for IPv6 operation. Fioccola, et al. Expires 4 June 2023 [Page 27] Internet-Draft IPv6 Deployment Status December 2022 IPv6 was designed to restore the end-to-end model of communications with all nodes on networks using globally unique addresses. But, considering this, IPv6 may imply privacy concerns, due to greater visibility on the Internet. IPv6 nodes can (and typically do) use privacy extensions [RFC8981] to prevent any tracking of their burned- in MAC address(es), which are easily readable in the original modified EUI-64 interface identifier format. But, on the other hand, stable IPv6 interface identifiers ([RFC8064]) were developed and this can also affect privacy. As reported in [ISOC3], comparing IPv6 and IPv4 at the protocol level, one may probably conclude that the increased complexity of IPv6 results in an increased number of attack vectors, that imply more possible ways to perform different types of attacks. However, a more interesting and practical question is how IPv6 deployments compare to IPv4 deployments in terms of security. In that sense, there are a number of aspects to consider. Most security vulnerabilities related to network protocols are based on implementation flaws. Typically, security researchers find vulnerabilities in protocol implementations, which eventually are "patched" to mitigate such vulnerabilities. Over time, this process of finding and patching vulnerabilities results in more robust implementations. For obvious reasons, the IPv4 protocols have benefited from the work of security researchers for much longer, and thus, IPv4 implementations are generally more robust than IPv6. However, with more IPv6 deployment, IPv6 will also benefit from this process in the long run. It is also worth mentioning that most vulnerabilities are nowadays in the human being and in the application layer and not in the IP layer. Besides the intrinsic properties of the protocols, the security level of the resulting deployments is closely related to the level of expertise of network and security engineers. In that sense, there is obviously much more experience and confidence with deploying and operating IPv4 networks than with deploying and operating IPv6 networks. 5.4.1. Protocols security issues In general, there are security concerns related to IPv6 that can be classified as follows: * Basic IPv6 protocol (Basic header, Extension Headers, Addressing) * IPv6 associated protocols (ICMPv6, NDP, MLD, DNS, DHCPv6) Fioccola, et al. Expires 4 June 2023 [Page 28] Internet-Draft IPv6 Deployment Status December 2022 * Internet-wide IPv6 security (Filtering, DDoS, Transition Mechanisms) ICMPv6 is an integral part of IPv6 and performs error reporting and diagnostic functions. Neighbor Discovery Protocol (NDP) is a node discovery protocol in IPv6 which replaces and enhances functions of ARP. Multicast Listener Discovery (MLD) is used by IPv6 routers for discovering multicast listeners on a directly attached link, much like Internet Group Management Protocol (IGMP) is used in IPv4. These IPv6 associated protocols like ICMPv6, NDP and MLD are something new compared to IPv4, so they add new security threats and the related solutions are still under discussion today. NDP has vulnerabilities [RFC3756] [RFC6583]. The specification says to use IPsec but it is impractical and not used, on the other hand, SEND (SEcure Neighbour Discovery) [RFC3971] is not widely available. It is worth mentioning that applying host isolation may address many of these concerns, as described in [I-D.ietf-v6ops-nd-considerations]. [RIPE2] describes the most important threats and solutions regarding IPv6 security. 5.4.1.1. IPv6 Extension Headers and Fragmentation IPv6 Extension Headers provide a hook for interesting new features to be added, and are more flexible than IPv4 Options. This does add some complexity, and in particular some security mechanisms may require to process the full chain of headers, and some firewalls may require to filter packets based on their Extension Headers. Additionally, packets with IPv6 Extension Headers may be dropped in the public Internet [RFC7872]. Some documents, e.g. [I-D.ietf-6man-hbh-processing], [I-D.ietf-v6ops-hbh], [I-D.bonica-6man-ext-hdr-update], analyze and provide guidance regarding the processing procedures of IPv6 Extension Headers. Defense against possible attacks through Extension Headers is necessary. For example, the original IPv6 Routing Header type 0 (RH0) was deprecated because of possible remote traffic amplification [RFC5095]. In addition, it is worth mentioning that unrecognized Hop-by-Hop Options Header and Destination Options Header will not be considered by the nodes if they are not configured to deal with it [RFC8200]. Other attacks based on Extension Headers may be based on IPv6 Header Chains and Fragmentation that could be used to bypass filtering. To mitigate this effect, the initial IPv6 Header, the Extension Headers and the Upper-Layer Header must all be in the first fragment [RFC8200]. Also, the use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages [RFC6980]. Fioccola, et al. Expires 4 June 2023 [Page 29] Internet-Draft IPv6 Deployment Status December 2022 Fragment Header is used by IPv6 source node to send a packet bigger than path MTU and the Destination host processes fragment headers. There are several threats related to fragmentation to pay attention to e.g. overlapping fragments (not allowed) resource consumption while waiting for last fragment (to discard), atomic fragments (to be isolated). The operational implications of IPv6 Packets with Extension Headers are further discussed in [RFC9098]. 6. Security Considerations This document has no impact on the security properties of specific IPv6 protocols or transition tools. In addition to the discussion above in Section 5.4, the security considerations relating to the protocols and transition tools are described in the relevant documents. 7. Contributors Nalini Elkins Inside Products Email: nalini.elkins@insidethestack.com Sébastien Lourdez Post Luxembourg Email: sebastien.lourdez@post.lu 8. Acknowledgements The authors of this document would like to thank Brian Carpenter, Fred Baker, Alexandre Petrescu, Fernando Gont, Barbara Stark, Haisheng Yu(Johnson), Dhruv Dhody, Gabor Lencse, Shuping Peng, Daniel Voyer, Daniel Bernier, Hariharan Ananthakrishnan, Donavan Fritz, Igor Lubashev, Erik Nygren, Eduard Vasilenko and Xipeng Xiao for their comments and review of this document. 9. IANA Considerations This document has no actions for IANA. 10. References 10.1. Normative References Fioccola, et al. Expires 4 June 2023 [Page 30] Internet-Draft IPv6 Deployment Status December 2022 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, DOI 10.17487/RFC3756, May 2004, . [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, . [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, . [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, DOI 10.17487/RFC6036, October 2010, . [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, DOI 10.17487/RFC6180, May 2011, . [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, . [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, DOI 10.17487/RFC6540, April 2012, . [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, DOI 10.17487/RFC6583, March 2012, . Fioccola, et al. Expires 4 June 2023 [Page 31] Internet-Draft IPv6 Deployment Status December 2022 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, . [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Content Providers and Application Service Providers", RFC 6883, DOI 10.17487/RFC6883, March 2013, . [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, . [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual- Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, . [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, . [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, . [RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. Patel, "Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop", RFC 8950, DOI 10.17487/RFC8950, November 2020, . [RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, "Operational Security Considerations for IPv6 Networks", RFC 9099, DOI 10.17487/RFC9099, August 2021, . [RFC9313] Lencse, G., Palet Martinez, J., Howard, L., Patterson, R., and I. Farrer, "Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS)", RFC 9313, DOI 10.17487/RFC9313, October 2022, . Fioccola, et al. Expires 4 June 2023 [Page 32] Internet-Draft IPv6 Deployment Status December 2022 10.2. Informative References [Akm-stats] Akamai, "IPv6 Adoption Visualization", 2021, . [Alx] Alexa, "The top 500 sites on the web", 2021, . [Amzn] Amazon, "Announcing Internet Protocol Version 6 (IPv6) support for Amazon CloudFront, AWS WAF, and Amazon S3 Transfer Acceleration", . [ANSI] ANSI/CTA, "ANSI/CTA Standard Host and Router Profiles for IPv6", 2020, . [APNIC1] APNIC, "IPv6 Capable Rate by country (%)", 2022, . [APNIC2] APNIC2, "IP Addressing 2021", 2022, . [APNIC3] APNIC, "BGP in 2020 – The BGP Table", 2021, >. [APNIC4] APNIC, "BGP in 2021 – The BGP Table", 2022, >. [APNIC5] APNIC, "Average RTT Difference (ms) (V6 - V4) for World (XA)", 2022, . [APRICOT] Huston, G., "Average RTT Difference (ms) (V6 - V4) for World (XA)", 2020, . [ARCEP] ARCEP, "Arcep Décision n° 2019-1386, Decision on the terms and conditions for awarding licences to use frequencies in the 3.4–3.8GHz band", 2019, . Fioccola, et al. Expires 4 June 2023 [Page 33] Internet-Draft IPv6 Deployment Status December 2022 [ARIN-CG] ARIN, "Community Grant Program: IPv6 Security, Applications, and Training for Enterprises", 2020, . [ARIN-SW] ARIN, "Preparing Applications for IPv6", . [BGR_1] BIIGROUP, "China Commercial IPv6 and DNSSEC Deployment Monitor", 2022, . [BGR_2] BIIGROUP, "China Government IPv6 and DNSSEC Deployment Monitor", 2022, . [BGR_3] BIIGROUP, "China Education IPv6 and DNSSEC Deployment Monitor", 2022, . [BIPT] Belgian Institute for Postal services and Telecommunications, "IPv6 in Belgium", 2017, . [CAIDA] APNIC, "Client-Side IPv6 Measurement", 2020, . [CAIR] Cisco, "Cisco Annual Internet Report (2018–2023) White Paper", 2020, . [Cldflr] Cloudflare, "Understanding and configuring Cloudflare's IPv6 support", . [cmpwr] Compuware, "Impact on Enterprises of the IPv6-Only direction for the US Federal Government", 2020, . Fioccola, et al. Expires 4 June 2023 [Page 34] Internet-Draft IPv6 Deployment Status December 2022 [CN] China.org.cn, "China to speed up IPv6-based Internet development", 2017, . [CN-IPv6] National IPv6 Deployment and Monitoring Platform, "Active IPv6 Internet users", 2022, . [CNLABS_1] CNLABS, "Industry IPv6 and DNSSEC Statistics", 2022, . [CNLABS_2] CNLABS, "Industry IPv6 and DNSSEC Statistics", 2022, . [ComputSecur] Computers & Security (Elsevier), "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", DOI 10.1016/j.cose.2018.04.012, 2018, . [Csc6lab] Cisco, "World - Display Content Data", 2022, . [EE] EE, "IPv6-only devices on EE mobile", 2017, . [ETSI-GR-IPE-001] ETSI, "ETSI GR IPE 001: IPv6 Enhanced Innovation (IPE) Gap Analysis", 2021, . [ETSI-IP6-WhitePaper] ETSI, "ETSI White Paper No. 35: IPv6 Best Practices, Benefits, Transition Challenges and the Way Forward", ISBN 979-10-92620-31-1, 2020. [FB] Saab, P., "Facebook IPv6 Experience", 2015, . [GFA] German Federal Government Commissioner for Information Technology, "IPv6-Masterplan für die Bundesverwaltung", 2019, . Fioccola, et al. Expires 4 June 2023 [Page 35] Internet-Draft IPv6 Deployment Status December 2022 [Ggl] Google, "Introduction to GGC", . [G_stats] Google, "Google IPv6 Statistics", 2021, . [HxBld] HexaBuild, "IPv6 Adoption Report 2020", 2020, . [I-D.bonica-6man-ext-hdr-update] Bonica, R. and T. Jinmei, "Inserting, Processing And Deleting IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-bonica-6man-ext-hdr-update-07, 24 February 2022, . [I-D.ietf-6man-hbh-processing] Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options Processing Procedures", Work in Progress, Internet-Draft, draft-ietf-6man-hbh-processing-04, 21 October 2022, . [I-D.ietf-v6ops-hbh] Peng, S., Li, Z., Xie, C., Qin, Z., and G. S. Mishra, "Operational Issues with Processing of the Hop-by-Hop Options Header", Work in Progress, Internet-Draft, draft- ietf-v6ops-hbh-02, 21 October 2022, . [I-D.ietf-v6ops-nd-considerations] Xiao, X., Vasilenko, E., Metz, E., Mishra, G., and N. Buraglio, "Selectively Applying Host Isolation to Simplify IPv6 First-hop Deployment", Work in Progress, Internet- Draft, draft-ietf-v6ops-nd-considerations-00, 24 October 2022, . [I-D.palet-v6ops-ipv6-only] Martinez, J. P., "IPv6-only Terminology Definition", Work in Progress, Internet-Draft, draft-palet-v6ops-ipv6-only- 05, 9 March 2020, . Fioccola, et al. Expires 4 June 2023 [Page 36] Internet-Draft IPv6 Deployment Status December 2022 [IAB] IAB, "IAB Statement on IPv6", 2016, . [IDT] Indian Department of Telecommunications, "Revision of IPv6 Transition Timelines", 2021, . [IGP-GT] Internet Governance Project, Georgia Tech, "The hidden standards war: economic factors affecting IPv6 deployment", 2019, . [INFOCOM] Doan, T.V., "A Longitudinal View of Netflix: Content Delivery over IPv6 and Content Cache Deployments", 2020, . [IPv6Forum] IPv6Forum, "Estimating IPv6 & DNSSEC External Service Deployment Status", 2022, . [ISIF-ASIA-G] ISIF Asia, "Internet Operations Research Grant: IPv6 Deployment at Enterprises. IIESoc. India", 2020, . [ISOC1] Internet Society, "State of IPv6 Deployment 2018", 2018, . [ISOC2] Internet Society, "Facebook News Feeds Load 20-40% Faster Over IPv6", 2015, . [ISOC3] Internet Society, "IPv6 Security FAQ", 2019, . [MAPRG] Bajpai, V., "Measuring YouTube Content Delivery over IPv6", 2017, . Fioccola, et al. Expires 4 June 2023 [Page 37] Internet-Draft IPv6 Deployment Status December 2022 [Mcrsft] Microsoft, "IPv6 for Azure VMs available in most regions", . [NRO] NRO, "Internet Number Resource Status Report", 2021, . [NST_1] NIST, "Estimating Industry IPv6 and DNSSEC External Service Deployment Status", 2022, . [NST_2] NIST, "Estimating USG IPv6 and DNSSEC External Service Deployment Status", 2022, . [NST_3] NIST, "Estimating University IPv6 and DNSSEC External Service Deployment Status", 2022, . [Ntflx] Netflix, "Enabling Support for IPv6", . [POTAROO1] POTAROO, "IP Addressing through 2021", 2022, . [POTAROO2] POTAROO, "IPv6 Resource Allocations", 2022, . [RelJio] Reliance Jio, "IPv6-only adoption challenges and standardization requirements", 2020, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, . Fioccola, et al. Expires 4 June 2023 [Page 38] Internet-Draft IPv6 Deployment Status December 2022 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, DOI 10.17487/RFC6264, June 2011, . [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, DOI 10.17487/RFC6980, August 2013, . [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, . [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . [RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks", RFC 8683, DOI 10.17487/RFC8683, November 2019, . [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, . Fioccola, et al. Expires 4 June 2023 [Page 39] Internet-Draft IPv6 Deployment Status December 2022 [RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, G., and W. Liu, "Operational Implications of IPv6 Packets with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, September 2021, . [RIPE1] Huston, G., "Measuring IPv6 Performance", 2016, . [RIPE2] RIPE, "IPv6 Security", 2019, . [SNDVN] SANDVINE, "Sandvine releases 2020 Mobile Internet Phenomena Report: YouTube is over 25% of all mobile traffic", 2020, . [TMus] T-Mobile US, "Going IPv6-only", 2018, . [US-CIO] The CIO Council, "Memorandum for Heads of Executive Departments and Agencies. Completing the Transition to Internet Protocol Version 6 (IPv6)", 2020, . [US-FR] Federal Register, "Request for Comments on Updated Guidance for Completing the Transition to the Next Generation Internet Protocol, Internet Protocol Version 6 (IPv6)", 2020, . [Vrzn] Verizon, "Verizon Digital Media Services announces IPv6 Compliance", . [W3Techs] W3Techs, "Historical yearly trends in the usage statistics of site elements for websites", 2021, . Fioccola, et al. Expires 4 June 2023 [Page 40] Internet-Draft IPv6 Deployment Status December 2022 [WIPv6L] World IPv6 Launch, "World IPv6 Launch - Measurements", 2021, . Appendix A. Summary of Questionnaire and Replies for network operators A survey was proposed to more than 50 service providers in the European region during the third quarter of 2020 to ask for their plans on IPv6 and the status of IPv6 deployment. 40 people, representing 38 organizations, provided a response. This appendix summarizes the results obtained. Respondents' business Convergent Mobile Fixed Type of operators 82% 8% 11% Question 1. Do you have plan to move more fixed or mobile or enterprise users to IPv6 in the next 2 years? a. If so, fixed, or mobile, or enterprise? b. What are the reasons to do so? c. When to start: already on going, in 12 months, after 12 months? d. Which transition solution will you use, Dual-Stack, DS-Lite, 464XLAT, MAP-T/E? Answer 1.A (38 respondents) Yes No Plans availability 79% 21% Mobile Fixed Enterprise Don't answer Business segment 63% 63% 50% 3% Answer 1.B (29 respondents) Even this was an open question, some common answers can be found. 14 respondents (48%) highlighted issues related to IPv4 depletion. The reason to move to IPv6 is to avoid private and/or overlapping addresses. For 6 respondents (20%) 5G/IoT is a business incentive to introduce IPv6. Fioccola, et al. Expires 4 June 2023 [Page 41] Internet-Draft IPv6 Deployment Status December 2022 4 respondents (13%) also highlight that there is a National regulation request to enable IPv6 associated with the launch of 5G. 4 respondents (13%) consider IPv6 as a part of their innovation strategy or an enabler for new services. 4 respondents (13%) introduce IPv6 because of Enterprise customers demand. Answer 1.C (30 respondents) Ongoing In 12 months After 12 months Don't answer Timeframe 60% 33% 0% 7% Answer 1.D (28 respondents for cellular, 27 for wireline) Transition in use Dual-Stack 464XLAT MAP-T Don't answer Cellular 39% 21% 4% 36% Transition in use Dual-Stack DS-Lite 6RD/6VPE Don't answer Wireline 59% 19% 4% 19% Question 2. Do you need to change network devices for the above goal? a. If yes, what kind of devices: CPE, or BNG/mobile core, or NAT? b. Will you start the transition of your metro or backbone or backhaul network to support IPv6? Answer 2.A (30 respondents) Yes No Don't answer Need of changing 43% 33% 23% CPEs Routers BNG CGN Mobile core What to change 47% 27% 20% 33% 27% Answer 2.B (22 respondents) Yes Future No Plans for transition 9% 9% 82% Fioccola, et al. Expires 4 June 2023 [Page 42] Internet-Draft IPv6 Deployment Status December 2022 Appendix B. Summary of Questionnaire and Replies for enterprises The Industry Network Technology Council (INTC) developed the following poll to verify the need or willingness of medium-to-large US-based enterprises for training and consultancy on IPv6 (https://industrynetcouncil.org/) in early 2021. 54 organizations provided an answer. Question 1. How much IPv6 implementation have you done at your organization? (54 respondents) None 16.67% Some people have gotten some training 16.67% Many people have gotten some training 1.85% Website is IPv6 enabled 7.41% Most equipment is dual-stacked 31.48% Have an IPv6 transition plan for entire network 5.56% Running IPv6-only in many places 20.37% Entire network is IPv6-only 0.00% Question 2. What kind of help or classes would you like to see INTC do? ( 54 respondents) Classes/labs on IPv6 security 66.67% Classes/labs on IPv6 fundamentals 55.56% Classes/labs on address planning/network conf. 57.41% Classes/labs on IPv6 troubleshooting 66.67% Classes/labs on application conversion 35.19% Other 14.81% Question 3. As you begin to think about the implementation of IPv6 at your organization, what areas do you feel are of concern? (54 respondents) Security 31.48% Application conversion 25.93% Training 27.78% All the above 33.33% Don't know enough to answer 14.81% Other 9.26% Authors' Addresses Fioccola, et al. Expires 4 June 2023 [Page 43] Internet-Draft IPv6 Deployment Status December 2022 Giuseppe Fioccola Huawei Technologies Riesstrasse, 25 80992 Munich Germany Email: giuseppe.fioccola@huawei.com Paolo Volpato Huawei Technologies Via Lorenteggio, 240 20147 Milan Italy Email: paolo.volpato@huawei.com Jordi Palet Martinez The IPv6 Company Molino de la Navata, 75 28420 La Navata - Galapagar, Madrid Spain Email: jordi.palet@theipv6company.com Gyan S. Mishra Verizon Inc. Email: gyan.s.mishra@verizon.com Chongfeng Xie China Telecom Email: xiechf@chinatelecom.cn Fioccola, et al. Expires 4 June 2023 [Page 44] ./draft-irtf-cfrg-hash-to-curve-16.txt0000644000764400076440000137530614252351713017316 0ustar iustiniustin CFRG A. Faz-Hernandez Internet-Draft Cloudflare, Inc. Intended status: Informational S. Scott Expires: 17 December 2022 Cornell Tech N. Sullivan Cloudflare, Inc. R.S. Wahby Stanford University C.A. Wood Cloudflare, Inc. 15 June 2022 Hashing to Elliptic Curves draft-irtf-cfrg-hash-to-curve-16 Abstract This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=cfrg. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Faz-Hernandez, et al. Expires 17 December 2022 [Page 1] Internet-Draft hash-to-curve June 2022 This Internet-Draft will expire on 17 December 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Elliptic curves . . . . . . . . . . . . . . . . . . . . . 6 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. Mappings . . . . . . . . . . . . . . . . . . . . . . 8 2.2.2. Encodings . . . . . . . . . . . . . . . . . . . . . . 9 2.2.3. Random oracle encodings . . . . . . . . . . . . . . . 9 2.2.4. Serialization . . . . . . . . . . . . . . . . . . . . 10 2.2.5. Domain separation . . . . . . . . . . . . . . . . . . 10 3. Encoding byte strings to elliptic curves . . . . . . . . . . 11 3.1. Domain separation requirements . . . . . . . . . . . . . 13 4. Utility functions . . . . . . . . . . . . . . . . . . . . . . 14 4.1. The sgn0 function . . . . . . . . . . . . . . . . . . . . 16 5. Hashing to a finite field . . . . . . . . . . . . . . . . . . 17 5.1. Efficiency considerations in extension fields . . . . . . 18 5.2. hash_to_field implementation . . . . . . . . . . . . . . 19 5.3. expand_message . . . . . . . . . . . . . . . . . . . . . 20 5.3.1. expand_message_xmd . . . . . . . . . . . . . . . . . 20 5.3.2. expand_message_xof . . . . . . . . . . . . . . . . . 22 5.3.3. Using DSTs longer than 255 bytes . . . . . . . . . . 23 5.3.4. Defining other expand_message variants . . . . . . . 24 6. Deterministic mappings . . . . . . . . . . . . . . . . . . . 25 6.1. Choosing a mapping function . . . . . . . . . . . . . . . 25 6.2. Interface . . . . . . . . . . . . . . . . . . . . . . . . 25 6.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 26 6.4. Sign of the resulting point . . . . . . . . . . . . . . . 26 6.5. Exceptional cases . . . . . . . . . . . . . . . . . . . . 26 6.6. Mappings for Weierstrass curves . . . . . . . . . . . . . 27 6.6.1. Shallue-van de Woestijne method . . . . . . . . . . . 27 Faz-Hernandez, et al. Expires 17 December 2022 [Page 2] Internet-Draft hash-to-curve June 2022 6.6.2. Simplified Shallue-van de Woestijne-Ulas method . . . 28 6.6.3. Simplified SWU for AB == 0 . . . . . . . . . . . . . 29 6.7. Mappings for Montgomery curves . . . . . . . . . . . . . 31 6.7.1. Elligator 2 method . . . . . . . . . . . . . . . . . 31 6.8. Mappings for twisted Edwards curves . . . . . . . . . . . 32 6.8.1. Rational maps from Montgomery to twisted Edwards curves . . . . . . . . . . . . . . . . . . . . . . . 32 6.8.2. Elligator 2 method . . . . . . . . . . . . . . . . . 33 7. Clearing the cofactor . . . . . . . . . . . . . . . . . . . . 33 8. Suites for hashing . . . . . . . . . . . . . . . . . . . . . 34 8.1. Implementing a hash-to-curve suite . . . . . . . . . . . 37 8.2. Suites for NIST P-256 . . . . . . . . . . . . . . . . . . 37 8.3. Suites for NIST P-384 . . . . . . . . . . . . . . . . . . 38 8.4. Suites for NIST P-521 . . . . . . . . . . . . . . . . . . 39 8.5. Suites for curve25519 and edwards25519 . . . . . . . . . 40 8.6. Suites for curve448 and edwards448 . . . . . . . . . . . 41 8.7. Suites for secp256k1 . . . . . . . . . . . . . . . . . . 42 8.8. Suites for BLS12-381 . . . . . . . . . . . . . . . . . . 43 8.8.1. BLS12-381 G1 . . . . . . . . . . . . . . . . . . . . 43 8.8.2. BLS12-381 G2 . . . . . . . . . . . . . . . . . . . . 44 8.9. Defining a new hash-to-curve suite . . . . . . . . . . . 45 8.10. Suite ID naming conventions . . . . . . . . . . . . . . . 46 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 47 10. Security considerations . . . . . . . . . . . . . . . . . . . 48 10.1. Properties of encodings . . . . . . . . . . . . . . . . 48 10.2. Hashing passwords . . . . . . . . . . . . . . . . . . . 49 10.3. Constant-time requirements . . . . . . . . . . . . . . . 49 10.4. encode_to_curve: output distribution and indifferentiability . . . . . . . . . . . . . . . . . . 49 10.5. hash_to_field security . . . . . . . . . . . . . . . . . 50 10.6. expand_message_xmd security . . . . . . . . . . . . . . 51 10.7. Domain separation for expand_message variants . . . . . 51 10.8. Target security levels . . . . . . . . . . . . . . . . . 55 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 13.1. Normative References . . . . . . . . . . . . . . . . . . 55 13.2. Informative References . . . . . . . . . . . . . . . . . 56 Appendix A. Related work . . . . . . . . . . . . . . . . . . . . 65 Appendix B. Hashing to ristretto255 . . . . . . . . . . . . . . 67 Appendix C. Hashing to decaf448 . . . . . . . . . . . . . . . . 68 Appendix D. Rational maps . . . . . . . . . . . . . . . . . . . 69 D.1. Generic Montgomery to twisted Edwards map . . . . . . . . 70 D.2. Weierstrass to Montgomery map . . . . . . . . . . . . . . 72 Appendix E. Isogeny maps for suites . . . . . . . . . . . . . . 72 E.1. 3-isogeny map for secp256k1 . . . . . . . . . . . . . . . 73 E.2. 11-isogeny map for BLS12-381 G1 . . . . . . . . . . . . . 74 E.3. 3-isogeny map for BLS12-381 G2 . . . . . . . . . . . . . 78 Faz-Hernandez, et al. Expires 17 December 2022 [Page 3] Internet-Draft hash-to-curve June 2022 Appendix F. Straight-line implementations of deterministic mappings . . . . . . . . . . . . . . . . . . . . . . . . 80 F.1. Shallue-van de Woestijne method . . . . . . . . . . . . . 80 F.2. Simplified SWU method . . . . . . . . . . . . . . . . . . 81 F.2.1. sqrt_ratio subroutines . . . . . . . . . . . . . . . 82 F.3. Elligator 2 method . . . . . . . . . . . . . . . . . . . 86 Appendix G. Curve-specific optimized sample code . . . . . . . . 87 G.1. Interface and projective coordinate systems . . . . . . . 87 G.2. Elligator 2 . . . . . . . . . . . . . . . . . . . . . . . 88 G.2.1. curve25519 (q = 5 (mod 8), K = 1) . . . . . . . . . . 88 G.2.2. edwards25519 . . . . . . . . . . . . . . . . . . . . 89 G.2.3. curve448 (q = 3 (mod 4), K = 1) . . . . . . . . . . . 90 G.2.4. edwards448 . . . . . . . . . . . . . . . . . . . . . 91 G.2.5. Montgomery curves with q = 3 (mod 4) . . . . . . . . 93 G.2.6. Montgomery curves with q = 5 (mod 8) . . . . . . . . 95 G.3. Cofactor clearing for BLS12-381 G2 . . . . . . . . . . . 96 Appendix H. Scripts for parameter generation . . . . . . . . . . 98 H.1. Finding Z for the Shallue-van de Woestijne map . . . . . 98 H.2. Finding Z for Simplified SWU . . . . . . . . . . . . . . 99 H.3. Finding Z for Elligator 2 . . . . . . . . . . . . . . . . 100 Appendix I. sqrt and is_square functions . . . . . . . . . . . . 100 I.1. sqrt for q = 3 (mod 4) . . . . . . . . . . . . . . . . . 101 I.2. sqrt for q = 5 (mod 8) . . . . . . . . . . . . . . . . . 101 I.3. sqrt for q = 9 (mod 16) . . . . . . . . . . . . . . . . . 101 I.4. Constant-time Tonelli-Shanks algorithm . . . . . . . . . 102 I.5. is_square for F = GF(p^2) . . . . . . . . . . . . . . . . 103 Appendix J. Suite test vectors . . . . . . . . . . . . . . . . . 104 J.1. NIST P-256 . . . . . . . . . . . . . . . . . . . . . . . 104 J.1.1. P256_XMD:SHA-256_SSWU_RO_ . . . . . . . . . . . . . . 104 J.1.2. P256_XMD:SHA-256_SSWU_NU_ . . . . . . . . . . . . . . 106 J.2. NIST P-384 . . . . . . . . . . . . . . . . . . . . . . . 108 J.2.1. P384_XMD:SHA-384_SSWU_RO_ . . . . . . . . . . . . . . 108 J.2.2. P384_XMD:SHA-384_SSWU_NU_ . . . . . . . . . . . . . . 110 J.3. NIST P-521 . . . . . . . . . . . . . . . . . . . . . . . 112 J.3.1. P521_XMD:SHA-512_SSWU_RO_ . . . . . . . . . . . . . . 112 J.3.2. P521_XMD:SHA-512_SSWU_NU_ . . . . . . . . . . . . . . 115 J.4. curve25519 . . . . . . . . . . . . . . . . . . . . . . . 117 J.4.1. curve25519_XMD:SHA-512_ELL2_RO_ . . . . . . . . . . . 117 J.4.2. curve25519_XMD:SHA-512_ELL2_NU_ . . . . . . . . . . . 119 J.5. edwards25519 . . . . . . . . . . . . . . . . . . . . . . 121 J.5.1. edwards25519_XMD:SHA-512_ELL2_RO_ . . . . . . . . . . 121 J.5.2. edwards25519_XMD:SHA-512_ELL2_NU_ . . . . . . . . . . 123 J.6. curve448 . . . . . . . . . . . . . . . . . . . . . . . . 125 J.6.1. curve448_XOF:SHAKE256_ELL2_RO_ . . . . . . . . . . . 125 J.6.2. curve448_XOF:SHAKE256_ELL2_NU_ . . . . . . . . . . . 128 J.7. edwards448 . . . . . . . . . . . . . . . . . . . . . . . 130 J.7.1. edwards448_XOF:SHAKE256_ELL2_RO_ . . . . . . . . . . 130 J.7.2. edwards448_XOF:SHAKE256_ELL2_NU_ . . . . . . . . . . 133 Faz-Hernandez, et al. Expires 17 December 2022 [Page 4] Internet-Draft hash-to-curve June 2022 J.8. secp256k1 . . . . . . . . . . . . . . . . . . . . . . . . 135 J.8.1. secp256k1_XMD:SHA-256_SSWU_RO_ . . . . . . . . . . . 135 J.8.2. secp256k1_XMD:SHA-256_SSWU_NU_ . . . . . . . . . . . 137 J.9. BLS12-381 G1 . . . . . . . . . . . . . . . . . . . . . . 139 J.9.1. BLS12381G1_XMD:SHA-256_SSWU_RO_ . . . . . . . . . . . 139 J.9.2. BLS12381G1_XMD:SHA-256_SSWU_NU_ . . . . . . . . . . . 141 J.10. BLS12-381 G2 . . . . . . . . . . . . . . . . . . . . . . 143 J.10.1. BLS12381G2_XMD:SHA-256_SSWU_RO_ . . . . . . . . . . 143 J.10.2. BLS12381G2_XMD:SHA-256_SSWU_NU_ . . . . . . . . . . 147 Appendix K. Expand test vectors . . . . . . . . . . . . . . . . 149 K.1. expand_message_xmd(SHA-256) . . . . . . . . . . . . . . . 150 K.2. expand_message_xmd(SHA-256) (long DST) . . . . . . . . . 154 K.3. expand_message_xmd(SHA-512) . . . . . . . . . . . . . . . 158 K.4. expand_message_xof(SHAKE128) . . . . . . . . . . . . . . 163 K.5. expand_message_xof(SHAKE128) (long DST) . . . . . . . . . 167 K.6. expand_message_xof(SHAKE256) . . . . . . . . . . . . . . 171 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 175 1. Introduction Many cryptographic protocols require a procedure that encodes an arbitrary input, e.g., a password, to a point on an elliptic curve. This procedure is known as hashing to an elliptic curve, where the hashing procedure provides collision resistance and does not reveal the discrete logarithm of the output point. Prominent examples of cryptosystems that hash to elliptic curves include password- authenticated key exchanges [BM92] [J96] [BMP00] [p1363.2], Identity- Based Encryption [BF01], Boneh-Lynn-Shacham signatures [BLS01] [I-D.irtf-cfrg-bls-signature], Verifiable Random Functions [MRV99] [I-D.irtf-cfrg-vrf], and Oblivious Pseudorandom Functions [NR97] [I-D.irtf-cfrg-voprf]. Unfortunately for implementors, the precise hash function that is suitable for a given protocol implemented using a given elliptic curve is often unclear from the protocol's description. Meanwhile, an incorrect choice of hash function can have disastrous consequences for security. This document aims to bridge this gap by providing a comprehensive set of recommended algorithms for a range of curve types. Each algorithm conforms to a common interface: it takes as input an arbitrary-length byte string and produces as output a point on an elliptic curve. We provide implementation details for each algorithm, describe the security rationale behind each recommendation, and give guidance for elliptic curves that are not explicitly covered. We also present optimized implementations for internal functions used by these algorithms. Faz-Hernandez, et al. Expires 17 December 2022 [Page 5] Internet-Draft hash-to-curve June 2022 Readers wishing to quickly specify or implement a conforming hash function should consult Section 8, which lists recommended hash-to- curve suites and describes both how to implement an existing suite and how to specify a new one. This document does not cover rejection sampling methods, sometimes referred to as "try-and-increment" or "hunt-and-peck," because the goal is to describe algorithms that can plausibly be computed in constant time. Use of these rejection methods is NOT RECOMMENDED, because they have been a perennial cause of side-channel vulnerabilities. See Dragonblood [VR20] as one example of this problem in practice, and see Appendix A for a further description of rejection sampling methods. This document represents the consensus of the Crypto Forum Research Group (CFRG). 1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Background 2.1. Elliptic curves The following is a brief definition of elliptic curves, with an emphasis on important parameters and their relation to hashing to curves. For further reference on elliptic curves, consult [CFADLNV05] or [W08]. Let F be the finite field GF(q) of prime characteristic p > 3. (This document does not consider elliptic curves over fields of characteristic 2 or 3.) In most cases F is a prime field, so q = p. Otherwise, F is an extension field, so q = p^m for an integer m > 1. This document writes elements of extension fields in a primitive element or polynomial basis, i.e., as a vector of m elements of GF(p) written in ascending order by degree. The entries of this vector are indexed in ascending order starting from 1, i.e., x = (x_1, x_2, ..., x_m). For example, if q = p^2 and the primitive element basis is (1, I), then x = (a, b) corresponds to the element a + b * I, where x_1 = a and x_2 = b. (Note that all choices of basis are isomorphic, but certain choices may result in a more efficient implementation; this document does not make any particular assumptions about choice of basis.) Faz-Hernandez, et al. Expires 17 December 2022 [Page 6] Internet-Draft hash-to-curve June 2022 An elliptic curve E is specified by an equation in two variables and a finite field F. An elliptic curve equation takes one of several standard forms, including (but not limited to) Weierstrass, Montgomery, and Edwards. The curve E induces an algebraic group of order n, meaning that the group has n distinct elements. (This document uses additive notation for the elliptic curve group operation.) Elements of an elliptic curve group are points with affine coordinates (x, y) satisfying the curve equation, where x and y are elements of F. In addition, all elliptic curve groups have a distinguished element, the identity point, which acts as the identity element for the group operation. On certain curves (including Weierstrass and Montgomery curves), the identity point cannot be represented as an (x, y) coordinate pair. For security reasons, cryptographic uses of elliptic curves generally require using a (sub)group of prime order. Let G be such a subgroup of the curve of prime order r, where n = h * r. In this equation, h is an integer called the cofactor. An algorithm that takes as input an arbitrary point on the curve E and produces as output a point in the subgroup G of E is said to "clear the cofactor." Such algorithms are discussed in Section 7. Certain hash-to-curve algorithms restrict the form of the curve equation, the characteristic of the field, or the parameters of the curve. For each algorithm presented, this document lists the relevant restrictions. The table below summarizes quantities relevant to hashing to curves: Faz-Hernandez, et al. Expires 17 December 2022 [Page 7] Internet-Draft hash-to-curve June 2022 +========+=====================+=======================+ | Symbol | Meaning | Relevance | +========+=====================+=======================+ | F,q,p | A finite field F of | For prime fields, q = | | | characteristic p | p; otherwise, q = p^m | | | and #F = q = p^m. | and m>1. | +--------+---------------------+-----------------------+ | E | Elliptic curve. | E is specified by an | | | | equation and a field | | | | F. | +--------+---------------------+-----------------------+ | n | Number of points on | n = h * r, for h and | | | the elliptic curve | r defined below. | | | E. | | +--------+---------------------+-----------------------+ | G | A prime-order | Destination group to | | | subgroup of the | which byte strings | | | points on E. | are encoded. | +--------+---------------------+-----------------------+ | r | Order of G. | r is a prime factor | | | | of n (usually, the | | | | largest such factor). | +--------+---------------------+-----------------------+ | h | Cofactor, h >= 1. | An integer satisfying | | | | n = h * r. | +--------+---------------------+-----------------------+ Table 1: Summary of symbols and their definitions. 2.2. Terminology In this section, we define important terms used throughout the document. 2.2.1. Mappings A mapping is a deterministic function from an element of the field F to a point on an elliptic curve E defined over F. In general, the set of all points that a mapping can produce over all possible inputs may be only a subset of the points on an elliptic curve (i.e., the mapping may not be surjective). In addition, a mapping may output the same point for two or more distinct inputs (i.e., the mapping may not be injective). For example, consider a mapping from F to an elliptic curve having n points: if the number of elements of F is not equal to n, then this mapping cannot be bijective (i.e., both injective and surjective) since the mapping is defined to be deterministic. Faz-Hernandez, et al. Expires 17 December 2022 [Page 8] Internet-Draft hash-to-curve June 2022 Mappings may also be invertible, meaning that there is an efficient algorithm that, for any point P output by the mapping, outputs an x in F such that applying the mapping to x outputs P. Some of the mappings given in Section 6 are invertible, but this document does not discuss inversion algorithms. 2.2.2. Encodings Encodings are closely related to mappings. Like a mapping, an encoding is a function that outputs a point on an elliptic curve. In contrast to a mapping, however, the input to an encoding is an arbitrary-length byte string. This document constructs deterministic encodings by composing a hash function Hf with a deterministic mapping. In particular, Hf takes as input an arbitrary string and outputs an element of F. The deterministic mapping takes that element as input and outputs a point on an elliptic curve E defined over F. Since Hf takes arbitrary- length byte strings as inputs, it cannot be injective: the set of inputs is larger than the set of outputs, so there must be distinct inputs that give the same output (i.e., there must be collisions). Thus, any encoding built from Hf is also not injective. Like mappings, encodings may be invertible, meaning that there is an efficient algorithm that, for any point P output by the encoding, outputs a string s such that applying the encoding to s outputs P. The instantiation of Hf used by all encodings specified in this document (Section 5) is not invertible. Thus, the encodings are also not invertible. In some applications of hashing to elliptic curves, it is important that encodings do not leak information through side channels. [VR20] is one example of this type of leakage leading to a security vulnerability. See Section 10.3 for further discussion. 2.2.3. Random oracle encodings A random-oracle encoding satisfies a strong property: it can be proved indifferentiable from a random oracle [MRH04] under a suitable assumption. Both constructions described in Section 3 are indifferentiable from random oracles [MRH04] when instantiated following the guidelines in this document. The constructions differ in their output distributions: one gives a uniformly random point on the curve, the other gives a point sampled from a nonuniform distribution. Faz-Hernandez, et al. Expires 17 December 2022 [Page 9] Internet-Draft hash-to-curve June 2022 A random-oracle encoding with a uniform output distribution is suitable for use in many cryptographic protocols proven secure in the random oracle model. See Section 10.1 for further discussion. 2.2.4. Serialization A procedure related to encoding is the conversion of an elliptic curve point to a bit string. This is called serialization, and is typically used for compactly storing or transmitting points. The inverse operation, deserialization, converts a bit string to an elliptic curve point. For example, [SEC1] and [p1363a] give standard methods for serialization and deserialization. Deserialization is different from encoding in that only certain strings (namely, those output by the serialization procedure) can be deserialized. In contrast, this document is concerned with encodings from arbitrary strings to elliptic curve points. This document does not cover serialization or deserialization. 2.2.5. Domain separation Cryptographic protocols proven secure in the random oracle model are often analyzed under the assumption that the random oracle only answers queries associated with that protocol (including queries made by adversaries) [BR93]. In practice, this assumption does not hold if two protocols use the same function to instantiate the random oracle. Concretely, consider protocols P1 and P2 that query a random oracle RO: if P1 and P2 both query RO on the same value x, the security analysis of one or both protocols may be invalidated. A common way of addressing this issue is called domain separation, which allows a single random oracle to simulate multiple, independent oracles. This is effected by ensuring that each simulated oracle sees queries that are distinct from those seen by all other simulated oracles. For example, to simulate two oracles RO1 and RO2 given a single oracle RO, one might define RO1(x) := RO("RO1" || x) RO2(x) := RO("RO2" || x) where || is the concatenation operator. In this example, "RO1" and "RO2" are called domain separation tags; they ensure that queries to RO1 and RO2 cannot result in identical queries to RO, meaning that it is safe to treat RO1 and RO2 as independent oracles. In general, domain separation requires defining a distinct injective encoding for each oracle being simulated. In the above example, "RO1" and "RO2" have the same length and thus satisfy this Faz-Hernandez, et al. Expires 17 December 2022 [Page 10] Internet-Draft hash-to-curve June 2022 requirement when used as prefixes. The algorithms specified in this document take a different approach to ensuring injectivity; see Section 5.3 and Section 10.7 for more details. 3. Encoding byte strings to elliptic curves This section presents a general framework and interface for encoding byte strings to points on an elliptic curve. The constructions in this section rely on three basic functions: * The function hash_to_field hashes arbitrary-length byte strings to a list of one or more elements of a finite field F; its implementation is defined in Section 5. hash_to_field(msg, count) Inputs: - msg, a byte string containing the message to hash. - count, the number of elements of F to output. Outputs: - (u_0, ..., u_(count - 1)), a list of field elements. Steps: defined in Section 5. * The function map_to_curve calculates a point on the elliptic curve E from an element of the finite field F over which E is defined. Section 6 describes mappings for a range of curve families. map_to_curve(u) Input: u, an element of field F. Output: Q, a point on the elliptic curve E. Steps: defined in Section 6. * The function clear_cofactor sends any point on the curve E to the subgroup G of E. Section 7 describes methods to perform this operation. clear_cofactor(Q) Input: Q, a point on the elliptic curve E. Output: P, a point in G. Steps: defined in Section 7. Faz-Hernandez, et al. Expires 17 December 2022 [Page 11] Internet-Draft hash-to-curve June 2022 The two encodings (Section 2.2.2) defined in this section have the same interface and are both random-oracle encodings (Section 2.2.3). Both are implemented as a composition of the three basic functions above. The difference between the two is that their outputs are sampled from different distributions: * encode_to_curve is a nonuniform encoding from byte strings to points in G. That is, the distribution of its output is not uniformly random in G: the set of possible outputs of encode_to_curve is only a fraction of the points in G, and some points in this set are more likely to be output than others. Section 10.4 gives a more precise definition of encode_to_curve's output distribution. encode_to_curve(msg) Input: msg, an arbitrary-length byte string. Output: P, a point in G. Steps: 1. u = hash_to_field(msg, 1) 2. Q = map_to_curve(u[0]) 3. P = clear_cofactor(Q) 4. return P * hash_to_curve is a uniform encoding from byte strings to points in G. That is, the distribution of its output is statistically close to uniform in G. This function is suitable for most applications requiring a random oracle returning points in G, when instantiated with any of the map_to_curve functions described in Section 6. See Section 10.1 for further discussion. hash_to_curve(msg) Input: msg, an arbitrary-length byte string. Output: P, a point in G. Steps: 1. u = hash_to_field(msg, 2) 2. Q0 = map_to_curve(u[0]) 3. Q1 = map_to_curve(u[1]) 4. R = Q0 + Q1 # Point addition 5. P = clear_cofactor(R) 6. return P Faz-Hernandez, et al. Expires 17 December 2022 [Page 12] Internet-Draft hash-to-curve June 2022 Each hash-to-curve suite in Section 8 instantiates one of these encoding functions for a specifc elliptic curve. 3.1. Domain separation requirements All uses of the encoding functions defined in this document MUST include domain separation (Section 2.2.5) to avoid interfering with other uses of similar functionality. Applications that instantiate multiple, independent instances of either hash_to_curve or encode_to_curve MUST enforce domain separation between those instances. This requirement applies both in the case of multiple instances targeting the same curve and in the case of multiple instances targeting different curves. (This is because the internal hash_to_field primitive (Section 5) requires domain separation to guarantee independent outputs.) Domain separation is enforced with a domain separation tag (DST), which is a byte string constructed according to the following requirements: 1. Tags MUST be supplied as the DST parameter to hash_to_field, as described in Section 5. 2. Tags MUST have nonzero length. A minimum length of 16 bytes is RECOMMENDED to reduce the chance of collisions with other applications. 3. Tags SHOULD begin with a fixed identification string that is unique to the application. 4. Tags SHOULD include a version number. 5. For applications that define multiple ciphersuites, each ciphersuite's tag MUST be different. For this purpose, it is RECOMMENDED to include a ciphersuite identifier in each tag. 6. For applications that use multiple encodings, either to the same curve or to different curves, each encoding MUST use a different tag. For this purpose, it is RECOMMENDED to include the encoding's Suite ID (Section 8) in the domain separation tag. For independent encodings based on the same suite, each tag SHOULD also include a distinct identifier, e.g., "ENC1" and "ENC2". As an example, consider a fictional application named Quux that defines several different ciphersuites, each for a different curve. A reasonable choice of tag is "QUUX-V-CS-", where Faz-Hernandez, et al. Expires 17 December 2022 [Page 13] Internet-Draft hash-to-curve June 2022 and are two-digit numbers indicating the version and ciphersuite, respectively, and is the Suite ID of the encoding used in ciphersuite . As another example, consider a fictional application named Baz that requires two independent random oracles to the same curve. Reasonable choices of tags for these oracles are "BAZ-V-CS- -ENC1" and "BAZ-V-CS--ENC2", respectively, where , , and are as described above. The example tags given above are assumed to be ASCII-encoded byte strings without null termination, which is the RECOMMENDED format. Other encodings can be used, but in all cases the encoding as a sequence of bytes MUST be specified unambiguously. 4. Utility functions Algorithms in this document use the utility functions described below, plus standard arithmetic operations (addition, multiplication, modular reduction, etc.) and elliptic curve point operations (point addition and scalar multiplication). For security, implementations of these functions SHOULD be constant time: in brief, this means that execution time and memory access patterns SHOULD NOT depend on the values of secret inputs, intermediate values, or outputs. For such constant-time implementations, all arithmetic, comparisons, and assignments MUST also be implemented in constant time. Section 10.3 briefly discusses constant-time security issues. Guidance on implementing low-level operations (in constant time or otherwise) is beyond the scope of this document; readers should consult standard reference material [MOV96] [CFADLNV05]. * CMOV(a, b, c): If c is False, CMOV returns a, otherwise it returns b. For constant-time implementations, this operation must run in time independent of the value of c. * AND, OR, NOT, and XOR are standard bitwise logical operators. For constant-time implementations, short-circuit operators MUST be avoided. * is_square(x): This function returns True whenever the value x is a square in the field F. By Euler's criterion, this function can be calculated in constant time as is_square(x) := { True, if x^((q - 1) / 2) is 0 or 1 in F; { False, otherwise. Faz-Hernandez, et al. Expires 17 December 2022 [Page 14] Internet-Draft hash-to-curve June 2022 In certain extension fields, is_square can be computed in constant time more quickly than by the above exponentiation. [AR13] and [S85] describe optimized methods for extension fields. Appendix I.5 gives an optimized straight-line method for GF(p^2). * sqrt(x): The sqrt operation is a multi-valued function, i.e., there exist two roots of x in the field F whenever x is square (except when x = 0). To maintain compatibility across implementations while allowing implementors leeway for optimizations, this document does not require sqrt() to return a particular value. Instead, as explained in Section 6.4, any function that calls sqrt also specifies how to determine the correct root. The preferred way of computing square roots is to fix a deterministic algorithm particular to F. We give several algorithms in Appendix I. * sgn0(x): This function returns either 0 or 1 indicating the "sign" of x, where sgn0(x) == 1 just when x is "negative". (In other words, this function always considers 0 to be positive.) Section 4.1 defines this function and discusses its implementation. * inv0(x): This function returns the multiplicative inverse of x in F, extended to all of F by fixing inv0(0) == 0. A straightforward way to implement inv0 in constant time is to compute inv0(x) := x^(q - 2). Notice that on input 0, the output is 0 as required. Certain fields may allow faster inversion methods; detailed discussion of such methods is beyond the scope of this document. * I2OSP and OS2IP: These functions are used to convert a byte string to and from a non-negative integer as described in [RFC8017]. (Note that these functions operate on byte strings in big-endian byte order.) * a || b: denotes the concatenation of byte strings a and b. For example, "ABC" || "DEF" == "ABCDEF". * substr(str, sbegin, slen): for a byte string str, this function returns the slen-byte substring starting at position sbegin; positions are zero indexed. For example, substr("ABCDEFG", 2, 3) == "CDE". Faz-Hernandez, et al. Expires 17 December 2022 [Page 15] Internet-Draft hash-to-curve June 2022 * len(str): for a byte string str, this function returns the length of str in bytes. For example, len("ABC") == 3. * strxor(str1, str2): for byte strings str1 and str2, strxor(str1, str2) returns the bitwise XOR of the two strings. For example, strxor("abc", "XYZ") == "9;9" (the strings in this example are ASCII literals, but strxor is defined for arbitrary byte strings). In this document, strxor is only applied to inputs of equal length. 4.1. The sgn0 function This section defines a generic sgn0 implementation that applies to any field F = GF(p^m). It also gives simplified implementations for the cases F = GF(p) and F = GF(p^2). The definition of the sgn0 function for extension fields relies on the polynomial basis or vector representation of field elements, and iterates over the entire vector representation of the input element. As a result, sgn0 depends on the primitive polynomial used to define the polynomial basis; see Section 8 for more information about this basis, and see Section 2.1 for a discussion of representing elements of extension fields as vectors. sgn0(x) Parameters: - F, a finite field of characteristic p and order q = p^m. - p, the characteristic of F (see immediately above). - m, the extension degree of F, m >= 1 (see immediately above). Input: x, an element of F. Output: 0 or 1. Steps: 1. sign = 0 2. zero = 1 3. for i in (1, 2, ..., m): 4. sign_i = x_i mod 2 5. zero_i = x_i == 0 6. sign = sign OR (zero AND sign_i) # Avoid short-circuit logic ops 7. zero = zero AND zero_i 8. return sign When m == 1, sgn0 can be significantly simplified: Faz-Hernandez, et al. Expires 17 December 2022 [Page 16] Internet-Draft hash-to-curve June 2022 sgn0_m_eq_1(x) Input: x, an element of GF(p). Output: 0 or 1. Steps: 1. return x mod 2 The case m == 2 is only slightly more complicated: sgn0_m_eq_2(x) Input: x, an element of GF(p^2). Output: 0 or 1. Steps: 1. sign_0 = x_0 mod 2 2. zero_0 = x_0 == 0 3. sign_1 = x_1 mod 2 4. s = sign_0 OR (zero_0 AND sign_1) # Avoid short-circuit logic ops 5. return s 5. Hashing to a finite field The hash_to_field function hashes a byte string msg of arbitrary length into one or more elements of a field F. This function works in two steps: it first hashes the input byte string to produce a uniformly random byte string, and then interprets this byte string as one or more elements of F. For the first step, hash_to_field calls an auxiliary function expand_message. This document defines two variants of expand_message: one appropriate for hash functions like SHA-2 [FIPS180-4] or SHA-3 [FIPS202], and another appropriate for extendable-output functions such as SHAKE128 [FIPS202]. Security considerations for each expand_message variant are discussed below (Section 5.3.1, Section 5.3.2). Implementors MUST NOT use rejection sampling to generate a uniformly random element of F, to ensure that the hash_to_field function is amenable to constant-time implementation. The reason is that rejection sampling procedures are difficult to implement in constant time, and later well-meaning "optimizations" may silently render an implementation non-constant-time. This means that any hash_to_field function based on rejection sampling would be incompatible with constant-time implementation. Faz-Hernandez, et al. Expires 17 December 2022 [Page 17] Internet-Draft hash-to-curve June 2022 The hash_to_field function is also suitable for securely hashing to scalars. For example, when hashing to the scalar field for an elliptic curve (sub)group with prime order r, it suffices to instantiate hash_to_field with target field GF(r). The hash_to_field function is designed to be indifferentiable from a random oracle [MRH04] when expand_message (Section 5.3) is modeled as a random oracle (see Section 10.5 for details about its indifferentiability). Ensuring indifferentiability requires care; to see why, consider a prime p that is close to 3/4 * 2^256. Reducing a random 256-bit integer modulo this p yields a value that is in the range [0, p / 3] with probability roughly 1/2, meaning that this value is statistically far from uniform in [0, p - 1]. To control bias, hash_to_field instead uses random integers whose length is at least ceil(log2(p)) + k bits, where k is the target security level for the suite in bits. Reducing such integers mod p gives bias at most 2^-k for any p; this bias is appropriate when targeting k-bit security. For each such integer, hash_to_field uses expand_message to obtain L uniform bytes, where L = ceil((ceil(log2(p)) + k) / 8) These uniform bytes are then interpreted as an integer via OS2IP. For example, for a 255-bit prime p, and k = 128-bit security, L = ceil((255 + 128) / 8) = 48 bytes. Note that k is an upper bound on the security level for the corresponding curve. See Section 10.8 for more details, and Section 8.9 for guidelines on choosing k for a given curve. 5.1. Efficiency considerations in extension fields The hash_to_field function described in this section is inefficient for certain extension fields. Specifically, when hashing to an element of the extension field GF(p^m), hash_to_field requires expanding msg into m * L bytes (for L as defined above). For extension fields where log2(p) is significantly smaller than the security level k, this approach is inefficient: it requires expand_message to output roughly m * log2(p) + m * k bits, whereas m * log2(p) + k bytes suffices to generate an element of GF(p^m) with bias at most 2^-k. In such cases, applications MAY use an alternative hash_to_field function, provided it meets the following security requirements: * The function MUST output field element(s) that are uniformly random except with bias at most 2^-k. Faz-Hernandez, et al. Expires 17 December 2022 [Page 18] Internet-Draft hash-to-curve June 2022 * The function MUST NOT use rejection sampling. * The function SHOULD be amenable to straight line implementations. For example, Pornin [P20] describes a method for hashing to GF(9767^19) that meets these requirements while using fewer output bits from expand_message than hash_to_field would for that field. 5.2. hash_to_field implementation The following procedure implements hash_to_field. The expand_message parameter to this function MUST conform to the requirements given in Section 5.3. Section 3.1 discusses the REQUIRED method for constructing DST, the domain separation tag. Note that hash_to_field may fail (abort) if expand_message fails. hash_to_field(msg, count) Parameters: - DST, a domain separation tag (see Section 3.1). - F, a finite field of characteristic p and order q = p^m. - p, the characteristic of F (see immediately above). - m, the extension degree of F, m >= 1 (see immediately above). - L = ceil((ceil(log2(p)) + k) / 8), where k is the security parameter of the suite (e.g., k = 128). - expand_message, a function that expands a byte string and domain separation tag into a uniformly random byte string (see Section 5.3). Inputs: - msg, a byte string containing the message to hash. - count, the number of elements of F to output. Outputs: - (u_0, ..., u_(count - 1)), a list of field elements. Steps: 1. len_in_bytes = count * m * L 2. uniform_bytes = expand_message(msg, DST, len_in_bytes) 3. for i in (0, ..., count - 1): 4. for j in (0, ..., m - 1): 5. elm_offset = L * (j + i * m) 6. tv = substr(uniform_bytes, elm_offset, L) 7. e_j = OS2IP(tv) mod p 8. u_i = (e_0, ..., e_(m - 1)) 9. return (u_0, ..., u_(count - 1)) Faz-Hernandez, et al. Expires 17 December 2022 [Page 19] Internet-Draft hash-to-curve June 2022 5.3. expand_message expand_message is a function that generates a uniformly random byte string. It takes three arguments: 1. msg, a byte string containing the message to hash, 2. DST, a byte string that acts as a domain separation tag, and 3. len_in_bytes, the number of bytes to be generated. This document defines the following two variants of expand_message: * expand_message_xmd (Section 5.3.1) is appropriate for use with a wide range of hash functions, including SHA-2 [FIPS180-4], SHA-3 [FIPS202], BLAKE2 [RFC7693], and others. * expand_message_xof (Section 5.3.2) is appropriate for use with extendable-output functions (XOFs) including functions in the SHAKE [FIPS202] or BLAKE2X [BLAKE2X] families. These variants should suffice for the vast majority of use cases, but other variants are possible; Section 5.3.4 discusses requirements. 5.3.1. expand_message_xmd The expand_message_xmd function produces a uniformly random byte string using a cryptographic hash function H that outputs b bits. For security, H MUST meet the following requirements: * The number of bits output by H MUST be b >= 2 * k, for k the target security level in bits, and b MUST be divisible by 8. The first requirement ensures k-bit collision resistance; the second ensures uniformity of expand_message_xmd's output. * H MAY be a Merkle-Damgaard hash function like SHA-2. In this case, security holds when the underlying compression function is modeled as a random oracle [CDMP05]. (See Section 10.6 for discussion.) * H MAY be a sponge-based hash function like SHA-3 or BLAKE2. In this case, security holds when the inner function is modeled as a random transformation or as a random permutation [BDPV08]. * Otherwise, H MUST be a hash function that has been proved indifferentiable from a random oracle [MRH04] under a reasonable cryptographic assumption. Faz-Hernandez, et al. Expires 17 December 2022 [Page 20] Internet-Draft hash-to-curve June 2022 SHA-2 [FIPS180-4] and SHA-3 [FIPS202] are typical and RECOMMENDED choices. As an example, for the 128-bit security level, b >= 256 bits and either SHA-256 or SHA3-256 would be an appropriate choice. The hash function H is assumed to work by repeatedly ingesting fixed- length blocks of data. The length in bits of these blocks is called the input block size (s). As examples, s = 1024 for SHA-512 [FIPS180-4] and s = 576 for SHA3-512 [FIPS202]. For correctness, H requires b <= s. The following procedure implements expand_message_xmd. expand_message_xmd(msg, DST, len_in_bytes) Parameters: - H, a hash function (see requirements above). - b_in_bytes, b / 8 for b the output size of H in bits. For example, for b = 256, b_in_bytes = 32. - s_in_bytes, the input block size of H, measured in bytes (see discussion above). For example, for SHA-256, s_in_bytes = 64. Input: - msg, a byte string. - DST, a byte string of at most 255 bytes. See below for information on using longer DSTs. - len_in_bytes, the length of the requested output in bytes, not greater than the lesser of (255 * b_in_bytes) or 2^16-1. Output: - uniform_bytes, a byte string. Steps: 1. ell = ceil(len_in_bytes / b_in_bytes) 2. ABORT if ell > 255 or len_in_bytes > 65535 or len(DST) > 255 3. DST_prime = DST || I2OSP(len(DST), 1) 4. Z_pad = I2OSP(0, s_in_bytes) 5. l_i_b_str = I2OSP(len_in_bytes, 2) 6. msg_prime = Z_pad || msg || l_i_b_str || I2OSP(0, 1) || DST_prime 7. b_0 = H(msg_prime) 8. b_1 = H(b_0 || I2OSP(1, 1) || DST_prime) 9. for i in (2, ..., ell): 10. b_i = H(strxor(b_0, b_(i - 1)) || I2OSP(i, 1) || DST_prime) 11. uniform_bytes = b_1 || ... || b_ell 12. return substr(uniform_bytes, 0, len_in_bytes) Note that the string Z_pad (step 6) is prefixed to msg before computing b_0 (step 7). This is necessary for security when H is a Merkle-Damgaard hash, e.g., SHA-2 (see Section 10.6). Hashing this Faz-Hernandez, et al. Expires 17 December 2022 [Page 21] Internet-Draft hash-to-curve June 2022 additional data means that the cost of computing b_0 is higher than the cost of simply computing H(msg). In most settings this overhead is negligible, because the cost of evaluating H is much less than the other costs involved in hashing to a curve. It is possible, however, to entirely avoid this overhead by taking advantage of the fact that Z_pad depends only on H, and not on the arguments to expand_message_xmd. To do so, first precompute and save the internal state of H after ingesting Z_pad. Then, when computing b_0, initialize H using the saved state. Further details are implementation dependent, and beyond the scope of this document. 5.3.2. expand_message_xof The expand_message_xof function produces a uniformly random byte string using an extendable-output function (XOF) H. For security, H MUST meet the following criteria: * The collision resistance of H MUST be at least k bits. * H MUST be an XOF that has been proved indifferentiable from a random oracle under a reasonable cryptographic assumption. The SHAKE [FIPS202] XOF family is a typical and RECOMMENDED choice. As an example, for 128-bit security, SHAKE128 would be an appropriate choice. The following procedure implements expand_message_xof. Faz-Hernandez, et al. Expires 17 December 2022 [Page 22] Internet-Draft hash-to-curve June 2022 expand_message_xof(msg, DST, len_in_bytes) Parameters: - H(m, d), an extendable-output function that processes input message m and returns d bytes. Input: - msg, a byte string. - DST, a byte string of at most 255 bytes. See below for information on using longer DSTs. - len_in_bytes, the length of the requested output in bytes. Output: - uniform_bytes, a byte string. Steps: 1. ABORT if len_in_bytes > 65535 or len(DST) > 255 2. DST_prime = DST || I2OSP(len(DST), 1) 3. msg_prime = msg || I2OSP(len_in_bytes, 2) || DST_prime 4. uniform_bytes = H(msg_prime, len_in_bytes) 5. return uniform_bytes 5.3.3. Using DSTs longer than 255 bytes The expand_message variants defined in this section accept domain separation tags of at most 255 bytes. If applications require a domain separation tag longer than 255 bytes, e.g., because of requirements imposed by an invoking protocol, implementors MUST compute a short domain separation tag by hashing, as follows: * For expand_message_xmd using hash function H, DST is computed as DST = H("H2C-OVERSIZE-DST-" || a_very_long_DST) * For expand_message_xof using extendable-output function H, DST is computed as DST = H("H2C-OVERSIZE-DST-" || a_very_long_DST, ceil(2 * k / 8)) Here, a_very_long_DST is the DST whose length is greater than 255 bytes, "H2C-OVERSIZE-DST-" is a 17-byte ASCII string literal, and k is the target security level in bits. Faz-Hernandez, et al. Expires 17 December 2022 [Page 23] Internet-Draft hash-to-curve June 2022 5.3.4. Defining other expand_message variants When defining a new expand_message variant, the most important consideration is that hash_to_field models expand_message as a random oracle. Thus, implementors SHOULD prove indifferentiability from a random oracle under an appropriate assumption about the underlying cryptographic primitives; see Section 10.5 for more information. In addition, expand_message variants: * MUST give collision resistance commensurate with the security level of the target elliptic curve. * MUST be built on primitives designed for use in applications requiring cryptographic randomness. As examples, a secure stream cipher is an appropriate primitive, whereas a Mersenne twister pseudorandom number generator [MT98] is not. * MUST NOT use rejection sampling. * MUST give independent values for distinct (msg, DST, length) inputs. Meeting this requirement is subtle. As a simplified example, hashing msg || DST does not work, because in this case distinct (msg, DST) pairs whose concatenations are equal will return the same output (e.g., ("AB", "CDEF") and ("ABC", "DEF")). The variants defined in this document use a suffix-free encoding of DST to avoid this issue. * MUST use the domain separation tag DST to ensure that invocations of cryptographic primitives inside of expand_message are domain separated from invocations outside of expand_message. For example, if the expand_message variant uses a hash function H, an encoding of DST MUST be added either as a prefix or a suffix of the input to each invocation of H. Adding DST as a suffix is the RECOMMENDED approach. * SHOULD read msg exactly once, for efficiency when msg is long. In addition, each expand_message variant MUST specify a unique EXP_TAG that identifies that variant in a Suite ID. See Section 8.10 for more information. Faz-Hernandez, et al. Expires 17 December 2022 [Page 24] Internet-Draft hash-to-curve June 2022 6. Deterministic mappings The mappings in this section are suitable for implementing either nonuniform or uniform encodings using the constructions in Section 3. Certain mappings restrict the form of the curve or its parameters. For each mapping presented, this document lists the relevant restrictions. Note that mappings in this section are not interchangeable: different mappings will almost certainly output different points when evaluated on the same input. 6.1. Choosing a mapping function This section gives brief guidelines on choosing a mapping function for a given elliptic curve. Note that the suites given in Section 8 are recommended mappings for the respective curves. If the target elliptic curve is a Montgomery curve (Section 6.7), the Elligator 2 method (Section 6.7.1) is recommended. Similarly, if the target elliptic curve is a twisted Edwards curve (Section 6.8), the twisted Edwards Elligator 2 method (Section 6.8.2) is recommended. The remaining cases are Weierstrass curves. For curves supported by the Simplified SWU method (Section 6.6.2), that mapping is the recommended one. Otherwise, the Simplified SWU method for AB == 0 (Section 6.6.3) is recommended if the goal is best performance, while the Shallue-van de Woestijne method (Section 6.6.1) is recommended if the goal is simplicity of implementation. (The reason for this distinction is that the Simplified SWU method for AB == 0 requires implementing an isogeny map in addition to the mapping function, while the Shallue-van de Woestijne method does not.) The Shallue-van de Woestijne method (Section 6.6.1) works with any curve, and may be used in cases where a generic mapping is required. Note, however, that this mapping is almost always more computationally expensive than the curve-specific recommendations above. 6.2. Interface The generic interface shared by all mappings in this section is as follows: (x, y) = map_to_curve(u) Faz-Hernandez, et al. Expires 17 December 2022 [Page 25] Internet-Draft hash-to-curve June 2022 The input u and outputs x and y are elements of the field F. The affine coordinates (x, y) specify a point on an elliptic curve defined over F. Note, however, that the point (x, y) is not a uniformly random point. 6.3. Notation As a rough guide, the following conventions are used in pseudocode: * All arithmetic operations are performed over a field F, unless explicitly stated otherwise. * u: the input to the mapping function. This is an element of F produced by the hash_to_field function. * (x, y), (s, t), (v, w): the affine coordinates of the point output by the mapping. Indexed variables (e.g., x1, y2, ...) are used for candidate values. * tv1, tv2, ...: reusable temporary variables. * c1, c2, ...: constant values, which can be computed in advance. 6.4. Sign of the resulting point In general, elliptic curves have equations of the form y^2 = g(x). The mappings in this section first identify an x such that g(x) is square, then take a square root to find y. Since there are two square roots when g(x) != 0, this may result in an ambiguity regarding the sign of y. When necessary, the mappings in this section resolve this ambiguity by specifying the sign of the y-coordinate in terms of the input to the mapping function. Two main reasons support this approach: first, this covers elliptic curves over any field in a uniform way, and second, it gives implementors leeway in optimizing square-root implementations. 6.5. Exceptional cases Mappings may have exceptional cases, i.e., inputs u on which the mapping is undefined. These cases must be handled carefully, especially for constant-time implementations. Faz-Hernandez, et al. Expires 17 December 2022 [Page 26] Internet-Draft hash-to-curve June 2022 For each mapping in this section, we discuss the exceptional cases and show how to handle them in constant time. Note that all implementations SHOULD use inv0 (Section 4) to compute multiplicative inverses, to avoid exceptional cases that result from attempting to compute the inverse of 0. 6.6. Mappings for Weierstrass curves The mappings in this section apply to a target curve E defined by the equation y^2 = g(x) = x^3 + A * x + B where 4 * A^3 + 27 * B^2 != 0. 6.6.1. Shallue-van de Woestijne method Shallue and van de Woestijne [SW06] describe a mapping that applies to essentially any elliptic curve. (Note, however, that this mapping is more expensive to evaluate than the other mappings in this document.) The parameterization given below is for Weierstrass curves; its derivation is detailed in [W19]. This parameterization also works for Montgomery (Section 6.7) and twisted Edwards (Section 6.8) curves via the rational maps given in Appendix D: first evaluate the Shallue-van de Woestijne mapping to an equivalent Weierstrass curve, then map that point to the target Montgomery or twisted Edwards curve using the corresponding rational map. Preconditions: A Weierstrass curve y^2 = x^3 + A * x + B. Constants: * A and B, the parameter of the Weierstrass curve. * Z, a non-zero element of F meeting the below criteria. Appendix H.1 gives a Sage [SAGE] script that outputs the RECOMMENDED Z. 1. g(Z) != 0 in F. 2. -(3 * Z^2 + 4 * A) / (4 * g(Z)) != 0 in F. 3. -(3 * Z^2 + 4 * A) / (4 * g(Z)) is square in F. 4. At least one of g(Z) and g(-Z / 2) is square in F. Faz-Hernandez, et al. Expires 17 December 2022 [Page 27] Internet-Draft hash-to-curve June 2022 Sign of y: Inputs u and -u give the same x-coordinate for many values of u. Thus, we set sgn0(y) == sgn0(u). Exceptions: The exceptional cases for u occur when (1 + u^2 * g(Z)) * (1 - u^2 * g(Z)) == 0. The restrictions on Z given above ensure that implementations that use inv0 to invert this product are exception free. Operations: 1. tv1 = u^2 * g(Z) 2. tv2 = 1 + tv1 3. tv1 = 1 - tv1 4. tv3 = inv0(tv1 * tv2) 5. tv4 = sqrt(-g(Z) * (3 * Z^2 + 4 * A)) # can be precomputed 6. If sgn0(tv4) == 1, set tv4 = -tv4 # sgn0(tv4) MUST equal 0 7. tv5 = u * tv1 * tv3 * tv4 8. tv6 = -4 * g(Z) / (3 * Z^2 + 4 * A) # can be precomputed 9. x1 = -Z / 2 - tv5 10. x2 = -Z / 2 + tv5 11. x3 = Z + tv6 * (tv2^2 * tv3)^2 12. If is_square(g(x1)), set x = x1 and y = sqrt(g(x1)) 13. Else If is_square(g(x2)), set x = x2 and y = sqrt(g(x2)) 14. Else set x = x3 and y = sqrt(g(x3)) 15. If sgn0(u) != sgn0(y), set y = -y 16. return (x, y) Appendix F.1 gives an example straight-line implementation of this mapping. 6.6.2. Simplified Shallue-van de Woestijne-Ulas method The function map_to_curve_simple_swu(u) implements a simplification of the Shallue-van de Woestijne-Ulas mapping [U07] described by Brier et al. [BCIMRT10], which they call the "simplified SWU" map. Wahby and Boneh [WB19] generalize and optimize this mapping. Preconditions: A Weierstrass curve y^2 = x^3 + A * x + B where A != 0 and B != 0. Constants: * A and B, the parameters of the Weierstrass curve. * Z, an element of F meeting the below criteria. Appendix H.2 gives a Sage [SAGE] script that outputs the RECOMMENDED Z. The criteria are: Faz-Hernandez, et al. Expires 17 December 2022 [Page 28] Internet-Draft hash-to-curve June 2022 1. Z is non-square in F, 2. Z != -1 in F, 3. the polynomial g(x) - Z is irreducible over F, and 4. g(B / (Z * A)) is square in F. Sign of y: Inputs u and -u give the same x-coordinate. Thus, we set sgn0(y) == sgn0(u). Exceptions: The exceptional cases are values of u such that Z^2 * u^4 + Z * u^2 == 0. This includes u == 0, and may include other values depending on Z. Implementations must detect this case and set x1 = B / (Z * A), which guarantees that g(x1) is square by the condition on Z given above. Operations: 1. tv1 = inv0(Z^2 * u^4 + Z * u^2) 2. x1 = (-B / A) * (1 + tv1) 3. If tv1 == 0, set x1 = B / (Z * A) 4. gx1 = x1^3 + A * x1 + B 5. x2 = Z * u^2 * x1 6. gx2 = x2^3 + A * x2 + B 7. If is_square(gx1), set x = x1 and y = sqrt(gx1) 8. Else set x = x2 and y = sqrt(gx2) 9. If sgn0(u) != sgn0(y), set y = -y 10. return (x, y) Appendix F.2 gives a general and optimized straight-line implementation of this mapping. For more information on optimizing this mapping, see [WB19] Section 4 or the example code found at [hash2curve-repo]. 6.6.3. Simplified SWU for AB == 0 Wahby and Boneh [WB19] show how to adapt the simplified SWU mapping to Weierstrass curves having A == 0 or B == 0, which the mapping of Section 6.6.2 does not support. (The case A == B == 0 is excluded because y^2 = x^3 is not an elliptic curve.) This method applies to curves like secp256k1 [SEC2] and to pairing- friendly curves in the Barreto-Lynn-Scott [BLS03], Barreto-Naehrig [BN05], and other families. This method requires finding another elliptic curve E' given by the equation Faz-Hernandez, et al. Expires 17 December 2022 [Page 29] Internet-Draft hash-to-curve June 2022 y'^2 = g'(x') = x'^3 + A' * x' + B' that is isogenous to E and has A' != 0 and B' != 0. (See [WB19], Appendix A, for one way of finding E' using [SAGE].) This isogeny defines a map iso_map(x', y') given by a pair of rational functions. iso_map takes as input a point on E' and produces as output a point on E. Once E' and iso_map are identified, this mapping works as follows: on input u, first apply the simplified SWU mapping to get a point on E', then apply the isogeny map to that point to get a point on E. Note that iso_map is a group homomorphism, meaning that point addition commutes with iso_map. Thus, when using this mapping in the hash_to_curve construction of Section 3, one can effect a small optimization by first mapping u0 and u1 to E', adding the resulting points on E', and then applying iso_map to the sum. This gives the same result while requiring only one evaluation of iso_map. Preconditions: An elliptic curve E' with A' != 0 and B' != 0 that is isogenous to the target curve E with isogeny map iso_map from E' to E. Helper functions: * map_to_curve_simple_swu is the mapping of Section 6.6.2 to E' * iso_map is the isogeny map from E' to E Sign of y: for this map, the sign is determined by map_to_curve_simple_swu. No further sign adjustments are necessary. Exceptions: map_to_curve_simple_swu handles its exceptional cases. Exceptional cases of iso_map are inputs that cause the denominator of either rational function to evaluate to zero; such cases MUST return the identity point on E. Operations: 1. (x', y') = map_to_curve_simple_swu(u) # (x', y') is on E' 2. (x, y) = iso_map(x', y') # (x, y) is on E 3. return (x, y) See [hash2curve-repo] or [WB19] Section 4.3 for details on implementing the isogeny map. Faz-Hernandez, et al. Expires 17 December 2022 [Page 30] Internet-Draft hash-to-curve June 2022 6.7. Mappings for Montgomery curves The mapping defined in this section applies to a target curve M defined by the equation K * t^2 = s^3 + J * s^2 + s 6.7.1. Elligator 2 method Bernstein, Hamburg, Krasnova, and Lange give a mapping that applies to any curve with a point of order 2 [BHKL13], which they call Elligator 2. Preconditions: A Montgomery curve K * t^2 = s^3 + J * s^2 + s where J != 0, K != 0, and (J^2 - 4) / K^2 is non-zero and non-square in F. Constants: * J and K, the parameters of the elliptic curve. * Z, a non-square element of F. Appendix H.3 gives a Sage [SAGE] script that outputs the RECOMMENDED Z. Sign of t: this mapping fixes the sign of t as specified in [BHKL13]. No additional adjustment is required. Exceptions: The exceptional case is Z * u^2 == -1, i.e., 1 + Z * u^2 == 0. Implementations must detect this case and set x1 = -(J / K). Note that this can only happen when q = 3 (mod 4). Operations: 1. x1 = -(J / K) * inv0(1 + Z * u^2) 2. If x1 == 0, set x1 = -(J / K) 3. gx1 = x1^3 + (J / K) * x1^2 + x1 / K^2 4. x2 = -x1 - (J / K) 5. gx2 = x2^3 + (J / K) * x2^2 + x2 / K^2 6. If is_square(gx1), set x = x1, y = sqrt(gx1) with sgn0(y) == 1. 7. Else set x = x2, y = sqrt(gx2) with sgn0(y) == 0. 8. s = x * K 9. t = y * K 10. return (s, t) Appendix F.3 gives an example straight-line implementation of this mapping. Appendix G.2 gives optimized straight-line procedures that apply to specific classes of curves and base fields. Faz-Hernandez, et al. Expires 17 December 2022 [Page 31] Internet-Draft hash-to-curve June 2022 6.8. Mappings for twisted Edwards curves Twisted Edwards curves (a class of curves that includes Edwards curves) are given by the equation a * v^2 + w^2 = 1 + d * v^2 * w^2 with a != 0, d != 0, and a != d [BBJLP08]. These curves are closely related to Montgomery curves (Section 6.7): every twisted Edwards curve is birationally equivalent to a Montgomery curve ([BBJLP08], Theorem 3.2). This equivalence yields an efficient way of hashing to a twisted Edwards curve: first, hash to an equivalent Montgomery curve, then transform the result into a point on the twisted Edwards curve via a rational map. This method of hashing to a twisted Edwards curve thus requires identifying a corresponding Montgomery curve and rational map. We describe how to identify such a curve and map immediately below. 6.8.1. Rational maps from Montgomery to twisted Edwards curves There are two ways to select a Montgomery curve and rational map for use when hashing to a given twisted Edwards curve. The selected Montgomery curve and rational map MUST be specified as part of the hash-to-curve suite for a given twisted Edwards curve; see Section 8. 1. When hashing to a standardized twisted Edwards curve for which a corresponding Montgomery form and rational map are also standardized, the standard Montgomery form and rational map SHOULD be used to ensure compatibility with existing software. In certain cases, e.g., edwards25519 [RFC7748], the sign of the rational map from the twisted Edwards curve to its corresponding Montgomery curve is not given explicitly. In this case, the sign MUST be fixed such that applying the rational map to the twisted Edwards curve's base point yields the Montgomery curve's base point with correct sign. (For edwards25519, see [RFC7748] and [EID4730].) When defining new twisted Edwards curves, a Montgomery equivalent and rational map SHOULD also be specified, and the sign of the rational map SHOULD be stated explicitly. 2. When hashing to a twisted Edwards curve that does not have a standardized Montgomery form or rational map, the map given in Appendix D SHOULD be used. Faz-Hernandez, et al. Expires 17 December 2022 [Page 32] Internet-Draft hash-to-curve June 2022 6.8.2. Elligator 2 method Preconditions: A twisted Edwards curve E and an equivalent Montgomery curve M meeting the requirements in Section 6.8.1. Helper functions: * map_to_curve_elligator2 is the mapping of Section 6.7.1 to the curve M. * rational_map is a function that takes a point (s, t) on M and returns a point (v, w) on E, as defined in Section 6.8.1. Sign of t (and v): for this map, the sign is determined by map_to_curve_elligator2. No further sign adjustments are required. Exceptions: The exceptions for the Elligator 2 mapping are as given in Section 6.7.1. The exceptions for the rational map are as given in Section 6.8.1. No other exceptions are possible. The following procedure implements the Elligator 2 mapping for a twisted Edwards curve. (Note that the output point is denoted (v, w) because it is a point on the target twisted Edwards curve.) map_to_curve_elligator2_edwards(u) Input: u, an element of F. Output: (v, w), a point on E. 1. (s, t) = map_to_curve_elligator2(u) # (s, t) is on M 2. (v, w) = rational_map(s, t) # (v, w) is on E 3. return (v, w) 7. Clearing the cofactor The mappings of Section 6 always output a point on the elliptic curve, i.e., a point in a group of order h * r (Section 2.1). Obtaining a point in G may require a final operation commonly called "clearing the cofactor," which takes as input any point on the curve and produces as output a point in the prime-order (sub)group G (Section 2.1). The cofactor can always be cleared via scalar multiplication by h. For elliptic curves where h = 1, i.e., the curves with a prime number of points, no operation is required. This applies, for example, to the NIST curves P-256, P-384, and P-521 [FIPS186-4]. Faz-Hernandez, et al. Expires 17 December 2022 [Page 33] Internet-Draft hash-to-curve June 2022 In some cases, it is possible to clear the cofactor via a faster method than scalar multiplication by h. These methods are equivalent to (but usually faster than) multiplication by some scalar h_eff whose value is determined by the method and the curve. Examples of fast cofactor clearing methods include the following: * For certain pairing-friendly curves having subgroup G2 over an extension field, Scott et al. [SBCDK09] describe a method for fast cofactor clearing that exploits an efficiently-computable endomorphism. Fuentes-Castaneda et al. [FKR11] propose an alternative method that is sometimes more efficient. Budroni and Pintore [BP17] give concrete instantiations of these methods for Barreto-Lynn-Scott pairing-friendly curves [BLS03]. This method is described for the specific case of BLS12-381 in Appendix G.3. * Wahby and Boneh ([WB19], Section 5) describe a trick due to Scott for fast cofactor clearing on any elliptic curve for which the prime factorization of h and the structure of the elliptic curve group meet certain conditions. The clear_cofactor function is parameterized by a scalar h_eff. Specifically, clear_cofactor(P) := h_eff * P where * represents scalar multiplication. When a curve does not support a fast cofactor clearing method, h_eff = h and the cofactor MUST be cleared via scalar multiplication. When a curve admits a fast cofactor clearing method, clear_cofactor MAY be evaluated either via that method or via scalar multiplication by the equivalent h_eff; these two methods give the same result. Note that in this case scalar multiplication by the cofactor h does not generally give the same result as the fast method, and MUST NOT be used. 8. Suites for hashing This section lists recommended suites for hashing to standard elliptic curves. A hash-to-curve suite fully specifies the procedure for hashing byte strings to points on a specific elliptic curve group. Section 8.1 describes how to implement a suite. Applications that require hashing to an elliptic curve should use either an existing suite or a new suite specified as described in Section 8.9. Faz-Hernandez, et al. Expires 17 December 2022 [Page 34] Internet-Draft hash-to-curve June 2022 All applications using a hash-to-curve suite MUST choose a domain separation tag (DST) in accordance with the guidelines in Section 3.1. In addition, applications whose security requires a random oracle that returns uniformly random points on the target curve MUST use a suite whose encoding type is hash_to_curve; see Section 3 and immediately below for more information. A hash-to-curve suite comprises the following parameters: * Suite ID, a short name used to refer to a given suite. Section 8.10 discusses the naming conventions for suite IDs. * encoding type, either uniform (hash_to_curve) or nonuniform (encode_to_curve). See Section 3 for definitions of these encoding types. * E, the target elliptic curve over a field F. * p, the characteristic of the field F. * m, the extension degree of the field F. If m > 1, the suite MUST also specify the polynomial basis used to represent extension field elements. * k, the target security level of the suite in bits. (See Section 10.8 for discussion.) * L, the length parameter for hash_to_field (Section 5). * expand_message, one of the variants specified in Section 5.3 plus any parameters required for the specified variant (for example, H, the underlying hash function). * f, a mapping function from Section 6. * h_eff, the scalar parameter for clear_cofactor (Section 7). In addition to the above parameters, the mapping f may require additional parameters Z, M, rational_map, E', or iso_map. When applicable, these MUST be specified. Faz-Hernandez, et al. Expires 17 December 2022 [Page 35] Internet-Draft hash-to-curve June 2022 The below table lists suites RECOMMENDED for some elliptic curves. The corresponding parameters are given in the following subsections. Applications instantiating cryptographic protocols whose security analysis relies on a random oracle that outputs points with a uniform distribution MUST NOT use a nonuniform encoding. Moreover, applications that use a nonuniform encoding SHOULD carefully analyze the security implications of nonuniformity. When the required encoding is not clear, applications SHOULD use a uniform encoding for security. +==============+===================================+=========+ | E | Suites | Section | +==============+===================================+=========+ | NIST P-256 | P256_XMD:SHA-256_SSWU_RO_ | Section | | | P256_XMD:SHA-256_SSWU_NU_ | 8.2 | +--------------+-----------------------------------+---------+ | NIST P-384 | P384_XMD:SHA-384_SSWU_RO_ | Section | | | P384_XMD:SHA-384_SSWU_NU_ | 8.3 | +--------------+-----------------------------------+---------+ | NIST P-521 | P521_XMD:SHA-512_SSWU_RO_ | Section | | | P521_XMD:SHA-512_SSWU_NU_ | 8.4 | +--------------+-----------------------------------+---------+ | curve25519 | curve25519_XMD:SHA-512_ELL2_RO_ | Section | | | curve25519_XMD:SHA-512_ELL2_NU_ | 8.5 | +--------------+-----------------------------------+---------+ | edwards25519 | edwards25519_XMD:SHA-512_ELL2_RO_ | Section | | | edwards25519_XMD:SHA-512_ELL2_NU_ | 8.5 | +--------------+-----------------------------------+---------+ | curve448 | curve448_XOF:SHAKE256_ELL2_RO_ | Section | | | curve448_XOF:SHAKE256_ELL2_NU_ | 8.6 | +--------------+-----------------------------------+---------+ | edwards448 | edwards448_XOF:SHAKE256_ELL2_RO_ | Section | | | edwards448_XOF:SHAKE256_ELL2_NU_ | 8.6 | +--------------+-----------------------------------+---------+ | secp256k1 | secp256k1_XMD:SHA-256_SSWU_RO_ | Section | | | secp256k1_XMD:SHA-256_SSWU_NU_ | 8.7 | +--------------+-----------------------------------+---------+ | BLS12-381 G1 | BLS12381G1_XMD:SHA-256_SSWU_RO_ | Section | | | BLS12381G1_XMD:SHA-256_SSWU_NU_ | 8.8 | +--------------+-----------------------------------+---------+ | BLS12-381 G2 | BLS12381G2_XMD:SHA-256_SSWU_RO_ | Section | | | BLS12381G2_XMD:SHA-256_SSWU_NU_ | 8.8 | +--------------+-----------------------------------+---------+ Table 2: Suites for hashing to elliptic curves. Faz-Hernandez, et al. Expires 17 December 2022 [Page 36] Internet-Draft hash-to-curve June 2022 8.1. Implementing a hash-to-curve suite A hash-to-curve suite requires the following functions. Note that some of these require utility functions from Section 4. 1. Base field arithmetic operations for the target elliptic curve, e.g., addition, multiplication, and square root. 2. Elliptic curve point operations for the target curve, e.g., point addition and scalar multiplication. 3. The hash_to_field function; see Section 5. This includes the expand_message variant (Section 5.3) and any constituent hash function or XOF. 4. The suite-specified mapping function; see the corresponding subsection of Section 6. 5. A cofactor clearing function; see Section 7. This may be implemented as scalar multiplication by h_eff or as a faster equivalent method. 6. The desired encoding function; see Section 3. This is either hash_to_curve or encode_to_curve. 8.2. Suites for NIST P-256 This section defines ciphersuites for the NIST P-256 elliptic curve [FIPS186-4]. P256_XMD:SHA-256_SSWU_RO_ is defined as follows: * encoding type: hash_to_curve (Section 3) * E: y^2 = x^3 + A * x + B, where - A = -3 - B = 0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e2 7d2604b * p: 2^256 - 2^224 + 2^192 + 2^96 - 1 * m: 1 * k: 128 * expand_message: expand_message_xmd (Section 5.3.1) Faz-Hernandez, et al. Expires 17 December 2022 [Page 37] Internet-Draft hash-to-curve June 2022 * H: SHA-256 * L: 48 * f: Simplified SWU method (Section 6.6.2) * Z: -10 * h_eff: 1 P256_XMD:SHA-256_SSWU_NU_ is identical to P256_XMD:SHA-256_SSWU_RO_, except that the encoding type is encode_to_curve (Section 3). An optimized example implementation of the Simplified SWU mapping to P-256 is given in Appendix F.2. 8.3. Suites for NIST P-384 This section defines ciphersuites for the NIST P-384 elliptic curve [FIPS186-4]. P384_XMD:SHA-384_SSWU_RO_ is defined as follows: * encoding type: hash_to_curve (Section 3) * E: y^2 = x^3 + A * x + B, where - A = -3 - B = 0xb3312fa7e23ee7e4988e056be3f82d19181d9c6efe8141120314088f5 013875ac656398d8a2ed19d2a85c8edd3ec2aef * p: 2^384 - 2^128 - 2^96 + 2^32 - 1 * m: 1 * k: 192 * expand_message: expand_message_xmd (Section 5.3.1) * H: SHA-384 * L: 72 * f: Simplified SWU method (Section 6.6.2) * Z: -12 Faz-Hernandez, et al. Expires 17 December 2022 [Page 38] Internet-Draft hash-to-curve June 2022 * h_eff: 1 P384_XMD:SHA-384_SSWU_NU_ is identical to P384_XMD:SHA-384_SSWU_RO_, except that the encoding type is encode_to_curve (Section 3). An optimized example implementation of the Simplified SWU mapping to P-384 is given in Appendix F.2. 8.4. Suites for NIST P-521 This section defines ciphersuites for the NIST P-521 elliptic curve [FIPS186-4]. P521_XMD:SHA-512_SSWU_RO_ is defined as follows: * encoding type: hash_to_curve (Section 3) * E: y^2 = x^3 + A * x + B, where - A = -3 - B = 0x51953eb9618e1c9a1f929a21a0b68540eea2da725b99b315f3b8b4899 18ef109e156193951ec7e937b1652c0bd3bb1bf073573df883d2c34f1ef451f d46b503f00 * p: 2^521 - 1 * m: 1 * k: 256 * expand_message: expand_message_xmd (Section 5.3.1) * H: SHA-512 * L: 98 * f: Simplified SWU method (Section 6.6.2) * Z: -4 * h_eff: 1 P521_XMD:SHA-512_SSWU_NU_ is identical to P521_XMD:SHA-512_SSWU_RO_, except that the encoding type is encode_to_curve (Section 3). An optimized example implementation of the Simplified SWU mapping to P-521 is given in Appendix F.2. Faz-Hernandez, et al. Expires 17 December 2022 [Page 39] Internet-Draft hash-to-curve June 2022 8.5. Suites for curve25519 and edwards25519 This section defines ciphersuites for curve25519 and edwards25519 [RFC7748]. Note that these ciphersuites MUST NOT be used when hashing to ristretto255 [I-D.irtf-cfrg-ristretto255-decaf448]. See Appendix B for information on how to hash to that group. curve25519_XMD:SHA-512_ELL2_RO_ is defined as follows: * encoding type: hash_to_curve (Section 3) * E: K * t^2 = s^3 + J * s^2 + s, where - J = 486662 - K = 1 * p: 2^255 - 19 * m: 1 * k: 128 * expand_message: expand_message_xmd (Section 5.3.1) * H: SHA-512 * L: 48 * f: Elligator 2 method (Section 6.7.1) * Z: 2 * h_eff: 8 edwards25519_XMD:SHA-512_ELL2_RO_ is identical to curve25519_XMD:SHA- 512_ELL2_RO_, except for the following parameters: * E: a * v^2 + w^2 = 1 + d * v^2 * w^2, where - a = -1 - d = 0x52036cee2b6ffe738cc740797779e89800700a4d4141d8ab75eb4dca1 35978a3 * f: Twisted Edwards Elligator 2 method (Section 6.8.2) * M: curve25519 defined in [RFC7748], Section 4.1 Faz-Hernandez, et al. Expires 17 December 2022 [Page 40] Internet-Draft hash-to-curve June 2022 * rational_map: the birational map defined in [RFC7748], Section 4.1 curve25519_XMD:SHA-512_ELL2_NU_ is identical to curve25519_XMD:SHA- 512_ELL2_RO_, except that the encoding type is encode_to_curve (Section 3). edwards25519_XMD:SHA-512_ELL2_NU_ is identical to edwards25519_XMD:SHA-512_ELL2_RO_, except that the encoding type is encode_to_curve (Section 3). Optimized example implementations of the above mappings are given in Appendix G.2.1 and Appendix G.2.2. 8.6. Suites for curve448 and edwards448 This section defines ciphersuites for curve448 and edwards448 [RFC7748]. Note that these ciphersuites MUST NOT be used when hashing to decaf448 [I-D.irtf-cfrg-ristretto255-decaf448]. See Appendix C for information on how to hash to that group. curve448_XOF:SHAKE256_ELL2_RO_ is defined as follows: * encoding type: hash_to_curve (Section 3) * E: K * t^2 = s^3 + J * s^2 + s, where - J = 156326 - K = 1 * p: 2^448 - 2^224 - 1 * m: 1 * k: 224 * expand_message: expand_message_xof (Section 5.3.2) * H: SHAKE256 * L: 84 * f: Elligator 2 method (Section 6.7.1) * Z: -1 * h_eff: 4 Faz-Hernandez, et al. Expires 17 December 2022 [Page 41] Internet-Draft hash-to-curve June 2022 edwards448_XOF:SHAKE256_ELL2_RO_ is identical to curve448_XOF:SHAKE256_ELL2_RO_, except for the following parameters: * E: a * v^2 + w^2 = 1 + d * v^2 * w^2, where - a = 1 - d = -39081 * f: Twisted Edwards Elligator 2 method (Section 6.8.2) * M: curve448, defined in [RFC7748], Section 4.2 * rational_map: the 4-isogeny map defined in [RFC7748], Section 4.2 curve448_XOF:SHAKE256_ELL2_NU_ is identical to curve448_XOF:SHAKE256_ELL2_RO_, except that the encoding type is encode_to_curve (Section 3). edwards448_XOF:SHAKE256_ELL2_NU_ is identical to edwards448_XOF:SHAKE256_ELL2_RO_, except that the encoding type is encode_to_curve (Section 3). Optimized example implementations of the above mappings are given in Appendix G.2.3 and Appendix G.2.4. 8.7. Suites for secp256k1 This section defines ciphersuites for the secp256k1 elliptic curve [SEC2]. secp256k1_XMD:SHA-256_SSWU_RO_ is defined as follows: * encoding type: hash_to_curve (Section 3) * E: y^2 = x^3 + 7 * p: 2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1 * m: 1 * k: 128 * expand_message: expand_message_xmd (Section 5.3.1) * H: SHA-256 * L: 48 Faz-Hernandez, et al. Expires 17 December 2022 [Page 42] Internet-Draft hash-to-curve June 2022 * f: Simplified SWU for AB == 0 (Section 6.6.3) * Z: -11 * E': y'^2 = x'^3 + A' * x' + B', where - A': 0x3f8731abdd661adca08a5558f0f5d272e953d363cb6f0e5d405447c01 a444533 - B': 1771 * iso_map: the 3-isogeny map from E' to E given in Appendix E.1 * h_eff: 1 secp256k1_XMD:SHA-256_SSWU_NU_ is identical to secp256k1_XMD:SHA- 256_SSWU_RO_, except that the encoding type is encode_to_curve (Section 3). An optimized example implementation of the Simplified SWU mapping to the curve E' isogenous to secp256k1 is given in Appendix F.2. 8.8. Suites for BLS12-381 This section defines ciphersuites for groups G1 and G2 of the BLS12-381 elliptic curve [BLS12-381]. The curve parameters in this section match the ones listed in [I-D.irtf-cfrg-pairing-friendly-curves], Appendix C. 8.8.1. BLS12-381 G1 BLS12381G1_XMD:SHA-256_SSWU_RO_ is defined as follows: * encoding type: hash_to_curve (Section 3) * E: y^2 = x^3 + 4 * p: 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f 6241eabfffeb153ffffb9feffffffffaaab * m: 1 * k: 128 * expand_message: expand_message_xmd (Section 5.3.1) * H: SHA-256 Faz-Hernandez, et al. Expires 17 December 2022 [Page 43] Internet-Draft hash-to-curve June 2022 * L: 64 * f: Simplified SWU for AB == 0 (Section 6.6.3) * Z: 11 * E': y'^2 = x'^3 + A' * x' + B', where - A' = 0x144698a3b8e9433d693a02c96d4982b0ea985383ee66a8d8e8981aef d881ac98936f8da0e0f97f5cf428082d584c1d - B' = 0x12e2908d11688030018b12e8753eee3b2016c1f0f24f4070a0b9c14f cef35ef55a23215a316ceaa5d1cc48e98e172be0 * iso_map: the 11-isogeny map from E' to E given in Appendix E.2 * h_eff: 0xd201000000010001 BLS12381G1_XMD:SHA-256_SSWU_NU_ is identical to BLS12381G1_XMD:SHA- 256_SSWU_RO_, except that the encoding type is encode_to_curve (Section 3). Note that the h_eff values for these suites are chosen for compatibility with the fast cofactor clearing method described by Scott ([WB19] Section 5). An optimized example implementation of the Simplified SWU mapping to the curve E' isogenous to BLS12-381 G1 is given in Appendix F.2. 8.8.2. BLS12-381 G2 BLS12381G2_XMD:SHA-256_SSWU_RO_ is defined as follows: * encoding type: hash_to_curve (Section 3) * E: y^2 = x^3 + 4 * (1 + I) * base field F is GF(p^m), where - p: 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6 b0f6241eabfffeb153ffffb9feffffffffaaab - m: 2 - (1, I) is the basis for F, where I^2 + 1 == 0 in F * k: 128 Faz-Hernandez, et al. Expires 17 December 2022 [Page 44] Internet-Draft hash-to-curve June 2022 * expand_message: expand_message_xmd (Section 5.3.1) * H: SHA-256 * L: 64 * f: Simplified SWU for AB == 0 (Section 6.6.3) * Z: -(2 + I) * E': y'^2 = x'^3 + A' * x' + B', where - A' = 240 * I - B' = 1012 * (1 + I) * iso_map: the isogeny map from E' to E given in Appendix E.3 * h_eff: 0xbc69f08f2ee75b3584c6a0ea91b352888e2a8e9145ad7689986ff0315 08ffe1329c2f178731db956d82bf015d1212b02ec0ec69d7477c1ae954cbc06689 f6a359894c0adebbf6b4e8020005aaa95551 BLS12381G2_XMD:SHA-256_SSWU_NU_ is identical to BLS12381G2_XMD:SHA- 256_SSWU_RO_, except that the encoding type is encode_to_curve (Section 3). Note that the h_eff values for these suites are chosen for compatibility with the fast cofactor clearing method described by Budroni and Pintore ([BP17], Section 4.1), and summarized in Appendix G.3. An optimized example implementation of the Simplified SWU mapping to the curve E' isogenous to BLS12-381 G2 is given in Appendix F.2. 8.9. Defining a new hash-to-curve suite For elliptic curves not listed elsewhere in Section 8, a new hash-to- curve suite can be defined by: 1. E, F, p, and m are determined by the elliptic curve and its base field. 2. k is an upper bound on the target security level of the suite (Section 10.8). A reasonable choice of k is ceil(log2(r) / 2), where r is the order of the subgroup G of the curve E (Section 2.1). Faz-Hernandez, et al. Expires 17 December 2022 [Page 45] Internet-Draft hash-to-curve June 2022 3. Choose encoding type, either hash_to_curve or encode_to_curve (Section 3). 4. Compute L as described in Section 5. 5. Choose an expand_message variant from Section 5.3 plus any underlying cryptographic primitives (e.g., a hash function H). 6. Choose a mapping following the guidelines in Section 6.1, and select any required parameters for that mapping. 7. Choose h_eff to be either the cofactor of E or, if a fast cofactor clearing method is to be used, a value appropriate to that method as discussed in Section 7. 8. Construct a Suite ID following the guidelines in Section 8.10. 8.10. Suite ID naming conventions Suite IDs MUST be constructed as follows: CURVE_ID || "_" || HASH_ID || "_" || MAP_ID || "_" || ENC_VAR || "_" The fields CURVE_ID, HASH_ID, MAP_ID, and ENC_VAR are ASCII-encoded strings of at most 64 characters each. Fields MUST contain only ASCII characters between 0x21 and 0x7E (inclusive) except that underscore (i.e., 0x5f) is not allowed. As indicated above, each field (including the last) is followed by an underscore ("_", ASCII 0x5f). This helps to ensure that Suite IDs are prefix free. Suite IDs MUST include the final underscore and MUST NOT include any characters after the final underscore. Suite ID fields MUST be chosen as follows: * CURVE_ID: a human-readable representation of the target elliptic curve. * HASH_ID: a human-readable representation of the expand_message function and any underlying hash primitives used in hash_to_field (Section 5). This field MUST be constructed as follows: EXP_TAG || ":" || HASH_NAME EXP_TAG indicates the expand_message variant: - "XMD" for expand_message_xmd (Section 5.3.1). Faz-Hernandez, et al. Expires 17 December 2022 [Page 46] Internet-Draft hash-to-curve June 2022 - "XOF" for expand_message_xof (Section 5.3.2). HASH_NAME is a human-readable name for the underlying hash primitive. As examples: 1. For expand_message_xof (Section 5.3.2) with SHAKE128, HASH_ID is "XOF:SHAKE128". 2. For expand_message_xmd (Section 5.3.1) with SHA3-256, HASH_ID is "XMD:SHA3-256". Suites that use an alternative hash_to_field function that meets the requirements in Section 5.1 MUST indicate this by appending a tag identifying that function to the HASH_ID field, separated by a colon (":", ASCII 0x3A). * MAP_ID: a human-readable representation of the map_to_curve function as defined in Section 6. These are defined as follows: - "SVDW" for or Shallue and van de Woestijne (Section 6.6.1). - "SSWU" for Simplified SWU (Section 6.6.2, Section 6.6.3). - "ELL2" for Elligator 2 (Section 6.7.1, Section 6.8.2). * ENC_VAR: a string indicating the encoding type and other information. The first two characters of this string indicate whether the suite represents a hash_to_curve or an encode_to_curve operation (Section 3), as follows: - If ENC_VAR begins with "RO", the suite uses hash_to_curve. - If ENC_VAR begins with "NU", the suite uses encode_to_curve. - ENC_VAR MUST NOT begin with any other string. ENC_VAR MAY also be used to encode other information used to identify variants, for example, a version number. The RECOMMENDED way to do so is to add one or more subfields separated by colons. For example, "RO:V02" is an appropriate ENC_VAR value for the second version of a uniform encoding suite, while "RO:V02:FOO01:BAR17" might be used to indicate a variant of that suite. 9. IANA considerations This document has no IANA actions. Faz-Hernandez, et al. Expires 17 December 2022 [Page 47] Internet-Draft hash-to-curve June 2022 10. Security considerations This section contains additional security considerations about the hash-to-curve mechanisms described in this document. 10.1. Properties of encodings Each encoding type (Section 3) accepts an arbitrary byte string and maps it to a point on the curve sampled from a distribution that depends on the encoding type. It is important to note that using a nonuniform encoding or directly evaluating one of the mappings of Section 6 produces an output that is easily distinguished from a uniformly random point. Applications that use a nonuniform encoding SHOULD carefully analyze the security implications of nonuniformity. When the required encoding is not clear, applications SHOULD use a uniform encoding. Both encodings given in Section 3 can output the identity element of the group G. The probability that either encoding function outputs the identity element is roughly 1/r for a random input, which is negligible for cryptographically useful elliptic curves. Further, it is computationally infeasible to find an input to either encoding function whose corresponding output is the identity element. (Both of these properties hold when the encoding functions are instantiated with a hash_to_field function that follows all guidelines in Section 5.) Protocols that use these encoding functions SHOULD NOT add a special case to detect and "fix" the identity element. When the hash_to_curve function (Section 3) is instantiated with a hash_to_field function that is indifferentiable from a random oracle (Section 5), the resulting function is indifferentiable from a random oracle ([MRH04], [BCIMRT10], [FFSTV13], [LBB19], [H20]). In many cases such a function can be safely used in cryptographic protocols whose security analysis assumes a random oracle that outputs uniformly random points on an elliptic curve. As Ristenpart et al. discuss in [RSS11], however, not all security proofs that rely on random oracles continue to hold when those oracles are replaced by indifferentiable functionalities. This limitation should be considered when analyzing the security of protocols relying on the hash_to_curve function. Faz-Hernandez, et al. Expires 17 December 2022 [Page 48] Internet-Draft hash-to-curve June 2022 10.2. Hashing passwords When hashing passwords using any function described in this document, an adversary who learns the output of the hash function (or potentially any intermediate value, e.g., the output of hash_to_field) may be able to carry out a dictionary attack. To mitigate such attacks, it is recommended to first execute a more costly key derivation function (e.g., PBKDF2 [RFC2898], scrypt [RFC7914], or Argon2 [I-D.irtf-cfrg-argon2]) on the password, then hash the output of that function to the target elliptic curve. For collision resistance, the hash underlying the key derivation function should be chosen according to the guidelines listed in Section 5.3.1. 10.3. Constant-time requirements Constant-time implementations of all functions in this document are STRONGLY RECOMMENDED for all uses, to avoid leaking information via side channels. It is especially important to use a constant-time implementation when inputs to an encoding are secret values; in such cases, constant-time implementations are REQUIRED for security against timing attacks (e.g., [VR20]). When constant-time implementations are required, all basic operations and utility functions must be implemented in constant time, as discussed in Section 4. In some applications (e.g., embedded systems), leakage through other side channels (e.g., power or electromagnetic side channels) may be pertinent. Defending against such leakage is outside the scope of this document, because the nature of the leakage and the appropriate defense depend on the application. 10.4. encode_to_curve: output distribution and indifferentiability The encode_to_curve function (Section 3) returns points sampled from a distribution that is statistically far from uniform. This distribution is bounded roughly as follows: first, it includes at least one eighth of the points in G, and second, the probability of points in the distribution varies by at most a factor of four. These bounds hold when encode_to_curve is instantiated with any of the map_to_curve functions in Section 6. The bounds above are derived from several works in the literature. Specifically: * Shallue and van de Woestijne [SW06] and Fouque and Tibouchi [FT12] derive bounds on the Shallue-van de Woestijne mapping (Section 6.6.1). * Fouque and Tibouchi [FT10] and Tibouchi [T14] derive bounds for the Simplified SWU mapping (Section 6.6.2, Section 6.6.3). Faz-Hernandez, et al. Expires 17 December 2022 [Page 49] Internet-Draft hash-to-curve June 2022 * Bernstein et al. [BHKL13] derive bounds for the Elligator 2 mapping (Section 6.7.1, Section 6.8.2). Indifferentiability of encode_to_curve follows from an argument similar to the one given by Brier et al. [BCIMRT10]; we briefly sketch. Consider an ideal random oracle Hc() that samples from the distribution induced by the map_to_curve function called by encode_to_curve, and assume for simplicity that the target elliptic curve has cofactor 1 (a similar argument applies for non-unity cofactors). Indifferentiability holds just if it is possible to efficiently simulate the "inner" random oracle in encode_to_curve, namely, hash_to_field. The simulator works as follows: on a fresh query msg, the simulator queries Hc(msg) and receives a point P in the image of map_to_curve (if msg is the same as a prior query, the simulator just returns the value it gave in response to that query). The simulator then computes the possible preimages of P under map_to_curve, i.e., elements u of F such that map_to_curve(u) == P (Tibouchi [T14] shows that this can be done efficiently for the Shallue-van de Woestijne and Simplified SWU maps, and Bernstein et al. show the same for Elligator 2). The simulator selects one such preimage at random and returns this value as the simulated output of the "inner" random oracle. By hypothesis, Hc() samples from the distribution induced by map_to_curve on a uniformly random input element of F, so this value is uniformly random and induces the correct point P when passed through map_to_curve. 10.5. hash_to_field security The hash_to_field function defined in Section 5 is indifferentiable from a random oracle [MRH04] when expand_message (Section 5.3) is modeled as a random oracle. By composability of indifferentiability proofs, this also holds when expand_message is proved indifferentiable from a random oracle relative to an underlying primitive that is modeled as a random oracle. When following the guidelines in Section 5.3, both variants of expand_message defined in that section meet this requirement (see also Section 10.6). We very briefly sketch the indifferentiability argument for hash_to_field. Notice that each integer mod p that hash_to_field returns (i.e., each element of the vector representation of F) is a member of an equivalence class of roughly 2^k integers of length log2(p) + k bits, all of which are equal modulo p. For each integer mod p that hash_to_field returns, the simulator samples one member of this equivalence class at random and outputs the byte string returned by I2OSP. (Notice that this is essentially the inverse of the hash_to_field procedure.) Faz-Hernandez, et al. Expires 17 December 2022 [Page 50] Internet-Draft hash-to-curve June 2022 10.6. expand_message_xmd security The expand_message_xmd function defined in Section 5.3.1 is indifferentiable from a random oracle [MRH04] when one of the following holds: 1. H is indifferentiable from a random oracle, 2. H is a sponge-based hash function whose inner function is modeled as a random transformation or random permutation [BDPV08], or 3. H is a Merkle-Damgaard hash function whose compression function is modeled as a random oracle [CDMP05]. For cases (1) and (2), the indifferentiability of expand_message_xmd follows directly from the indifferentiability of H. For case (3), i.e., for H a Merkle-Damgaard hash function, indifferentiability follows from [CDMP05], Theorem 3.5. In particular, expand_message_xmd computes b_0 by prefixing the message with one block of 0-bytes plus auxiliary information (length, counter, and DST). Then, each of the output blocks b_i, i >= 1 in expand_message_xmd is the result of invoking H on a unique, prefix- free encoding of b_0. This is true, first, because the length of the input to all such invocations is equal and fixed by the choice of H and DST, and second, because each such input has a unique suffix (because of the inclusion of the counter byte I2OSP(i, 1)). The essential difference between the construction of [CDMP05] and expand_message_xmd is that the latter hashes a counter appended to strxor(b_0, b_(i - 1)) (step 10) rather than to b_0. This approach increases the Hamming distance between inputs to different invocations of H, which reduces the likelihood that nonidealities in H affect the distribution of the b_i values. We note that expand_message_xmd can be used to instantiate a general- purpose indifferentiable functionality with variable-length output based on any hash function meeting one of the above criteria. Applications that use expand_message_xmd outside of hash_to_field should ensure domain separation by picking a distinct value for DST. 10.7. Domain separation for expand_message variants As discussed in Section 2.2.5, the purpose of domain separation is to ensure that security analyses of cryptographic protocols that query multiple independent random oracles remain valid even if all of these random oracles are instantiated based on one underlying function H. Faz-Hernandez, et al. Expires 17 December 2022 [Page 51] Internet-Draft hash-to-curve June 2022 The expand_message variants in this document (Section 5.3) ensure domain separation by appending a suffix-free-encoded domain separation tag DST_prime to all strings hashed by H, an underlying hash or extendable-output function. (Other expand_message variants that follow the guidelines in Section 5.3.4 are expected to behave similarly, but these should be analyzed on a case-by-case basis.) For security, applications that use the same function H outside of expand_message should enforce domain separation between those uses of H and expand_message, and should separate all of these from uses of H in other applications. This section suggests four methods for enforcing domain separation from expand_message variants, explains how each method achieves domain separation, and lists the situations in which each is appropriate. These methods share a high-level structure: the application designer fixes a tag DST_ext distinct from DST_prime and augments calls to H with DST_ext. Each method augments calls to H differently, and each may impose additional requirements on DST_ext. These methods can be used to instantiate multiple domain separated functions (e.g., H1 and H2) by selecting distinct DST_ext values for each (e.g., DST_ext1, DST_ext2). 1. (Suffix-only domain separation.) This method is useful when domain separating invocations of H from expand_message_xmd or expand_message_xof. It is not appropriate for domain separating expand_message from HMAC-H [RFC2104]; for that purpose, see method 4. To instantiate a suffix-only domain separated function Hso, compute Hso(msg) = H(msg || DST_ext) DST_ext should be suffix-free encoded (e.g., by appending one byte encoding the length of DST_ext) to make it infeasible to find distinct (msg, DST_ext) pairs that hash to the same value. This method ensures domain separation because all distinct invocations of H have distinct suffixes, since DST_ext is distinct from DST_prime. 2. (Prefix-suffix domain separation.) This method can be used in the same cases as the suffix-only method. To instantiate a prefix-suffix domain separated function Hps, compute Faz-Hernandez, et al. Expires 17 December 2022 [Page 52] Internet-Draft hash-to-curve June 2022 Hps(msg) = H(DST_ext || msg || I2OSP(0, 1)) DST_ext should be prefix-free encoded (e.g., by adding a one-byte prefix that encodes the length of DST_ext) to make it infeasible to find distinct (msg, DST_ext) pairs that hash to the same value. This method ensures domain separation because appending the byte I2OSP(0, 1) ensures that inputs to H inside Hps are distinct from those inside expand_message. Specifically, the final byte of DST_prime encodes the length of DST, which is required to be nonzero (Section 3.1, requirement 2), and DST_prime is always appended to invocations of H inside expand_message. 3. (Prefix-only domain separation.) This method is only useful for domain separating invocations of H from expand_message_xmd. It does not give domain separation for expand_message_xof or HMAC-H. To instantiate a prefix-only domain separated function Hpo, compute Hpo(msg) = H(DST_ext || msg) In order for this method to give domain separation, DST_ext should be at least b bits long, where b is the number of bits output by the hash function H. In addition, at least one of the first b bits must be nonzero. Finally, DST_ext should be prefix- free encoded (e.g., by adding a one-byte prefix that encodes the length of DST_ext) to make it infeasible to find distinct (msg, DST_ext) pairs that hash to the same value. This method ensures domain separation as follows. First, since DST_ext contains at least one nonzero bit among its first b bits, it is guaranteed to be distinct from the value Z_pad (Section 5.3.1, step 4), which ensures that all inputs to H are distinct from the input used to generate b_0 in expand_message_xmd. Second, since DST_ext is at least b bits long, it is almost certainly distinct from the values b_0 and strxor(b_0, b_(i - 1)), and therefore all inputs to H are distinct from the inputs used to generate b_i, i >= 1, with high probability. 4. (XMD-HMAC domain separation.) This method is useful for domain separating invocations of H inside HMAC-H (i.e., HMAC [RFC2104] instantiated with hash function H) from expand_message_xmd. It also applies to HKDF-H [RFC5869], as discussed below. Faz-Hernandez, et al. Expires 17 December 2022 [Page 53] Internet-Draft hash-to-curve June 2022 Specifically, this method applies when HMAC-H is used with a non- secret key to instantiate a random oracle based on a hash function H (note that expand_message_xmd can also be used for this purpose; see Section 10.6). When using HMAC-H with a high- entropy secret key, domain separation is not necessary; see discussion below. To choose a non-secret HMAC key DST_key that ensures domain separation from expand_message_xmd, compute DST_key_preimage = "DERIVE-HMAC-KEY-" || DST_ext || I2OSP(0, 1) DST_key = H(DST_key_preimage) Then, to instantiate the random oracle Hro using HMAC-H, compute Hro(msg) = HMAC-H(DST_key, msg) The trailing zero byte in DST_key_preimage ensures that this value is distinct from inputs to H inside expand_message_xmd (because all such inputs have suffix DST_prime, which cannot end with a zero byte as discussed above). This ensures domain separation because, with overwhelming probability, all inputs to H inside of HMAC-H using key DST_key have prefixes that are distinct from the values Z_pad, b_0, and strxor(b_0, b_(i - 1)) inside of expand_message_xmd. For uses of HMAC-H that instantiate a private random oracle by fixing a high-entropy secret key, domain separation from expand_message_xmd is not necessary. This is because, similarly to the case above, all inputs to H inside HMAC-H using this secret key almost certainly have distinct prefixes from all inputs to H inside expand_message_xmd. Finally, this method can be used with HKDF-H [RFC5869] by fixing the salt input to HKDF-Extract to DST_key, computed as above. This ensures domain separation for HKDF-Extract by the same argument as for HMAC-H using DST_key. Moreover, assuming that the IKM input to HKDF-Extract has sufficiently high entropy (say, commensurate with the security parameter), the HKDF-Expand step is domain separated by the same argument as for HMAC-H with a high-entropy secret key (since PRK is exactly that). Faz-Hernandez, et al. Expires 17 December 2022 [Page 54] Internet-Draft hash-to-curve June 2022 10.8. Target security levels Each ciphersuite specifies a target security level (in bits) for the underlying curve. This parameter ensures the corresponding hash_to_field instantiation is conservative and correct. We stress that this parameter is only an upper bound on the security level of the curve, and is neither a guarantee nor endorsement of its suitability for a given application. Mathematical and cryptographic advancements may reduce the effective security level for any curve. 11. Acknowledgements The authors would like to thank Adam Langley for his detailed writeup of Elligator 2 with Curve25519 [L13]; Dan Boneh, Christopher Patton, Benjamin Lipp, and Leonid Reyzin for educational discussions; and David Benjamin, Daniel Bourdrez, Frank Denis, Sean Devlin, Justin Drake, Bjoern Haase, Mike Hamburg, Dan Harkins, Daira Hopwood, Thomas Icart, Andy Polyakov, Thomas Pornin, Mamy Ratsimbazafy, Michael Scott, Filippo Valsorda, and Mathy Vanhoef for helpful reviews and feedback. 12. Contributors * Sharon Goldberg, Boston University (goldbe@cs.bu.edu) * Ela Lee, Royal Holloway, University of London (Ela.Lee.2010@live.rhul.ac.uk) * Michele Orru (michele.orru@ens.fr) 13. References 13.1. Normative References [EID4730] Langley, A., "RFC 7748, Errata ID 4730", July 2016, . [I-D.irtf-cfrg-pairing-friendly-curves] Sakemi, Y., Kobayashi, T., Saito, T., and R. S. Wahby, "Pairing-Friendly Curves", Work in Progress, Internet- Draft, draft-irtf-cfrg-pairing-friendly-curves-10, 30 July 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Faz-Hernandez, et al. Expires 17 December 2022 [Page 55] Internet-Draft hash-to-curve June 2022 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 13.2. Informative References [AFQTZ14] Aranha, D.F., Fouque, P.A., Qian, C., Tibouchi, M., and J.C. Zapalowicz, "Binary Elligator squared", DOI 10.1007/978-3-319-13051-4_2, pages 20-37, In Selected Areas in Cryptography - SAC 2014, 2014, . [AR13] Adj, G. and F. Rodriguez-Henriquez, "Square Root Computation over Even Extension Fields", DOI 10.1109/TC.2013.145, pages 2829-2841, In IEEE Transactions on Computers. vol 63 issue 11, November 2014, . [BBJLP08] Bernstein, D.J., Birkner, P., Joye, M., Lange, T., and C. Peters, "Twisted Edwards curves", DOI 10.1007/978-3-540-68164-9_26, pages 389-405, In AFRICACRYPT 2008, 2008, . [BCIMRT10] Brier, E., Coron, J-S., Icart, T., Madore, D., Randriam, H., and M. Tibouchi, "Efficient Indifferentiable Hashing into Ordinary Elliptic Curves", DOI 10.1007/978-3-642-14623-7_13, pages 237-254, In Advances in Cryptology - CRYPTO 2010, 2010, . [BDPV08] Bertoni,, G., Daemen, J., Peeters, M., and G. Van Assche, "On the Indifferentiability of the Sponge Construction", DOI 10.1007/978-3-540-78967-3_11, pages 181-197, In Advances in Cryptology - EUROCRYPT 2008, 2008, . Faz-Hernandez, et al. Expires 17 December 2022 [Page 56] Internet-Draft hash-to-curve June 2022 [BF01] Boneh, D. and M. Franklin, "Identity-based encryption from the Weil pairing", DOI 10.1007/3-540-44647-8_13, pages 213-229, In Advances in Cryptology - CRYPTO 2001, August 2001, . [BHKL13] Bernstein, D.J., Hamburg, M., Krasnova, A., and T. Lange, "Elligator: elliptic-curve points indistinguishable from uniform random strings", DOI 10.1145/2508859.2516734, pages 967-980, In Proceedings of the 2013 ACM SIGSAC Conference on Computer and Communications Security, November 2013, . [BLAKE2X] Aumasson, J-P., Neves, S., Wilcox-O'Hearn, Z., and C. Winnerlein, "BLAKE2X", December 2016, . [BLMP19] Bernstein, D.J., Lange, T., Martindale, C., and L. Panny, "Quantum circuits for the CSIDH: optimizing quantum evaluation of isogenies", DOI 10.1007/978-3-030-17656-3, In Advances in Cryptology - EUROCRYPT 2019, 2019, . [BLS01] Boneh, D., Lynn, B., and H. Shacham, "Short signatures from the Weil pairing", DOI 10.1007/s00145-004-0314-9, pages 297-319, In Journal of Cryptology, vol 17, July 2004, . [BLS03] Barreto, P., Lynn, B., and M. Scott, "Constructing Elliptic Curves with Prescribed Embedding Degrees", DOI 10.1007/3-540-36413-7_19, pages 257-267, In Security in Communication Networks, 2003, . [BLS12-381] Bowe, S., "BLS12-381: New zk-SNARK Elliptic Curve Construction", March 2017, . [BM92] Bellovin, S.M. and M. Merritt, "Encrypted key exchange: Password-based protocols secure against dictionary attacks", DOI 10.1109/RISP.1992.213269, pages 72-84, In IEEE Symposium on Security and Privacy - Oakland 1992, 1992, . Faz-Hernandez, et al. Expires 17 December 2022 [Page 57] Internet-Draft hash-to-curve June 2022 [BMP00] Boyko, V., MacKenzie, P.D., and S. Patel, "Provably secure password-authenticated key exchange using Diffie-Hellman", DOI 10.1007/3-540-45539-6_12, pages 156-171, In Advances in Cryptology - EUROCRYPT 2000, May 2000, . [BN05] Barreto, P. and M. Naehrig, "Pairing-Friendly Elliptic Curves of Prime Order", DOI 10.1007/11693383_22, pages 319-331, In Selected Areas in Cryptography 2005, 2006, . [BP17] Budroni, A. and F. Pintore, "Efficient hash maps to G2 on BLS curves", ePrint 2017/419, May 2017, . [BR93] Bellare, M. and P. Rogaway, "Random oracles are practical: a paradigm for designing efficient protocols", DOI 10.1145/168588.168596, pages 62-73, In Proceedings of the 1993 ACM Conference on Computer and Communications Security, December 1993, . [C93] Cohen, H., "A Course in Computational Algebraic Number Theory", ISBN 9783642081422, publisher Springer-Verlag, 1993, . [CDMP05] Coron, J-S., Dodis, Y., Malinaud, C., and P. Puniya, "Merkle-Damgaard Revisited: How to Construct a Hash Function", DOI 10.1007/11535218_26, pages 430-448, In Advances in Cryptology - CRYPTO 2005, 2005, . [CFADLNV05] Cohen, H., Frey, G., Avanzi, R., Doche, C., Lange, T., Nguyen, K., and F. Vercauteren, "Handbook of Elliptic and Hyperelliptic Curve Cryptography", ISBN 9781584885184, publisher Chapman and Hall / CRC, 2005, . [CK11] Couveignes, J. and J. Kammerer, "The geometry of flex tangents to a cubic curve and its parameterizations", DOI 10.1016/j.jsc.2011.11.003, pages 266-281, In Journal of Symbolic Computation, vol 47 issue 3, 2012, . Faz-Hernandez, et al. Expires 17 December 2022 [Page 58] Internet-Draft hash-to-curve June 2022 [F11] Farashahi, R.R., "Hashing into Hessian curves", DOI 10.1007/978-3-642-21969-6_17, pages 278-289, In AFRICACRYPT 2011, 2011, . [FFSTV13] Farashahi, R.R., Fouque, P.A., Shparlinski, I.E., Tibouchi, M., and J.F. Voloch, "Indifferentiable deterministic hashing to elliptic and hyperelliptic curves", DOI 10.1090/S0025-5718-2012-02606-8, pages 491-512, In Math. Comp. vol 82, 2013, . [FIPS180-4] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", August 2015, . [FIPS186-4] National Institute of Standards and Technology (NIST), "FIPS Publication 186-4: Digital Signature Standard", July 2013, . [FIPS202] National Institute of Standards and Technology (NIST), "SHA-3 Standard: Permutation-Based Hash and Extendable- Output Functions", August 2015, . [FJT13] Fouque, P-A., Joux, A., and M. Tibouchi, "Injective encodings to elliptic curves", DOI 10.1007/978-3-642-39059-3_14, pages 203-218, In ACISP 2013, 2013, . [FKR11] Fuentes-Castaneda, L., Knapp, E., and F. Rodriguez- Henriquez, "Fast Hashing to G2 on Pairing-Friendly Curves", DOI 10.1007/978-3-642-28496-0_25, pages 412-430, In Selected Areas in Cryptography, 2011, . [FSV09] Farashahi, R.R., Shparlinski, I.E., and J.F. Voloch, "On hashing into elliptic curves", DOI 10.1515/JMC.2009.022, pages 353-360, In Journal of Mathematical Cryptology, vol 3 no 4, 2009, . Faz-Hernandez, et al. Expires 17 December 2022 [Page 59] Internet-Draft hash-to-curve June 2022 [FT10] Fouque, P-A. and M. Tibouchi, "Estimating the size of the image of deterministic hash functions to elliptic curves.", DOI 10.1007/978-3-642-14712-8_5, pages 81-91, In Progress in Cryptology - LATINCRYPT 2010, 2010, . [FT12] Fouque, P-A. and M. Tibouchi, "Indifferentiable Hashing to Barreto-Naehrig Curves", DOI 10.1007/978-3-642-33481-8_1, pages 1-7, In Progress in Cryptology - LATINCRYPT 2012, 2012, . [H20] Hamburg, M., "Indifferentiable hashing from Elligator 2", 2020, . [hash2curve-repo] "Hashing to Elliptic Curves - GitHub repository", 2019, . [I-D.irtf-cfrg-argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications", Work in Progress, Internet-Draft, draft-irtf-cfrg-argon2-13, 11 March 2021, . [I-D.irtf-cfrg-bls-signature] Boneh, D., Gorbunov, S., Wahby, R. S., Wee, H., and Z. Zhang, "BLS Signatures", Work in Progress, Internet-Draft, draft-irtf-cfrg-bls-signature-04, 10 September 2020, . [I-D.irtf-cfrg-ristretto255-decaf448] Valence, H. D., Grigg, J., Hamburg, M., Lovecruft, I., Tankersley, G., and F. Valsorda, "The ristretto255 and decaf448 Groups", Work in Progress, Internet-Draft, draft- irtf-cfrg-ristretto255-decaf448-03, 25 February 2022, . [I-D.irtf-cfrg-voprf] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. Wood, "Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups", Work in Progress, Internet-Draft, draft-irtf-cfrg-voprf-09, 8 February 2022, . Faz-Hernandez, et al. Expires 17 December 2022 [Page 60] Internet-Draft hash-to-curve June 2022 [I-D.irtf-cfrg-vrf] Goldberg, S., Reyzin, L., Papadopoulos, D., and J. Vcelak, "Verifiable Random Functions (VRFs)", Work in Progress, Internet-Draft, draft-irtf-cfrg-vrf-12, 26 May 2022, . [Icart09] Icart, T., "How to Hash into Elliptic Curves", DOI 10.1007/978-3-642-03356-8_18, pages 303-316, In Advances in Cryptology - CRYPTO 2009, 2009, . [J96] Jablon, D.P., "Strong password-only authenticated key exchange", DOI 10.1145/242896.242897, pages 5-26, In SIGCOMM Computer Communication Review, vol 26 issue 5, 1996, . [jubjub-fq] "zkcrypto/jubjub - fq.rs", 2019, . [KLR10] Kammerer, J., Lercier, R., and G. Renault, "Encoding points on hyperelliptic curves over finite fields in deterministic polynomial time", DOI 10.1007/978-3-642-17455-1_18, pages 278-297, In PAIRING 2010, 2010, . [L13] Langley, A., "Implementing Elligator for Curve25519", 2013, . [LBB19] Lipp, B., Blanchet, B., and K. Bhargavan, "A Mechanised Proof of the WireGuard Virtual Private Network Protocol", In INRIA Research Report No. 9269, April 2019, . [MOV96] Menezes, A.J., van Oorschot, P.C., and S.A. Vanstone, "Handbook of Applied Cryptography", ISBN 9780849385230, publisher CRC Press, 1996, . Faz-Hernandez, et al. Expires 17 December 2022 [Page 61] Internet-Draft hash-to-curve June 2022 [MRH04] Maurer, U., Renner, R., and C. Holenstein, "Indifferentiability, impossibility results on reductions, and applications to the random oracle methodology", DOI 10.1007/978-3-540-24638-1_2, pages 21-39, In TCC 2004: Theory of Cryptography, February 2004, . [MRV99] Micali, S., Rabin, M., and S. Vadhan, "Verifiable Random Functions", DOI 10.1109/SFFCS.1999.814584, In Symposium on the Foundations of Computer Science, October 1999, . [MT98] Matsumoto, M. and T. Nishimura, "Mersenne twister: A 623-dimensionally equidistributed uniform pseudo-random number generator", DOI 10.1145/272991.272995, pages 3-30, In ACM Transactions on Modeling and Computer Simulation (TOMACS), Volume 8, Issue 1, January 1998, . [NR97] Naor, M. and O. Reingold, "Number-theoretic constructions of efficient pseudo-random functions", DOI 10.1109/SFCS.1997.646134, In Symposium on the Foundations of Computer Science, October 1997, . [p1363.2] IEEE Computer Society, "IEEE Standard Specification for Password-Based Public-Key Cryptography Techniques", September 2008, . [p1363a] IEEE Computer Society, "IEEE Standard Specifications for Public-Key Cryptography---Amendment 1: Additional Techniques", March 2004, . [P20] Pornin, T., "Efficient Elliptic Curve Operations On Microcontrollers With Finite Field Extensions", 2020, . [RCB16] Renes, J., Costello, C., and L. Batina, "Complete addition formulas for prime order elliptic curves", DOI 10.1007/978-3-662-49890-3_16, pages 403-428, In Advances in Cryptology - EUROCRYPT 2016, May 2016, . Faz-Hernandez, et al. Expires 17 December 2022 [Page 62] Internet-Draft hash-to-curve June 2022 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, DOI 10.17487/RFC2898, September 2000, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)", RFC 7693, DOI 10.17487/RFC7693, November 2015, . [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, August 2016, . [RSS11] Ristenpart, T., Shacham, H., and T. Shrimpton, "Careful with Composition: Limitations of the Indifferentiability Framework", DOI 10.1007/978-3-642-20465-4_27, pages 487-506, In Advances in Cryptology - EUROCRYPT 2011, May 2011, . [S05] Skalba, M., "Points on elliptic curves over finite fields", DOI 10.4064/aa117-3-7, pages 293-301, In Acta Arithmetica, vol 117 no 3, 2005, . [S85] Schoof, R., "Elliptic Curves Over Finite Fields and the Computation of Square Roots mod p", DOI 10.1090/S0025-5718-1985-0777280-6, pages 483-494, In Mathematics of Computation vol 44 issue 170, April 1985, . [SAGE] The Sage Developers, "SageMath, the Sage Mathematics Software System", 2019, . Faz-Hernandez, et al. Expires 17 December 2022 [Page 63] Internet-Draft hash-to-curve June 2022 [SBCDK09] Scott, M., Benger, N., Charlemagne, M., Dominguez Perez, L.J., and E.J. Kachisa, "Fast Hashing to G2 on Pairing- Friendly Curves", DOI 10.1007/978-3-642-03298-1_8, pages 102-113, In Pairing-Based Cryptography - Pairing 2009, 2009, . [SEC1] Standards for Efficient Cryptography Group (SECG), "SEC 1: Elliptic Curve Cryptography", May 2009, . [SEC2] Standards for Efficient Cryptography Group (SECG), "SEC 2: Recommended Elliptic Curve Domain Parameters", January 2010, . [SS04] Schinzel, A. and M. Skalba, "On equations y^2 = x^n + k in a finite field.", DOI 10.4064/ba52-3-1, pages 223-226, In Bulletin Polish Acad. Sci. Math. vol 52, no 3, 2004, . [SW06] Shallue, A. and C. van de Woestijne, "Construction of rational points on elliptic curves over finite fields", DOI 10.1007/11792086_36, pages 510-524, In Algorithmic Number Theory. ANTS 2006., 2006, . [T14] Tibouchi, M., "Elligator squared: Uniform points on elliptic curves of prime order as uniform random strings", DOI 10.1007/978-3-662-45472-5_10, pages 139-156, In Financial Cryptography and Data Security - FC 2014, 2014, . [TK17] Tibouchi, M. and T. Kim, "Improved elliptic curve hashing and point representation", DOI 10.1007/s10623-016-0288-2, pages 161-177, In Designs, Codes, and Cryptography, vol 82, 2017, . [U07] Ulas, M., "Rational points on certain hyperelliptic curves over finite fields", DOI 10.4064/ba55-2-1, pages 97-104, In Bulletin Polish Acad. Sci. Math. vol 55, no 2, 2007, . [VR20] Vanhoef, M. and E. Ronen, "Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd", In IEEE Symposium on Security & Privacy (SP), 2020, . Faz-Hernandez, et al. Expires 17 December 2022 [Page 64] Internet-Draft hash-to-curve June 2022 [W08] Washington, L.C., "Elliptic curves: Number theory and cryptography", ISBN 9781420071467, publisher Chapman and Hall / CRC, edition 2nd, 2008, . [W19] Wahby, R.S., "An explicit, generic parameterization for the Shallue--van de Woestijne map", 2019, . [WB19] Wahby, R.S. and D. Boneh, "Fast and simple constant-time hashing to the BLS12-381 elliptic curve", DOI 10.13154/tches.v2019.i4.154-179, ePrint 2019/403, issue 4, volume 2019, In IACR Trans. CHES, August 2019, . Appendix A. Related work The problem of mapping arbitrary bit strings to elliptic curve points has been the subject of both practical and theoretical research. This section briefly describes the background and research results that underly the recommendations in this document. This section is provided for informational purposes only. A naive but generally insecure method of mapping a string msg to a point on an elliptic curve E having n points is to first fix a point P that generates the elliptic curve group, and a hash function Hn from bit strings to integers less than n; then compute Hn(msg) * P, where the * operator represents scalar multiplication. The reason this approach is insecure is that the resulting point has a known discrete log relationship to P. Thus, except in cases where this method is specified by the protocol, it must not be used; doing so risks catastrophic security failures. Boneh et al. [BLS01] describe an encoding method they call MapToGroup, which works roughly as follows: first, use the input string to initialize a pseudorandom number generator, then use the generator to produce a value x in F. If x is the x-coordinate of a point on the elliptic curve, output that point. Otherwise, generate a new value x in F and try again. Since a random value x in F has probability about 1/2 of corresponding to a point on the curve, the expected number of tries is just two. However, the running time of this method, which is generally referred to as a probabilistic try- and-increment algorithm, depends on the input string. As such, it is not safe to use in protocols sensitive to timing side channels, as was exemplified by the Dragonblood attack [VR20]. Faz-Hernandez, et al. Expires 17 December 2022 [Page 65] Internet-Draft hash-to-curve June 2022 Schinzel and Skalba [SS04] introduce a method of constructing elliptic curve points deterministically, for a restricted class of curves and a very small number of points. Skalba [S05] generalizes this construction to more curves and more points on those curves. Shallue and van de Woestijne [SW06] further generalize and simplify Skalba's construction, yielding concretely efficient maps to a constant fraction of the points on almost any curve. Fouque and Tibouchi [FT12] give a parameterization of this mapping for Barreto- Naehrig pairing-friendly curves [BN05]. Ulas [U07] describes a simpler version of the Shallue-van de Woestijne map, and Brier et al. [BCIMRT10] give a further simplification, which the authors call the "simplified SWU" map. That simplified map applies only to fields of characteristic p = 3 (mod 4); Wahby and Boneh [WB19] generalize to fields of any characteristic, and give further optimizations. Boneh and Franklin give a deterministic algorithm mapping to certain supersingular curves over fields of characteristic p = 2 (mod 3) [BF01]. Icart gives another deterministic algorithm which maps to any curve over a field of characteristic p = 2 (mod 3) [Icart09]. Several extensions and generalizations follow this work, including [FSV09], [FT10], [KLR10], [F11], and [CK11]. Following the work of Farashahi [F11], Fouque et al. [FJT13] describe a mapping to curves over fields of characteristic p = 3 (mod 4) having a number of points divisible by 4. Bernstein et al. [BHKL13] optimize this mapping and describe a related mapping that they call "Elligator 2," which applies to any curve over a field of odd characteristic having a point of order 2. This includes Curve25519 and Curve448, both of which are CFRG-recommended curves [RFC7748]. Bernstein et al. [BLMP19] extend the Elligator 2 map to a class of supersingular curves over fields of characteristic p = 3 (mod 4). An important caveat regarding all of the above deterministic mapping functions is that none of them map to the entire curve, but rather to some fraction of the points. This means that they cannot be used directly to construct a random oracle that outputs points on the curve. Brier et al. [BCIMRT10] give two solutions to this problem. The first, which Brier et al. prove applies to Icart's method, computes f(H0(msg)) + f(H1(msg)) for two distinct hash functions H0 and H1 from bit strings to F and a mapping f from F to the elliptic curve E. The second, which applies to essentially all deterministic mappings but is more costly, computes f(H0(msg)) + H2(msg) * P, for P a generator of the elliptic curve group and H2 a hash from bit strings Faz-Hernandez, et al. Expires 17 December 2022 [Page 66] Internet-Draft hash-to-curve June 2022 to integers modulo r, the order of the elliptic curve group. Farashahi et al. [FFSTV13] improve the analysis of the first method, showing that it applies to essentially all deterministic mappings. Tibouchi and Kim [TK17] further refine the analysis and describe additional optimizations. Complementary to the problem of mapping from bit strings to elliptic curve points, Bernstein et al. [BHKL13] study the problem of mapping from elliptic curve points to uniformly random bit strings, giving solutions for a class of curves including Montgomery and twisted Edwards curves. Tibouchi [T14] and Aranha et al. [AFQTZ14] generalize these results. This document does not deal with this complementary problem. Appendix B. Hashing to ristretto255 ristretto255 [I-D.irtf-cfrg-ristretto255-decaf448] provides a prime- order group based on Curve25519 [RFC7748]. This section describes hash_to_ristretto255, which implements a random-oracle encoding to this group that has a uniform output distribution (Section 2.2.3) and the same security properties and interface as the hash_to_curve function (Section 3). The ristretto255 API defines a one-way map ([I-D.irtf-cfrg-ristretto255-decaf448], Section 4.3.4); this section refers to that map as ristretto255_map. The hash_to_ristretto255 function MUST be instantiated with an expand_message function that conforms to the requirements given in Section 5.3. In addition, it MUST use a domain separation tag constructed as described in Section 3.1, and all domain separation recommendations given in Section 10.7 apply when implementing protocols that use hash_to_ristretto255. Faz-Hernandez, et al. Expires 17 December 2022 [Page 67] Internet-Draft hash-to-curve June 2022 hash_to_ristretto255(msg) Parameters: - DST, a domain separation tag (see discussion above). - expand_message, a function that expands a byte string and domain separation tag into a uniformly random byte string (see discussion above). - ristretto255_map, the one-way map from the ristretto255 API. Input: msg, an arbitrary-length byte string. Output: P, an element of the ristretto255 group. Steps: 1. uniform_bytes = expand_message(msg, DST, 64) 2. P = ristretto255_map(uniform_bytes) 3. return P Since hash_to_ristretto255 is not a hash-to-curve suite, it does not have a Suite ID. If a similar identifier is needed, it MUST be constructed following the guidelines in Section 8.10, with the following parameters: * CURVE_ID: "ristretto255" * HASH_ID: as described in Section 8.10 * MAP_ID: "R255MAP" * ENC_VAR: "RO" For example, if expand_message is expand_message_xmd using SHA-512, the REQUIRED identifier is: ristretto255_XMD:SHA-512_R255MAP_RO_ Appendix C. Hashing to decaf448 Similar to ristretto255, decaf448 [I-D.irtf-cfrg-ristretto255-decaf448] provides a prime-order group based on Curve448 [RFC7748]. This section describes hash_to_decaf448, which implements a random-oracle encoding to this group that has a uniform output distribution (Section 2.2.3) and the same security properties and interface as the hash_to_curve function (Section 3). The decaf448 API defines a one-way map ([I-D.irtf-cfrg-ristretto255-decaf448], Section 5.3.4); this section refers to that map as decaf448_map. Faz-Hernandez, et al. Expires 17 December 2022 [Page 68] Internet-Draft hash-to-curve June 2022 The hash_to_decaf448 function MUST be instantiated with an expand_message function that conforms to the requirements given in Section 5.3. In addition, it MUST use a domain separation tag constructed as described in Section 3.1, and all domain separation recommendations given in Section 10.7 apply when implementing protocols that use hash_to_decaf448. hash_to_decaf448(msg) Parameters: - DST, a domain separation tag (see discussion above). - expand_message, a function that expands a byte string and domain separation tag into a uniformly random byte string (see discussion above). - decaf448_map, the one-way map from the decaf448 API. Input: msg, an arbitrary-length byte string. Output: P, an element of the decaf448 group. Steps: 1. uniform_bytes = expand_message(msg, DST, 112) 2. P = decaf448_map(uniform_bytes) 3. return P Since hash_to_decaf448 is not a hash-to-curve suite, it does not have a Suite ID. If a similar identifier is needed, it MUST be constructed following the guidelines in Section 8.10, with the following parameters: * CURVE_ID: "decaf448" * HASH_ID: as described in Section 8.10 * MAP_ID: "D448MAP" * ENC_VAR: "RO" For example, if expand_message is expand_message_xof using SHAKE256, the REQUIRED identifier is: decaf448_XOF:SHAKE256_D448MAP_RO_ Appendix D. Rational maps This section gives rational maps that can be used when hashing to twisted Edwards or Montgomery curves. Faz-Hernandez, et al. Expires 17 December 2022 [Page 69] Internet-Draft hash-to-curve June 2022 Given a twisted Edwards curve, Appendix D.1 shows how to derive a corresponding Montgomery curve and how to map from that curve to the twisted Edwards curve. This mapping may be used when hashing to twisted Edwards curves as described in Section 6.8. Given a Montgomery curve, Appendix D.2 shows how to derive a corresponding Weierstrass curve and how to map from that curve to the Montgomery curve. This mapping can be used to hash to Montgomery or twisted Edwards curves via the Shallue-van de Woestijne (Section 6.6.1) or Simplified SWU (Section 6.6.2) method, as follows: * For Montgomery curves, first map to the Weierstrass curve, then convert to Montgomery coordinates via the mapping. * For twisted Edwards curves, compose the Weierstrass to Montgomery mapping with the Montgomery to twisted Edwards mapping (Appendix D.1) to obtain a Weierstrass curve and a mapping to the target twisted Edwards curve. Map to this Weierstrass curve, then convert to Edwards coordinates via the mapping. D.1. Generic Montgomery to twisted Edwards map This section gives a generic birational map between twisted Edwards and Montgomery curves. The map in this section is a simplified version of the map given in [BBJLP08], Theorem 3.2. Specifically, this section's map handles exceptional cases in a simplified way that is geared towards hashing to a twisted Edwards curve's prime-order subgroup. The twisted Edwards curve a * v^2 + w^2 = 1 + d * v^2 * w^2 is birationally equivalent to the Montgomery curve K * t^2 = s^3 + J * s^2 + s which has the form required by the Elligator 2 mapping of Section 6.7.1. The coefficients of the Montgomery curve are * J = 2 * (a + d) / (a - d) * K = 4 / (a - d) The rational map from the point (s, t) on the above Montgomery curve to the point (v, w) on the twisted Edwards curve is given by Faz-Hernandez, et al. Expires 17 December 2022 [Page 70] Internet-Draft hash-to-curve June 2022 * v = s / t * w = (s - 1) / (s + 1) This mapping is undefined when t == 0 or s == -1, i.e., when the denominator of either of the above rational functions is zero. Implementations MUST detect exceptional cases and return the value (v, w) = (0, 1), which is the identity point on all twisted Edwards curves. The following straight-line implementation of the above rational map handles the exceptional cases. monty_to_edw_generic(s, t) Input: (s, t), a point on the curve K * t^2 = s^3 + J * s^2 + s. Output: (v, w), a point on an equivalent twisted Edwards curve. 1. tv1 = s + 1 2. tv2 = tv1 * t # (s + 1) * t 3. tv2 = inv0(tv2) # 1 / ((s + 1) * t) 4. v = tv2 * tv1 # 1 / t 5. v = v * s # s / t 6. w = tv2 * t # 1 / (s + 1) 7. tv1 = s - 1 8. w = w * tv1 # (s - 1) / (s + 1) 9. e = tv2 == 0 10. w = CMOV(w, 1, e) # handle exceptional case 11. return (v, w) For completeness, we also give the inverse relations. (Note that this map is not required when hashing to twisted Edwards curves.) The coefficients of the twisted Edwards curve corresponding to the above Montgomery curve are * a = (J + 2) / K * d = (J - 2) / K The rational map from the point (v, w) on the twisted Edwards curve to the point (s, t) on the Montgomery curve is given by * s = (1 + w) / (1 - w) * t = (1 + w) / (v * (1 - w)) Faz-Hernandez, et al. Expires 17 December 2022 [Page 71] Internet-Draft hash-to-curve June 2022 The mapping is undefined when v == 0 or w == 1. When the goal is to map into the prime-order subgroup of the Montgomery curve, it suffices to return the identity point on the Montgomery curve in the exceptional cases. D.2. Weierstrass to Montgomery map The rational map from the point (s, t) on the Montgomery curve K * t^2 = s^3 + J * s^2 + s to the point (x, y) on the equivalent Weierstrass curve y^2 = x^3 + A * x + B is given by: * A = (3 - J^2) / (3 * K^2) * B = (2 * J^3 - 9 * J) / (27 * K^3) * x = (3 * s + J) / (3 * K) * y = t / K The inverse map, from the point (x, y) to the point (s, t), is given by * s = (3 * K * x - J) / 3 * t = y * K This mapping can be used to apply the Shallue-van de Woestijne (Section 6.6.1) or Simplified SWU (Section 6.6.2) method to Montgomery curves. Appendix E. Isogeny maps for suites This section specifies the isogeny maps for the secp256k1 and BLS12-381 suites listed in Section 8. These maps are given in terms of affine coordinates. Wahby and Boneh ([WB19], Section 4.3) show how to evaluate these maps in a projective coordinate system (Appendix G.1), which avoids modular inversions. Refer to the draft repository [hash2curve-repo] for a Sage [SAGE] script that constructs these isogenies. Faz-Hernandez, et al. Expires 17 December 2022 [Page 72] Internet-Draft hash-to-curve June 2022 E.1. 3-isogeny map for secp256k1 This section specifies the isogeny map for the secp256k1 suite listed in Section 8.7. The 3-isogeny map from (x', y') on E' to (x, y) on E is given by the following rational functions: * x = x_num / x_den, where - x_num = k_(1,3) * x'^3 + k_(1,2) * x'^2 + k_(1,1) * x' + k_(1,0) - x_den = x'^2 + k_(2,1) * x' + k_(2,0) * y = y' * y_num / y_den, where - y_num = k_(3,3) * x'^3 + k_(3,2) * x'^2 + k_(3,1) * x' + k_(3,0) - y_den = x'^3 + k_(4,2) * x'^2 + k_(4,1) * x' + k_(4,0) The constants used to compute x_num are as follows: * k_(1,0) = 0x8e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38daaaaa8c7 * k_(1,1) = 0x7d3d4c80bc321d5b9f315cea7fd44c5d595d2fc0bf63b92dfff1044f17c6581 * k_(1,2) = 0x534c328d23f234e6e2a413deca25caece4506144037c40314ecbd0b53d9dd262 * k_(1,3) = 0x8e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38daaaaa88c The constants used to compute x_den are as follows: * k_(2,0) = 0xd35771193d94918a9ca34ccbb7b640dd86cd409542f8487d9fe6b745781eb49b * k_(2,1) = 0xedadc6f64383dc1df7c4b2d51b54225406d36b641f5e41bbc52a56612a8c6d14 The constants used to compute y_num are as follows: * k_(3,0) = 0x4bda12f684bda12f684bda12f684bda12f684bda12f684bda12f684b8e38e23c Faz-Hernandez, et al. Expires 17 December 2022 [Page 73] Internet-Draft hash-to-curve June 2022 * k_(3,1) = 0xc75e0c32d5cb7c0fa9d0a54b12a0a6d5647ab046d686da6fdffc90fc201d71a3 * k_(3,2) = 0x29a6194691f91a73715209ef6512e576722830a201be2018a765e85a9ecee931 * k_(3,3) = 0x2f684bda12f684bda12f684bda12f684bda12f684bda12f684bda12f38e38d84 The constants used to compute y_den are as follows: * k_(4,0) = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffff93b * k_(4,1) = 0x7a06534bb8bdb49fd5e9e6632722c2989467c1bfc8e8d978dfb425d2685c2573 * k_(4,2) = 0x6484aa716545ca2cf3a70c3fa8fe337e0a3d21162f0d6299a7bf8192bfd2a76f E.2. 11-isogeny map for BLS12-381 G1 The 11-isogeny map from (x', y') on E' to (x, y) on E is given by the following rational functions: * x = x_num / x_den, where - x_num = k_(1,11) * x'^11 + k_(1,10) * x'^10 + k_(1,9) * x'^9 + ... + k_(1,0) - x_den = x'^10 + k_(2,9) * x'^9 + k_(2,8) * x'^8 + ... + k_(2,0) * y = y' * y_num / y_den, where - y_num = k_(3,15) * x'^15 + k_(3,14) * x'^14 + k_(3,13) * x'^13 + ... + k_(3,0) - y_den = x'^15 + k_(4,14) * x'^14 + k_(4,13) * x'^13 + ... + k_(4,0) The constants used to compute x_num are as follows: * k_(1,0) = 0x11a05f2b1e833340b809101dd99815856b303e88a2d7005ff2627b 56cdb4e2c85610c2d5f2e62d6eaeac1662734649b7 * k_(1,1) = 0x17294ed3e943ab2f0588bab22147a81c7c17e75b2f6a8417f565e3 3c70d1e86b4838f2a6f318c356e834eef1b3cb83bb Faz-Hernandez, et al. Expires 17 December 2022 [Page 74] Internet-Draft hash-to-curve June 2022 * k_(1,2) = 0xd54005db97678ec1d1048c5d10a9a1bce032473295983e56878e50 1ec68e25c958c3e3d2a09729fe0179f9dac9edcb0 * k_(1,3) = 0x1778e7166fcc6db74e0609d307e55412d7f5e4656a8dbf25f1b332 89f1b330835336e25ce3107193c5b388641d9b6861 * k_(1,4) = 0xe99726a3199f4436642b4b3e4118e5499db995a1257fb3f086eeb6 5982fac18985a286f301e77c451154ce9ac8895d9 * k_(1,5) = 0x1630c3250d7313ff01d1201bf7a74ab5db3cb17dd952799b9ed3ab 9097e68f90a0870d2dcae73d19cd13c1c66f652983 * k_(1,6) = 0xd6ed6553fe44d296a3726c38ae652bfb11586264f0f8ce19008e21 8f9c86b2a8da25128c1052ecaddd7f225a139ed84 * k_(1,7) = 0x17b81e7701abdbe2e8743884d1117e53356de5ab275b4db1a682c6 2ef0f2753339b7c8f8c8f475af9ccb5618e3f0c88e * k_(1,8) = 0x80d3cf1f9a78fc47b90b33563be990dc43b756ce79f5574a2c596c 928c5d1de4fa295f296b74e956d71986a8497e317 * k_(1,9) = 0x169b1f8e1bcfa7c42e0c37515d138f22dd2ecb803a0c5c99676314 baf4bb1b7fa3190b2edc0327797f241067be390c9e * k_(1,10) = 0x10321da079ce07e272d8ec09d2565b0dfa7dccdde6787f96d50af 36003b14866f69b771f8c285decca67df3f1605fb7b * k_(1,11) = 0x6e08c248e260e70bd1e962381edee3d31d79d7e22c837bc23c0bf 1bc24c6b68c24b1b80b64d391fa9c8ba2e8ba2d229 The constants used to compute x_den are as follows: * k_(2,0) = 0x8ca8d548cff19ae18b2e62f4bd3fa6f01d5ef4ba35b48ba9c95886 17fc8ac62b558d681be343df8993cf9fa40d21b1c * k_(2,1) = 0x12561a5deb559c4348b4711298e536367041e8ca0cf0800c0126c2 588c48bf5713daa8846cb026e9e5c8276ec82b3bff * k_(2,2) = 0xb2962fe57a3225e8137e629bff2991f6f89416f5a718cd1fca64e0 0b11aceacd6a3d0967c94fedcfcc239ba5cb83e19 * k_(2,3) = 0x3425581a58ae2fec83aafef7c40eb545b08243f16b1655154cca8a bc28d6fd04976d5243eecf5c4130de8938dc62cd8 * k_(2,4) = 0x13a8e162022914a80a6f1d5f43e7a07dffdfc759a12062bb8d6b44 e833b306da9bd29ba81f35781d539d395b3532a21e Faz-Hernandez, et al. Expires 17 December 2022 [Page 75] Internet-Draft hash-to-curve June 2022 * k_(2,5) = 0xe7355f8e4e667b955390f7f0506c6e9395735e9ce9cad4d0a43bce f24b8982f7400d24bc4228f11c02df9a29f6304a5 * k_(2,6) = 0x772caacf16936190f3e0c63e0596721570f5799af53a1894e2e073 062aede9cea73b3538f0de06cec2574496ee84a3a * k_(2,7) = 0x14a7ac2a9d64a8b230b3f5b074cf01996e7f63c21bca68a81996e1 cdf9822c580fa5b9489d11e2d311f7d99bbdcc5a5e * k_(2,8) = 0xa10ecf6ada54f825e920b3dafc7a3cce07f8d1d7161366b74100da 67f39883503826692abba43704776ec3a79a1d641 * k_(2,9) = 0x95fc13ab9e92ad4476d6e3eb3a56680f682b4ee96f7d03776df533 978f31c1593174e4b4b7865002d6384d168ecdd0a The constants used to compute y_num are as follows: * k_(3,0) = 0x90d97c81ba24ee0259d1f094980dcfa11ad138e48a869522b52af6 c956543d3cd0c7aee9b3ba3c2be9845719707bb33 * k_(3,1) = 0x134996a104ee5811d51036d776fb46831223e96c254f383d0f9063 43eb67ad34d6c56711962fa8bfe097e75a2e41c696 * k_(3,2) = 0xcc786baa966e66f4a384c86a3b49942552e2d658a31ce2c344be4b 91400da7d26d521628b00523b8dfe240c72de1f6 * k_(3,3) = 0x1f86376e8981c217898751ad8746757d42aa7b90eeb791c09e4a3e c03251cf9de405aba9ec61deca6355c77b0e5f4cb * k_(3,4) = 0x8cc03fdefe0ff135caf4fe2a21529c4195536fbe3ce50b879833fd 221351adc2ee7f8dc099040a841b6daecf2e8fedb * k_(3,5) = 0x16603fca40634b6a2211e11db8f0a6a074a7d0d4afadb7bd76505c 3d3ad5544e203f6326c95a807299b23ab13633a5f0 * k_(3,6) = 0x4ab0b9bcfac1bbcb2c977d027796b3ce75bb8ca2be184cb5231413 c4d634f3747a87ac2460f415ec961f8855fe9d6f2 * k_(3,7) = 0x987c8d5333ab86fde9926bd2ca6c674170a05bfe3bdd81ffd038da 6c26c842642f64550fedfe935a15e4ca31870fb29 * k_(3,8) = 0x9fc4018bd96684be88c9e221e4da1bb8f3abd16679dc26c1e8b6e6 a1f20cabe69d65201c78607a360370e577bdba587 * k_(3,9) = 0xe1bba7a1186bdb5223abde7ada14a23c42a0ca7915af6fe06985e7 ed1e4d43b9b3f7055dd4eba6f2bafaaebca731c30 Faz-Hernandez, et al. Expires 17 December 2022 [Page 76] Internet-Draft hash-to-curve June 2022 * k_(3,10) = 0x19713e47937cd1be0dfd0b8f1d43fb93cd2fcbcb6caf493fd1183 e416389e61031bf3a5cce3fbafce813711ad011c132 * k_(3,11) = 0x18b46a908f36f6deb918c143fed2edcc523559b8aaf0c2462e6bf e7f911f643249d9cdf41b44d606ce07c8a4d0074d8e * k_(3,12) = 0xb182cac101b9399d155096004f53f447aa7b12a3426b08ec02710 e807b4633f06c851c1919211f20d4c04f00b971ef8 * k_(3,13) = 0x245a394ad1eca9b72fc00ae7be315dc757b3b080d4c158013e663 2d3c40659cc6cf90ad1c232a6442d9d3f5db980133 * k_(3,14) = 0x5c129645e44cf1102a159f748c4a3fc5e673d81d7e86568d9ab0f 5d396a7ce46ba1049b6579afb7866b1e715475224b * k_(3,15) = 0x15e6be4e990f03ce4ea50b3b42df2eb5cb181d8f84965a3957add 4fa95af01b2b665027efec01c7704b456be69c8b604 The constants used to compute y_den are as follows: * k_(4,0) = 0x16112c4c3a9c98b252181140fad0eae9601a6de578980be6eec323 2b5be72e7a07f3688ef60c206d01479253b03663c1 * k_(4,1) = 0x1962d75c2381201e1a0cbd6c43c348b885c84ff731c4d59ca4a103 56f453e01f78a4260763529e3532f6102c2e49a03d * k_(4,2) = 0x58df3306640da276faaae7d6e8eb15778c4855551ae7f310c35a5d d279cd2eca6757cd636f96f891e2538b53dbf67f2 * k_(4,3) = 0x16b7d288798e5395f20d23bf89edb4d1d115c5dbddbcd30e123da4 89e726af41727364f2c28297ada8d26d98445f5416 * k_(4,4) = 0xbe0e079545f43e4b00cc912f8228ddcc6d19c9f0f69bbb0542eda0 fc9dec916a20b15dc0fd2ededda39142311a5001d * k_(4,5) = 0x8d9e5297186db2d9fb266eaac783182b70152c65550d881c5ecd87 b6f0f5a6449f38db9dfa9cce202c6477faaf9b7ac * k_(4,6) = 0x166007c08a99db2fc3ba8734ace9824b5eecfdfa8d0cf8ef5dd365 bc400a0051d5fa9c01a58b1fb93d1a1399126a775c * k_(4,7) = 0x16a3ef08be3ea7ea03bcddfabba6ff6ee5a4375efa1f4fd7feb34f d206357132b920f5b00801dee460ee415a15812ed9 * k_(4,8) = 0x1866c8ed336c61231a1be54fd1d74cc4f9fb0ce4c6af5920abc575 0c4bf39b4852cfe2f7bb9248836b233d9d55535d4a Faz-Hernandez, et al. Expires 17 December 2022 [Page 77] Internet-Draft hash-to-curve June 2022 * k_(4,9) = 0x167a55cda70a6e1cea820597d94a84903216f763e13d87bb530859 2e7ea7d4fbc7385ea3d529b35e346ef48bb8913f55 * k_(4,10) = 0x4d2f259eea405bd48f010a01ad2911d9c6dd039bb61a6290e591b 36e636a5c871a5c29f4f83060400f8b49cba8f6aa8 * k_(4,11) = 0xaccbb67481d033ff5852c1e48c50c477f94ff8aefce42d28c0f9a 88cea7913516f968986f7ebbea9684b529e2561092 * k_(4,12) = 0xad6b9514c767fe3c3613144b45f1496543346d98adf02267d5cee f9a00d9b8693000763e3b90ac11e99b138573345cc * k_(4,13) = 0x2660400eb2e4f3b628bdd0d53cd76f2bf565b94e72927c1cb748d f27942480e420517bd8714cc80d1fadc1326ed06f7 * k_(4,14) = 0xe0fa1d816ddc03e6b24255e0d7819c171c40f65e273b853324efc d6356caa205ca2f570f13497804415473a1d634b8f E.3. 3-isogeny map for BLS12-381 G2 The 3-isogeny map from (x', y') on E' to (x, y) on E is given by the following rational functions: * x = x_num / x_den, where - x_num = k_(1,3) * x'^3 + k_(1,2) * x'^2 + k_(1,1) * x' + k_(1,0) - x_den = x'^2 + k_(2,1) * x' + k_(2,0) * y = y' * y_num / y_den, where - y_num = k_(3,3) * x'^3 + k_(3,2) * x'^2 + k_(3,1) * x' + k_(3,0) - y_den = x'^3 + k_(4,2) * x'^2 + k_(4,1) * x' + k_(4,0) The constants used to compute x_num are as follows: * k_(1,0) = 0x5c759507e8e333ebb5b7a9a47d7ed8532c52d39fd3a042a88b5842 3c50ae15d5c2638e343d9c71c6238aaaaaaaa97d6 + 0x5c759507e8e333ebb5b7 a9a47d7ed8532c52d39fd3a042a88b58423c50ae15d5c2638e343d9c71c6238aaa aaaaa97d6 * I * k_(1,1) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c 6b4f20a4181472aaa9cb8d555526a9ffffffffc71a * I Faz-Hernandez, et al. Expires 17 December 2022 [Page 78] Internet-Draft hash-to-curve June 2022 * k_(1,2) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c 6b4f20a4181472aaa9cb8d555526a9ffffffffc71e + 0x8ab05f8bdd54cde1909 37e76bc3e447cc27c3d6fbd7063fcd104635a790520c0a395554e5c6aaaa9354ff ffffffe38d * I * k_(1,3) = 0x171d6541fa38ccfaed6dea691f5fb614cb14b4e7f4e810aa22d610 8f142b85757098e38d0f671c7188e2aaaaaaaa5ed1 The constants used to compute x_den are as follows: * k_(2,0) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2 a0f6b0f6241eabfffeb153ffffb9feffffffffaa63 * I * k_(2,1) = 0xc + 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf 6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaa9f * I The constants used to compute y_num are as follows: * k_(3,0) = 0x1530477c7ab4113b59a4c18b076d11930f7da5d4a07f649bf54439 d87d27e500fc8c25ebf8c92f6812cfc71c71c6d706 + 0x1530477c7ab4113b59a 4c18b076d11930f7da5d4a07f649bf54439d87d27e500fc8c25ebf8c92f6812cfc 71c71c6d706 * I * k_(3,1) = 0x5c759507e8e333ebb5b7a9a47d7ed8532c52d39fd3a042a88b5842 3c50ae15d5c2638e343d9c71c6238aaaaaaaa97be * I * k_(3,2) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c 6b4f20a4181472aaa9cb8d555526a9ffffffffc71c + 0x8ab05f8bdd54cde1909 37e76bc3e447cc27c3d6fbd7063fcd104635a790520c0a395554e5c6aaaa9354ff ffffffe38f * I * k_(3,3) = 0x124c9ad43b6cf79bfbf7043de3811ad0761b0f37a1e26286b0e977 c69aa274524e79097a56dc4bd9e1b371c71c718b10 The constants used to compute y_den are as follows: * k_(4,0) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2 a0f6b0f6241eabfffeb153ffffb9feffffffffa8fb + 0x1a0111ea397fe69a4b1 ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9fef fffffffa8fb * I * k_(4,1) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2 a0f6b0f6241eabfffeb153ffffb9feffffffffa9d3 * I * k_(4,2) = 0x12 + 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512b f6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaa99 * I Faz-Hernandez, et al. Expires 17 December 2022 [Page 79] Internet-Draft hash-to-curve June 2022 Appendix F. Straight-line implementations of deterministic mappings This section gives straight-line implementations of the mappings of Section 6. These implementations are generic, i.e., they are defined for any curve and field. Appendix G gives further implementations that are optimized for specific classes of curves and fields. F.1. Shallue-van de Woestijne method This section gives a straight-line implementation of the Shallue and van de Woestijne method for any Weierstrass curve of the form given in Section 6.6. See Section 6.6.1 for information on the constants used in this mapping. Note that the constant c3 below MUST be chosen such that sgn0(c3) = 0. In other words, if the square-root computation returns a value cx such that sgn0(cx) = 1, set c3 = -cx; otherwise, set c3 = cx. map_to_curve_svdw(u) Input: u, an element of F. Output: (x, y), a point on E. Constants: 1. c1 = g(Z) 2. c2 = -Z / 2 3. c3 = sqrt(-g(Z) * (3 * Z^2 + 4 * A)) # sgn0(c3) MUST equal 0 4. c4 = -4 * g(Z) / (3 * Z^2 + 4 * A) Steps: 1. tv1 = u^2 2. tv1 = tv1 * c1 3. tv2 = 1 + tv1 4. tv1 = 1 - tv1 5. tv3 = tv1 * tv2 6. tv3 = inv0(tv3) 7. tv4 = u * tv1 8. tv4 = tv4 * tv3 9. tv4 = tv4 * c3 10. x1 = c2 - tv4 11. gx1 = x1^2 12. gx1 = gx1 + A 13. gx1 = gx1 * x1 14. gx1 = gx1 + B 15. e1 = is_square(gx1) 16. x2 = c2 + tv4 17. gx2 = x2^2 18. gx2 = gx2 + A Faz-Hernandez, et al. Expires 17 December 2022 [Page 80] Internet-Draft hash-to-curve June 2022 19. gx2 = gx2 * x2 20. gx2 = gx2 + B 21. e2 = is_square(gx2) AND NOT e1 # Avoid short-circuit logic ops 22. x3 = tv2^2 23. x3 = x3 * tv3 24. x3 = x3^2 25. x3 = x3 * c4 26. x3 = x3 + Z 27. x = CMOV(x3, x1, e1) # x = x1 if gx1 is square, else x = x3 28. x = CMOV(x, x2, e2) # x = x2 if gx2 is square and gx1 is not 29. gx = x^2 30. gx = gx + A 31. gx = gx * x 32. gx = gx + B 33. y = sqrt(gx) 34. e3 = sgn0(u) == sgn0(y) 35. y = CMOV(-y, y, e3) # Select correct sign of y 36. return (x, y) F.2. Simplified SWU method This section gives a straight-line implementation of the simplified SWU method for any Weierstrass curve of the form given in Section 6.6. See Section 6.6.2 for information on the constants used in this mapping. This optimized, straight-line procedure applies to any base field. The sqrt_ratio subroutine is defined in Appendix F.2.1. Faz-Hernandez, et al. Expires 17 December 2022 [Page 81] Internet-Draft hash-to-curve June 2022 map_to_curve_simple_swu(u) Input: u, an element of F. Output: (x, y), a point on E. Steps: 1. tv1 = u^2 2. tv1 = Z * tv1 3. tv2 = tv1^2 4. tv2 = tv2 + tv1 5. tv3 = tv2 + 1 6. tv3 = B * tv3 7. tv4 = CMOV(Z, -tv2, tv2 != 0) 8. tv4 = A * tv4 9. tv2 = tv3^2 10. tv6 = tv4^2 11. tv5 = A * tv6 12. tv2 = tv2 + tv5 13. tv2 = tv2 * tv3 14. tv6 = tv6 * tv4 15. tv5 = B * tv6 16. tv2 = tv2 + tv5 17. x = tv1 * tv3 18. (is_gx1_square, y1) = sqrt_ratio(tv2, tv6) 19. y = tv1 * u 20. y = y * y1 21. x = CMOV(x, tv3, is_gx1_square) 22. y = CMOV(y, y1, is_gx1_square) 23. e1 = sgn0(u) == sgn0(y) 24. y = CMOV(-y, y, e1) 25. x = x / tv4 26. return (x, y) F.2.1. sqrt_ratio subroutines This section defines three variants of the sqrt_ratio subroutine used by the above procedure. The first variant can be used with any field; the others are optimized versions for specific fields. The routines given in this section depend on the constant Z from the simplified SWU map. For correctness, sqrt_ratio and map_to_curve_simple_swu MUST use the same value for Z. F.2.1.1. sqrt_ratio for any field Faz-Hernandez, et al. Expires 17 December 2022 [Page 82] Internet-Draft hash-to-curve June 2022 sqrt_ratio(u, v) Parameters: - F, a finite field of characteristic p and order q = p^m. - Z, the constant from the simplified SWU map. Input: u and v, elements of F, where v != 0. Output: (b, y), where b = True and y = sqrt(u / v) if (u / v) is square in F, and b = False and y = sqrt(Z * (u / v)) otherwise. Constants: 1. c1, the largest integer such that 2^c1 divides q - 1. 2. c2 = (q - 1) / (2^c1) # Integer arithmetic 3. c3 = (c2 - 1) / 2 # Integer arithmetic 4. c4 = 2^c1 - 1 # Integer arithmetic 5. c5 = 2^(c1 - 1) # Integer arithmetic 6. c6 = Z^c2 7. c7 = Z^((c2 + 1) / 2) Procedure: 1. tv1 = c6 2. tv2 = v^c4 3. tv3 = tv2^2 4. tv3 = tv3 * v 5. tv5 = u * tv3 6. tv5 = tv5^c3 7. tv5 = tv5 * tv2 8. tv2 = tv5 * v 9. tv3 = tv5 * u 10. tv4 = tv3 * tv2 11. tv5 = tv4^c5 12. isQR = tv5 == 1 13. tv2 = tv3 * c7 14. tv5 = tv4 * tv1 15. tv3 = CMOV(tv2, tv3, isQR) 16. tv4 = CMOV(tv5, tv4, isQR) 17. for i in (c1, c1 - 1, ..., 2): 18. tv5 = i - 2 19. tv5 = 2^tv5 20. tv5 = tv4^tv5 21. e1 = tv5 == 1 22. tv2 = tv3 * tv1 23. tv1 = tv1 * tv1 24. tv5 = tv4 * tv1 25. tv3 = CMOV(tv2, tv3, e1) 26. tv4 = CMOV(tv5, tv4, e1) 27. return (isQR, tv3) Faz-Hernandez, et al. Expires 17 December 2022 [Page 83] Internet-Draft hash-to-curve June 2022 F.2.1.2. optimized sqrt_ratio for q = 3 mod 4 sqrt_ratio_3mod4(u, v) Parameters: - F, a finite field of characteristic p and order q = p^m, where q = 3 mod 4. - Z, the constant from the simplified SWU map. Input: u and v, elements of F, where v != 0. Output: (b, y), where b = True and y = sqrt(u / v) if (u / v) is square in F, and b = False and y = sqrt(Z * (u / v)) otherwise. Constants: 1. c1 = (q - 3) / 4 # Integer arithmetic 2. c2 = sqrt(-Z) Procedure: 1. tv1 = v^2 2. tv2 = u * v 3. tv1 = tv1 * tv2 4. y1 = tv1^c1 5. y1 = y1 * tv2 6. y2 = y1 * c2 7. tv3 = y1^2 8. tv3 = tv3 * v 9. isQR = tv3 == u 10. y = CMOV(y2, y1, isQR) 11. return (isQR, y) F.2.1.3. optimized sqrt_ratio for q = 5 mod 8 Faz-Hernandez, et al. Expires 17 December 2022 [Page 84] Internet-Draft hash-to-curve June 2022 sqrt_ratio_5mod8(u, v) Parameters: - F, a finite field of characteristic p and order q = p^m, where q = 5 mod 8. - Z, the constant from the simplified SWU map. Input: u and v, elements of F, where v != 0. Output: (b, y), where b = True and y = sqrt(u / v) if (u / v) is square in F, and b = False and y = sqrt(Z * (u / v)) otherwise. Constants: 1. c1 = (q - 5) / 8 2. c2 = sqrt(-1) 3. c3 = sqrt(Z / c2) Steps: 1. tv1 = v^2 2. tv2 = tv1 * v 3. tv1 = tv1^2 4. tv2 = tv2 * u 5. tv1 = tv1 * tv2 6. y1 = tv1^c1 7. y1 = y1 * tv2 8. tv1 = y1 * c2 9. tv2 = tv1^2 10. tv2 = tv2 * v 11. e1 = tv2 == u 12. y1 = CMOV(y1, tv1, e1) 13. tv2 = y1^2 14. tv2 = tv2 * v 15. isQR = tv2 == u 16. y2 = y1 * c3 17. tv1 = y2 * c2 18. tv2 = tv1^2 19. tv2 = tv2 * v 20. tv3 = Z * u 21. e2 = tv2 == tv3 22. y2 = CMOV(y2, tv1, e2) 23. y = CMOV(y2, y1, isQR) 24. return (isQR, y) Faz-Hernandez, et al. Expires 17 December 2022 [Page 85] Internet-Draft hash-to-curve June 2022 F.3. Elligator 2 method This section gives a straight-line implementation of the Elligator 2 method for any Montgomery curve of the form given in Section 6.7. See Section 6.7.1 for information on the constants used in this mapping. Appendix G.2 gives optimized straight-line procedures that apply to specific classes of curves and base fields, including curve25519 and curve448 [RFC7748]. map_to_curve_elligator2(u) Input: u, an element of F. Output: (s, t), a point on M. Constants: 1. c1 = J / K 2. c2 = 1 / K^2 Steps: 1. tv1 = u^2 2. tv1 = Z * tv1 # Z * u^2 3. e1 = tv1 == -1 # exceptional case: Z * u^2 == -1 4. tv1 = CMOV(tv1, 0, e1) # if tv1 == -1, set tv1 = 0 5. x1 = tv1 + 1 6. x1 = inv0(x1) 7. x1 = -c1 * x1 # x1 = -(J / K) / (1 + Z * u^2) 8. gx1 = x1 + c1 9. gx1 = gx1 * x1 10. gx1 = gx1 + c2 11. gx1 = gx1 * x1 # gx1 = x1^3 + (J / K) * x1^2 + x1 / K^2 12. x2 = -x1 - c1 13. gx2 = tv1 * gx1 14. e2 = is_square(gx1) # If is_square(gx1) 15. x = CMOV(x2, x1, e2) # then x = x1, else x = x2 16. y2 = CMOV(gx2, gx1, e2) # then y2 = gx1, else y2 = gx2 17. y = sqrt(y2) 18. e3 = sgn0(y) == 1 19. y = CMOV(y, -y, e2 XOR e3) # fix sign of y 20. s = x * K 21. t = y * K 22. return (s, t) Faz-Hernandez, et al. Expires 17 December 2022 [Page 86] Internet-Draft hash-to-curve June 2022 Appendix G. Curve-specific optimized sample code This section gives sample implementations optimized for some of the elliptic curves listed in Section 8. Sample Sage [SAGE] code for each algorithm can also be found in the draft repository [hash2curve-repo]. G.1. Interface and projective coordinate systems The sample code in this section uses a different interface than the mappings of Section 6. Specifically, each mapping function in this section has the following signature: (xn, xd, yn, yd) = map_to_curve(u) The resulting affine point (x, y) is given by (xn / xd, yn / yd). The reason for this modified interface is that it enables further optimizations when working with points in a projective coordinate system. This is desirable, for example, when the resulting point will be immediately multiplied by a scalar, since most scalar multiplication algorithms operate on projective points. Projective coordinates are also useful when implementing random oracle encodings (Section 3). One reason is that, in general, point addition is faster using projective coordinates. Another reason is that, for Weierstrass curves, projective coordinates allow using complete addition formulas [RCB16]. This is especially convenient when implementing a constant-time encoding, because it eliminates the need for a special case when Q0 == Q1, which incomplete addition formulas usually do not handle. The following are two commonly used projective coordinate systems and the corresponding conversions: * A point (X, Y, Z) in homogeneous projective coordinates corresponds to the affine point (x, y) = (X / Z, Y / Z); the inverse conversion is given by (X, Y, Z) = (x, y, 1). To convert (xn, xd, yn, yd) to homogeneous projective coordinates, compute (X, Y, Z) = (xn * yd, yn * xd, xd * yd). * A point (X', Y', Z') in Jacobian projective coordinates corresponds to the affine point (x, y) = (X' / Z'^2, Y' / Z'^3); the inverse conversion is given by (X', Y', Z') = (x, y, 1). To convert (xn, xd, yn, yd) to Jacobian projective coordinates, compute (X', Y', Z') = (xn * xd * yd^2, yn * yd^2 * xd^3, xd * yd). Faz-Hernandez, et al. Expires 17 December 2022 [Page 87] Internet-Draft hash-to-curve June 2022 G.2. Elligator 2 G.2.1. curve25519 (q = 5 (mod 8), K = 1) The following is a straight-line implementation of Elligator 2 for curve25519 [RFC7748] as specified in Section 8.5. This implementation can also be used for any Montgomery curve with K = 1 over GF(q) where q = 5 (mod 8). map_to_curve_elligator2_curve25519(u) Input: u, an element of F. Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a point on curve25519. Constants: 1. c1 = (q + 3) / 8 # Integer arithmetic 2. c2 = 2^c1 3. c3 = sqrt(-1) 4. c4 = (q - 5) / 8 # Integer arithmetic Steps: 1. tv1 = u^2 2. tv1 = 2 * tv1 3. xd = tv1 + 1 # Nonzero: -1 is square (mod p), tv1 is not 4. x1n = -J # x1 = x1n / xd = -J / (1 + 2 * u^2) 5. tv2 = xd^2 6. gxd = tv2 * xd # gxd = xd^3 7. gx1 = J * tv1 # x1n + J * xd 8. gx1 = gx1 * x1n # x1n^2 + J * x1n * xd 9. gx1 = gx1 + tv2 # x1n^2 + J * x1n * xd + xd^2 10. gx1 = gx1 * x1n # x1n^3 + J * x1n^2 * xd + x1n * xd^2 11. tv3 = gxd^2 12. tv2 = tv3^2 # gxd^4 13. tv3 = tv3 * gxd # gxd^3 14. tv3 = tv3 * gx1 # gx1 * gxd^3 15. tv2 = tv2 * tv3 # gx1 * gxd^7 16. y11 = tv2^c4 # (gx1 * gxd^7)^((p - 5) / 8) 17. y11 = y11 * tv3 # gx1 * gxd^3 * (gx1 * gxd^7)^((p - 5) / 8) 18. y12 = y11 * c3 19. tv2 = y11^2 20. tv2 = tv2 * gxd 21. e1 = tv2 == gx1 22. y1 = CMOV(y12, y11, e1) # If g(x1) is square, this is its sqrt 23. x2n = x1n * tv1 # x2 = x2n / xd = 2 * u^2 * x1n / xd 24. y21 = y11 * u 25. y21 = y21 * c2 Faz-Hernandez, et al. Expires 17 December 2022 [Page 88] Internet-Draft hash-to-curve June 2022 26. y22 = y21 * c3 27. gx2 = gx1 * tv1 # g(x2) = gx2 / gxd = 2 * u^2 * g(x1) 28. tv2 = y21^2 29. tv2 = tv2 * gxd 30. e2 = tv2 == gx2 31. y2 = CMOV(y22, y21, e2) # If g(x2) is square, this is its sqrt 32. tv2 = y1^2 33. tv2 = tv2 * gxd 34. e3 = tv2 == gx1 35. xn = CMOV(x2n, x1n, e3) # If e3, x = x1, else x = x2 36. y = CMOV(y2, y1, e3) # If e3, y = y1, else y = y2 37. e4 = sgn0(y) == 1 # Fix sign of y 38. y = CMOV(y, -y, e3 XOR e4) 39. return (xn, xd, y, 1) G.2.2. edwards25519 The following is a straight-line implementation of Elligator 2 for edwards25519 [RFC7748] as specified in Section 8.5. The subroutine map_to_curve_elligator2_curve25519 is defined in Appendix G.2.1. Note that the sign of the constant c1 below is chosen as specified in Section 6.8.1, i.e., applying the rational map to the edwards25519 base point yields the curve25519 base point (see erratum [EID4730]). map_to_curve_elligator2_edwards25519(u) Input: u, an element of F. Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a point on edwards25519. Constants: 1. c1 = sqrt(-486664) # sgn0(c1) MUST equal 0 Steps: 1. (xMn, xMd, yMn, yMd) = map_to_curve_elligator2_curve25519(u) 2. xn = xMn * yMd 3. xn = xn * c1 4. xd = xMd * yMn # xn / xd = c1 * xM / yM 5. yn = xMn - xMd 6. yd = xMn + xMd # (n / d - 1) / (n / d + 1) = (n - d) / (n + d) 7. tv1 = xd * yd 8. e = tv1 == 0 9. xn = CMOV(xn, 0, e) 10. xd = CMOV(xd, 1, e) 11. yn = CMOV(yn, 1, e) 12. yd = CMOV(yd, 1, e) 13. return (xn, xd, yn, yd) Faz-Hernandez, et al. Expires 17 December 2022 [Page 89] Internet-Draft hash-to-curve June 2022 G.2.3. curve448 (q = 3 (mod 4), K = 1) The following is a straight-line implementation of Elligator 2 for curve448 [RFC7748] as specified in Section 8.6. This implementation can also be used for any Montgomery curve with K = 1 over GF(q) where q = 3 (mod 4). map_to_curve_elligator2_curve448(u) Input: u, an element of F. Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a point on curve448. Constants: 1. c1 = (q - 3) / 4 # Integer arithmetic Steps: 1. tv1 = u^2 2. e1 = tv1 == 1 3. tv1 = CMOV(tv1, 0, e1) # If Z * u^2 == -1, set tv1 = 0 4. xd = 1 - tv1 5. x1n = -J 6. tv2 = xd^2 7. gxd = tv2 * xd # gxd = xd^3 8. gx1 = -J * tv1 # x1n + J * xd 9. gx1 = gx1 * x1n # x1n^2 + J * x1n * xd 10. gx1 = gx1 + tv2 # x1n^2 + J * x1n * xd + xd^2 11. gx1 = gx1 * x1n # x1n^3 + J * x1n^2 * xd + x1n * xd^2 12. tv3 = gxd^2 13. tv2 = gx1 * gxd # gx1 * gxd 14. tv3 = tv3 * tv2 # gx1 * gxd^3 15. y1 = tv3^c1 # (gx1 * gxd^3)^((p - 3) / 4) 16. y1 = y1 * tv2 # gx1 * gxd * (gx1 * gxd^3)^((p - 3) / 4) 17. x2n = -tv1 * x1n # x2 = x2n / xd = -1 * u^2 * x1n / xd 18. y2 = y1 * u 19. y2 = CMOV(y2, 0, e1) 20. tv2 = y1^2 21. tv2 = tv2 * gxd 22. e2 = tv2 == gx1 23. xn = CMOV(x2n, x1n, e2) # If e2, x = x1, else x = x2 24. y = CMOV(y2, y1, e2) # If e2, y = y1, else y = y2 25. e3 = sgn0(y) == 1 # Fix sign of y 26. y = CMOV(y, -y, e2 XOR e3) 27. return (xn, xd, y, 1) Faz-Hernandez, et al. Expires 17 December 2022 [Page 90] Internet-Draft hash-to-curve June 2022 G.2.4. edwards448 The following is a straight-line implementation of Elligator 2 for edwards448 [RFC7748] as specified in Section 8.6. The subroutine map_to_curve_elligator2_curve448 is defined in Appendix G.2.3. Faz-Hernandez, et al. Expires 17 December 2022 [Page 91] Internet-Draft hash-to-curve June 2022 map_to_curve_elligator2_edwards448(u) Input: u, an element of F. Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a point on edwards448. Steps: 1. (xn, xd, yn, yd) = map_to_curve_elligator2_curve448(u) 2. xn2 = xn^2 3. xd2 = xd^2 4. xd4 = xd2^2 5. yn2 = yn^2 6. yd2 = yd^2 7. xEn = xn2 - xd2 8. tv2 = xEn - xd2 9. xEn = xEn * xd2 10. xEn = xEn * yd 11. xEn = xEn * yn 12. xEn = xEn * 4 13. tv2 = tv2 * xn2 14. tv2 = tv2 * yd2 15. tv3 = 4 * yn2 16. tv1 = tv3 + yd2 17. tv1 = tv1 * xd4 18. xEd = tv1 + tv2 19. tv2 = tv2 * xn 20. tv4 = xn * xd4 21. yEn = tv3 - yd2 22. yEn = yEn * tv4 23. yEn = yEn - tv2 24. tv1 = xn2 + xd2 25. tv1 = tv1 * xd2 26. tv1 = tv1 * xd 27. tv1 = tv1 * yn2 28. tv1 = -2 * tv1 29. yEd = tv2 + tv1 30. tv4 = tv4 * yd2 31. yEd = yEd + tv4 32. tv1 = xEd * yEd 33. e = tv1 == 0 34. xEn = CMOV(xEn, 0, e) 35. xEd = CMOV(xEd, 1, e) 36. yEn = CMOV(yEn, 1, e) 37. yEd = CMOV(yEd, 1, e) 38. return (xEn, xEd, yEn, yEd) Faz-Hernandez, et al. Expires 17 December 2022 [Page 92] Internet-Draft hash-to-curve June 2022 G.2.5. Montgomery curves with q = 3 (mod 4) The following is a straight-line implementation of Elligator 2 that applies to any Montgomery curve defined over GF(q) where q = 3 (mod 4). For curves where K = 1, the implementation given in Appendix G.2.3 gives identical results with slightly reduced cost. Faz-Hernandez, et al. Expires 17 December 2022 [Page 93] Internet-Draft hash-to-curve June 2022 map_to_curve_elligator2_3mod4(u) Input: u, an element of F. Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a point on the target curve. Constants: 1. c1 = (q - 3) / 4 # Integer arithmetic 2. c2 = K^2 Steps: 1. tv1 = u^2 2. e1 = tv1 == 1 3. tv1 = CMOV(tv1, 0, e1) # If Z * u^2 == -1, set tv1 = 0 4. xd = 1 - tv1 5. xd = xd * K 6. x1n = -J # x1 = x1n / xd = -J / (K * (1 + 2 * u^2)) 7. tv2 = xd^2 8. gxd = tv2 * xd 9. gxd = gxd * c2 # gxd = xd^3 * K^2 10. gx1 = x1n * K 11. tv3 = xd * J 12. tv3 = gx1 + tv3 # x1n * K + xd * J 13. gx1 = gx1 * tv3 # K^2 * x1n^2 + J * K * x1n * xd 14. gx1 = gx1 + tv2 # K^2 * x1n^2 + J * K * x1n * xd + xd^2 15. gx1 = gx1 * x1n # K^2 * x1n^3 + J * K * x1n^2 * xd + x1n * xd^2 16. tv3 = gxd^2 17. tv2 = gx1 * gxd # gx1 * gxd 18. tv3 = tv3 * tv2 # gx1 * gxd^3 19. y1 = tv3^c1 # (gx1 * gxd^3)^((q - 3) / 4) 20. y1 = y1 * tv2 # gx1 * gxd * (gx1 * gxd^3)^((q - 3) / 4) 21. x2n = -tv1 * x1n # x2 = x2n / xd = -1 * u^2 * x1n / xd 22. y2 = y1 * u 23. y2 = CMOV(y2, 0, e1) 24. tv2 = y1^2 25. tv2 = tv2 * gxd 26. e2 = tv2 == gx1 27. xn = CMOV(x2n, x1n, e2) # If e2, x = x1, else x = x2 28. xn = xn * K 29. y = CMOV(y2, y1, e2) # If e2, y = y1, else y = y2 30. e3 = sgn0(y) == 1 # Fix sign of y 31. y = CMOV(y, -y, e2 XOR e3) 32. y = y * K 33. return (xn, xd, y, 1) Faz-Hernandez, et al. Expires 17 December 2022 [Page 94] Internet-Draft hash-to-curve June 2022 G.2.6. Montgomery curves with q = 5 (mod 8) The following is a straight-line implementation of Elligator 2 that applies to any Montgomery curve defined over GF(q) where q = 5 (mod 8). For curves where K = 1, the implementation given in Appendix G.2.1 gives identical results with slightly reduced cost. map_to_curve_elligator2_5mod8(u) Input: u, an element of F. Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a point on the target curve. Constants: 1. c1 = (q + 3) / 8 # Integer arithmetic 2. c2 = 2^c1 3. c3 = sqrt(-1) 4. c4 = (q - 5) / 8 # Integer arithmetic 5. c5 = K^2 Steps: 1. tv1 = u^2 2. tv1 = 2 * tv1 3. xd = tv1 + 1 # Nonzero: -1 is square (mod p), tv1 is not 4. xd = xd * K 5. x1n = -J # x1 = x1n / xd = -J / (K * (1 + 2 * u^2)) 6. tv2 = xd^2 7. gxd = tv2 * xd 8. gxd = gxd * c5 # gxd = xd^3 * K^2 9. gx1 = x1n * K 10. tv3 = xd * J 11. tv3 = gx1 + tv3 # x1n * K + xd * J 12. gx1 = gx1 * tv3 # K^2 * x1n^2 + J * K * x1n * xd 13. gx1 = gx1 + tv2 # K^2 * x1n^2 + J * K * x1n * xd + xd^2 14. gx1 = gx1 * x1n # K^2 * x1n^3 + J * K * x1n^2 * xd + x1n * xd^2 15. tv3 = gxd^2 16. tv2 = tv3^2 # gxd^4 17. tv3 = tv3 * gxd # gxd^3 18. tv3 = tv3 * gx1 # gx1 * gxd^3 19. tv2 = tv2 * tv3 # gx1 * gxd^7 20. y11 = tv2^c4 # (gx1 * gxd^7)^((q - 5) / 8) 21. y11 = y11 * tv3 # gx1 * gxd^3 * (gx1 * gxd^7)^((q - 5) / 8) 22. y12 = y11 * c3 23. tv2 = y11^2 24. tv2 = tv2 * gxd 25. e1 = tv2 == gx1 Faz-Hernandez, et al. Expires 17 December 2022 [Page 95] Internet-Draft hash-to-curve June 2022 26. y1 = CMOV(y12, y11, e1) # If g(x1) is square, this is its sqrt 27. x2n = x1n * tv1 # x2 = x2n / xd = 2 * u^2 * x1n / xd 28. y21 = y11 * u 29. y21 = y21 * c2 30. y22 = y21 * c3 31. gx2 = gx1 * tv1 # g(x2) = gx2 / gxd = 2 * u^2 * g(x1) 32. tv2 = y21^2 33. tv2 = tv2 * gxd 34. e2 = tv2 == gx2 35. y2 = CMOV(y22, y21, e2) # If g(x2) is square, this is its sqrt 36. tv2 = y1^2 37. tv2 = tv2 * gxd 38. e3 = tv2 == gx1 39. xn = CMOV(x2n, x1n, e3) # If e3, x = x1, else x = x2 40. xn = xn * K 41. y = CMOV(y2, y1, e3) # If e3, y = y1, else y = y2 42. e4 = sgn0(y) == 1 # Fix sign of y 43. y = CMOV(y, -y, e3 XOR e4) 44. y = y * K 45. return (xn, xd, y, 1) G.3. Cofactor clearing for BLS12-381 G2 The curve BLS12-381, whose parameters are defined in Section 8.8.2, admits an efficiently-computable endomorphism psi that can be used to speed up cofactor clearing for G2 [SBCDK09] [FKR11] [BP17] (see also Section 7). This section implements the endomorphism psi and a fast cofactor clearing method described by Budroni and Pintore [BP17]. The functions in this section operate on points whose coordinates are represented as ratios, i.e., (xn, xd, yn, yd) corresponds to the point (xn / xd, yn / yd); see Appendix G.1 for further discussion of projective coordinates. When points are represented in affine coordinates, one can simply ignore the denominators (xd == 1 and yd == 1). The following function computes the Frobenius endomorphism for an element of F = GF(p^2) with basis (1, I), where I^2 + 1 == 0 in F. (This is the base field of the elliptic curve E defined in Section 8.8.2.) Faz-Hernandez, et al. Expires 17 December 2022 [Page 96] Internet-Draft hash-to-curve June 2022 frobenius(x) Input: x, an element of GF(p^2). Output: a, an element of GF(p^2). Notation: x = x0 + I * x1, where x0 and x1 are elements of GF(p). Steps: 1. a = x0 - I * x1 2. return a The following function computes the endomorphism psi for points on the elliptic curve E defined in Section 8.8.2. psi(xn, xd, yn, yd) Input: P, a point (xn / xd, yn / yd) on the curve E (see above). Output: Q, a point on the same curve. Constants: 1. c1 = 1 / (1 + I)^((p - 1) / 3) # in GF(p^2) 2. c2 = 1 / (1 + I)^((p - 1) / 2) # in GF(p^2) Steps: 1. qxn = c1 * frobenius(xn) 2. qxd = frobenius(xd) 3. qyn = c2 * frobenius(yn) 4. qyd = frobenius(yd) 5. return (qxn, qxd, qyn, qyd) The following function efficiently computes psi(psi(P)). psi2(xn, xd, yn, yd) Input: P, a point (xn / xd, yn / yd) on the curve E (see above). Output: Q, a point on the same curve. Constants: 1. c1 = 1 / 2^((p - 1) / 3) # in GF(p^2) Steps: 1. qxn = c1 * xn 2. qyn = -yn 3. return (qxn, xd, qyn, yd) Faz-Hernandez, et al. Expires 17 December 2022 [Page 97] Internet-Draft hash-to-curve June 2022 The following function maps any point on the elliptic curve E (Section 8.8.2) into the prime-order subgroup G2. This function returns a point equal to h_eff * P, where h_eff is the parameter given in Section 8.8.2. clear_cofactor_bls12381_g2(P) Input: P, a point (xn / xd, yn / yd) on the curve E (see above). Output: Q, a point in the subgroup G2 of BLS12-381. Constants: 1. c1 = -15132376222941642752 # the BLS parameter for BLS12-381 # i.e., -0xd201000000010000 Notation: in this procedure, + and - represent elliptic curve point addition and subtraction, respectively, and * represents scalar multiplication. Steps: 1. t1 = c1 * P 2. t2 = psi(P) 3. t3 = 2 * P 4. t3 = psi2(t3) 5. t3 = t3 - t2 6. t2 = t1 + t2 7. t2 = c1 * t2 8. t3 = t3 + t2 9. t3 = t3 - t1 10. Q = t3 - P 11. return Q Appendix H. Scripts for parameter generation This section gives Sage [SAGE] scripts used to generate parameters for the mappings of Section 6. H.1. Finding Z for the Shallue-van de Woestijne map The below function outputs an appropriate Z for the Shallue and van de Woestijne map (Section 6.6.1). Faz-Hernandez, et al. Expires 17 December 2022 [Page 98] Internet-Draft hash-to-curve June 2022 # Arguments: # - F, a field object, e.g., F = GF(2^521 - 1) # - A and B, the coefficients of the curve y^2 = x^3 + A * x + B def find_z_svdw(F, A, B, init_ctr=1): g = lambda x: F(x)^3 + F(A) * F(x) + F(B) h = lambda Z: -(F(3) * Z^2 + F(4) * A) / (F(4) * g(Z)) # NOTE: if init_ctr=1 fails to find Z, try setting it to F.gen() ctr = init_ctr while True: for Z_cand in (F(ctr), F(-ctr)): # Criterion 1: # g(Z) != 0 in F. if g(Z_cand) == F(0): continue # Criterion 2: # -(3 * Z^2 + 4 * A) / (4 * g(Z)) != 0 in F. if h(Z_cand) == F(0): continue # Criterion 3: # -(3 * Z^2 + 4 * A) / (4 * g(Z)) is square in F. if not is_square(h(Z_cand)): continue # Criterion 4: # At least one of g(Z) and g(-Z / 2) is square in F. if is_square(g(Z_cand)) or is_square(g(-Z_cand / F(2))): return Z_cand ctr += 1 H.2. Finding Z for Simplified SWU The below function outputs an appropriate Z for the Simplified SWU map (Section 6.6.2). Faz-Hernandez, et al. Expires 17 December 2022 [Page 99] Internet-Draft hash-to-curve June 2022 # Arguments: # - F, a field object, e.g., F = GF(2^521 - 1) # - A and B, the coefficients of the curve y^2 = x^3 + A * x + B def find_z_sswu(F, A, B): R. = F[] # Polynomial ring over F g = xx^3 + F(A) * xx + F(B) # y^2 = g(x) = x^3 + A * x + B ctr = F.gen() while True: for Z_cand in (F(ctr), F(-ctr)): # Criterion 1: Z is non-square in F. if is_square(Z_cand): continue # Criterion 2: Z != -1 in F. if Z_cand == F(-1): continue # Criterion 3: g(x) - Z is irreducible over F. if not (g - Z_cand).is_irreducible(): continue # Criterion 4: g(B / (Z * A)) is square in F. if is_square(g(B / (Z_cand * A))): return Z_cand ctr += 1 H.3. Finding Z for Elligator 2 The below function outputs an appropriate Z for the Elligator 2 map (Section 6.7.1). # Argument: # - F, a field object, e.g., F = GF(2^255 - 19) def find_z_ell2(F): ctr = F.gen() while True: for Z_cand in (F(ctr), F(-ctr)): # Z must be a non-square in F. if is_square(Z_cand): continue return Z_cand ctr += 1 Appendix I. sqrt and is_square functions This section defines special-purpose sqrt functions for the three most common cases, q = 3 (mod 4), q = 5 (mod 8), and q = 9 (mod 16), plus a generic constant-time algorithm that works for any prime modulus. In addition, it gives an optimized is_square method for GF(p^2). Faz-Hernandez, et al. Expires 17 December 2022 [Page 100] Internet-Draft hash-to-curve June 2022 I.1. sqrt for q = 3 (mod 4) sqrt_3mod4(x) Parameters: - F, a finite field of characteristic p and order q = p^m. Input: x, an element of F. Output: z, an element of F such that (z^2) == x, if x is square in F. Constants: 1. c1 = (q + 1) / 4 # Integer arithmetic Procedure: 1. return x^c1 I.2. sqrt for q = 5 (mod 8) sqrt_5mod8(x) Parameters: - F, a finite field of characteristic p and order q = p^m. Input: x, an element of F. Output: z, an element of F such that (z^2) == x, if x is square in F. Constants: 1. c1 = sqrt(-1) in F, i.e., (c1^2) == -1 in F 2. c2 = (q + 3) / 8 # Integer arithmetic Procedure: 1. tv1 = x^c2 2. tv2 = tv1 * c1 3. e = (tv1^2) == x 4. z = CMOV(tv2, tv1, e) 5. return z I.3. sqrt for q = 9 (mod 16) Faz-Hernandez, et al. Expires 17 December 2022 [Page 101] Internet-Draft hash-to-curve June 2022 sqrt_9mod16(x) Parameters: - F, a finite field of characteristic p and order q = p^m. Input: x, an element of F. Output: z, an element of F such that (z^2) == x, if x is square in F. Constants: 1. c1 = sqrt(-1) in F, i.e., (c1^2) == -1 in F 2. c2 = sqrt(c1) in F, i.e., (c2^2) == c1 in F 3. c3 = sqrt(-c1) in F, i.e., (c3^2) == -c1 in F 4. c4 = (q + 7) / 16 # Integer arithmetic Procedure: 1. tv1 = x^c4 2. tv2 = c1 * tv1 3. tv3 = c2 * tv1 4. tv4 = c3 * tv1 5. e1 = (tv2^2) == x 6. e2 = (tv3^2) == x 7. tv1 = CMOV(tv1, tv2, e1) # Select tv2 if (tv2^2) == x 8. tv2 = CMOV(tv4, tv3, e2) # Select tv3 if (tv3^2) == x 9. e3 = (tv2^2) == x 10. z = CMOV(tv1, tv2, e3) # Select the sqrt from tv1 and tv2 11. return z I.4. Constant-time Tonelli-Shanks algorithm This algorithm is a constant-time version of the classic Tonelli- Shanks algorithm ([C93], Algorithm 1.5.1) due to Sean Bowe, Jack Grigg, and Eirik Ogilvie-Wigley [jubjub-fq], adapted and optimized by Michael Scott. This algorithm applies to GF(p) for any p. Note, however, that the special-purpose algorithms given in the prior sections are faster, when they apply. Faz-Hernandez, et al. Expires 17 December 2022 [Page 102] Internet-Draft hash-to-curve June 2022 sqrt_ts_ct(x) Parameters: - F, a finite field of characteristic p and order q = p^m. Input x, an element of F. Output: z, an element of F such that z^2 == x, if x is square in F. Constants: 1. c1, the largest integer such that 2^c1 divides q - 1. 2. c2 = (q - 1) / (2^c1) # Integer arithmetic 3. c3 = (c2 - 1) / 2 # Integer arithmetic 4. c4, a non-square value in F 5. c5 = c4^c2 in F Procedure: 1. z = x^c3 2. t = z * z 3. t = t * x 4. z = z * x 5. b = t 6. c = c5 7. for i in (c1, c1 - 1, ..., 2): 8. for j in (1, 2, ..., i - 2): 9. b = b * b 10. e = b == 1 11. zt = z * c 12. z = CMOV(zt, z, e) 13. c = c * c 14. tt = t * c 15. t = CMOV(tt, t, e) 16. b = t 17. return z I.5. is_square for F = GF(p^2) The following is_square method applies to any field F = GF(p^2) with basis (1, I) represented as described in Section 2.1, i.e., an element x = (x_1, x_2) = x_1 + x_2 * I. Other optimizations of this type are possible in other extension fields; see, e.g., [AR13] for more information. Faz-Hernandez, et al. Expires 17 December 2022 [Page 103] Internet-Draft hash-to-curve June 2022 is_square(x) Parameters: - F, an extension field of characteristic p and order q = p^2 with basis (1, I). Input: x, an element of F. Output: True if x is square in F, and False otherwise. Constants: 1. c1 = (p - 1) / 2 # Integer arithmetic Procedure: 1. tv1 = x_1^2 2. tv2 = I * x_2 3. tv2 = tv2^2 4. tv1 = tv1 - tv2 5. tv1 = tv1^c1 6. e1 = tv1 != -1 # Note: -1 in F 7. return e1 Appendix J. Suite test vectors This section gives test vectors for each suite defined in Section 8. The test vectors in this section were generated using code that is available from [hash2curve-repo]. Each test vector in this section lists values computed by the appropriate encoding function, with variable names defined as in Section 3. For example, for a suite whose encoding type is random oracle, the test vector gives the value for msg, u, Q0, Q1, and the output point P. J.1. NIST P-256 J.1.1. P256_XMD:SHA-256_SSWU_RO_ suite = P256_XMD:SHA-256_SSWU_RO_ dst = QUUX-V01-CS02-with-P256_XMD:SHA-256_SSWU_RO_ msg = P.x = 2c15230b26dbc6fc9a37051158c95b79656e17a1a920b11394ca91 c44247d3e4 P.y = 8a7a74985cc5c776cdfe4b1f19884970453912e9d31528c060be9a b5c43e8415 u[0] = ad5342c66a6dd0ff080df1da0ea1c04b96e0330dd89406465eeba1 1582515009 u[1] = 8c0f1d43204bd6f6ea70ae8013070a1518b43873bcd850aafa0a9e Faz-Hernandez, et al. Expires 17 December 2022 [Page 104] Internet-Draft hash-to-curve June 2022 220e2eea5a Q0.x = ab640a12220d3ff283510ff3f4b1953d09fad35795140b1c5d64f3 13967934d5 Q0.y = dccb558863804a881d4fff3455716c836cef230e5209594ddd33d8 5c565b19b1 Q1.x = 51cce63c50d972a6e51c61334f0f4875c9ac1cd2d3238412f84e31 da7d980ef5 Q1.y = b45d1a36d00ad90e5ec7840a60a4de411917fbe7c82c3949a6e699 e5a1b66aac msg = abc P.x = 0bb8b87485551aa43ed54f009230450b492fead5f1cc91658775da c4a3388a0f P.y = 5c41b3d0731a27a7b14bc0bf0ccded2d8751f83493404c84a88e71 ffd424212e u[0] = afe47f2ea2b10465cc26ac403194dfb68b7f5ee865cda61e9f3e07 a537220af1 u[1] = 379a27833b0bfe6f7bdca08e1e83c760bf9a338ab335542704edcd 69ce9e46e0 Q0.x = 5219ad0ddef3cc49b714145e91b2f7de6ce0a7a7dc7406c7726c7e 373c58cb48 Q0.y = 7950144e52d30acbec7b624c203b1996c99617d0b61c2442354301 b191d93ecf Q1.x = 019b7cb4efcfeaf39f738fe638e31d375ad6837f58a852d032ff60 c69ee3875f Q1.y = 589a62d2b22357fed5449bc38065b760095ebe6aeac84b01156ee4 252715446e msg = abcdef0123456789 P.x = 65038ac8f2b1def042a5df0b33b1f4eca6bff7cb0f9c6c15268118 64e544ed80 P.y = cad44d40a656e7aff4002a8de287abc8ae0482b5ae825822bb870d 6df9b56ca3 u[0] = 0fad9d125a9477d55cf9357105b0eb3a5c4259809bf87180aa01d6 51f53d312c u[1] = b68597377392cd3419d8fcc7d7660948c8403b19ea78bbca4b133c 9d2196c0fb Q0.x = a17bdf2965eb88074bc01157e644ed409dac97cfcf0c61c998ed0f a45e79e4a2 Q0.y = 4f1bc80c70d411a3cc1d67aeae6e726f0f311639fee560c7f5a664 554e3c9c2e Q1.x = 7da48bb67225c1a17d452c983798113f47e438e4202219dd0715f8 419b274d66 Q1.y = b765696b2913e36db3016c47edb99e24b1da30e761a8a3215dc0ec 4d8f96e6f9 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq Faz-Hernandez, et al. Expires 17 December 2022 [Page 105] Internet-Draft hash-to-curve June 2022 qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 4be61ee205094282ba8a2042bcb48d88dfbb609301c49aa8b07853 3dc65a0b5d P.y = 98f8df449a072c4721d241a3b1236d3caccba603f916ca680f4539 d2bfb3c29e u[0] = 3bbc30446f39a7befad080f4d5f32ed116b9534626993d2cc5033f 6f8d805919 u[1] = 76bb02db019ca9d3c1e02f0c17f8baf617bbdae5c393a81d9ce11e 3be1bf1d33 Q0.x = c76aaa823aeadeb3f356909cb08f97eee46ecb157c1f56699b5efe bddf0e6398 Q0.y = 776a6f45f528a0e8d289a4be12c4fab80762386ec644abf2bffb9b 627e4352b1 Q1.x = 418ac3d85a5ccc4ea8dec14f750a3a9ec8b85176c95a7022f39182 6794eb5a75 Q1.y = fd6604f69e9d9d2b74b072d14ea13050db72c932815523305cb9e8 07cc900aff msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 457ae2981f70ca85d8e24c308b14db22f3e3862c5ea0f652ca38b5 e49cd64bc5 P.y = ecb9f0eadc9aeed232dabc53235368c1394c78de05dd96893eefa6 2b0f4757dc u[0] = 4ebc95a6e839b1ae3c63b847798e85cb3c12d3817ec6ebc10af6ee 51adb29fec u[1] = 4e21af88e22ea80156aff790750121035b3eefaa96b425a8716e0d 20b4e269ee Q0.x = d88b989ee9d1295df413d4456c5c850b8b2fb0f5402cc5c4c7e815 412e926db8 Q0.y = bb4a1edeff506cf16def96afff41b16fc74f6dbd55c2210e5b8f01 1ba32f4f40 Q1.x = a281e34e628f3a4d2a53fa87ff973537d68ad4fbc28d3be5e8d9f6 a2571c5a4b Q1.y = f6ed88a7aab56a488100e6f1174fa9810b47db13e86be999644922 961206e184 J.1.2. P256_XMD:SHA-256_SSWU_NU_ Faz-Hernandez, et al. Expires 17 December 2022 [Page 106] Internet-Draft hash-to-curve June 2022 suite = P256_XMD:SHA-256_SSWU_NU_ dst = QUUX-V01-CS02-with-P256_XMD:SHA-256_SSWU_NU_ msg = P.x = f871caad25ea3b59c16cf87c1894902f7e7b2c822c3d3f73596c5a ce8ddd14d1 P.y = 87b9ae23335bee057b99bac1e68588b18b5691af476234b8971bc4 f011ddc99b u[0] = b22d487045f80e9edcb0ecc8d4bf77833e2bf1f3a54004d7df1d57 f4802d311f Q.x = f871caad25ea3b59c16cf87c1894902f7e7b2c822c3d3f73596c5a ce8ddd14d1 Q.y = 87b9ae23335bee057b99bac1e68588b18b5691af476234b8971bc4 f011ddc99b msg = abc P.x = fc3f5d734e8dce41ddac49f47dd2b8a57257522a865c124ed02b92 b5237befa4 P.y = fe4d197ecf5a62645b9690599e1d80e82c500b22ac705a0b421fac 7b47157866 u[0] = c7f96eadac763e176629b09ed0c11992225b3a5ae99479760601cb d69c221e58 Q.x = fc3f5d734e8dce41ddac49f47dd2b8a57257522a865c124ed02b92 b5237befa4 Q.y = fe4d197ecf5a62645b9690599e1d80e82c500b22ac705a0b421fac 7b47157866 msg = abcdef0123456789 P.x = f164c6674a02207e414c257ce759d35eddc7f55be6d7f415e2cc17 7e5d8faa84 P.y = 3aa274881d30db70485368c0467e97da0e73c18c1d00f34775d012 b6fcee7f97 u[0] = 314e8585fa92068b3ea2c3bab452d4257b38be1c097d58a2189045 6c2929614d Q.x = f164c6674a02207e414c257ce759d35eddc7f55be6d7f415e2cc17 7e5d8faa84 Q.y = 3aa274881d30db70485368c0467e97da0e73c18c1d00f34775d012 b6fcee7f97 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 324532006312be4f162614076460315f7a54a6f85544da773dc659 aca0311853 P.y = 8d8197374bcd52de2acfefc8a54fe2c8d8bebd2a39f16be9b710e4 b1af6ef883 u[0] = 752d8eaa38cd785a799a31d63d99c2ae4261823b4a367b133b2c66 27f48858ab Faz-Hernandez, et al. Expires 17 December 2022 [Page 107] Internet-Draft hash-to-curve June 2022 Q.x = 324532006312be4f162614076460315f7a54a6f85544da773dc659 aca0311853 Q.y = 8d8197374bcd52de2acfefc8a54fe2c8d8bebd2a39f16be9b710e4 b1af6ef883 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 5c4bad52f81f39c8e8de1260e9a06d72b8b00a0829a8ea004a610b 0691bea5d9 P.y = c801e7c0782af1f74f24fc385a8555da0582032a3ce038de637ccd cb16f7ef7b u[0] = 0e1527840b9df2dfbef966678ff167140f2b27c4dccd884c25014d ce0e41dfa3 Q.x = 5c4bad52f81f39c8e8de1260e9a06d72b8b00a0829a8ea004a610b 0691bea5d9 Q.y = c801e7c0782af1f74f24fc385a8555da0582032a3ce038de637ccd cb16f7ef7b J.2. NIST P-384 J.2.1. P384_XMD:SHA-384_SSWU_RO_ suite = P384_XMD:SHA-384_SSWU_RO_ dst = QUUX-V01-CS02-with-P384_XMD:SHA-384_SSWU_RO_ msg = P.x = eb9fe1b4f4e14e7140803c1d99d0a93cd823d2b024040f9c067a8e ca1f5a2eeac9ad604973527a356f3fa3aeff0e4d83 P.y = 0c21708cff382b7f4643c07b105c2eaec2cead93a917d825601e63 c8f21f6abd9abc22c93c2bed6f235954b25048bb1a u[0] = 25c8d7dc1acd4ee617766693f7f8829396065d1b447eedb155871f effd9c6653279ac7e5c46edb7010a0e4ff64c9f3b4 u[1] = 59428be4ed69131df59a0c6a8e188d2d4ece3f1b2a3a02602962b4 7efa4d7905945b1e2cc80b36aa35c99451073521ac Q0.x = e4717e29eef38d862bee4902a7d21b44efb58c464e3e1f0d03894d 94de310f8ffc6de86786dd3e15a1541b18d4eb2846 Q0.y = 6b95a6e639822312298a47526bb77d9cd7bcf76244c991c8cd7007 5e2ee6e8b9a135c4a37e3c0768c7ca871c0ceb53d4 Q1.x = 509527cfc0750eedc53147e6d5f78596c8a3b7360e0608e2fab056 3a1670d58d8ae107c9f04bcf90e89489ace5650efd Faz-Hernandez, et al. Expires 17 December 2022 [Page 108] Internet-Draft hash-to-curve June 2022 Q1.y = 33337b13cb35e173fdea4cb9e8cce915d836ff57803dbbeb7998aa 49d17df2ff09b67031773039d09fbd9305a1566bc4 msg = abc P.x = e02fc1a5f44a7519419dd314e29863f30df55a514da2d655775a81 d413003c4d4e7fd59af0826dfaad4200ac6f60abe1 P.y = 01f638d04d98677d65bef99aef1a12a70a4cbb9270ec55248c0453 0d8bc1f8f90f8a6a859a7c1f1ddccedf8f96d675f6 u[0] = 53350214cb6bef0b51abb791b1c4209a2b4c16a0c67e1ab1401017 fad774cd3b3f9a8bcdf7f6229dd8dd5a075cb149a0 u[1] = c0473083898f63e03f26f14877a2407bd60c75ad491e7d26cbc6cc 5ce815654075ec6b6898c7a41d74ceaf720a10c02e Q0.x = fc853b69437aee9a19d5acf96a4ee4c5e04cf7b53406dfaa2afbdd 7ad2351b7f554e4bbc6f5db4177d4d44f933a8f6ee Q0.y = 7e042547e01834c9043b10f3a8221c4a879cb156f04f72bfccab0c 047a304e30f2aa8b2e260d34c4592c0c33dd0c6482 Q1.x = 57912293709b3556b43a2dfb137a315d256d573b82ded120ef8c78 2d607c05d930d958e50cb6dc1cc480b9afc38c45f1 Q1.y = de9387dab0eef0bda219c6f168a92645a84665c4f2137c14270fb4 24b7532ff84843c3da383ceea24c47fa343c227bb8 msg = abcdef0123456789 P.x = bdecc1c1d870624965f19505be50459d363c71a699a496ab672f9a 5d6b78676400926fbceee6fcd1780fe86e62b2aa89 P.y = 57cf1f99b5ee00f3c201139b3bfe4dd30a653193778d89a0accc5e 0f47e46e4e4b85a0595da29c9494c1814acafe183c u[0] = aab7fb87238cf6b2ab56cdcca7e028959bb2ea599d34f68484139d de85ec6548a6e48771d17956421bdb7790598ea52e u[1] = 26e8d833552d7844d167833ca5a87c35bcfaa5a0d86023479fb28e 5cd6075c18b168bf1f5d2a0ea146d057971336d8d1 Q0.x = 0ceece45b73f89844671df962ad2932122e878ad2259e650626924 e4e7f132589341dec1480ebcbbbe3509d11fb570b7 Q0.y = fafd71a3115298f6be4ae5c6dfc96c400cfb55760f185b7b03f3fa 45f3f91eb65d27628b3c705cafd0466fafa54883ce Q1.x = dea1be8d3f9be4cbf4fab9d71d549dde76875b5d9b876832313a08 3ec81e528cbc2a0a1d0596b3bcb0ba77866b129776 Q1.y = eb15fe71662214fb03b65541f40d3eb0f4cf5c3b559f647da138c9 f9b7484c48a08760e02c16f1992762cb7298fa52cf msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 03c3a9f401b78c6c36a52f07eeee0ec1289f178adf78448f43a385 0e0456f5dd7f7633dd31676d990eda32882ab486c0 P.y = cc183d0d7bdfd0a3af05f50e16a3f2de4abbc523215bf57c848d5e a662482b8c1f43dc453a93b94a8026db58f3f5d878 u[0] = 04c00051b0de6e726d228c85bf243bf5f4789efb512b22b498cde3 821db9da667199b74bd5a09a79583c6d353a3bb41c Faz-Hernandez, et al. Expires 17 December 2022 [Page 109] Internet-Draft hash-to-curve June 2022 u[1] = 97580f218255f899f9204db64cd15e6a312cb4d8182375d1e5157c 8f80f41d6a1a4b77fb1ded9dce56c32058b8d5202b Q0.x = 051a22105e0817a35d66196338c8d85bd52690d79bba373ead8a86 dd9899411513bb9f75273f6483395a7847fb21edb4 Q0.y = f168295c1bbcff5f8b01248e9dbc885335d6d6a04aea960f7384f7 46ba6502ce477e624151cc1d1392b00df0f5400c06 Q1.x = 6ad7bc8ed8b841efd8ad0765c8a23d0b968ec9aa360a558ff33500 f164faa02bee6c704f5f91507c4c5aad2b0dc5b943 Q1.y = 47313cc0a873ade774048338fc34ca5313f96bbf6ae22ac6ef475d 85f03d24792dc6afba8d0b4a70170c1b4f0f716629 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 7b18d210b1f090ac701f65f606f6ca18fb8d081e3bc6cbd937c560 4325f1cdea4c15c10a54ef303aabf2ea58bd9947a4 P.y = ea857285a33abb516732915c353c75c576bf82ccc96adb63c094dd e580021eddeafd91f8c0bfee6f636528f3d0c47fd2 u[0] = 480cb3ac2c389db7f9dac9c396d2647ae946db844598971c26d1af d53912a1491199c0a5902811e4b809c26fcd37a014 u[1] = d28435eb34680e148bf3908536e42231cba9e1f73ae2c6902a222a 89db5c49c97db2f8fa4d4cd6e424b17ac60bdb9bb6 Q0.x = 42e6666f505e854187186bad3011598d9278b9d6e3e4d2503c3d23 6381a56748dec5d139c223129b324df53fa147c4df Q0.y = 8ee51dbda46413bf621838cc935d18d617881c6f33f3838a79c767 a1e5618e34b22f79142df708d2432f75c7366c8512 Q1.x = 4ff01ceeba60484fa1bc0d825fe1e5e383d8f79f1e5bb78e5fb26b 7a7ef758153e31e78b9d60ce75c5e32e43869d4e12 Q1.y = 0f84b978fac8ceda7304b47e229d6037d32062e597dc7a9b95bcd9 af441f3c56c619a901d21635f9ec6ab4710b9fcd0e J.2.2. P384_XMD:SHA-384_SSWU_NU_ suite = P384_XMD:SHA-384_SSWU_NU_ dst = QUUX-V01-CS02-with-P384_XMD:SHA-384_SSWU_NU_ msg = P.x = de5a893c83061b2d7ce6a0d8b049f0326f2ada4b966dc7e7292725 6b033ef61058029a3bfb13c1c7ececd6641881ae20 P.y = 63f46da6139785674da315c1947e06e9a0867f5608cf24724eb379 3a1f5b3809ee28eb21a0c64be3be169afc6cdb38ca Faz-Hernandez, et al. Expires 17 December 2022 [Page 110] Internet-Draft hash-to-curve June 2022 u[0] = bc7dc1b2cdc5d588a66de3276b0f24310d4aca4977efda7d6272e1 be25187b001493d267dc53b56183c9e28282368e60 Q.x = de5a893c83061b2d7ce6a0d8b049f0326f2ada4b966dc7e7292725 6b033ef61058029a3bfb13c1c7ececd6641881ae20 Q.y = 63f46da6139785674da315c1947e06e9a0867f5608cf24724eb379 3a1f5b3809ee28eb21a0c64be3be169afc6cdb38ca msg = abc P.x = 1f08108b87e703c86c872ab3eb198a19f2b708237ac4be53d7929f b4bd5194583f40d052f32df66afe5249c9915d139b P.y = 1369dc8d5bf038032336b989994874a2270adadb67a7fcc32f0f88 24bc5118613f0ac8de04a1041d90ff8a5ad555f96c u[0] = 9de6cf41e6e41c03e4a7784ac5c885b4d1e49d6de390b3cdd5a1ac 5dd8c40afb3dfd7bb2686923bab644134483fc1926 Q.x = 1f08108b87e703c86c872ab3eb198a19f2b708237ac4be53d7929f b4bd5194583f40d052f32df66afe5249c9915d139b Q.y = 1369dc8d5bf038032336b989994874a2270adadb67a7fcc32f0f88 24bc5118613f0ac8de04a1041d90ff8a5ad555f96c msg = abcdef0123456789 P.x = 4dac31ec8a82ee3c02ba2d7c9fa431f1e59ffe65bf977b948c59e1 d813c2d7963c7be81aa6db39e78ff315a10115c0d0 P.y = 845333cdb5702ad5c525e603f302904d6fc84879f0ef2ee2014a6b 13edd39131bfd66f7bd7cdc2d9ccf778f0c8892c3f u[0] = 84e2d430a5e2543573e58e368af41821ca3ccc97baba7e9aab51a8 4543d5a0298638a22ceee6090d9d642921112af5b7 Q.x = 4dac31ec8a82ee3c02ba2d7c9fa431f1e59ffe65bf977b948c59e1 d813c2d7963c7be81aa6db39e78ff315a10115c0d0 Q.y = 845333cdb5702ad5c525e603f302904d6fc84879f0ef2ee2014a6b 13edd39131bfd66f7bd7cdc2d9ccf778f0c8892c3f msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 13c1f8c52a492183f7c28e379b0475486718a7e3ac1dfef39283b9 ce5fb02b73f70c6c1f3dfe0c286b03e2af1af12d1d P.y = 57e101887e73e40eab8963324ed16c177d55eb89f804ec9df06801 579820420b5546b579008df2145fd770f584a1a54c u[0] = 504e4d5a529333b9205acaa283107bd1bffde753898f7744161f7d d19ba57fbb6a64214a2e00ddd2613d76cd508ddb30 Q.x = 13c1f8c52a492183f7c28e379b0475486718a7e3ac1dfef39283b9 ce5fb02b73f70c6c1f3dfe0c286b03e2af1af12d1d Q.y = 57e101887e73e40eab8963324ed16c177d55eb89f804ec9df06801 579820420b5546b579008df2145fd770f584a1a54c msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Faz-Hernandez, et al. Expires 17 December 2022 [Page 111] Internet-Draft hash-to-curve June 2022 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = af129727a4207a8cb9e9dce656d88f79fce25edbcea350499d65e9 bf1204537bdde73c7cefb752a6ed5ebcd44e183302 P.y = ce68a3d5e161b2e6a968e4ddaa9e51504ad1516ec170c7eef3ca6b 5327943eca95d90b23b009ba45f58b72906f2a99e2 u[0] = 7b01ce9b8c5a60d9fbc202d6dde92822e46915d8c17e03fcb92ece 1ed6074d01e149fc9236def40d673de903c1d4c166 Q.x = af129727a4207a8cb9e9dce656d88f79fce25edbcea350499d65e9 bf1204537bdde73c7cefb752a6ed5ebcd44e183302 Q.y = ce68a3d5e161b2e6a968e4ddaa9e51504ad1516ec170c7eef3ca6b 5327943eca95d90b23b009ba45f58b72906f2a99e2 J.3. NIST P-521 J.3.1. P521_XMD:SHA-512_SSWU_RO_ suite = P521_XMD:SHA-512_SSWU_RO_ dst = QUUX-V01-CS02-with-P521_XMD:SHA-512_SSWU_RO_ msg = P.x = 00fd767cebb2452030358d0e9cf907f525f50920c8f607889a6a35 680727f64f4d66b161fafeb2654bea0d35086bec0a10b30b14adef 3556ed9f7f1bc23cecc9c088 P.y = 0169ba78d8d851e930680322596e39c78f4fe31b97e57629ef6460 ddd68f8763fd7bd767a4e94a80d3d21a3c2ee98347e024fc73ee1c 27166dc3fe5eeef782be411d u[0] = 01e5f09974e5724f25286763f00ce76238c7a6e03dc396600350ee 2c4135fb17dc555be99a4a4bae0fd303d4f66d984ed7b6a3ba3860 93752a855d26d559d69e7e9e u[1] = 00ae593b42ca2ef93ac488e9e09a5fe5a2f6fb330d18913734ff60 2f2a761fcaaf5f596e790bcc572c9140ec03f6cccc38f767f1c197 5a0b4d70b392d95a0c7278aa Q0.x = 00b70ae99b6339fffac19cb9bfde2098b84f75e50ac1e80d6acb95 4e4534af5f0e9c4a5b8a9c10317b8e6421574bae2b133b4f2b8c6c e4b3063da1d91d34fa2b3a3c Q0.y = 007f368d98a4ddbf381fb354de40e44b19e43bb11a1278759f4ea7 b485e1b6db33e750507c071250e3e443c1aaed61f2c28541bb54b1 b456843eda1eb15ec2a9b36e Q1.x = 01143d0e9cddcdacd6a9aafe1bcf8d218c0afc45d4451239e821f5 d2a56df92be942660b532b2aa59a9c635ae6b30e803c45a6ac8714 32452e685d661cd41cf67214 Q1.y = 00ff75515df265e996d702a5380defffab1a6d2bc232234c7bcffa Faz-Hernandez, et al. Expires 17 December 2022 [Page 112] Internet-Draft hash-to-curve June 2022 433cd8aa791fbc8dcf667f08818bffa739ae25773b32073213cae9 a0f2a917a0b1301a242dda0c msg = abc P.x = 002f89a1677b28054b50d15e1f81ed6669b5a2158211118ebdef8a 6efc77f8ccaa528f698214e4340155abc1fa08f8f613ef14a04371 7503d57e267d57155cf784a4 P.y = 010e0be5dc8e753da8ce51091908b72396d3deed14ae166f66d8eb f0a4e7059ead169ea4bead0232e9b700dd380b316e9361cfdba55a 08c73545563a80966ecbb86d u[0] = 003d00c37e95f19f358adeeaa47288ec39998039c3256e13c2a4c0 0a7cb61a34c8969472960150a27276f2390eb5e53e47ab193351c2 d2d9f164a85c6a5696d94fe8 u[1] = 01f3cbd3df3893a45a2f1fecdac4d525eb16f345b03e2820d69bc5 80f5cbe9cb89196fdf720ef933c4c0361fcfe29940fd0db0a5da6b afb0bee8876b589c41365f15 Q0.x = 01b254e1c99c835836f0aceebba7d77750c48366ecb07fb658e4f5 b76e229ae6ca5d271bb0006ffcc42324e15a6d3daae587f9049de2 dbb0494378ffb60279406f56 Q0.y = 01845f4af72fc2b1a5a2fe966f6a97298614288b456cfc385a425b 686048b25c952fbb5674057e1eb055d04568c0679a8e2dda3158dc 16ac598dbb1d006f5ad915b0 Q1.x = 007f08e813c620e527c961b717ffc74aac7afccb9158cebc347d57 15d5c2214f952c97e194f11d114d80d3481ed766ac0a3dba3eb73f 6ff9ccb9304ad10bbd7b4a36 Q1.y = 0022468f92041f9970a7cc025d71d5b647f822784d29ca7b3bc3b0 829d6bb8581e745f8d0cc9dc6279d0450e779ac2275c4c3608064a d6779108a7828ebd9954caeb msg = abcdef0123456789 P.x = 006e200e276a4a81760099677814d7f8794a4a5f3658442de63c18 d2244dcc957c645e94cb0754f95fcf103b2aeaf94411847c24187b 89fb7462ad3679066337cbc4 P.y = 001dd8dfa9775b60b1614f6f169089d8140d4b3e4012949b52f98d b2deff3e1d97bf73a1fa4d437d1dcdf39b6360cc518d8ebcc0f899 018206fded7617b654f6b168 u[0] = 00183ee1a9bbdc37181b09ec336bcaa34095f91ef14b66b1485c16 6720523dfb81d5c470d44afcb52a87b704dbc5c9bc9d0ef524dec2 9884a4795f55c1359945baf3 u[1] = 00504064fd137f06c81a7cf0f84aa7e92b6b3d56c2368f0a08f447 76aa8930480da1582d01d7f52df31dca35ee0a7876500ece3d8fe0 293cd285f790c9881c998d5e Q0.x = 0021482e8622aac14da60e656043f79a6a110cbae5012268a62dd6 a152c41594549f373910ebed170ade892dd5a19f5d687fae7095a4 61d583f8c4295f7aaf8cd7da Q0.y = 0177e2d8c6356b7de06e0b5712d8387d529b848748e54a8bc0ef5f 1475aa569f8f492fa85c3ad1c5edc51faf7911f11359bfa2a12d2e f0bd73df9cb5abd1b101c8b1 Faz-Hernandez, et al. Expires 17 December 2022 [Page 113] Internet-Draft hash-to-curve June 2022 Q1.x = 00abeafb16fdbb5eb95095678d5a65c1f293291dfd20a3751dbe05 d0a9bfe2d2eef19449fe59ec32cdd4a4adc3411177c0f2dffd0159 438706159a1bbd0567d9b3d0 Q1.y = 007cc657f847db9db651d91c801741060d63dab4056d0a1d3524e2 eb0e819954d8f677aa353bd056244a88f00017e00c3ce8beeedb43 82d83d74418bd48930c6c182 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 01b264a630bd6555be537b000b99a06761a9325c53322b65bdc41b f196711f9708d58d34b3b90faf12640c27b91c70a507998e559406 48caa8e71098bf2bc8d24664 P.y = 01ea9f445bee198b3ee4c812dcf7b0f91e0881f0251aab272a1220 1fd89b1a95733fd2a699c162b639e9acdcc54fdc2f6536129b6beb 0432be01aa8da02df5e59aaa u[0] = 0159871e222689aad7694dc4c3480a49807b1eedd9c8cb4ae1b219 d5ba51655ea5b38e2e4f56b36bf3e3da44a7b139849d28f598c816 fe1bc7ed15893b22f63363c3 u[1] = 004ef0cffd475152f3858c0a8ccbdf7902d8261da92744e98df9b7 fadb0a5502f29c5086e76e2cf498f47321434a40b1504911552ce4 4ad7356a04e08729ad9411f5 Q0.x = 0005eac7b0b81e38727efcab1e375f6779aea949c3e409b53a1d37 aa2acbac87a7e6ad24aafbf3c52f82f7f0e21b872e88c55e17b7fa 21ce08a94ea2121c42c2eb73 Q0.y = 00a173b6a53a7420dbd61d4a21a7c0a52de7a5c6ce05f31403bef7 47d16cc8604a039a73bdd6e114340e55dacd6bea8e217ffbadfb8c 292afa3e1b2afc839a6ce7bb Q1.x = 01881e3c193a69e4d88d8180a6879b74782a0bc7e529233e9f84bf 7f17d2f319c36920ffba26f9e57a1e045cc7822c834c239593b6e1 42a694aa00c757b0db79e5e8 Q1.y = 01558b16d396d866e476e001f2dd0758927655450b84e12f154032 c7c2a6db837942cd9f44b814f79b4d729996ced61eec61d85c6751 39cbffe3fbf071d2c21cfecb msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 00c12bc3e28db07b6b4d2a2b1167ab9e26fc2fa85c7b0498a17b03 47edf52392856d7e28b8fa7a2dd004611159505835b687ecf1a764 857e27e9745848c436ef3925 Faz-Hernandez, et al. Expires 17 December 2022 [Page 114] Internet-Draft hash-to-curve June 2022 P.y = 01cd287df9a50c22a9231beb452346720bb163344a41c5f5a24e83 35b6ccc595fd436aea89737b1281aecb411eb835f0b939073fdd1d d4d5a2492e91ef4a3c55bcbd u[0] = 0033d06d17bc3b9a3efc081a05d65805a14a3050a0dd4dfb488461 8eb5c73980a59c5a246b18f58ad022dd3630faa22889fbb8ba1593 466515e6ab4aeb7381c26334 u[1] = 0092290ab99c3fea1a5b8fb2ca49f859994a04faee3301cefab312 d34227f6a2d0c3322cf76861c6a3683bdaa2dd2a6daa5d6906c663 e065338b2344d20e313f1114 Q0.x = 00041f6eb92af8777260718e4c22328a7d74203350c6c8f5794d99 d5789766698f459b83d5068276716f01429934e40af3d1111a2278 0b1e07e72238d2207e5386be Q0.y = 001c712f0182813942b87cab8e72337db017126f52ed797dd23458 4ac9ae7e80dfe7abea11db02cf1855312eae1447dbaecc9d7e8c88 0a5e76a39f6258074e1bc2e0 Q1.x = 0125c0b69bcf55eab49280b14f707883405028e05c927cd7625d4e 04115bd0e0e6323b12f5d43d0d6d2eff16dbcf244542f84ec05891 1260dc3bb6512ab5db285fbd Q1.y = 008bddfb803b3f4c761458eb5f8a0aee3e1f7f68e9d7424405fa69 172919899317fb6ac1d6903a432d967d14e0f80af63e7035aaae0c 123e56862ce969456f99f102 J.3.2. P521_XMD:SHA-512_SSWU_NU_ suite = P521_XMD:SHA-512_SSWU_NU_ dst = QUUX-V01-CS02-with-P521_XMD:SHA-512_SSWU_NU_ msg = P.x = 01ec604b4e1e3e4c7449b7a41e366e876655538acf51fd40d08b97 be066f7d020634e906b1b6942f9174b417027c953d75fb6ec64b8c ee2a3672d4f1987d13974705 P.y = 00944fc439b4aad2463e5c9cfa0b0707af3c9a42e37c5a57bb4ecd 12fef9fb21508568aedcdd8d2490472df4bbafd79081c81e99f4da 3286eddf19be47e9c4cf0e91 u[0] = 01e4947fe62a4e47792cee2798912f672fff820b2556282d9843b4 b465940d7683a986f93ccb0e9a191fbc09a6e770a564490d2a4ae5 1b287ca39f69c3d910ba6a4f Q.x = 01ec604b4e1e3e4c7449b7a41e366e876655538acf51fd40d08b97 be066f7d020634e906b1b6942f9174b417027c953d75fb6ec64b8c ee2a3672d4f1987d13974705 Q.y = 00944fc439b4aad2463e5c9cfa0b0707af3c9a42e37c5a57bb4ecd 12fef9fb21508568aedcdd8d2490472df4bbafd79081c81e99f4da 3286eddf19be47e9c4cf0e91 msg = abc P.x = 00c720ab56aa5a7a4c07a7732a0a4e1b909e32d063ae1b58db5f0e b5e09f08a9884bff55a2bef4668f715788e692c18c1915cd034a6b 998311fcf46924ce66a2be9a Faz-Hernandez, et al. Expires 17 December 2022 [Page 115] Internet-Draft hash-to-curve June 2022 P.y = 003570e87f91a4f3c7a56be2cb2a078ffc153862a53d5e03e5dad5 bccc6c529b8bab0b7dbb157499e1949e4edab21cf5d10b782bc1e9 45e13d7421ad8121dbc72b1d u[0] = 0019b85ef78596efc84783d42799e80d787591fe7432dee1d9fa2b 7651891321be732ddf653fa8fefa34d86fb728db569d36b5b6ed39 83945854b2fc2dc6a75aa25b Q.x = 00c720ab56aa5a7a4c07a7732a0a4e1b909e32d063ae1b58db5f0e b5e09f08a9884bff55a2bef4668f715788e692c18c1915cd034a6b 998311fcf46924ce66a2be9a Q.y = 003570e87f91a4f3c7a56be2cb2a078ffc153862a53d5e03e5dad5 bccc6c529b8bab0b7dbb157499e1949e4edab21cf5d10b782bc1e9 45e13d7421ad8121dbc72b1d msg = abcdef0123456789 P.x = 00bcaf32a968ff7971b3bbd9ce8edfbee1309e2019d7ff373c3838 7a782b005dce6ceffccfeda5c6511c8f7f312f343f3a891029c585 8f45ee0bf370aba25fc990cc P.y = 00923517e767532d82cb8a0b59705eec2b7779ce05f9181c7d5d5e 25694ef8ebd4696343f0bc27006834d2517215ecf79482a84111f5 0c1bae25044fe1dd77744bbd u[0] = 01dba0d7fa26a562ee8a9014ebc2cca4d66fd9de036176aca8fc11 ef254cd1bc208847ab7701dbca7af328b3f601b11a1737a899575a 5c14f4dca5aaca45e9935e07 Q.x = 00bcaf32a968ff7971b3bbd9ce8edfbee1309e2019d7ff373c3838 7a782b005dce6ceffccfeda5c6511c8f7f312f343f3a891029c585 8f45ee0bf370aba25fc990cc Q.y = 00923517e767532d82cb8a0b59705eec2b7779ce05f9181c7d5d5e 25694ef8ebd4696343f0bc27006834d2517215ecf79482a84111f5 0c1bae25044fe1dd77744bbd msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 001ac69014869b6c4ad7aa8c443c255439d36b0e48a0f57b03d6fe 9c40a66b4e2eaed2a93390679a5cc44b3a91862b34b673f0e92c83 187da02bf3db967d867ce748 P.y = 00d5603d530e4d62b30fccfa1d90c2206654d74291c1db1c25b86a 051ee3fffc294e5d56f2e776853406bd09206c63d40f37ad882952 4cf89ad70b5d6e0b4a3b7341 u[0] = 00844da980675e1244cb209dcf3ea0aabec23bd54b2cda69fff86e b3acc318bf3d01bae96e9cd6f4c5ceb5539df9a7ad7fcc5e9d5469 6081ba9782f3a0f6d14987e3 Q.x = 001ac69014869b6c4ad7aa8c443c255439d36b0e48a0f57b03d6fe 9c40a66b4e2eaed2a93390679a5cc44b3a91862b34b673f0e92c83 187da02bf3db967d867ce748 Q.y = 00d5603d530e4d62b30fccfa1d90c2206654d74291c1db1c25b86a 051ee3fffc294e5d56f2e776853406bd09206c63d40f37ad882952 4cf89ad70b5d6e0b4a3b7341 Faz-Hernandez, et al. Expires 17 December 2022 [Page 116] Internet-Draft hash-to-curve June 2022 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 01801de044c517a80443d2bd4f503a9e6866750d2f94a22970f62d 721f96e4310e4a828206d9cdeaa8f2d476705cc3bbc490a6165c68 7668f15ec178a17e3d27349b P.y = 0068889ea2e1442245fe42bfda9e58266828c0263119f35a61631a 3358330f3bb84443fcb54fcd53a1d097fccbe310489b74ee143fc2 938959a83a1f7dd4a6fd395b u[0] = 01aab1fb7e5cd44ba4d9f32353a383cb1bb9eb763ed40b32bdd5f6 66988970205998c0e44af6e2b5f6f8e48e969b3f649cae3c6ab463 e1b274d968d91c02f00cce91 Q.x = 01801de044c517a80443d2bd4f503a9e6866750d2f94a22970f62d 721f96e4310e4a828206d9cdeaa8f2d476705cc3bbc490a6165c68 7668f15ec178a17e3d27349b Q.y = 0068889ea2e1442245fe42bfda9e58266828c0263119f35a61631a 3358330f3bb84443fcb54fcd53a1d097fccbe310489b74ee143fc2 938959a83a1f7dd4a6fd395b J.4. curve25519 J.4.1. curve25519_XMD:SHA-512_ELL2_RO_ suite = curve25519_XMD:SHA-512_ELL2_RO_ dst = QUUX-V01-CS02-with-curve25519_XMD:SHA-512_ELL2_RO_ msg = P.x = 2de3780abb67e861289f5749d16d3e217ffa722192d16bbd9d1bfb 9d112b98c0 P.y = 3b5dc2a498941a1033d176567d457845637554a2fe7a3507d21abd 1c1bd6e878 u[0] = 005fe8a7b8fef0a16c105e6cadf5a6740b3365e18692a9c05bfbb4 d97f645a6a u[1] = 1347edbec6a2b5d8c02e058819819bee177077c9d10a4ce165aab0 fd0252261a Q0.x = 36b4df0c864c64707cbf6cf36e9ee2c09a6cb93b28313c169be295 61bb904f98 Q0.y = 6cd59d664fb58c66c892883cd0eb792e52055284dac3907dd756b4 5d15c3983d Q1.x = 3fa114783a505c0b2b2fbeef0102853c0b494e7757f2a089d0daae 7ed9a0db2b Faz-Hernandez, et al. Expires 17 December 2022 [Page 117] Internet-Draft hash-to-curve June 2022 Q1.y = 76c0fe7fec932aaafb8eefb42d9cbb32eb931158f469ff3050af15 cfdbbeff94 msg = abc P.x = 2b4419f1f2d48f5872de692b0aca72cc7b0a60915dd70bde432e82 6b6abc526d P.y = 1b8235f255a268f0a6fa8763e97eb3d22d149343d495da1160eff9 703f2d07dd u[0] = 49bed021c7a3748f09fa8cdfcac044089f7829d3531066ac9e74e0 994e05bc7d u[1] = 5c36525b663e63389d886105cee7ed712325d5a97e60e140aba7e2 ce5ae851b6 Q0.x = 16b3d86e056b7970fa00165f6f48d90b619ad618791661b7b5e1ec 78be10eac1 Q0.y = 4ab256422d84c5120b278cbdfc4e1facc5baadffeccecf8ee9bf39 46106d50ca Q1.x = 7ec29ddbf34539c40adfa98fcb39ec36368f47f30e8f888cc7e86f 4d46e0c264 Q1.y = 10d1abc1cae2d34c06e247f2141ba897657fb39f1080d54f09ce0a f128067c74 msg = abcdef0123456789 P.x = 68ca1ea5a6acf4e9956daa101709b1eee6c1bb0df1de3b90d46023 82a104c036 P.y = 2a375b656207123d10766e68b938b1812a4a6625ff83cb8d5e86f5 8a4be08353 u[0] = 6412b7485ba26d3d1b6c290a8e1435b2959f03721874939b21782d f17323d160 u[1] = 24c7b46c1c6d9a21d32f5707be1380ab82db1054fde82865d5c9e3 d968f287b2 Q0.x = 71de3dadfe268872326c35ac512164850860567aea0e7325e6b91a 98f86533ad Q0.y = 26a08b6e9a18084c56f2147bf515414b9b63f1522e1b6c5649f7d4 b0324296ec Q1.x = 5704069021f61e41779e2ba6b932268316d6d2a6f064f997a22fef 16d1eaeaca Q1.y = 50483c7540f64fb4497619c050f2c7fe55454ec0f0e79870bb4430 2e34232210 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 096e9c8bae6c06b554c1ee69383bb0e82267e064236b3a30608d4e d20b73ac5a P.y = 1eb5a62612cafb32b16c3329794645b5b948d9f8ffe501d4e26b07 3fef6de355 u[0] = 5e123990f11bbb5586613ffabdb58d47f64bb5f2fa115f8ea8df01 88e0c9e1b5 Faz-Hernandez, et al. Expires 17 December 2022 [Page 118] Internet-Draft hash-to-curve June 2022 u[1] = 5e8553eb00438a0bb1e7faa59dec6d8087f9c8011e5fb8ed9df31c b6c0d4ac19 Q0.x = 7a94d45a198fb5daa381f45f2619ab279744efdd8bd8ed587fc5b6 5d6cea1df0 Q0.y = 67d44f85d376e64bb7d713585230cdbfafc8e2676f7568e0b6ee59 361116a6e1 Q1.x = 30506fb7a32136694abd61b6113770270debe593027a968a01f271 e146e60c18 Q1.y = 7eeee0e706b40c6b5174e551426a67f975ad5a977ee2f01e8e20a6 d612458c3b msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 1bc61845a138e912f047b5e70ba9606ba2a447a4dade024c8ef3dd 42b7bbc5fe P.y = 623d05e47b70e25f7f1d51dda6d7c23c9a18ce015fe3548df596ea 9e38c69bf1 u[0] = 20f481e85da7a3bf60ac0fb11ed1d0558fc6f941b3ac5469aa8b56 ec883d6d7d u[1] = 017d57fd257e9a78913999a23b52ca988157a81b09c5442501d07f ed20869465 Q0.x = 02d606e2699b918ee36f2818f2bc5013e437e673c9f9b9cdc15fd0 c5ee913970 Q0.y = 29e9dc92297231ef211245db9e31767996c5625dfbf92e1c8107ef 887365de1e Q1.x = 38920e9b988d1ab7449c0fa9a6058192c0c797bb3d42ac34572434 1a1aa98745 Q1.y = 24dcc1be7c4d591d307e89049fd2ed30aae8911245a9d8554bf603 2e5aa40d3d J.4.2. curve25519_XMD:SHA-512_ELL2_NU_ suite = curve25519_XMD:SHA-512_ELL2_NU_ dst = QUUX-V01-CS02-with-curve25519_XMD:SHA-512_ELL2_NU_ msg = P.x = 1bb913f0c9daefa0b3375378ffa534bda5526c97391952a7789eb9 76edfe4d08 P.y = 4548368f4f983243e747b62a600840ae7c1dab5c723991f85d3a97 68479f3ec4 Faz-Hernandez, et al. Expires 17 December 2022 [Page 119] Internet-Draft hash-to-curve June 2022 u[0] = 608d892b641f0328523802a6603427c26e55e6f27e71a91a478148 d45b5093cd Q.x = 51125222da5e763d97f3c10fcc92ea6860b9ccbbd2eb1285728f56 6721c1e65b Q.y = 343d2204f812d3dfc5304a5808c6c0d81a903a5d228b342442aa3c 9ba5520a3d msg = abc P.x = 7c22950b7d900fa866334262fcaea47a441a578df43b894b4625c9 b450f9a026 P.y = 5547bc00e4c09685dcbc6cb6765288b386d8bdcb595fa5a6e3969e 08097f0541 u[0] = 46f5b22494bfeaa7f232cc8d054be68561af50230234d7d1d63d1d 9abeca8da5 Q.x = 7d56d1e08cb0ccb92baf069c18c49bb5a0dcd927eff8dcf75ca921 ef7f3e6eeb Q.y = 404d9a7dc25c9c05c44ab9a94590e7c3fe2dcec74533a0b24b188a 5d5dacf429 msg = abcdef0123456789 P.x = 31ad08a8b0deeb2a4d8b0206ca25f567ab4e042746f792f4b7973f 3ae2096c52 P.y = 405070c28e78b4fa269427c82827261991b9718bd6c6e95d627d70 1a53c30db1 u[0] = 235fe40c443766ce7e18111c33862d66c3b33267efa50d50f9e8e5 d252a40aaa Q.x = 3fbe66b9c9883d79e8407150e7c2a1c8680bee496c62fabe4619a7 2b3cabe90f Q.y = 08ec476147c9a0a3ff312d303dbbd076abb7551e5fce82b48ab14b 433f8d0a7b msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 027877759d155b1997d0d84683a313eb78bdb493271d935b622900 459d52ceaa P.y = 54d691731a53baa30707f4a87121d5169fb5d587d70fb0292b5830 dedbec4c18 u[0] = 001e92a544463bda9bd04ddbe3d6eed248f82de32f522669efc5dd ce95f46f5b Q.x = 227e0bb89de700385d19ec40e857db6e6a3e634b1c32962f370d26 f84ff19683 Q.y = 5f86ff3851d262727326a32c1bf7655a03665830fa7f1b8b1e5a09 d85bc66e4a msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Faz-Hernandez, et al. Expires 17 December 2022 [Page 120] Internet-Draft hash-to-curve June 2022 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 5fd892c0958d1a75f54c3182a18d286efab784e774d1e017ba2fb2 52998b5dc1 P.y = 750af3c66101737423a4519ac792fb93337bd74ee751f19da4cf1e 94f4d6d0b8 u[0] = 1a68a1af9f663592291af987203393f707305c7bac9c8d63d6a729 bdc553dc19 Q.x = 3bcd651ee54d5f7b6013898aab251ee8ecc0688166fce6e9548d38 472f6bd196 Q.y = 1bb36ad9197299f111b4ef21271c41f4b7ecf5543db8bb5931307e bdb2eaa465 J.5. edwards25519 J.5.1. edwards25519_XMD:SHA-512_ELL2_RO_ suite = edwards25519_XMD:SHA-512_ELL2_RO_ dst = QUUX-V01-CS02-with-edwards25519_XMD:SHA-512_ELL2_RO_ msg = P.x = 3c3da6925a3c3c268448dcabb47ccde5439559d9599646a8260e47 b1e4822fc6 P.y = 09a6c8561a0b22bef63124c588ce4c62ea83a3c899763af26d7953 02e115dc21 u[0] = 03fef4813c8cb5f98c6eef88fae174e6e7d5380de2b007799ac7ee 712d203f3a u[1] = 780bdddd137290c8f589dc687795aafae35f6b674668d92bf92ae7 93e6a60c75 Q0.x = 6549118f65bb617b9e8b438decedc73c496eaed496806d3b2eb9ee 60b88e09a7 Q0.y = 7315bcc8cf47ed68048d22bad602c6680b3382a08c7c5d3f439a97 3fb4cf9feb Q1.x = 31dcfc5c58aa1bee6e760bf78cbe71c2bead8cebb2e397ece0f37a 3da19c9ed2 Q1.y = 7876d81474828d8a5928b50c82420b2bd0898d819e9550c5c82c39 fc9bafa196 msg = abc P.x = 608040b42285cc0d72cbb3985c6b04c935370c7361f4b7fbdb1ae7 f8c1a8ecad P.y = 1a8395b88338f22e435bbd301183e7f20a5f9de643f11882fb237f 88268a5531 Faz-Hernandez, et al. Expires 17 December 2022 [Page 121] Internet-Draft hash-to-curve June 2022 u[0] = 5081955c4141e4e7d02ec0e36becffaa1934df4d7a270f70679c78 f9bd57c227 u[1] = 005bdc17a9b378b6272573a31b04361f21c371b256252ae5463119 aa0b925b76 Q0.x = 5c1525bd5d4b4e034512949d187c39d48e8cd84242aa4758956e4a dc7d445573 Q0.y = 2bf426cf7122d1a90abc7f2d108befc2ef415ce8c2d09695a74072 40faa01f29 Q1.x = 37b03bba828860c6b459ddad476c83e0f9285787a269df2156219b 7e5c86210c Q1.y = 285ebf5412f84d0ad7bb4e136729a9ffd2195d5b8e73c0dc85110c e06958f432 msg = abcdef0123456789 P.x = 6d7fabf47a2dc03fe7d47f7dddd21082c5fb8f86743cd020f3fb14 7d57161472 P.y = 53060a3d140e7fbcda641ed3cf42c88a75411e648a1add71217f70 ea8ec561a6 u[0] = 285ebaa3be701b79871bcb6e225ecc9b0b32dff2d60424b4c50642 636a78d5b3 u[1] = 2e253e6a0ef658fedb8e4bd6a62d1544fd6547922acb3598ec6b36 9760b81b31 Q0.x = 3ac463dd7fddb773b069c5b2b01c0f6b340638f54ee3bd92d452fc ec3015b52d Q0.y = 7b03ba1e8db9ec0b390d5c90168a6a0b7107156c994c674b61fe69 6cbeb46baf Q1.x = 0757e7e904f5e86d2d2f4acf7e01c63827fde2d363985aa7432106 f1b3a444ec Q1.y = 50026c96930a24961e9d86aa91ea1465398ff8e42015e2ec1fa397 d416f6a1c0 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 5fb0b92acedd16f3bcb0ef83f5c7b7a9466b5f1e0d8d217421878e a3686f8524 P.y = 2eca15e355fcfa39d2982f67ddb0eea138e2994f5956ed37b7f72e ea5e89d2f7 u[0] = 4fedd25431c41f2a606952e2945ef5e3ac905a42cf64b8b4d4a83c 533bf321af u[1] = 02f20716a5801b843987097a8276b6d869295b2e11253751ca72c1 09d37485a9 Q0.x = 703e69787ea7524541933edf41f94010a201cc841c1cce60205ec3 8513458872 Q0.y = 32bb192c4f89106466f0874f5fd56a0d6b6f101cb714777983336c 159a9bec75 Q1.x = 0c9077c5c31720ed9413abe59bf49ce768506128d810cb882435aa 90f713ef6b Faz-Hernandez, et al. Expires 17 December 2022 [Page 122] Internet-Draft hash-to-curve June 2022 Q1.y = 7d5aec5210db638c53f050597964b74d6dda4be5b54fa73041bf90 9ccb3826cb msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 0efcfde5898a839b00997fbe40d2ebe950bc81181afbd5cd6b9618 aa336c1e8c P.y = 6dc2fc04f266c5c27f236a80b14f92ccd051ef1ff027f26a07f8c0 f327d8f995 u[0] = 6e34e04a5106e9bd59f64aba49601bf09d23b27f7b594e56d5de06 df4a4ea33b u[1] = 1c1c2cb59fc053f44b86c5d5eb8c1954b64976d0302d3729ff66e8 4068f5fd96 Q0.x = 21091b2e3f9258c7dfa075e7ae513325a94a3d8a28e1b1cb3b5b6f 5d65675592 Q0.y = 41a33d324c89f570e0682cdf7bdb78852295daf8084c669f2cc969 2896ab5026 Q1.x = 4c07ec48c373e39a23bd7954f9e9b66eeab9e5ee1279b867b3d531 5aa815454f Q1.y = 67ccac7c3cb8d1381242d8d6585c57eabaddbb5dca5243a68a8aeb 5477d94b3a J.5.2. edwards25519_XMD:SHA-512_ELL2_NU_ suite = edwards25519_XMD:SHA-512_ELL2_NU_ dst = QUUX-V01-CS02-with-edwards25519_XMD:SHA-512_ELL2_NU_ msg = P.x = 1ff2b70ecf862799e11b7ae744e3489aa058ce805dd323a936375a 84695e76da P.y = 222e314d04a4d5725e9f2aff9fb2a6b69ef375a1214eb19021ceab 2d687f0f9b u[0] = 7f3e7fb9428103ad7f52db32f9df32505d7b427d894c5093f7a0f0 374a30641d Q.x = 42836f691d05211ebc65ef8fcf01e0fb6328ec9c4737c26050471e 50803022eb Q.y = 22cb4aaa555e23bd460262d2130d6a3c9207aa8bbb85060928beb2 63d6d42a95 msg = abc Faz-Hernandez, et al. Expires 17 December 2022 [Page 123] Internet-Draft hash-to-curve June 2022 P.x = 5f13cc69c891d86927eb37bd4afc6672360007c63f68a33ab423a3 aa040fd2a8 P.y = 67732d50f9a26f73111dd1ed5dba225614e538599db58ba30aaea1 f5c827fa42 u[0] = 09cfa30ad79bd59456594a0f5d3a76f6b71c6787b04de98be5cd20 1a556e253b Q.x = 333e41b61c6dd43af220c1ac34a3663e1cf537f996bab50ab66e33 c4bd8e4e19 Q.y = 51b6f178eb08c4a782c820e306b82c6e273ab22e258d972cd0c511 787b2a3443 msg = abcdef0123456789 P.x = 1dd2fefce934ecfd7aae6ec998de088d7dd03316aa1847198aecf6 99ba6613f1 P.y = 2f8a6c24dd1adde73909cada6a4a137577b0f179d336685c4a955a 0a8e1a86fb u[0] = 475ccff99225ef90d78cc9338e9f6a6bb7b17607c0c4428937de75 d33edba941 Q.x = 55186c242c78e7d0ec5b6c9553f04c6aeef64e69ec2e824472394d a32647cfc6 Q.y = 5b9ea3c265ee42256a8f724f616307ef38496ef7eba391c08f99f3 bea6fa88f0 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 35fbdc5143e8a97afd3096f2b843e07df72e15bfca2eaf6879bf97 c5d3362f73 P.y = 2af6ff6ef5ebba128b0774f4296cb4c2279a074658b083b8dcca91 f57a603450 u[0] = 049a1c8bd51bcb2aec339f387d1ff51428b88d0763a91bcdf69298 14ac95d03d Q.x = 024b6e1621606dca8071aa97b43dce4040ca78284f2a527dcf5d0f bfac2b07e7 Q.y = 5102353883d739bdc9f8a3af650342b171217167dcce34f8db5720 8ec1dfdbf2 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 6e5e1f37e99345887fc12111575fc1c3e36df4b289b8759d23af14 Faz-Hernandez, et al. Expires 17 December 2022 [Page 124] Internet-Draft hash-to-curve June 2022 d774b66bff P.y = 2c90c3d39eb18ff291d33441b35f3262cdd307162cc97c31bfcc7a 4245891a37 u[0] = 3cb0178a8137cefa5b79a3a57c858d7eeeaa787b2781be4a362a2f 0750d24fa0 Q.x = 3e6368cff6e88a58e250c54bd27d2c989ae9b3acb6067f2651ad28 2ab8c21cd9 Q.y = 38fb39f1566ca118ae6c7af42810c0bb9767ae5960abb5a8ca7925 30bfb9447d J.6. curve448 J.6.1. curve448_XOF:SHAKE256_ELL2_RO_ suite = curve448_XOF:SHAKE256_ELL2_RO_ dst = QUUX-V01-CS02-with-curve448_XOF:SHAKE256_ELL2_RO_ msg = P.x = 5ea5ff623d27c75e73717514134e73e419f831a875ca9e82915fdf c7069d0a9f8b532cfb32b1d8dd04ddeedbe3fa1d0d681c01e825d6 a9ea P.y = afadd8de789f8f8e3516efbbe313a7eba364c939ecba00dabf4ced 5c563b18e70a284c17d8f46b564c4e6ce11784a3825d9411166221 28c1 u[0] = c704c7b3d3b36614cf3eedd0324fe6fe7d1402c50efd16cff89ff6 3f50938506280d3843478c08e24f7842f4e3ef45f6e3c4897f9d97 6148 u[1] = c25427dc97fff7a5ad0a78654e2c6c27b1c1127b5b53c7950cd1fd 6edd2703646b25f341e73deedfebf022d1d3cecd02b93b4d585ead 3ed7 Q0.x = 3ba318806f89c19cc019f51e33eb6b8c038dab892e858ce7c7f2c2 ac58618d06146a5fef31e49af49588d4d3db1bcf02bd4e4a733e37 065d Q0.y = b30b4cfc2fd14d9d4b70456c0f5c6f6070be551788893d570e7955 675a20f6c286d01d6e90d2fb500d2efb8f4e18db7f8268bb9b7fbc 5975 Q1.x = f03a48cf003f63be61ca055fec87c750434da07a15f8aa6210389f f85943b5166484339c8bea1af9fc571313d35ed2fbb779408b760c 4cbd Q1.y = 23943a33b2954dc54b76a8222faf5b7e18405a41f5ecc61bf1b8df 1f9cbfad057307ed0c7b721f19c0390b8ee3a2dec223671f9ff905 fda7 msg = abc P.x = 9b2f7ce34878d7cebf34c582db14958308ea09366d1ec71f646411 d3de0ae564d082b06f40cd30dfc08d9fb7cb21df390cf207806ad9 d0e4 P.y = 138a0eef0a4993ea696152ed7db61f7ddb4e8100573591e7466d61 Faz-Hernandez, et al. Expires 17 December 2022 [Page 125] Internet-Draft hash-to-curve June 2022 c0c568ecaec939e36a84d276f34c402526d8989a96e99760c4869e d633 u[0] = 2dd95593dfee26fe0d218d3d9a0a23d9e1a262fd1d0b602483d084 15213e75e2db3c69b0a5bc89e71bcefc8c723d2b6a0cf263f02ad2 aa70 u[1] = 272e4c79a1290cc6d2bc4f4f9d31bf7fbe956ca303c04518f117d7 7c0e9d850796fc3e1e2bcb9c75e8eaaded5e150333cae993186804 7c9d Q0.x = 26714783887ec444fbade9ae350dc13e8d5a64150679232560726a 73d36e28bd56766d7d0b0899d79c8d1c889ae333f601c57532ff3c 4f09 Q0.y = 080e486f8f5740dbbe82305160cab9fac247b0b22a54d961de6750 37c3036fa68464c8756478c322ae0aeb9ba386fe626cebb0bcca46 840c Q1.x = 0d9741d10421691a8ebc7778b5f623260fdf8b28ae28d776efcb8e 0d5fbb65139a2f828617835f527cb2ca24a8f5fc8e84378343c43d 096d Q1.y = 54f4c499bf3d5b154511913f9615bd914969b65cfb74508d7ae5a1 69e9595b7cbcab9a1485e07b2ce426e4fbed052f03842c4313b7db e39a msg = abcdef0123456789 P.x = f54ecd14b85a50eeeee0618452df3a75be7bfba11da5118774ae4e a55ac204e153f77285d780c4acee6c96abe3577a0c0b00be6e790c f194 P.y = 935247a64bf78c107069943c7e3ecc52acb27ce4a3230407c83573 41685ea2152e8c3da93f8cd77da1bddb5bb759c6e7ae7d516dced4 2850 u[0] = 6aab71a38391639f27e49eae8b1cb6b7172a1f478190ece293957e 7cdb2391e7cc1c4261970d9c1bbf9c3915438f74fbd7eb5cd4d4d1 7ace u[1] = c80b8380ca47a3bcbf76caa75cef0e09f3d270d5ee8f676cde11ae df41aaca6741bd81a86232bd336ccb42efad39f06542bc06a67b65 909e Q0.x = 946d91bd50c90ef70743e0dd194bddd68bb630f4e67e5b93e15a9b 94e62cb85134467993501759525c1f4fdbf06f10ddaf817847d735 e062 Q0.y = 185cf511262ec1e9b3c3cbdc015ab93df4e71cbe87766917d81c9f 3419d480407c1462385122c84982d4dae60c3ae4acce0089e37ad6 5934 Q1.x = 01778f4797b717cd6f83c193b2dfb92a1606a36ede941b0f6ab0ac 71ad0eac756d17604bf054398887da907e41065d3595f178ae802f 2087 Q1.y = b4ca727d0bda895e0eee7eb3cbc28710fa2e90a73b568cae26bd7c 2e73b70a9fa0affe1096f0810198890ed65d8935886b6e60dc4c56 9dc6 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq Faz-Hernandez, et al. Expires 17 December 2022 [Page 126] Internet-Draft hash-to-curve June 2022 qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 5bd67c4f88adf6beb10f7e0d0054659776a55c97b809ec8b310172 9e104fd0f684e103792f267fd87cc4afc25a073956ef4f268fb028 24d5 P.y = da1f5cb16a352719e4cb064cf47ba72aeba7752d03e8ca2c56229f 419b4ef378785a5af1a53dd7ab4d467c1f92f7b139b3752faf29c9 6432 u[0] = cb5c27e51f9c18ee8ffdb6be230f4eb4f2c2481963b2293484f08d a2241c1ff59f80978e6defe9d70e34abba2fcbe12dc3a1eb2c5d3d 2e4a u[1] = c895e8afecec5466e126fa70fc4aa784b8009063afb10e3ee06a9b 22318256aa8693b0c85b955cf2d6540b8ed71e729af1b8d5ca3b11 6cd7 Q0.x = c2d275826d6ad55e41a22318f6b6240f1f862a2e231120ff41eadb ec319756032e8cef2a7ac6c10214fa0608c17fcaf61ec2694a8a2b 358b Q0.y = 93d2e092762b135509840e609d413200df800d99da91d8b8284066 6cac30e7a3520adbaa4b089bfdc86132e42729f651d022f4782502 f12c Q1.x = 3c0880ece7244036e9a45944a85599f9809d772f770cc237ac41b2 1aa71615e4f3bb08f64fca618896e4f6cf5bd92e16b89d2cf6e195 6bfb Q1.y = 45cce4beb96505cac5976b3d2673641e9bcd18d3462bbb453d293e 5282740a6389cfeae610adc7bd425c728541ceec83fcc999164af4 3fb5 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = ea441c10b3636ecedd5c0dfcae96384cc40de8390a0ab648765b45 08da12c586d55dc981275776507ebca0e4d1bcaa302bb69dcfa31b 3451 P.y = fee0192d49bcc0c28d954763c2cbe739b9265c4bebe3883803c649 71220cfda60b9ac99ad986cd908c0534b260b5cfca46f6c2b0f3f2 1bda u[0] = 8cba93a007bb2c801b1769e026b1fa1640b14a34cf3029db3c7fd6 392745d6fec0f7870b5071d6da4402cedbbde28ae4e50ab30e1049 a238 u[1] = 4223746145069e4b8a981acc3404259d1a2c3ecfed5d864798a89d 45f81a2c59e2d40eb1d5f0fe11478cbb2bb30246dd388cb932ad7b Faz-Hernandez, et al. Expires 17 December 2022 [Page 127] Internet-Draft hash-to-curve June 2022 b330 Q0.x = 4321ab02a9849128691e9b80a5c5576793a218de14885fddccb91f 17ceb1646ea00a28b69ad211e1f14f17739612dbde3782319bdf00 9689 Q0.y = 1b8a7b539519eec0ea9f7a46a43822e16cba39a439733d6847ac44 a806b8adb3e1a75ea48a1228b8937ba85c6cb6ee01046e10cad895 3b1e Q1.x = 126d744da6a14fddec0f78a9cee4571c1320ac7645b600187812e4 d7021f98fc4703732c54daec787206e1f34d9dbbf4b292c68160b8 bfbd Q1.y = 136eebe6020f2389d448923899a1a38a4c8ad74254e0686e91c4f9 3c1f8f8e1bd619ffb7c1281467882a9c957d22d50f65c5b72b2aee 11af J.6.2. curve448_XOF:SHAKE256_ELL2_NU_ suite = curve448_XOF:SHAKE256_ELL2_NU_ dst = QUUX-V01-CS02-with-curve448_XOF:SHAKE256_ELL2_NU_ msg = P.x = b65e8dbb279fd656f926f68d463b13ca7a982b32f5da9c7cc58afc f6199e4729863fb75ca9ae3c95c6887d95a5102637a1c5c40ff0aa fadc P.y = ea1ea211cf29eca11c057fe8248181591a19f6ac51d45843a65d4b b8b71bc83a64c771ed7686218a278ef1c5d620f3d26b5316218864 5453 u[0] = 242c70f74eac8184116c71630d284cf8a742fc463e710545847ff6 4d8e9161cb9f599728a18a32dbd8b67c3bec5d64c9b1d2f2cde7b5 888d Q.x = e6304424de5af3f556d3e645600530c53ad949891c3e60ba041dd5 f68a93901beff8440164477d348c13d28e27bfcd360c44c80b4c7d 4cea Q.y = 4160a8f2043a347185406a6a7e50973b98b82edbdfa3209b0e1c90 118e10eeb45045b0990d4b2b0708a30eca17df40ad53c9100f20c1 0b44 msg = abc P.x = 51aceca4fa95854bbaba58d8a5e17a86c07acadef32e1188cafda2 6232131800002cc2f27c7aec454e5e0c615bddffb7df6a5f7f0f14 793f P.y = c590c9246eb28b08dee816d608ef233ea5d76e305dc458774a1e1b d880387e6734219e2018e4aa50a49486dce0ba8740065da37e6cf5 212c u[0] = ef6dcb75b696d325fb36d66b104700df1480c4c17ea9190d447eee 1e7e4c9b7f36bbfb8ba7ba7c4cb6b07fed16531c1ac7a26a3618b4 0b34 Q.x = de0dc93df9ce7953452f20e270699c1e7dacd5d571c226d77f53b7 e3053d16f8a81b1601efb362054e973c8e733b663af93f00cb81ba Faz-Hernandez, et al. Expires 17 December 2022 [Page 128] Internet-Draft hash-to-curve June 2022 f130 Q.y = 8c5bdec6fa6690905f6eff966b0f98f5a8161493bd04976684d4ec 1f4512fa8743d86860b2ff2c5d67e9c145fd906f2cb89ff812c6b9 883f msg = abcdef0123456789 P.x = c6d65987f146b8d0cb5d2c44e1872ac3af1f458f6a8bd8c232ffe8 b9d09496229a5a27f350eb7d97305bcc4e0f38328718352e8e3129 ed71 P.y = 4d2f901bf333fdc4135b954f20d59207e9f6a4ecf88ce5af11c892 b44f79766ec4ecc9f60d669b95ca8940f39b1b7044140ac2040c1b f659 u[0] = 3012ba5d9b3bb648e4613833a26ecaeadb3e8c8bba07fc90ac3da0 375769289c44d3dc87474b23df7f45f9a4030892cda689e343aeee a6ad Q.x = dc29532761f03c24d57f530da4c24acc4c676d185becaa89fcc083 266541fb7f10ecec91dac64a34cd988274633ae25c4d784aee52de 47a8 Q.y = a5f6da11259c69f2e07fce6a7b6afec4c25bd2df83426765f9c070 4111da24c6a0550d5c7aac7d648d55f7640d50be99c926195e852a daac msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 9b8d008863beb4a02fb9e4efefd2eba867307fb1c7ce01746115d3 2e1db551bb254e8e3e4532d5c74a83949a69a60519ecc9178083cb e943 P.y = 346a1fca454d1e67c628437c270ec0f0c4256bb774fe6c0e49de70 04ff6d9199e2cd99d8f7575a96aafc4dc8db1811ba0a44317581f4 1371 u[0] = fe952ac0149f92436bba12ea2e542aa226f4fc074d79ff462c41b3 27968a649a495a8a93b6c3044af2273456abb5e166ce4fb8c9b10c 8c2e Q.x = 512803d89f59c57376e6570cd54c4e901643e089cd9456f549daa4 372b8b52679860b68aa8bedfaa88970f15ab6098d5f252083ac98a 58c9 Q.y = 3d9b6593c7941a20d76161c9a171f1e507495a08f03dfcae33a2ac 3602698e46a74d1039b583c984036f590eaa43d20ba5aada3ffb55 2f77 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Faz-Hernandez, et al. Expires 17 December 2022 [Page 129] Internet-Draft hash-to-curve June 2022 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 8746dc34799112d1f20acda9d7f722c9abb29b1fb6b7e9e5669838 43c20bd7c9bfad21b45c5166b808d2f5d44e188f1fdaf29cdee8a7 2e4c P.y = 7c1293484c9287c298a1a0600c64347eee8530acf563cd8705e057 28274d8cd8101835f8003b6f3b78b5beb28f5be188a3d7bce1ec5a 36b1 u[0] = afd3d7ad9d819be7561706e050d4f30b634b203387ab682739365f 62cd7393ca2cf18cd07a3d3af8dd163f043ac7457c2eb145b4a561 70a9 Q.x = 08aed6480793218034fd3b3b0867943d7e0bd1b6f76b4929e0885b d082b84d4449341da6038bb08229ad9eb7d518dff2c7ea50148e70 a4db Q.y = e00d32244561ebd4b5f4ef70fcac75a06416be0a1c1b304e7bd361 a6a6586915bb902a323eaf73cf7738e70d34282f61485395ab2833 d2c1 J.7. edwards448 J.7.1. edwards448_XOF:SHAKE256_ELL2_RO_ suite = edwards448_XOF:SHAKE256_ELL2_RO_ dst = QUUX-V01-CS02-with-edwards448_XOF:SHAKE256_ELL2_RO_ msg = P.x = 73036d4a88949c032f01507005c133884e2f0d81f9a950826245dd a9e844fc78186c39daaa7147ead3e462cff60e9c6340b58134480b 4d17 P.y = 94c1d61b43728e5d784ef4fcb1f38e1075f3aef5e99866911de5a2 34f1aafdc26b554344742e6ba0420b71b298671bbeb2b773661863 4610 u[0] = 0847c5ebf957d3370b1f98fde499fb3e659996d9fc9b5707176ade 785ba72cd84b8a5597c12b1024be5f510fa5ba99642c4cec7f3f69 d3e7 u[1] = f8cbd8a7ae8c8deed071f3ac4b93e7cfcb8f1eac1645d699fd6d38 81cb295a5d3006d9449ed7cad412a77a1fe61e84a9e41d59ef384d 6f9a Q0.x = c08177330869db17fb81a5e6e53b36d29086d806269760f2e4caba a4015f5dbadb7ca2ba594d96a89d0ca4f0944489e1ef393d53db85 096f Q0.y = 02e894598c050eeb7195f5791f1a5f65da3776b7534be37640bcbf 95d4b915bd22333c50387583507169708fbd7bea0d7aa385dcc614 be9c Q1.x = 770877fd3b6c5503398157b68a9d3609f585f40e1ebebdd69bb0e4 d3d9aa811995ce75333fdadfa50db886a35959cc59cffd5c9710da ca25 Faz-Hernandez, et al. Expires 17 December 2022 [Page 130] Internet-Draft hash-to-curve June 2022 Q1.y = b27fef77aa6231fbbc27538fa90eaca8abd03eb1e62fdae4ec5e82 8117c3b8b3ff8c34d0a6e6d79fff16d339b94ae8ede33331d5b464 c792 msg = abc P.x = 4e0158acacffa545adb818a6ed8e0b870e6abc24dfc1dc45cf9a05 2e98469275d9ff0c168d6a5ac7ec05b742412ee090581f12aa398f 9f8c P.y = 894d3fa437b2d2e28cdc3bfaade035430f350ec5239b6b406b5501 da6f6d6210ff26719cad83b63e97ab26a12df6dec851d6bf38e294 af9a u[0] = 04d975cd938ab49be3e81703d6a57cca84ed80d2ff6d4756d3f229 47fb5b70ab0231f0087cbfb4b7cae73b41b0c9396b356a4831d9a1 4322 u[1] = 2547ca887ac3db7b5fad3a098aa476e90078afe1358af6c63d677d 6edfd2100bc004e0f5db94dd2560fc5b308e223241d00488c9ca6b 0ef2 Q0.x = 7544612a97f4419c94ab0f621a1ee8ccf46c6657b8e0778ec9718b f4b41bc774487ad87d9b1e617aa49d3a4dd35a3cf57cd390ebf042 9952 Q0.y = d3ab703e60267d796b485bb58a28f934bd0133a6d1bbdfeda5277f a293310be262d7f653a5adffa608c37ed45c0e6008e54a16e1a342 e4df Q1.x = 6262f18d064bc131ade1b8bbcf1cbdf984f4f88153fcc9f94c888a f35d5e41aae84c12f169a55d8abf06e6de6c5b23079e587a58cf73 303e Q1.y = 6d57589e901abe7d947c93ab02c307ad9093ed9a83eb0b6e829fb7 318d590381ca25f3cc628a36a924a9ddfcf3cbedf94edf3b338ea7 7403 msg = abcdef0123456789 P.x = 2c25b4503fadc94b27391933b557abdecc601c13ed51c5de683894 84f93dbd6c22e5f962d9babf7a39f39f994312f8ca23344847e1fb f176 P.y = d5e6f5350f430e53a110f5ac7fcc82a96cb865aeca982029522d32 601e41c042a9dfbdfbefa2b0bdcdc3bc58cca8a7cd546803083d3a 8548 u[0] = 10659ce25588db4e4be6f7c791a79eb21a7f24aaaca76a6ca3b83b 80aaf95aa328fe7d569a1ac99f9cd216edf3915d72632f1a8b990e 250c u[1] = 9243e5b6c480683fd533e81f4a778349a309ce00bd163a29eb9fa8 dbc8f549242bef33e030db21cffacd408d2c4264b93e476c6a8590 e7aa Q0.x = 1457b60c12e00e47ceb3ce64b57e7c3c61636475443d704a8e2b2a b0a5ac7e4b3909435416784e16e19929c653b1bdcd9478a8e5331c a9ae Q0.y = 935d9f75f7a0babbc39c0a1c3b412518ed8a24bc2c4886722fb4b7 d4a747af98e4e2528c75221e2dffd3424abb436e10539a74caaafa Faz-Hernandez, et al. Expires 17 December 2022 [Page 131] Internet-Draft hash-to-curve June 2022 3ea3 Q1.x = b44d9e34211b4028f24117e856585ed81448f3c8b934987a1c5939 c86048737a08d85934fec6b3c2ef9f09cbd365cf22744f2e4ce697 62a4 Q1.y = dc996c1736f4319868f897d9a27c45b02dd3bc6b7ca356a039606e 5406e131a0bbe8238208b327b00853e8af84b58b13443e70542556 3323 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = a1861a9464ae31249a0e60bf38791f3663049a3f5378998499a832 92e159a2fecff838eb9bc6939e5c6ae76eb074ad4aae39b55b72ca 0b9a P.y = 580a2798c5b904f8adfec5bd29fb49b4633cd9f8c2935eb4a0f12e 5dfa0285680880296bb729c6405337525fb5ed3dff930c137314f6 0401 u[0] = c80390020e578f009ead417029eff6cd0926110922db63ab98395e 3bdfdd5d8a65b1a2b8d495dc8c5e59b7f3518731f7dfc0f93ace5d ee4b u[1] = 1c4dc6653a445bbef2add81d8e90a6c8591a788deb91d0d3f1519a 2e4a460313041b77c1b0817f2e80b388e5c3e49f37d787dc1f85e4 324a Q0.x = 9d355251e245e4b13ed4ea3e5a3c55bf9b7211f1704771f2e1d8f1 a65610c468b1cf70c6c2ce30dcaad54ad9e5439471ec554b862ec8 875a Q0.y = 6689ba36a242af69ac2aadb955d15e982d9b04f5d77f7609ebf742 9587feb7e5ce27490b9c72114509f89565122074e46a614d7fd7c8 00bd Q1.x = c4b3d3ad4d2d62739a62989532992c1081e9474a201085b4616da5 706cab824693b9fb428a201bcd1639a4588cc43b9eb841dbca7421 9b1f Q1.y = 265286f5dee8f3d894b5649da8565b58e96b4cfd44b462a2883ea6 4dbcda21a00706ea3fea53fc2d769084b0b74589e91d0384d71189 09fb msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 987c5ac19dd4b47835466a50b2d9feba7c8491b8885a04edf577e1 5a9f2c98b203ec2cd3e5390b3d20bba0fa6fc3eecefb5029a31723 Faz-Hernandez, et al. Expires 17 December 2022 [Page 132] Internet-Draft hash-to-curve June 2022 4401 P.y = 5e273fcfff6b007bb6771e90509275a71ff1480c459ded26fc7b10 664db0a68aaa98bc7ecb07e49cf05b80ae5ac653fbdd14276bbd35 ccbc u[0] = 163c79ab0210a4b5e4f44fb19437ea965bf5431ab233ef16606f0b 03c5f16a3feb7d46a5a675ce8f606e9c2bf74ee5336c54a1e54919 f13f u[1] = f99666bde4995c4088333d6c2734687e815f80a99c6da02c47df4b 51f6c9d9ed466b4fecf7d9884990a8e0d0be6907fa437e0b1a27f4 9265 Q0.x = d1a5eba4a332514b69760948af09ceaeddbbb9fd4cb1f19b78349c 2ee4cf9ee86dbcf9064659a4a0566fe9c34d90aec86f0801edc131 ad9b Q0.y = 5d0a75a3014c3269c33b1b5da80706a4f097893461df286353484d 8031cd607c98edc2a846c77a841f057c7251eb45077853c7b20595 7e52 Q1.x = 69583b00dc6b2aced6ffa44630cc8c8cd0dd0649f57588dd0fb1da ad2ce132e281d01e3f25ccd3f405be759975c6484268bfe8f5e5f2 3c30 Q1.y = 8418484035f60bdccf48cb488634c2dfb40272123435f7e654fb6f 254c6c42e7e38f1fa79a637a168a28de6c275232b704f9ded0ff76 dd94 J.7.2. edwards448_XOF:SHAKE256_ELL2_NU_ suite = edwards448_XOF:SHAKE256_ELL2_NU_ dst = QUUX-V01-CS02-with-edwards448_XOF:SHAKE256_ELL2_NU_ msg = P.x = eb5a1fc376fd73230af2de0f3374087cc7f279f0460114cf0a6c12 d6d044c16de34ec2350c34b26bf110377655ab77936869d085406a f71e P.y = df5dcea6d42e8f494b279a500d09e895d26ac703d75ca6d118e8ca 58bf6f608a2a383f292fce1563ff995dce75aede1fdc8e7c0c737a e9ad u[0] = 1368aefc0416867ea2cfc515416bcbeecc9ec81c4ecbd52ccdb91e 06996b3f359bc930eef6743c7a2dd7adb785bc7093ed044efed950 86d7 Q.x = 4b2abf8c0fca49d027c2a81bf73bb5990e05f3e76c7ba137cc0b89 415ccd55ce7f191cc0c11b0560c1cdc2a8085dd56996079e05a3cd 8dde Q.y = 82532f5b0cb3bfb8542d3228d055bfe61129dbeae8bace80cf61f1 7725e8ec8226a24f0e687f78f01da88e3b2715194a03dca7c0a96b bf04 msg = abc P.x = 4623a64bceaba3202df76cd8b6e3daf70164f3fcbda6d6e340f7fa b5cdf89140d955f722524f5fe4d968fef6ba2853ff4ea086c2f67d Faz-Hernandez, et al. Expires 17 December 2022 [Page 133] Internet-Draft hash-to-curve June 2022 8110 P.y = abaac321a169761a8802ab5b5d10061fec1a83c670ac6bc9595470 0317ee5f82870120e0e2c5a21b12a0c7ad17ebd343363604c4bcec afd1 u[0] = cda3b0ecfe054c4077007d7300969ec24f4c741300b630ec9188eb ab31a5ae0065612ee22d9f793733179ffc2e10c53ca5b539057aaf dc2f Q.x = b1ca5bef2f157673a210f56c9b0039db8399e4749585abac64f831 f74ed1ec5f591928976c687c06d57686bacb98440e77af878349cd f2d2 Q.y = 5bbfd6a3730d517b03c3cd9e2eed94af12891334ec090e0495c2ed c588e9e10b6f63b03a62076808cbcd6da95adfb5af76c136b2d42e 0dac msg = abcdef0123456789 P.x = e9eb562e76db093baa43a31b7edd04ec4aadcef3389a7b9c58a19c f87f8ae3d154e134b6b3ed45847a741e33df51903da681629a4b8b cc2e P.y = 0cf6606927ad7eb15dbc193993bc7e4dda744b311a8ec4274c8f73 8f74f605934582474c79260f60280fe35bd37d4347e59184cbfa12 cbc4 u[0] = d36bae98351512c382c7a3e1eba22497574f11fef9867901b1a270 0b39fa2cd0d38ed4380387a99162b7ba0240c743f0532ef60d577c 413d Q.x = 958a51e2f02e0dfd3930709010d5d16f869adb9d8a8f7c01139911 d206c20cdb7bfb40ee33ba30536a99f49362fa7633d0f417fc3914 fe21 Q.y = f4307a36ab6612fa97501497f01afa109733ce85875935551c3ca9 0f0fa7e0097a8640bb7e5dbcc38ab32b23b748790f2261f2c44c3b f3ba msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 122a3234d34b26c69749f23356452bf9501efa2d94859d5ef741fe f024156d9d191a03a2ad24c38186f93e02d05572575968b083d8a3 9738 P.y = ddf55e74eb4414c2c1fa4aa6bc37c4ab470a3fed6bb5af1e435703 09b162fb61879bb15f9ea49c712efd42d0a71666430f9f0d4a2050 5050 u[0] = 5945744d27122f89da3daf76ab4db9616053df64e25d30ec9a0066 7ee6710240579c1db8f8ef3386f3f4f413cfb325ac14094d582026 a971 Q.x = e7e1f2d13548ac2c8fcd346e4c63606545bf93652011721e83ac3b 64226f77a8823d3881e164bc6ca45505b236e8e3721c028052fcc9 ade5 Q.y = 7e0f340501bf25f018b9d374c2acbdd43c07261d85a6ef3c855113 d4e023634db59a87b8fab9efe04ed1fee302c8a4994e83bdda32bd Faz-Hernandez, et al. Expires 17 December 2022 [Page 134] Internet-Draft hash-to-curve June 2022 9c0b msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 221704949b1ce1ab8dd174dc9b8c56fcffa27179569ce9219c0c2f e183d3d23343a4c42a0e2e9d6b9d0feb1df3883ec489b6671d1fa6 4089 P.y = ebdecfdc87142d1a919034bf22ecfad934c9a85effff14b594ae2c 00943ca62a39d6ee3be9df0bb504ce8a9e1669bc6959c42ad6a1d3 b686 u[0] = 1192e378043f01cedc7ea0209321519213b0184ea0d8575816bcd9 182a367823e1eecc2faf1df8f79b24027a4b9bfa208cd320e79bef 06ea Q.x = 0fd3bb833c1d7a5b319d1d4117406a23b9aece976186ecb18a11a6 35e6fbdb920d47e04762b1f2a8c59d2f8435d0fdefe501f544cda2 3dbf Q.y = f13b0dad4d5eeb120f2443ac4392f8096a1396f5014ec2a3506a34 7fef8076a7282035cf619599b1919cf29df5ce87711c11688aab77 00a6 J.8. secp256k1 J.8.1. secp256k1_XMD:SHA-256_SSWU_RO_ suite = secp256k1_XMD:SHA-256_SSWU_RO_ dst = QUUX-V01-CS02-with-secp256k1_XMD:SHA-256_SSWU_RO_ msg = P.x = c1cae290e291aee617ebaef1be6d73861479c48b841eaba9b7b585 2ddfeb1346 P.y = 64fa678e07ae116126f08b022a94af6de15985c996c3a91b64c406 a960e51067 u[0] = 6b0f9910dd2ba71c78f2ee9f04d73b5f4c5f7fc773a701abea1e57 3cab002fb3 u[1] = 1ae6c212e08fe1a5937f6202f929a2cc8ef4ee5b9782db68b0d579 9fd8f09e16 Q0.x = 74519ef88b32b425a095e4ebcc84d81b64e9e2c2675340a720bb1a 1857b99f1e Q0.y = c174fa322ab7c192e11748beed45b508e9fdb1ce046dee9c2cd3a2 a86b410936 Faz-Hernandez, et al. Expires 17 December 2022 [Page 135] Internet-Draft hash-to-curve June 2022 Q1.x = 44548adb1b399263ded3510554d28b4bead34b8cf9a37b4bd0bd2b a4db87ae63 Q1.y = 96eb8e2faf05e368efe5957c6167001760233e6dd2487516b46ae7 25c4cce0c6 msg = abc P.x = 3377e01eab42db296b512293120c6cee72b6ecf9f9205760bd9ff1 1fb3cb2c4b P.y = 7f95890f33efebd1044d382a01b1bee0900fb6116f94688d487c6c 7b9c8371f6 u[0] = 128aab5d3679a1f7601e3bdf94ced1f43e491f544767e18a4873f3 97b08a2b61 u[1] = 5897b65da3b595a813d0fdcc75c895dc531be76a03518b044daaa0 f2e4689e00 Q0.x = 07dd9432d426845fb19857d1b3a91722436604ccbbbadad8523b8f c38a5322d7 Q0.y = 604588ef5138cffe3277bbd590b8550bcbe0e523bbaf1bed4014a4 67122eb33f Q1.x = e9ef9794d15d4e77dde751e06c182782046b8dac05f8491eb88764 fc65321f78 Q1.y = cb07ce53670d5314bf236ee2c871455c562dd76314aa41f012919f e8e7f717b3 msg = abcdef0123456789 P.x = bac54083f293f1fe08e4a70137260aa90783a5cb84d3f35848b324 d0674b0e3a P.y = 4436476085d4c3c4508b60fcf4389c40176adce756b398bdee27bc a19758d828 u[0] = ea67a7c02f2cd5d8b87715c169d055a22520f74daeb080e6180958 380e2f98b9 u[1] = 7434d0d1a500d38380d1f9615c021857ac8d546925f5f2355319d8 23a478da18 Q0.x = 576d43ab0260275adf11af990d130a5752704f7947862876172080 8862544b5d Q0.y = 643c4a7fb68ae6cff55edd66b809087434bbaff0c07f3f9ec4d49b b3c16623c3 Q1.x = f89d6d261a5e00fe5cf45e827b507643e67c2a947a20fd9ad71039 f8b0e29ff8 Q1.y = b33855e0cc34a9176ead91c6c3acb1aacb1ce936d563bc1cee1dcf fc806caf57 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = e2167bc785333a37aa562f021f1e881defb853839babf52a7f72b1 02e41890e9 P.y = f2401dd95cc35867ffed4f367cd564763719fbc6a53e969fb8496a 1e6685d873 Faz-Hernandez, et al. Expires 17 December 2022 [Page 136] Internet-Draft hash-to-curve June 2022 u[0] = eda89a5024fac0a8207a87e8cc4e85aa3bce10745d501a30deb873 41b05bcdf5 u[1] = dfe78cd116818fc2c16f3837fedbe2639fab012c407eac9dfe9245 bf650ac51d Q0.x = 9c91513ccfe9520c9c645588dff5f9b4e92eaf6ad4ab6f1cd720d1 92eb58247a Q0.y = c7371dcd0134412f221e386f8d68f49e7fa36f9037676e163d4a06 3fbf8a1fb8 Q1.x = 10fee3284d7be6bd5912503b972fc52bf4761f47141a0015f1c6ae 36848d869b Q1.y = 0b163d9b4bf21887364332be3eff3c870fa053cf508732900fc69a 6eb0e1b672 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = e3c8d35aaaf0b9b647e88a0a0a7ee5d5bed5ad38238152e4e6fd8c 1f8cb7c998 P.y = 8446eeb6181bf12f56a9d24e262221cc2f0c4725c7e3803024b588 8ee5823aa6 u[0] = 8d862e7e7e23d7843fe16d811d46d7e6480127a6b78838c277bca1 7df6900e9f u[1] = 68071d2530f040f081ba818d3c7188a94c900586761e9115efa47a e9bd847938 Q0.x = b32b0ab55977b936f1e93fdc68cec775e13245e161dbfe556bbb1f 72799b4181 Q0.y = 2f5317098360b722f132d7156a94822641b615c91f8663be691698 70a12af9e8 Q1.x = 148f98780f19388b9fa93e7dc567b5a673e5fca7079cd9cdafd719 82ec4c5e12 Q1.y = 3989645d83a433bc0c001f3dac29af861f33a6fd1e04f4b36873f5 bff497298a J.8.2. secp256k1_XMD:SHA-256_SSWU_NU_ suite = secp256k1_XMD:SHA-256_SSWU_NU_ dst = QUUX-V01-CS02-with-secp256k1_XMD:SHA-256_SSWU_NU_ msg = P.x = a4792346075feae77ac3b30026f99c1441b4ecf666ded19b7522cf 65c4c55c5b Faz-Hernandez, et al. Expires 17 December 2022 [Page 137] Internet-Draft hash-to-curve June 2022 P.y = 62c59e2a6aeed1b23be5883e833912b08ba06be7f57c0e9cdc663f 31639ff3a7 u[0] = 0137fcd23bc3da962e8808f97474d097a6c8aa2881fceef4514173 635872cf3b Q.x = a4792346075feae77ac3b30026f99c1441b4ecf666ded19b7522cf 65c4c55c5b Q.y = 62c59e2a6aeed1b23be5883e833912b08ba06be7f57c0e9cdc663f 31639ff3a7 msg = abc P.x = 3f3b5842033fff837d504bb4ce2a372bfeadbdbd84a1d2b678b6e1 d7ee426b9d P.y = 902910d1fef15d8ae2006fc84f2a5a7bda0e0407dc913062c3a493 c4f5d876a5 u[0] = e03f894b4d7caf1a50d6aa45cac27412c8867a25489e32c5ddeb50 3229f63a2e Q.x = 3f3b5842033fff837d504bb4ce2a372bfeadbdbd84a1d2b678b6e1 d7ee426b9d Q.y = 902910d1fef15d8ae2006fc84f2a5a7bda0e0407dc913062c3a493 c4f5d876a5 msg = abcdef0123456789 P.x = 07644fa6281c694709f53bdd21bed94dab995671e4a8cd1904ec4a a50c59bfdf P.y = c79f8d1dad79b6540426922f7fbc9579c3018dafeffcd4552b1626 b506c21e7b u[0] = e7a6525ae7069ff43498f7f508b41c57f80563c1fe4283510b3224 46f32af41b Q.x = 07644fa6281c694709f53bdd21bed94dab995671e4a8cd1904ec4a a50c59bfdf Q.y = c79f8d1dad79b6540426922f7fbc9579c3018dafeffcd4552b1626 b506c21e7b msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = b734f05e9b9709ab631d960fa26d669c4aeaea64ae62004b9d34f4 83aa9acc33 P.y = 03fc8a4a5a78632e2eb4d8460d69ff33c1d72574b79a35e402e801 f2d0b1d6ee u[0] = d97cf3d176a2f26b9614a704d7d434739d194226a706c886c5c3c3 9806bc323c Q.x = b734f05e9b9709ab631d960fa26d669c4aeaea64ae62004b9d34f4 83aa9acc33 Q.y = 03fc8a4a5a78632e2eb4d8460d69ff33c1d72574b79a35e402e801 f2d0b1d6ee msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Faz-Hernandez, et al. Expires 17 December 2022 [Page 138] Internet-Draft hash-to-curve June 2022 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 17d22b867658977b5002dbe8d0ee70a8cfddec3eec50fb93f36136 070fd9fa6c P.y = e9178ff02f4dab73480f8dd590328aea99856a7b6cc8e5a6cdf289 ecc2a51718 u[0] = a9ffbeee1d6e41ac33c248fb3364612ff591b502386c1bf6ac4aaf 1ea51f8c3b Q.x = 17d22b867658977b5002dbe8d0ee70a8cfddec3eec50fb93f36136 070fd9fa6c Q.y = e9178ff02f4dab73480f8dd590328aea99856a7b6cc8e5a6cdf289 ecc2a51718 J.9. BLS12-381 G1 J.9.1. BLS12381G1_XMD:SHA-256_SSWU_RO_ suite = BLS12381G1_XMD:SHA-256_SSWU_RO_ dst = QUUX-V01-CS02-with-BLS12381G1_XMD:SHA-256_SSWU_RO_ msg = P.x = 052926add2207b76ca4fa57a8734416c8dc95e24501772c8142787 00eed6d1e4e8cf62d9c09db0fac349612b759e79a1 P.y = 08ba738453bfed09cb546dbb0783dbb3a5f1f566ed67bb6be0e8c6 7e2e81a4cc68ee29813bb7994998f3eae0c9c6a265 u[0] = 0ba14bd907ad64a016293ee7c2d276b8eae71f25a4b941eece7b0d 89f17f75cb3ae5438a614fb61d6835ad59f29c564f u[1] = 019b9bd7979f12657976de2884c7cce192b82c177c80e0ec604436 a7f538d231552f0d96d9f7babe5fa3b19b3ff25ac9 Q0.x = 11a3cce7e1d90975990066b2f2643b9540fa40d6137780df4e753a 8054d07580db3b7f1f03396333d4a359d1fe3766fe Q0.y = 0eeaf6d794e479e270da10fdaf768db4c96b650a74518fc67b04b0 3927754bac66f3ac720404f339ecdcc028afa091b7 Q1.x = 160003aaf1632b13396dbad518effa00fff532f604de1a7fc2082f f4cb0afa2d63b2c32da1bef2bf6c5ca62dc6b72f9c Q1.y = 0d8bb2d14e20cf9f6036152ed386d79189415b6d015a20133acb4e 019139b94e9c146aaad5817f866c95d609a361735e msg = abc P.x = 03567bc5ef9c690c2ab2ecdf6a96ef1c139cc0b2f284dca0a9a794 3388a49a3aee664ba5379a7655d3c68900be2f6903 Faz-Hernandez, et al. Expires 17 December 2022 [Page 139] Internet-Draft hash-to-curve June 2022 P.y = 0b9c15f3fe6e5cf4211f346271d7b01c8f3b28be689c8429c85b67 af215533311f0b8dfaaa154fa6b88176c229f2885d u[0] = 0d921c33f2bad966478a03ca35d05719bdf92d347557ea166e5bba 579eea9b83e9afa5c088573c2281410369fbd32951 u[1] = 003574a00b109ada2f26a37a91f9d1e740dffd8d69ec0c35e1e9f4 652c7dba61123e9dd2e76c655d956e2b3462611139 Q0.x = 125435adce8e1cbd1c803e7123f45392dc6e326d292499c2c45c58 65985fd74fe8f042ecdeeec5ecac80680d04317d80 Q0.y = 0e8828948c989126595ee30e4f7c931cbd6f4570735624fd25aef2 fa41d3f79cfb4b4ee7b7e55a8ce013af2a5ba20bf2 Q1.x = 11def93719829ecda3b46aa8c31fc3ac9c34b428982b898369608e 4f042babee6c77ab9218aad5c87ba785481eff8ae4 Q1.y = 0007c9cef122ccf2efd233d6eb9bfc680aa276652b0661f4f820a6 53cec1db7ff69899f8e52b8e92b025a12c822a6ce6 msg = abcdef0123456789 P.x = 11e0b079dea29a68f0383ee94fed1b940995272407e3bb916bbf26 8c263ddd57a6a27200a784cbc248e84f357ce82d98 P.y = 03a87ae2caf14e8ee52e51fa2ed8eefe80f02457004ba4d486d6aa 1f517c0889501dc7413753f9599b099ebcbbd2d709 u[0] = 062d1865eb80ebfa73dcfc45db1ad4266b9f3a93219976a3790ab8 d52d3e5f1e62f3b01795e36834b17b70e7b76246d4 u[1] = 0cdc3e2f271f29c4ff75020857ce6c5d36008c9b48385ea2f2bf6f 96f428a3deb798aa033cd482d1cdc8b30178b08e3a Q0.x = 08834484878c217682f6d09a4b51444802fdba3d7f2df9903a0dda db92130ebbfa807fffa0eabf257d7b48272410afff Q0.y = 0b318f7ecf77f45a0f038e62d7098221d2dbbca2a394164e2e3fe9 53dc714ac2cde412d8f2d7f0c03b259e6795a2508e Q1.x = 158418ed6b27e2549f05531a8281b5822b31c3bf3144277fbb977f 8d6e2694fedceb7011b3c2b192f23e2a44b2bd106e Q1.y = 1879074f344471fac5f839e2b4920789643c075792bec5af4282c7 3f7941cda5aa77b00085eb10e206171b9787c4169f msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 15f68eaa693b95ccb85215dc65fa81038d69629f70aeee0d0f677c f22285e7bf58d7cb86eefe8f2e9bc3f8cb84fac488 P.y = 1807a1d50c29f430b8cafc4f8638dfeeadf51211e1602a5f184443 076715f91bb90a48ba1e370edce6ae1062f5e6dd38 u[0] = 010476f6a060453c0b1ad0b628f3e57c23039ee16eea5e71bb87c3 b5419b1255dc0e5883322e563b84a29543823c0e86 u[1] = 0b1a912064fb0554b180e07af7e787f1f883a0470759c03c1b6509 eb8ce980d1670305ae7b928226bb58fdc0a419f46e Q0.x = 0cbd7f84ad2c99643fea7a7ac8f52d63d66cefa06d9a56148e58b9 84b3dd25e1f41ff47154543343949c64f88d48a710 Q0.y = 052c00e4ed52d000d94881a5638ae9274d3efc8bc77bc0e5c650de 04a000b2c334a9e80b85282a00f3148dfdface0865 Faz-Hernandez, et al. Expires 17 December 2022 [Page 140] Internet-Draft hash-to-curve June 2022 Q1.x = 06493fb68f0d513af08be0372f849436a787e7b701ae31cb964d96 8021d6ba6bd7d26a38aaa5a68e8c21a6b17dc8b579 Q1.y = 02e98f2ccf5802b05ffaac7c20018bc0c0b2fd580216c4aa2275d2 909dc0c92d0d0bdc979226adeb57a29933536b6bb4 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 082aabae8b7dedb0e78aeb619ad3bfd9277a2f77ba7fad20ef6aab dc6c31d19ba5a6d12283553294c1825c4b3ca2dcfe P.y = 05b84ae5a942248eea39e1d91030458c40153f3b654ab7872d779a d1e942856a20c438e8d99bc8abfbf74729ce1f7ac8 u[0] = 0a8ffa7447f6be1c5a2ea4b959c9454b431e29ccc0802bc052413a 9c5b4f9aac67a93431bd480d15be1e057c8a08e8c6 u[1] = 05d487032f602c90fa7625dbafe0f4a49ef4a6b0b33d7bb349ff4c f5410d297fd6241876e3e77b651cfc8191e40a68b7 Q0.x = 0cf97e6dbd0947857f3e578231d07b309c622ade08f2c08b32ff37 2bd90db19467b2563cc997d4407968d4ac80e154f8 Q0.y = 127f0cddf2613058101a5701f4cb9d0861fd6c2a1b8e0afe194fcc f586a3201a53874a2761a9ab6d7220c68661a35ab3 Q1.x = 092f1acfa62b05f95884c6791fba989bbe58044ee6355d100973bf 9553ade52b47929264e6ae770fb264582d8dce512a Q1.y = 028e6d0169a72cfedb737be45db6c401d3adfb12c58c619c82b93a 5dfcccef12290de530b0480575ddc8397cda0bbebf J.9.2. BLS12381G1_XMD:SHA-256_SSWU_NU_ suite = BLS12381G1_XMD:SHA-256_SSWU_NU_ dst = QUUX-V01-CS02-with-BLS12381G1_XMD:SHA-256_SSWU_NU_ msg = P.x = 184bb665c37ff561a89ec2122dd343f20e0f4cbcaec84e3c3052ea 81d1834e192c426074b02ed3dca4e7676ce4ce48ba P.y = 04407b8d35af4dacc809927071fc0405218f1401a6d15af775810e 4e460064bcc9468beeba82fdc751be70476c888bf3 u[0] = 156c8a6a2c184569d69a76be144b5cdc5141d2d2ca4fe341f011e2 5e3969c55ad9e9b9ce2eb833c81a908e5fa4ac5f03 Q.x = 11398d3b324810a1b093f8e35aa8571cced95858207e7f49c4fd74 656096d61d8a2f9a23cdb18a4dd11cd1d66f41f709 Q.y = 19316b6fb2ba7717355d5d66a361899057e1e84a6823039efc7bec cefe09d023fb2713b1c415fcf278eb0c39a89b4f72 Faz-Hernandez, et al. Expires 17 December 2022 [Page 141] Internet-Draft hash-to-curve June 2022 msg = abc P.x = 009769f3ab59bfd551d53a5f846b9984c59b97d6842b20a2c565ba a167945e3d026a3755b6345df8ec7e6acb6868ae6d P.y = 1532c00cf61aa3d0ce3e5aa20c3b531a2abd2c770a790a26138183 03c6b830ffc0ecf6c357af3317b9575c567f11cd2c u[0] = 147e1ed29f06e4c5079b9d14fc89d2820d32419b990c1c7bb7dbea 2a36a045124b31ffbde7c99329c05c559af1c6cc82 Q.x = 1998321bc27ff6d71df3051b5aec12ff47363d81a5e9d2dff55f44 4f6ca7e7d6af45c56fd029c58237c266ef5cda5254 Q.y = 034d274476c6307ae584f951c82e7ea85b84f72d28f4d647173235 6121af8d62a49bc263e8eb913a6cf6f125995514ee msg = abcdef0123456789 P.x = 1974dbb8e6b5d20b84df7e625e2fbfecb2cdb5f77d5eae5fb2955e 5ce7313cae8364bc2fff520a6c25619739c6bdcb6a P.y = 15f9897e11c6441eaa676de141c8d83c37aab8667173cbe1dfd6de 74d11861b961dccebcd9d289ac633455dfcc7013a3 u[0] = 04090815ad598a06897dd89bcda860f25837d54e897298ce31e694 7378134d3761dc59a572154963e8c954919ecfa82d Q.x = 17d502fa43bd6a4cad2859049a0c3ecefd60240d129be65da271a4 c03a9c38fa78163b9d2a919d2beb57df7d609b4919 Q.y = 109019902ae93a8732abecf2ff7fecd2e4e305eb91f41c9c3267f1 6b6c19de138c7272947f25512745da6c466cdfd1ac msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 0a7a047c4a8397b3446450642c2ac64d7239b61872c9ae7a59707a 8f4f950f101e766afe58223b3bff3a19a7f754027c P.y = 1383aebba1e4327ccff7cf9912bda0dbc77de048b71ef8c8a81111 d71dc33c5e3aa6edee9cf6f5fe525d50cc50b77cc9 u[0] = 08dccd088ca55b8bfbc96fb50bb25c592faa867a8bb78d4e94a8cc 2c92306190244532e91feba2b7fed977e3c3bb5a1f Q.x = 112eb92dd2b3aa9cd38b08de4bef603f2f9fb0ca226030626a9a2e 47ad1e9847fe0a5ed13766c339e38f514bba143b21 Q.y = 17542ce2f8d0a54f2c5ba8c4b14e10b22d5bcd7bae2af3c965c8c8 72b571058c720eac448276c99967ded2bf124490e1 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Faz-Hernandez, et al. Expires 17 December 2022 [Page 142] Internet-Draft hash-to-curve June 2022 P.x = 0e7a16a975904f131682edbb03d9560d3e48214c9986bd50417a77 108d13dc957500edf96462a3d01e62dc6cd468ef11 P.y = 0ae89e677711d05c30a48d6d75e76ca9fb70fe06c6dd6ff988683d 89ccde29ac7d46c53bb97a59b1901abf1db66052db u[0] = 0dd824886d2123a96447f6c56e3a3fa992fbfefdba17b6673f9f63 0ff19e4d326529db37e1c1be43f905bf9202e0278d Q.x = 1775d400a1bacc1c39c355da7e96d2d1c97baa9430c4a3476881f8 521c09a01f921f592607961efc99c4cd46bd78ca19 Q.y = 1109b5d59f65964315de65a7a143e86eabc053104ed289cf480949 317a5685fad7254ff8e7fe6d24d3104e5d55ad6370 J.10. BLS12-381 G2 J.10.1. BLS12381G2_XMD:SHA-256_SSWU_RO_ suite = BLS12381G2_XMD:SHA-256_SSWU_RO_ dst = QUUX-V01-CS02-with-BLS12381G2_XMD:SHA-256_SSWU_RO_ msg = P.x = 0141ebfbdca40eb85b87142e130ab689c673cf60f1a3e98d693352 66f30d9b8d4ac44c1038e9dcdd5393faf5c41fb78a + I * 05cb8437535e20ecffaef7752baddf98034139c38452458baeefab 379ba13dff5bf5dd71b72418717047f5b0f37da03d P.y = 0503921d7f6a12805e72940b963c0cf3471c7b2a524950ca195d11 062ee75ec076daf2d4bc358c4b190c0c98064fdd92 + I * 12424ac32561493f3fe3c260708a12b7c620e7be00099a974e259d dc7d1f6395c3c811cdd19f1e8dbf3e9ecfdcbab8d6 u[0] = 03dbc2cce174e91ba93cbb08f26b917f98194a2ea08d1cce75b2b9 cc9f21689d80bd79b594a613d0a68eb807dfdc1cf8 + I * 05a2acec64114845711a54199ea339abd125ba38253b70a92c876d f10598bd1986b739cad67961eb94f7076511b3b39a u[1] = 02f99798e8a5acdeed60d7e18e9120521ba1f47ec090984662846b c825de191b5b7641148c0dbc237726a334473eee94 + I * 145a81e418d4010cc027a68f14391b30074e89e60ee7a22f87217b 2f6eb0c4b94c9115b436e6fa4607e95a98de30a435 Q0.x = 019ad3fc9c72425a998d7ab1ea0e646a1f6093444fc6965f1cad5a 3195a7b1e099c050d57f45e3fa191cc6d75ed7458c + I * 171c88b0b0efb5eb2b88913a9e74fe111a4f68867b59db252ce586 8af4d1254bfab77ebde5d61cd1a86fb2fe4a5a1c1d Q0.y = 0ba10604e62bdd9eeeb4156652066167b72c8d743b050fb4c1016c 31b505129374f76e03fa127d6a156213576910fef3 + I * 0eb22c7a543d3d376e9716a49b72e79a89c9bfe9feee8533ed931c bb5373dde1fbcd7411d8052e02693654f71e15410a Q1.x = 113d2b9cd4bd98aee53470b27abc658d91b47a78a51584f3d4b950 677cfb8a3e99c24222c406128c91296ef6b45608be + I * 13855912321c5cb793e9d1e88f6f8d342d49c0b0dbac613ee9e17e 3c0b3c97dfbb5a49cc3fb45102fdbaf65e0efe2632 Q1.y = 0fd3def0b7574a1d801be44fde617162aa2e89da47f464317d9bb5 Faz-Hernandez, et al. Expires 17 December 2022 [Page 143] Internet-Draft hash-to-curve June 2022 abc3a7071763ce74180883ad7ad9a723a9afafcdca + I * 056f617902b3c0d0f78a9a8cbda43a26b65f602f8786540b9469b0 60db7b38417915b413ca65f875c130bebfaa59790c msg = abc P.x = 02c2d18e033b960562aae3cab37a27ce00d80ccd5ba4b7fe0e7a21 0245129dbec7780ccc7954725f4168aff2787776e6 + I * 139cddbccdc5e91b9623efd38c49f81a6f83f175e80b06fc374de9 eb4b41dfe4ca3a230ed250fbe3a2acf73a41177fd8 P.y = 1787327b68159716a37440985269cf584bcb1e621d3a7202be6ea0 5c4cfe244aeb197642555a0645fb87bf7466b2ba48 + I * 00aa65dae3c8d732d10ecd2c50f8a1baf3001578f71c694e03866e 9f3d49ac1e1ce70dd94a733534f106d4cec0eddd16 u[0] = 15f7c0aa8f6b296ab5ff9c2c7581ade64f4ee6f1bf18f55179ff44 a2cf355fa53dd2a2158c5ecb17d7c52f63e7195771 + I * 01c8067bf4c0ba709aa8b9abc3d1cef589a4758e09ef53732d670f d8739a7274e111ba2fcaa71b3d33df2a3a0c8529dd u[1] = 187111d5e088b6b9acfdfad078c4dacf72dcd17ca17c82be35e79f 8c372a693f60a033b461d81b025864a0ad051a06e4 + I * 08b852331c96ed983e497ebc6dee9b75e373d923b729194af8e72a 051ea586f3538a6ebb1e80881a082fa2b24df9f566 Q0.x = 12b2e525281b5f4d2276954e84ac4f42cf4e13b6ac4228624e1776 0faf94ce5706d53f0ca1952f1c5ef75239aeed55ad + I * 05d8a724db78e570e34100c0bc4a5fa84ad5839359b40398151f37 cff5a51de945c563463c9efbdda569850ee5a53e77 Q0.y = 02eacdc556d0bdb5d18d22f23dcb086dd106cad713777c7e640794 3edbe0b3d1efe391eedf11e977fac55f9b94f2489c + I * 04bbe48bfd5814648d0b9e30f0717b34015d45a861425fabc1ee06 fdfce36384ae2c808185e693ae97dcde118f34de41 Q1.x = 19f18cc5ec0c2f055e47c802acc3b0e40c337256a208001dde14b2 5afced146f37ea3d3ce16834c78175b3ed61f3c537 + I * 15b0dadc256a258b4c68ea43605dffa6d312eef215c19e6474b3e1 01d33b661dfee43b51abbf96fee68fc6043ac56a58 Q1.y = 05e47c1781286e61c7ade887512bd9c2cb9f640d3be9cf87ea0bad 24bd0ebfe946497b48a581ab6c7d4ca74b5147287f + I * 19f98db2f4a1fcdf56a9ced7b320ea9deecf57c8e59236b0dc21f6 ee7229aa9705ce9ac7fe7a31c72edca0d92370c096 msg = abcdef0123456789 P.x = 121982811d2491fde9ba7ed31ef9ca474f0e1501297f68c298e9f4 c0028add35aea8bb83d53c08cfc007c1e005723cd0 + I * 190d119345b94fbd15497bcba94ecf7db2cbfd1e1fe7da034d26cb ba169fb3968288b3fafb265f9ebd380512a71c3f2c P.y = 05571a0f8d3c08d094576981f4a3b8eda0a8e771fcdcc8ecceaf13 56a6acf17574518acb506e435b639353c2e14827c8 + I * 0bb5e7572275c567462d91807de765611490205a941a5a6af3b169 1bfe596c31225d3aabdf15faff860cb4ef17c7c3be u[0] = 0313d9325081b415bfd4e5364efaef392ecf69b087496973b22930 Faz-Hernandez, et al. Expires 17 December 2022 [Page 144] Internet-Draft hash-to-curve June 2022 3e1816d2080971470f7da112c4eb43053130b785e1 + I * 062f84cb21ed89406890c051a0e8b9cf6c575cf6e8e18ecf63ba86 826b0ae02548d83b483b79e48512b82a6c0686df8f u[1] = 1739123845406baa7be5c5dc74492051b6d42504de008c635f3535 bb831d478a341420e67dcc7b46b2e8cba5379cca97 + I * 01897665d9cb5db16a27657760bbea7951f67ad68f8d55f7113f24 ba6ddd82caef240a9bfa627972279974894701d975 Q0.x = 0f48f1ea1318ddb713697708f7327781fb39718971d72a9245b973 1faaca4dbaa7cca433d6c434a820c28b18e20ea208 + I * 06051467c8f85da5ba2540974758f7a1e0239a5981de441fdd8768 0a995649c211054869c50edbac1f3a86c561ba3162 Q0.y = 168b3d6df80069dbbedb714d41b32961ad064c227355e1ce5fac8e 105de5e49d77f0c64867f3834848f152497eb76333 + I * 134e0e8331cee8cb12f9c2d0742714ed9eee78a84d634c9a95f6a7 391b37125ed48bfc6e90bf3546e99930ff67cc97bc Q1.x = 004fd03968cd1c99a0dd84551f44c206c84dcbdb78076c5bfee24e 89a92c8508b52b88b68a92258403cbe1ea2da3495f + I * 1674338ea298281b636b2eb0fe593008d03171195fd6dcd4531e8a 1ed1f02a72da238a17a635de307d7d24aa2d969a47 Q1.y = 0dc7fa13fff6b12558419e0a1e94bfc3cfaf67238009991c5f24ee 94b632c3d09e27eca329989aee348a67b50d5e236c + I * 169585e164c131103d85324f2d7747b23b91d66ae5d947c449c819 4a347969fc6bbd967729768da485ba71868df8aed2 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 19a84dd7248a1066f737cc34502ee5555bd3c19f2ecdb3c7d9e24d c65d4e25e50d83f0f77105e955d78f4762d33c17da + I * 0934aba516a52d8ae479939a91998299c76d39cc0c035cd18813be c433f587e2d7a4fef038260eef0cef4d02aae3eb91 P.y = 14f81cd421617428bc3b9fe25afbb751d934a00493524bc4e06563 5b0555084dd54679df1536101b2c979c0152d09192 + I * 09bcccfa036b4847c9950780733633f13619994394c23ff0b32fa6 b795844f4a0673e20282d07bc69641cee04f5e5662 u[0] = 025820cefc7d06fd38de7d8e370e0da8a52498be9b53cba9927b2e f5c6de1e12e12f188bbc7bc923864883c57e49e253 + I * 034147b77ce337a52e5948f66db0bab47a8d038e712123bb381899 b6ab5ad20f02805601e6104c29df18c254b8618c7b u[1] = 0930315cae1f9a6017c3f0c8f2314baa130e1cf13f6532bff0a8a1 790cd70af918088c3db94bda214e896e1543629795 + I * 10c4df2cacf67ea3cb3108b00d4cbd0b3968031ebc8eac4b1ebcef e84d6b715fde66bef0219951ece29d1facc8a520ef Q0.x = 09eccbc53df677f0e5814e3f86e41e146422834854a224bf5a83a5 0e4cc0a77bfc56718e8166ad180f53526ea9194b57 + I * 0c3633943f91daee715277bd644fba585168a72f96ded64fc5a384 cce4ec884a4c3c30f08e09cd2129335dc8f67840ec Q0.y = 0eb6186a0457d5b12d132902d4468bfeb7315d83320b6c32f1c875 Faz-Hernandez, et al. Expires 17 December 2022 [Page 145] Internet-Draft hash-to-curve June 2022 f344efcba979952b4aa418589cb01af712f98cc555 + I * 119e3cf167e69eb16c1c7830e8df88856d48be12e3ff0a40791a5c d2f7221311d4bf13b1847f371f467357b3f3c0b4c7 Q1.x = 0eb3aabc1ddfce17ff18455fcc7167d15ce6b60ddc9eb9b59f8d40 ab49420d35558686293d046fc1e42f864b7f60e381 + I * 198bdfb19d7441ebcca61e8ff774b29d17da16547d2c10c273227a 635cacea3f16826322ae85717630f0867539b5ed8b Q1.y = 0aaf1dee3adf3ed4c80e481c09b57ea4c705e1b8d25b897f0ceeec 3990748716575f92abff22a1c8f4582aff7b872d52 + I * 0d058d9061ed27d4259848a06c96c5ca68921a5d269b078650c882 cb3c2bd424a8702b7a6ee4e0ead9982baf6843e924 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 01a6ba2f9a11fa5598b2d8ace0fbe0a0eacb65deceb476fbbcb64f d24557c2f4b18ecfc5663e54ae16a84f5ab7f62534 + I * 11fca2ff525572795a801eed17eb12785887c7b63fb77a42be46ce 4a34131d71f7a73e95fee3f812aea3de78b4d01569 P.y = 0b6798718c8aed24bc19cb27f866f1c9effcdbf92397ad6448b5c9 db90d2b9da6cbabf48adc1adf59a1a28344e79d57e + I * 03a47f8e6d1763ba0cad63d6114c0accbef65707825a511b251a66 0a9b3994249ae4e63fac38b23da0c398689ee2ab52 u[0] = 190b513da3e66fc9a3587b78c76d1d132b1152174d0b83e3c11140 66392579a45824c5fa17649ab89299ddd4bda54935 + I * 12ab625b0fe0ebd1367fe9fac57bb1168891846039b4216b9d9400 7b674de2d79126870e88aeef54b2ec717a887dcf39 u[1] = 0e6a42010cf435fb5bacc156a585e1ea3294cc81d0ceb81924d950 40298380b164f702275892cedd81b62de3aba3f6b5 + I * 117d9a0defc57a33ed208428cb84e54c85a6840e7648480ae42883 8989d25d97a0af8e3255be62b25c2a85630d2dddd8 Q0.x = 17cadf8d04a1a170f8347d42856526a24cc466cb2ddfd506cff011 91666b7f944e31244d662c904de5440516a2b09004 + I * 0d13ba91f2a8b0051cf3279ea0ee63a9f19bc9cb8bfcc7d78b3cbd 8cc4fc43ba726774b28038213acf2b0095391c523e Q0.y = 17ef19497d6d9246fa94d35575c0f8d06ee02f21a284dbeaa78768 cb1e25abd564e3381de87bda26acd04f41181610c5 + I * 12c3c913ba4ed03c24f0721a81a6be7430f2971ffca8fd1729aafe 496bb725807531b44b34b59b3ae5495e5a2dcbd5c8 Q1.x = 16ec57b7fe04c71dfe34fb5ad84dbce5a2dbbd6ee085f1d8cd17f4 5e8868976fc3c51ad9eeda682c7869024d24579bfd Faz-Hernandez, et al. Expires 17 December 2022 [Page 146] Internet-Draft hash-to-curve June 2022 + I * 13103f7aace1ae1420d208a537f7d3a9679c287208026e4e3439ab 8cd534c12856284d95e27f5e1f33eec2ce656533b0 Q1.y = 0958b2c4c2c10fcef5a6c59b9e92c4a67b0fae3e2e0f1b6b5edad9 c940b8f3524ba9ebbc3f2ceb3cfe377655b3163bd7 + I * 0ccb594ed8bd14ca64ed9cb4e0aba221be540f25dd0d6ba15a4a4b e5d67bcf35df7853b2d8dad3ba245f1ea3697f66aa J.10.2. BLS12381G2_XMD:SHA-256_SSWU_NU_ suite = BLS12381G2_XMD:SHA-256_SSWU_NU_ dst = QUUX-V01-CS02-with-BLS12381G2_XMD:SHA-256_SSWU_NU_ msg = P.x = 00e7f4568a82b4b7dc1f14c6aaa055edf51502319c723c4dc2688c 7fe5944c213f510328082396515734b6612c4e7bb7 + I * 126b855e9e69b1f691f816e48ac6977664d24d99f8724868a18418 6469ddfd4617367e94527d4b74fc86413483afb35b P.y = 0caead0fd7b6176c01436833c79d305c78be307da5f6af6c133c47 311def6ff1e0babf57a0fb5539fce7ee12407b0a42 + I * 1498aadcf7ae2b345243e281ae076df6de84455d766ab6fcdaad71 fab60abb2e8b980a440043cd305db09d283c895e3d u[0] = 07355d25caf6e7f2f0cb2812ca0e513bd026ed09dda65b177500fa 31714e09ea0ded3a078b526bed3307f804d4b93b04 + I * 02829ce3c021339ccb5caf3e187f6370e1e2a311dec9b753631170 63ab2015603ff52c3d3b98f19c2f65575e99e8b78c Q.x = 18ed3794ad43c781816c523776188deafba67ab773189b8f18c49b c7aa841cd81525171f7a5203b2a340579192403bef + I * 0727d90785d179e7b5732c8a34b660335fed03b913710b60903cf4 954b651ed3466dc3728e21855ae822d4a0f1d06587 Q.y = 00764a5cf6c5f61c52c838523460eb2168b5a5b43705e19cb612e0 06f29b717897facfd15dd1c8874c915f6d53d0342d + I * 19290bb9797c12c1d275817aa2605ebe42275b66860f0e4d04487e bc2e47c50b36edd86c685a60c20a2bd584a82b011a msg = abc P.x = 108ed59fd9fae381abfd1d6bce2fd2fa220990f0f837fa30e0f279 14ed6e1454db0d1ee957b219f61da6ff8be0d6441f + I * 0296238ea82c6d4adb3c838ee3cb2346049c90b96d602d7bb1b469 b905c9228be25c627bffee872def773d5b2a2eb57d P.y = 033f90f6057aadacae7963b0a0b379dd46750c1c94a6357c99b65f 63b79e321ff50fe3053330911c56b6ceea08fee656 + I * 153606c417e59fb331b7ae6bce4fbf7c5190c33ce9402b5ebe2b70 e44fca614f3f1382a3625ed5493843d0b0a652fc3f u[0] = 138879a9559e24cecee8697b8b4ad32cced053138ab913b9987277 2dc753a2967ed50aabc907937aefb2439ba06cc50c + I * 0a1ae7999ea9bab1dcc9ef8887a6cb6e8f1e22566015428d220b7e ec90ffa70ad1f624018a9ad11e78d588bd3617f9f2 Q.x = 0f40e1d5025ecef0d850aa0bb7bbeceab21a3d4e85e6bee857805b Faz-Hernandez, et al. Expires 17 December 2022 [Page 147] Internet-Draft hash-to-curve June 2022 09693051f5b25428c6be343edba5f14317fcc30143 + I * 02e0d261f2b9fee88b82804ec83db330caa75fbb12719cfa71ccce 1c532dc4e1e79b0a6a281ed8d3817524286c8bc04c Q.y = 0cf4a4adc5c66da0bca4caddc6a57ecd97c8252d7526a8ff478e0d fed816c4d321b5c3039c6683ae9b1e6a3a38c9c0ae + I * 11cad1646bb3768c04be2ab2bbe1f80263b7ff6f8f9488f5bc3b68 50e5a3e97e20acc583613c69cf3d2bfe8489744ebb msg = abcdef0123456789 P.x = 038af300ef34c7759a6caaa4e69363cafeed218a1f207e93b2c70d 91a1263d375d6730bd6b6509dcac3ba5b567e85bf3 + I * 0da75be60fb6aa0e9e3143e40c42796edf15685cafe0279afd2a67 c3dff1c82341f17effd402e4f1af240ea90f4b659b P.y = 19b148cbdf163cf0894f29660d2e7bfb2b68e37d54cc83fd4e6e62 c020eaa48709302ef8e746736c0e19342cc1ce3df4 + I * 0492f4fed741b073e5a82580f7c663f9b79e036b70ab3e51162359 cec4e77c78086fe879b65ca7a47d34374c8315ac5e u[0] = 18c16fe362b7dbdfa102e42bdfd3e2f4e6191d479437a59db4eb71 6986bf08ee1f42634db66bde97d6c16bbfd342b3b8 + I * 0e37812ce1b146d998d5f92bdd5ada2a31bfd63dfe18311aa91637 b5f279dd045763166aa1615e46a50d8d8f475f184e Q.x = 13a9d4a738a85c9f917c7be36b240915434b58679980010499b9ae 8d7a1bf7fbe617a15b3cd6060093f40d18e0f19456 + I * 16fa88754e7670366a859d6f6899ad765bf5a177abedb2740aacc9 252c43f90cd0421373fbd5b2b76bb8f5c4886b5d37 Q.y = 0a7fa7d82c46797039398253e8765a4194100b330dfed6d7fbb46d 6fbf01e222088779ac336e3675c7a7a0ee05bbb6e3 + I * 0c6ee170ab766d11fa9457cef53253f2628010b2cffc102b3b2835 1eb9df6c281d3cfc78e9934769d661b72a5265338d msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq P.x = 0c5ae723be00e6c3f0efe184fdc0702b64588fe77dda152ab13099 a3bacd3876767fa7bbad6d6fd90b3642e902b208f9 + I * 12c8c05c1d5fc7bfa847f4d7d81e294e66b9a78bc9953990c35894 5e1f042eedafce608b67fdd3ab0cb2e6e263b9b1ad P.y = 04e77ddb3ede41b5ec4396b7421dd916efc68a358a0d7425bddd25 3547f2fb4830522358491827265dfc5bcc1928a569 + I * 11c624c56dbe154d759d021eec60fab3d8b852395a89de497e4850 4366feedd4662d023af447d66926a28076813dd646 u[0] = 08d4a0997b9d52fecf99427abb721f0fa779479963315fe21c6445 250de7183e3f63bfdf86570da8929489e421d4ee95 + I * 16cb4ccad91ec95aab070f22043916cd6a59c4ca94097f7f510043 d48515526dc8eaaea27e586f09151ae613688d5a89 Q.x = 0a08b2f639855dfdeaaed972702b109e2241a54de198b2b4cd12ad 9f88fa419a6086a58d91fc805de812ea29bee427c2 + I * 04a7442e4cb8b42ef0f41dac9ee74e65ecad3ce0851f0746dc4756 Faz-Hernandez, et al. Expires 17 December 2022 [Page 148] Internet-Draft hash-to-curve June 2022 8b0e7a8134121ed09ba054509232c49148aef62cda Q.y = 05d60b1f04212b2c87607458f71d770f43973511c260f0540eef3a 565f42c7ce59aa1cea684bb2a7bcab84acd2f36c8c + I * 1017aa5747ba15505ece266a86b0ca9c712f41a254b76ca04094ca 442ce45ecd224bd5544cd16685d0d1b9d156dd0531 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa P.x = 0ea4e7c33d43e17cc516a72f76437c4bf81d8f4eac69ac355d3bf9 b71b8138d55dc10fd458be115afa798b55dac34be1 + I * 1565c2f625032d232f13121d3cfb476f45275c303a037faa255f9d a62000c2c864ea881e2bcddd111edc4a3c0da3e88d P.y = 043b6f5fe4e52c839148dc66f2b3751e69a0f6ebb3d056d6465d50 d4108543ecd956e10fa1640dfd9bc0030cc2558d28 + I * 0f8991d2a1ad662e7b6f58ab787947f1fa607fce12dde171bc1790 3b012091b657e15333e11701edcf5b63ba2a561247 u[0] = 03f80ce4ff0ca2f576d797a3660e3f65b274285c054feccc3215c8 79e2c0589d376e83ede13f93c32f05da0f68fd6a10 + I * 006488a837c5413746d868d1efb7232724da10eca410b07d8b505b 9363bdccf0a1fc0029bad07d65b15ccfe6dd25e20d Q.x = 19592c812d5a50c5601062faba14c7d670711745311c879de1235a 0a11c75aab61327bf2d1725db07ec4d6996a682886 + I * 0eef4fa41ddc17ed47baf447a2c498548f3c72a02381313d13bef9 16e240b61ce125539090d62d9fbb14a900bf1b8e90 Q.y = 1260d6e0987eae96af9ebe551e08de22b37791d53f4db9e0d59da7 36e66699735793e853e26362531fe4adf99c1883e3 + I * 0dbace5df0a4ac4ac2f45d8fdf8aee45484576fdd6efc4f98ab9b9 f4112309e628255e183022d98ea5ed6e47ca00306c Appendix K. Expand test vectors This section gives test vectors for expand_message variants specified in Section 5.3. The test vectors in this section were generated using code that is available from [hash2curve-repo]. Faz-Hernandez, et al. Expires 17 December 2022 [Page 149] Internet-Draft hash-to-curve June 2022 Each test vector in this section lists the expand_message name, hash function, and DST, along with a series of tuples of the function inputs (msg and len_in_bytes), output (uniform_bytes), and intermediate values (dst_prime and msg_prime). DST and msg are represented as ASCII strings. Intermediate and output values are represented as byte strings in hexadecimal. K.1. expand_message_xmd(SHA-256) name = expand_message_xmd DST = QUUX-V01-CS02-with-expander-SHA256-128 hash = SHA256 k = 128 msg = len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413235362d31323826 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000002000515555582d5630312d43533032 2d776974682d657870616e6465722d5348413235362d31323826 uniform_bytes = 68a985b87eb6b46952128911f2a4412bbc302a9d759667f8 7f7a21d803f07235 msg = abc len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413235362d31323826 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000616263002000515555582d5630312d43 5330322d776974682d657870616e6465722d5348413235362d3132 3826 uniform_bytes = d8ccab23b5985ccea865c6c97b6e5b8350e794e603b4b979 02f53a8a0d605615 msg = abcdef0123456789 len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413235362d31323826 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000061626364656630313233343536373839 002000515555582d5630312d435330322d776974682d657870616e 6465722d5348413235362d31323826 uniform_bytes = eff31487c770a893cfb36f912fbfcbff40d5661771ca4b2c b4eafe524333f5c1 Faz-Hernandez, et al. Expires 17 December 2022 [Page 150] Internet-Draft hash-to-curve June 2022 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413235362d31323826 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000713132385f7171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171002000515555582d5630312d435330322d77 6974682d657870616e6465722d5348413235362d31323826 uniform_bytes = b23a1d2b4d97b2ef7785562a7e8bac7eed54ed6e97e29aa5 1bfe3f12ddad1ff9 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413235362d31323826 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000613531325f6161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 Faz-Hernandez, et al. Expires 17 December 2022 [Page 151] Internet-Draft hash-to-curve June 2022 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161002000515555582d5630312d 435330322d776974682d657870616e6465722d5348413235362d31 323826 uniform_bytes = 4623227bcc01293b8c130bf771da8c298dede7383243dc09 93d2d94823958c4c msg = len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413235362d31323826 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000008000515555582d5630312d43533032 2d776974682d657870616e6465722d5348413235362d31323826 uniform_bytes = af84c27ccfd45d41914fdff5df25293e221afc53d8ad2ac0 6d5e3e29485dadbee0d121587713a3e0dd4d5e69e93eb7cd4f5df4 cd103e188cf60cb02edc3edf18eda8576c412b18ffb658e3dd6ec8 49469b979d444cf7b26911a08e63cf31f9dcc541708d3491184472 c2c29bb749d4286b004ceb5ee6b9a7fa5b646c993f0ced msg = abc len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413235362d31323826 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000616263008000515555582d5630312d43 5330322d776974682d657870616e6465722d5348413235362d3132 3826 uniform_bytes = abba86a6129e366fc877aab32fc4ffc70120d8996c88aee2 fe4b32d6c7b6437a647e6c3163d40b76a73cf6a5674ef1d890f95b 664ee0afa5359a5c4e07985635bbecbac65d747d3d2da7ec2b8221 b17b0ca9dc8a1ac1c07ea6a1e60583e2cb00058e77b7b72a298425 cd1b941ad4ec65e8afc50303a22c0f99b0509b4c895f40 msg = abcdef0123456789 len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413235362d31323826 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000061626364656630313233343536373839 008000515555582d5630312d435330322d776974682d657870616e 6465722d5348413235362d31323826 Faz-Hernandez, et al. Expires 17 December 2022 [Page 152] Internet-Draft hash-to-curve June 2022 uniform_bytes = ef904a29bffc4cf9ee82832451c946ac3c8f8058ae97d8d6 29831a74c6572bd9ebd0df635cd1f208e2038e760c4994984ce73f 0d55ea9f22af83ba4734569d4bc95e18350f740c07eef653cbb9f8 7910d833751825f0ebefa1abe5420bb52be14cf489b37fe1a72f7d e2d10be453b2c9d9eb20c7e3f6edc5a60629178d9478df msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413235362d31323826 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000713132385f7171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171008000515555582d5630312d435330322d77 6974682d657870616e6465722d5348413235362d31323826 uniform_bytes = 80be107d0884f0d881bb460322f0443d38bd222db8bd0b0a 5312a6fedb49c1bbd88fd75d8b9a09486c60123dfa1d73c1cc3169 761b17476d3c6b7cbbd727acd0e2c942f4dd96ae3da5de368d26b3 2286e32de7e5a8cb2949f866a0b80c58116b29fa7fabb3ea7d520e e603e0c25bcaf0b9a5e92ec6a1fe4e0391d1cdbce8c68a msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413235362d31323826 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000613531325f6161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 Faz-Hernandez, et al. Expires 17 December 2022 [Page 153] Internet-Draft hash-to-curve June 2022 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161008000515555582d5630312d 435330322d776974682d657870616e6465722d5348413235362d31 323826 uniform_bytes = 546aff5444b5b79aa6148bd81728704c32decb73a3ba76e9 e75885cad9def1d06d6792f8a7d12794e90efed817d96920d72889 6a4510864370c207f99bd4a608ea121700ef01ed879745ee3e4cee f777eda6d9e5e38b90c86ea6fb0b36504ba4a45d22e86f6db5dd43 d98a294bebb9125d5b794e9d2a81181066eb954966a487 K.2. expand_message_xmd(SHA-256) (long DST) name = expand_message_xmd DST = QUUX-V01-CS02-with-expander-SHA256-128-long-DST-111111 111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111 hash = SHA256 k = 128 msg = len_in_bytes = 0x20 DST_prime = 412717974da474d0f8c420f320ff81e8432adb7c927d9bd082b4 fb4d16c0a23620 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000002000412717974da474d0f8c420f320 ff81e8432adb7c927d9bd082b4fb4d16c0a23620 uniform_bytes = e8dc0c8b686b7ef2074086fbdd2f30e3f8bfbd3bdf177f73 f04b97ce618a3ed3 msg = abc len_in_bytes = 0x20 DST_prime = 412717974da474d0f8c420f320ff81e8432adb7c927d9bd082b4 fb4d16c0a23620 Faz-Hernandez, et al. Expires 17 December 2022 [Page 154] Internet-Draft hash-to-curve June 2022 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000616263002000412717974da474d0f8c4 20f320ff81e8432adb7c927d9bd082b4fb4d16c0a23620 uniform_bytes = 52dbf4f36cf560fca57dedec2ad924ee9c266341d8f3d6af e5171733b16bbb12 msg = abcdef0123456789 len_in_bytes = 0x20 DST_prime = 412717974da474d0f8c420f320ff81e8432adb7c927d9bd082b4 fb4d16c0a23620 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000061626364656630313233343536373839 002000412717974da474d0f8c420f320ff81e8432adb7c927d9bd0 82b4fb4d16c0a23620 uniform_bytes = 35387dcf22618f3728e6c686490f8b431f76550b0b2c61cb c1ce7001536f4521 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq len_in_bytes = 0x20 DST_prime = 412717974da474d0f8c420f320ff81e8432adb7c927d9bd082b4 fb4d16c0a23620 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000713132385f7171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171002000412717974da474d0f8c420f320ff81 e8432adb7c927d9bd082b4fb4d16c0a23620 uniform_bytes = 01b637612bb18e840028be900a833a74414140dde0c4754c 198532c3a0ba42bc msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa len_in_bytes = 0x20 Faz-Hernandez, et al. Expires 17 December 2022 [Page 155] Internet-Draft hash-to-curve June 2022 DST_prime = 412717974da474d0f8c420f320ff81e8432adb7c927d9bd082b4 fb4d16c0a23620 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000613531325f6161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161002000412717974da474d0f8 c420f320ff81e8432adb7c927d9bd082b4fb4d16c0a23620 uniform_bytes = 20cce7033cabc5460743180be6fa8aac5a103f56d481cf36 9a8accc0c374431b msg = len_in_bytes = 0x80 DST_prime = 412717974da474d0f8c420f320ff81e8432adb7c927d9bd082b4 fb4d16c0a23620 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000008000412717974da474d0f8c420f320 ff81e8432adb7c927d9bd082b4fb4d16c0a23620 uniform_bytes = 14604d85432c68b757e485c8894db3117992fc57e0e136f7 1ad987f789a0abc287c47876978e2388a02af86b1e8d1342e5ce4f 7aaa07a87321e691f6fba7e0072eecc1218aebb89fb14a0662322d 5edbd873f0eb35260145cd4e64f748c5dfe60567e126604bcab1a3 ee2dc0778102ae8a5cfd1429ebc0fa6bf1a53c36f55dfc msg = abc len_in_bytes = 0x80 DST_prime = 412717974da474d0f8c420f320ff81e8432adb7c927d9bd082b4 fb4d16c0a23620 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 Faz-Hernandez, et al. Expires 17 December 2022 [Page 156] Internet-Draft hash-to-curve June 2022 0000000000000000000000616263008000412717974da474d0f8c4 20f320ff81e8432adb7c927d9bd082b4fb4d16c0a23620 uniform_bytes = 1a30a5e36fbdb87077552b9d18b9f0aee16e80181d5b951d 0471d55b66684914aef87dbb3626eaabf5ded8cd0686567e503853 e5c84c259ba0efc37f71c839da2129fe81afdaec7fbdc0ccd4c794 727a17c0d20ff0ea55e1389d6982d1241cb8d165762dbc39fb0cee 4474d2cbbd468a835ae5b2f20e4f959f56ab24cd6fe267 msg = abcdef0123456789 len_in_bytes = 0x80 DST_prime = 412717974da474d0f8c420f320ff81e8432adb7c927d9bd082b4 fb4d16c0a23620 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000061626364656630313233343536373839 008000412717974da474d0f8c420f320ff81e8432adb7c927d9bd0 82b4fb4d16c0a23620 uniform_bytes = d2ecef3635d2397f34a9f86438d772db19ffe9924e28a1ca f6f1c8f15603d4028f40891044e5c7e39ebb9b31339979ff33a424 9206f67d4a1e7c765410bcd249ad78d407e303675918f20f26ce6d 7027ed3774512ef5b00d816e51bfcc96c3539601fa48ef1c07e494 bdc37054ba96ecb9dbd666417e3de289d4f424f502a982 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq len_in_bytes = 0x80 DST_prime = 412717974da474d0f8c420f320ff81e8432adb7c927d9bd082b4 fb4d16c0a23620 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000713132385f7171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171008000412717974da474d0f8c420f320ff81 e8432adb7c927d9bd082b4fb4d16c0a23620 uniform_bytes = ed6e8c036df90111410431431a232d41a32c86e296c05d42 6e5f44e75b9a50d335b2412bc6c91e0a6dc131de09c43110d9180d 0a70f0d6289cb4e43b05f7ee5e9b3f42a1fad0f31bac6a625b3b5c 50e3a83316783b649e5ecc9d3b1d9471cb5024b7ccf40d41d1751a 04ca0356548bc6e703fca02ab521b505e8e45600508d32 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Faz-Hernandez, et al. Expires 17 December 2022 [Page 157] Internet-Draft hash-to-curve June 2022 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa len_in_bytes = 0x80 DST_prime = 412717974da474d0f8c420f320ff81e8432adb7c927d9bd082b4 fb4d16c0a23620 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 0000000000000000000000613531325f6161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161008000412717974da474d0f8 c420f320ff81e8432adb7c927d9bd082b4fb4d16c0a23620 uniform_bytes = 78b53f2413f3c688f07732c10e5ced29a17c6a16f717179f fbe38d92d6c9ec296502eb9889af83a1928cd162e845b0d3c5424e 83280fed3d10cffb2f8431f14e7a23f4c68819d40617589e4c4116 9d0b56e0e3535be1fd71fbb08bb70c5b5ffed953d6c14bf7618b35 fc1f4c4b30538236b4b08c9fbf90462447a8ada60be495 K.3. expand_message_xmd(SHA-512) name = expand_message_xmd DST = QUUX-V01-CS02-with-expander-SHA512-256 hash = SHA512 k = 256 msg = len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 Faz-Hernandez, et al. Expires 17 December 2022 [Page 158] Internet-Draft hash-to-curve June 2022 722d5348413531322d32353626 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000002000515555 582d5630312d435330322d776974682d657870616e6465722d5348 413531322d32353626 uniform_bytes = 6b9a7312411d92f921c6f68ca0b6380730a1a4d982c50721 1a90964c394179ba msg = abc len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413531322d32353626 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000616263002000 515555582d5630312d435330322d776974682d657870616e646572 2d5348413531322d32353626 uniform_bytes = 0da749f12fbe5483eb066a5f595055679b976e93abe9be6f 0f6318bce7aca8dc msg = abcdef0123456789 len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413531322d32353626 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000616263646566 30313233343536373839002000515555582d5630312d435330322d 776974682d657870616e6465722d5348413531322d32353626 uniform_bytes = 087e45a86e2939ee8b91100af1583c4938e0f5fc6c9db4b1 07b83346bc967f58 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413531322d32353626 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 Faz-Hernandez, et al. Expires 17 December 2022 [Page 159] Internet-Draft hash-to-curve June 2022 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000713132385f71 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 71717171717171717171717171717171717171002000515555582d 5630312d435330322d776974682d657870616e6465722d53484135 31322d32353626 uniform_bytes = 7336234ee9983902440f6bc35b348352013becd88938d2af ec44311caf8356b3 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413531322d32353626 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000613531325f61 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 Faz-Hernandez, et al. Expires 17 December 2022 [Page 160] Internet-Draft hash-to-curve June 2022 616161616161616161616161616161616161616161616161610020 00515555582d5630312d435330322d776974682d657870616e6465 722d5348413531322d32353626 uniform_bytes = 57b5f7e766d5be68a6bfe1768e3c2b7f1228b3e4b3134956 dd73a59b954c66f4 msg = len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413531322d32353626 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000008000515555 582d5630312d435330322d776974682d657870616e6465722d5348 413531322d32353626 uniform_bytes = 41b037d1734a5f8df225dd8c7de38f851efdb45c372887be 655212d07251b921b052b62eaed99b46f72f2ef4cc96bfaf254ebb bec091e1a3b9e4fb5e5b619d2e0c5414800a1d882b62bb5cd1778f 098b8eb6cb399d5d9d18f5d5842cf5d13d7eb00a7cff859b605da6 78b318bd0e65ebff70bec88c753b159a805d2c89c55961 msg = abc len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413531322d32353626 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000616263008000 515555582d5630312d435330322d776974682d657870616e646572 2d5348413531322d32353626 uniform_bytes = 7f1dddd13c08b543f2e2037b14cefb255b44c83cc397c178 6d975653e36a6b11bdd7732d8b38adb4a0edc26a0cef4bb4521713 5456e58fbca1703cd6032cb1347ee720b87972d63fbf232587043e d2901bce7f22610c0419751c065922b488431851041310ad659e4b 23520e1772ab29dcdeb2002222a363f0c2b1c972b3efe1 msg = abcdef0123456789 len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413531322d32353626 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 Faz-Hernandez, et al. Expires 17 December 2022 [Page 161] Internet-Draft hash-to-curve June 2022 000000000000000000000000000000000000000000616263646566 30313233343536373839008000515555582d5630312d435330322d 776974682d657870616e6465722d5348413531322d32353626 uniform_bytes = 3f721f208e6199fe903545abc26c837ce59ac6fa45733f1b aaf0222f8b7acb0424814fcb5eecf6c1d38f06e9d0a6ccfbf85ae6 12ab8735dfdf9ce84c372a77c8f9e1c1e952c3a61b7567dd069301 6af51d2745822663d0c2367e3f4f0bed827feecc2aaf98c949b5ed 0d35c3f1023d64ad1407924288d366ea159f46287e61ac msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413531322d32353626 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000713132385f71 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 71717171717171717171717171717171717171008000515555582d 5630312d435330322d776974682d657870616e6465722d53484135 31322d32353626 uniform_bytes = b799b045a58c8d2b4334cf54b78260b45eec544f9f2fb5bd 12fb603eaee70db7317bf807c406e26373922b7b8920fa29142703 dd52bdf280084fb7ef69da78afdf80b3586395b433dc66cde048a2 58e476a561e9deba7060af40adf30c64249ca7ddea79806ee5beb9 a1422949471d267b21bc88e688e4014087a0b592b695ed msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348413531322d32353626 msg_prime = 0000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 Faz-Hernandez, et al. Expires 17 December 2022 [Page 162] Internet-Draft hash-to-curve June 2022 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000613531325f61 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161610080 00515555582d5630312d435330322d776974682d657870616e6465 722d5348413531322d32353626 uniform_bytes = 05b0bfef265dcee87654372777b7c44177e2ae4c13a27f10 3340d9cd11c86cb2426ffcad5bd964080c2aee97f03be1ca18e30a 1f14e27bc11ebbd650f305269cc9fb1db08bf90bfc79b42a952b46 daf810359e7bc36452684784a64952c343c52e5124cd1f71d474d5 197fefc571a92929c9084ffe1112cf5eea5192ebff330b K.4. expand_message_xof(SHAKE128) name = expand_message_xof DST = QUUX-V01-CS02-with-expander-SHAKE128 hash = SHAKE128 k = 128 msg = len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4531323824 msg_prime = 0020515555582d5630312d435330322d776974682d657870616e 6465722d5348414b4531323824 uniform_bytes = 86518c9cd86581486e9485aa74ab35ba150d1c75c88e26b7 043e44e2acd735a2 msg = abc len_in_bytes = 0x20 Faz-Hernandez, et al. Expires 17 December 2022 [Page 163] Internet-Draft hash-to-curve June 2022 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4531323824 msg_prime = 6162630020515555582d5630312d435330322d776974682d6578 70616e6465722d5348414b4531323824 uniform_bytes = 8696af52a4d862417c0763556073f47bc9b9ba43c99b5053 05cb1ec04a9ab468 msg = abcdef0123456789 len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4531323824 msg_prime = 616263646566303132333435363738390020515555582d563031 2d435330322d776974682d657870616e6465722d5348414b453132 3824 uniform_bytes = 912c58deac4821c3509dbefa094df54b34b8f5d01a191d1d 3108a2c89077acca msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4531323824 msg_prime = 713132385f717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717100 20515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4531323824 uniform_bytes = 1adbcc448aef2a0cebc71dac9f756b22e51839d348e031e6 3b33ebb50faeaf3f msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4531323824 msg_prime = 613531325f616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 Faz-Hernandez, et al. Expires 17 December 2022 [Page 164] Internet-Draft hash-to-curve June 2022 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 61616161610020515555582d5630312d435330322d776974682d65 7870616e6465722d5348414b4531323824 uniform_bytes = df3447cc5f3e9a77da10f819218ddf31342c310778e0e4ef 72bbaecee786a4fe msg = len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4531323824 msg_prime = 0080515555582d5630312d435330322d776974682d657870616e 6465722d5348414b4531323824 uniform_bytes = 7314ff1a155a2fb99a0171dc71b89ab6e3b2b7d59e38e644 19b8b6294d03ffee42491f11370261f436220ef787f8f76f5b26bd cd850071920ce023f3ac46847744f4612b8714db8f5db83205b2e6 25d95afd7d7b4d3094d3bdde815f52850bb41ead9822e08f22cf41 d615a303b0d9dde73263c049a7b9898208003a739a2e57 msg = abc len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4531323824 msg_prime = 6162630080515555582d5630312d435330322d776974682d6578 70616e6465722d5348414b4531323824 uniform_bytes = c952f0c8e529ca8824acc6a4cab0e782fc3648c563ddb00d a7399f2ae35654f4860ec671db2356ba7baa55a34a9d7f79197b60 ddae6e64768a37d699a78323496db3878c8d64d909d0f8a7de4927 dcab0d3dbbc26cb20a49eceb0530b431cdf47bc8c0fa3e0d88f53b 318b6739fbed7d7634974f1b5c386d6230c76260d5337a msg = abcdef0123456789 len_in_bytes = 0x80 Faz-Hernandez, et al. Expires 17 December 2022 [Page 165] Internet-Draft hash-to-curve June 2022 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4531323824 msg_prime = 616263646566303132333435363738390080515555582d563031 2d435330322d776974682d657870616e6465722d5348414b453132 3824 uniform_bytes = 19b65ee7afec6ac06a144f2d6134f08eeec185f1a890fe34 e68f0e377b7d0312883c048d9b8a1d6ecc3b541cb4987c26f45e0c 82691ea299b5e6889bbfe589153016d8131717ba26f07c3c14ffbe f1f3eff9752e5b6183f43871a78219a75e7000fbac6a7072e2b83c 790a3a5aecd9d14be79f9fd4fb180960a3772e08680495 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4531323824 msg_prime = 713132385f717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717100 80515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4531323824 uniform_bytes = ca1b56861482b16eae0f4a26212112362fcc2d76dcc80c93 c4182ed66c5113fe41733ed68be2942a3487394317f3379856f482 2a611735e50528a60e7ade8ec8c71670fec6661e2c59a09ed36386 513221688b35dc47e3c3111ee8c67ff49579089d661caa29db1ef1 0eb6eace575bf3dc9806e7c4016bd50f3c0e2a6481ee6d msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4531323824 msg_prime = 613531325f616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 Faz-Hernandez, et al. Expires 17 December 2022 [Page 166] Internet-Draft hash-to-curve June 2022 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 61616161610080515555582d5630312d435330322d776974682d65 7870616e6465722d5348414b4531323824 uniform_bytes = 9d763a5ce58f65c91531b4100c7266d479a5d9777ba76169 3d052acd37d149e7ac91c796a10b919cd74a591a1e38719fb91b72 03e2af31eac3bff7ead2c195af7d88b8bc0a8adf3d1e90ab9bed6d dc2b7f655dd86c730bdeaea884e73741097142c92f0e3fc1811b69 9ba593c7fbd81da288a29d423df831652e3a01a9374999 K.5. expand_message_xof(SHAKE128) (long DST) name = expand_message_xof DST = QUUX-V01-CS02-with-expander-SHAKE128-long-DST-11111111 111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111 hash = SHAKE128 k = 128 msg = len_in_bytes = 0x20 DST_prime = acb9736c0867fdfbd6385519b90fc8c034b5af04a95897321295 0132d035792f20 msg_prime = 0020acb9736c0867fdfbd6385519b90fc8c034b5af04a9589732 12950132d035792f20 uniform_bytes = 827c6216330a122352312bccc0c8d6e7a146c5257a776dbd 9ad9d75cd880fc53 msg = abc len_in_bytes = 0x20 DST_prime = acb9736c0867fdfbd6385519b90fc8c034b5af04a95897321295 0132d035792f20 msg_prime = 6162630020acb9736c0867fdfbd6385519b90fc8c034b5af04a9 58973212950132d035792f20 Faz-Hernandez, et al. Expires 17 December 2022 [Page 167] Internet-Draft hash-to-curve June 2022 uniform_bytes = 690c8d82c7213b4282c6cb41c00e31ea1d3e2005f93ad19b bf6da40f15790c5c msg = abcdef0123456789 len_in_bytes = 0x20 DST_prime = acb9736c0867fdfbd6385519b90fc8c034b5af04a95897321295 0132d035792f20 msg_prime = 616263646566303132333435363738390020acb9736c0867fdfb d6385519b90fc8c034b5af04a958973212950132d035792f20 uniform_bytes = 979e3a15064afbbcf99f62cc09fa9c85028afcf3f825eb07 11894dcfc2f57057 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq len_in_bytes = 0x20 DST_prime = acb9736c0867fdfbd6385519b90fc8c034b5af04a95897321295 0132d035792f20 msg_prime = 713132385f717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717100 20acb9736c0867fdfbd6385519b90fc8c034b5af04a95897321295 0132d035792f20 uniform_bytes = c5a9220962d9edc212c063f4f65b609755a1ed96e62f9db5 d1fd6adb5a8dc52b msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa len_in_bytes = 0x20 DST_prime = acb9736c0867fdfbd6385519b90fc8c034b5af04a95897321295 0132d035792f20 msg_prime = 613531325f616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 Faz-Hernandez, et al. Expires 17 December 2022 [Page 168] Internet-Draft hash-to-curve June 2022 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 61616161610020acb9736c0867fdfbd6385519b90fc8c034b5af04 a958973212950132d035792f20 uniform_bytes = f7b96a5901af5d78ce1d071d9c383cac66a1dfadb508300e c6aeaea0d62d5d62 msg = len_in_bytes = 0x80 DST_prime = acb9736c0867fdfbd6385519b90fc8c034b5af04a95897321295 0132d035792f20 msg_prime = 0080acb9736c0867fdfbd6385519b90fc8c034b5af04a9589732 12950132d035792f20 uniform_bytes = 3890dbab00a2830be398524b71c2713bbef5f4884ac2e6f0 70b092effdb19208c7df943dc5dcbaee3094a78c267ef276632ee2 c8ea0c05363c94b6348500fae4208345dd3475fe0c834c2beac7fa 7bc181692fb728c0a53d809fc8111495222ce0f38468b11becb15b 32060218e285c57a60162c2c8bb5b6bded13973cd41819 msg = abc len_in_bytes = 0x80 DST_prime = acb9736c0867fdfbd6385519b90fc8c034b5af04a95897321295 0132d035792f20 msg_prime = 6162630080acb9736c0867fdfbd6385519b90fc8c034b5af04a9 58973212950132d035792f20 uniform_bytes = 41b7ffa7a301b5c1441495ebb9774e2a53dbbf4e54b9a1af 6a20fd41eafd69ef7b9418599c5545b1ee422f363642b01d4a5344 9313f68da3e49dddb9cd25b97465170537d45dcbdf92391b5bdff3 44db4bd06311a05bca7dcd360b6caec849c299133e5c9194f4e15e 3e23cfaab4003fab776f6ac0bfae9144c6e2e1c62e7d57 msg = abcdef0123456789 len_in_bytes = 0x80 DST_prime = acb9736c0867fdfbd6385519b90fc8c034b5af04a95897321295 0132d035792f20 msg_prime = 616263646566303132333435363738390080acb9736c0867fdfb d6385519b90fc8c034b5af04a958973212950132d035792f20 uniform_bytes = 55317e4a21318472cd2290c3082957e1242241d9e0d04f47 Faz-Hernandez, et al. Expires 17 December 2022 [Page 169] Internet-Draft hash-to-curve June 2022 026f03401643131401071f01aa03038b2783e795bdfa8a3541c194 ad5de7cb9c225133e24af6c86e748deb52e560569bd54ef4dac034 65111a3a44b0ea490fb36777ff8ea9f1a8a3e8e0de3cf0880b4b2f 8dd37d3a85a8b82375aee4fa0e909f9763319b55778e71 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq len_in_bytes = 0x80 DST_prime = acb9736c0867fdfbd6385519b90fc8c034b5af04a95897321295 0132d035792f20 msg_prime = 713132385f717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717100 80acb9736c0867fdfbd6385519b90fc8c034b5af04a95897321295 0132d035792f20 uniform_bytes = 19fdd2639f082e31c77717ac9bb032a22ff0958382b2dbb3 9020cdc78f0da43305414806abf9a561cb2d0067eb2f7bc544482f 75623438ed4b4e39dd9e6e2909dd858bd8f1d57cd0fce2d3150d90 aa67b4498bdf2df98c0100dd1a173436ba5d0df6be1defb0b2ce55 ccd2f4fc05eb7cb2c019c35d5398b85adc676da4238bc7 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa len_in_bytes = 0x80 DST_prime = acb9736c0867fdfbd6385519b90fc8c034b5af04a95897321295 0132d035792f20 msg_prime = 613531325f616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 Faz-Hernandez, et al. Expires 17 December 2022 [Page 170] Internet-Draft hash-to-curve June 2022 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 61616161610080acb9736c0867fdfbd6385519b90fc8c034b5af04 a958973212950132d035792f20 uniform_bytes = 945373f0b3431a103333ba6a0a34f1efab2702efde41754c 4cb1d5216d5b0a92a67458d968562bde7fa6310a83f53dda138368 0a276a283438d58ceebfa7ab7ba72499d4a3eddc860595f63c93b1 c5e823ea41fc490d938398a26db28f61857698553e93f0574eb8c5 017bfed6249491f9976aaa8d23d9485339cc85ca329308 K.6. expand_message_xof(SHAKE256) name = expand_message_xof DST = QUUX-V01-CS02-with-expander-SHAKE256 hash = SHAKE256 k = 256 msg = len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4532353624 msg_prime = 0020515555582d5630312d435330322d776974682d657870616e 6465722d5348414b4532353624 uniform_bytes = 2ffc05c48ed32b95d72e807f6eab9f7530dd1c2f013914c8 fed38c5ccc15ad76 msg = abc len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4532353624 msg_prime = 6162630020515555582d5630312d435330322d776974682d6578 70616e6465722d5348414b4532353624 uniform_bytes = b39e493867e2767216792abce1f2676c197c0692aed06156 0ead251821808e07 msg = abcdef0123456789 len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4532353624 msg_prime = 616263646566303132333435363738390020515555582d563031 2d435330322d776974682d657870616e6465722d5348414b453235 3624 Faz-Hernandez, et al. Expires 17 December 2022 [Page 171] Internet-Draft hash-to-curve June 2022 uniform_bytes = 245389cf44a13f0e70af8665fe5337ec2dcd138890bb7901 c4ad9cfceb054b65 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4532353624 msg_prime = 713132385f717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717100 20515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4532353624 uniform_bytes = 719b3911821e6428a5ed9b8e600f2866bcf23c8f0515e52d 6c6c019a03f16f0e msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa len_in_bytes = 0x20 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4532353624 msg_prime = 613531325f616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 Faz-Hernandez, et al. Expires 17 December 2022 [Page 172] Internet-Draft hash-to-curve June 2022 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 61616161610020515555582d5630312d435330322d776974682d65 7870616e6465722d5348414b4532353624 uniform_bytes = 9181ead5220b1963f1b5951f35547a5ea86a820562287d6c a4723633d17ccbbc msg = len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4532353624 msg_prime = 0080515555582d5630312d435330322d776974682d657870616e 6465722d5348414b4532353624 uniform_bytes = 7a1361d2d7d82d79e035b8880c5a3c86c5afa719478c007d 96e6c88737a3f631dd74a2c88df79a4cb5e5d9f7504957c70d669e c6bfedc31e01e2bacc4ff3fdf9b6a00b17cc18d9d72ace7d6b81c2 e481b4f73f34f9a7505dccbe8f5485f3d20c5409b0310093d5d649 2dea4e18aa6979c23c8ea5de01582e9689612afbb353df msg = abc len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4532353624 msg_prime = 6162630080515555582d5630312d435330322d776974682d6578 70616e6465722d5348414b4532353624 uniform_bytes = a54303e6b172909783353ab05ef08dd435a558c3197db0c1 32134649708e0b9b4e34fb99b92a9e9e28fc1f1d8860d85897a8e0 21e6382f3eea10577f968ff6df6c45fe624ce65ca25932f679a42a 404bc3681efe03fcd45ef73bb3a8f79ba784f80f55ea8a3c367408 f30381299617f50c8cf8fbb21d0f1e1d70b0131a7b6fbe msg = abcdef0123456789 len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4532353624 msg_prime = 616263646566303132333435363738390080515555582d563031 2d435330322d776974682d657870616e6465722d5348414b453235 3624 uniform_bytes = e42e4d9538a189316e3154b821c1bafb390f78b2f010ea40 4e6ac063deb8c0852fcd412e098e231e43427bd2be1330bb47b403 9ad57b30ae1fc94e34993b162ff4d695e42d59d9777ea18d3848d9 d336c25d2acb93adcad009bcfb9cde12286df267ada283063de0bb 1505565b2eb6c90e31c48798ecdc71a71756a9110ff373 msg = q128_qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqq Faz-Hernandez, et al. Expires 17 December 2022 [Page 173] Internet-Draft hash-to-curve June 2022 len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4532353624 msg_prime = 713132385f717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717171 717171717171717171717171717171717171717171717171717100 80515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4532353624 uniform_bytes = 4ac054dda0a38a65d0ecf7afd3c2812300027c8789655e47 aecf1ecc1a2426b17444c7482c99e5907afd9c25b991990490bb9c 686f43e79b4471a23a703d4b02f23c669737a886a7ec28bddb92c3 a98de63ebf878aa363a501a60055c048bea11840c4717beae7eee2 8c3cfa42857b3d130188571943a7bd747de831bd6444e0 msg = a512_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa len_in_bytes = 0x80 DST_prime = 515555582d5630312d435330322d776974682d657870616e6465 722d5348414b4532353624 msg_prime = 613531325f616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 616161616161616161616161616161616161616161616161616161 Faz-Hernandez, et al. Expires 17 December 2022 [Page 174] Internet-Draft hash-to-curve June 2022 61616161610080515555582d5630312d435330322d776974682d65 7870616e6465722d5348414b4532353624 uniform_bytes = 09afc76d51c2cccbc129c2315df66c2be7295a231203b8ab 2dd7f95c2772c68e500bc72e20c602abc9964663b7a03a389be128 c56971ce81001a0b875e7fd17822db9d69792ddf6a23a151bf4700 79c518279aef3e75611f8f828994a9988f4a8a256ddb8bae161e65 8d5a2a09bcfe839c6396dc06ee5c8ff3c22d3b1f9deb7e Authors' Addresses Armando Faz-Hernandez Cloudflare, Inc. 101 Townsend St San Francisco, United States of America Email: armfazh@cloudflare.com Sam Scott Cornell Tech 2 West Loop Rd New York, New York 10044, United States of America Email: sam.scott@cornell.edu Nick Sullivan Cloudflare, Inc. 101 Townsend St San Francisco, United States of America Email: nick@cloudflare.com Riad S. Wahby Stanford University Email: rsw@cs.stanford.edu Christopher A. Wood Cloudflare, Inc. 101 Townsend St San Francisco, United States of America Email: caw@heapingbits.net Faz-Hernandez, et al. Expires 17 December 2022 [Page 175] ./draft-irtf-cfrg-spake2-26.txt0000644000764400076440000011630214200565777016015 0ustar iustiniustin Internet Research Task Force W. Ladd Internet-Draft Sealance Intended status: Informational B. Kaduk, Ed. Expires: 12 August 2022 Akamai February 2022 SPAKE2, a PAKE draft-irtf-cfrg-spake2-26 Abstract This document describes SPAKE2 which is a protocol for two parties that share a password to derive a strong shared key without disclosing the password. This method is compatible with any group, is computationally efficient, and SPAKE2 has a security proof. This document predated the CFRG PAKE competition and it was not selected, however, given existing use of variants in Kerberos and other applications it was felt publication was beneficial. Applications that need a symmetric PAKE (password authenticated key exchange) and where hashing onto an elliptic curve at execution time is not possible can use SPAKE2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 August 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Ladd & Kaduk Expires 12 August 2022 [Page 1] Internet-Draft SPAKE2, a PAKE February 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 3. Definition of SPAKE2 . . . . . . . . . . . . . . . . . . . . 3 4. Key Schedule and Key Confirmation . . . . . . . . . . . . . . 6 5. Per-User M and N and M=N . . . . . . . . . . . . . . . . . . 7 6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Algorithm used for Point Generation . . . . . . . . 13 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction This document describes SPAKE2, a means for two parties that share a password to derive a strong shared key without disclosing the password. This password-based key exchange protocol is compatible with any group (requiring only a scheme to map a random input of fixed length per group to a random group element), is computationally efficient, and has a security proof. Predetermined parameters for a selection of commonly used groups are also provided for use by other protocols. SPAKE2 was not selected as the result of the CFRG PAKE selection competition. However, given existing use of variants in Kerberos and other applications it was felt publication was beneficial. This RFC represents the individual opinion(s) of one or more members of the Crypto Forum Research Group of the Internet Research Task Force (IRTF). Many of these applications predated methods to hash to elliptic curves being available or predated the publication of the PAKEs that were chosen as an outcome of the PAKE selection competition. In cases where a symmetric PAKE is needed, and hashing onto an elliptic curve at protocol execution time is not available, SPAKE2 is useful. Ladd & Kaduk Expires 12 August 2022 [Page 2] Internet-Draft SPAKE2, a PAKE February 2022 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Definition of SPAKE2 3.1. Protocol Flow SPAKE2 is a two round protocol, wherein the first round establishes a shared secret between A and B, and the second round serves as key confirmation. Prior to invocation, A and B are provisioned with information such as the input password needed to run the protocol. We assume that the roles of A and B are agreed upon by both sides: A goes first and uses M, and B goes second and uses N. If this assignment of roles is not possible a symmetric variant MUST be used as described later Section 5. For instance A may be the client when using TCP or TLS as an underlying protocol and B the server. Most protocols have such a distinction. During the first round, A sends a public value pA to B, and B responds with its own public value pB. Both A and B then derive a shared secret used to produce encryption and authentication keys. The latter are used during the second round for key confirmation. (Section 4 details the key derivation and confirmation steps.) In particular, A sends a key confirmation message cA to B, and B responds with its own key confirmation message cB. A MUST NOT consider the protocol complete until it receives and verifies cB. Likewise, B MUST NOT consider the protocol complete until it receives and verifies cA. This sample flow is shown below. Ladd & Kaduk Expires 12 August 2022 [Page 3] Internet-Draft SPAKE2, a PAKE February 2022 A B | (setup protocol) | | | (compute pA) | pA | |----------------->| | pB | (compute pB) |<-----------------| | | | (derive secrets) | | | (compute cA) | cA | |----------------->| | cB | (compute cB) | | (check cA) |<-----------------| (check cB) | | 3.2. Setup Let G be a group in which the gap Diffie-Hellman (GDH) problem is hard. Suppose G has order p*h where p is a large prime; h will be called the cofactor. Let I be the unit element in G, e.g., the point at infinity if G is an elliptic curve group. We denote the operations in the group additively. We assume there is a representation of elements of G as byte strings: common choices would be SEC1 [SEC1] uncompressed or compressed for elliptic curve groups or big endian integers of a fixed (per-group) length for prime field DH. Applications MUST specify this encoding, typically by referring to the document defining the group. We fix two elements M and N in the prime-order subgroup of G as defined in the table in this document for common groups, as well as a generator P of the (large) prime-order subgroup of G. In the case of a composite order group we will work in the quotient group. For common groups used in this document, P is specified in the document defining the group, and so we do not repeat it here. For elliptic curves other than the ones in this document the methods of [I-D.irtf-cfrg-hash-to-curve] SHOULD be used to generate M and N, e.g. via M = hash_to_curve("M SPAKE2 seed OID x") and N = hash_to_curve("N SPAKE2 seed OID x"), where x is an OID for the curve. Applications MAY include a DST tag in this step, as specified in [I-D.irtf-cfrg-hash-to-curve], though this is not required. || denotes concatenation of byte strings. We also let len(S) denote the length of a string in bytes, represented as an eight-byte little- endian number. Finally, let nil represent an empty string, i.e., len(nil) = 0. Text strings in double quotes are treated as their ASCII encodings throughout this document. Ladd & Kaduk Expires 12 August 2022 [Page 4] Internet-Draft SPAKE2, a PAKE February 2022 KDF(ikm, salt, info, L) is a key-derivation function that takes as input a salt, intermediate keying material (IKM), info string, and derived key length L to derive a cryptographic key of length L. MAC(key, message) is a Message Authentication Code algorithm that takes a secret key and message as input to produce an output. Let Hash be a hash function from arbitrary strings to bit strings of a fixed length, at least 256 bits long. Common choices for Hash are SHA256 or SHA512 [RFC6234]. Let MHF be a memory-hard hash function designed to slow down brute-force attackers. Scrypt [RFC7914] is a common example of this function. The output length of MHF matches that of Hash. Parameter selection for MHF is out of scope for this document. Section 6 specifies variants of KDF, MAC, and Hash suitable for use with the protocols contained herein. Let A and B be two parties. A and B may also have digital representations of the parties' identities such as Media Access Control addresses or other names (hostnames, usernames, etc). A and B may share Additional Authenticated Data (AAD) of length at most 2^16 - 128 bits that is separate from their identities which they may want to include in the protocol execution. One example of AAD is a list of supported protocol versions if SPAKE2 were used in a higher- level protocol which negotiates use of a particular PAKE. Including this list would ensure that both parties agree upon the same set of supported protocols and therefore prevent downgrade attacks. We also assume A and B share an integer w; typically w = MHF(pw) mod p, for a user-supplied password pw. Standards such as NIST.SP.800-56Ar3 suggest taking mod p of a hash value that is 64 bits longer than that needed to represent p to remove statistical bias introduced by the modulation. Protocols using this specification MUST define the method used to compute w. In some cases, it may be necessary to carry out various forms of normalization of the password before hashing [RFC8265]. The hashing algorithm SHOULD be a MHF so as to slow down brute-force attackers. 3.3. SPAKE2 To begin, A picks x randomly and uniformly from the integers in [0,p), and calculates X=x*P and pA=w*M+X, then transmits pA to B. B selects y randomly and uniformly from the integers in [0,p), and calculates Y=y*P, pB=w*N+Y, then transmits pB to A. Both A and B calculate a group element K. A calculates it as h*x*(pB-w*N), while B calculates it as h*y*(pA-w*M). A knows pB because it has received it, and likewise B knows pA. The multiplication by h prevents small subgroup confinement attacks by computing a unique value in the quotient group. Ladd & Kaduk Expires 12 August 2022 [Page 5] Internet-Draft SPAKE2, a PAKE February 2022 K is a shared value, though it MUST NOT be used or output as a shared secret from the protocol. Both A and B must derive two additional shared secrets from the protocol transcript, which includes K. This prevents man-in-the-middle attackers from inserting themselves into the exchange. The transcript TT is encoded as follows: TT = len(A) || A || len(B) || B || len(pA) || pA || len(pB) || pB || len(K) || K || len(w) || w Here w is encoded as a big endian number padded to the length of p. This representation prevents timing attacks that otherwise would reveal the length of w. len(w) is thus a constant. We include it for consistency. If an identity is absent, it is encoded as a zero-length string. This MUST only be done for applications in which identities are implicit. Otherwise, the protocol risks unknown key share attacks, where both sides of a connection disagree over who is authenticated. Upon completion of this protocol, A and B compute shared secrets Ke, KcA, and KcB as specified in Section 4. A MUST send B a key confirmation message so both parties agree upon these shared secrets. This confirmation message cA is computed as a MAC over the protocol transcript TT using KcA, as follows: cA = MAC(KcA, TT). Similarly, B MUST send A a confirmation message using a MAC computed equivalently except with the use of KcB. Key confirmation verification requires computing cB and checking for equality against that which was received. 4. Key Schedule and Key Confirmation The protocol transcript TT, as defined in Section 3.3, is unique and secret to A and B. Both parties use TT to derive shared symmetric secrets Ke and Ka as Ke || Ka = Hash(TT), with |Ke| = |Ka|. The length of each key is equal to half of the digest output, e.g., 128 bits for SHA-256. Keys MUST be at least 128 bits in length. Ladd & Kaduk Expires 12 August 2022 [Page 6] Internet-Draft SPAKE2, a PAKE February 2022 Both endpoints use Ka to derive subsequent MAC keys for key confirmation messages. Specifically, let KcA and KcB be the MAC keys used by A and B, respectively. A and B compute them as KcA || KcB = KDF(Ka, nil, "ConfirmationKeys" || AAD, L), where AAD is the associated data each given to each endpoint, or nil if none was provided. The length of each of KcA and KcB is equal to half of the underlying hash output length, e.g., |KcA| = |KcB| = 128 bits for HKDF(SHA256), with L=256 bits. The resulting key schedule for this protocol, given transcript TT and additional associated data AAD, is as follows. TT -> Hash(TT) = Ke || Ka AAD -> KDF(Ka, nil, "ConfirmationKeys" || AAD) = KcA || KcB A and B output Ke as the shared secret from the protocol. Ka and its derived keys are not used for anything except key confirmation. 5. Per-User M and N and M=N To avoid concerns that an attacker needs to solve a single ECDH instance to break the authentication of SPAKE2, it is possible to vary M and N using [I-D.irtf-cfrg-hash-to-curve] as follows: M = hash_to_curve(Hash("M SPAKE2" || len(A) || A || len(B) || B)) N = hash_to_curve(Hash("N SPAKE2" || len(A) || A || len(B) || B)) There is also a symmetric variant where M=N. For this variant we set M = hash_to_curve(Hash("M AND N SPAKE2")) This variant MUST be used when it is not possible to determine which of A and B should use M or N, due to asymmetries in the protocol flows or the desire to use only a single shared secret with nil identities for authentication. The security of these variants is examined in [MNVAR]. The variant with per-user M and N may not be suitable for protocols that require the initial messages to be generated by each party at the same time and do not know the exact identity of the parties before the flow begins. 6. Ciphersuites This section documents SPAKE2 ciphersuite configurations. A ciphersuite indicates a group, cryptographic hash function, and pair of KDF and MAC functions, e.g., SPAKE2-P256-SHA256-HKDF-HMAC. This ciphersuite indicates a SPAKE2 protocol instance over P-256 that uses SHA256 along with HKDF [RFC5869] and HMAC [RFC2104] for G, Hash, KDF, and MAC functions, respectively. For Ed25519 the compressed encoding Ladd & Kaduk Expires 12 August 2022 [Page 7] Internet-Draft SPAKE2, a PAKE February 2022 is used [RFC8032], all others use the uncompressed SEC1 encoding. +==============+==================+================+================+ | G | Hash | KDF | MAC | +==============+==================+================+================+ | P-256 | SHA256 [RFC6234] | HKDF [RFC5869] | HMAC | | | | | [RFC2104] | +--------------+------------------+----------------+----------------+ | P-256 | SHA512 [RFC6234] | HKDF [RFC5869] | HMAC | | | | | [RFC2104] | +--------------+------------------+----------------+----------------+ | P-384 | SHA256 [RFC6234] | HKDF [RFC5869] | HMAC | | | | | [RFC2104] | +--------------+------------------+----------------+----------------+ | P-384 | SHA512 [RFC6234] | HKDF [RFC5869] | HMAC | | | | | [RFC2104] | +--------------+------------------+----------------+----------------+ | P-521 | SHA512 [RFC6234] | HKDF [RFC5869] | HMAC | | | | | [RFC2104] | +--------------+------------------+----------------+----------------+ | edwards25519 | SHA256 [RFC6234] | HKDF [RFC5869] | HMAC | | [RFC8032] | | | [RFC2104] | +--------------+------------------+----------------+----------------+ | edwards448 | SHA512 [RFC6234] | HKDF [RFC5869] | HMAC | | [RFC8032] | | | [RFC2104] | +--------------+------------------+----------------+----------------+ | P-256 | SHA256 [RFC6234] | HKDF [RFC5869] | CMAC-AES-128 | | | | | [RFC4493] | +--------------+------------------+----------------+----------------+ | P-256 | SHA512 [RFC6234] | HKDF [RFC5869] | CMAC-AES-128 | | | | | [RFC4493] | +--------------+------------------+----------------+----------------+ Table 1: SPAKE2 Ciphersuites The following points represent permissible point generation seeds for the groups listed in the Table Table 1, using the algorithm presented in Appendix A. These bytestrings are compressed points as in [SEC1] for curves from [SEC1]. For P256: Ladd & Kaduk Expires 12 August 2022 [Page 8] Internet-Draft SPAKE2, a PAKE February 2022 M = 02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f seed: 1.2.840.10045.3.1.7 point generation seed (M) N = 03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49 seed: 1.2.840.10045.3.1.7 point generation seed (N) For P384: M = 030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3dc 36f15314739074d2eb8613fceec2853 seed: 1.3.132.0.34 point generation seed (M) N = 02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543bb 252c5490214cf9aa3f0baab4b665c10 seed: 1.3.132.0.34 point generation seed (N) For P521: M = 02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d85608 cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7aa seed: 1.3.132.0.35 point generation seed (M) N = 0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e494b25 32d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd25 seed: 1.3.132.0.35 point generation seed (N) For edwards25519: M = d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf seed: edwards25519 point generation seed (M) N = d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab seed: edwards25519 point generation seed (N) For edwards448: Ladd & Kaduk Expires 12 August 2022 [Page 9] Internet-Draft SPAKE2, a PAKE February 2022 M = b6221038a775ecd007a4e4dde39fd76ae91d3cf0cc92be8f0c2fa6d6b66f9a12 942f5a92646109152292464f3e63d354701c7848d9fc3b8880 seed: edwards448 point generation seed (M) N = 6034c65b66e4cd7a49b0edec3e3c9ccc4588afd8cf324e29f0a84a072531c4db f97ff9af195ed714a689251f08f8e06e2d1f24a0ffc0146600 seed: edwards448 point generation seed (N) 7. Security Considerations A security proof of SPAKE2 for prime order groups is found in [REF], reducing the security of SPAKE2 to the gap Diffie-Hellman assumption. Note that the choice of M and N is critical for the security proof. The generation methods specified in this document are designed to eliminate concerns related to knowing discrete logs of M and N. Elements received from a peer MUST be checked for group membership: failure to properly deserialize and validate group elements can lead to attacks. An endpoint MUST abort the protocol if any received public value is not a member of G. The choices of random numbers MUST BE uniform. Randomly generated values, e.g., x and y, MUST NOT be reused; such reuse violates the security assumptions of the protocol and results in significant insecurity. It is RECOMMENDED to generate these uniform numbers using rejection sampling. Some implementations of elliptic curve multiplication may leak information about the length of the scalar. These MUST NOT be used. All operations on elliptic curve points must take time independent of the inputs. Hashing of the transcript may take time depending only on the length of the transcript, but not the contents. SPAKE2 does not support augmentation. As a result, the server has to store a password equivalent. This is considered a significant drawback in some use cases. Applications that need augmented PAKEs should use [I-D.irtf-cfrg-opaque]. The HMAC keys in this document are shorter than recommended in [RFC8032]. This is appropriate as the difficulty of the discrete logarithm problem is comparable with the difficulty of brute forcing the keys. Ladd & Kaduk Expires 12 August 2022 [Page 10] Internet-Draft SPAKE2, a PAKE February 2022 8. IANA Considerations No IANA action is required. 9. Acknowledgments Special thanks to Nathaniel McCallum and Greg Hudson for generation of M and N, and Chris Wood for test vectors. Thanks to Mike Hamburg for advice on how to deal with cofactors. Greg Hudson also suggested the addition of warnings on the reuse of x and y. Thanks to Fedor Brunner, Adam Langley, Liliya Akhmetzyanova, and the members of the CFRG for comments and advice. Thanks to Scott Fluhrer and those Crypto Panel experts involved in the PAKE selection process (https://github.com/cfrg/pake-selection) who have provided valuable comments. Chris Wood contributed substantial text and reformatting to address the excellent review comments from Kenny Paterson. 10. References 10.1. Normative References [I-D.irtf-cfrg-hash-to-curve] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R., and C. Wood, "Hashing to Elliptic Curves", Work in Progress, Internet-Draft, draft-irtf-cfrg-hash-to-curve-05, 2 November 2019, . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2006, . [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, . Ladd & Kaduk Expires 12 August 2022 [Page 11] Internet-Draft SPAKE2, a PAKE February 2022 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, August 2016, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [SEC1] Standards for Efficient Cryptography Group, "SEC 1: Elliptic Curve Cryptography", May 2009. [MNVAR] Abdalla, M., Barbosa, M., Bradley, T., Jarecki, S., Katz, J., and J. Xu, "Universally Composable Relaxed Password Authentication", August 2020. Appears in Micciancio D., Ristenpart T. (eds) Advances in Cryptology -CRYPTO 2020. Crypto 2020. Lecture notes in Computer Science volume 12170. Springer. [REF] Abdalla, M. and D. Pointcheval, "Simple Password-Based Encrypted Key Exchange Protocols.", February 2005. Appears in A. Menezes, editor. Topics in Cryptography- CT-RSA 2005, Volume 3376 of Lecture Notes in Computer Science, pages 191-208, San Francisco, CA, US. Springer- Verlag, Berlin, Germany. [TDH] Cash, D., Kiltz, E., and V. Shoup, "The Twin-Diffie Hellman Problem and Applications", 2008. EUROCRYPT 2008. Volume 4965 of Lecture notes in Computer Science, pages 127-145. Springer-Verlag, Berlin, Germany. Ladd & Kaduk Expires 12 August 2022 [Page 12] Internet-Draft SPAKE2, a PAKE February 2022 [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 8265, DOI 10.17487/RFC8265, October 2017, . [I-D.irtf-cfrg-opaque] Krawczyk, H., Bourdrez, D., Lewi, K., and C. A. Wood, "The OPAQUE Asymmetric PAKE Protocol", Work in Progress, Internet-Draft, draft-irtf-cfrg-opaque-06, 12 July 2021, . Appendix A. Algorithm used for Point Generation This section describes the algorithm that was used to generate the points M and N in the table in Section 6. For each curve in the table below, we construct a string using the curve OID from [RFC5480] (as an ASCII string) or its name, combined with the needed constant, e.g., "1.3.132.0.35 point generation seed (M)" for P-521. This string is turned into a series of blocks by hashing with SHA256, and hashing that output again to generate the next 32 bytes, and so on. This pattern is repeated for each group and value, with the string modified appropriately. A byte string of length equal to that of an encoded group element is constructed by concatenating as many blocks as are required, starting from the first block, and truncating to the desired length. The byte string is then formatted as required for the group. In the case of Weierstrass curves, we take the desired length as the length for representing a compressed point (section 2.3.4 of [SEC1]), and use the low-order bit of the first byte as the sign bit. In order to obtain the correct format, the value of the first byte is set to 0x02 or 0x03 (clearing the first six bits and setting the seventh bit), leaving the sign bit as it was in the byte string constructed by concatenating hash blocks. For the [RFC8032] curves a different procedure is used. For edwards448 the 57-byte input has the least- significant 7 bits of the last byte set to zero, and for edwards25519 the 32-byte input is not modified. For both the [RFC8032] curves the (modified) input is then interpreted as the representation of the group element. If this interpretation yields a valid group element with the correct order (p), the (modified) byte string is the output. Otherwise, the initial hash block is discarded and a new byte string constructed from the remaining hash blocks. The procedure of constructing a byte string of the appropriate length, formatting it as required for the curve, and checking if it is a valid point of the correct order, is repeated until a valid element is found. Ladd & Kaduk Expires 12 August 2022 [Page 13] Internet-Draft SPAKE2, a PAKE February 2022 The following python snippet generates the above points, assuming an elliptic curve implementation following the interface of Edwards25519Point.stdbase() and Edwards448Point.stdbase() in Appendix A of [RFC8032]: def iterated_hash(seed, n): h = seed for i in range(n): h = hashlib.sha256(h).digest() return h def bighash(seed, start, sz): n = -(-sz // 32) hashes = [iterated_hash(seed, i) for i in range(start, start + n)] return b''.join(hashes)[:sz] def canon_pointstr(ecname, s): if ecname == 'edwards25519': return s elif ecname == 'edwards448': return s[:-1] + bytes([s[-1] & 0x80]) else: return bytes([(s[0] & 1) | 2]) + s[1:] def gen_point(seed, ecname, ec): for i in range(1, 1000): hval = bighash(seed, i, len(ec.encode())) pointstr = canon_pointstr(ecname, hval) try: p = ec.decode(pointstr) if p != ec.zero_elem() and p * p.l() == ec.zero_elem(): return pointstr, i except Exception: pass Appendix B. Test Vectors This section contains test vectors for SPAKE2 using the P256-SHA256- HKDF-HMAC ciphersuite. (Choice of MHF is omitted and values for w, x, and y are provided directly.) All points are encoded using the uncompressed format, i.e., with a 0x04 octet prefix, specified in [SEC1] A and B identity strings are provided in the protocol invocation. B.1. SPAKE2 Test Vectors Ladd & Kaduk Expires 12 August 2022 [Page 14] Internet-Draft SPAKE2, a PAKE February 2022 spake2: A='server', B='client' w = 0x2ee57912099d31560b3a44b1184b9b4866e904c49d12ac5042c97dca461b1a5f x = 0x43dd0fd7215bdcb482879fca3220c6a968e66d70b1356cac18bb26c84a78d729 pA = 0x04a56fa807caaa53a4d28dbb9853b9815c61a411118a6fe516a8798434751470 f9010153ac33d0d5f2047ffdb1a3e42c9b4e6be662766e1eeb4116988ede5f912c y = 0xdcb60106f276b02606d8ef0a328c02e4b629f84f89786af5befb0bc75b6e66be pB = 0x0406557e482bd03097ad0cbaa5df82115460d951e3451962f1eaf4367a420676 d09857ccbc522686c83d1852abfa8ed6e4a1155cf8f1543ceca528afb591a1e0b7 K = 0x0412af7e89717850671913e6b469ace67bd90a4df8ce45c2af19010175e37eed 69f75897996d539356e2fa6a406d528501f907e04d97515fbe83db277b715d3325 TT = 0x06000000000000007365727665720600000000000000636c69656e744100000 00000000004a56fa807caaa53a4d28dbb9853b9815c61a411118a6fe516a8798434751 470f9010153ac33d0d5f2047ffdb1a3e42c9b4e6be662766e1eeb4116988ede5f912c4 1000000000000000406557e482bd03097ad0cbaa5df82115460d951e3451962f1eaf43 67a420676d09857ccbc522686c83d1852abfa8ed6e4a1155cf8f1543ceca528afb591a 1e0b741000000000000000412af7e89717850671913e6b469ace67bd90a4df8ce45c2a f19010175e37eed69f75897996d539356e2fa6a406d528501f907e04d97515fbe83db2 77b715d332520000000000000002ee57912099d31560b3a44b1184b9b4866e904c49d1 2ac5042c97dca461b1a5f Hash(TT) = 0x0e0672dc86f8e45565d338b0540abe6915bdf72e2b35b5c9e5663168e960a91b Ke = 0x0e0672dc86f8e45565d338b0540abe69 Ka = 0x15bdf72e2b35b5c9e5663168e960a91b KcA = 0x00c12546835755c86d8c0db7851ae86f KcB = 0xa9fa3406c3b781b93d804485430ca27a A conf = 0x58ad4aa88e0b60d5061eb6b5dd93e80d9c4f00d127c65b3b35b1b5281fee38f0 B conf = 0xd3e2e547f1ae04f2dbdbf0fc4b79f8ecff2dff314b5d32fe9fcef2fb26dc459b spake2: A='', B='client' w = 0x0548d8729f730589e579b0475a582c1608138ddf7054b73b5381c7e883e2efae x = 0x403abbe3b1b4b9ba17e3032849759d723939a27a27b9d921c500edde18ed654b pA = 0x04a897b769e681c62ac1c2357319a3d363f610839c4477720d24cbe32f5fd85f 44fb92ba966578c1b712be6962498834078262caa5b441ecfa9d4a9485720e918a y = 0x903023b6598908936ea7c929bd761af6039577a9c3f9581064187c3049d87065 pB = 0x04e0f816fd1c35e22065d5556215c097e799390d16661c386e0ecc84593974a6 1b881a8c82327687d0501862970c64565560cb5671f696048050ca66ca5f8cc7fc K = 0x048f83ec9f6e4f87cc6f9dc740bdc2769725f923364f01c84148c049a39a735e bda82eac03e00112fd6a5710682767cff5361f7e819e53d8d3c3a2922e0d837aa6 TT = 0x00000000000000000600000000000000636c69656e74410000000000000004a 897b769e681c62ac1c2357319a3d363f610839c4477720d24cbe32f5fd85f44fb92ba9 66578c1b712be6962498834078262caa5b441ecfa9d4a9485720e918a4100000000000 00004e0f816fd1c35e22065d5556215c097e799390d16661c386e0ecc84593974a61b8 81a8c82327687d0501862970c64565560cb5671f696048050ca66ca5f8cc7fc4100000 000000000048f83ec9f6e4f87cc6f9dc740bdc2769725f923364f01c84148c049a39a7 35ebda82eac03e00112fd6a5710682767cff5361f7e819e53d8d3c3a2922e0d837aa62 0000000000000000548d8729f730589e579b0475a582c1608138ddf7054b73b5381c7e 883e2efae Hash(TT) = 0x642f05c473c2cd79909f9a841e2f30a70bf89b18180af97353ba198789c2b963 Ladd & Kaduk Expires 12 August 2022 [Page 15] Internet-Draft SPAKE2, a PAKE February 2022 Ke = 0x642f05c473c2cd79909f9a841e2f30a7 Ka = 0x0bf89b18180af97353ba198789c2b963 KcA = 0xc6be376fc7cd1301fd0a13adf3e7bffd KcB = 0xb7243f4ae60440a49b3f8cab3c1fba07 A conf = 0x47d29e6666af1b7dd450d571233085d7a9866e4d49d2645e2df975489521232b B conf = 0x3313c5cefc361d27fb16847a91c2a73b766ffa90a4839122a9b70a2f6bd1d6df spake2: A='server', B='' w = 0x626e0cdc7b14c9db3e52a0b1b3a768c98e37852d5db30febe0497b14eae8c254 x = 0x07adb3db6bc623d3399726bfdbfd3d15a58ea776ab8a308b00392621291f9633 pA = 0x04f88fb71c99bfffaea370966b7eb99cd4be0ff1a7d335caac4211c4afd855e2 e15a873b298503ad8ba1d9cbb9a392d2ba309b48bfd7879aefd0f2cea6009763b0 y = 0xb6a4fc8dbb629d4ba51d6f91ed1532cf87adec98f25dd153a75accafafedec16 pB = 0x040c269d6be017dccb15182ac6bfcd9e2a14de019dd587eaf4bdfd353f031101 e7cca177f8eb362a6e83e7d5e729c0732e1b528879c086f39ba0f31a9661bd34db K = 0x0445ee233b8ecb51ebd6e7da3f307e88a1616bae2166121221fdc0dadb986afa f3ec8a988dc9c626fa3b99f58a7ca7c9b844bb3e8dd9554aafc5b53813504c1cbe TT = 0x06000000000000007365727665720000000000000000410000000000000004f 88fb71c99bfffaea370966b7eb99cd4be0ff1a7d335caac4211c4afd855e2e15a873b2 98503ad8ba1d9cbb9a392d2ba309b48bfd7879aefd0f2cea6009763b04100000000000 000040c269d6be017dccb15182ac6bfcd9e2a14de019dd587eaf4bdfd353f031101e7c ca177f8eb362a6e83e7d5e729c0732e1b528879c086f39ba0f31a9661bd34db4100000 0000000000445ee233b8ecb51ebd6e7da3f307e88a1616bae2166121221fdc0dadb986 afaf3ec8a988dc9c626fa3b99f58a7ca7c9b844bb3e8dd9554aafc5b53813504c1cbe2 000000000000000626e0cdc7b14c9db3e52a0b1b3a768c98e37852d5db30febe0497b1 4eae8c254 Hash(TT) = 0x005184ff460da2ce59062c87733c299c3521297d736598fc0a1127600efa1afb Ke = 0x005184ff460da2ce59062c87733c299c Ka = 0x3521297d736598fc0a1127600efa1afb KcA = 0xf3da53604f0aeecea5a33be7bddf6edf KcB = 0x9e3f86848736f159bd92b6e107ec6799 A conf = 0xbc9f9bbe99f26d0b2260e6456e05a86196a3307ec6663a18bf6ac825736533b2 B conf = 0xc2370e1bf813b086dff0d834e74425a06e6390f48f5411900276dcccc5a297ec spake2: A='', B='' w = 0x7bf46c454b4c1b25799527d896508afd5fc62ef4ec59db1efb49113063d70cca x = 0x8cef65df64bb2d0f83540c53632de911b5b24b3eab6cc74a97609fd659e95473 pA = 0x04a65b367a3f613cf9f0654b1b28a1e3a8a40387956c8ba6063e8658563890f4 6ca1ef6a676598889fc28de2950ab8120b79a5ef1ea4c9f44bc98f585634b46d66 y = 0xd7a66f64074a84652d8d623a92e20c9675c61cb5b4f6a0063e4648a2fdc02d53 pB = 0x04589f13218822710d98d8b2123a079041052d9941b9cf88c6617ddb2fcc0494 662eea8ba6b64692dc318250030c6af045cb738bc81ba35b043c3dcb46adf6f58d K = 0x041a3c03d51b452537ca2a1fea6110353c6d5ed483c4f0f86f4492ca3f378d40 a994b4477f93c64d928edbbcd3e85a7c709b7ea73ee97986ce3d1438e135543772 TT = 0x00000000000000000000000000000000410000000000000004a65b367a3f613 cf9f0654b1b28a1e3a8a40387956c8ba6063e8658563890f46ca1ef6a676598889fc28 de2950ab8120b79a5ef1ea4c9f44bc98f585634b46d66410000000000000004589f132 18822710d98d8b2123a079041052d9941b9cf88c6617ddb2fcc0494662eea8ba6b6469 Ladd & Kaduk Expires 12 August 2022 [Page 16] Internet-Draft SPAKE2, a PAKE February 2022 2dc318250030c6af045cb738bc81ba35b043c3dcb46adf6f58d4100000000000000041 a3c03d51b452537ca2a1fea6110353c6d5ed483c4f0f86f4492ca3f378d40a994b4477 f93c64d928edbbcd3e85a7c709b7ea73ee97986ce3d1438e1355437722000000000000 0007bf46c454b4c1b25799527d896508afd5fc62ef4ec59db1efb49113063d70cca Hash(TT) = 0xfc6374762ba5cf11f4b2caa08b2cd1b9907ae0e26e8d6234318d91583cd74c86 Ke = 0xfc6374762ba5cf11f4b2caa08b2cd1b9 Ka = 0x907ae0e26e8d6234318d91583cd74c86 KcA = 0x5dbd2f477166b7fb6d61febbd77a5563 KcB = 0x7689b4654407a5faeffdc8f18359d8a3 A conf = 0xdfb4db8d48ae5a675963ea5e6c19d98d4ea028d8e898dad96ea19a80ade95dca B conf = 0xd0f0609d1613138d354f7e95f19fb556bf52d751947241e8c7118df5ef0ae175 Authors' Addresses Watson Ladd Sealance Email: watsonbladd@gmail.com Benjamin Kaduk (editor) Akamai Technologies Email: kaduk@mit.edu Ladd & Kaduk Expires 12 August 2022 [Page 17] ./draft-irtf-pearg-numeric-ids-generation-12.txt0000644000764400076440000030424314345316060021340 0ustar iustiniustin Internet Research Task Force (IRTF) F. Gont Internet-Draft SI6 Networks Intended status: Informational I. Arce Expires: 14 June 2023 Quarkslab 11 December 2022 On the Generation of Transient Numeric Identifiers draft-irtf-pearg-numeric-ids-generation-12 Abstract This document performs an analysis of the security and privacy implications of different types of "transient numeric identifiers" used in IETF protocols, and tries to categorize them based on their interoperability requirements and their associated failure severity when such requirements are not met. Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier category, while minimizing the negative security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, it describes a number of algorithms that have been employed in real implementations to generate transient numeric identifiers, and analyzes their security and privacy properties. This document is a product of the Privacy Enhancement and Assessment Research Group (PEARG) in the IRTF. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Gont & Arce Expires 14 June 2023 [Page 1] Internet-Draft Generation of Transient Numeric IDs December 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Issues with the Specification of Transient Numeric Identifiers . . . . . . . . . . . . . . . . . . . . . . . 6 5. Protocol Failure Severity . . . . . . . . . . . . . . . . . . 7 6. Categorizing Transient Numeric Identifiers . . . . . . . . . 7 7. Common Algorithms for Transient Numeric Identifier Generation . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Category #1: Uniqueness (soft failure) . . . . . . . . . 10 7.2. Category #2: Uniqueness (hard failure) . . . . . . . . . 14 7.3. Category #3: Uniqueness, stable within context (soft failure) . . . . . . . . . . . . . . . . . . . . . . . . 15 7.4. Category #4: Uniqueness, monotonically increasing within context (hard failure) . . . . . . . . . . . . . . . . . 17 8. Common Vulnerabilities Associated with Transient Numeric Identifiers . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Network Activity Correlation . . . . . . . . . . . . . . 23 8.2. Information Leakage . . . . . . . . . . . . . . . . . . . 24 8.3. Fingerprinting . . . . . . . . . . . . . . . . . . . . . 25 8.4. Exploitation of the Semantics of Transient Numeric Identifiers . . . . . . . . . . . . . . . . . . . . . . . 26 8.5. Exploitation of Collisions of Transient Numeric Identifiers . . . . . . . . . . . . . . . . . . . . . . . 27 8.6. Exploitation of Predictable Transient Numeric Identifiers for Injection Attacks . . . . . . . . . . . . . . . . . . 27 8.7. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 28 9. Vulnerability Assessment of Transient Numeric Identifiers . . 28 9.1. Category #1: Uniqueness (soft failure) . . . . . . . . . 28 9.2. Category #2: Uniqueness (hard failure) . . . . . . . . . 29 9.3. Category #3: Uniqueness, stable within context (soft failure) . . . . . . . . . . . . . . . . . . . . . . . . 29 9.4. Category #4: Uniqueness, monotonically increasing within context (hard failure) . . . . . . . . . . . . . . . . . 30 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 13.1. Normative References . . . . . . . . . . . . . . . . . . 33 13.2. Informative References . . . . . . . . . . . . . . . . . 35 Gont & Arce Expires 14 June 2023 [Page 2] Internet-Draft Generation of Transient Numeric IDs December 2022 Appendix A. Algorithms and Techniques with Known Issues . . . . 41 A.1. Predictable Linear Identifiers Algorithm . . . . . . . . 41 A.2. Random-Increments Algorithm . . . . . . . . . . . . . . . 43 A.3. Re-using Identifiers Across Different Contexts . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction Networking protocols employ a variety of transient numeric identifiers for different protocol objects, such as IPv4 and IPv6 Fragment Identifiers [RFC0791] [RFC8200], IPv6 Interface Identifiers (IIDs) [RFC4291], transport protocol ephemeral port numbers [RFC6056], TCP Initial Sequence Numbers (ISNs) [RFC0793], and DNS Query IDs [RFC1035].These identifiers usually have specific interoperability requirements (e.g. uniqueness during a specified period of time) that must be satisfied such that they do not result in negative interoperability implications, and an associated failure severity when such requirements are not met, ranging from soft to hard failures. For more than 30 years, a large number of implementations of IETF protocols have been subject to a variety of attacks, with effects ranging from Denial of Service (DoS) or data injection, to information leakages that could be exploited for pervasive monitoring [RFC7258]. The root cause of these issues has been, in many cases, the poor selection of transient numeric identifiers in such protocols, usually as a result of insufficient or misleading specifications. While it is generally trivial to identify an algorithm that can satisfy the interoperability requirements of a given transient numeric identifier, empirical evidence exists that doing so without negatively affecting the security and/or privacy properties of the aforementioned protocols is prone to error [I-D.irtf-pearg-numeric-ids-history]. For example, implementations have been subject to security and/or privacy issues resulting from: * Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. [Sanfilippo1998a], [RFC6274], and [RFC7739]) * Predictable IPv6 IIDs (see e.g. [RFC7721], [RFC7707], and [RFC7217]) * Predictable transport protocol ephemeral port numbers (see e.g. [RFC6056] and [Silbersack2005]) * Predictable TCP Initial Sequence Numbers (ISNs) (see e.g. [Morris1985], [Bellovin1989], and [RFC6528]) Gont & Arce Expires 14 June 2023 [Page 3] Internet-Draft Generation of Transient Numeric IDs December 2022 * Predictable initial timestamps in TCP timestamps Options (see e.g. [TCPT-uptime] and [RFC7323]) * Predictable DNS Query IDs (see e.g. [Schuba1993] and [Klein2007]) Recent history indicates that when new protocols are standardized or new protocol implementations are produced, the security and privacy properties of the associated transient numeric identifiers tend to be overlooked, and inappropriate algorithms to generate transient numeric identifiers are either suggested in the specifications or selected by implementers. As a result, it should be evident that advice in this area is warranted. We note that the use of cryptographic techniques may readily mitigate some of the issues arising from predictable transient numeric identifiers. For example, cryptographic integrity and authentication can readily mitigate data injection attacks even in the presence of predictable transient numeric identifiers (such as "sequence numbers"). However, use of flawed algorithms (such as global counters) for generating transient numeric identifiers could still result in information leakages even when cryptographic techniques are employed. This document contains a non-exhaustive survey of transient numeric identifiers employed in various IETF protocols, and aims to categorize such identifiers based on their interoperability requirements, and the associated failure severity when such requirements are not met. Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each category, while minimizing negative security and privacy implications. Finally, it analyzes several algorithms that have been employed in real implementations to meet such requirements, and analyzes their security and privacy properties. This document represents the consensus of the Privacy Enhancement and Assessment Research Group (PEARG). 2. Terminology Transient Numeric Identifier: A data object in a protocol specification that can be used to definitely distinguish a protocol object (a datagram, network interface, transport protocol endpoint, session, etc.) from all other objects of the same type, in a given context. Transient numeric identifiers are usually defined as a series of bits, and represented using integer values. These identifiers are typically dynamically selected, as opposed to statically-assigned numeric Gont & Arce Expires 14 June 2023 [Page 4] Internet-Draft Generation of Transient Numeric IDs December 2022 identifiers (see e.g. [IANA-PROT]). We note that different transient numeric identifiers may have additional requirements or properties depending on their specific use in a protocol. We use the term "transient numeric identifier" (or simply "numeric identifier" or "identifier" as short forms) as a generic term to refer to any data object in a protocol specification that satisfies the identification property stated above. Failure Severity: The interoperability consequences of a failure to comply with the interoperability requirements of a given identifier. Severity considers the worst potential consequence of a failure, determined by the system damage and/or time lost to repair the failure. In this document we define two types of failure severity: "soft failure" and "hard failure". Soft Failure: A soft failure is a recoverable condition in which a protocol does not operate in the prescribed manner but normal operation can be resumed automatically in a short period of time. For example, a simple packet-loss event that is subsequently recovered with a packet-retransmission can be considered a soft failure. Hard Failure: A hard failure is a non-recoverable condition in which a protocol does not operate in the prescribed manner or it operates with excessive degradation of service. For example, an established TCP connection that is aborted due to an error condition constitutes, from the point of view of the transport protocol, a hard failure, since it enters a state from which normal operation cannot be resumed. 3. Threat Model Throughout this document, we do not consider on-path attacks. That is, we assume an attacker does not have physical or logical access to the system(s) being attacked, and that the attacker can only observe traffic explicitly directed to the attacker. Similarly, an attacker cannot observe traffic transferred between a sender and the receiver(s) of a target protocol, but may be able to interact with any of these entities, including by e.g. sending traffic to them to sample transient numeric identifiers employed by the target systems when communicating with the attacker. For example, when analyzing vulnerabilities associated with TCP Initial Sequence Numbers (ISNs), we consider the attacker is unable to capture network traffic corresponding to a TCP connection between two other hosts. However, we consider the attacker is able to Gont & Arce Expires 14 June 2023 [Page 5] Internet-Draft Generation of Transient Numeric IDs December 2022 communicate with any of these hosts (e.g., establish a TCP connection with any of them), to e.g. sample the TCP ISNs employed by these systems when communicating with the attacker. Similarly, when considering host-tracking attacks based on IPv6 interface identifiers, we consider an attacker may learn the IPv6 address employed by a victim node if e.g. the address becomes exposed as a result of the victim node communicating with an attacker- operated server. Subsequently, an attacker may perform host-tracking by probing a set of target addresses composed by a set of target prefixes and the IPv6 interface identifier originally learned by the attacker. Alternatively, an attacker may perform host tracking if e.g. the victim node communicates with an attacker-operated server as it moves from one location to another, those exposing its configured addresses. We note that none of these scenarios requires the attacker observe traffic not explicitly directed to the attacker. 4. Issues with the Specification of Transient Numeric Identifiers While assessing protocol specifications regarding the use of transient numeric identifiers, we have found that most of the issues discussed in this document arise as a result of one of the following conditions: * Protocol specifications that under-specify the requirements for their transient numeric identifiers * Protocol specifications that over-specify their transient numeric identifiers * Protocol implementations that simply fail to comply with the specified requirements A number of protocol specifications (too many of them) have simply overlooked the security and privacy implications of transient numeric identifiers [I-D.irtf-pearg-numeric-ids-history]. Examples of them are the specification of TCP ephemeral ports in [RFC0793], the specification of TCP sequence numbers in [RFC0793], or the specification of the DNS Query ID in [RFC1035]. On the other hand, there are a number of protocol specifications that over-specify some of their associated transient numeric identifiers. For example, [RFC4291] essentially overloads the semantics of IPv6 Interface Identifiers (IIDs) by embedding link-layer addresses in the IPv6 IIDs, when the interoperability requirement of uniqueness could be achieved in other ways that do not result in negative security and privacy implications [RFC7721]. Similarly, [RFC2460] suggested the use of a global counter for the generation of Fragment Identification Gont & Arce Expires 14 June 2023 [Page 6] Internet-Draft Generation of Transient Numeric IDs December 2022 values, when the interoperability properties of uniqueness per {IPv6 Source Address, IPv6 Destination Address} could be achieved with other algorithms that do not result in negative security and privacy implications [RFC7739]. Finally, there are protocol implementations that simply fail to comply with existing protocol specifications. For example, some popular operating systems (notably Microsoft Windows) still fail to implement transport protocol ephemeral port randomization, as recommended in [RFC6056]. 5. Protocol Failure Severity Section 2 defines the concept of "Failure Severity", along with two types of failure severities that we employ throughout this document: soft and hard. Our analysis of the severity of a failure is performed from the point of view of the protocol in question. However, the corresponding severity on the upper protocol (or application) might not be the same as that of the protocol in question. For example, a TCP connection that is aborted might or might not result in a hard failure of the upper application: if the upper application can establish a new TCP connection without any impact on the application, a hard failure at the TCP protocol may have no severity at the application level. On the other hand, if a hard failure of a TCP connection results in excessive degradation of service at the application layer, it will also result in a hard failure at the application. 6. Categorizing Transient Numeric Identifiers This section includes a non-exhaustive survey of transient numeric identifiers, which are representative of all the possible combinations of interoperability requirements and failure severities found in popular protocols from different layers. Additionally, it proposes a number of categories that can accommodate these identifiers based on their interoperability requirements and their associated failure severity (soft or hard). NOTE: All other transient numeric identifiers that were analyzed as part of this effort could be accommodated into one of the existing categories from Table 1. Gont & Arce Expires 14 June 2023 [Page 7] Internet-Draft Generation of Transient Numeric IDs December 2022 +==============+===============================+==================+ | Identifier | Interoperability Requirements | Failure Severity | +==============+===============================+==================+ | IPv6 Frag ID | Uniqueness (for IP address | Soft/Hard (1) | | | pair) | | +--------------+-------------------------------+------------------+ | IPv6 IID | Uniqueness (and stable within | Soft (3) | | | IPv6 prefix) (2) | | +--------------+-------------------------------+------------------+ | TCP ISN | Monotonically-increasing (4) | Hard (4) | +--------------+-------------------------------+------------------+ | TCP initial | Monotonically-increasing (5) | Hard (5) | | timestamp | | | +--------------+-------------------------------+------------------+ | TCP eph. | Uniqueness (for connection | Hard | | port | ID) | | +--------------+-------------------------------+------------------+ | IPv6 Flow | Uniqueness | None (6) | | Label | | | +--------------+-------------------------------+------------------+ | DNS Query ID | Uniqueness | None (7) | +--------------+-------------------------------+------------------+ Table 1: Survey of Transient Numeric Identifiers NOTE: (1) While a single collision of Fragment ID values would simply lead to a single packet drop (and hence a "soft" failure), repeated collisions at high data rates might result in self-propagating collisions of Fragment IDs, thus possibly leading to a hard failure [RFC4963]. (2) While the interoperability requirements are simply that the Interface ID results in a unique IPv6 address, for operational reasons it is typically desirable that the resulting IPv6 address (and hence the corresponding Interface ID) be stable within each network [RFC7217] [RFC8064]. (3) While IPv6 Interface IDs must result in unique IPv6 addresses, IPv6 Duplicate Address Detection (DAD) [RFC4862] allows for the detection of duplicate addresses, and hence such Interface ID collisions can be recovered. Gont & Arce Expires 14 June 2023 [Page 8] Internet-Draft Generation of Transient Numeric IDs December 2022 (4) In theory, there are no interoperability requirements for TCP Initial Sequence Numbers (ISNs), since the TIME-WAIT state and TCP's "quiet time" concept take care of old segments from previous incarnations of a connection. However, a widespread optimization allows for a new incarnation of a previous connection to be created if the ISN of the incoming SYN is larger than the last sequence number seen in that direction for the previous incarnation of the connection. Thus, monotonically-increasing TCP ISNs allow for such optimization to work as expected [RFC6528], and can help avoid connection-establishment failures. (5) Strictly speaking, there are no interoperability requirements for the *initial* TCP timestamp employed by a TCP instance (i.e., the TS Value (TSval) in a segment with the SYN bit set). However, some TCP implementations allow a new incarnation of a previous connection to be created if the TSval of the incoming SYN is larger than the last TSval seen in that direction for the previous incarnation of the connection (please see [RFC6191]). Thus, monotonically-increasing TCP initial timestamps (across connections to the same endpoint) allow for such optimization to work as expected [RFC6191], and can help avoid connection- establishment failures. (6) The IPv6 Flow Label [RFC6437], along with the Source and Destination IPv6 addresses, is typically employed for load sharing [RFC7098]. Reuse of a Flow Label value for the same set {Source Address, Destination Address} would typically cause both flows to be multiplexed onto the same link. However, as long as this does not occur deterministically, it will not result in any negative implications. (7) DNS Query IDs are employed, together with the Source Address, Destination Address, Source Port, and Destination Port, to match DNS requests and responses. However, since an implementation knows which DNS requests were sent for that set of {Source Address, Destination Address, Source Port, and Destination Port, Query ID}, a collision of Query IDs would result, if anything, in a small performance penalty (the response would nevertheless be discarded when it is found that it does not answer the query sent in the corresponding DNS query). Based on the survey above, we can categorize identifiers as follows: Gont & Arce Expires 14 June 2023 [Page 9] Internet-Draft Generation of Transient Numeric IDs December 2022 +=======+======================================+===================+ | Cat # | Category | Sample Proto IDs | +=======+======================================+===================+ | 1 | Uniqueness (soft failure) | IPv6 Flow L., DNS | | | | Query ID | +-------+--------------------------------------+-------------------+ | 2 | Uniqueness (hard failure) | IPv6 Frag ID, TCP | | | | ephemeral port | +-------+--------------------------------------+-------------------+ | 3 | Uniqueness, stable within context | IPv6 IID | | | (soft failure) | | +-------+--------------------------------------+-------------------+ | 4 | Uniqueness, monotonically increasing | TCP ISN, TCP | | | within context (hard failure) | initial timestamp | +-------+--------------------------------------+-------------------+ Table 2: Identifier Categories We note that Category #4 could be considered a generalized case of category #3, in which a monotonically increasing element is added to a stable (within context) element, such that the resulting identifiers are monotonically increasing within a specified context. That is, the same algorithm could be employed for both #3 and #4, given appropriate parameters. 7. Common Algorithms for Transient Numeric Identifier Generation The following subsections describe some sample algorithms that can be employed for generating transient numeric identifiers for each of the categories above, while mitigating the vulnerabilities analyzed in Section 8 of this document. All of the variables employed in the algorithms of the following subsections are of "unsigned integer" type, except for the "retry" variable, that is of (signed) "integer" type. 7.1. Category #1: Uniqueness (soft failure) The requirement of uniqueness with a soft failure severity can be complied with a Pseudo-Random Number Generator (PRNG). NOTE: Please see [RFC4086] regarding randomness requirements for security. Gont & Arce Expires 14 June 2023 [Page 10] Internet-Draft Generation of Transient Numeric IDs December 2022 While most systems provide access to a PRNG, many of such PRNG implementations are not cryptographically secure, and therefore might be statistically biased or subject to adversarial influence. For example, ISO C [C11] rand(3) implementations are not cryptographically secure. NOTE: Section 7.1 ("Uniform Deviates") of [Press1992] discusses the underlying issues affecting ISO C [C11] rand(3) implementations. On the other hand, a number of systems provide an interface to a Cryptographically Secure PRNG (CSPRNG) [RFC8937] [RFC4086], which guarantees high entropy, unpredictability, and good statistical distribution of the random values generated. For example, GNU/ Linux's CSPRNG implementation is available via the getentropy(3) interface [GETENTROPY], while OpenBSD's CSPRNG implementation is available via the arc4random(3) and arc4random_uniform(3) interfaces [ARC4RANDOM]. Where available, these CSPRNGs should be preferred over e.g. POSIX [POSIX] random(3) or ISO C [C11] rand(3) implementations. In scenarios where a CSPRNG is not readily available to select transient numeric identifiers of Category #1, a security and privacy assessment of employing a regular PRNG should be performed, supporting the implementation decision. NOTE: [Aumasson2018], [Press1992], and [Knuth1983], discuss theoretical and practical aspects of pseudorandom numbers generation, and provide guidance on how to evaluate PRNGs. We note that since the premise is that collisions of transient numeric identifiers of this category only leads to soft failures, in many cases, the algorithm might not need to check the suitability of a selected identifier (i.e., the suitable_id() function, described below, could always return "true"). In scenarios where e.g. simultaneous use of a given numeric ID is undesirable and the implementation detects such condition, an implementation may opt to select the next available identifier in the same sequence, or select another random number. Section 7.1.1 is an implementation of the former strategy, while Section 7.1.2 is an implementation of the later. Typically, the algorithm in Section 7.1.2 results in a more uniform distribution of the generated transient numeric identifiers. However, for transient numeric identifiers where an implementation typically keeps local state about unsuitable/used identifiers, the algorithm in Section 7.1.2 may require many more iterations than the algorithm in Section 7.1.1 to Gont & Arce Expires 14 June 2023 [Page 11] Internet-Draft Generation of Transient Numeric IDs December 2022 generate a suitable transient numeric identifier. This will usually be affected by the current usage ratio of transient numeric identifiers (i.e., number of numeric identifiers considered suitable / total number of numeric identifiers) and other parameters. Therefore, in such cases many implementations tend to prefer the algorithm in Section 7.1.1 over the algorithm in Section 7.1.2. 7.1.1. Simple Randomization Algorithm /* Transient Numeric ID selection function */ id_range = max_id - min_id + 1; next_id = min_id + (random() % id_range); retry = id_range; do { if (suitable_id(next_id)) { return next_id; } if (next_id == max_id) { next_id = min_id; } else { next_id++; } retry--; } while (retry > 0); return ERROR; NOTE: random() is a PRNG that returns a pseudo-random unsigned integer number of appropriate size. Beware that "adapting" the length of the output of random() with a modulo operator (e.g., C-language's "%") may change the distribution of the PRNG. To preserve a uniform distribution, the rejection sampling technique [Romailler2020] can be used. Gont & Arce Expires 14 June 2023 [Page 12] Internet-Draft Generation of Transient Numeric IDs December 2022 The function suitable_id() can check, when possible and desirable, whether a selected transient numeric identifier is suitable (e.g. it is not already in use). Depending on how/where the numeric identifier is used, it may or may not be possible (or even desirable) to check whether the numeric identifier is in use (or whether it has been recently employed). When an identifier is found to be unsuitable, this algorithm selects the next available numeric identifier in sequence. Even when this algorithm selects numeric IDs randomly, it is biased towards the first available numeric ID after a sequence of unavailable numeric IDs. For example, if this algorithm is employed for transport protocol ephemeral port randomization [RFC6056] and the local list of unsuitable port numbers (e.g., registered port numbers that should not be used for ephemeral ports) is significant, an attacker may actually have a significantly better chance of guessing a port number. All the variables (in this and all the algorithms discussed in this document) are unsigned integers. Assuming the randomness requirements for the PRNG are met (see [RFC4086]), this algorithm does not suffer from any of the issues discussed in Section 8. 7.1.2. Another Simple Randomization Algorithm The following pseudo-code illustrates another algorithm for selecting a random transient numeric identifier which, in the event a selected identifier is found to be unsuitable (e.g., already in use), another identifier is randomly selected: Gont & Arce Expires 14 June 2023 [Page 13] Internet-Draft Generation of Transient Numeric IDs December 2022 /* Transient Numeric ID selection function */ id_range = max_id - min_id + 1; retry = id_range; do { next_id = min_id + (random() % id_range); if (suitable_id(next_id)) { return next_id; } retry--; } while (retry > 0); return ERROR; This algorithm might be unable to select a transient numeric identifier (i.e., return "ERROR") even if there are suitable identifiers available, in cases where a large number of identifiers are found to be unsuitable (e.g. "in use"). The same considerations from Section 7.1.1 with respect to the properties of random() and the adaptation of its output length apply to this algorithm. Assuming the randomness requirements for the PRNG are met (see [RFC4086]), this algorithm does not suffer from any of the issues discussed in Section 8. 7.2. Category #2: Uniqueness (hard failure) One of the most trivial approaches for generating unique transient numeric identifier (with a hard failure severity) is to reduce the identifier reuse frequency by generating the numeric identifiers with a monotonically-increasing function (e.g. linear). As a result, any of the algorithms described in Section 7.4 ("Category #4: Uniqueness, monotonically increasing within context (hard failure)") can be readily employed for complying with the requirements of this transient numeric identifier category. In cases where suitability (e.g. uniqueness) of the selected identifiers can be definitely assessed by the local system, any of the algorithms described in Section 7.1 ("Category #1: Uniqueness (soft failure)") can be readily employed for complying with the requirements of this numeric identifier category. Gont & Arce Expires 14 June 2023 [Page 14] Internet-Draft Generation of Transient Numeric IDs December 2022 NOTE: In the case of e.g. TCP ephemeral ports or TCP ISNs, a transient numeric identifier that might seem suitable from the perspective of the local system, might actually be unsuitable from the perspective of the remote system (e.g., because there is state associated with the selected identifier at the remote system). Therefore, in such cases it is not possible to employ the algorithms from Section 7.1 ("Category #1: Uniqueness (soft failure)"). 7.3. Category #3: Uniqueness, stable within context (soft failure) The goal of the following algorithm is to produce identifiers that are stable for a given context (identified by "CONTEXT"), but that change when the aforementioned context changes. In order to avoid storing in memory the transient numeric identifiers computed for each CONTEXT, the following algorithm employs a calculated technique (as opposed to keeping state in memory) to generate a stable transient numeric identifier for each given context. /* Transient Numeric ID selection function */ id_range = max_id - min_id + 1; retry = 0; do { offset = F(CONTEXT, retry, secret_key); next_id = min_id + (offset % id_range); if (suitable_id(next_id)) { return next_id; } retry++; } while (retry <= MAX_RETRIES); return ERROR; In this algorithm, the function F() provides a stateless and stable per-CONTEXT offset, where CONTEXT is the concatenation of all the elements that define the given context. For example, if this algorithm is expected to produce IPv6 IIDs Gont & Arce Expires 14 June 2023 [Page 15] Internet-Draft Generation of Transient Numeric IDs December 2022 that are unique per network interface and SLAAC autoconfiguration prefix, the CONTEXT should be the concatenation of e.g. the network interface index and the SLAAC autoconfiguration prefix (please see [RFC7217] for an implementation of this algorithm for generation of stable IPv6 IIDs). F() is a pseudorandom function (PRF). It must not be computable from the outside (without knowledge of the secret key). F() must also be difficult to reverse, such that it resists attempts to obtain the secret_key, even when given samples of the output of F() and knowledge or control of the other input parameters. F() should produce an output of at least as many bits as required for the transient numeric identifier. SipHash-2-4 (128-bit key, 64-bit output) [SipHash] and BLAKE3 (256-bit key, arbitrary-length output) [BLAKE3] are two possible options for F(). Alternatively, F() could be implemented with a keyed-hash message authentication code (HMAC) [RFC2104]. HMAC-SHA-256 [FIPS-SHS] would be one possible option for such implementation alternative. Note: Use of HMAC-MD5 [RFC1321] or HMAC-SHA1 [FIPS-SHS] are not recommended for F() [RFC6151] [RFC6194]. The result of F() is no more secure than the secret key, and therefore 'secret_key' must be unknown to the attacker, and must be of a reasonable length. 'secret_key' must remain stable for a given CONTEXT, since otherwise the numeric identifiers generated by this algorithm would not have the desired stability properties (i.e., stable for a given CONTEXT). In most cases, 'secret_key' should be selected with a PRNG (see [RFC4086] for recommendations on choosing secrets) at an appropriate time, and stored in stable or volatile storage (as necessary) for future use. The result of F() is stored in the variable 'offset', which may take any value within the storage type range, since we are restricting the resulting identifier to be in the range [min_id, max_id] in a similar way as in the algorithm described in Section 7.1.1. suitable_id() checks whether the candidate identifier has suitable uniqueness properties. Collisions (i.e., an identifier that is not unique) are recovered by incrementing the 'retry' variable and recomputing F(), up to a maximum of MAX_RETRIES times. However, recovering from collisions will usually result in identifiers that fail to remain constant for the specified context. This is normally acceptable when the probability of collisions is small, as in the case of e.g. IPv6 IIDs resulting from SLAAC [RFC7217] [RFC8981]. For obvious reasons, the transient numeric identifiers generated with this algorithm allow for network activity correlation and fingerprinting within "CONTEXT". However, this is essentially a design goal of this category of transient numeric identifiers. Gont & Arce Expires 14 June 2023 [Page 16] Internet-Draft Generation of Transient Numeric IDs December 2022 7.4. Category #4: Uniqueness, monotonically increasing within context (hard failure) 7.4.1. Per-context Counter Algorithm One possible way of selecting unique monotonically-increasing identifiers (per context) is to employ a per-context counter. Such an algorithm could be described as follows: /* Transient Numeric ID selection function */ id_range = max_id - min_id + 1; retry = id_range; id_inc = increment() % id_range; if( (next_id = lookup_counter(CONTEXT)) == ERROR){ next_id = min_id + random() % id_range; } do { if ( (max_id - next_id) >= id_inc){ next_id = next_id + id_inc; } else { next_id = min_id + id_inc - (max_id - next_id); } if (suitable_id(next_id)){ store_counter(CONTEXT, next_id); return next_id; } retry = retry - id_inc; } while (retry > 0); return ERROR; NOTES: increment() returns a small integer that is employed to increment the current counter value to obtain the next transient numeric identifier. This value must be much smaller than the number of possible values for the numeric IDs (i.e., "id_range"). Most implementations of this algorithm employ a constant increment of 1. Using a value other than 1 can help mitigate some information leakages (please see below), at the expense of a possible increase in the numeric ID reuse frequency. Gont & Arce Expires 14 June 2023 [Page 17] Internet-Draft Generation of Transient Numeric IDs December 2022 The code above makes sure that the increment employed in the algorithm (id_inc) is always smaller than the number of possible values for the numeric IDs (i.e., "max_id - min_d + 1"). However, as noted above, this value must also be much smaller than the number of possible values for the numeric IDs. lookup_counter() is a function that returns the current counter for a given context, or an error condition if that counter does not exist. store_counter() is a function that saves a counter value for a given context. suitable_id() is a function that checks whether the resulting identifier is acceptable (e.g., whether it is not already in use, etc.). Essentially, whenever a new identifier is to be selected, the algorithm checks whether a counter for the corresponding context exists. If does, the value of such counter is incremented to obtain the new transient numeric identifier, and the counter is updated. If no counter exists for such context, a new counter is created and initialized to a random value, and used as the selected transient numeric identifier. This algorithm produces a per-context counter, which results in one monotonically-increasing function for each context. Since each counter is initialized to a random value, the resulting values are unpredictable by an off-path attacker. The choice of id_inc has implications on both the security and privacy properties of the resulting identifiers, but also on the corresponding interoperability properties. On one hand, minimizing the increments generally minimizes the identifier reuse frequency, albeit at increased predictability. On the other hand, if the increments are randomized, predictability of the resulting identifiers is reduced, and the information leakage produced by global constant increments is mitigated. However, using larger increments than necessary can result in higher numeric ID reuse frequency. This algorithm has the following drawbacks: * It requires an implementation to store each per-CONTEXT counter in memory. If, as a result of resource management, the counter for a given context must be removed, the last transient numeric identifier value used for that context will be lost. Thus, if Gont & Arce Expires 14 June 2023 [Page 18] Internet-Draft Generation of Transient Numeric IDs December 2022 subsequently an identifier needs to be generated for the same context, the corresponding counter will need to be recreated and reinitialized to a random value, thus possibly leading to reuse/ collision of numeric identifiers. * Keeping one counter for each possible "context" may in some cases be considered too onerous in terms of memory requirements. Otherwise, the identifiers produced by this algorithm do not suffer from the other issues discussed in Section 8. 7.4.2. Simple PRF-Based Algorithm The goal of this algorithm is to produce monotonically-increasing transient numeric identifiers (for each given context), with a randomized initial value. For example, if the identifiers being generated must be monotonically-increasing for each {IP Source Address, IP Destination Address} set, then each possible combination of {IP Source Address, IP Destination Address} should have a separate monotonically-increasing sequence, that starts at a different random value. Instead of maintaining a per-context counter (as in the algorithm from Section 7.4.1), the following algorithm employs a calculated technique to maintain a random offset for each possible context. Gont & Arce Expires 14 June 2023 [Page 19] Internet-Draft Generation of Transient Numeric IDs December 2022 /* Initialization code */ counter = 0; /* Transient Numeric ID selection function */ id_range = max_id - min_id + 1; id_inc = increment() % id_range; offset = F(CONTEXT, secret_key); retry = id_range; do { next_id = min_id + (offset + counter) % id_range; counter = counter + id_inc; if (suitable_id(next_id)) { return next_id; } retry = retry - id_inc; } while (retry > 0); return ERROR; In the algorithm above, the function F() provides a (stateless) unpredictable offset for each given context (as identified by 'CONTEXT'). F() is a PRF, with the same properties as those specified for F() in Section 7.3. CONTEXT is the concatenation of all the elements that define a given context. For example, if this algorithm is expected to produce identifiers that are monotonically-increasing for each set (Source IP Address, Destination IP Address), CONTEXT should be the concatenation of these two IP addresses. The function F() provides a "per-CONTEXT" fixed offset within the numeric identifier "space". Both the 'offset' and 'counter' variables may take any value within the storage type range since we are restricting the resulting identifier to be in the range [min_id, max_id] in a similar way as in the algorithm described in Section 7.1.1. This allows us to simply increment the 'counter' variable and rely on the unsigned integer to wrap around. Gont & Arce Expires 14 June 2023 [Page 20] Internet-Draft Generation of Transient Numeric IDs December 2022 The result of F() is no more secure than the secret key, and therefore 'secret_key' must be unknown to the attacker, and must be of a reasonable length. 'secret_key' must remain stable for a given CONTEXT, since otherwise the numeric identifiers generated by this algorithm would not have the desired stability properties (i.e., monotonically-increasing for a given CONTEXT). In most cases, 'secret_key' should be selected with a PRNG (see [RFC4086] for recommendations on choosing secrets) at an appropriate time, and stored in stable or volatile storage (as necessary) for future use. It should be noted that, since this algorithm uses a global counter ("counter") for selecting identifiers (i.e., all counters share the same increments space), this algorithm results in an information leakage (as described in Section 8.2). For example, if this algorithm were used for selecting TCP ephemeral ports, and an attacker could force a client to periodically establish a new TCP connection to an attacker-controlled system (or through an attacker- observable routing path), the attacker could subtract consecutive source port values to obtain the number of outgoing TCP connections established globally by the victim host within that time period (up to wrap-around issues and five-tuple collisions, of course). This information leakage could be partially mitigated by employing small random values for the increments (i.e., increment() function), instead of having increment() return the constant "1". We nevertheless note that an improved mitigation of this information leakage could be more successfully achieved by employing the algorithm from Section 7.4.3, instead. 7.4.3. Double-PRF Algorithm A trade-off between maintaining a single global 'counter' variable and maintaining 2**N 'counter' variables (where N is the width of the result of F()), could be achieved as follows. The system would keep an array of TABLE_LENGTH values, which would provide a separation of the increment space into multiple buckets. This improvement could be incorporated into the algorithm from Section 7.4.2 as follows: Gont & Arce Expires 14 June 2023 [Page 21] Internet-Draft Generation of Transient Numeric IDs December 2022 /* Initialization code */ for(i = 0; i < TABLE_LENGTH; i++) { table[i] = random(); } /* Transient Numeric ID selection function */ id_range = max_id - min_id + 1; id_inc = increment() % id_range; offset = F(CONTEXT, secret_key1); index = G(CONTEXT, secret_key2) % TABLE_LENGTH; retry = id_range; do { next_id = min_id + (offset + table[index]) % id_range; table[index] = table[index] + id_inc; if (suitable_id(next_id)) { return next_id; } retry = retry - id_inc; } while (retry > 0); return ERROR; 'table[]' could be initialized with random values, as indicated by the initialization code in the pseudo-code above. Both F() and G() are PRFs, with the same properties as those required for F() in Section 7.3. The results of F() and G() are no more secure than their respective secret keys ('secret_key1' and 'secret_key2', respectively), and therefore both secret keys must be unknown to the attacker, and must be of a reasonable length. Both secret keys must remain stable for the given CONTEXT, since otherwise the transient numeric identifiers generated by this algorithm would not have the desired stability properties (i.e., monotonically-increasing for a given CONTEXT). In most cases, both secret keys should be selected with a PRNG (see [RFC4086] for recommendations on choosing secrets) at an appropriate time, and stored in stable or volatile storage (as necessary) for future use. Gont & Arce Expires 14 June 2023 [Page 22] Internet-Draft Generation of Transient Numeric IDs December 2022 The 'table[]' array assures that successive transient numeric identifiers for a given context will be monotonically-increasing. Since the increments space is separated into TABLE_LENGTH different spaces, the identifier reuse frequency will be (probabilistically) lower than that of the algorithm in Section 7.4.2. That is, the generation of an identifier for one given context will not necessarily result in increments in the identifier sequence of other contexts. It is interesting to note that the size of 'table[]' does not limit the number of different identifier sequences, but rather separates the *increment space* into TABLE_LENGTH different spaces. The selected transient numeric identifier sequence will be obtained by adding the corresponding entry from 'table[]' to the value in the 'offset' variable, which selects the actual identifier sequence space (as in the algorithm from Section 7.4.2). An attacker can perform traffic analysis for any "increment space" (i.e., context) into which the attacker has "visibility" -- namely, the attacker can force a system to generate identifiers for G(CONTEXT, secret_key2), where the result of G() identifies the target "increment space". However, the attacker's ability to perform traffic analysis is very reduced when compared to the simple PRF- based identifiers (described in Section 7.4.2) and the predictable linear identifiers (described in Appendix A.1). Additionally, an implementation can further limit the attacker's ability to perform traffic analysis by further separating the increment space (that is, using a larger value for TABLE_LENGTH) and/or by randomizing the increments (i.e., increment() returning a small random number as opposed to the constant "1"). Otherwise, this algorithm does not suffer from the issues discussed in Section 8. 8. Common Vulnerabilities Associated with Transient Numeric Identifiers 8.1. Network Activity Correlation An identifier that is predictable within a given context allows for network activity correlation within that context. For example, a stable IPv6 Interface Identifier allows for network activity to be correlated within the context in which the Interface Identifier is stable [RFC7721]. A stable-per-network IPv6 Interface Identifier (as in [RFC7217]) allows for network activity correlation within a network, whereas a constant IPv6 Interface Identifier (that remains constant across networks) allows not only network activity correlation within the same network, but also across networks ("host tracking"). Gont & Arce Expires 14 June 2023 [Page 23] Internet-Draft Generation of Transient Numeric IDs December 2022 Similarly, an implementation that generates TCP ISNs with a global counter could allow for fingerprinting and network activity correlation across networks, since an attacker could passively infer the identity of the victim based on the TCP ISNs employed for subsequent communication instances. Similarly, an implementation that generates predictable IPv6 Fragment Identification values could be subject to fingerprinting attacks (see e.g. [Bellovin2002]). 8.2. Information Leakage Transient numeric identifiers that result in specific patterns can produce an information leakage to other communicating entities. For example, it is common to generate transient numeric identifiers with an algorithm such as: ID = offset(CONTEXT) + mono(CONTEXT); This generic expression generates identifiers by adding a monotonically-increasing function (e.g. linear) to a randomized offset. offset() is constant within a given context, whereas mono() produces a monotonically-increasing sequence for the given context. Identifiers generated with this expression will generally be predictable within CONTEXT. The predictability of mono(), irrespective of the predictability of offset(), can leak information that may be of use to attackers. For example, a node that selects ephemeral port numbers as in: ephemeral_port = offset(Dest_IP) + mono() that is, with a per-destination offset, but a global mono() function (e.g., a global counter), will leak information about total number of outgoing connections that have been issued by the vulnerable implementation. Similarly, a node that generates Fragment Identification values as in: Frag_ID = offset(IP_src_addr, IP_dst_addr) + mono() will leak out information about the total number of fragmented packets that have been transmitted by the vulnerable implementation. The vulnerabilities described in Gont & Arce Expires 14 June 2023 [Page 24] Internet-Draft Generation of Transient Numeric IDs December 2022 [Sanfilippo1998a], [Sanfilippo1998b], and [Sanfilippo1999] are all associated with the use of a global mono() function (i.e., with a global and constant "context") -- particularly when it is a linear function (constant increments of 1). Predicting transient numeric identifiers can be of help for other types of attacks. For example, predictable TCP ISNs can open the door to trivial connection-reset and data injection attacks (see Section 8.6). 8.3. Fingerprinting Fingerprinting is the capability of an attacker to identify or re- identify a visiting user, user agent or device via configuration settings or other observable characteristics. Observable protocol objects and characteristics can be employed to identify/re-identify a variety of entities, ranging from the underlying hardware or Operating System (vendor, type and version), to the user itself (i.e. his/her identity). [EFF] illustrates web browser-based fingerprinting, but similar techniques can be applied at other layers and protocols, whether alternatively or in conjunction with it. Transient numeric identifiers are one of the observable protocol components that could be leveraged for fingerprinting purposes. That is, an attacker could sample transient numeric identifiers to infer the algorithm (and its associated parameters, if any) for generating such identifiers, possibly revealing the underlying Operating System (OS) vendor, type, and version. This information could possibly be further leveraged in conjunction with other fingerprinting techniques and sources. Evasion of protocol-stack fingerprinting can prove to be a very difficult task: most systems make use of a wide variety of protocols, each of which have a large number of parameters that can be set to arbitrary values or generated with a variety of algorithms with multiple parameters. Gont & Arce Expires 14 June 2023 [Page 25] Internet-Draft Generation of Transient Numeric IDs December 2022 NOTE: General protocol-based fingerprinting is discussed in [RFC6973], along with guidelines to mitigate the associated vulnerability. [Fyodor1998] and [Fyodor2006] are classic references on Operating System detection via TCP/IP stack fingerprinting. Nmap [nmap] is probably the most popular tool for remote OS identification via active TCP/IP stack fingerprinting. p0f [Zalewski2012], on the other hand, is a tool for performing remote OS detection via passive TCP/IP stack fingerprinting. Finally, [TBIT] is a TCP fingerprinting tool that aims at characterizing the behaviour of a remote TCP peer based on active probes, and which has been widely used in the research community. Algorithms that, from the perspective of an observer (e.g., the legitimate communicating peer), result in specific values or patterns, will allow for at least some level of fingerprinting. For example, the algorithm from Section 7.3 will typically allow fingerprinting within the context where the resulting identifiers are stable. Similarly, the algorithms from Section 7.4 will result in a monotonically-increasing sequences within a given context, thus allowing for at least some level of fingerprinting (when the other communicating entity can correlate different sampled identifiers as belonging to the same monotonically-increasing sequence). Thus, where possible, algorithms from Section 7.1 should be preferred over algorithms that result in specific values or patterns. 8.4. Exploitation of the Semantics of Transient Numeric Identifiers Identifiers that are not semantically opaque tend to be more predictable than semantically-opaque identifiers. For example, a MAC address contains an OUI (Organizationally-Unique Identifier) which may identify the vendor that manufactured the corresponding network interface card. This can be leveraged by an attacker trying to "guess" MAC addresses, who has some knowledge about the possible Network Interface Card (NIC) vendor. [RFC7707] discusses a number of techniques to reduce the search space when performing IPv6 address-scanning attacks by leveraging the semantics of the IIDs produced by traditional SLAAC algorithms (eventually replaced by [RFC7217]) that embed MAC addresses in the IID of IPv6 addresses. Gont & Arce Expires 14 June 2023 [Page 26] Internet-Draft Generation of Transient Numeric IDs December 2022 8.5. Exploitation of Collisions of Transient Numeric Identifiers In many cases, the collision of transient network identifiers can have a hard failure severity (or result in a hard failure severity if an attacker can cause multiple collisions deterministically, one after another). For example, predictable Fragment Identification values open the door to Denial of Service (DoS) attacks (see e.g. [RFC5722].). 8.6. Exploitation of Predictable Transient Numeric Identifiers for Injection Attacks Some protocols rely on "sequence numbers" for the validation of incoming packets. For example, TCP employs sequence numbers for reassembling TCP segments, while IPv4 and IPv6 employ Fragment Identification values for reassembling IPv4 and IPv6 fragments (respectively). Lacking built-in cryptographic mechanisms for validating packets, these protocols are therefore vulnerable to on- path data (see e.g. [Joncheray1995]) and/or control-information (see e.g. [RFC4953] and [RFC5927]) injection attacks. The extent to which these protocols may resist off-path (i.e. "blind") injection attacks depends on whether the associated "sequence numbers" are predictable, and effort required to successfully predict a valid "sequence number" (see e.g. [RFC4953] and [RFC5927]). We note that the use of unpredictable "sequence numbers" is a completely-ineffective mitigation for on-path injection attacks, and also a mostly-ineffective mitigation for off-path (i.e. "blind") injection attacks. However, many legacy protocols (such as TCP) do not natively incorporate cryptographic mitigations, but rather only as optional features (see e.g. [RFC5925]), if at all available. Additionally, ad-hoc use of cryptographic mitigations might not be sufficient to relieve a protocol implementation of generating appropriate transient numeric identifiers. For example, use of the Transport Layer Security (TLS) protocol [RFC8446] with TCP will protect the application protocol, but will not help to mitigate e.g. TCP-based connection-reset attacks (see e.g. [RFC4953]). Similarly, use of SEcure Neighbor Discovery (SEND) [RFC3971] will still imply reliance on the successful reassembly of IPv6 fragments in those cases where SEND packets do not fit into the link Maximum Transmission Unit (MTU) (see [RFC6980]). Gont & Arce Expires 14 June 2023 [Page 27] Internet-Draft Generation of Transient Numeric IDs December 2022 8.7. Cryptanalysis A number of algorithms discussed in this document (such as those described in Section 7.4.2 and Section 7.4.3) rely on PRFs. Implementations that employ weak PRFs or keys of inappropriate size can be subject to cryptanalysis, where an attacker can obtain the secret key employed for the PRF, predict numeric identifiers, etc. Furthermore, an implementation that overloads the semantics of the secret key can result in more trivial cryptanalysis, possibly resulting in the leakage of the value employed for the secret key. NOTE: [IPID-DEV] describes two vulnerable transient numeric ID generators that employ cryptographically-weak hash functions. Additionally, one of such implementations employs 32-bits of a kernel address as the secret key for a hash function, and therefore successful cryptanalysis leaks the aforementioned kernel address, allowing for Kernel Address Space Layout Randomization (KASLR) [KASLR] bypass. 9. Vulnerability Assessment of Transient Numeric Identifiers The following subsections analyze possible vulnerabilities associated with the algorithms described in Section 7. 9.1. Category #1: Uniqueness (soft failure) Possible vulnerabilities associated with the algorithms from Section 7.1 include: * Use of flawed PRNGs (please see e.g. [Zalewski2001], [Zalewski2002], [Klein2007] and [CVEs]). * Inadvertently affecting the distribution of an otherwise suitable PRNG (please see e.g. [Romailler2020]). Where available, CSPRNGs should be preferred over regular PRNGs such as e.g. POSIX random(3) implementations. In scenarios where a CSPRNG is not readily available, a security and privacy assessment of employing a regular PRNG should be performed, supporting the implementation decision. NOTE: Please see [RFC4086] regarding randomness requirements for security. [Aumasson2018], [Press1992], and [Knuth1983], discuss theoretical and practical aspects of random numbers generation, and provide guidance on how to evaluate PRNGs. Gont & Arce Expires 14 June 2023 [Page 28] Internet-Draft Generation of Transient Numeric IDs December 2022 When employing a PRNG, many implementations "adapt" the length of its output with a modulo operator (e.g., C language's "%"), possibly changing the distribution of the output of the PRNG. For example, consider an implementation that employs the following code: id = random() % 50000; This example implementation means to obtain a transient numeric identifier in the range 0-49999. If random() produces e.g. a pseudorandom number of 16 bits (with uniform distribution), the selected transient numeric identifier will have a non-uniform distribution with the numbers in the range 0-15535 having double- frequency than the numbers in the range 15536-49999. NOTE: For example, in our sample code both an output of 10 and output of 50010 from the random() function will result in an 'id' value of 10. This effect is reduced if the PRNG produces an output that is much longer than the length implied by the modulo operation. We note that to preserve a uniform distribution, the rejection sampling technique [Romailler2020] can be used. Use of algorithms other than PRNGs for generating identifiers of this category is discouraged. 9.2. Category #2: Uniqueness (hard failure) As noted in Section 7.2, this category can employ the same algorithms as Category #4, since a monotonically-increasing sequence tends to minimize the transient numeric identifier reuse frequency. Therefore, the vulnerability analysis in Section 9.4 also applies to this category. Additionally, as noted in Section 7.2, some transient numeric identifiers of this category might be able to use the algorithms from Section 7.1, in which case the same considerations as in Section 9.1 would apply. 9.3. Category #3: Uniqueness, stable within context (soft failure) Possible vulnerabilities associated with the algorithms from Section 7.3 are: Gont & Arce Expires 14 June 2023 [Page 29] Internet-Draft Generation of Transient Numeric IDs December 2022 1. Use of weak PRFs, or inappropriate secret keys (whether inappropriate selection or inappropriate size) could allow for cryptanalysis, which could eventually be exploited by an attacker to predict future transient numeric identifiers. 2. Since the algorithm generates a unique and stable identifier within a specified context, it may allow for network activity correlation and fingerprinting within the specified context. 9.4. Category #4: Uniqueness, monotonically increasing within context (hard failure) The algorithm described in Section 7.4.1 for generating identifiers of Category #4 will result in an identifiable pattern (i.e. a monotonically-increasing sequence) for the transient numeric identifiers generated for each CONTEXT, and thus will allow for fingerprinting and network activity correlation within each CONTEXT. On the other hand, a simple way to generalize and analyze the algorithms described in Section 7.4.2 and Section 7.4.3 for generating identifiers of Category #4, is as follows: /* Transient Numeric ID selection function */ id_range = max_id - min_id + 1; retry = id_range; id_inc = increment() % id_range; do { update_mono(CONTEXT, id_inc); next_id = min_id + (offset(CONTEXT) + \ mono(CONTEXT)) % id_range; if (suitable_id(next_id)) { return next_id; } retry = retry - id_inc; } while (retry > 0); return ERROR; Gont & Arce Expires 14 June 2023 [Page 30] Internet-Draft Generation of Transient Numeric IDs December 2022 NOTE: increment() returns a small integer that is employed to generate a monotonically-increasing function. Most implementations employ a constant value for "increment()" (usually 1). The value returned by increment() must be much smaller than the value computed for "id_range". update_mono(CONTEXT, id_inc) increments the counter corresponding to CONTEXT by "id_inc". mono(CONTEXT) reads the counter corresponding to CONTEXT. Essentially, an identifier (next_id) is generated by adding a monotonically-increasing function (mono()) to an offset value, unknown to the attacker and stable for given context (CONTEXT). The following aspects of the algorithm should be considered: * For the most part, it is the offset() function that results in identifiers that are unpredictable by an off-patch attacker. While the resulting sequence is known to be monotonically- increasing, the use of a randomized offset value makes the resulting values unknown to the attacker. * The most straightforward "stateless" implementation of offset() is with a PRF that takes the values that identify the context and a "secret_key" (not shown in the figure above) as arguments. * One possible implementation of mono() would be to have mono() internally employ a single counter (as in the algorithm from Section 7.4.2), or map the increments for different contexts into a number of counters/buckets, such that the number of counters that need to be maintained in memory is reduced (as in the algorithm from algorithm in Section 7.4.3). * In all cases, a monotonically increasing function is implemented by incrementing the previous value of a counter by increment() units. In the most trivial case, increment() could return the constant "1". But increment() could also be implemented to return small random integers such that the increments are unpredictable (see Appendix A of [RFC7739]). This represents a trade-off between the unpredictability of the resulting transient numeric IDs and the transient numeric ID reuse frequency. Considering the generic algorithm illustrated above, we can identify the following possible vulnerabilities: Gont & Arce Expires 14 June 2023 [Page 31] Internet-Draft Generation of Transient Numeric IDs December 2022 * Since the algorithms for this category are similar to those of Section 9.3, with the addition of a monotonically-increasing function, all the issues discussed in Section 9.3 ("Category #3: Uniqueness, stable within context (soft failure)") also apply to this case. * mono() can be correlated to the number of identifiers generated for a given context (CONTEXT). Thus, if mono() spans more than the necessary context, the "increments" could be leaked to other parties, thus disclosing information about the number of identifiers that have been generated by the algorithm for all contexts. This is information disclosure becomes more evident when an implementation employs a constant increment of 1. For example, an implementation where mono() is actually a single global counter, will unnecessarily leak information the number of identifiers that have been generated by the algorithm (globally, for all contexts). [Fyodor2003] is one example of how such information leakages can be exploited. We note that limiting the span of the increments space will require a larger number of counters to be stored in memory (i.e., a larger value for the TABLE_LENGTH parameter of the algorithm in Section 7.4.3). * Transient numeric identifiers generated with the algorithms described in Section 7.4.2 and Section 7.4.3 will normally allow for fingerprinting within CONTEXT since, for such context, the resulting identifiers will have an identifiable pattern (i.e. a monotonically-increasing sequence). 10. IANA Considerations This document has no IANA actions. 11. Security Considerations The entire document is about the security and privacy implications of transient numeric identifiers. [I-D.gont-numeric-ids-sec-considerations] recommends that protocol specifications specify the interoperability requirements of their transient numeric identifiers, perform a vulnerability assessment of their transient numeric identifiers, and suggest an algorithm for generating each of their transient numeric identifiers. This document analyzes possible algorithms (and their implications) that could be employed to comply with the interoperability properties of most common categories of transient numeric identifiers, while minimizing the associated negative security and privacy implications. Gont & Arce Expires 14 June 2023 [Page 32] Internet-Draft Generation of Transient Numeric IDs December 2022 12. Acknowledgements The authors would like to thank (in alphabetical order) Bernard Aboba, Jean-Philippe Aumasson, Steven Bellovin, Luis Leon Cardenas Graide, Spencer Dawkins, Theo de Raadt, Guillermo Gont, Joseph Lorenzo Hall, Gre Norcie, Colin Perkins, Vincent Roca, Shivan Sahib, Rich Salz, Martin Thomson, and Michael Tuexen, for providing valuable comments on earlier versions of this document. The authors would like to thank Shivan Sahib and Christopher Wood, for their guidance during the publication process of this document. The authors would like to thank Jean-Philippe Aumasson and Mathew D. Green (John Hopkins University) for kindly answering a number of questions. The authors would like to thank Diego Armando Maradona for his magic and inspiration. 13. References 13.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 2012, . [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . Gont & Arce Expires 14 June 2023 [Page 33] Internet-Draft Generation of Transient Numeric IDs December 2022 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, DOI 10.17487/RFC5722, December 2009, . [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, . [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, . [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, . [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP Timestamps", BCP 159, RFC 6191, DOI 10.17487/RFC6191, April 2011, . Gont & Arce Expires 14 June 2023 [Page 34] Internet-Draft Generation of Transient Numeric IDs December 2022 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, . [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, . [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . 13.2. Informative References [KASLR] PaX Team, "Address Space Layout Randomization", . [IANA-PROT] IANA, "Protocol Registries", . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [Fyodor1998] Fyodor, "Remote OS Detection via TCP/IP Stack Fingerprinting", Phrack Magazine, Volume 9, Issue 54, 1998, . [Fyodor2006] Lyon, G., "Chapter 8. Remote OS Detection", 2006, . [nmap] nmap, "Nmap: Free Security Scanner For Network Exploration and Audit", 2020, . [EFF] EFF, "Cover your tracks: See how trackers view your browser", 2020, . Gont & Arce Expires 14 June 2023 [Page 35] Internet-Draft Generation of Transient Numeric IDs December 2022 [Schuba1993] Schuba, C., "ADDRESSING WEAKNESSES IN THE DOMAIN NAME SYSTEM PROTOCOL", 1993, . [TBIT] TBIT, "TBIT, the TCP Behavior Inference Tool", 2001, . [C11] ISO/IEC, "Information technology - Programming languages - C", ISO/IEC 9899:2011, 2011. [POSIX] IEEE, "IEEE Standard for Information Technology -- Portable Operating System Interface (POSIX)", IEEE Std 1003.1-2017, 2017. [ARC4RANDOM] OpenBSD, "arc4random(3)", Library Functions Manual, 2022, . [GETENTROPY] Linux, "getentropy(3)", Linux Programmer's Manual, 2022, . [CVEs] NVD, "Vulnerability Advisories for Pseudo Random Number Generators", 2022, . [Zalewski2012] Zalewski, M., "p0f v3 (version 3.09b)", 2012, . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 Flow Label for Load Balancing in Server Farms", RFC 7098, DOI 10.17487/RFC7098, January 2014, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . Gont & Arce Expires 14 June 2023 [Page 36] Internet-Draft Generation of Transient Numeric IDs December 2022 [CPNI-TCP] Gont, F., "Security Assessment of the Transmission Control Protocol (TCP)", United Kingdom's Centre for the Protection of National Infrastructure (CPNI) Technical Report, 2009, . [Zalewski2001] Zalewski, M., "Strange Attractors and TCP/IP Sequence Number Analysis", 2001, . [Zalewski2002] Zalewski, M., "Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later", 2001, . [Joncheray1995] Joncheray, L., "A Simple Active Attack Against TCP", Proc. Fifth Usenix UNIX Security Symposium, 1995, . [Morris1985] Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, NJ, 1985, . [Shimomura1995] Shimomura, T., "Technical details of the attack described by Markoff in NYT", Message posted in USENET's comp.security.misc newsgroup Message-ID: <3g5gkl$5j1@ariel.sdsc.edu>, 1995, . [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, July 2010, . [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, DOI 10.17487/RFC4953, July 2007, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Gont & Arce Expires 14 June 2023 [Page 37] Internet-Draft Generation of Transient Numeric IDs December 2022 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, . [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, DOI 10.17487/RFC6980, August 2013, . [RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016, . [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, July 2007, . [RFC6274] Gont, F., "Security Assessment of the Internet Protocol Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, . [Press1992] Press, W. H., Teukolsky, S. A., Vetterling, W. T., and B. P. Flannery, "Numerical Recipes in C: The Art of Scientific Computing", 2nd ed. ISBN 0-521-43108-5. Cambridge University Press, 1992. [Romailler2020] Romailler, Y., "THE DEFINITIVE GUIDE TO "MODULO BIAS AND HOW TO AVOID IT"!", Kudelski Security Research, 2020, . [Aumasson2018] Aumasson, J.P., "Serious Cryptography: A Practical Introduction to Modern Encryption", ISBN-10: 1-59327-826-8, No Starch Press, Inc., 2018. [Knuth1983] Knuth, D., "The Art of Computer Programming", volume 2 (Seminumerical Algorithms), 2nd ed. Reading, Massachusetts: Addison-Wesley Publishing Company, 1981. Gont & Arce Expires 14 June 2023 [Page 38] Internet-Draft Generation of Transient Numeric IDs December 2022 [Bellovin1989] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", Computer Communications Review, vol. 19, no. 2, pp. 32-48, 1989, . [Bellovin2002] Bellovin, S. M., "A Technique for Counting NATted Hosts", IMW'02 Nov. 6-8, 2002, Marseille, France, 2002, . [Fyodor2003] Fyodor, "Idle scanning and related IP ID games", 2003, . [Sanfilippo1998a] Sanfilippo, S., "about the ip header id", Post to Bugtraq mailing-list, Mon Dec 14 1998, . [Sanfilippo1998b] Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 1998, . [Sanfilippo1999] Sanfilippo, S., "more ip id", Post to Bugtraq mailing- list, 1999, . [Silbersack2005] Silbersack, M.J., "Improving TCP/IP security through randomization without sacrificing interoperability", EuroBSDCon 2005 Conference, 2005, . [Klein2007] Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S Predictable IP ID Vulnerability", 2007, . Gont & Arce Expires 14 June 2023 [Page 39] Internet-Draft Generation of Transient Numeric IDs December 2022 [IPID-DEV] Klein, A. and B. Pinkas, "From IP ID to Device ID and KASLR Bypass (Extended Version)", June 2019, . [I-D.irtf-pearg-numeric-ids-history] Gont, F. and I. Arce, "Unfortunate History of Transient Numeric Identifiers", Work in Progress, Internet-Draft, draft-irtf-pearg-numeric-ids-history-10, 11 July 2022, . [I-D.gont-numeric-ids-sec-considerations] Gont, F. and I. Arce, "Security Considerations for Transient Numeric Identifiers Employed in Network Protocols", Work in Progress, Internet-Draft, draft-gont- numeric-ids-sec-considerations-08, 10 December 2022, . [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, . [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., and C. Wood, "Randomness Improvements for Security Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, . [TCPT-uptime] McDanel, B., "TCP Timestamping - Obtaining System Uptime Remotely", 14 March 2001, . [SipHash] Aumasson, J. P. and D. J. Bernstein, "SipHash: a fast short-input PRF", 2012, . [BLAKE3] O'Connor, J., Aumasson, J. P., Neves, S., and Z. Wilcox- O'Hearn, "BLAKE3: one function, fast everywhere", 2020, . Gont & Arce Expires 14 June 2023 [Page 40] Internet-Draft Generation of Transient Numeric IDs December 2022 [FIPS-SHS] NIST, "Secure Hash Standard (SHS)", Federal Information Processing Standards Publication 180-4, August 2015, . [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, . Appendix A. Algorithms and Techniques with Known Issues The following subsections discuss algorithms and techniques with known negative security and privacy implications. NOTE: As discussed in Section 1, the use of cryptographic techniques might allow for the safe use of some of these algorithms and techniques. However, this should be evaluated on a case by case basis. A.1. Predictable Linear Identifiers Algorithm One of the most trivial ways to achieve uniqueness with a low identifier reuse frequency is to produce a linear sequence. This type of algorithm has been employed in the past to generate identifiers of Categories #1, #2, and #4 (please see Section 6 for an analysis of these categories). For example, the following algorithm has been employed (see e.g. [Morris1985], [Shimomura1995], [Silbersack2005] and [CPNI-TCP]) in a number of operating systems for selecting IP fragment IDs, TCP ephemeral ports, etc.: Gont & Arce Expires 14 June 2023 [Page 41] Internet-Draft Generation of Transient Numeric IDs December 2022 /* Initialization code */ next_id = min_id; id_inc= 1; /* Transient Numeric ID selection function */ id_range = max_id - min_id + 1; retry = id_range; do { if (next_id == max_id) { next_id = min_id; } else { next_id = next_id + id_inc; } if (suitable_id(next_id)) { return next_id; } retry--; } while (retry > 0); return ERROR; NOTE: suitable_id() is a function that checks whether the resulting identifier is acceptable (e.g., whether it's in use, etc.). For obvious reasons, this algorithm results in predictable sequences. Since a global counter is used to generate the transient numeric identifiers ("next_id" in the example above), an entity that learns one numeric identifier can infer past numeric identifiers and predict future values to be generated by the same algorithm. Since the value employed for the increments is known (such as "1" in this case), an attacker can sample two values, and learn the number of identifiers that have been were generated in-between the two sampled values. Furthermore, if the counter is initialized e.g. when the system its bootstrapped to some known value, the algorithm will leak additional information, such as the number of transmitted fragmented datagrams in the case of an IP ID generator [Sanfilippo1998a], or the system uptime in the case of TCP timestamps [TCPT-uptime]. Gont & Arce Expires 14 June 2023 [Page 42] Internet-Draft Generation of Transient Numeric IDs December 2022 A.2. Random-Increments Algorithm This algorithm offers a middle ground between the algorithms that generate randomized transient numeric identifiers (such as those described in Section 7.1.1 and Section 7.1.2), and those that generate identifiers with a predictable monotonically-increasing function (see Appendix A.1). /* Initialization code */ next_id = random(); /* Initialization value */ id_rinc = 500; /* Determines the trade-off */ /* Transient Numeric ID selection function */ id_range = max_id - min_id + 1; retry = id_range; do { /* Random increment */ id_inc = (random() % id_rinc) + 1; if ( (max_id - next_id) >= id_inc){ next_id = next_id + id_inc; } else { next_id = min_id + id_inc - (max_id - next_id); } if (suitable_id(next_id)) { return next_id; } retry = retry - id_inc; } while (retry > 0); return ERROR; This algorithm aims at producing a global monotonically-increasing sequence of transient numeric identifiers, while avoiding the use of fixed increments, which would lead to trivially predictable sequences. The value "id_inc" allows for direct control of the trade-off between unpredictability and identifier reuse frequency. The smaller the value of "id_inc", the more similar this algorithm is Gont & Arce Expires 14 June 2023 [Page 43] Internet-Draft Generation of Transient Numeric IDs December 2022 to a predicable, global linear ID generation algorithm (as the one in Appendix A.1). The larger the value of "id_inc", the more similar this algorithm is to the algorithm described in Section 7.1.1 of this document. When the identifiers wrap, there is a risk of collisions of transient numeric identifiers (i.e., identifier reuse). Therefore, "id_inc" should be selected according to the following criteria: * It should maximize the wrapping time of the identifier space. * It should minimize identifier reuse frequency. * It should maximize unpredictability. Clearly, these are competing goals, and the decision of which value of "id_inc" to use is a trade-off. Therefore, the value of "id_inc" is at times a configurable parameter so that system administrators can make the trade-off for themselves. We note that the alternative algorithms discussed throughout this document offer better interoperability, security and privacy properties than this algorithm, and hence implementation of this algorithm is discouraged. A.3. Re-using Identifiers Across Different Contexts Employing the same identifier across contexts in which stability is not required (i.e. overloading the semantics of transient numeric identifier) usually has negative security and privacy implications. For example, in order to generate transient numeric identifiers of Category #2 or Category #3, an implementation or specification might be tempted to employ a source for the numeric identifiers which is known to provide unique values, but that may also be predictable or leak information related to the entity generating the identifier. This technique has been employed in the past for e.g. generating IPv6 IIDs by re-using the MAC address of the underlying network interface. However, as noted in [RFC7721] and [RFC7707], embedding link-layer addresses in IPv6 IIDs not only results in predictable values, but also leaks information about the manufacturer of the underlying network interface card, allows for network activity correlation, and makes address-based scanning attacks feasible. Authors' Addresses Gont & Arce Expires 14 June 2023 [Page 44] Internet-Draft Generation of Transient Numeric IDs December 2022 Fernando Gont SI6 Networks Segurola y Habana 4310 7mo piso Ciudad Autonoma de Buenos Aires Buenos Aires Argentina Email: fgont@si6networks.com URI: https://www.si6networks.com Ivan Arce Quarkslab Segurola y Habana 4310 7mo piso Ciudad Autonoma de Buenos Aires Buenos Aires Argentina Email: iarce@quarkslab.com URI: https://www.quarkslab.com Gont & Arce Expires 14 June 2023 [Page 45] ./draft-irtf-pearg-numeric-ids-history-11.txt0000644000764400076440000023211114345315674020711 0ustar iustiniustin Internet Research Task Force (IRTF) F. Gont Internet-Draft SI6 Networks Intended status: Informational I. Arce Expires: 14 June 2023 Quarkslab 11 December 2022 Unfortunate History of Transient Numeric Identifiers draft-irtf-pearg-numeric-ids-history-11 Abstract This document analyzes the timeline of the specification and implementation of different types of "transient numeric identifiers" used in IETF protocols, and how the security and privacy properties of such protocols have been affected as a result of it. It provides empirical evidence that advice in this area is warranted. This document is a product of the Privacy Enhancement and Assessment Research Group (PEARG) in the IRTF. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Gont & Arce Expires 14 June 2023 [Page 1] Internet-Draft Predictable Transient Numeric IDs December 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Issues with the Specification of Transient Numeric Identifiers . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . 6 4.2. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . 10 4.3. IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . . 12 4.4. NTP Reference IDs (REFIDs) . . . . . . . . . . . . . . . 15 4.5. Transport Protocol Ephemeral Port Numbers . . . . . . . . 16 4.6. DNS Query ID . . . . . . . . . . . . . . . . . . . . . . 17 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction Networking protocols employ a variety of transient numeric identifiers for different protocol objects, such as IPv4 and IPv6 Fragment Identifiers [RFC0791] [RFC8200], IPv6 Interface Identifiers (IIDs) [RFC4291], transport protocol ephemeral port numbers [RFC6056], TCP Initial Sequence Numbers (ISNs) [RFC0793], NTP Reference IDs (REFIDs) [RFC5905], and DNS Query IDs [RFC1035]. These identifiers typically have specific interoperability requirements (e.g. uniqueness during a specified period of time), and associated failure severities when such requirements are not met [I-D.irtf-pearg-numeric-ids-generation]. For more than 30 years, a large number of implementations of the IETF protocols have been subject to a variety of attacks, with effects ranging from Denial of Service (DoS) or data injection, to information leakages that could be exploited for pervasive monitoring [RFC7258]. The root cause of these issues has been, in many cases, poor selection of transient numeric identifiers, usually as a result of insufficient or misleading specifications. For example, implementations have been subject to security or privacy issues resulting from: * Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. [Sanfilippo1998a], [RFC6274], and [RFC7739]) Gont & Arce Expires 14 June 2023 [Page 2] Internet-Draft Predictable Transient Numeric IDs December 2022 * Predictable IPv6 IIDs (see e.g. [RFC7721], [RFC7707], and [RFC7217]) * Predictable transport protocol ephemeral port numbers (see e.g. [RFC6056] and [Silbersack2005]) * Predictable TCP Initial Sequence Numbers (ISNs) (see e.g. [Morris1985], [Bellovin1989], and [RFC6528]) * Predictable DNS Query IDs (see e.g. [Arce1997] and [Klein2007]) These examples indicate that when new protocols are standardized or implemented, the security and privacy properties of the associated transient numeric identifiers tend to be overlooked, and inappropriate algorithms to generate such identifiers (i.e. that negatively affect the security or privacy properties of the protocol) are either suggested in the specification or selected by implementers. This document contains a non-exhaustive timeline of the specification and vulnerability disclosures related to some sample transient numeric identifiers, including other work that has led to advances in this area. This analysis indicates that: * Vulnerabilities associated with the inappropriate generation of transient numeric identifiers have affected protocol implementations for an extremely long period of time. * Such vulnerabilities, even when addressed for a given protocol version, were later reintroduced in new versions or new implementations of the same protocol. * Standardization efforts that discuss and provide advice in this area can have a positive effect on IETF specifications and their corresponding implementations. While it is generally possible to identify an algorithm that can satisfy the interoperability requirements for a given transient numeric identifier, this document provides empirical evidence that doing so without negatively affecting the security or privacy properties of the aforementioned protocols is non-trivial. Other related documents ([I-D.irtf-pearg-numeric-ids-generation] and [I-D.gont-numeric-ids-sec-considerations]) provide guidance in this area, as motivated by the present document. This document represents the consensus of the Privacy Enhancement and Assessment Research Group (PEARG). Gont & Arce Expires 14 June 2023 [Page 3] Internet-Draft Predictable Transient Numeric IDs December 2022 2. Terminology Transient Numeric Identifier: A data object in a protocol specification that can be used to definitely distinguish a protocol object (a datagram, network interface, transport protocol endpoint, session, etc) from all other objects of the same type, in a given context. Transient numeric identifiers are usually defined as a series of bits, and represented using integer values. These identifiers are typically dynamically selected, as opposed to statically-assigned numeric identifiers (see e.g. [IANA-PROT]). We note that different identifiers may have additional requirements or properties depending on their specific use in a protocol. We use the term "transient numeric identifier" (or simply "numeric identifier" or "identifier" as short forms) as a generic term to refer to any data object in a protocol specification that satisfies the identification property stated above. The terms "constant IID", "stable IID", and "temporary IID" are to be interpreted as defined in [RFC7721]. 3. Threat Model Throughout this document, we do not consider on-path attacks. That is, we assume the attacker does not have physical or logical access to the system(s) being attacked, and that the attacker can only observe traffic explicitly directed to the attacker. Similarly, an attacker cannot observe traffic transferred between a sender and the receiver(s) of a target protocol, but may be able to interact with any of these entities, including by e.g. sending any traffic to them to sample transient numeric identifiers employed by the target systems when communicating with the attacker. For example, when analyzing vulnerabilities associated with TCP Initial Sequence Numbers (ISNs), we consider the attacker is unable to capture network traffic corresponding to a TCP connection between two other hosts. However, we consider the attacker is able to communicate with any of these hosts (e.g., establish a TCP connection with any of them), to e.g. sample the TCP ISNs employed by these systems when communicating with the attacker. Similarly, when considering host-tracking attacks based on IPv6 interface identifiers, we consider an attacker may learn the IPv6 address employed by a victim node if e.g. the address becomes exposed as a result of the victim node communicating with an attacker- operated server. Subsequently, an attacker may perform host-tracking by probing a set of target addresses composed by a set of target prefixes and the IPv6 interface identifier originally learned by the Gont & Arce Expires 14 June 2023 [Page 4] Internet-Draft Predictable Transient Numeric IDs December 2022 attacker. Alternatively, an attacker may perform host tracking if e.g. the victim node communicates with an attacker-operated server as it moves from one location to another, those exposing its configured addresses. We note that none of these scenarios requires the attacker observe traffic not explicitly directed to the attacker. 4. Issues with the Specification of Transient Numeric Identifiers While assessing IETF protocol specifications regarding the use of transient numeric identifiers, we have found that most of the issues discussed in this document arise as a result of one of the following conditions: * Protocol specifications that under-specify the requirements for their transient numeric identifiers * Protocol specifications that over-specify their transient numeric identifiers * Protocol implementations that simply fail to comply with the specified requirements A number of IETF protocol specifications have simply overlooked the security and privacy implications of transient numeric identifiers. Examples of them are the specification of TCP ephemeral ports in [RFC0793], the specification of TCP sequence numbers in [RFC0793], or the specification of the DNS TxID in [RFC1035]. On the other hand, there are a number of IETF protocol specifications that over-specify some of their associated transient numeric identifiers. For example, [RFC4291] essentially overloads the semantics of IPv6 Interface Identifiers (IIDs) by embedding link- layer addresses in the IPv6 IIDs, when the interoperability requirement of uniqueness could be achieved in other ways that do not result in negative security and privacy implications [RFC7721]. Similarly, [RFC2460] suggested the use of a global counter for the generation of Fragment Identification values, when the interoperability properties of uniqueness per {Src IP, Dst IP} could be achieved with other algorithms that do not result in negative security and privacy implications [RFC7739]. Finally, there are implementations that simply fail to comply with the corresponding IETF protocol specifications or recommendations. For example, some popular operating systems (notably Microsoft Windows) still fail to implement transport protocol ephemeral port randomization, as recommended in [RFC6056]. Gont & Arce Expires 14 June 2023 [Page 5] Internet-Draft Predictable Transient Numeric IDs December 2022 The following subsections document the timelines for a number of sample transient numeric identifiers, that illustrate how the problem discussed in this document has affected protocols from different layers over time. These sample transient numeric identifiers have different interoperability requirements and failure severities (see Section 6 of [I-D.irtf-pearg-numeric-ids-generation]), and thus are considered to be representative of the problem being analyzed in this document. 4.1. IPv4/IPv6 Identification This section presents the timeline of the Identification field employed by IPv4 (in the base header) and IPv6 (in Fragment Headers). The reason for presenting both cases in the same section is to make it evident that while the Identification value serves the same purpose in both IPv4 and IPv6, the work and research done for the IPv4 case did not affect IPv6 specifications or implementations. The IPv4 Identification is specified in [RFC0791], which specifies the interoperability requirements for the Identification field: the sender must choose the Identification field to be unique for a given source address, destination address, and protocol, for the time the datagram (or any fragment of it) could be alive in the internet. It suggests that a node may keep "a table of Identifiers, one entry for each destination it has communicated with in the last maximum packet lifetime for the internet", and suggests that "since the Identifier field allows 65,536 different values, hosts may be able to simply use unique identifiers independent of destination". The above has been interpreted numerous times as a suggestion to employ per-destination or global counters for the generation of Identification values. While [RFC0791] does not suggest any flawed algorithm for the generation of Identification values, the specification omits a discussion of the security and privacy implications of predictable Identification values. This has resulted in many IPv4 implementations generating predictable fragment Identification values by means of a global counter, at least at some point in time. The IPv6 Identification was originally specified in [RFC1883]. It serves the same purpose as its IPv4 counterpart, with the only difference residing in the length of the corresponding field, and that while the IPv4 Identification field is part of the base IPv4 header, in the IPv6 case it is part of the Fragment header (which may or may not be present in an IPv6 packet). [RFC1883] states, in Section 4.5, that the Identification must be different than that of any other fragmented packet sent recently (within the maximum likely lifetime of a packet) with the same Source Address and Destination Address. Subsequently, it notes that this requirement can be met by means of a wrap-around 32-bit counter that is incremented each time a Gont & Arce Expires 14 June 2023 [Page 6] Internet-Draft Predictable Transient Numeric IDs December 2022 packet must be fragmented, and that it is an implementation choice whether to use a global or a per-destination counter. Thus, the implementation of the IPv6 Identification is similar to that of the IPv4 case, with the only difference that in the IPv6 case the suggestions to use simple counters is more explicit. [RFC2460] was the first revision of the core IPv6 specification, and maintained the same text for the specification of the IPv6 Identification field. [RFC8200], the second revision of the core IPv6 specification, removes the suggestion from [RFC2460] to use a counter for the generation of IPv6 Identification values, and points to [RFC7739] for sample algorithms for their generation. September 1981: [RFC0791] specifies the interoperability requirements for IPv4 Identification value, but does not perform a vulnerability assessment of this transient numeric identifier. December 1995: [RFC1883], the first specification of the IPv6 protocol, is published. It suggests that a counter be used to generate the IPv6 Identification value, and notes that it is an implementation choice whether to maintain a single counter for the node or multiple counters, e.g., one for each of the node's possible source addresses, or one for each active (source address, destination address) combination. December 1998: [Sanfilippo1998a] finds that predictable IPv4 Identification values (generated by most popular implementations) can be leveraged to count the number of packets sent by a target node. [Sanfilippo1998b] explains how to leverage the same vulnerability to implement a port-scanning technique known as "dumb/idle scan". A tool that implements this attack is publicly released. December 1998: [RFC2460], a revision of the IPv6 specification, is published, obsoleting [RFC1883]. It maintains the same specification of the IPv6 Identification field as its predecessor ([RFC1883]). December 1998: OpenBSD implements randomization of the IPv4 Identification field [OpenBSD-IPv4-ID]. November 1999: [Sanfilippo1999] discusses how to leverage predictable IPv4 Identification to uncover the rules of a number of firewalls. Gont & Arce Expires 14 June 2023 [Page 7] Internet-Draft Predictable Transient Numeric IDs December 2022 September 2002: [Fyodor2002] documents the implementation of the "idle/dumb scan" technique in the popular nmap tool. November 2002: [Bellovin2002] explains how the IPv4 Identification field can be exploited to count the number of systems behind a NAT. October 2003: OpenBSD implements randomization of the IPv6 Identification field [OpenBSD-IPv6-ID]. December 2003: [Zalewski2003] explains a technique to perform TCP data injection attacks based on predictable IPv4 identification values, which requires less effort than TCP injection attacks performed with bare TCP packets. November 2005: [Silbersack2005] discusses shortcomings in a number of techniques to mitigate predictable IPv4 Identification values. October 2007: [Klein2007] describes a weakness in the pseudo random number generator (PRNG) in use for the generation of the IP Identification by a number of operating systems. June 2011: [Gont2011] describes how to perform dumb/idle scan attacks in IPv6. November 2011: Linux mitigates predictable IPv6 Identification values [RedHat2011] [SUSE2011] [Ubuntu2011]. December 2011: [draft-gont-6man-predictable-fragment-id-00] describes the security implications of predictable IPv6 Identification values, and possible mitigations. This document has the Intended Status of "Standards Track", with the intention to formally update [RFC2460], to introduce security and privacy requirements on the generation of IPv6 Identification values. May 2012: [Gont2012] notes that some major IPv6 implementations still employ predictable IPv6 Identification values. Gont & Arce Expires 14 June 2023 [Page 8] Internet-Draft Predictable Transient Numeric IDs December 2022 March 2013: The 6man WG adopts [I-D.gont-6man-predictable-fragment-id], but changes the track to "BCP" (while still formally updating [RFC2460]), publishing the resulting document as [draft-ietf-6man-predictable-fragment-id-00]. June 2013: A patch to incorporate support for IPv6-based idle/dumb scans in nmap is submitted [Morbitzer2013]. December 2014: The 6man WG changes the Intended Status of [draft-ietf-6man-predictable-fragment-id-01] to "Informational" and publishes it as [draft-ietf-6man-predictable-fragment-id-02]. As a result, it no longer formally updates [RFC2460], and security and privacy requirements on the generation of IPv6 Identification values are eliminated. June 2015: [draft-ietf-6man-predictable-fragment-id-08] notes that some popular host and router implementations still employ predictable IPv6 Identification values. February 2016: [RFC7739] (based on [I-D.ietf-6man-predictable-fragment-id]) analyzes the security and privacy implications of predictable IPv6 Identification values, and provides guidance for selecting an algorithm to generate such values. However, being published with the Intended Status of "Informational", it does not formally update [RFC2460], and does not introduce security and privacy requirements on the generation of IPv6 Identification values. June 2016: [I-D.ietf-6man-rfc2460bis], revision of [RFC2460], removes the suggestion from RFC2460 to use a counter for the generation of IPv6 Identification values, but does not perform a vulnerability assessment of the generation of IPv6 Identification values, and does not introduce security and privacy requirements on the generation of IPv6 Identification values. July 2017: [I-D.ietf-6man-rfc2460bis] is finally published as [RFC8200], obsoleting [RFC2460], and pointing to [RFC7739] for sample algorithms for the generation of IPv6 Fragment Identification values. However, it does not introduce security and privacy requirements on the generation of IPv6 Identification values. Gont & Arce Expires 14 June 2023 [Page 9] Internet-Draft Predictable Transient Numeric IDs December 2022 June 2019: [IPID-DEV] notes that the IPv6 ID generators of two popular operating systems are flawed. 4.2. TCP Initial Sequence Numbers (ISNs) [RFC0793] suggests that the choice of the ISN of a connection is not arbitrary, but aims to reduce the chances of a stale segment from being accepted by a new incarnation of a previous connection. [RFC0793] suggests the use of a global 32-bit ISN generator that is incremented by 1 roughly every 4 microseconds. However, as a matter of fact, protection against stale segments from a previous incarnation of the connection is enforced by preventing the creation of a new incarnation of a previous connection before 2*MSL have passed since a segment corresponding to the old incarnation was last seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This is accomplished by the TIME-WAIT state and TCP's "quiet time" concept (see Appendix B of [RFC1323]). Based on the assumption that ISNs are monotonically increasing across connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an incoming SYN segment to perform "heuristics" that enable the creation of a new incarnation of a connection while the previous incarnation is still in the TIME-WAIT state (see p. 945 of [Wright1994]). This avoids an interoperability problem that may arise when a node establishes connections to a specific TCP end-point at a high rate [Silbersack2005]. The interoperability requirements for TCP ISNs are probably not as clearly spelled out as one would expect. Furthermore, the suggestion of employing a global counter in [RFC0793] negatively affects the security and privacy properties of the protocol. September 1981: [RFC0793], suggests the use of a global 32-bit ISN generator, whose lower bit is incremented roughly every 4 microseconds. However, such an ISN generator makes it trivial to predict the ISN that a TCP instance will use for new connections, thus allowing a variety of attacks against TCP. February 1985: [Morris1985] was the first to describe how to exploit predictable TCP ISNs for forging TCP connections that could then be leveraged for trust relationship exploitation. April 1989: [Bellovin1989] discussed the security considerations for predictable ISNs (along with a range of other protocol-based vulnerabilities). Gont & Arce Expires 14 June 2023 [Page 10] Internet-Draft Predictable Transient Numeric IDs December 2022 February 1995: [Shimomura1995] reported a real-world exploitation of the attack described in [Morris1985] ten years before (in 1985). May 1996: [RFC1948] was the first IETF effort, authored by Steven Bellovin, to address predictable TCP ISNs. However, [RFC1948] does not formally update [RFC0793]. The same concept specified in this document for TCP ISNs was later proposed for TCP ephemeral ports [RFC6056], TCP Timestamps, and eventually even IPv6 Interface Identifiers [RFC7217]. July 1996: OpenBSD implements TCP ISN randomization based on random increments (please see Appendix A.2 of [I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-I]. December 2000: OpenBSD implements TCP ISN randomization using simple randomization (please see Section 7.1 of [I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-R]. March 2001: [Zalewski2001] provides a detailed analysis of statistical weaknesses in some ISN generators, and includes a survey of the algorithms in use by popular TCP implementations. May 2001: Vulnerability advisories [CERT2001] [USCERT2001] were released regarding statistical weaknesses in some ISN generators, affecting popular TCP implementations. March 2002: [Zalewski2002] updates and complements [Zalewski2001]. It concludes that "while some vendors [...] reacted promptly and tested their solutions properly, many still either ignored the issue and never evaluated their implementations, or implemented a flawed solution that apparently was not tested using a known approach" [Zalewski2002]. Gont & Arce Expires 14 June 2023 [Page 11] Internet-Draft Predictable Transient Numeric IDs December 2022 June 2007: OpenBSD implements TCP ISN randomization based on the algorithm specified in [RFC1948] (currently obsoleted and replaced by [RFC6528]) for the TCP endpoint that performs the active open, while keeping the simple randomization scheme for the endpoint performing the passive open [OpenBSD-TCP-ISN-H]. This provides monotonically-increasing ISNs for the client side (allowing the BSD heuristics to work as expected), while avoiding any patterns in the ISN generation for the server side. February 2012: [RFC6528], published 27 years after Morris' original work [Morris1985], formally updates [RFC0793] to mitigate predictable TCP ISNs. August 2014: [I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP protocol specification, incorporates the algorithm specified in [RFC6528] as the recommended ("SHOULD") algorithm for TCP ISN generation. 4.3. IPv6 Interface Identifiers (IIDs) IPv6 Interface Identifiers can be generated as a result of different mechanisms, including SLAAC [RFC4862], DHCPv6 [RFC8415], and manual configuration. This section focuses on Interface Identifiers resulting from SLAAC. The Interface Identifier of stable (traditional) IPv6 addresses resulting from SLAAC have traditionally resulted in the underlying link-layer address being embedded in the IID.At the time, employing the underlying link-layer address for the IID was seen as a convenient way to obtain a unique address. However, recent awareness about the security and privacy properties of this approach [RFC7707] [RFC7721] has led to the replacement of this flawed scheme with an alternative one [RFC7217] [RFC8064] that does not negatively affect the security and privacy properties of the protocol. January 1997: [RFC2073] specifies the syntax of IPv6 global addresses (referred to as "An IPv6 Provider-Based Unicast Address Format" at the time), consistent with the IPv6 addressing architecture specified in [RFC1884]. Hosts are recommended to "generate addresses using link-specific addresses as Interface ID such as 48 bit IEEE-802 MAC addresses". Gont & Arce Expires 14 June 2023 [Page 12] Internet-Draft Predictable Transient Numeric IDs December 2022 July 1998: [RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address Format" (obsoleting [RFC2373]) changing the size of the IID to 64 bits, and specifies that IIDs must be constructed in IEEE EUI-64 format. How such identifiers are constructed becomes specified in the corresponding "IPv6 over " specifications, such as "IPv6 over Ethernet". January 2001: [RFC3041] recognizes the problem of network activity correlation, and specifies temporary addresses. Temporary addresses are to be used along with stable addresses. August 2003: [RFC3587] obsoletes [RFC2374], making the TLA/NLA structure historic. The syntax and recommendations for the traditional stable IIDs remain unchanged, though. February 2006: [RFC4291] is published as the latest "IP Version 6 Addressing Architecture", requiring the IIDs of the traditional (stable) IPv6 addresses resulting from SLAAC to employ the Modified EUI-64 format. The details of constructing such interface identifiers are defined in the corresponding "IPv6 over " specifications. March 2008: [RFC5157] provides hints regarding how patterns in IPv6 addresses could be leveraged for the purpose of address scanning. December 2011: [draft-gont-6man-stable-privacy-addresses-00] notes that the traditional scheme for generating stable addresses allows for address scanning, and also does not prevent active node tracking. It also specifies an alternative algorithm meant to replace IIDs based on Modified EUI-64 format identifiers. November 2012: The 6man WG adopts [I-D.gont-6man-stable-privacy-addresses] as a working group item (as [draft-ietf-6man-stable-privacy-addresses-00]). However, the document no longer formally updates [RFC4291], and therefore the specified algorithm no longer formally replaces the Modified EUI-64 format identifiers. February 2013: An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages IPv6 address patterns is released [Gont2013]. Gont & Arce Expires 14 June 2023 [Page 13] Internet-Draft Predictable Transient Numeric IDs December 2022 July 2013: [I-D.cooper-6man-ipv6-address-generation-privacy] elaborates on the security and privacy properties of all known algorithms for generating IPv6 IIDs. January 2014: The 6man WG publishes [draft-ietf-6man-default-iids-00] ("Recommendation on Stable IPv6 Interface Identifiers"), recommending [I-D.ietf-6man-stable-privacy-addresses] for the generation of stable addresses. April 2014: [RFC7217] (formerly [I-D.ietf-6man-stable-privacy-addresses]) is published, specifying "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" as an alternative to (but *not* replacement of) Modified EUI-64 format IIDs. March 2016: [RFC7707] (formerly [I-D.gont-opsec-ipv6-host-scanning], and later [I-D.ietf-opsec-ipv6-host-scanning]), about "Network Reconnaissance in IPv6 Networks", is published. March 2016: [RFC7721] (formerly [I-D.cooper-6man-ipv6-address-generation-privacy] and later [I-D.ietf-6man-ipv6-address-generation-privacy]), about "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", is published. May 2016: [draft-gont-6man-non-stable-iids-00] is published, with the goal of specifying requirements for non-stable addresses, and updating [RFC4941] such that use of only temporary addresses is allowed. May 2016: [draft-gont-6man-address-usage-recommendations-00] is published, providing an analysis of how different aspects on an address (from stability to usage mode) affect their corresponding security and privacy properties, and meaning to eventually provide advice in this area. February 2017: The 6man WG publishes [RFC8064] ("Recommendation on Stable IPv6 Interface Identifiers") (formerly [I-D.ietf-6man-default-iids]), with requirements for stable addresses and a recommendation to employ [RFC7217] for the generation of stable addresses. It formally updates a large number of RFCs. Gont & Arce Expires 14 June 2023 [Page 14] Internet-Draft Predictable Transient Numeric IDs December 2022 March 2018: [draft-fgont-6man-rfc4941bis-00] is published (as suggested by the 6man WG), to address flaws in [RFC4941] by revising it (as an alternative to the [draft-gont-6man-non-stable-iids-00] effort, published in March 2016). July 2018: [draft-fgont-6man-rfc4941bis-00] is adopted (as [draft-ietf-6man-rfc4941bis-00]) as a WG item of the 6man WG. December 2020: [I-D.ietf-6man-rfc4941bis] is approved by the IESG for publication as an RFC. February 2021: [I-D.ietf-6man-rfc4941bis] is finally published as [RFC8981]. 4.4. NTP Reference IDs (REFIDs) The NTP [RFC5905] Reference ID is a 32-bit code identifying the particular server or reference clock. Above stratum 1 (secondary servers and clients), this value can be employed to avoid degree-one timing loops; that is, scenarios where two NTP peers are (mutually) the time source of each other. If using the IPv4 address family, the identifier is the four-octet IPv4 address. If using the IPv6 address family, it is the first four octets of the MD5 hash of the IPv6 address. June 2010: [RFC5905], "Network Time Protocol Version 4: Protocol and Algorithms Specification" is published. It specifies that for NTP peers with stratum higher than 1 the REFID embeds the IPv4 Address of the time source or an MD5 hash of the IPv6 address of the time source. July 2016: [draft-stenn-ntp-not-you-refid-00] is published, describing the information leakage produced via the NTP REFID. It proposes that NTP returns a special REFID when a packet employs an IP Source Address that is not believed to be a current NTP peer, but otherwise generates and returns the traditional REFID. It is subsequently adopted by the NTP WG as [I-D.ietf-ntp-refid-updates]. Gont & Arce Expires 14 June 2023 [Page 15] Internet-Draft Predictable Transient Numeric IDs December 2022 April 2019: [Gont-NTP] notes that the proposed fix specified in [draft-ietf-ntp-refid-updates-00] is, at the very least, sub- optimal. As a result of lack of WG support, the effort is eventually abandoned. 4.5. Transport Protocol Ephemeral Port Numbers Most (if not all) transport protocols employ "port numbers" to demultiplex packets to the corresponding transport protocol instances. August 1980: [RFC0768] notes that the UDP source port is optional and identifies the port of the sending process. It does not specify interoperability requirements for source port selection, nor does it suggest possible ways to select port numbers. Most popular implementations end up selecting source ports from a system-wide global counter. September 1981: [RFC0793] (the TCP specification) essentially describes the use of port numbers, and specifies that port numbers should result in a unique socket pair (local address, local port, remote address, remote port). How ephemeral ports (i.e. port numbers for "active opens") are selected, and the port range from which they are selected, are left unspecified. July 1996: OpenBSD implements ephemeral port randomization [OpenBSD-PR]. July 2008: The CERT Coordination Centre published details of what became known as the "Kaminsky Attack" [VU-800113] [Kaminsky2008] on the DNS. The attack exploited the lack of source port randomization in many major DNS implementations to perform cache poisoning in an effective and practical manner. January 2009: [RFC5452] mandates the use of port randomization for DNS resolvers, and mandates that implementations must randomize ports from the range (53 or 1024, and above) or the largest possible port range. It does not recommend possible algorithms for port randomization, although the document specifically targets DNS resolvers, for which a simple port randomization suffices (e.g. Algorithm 1 of [RFC6056]). This document led to the implementation of port randomization in the DNS resolver themselves, rather than in the underlying transport-protocols. Gont & Arce Expires 14 June 2023 [Page 16] Internet-Draft Predictable Transient Numeric IDs December 2022 January 2011: [RFC6056] notes that many TCP and UDP implementations result in predictable port numbers, and also notes that many implementations select port numbers from a small portion of the whole port number space. It recommends the implementation and use of ephemeral port randomization, proposes a number of possible algorithms for port randomization, and also recommends to randomize port numbers over the range 1024-65535. March 2016: [NIST-NTP] reports a non-normal distribution of the ephemeral port numbers employed by the NTP clients of an Internet Time Service. April 2019: [I-D.gont-ntp-port-randomization] notes that some NTP implementations employ the NTP service port (123) as the local port for non-symmetric modes, and aims to update the NTP specification to recommend port randomization in such cases, in line with [RFC6056]. The proposal experiences some push-back in the relevant working group (NTP WG) [NTP-PORTR], but is finally adopted as a working group item as [I-D.ietf-ntp-port-randomization]. August 2021: [I-D.ietf-ntp-port-randomization] is finally published as [RFC9109]. 4.6. DNS Query ID The DNS Query ID [RFC1035] can be employed to match DNS replies to outstanding DNS queries. November 1987: [RFC1035] specifies that the ID is a 16 bit identifier assigned by the program that generates any kind of query, and that this identifier is copied in the corresponding reply and can be used by the requester to match up replies to outstanding queries. It does not specify the interoperability requirements for these numeric identifiers, nor does it suggest an algorithm for generating them. 1993: [Schuba1993] describes DNS cache poisoning attacks that require the attacker to guess the Query ID. Gont & Arce Expires 14 June 2023 [Page 17] Internet-Draft Predictable Transient Numeric IDs December 2022 June 1995: [Vixie1995] suggests that both the UDP source port and the ID of query packets should be randomized, although that might not provide enough entropy to prevent an attacker from guessing these values. April 1997: [Arce1997] finds that implementations employ predictable UDP source ports and predictable Query IDs, and argues that both should be randomized. November 2002: [Sacramento2002] finds that by spoofing multiple requests for the same domain name from different IP addresses, an attacker may guess the Query ID employed for a victim with a high probability of success, thus performing DNS cache poisoning attacks. July 2007: [Klein2007b] finds that a popular DNS server software (BIND 9) that randomizes the Query ID is still subject to DNS cache poisoning attacks by forging a large number of queries and leveraging the birthday paradox. March 2007: [Klein2007c] finds that Microsoft Windows DNS Server generates predictable Query ID values. October 2007: [Klein2007] finds that OpenBSD's DNS software (based on ISC's BIND DNS Server) generates predictable Query ID values. January 2009: [RFC5452] is published, requiring resolvers to randomize the Query ID of DNS queries, and to verify that the Query ID of a DNS reply matches that of the DNS query as part of the DNS reply validation process. May 2010: [Economou2010] finds that Windows SMTP Service implements its own DNS resolver that results in predictable Query ID values. Additionally, it fails to validate that the Query ID of DNS reply matches the one from the DNS query that supposedly elicited the reply. Gont & Arce Expires 14 June 2023 [Page 18] Internet-Draft Predictable Transient Numeric IDs December 2022 5. Conclusions For more than 30 years, a large number of implementations of the IETF protocols have been subject to a variety of attacks, with effects ranging from Denial of Service (DoS) or data injection, to information leakages that could be exploited for pervasive monitoring [RFC7258]. The root cause of these issues has been, in many cases, poor selection of transient numeric identifiers, usually as a result of insufficient or misleading specifications. While it is generally possible to identify an algorithm that can satisfy the interoperability requirements for a given transient numeric identifier, this document provides empirical evidence that doing so without negatively affecting the security or privacy properties of the aforementioned protocols is non-trivial. It is thus evident that advice in this area is warranted. [I-D.gont-numeric-ids-sec-considerations] aims at requiring future IETF protocol specifications to contain analysis of the security and privacy properties of any transient numeric identifiers specified by the protocol, and to recommend an algorithm for the generation of such transient numeric identifiers. [I-D.irtf-pearg-numeric-ids-generation] specifies a number of sample algorithms for generating transient numeric identifiers with specific interorability requirements and failure severities. 6. IANA Considerations There are no IANA registries within this document. 7. Security Considerations This document analyzes the timeline of the specification and implementation of the transient numeric identifiers of some sample IETF protocols, and how the security and privacy properties of such protocols have been affected as a result of it. It provides concrete evidence that advice in this area is warranted. [I-D.gont-numeric-ids-sec-considerations] formally requires IETF protocol specifications to specify the interoperability requirements for their transient numeric identifiers, to do a warranted vulnerability assessment of such transient numeric identifiers, and to recommend possible algorithms for their generation, such that the interoperability requirements are complied with, while any negative security and privacy properties of these transient numeric identifiers are mitigated. Gont & Arce Expires 14 June 2023 [Page 19] Internet-Draft Predictable Transient Numeric IDs December 2022 [I-D.irtf-pearg-numeric-ids-generation] analyzes and categorizes transient numeric identifiers based on their interoperability requirements and their associated failure severities, and recommends possible algorithms that can comply with those requirements without negatively affecting the security and privacy properties of the corresponding protocols. 8. Acknowledgements The authors would like to thank (in alphabetical order) Bernard Aboba, Dave Crocker, Spencer Dawkins, Theo de Raadt, Sara Dickinson, Guillermo Gont, Christian Huitema, Colin Perkins, Vincent Roca, Kris Shrishak, Joe Touch, Brian Trammell, and Christopher Wood, for providing valuable comments on earlier versions of this document. The authors would like to thank (in alphabetical order) Steven Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for providing valuable comments on [I-D.gont-predictable-numeric-ids], on which this document is based. Section 4.2 of this document borrows text from [RFC6528], authored by Fernando Gont and Steven Bellovin. The authors would like to thank Sara Dickinson and Christopher Wood, for their guidance during the publication process of this document. The authors would like to thank Diego Armando Maradona for his magic and inspiration. 9. References 9.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0793] Postel, J., "Transmission Control Protocol", RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 2012, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . Gont & Arce Expires 14 June 2023 [Page 20] Internet-Draft Predictable Transient Numeric IDs December 2022 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, December 1995, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, . [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, DOI 10.17487/RFC3041, January 2001, . [RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J. Postel, "An IPv6 Provider-Based Unicast Address Format", RFC 2073, DOI 10.17487/RFC2073, January 1997, . [RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, DOI 10.17487/RFC2374, July 1998, . [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, August 2003, . [RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6 Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884, December 1995, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . Gont & Arce Expires 14 June 2023 [Page 21] Internet-Draft Predictable Transient Numeric IDs December 2022 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 1992, . [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, . [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, DOI 10.17487/RFC5452, January 2009, . 9.2. Informative References [OpenBSD-PR] OpenBSD, "Implementation of port randomization", 29 July 1996, . [VU-800113] CERT/CC, "Multiple DNS implementations vulnerable to cache poisoning (Vulnerability Note VU#800113)", 8 July 2008, . Gont & Arce Expires 14 June 2023 [Page 22] Internet-Draft Predictable Transient Numeric IDs December 2022 [IANA-PROT] IANA, "Protocol Registries", . [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, DOI 10.17487/RFC5157, March 2008, . [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, . [I-D.ietf-6man-rfc4941bis] Gont, F., Krishnan, S., Narten, T., and R. P. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", Work in Progress, Internet- Draft, draft-ietf-6man-rfc4941bis-12, 2 November 2020, . [I-D.gont-opsec-ipv6-host-scanning] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", Work in Progress, Internet-Draft, draft-gont- opsec-ipv6-host-scanning-02, 22 October 2012, . [I-D.ietf-opsec-ipv6-host-scanning] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", Work in Progress, Internet-Draft, draft-ietf- opsec-ipv6-host-scanning-08, 28 August 2015, . [I-D.gont-6man-stable-privacy-addresses] Gont, F., "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)", Work in Progress, Internet-Draft, draft-gont- 6man-stable-privacy-addresses-01, 31 March 2012, . [I-D.ietf-6man-stable-privacy-addresses] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", Work in Progress, Internet- Gont & Arce Expires 14 June 2023 [Page 23] Internet-Draft Predictable Transient Numeric IDs December 2022 Draft, draft-ietf-6man-stable-privacy-addresses-17, 27 January 2014, . [I-D.cooper-6man-ipv6-address-generation-privacy] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", Work in Progress, Internet-Draft, draft-cooper-6man-ipv6- address-generation-privacy-00, 15 July 2013, . [I-D.ietf-6man-ipv6-address-generation-privacy] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", Work in Progress, Internet-Draft, draft-ietf-6man-ipv6- address-generation-privacy-08, 23 September 2015, . [Gont2013] Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit (help wanted!)", Message posted to the IPv6 Hackers mailing-list Message-ID: <51184548.3030105@si6networks.com>, 2013, . [IPv6-Toolkit] SI6 Networks, "SI6 Networks' IPv6 Toolkit", . [draft-gont-6man-stable-privacy-addresses-00] Gont, F., "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)", Work in Progress, Internet-Draft, draft-gont- 6man-stable-privacy-addresses-00, 15 December 2011, . [draft-ietf-6man-stable-privacy-addresses-00] Gont, F., "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)", Work in Progress, Internet-Draft, draft-ietf- 6man-stable-privacy-addresses-00, 18 May 2012, . Gont & Arce Expires 14 June 2023 [Page 24] Internet-Draft Predictable Transient Numeric IDs December 2022 [draft-gont-6man-address-usage-recommendations-00] Gont, F. and W. Liu, "IPv6 Address Usage Recommendations", Work in Progress, Internet-Draft, draft-gont-6man-address- usage-recommendations-00, 27 May 2016, . [draft-gont-6man-non-stable-iids-00] Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6 Interface Identifiers", Work in Progress, Internet-Draft, draft-gont-6man-non-stable-iids-00, 23 May 2016, . [draft-ietf-6man-default-iids-00] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", Work in Progress, Internet-Draft, draft-ietf-6man-default- iids-00, 28 July 2014, . [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, . [draft-ietf-6man-rfc4941bis-00] Gont, F., Krishnan, S.K., Narten, T.N., and R.D. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", Work in Progress, Internet- Draft, draft-ietf-6man-rfc4941bis-00, 2 July 2018, . [draft-fgont-6man-rfc4941bis-00] Gont, F., Krishnan, S.K., Narten, T.N., and R.D. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", Work in Progress, Internet- Draft, draft-fgont-6man-rfc4941bis-00, 25 March 2018, . Gont & Arce Expires 14 June 2023 [Page 25] Internet-Draft Predictable Transient Numeric IDs December 2022 [I-D.ietf-6man-default-iids] Gont, F., Cooper, A., Thaler, D., and W. S. LIU, "Recommendation on Stable IPv6 Interface Identifiers", Work in Progress, Internet-Draft, draft-ietf-6man-default- iids-16, 28 September 2016, . [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, . [I-D.gont-predictable-numeric-ids] Gont, F. and I. Arce, "Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols", Work in Progress, Internet-Draft, draft-gont-predictable- numeric-ids-03, 11 March 2019, . [I-D.gont-numeric-ids-sec-considerations] Gont, F. and I. Arce, "Security Considerations for Transient Numeric Identifiers Employed in Network Protocols", Work in Progress, Internet-Draft, draft-gont- numeric-ids-sec-considerations-08, 10 December 2022, . [I-D.irtf-pearg-numeric-ids-generation] Gont, F. and I. Arce, "On the Generation of Transient Numeric Identifiers", Work in Progress, Internet-Draft, draft-irtf-pearg-numeric-ids-generation-11, 11 July 2022, . [I-D.ietf-6man-rfc2460bis] Deering, S. E. and R. M. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", Work in Progress, Internet-Draft, draft-ietf-6man-rfc2460bis-13, 19 May 2017, . Gont & Arce Expires 14 June 2023 [Page 26] Internet-Draft Predictable Transient Numeric IDs December 2022 [draft-stenn-ntp-not-you-refid-00] Goldberg, S. and H. Stenn, "Network Time Protocol Not You REFID", Work in Progress, Internet-Draft, draft-stenn-ntp- not-you-refid-00, 8 July 2016, . [draft-ietf-ntp-refid-updates-00] Goldberg, S. and H. Stenn, "Network Time Protocol Not You REFID", Work in Progress, Internet-Draft, draft-ietf-ntp- refid-updates-00, 13 November 2016, . [Gont-NTP] Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates- 05", Post to the NTP WG mailing list Message-ID: , 16 April 2019, . [I-D.ietf-ntp-refid-updates] Stenn, H. and S. Goldberg, "Network Time Protocol REFID Updates", Work in Progress, Internet-Draft, draft-ietf- ntp-refid-updates-05, 25 March 2019, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, DOI 10.17487/RFC1948, May 1996, . [Wright1994] Wright, G.R. and W.R. Stevens, "TCP/IP Illustrated, Volume 2: The Implementation", Addison-Wesley, 1994. [Zalewski2001] Zalewski, M., "Strange Attractors and TCP/IP Sequence Number Analysis", 2001, . Gont & Arce Expires 14 June 2023 [Page 27] Internet-Draft Predictable Transient Numeric IDs December 2022 [Zalewski2002] Zalewski, M., "Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later", 2001, . [Bellovin1989] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", Computer Communications Review, vol. 19, no. 2, pp. 32-48, 1989, . [Morris1985] Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, NJ, 1985, . [USCERT2001] US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple TCP/IP implementations may use statistically predictable initial sequence numbers", 2001, . [CERT2001] CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in TCP/IP Initial Sequence Numbers", 2001, . [Shimomura1995] Shimomura, T., "Technical details of the attack described by Markoff in NYT", Message posted in USENET's comp.security.misc newsgroup Message-ID: <3g5gkl$5j1@ariel.sdsc.edu>, 1995, . [I-D.eddy-rfc793bis-04] Eddy, W., "Transmission Control Protocol Specification", Work in Progress, Internet-Draft, draft-eddy-rfc793bis-04, 25 August 2014, . [OpenBSD-TCP-ISN-I] OpenBSD, "Implementation of TCP ISN randomization based on random increments", 29 July 1996, . Gont & Arce Expires 14 June 2023 [Page 28] Internet-Draft Predictable Transient Numeric IDs December 2022 [OpenBSD-TCP-ISN-R] OpenBSD, "Implementation of TCP ISN randomization based on simple randomization", 13 December 2000, . [OpenBSD-TCP-ISN-H] OpenBSD, "Implementation of RFC1948 for TCP ISN randomization", 13 December 2000, . [I-D.gont-ntp-port-randomization] Gont, F. and G. Gont, "Port Randomization in the Network Time Protocol Version 4", Work in Progress, Internet- Draft, draft-gont-ntp-port-randomization-04, 6 August 2019, . [I-D.ietf-ntp-port-randomization] Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol Version 4: Port Randomization", Work in Progress, Internet-Draft, draft-ietf-ntp-port-randomization-08, 10 June 2021, . [RFC9109] Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol Version 4: Port Randomization", RFC 9109, DOI 10.17487/RFC9109, August 2021, . [NTP-PORTR] Gont, F., "[Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port- randomization-01.txt)", 2019, . [NIST-NTP] Sherman, J.A. and J. Levine, "Usage Analysis of the NIST Internet Time Service", Journal of Research of the National Institute of Standards and Technology Volume 121, 8 March 2016, . [IPID-DEV] Klein, A. and B. Pinkas, "From IP ID to Device ID and KASLR Bypass (Extended Version)", June 2019, . Gont & Arce Expires 14 June 2023 [Page 29] Internet-Draft Predictable Transient Numeric IDs December 2022 [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC6274] Gont, F., "Security Assessment of the Internet Protocol Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, . [RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016, . [Bellovin2002] Bellovin, S. M., "A Technique for Counting NATted Hosts", IMW'02 Nov. 6-8, 2002, Marseille, France, 2002, . [Fyodor2002] Fyodor, "Idle scanning and related IP ID games", 2002, . [Sanfilippo1998a] Sanfilippo, S., "about the ip header id", Post to Bugtraq mailing-list, Mon Dec 14 1998, . [Sanfilippo1998b] Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 1998, . [Sanfilippo1999] Sanfilippo, S., "more ip id", Post to Bugtraq mailing- list, 1999, . [Morbitzer2013] Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", Message posted to the nmap-dev mailing-list, 2013, . [OpenBSD-IPv4-ID] OpenBSD, "Randomization of the IPv4 Identification field", 26 December 1998, . Gont & Arce Expires 14 June 2023 [Page 30] Internet-Draft Predictable Transient Numeric IDs December 2022 [OpenBSD-IPv6-ID] OpenBSD, "Randomization of the IPv6 Identification field", 1 October 2003, . [Silbersack2005] Silbersack, M.J., "Improving TCP/IP security through randomization without sacrificing interoperability", EuroBSDCon 2005 Conference, 2005, . [Zalewski2003] Zalewski, M., "A new TCP/IP blind data injection technique?", 2003, . [Arce1997] Arce, I. and E. Kargieman, "BIND Vulnerabilities and Solutions", 1997, . [Klein2007] Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S Predictable IP ID Vulnerability", 2007, . [Gont2011] Gont, F., "Hacking IPv6 Networks (training course)", Hack In Paris 2011 Conference Paris, France, June 2011. [RedHat2011] RedHat, "RedHat Security Advisory RHSA-2011:1465-1: Important: kernel security and bug fix update", 2011, . [Ubuntu2011] Ubuntu, "Ubuntu: USN-1253-1: Linux kernel vulnerabilities", 2011, . [SUSE2011] SUSE, "SUSE Security Announcement: Linux kernel security update (SUSE-SA:2011:046)", 2011, . Gont & Arce Expires 14 June 2023 [Page 31] Internet-Draft Predictable Transient Numeric IDs December 2022 [Gont2012] Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012 Conference Ottawa, Canada. May 11-12, 2012, May 2012, . [I-D.gont-6man-predictable-fragment-id] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, Internet-Draft, draft-gont-6man-predictable-fragment-id-03, 9 January 2013, . [I-D.ietf-6man-predictable-fragment-id] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, Internet-Draft, draft-ietf-6man-predictable-fragment-id-10, 9 October 2015, . [draft-ietf-6man-predictable-fragment-id-01] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, Internet-Draft, draft-ietf-6man-predictable-fragment-id-01, 30 April 2014, . [draft-ietf-6man-predictable-fragment-id-02] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, Internet-Draft, draft-ietf-6man-predictable-fragment-id-02, 19 December 2014, . [draft-gont-6man-predictable-fragment-id-00] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, Internet-Draft, draft-gont-6man-predictable-fragment-id-00, 15 December 2011, . [draft-ietf-6man-predictable-fragment-id-00] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, Internet-Draft, draft-ietf-6man-predictable-fragment-id-00, 22 March 2013, . Gont & Arce Expires 14 June 2023 [Page 32] Internet-Draft Predictable Transient Numeric IDs December 2022 [draft-ietf-6man-predictable-fragment-id-08] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, Internet-Draft, draft-ietf-6man-predictable-fragment-id-08, 9 June 2015, . [Schuba1993] Schuba, C., "ADDRESSING WEAKNESSES IN THE DOMAIN NAME SYSTEM PROTOCOL", 1993, . [Vixie1995] Vixie, P., "DNS and BIND Security Issues", 5th Usenix Security Symposium May 2, 1995, 2 May 1995, . [Klein2007b] Klein, A., "BIND 9 DNS Cache Poisoning", March 2007, . [Klein2007c] Klein, A., "Windows DNS Server Cache Poisoning", March 2007, . [Sacramento2002] Sacramento, V., "CAIS-ALERT: Vulnerability in the sending requests control of BIND", 19 November 2002, . [Kaminsky2008] Kaminsky, D., "Black Ops 2008: It's The End Of The Cache As We Know It", August 2008, . [Economou2010] Economou, N., "Windows SMTP Service DNS query Id vulnerabilities", Advisory ID Internal CORE-2010-0427 May 4, 2010, 4 May 2010, . Gont & Arce Expires 14 June 2023 [Page 33] Internet-Draft Predictable Transient Numeric IDs December 2022 Authors' Addresses Fernando Gont SI6 Networks Segurola y Habana 4310 7mo piso Ciudad Autonoma de Buenos Aires Buenos Aires Argentina Email: fgont@si6networks.com URI: https://www.si6networks.com Ivan Arce Quarkslab Segurola y Habana 4310 7mo piso Ciudad Autonoma de Buenos Aires Buenos Aires Argentina Email: iarce@quarkslab.com URI: https://www.quarkslab.com Gont & Arce Expires 14 June 2023 [Page 34] ./draft-irtf-qirg-principles-11.txt0000644000764400076440000034401014303054625016777 0ustar iustiniustin Quantum Internet Research Group W. Kozlowski Internet-Draft S. Wehner Intended status: Informational QuTech Expires: 1 March 2023 R. Van Meter Keio University B. Rijsman Individual A. S. Cacciapuoti M. Caleffi University of Naples Federico II S. Nagayama Mercari, Inc. 28 August 2022 Architectural Principles for a Quantum Internet draft-irtf-qirg-principles-11 Abstract The vision of a quantum internet is to enhance existing Internet technology by enabling quantum communication between any two points on Earth. To achieve this goal, a quantum network stack should be built from the ground up to account for the fundamentally new properties of quantum entanglement. The first quantum entanglement networks have been realised [Pompili21.1], but there is no practical proposal for how to organise, utilise, and manage such networks. In this draft, we attempt to lay down the framework and introduce some basic architectural principles for a quantum internet. This is intended for general guidance and general interest, but also to provide a foundation for discussion between physicists and network specialists. This document is a product of the Quantum Internet Research Group (QIRG). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Kozlowski, et al. Expires 1 March 2023 [Page 1] Internet-Draft Principles for a Quantum Internet August 2022 This Internet-Draft will expire on 1 March 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Quantum information . . . . . . . . . . . . . . . . . . . . . 4 2.1. Quantum state . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Qubit . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Multiple qubits . . . . . . . . . . . . . . . . . . . . . 6 3. Entanglement as the fundamental resource . . . . . . . . . . 8 4. Achieving quantum connectivity . . . . . . . . . . . . . . . 9 4.1. Challenges . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. The measurement problem . . . . . . . . . . . . . . . 9 4.1.2. No-cloning theorem . . . . . . . . . . . . . . . . . 10 4.1.3. Fidelity . . . . . . . . . . . . . . . . . . . . . . 10 4.1.4. Inadequacy of direct transmission . . . . . . . . . . 11 4.2. Bell pairs . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Teleportation . . . . . . . . . . . . . . . . . . . . . . 12 4.4. The life cycle of entanglement . . . . . . . . . . . . . 13 4.4.1. Elementary link generation . . . . . . . . . . . . . 13 4.4.2. Entanglement swapping . . . . . . . . . . . . . . . . 14 4.4.3. Error Management . . . . . . . . . . . . . . . . . . 15 4.4.4. Delivery . . . . . . . . . . . . . . . . . . . . . . 19 5. Architecture of a quantum internet . . . . . . . . . . . . . 19 5.1. Challenges . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Classical communication . . . . . . . . . . . . . . . . . 21 5.3. Abstract model of the network . . . . . . . . . . . . . . 22 5.3.1. The control and data planes . . . . . . . . . . . . . 22 5.3.2. Elements of a quantum network . . . . . . . . . . . . 23 5.3.3. Putting it all together . . . . . . . . . . . . . . . 24 5.4. Physical constraints . . . . . . . . . . . . . . . . . . 25 5.4.1. Memory lifetimes . . . . . . . . . . . . . . . . . . 26 5.4.2. Rates . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4.3. Communication qubits . . . . . . . . . . . . . . . . 27 Kozlowski, et al. Expires 1 March 2023 [Page 2] Internet-Draft Principles for a Quantum Internet August 2022 5.4.4. Homogeneity . . . . . . . . . . . . . . . . . . . . . 27 6. Architectural principles . . . . . . . . . . . . . . . . . . 28 6.1. Goals of a quantum internet . . . . . . . . . . . . . . . 28 6.2. The principles of a quantum internet . . . . . . . . . . 32 7. A thought experiment inspired by classical networks . . . . . 34 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 11. Informative References . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction Quantum networks are distributed systems of quantum devices that utilise fundamental quantum mechanical phenomena such as superposition, entanglement, and quantum measurement to achieve capabilities beyond what is possible with non-quantum (classical) networks [Kimble08]. Depending on the stage of a quantum network [Wehner18] such devices may range from simple photonic devices capable of preparing and measuring only one quantum bit (qubit) at a time all the way to large-scale quantum computers of the future. A quantum network is not meant to replace classical networks, but rather form an overall hybrid classical-quantum network supporting new capabilities which are otherwise impossible to realise [VanMeterBook]. For example, the most well-known application of quantum communication, quantum key distribution (QKD), can create and distribute a pair of symmetric encryption keys in such a way that the security of the entire process relies on the laws of physics (and thus can be mathematically proven to be unbreakable) rather than the intractability of certain mathematical problems [Bennett14] [Ekert91]. Small networks capable of QKD have even already been deployed at short (roughly 100km) distances [Elliott03] [Peev09] [Aguado19] [Joshi20]. The quantum networking paradigm also offers promise for a range of new applications beyond quantum cryptography, such as distributed quantum computation [Cirac99] [Crepeau02], secure quantum computing in the cloud [Fitzsimons17], quantum-enhanced measurement networks [Giovanetti04], or higher-precision, long-baseline telescopes [Gottesman12]. These applications are much more demanding than QKD and networks capable of executing them are in their infancy. The first fully quantum, multinode network capable of sending, receiving, and manipulating distributed quantum information has only recently been realized [Pompili21.1] Whilst a lot of effort has gone into physically realising and connecting such devices, and making improvements to their speed and error tolerance, there are no worked out proposals for how to run Kozlowski, et al. Expires 1 March 2023 [Page 3] Internet-Draft Principles for a Quantum Internet August 2022 these networks. To draw an analogy with a classical network, we are at a stage where we can start to physically connect our devices and send data, but all sending, receiving, buffer management, connection synchronisation, and so on, must be managed by the application directly by using low-level, custom-built, and hardware-specific interfaces, rather than being managed by a network stack that exposes a convenient high-level interface, such as sockets. Only recently, was the first ever attempt at such a network stack experimentally demonstrated in a laboratory setting [Pompili21.2]. Furthermore, whilst physical mechanisms for transmitting quantum information exist, there are no robust protocols for managing such transmissions. This document, produced by the Quantum Internet Research Group (QIRG), introduces quantum networks and presents general guidelines for the design and construction of such networks. Overall, it is intended as an introduction to the subject for network engineers and researchers. It should not be considered as a conclusive statement on how quantum network should or will be implemented. This document was discussed on the QIRG mailing list and several IETF meetings and represents the consensus of the QIRG members, both of experts in the subject matter (from the quantum as well networking domain) as well as newcomers who are the target audience. 2. Quantum information In order to understand the framework for quantum networking, a basic understanding of quantum information theory is necessary. The following sections aim to introduce the minimum amount of knowledge necessary to understand the principles of operation of a quantum network. This exposition was written with a classical networking audience in mind. It is assumed that the reader has never before been exposed to any quantum physics. We refer the reader to [SutorBook] and [NielsenChuang] for an in-depth introduction to quantum information systems. 2.1. Quantum state A quantum mechanical system is described by its quantum state. A quantum state is an abstract object that provides a complete description of the system at that particular moment. When combined with the rules of the system's evolution in time, such as a quantum circuit, it also then provides a complete description of the system at all times. For the purposes of computing and networking, the classical equivalent of a quantum state would be a string or stream of logical bit values. These bits provide a complete description of what values we can read out from that string at that particular moment and when combined with its rules for evolution in time, such as a logical circuit, we will also know its value at any other time. Kozlowski, et al. Expires 1 March 2023 [Page 4] Internet-Draft Principles for a Quantum Internet August 2022 Just like a single classical bit, a quantum mechanical system can be simple and consist of a single particle, e.g. an atom or a photon of light. In this case, the quantum state provides the complete description of that one particle. Similarly, just like a string of bits consists of multiple bits, a single quantum state can be used to also describe an ensemble of many particles. However, because quantum states are governed by the laws of quantum mechanics their behaviour is significantly different to that of a string of bits. In this section we will summarise the key concepts to understand these differences and the we will explain their consequences for networking in the rest of the draft. 2.2. Qubit The differences between quantum computation and classical computation begin at the bit-level. A classical computer operates on the binary alphabet { 0, 1 }. A quantum bit, called a qubit, exists over the same binary space, but unlike the classical bit, its state can exist in a superposition of the two possibilities: |qubit> = a |0> + b |1>, where |X> is Dirac's ket notation for a quantum state (the value that a qubit holds), here the binary 0 and 1, and the coefficients a and b are complex numbers called probability amplitudes. Physically, such a state can be realised using a variety of different technologies such as electron spin, photon polarisation, atomic energy levels, and so on. Upon measurement, the qubit loses its superposition and irreversibly collapses into one of the two basis states, either |0> or |1>. Which of the two states it ends up in may not be deterministic, but can be determined from the readout of the measurement. The measurement result is a classical bit, 0 or 1, corresponding to |0> and |1> respectively. The probability of measuring the state in the |0> state is |a|^2 and similarly the probability of measuring the state in the |1> state is |b|^2, where |a|^2 + |b|^2 = 1. This randomness is not due to our ignorance of the underlying mechanisms, but rather is a fundamental feature of a quantum mechanical system [Aspect81]. The superposition property plays an important role in fundamental gate operations on qubits. Since a qubit can exist in a superposition of its basis states, the elementary quantum gates are able to act on all states of the superposition at the same time. For example, consider the NOT gate: NOT (a |0> + b |1>) -> a |1> + b |0>. Kozlowski, et al. Expires 1 March 2023 [Page 5] Internet-Draft Principles for a Quantum Internet August 2022 It is important to note that "qubit" can have two meanings. In the first meaning, "qubit" refers to a physical quantum *system* whose quantum state can be expressed as a superposition of two basis states, which we often label |0> and |1>. Here, "qubit" refers to a physical implementation akin to what a flip-flop, switch, voltage, or current would be for a classical bit. In the second meaning, "qubit" refers to the abstract quantum *state* of a quantum system with such two basis states. In this case, the meaning of "qubit" is akin to the logical value of a bit, from classical computing, i.e. "logical 0" or "logical 1". The two concepts are related, because a physical "qubit" (first meaning) can be used to store the abstract "qubit" (second meaning). Both meanings are used interchangeably in literature and the meaning is generally clear from the context. 2.3. Multiple qubits When multiple qubits are combined in a single quantum state the space of possible states grows exponentially and all these states can coexist in a superposition. For example, the general form of a two- qubit register is a |00> + b |01> + c |10> + d |11> where the coefficients have the same probability amplitude interpretation as for the single qubit state. Each state represents a possible outcome of a measurement of the two-qubit register. For example, |01> denotes a state in which the first qubit is in the state |0> and the second is in the state |1>. Performing single qubit gates affects the relevant qubit in each of the superposition states. Similarly, two-qubit gates also act on all the relevant superposition states, but their outcome is far more interesting. Consider a two-qubit register where the first qubit is in the superposed state (|0> + |1>)/sqrt(2) and the other is in the state |0>. This combined state can be written as: (|0> + |1>)/sqrt(2) x |0> = (|00> + |10>)/sqrt(2), where x denotes a tensor product (the mathematical mechanism for combining quantum states together). The constant 1/sqrt(2) is called the normalisation factor and reflects the fact that the probabilities of measuring either a |0> or a |1> for the first qubit add up to one. Kozlowski, et al. Expires 1 March 2023 [Page 6] Internet-Draft Principles for a Quantum Internet August 2022 Let us now consider the two-qubit controlled-NOT, or CNOT, gate. The CNOT gate takes as input two qubits, a control and target, and applies the NOT gate to the target if the control qubit is set. The truth table looks like +====+=====+ | IN | OUT | +====+=====+ | 00 | 00 | +----+-----+ | 01 | 01 | +----+-----+ | 10 | 11 | +----+-----+ | 11 | 10 | +----+-----+ Table 1 Now, consider performing a CNOT gate on the state with the first qubit being the control. We apply a two-qubit gate on all the superposition states: CNOT (|00> + |10>)/sqrt(2) -> (|00> + |11>)/sqrt(2). What is so interesting about this two-qubit gate operation? The final state is *entangled*. There is no possible way of representing that quantum state as a product of two individual qubits; they are no longer independent. That is, it is not possible to describe the quantum state of either of the individual qubits in a way that is independent of the other qubit. Only the quantum state of the system that consists of both qubits provides a physically complete description of the two-qubit system. The states of the two individual qubits are now correlated beyond what is possible to achieve classically. Neither qubit is in a definite |0> or |1> state, but if we perform a measurement on either one, the outcome of the partner qubit will *always* yield the exact same outcome. The final state, whether it's |00> or |11>, is fundamentally random as before, but the states of the two qubits following a measurement will always be identical. One can think of this as flipping two coins, but the coins always both land on "heads" or both land on "tails" together. Something that we know is impossible classically. Once a measurement is performed, the two qubits are once again independent. The final state is either |00> or |11> and both of these states can be trivially decomposed into a product of two individual qubits. The entanglement has been consumed and the entangled state must be prepared again. Kozlowski, et al. Expires 1 March 2023 [Page 7] Internet-Draft Principles for a Quantum Internet August 2022 3. Entanglement as the fundamental resource Entanglement is the fundamental building block of quantum networks. Consider the state from the previous section: (|00> + |11>)/sqrt(2). Neither of the two qubits is in a definite |0> or |1> state and we need to know the state of the entire register to be able to fully describe the behaviour of the two qubits. Entangled qubits have interesting non-local properties. Consider sending one of the qubits to another device. This device could in principle be anywhere: on the other side of the room, in a different country, or even on a different planet. Provided negligible noise has been introduced, the two qubits will forever remain in the entangled state until a measurement is performed. The physical distance does not matter at all for entanglement. This lies at the heart of quantum networking, because it is possible to leverage the non-classical correlations provided by entanglement in order to design completely new types of application protocols that are not possible to achieve with just classical communication. Examples of such applications are quantum cryptography [Bennett14] [Ekert91], blind quantum computation [Fitzsimons17], or distributed quantum computation [Crepeau02]. Entanglement has two very special features from which one can derive some intuition about the types of applications enabled by a quantum network. The first stems from the fact that entanglement enables stronger than classical correlations, leading to opportunities for tasks that require coordination. As a trivial example, consider the problem of consensus between two nodes who want to agree on the value of a single bit. They can use the quantum network to prepare the state (|00> + |11>)/sqrt(2) with each node holding one of the two qubits. Once either of the two nodes performs a measurement, the state of the two qubits collapses to either |00> or |11>, so whilst the outcome is random and does not exist before measurement, the two nodes will always measure the same value. We can also build the more general multi-qubit state (|00...> + |11...>)/sqrt(2) and perform the same algorithm between an arbitrary number of nodes. These stronger than classical correlations generalise to more complicated measurement schemes as well. Kozlowski, et al. Expires 1 March 2023 [Page 8] Internet-Draft Principles for a Quantum Internet August 2022 The second feature of entanglement is that it cannot be shared, in the sense that if two qubits are maximally entangled with each other, then it is physically impossible for these two qubits to also be entangled with a third qubit [Terhal04]. Hence, entanglement forms a sort of private and inherently untappable connection between two nodes once established. Entanglement is created through local interactions between two qubits or as a product of the way the qubits were created (e.g. entangled photon pairs). To create a distributed entangled state, one can then physically send one of the qubits to a remote node. It is also possible to directly entangle qubits that are physically separated, but this still requires local interactions between some other qubits that the separated qubits are initially entangled with. Therefore, it is the transmission of qubits that draws the line between a genuine quantum network and a collection of quantum computers connected over a classical network. A quantum network is defined as a collection of nodes that is able to exchange qubits and distribute entangled states amongst themselves. A quantum node that is able only to communicate classically with another quantum node is not a member of a quantum network. More complex services and applications can be built on top of entangled states distributed by the network, see e.g. [ZOO] 4. Achieving quantum connectivity This section explains the meaning of quantum connectivity and the necessary physical processes at an abstract level. 4.1. Challenges A quantum network cannot be built by simply extrapolating all the classical models to their quantum analogues. Sending qubits over a wire like we send classical bits is simply not as easy to do. There are several technological as well as fundamental challenges that make classical approaches unsuitable in a quantum context. 4.1.1. The measurement problem In classical computers and networks we can read out the bits stored in memory at any time. This is helpful for a variety of purposes such as copying, error detection and correction, and so on. This is not possible with qubits. Kozlowski, et al. Expires 1 March 2023 [Page 9] Internet-Draft Principles for a Quantum Internet August 2022 A measurement of a qubit's state will destroy its superposition and with it any entanglement it may have been part of. Once a qubit is being processed, it cannot be read out until a suitable point in the computation, determined by the protocol handling the qubit, has been reached. Therefore, we cannot use the same methods known from classical computing for the purposes of error detection and correction. Nevertheless, quantum error detection and correction schemes exist that take this problem into account and how a network chooses to manage errors will have an impact on its architecture. 4.1.2. No-cloning theorem Since directly reading the state of a qubit is not possible, one could ask if we can simply copy a qubit without looking at it. Unfortunately, this is fundamentally not possible in quantum mechanics [Park70] [Wootters82]. The no-cloning theorem states that it is impossible to create an identical copy of an arbitrary, unknown quantum state. Therefore, it is also impossible to use the same mechanisms that worked for classical networks for signal amplification, retransmission, and so on as they all rely on the ability to copy the underlying data. Since any physical channel will always be lossy, connecting nodes within a quantum network is a challenging endeavour and its architecture must at its core address this very issue. 4.1.3. Fidelity In general, it is expected that a classical packet arrives at its destination without any errors introduced by hardware noise along the way. This is verified at various levels through a variety of error detection and correction mechanisms. Since we cannot read or copy a quantum state, error detection and correction is more involved. To describe the quality of a quantum state, a physical quantity called fidelity is used [NielsenChuang]. Fidelity takes a value between 0 and 1 -- higher is better, and less than 0.5 means the state is unusable. It measures how close a quantum state is to the state we have tried to create. It expresses the probability that the state will behave exactly the same as our desired state. Fidelity is an important property of a quantum system that allows us to quantify how much a particular state has been affected by noise from various sources (gate errors, channel losses, environment noise). Interestingly, quantum applications do not need perfect fidelity to be able to execute -- as long as the fidelity is above some application-specific threshold, they will simply operate at lower rates. Therefore, rather than trying to ensure that we always Kozlowski, et al. Expires 1 March 2023 [Page 10] Internet-Draft Principles for a Quantum Internet August 2022 deliver perfect states (a technologically challenging task) applications will specify a minimum threshold for the fidelity and the network will try its best to deliver it. A higher fidelity can be achieved by either having hardware produce states of better fidelity (sometimes one can sacrifice rate for higher fidelity) or by employing quantum error detection and correction mechanisms (see [Mural16] and [VanMeterBook] chapter 11). 4.1.4. Inadequacy of direct transmission Conceptually, the most straightforward way to distribute an entangled state is to simply transmit one of the qubits directly to the other end across a series of nodes while performing sufficient forward quantum error correction (Section 4.4.3.2) to bring losses down to an acceptable level. Despite the no-cloning theorem and the inability to directly measure a quantum state, error-correcting mechanisms for quantum communication exist [Jiang09] [Fowler10] [Devitt13] [Mural16]. However, quantum error correction makes very high demands on both resources (physical qubits needed) and their initial fidelity. Implementation is very challenging and quantum error correction is not expected to be used until later generations of quantum networks are possible (see [Mural16] figure 2 and Section 4.4.3.3). Until then, quantum networks rely on entanglement swapping (Section 4.4.2) and teleportation (Section 4.3). This alternative relies on the observation that we do not need to be able to distribute any arbitrary entangled quantum state. We only need to be able to distribute any one of what are known as the Bell pair states [Briegel98]. 4.2. Bell pairs Bell pair states are the entangled two-qubit states: |00> + |11>, |00> - |11>, |01> + |10>, |01> - |10>, where the constant 1/sqrt(2) normalisation factor has been ignored for clarity. Any of the four Bell pair states above will do, as it is possible to transform any Bell pair into another Bell pair with local operations performed on only one of the qubits. When each qubit in a Bell pair is held by a separate node, either node can apply a series of single qubit gates to their qubit alone in order to transform the state between the different variants. Distributing a Bell pair between two nodes is much easier than transmitting an arbitrary quantum state over a network. Since the state is known, handling errors becomes easier and small-scale error- correction (such as entanglement distillation discussed in a later section) combined with reattempts becomes a valid strategy. Kozlowski, et al. Expires 1 March 2023 [Page 11] Internet-Draft Principles for a Quantum Internet August 2022 The reason for using Bell pairs specifically as opposed to any other two-qubit state is that they are the maximally entangled two-qubit set of basis states. Maximal entanglement means that these states have the strongest non-classical correlations of all possible two- qubit states. Furthermore, since single-qubit local operations can never increase entanglement, less entangled states would impose some constraints on distributed quantum algorithms. This makes Bell pairs particularly useful as a generic building block for distributed quantum applications. 4.3. Teleportation The observation that we only need to be able to distribute Bell pairs relies on the fact that this enables the distribution of any other arbitrary entangled state. This can be achieved via quantum state teleportation [Bennett93]. Quantum state teleportation consumes an unknown qubit state that we want to transmit and recreates it at the desired destination. This does not violate the no-cloning theorem as the original state is destroyed in the process. To achieve this, an entangled pair needs to be distributed between the source and destination before teleportation commences. The source then entangles the transmission qubit with its end of the pair and performs a read out of the two qubits (the sum of these operations is called a Bell state measurement). This consumes the Bell pair's entanglement, turning the source and destination qubits into independent states. The measurements yields two classical bits which the source sends to the destination over a classical channel. Based on the value of the received two classical bits, the destination performs one of four possible corrections (called the Pauli corrections) on its end of the pair, which turns it into the unknown qubit state that we wanted to transmit. This requirement to communicate the measurement read out over a classical channel unfortunately means that entanglement cannot be used to transmit information faster than the speed of light. The unknown quantum state that was transmitted was never fed into the network itself. Therefore, the network needs to only be able to reliably produce Bell pairs between any two nodes in the network. Thus, a key difference between a classical and quantum data planes is that a classical one carries user data, but a quantum data plane provides the resources for the user to transmit user data themselves without further involvement of the network. Kozlowski, et al. Expires 1 March 2023 [Page 12] Internet-Draft Principles for a Quantum Internet August 2022 4.4. The life cycle of entanglement Reducing the problem of quantum connectivity to one of generating a Bell pair has facilitated the problem, but it has not solved it. In this section, we discuss how these entangled pairs are generated in the first place, and how their two qubits are delivered to the end- points. 4.4.1. Elementary link generation In a quantum network, entanglement is always first generated locally (at a node or an auxiliary element) followed by a movement of one or both of the entangled qubits across the link through quantum channels. In this context, photons (particles of light) are the natural candidate for entanglement carriers, called flying qubits. The rationale for this choice is related to the advantages provided by photons such as moderate interaction with the environment leading to moderate decoherence, convenient control with standard optical components, and high-speed, low-loss transmissions. However, since photons are hard to store, a transducer must transfer the flying qubit's state to a qubit suitable for information processing and/or storage (often referred to as a matter qubit). Since this process may fail, in order to generate and store entanglement efficiently, we must be able to distinguish successful attempts from failures. Entanglement generation schemes that are able to announce successful generation are called heralded entanglement generation schemes. There exist three basic schemes for heralded entanglement generation on a link through coordinated action of the two nodes at the two ends of the link [Cacciapuoti19]: * "At mid-point": in this scheme an entangled photon pair source sitting midway between the two nodes with matter qubits sends an entangled photon through a quantum channel to each of the nodes. There, transducers are invoked to transfer the entanglement from the flying qubits to the matter qubits. In this scheme, the transducers know if the transfers succeeded and are able to herald successful entanglement generation via a message exchange over the classical channel. Kozlowski, et al. Expires 1 March 2023 [Page 13] Internet-Draft Principles for a Quantum Internet August 2022 * "At source": in this scheme one of the two nodes sends a flying qubit that is entangled with one of its matter qubits. A transducer at the other end of the link will transfer the entanglement from the flying qubit to one of its matter qubits. Just like in the previous scheme, the transducer knows if its transfer succeeded and is able to herald successful entanglement generation with a classical message sent to the other node. * "At both end-points": in this scheme both nodes send a flying qubit that is entangled with one of their matter qubits. A detector somewhere in between the nodes performs a joint measurement on the two qubits, which stochastically projects the remote matter qubits into an entangled quantum state. The detector knows if the entanglement succeeded and is able to herald successful entanglement generation by sending a message to each node over the classical channel. The "mid-point source" scheme is more robust to photon loss, but in the other schemes the nodes retain greater control over the entangled pair generation. Note that whilst photons travel in a particular direction through the quantum channel the resulting entangled pair of qubits does not have a direction associated with it. Physically, there is no upstream or downstream end of the pair. 4.4.2. Entanglement swapping The problem with generating entangled pairs directly across a link is that efficiency decreases with channel length. Beyond a few 10s of kilometres in optical fibre or 1000 kilometres in free space (via satellite) the rate is effectively zero and due to the no-cloning theorem we cannot simply amplify the signal. The solution is entanglement swapping [Briegel98]. A Bell pair between any two nodes in the network can be constructed by combining the pairs generated along each individual link on a path between the two end-points. Each node along the path can consume the two pairs on the two links that it is connected to in order to produce a new entangled pair between the two remote ends. This process is known as entanglement swapping. Pictorially it can be represented as follows: +---------+ +---------+ +---------+ | A | | B | | C | | |------| |------| | | X1~~~~~~~~~~X2 Y1~~~~~~~~~~Y2 | +---------+ +---------+ +---------+ Kozlowski, et al. Expires 1 March 2023 [Page 14] Internet-Draft Principles for a Quantum Internet August 2022 where X1 and X2 are the qubits of the entangled pair X and Y1 and Y2 are the qubits of entangled pair Y. The entanglement is denoted with ~~. In the diagram above, nodes A and B share the pair X and nodes B and C share the pair Y, but we want entanglement between A and C. To achieve this goal, we simply teleport the qubit X2 using the pair Y. This requires node B to perform a Bell state measurement on the qubits X2 and Y1 which result in the destruction of the entanglement between Y1 and Y2. However, X2 is recreated in Y2's place, carrying with it its entanglement with X1. The end-result is shown below: +---------+ +---------+ +---------+ | A | | B | | C | | |------| |------| | | X1~~~~~~~~~~~~~~~~~~~~~~~~~~~X2 | +---------+ +---------+ +---------+ Depending on the needs of the network and/or application, a final Pauli correction at the recipient node may not be necessary since the result of this operation is also a Bell pair. However, the two classical bits that form the read out from the measurement at node B must still be communicated, because they carry information about which of the four Bell pairs was actually produced. If a correction is not performed, the recipient must be informed which Bell pair was received. This process of teleporting Bell pairs using other entangled pairs is called entanglement swapping. Quantum nodes that create long- distance entangled pairs via entanglement swapping are called quantum repeaters in academic literature [Briegel98] and we will use the same terminology in this draft. 4.4.3. Error Management 4.4.3.1. Distillation Neither the generation of Bell pairs nor the swapping operations are noiseless operations. Therefore, with each link and each swap the fidelity of the state degrades. However, it is possible to create higher fidelity Bell pair states from two or more lower fidelity pairs through a process called distillation (sometimes also referred to as purification) [Dur07]. To distil a quantum state, a second (and sometimes third) quantum state is used as a "test tool" to test a proposition about the first state, e.g., "the parity of the two qubits in the first state is even." When the test succeeds, confidence in the state is improved, and thus the fidelity is improved. The test tool states are Kozlowski, et al. Expires 1 March 2023 [Page 15] Internet-Draft Principles for a Quantum Internet August 2022 destroyed in the process, so resource demands increase substantially when distillation is used. When the test fails, the tested state must also be discarded. Distillation makes low demands on fidelity and resources compared to quantum error correction, but distributed protocols incur round-trip delays due to classical communication [Bennett96]. 4.4.3.2. Quantum Error Correction Just like classical error correction, quantum error correction (QEC) encodes logical qubits using several physical (raw) qubits to protect them from errors described in Section 4.1.3 [Jiang09] [Fowler10] [Devitt13] [Mural16]. Furthermore, similarly to its classical counterpart, QEC can not only correct state errors but also account for lost qubits. Additionally, if all physical qubits which encode a logical qubit are located at the same node, the correction procedure can be executed locally, even if the logical qubit is entangled with remote qubits. Although QEC was originally a scheme proposed to protect a qubit from noise, QEC can also be applied to entanglement distillation. Such QEC-applied distillation is cost-effective but requires a higher base fidelity. 4.4.3.3. Error management schemes Quantum networks have been categorized into three "generations" based on the error management scheme they employ [Mural16]. Note that these "generations" are more like categories; they do not necessarily imply a time progression and do not obsolete each other, though the later generations do require more advanced technologies. Which generation is used depends on the hardware platform and network design choices. Table 2 summarises the generations. Kozlowski, et al. Expires 1 March 2023 [Page 16] Internet-Draft Principles for a Quantum Internet August 2022 +===========+=================+=======================+============+ | | First | Second generation | Third | | | generation | | generation | +===========+=================+=======================+============+ | Loss | Heralded | Heralded entanglement | Quantum | | tolerance | entanglement | generation (bi- | Error | | | generation (bi- | directional classical | Correction | | | directional | signaling) | (no | | | classical | | classical | | | signaling) | | signaling) | +-----------+-----------------+-----------------------+------------+ +-----------+-----------------+-----------------------+------------+ | Error | Entanglement | Entanglement | Quantum | | tolerance | distillation | distillation (uni- | Error | | | (bi-directional | directional classical | Correction | | | classical | signaling) or Quantum | (no | | | signaling) | Error Correction (no | classical | | | | classical signaling) | signaling) | +-----------+-----------------+-----------------------+------------+ Table 2: Classical signaling and generations Generations are defined by the directions of classical signalling required in their distributed protocols for loss tolerance and error tolerance. Classical signalling carries the classical bits and incurs round-trip delays described in Section 4.4.3.1, hence they affect the performance of quantum networks, especially as the distance between the communicating nodes increases. Loss tolerance is about tolerating qubit transmission losses between nodes. Heralded entanglement generation, as described in Section 4.4.1, confirms the receipt of an entangled qubit using a heralding signal. A pair of directly connected quantum nodes repeatedly attempt to generate an entangled pair until the a heralding signal is received. As described in Section 4.4.3.2, QEC can be applied to complement lost qubits eliminating the need for re- attempts. Furthermore, since the correction procedure is composed of local operations, it does not require a heralding signal. However, it is possible only when the photon loss rate from transmission to measurement is less than 50%. Kozlowski, et al. Expires 1 March 2023 [Page 17] Internet-Draft Principles for a Quantum Internet August 2022 Error tolerance is about tolerating quantum state errors. Entanglement distillation is the easiest mechanism for improved error tolerance to implement, but it incurs round-trip delays due the requirement for bi-directional classical signalling. The alternative, QEC, is able to correct state errors locally so that it does not need any classical signalling between the quantum nodes. In between these two extremes, there is also QEC-applied distillation, which requires uni-directional classical signalling. The three "generations" summarised: 1. First generation quantum networks use heralding for loss tolerance and entanglement distillation for error tolerance. These networks can be implemented even with a limited set of available quantum gates. 2. Second generation quantum networks improve upon the first generation with QEC codes for error tolerance (but not loss tolerance). At first, QEC will be applied to entanglement distillation only which requires uni-directional classical signalling. Later, QEC codes will be used to create logical Bell pairs which no longer require any classical signalling for the purposes of error tolerance. Heralding is still used to compensate for transmission losses. 3. Third generation quantum networks directly transmit QEC encoded qubits to adjacent nodes, as discussed in Section 4.1.4. Elementary link Bell pairs can now be created without heralding or any other classical signalling. Furthermore, this also enables direct transmission architectures in which qubits are forwarded end-to-end like classical packets rather than relying on Bell pairs and entanglement swapping. Despite the fact that there are important distinctions in how errors will be managed in the different generations it is unlikely that all quantum networks will consistently use the same method. This is due to different hardware requirements of the different generations and the practical reality of network upgrades. Therefore, it is unavoidable that eventually boundaries between different error management schemes start forming. This will affect the content and semantics of messages that must cross those boundaries -- both for connection setup and real-time operation [Nagayama16]. Kozlowski, et al. Expires 1 March 2023 [Page 18] Internet-Draft Principles for a Quantum Internet August 2022 4.4.4. Delivery Eventually, the Bell pairs must be delivered to an application (or higher layer protocol) at the two end-nodes. A detailed list of such requirements is beyond the scope of this draft. At minimum, the end- nodes require information to map a particular Bell pair to the qubit in their local memory that is part of this entangled pair. 5. Architecture of a quantum internet It is evident from the previous sections that the fundamental service provided by a quantum network significantly differs from that of a classical network. Therefore, it is not surprising that the architecture of a quantum internet will itself be very different from that of the classical Internet. 5.1. Challenges This subsection covers the major fundamental challenges building quantum networks. Here, we only describe the fundamental differences. Technological limitations are described later. 1. Bell pairs are not equivalent to payload carrying packets. In most classical networks, including Ethernet, Internet Protocol (IP), and Multi-Protocol Label Switching (MPLS) networks, user data is grouped into packets. In addition to the user data, each packet also contains a series of headers which contain the control information that lets routers and switches forward it towards its destination. Packets are the fundamental unit in a classical network. Kozlowski, et al. Expires 1 March 2023 [Page 19] Internet-Draft Principles for a Quantum Internet August 2022 In a quantum network, the entangled pairs of qubits are the basic unit of networking. These qubits themselves do not carry any headers. Therefore, quantum networks will have to send all control information via separate classical channels which the repeaters will have to correlate with the qubits stored in their memory. Furthermore, a Bell pair consists of two qubits distributed across two nodes which is unlike a classical packet which is located at a single node. This has a fundamental impact on how quantum networks will be managed and how protocols need to be designed. To make long-distance Bell pairs, the nodes may have to keep their qubits in their quantum memories and wait until control information is exchanged before proceeding with the next operation. This signalling will result in additional latency which will depend on the distance between the nodes holding the two ends of the Bell pair. Error management, such as entanglement distillation, is a typical example of such control information exchange [Nagayama21] (see also Section 4.4.3.3). 2. "Store and forward" vs "store and swap" quantum networks. As described in Section 4.4.1, quantum links provide Bell pairs that are undirected network resources, in contrast to directed frames of classical networks. This phenomenological distinction leads to architectural differences between quantum networks and classical networks. Quantum networks combine multiple elementary link Bell pairs together to create one end-to-end Bell pair, whereas classical networks deliver messages from one end to the other end hop by hop. Classical networks receive data on one interface, store it in local buffers, then forward the data to another appropriate interface. Quantum networks store Bell pairs and then execute entanglement swapping instead of forwarding in the data plane. Such quantum networks are "store and swap" networks. In "store and swap" networks, we do not need to care about the order in which the Bell pairs were generated since they are undirected. However, whilst the ordering does not matter, it is very important that the right entangled pairs get swapped, and that the intermediate measurement outcomes (see Section 4.4.2) are signalled to and correlated with the correct qubits at the other nodes. Otherwise, the final end-to-end entangled pair will not be created between the expected end-points or will be in a different quantum state than expected. For example, rather than Alice receiving a qubit that is entangled with Bob's qubit, her qubit is entangled with Charlie's qubit. This distinction makes control algorithms and optimisation of quantum networks different from classical ones, in the sense that swapping is stateful in contrast to stateless packet-by-packet forwarding. Note that Kozlowski, et al. Expires 1 March 2023 [Page 20] Internet-Draft Principles for a Quantum Internet August 2022 third generation quantum networks, as described in Section 4.4.1, will be able to support a "store and forward" architecture in addition to "store and swap". 3. An entangled pair is only useful if the locations of both qubits are known. A classical network packet logically exists only at one location at any point in time. If a packet is modified in some way, whether headers or payload, this information does not need to be conveyed to anybody else in the network. The packet can be simply forwarded as before. In contrast, entanglement is a phenomenon in which two or more qubits exist in a physically distributed state. Operations on one of the qubits change the mutual state of the pair. Since the owner of a particular qubit cannot just read out its state, it must coordinate all its actions with the owner of the pair's other qubit. Therefore, the owner of any qubit that is part of an entangled pair must know the location of its counterpart. Location, in this context, need not be the explicit spatial location. A relevant pair identifier, a means of communication between the pair owners, and an association between the pair ID and the individual qubits is sufficient. 4. Generating entanglement requires temporary state. Packet forwarding in a classical network is largely a stateless operation. When a packet is received, the router does a lookup in its forwarding table and sends the packet out of the appropriate output. There is no need to keep any memory of the packet any more. A quantum node must be able to make decisions about qubits that it receives and is holding in its memory. Since qubits do not carry headers, the receipt of an entangled pair conveys no control information based on which the repeater can make a decision. The relevant control information will arrive separately over a classical channel. This implies that a repeater must store temporary state as the control information and the qubit it pertains to will, in general, not arrive at the same time. 5.2. Classical communication In this draft we have already covered two different roles that classical communication must perform: Kozlowski, et al. Expires 1 March 2023 [Page 21] Internet-Draft Principles for a Quantum Internet August 2022 * communicate classical bits of information as part of distributed protocols such as entanglement swapping and teleportation, * communicate control information within a network, including both background protocols such as routing as well as signalling protocols to set up end-to-end entanglement generation. Classical communication is a crucial building block of any quantum network. All nodes in a quantum network are assumed to have classical connectivity with each other (within typical administrative domain limits). Therefore, quantum nodes will need to manage two data planes in parallel, a classical one and a quantum one. Additionally, a node must be able to correlate information between the two planes so that the control information received on a classical channel can be applied to the qubits managed by the quantum data plane. 5.3. Abstract model of the network 5.3.1. The control and data planes Control plane protocols for quantum networks will have many responsibilities similar to their classical counterparts, namely discovering the network topology, resource management, populating data plane tables, etc. Most of these protocols do not require the manipulation of quantum data and can operate simply by exchanging classical messages only. There may also be some control plane functionality that does require the handling of quantum data, e.g. a quantum ping [I-D.irtf-qirg-quantum-internet-use-cases]. As it is not clear if there is much benefit in defining a separate quantum control plane given the significant overlap in responsibilities with its classical counterpart, the question of whether there should be a separate quantum control plane is beyond the scope of this document. However, the data plane separation is much more distinct and there will be two data planes: a classical data plane and a quantum data plane. The classical data plane processes and forwards classical packets. The quantum data plane processes and swaps entangled pairs. Third generation quantum networks may also forward qubits in addition to swapping Bell pairs. Kozlowski, et al. Expires 1 March 2023 [Page 22] Internet-Draft Principles for a Quantum Internet August 2022 In addition to control plane messages, there will also be control information messages that operate at the granularity of individual entangled pairs, such as heralding messages used for elementary link generation (Section 4.4.1). In terms of functionality, these messages are closer to classical packet headers than control plane messages and thus we consider them to be part of the quantum data plane. Therefore, a quantum data plane also includes the exchange of classical control information at the granularity of individual qubits and entangled pairs. 5.3.2. Elements of a quantum network We have identified quantum repeaters as the core building block of a quantum network. However, a quantum repeater will have to do more than just entanglement swapping in a functional quantum network. Its key responsibilities will include: 1. Creating link-local entanglement between neighbouring nodes. 2. Extending entanglement from link-local pairs to long-range pairs through entanglement swapping. 3. Performing distillation to manage the fidelity of the produced pairs. 4. Participating in the management of the network (routing, etc.). Not all quantum repeaters in the network will be the same; here we break them down further: * Quantum routers (controllable quantum nodes) - A quantum router is a quantum repeater with a control plane that participates in the management of the network and will make decisions about which qubits to swap to generate the requested end-to-end pairs. * Automated quantum nodes - An automated quantum node is a data plane only quantum repeater that does not participate in the network control plane. Since the no-cloning theorem precludes the use of amplification, long-range links will be established by chaining multiple such automated nodes together. * End-nodes - End-nodes in a quantum network must be able to receive and handle an entangled pair, but they do not need to be able to perform an entanglement swap (and thus are not necessarily quantum repeaters). End-nodes are also not required to have any quantum memory as certain quantum applications can be realised by having the end-node measure its qubit as soon as it is received. Kozlowski, et al. Expires 1 March 2023 [Page 23] Internet-Draft Principles for a Quantum Internet August 2022 * Non-quantum nodes - Not all nodes in a quantum network need to have a quantum data plane. A non-quantum node is any device that can handle classical network traffic. Additionally, we need to identify two kinds of links that will be used in a quantum network: * Quantum links - A quantum link is a link which can be used to generate an entangled pair between two directly connected quantum repeaters. This may include additional mid-point elements described in Section 4.4.1. It may also include a dedicated classical channel that is to be used solely for the purpose of coordinating the entanglement generation on this quantum link. * Classical links - A classical link is a link between any node in the network that is capable of carrying classical network traffic. Note that passive elements, such as optical switches, do not destroy the quantum state. Therefore, it is possible to connect multiple quantum nodes with each other over an optical network and perform optical switching rather than routing via entanglement swapping at quantum routers. This does require coordination with the elementary link entanglement generation process and it still requires repeaters to overcome the short-distance limitations. However, this is a potentially feasible architecture for local area networks. 5.3.3. Putting it all together A two-hop path in a generic quantum network can be represented as: +-----+ +-----+ | App |- - - - - - - - - -CC- - - - - - - - - -| App | +-----+ +------+ +-----+ | EN |------ CL ------| QR |------ CL ------| EN | | |------ QL ------| |------ QL ------| | +-----+ +------+ +-----+ App - user-level application EN - end-node QL - quantum link CL - classical link CC - classical channel (traverses one or more CLs) QR - quantum repeater An application (App) running on two end-nodes (ENs) attached to a network will at some point need the network to generate entangled pairs for its use. This may require negotiation between the end- nodes (possibly ahead of time), because they must both open a Kozlowski, et al. Expires 1 March 2023 [Page 24] Internet-Draft Principles for a Quantum Internet August 2022 communication end-point which the network can use to identify the two ends of the connection. The two end-nodes use a classical channel (CC) available in the network to achieve this goal. When the network receives a request to generate end-to-end entangled pairs it uses the classical communication links (CLs) to coordinate and claim the resources necessary to fulfill this request. This may be some combination of prior control information (e.g. routing tables) and signalling protocols, but the details of how this is achieved are an active research question. A thought experiment on what this might look like be can be found later in this draft in Section 7. During or after the distribution of control information, the network performs the necessary quantum operations such as generating entanglement over individual quantum links (QLs), performing entanglement swaps at quantum repeaters (QRs), and further signalling to transmit the swap outcomes and other control information. Since Bell pairs do not carry any user data, some of these operations can be performed before the request is received in anticipation of the demand. Note that here, "signalling" is used in a very broad sense and covers many different types of messaging necessary for entanglement generation control. For example, heralded entanglement generation requires very precise timing synchronisation between the neighbouring nodes and thus the triggering of entanglement generation and heralding may happen over its own, perhaps physically separate CL, as was the case in network stack demonstration in [Pompili21.2]. Higher level signalling with less stringent timing requirements (e.g. control plane signalling) may then happen over its own CL. The entangled pair is delivered to the application once it is ready, together with the relevant pair identifier. However, being ready does not necessarily mean that all link pairs and entanglement swaps are complete, as some applications can start executing on an incomplete pair. In this case the remaining entanglement swaps will propagate the actions across the network to the other end, sometimes necessitating fixup operations at the end node. 5.4. Physical constraints The model above has effectively abstracted away the particulars of the hardware implementation. However, certain physical constraints need to be considered in order to build a practical network. Some of these are fundamental constraints and no matter how much the technology improves, they will always need to be addressed. Others are artifacts of the early stages of a new technology. Here, we Kozlowski, et al. Expires 1 March 2023 [Page 25] Internet-Draft Principles for a Quantum Internet August 2022 consider a highly abstract scenario and refer to [Wehner18] for pointers to the physics literature. 5.4.1. Memory lifetimes In addition to discrete operations being imperfect, storing a qubit in memory is also highly non-trivial. The main difficulty in achieving persistent storage is that it is extremely challenging to isolate a quantum system from the environment. The environment introduces an uncontrollable source of noise into the system which affects the fidelity of the state. This process is known as decoherence. Eventually, the state has to be discarded once its fidelity degrades too much. The memory lifetime depends on the particular physical setup, but the highest achievable values in quantum network hardware currently are on the order of seconds [Abobeih18] although a lifetime of a minute has also been demonstrated for qubits not connected to a quantum network [Bradley19] (as of 2020). These values have increased tremendously over the lifetime of the different technologies and are bound to keep increasing. However, if quantum networks are to be realised in the near future, they need to be able to handle short memory lifetimes, for example by reducing latency on critical paths. 5.4.2. Rates Entanglement generation on a link between two connected nodes is not a very efficient process and it requires many attempts to succeed [Hensen15] [Dahlberg19]. For example, the highest achievable rates of success between nitrogen-vacancy center nodes, which in addition to entanglement generation are also capable of storing and processing the resulting qubits, are on the order of 10 Hz. Combined with short memory lifetimes this leads to very tight timing windows to build up network-wide connectivity. Other platforms have shown higher entanglement rates, but this usually comes at the cost of other hardware capabilities, such as no quantum memory and/or limited processing capabilities [Wei22]. Nevertheless, the current rates are not sufficient for practical applications beyond simple experimental proofs of concept. However, they are expected to improve over time as quantum network technology evolves [Wei22]. Kozlowski, et al. Expires 1 March 2023 [Page 26] Internet-Draft Principles for a Quantum Internet August 2022 5.4.3. Communication qubits Most physical architectures capable of storing qubits are only able to generate entanglement using only a subset of available qubits called communication qubits [Dahlberg19]. Once a Bell pair has been generated using a communication qubit, its state can be transferred into memory. This may impose additional limitations on the network. In particular, if a given node has only one communication qubit it cannot simultaneously generate Bell pairs over two links. It must generate entanglement over the links one at a time. 5.4.4. Homogeneity Currently all existing quantum network implementations are homogeneous and they do not interface with each other. In general, it is very challenging to combine different quantum information processing technologies. There are many different physical hardware platforms for implementing quantum networking hardware. The different technologies differ in how they store and manipulate qubits in memory and how they generate entanglement across a link with their neighbours. For example, hardware based on optical elements and atomic ensembles [Sangouard11] is very efficient at generating entanglement at high rates, but provides limited processing capabilities once the entanglement is generated. On the other hand, nitrogen-vacancy based [Hensen15] or trapped ion [Moehring07] platforms offer a much greater degree of control over the qubits, but have a harder time generating entanglement at high rates. In order to overcome the weaknesses of the different platforms, coupling the different technologies will help to build fully functional networks. For example, end-nodes may be implemented using technology with good qubit processing capabilities to enable complex applications, but automated quantum nodes that that serve only to "repeat" along a linear chain, where the processing logic is much simpler, can be implemented with technologies that sacrifice processing capabilities for higher entanglement rates at long distances [Askarani21]. Kozlowski, et al. Expires 1 March 2023 [Page 27] Internet-Draft Principles for a Quantum Internet August 2022 This point is further exacerbated by the fact that quantum computers (i.e. end-nodes in a quantum network) are often based on different hardware platforms than quantum repeaters thus requiring a coupling (transduction) between the two. This is especially true for quantum computers based on superconducting technology which are challenging to connect to optical networks. However, even trapped ion quantum computers, which is a platform that has shown promise for quantum networking, will still need to connect to other platforms that are better at creating entanglement at high rates over long distances (hundreds of kms). 6. Architectural principles Given that the most practical way of realising quantum network connectivity is using Bell pair and entanglement swapping repeater technology, what sort of principles should guide us in assembling such networks such that they are functional, robust, efficient, and most importantly, do they work? Furthermore, how do we design networks so that they work under the constraints imposed by the hardware available today, but do not impose unnecessary burdens on future technology? As quantum networking is a completely new technology that is likely to see many iterations over its lifetime, this draft must not serve as a definitive set of rules, but merely as a general set of recommended guidelines for the first generations of quantum networks based on principles and observations made by the community. The benefit of having a community built document at this early stage is that expertise in both quantum information and network architecture is needed in order to successfully build a quantum internet. 6.1. Goals of a quantum internet When outlining any set of principles we must ask ourselves what goals do we want to achieve as inevitably trade-offs must be made. So what sort of goals should drive a quantum network architecture? The following list has been inspired by the history of computer networking and thus it is inevitably very similar to one that could be produced for the classical Internet [Clark88]. However, whilst the goals may be similar the challenges involved are often fundamentally different. The list will also most likely evolve with time and the needs of its users. 1. Support distributed quantum applications This goal seems trivially obvious, but makes a subtle, but important point which highlights a key difference between quantum and classical networks. Ultimately, quantum data transmission is Kozlowski, et al. Expires 1 March 2023 [Page 28] Internet-Draft Principles for a Quantum Internet August 2022 not the goal of a quantum network - it is only one possible component of more advanced quantum application protocols [Wehner18]. Whilst transmission certainly could be used as a building block for all quantum applications, it is not the most basic one possible. For example, entanglement-based QKD, the most well known quantum application protocol, only relies on the stronger-than-classical correlations and inherent secrecy of entangled Bell pairs and does not have to transmit arbitrary quantum states [Ekert91]. The primary purpose of a quantum internet is to support distributed quantum application protocols and it is of utmost importance that they can run well and efficiently. Thus, it is important to develop performance metrics meaningful to application to drive the development of quantum network protocols. For example, the Bell pair generation rate is meaningless if one does not also consider their fidelity. It is generally much easier to generate pairs of lower fidelity, but quantum applications may have to make multiple re-attempts or even abort if the fidelity is too low. A review of the requirements for different known quantum applications can be found in [Wehner18] and an overview of use-cases can be found in [I-D.irtf-qirg-quantum-internet-use-cases]. 2. Support tomorrow's distributed quantum applications The only principle of the Internet that should survive indefinitely is the principle of constant change [RFC1958]. Technical change is continuous and the size and capabilities of the quantum internet will change by orders of magnitude. Therefore, it is an explicit goal that a quantum internet architecture be able to embrace this change. We have the benefit of having been witness to the evolution of the classical Internet over several decades and seen what worked and what did not. It is vital for a quantum internet to avoid the need for flag days (e.g. NCP to TCP/IP) or upgrades that take decades to roll out (e.g. IPv4 to IPv6). Therefore, it is important that any proposed architecture for general purpose quantum repeater networks can integrate new devices and solutions as they become available. The architecture should not be constrained due to considerations for early-stage hardware and applications. For example, it is already possible to run QKD efficiently on metropolitan scales and such networks are already commercially available. However, they are not based on quantum repeaters and thus will not be able to easily transition to more sophisticated applications. Kozlowski, et al. Expires 1 March 2023 [Page 29] Internet-Draft Principles for a Quantum Internet August 2022 3. Support heterogeneity There are multiple proposals for realising practical quantum repeater hardware and they all have their advantages and disadvantages. Some may offer higher Bell pair generation rates on individual links at the cost of more difficult entanglement swap operations. Other platforms may be good all around, but are more difficult to build. In addition to physical boundaries, there may be distinctions in how errors are managed (Section 4.4.3.3). These difference will affect the content and semantics of messages that cross these boundaries -- both for connection setup and real-time operation. The optimal network configuration will likely leverage the advantages of multiple platforms to optimise the provided service. Therefore, it is an explicit goal to incorporate varied hardware and technology support from the beginning. 4. Ensure security at the network level The question of security in quantum networks is just as critical as it is in the classical Internet, especially since enhanced security offered by quantum entanglement is one of the key driving factors. Fortunately, from an application's point of view, as long as the underlying implementation corresponds to (or sufficiently approximates) theoretical models of quantum cryptography, quantum cryptographic protocols do not need the network to provide any guarantees about the confidentiality or integrity of the transmitted qubits or the generated entanglement (though they may impose requirements on the classical channel, e.g to be authenticated [Wang21]). Instead, applications will leverage the classical networks to establish the end-to-end security of the results obtained from the processing of entangled qubits. However, it is important to note that whilst classical networks are necessary to establish these end-to-end guarantees, the security relies on the properties of quantum entanglement. For example, QKD uses classical information reconciliation [Tang19] for error correction and privacy amplification [Elkouss11] for generating the final secure key, but the raw bits that are fed into these protocols must come from measuring entangled qubits [Ekert91]. In another application, secure delegated quantum computing, the client hides its computation from the server by sending qubits to the server and then requesting it (in a classical message) to measure them in an encoded basis. The client then decodes the results it receives from the server to Kozlowski, et al. Expires 1 March 2023 [Page 30] Internet-Draft Principles for a Quantum Internet August 2022 obtain the result of the computation [Broadbent10]. Once again, whilst a classical network is used to achieve the goal of secure computation, the remote computation is strictly quantum. Nevertheless, whilst applications can ensure their own end-to-end security, network protocols themselves should be security aware in order to protect the network itself and limit disruption. Whilst the applications remain secure they are not necessarily operational or as efficient in the presence of an attacker. For example, if an attacker can measure every qubit between two parties trying to establish a key using QKD, no secret key can be generated. Security concerns in quantum networks are described in more detail in [Satoh17] [Satoh20]. 5. Make them easy to monitor In order to manage, evaluate the performance of, or debug a network it is necessary to have the ability to monitor the network while ensuring there will be mechanisms in place to protect the confidentiality and integrity of the devices connected to it. Quantum networks bring new challenges in this area so it should be a goal of a quantum network architecture to make this task easy. The fundamental unit of quantum information, the qubit, cannot be actively monitored as any readout irreversibly destroys its contents. One of the implications of this fact is that measuring an individual pair's fidelity is impossible. Fidelity is meaningful only as a statistical quantity which requires the constant monitoring and the sacrifice of generated Bell pairs for tomography or other methods. Furthermore, given one end of an entangled pair, it is impossible to tell where the other qubit is without any additional classical metadata. It is impossible to extract this information from the qubits themselves. This implies that tracking entangled pairs necessitates some exchange of classical information. This information might include (i) a reference to the entangled pair that allows distributed applications to coordinate actions on qubits of the same pair, and (ii) the two bits from each entanglement swap necessary to identify the final state of the Bell pair (Section 4.4.2). 6. Ensure availability and resilience Any practical and usable network, classical or quantum, must be able to continue to operate despite losses and failures, and be robust to malicious actors trying to disable connectivity. What Kozlowski, et al. Expires 1 March 2023 [Page 31] Internet-Draft Principles for a Quantum Internet August 2022 differs in quantum networks as compared to classical networks in this regard is that we now have two data planes and two types of channels to worry about: a quantum and a classical one. Therefore, availability and resilience will most likely require a more advanced treatment than they do in classical networks. Note that privacy, whilst related to security, is not listed as an explicit goal, because the privacy benefits will depend on the use case. For example, QKD only provides increased security for the distribution of symmetric keys [Bennett14] [Ekert91]. The handling, manipulation, sharing, encryption, and decryption of data will remain entirely classical limiting the benefits to privacy that can be gained from using a quantum network. On the other hand, there are applications like blind quantum computation which provides the user with the ability to execute a quantum computation on a remote server without the server knowing what the computation was or its input and output [Fitzsimons17]. Therefore, privacy must be considered on a per-application basis. An overview of quantum network use cases can be found in [I-D.irtf-qirg-quantum-internet-use-cases]. 6.2. The principles of a quantum internet The principles support the goals, but are not goals themselves. The goals define what we want to build and the principles provide a guideline in how we might achieve this. The goals will also be the foundation for defining any metric of success for a network architecture, whereas the principles in themselves do not distinguish between success and failure. For more information about design considerations for quantum networks see [VanMeter13.1] [Dahlberg19]. 1. Entanglement is the fundamental service The key service that a quantum network provides is the distribution of entanglement between the nodes in a network. All distributed quantum applications are built on top of this key resource. Applications such as clustered quantum computing, distributed quantum computing, distributed quantum sensing networks, and certain kinds of quantum secure networks all consume quantum entanglement as a resource. Some applications (e.g. quantum key distribution) simply measure the entangled qubits to obtain a shared secret key [QKD]. Other applications (e.g. distributed quantum computing) build more complex abstractions and operations on the entangled qubits, e.g., distributed CNOT gates [DistCNOT] or teleportation of arbitrary qubit states [Teleportation]. Kozlowski, et al. Expires 1 March 2023 [Page 32] Internet-Draft Principles for a Quantum Internet August 2022 A quantum network may also distribute multipartite entangled states (entangled states of three or more qubits) [Meignant19] which are useful for applications such as conference key agreement [Murta20], distributed quantum computing [Cirac99], secret sharing [Qin17], and clock synchronisation [Komar14]. Though it was worth noting that multipartite entangled states can also be constructed from multiple entangled pairs distributed between the end-nodes. 2. Bell Pairs are indistinguishable Any two Bell Pairs between the same two nodes are indistinguishable for the purposes of an application provided they both satisfy its required fidelity threshold. This observation is likely to be key in enabling a more optimal allocation of resources in a network, e.g. for the purposes of provisioning resources to meet application demand. However, the qubits that make up the pair themselves are not indistinguishable and the two nodes operating on a pair must coordinate to make sure they are operating on qubits that belong to the same Bell pair. 3. Fidelity is part of the service In addition to being able to deliver Bell pairs to the communication end-points, the Bell Pairs must be of sufficient fidelity. Unlike in classical networks where most errors are effectively eliminated before reaching the application, many quantum applications only need imperfect entanglement to function. However, quantum applications will generally have a threshold for Bell pair fidelity below which they are no longer able to operate. Different applications will have different requirements for what fidelity they can work with. It is the network's responsibility to balance the resource usage with respect to the applications' requirements. It may be that it is cheaper for the network to provide lower fidelity pairs that are just above the threshold required by the application than it is to guarantee high fidelity pairs to all applications regardless of their requirements. 4. Time is an expensive resource Time is not the only resource that is in short supply (memory, and communication qubits are as well), but ultimately it is the lifetime of quantum memories that imposes some of the most difficult conditions for operating an extended network of quantum nodes. Current hardware has low rates of Bell pair generation, short memory lifetimes, and access to a limited number of Kozlowski, et al. Expires 1 March 2023 [Page 33] Internet-Draft Principles for a Quantum Internet August 2022 communication qubits. All these factors combined mean that even a short waiting queue at some node could be enough for a Bell pair to decohere or result in an end-to-end pair below an application's fidelity threshold. Therefore, managing the idle time of qubits holding live quantum states should be done carefully. Ideally by minimising the idle time, but potentially also by moving the quantum state for temporary storage to a quantum memory with a longer lifetime. 5. Be flexible with regards to capabilities and limitations This goal encompasses two important points. First, the architecture should be able to function under the physical constraints imposed by the current generation hardware. Near- future hardware will have low entanglement generation rates, quantum memories able to hold a handful of qubits at best, and decoherence rates that will render many generated pairs unusable. Second, the architecture should not make it difficult to run the network over any hardware that may come along in the future. The physical capabilities of repeaters will improve and redeploying a technology is extremely challenging. 7. A thought experiment inspired by classical networks To conclude, we discuss a plausible quantum network architecture inspired by MPLS. This is not an architecture proposal, but rather a thought experiment to give the reader an idea of what components are necessary for a functional quantum network. We use classical MPLS as a basis as it is well known and understood in the networking community. Creating end-to-end Bell pairs between remote end-points is a stateful distributed task that requires a lot of a-priori coordination. Therefore, a connection-oriented approach seems the most natural for quantum networks. In connection-oriented quantum networks, when two quantum application end-points wish to start creating end-to-end Bell pairs, they must first create a quantum virtual circuit (QVC). As an analogy, in MPLS networks end-points must establish a label switched path (LSP) before exchanging traffic. Connection-oriented quantum networks may also support virtual circuits with multiple end-points for creating multipartite entanglement. As an analogy, MPLS networks have the concept of multi-point LSPs for multicast. When a quantum application creates a quantum virtual circuit, it can indicate quality of service (QoS) parameters such as the required capacity in end-to-end Bell pairs per second (BPPS) and the required Kozlowski, et al. Expires 1 March 2023 [Page 34] Internet-Draft Principles for a Quantum Internet August 2022 fidelity of the Bell pairs. As an analogy, in MPLS networks applications specify the required bandwidth in bits per second (BPS) and other constraints when they create a new LSP. Different applications will have different QoS requirements. For example, applications such as QKD, that don't need to process the entangled qubits and only need measure them and store the resulting outcome, may require a large volume of entanglement, but will be tolerant of delay and jitter for individual pairs. On the other hand, distributed/cloud quantum computing applications may need fewer entangled pairs, but instead, may need all of them to be generated in one go so that they can be processed all together before any of them decohere. Quantum networks need a routing function to compute the optimal path (i.e. the best sequence of routers and links) for each new quantum virtual circuit. The routing function may be centralized or distributed. In the latter case, the quantum network needs a distributed routing protocol. As an analogy, classical networks use routing protocols such as open shortest path first (OSPF) and intermediate-system to intermediate system (IS-IS). However, note that the definition of "shortest-path"/"least-cost" may be different in a quantum network to account for its non-classical features, such as fidelity [VanMeter13.2]. Given the very scarce availability of resources in early quantum networks, a traffic engineering function is likely to be beneficial. Without traffic engineering, quantum virtual circuits always use the shortest path. In this case, the quantum network cannot guarantee that each quantum end-point will get its Bell pairs at the required rate or fidelity. This is analogous to "best effort" service in classical networks. With traffic engineering, quantum virtual circuits choose a path that is guaranteed to have the requested resources (e.g. bandwidth in BPPS) available, taking into account the capacity of the routers and links and taking into account the resources already consumed by other virtual circuits. As an analogy, both OSPF and IS-IS have traffic engineering (TE) extensions to keep track of used and available resources, and can use constrained shortest path first (CSPF) to take resource availability and other constraints into account when computing the optimal path. The use of traffic engineering implies the use of call admission control (CAC): the network denies any virtual circuits for which it cannot guarantee the requested quality of service a-priori. Or alternatively, the network pre-empts lower priority circuits to make room for the new one. Kozlowski, et al. Expires 1 March 2023 [Page 35] Internet-Draft Principles for a Quantum Internet August 2022 Quantum networks need a signaling function: once the path for a quantum virtual circuit has been computed, signaling is used to install the "forwarding rules" into the data plane of each quantum router on the path. The signaling may be distributed, analogous to the resource reservation protocol (RSVP) in MPLS. Or the signaling may be centralized, similar to OpenFlow. Quantum networks need an abstraction of the hardware for specifying the forwarding rules. This allows us to de-couple the control plane (routing and signaling) from the data plane (actual creation of Bell pairs). The forwarding rules are specified using abstract building blocks such as "creating local Bell pairs", "swapping Bell pairs", "distillation of Bell pairs". As an analogy, classical networks use abstractions that are based on match conditions (e.g. looking up header fields in tables) and actions (e.g. modifying fields or forwarding a packet to a specific interface). The data-plane abstractions in quantum networks will be very different from those in classical networks due to the fundamental differences in technology and the stateful nature of quantum networks. In fact, choosing the right abstractions will be one of the biggest challenges when designing interoperable quantum network protocols. In quantum networks, control plane traffic (routing and signaling messages) is exchanged over a classical channel, whereas data plane traffic (the actual Bell pair qubits) is exchanged over a separate quantum channel. This is in contrast to most classical networks, where control plane traffic and data plane traffic share the same channel and where a single packet contains both user fields and header fields. There is, however, a classical analogy to the way quantum networks work. Generalized MPLS (GMPLS) networks use separate channels for control plane traffic and data plane traffic. Furthermore, GMPLS networks support data planes where there is no such thing as data plane headers (e.g. DWDM or TDM networks). 8. Security Considerations Security is listed as an explicit goal for the architecture and this issue is addressed in the section on goals. However, as this is an informational draft it does not propose any concrete mechanisms to achieve these goals. 9. IANA Considerations This draft includes no request to IANA. Kozlowski, et al. Expires 1 March 2023 [Page 36] Internet-Draft Principles for a Quantum Internet August 2022 10. Acknowledgements The authors want to thank Carlo Delle Donne, Matthew Skrzypczyk, Axel Dahlberg, Mathias van den Bossche, Patrick Gelard, Chonggang Wang, Scott Fluhrer, Joey Salazar, Joseph Touch, and the rest of the QIRG community as a whole for their very useful reviews and comments to the document. 11. Informative References [Abobeih18] Abobeih, M.H., Cramer, J., Bakker, M.A., Kalb, N., Markham, M., Twitchen, D.J., and T.H. Taminiau, "One- second coherence for a single electron spin coupled to a multi-qubit nuclear-spin environment", Nature communications Vol. 9, Iss. 1, pp. 1-8, 2018, . [Aguado19] Aguado, A., Lopez, V., Diego, D., Peev, M., Poppe, A., Pastor, A., Folgueira, J., and M. Vicente, "The engineering of software-defined quantum key distribution networks", IEEE Communications Magazine Vol. 57, Iss. 7, pp. 20-26, 2019, . [Askarani21] Askarani, M.F., Chakraborty, K., and G.C. do Amaral, "Entanglement Distribution in Multi-Platform Buffered- Router-Assisted Frequency-Multiplexed Automated Repeater Chains", arXiv 2106.04671, 2021, . [Aspect81] Aspect, A., Grangier, P., and G. Roger, "Experimental tests of realistic local theories via Bell's theorem", Physical Review Letters Vol. 47, Iss. 7, pp. 460-463, 1981, . [Bennett14] Bennett, C.H. and G. Brassard, "Quantum cryptography: Public key distribution and coin tossing", Theoretical Computer Science Vol. 560 (Part 1), pp. 7-11, 2014, . [Bennett93] Bennett, C.H., Brassard, G., Crepeau, C., Jozsa, R., Peres, A., and W.K. Wootters, "Teleporting an unknown quantum state via dual classical and Einstein-Podolsky- Rosen channels", Physical Review Letters Vol. 70, Iss. 13, Kozlowski, et al. Expires 1 March 2023 [Page 37] Internet-Draft Principles for a Quantum Internet August 2022 pp. 1895-1899, 1993, . [Bennett96] Bennett, C.H., DiVincenzo, D.P., Smolin, J.A., and W.K. Wootters, "Mixed state entanglement and quantum error correction", Physical Review A Vol. 54, Iss. 5, pp. 3824-3851, 1996, . [Bradley19] Bradley, C.E., Randall, J., Abobeih, M.H., Berrevoets, R.C., Degen, M.J., Bakker, M.A., Markham, M., Twitchen, D.J., and T.H. Taminiau, "A 10-qubit solid-state spin register with quantum memory up to one minute", Physical Review X Vol. 9, Iss. 3, pp. 031045, 2019, . [Briegel98] Briegel, H.-J., Dur, W., Cirac, J.I., and P. Zoller, "Quantum repeaters: The role of imperfect local operations in quantum communication", Physical Review Letters Vol. 81, Iss. 26, pp. 5932-5935, 1998, . [Broadbent10] Broadbent, A., Fitzsimons, J., and E. Kashefi, "Measurement-Based and Universal Blind Quantum Computation", Springer-Verlag 978-3-642-13678-8, 2010, . [Cacciapuoti19] Cacciapuoti, A.S., Caleffi, M., Van Meter, R., and L. Hanzo, "When Entanglement meets Classical Communications: Quantum Teleportation for the Quantum Internet", IEEE Transactions on Communications Vol. 68, Iss. 6, pp. 3808-3833, 2019, . [Cirac99] Cirac, J.I., Ekert, A.K., Huelga, S.F., and C. Macchiavello, "Distributed quantum computation over noisy channels", Physical Review A Vol. 59, Iss. 6, pp. 4249, . [Clark88] Clark, D., "The design philosophy of the DARPA internet protocols", Symposium proceedings on Communications architectures and protocols pp. 106-114, 1988, . Kozlowski, et al. Expires 1 March 2023 [Page 38] Internet-Draft Principles for a Quantum Internet August 2022 [Crepeau02] Crepeau, C., Gottesman, D., and A. Smith, "Secure multi- party quantum computation", Proceedings of the thiry- fourth annual ACM symposium on Theory of computing pp. 643-652, 2002, . [Dahlberg19] Dahlberg, A., Skrzypczyk, M., Coopmans, T., Wubben, L., Rozpedek, F., Pompili, M., Stolk, A., Pawelczak, P., Knegjens, R., de Oliveira Filho, J., Hanson, R., and S. Wehner, "A link layer protocol for quantum networks", Proceedings of the ACM Special Interest Group on Data Communication pp. 159-173, 2019, . [Devitt13] Devitt, S.J., Nemoto, K., and W.J. Munro, "Quantum error correction for beginners", Reports on Progress in Physics Vol. 76, Iss. 7, pp. 076001, 2013, . [DistCNOT] Quantum Network Explorer by QuTech, "Distributed CNOT", 2021, . [Dur07] Duer, W. and H.J. Briegel, "Entanglement purification and quantum error correction", Reports on Progress in Physics Vol. 70, Iss. 8, pp. 1381-1424, 2007, . [Ekert91] Ekert, A.K., "Quantum cryptography based on Bell's theorem", Physical Review Letters Vol. 67, Iss. 6, pp. 661-663, 1991, . [Elkouss11] Elkouss, D., Martinez-Mateo, J., and V. Martin, "Information Reconciliation for Quantum Key Distribution", Quantum Information and Computation Vol. 11, No. 3 and 4, pp. 0226-0238, 2011, . [Elliott03] Elliott, C., Pearson, D., and G. Troxel, "Quantum cryptography in practice", Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications pp. 227-238, 2003, . Kozlowski, et al. Expires 1 March 2023 [Page 39] Internet-Draft Principles for a Quantum Internet August 2022 [Fitzsimons17] Fitzsimons, J.F. and E. Kashefi, "Unconditionally verifiable blind quantum computation", Physical Review A Vol. 96, Iss. 1, pp. 012303, 2017, . [Fowler10] Fowler, A.G., Wang, D.S., Hill, C.D., Ladd, T.D., Van Meter, R., and L.C.L. Hollenberg, "Surface code quantum communication", Physical Review Letters Vol. 104, Iss. 18, pp. 180503, 2010, . [Giovanetti04] Giovanetti, V., Lloyd, S., and L. Maccone, "Quantum- enhanced measurements: beating the standard quantum limit", Science Vol. 306, Iss. 5700, pp. 1330-1336, 2004, . [Gottesman12] Gottesman, D., Jennewein, T., and S. Croke, "Longer- baseline telescopes using quantum repeaters", Physical Review Letters Vol. 109, Iss. 7, pp. 070503, 2012, . [Hensen15] Hensen, B., Bernien, H., Dreau, A.E., Reiserer, A., Kalb, N., Blok, M.S., Ruitenberg, J., Vermeulen, R.F.L., Schouten, R.N., Abellan, C., Amaya, W., Pruneri, V., Mitchell, M.W., Markham, M., Twitchen, D.J., Elkouss, D., Wehner, S., Taminiau, T.H., and R. Hanson, "Loophole-free Bell inequality violation using electron spins separated by 1.3 kilometres", Nature Vol. 526, Iss. 7575, pp. 682-686, 2015, . [I-D.irtf-qirg-quantum-internet-use-cases] Wang, C., Rahman, A., Li, R., Aelmans, M., and K. Chakraborty, "Application Scenarios for the Quantum Internet", Work in Progress, Internet-Draft, draft-irtf- qirg-quantum-internet-use-cases-13, 10 June 2022, . [Jiang09] Jiang, L., Taylor, J.M., Nemoto, K., Munro, W.J., Van Meter, R., and M.D. Lukin, "Quantum repeater with encoding", Physical Review A Vol. 79, Iss. 3, pp. 032325, 2009, . [Joshi20] Joshi, S.K., Aktas, D., Wengerowsky, S., Loncaric, M., Neumann, S.P., Liu, B., Scheidl, T., Lorenzo, G.C., Samec, Z., Kling, L., Qiu, A., Razavi, M., Stipcevic, M., Rarity, Kozlowski, et al. Expires 1 March 2023 [Page 40] Internet-Draft Principles for a Quantum Internet August 2022 J.G., and R. Ursin, "A trusted-node-free eight-user metropolitan quantum communication network", Science Advances Vol. 6, no.36, pp. eaba0959, 2020, . [Kimble08] Kimble, H.J., "The Quantum Internet", Nature Vol. 453, Iss. 7198, pp. 1023-1030, 2008, . [Komar14] Komar, P., Kessler, E.M., Bishof, M., Jiang, L., Sorensen, A.S., Ye, J., and M.D. Lukin, "A quantum network of clocks", Nature Physics Vol. 10, Iss. 8, pp. 582-587, 2014, . [Meignant19] Meignant, C., Markham, D., and F. Grosshans, "Distributing graph states over arbitrary quantum networks", Physical Review A Vol. 100, Iss. 5, pp. 052333, 2019, . [Moehring07] Moehring, D.L., Maunz, P., Olmschenk, S., Younge, K.C., Matsukevich, D.N., Duan, L.M., and C. Monroe, "Entanglement of single-atom quantum bits at a distance", Nature Iss. 449, pp. 68-71, 2007, . [Mural16] Muralidharan, S., Li, L., Kim, J., Lutkenhaus, N., Lukin, M., and L. Jiang, "Optimal architectures for long distance quantum communication", Scientific Reports Vol. 6, Iss. 1, pp. 1-10, 2016, . [Murta20] Murta, G., Grasselli, F., Kampermann, H., and D. Bruss, "Quantum conference key agreement: A review", Advanced Quantum Technologies Vol. 3, Iss. 11, pp. 2000025, 2020, . [Nagayama16] Nagayama, S., Choi, B.-S., Devitt, S., Suzuki, S., and R. Van Meter, "Interoperability in encoded quantum repeater networks", Physical Review A Vol. 93, Iss. 4, pp. 042338, 2016, . [Nagayama21] Nagayama, S., "Towards End-to-End Error Management for a Quantum Internet", arXiv 2112.07185, 2021, . Kozlowski, et al. Expires 1 March 2023 [Page 41] Internet-Draft Principles for a Quantum Internet August 2022 [NielsenChuang] Nielsen, M.A. and I.L. Chuang, "Quantum Computation and Quantum Information", Cambridge University Press , 2011. [Park70] Park, J.L., "The concept of transition in quantum mechanics", Foundations of Physics Vol. 1, Iss. 1, pp. 23-33, 1970, . [Peev09] Peev, M., Pacher, C., Alleaume, R., Barreiro, C., Bouda, J., Boxleitner, W., Debuisschert, T., Diamanti, E., Dianati, M., Dynes, J.F., Fasel, S., Fossier, S., Fuerst, M., Gautier, J.-D., Gay, O., Gisin, N., Grangier, P., Happe, A., Hasani, Y., Hentschel, M., Huebel, H., Humer, G., Laenger, T., Legre, M., Lieger, R., Lodewyck, J., Loruenser, T., Luetkenhaus, N., Marhold, A., Matyus, T., Maurhart, O., Monat, L., Nauerth, S., Page, J.-B., Poppe, A., Querasser, E., Ribordy, G., Robyr, S., Salvail, L., Sharpe, A.W., Shields, A.J., Stucki, D., Suda, M., Tamas, C., Themel, T., Thew, R.T., Thoma, Y., Treiber, A., Trinkler, P., Tualle-Brouri, R., Vannel, F., Walenta, N., Weier, H., Weinfurter, H., Wimberger, I., Yuan, Z.L., Zbinden, H., and A. Zeilinger, "The SECOQC quantum key distribution network in Vienna", New Journal of Physics Vol. 11, Iss. 7, pp. 075001, 2009, . [Pompili21.1] Pompili, M., Hermans, S.L.N., Baier, S., Beukers, H.K.C., Humphreys, P.C., Schouten, R.N., Vermeulen, R.F.L., Tiggelman, M.J., dos Santos Martins, L., Dirkse, B., Wehner, S., and R. Hanson, "Realization of a multi-node quantum network of remote solid-state qubits", Science Vol. 372, Iss. 6539, pp. 259-264, 2021, . [Pompili21.2] Pompili, M., Delle Donne, C., te Raa, I., van der Vecht, B., Skrzypczyk, M., Ferreira, G., de Kluijver, L., Stolk, A.J., Hermans, S.L.N., Pawelczak, P., Kozlowski, W., Hanson, R., and S. Wehner, "Experimental demonstration of entanglement delivery using a quantum network stack", arXiv 2111.11332, 2021, . Kozlowski, et al. Expires 1 March 2023 [Page 42] Internet-Draft Principles for a Quantum Internet August 2022 [Qin17] Qin, H. and Y. Dai, "Dynamic quantum secret sharing by using d-dimensional GHZ state", Quantum information processing Vol. 16, Iss. 3, pp. 64, 2017, . [QKD] Quantum Network Explorer by QuTech, "Quantum Key Distribution", 2021, . [RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, . [Sangouard11] Sangouard, N., Simon, C., de Riedmatten, H., and N. Gisin, "Quantum repeaters based on atomic ensembles and linear optics", Reviews of Modern Physics Vol. 83, Iss. 1, pp. 33-80, 2011, . [Satoh17] Satoh, T., Nagayama, S., and R. Van Meter, "The network impact of hijacking a quantum repeater", Quantum Science and Technology Vol. 3, Iss. 3, pp. 034008, 2017, . [Satoh20] Satoh, T., Nagayama, S., Suzuki, S., Matsuo, T., and R. Van Meter, "Attacking the quantum internet", arXiv 2005.04617, 2020, . [SutorBook] Sutor, R.S., "Dancing with Qubits", Packt Publishing , 2019. [Tang19] Tang, B.-Y., Liu, B., Zhai, Y.-P., Wu, C.-Q., and W.-R. Yu, "High-speed and Large-scale Privacy Amplification Scheme for Quantum Key Distribution", Scientific Reports Vol. 9, Iss. 1, pp. 1-8, 2019, . [Teleportation] Quantum Network Explorer by QuTech, "State teleportation", 2021, . [Terhal04] Terhal, B.M., "Is entanglement monogamous?", IBM Journal of Research and Development Vol. 48, Iss. 1, pp. 71-78, 2004, . Kozlowski, et al. Expires 1 March 2023 [Page 43] Internet-Draft Principles for a Quantum Internet August 2022 [VanMeter13.1] Van Meter, R. and J. Touch, "Designing quantum repeater networks", IEEE Communications Magazine Vol. 51, Iss. 8, pp. 64-71, 2013, . [VanMeter13.2] Van Meter, R., Satoh, T., Ladd, T.D., Munro, W.J., and K. Nemoto, "Path selection for quantum repeater networks", Networking Science Vol. 3, Iss. 1-4, pp. 82-95, 2013, . [VanMeterBook] Van Meter, R., "Quantum Networking", ISTE Ltd/John Wiley and Sons Inc 978-1-84821-537-5, 2014. [Wang21] Wang, L.-J., Zhang, K.-Y., Wang, J.-Y., Cheng, J., Yang, Y.-H., Tang, S.-B., Yan, D., Tang, Y.-L., Liu, Z., Yu, Y., Zhang, Q., and J.-W. Pan, "Experimental authentication of quantum key distribution with post-quantum cryptography", npj Quantum Information Vol. 7, no. 1, pp. 1-7, 2021, . [Wehner18] Wehner, S., Elkouss, D., and R. Hanson, "Quantum internet: A vision for the road ahead", Science Vol. 362, Iss. 6412, 2018, . [Wei22] Wei, S.-H., Jing, B., Zhang, X.-Y., Liao, J.-Y., Yuan, C.- Z., Fan, B.-Y., Lyu, C., Zhou, D.-L., Wang, Y., Deng, G.- W., Song, H.-Z., Oblak, D., Guo, G.-C., and Q. Zhou, "Towards real-world quantum networks: a review", arXiv 2201.04802, 2022, . [Wootters82] Wootters, W.K. and W.H. Zurek, "A single quantum cannot be cloned", Nature Vol. 299, Iss. 5886, pp. 802-803, 1982, . [ZOO] "The Quantum Protocol Zoo", . Authors' Addresses Kozlowski, et al. Expires 1 March 2023 [Page 44] Internet-Draft Principles for a Quantum Internet August 2022 Wojciech Kozlowski QuTech Building 22 Lorentzweg 1 2628 CJ Delft Netherlands Email: w.kozlowski@tudelft.nl Stephanie Wehner QuTech Building 22 Lorentzweg 1 2628 CJ Delft Netherlands Email: s.d.c.wehner@tudelft.nl Rodney Van Meter Keio University 5322 Endo, Kanagawa 252-0882 Japan Email: rdv@sfc.wide.ad.jp Bruno Rijsman Individual Email: brunorijsman@gmail.com Angela Sara Cacciapuoti University of Naples Federico II Department of Electrical Engineering and Information Technologies Claudio 21 80125 Naples Italy Email: angelasara.cacciapuoti@unina.it Marcello Caleffi University of Naples Federico II Department of Electrical Engineering and Information Technologies Claudio 21 80125 Naples Italy Email: marcello.caleffi@unina.it Kozlowski, et al. Expires 1 March 2023 [Page 45] Internet-Draft Principles for a Quantum Internet August 2022 Shota Nagayama Mercari, Inc. Roppongi Hills Mori Tower 18F 6-10-1 Roppongi, Minato-ku, 106-6118 Japan Email: shota.nagayama@mercari.com Kozlowski, et al. Expires 1 March 2023 [Page 46] ./draft-moskowitz-ipsecme-ipseckey-eddsa-09.txt0000644000764400076440000001735014355103256021323 0ustar iustiniustin IPSECME R. Moskowitz Internet-Draft HTT Consulting Intended status: Standards Track T. Kivinen Expires: 7 July 2023 M. Richardson Sandelman 3 January 2023 EdDSA value for IPSECKEY draft-moskowitz-ipsecme-ipseckey-eddsa-09 Abstract This document assigns a value for EdDSA Public Keys to the IPSECKEY IANA registry. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 July 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Moskowitz, et al. Expires 7 July 2023 [Page 1] Internet-Draft IPSECKEY EdDSA January 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. IPSECKEY support for EdDSA . . . . . . . . . . . . . . . . . 2 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2 3.1. IANA IPSECKEY Registry Update . . . . . . . . . . . . . . 2 3.1.1. Reformat Algorithm Type Field Subregistry . . . . . . 3 3.1.2. Add to Algorithm Type Field Subregistry . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 5.1. Normative References . . . . . . . . . . . . . . . . . . 3 5.2. Informative References . . . . . . . . . . . . . . . . . 4 Appendix A. IPSECKEY EdDSA example . . . . . . . . . . . . . . . 4 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction IPSECKEY [RFC4025) is a resource record (RR) for the Domain Name System (DNS) that is used to store public keys for use in IP security (IPsec) systems. The IPSECKEY RR relies on the IPSECKEY Algorithm Type Field registry [IANA-IPSECKEY] to enumerate the permissible formats for the public keys. This document adds support for Edwards-Curve Digital Security Algorithm (EdDSA) public keys in the format defined in [RFC8080] to the IPSECKEY RR. 2. IPSECKEY support for EdDSA When using the EdDSA public key in the IPSECKEY RR, then the value TBD1 is used as an algorithm and the public key is formatted as specified in Section 3 of the "Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC" ([RFC8080]) document. Value Description Format description Reference TBD1 An EdDSA Public Key [RFC8080], Sec. 3 [ThisRFC] 3. IANA Considerations 3.1. IANA IPSECKEY Registry Update Moskowitz, et al. Expires 7 July 2023 [Page 2] Internet-Draft IPSECKEY EdDSA January 2023 3.1.1. Reformat Algorithm Type Field Subregistry This document requests IANA to add a new field "Format description" to the "Algorithm Type Field" subregistry of the "IPSECKEY Resource Record Parameters" [IANA-IPSECKEY]. Also, this document requests IANA to update the "Description" field in existing entries of that registry to explicitly state that is for "Public" keys: Value Description Format description Reference 0 No Public key is present [RFC4025] 1 A DSA Public Key [RFC2536], Sec. 2 [RFC4025] 2 A RSA Public Key [RFC3110], Sec. 2 [RFC4025] 3 An ECDSA Public Key [RFC6605], Sec. 4 [RFC8005] IANA is requested to update the reference of that registry by adding the RFC number to be assigned to this document. 3.1.2. Add to Algorithm Type Field Subregistry Further, this document requests IANA to make the following addition to the "IPSECKEY Resource Record Parameters" [IANA-IPSECKEY] registry: IPSECKEY: This document defines the new IPSECKEY value TBD1 (suggested: 4) (Section 2) in the "Algorithm Type Field" subregistry of the "IPSECKEY Resource Record Parameters" registry. Value Description Format description Reference TBD1 An EdDSA Public Key [RFC8080], Sec. 3 [ThisRFC] 4. Security Considerations No new issues than [RFC4025] describes. 5. References 5.1. Normative References [IANA-IPSECKEY] IANA, "IPSECKEY Resource Record Parameters", . Moskowitz, et al. Expires 7 July 2023 [Page 3] Internet-Draft IPSECKEY EdDSA January 2023 [RFC8080] Sury, O., Edmonds, R., and RFC Publisher, "Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC", RFC 8080, DOI 10.17487/RFC8080, February 2017, . 5.2. Informative References [RFC4025] Richardson, M. and RFC Publisher, "A Method for Storing IPsec Keying Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 2005, . Appendix A. IPSECKEY EdDSA example The following is an example of an IPSECKEY RR with an EdDSA public key base64 encode with no gateway: foo.example.com. IN IPSECKEY ( 10 0 4 . 3WTXgUvpn1RlCXnm80gGY2LZ/ErUUEZtZ33IDi8yfhM= ) The associated EdDSA private key (in hex): c7be71a45cbf87785f639dc4fd1c82637c21b5e02488939976ece32b9268d0b7 Acknowledgments Thanks to Security Area director, Paul Wouters, for initial review. And Security Area director, Roman Danyliw, for final reviews and draft shepherding. Authors' Addresses Robert Moskowitz HTT Consulting Oak Park, MI 48237 United States of America Email: rgm@labs.htt-consult.com Tero Kivinen Email: kivinen@iki.fi Michael C. Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca Moskowitz, et al. Expires 7 July 2023 [Page 4] Internet-Draft IPSECKEY EdDSA January 2023 URI: https://www.sandelman.ca/ Moskowitz, et al. Expires 7 July 2023 [Page 5] ./draft-pti-pen-registration-10.txt0000644000764400076440000003023514346652626017025 0ustar iustiniustin Network Working Group A. Baber Internet-Draft IANA Intended status: Informational P. Hoffman Expires: 18 June 2023 ICANN 15 December 2022 Registration Procedures for Private Enterprise Numbers (PENs) draft-pti-pen-registration-10 Abstract This document describes how Private Enterprise Numbers (PENs) are registered by IANA. It shows how to request a new PEN and how to request an update to a current PEN. It also gives a brief overview of PEN uses. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 18 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Baber & Hoffman Expires 18 June 2023 [Page 1] Internet-Draft PEN registration December 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Uses of PENs . . . . . . . . . . . . . . . . . . . . . . 2 2. PEN Assignment . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requesting a PEN Assignment . . . . . . . . . . . . . . . 3 2.2. Modifying an Existing Record . . . . . . . . . . . . . . 3 2.3. Deleting a PEN Record . . . . . . . . . . . . . . . . . . 4 3. PEN Registry Specifics . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Private Enterprise Numbers (PENs) are identifiers that can be used anywhere that an ASN.1 object identifier (OID) [ASN1] can be used. Originally, PENs were developed so that organizations that needed to identify themselves in Simple Network Management Protocol (SNMP) [RFC3411] Management Information Base (MIB) configurations could do so easily. PENs are also useful in any application or configuration language that needs OIDs to identify organizations. The IANA Functions Operator, referred to in this document as "IANA", manages and maintains the PEN registry in consultation with the IESG. PENs are issued from an OID prefix that was assigned to IANA. That OID prefix is 1.3.6.1.4.1. Using the (now archaic) notation of ownership names in the OID tree, that corresponds to: 1 3 6 1 4 1 iso.org.dod.internet.private.enterprise A PEN is an OID that begins with the PEN prefix. Thus, the OID 1.3.6.1.4.1.32473 is a PEN. 1.1. Uses of PENs Once a PEN has been assigned to an organization, individual, or other entity, that assignee can use the PEN by itself (possibly to represent the assignee) or as the root of other OIDs associated with the assignee. For example, if an assignee is assigned the PEN 1.3.6.1.4.1.32473, it might use 1.3.6.1.4.1.32473.7 to identify a protocol extension and use 1.3.6.1.4.1.32473.12.3 to identify a set of algorithms that it supports in a protocol. Baber & Hoffman Expires 18 June 2023 [Page 2] Internet-Draft PEN registration December 2022 Neither IANA nor the IETF can control how an assignee uses its PEN. In fact, no one can exert such control: that is the meaning of "private" in "private enterprise number". Similarly, no one can prevent an assignee that is not the registered owner of a PEN from using that PEN, or any PEN, however they want. A very common use of PENs is to give unique identifiers in IETF protocols. SNMP MIB configuration files use PENs for identifying the origin of values. Some protocols that use PENs as identifiers of extension mechanisms include RADIUS [RFC2865], Diameter [RFC6733], Syslog [RFC5424], RSVP [RFC5284], and vCard [RFC6350]. 2. PEN Assignment Private Enterprise Numbers (PENs) are assigned by IANA. The registry is located at https://www.iana.org/assignments/enterprise-numbers, and requests for new assignments or the modification of existing assignments can also be submitted at that URL. IANA maintains the PEN registry in accordance with the "First Come First Served" registration policy described in [RFC8126]. Values are assigned sequentially. 2.1. Requesting a PEN Assignment Requests for assignment must provide the name of the assignee, the name of a public contact who can respond to questions about the assignment, and contact information that can be used to verify change requests. The contact's name and email address will be included in the public registry. A proposed assignee may request multiple PENs, but obtaining one PEN and making internal sub-assignments is typically more appropriate. (Sub-assignments should not be reported to IANA.) IANA may refuse to process abusive requests. 2.2. Modifying an Existing Record Any of the information associated with a registered value can be modified, including the name of the assignee. Modification requests require authorization by a representative of the assignee. Authorization will be validated either with information kept on file with IANA or with other identifying documentation, if necessary. Baber & Hoffman Expires 18 June 2023 [Page 3] Internet-Draft PEN registration December 2022 2.3. Deleting a PEN Record Although such requests are rare, registrations can be deleted. When a registration is deleted, all identifying information is removed from the registry, and the value is marked as "returned." Returned values will not be made available for re-assignment until all other unassigned values have been exhausted; as can be seen in Section 3, the unassigned values are unlikely to ever run out. 3. PEN Registry Specifics The range for values after the PEN prefix is 0 to 2**32-1. The values 0 and 4294967295 (2**32-1) are reserved. Note that while the original PEN definition had no upper bound for the value after the PEN prefix, there is now an upper bound due to some IETF protocols limiting the size of that value. For example, Diameter [RFC6733] limits the value to 2**32-1. There is a PEN number, 32473, reserved for use as an example in documentation. This reservation is described in [RFC5612]. Values in the registry that have unclear ownership are marked "Reserved". These values will not be reassigned to a new company or individual without consulting the IESG. 4. IANA Considerations This document requires two changes to the PEN registry. Values 2187, 2188, 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144, 5201, 5683, 5777, 6260, 6619, 14827, 16739, 26975 and the range from 11670 to 11769, which had been missing from the registry, will be listed as "Reserved." As described in [RFC8126], reserved values can be released by the IESG. In addition, this document will be listed in the registry's "Reference" field. 5. Security Considerations Registering PENs does not introduce any significant security considerations. Baber & Hoffman Expires 18 June 2023 [Page 4] Internet-Draft PEN registration December 2022 There is no cryptographic binding of a registrant in the PEN registry and the PEN(s) assigned to them. Thus, the entries in the PEN registry cannot be used to validate the ownership of a PEN in use. For example, if the PEN 1.3.6.1.4.1.32473 is seen in a protocol as indicating the owner of some data, there is no way to securely correlate that use with the name and assignee of the owner listed in the PEN registry. 6. Acknowledgements An earlier version of this document was authored by Pearl Liang and Alexey Melnikov. Additional significant contributions have come from Dan Romascanu, Bert Wijnen, David Conrad, Michelle Cotton, and Benoit Claise. 7. References 7.1. Normative References [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . 7.2. Informative References [ASN1] ITU-T, "ITU-T X.690: Information technology - ASN.1 encoding rules", 2016, . [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, . [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, . [RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", RFC 5284, DOI 10.17487/RFC5284, August 2008, . [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, . Baber & Hoffman Expires 18 June 2023 [Page 5] Internet-Draft PEN registration December 2022 [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 2009, . [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, . [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, . Authors' Addresses Amanda Baber Internet Assigned Numbers Authority PTI/ICANN 12025 Waterfront Drive Los Angeles, 90094 United States of America Email: amanda.baber@iana.org Paul Hoffman ICANN 12025 Waterfront Drive Los Angeles, 90094 United States of America Email: paul.hoffman@icann.org Baber & Hoffman Expires 18 June 2023 [Page 6] ./draft-smyshlyaev-tls13-gost-suites-08.txt0000644000764400076440000053515414307404643020405 0ustar iustiniustin Network Working Group S.V. Smyshlyaev, Ed. Internet-Draft E.K. Alekseev Intended status: Informational E.S. Griboedova Expires: 15 March 2023 A.A. Babueva L.O. Nikiforova CryptoPro 11 September 2022 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3 draft-smyshlyaev-tls13-gost-suites-08 Abstract The purpose of this document is to make the Russian cryptographic standards available to the Internet community for their implementation in the Transport Layer Security (TLS) Protocol Version 1.3. This document defines the cipher suites, signature schemes, and key exchange mechanisms for using Russian cryptographic standards, called GOST algorithms, with Transport Layer Security (TLS) Version 1.3. Additionally, this document specifies a profile of TLS 1.3 with GOST algorithms to facilitate interoperable implementations. The IETF has not endorsed the cipher suites, signature schemes, key exchange mechanism described in this document. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 15 March 2023. Smyshlyaev, et al. Expires 15 March 2023 [Page 1] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Basic Terms and Definitions . . . . . . . . . . . . . . . . . 4 4. Cipher Suite Definition . . . . . . . . . . . . . . . . . . . 6 4.1. Record Protection Algorithm . . . . . . . . . . . . . . . 6 4.1.1. AEAD Algorithm . . . . . . . . . . . . . . . . . . . 8 4.1.2. TLSTREE . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.3. SNMAX parameter . . . . . . . . . . . . . . . . . . . 10 4.2. Hash Algorithm . . . . . . . . . . . . . . . . . . . . . 11 5. Signature Scheme Definition . . . . . . . . . . . . . . . . . 11 5.1. Signature Algorithm . . . . . . . . . . . . . . . . . . . 11 5.2. Elliptic Curve . . . . . . . . . . . . . . . . . . . . . 12 5.3. SIGN function . . . . . . . . . . . . . . . . . . . . . . 13 6. Key Exchange and Authentication . . . . . . . . . . . . . . . 13 6.1. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 14 6.1.1. ECDHE Shared Secret Calculation . . . . . . . . . . . 14 6.1.1.1. ECDHE Shared Secret Calculation on Client Side . 14 6.1.1.2. ECDHE Shared Secret Calculation on Server Side . 16 6.1.1.3. Public ephemeral key representation . . . . . . . 17 6.1.2. Values for the TLS Supported Groups Registry . . . . 17 6.2. Authentication . . . . . . . . . . . . . . . . . . . . . 18 6.3. Handshake Messages . . . . . . . . . . . . . . . . . . . 19 6.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 19 6.3.2. CertificateRequest . . . . . . . . . . . . . . . . . 20 6.3.3. Certificate . . . . . . . . . . . . . . . . . . . . . 20 6.3.4. CertificateVerify . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. Historical considerations . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 24 Smyshlyaev, et al. Expires 15 March 2023 [Page 2] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 Appendix A. Test Examples . . . . . . . . . . . . . . . . . . . 24 A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 24 A.1.1. Test case . . . . . . . . . . . . . . . . . . . . . . 25 A.1.2. Test examples . . . . . . . . . . . . . . . . . . . . 25 A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 59 A.2.1. Test case . . . . . . . . . . . . . . . . . . . . . . 59 A.2.2. Test examples . . . . . . . . . . . . . . . . . . . . 59 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84 1. Introduction This document defines four new cipher suites (the TLS13_GOST cipher suites) and seven new signature schemes (the TLS13_GOST signature schemes) for the Transport Layer Security (TLS) Protocol Version 1.3, that are based on Russian cryptographic standards GOST R 34.12-2015 [RFC7801], GOST R 34.11-2012 [RFC6986] and GOST R 34.10-2012 [RFC7091]. The TLS13_GOST cipher suites (see Section 4) have the following values: TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1, 0x03}; TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {0xC1, 0x04}; TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {0xC1, 0x05}; TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06}. Each TLS13_GOST cipher suite specifies a pair (record protection algorithm, hash algorithm) such that: * The record protection algorithm is the AEAD algorithm (see Section 4.1.1) based on the GOST R 34.12-2015 block cipher [RFC7801] in the Multilinear Galois Mode (MGM) [RFC9058] and the external re-keying approach (see [RFC8645]) intended for increasing the lifetime of symmetric keys used to protect records. * The hash algorithm is the GOST R 34.11-2012 algorithm [RFC6986]. Note: The TLS13_GOST cipher suites are divided into two types (depending on the key lifetime limitations, see Section 4.1.2 and Section 4.1.3): the "_S" (strong) cipher suites and the "_L" (light) cipher suites. The TLS13_GOST signature schemes have the following values: gostr34102012_256a = 0x0709; gostr34102012_256b = 0x070A; Smyshlyaev, et al. Expires 15 March 2023 [Page 3] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 gostr34102012_256c = 0x070B; gostr34102012_256d = 0x070C; gostr34102012_512a = 0x070D; gostr34102012_512b = 0x070E; gostr34102012_512c = 0x070F. Each TLS13_GOST signature scheme specifies a pair (signature algorithm, elliptic curve) such that: * The signature algorithm is the GOST R 34.10-2012 algorithm [RFC7091]. * The elliptic curve is one of the curves defined in Section 5.2. Also, this document specifies the key exchange mechanism with GOST algorithms for TLS 1.3 protocol (see Section 6.1). Additionally, this document specifies a TLS13_GOST profile of the TLS 1.3 protocol with GOST algorithms so that implementers can produce interoperable implementations. It uses TLS13_GOST cipher suites, TLS13_GOST signature schemes, key exchange mechanism that defined in this document. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Basic Terms and Definitions This document follows the terminology from [I-D.ietf-tls-rfc8446bis] for "main secret". This document uses the following terms and definitions for the sets and operations on the elements of these sets: B_t the set of byte strings of length t, t >= 0, for t = 0 the B_t set consists of a single empty string of zero length. If A is an element in B_t, then A = (a_1, a_2, ... , a_t), where a_1, a_2, ... , a_t are in {0, ... , 255}; Smyshlyaev, et al. Expires 15 March 2023 [Page 4] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 B* the set of all byte strings of a finite length (hereinafter referred to as strings), including the empty string; A[i..j] the string A[i..j] = (a_i, a_{i+1}, ... , a_j) in B_{j-i+1}, where A = (a_1, a_2, ... , a_t) in B_t and 1<=i<=j<=t; A[i] the integer a_i in {0, ... , 255}, where A = (a_1, a_2, ... , a_t) in B_t and 1<=i<=t; |A| the length of the byte string A in bytes; A | C the concatenation of strings A and C both belonging to B*, i.e., a string in B_{|A|+|C|}, where the left substring in B_|A| is equal to A, and the right substring in B_|C| is equal to C; i & j bitwise AND of integers i and j; STR_t the transformation that maps an integer i = 256^(t-1) * i_1 + ... + 256 * i_{t-1} + i_t into the byte string STR_t(i) = (i_1, ... , i_t) in B_t (the interpretation of the integer as a byte string in big-endian format); str_t the transformation that maps an integer i = 256^(t-1) * i_t + ... + 256 * i_2 + i_1 into the byte string str_t(i) = (i_1, ... , i_t) in B_t (the interpretation of the integer as a byte string in little-endian format); k the length of the block cipher key in bytes; n the length of the block cipher block in bytes; IVlen the length of the initialization vector in bytes; S the length of the authentication tag in bytes; E_i the elliptic curve indicated by the client in "supported_groups" extension; O_i the zero point of the elliptic curve E_i; m_i the order of group of points belonging to the elliptic curve E_i; Smyshlyaev, et al. Expires 15 March 2023 [Page 5] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 q_i the order of the cyclic subgroup of the group of points belonging to the elliptic curve E_i; h_i the cofactor of the cyclic subgroup which is equal to m_i / q_i; Q_sign the public key stored in endpoint's certificate; d_sign the private key that corresponds to the Q_sign key; P_i the point of the elliptic curve E_i of the order q_i; (d_C^i, Q_C^i) the client's ephemeral key pair which consists of the private key and the public key corresponding to the elliptic curve E_i; (d_S^i, Q_S^i) the server's ephemeral key pair which consists of the private key and the public key corresponding to the elliptic curve E_i. 4. Cipher Suite Definition This section defines the following four TLS13_GOST cipher suites: CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1, 0x03}; CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {0xC1, 0x04}; CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {0xC1, 0x05}; CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06}; Each cipher suite specifies a pair of a record protection algorithm (see Section 4.1) and a hash algorithm (Section 4.2). 4.1. Record Protection Algorithm In accordance with Section 5.2 of [RFC8446], the record protection algorithm translates a TLSPlaintext structure into a TLSCiphertext structure. If the TLS13_GOST cipher suite is negotiated, the encrypted_record field of the TLSCiphertext structure MUST be set to the AEADEncrypted value computed as follows: AEADEncrypted = AEAD-Encrypt(sender_record_write_key, nonce, additional_data, plaintext), where * the AEAD-Encrypt function is defined in Section 4.1.1; Smyshlyaev, et al. Expires 15 March 2023 [Page 6] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 * the sender_record_write_key is a key derived from sender_write_key (see Section 7.3 of [RFC8446]) using the TLSTREE function defined in Section 4.1.2 and sequence number seqnum as follows: sender_record_write_key = TLSTREE(sender_write_key, seqnum); * the nonce is a value derived from sequence number seqnum and sender_write_iv (see Section 7.3 of [RFC8446]) in accordance with Section 5.3 of [RFC8446]; * the additional_data value is a record header that is generated in accordance with Section 5.2 of [RFC8446]; * the plaintext value is the TLSInnerPlaintext structure encoded in accordance with Section 5.2 of [RFC8446]. Note1: The AEAD-Encrypt function is exactly the same as the AEAD- Encrypt function defined in [RFC8446], such that the key (the first argument) is calculated from sender_write_key and sequence number seqnum for each message separately to support the external re-keying approach according to [RFC8645]. Note2: Sequence number is a value in the range 0-SNMAX, where the SNMAX value is defined in Section 4.1.3. The SNMAX parameter is specified by a particular TLS13_GOST cipher suite to limit an amount of data that can be encrypted under the same traffic key material (sender_write_key, sender_write_iv). The record deprotection algorithm reverses the process of the record protection. In order to decrypt and verify a protected record with sequence number seqnum the algorithm takes as an input: sender_record_write_key, which is derived from sender_write_key, nonce, additional_data and the AEADEncrypted value. The algorithm outputs the res value which is either plaintext or an error indicating that the decryption failed. If a TLS13_GOST cipher suite is negotiated, the res value MUST be computed as follows: res = AEAD-Decrypt(sender_record_write_key, nonce, additional_data, AEADEncrypted), where the AEAD-Decrypt function is defined in Section 4.1.1. Note: The AEAD-Decrypt function is exactly the same as the AEAD- Decrypt function defined in [RFC8446], such that the key (the first argument) is calculated from sender_write_key and sequence number seqnum for each message separately to support the external re-keying approach according to [RFC8645]. Smyshlyaev, et al. Expires 15 March 2023 [Page 7] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 4.1.1. AEAD Algorithm The AEAD-Encrypt and AEAD-Decrypt functions are defined as follows. +-------------------------------------------------------------------+ | AEAD-Encrypt(K, nonce, A, P) | |-------------------------------------------------------------------| | Input: | | - encryption key K in B_k, | | - unique vector nonce in B_IVlen, | | - additional authenticated data A in B_r, r >= 0, | | - plaintext P in B_t, t >= 0. | | Output: | | - ciphertext C in B_{|P|}, | | - authentication tag T in B_S. | |-------------------------------------------------------------------| | 1. MGMnonce = STR_1(nonce[1] & 0x7f) | nonce[2..IVlen]; | | 2. (MGMnonce, A, C, T) = MGM-Encrypt(K, MGMnonce, A, P); | | 3. Return C | T. | +-------------------------------------------------------------------+ +-------------------------------------------------------------------+ | AEAD-Decrypt(K, nonce, A, C | T) | |-------------------------------------------------------------------| | Input: | | - encryption key K in B_k, | | - unique vector nonce in B_IVlen, | | - additional authenticated data A in B_r, r >= 0, | | - ciphertext C in B_t, t >= 0, | | - authentication tag T in B_S. | | Output: | | - plaintext P in B_{|C|} or FAIL. | |-------------------------------------------------------------------| | 1. MGMnonce = STR_1(nonce[1] & 0x7f) | nonce[2..IVlen]; | | 2. res' = MGM-Decrypt(K, MGMnonce, A, C, T); | | 3. IF res' = FAIL then return FAIL; | | 4. IF res' = (A, P) then return P. | +-------------------------------------------------------------------+ where * the MGM-Encrypt and MGM-Decrypt functions are defined in [RFC9058]. The length of authentication tag T is equal to n bytes (S = n). The length of the nonce parameter is equal to n bytes (IVlen = n). Smyshlyaev, et al. Expires 15 March 2023 [Page 8] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 Cipher suites TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L and TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S MUST use Kuznyechik [RFC7801] as a base block cipher for the AEAD algorithm. The block length n is 16 bytes (n = 16) and the key length k is 32 bytes (k = 32). Cipher suites TLS_GOSTR341112_256_WITH_MAGMA_MGM_L and TLS_GOSTR341112_256_WITH_MAGMA_MGM_S MUST use Magma [RFC8891] as a base block cipher for the AEAD algorithm. The block length n is 8 bytes (n = 8) and the key length k is 32 bytes (k = 32). 4.1.2. TLSTREE The TLS13_GOST cipher suites use the TLSTREE function to support the external re-keying approach (see [RFC8645]). The TLSTREE function is defined as follows: TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, STR_8(i & C_1)), STR_8(i & C_2)), STR_8(i & C_3)), where * K_root in B_32; * i in {0, 1, ... , 2^64 - 1}; * KDF_j(K, D), j = 1, 2, 3, is the key derivation function defined as follows: KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D), KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D), KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D), where the KDF_GOSTR3411_2012_256 function is defined in [RFC7836], K in B_32, D in B_8. * C_1, C_2, C_3 are the constants defined by each cipher suite as follows: Smyshlyaev, et al. Expires 15 March 2023 [Page 9] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 +------------------------------------------+----------------------+ | CipherSuites | C_1, C_2, C_3 | +------------------------------------------+----------------------+ |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L |C_1=0xf800000000000000| | |C_2=0xfffffff000000000| | |C_3=0xffffffffffffe000| +------------------------------------------+----------------------+ |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L |C_1=0xffe0000000000000| | |C_2=0xffffffffc0000000| | |C_3=0xffffffffffffff80| +------------------------------------------+----------------------+ |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S |C_1=0xffffffffe0000000| | |C_2=0xffffffffffff0000| | |C_3=0xfffffffffffffff8| +------------------------------------------+----------------------+ |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S |C_1=0xfffffffffc000000| | |C_2=0xffffffffffffe000| | |C_3=0xffffffffffffffff| +------------------------------------------+----------------------+ Table 1 4.1.3. SNMAX parameter The SNMAX parameter is the maximum number of records encrypted under the same traffic key material (sender_write_key and sender_write_iv) and is defined by each cipher suite as follows: +------------------------------------------+--------------------+ | CipherSuites | SNMAX | +------------------------------------------+--------------------+ |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L | SNMAX = 2^64 - 1 | +------------------------------------------+--------------------+ |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L | SNMAX = 2^64 - 1 | +------------------------------------------+--------------------+ |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S | SNMAX = 2^42 - 1 | +------------------------------------------+--------------------+ |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S | SNMAX = 2^39 - 1 | +------------------------------------------+--------------------+ Table 2 Smyshlyaev, et al. Expires 15 March 2023 [Page 10] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 4.2. Hash Algorithm The Hash algorithm is used for the key derivation process (see Section 7.1 of [RFC8446]), Finished message calculation (see Section 4.4.4 of [RFC8446]), Transcript-Hash function computation (see Section 4.4.1 of [RFC8446]), PSK binder value calculation (see Section 4.2.11.2 of [RFC8446]), external re-keying approach (see Section 4.1.2) and other purposes. If a TLS13_GOST cipher suite is negotiated, the Hash algorithm MUST be the GOST R 34.11-2012 hash algorithm [RFC6986] with 32-byte (256-bit) hash value. 5. Signature Scheme Definition This section defines the following seven TLS13_GOST signature schemes: enum { gostr34102012_256a(0x0709), gostr34102012_256b(0x070A), gostr34102012_256c(0x070B), gostr34102012_256d(0x070C), gostr34102012_512a(0x070D), gostr34102012_512b(0x070E), gostr34102012_512c(0x070F) } SignatureScheme; One of the TLS13_GOST signature schemes listed above SHOULD be used with the TLS13_GOST profile. Each signature scheme specifies a pair of the signature algorithm (see Section 5.1) and the elliptic curve (see Section 5.2). The procedure to calculate the signature value using TLS13_GOST signature schemes is defined in Section 5.3. 5.1. Signature Algorithm Signature algorithms corresponding to the TLS13_GOST signature schemes are defined as follows: Smyshlyaev, et al. Expires 15 March 2023 [Page 11] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 +------------------+--------------------------------------+--------+ | SignatureScheme | Signature Algorithm | Refe- | | Value | | rences | +------------------+--------------------------------------+--------+ |gostr34102012_256a|GOST R 34.10-2012 , 32-byte key length|RFC 7091| +------------------+--------------------------------------+--------+ |gostr34102012_256b|GOST R 34.10-2012 , 32-byte key length|RFC 7091| +------------------+--------------------------------------+--------+ |gostr34102012_256c|GOST R 34.10-2012 , 32-byte key length|RFC 7091| +------------------+--------------------------------------+--------+ |gostr34102012_256d|GOST R 34.10-2012 , 32-byte key length|RFC 7091| +------------------+--------------------------------------+--------+ |gostr34102012_512a|GOST R 34.10-2012 , 64-byte key length|RFC 7091| +------------------+--------------------------------------+--------+ |gostr34102012_512b|GOST R 34.10-2012 , 64-byte key length|RFC 7091| +------------------+--------------------------------------+--------+ |gostr34102012_512c|GOST R 34.10-2012 , 64-byte key length|RFC 7091| +------------------+--------------------------------------+--------+ Table 3 5.2. Elliptic Curve Elliptic curves corresponding to the TLS13_GOST signature schemes are defined as follows: +------------------+--------------------------------------+--------+ | SignatureScheme | Curve Identifier Value | Refe- | | Value | | rences | +------------------+--------------------------------------+--------+ |gostr34102012_256a| id-tc26-gost-3410-2012-256-paramSetA |RFC 7836| +------------------+--------------------------------------+--------+ |gostr34102012_256b|id-GostR3410-2001-CryptoPro-A-ParamSet|RFC 4357| +------------------+--------------------------------------+--------+ |gostr34102012_256c|id-GostR3410-2001-CryptoPro-B-ParamSet|RFC 4357| +------------------+--------------------------------------+--------+ |gostr34102012_256d|id-GostR3410-2001-CryptoPro-C-ParamSet|RFC 4357| +------------------+--------------------------------------+--------+ |gostr34102012_512a| id-tc26-gost-3410-12-512-paramSetA |RFC 7836| +------------------+--------------------------------------+--------+ |gostr34102012_512b| id-tc26-gost-3410-12-512-paramSetB |RFC 7836| +------------------+--------------------------------------+--------+ |gostr34102012_512c| id-tc26-gost-3410-2012-512-paramSetC |RFC 7836| +------------------+--------------------------------------+--------+ Table 4 Smyshlyaev, et al. Expires 15 March 2023 [Page 12] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 5.3. SIGN function If the TLS13_GOST signature scheme is used, the signature value in the CertificateVerify message (see Section 6.3.4) MUST be calculated using the SIGN function defined as follows: +-----------------------------------------------------+ | SIGN(d_sign, M) | |-----------------------------------------------------| | Input: | | - the sign key d_sign: 0 < d_sign < q; | | - the byte string M in B*. | | Output: | | - signature value sgn in B_{2*l}. | |-----------------------------------------------------| | 1. (r, s) = SIGNGOST(d_sign, M) | | 2. Return str_l(r) | str_l(s). | |-----------------------------------------------------+ where * q is the subgroup order of group of points of the elliptic curve; * l is defined as follows: - l = 32 for the gostr34102012_256a, gostr34102012_256b, gostr34102012_256c and gostr34102012_256d signature schemes; - l = 64 for the gostr34102012_512a, gostr34102012_512b and gostr34102012_512c signature schemes; * SIGNGOST is an algorithm which takes a private key d_sign and a message M as an input and returns a pair of integers (r, s) calculated during signature generation process in accordance with the GOST R 34.10-2012 signature algorithm (see Section 6.1 of [RFC7091]). Note: The signature value sgn is the concatenation of two strings that are byte representations of r and s values in the little-endian format. 6. Key Exchange and Authentication Key exchange and authentication process in case of using the TLS13_GOST profile is defined in Section 6.1, Section 6.2 and Section 6.3. Smyshlyaev, et al. Expires 15 March 2023 [Page 13] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 6.1. Key Exchange TLS13_GOST profile supports three basic key exchange modes which are defined in [RFC8446]: ECDHE, PSK-only and PSK with ECDHE. Note: In accordance with [RFC8446] TLS 1.3 also supports key exchange modes based on Diffie-Hellman protocol over finite fields. However, TLS13_GOST profile MUST use modes based on Diffie-Hellman protocol over elliptic curves. In accordance with [RFC8446] PSKs can be divided into two types: * internal PSKs which can be established during the previous connection; * external PSKs which can be established out of band. If the TLS13_GOST profile is used, PSK-only key exchange mode SHOULD be established via the internal PSKs, and external PSKs SHOULD be used only in PSK with ECDHE mode (see more in Section 9). If the TLS13_GOST profile is used and ECDHE or PSK with ECDHE key exchange mode is used, the ECDHE shared secret SHOULD be calculated in accordance with Section 6.1.1 on the basis of one of the elliptic curves defined in Section 6.1.2. 6.1.1. ECDHE Shared Secret Calculation If the TLS13_GOST profile is used, ECDHE shared secret SHOULD be calculated in accordance with Section 6.1.1.1 and Section 6.1.1.2. The public ephemeral keys used to obtain ECDHE shared secret SHOULD be represented in the format described in Section 6.1.1.3. 6.1.1.1. ECDHE Shared Secret Calculation on Client Side The client calculates ECDHE shared secret in accordance with the following steps: 1. Chooses from all supported curves E_1, ..., E_R the set of curves E_{i_1}, ..., E_{i_r}, 1 <= i_1 <= i_r <= R, where * r >= 1 in case of the first ClientHello message; * r = 1 in case of responding to the HelloRetryRequest message, E_{i_1} corresponds to the curve indicated in the "key_share" extension in the HelloRetryRequest message. Smyshlyaev, et al. Expires 15 March 2023 [Page 14] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 2. Generates ephemeral key pairs (d_C^{i_1}, Q_C^{i_1}), ..., (d_C^{i_r}, Q_C^{i_r}) corresponding to the curves E_{i_1}, ..., E_{i_r}, where for each i in {i_1, ..., i_r}: * d_C^i is chosen from {1, ..., q_i - 1} at random; * Q_C^i = d_C^i * P_i. 3. Sends the ClientHello message specified in accordance with Section 4.1.2 of [RFC8446] and Section 6.3.1, which contains: * "key_share" extension with public ephemeral keys Q_C^{i_1}, ..., Q_C^{i_r} built in accordance with Section 4.2.8 of [RFC8446]; * "supported_groups" extension with supported curves E_1, ..., E_R built in accordance with Section 4.2.7 of [RFC8446]. Note: The client MAY send an empty "key_share" extension in the first ClientHello message to request a group selection from the server in the HelloRetryRequest message and to generate an ephemeral key for the selected group only. The ECDHE shared secret may be calculated without sending HelloRetryRequest message, if the "key_share" extension in the first ClientHello message contains the value corresponding to the curve that is selected by the server. 4. If the HelloRetryRequest message is received, the client MUST return to step 1 and choose correct parameters in accordance with Section 4.1.2 of [RFC8446]. If the ServerHello message is received, the client proceeds to the next step. In other cases, the client MUST terminate the connection with the "unexpected_message" alert. 5. Extracts curve E_res and ephemeral key Q_S^res, res in {1, ..., R}, from the ServerHello message and checks whether Q_S^res belongs to E_res. If this check fails, the client MUST terminate the connection with "handshake_failure" alert. 6. Generates Q^ECDHE: Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_C^res) * Q_S^res. 7. The client MUST check whether the calculated shared secret Q^ECDHE is not equal to the zero point O_res. If this check fails, the client MUST terminate the connection with "handshake_failure" alert. 8. The ECDHE shared secret is the byte representation of the coordinate X^ECDHE of the point Q^ECDHE in the little-endian format: Smyshlyaev, et al. Expires 15 March 2023 [Page 15] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 ECDHE = str_{coordinate_length}(X^ECDHE), where the coordinate_length value is defined by the particular elliptic curve (see Section 6.1.2). 6.1.1.2. ECDHE Shared Secret Calculation on Server Side Upon receiving the ClientHello message, the server calculates ECDHE shared secret in accordance with the following steps: 1. Chooses the curve E_res, res in {1, ..., R}, from the list of the curves E_1, ..., E_R indicated in the "supported_groups" extension in the ClientHello message and the corresponding public ephemeral key Q_C^res from the list Q_C^{i_1}, ..., Q_C^{i_r}, 1 <= i_1 <= i_r <= R, indicated in the "key_share" extension. If the corresponding public ephemeral key is not found (res in {1, ..., R}\{i_1, ..., i_r}), the server MUST send the HelloRetryRequest message with the "key_share" extension indicating the selected elliptic curve E_res and wait for the new ClientHello message. 2. Checks whether Q_C^res belongs to E_res. If this check fails, the server MUST terminate the connection with "handshake_failure" alert. 3. Generates ephemeral key pair (d_S^res, Q_S^res) corresponding to E_res: * d_S^res is chosen from {1, ..., q_res - 1} at random; * Q_S^res = d_S^res * P_res. 4. Sends the ServerHello message generated in accordance with Section 4.1.3 of [RFC8446] and Section 6.3.1 with the "key_share" extension which contains public ephemeral key Q_S^res corresponding to E_res. 5. Generates Q^ECDHE: Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_S^res) * Q_C^res. 6. The server MUST check whether the calculated shared secret Q^ECDHE is not equal to the zero point O_res. If this check fails, the server MUST abort the handshake with "handshake_failure" alert. 7. The ECDHE shared secret is the byte representation of the coordinate X^ECDHE of the point Q^ECDHE in the little-endian format: ECDHE = str_{coordinate_length}(X^ECDHE), Smyshlyaev, et al. Expires 15 March 2023 [Page 16] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 where the coordinate_length value is defined by the particular elliptic curve (see Section 6.1.2). 6.1.1.3. Public ephemeral key representation This section defines the representation format of the public ephemeral keys generated during the ECDHE shared secret calculation (see Section 6.1.1.1 and Section 6.1.1.2). If the TLS13_GOST profile is used and ECDHE or PSK with ECDHE key exchange mode is used, the public ephemeral key Q indicated in the KeyShareEntry.key_exchange field MUST contain the data defined by the following structure: struct { opaque X[coordinate_length]; opaque Y[coordinate_length]; } PlainPointRepresentation; where X and Y, respectively, contain the byte representations of x and y values of the point Q (Q = (x, y)) in the little-endian format and are specified as follows: X = str_{coordinate_length}(x); Y = str_{coordinate_length}(y). The coordinate_length value is defined by the particular elliptic curve (see Section 6.1.2). 6.1.2. Values for the TLS Supported Groups Registry The "supported_groups" extension is used to indicate the set of the elliptic curves supported by an endpoint and is defined in Section 4.2.7 [RFC8446]. This extension is always contained in the ClientHello message and optionally in the EncryptedExtensions message. This section defines the following seven elliptic curves: enum { GC256A(0x22), GC256B(0x23), GC256C(0x24), GC256D(0x25), GC512A(0x26), GC512B(0x27), GC512C(0x28) } NamedGroup; Smyshlyaev, et al. Expires 15 March 2023 [Page 17] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 If the TLS13_GOST profile is used and ECDHE or PSK with ECDHE key exchange mode is used, one of the elliptic curves listed above SHOULD be used. Each curve corresponds to the particular identifier and specifies the value of coordinate_length parameter (see "cl" column) as follows: +-----------+--------------------------------------+----+---------+ |Description| Curve Identifier Value | cl |Reference| +-----------+--------------------------------------+----+---------+ | GC256A | id-tc26-gost-3410-2012-256-paramSetA | 32 | RFC 7836| +-----------+--------------------------------------+----+---------+ | GC256B |id-GostR3410-2001-CryptoPro-A-ParamSet| 32 | RFC 4357| +-----------+--------------------------------------+----+---------+ | GC256C |id-GostR3410-2001-CryptoPro-B-ParamSet| 32 | RFC 4357| +-----------+--------------------------------------+----+---------+ | GC256D |id-GostR3410-2001-CryptoPro-C-ParamSet| 32 | RFC 4357| +-----------+--------------------------------------+----+---------+ | GC512A | id-tc26-gost-3410-12-512-paramSetA | 64 | RFC 7836| +-----------+--------------------------------------+----+---------+ | GC512B | id-tc26-gost-3410-12-512-paramSetB | 64 | RFC 7836| +-----------+--------------------------------------+----+---------+ | GC512C | id-tc26-gost-3410-2012-512-paramSetC | 64 | RFC 7836| +-----------+--------------------------------------+----+---------+ Table 5 Note: The identifier values and the corresponding elliptic curves are the same as in [RFC9189]. 6.2. Authentication In accordance with [RFC8446], authentication can be performed via a signature with a certificate or via a symmetric pre-shared key (PSK). The server side is always authenticated; the client side is optionally authenticated. PSK-based authentication is performed as a side effect of key exchange. If the TLS13_GOST profile is used, external PSKs SHOULD be combined only with the mutual authentication (see more in Section 9). Smyshlyaev, et al. Expires 15 March 2023 [Page 18] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 Certificate-based authentication is performed via Authentication messages and optional CertificateRequest message (sent if client authentication is required). If the TLS13_GOST profile is used, the signature schemes used for certificate-based authentication are defined in Section 5 and Authentication messages are specified in Section 6.3.3 and Section 6.3.4. The CertificateRequest message is specified in Section 6.3.2. 6.3. Handshake Messages The TLS13_GOST profile specifies the ClientHello, ServerHello, CertificateRequest, Certificate and CertificateVerify handshake messages that are described in further detail below. 6.3.1. Hello Messages The ClientHello message is sent when the client first connects to the server or responds to the HelloRetryRequest message and is specified in accordance with Section 4.1.2 of [RFC8446]. If the TLS13_GOST profile is used, the ClientHello message MUST meet the following requirements. * The ClientHello.cipher_suites field MUST contain the values defined in Section 4. * If server authentication via a certificate is required, the extension_data field of the "signature_algorithms" extension MUST contain the values defined in Section 5, which correspond to the GOST R 34.10-2012 signature algorithm. * If server authentication via a certificate is required and the client uses optional "signature_algorithms_cert" extension, the extension_data field of this extension SHOULD contain the values defined in Section 5, which correspond to the GOST R 34.10-2012 signature algorithm. * If the client wants to establish a TLS 1.3 connection using ECDHE shared secret, the extension_data field of the "supported_groups" extension MUST contain the elliptic curve identifiers defined in Section 6.1.2. The ServerHello message is sent by the server in response to the ClientHello message to negotiate an acceptable set of handshake parameters based on the ClientHello message and is specified in accordance with Section 4.1.3 of [RFC8446]. Smyshlyaev, et al. Expires 15 March 2023 [Page 19] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 If the TLS13_GOST profile is used, the ServerHello message MUST meet the following requirements. * The ServerHello.cipher_suite field MUST contain one of the values defined in Section 4. * If the server decides to establish a TLS 1.3 connection using ECDHE shared secret, the extension_data field of the "key_share" extension MUST contain the elliptic curve identifier and the public ephemeral key that satisfy the following conditions. - The elliptic curve identifier corresponds to the value that was indicated in the "supported_groups" and the "key_share" extensions in the ClientHello message. - The elliptic curve identifier is one of the values defined in Section 6.1.2. - The public ephemeral key corresponds to the elliptic curve specified by the KeyShareEntry.group identifier. 6.3.2. CertificateRequest This message is sent when the server requests client authentication via a certificate and is specified in accordance with Section 4.3.2 of [RFC8446]. If the TLS13_GOST profile is used, the CertificateRequest message MUST meet the following requirements. * The extension_data field of the "signature_algorithms" extension MUST contain only the values defined in Section 5. * If the server uses optional "signature_algorithms_cert" extension, the extension_data field of this extension SHOULD contain only the values defined in Section 5. 6.3.3. Certificate This message is sent to convey the endpoint's certificate chain to the peer and is specified in accordance with Section 4.4.2 of [RFC8446]. If the TLS13_GOST profile is used, the Certificate message MUST meet the following requirements. Smyshlyaev, et al. Expires 15 March 2023 [Page 20] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 * Each endpoint's certificate provided to the peer MUST be signed using the algorithm which corresponds to a signature scheme indicated by the peer in its "signature_algoritms_cert" extension, if present (or in the "signature_algorithms" extension, otherwise). * The signature algorithm used for signing certificates SHOULD correspond to one of the signature schemes defined in Section 5. 6.3.4. CertificateVerify This message is sent to provide explicit proof that the endpoint has the private key corresponding to the public key indicated in its certificate and is specified in accordance with Section 4.4.3 of [RFC8446]. If the TLS13_GOST profile is used, the CertificateVerify message MUST meet the following requirements. * The CertificateVerify.algorithm field MUST contain the signature scheme identifier which corresponds to the value indicated in the peer's "signature_algorithms" extension and which is one of the values defined in Section 5. * The CertificateVerify.signature field contains the sgn value, which is computed as follows: sgn = SIGN(d_sign, M), where - the SIGN function is defined in Section 5.3, - d_sign is the sender's long-term private key that corresponds to the sender's long-term public key Q_sign from the sender's certificate, - the message M is defined in accordance with Section 4.4.3 of [RFC8446]. 7. IANA Considerations IANA has added the following values to the "TLS Cipher Suites" registry: Smyshlyaev, et al. Expires 15 March 2023 [Page 21] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 +----------+-----------------------------+-------+-------------+-----------+ | Value | Description |DTLS-OK| Recommended | Reference | +----------+-----------------------------+-------+-------------+-----------+ |0xC1, 0x03| TLS_GOSTR341112_256_ | N | N | this RFC | | | _WITH_KUZNYECHIK_MGM_L | | | | +----------+-----------------------------+-------+-------------+-----------+ |0xC1, 0x04| TLS_GOSTR341112_256_ | N | N | this RFC | | | _WITH_MAGMA_MGM_L | | | | +----------+-----------------------------+-------+-------------+-----------+ |0xC1, 0x05| TLS_GOSTR341112_256_ | N | N | this RFC | | | _WITH_KUZNYECHIK_MGM_S | | | | +----------+-----------------------------+-------+-------------+-----------+ |0xC1, 0x06| TLS_GOSTR341112_256_ | N | N | this RFC | | | _WITH_MAGMA_MGM_S | | | | +----------+-----------------------------+-------+-------------+-----------+ Table 6 IANA has added the following values to the "TLS SignatureScheme" registry: +-----------+----------------------+---------------+----------+ | Value | Description | Recommended | Reference| +-----------+----------------------+---------------+----------+ | 0x0709 | gostr34102012_256a | N | this RFC | +-----------+----------------------+---------------+----------+ | 0x070A | gostr34102012_256b | N | this RFC | +-----------+----------------------+---------------+----------+ | 0x070B | gostr34102012_256c | N | this RFC | +-----------+----------------------+---------------+----------+ | 0x070C | gostr34102012_256d | N | this RFC | +-----------+----------------------+---------------+----------+ | 0x070D | gostr34102012_512a | N | this RFC | +-----------+----------------------+---------------+----------+ | 0x070E | gostr34102012_512b | N | this RFC | +-----------+----------------------+---------------+----------+ | 0x070F | gostr34102012_512c | N | this RFC | +-----------+----------------------+---------------+----------+ Table 7 8. Historical considerations Due to historical reasons in addition to the curve identifier values listed in Table 5 there exist some additional identifier values that correspond to the signature schemes as follows. Smyshlyaev, et al. Expires 15 March 2023 [Page 22] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 +--------------------+-------------------------------------------+ | Description | Curve Identifier Value | +--------------------+-------------------------------------------+ | gostr34102012_256b | id-GostR3410-2001-CryptoPro-XchA-ParamSet | | | id-tc26-gost-3410-2012-256-paramSetB | +--------------------+-------------------------------------------+ | gostr34102012_256c | id-tc26-gost-3410-2012-256-paramSetC | +--------------------+-------------------------------------------+ | gostr34102012_256d | id-GostR3410-2001-CryptoPro-XchB-ParamSet | | | id-tc26-gost-3410-2012-256-paramSetD | +--------------------+-------------------------------------------+ Table 8 Client should be prepared to handle any of them correctly if corresponding signature scheme is included in the "signature_algorithms" or "signature_algorithms_cert" extensions. 9. Security Considerations In order to create an efficient and side-channel resistant implementation, while using the TLSTREE algorithm the functions KDF_j, j = 1, 2, 3, SHOULD be called only when necessary (when the record sequence number seqnum reaches such a value that seqnum & C_j != (seqnum - 1) & C_j). Otherwise the previous value should be used. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 2013, . [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: Digital Signature Algorithm", RFC 7091, DOI 10.17487/RFC7091, December 2013, . [RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016, . Smyshlyaev, et al. Expires 15 March 2023 [Page 23] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012", RFC 7836, DOI 10.17487/RFC7836, March 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8645] Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019, . [RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015: Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891, September 2020, . [RFC9058] Smyshlyaev, S., Ed., Nozdrunov, V., Shishkin, V., and E. Griboedova, "Multilinear Galois Mode (MGM)", RFC 9058, DOI 10.17487/RFC9058, June 2021, . [RFC9189] Smyshlyaev, S., Ed., Belyavsky, D., and E. Alekseev, "GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2", RFC 9189, DOI 10.17487/RFC9189, March 2022, . 10.2. Informative References [I-D.ietf-tls-rfc8446bis] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft- ietf-tls-rfc8446bis-04, 7 March 2022, . Appendix A. Test Examples A.1. Example 1 Smyshlyaev, et al. Expires 15 March 2023 [Page 24] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 A.1.1. Test case Test examples are given for the following order of using the TLS13_GOST profile. 1. Full TLS Handshake is used. 2. ECDHE key exchange mode is used. The elliptic curve GC512C is used for ECDHE shared secret calculation. 3. The server side only authentication is used. The signature scheme gost34102012_256b is used. 4. TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S cipher suite is negotiated. 5. Application Data is sent by the server prior to receiving the Finished message from the client. 6. NewSessionTicket is sent after establishing a secure connection. 7. Nine Application Data records are sent during the operation of the Record protocol. The sequence numbers are selected to demonstrate the operation of the TLSTREE function. 8. Alert protocol is used for closure of the connection. A.1.2. Test examples ---------------------------Client--------------------------- ClientHello message: msg_type: 01 length: 0000DE body: legacy_version: 0303 random: 03030303030303030303030303030303 03030303030303030303030303030303 legasy_session_id: length: 00 vector: -- cipher_suites: length: 0002 vector: CipherSuite: C105 compression_methods: Smyshlyaev, et al. Expires 15 March 2023 [Page 25] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 length: 01 vector: CompressionMethod: 00 extensions: length: 00B3 vector: Extension: /* supported_groups */ extension_type: 000A extension_data: length: 0004 vector: named_group_list: length: 0002 vector: /* GC512C */ 0028 Extension: /* signature_algorithms */ extension_type: 000D extension_data: length: 0010 vector: supported_signature_algorithms: length: 000E vector: /* gost34102012256a */ 0709 /* gost34102012256b */ 070A /* gost34102012256c */ 070B /* gost34102012256d */ 070C /* gost34102012512a */ 070D /* gost34102012512b */ 070E /* gost34102012512c */ 070F Extension: /* supported_versions */ extension_type: 002B extension_data: length: 0003 vector: versions: length: 02 vector: 0304 Extension: /* psk_key_exchange_modes */ Smyshlyaev, et al. Expires 15 March 2023 [Page 26] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 extension_type: 002D extension_data: length: 0002 vector: ke_modes: length: 01 vector: /* psk_ke */ 00 Extension: /* key_share */ extension_type: 0033 extension_data: length: 0086 vector: length: 0084 vector: group: 0028 key_exchange: length: 0080 vector: 05EEBDF3DDC1D2F5F3822433241284E7 7641487938EA88721F26203E9792B5CB 97EB70EF02E8F72B7491D4F2CFDC332A DF7F1778E854A88DDC2113FEC527A151 71A04CB0C573793A7AEF9BBCA486B6B0 46B2149B46F4332903E5B7C438ADD05E 185EFBF45557475A8CCBF6ACED1A2EB4 16F916729D7CEF9CBD8334989304AFAE 0000: 01 00 00 DE 03 03 03 03 03 03 03 03 03 03 03 03 0010: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 0020: 03 03 03 03 03 03 00 00 02 C1 05 01 00 00 B3 00 0030: 0A 00 04 00 02 00 28 00 0D 00 10 00 0E 07 09 07 0040: 0A 07 0B 07 0C 07 0D 07 0E 07 0F 00 2B 00 03 02 0050: 03 04 00 2D 00 02 01 00 00 33 00 86 00 84 00 28 0060: 00 80 05 EE BD F3 DD C1 D2 F5 F3 82 24 33 24 12 0070: 84 E7 76 41 48 79 38 EA 88 72 1F 26 20 3E 97 92 0080: B5 CB 97 EB 70 EF 02 E8 F7 2B 74 91 D4 F2 CF DC 0090: 33 2A DF 7F 17 78 E8 54 A8 8D DC 21 13 FE C5 27 00A0: A1 51 71 A0 4C B0 C5 73 79 3A 7A EF 9B BC A4 86 00B0: B6 B0 46 B2 14 9B 46 F4 33 29 03 E5 B7 C4 38 AD 00C0: D0 5E 18 5E FB F4 55 57 47 5A 8C CB F6 AC ED 1A 00D0: 2E B4 16 F9 16 72 9D 7C EF 9C BD 83 34 98 93 04 00E0: AF AE Record layer message: type: 16 legacy_record_version: 0301 Smyshlyaev, et al. Expires 15 March 2023 [Page 27] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 length: 00E2 fragment: 010000DE030303030303030303030303 03030303030303030303030303030303 030303030303000002C105010000B300 0A000400020028000D0010000E070907 0A070B070C070D070E070F002B000302 0304002D000201000033008600840028 008005EEBDF3DDC1D2F5F38224332412 84E77641487938EA88721F26203E9792 B5CB97EB70EF02E8F72B7491D4F2CFDC 332ADF7F1778E854A88DDC2113FEC527 A15171A04CB0C573793A7AEF9BBCA486 B6B046B2149B46F4332903E5B7C438AD D05E185EFBF45557475A8CCBF6ACED1A 2EB416F916729D7CEF9CBD8334989304 AFAE 00000: 16 03 01 00 E2 01 00 00 DE 03 03 03 03 03 03 03 00010: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 00020: 03 03 03 03 03 03 03 03 03 03 03 00 00 02 C1 05 00030: 01 00 00 B3 00 0A 00 04 00 02 00 28 00 0D 00 10 00040: 00 0E 07 09 07 0A 07 0B 07 0C 07 0D 07 0E 07 0F 00050: 00 2B 00 03 02 03 04 00 2D 00 02 01 00 00 33 00 00060: 86 00 84 00 28 00 80 05 EE BD F3 DD C1 D2 F5 F3 00070: 82 24 33 24 12 84 E7 76 41 48 79 38 EA 88 72 1F 00080: 26 20 3E 97 92 B5 CB 97 EB 70 EF 02 E8 F7 2B 74 00090: 91 D4 F2 CF DC 33 2A DF 7F 17 78 E8 54 A8 8D DC 000A0: 21 13 FE C5 27 A1 51 71 A0 4C B0 C5 73 79 3A 7A 000B0: EF 9B BC A4 86 B6 B0 46 B2 14 9B 46 F4 33 29 03 000D0: E5 B7 C4 38 AD D0 5E 18 5E FB F4 55 57 47 5A 8C 000E0: CB F6 AC ED 1A 2E B4 16 F9 16 72 9D 7C EF 9C BD 000F0: 83 34 98 93 04 AF AE ---------------------------Server--------------------------- ServerHello message: msg_type: 02 length: 0000B6 body: legacy_version: 0303 random: 83838383838383838383838383838383 83838383838383838383838383838383 legasy_session_id: length: 00 vector: -- cipher_suite: CipherSuite: C105 Smyshlyaev, et al. Expires 15 March 2023 [Page 28] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 compression_method: CompressionMethod: 00 extensions: length: 008E vector: Extension: /* supported_versions */ extension_type: 002B extension_data: length: 0002 vector: selected_version: 0304 Extension: /* key_share */ extension_type: 0033 extension_data: length: 0084 vector: group: 0028 key_exchange: length: 0080 vector: 2F3C663FE74735A1C421160DF0F43266 185FD30B6E5D6E88FC4061FAEACAB338 B10A1BD20CB0B4EE757E74A0027D409F E937F01633A1E3F9A5518DEFD0F89F9D 3D9F6CC651413DEC2C74366D83C47EE1 DE4E421F65CD1163E94EA0C2E19ED45D 35558B937D9BFDC5ECC2B2A21B4EC3D5 3B29579A8FD5E074811028FBCF17994F 00000: 02 00 00 B6 03 03 83 83 83 83 83 83 83 83 83 83 00010: 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 00020: 83 83 83 83 83 83 00 C1 05 00 00 8E 00 2B 00 02 00030: 03 04 00 33 00 84 00 28 00 80 2F 3C 66 3F E7 47 00040: 35 A1 C4 21 16 0D F0 F4 32 66 18 5F D3 0B 6E 5D 00050: 6E 88 FC 40 61 FA EA CA B3 38 B1 0A 1B D2 0C B0 00060: B4 EE 75 7E 74 A0 02 7D 40 9F E9 37 F0 16 33 A1 00070: E3 F9 A5 51 8D EF D0 F8 9F 9D 3D 9F 6C C6 51 41 00080: 3D EC 2C 74 36 6D 83 C4 7E E1 DE 4E 42 1F 65 CD 00090: 11 63 E9 4E A0 C2 E1 9E D4 5D 35 55 8B 93 7D 9B 000A0: FD C5 EC C2 B2 A2 1B 4E C3 D5 3B 29 57 9A 8F D5 000B0: E0 74 81 10 28 FB CF 17 99 4F Record layer message: type: 16 legacy_record_version: 0303 length: 00BA fragment: 020000B6030383838383838383838383 Smyshlyaev, et al. Expires 15 March 2023 [Page 29] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 83838383838383838383838383838383 83838383838300C10500008E002B0002 030400330084002800802F3C663FE747 35A1C421160DF0F43266185FD30B6E5D 6E88FC4061FAEACAB338B10A1BD20CB0 B4EE757E74A0027D409FE937F01633A1 E3F9A5518DEFD0F89F9D3D9F6CC65141 3DEC2C74366D83C47EE1DE4E421F65CD 1163E94EA0C2E19ED45D35558B937D9B FDC5ECC2B2A21B4EC3D53B29579A8FD5 E074811028FBCF17994F 00000: 16 03 03 00 BA 02 00 00 B6 03 03 83 83 83 83 83 00010: 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 00020: 83 83 83 83 83 83 83 83 83 83 83 00 C1 05 00 00 00030: 8E 00 2B 00 02 03 04 00 33 00 84 00 28 00 80 2F 00040: 3C 66 3F E7 47 35 A1 C4 21 16 0D F0 F4 32 66 18 00050: 5F D3 0B 6E 5D 6E 88 FC 40 61 FA EA CA B3 38 B1 00060: 0A 1B D2 0C B0 B4 EE 75 7E 74 A0 02 7D 40 9F E9 00070: 37 F0 16 33 A1 E3 F9 A5 51 8D EF D0 F8 9F 9D 3D 00080: 9F 6C C6 51 41 3D EC 2C 74 36 6D 83 C4 7E E1 DE 00090: 4E 42 1F 65 CD 11 63 E9 4E A0 C2 E1 9E D4 5D 35 000A0: 55 8B 93 7D 9B FD C5 EC C2 B2 A2 1B 4E C3 D5 3B 000B0: 29 57 9A 8F D5 E0 74 81 10 28 FB CF 17 99 4F ---------------------------Client--------------------------- d_C^res: 00000: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 00010: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 00020: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 00030: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 Q_S^res: 00000: 2F 3C 66 3F E7 47 35 A1 C4 21 16 0D F0 F4 32 66 00010: 18 5F D3 0B 6E 5D 6E 88 FC 40 61 FA EA CA B3 38 00020: B1 0A 1B D2 0C B0 B4 EE 75 7E 74 A0 02 7D 40 9F 00030: E9 37 F0 16 33 A1 E3 F9 A5 51 8D EF D0 F8 9F 9D 00040: 3D 9F 6C C6 51 41 3D EC 2C 74 36 6D 83 C4 7E E1 00050: DE 4E 42 1F 65 CD 11 63 E9 4E A0 C2 E1 9E D4 5D 00060: 35 55 8B 93 7D 9B FD C5 EC C2 B2 A2 1B 4E C3 D5 00070: 3B 29 57 9A 8F D5 E0 74 81 10 28 FB CF 17 99 4F ECDHE: 00000: 4D E6 0D 21 EA 8F B9 22 0D 14 64 23 B4 90 DA 40 00010: CC EB C4 3B C5 89 DB 79 B8 31 A4 7D 6B 06 30 07 00020: DD 03 40 5A 1B 79 76 B6 23 DC AA 69 B0 11 AE 10 00030: 6E 7E 41 74 38 5F 86 26 E1 21 B5 99 43 63 C9 9F Smyshlyaev, et al. Expires 15 March 2023 [Page 30] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 ---------------------------Server--------------------------- d_S^res: 00000: AA 3C A4 F4 A5 0A C0 5B 37 42 B1 35 B5 30 A9 F2 00010: 2A E4 F5 E1 85 30 1D EC 83 2E 77 BA 3B CD 6A F1 00020: 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 00030: 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 04 Q_C^res: 00000: 05 EE BD F3 DD C1 D2 F5 F3 82 24 33 24 12 84 E7 00010: 76 41 48 79 38 EA 88 72 1F 26 20 3E 97 92 B5 CB 00020: 97 EB 70 EF 02 E8 F7 2B 74 91 D4 F2 CF DC 33 2A 00030: DF 7F 17 78 E8 54 A8 8D DC 21 13 FE C5 27 A1 51 00040: 71 A0 4C B0 C5 73 79 3A 7A EF 9B BC A4 86 B6 B0 00050: 46 B2 14 9B 46 F4 33 29 03 E5 B7 C4 38 AD D0 5E 00060: 18 5E FB F4 55 57 47 5A 8C CB F6 AC ED 1A 2E B4 00070: 16 F9 16 72 9D 7C EF 9C BD 83 34 98 93 04 AF AE ECDHE: 00000: 4D E6 0D 21 EA 8F B9 22 0D 14 64 23 B4 90 DA 40 00010: CC EB C4 3B C5 89 DB 79 B8 31 A4 7D 6B 06 30 07 00020: DD 03 40 5A 1B 79 76 B6 23 DC AA 69 B0 11 AE 10 00030: 6E 7E 41 74 38 5F 86 26 E1 21 B5 99 43 63 C9 9F ---------------------------Server--------------------------- EncryptedExtensions message: msg_type: 08 length: 000002 body: extensions: length: 0000 vector: -- 00000: 08 00 00 02 00 00 Record payload protection: EarlySecret = HKDF-Extract(Salt: 0^256, IKM: 0^256): 00000: FB DE FB E5 27 FE EA 66 5A AB 92 77 A2 16 3B 83 00010: 43 08 4F D1 91 C4 60 66 26 0F AC 6F D1 43 6C 72 Derived #0 = Derive-Secret(EarlySecret, "derived", "") = HKDF-Expand-Label(EarlySecret, "derived", "", 32): 00000: DB C3 C8 26 D8 77 A3 B7 D2 D2 45 3D BF DC 6C FB 00010: FB 11 51 B3 E8 4F 0C 8F 26 01 1D 8D 5B F3 ED F7 HandshakeSecret = HKDF-Extract(Salt: Derived #0, IKM: ECDHE): Smyshlyaev, et al. Expires 15 March 2023 [Page 31] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 00000: 44 24 5E 2C 43 32 D1 F7 8B 0F 8D 16 F4 03 EB 69 00010: ED 2A 40 53 84 7C DC 39 FA 8B 3D 29 74 F7 45 E7 HM1 = (ClientHello, ServerHello) TH1 = Transcript-Hash(HM1): 00000: 99 3B A7 22 12 4A F3 CB FD 47 71 E7 FA E3 2A C1 00010: D0 E9 27 8C F7 84 3F CB C6 20 E1 A0 08 5A 87 A1 server_handshake_traffic_secret (SHTS): SHTS = Derive-Secret(HandshakeSecret, "s hs traffic", HM1) = HKDF-Expand-Label(HandshakeSecret, "s hs traffic", TH1, 32): 00000: 70 A5 F2 46 3D F6 0D BA A2 36 8B 67 FD 45 AE FF 00010: 7C 1A 0B A4 2D 8A BD 72 41 5E CD 1D 94 E9 EF 54 server_write_key_hs = HKDF-Expand-Label(SHTS, "key", "", 32): 00000: E1 37 64 B5 4B 9E 1B 47 D4 33 98 D6 D2 16 DF 24 00010: C2 89 A3 96 AB 6C 5B 52 4B BB 9C 06 F3 9F EF 01 server_write_iv_hs = HKDF-Expand-Label(SHTS, "iv", "", 16): 00000: 69 69 FF AA A4 52 52 81 EE BB EB 4C BD 0B 64 0E server_record_write_key = TLSTREE(server_write_key_hs, 0): 00000: 56 EE 18 13 72 72 49 C9 DC DF 35 13 78 7E DB 93 00010: DF 62 C6 1E E7 B1 26 C5 0F 26 C0 AA AF AE 00 E1 seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 nonce: 00000: 69 69 FF AA A4 52 52 81 EE BB EB 4C BD 0B 64 0E additional_data: 00000: 17 03 03 00 17 TLSInnerPlaintext: 00000: 08 00 00 02 00 00 16 TLSCiphertext: 00000: 17 03 03 00 17 94 0E 5D 2C 75 3A E5 FE BD 20 01 00010: 2C C9 E3 EB 24 A3 79 84 1E 02 AB BE Record layer message: type: 17 legacy_record_version: 0303 length: 0017 encrypted_record: 940E5D2C753AE5FEBD20012CC9E3EB24 A379841E02ABBE Smyshlyaev, et al. Expires 15 March 2023 [Page 32] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 00000: 17 03 03 00 17 94 0E 5D 2C 75 3A E5 FE BD 20 01 00010: 2C C9 E3 EB 24 A3 79 84 1E 02 AB BE ---------------------------Server--------------------------- Certificate message: msg_type: 0B length: 000151 body: certificate_request_context: length: 00 vector: -- certificate_list: length: 00014D vector: ASN.1Cert: length: 000148 vector: 308201443081F2A00302010202023039 300A06082A85030701010302301B3119 301706035504031310676F73742E6578 616D706C652E636F6D301E170D323030 3232383131303833375A170D33303032 32353131303833375A301B3119301706 035504031310676F73742E6578616D70 6C652E636F6D305E301706082A850307 01010101300B06092A85030701020101 020343000440F383CEE83048B4EB14C7 1A7F6DE44A37CE11A6AC1750F1CFB8DA D8A38CCDD8FD06656F7CFC075F4083C3 716221478F1EE24C6B1B70CCE3C72AFD 2ACE65C775BCA321301F301D0603551D 0E04160414F330FA7166DF095AF3A073 BC3B8EA356D7DFAC71300A06082A8503 0701010302034100AB2EDA23F49B4862 3B0CFF5906B7DD3C23B473570B296A08 71DD15EF9A33201B97904A5CFA6C931C 5473DC0C5A5F2FBB2E50CF587AE27C4D 8E52EB80189DD08B extensions: length: 0000 vector: -- 00000: 0B 00 01 51 00 00 01 4D 00 01 48 30 82 01 44 30 00010: 81 F2 A0 03 02 01 02 02 02 30 39 30 0A 06 08 2A 00020: 85 03 07 01 01 03 02 30 1B 31 19 30 17 06 03 55 00030: 04 03 13 10 67 6F 73 74 2E 65 78 61 6D 70 6C 65 00040: 2E 63 6F 6D 30 1E 17 0D 32 30 30 32 32 38 31 31 00050: 30 38 33 37 5A 17 0D 33 30 30 32 32 35 31 31 30 Smyshlyaev, et al. Expires 15 March 2023 [Page 33] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 00060: 38 33 37 5A 30 1B 31 19 30 17 06 03 55 04 03 13 00070: 10 67 6F 73 74 2E 65 78 61 6D 70 6C 65 2E 63 6F 00080: 6D 30 5E 30 17 06 08 2A 85 03 07 01 01 01 01 30 00090: 0B 06 09 2A 85 03 07 01 02 01 01 02 03 43 00 04 000A0: 40 F3 83 CE E8 30 48 B4 EB 14 C7 1A 7F 6D E4 4A 000B0: 37 CE 11 A6 AC 17 50 F1 CF B8 DA D8 A3 8C CD D8 000C0: FD 06 65 6F 7C FC 07 5F 40 83 C3 71 62 21 47 8F 000D0: 1E E2 4C 6B 1B 70 CC E3 C7 2A FD 2A CE 65 C7 75 000E0: BC A3 21 30 1F 30 1D 06 03 55 1D 0E 04 16 04 14 000F0: F3 30 FA 71 66 DF 09 5A F3 A0 73 BC 3B 8E A3 56 00100: D7 DF AC 71 30 0A 06 08 2A 85 03 07 01 01 03 02 00110: 03 41 00 AB 2E DA 23 F4 9B 48 62 3B 0C FF 59 06 00120: B7 DD 3C 23 B4 73 57 0B 29 6A 08 71 DD 15 EF 9A 00130: 33 20 1B 97 90 4A 5C FA 6C 93 1C 54 73 DC 0C 5A 00140: 5F 2F BB 2E 50 CF 58 7A E2 7C 4D 8E 52 EB 80 18 00150: 9D D0 8B 00 00 Record payload protection: server_record_write_key = TLSTREE(server_write_key_hs, 1): 00000: 56 EE 18 13 72 72 49 C9 DC DF 35 13 78 7E DB 93 00010: DF 62 C6 1E E7 B1 26 C5 0F 26 C0 AA AF AE 00 E1 seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 nonce: 00000: 69 69 FF AA A4 52 52 81 EE BB EB 4C BD 0B 64 0F additional_data: 00000: 17 03 03 01 66 TLSInnerPlaintext: 00000: 0B 00 01 51 00 00 01 4D 00 01 48 30 82 01 44 30 00010: 81 F2 A0 03 02 01 02 02 02 30 39 30 0A 06 08 2A 00020: 85 03 07 01 01 03 02 30 1B 31 19 30 17 06 03 55 00030: 04 03 13 10 67 6F 73 74 2E 65 78 61 6D 70 6C 65 00040: 2E 63 6F 6D 30 1E 17 0D 32 30 30 32 32 38 31 31 00050: 30 38 33 37 5A 17 0D 33 30 30 32 32 35 31 31 30 00060: 38 33 37 5A 30 1B 31 19 30 17 06 03 55 04 03 13 00070: 10 67 6F 73 74 2E 65 78 61 6D 70 6C 65 2E 63 6F 00080: 6D 30 5E 30 17 06 08 2A 85 03 07 01 01 01 01 30 00090: 0B 06 09 2A 85 03 07 01 02 01 01 02 03 43 00 04 000A0: 40 F3 83 CE E8 30 48 B4 EB 14 C7 1A 7F 6D E4 4A 000B0: 37 CE 11 A6 AC 17 50 F1 CF B8 DA D8 A3 8C CD D8 000C0: FD 06 65 6F 7C FC 07 5F 40 83 C3 71 62 21 47 8F 000D0: 1E E2 4C 6B 1B 70 CC E3 C7 2A FD 2A CE 65 C7 75 000E0: BC A3 21 30 1F 30 1D 06 03 55 1D 0E 04 16 04 14 Smyshlyaev, et al. Expires 15 March 2023 [Page 34] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 000F0: F3 30 FA 71 66 DF 09 5A F3 A0 73 BC 3B 8E A3 56 00100: D7 DF AC 71 30 0A 06 08 2A 85 03 07 01 01 03 02 00110: 03 41 00 AB 2E DA 23 F4 9B 48 62 3B 0C FF 59 06 00120: B7 DD 3C 23 B4 73 57 0B 29 6A 08 71 DD 15 EF 9A 00130: 33 20 1B 97 90 4A 5C FA 6C 93 1C 54 73 DC 0C 5A 00140: 5F 2F BB 2E 50 CF 58 7A E2 7C 4D 8E 52 EB 80 18 00150: 9D D0 8B 00 00 16 Record layer message: type: 17 legacy_record_version: 0303 length: 0166 encrypted_record: F57944FE9A599A76E7FE9C26E3FCE5BB AC4DDCF68EF2E77624E33E80B6743E39 10502EE419A219B3BB6A1712D15458BB 897D3DAC7A48769945C89237DFB86620 CC31C456B4374B075905E42AB5333742 3463819982DC6D76A067C4FD83BD3E47 9CD9B7FD2926A5A63B1E88B1525DB976 C7F409190F955AE9F0AC5F976A471F23 675DEB9B24E162D24F494ECDC483A070 7129F3BD17D0FAC4944F2B3BF140D616 D654709297495B23898893B211505856 EEC1A96BC4DCF78A016798E5500D662C 54A74BDF6A7F300AC9B72299B4F15F6F 449F396CE1D0C9243CBC1C86BECD5CAB BFDF50197B7AFF4BE903D7E3311B729B C32D09D2D0DCE06622985AE037DC2F87 CB0C492F2D5106B259CC86E227CC8338 C1DF6C63576B17DB9655FD255F156E1F 4F767FAFB74471731E4225256818DE94 64218263D7CF7B87EB5222E76DE6C951 E462CCCCC53E06387BB4FEDEFD34B9C1 3AB4EE3D49057CD2672F852A5F692408 29B92341CDC9 TLSCiphertext: 00000: 17 03 03 01 66 F5 79 44 FE 9A 59 9A 76 E7 FE 9C 00010: 26 E3 FC E5 BB AC 4D DC F6 8E F2 E7 76 24 E3 3E 00020: 80 B6 74 3E 39 10 50 2E E4 19 A2 19 B3 BB 6A 17 00030: 12 D1 54 58 BB 89 7D 3D AC 7A 48 76 99 45 C8 92 00040: 37 DF B8 66 20 CC 31 C4 56 B4 37 4B 07 59 05 E4 00050: 2A B5 33 37 42 34 63 81 99 82 DC 6D 76 A0 67 C4 00060: FD 83 BD 3E 47 9C D9 B7 FD 29 26 A5 A6 3B 1E 88 00070: B1 52 5D B9 76 C7 F4 09 19 0F 95 5A E9 F0 AC 5F 00080: 97 6A 47 1F 23 67 5D EB 9B 24 E1 62 D2 4F 49 4E 00090: CD C4 83 A0 70 71 29 F3 BD 17 D0 FA C4 94 4F 2B 000A0: 3B F1 40 D6 16 D6 54 70 92 97 49 5B 23 89 88 93 Smyshlyaev, et al. Expires 15 March 2023 [Page 35] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 000B0: B2 11 50 58 56 EE C1 A9 6B C4 DC F7 8A 01 67 98 000C0: E5 50 0D 66 2C 54 A7 4B DF 6A 7F 30 0A C9 B7 22 000D0: 99 B4 F1 5F 6F 44 9F 39 6C E1 D0 C9 24 3C BC 1C 000E0: 86 BE CD 5C AB BF DF 50 19 7B 7A FF 4B E9 03 D7 000F0: E3 31 1B 72 9B C3 2D 09 D2 D0 DC E0 66 22 98 5A 00100: E0 37 DC 2F 87 CB 0C 49 2F 2D 51 06 B2 59 CC 86 00110: E2 27 CC 83 38 C1 DF 6C 63 57 6B 17 DB 96 55 FD 00120: 25 5F 15 6E 1F 4F 76 7F AF B7 44 71 73 1E 42 25 00130: 25 68 18 DE 94 64 21 82 63 D7 CF 7B 87 EB 52 22 00140: E7 6D E6 C9 51 E4 62 CC CC C5 3E 06 38 7B B4 FE 00150: DE FD 34 B9 C1 3A B4 EE 3D 49 05 7C D2 67 2F 85 00160: 2A 5F 69 24 08 29 B9 23 41 CD C9 ---------------------------Server--------------------------- HMCertificateVerify = (ClientHello, ServerHello, EncryptedExtensions, Certificate) Transcript-Hash(HMCertificateVerify): 00000: E0 CC 4B C1 4B EC 5D 13 19 2C DC 66 22 B4 FD A9 00010: 67 6A 1B 50 E4 56 83 0B B5 F0 7E 01 21 22 73 06 k (random for signature algorithm): 00000: 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 00010: 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 sgn: 00000: A0 AA 13 91 5C 5B 80 C6 02 E2 FD 85 80 4F 99 2C 00010: 77 15 97 AD 37 85 7A D6 BC 2A 9D 7B C5 FE BE C3 00020: 7C 72 94 BA A2 3C F6 9D 03 E4 71 0B D7 08 13 FD 00030: AC 59 6B C1 58 E7 56 BD 37 1C 44 2E 95 22 DE 87 CertificateVerify message: msg_type: 0F length: 000044 body: algorithm: 070A signature: length: 0040 vector: A0AA13915C5B80C602E2FD85804F992C 771597AD37857AD6BC2A9D7BC5FEBEC3 7C7294BAA23CF69D03E4710BD70813FD AC596BC158E756BD371C442E9522DE87 00000: 0F 00 00 44 07 0A 00 40 A0 AA 13 91 5C 5B 80 C6 00010: 02 E2 FD 85 80 4F 99 2C 77 15 97 AD 37 85 7A D6 00020: BC 2A 9D 7B C5 FE BE C3 7C 72 94 BA A2 3C F6 9D Smyshlyaev, et al. Expires 15 March 2023 [Page 36] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 00030: 03 E4 71 0B D7 08 13 FD AC 59 6B C1 58 E7 56 BD 00040: 37 1C 44 2E 95 22 DE 87 Record payload protection: server_record_write_key = TLSTREE(server_write_key_hs, 2): 00000: 56 EE 18 13 72 72 49 C9 DC DF 35 13 78 7E DB 93 00010: DF 62 C6 1E E7 B1 26 C5 0F 26 C0 AA AF AE 00 E1 seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 nonce: 00000: 69 69 FF AA A4 52 52 81 EE BB EB 4C BD 0B 64 0C additional_data: 00000: 17 03 03 00 59 TLSInnerPlaintext: 00000: 0F 00 00 44 07 0A 00 40 A0 AA 13 91 5C 5B 80 C6 00010: 02 E2 FD 85 80 4F 99 2C 77 15 97 AD 37 85 7A D6 00020: BC 2A 9D 7B C5 FE BE C3 7C 72 94 BA A2 3C F6 9D 00030: 03 E4 71 0B D7 08 13 FD AC 59 6B C1 58 E7 56 BD 00040: 37 1C 44 2E 95 22 DE 87 16 Record layer message: type: 17 legacy_record_version: 0303 length: 0059 encrypted_record: 52631D5BFDF48254BDFB5F9E02A6A527 0163BCE1E0D818E8D74176535C6CDD25 2DE065AE77984A65ADBA036D59CF45B9 A0047BABCCD0B28044D34BCFD09E6E46 27044B26FE5CA734FCB08607146F41A8 71C3F95384B48ADABC TLSCiphertext: 00000: 17 03 03 00 59 52 63 1D 5B FD F4 82 54 BD FB 5F 00010: 9E 02 A6 A5 27 01 63 BC E1 E0 D8 18 E8 D7 41 76 00020: 53 5C 6C DD 25 2D E0 65 AE 77 98 4A 65 AD BA 03 00030: 6D 59 CF 45 B9 A0 04 7B AB CC D0 B2 80 44 D3 4B 00040: CF D0 9E 6E 46 27 04 4B 26 FE 5C A7 34 FC B0 86 00050: 07 14 6F 41 A8 71 C3 F9 53 84 B4 8A DA BC ---------------------------Server--------------------------- server_finished_key = HKDF-Expand-Label(SHTS, "finished", "", 32): 00000: 53 F1 C0 38 8F 8A 70 C0 BC A0 DD 21 A0 30 F2 38 Smyshlyaev, et al. Expires 15 March 2023 [Page 37] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 00010: 1C 34 37 CD 0E 7E C9 3D 0A 96 5E 25 63 2D D7 9A HMFinished = (ClientHello, ServerHello, EncryptedExtensions Certificate, CertificateVerify) Transcript-Hash(HMFinished): 00000: 03 EC 9B 1D 0B 37 41 42 45 72 BA C9 DF 3A A5 2C 00010: 03 EF E9 E9 58 07 69 43 AF D8 58 19 BC 60 2F 46 FinishedHash = HMAC(server_finished_key,Transcript-Hash(HMFinished)): 00000: E0 BA A3 36 14 E0 69 69 7E 4D FA B0 71 B9 72 57 00010: 73 F8 FE 1A 32 6A 66 2D 0F 52 30 9B 45 B6 E0 31 Finished message: msg_type: 14 length: 000020 body: verify_data: E0BAA33614E069697E4DFAB071B97257 73F8FE1A326A662D0F52309B45B6E031 00000: 14 00 00 20 E0 BA A3 36 14 E0 69 69 7E 4D FA B0 00010: 71 B9 72 57 73 F8 FE 1A 32 6A 66 2D 0F 52 30 9B 00020: 45 B6 E0 31 Record payload protection: server_record_write_key = TLSTREE(server_write_key_hs, 3): 00000: 56 EE 18 13 72 72 49 C9 DC DF 35 13 78 7E DB 93 00010: DF 62 C6 1E E7 B1 26 C5 0F 26 C0 AA AF AE 00 E1 seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 nonce: 00000: 69 69 FF AA A4 52 52 81 EE BB EB 4C BD 0B 64 0D additional_data: 00000: 17 03 03 00 35 TLSInnerPlaintext: 00000: 14 00 00 20 E0 BA A3 36 14 E0 69 69 7E 4D FA B0 00010: 71 B9 72 57 73 F8 FE 1A 32 6A 66 2D 0F 52 30 9B 00020: 45 B6 E0 31 16 Record layer message: type: 17 legacy_record_version: 0303 Smyshlyaev, et al. Expires 15 March 2023 [Page 38] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 length: 0035 encrypted_record: 57B1706C4918F67EACCA457F7D5B537C CE5036B4004C778022B97EE802320398 119404506680ADD7D6A6CD7C8153B755 3C6E646AD6 TLSCiphertext: 00000: 17 03 03 00 35 57 B1 70 6C 49 18 F6 7E AC CA 45 00010: 7F 7D 5B 53 7C CE 50 36 B4 00 4C 77 80 22 B9 7E 00020: E8 02 32 03 98 11 94 04 50 66 80 AD D7 D6 A6 CD 00030: 7C 81 53 B7 55 3C 6E 64 6A D6 ---------------------------Server--------------------------- Application Data: HELO gost.example.com\r\n Record payload protection: Derived #1 = Derive-Secret(HandshakeSecret, "derived", "") = HKDF-Expand-Label(HandshakeSecret, "derived", "", 32): 00000: EA 3C 54 BB D1 4E F9 D7 50 77 6F AB E3 95 BE 2A 00010: BD DB BB B7 1C 13 C2 BD 60 9E 35 15 79 4A FA 02 MainSecret = HKDF-Extract(Salt: Derived #1, IKM: 0^256): 00000: 31 BB 1D 61 2C CD 53 32 68 8A 55 1A 48 CA 25 0F 00010: 24 78 3D 4A B0 B4 A7 6D 3F E5 06 7A 26 16 A4 A3 HM2 = (ClientHello, ServerHello, EncryptedExtensions, Certificate, CertificateVerify, Server Finished) TH2 = Transcript-Hash(HM2): 00000: 9E BC 5F BE 32 D9 F4 0D 48 F8 EE CE BB 62 31 A5 00010: 33 C2 C0 EF 24 32 77 B9 6D 6F 7A D3 BB FD 14 94 server_application_traffic_secret (SATS): SATS = Derive-Secret(MainSecret, "s ap traffic", HM2) = HKDF-Expand-Label(MainSecret, "s ap traffic", TH2, 32): 00000: 87 73 4F 4B 4C FD 17 B9 7B 83 4D 82 2D 9D 73 79 00010: F6 F5 E0 3B 80 B5 2A EB 2A FF 51 0E DD 83 DB D2 server_write_key_ap = HKDF-Expand-Label(SATS, "key", "", 32): 00000: 47 5E 4C 51 4C C6 31 8C 3A 5F 00 0F 12 65 BD 1A 00010: B5 F0 DE 1A F3 57 ED 00 79 EC 5F F0 AF BD 03 0C server_write_iv_ap = HKDF-Expand-Label(SATS, "iv", "", 16): 00000: AF E9 1F 71 18 35 40 26 31 7E 1A B4 D8 22 17 B8 server_record_write_key = TLSTREE(server_write_key_ap, 0): Smyshlyaev, et al. Expires 15 March 2023 [Page 39] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 00000: C8 FC 93 D7 C5 86 F2 B0 A3 10 1B AA 6A 97 9E 4E 00010: 38 86 70 65 51 E8 11 87 E9 78 80 40 9C 7E 8E E9 seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 nonce: 00000: 2F E9 1F 71 18 35 40 26 31 7E 1A B4 D8 22 17 B8 additional_data: 00000: 17 03 03 00 28 TLSInnerPlaintext: 00000: 48 45 4C 4F 20 67 6F 73 74 2E 65 78 61 6D 70 6C 00010: 65 2E 63 6F 6D 0D 0A 17 Record layer message: type: 17 legacy_record_version: 0303 length: 0028 encrypted_record: ABB8C372C79681DCE5C3C909DD039D59 8161FD3E6CE5D6F9CA5715BD6B5C1824 7FB26AC1AB396A4E TLSCiphertext: 00000: 17 03 03 00 28 AB B8 C3 72 C7 96 81 DC E5 C3 C9 00010: 09 DD 03 9D 59 81 61 FD 3E 6C E5 D6 F9 CA 57 15 00020: BD 6B 5C 18 24 7F B2 6A C1 AB 39 6A 4E ---------------------------Client--------------------------- client_finished_key = HKDF-Expand-Label(CHTS, "finished", "", 32): 00000: 2F 21 54 8C F5 27 78 69 AE 49 0D E7 BC 15 AC E6 00010: 39 F6 57 E3 58 2A 5A 63 4B 0A 91 56 95 D5 4C 42 HM2 = (ClientHello, ServerHello, EncryptedExtensions, Certificate, CertificateVerify, Server Finished) TH2 = Transcript-Hash(HM2): 00000: 9E BC 5F BE 32 D9 F4 0D 48 F8 EE CE BB 62 31 A5 00010: 33 C2 C0 EF 24 32 77 B9 6D 6F 7A D3 BB FD 14 94 FinishedHash = HMAC(client_finished_key, TH2): 00000: 08 5F C7 FD 79 B6 D1 11 CD 8D 3F F6 B2 3A 06 5A 00010: 7A F7 A6 38 73 42 A5 F3 57 68 14 CD 00 47 19 D2 Finished message: Smyshlyaev, et al. Expires 15 March 2023 [Page 40] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 msg_type: 14 length: 000020 body: verify_data: 085FC7FD79B6D111CD8D3FF6B23A065A 7AF7A6387342A5F3576814CD004719D2 00000: 14 00 00 20 08 5F C7 FD 79 B6 D1 11 CD 8D 3F F6 00010: B2 3A 06 5A 7A F7 A6 38 73 42 A5 F3 57 68 14 CD 00020: 00 47 19 D2 Record payload protection: EarlySecret = HKDF-Extract(Salt: 0^256, IKM: 0^256): 00000: FB DE FB E5 27 FE EA 66 5A AB 92 77 A2 16 3B 83 00010: 43 08 4F D1 91 C4 60 66 26 0F AC 6F D1 43 6C 72 Derived #0 = Derive-Secret(EarlySecret, "derived", "") = HKDF-Expand-Label(EarlySecret, "derived", "", 32): 00000: DB C3 C8 26 D8 77 A3 B7 D2 D2 45 3D BF DC 6C FB 00010: FB 11 51 B3 E8 4F 0C 8F 26 01 1D 8D 5B F3 ED F7 HandshakeSecret = HKDF-Extract(Salt: Derived #0, IKM: ECDHE): 00000: 44 24 5E 2C 43 32 D1 F7 8B 0F 8D 16 F4 03 EB 69 00010: ED 2A 40 53 84 7C DC 39 FA 8B 3D 29 74 F7 45 E7 HM1 = (ClientHello, ServerHello) TH1 = Transcript-Hash(HM1): 00000: 99 3B A7 22 12 4A F3 CB FD 47 71 E7 FA E3 2A C1 00010: D0 E9 27 8C F7 84 3F CB C6 20 E1 A0 08 5A 87 A1 client_handshake_traffic_secret (CHTS): CHTS = Derive-Secret(HandshakeSecret, "c hs traffic", HM1) = HKDF-Expand-Label(HandshakeSecret, "c hs traffic", TH1, 32): 00000: B3 F7 11 3D 35 26 55 4F E6 55 E5 6F AB 79 B1 A0 00010: 3D E3 35 96 E3 30 88 C7 78 37 19 A9 A4 B0 DC CD client_write_key_hs = HKDF-Expand-Label(CHTS, "key", "", 32): 00000: 58 16 88 D7 6E FE 12 2B B5 5F 62 B3 8E F0 1B CC 00010: 8C 88 DB 83 E9 EA 4D 55 D3 89 8C 53 72 1F C3 84 client_write_iv_hs = HKDF-Expand-Label(CHTS, "iv", "", 16): 00000: 43 9A 07 45 3D 0B EA 0C 1D 1B EB 73 8E B5 B8 DD client_record_write_key = TLSTREE(client_write_key_hs, 0): 00000: E1 C5 9B 41 69 D8 96 10 7F 78 45 68 93 A3 75 1E 00010: 15 73 54 3D AD 8C B7 40 69 E6 81 4A 51 3B BB 1C Smyshlyaev, et al. Expires 15 March 2023 [Page 41] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 nonce: 00000: 43 9A 07 45 3D 0B EA 0C 1D 1B EB 73 8E B5 B8 DD additional_data: 00000: 17 03 03 00 35 TLSInnerPlaintext: 00000: 14 00 00 20 08 5F C7 FD 79 B6 D1 11 CD 8D 3F F6 00010: B2 3A 06 5A 7A F7 A6 38 73 42 A5 F3 57 68 14 CD 00020: 00 47 19 D2 16 Record layer message: type: 17 legacy_record_version: 0303 length: 0035 encrypted_record: C9C65EAAB4A80E04849A122EB0CC26A9 CA6B5DD4DB7AD6813949F629FC09E052 2FF7ACDBBA93926C20008B8CCE865422 7B31D439F8 TLSCiphertext: 00000: 17 03 03 00 35 C9 C6 5E AA B4 A8 0E 04 84 9A 12 00010: 2E B0 CC 26 A9 CA 6B 5D D4 DB 7A D6 81 39 49 F6 00020: 29 FC 09 E0 52 2F F7 AC DB BA 93 92 6C 20 00 8B 00030: 8C CE 86 54 22 7B 31 D4 39 F8 ---------------------------Server--------------------------- NewSessionTicket message: msg_type: 04 length: 000035 body: ticket_lifetime: 00093A80 ticket_age_add: 86868686 ticket_nonce: length: 08 vector: 0000000000000000 ticket: length: 0020 vector: 88888888888888888888888888888888 88888888888888888888888888888888 extensions: length: 0000 vector: -- Smyshlyaev, et al. Expires 15 March 2023 [Page 42] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 00000: 04 00 00 35 00 09 3A 80 86 86 86 86 08 00 00 00 00010: 00 00 00 00 00 00 20 88 88 88 88 88 88 88 88 88 00020: 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 00030: 88 88 88 88 88 88 88 00 00 Record payload protection: server_record_write_key = TLSTREE(server_write_key_ap, 1): 00000: C8 FC 93 D7 C5 86 F2 B0 A3 10 1B AA 6A 97 9E 4E 00010: 38 86 70 65 51 E8 11 87 E9 78 80 40 9C 7E 8E E9 seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 nonce: 00000: 2F E9 1F 71 18 35 40 26 31 7E 1A B4 D8 22 17 B9 additional_data: 00000: 17 03 03 00 4A TLSInnerPlaintext: 00000: 04 00 00 35 00 09 3A 80 86 86 86 86 08 00 00 00 00010: 00 00 00 00 00 00 20 88 88 88 88 88 88 88 88 88 00020: 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 00030: 88 88 88 88 88 88 88 00 00 16 Record layer message: type: 17 legacy_record_version: 0303 length: 004A encrypted_record: CA6688A5DC22208DC8A8DE7E597292E3 CB5D454945B8F06C7C50F1823D7B6BB0 021178AE3ADB2DE3994539FD696945CF AA6919F3F1294CD41ED2A8EA75302869 ACB994F3920B09D67186 TLSCiphertext: 00000: 17 03 03 00 4A CA 66 88 A5 DC 22 20 8D C8 A8 DE 00010: 7E 59 72 92 E3 CB 5D 45 49 45 B8 F0 6C 7C 50 F1 00020: 82 3D 7B 6B B0 02 11 78 AE 3A DB 2D E3 99 45 39 00030: FD 69 69 45 CF AA 69 19 F3 F1 29 4C D4 1E D2 A8 00040: EA 75 30 28 69 AC B9 94 F3 92 0B 09 D6 71 86 ---------------------------Server--------------------------- Application data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] Smyshlyaev, et al. Expires 15 March 2023 [Page 43] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Pad: 15360 bytes Record payload protection: server_record_write_key = TLSTREE(server_write_key_ap, 2): 00000: C8 FC 93 D7 C5 86 F2 B0 A3 10 1B AA 6A 97 9E 4E 00010: 38 86 70 65 51 E8 11 87 E9 78 80 40 9C 7E 8E E9 seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 nonce: 00000: 2F E9 1F 71 18 35 40 26 31 7E 1A B4 D8 22 17 BA additional_data: 00000: 17 03 03 40 11 TLSInnerPlaintext: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000400: 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 00004000: 00 Record layer message: type: 17 legacy_record_version: 0303 length: 4011 encrypted_record: 9B3AD6939F05A403EEB1A636E13989D9 1CCA6A45BE5B7CB5C980020627A1B2AD 34AC4B5AAE5BD445C91C28325E4C7149 188D55EF27016D80AF440704820BCE22 CE501EA619A4FF7CD9F722A28391CE8B B86BF87D5A85555BEF59A9C9A1572F38 114E64FD04A0DB2E1787A585EA51DCAB B95DAFB73D0B3FE3F0702C5E1AA01571 17D884783E5E6113F6CA8352F6CF49F9 DB3B3DAB380BFD7BE04B0A [...] 64E7027D926E0F95AB7F133B5921F996 A81EB67B78449DD32F4511E013206524 AD4AFACF0B1C1622282CB20A965E670C C9A17E13F343AF3825AFD58B06915BDC 9E49477F02830694F5AC7CC99C887F62 CDAAEF0053766FB12BC9A082C157C347 21C5400C376088A660EE4329ED645D7C Smyshlyaev, et al. Expires 15 March 2023 [Page 44] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 07D4DA1ABDF6F9A1B9D51BF3E09CFCC1 A59CD96F07FC9ACF004EA1B20E6BBDAD 7BBF0C9E2A1B TLSCiphertext: 00000000: 17 03 03 40 11 9B 3A D6 93 9F 05 A4 03 EE B1 A6 00000010: 36 E1 39 89 D9 1C CA 6A 45 BE 5B 7C B5 C9 80 02 00000020: 06 27 A1 B2 AD 34 AC 4B 5A AE 5B D4 45 C9 1C 28 00000030: 32 5E 4C 71 49 18 8D 55 EF 27 01 6D 80 AF 44 07 00000040: 04 82 0B CE 22 CE 50 1E A6 19 A4 FF 7C D9 F7 22 00000050: A2 83 91 CE 8B B8 6B F8 7D 5A 85 55 5B EF 59 A9 00000060: C9 A1 57 2F 38 11 4E 64 FD 04 A0 DB 2E 17 87 A5 00000070: 85 EA 51 DC AB B9 5D AF B7 3D 0B 3F E3 F0 70 2C 00000080: 5E 1A A0 15 71 17 D8 84 78 3E 5E 61 13 F6 CA 83 00000090: 52 F6 CF 49 F9 DB 3B 3D AB 38 0B FD 7B E0 4B 0A [...] 00003F80: 64 E7 02 7D 92 6E 0F 95 AB 7F 13 3B 59 21 F9 96 00003F90: A8 1E B6 7B 78 44 9D D3 2F 45 11 E0 13 20 65 24 00003FA0: AD 4A FA CF 0B 1C 16 22 28 2C B2 0A 96 5E 67 0C 00003FB0: C9 A1 7E 13 F3 43 AF 38 25 AF D5 8B 06 91 5B DC 00003FC0: 9E 49 47 7F 02 83 06 94 F5 AC 7C C9 9C 88 7F 62 00003FD0: CD AA EF 00 53 76 6F B1 2B C9 A0 82 C1 57 C3 47 00003FE0: 21 C5 40 0C 37 60 88 A6 60 EE 43 29 ED 64 5D 7C 00003FF0: 07 D4 DA 1A BD F6 F9 A1 B9 D5 1B F3 E0 9C FC C1 00004000: A5 9C D9 6F 07 FC 9A CF 00 4E A1 B2 0E 6B BD AD 00004010: 7B BF 0C 9E 2A 1B ---------------------------Server--------------------------- Application data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Pad: 15360 bytes Record payload protection: server_record_write_key = TLSTREE(server_write_key_ap, 3): 00000: C8 FC 93 D7 C5 86 F2 B0 A3 10 1B AA 6A 97 9E 4E 00010: 38 86 70 65 51 E8 11 87 E9 78 80 40 9C 7E 8E E9 seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 nonce: 00000: 2F E9 1F 71 18 35 40 26 31 7E 1A B4 D8 22 17 BB additional_data: Smyshlyaev, et al. Expires 15 March 2023 [Page 45] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 00000: 17 03 03 40 11 TLSInnerPlaintext: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000400: 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 00004000: 00 Record layer message: type: 17 legacy_record_version: 0303 length: 4011 encrypted_record: F06C5032F8A7AD58CED14D5383ED969E 628DE4F35CF9B6FCF5047D9B02261F56 F724DE961F8FF9C27AE76FBAC0A18E96 AA30CA7D8EBAD5B5135A0962515CC4F2 A16EBAB9A08886ED4EFD9DFAEC158F94 EFB0F90725C9114D9D8D904A18ABF184 E74B07150B2F2F27CB8032064943C957 11E480E4F4FCE8E9F020D5C90489E734 AEA10D91C7097AEC8CD6D5E3EEC764B0 CD447FC07735F0F8D9D490 [...] 3A79E7B3BCFD2B2478092911073A7CC9 6AC626C30DD0A5612DBBFF26E35AF0BB 5CEC24EED391100533FB999D4873ED5D 5E4693C5EEDC3ECC3C6EFF041B0A7F42 25A1092F4AADD9A508C7A56CB13A3F33 E844E28C8ADCD45250F4EE29834C5CAA C50B5EBF94501785664E78AE9B5FDBFA DF730DED97985D659135F5DABAD883FF AC6046A0F629881F76147646D8E2A867 3B14295621F7 TLSCiphertext: 00000000: 17 03 03 40 11 F0 6C 50 32 F8 A7 AD 58 CE D1 4D 00000010: 53 83 ED 96 9E 62 8D E4 F3 5C F9 B6 FC F5 04 7D 00000020: 9B 02 26 1F 56 F7 24 DE 96 1F 8F F9 C2 7A E7 6F 00000030: BA C0 A1 8E 96 AA 30 CA 7D 8E BA D5 B5 13 5A 09 00000040: 62 51 5C C4 F2 A1 6E BA B9 A0 88 86 ED 4E FD 9D 00000050: FA EC 15 8F 94 EF B0 F9 07 25 C9 11 4D 9D 8D 90 00000060: 4A 18 AB F1 84 E7 4B 07 15 0B 2F 2F 27 CB 80 32 00000070: 06 49 43 C9 57 11 E4 80 E4 F4 FC E8 E9 F0 20 D5 00000080: C9 04 89 E7 34 AE A1 0D 91 C7 09 7A EC 8C D6 D5 00000090: E3 EE C7 64 B0 CD 44 7F C0 77 35 F0 F8 D9 D4 90 Smyshlyaev, et al. Expires 15 March 2023 [Page 46] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 [...] 00003F80: 3A 79 E7 B3 BC FD 2B 24 78 09 29 11 07 3A 7C C9 00003F90: 6A C6 26 C3 0D D0 A5 61 2D BB FF 26 E3 5A F0 BB 00003FA0: 5C EC 24 EE D3 91 10 05 33 FB 99 9D 48 73 ED 5D 00003FB0: 5E 46 93 C5 EE DC 3E CC 3C 6E FF 04 1B 0A 7F 42 00003FC0: 25 A1 09 2F 4A AD D9 A5 08 C7 A5 6C B1 3A 3F 33 00003FD0: E8 44 E2 8C 8A DC D4 52 50 F4 EE 29 83 4C 5C AA 00003FE0: C5 0B 5E BF 94 50 17 85 66 4E 78 AE 9B 5F DB FA 00003FF0: DF 73 0D ED 97 98 5D 65 91 35 F5 DA BA D8 83 FF 00004000: AC 60 46 A0 F6 29 88 1F 76 14 76 46 D8 E2 A8 67 00004010: 3B 14 29 56 21 F7 ---------------------------Server--------------------------- Application data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Pad: 15360 bytes Record payload protection: server_record_write_key = TLSTREE(server_write_key_ap, 8): 00000: D3 CD 87 D5 68 74 07 82 39 78 34 4C 06 B9 28 A8 00010: 58 98 B7 39 A3 1D 3D E5 FF 2B 78 8E F3 91 96 ED seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 nonce: 00000: 2F E9 1F 71 18 35 40 26 31 7E 1A B4 D8 22 17 B0 additional_data: 00000: 17 03 03 40 11 TLSInnerPlaintext: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000400: 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 00004000: 00 Record layer message: type: 17 legacy_record_version: 0303 length: 4011 Smyshlyaev, et al. Expires 15 March 2023 [Page 47] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 encrypted_record: E3DF00F169A76FA19FE55FA304E0A552 5A28FDBD3DD4CA654B89140EFD69E263 28A65A77F5D8B2E2F73568F7A677E5DF 8D225FAA8ED5FED98F09963FF1E82161 81595E9FA6989CCABC2150CA668D70EA 8CB6F62BCC528D26B52FB27AB70F194A 30E5C9085D9323D38745093070D15650 52468045F3398DC5BF93D6A983956E1D 3077337B773DAF4B9A6BA5BC569A251D 34FE23DF7B9343A0550094 [...] 2B516EE4A4971FD26EFB9293981435E9 FCC560B618B8ED0A52589E7342C25325 11C3D7C145559B8119BC02CB22CBF1EB 915578E8468806B2D0728C591B617354 CC47D51FF2363197A559018AD3498846 AD167DD086BD12EF52179D45ABF06C28 97B0C1D8AAD49413E0CCC086586D537A 296F9CEEB7E7E1DD2537540232C6BD71 619FC93BAE3FD8B0C95EA9915B6127B9 9F87884541F7 TLSCiphertext: 00000000: 17 03 03 40 11 E3 DF 00 F1 69 A7 6F A1 9F E5 5F 00000010: A3 04 E0 A5 52 5A 28 FD BD 3D D4 CA 65 4B 89 14 00000020: 0E FD 69 E2 63 28 A6 5A 77 F5 D8 B2 E2 F7 35 68 00000030: F7 A6 77 E5 DF 8D 22 5F AA 8E D5 FE D9 8F 09 96 00000040: 3F F1 E8 21 61 81 59 5E 9F A6 98 9C CA BC 21 50 00000050: CA 66 8D 70 EA 8C B6 F6 2B CC 52 8D 26 B5 2F B2 00000060: 7A B7 0F 19 4A 30 E5 C9 08 5D 93 23 D3 87 45 09 00000070: 30 70 D1 56 50 52 46 80 45 F3 39 8D C5 BF 93 D6 00000080: A9 83 95 6E 1D 30 77 33 7B 77 3D AF 4B 9A 6B A5 00000090: BC 56 9A 25 1D 34 FE 23 DF 7B 93 43 A0 55 00 94 [...] 00003F80: 2B 51 6E E4 A4 97 1F D2 6E FB 92 93 98 14 35 E9 00003F90: FC C5 60 B6 18 B8 ED 0A 52 58 9E 73 42 C2 53 25 00003FA0: 11 C3 D7 C1 45 55 9B 81 19 BC 02 CB 22 CB F1 EB 00003FB0: 91 55 78 E8 46 88 06 B2 D0 72 8C 59 1B 61 73 54 00003FC0: CC 47 D5 1F F2 36 31 97 A5 59 01 8A D3 49 88 46 00003FD0: AD 16 7D D0 86 BD 12 EF 52 17 9D 45 AB F0 6C 28 00003FE0: 97 B0 C1 D8 AA D4 94 13 E0 CC C0 86 58 6D 53 7A 00003FF0: 29 6F 9C EE B7 E7 E1 DD 25 37 54 02 32 C6 BD 71 00004000: 61 9F C9 3B AE 3F D8 B0 C9 5E A9 91 5B 61 27 B9 00004010: 9F 87 88 45 41 F7 ---------------------------Server--------------------------- Application data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Smyshlyaev, et al. Expires 15 March 2023 [Page 48] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Pad: 15360 bytes Record payload protection: server_record_write_key = TLSTREE(server_write_key_ap, 9): 00000: D3 CD 87 D5 68 74 07 82 39 78 34 4C 06 B9 28 A8 00010: 58 98 B7 39 A3 1D 3D E5 FF 2B 78 8E F3 91 96 ED seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 nonce: 00000: 2F E9 1F 71 18 35 40 26 31 7E 1A B4 D8 22 17 B1 additional_data: 00000: 17 03 03 40 11 TLSInnerPlaintext: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000400: 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 00004000: 00 Record layer message: type: 17 legacy_record_version: 0303 length: 4011 encrypted_record: 4AFCD1257E2C8D4626BC0BFBB30F2F9C A57A9D0DEC090B4248CAADDFE7AA4AEB 770F285384FEA308CADE2EEF318148C2 BED4870ABEE1955CCA41CE8344C3EDA4 7C2512CDD19FD54C7E0260BBC7BD8DD1 EE9D4EBADD3D7915D0A029D7847CA05D 078068CC8A792FED69A4E655A6E6D22D A134ECA2BDECA1E59D3AE7313E45E785 AF89A8F1890BFCC59F03F39C4FB2337C 326D94FA04F5548619D6DC [...] 79B6F56B6EBF8B8860436EFF9D8F03CC 73BDF446D30F918AF8FF8BA2D078D243 1AC04657D7871203F15969F160820D7D FCA78F65FF954CE5549F2C78AA3A0885 04527FC561B6AE06020A8772B75CE933 6CAC35B536A50DB26930BFA21E9EB56E Smyshlyaev, et al. Expires 15 March 2023 [Page 49] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 A20E39CC2BBBA66D41C2E8720AA0143D 298D8036D7B0090A0214F58C5B1890A7 5B4783820395E39421F4357A49597EB0 64123818EACE TLSCiphertext: 00000000: 17 03 03 40 11 4A FC D1 25 7E 2C 8D 46 26 BC 0B 00000010: FB B3 0F 2F 9C A5 7A 9D 0D EC 09 0B 42 48 CA AD 00000020: DF E7 AA 4A EB 77 0F 28 53 84 FE A3 08 CA DE 2E 00000030: EF 31 81 48 C2 BE D4 87 0A BE E1 95 5C CA 41 CE 00000040: 83 44 C3 ED A4 7C 25 12 CD D1 9F D5 4C 7E 02 60 00000050: BB C7 BD 8D D1 EE 9D 4E BA DD 3D 79 15 D0 A0 29 00000060: D7 84 7C A0 5D 07 80 68 CC 8A 79 2F ED 69 A4 E6 00000070: 55 A6 E6 D2 2D A1 34 EC A2 BD EC A1 E5 9D 3A E7 00000080: 31 3E 45 E7 85 AF 89 A8 F1 89 0B FC C5 9F 03 F3 00000090: 9C 4F B2 33 7C 32 6D 94 FA 04 F5 54 86 19 D6 DC [...] 00003F80: 79 B6 F5 6B 6E BF 8B 88 60 43 6E FF 9D 8F 03 CC 00003F90: 73 BD F4 46 D3 0F 91 8A F8 FF 8B A2 D0 78 D2 43 00003FA0: 1A C0 46 57 D7 87 12 03 F1 59 69 F1 60 82 0D 7D 00003FB0: FC A7 8F 65 FF 95 4C E5 54 9F 2C 78 AA 3A 08 85 00003FC0: 04 52 7F C5 61 B6 AE 06 02 0A 87 72 B7 5C E9 33 00003FD0: 6C AC 35 B5 36 A5 0D B2 69 30 BF A2 1E 9E B5 6E 00003FE0: A2 0E 39 CC 2B BB A6 6D 41 C2 E8 72 0A A0 14 3D 00003FF0: 29 8D 80 36 D7 B0 09 0A 02 14 F5 8C 5B 18 90 A7 00004000: 5B 47 83 82 03 95 E3 94 21 F4 35 7A 49 59 7E B0 00004010: 64 12 38 18 EA CE ---------------------------Client----------------------------- Application data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Pad: 15360 bytes Record payload protection: Derived #1 = Derive-Secret(HandshakeSecret, "derived", "") = HKDF-Expand-Label(HandshakeSecret, "derived", "", 32): 00000: EA 3C 54 BB D1 4E F9 D7 50 77 6F AB E3 95 BE 2A 00010: BD DB BB B7 1C 13 C2 BD 60 9E 35 15 79 4A FA 02 MainSecret = HKDF-Extract(Salt: Derived #1, IKM: 0^256): 00000: 31 BB 1D 61 2C CD 53 32 68 8A 55 1A 48 CA 25 0F 00010: 24 78 3D 4A B0 B4 A7 6D 3F E5 06 7A 26 16 A4 A3 HM2 = (ClientHello, ServerHello, EncryptedExtensions, Certificate, Smyshlyaev, et al. Expires 15 March 2023 [Page 50] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 CertificateVerify, Server Finished) TH2 = Transcript-Hash(HM2): 00000: 9E BC 5F BE 32 D9 F4 0D 48 F8 EE CE BB 62 31 A5 00010: 33 C2 C0 EF 24 32 77 B9 6D 6F 7A D3 BB FD 14 94 client_application_traffic_secret (CATS): CATS = Derive-Secret(MainSecret, "c ap traffic", HM2) = HKDF-Expand-Label(MainSecret, "c ap traffic", TH2, 32): 00000: 8A CF 74 6B EC 31 17 6C BD 14 2C 75 80 6C 27 0A 00010: 0A EF 6F C3 8E 0D 8F DC B5 A8 85 25 36 3A DE 81 client_write_key_ap = HKDF-Expand-Label(CATS, "key", "", 32): 00000: 7B E6 4E 2C 12 78 7B 5B 8C 87 56 C4 3D 92 FA EF 00010: 64 F1 5A 3A 3C 10 81 AD 34 BC A5 06 F0 32 24 15 client_write_iv_ap = HKDF-Expand-Label(CATS, "iv", "", 16): 00000: 31 09 57 EF 71 31 44 33 F5 76 CC 9B 00 AD 93 54 client_record_write_key = TLSTREE(client_write_key_ap, 0): 00000: D4 9A 57 15 49 E7 48 94 9F A2 4B 88 34 23 2C A8 00010: 75 D3 7A 26 C4 BB 5C 62 A2 61 DA B3 72 65 05 26 seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 nonce: 00000: 31 09 57 EF 71 31 44 33 F5 76 CC 9B 00 AD 93 54 additional_data: 00000: 17 03 03 40 11 TLSInnerPlaintext: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000400: 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 00004000: 00 Record layer message: type: 17 legacy_record_version: 0303 length: 4011 encrypted_record: EA6CB652C7CBE6B50560D0364DC94D90 2560DFE55D8B83C8AA919F5A1E5492E7 4CA5156F18BEC8EAB6971CAA2D2C1FF1 Smyshlyaev, et al. Expires 15 March 2023 [Page 51] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 46EA5FEF5D62682601868FFCD2688F34 83899C31F6BA87538682E7F895F653C0 9BFE95ABF3EEDF7EBB261CCC593DFCB0 04F05119567148BB35F3C7B4F09713A6 247A047EF29B05F7720E375A6E3264F4 7922EAEBE3AA6D1E80832806D5F20E7C 56662A7128B191829597DB [...] 6A5184907D9FF8D3FC0994A3C850DDBC 2D0420EB66EA177FCDD78F16246E2076 039C525604F79A007F472AC7A20A4574 1B9D96E38E565899D40A724B8A37FF68 702BF9A645D04962BBC9C66A35FFD219 A08A385FE4CDD0A1F3F080BECDF01E45 68C338FAD2C850DFEAA98A7F1B95ECA1 72BA7F7526E3BFF2EFF2395CE4561867 DC9DE8FD10F38BCA1E44B0207AF4CCE8 8155836330BC TLSCiphertext: 00000000: 17 03 03 40 11 EA 6C B6 52 C7 CB E6 B5 05 60 D0 00000010: 36 4D C9 4D 90 25 60 DF E5 5D 8B 83 C8 AA 91 9F 00000020: 5A 1E 54 92 E7 4C A5 15 6F 18 BE C8 EA B6 97 1C 00000030: AA 2D 2C 1F F1 46 EA 5F EF 5D 62 68 26 01 86 8F 00000040: FC D2 68 8F 34 83 89 9C 31 F6 BA 87 53 86 82 E7 00000050: F8 95 F6 53 C0 9B FE 95 AB F3 EE DF 7E BB 26 1C 00000060: CC 59 3D FC B0 04 F0 51 19 56 71 48 BB 35 F3 C7 00000070: B4 F0 97 13 A6 24 7A 04 7E F2 9B 05 F7 72 0E 37 00000080: 5A 6E 32 64 F4 79 22 EA EB E3 AA 6D 1E 80 83 28 00000090: 06 D5 F2 0E 7C 56 66 2A 71 28 B1 91 82 95 97 DB [...] 00003F80: 6A 51 84 90 7D 9F F8 D3 FC 09 94 A3 C8 50 DD BC 00003F90: 2D 04 20 EB 66 EA 17 7F CD D7 8F 16 24 6E 20 76 00003FA0: 03 9C 52 56 04 F7 9A 00 7F 47 2A C7 A2 0A 45 74 00003FB0: 1B 9D 96 E3 8E 56 58 99 D4 0A 72 4B 8A 37 FF 68 00003FC0: 70 2B F9 A6 45 D0 49 62 BB C9 C6 6A 35 FF D2 19 00003FD0: A0 8A 38 5F E4 CD D0 A1 F3 F0 80 BE CD F0 1E 45 00003FE0: 68 C3 38 FA D2 C8 50 DF EA A9 8A 7F 1B 95 EC A1 00003FF0: 72 BA 7F 75 26 E3 BF F2 EF F2 39 5C E4 56 18 67 00004000: DC 9D E8 FD 10 F3 8B CA 1E 44 B0 20 7A F4 CC E8 00004010: 81 55 83 63 30 BC ---------------------------Client----------------------------- Application data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Pad: 15360 bytes Smyshlyaev, et al. Expires 15 March 2023 [Page 52] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 Record payload protection: server_record_write_key = TLSTREE(server_write_key_ap, 1): 00000: D4 9A 57 15 49 E7 48 94 9F A2 4B 88 34 23 2C A8 00010: 75 D3 7A 26 C4 BB 5C 62 A2 61 DA B3 72 65 05 26 seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 nonce: 00000: 31 09 57 EF 71 31 44 33 F5 76 CC 9B 00 AD 93 55 additional_data: 00000: 17 03 03 40 11 TLSInnerPlaintext: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000400: 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 00004000: 00 Record layer message: type: 17 legacy_record_version: 0303 length: 4011 encrypted_record: 0D486A03D03A020296EA0AD1D684A9F4 AE35824129141D3434CEE064FD5E966F 88D6E8903913417658E46C49B18BB0CC B29B663D3F380A2CF9E5234BCD27F3A4 E12EBF3A3C69DB7661B08FC1685FADDE 50F68028A6E85EE12729D6F9CAD762FF A6BAB5FC94AC65BAA36885DAF85C9B27 C68F9E97AB85ECFA760CDD22F9A8C0BA 6097D7960587CA708834516D9588592D D1B8E05210BAA640FE6540 [...] 55A9C5A6557D35B8F1A9804BFA0F2789 3EDC6AA0350E9630AFF6C9B06C3CE01D 5BE51E87EBFFAC58230D074BE121F077 9D08F8177AFFFBB36DCEFDD0D0696873 A772B9A1DA73C681B0F8359EC1C74B6E 0452095C622C4C797F450CAA4F26975A 311F41F31C6A617747298CC052A6376F A46191658FEE5BD8D7A998E7F12E8838 7365BAAD4BA490114733FC15A58148E6 186484821A94 Smyshlyaev, et al. Expires 15 March 2023 [Page 53] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 TLSCiphertext: 00000000: 17 03 03 40 11 0D 48 6A 03 D0 3A 02 02 96 EA 0A 00000010: D1 D6 84 A9 F4 AE 35 82 41 29 14 1D 34 34 CE E0 00000020: 64 FD 5E 96 6F 88 D6 E8 90 39 13 41 76 58 E4 6C 00000030: 49 B1 8B B0 CC B2 9B 66 3D 3F 38 0A 2C F9 E5 23 00000040: 4B CD 27 F3 A4 E1 2E BF 3A 3C 69 DB 76 61 B0 8F 00000050: C1 68 5F AD DE 50 F6 80 28 A6 E8 5E E1 27 29 D6 00000060: F9 CA D7 62 FF A6 BA B5 FC 94 AC 65 BA A3 68 85 00000070: DA F8 5C 9B 27 C6 8F 9E 97 AB 85 EC FA 76 0C DD 00000080: 22 F9 A8 C0 BA 60 97 D7 96 05 87 CA 70 88 34 51 00000090: 6D 95 88 59 2D D1 B8 E0 52 10 BA A6 40 FE 65 40 [...] 00003F80: 55 A9 C5 A6 55 7D 35 B8 F1 A9 80 4B FA 0F 27 89 00003F90: 3E DC 6A A0 35 0E 96 30 AF F6 C9 B0 6C 3C E0 1D 00003FA0: 5B E5 1E 87 EB FF AC 58 23 0D 07 4B E1 21 F0 77 00003FB0: 9D 08 F8 17 7A FF FB B3 6D CE FD D0 D0 69 68 73 00003FC0: A7 72 B9 A1 DA 73 C6 81 B0 F8 35 9E C1 C7 4B 6E 00003FD0: 04 52 09 5C 62 2C 4C 79 7F 45 0C AA 4F 26 97 5A 00003FE0: 31 1F 41 F3 1C 6A 61 77 47 29 8C C0 52 A6 37 6F 00003FF0: A4 61 91 65 8F EE 5B D8 D7 A9 98 E7 F1 2E 88 38 00004000: 73 65 BA AD 4B A4 90 11 47 33 FC 15 A5 81 48 E6 00004010: 18 64 84 82 1A 94 ---------------------------Client----------------------------- Application data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Pad: 15360 bytes Record payload protection: client_record_write_key = TLSTREE(client_write_key_ap, 8): 00000: B8 2D 78 25 D1 5F AE 18 A7 01 32 28 B3 1C B0 C5 00010: 97 52 C6 40 9C 5F 78 99 EC C6 95 0F 74 63 C0 90 seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 nonce: 00000: 31 09 57 EF 71 31 44 33 F5 76 CC 9B 00 AD 93 5C additional_data: 00000: 17 03 03 40 11 TLSInnerPlaintext: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Smyshlyaev, et al. Expires 15 March 2023 [Page 54] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000400: 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 00004000: 00 Record layer message: type: 17 legacy_record_version: 0303 length: 4011 encrypted_record: F8B5732A300C8EF05FB712A2972F4DB8 4BE783A959090398E989516B6A54F333 331049283186BD1C42EFD98003A476A2 408EACE0D7047FB536979386C26B5523 F933A4F5BD7048B094EC5F5627EDFA98 99DE1AF8D9A493E481BA5DA0857BE15A 3F21CA01E22092159BAA770569CFBE54 F653BEFB4A8B32295DEFE992258F4581 257E936AF549E82D54EA6C09EF0D987B F3A3E8453C1548CEF1C349 [...] 0EF4E88899AA3481AEDAE0E257449F80 A20CBDF070EC02211B6B9CBA9248B192 CF75C88A085DBFF77ABCFB1D82DAA421 1B487A48230350CBA4F338DD0BFD36D8 AAC5EE709456B7E317C78E7198FB7264 5B45EEFD3F93BF1C021F9E74A2ED2BCC 1CF5D367B553C7E7E9D80DD2447C7D13 D0345FEF2976696DFE579E5F71740C71 3124CFBAD66C7BB5BC21AAAE2F1E0860 5C248ADAF8BA TLSCiphertext: 00000000: 17 03 03 40 11 F8 B5 73 2A 30 0C 8E F0 5F B7 12 00000010: A2 97 2F 4D B8 4B E7 83 A9 59 09 03 98 E9 89 51 00000020: 6B 6A 54 F3 33 33 10 49 28 31 86 BD 1C 42 EF D9 00000030: 80 03 A4 76 A2 40 8E AC E0 D7 04 7F B5 36 97 93 00000040: 86 C2 6B 55 23 F9 33 A4 F5 BD 70 48 B0 94 EC 5F 00000050: 56 27 ED FA 98 99 DE 1A F8 D9 A4 93 E4 81 BA 5D 00000060: A0 85 7B E1 5A 3F 21 CA 01 E2 20 92 15 9B AA 77 00000070: 05 69 CF BE 54 F6 53 BE FB 4A 8B 32 29 5D EF E9 00000080: 92 25 8F 45 81 25 7E 93 6A F5 49 E8 2D 54 EA 6C 00000090: 09 EF 0D 98 7B F3 A3 E8 45 3C 15 48 CE F1 C3 49 [...] 00003F80: 0E F4 E8 88 99 AA 34 81 AE DA E0 E2 57 44 9F 80 00003F90: A2 0C BD F0 70 EC 02 21 1B 6B 9C BA 92 48 B1 92 00003FA0: CF 75 C8 8A 08 5D BF F7 7A BC FB 1D 82 DA A4 21 00003FB0: 1B 48 7A 48 23 03 50 CB A4 F3 38 DD 0B FD 36 D8 Smyshlyaev, et al. Expires 15 March 2023 [Page 55] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 00003FC0: AA C5 EE 70 94 56 B7 E3 17 C7 8E 71 98 FB 72 64 00003FD0: 5B 45 EE FD 3F 93 BF 1C 02 1F 9E 74 A2 ED 2B CC 00003FE0: 1C F5 D3 67 B5 53 C7 E7 E9 D8 0D D2 44 7C 7D 13 00003FF0: D0 34 5F EF 29 76 69 6D FE 57 9E 5F 71 74 0C 71 00004000: 31 24 CF BA D6 6C 7B B5 BC 21 AA AE 2F 1E 08 60 00004010: 5C 24 8A DA F8 BA ---------------------------Client----------------------------- Application data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Pad: 15360 bytes Record payload protection: client_record_write_key = TLSTREE(client_write_key_ap, 9): 00000: B8 2D 78 25 D1 5F AE 18 A7 01 32 28 B3 1C B0 C5 00010: 97 52 C6 40 9C 5F 78 99 EC C6 95 0F 74 63 C0 90 seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 nonce: 00000: 31 09 57 EF 71 31 44 33 F5 76 CC 9B 00 AD 93 5D additional_data: 00000: 17 03 03 40 11 TLSInnerPlaintext: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000400: 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 00004000: 00 Record layer message: type: 17 legacy_record_version: 0303 length: 4011 encrypted_record: C1719B62D4F5E295AB8A4A2CBD6BBEF3 0F07297D96004EBABE315090247510A6 BEE6395676956B4249B16B52CE9FE171 B1F4693F48B3446D48A99B6224537FBB 9BC8BF54AEA688D21E39F17840DB9F33 Smyshlyaev, et al. Expires 15 March 2023 [Page 56] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 632EA196922B7E15D6AE080F9F3B33F2 FABE63BB66E21C590785EFAEBE75BB1E 17C9E5F58A1B1D1101DE95F9BF346C62 1C63CABEB6D7245DB75F18DA495F129A 652CE6B7E0FE47FB210D6A [...] 2AF9D515B26C3D8F37F9BF5F3A766D8B 03189A78605069179FB9CF9B1A449DC0 4F0FE37E67FDF9A0341B1F0D64AA2871 D4DFEF10EC7DFE7475CFE364BB4D9453 A9F176829887148F3E8C0EEE858F9C17 C0B753C145D13BD2A96B23822F73DC6C FD623DE3CB70F8D507E436C20E393940 F3A36C913C0BCDFE672C903C5522AA41 0B318DD1268D035C59D3E11FF273B1D7 715E2FBF3ACA TLSCiphertext: 00000000: 17 03 03 40 11 C1 71 9B 62 D4 F5 E2 95 AB 8A 4A 00000010: 2C BD 6B BE F3 0F 07 29 7D 96 00 4E BA BE 31 50 00000020: 90 24 75 10 A6 BE E6 39 56 76 95 6B 42 49 B1 6B 00000030: 52 CE 9F E1 71 B1 F4 69 3F 48 B3 44 6D 48 A9 9B 00000040: 62 24 53 7F BB 9B C8 BF 54 AE A6 88 D2 1E 39 F1 00000050: 78 40 DB 9F 33 63 2E A1 96 92 2B 7E 15 D6 AE 08 00000060: 0F 9F 3B 33 F2 FA BE 63 BB 66 E2 1C 59 07 85 EF 00000070: AE BE 75 BB 1E 17 C9 E5 F5 8A 1B 1D 11 01 DE 95 00000080: F9 BF 34 6C 62 1C 63 CA BE B6 D7 24 5D B7 5F 18 00000090: DA 49 5F 12 9A 65 2C E6 B7 E0 FE 47 FB 21 0D 6A [...] 00003F80: 2A F9 D5 15 B2 6C 3D 8F 37 F9 BF 5F 3A 76 6D 8B 00003F90: 03 18 9A 78 60 50 69 17 9F B9 CF 9B 1A 44 9D C0 00003FA0: 4F 0F E3 7E 67 FD F9 A0 34 1B 1F 0D 64 AA 28 71 00003FB0: D4 DF EF 10 EC 7D FE 74 75 CF E3 64 BB 4D 94 53 00003FC0: A9 F1 76 82 98 87 14 8F 3E 8C 0E EE 85 8F 9C 17 00003FD0: C0 B7 53 C1 45 D1 3B D2 A9 6B 23 82 2F 73 DC 6C 00003FE0: FD 62 3D E3 CB 70 F8 D5 07 E4 36 C2 0E 39 39 40 00003FF0: F3 A3 6C 91 3C 0B CD FE 67 2C 90 3C 55 22 AA 41 00004000: 0B 31 8D D1 26 8D 03 5C 59 D3 E1 1F F2 73 B1 D7 00004010: 71 5E 2F BF 3A CA ---------------------------Server--------------------------- Alert message: level: 01 description: 00 00000: 01 00 Record payload protection: Smyshlyaev, et al. Expires 15 March 2023 [Page 57] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 client_record_write_key = TLSTREE(client_write_key_ap, 10): 00000: D3 CD 87 D5 68 74 07 82 39 78 34 4C 06 B9 28 A8 00010: 58 98 B7 39 A3 1D 3D E5 FF 2B 78 8E F3 91 96 ED seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A nonce: 00000: 2F E9 1F 71 18 35 40 26 31 7E 1A B4 D8 22 17 B2 additional_data: 00000: 17 03 03 00 13 TLSInnerPlaintext: 00000: 01 00 15 Record layer message: type: 17 legacy_record_version: 0303 length: 0013 encrypted_record: 7CBC00AD5D29E301739394D31942C6A1 6658E9 TLSCiphertext: 00000: 17 03 03 00 13 7C BC 00 AD 5D 29 E3 01 73 93 94 00010: D3 19 42 C6 A1 66 58 E9 ---------------------------Client--------------------------- Alert message: level: 01 description: 00 00000: 01 00 Record payload protection: client_record_write_key = TLSTREE(client_write_key_ap, 10): 00000: B8 2D 78 25 D1 5F AE 18 A7 01 32 28 B3 1C B0 C5 00010: 97 52 C6 40 9C 5F 78 99 EC C6 95 0F 74 63 C0 90 seqnum: 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A nonce: 00000: 31 09 57 EF 71 31 44 33 F5 76 CC 9B 00 AD 93 5E additional_data: Smyshlyaev, et al. Expires 15 March 2023 [Page 58] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 00000: 17 03 03 00 13 TLSInnerPlaintext: 00000: 01 00 15 Record layer message: type: 17 legacy_record_version: 0303 length: 0013 encrypted_record: CB19F306C3641754BE4FC95390DF06F9 CD44AA TLSCiphertext: 00000: 17 03 03 00 13 CB 19 F3 06 C3 64 17 54 BE 4F C9 00010: 53 90 DF 06 F9 CD 44 AA A.2. Example 2 A.2.1. Test case Test examples are given for the following order of using the TLS13_GOST profile. 1. Full TLS Handshake is used. 2. PSK with ECDHE key exchange mode is used. The elliptic curve GC256B is used for ECDHE shared secret calculation. 3. The server and client sides authentication is used. The external PSK is used for the mutual authentication. 4. TLS_GOSTR341112_256_WITH_MAGMA_MGM_L cipher suite is negotiated. 5. Four Application Data records are sent during the operation of the Record protocol. The sequence numbers are selected to demonstrate the operation of the TLSTREE function. 6. Alert protocol is used for closure of the connection. A.2.2. Test examples ePSK: 00000: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 00000: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ---------------------------Client--------------------------- Smyshlyaev, et al. Expires 15 March 2023 [Page 59] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 ClientHello1 message: msg_type: 01 length: 00007B body: legacy_version: 0303 random: 01010101010101010101010101010101 01010101010101010101010101010101 legasy_session_id: length: 00 vector: -- cipher_suites: length: 0002 vector: CipherSuite: C104 compression_methods: length: 01 vector: CompressionMethod: 00 extensions: length: 0050 vector: Extension: /* supported_groups */ extension_type: 000A extension_data: length: 0006 vector: named_group_list: length: 0004 vector: /* GC256B */ 0023 /* GC512C */ 0028 Extension: /* supported_versions */ extension_type: 002B extension_data: length: 0003 vector: versions: length: 02 vector: 0304 Extension: /* psk_key_exchange_modes */ extension_type: 002D extension_data: length: 0002 vector: ke_modes: Smyshlyaev, et al. Expires 15 March 2023 [Page 60] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 length: 01 vector: /* psk_dhe_ke */ 01 Extension: /* key_share */ extension_type: 0033 extension_data: length: 0002 client_shares: length: 0000 vector: -- Extension: /* pre_shared_key */ extension_type: 0029 extension_data: length: 002F vector: identities: length: 000A vector: identity: length: 0004 vector: 6550534B obfuscated_ticket_age: 00000000 binders: length: 0021 vector: binder: length: 20 vector: 6F3A0B91F2945EF7056DB74302BC34B6 DF77A88E09C587508AB6287C6C0514AD Truncate(ClientHello1): 0000: 01 00 00 7B 03 03 01 01 01 01 01 01 01 01 01 01 0010: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 0020: 01 01 01 01 01 01 00 00 02 C1 04 01 00 00 50 00 0030: 0A 00 06 00 04 00 23 00 28 00 2B 00 03 02 03 04 0040: 00 2D 00 02 01 01 00 33 00 02 00 00 00 29 00 2F 0050: 00 0A 00 04 65 50 53 4B 00 00 00 00 Hash(Truncate(ClientHello1)): 0000: CC 9C A9 FC 18 DF 7A 2F 5F 63 27 D7 7B EA DC F1 0010: A7 3D 80 97 7F EB EA B4 F0 D3 83 39 30 00 2B 8D EarlySecret = HKDF-Extract(Salt: 0^Hlen, IKM: ePSK): 00000: 42 30 7A 99 68 18 34 0D D0 56 2F 7F EB E6 2A B5 00010: 70 F3 BC 88 9C A9 29 3A 89 0D F2 09 B9 1B BB F3 binder_key = Derive-Secret(EarlySecret, "ext binder", "") = Smyshlyaev, et al. Expires 15 March 2023 [Page 61] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 HKDF-Expand-Label(EarlySecret, "ext binder", "", 32): 00000: A4 37 62 C3 5E 75 54 1A 15 58 A0 8D 15 50 D3 29 00010: 4C C3 F9 0C 73 99 EC C0 50 B9 15 37 A2 4C D5 E4 finished_binder_key = HKDF-Expand-Label(binder_key, "finished", "", 32): 00000: F5 6F 59 C2 E2 F8 E7 7C 69 80 1F B1 7D B4 C1 8B 00010: ED 96 EB 32 FC D7 AB 95 AD D6 B1 CF F1 73 E6 65 binder = HMAC(finished_binder_key, Hash(Truncate(ClientHello1))): 00000: 6F 3A 0B 91 F2 94 5E F7 05 6D B7 43 02 BC 34 B6 00010: DF 77 A8 8E 09 C5 87 50 8A B6 28 7C 6C 05 14 AD 0000: 01 00 00 7B 03 03 01 01 01 01 01 01 01 01 01 01 0010: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 0020: 01 01 01 01 01 01 00 00 02 C1 04 01 00 00 50 00 0030: 0A 00 06 00 04 00 23 00 28 00 2B 00 03 02 03 04 0040: 0A 07 0B 07 0C 07 0D 07 0E 07 0F 00 2B 00 03 02 0050: 00 2D 00 02 01 01 00 33 00 02 00 00 00 29 00 2F 0060: 00 0A 00 04 65 50 53 4B 00 00 00 00 00 21 20 6F 0070: 3A 0B 91 F2 94 5E F7 05 6D B7 43 02 BC 34 B6 DF 0080: 77 A8 8E 09 C5 87 50 8A B6 28 7C 6C 05 14 AD Record layer message: type: 16 legacy_record_version: 0301 length: 007F fragment: 0100007B030301010101010101010101 01010101010101010101010101010101 010101010101000002C1040100005000 0A0006000400230028002B0003020304 0A070B070C070D070E070F002B000302 002D000201010033000200000029002F 000A00046550534B000000000021206F 3A0B91F2945EF7056DB74302BC34B6DF 77A88E09C587508AB6287C6C0514AD 00000: 16 03 01 00 7F 01 00 00 7B 03 03 01 01 01 01 01 00010: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00020: 01 01 01 01 01 01 01 01 01 01 01 00 00 02 C1 04 00030: 01 00 00 50 00 0A 00 06 00 04 00 23 00 28 00 2B 00040: 00 03 02 03 04 0A 07 0B 07 0C 07 0D 07 0E 07 0F 00050: 00 2B 00 03 02 00 2D 00 02 01 01 00 33 00 02 00 00060: 00 00 29 00 2F 00 0A 00 04 65 50 53 4B 00 00 00 00070: 00 00 21 20 6F 3A 0B 91 F2 94 5E F7 05 6D B7 43 00080: 02 BC 34 B6 DF 77 A8 8E 09 C5 87 50 8A B6 28 7C 00090: 6C 05 14 AD Smyshlyaev, et al. Expires 15 March 2023 [Page 62] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 ---------------------------Server--------------------------- HelloRetryRequest message: msg_type: 02 length: 000034 body: legacy_version: 0303 random: CF21AD74E59A6111BE1D8C021E65B891 C2A211167ABB8C5E079E09E2C8A8339C legasy_session_id: length: 00 vector: -- cipher_suite: CipherSuite: C104 compression_method: CompressionMethod: 00 extensions: length: 000C vector: Extension: /* supported_versions */ extension_type: 002B extension_data: length: 0002 vector: selected_version: 0304 Extension: /* key_share */ extension_type: 0033 extension_data: length: 0002 selected_group: 0023 00000: 02 00 00 34 03 03 CF 21 AD 74 E5 9A 61 11 BE 1D 00010: 8C 02 1E 65 B8 91 C2 A2 11 16 7A BB 8C 5E 07 9E 00020: 09 E2 C8 A8 33 9C 00 C1 04 00 00 0C 00 2B 00 02 00030: 03 04 00 33 00 02 00 23 Record layer message: type: 16 legacy_record_version: 0303 length: 0038 fragment: 020000340303CF21AD74E59A6111BE1D 8C021E65B891C2A211167ABB8C5E079E 09E2C8A8339C00C10400000C002B0002 0304003300020023 00000: 16 03 03 00 38 02 00 00 34 03 03 CF 21 AD 74 E5 00010: 9A 61 11 BE 1D 8C 02 1E 65 B8 91 C2 A2 11 16 7A Smyshlyaev, et al. Expires 15 March 2023 [Page 63] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 00020: BB 8C 5E 07 9E 09 E2 C8 A8 33 9C 00 C1 04 00 00 00030: 0C 00 2B 00 02 03 04 00 33 00 02 00 23 ---------------------------Client--------------------------- ClientHello2 message: msg_type: 01 length: 0000BF body: legacy_version: 0303 random: 01010101010101010101010101010101 01010101010101010101010101010101 legasy_session_id: length: 00 vector: -- cipher_suites: length: 0002 vector: CipherSuite: C104 compression_methods: length: 01 vector: CompressionMethod: 00 extensions: length: 0094 vector: Extension: /* supported_groups */ extension_type: 000A extension_data: length: 0006 vector: named_group_list: length: 0004 vector: /* GC256B */ 0023 /* GC512C */ 0028 Extension: /* supported_versions */ extension_type: 002B extension_data: length: 0003 vector: versions: length: 02 vector: 0304 Extension: /* psk_key_exchange_modes */ Smyshlyaev, et al. Expires 15 March 2023 [Page 64] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 extension_type: 002D extension_data: length: 0002 vector: ke_modes: length: 01 vector: /* psk_dhe_ke */ 01 Extension: /* key_share */ extension_type: 0033 extension_data: length: 0046 client_shares: length: 0044 vector: group: 0023 key_exchange: length: 0040 vector: D35AA795C452450949591D60E7D5C076 056D6646F3B80708CDC2E7034DE85F68 D1122DC32A3B986D40FF910622A06C12 26D9EC3A7D3A52E0A37C282C47602A43 Extension: /* pre_shared_key */ extension_type: 0029 extension_data: length: 002F vector: identities: length: 000A vector: identity: length: 0004 vector: 6550534B obfuscated_ticket_age: 00000000 binders: length: 0021 vector: binder: length: 20 vector: 0BF74AA3933B7D1A66961B6E2CFB6A28 04D696BB607710E3F56DDA91F56B57CB Truncate(ClientHello2): 0000: 01 00 00 BF 03 03 01 01 01 01 01 01 01 01 01 01 0010: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 0020: 01 01 01 01 01 01 00 00 02 C1 04 01 00 00 94 00 Smyshlyaev, et al. Expires 15 March 2023 [Page 65] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 0030: 0A 00 06 00 04 00 23 00 28 00 2B 00 03 02 03 04 0040: 00 2D 00 02 01 01 00 33 00 46 00 44 00 23 00 40 0050: D3 5A A7 95 C4 52 45 09 49 59 1D 60 E7 D5 C0 76 0060: 05 6D 66 46 F3 B8 07 08 CD C2 E7 03 4D E8 5F 68 0070: D1 12 2D C3 2A 3B 98 6D 40 FF 91 06 22 A0 6C 12 0080: 26 D9 EC 3A 7D 3A 52 E0 A3 7C 28 2C 47 60 2A 43 0090: 00 29 00 2F 00 0A 00 04 65 50 53 4B 00 00 00 00 finished_binder_key: 00000: F5 6F 59 C2 E2 F8 E7 7C 69 80 1F B1 7D B4 C1 8B 00010: ED 96 EB 32 FC D7 AB 95 AD D6 B1 CF F1 73 E6 65 BinderMsg = (FE 00 00 20 | Hash(ClientHello1), HelloRetryRequest, Truncate(ClientHello2)) Hash(BinderMsg) = 73 7C 63 74 1B 3A EA DF C8 73 DF 6E EA 81 19 32 BF CE 93 4F AA 85 84 F1 44 F8 77 13 E0 D0 CA 32 binder = HMAC(finished_binder_key, Hash(BinderMsg)) = 0B F7 4A A3 93 3B 7D 1A 66 96 1B 6E 2C FB 6A 28 04 D6 96 BB 60 77 10 E3 F5 6D DA 91 F5 6B 57 CB 0000: 01 00 00 BF 03 03 01 01 01 01 01 01 01 01 01 01 0010: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 0020: 01 01 01 01 01 01 00 00 02 C1 04 01 00 00 94 00 0030: 0A 00 06 00 04 00 23 00 28 00 2B 00 03 02 03 04 0040: 00 2D 00 02 01 01 00 33 00 46 00 44 00 23 00 40 0050: D3 5A A7 95 C4 52 45 09 49 59 1D 60 E7 D5 C0 76 0060: 05 6D 66 46 F3 B8 07 08 CD C2 E7 03 4D E8 5F 68 0070: D1 12 2D C3 2A 3B 98 6D 40 FF 91 06 22 A0 6C 12 0080: 26 D9 EC 3A 7D 3A 52 E0 A3 7C 28 2C 47 60 2A 43 0090: 00 29 00 2F 00 0A 00 04 65 50 53 4B 00 00 00 00 00A0: 00 21 20 0B F7 4A A3 93 3B 7D 1A 66 96 1B 6E 2C 00B0: FB 6A 28 04 D6 96 BB 60 77 10 E3 F5 6D DA 91 F5 00C0: 6B 57 CB Record layer message: type: 16 legacy_record_version: 0303 length: 00C3 fragment: 010000BF030301010101010101010101 01010101010101010101010101010101 010101010101000002C1040100009400 0A0006000400230028002B0003020304 002D0002010100330046004400230040 Smyshlyaev, et al. Expires 15 March 2023 [Page 66] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 D35AA795C452450949591D60E7D5C076 056D6646F3B80708CDC2E7034DE85F68 D1122DC32A3B986D40FF910622A06C12 26D9EC3A7D3A52E0A37C282C47602A43 0029002F000A00046550534B00000000 0021200BF74AA3933B7D1A66961B6E2C FB6A2804D696BB607710E3F56DDA91F5 6B57CB 00000: 16 03 03 00 C3 01 00 00 BF 03 03 01 01 01 01 01 00010: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00020: 01 01 01 01 01 01 01 01 01 01 01 00 00 02 C1 04 00030: 01 00 00 94 00 0A 00 06 00 04 00 23 00 28 00 2B 00040: 00 03 02 03 04 00 2D 00 02 01 01 00 33 00 46 00 00050: 44 00 23 00 40 D3 5A A7 95 C4 52 45 09 49 59 1D 00060: 60 E7 D5 C0 76 05 6D 66 46 F3 B8 07 08 CD C2 E7 00070: 03 4D E8 5F 68 D1 12 2D C3 2A 3B 98 6D 40 FF 91 00080: 06 22 A0 6C 12 26 D9 EC 3A 7D 3A 52 E0 A3 7C 28 00090: 2C 47 60 2A 43 00 29 00 2F 00 0A 00 04 65 50 53 000A0: 4B 00 00 00 00 00 21 20 0B F7 4A A3 93 3B 7D 1A 000B0: 66 96 1B 6E 2C FB 6A 28 04 D6 96 BB 60 77 10 E3 000C0: F5 6D DA 91 F5 6B 57 CB ---------------------------Server--------------------------- ServerHello message: msg_type: 02 length: 00007C body: legacy_version: 0303 random: 82828282828282828282828282828282 82828282828282828282828282828282 legasy_session_id: length: 00 vector: -- cipher_suite: CipherSuite: C104 compression_method: CompressionMethod: 00 extensions: length: 0054 vector: Extension: /* supported_versions */ extension_type: 002B extension_data: length: 0002 Smyshlyaev, et al. Expires 15 March 2023 [Page 67] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 vector: selected_version: 0304 Extension: /* key_share */ extension_type: 0033 extension_data: length: 0044 vector: group: 0023 key_exchange: length: 0040 vector: 3D2FB067E106CC9980FB8842811164BA 708BBB5038D5EDFBEE1D5E5DFBE6F74F 1931217C67C2BDF46253DB9CE3487241 F2DBD84E2DABDF65455851B0B19AEFEC Extension: /* pre_shared_key */ extension_type: 0029 extension_data: length: 0002 selected_identity: 0000 00000: 02 00 00 7C 03 03 82 82 82 82 82 82 82 82 82 82 00010: 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 00020: 82 82 82 82 82 82 00 C1 04 00 00 54 00 2B 00 02 00030: 03 04 00 33 00 44 00 23 00 40 3D 2F B0 67 E1 06 00040: CC 99 80 FB 88 42 81 11 64 BA 70 8B BB 50 38 D5 00050: ED FB EE 1D 5E 5D FB E6 F7 4F 19 31 21 7C 67 C2 00060: BD F4 62 53 DB 9C E3 48 72 41 F2 DB D8 4E 2D AB 00070: DF 65 45 58 51 B0 B1 9A EF EC 00 29 00 02 00 00 Record layer message: type: 16 legacy_record_version: 0303 length: 0080 fragment: 020000410303933EA21E49C31BC3A345 6165889684CAA5576CE7924A24F58113 808DBD9EF85610C3802A561550EC78D6 ED51AC2439D7E7C101000009FF010001 0000170000 00000: 16 03 03 00 80 02 00 00 7C 03 03 82 82 82 82 82 00010: 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 00020: 82 82 82 82 82 82 82 82 82 82 82 00 C1 04 00 00 00030: 54 00 2B 00 02 03 04 00 33 00 44 00 23 00 40 3D 00040: 2F B0 67 E1 06 CC 99 80 FB 88 42 81 11 64 BA 70 00050: 8B BB 50 38 D5 ED FB EE 1D 5E 5D FB E6 F7 4F 19 Smyshlyaev, et al. Expires 15 March 2023 [Page 68] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 00060: 31 21 7C 67 C2 BD F4 62 53 DB 9C E3 48 72 41 F2 00070: DB D8 4E 2D AB DF 65 45 58 51 B0 B1 9A EF EC 00 00080: 29 00 02 00 00 ---------------------------Client--------------------------- d_C^res: 00000: 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 00010: 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 Q_S^res: 00000: 3D 2F B0 67 E1 06 CC 99 80 FB 88 42 81 11 64 BA 00010: 70 8B BB 50 38 D5 ED FB EE 1D 5E 5D FB E6 F7 4F 00020: 19 31 21 7C 67 C2 BD F4 62 53 DB 9C E3 48 72 41 00030: F2 DB D8 4E 2D AB DF 65 45 58 51 B0 B1 9A EF EC ECDHE: 00000: 98 5A 86 59 D5 5A 8D 48 E0 E6 77 13 96 58 0B 2C 00010: DC DA 37 E9 2A EE 18 14 D1 0E 1B F2 A4 4F 0D 24 ---------------------------Server--------------------------- d_S^res: 00000: 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 00010: 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 83 Q_C^res: 00000: D3 5A A7 95 C4 52 45 09 49 59 1D 60 E7 D5 C0 76 00010: 05 6D 66 46 F3 B8 07 08 CD C2 E7 03 4D E8 5F 68 00020: D1 12 2D C3 2A 3B 98 6D 40 FF 91 06 22 A0 6C 12 00030: 26 D9 EC 3A 7D 3A 52 E0 A3 7C 28 2C 47 60 2A 43 ECDHE: 00000: 98 5A 86 59 D5 5A 8D 48 E0 E6 77 13 96 58 0B 2C 00010: DC DA 37 E9 2A EE 18 14 D1 0E 1B F2 A4 4F 0D 24 ---------------------------Server--------------------------- EncryptedExtensions message: msg_type: 08 length: 000002 Smyshlyaev, et al. Expires 15 March 2023 [Page 69] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 body: extensions: length: 0000 vector: -- 00000: 08 00 00 02 00 00 Record payload protection: EarlySecret = HKDF-Extract(Salt: 0^256, IKM: ePSK): 00000: 42 30 7A 99 68 18 34 0D D0 56 2F 7F EB E6 2A B5 00010: 70 F3 BC 88 9C A9 29 3A 89 0D F2 09 B9 1B BB F3 Derived #0 = Derive-Secret(EarlySecret, "derived", "") = HKDF-Expand-Label(EarlySecret, "derived", "", 32): 00000: 6B 4E 9C 49 C5 C6 F1 7F 60 B2 B8 4B 55 0A 16 38 00010: 14 09 5B 80 88 8E C0 B0 CA 52 E4 09 0C B3 F8 BE HandshakeSecret = HKDF-Extract(Salt: Derived #0, IKM: ECDHE): 00000: A9 CB E6 58 50 2F 3F D1 18 66 51 5F D6 15 E9 88 00010: 0D 1E 61 B5 28 34 BB FD 5F 19 C2 4C 53 C8 79 7F HM1 = (FE 00 00 20 | Hash(ClientHello1), HelloRetryRequest, ClientHello2, ServerHello) TH1 = Transcript-Hash(HM1): 00000: 88 8D 5D 1E 15 98 65 05 97 3E F2 0F 9A FA F5 71 00010: 20 A3 66 C2 D2 19 91 D1 5E 25 07 0C 3D 07 D5 E9 server_handshake_traffic_secret (SHTS): SHTS = Derive-Secret(HandshakeSecret, "s hs traffic", HM1) = HKDF-Expand-Label(HandshakeSecret, "s hs traffic", TH1, 32): 00000: 4E F8 68 E5 5B 27 F8 88 8A 6F 82 DA A7 0B 01 1B 00010: DA B1 77 95 10 F0 88 78 A0 22 2B 3E 2C 76 E6 83 server_write_key_hs = HKDF-Expand-Label(SHTS, "key", "", 32): 00000: DB 61 9B 58 F4 41 1E 33 4F 07 EA C7 7C EF EF CA 00010: 78 41 F5 40 88 B8 D0 D5 CE 6A 62 C9 82 85 C6 81 server_write_iv_hs = HKDF-Expand-Label(SHTS, "iv", "", 16): 00000: FC 9E 2A C6 63 04 C2 5B server_record_write_key = TLSTREE(server_write_key_hs, 0): 00000: 3C 7D F3 5E AC F4 FE 71 EA 6A DC E0 DC 44 5D D3 00010: A9 29 EF CD 08 3F 18 2F BD 51 42 BA 68 6D 38 84 Smyshlyaev, et al. Expires 15 March 2023 [Page 70] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 seqnum: 00000: 00 00 00 00 00 00 00 00 nonce: 00000: 7C 9E 2A C6 63 04 C2 5B additional_data: 00000: 17 03 03 00 0F TLSInnerPlaintext: 00000: 08 00 00 02 00 00 16 TLSCiphertext: 00000: 17 03 03 00 0F 49 67 A7 E1 AE 7B FB 37 5A 0F 4B 00010: 25 45 91 17 Record layer message: type: 17 legacy_record_version: 0303 length: 000F encrypted_record: 4967A7E1AE7BFB375A0F4B 25459117 00000: 17 03 03 00 0F 49 67 A7 E1 AE 7B FB 37 5A 0F 4B 00010: 25 45 91 17 ---------------------------Server--------------------------- server_finished_key = HKDF-Expand-Label(SHTS, "finished", "", 32): 00000: AF 41 F7 7A CB 18 B4 C5 9D E0 F7 8D 46 D5 AE 95 00010: 7A A4 92 A7 D8 D8 2A 36 F4 B2 09 B8 20 7C 79 03 HMFinished = (FE 00 00 20 | Hash(ClientHello1), HelloRetryRequest, ClientHello2, ServerHello, EncryptedExtensions) Transcript-Hash(HMFinished): 00000: E0 5D D6 C9 DE BA 09 3D 72 AD 6F 4A 7D 0E 11 95 00010: FC E7 AE 31 93 F2 FF 5B 2D 0B F6 14 8E CB E7 B9 FinishedHash = HMAC(server_finished_key,Transcript-Hash(HMFinished)): 00000: 96 14 5B 61 68 E0 1C 4C F2 99 50 96 EE 12 C8 6B 00010: 1F 53 1F 96 0A 48 9D E9 C3 44 2A 24 33 E9 AE EE Finished message: msg_type: 14 length: 000020 body: Smyshlyaev, et al. Expires 15 March 2023 [Page 71] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 verify_data: 96145B6168E01C4CF2995096EE12C86B 1F531F960A489DE9C3442A2433E9AEEE 00000: 14 00 00 20 96 14 5B 61 68 E0 1C 4C F2 99 50 96 00010: EE 12 C8 6B 1F 53 1F 96 0A 48 9D E9 C3 44 2A 24 00020: 33 E9 AE EE Record payload protection: server_record_write_key = TLSTREE(server_write_key_hs, 1): 00000: 3C 7D F3 5E AC F4 FE 71 EA 6A DC E0 DC 44 5D D3 00010: A9 29 EF CD 08 3F 18 2F BD 51 42 BA 68 6D 38 84 seqnum: 00000: 00 00 00 00 00 00 00 01 nonce: 00000: 7C 9E 2A C6 63 04 C2 5A additional_data: 00000: 17 03 03 00 2D TLSInnerPlaintext: 00000: 14 00 00 20 96 14 5B 61 68 E0 1C 4C F2 99 50 96 00010: EE 12 C8 6B 1F 53 1F 96 0A 48 9D E9 C3 44 2A 24 00020: 33 E9 AE EE 16 Record layer message: type: 17 legacy_record_version: 0303 length: 002D encrypted_record: 3BFB2AEADBC349FD89AFB8E481F8426B CC6B7F5D975FE05E5B28755C00BF353F CA6A48E9F0145993C40CE06F37 TLSCiphertext: 00000: 17 03 03 00 2D 3B FB 2A EA DB C3 49 FD 89 AF B8 00010: E4 81 F8 42 6B CC 6B 7F 5D 97 5F E0 5E 5B 28 75 00020: 5C 00 BF 35 3F CA 6A 48 E9 F0 14 59 93 C4 0C E0 00030: 6F 37 ---------------------------Client--------------------------- EarlySecret = HKDF-Extract(Salt: 0^256, IKM: ePSK): 00000: 42 30 7A 99 68 18 34 0D D0 56 2F 7F EB E6 2A B5 00010: 70 F3 BC 88 9C A9 29 3A 89 0D F2 09 B9 1B BB F3 Smyshlyaev, et al. Expires 15 March 2023 [Page 72] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 Derived #0 = Derive-Secret(EarlySecret, "derived", "") = HKDF-Expand-Label(EarlySecret, "derived", "", 32): 00000: 6B 4E 9C 49 C5 C6 F1 7F 60 B2 B8 4B 55 0A 16 38 00010: 14 09 5B 80 88 8E C0 B0 CA 52 E4 09 0C B3 F8 BE HandshakeSecret = HKDF-Extract(Salt: Derived #0, IKM: ECDHE): 00000: A9 CB E6 58 50 2F 3F D1 18 66 51 5F D6 15 E9 88 00010: 0D 1E 61 B5 28 34 BB FD 5F 19 C2 4C 53 C8 79 7F HM1 = (FE 00 00 20 | Hash(ClientHello1), HelloRetryRequest, ClientHello2, ServerHello) TH1 = Transcript-Hash(HM1): 00000: 88 8D 5D 1E 15 98 65 05 97 3E F2 0F 9A FA F5 71 00010: 20 A3 66 C2 D2 19 91 D1 5E 25 07 0C 3D 07 D5 E9 client_handshake_traffic_secret (CHTS): CHTS = Derive-Secret(HandshakeSecret, "c hs traffic", HM1) = HKDF-Expand-Label(HandshakeSecret, "c hs traffic", TH1, 32): 00000: DF 00 4B 79 A1 D3 51 55 97 1B 0E 84 C8 91 99 7F 00010: FE E6 D0 1B 27 04 23 CC 74 64 4B 25 47 3E 78 60 client_finished_key = HKDF-Expand-Label(CHTS, "finished", "", 32): 00000: 1F A6 7D 28 9F F2 A6 85 C7 BE 13 FD F5 60 A6 D5 00010: A9 F5 EA 85 63 AD 6C C7 B4 85 30 76 59 A5 55 81 HM2 = (FE 00 00 20 | Hash(ClientHello1), HelloRetryRequest, ClientHello2, ServerHello, EncryptedExtensions, Server Finished) TH2 =Transcript-Hash(HM2): 00000: 53 06 24 EE 07 6F FF E1 04 DC 15 EB B4 2D 78 8F 00010: 1E 4F EB 3E 8C 2D CF A5 CB 85 D7 2F 81 D0 6D 15 FinishedHash = HMAC(client_finished_key, TH2): 00000: BB 83 09 94 BE 38 A9 8F FC A3 BF D2 35 CD 80 7E 00010: 81 82 1E 67 37 AB 98 31 43 DC A9 7B 9E E0 23 25 Finished message: msg_type: 14 length: 000020 body: verify_data: BB830994BE38A98FFCA3BFD235CD807E 81821E6737AB983143DCA97B9EE02325 00000: 14 00 00 20 BB 83 09 94 BE 38 A9 8F FC A3 BF D2 00010: 35 CD 80 7E 81 82 1E 67 37 AB 98 31 43 DC A9 7B 00020: 9E E0 23 25 Smyshlyaev, et al. Expires 15 March 2023 [Page 73] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 Record payload protection: client_write_key_hs = HKDF-Expand-Label(CHTS, "key", "", 32): 00000: DF 66 60 1E DD D6 4E 96 1D FC 7D D0 21 2E F2 25 00010: C0 05 33 E6 DA A4 AD 24 18 5E BE B2 24 B5 46 B8 client_write_iv_hs = HKDF-Expand-Label(CHTS, "iv", "", 16): 00000: E8 94 3C 9F A2 88 56 A1 client_record_write_key = TLSTREE(client_write_key_hs, 0): 00000: BD 00 9F FC 04 A0 52 9E 60 78 EB A5 A0 7A DE 74 00010: 93 7F F3 A1 AB 75 F7 AE 05 19 04 78 51 9B 6D F3 seqnum: 00000: 00 00 00 00 00 00 00 00 nonce: 00000: 68 94 3C 9F A2 88 56 A1 additional_data: 00000: 17 03 03 00 2D TLSInnerPlaintext: 00000: 14 00 00 20 BB 83 09 94 BE 38 A9 8F FC A3 BF D2 00010: 35 CD 80 7E 81 82 1E 67 37 AB 98 31 43 DC A9 7B 00020: 9E E0 23 25 16 Record layer message: type: 17 legacy_record_version: 0303 length: 002D encrypted_record: 14254CA6B9EBCC4A951A3D1F1040B0B1 45446DF131946CEECBDB6A8EC534F194 223281B56532A703C492160E2C TLSCiphertext: 00000: 17 03 03 00 2D 14 25 4C A6 B9 EB CC 4A 95 1A 3D 00010: 1F 10 40 B0 B1 45 44 6D F1 31 94 6C EE CB DB 6A 00020: 8E C5 34 F1 94 22 32 81 B5 65 32 A7 03 C4 92 16 00030: 0E 2C ---------------------------Server--------------------------- Application data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] Smyshlyaev, et al. Expires 15 March 2023 [Page 74] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Record payload protection: Derived #1 = Derive-Secret(HandshakeSecret, "derived", "") = HKDF-Expand-Label(HandshakeSecret, "derived", "", 32): 00000: BC 4D 6F E3 D9 43 78 21 1D 3D 64 1C 75 92 EB AA 00010: 7A A2 96 47 9C 57 BD D1 E1 4C 7B 04 9F 6D F1 CD MainSecret = HKDF-Extract(Salt: Derived #1, IKM: 0^256): 00000: DB FF 82 86 2E 54 A1 41 3E 6C 2E D8 2C 6D A5 AF 00010: FD BF DE 12 30 2E 49 75 5B 61 F2 06 32 E1 0A 42 HM2 = (FE 00 00 20 | Hash(ClientHello1), HelloRetryRequest, ClientHello2, ServerHello, EncryptedExtensions, Server Finished) TH2 = Transcript-Hash(HM2): 00000: 53 06 24 EE 07 6F FF E1 04 DC 15 EB B4 2D 78 8F 00010: 1E 4F EB 3E 8C 2D CF A5 CB 85 D7 2F 81 D0 6D 15 SATS = Derive-Secret(MainSecret, "s ap traffic", HM2) = HKDF-Expand-Label(MainSecret, "s ap traffic", TH2, 32): 00000: 52 91 26 2B EC B5 22 69 34 3A E8 27 9B 43 54 B1 00010: 89 22 D5 15 04 60 8B A7 21 C4 72 46 7E EE E8 78 server_write_key_ap = HKDF-Expand-Label(SATS, "key", "", 32): 00000: 15 D9 2C 51 47 B2 13 10 ED ED F5 5B 3D 7A B7 76 00000: 81 7D 6F E2 FC F2 30 D7 E3 F2 92 75 F6 E2 41 EC server_write_iv_ap = HKDF-Expand-Label(SATS, "iv", "", 8): 00000: 71 2E 2F 11 CD 50 6E B9 server_record_write_key = TLSTREE(server_write_key_ap, 0): 00000: 7B B8 81 55 35 98 DE F5 34 FC AF 9B 77 A3 35 5B 00010: C3 BC A3 87 4D 67 40 F6 CB F5 C1 B6 D3 5C 65 ED seqnum: 00000: 00 00 00 00 00 00 00 00 nonce: 00000: 71 2E 2F 11 CD 50 6E B9 additional_data: 00000: 17 03 03 04 09 TLSInnerPlaintext: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] Smyshlyaev, et al. Expires 15 March 2023 [Page 75] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000400: 17 Record layer message: type: 17 legacy_record_version: 0303 length: 0409 encrypted_record: 7CAA82039F67326C2D735EE809B57750 945F5CE2B0C47B8EF1ECADA3D3F1AD9E 3FBA5926FDB2B61197D08B8B1399167B 6C249C90C0A3101452FD72078FBFB057 31E06215019395DDCF44AA763DCB1ACA 8B3F47D033FBA12E7C0FBB4DFBDABD8B 97E996E8E36231BE8015412B90CCCFBB E2BC967E597FC2E7B251A9BBEBAA245B 63139387203DB90BD1BF5300A5B577BF 46793DB1AA30FEDFD1E6A5 [...] E1D55816BFD6BFFBF6E6FB23D86117D2 47441BC211D078199C1F8340BE808BA6 E5BE092B9E081E95D4A57672A07970A6 1FEF2F4B12A0F401FA30B813FE7CD1BF 881485157381B8489EC36296C6EE7538 0FB1DAA1B1473358FD87AA41D5DBA089 F528BD5F3B41B34002D945D7E0C49EFA 54A4EFB0DA4049F5F248B3F7D46FEC05 A25BBE0A5120106BC21C1EA25EFF3125 E079CA0F7FFA56FD89C1A80DA0A3 TLSCiphertext: 00000000: 17 03 03 04 09 7C AA 82 03 9F 67 32 6C 2D 73 5E 00000010: E8 09 B5 77 50 94 5F 5C E2 B0 C4 7B 8E F1 EC AD 00000020: A3 D3 F1 AD 9E 3F BA 59 26 FD B2 B6 11 97 D0 8B 00000030: 8B 13 99 16 7B 6C 24 9C 90 C0 A3 10 14 52 FD 72 00000040: 07 8F BF B0 57 31 E0 62 15 01 93 95 DD CF 44 AA 00000050: 76 3D CB 1A CA 8B 3F 47 D0 33 FB A1 2E 7C 0F BB 00000060: 4D FB DA BD 8B 97 E9 96 E8 E3 62 31 BE 80 15 41 00000070: 2B 90 CC CF BB E2 BC 96 7E 59 7F C2 E7 B2 51 A9 00000080: BB EB AA 24 5B 63 13 93 87 20 3D B9 0B D1 BF 53 00000090: 00 A5 B5 77 BF 46 79 3D B1 AA 30 FE DF D1 E6 A5 [...] 00000370: E1 D5 58 16 BF D6 BF FB F6 E6 FB 23 D8 61 17 D2 00000380: 47 44 1B C2 11 D0 78 19 9C 1F 83 40 BE 80 8B A6 00000390: E5 BE 09 2B 9E 08 1E 95 D4 A5 76 72 A0 79 70 A6 000003A0: 1F EF 2F 4B 12 A0 F4 01 FA 30 B8 13 FE 7C D1 BF 000003B0: 88 14 85 15 73 81 B8 48 9E C3 62 96 C6 EE 75 38 000003C0: 0F B1 DA A1 B1 47 33 58 FD 87 AA 41 D5 DB A0 89 000003D0: F5 28 BD 5F 3B 41 B3 40 02 D9 45 D7 E0 C4 9E FA Smyshlyaev, et al. Expires 15 March 2023 [Page 76] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 000003E0: 54 A4 EF B0 DA 40 49 F5F2 48 B3 F7 D4 6F EC 05 000003F0: A2 5B BE 0A 51 20 10 6B C2 1C 1E A2 5E FF 31 25 00000400: E0 79 CA 0F 7F FA 56 FD 89 C1 A8 0D A0 A3 ---------------------------Server--------------------------- Application data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Record payload protection: server_record_write_key = TLSTREE(server_write_key_ap, 1): 00000: 7B B8 81 55 35 98 DE F5 34 FC AF 9B 77 A3 35 5B 00010: C3 BC A3 87 4D 67 40 F6 CB F5 C1 B6 D3 5C 65 ED seqnum: 00000: 00 00 00 00 00 00 00 01 nonce: 00000: 71 2E 2F 11 CD 50 6E B8 additional_data: 00000: 17 03 03 04 09 TLSInnerPlaintext: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000400: 17 Record layer message: type: 17 legacy_record_version: 0303 length: 0409 encrypted_record: DC593FC6FAFC5191242B632E144504A2 61AEF332970FF8316FA4DE507BFB471E A83C713FF950791078FD9A3178D02682 66E12BC970FFB1EE4A56600DF32ABF9F A318FF45C91CDEF42E1C1D450059729B 1BB6925F773A1E8F304E7AB143F0FC16 EF16BC4E0DF60D76DE43390F9CD257DE D256209B1675378FE6822CBB19A53620 BD5B240282CF4977F1C572AB3B1DD6CF 497F2757286B7E49CF80C7 [...] EE2E29D3F79640D9CA3C35181B9CE939 Smyshlyaev, et al. Expires 15 March 2023 [Page 77] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 CA16A862AC460424B6AEF6B89D533406 7724CCF2466A804F09FAB3EBE737F99C 6498EFF2379CAD6596C3C352F4426876 95ACBC4FB44B5D069FB66605E47945FE 2F11509FF7B5961BE8AB43EC2060D822 A994D97C59C8058C951708029AE0BEDA 8045ECA025FE02E6D2EFAF13202012E9 E34358DE79E561CCEC8F549E70073EE6 938F4A1AAE97465970D65260604C TLSCiphertext: 00000000: 17 03 03 04 09 DC 59 3F C6 FA FC 51 91 24 2B 63 00000010: 2E 14 45 04 A2 61 AE F3 32 97 0F F8 31 6F A4 DE 00000020: 50 7B FB 47 1E A8 3C 71 3F F9 50 79 10 78 FD 9A 00000030: 31 78 D0 26 82 66 E1 2B C9 70 FF B1 EE 4A 56 60 00000040: 0D F3 2A BF 9F A3 18 FF 45 C9 1C DE F4 2E 1C 1D 00000050: 45 00 59 72 9B 1B B6 92 5F 77 3A 1E 8F 30 4E 7A 00000060: B1 43 F0 FC 16 EF 16 BC 4E 0D F6 0D 76 DE 43 39 00000070: 0F 9C D2 57 DE D2 56 20 9B 16 75 37 8F E6 82 2C 00000080: BB 19 A5 36 20 BD 5B 24 02 82 CF 49 77 F1 C5 72 00000090: AB 3B 1D D6 CF 49 7F 27 57 28 6B 7E 49 CF 80 C7 [...] 00000370: EE 2E 29 D3 F7 96 40 D9 CA 3C 35 18 1B 9C E9 39 00000380: CA 16 A8 62 AC 46 04 24 B6 AE F6 B8 9D 53 34 06 00000390: 77 24 CC F2 46 6A 80 4F 09 FA B3 EB E7 37 F9 9C 000003A0: 64 98 EF F2 37 9C AD 65 96 C3 C3 52 F4 42 68 76 000003B0: 95 AC BC 4F B4 4B 5D 06 9F B6 66 05 E4 79 45 FE 000003C0: 2F 11 50 9F F7 B5 96 1B E8 AB 43 EC 20 60 D8 22 000003D0: A9 94 D9 7C 59 C8 05 8C 95 17 08 02 9A E0 BE DA 000003E0: 80 45 EC A0 25 FE 02 E6 D2 EF AF 13 20 20 12 E9 000003F0: E3 43 58 DE 79 E5 61 CC EC 8F 54 9E 70 07 3E E6 00000400: 93 8F 4A 1A AE 97 46 59 70 D6 52 60 60 4C ---------------------------Server--------------------------- Application data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Record payload protection: server_record_write_key = TLSTREE(server_write_key_ap, 128): 00000: 93 D5 D6 E1 03 6F DF B3 EF BF 31 E6 DA 5E EC E6 00010: 85 17 1C 97 7F F9 CD 6C 3A 3F 67 C0 22 4A B6 EB Smyshlyaev, et al. Expires 15 March 2023 [Page 78] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 seqnum: 00000: 00 00 00 00 00 00 00 80 nonce: 00000: 71 2E 2F 11 CD 50 6E 39 additional_data: 00000: 17 03 03 04 09 TLSInnerPlaintext: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000400: 17 Record layer message: type: 17 legacy_record_version: 0303 length: 0409 encrypted_record: 56A7E2F32541DB0EE1563F8CA79EB129 3192E2122BA8A89A6CF05B151D205AEC EB60321D0F637A98880814BEF639FC08 A1E8222D95A54E5593F8BB9CF520D3FA 7D38D960E00665BB736A7AFF49D7A7BA D092DDB1714655EDF1A9A24F4727DA7E 873135F2A0534FAF7825EA99401FE1F0 1E8C4246D2B55CEBE768FA205B3F7890 9827B912C6AA9FDDE3CFCA47F2D9E2E2 0FBEE9606D0E0105A7C97A [...] A72D5F8E43ABC13984593F16DCECBE7B 26AF73FDC82D7BE1F913B846D2612531 BA0F05FF0C52DEFC8674AF3A1AE27393 FC092D45DCD0F71E2B54B60EC618C2A4 5BE72EC19B5FB263C2DC780FF3093FD5 D2F75185E437BE8BB3E5C26F9E0E71B3 C5D6CCA2E0D2F44BB1ACDA17B189F21E C97C748502A2155E3ADC3CCC1BA14EEB 7CDAA018253FCB57D53A12F548C5456C DDA00385EE1C0826AB58E964007C TLSCiphertext: 00000000: 17 03 03 04 09 56 A7 E2 F3 25 41 DB 0E E1 56 3F 00000010: 8C A7 9E B1 29 31 92 E2 12 2B A8 A8 9A 6C F0 5B 00000020: 15 1D 20 5A EC EB 60 32 1D 0F 63 7A 98 88 08 14 00000030: BE F6 39 FC 08 A1 E8 22 2D 95 A5 4E 55 93 F8 BB 00000040: 9C F5 20 D3 FA 7D 38 D9 60 E0 06 65 BB 73 6A 7A 00000050: FF 49 D7 A7 BA D0 92 DD B1 71 46 55 ED F1 A9 A2 00000060: 4F 47 27 DA 7E 87 31 35 F2 A0 53 4F AF 78 25 EA 00000070: 99 40 1F E1 F0 1E 8C 42 46 D2 B5 5C EB E7 68 FA Smyshlyaev, et al. Expires 15 March 2023 [Page 79] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 00000080: 20 5B 3F 78 90 98 27 B9 12 C6 AA 9F DD E3 CF CA 00000090: 47 F2 D9 E2 E2 0F BE E9 60 6D 0E 01 05 A7 C9 7A [...] 00000370: A7 2D 5F 8E 43 AB C1 39 84 59 3F 16 DC EC BE 7B 00000380: 26 AF 73 FD C8 2D 7B E1 F9 13 B8 46 D2 61 25 31 00000390: BA 0F 05 FF 0C 52 DE FC 86 74 AF 3A 1A E2 73 93 000003A0: FC 09 2D 45 DC D0 F7 1E 2B 54 B6 0E C6 18 C2 A4 000003B0: 5B E7 2E C1 9B 5F B2 63 C2 DC 78 0F F3 09 3F D5 000003C0: D2 F7 51 85 E4 37 BE 8B B3 E5 C2 6F 9E 0E 71 B3 000003D0: C5 D6 CC A2 E0 D2 F4 4B B1 AC DA 17 B1 89 F2 1E 000003E0: C9 7C 74 85 02 A2 15 5E 3A DC 3C CC 1B A1 4E EB 000003F0: 7C DA A0 18 25 3F CB 57 D5 3A 12 F5 48 C5 45 6C 00000400: DD A0 03 85 EE 1C 08 26 AB 58 E9 64 00 7C ---------------------------Server--------------------------- Application data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Record payload protection: server_record_write_key = TLSTREE(server_write_key_ap, 129): 00000: 93 D5 D6 E1 03 6F DF B3 EF BF 31 E6 DA 5E EC E6 00010: 85 17 1C 97 7F F9 CD 6C 3A 3F 67 C0 22 4A B6 EB seqnum: 00000: 00 00 00 00 00 00 00 81 nonce: 00000: 71 2E 2F 11 CD 50 6E 38 additional_data: 00000: 17 03 03 04 09 TLSInnerPlaintext: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [...] 000003F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000400: 17 Record layer message: type: 17 legacy_record_version: 0303 length: 0409 encrypted_record: EE73C4CAE69FD30BC4B3A66CA571CD9F Smyshlyaev, et al. Expires 15 March 2023 [Page 80] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 3C7AA2C2BA9F428A82249720F717738F 8C35AC7745B701F3B0CEE993EB2CFDAB 4468B22297A8286C2572DE366AC38B70 471B26A1EC4F19D68E7EDA0A231C3BD1 98013FA05BAC92E774A370EB10C0CBD9 15BACD0117A885804B9A475B44A6F3E8 7D7BCA40F3F52EF4AB624B6EDD3094F9 86269E409F8BB76CEB4BE26D4B1AF54C 0A14D41C291EB8E181F79A [...] 10C401A9423D02804B51DDBFE5925294 ADEE0067193FED8F66CBEED9475873B8 8A730496487E8E7F45FC05EEE9C628AF E9236696F41A1505AA7392BF71C7EED3 78035013ADE1EF07DE5A0230669E133E 0D18B6C977A7FE94F4D22AB29CBAA6B5 CDDBF4B35598C0007F3BA69D3FA2730D F51D867E1E47CFDE22CAEACD4C5AFD97 088AEB92D12CE3C685C4E517730B8339 4FC8514264E2F15E51CE439DED1D TLSCiphertext: 00000000: 17 03 03 04 09 EE 73 C4 CA E6 9F D3 0B C4 B3 A6 00000010: 6C A5 71 CD 9F 3C 7A A2 C2 BA 9F 42 8A 82 24 97 00000020: 20 F7 17 73 8F 8C 35 AC 77 45 B7 01 F3 B0 CE E9 00000030: 93 EB 2C FD AB 44 68 B2 22 97 A8 28 6C 25 72 DE 00000040: 36 6A C3 8B 70 47 1B 26 A1 EC 4F 19 D6 8E 7E DA 00000050: 0A 23 1C 3B D1 98 01 3F A0 5B AC 92 E7 74 A3 70 00000060: EB 10 C0 CB D9 15 BA CD 01 17 A8 85 80 4B 9A 47 00000070: 5B 44 A6 F3 E8 7D 7B CA 40 F3 F5 2E F4 AB 62 4B 00000080: 6E DD 30 94 F9 86 26 9E 40 9F 8B B7 6C EB 4B E2 00000090: 6D 4B 1A F5 4C 0A 14 D4 1C 29 1E B8 E1 81 F7 9A [...] 00000370: 10 C4 01 A9 42 3D 02 80 4B 51 DD BF E5 92 52 94 00000380: AD EE 00 67 19 3F ED 8F 66 CB EE D9 47 58 73 B8 00000390: 8A 73 04 96 48 7E 8E 7F 45 FC 05 EE E9 C6 28 AF 000003A0: E9 23 66 96 F4 1A 15 05 AA 73 92 BF 71 C7 EE D3 000003B0: 78 03 50 13 AD E1 EF 07 DE 5A 02 30 66 9E 13 3E 000003C0: 0D 18 B6 C9 77 A7 FE 94 F4 D2 2A B2 9C BA A6 B5 000003D0: CD DB F4 B3 55 98 C0 00 7F 3B A6 9D 3F A2 73 0D 000003E0: F5 1D 86 7E 1E 47 CF DE 22 CA EA CD 4C 5A FD 97 000003F0: 08 8A EB 92 D1 2C E3 C6 85 C4 E5 17 73 0B 83 39 00000400: 4F C8 51 42 64 E2 F1 5E 51 CE 43 9D ED 1D ---------------------------Server--------------------------- Alert message: level: 01 description: 00 Smyshlyaev, et al. Expires 15 March 2023 [Page 81] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 00000: 01 00 Record payload protection: server_record_write_key = TLSTREE(server_write_key_ap, 130): 00000: 93 D5 D6 E1 03 6F DF B3 EF BF 31 E6 DA 5E EC E6 00010: 85 17 1C 97 7F F9 CD 6C 3A 3F 67 C0 22 4A B6 EB seqnum: 00000: 00 00 00 00 00 00 00 82 nonce: 00000: 71 2E 2F 11 CD 50 6E 3B additional_data: 00000: 17 03 03 00 0B TLSInnerPlaintext: 00000: 01 00 15 Record layer message: type: 17 legacy_record_version: 0303 length: 000B encrypted_record: 447A3FAE8F86C135189B10 TLSCiphertext: 00000: 17 03 03 00 0B 44 7A 3F AE 8F 86 C1 35 18 9B 10 ---------------------------Client--------------------------- Alert message: level: 01 description: 00 00000: 01 00 Record payload protection: Derived #1 = Derive-Secret(HandshakeSecret, "derived", "") = HKDF-Expand-Label(HandshakeSecret, "derived", "", 32): 00000: BC 4D 6F E3 D9 43 78 21 1D 3D 64 1C 75 92 EB AA 00010: 7A A2 96 47 9C 57 BD D1 E1 4C 7B 04 9F 6D F1 CD MainSecret = HKDF-Extract(Salt: Derived #1, IKM: 0^256): 00000: DB FF 82 86 2E 54 A1 41 3E 6C 2E D8 2C 6D A5 AF 00010: FD BF DE 12 30 2E 49 75 5B 61 F2 06 32 E1 0A 42 HM2 = (FE 00 00 20 | Hash(ClientHello1), HelloRetryRequest, Smyshlyaev, et al. Expires 15 March 2023 [Page 82] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 ClientHello2, ServerHello, EncryptedExtensions, Server Finished) TH2 = Transcript-Hash(HM2): 00000: 53 06 24 EE 07 6F FF E1 04 DC 15 EB B4 2D 78 8F 00010: 1E 4F EB 3E 8C 2D CF A5 CB 85 D7 2F 81 D0 6D 15 client_application_traffic_secret (CATS): CATS = Derive-Secret(MainSecret, "c ap traffic", HM2) = HKDF-Expand-Label(MainSecret, "c ap traffic", TH2, 32): 20 D9 85 D5 B8 4D 9D 8D 4E 5E CF CD BC DD 67 41 55 F1 82 F7 28 7B 18 4D A5 53 42 5C 6C 64 57 83 client_write_key_ap = HKDF-Expand-Label(CATS, "key", "", 32): 00000: EB D2 71 DE 19 FE E1 8B B1 99 8F 69 AF 5B 6A E1 00010: 89 58 E8 D3 70 2F 12 FB B5 B0 3F 6F D6 91 FE FA client_write_iv_ap = HKDF-Expand-Label(CATS, "iv", "", 8): 00000: 18 FB 03 8D BF 72 41 E6 client_record_write_key = TLSTREE(client_write_key_ap, 0): 00000: 86 2A 74 18 0B 4A E4 C2 D1 5F 4A 62 ED 8A 4A 75 00010: B0 8D 72 B0 46 AF DE CB 3A 8E F0 C2 67 F4 56 BD seqnum: 00000: 00 00 00 00 00 00 00 00 nonce: 00000: 18 FB 03 8D BF 72 41 E6 additional_data: 00000: 17 03 03 00 0B TLSInnerPlaintext: 00000: 01 00 15 Record layer message: type: 17 legacy_record_version: 0303 length: 000B encrypted_record: 464AEEAD391D97987169F3 TLSCiphertext: 00000: 17 03 03 00 0B 46 4A EE AD 39 1D 97 98 71 69 F3 Smyshlyaev, et al. Expires 15 March 2023 [Page 83] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 Appendix B. Contributors * Lilia Akhmetzyanova CryptoPro lah@cryptopro.ru * Alexandr Sokolov CryptoPro sokolov@cryptopro.ru * Vasily Nikolaev CryptoPro nikolaev@cryptopro.ru Authors' Addresses Stanislav Smyshlyaev (editor) CryptoPro 18, Suschevsky val Moscow 127018 Russian Federation Phone: +7 (495) 995-48-20 Email: svs@cryptopro.ru Evgeny Alekseev CryptoPro 18, Suschevsky val Moscow 127018 Russian Federation Email: alekseev@cryptopro.ru Ekaterina Griboedova CryptoPro 18, Suschevsky val Moscow 127018 Russian Federation Email: griboedova.e.s@gmail.com Smyshlyaev, et al. Expires 15 March 2023 [Page 84] Internet-Draft GOST Cipher Suites for TLS 1.3 September 2022 Alexandra Babueva CryptoPro 18, Suschevsky val Moscow 127018 Russian Federation Email: babueva@cryptopro.ru Lidiia Nikiforova CryptoPro 18, Suschevsky val Moscow 127018 Russian Federation Email: nikiforova@cryptopro.ru Smyshlyaev, et al. Expires 15 March 2023 [Page 85] ./draft-smyslov-ike2-gost-15.txt0000644000764400076440000113641214343643163016262 0ustar iustiniustin Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS Intended status: Informational 6 December 2022 Expires: 9 June 2023 Using GOST Cryptographic Algorithms in the Internet Key Exchange Protocol Version 2 (IKEv2) draft-smyslov-ike2-gost-15 Abstract This document defines a set of cryptographic transforms for use in the Internet Key Exchange protocol version 2 (IKEv2). The transforms are based on Russian cryptographic standard algorithms (GOST). Use of GOST ciphers in IKEv2 was defined in RFC 9227. This document aims to define using GOST algorithms for the rest of cryptographic transforms used in IKEv2. This specification was developed to facilitate implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used in this document. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 9 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Smyslov Expires 9 June 2023 [Page 1] Internet-Draft GOST algorithms in IKEv2 December 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. IKE SA Protection . . . . . . . . . . . . . . . . . . . . . . 3 5. Pseudo Random Function . . . . . . . . . . . . . . . . . . . 3 6. Shared Key Calculation . . . . . . . . . . . . . . . . . . . 4 6.1. Recipient Tests . . . . . . . . . . . . . . . . . . . . . 4 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Hash Functions . . . . . . . . . . . . . . . . . . . . . 5 7.2. ASN.1 Objects . . . . . . . . . . . . . . . . . . . . . . 6 7.2.1. id-tc26-signwithdigest-gost3410-12-256 . . . . . . . 6 7.2.2. id-tc26-signwithdigest-gost3410-12-512 . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 10 A.1. Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . 10 A.2. Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 150 1. Introduction The Internet Key Exchange protocol version 2 (IKEv2) defined in [RFC7296] is an important part of the IP Security (IPsec) architecture. It is used for the authenticated key exchange and for the negotiation of various protocol parameters and features. This document defines a number of transforms for IKEv2, based on Russian cryptographic standard algorithms (often reffered to as "GOST" algorithms) for hash function, digital signature and key exchange method. These definitions are based on the recommendations [GOST-IKEv2] established by the Standardisation Technical Committee "Cryptographic information protection", which describe how Russian cryptographic standard algorithms are used in IKEv2. Along with the transforms defined in [RFC9227], the transforms defined in this specification allow using GOST cryptographic algorithms in IPsec protocols. Smyslov Expires 9 June 2023 [Page 2] Internet-Draft GOST algorithms in IKEv2 December 2022 This specification was developed to facilitate implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used in this document. 2. Terminology and Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Overview Russian cryptographic standard (GOST) algorithms are a set of cryptographic algorithms of different types - ciphers, hash functions, digital signatures etc. In particular, Russian cryptographic standard [GOST3412-2015] defines block ciphers "Kuznyechik" (also defined in [RFC7801]) and "Magma" (also defined in [RFC8891]). Cryptographic standard [GOST3410-2012] defines elliptic curve digital signature algorithm (also defined in [RFC7091]), while [GOST3411-2012] defines two cryptographic hash functions "Streebog", with different output length (also defined in [RFC6986]). The parameters for the elliptic curves used in GOST signature and key exchange algorithms are defined in [RFC7836]. 4. IKE SA Protection IKE SA protection using GOST algorithms is defined in [RFC9227]. In particular, two transforms of type 1 (Encryption Algorithm Transform IDs) can be used for IKE SA protection: ENCR_KUZNYECHIK_MGM_KTREE (32) based on "Kuznyechik" block cipher and ENCR_MAGMA_MGM_KTREE (33) based on "Magma" block cipher, both in Multilinear Galois Mode (MGM). The information here is provided for convenience. For full details, please see [RFC9227]. 5. Pseudo Random Function This specification defines a new transform of type 2 (Pseudorandom Function Transform IDs) - PRF_HMAC_STREEBOG_512 (9). This transform uses PRF HMAC_GOSTR3411_2012_512 defined in Section 4.1.2 of [RFC7836]. The PRF uses GOST R 34.11-2012 ("Streebog") hash-function with 512-bit output defined in [RFC6986][GOST3411-2012] with HMAC [RFC2104] construction. The PRF has a 512-bit block size and a 512-bit output length. Smyslov Expires 9 June 2023 [Page 3] Internet-Draft GOST algorithms in IKEv2 December 2022 6. Shared Key Calculation This specification defines two new transforms of type 4 (Diffie- Hellman Group Transform IDs): GOST3410_2012_256 (33) and GOST3410_2012_512 (34). These transforms uses Elliptic Curve Diffie- Hellman (ECDH) key exchange algorithm over Twisted Edwards curves. The parameters for these curves are defined in Section A.2 of [RFC7836]. In particular, transform GOST3410_2012_256 uses id-tc26- gost-3410-2012-256-paramSetA parameter set and GOST3410_2012_512 uses id-tc26-gost-3410-2012-512-paramSetC parameter set (both defined in [RFC7836]). Shared secret is computed as follows. The initiator randomly selects its private key d_i from {1,..,q - 1}, where q is the subgroup order and is a parameter of the selected curve. Then a public key Q_i is computed as a point on the curve: Q_i = d_i * G where G is the generator for the selected curve, and then is sent to the responder. The responder makes the same calculations to get d_r and Q_r and sends Q_r to the initiator. After peers exchange Q_i and Q_R both sides can compute a point on the curve: S = ((m / q) * d_i) * Q_r = ((m / q) * d_r) * Q_i where m is the group order and is a parameter of the selected curve. The shared secret K is an x coordinate of S in a little-endian representation. The size of K is determined by the size of used curve and is either 256 or 512 bit. When GOST public key is transmitted in the KE payload, it MUST be represented as x coordinate immediately followed by y coordinate, each in a little-endian representation. The size of each coordinate is determined by the size of the used curve and is either 256 or 512 bits, so that the size of the Key Exchange Data field in the KE payload is either 64 or 128 octets. 6.1. Recipient Tests Upon receiving peer's public key, implementations MUST check that the key is actually a point on the curve. Otherwise the exchange fails. Implementations MUST check that the calculated public value S is not an identity element of the curve. If S appears to be the identity element of the curve, the exchange fails. The INVALID_SYNTAX notification MAY be sent in these cases. Smyslov Expires 9 June 2023 [Page 4] Internet-Draft GOST algorithms in IKEv2 December 2022 7. Authentication IKEv2 allows various authentication methods to be used for IKE SA establishment. Some methods are tied to a particular algorithm, while others may be used with different algorithms. This specification makes no restrictions on using the latter ones with the GOST algorithms. In particular, "Shared Key Message Integrity Code" (2), defined in [RFC7296], and "NULL Authentication" (13), defined in [RFC7619], can be used with GOST algorithms with no changes to the process of the AUTH payload content calculation. When GOST digital signature is used in IKEv2 for authentication purposes, an Authentication Method "Digital Signature" (14), defined in [RFC7427], MUST be specified in the AUTH payload. GOST digital signature algorithm GOST R 34.10-2012 is defined in [RFC7091][GOST3410-2012]. There are two variants of GOST signature algorithm - one over 256-bit elliptic curve and the other over 512-bit key elliptic curve. The signature value, as defined in [RFC7091][GOST3410-2012], consists of two integers r and s. The size of each integer is either 256 bit or 512 bit depending on the used elliptic curve. The content of the Signature Value field in the AUTH payload MUST consist of s immediately followed by r, each in a big- endian representation, so that the size of the field is either 64 or 128 octets. The AlgorithmIdentifier ASN.1 objects for GOST digital signature algorithm are defined in Section 7.2. 7.1. Hash Functions GOST digital signature algorithm uses GOST hash functions GOST R 34.11-2012 ("Streebog") defined in [RFC6986][GOST3411-2012]. There are two "Streebog" hash functions - one with 256-bit output length and the other with 512-bit output length. The former is used with GOST digital signature algorithm over a 256-bit elliptic curve and the latter - over a 512-bit key elliptic curve. This specification defines two new values for IKEv2 Hash Algorithms registry: STREEBOG_256 (6) for GOST hash function with 256-bit output length and STREEBOG_512 (7) for the 512-bit length output. These values MUST be included in the SIGNATURE_HASH_ALGORITHMS notify if a corresponding GOST digital signature algorithm is supported by the sender and its local policy allows using this algorithm (see Section 4 of [RFC7427] for details). Smyslov Expires 9 June 2023 [Page 5] Internet-Draft GOST algorithms in IKEv2 December 2022 7.2. ASN.1 Objects This section lists GOST signature algorithm ASN.1 AlgorithmIdentifier objects in binary form. With GOST signature algorithms, optional parameters in AlgorithmIdentifier objects are always omitted. This objects are defined in [RFC9215][USING-GOST-IN-CERTS] and are provided here for convenience. 7.2.1. id-tc26-signwithdigest-gost3410-12-256 id-tc26-signwithdigest-gost3410-12-256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1) signwithdigest(3) gost3410-12-256(2) } The optional parameters field must be omitted. Name = id-tc26-signwithdigest-gost3410-12-256 OID = 1.2.643.7.1.1.3.2 Length = 12 0000: 300a 0608 2a85 0307 0101 0302 7.2.2. id-tc26-signwithdigest-gost3410-12-512 id-tc26-signwithdigest-gost3410-12-512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1) signwithdigest(3) gost3410-12-512(3) } The optional parameters field must be omitted. Name = id-tc26-signwithdigest-gost3410-12-512 OID = 1.2.643.7.1.1.3.3 Length = 12 0000: 300a 0608 2a85 0307 0101 0303 8. Security Considerations The security considerations of [RFC7296] and [RFC7427] apply accordingly. The security of GOST elliptic curves is discussed in [GOST-EC-SECURITY]. The security of "Streebog" hash function is discussed in [STREEBOG-SECURITY]. A second preimage attack on "Streebog" is described in [STREEBOG-PREIMAGE] if message size exceeds 2^259 blocks. This attack is not relevant to how "Streebog" is used in IKEv2. Smyslov Expires 9 June 2023 [Page 6] Internet-Draft GOST algorithms in IKEv2 December 2022 9. IANA Considerations IANA has assigned one Transform ID in the "Transform Type 2 - Pseudorandom Function Transform IDs" registry (where RFCXXXX is this document): Number Name Reference ------------------------------------------------- 9 PRF_HMAC_STREEBOG_512 [RFCXXXX] IANA has assigned two Transform IDs in the "Transform Type 4 - Diffie-Hellman Group Transform IDs" registry (where RFCXXXX is this document): Number Name Recipient Tests Reference --------------------------------------------------------------------- 33 GOST3410_2012_256 [RFCXXXX] Sec. 6.1 [RFCXXXX] 34 GOST3410_2012_512 [RFCXXXX] Sec. 6.1 [RFCXXXX] IANA has assigned two values in the "IKEv2 Hash Algorithms" registry (where RFCXXXX is this document): Number Hash Algorithm Reference ------------------------------------------------- 6 STREEBOG_256 [RFCXXXX] 7 STREEBOG_512 [RFCXXXX] 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 2013, . Smyslov Expires 9 June 2023 [Page 7] Internet-Draft GOST algorithms in IKEv2 December 2022 [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: Digital Signature Algorithm", RFC 7091, DOI 10.17487/RFC7091, December 2013, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, DOI 10.17487/RFC7427, January 2015, . [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012", RFC 7836, DOI 10.17487/RFC7836, March 2016, . [RFC9215] Baryshkov, D., Ed., Nikolaev, V., and A. Chelpanov, "Using GOST R 34.10-2012 and GOST R 34.11-2012 Algorithms with the Internet X.509 Public Key Infrastructure", RFC 9215, DOI 10.17487/RFC9215, March 2022, . [RFC9227] Smyslov, V., "Using GOST Ciphers in the Encapsulating Security Payload (ESP) and Internet Key Exchange Version 2 (IKEv2) Protocols", RFC 9227, DOI 10.17487/RFC9227, March 2022, . 10.2. Informative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, . [RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016, . Smyslov Expires 9 June 2023 [Page 8] Internet-Draft GOST algorithms in IKEv2 December 2022 [RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015: Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891, September 2020, . [GOST3410-2012] Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic data security. Signature and verification processes of [electronic] digital signature", GOST R 34.10-2012, 2012. (In Russian) [GOST3411-2012] Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic data security. Hashing function", GOST R 34.11-2012, 2012. (In Russian) [GOST3412-2015] Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic data security. Block ciphers", GOST R 34.12-2015, 2015. (In Russian) [GOST-IKEv2] Standardisation Technical Committee "Cryptographic information protection", "Information technology. Cryptographic information protection. The use of Russian cryptographic algorithms in the IKEv2 key exchange protocol", MR 26.2.001-22, 2022. (In Russian) [GOST-IKEv2-TESTVECTORS] Standardisation Technical Committee "Cryptographic information protection", "Information technology. Cryptographic information protection. The test vectors for the use of Russian cryptographic algorithms in the IKEv2 key exchange protocol", MR 26.2.002-22, 2022. (In Russian) [USING-GOST-IN-CERTS] Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic data security. Using GOST R 34.10-2012 and GOST R 34.11-2012 algorithms in X.509 Certificates, CRLs and PKCS #10 Certificate Requests", R 1323565.1.023-2018, 2018. (In Russian) [GOST-EC-SECURITY] Alekseev, E., Nikolaev, V., and S. Smyshlyaev, "On the security properties of Russian standardized elliptic curves", https://doi.org/10.4213/mvk260, 2018. Smyslov Expires 9 June 2023 [Page 9] Internet-Draft GOST algorithms in IKEv2 December 2022 [STREEBOG-SECURITY] Wang, Z., Yu, H., and X. Wang, "Cryptanalysis of GOST R hash function", https://doi.org/10.1016/j.ipl.2014.07.007, 2014. [STREEBOG-PREIMAGE] Guo, J., Jean, J., Leurent, G., Peyrin, T., and L. Wang, "The Usage of Counter Revisited: Second-Preimage Attack on New Russian Standardized Hash Function", https://eprint.iacr.org/2014/675, 2014. Appendix A. Test Vectors This Appendix contains test vectors for two scenarios. The test vectors were borrowed from [GOST-IKEv2-TESTVECTORS]. In both scenarios peers establish, rekey and delete IKE SA and ESP SAs. The IP addresses of the peers used in both scenarios are the same: * initiator's IP address is 10.111.10.171 * responder's IP address is 10.111.10.45 The test vectors also cover IKE message protection for transforms defined in [RFC9227]. The keys SK_ei, SK_er are transform keys (see Section 4.4 of [RFC9227]) and the keys K1i, K2i K3i, K1r, K2r, and K3r represent nodes in the key tree for the initiator and responder correspondently. The leaf keys K3i and K3r are effectively message protection keys (K_msg in terms of [RFC9227]). MGM nonces (also known as Initial Counter Nonces) are defined in Section 4.3 of [RFC9227]. IV format is defined in Section 4.2 of [RFC9227] and AAD format is defined in Section 4.7 of [RFC9227]. All other keys and entities used in the test vectors are defined in [RFC7296]. A.1. Scenario 1 With this scenario peers establish, rekey and delete IKE SA and ESP SAs using the following prerequisites: * Peers authenticate each other using preshared key * Initiator's ID is "IKE-Initiator" of type ID_FQDN * Responder's ID is "IKE-Responder" of type ID_FQDN * No NAT is present between the peers Smyslov Expires 9 June 2023 [Page 10] Internet-Draft GOST algorithms in IKEv2 December 2022 * IKE fragmentation is not used * IKE SA is created with the following transforms: - ENCR_KUZNYECHIK_MGM_KTREE - PRF_HMAC_STREEBOG_512 - GOST3410_2012_512 * ESP SAs are created with the following transforms: - ENCR_KUZNYECHIK_MGM_KTREE - ESN off The 256-bit preshared key (PSK) used for authentication: 00000000: e2 69 24 cf 15 32 93 47 3a 11 a4 97 a8 a4 5c b3 00000010: 4e 28 31 ef 0e 28 bb 77 69 69 c6 3c 68 bf e1 0d This scenario includes four sub-scenarios. Sub-scenario 1: Establishing of IKE and ESP SAs using the IKE_SA_INIT and the IKE_AUTH exchanges. Initiator Responder HDR, SAi1, KEi, Ni [,N+] ---> <--- HDR, SAr1, KEr, Nr [,N+] HDR, SK {IDi, [IDr,] [N+,] AUTH, SAi2, TSi, TSr} ---> <--- HDR, SK {IDr, [N+,] AUTH, SAr2, TSi, TSr} Initiator's actions: (1) Generates random SPIi for IKE SA 00000000: e9 d3 f3 78 19 1c 38 40 (2) Generates random IKE nonce Ni 00000000: 48 b6 d3 b3 ab 56 f2 c8 f0 42 d5 16 e7 21 d9 31 00000010: f9 ac 10 f9 7f 80 8c 51 2b d6 f4 59 93 a7 4d 13 (3) Generates ephemeral private key Smyslov Expires 9 June 2023 [Page 11] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 95 07 3a 04 dc db ce 77 f5 5e 4f fe 97 0c cd 6f 00000010: 0a e0 b5 c6 53 bd a0 da 47 fc 03 b5 8a e1 d5 1d 00000020: 89 e6 c0 db dc b1 ea 74 59 1f 1d 0c 9f 3f 4f dc 00000030: 10 d5 c9 cc a4 34 9c 3d 3e 6b dd 57 c5 d6 c9 01 (4) Computes public key 00000000: 96 1b 9b 21 4f 7e e9 83 ec 27 a0 64 0c 77 4f be 00000010: 78 31 be fd 1e 63 7d 6e 76 eb 2f 81 23 80 62 87 00000020: ba 2c f7 31 a2 70 b7 3e 8a 1d 91 93 72 cf 61 c8 00000030: d3 18 f6 bc f7 a0 44 c8 11 a7 fe d2 99 ea 8b 4d 00000040: 59 fa a7 38 ae 03 48 d2 aa f7 ff 11 e0 60 29 dd 00000050: 16 59 58 78 8e 3b e2 b5 48 36 3c ca 07 1a 5d be 00000060: a7 42 79 81 74 22 6f 53 15 d2 c2 f6 06 d4 0f ed 00000070: 70 f0 1c cf 89 2e ac 3c fe 01 02 91 85 06 7b d4 (5) Creates message IKE SA Init E9D3F378191C3840.0000000000000000.00000000 IKEv2 R<-I[316] SA[52]{ P[48](#1:IKE::5#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, ENCR_MAGMA_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_512, GOST3410_2012_256}}, KE[136](GOST3410_2012_512){961B9B...067BD4}, NONCE[36]{48B6D3...A74D13}, N[28](NAT_DETECTION_SOURCE_IP){92B291...F4E2BF}, N[28](NAT_DETECTION_DESTINATION_IP){77E199...98A613}, N[8](IKEV2_FRAGMENTATION_SUPPORTED) (6) Sends message, peer receives message Smyslov Expires 9 June 2023 [Page 12] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54294->10.111.15.45:500 [316] 00000000: e9 d3 f3 78 19 1c 38 40 00 00 00 00 00 00 00 00 00000010: 21 20 22 08 00 00 00 00 00 00 01 3c 22 00 00 34 00000020: 00 00 00 30 01 01 00 05 03 00 00 08 01 00 00 20 00000030: 03 00 00 08 01 00 00 21 03 00 00 08 02 00 00 09 00000040: 03 00 00 08 04 00 00 22 00 00 00 08 04 00 00 21 00000050: 28 00 00 88 00 22 00 00 96 1b 9b 21 4f 7e e9 83 00000060: ec 27 a0 64 0c 77 4f be 78 31 be fd 1e 63 7d 6e 00000070: 76 eb 2f 81 23 80 62 87 ba 2c f7 31 a2 70 b7 3e 00000080: 8a 1d 91 93 72 cf 61 c8 d3 18 f6 bc f7 a0 44 c8 00000090: 11 a7 fe d2 99 ea 8b 4d 59 fa a7 38 ae 03 48 d2 000000A0: aa f7 ff 11 e0 60 29 dd 16 59 58 78 8e 3b e2 b5 000000B0: 48 36 3c ca 07 1a 5d be a7 42 79 81 74 22 6f 53 000000C0: 15 d2 c2 f6 06 d4 0f ed 70 f0 1c cf 89 2e ac 3c 000000D0: fe 01 02 91 85 06 7b d4 29 00 00 24 48 b6 d3 b3 000000E0: ab 56 f2 c8 f0 42 d5 16 e7 21 d9 31 f9 ac 10 f9 000000F0: 7f 80 8c 51 2b d6 f4 59 93 a7 4d 13 29 00 00 1c 00000100: 00 00 40 04 92 b2 91 d3 9b 53 51 c8 33 c2 1f 2e 00000110: 92 ef 24 88 ef f4 e2 bf 29 00 00 1c 00 00 40 05 00000120: 77 e1 99 fe 3b 7e 33 42 b5 af ad 51 cf 97 91 4b 00000130: 08 98 a6 13 00 00 00 08 00 00 40 2e Responder's actions: (7) Parses received message IKE SA Init E9D3F378191C3840.0000000000000000.00000000 IKEv2 I->R[316] SA[52]{ P[48](#1:IKE::5#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, ENCR_MAGMA_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_512, GOST3410_2012_256}}, KE[136](GOST3410_2012_512){961B9B...067BD4}, NONCE[36]{48B6D3...A74D13}, N[28](NAT_DETECTION_SOURCE_IP){92B291...F4E2BF}, N[28](NAT_DETECTION_DESTINATION_IP){77E199...98A613}, N[8](IKEV2_FRAGMENTATION_SUPPORTED) (8) Generates random SPIr for IKE SA 00000000: 8d df f4 01 fb fb 0b 14 (9) Generates random IKE nonce Nr Smyslov Expires 9 June 2023 [Page 13] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: fb 81 c8 80 e5 f0 35 60 99 ef 46 b2 72 44 95 0f 00000010: 03 85 f4 73 92 67 b7 68 43 8f 90 69 16 fe 63 f0 (10) Generates ephemeral private key 00000000: 7f 49 e3 77 39 db 03 cc fe fe c9 63 17 71 e9 f1 00000010: 50 4b 98 79 b3 df 3b 48 bd f3 89 72 52 07 47 4f 00000020: 70 29 f8 39 63 2c 89 b6 92 39 18 27 9c fb 80 f5 00000030: 43 af 8b 9c 68 bb 93 22 1e 18 7d c2 1b dc e1 22 (11) Computes public key 00000000: ad b4 e4 db b9 af 28 59 ab 76 4d 30 fd d4 7a f3 00000010: 5f 8c cb 85 8c cc ca 30 5e 4a 9d 20 52 32 48 88 00000020: 69 81 48 5e ae db 1e 8c 0d 8d db 12 3e f5 ef 1d 00000030: 7f e8 83 39 7f e6 5d 6e 51 ca 9e ee f5 b6 ba 02 00000040: db 10 87 47 ba 38 b3 17 95 60 6d a3 81 15 5c 3d 00000050: 6b 86 d3 59 2f 5f 74 14 17 a9 64 20 3d 05 12 08 00000060: 02 75 15 ac ff 08 7c aa 82 1d f6 89 6c f4 33 e0 00000070: 01 4e 11 68 73 7e e3 e9 c6 88 ce 90 9b 39 05 48 (12) Creates message IKE SA Init E9D3F378191C3840.8DDFF401FBFB0B14.00000000 IKEv2 I<=R[300] SA[36]{ P[32](#1:IKE::3#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_512}}, KE[136](GOST3410_2012_512){ADB4E4...390548}, NONCE[36]{FB81C8...FE63F0}, N[28](NAT_DETECTION_SOURCE_IP){6D7A48...683D59}, N[28](NAT_DETECTION_DESTINATION_IP){481A5B...905499}, N[8](IKEV2_FRAGMENTATION_SUPPORTED) (13) Sends message, peer receives message Smyslov Expires 9 June 2023 [Page 14] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54294<-10.111.15.45:500 [300] 00000000: e9 d3 f3 78 19 1c 38 40 8d df f4 01 fb fb 0b 14 00000010: 21 20 22 20 00 00 00 00 00 00 01 2c 22 00 00 24 00000020: 00 00 00 20 01 01 00 03 03 00 00 08 01 00 00 20 00000030: 03 00 00 08 02 00 00 09 00 00 00 08 04 00 00 22 00000040: 28 00 00 88 00 22 00 00 ad b4 e4 db b9 af 28 59 00000050: ab 76 4d 30 fd d4 7a f3 5f 8c cb 85 8c cc ca 30 00000060: 5e 4a 9d 20 52 32 48 88 69 81 48 5e ae db 1e 8c 00000070: 0d 8d db 12 3e f5 ef 1d 7f e8 83 39 7f e6 5d 6e 00000080: 51 ca 9e ee f5 b6 ba 02 db 10 87 47 ba 38 b3 17 00000090: 95 60 6d a3 81 15 5c 3d 6b 86 d3 59 2f 5f 74 14 000000A0: 17 a9 64 20 3d 05 12 08 02 75 15 ac ff 08 7c aa 000000B0: 82 1d f6 89 6c f4 33 e0 01 4e 11 68 73 7e e3 e9 000000C0: c6 88 ce 90 9b 39 05 48 29 00 00 24 fb 81 c8 80 000000D0: e5 f0 35 60 99 ef 46 b2 72 44 95 0f 03 85 f4 73 000000E0: 92 67 b7 68 43 8f 90 69 16 fe 63 f0 29 00 00 1c 000000F0: 00 00 40 04 6d 7a 48 7a 9d ce 80 6f b0 09 4b f7 00000100: 8d fd ec eb 2e 68 3d 59 29 00 00 1c 00 00 40 05 00000110: 48 1a 5b 15 12 e4 26 a3 8d 88 8b 65 8e 17 b3 f1 00000120: 38 90 54 99 00 00 00 08 00 00 40 2e Initiator's actions: (14) Parses received message IKE SA Init E9D3F378191C3840.8DDFF401FBFB0B14.00000000 IKEv2 R=>I[300] SA[36]{ P[32](#1:IKE::3#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_512}}, KE[136](GOST3410_2012_512){ADB4E4...390548}, NONCE[36]{FB81C8...FE63F0}, N[28](NAT_DETECTION_SOURCE_IP){6D7A48...683D59}, N[28](NAT_DETECTION_DESTINATION_IP){481A5B...905499}, N[8](IKEV2_FRAGMENTATION_SUPPORTED) (15) Computes shared key 00000000: a2 43 6c bd 2d c1 0f 81 0d f7 6f 24 ae 78 70 f2 00000010: 27 5d 1b dc c5 52 0e d8 53 e5 c5 43 98 f7 35 ce 00000020: 32 70 89 2b 8e 89 0b 7d b3 98 77 cd bd 31 5d 18 00000030: 10 5d 8b ac 16 f0 aa fd bc dc 7c 69 75 14 48 a8 (16) Computes SKEYSEED Smyslov Expires 9 June 2023 [Page 15] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: fc 7b d9 80 4b 15 00 60 d2 08 17 3a 08 4b a9 2a 00000010: 0f 01 cb c3 ef e9 b5 aa 15 5b 0e 80 24 68 3c 4c 00000020: 6c fb e9 c8 16 7d 54 2d 48 ee 61 71 01 68 ca 68 00000030: 4f 7c b0 1b 61 29 20 9a 68 88 5b 3f d7 19 0b d0 (17) Computes SK_d 00000000: 6b 2b 83 d7 a9 10 5f f4 27 e8 05 86 b7 f0 09 31 00000010: 16 43 81 ae 88 7a 3f c9 65 30 73 00 e5 82 81 52 00000020: 68 07 ba e5 39 ef 6e a7 75 db 2c c9 1c d3 4b 70 00000030: e0 be 97 14 81 bb 0c 80 ef b3 6e 12 2a 08 74 36 (18) Computes SK_ei 00000000: 8c 6d f1 8f 6a ff 9f 1b 3e be 40 ef e2 64 c2 bf 00000010: 8e 6e d7 4c b5 8b 0a 74 a7 30 0c 21 7e 66 c7 d4 00000020: 83 00 37 c3 08 01 7e c3 0a 71 62 01 (19) Computes SK_er 00000000: df e8 7d 5f 9c da 5e 45 b8 b9 11 02 63 6c 08 47 00000010: f6 4f c5 5d 6a 7b 4b 91 52 32 0a a2 5e c0 31 34 00000020: 65 20 72 e7 0a 1e ff 7d da ba 17 31 (20) Computes SK_pi 00000000: 93 11 c6 4c d7 12 b5 40 f9 e8 7e 73 c5 28 a7 d8 00000010: 89 48 1c f1 bf a3 ad 67 cf b4 d9 6a 9b fe 3c ea 00000020: 2f cc 2a 5e d4 e4 0b 27 7f be c9 9d c3 8d b7 68 00000030: 03 c1 f3 f8 94 af 47 8b d8 35 b8 6b c2 ca 38 16 (21) Computes SK_pr 00000000: 7b b0 4b 24 74 9c 73 68 7f 34 a3 b8 17 6b 9e 30 00000010: f2 eb 33 73 23 ff 49 1e e3 07 e7 9f 77 b6 2a ef 00000020: 5a 5e a9 02 8e 90 5c 83 49 ec 1e aa a4 05 bc e1 00000030: fb c4 5b f0 27 d6 9b 41 77 6f e1 48 f3 37 99 e5 (22) Computes prf(SK_pi, IDi) 00000000: 06 d3 d4 36 ab 5b 4f 41 d4 3d fc 79 1f 13 a3 89 00000010: e9 a6 6e d7 87 7d 72 d1 9d 71 78 2d 05 ee 47 fb 00000020: 82 c8 8f 86 cd b5 05 1d 25 7c 1e 79 18 ef 4e 4e 00000030: 8d ca f4 47 12 c6 7f 6a 32 7d d8 e8 f2 8e f8 33 (23) Uses PSK Smyslov Expires 9 June 2023 [Page 16] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: e2 69 24 cf 15 32 93 47 3a 11 a4 97 a8 a4 5c b3 00000010: 4e 28 31 ef 0e 28 bb 77 69 69 c6 3c 68 bf e1 0d (24) Computes prf(PSK,"Key Pad for IKEv2") 00000000: 01 3c a5 24 59 4e bc 78 99 20 61 6c 3f 03 e5 2e 00000010: 7a 75 2a 0b 78 36 bd 0a 89 ce 1d e7 8b 23 32 ae 00000020: 08 9a a0 03 1d da f6 14 8c 38 c6 bd 7c 03 13 24 00000030: bd af c8 ad 88 18 8f 41 d0 12 b9 e1 5a 66 8f 10 (25) Computes content of AUTH payload 00000000: c9 9b 01 9a 89 ee 56 53 ab 28 25 a1 d7 51 54 ac 00000010: 01 42 fb d6 2e bc 1e f3 65 73 63 5b 16 81 4b 97 00000020: 38 b4 20 5d 09 d9 b4 21 b4 0c f4 55 27 80 e7 4c 00000030: cf 66 d0 14 25 87 7c 20 84 68 d5 79 3a 74 1e e3 (26) Computes K1i (i1 = 0) 00000000: f2 ac 10 7a 1f 92 d1 b1 1b b1 74 c3 42 76 a3 3f 00000010: fa ea 1b 1e 81 10 c1 01 7a 25 9a 00 8d 76 57 de (27) Computes K2i (i2 = 0) 00000000: 77 e0 16 18 ad 76 e8 5a 66 2f 88 c4 c0 92 ec 33 00000010: 6d 23 63 28 28 d5 77 d8 84 e1 01 b1 8d 84 a7 1d (28) Computes K3i (i3 = 0) 00000000: 36 ff fa db 84 a9 f1 21 d5 84 16 db eb af 21 a2 00000010: 12 6d 5c 35 95 fe 89 cf 27 47 52 8a b7 36 92 d4 (29) Selects SPI for incoming ESP SA 00000000: 0a de 5f cd (30) Creates message Smyslov Expires 9 June 2023 [Page 17] Internet-Draft GOST algorithms in IKEv2 December 2022 IKE SA Auth E9D3F378191C3840.8DDFF401FBFB0B14.00000001 IKEv2 R<-I[334] E[306]{ IDi[21](FQDN){"IKE-Initiator"}, AUTH[72](Preshared-Key){C99B01...741EE3}, N[8](INITIAL_CONTACT), N[12](SET_WINDOW_SIZE){4}, CP[16](REQUEST){IP4.Address[0], IP4.DNS[0]}, SA[56]{ P[52](#1:ESP:0ADE5FCD:5#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, ENCR_MAGMA_MGM_KTREE, ENCR_KUZNYECHIK_MGM_MAC_KTREE, ENCR_MAGMA_MGM_MAC_KTREE, ESN=Off}}, TSi[40](2#){10.111.10.171:icmp:8.0, 0.0.0.0-255.255.255.255}, TSr[40](2#){10.0.0.2:icmp:8.0, 10.0.0.0-10.0.0.255}, N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} (31) Composes MGM nonce 00000000: 00 00 00 00 83 00 37 c3 08 01 7e c3 0a 71 62 01 (32) Composes AAD 00000000: e9 d3 f3 78 19 1c 38 40 8d df f4 01 fb fb 0b 14 00000010: 2e 20 23 08 00 00 00 01 00 00 01 4e 23 00 01 32 (33) Composes plaintext Smyslov Expires 9 June 2023 [Page 18] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 27 00 00 15 02 00 00 00 49 4b 45 2d 49 6e 69 74 00000010: 69 61 74 6f 72 29 00 00 48 02 00 00 00 c9 9b 01 00000020: 9a 89 ee 56 53 ab 28 25 a1 d7 51 54 ac 01 42 fb 00000030: d6 2e bc 1e f3 65 73 63 5b 16 81 4b 97 38 b4 20 00000040: 5d 09 d9 b4 21 b4 0c f4 55 27 80 e7 4c cf 66 d0 00000050: 14 25 87 7c 20 84 68 d5 79 3a 74 1e e3 29 00 00 00000060: 08 00 00 40 00 2f 00 00 0c 00 00 40 01 00 00 00 00000070: 04 21 00 00 10 01 00 00 00 00 01 00 00 00 03 00 00000080: 00 2c 00 00 38 00 00 00 34 01 03 04 05 0a de 5f 00000090: cd 03 00 00 08 01 00 00 20 03 00 00 08 01 00 00 000000A0: 21 03 00 00 08 01 00 00 22 03 00 00 08 01 00 00 000000B0: 23 00 00 00 08 05 00 00 00 2d 00 00 28 02 00 00 000000C0: 00 07 01 00 10 08 00 08 00 0a 6f 0a ab 0a 6f 0a 000000D0: ab 07 00 00 10 00 00 ff ff 00 00 00 00 ff ff ff 000000E0: ff 29 00 00 28 02 00 00 00 07 01 00 10 08 00 08 000000F0: 00 0a 00 00 02 0a 00 00 02 07 00 00 10 00 00 ff 00000100: ff 0a 00 00 00 0a 00 00 ff 29 00 00 08 00 00 40 00000110: 0a 00 00 00 08 00 00 40 0b 00 (34) Encrypts plaintext using K3i as K_msg, resulted in ciphertext 00000000: a5 7d 65 70 aa c3 ef f7 df d6 5c 58 f6 2e ea 80 00000010: 82 15 dc 9d ae 42 1c f0 4c e4 cd 2a 45 f0 22 96 00000020: ea d2 06 cc 9b 59 97 9e 45 5d 27 5f b4 fd 55 6a 00000030: 90 bb 14 da df 9f 56 b0 e8 4c 89 a5 d8 f1 f6 55 00000040: a9 f0 82 90 57 28 86 a5 bd 12 85 2f 2e 51 54 29 00000050: fe 04 45 a4 90 f0 f8 0e 8b e9 c7 37 05 8f 6b bb 00000060: 36 b0 24 8a 5f a3 ca f3 7e 7d f9 8e 73 4b b0 14 00000070: ce b0 af 63 4c 4f ea 60 f6 46 4c 61 76 7c 9f 18 00000080: 0c 61 73 fa 30 9f 91 c4 22 c9 ab 61 80 5a de 8e 00000090: 06 40 36 7a 71 59 a5 ad 1c 67 25 03 9b af 2b 04 000000A0: 9f c1 de 51 11 7b f1 16 20 81 78 3f a8 01 d6 c8 000000B0: 79 89 d9 65 3e ea 58 6d ac 48 fc 4a 9a b9 48 02 000000C0: d7 2b 01 5d 6a 2d cb 65 bb ad 99 86 e2 03 08 76 000000D0: 1b dd 7c 56 3c 49 a4 2c da 24 1f ad 54 79 f5 d8 000000E0: 0e 52 8a 49 92 90 66 80 85 00 b7 d8 89 5f b7 f4 000000F0: 92 c1 5b ed 8a 16 00 f3 9a f8 90 4b fa 6a b2 de 00000100: 2a 89 74 9f 99 c7 c3 57 88 5b 88 95 5c ec 46 52 00000110: 04 c4 49 08 05 ab ee 1c 80 f6 (35) Computes ICV using K3i as K_msg 00000000: 7a 4f 14 38 e6 5f 6b 8c f5 5d 55 f5 (36) Composes IV 00000000: 00 00 00 00 00 00 00 00 Smyslov Expires 9 June 2023 [Page 19] Internet-Draft GOST algorithms in IKEv2 December 2022 (37) Sends message, peer receives message 10.111.10.171:54294->10.111.15.45:500 [334] 00000000: e9 d3 f3 78 19 1c 38 40 8d df f4 01 fb fb 0b 14 00000010: 2e 20 23 08 00 00 00 01 00 00 01 4e 23 00 01 32 00000020: 00 00 00 00 00 00 00 00 a5 7d 65 70 aa c3 ef f7 00000030: df d6 5c 58 f6 2e ea 80 82 15 dc 9d ae 42 1c f0 00000040: 4c e4 cd 2a 45 f0 22 96 ea d2 06 cc 9b 59 97 9e 00000050: 45 5d 27 5f b4 fd 55 6a 90 bb 14 da df 9f 56 b0 00000060: e8 4c 89 a5 d8 f1 f6 55 a9 f0 82 90 57 28 86 a5 00000070: bd 12 85 2f 2e 51 54 29 fe 04 45 a4 90 f0 f8 0e 00000080: 8b e9 c7 37 05 8f 6b bb 36 b0 24 8a 5f a3 ca f3 00000090: 7e 7d f9 8e 73 4b b0 14 ce b0 af 63 4c 4f ea 60 000000A0: f6 46 4c 61 76 7c 9f 18 0c 61 73 fa 30 9f 91 c4 000000B0: 22 c9 ab 61 80 5a de 8e 06 40 36 7a 71 59 a5 ad 000000C0: 1c 67 25 03 9b af 2b 04 9f c1 de 51 11 7b f1 16 000000D0: 20 81 78 3f a8 01 d6 c8 79 89 d9 65 3e ea 58 6d 000000E0: ac 48 fc 4a 9a b9 48 02 d7 2b 01 5d 6a 2d cb 65 000000F0: bb ad 99 86 e2 03 08 76 1b dd 7c 56 3c 49 a4 2c 00000100: da 24 1f ad 54 79 f5 d8 0e 52 8a 49 92 90 66 80 00000110: 85 00 b7 d8 89 5f b7 f4 92 c1 5b ed 8a 16 00 f3 00000120: 9a f8 90 4b fa 6a b2 de 2a 89 74 9f 99 c7 c3 57 00000130: 88 5b 88 95 5c ec 46 52 04 c4 49 08 05 ab ee 1c 00000140: 80 f6 7a 4f 14 38 e6 5f 6b 8c f5 5d 55 f5 Responder's actions: (38) Computes shared key 00000000: a2 43 6c bd 2d c1 0f 81 0d f7 6f 24 ae 78 70 f2 00000010: 27 5d 1b dc c5 52 0e d8 53 e5 c5 43 98 f7 35 ce 00000020: 32 70 89 2b 8e 89 0b 7d b3 98 77 cd bd 31 5d 18 00000030: 10 5d 8b ac 16 f0 aa fd bc dc 7c 69 75 14 48 a8 (39) Computes SKEYSEED 00000000: fc 7b d9 80 4b 15 00 60 d2 08 17 3a 08 4b a9 2a 00000010: 0f 01 cb c3 ef e9 b5 aa 15 5b 0e 80 24 68 3c 4c 00000020: 6c fb e9 c8 16 7d 54 2d 48 ee 61 71 01 68 ca 68 00000030: 4f 7c b0 1b 61 29 20 9a 68 88 5b 3f d7 19 0b d0 (40) Computes SK_d 00000000: 6b 2b 83 d7 a9 10 5f f4 27 e8 05 86 b7 f0 09 31 00000010: 16 43 81 ae 88 7a 3f c9 65 30 73 00 e5 82 81 52 00000020: 68 07 ba e5 39 ef 6e a7 75 db 2c c9 1c d3 4b 70 00000030: e0 be 97 14 81 bb 0c 80 ef b3 6e 12 2a 08 74 36 Smyslov Expires 9 June 2023 [Page 20] Internet-Draft GOST algorithms in IKEv2 December 2022 (41) Computes SK_ei 00000000: 8c 6d f1 8f 6a ff 9f 1b 3e be 40 ef e2 64 c2 bf 00000010: 8e 6e d7 4c b5 8b 0a 74 a7 30 0c 21 7e 66 c7 d4 00000020: 83 00 37 c3 08 01 7e c3 0a 71 62 01 (42) Computes SK_er 00000000: df e8 7d 5f 9c da 5e 45 b8 b9 11 02 63 6c 08 47 00000010: f6 4f c5 5d 6a 7b 4b 91 52 32 0a a2 5e c0 31 34 00000020: 65 20 72 e7 0a 1e ff 7d da ba 17 31 (43) Computes SK_pi 00000000: 93 11 c6 4c d7 12 b5 40 f9 e8 7e 73 c5 28 a7 d8 00000010: 89 48 1c f1 bf a3 ad 67 cf b4 d9 6a 9b fe 3c ea 00000020: 2f cc 2a 5e d4 e4 0b 27 7f be c9 9d c3 8d b7 68 00000030: 03 c1 f3 f8 94 af 47 8b d8 35 b8 6b c2 ca 38 16 (44) Computes SK_pr 00000000: 7b b0 4b 24 74 9c 73 68 7f 34 a3 b8 17 6b 9e 30 00000010: f2 eb 33 73 23 ff 49 1e e3 07 e7 9f 77 b6 2a ef 00000020: 5a 5e a9 02 8e 90 5c 83 49 ec 1e aa a4 05 bc e1 00000030: fb c4 5b f0 27 d6 9b 41 77 6f e1 48 f3 37 99 e5 (45) Extracts IV from message 00000000: 00 00 00 00 00 00 00 00 (46) Computes K1i (i1 = 0) 00000000: f2 ac 10 7a 1f 92 d1 b1 1b b1 74 c3 42 76 a3 3f 00000010: fa ea 1b 1e 81 10 c1 01 7a 25 9a 00 8d 76 57 de (47) Computes K2i (i2 = 0) 00000000: 77 e0 16 18 ad 76 e8 5a 66 2f 88 c4 c0 92 ec 33 00000010: 6d 23 63 28 28 d5 77 d8 84 e1 01 b1 8d 84 a7 1d (48) Computes K3i (i3 = 0) 00000000: 36 ff fa db 84 a9 f1 21 d5 84 16 db eb af 21 a2 00000010: 12 6d 5c 35 95 fe 89 cf 27 47 52 8a b7 36 92 d4 (49) Composes MGM nonce 00000000: 00 00 00 00 83 00 37 c3 08 01 7e c3 0a 71 62 01 Smyslov Expires 9 June 2023 [Page 21] Internet-Draft GOST algorithms in IKEv2 December 2022 (50) Extracts ICV from message 00000000: 7a 4f 14 38 e6 5f 6b 8c f5 5d 55 f5 (51) Extracts AAD from message 00000000: e9 d3 f3 78 19 1c 38 40 8d df f4 01 fb fb 0b 14 00000010: 2e 20 23 08 00 00 00 01 00 00 01 4e 23 00 01 32 (52) Extracts ciphertext from message 00000000: a5 7d 65 70 aa c3 ef f7 df d6 5c 58 f6 2e ea 80 00000010: 82 15 dc 9d ae 42 1c f0 4c e4 cd 2a 45 f0 22 96 00000020: ea d2 06 cc 9b 59 97 9e 45 5d 27 5f b4 fd 55 6a 00000030: 90 bb 14 da df 9f 56 b0 e8 4c 89 a5 d8 f1 f6 55 00000040: a9 f0 82 90 57 28 86 a5 bd 12 85 2f 2e 51 54 29 00000050: fe 04 45 a4 90 f0 f8 0e 8b e9 c7 37 05 8f 6b bb 00000060: 36 b0 24 8a 5f a3 ca f3 7e 7d f9 8e 73 4b b0 14 00000070: ce b0 af 63 4c 4f ea 60 f6 46 4c 61 76 7c 9f 18 00000080: 0c 61 73 fa 30 9f 91 c4 22 c9 ab 61 80 5a de 8e 00000090: 06 40 36 7a 71 59 a5 ad 1c 67 25 03 9b af 2b 04 000000A0: 9f c1 de 51 11 7b f1 16 20 81 78 3f a8 01 d6 c8 000000B0: 79 89 d9 65 3e ea 58 6d ac 48 fc 4a 9a b9 48 02 000000C0: d7 2b 01 5d 6a 2d cb 65 bb ad 99 86 e2 03 08 76 000000D0: 1b dd 7c 56 3c 49 a4 2c da 24 1f ad 54 79 f5 d8 000000E0: 0e 52 8a 49 92 90 66 80 85 00 b7 d8 89 5f b7 f4 000000F0: 92 c1 5b ed 8a 16 00 f3 9a f8 90 4b fa 6a b2 de 00000100: 2a 89 74 9f 99 c7 c3 57 88 5b 88 95 5c ec 46 52 00000110: 04 c4 49 08 05 ab ee 1c 80 f6 (53) Decrypts ciphertext and verifies ICV using K3i as K_msg, resulted in plaintext Smyslov Expires 9 June 2023 [Page 22] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 27 00 00 15 02 00 00 00 49 4b 45 2d 49 6e 69 74 00000010: 69 61 74 6f 72 29 00 00 48 02 00 00 00 c9 9b 01 00000020: 9a 89 ee 56 53 ab 28 25 a1 d7 51 54 ac 01 42 fb 00000030: d6 2e bc 1e f3 65 73 63 5b 16 81 4b 97 38 b4 20 00000040: 5d 09 d9 b4 21 b4 0c f4 55 27 80 e7 4c cf 66 d0 00000050: 14 25 87 7c 20 84 68 d5 79 3a 74 1e e3 29 00 00 00000060: 08 00 00 40 00 2f 00 00 0c 00 00 40 01 00 00 00 00000070: 04 21 00 00 10 01 00 00 00 00 01 00 00 00 03 00 00000080: 00 2c 00 00 38 00 00 00 34 01 03 04 05 0a de 5f 00000090: cd 03 00 00 08 01 00 00 20 03 00 00 08 01 00 00 000000A0: 21 03 00 00 08 01 00 00 22 03 00 00 08 01 00 00 000000B0: 23 00 00 00 08 05 00 00 00 2d 00 00 28 02 00 00 000000C0: 00 07 01 00 10 08 00 08 00 0a 6f 0a ab 0a 6f 0a 000000D0: ab 07 00 00 10 00 00 ff ff 00 00 00 00 ff ff ff 000000E0: ff 29 00 00 28 02 00 00 00 07 01 00 10 08 00 08 000000F0: 00 0a 00 00 02 0a 00 00 02 07 00 00 10 00 00 ff 00000100: ff 0a 00 00 00 0a 00 00 ff 29 00 00 08 00 00 40 00000110: 0a 00 00 00 08 00 00 40 0b 00 (54) Parses received message IKE SA Auth E9D3F378191C3840.8DDFF401FBFB0B14.00000001 IKEv2 I->R[334] E[306]{ IDi[21](FQDN){"IKE-Initiator"}, AUTH[72](Preshared-Key){C99B01...741EE3}, N[8](INITIAL_CONTACT), N[12](SET_WINDOW_SIZE){4}, CP[16](REQUEST){IP4.Address[0], IP4.DNS[0]}, SA[56]{ P[52](#1:ESP:0ADE5FCD:5#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, ENCR_MAGMA_MGM_KTREE, ENCR_KUZNYECHIK_MGM_MAC_KTREE, ENCR_MAGMA_MGM_MAC_KTREE, ESN=Off}}, TSi[40](2#){10.111.10.171:icmp:8.0, 0.0.0.0-255.255.255.255}, TSr[40](2#){10.0.0.2:icmp:8.0, 10.0.0.0-10.0.0.255}, N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} (55) Computes prf(SK_pi, IDi) 00000000: 06 d3 d4 36 ab 5b 4f 41 d4 3d fc 79 1f 13 a3 89 00000010: e9 a6 6e d7 87 7d 72 d1 9d 71 78 2d 05 ee 47 fb 00000020: 82 c8 8f 86 cd b5 05 1d 25 7c 1e 79 18 ef 4e 4e 00000030: 8d ca f4 47 12 c6 7f 6a 32 7d d8 e8 f2 8e f8 33 Smyslov Expires 9 June 2023 [Page 23] Internet-Draft GOST algorithms in IKEv2 December 2022 (56) Uses PSK 00000000: e2 69 24 cf 15 32 93 47 3a 11 a4 97 a8 a4 5c b3 00000010: 4e 28 31 ef 0e 28 bb 77 69 69 c6 3c 68 bf e1 0d (57) Computes prf(PSK,"Key Pad for IKEv2") 00000000: 01 3c a5 24 59 4e bc 78 99 20 61 6c 3f 03 e5 2e 00000010: 7a 75 2a 0b 78 36 bd 0a 89 ce 1d e7 8b 23 32 ae 00000020: 08 9a a0 03 1d da f6 14 8c 38 c6 bd 7c 03 13 24 00000030: bd af c8 ad 88 18 8f 41 d0 12 b9 e1 5a 66 8f 10 (58) Computes content of AUTH payload and compares it with the received one 00000000: c9 9b 01 9a 89 ee 56 53 ab 28 25 a1 d7 51 54 ac 00000010: 01 42 fb d6 2e bc 1e f3 65 73 63 5b 16 81 4b 97 00000020: 38 b4 20 5d 09 d9 b4 21 b4 0c f4 55 27 80 e7 4c 00000030: cf 66 d0 14 25 87 7c 20 84 68 d5 79 3a 74 1e e3 (59) Computes keys for ESP SAs 00000000: ff 42 3b a3 78 29 2b 10 52 c8 bf 06 fa ba 6d 5f 00000010: e2 db 51 1b 74 1b 54 ad 35 85 e3 cf 2b 77 52 42 00000020: bc 8c d8 ba dd f4 46 9e 89 41 5c d6 00000000: 8c eb 84 af 18 01 18 36 b7 8d 65 be 03 ca 69 64 00000010: 89 6e a8 91 03 bc 9a dc bd 49 10 ab 20 83 9f 83 00000020: b1 7c 45 9d ab d8 ab 6f de 6a 62 d1 (60) Computes prf(SK_pr,IDr) 00000000: 32 61 00 71 e8 1a d6 a1 12 8d ef 4e 2a e9 bb c2 00000010: 9f 3d ba 28 1b 2a a5 10 a2 ad c6 b1 73 07 c9 f1 00000020: 50 9e 1c d7 a5 85 8f a8 40 ef dd a7 ae 33 71 74 00000030: c8 8b a9 f4 3a 83 0f c1 c5 3c 9b 21 9f a9 58 25 (61) Uses PSK 00000000: e2 69 24 cf 15 32 93 47 3a 11 a4 97 a8 a4 5c b3 00000010: 4e 28 31 ef 0e 28 bb 77 69 69 c6 3c 68 bf e1 0d (62) Computes prf(PSK,"Key Pad for IKEv2") 00000000: 01 3c a5 24 59 4e bc 78 99 20 61 6c 3f 03 e5 2e 00000010: 7a 75 2a 0b 78 36 bd 0a 89 ce 1d e7 8b 23 32 ae 00000020: 08 9a a0 03 1d da f6 14 8c 38 c6 bd 7c 03 13 24 00000030: bd af c8 ad 88 18 8f 41 d0 12 b9 e1 5a 66 8f 10 Smyslov Expires 9 June 2023 [Page 24] Internet-Draft GOST algorithms in IKEv2 December 2022 (63) Computes content of AUTH payload 00000000: 35 ce 8a ab dd 3d b1 5f 38 7b 2e c9 a6 24 7a 1f 00000010: a7 bb a0 6f b6 5e d8 81 07 d3 43 c8 a5 db 37 51 00000020: 0e 9d 9a 85 66 18 7a 0f 5c e2 1b fb 27 56 65 ed 00000030: 0e 41 fe ce 5e 95 bf 8a ae 57 f6 d6 26 d2 d1 2d (64) Computes K1r (i1 = 0) 00000000: 61 cd ad b1 01 10 71 7c dc 18 81 1d 1f aa e3 13 00000010: 4b 07 f8 f7 49 a7 3d 0a 57 2f e1 61 bc ab 85 c4 (65) Computes K2r (i2 = 0) 00000000: 5f e7 47 77 da f7 54 d7 a8 e5 eb ed f9 82 c8 a9 00000010: 74 0c 54 77 6f eb b8 70 a4 43 43 3e c2 9e ce a6 (66) Computes K3r (i3 = 0) 00000000: e8 af 72 c4 c3 55 a2 6a fb ad 37 fd b4 b9 7f d6 00000010: f6 c8 cc 32 3f 50 32 40 06 86 ce 85 1b 02 28 f3 (67) Selects SPI for incoming ESP SA 00000000: 50 3c 8d af (68) Creates message IKE SA Auth E9D3F378191C3840.8DDFF401FBFB0B14.00000001 IKEv2 I<=R[286] E[258]{ IDr[21](FQDN){"IKE-Responder"}, AUTH[72](Preshared-Key){35CE8A...D2D12D}, N[8](INITIAL_CONTACT), N[12](SET_WINDOW_SIZE){64}, CP[16](REPLY){IP4.Address[4]=10.1.1.2}, SA[32]{ P[28](#1:ESP:503C8DAF:2#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, ESN=Off}}, TSi[24](1#){10.1.1.2}, TSr[24](1#){10.0.0.0-10.0.0.255}, N[8](ADDITIONAL_TS_POSSIBLE), N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} (69) Composes MGM nonce Smyslov Expires 9 June 2023 [Page 25] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 00 00 00 00 65 20 72 e7 0a 1e ff 7d da ba 17 31 (70) Composes AAD 00000000: e9 d3 f3 78 19 1c 38 40 8d df f4 01 fb fb 0b 14 00000010: 2e 20 23 20 00 00 00 01 00 00 01 1e 24 00 01 02 (71) Composes plaintext 00000000: 27 00 00 15 02 00 00 00 49 4b 45 2d 52 65 73 70 00000010: 6f 6e 64 65 72 29 00 00 48 02 00 00 00 35 ce 8a 00000020: ab dd 3d b1 5f 38 7b 2e c9 a6 24 7a 1f a7 bb a0 00000030: 6f b6 5e d8 81 07 d3 43 c8 a5 db 37 51 0e 9d 9a 00000040: 85 66 18 7a 0f 5c e2 1b fb 27 56 65 ed 0e 41 fe 00000050: ce 5e 95 bf 8a ae 57 f6 d6 26 d2 d1 2d 29 00 00 00000060: 08 00 00 40 00 2f 00 00 0c 00 00 40 01 00 00 00 00000070: 40 21 00 00 10 02 00 00 00 00 01 00 04 0a 01 01 00000080: 02 2c 00 00 20 00 00 00 1c 01 03 04 02 50 3c 8d 00000090: af 03 00 00 08 01 00 00 20 00 00 00 08 05 00 00 000000A0: 00 2d 00 00 18 01 00 00 00 07 00 00 10 00 00 ff 000000B0: ff 0a 01 01 02 0a 01 01 02 29 00 00 18 01 00 00 000000C0: 00 07 00 00 10 00 00 ff ff 0a 00 00 00 0a 00 00 000000D0: ff 29 00 00 08 00 00 40 02 29 00 00 08 00 00 40 000000E0: 0a 00 00 00 08 00 00 40 0b 00 (72) Encrypts plaintext using K3r as K_msg, resulted in ciphertext 00000000: 9b 5d 58 8a 99 44 11 d6 5b 93 7f 98 57 0d 0f 09 00000010: 0c a3 d9 36 41 b5 9c 91 94 17 3a cb 00 88 24 5e 00000020: 25 b7 0d 75 2f fb 4d d0 ab 2c cc 84 42 e7 f8 1b 00000030: 5a e6 88 13 9a 3e b1 03 79 31 0c 69 f6 17 a2 40 00000040: f8 aa 74 2e 62 29 ee 57 43 3f 10 bf 44 73 51 97 00000050: 2c 93 a4 02 87 3d 37 45 2c f1 3e 16 c3 d9 ec b3 00000060: b8 6f 66 1a f1 73 44 7c db 74 11 e6 07 4a 75 23 00000070: 83 df 00 52 ae 68 60 39 83 4c c3 b1 d5 7a e8 7f 00000080: 61 59 9e 4f 92 3c 2f 04 3b c3 ac e7 23 3f 1c a7 00000090: a5 3f 4d 33 1f 46 25 9f 09 5e f4 75 e0 12 32 5b 000000A0: 29 64 a4 40 1a b5 c9 cd 9e 8f 91 cc 5b 7d 14 15 000000B0: d0 89 70 e0 c6 d8 e4 e0 93 ff 02 4c 69 db ab 84 000000C0: d6 8f b9 f9 ed 07 aa 96 29 2a 50 c2 c4 b6 e5 cb 000000D0: 8e 16 33 7a 20 a4 3b 0e f2 53 9b b1 63 c0 46 4b 000000E0: d9 31 a8 98 f5 17 8a ff 0a c0 (73) Computes ICV using K3r as K_msg 00000000: 4a db a4 67 7e a1 3c 54 22 1f cf 62 (74) Composes IV Smyslov Expires 9 June 2023 [Page 26] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 00 00 00 00 00 00 00 00 (75) Sends message, peer receives message 10.111.10.171:54294<-10.111.15.45:500 [286] 00000000: e9 d3 f3 78 19 1c 38 40 8d df f4 01 fb fb 0b 14 00000010: 2e 20 23 20 00 00 00 01 00 00 01 1e 24 00 01 02 00000020: 00 00 00 00 00 00 00 00 9b 5d 58 8a 99 44 11 d6 00000030: 5b 93 7f 98 57 0d 0f 09 0c a3 d9 36 41 b5 9c 91 00000040: 94 17 3a cb 00 88 24 5e 25 b7 0d 75 2f fb 4d d0 00000050: ab 2c cc 84 42 e7 f8 1b 5a e6 88 13 9a 3e b1 03 00000060: 79 31 0c 69 f6 17 a2 40 f8 aa 74 2e 62 29 ee 57 00000070: 43 3f 10 bf 44 73 51 97 2c 93 a4 02 87 3d 37 45 00000080: 2c f1 3e 16 c3 d9 ec b3 b8 6f 66 1a f1 73 44 7c 00000090: db 74 11 e6 07 4a 75 23 83 df 00 52 ae 68 60 39 000000A0: 83 4c c3 b1 d5 7a e8 7f 61 59 9e 4f 92 3c 2f 04 000000B0: 3b c3 ac e7 23 3f 1c a7 a5 3f 4d 33 1f 46 25 9f 000000C0: 09 5e f4 75 e0 12 32 5b 29 64 a4 40 1a b5 c9 cd 000000D0: 9e 8f 91 cc 5b 7d 14 15 d0 89 70 e0 c6 d8 e4 e0 000000E0: 93 ff 02 4c 69 db ab 84 d6 8f b9 f9 ed 07 aa 96 000000F0: 29 2a 50 c2 c4 b6 e5 cb 8e 16 33 7a 20 a4 3b 0e 00000100: f2 53 9b b1 63 c0 46 4b d9 31 a8 98 f5 17 8a ff 00000110: 0a c0 4a db a4 67 7e a1 3c 54 22 1f cf 62 Initiator's actions: (76) Extracts IV from message 00000000: 00 00 00 00 00 00 00 00 (77) Computes K1r (i1 = 0) 00000000: 61 cd ad b1 01 10 71 7c dc 18 81 1d 1f aa e3 13 00000010: 4b 07 f8 f7 49 a7 3d 0a 57 2f e1 61 bc ab 85 c4 (78) Computes K2r (i2 = 0) 00000000: 5f e7 47 77 da f7 54 d7 a8 e5 eb ed f9 82 c8 a9 00000010: 74 0c 54 77 6f eb b8 70 a4 43 43 3e c2 9e ce a6 (79) Computes K3r (i3 = 0) 00000000: e8 af 72 c4 c3 55 a2 6a fb ad 37 fd b4 b9 7f d6 00000010: f6 c8 cc 32 3f 50 32 40 06 86 ce 85 1b 02 28 f3 (80) Composes MGM nonce Smyslov Expires 9 June 2023 [Page 27] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 00 00 00 00 65 20 72 e7 0a 1e ff 7d da ba 17 31 (81) Extracts ICV from message 00000000: 4a db a4 67 7e a1 3c 54 22 1f cf 62 (82) Extracts AAD from message 00000000: e9 d3 f3 78 19 1c 38 40 8d df f4 01 fb fb 0b 14 00000010: 2e 20 23 20 00 00 00 01 00 00 01 1e 24 00 01 02 (83) Extracts ciphertext from message 00000000: 9b 5d 58 8a 99 44 11 d6 5b 93 7f 98 57 0d 0f 09 00000010: 0c a3 d9 36 41 b5 9c 91 94 17 3a cb 00 88 24 5e 00000020: 25 b7 0d 75 2f fb 4d d0 ab 2c cc 84 42 e7 f8 1b 00000030: 5a e6 88 13 9a 3e b1 03 79 31 0c 69 f6 17 a2 40 00000040: f8 aa 74 2e 62 29 ee 57 43 3f 10 bf 44 73 51 97 00000050: 2c 93 a4 02 87 3d 37 45 2c f1 3e 16 c3 d9 ec b3 00000060: b8 6f 66 1a f1 73 44 7c db 74 11 e6 07 4a 75 23 00000070: 83 df 00 52 ae 68 60 39 83 4c c3 b1 d5 7a e8 7f 00000080: 61 59 9e 4f 92 3c 2f 04 3b c3 ac e7 23 3f 1c a7 00000090: a5 3f 4d 33 1f 46 25 9f 09 5e f4 75 e0 12 32 5b 000000A0: 29 64 a4 40 1a b5 c9 cd 9e 8f 91 cc 5b 7d 14 15 000000B0: d0 89 70 e0 c6 d8 e4 e0 93 ff 02 4c 69 db ab 84 000000C0: d6 8f b9 f9 ed 07 aa 96 29 2a 50 c2 c4 b6 e5 cb 000000D0: 8e 16 33 7a 20 a4 3b 0e f2 53 9b b1 63 c0 46 4b 000000E0: d9 31 a8 98 f5 17 8a ff 0a c0 (84) Decrypts ciphertext and verifies ICV using K3r as K_msg, resulted in plaintext 00000000: 27 00 00 15 02 00 00 00 49 4b 45 2d 52 65 73 70 00000010: 6f 6e 64 65 72 29 00 00 48 02 00 00 00 35 ce 8a 00000020: ab dd 3d b1 5f 38 7b 2e c9 a6 24 7a 1f a7 bb a0 00000030: 6f b6 5e d8 81 07 d3 43 c8 a5 db 37 51 0e 9d 9a 00000040: 85 66 18 7a 0f 5c e2 1b fb 27 56 65 ed 0e 41 fe 00000050: ce 5e 95 bf 8a ae 57 f6 d6 26 d2 d1 2d 29 00 00 00000060: 08 00 00 40 00 2f 00 00 0c 00 00 40 01 00 00 00 00000070: 40 21 00 00 10 02 00 00 00 00 01 00 04 0a 01 01 00000080: 02 2c 00 00 20 00 00 00 1c 01 03 04 02 50 3c 8d 00000090: af 03 00 00 08 01 00 00 20 00 00 00 08 05 00 00 000000A0: 00 2d 00 00 18 01 00 00 00 07 00 00 10 00 00 ff 000000B0: ff 0a 01 01 02 0a 01 01 02 29 00 00 18 01 00 00 000000C0: 00 07 00 00 10 00 00 ff ff 0a 00 00 00 0a 00 00 000000D0: ff 29 00 00 08 00 00 40 02 29 00 00 08 00 00 40 000000E0: 0a 00 00 00 08 00 00 40 0b 00 Smyslov Expires 9 June 2023 [Page 28] Internet-Draft GOST algorithms in IKEv2 December 2022 (85) Parses received message IKE SA Auth E9D3F378191C3840.8DDFF401FBFB0B14.00000001 IKEv2 R=>I[286] E[258]{ IDr[21](FQDN){"IKE-Responder"}, AUTH[72](Preshared-Key){35CE8A...D2D12D}, N[8](INITIAL_CONTACT), N[12](SET_WINDOW_SIZE){64}, CP[16](REPLY){IP4.Address[4]=10.1.1.2}, SA[32]{ P[28](#1:ESP:503C8DAF:2#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, ESN=Off}}, TSi[24](1#){10.1.1.2}, TSr[24](1#){10.0.0.0-10.0.0.255}, N[8](ADDITIONAL_TS_POSSIBLE), N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} (86) Computes prf(SK_pr, IDr) 00000000: 32 61 00 71 e8 1a d6 a1 12 8d ef 4e 2a e9 bb c2 00000010: 9f 3d ba 28 1b 2a a5 10 a2 ad c6 b1 73 07 c9 f1 00000020: 50 9e 1c d7 a5 85 8f a8 40 ef dd a7 ae 33 71 74 00000030: c8 8b a9 f4 3a 83 0f c1 c5 3c 9b 21 9f a9 58 25 (87) Uses PSK 00000000: e2 69 24 cf 15 32 93 47 3a 11 a4 97 a8 a4 5c b3 00000010: 4e 28 31 ef 0e 28 bb 77 69 69 c6 3c 68 bf e1 0d (88) Computes prf(PSK,"Key Pad for IKEv2") 00000000: 01 3c a5 24 59 4e bc 78 99 20 61 6c 3f 03 e5 2e 00000010: 7a 75 2a 0b 78 36 bd 0a 89 ce 1d e7 8b 23 32 ae 00000020: 08 9a a0 03 1d da f6 14 8c 38 c6 bd 7c 03 13 24 00000030: bd af c8 ad 88 18 8f 41 d0 12 b9 e1 5a 66 8f 10 (89) Computes content of AUTH payload and compares it with the received one 00000000: 35 ce 8a ab dd 3d b1 5f 38 7b 2e c9 a6 24 7a 1f 00000010: a7 bb a0 6f b6 5e d8 81 07 d3 43 c8 a5 db 37 51 00000020: 0e 9d 9a 85 66 18 7a 0f 5c e2 1b fb 27 56 65 ed 00000030: 0e 41 fe ce 5e 95 bf 8a ae 57 f6 d6 26 d2 d1 2d (90) Computes keys for ESP SAs Smyslov Expires 9 June 2023 [Page 29] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: ff 42 3b a3 78 29 2b 10 52 c8 bf 06 fa ba 6d 5f 00000010: e2 db 51 1b 74 1b 54 ad 35 85 e3 cf 2b 77 52 42 00000020: bc 8c d8 ba dd f4 46 9e 89 41 5c d6 00000000: 8c eb 84 af 18 01 18 36 b7 8d 65 be 03 ca 69 64 00000010: 89 6e a8 91 03 bc 9a dc bd 49 10 ab 20 83 9f 83 00000020: b1 7c 45 9d ab d8 ab 6f de 6a 62 d1 Sub-scenario 2: IKE SA rekeying using the CREATE_CHILD_SA exchange. Initiator Responder HDR, SK {SAi, Ni, KEi [,N+]} ---> <--- HDR, SK {SAr, Nr, KEr [,N+]} Initiator's actions: (1) Generates random SPIi for new IKE SA 00000000: 43 87 64 8d 6c 9e 28 ff (2) Generates random IKE nonce Ni 00000000: 6c 83 67 41 1b 45 94 1d 79 94 51 2d 3f 7d 1e ce 00000010: 06 76 a6 09 cc a9 3a 8f f8 17 81 ff 28 08 5a 4c (3) Generates ephemeral private key 00000000: cf 8f f0 df 04 24 43 b5 7e 15 2c bd 9f cd bd d9 00000010: 20 b5 35 7c e8 8b a6 d7 bd 7f 32 39 3d 5e 9a 3c 00000020: eb 88 4f 7f 6c 5d 03 05 fc bf 08 12 41 76 f4 a6 00000030: 2e 4c f7 ce 55 18 9d 6a 54 1f f7 57 46 23 cd 26 (4) Computes public key 00000000: 04 db 0b d3 9a ac 83 f3 e9 9d a9 11 c3 12 f6 df 00000010: f6 ae 99 38 55 20 1f 83 c8 28 ed 14 f9 68 88 77 00000020: ac 78 36 41 7a d7 93 a7 ee 4c 6a d7 f2 50 24 f5 00000030: a8 7b 03 28 22 9f a4 66 11 20 57 64 56 7c 36 3c 00000040: 72 c7 91 0a 1c fd 64 54 f1 17 97 6a 35 48 dc 8f 00000050: 85 97 20 12 2f 35 55 58 9b ca 7a 84 f3 01 cf ca 00000060: 78 e7 41 87 d3 3f 0f 2b 6d 78 59 ad f2 f2 c2 97 00000070: db 0b 75 6e 00 38 a2 72 8d 17 6b 44 f9 8b 95 66 (5) Creates message Smyslov Expires 9 June 2023 [Page 30] Internet-Draft GOST algorithms in IKEv2 December 2022 Create Child SA E9D3F378191C3840.8DDFF401FBFB0B14.00000002 IKEv2 R<-I [281] E[253]{ SA[44]{ P[40](#1:IKE:4387648D6C9E28FF:3#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_512}}, NONCE[36]{6C8367...085A4C}, KE[136](GOST3410_2012_512){04DB0B...8B9566}, N[12](SET_WINDOW_SIZE){4}} (6) Uses previously computed key K3i 00000000: 36 ff fa db 84 a9 f1 21 d5 84 16 db eb af 21 a2 00000010: 12 6d 5c 35 95 fe 89 cf 27 47 52 8a b7 36 92 d4 (7) Composes MGM nonce 00000000: 00 00 00 01 83 00 37 c3 08 01 7e c3 0a 71 62 01 (8) Composes AAD 00000000: e9 d3 f3 78 19 1c 38 40 8d df f4 01 fb fb 0b 14 00000010: 2e 20 24 08 00 00 00 02 00 00 01 19 21 00 00 fd (9) Composes plaintext 00000000: 28 00 00 2c 00 00 00 28 01 01 08 03 43 87 64 8d 00000010: 6c 9e 28 ff 03 00 00 08 01 00 00 20 03 00 00 08 00000020: 02 00 00 09 00 00 00 08 04 00 00 22 22 00 00 24 00000030: 6c 83 67 41 1b 45 94 1d 79 94 51 2d 3f 7d 1e ce 00000040: 06 76 a6 09 cc a9 3a 8f f8 17 81 ff 28 08 5a 4c 00000050: 29 00 00 88 00 22 00 00 04 db 0b d3 9a ac 83 f3 00000060: e9 9d a9 11 c3 12 f6 df f6 ae 99 38 55 20 1f 83 00000070: c8 28 ed 14 f9 68 88 77 ac 78 36 41 7a d7 93 a7 00000080: ee 4c 6a d7 f2 50 24 f5 a8 7b 03 28 22 9f a4 66 00000090: 11 20 57 64 56 7c 36 3c 72 c7 91 0a 1c fd 64 54 000000A0: f1 17 97 6a 35 48 dc 8f 85 97 20 12 2f 35 55 58 000000B0: 9b ca 7a 84 f3 01 cf ca 78 e7 41 87 d3 3f 0f 2b 000000C0: 6d 78 59 ad f2 f2 c2 97 db 0b 75 6e 00 38 a2 72 000000D0: 8d 17 6b 44 f9 8b 95 66 00 00 00 0c 00 00 40 01 000000E0: 00 00 00 04 00 (10) Encrypts plaintext using K3i as K_msg, resulted in ciphertext Smyslov Expires 9 June 2023 [Page 31] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 00 16 cf 92 8a 87 4c 02 79 31 04 22 c3 d9 5f fd 00000010: 5a 19 23 62 25 d1 99 c2 af 75 4d f1 3c ac c0 c1 00000020: c7 db d0 fd 93 ac 6d 25 b4 19 01 e6 df e8 51 c2 00000030: 88 a9 8a 26 92 98 ec ce c1 2f cf ca ce 9b 5a 6d 00000040: 4c 8b cf 97 63 5a a3 e6 46 49 0f 1f 05 54 00 49 00000050: 6b d8 14 f4 e2 ee b3 66 2a 13 9b dd 63 53 7a 82 00000060: 2a d8 bf 48 aa db 79 21 d3 d8 ac b1 ac 8f 9b 41 00000070: a7 49 81 95 d7 54 46 e2 00 9b 17 3a ab 9a 4c 8f 00000080: 19 9e ac 61 cc f6 02 47 a1 7e f4 48 5b e7 3c a7 00000090: 53 dc 03 9e ea 5f c4 99 60 6e db 6a 21 fe 7c 7b 000000A0: 11 ed bf 44 59 73 fa 65 01 98 e4 e6 10 63 87 27 000000B0: 8b f0 8c bb 94 52 dd 97 ee dc ce 88 c4 45 b4 16 000000C0: f2 8b d4 74 cb 46 38 57 f4 44 88 23 44 06 d9 91 000000D0: 00 ea 81 2c e7 f6 66 0f a8 45 0f 1d 8c 2d f1 02 000000E0: a2 06 78 c7 e0 (11) Computes ICV using K3i as K_msg 00000000: b1 2f da a5 96 fa 27 ee 67 de 9e 95 (12) Composes IV 00000000: 00 00 00 00 00 00 00 01 (13) Sends message, peer receives message 10.111.10.171:54294->10.111.15.45:500 [281] 00000000: e9 d3 f3 78 19 1c 38 40 8d df f4 01 fb fb 0b 14 00000010: 2e 20 24 08 00 00 00 02 00 00 01 19 21 00 00 fd 00000020: 00 00 00 00 00 00 00 01 00 16 cf 92 8a 87 4c 02 00000030: 79 31 04 22 c3 d9 5f fd 5a 19 23 62 25 d1 99 c2 00000040: af 75 4d f1 3c ac c0 c1 c7 db d0 fd 93 ac 6d 25 00000050: b4 19 01 e6 df e8 51 c2 88 a9 8a 26 92 98 ec ce 00000060: c1 2f cf ca ce 9b 5a 6d 4c 8b cf 97 63 5a a3 e6 00000070: 46 49 0f 1f 05 54 00 49 6b d8 14 f4 e2 ee b3 66 00000080: 2a 13 9b dd 63 53 7a 82 2a d8 bf 48 aa db 79 21 00000090: d3 d8 ac b1 ac 8f 9b 41 a7 49 81 95 d7 54 46 e2 000000A0: 00 9b 17 3a ab 9a 4c 8f 19 9e ac 61 cc f6 02 47 000000B0: a1 7e f4 48 5b e7 3c a7 53 dc 03 9e ea 5f c4 99 000000C0: 60 6e db 6a 21 fe 7c 7b 11 ed bf 44 59 73 fa 65 000000D0: 01 98 e4 e6 10 63 87 27 8b f0 8c bb 94 52 dd 97 000000E0: ee dc ce 88 c4 45 b4 16 f2 8b d4 74 cb 46 38 57 000000F0: f4 44 88 23 44 06 d9 91 00 ea 81 2c e7 f6 66 0f 00000100: a8 45 0f 1d 8c 2d f1 02 a2 06 78 c7 e0 b1 2f da 00000110: a5 96 fa 27 ee 67 de 9e 95 Responder's actions: Smyslov Expires 9 June 2023 [Page 32] Internet-Draft GOST algorithms in IKEv2 December 2022 (14) Extracts IV from message 00000000: 00 00 00 00 00 00 00 01 (15) Uses previously computed key K3i 00000000: 36 ff fa db 84 a9 f1 21 d5 84 16 db eb af 21 a2 00000010: 12 6d 5c 35 95 fe 89 cf 27 47 52 8a b7 36 92 d4 (16) Composes MGM nonce 00000000: 00 00 00 01 83 00 37 c3 08 01 7e c3 0a 71 62 01 (17) Extracts ICV from message 00000000: b1 2f da a5 96 fa 27 ee 67 de 9e 95 (18) Extracts AAD from message 00000000: e9 d3 f3 78 19 1c 38 40 8d df f4 01 fb fb 0b 14 00000010: 2e 20 24 08 00 00 00 02 00 00 01 19 21 00 00 fd (19) Extracts ciphertext from message 00000000: 00 16 cf 92 8a 87 4c 02 79 31 04 22 c3 d9 5f fd 00000010: 5a 19 23 62 25 d1 99 c2 af 75 4d f1 3c ac c0 c1 00000020: c7 db d0 fd 93 ac 6d 25 b4 19 01 e6 df e8 51 c2 00000030: 88 a9 8a 26 92 98 ec ce c1 2f cf ca ce 9b 5a 6d 00000040: 4c 8b cf 97 63 5a a3 e6 46 49 0f 1f 05 54 00 49 00000050: 6b d8 14 f4 e2 ee b3 66 2a 13 9b dd 63 53 7a 82 00000060: 2a d8 bf 48 aa db 79 21 d3 d8 ac b1 ac 8f 9b 41 00000070: a7 49 81 95 d7 54 46 e2 00 9b 17 3a ab 9a 4c 8f 00000080: 19 9e ac 61 cc f6 02 47 a1 7e f4 48 5b e7 3c a7 00000090: 53 dc 03 9e ea 5f c4 99 60 6e db 6a 21 fe 7c 7b 000000A0: 11 ed bf 44 59 73 fa 65 01 98 e4 e6 10 63 87 27 000000B0: 8b f0 8c bb 94 52 dd 97 ee dc ce 88 c4 45 b4 16 000000C0: f2 8b d4 74 cb 46 38 57 f4 44 88 23 44 06 d9 91 000000D0: 00 ea 81 2c e7 f6 66 0f a8 45 0f 1d 8c 2d f1 02 000000E0: a2 06 78 c7 e0 (20) Decrypts ciphertext and verifies ICV using K3i as K_msg, resulted in plaintext Smyslov Expires 9 June 2023 [Page 33] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 28 00 00 2c 00 00 00 28 01 01 08 03 43 87 64 8d 00000010: 6c 9e 28 ff 03 00 00 08 01 00 00 20 03 00 00 08 00000020: 02 00 00 09 00 00 00 08 04 00 00 22 22 00 00 24 00000030: 6c 83 67 41 1b 45 94 1d 79 94 51 2d 3f 7d 1e ce 00000040: 06 76 a6 09 cc a9 3a 8f f8 17 81 ff 28 08 5a 4c 00000050: 29 00 00 88 00 22 00 00 04 db 0b d3 9a ac 83 f3 00000060: e9 9d a9 11 c3 12 f6 df f6 ae 99 38 55 20 1f 83 00000070: c8 28 ed 14 f9 68 88 77 ac 78 36 41 7a d7 93 a7 00000080: ee 4c 6a d7 f2 50 24 f5 a8 7b 03 28 22 9f a4 66 00000090: 11 20 57 64 56 7c 36 3c 72 c7 91 0a 1c fd 64 54 000000A0: f1 17 97 6a 35 48 dc 8f 85 97 20 12 2f 35 55 58 000000B0: 9b ca 7a 84 f3 01 cf ca 78 e7 41 87 d3 3f 0f 2b 000000C0: 6d 78 59 ad f2 f2 c2 97 db 0b 75 6e 00 38 a2 72 000000D0: 8d 17 6b 44 f9 8b 95 66 00 00 00 0c 00 00 40 01 000000E0: 00 00 00 04 00 (21) Parses received message Create Child SA E9D3F378191C3840.8DDFF401FBFB0B14.00000002 IKEv2 I->R[281] E[253]{ SA[44]{ P[40](#1:IKE:4387648D6C9E28FF:3#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_512}}, NONCE[36]{6C8367...085A4C}, KE[136](GOST3410_2012_512){04DB0B...8B9566}, N[12](SET_WINDOW_SIZE){4}} (22) Generates random SPIr for new IKE SA 00000000: 82 d9 fa f8 74 49 b9 36 (23) Generates random IKE nonce Nr 00000000: 5a 2d d2 68 c6 85 5d 32 d4 7b 0b 8e ae 7d c9 81 00000010: be 3e 69 c1 bb f5 ae 89 55 59 c7 48 bc 96 43 7b (24) Generates ephemeral private key 00000000: b9 ea c6 c1 84 db 39 54 e3 e7 74 be 02 e0 c9 0b 00000010: 5c b9 72 03 d4 fc a2 3f b6 cf 71 8d 4f f4 b4 c5 00000020: 21 1c 93 f9 86 cc 6b cb db ff 78 51 5b b6 48 e8 00000030: 44 ce c0 83 c9 d0 b8 90 08 94 db 29 9f bb c2 1a (25) Computes public key Smyslov Expires 9 June 2023 [Page 34] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: b9 f9 27 a8 96 70 7a 03 58 c2 39 58 63 2d 50 20 00000010: bf 69 c0 1d a6 de d4 4d 65 aa 26 c6 8f 9f e9 e9 00000020: 4b bb da 1d 2f d3 60 2d 18 33 04 9b b2 25 a6 07 00000030: ac 58 1b fc 3c 5b 1e f3 4b c0 f9 cb 90 14 c6 80 00000040: 6e c3 73 c1 4a f7 5c 27 dd 2a e1 ba 94 9c f7 06 00000050: 68 92 19 8e 85 67 f9 d2 d1 ea 3c 16 16 b9 3f 0c 00000060: 8b 2d 2e d6 20 14 7e 27 18 d3 23 9e 2a 99 41 40 00000070: 6a 41 c5 3f 79 9c a7 22 79 15 98 1d 98 b5 ac 4a (26) Computes shared key 00000000: dd e7 44 39 1c d9 66 cf d2 24 a4 bb 0a 57 b3 3e 00000010: 1a 8f 5d 07 11 4d c3 47 87 1a 13 ec 84 26 03 f8 00000020: ea 93 5a f5 23 a3 45 71 ff 5f f2 3d 59 43 3a 5e 00000030: eb 5e 79 fa 0e 62 9e bc af ca e4 ee 7a 81 3a 84 (27) Computes SKEYSEED for new SA 00000000: ec 5f 4f 15 ce d7 7d 2f 12 fb a1 df 5f 44 aa 88 00000010: 6a ef 45 e4 04 97 86 95 15 1b 3c ac 31 cc 57 a3 00000020: f0 f4 92 89 33 00 76 2b e9 fd 8b c2 ed 8b e7 36 00000030: cb 17 59 55 9e cc 22 14 72 a5 79 27 27 1d 06 62 (28) Computes SK_d for new SA 00000000: 08 58 14 7d eb c9 41 7f 7f a2 86 66 bf d4 76 37 00000010: 04 27 4e bc 5d 63 f7 07 79 62 69 7a 69 3c da 7a 00000020: d5 4d 6f 08 1e 14 51 66 2f 94 0d bd 29 45 9c b0 00000030: 51 26 09 4b 47 52 ba 19 98 a5 c2 65 af 84 a1 34 (29) Computes SK_ei for new SA 00000000: 18 0a 4f 98 7d a4 21 6c 68 84 94 1f d9 28 49 b9 00000010: 05 30 f8 aa 43 02 7e 0d aa d3 27 e9 8c 9a 39 9a 00000020: 03 a0 05 b7 b2 2d f9 90 bb 6c ff ca (30) Computes SK_er for new SA 00000000: 47 dc aa 71 4a 8b 66 13 d8 09 79 c7 8c 72 0a 78 00000010: 06 48 6d 4f 1f 53 3a 91 1d b7 2c 86 f5 f1 4e 00 00000020: 84 57 87 2b 38 70 63 27 8c dd 88 78 (31) Creates message Smyslov Expires 9 June 2023 [Page 35] Internet-Draft GOST algorithms in IKEv2 December 2022 Create Child SA E9D3F378191C3840.8DDFF401FBFB0B14.00000002 IKEv2 I<=R[281] E[253]{ SA[44]{ P[40](#1:IKE:82D9FAF87449B936:3#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_512}}, NONCE[36]{5A2DD2...96437B}, KE[136](GOST3410_2012_512){B9F927...B5AC4A}, N[12](SET_WINDOW_SIZE){64}} (32) Uses previously computed key K3r 00000000: e8 af 72 c4 c3 55 a2 6a fb ad 37 fd b4 b9 7f d6 00000010: f6 c8 cc 32 3f 50 32 40 06 86 ce 85 1b 02 28 f3 (33) Composes MGM nonce 00000000: 00 00 00 01 65 20 72 e7 0a 1e ff 7d da ba 17 31 (34) Composes AAD 00000000: e9 d3 f3 78 19 1c 38 40 8d df f4 01 fb fb 0b 14 00000010: 2e 20 24 20 00 00 00 02 00 00 01 19 21 00 00 fd (35) Composes plaintext 00000000: 28 00 00 2c 00 00 00 28 01 01 08 03 82 d9 fa f8 00000010: 74 49 b9 36 03 00 00 08 01 00 00 20 03 00 00 08 00000020: 02 00 00 09 00 00 00 08 04 00 00 22 22 00 00 24 00000030: 5a 2d d2 68 c6 85 5d 32 d4 7b 0b 8e ae 7d c9 81 00000040: be 3e 69 c1 bb f5 ae 89 55 59 c7 48 bc 96 43 7b 00000050: 29 00 00 88 00 22 00 00 b9 f9 27 a8 96 70 7a 03 00000060: 58 c2 39 58 63 2d 50 20 bf 69 c0 1d a6 de d4 4d 00000070: 65 aa 26 c6 8f 9f e9 e9 4b bb da 1d 2f d3 60 2d 00000080: 18 33 04 9b b2 25 a6 07 ac 58 1b fc 3c 5b 1e f3 00000090: 4b c0 f9 cb 90 14 c6 80 6e c3 73 c1 4a f7 5c 27 000000A0: dd 2a e1 ba 94 9c f7 06 68 92 19 8e 85 67 f9 d2 000000B0: d1 ea 3c 16 16 b9 3f 0c 8b 2d 2e d6 20 14 7e 27 000000C0: 18 d3 23 9e 2a 99 41 40 6a 41 c5 3f 79 9c a7 22 000000D0: 79 15 98 1d 98 b5 ac 4a 00 00 00 0c 00 00 40 01 000000E0: 00 00 00 40 00 (36) Encrypts plaintext using K3r as K_msg, resulted in ciphertext Smyslov Expires 9 June 2023 [Page 36] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: fd ee 4c 8f 78 ff b6 0c fc 65 bb ef db 53 56 a2 00000010: d3 2d 4f 59 ff 28 38 eb 76 0b 40 5e 8d 52 e8 c1 00000020: b9 75 22 b4 bb 71 8f 16 3a 97 0e 4d 95 ef bc 84 00000030: 46 c6 77 1e 4b 14 73 46 89 ed d4 b4 54 a2 64 19 00000040: 67 b2 98 7e 8b d4 45 31 17 1e e4 ae f4 24 44 42 00000050: dd 55 a0 49 fe 08 59 d0 a1 16 69 60 8a 8e 54 d2 00000060: 02 6d ae 17 5f 32 bf 14 78 f0 86 47 26 bf fb 6b 00000070: 7c 17 f7 f5 62 b6 d6 a0 e5 f3 c2 af b5 28 ee d0 00000080: 9b 22 8c e6 d0 58 4d 48 18 6d dd 3e 4e 33 66 ac 00000090: a2 29 1f 3b 62 4a e6 4a 8c 98 18 8b 21 73 a5 88 000000A0: 49 09 3b 27 88 20 40 6b a5 fc 08 37 c7 ac c9 0f 000000B0: 5d 69 87 7c 37 c8 c7 fd d8 72 6d ad ac 22 27 ca 000000C0: 93 d6 bd 6a 55 2a 1a 8b 2e 84 b4 0a 35 d3 ac d5 000000D0: 99 c9 ac d5 6f 03 94 bf ca f5 53 e5 a5 74 57 de 000000E0: 6a 5a 26 b8 e4 (37) Computes ICV using K3r as K_msg 00000000: 04 2f 99 3f 02 19 56 c4 0d 0b 7a 45 (38) Composes IV 00000000: 00 00 00 00 00 00 00 01 (39) Sends message, peer receives message 10.111.10.171:54294<-10.111.15.45:500 [281] 00000000: e9 d3 f3 78 19 1c 38 40 8d df f4 01 fb fb 0b 14 00000010: 2e 20 24 20 00 00 00 02 00 00 01 19 21 00 00 fd 00000020: 00 00 00 00 00 00 00 01 fd ee 4c 8f 78 ff b6 0c 00000030: fc 65 bb ef db 53 56 a2 d3 2d 4f 59 ff 28 38 eb 00000040: 76 0b 40 5e 8d 52 e8 c1 b9 75 22 b4 bb 71 8f 16 00000050: 3a 97 0e 4d 95 ef bc 84 46 c6 77 1e 4b 14 73 46 00000060: 89 ed d4 b4 54 a2 64 19 67 b2 98 7e 8b d4 45 31 00000070: 17 1e e4 ae f4 24 44 42 dd 55 a0 49 fe 08 59 d0 00000080: a1 16 69 60 8a 8e 54 d2 02 6d ae 17 5f 32 bf 14 00000090: 78 f0 86 47 26 bf fb 6b 7c 17 f7 f5 62 b6 d6 a0 000000A0: e5 f3 c2 af b5 28 ee d0 9b 22 8c e6 d0 58 4d 48 000000B0: 18 6d dd 3e 4e 33 66 ac a2 29 1f 3b 62 4a e6 4a 000000C0: 8c 98 18 8b 21 73 a5 88 49 09 3b 27 88 20 40 6b 000000D0: a5 fc 08 37 c7 ac c9 0f 5d 69 87 7c 37 c8 c7 fd 000000E0: d8 72 6d ad ac 22 27 ca 93 d6 bd 6a 55 2a 1a 8b 000000F0: 2e 84 b4 0a 35 d3 ac d5 99 c9 ac d5 6f 03 94 bf 00000100: ca f5 53 e5 a5 74 57 de 6a 5a 26 b8 e4 04 2f 99 00000110: 3f 02 19 56 c4 0d 0b 7a 45 Initiator's actions: Smyslov Expires 9 June 2023 [Page 37] Internet-Draft GOST algorithms in IKEv2 December 2022 (40) Extracts IV from message 00000000: 00 00 00 00 00 00 00 01 (41) Uses previously computed key K3r 00000000: e8 af 72 c4 c3 55 a2 6a fb ad 37 fd b4 b9 7f d6 00000010: f6 c8 cc 32 3f 50 32 40 06 86 ce 85 1b 02 28 f3 (42) Composes MGM nonce 00000000: 00 00 00 01 65 20 72 e7 0a 1e ff 7d da ba 17 31 (43) Extracts ICV from message 00000000: 04 2f 99 3f 02 19 56 c4 0d 0b 7a 45 (44) Extracts AAD from message 00000000: e9 d3 f3 78 19 1c 38 40 8d df f4 01 fb fb 0b 14 00000010: 2e 20 24 20 00 00 00 02 00 00 01 19 21 00 00 fd (45) Extracts ciphertext from message 00000000: fd ee 4c 8f 78 ff b6 0c fc 65 bb ef db 53 56 a2 00000010: d3 2d 4f 59 ff 28 38 eb 76 0b 40 5e 8d 52 e8 c1 00000020: b9 75 22 b4 bb 71 8f 16 3a 97 0e 4d 95 ef bc 84 00000030: 46 c6 77 1e 4b 14 73 46 89 ed d4 b4 54 a2 64 19 00000040: 67 b2 98 7e 8b d4 45 31 17 1e e4 ae f4 24 44 42 00000050: dd 55 a0 49 fe 08 59 d0 a1 16 69 60 8a 8e 54 d2 00000060: 02 6d ae 17 5f 32 bf 14 78 f0 86 47 26 bf fb 6b 00000070: 7c 17 f7 f5 62 b6 d6 a0 e5 f3 c2 af b5 28 ee d0 00000080: 9b 22 8c e6 d0 58 4d 48 18 6d dd 3e 4e 33 66 ac 00000090: a2 29 1f 3b 62 4a e6 4a 8c 98 18 8b 21 73 a5 88 000000A0: 49 09 3b 27 88 20 40 6b a5 fc 08 37 c7 ac c9 0f 000000B0: 5d 69 87 7c 37 c8 c7 fd d8 72 6d ad ac 22 27 ca 000000C0: 93 d6 bd 6a 55 2a 1a 8b 2e 84 b4 0a 35 d3 ac d5 000000D0: 99 c9 ac d5 6f 03 94 bf ca f5 53 e5 a5 74 57 de 000000E0: 6a 5a 26 b8 e4 (46) Decrypts ciphertext and verifies ICV using K3r as K_msg, resulted in plaintext Smyslov Expires 9 June 2023 [Page 38] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 28 00 00 2c 00 00 00 28 01 01 08 03 82 d9 fa f8 00000010: 74 49 b9 36 03 00 00 08 01 00 00 20 03 00 00 08 00000020: 02 00 00 09 00 00 00 08 04 00 00 22 22 00 00 24 00000030: 5a 2d d2 68 c6 85 5d 32 d4 7b 0b 8e ae 7d c9 81 00000040: be 3e 69 c1 bb f5 ae 89 55 59 c7 48 bc 96 43 7b 00000050: 29 00 00 88 00 22 00 00 b9 f9 27 a8 96 70 7a 03 00000060: 58 c2 39 58 63 2d 50 20 bf 69 c0 1d a6 de d4 4d 00000070: 65 aa 26 c6 8f 9f e9 e9 4b bb da 1d 2f d3 60 2d 00000080: 18 33 04 9b b2 25 a6 07 ac 58 1b fc 3c 5b 1e f3 00000090: 4b c0 f9 cb 90 14 c6 80 6e c3 73 c1 4a f7 5c 27 000000A0: dd 2a e1 ba 94 9c f7 06 68 92 19 8e 85 67 f9 d2 000000B0: d1 ea 3c 16 16 b9 3f 0c 8b 2d 2e d6 20 14 7e 27 000000C0: 18 d3 23 9e 2a 99 41 40 6a 41 c5 3f 79 9c a7 22 000000D0: 79 15 98 1d 98 b5 ac 4a 00 00 00 0c 00 00 40 01 000000E0: 00 00 00 40 00 (47) Parses received message Create Child SA E9D3F378191C3840.8DDFF401FBFB0B14.00000002 IKEv2 R=>I[281] E[253]{ SA[44]{ P[40](#1:IKE:82D9FAF87449B936:3#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_512}}, NONCE[36]{5A2DD2...96437B}, KE[136](GOST3410_2012_512){B9F927...B5AC4A}, N[12](SET_WINDOW_SIZE){64}} (48) Computes shared key 00000000: dd e7 44 39 1c d9 66 cf d2 24 a4 bb 0a 57 b3 3e 00000010: 1a 8f 5d 07 11 4d c3 47 87 1a 13 ec 84 26 03 f8 00000020: ea 93 5a f5 23 a3 45 71 ff 5f f2 3d 59 43 3a 5e 00000030: eb 5e 79 fa 0e 62 9e bc af ca e4 ee 7a 81 3a 84 (49) Computes SKEYSEED for new SA 00000000: ec 5f 4f 15 ce d7 7d 2f 12 fb a1 df 5f 44 aa 88 00000010: 6a ef 45 e4 04 97 86 95 15 1b 3c ac 31 cc 57 a3 00000020: f0 f4 92 89 33 00 76 2b e9 fd 8b c2 ed 8b e7 36 00000030: cb 17 59 55 9e cc 22 14 72 a5 79 27 27 1d 06 62 (50) Computes SK_d for new SA Smyslov Expires 9 June 2023 [Page 39] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 08 58 14 7d eb c9 41 7f 7f a2 86 66 bf d4 76 37 00000010: 04 27 4e bc 5d 63 f7 07 79 62 69 7a 69 3c da 7a 00000020: d5 4d 6f 08 1e 14 51 66 2f 94 0d bd 29 45 9c b0 00000030: 51 26 09 4b 47 52 ba 19 98 a5 c2 65 af 84 a1 34 (51) Computes SK_ei for new SA 00000000: 18 0a 4f 98 7d a4 21 6c 68 84 94 1f d9 28 49 b9 00000010: 05 30 f8 aa 43 02 7e 0d aa d3 27 e9 8c 9a 39 9a 00000020: 03 a0 05 b7 b2 2d f9 90 bb 6c ff ca (52) Computes SK_er for new SA 00000000: 47 dc aa 71 4a 8b 66 13 d8 09 79 c7 8c 72 0a 78 00000010: 06 48 6d 4f 1f 53 3a 91 1d b7 2c 86 f5 f1 4e 00 00000020: 84 57 87 2b 38 70 63 27 8c dd 88 78 Sub-scenario 3: ESP SAs rekeying with PFS using the CREATE_CHILD_SA exchange. Initiator Responder HDR, SK {N(REKEY_SA), SAi, Ni, KEi, TSi, TSr [,N+]} ---> <--- HDR, SK {SAr, Nr, KEr, TSi, TSr [,N+]} Initiator's actions: (1) Generates random IKE nonce Ni 00000000: 59 52 b2 58 00 b7 d3 f9 c3 31 23 16 6f c2 d1 d7 00000010: 07 8b 99 fb 24 cf 24 30 a3 ce a6 fe d3 0f 20 9b (2) Generates ephemeral private key 00000000: 2f b9 df 43 dc 50 f5 17 59 c0 c7 21 ac ca 03 7a 00000010: 55 87 f9 bb a6 5a 9e d4 46 98 15 c9 3a 6b 40 91 00000020: e6 99 f4 f2 e5 88 14 e7 d8 9f 98 b1 59 21 05 52 00000030: f0 b0 ce dc 8e c6 db 1f 9d a9 4a 6d 95 f2 cb 3d (3) Computes public key Smyslov Expires 9 June 2023 [Page 40] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 1c 55 08 b9 01 f5 76 6a 01 27 97 2d 38 b1 4a 5c 00000010: b7 43 f1 64 24 ef 76 75 50 ce 4f 6f 59 ca 96 ae 00000020: 54 85 9c 94 8d 04 91 62 3a 0c b6 6e 77 59 81 40 00000030: 69 bf bb 80 f7 7c 29 ee 9f 9e 0c 83 b6 08 fc 43 00000040: b8 c6 66 36 e5 eb a0 43 c2 56 fa 52 f9 99 b6 95 00000050: 34 4c cd 49 1f c7 83 9e d7 d9 ca e3 a5 d0 3c aa 00000060: e8 ee ed 2c dd 5c 81 49 ab 3c d4 fa 15 4e 29 5f 00000070: 7c cd b2 f1 c1 d2 6f 8f a7 74 4d 6a d8 8a c3 60 (4) Selects SPI for new incoming ESP SA 00000000: a4 fe 65 a1 (5) Creates message Create Child SA 4387648D6C9E28FF.82D9FAF87449B936.00000000 IKEv2 R<-I[341] E[313]{ N[12](ESP:0ADE5FCD:REKEY_SA), SA[40]{ P[36](#1:ESP:A4FE65A1:3#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, KE=GOST3410_2012_512, ESN=Off}}, NONCE[36]{5952B2...0F209B}, KE[136](GOST3410_2012_512){1C5508...8AC360}, TSi[24](1#){10.1.1.2}, TSr[24](1#){10.0.0.0-10.0.0.255}, N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} (6) Computes K1i (i1 = 0) 00000000: 17 ec f1 84 33 9a c3 e3 93 e1 21 d7 65 3b 6c 83 00000010: d4 ae 9c 29 5b 12 cc b3 c5 0c 48 19 49 eb c0 ba (7) Computes K2i (i2 = 0) 00000000: 2d 33 c0 55 87 f2 ee ce ac 1a f2 28 64 c6 f5 ad 00000010: de 2d be 7a a8 92 d0 a6 20 bc ef 25 29 7b 56 9f (8) Computes K3i (i3 = 0) 00000000: c9 41 22 b5 39 b7 d2 3f c4 4d a6 ae 88 2e ff b4 00000010: f4 c0 90 9c bd bc 63 56 14 62 e8 8f 90 1a e7 eb (9) Composes MGM nonce Smyslov Expires 9 June 2023 [Page 41] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 00 00 00 00 03 a0 05 b7 b2 2d f9 90 bb 6c ff ca (10) Composes AAD 00000000: 43 87 64 8d 6c 9e 28 ff 82 d9 fa f8 74 49 b9 36 00000010: 2e 20 24 08 00 00 00 00 00 00 01 55 29 00 01 39 (11) Composes plaintext 00000000: 21 00 00 0c 03 04 40 09 0a de 5f cd 28 00 00 28 00000010: 00 00 00 24 01 03 04 03 a4 fe 65 a1 03 00 00 08 00000020: 01 00 00 20 03 00 00 08 04 00 00 22 00 00 00 08 00000030: 05 00 00 00 22 00 00 24 59 52 b2 58 00 b7 d3 f9 00000040: c3 31 23 16 6f c2 d1 d7 07 8b 99 fb 24 cf 24 30 00000050: a3 ce a6 fe d3 0f 20 9b 2c 00 00 88 00 22 00 00 00000060: 1c 55 08 b9 01 f5 76 6a 01 27 97 2d 38 b1 4a 5c 00000070: b7 43 f1 64 24 ef 76 75 50 ce 4f 6f 59 ca 96 ae 00000080: 54 85 9c 94 8d 04 91 62 3a 0c b6 6e 77 59 81 40 00000090: 69 bf bb 80 f7 7c 29 ee 9f 9e 0c 83 b6 08 fc 43 000000A0: b8 c6 66 36 e5 eb a0 43 c2 56 fa 52 f9 99 b6 95 000000B0: 34 4c cd 49 1f c7 83 9e d7 d9 ca e3 a5 d0 3c aa 000000C0: e8 ee ed 2c dd 5c 81 49 ab 3c d4 fa 15 4e 29 5f 000000D0: 7c cd b2 f1 c1 d2 6f 8f a7 74 4d 6a d8 8a c3 60 000000E0: 2d 00 00 18 01 00 00 00 07 00 00 10 00 00 ff ff 000000F0: 0a 01 01 02 0a 01 01 02 29 00 00 18 01 00 00 00 00000100: 07 00 00 10 00 00 ff ff 0a 00 00 00 0a 00 00 ff 00000110: 29 00 00 08 00 00 40 0a 00 00 00 08 00 00 40 0b 00000120: 00 (12) Encrypts plaintext using K3i as K_msg, resulted in ciphertext Smyslov Expires 9 June 2023 [Page 42] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 00 9b 13 cb cb f1 18 53 fc 81 2e 75 c3 03 e0 ca 00000010: 55 c1 fb 55 c0 29 40 48 fc 20 f4 a8 51 5b 97 6b 00000020: c6 07 4c 7d 45 54 51 0f 18 7f 43 a4 df 4b e8 e3 00000030: b4 eb 68 24 4b f0 1c df 8f 1e a2 21 31 02 29 68 00000040: 38 4d 68 fd 42 66 34 3e 82 46 f0 17 02 bf 65 19 00000050: b0 f7 09 62 0d 12 6a 7e ad 76 57 0d 19 55 cf 01 00000060: 89 9c 7e f5 5a fa 20 4f 8c 6d a4 83 b9 94 ad 4e 00000070: 2a 46 08 5a 58 a1 4b 8e 53 2b a4 e6 3b fc 33 de 00000080: cf cb ee 50 6d a1 9f e4 94 06 19 39 39 6b 7e 4b 00000090: 83 f7 07 c0 bb 15 21 8d 8f 2d 5f 6c f6 97 68 21 000000A0: 3c ce c6 67 82 00 8f f3 d7 d6 c3 f2 87 47 b8 b9 000000B0: a3 0f f8 e2 0a 62 e8 f5 98 df bc f0 02 6a 3f 47 000000C0: c4 f0 24 a4 80 95 bf cf 32 5a a5 22 3c a5 a8 f1 000000D0: 57 d6 3b b8 06 1c b6 d7 c7 b3 58 e7 ee 69 eb 31 000000E0: d6 09 db 8b 8a 1d 2b a1 f7 46 e5 b9 99 13 73 30 000000F0: 1f ed 0c 82 4b cc ce 5e 25 79 1b ff 8b ca f0 b2 00000100: 1e 7e 70 03 66 c7 7b 6c 10 92 f2 34 b6 e9 ce bb 00000110: 65 ce d4 b5 99 f3 70 78 5f 06 f4 fe 0a 3c 00 28 00000120: 68 (13) Computes ICV using K3i as K_msg 00000000: fc 85 a4 7e 0b 41 77 54 ef 1a 03 cb (14) Composes IV 00000000: 00 00 00 00 00 00 00 00 (15) Sends message, peer receives message Smyslov Expires 9 June 2023 [Page 43] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54294->10.111.15.45:500 [341] 00000000: 43 87 64 8d 6c 9e 28 ff 82 d9 fa f8 74 49 b9 36 00000010: 2e 20 24 08 00 00 00 00 00 00 01 55 29 00 01 39 00000020: 00 00 00 00 00 00 00 00 00 9b 13 cb cb f1 18 53 00000030: fc 81 2e 75 c3 03 e0 ca 55 c1 fb 55 c0 29 40 48 00000040: fc 20 f4 a8 51 5b 97 6b c6 07 4c 7d 45 54 51 0f 00000050: 18 7f 43 a4 df 4b e8 e3 b4 eb 68 24 4b f0 1c df 00000060: 8f 1e a2 21 31 02 29 68 38 4d 68 fd 42 66 34 3e 00000070: 82 46 f0 17 02 bf 65 19 b0 f7 09 62 0d 12 6a 7e 00000080: ad 76 57 0d 19 55 cf 01 89 9c 7e f5 5a fa 20 4f 00000090: 8c 6d a4 83 b9 94 ad 4e 2a 46 08 5a 58 a1 4b 8e 000000A0: 53 2b a4 e6 3b fc 33 de cf cb ee 50 6d a1 9f e4 000000B0: 94 06 19 39 39 6b 7e 4b 83 f7 07 c0 bb 15 21 8d 000000C0: 8f 2d 5f 6c f6 97 68 21 3c ce c6 67 82 00 8f f3 000000D0: d7 d6 c3 f2 87 47 b8 b9 a3 0f f8 e2 0a 62 e8 f5 000000E0: 98 df bc f0 02 6a 3f 47 c4 f0 24 a4 80 95 bf cf 000000F0: 32 5a a5 22 3c a5 a8 f1 57 d6 3b b8 06 1c b6 d7 00000100: c7 b3 58 e7 ee 69 eb 31 d6 09 db 8b 8a 1d 2b a1 00000110: f7 46 e5 b9 99 13 73 30 1f ed 0c 82 4b cc ce 5e 00000120: 25 79 1b ff 8b ca f0 b2 1e 7e 70 03 66 c7 7b 6c 00000130: 10 92 f2 34 b6 e9 ce bb 65 ce d4 b5 99 f3 70 78 00000140: 5f 06 f4 fe 0a 3c 00 28 68 fc 85 a4 7e 0b 41 77 00000150: 54 ef 1a 03 cb Responder's actions: (16) Extracts IV from message 00000000: 00 00 00 00 00 00 00 00 (17) Computes K1i (i1 = 0) 00000000: 17 ec f1 84 33 9a c3 e3 93 e1 21 d7 65 3b 6c 83 00000010: d4 ae 9c 29 5b 12 cc b3 c5 0c 48 19 49 eb c0 ba (18) Computes K2i (i2 = 0) 00000000: 2d 33 c0 55 87 f2 ee ce ac 1a f2 28 64 c6 f5 ad 00000010: de 2d be 7a a8 92 d0 a6 20 bc ef 25 29 7b 56 9f (19) Computes K3i (i3 = 0) 00000000: c9 41 22 b5 39 b7 d2 3f c4 4d a6 ae 88 2e ff b4 00000010: f4 c0 90 9c bd bc 63 56 14 62 e8 8f 90 1a e7 eb (20) Composes MGM nonce Smyslov Expires 9 June 2023 [Page 44] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 00 00 00 00 03 a0 05 b7 b2 2d f9 90 bb 6c ff ca (21) Extracts ICV from message 00000000: fc 85 a4 7e 0b 41 77 54 ef 1a 03 cb (22) Extracts AAD from message 00000000: 43 87 64 8d 6c 9e 28 ff 82 d9 fa f8 74 49 b9 36 00000010: 2e 20 24 08 00 00 00 00 00 00 01 55 29 00 01 39 (23) Extracts ciphertext from message 00000000: 00 9b 13 cb cb f1 18 53 fc 81 2e 75 c3 03 e0 ca 00000010: 55 c1 fb 55 c0 29 40 48 fc 20 f4 a8 51 5b 97 6b 00000020: c6 07 4c 7d 45 54 51 0f 18 7f 43 a4 df 4b e8 e3 00000030: b4 eb 68 24 4b f0 1c df 8f 1e a2 21 31 02 29 68 00000040: 38 4d 68 fd 42 66 34 3e 82 46 f0 17 02 bf 65 19 00000050: b0 f7 09 62 0d 12 6a 7e ad 76 57 0d 19 55 cf 01 00000060: 89 9c 7e f5 5a fa 20 4f 8c 6d a4 83 b9 94 ad 4e 00000070: 2a 46 08 5a 58 a1 4b 8e 53 2b a4 e6 3b fc 33 de 00000080: cf cb ee 50 6d a1 9f e4 94 06 19 39 39 6b 7e 4b 00000090: 83 f7 07 c0 bb 15 21 8d 8f 2d 5f 6c f6 97 68 21 000000A0: 3c ce c6 67 82 00 8f f3 d7 d6 c3 f2 87 47 b8 b9 000000B0: a3 0f f8 e2 0a 62 e8 f5 98 df bc f0 02 6a 3f 47 000000C0: c4 f0 24 a4 80 95 bf cf 32 5a a5 22 3c a5 a8 f1 000000D0: 57 d6 3b b8 06 1c b6 d7 c7 b3 58 e7 ee 69 eb 31 000000E0: d6 09 db 8b 8a 1d 2b a1 f7 46 e5 b9 99 13 73 30 000000F0: 1f ed 0c 82 4b cc ce 5e 25 79 1b ff 8b ca f0 b2 00000100: 1e 7e 70 03 66 c7 7b 6c 10 92 f2 34 b6 e9 ce bb 00000110: 65 ce d4 b5 99 f3 70 78 5f 06 f4 fe 0a 3c 00 28 00000120: 68 (24) Decrypts ciphertext and verifies ICV using K3i as K_msg, resulted in plaintext Smyslov Expires 9 June 2023 [Page 45] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 21 00 00 0c 03 04 40 09 0a de 5f cd 28 00 00 28 00000010: 00 00 00 24 01 03 04 03 a4 fe 65 a1 03 00 00 08 00000020: 01 00 00 20 03 00 00 08 04 00 00 22 00 00 00 08 00000030: 05 00 00 00 22 00 00 24 59 52 b2 58 00 b7 d3 f9 00000040: c3 31 23 16 6f c2 d1 d7 07 8b 99 fb 24 cf 24 30 00000050: a3 ce a6 fe d3 0f 20 9b 2c 00 00 88 00 22 00 00 00000060: 1c 55 08 b9 01 f5 76 6a 01 27 97 2d 38 b1 4a 5c 00000070: b7 43 f1 64 24 ef 76 75 50 ce 4f 6f 59 ca 96 ae 00000080: 54 85 9c 94 8d 04 91 62 3a 0c b6 6e 77 59 81 40 00000090: 69 bf bb 80 f7 7c 29 ee 9f 9e 0c 83 b6 08 fc 43 000000A0: b8 c6 66 36 e5 eb a0 43 c2 56 fa 52 f9 99 b6 95 000000B0: 34 4c cd 49 1f c7 83 9e d7 d9 ca e3 a5 d0 3c aa 000000C0: e8 ee ed 2c dd 5c 81 49 ab 3c d4 fa 15 4e 29 5f 000000D0: 7c cd b2 f1 c1 d2 6f 8f a7 74 4d 6a d8 8a c3 60 000000E0: 2d 00 00 18 01 00 00 00 07 00 00 10 00 00 ff ff 000000F0: 0a 01 01 02 0a 01 01 02 29 00 00 18 01 00 00 00 00000100: 07 00 00 10 00 00 ff ff 0a 00 00 00 0a 00 00 ff 00000110: 29 00 00 08 00 00 40 0a 00 00 00 08 00 00 40 0b 00000120: 00 (25) Parses received message Create Child SA 4387648D6C9E28FF.82D9FAF87449B936.00000000 IKEv2 I->R[341] E[313]{ N[12](ESP:0ADE5FCD:REKEY_SA), SA[40]{ P[36](#1:ESP:A4FE65A1:3#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, KE=GOST3410_2012_512, ESN=Off}}, NONCE[36]{5952B2...0F209B}, KE[136](GOST3410_2012_512){1C5508...8AC360}, TSi[24](1#){10.1.1.2}, TSr[24](1#){10.0.0.0-10.0.0.255}, N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} (26) Generates random IKE nonce Nr 00000000: f1 c1 3f 5e c4 c9 70 81 cb 1f 57 fe af 3d 80 37 00000010: 92 a9 ff 96 db 8f 3f 31 0a db 84 d1 24 d5 94 12 (27) Generates ephemeral private key Smyslov Expires 9 June 2023 [Page 46] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 2e 75 2f 5d 6c f0 9a 59 af 47 8d e1 2a a5 aa f5 00000010: c1 ef 9a fb e0 16 5e d9 59 6a c5 96 e8 88 14 62 00000020: 03 81 90 4f 18 d1 60 18 fe dc 9a a1 61 b3 8b c0 00000030: bf e0 d9 a0 d5 2b f2 7b 6b 60 f5 b9 4d e9 0b 36 (28) Computes public key 00000000: de 1d 91 64 c3 3e 58 4a b3 3e 55 5d 3e f6 5b cb 00000010: b5 c6 1c 09 cb 9a 17 91 81 13 5f 46 ce 52 98 c5 00000020: 1e bb 77 96 c9 04 03 2d f4 e5 23 f9 75 e3 ef a8 00000030: 53 52 b4 75 9c 00 55 7b 09 75 49 55 c1 65 7c 4d 00000040: 67 77 00 0a bc cd bc 4c 34 c3 b3 85 ed 86 7d 3b 00000050: 9f f7 15 ea 55 b5 e4 1e 45 d9 b0 4f 69 3f ee 7c 00000060: 89 0e 09 3d 4b 35 2e 8a 3c 0c 33 20 c3 54 7b 44 00000070: db 9f c7 96 a0 1e 9e ae b4 bd 29 73 b6 80 2d 00 (29) Selects SPI for new incoming ESP SA 00000000: 29 0a 8e 3f (30) Computes keys for new ESP SAs 00000000: 4e c4 99 c2 d9 e8 fc 7f 26 fa cf df 20 8f a2 5c 00000010: 85 f8 e3 0c f7 fd 11 5b 5f 80 ba c4 e6 70 8b e4 00000020: 0b 90 d7 8f bd d4 c5 bd c4 31 6f 0b 00000000: 3c cc d8 46 72 44 68 c6 41 84 d2 22 ea 39 7c e8 00000010: aa 83 66 11 3a 26 4d 7b 07 52 6b c7 65 25 73 9d 00000020: 0f 3d 80 bc 8c 34 ff 07 31 11 5e d2 (31) Creates message Create Child SA 4387648D6C9E28FF.82D9FAF87449B936.00000000 IKEv2 I<=R[337] E[309]{ SA[40]{ P[36](#1:ESP:290A8E3F:3#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, KE=GOST3410_2012_512, ESN=Off}}, NONCE[36]{F1C13F...D59412}, KE[136](GOST3410_2012_512){DE1D91...802D00}, TSi[24](1#){10.1.1.2}, TSr[24](1#){10.0.0.0-10.0.0.255}, N[8](ADDITIONAL_TS_POSSIBLE), N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} (32) Computes K1r (i1 = 0) Smyslov Expires 9 June 2023 [Page 47] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 0c 45 d2 29 64 b8 72 57 11 10 3b a0 c2 66 d8 63 00000010: 34 f5 22 43 bf 6b 9a 1b 67 d6 d2 d8 fc 87 75 38 (33) Computes K2r (i2 = 0) 00000000: a9 92 d9 92 1f 15 13 bd db 61 83 43 58 2d dd e6 00000010: 66 28 4f 5d 71 47 a9 d4 8e 31 2e 95 37 f8 c5 d2 (34) Computes K3r (i3 = 0) 00000000: c1 ca 4f dd 2d 02 55 a4 11 9a 10 08 43 2d 61 ea 00000010: 52 68 83 c5 ec 92 53 24 01 b0 a2 0b d2 8f 72 78 (35) Composes MGM nonce 00000000: 00 00 00 00 84 57 87 2b 38 70 63 27 8c dd 88 78 (36) Composes AAD 00000000: 43 87 64 8d 6c 9e 28 ff 82 d9 fa f8 74 49 b9 36 00000010: 2e 20 24 20 00 00 00 00 00 00 01 51 21 00 01 35 (37) Composes plaintext 00000000: 28 00 00 28 00 00 00 24 01 03 04 03 29 0a 8e 3f 00000010: 03 00 00 08 01 00 00 20 03 00 00 08 04 00 00 22 00000020: 00 00 00 08 05 00 00 00 22 00 00 24 f1 c1 3f 5e 00000030: c4 c9 70 81 cb 1f 57 fe af 3d 80 37 92 a9 ff 96 00000040: db 8f 3f 31 0a db 84 d1 24 d5 94 12 2c 00 00 88 00000050: 00 22 00 00 de 1d 91 64 c3 3e 58 4a b3 3e 55 5d 00000060: 3e f6 5b cb b5 c6 1c 09 cb 9a 17 91 81 13 5f 46 00000070: ce 52 98 c5 1e bb 77 96 c9 04 03 2d f4 e5 23 f9 00000080: 75 e3 ef a8 53 52 b4 75 9c 00 55 7b 09 75 49 55 00000090: c1 65 7c 4d 67 77 00 0a bc cd bc 4c 34 c3 b3 85 000000A0: ed 86 7d 3b 9f f7 15 ea 55 b5 e4 1e 45 d9 b0 4f 000000B0: 69 3f ee 7c 89 0e 09 3d 4b 35 2e 8a 3c 0c 33 20 000000C0: c3 54 7b 44 db 9f c7 96 a0 1e 9e ae b4 bd 29 73 000000D0: b6 80 2d 00 2d 00 00 18 01 00 00 00 07 00 00 10 000000E0: 00 00 ff ff 0a 01 01 02 0a 01 01 02 29 00 00 18 000000F0: 01 00 00 00 07 00 00 10 00 00 ff ff 0a 00 00 00 00000100: 0a 00 00 ff 29 00 00 08 00 00 40 02 29 00 00 08 00000110: 00 00 40 0a 00 00 00 08 00 00 40 0b 00 (38) Encrypts plaintext using K3r as K_msg, resulted in ciphertext Smyslov Expires 9 June 2023 [Page 48] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 42 73 5f 2b 14 a0 27 ca 3c 90 67 80 3c 3d 99 02 00000010: 1c 08 c8 67 03 0f 69 f1 c3 64 43 a6 59 74 ce b0 00000020: d7 5d 29 58 53 3a f6 c3 20 04 56 ba 2e af 14 9b 00000030: 2d a3 93 15 2c e5 15 e6 59 2b 7f 47 94 7f 90 82 00000040: ce d3 64 cc 89 92 04 c6 bc 7b ce 61 c6 1d 7f a5 00000050: 45 1c 27 e6 0b 78 1a f2 75 8f 3e 47 53 8e d7 16 00000060: 11 f4 26 04 ae 5e d5 b8 84 b6 ac e6 20 28 da ca 00000070: da 84 fe 0d c4 4d 29 2f 58 30 fe 93 f6 59 04 4a 00000080: 9b aa 97 99 5b 5e 74 9c 5d 45 d5 99 42 16 8c ab 00000090: 62 cb 9f 14 5f f5 25 92 34 5c 8d 61 45 44 55 6d 000000A0: 3d 80 b0 39 f0 39 0b 43 8a f9 b7 b7 17 41 34 ce 000000B0: 36 bf e3 e7 1a 68 61 72 0e f1 91 24 89 ab d7 e9 000000C0: a9 b1 87 38 a1 c0 4c 42 4e 47 62 28 9e d7 1f 02 000000D0: 13 40 69 38 31 f1 91 87 ec 54 11 0a 2d d9 25 15 000000E0: 15 16 37 b7 71 94 11 49 5e f7 28 90 c5 1e 6b 07 000000F0: d9 cf 06 a2 a2 33 0e e0 25 67 db a6 17 11 27 60 00000100: c8 21 f7 79 63 aa b0 f9 7b 95 03 a7 8d 2e d7 df 00000110: 58 e7 30 ab d3 c8 f1 24 40 69 fc 3f bf (39) Computes ICV using K3r as K_msg 00000000: 3a 2d 3c 6b 87 43 ed 6e 80 ab 27 e2 (40) Composes IV 00000000: 00 00 00 00 00 00 00 00 (41) Sends message, peer receives message Smyslov Expires 9 June 2023 [Page 49] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54294<-10.111.15.45:500 [337] 00000000: 43 87 64 8d 6c 9e 28 ff 82 d9 fa f8 74 49 b9 36 00000010: 2e 20 24 20 00 00 00 00 00 00 01 51 21 00 01 35 00000020: 00 00 00 00 00 00 00 00 42 73 5f 2b 14 a0 27 ca 00000030: 3c 90 67 80 3c 3d 99 02 1c 08 c8 67 03 0f 69 f1 00000040: c3 64 43 a6 59 74 ce b0 d7 5d 29 58 53 3a f6 c3 00000050: 20 04 56 ba 2e af 14 9b 2d a3 93 15 2c e5 15 e6 00000060: 59 2b 7f 47 94 7f 90 82 ce d3 64 cc 89 92 04 c6 00000070: bc 7b ce 61 c6 1d 7f a5 45 1c 27 e6 0b 78 1a f2 00000080: 75 8f 3e 47 53 8e d7 16 11 f4 26 04 ae 5e d5 b8 00000090: 84 b6 ac e6 20 28 da ca da 84 fe 0d c4 4d 29 2f 000000A0: 58 30 fe 93 f6 59 04 4a 9b aa 97 99 5b 5e 74 9c 000000B0: 5d 45 d5 99 42 16 8c ab 62 cb 9f 14 5f f5 25 92 000000C0: 34 5c 8d 61 45 44 55 6d 3d 80 b0 39 f0 39 0b 43 000000D0: 8a f9 b7 b7 17 41 34 ce 36 bf e3 e7 1a 68 61 72 000000E0: 0e f1 91 24 89 ab d7 e9 a9 b1 87 38 a1 c0 4c 42 000000F0: 4e 47 62 28 9e d7 1f 02 13 40 69 38 31 f1 91 87 00000100: ec 54 11 0a 2d d9 25 15 15 16 37 b7 71 94 11 49 00000110: 5e f7 28 90 c5 1e 6b 07 d9 cf 06 a2 a2 33 0e e0 00000120: 25 67 db a6 17 11 27 60 c8 21 f7 79 63 aa b0 f9 00000130: 7b 95 03 a7 8d 2e d7 df 58 e7 30 ab d3 c8 f1 24 00000140: 40 69 fc 3f bf 3a 2d 3c 6b 87 43 ed 6e 80 ab 27 00000150: e2 Initiator's actions: (42) Extracts IV from message 00000000: 00 00 00 00 00 00 00 00 (43) Computes K1r (i1 = 0) 00000000: 0c 45 d2 29 64 b8 72 57 11 10 3b a0 c2 66 d8 63 00000010: 34 f5 22 43 bf 6b 9a 1b 67 d6 d2 d8 fc 87 75 38 (44) Computes K2r (i2 = 0) 00000000: a9 92 d9 92 1f 15 13 bd db 61 83 43 58 2d dd e6 00000010: 66 28 4f 5d 71 47 a9 d4 8e 31 2e 95 37 f8 c5 d2 (45) Computes K3r (i3 = 0) 00000000: c1 ca 4f dd 2d 02 55 a4 11 9a 10 08 43 2d 61 ea 00000010: 52 68 83 c5 ec 92 53 24 01 b0 a2 0b d2 8f 72 78 (46) Composes MGM nonce Smyslov Expires 9 June 2023 [Page 50] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 00 00 00 00 84 57 87 2b 38 70 63 27 8c dd 88 78 (47) Extracts ICV from message 00000000: 3a 2d 3c 6b 87 43 ed 6e 80 ab 27 e2 (48) Extracts AAD from message 00000000: 43 87 64 8d 6c 9e 28 ff 82 d9 fa f8 74 49 b9 36 00000010: 2e 20 24 20 00 00 00 00 00 00 01 51 21 00 01 35 (49) Extracts ciphertext from message 00000000: 42 73 5f 2b 14 a0 27 ca 3c 90 67 80 3c 3d 99 02 00000010: 1c 08 c8 67 03 0f 69 f1 c3 64 43 a6 59 74 ce b0 00000020: d7 5d 29 58 53 3a f6 c3 20 04 56 ba 2e af 14 9b 00000030: 2d a3 93 15 2c e5 15 e6 59 2b 7f 47 94 7f 90 82 00000040: ce d3 64 cc 89 92 04 c6 bc 7b ce 61 c6 1d 7f a5 00000050: 45 1c 27 e6 0b 78 1a f2 75 8f 3e 47 53 8e d7 16 00000060: 11 f4 26 04 ae 5e d5 b8 84 b6 ac e6 20 28 da ca 00000070: da 84 fe 0d c4 4d 29 2f 58 30 fe 93 f6 59 04 4a 00000080: 9b aa 97 99 5b 5e 74 9c 5d 45 d5 99 42 16 8c ab 00000090: 62 cb 9f 14 5f f5 25 92 34 5c 8d 61 45 44 55 6d 000000A0: 3d 80 b0 39 f0 39 0b 43 8a f9 b7 b7 17 41 34 ce 000000B0: 36 bf e3 e7 1a 68 61 72 0e f1 91 24 89 ab d7 e9 000000C0: a9 b1 87 38 a1 c0 4c 42 4e 47 62 28 9e d7 1f 02 000000D0: 13 40 69 38 31 f1 91 87 ec 54 11 0a 2d d9 25 15 000000E0: 15 16 37 b7 71 94 11 49 5e f7 28 90 c5 1e 6b 07 000000F0: d9 cf 06 a2 a2 33 0e e0 25 67 db a6 17 11 27 60 00000100: c8 21 f7 79 63 aa b0 f9 7b 95 03 a7 8d 2e d7 df 00000110: 58 e7 30 ab d3 c8 f1 24 40 69 fc 3f bf (50) Decrypts ciphertext and verifies ICV using K3r as K_msg, resulted in plaintext Smyslov Expires 9 June 2023 [Page 51] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 28 00 00 28 00 00 00 24 01 03 04 03 29 0a 8e 3f 00000010: 03 00 00 08 01 00 00 20 03 00 00 08 04 00 00 22 00000020: 00 00 00 08 05 00 00 00 22 00 00 24 f1 c1 3f 5e 00000030: c4 c9 70 81 cb 1f 57 fe af 3d 80 37 92 a9 ff 96 00000040: db 8f 3f 31 0a db 84 d1 24 d5 94 12 2c 00 00 88 00000050: 00 22 00 00 de 1d 91 64 c3 3e 58 4a b3 3e 55 5d 00000060: 3e f6 5b cb b5 c6 1c 09 cb 9a 17 91 81 13 5f 46 00000070: ce 52 98 c5 1e bb 77 96 c9 04 03 2d f4 e5 23 f9 00000080: 75 e3 ef a8 53 52 b4 75 9c 00 55 7b 09 75 49 55 00000090: c1 65 7c 4d 67 77 00 0a bc cd bc 4c 34 c3 b3 85 000000A0: ed 86 7d 3b 9f f7 15 ea 55 b5 e4 1e 45 d9 b0 4f 000000B0: 69 3f ee 7c 89 0e 09 3d 4b 35 2e 8a 3c 0c 33 20 000000C0: c3 54 7b 44 db 9f c7 96 a0 1e 9e ae b4 bd 29 73 000000D0: b6 80 2d 00 2d 00 00 18 01 00 00 00 07 00 00 10 000000E0: 00 00 ff ff 0a 01 01 02 0a 01 01 02 29 00 00 18 000000F0: 01 00 00 00 07 00 00 10 00 00 ff ff 0a 00 00 00 00000100: 0a 00 00 ff 29 00 00 08 00 00 40 02 29 00 00 08 00000110: 00 00 40 0a 00 00 00 08 00 00 40 0b 00 (51) Parses received message Create Child SA 4387648D6C9E28FF.82D9FAF87449B936.00000000 IKEv2 R=>I[337] E[309]{ SA[40]{ P[36](#1:ESP:290A8E3F:3#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, KE=GOST3410_2012_512, ESN=Off}}, NONCE[36]{F1C13F...D59412}, KE[136](GOST3410_2012_512){DE1D91...802D00}, TSi[24](1#){10.1.1.2}, TSr[24](1#){10.0.0.0-10.0.0.255}, N[8](ADDITIONAL_TS_POSSIBLE), N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} (52) Computes keys for new ESP SAs 00000000: 4e c4 99 c2 d9 e8 fc 7f 26 fa cf df 20 8f a2 5c 00000010: 85 f8 e3 0c f7 fd 11 5b 5f 80 ba c4 e6 70 8b e4 00000020: 0b 90 d7 8f bd d4 c5 bd c4 31 6f 0b 00000000: 3c cc d8 46 72 44 68 c6 41 84 d2 22 ea 39 7c e8 00000010: aa 83 66 11 3a 26 4d 7b 07 52 6b c7 65 25 73 9d 00000020: 0f 3d 80 bc 8c 34 ff 07 31 11 5e d2 Smyslov Expires 9 June 2023 [Page 52] Internet-Draft GOST algorithms in IKEv2 December 2022 Sub-scenario 4: IKE SA deletion using the INFORMATIONAL exchange. Initiator Responder HDR, SK {D} ---> <--- HDR, SK { } Initiator's actions: (1) Creates message Informational 4387648D6C9E28FF.82D9FAF87449B936.00000003 IKEv2 R<-I[61] E[33]{ D[8](IKE)} (2) Uses previously computed key K3i 00000000: c9 41 22 b5 39 b7 d2 3f c4 4d a6 ae 88 2e ff b4 00000010: f4 c0 90 9c bd bc 63 56 14 62 e8 8f 90 1a e7 eb (3) Composes MGM nonce 00000000: 00 00 00 03 03 a0 05 b7 b2 2d f9 90 bb 6c ff ca (4) Composes AAD 00000000: 43 87 64 8d 6c 9e 28 ff 82 d9 fa f8 74 49 b9 36 00000010: 2e 20 25 08 00 00 00 03 00 00 00 3d 2a 00 00 21 (5) Composes plaintext 00000000: 00 00 00 08 01 00 00 00 00 (6) Encrypts plaintext using K3i as K_msg, resulted in ciphertext 00000000: 3e 17 6f 6c 23 48 06 e9 fd (7) Computes ICV using K3i as K_msg 00000000: 23 7b a2 fc d5 1c 6f 2c c0 1e 21 e4 (8) Composes IV 00000000: 00 00 00 00 00 00 00 03 (9) Sends message, peer receives message Smyslov Expires 9 June 2023 [Page 53] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54294->10.111.15.45:500 [61] 00000000: 43 87 64 8d 6c 9e 28 ff 82 d9 fa f8 74 49 b9 36 00000010: 2e 20 25 08 00 00 00 03 00 00 00 3d 2a 00 00 21 00000020: 00 00 00 00 00 00 00 03 3e 17 6f 6c 23 48 06 e9 00000030: fd 23 7b a2 fc d5 1c 6f 2c c0 1e 21 e4 Responder's actions: (10) Extracts IV from message 00000000: 00 00 00 00 00 00 00 03 (11) Uses previously computed key K3i 00000000: c9 41 22 b5 39 b7 d2 3f c4 4d a6 ae 88 2e ff b4 00000010: f4 c0 90 9c bd bc 63 56 14 62 e8 8f 90 1a e7 eb (12) Composes MGM nonce 00000000: 00 00 00 03 03 a0 05 b7 b2 2d f9 90 bb 6c ff ca (13) Extracts ICV from message 00000000: 23 7b a2 fc d5 1c 6f 2c c0 1e 21 e4 (14) Extracts AAD from message 00000000: 43 87 64 8d 6c 9e 28 ff 82 d9 fa f8 74 49 b9 36 00000010: 2e 20 25 08 00 00 00 03 00 00 00 3d 2a 00 00 21 (15) Extracts ciphertext from message 00000000: 3e 17 6f 6c 23 48 06 e9 fd (16) Decrypts ciphertext and verifies ICV using K3i as K_msg, resulted in plaintext 00000000: 00 00 00 08 01 00 00 00 00 (17) Parses received message Informational 4387648D6C9E28FF.82D9FAF87449B936.00000003 IKEv2 I->R[61] E[33]{ D[8](IKE)} (18) Creates message Smyslov Expires 9 June 2023 [Page 54] Internet-Draft GOST algorithms in IKEv2 December 2022 Informational 4387648D6C9E28FF.82D9FAF87449B936.00000003 IKEv2 I<=R[53] E[25]{} (19) Uses previously computed key K3r 00000000: c1 ca 4f dd 2d 02 55 a4 11 9a 10 08 43 2d 61 ea 00000010: 52 68 83 c5 ec 92 53 24 01 b0 a2 0b d2 8f 72 78 (20) Composes MGM nonce 00000000: 00 00 00 03 84 57 87 2b 38 70 63 27 8c dd 88 78 (21) Composes AAD 00000000: 43 87 64 8d 6c 9e 28 ff 82 d9 fa f8 74 49 b9 36 00000010: 2e 20 25 20 00 00 00 03 00 00 00 35 00 00 00 19 (22) Composes plaintext 00000000: 00 (23) Encrypts plaintext using K3r as K_msg, resulted in ciphertext 00000000: f1 (24) Computes ICV using K3r as K_msg 00000000: 38 3b 47 ed 04 4d af 44 b8 59 9a ce (25) Composes IV 00000000: 00 00 00 00 00 00 00 03 (26) Sends message, peer receives message 10.111.10.171:54294<-10.111.15.45:500 [53] 00000000: 43 87 64 8d 6c 9e 28 ff 82 d9 fa f8 74 49 b9 36 00000010: 2e 20 25 20 00 00 00 03 00 00 00 35 00 00 00 19 00000020: 00 00 00 00 00 00 00 03 f1 38 3b 47 ed 04 4d af 00000030: 44 b8 59 9a ce Initiator's actions: (27) Extracts IV from message 00000000: 00 00 00 00 00 00 00 03 Smyslov Expires 9 June 2023 [Page 55] Internet-Draft GOST algorithms in IKEv2 December 2022 (28) Uses previously computed key K3r 00000000: c1 ca 4f dd 2d 02 55 a4 11 9a 10 08 43 2d 61 ea 00000010: 52 68 83 c5 ec 92 53 24 01 b0 a2 0b d2 8f 72 78 (29) Composes MGM nonce 00000000: 00 00 00 03 84 57 87 2b 38 70 63 27 8c dd 88 78 (30) Extracts ICV from message 00000000: 38 3b 47 ed 04 4d af 44 b8 59 9a ce (31) Extracts AAD from message 00000000: 43 87 64 8d 6c 9e 28 ff 82 d9 fa f8 74 49 b9 36 00000010: 2e 20 25 20 00 00 00 03 00 00 00 35 00 00 00 19 (32) Extracts ciphertext from message 00000000: f1 (33) Decrypts ciphertext and verifies ICV using K3r as K_msg, resulted in plaintext 00000000: 00 (34) Parses received message Informational 4387648D6C9E28FF.82D9FAF87449B936.00000003 IKEv2 R=>I[53] E[25]{} A.2. Scenario 2 With this scenario peers establish, rekey and delete IKE SA and ESP SAs using the following prerequisites: * Peers authenticate each other using digital signatures * Initiator's ID is "CN=IKE Interop Test Client, O=ELVIS-PLUS, C=RU" of type ID_DER_ASN1_DN: 00000010: 30 44 31 20 30 1e 06 03 55 04 03 13 17 49 4b 45 00000020: 20 49 6e 74 65 72 6f 70 20 54 65 73 74 20 43 6c 00000030: 69 65 6e 74 31 13 30 11 06 03 55 04 0a 13 0a 45 00000040: 4c 56 49 53 2d 50 4c 55 53 31 0b 30 09 06 03 55 00000050: 04 06 13 02 52 55 Smyslov Expires 9 June 2023 [Page 56] Internet-Draft GOST algorithms in IKEv2 December 2022 * Responder's ID is "CN=IKE Interop Test Server, O=ELVIS-PLUS, C=RU" of type ID_DER_ASN1_DN: 00000010: 30 44 31 20 30 1e 06 03 55 04 03 13 17 49 4b 45 00000020: 20 49 6e 74 65 72 6f 70 20 54 65 73 74 20 53 65 00000030: 72 76 65 72 31 13 30 11 06 03 55 04 0a 13 0a 45 00000040: 4c 56 49 53 2d 50 4c 55 53 31 0b 30 09 06 03 55 00000050: 04 06 13 02 52 55 * No NAT is present between the peers, but using UDP encapsulation is forced by the initiator by setting NAT_DETECTION_SOURCE_IP notify to all zeroes * IKE fragmentation is used in the IKE_AUTH exchange * IKE SA is created with the following transforms: - ENCR_MAGMA_MGM_KTREE - PRF_HMAC_STREEBOG_512 - GOST3410_2012_256 * ESP SAs are created with the following transforms: - ENCR_MAGMA_MGM_KTREE - ESN off The certificates for this scenatio were obtained from the public testing CA service https://testgost2012.cryptopro.ru/certsrv/ The initiator's certificate private key (little endian): 0000000000: 76 e9 dd b3 f3 a2 08 a2 4e a5 81 9c ae 41 da b4 0000000010: 77 3c 1d d5 dc eb af e6 58 b1 47 d2 d8 29 ce 71 0000000020: 18 a9 85 5d 28 5b 3c e3 23 bd 80 ac 2f 00 cc b6 0000000030: 61 4c 42 a1 65 61 02 cf 33 eb 1f 5f 02 ce 8a b9 The initiator's certificate: 0000000000: 30 82 04 f7 30 82 04 a4 a0 03 02 01 02 02 13 7c 0000000010: 00 03 da a8 9e 1e ff 9e 79 05 fb bb 00 01 00 03 0000000020: da a8 30 0a 06 08 2a 85 03 07 01 01 03 02 30 82 0000000030: 01 0a 31 18 30 16 06 05 2a 85 03 64 01 12 0d 31 0000000040: 32 33 34 35 36 37 38 39 30 31 32 33 31 1a 30 18 0000000050: 06 08 2a 85 03 03 81 03 01 01 12 0c 30 30 31 32 0000000060: 33 34 35 36 37 38 39 30 31 2f 30 2d 06 03 55 04 Smyslov Expires 9 June 2023 [Page 57] Internet-Draft GOST algorithms in IKEv2 December 2022 0000000070: 09 0c 26 d1 83 d0 bb 2e 20 d0 a1 d1 83 d1 89 d1 0000000080: 91 d0 b2 d1 81 d0 ba d0 b8 d0 b9 20 d0 b2 d0 b0 0000000090: d0 bb 20 d0 b4 2e 20 31 38 31 0b 30 09 06 03 55 00000000A0: 04 06 13 02 52 55 31 19 30 17 06 03 55 04 08 0c 00000000B0: 10 d0 b3 2e 20 d0 9c d0 be d1 81 d0 ba d0 b2 d0 00000000C0: b0 31 15 30 13 06 03 55 04 07 0c 0c d0 9c d0 be 00000000D0: d1 81 d0 ba d0 b2 d0 b0 31 25 30 23 06 03 55 04 00000000E0: 0a 0c 1c d0 9e d0 9e d0 9e 20 22 d0 9a d0 a0 d0 00000000F0: 98 d0 9f d0 a2 d0 9e 2d d0 9f d0 a0 d0 9e 22 31 0000000100: 3b 30 39 06 03 55 04 03 0c 32 d0 a2 d0 b5 d1 81 0000000110: d1 82 d0 be d0 b2 d1 8b d0 b9 20 d0 a3 d0 a6 20 0000000120: d0 9e d0 9e d0 9e 20 22 d0 9a d0 a0 d0 98 d0 9f 0000000130: d0 a2 d0 9e 2d d0 9f d0 a0 d0 9e 22 30 1e 17 0d 0000000140: 32 31 31 30 30 31 30 36 31 30 31 30 5a 17 0d 32 0000000150: 32 30 31 30 31 30 36 32 30 31 30 5a 30 44 31 20 0000000160: 30 1e 06 03 55 04 03 13 17 49 4b 45 20 49 6e 74 0000000170: 65 72 6f 70 20 54 65 73 74 20 43 6c 69 65 6e 74 0000000180: 31 13 30 11 06 03 55 04 0a 13 0a 45 4c 56 49 53 0000000190: 2d 50 4c 55 53 31 0b 30 09 06 03 55 04 06 13 02 00000001A0: 52 55 30 81 aa 30 21 06 08 2a 85 03 07 01 01 01 00000001B0: 02 30 15 06 09 2a 85 03 07 01 02 01 02 01 06 08 00000001C0: 2a 85 03 07 01 01 02 03 03 81 84 00 04 81 80 ee 00000001D0: 2f 0a 0e 09 1e 7e 04 ef ba 5b 62 a2 52 86 e1 9c 00000001E0: 24 50 30 50 b0 b4 8a 37 35 b5 fc af 28 94 ec b5 00000001F0: 9b 92 41 5b 69 e2 c9 ba 24 de 6a 72 c4 ef 44 bb 0000000200: 89 a1 05 14 1b 87 3d 6a a3 72 3e 17 ca 7f 39 28 0000000210: ce 16 8b dd 07 52 87 6a 0d 77 42 6d 99 2b 46 2c 0000000220: fd 4b b2 7c d7 c7 17 08 12 54 63 47 9d 14 3d 61 0000000230: ed f2 95 ab 11 80 69 02 a7 66 60 50 7e a4 53 6d 0000000240: ad 01 49 b2 16 8a 95 1d cf 1a 57 93 56 14 5e a3 0000000250: 82 02 59 30 82 02 55 30 0e 06 03 55 1d 0f 01 01 0000000260: ff 04 04 03 02 05 a0 30 13 06 03 55 1d 25 04 0c 0000000270: 30 0a 06 08 2b 06 01 05 05 07 03 11 30 1d 06 03 0000000280: 55 1d 0e 04 16 04 14 40 81 b1 d1 18 75 f0 da 6b 0000000290: 3c 50 5f cd 73 1d d9 77 f2 d7 c1 30 1f 06 03 55 00000002A0: 1d 23 04 18 30 16 80 14 9b 85 5e fb 81 dc 4d 59 00000002B0: 07 51 63 cf be df da 2c 7f c9 44 3c 30 82 01 0f 00000002C0: 06 03 55 1d 1f 04 82 01 06 30 82 01 02 30 81 ff 00000002D0: a0 81 fc a0 81 f9 86 81 b5 68 74 74 70 3a 2f 2f 00000002E0: 74 65 73 74 67 6f 73 74 32 30 31 32 2e 63 72 79 00000002F0: 70 74 6f 70 72 6f 2e 72 75 2f 43 65 72 74 45 6e 0000000300: 72 6f 6c 6c 2f 21 30 34 32 32 21 30 34 33 35 21 0000000310: 30 34 34 31 21 30 34 34 32 21 30 34 33 65 21 30 0000000320: 34 33 32 21 30 34 34 62 21 30 34 33 39 25 32 30 0000000330: 21 30 34 32 33 21 30 34 32 36 25 32 30 21 30 34 0000000340: 31 65 21 30 34 31 65 21 30 34 31 65 25 32 30 21 0000000350: 30 30 32 32 21 30 34 31 61 21 30 34 32 30 21 30 0000000360: 34 31 38 21 30 34 31 66 21 30 34 32 32 21 30 34 Smyslov Expires 9 June 2023 [Page 58] Internet-Draft GOST algorithms in IKEv2 December 2022 0000000370: 31 65 2d 21 30 34 31 66 21 30 34 32 30 21 30 34 0000000380: 31 65 21 30 30 32 32 28 31 29 2e 63 72 6c 86 3f 0000000390: 68 74 74 70 3a 2f 2f 74 65 73 74 67 6f 73 74 32 00000003A0: 30 31 32 2e 63 72 79 70 74 6f 70 72 6f 2e 72 75 00000003B0: 2f 43 65 72 74 45 6e 72 6f 6c 6c 2f 74 65 73 74 00000003C0: 67 6f 73 74 32 30 31 32 28 31 29 2e 63 72 6c 30 00000003D0: 81 da 06 08 2b 06 01 05 05 07 01 01 04 81 cd 30 00000003E0: 81 ca 30 44 06 08 2b 06 01 05 05 07 30 02 86 38 00000003F0: 68 74 74 70 3a 2f 2f 74 65 73 74 67 6f 73 74 32 0000000400: 30 31 32 2e 63 72 79 70 74 6f 70 72 6f 2e 72 75 0000000410: 2f 43 65 72 74 45 6e 72 6f 6c 6c 2f 72 6f 6f 74 0000000420: 32 30 31 38 2e 63 72 74 30 3f 06 08 2b 06 01 05 0000000430: 05 07 30 01 86 33 68 74 74 70 3a 2f 2f 74 65 73 0000000440: 74 67 6f 73 74 32 30 31 32 2e 63 72 79 70 74 6f 0000000450: 70 72 6f 2e 72 75 2f 6f 63 73 70 32 30 31 32 67 0000000460: 2f 6f 63 73 70 2e 73 72 66 30 41 06 08 2b 06 01 0000000470: 05 05 07 30 01 86 35 68 74 74 70 3a 2f 2f 74 65 0000000480: 73 74 67 6f 73 74 32 30 31 32 2e 63 72 79 70 74 0000000490: 6f 70 72 6f 2e 72 75 2f 6f 63 73 70 32 30 31 32 00000004A0: 67 73 74 2f 6f 63 73 70 2e 73 72 66 30 0a 06 08 00000004B0: 2a 85 03 07 01 01 03 02 03 41 00 21 ee 3b e1 fd 00000004C0: 0f 36 90 92 c4 a2 35 26 e8 dc 4e b8 ef 89 40 70 00000004D0: d2 91 39 bc 79 a6 e2 f7 c1 06 bd d5 d6 ff 72 a5 00000004E0: 6c f2 c0 c3 75 e9 ca 67 81 c1 93 96 b4 bd 18 12 00000004F0: 4c 37 f7 d9 73 d6 4c 8a a6 c4 0a 0 1271: SEQUENCE { 4 1188: SEQUENCE { 8 3: [0] { 10 1: INTEGER 2 : } 13 19: INTEGER : 7c 00 03 da a8 9e 1e ff 9e 79 05 fb bb 00 01 00 : 03 da a8 34 10: SEQUENCE { 36 8: OBJECT IDENTIFIER : gost2012Signature256 (1 2 643 7 1 1 3 2) : } 46 266: SEQUENCE { 50 24: SET { 52 22: SEQUENCE { 54 5: OBJECT IDENTIFIER '1 2 643 100 1' 61 13: NumericString '1234567890123' : } : } 76 26: SET { 78 24: SEQUENCE { 80 8: OBJECT IDENTIFIER '1 2 643 3 131 1 1' Smyslov Expires 9 June 2023 [Page 59] Internet-Draft GOST algorithms in IKEv2 December 2022 90 12: NumericString '001234567890' : } : } 104 47: SET { 106 45: SEQUENCE { 108 3: OBJECT IDENTIFIER : streetAddress (2 5 4 9) 113 38: UTF8String 'ул. Сущёвский вал д. 18' : } : } 153 11: SET { 155 9: SEQUENCE { 157 3: OBJECT IDENTIFIER : countryName (2 5 4 6) 162 2: PrintableString 'RU' : } : } 166 25: SET { 168 23: SEQUENCE { 170 3: OBJECT IDENTIFIER : stateOrProvinceName (2 5 4 8) 175 16: UTF8String 'г. Москва' : } : } 193 21: SET { 195 19: SEQUENCE { 197 3: OBJECT IDENTIFIER : localityName (2 5 4 7) 202 12: UTF8String 'Москва' : } : } 216 37: SET { 218 35: SEQUENCE { 220 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 225 28: UTF8String 'ООО "КРИПТО-ПРО"' : } : } 255 59: SET { 257 57: SEQUENCE { 259 3: OBJECT IDENTIFIER : commonName (2 5 4 3) 264 50: UTF8String : 'Тестовый УЦ ООО "КРИПТО-ПРО"' : } : } : } 316 30: SEQUENCE { Smyslov Expires 9 June 2023 [Page 60] Internet-Draft GOST algorithms in IKEv2 December 2022 318 13: UTCTime 01/10/2021 06:10:10 GMT 333 13: UTCTime 01/01/2022 06:20:10 GMT : } 348 68: SEQUENCE { 350 32: SET { 352 30: SEQUENCE { 354 3: OBJECT IDENTIFIER : commonName (2 5 4 3) 359 23: PrintableString 'IKE Interop Test Client' : } : } 384 19: SET { 386 17: SEQUENCE { 388 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 393 10: PrintableString 'ELVIS-PLUS' : } : } 405 11: SET { 407 9: SEQUENCE { 409 3: OBJECT IDENTIFIER : countryName (2 5 4 6) 414 2: PrintableString 'RU' : } : } : } 418 170: SEQUENCE { 421 33: SEQUENCE { 423 8: OBJECT IDENTIFIER : gost2012PublicKey512 (1 2 643 7 1 1 1 2) 433 21: SEQUENCE { 435 9: OBJECT IDENTIFIER : cryptoPro2012Sign512A (1 2 643 7 1 2 1 2 1) 446 8: OBJECT IDENTIFIER : gost2012Digest512 (1 2 643 7 1 1 2 3) : } : } 456 132: BIT STRING, encapsulates { 460 128: OCTET STRING : ee 2f 0a 0e 09 1e 7e 04 ef ba 5b 62 a2 52 86 e1 : 9c 24 50 30 50 b0 b4 8a 37 35 b5 fc af 28 94 ec : b5 9b 92 41 5b 69 e2 c9 ba 24 de 6a 72 c4 ef 44 : bb 89 a1 05 14 1b 87 3d 6a a3 72 3e 17 ca 7f 39 : 28 ce 16 8b dd 07 52 87 6a 0d 77 42 6d 99 2b 46 : 2c fd 4b b2 7c d7 c7 17 08 12 54 63 47 9d 14 3d : 61 ed f2 95 ab 11 80 69 02 a7 66 60 50 7e a4 53 : 6d ad 01 49 b2 16 8a 95 1d cf 1a 57 93 56 14 5e : } Smyslov Expires 9 June 2023 [Page 61] Internet-Draft GOST algorithms in IKEv2 December 2022 : } 591 601: [3] { 595 597: SEQUENCE { 599 14: SEQUENCE { 601 3: OBJECT IDENTIFIER : keyUsage (2 5 29 15) 606 1: BOOLEAN TRUE 609 4: OCTET STRING, encapsulates { 611 2: BIT STRING 5 unused bits : '101'B : } : } 615 19: SEQUENCE { 617 3: OBJECT IDENTIFIER : extKeyUsage (2 5 29 37) 622 12: OCTET STRING, encapsulates { 624 10: SEQUENCE { 626 8: OBJECT IDENTIFIER : ipsecIKE (1 3 6 1 5 5 7 3 17) : } : } : } 636 29: SEQUENCE { 638 3: OBJECT IDENTIFIER : subjectKeyIdentifier (2 5 29 14) 643 22: OCTET STRING, encapsulates { 645 20: OCTET STRING : 40 81 b1 d1 18 75 f0 da 6b 3c 50 5f cd 73 1d d9 : 77 f2 d7 c1 : } : } 667 31: SEQUENCE { 669 3: OBJECT IDENTIFIER : authorityKeyIdentifier (2 5 29 35) 674 24: OCTET STRING, encapsulates { 676 22: SEQUENCE { 678 20: [0] : 9b 85 5e fb 81 dc 4d 59 07 51 63 cf be df da 2c : 7f c9 44 3c : } : } : } 700 271: SEQUENCE { 704 3: OBJECT IDENTIFIER : cRLDistributionPoints (2 5 29 31) 709 262: OCTET STRING, encapsulates { 713 258: SEQUENCE { 717 255: SEQUENCE { Smyslov Expires 9 June 2023 [Page 62] Internet-Draft GOST algorithms in IKEv2 December 2022 720 252: [0] { 723 249: [0] { 726 181: [6] : 'http://testgost2012.cryptopro.ru/CertEnroll/!042' : '2!0435!0441!0442!043e!0432!044b!0439%20!0423!042' : '6%20!041e!041e!041e%20!0022!041a!0420!0418!041f!' : '0422!041e-!041f!0420!041e!0022(1).crl' 910 63: [6] : 'http://testgost2012.cryptopro.ru/CertEnroll/test' : 'gost2012(1).crl' : } : } : } : } : } : } 975 218: SEQUENCE { 978 8: OBJECT IDENTIFIER : authorityInfoAccess (1 3 6 1 5 5 7 1 1) 988 205: OCTET STRING, encapsulates { 991 202: SEQUENCE { 994 68: SEQUENCE { 996 8: OBJECT IDENTIFIER : caIssuers (1 3 6 1 5 5 7 48 2) 1006 56: [6] : 'http://testgost2012.cryptopro.ru/CertEnroll/root' : '2018.crt' : } 1064 63: SEQUENCE { 1066 8: OBJECT IDENTIFIER : ocsp (1 3 6 1 5 5 7 48 1) 1076 51: [6] : 'http://testgost2012.cryptopro.ru/ocsp2012g/ocsp.' : 'srf' : } 1129 65: SEQUENCE { 1131 8: OBJECT IDENTIFIER : ocsp (1 3 6 1 5 5 7 48 1) 1141 53: [6] : 'http://testgost2012.cryptopro.ru/ocsp2012gst/ocs' : 'p.srf' : } : } : } : } : } : } : } Smyslov Expires 9 June 2023 [Page 63] Internet-Draft GOST algorithms in IKEv2 December 2022 1196 10: SEQUENCE { 1198 8: OBJECT IDENTIFIER : gost2012Signature256 (1 2 643 7 1 1 3 2) : } 1208 65: BIT STRING : 21 ee 3b e1 fd 0f 36 90 92 c4 a2 35 26 e8 dc 4e : b8 ef 89 40 70 d2 91 39 bc 79 a6 e2 f7 c1 06 bd : d5 d6 ff 72 a5 6c f2 c0 c3 75 e9 ca 67 81 c1 93 : 96 b4 bd 18 12 4c 37 f7 d9 73 d6 4c 8a a6 c4 0a : } The responder's certificate private key (little endian): 0000000000: cb 73 0c 81 6f ac 6d 81 9f 82 ae 15 a9 08 12 17 0000000010: d3 1b 97 64 b7 1c 34 0d d3 dd 90 1f 15 8c 9b 06 The responder's certificate: 0000000000: 30 82 04 b2 30 82 04 5f a0 03 02 01 02 02 13 7c 0000000010: 00 03 d9 02 ec f9 34 3e c8 aa d6 59 00 01 00 03 0000000020: d9 02 30 0a 06 08 2a 85 03 07 01 01 03 02 30 82 0000000030: 01 0a 31 18 30 16 06 05 2a 85 03 64 01 12 0d 31 0000000040: 32 33 34 35 36 37 38 39 30 31 32 33 31 1a 30 18 0000000050: 06 08 2a 85 03 03 81 03 01 01 12 0c 30 30 31 32 0000000060: 33 34 35 36 37 38 39 30 31 2f 30 2d 06 03 55 04 0000000070: 09 0c 26 d1 83 d0 bb 2e 20 d0 a1 d1 83 d1 89 d1 0000000080: 91 d0 b2 d1 81 d0 ba d0 b8 d0 b9 20 d0 b2 d0 b0 0000000090: d0 bb 20 d0 b4 2e 20 31 38 31 0b 30 09 06 03 55 00000000A0: 04 06 13 02 52 55 31 19 30 17 06 03 55 04 08 0c 00000000B0: 10 d0 b3 2e 20 d0 9c d0 be d1 81 d0 ba d0 b2 d0 00000000C0: b0 31 15 30 13 06 03 55 04 07 0c 0c d0 9c d0 be 00000000D0: d1 81 d0 ba d0 b2 d0 b0 31 25 30 23 06 03 55 04 00000000E0: 0a 0c 1c d0 9e d0 9e d0 9e 20 22 d0 9a d0 a0 d0 00000000F0: 98 d0 9f d0 a2 d0 9e 2d d0 9f d0 a0 d0 9e 22 31 0000000100: 3b 30 39 06 03 55 04 03 0c 32 d0 a2 d0 b5 d1 81 0000000110: d1 82 d0 be d0 b2 d1 8b d0 b9 20 d0 a3 d0 a6 20 0000000120: d0 9e d0 9e d0 9e 20 22 d0 9a d0 a0 d0 98 d0 9f 0000000130: d0 a2 d0 9e 2d d0 9f d0 a0 d0 9e 22 30 1e 17 0d 0000000140: 32 31 30 39 33 30 31 33 32 34 30 36 5a 17 0d 32 0000000150: 31 31 32 33 30 31 33 33 34 30 36 5a 30 44 31 20 0000000160: 30 1e 06 03 55 04 03 13 17 49 4b 45 20 49 6e 74 0000000170: 65 72 6f 70 20 54 65 73 74 20 53 65 72 76 65 72 0000000180: 31 13 30 11 06 03 55 04 0a 13 0a 45 4c 56 49 53 0000000190: 2d 50 4c 55 53 31 0b 30 09 06 03 55 04 06 13 02 00000001A0: 52 55 30 66 30 1f 06 08 2a 85 03 07 01 01 01 01 00000001B0: 30 13 06 07 2a 85 03 02 02 24 00 06 08 2a 85 03 00000001C0: 07 01 01 02 02 03 43 00 04 40 5b b3 14 3e f4 70 00000001D0: c1 70 d7 f3 27 25 d8 53 7c e6 de 6d 8c 29 f6 b2 Smyslov Expires 9 June 2023 [Page 64] Internet-Draft GOST algorithms in IKEv2 December 2022 00000001E0: 32 64 56 dc b1 77 f2 3d fa f4 2a 5c f3 74 86 7f 00000001F0: 04 72 51 c1 cf b3 43 36 f5 95 a2 af 05 47 57 1a 0000000200: 55 c0 78 a4 9d 64 26 b8 61 14 a3 82 02 59 30 82 0000000210: 02 55 30 0e 06 03 55 1d 0f 01 01 ff 04 04 03 02 0000000220: 05 a0 30 13 06 03 55 1d 25 04 0c 30 0a 06 08 2b 0000000230: 06 01 05 05 07 03 11 30 1d 06 03 55 1d 0e 04 16 0000000240: 04 14 e0 d3 f0 09 ad ce 6c a5 47 ba 9b f7 a6 a5 0000000250: 1b 06 14 ba a5 43 30 1f 06 03 55 1d 23 04 18 30 0000000260: 16 80 14 9b 85 5e fb 81 dc 4d 59 07 51 63 cf be 0000000270: df da 2c 7f c9 44 3c 30 82 01 0f 06 03 55 1d 1f 0000000280: 04 82 01 06 30 82 01 02 30 81 ff a0 81 fc a0 81 0000000290: f9 86 81 b5 68 74 74 70 3a 2f 2f 74 65 73 74 67 00000002A0: 6f 73 74 32 30 31 32 2e 63 72 79 70 74 6f 70 72 00000002B0: 6f 2e 72 75 2f 43 65 72 74 45 6e 72 6f 6c 6c 2f 00000002C0: 21 30 34 32 32 21 30 34 33 35 21 30 34 34 31 21 00000002D0: 30 34 34 32 21 30 34 33 65 21 30 34 33 32 21 30 00000002E0: 34 34 62 21 30 34 33 39 25 32 30 21 30 34 32 33 00000002F0: 21 30 34 32 36 25 32 30 21 30 34 31 65 21 30 34 0000000300: 31 65 21 30 34 31 65 25 32 30 21 30 30 32 32 21 0000000310: 30 34 31 61 21 30 34 32 30 21 30 34 31 38 21 30 0000000320: 34 31 66 21 30 34 32 32 21 30 34 31 65 2d 21 30 0000000330: 34 31 66 21 30 34 32 30 21 30 34 31 65 21 30 30 0000000340: 32 32 28 31 29 2e 63 72 6c 86 3f 68 74 74 70 3a 0000000350: 2f 2f 74 65 73 74 67 6f 73 74 32 30 31 32 2e 63 0000000360: 72 79 70 74 6f 70 72 6f 2e 72 75 2f 43 65 72 74 0000000370: 45 6e 72 6f 6c 6c 2f 74 65 73 74 67 6f 73 74 32 0000000380: 30 31 32 28 31 29 2e 63 72 6c 30 81 da 06 08 2b 0000000390: 06 01 05 05 07 01 01 04 81 cd 30 81 ca 30 44 06 00000003A0: 08 2b 06 01 05 05 07 30 02 86 38 68 74 74 70 3a 00000003B0: 2f 2f 74 65 73 74 67 6f 73 74 32 30 31 32 2e 63 00000003C0: 72 79 70 74 6f 70 72 6f 2e 72 75 2f 43 65 72 74 00000003D0: 45 6e 72 6f 6c 6c 2f 72 6f 6f 74 32 30 31 38 2e 00000003E0: 63 72 74 30 3f 06 08 2b 06 01 05 05 07 30 01 86 00000003F0: 33 68 74 74 70 3a 2f 2f 74 65 73 74 67 6f 73 74 0000000400: 32 30 31 32 2e 63 72 79 70 74 6f 70 72 6f 2e 72 0000000410: 75 2f 6f 63 73 70 32 30 31 32 67 2f 6f 63 73 70 0000000420: 2e 73 72 66 30 41 06 08 2b 06 01 05 05 07 30 01 0000000430: 86 35 68 74 74 70 3a 2f 2f 74 65 73 74 67 6f 73 0000000440: 74 32 30 31 32 2e 63 72 79 70 74 6f 70 72 6f 2e 0000000450: 72 75 2f 6f 63 73 70 32 30 31 32 67 73 74 2f 6f 0000000460: 63 73 70 2e 73 72 66 30 0a 06 08 2a 85 03 07 01 0000000470: 01 03 02 03 41 00 a5 39 5f ca 48 e1 c2 93 c1 e0 0000000480: 8a 64 74 0f 6b 86 a2 15 9b 46 29 d0 42 71 4f ce 0000000490: e7 52 d7 d7 3d aa 47 ce cf 52 63 8f 26 b2 17 5f 00000004A0: ad 96 57 76 ea 5f d0 87 bb 12 29 e4 06 0e e1 5f 00000004B0: fd 59 81 fb 34 6d Smyslov Expires 9 June 2023 [Page 65] Internet-Draft GOST algorithms in IKEv2 December 2022 0 1202: SEQUENCE { 4 1119: SEQUENCE { 8 3: [0] { 10 1: INTEGER 2 : } 13 19: INTEGER : 7c 00 03 d9 02 ec f9 34 3e c8 aa d6 59 00 01 00 : 03 d9 02 34 10: SEQUENCE { 36 8: OBJECT IDENTIFIER : gost2012Signature256 (1 2 643 7 1 1 3 2) : } 46 266: SEQUENCE { 50 24: SET { 52 22: SEQUENCE { 54 5: OBJECT IDENTIFIER '1 2 643 100 1' 61 13: NumericString '1234567890123' : } : } 76 26: SET { 78 24: SEQUENCE { 80 8: OBJECT IDENTIFIER '1 2 643 3 131 1 1' 90 12: NumericString '001234567890' : } : } 104 47: SET { 106 45: SEQUENCE { 108 3: OBJECT IDENTIFIER : streetAddress (2 5 4 9) 113 38: UTF8String 'ул. Сущёвский вал д. 18' : } : } 153 11: SET { 155 9: SEQUENCE { 157 3: OBJECT IDENTIFIER : countryName (2 5 4 6) 162 2: PrintableString 'RU' : } : } 166 25: SET { 168 23: SEQUENCE { 170 3: OBJECT IDENTIFIER : stateOrProvinceName (2 5 4 8) 175 16: UTF8String 'г. Москва' : } : } 193 21: SET { 195 19: SEQUENCE { Smyslov Expires 9 June 2023 [Page 66] Internet-Draft GOST algorithms in IKEv2 December 2022 197 3: OBJECT IDENTIFIER : localityName (2 5 4 7) 202 12: UTF8String 'Москва' : } : } 216 37: SET { 218 35: SEQUENCE { 220 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 225 28: UTF8String 'ООО "КРИПТО-ПРО"' : } : } 255 59: SET { 257 57: SEQUENCE { 259 3: OBJECT IDENTIFIER : commonName (2 5 4 3) 264 50: UTF8String : 'Тестовый УЦ ООО "КРИПТО-ПРО"' : } : } : } 316 30: SEQUENCE { 318 13: UTCTime 30/09/2021 13:24:06 GMT 333 13: UTCTime 30/12/2021 13:34:06 GMT : } 348 68: SEQUENCE { 350 32: SET { 352 30: SEQUENCE { 354 3: OBJECT IDENTIFIER : commonName (2 5 4 3) 359 23: PrintableString 'IKE Interop Test Server' : } : } 384 19: SET { 386 17: SEQUENCE { 388 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 393 10: PrintableString 'ELVIS-PLUS' : } : } 405 11: SET { 407 9: SEQUENCE { 409 3: OBJECT IDENTIFIER : countryName (2 5 4 6) 414 2: PrintableString 'RU' : } : } : } Smyslov Expires 9 June 2023 [Page 67] Internet-Draft GOST algorithms in IKEv2 December 2022 418 102: SEQUENCE { 420 31: SEQUENCE { 422 8: OBJECT IDENTIFIER : gost2012PublicKey256 (1 2 643 7 1 1 1 1) 432 19: SEQUENCE { 434 7: OBJECT IDENTIFIER : cryptoProSignXA (1 2 643 2 2 36 0) 443 8: OBJECT IDENTIFIER : gost2012Digest256 (1 2 643 7 1 1 2 2) : } : } 453 67: BIT STRING, encapsulates { 456 64: OCTET STRING : 5b b3 14 3e f4 70 c1 70 d7 f3 27 25 d8 53 7c e6 : de 6d 8c 29 f6 b2 32 64 56 dc b1 77 f2 3d fa f4 : 2a 5c f3 74 86 7f 04 72 51 c1 cf b3 43 36 f5 95 : a2 af 05 47 57 1a 55 c0 78 a4 9d 64 26 b8 61 14 : } : } 522 601: [3] { 526 597: SEQUENCE { 530 14: SEQUENCE { 532 3: OBJECT IDENTIFIER : keyUsage (2 5 29 15) 537 1: BOOLEAN TRUE 540 4: OCTET STRING, encapsulates { 542 2: BIT STRING 5 unused bits : '101'B : } : } 546 19: SEQUENCE { 548 3: OBJECT IDENTIFIER : extKeyUsage (2 5 29 37) 553 12: OCTET STRING, encapsulates { 555 10: SEQUENCE { 557 8: OBJECT IDENTIFIER : ipsecIKE (1 3 6 1 5 5 7 3 17) : } : } : } 567 29: SEQUENCE { 569 3: OBJECT IDENTIFIER : subjectKeyIdentifier (2 5 29 14) 574 22: OCTET STRING, encapsulates { 576 20: OCTET STRING : e0 d3 f0 09 ad ce 6c a5 47 ba 9b f7 a6 a5 1b 06 : 14 ba a5 43 : } Smyslov Expires 9 June 2023 [Page 68] Internet-Draft GOST algorithms in IKEv2 December 2022 : } 598 31: SEQUENCE { 600 3: OBJECT IDENTIFIER : authorityKeyIdentifier (2 5 29 35) 605 24: OCTET STRING, encapsulates { 607 22: SEQUENCE { 609 20: [0] : 9b 85 5e fb 81 dc 4d 59 07 51 63 cf be df dA 2C : 7f C9 44 3c : } : } : } 631 271: SEQUENCE { 635 3: OBJECT IDENTIFIER : cRLDistributionPoints (2 5 29 31) 640 262: OCTET STRING, encapsulates { 644 258: SEQUENCE { 648 255: SEQUENCE { 651 252: [0] { 654 249: [0] { 657 181: [6] : 'http://testgost2012.cryptopro.ru/CertEnroll/!042' : '2!0435!0441!0442!043e!0432!044b!0439%20!0423!042' : '6%20!041e!041e!041e%20!0022!041a!0420!0418!041f!' : '0422!041e-!041f!0420!041e!0022(1).crl' 841 63: [6] : 'http://testgost2012.cryptopro.ru/CertEnroll/test' : 'gost2012(1).crl' : } : } : } : } : } : } 906 218: SEQUENCE { 909 8: OBJECT IDENTIFIER : authorityInfoAccess (1 3 6 1 5 5 7 1 1) 919 205: OCTET STRING, encapsulates { 922 202: SEQUENCE { 925 68: SEQUENCE { 927 8: OBJECT IDENTIFIER : caIssuers (1 3 6 1 5 5 7 48 2) 937 56: [6] : 'http://testgost2012.cryptopro.ru/CertEnroll/root' : '2018.crt' : } 995 63: SEQUENCE { 997 8: OBJECT IDENTIFIER Smyslov Expires 9 June 2023 [Page 69] Internet-Draft GOST algorithms in IKEv2 December 2022 : ocsp (1 3 6 1 5 5 7 48 1) 1007 51: [6] : 'http://testgost2012.cryptopro.ru/ocsp2012g/ocsp.' : 'srf' : } 1060 65: SEQUENCE { 1062 8: OBJECT IDENTIFIER : ocsp (1 3 6 1 5 5 7 48 1) 1072 53: [6] : 'http://testgost2012.cryptopro.ru/ocsp2012gst/ocs' : 'p.srf' : } : } : } : } : } : } : } 1127 10: SEQUENCE { 1129 8: OBJECT IDENTIFIER : gost2012Signature256 (1 2 643 7 1 1 3 2) : } 1139 65: BIT STRING : a5 39 5f ca 48 e1 c2 93 c1 e0 8a 64 74 0f 6b 86 : a2 15 9b 46 29 d0 42 71 4f ce e7 52 d7 d7 3d aa : 47 ce cf 52 63 8f 26 b2 17 5f ad 96 57 76 ea 5f : d0 87 bb 12 29 e4 06 0e e1 5f fd 59 81 fb 34 6d : } CA certificate: 0000000000: 30 82 05 1c 30 82 04 c9 a0 03 02 01 02 02 10 3b 0000000010: 20 8a e5 fd 46 68 86 49 a0 50 fa af a8 83 93 30 0000000020: 0a 06 08 2a 85 03 07 01 01 03 02 30 82 01 0a 31 0000000030: 18 30 16 06 05 2a 85 03 64 01 12 0d 31 32 33 34 0000000040: 35 36 37 38 39 30 31 32 33 31 1a 30 18 06 08 2a 0000000050: 85 03 03 81 03 01 01 12 0c 30 30 31 32 33 34 35 0000000060: 36 37 38 39 30 31 2f 30 2d 06 03 55 04 09 0c 26 0000000070: d1 83 d0 bb 2e 20 d0 a1 d1 83 d1 89 d1 91 d0 b2 0000000080: d1 81 d0 ba d0 b8 d0 b9 20 d0 b2 d0 b0 d0 bb 20 0000000090: d0 b4 2e 20 31 38 31 0b 30 09 06 03 55 04 06 13 00000000A0: 02 52 55 31 19 30 17 06 03 55 04 08 0c 10 d0 b3 00000000B0: 2e 20 d0 9c d0 be d1 81 d0 ba d0 b2 d0 b0 31 15 00000000C0: 30 13 06 03 55 04 07 0c 0c d0 9c d0 be d1 81 d0 00000000D0: ba d0 b2 d0 b0 31 25 30 23 06 03 55 04 0a 0c 1c 00000000E0: d0 9e d0 9e d0 9e 20 22 d0 9a d0 a0 d0 98 d0 9f 00000000F0: d0 a2 d0 9e 2d d0 9f d0 a0 d0 9e 22 31 3b 30 39 0000000100: 06 03 55 04 03 0c 32 d0 a2 d0 b5 d1 81 d1 82 d0 Smyslov Expires 9 June 2023 [Page 70] Internet-Draft GOST algorithms in IKEv2 December 2022 0000000110: be d0 b2 d1 8b d0 b9 20 d0 a3 d0 a6 20 d0 9e d0 0000000120: 9e d0 9e 20 22 d0 9a d0 a0 d0 98 d0 9f d0 a2 d0 0000000130: 9e 2d d0 9f d0 a0 d0 9e 22 30 1e 17 0d 31 38 30 0000000140: 39 31 32 31 30 31 39 33 30 5a 17 0d 32 33 30 39 0000000150: 31 32 31 30 32 38 35 35 5a 30 82 01 0a 31 18 30 0000000160: 16 06 05 2a 85 03 64 01 12 0d 31 32 33 34 35 36 0000000170: 37 38 39 30 31 32 33 31 1a 30 18 06 08 2a 85 03 0000000180: 03 81 03 01 01 12 0c 30 30 31 32 33 34 35 36 37 0000000190: 38 39 30 31 2f 30 2d 06 03 55 04 09 0c 26 d1 83 00000001A0: d0 bb 2e 20 d0 a1 d1 83 d1 89 d1 91 d0 b2 d1 81 00000001B0: d0 ba d0 b8 d0 b9 20 d0 b2 d0 b0 d0 bb 20 d0 b4 00000001C0: 2e 20 31 38 31 0b 30 09 06 03 55 04 06 13 02 52 00000001D0: 55 31 19 30 17 06 03 55 04 08 0c 10 d0 b3 2e 20 00000001E0: d0 9c d0 be d1 81 d0 ba d0 b2 d0 b0 31 15 30 13 00000001F0: 06 03 55 04 07 0c 0c d0 9c d0 be d1 81 d0 ba d0 0000000200: b2 d0 b0 31 25 30 23 06 03 55 04 0a 0c 1c d0 9e 0000000210: d0 9e d0 9e 20 22 d0 9a d0 a0 d0 98 d0 9f d0 a2 0000000220: d0 9e 2d d0 9f d0 a0 d0 9e 22 31 3b 30 39 06 03 0000000230: 55 04 03 0c 32 d0 a2 d0 b5 d1 81 d1 82 d0 be d0 0000000240: b2 d1 8b d0 b9 20 d0 a3 d0 a6 20 d0 9e d0 9e d0 0000000250: 9e 20 22 d0 9a d0 a0 d0 98 d0 9f d0 a2 d0 9e 2d 0000000260: d0 9f d0 a0 d0 9e 22 30 66 30 1f 06 08 2a 85 03 0000000270: 07 01 01 01 01 30 13 06 07 2a 85 03 02 02 23 01 0000000280: 06 08 2a 85 03 07 01 01 02 02 03 43 00 04 40 98 0000000290: 1f fd a9 50 cd 21 86 30 f4 59 06 72 a9 d6 3d 6b 00000002A0: c0 33 82 06 46 37 e3 dc 21 4a b1 f8 9f b7 56 ec 00000002B0: a5 2d b5 81 87 b6 9d c2 2e df fd 09 33 53 9c 18 00000002C0: 32 ac d7 42 2e 09 a5 f4 36 a3 a5 c1 d2 22 f0 a3 00000002D0: 82 01 fe 30 82 01 fa 30 36 06 05 2a 85 03 64 6f 00000002E0: 04 2d 0c 2b 22 d0 9a d1 80 d0 b8 d0 bf d1 82 d0 00000002F0: be d0 9f d1 80 d0 be 20 43 53 50 22 20 28 d0 b2 0000000300: d0 b5 d1 80 d1 81 d0 b8 d1 8f 20 34 2e 30 29 30 0000000310: 82 01 21 06 05 2a 85 03 64 70 04 82 01 16 30 82 0000000320: 01 12 0c 2b 22 d0 9a d1 80 d0 b8 d0 bf d1 82 d0 0000000330: be d0 9f d1 80 d0 be 20 43 53 50 22 20 28 d0 b2 0000000340: d0 b5 d1 80 d1 81 d0 b8 d1 8f 20 34 2e 30 29 0c 0000000350: 41 d0 a3 d0 b4 d0 be d1 81 d1 82 d0 be d0 b2 d0 0000000360: b5 d1 80 d1 8f d1 8e d1 89 d0 b8 d0 b9 20 d1 86 0000000370: d0 b5 d0 bd d1 82 d1 80 20 22 d0 9a d1 80 d0 b8 0000000380: d0 bf d1 82 d0 be d0 9f d1 80 d0 be 20 d0 a3 d0 0000000390: a6 22 0c 4f d0 a1 d0 b5 d1 80 d1 82 d0 b8 d1 84 00000003A0: d0 b8 d0 ba d0 b0 d1 82 20 d1 81 d0 be d0 be d1 00000003B0: 82 d0 b2 d0 b5 d1 82 d1 81 d1 82 d0 b2 d0 b8 d1 00000003C0: 8f 20 e2 84 96 20 d0 a1 d0 a4 2f 30 30 30 2d 30 00000003D0: 30 30 30 20 d0 be d1 82 20 30 30 2e 30 30 2e 30 00000003E0: 30 30 30 0c 4f d0 a1 d0 b5 d1 80 d1 82 d0 b8 d1 00000003F0: 84 d0 b8 d0 ba d0 b0 d1 82 20 d1 81 d0 be d0 be 0000000400: d1 82 d0 b2 d0 b5 d1 82 d1 81 d1 82 d0 b2 d0 b8 Smyslov Expires 9 June 2023 [Page 71] Internet-Draft GOST algorithms in IKEv2 December 2022 0000000410: d1 8f 20 e2 84 96 20 d0 a1 d0 a4 2f 30 30 30 2d 0000000420: 30 30 30 30 20 d0 be d1 82 20 30 30 2e 30 30 2e 0000000430: 30 30 30 30 30 0b 06 03 55 1d 0f 04 04 03 02 01 0000000440: 86 30 0f 06 03 55 1d 13 01 01 ff 04 05 30 03 01 0000000450: 01 ff 30 1d 06 03 55 1d 0e 04 16 04 14 9b 85 5e 0000000460: fb 81 dc 4d 59 07 51 63 cf be df da 2c 7f c9 44 0000000470: 3c 30 12 06 09 2b 06 01 04 01 82 37 15 01 04 05 0000000480: 02 03 01 00 01 30 25 06 03 55 1d 20 04 1e 30 1c 0000000490: 30 08 06 06 2a 85 03 64 71 01 30 08 06 06 2a 85 00000004A0: 03 64 71 02 30 06 06 04 55 1d 20 00 30 23 06 09 00000004B0: 2b 06 01 04 01 82 37 15 02 04 16 04 14 c8 da 66 00000004C0: cb b6 97 d2 3e c9 67 1d c2 5b 64 3a ab dc bb cf 00000004D0: 69 30 0a 06 08 2a 85 03 07 01 01 03 02 03 41 00 00000004E0: 3e 95 cd d8 1f 95 bd 09 ab 73 82 f5 04 e0 f2 66 00000004F0: 12 32 82 9b 2b 03 cc 4b c0 b3 73 f8 e7 0d d6 bd 0000000500: 83 c8 27 2d 01 c1 ec ef 65 5d ac 77 fd dd da 9d 0000000510: 04 e2 bf e8 02 7f 87 36 1b cf ac 7a 28 9c 21 fe 0 1308: SEQUENCE { 4 1225: SEQUENCE { 8 3: [0] { 10 1: INTEGER 2 : } 13 16: INTEGER : 3b 20 8a e5 fd 46 68 86 49 a0 50 fa af a8 83 93 31 10: SEQUENCE { 33 8: OBJECT IDENTIFIER : gost2012Signature256 (1 2 643 7 1 1 3 2) : } 43 266: SEQUENCE { 47 24: SET { 49 22: SEQUENCE { 51 5: OBJECT IDENTIFIER '1 2 643 100 1' 58 13: NumericString '1234567890123' : } : } 73 26: SET { 75 24: SEQUENCE { 77 8: OBJECT IDENTIFIER '1 2 643 3 131 1 1' 87 12: NumericString '001234567890' : } : } 101 47: SET { 103 45: SEQUENCE { 105 3: OBJECT IDENTIFIER : streetAddress (2 5 4 9) 110 38: UTF8String 'ул. Сущёвский вал д. 18' : } Smyslov Expires 9 June 2023 [Page 72] Internet-Draft GOST algorithms in IKEv2 December 2022 : } 150 11: SET { 152 9: SEQUENCE { 154 3: OBJECT IDENTIFIER : countryName (2 5 4 6) 159 2: PrintableString 'RU' : } : } 163 25: SET { 165 23: SEQUENCE { 167 3: OBJECT IDENTIFIER : stateOrProvinceName (2 5 4 8) 172 16: UTF8String 'г. Москва' : } : } 190 21: SET { 192 19: SEQUENCE { 194 3: OBJECT IDENTIFIER : localityName (2 5 4 7) 199 12: UTF8String 'Москва' : } : } 213 37: SET { 215 35: SEQUENCE { 217 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 222 28: UTF8String 'ООО "КРИПТО-ПРО"' : } : } 252 59: SET { 254 57: SEQUENCE { 256 3: OBJECT IDENTIFIER : commonName (2 5 4 3) 261 50: UTF8String : 'Тестовый УЦ ООО "КРИПТО-ПРО"' : } : } : } 313 30: SEQUENCE { 315 13: UTCTime 12/09/2018 10:19:30 GMT 330 13: UTCTime 12/09/2023 10:28:55 GMT : } 345 266: SEQUENCE { 349 24: SET { 351 22: SEQUENCE { 353 5: OBJECT IDENTIFIER '1 2 643 100 1' 360 13: NumericString '1234567890123' : } Smyslov Expires 9 June 2023 [Page 73] Internet-Draft GOST algorithms in IKEv2 December 2022 : } 375 26: SET { 377 24: SEQUENCE { 379 8: OBJECT IDENTIFIER '1 2 643 3 131 1 1' 389 12: NumericString '001234567890' : } : } 403 47: SET { 405 45: SEQUENCE { 407 3: OBJECT IDENTIFIER : streetAddress (2 5 4 9) 412 38: UTF8String 'ул. Сущёвский вал д. 18' : } : } 452 11: SET { 454 9: SEQUENCE { 456 3: OBJECT IDENTIFIER : countryName (2 5 4 6) 461 2: PrintableString 'RU' : } : } 465 25: SET { 467 23: SEQUENCE { 469 3: OBJECT IDENTIFIER : stateOrProvinceName (2 5 4 8) 474 16: UTF8String 'г. Москва' : } : } 492 21: SET { 494 19: SEQUENCE { 496 3: OBJECT IDENTIFIER : localityName (2 5 4 7) 501 12: UTF8String 'Москва' : } : } 515 37: SET { 517 35: SEQUENCE { 519 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 524 28: UTF8String 'ООО "КРИПТО-ПРО"' : } : } 554 59: SET { 556 57: SEQUENCE { 558 3: OBJECT IDENTIFIER : commonName (2 5 4 3) 563 50: UTF8String : 'Тестовый УЦ ООО "КРИПТО-ПРО"' Smyslov Expires 9 June 2023 [Page 74] Internet-Draft GOST algorithms in IKEv2 December 2022 : } : } : } 615 102: SEQUENCE { 617 31: SEQUENCE { 619 8: OBJECT IDENTIFIER : gost2012PublicKey256 (1 2 643 7 1 1 1 1) 629 19: SEQUENCE { 631 7: OBJECT IDENTIFIER : cryptoProSignA (1 2 643 2 2 35 1) 640 8: OBJECT IDENTIFIER : gost2012Digest256 (1 2 643 7 1 1 2 2) : } : } 650 67: BIT STRING, encapsulates { 653 64: OCTET STRING : 98 1f fd a9 50 cd 21 86 30 f4 59 06 72 a9 d6 3d : 6b c0 33 82 06 46 37 e3 dc 21 4a b1 f8 9f b7 56 : ec a5 2d b5 81 87 b6 9d c2 2e df fd 09 33 53 9c : 18 32 ac d7 42 2e 09 a5 f4 36 a3 a5 c1 d2 22 f0 : } : } 719 510: [3] { 723 506: SEQUENCE { 727 54: SEQUENCE { 729 5: OBJECT IDENTIFIER '1 2 643 100 111' 736 45: OCTET STRING, encapsulates { 738 43: UTF8String : '"КриптоПро CSP" (версия 4.0)' : } : } 783 289: SEQUENCE { 787 5: OBJECT IDENTIFIER '1 2 643 100 112' 794 278: OCTET STRING, encapsulates { 798 274: SEQUENCE { 802 43: UTF8String : '"КриптоПро CSP" (версия 4.0)' 847 65: UTF8String : 'Удостоверяющий центр "КриптоПро УЦ"' 914 79: UTF8String : 'Сертификат соответствия № СФ/000-0000 от 00.00.' : '0000' 995 79: UTF8String : 'Сертификат соответствия № СФ/000-0000 от 00.00.' : '0000' : } : } : } Smyslov Expires 9 June 2023 [Page 75] Internet-Draft GOST algorithms in IKEv2 December 2022 1076 11: SEQUENCE { 1078 3: OBJECT IDENTIFIER : keyUsage (2 5 29 15) 1083 4: OCTET STRING, encapsulates { 1085 2: BIT STRING 1 unused bit : '1100001'B : } : } 1089 15: SEQUENCE { 1091 3: OBJECT IDENTIFIER : basicConstraints (2 5 29 19) 1096 1: BOOLEAN TRUE 1099 5: OCTET STRING, encapsulates { 1101 3: SEQUENCE { 1103 1: BOOLEAN TRUE : } : } : } 1106 29: SEQUENCE { 1108 3: OBJECT IDENTIFIER : subjectKeyIdentifier (2 5 29 14) 1113 22: OCTET STRING, encapsulates { 1115 20: OCTET STRING : 9b 85 5e fb 81 dc 4d 59 07 51 63 cf be df da 2c : 7f c9 44 3c : } : } 1137 18: SEQUENCE { 1139 9: OBJECT IDENTIFIER : cAKeyCertIndexPair (1 3 6 1 4 1 311 21 1) 1150 5: OCTET STRING, encapsulates { 1152 3: INTEGER 65537 : } : } 1157 37: SEQUENCE { 1159 3: OBJECT IDENTIFIER : certificatePolicies (2 5 29 32) 1164 30: OCTET STRING, encapsulates { 1166 28: SEQUENCE { 1168 8: SEQUENCE { 1170 6: OBJECT IDENTIFIER '1 2 643 100 113 1' : } 1178 8: SEQUENCE { 1180 6: OBJECT IDENTIFIER '1 2 643 100 113 2' : } 1188 6: SEQUENCE { 1190 4: OBJECT IDENTIFIER : anyPolicy (2 5 29 32 0) Smyslov Expires 9 June 2023 [Page 76] Internet-Draft GOST algorithms in IKEv2 December 2022 : } : } : } : } 1196 35: SEQUENCE { 1198 9: OBJECT IDENTIFIER : certSrvPreviousCertHash (1 3 6 1 4 1 311 21 2) 1209 22: OCTET STRING, encapsulates { 1211 20: OCTET STRING : c8 da 66 cb b6 97 d2 3e c9 67 1d c2 5b 64 3a ab : dc bb cf 69 : } : } : } : } : } 1233 10: SEQUENCE { 1235 8: OBJECT IDENTIFIER : gost2012Signature256 (1 2 643 7 1 1 3 2) : } 1245 65: BIT STRING : 3e 95 cd d8 1f 95 bd 09 ab 73 82 f5 04 e0 f2 66 : 12 32 82 9b 2b 03 cc 4b c0 b3 73 f8 e7 0d d6 bd : 83 c8 27 2d 01 c1 ec ef 65 5d ac 77 fd dd da 9d : 04 e2 bf e8 02 7f 87 36 1b cf ac 7a 28 9c 21 fe : } This scenario includes four sub-scenarios. Sub-scenario 1: Establishing of IKE and ESP SAs using the IKE_SA_INIT and the IKE_AUTH exchanges. Initiator Responder HDR, SAi1, KEi, Ni [,N+] ---> <--- HDR, N(INVALID_KE_PAYLOAD) HDR, SAi1, KEi, Ni [,N+] ---> <--- HDR, SAr1, KEr, Nr [,CERTREQ] [,N+] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] [N+,] AUTH, SAi2, TSi, TSr} ---> <--- HDR, SK {IDr, [CERT,] [N+,] AUTH, SAr2, TSi, TSr} Initiator's actions: Smyslov Expires 9 June 2023 [Page 77] Internet-Draft GOST algorithms in IKEv2 December 2022 (1) Generates random SPIi for IKE SA 00000000: 92 80 e0 82 2e 75 87 78 (2) Generates random IKE nonce Ni 00000000: 98 44 d5 40 ef 89 46 f4 55 20 0a 55 73 dc ad 73 00000010: dd 2a 6f a8 31 f8 49 05 f5 8e 17 a2 6c cc 01 1f (3) Generates ephemeral private key (512 bit) 00000000: 82 fb 1c 90 c3 a3 c2 16 7f 76 15 5d 69 06 f8 47 00000010: 3e fe 83 3e 21 cd e7 a4 e5 cd d9 71 ef d3 c5 db 00000020: 7e de 50 70 48 96 90 01 0c 81 02 b9 4b 56 f6 47 00000030: cb 27 40 25 58 55 80 32 e9 59 17 10 3b 0f eb 3b (4) Computes public key 00000000: 89 77 c6 d7 2b 08 5d d5 48 b1 ea 5d 99 c5 03 09 00000010: c6 62 fe d7 7d 84 a4 d8 8b 9b a5 c8 3a 7a 05 86 00000020: e2 0d 8d 9b 5d ce 01 18 e2 d2 da 73 83 ee 30 ad 00000030: 49 88 44 6f bd 18 78 b4 bb da c9 df 1a ca d1 2a 00000040: 05 98 75 da 9e 9a 21 e4 db 71 8f af d1 96 c7 8b 00000050: de 9a b2 98 f7 55 bb 74 38 34 a4 da 47 ab 86 15 00000060: d4 c8 33 70 b7 02 79 b8 7f c2 97 6d 03 8f 2d 08 00000070: d7 ab ac 85 4c bf 5a f6 27 57 ad fe 61 50 5e 45 (5) Creates message IKE SA Init 9280E0822E758778.0000000000000000.00000000 IKEv2 R<-I[328] SA[52]{ P[48](#1:IKE::5#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, ENCR_MAGMA_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_512, GOST3410_2012_256}}, KE[136](GOST3410_2012_512){8977C6...505E45}, NONCE[36]{9844D5...CC011F}, N[28](NAT_DETECTION_SOURCE_IP){000000...000000}, N[28](NAT_DETECTION_DESTINATION_IP){7D2124...4E6F10}, N[8](IKEV2_FRAGMENTATION_SUPPORTED), N[12](SIGNATURE_HASH_ALGORITHMS){STREEBOG_256, STREEBOG_512} (6) Sends message, peer receives message Smyslov Expires 9 June 2023 [Page 78] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54294->10.111.15.45:500 [328] 00000000: 92 80 e0 82 2e 75 87 78 00 00 00 00 00 00 00 00 00000010: 21 20 22 08 00 00 00 00 00 00 01 48 22 00 00 34 00000020: 00 00 00 30 01 01 00 05 03 00 00 08 01 00 00 20 00000030: 03 00 00 08 01 00 00 21 03 00 00 08 02 00 00 09 00000040: 03 00 00 08 04 00 00 22 00 00 00 08 04 00 00 21 00000050: 28 00 00 88 00 22 00 00 89 77 c6 d7 2b 08 5d d5 00000060: 48 b1 ea 5d 99 c5 03 09 c6 62 fe d7 7d 84 a4 d8 00000070: 8b 9b a5 c8 3a 7a 05 86 e2 0d 8d 9b 5d ce 01 18 00000080: e2 d2 da 73 83 ee 30 ad 49 88 44 6f bd 18 78 b4 00000090: bb da c9 df 1a ca d1 2a 05 98 75 da 9e 9a 21 e4 000000A0: db 71 8f af d1 96 c7 8b de 9a b2 98 f7 55 bb 74 000000B0: 38 34 a4 da 47 ab 86 15 d4 c8 33 70 b7 02 79 b8 000000C0: 7f c2 97 6d 03 8f 2d 08 d7 ab ac 85 4c bf 5a f6 000000D0: 27 57 ad fe 61 50 5e 45 29 00 00 24 98 44 d5 40 000000E0: ef 89 46 f4 55 20 0a 55 73 dc ad 73 dd 2a 6f a8 000000F0: 31 f8 49 05 f5 8e 17 a2 6c cc 01 1f 29 00 00 1c 00000100: 00 00 40 04 00 00 00 00 00 00 00 00 00 00 00 00 00000110: 00 00 00 00 00 00 00 00 29 00 00 1c 00 00 40 05 00000120: 7d 21 24 87 89 d7 95 71 bd a2 2d 22 9d 51 d0 71 00000130: e9 4e 6f 10 29 00 00 08 00 00 40 2e 00 00 00 0c 00000140: 00 00 40 2f 00 06 00 07 Responder's actions: (7) Parses received message IKE SA Init 9280E0822E758778.0000000000000000.00000000 IKEv2 I->R[328] SA[52]{ P[48](#1:IKE::5#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, ENCR_MAGMA_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_512, GOST3410_2012_256}}, KE[136](GOST3410_2012_512){8977C6...505E45}, NONCE[36]{9844D5...CC011F}, N[28](NAT_DETECTION_SOURCE_IP){000000...000000}, N[28](NAT_DETECTION_DESTINATION_IP){7D2124...4E6F10}, N[8](IKEV2_FRAGMENTATION_SUPPORTED), N[12](SIGNATURE_HASH_ALGORITHMS){STREEBOG_256, STREEBOG_512} (8) Creates message Smyslov Expires 9 June 2023 [Page 79] Internet-Draft GOST algorithms in IKEv2 December 2022 IKE SA Init 9280E0822E758778.0000000000000000.00000000 IKEv2 I<=R[38] N[10](INVALID_KE_PAYLOAD){GOST3410_2012_256} (9) Sends message, peer receives message 10.111.10.171:54294<-10.111.15.45:500 [38] 00000000: 92 80 e0 82 2e 75 87 78 00 00 00 00 00 00 00 00 00000010: 29 20 22 20 00 00 00 00 00 00 00 26 00 00 00 0a 00000020: 00 00 00 11 00 21 Initiator's actions: (10) Parses received message IKE SA Init 9280E0822E758778.0000000000000000.00000000 IKEv2 R=>I[38] N[10](INVALID_KE_PAYLOAD){GOST3410_2012_256}} (11) Generates ephemeral private key (256 bit) 00000000: b9 7c ac df 01 43 44 dd 54 92 33 63 4a 6e da 64 00000010: 38 5b 6a 9c c0 3c 6c 41 c5 02 eb 63 d1 e6 24 21 (12) Computes public key 00000000: 7d b0 49 81 88 6d 1b 02 b2 a6 35 c5 8b ea 90 8c 00000010: 3e 16 de e5 43 13 22 0b ad f5 89 9f 7f 85 54 2d 00000020: 3e db 1e de 85 f7 d5 5d 6f 83 c5 d0 31 bd 31 49 00000030: dd 29 c5 16 16 7d ec 86 16 d8 85 e6 e4 50 ab 46 (13) Creates message Smyslov Expires 9 June 2023 [Page 80] Internet-Draft GOST algorithms in IKEv2 December 2022 IKE SA Init 9280E0822E758778.0000000000000000.00000000 IKEv2 R<-I[264] SA[52]{ P[48](#1:IKE::5#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, ENCR_MAGMA_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_512, GOST3410_2012_256}}, KE[72](GOST3410_2012_256){7DB049...50AB46}, NONCE[36]{9844D5...CC011F}, N[28](NAT_DETECTION_SOURCE_IP){000000...000000}, N[28](NAT_DETECTION_DESTINATION_IP){7D2124...4E6F10}, N[8](IKEV2_FRAGMENTATION_SUPPORTED), N[12](SIGNATURE_HASH_ALGORITHMS){STREEBOG_256, STREEBOG_512} (14) Sends message, peer receives message 10.111.10.171:54294->10.111.15.45:500 [264] 00000000: 92 80 e0 82 2e 75 87 78 00 00 00 00 00 00 00 00 00000010: 21 20 22 08 00 00 00 00 00 00 01 08 22 00 00 34 00000020: 00 00 00 30 01 01 00 05 03 00 00 08 01 00 00 20 00000030: 03 00 00 08 01 00 00 21 03 00 00 08 02 00 00 09 00000040: 03 00 00 08 04 00 00 22 00 00 00 08 04 00 00 21 00000050: 28 00 00 48 00 21 00 00 7d b0 49 81 88 6d 1b 02 00000060: b2 a6 35 c5 8b ea 90 8c 3e 16 de e5 43 13 22 0b 00000070: ad f5 89 9f 7f 85 54 2d 3e db 1e de 85 f7 d5 5d 00000080: 6f 83 c5 d0 31 bd 31 49 dd 29 c5 16 16 7d ec 86 00000090: 16 d8 85 e6 e4 50 ab 46 29 00 00 24 98 44 d5 40 000000A0: ef 89 46 f4 55 20 0a 55 73 dc ad 73 dd 2a 6f a8 000000B0: 31 f8 49 05 f5 8e 17 a2 6c cc 01 1f 29 00 00 1c 000000C0: 00 00 40 04 00 00 00 00 00 00 00 00 00 00 00 00 000000D0: 00 00 00 00 00 00 00 00 29 00 00 1c 00 00 40 05 000000E0: 7d 21 24 87 89 d7 95 71 bd a2 2d 22 9d 51 d0 71 000000F0: e9 4e 6f 10 29 00 00 08 00 00 40 2e 00 00 00 0c 00000100: 00 00 40 2f 00 06 00 07 Responder's actions: (15) Parses received message Smyslov Expires 9 June 2023 [Page 81] Internet-Draft GOST algorithms in IKEv2 December 2022 IKE SA Init 9280E0822E758778.0000000000000000.00000000 IKEv2 I->R[264] SA[52]{ P[48](#1:IKE::5#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, ENCR_MAGMA_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_512, GOST3410_2012_256}}, KE[72](GOST3410_2012_256){7DB049...50AB46}, NONCE[36]{9844D5...CC011F}, N[28](NAT_DETECTION_SOURCE_IP){000000...000000}, N[28](NAT_DETECTION_DESTINATION_IP){7D2124...4E6F10}, N[8](IKEV2_FRAGMENTATION_SUPPORTED), N[12](SIGNATURE_HASH_ALGORITHMS){STREEBOG_256, STREEBOG_512} (16) Generates random SPIr for IKE SA 00000000: db 57 8d 97 de 11 9d 1e (17) Generates random IKE nonce Nr 00000000: 6c de 24 c1 2c 0a 10 d5 c3 fe 55 e8 7e 90 30 66 00000010: ee 54 5b 24 1c 3c 01 dd b3 98 06 ae d3 b5 00 48 (18) Generates ephemeral private key 00000000: 46 fd 19 da 1c 77 e8 4c 12 69 cf c8 a2 2a 0b e9 00000010: 70 db c1 2c 9f 6d 88 0a 70 71 22 03 68 c6 fd 2d (19) Computes public key 00000000: 49 c2 40 f6 ac 35 f1 70 a7 c2 37 5e 9a 78 3c 09 00000010: 59 8d 55 3b 30 5b 64 58 db 2f 3c 36 f4 b1 db ad 00000020: ff c8 f4 b2 bd 14 cf 96 5b b2 d6 80 51 69 67 06 00000030: bd 16 39 0e 6d 07 83 e4 9d ed fd 04 f1 9e 07 a2 (20) Computes hash of CA public key 00000000: 5e 9e 50 5f 58 b0 a5 7a 33 45 83 49 66 0f 1c 3c 00000010: 7a 67 71 98 (21) Creates message Smyslov Expires 9 June 2023 [Page 82] Internet-Draft GOST algorithms in IKEv2 December 2022 IKE SA Init 9280E0822E758778.DB578D97DE119D1E.00000000 IKEv2 I<=R[273] SA[36]{ P[32](#1:IKE::3#){ Encryption=ENCR_MAGMA_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_256}}, KE[72](GOST3410_2012_256){49C240...9E07A2}, NONCE[36]{6CDE24...B50048}, N[28](NAT_DETECTION_SOURCE_IP){A4DCA3...2F5B3F}, N[28](NAT_DETECTION_DESTINATION_IP){BA7D7A...7AB7C9}, CERTREQ[25](X.509 Cert){5E9E50...677198}, N[8](IKEV2_FRAGMENTATION_SUPPORTED), N[12](SIGNATURE_HASH_ALGORITHMS){STREEBOG_256, STREEBOG_512} (22) Sends message, peer receives message 10.111.10.171:54294<-10.111.15.45:500 [273] 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 21 20 22 20 00 00 00 00 00 00 01 11 22 00 00 24 00000020: 00 00 00 20 01 01 00 03 03 00 00 08 01 00 00 21 00000030: 03 00 00 08 02 00 00 09 00 00 00 08 04 00 00 21 00000040: 28 00 00 48 00 21 00 00 49 c2 40 f6 ac 35 f1 70 00000050: a7 c2 37 5e 9a 78 3c 09 59 8d 55 3b 30 5b 64 58 00000060: db 2f 3c 36 f4 b1 db ad ff c8 f4 b2 bd 14 cf 96 00000070: 5b b2 d6 80 51 69 67 06 bd 16 39 0e 6d 07 83 e4 00000080: 9d ed fd 04 f1 9e 07 a2 29 00 00 24 6c de 24 c1 00000090: 2c 0a 10 d5 c3 fe 55 e8 7e 90 30 66 ee 54 5b 24 000000A0: 1c 3c 01 dd b3 98 06 ae d3 b5 00 48 29 00 00 1c 000000B0: 00 00 40 04 a4 dc a3 62 54 e8 4b 53 2b ff e7 d2 000000C0: 26 83 f3 8f 28 2f 5b 3f 26 00 00 1c 00 00 40 05 000000D0: ba 7d 7a b8 48 82 72 f6 30 91 b6 ae 2b dd fb 48 000000E0: ba 7a b7 c9 29 00 00 19 04 5e 9e 50 5f 58 b0 a5 000000F0: 7a 33 45 83 49 66 0f 1c 3c 7a 67 71 98 29 00 00 00000100: 08 00 00 40 2e 00 00 00 0c 00 00 40 2f 00 06 00 00000110: 07 Initiator's actions: (23) Parses received message Smyslov Expires 9 June 2023 [Page 83] Internet-Draft GOST algorithms in IKEv2 December 2022 IKE SA Init 9280E0822E758778.DB578D97DE119D1E.00000000 IKEv2 R=>I[273] SA[36]{ P[32](#1:IKE::3#){ Encryption=ENCR_MAGMA_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_256}}, KE[72](GOST3410_2012_256){49C240...9E07A2}, NONCE[36]{6CDE24...B50048}, N[28](NAT_DETECTION_SOURCE_IP){A4DCA3...2F5B3F}, N[28](NAT_DETECTION_DESTINATION_IP){BA7D7A...7AB7C9}, CERTREQ[25](X.509 Cert){5E9E50...677198}, N[8](IKEV2_FRAGMENTATION_SUPPORTED), N[12](SIGNATURE_HASH_ALGORITHMS){STREEBOG_256, STREEBOG_512} (24) Computes shared key 00000000: bd 04 9d 0f 9c 5f 58 af c7 e4 01 bc 18 59 01 7c 00000010: 88 28 f9 f2 9f 33 01 5d 49 9a 7d 14 74 d4 31 ac (25) Computes SKEYSEED 00000000: 9b ed 6c 79 64 b3 de 3a e4 9e dd 62 04 5a f0 8b 00000010: 43 88 33 d4 e6 9e 73 16 a1 1a 9e b2 b4 19 13 c5 00000020: d0 6d fb 86 40 11 c3 02 bb e5 a3 b5 e4 4a c4 c0 00000030: 9d 18 c6 94 de c3 c5 14 82 e7 a2 51 fe c4 98 ca (26) Computes SK_d 00000000: c2 21 15 fd d3 99 3b 2a 43 60 c4 59 34 b0 be 3f 00000010: 53 ef 6e b1 dd 88 ad 72 55 dd 83 22 5c 6f e1 d6 00000020: 1f 1e ab 06 f9 41 cb c8 ea f9 dc fc 19 a0 2d bf 00000030: 9a 0a 3f 3a 9a 45 1f 08 b6 a9 2c 62 52 b7 26 34 (27) Computes SK_ei 00000000: 18 4e 4e 0f 36 28 bf 3c 9c 04 8e 93 bf a0 77 53 00000010: 91 34 12 81 42 e6 4e 62 7f db a5 ed 98 60 50 ff 00000020: b4 e1 3e 23 (28) Computes SK_er 00000000: e9 27 59 2f 09 49 68 1e 0e 62 db c6 19 06 73 13 00000010: cf da 5c 02 27 3e 4a b4 78 98 b4 86 d0 e9 34 f4 00000020: a5 bb 18 2f (29) Computes SK_pi Smyslov Expires 9 June 2023 [Page 84] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 30 2c 10 8d 0f 61 47 00 f1 40 4f a9 4f af b5 30 00000010: 11 ba 5f 24 39 32 85 12 4e 7e 71 75 50 15 a6 93 00000020: c3 d0 5e 40 2e 21 8e b1 59 09 cd a4 eb b4 91 68 00000030: 29 42 fe e2 d8 76 8f a6 96 55 1f ab 6c 9b 00 f8 (30) Computes SK_pr 00000000: 6f 81 72 cb 96 58 fb 0e 17 70 b6 b9 1f a9 69 a9 00000010: fc c7 27 4f b4 e1 85 90 a0 c7 9f f9 72 11 61 2a 00000020: 35 b7 b7 96 d3 6a bb a5 aa b1 b8 34 8d 99 c6 f3 00000030: 2b fc 32 56 c1 94 71 04 55 bd 89 6a bf c3 8b fe (31) Computes prf(SK_pi, IDi) 00000000: ce e8 8b d1 7e 3c 83 32 eb d1 29 08 de dc 71 f4 00000010: 8f ba 09 b8 ca 5b 10 e2 f4 44 29 5c 97 7b 26 01 00000020: a4 ba 83 c8 ea 40 92 0f 88 18 bd e7 e1 c9 45 cf 00000030: ff 99 48 05 0d f4 93 a6 cd 54 46 d7 eb 7a 52 94 (32) Uses private key for signing (little endian) 00000000: 76 E9 DD B3 F3 A2 08 A2 4E A5 81 9C AE 41 DA B4 00000010: 77 3C 1D D5 DC EB AF E6 58 B1 47 D2 D8 29 CE 71 00000020: 18 A9 85 5D 28 5B 3C E3 23 BD 80 AC 2F 00 CC B6 00000030: 61 4C 42 A1 65 61 02 CF 33 EB 1F 5F 02 CE 8A B9 (33) Uses random number for signing 00000000: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00000010: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00000020: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00000030: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 (34) Computes signature using algorithm id-tc26-signwithdigest- gost3410-12-512 00000000: 6a 3e 59 0d 72 1e 55 a3 c0 d1 2f 8a 9b 4e 44 10 00000010: 58 59 bd 62 9e e7 12 31 e5 7d 01 53 f3 84 40 dd 00000020: ac 73 ed 09 3a 10 d9 6e 7f eb 80 6c 11 9e 91 f3 00000030: 7c 3c b0 55 f7 4b ec 0e 78 36 10 95 02 09 86 b3 00000040: 27 04 2a 83 3c 89 36 1b 73 cf 7b c9 e0 df a2 07 00000050: 12 1e 69 52 4d 89 1b de 6e 48 d1 34 fa 21 78 22 00000060: 88 2e 30 86 c0 80 0a 2d 74 af 08 ff 35 75 a5 79 00000070: e3 85 40 22 6b a8 42 f6 72 24 bf 29 87 58 a8 20 (35) Computes K1i (i1 = 0) Smyslov Expires 9 June 2023 [Page 85] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 3c 57 d7 c8 9f 50 98 fc 86 81 d6 8a 4e 5d 83 c6 00000010: 1e 42 e6 e7 60 67 05 8d f5 2e 10 13 12 15 32 58 (36) Computes K2i (i2 = 0) 00000000: 0b 88 0a 1b c8 3e 61 79 82 08 db 13 31 08 63 3c 00000010: 17 62 17 cb 7d 18 ce 70 37 84 85 f4 89 49 d0 06 (37) Computes K3i (i3 = 0) 00000000: 18 63 41 67 49 6e cf 48 56 71 4d aa 42 63 5c 11 00000010: 2e 26 5b e2 7b c7 53 a4 09 82 e5 5a 7e f4 65 4d (38) Selects SPI for incoming ESP SA 00000000: 6c 0c a5 70 (39) Computes hash of CA public key 00000000: 5e 9e 50 5f 58 b0 a5 7a 33 45 83 49 66 0f 1c 3c 00000010: 7a 67 71 98 (40) Creates message splitting it into 4 fragments IKE SA Auth #9280E0822E758778.DB578D97DE119D1E.00000001 IKEv2 R<-I[1847] E[1819]->4*EF[...]{ IDi[78](DN){CN=IKE Interop Test Client,O=ELVIS-PLUS,C=RU}, CERT[1280](X.509 Cert){308204...A6C40A}, CERTREQ[25](X.509 Cert){5E9E50...677198}, IDr[78](DN){CN=IKE Interop Test Server,O=ELVIS-PLUS,C=RU}, AUTH[149](Sig){id-tc26-signwithdigest-gost3410-12-512[12]: 6A3E59...58A820}, N[8](INITIAL_CONTACT), N[12](SET_WINDOW_SIZE){4}, CP[16](REQUEST){IP4.Address[0], IP4.DNS[0]}, SA[56]{ P[52](#1:ESP:6C0CA570:5#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, ENCR_MAGMA_MGM_KTREE, ENCR_KUZNYECHIK_MGM_MAC_KTREE, ENCR_MAGMA_MGM_MAC_KTREE, ESN=Off}}, TSi[40](2#){10.111.10.171:icmp:8.0, 0.0.0.0-255.255.255.255}, TSr[40](2#){10.0.0.2:icmp:8.0, 10.0.0.0-10.0.0.255}, N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} Smyslov Expires 9 June 2023 [Page 86] Internet-Draft GOST algorithms in IKEv2 December 2022 (41) Composes MGM nonce (fragment 1) 00000000: 00 00 00 00 b4 e1 3e 23 (42) Composes AAD (fragment 1) 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 08 00 00 00 01 00 00 02 20 23 00 02 04 00000020: 00 01 00 04 (43) Composes plaintext (fragment 1) 00000000: 25 00 00 4e 09 00 00 00 30 44 31 20 30 1e 06 03 00000010: 55 04 03 13 17 49 4b 45 20 49 6e 74 65 72 6f 70 00000020: 20 54 65 73 74 20 43 6c 69 65 6e 74 31 13 30 11 00000030: 06 03 55 04 0a 13 0a 45 4c 56 49 53 2d 50 4c 55 00000040: 53 31 0b 30 09 06 03 55 04 06 13 02 52 55 26 00 00000050: 05 00 04 30 82 04 f7 30 82 04 a4 a0 03 02 01 02 00000060: 02 13 7c 00 03 da a8 9e 1e ff 9e 79 05 fb bb 00 00000070: 01 00 03 da a8 30 0a 06 08 2a 85 03 07 01 01 03 00000080: 02 30 82 01 0a 31 18 30 16 06 05 2a 85 03 64 01 00000090: 12 0d 31 32 33 34 35 36 37 38 39 30 31 32 33 31 000000A0: 1a 30 18 06 08 2a 85 03 03 81 03 01 01 12 0c 30 000000B0: 30 31 32 33 34 35 36 37 38 39 30 31 2f 30 2d 06 000000C0: 03 55 04 09 0c 26 d1 83 d0 bb 2e 20 d0 a1 d1 83 000000D0: d1 89 d1 91 d0 b2 d1 81 d0 ba d0 b8 d0 b9 20 d0 000000E0: b2 d0 b0 d0 bb 20 d0 b4 2e 20 31 38 31 0b 30 09 000000F0: 06 03 55 04 06 13 02 52 55 31 19 30 17 06 03 55 00000100: 04 08 0c 10 d0 b3 2e 20 d0 9c d0 be d1 81 d0 ba 00000110: d0 b2 d0 b0 31 15 30 13 06 03 55 04 07 0c 0c d0 00000120: 9c d0 be d1 81 d0 ba d0 b2 d0 b0 31 25 30 23 06 00000130: 03 55 04 0a 0c 1c d0 9e d0 9e d0 9e 20 22 d0 9a 00000140: d0 a0 d0 98 d0 9f d0 a2 d0 9e 2d d0 9f d0 a0 d0 00000150: 9e 22 31 3b 30 39 06 03 55 04 03 0c 32 d0 a2 d0 00000160: b5 d1 81 d1 82 d0 be d0 b2 d1 8b d0 b9 20 d0 a3 00000170: d0 a6 20 d0 9e d0 9e d0 9e 20 22 d0 9a d0 a0 d0 00000180: 98 d0 9f d0 a2 d0 9e 2d d0 9f d0 a0 d0 9e 22 30 00000190: 1e 17 0d 32 31 31 30 30 31 30 36 31 30 31 30 5a 000001A0: 17 0d 32 32 30 31 30 31 30 36 32 30 31 30 5a 30 000001B0: 44 31 20 30 1e 06 03 55 04 03 13 17 49 4b 45 20 000001C0: 49 6e 74 65 72 6f 70 20 54 65 73 74 20 43 6c 69 000001D0: 65 6e 74 31 13 30 11 06 03 55 04 0a 13 0a 45 4c 000001E0: 56 49 53 2d 50 4c 55 53 31 0b 30 00 (44) Encrypts plaintext using K3i as K_msg, resulted in ciphertext (fragment 1) Smyslov Expires 9 June 2023 [Page 87] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 03 45 60 11 15 25 f5 45 bb 0e f4 25 26 e2 14 8c 00000010: a7 01 82 f6 9c 6e 42 f1 a3 9b 9e ac a6 dd 0d 9c 00000020: ff 79 15 ed b9 0c 81 a0 b4 29 61 fb 55 1b c1 73 00000030: 4d de 1f b2 5f 1f cb 84 5d 12 24 85 52 c4 f2 1d 00000040: 01 a7 92 ad 55 4d 90 d0 58 d2 1a 5e f6 dc 4e 73 00000050: d4 9b 08 66 d7 64 de 10 e6 75 69 20 e3 7b 6c f0 00000060: 4b 8b ff 60 39 f1 19 31 72 dd c1 09 33 5b 1d 56 00000070: ee 0c 1c 42 d7 f3 04 d3 5b 9a 6e cf 7f b3 1f ac 00000080: 34 a6 ee e0 ac 87 b8 88 99 75 a6 ae dc b5 30 38 00000090: eb 3d 48 fd cc 69 64 f8 c6 61 ce e9 e1 24 ba aa 000000A0: 25 5e e6 ea 8b 0c ef 20 31 bf a9 ae 6d e2 82 d4 000000B0: ab 2c d7 af ca 62 fe bd 7c 8f a9 dc d3 63 05 d7 000000C0: ba 92 56 66 44 ad 5d 9d 1e 9a 27 2e 22 6e 5b 0c 000000D0: af 84 6b c6 a7 cf ca 72 f8 8e d3 a1 bc d4 7c 5b 000000E0: 7e 26 7f b3 05 d8 62 ef ad d6 07 70 d7 4b 33 e4 000000F0: 26 84 e6 eb 5b 65 5c a7 71 29 45 15 d9 b0 83 6a 00000100: 52 5f a9 d8 dd f1 d8 62 c7 d7 3d e9 69 0e c5 b1 00000110: e1 de 20 6c 3d 5f f7 f7 9f f6 a5 7b 4d a5 4e e9 00000120: b4 c4 c2 7d cc 43 62 77 57 37 d3 40 48 b2 c0 5b 00000130: 48 ab d0 94 79 ef 3d 04 e3 d8 6d 42 56 ed cd 94 00000140: b4 23 2c fa f0 6b 39 ad 41 a3 b3 8f ec b8 6c ef 00000150: e1 98 3a b2 fb a8 fd 21 96 8a bf 3a 65 47 8a e9 00000160: 69 60 44 02 2c ec 7a 86 74 fe 1d 9b 08 5e b8 5e 00000170: f8 ca 37 20 5f a7 74 8c 12 88 f2 d8 9e d4 94 29 00000180: c2 db f9 fb 35 a0 cf 21 2b da 8b 9e cc 52 84 eb 00000190: c4 12 39 3e e6 18 fb f7 57 6c b5 1e 10 3d 11 9c 000001A0: 29 9c 41 73 69 d8 d0 9d 71 2b 77 66 87 65 51 19 000001B0: db 27 a0 dd aa 64 ba fd c0 5f e1 4e da 7c 20 fc 000001C0: 8c 13 ab 2d c2 9c 37 9d 7e 51 cb 29 03 10 52 dc 000001D0: f8 09 61 cc 12 9a a0 8e 1b e4 52 f8 72 bd 7a 86 000001E0: db 93 7c 55 b8 1e 7f 21 d4 e6 02 f2 (45) Computes ICV using K3i as K_msg (fragment 1) 00000000: b1 51 cd e6 dc 64 12 1c (46) Composes IV (fragment 1) 00000000: 00 00 00 00 00 00 00 00 (47) Composes MGM nonce (fragment 2) 00000000: 00 00 00 01 b4 e1 3e 23 (48) Composes AAD (fragment 2) Smyslov Expires 9 June 2023 [Page 88] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 08 00 00 00 01 00 00 02 20 00 00 02 04 00000020: 00 02 00 04 (49) Composes plaintext (fragment 2) 00000000: 09 06 03 55 04 06 13 02 52 55 30 81 aa 30 21 06 00000010: 08 2a 85 03 07 01 01 01 02 30 15 06 09 2a 85 03 00000020: 07 01 02 01 02 01 06 08 2a 85 03 07 01 01 02 03 00000030: 03 81 84 00 04 81 80 ee 2f 0a 0e 09 1e 7e 04 ef 00000040: ba 5b 62 a2 52 86 e1 9c 24 50 30 50 b0 b4 8a 37 00000050: 35 b5 fc af 28 94 ec b5 9b 92 41 5b 69 e2 c9 ba 00000060: 24 de 6a 72 c4 ef 44 bb 89 a1 05 14 1b 87 3d 6a 00000070: a3 72 3e 17 ca 7f 39 28 ce 16 8b dd 07 52 87 6a 00000080: 0d 77 42 6d 99 2b 46 2c fd 4b b2 7c d7 c7 17 08 00000090: 12 54 63 47 9d 14 3d 61 ed f2 95 ab 11 80 69 02 000000A0: a7 66 60 50 7e a4 53 6d ad 01 49 b2 16 8a 95 1d 000000B0: cf 1a 57 93 56 14 5e a3 82 02 59 30 82 02 55 30 000000C0: 0e 06 03 55 1d 0f 01 01 ff 04 04 03 02 05 a0 30 000000D0: 13 06 03 55 1d 25 04 0c 30 0a 06 08 2b 06 01 05 000000E0: 05 07 03 11 30 1d 06 03 55 1d 0e 04 16 04 14 40 000000F0: 81 b1 d1 18 75 f0 da 6b 3c 50 5f cd 73 1d d9 77 00000100: f2 d7 c1 30 1f 06 03 55 1d 23 04 18 30 16 80 14 00000110: 9b 85 5e fb 81 dc 4d 59 07 51 63 cf be df da 2c 00000120: 7f c9 44 3c 30 82 01 0f 06 03 55 1d 1f 04 82 01 00000130: 06 30 82 01 02 30 81 ff a0 81 fc a0 81 f9 86 81 00000140: b5 68 74 74 70 3a 2f 2f 74 65 73 74 67 6f 73 74 00000150: 32 30 31 32 2e 63 72 79 70 74 6f 70 72 6f 2e 72 00000160: 75 2f 43 65 72 74 45 6e 72 6f 6c 6c 2f 21 30 34 00000170: 32 32 21 30 34 33 35 21 30 34 34 31 21 30 34 34 00000180: 32 21 30 34 33 65 21 30 34 33 32 21 30 34 34 62 00000190: 21 30 34 33 39 25 32 30 21 30 34 32 33 21 30 34 000001A0: 32 36 25 32 30 21 30 34 31 65 21 30 34 31 65 21 000001B0: 30 34 31 65 25 32 30 21 30 30 32 32 21 30 34 31 000001C0: 61 21 30 34 32 30 21 30 34 31 38 21 30 34 31 66 000001D0: 21 30 34 32 32 21 30 34 31 65 2d 21 30 34 31 66 000001E0: 21 30 34 32 30 21 30 34 31 65 21 00 (50) Encrypts plaintext using K3i as K_msg, resulted in ciphertext (fragment 2) Smyslov Expires 9 June 2023 [Page 89] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 3c b1 b4 aa 04 56 27 1b 45 04 f7 70 1b 17 16 16 00000010: 85 16 ee b3 88 7d 08 64 2d 24 b8 1d 7e ac c9 72 00000020: 73 07 d3 d9 ef 5d 08 8b 47 97 5a 98 53 00 ec 13 00000030: cc 5a 46 7b 16 a2 14 6a f1 ea 17 71 9b 75 1d 46 00000040: 9d 6d 8c 3a a2 b2 75 c5 c9 4c 16 56 73 03 16 40 00000050: 42 fe a2 5a cc c7 ed 37 91 b1 eb e5 56 2a 01 bc 00000060: a2 83 ac 05 f1 a7 56 e5 f2 bb f4 18 7f 05 82 14 00000070: 70 de af 44 d4 cc a9 0a 95 6d c1 96 11 3d cf e1 00000080: aa 27 f1 87 60 d2 32 c1 1e 91 bf 60 00 5f d3 fb 00000090: a4 55 2e f0 0b 08 14 ed a3 63 54 4c b8 7b 5c 71 000000A0: 69 d1 3b 0c 6c 93 f3 99 2e fe 36 98 90 a1 05 ee 000000B0: 35 d2 da f8 81 59 f5 17 23 33 40 99 99 42 37 b0 000000C0: 0d 94 0a bd 00 cf 1c be 0e d0 13 93 e2 27 5a a5 000000D0: c5 e8 a0 25 5a 2d ad 6c b4 bc 64 37 05 ac cd 22 000000E0: 92 13 83 ab e8 87 93 29 82 dc 47 b4 1c 92 4d 36 000000F0: ef ba 10 3d 42 2d d6 2c d5 6b 95 99 2d 17 61 c4 00000100: c5 13 ed 55 a5 e5 b2 65 ac 25 24 21 c4 25 7f 6f 00000110: 68 fb ce 8f 17 60 e9 ac 9c 52 9f d5 d4 a7 14 35 00000120: 89 a4 1f de 21 a9 51 3c 1d 73 00 10 ba a6 7c 24 00000130: fb b9 20 21 5e df 63 8a c8 1f b1 55 05 5a 70 a8 00000140: b5 f4 23 9e 22 c0 2a 7c a5 11 01 c3 5e 3d 52 2a 00000150: b8 1d c5 19 b5 55 cc 8e f0 8d 6e 93 36 10 cd e3 00000160: c8 a5 a6 2e 90 53 fa 92 64 16 6c 4f da 9b e5 f8 00000170: 91 c5 ea b4 60 64 db ed d5 bc fc 3a 73 62 ce b2 00000180: ff 7a 15 95 0d 77 00 ee 5c a8 c5 89 2f 39 13 59 00000190: dd 52 ea 11 ae 28 82 36 be aa 29 68 4c f6 63 d5 000001A0: 93 a5 54 3d 8f 13 26 0a 87 34 b9 81 1c 2c cd d5 000001B0: 79 3a 65 6d 1c 6e 32 be b0 77 b7 b3 e4 ae b8 72 000001C0: f9 44 59 e9 14 46 67 56 93 ca 70 d1 ac 25 05 62 000001D0: f7 55 c2 9e 2e 11 a7 29 01 24 77 4a 6f 1c ba f6 000001E0: 4a 4f 83 75 29 1e c7 a9 68 29 02 d0 (51) Computes ICV using K3i as K_msg (fragment 2) 00000000: b4 68 c7 4d eb dd bd 92 (52) Composes IV (fragment 2) 00000000: 00 00 00 00 00 00 00 01 (53) Composes MGM nonce (fragment 3) 00000000: 00 00 00 02 b4 e1 3e 23 (54) Composes AAD (fragment 3) Smyslov Expires 9 June 2023 [Page 90] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 08 00 00 00 01 00 00 02 20 00 00 02 04 00000020: 00 03 00 04 (55) Composes plaintext (fragment 3) 00000000: 30 30 32 32 28 31 29 2e 63 72 6c 86 3f 68 74 74 00000010: 70 3a 2f 2f 74 65 73 74 67 6f 73 74 32 30 31 32 00000020: 2e 63 72 79 70 74 6f 70 72 6f 2e 72 75 2f 43 65 00000030: 72 74 45 6e 72 6f 6c 6c 2f 74 65 73 74 67 6f 73 00000040: 74 32 30 31 32 28 31 29 2e 63 72 6c 30 81 da 06 00000050: 08 2b 06 01 05 05 07 01 01 04 81 cd 30 81 ca 30 00000060: 44 06 08 2b 06 01 05 05 07 30 02 86 38 68 74 74 00000070: 70 3a 2f 2f 74 65 73 74 67 6f 73 74 32 30 31 32 00000080: 2e 63 72 79 70 74 6f 70 72 6f 2e 72 75 2f 43 65 00000090: 72 74 45 6e 72 6f 6c 6c 2f 72 6f 6f 74 32 30 31 000000A0: 38 2e 63 72 74 30 3f 06 08 2b 06 01 05 05 07 30 000000B0: 01 86 33 68 74 74 70 3a 2f 2f 74 65 73 74 67 6f 000000C0: 73 74 32 30 31 32 2e 63 72 79 70 74 6f 70 72 6f 000000D0: 2e 72 75 2f 6f 63 73 70 32 30 31 32 67 2f 6f 63 000000E0: 73 70 2e 73 72 66 30 41 06 08 2b 06 01 05 05 07 000000F0: 30 01 86 35 68 74 74 70 3a 2f 2f 74 65 73 74 67 00000100: 6f 73 74 32 30 31 32 2e 63 72 79 70 74 6f 70 72 00000110: 6f 2e 72 75 2f 6f 63 73 70 32 30 31 32 67 73 74 00000120: 2f 6f 63 73 70 2e 73 72 66 30 0a 06 08 2a 85 03 00000130: 07 01 01 03 02 03 41 00 21 ee 3b e1 fd 0f 36 90 00000140: 92 c4 a2 35 26 e8 dc 4e b8 ef 89 40 70 d2 91 39 00000150: bc 79 a6 e2 f7 c1 06 bd d5 d6 ff 72 a5 6c f2 c0 00000160: c3 75 e9 ca 67 81 c1 93 96 b4 bd 18 12 4c 37 f7 00000170: d9 73 d6 4c 8a a6 c4 0a 24 00 00 19 04 5e 9e 50 00000180: 5f 58 b0 a5 7a 33 45 83 49 66 0f 1c 3c 7a 67 71 00000190: 98 27 00 00 4e 09 00 00 00 30 44 31 20 30 1e 06 000001A0: 03 55 04 03 13 17 49 4b 45 20 49 6e 74 65 72 6f 000001B0: 70 20 54 65 73 74 20 53 65 72 76 65 72 31 13 30 000001C0: 11 06 03 55 04 0a 13 0a 45 4c 56 49 53 2d 50 4c 000001D0: 55 53 31 0b 30 09 06 03 55 04 06 13 02 52 55 29 000001E0: 00 00 95 0e 00 00 00 0c 30 0a 06 00 (56) Encrypts plaintext using K3i as K_msg, resulted in ciphertext (fragment 3) Smyslov Expires 9 June 2023 [Page 91] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: e7 72 d9 51 90 b1 a2 bc 81 8d d6 56 bf 7a 81 e0 00000010: 1a a1 70 8b 35 a0 7e 5f e8 df 58 3d 75 5d d2 4c 00000020: 4c ce 17 77 3f 28 9c ca 7a a4 23 23 f0 c7 ff ff 00000030: 98 ee e3 1a 27 39 4d 90 1a b7 5b 44 11 16 11 3a 00000040: ea bf 83 66 da 92 2a 3a 3d bd b5 40 c8 bc f6 ed 00000050: cb 1d 5a 8e 30 f0 06 72 dc 6c da c1 45 7b e8 25 00000060: ca 93 2a b2 fe 4a db 00 90 e3 31 78 26 8d ae c8 00000070: 39 66 80 7d e5 01 5f 21 d6 c3 40 46 19 e4 43 9d 00000080: 23 c6 c1 18 06 49 bd f5 dc 8c 1b 19 b0 60 0c a3 00000090: ad f5 5c 57 e8 8e 37 e6 ea b6 79 11 b8 f1 16 ba 000000A0: a6 d9 09 1f 0d e0 3c 07 b8 ce 9d 11 a3 c6 f7 e4 000000B0: 62 e8 94 7b ad b9 8a 6b 9c f1 f8 43 cf 7e fc 5e 000000C0: 44 ab bf b1 88 f5 67 1e 84 5f 82 63 f3 13 89 55 000000D0: f5 ef 86 c3 db 48 37 f8 26 3c c4 6d a5 fc b5 69 000000E0: 56 0d 2d f3 c0 98 dd e7 53 da 0a 28 87 2f 38 ab 000000F0: a9 ec 60 a6 c4 54 c6 68 e7 6b e3 4b 54 bf b5 82 00000100: 44 c9 b9 45 bc 9e f5 58 d8 76 63 92 cd 52 ec 82 00000110: 80 d6 43 86 10 16 eb 7b 32 e4 ee ba ec 09 b6 4f 00000120: 35 1a bf da d7 de 40 fa b5 d2 40 f2 73 09 2d 52 00000130: 83 bd 56 a6 6b d3 9f 8a c2 c5 66 c6 6b 22 fb 6a 00000140: 00 b2 8a ac 9d 8b fc 8d 41 af 80 92 16 51 e2 cb 00000150: 89 62 9b 77 2b 1e 38 01 df fc 1f 81 2d 95 8b 9e 00000160: 1d 1e ad 9c c0 0d fc 77 6e 35 13 16 26 28 1a 29 00000170: 19 7f f8 08 5a 0f 09 4f 6f ba 7f 4c 5b cd 0c c2 00000180: 71 ab ea 82 a2 d2 d1 1b 17 fd dc c3 54 03 85 14 00000190: f4 90 47 2e 67 d7 93 c3 67 7e 8a f7 43 1a b3 41 000001A0: 32 f7 b0 58 38 6e 24 c8 96 d9 94 d3 54 89 2d 61 000001B0: 10 a9 9c 22 51 52 02 c9 b7 8d cc 5b 28 6d cb 55 000001C0: 5d 2f 97 8a 8f 3f 27 56 73 eb ec 5d e4 64 91 49 000001D0: 3b 88 f2 0a fc ed a5 67 a9 e3 71 ef 31 ce a0 33 000001E0: fc d8 ea 4d 1e 3f dc 89 c8 89 e2 c3 (57) Computes ICV using K3i as K_msg (fragment 3) 00000000: 54 4f 9b aa dd af bd ca (58) Composes IV (fragment 3) 00000000: 00 00 00 00 00 00 00 02 (59) Composes MGM nonce (fragment 4) 00000000: 00 00 00 03 b4 e1 3e 23 (60) Composes AAD (fragment 4) Smyslov Expires 9 June 2023 [Page 92] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 08 00 00 00 01 00 00 01 7a 00 00 01 5e 00000020: 00 04 00 04 (61) Composes plaintext (fragment 4) 00000000: 08 2a 85 03 07 01 01 03 03 6a 3e 59 0d 72 1e 55 00000010: a3 c0 d1 2f 8a 9b 4e 44 10 58 59 bd 62 9e e7 12 00000020: 31 e5 7d 01 53 f3 84 40 dd ac 73 ed 09 3a 10 d9 00000030: 6e 7f eb 80 6c 11 9e 91 f3 7c 3c b0 55 f7 4b ec 00000040: 0e 78 36 10 95 02 09 86 b3 27 04 2a 83 3c 89 36 00000050: 1b 73 cf 7b c9 e0 df a2 07 12 1e 69 52 4d 89 1b 00000060: de 6e 48 d1 34 fa 21 78 22 88 2e 30 86 c0 80 0a 00000070: 2d 74 af 08 ff 35 75 a5 79 e3 85 40 22 6b a8 42 00000080: f6 72 24 bf 29 87 58 a8 20 29 00 00 08 00 00 40 00000090: 00 2f 00 00 0c 00 00 40 01 00 00 00 04 21 00 00 000000A0: 10 01 00 00 00 00 01 00 00 00 03 00 00 2c 00 00 000000B0: 38 00 00 00 34 01 03 04 05 6c 0c a5 70 03 00 00 000000C0: 08 01 00 00 20 03 00 00 08 01 00 00 21 03 00 00 000000D0: 08 01 00 00 22 03 00 00 08 01 00 00 23 00 00 00 000000E0: 08 05 00 00 00 2d 00 00 28 02 00 00 00 07 01 00 000000F0: 10 08 00 08 00 0a 6f 0a ab 0a 6f 0a ab 07 00 00 00000100: 10 00 00 ff ff 00 00 00 00 ff ff ff ff 29 00 00 00000110: 28 02 00 00 00 07 01 00 10 08 00 08 00 0a 00 00 00000120: 02 0a 00 00 02 07 00 00 10 00 00 ff ff 0a 00 00 00000130: 00 0a 00 00 ff 29 00 00 08 00 00 40 0a 00 00 00 00000140: 08 00 00 40 0b 00 (62) Encrypts plaintext using K3i as K_msg, resulted in ciphertext (fragment 4) Smyslov Expires 9 June 2023 [Page 93] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: e0 8a 0b 04 ee f8 47 c2 52 96 71 9f 9d 39 0c 91 00000010: ea 6a 16 7c 80 31 a0 fd 76 cc c4 f1 8f 1a d3 be 00000020: fa 78 6b df c1 c6 73 83 be 36 69 c4 8a 87 ed 11 00000030: 90 31 a8 fd f9 0a 5c e4 d4 23 c9 e6 b3 96 ac b6 00000040: 8e bd fc 27 58 79 9f cc 8b ac 6b 59 e4 70 4b 05 00000050: 23 16 ed 49 25 f3 de 02 2e ce ae 86 e8 b4 ca b4 00000060: 96 ad 5b f6 2b c2 47 33 6f da f3 97 3c 13 ed 1f 00000070: 7a da 93 b5 69 6a b5 10 93 38 75 ea b7 34 a3 87 00000080: b6 83 c7 da 8a a1 d9 2a 0b 22 e2 ab 63 2b 57 2b 00000090: 88 e3 ea be 7b fc dc 26 ac b8 bb 15 96 f9 c2 f4 000000A0: 60 17 e4 09 18 ae 78 b8 73 02 6b 0e 20 cc b1 cd 000000B0: b4 4d 94 7f f3 16 28 9a d2 bd 26 77 4b a5 85 56 000000C0: b1 81 8b 9c c3 0a 7f 67 fe 6a 61 15 f1 45 66 f3 000000D0: 36 fc a5 bb 1f d7 6d e7 1d 9f 3f b5 cc 60 19 48 000000E0: 17 f7 08 28 1c 58 9f 2b 7a 0b b9 50 bd 02 ea b8 000000F0: 1e 03 1f 52 6a 7a fc e5 b4 6b 00 cf 0d 83 1f d2 00000100: 3f f2 ad 43 d4 86 6e c1 88 d2 87 d6 1f ac a3 30 00000110: 7b c1 5b 6a 3d 4c 20 72 5d 2c ca bf 87 a2 ce 1d 00000120: b3 fa c7 7c 22 cd 66 fc be 49 22 32 17 ee 6e 5e 00000130: 62 c1 ca 12 2b 5d 3d 7b ae b5 3e 53 c5 98 05 1f 00000140: 42 53 49 d1 2c c2 (63) Computes ICV using K3i as K_msg (fragment 4) 00000000: d2 25 f1 d0 38 65 b7 b6 (64) Composes IV (fragment 4) 00000000: 00 00 00 00 00 00 00 03 (65) Sends message fragment (1) , peer receives message fragment (1) Smyslov Expires 9 June 2023 [Page 94] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54295->10.111.15.45:4500 [548] 00000000: 00 00 00 00 92 80 e0 82 2e 75 87 78 db 57 8d 97 00000010: de 11 9d 1e 35 20 23 08 00 00 00 01 00 00 02 20 00000020: 23 00 02 04 00 01 00 04 00 00 00 00 00 00 00 00 00000030: 03 45 60 11 15 25 f5 45 bb 0e f4 25 26 e2 14 8c 00000040: a7 01 82 f6 9c 6e 42 f1 a3 9b 9e ac a6 dd 0d 9c 00000050: ff 79 15 ed b9 0c 81 a0 b4 29 61 fb 55 1b c1 73 00000060: 4d de 1f b2 5f 1f cb 84 5d 12 24 85 52 c4 f2 1d 00000070: 01 a7 92 ad 55 4d 90 d0 58 d2 1a 5e f6 dc 4e 73 00000080: d4 9b 08 66 d7 64 de 10 e6 75 69 20 e3 7b 6c f0 00000090: 4b 8b ff 60 39 f1 19 31 72 dd c1 09 33 5b 1d 56 000000A0: ee 0c 1c 42 d7 f3 04 d3 5b 9a 6e cf 7f b3 1f ac 000000B0: 34 a6 ee e0 ac 87 b8 88 99 75 a6 ae dc b5 30 38 000000C0: eb 3d 48 fd cc 69 64 f8 c6 61 ce e9 e1 24 ba aa 000000D0: 25 5e e6 ea 8b 0c ef 20 31 bf a9 ae 6d e2 82 d4 000000E0: ab 2c d7 af ca 62 fe bd 7c 8f a9 dc d3 63 05 d7 000000F0: ba 92 56 66 44 ad 5d 9d 1e 9a 27 2e 22 6e 5b 0c 00000100: af 84 6b c6 a7 cf ca 72 f8 8e d3 a1 bc d4 7c 5b 00000110: 7e 26 7f b3 05 d8 62 ef ad d6 07 70 d7 4b 33 e4 00000120: 26 84 e6 eb 5b 65 5c a7 71 29 45 15 d9 b0 83 6a 00000130: 52 5f a9 d8 dd f1 d8 62 c7 d7 3d e9 69 0e c5 b1 00000140: e1 de 20 6c 3d 5f f7 f7 9f f6 a5 7b 4d a5 4e e9 00000150: b4 c4 c2 7d cc 43 62 77 57 37 d3 40 48 b2 c0 5b 00000160: 48 ab d0 94 79 ef 3d 04 e3 d8 6d 42 56 ed cd 94 00000170: b4 23 2c fa f0 6b 39 ad 41 a3 b3 8f ec b8 6c ef 00000180: e1 98 3a b2 fb a8 fd 21 96 8a bf 3a 65 47 8a e9 00000190: 69 60 44 02 2c ec 7a 86 74 fe 1d 9b 08 5e b8 5e 000001A0: f8 ca 37 20 5f a7 74 8c 12 88 f2 d8 9e d4 94 29 000001B0: c2 db f9 fb 35 a0 cf 21 2b da 8b 9e cc 52 84 eb 000001C0: c4 12 39 3e e6 18 fb f7 57 6c b5 1e 10 3d 11 9c 000001D0: 29 9c 41 73 69 d8 d0 9d 71 2b 77 66 87 65 51 19 000001E0: db 27 a0 dd aa 64 ba fd c0 5f e1 4e da 7c 20 fc 000001F0: 8c 13 ab 2d c2 9c 37 9d 7e 51 cb 29 03 10 52 dc 00000200: f8 09 61 cc 12 9a a0 8e 1b e4 52 f8 72 bd 7a 86 00000210: db 93 7c 55 b8 1e 7f 21 d4 e6 02 f2 b1 51 cd e6 00000220: dc 64 12 1c (66) Sends message fragment (2) , peer receives message fragment (2) Smyslov Expires 9 June 2023 [Page 95] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54295->10.111.15.45:4500 [548] 00000000: 00 00 00 00 92 80 e0 82 2e 75 87 78 db 57 8d 97 00000010: de 11 9d 1e 35 20 23 08 00 00 00 01 00 00 02 20 00000020: 00 00 02 04 00 02 00 04 00 00 00 00 00 00 00 01 00000030: 3c b1 b4 aa 04 56 27 1b 45 04 f7 70 1b 17 16 16 00000040: 85 16 ee b3 88 7d 08 64 2d 24 b8 1d 7e ac c9 72 00000050: 73 07 d3 d9 ef 5d 08 8b 47 97 5a 98 53 00 ec 13 00000060: cc 5a 46 7b 16 a2 14 6a f1 ea 17 71 9b 75 1d 46 00000070: 9d 6d 8c 3a a2 b2 75 c5 c9 4c 16 56 73 03 16 40 00000080: 42 fe a2 5a cc c7 ed 37 91 b1 eb e5 56 2a 01 bc 00000090: a2 83 ac 05 f1 a7 56 e5 f2 bb f4 18 7f 05 82 14 000000A0: 70 de af 44 d4 cc a9 0a 95 6d c1 96 11 3d cf e1 000000B0: aa 27 f1 87 60 d2 32 c1 1e 91 bf 60 00 5f d3 fb 000000C0: a4 55 2e f0 0b 08 14 ed a3 63 54 4c b8 7b 5c 71 000000D0: 69 d1 3b 0c 6c 93 f3 99 2e fe 36 98 90 a1 05 ee 000000E0: 35 d2 da f8 81 59 f5 17 23 33 40 99 99 42 37 b0 000000F0: 0d 94 0a bd 00 cf 1c be 0e d0 13 93 e2 27 5a a5 00000100: c5 e8 a0 25 5a 2d ad 6c b4 bc 64 37 05 ac cd 22 00000110: 92 13 83 ab e8 87 93 29 82 dc 47 b4 1c 92 4d 36 00000120: ef ba 10 3d 42 2d d6 2c d5 6b 95 99 2d 17 61 c4 00000130: c5 13 ed 55 a5 e5 b2 65 ac 25 24 21 c4 25 7f 6f 00000140: 68 fb ce 8f 17 60 e9 ac 9c 52 9f d5 d4 a7 14 35 00000150: 89 a4 1f de 21 a9 51 3c 1d 73 00 10 ba a6 7c 24 00000160: fb b9 20 21 5e df 63 8a c8 1f b1 55 05 5a 70 a8 00000170: b5 f4 23 9e 22 c0 2a 7c a5 11 01 c3 5e 3d 52 2a 00000180: b8 1d c5 19 b5 55 cc 8e f0 8d 6e 93 36 10 cd e3 00000190: c8 a5 a6 2e 90 53 fa 92 64 16 6c 4f da 9b e5 f8 000001A0: 91 c5 ea b4 60 64 db ed d5 bc fc 3a 73 62 ce b2 000001B0: ff 7a 15 95 0d 77 00 ee 5c a8 c5 89 2f 39 13 59 000001C0: dd 52 ea 11 ae 28 82 36 be aa 29 68 4c f6 63 d5 000001D0: 93 a5 54 3d 8f 13 26 0a 87 34 b9 81 1c 2c cd d5 000001E0: 79 3a 65 6d 1c 6e 32 be b0 77 b7 b3 e4 ae b8 72 000001F0: f9 44 59 e9 14 46 67 56 93 ca 70 d1 ac 25 05 62 00000200: f7 55 c2 9e 2e 11 a7 29 01 24 77 4a 6f 1c ba f6 00000210: 4a 4f 83 75 29 1e c7 a9 68 29 02 d0 b4 68 c7 4d 00000220: eb dd bd 92 (67) Sends message fragment (3) , peer receives message fragment (3) Smyslov Expires 9 June 2023 [Page 96] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54295->10.111.15.45:4500 [548] 00000000: 00 00 00 00 92 80 e0 82 2e 75 87 78 db 57 8d 97 00000010: de 11 9d 1e 35 20 23 08 00 00 00 01 00 00 02 20 00000020: 00 00 02 04 00 03 00 04 00 00 00 00 00 00 00 02 00000030: e7 72 d9 51 90 b1 a2 bc 81 8d d6 56 bf 7a 81 e0 00000040: 1a a1 70 8b 35 a0 7e 5f e8 df 58 3d 75 5d d2 4c 00000050: 4c ce 17 77 3f 28 9c ca 7a a4 23 23 f0 c7 ff ff 00000060: 98 ee e3 1a 27 39 4d 90 1a b7 5b 44 11 16 11 3a 00000070: ea bf 83 66 da 92 2a 3a 3d bd b5 40 c8 bc f6 ed 00000080: cb 1d 5a 8e 30 f0 06 72 dc 6c da c1 45 7b e8 25 00000090: ca 93 2a b2 fe 4a db 00 90 e3 31 78 26 8d ae c8 000000A0: 39 66 80 7d e5 01 5f 21 d6 c3 40 46 19 e4 43 9d 000000B0: 23 c6 c1 18 06 49 bd f5 dc 8c 1b 19 b0 60 0c a3 000000C0: ad f5 5c 57 e8 8e 37 e6 ea b6 79 11 b8 f1 16 ba 000000D0: a6 d9 09 1f 0d e0 3c 07 b8 ce 9d 11 a3 c6 f7 e4 000000E0: 62 e8 94 7b ad b9 8a 6b 9c f1 f8 43 cf 7e fc 5e 000000F0: 44 ab bf b1 88 f5 67 1e 84 5f 82 63 f3 13 89 55 00000100: f5 ef 86 c3 db 48 37 f8 26 3c c4 6d a5 fc b5 69 00000110: 56 0d 2d f3 c0 98 dd e7 53 da 0a 28 87 2f 38 ab 00000120: a9 ec 60 a6 c4 54 c6 68 e7 6b e3 4b 54 bf b5 82 00000130: 44 c9 b9 45 bc 9e f5 58 d8 76 63 92 cd 52 ec 82 00000140: 80 d6 43 86 10 16 eb 7b 32 e4 ee ba ec 09 b6 4f 00000150: 35 1a bf da d7 de 40 fa b5 d2 40 f2 73 09 2d 52 00000160: 83 bd 56 a6 6b d3 9f 8a c2 c5 66 c6 6b 22 fb 6a 00000170: 00 b2 8a ac 9d 8b fc 8d 41 af 80 92 16 51 e2 cb 00000180: 89 62 9b 77 2b 1e 38 01 df fc 1f 81 2d 95 8b 9e 00000190: 1d 1e ad 9c c0 0d fc 77 6e 35 13 16 26 28 1a 29 000001A0: 19 7f f8 08 5a 0f 09 4f 6f ba 7f 4c 5b cd 0c c2 000001B0: 71 ab ea 82 a2 d2 d1 1b 17 fd dc c3 54 03 85 14 000001C0: f4 90 47 2e 67 d7 93 c3 67 7e 8a f7 43 1a b3 41 000001D0: 32 f7 b0 58 38 6e 24 c8 96 d9 94 d3 54 89 2d 61 000001E0: 10 a9 9c 22 51 52 02 c9 b7 8d cc 5b 28 6d cb 55 000001F0: 5d 2f 97 8a 8f 3f 27 56 73 eb ec 5d e4 64 91 49 00000200: 3b 88 f2 0a fc ed a5 67 a9 e3 71 ef 31 ce a0 33 00000210: fc d8 ea 4d 1e 3f dc 89 c8 89 e2 c3 54 4f 9b aa 00000220: dd af bd ca (68) Sends message fragment (4) , peer receives message fragment (4) Smyslov Expires 9 June 2023 [Page 97] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54295->10.111.15.45:4500 [382] 00000000: 00 00 00 00 92 80 e0 82 2e 75 87 78 db 57 8d 97 00000010: de 11 9d 1e 35 20 23 08 00 00 00 01 00 00 01 7a 00000020: 00 00 01 5e 00 04 00 04 00 00 00 00 00 00 00 03 00000030: e0 8a 0b 04 ee f8 47 c2 52 96 71 9f 9d 39 0c 91 00000040: ea 6a 16 7c 80 31 a0 fd 76 cc c4 f1 8f 1a d3 be 00000050: fa 78 6b df c1 c6 73 83 be 36 69 c4 8a 87 ed 11 00000060: 90 31 a8 fd f9 0a 5c e4 d4 23 c9 e6 b3 96 ac b6 00000070: 8e bd fc 27 58 79 9f cc 8b ac 6b 59 e4 70 4b 05 00000080: 23 16 ed 49 25 f3 de 02 2e ce ae 86 e8 b4 ca b4 00000090: 96 ad 5b f6 2b c2 47 33 6f da f3 97 3c 13 ed 1f 000000A0: 7a da 93 b5 69 6a b5 10 93 38 75 ea b7 34 a3 87 000000B0: b6 83 c7 da 8a a1 d9 2a 0b 22 e2 ab 63 2b 57 2b 000000C0: 88 e3 ea be 7b fc dc 26 ac b8 bb 15 96 f9 c2 f4 000000D0: 60 17 e4 09 18 ae 78 b8 73 02 6b 0e 20 cc b1 cd 000000E0: b4 4d 94 7f f3 16 28 9a d2 bd 26 77 4b a5 85 56 000000F0: b1 81 8b 9c c3 0a 7f 67 fe 6a 61 15 f1 45 66 f3 00000100: 36 fc a5 bb 1f d7 6d e7 1d 9f 3f b5 cc 60 19 48 00000110: 17 f7 08 28 1c 58 9f 2b 7a 0b b9 50 bd 02 ea b8 00000120: 1e 03 1f 52 6a 7a fc e5 b4 6b 00 cf 0d 83 1f d2 00000130: 3f f2 ad 43 d4 86 6e c1 88 d2 87 d6 1f ac a3 30 00000140: 7b c1 5b 6a 3d 4c 20 72 5d 2c ca bf 87 a2 ce 1d 00000150: b3 fa c7 7c 22 cd 66 fc be 49 22 32 17 ee 6e 5e 00000160: 62 c1 ca 12 2b 5d 3d 7b ae b5 3e 53 c5 98 05 1f 00000170: 42 53 49 d1 2c c2 d2 25 f1 d0 38 65 b7 b6 Responder's actions: (69) Computes shared key 00000000: bd 04 9d 0f 9c 5f 58 af c7 e4 01 bc 18 59 01 7c 00000010: 88 28 f9 f2 9f 33 01 5d 49 9a 7d 14 74 d4 31 ac (70) Computes SKEYSEED 00000000: 9b ed 6c 79 64 b3 de 3a e4 9e dd 62 04 5a f0 8b 00000010: 43 88 33 d4 e6 9e 73 16 a1 1a 9e b2 b4 19 13 c5 00000020: d0 6d fb 86 40 11 c3 02 bb e5 a3 b5 e4 4a c4 c0 00000030: 9d 18 c6 94 de c3 c5 14 82 e7 a2 51 fe c4 98 ca (71) Computes SK_d 00000000: c2 21 15 fd d3 99 3b 2a 43 60 c4 59 34 b0 be 3f 00000010: 53 ef 6e b1 dd 88 ad 72 55 dd 83 22 5c 6f e1 d6 00000020: 1f 1e ab 06 f9 41 cb c8 ea f9 dc fc 19 a0 2d bf 00000030: 9a 0a 3f 3a 9a 45 1f 08 b6 a9 2c 62 52 b7 26 34 Smyslov Expires 9 June 2023 [Page 98] Internet-Draft GOST algorithms in IKEv2 December 2022 (72) Computes SK_ei 00000000: 18 4e 4e 0f 36 28 bf 3c 9c 04 8e 93 bf a0 77 53 00000010: 91 34 12 81 42 e6 4e 62 7f db a5 ed 98 60 50 ff 00000020: b4 e1 3e 23 (73) Computes SK_er 00000000: e9 27 59 2f 09 49 68 1e 0e 62 db c6 19 06 73 13 00000010: cf da 5c 02 27 3e 4a b4 78 98 b4 86 d0 e9 34 f4 00000020: a5 bb 18 2f (74) Computes SK_pi 00000000: 30 2c 10 8d 0f 61 47 00 f1 40 4f a9 4f af b5 30 00000010: 11 ba 5f 24 39 32 85 12 4e 7e 71 75 50 15 a6 93 00000020: c3 d0 5e 40 2e 21 8e b1 59 09 cd a4 eb b4 91 68 00000030: 29 42 fe e2 d8 76 8f a6 96 55 1f ab 6c 9b 00 f8 (75) Computes SK_pr 00000000: 6f 81 72 cb 96 58 fb 0e 17 70 b6 b9 1f a9 69 a9 00000010: fc c7 27 4f b4 e1 85 90 a0 c7 9f f9 72 11 61 2a 00000020: 35 b7 b7 96 d3 6a bb a5 aa b1 b8 34 8d 99 c6 f3 00000030: 2b fc 32 56 c1 94 71 04 55 bd 89 6a bf c3 8b fe (76) Extracts IV from message (fragment 1) 00000000: 00 00 00 00 00 00 00 00 (77) Computes K1i (i1 = 0) 00000000: 3c 57 d7 c8 9f 50 98 fc 86 81 d6 8a 4e 5d 83 c6 00000010: 1e 42 e6 e7 60 67 05 8d f5 2e 10 13 12 15 32 58 (78) Computes K2i (i2 = 0) 00000000: 0b 88 0a 1b c8 3e 61 79 82 08 db 13 31 08 63 3c 00000010: 17 62 17 cb 7d 18 ce 70 37 84 85 f4 89 49 d0 06 (79) Computes K3i (i3 = 0) 00000000: 18 63 41 67 49 6e cf 48 56 71 4d aa 42 63 5c 11 00000010: 2e 26 5b e2 7b c7 53 a4 09 82 e5 5a 7e f4 65 4d (80) Composes MGM nonce (fragment 1) 00000000: 00 00 00 00 b4 e1 3e 23 Smyslov Expires 9 June 2023 [Page 99] Internet-Draft GOST algorithms in IKEv2 December 2022 (81) Extracts ICV from message (fragment 1) 00000000: b1 51 cd e6 dc 64 12 1c (82) Extracts AAD from message (fragment 1) 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 08 00 00 00 01 00 00 02 20 23 00 02 04 00000020: 00 01 00 04 (83) Extracts ciphertext from message (fragment 1) 00000000: 03 45 60 11 15 25 f5 45 bb 0e f4 25 26 e2 14 8c 00000010: a7 01 82 f6 9c 6e 42 f1 a3 9b 9e ac a6 dd 0d 9c 00000020: ff 79 15 ed b9 0c 81 a0 b4 29 61 fb 55 1b c1 73 00000030: 4d de 1f b2 5f 1f cb 84 5d 12 24 85 52 c4 f2 1d 00000040: 01 a7 92 ad 55 4d 90 d0 58 d2 1a 5e f6 dc 4e 73 00000050: d4 9b 08 66 d7 64 de 10 e6 75 69 20 e3 7b 6c f0 00000060: 4b 8b ff 60 39 f1 19 31 72 dd c1 09 33 5b 1d 56 00000070: ee 0c 1c 42 d7 f3 04 d3 5b 9a 6e cf 7f b3 1f ac 00000080: 34 a6 ee e0 ac 87 b8 88 99 75 a6 ae dc b5 30 38 00000090: eb 3d 48 fd cc 69 64 f8 c6 61 ce e9 e1 24 ba aa 000000A0: 25 5e e6 ea 8b 0c ef 20 31 bf a9 ae 6d e2 82 d4 000000B0: ab 2c d7 af ca 62 fe bd 7c 8f a9 dc d3 63 05 d7 000000C0: ba 92 56 66 44 ad 5d 9d 1e 9a 27 2e 22 6e 5b 0c 000000D0: af 84 6b c6 a7 cf ca 72 f8 8e d3 a1 bc d4 7c 5b 000000E0: 7e 26 7f b3 05 d8 62 ef ad d6 07 70 d7 4b 33 e4 000000F0: 26 84 e6 eb 5b 65 5c a7 71 29 45 15 d9 b0 83 6a 00000100: 52 5f a9 d8 dd f1 d8 62 c7 d7 3d e9 69 0e c5 b1 00000110: e1 de 20 6c 3d 5f f7 f7 9f f6 a5 7b 4d a5 4e e9 00000120: b4 c4 c2 7d cc 43 62 77 57 37 d3 40 48 b2 c0 5b 00000130: 48 ab d0 94 79 ef 3d 04 e3 d8 6d 42 56 ed cd 94 00000140: b4 23 2c fa f0 6b 39 ad 41 a3 b3 8f ec b8 6c ef 00000150: e1 98 3a b2 fb a8 fd 21 96 8a bf 3a 65 47 8a e9 00000160: 69 60 44 02 2c ec 7a 86 74 fe 1d 9b 08 5e b8 5e 00000170: f8 ca 37 20 5f a7 74 8c 12 88 f2 d8 9e d4 94 29 00000180: c2 db f9 fb 35 a0 cf 21 2b da 8b 9e cc 52 84 eb 00000190: c4 12 39 3e e6 18 fb f7 57 6c b5 1e 10 3d 11 9c 000001A0: 29 9c 41 73 69 d8 d0 9d 71 2b 77 66 87 65 51 19 000001B0: db 27 a0 dd aa 64 ba fd c0 5f e1 4e da 7c 20 fc 000001C0: 8c 13 ab 2d c2 9c 37 9d 7e 51 cb 29 03 10 52 dc 000001D0: f8 09 61 cc 12 9a a0 8e 1b e4 52 f8 72 bd 7a 86 000001E0: db 93 7c 55 b8 1e 7f 21 d4 e6 02 f2 (84) Decrypts ciphertext and verifies ICV using K3i as K_msg, resulted in plaintext (fragment 1) Smyslov Expires 9 June 2023 [Page 100] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 25 00 00 4e 09 00 00 00 30 44 31 20 30 1e 06 03 00000010: 55 04 03 13 17 49 4b 45 20 49 6e 74 65 72 6f 70 00000020: 20 54 65 73 74 20 43 6c 69 65 6e 74 31 13 30 11 00000030: 06 03 55 04 0a 13 0a 45 4c 56 49 53 2d 50 4c 55 00000040: 53 31 0b 30 09 06 03 55 04 06 13 02 52 55 26 00 00000050: 05 00 04 30 82 04 f7 30 82 04 a4 a0 03 02 01 02 00000060: 02 13 7c 00 03 da a8 9e 1e ff 9e 79 05 fb bb 00 00000070: 01 00 03 da a8 30 0a 06 08 2a 85 03 07 01 01 03 00000080: 02 30 82 01 0a 31 18 30 16 06 05 2a 85 03 64 01 00000090: 12 0d 31 32 33 34 35 36 37 38 39 30 31 32 33 31 000000A0: 1a 30 18 06 08 2a 85 03 03 81 03 01 01 12 0c 30 000000B0: 30 31 32 33 34 35 36 37 38 39 30 31 2f 30 2d 06 000000C0: 03 55 04 09 0c 26 d1 83 d0 bb 2e 20 d0 a1 d1 83 000000D0: d1 89 d1 91 d0 b2 d1 81 d0 ba d0 b8 d0 b9 20 d0 000000E0: b2 d0 b0 d0 bb 20 d0 b4 2e 20 31 38 31 0b 30 09 000000F0: 06 03 55 04 06 13 02 52 55 31 19 30 17 06 03 55 00000100: 04 08 0c 10 d0 b3 2e 20 d0 9c d0 be d1 81 d0 ba 00000110: d0 b2 d0 b0 31 15 30 13 06 03 55 04 07 0c 0c d0 00000120: 9c d0 be d1 81 d0 ba d0 b2 d0 b0 31 25 30 23 06 00000130: 03 55 04 0a 0c 1c d0 9e d0 9e d0 9e 20 22 d0 9a 00000140: d0 a0 d0 98 d0 9f d0 a2 d0 9e 2d d0 9f d0 a0 d0 00000150: 9e 22 31 3b 30 39 06 03 55 04 03 0c 32 d0 a2 d0 00000160: b5 d1 81 d1 82 d0 be d0 b2 d1 8b d0 b9 20 d0 a3 00000170: d0 a6 20 d0 9e d0 9e d0 9e 20 22 d0 9a d0 a0 d0 00000180: 98 d0 9f d0 a2 d0 9e 2d d0 9f d0 a0 d0 9e 22 30 00000190: 1e 17 0d 32 31 31 30 30 31 30 36 31 30 31 30 5a 000001A0: 17 0d 32 32 30 31 30 31 30 36 32 30 31 30 5a 30 000001B0: 44 31 20 30 1e 06 03 55 04 03 13 17 49 4b 45 20 000001C0: 49 6e 74 65 72 6f 70 20 54 65 73 74 20 43 6c 69 000001D0: 65 6e 74 31 13 30 11 06 03 55 04 0a 13 0a 45 4c 000001E0: 56 49 53 2d 50 4c 55 53 31 0b 30 00 (85) Extracts IV from message (fragment 2) 00000000: 00 00 00 00 00 00 00 01 (86) Uses previously computed key K3i 00000000: 18 63 41 67 49 6e cf 48 56 71 4d aa 42 63 5c 11 00000010: 2e 26 5b e2 7b c7 53 a4 09 82 e5 5a 7e f4 65 4d (87) Composes MGM nonce (fragment 2) 00000000: 00 00 00 01 b4 e1 3e 23 (88) Extracts ICV from message (fragment 2) 00000000: b4 68 c7 4d eb dd bd 92 Smyslov Expires 9 June 2023 [Page 101] Internet-Draft GOST algorithms in IKEv2 December 2022 (89) Extracts AAD from message (fragment 2) 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 08 00 00 00 01 00 00 02 20 00 00 02 04 00000020: 00 02 00 04 (90) Extracts ciphertext from message (fragment 2) 00000000: 3c b1 b4 aa 04 56 27 1b 45 04 f7 70 1b 17 16 16 00000010: 85 16 ee b3 88 7d 08 64 2d 24 b8 1d 7e ac c9 72 00000020: 73 07 d3 d9 ef 5d 08 8b 47 97 5a 98 53 00 ec 13 00000030: cc 5a 46 7b 16 a2 14 6a f1 ea 17 71 9b 75 1d 46 00000040: 9d 6d 8c 3a a2 b2 75 c5 c9 4c 16 56 73 03 16 40 00000050: 42 fe a2 5a cc c7 ed 37 91 b1 eb e5 56 2a 01 bc 00000060: a2 83 ac 05 f1 a7 56 e5 f2 bb f4 18 7f 05 82 14 00000070: 70 de af 44 d4 cc a9 0a 95 6d c1 96 11 3d cf e1 00000080: aa 27 f1 87 60 d2 32 c1 1e 91 bf 60 00 5f d3 fb 00000090: a4 55 2e f0 0b 08 14 ed a3 63 54 4c b8 7b 5c 71 000000A0: 69 d1 3b 0c 6c 93 f3 99 2e fe 36 98 90 a1 05 ee 000000B0: 35 d2 da f8 81 59 f5 17 23 33 40 99 99 42 37 b0 000000C0: 0d 94 0a bd 00 cf 1c be 0e d0 13 93 e2 27 5a a5 000000D0: c5 e8 a0 25 5a 2d ad 6c b4 bc 64 37 05 ac cd 22 000000E0: 92 13 83 ab e8 87 93 29 82 dc 47 b4 1c 92 4d 36 000000F0: ef ba 10 3d 42 2d d6 2c d5 6b 95 99 2d 17 61 c4 00000100: c5 13 ed 55 a5 e5 b2 65 ac 25 24 21 c4 25 7f 6f 00000110: 68 fb ce 8f 17 60 e9 ac 9c 52 9f d5 d4 a7 14 35 00000120: 89 a4 1f de 21 a9 51 3c 1d 73 00 10 ba a6 7c 24 00000130: fb b9 20 21 5e df 63 8a c8 1f b1 55 05 5a 70 a8 00000140: b5 f4 23 9e 22 c0 2a 7c a5 11 01 c3 5e 3d 52 2a 00000150: b8 1d c5 19 b5 55 cc 8e f0 8d 6e 93 36 10 cd e3 00000160: c8 a5 a6 2e 90 53 fa 92 64 16 6c 4f da 9b e5 f8 00000170: 91 c5 ea b4 60 64 db ed d5 bc fc 3a 73 62 ce b2 00000180: ff 7a 15 95 0d 77 00 ee 5c a8 c5 89 2f 39 13 59 00000190: dd 52 ea 11 ae 28 82 36 be aa 29 68 4c f6 63 d5 000001A0: 93 a5 54 3d 8f 13 26 0a 87 34 b9 81 1c 2c cd d5 000001B0: 79 3a 65 6d 1c 6e 32 be b0 77 b7 b3 e4 ae b8 72 000001C0: f9 44 59 e9 14 46 67 56 93 ca 70 d1 ac 25 05 62 000001D0: f7 55 c2 9e 2e 11 a7 29 01 24 77 4a 6f 1c ba f6 000001E0: 4a 4f 83 75 29 1e c7 a9 68 29 02 d0 (91) Decrypts ciphertext and verifies ICV using K3i as K_msg, resulted in plaintext (fragment 2) Smyslov Expires 9 June 2023 [Page 102] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 09 06 03 55 04 06 13 02 52 55 30 81 aa 30 21 06 00000010: 08 2a 85 03 07 01 01 01 02 30 15 06 09 2a 85 03 00000020: 07 01 02 01 02 01 06 08 2a 85 03 07 01 01 02 03 00000030: 03 81 84 00 04 81 80 ee 2f 0a 0e 09 1e 7e 04 ef 00000040: ba 5b 62 a2 52 86 e1 9c 24 50 30 50 b0 b4 8a 37 00000050: 35 b5 fc af 28 94 ec b5 9b 92 41 5b 69 e2 c9 ba 00000060: 24 de 6a 72 c4 ef 44 bb 89 a1 05 14 1b 87 3d 6a 00000070: a3 72 3e 17 ca 7f 39 28 ce 16 8b dd 07 52 87 6a 00000080: 0d 77 42 6d 99 2b 46 2c fd 4b b2 7c d7 c7 17 08 00000090: 12 54 63 47 9d 14 3d 61 ed f2 95 ab 11 80 69 02 000000A0: a7 66 60 50 7e a4 53 6d ad 01 49 b2 16 8a 95 1d 000000B0: cf 1a 57 93 56 14 5e a3 82 02 59 30 82 02 55 30 000000C0: 0e 06 03 55 1d 0f 01 01 ff 04 04 03 02 05 a0 30 000000D0: 13 06 03 55 1d 25 04 0c 30 0a 06 08 2b 06 01 05 000000E0: 05 07 03 11 30 1d 06 03 55 1d 0e 04 16 04 14 40 000000F0: 81 b1 d1 18 75 f0 da 6b 3c 50 5f cd 73 1d d9 77 00000100: f2 d7 c1 30 1f 06 03 55 1d 23 04 18 30 16 80 14 00000110: 9b 85 5e fb 81 dc 4d 59 07 51 63 cf be df da 2c 00000120: 7f c9 44 3c 30 82 01 0f 06 03 55 1d 1f 04 82 01 00000130: 06 30 82 01 02 30 81 ff a0 81 fc a0 81 f9 86 81 00000140: b5 68 74 74 70 3a 2f 2f 74 65 73 74 67 6f 73 74 00000150: 32 30 31 32 2e 63 72 79 70 74 6f 70 72 6f 2e 72 00000160: 75 2f 43 65 72 74 45 6e 72 6f 6c 6c 2f 21 30 34 00000170: 32 32 21 30 34 33 35 21 30 34 34 31 21 30 34 34 00000180: 32 21 30 34 33 65 21 30 34 33 32 21 30 34 34 62 00000190: 21 30 34 33 39 25 32 30 21 30 34 32 33 21 30 34 000001A0: 32 36 25 32 30 21 30 34 31 65 21 30 34 31 65 21 000001B0: 30 34 31 65 25 32 30 21 30 30 32 32 21 30 34 31 000001C0: 61 21 30 34 32 30 21 30 34 31 38 21 30 34 31 66 000001D0: 21 30 34 32 32 21 30 34 31 65 2d 21 30 34 31 66 000001E0: 21 30 34 32 30 21 30 34 31 65 21 00 (92) Extracts IV from message (fragment 3) 00000000: 00 00 00 00 00 00 00 02 (93) Uses previously computed key K3i 00000000: 18 63 41 67 49 6e cf 48 56 71 4d aa 42 63 5c 11 00000010: 2e 26 5b e2 7b c7 53 a4 09 82 e5 5a 7e f4 65 4d (94) Composes MGM nonce (fragment 3) 00000000: 00 00 00 02 b4 e1 3e 23 (95) Extracts ICV from message (fragment 3) 00000000: 54 4f 9b aa dd af bd ca Smyslov Expires 9 June 2023 [Page 103] Internet-Draft GOST algorithms in IKEv2 December 2022 (96) Extracts AAD from message (fragment 3) 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 08 00 00 00 01 00 00 02 20 00 00 02 04 00000020: 00 03 00 04 (97) Extracts ciphertext from message (fragment 3) 00000000: e7 72 d9 51 90 b1 a2 bc 81 8d d6 56 bf 7a 81 e0 00000010: 1a a1 70 8b 35 a0 7e 5f e8 df 58 3d 75 5d d2 4c 00000020: 4c ce 17 77 3f 28 9c ca 7a a4 23 23 f0 c7 ff ff 00000030: 98 ee e3 1a 27 39 4d 90 1a b7 5b 44 11 16 11 3a 00000040: ea bf 83 66 da 92 2a 3a 3d bd b5 40 c8 bc f6 ed 00000050: cb 1d 5a 8e 30 f0 06 72 dc 6c da c1 45 7b e8 25 00000060: ca 93 2a b2 fe 4a db 00 90 e3 31 78 26 8d ae c8 00000070: 39 66 80 7d e5 01 5f 21 d6 c3 40 46 19 e4 43 9d 00000080: 23 c6 c1 18 06 49 bd f5 dc 8c 1b 19 b0 60 0c a3 00000090: ad f5 5c 57 e8 8e 37 e6 ea b6 79 11 b8 f1 16 ba 000000A0: a6 d9 09 1f 0d e0 3c 07 b8 ce 9d 11 a3 c6 f7 e4 000000B0: 62 e8 94 7b ad b9 8a 6b 9c f1 f8 43 cf 7e fc 5e 000000C0: 44 ab bf b1 88 f5 67 1e 84 5f 82 63 f3 13 89 55 000000D0: f5 ef 86 c3 db 48 37 f8 26 3c c4 6d a5 fc b5 69 000000E0: 56 0d 2d f3 c0 98 dd e7 53 da 0a 28 87 2f 38 ab 000000F0: a9 ec 60 a6 c4 54 c6 68 e7 6b e3 4b 54 bf b5 82 00000100: 44 c9 b9 45 bc 9e f5 58 d8 76 63 92 cd 52 ec 82 00000110: 80 d6 43 86 10 16 eb 7b 32 e4 ee ba ec 09 b6 4f 00000120: 35 1a bf da d7 de 40 fa b5 d2 40 f2 73 09 2d 52 00000130: 83 bd 56 a6 6b d3 9f 8a c2 c5 66 c6 6b 22 fb 6a 00000140: 00 b2 8a ac 9d 8b fc 8d 41 af 80 92 16 51 e2 cb 00000150: 89 62 9b 77 2b 1e 38 01 df fc 1f 81 2d 95 8b 9e 00000160: 1d 1e ad 9c c0 0d fc 77 6e 35 13 16 26 28 1a 29 00000170: 19 7f f8 08 5a 0f 09 4f 6f ba 7f 4c 5b cd 0c c2 00000180: 71 ab ea 82 a2 d2 d1 1b 17 fd dc c3 54 03 85 14 00000190: f4 90 47 2e 67 d7 93 c3 67 7e 8a f7 43 1a b3 41 000001A0: 32 f7 b0 58 38 6e 24 c8 96 d9 94 d3 54 89 2d 61 000001B0: 10 a9 9c 22 51 52 02 c9 b7 8d cc 5b 28 6d cb 55 000001C0: 5d 2f 97 8a 8f 3f 27 56 73 eb ec 5d e4 64 91 49 000001D0: 3b 88 f2 0a fc ed a5 67 a9 e3 71 ef 31 ce a0 33 000001E0: fc d8 ea 4d 1e 3f dc 89 c8 89 e2 c3 (98) Decrypts ciphertext and verifies ICV using K3i as K_msg, resulted in plaintext (fragment 3) Smyslov Expires 9 June 2023 [Page 104] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 30 30 32 32 28 31 29 2e 63 72 6c 86 3f 68 74 74 00000010: 70 3a 2f 2f 74 65 73 74 67 6f 73 74 32 30 31 32 00000020: 2e 63 72 79 70 74 6f 70 72 6f 2e 72 75 2f 43 65 00000030: 72 74 45 6e 72 6f 6c 6c 2f 74 65 73 74 67 6f 73 00000040: 74 32 30 31 32 28 31 29 2e 63 72 6c 30 81 da 06 00000050: 08 2b 06 01 05 05 07 01 01 04 81 cd 30 81 ca 30 00000060: 44 06 08 2b 06 01 05 05 07 30 02 86 38 68 74 74 00000070: 70 3a 2f 2f 74 65 73 74 67 6f 73 74 32 30 31 32 00000080: 2e 63 72 79 70 74 6f 70 72 6f 2e 72 75 2f 43 65 00000090: 72 74 45 6e 72 6f 6c 6c 2f 72 6f 6f 74 32 30 31 000000A0: 38 2e 63 72 74 30 3f 06 08 2b 06 01 05 05 07 30 000000B0: 01 86 33 68 74 74 70 3a 2f 2f 74 65 73 74 67 6f 000000C0: 73 74 32 30 31 32 2e 63 72 79 70 74 6f 70 72 6f 000000D0: 2e 72 75 2f 6f 63 73 70 32 30 31 32 67 2f 6f 63 000000E0: 73 70 2e 73 72 66 30 41 06 08 2b 06 01 05 05 07 000000F0: 30 01 86 35 68 74 74 70 3a 2f 2f 74 65 73 74 67 00000100: 6f 73 74 32 30 31 32 2e 63 72 79 70 74 6f 70 72 00000110: 6f 2e 72 75 2f 6f 63 73 70 32 30 31 32 67 73 74 00000120: 2f 6f 63 73 70 2e 73 72 66 30 0a 06 08 2a 85 03 00000130: 07 01 01 03 02 03 41 00 21 ee 3b e1 fd 0f 36 90 00000140: 92 c4 a2 35 26 e8 dc 4e b8 ef 89 40 70 d2 91 39 00000150: bc 79 a6 e2 f7 c1 06 bd d5 d6 ff 72 a5 6c f2 c0 00000160: c3 75 e9 ca 67 81 c1 93 96 b4 bd 18 12 4c 37 f7 00000170: d9 73 d6 4c 8a a6 c4 0a 24 00 00 19 04 5e 9e 50 00000180: 5f 58 b0 a5 7a 33 45 83 49 66 0f 1c 3c 7a 67 71 00000190: 98 27 00 00 4e 09 00 00 00 30 44 31 20 30 1e 06 000001A0: 03 55 04 03 13 17 49 4b 45 20 49 6e 74 65 72 6f 000001B0: 70 20 54 65 73 74 20 53 65 72 76 65 72 31 13 30 000001C0: 11 06 03 55 04 0a 13 0a 45 4c 56 49 53 2d 50 4c 000001D0: 55 53 31 0b 30 09 06 03 55 04 06 13 02 52 55 29 000001E0: 00 00 95 0e 00 00 00 0c 30 0a 06 00 (99) Extracts IV from message (fragment 4) 00000000: 00 00 00 00 00 00 00 03 (100) Uses previously computed key K3i 00000000: 18 63 41 67 49 6e cf 48 56 71 4d aa 42 63 5c 11 00000010: 2e 26 5b e2 7b c7 53 a4 09 82 e5 5a 7e f4 65 4d (101) Composes MGM nonce (fragment 4) 00000000: 00 00 00 03 b4 e1 3e 23 (102) Extracts ICV from message (fragment 4) 00000000: d2 25 f1 d0 38 65 b7 b6 Smyslov Expires 9 June 2023 [Page 105] Internet-Draft GOST algorithms in IKEv2 December 2022 (103) Extracts AAD from message (fragment 4) 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 08 00 00 00 01 00 00 01 7a 00 00 01 5e 00000020: 00 04 00 04 (104) Extracts ciphertext from message (fragment 4) 00000000: e0 8a 0b 04 ee f8 47 c2 52 96 71 9f 9d 39 0c 91 00000010: ea 6a 16 7c 80 31 a0 fd 76 cc c4 f1 8f 1a d3 be 00000020: fa 78 6b df c1 c6 73 83 be 36 69 c4 8a 87 ed 11 00000030: 90 31 a8 fd f9 0a 5c e4 d4 23 c9 e6 b3 96 ac b6 00000040: 8e bd fc 27 58 79 9f cc 8b ac 6b 59 e4 70 4b 05 00000050: 23 16 ed 49 25 f3 de 02 2e ce ae 86 e8 b4 ca b4 00000060: 96 ad 5b f6 2b c2 47 33 6f da f3 97 3c 13 ed 1f 00000070: 7a da 93 b5 69 6a b5 10 93 38 75 ea b7 34 a3 87 00000080: b6 83 c7 da 8a a1 d9 2a 0b 22 e2 ab 63 2b 57 2b 00000090: 88 e3 ea be 7b fc dc 26 ac b8 bb 15 96 f9 c2 f4 000000A0: 60 17 e4 09 18 ae 78 b8 73 02 6b 0e 20 cc b1 cd 000000B0: b4 4d 94 7f f3 16 28 9a d2 bd 26 77 4b a5 85 56 000000C0: b1 81 8b 9c c3 0a 7f 67 fe 6a 61 15 f1 45 66 f3 000000D0: 36 fc a5 bb 1f d7 6d e7 1d 9f 3f b5 cc 60 19 48 000000E0: 17 f7 08 28 1c 58 9f 2b 7a 0b b9 50 bd 02 ea b8 000000F0: 1e 03 1f 52 6a 7a fc e5 b4 6b 00 cf 0d 83 1f d2 00000100: 3f f2 ad 43 d4 86 6e c1 88 d2 87 d6 1f ac a3 30 00000110: 7b c1 5b 6a 3d 4c 20 72 5d 2c ca bf 87 a2 ce 1d 00000120: b3 fa c7 7c 22 cd 66 fc be 49 22 32 17 ee 6e 5e 00000130: 62 c1 ca 12 2b 5d 3d 7b ae b5 3e 53 c5 98 05 1f 00000140: 42 53 49 d1 2c c2 (105) Decrypts ciphertext and verifies ICV using K3i as K_msg, resulted in plaintext (fragment 4) Smyslov Expires 9 June 2023 [Page 106] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 08 2a 85 03 07 01 01 03 03 6a 3e 59 0d 72 1e 55 00000010: a3 c0 d1 2f 8a 9b 4e 44 10 58 59 bd 62 9e e7 12 00000020: 31 e5 7d 01 53 f3 84 40 dd ac 73 ed 09 3a 10 d9 00000030: 6e 7f eb 80 6c 11 9e 91 f3 7c 3c b0 55 f7 4b ec 00000040: 0e 78 36 10 95 02 09 86 b3 27 04 2a 83 3c 89 36 00000050: 1b 73 cf 7b c9 e0 df a2 07 12 1e 69 52 4d 89 1b 00000060: de 6e 48 d1 34 fa 21 78 22 88 2e 30 86 c0 80 0a 00000070: 2d 74 af 08 ff 35 75 a5 79 e3 85 40 22 6b a8 42 00000080: f6 72 24 bf 29 87 58 a8 20 29 00 00 08 00 00 40 00000090: 00 2f 00 00 0c 00 00 40 01 00 00 00 04 21 00 00 000000A0: 10 01 00 00 00 00 01 00 00 00 03 00 00 2c 00 00 000000B0: 38 00 00 00 34 01 03 04 05 6c 0c a5 70 03 00 00 000000C0: 08 01 00 00 20 03 00 00 08 01 00 00 21 03 00 00 000000D0: 08 01 00 00 22 03 00 00 08 01 00 00 23 00 00 00 000000E0: 08 05 00 00 00 2d 00 00 28 02 00 00 00 07 01 00 000000F0: 10 08 00 08 00 0a 6f 0a ab 0a 6f 0a ab 07 00 00 00000100: 10 00 00 ff ff 00 00 00 00 ff ff ff ff 29 00 00 00000110: 28 02 00 00 00 07 01 00 10 08 00 08 00 0a 00 00 00000120: 02 0a 00 00 02 07 00 00 10 00 00 ff ff 0a 00 00 00000130: 00 0a 00 00 ff 29 00 00 08 00 00 40 0a 00 00 00 00000140: 08 00 00 40 0b 00 (106) Reassembles message from received fragments and parses it IKE SA Auth #9280E0822E758778.DB578D97DE119D1E.00000001 IKEv2 I->R[1847] 4*EF[...]->E[1819]{ IDi[78](DN){CN=IKE Interop Test Client,O=ELVIS-PLUS,C=RU}, CERT[1280](X.509 Cert){308204...A6C40A}, CERTREQ[25](X.509 Cert){5E9E50...677198}, IDr[78](DN){CN=IKE Interop Test Server,O=ELVIS-PLUS,C=RU}, AUTH[149](Sig){id-tc26-signwithdigest-gost3410-12-512[12]: 6A3E59...58A820}, N[8](INITIAL_CONTACT), N[12](SET_WINDOW_SIZE){4}, CP[16](REQUEST){IP4.Address[0], IP4.DNS[0]}, SA[56]{ P[52](#1:ESP:6C0CA570:5#){ Encryption=ENCR_KUZNYECHIK_MGM_KTREE, ENCR_MAGMA_MGM_KTREE, ENCR_KUZNYECHIK_MGM_MAC_KTREE, ENCR_MAGMA_MGM_MAC_KTREE, ESN=Off}}, TSi[40](2#){10.111.10.171:icmp:8.0, 0.0.0.0-255.255.255.255}, TSr[40](2#){10.0.0.2:icmp:8.0, 10.0.0.0-10.0.0.255}, N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} Smyslov Expires 9 June 2023 [Page 107] Internet-Draft GOST algorithms in IKEv2 December 2022 (107) Computes prf(SK_pi, IDi) 00000000: ce e8 8b d1 7e 3c 83 32 eb d1 29 08 de dc 71 f4 00000010: 8f ba 09 b8 ca 5b 10 e2 f4 44 29 5c 97 7b 26 01 00000020: a4 ba 83 c8 ea 40 92 0f 88 18 bd e7 e1 c9 45 cf 00000030: ff 99 48 05 0d f4 93 a6 cd 54 46 d7 eb 7a 52 94 (108) Uses initiator's public key 00000010: EE 2F 0A 0E 09 1E 7E 04 EF BA 5B 62 A2 52 86 E1 00000020: 9C 24 50 30 50 B0 B4 8A 37 35 B5 FC AF 28 94 EC 00000030: B5 9B 92 41 5B 69 E2 C9 BA 24 DE 6A 72 C4 EF 44 00000040: BB 89 A1 05 14 1B 87 3D 6A A3 72 3E 17 CA 7F 39 00000050: 28 CE 16 8B DD 07 52 87 6A 0D 77 42 6D 99 2B 46 00000060: 2C FD 4B B2 7C D7 C7 17 08 12 54 63 47 9D 14 3D 00000070: 61 ED F2 95 AB 11 80 69 02 A7 66 60 50 7E A4 53 00000080: 6D AD 01 49 B2 16 8A 95 1D CF 1A 57 93 56 14 5E (109) Verifies signature from AUTH payload using algorithm id-tc26- signwithdigest-gost3410-12-512 00000000: 6a 3e 59 0d 72 1e 55 a3 c0 d1 2f 8a 9b 4e 44 10 00000010: 58 59 bd 62 9e e7 12 31 e5 7d 01 53 f3 84 40 dd 00000020: ac 73 ed 09 3a 10 d9 6e 7f eb 80 6c 11 9e 91 f3 00000030: 7c 3c b0 55 f7 4b ec 0e 78 36 10 95 02 09 86 b3 00000040: 27 04 2a 83 3c 89 36 1b 73 cf 7b c9 e0 df a2 07 00000050: 12 1e 69 52 4d 89 1b de 6e 48 d1 34 fa 21 78 22 00000060: 88 2e 30 86 c0 80 0a 2d 74 af 08 ff 35 75 a5 79 00000070: e3 85 40 22 6b a8 42 f6 72 24 bf 29 87 58 a8 20 (110) Computes keys for ESP SAs 00000000: 98 ab 7e db 78 03 a1 e6 c7 21 43 ee b9 7f 5f 56 00000010: 45 bb 51 cd 0b b7 09 a1 af 34 02 87 69 4d 7b a0 00000020: 1d 14 a0 cc 00000000: 70 31 4d 57 94 8b 7e 5c 6f 29 d5 68 1b fd 43 2b 00000010: 19 4e 64 6d 8f 8a 8d 1e ba 72 24 59 c7 0c de 81 00000020: e2 04 84 af (111) Computes prf(SK_pr,IDr) 00000000: 7d c8 6a 33 12 02 5c 21 1f ab dc 83 0b 01 a5 27 00000010: 82 a2 f2 1f 64 c6 e9 5e 0e c0 4c e5 d9 11 8d 8e 00000020: b9 5c ef fa b0 a3 37 75 94 20 7c e4 60 60 ed 9d 00000030: fa 5e cb 7e e7 79 05 ab fb 51 1b 03 a8 2c c5 6a (112) Uses private key for signing (little endian) Smyslov Expires 9 June 2023 [Page 108] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: CB 73 0C 81 6F AC 6D 81 9F 82 AE 15 A9 08 12 17 00000010: D3 1B 97 64 B7 1C 34 0D D3 DD 90 1F 15 8C 9B 06 (113) Uses random number for signing 00000000: 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 00000010: 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 (114) Computes signature using algorithm id-tc26-signwithdigest- gost3410-12-256 00000000: c8 40 af f7 46 6f 7b eb d2 b9 1c 5a 80 d0 00 93 00000010: c2 5e 44 16 40 47 f7 8e 61 9c da a5 16 94 83 c5 00000020: 68 5f e8 4d 03 e7 c2 cd 08 07 b8 f3 46 66 6d 05 00000030: 76 c0 d5 e7 60 1d 59 49 09 45 52 c4 95 a7 5a d3 (115) Computes K1r (i1 = 0) 00000000: 35 e4 d1 65 2e ec 24 89 e4 c9 58 b1 b9 05 1b 83 00000010: 62 5e 65 d7 61 73 d9 1c cf 84 60 64 b9 f2 e7 51 (116) Computes K2r (i2 = 0) 00000000: 86 8c 89 42 41 d7 30 da 1a 4a 67 69 3a 32 4d 38 00000010: f3 54 02 9f f7 7d b7 bc 5a ee 3b 60 2b 3f 05 56 (117) Computes K3r (i3 = 0) 00000000: 31 95 e8 c6 67 af 42 d8 ce f1 e8 99 c6 8b 2a c2 00000010: 29 aa 3d c0 ff 18 5f 3d 79 4a 14 6b 9f ac d0 bb (118) Selects SPI for incoming ESP SA 00000000: 34 ff 8a 25 (119) Creates message splitting it into 4 fragments Smyslov Expires 9 June 2023 [Page 109] Internet-Draft GOST algorithms in IKEv2 December 2022 IKE SA Auth #9280E0822E758778.DB578D97DE119D1E.00000001 IKEv2 I<=R[1563] E[1535]->4*EF[...]{ IDr[78](DN){CN=IKE Interop Test Server,O=ELVIS-PLUS,C=RU}, CERT[1211](X.509 Cert){308204...FB346D}, AUTH[85](Sig){id-tc26-signwithdigest-gost3410-12-256[12]: C840AF...A75AD3}, N[8](INITIAL_CONTACT), N[12](SET_WINDOW_SIZE){64}, CP[16](REPLY){IP4.Address[4]=10.1.1.3}, SA[32]{ P[28](#1:ESP:34FF8A25:2#){ Encryption=ENCR_MAGMA_MGM_KTREE, ESN=Off}}, TSi[24](1#){10.1.1.3}, TSr[24](1#){10.0.0.0-10.0.0.255}, N[8](ADDITIONAL_TS_POSSIBLE), N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} (120) Composes MGM nonce (fragment 1) 00000000: 00 00 00 00 a5 bb 18 2f (121) Composes AAD (fragment 1) 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 20 00 00 00 01 00 00 02 20 24 00 02 04 00000020: 00 01 00 04 (122) Composes plaintext (fragment 1) Smyslov Expires 9 June 2023 [Page 110] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 25 00 00 4e 09 00 00 00 30 44 31 20 30 1e 06 03 00000010: 55 04 03 13 17 49 4b 45 20 49 6e 74 65 72 6f 70 00000020: 20 54 65 73 74 20 53 65 72 76 65 72 31 13 30 11 00000030: 06 03 55 04 0a 13 0a 45 4c 56 49 53 2d 50 4c 55 00000040: 53 31 0b 30 09 06 03 55 04 06 13 02 52 55 27 00 00000050: 04 bb 04 30 82 04 b2 30 82 04 5f a0 03 02 01 02 00000060: 02 13 7c 00 03 d9 02 ec f9 34 3e c8 aa d6 59 00 00000070: 01 00 03 d9 02 30 0a 06 08 2a 85 03 07 01 01 03 00000080: 02 30 82 01 0a 31 18 30 16 06 05 2a 85 03 64 01 00000090: 12 0d 31 32 33 34 35 36 37 38 39 30 31 32 33 31 000000A0: 1a 30 18 06 08 2a 85 03 03 81 03 01 01 12 0c 30 000000B0: 30 31 32 33 34 35 36 37 38 39 30 31 2f 30 2d 06 000000C0: 03 55 04 09 0c 26 d1 83 d0 bb 2e 20 d0 a1 d1 83 000000D0: d1 89 d1 91 d0 b2 d1 81 d0 ba d0 b8 d0 b9 20 d0 000000E0: b2 d0 b0 d0 bb 20 d0 b4 2e 20 31 38 31 0b 30 09 000000F0: 06 03 55 04 06 13 02 52 55 31 19 30 17 06 03 55 00000100: 04 08 0c 10 d0 b3 2e 20 d0 9c d0 be d1 81 d0 ba 00000110: d0 b2 d0 b0 31 15 30 13 06 03 55 04 07 0c 0c d0 00000120: 9c d0 be d1 81 d0 ba d0 b2 d0 b0 31 25 30 23 06 00000130: 03 55 04 0a 0c 1c d0 9e d0 9e d0 9e 20 22 d0 9a 00000140: d0 a0 d0 98 d0 9f d0 a2 d0 9e 2d d0 9f d0 a0 d0 00000150: 9e 22 31 3b 30 39 06 03 55 04 03 0c 32 d0 a2 d0 00000160: b5 d1 81 d1 82 d0 be d0 b2 d1 8b d0 b9 20 d0 a3 00000170: d0 a6 20 d0 9e d0 9e d0 9e 20 22 d0 9a d0 a0 d0 00000180: 98 d0 9f d0 a2 d0 9e 2d d0 9f d0 a0 d0 9e 22 30 00000190: 1e 17 0d 32 31 30 39 33 30 31 33 32 34 30 36 5a 000001A0: 17 0d 32 31 31 32 33 30 31 33 33 34 30 36 5a 30 000001B0: 44 31 20 30 1e 06 03 55 04 03 13 17 49 4b 45 20 000001C0: 49 6e 74 65 72 6f 70 20 54 65 73 74 20 53 65 72 000001D0: 76 65 72 31 13 30 11 06 03 55 04 0a 13 0a 45 4c 000001E0: 56 49 53 2d 50 4c 55 53 31 0b 30 00 (123) Encrypts plaintext using K3r as K_msg, resulted in ciphertext (fragment 1) Smyslov Expires 9 June 2023 [Page 111] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 73 f2 45 3e fb 6a 26 28 67 7d 14 e3 bf 0a 90 74 00000010: c9 95 6a 40 d5 4e a6 77 cf 58 2e b8 ae 52 f4 25 00000020: f7 82 bc d9 f0 74 4e 38 51 90 07 70 27 f8 01 27 00000030: 17 da f4 ba bc 1e 02 0b 73 ec cc 7b f8 b3 68 64 00000040: f3 48 65 33 3b ab ac 19 11 d3 f7 78 b4 f8 d1 3f 00000050: 6d 46 93 37 a6 58 48 3a 7d d0 8a 9c 84 ab de eb 00000060: 0d d4 8d ab 75 20 18 27 42 fe 24 ee ba c4 a4 6e 00000070: db 80 68 3c 84 7e d6 36 50 d4 1b 1c bc c5 9f 18 00000080: 41 af 48 52 c1 7e a2 f0 e4 bc 0a 3c 64 34 81 ca 00000090: df 96 ba 51 91 f1 06 13 b2 04 23 c8 70 3a ea 64 000000A0: e9 ea ce c2 db aa 12 90 28 0c 9d f9 89 02 a8 5e 000000B0: 66 f5 6e ce dd e7 2c 4a 45 54 de 5e b8 76 73 67 000000C0: 2d a3 a0 52 91 74 ff b7 eb e4 ea d1 2b 04 76 f7 000000D0: ff 4b 1c b8 45 7e 8a 60 e7 1e ec 13 3e c1 d8 d0 000000E0: 78 be f4 79 77 06 ce 76 04 64 ad e7 10 19 65 2b 000000F0: 45 66 23 3d 34 7a 40 6c 36 c0 20 73 47 d8 7a b6 00000100: 2b 0f 56 04 7a c0 41 ab 18 23 11 78 7f 4f d4 f5 00000110: 7d 2e 06 a5 15 ee de 84 9f c2 0a f6 c8 1e a4 30 00000120: 70 42 07 c8 5e 97 08 69 12 27 58 c3 c7 b7 db 7a 00000130: 8c 50 3a 3a 5c bf 3a a7 73 40 8f 9c 18 f6 13 77 00000140: 63 c1 60 06 36 a1 43 ab 88 08 c9 cc ad f2 88 ca 00000150: 84 bd 45 e0 8e d9 27 a3 07 f2 63 79 b0 a8 62 9f 00000160: 5f ba dc a7 f5 54 b8 4f 4f bb 1e a2 16 4b 4f 2d 00000170: d4 08 4e 45 c2 c0 60 3b 73 df 6b 35 3a fe 38 2e 00000180: 25 75 fc be 89 4c d2 7a 9c 1f b4 41 a6 31 d3 3d 00000190: 39 a6 d1 c4 47 94 44 30 3a 2b 23 22 ba c0 a9 df 000001A0: dc 1c 90 8d d1 e8 13 f9 08 68 5a 94 98 c7 3f 47 000001B0: 77 79 b5 bb fb 22 56 4b 38 55 48 e8 14 d4 01 eb 000001C0: 63 e9 17 da 24 69 9a 6d dc 1e 25 06 ef 77 10 46 000001D0: ad 99 ad 9c 54 4f d4 68 64 ea 05 1d ef 29 ea 0e 000001E0: 3c 1c 7e 27 cf 59 76 42 5b 02 04 b8 (124) Computes ICV using K3r as K_msg (fragment 1) 00000000: 96 08 17 ed ef 01 4d a0 (125) Composes IV (fragment 1) 00000000: 00 00 00 00 00 00 00 00 (126) Composes MGM nonce (fragment 2) 00000000: 00 00 00 01 a5 bb 18 2f (127) Composes AAD (fragment 2) Smyslov Expires 9 June 2023 [Page 112] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 20 00 00 00 01 00 00 02 20 00 00 02 04 00000020: 00 02 00 04 (128) Composes plaintext (fragment 2) 00000000: 09 06 03 55 04 06 13 02 52 55 30 66 30 1f 06 08 00000010: 2a 85 03 07 01 01 01 01 30 13 06 07 2a 85 03 02 00000020: 02 24 00 06 08 2a 85 03 07 01 01 02 02 03 43 00 00000030: 04 40 5b b3 14 3e f4 70 c1 70 d7 f3 27 25 d8 53 00000040: 7c e6 de 6d 8c 29 f6 b2 32 64 56 dc b1 77 f2 3d 00000050: fa f4 2a 5c f3 74 86 7f 04 72 51 c1 cf b3 43 36 00000060: f5 95 a2 af 05 47 57 1a 55 c0 78 a4 9d 64 26 b8 00000070: 61 14 a3 82 02 59 30 82 02 55 30 0e 06 03 55 1d 00000080: 0f 01 01 ff 04 04 03 02 05 a0 30 13 06 03 55 1d 00000090: 25 04 0c 30 0a 06 08 2b 06 01 05 05 07 03 11 30 000000A0: 1d 06 03 55 1d 0e 04 16 04 14 e0 d3 f0 09 ad ce 000000B0: 6c a5 47 ba 9b f7 a6 a5 1b 06 14 ba a5 43 30 1f 000000C0: 06 03 55 1d 23 04 18 30 16 80 14 9b 85 5e fb 81 000000D0: dc 4d 59 07 51 63 cf be df da 2c 7f c9 44 3c 30 000000E0: 82 01 0f 06 03 55 1d 1f 04 82 01 06 30 82 01 02 000000F0: 30 81 ff a0 81 fc a0 81 f9 86 81 b5 68 74 74 70 00000100: 3a 2f 2f 74 65 73 74 67 6f 73 74 32 30 31 32 2e 00000110: 63 72 79 70 74 6f 70 72 6f 2e 72 75 2f 43 65 72 00000120: 74 45 6e 72 6f 6c 6c 2f 21 30 34 32 32 21 30 34 00000130: 33 35 21 30 34 34 31 21 30 34 34 32 21 30 34 33 00000140: 65 21 30 34 33 32 21 30 34 34 62 21 30 34 33 39 00000150: 25 32 30 21 30 34 32 33 21 30 34 32 36 25 32 30 00000160: 21 30 34 31 65 21 30 34 31 65 21 30 34 31 65 25 00000170: 32 30 21 30 30 32 32 21 30 34 31 61 21 30 34 32 00000180: 30 21 30 34 31 38 21 30 34 31 66 21 30 34 32 32 00000190: 21 30 34 31 65 2d 21 30 34 31 66 21 30 34 32 30 000001A0: 21 30 34 31 65 21 30 30 32 32 28 31 29 2e 63 72 000001B0: 6c 86 3f 68 74 74 70 3a 2f 2f 74 65 73 74 67 6f 000001C0: 73 74 32 30 31 32 2e 63 72 79 70 74 6f 70 72 6f 000001D0: 2e 72 75 2f 43 65 72 74 45 6e 72 6f 6c 6c 2f 74 000001E0: 65 73 74 67 6f 73 74 32 30 31 32 00 (129) Encrypts plaintext using K3r as K_msg, resulted in ciphertext (fragment 2) Smyslov Expires 9 June 2023 [Page 113] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: b1 c8 8d ae d9 6f 91 7e 5a 6a 2d 8c e0 d6 28 3e 00000010: 10 59 46 12 a1 1e fa 53 c3 58 ec 4e a9 a5 92 0c 00000020: fa 5e cf a3 33 4a 8b b7 56 66 54 d9 9c 64 2e b6 00000030: 4d 03 3f 77 a8 17 88 f6 23 e0 2e 56 a6 a2 4c 4d 00000040: 6e e3 09 8a 2e 31 a1 85 1c cf ce 95 e7 73 93 8e 00000050: 9c 5a 7b 3b 49 75 96 69 d4 b0 46 f7 74 b0 0d 5d 00000060: 91 3b 6d 2b a4 46 cc 5c d9 a8 38 c0 6b ad 73 35 00000070: 09 aa c7 4c 91 8a 84 1c dd 3f e1 44 f7 c5 9c 61 00000080: 0e b7 03 6b 84 cc 8e 93 5b d5 f6 7e 71 3a f4 2c 00000090: 98 14 ad 47 e3 c3 70 dc e3 3e c0 a5 e0 e4 6d 01 000000A0: 44 78 7f e3 b7 6c cb 44 29 59 96 e9 84 6d 9d 18 000000B0: 89 66 16 07 46 a4 cd 72 a6 0e bd d2 a7 1c f7 21 000000C0: f0 d1 67 a9 0d 1c c4 c8 30 bd 26 1f 53 7d 61 8b 000000D0: ad 6f ef 3e 2c 6e 7e 69 b9 92 72 66 65 b6 06 22 000000E0: 49 a1 a8 f1 2f 02 dd 41 bf f5 d1 f6 7c 93 25 6e 000000F0: 52 8b a9 3f b5 40 97 02 bb 7c f5 33 a6 60 52 b8 00000100: 4f 3e 80 6c 38 cf e4 8b 15 fd d0 66 75 c1 bf bb 00000110: ac fc ac 01 c3 11 8e 0b 3e e9 2c 1b 5d b9 9f f6 00000120: 2f d7 e8 3c c7 a9 25 8b aa 6e c6 49 6d 6f df 42 00000130: 53 0e ba 70 54 d2 af c3 4d 02 e1 48 42 c5 45 53 00000140: 25 59 66 25 c7 3c c6 c2 e2 99 e2 bb 47 a4 a7 be 00000150: 6c 92 0d 3b 4c ab 6e d7 23 05 ea 73 07 62 e8 c0 00000160: e8 78 47 af 54 c8 67 8f dd 32 59 8d 87 ac 42 0e 00000170: 21 15 c4 f7 66 dc 02 cf 55 c2 e3 4d 8e 91 7a fd 00000180: d7 4d 20 b0 6f 67 78 58 08 9c ba 05 8b b0 9c 16 00000190: 20 51 75 12 96 e2 d5 28 ac 3e 50 26 04 6f 59 02 000001A0: 28 e0 ec 2c da 70 4a 9c 15 5a 2e 52 01 e6 4e 1e 000001B0: 10 6d 8d 5d 2a 81 69 0e 54 d0 5e 13 82 82 84 9a 000001C0: ac a6 0e 69 4e 17 5c c1 8a 71 f8 b4 80 3b 7a e5 000001D0: b8 1f 09 4a 02 14 24 07 af 6a 14 d9 52 8e da d3 000001E0: 58 23 68 71 27 b2 9a 03 09 f7 80 51 (130) Computes ICV using K3r as K_msg (fragment 2) 00000000: 89 bd 07 12 fc 3f 15 8d (131) Composes IV (fragment 2) 00000000: 00 00 00 00 00 00 00 01 (132) Composes MGM nonce (fragment 3) 00000000: 00 00 00 02 a5 bb 18 2f (133) Composes AAD (fragment 3) Smyslov Expires 9 June 2023 [Page 114] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 20 00 00 00 01 00 00 02 20 00 00 02 04 00000020: 00 03 00 04 (134) Composes plaintext (fragment 3) 00000000: 28 31 29 2e 63 72 6c 30 81 da 06 08 2b 06 01 05 00000010: 05 07 01 01 04 81 cd 30 81 ca 30 44 06 08 2b 06 00000020: 01 05 05 07 30 02 86 38 68 74 74 70 3a 2f 2f 74 00000030: 65 73 74 67 6f 73 74 32 30 31 32 2e 63 72 79 70 00000040: 74 6f 70 72 6f 2e 72 75 2f 43 65 72 74 45 6e 72 00000050: 6f 6c 6c 2f 72 6f 6f 74 32 30 31 38 2e 63 72 74 00000060: 30 3f 06 08 2b 06 01 05 05 07 30 01 86 33 68 74 00000070: 74 70 3a 2f 2f 74 65 73 74 67 6f 73 74 32 30 31 00000080: 32 2e 63 72 79 70 74 6f 70 72 6f 2e 72 75 2f 6f 00000090: 63 73 70 32 30 31 32 67 2f 6f 63 73 70 2e 73 72 000000A0: 66 30 41 06 08 2b 06 01 05 05 07 30 01 86 35 68 000000B0: 74 74 70 3a 2f 2f 74 65 73 74 67 6f 73 74 32 30 000000C0: 31 32 2e 63 72 79 70 74 6f 70 72 6f 2e 72 75 2f 000000D0: 6f 63 73 70 32 30 31 32 67 73 74 2f 6f 63 73 70 000000E0: 2e 73 72 66 30 0a 06 08 2a 85 03 07 01 01 03 02 000000F0: 03 41 00 a5 39 5f ca 48 e1 c2 93 c1 e0 8a 64 74 00000100: 0f 6b 86 a2 15 9b 46 29 d0 42 71 4f ce e7 52 d7 00000110: d7 3d aa 47 ce cf 52 63 8f 26 b2 17 5f ad 96 57 00000120: 76 ea 5f d0 87 bb 12 29 e4 06 0e e1 5f fd 59 81 00000130: fb 34 6d 29 00 00 55 0e 00 00 00 0c 30 0a 06 08 00000140: 2a 85 03 07 01 01 03 02 c8 40 af f7 46 6f 7b eb 00000150: d2 b9 1c 5a 80 d0 00 93 c2 5e 44 16 40 47 f7 8e 00000160: 61 9c da a5 16 94 83 c5 68 5f e8 4d 03 e7 c2 cd 00000170: 08 07 b8 f3 46 66 6d 05 76 c0 d5 e7 60 1d 59 49 00000180: 09 45 52 c4 95 a7 5a d3 29 00 00 08 00 00 40 00 00000190: 2f 00 00 0c 00 00 40 01 00 00 00 40 21 00 00 10 000001A0: 02 00 00 00 00 01 00 04 0a 01 01 03 2c 00 00 20 000001B0: 00 00 00 1c 01 03 04 02 34 ff 8a 25 03 00 00 08 000001C0: 01 00 00 21 00 00 00 08 05 00 00 00 2d 00 00 18 000001D0: 01 00 00 00 07 00 00 10 00 00 ff ff 0a 01 01 03 000001E0: 0a 01 01 03 29 00 00 18 01 00 00 00 (135) Encrypts plaintext using K3r as K_msg, resulted in ciphertext (fragment 3) Smyslov Expires 9 June 2023 [Page 115] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 08 e0 86 04 1f 8a c9 b5 68 cd 96 10 ab 59 99 3a 00000010: 54 7b a9 fa d7 60 46 ec c3 bf bd 8f fa 03 ed 41 00000020: 49 13 ca 8c 9c b8 0c df 81 25 e2 30 ca cb 65 b9 00000030: 16 55 8e 67 f4 b3 7c b8 91 66 76 7c a4 15 98 a3 00000040: 3a c9 48 64 e4 ce 9f 64 67 5d bb 7c 03 23 9e c9 00000050: 81 3f da 48 ee a6 2a d8 fb ac 77 ce ed c2 a4 d9 00000060: 24 d3 71 99 fc 71 2b 6c 10 d3 c3 4b b5 37 e2 55 00000070: 5f d5 ee c0 d6 ff 66 15 8c e5 63 26 96 cd 3f 49 00000080: 2b da 51 94 55 6e 2e e5 2e d1 b4 91 81 50 85 8a 00000090: 84 bd fe 52 ec ce 1b 6b bd 7d 12 b4 de a5 88 c4 000000A0: b7 78 d3 3d 2d 46 ef dc 0f 91 43 be 08 7a ba fa 000000B0: b3 2a c2 17 30 99 79 ae 3a 00 f0 3f 47 4a 9b 11 000000C0: 4d 7b 1b 28 0a 44 5b 1a af 35 4d c3 2b 6b be 11 000000D0: 89 03 b9 de cf 37 57 53 1e a4 f3 3f ce 52 a6 d8 000000E0: 7e 9d d8 d4 2f 9f f5 8f 3c c6 cb 2f 56 e0 97 2d 000000F0: b2 0e 10 66 3b 3c ec 34 50 99 a3 7d 42 ec 96 eb 00000100: 87 48 72 2c 0a 6d af b9 4b 62 48 89 36 01 21 ab 00000110: 8e 79 10 54 9c 83 ab a9 8a 6c 37 c7 ac dc a1 7e 00000120: 41 0e 58 de da aa 95 71 fb 34 50 8a ef 37 0b c4 00000130: 56 ca 4b 2c 75 b7 c7 d9 74 22 c2 65 1a e4 4f 94 00000140: 20 f6 e9 44 f1 69 5e d2 18 d3 30 2e 85 74 25 be 00000150: 2a 88 e2 ce fe 75 ca fa 25 f9 2e 88 8c ed 6f dd 00000160: c3 c5 53 2e da 14 fd 96 28 4a b7 81 3a b3 d5 44 00000170: 26 e2 84 21 f2 5c 0a ed bf c4 34 1c a4 91 5e f3 00000180: 47 ef 0e 9e fb ee 34 95 5d 21 72 43 c9 63 af b4 00000190: f2 98 4a 36 57 77 fc e7 57 52 b2 4d bf 34 2a 98 000001A0: ea 70 cd d7 a9 da 4c 0d 19 05 d4 1e dd 36 c7 c4 000001B0: 31 54 18 2a ef 0e 30 44 97 31 15 57 cd d4 88 52 000001C0: 4e 42 c8 20 89 8d 35 7b 8e 03 96 b4 74 fb ec 3b 000001D0: 14 c2 64 49 92 f2 1f 3d ff 84 2d 92 4c b9 01 04 000001E0: 3d 0a 2a 28 33 de 43 44 6b cf 79 0e (136) Computes ICV using K3r as K_msg (fragment 3) 00000000: 7d 7c 57 8f 91 d0 c9 eb (137) Composes IV (fragment 3) 00000000: 00 00 00 00 00 00 00 02 (138) Composes MGM nonce (fragment 4) 00000000: 00 00 00 03 a5 bb 18 2f (139) Composes AAD (fragment 4) Smyslov Expires 9 June 2023 [Page 116] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 20 00 00 00 01 00 00 00 5e 00 00 00 42 00000020: 00 04 00 04 (140) Composes plaintext (fragment 4) 00000000: 00 07 00 00 10 00 00 ff ff 0a 00 00 00 0a 00 00 00000010: ff 29 00 00 08 00 00 40 02 29 00 00 08 00 00 40 00000020: 0a 00 00 00 08 00 00 40 0b 00 (141) Encrypts plaintext using K3r as K_msg, resulted in ciphertext (fragment 4) 00000000: 81 fa 5d 7a 67 13 b7 93 f4 2c 01 b8 d1 02 8c ab 00000010: 8e 80 47 25 6e c5 69 e3 0c 84 cd 35 9a 0f 7a cc 00000020: 0a 92 7a 74 77 dc ba 60 ac 4a (142) Computes ICV using K3r as K_msg (fragment 4) 00000000: 6c 27 70 e0 8a 82 bd 4b (143) Composes IV (fragment 4) 00000000: 00 00 00 00 00 00 00 03 (144) Sends message fragment (1) , peer receives message fragment (1) Smyslov Expires 9 June 2023 [Page 117] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54295<-10.111.15.45:4500 [548] 00000000: 00 00 00 00 92 80 e0 82 2e 75 87 78 db 57 8d 97 00000010: de 11 9d 1e 35 20 23 20 00 00 00 01 00 00 02 20 00000020: 24 00 02 04 00 01 00 04 00 00 00 00 00 00 00 00 00000030: 73 f2 45 3e fb 6a 26 28 67 7d 14 e3 bf 0a 90 74 00000040: c9 95 6a 40 d5 4e a6 77 cf 58 2e b8 ae 52 f4 25 00000050: f7 82 bc d9 f0 74 4e 38 51 90 07 70 27 f8 01 27 00000060: 17 da f4 ba bc 1e 02 0b 73 ec cc 7b f8 b3 68 64 00000070: f3 48 65 33 3b ab ac 19 11 d3 f7 78 b4 f8 d1 3f 00000080: 6d 46 93 37 a6 58 48 3a 7d d0 8a 9c 84 ab de eb 00000090: 0d d4 8d ab 75 20 18 27 42 fe 24 ee ba c4 a4 6e 000000A0: db 80 68 3c 84 7e d6 36 50 d4 1b 1c bc c5 9f 18 000000B0: 41 af 48 52 c1 7e a2 f0 e4 bc 0a 3c 64 34 81 ca 000000C0: df 96 ba 51 91 f1 06 13 b2 04 23 c8 70 3a ea 64 000000D0: e9 ea ce c2 db aa 12 90 28 0c 9d f9 89 02 a8 5e 000000E0: 66 f5 6e ce dd e7 2c 4a 45 54 de 5e b8 76 73 67 000000F0: 2d a3 a0 52 91 74 ff b7 eb e4 ea d1 2b 04 76 f7 00000100: ff 4b 1c b8 45 7e 8a 60 e7 1e ec 13 3e c1 d8 d0 00000110: 78 be f4 79 77 06 ce 76 04 64 ad e7 10 19 65 2b 00000120: 45 66 23 3d 34 7a 40 6c 36 c0 20 73 47 d8 7a b6 00000130: 2b 0f 56 04 7a c0 41 ab 18 23 11 78 7f 4f d4 f5 00000140: 7d 2e 06 a5 15 ee de 84 9f c2 0a f6 c8 1e a4 30 00000150: 70 42 07 c8 5e 97 08 69 12 27 58 c3 c7 b7 db 7a 00000160: 8c 50 3a 3a 5c bf 3a a7 73 40 8f 9c 18 f6 13 77 00000170: 63 c1 60 06 36 a1 43 ab 88 08 c9 cc ad f2 88 ca 00000180: 84 bd 45 e0 8e d9 27 a3 07 f2 63 79 b0 a8 62 9f 00000190: 5f ba dc a7 f5 54 b8 4f 4f bb 1e a2 16 4b 4f 2d 000001A0: d4 08 4e 45 c2 c0 60 3b 73 df 6b 35 3a fe 38 2e 000001B0: 25 75 fc be 89 4c d2 7a 9c 1f b4 41 a6 31 d3 3d 000001C0: 39 a6 d1 c4 47 94 44 30 3a 2b 23 22 ba c0 a9 df 000001D0: dc 1c 90 8d d1 e8 13 f9 08 68 5a 94 98 c7 3f 47 000001E0: 77 79 b5 bb fb 22 56 4b 38 55 48 e8 14 d4 01 eb 000001F0: 63 e9 17 da 24 69 9a 6d dc 1e 25 06 ef 77 10 46 00000200: ad 99 ad 9c 54 4f d4 68 64 ea 05 1d ef 29 ea 0e 00000210: 3c 1c 7e 27 cf 59 76 42 5b 02 04 b8 96 08 17 ed 00000220: ef 01 4d a0 (145) Sends message fragment (2) , peer receives message fragment (2) Smyslov Expires 9 June 2023 [Page 118] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54295<-10.111.15.45:4500 [548] 00000000: 00 00 00 00 92 80 e0 82 2e 75 87 78 db 57 8d 97 00000010: de 11 9d 1e 35 20 23 20 00 00 00 01 00 00 02 20 00000020: 00 00 02 04 00 02 00 04 00 00 00 00 00 00 00 01 00000030: b1 c8 8d ae d9 6f 91 7e 5a 6a 2d 8c e0 d6 28 3e 00000040: 10 59 46 12 a1 1e fa 53 c3 58 ec 4e a9 a5 92 0c 00000050: fa 5e cf a3 33 4a 8b b7 56 66 54 d9 9c 64 2e b6 00000060: 4d 03 3f 77 a8 17 88 f6 23 e0 2e 56 a6 a2 4c 4d 00000070: 6e e3 09 8a 2e 31 a1 85 1c cf ce 95 e7 73 93 8e 00000080: 9c 5a 7b 3b 49 75 96 69 d4 b0 46 f7 74 b0 0d 5d 00000090: 91 3b 6d 2b a4 46 cc 5c d9 a8 38 c0 6b ad 73 35 000000A0: 09 aa c7 4c 91 8a 84 1c dd 3f e1 44 f7 c5 9c 61 000000B0: 0e b7 03 6b 84 cc 8e 93 5b d5 f6 7e 71 3a f4 2c 000000C0: 98 14 ad 47 e3 c3 70 dc e3 3e c0 a5 e0 e4 6d 01 000000D0: 44 78 7f e3 b7 6c cb 44 29 59 96 e9 84 6d 9d 18 000000E0: 89 66 16 07 46 a4 cd 72 a6 0e bd d2 a7 1c f7 21 000000F0: f0 d1 67 a9 0d 1c c4 c8 30 bd 26 1f 53 7d 61 8b 00000100: ad 6f ef 3e 2c 6e 7e 69 b9 92 72 66 65 b6 06 22 00000110: 49 a1 a8 f1 2f 02 dd 41 bf f5 d1 f6 7c 93 25 6e 00000120: 52 8b a9 3f b5 40 97 02 bb 7c f5 33 a6 60 52 b8 00000130: 4f 3e 80 6c 38 cf e4 8b 15 fd d0 66 75 c1 bf bb 00000140: ac fc ac 01 c3 11 8e 0b 3e e9 2c 1b 5d b9 9f f6 00000150: 2f d7 e8 3c c7 a9 25 8b aa 6e c6 49 6d 6f df 42 00000160: 53 0e ba 70 54 d2 af c3 4d 02 e1 48 42 c5 45 53 00000170: 25 59 66 25 c7 3c c6 c2 e2 99 e2 bb 47 a4 a7 be 00000180: 6c 92 0d 3b 4c ab 6e d7 23 05 ea 73 07 62 e8 c0 00000190: e8 78 47 af 54 c8 67 8f dd 32 59 8d 87 ac 42 0e 000001A0: 21 15 c4 f7 66 dc 02 cf 55 c2 e3 4d 8e 91 7a fd 000001B0: d7 4d 20 b0 6f 67 78 58 08 9c ba 05 8b b0 9c 16 000001C0: 20 51 75 12 96 e2 d5 28 ac 3e 50 26 04 6f 59 02 000001D0: 28 e0 ec 2c da 70 4a 9c 15 5a 2e 52 01 e6 4e 1e 000001E0: 10 6d 8d 5d 2a 81 69 0e 54 d0 5e 13 82 82 84 9a 000001F0: ac a6 0e 69 4e 17 5c c1 8a 71 f8 b4 80 3b 7a e5 00000200: b8 1f 09 4a 02 14 24 07 af 6a 14 d9 52 8e da d3 00000210: 58 23 68 71 27 b2 9a 03 09 f7 80 51 89 bd 07 12 00000220: fc 3f 15 8d (146) Sends message fragment (3) , peer receives message fragment (3) Smyslov Expires 9 June 2023 [Page 119] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54295<-10.111.15.45:4500 [548] 00000000: 00 00 00 00 92 80 e0 82 2e 75 87 78 db 57 8d 97 00000010: de 11 9d 1e 35 20 23 20 00 00 00 01 00 00 02 20 00000020: 00 00 02 04 00 03 00 04 00 00 00 00 00 00 00 02 00000030: 08 e0 86 04 1f 8a c9 b5 68 cd 96 10 ab 59 99 3a 00000040: 54 7b a9 fa d7 60 46 ec c3 bf bd 8f fa 03 ed 41 00000050: 49 13 ca 8c 9c b8 0c df 81 25 e2 30 ca cb 65 b9 00000060: 16 55 8e 67 f4 b3 7c b8 91 66 76 7c a4 15 98 a3 00000070: 3a c9 48 64 e4 ce 9f 64 67 5d bb 7c 03 23 9e c9 00000080: 81 3f da 48 ee a6 2a d8 fb ac 77 ce ed c2 a4 d9 00000090: 24 d3 71 99 fc 71 2b 6c 10 d3 c3 4b b5 37 e2 55 000000A0: 5f d5 ee c0 d6 ff 66 15 8c e5 63 26 96 cd 3f 49 000000B0: 2b da 51 94 55 6e 2e e5 2e d1 b4 91 81 50 85 8a 000000C0: 84 bd fe 52 ec ce 1b 6b bd 7d 12 b4 de a5 88 c4 000000D0: b7 78 d3 3d 2d 46 ef dc 0f 91 43 be 08 7a ba fa 000000E0: b3 2a c2 17 30 99 79 ae 3a 00 f0 3f 47 4a 9b 11 000000F0: 4d 7b 1b 28 0a 44 5b 1a af 35 4d c3 2b 6b be 11 00000100: 89 03 b9 de cf 37 57 53 1e a4 f3 3f ce 52 a6 d8 00000110: 7e 9d d8 d4 2f 9f f5 8f 3c c6 cb 2f 56 e0 97 2d 00000120: b2 0e 10 66 3b 3c ec 34 50 99 a3 7d 42 ec 96 eb 00000130: 87 48 72 2c 0a 6d af b9 4b 62 48 89 36 01 21 ab 00000140: 8e 79 10 54 9c 83 ab a9 8a 6c 37 c7 ac dc a1 7e 00000150: 41 0e 58 de da aa 95 71 fb 34 50 8a ef 37 0b c4 00000160: 56 ca 4b 2c 75 b7 c7 d9 74 22 c2 65 1a e4 4f 94 00000170: 20 f6 e9 44 f1 69 5e d2 18 d3 30 2e 85 74 25 be 00000180: 2a 88 e2 ce fe 75 ca fa 25 f9 2e 88 8c ed 6f dd 00000190: c3 c5 53 2e da 14 fd 96 28 4a b7 81 3a b3 d5 44 000001A0: 26 e2 84 21 f2 5c 0a ed bf c4 34 1c a4 91 5e f3 000001B0: 47 ef 0e 9e fb ee 34 95 5d 21 72 43 c9 63 af b4 000001C0: f2 98 4a 36 57 77 fc e7 57 52 b2 4d bf 34 2a 98 000001D0: ea 70 cd d7 a9 da 4c 0d 19 05 d4 1e dd 36 c7 c4 000001E0: 31 54 18 2a ef 0e 30 44 97 31 15 57 cd d4 88 52 000001F0: 4e 42 c8 20 89 8d 35 7b 8e 03 96 b4 74 fb ec 3b 00000200: 14 c2 64 49 92 f2 1f 3d ff 84 2d 92 4c b9 01 04 00000210: 3d 0a 2a 28 33 de 43 44 6b cf 79 0e 7d 7c 57 8f 00000220: 91 d0 c9 eb (147) Sends message fragment (4) , peer receives message fragment (4) Smyslov Expires 9 June 2023 [Page 120] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54295<-10.111.15.45:4500 [98] 00000000: 00 00 00 00 92 80 e0 82 2e 75 87 78 db 57 8d 97 00000010: de 11 9d 1e 35 20 23 20 00 00 00 01 00 00 00 5e 00000020: 00 00 00 42 00 04 00 04 00 00 00 00 00 00 00 03 00000030: 81 fa 5d 7a 67 13 b7 93 f4 2c 01 b8 d1 02 8c ab 00000040: 8e 80 47 25 6e c5 69 e3 0c 84 cd 35 9a 0f 7a cc 00000050: 0a 92 7a 74 77 dc ba 60 ac 4a 6c 27 70 e0 8a 82 00000060: bd 4b Initiator's actions: (148) Extracts IV from message (fragment 1) 00000000: 00 00 00 00 00 00 00 00 (149) Computes K1r (i1 = 0) 00000000: 35 e4 d1 65 2e ec 24 89 e4 c9 58 b1 b9 05 1b 83 00000010: 62 5e 65 d7 61 73 d9 1c cf 84 60 64 b9 f2 e7 51 (150) Computes K2r (i2 = 0) 00000000: 86 8c 89 42 41 d7 30 da 1a 4a 67 69 3a 32 4d 38 00000010: f3 54 02 9f f7 7d b7 bc 5a ee 3b 60 2b 3f 05 56 (151) Computes K3r (i3 = 0) 00000000: 31 95 e8 c6 67 af 42 d8 ce f1 e8 99 c6 8b 2a c2 00000010: 29 aa 3d c0 ff 18 5f 3d 79 4a 14 6b 9f ac d0 bb (152) Composes MGM nonce (fragment 1) 00000000: 00 00 00 00 a5 bb 18 2f (153) Extracts ICV from message (fragment 1) 00000000: 96 08 17 ed ef 01 4d a0 (154) Extracts AAD from message (fragment 1) 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 20 00 00 00 01 00 00 02 20 24 00 02 04 00000020: 00 01 00 04 (155) Extracts ciphertext from message (fragment 1) Smyslov Expires 9 June 2023 [Page 121] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 73 f2 45 3e fb 6a 26 28 67 7d 14 e3 bf 0a 90 74 00000010: c9 95 6a 40 d5 4e a6 77 cf 58 2e b8 ae 52 f4 25 00000020: f7 82 bc d9 f0 74 4e 38 51 90 07 70 27 f8 01 27 00000030: 17 da f4 ba bc 1e 02 0b 73 ec cc 7b f8 b3 68 64 00000040: f3 48 65 33 3b ab ac 19 11 d3 f7 78 b4 f8 d1 3f 00000050: 6d 46 93 37 a6 58 48 3a 7d d0 8a 9c 84 ab de eb 00000060: 0d d4 8d ab 75 20 18 27 42 fe 24 ee ba c4 a4 6e 00000070: db 80 68 3c 84 7e d6 36 50 d4 1b 1c bc c5 9f 18 00000080: 41 af 48 52 c1 7e a2 f0 e4 bc 0a 3c 64 34 81 ca 00000090: df 96 ba 51 91 f1 06 13 b2 04 23 c8 70 3a ea 64 000000A0: e9 ea ce c2 db aa 12 90 28 0c 9d f9 89 02 a8 5e 000000B0: 66 f5 6e ce dd e7 2c 4a 45 54 de 5e b8 76 73 67 000000C0: 2d a3 a0 52 91 74 ff b7 eb e4 ea d1 2b 04 76 f7 000000D0: ff 4b 1c b8 45 7e 8a 60 e7 1e ec 13 3e c1 d8 d0 000000E0: 78 be f4 79 77 06 ce 76 04 64 ad e7 10 19 65 2b 000000F0: 45 66 23 3d 34 7a 40 6c 36 c0 20 73 47 d8 7a b6 00000100: 2b 0f 56 04 7a c0 41 ab 18 23 11 78 7f 4f d4 f5 00000110: 7d 2e 06 a5 15 ee de 84 9f c2 0a f6 c8 1e a4 30 00000120: 70 42 07 c8 5e 97 08 69 12 27 58 c3 c7 b7 db 7a 00000130: 8c 50 3a 3a 5c bf 3a a7 73 40 8f 9c 18 f6 13 77 00000140: 63 c1 60 06 36 a1 43 ab 88 08 c9 cc ad f2 88 ca 00000150: 84 bd 45 e0 8e d9 27 a3 07 f2 63 79 b0 a8 62 9f 00000160: 5f ba dc a7 f5 54 b8 4f 4f bb 1e a2 16 4b 4f 2d 00000170: d4 08 4e 45 c2 c0 60 3b 73 df 6b 35 3a fe 38 2e 00000180: 25 75 fc be 89 4c d2 7a 9c 1f b4 41 a6 31 d3 3d 00000190: 39 a6 d1 c4 47 94 44 30 3a 2b 23 22 ba c0 a9 df 000001A0: dc 1c 90 8d d1 e8 13 f9 08 68 5a 94 98 c7 3f 47 000001B0: 77 79 b5 bb fb 22 56 4b 38 55 48 e8 14 d4 01 eb 000001C0: 63 e9 17 da 24 69 9a 6d dc 1e 25 06 ef 77 10 46 000001D0: ad 99 ad 9c 54 4f d4 68 64 ea 05 1d ef 29 ea 0e 000001E0: 3c 1c 7e 27 cf 59 76 42 5b 02 04 b8 (156) Decrypts ciphertext and verifies ICV using K3r as K_msg, resulted in plaintext (fragment 1) Smyslov Expires 9 June 2023 [Page 122] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 25 00 00 4e 09 00 00 00 30 44 31 20 30 1e 06 03 00000010: 55 04 03 13 17 49 4b 45 20 49 6e 74 65 72 6f 70 00000020: 20 54 65 73 74 20 53 65 72 76 65 72 31 13 30 11 00000030: 06 03 55 04 0a 13 0a 45 4c 56 49 53 2d 50 4c 55 00000040: 53 31 0b 30 09 06 03 55 04 06 13 02 52 55 27 00 00000050: 04 bb 04 30 82 04 b2 30 82 04 5f a0 03 02 01 02 00000060: 02 13 7c 00 03 d9 02 ec f9 34 3e c8 aa d6 59 00 00000070: 01 00 03 d9 02 30 0a 06 08 2a 85 03 07 01 01 03 00000080: 02 30 82 01 0a 31 18 30 16 06 05 2a 85 03 64 01 00000090: 12 0d 31 32 33 34 35 36 37 38 39 30 31 32 33 31 000000A0: 1a 30 18 06 08 2a 85 03 03 81 03 01 01 12 0c 30 000000B0: 30 31 32 33 34 35 36 37 38 39 30 31 2f 30 2d 06 000000C0: 03 55 04 09 0c 26 d1 83 d0 bb 2e 20 d0 a1 d1 83 000000D0: d1 89 d1 91 d0 b2 d1 81 d0 ba d0 b8 d0 b9 20 d0 000000E0: b2 d0 b0 d0 bb 20 d0 b4 2e 20 31 38 31 0b 30 09 000000F0: 06 03 55 04 06 13 02 52 55 31 19 30 17 06 03 55 00000100: 04 08 0c 10 d0 b3 2e 20 d0 9c d0 be d1 81 d0 ba 00000110: d0 b2 d0 b0 31 15 30 13 06 03 55 04 07 0c 0c d0 00000120: 9c d0 be d1 81 d0 ba d0 b2 d0 b0 31 25 30 23 06 00000130: 03 55 04 0a 0c 1c d0 9e d0 9e d0 9e 20 22 d0 9a 00000140: d0 a0 d0 98 d0 9f d0 a2 d0 9e 2d d0 9f d0 a0 d0 00000150: 9e 22 31 3b 30 39 06 03 55 04 03 0c 32 d0 a2 d0 00000160: b5 d1 81 d1 82 d0 be d0 b2 d1 8b d0 b9 20 d0 a3 00000170: d0 a6 20 d0 9e d0 9e d0 9e 20 22 d0 9a d0 a0 d0 00000180: 98 d0 9f d0 a2 d0 9e 2d d0 9f d0 a0 d0 9e 22 30 00000190: 1e 17 0d 32 31 30 39 33 30 31 33 32 34 30 36 5a 000001A0: 17 0d 32 31 31 32 33 30 31 33 33 34 30 36 5a 30 000001B0: 44 31 20 30 1e 06 03 55 04 03 13 17 49 4b 45 20 000001C0: 49 6e 74 65 72 6f 70 20 54 65 73 74 20 53 65 72 000001D0: 76 65 72 31 13 30 11 06 03 55 04 0a 13 0a 45 4c 000001E0: 56 49 53 2d 50 4c 55 53 31 0b 30 00 (157) Extracts IV from message (fragment 2) 00000000: 00 00 00 00 00 00 00 01 (158) Uses previously computed key K3r 00000000: 31 95 e8 c6 67 af 42 d8 ce f1 e8 99 c6 8b 2a c2 00000010: 29 aa 3d c0 ff 18 5f 3d 79 4a 14 6b 9f ac d0 bb (159) Composes MGM nonce (fragment 2) 00000000: 00 00 00 01 a5 bb 18 2f (160) Extracts ICV from message (fragment 2) 00000000: 89 bd 07 12 fc 3f 15 8d Smyslov Expires 9 June 2023 [Page 123] Internet-Draft GOST algorithms in IKEv2 December 2022 (161) Extracts AAD from message (fragment 2) 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 20 00 00 00 01 00 00 02 20 00 00 02 04 00000020: 00 02 00 04 (162) Extracts ciphertext from message (fragment 2) 00000000: b1 c8 8d ae d9 6f 91 7e 5a 6a 2d 8c e0 d6 28 3e 00000010: 10 59 46 12 a1 1e fa 53 c3 58 ec 4e a9 a5 92 0c 00000020: fa 5e cf a3 33 4a 8b b7 56 66 54 d9 9c 64 2e b6 00000030: 4d 03 3f 77 a8 17 88 f6 23 e0 2e 56 a6 a2 4c 4d 00000040: 6e e3 09 8a 2e 31 a1 85 1c cf ce 95 e7 73 93 8e 00000050: 9c 5a 7b 3b 49 75 96 69 d4 b0 46 f7 74 b0 0d 5d 00000060: 91 3b 6d 2b a4 46 cc 5c d9 a8 38 c0 6b ad 73 35 00000070: 09 aa c7 4c 91 8a 84 1c dd 3f e1 44 f7 c5 9c 61 00000080: 0e b7 03 6b 84 cc 8e 93 5b d5 f6 7e 71 3a f4 2c 00000090: 98 14 ad 47 e3 c3 70 dc e3 3e c0 a5 e0 e4 6d 01 000000A0: 44 78 7f e3 b7 6c cb 44 29 59 96 e9 84 6d 9d 18 000000B0: 89 66 16 07 46 a4 cd 72 a6 0e bd d2 a7 1c f7 21 000000C0: f0 d1 67 a9 0d 1c c4 c8 30 bd 26 1f 53 7d 61 8b 000000D0: ad 6f ef 3e 2c 6e 7e 69 b9 92 72 66 65 b6 06 22 000000E0: 49 a1 a8 f1 2f 02 dd 41 bf f5 d1 f6 7c 93 25 6e 000000F0: 52 8b a9 3f b5 40 97 02 bb 7c f5 33 a6 60 52 b8 00000100: 4f 3e 80 6c 38 cf e4 8b 15 fd d0 66 75 c1 bf bb 00000110: ac fc ac 01 c3 11 8e 0b 3e e9 2c 1b 5d b9 9f f6 00000120: 2f d7 e8 3c c7 a9 25 8b aa 6e c6 49 6d 6f df 42 00000130: 53 0e ba 70 54 d2 af c3 4d 02 e1 48 42 c5 45 53 00000140: 25 59 66 25 c7 3c c6 c2 e2 99 e2 bb 47 a4 a7 be 00000150: 6c 92 0d 3b 4c ab 6e d7 23 05 ea 73 07 62 e8 c0 00000160: e8 78 47 af 54 c8 67 8f dd 32 59 8d 87 ac 42 0e 00000170: 21 15 c4 f7 66 dc 02 cf 55 c2 e3 4d 8e 91 7a fd 00000180: d7 4d 20 b0 6f 67 78 58 08 9c ba 05 8b b0 9c 16 00000190: 20 51 75 12 96 e2 d5 28 ac 3e 50 26 04 6f 59 02 000001A0: 28 e0 ec 2c da 70 4a 9c 15 5a 2e 52 01 e6 4e 1e 000001B0: 10 6d 8d 5d 2a 81 69 0e 54 d0 5e 13 82 82 84 9a 000001C0: ac a6 0e 69 4e 17 5c c1 8a 71 f8 b4 80 3b 7a e5 000001D0: b8 1f 09 4a 02 14 24 07 af 6a 14 d9 52 8e da d3 000001E0: 58 23 68 71 27 b2 9a 03 09 f7 80 51 (163) Decrypts ciphertext and verifies ICV using K3r as K_msg, resulted in plaintext (fragment 2) Smyslov Expires 9 June 2023 [Page 124] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 09 06 03 55 04 06 13 02 52 55 30 66 30 1f 06 08 00000010: 2a 85 03 07 01 01 01 01 30 13 06 07 2a 85 03 02 00000020: 02 24 00 06 08 2a 85 03 07 01 01 02 02 03 43 00 00000030: 04 40 5b b3 14 3e f4 70 c1 70 d7 f3 27 25 d8 53 00000040: 7c e6 de 6d 8c 29 f6 b2 32 64 56 dc b1 77 f2 3d 00000050: fa f4 2a 5c f3 74 86 7f 04 72 51 c1 cf b3 43 36 00000060: f5 95 a2 af 05 47 57 1a 55 c0 78 a4 9d 64 26 b8 00000070: 61 14 a3 82 02 59 30 82 02 55 30 0e 06 03 55 1d 00000080: 0f 01 01 ff 04 04 03 02 05 a0 30 13 06 03 55 1d 00000090: 25 04 0c 30 0a 06 08 2b 06 01 05 05 07 03 11 30 000000A0: 1d 06 03 55 1d 0e 04 16 04 14 e0 d3 f0 09 ad ce 000000B0: 6c a5 47 ba 9b f7 a6 a5 1b 06 14 ba a5 43 30 1f 000000C0: 06 03 55 1d 23 04 18 30 16 80 14 9b 85 5e fb 81 000000D0: dc 4d 59 07 51 63 cf be df da 2c 7f c9 44 3c 30 000000E0: 82 01 0f 06 03 55 1d 1f 04 82 01 06 30 82 01 02 000000F0: 30 81 ff a0 81 fc a0 81 f9 86 81 b5 68 74 74 70 00000100: 3a 2f 2f 74 65 73 74 67 6f 73 74 32 30 31 32 2e 00000110: 63 72 79 70 74 6f 70 72 6f 2e 72 75 2f 43 65 72 00000120: 74 45 6e 72 6f 6c 6c 2f 21 30 34 32 32 21 30 34 00000130: 33 35 21 30 34 34 31 21 30 34 34 32 21 30 34 33 00000140: 65 21 30 34 33 32 21 30 34 34 62 21 30 34 33 39 00000150: 25 32 30 21 30 34 32 33 21 30 34 32 36 25 32 30 00000160: 21 30 34 31 65 21 30 34 31 65 21 30 34 31 65 25 00000170: 32 30 21 30 30 32 32 21 30 34 31 61 21 30 34 32 00000180: 30 21 30 34 31 38 21 30 34 31 66 21 30 34 32 32 00000190: 21 30 34 31 65 2d 21 30 34 31 66 21 30 34 32 30 000001A0: 21 30 34 31 65 21 30 30 32 32 28 31 29 2e 63 72 000001B0: 6c 86 3f 68 74 74 70 3a 2f 2f 74 65 73 74 67 6f 000001C0: 73 74 32 30 31 32 2e 63 72 79 70 74 6f 70 72 6f 000001D0: 2e 72 75 2f 43 65 72 74 45 6e 72 6f 6c 6c 2f 74 000001E0: 65 73 74 67 6f 73 74 32 30 31 32 00 (164) Extracts IV from message (fragment 3) 00000000: 00 00 00 00 00 00 00 02 (165) Uses previously computed key K3r 00000000: 31 95 e8 c6 67 af 42 d8 ce f1 e8 99 c6 8b 2a c2 00000010: 29 aa 3d c0 ff 18 5f 3d 79 4a 14 6b 9f ac d0 bb (166) Composes MGM nonce (fragment 3) 00000000: 00 00 00 02 a5 bb 18 2f (167) Extracts ICV from message (fragment 3) 00000000: 7d 7c 57 8f 91 d0 c9 eb Smyslov Expires 9 June 2023 [Page 125] Internet-Draft GOST algorithms in IKEv2 December 2022 (168) Extracts AAD from message (fragment 3) 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 20 00 00 00 01 00 00 02 20 00 00 02 04 00000020: 00 03 00 04 (169) Extracts ciphertext from message (fragment 3) 00000000: 08 e0 86 04 1f 8a c9 b5 68 cd 96 10 ab 59 99 3a 00000010: 54 7b a9 fa d7 60 46 ec c3 bf bd 8f fa 03 ed 41 00000020: 49 13 ca 8c 9c b8 0c df 81 25 e2 30 ca cb 65 b9 00000030: 16 55 8e 67 f4 b3 7c b8 91 66 76 7c a4 15 98 a3 00000040: 3a c9 48 64 e4 ce 9f 64 67 5d bb 7c 03 23 9e c9 00000050: 81 3f da 48 ee a6 2a d8 fb ac 77 ce ed c2 a4 d9 00000060: 24 d3 71 99 fc 71 2b 6c 10 d3 c3 4b b5 37 e2 55 00000070: 5f d5 ee c0 d6 ff 66 15 8c e5 63 26 96 cd 3f 49 00000080: 2b da 51 94 55 6e 2e e5 2e d1 b4 91 81 50 85 8a 00000090: 84 bd fe 52 ec ce 1b 6b bd 7d 12 b4 de a5 88 c4 000000A0: b7 78 d3 3d 2d 46 ef dc 0f 91 43 be 08 7a ba fa 000000B0: b3 2a c2 17 30 99 79 ae 3a 00 f0 3f 47 4a 9b 11 000000C0: 4d 7b 1b 28 0a 44 5b 1a af 35 4d c3 2b 6b be 11 000000D0: 89 03 b9 de cf 37 57 53 1e a4 f3 3f ce 52 a6 d8 000000E0: 7e 9d d8 d4 2f 9f f5 8f 3c c6 cb 2f 56 e0 97 2d 000000F0: b2 0e 10 66 3b 3c ec 34 50 99 a3 7d 42 ec 96 eb 00000100: 87 48 72 2c 0a 6d af b9 4b 62 48 89 36 01 21 ab 00000110: 8e 79 10 54 9c 83 ab a9 8a 6c 37 c7 ac dc a1 7e 00000120: 41 0e 58 de da aa 95 71 fb 34 50 8a ef 37 0b c4 00000130: 56 ca 4b 2c 75 b7 c7 d9 74 22 c2 65 1a e4 4f 94 00000140: 20 f6 e9 44 f1 69 5e d2 18 d3 30 2e 85 74 25 be 00000150: 2a 88 e2 ce fe 75 ca fa 25 f9 2e 88 8c ed 6f dd 00000160: c3 c5 53 2e da 14 fd 96 28 4a b7 81 3a b3 d5 44 00000170: 26 e2 84 21 f2 5c 0a ed bf c4 34 1c a4 91 5e f3 00000180: 47 ef 0e 9e fb ee 34 95 5d 21 72 43 c9 63 af b4 00000190: f2 98 4a 36 57 77 fc e7 57 52 b2 4d bf 34 2a 98 000001A0: ea 70 cd d7 a9 da 4c 0d 19 05 d4 1e dd 36 c7 c4 000001B0: 31 54 18 2a ef 0e 30 44 97 31 15 57 cd d4 88 52 000001C0: 4e 42 c8 20 89 8d 35 7b 8e 03 96 b4 74 fb ec 3b 000001D0: 14 c2 64 49 92 f2 1f 3d ff 84 2d 92 4c b9 01 04 000001E0: 3d 0a 2a 28 33 de 43 44 6b cf 79 0e (170) Decrypts ciphertext and verifies ICV using K3r as K_msg, resulted in plaintext (fragment 3) Smyslov Expires 9 June 2023 [Page 126] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 28 31 29 2e 63 72 6c 30 81 da 06 08 2b 06 01 05 00000010: 05 07 01 01 04 81 cd 30 81 ca 30 44 06 08 2b 06 00000020: 01 05 05 07 30 02 86 38 68 74 74 70 3a 2f 2f 74 00000030: 65 73 74 67 6f 73 74 32 30 31 32 2e 63 72 79 70 00000040: 74 6f 70 72 6f 2e 72 75 2f 43 65 72 74 45 6e 72 00000050: 6f 6c 6c 2f 72 6f 6f 74 32 30 31 38 2e 63 72 74 00000060: 30 3f 06 08 2b 06 01 05 05 07 30 01 86 33 68 74 00000070: 74 70 3a 2f 2f 74 65 73 74 67 6f 73 74 32 30 31 00000080: 32 2e 63 72 79 70 74 6f 70 72 6f 2e 72 75 2f 6f 00000090: 63 73 70 32 30 31 32 67 2f 6f 63 73 70 2e 73 72 000000A0: 66 30 41 06 08 2b 06 01 05 05 07 30 01 86 35 68 000000B0: 74 74 70 3a 2f 2f 74 65 73 74 67 6f 73 74 32 30 000000C0: 31 32 2e 63 72 79 70 74 6f 70 72 6f 2e 72 75 2f 000000D0: 6f 63 73 70 32 30 31 32 67 73 74 2f 6f 63 73 70 000000E0: 2e 73 72 66 30 0a 06 08 2a 85 03 07 01 01 03 02 000000F0: 03 41 00 a5 39 5f ca 48 e1 c2 93 c1 e0 8a 64 74 00000100: 0f 6b 86 a2 15 9b 46 29 d0 42 71 4f ce e7 52 d7 00000110: d7 3d aa 47 ce cf 52 63 8f 26 b2 17 5f ad 96 57 00000120: 76 ea 5f d0 87 bb 12 29 e4 06 0e e1 5f fd 59 81 00000130: fb 34 6d 29 00 00 55 0e 00 00 00 0c 30 0a 06 08 00000140: 2a 85 03 07 01 01 03 02 c8 40 af f7 46 6f 7b eb 00000150: d2 b9 1c 5a 80 d0 00 93 c2 5e 44 16 40 47 f7 8e 00000160: 61 9c da a5 16 94 83 c5 68 5f e8 4d 03 e7 c2 cd 00000170: 08 07 b8 f3 46 66 6d 05 76 c0 d5 e7 60 1d 59 49 00000180: 09 45 52 c4 95 a7 5a d3 29 00 00 08 00 00 40 00 00000190: 2f 00 00 0c 00 00 40 01 00 00 00 40 21 00 00 10 000001A0: 02 00 00 00 00 01 00 04 0a 01 01 03 2c 00 00 20 000001B0: 00 00 00 1c 01 03 04 02 34 ff 8a 25 03 00 00 08 000001C0: 01 00 00 21 00 00 00 08 05 00 00 00 2d 00 00 18 000001D0: 01 00 00 00 07 00 00 10 00 00 ff ff 0a 01 01 03 000001E0: 0a 01 01 03 29 00 00 18 01 00 00 00 (171) Extracts IV from message (fragment 4) 00000000: 00 00 00 00 00 00 00 03 (172) Uses previously computed key K3r 00000000: 31 95 e8 c6 67 af 42 d8 ce f1 e8 99 c6 8b 2a c2 00000010: 29 aa 3d c0 ff 18 5f 3d 79 4a 14 6b 9f ac d0 bb (173) Composes MGM nonce (fragment 4) 00000000: 00 00 00 03 a5 bb 18 2f (174) Extracts ICV from message (fragment 4) 00000000: 6c 27 70 e0 8a 82 bd 4b Smyslov Expires 9 June 2023 [Page 127] Internet-Draft GOST algorithms in IKEv2 December 2022 (175) Extracts AAD from message (fragment 4) 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 35 20 23 20 00 00 00 01 00 00 00 5e 00 00 00 42 00000020: 00 04 00 04 (176) Extracts ciphertext from message (fragment 4) 00000000: 81 fa 5d 7a 67 13 b7 93 f4 2c 01 b8 d1 02 8c ab 00000010: 8e 80 47 25 6e c5 69 e3 0c 84 cd 35 9a 0f 7a cc 00000020: 0a 92 7a 74 77 dc ba 60 ac 4a (177) Decrypts ciphertext and verifies ICV using K3r as K_msg, resulted in plaintext (fragment 4) 00000000: 00 07 00 00 10 00 00 ff ff 0a 00 00 00 0a 00 00 00000010: ff 29 00 00 08 00 00 40 02 29 00 00 08 00 00 40 00000020: 0a 00 00 00 08 00 00 40 0b 00 (178) Reassembles message from received fragments and parses it IKE SA Auth #9280E0822E758778.DB578D97DE119D1E.00000001 IKEv2 R=>I[1563] 4*EF[...]->E[1535]{ IDr[78](DN){CN=IKE Interop Test Server,O=ELVIS-PLUS,C=RU}, CERT[1211](X.509 Cert){308204...FB346D}, AUTH[85](Sig){id-tc26-signwithdigest-gost3410-12-256[12]: C840AF...A75AD3}, N[8](INITIAL_CONTACT), N[12](SET_WINDOW_SIZE){64}, CP[16](REPLY){IP4.Address[4]=10.1.1.3}, SA[32]{ P[28](#1:ESP:34FF8A25:2#){ Encryption=ENCR_MAGMA_MGM_KTREE, ESN=Off}}, TSi[24](1#){10.1.1.3}, TSr[24](1#){10.0.0.0-10.0.0.255}, N[8](ADDITIONAL_TS_POSSIBLE), N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} (179) Computes prf(SK_pr, IDr) 00000000: 7d c8 6a 33 12 02 5c 21 1f ab dc 83 0b 01 a5 27 00000010: 82 a2 f2 1f 64 c6 e9 5e 0e c0 4c e5 d9 11 8d 8e 00000020: b9 5c ef fa b0 a3 37 75 94 20 7c e4 60 60 ed 9d 00000030: fa 5e cb 7e e7 79 05 ab fb 51 1b 03 a8 2c c5 6a Smyslov Expires 9 June 2023 [Page 128] Internet-Draft GOST algorithms in IKEv2 December 2022 (180) Uses responder's public key 00000000: 5B B3 14 3E F4 70 C1 70 D7 F3 27 25 D8 53 7C E6 00000010: DE 6D 8C 29 F6 B2 32 64 56 DC B1 77 F2 3D FA F4 00000020: 2A 5C F3 74 86 7F 04 72 51 C1 CF B3 43 36 F5 95 00000030: A2 AF 05 47 57 1A 55 C0 78 A4 9D 64 26 B8 61 14 (181) Verifies signature from AUTH payload using algorithm id-tc26- signwithdigest-gost3410-12-256 00000000: c8 40 af f7 46 6f 7b eb d2 b9 1c 5a 80 d0 00 93 00000010: c2 5e 44 16 40 47 f7 8e 61 9c da a5 16 94 83 c5 00000020: 68 5f e8 4d 03 e7 c2 cd 08 07 b8 f3 46 66 6d 05 00000030: 76 c0 d5 e7 60 1d 59 49 09 45 52 c4 95 a7 5a d3 (182) Computes keys for ESP SAs 00000000: 98 ab 7e db 78 03 a1 e6 c7 21 43 ee b9 7f 5f 56 00000010: 45 bb 51 cd 0b b7 09 a1 af 34 02 87 69 4d 7b a0 00000020: 1d 14 a0 cc 00000000: 70 31 4d 57 94 8b 7e 5c 6f 29 d5 68 1b fd 43 2b 00000010: 19 4e 64 6d 8f 8a 8d 1e ba 72 24 59 c7 0c de 81 00000020: e2 04 84 af Sub-scenario 2: IKE SA rekeying using the CREATE_CHILD_SA exchange. Initiator Responder HDR, SK {SAi, Ni, KEi [,N+]} ---> <--- HDR, SK {SAr, Nr, KEr [,N+]} Initiator's actions: (1) Generates random SPIi for new IKE SA 00000000: fd d9 35 89 50 d5 db 22 (2) Generates random IKE nonce Ni 00000000: 2e 98 99 76 4a 67 1e d9 17 27 32 f2 6d 3a 93 3c 00000010: 7f 21 2b 0e 59 90 cf 2a 7f 85 53 c5 ed 8a ec 37 (3) Generates ephemeral private key Smyslov Expires 9 June 2023 [Page 129] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 29 2c 72 52 e0 6c fd 39 1d 55 04 e9 cf af 82 29 00000010: 89 09 ff 1c ab b2 dd a5 88 f0 34 fd 2c 57 d2 28 (4) Computes public key 00000000: 13 78 88 b1 0f 09 65 43 94 53 b7 26 5d 2a 8b 29 00000010: 5f a9 d6 73 a2 d0 64 6c 98 0f 02 44 d5 5a 1d 13 00000020: 7b b4 4d 18 81 c3 ee 48 35 18 a7 71 ce 4f fa 45 00000030: b0 e9 74 63 37 58 32 7c ff a5 e4 98 b5 02 d4 ef (5) Creates message Create Child SA #9280E0822E758778.DB578D97DE119D1E.00000002 IKEv2 R<-I[213] E[185]{ SA[44]{ P[40](#1:IKE:FDD9358950D5DB22:3#){ Encryption=ENCR_MAGMA_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_256}}, NONCE[36]{2E9899...8AEC37}, KE[72](GOST3410_2012_256){137888...02D4EF}, N[12](SET_WINDOW_SIZE){4}} (6) Computes K3i (i3 = 1) 00000000: da 26 f7 b5 4c 4c 97 23 3f e2 cb 53 23 82 1b 2a 00000010: 40 3c 95 e1 78 2a 8f 3d 1b 0f a4 d3 ab c3 98 3d (7) Composes MGM nonce 00000000: 00 00 00 00 b4 e1 3e 23 (8) Composes AAD 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 2e 20 24 08 00 00 00 02 00 00 00 d5 21 00 00 b9 (9) Composes plaintext Smyslov Expires 9 June 2023 [Page 130] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 28 00 00 2c 00 00 00 28 01 01 08 03 fd d9 35 89 00000010: 50 d5 db 22 03 00 00 08 01 00 00 21 03 00 00 08 00000020: 02 00 00 09 00 00 00 08 04 00 00 21 22 00 00 24 00000030: 2e 98 99 76 4a 67 1e d9 17 27 32 f2 6d 3a 93 3c 00000040: 7f 21 2b 0e 59 90 cf 2a 7f 85 53 c5 ed 8a ec 37 00000050: 29 00 00 48 00 21 00 00 13 78 88 b1 0f 09 65 43 00000060: 94 53 b7 26 5d 2a 8b 29 5f a9 d6 73 a2 d0 64 6c 00000070: 98 0f 02 44 d5 5a 1d 13 7b b4 4d 18 81 c3 ee 48 00000080: 35 18 a7 71 ce 4f fa 45 b0 e9 74 63 37 58 32 7c 00000090: ff a5 e4 98 b5 02 d4 ef 00 00 00 0c 00 00 40 01 000000A0: 00 00 00 04 00 (10) Encrypts plaintext using K3i as K_msg, resulted in ciphertext 00000000: f4 d1 2b 1e 51 65 d1 0b 7f 38 c6 16 3f 6e 5e f7 00000010: e0 48 24 15 6a 45 50 51 1a 6e fb 1c 1d b8 52 75 00000020: 80 56 e4 da fb e5 fe 42 08 71 79 99 ef 17 7a 03 00000030: fc c3 c6 b0 15 a5 72 a4 1b de e2 b5 e6 46 56 73 00000040: 3f 78 57 9e 6b b4 05 4c 86 91 c3 61 00 2d 9b 89 00000050: c0 0c 8b 11 0b 41 e7 92 16 7f f8 f6 5d ef f4 29 00000060: 27 ef ba 8c 5f 30 fd a9 12 4c 5f 8d e9 39 97 48 00000070: 9a e1 6a 91 01 c7 8c 94 aa 3b 89 bb 54 40 3b f1 00000080: 8d 2b 0e 75 d8 f6 98 d2 74 e4 b7 2f f5 ac a0 41 00000090: df 73 7f 1c 37 18 b9 79 8e 9d 6f ea e5 8a b6 9f 000000A0: 35 d9 d4 b3 cd (11) Computes ICV using K3i as K_msg 00000000: 49 96 ac 4c 3f c4 fc 1d (12) Composes IV 00000000: 00 00 00 00 01 00 00 00 (13) Sends message, peer receives message Smyslov Expires 9 June 2023 [Page 131] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54295->10.111.15.45:4500 [217] 00000000: 00 00 00 00 92 80 e0 82 2e 75 87 78 db 57 8d 97 00000010: de 11 9d 1e 2e 20 24 08 00 00 00 02 00 00 00 d5 00000020: 21 00 00 b9 00 00 00 00 01 00 00 00 f4 d1 2b 1e 00000030: 51 65 d1 0b 7f 38 c6 16 3f 6e 5e f7 e0 48 24 15 00000040: 6a 45 50 51 1a 6e fb 1c 1d b8 52 75 80 56 e4 da 00000050: fb e5 fe 42 08 71 79 99 ef 17 7a 03 fc c3 c6 b0 00000060: 15 a5 72 a4 1b de e2 b5 e6 46 56 73 3f 78 57 9e 00000070: 6b b4 05 4c 86 91 c3 61 00 2d 9b 89 c0 0c 8b 11 00000080: 0b 41 e7 92 16 7f f8 f6 5d ef f4 29 27 ef ba 8c 00000090: 5f 30 fd a9 12 4c 5f 8d e9 39 97 48 9a e1 6a 91 000000A0: 01 c7 8c 94 aa 3b 89 bb 54 40 3b f1 8d 2b 0e 75 000000B0: d8 f6 98 d2 74 e4 b7 2f f5 ac a0 41 df 73 7f 1c 000000C0: 37 18 b9 79 8e 9d 6f ea e5 8a b6 9f 35 d9 d4 b3 000000D0: cd 49 96 ac 4c 3f c4 fc 1d Responder's actions: (14) Extracts IV from message 00000000: 00 00 00 00 01 00 00 00 (15) Computes K3i (I = 1) 00000000: da 26 f7 b5 4c 4c 97 23 3f e2 cb 53 23 82 1b 2a 00000010: 40 3c 95 e1 78 2a 8f 3d 1b 0f a4 d3 ab c3 98 3d (16) Composes MGM nonce 00000000: 00 00 00 00 b4 e1 3e 23 (17) Extracts ICV from message 00000000: 49 96 ac 4c 3f c4 fc 1d (18) Extracts AAD from message 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 2e 20 24 08 00 00 00 02 00 00 00 d5 21 00 00 b9 (19) Extracts ciphertext from message Smyslov Expires 9 June 2023 [Page 132] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: f4 d1 2b 1e 51 65 d1 0b 7f 38 c6 16 3f 6e 5e f7 00000010: e0 48 24 15 6a 45 50 51 1a 6e fb 1c 1d b8 52 75 00000020: 80 56 e4 da fb e5 fe 42 08 71 79 99 ef 17 7a 03 00000030: fc c3 c6 b0 15 a5 72 a4 1b de e2 b5 e6 46 56 73 00000040: 3f 78 57 9e 6b b4 05 4c 86 91 c3 61 00 2d 9b 89 00000050: c0 0c 8b 11 0b 41 e7 92 16 7f f8 f6 5d ef f4 29 00000060: 27 ef ba 8c 5f 30 fd a9 12 4c 5f 8d e9 39 97 48 00000070: 9a e1 6a 91 01 c7 8c 94 aa 3b 89 bb 54 40 3b f1 00000080: 8d 2b 0e 75 d8 f6 98 d2 74 e4 b7 2f f5 ac a0 41 00000090: df 73 7f 1c 37 18 b9 79 8e 9d 6f ea e5 8a b6 9f 000000A0: 35 d9 d4 b3 cd (20) Decrypts ciphertext and verifies ICV using K3i as K_msg, resulted in plaintext 00000000: 28 00 00 2c 00 00 00 28 01 01 08 03 fd d9 35 89 00000010: 50 d5 db 22 03 00 00 08 01 00 00 21 03 00 00 08 00000020: 02 00 00 09 00 00 00 08 04 00 00 21 22 00 00 24 00000030: 2e 98 99 76 4a 67 1e d9 17 27 32 f2 6d 3a 93 3c 00000040: 7f 21 2b 0e 59 90 cf 2a 7f 85 53 c5 ed 8a ec 37 00000050: 29 00 00 48 00 21 00 00 13 78 88 b1 0f 09 65 43 00000060: 94 53 b7 26 5d 2a 8b 29 5f a9 d6 73 a2 d0 64 6c 00000070: 98 0f 02 44 d5 5a 1d 13 7b b4 4d 18 81 c3 ee 48 00000080: 35 18 a7 71 ce 4f fa 45 b0 e9 74 63 37 58 32 7c 00000090: ff a5 e4 98 b5 02 d4 ef 00 00 00 0c 00 00 40 01 000000A0: 00 00 00 04 00 (21) Parses received message Create Child SA #9280E0822E758778.DB578D97DE119D1E.00000002 IKEv2 I->R[213] E[185]{ SA[44]{ P[40](#1:IKE:FDD9358950D5DB22:3#){ Encryption=ENCR_MAGMA_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_256}}, NONCE[36]{2E9899...8AEC37}, KE[72](GOST3410_2012_256){137888...02D4EF}, N[12](SET_WINDOW_SIZE){4}} (22) Generates random SPIr for new IKE SA 00000000: 81 27 5d a2 98 90 1a 06 (23) Generates random IKE nonce Nr Smyslov Expires 9 June 2023 [Page 133] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: cf 8e 80 0f 84 c9 d8 50 06 a4 02 b5 19 2a 0f a0 00000010: d7 f4 db 70 ca f1 2b 9b 02 ce 92 8d 97 20 43 96 (24) Generates ephemeral private key 00000000: af 9a 62 7d d3 b8 23 d2 49 7f f9 0a 9d f2 55 8c 00000010: ae 9c 48 ad f5 a4 ee a5 f6 24 5f 48 3c f8 42 0d (25) Computes public key 00000000: ba 9c bb 8d c4 51 68 1c 63 50 9c 5b 78 c2 93 be 00000010: 52 9b 7a a0 6b 14 1e 0f 52 d4 a3 0e 71 d7 5b 4c 00000020: aa 58 af 26 21 d9 b2 92 87 1c d9 7a 89 6f c2 7d 00000030: 7d 95 96 39 a2 36 37 8f f4 b9 1d 2f a8 b7 f5 c9 (26) Computes shared key 00000000: ae 27 a3 df af 7d bb ad f4 5c 19 64 c9 27 eb 41 00000010: 14 fc 1a f8 25 cc 93 50 a2 64 5f 04 67 0a 74 cb (27) Computes SKEYSEED for new SA 00000000: 31 2b 7f 6a 24 23 8f ed b6 ac 40 a7 58 2e 28 54 00000010: 47 53 76 20 05 c7 00 c8 87 c1 51 68 93 40 7e 2d 00000020: ed 14 c4 78 9a f4 12 e7 f0 19 4d 4d 12 45 0d 42 00000030: e4 b2 29 e5 57 b4 90 cc cf d5 94 84 b4 59 5e b9 (28) Computes SK_d for new SA 00000000: 38 ec b5 1c 33 77 f8 62 29 9f 00 d9 98 5f a4 4c 00000010: ea c7 97 31 01 b9 39 ce 16 2c 1c 30 dd 53 d8 97 00000020: 48 49 cd ca 82 7b 57 55 e4 5a 33 1c 80 e6 b9 1f 00000030: 2c 80 b2 e5 48 8a 23 9d 8e 42 32 ed 4f 63 3a f1 (29) Computes SK_ei for new SA 00000000: 17 1c 7c 08 bd 1a 3d 50 58 e1 13 58 9d c4 21 c6 00000010: a3 44 e5 c1 f5 14 e8 22 ed 94 03 2e 76 47 b1 8d 00000020: 2b 3d 3b 2f (30) Computes SK_er for new SA 00000000: 4a a9 b7 36 1d 2c e1 e0 dc 55 b6 45 0a 38 f1 9a 00000010: 83 cb 8f 79 57 5e df d8 5f 5e 22 a8 36 bd 3a 4a 00000020: d2 f6 27 21 (31) Creates message Smyslov Expires 9 June 2023 [Page 134] Internet-Draft GOST algorithms in IKEv2 December 2022 Create Child SA #9280E0822E758778.DB578D97DE119D1E.00000002 IKEv2 I<=R[213] E[185]{ SA[44]{ P[40](#1:IKE:81275DA298901A06:3#){ Encryption=ENCR_MAGMA_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_256}}, NONCE[36]{CF8E80...204396}, KE[72](GOST3410_2012_256){BA9CBB...B7F5C9}, N[12](SET_WINDOW_SIZE){64}} (32) Computes K3r (i3 = 1) 00000000: 9b 6c de 40 b4 63 c4 85 db 09 b7 24 f4 60 fa d0 00000010: 1f d3 f3 fa e9 f8 e9 03 0c 34 cb 51 52 51 5b 56 (33) Composes MGM nonce 00000000: 00 00 00 00 a5 bb 18 2f (34) Composes AAD 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 2e 20 24 20 00 00 00 02 00 00 00 d5 21 00 00 b9 (35) Composes plaintext 00000000: 28 00 00 2c 00 00 00 28 01 01 08 03 81 27 5d a2 00000010: 98 90 1a 06 03 00 00 08 01 00 00 21 03 00 00 08 00000020: 02 00 00 09 00 00 00 08 04 00 00 21 22 00 00 24 00000030: cf 8e 80 0f 84 c9 d8 50 06 a4 02 b5 19 2a 0f a0 00000040: d7 f4 db 70 ca f1 2b 9b 02 ce 92 8d 97 20 43 96 00000050: 29 00 00 48 00 21 00 00 ba 9c bb 8d c4 51 68 1c 00000060: 63 50 9c 5b 78 c2 93 be 52 9b 7a a0 6b 14 1e 0f 00000070: 52 d4 a3 0e 71 d7 5b 4c aa 58 af 26 21 d9 b2 92 00000080: 87 1c d9 7a 89 6f c2 7d 7d 95 96 39 a2 36 37 8f 00000090: f4 b9 1d 2f a8 b7 f5 c9 00 00 00 0c 00 00 40 01 000000A0: 00 00 00 40 00 (36) Encrypts plaintext using K3r as K_msg, resulted in ciphertext Smyslov Expires 9 June 2023 [Page 135] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 6e a0 bc 5e 58 16 91 db 1f e0 22 20 b6 75 fd e6 00000010: e0 01 a7 86 0c 9c a6 77 ef cd f6 be e4 c8 31 18 00000020: c7 7f 68 58 d8 85 75 6c 1d 4a 0e 66 09 86 7c 84 00000030: 30 a7 2e f0 26 2b 19 da c5 25 34 5b 19 f0 97 86 00000040: 54 ca 08 92 65 9c e3 92 4d ee 92 0a a0 86 d7 3f 00000050: 4d d9 f2 7e 32 48 b3 9f ea 54 d2 96 99 42 30 6b 00000060: b0 b4 fe 5d 4a fc 8c ff 54 f6 2f b7 ca 7b 83 01 00000070: 36 85 57 78 b3 74 84 72 9d 94 2f 6f ae 4e 26 bb 00000080: 6e 06 84 2b ac f8 99 29 31 ad 7b dc db c0 0f 19 00000090: 5f 06 42 2d 90 d2 6a 05 8a 41 ee 24 e2 49 a5 b6 000000A0: 61 e8 cb 46 3c (37) Computes ICV using K3r as K_msg 00000000: dc c4 ca 6d 07 cf 31 a8 (38) Composes IV 00000000: 00 00 00 00 01 00 00 00 (39) Sends message, peer receives message 10.111.10.171:54295<-10.111.15.45:4500 [217] 00000000: 00 00 00 00 92 80 e0 82 2e 75 87 78 db 57 8d 97 00000010: de 11 9d 1e 2e 20 24 20 00 00 00 02 00 00 00 d5 00000020: 21 00 00 b9 00 00 00 00 01 00 00 00 6e a0 bc 5e 00000030: 58 16 91 db 1f e0 22 20 b6 75 fd e6 e0 01 a7 86 00000040: 0c 9c a6 77 ef cd f6 be e4 c8 31 18 c7 7f 68 58 00000050: d8 85 75 6c 1d 4a 0e 66 09 86 7c 84 30 a7 2e f0 00000060: 26 2b 19 da c5 25 34 5b 19 f0 97 86 54 ca 08 92 00000070: 65 9c e3 92 4d ee 92 0a a0 86 d7 3f 4d d9 f2 7e 00000080: 32 48 b3 9f ea 54 d2 96 99 42 30 6b b0 b4 fe 5d 00000090: 4a fc 8c ff 54 f6 2f b7 ca 7b 83 01 36 85 57 78 000000A0: b3 74 84 72 9d 94 2f 6f ae 4e 26 bb 6e 06 84 2b 000000B0: ac f8 99 29 31 ad 7b dc db c0 0f 19 5f 06 42 2d 000000C0: 90 d2 6a 05 8a 41 ee 24 e2 49 a5 b6 61 e8 cb 46 000000D0: 3c dc c4 ca 6d 07 cf 31 a8 Initiator's actions: (40) Extracts IV from message 00000000: 00 00 00 00 01 00 00 00 (41) Computes K3r (i3 = 1) Smyslov Expires 9 June 2023 [Page 136] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 9b 6c de 40 b4 63 c4 85 db 09 b7 24 f4 60 fa d0 00000010: 1f d3 f3 fa e9 f8 e9 03 0c 34 cb 51 52 51 5b 56 (42) Composes MGM nonce 00000000: 00 00 00 00 a5 bb 18 2f (43) Extracts ICV from message 00000000: dc c4 ca 6d 07 cf 31 a8 (44) Extracts AAD from message 00000000: 92 80 e0 82 2e 75 87 78 db 57 8d 97 de 11 9d 1e 00000010: 2e 20 24 20 00 00 00 02 00 00 00 d5 21 00 00 b9 (45) Extracts ciphertext from message 00000000: 6e a0 bc 5e 58 16 91 db 1f e0 22 20 b6 75 fd e6 00000010: e0 01 a7 86 0c 9c a6 77 ef cd f6 be e4 c8 31 18 00000020: c7 7f 68 58 d8 85 75 6c 1d 4a 0e 66 09 86 7c 84 00000030: 30 a7 2e f0 26 2b 19 da c5 25 34 5b 19 f0 97 86 00000040: 54 ca 08 92 65 9c e3 92 4d ee 92 0a a0 86 d7 3f 00000050: 4d d9 f2 7e 32 48 b3 9f ea 54 d2 96 99 42 30 6b 00000060: b0 b4 fe 5d 4a fc 8c ff 54 f6 2f b7 ca 7b 83 01 00000070: 36 85 57 78 b3 74 84 72 9d 94 2f 6f ae 4e 26 bb 00000080: 6e 06 84 2b ac f8 99 29 31 ad 7b dc db c0 0f 19 00000090: 5f 06 42 2d 90 d2 6a 05 8a 41 ee 24 e2 49 a5 b6 000000A0: 61 e8 cb 46 3c (46) Decrypts ciphertext and verifies ICV using K3r as K_msg, resulted in plaintext 00000000: 28 00 00 2c 00 00 00 28 01 01 08 03 81 27 5d a2 00000010: 98 90 1a 06 03 00 00 08 01 00 00 21 03 00 00 08 00000020: 02 00 00 09 00 00 00 08 04 00 00 21 22 00 00 24 00000030: cf 8e 80 0f 84 c9 d8 50 06 a4 02 b5 19 2a 0f a0 00000040: d7 f4 db 70 ca f1 2b 9b 02 ce 92 8d 97 20 43 96 00000050: 29 00 00 48 00 21 00 00 ba 9c bb 8d c4 51 68 1c 00000060: 63 50 9c 5b 78 c2 93 be 52 9b 7a a0 6b 14 1e 0f 00000070: 52 d4 a3 0e 71 d7 5b 4c aa 58 af 26 21 d9 b2 92 00000080: 87 1c d9 7a 89 6f c2 7d 7d 95 96 39 a2 36 37 8f 00000090: f4 b9 1d 2f a8 b7 f5 c9 00 00 00 0c 00 00 40 01 000000A0: 00 00 00 40 00 (47) Parses received message Smyslov Expires 9 June 2023 [Page 137] Internet-Draft GOST algorithms in IKEv2 December 2022 Create Child SA #9280E0822E758778.DB578D97DE119D1E.00000002 IKEv2 R=>I[213] E[185]{ SA[44]{ P[40](#1:IKE:81275DA298901A06:3#){ Encryption=ENCR_MAGMA_MGM_KTREE, PRF=PRF_HMAC_STREEBOG_512, KE=GOST3410_2012_256}}, NONCE[36]{CF8E80...204396}, KE[72](GOST3410_2012_256){BA9CBB...B7F5C9}, N[12](SET_WINDOW_SIZE){64}} (48) Computes shared key 00000000: ae 27 a3 df af 7d bb ad f4 5c 19 64 c9 27 eb 41 00000010: 14 fc 1a f8 25 cc 93 50 a2 64 5f 04 67 0a 74 cb (49) Computes SKEYSEED for new SA 00000000: 31 2b 7f 6a 24 23 8f ed b6 ac 40 a7 58 2e 28 54 00000010: 47 53 76 20 05 c7 00 c8 87 c1 51 68 93 40 7e 2d 00000020: ed 14 c4 78 9a f4 12 e7 f0 19 4d 4d 12 45 0d 42 00000030: e4 b2 29 e5 57 b4 90 cc cf d5 94 84 b4 59 5e b9 (50) Computes SK_d for new SA 00000000: 38 ec b5 1c 33 77 f8 62 29 9f 00 d9 98 5f a4 4c 00000010: ea c7 97 31 01 b9 39 ce 16 2c 1c 30 dd 53 d8 97 00000020: 48 49 cd ca 82 7b 57 55 e4 5a 33 1c 80 e6 b9 1f 00000030: 2c 80 b2 e5 48 8a 23 9d 8e 42 32 ed 4f 63 3a f1 (51) Computes SK_ei for new SA 00000000: 17 1c 7c 08 bd 1a 3d 50 58 e1 13 58 9d c4 21 c6 00000010: a3 44 e5 c1 f5 14 e8 22 ed 94 03 2e 76 47 b1 8d 00000020: 2b 3d 3b 2f (52) Computes SK_er for new SA 00000000: 4a a9 b7 36 1d 2c e1 e0 dc 55 b6 45 0a 38 f1 9a 00000010: 83 cb 8f 79 57 5e df d8 5f 5e 22 a8 36 bd 3a 4a 00000020: d2 f6 27 21 Sub-scenario 3: ESP SAs rekeying without PFS using the CREATE_CHILD_SA exchange. Smyslov Expires 9 June 2023 [Page 138] Internet-Draft GOST algorithms in IKEv2 December 2022 Initiator Responder HDR, SK {N(REKEY_SA), SAi, Ni, TSi, TSr [,N+]} ---> <--- HDR, SK {SAr, Nr, TSi, TSr [,N+]} Initiator's actions: (1) Generates random IKE nonce Ni 00000000: b5 48 18 7d 30 d8 ea 49 20 d0 9d 42 de 9e 91 ce 00000010: b3 1c 41 85 37 66 d8 9e c6 a6 f8 08 93 f4 48 23 (2) Computes K1i (i1 = 0) 00000000: 28 b9 3c 93 ea db 74 38 64 87 8a 28 8d e0 38 5c 00000010: 14 cb ea 9f 67 58 a6 ee e2 2d c9 37 bb c8 41 69 (3) Computes K2i (i2 = 0) 00000000: 75 11 35 65 e6 29 70 2a d9 7d 38 a8 3a e3 aa 8a 00000010: 9e fb 80 af f5 52 71 be c9 c6 c3 4b 4b 40 96 44 (4) Computes K3i (i3 = 0) 00000000: 45 6f 03 f7 ad 75 eb e9 52 b8 8f 0d e8 36 47 69 00000010: 4d 2e f2 ba 15 e6 8c 89 1c 99 62 64 fb 0e 70 0a (5) Selects SPI for new incoming ESP SA 00000000: 9a 8c 6a 9b (6) Creates message Create Child SA #FDD9358950D5DB22.81275DA298901A06.00000000 IKEv2 R<-I[193] E[165]{ N[12](ESP:6C0CA570:REKEY_SA), SA[32]{ P[28](#1:ESP:9A8C6A9B:2#){ Encryption=ENCR_MAGMA_MGM_KTREE, ESN=Off}}, NONCE[36]{B54818...F44823}, TSi[24](1#){10.1.1.3}, TSr[24](1#){10.0.0.0-10.0.0.255}, N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} Smyslov Expires 9 June 2023 [Page 139] Internet-Draft GOST algorithms in IKEv2 December 2022 (7) Composes MGM nonce 00000000: 00 00 00 00 2b 3d 3b 2f (8) Composes AAD 00000000: fd d9 35 89 50 d5 db 22 81 27 5d a2 98 90 1a 06 00000010: 2e 20 24 08 00 00 00 00 00 00 00 c1 29 00 00 a5 (9) Composes plaintext 00000000: 21 00 00 0c 03 04 40 09 6c 0c a5 70 28 00 00 20 00000010: 00 00 00 1c 01 03 04 02 9a 8c 6a 9b 03 00 00 08 00000020: 01 00 00 21 00 00 00 08 05 00 00 00 2c 00 00 24 00000030: b5 48 18 7d 30 d8 ea 49 20 d0 9d 42 de 9e 91 ce 00000040: b3 1c 41 85 37 66 d8 9e c6 a6 f8 08 93 f4 48 23 00000050: 2d 00 00 18 01 00 00 00 07 00 00 10 00 00 ff ff 00000060: 0a 01 01 03 0a 01 01 03 29 00 00 18 01 00 00 00 00000070: 07 00 00 10 00 00 ff ff 0a 00 00 00 0a 00 00 ff 00000080: 29 00 00 08 00 00 40 0a 00 00 00 08 00 00 40 0b 00000090: 00 (10) Encrypts plaintext using K3i as K_msg, resulted in ciphertext 00000000: 47 71 bb 57 2a 1a 58 a6 44 cb 60 d4 8e 5c cc 0a 00000010: b9 34 0f 34 80 cf a2 38 54 f6 70 3b 98 4e 8f 9f 00000020: 3b 5c 5a 04 06 dc e9 d4 d3 54 c6 4d 73 09 10 c5 00000030: 4e 26 c4 27 fd cb 54 e1 cf e0 fd b4 9f f8 00 41 00000040: 41 c8 58 b2 c9 3a d8 e0 19 40 a3 89 ee 26 d4 84 00000050: 69 e9 52 68 d5 e1 ee f0 89 6e d3 95 34 62 ad 2e 00000060: e6 77 17 b8 6c 25 52 7f d8 70 9c 36 0b c8 1d 1a 00000070: 43 50 82 2a be b6 31 ff 2f 43 11 f7 d0 60 bf 62 00000080: b9 08 c3 09 a3 78 fb 5e 76 57 91 5d 48 1c aa d2 00000090: a3 (11) Computes ICV using K3i as K_msg 00000000: b3 05 bd 43 2f 87 0c 3f (12) Composes IV 00000000: 00 00 00 00 00 00 00 00 (13) Sends message, peer receives message Smyslov Expires 9 June 2023 [Page 140] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54295->10.111.15.45:4500 [197] 00000000: 00 00 00 00 fd d9 35 89 50 d5 db 22 81 27 5d a2 00000010: 98 90 1a 06 2e 20 24 08 00 00 00 00 00 00 00 c1 00000020: 29 00 00 a5 00 00 00 00 00 00 00 00 47 71 bb 57 00000030: 2a 1a 58 a6 44 cb 60 d4 8e 5c cc 0a b9 34 0f 34 00000040: 80 cf a2 38 54 f6 70 3b 98 4e 8f 9f 3b 5c 5a 04 00000050: 06 dc e9 d4 d3 54 c6 4d 73 09 10 c5 4e 26 c4 27 00000060: fd cb 54 e1 cf e0 fd b4 9f f8 00 41 41 c8 58 b2 00000070: c9 3a d8 e0 19 40 a3 89 ee 26 d4 84 69 e9 52 68 00000080: d5 e1 ee f0 89 6e d3 95 34 62 ad 2e e6 77 17 b8 00000090: 6c 25 52 7f d8 70 9c 36 0b c8 1d 1a 43 50 82 2a 000000A0: be b6 31 ff 2f 43 11 f7 d0 60 bf 62 b9 08 c3 09 000000B0: a3 78 fb 5e 76 57 91 5d 48 1c aa d2 a3 b3 05 bd 000000C0: 43 2f 87 0c 3f Responder's actions: (14) Extracts IV from message 00000000: 00 00 00 00 00 00 00 00 (15) Computes K1i (i1 = 0) 00000000: 28 b9 3c 93 ea db 74 38 64 87 8a 28 8d e0 38 5c 00000010: 14 cb ea 9f 67 58 a6 ee e2 2d c9 37 bb c8 41 69 (16) Computes K2i (i2 = 0) 00000000: 75 11 35 65 e6 29 70 2a d9 7d 38 a8 3a e3 aa 8a 00000010: 9e fb 80 af f5 52 71 be c9 c6 c3 4b 4b 40 96 44 (17) Computes K3i (i3 = 0) 00000000: 45 6f 03 f7 ad 75 eb e9 52 b8 8f 0d e8 36 47 69 00000010: 4d 2e f2 ba 15 e6 8c 89 1c 99 62 64 fb 0e 70 0a (18) Composes MGM nonce 00000000: 00 00 00 00 2b 3d 3b 2f (19) Extracts ICV from message 00000000: b3 05 bd 43 2f 87 0c 3f (20) Extracts AAD from message Smyslov Expires 9 June 2023 [Page 141] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: fd d9 35 89 50 d5 db 22 81 27 5d a2 98 90 1a 06 00000010: 2e 20 24 08 00 00 00 00 00 00 00 c1 29 00 00 a5 (21) Extracts ciphertext from message 00000000: 47 71 bb 57 2a 1a 58 a6 44 cb 60 d4 8e 5c cc 0a 00000010: b9 34 0f 34 80 cf a2 38 54 f6 70 3b 98 4e 8f 9f 00000020: 3b 5c 5a 04 06 dc e9 d4 d3 54 c6 4d 73 09 10 c5 00000030: 4e 26 c4 27 fd cb 54 e1 cf e0 fd b4 9f f8 00 41 00000040: 41 c8 58 b2 c9 3a d8 e0 19 40 a3 89 ee 26 d4 84 00000050: 69 e9 52 68 d5 e1 ee f0 89 6e d3 95 34 62 ad 2e 00000060: e6 77 17 b8 6c 25 52 7f d8 70 9c 36 0b c8 1d 1a 00000070: 43 50 82 2a be b6 31 ff 2f 43 11 f7 d0 60 bf 62 00000080: b9 08 c3 09 a3 78 fb 5e 76 57 91 5d 48 1c aa d2 00000090: a3 (22) Decrypts ciphertext and verifies ICV using K3i as K_msg, resulted in plaintext 00000000: 21 00 00 0c 03 04 40 09 6c 0c a5 70 28 00 00 20 00000010: 00 00 00 1c 01 03 04 02 9a 8c 6a 9b 03 00 00 08 00000020: 01 00 00 21 00 00 00 08 05 00 00 00 2c 00 00 24 00000030: b5 48 18 7d 30 d8 ea 49 20 d0 9d 42 de 9e 91 ce 00000040: b3 1c 41 85 37 66 d8 9e c6 a6 f8 08 93 f4 48 23 00000050: 2d 00 00 18 01 00 00 00 07 00 00 10 00 00 ff ff 00000060: 0a 01 01 03 0a 01 01 03 29 00 00 18 01 00 00 00 00000070: 07 00 00 10 00 00 ff ff 0a 00 00 00 0a 00 00 ff 00000080: 29 00 00 08 00 00 40 0a 00 00 00 08 00 00 40 0b 00000090: 00 (23) Parses received message Create Child SA #FDD9358950D5DB22.81275DA298901A06.00000000 IKEv2 I->R[193] E[165]{ N[12](ESP:6C0CA570:REKEY_SA), SA[32]{ P[28](#1:ESP:9A8C6A9B:2#){ Encryption=ENCR_MAGMA_MGM_KTREE, ESN=Off}}, NONCE[36]{B54818...F44823}, TSi[24](1#){10.1.1.3}, TSr[24](1#){10.0.0.0-10.0.0.255}, N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} (24) Generates random IKE nonce Nr Smyslov Expires 9 June 2023 [Page 142] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 41 5e a7 ed 7e 65 d3 ff d3 df ed 5f b5 c8 5c 60 00000010: 2b 9c 15 14 eb 52 97 b7 fc aa 33 c4 64 f3 58 06 (25) Selects SPI for new incoming ESP SA 00000000: 15 4f 35 39 (26) Computes keys for new ESP SAs 00000000: 6a b6 a0 e7 05 d3 51 16 6f 4f b9 d6 59 0c c8 69 00000010: 43 70 cf 6f 0d 32 c3 7d 92 75 00 4b 0a 76 35 67 00000020: 64 0e 3a fe 00000000: 65 56 1c 79 27 cb c6 d6 8c b8 69 0f 40 00 d2 0a 00000010: c1 49 1c d1 86 88 db 88 ae f3 be 82 0c 71 b7 c9 00000020: 6c cf a3 64 (27) Creates message Create Child SA #FDD9358950D5DB22.81275DA298901A06.00000000 IKEv2 I<=R[189] E[161]{ SA[32]{ P[28](#1:ESP:154F3539:2#){ Encryption=ENCR_MAGMA_MGM_KTREE, ESN=Off}}, NONCE[36]{415EA7...F35806}, TSi[24](1#){10.1.1.3}, TSr[24](1#){10.0.0.0-10.0.0.255}, N[8](ADDITIONAL_TS_POSSIBLE), N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} (28) Computes K1r (i1 = 0) 00000000: 51 49 d5 41 33 91 45 dd ff 04 f5 05 e5 21 39 f2 00000010: 3a 71 1c 18 ef 39 94 1e dd 0c 70 e5 14 12 43 0a (29) Computes K2r (i2 = 0) 00000000: 0e 8f 21 54 2e fc 81 79 57 c4 c9 0b e0 25 9a 59 00000010: 29 26 0e 86 20 bf d4 e6 00 32 23 43 ae f0 11 52 (30) Computes K3r (i3 = 0) 00000000: 92 b8 b2 d6 7a 2d e1 db 5f e1 39 d2 57 c8 24 5f 00000010: f6 22 54 de fc 35 35 c9 24 cf a5 4a e1 5d 75 71 (31) Composes MGM nonce Smyslov Expires 9 June 2023 [Page 143] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 00 00 00 00 d2 f6 27 21 (32) Composes AAD 00000000: fd d9 35 89 50 d5 db 22 81 27 5d a2 98 90 1a 06 00000010: 2e 20 24 20 00 00 00 00 00 00 00 bd 21 00 00 a1 (33) Composes plaintext 00000000: 28 00 00 20 00 00 00 1c 01 03 04 02 15 4f 35 39 00000010: 03 00 00 08 01 00 00 21 00 00 00 08 05 00 00 00 00000020: 2c 00 00 24 41 5e a7 ed 7e 65 d3 ff d3 df ed 5f 00000030: b5 c8 5c 60 2b 9c 15 14 eb 52 97 b7 fc aa 33 c4 00000040: 64 f3 58 06 2d 00 00 18 01 00 00 00 07 00 00 10 00000050: 00 00 ff ff 0a 01 01 03 0a 01 01 03 29 00 00 18 00000060: 01 00 00 00 07 00 00 10 00 00 ff ff 0a 00 00 00 00000070: 0a 00 00 ff 29 00 00 08 00 00 40 02 29 00 00 08 00000080: 00 00 40 0a 00 00 00 08 00 00 40 0b 00 (34) Encrypts plaintext using K3r as K_msg, resulted in ciphertext 00000000: 2e c7 13 73 4c cc f8 f3 51 71 ac d9 7a 6e 20 2c 00000010: 68 70 bb 8f 82 42 2a 14 e3 8d b8 25 10 9a 1f b6 00000020: 51 ef c5 35 50 bf df 8e 96 bc 94 5a e5 4d 9d 99 00000030: 9a 14 36 d1 4b 61 e1 de 3b 0d 12 94 e5 72 60 00 00000040: 0f 9d dd 2b e1 97 25 4c 5c ee 48 2e 9b f7 d8 9e 00000050: 01 6b 1d 92 b7 c1 7f 16 81 0f e2 e3 14 1c 27 c7 00000060: 35 e9 e3 fd b8 fc 5d fb a2 ee 2f f9 b0 17 39 ca 00000070: f1 2e b1 13 99 e0 da 10 1a 29 74 26 a3 63 ce 09 00000080: 6a f9 1b 67 4a f2 fb 0f 17 5e 48 1a 93 (35) Computes ICV using K3r as K_msg 00000000: 57 b4 30 41 07 50 b1 cc (36) Composes IV 00000000: 00 00 00 00 00 00 00 00 (37) Sends message, peer receives message Smyslov Expires 9 June 2023 [Page 144] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54295<-10.111.15.45:4500 [193] 00000000: 00 00 00 00 fd d9 35 89 50 d5 db 22 81 27 5d a2 00000010: 98 90 1a 06 2e 20 24 20 00 00 00 00 00 00 00 bd 00000020: 21 00 00 a1 00 00 00 00 00 00 00 00 2e c7 13 73 00000030: 4c cc f8 f3 51 71 ac d9 7a 6e 20 2c 68 70 bb 8f 00000040: 82 42 2a 14 e3 8d b8 25 10 9a 1f b6 51 ef c5 35 00000050: 50 bf df 8e 96 bc 94 5a e5 4d 9d 99 9a 14 36 d1 00000060: 4b 61 e1 de 3b 0d 12 94 e5 72 60 00 0f 9d dd 2b 00000070: e1 97 25 4c 5c ee 48 2e 9b f7 d8 9e 01 6b 1d 92 00000080: b7 c1 7f 16 81 0f e2 e3 14 1c 27 c7 35 e9 e3 fd 00000090: b8 fc 5d fb a2 ee 2f f9 b0 17 39 ca f1 2e b1 13 000000A0: 99 e0 da 10 1a 29 74 26 a3 63 ce 09 6a f9 1b 67 000000B0: 4a f2 fb 0f 17 5e 48 1a 93 57 b4 30 41 07 50 b1 000000C0: cc Initiator's actions: (38) Extracts IV from message 00000000: 00 00 00 00 00 00 00 00 (39) Computes K1r (i1 = 0) 00000000: 51 49 d5 41 33 91 45 dd ff 04 f5 05 e5 21 39 f2 00000010: 3a 71 1c 18 ef 39 94 1e dd 0c 70 e5 14 12 43 0a (40) Computes K2r (i2 = 0) 00000000: 0e 8f 21 54 2e fc 81 79 57 c4 c9 0b e0 25 9a 59 00000010: 29 26 0e 86 20 bf d4 e6 00 32 23 43 ae f0 11 52 (41) Computes K3r (i3 = 0) 00000000: 92 b8 b2 d6 7a 2d e1 db 5f e1 39 d2 57 c8 24 5f 00000010: f6 22 54 de fc 35 35 c9 24 cf a5 4a e1 5d 75 71 (42) Composes MGM nonce 00000000: 00 00 00 00 d2 f6 27 21 (43) Extracts ICV from message 00000000: 57 b4 30 41 07 50 b1 cc (44) Extracts AAD from message Smyslov Expires 9 June 2023 [Page 145] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: fd d9 35 89 50 d5 db 22 81 27 5d a2 98 90 1a 06 00000010: 2e 20 24 20 00 00 00 00 00 00 00 bd 21 00 00 a1 (45) Extracts ciphertext from message 00000000: 2e c7 13 73 4c cc f8 f3 51 71 ac d9 7a 6e 20 2c 00000010: 68 70 bb 8f 82 42 2a 14 e3 8d b8 25 10 9a 1f b6 00000020: 51 ef c5 35 50 bf df 8e 96 bc 94 5a e5 4d 9d 99 00000030: 9a 14 36 d1 4b 61 e1 de 3b 0d 12 94 e5 72 60 00 00000040: 0f 9d dd 2b e1 97 25 4c 5c ee 48 2e 9b f7 d8 9e 00000050: 01 6b 1d 92 b7 c1 7f 16 81 0f e2 e3 14 1c 27 c7 00000060: 35 e9 e3 fd b8 fc 5d fb a2 ee 2f f9 b0 17 39 ca 00000070: f1 2e b1 13 99 e0 da 10 1a 29 74 26 a3 63 ce 09 00000080: 6a f9 1b 67 4a f2 fb 0f 17 5e 48 1a 93 (46) Decrypts ciphertext and verifies ICV using K3r as K_msg, resulted in plaintext 00000000: 28 00 00 20 00 00 00 1c 01 03 04 02 15 4f 35 39 00000010: 03 00 00 08 01 00 00 21 00 00 00 08 05 00 00 00 00000020: 2c 00 00 24 41 5e a7 ed 7e 65 d3 ff d3 df ed 5f 00000030: b5 c8 5c 60 2b 9c 15 14 eb 52 97 b7 fc aa 33 c4 00000040: 64 f3 58 06 2d 00 00 18 01 00 00 00 07 00 00 10 00000050: 00 00 ff ff 0a 01 01 03 0a 01 01 03 29 00 00 18 00000060: 01 00 00 00 07 00 00 10 00 00 ff ff 0a 00 00 00 00000070: 0a 00 00 ff 29 00 00 08 00 00 40 02 29 00 00 08 00000080: 00 00 40 0a 00 00 00 08 00 00 40 0b 00 (47) Parses received message Create Child SA #FDD9358950D5DB22.81275DA298901A06.00000000 IKEv2 R=>I[189] E[161]{ SA[32]{ P[28](#1:ESP:154F3539:2#){ Encryption=ENCR_MAGMA_MGM_KTREE, ESN=Off}}, NONCE[36]{415EA7...F35806}, TSi[24](1#){10.1.1.3}, TSr[24](1#){10.0.0.0-10.0.0.255}, N[8](ADDITIONAL_TS_POSSIBLE), N[8](ESP_TFC_PADDING_NOT_SUPPORTED), N[8](NON_FIRST_FRAGMENTS_ALSO)} (48) Computes keys for new ESP SAs Smyslov Expires 9 June 2023 [Page 146] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 6a b6 a0 e7 05 d3 51 16 6f 4f b9 d6 59 0c c8 69 00000010: 43 70 cf 6f 0d 32 c3 7d 92 75 00 4b 0a 76 35 67 00000020: 64 0e 3a fe 00000000: 65 56 1c 79 27 cb c6 d6 8c b8 69 0f 40 00 d2 0a 00000010: c1 49 1c d1 86 88 db 88 ae f3 be 82 0c 71 b7 c9 00000020: 6c cf a3 64 Sub-scenario 4: IKE SA deletion using the INFORMATIONAL exchange. Initiator Responder HDR, SK {D} ---> <--- HDR, SK { } Initiator's actions: (1) Creates message Informational #FDD9358950D5DB22.81275DA298901A06.00000003 IKEv2 R<-I[57] E[29]{ D[8](IKE)} (2) Uses previously computed key K3i 00000000: 45 6f 03 f7 ad 75 eb e9 52 b8 8f 0d e8 36 47 69 00000010: 4d 2e f2 ba 15 e6 8c 89 1c 99 62 64 fb 0e 70 0a (3) Composes MGM nonce 00000000: 00 00 00 03 2b 3d 3b 2f (4) Composes AAD 00000000: fd d9 35 89 50 d5 db 22 81 27 5d a2 98 90 1a 06 00000010: 2e 20 25 08 00 00 00 03 00 00 00 39 2a 00 00 1d (5) Composes plaintext 00000000: 00 00 00 08 01 00 00 00 00 (6) Encrypts plaintext using K3i as K_msg, resulted in ciphertext 00000000: 4f ff 67 66 41 9c d3 ec 8e Smyslov Expires 9 June 2023 [Page 147] Internet-Draft GOST algorithms in IKEv2 December 2022 (7) Computes ICV using K3i as K_msg 00000000: d2 bf 0e b7 8f c5 53 03 (8) Composes IV 00000000: 00 00 00 00 00 00 00 03 (9) Sends message, peer receives message 10.111.10.171:54295->10.111.15.45:4500 [61] 00000000: 00 00 00 00 fd d9 35 89 50 d5 db 22 81 27 5d a2 00000010: 98 90 1a 06 2e 20 25 08 00 00 00 03 00 00 00 39 00000020: 2a 00 00 1d 00 00 00 00 00 00 00 03 4f ff 67 66 00000030: 41 9c d3 ec 8e d2 bf 0e b7 8f c5 53 03 Responder's actions: (10) Extracts IV from message 00000000: 00 00 00 00 00 00 00 03 (11) Uses previously computed key K3i 00000000: 45 6f 03 f7 ad 75 eb e9 52 b8 8f 0d e8 36 47 69 00000010: 4d 2e f2 ba 15 e6 8c 89 1c 99 62 64 fb 0e 70 0a (12) Composes MGM nonce 00000000: 00 00 00 03 2b 3d 3b 2f (13) Extracts ICV from message 00000000: d2 bf 0e b7 8f c5 53 03 (14) Extracts AAD from message 00000000: fd d9 35 89 50 d5 db 22 81 27 5d a2 98 90 1a 06 00000010: 2e 20 25 08 00 00 00 03 00 00 00 39 2a 00 00 1d (15) Extracts ciphertext from message 00000000: 4f ff 67 66 41 9c d3 ec 8e (16) Decrypts ciphertext and verifies ICV using K3i as K_msg, resulted in plaintext Smyslov Expires 9 June 2023 [Page 148] Internet-Draft GOST algorithms in IKEv2 December 2022 00000000: 00 00 00 08 01 00 00 00 00 (17) Parses received message Informational #FDD9358950D5DB22.81275DA298901A06.00000003 IKEv2 I->R[57] E[29]{ D[8](IKE)} (18) Creates message Informational #FDD9358950D5DB22.81275DA298901A06.00000003 IKEv2 I<=R[49] E[21]{} (19) Uses previously computed key K3r 00000000: 92 b8 b2 d6 7a 2d e1 db 5f e1 39 d2 57 c8 24 5f 00000010: f6 22 54 de fc 35 35 c9 24 cf a5 4a e1 5d 75 71 (20) Composes MGM nonce 00000000: 00 00 00 03 d2 f6 27 21 (21) Composes AAD 00000000: fd d9 35 89 50 d5 db 22 81 27 5d a2 98 90 1a 06 00000010: 2e 20 25 20 00 00 00 03 00 00 00 31 00 00 00 15 (22) Composes plaintext 00000000: 00 (23) Encrypts plaintext using K3r as K_msg, resulted in ciphertext 00000000: a8 (24) Computes ICV using K3r as K_msg 00000000: ef 77 21 c9 8b c1 eb 98 (25) Composes IV 00000000: 00 00 00 00 00 00 00 03 (26) Sends message, peer receives message Smyslov Expires 9 June 2023 [Page 149] Internet-Draft GOST algorithms in IKEv2 December 2022 10.111.10.171:54295<-10.111.15.45:4500 [53] 00000000: 00 00 00 00 fd d9 35 89 50 d5 db 22 81 27 5d a2 00000010: 98 90 1a 06 2e 20 25 20 00 00 00 03 00 00 00 31 00000020: 00 00 00 15 00 00 00 00 00 00 00 03 a8 ef 77 21 00000030: c9 8b c1 eb 98 Initiator's actions: (27) Extracts IV from message 00000000: 00 00 00 00 00 00 00 03 (28) Uses previously computed key K3r 00000000: 92 b8 b2 d6 7a 2d e1 db 5f e1 39 d2 57 c8 24 5f 00000010: f6 22 54 de fc 35 35 c9 24 cf a5 4a e1 5d 75 71 (29) Composes MGM nonce 00000000: 00 00 00 03 d2 f6 27 21 (30) Extracts ICV from message 00000000: ef 77 21 c9 8b c1 eb 98 (31) Extracts AAD from message 00000000: fd d9 35 89 50 d5 db 22 81 27 5d a2 98 90 1a 06 00000010: 2e 20 25 20 00 00 00 03 00 00 00 31 00 00 00 15 (32) Extracts ciphertext from message 00000000: a8 (33) Decrypts ciphertext and verifies ICV using K3r as K_msg, resulted in plaintext 00000000: 00 (34) Parses received message Informational #FDD9358950D5DB22.81275DA298901A06.00000003 IKEv2 R=>I[49] E[21]{} Author's Address Smyslov Expires 9 June 2023 [Page 150] Internet-Draft GOST algorithms in IKEv2 December 2022 Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation Phone: +7 495 276 0211 Email: svan@elvis.ru Smyslov Expires 9 June 2023 [Page 151] ./draft-zern-webp-12.txt0000644000764400076440000030651114345765243014656 0ustar iustiniustin Internet Engineering Task Force J. Zern Internet-Draft P. Massimino Intended status: Informational J. Alakuijala Expires: 15 June 2023 Google LLC 12 December 2022 WebP Image Format draft-zern-webp-12 Abstract This document defines the WebP image format and registers a media type supporting its use. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 15 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Zern, et al. Expires 15 June 2023 [Page 1] Internet-Draft WebP Image Format December 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. WebP Container Specification . . . . . . . . . . . . . . . . 3 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology & Basics . . . . . . . . . . . . . . . . . . 4 2.3. RIFF File Format . . . . . . . . . . . . . . . . . . . . 5 2.4. WebP File Header . . . . . . . . . . . . . . . . . . . . 6 2.5. Simple File Format (Lossy) . . . . . . . . . . . . . . . 6 2.6. Simple File Format (Lossless) . . . . . . . . . . . . . . 7 2.7. Extended File Format . . . . . . . . . . . . . . . . . . 8 2.7.1. Chunks . . . . . . . . . . . . . . . . . . . . . . . 10 2.7.1.1. Animation . . . . . . . . . . . . . . . . . . . . 10 2.7.1.2. Alpha . . . . . . . . . . . . . . . . . . . . . . 14 2.7.1.3. Bitstream (VP8/VP8L) . . . . . . . . . . . . . . 17 2.7.1.4. Color Profile . . . . . . . . . . . . . . . . . . 17 2.7.1.5. Metadata . . . . . . . . . . . . . . . . . . . . 17 2.7.1.6. Unknown Chunks . . . . . . . . . . . . . . . . . 18 2.7.2. Assembling the Canvas From Frames . . . . . . . . . . 19 2.7.3. Example File Layouts . . . . . . . . . . . . . . . . 20 3. Specification for WebP Lossless Bitstream . . . . . . . . . . 21 3.1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2. Introduction . . . . . . . . . . . . . . . . . . . . . . 22 3.3. Nomenclature . . . . . . . . . . . . . . . . . . . . . . 22 3.4. RIFF Header . . . . . . . . . . . . . . . . . . . . . . . 24 3.5. Transformations . . . . . . . . . . . . . . . . . . . . . 25 3.5.1. Predictor Transform . . . . . . . . . . . . . . . . . 26 3.5.2. Color Transform . . . . . . . . . . . . . . . . . . . 29 3.5.3. Subtract Green Transform . . . . . . . . . . . . . . 31 3.5.4. Color Indexing Transform . . . . . . . . . . . . . . 31 3.6. Image Data . . . . . . . . . . . . . . . . . . . . . . . 33 3.6.1. Roles of Image Data . . . . . . . . . . . . . . . . . 33 3.6.2. Encoding of Image Data . . . . . . . . . . . . . . . 34 3.6.2.1. Prefix Coded Literals . . . . . . . . . . . . . . 35 3.6.2.2. LZ77 Backward Reference . . . . . . . . . . . . . 35 3.6.2.3. Color Cache Coding . . . . . . . . . . . . . . . 37 3.7. Entropy Code . . . . . . . . . . . . . . . . . . . . . . 38 3.7.1. Overview . . . . . . . . . . . . . . . . . . . . . . 38 3.7.2. Details . . . . . . . . . . . . . . . . . . . . . . . 39 3.7.2.1. Decoding and Building the Prefix Codes . . . . . 39 3.7.2.2. Decoding of Meta Prefix Codes . . . . . . . . . . 41 3.7.2.3. Decoding Entropy-coded Image Data . . . . . . . . 43 3.8. Overall Structure of the Format . . . . . . . . . . . . . 44 3.8.1. Basic Structure . . . . . . . . . . . . . . . . . . . 44 3.8.2. Structure of Transforms . . . . . . . . . . . . . . . 44 3.8.3. Structure of the Image Data . . . . . . . . . . . . . 45 4. Security Considerations . . . . . . . . . . . . . . . . . . . 45 5. Interoperability Considerations . . . . . . . . . . . . . . . 46 Zern, et al. Expires 15 June 2023 [Page 2] Internet-Draft WebP Image Format December 2022 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 6.1. The 'image/webp' Media Type . . . . . . . . . . . . . . . 46 6.1.1. Registration Details . . . . . . . . . . . . . . . . 46 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 7.1. Normative References . . . . . . . . . . . . . . . . . . 48 7.2. Informative References . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 1. Introduction WebP is a Resource Interchange File Format (RIFF) [RIFF-spec] based image file format (Section 2) which supports lossless and lossy compression as well as alpha (transparency) and animation. It covers use cases similar to JPEG [JPEG-spec], PNG [RFC2083] and the Graphics Interchange Format (GIF) [GIF-spec]. WebP consists of two compression algorithms used to reduce the size of image pixel data, including alpha (transparency) information. Lossy compression is achieved using VP8 intra-frame encoding [RFC6386]. The lossless algorithm (Section 3) stores and restores the pixel values exactly, including the color values for zero alpha pixels. The format uses subresolution images, recursively embedded into the format itself, for storing statistical data about the images, such as the used entropy codes, spatial predictors, color space conversion, and color table. [LZ77], prefix coding [Huffman], and a color cache are used for compression of the bulk data. 2. WebP Container Specification Note this section is based on the documentation in the libwebp source repository [webp-riff-src]. 2.1. Introduction WebP is an image format that uses either (i) the VP8 intra-frame encoding [RFC6386] to compress image data in a lossy way, or (ii) the WebP lossless encoding (Section 3). These encoding schemes should make it more efficient than currently used formats. It is optimized for fast image transfer over the network (e.g., for websites). The WebP format has feature parity (color profile, metadata, animation, etc.) with other formats as well. This section describes the structure of a WebP file. The WebP container (i.e., RIFF container for WebP) allows feature support over and above the basic use case of WebP (i.e., a file containing a single image encoded as a VP8 key frame). The WebP container provides additional support for: Zern, et al. Expires 15 June 2023 [Page 3] Internet-Draft WebP Image Format December 2022 * Lossless compression. An image can be losslessly compressed, using the WebP Lossless Format. * Metadata. An image may have metadata stored in [Exif] or [XMP] formats. * Transparency. An image may have transparency, i.e., an alpha channel. * Color Profile. An image may have an embedded ICC profile [ICC]. * Animation. An image may have multiple frames with pauses between them, making it an animation. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Bit numbering in chunk diagrams starts at 0 for the most significant bit ('MSB 0') as described in [RFC1166]. 2.2. Terminology & Basics A WebP file contains either a still image (i.e., an encoded matrix of pixels) or an animation (Section 2.7.1.1). Optionally, it can also contain transparency information, color profile and metadata. In case we need to refer only to the matrix of pixels, we will call it the _canvas_ of the image. Below are additional terms used throughout this section: Reader/Writer Code that reads WebP files is referred to as a _reader_, while code that writes them is referred to as a _writer_. uint16 A 16-bit, little-endian, unsigned integer. uint24 A 24-bit, little-endian, unsigned integer. uint32 A 32-bit, little-endian, unsigned integer. Zern, et al. Expires 15 June 2023 [Page 4] Internet-Draft WebP Image Format December 2022 FourCC A FourCC (four-character code) is a uint32 created by concatenating four ASCII characters in little-endian order. This means 'aaaa' (0x61616161) and 'AAAA' (0x41414141) are treated as different FourCCs. 1-based An unsigned integer field storing values offset by -1. e.g., Such a field would store value _25_ as _24_. ChunkHeader('ABCD') This is used to describe the _FourCC_ and _Chunk Size_ header of individual chunks, where 'ABCD' is the FourCC for the chunk. This element's size is 8 bytes. 2.3. RIFF File Format The WebP file format is based on the RIFF [RIFF-spec] (Resource Interchange File Format) document format. The basic element of a RIFF file is a _chunk_. It consists of: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk FourCC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Chunk Payload : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: RIFF chunk structure Chunk FourCC: 32 bits ASCII four-character code used for chunk identification. Chunk Size: 32 bits (_uint32_) The size of the chunk in bytes, not including this field, the chunk identifier or padding. Chunk Payload: _Chunk Size_ bytes The data payload. If _Chunk Size_ is odd, a single padding byte -- that MUST be 0 to conform with RIFF [RIFF-spec] -- is added. Zern, et al. Expires 15 June 2023 [Page 5] Internet-Draft WebP Image Format December 2022 Note: RIFF has a convention that all-uppercase chunk FourCCs are standard chunks that apply to any RIFF file format, while FourCCs specific to a file format are all lowercase. WebP does not follow this convention. 2.4. WebP File Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'R' | 'I' | 'F' | 'F' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | File Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'W' | 'E' | 'B' | 'P' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: WebP file header chunk 'RIFF': 32 bits The ASCII characters 'R' 'I' 'F' 'F'. File Size: 32 bits (_uint32_) The size of the file in bytes starting at offset 8. The maximum value of this field is 2^32 minus 10 bytes and thus the size of the whole file is at most 4GiB minus 2 bytes. 'WEBP': 32 bits The ASCII characters 'W' 'E' 'B' 'P'. A WebP file MUST begin with a RIFF header with the FourCC 'WEBP'. The file size in the header is the total size of the chunks that follow plus 4 bytes for the 'WEBP' FourCC. The file SHOULD NOT contain any data after the data specified by _File Size_. Readers MAY parse such files, ignoring the trailing data. As the size of any chunk is even, the size given by the RIFF header is also even. The contents of individual chunks will be described in the following sections. 2.5. Simple File Format (Lossy) This layout SHOULD be used if the image requires lossy encoding and does not require transparency or other advanced features provided by the extended format. Files with this layout are smaller and supported by older software. Simple WebP (lossy) file format: Zern, et al. Expires 15 June 2023 [Page 6] Internet-Draft WebP Image Format December 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | WebP file header (12 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : VP8 chunk : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Simple WebP (lossy) file format VP8 chunk: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ChunkHeader('VP8 ') | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : VP8 data : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: VP8 chunk VP8 data: _Chunk Size_ bytes VP8 bitstream data. Note the fourth character in the 'VP8 ' FourCC is an ASCII space (0x20). The VP8 bitstream format specification is described by [RFC6386]. Note that the VP8 frame header contains the VP8 frame width and height. That is assumed to be the width and height of the canvas. The VP8 specification describes how to decode the image into Y'CbCr format. To convert to RGB, Rec. 601 [rec601] SHOULD be used. Applications MAY use another conversion method, but visual results may differ among decoders. 2.6. Simple File Format (Lossless) Note: Older readers may not support files using the lossless format. This layout SHOULD be used if the image requires lossless encoding (with an optional transparency channel) and does not require advanced features provided by the extended format. Zern, et al. Expires 15 June 2023 [Page 7] Internet-Draft WebP Image Format December 2022 Simple WebP (lossless) file format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | WebP file header (12 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : VP8L chunk : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Simple WebP (lossless) file format VP8L chunk: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ChunkHeader('VP8L') | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : VP8L data : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: VP8L chunk VP8L data: _Chunk Size_ bytes VP8L bitstream data. The specification of the VP8L bitstream can be found in Section 3. Note that the VP8L header contains the VP8L image width and height. That is assumed to be the width and height of the canvas. 2.7. Extended File Format Note: Older readers may not support files using the extended format. An extended format file consists of: * A 'VP8X' chunk with information about features used in the file. * An optional 'ICCP' chunk with color profile. * An optional 'ANIM' chunk with animation control data. * Image data. Zern, et al. Expires 15 June 2023 [Page 8] Internet-Draft WebP Image Format December 2022 * An optional 'EXIF' chunk with Exif metadata. * An optional 'XMP ' chunk with XMP metadata. * An optional list of unknown chunks (Section 2.7.1.6). For a _still image_, the _image data_ consists of a single frame, which is made up of: * An optional alpha subchunk (Section 2.7.1.2). * A bitstream subchunk (Section 2.7.1.3). For an _animated image_, the _image data_ consists of multiple frames. More details about frames can be found in Section 2.7.1.1. All chunks SHOULD be placed in the same order as listed above. If a chunk appears in the wrong place, the file is invalid, but readers MAY parse the file, ignoring the chunks that are out of order. Rationale: Setting the order of chunks should allow quicker file parsing. For example, if an 'ALPH' chunk does not appear in its required position, a decoder can choose to stop searching for it. The rule of ignoring late chunks should make programs that need to do a full search give the same results as the ones stopping early. Extended WebP file header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | WebP file header (12 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ChunkHeader('VP8X') | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Rsv|I|L|E|X|A|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Canvas Width Minus One | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Canvas Height Minus One | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Extended WebP file header Zern, et al. Expires 15 June 2023 [Page 9] Internet-Draft WebP Image Format December 2022 Reserved (Rsv): 2 bits MUST be 0. Readers MUST ignore this field. ICC profile (I): 1 bit Set if the file contains an ICC profile. Alpha (L): 1 bit Set if any of the frames of the image contain transparency information ("alpha"). Exif metadata (E): 1 bit Set if the file contains Exif metadata. XMP metadata (X): 1 bit Set if the file contains XMP metadata. Animation (A): 1 bit Set if this is an animated image. Data in 'ANIM' and 'ANMF' chunks should be used to control the animation. Reserved (R): 1 bit MUST be 0. Readers MUST ignore this field. Reserved: 24 bits MUST be 0. Readers MUST ignore this field. Canvas Width Minus One: 24 bits _1-based_ width of the canvas in pixels. The actual canvas width is 1 + Canvas Width Minus One Canvas Height Minus One: 24 bits _1-based_ height of the canvas in pixels. The actual canvas height is 1 + Canvas Height Minus One The product of _Canvas Width_ and _Canvas Height_ MUST be at most 2^32 - 1. Future specifications may add more fields. Unknown fields MUST be ignored. 2.7.1. Chunks 2.7.1.1. Animation An animation is controlled by ANIM and ANMF chunks. ANIM Chunk: Zern, et al. Expires 15 June 2023 [Page 10] Internet-Draft WebP Image Format December 2022 For an animated image, this chunk contains the _global parameters_ of the animation. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ChunkHeader('ANIM') | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Background Color | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: ANIM chunk Background Color: 32 bits (_uint32_) The default background color of the canvas in [Blue, Green, Red, Alpha] byte order. This color MAY be used to fill the unused space on the canvas around the frames, as well as the transparent pixels of the first frame. Background color is also used when disposal method is 1. Note: * Background color MAY contain a non-opaque alpha value, even if the _Alpha_ flag in VP8X chunk (Section 2.7, Paragraph 9) is unset. * Viewer applications SHOULD treat the background color value as a hint, and are not required to use it. * The canvas is cleared at the start of each loop. The background color MAY be used to achieve this. Loop Count: 16 bits (_uint16_) The number of times to loop the animation. 0 means infinitely. This chunk MUST appear if the _Animation_ flag in the VP8X chunk is set. If the _Animation_ flag is not set and this chunk is present, it MUST be ignored. ANMF chunk: For animated images, this chunk contains information about a _single_ frame. If the _Animation flag_ is not set, then this chunk SHOULD NOT be present. Zern, et al. Expires 15 June 2023 [Page 11] Internet-Draft WebP Image Format December 2022 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ChunkHeader('ANMF') | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame X | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Frame Y | Frame Width Minus One ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Frame Height Minus One | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Duration | Reserved |B|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Frame Data : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: ANMF chunk Frame X: 24 bits (_uint24_) The X coordinate of the upper left corner of the frame is Frame X * 2 Frame Y: 24 bits (_uint24_) The Y coordinate of the upper left corner of the frame is Frame Y * 2 Frame Width Minus One: 24 bits (_uint24_) The _1-based_ width of the frame. The frame width is 1 + Frame Width Minus One Frame Height Minus One: 24 bits (_uint24_) The _1-based_ height of the frame. The frame height is 1 + Frame Height Minus One Frame Duration: 24 bits (_uint24_) The time to wait before displaying the next frame, in 1 millisecond units. Note the interpretation of frame duration of 0 (and often <= 10) is implementation defined. Many tools and browsers assign a minimum duration similar to GIF. Reserved: 6 bits MUST be 0. Readers MUST ignore this field. Blending method (B): 1 bit Indicates how transparent pixels of _the current frame_ are to be blended with corresponding pixels of the previous canvas: Zern, et al. Expires 15 June 2023 [Page 12] Internet-Draft WebP Image Format December 2022 * 0: Use alpha blending. After disposing of the previous frame, render the current frame on the canvas using alpha-blending (Section 2.7.1.1, Paragraph 10, Item 16.4.2). If the current frame does not have an alpha channel, assume alpha value of 255, effectively replacing the rectangle. * 1: Do not blend. After disposing of the previous frame, render the current frame on the canvas by overwriting the rectangle covered by the current frame. Disposal method (D): 1 bit Indicates how _the current frame_ is to be treated after it has been displayed (before rendering the next frame) on the canvas: * 0: Do not dispose. Leave the canvas as is. * 1: Dispose to background color. Fill the _rectangle_ on the canvas covered by the _current frame_ with background color specified in the ANIM chunk (Section 2.7.1.1, Paragraph 2). Notes: * The frame disposal only applies to the _frame rectangle_, that is, the rectangle defined by _Frame X_, _Frame Y_, _frame width_ and _frame height_. It may or may not cover the whole canvas. * Alpha-blending: Given that each of the R, G, B and A channels is 8-bit, and the RGB channels are _not premultiplied_ by alpha, the formula for blending 'dst' onto 'src' is: blend.A = src.A + dst.A * (1 - src.A / 255) if blend.A = 0 then blend.RGB = 0 else blend.RGB = (src.RGB * src.A + dst.RGB * dst.A * (1 - src.A / 255)) / blend.A Zern, et al. Expires 15 June 2023 [Page 13] Internet-Draft WebP Image Format December 2022 * Alpha-blending SHOULD be done in linear color space, by taking into account the color profile (Section 2.7.1.4) of the image. If the color profile is not present, sRGB is to be assumed. (Note that sRGB also needs to be linearized due to a gamma of ~2.2). Frame Data: _Chunk Size_ - 16 bytes Consists of: * An optional alpha subchunk (Section 2.7.1.2) for the frame. * A bitstream subchunk (Section 2.7.1.3) for the frame. * An optional list of unknown chunks (Section 2.7.1.6). Note: The 'ANMF' payload, _Frame Data_ above, consists of individual _padded_ chunks as described by the RIFF file format (Section 2.3). 2.7.1.2. Alpha 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ChunkHeader('ALPH') | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Rsv| P | F | C | Alpha Bitstream... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: ALPH chunk Reserved (Rsv): 2 bits MUST be 0. Readers MUST ignore this field. Pre-processing (P): 2 bits These informative bits are used to signal the pre-processing that has been performed during compression. The decoder can use this information to e.g. dither the values or smooth the gradients prior to display. * 0: No pre-processing. * 1: Level reduction. Filtering method (F): 2 bits The filtering method used: Zern, et al. Expires 15 June 2023 [Page 14] Internet-Draft WebP Image Format December 2022 * 0: None. * 1: Horizontal filter. * 2: Vertical filter. * 3: Gradient filter. For each pixel, filtering is performed using the following calculations. Assume the alpha values surrounding the current X position are labeled as: C | B | ---+---+ A | X | Figure 11 We seek to compute the alpha value at position X. First, a prediction is made depending on the filtering method: * Method 0: predictor = 0 * Method 1: predictor = A * Method 2: predictor = B * Method 3: predictor = clip(A + B - C) where clip(v) is equal to: * 0 if v < 0 * 255 if v > 255 * v otherwise The final value is derived by adding the decompressed value X to the predictor and using modulo-256 arithmetic to wrap the [256..511] range into the [0..255] one: alpha = (predictor + X) % 256 There are special cases for the left-most and top-most pixel positions: * The top-left value at location (0, 0) uses 0 as predictor value. Otherwise, Zern, et al. Expires 15 June 2023 [Page 15] Internet-Draft WebP Image Format December 2022 * For horizontal or gradient filtering methods, the left- most pixels at location (0, y) are predicted using the location (0, y-1) just above. * For vertical or gradient filtering methods, the top-most pixels at location (x, 0) are predicted using the location (x-1, 0) on the left. Decoders are not required to use this information in any specified way. Compression method (C): 2 bits The compression method used: * 0: No compression. * 1: Compressed using the WebP lossless format. Alpha bitstream: _Chunk Size_ - 1 bytes Encoded alpha bitstream. This optional chunk contains encoded alpha data for this frame. A frame containing a 'VP8L' chunk SHOULD NOT contain this chunk. Rationale: The transparency information is already part of the 'VP8L' chunk. The alpha channel data is stored as uncompressed raw data (when compression method is '0') or compressed using the lossless format (when the compression method is '1'). * Raw data: consists of a byte sequence of length width * height, containing all the 8-bit transparency values in scan order. * Lossless format compression: the byte sequence is a compressed image-stream (as described in Section 3) of implicit dimension width x height. That is, this image-stream does NOT contain any headers describing the image dimension. Rationale: the dimension is already known from other sources, so storing it again would be redundant and error-prone. Once the image-stream is decoded into ARGB color values, following the process described in the lossless format specification, the transparency information must be extracted from the green channel of the ARGB quadruplet. Zern, et al. Expires 15 June 2023 [Page 16] Internet-Draft WebP Image Format December 2022 Rationale: the green channel is allowed extra transformation steps in the specification -- unlike the other channels -- that can improve compression. 2.7.1.3. Bitstream (VP8/VP8L) This chunk contains compressed bitstream data for a single frame. A bitstream chunk may be either (i) a VP8 chunk, using "VP8 " (note the significant fourth-character space) as its tag _or_ (ii) a VP8L chunk, using "VP8L" as its tag. The formats of VP8 and VP8L chunks are as described in Section 2.5 and Section 2.6 respectively. 2.7.1.4. Color Profile 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ChunkHeader('ICCP') | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Color Profile : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: ICCP chunk Color Profile: _Chunk Size_ bytes ICC profile. This chunk MUST appear before the image data. There SHOULD be at most one such chunk. If there are more such chunks, readers MAY ignore all except the first one. See the ICC Specification [ICC] for details. If this chunk is not present, sRGB SHOULD be assumed. 2.7.1.5. Metadata Metadata can be stored in 'EXIF' or 'XMP ' chunks. There SHOULD be at most one chunk of each type ('EXIF' and 'XMP '). If there are more such chunks, readers MAY ignore all except the first one. The chunks are defined as follows: Zern, et al. Expires 15 June 2023 [Page 17] Internet-Draft WebP Image Format December 2022 EXIF chunk: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ChunkHeader('EXIF') | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Exif Metadata : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: EXIF chunk Exif Metadata: _Chunk Size_ bytes Image metadata in [Exif] format. XMP chunk: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ChunkHeader('XMP ') | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : XMP Metadata : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: XMP chunk XMP Metadata: _Chunk Size_ bytes Image metadata in [XMP] format. Note the fourth character in the 'XMP ' FourCC is an ASCII space (0x20). Additional guidance about handling metadata can be found in the Metadata Working Group's Guidelines for Handling Metadata [MWG]. 2.7.1.6. Unknown Chunks A RIFF chunk (described in Section 2.2.) whose _chunk tag_ is different from any of the chunks described in this section, is considered an _unknown chunk_. Rationale: Allowing unknown chunks gives a provision for future extension of the format, and also allows storage of any application- specific data. Zern, et al. Expires 15 June 2023 [Page 18] Internet-Draft WebP Image Format December 2022 A file MAY contain unknown chunks: * At the end of the file as described in Section 2.7, Paragraph 9. * At the end of ANMF chunks as described in Section 2.7.1.1. Readers SHOULD ignore these chunks. Writers SHOULD preserve them in their original order (unless they specifically intend to modify these chunks). 2.7.2. Assembling the Canvas From Frames Here we provide an overview of how a reader MUST assemble a canvas in the case of an animated image. The process begins with creating a canvas using the dimensions given in the 'VP8X' chunk, Canvas Width Minus One + 1 pixels wide by Canvas Height Minus One + 1 pixels high. The Loop Count field from the 'ANIM' chunk controls how many times the animation process is repeated. This is Loop Count - 1 for non-zero Loop Count values or infinitely if Loop Count is zero. At the beginning of each loop iteration the canvas is filled using the background color from the 'ANIM' chunk or an application defined color. 'ANMF' chunks contain individual frames given in display order. Before rendering each frame, the previous frame's Disposal method is applied. The rendering of the decoded frame begins at the Cartesian coordinates (2 * Frame X, 2 * Frame Y) using the top-left corner of the canvas as the origin. Frame Width Minus One + 1 pixels wide by Frame Height Minus One + 1 pixels high are rendered onto the canvas using the Blending method. The canvas is displayed for Frame Duration milliseconds. This continues until all frames given by 'ANMF' chunks have been displayed. A new loop iteration is then begun or the canvas is left in its final state if all iterations have been completed. The following pseudocode illustrates the rendering process. The notation _VP8X.field_ means the field in the 'VP8X' chunk with the same description. Zern, et al. Expires 15 June 2023 [Page 19] Internet-Draft WebP Image Format December 2022 assert VP8X.flags.hasAnimation canvas <- new image of size VP8X.canvasWidth x VP8X.canvasHeight with background color ANIM.background_color. loop_count <- ANIM.loopCount dispose_method <- Dispose to background color if loop_count == 0: loop_count = inf frame_params <- nil assert next chunk in image_data is ANMF for loop = 0..loop_count - 1 clear canvas to ANIM.background_color or application defined color until eof or non-ANMF chunk frame_params.frameX = Frame X frame_params.frameY = Frame Y frame_params.frameWidth = Frame Width Minus One + 1 frame_params.frameHeight = Frame Height Minus One + 1 frame_params.frameDuration = Frame Duration frame_right = frame_params.frameX + frame_params.frameWidth frame_bottom = frame_params.frameY + frame_params.frameHeight assert VP8X.canvasWidth >= frame_right assert VP8X.canvasHeight >= frame_bottom for subchunk in 'Frame Data': if subchunk.tag == "ALPH": assert alpha subchunks not found in 'Frame Data' earlier frame_params.alpha = alpha_data else if subchunk.tag == "VP8 " OR subchunk.tag == "VP8L": assert bitstream subchunks not found in 'Frame Data' earlier frame_params.bitstream = bitstream_data render frame with frame_params.alpha and frame_params.bitstream on canvas with top-left corner at (frame_params.frameX, frame_params.frameY), using blending method frame_params.blendingMethod. canvas contains the decoded image. Show the contents of the canvas for frame_params.frameDuration * 1ms. dispose_method = frame_params.disposeMethod 2.7.3. Example File Layouts A lossy encoded image with alpha may look as follows: RIFF/WEBP +- VP8X (descriptions of features used) +- ALPH (alpha bitstream) +- VP8 (bitstream) Figure 15 Zern, et al. Expires 15 June 2023 [Page 20] Internet-Draft WebP Image Format December 2022 A losslessly encoded image may look as follows: RIFF/WEBP +- VP8X (descriptions of features used) +- XYZW (unknown chunk) +- VP8L (lossless bitstream) Figure 16 A lossless image with ICC profile and XMP metadata may look as follows: RIFF/WEBP +- VP8X (descriptions of features used) +- ICCP (color profile) +- VP8L (lossless bitstream) +- XMP (metadata) Figure 17 An animated image with Exif metadata may look as follows: RIFF/WEBP +- VP8X (descriptions of features used) +- ANIM (global animation parameters) +- ANMF (frame1 parameters + data) +- ANMF (frame2 parameters + data) +- ANMF (frame3 parameters + data) +- ANMF (frame4 parameters + data) +- EXIF (metadata) Figure 18 3. Specification for WebP Lossless Bitstream Note this section is based on the documentation in the libwebp source repository [webp-lossless-src]. 3.1. Abstract WebP lossless is an image format for lossless compression of ARGB images. The lossless format stores and restores the pixel values exactly, including the color values for pixels whose alpha value is 0. The format uses subresolution images, recursively embedded into the format itself, for storing statistical data about the images, such as the used entropy codes, spatial predictors, color space conversion, and color table. LZ77, prefix coding, and a color cache are used for compression of the bulk data. Decoding speeds faster Zern, et al. Expires 15 June 2023 [Page 21] Internet-Draft WebP Image Format December 2022 than PNG have been demonstrated, as well as 25% denser compression than can be achieved using today's PNG format [webp-lossless-study]. 3.2. Introduction This section describes the compressed data representation of a WebP lossless image. In this section, we extensively use C programming language syntax [ISO.9899.2018] to describe the bitstream, and assume the existence of a function for reading bits, ReadBits(n). The bytes are read in the natural order of the stream containing them, and bits of each byte are read in least-significant-bit-first order. When multiple bits are read at the same time, the integer is constructed from the original data in the original order. The most significant bits of the returned integer are also the most significant bits of the original data. Thus, the statement b = ReadBits(2); is equivalent with the two statements below: b = ReadBits(1); b |= ReadBits(1) << 1; We assume that each color component (e.g. alpha, red, blue and green) is represented using an 8-bit byte. We define the corresponding type as uint8. A whole ARGB pixel is represented by a type called uint32, an unsigned integer consisting of 32 bits. In the code showing the behavior of the transformations, alpha value is codified in bits 31..24, red in bits 23..16, green in bits 15..8 and blue in bits 7..0, but implementations of the format are free to use another representation internally. Broadly, a WebP lossless image contains header data, transform information and actual image data. Headers contain width and height of the image. A WebP lossless image can go through four different types of transformation before being entropy encoded. The transform information in the bitstream contains the data required to apply the respective inverse transforms. 3.3. Nomenclature ARGB A pixel value consisting of alpha, red, green, and blue values. Zern, et al. Expires 15 June 2023 [Page 22] Internet-Draft WebP Image Format December 2022 ARGB image A two-dimensional array containing ARGB pixels. color cache A small hash-addressed array to store recently used colors, to be able to recall them with shorter codes. color indexing image A one-dimensional image of colors that can be indexed using a small integer (up to 256 within WebP lossless). color transform image A two-dimensional subresolution image containing data about correlations of color components. distance mapping Changes LZ77 distances to have the smallest values for pixels in 2D proximity. entropy image A two-dimensional subresolution image indicating which entropy coding should be used in a respective square in the image, i.e., each pixel is a meta prefix code. prefix code A classic way to do entropy coding where a smaller number of bits are used for more frequent codes. [LZ77] Dictionary-based sliding window compression algorithm that either emits symbols or describes them as sequences of past symbols. meta prefix code A small integer (up to 16 bits) that indexes an element in the meta prefix table. predictor image A two-dimensional subresolution image indicating which spatial predictor is used for a particular square in the image. prefix coding A way to entropy code larger integers that codes a few bits of the integer using an entropy code and codifies the remaining bits raw. This allows for the descriptions of the entropy codes to remain relatively small even when the range of symbols is large. Zern, et al. Expires 15 June 2023 [Page 23] Internet-Draft WebP Image Format December 2022 scan-line order A processing order of pixels, left-to-right, top-to-bottom, starting from the left-hand-top pixel, proceeding to the right. Once a row is completed, continue from the left-hand column of the next row. 3.4. RIFF Header The beginning of the header has the RIFF container. This consists of the following 21 bytes: 1. String "RIFF" 2. A little-endian 32 bit value of the block length, the whole size of the block controlled by the RIFF header. Normally this equals the payload size (file size minus 8 bytes: 4 bytes for the 'RIFF' identifier and 4 bytes for storing the value itself). 3. String "WEBP" (RIFF container name). 4. String "VP8L" (chunk tag for lossless encoded image data). 5. A little-endian 32-bit value of the number of bytes in the lossless stream. 6. One byte signature 0x2f. The first 28 bits of the bitstream specify the width and height of the image. Width and height are decoded as 14-bit integers as follows: int image_width = ReadBits(14) + 1; int image_height = ReadBits(14) + 1; The 14-bit dynamics for image size limit the maximum size of a WebP lossless image to 16384x16384 pixels. The alpha_is_used bit is a hint only, and SHOULD NOT impact decoding. It SHOULD be set to 0 when all alpha values are 255 in the picture, and 1 otherwise. int alpha_is_used = ReadBits(1); The version_number is a 3 bit code that MUST be set to 0. Any other value MUST be treated as an error. int version_number = ReadBits(3); Zern, et al. Expires 15 June 2023 [Page 24] Internet-Draft WebP Image Format December 2022 3.5. Transformations Transformations are reversible manipulations of the image data that can reduce the remaining symbolic entropy by modeling spatial and color correlations. Transformations can make the final compression more dense. An image can go through four types of transformation. A 1 bit indicates the presence of a transform. Each transform is allowed to be used only once. The transformations are used only for the main level ARGB image: the subresolution images have no transforms, not even the 0 bit indicating the end-of-transforms. Typically, an encoder would use these transforms to reduce the Shannon entropy in the residual image. Also, the transform data can be decided based on entropy minimization. while (ReadBits(1)) { // Transform present. // Decode transform type. enum TransformType transform_type = ReadBits(2); // Decode transform data. ... } // Decode actual image data. If a transform is present then the next two bits specify the transform type. There are four types of transforms. enum TransformType { PREDICTOR_TRANSFORM = 0, COLOR_TRANSFORM = 1, SUBTRACT_GREEN_TRANSFORM = 2, COLOR_INDEXING_TRANSFORM = 3, }; The transform type is followed by the transform data. Transform data contains the information required to apply the inverse transform and depends on the transform type. Next we describe the transform data for different types. Zern, et al. Expires 15 June 2023 [Page 25] Internet-Draft WebP Image Format December 2022 3.5.1. Predictor Transform The predictor transform can be used to reduce entropy by exploiting the fact that neighboring pixels are often correlated. In the predictor transform, the current pixel value is predicted from the pixels already decoded (in scan-line order) and only the residual value (actual - predicted) is encoded. The _prediction mode_ determines the type of prediction to use. We divide the image into squares and all the pixels in a square use the same prediction mode. The first 3 bits of prediction data define the block width and height in number of bits. The number of block columns, block_xsize, is used in indexing two-dimensionally. int size_bits = ReadBits(3) + 2; int block_width = (1 << size_bits); int block_height = (1 << size_bits); #define DIV_ROUND_UP(num, den) ((num) + (den) - 1) / (den)) int block_xsize = DIV_ROUND_UP(image_width, 1 << size_bits); The transform data contains the prediction mode for each block of the image. All the block_width * block_height pixels of a block use same prediction mode. The prediction modes are treated as pixels of an image and encoded using the same techniques described in Section 3.6. For a pixel _x, y_, one can compute the respective filter block address by: int block_index = (y >> size_bits) * block_xsize + (x >> size_bits); There are 14 different prediction modes. In each prediction mode, the current pixel value is predicted from one or more neighboring pixels whose values are already known. We choose the neighboring pixels (TL, T, TR, and L) of the current pixel (P) as follows: O O O O O O O O O O O O O O O O O O O O O O O O O O TL T TR O O O O O O O O L P X X X X X X X X X X X X X X X X X X X X X X X X X X X Figure 19 Zern, et al. Expires 15 June 2023 [Page 26] Internet-Draft WebP Image Format December 2022 where TL means top-left, T top, TR top-right, L left pixel. At the time of predicting a value for P, all pixels O, TL, T, TR and L have already been processed, and pixel P and all pixels X are unknown. Given the above neighboring pixels, the different prediction modes are defined as follows. | Mode | Predicted value of each channel of the current pixel | | ------ | ------------------------------------------------------- | | 0 | 0xff000000 (represents solid black color in ARGB) | | 1 | L | | 2 | T | | 3 | TR | | 4 | TL | | 5 | Average2(Average2(L, TR), T) | | 6 | Average2(L, TL) | | 7 | Average2(L, T) | | 8 | Average2(TL, T) | | 9 | Average2(T, TR) | | 10 | Average2(Average2(L, TL), Average2(T, TR)) | | 11 | Select(L, T, TL) | | 12 | ClampAddSubtractFull(L, T, TL) | | 13 | ClampAddSubtractHalf(Average2(L, T), TL) | Figure 20 Average2 is defined as follows for each ARGB component: uint8 Average2(uint8 a, uint8 b) { return (a + b) / 2; } The Select predictor is defined as follows: Zern, et al. Expires 15 June 2023 [Page 27] Internet-Draft WebP Image Format December 2022 uint32 Select(uint32 L, uint32 T, uint32 TL) { // L = left pixel, T = top pixel, TL = top left pixel. // ARGB component estimates for prediction. int pAlpha = ALPHA(L) + ALPHA(T) - ALPHA(TL); int pRed = RED(L) + RED(T) - RED(TL); int pGreen = GREEN(L) + GREEN(T) - GREEN(TL); int pBlue = BLUE(L) + BLUE(T) - BLUE(TL); // Manhattan distances to estimates for left and top pixels. int pL = abs(pAlpha - ALPHA(L)) + abs(pRed - RED(L)) + abs(pGreen - GREEN(L)) + abs(pBlue - BLUE(L)); int pT = abs(pAlpha - ALPHA(T)) + abs(pRed - RED(T)) + abs(pGreen - GREEN(T)) + abs(pBlue - BLUE(T)); // Return either left or top, the one closer to the prediction. if (pL < pT) { return L; } else { return T; } } The functions ClampAddSubtractFull and ClampAddSubtractHalf are performed for each ARGB component as follows: // Clamp the input value between 0 and 255. int Clamp(int a) { return (a < 0) ? 0 : (a > 255) ? 255 : a; } int ClampAddSubtractFull(int a, int b, int c) { return Clamp(a + b - c); } int ClampAddSubtractHalf(int a, int b) { return Clamp(a + (a - b) / 2); } There are special handling rules for some border pixels. If there is a prediction transform, regardless of the mode [0..13] for these pixels, the predicted value for the left-topmost pixel of the image is 0xff000000, L-pixel for all pixels on the top row, and T-pixel for all pixels on the leftmost column. Zern, et al. Expires 15 June 2023 [Page 28] Internet-Draft WebP Image Format December 2022 Addressing the TR-pixel for pixels on the rightmost column is exceptional. The pixels on the rightmost column are predicted by using the modes [0..13] just like pixels not on the border, but the leftmost pixel on the same row as the current pixel is instead used as the TR-pixel. 3.5.2. Color Transform The goal of the color transform is to decorrelate the R, G and B values of each pixel. The color transform keeps the green (G) value as it is, transforms red (R) based on green and transforms blue (B) based on green and then based on red. As is the case for the predictor transform, first the image is divided into blocks and the same transform mode is used for all the pixels in a block. For each block there are three types of color transform elements. typedef struct { uint8 green_to_red; uint8 green_to_blue; uint8 red_to_blue; } ColorTransformElement; The actual color transformation is done by defining a color transform delta. The color transform delta depends on the ColorTransformElement, which is the same for all the pixels in a particular block. The delta is subtracted during the color transform. The inverse color transform then is just adding those deltas. The color transform function is defined as follows: void ColorTransform(uint8 red, uint8 blue, uint8 green, ColorTransformElement *trans, uint8 *new_red, uint8 *new_blue) { // Transformed values of red and blue components int tmp_red = red; int tmp_blue = blue; // Applying the transform is just subtracting the transform deltas tmp_red -= ColorTransformDelta(trans->green_to_red_, green); tmp_blue -= ColorTransformDelta(trans->green_to_blue_, green); tmp_blue -= ColorTransformDelta(trans->red_to_blue_, red); *new_red = tmp_red & 0xff; *new_blue = tmp_blue & 0xff; } Zern, et al. Expires 15 June 2023 [Page 29] Internet-Draft WebP Image Format December 2022 ColorTransformDelta is computed using a signed 8-bit integer representing a 3.5-fixed-point number, and a signed 8-bit RGB color channel (c) [-128..127] and is defined as follows: int8 ColorTransformDelta(int8 t, int8 c) { return (t * c) >> 5; } A conversion from the 8-bit unsigned representation (uint8) to the 8-bit signed one (int8) is required before calling ColorTransformDelta(). It should be performed using 8-bit two's complement (that is: uint8 range [128..255] is mapped to the [-128..-1] range of its converted int8 value). The multiplication is to be done using more precision (with at least 16-bit dynamics). The sign extension property of the shift operation does not matter here: only the lowest 8 bits are used from the result, and there the sign extension shifting and unsigned shifting are consistent with each other. Now we describe the contents of color transform data so that decoding can apply the inverse color transform and recover the original red and blue values. The first 3 bits of the color transform data contain the width and height of the image block in number of bits, just like the predictor transform: int size_bits = ReadBits(3) + 2; int block_width = 1 << size_bits; int block_height = 1 << size_bits; The remaining part of the color transform data contains ColorTransformElement instances corresponding to each block of the image. ColorTransformElement instances are treated as pixels of an image and encoded using the methods described in Section 3.6. During decoding, ColorTransformElement instances of the blocks are decoded and the inverse color transform is applied on the ARGB values of the pixels. As mentioned earlier, that inverse color transform is just adding ColorTransformElement values to the red and blue channels. Zern, et al. Expires 15 June 2023 [Page 30] Internet-Draft WebP Image Format December 2022 void InverseTransform(uint8 red, uint8 green, uint8 blue, ColorTransformElement *trans, uint8 *new_red, uint8 *new_blue) { // Transformed values of red and blue components int tmp_red = red; int tmp_blue = blue; // Applying the inverse transform is just adding the // color transform deltas tmp_red += ColorTransformDelta(trans->green_to_red, green); tmp_blue += ColorTransformDelta(trans->green_to_blue, green); tmp_blue += ColorTransformDelta(trans->red_to_blue, tmp_red & 0xff); *new_red = tmp_red & 0xff; *new_blue = tmp_blue & 0xff; } 3.5.3. Subtract Green Transform The subtract green transform subtracts green values from red and blue values of each pixel. When this transform is present, the decoder needs to add the green value to both red and blue. There is no data associated with this transform. The decoder applies the inverse transform as follows: void AddGreenToBlueAndRed(uint8 green, uint8 *red, uint8 *blue) { *red = (*red + green) & 0xff; *blue = (*blue + green) & 0xff; } This transform is redundant as it can be modeled using the color transform, but it is still often useful. Since it can extend the dynamics of the color transform and there is no additional data here, the subtract green transform can be coded using fewer bits than a full-blown color transform. 3.5.4. Color Indexing Transform If there are not many unique pixel values, it may be more efficient to create a color index array and replace the pixel values by the array's indices. The color indexing transform achieves this. (In the context of WebP lossless, we specifically do not call this a palette transform because a similar but more dynamic concept exists in WebP lossless encoding: color cache). Zern, et al. Expires 15 June 2023 [Page 31] Internet-Draft WebP Image Format December 2022 The color indexing transform checks for the number of unique ARGB values in the image. If that number is below a threshold (256), it creates an array of those ARGB values, which is then used to replace the pixel values with the corresponding index: the green channel of the pixels are replaced with the index; all alpha values are set to 255; all red and blue values to 0. The transform data contains color table size and the entries in the color table. The decoder reads the color indexing transform data as follows: // 8 bit value for color table size int color_table_size = ReadBits(8) + 1; The color table is stored using the image storage format itself. The color table can be obtained by reading an image, without the RIFF header, image size, and transforms, assuming a height of one pixel and a width of color_table_size. The color table is always subtraction-coded to reduce image entropy. The deltas of palette colors contain typically much less entropy than the colors themselves, leading to significant savings for smaller images. In decoding, every final color in the color table can be obtained by adding the previous color component values by each ARGB component separately, and storing the least significant 8 bits of the result. The inverse transform for the image is simply replacing the pixel values (which are indices to the color table) with the actual color table values. The indexing is done based on the green component of the ARGB color. // Inverse transform argb = color_table[GREEN(argb)]; If the index is equal or larger than color_table_size, the argb color value should be set to 0x00000000 (transparent black). When the color table is small (equal to or less than 16 colors), several pixels are bundled into a single pixel. The pixel bundling packs several (2, 4, or 8) pixels into a single pixel, reducing the image width respectively. Pixel bundling allows for a more efficient joint distribution entropy coding of neighboring pixels, and gives some arithmetic coding-like benefits to the entropy code, but it can only be used when there are 16 or fewer unique values. color_table_size specifies how many pixels are combined: Zern, et al. Expires 15 June 2023 [Page 32] Internet-Draft WebP Image Format December 2022 int width_bits; if (color_table_size <= 2) { width_bits = 3; } else if (color_table_size <= 4) { width_bits = 2; } else if (color_table_size <= 16) { width_bits = 1; } else { width_bits = 0; } width_bits has a value of 0, 1, 2 or 3. A value of 0 indicates no pixel bundling is to be done for the image. A value of 1 indicates that two pixels are combined, and each pixel has a range of [0..15]. A value of 2 indicates that four pixels are combined, and each pixel has a range of [0..3]. A value of 3 indicates that eight pixels are combined, and each pixel has a range of [0..1], i.e., a binary value. The values are packed into the green component as follows: * width_bits = 1: for every x value where x = 2k + 0, a green value at x is positioned into the 4 least-significant bits of the green value at x / 2, a green value at x + 1 is positioned into the 4 most-significant bits of the green value at x / 2. * width_bits = 2: for every x value where x = 4k + 0, a green value at x is positioned into the 2 least-significant bits of the green value at x / 4, green values at x + 1 to x + 3 are positioned in order to the more significant bits of the green value at x / 4. * width_bits = 3: for every x value where x = 8k + 0, a green value at x is positioned into the least-significant bit of the green value at x / 8, green values at x + 1 to x + 7 are positioned in order to the more significant bits of the green value at x / 8. 3.6. Image Data Image data is an array of pixel values in scan-line order. 3.6.1. Roles of Image Data We use image data in five different roles: 1. ARGB image: Stores the actual pixels of the image. 2. Entropy image: Stores the meta prefix codes (Section 3.7.2.2). The red and green components of a pixel define the meta prefix code used in a particular block of the ARGB image. Zern, et al. Expires 15 June 2023 [Page 33] Internet-Draft WebP Image Format December 2022 3. Predictor image: Stores the metadata for Predictor Transform (Section 3.5.1). The green component of a pixel defines which of the 14 predictors is used within a particular block of the ARGB image. 4. Color transform image. It is created by ColorTransformElement values (defined in Color Transform (Section 3.5.2)) for different blocks of the image. Each ColorTransformElement 'cte' is treated as a pixel whose alpha component is 255, red component is cte.red_to_blue, green component is cte.green_to_blue and blue component is cte.green_to_red. 5. Color indexing image: An array of size color_table_size (up to 256 ARGB values) storing the metadata for the Color Indexing Transform (Section 3.5.4). This is stored as an image of width color_table_size and height 1. 3.6.2. Encoding of Image Data The encoding of image data is independent of its role. The image is first divided into a set of fixed-size blocks (typically 16x16 blocks). Each of these blocks are modeled using their own entropy codes. Also, several blocks may share the same entropy codes. Rationale: Storing an entropy code incurs a cost. This cost can be minimized if statistically similar blocks share an entropy code, thereby storing that code only once. For example, an encoder can find similar blocks by clustering them using their statistical properties, or by repeatedly joining a pair of randomly selected clusters when it reduces the overall amount of bits needed to encode the image. Each pixel is encoded using one of the three possible methods: 1. Prefix coded literal: each channel (green, red, blue and alpha) is entropy-coded independently; 2. LZ77 backward reference: a sequence of pixels are copied from elsewhere in the image; or 3. Color cache code: using a short multiplicative hash code (color cache index) of a recently seen color. The following subsections describe each of these in detail. Zern, et al. Expires 15 June 2023 [Page 34] Internet-Draft WebP Image Format December 2022 3.6.2.1. Prefix Coded Literals The pixel is stored as prefix coded values of green, red, blue and alpha (in that order). See Section 3.7.2.3 for details. 3.6.2.2. LZ77 Backward Reference Backward references are tuples of _length_ and _distance code_: * Length indicates how many pixels in scan-line order are to be copied. * Distance code is a number indicating the position of a previously seen pixel, from which the pixels are to be copied. The exact mapping is described below (Section 3.6.2.2, Paragraph 11). The length and distance values are stored using *LZ77 prefix coding*. LZ77 prefix coding divides large integer values into two parts: the _prefix code_ and the _extra bits_: the prefix code is stored using an entropy code, while the extra bits are stored as they are (without an entropy code). Rationale: This approach reduces the storage requirement for the entropy code. Also, large values are usually rare, and so extra bits would be used for very few values in the image. Thus, this approach results in better compression overall. The following table denotes the prefix codes and extra bits used for storing different ranges of values. Note: The maximum backward reference length is limited to 4096. Hence, only the first 24 prefix codes (with the respective extra bits) are meaningful for length values. For distance values, however, all the 40 prefix codes are valid. Zern, et al. Expires 15 June 2023 [Page 35] Internet-Draft WebP Image Format December 2022 | Value range | Prefix code | Extra bits | | --------------- | ----------- | ---------- | | 1 | 0 | 0 | | 2 | 1 | 0 | | 3 | 2 | 0 | | 4 | 3 | 0 | | 5..6 | 4 | 1 | | 7..8 | 5 | 1 | | 9..12 | 6 | 2 | | 13..16 | 7 | 2 | | ... | ... | ... | | 3072..4096 | 23 | 10 | | ... | ... | ... | | 524289..786432 | 38 | 18 | | 786433..1048576 | 39 | 18 | Figure 21 The pseudocode to obtain a (length or distance) value from the prefix code is as follows: if (prefix_code < 4) { return prefix_code + 1; } int extra_bits = (prefix_code - 2) >> 1; int offset = (2 + (prefix_code & 1)) << extra_bits; return offset + ReadBits(extra_bits) + 1; Distance Mapping: As noted previously, a distance code is a number indicating the position of a previously seen pixel, from which the pixels are to be copied. This subsection defines the mapping between a distance code and the position of a previous pixel. Distance codes larger than 120 denote the pixel-distance in scan-line order, offset by 120. The smallest distance codes [1..120] are special, and are reserved for a close neighborhood of the current pixel. This neighborhood consists of 120 pixels: * Pixels that are 1 to 7 rows above the current pixel, and are up to 8 columns to the left or up to 7 columns to the right of the current pixel. [Total such pixels = 7 * (8 + 1 + 7) = 112]. * Pixels that are in same row as the current pixel, and are up to 8 columns to the left of the current pixel. [8 such pixels]. Zern, et al. Expires 15 June 2023 [Page 36] Internet-Draft WebP Image Format December 2022 The mapping between distance code i and the neighboring pixel offset (xi, yi) is as follows: (0, 1), (1, 0), (1, 1), (-1, 1), (0, 2), (2, 0), (1, 2), (-1, 2), (2, 1), (-2, 1), (2, 2), (-2, 2), (0, 3), (3, 0), (1, 3), (-1, 3), (3, 1), (-3, 1), (2, 3), (-2, 3), (3, 2), (-3, 2), (0, 4), (4, 0), (1, 4), (-1, 4), (4, 1), (-4, 1), (3, 3), (-3, 3), (2, 4), (-2, 4), (4, 2), (-4, 2), (0, 5), (3, 4), (-3, 4), (4, 3), (-4, 3), (5, 0), (1, 5), (-1, 5), (5, 1), (-5, 1), (2, 5), (-2, 5), (5, 2), (-5, 2), (4, 4), (-4, 4), (3, 5), (-3, 5), (5, 3), (-5, 3), (0, 6), (6, 0), (1, 6), (-1, 6), (6, 1), (-6, 1), (2, 6), (-2, 6), (6, 2), (-6, 2), (4, 5), (-4, 5), (5, 4), (-5, 4), (3, 6), (-3, 6), (6, 3), (-6, 3), (0, 7), (7, 0), (1, 7), (-1, 7), (5, 5), (-5, 5), (7, 1), (-7, 1), (4, 6), (-4, 6), (6, 4), (-6, 4), (2, 7), (-2, 7), (7, 2), (-7, 2), (3, 7), (-3, 7), (7, 3), (-7, 3), (5, 6), (-5, 6), (6, 5), (-6, 5), (8, 0), (4, 7), (-4, 7), (7, 4), (-7, 4), (8, 1), (8, 2), (6, 6), (-6, 6), (8, 3), (5, 7), (-5, 7), (7, 5), (-7, 5), (8, 4), (6, 7), (-6, 7), (7, 6), (-7, 6), (8, 5), (7, 7), (-7, 7), (8, 6), (8, 7) Figure 22 For example, the distance code 1 indicates an offset of (0, 1) for the neighboring pixel, that is, the pixel above the current pixel (0-pixel difference in the X-direction and 1 pixel difference in the Y-direction). Similarly, the distance code 3 indicates the left-top pixel. The decoder can convert a distance code i to a scan-line order distance dist as follows: (xi, yi) = distance_map[i - 1] dist = xi + yi * xsize if (dist < 1) { dist = 1 } where distance_map is the mapping noted above and xsize is the width of the image in pixels. 3.6.2.3. Color Cache Coding Color cache stores a set of colors that have been recently used in the image. Zern, et al. Expires 15 June 2023 [Page 37] Internet-Draft WebP Image Format December 2022 Rationale: This way, the recently used colors can sometimes be referred to more efficiently than emitting them using the other two methods (described in Section 3.6.2.1 and Section 3.6.2.2). Color cache codes are stored as follows. First, there is a 1-bit value that indicates if the color cache is used. If this bit is 0, no color cache codes exist, and they are not transmitted in the prefix code that decodes the green symbols and the length prefix codes. However, if this bit is 1, the color cache size is read next: int color_cache_code_bits = ReadBits(4); int color_cache_size = 1 << color_cache_code_bits; color_cache_code_bits defines the size of the color_cache by (1 << color_cache_code_bits). The range of allowed values for color_cache_code_bits is [1..11]. Compliant decoders MUST indicate a corrupted bitstream for other values. A color cache is an array of size color_cache_size. Each entry stores one ARGB color. Colors are looked up by indexing them by (0x1e35a7bd * color) >> (32 - color_cache_code_bits). Only one lookup is done in a color cache; there is no conflict resolution. In the beginning of decoding or encoding of an image, all entries in all color cache values are set to zero. The color cache code is converted to this color at decoding time. The state of the color cache is maintained by inserting every pixel, be it produced by backward referencing or as literals, into the cache in the order they appear in the stream. 3.7. Entropy Code 3.7.1. Overview Most of the data is coded using a canonical prefix code [Huffman]. Hence, the codes are transmitted by sending the _prefix code lengths_, as opposed to the actual _prefix codes_. In particular, the format uses *spatially-variant prefix coding*. In other words, different blocks of the image can potentially use different entropy codes. Rationale: Different areas of the image may have different characteristics. So, allowing them to use different entropy codes provides more flexibility and potentially better compression. Zern, et al. Expires 15 June 2023 [Page 38] Internet-Draft WebP Image Format December 2022 3.7.2. Details The encoded image data consists of several parts: 1. Decoding and building the prefix codes 2. Meta prefix codes 3. Entropy-coded image data 3.7.2.1. Decoding and Building the Prefix Codes There are several steps in decoding the prefix codes. *Decoding the Code Lengths:* This section describes how to read the prefix code lengths from the bitstream. The prefix code lengths can be coded in two ways. The method used is specified by a 1-bit value. * If this bit is 1, it is a _simple code length code_, and * If this bit is 0, it is a _normal code length code_. In both cases, there can be unused code lengths that are still part of the stream. This may be inefficient, but it is allowed by the format. *(i) Simple Code Length Code:* This variant is used in the special case when only 1 or 2 prefix symbols are in the range [0..255] with code length 1. All other prefix code lengths are implicitly zeros. The first bit indicates the number of symbols: int num_symbols = ReadBits(1) + 1; Following are the symbol values. This first symbol is coded using 1 or 8 bits depending on the value of is_first_8bits. The range is [0..1] or [0..255], respectively. The second symbol, if present, is always assumed to be in the range [0..255] and coded using 8 bits. Zern, et al. Expires 15 June 2023 [Page 39] Internet-Draft WebP Image Format December 2022 int is_first_8bits = ReadBits(1); symbol0 = ReadBits(1 + 7 * is_first_8bits); code_lengths[symbol0] = 1; if (num_symbols == 2) { symbol1 = ReadBits(8); code_lengths[symbol1] = 1; } Note: Another special case is when _all_ prefix code lengths are _zeros_ (an empty prefix code). For example, a prefix code for distance can be empty if there are no backward references. Similarly, prefix codes for alpha, red, and blue can be empty if all pixels within the same meta prefix code are produced using the color cache. However, this case doesn't need special handling, as empty prefix codes can be coded as those containing a single symbol 0. *(ii) Normal Code Length Code:* The code lengths of the prefix code fit in 8 bits and are read as follows. First, num_code_lengths specifies the number of code lengths. int num_code_lengths = 4 + ReadBits(4); If num_code_lengths is > 19, the bitstream is invalid. The code lengths are themselves encoded using prefix codes: lower level code lengths, code_length_code_lengths, first have to be read. The rest of those code_length_code_lengths (according to the order in kCodeLengthCodeOrder) are zeros. int kCodeLengthCodes = 19; int kCodeLengthCodeOrder[kCodeLengthCodes] = { 17, 18, 0, 1, 2, 3, 4, 5, 16, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 }; int code_length_code_lengths[kCodeLengthCodes] = { 0 }; // All zeros for (i = 0; i < num_code_lengths; ++i) { code_length_code_lengths[kCodeLengthCodeOrder[i]] = ReadBits(3); } Next, if ReadBits(1) == 0, the maximum number of different read symbols is num_code_lengths. Otherwise, it is defined as: int length_nbits = 2 + 2 * ReadBits(3); int max_symbol = 2 + ReadBits(length_nbits); A prefix table is then built from code_length_code_lengths and used to read up to max_symbol code lengths. Zern, et al. Expires 15 June 2023 [Page 40] Internet-Draft WebP Image Format December 2022 * Code [0..15] indicates literal code lengths. - Value 0 means no symbols have been coded. - Values [1..15] indicate the bit length of the respective code. * Code 16 repeats the previous non-zero value [3..6] times, i.e., 3 + ReadBits(2) times. If code 16 is used before a non-zero value has been emitted, a value of 8 is repeated. * Code 17 emits a streak of zeros [3..10], i.e., 3 + ReadBits(3) times. * Code 18 emits a streak of zeros of length [11..138], i.e., 11 + ReadBits(7) times. Once code lengths are read, a prefix code for each symbol type (A, R, G, B, distance) is formed using their respective alphabet sizes: * G channel: 256 + 24 + color_cache_size * other literals (A,R,B): 256 * distance code: 40 3.7.2.2. Decoding of Meta Prefix Codes As noted earlier, the format allows the use of different prefix codes for different blocks of the image. _Meta prefix codes_ are indexes identifying which prefix codes to use in different parts of the image. Meta prefix codes may be used _only_ when the image is being used in the role (Section 3.6.1) of an _ARGB image_. There are two possibilities for the meta prefix codes, indicated by a 1-bit value: * If this bit is zero, there is only one meta prefix code used everywhere in the image. No more data is stored. * If this bit is one, the image uses multiple meta prefix codes. These meta prefix codes are stored as an _entropy image_ (described below). Entropy image: Zern, et al. Expires 15 June 2023 [Page 41] Internet-Draft WebP Image Format December 2022 The entropy image defines which prefix codes are used in different parts of the image, as described below. The first 3-bits contain the prefix_bits value. The dimensions of the entropy image are derived from prefix_bits. int prefix_bits = ReadBits(3) + 2; int prefix_xsize = DIV_ROUND_UP(xsize, 1 << prefix_bits); int prefix_ysize = DIV_ROUND_UP(ysize, 1 << prefix_bits); where DIV_ROUND_UP is as defined in Section 3.5.1. The next bits contain an entropy image of width prefix_xsize and height prefix_ysize. Interpretation of Meta Prefix Codes: For any given pixel (x, y), there is a set of five prefix codes associated with it. These codes are (in bitstream order): * *Prefix code #1*: used for green channel, backward-reference length and color cache. * *Prefix code #2, #3 and #4*: used for red, blue and alpha channels respectively. * *Prefix code #5*: used for backward-reference distance. From here on, we refer to this set as a *prefix code group*. The number of prefix code groups in the ARGB image can be obtained by finding the _largest meta prefix code_ from the entropy image: int num_prefix_groups = max(entropy image) + 1; where max(entropy image) indicates the largest prefix code stored in the entropy image. As each prefix code group contains five prefix codes, the total number of prefix codes is: int num_prefix_codes = 5 * num_prefix_groups; Given a pixel (x, y) in the ARGB image, we can obtain the corresponding prefix codes to be used as follows: Zern, et al. Expires 15 June 2023 [Page 42] Internet-Draft WebP Image Format December 2022 int position = (y >> prefix_bits) * prefix_xsize + (x >> prefix_bits); int meta_prefix_code = (entropy_image[pos] >> 8) & 0xffff; PrefixCodeGroup prefix_group = prefix_code_groups[meta_prefix_code]; where, we have assumed the existence of PrefixCodeGroup structure, which represents a set of five prefix codes. Also, prefix_code_groups is an array of PrefixCodeGroup (of size num_prefix_groups). The decoder then uses prefix code group prefix_group to decode the pixel (x, y) as explained in Section 3.7.2.3. 3.7.2.3. Decoding Entropy-coded Image Data For the current position (x, y) in the image, the decoder first identifies the corresponding prefix code group (as explained in the last section). Given the prefix code group, the pixel is read and decoded as follows: Read next the symbol S from the bitstream using prefix code #1. Note that S is any integer in the range 0 to (256 + 24 + color_cache_size (Section 3.6.2.3)- 1). The interpretation of S depends on its value: 1. if S < 256 i. Use S as the green component. ii. Read red from the bitstream using prefix code #2. iii. Read blue from the bitstream using prefix code #3. iv. Read alpha from the bitstream using prefix code #4. 2. if S >= 256 && S < 256 + 24 i. Use S - 256 as a length prefix code. ii. Read extra bits for length from the bitstream. iii. Determine backward-reference length L from length prefix code and the extra bits read. iv. Read distance prefix code from the bitstream using prefix code #5. Zern, et al. Expires 15 June 2023 [Page 43] Internet-Draft WebP Image Format December 2022 v. Read extra bits for distance from the bitstream. vi. Determine backward-reference distance D from distance prefix code and the extra bits read. vii. Copy the L pixels (in scan-line order) from the sequence of pixels prior to them by D pixels. 3. if S >= 256 + 24 i. Use S - (256 + 24) as the index into the color cache. ii. Get ARGB color from the color cache at that index. 3.8. Overall Structure of the Format Below is a view into the format in Augmented Backus-Naur Form [RFC5234]. It does not cover all details. End-of-image (EOI) is only implicitly coded into the number of pixels (xsize * ysize). 3.8.1. Basic Structure format = RIFF-header image-size image-stream RIFF-header = "RIFF" 4OCTET "WEBP" "VP8L" 4OCTET %x2F image-size = 14BIT 14BIT ; width - 1, height - 1 image-stream = optional-transform spatially-coded-image 3.8.2. Structure of Transforms optional-transform = (%b1 transform optional-transform) / %b0 transform = predictor-tx / color-tx / subtract-green-tx transform =/ color-indexing-tx predictor-tx = %b00 predictor-image predictor-image = 3BIT ; sub-pixel code entropy-coded-image color-tx = %b01 color-image color-image = 3BIT ; sub-pixel code entropy-coded-image subtract-green-tx = %b10 color-indexing-tx = %b11 color-indexing-image color-indexing-image = 8BIT ; color count entropy-coded-image Zern, et al. Expires 15 June 2023 [Page 44] Internet-Draft WebP Image Format December 2022 3.8.3. Structure of the Image Data spatially-coded-image = color-cache-info meta-prefix data entropy-coded-image = color-cache-info data color-cache-info = %b0 color-cache-info =/ (%b1 4BIT) ; 1 followed by color cache size meta-prefix = %b0 / (%b1 entropy-image) data = prefix-codes lz77-coded-image entropy-image = 3BIT ; subsample value entropy-coded-image prefix-codes = prefix-code-group *prefix-codes prefix-code-group = 5prefix-code ; See "Interpretation of Meta Prefix Codes" to ; understand what each of these five prefix ; codes are for. prefix-code = simple-prefix-code / normal-prefix-code simple-prefix-code = ; see "Simple Code Length Code" for details normal-prefix-code = code-length-code encoded-code-lengths code-length-code = ; see section "Normal Code Length Code" lz77-coded-image = *((argb-pixel / lz77-copy / color-cache-code) lz77-coded-image) A possible example sequence: RIFF-header image-size %b1 subtract-green-tx %b1 predictor-tx %b0 color-cache-info %b0 prefix-codes lz77-coded-image 4. Security Considerations Implementations of this format face security risks such as integer overflows, out-of-bounds reads and writes to both heap and stack, uninitialized data usage, null pointer dereferences, resource (disk, memory) exhaustion and extended resource usage (long running time) as part of the demuxing and decoding process. In particular, implementations reading this format are likely to take input from unknown and possibly unsafe sources -- both clients (e.g., web browsers, email clients) and servers (e.g., applications which accept uploaded images). These may result in arbitrary code execution, information leakage (memory layout and contents) or crashes and thereby allow a device to be compromised or cause a denial of service to an application using the format [cve.mitre.org-libwebp] Zern, et al. Expires 15 June 2023 [Page 45] Internet-Draft WebP Image Format December 2022 [crbug-security]. The format does not employ "active content", but does allow metadata ([XMP], [Exif]) and custom chunks to be embedded in a file. Applications that interpret these chunks may be subject to security considerations for those formats. 5. Interoperability Considerations The format is defined using little-endian byte ordering (see Section 3.1 of [RFC2781]), but demuxing and decoding are possible on platforms using a different ordering with the appropriate conversion. The container is RIFF-based and allows extension via user defined chunks, but nothing beyond the chunks defined by the container format (Section 2) are required for decoding of the image. These have been finalized, but were extended in the format's early stages, so some older readers may not support lossless or animated image decoding. 6. IANA Considerations IANA has registered the following media type [RFC2046]. 6.1. The 'image/webp' Media Type This section contains the media type registration details as per [RFC6838]. 6.1.1. Registration Details *RFC Editor Note:* Replace RFCXXXX with the published RFC number and add an xref to the entry in the Normative References section. Type name: image Subtype name: webp Required parameters: N/A Optional parameters: N/A Encoding considerations: Binary. The Base64 encoding [RFC4648] should be used on transports that cannot accommodate binary data directly. Security considerations: See Section 4. Interoperability considerations: See Section 5. Zern, et al. Expires 15 June 2023 [Page 46] Internet-Draft WebP Image Format December 2022 Published specification: RFCXXXX Applications that use this media type: Applications that are used to display and process images, especially when smaller image file sizes are important. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): The first 4 bytes are 0x52, 0x49, 0x46, 0x46 ('RIFF'), followed by 4 bytes for the RIFF chunk size. The next 7 bytes are 0x57, 0x45, 0x42, 0x50, 0x56, 0x50, 0x38 ('WEBPVP8'). File extension(s): webp Apple Uniform Type Identifier: org.webmproject.webp conforms to public.image Object Identifiers: N/A Person & email address to contact for further information: Name: James Zern Email: jzern@google.com Intended usage: COMMON Restrictions on usage: N/A Author: Name: James Zern Email: jzern@google.com Change controller: Name: James Zern Email: jzern@google.com Name: Pascal Massimino Email: pascal.massimino@gmail.com Zern, et al. Expires 15 June 2023 [Page 47] Internet-Draft WebP Image Format December 2022 Name: WebM Project Email: webmaster@webmproject.org Provisional registration? (standards tree only): N/A 7. References 7.1. Normative References [Exif] Camera & Imaging Products Association (CIPA), Japan Electronics and Information Technology Industries Association (JEITA), "Exchangeable image file format for digital still cameras: Exif Version 2.3", . [ICC] International Color Consortium, "ICC Specification", December 2010, . [ISO.9899.2018] International Organization for Standardization, "Information technology - Programming languages - C", ISO/ IEC 9899:2018, June 2018. [rec601] ITU, "BT.601: Studio encoding parameters of digital television for standard 4:3 and wide screen 16:9 aspect ratios", March 2011, . [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, DOI 10.17487/RFC1166, July 1990, . [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000, . Zern, et al. Expires 15 June 2023 [Page 48] Internet-Draft WebP Image Format December 2022 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [XMP] Adobe Inc., "XMP Specification", . 7.2. Informative References [crbug-security] "libwebp Security Issues", . [cve.mitre.org-libwebp] "libwebp CVE List", . [GIF-spec] "GIF89a Specification", . [Huffman] Huffman, D. A., "A Method for the Construction of Minimum Redundancy Codes", Proceedings of the Institute of Radio Engineers Number 9, pp. 1098-1101., September 1952. [JPEG-spec] "JPEG Standard (JPEG ISO/IEC 10918-1 ITU-T Recommendation T.81)", . Zern, et al. Expires 15 June 2023 [Page 49] Internet-Draft WebP Image Format December 2022 [LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for Sequential Data Compression", IEEE Transactions on Information Theory Vol. 23, No. 3, pp. 337-343., May 1977. [MWG] Metadata Working Group, "Guidelines For Handling Image Metadata", November 2010, . [RFC2083] Boutell, T., "PNG (Portable Network Graphics) Specification Version 1.0", RFC 2083, DOI 10.17487/RFC2083, March 1997, . [RIFF-spec] "RIFF (Resource Interchange File Format)", . [webp-lossless-src] Alakuijala, J., "WebP Lossless Bitstream Specification", November 2022, . [webp-lossless-study] Alakuijala, J. and V. Rabaud, "Lossless and Transparency Encoding in WebP", August 2017, . [webp-riff-src] Google LLC, "WebP RIFF Container", November 2022, . Authors' Addresses James Zern Google LLC 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America Phone: +1 650 253-0000 Email: jzern@google.com Zern, et al. Expires 15 June 2023 [Page 50] Internet-Draft WebP Image Format December 2022 Pascal Massimino Google LLC Email: pascal.massimino@gmail.com Jyrki Alakuijala Google LLC Email: jyrki.alakuijala@gmail.com Zern, et al. Expires 15 June 2023 [Page 51] ./rfc-index.txt0000644000764400076440000712415414363164772013316 0ustar iustiniustin ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RFC INDEX ------------- (CREATED ON: 01/22/2023.) This file contains citations for all RFCs in numeric order. RFC citations appear in this format: #### Title of RFC. Author 1, Author 2, Author 3. Issue date. (Format: ASCII) (Obsoletes xxx) (Obsoleted by xxx) (Updates xxx) (Updated by xxx) (Also FYI ####) (Status: ssssss) (DOI: ddd) or #### Not Issued. For example: 1129 Internet Time Synchronization: The Network Time Protocol. D.L. Mills. October 1989. (Format: TXT, PS, PDF, HTML) (Also RFC1119) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1129) Key to citations: #### is the RFC number. Following the RFC number are the title, the author(s), and the publication date of the RFC. Each of these is terminated by a period. Following the number are the title (terminated with a period), the author, or list of authors (terminated with a period), and the date (terminated with a period). The format follows in parentheses. One or more of the following formats are listed: text (TXT), PostScript (PS), Portable Document Format (PDF), HTML, XML. Obsoletes xxxx refers to other RFCs that this one replaces; Obsoleted by xxxx refers to RFCs that have replaced this one. Updates xxxx refers to other RFCs that this one merely updates (but does not replace); Updated by xxxx refers to RFCs that have updated (but not replaced) this one. Generally, only immediately succeeding and/or preceding RFCs are indicated, not the entire history of each related earlier or later RFC in a related series. The (Also FYI ##) or (Also STD ##) or (Also BCP ##) phrase gives the equivalent FYI, STD, or BCP number if the RFC is also in those document sub-series. The Status field gives the document's current status (see RFC 2026). The (DOI ddd) field gives the Digital Object Identifier. RFCs may be obtained in a number of ways, using HTTP, FTP, or email. See the RFC Editor Web page http://www.rfc-editor.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RFC INDEX --------- 0001 Host Software. S. Crocker. April 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0001) 0002 Host software. B. Duvall. April 1969. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0002) 0003 Documentation conventions. S.D. Crocker. April 1969. (Format: TXT, HTML) (Obsoleted by RFC0010) (Status: UNKNOWN) (DOI: 10.17487/RFC0003) 0004 Network timetable. E.B. Shapiro. March 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0004) 0005 Decode Encode Language (DEL). J. Rulifson. June 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0005) 0006 Conversation with Bob Kahn. S.D. Crocker. April 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0006) 0007 Host-IMP interface. G. Deloche. May 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0007) 0008 ARPA Network Functional Specifications. G. Deloche. May 1969. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0008) 0009 Host Software. G. Deloche. May 1969. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0009) 0010 Documentation conventions. S.D. Crocker. July 1969. (Format: TXT, HTML) (Obsoletes RFC0003) (Obsoleted by RFC0016) (Updated by RFC0024, RFC0027, RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0010) 0011 Implementation of the Host - Host Software Procedures in GORDO. G. Deloche. August 1969. (Format: TXT, PDF, HTML) (Obsoleted by RFC0033) (Status: UNKNOWN) (DOI: 10.17487/RFC0011) 0012 IMP-Host interface flow diagrams. M. Wingfield. August 1969. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0012) 0013 Zero Text Length EOF Message. V. Cerf. August 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0013) 0014 Not Issued. 0015 Network subsystem for time sharing hosts. C.S. Carr. September 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0015) 0016 M.I.T. S. Crocker. August 1969. (Format: TXT, HTML) (Obsoletes RFC0010) (Obsoleted by RFC0024) (Updated by RFC0024, RFC0027, RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0016) 0017 Some questions re: Host-IMP Protocol. J.E. Kreznar. August 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0017) 0018 IMP-IMP and HOST-HOST Control Links. V. Cerf. September 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0018) 0019 Two protocol suggestions to reduce congestion at swap bound nodes. J.E. Kreznar. October 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0019) 0020 ASCII format for network interchange. V.G. Cerf. October 1969. (Format: TXT, PDF, HTML) (Also STD0080) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0020) 0021 Network meeting. V.G. Cerf. October 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0021) 0022 Host-host control message formats. V.G. Cerf. October 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0022) 0023 Transmission of Multiple Control Messages. G. Gregg. October 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0023) 0024 Documentation Conventions. S.D. Crocker. November 1969. (Format: TXT, HTML) (Obsoletes RFC0016) (Updates RFC0010, RFC0016) (Updated by RFC0027, RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0024) 0025 No High Link Numbers. S.D. Crocker. October 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0025) 0026 Not Issued. 0027 Documentation Conventions. S.D. Crocker. December 1969. (Format: TXT, HTML) (Updates RFC0010, RFC0016, RFC0024) (Updated by RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0027) 0028 Time Standards. W.K. English. January 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0028) 0029 Response to RFC 28. R.E. Kahn. January 1970. (Format: TXT, HTML) (Also RFC0028) (Status: UNKNOWN) (DOI: 10.17487/RFC0029) 0030 Documentation Conventions. S.D. Crocker. February 1970. (Format: TXT, HTML) (Updates RFC0010, RFC0016, RFC0024, RFC0027) (Status: UNKNOWN) (DOI: 10.17487/RFC0030) 0031 Binary Message Forms in Computer. D. Bobrow, W.R. Sutherland. February 1968. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0031) 0032 Some Thoughts on SRI's Proposed Real Time Clock. J. Cole. February 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0032) 0033 New Host-Host Protocol. S.D. Crocker. February 1970. (Format: TXT, HTML) (Obsoletes RFC0011) (Updated by RFC0036, RFC0047) (Status: UNKNOWN) (DOI: 10.17487/RFC0033) 0034 Some Brief Preliminary Notes on the Augmentation Research Center Clock. W.K. English. February 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0034) 0035 Network Meeting. S.D. Crocker. March 1970. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0035) 0036 Protocol Notes. S.D. Crocker. March 1970. (Format: TXT, HTML) (Updates RFC0033) (Updated by RFC0039, RFC0044) (Status: UNKNOWN) (DOI: 10.17487/RFC0036) 0037 Network Meeting Epilogue, etc. S.D. Crocker. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0037) 0038 Comments on Network Protocol from NWG/RFC #36. S.M. Wolfe. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0038) 0039 Comments on Protocol Re: NWG/RFC #36. E. Harslem, J.F. Heafner. March 1970. (Format: TXT, HTML) (Updates RFC0036) (Status: UNKNOWN) (DOI: 10.17487/RFC0039) 0040 More Comments on the Forthcoming Protocol. E. Harslem, J.F. Heafner. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0040) 0041 IMP-IMP Teletype Communication. J.T. Melvin. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0041) 0042 Message Data Types. E. Ancona. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0042) 0043 Proposed Meeting. A.G. Nemeth. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0043) 0044 Comments on NWG/RFC 33 and 36. A. Shoshani, R. Long, A. Landsberg. April 1970. (Format: TXT, HTML) (Updates RFC0036) (Status: UNKNOWN) (DOI: 10.17487/RFC0044) 0045 New Protocol is Coming. J. Postel, S.D. Crocker. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0045) 0046 ARPA Network protocol notes. E. Meyer. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0046) 0047 BBN's Comments on NWG/RFC #33. J. Postel, S. Crocker. April 1970. (Format: TXT, HTML) (Updates RFC0033) (Status: UNKNOWN) (DOI: 10.17487/RFC0047) 0048 Possible protocol plateau. J. Postel, S.D. Crocker. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0048) 0049 Conversations with S. Crocker (UCLA). E. Meyer. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0049) 0050 Comments on the Meyer Proposal. E. Harslen, J. Heafner. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0050) 0051 Proposal for a Network Interchange Language. M. Elie. May 1970. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0051) 0052 Updated distribution list. J. Postel, S.D. Crocker. July 1970. (Format: TXT, HTML) (Updated by RFC0069) (Status: UNKNOWN) (DOI: 10.17487/RFC0052) 0053 Official protocol mechanism. S.D. Crocker. June 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0053) 0054 Official Protocol Proffering. S.D. Crocker, J. Postel, J. Newkirk, M. Kraley. June 1970. (Format: TXT, HTML) (Updated by RFC0057) (Status: UNKNOWN) (DOI: 10.17487/RFC0054) 0055 Prototypical implementation of the NCP. J. Newkirk, M. Kraley, J. Postel, S.D. Crocker. June 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0055) 0056 Third Level Protocol: Logger Protocol. E. Belove, D. Black, R. Flegal, L.G. Farquar. June 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0056) 0057 Thoughts and Reflections on NWG/RFC 54. M. Kraley, J. Newkirk. June 1970. (Format: TXT, HTML) (Updates RFC0054) (Status: UNKNOWN) (DOI: 10.17487/RFC0057) 0058 Logical Message Synchronization. T.P. Skinner. June 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0058) 0059 Flow Control - Fixed Versus Demand Allocation. E. Meyer. June 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0059) 0060 A Simplified NCP Protocol. R. Kalin. July 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0060) 0061 Note on Interprocess Communication in a Resource Sharing Computer Network. D.C. Walden. July 1970. (Format: TXT, HTML) (Obsoleted by RFC0062) (Status: UNKNOWN) (DOI: 10.17487/RFC0061) 0062 Systems for Interprocess Communication in a Resource Sharing Computer Network. D.C. Walden. August 1970. (Format: TXT, HTML) (Obsoletes RFC0061) (Status: UNKNOWN) (DOI: 10.17487/RFC0062) 0063 Belated Network Meeting Report. V.G. Cerf. July 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0063) 0064 Getting rid of marking. M. Elie. July 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0064) 0065 Comments on Host/Host Protocol document #1. D.C. Walden. August 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0065) 0066 NIC - third level ideas and other noise. S.D. Crocker. August 1970. (Format: TXT, HTML) (Obsoleted by RFC0123) (Updated by RFC0080, RFC0093) (Status: UNKNOWN) (DOI: 10.17487/RFC0066) 0067 Proposed Change to Host/IMP Spec to Eliminate Marking. W.R. Crowther. January 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0067) 0068 Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM. M. Elie. August 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0068) 0069 Distribution List Change for MIT. A.K. Bhushan. September 1970. (Format: TXT, HTML) (Updates RFC0052) (Status: UNKNOWN) (DOI: 10.17487/RFC0069) 0070 Note on Padding. S.D. Crocker. October 1970. (Format: TXT, HTML) (Updated by RFC0228) (Status: UNKNOWN) (DOI: 10.17487/RFC0070) 0071 Reallocation in Case of Input Error. T. Schipper. September 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0071) 0072 Proposed Moratorium on Changes to Network Protocol. R.D. Bressler. September 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0072) 0073 Response to NWG/RFC 67. S.D. Crocker. September 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0073) 0074 Specifications for Network Use of the UCSB On-Line System. J.E. White. October 1970. (Format: TXT, PDF, HTML) (Updated by RFC0217, RFC0225) (Status: UNKNOWN) (DOI: 10.17487/RFC0074) 0075 Network Meeting. S.D. Crocker. October 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0075) 0076 Connection by name: User oriented protocol. J. Bouknight, J. Madden, G.R. Grossman. October 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0076) 0077 Network meeting report. J. Postel. November 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0077) 0078 NCP Status Report: UCSB/Rand. E. Harslem, J.F. Heafner, J.E. White. October 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0078) 0079 Logger Protocol error. E. Meyer. November 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0079) 0080 Protocols and Data Formats. E. Harslem, J.F. Heafner. December 1970. (Format: TXT, HTML) (Obsoleted by RFC0123) (Updates RFC0066) (Updated by RFC0093) (Status: UNKNOWN) (DOI: 10.17487/RFC0080) 0081 Request for Reference Information. J. Bouknight. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0081) 0082 Network Meeting Notes. E. Meyer. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0082) 0083 Language-machine for data reconfiguration. R.H. Anderson, E. Harslem, J.F. Heafner. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0083) 0084 List of NWG/RFC's 1-80. J.B. North. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0084) 0085 Network Working Group meeting. S.D. Crocker. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0085) 0086 Proposal for a Network Standard Format for a Data Stream to Control Graphics Display. S.D. Crocker. January 1971. (Format: TXT, HTML) (Updated by RFC0125) (Status: UNKNOWN) (DOI: 10.17487/RFC0086) 0087 Topic for Discussion at the Next Network Working Group Meeting. A. Vezza. January 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0087) 0088 NETRJS: A third level protocol for Remote Job Entry. R.T. Braden, S.M. Wolfe. January 1971. (Format: TXT, HTML) (Obsoleted by RFC0189) (Status: UNKNOWN) (DOI: 10.17487/RFC0088) 0089 Some historic moments in networking. R.M. Metcalfe. January 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0089) 0090 CCN as a Network Service Center. R.T. Braden. January 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0090) 0091 Proposed User-User Protocol. G.H. Mealy. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0091) 0092 Not Issued. 0093 Initial Connection Protocol. A.M. McKenzie. January 1971. (Format: TXT, HTML) (Updates RFC0066, RFC0080) (Status: UNKNOWN) (DOI: 10.17487/RFC0093) 0094 Some thoughts on Network Graphics. E. Harslem, J.F. Heafner. February 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0094) 0095 Distribution of NWG/RFC's through the NIC. S. Crocker. February 1971. (Format: TXT, HTML) (Obsoleted by RFC0155) (Status: UNKNOWN) (DOI: 10.17487/RFC0095) 0096 An Interactive Network Experiment to Study Modes of Access the Network Information Center. R.W. Watson. February 1971. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0096) 0097 First Cut at a Proposed Telnet Protocol. J.T. Melvin, R.W. Watson. February 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0097) 0098 Logger Protocol Proposal. E. Meyer, T. Skinner. February 1971. (Format: TXT, HTML) (Updated by RFC0123) (Status: UNKNOWN) (DOI: 10.17487/RFC0098) 0099 Network Meeting. P.M. Karp. February 1971. (Format: TXT, HTML) (Updated by RFC0116) (Status: UNKNOWN) (DOI: 10.17487/RFC0099) 0100 Categorization and guide to NWG/RFCs. P.M. Karp. February 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0100) 0101 Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971. R.W. Watson. February 1971. (Format: TXT, HTML) (Updated by RFC0108, RFC0123) (Status: UNKNOWN) (DOI: 10.17487/RFC0101) 0102 Output of the Host-Host Protocol glitch cleaning committee. S.D. Crocker. February 1971. (Format: TXT, HTML) (Updated by RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0102) 0103 Implementation of Interrupt Keys. R.B. Kalin. February 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0103) 0104 Link 191. J.B. Postel, S.D. Crocker. February 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0104) 0105 Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB. J.E. White. March 1971. (Format: TXT, HTML) (Updated by RFC0217) (Status: UNKNOWN) (DOI: 10.17487/RFC0105) 0106 User/Server Site Protocol Network Host Questionnaire. T.C. O'Sullivan. March 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0106) 0107 Output of the Host-Host Protocol Glitch Cleaning Committee. R.D. Bressler, S.D. Crocker, W.R. Crowther, G.R. Grossman, R.S. Tomlinson, J.E. White. March 1971. (Format: TXT, HTML) (Updates RFC0102) (Updated by RFC0111, RFC0124, RFC0132, RFC0154, RFC0179) (Status: UNKNOWN) (DOI: 10.17487/RFC0107) 0108 Attendance list at the Urbana NWG meeting, February 17-19, 1971. R.W. Watson. March 1971. (Format: TXT, HTML) (Updates RFC0101) (Status: UNKNOWN) (DOI: 10.17487/RFC0108) 0109 Level III Server Protocol for the Lincoln Laboratory 360/67 Host. J. Winett. March 1971. (Format: TXT, PDF, HTML) (Also RFC0393) (Status: UNKNOWN) (DOI: 10.17487/RFC0109) 0110 Conventions for Using an IBM 2741 Terminal as a User Console for Access to Network Server Hosts. J. Winett. March 1971. (Format: TXT, PDF, HTML) (Updated by RFC0135) (Status: UNKNOWN) (DOI: 10.17487/RFC0110) 0111 Pressure from the Chairman. S.D. Crocker. March 1971. (Format: TXT, HTML) (Updates RFC0107) (Updated by RFC0130) (Status: UNKNOWN) (DOI: 10.17487/RFC0111) 0112 User/Server Site Protocol: Network Host Questionnaire. T.C. O'Sullivan. April 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0112) 0113 Network activity report: UCSB Rand. E. Harslem, J.F. Heafner, J.E. White. April 1971. (Format: TXT, HTML) (Updated by RFC0227) (Status: UNKNOWN) (DOI: 10.17487/RFC0113) 0114 File Transfer Protocol. A.K. Bhushan. April 1971. (Format: TXT, HTML) (Updated by RFC0133, RFC0141, RFC0171, RFC0172) (Status: UNKNOWN) (DOI: 10.17487/RFC0114) 0115 Some Network Information Center policies on handling documents. R.W. Watson, J.B. North. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0115) 0116 Structure of the May NWG Meeting. S.D. Crocker. April 1971. (Format: TXT, HTML) (Updates RFC0099) (Updated by RFC0131, RFC0156) (Status: UNKNOWN) (DOI: 10.17487/RFC0116) 0117 Some comments on the official protocol. J. Wong. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0117) 0118 Recommendations for facility documentation. R.W. Watson. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0118) 0119 Network Fortran Subprograms. M. Krilanovich. April 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0119) 0120 Network PL1 subprograms. M. Krilanovich. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0120) 0121 Network on-line operators. M. Krilanovich. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0121) 0122 Network specifications for UCSB's Simple-Minded File System. J.E. White. April 1971. (Format: TXT, HTML) (Updated by RFC0217, RFC0269, RFC0399, RFC0431) (Status: UNKNOWN) (DOI: 10.17487/RFC0122) 0123 Proffered Official ICP. S.D. Crocker. April 1971. (Format: TXT, HTML) (Obsoletes RFC0066, RFC0080) (Obsoleted by RFC0165) (Updates RFC0098, RFC0101) (Updated by RFC0127, RFC0143, RFC0148) (Status: UNKNOWN) (DOI: 10.17487/RFC0123) 0124 Typographical error in RFC 107. J.T. Melvin. April 1971. (Format: TXT, HTML) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0124) 0125 Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream. J. McConnell. April 1971. (Format: TXT, HTML) (Updates RFC0086) (Updated by RFC0177) (Status: UNKNOWN) (DOI: 10.17487/RFC0125) 0126 Graphics Facilities at Ames Research Center. J. McConnell. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0126) 0127 Comments on RFC 123. J. Postel. April 1971. (Format: TXT, HTML) (Obsoleted by RFC0145) (Updates RFC0123) (Updated by RFC0151) (Status: UNKNOWN) (DOI: 10.17487/RFC0127) 0128 Bytes. J. Postel. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0128) 0129 Request for comments on socket name structure. E. Harslem, J. Heafner, E. Meyer. April 1971. (Format: TXT, HTML) (Updated by RFC0147) (Status: UNKNOWN) (DOI: 10.17487/RFC0129) 0130 Response to RFC 111: Pressure from the chairman. J.F. Heafner. April 1971. (Format: TXT, HTML) (Updates RFC0111) (Status: UNKNOWN) (DOI: 10.17487/RFC0130) 0131 Response to RFC 116: May NWG meeting. E. Harslem, J.F. Heafner. April 1971. (Format: TXT, HTML) (Updates RFC0116) (Status: UNKNOWN) (DOI: 10.17487/RFC0131) 0132 Typographical Error in RFC 107. J.E. White. April 1971. (Format: TXT, HTML) (Obsoleted by RFC0154) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0132) 0133 File Transfer and Error Recovery. R.L. Sunberg. April 1971. (Format: TXT, HTML) (Updates RFC0114) (Status: UNKNOWN) (DOI: 10.17487/RFC0133) 0134 Network Graphics meeting. A. Vezza. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0134) 0135 Response to NWG/RFC 110. W. Hathaway. April 1971. (Format: TXT, HTML) (Updates RFC0110) (Status: UNKNOWN) (DOI: 10.17487/RFC0135) 0136 Host accounting and administrative procedures. R.E. Kahn. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0136) 0137 Telnet Protocol - a proposed document. T.C. O'Sullivan. April 1971. (Format: TXT, HTML) (Updated by RFC0139) (Status: UNKNOWN) (DOI: 10.17487/RFC0137) 0138 Status report on proposed Data Reconfiguration Service. R.H. Anderson, V.G. Cerf, E. Harslem, J.F. Heafner, J. Madden, R.M. Metcalfe, A. Shoshani, J.E. White, D.C.M. Wood. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0138) 0139 Discussion of Telnet Protocol. T.C. O'Sullivan. May 1971. (Format: TXT, HTML) (Updates RFC0137) (Updated by RFC0158) (Also RFC0393) (Status: UNKNOWN) (DOI: 10.17487/RFC0139) 0140 Agenda for the May NWG meeting. S.D. Crocker. May 1971. (Format: TXT, HTML) (Updated by RFC0149) (Status: UNKNOWN) (DOI: 10.17487/RFC0140) 0141 Comments on RFC 114: A File Transfer Protocol. E. Harslem, J.F. Heafner. April 1971. (Format: TXT, HTML) (Updates RFC0114) (Status: UNKNOWN) (DOI: 10.17487/RFC0141) 0142 Time-Out Mechanism in the Host-Host Protocol. C. Kline, J. Wong. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0142) 0143 Regarding proffered official ICP. W. Naylor, J. Wong, C. Kline, J. Postel. May 1971. (Format: TXT, HTML) (Obsoleted by RFC0165) (Updates RFC0123, RFC0145) (Status: UNKNOWN) (DOI: 10.17487/RFC0143) 0144 Data sharing on computer networks. A. Shoshani. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0144) 0145 Initial Connection Protocol Control Commands. J. Postel. May 1971. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC0127) (Obsoleted by RFC0165) (Updated by RFC0143) (Status: UNKNOWN) (DOI: 10.17487/RFC0145) 0146 Views on issues relevant to data sharing on computer networks. P.M. Karp, D.B. McKay, D.C.M. Wood. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0146) 0147 Definition of a socket. J.M. Winett. May 1971. (Format: TXT, HTML) (Updates RFC0129) (Status: UNKNOWN) (DOI: 10.17487/RFC0147) 0148 Comments on RFC 123. A.K. Bhushan. May 1971. (Format: TXT, HTML) (Updates RFC0123) (Status: UNKNOWN) (DOI: 10.17487/RFC0148) 0149 Best Laid Plans. S.D. Crocker. May 1971. (Format: TXT, HTML) (Updates RFC0140) (Status: UNKNOWN) (DOI: 10.17487/RFC0149) 0150 Use of IPC Facilities: A Working Paper. R.B. Kalin. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0150) 0151 Comments on a proffered official ICP: RFCs 123, 127. A. Shoshani. May 1971. (Format: TXT, HTML) (Updates RFC0127) (Status: UNKNOWN) (DOI: 10.17487/RFC0151) 0152 SRI Artificial Intelligence status report. M. Wilber. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0152) 0153 SRI ARC-NIC status. J.T. Melvin, R.W. Watson. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0153) 0154 Exposition Style. S.D. Crocker. May 1971. (Format: TXT, HTML) (Obsoletes RFC0132) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0154) 0155 ARPA Network mailing lists. J.B. North. May 1971. (Format: TXT, HTML) (Obsoletes RFC0095) (Obsoleted by RFC0168) (Status: UNKNOWN) (DOI: 10.17487/RFC0155) 0156 Status of the Illinois site: Response to RFC 116. J. Bouknight. April 1971. (Format: TXT, HTML) (Updates RFC0116) (Status: UNKNOWN) (DOI: 10.17487/RFC0156) 0157 Invitation to the Second Symposium on Problems in the Optimization of Data Communications Systems. V.G. Cerf. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0157) 0158 Telnet Protocol: A Proposed Document. T.C. O'Sullivan. May 1971. (Format: TXT, PDF, HTML) (Obsoleted by RFC0495) (Updates RFC0139) (Updated by RFC0318) (Also RFC0393) (Status: UNKNOWN) (DOI: 10.17487/RFC0158) 0159 Not Issued. 0160 RFC brief list. Network Information Center. Stanford Research Institute. May 1971. (Format: TXT, HTML) (Obsoleted by RFC0200, RFC0999) (Updates NIC6716) (Status: UNKNOWN) (DOI: 10.17487/RFC0160) 0161 Solution to the race condition in the ICP. A. Shoshani. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0161) 0162 NETBUGGER3. M. Kampe. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0162) 0163 Data transfer protocols. V.G. Cerf. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0163) 0164 Minutes of Network Working Group meeting, 5/16 through 5/19/71. J.F. Heafner. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0164) 0165 Proffered Official Initial Connection Protocol. J. Postel. May 1971. (Format: TXT, PDF, HTML) (Obsoletes RFC0145, RFC0143, RFC0123) (Updated by NIC7101) (Status: UNKNOWN) (DOI: 10.17487/RFC0165) 0166 Data Reconfiguration Service: An implementation specification. R.H. Anderson, V.G. Cerf, E. Harslem, J.F. Heafner, J. Madden, R.M. Metcalfe, A. Shoshani, J.E. White, D.C.M. Wood. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0166) 0167 Socket conventions reconsidered. A.K. Bhushan, R.M. Metcalfe, J.M. Winett. May 1971. (Format: TXT, HTML) (Also RFC0129, RFC0147) (Status: UNKNOWN) (DOI: 10.17487/RFC0167) 0168 ARPA Network mailing lists. J.B. North. May 1971. (Format: TXT, HTML) (Obsoletes RFC0155) (Obsoleted by RFC0211) (Status: UNKNOWN) (DOI: 10.17487/RFC0168) 0169 COMPUTER NETWORKS. S.D. Crocker. May 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0169) 0170 RFC List by Number. Network Information Center. Stanford Research Institute. June 1971. (Format: TXT, HTML) (Obsoleted by RFC0200) (Status: UNKNOWN) (DOI: 10.17487/RFC0170) 0171 The Data Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, J. Melvin, B. Sundberg, D. Watson, J. White. June 1971. (Format: TXT, HTML) (Obsoleted by RFC0264) (Updates RFC0114) (Updated by RFC0238) (Status: UNKNOWN) (DOI: 10.17487/RFC0171) 0172 The File Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White. June 1971. (Format: TXT, HTML) (Obsoleted by RFC0265) (Updates RFC0114) (Updated by RFC0238) (Status: UNKNOWN) (DOI: 10.17487/RFC0172) 0173 Network Data Management Committee Meeting Announcement. P.M. Karp, D.B. McKay. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0173) 0174 UCLA - Computer Science Graphics Overview. J. Postel, V.G. Cerf. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0174) 0175 Comments on "Socket Conventions Reconsidered". E. Harslem, J.F. Heafner. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0175) 0176 Comments on "Byte size for connections". A.K. Bhushan, R. Kanodia, R.M. Metcalfe, J. Postel. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0176) 0177 Device independent graphical display description. J. McConnell. June 1971. (Format: TXT, HTML) (Updates RFC0125) (Updated by RFC0181) (Status: UNKNOWN) (DOI: 10.17487/RFC0177) 0178 Network graphic attention handling. I.W. Cotton. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0178) 0179 Link Number Assignments. A.M. McKenzie. June 1971. (Format: TXT, HTML) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0179) 0180 File system questionnaire. A.M. McKenzie. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0180) 0181 Modifications to RFC 177. J. McConnell. July 1971. (Format: TXT, HTML) (Updates RFC0177) (Status: UNKNOWN) (DOI: 10.17487/RFC0181) 0182 Compilation of list of relevant site reports. J.B. North. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0182) 0183 EBCDIC Codes and Their Mapping to ASCII. J.M. Winett. July 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0183) 0184 Proposed graphic display modes. K.C. Kelley. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0184) 0185 NIC distribution of manuals and handbooks. J.B. North. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0185) 0186 Network graphics loader. J.C. Michener. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0186) 0187 Network/440 Protocol Concept. D.B. McKay, D.P. Karp. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0187) 0188 Data management meeting announcement. P.M. Karp, D.B. McKay. January 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0188) 0189 Interim NETRJS specifications. R.T. Braden. July 1971. (Format: TXT, HTML) (Obsoletes RFC0088) (Obsoleted by RFC0599) (Updated by RFC0283) (Status: UNKNOWN) (DOI: 10.17487/RFC0189) 0190 DEC PDP-10-IMLAC communications system. L.P. Deutsch. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0190) 0191 Graphics implementation and conceptualization at Augmentation Research Center. C.H. Irby. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0191) 0192 Some factors which a Network Graphics Protocol must consider. R.W. Watson. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0192) 0193 NETWORK CHECKOUT. E. Harslem, J.F. Heafner. July 1971. (Format: TXT, HTML) (Obsoleted by RFC0198) (Updated by RFC0198) (Status: UNKNOWN) (DOI: 10.17487/RFC0193) 0194 The Data Reconfiguration Service -- Compiler/Interpreter Implementation Notes. V. Cerf, E. Harslem, J. Heafner, B. Metcalfe, J. White. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0194) 0195 Data computers-data descriptions and access language. G.H. Mealy. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0195) 0196 Mail Box Protocol. R.W. Watson. July 1971. (Format: TXT, HTML) (Obsoleted by RFC0221) (Status: UNKNOWN) (DOI: 10.17487/RFC0196) 0197 Initial Connection Protocol - Reviewed. A. Shoshani, E. Harslem. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0197) 0198 Site Certification - Lincoln Labs 360/67. J.F. Heafner. July 1971. (Format: TXT, HTML) (Obsoletes RFC0193) (Obsoleted by RFC0214) (Updates RFC0193) (Status: UNKNOWN) (DOI: 10.17487/RFC0198) 0199 Suggestions for a Network Data-Tablet Graphics Protocol. T. Williams. July 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0199) 0200 RFC list by number. J.B. North. August 1971. (Format: TXT, HTML) (Obsoletes RFC0170, RFC0160) (Obsoleted by NIC7724) (Status: UNKNOWN) (DOI: 10.17487/RFC0200) 0201 Not Issued. 0202 Possible Deadlock in ICP. S.M. Wolfe, J. Postel. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0202) 0203 Achieving reliable communication. R.B. Kalin. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0203) 0204 Sockets in use. J. Postel. August 1971. (Format: TXT, HTML) (Updated by RFC0234) (Status: UNKNOWN) (DOI: 10.17487/RFC0204) 0205 NETCRT - a character display protocol. R.T. Braden. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0205) 0206 A User TELNET Description of an Initial Implementation. J. White. August 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0206) 0207 September Network Working Group meeting. A. Vezza. August 1971. (Format: TXT, HTML) (Obsoleted by RFC0212) (Status: UNKNOWN) (DOI: 10.17487/RFC0207) 0208 Address tables. A.M. McKenzie. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0208) 0209 Host/IMP interface documentation. B. Cosell. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0209) 0210 Improvement of Flow Control. W. Conrad. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0210) 0211 ARPA Network Mailing Lists. J.B. North. August 1971. (Format: TXT, PDF, HTML) (Obsoletes RFC0168) (Obsoleted by RFC0300) (Status: UNKNOWN) (DOI: 10.17487/RFC0211) 0212 NWG meeting on network usage. Information Sciences Institute University of Southern California. August 1971. (Format: TXT, HTML) (Obsoletes RFC0207) (Updated by RFC0222) (Status: UNKNOWN) (DOI: 10.17487/RFC0212) 0213 IMP System change notification. B. Cosell. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0213) 0214 Network checkpoint. E. Harslem. August 1971. (Format: TXT, HTML) (Obsoletes RFC0198) (Status: UNKNOWN) (DOI: 10.17487/RFC0214) 0215 NCP, ICP, and Telnet: The Terminal IMP implementation. A.M. McKenzie. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0215) 0216 Telnet Access to UCSB's On-Line System. J.E. White. September 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0216) 0217 Specifications changes for OLS, RJE/RJOR, and SMFS. J.E. White. September 1971. (Format: TXT, HTML) (Updates RFC0074, RFC0105, RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0217) 0218 Changing the IMP status reporting facility. B. Cosell. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0218) 0219 User's View of the Datacomputer. R. Winter. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0219) 0220 Not Issued. 0221 Mail Box Protocol: Version 2. R.W. Watson. August 1971. (Format: TXT, HTML) (Obsoletes RFC0196) (Obsoleted by RFC0278) (Status: UNKNOWN) (DOI: 10.17487/RFC0221) 0222 Subject: System programmer's workshop. R.M. Metcalfe. September 1971. (Format: TXT, HTML) (Updates RFC0212) (Updated by RFC0234) (Status: UNKNOWN) (DOI: 10.17487/RFC0222) 0223 Network Information Center schedule for network users. J.T. Melvin, R.W. Watson. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0223) 0224 Comments on Mailbox Protocol. A.M. McKenzie. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0224) 0225 Rand/UCSB network graphics experiment. E. Harslem, R. Stoughton. September 1971. (Format: TXT, HTML) (Updates RFC0074) (Status: UNKNOWN) (DOI: 10.17487/RFC0225) 0226 Standardization of host mnemonics. P.M. Karp. September 1971. (Format: TXT, HTML) (Obsoleted by RFC0247) (Status: UNKNOWN) (DOI: 10.17487/RFC0226) 0227 Data transfer rates (Rand/UCLA). J.F. Heafner, E. Harslem. September 1971. (Format: TXT, HTML) (Updates RFC0113) (Status: UNKNOWN) (DOI: 10.17487/RFC0227) 0228 Clarification. D.C. Walden. September 1971. (Format: TXT, HTML) (Updates RFC0070) (Status: UNKNOWN) (DOI: 10.17487/RFC0228) 0229 Standard host names. J. Postel. September 1971. (Format: TXT, HTML) (Obsoleted by RFC0236) (Status: UNKNOWN) (DOI: 10.17487/RFC0229) 0230 Toward reliable operation of minicomputer-based terminals on a TIP. T. Pyke. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0230) 0231 Service center standards for remote usage: A user's view. J.F. Heafner, E. Harslem. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0231) 0232 Postponement of network graphics meeting. A. Vezza. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0232) 0233 Standardization of host call letters. A. Bhushan, R. Metcalfe. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0233) 0234 Network Working Group meeting schedule. A. Vezza. October 1971. (Format: TXT, HTML) (Updates RFC0222, RFC0204) (Status: UNKNOWN) (DOI: 10.17487/RFC0234) 0235 Site status. E. Westheimer. September 1971. (Format: TXT, HTML) (Obsoleted by RFC0240) (Status: UNKNOWN) (DOI: 10.17487/RFC0235) 0236 Standard host names. J. Postel. September 1971. (Format: TXT, HTML) (Obsoletes RFC0229) (Status: UNKNOWN) (DOI: 10.17487/RFC0236) 0237 NIC view of standard host names. R.W. Watson. October 1971. (Format: TXT, HTML) (Obsoleted by RFC0273) (Status: UNKNOWN) (DOI: 10.17487/RFC0237) 0238 Comments on DTP and FTP proposals. R.T. Braden. September 1971. (Format: TXT, HTML) (Updates RFC0171, RFC0172) (Status: UNKNOWN) (DOI: 10.17487/RFC0238) 0239 Host mnemonics proposed in RFC 226 (NIC 7625). R.T. Braden. September 1971. (Format: TXT, HTML) (Also RFC0226, RFC0229, RFC0236) (Status: UNKNOWN) (DOI: 10.17487/RFC0239) 0240 Site Status. A.M. McKenzie. September 1971. (Format: TXT, HTML) (Obsoletes RFC0235) (Obsoleted by RFC0252) (Status: UNKNOWN) (DOI: 10.17487/RFC0240) 0241 Connecting computers to MLC ports. A.M. McKenzie. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0241) 0242 Data Descriptive Language for Shared Data. L. Haibt, A.P. Mullery. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0242) 0243 Network and data sharing bibliography. A.P. Mullery. October 1971. (Format: TXT, HTML) (Obsoleted by RFC0290) (Status: UNKNOWN) (DOI: 10.17487/RFC0243) 0244 Not Issued. 0245 Reservations for Network Group meeting. C. Falls. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0245) 0246 Network Graphics meeting. A. Vezza. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0246) 0247 Proffered set of standard host names. P.M. Karp. October 1971. (Format: TXT, HTML) (Obsoletes RFC0226) (Status: UNKNOWN) (DOI: 10.17487/RFC0247) 0248 Not Issued. 0249 Coordination of equipment and supplies purchase. R.F. Borelli. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0249) 0250 Some thoughts on file transfer. H. Brodie. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0250) 0251 Weather data. D. Stern. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0251) 0252 Network host status. E. Westheimer. October 1971. (Format: TXT, HTML) (Obsoletes RFC0240) (Obsoleted by RFC0255) (Status: UNKNOWN) (DOI: 10.17487/RFC0252) 0253 Second Network Graphics meeting details. J.A. Moorer. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0253) 0254 Scenarios for using ARPANET computers. A. Bhushan. October 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0254) 0255 Status of network hosts. E. Westheimer. October 1971. (Format: TXT, HTML) (Obsoletes RFC0252) (Obsoleted by RFC0266) (Status: UNKNOWN) (DOI: 10.17487/RFC0255) 0256 IMPSYS change notification. B. Cosell. November 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0256) 0257 Not Issued. 0258 Not Issued. 0259 Not Issued. 0260 Not Issued. 0261 Not Issued. 0262 Not Issued. 0263 "Very Distant" Host interface. A.M. McKenzie. December 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0263) 0264 The Data Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, B. Sundberg, D. Watson, J. White. January 1972. (Format: TXT, HTML) (Obsoletes RFC0171) (Obsoleted by RFC0354) (Updated by RFC0310) (Also RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0264) 0265 The File Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White. November 1971. (Format: TXT, HTML) (Obsoletes RFC0172) (Obsoleted by RFC0354) (Updated by RFC0281, RFC0294, RFC0310) (Also RFC0264) (Status: UNKNOWN) (DOI: 10.17487/RFC0265) 0266 Network host status. E. Westheimer. November 1971. (Format: TXT, HTML) (Obsoletes RFC0255) (Obsoleted by RFC0267) (Status: UNKNOWN) (DOI: 10.17487/RFC0266) 0267 Network Host Status. E. Westheimer. November 1971. (Format: TXT, HTML) (Obsoletes RFC0266) (Obsoleted by RFC0287) (Status: UNKNOWN) (DOI: 10.17487/RFC0267) 0268 Graphics facilities information. J. Postel. November 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0268) 0269 Some Experience with File Transfer. H. Brodie. December 1971. (Format: TXT, HTML) (Updates RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0269) 0270 Correction to BBN Report No. 1822 (NIC NO 7958). A.M. McKenzie. January 1972. (Format: TXT, PDF, HTML) (Updates NIC7959) (Status: UNKNOWN) (DOI: 10.17487/RFC0270) 0271 IMP System change notifications. B. Cosell. January 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0271) 0272 Not Issued. 0273 More on standard host names. R.W. Watson. October 1971. (Format: TXT, HTML) (Obsoletes RFC0237) (Status: UNKNOWN) (DOI: 10.17487/RFC0273) 0274 Establishing a local guide for network usage. E. Forman. November 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0274) 0275 Not Issued. 0276 NIC course. R.W. Watson. November 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0276) 0277 Not Issued. 0278 Revision of the Mail Box Protocol. A.K. Bhushan, R.T. Braden, E. Harslem, J.F. Heafner, A.M. McKenzie, J.T. Melvin, R.L. Sundberg, R.W. Watson, J.E. White. November 1971. (Format: TXT, HTML) (Obsoletes RFC0221) (Status: UNKNOWN) (DOI: 10.17487/RFC0278) 0279 Not Issued. 0280 A Draft of Host Names. R.W. Watson. November 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0280) 0281 Suggested addition to File Transfer Protocol. A.M. McKenzie. December 1971. (Format: TXT, HTML) (Updates RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0281) 0282 Graphics meeting report. M.A. Padlipsky. December 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0282) 0283 NETRJT: Remote Job Service Protocol for TIPS. R.T. Braden. December 1971. (Format: TXT, HTML) (Updates RFC0189) (Status: UNKNOWN) (DOI: 10.17487/RFC0283) 0284 Not Issued. 0285 Network graphics. D. Huff. December 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0285) 0286 Network Library Information System. E. Forman. December 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0286) 0287 Status of Network Hosts. E. Westheimer. December 1971. (Format: TXT, HTML) (Obsoletes RFC0267) (Obsoleted by RFC0288) (Status: UNKNOWN) (DOI: 10.17487/RFC0287) 0288 Network host status. E. Westheimer. January 1972. (Format: TXT, HTML) (Obsoletes RFC0287) (Obsoleted by RFC0293) (Updated by RFC0293) (Status: UNKNOWN) (DOI: 10.17487/RFC0288) 0289 What we hope is an official list of host names. R.W. Watson. December 1971. (Format: TXT, HTML) (Obsoleted by RFC0384) (Status: UNKNOWN) (DOI: 10.17487/RFC0289) 0290 Computer networks and data sharing: A bibliography. A.P. Mullery. January 1972. (Format: TXT, HTML) (Obsoletes RFC0243) (Status: UNKNOWN) (DOI: 10.17487/RFC0290) 0291 Data Management Meeting Announcement. D.B. McKay. January 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0291) 0292 Graphics Protocol: Level 0 only. J.C. Michener, I.W. Cotton, K.C. Kelley, D.E. Liddle, E. Meyer. January 1972. (Format: TXT, HTML) (Obsoleted by RFC0493) (Status: UNKNOWN) (DOI: 10.17487/RFC0292) 0293 Network Host Status. E. Westheimer. January 1972. (Format: TXT, HTML) (Obsoletes RFC0288) (Obsoleted by RFC0298) (Updates RFC0288) (Status: UNKNOWN) (DOI: 10.17487/RFC0293) 0294 The Use of "Set Data Type" Transaction in File Transfer Protocol. A.K. Bhushan. January 1972. (Format: TXT, HTML) (Updates RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0294) 0295 Report of the Protocol Workshop, 12 October 1971. J. Postel. January 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0295) 0296 DS-1 Display System. D.E. Liddle. January 1972. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0296) 0297 TIP Message Buffers. D.C. Walden. January 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0297) 0298 Network host status. E. Westheimer. February 1972. (Format: TXT, HTML) (Obsoletes RFC0293) (Obsoleted by RFC0306) (Status: UNKNOWN) (DOI: 10.17487/RFC0298) 0299 Information Management System. D. Hopkin. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0299) 0300 ARPA Network mailing lists. J.B. North. January 1972. (Format: TXT, HTML) (Obsoletes RFC0211) (Obsoleted by RFC0303) (Status: UNKNOWN) (DOI: 10.17487/RFC0300) 0301 BBN IMP (#5) and NCC Schedule March 4, 1971. R. Alter. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0301) 0302 Exercising The ARPANET. R.F. Bryan. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0302) 0303 ARPA Network mailing lists. Network Information Center. Stanford Research Institute. March 1972. (Format: TXT, HTML) (Obsoletes RFC0300) (Obsoleted by RFC0329) (Status: UNKNOWN) (DOI: 10.17487/RFC0303) 0304 Data Management System Proposal for the ARPA Network. D.B. McKay. February 1972. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0304) 0305 Unknown Host Numbers. R. Alter. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0305) 0306 Network host status. E. Westheimer. February 1972. (Format: TXT, HTML) (Obsoletes RFC0298) (Obsoleted by RFC0315) (Status: UNKNOWN) (DOI: 10.17487/RFC0306) 0307 Using network Remote Job Entry. E. Harslem. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0307) 0308 ARPANET host availability data. M. Seriff. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0308) 0309 Data and File Transfer Workshop Announcement. A.K. Bhushan. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0309) 0310 Another Look at Data and File Transfer Protocols. A.K. Bhushan. April 1972. (Format: TXT, HTML) (Updates RFC0264, RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0310) 0311 New Console Attachments to the USCB Host. R.F. Bryan. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0311) 0312 Proposed Change in IMP-to-Host Protocol. A.M. McKenzie. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0312) 0313 Computer based instruction. T.C. O'Sullivan. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0313) 0314 Network Graphics Working Group Meeting. I.W. Cotton. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0314) 0315 Network Host Status. E. Westheimer. March 1972. (Format: TXT, HTML) (Obsoletes RFC0306) (Obsoleted by RFC0319) (Status: UNKNOWN) (DOI: 10.17487/RFC0315) 0316 ARPA Network Data Management Working Group. D.B. McKay, A.P. Mullery. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0316) 0317 Official Host-Host Protocol Modification: Assigned Link Numbers. J. Postel. March 1972. (Format: TXT, HTML) (Obsoleted by RFC0604) (Status: UNKNOWN) (DOI: 10.17487/RFC0317) 0318 Telnet Protocols. J. Postel. April 1972. (Format: TXT, HTML) (Updates RFC0158) (Updated by RFC0435) (Also RFC0139, RFC0158) (Status: UNKNOWN) (DOI: 10.17487/RFC0318) 0319 Network Host Status. E. Westheimer. March 1972. (Format: TXT, HTML) (Obsoletes RFC0315) (Updated by RFC0326) (Status: UNKNOWN) (DOI: 10.17487/RFC0319) 0320 Workshop on Hard Copy Line Graphics. R. Reddy. March 1972. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0320) 0321 CBI Networking Activity at MITRE. P.M. Karp. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0321) 0322 Well known socket numbers. V. Cerf, J. Postel. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0322) 0323 Formation of Network Measurement Group (NMG). V. Cerf. March 1972. (Format: TXT, HTML) (Updated by RFC0388) (Status: UNKNOWN) (DOI: 10.17487/RFC0323) 0324 RJE Protocol meeting. J. Postel. April 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0324) 0325 Network Remote Job Entry program - NETRJS. G. Hicks. April 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0325) 0326 Network Host Status. E. Westheimer. April 1972. (Format: TXT, HTML) (Obsoleted by RFC0330) (Updates RFC0319) (Status: UNKNOWN) (DOI: 10.17487/RFC0326) 0327 Data and File Transfer workshop notes. A.K. Bhushan. April 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0327) 0328 Suggested Telnet Protocol Changes. J. Postel. April 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0328) 0329 ARPA Network Mailing Lists. Network Information Center. Stanford Research Institute. May 1972. (Format: TXT, HTML) (Obsoletes RFC0303) (Obsoleted by RFC0363) (Status: UNKNOWN) (DOI: 10.17487/RFC0329) 0330 Network Host Status. E. Westheimer. April 1972. (Format: TXT, HTML) (Obsoletes RFC0326) (Updated by RFC0332) (Status: UNKNOWN) (DOI: 10.17487/RFC0330) 0331 IMP System Change Notification. J.M. McQuillan. April 1972. (Format: TXT, HTML) (Obsoleted by RFC0343) (Status: UNKNOWN) (DOI: 10.17487/RFC0331) 0332 Network Host Status. E. Westheimer. April 1972. (Format: TXT, HTML) (Obsoleted by RFC0342) (Updates RFC0330) (Status: UNKNOWN) (DOI: 10.17487/RFC0332) 0333 Proposed experiment with a Message Switching Protocol. R.D. Bressler, D. Murphy, D.C. Walden. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0333) 0334 Network Use on May 8. A.M. McKenzie. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0334) 0335 New Interface - IMP/360. R.F. Bryan. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0335) 0336 Level 0 Graphic Input Protocol. I.W. Cotton. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0336) 0337 Not Issued. 0338 EBCDIC/ASCII Mapping for Network RJE. R.T. Braden. May 1972. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0338) 0339 MLTNET: A "Multi Telnet" Subsystem for Tenex. R. Thomas. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0339) 0340 Proposed Telnet Changes. T.C. O'Sullivan. May 1972. (Format: TXT, HTML) (Also RFC0328) (Status: UNKNOWN) (DOI: 10.17487/RFC0340) 0341 Not Issued. 0342 Network Host Status. E. Westheimer. May 1972. (Format: TXT, HTML) (Obsoletes RFC0332) (Obsoleted by RFC0344) (Status: UNKNOWN) (DOI: 10.17487/RFC0342) 0343 IMP System change notification. A.M. McKenzie. May 1972. (Format: TXT, HTML) (Obsoletes RFC0331) (Obsoleted by RFC0359) (Status: UNKNOWN) (DOI: 10.17487/RFC0343) 0344 Network Host Status. E. Westheimer. May 1972. (Format: TXT, HTML) (Obsoletes RFC0342) (Obsoleted by RFC0353) (Status: UNKNOWN) (DOI: 10.17487/RFC0344) 0345 Interest in Mixed Integer Programming (MPSX on NIC 360/91 at CCN). K.C. Kelley. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0345) 0346 Satellite Considerations. J. Postel. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0346) 0347 Echo process. J. Postel. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0347) 0348 Discard Process. J. Postel. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0348) 0349 Proposed Standard Socket Numbers. J. Postel. May 1972. (Format: TXT, HTML) (Obsoleted by RFC0433) (Also RFC0204, RFC0322) (Status: UNKNOWN) (DOI: 10.17487/RFC0349) 0350 User Accounts for UCSB On-Line System. R. Stoughton. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0350) 0351 Graphics information form for the ARPANET graphics resources notebook. D. Crocker. June 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0351) 0352 TIP Site Information Form. D. Crocker. June 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0352) 0353 Network host status. E. Westheimer. June 1972. (Format: TXT, HTML) (Obsoletes RFC0344) (Obsoleted by RFC0362) (Status: UNKNOWN) (DOI: 10.17487/RFC0353) 0354 File Transfer Protocol. A.K. Bhushan. July 1972. (Format: TXT, HTML) (Obsoletes RFC0264, RFC0265) (Obsoleted by RFC0542) (Updated by RFC0385, RFC0454, RFC0683) (Status: UNKNOWN) (DOI: 10.17487/RFC0354) 0355 Response to NWG/RFC 346. J. Davidson. June 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0355) 0356 ARPA Network Control Center. R. Alter. June 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0356) 0357 Echoing strategy for satellite links. J. Davidson. June 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0357) 0358 Not Issued. 0359 Status of the Release of the New IMP System (2600). D.C. Walden. June 1972. (Format: TXT, HTML) (Obsoletes RFC0343) (Status: UNKNOWN) (DOI: 10.17487/RFC0359) 0360 Proposed Remote Job Entry Protocol. C. Holland. June 1972. (Format: TXT, PDF, HTML) (Obsoleted by RFC0407) (Status: UNKNOWN) (DOI: 10.17487/RFC0360) 0361 Deamon Processes on Host 106. R.D. Bressler. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0361) 0362 Network Host Status. E. Westheimer. June 1972. (Format: TXT, HTML) (Obsoletes RFC0353) (Obsoleted by RFC0366) (Status: UNKNOWN) (DOI: 10.17487/RFC0362) 0363 ARPA Network mailing lists. Network Information Center. Stanford Research Institute. August 1972. (Format: TXT, HTML) (Obsoletes RFC0329) (Obsoleted by RFC0402) (Status: UNKNOWN) (DOI: 10.17487/RFC0363) 0364 Serving remote users on the ARPANET. M.D. Abrams. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0364) 0365 Letter to All TIP Users. D.C. Walden. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0365) 0366 Network Host Status. E. Westheimer. July 1972. (Format: TXT, HTML) (Obsoletes RFC0362) (Obsoleted by RFC0367) (Status: UNKNOWN) (DOI: 10.17487/RFC0366) 0367 Network host status. E. Westheimer. July 1972. (Format: TXT, HTML) (Obsoletes RFC0366) (Obsoleted by RFC0370) (Status: UNKNOWN) (DOI: 10.17487/RFC0367) 0368 Comments on "Proposed Remote Job Entry Protocol". R.T. Braden. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0368) 0369 Evaluation of ARPANET services January-March, 1972. J.R. Pickens. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0369) 0370 Network Host Status. E. Westheimer. July 1972. (Format: TXT, HTML) (Obsoletes RFC0367) (Updated by RFC0376) (Status: UNKNOWN) (DOI: 10.17487/RFC0370) 0371 Demonstration at International Computer Communications Conference. R.E. Kahn. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0371) 0372 Notes on a Conversation with Bob Kahn on the ICCC. R.W. Watson. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0372) 0373 Arbitrary Character Sets. J. McCarthy. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0373) 0374 IMP System Announcement. A.M. McKenzie. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0374) 0375 Not Issued. 0376 Network Host Status. E. Westheimer. August 1972. (Format: TXT, HTML) (Updates RFC0370) (Status: UNKNOWN) (DOI: 10.17487/RFC0376) 0377 Using TSO via ARPA Network Virtual Terminal. R.T. Braden. August 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0377) 0378 Traffic statistics (July 1972). A.M. McKenzie. August 1972. (Format: TXT, HTML) (Obsoleted by RFC0391) (Status: UNKNOWN) (DOI: 10.17487/RFC0378) 0379 Using TSO at CCN. R. Braden. August 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0379) 0380 Not Issued. 0381 Three aids to improved network operation. J.M. McQuillan. July 1972. (Format: TXT, HTML) (Updated by RFC0394) (Status: UNKNOWN) (DOI: 10.17487/RFC0381) 0382 Mathematical Software on the ARPA Network. L. McDaniel. August 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0382) 0383 Not Issued. 0384 Official site idents for organizations in the ARPA Network. J.B. North. August 1972. (Format: TXT, HTML) (Obsoletes RFC0289) (Status: UNKNOWN) (DOI: 10.17487/RFC0384) 0385 Comments on the File Transfer Protocol. A.K. Bhushan. August 1972. (Format: TXT, HTML) (Updates RFC0354) (Updated by RFC0414) (Status: UNKNOWN) (DOI: 10.17487/RFC0385) 0386 Letter to TIP users-2. B. Cosell, D.C. Walden. August 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0386) 0387 Some experiences in implementing Network Graphics Protocol Level 0. K.C. Kelley, J. Meir. August 1972. (Format: TXT, HTML) (Updated by RFC0401) (Status: UNKNOWN) (DOI: 10.17487/RFC0387) 0388 NCP statistics. V. Cerf. August 1972. (Format: TXT, HTML) (Updates RFC0323) (Status: UNKNOWN) (DOI: 10.17487/RFC0388) 0389 UCLA Campus Computing Network Liaison Staff for ARPA Network. B. Noble. August 1972. (Format: TXT, HTML) (Obsoleted by RFC0423) (Status: UNKNOWN) (DOI: 10.17487/RFC0389) 0390 TSO Scenario. R.T. Braden. September 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0390) 0391 Traffic statistics (August 1972). A.M. McKenzie. September 1972. (Format: TXT, HTML) (Obsoletes RFC0378) (Status: UNKNOWN) (DOI: 10.17487/RFC0391) 0392 Measurement of host costs for transmitting network data. G. Hicks, B.D. Wessler. September 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0392) 0393 Comments on Telnet Protocol Changes. J.M. Winett. October 1972. (Format: TXT, HTML) (Also RFC0109, RFC0139, RFC0158, RFC0318, RFC0328) (Status: UNKNOWN) (DOI: 10.17487/RFC0393) 0394 Two Proposed Changes to the IMP-Host Protocol. J.M. McQuillan. September 1972. (Format: TXT, HTML) (Updates RFC0381) (Status: UNKNOWN) (DOI: 10.17487/RFC0394) 0395 Switch Settings on IMPs and TIPs. J.M. McQuillan. October 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0395) 0396 Network Graphics Working Group Meeting - Second Iteration. S. Bunch. November 1972. (Format: TXT, HTML) (Updated by RFC0474) (Status: UNKNOWN) (DOI: 10.17487/RFC0396) 0397 Not Issued. 0398 UCSB Online Graphics. J.R. Pickens, E. Faeh. September 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0398) 0399 SMFS Login and Logout. M. Krilanovich. September 1972. (Format: TXT, HTML) (Obsoleted by RFC0431) (Updates RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0399) 0400 Traffic Statistics (September 1972). A.M. McKenzie. October 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0400) 0401 Conversion of NGP-0 Coordinates to Device Specific Coordinates. J. Hansen. October 1972. (Format: TXT, HTML) (Updates RFC0387) (Status: UNKNOWN) (DOI: 10.17487/RFC0401) 0402 ARPA Network Mailing Lists. J.B. North. October 1972. (Format: TXT, HTML) (Obsoletes RFC0363) (Status: UNKNOWN) (DOI: 10.17487/RFC0402) 0403 Desirability of a Network 1108 Service. G. Hicks. January 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0403) 0404 Host Address Changes Involving Rand and ISI. A.M. McKenzie. October 1972. (Format: TXT, HTML) (Updated by RFC0405) (Status: UNKNOWN) (DOI: 10.17487/RFC0404) 0405 Correction to RFC 404. A.M. McKenzie. October 1972. (Format: TXT, HTML) (Updates RFC0404) (Status: UNKNOWN) (DOI: 10.17487/RFC0405) 0406 Scheduled IMP Software Releases. J.M. McQuillan. October 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0406) 0407 Remote Job Entry Protocol. R.D. Bressler, R. Guida, A.M. McKenzie. October 1972. (Format: TXT, HTML) (Obsoletes RFC0360) (Status: HISTORIC) (DOI: 10.17487/RFC0407) 0408 NETBANK. A.D. Owen, J. Postel. October 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0408) 0409 Tenex interface to UCSB's Simple-Minded File System. J.E. White. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0409) 0410 Removal of the 30-Second Delay When Hosts Come Up. J.M. McQuillan. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0410) 0411 New MULTICS Network Software Features. M.A. Padlipsky. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0411) 0412 User FTP Documentation. G. Hicks. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0412) 0413 Traffic statistics (October 1972). A.M. McKenzie. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0413) 0414 File Transfer Protocol (FTP) status and further comments. A.K. Bhushan. December 1972. (Format: TXT, HTML) (Updates RFC0385) (Status: UNKNOWN) (DOI: 10.17487/RFC0414) 0415 Tenex bandwidth. H. Murray. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0415) 0416 ARC System Will Be Unavailable for Use During Thanksgiving Week. J.C. Norton. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0416) 0417 Link usage violation. J. Postel, C. Kline. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0417) 0418 Server File Transfer Under TSS/360 At NASA-Ames Research Center. W. Hathaway. November 1972. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0418) 0419 To: Network liaisons and station agents. A. Vezza. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0419) 0420 CCA ICCC weather demo. H. Murray. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0420) 0421 Software Consulting Service for Network Users. A.M. McKenzie. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0421) 0422 Traffic statistics (November 1972). A.M. McKenzie. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0422) 0423 UCLA Campus Computing Network Liaison Staff for ARPANET. B. Noble. December 1972. (Format: TXT, HTML) (Obsoletes RFC0389) (Status: UNKNOWN) (DOI: 10.17487/RFC0423) 0424 Not Issued. 0425 "But my NCP costs $500 a day". R.D. Bressler. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0425) 0426 Reconnection Protocol. R. Thomas. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0426) 0427 Not Issued. 0428 Not Issued. 0429 Character Generator Process. J. Postel. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0429) 0430 Comments on File Transfer Protocol. R.T. Braden. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0430) 0431 Update on SMFS Login and Logout. M. Krilanovich. December 1972. (Format: TXT, HTML) (Obsoletes RFC0399) (Updates RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0431) 0432 Network logical map. N. Neigus. December 1972. (Format: TXT, PDF, PS, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0432) 0433 Socket number list. J. Postel. December 1972. (Format: TXT, HTML) (Obsoletes RFC0349) (Obsoleted by RFC0503) (Status: UNKNOWN) (DOI: 10.17487/RFC0433) 0434 IMP/TIP memory retrofit schedule. A.M. McKenzie. January 1973. (Format: TXT, HTML) (Obsoleted by RFC0447) (Status: UNKNOWN) (DOI: 10.17487/RFC0434) 0435 Telnet issues. B. Cosell, D.C. Walden. January 1973. (Format: TXT, HTML) (Updates RFC0318) (Status: UNKNOWN) (DOI: 10.17487/RFC0435) 0436 Announcement of RJS at UCSB. M. Krilanovich. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0436) 0437 Data Reconfiguration Service at UCSB. E. Faeh. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0437) 0438 FTP server-server interaction. R. Thomas, R. Clements. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0438) 0439 PARRY encounters the DOCTOR. V. Cerf. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0439) 0440 Scheduled network software maintenance. D.C. Walden. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0440) 0441 Inter-Entity Communication - an experiment. R.D. Bressler, R. Thomas. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0441) 0442 Current flow-control scheme for IMPSYS. V. Cerf. January 1973. (Format: TXT, HTML) (Updated by RFC0449) (Status: UNKNOWN) (DOI: 10.17487/RFC0442) 0443 Traffic statistics (December 1972). A.M. McKenzie. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0443) 0444 Not Issued. 0445 IMP/TIP preventive maintenance schedule. A.M. McKenzie. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0445) 0446 Proposal to consider a network program resource notebook. L.P. Deutsch. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0446) 0447 IMP/TIP memory retrofit schedule. A.M. McKenzie. January 1973. (Format: TXT, HTML) (Obsoletes RFC0434) (Obsoleted by RFC0476) (Status: UNKNOWN) (DOI: 10.17487/RFC0447) 0448 Print files in FTP. R.T. Braden. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0448) 0449 Current flow-control scheme for IMPSYS. D.C. Walden. January 1973. (Format: TXT, HTML) (Updates RFC0442) (Status: UNKNOWN) (DOI: 10.17487/RFC0449) 0450 MULTICS sampling timeout change. M.A. Padlipsky. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0450) 0451 Tentative proposal for a Unified User Level Protocol. M.A. Padlipsky. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0451) 0452 TELNET Command at Host LL. J. Winett. February 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0452) 0453 Meeting announcement to discuss a network mail system. M.D. Kudlick. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0453) 0454 File Transfer Protocol - meeting announcement and a new proposed document. A.M. McKenzie. February 1973. (Format: TXT, HTML) (Updates RFC0354) (Status: UNKNOWN) (DOI: 10.17487/RFC0454) 0455 Traffic statistics (January 1973). A.M. McKenzie. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0455) 0456 Memorandum: Date change of mail meeting. M.D. Kudlick. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0456) 0457 TIPUG. D.C. Walden. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0457) 0458 Mail retrieval via FTP. R.D. Bressler, R. Thomas. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0458) 0459 Network questionnaires. W. Kantrowitz. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0459) 0460 NCP survey. C. Kline. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0460) 0461 Telnet Protocol meeting announcement. A.M. McKenzie. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0461) 0462 Responding to user needs. J. Iseli, D. Crocker. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0462) 0463 FTP comments and response to RFC 430. A.K. Bhushan. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0463) 0464 Resource notebook framework. M.D. Kudlick. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0464) 0465 Not Issued. 0466 Telnet logger/server for host LL-67. J.M. Winett. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0466) 0467 Proposed change to Host-Host Protocol: Resynchronization of connection status. J.D. Burchfiel, R.S. Tomlinson. February 1973. (Format: TXT, HTML) (Updated by RFC0492) (Status: UNKNOWN) (DOI: 10.17487/RFC0467) 0468 FTP data compression. R.T. Braden. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0468) 0469 Network mail meeting summary. M.D. Kudlick. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0469) 0470 Change in socket for TIP news facility. R. Thomas. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0470) 0471 Workshop on multi-site executive programs. R. Thomas. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0471) 0472 Illinois' reply to Maxwell's request for graphics information (NIC 14925). S. Bunch. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0472) 0473 MIX and MIXAL?. D.C. Walden. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0473) 0474 Announcement of NGWG meeting: Call for papers. S. Bunch. March 1973. (Format: TXT, HTML) (Updates RFC0396) (Status: UNKNOWN) (DOI: 10.17487/RFC0474) 0475 FTP and Network Mail System. A.K. Bhushan. March 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0475) 0476 IMP/TIP memory retrofit schedule (rev 2). A.M. McKenzie. March 1973. (Format: TXT, HTML) (Obsoletes RFC0447) (Status: UNKNOWN) (DOI: 10.17487/RFC0476) 0477 Remote Job Service at UCSB. M. Krilanovich. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0477) 0478 FTP server-server interaction - II. R.D. Bressler, R. Thomas. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0478) 0479 Use of FTP by the NIC Journal. J.E. White. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0479) 0480 Host-dependent FTP parameters. J.E. White. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0480) 0481 Not Issued. 0482 Traffic statistics (February 1973). A.M. McKenzie. March 1973. (Format: TXT, HTML) (Updated by RFC0497) (Status: UNKNOWN) (DOI: 10.17487/RFC0482) 0483 Cancellation of the resource notebook framework meeting. M.D. Kudlick. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0483) 0484 Not Issued. 0485 MIX and MIXAL at UCSB. J.R. Pickens. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0485) 0486 Data transfer revisited. R.D. Bressler. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0486) 0487 Free file transfer. R.D. Bressler. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0487) 0488 NLS classes at network sites. M.F. Auerbach. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0488) 0489 Comment on resynchronization of connection status proposal. J. Postel. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0489) 0490 Surrogate RJS for UCLA-CCN. J.R. Pickens. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0490) 0491 What is "Free"?. M.A. Padlipsky. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0491) 0492 Response to RFC 467. E. Meyer. April 1973. (Format: TXT, HTML) (Updates RFC0467) (Status: UNKNOWN) (DOI: 10.17487/RFC0492) 0493 GRAPHICS PROTOCOL. J.C. Michener, I.W. Cotton, K.C. Kelley, D.E. Liddle, E. Meyer. April 1973. (Format: TXT, PDF, HTML) (Obsoletes RFC0292) (Status: UNKNOWN) (DOI: 10.17487/RFC0493) 0494 Availability of MIX and MIXAL in the Network. D.C. Walden. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0494) 0495 Telnet Protocol specifications. A.M. McKenzie. May 1973. (Format: TXT, HTML) (Obsoletes RFC0158) (Updated by RFC0562) (Status: UNKNOWN) (DOI: 10.17487/RFC0495) 0496 TNLS quick reference card is available. M.F. Auerbach. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0496) 0497 Traffic Statistics (March 1973). A.M. McKenzie. April 1973. (Format: TXT, PDF, HTML) (Updates RFC0482) (Status: UNKNOWN) (DOI: 10.17487/RFC0497) 0498 On mail service to CCN. R.T. Braden. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0498) 0499 Harvard's network RJE. B.R. Reussow. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0499) 0500 Integration of data management systems on a computer network. A. Shoshani, I. Spiegler. April 1973. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0500) 0501 Un-muddling "free file transfer". K.T. Pogran. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0501) 0502 Not Issued. 0503 Socket number list. N. Neigus, J. Postel. April 1973. (Format: TXT, HTML) (Obsoletes RFC0433) (Obsoleted by RFC0739) (Status: UNKNOWN) (DOI: 10.17487/RFC0503) 0504 Distributed resources workshop announcement. R. Thomas. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0504) 0505 Two solutions to a file transfer access problem. M.A. Padlipsky. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0505) 0506 FTP command naming problem. M.A. Padlipsky. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0506) 0507 Not Issued. 0508 Real-time data transmission on the ARPANET. L. Pfeifer, J. McAfee. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0508) 0509 Traffic statistics (April 1973). A.M. McKenzie. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0509) 0510 Request for network mailbox addresses. J.E. White. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0510) 0511 Enterprise phone service to NIC from ARPANET sites. J.B. North. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0511) 0512 More on lost message detection. W. Hathaway. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0512) 0513 Comments on the new Telnet specifications. W. Hathaway. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0513) 0514 Network make-work. W. Kantrowitz. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0514) 0515 Specifications for Datalanguage, Version 0/9. R. Winter. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0515) 0516 Lost message detection. J. Postel. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0516) 0517 Not Issued. 0518 ARPANET accounts. N. Vaughan, E.J. Feinler. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0518) 0519 Resource Evaluation. J.R. Pickens. June 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0519) 0520 Memo to FTP group: Proposal for File Access Protocol. J.D. Day. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0520) 0521 Restricted use of IMP DDT. A.M. McKenzie. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0521) 0522 Traffic Statistics (May 1973). A.M. McKenzie. June 1973. (Format: TXT, PDF, HTML) (Updates RFC0509) (Status: UNKNOWN) (DOI: 10.17487/RFC0522) 0523 SURVEY is in operation again. A.K. Bhushan. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0523) 0524 Proposed Mail Protocol. J.E. White. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0524) 0525 MIT-MATHLAB meets UCSB-OLS -an example of resource sharing. W. Parrish, J.R. Pickens. June 1973. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0525) 0526 Technical meeting: Digital image processing software systems. W.K. Pratt. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0526) 0527 ARPAWOCKY. R. Merryman. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0527) 0528 Software checksumming in the IMP and network reliability. J.M. McQuillan. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0528) 0529 Note on protocol synch sequences. A.M. McKenzie, R. Thomas, R.S. Tomlinson, K.T. Pogran. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0529) 0530 Report on the Survey Project. A.K. Bhushan. June 1973. (Format: PDF, HTML) (Updates RFC0308, RFC0523) (Status: UNKNOWN) (DOI: 10.17487/RFC0530) 0531 Feast or famine? A response to two recent RFC's about network information. M.A. Padlipsky. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0531) 0532 UCSD-CC Server-FTP facility. R.G. Merryman. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0532) 0533 Message-ID numbers. D.C. Walden. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0533) 0534 Lost message detection. D.C. Walden. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0534) 0535 Comments on File Access Protocol. R. Thomas. July 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0535) 0536 Not Issued. 0537 Announcement of NGG meeting July 16-17. S. Bunch. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0537) 0538 Traffic statistics (June 1973). A.M. McKenzie. July 1973. (Format: TXT, HTML) (Updated by RFC0556) (Status: UNKNOWN) (DOI: 10.17487/RFC0538) 0539 Thoughts on the mail protocol proposed in RFC 524. D. Crocker, J. Postel. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0539) 0540 Not Issued. 0541 Not Issued. 0542 File Transfer Protocol. N. Neigus. August 1973. (Format: TXT, HTML) (Obsoletes RFC0354) (Obsoleted by RFC0765) (Updated by RFC0614, RFC0640) (Also RFC0454, RFC0495) (Status: UNKNOWN) (DOI: 10.17487/RFC0542) 0543 Network journal submission and delivery. N.D. Meyer. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0543) 0544 Locating on-line documentation at SRI-ARC. N.D. Meyer, K. Kelley. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0544) 0545 Of what quality be the UCSB resources evaluators?. J.R. Pickens. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0545) 0546 Tenex load averages for July 1973. R. Thomas. August 1973. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0546) 0547 Change to the Very Distant Host specification. D.C. Walden. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0547) 0548 Hosts using the IMP Going Down message. D.C. Walden. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0548) 0549 Minutes of Network Graphics Group meeting, 15-17 July 1973. J.C. Michener. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0549) 0550 NIC NCP experiment. L.P. Deutsch. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0550) 0551 NYU, ANL, and LBL Joining the Net. Y. Feinroth, R. Fink. August 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0551) 0552 Single access to standard protocols. A.D. Owen. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0552) 0553 Draft design for a text/graphics protocol. C.H. Irby, K. Victor. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0553) 0554 Not Issued. 0555 Responses to critiques of the proposed mail protocol. J.E. White. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0555) 0556 Traffic Statistics (July 1973). A.M. McKenzie. August 1973. (Format: TXT, PDF, HTML) (Updates RFC0538) (Status: UNKNOWN) (DOI: 10.17487/RFC0556) 0557 REVELATIONS IN NETWORK HOST MEASUREMENTS. B.D. Wessler. August 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0557) 0558 Not Issued. 0559 Comments on The New Telnet Protocol and its Implementation. A.K. Bushan. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0559) 0560 Remote Controlled Transmission and Echoing Telnet option. D. Crocker, J. Postel. August 1973. (Format: TXT, PDF, HTML) (Updated by RFC0581) (Status: UNKNOWN) (DOI: 10.17487/RFC0560) 0561 Standardizing Network Mail Headers. A.K. Bhushan, K.T. Pogran, R.S. Tomlinson, J.E. White. September 1973. (Format: TXT, HTML) (Updated by RFC0680) (Status: UNKNOWN) (DOI: 10.17487/RFC0561) 0562 Modifications to the TELNET Specification. A.M. McKenzie. August 1973. (Format: TXT, PDF, HTML) (Updates RFC0495) (Status: UNKNOWN) (DOI: 10.17487/RFC0562) 0563 Comments on the RCTE Telnet option. J. Davidson. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0563) 0564 Not Issued. 0565 Storing network survey data at the datacomputer. D. Cantor. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0565) 0566 Traffic statistics (August 1973). A.M. McKenzie. September 1973. (Format: TXT, HTML) (Updated by RFC0579) (Status: UNKNOWN) (DOI: 10.17487/RFC0566) 0567 Cross Country Network Bandwidth. L.P. Deutsch. September 1973. (Format: TXT, HTML) (Updated by RFC0568) (Status: UNKNOWN) (DOI: 10.17487/RFC0567) 0568 Response to RFC 567 - cross country network bandwidth. J.M. McQuillan. September 1973. (Format: TXT, HTML) (Updates RFC0567) (Status: UNKNOWN) (DOI: 10.17487/RFC0568) 0569 NETED: A Common Editor for the ARPA Network. M.A. Padlipsky. October 1973. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0569) 0570 Experimental input mapping between NVT ASCII and UCSB On Line System. J.R. Pickens. October 1973. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0570) 0571 TENEX FTP PROBLEM. R. Braden. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0571) 0572 Not Issued. 0573 DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS. A. Bhushan. September 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0573) 0574 Announcement of a Mail Facility at UCSB. M. Krilanovich. September 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0574) 0575 Not Issued. 0576 Proposal for modifying linking. K. Victor. September 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0576) 0577 Mail priority. D. Crocker. October 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0577) 0578 Using MIT-Mathlab MACSYMA from MIT-DMS Muddle. A.K. Bhushan, N.D. Ryan. October 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0578) 0579 Traffic statistics (September 1973). A.M. McKenzie. November 1973. (Format: TXT, PDF, HTML) (Updates RFC0566) (Updated by RFC0586) (Status: UNKNOWN) (DOI: 10.17487/RFC0579) 0580 Note to Protocol Designers and Implementers. J. Postel. October 1973. (Format: TXT, HTML) (Updated by RFC0582) (Status: UNKNOWN) (DOI: 10.17487/RFC0580) 0581 Corrections to RFC 560: Remote Controlled Transmission and Echoing Telnet Option. D. Crocker, J. Postel. November 1973. (Format: TXT, PDF, HTML) (Updates RFC0560) (Status: UNKNOWN) (DOI: 10.17487/RFC0581) 0582 Comments on RFC 580: Machine readable protocols. R. Clements. November 1973. (Format: TXT, HTML) (Updates RFC0580) (Status: UNKNOWN) (DOI: 10.17487/RFC0582) 0583 Not Issued. 0584 Charter for ARPANET Users Interest Working Group. J. Iseli, D. Crocker, N. Neigus. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0584) 0585 ARPANET users interest working group meeting. D. Crocker, N. Neigus, E.J. Feinler, J. Iseli. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0585) 0586 Traffic statistics (October 1973). A.M. McKenzie. November 1973. (Format: TXT, PDF, HTML) (Updates RFC0579) (Status: UNKNOWN) (DOI: 10.17487/RFC0586) 0587 Announcing New Telnet Options. J. Postel. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0587) 0588 London Node Is Now Up. A. Stokes. October 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0588) 0589 CCN NETRJS server messages to remote user. R.T. Braden. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0589) 0590 MULTICS address change. M.A. Padlipsky. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0590) 0591 Addition to the Very Distant Host specifications. D.C. Walden. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0591) 0592 Some thoughts on system design to facilitate resource sharing. R.W. Watson. November 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0592) 0593 Telnet and FTP implementation schedule change. A.M. McKenzie, J. Postel. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0593) 0594 Speedup of Host-IMP interface. J.D. Burchfiel. December 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0594) 0595 Second thoughts in defense of the Telnet Go-Ahead. W. Hathaway. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0595) 0596 Second thoughts on Telnet Go-Ahead. E.A. Taft. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0596) 0597 Host status. N. Neigus, E.J. Feinler. December 1973. (Format: TXT, HTML) (Updated by RFC0603) (Status: UNKNOWN) (DOI: 10.17487/RFC0597) 0598 RFC index - December 5, 1973. Network Information Center. Stanford Research Institute. December 1973. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0598) 0599 Update on NETRJS. R.T. Braden. December 1973. (Format: TXT, HTML) (Obsoletes RFC0189) (Obsoleted by RFC0740) (Status: UNKNOWN) (DOI: 10.17487/RFC0599) 0600 Interfacing an Illinois plasma terminal to the ARPANET. A. Berggreen. November 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0600) 0601 Traffic statistics (November 1973). A.M. McKenzie. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0601) 0602 "The stockings were hung by the chimney with care". R.M. Metcalfe. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0602) 0603 Response to RFC 597: Host status. J.D. Burchfiel. December 1973. (Format: TXT, HTML) (Updates RFC0597) (Updated by RFC0613) (Status: UNKNOWN) (DOI: 10.17487/RFC0603) 0604 Assigned link numbers. J. Postel. December 1973. (Format: TXT, HTML) (Obsoletes RFC0317) (Obsoleted by RFC0739) (Status: UNKNOWN) (DOI: 10.17487/RFC0604) 0605 Not Issued. 0606 Host names on-line. L.P. Deutsch. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0606) 0607 Comments on the File Transfer Protocol. M. Krilanovich, G. Gregg. January 1974. (Format: TXT, HTML) (Obsoleted by RFC0624) (Updated by RFC0614) (Status: UNKNOWN) (DOI: 10.17487/RFC0607) 0608 Host names on-line. M.D. Kudlick. January 1974. (Format: TXT, HTML) (Obsoleted by RFC0810) (Status: UNKNOWN) (DOI: 10.17487/RFC0608) 0609 Statement of upcoming move of NIC/NLS service. B. Ferguson. January 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0609) 0610 Further datalanguage design concepts. R. Winter, J. Hill, W. Greiff. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0610) 0611 Two changes to the IMP/Host Protocol to improve user/network communications. D.C. Walden. February 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0611) 0612 Traffic statistics (December 1973). A.M. McKenzie. January 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0612) 0613 Network connectivity: A response to RFC 603. A.M. McKenzie. January 1974. (Format: TXT, HTML) (Updates RFC0603) (Status: UNKNOWN) (DOI: 10.17487/RFC0613) 0614 Response to RFC 607: "Comments on the File Transfer Protocol". K.T. Pogran, N. Neigus. January 1974. (Format: TXT, HTML) (Updates RFC0542, RFC0607) (Status: UNKNOWN) (DOI: 10.17487/RFC0614) 0615 Proposed Network Standard Data Pathname syntax. D. Crocker. March 1974. (Format: TXT, HTML) (Obsoleted by RFC0645) (Status: UNKNOWN) (DOI: 10.17487/RFC0615) 0616 LATEST NETWORK MAPS. D. Walden. February 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0616) 0617 Note on socket number assignment. E.A. Taft. February 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0617) 0618 Few observations on NCP statistics. E.A. Taft. February 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0618) 0619 Mean round-trip times in the ARPANET. W. Naylor, H. Opderbeck. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0619) 0620 Request for monitor host table updates. B. Ferguson. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0620) 0621 NIC user directories at SRI ARC. M.D. Kudlick. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0621) 0622 Scheduling IMP/TIP down time. A.M. McKenzie. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0622) 0623 Comments on on-line host name service. M. Krilanovich. February 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0623) 0624 Comments on the File Transfer Protocol. M. Krilanovich, G. Gregg, W. Hathaway, J.E. White. February 1974. (Format: TXT, HTML) (Obsoletes RFC0607) (Status: UNKNOWN) (DOI: 10.17487/RFC0624) 0625 On-line hostnames service. M.D. Kudlick, E.J. Feinler. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0625) 0626 On a possible lockup condition in IMP subnet due to message sequencing. L. Kleinrock, H. Opderbeck. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0626) 0627 ASCII text file of hostnames. M.D. Kudlick, E.J. Feinler. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0627) 0628 Status of RFC numbers and a note on pre-assigned journal numbers. M.L. Keeney. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0628) 0629 Scenario for using the Network Journal. J.B. North. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0629) 0630 FTP error code usage for more reliable mail service. J. Sussman. April 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0630) 0631 International meeting on minicomputers and data communication: Call for papers. A. Danthine. April 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0631) 0632 Throughput degradations for single packet messages. H. Opderbeck. May 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0632) 0633 IMP/TIP preventive maintenance schedule. A.M. McKenzie. March 1974. (Format: TXT, HTML) (Obsoleted by RFC0638) (Status: UNKNOWN) (DOI: 10.17487/RFC0633) 0634 Change in network address for Haskins Lab. A.M. McKenzie. April 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0634) 0635 Assessment of ARPANET protocols. V. Cerf. April 1974. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0635) 0636 TIP/Tenex reliability improvements. J.D. Burchfiel, B. Cosell, R.S. Tomlinson, D.C. Walden. June 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0636) 0637 Change of network address for SU-DSL. A.M. McKenzie. April 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0637) 0638 IMP/TIP preventive maintenance schedule. A.M. McKenzie. April 1974. (Format: TXT, HTML) (Obsoletes RFC0633) (Status: UNKNOWN) (DOI: 10.17487/RFC0638) 0639 Not Issued. 0640 Revised FTP reply codes. J. Postel. June 1974. (Format: TXT, HTML) (Updates RFC0542) (Status: UNKNOWN) (DOI: 10.17487/RFC0640) 0641 Not Issued. 0642 Ready line philosophy and implementation. J.D. Burchfiel. July 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0642) 0643 Network Debugging Protocol. E. Mader. July 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0643) 0644 On the problem of signature authentication for network mail. R. Thomas. July 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0644) 0645 Network Standard Data Specification syntax. D. Crocker. June 1974. (Format: TXT, PDF, HTML) (Obsoletes RFC0615) (Status: UNKNOWN) (DOI: 10.17487/RFC0645) 0646 Not Issued. 0647 Proposed protocol for connecting host computers to ARPA-like networks via front end processors. M.A. Padlipsky. November 1974. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0647) 0648 Not Issued. 0649 Not Issued. 0650 Not Issued. 0651 Revised Telnet status option. D. Crocker. October 1974. (Format: TXT, HTML) (Obsoleted by RFC0859) (Status: UNKNOWN) (DOI: 10.17487/RFC0651) 0652 Telnet output carriage-return disposition option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0652) 0653 Telnet output horizontal tabstops option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0653) 0654 Telnet output horizontal tab disposition option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0654) 0655 Telnet output formfeed disposition option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0655) 0656 Telnet output vertical tabstops option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0656) 0657 Telnet output vertical tab disposition option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0657) 0658 Telnet output linefeed disposition. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0658) 0659 Announcing additional Telnet options. J. Postel. October 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0659) 0660 Some changes to the IMP and the IMP/Host interface. D.C. Walden. October 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0660) 0661 Protocol information. J. Postel. November 1974. (Format: TXT, PDF, HTML) (Updated by RFC0694) (Status: UNKNOWN) (DOI: 10.17487/RFC0661) 0662 Performance improvement in ARPANET file transfers from Multics. R. Kanodia. November 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0662) 0663 Lost message detection and recovery protocol. R. Kanodia. November 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0663) 0664 Not Issued. 0665 Not Issued. 0666 Specification of the Unified User-Level Protocol. M.A. Padlipsky. November 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0666) 0667 Host Ports. S.G. Chipman. December 1974. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0667) 0668 Not Issued. 0669 November, 1974, survey of New-Protocol Telnet servers. D.W. Dodds. December 1974. (Format: TXT, PDF, HTML) (Updates RFC0702) (Updated by RFC0679) (Status: UNKNOWN) (DOI: 10.17487/RFC0669) 0670 Not Issued. 0671 Note on Reconnection Protocol. R. Schantz. December 1974. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0671) 0672 Multi-site data collection facility. R. Schantz. December 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0672) 0673 Not Issued. 0674 Procedure call documents: Version 2. J. Postel, J.E. White. December 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0674) 0675 Specification of Internet Transmission Control Program. V. Cerf, Y. Dalal, C. Sunshine. December 1974. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0675) 0676 Not Issued. 0677 Maintenance of duplicate databases. P.R. Johnson, R. Thomas. January 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0677) 0678 Standard file formats. J. Postel. December 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0678) 0679 February, 1975, survey of New-Protocol Telnet servers. D.W. Dodds. February 1975. (Format: TXT, PDF, HTML) (Updates RFC0669) (Updated by RFC0703) (Status: UNKNOWN) (DOI: 10.17487/RFC0679) 0680 Message Transmission Protocol. T.H. Myer, D.A. Henderson. April 1975. (Format: TXT, HTML) (Updates RFC0561) (Status: UNKNOWN) (DOI: 10.17487/RFC0680) 0681 Network UNIX. S. Holmgren. March 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0681) 0682 Not Issued. 0683 FTPSRV - Tenex extension for paged files. R. Clements. April 1975. (Format: TXT, HTML) (Updates RFC0354) (Status: UNKNOWN) (DOI: 10.17487/RFC0683) 0684 Commentary on procedure calling as a network protocol. R. Schantz. April 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0684) 0685 Response time in cross network debugging. M. Beeler. April 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0685) 0686 Leaving well enough alone. B. Harvey. May 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0686) 0687 IMP/Host and Host/IMP Protocol changes. D.C. Walden. June 1975. (Format: TXT, HTML) (Obsoleted by RFC0704) (Updated by RFC0690) (Status: UNKNOWN) (DOI: 10.17487/RFC0687) 0688 Tentative schedule for the new Telnet implementation for the TIP. D.C. Walden. June 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0688) 0689 Tenex NCP finite state machine for connections. R. Clements. May 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0689) 0690 Comments on the proposed Host/IMP Protocol changes. J. Postel. June 1975. (Format: TXT, HTML) (Updates RFC0687) (Updated by RFC0692) (Status: UNKNOWN) (DOI: 10.17487/RFC0690) 0691 One more try on the FTP. B. Harvey. June 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0691) 0692 Comments on IMP/Host Protocol changes (RFCs 687 and 690). S.M. Wolfe. June 1975. (Format: TXT, HTML) (Updates RFC0690) (Status: UNKNOWN) (DOI: 10.17487/RFC0692) 0693 Not Issued. 0694 Protocol information. J. Postel. June 1975. (Format: TXT, PDF, HTML) (Updates RFC0661) (Status: UNKNOWN) (DOI: 10.17487/RFC0694) 0695 Official change in Host-Host Protocol. M. Krilanovich. July 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0695) 0696 Comments on the IMP/Host and Host/IMP Protocol changes. V.G. Cerf. July 1975. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0696) 0697 CWD command of FTP. J. Lieb. July 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0697) 0698 Telnet extended ASCII option. T. Mock. July 1975. (Format: TXT, HTML) (Obsoleted by RFC5198) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0698) 0699 Request For Comments summary notes: 600-699. J. Postel, J. Vernon. November 1982. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0699) 0700 Protocol experiment. E. Mader, W.W. Plummer, R.S. Tomlinson. August 1974. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0700) 0701 August, 1974, survey of New-Protocol Telnet servers. D.W. Dodds. August 1974. (Format: TXT, HTML) (Updated by RFC0702) (Status: UNKNOWN) (DOI: 10.17487/RFC0701) 0702 September, 1974, survey of New-Protocol Telnet servers. D.W. Dodds. September 1974. (Format: TXT, HTML) (Updates RFC0701) (Updated by RFC0669) (Status: UNKNOWN) (DOI: 10.17487/RFC0702) 0703 July, 1975, survey of New-Protocol Telnet Servers. D.W. Dodds. July 1975. (Format: TXT, HTML) (Updates RFC0679) (Status: UNKNOWN) (DOI: 10.17487/RFC0703) 0704 IMP/Host and Host/IMP Protocol change. P.J. Santos. September 1975. (Format: TXT, HTML) (Obsoletes RFC0687) (Status: UNKNOWN) (DOI: 10.17487/RFC0704) 0705 Front-end Protocol B6700 version. R.F. Bryan. November 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0705) 0706 On the junk mail problem. J. Postel. November 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0706) 0707 High-level framework for network-based resource sharing. J.E. White. December 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0707) 0708 Elements of a Distributed Programming System. J.E. White. January 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0708) 0709 Not Issued. 0710 Not Issued. 0711 Not Issued. 0712 Distributed Capability Computing System (DCCS). J.E. Donnelley. February 1976. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0712) 0713 MSDTP-Message Services Data Transmission Protocol. J. Haverty. April 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0713) 0714 Host-Host Protocol for an ARPANET-Type Network. A.M. McKenzie. April 1976. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0714) 0715 Not Issued. 0716 Interim Revision to Appendix F of BBN 1822. D.C. Walden, J. Levin. May 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0716) 0717 Assigned Network Numbers. J. Postel. July 1976. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0717) 0718 Comments on RCTE from the Tenex Implementation Experience. J. Postel. June 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0718) 0719 Discussion on RCTE. J. Postel. July 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0719) 0720 Address Specification Syntax for Network Mail. D. Crocker. August 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0720) 0721 Out-of-Band Control Signals in a Host-to-Host Protocol. L.L. Garlick. September 1976. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0721) 0722 Thoughts on Interactions in Distributed Services. J. Haverty. September 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0722) 0723 Not Issued. 0724 Proposed official standard for the format of ARPA Network messages. D. Crocker, K.T. Pogran, J. Vittal, D.A. Henderson. May 1977. (Format: TXT, HTML) (Obsoleted by RFC0733) (Status: UNKNOWN) (DOI: 10.17487/RFC0724) 0725 RJE protocol for a resource sharing network. J.D. Day, G.R. Grossman. March 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0725) 0726 Remote Controlled Transmission and Echoing Telnet option. J. Postel, D. Crocker. March 1977. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0726) 0727 Telnet logout option. M.R. Crispin. April 1977. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0727) 0728 Minor pitfall in the Telnet Protocol. J.D. Day. April 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0728) 0729 Telnet byte macro option. D. Crocker. May 1977. (Format: TXT, HTML) (Obsoleted by RFC0735) (Status: UNKNOWN) (DOI: 10.17487/RFC0729) 0730 Extensible field addressing. J. Postel. May 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0730) 0731 Telnet Data Entry Terminal option. J.D. Day. June 1977. (Format: TXT, HTML) (Obsoleted by RFC0732) (Status: UNKNOWN) (DOI: 10.17487/RFC0731) 0732 Telnet Data Entry Terminal option. J.D. Day. September 1977. (Format: TXT, HTML) (Obsoletes RFC0731) (Updated by RFC1043) (Status: UNKNOWN) (DOI: 10.17487/RFC0732) 0733 Standard for the format of ARPA network text messages. D. Crocker, J. Vittal, K.T. Pogran, D.A. Henderson. November 1977. (Format: TXT, HTML) (Obsoletes RFC0724) (Obsoleted by RFC0822) (Status: UNKNOWN) (DOI: 10.17487/RFC0733) 0734 SUPDUP Protocol. M.R. Crispin. October 1977. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0734) 0735 Revised Telnet byte macro option. D. Crocker, R.H. Gumpertz. November 1977. (Format: TXT, HTML) (Obsoletes RFC0729) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0735) 0736 Telnet SUPDUP option. M.R. Crispin. October 1977. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0736) 0737 FTP extension: XSEN. K. Harrenstien. October 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0737) 0738 Time server. K. Harrenstien. October 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0738) 0739 Assigned numbers. J. Postel. November 1977. (Format: TXT, HTML) (Obsoletes RFC0604, RFC0503) (Obsoleted by RFC0750) (Status: HISTORIC) (DOI: 10.17487/RFC0739) 0740 NETRJS Protocol. R.T. Braden. November 1977. (Format: TXT, HTML) (Obsoletes RFC0599) (Status: HISTORIC) (DOI: 10.17487/RFC0740) 0741 Specifications for the Network Voice Protocol (NVP). D. Cohen. November 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0741) 0742 NAME/FINGER Protocol. K. Harrenstien. December 1977. (Format: TXT, HTML) (Obsoleted by RFC1288, RFC1196, RFC1194) (Status: UNKNOWN) (DOI: 10.17487/RFC0742) 0743 FTP extension: XRSQ/XRCP. K. Harrenstien. December 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0743) 0744 MARS - a Message Archiving and Retrieval Service. J. Sattley. January 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0744) 0745 JANUS interface specifications. M. Beeler. March 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0745) 0746 SUPDUP graphics extension. R. Stallman. March 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0746) 0747 Recent extensions to the SUPDUP Protocol. M.R. Crispin. March 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0747) 0748 Telnet randomly-lose option. M.R. Crispin. 1 April 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0748) 0749 Telnet SUPDUP-Output option. B. Greenberg. September 1978. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0749) 0750 Assigned numbers. J. Postel. September 1978. (Format: TXT, HTML) (Obsoletes RFC0739) (Obsoleted by RFC0755) (Status: HISTORIC) (DOI: 10.17487/RFC0750) 0751 Survey of FTP mail and MLFL. P.D. Lebling. December 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0751) 0752 Universal host table. M.R. Crispin. January 1979. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0752) 0753 Internet Message Protocol. J. Postel. March 1979. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0753) 0754 Out-of-net host addresses for mail. J. Postel. April 1979. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0754) 0755 Assigned numbers. J. Postel. May 1979. (Format: TXT, HTML) (Obsoletes RFC0750) (Obsoleted by RFC0758) (Status: HISTORIC) (DOI: 10.17487/RFC0755) 0756 NIC name server - a datagram-based information utility. J.R. Pickens, E.J. Feinler, J.E. Mathis. July 1979. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0756) 0757 Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems. D.P. Deutsch. September 1979. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0757) 0758 Assigned numbers. J. Postel. August 1979. (Format: TXT, HTML) (Obsoletes RFC0755) (Obsoleted by RFC0762) (Status: HISTORIC) (DOI: 10.17487/RFC0758) 0759 Internet Message Protocol. J. Postel. August 1980. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0759) 0760 DoD standard Internet Protocol. J. Postel. January 1980. (Format: TXT, HTML) (Obsoletes IEN123) (Obsoleted by RFC0791) (Updated by RFC0777) (Status: UNKNOWN) (DOI: 10.17487/RFC0760) 0761 DoD standard Transmission Control Protocol. J. Postel. January 1980. (Format: TXT, HTML) (Obsoleted by RFC0793, RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0761) 0762 Assigned numbers. J. Postel. January 1980. (Format: TXT, HTML) (Obsoletes RFC0758) (Obsoleted by RFC0770) (Status: HISTORIC) (DOI: 10.17487/RFC0762) 0763 Role mailboxes. M.D. Abrams. May 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0763) 0764 Telnet Protocol specification. J. Postel. June 1980. (Format: TXT, HTML) (Obsoleted by RFC0854) (Status: UNKNOWN) (DOI: 10.17487/RFC0764) 0765 File Transfer Protocol specification. J. Postel. June 1980. (Format: TXT, HTML) (Obsoletes RFC0542) (Obsoleted by RFC0959) (Status: UNKNOWN) (DOI: 10.17487/RFC0765) 0766 Internet Protocol Handbook: Table of contents. J. Postel. July 1980. (Format: TXT, HTML) (Obsoleted by RFC0774) (Status: UNKNOWN) (DOI: 10.17487/RFC0766) 0767 Structured format for transmission of multi-media documents. J. Postel. August 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0767) 0768 User Datagram Protocol. J. Postel. August 1980. (Format: TXT, HTML) (Also STD0006) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0768) 0769 Rapicom 450 facsimile file format. J. Postel. September 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0769) 0770 Assigned numbers. J. Postel. September 1980. (Format: TXT, HTML) (Obsoletes RFC0762) (Obsoleted by RFC0776) (Status: HISTORIC) (DOI: 10.17487/RFC0770) 0771 Mail transition plan. V.G. Cerf, J. Postel. September 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0771) 0772 Mail Transfer Protocol. S. Sluizer, J. Postel. September 1980. (Format: TXT, HTML) (Obsoleted by RFC0780) (Status: UNKNOWN) (DOI: 10.17487/RFC0772) 0773 Comments on NCP/TCP mail service transition strategy. V.G. Cerf. October 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0773) 0774 Internet Protocol Handbook: Table of contents. J. Postel. October 1980. (Format: TXT, HTML) (Obsoletes RFC0766) (Status: UNKNOWN) (DOI: 10.17487/RFC0774) 0775 Directory oriented FTP commands. D. Mankins, D. Franklin, A.D. Owen. December 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0775) 0776 Assigned numbers. J. Postel. January 1981. (Format: TXT, HTML) (Obsoletes RFC0770) (Obsoleted by RFC0790) (Status: HISTORIC) (DOI: 10.17487/RFC0776) 0777 Internet Control Message Protocol. J. Postel. April 1981. (Format: TXT, HTML) (Obsoleted by RFC0792) (Updates RFC0760) (Status: UNKNOWN) (DOI: 10.17487/RFC0777) 0778 DCNET Internet Clock Service. D.L. Mills. April 1981. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0778) 0779 Telnet send-location option. E. Killian. April 1981. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0779) 0780 Mail Transfer Protocol. S. Sluizer, J. Postel. May 1981. (Format: TXT, HTML) (Obsoletes RFC0772) (Obsoleted by RFC0788) (Status: UNKNOWN) (DOI: 10.17487/RFC0780) 0781 Specification of the Internet Protocol (IP) timestamp option. Z. Su. May 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0781) 0782 Virtual Terminal management model. J. Nabielsky, A.P. Skelton. January 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0782) 0783 TFTP Protocol (revision 2). K.R. Sollins. June 1981. (Format: TXT, HTML) (Obsoletes IEN133) (Obsoleted by RFC1350) (Status: UNKNOWN) (DOI: 10.17487/RFC0783) 0784 Mail Transfer Protocol: ISI TOPS20 implementation. S. Sluizer, J. Postel. July 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0784) 0785 Mail Transfer Protocol: ISI TOPS20 file definitions. S. Sluizer, J. Postel. July 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0785) 0786 Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL interface. S. Sluizer, J. Postel. July 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0786) 0787 Connectionless data transmission survey/tutorial. A.L. Chapin. July 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0787) 0788 Simple Mail Transfer Protocol. J. Postel. November 1981. (Format: TXT, HTML) (Obsoletes RFC0780) (Obsoleted by RFC0821) (Status: UNKNOWN) (DOI: 10.17487/RFC0788) 0789 Vulnerabilities of network control protocols: An example. E.C. Rosen. July 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0789) 0790 Assigned numbers. J. Postel. September 1981. (Format: TXT, HTML) (Obsoletes RFC0776) (Obsoleted by RFC0820) (Status: HISTORIC) (DOI: 10.17487/RFC0790) 0791 Internet Protocol. J. Postel. September 1981. (Format: TXT, HTML) (Obsoletes RFC0760) (Updated by RFC1349, RFC2474, RFC6864) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0791) 0792 Internet Control Message Protocol. J. Postel. September 1981. (Format: TXT, HTML) (Obsoletes RFC0777) (Updated by RFC0950, RFC4884, RFC6633, RFC6918) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0792) 0793 Transmission Control Protocol. J. Postel. September 1981. (Format: TXT, HTML) (Obsoletes RFC0761) (Obsoleted by RFC9293) (Updated by RFC1122, RFC3168, RFC6093, RFC6528) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0793) 0794 Pre-emption. V.G. Cerf. September 1981. (Format: TXT, HTML) (Updates IEN125) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0794) 0795 Service mappings. J. Postel. September 1981. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0795) 0796 Address mappings. J. Postel. September 1981. (Format: TXT, HTML) (Obsoletes IEN115) (Status: HISTORIC) (DOI: 10.17487/RFC0796) 0797 Format for Bitmap files. A.R. Katz. September 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0797) 0798 Decoding facsimile data from the Rapicom 450. A.R. Katz. September 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0798) 0799 Internet name domains. D.L. Mills. September 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0799) 0800 Request For Comments summary notes: 700-799. J. Postel, J. Vernon. November 1982. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0800) 0801 NCP/TCP transition plan. J. Postel. November 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0801) 0802 ARPANET 1822L Host Access Protocol. A.G. Malis. November 1981. (Format: TXT, HTML) (Obsoleted by RFC0851) (Status: UNKNOWN) (DOI: 10.17487/RFC0802) 0803 Dacom 450/500 facsimile data transcoding. A. Agarwal, M.J. O'Connor, D.L. Mills. November 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0803) 0804 CCITT draft recommendation T.4. International Telegraph and Telephone Consultative Committee of the International Telecommunication Union. January 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0804) 0805 Computer mail meeting notes. J. Postel. February 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0805) 0806 Proposed Federal Information Processing Standard: Specification for message format for computer based message systems. National Bureau of Standards. September 1981. (Format: TXT, HTML) (Obsoleted by RFC0841) (Status: UNKNOWN) (DOI: 10.17487/RFC0806) 0807 Multimedia mail meeting notes. J. Postel. February 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0807) 0808 Summary of computer mail services meeting held at BBN on 10 January 1979. J. Postel. March 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0808) 0809 UCL facsimile system. T. Chang. February 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0809) 0810 DoD Internet host table specification. E.J. Feinler, K. Harrenstien, Z. Su, V. White. March 1982. (Format: TXT, HTML) (Obsoletes RFC0608) (Obsoleted by RFC0952) (Status: UNKNOWN) (DOI: 10.17487/RFC0810) 0811 Hostnames Server. K. Harrenstien, V. White, E.J. Feinler. March 1982. (Format: TXT, HTML) (Obsoleted by RFC0953) (Status: UNKNOWN) (DOI: 10.17487/RFC0811) 0812 NICNAME/WHOIS. K. Harrenstien, V. White. March 1982. (Format: TXT, HTML) (Obsoleted by RFC0954, RFC3912) (Status: UNKNOWN) (DOI: 10.17487/RFC0812) 0813 Window and Acknowledgement Strategy in TCP. D.D. Clark. July 1982. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0813) 0814 Name, addresses, ports, and routes. D.D. Clark. July 1982. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0814) 0815 IP datagram reassembly algorithms. D.D. Clark. July 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0815) 0816 Fault isolation and recovery. D.D. Clark. July 1982. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0816) 0817 Modularity and efficiency in protocol implementation. D.D. Clark. July 1982. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0817) 0818 Remote User Telnet service. J. Postel. November 1982. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0818) 0819 The Domain Naming Convention for Internet User Applications. Z. Su, J. Postel. August 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0819) 0820 Assigned numbers. J. Postel. August 1982. (Format: TXT, HTML) (Obsoletes RFC0790) (Obsoleted by RFC0870) (Status: HISTORIC) (DOI: 10.17487/RFC0820) 0821 Simple Mail Transfer Protocol. J. Postel. August 1982. (Format: TXT, HTML) (Obsoletes RFC0788) (Obsoleted by RFC2821) (Also STD0010) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0821) 0822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES. D. Crocker. August 1982. (Format: TXT, HTML) (Obsoletes RFC0733) (Obsoleted by RFC2822) (Updated by RFC1123, RFC2156, RFC1327, RFC1138, RFC1148) (Also STD0011) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0822) 0823 DARPA Internet gateway. R.M. Hinden, A. Sheltzer. September 1982. (Format: TXT, HTML) (Updates IEN109, IEN30) (Status: HISTORIC) (DOI: 10.17487/RFC0823) 0824 CRONUS Virtual Local Network. W.I. MacGregor, D.C. Tappan. August 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0824) 0825 Request for comments on Requests For Comments. J. Postel. November 1982. (Format: TXT, HTML) (Obsoleted by RFC1111, RFC1543, RFC2223) (Status: UNKNOWN) (DOI: 10.17487/RFC0825) 0826 An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware. D. Plummer. November 1982. (Format: TXT, HTML) (Updated by RFC5227, RFC5494) (Also STD0037) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0826) 0827 Exterior Gateway Protocol (EGP). E.C. Rosen. October 1982. (Format: TXT, HTML) (Updated by RFC0904) (Status: UNKNOWN) (DOI: 10.17487/RFC0827) 0828 Data communications: IFIP's international "network" of experts. K. Owen. August 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0828) 0829 Packet satellite technology reference sources. V.G. Cerf. November 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0829) 0830 Distributed system for Internet name service. Z. Su. October 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0830) 0831 Backup access to the European side of SATNET. R.T. Braden. December 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0831) 0832 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT, HTML) (Obsoleted by RFC0833) (Status: UNKNOWN) (DOI: 10.17487/RFC0832) 0833 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT, HTML) (Obsoletes RFC0832) (Obsoleted by RFC0834) (Status: UNKNOWN) (DOI: 10.17487/RFC0833) 0834 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT, HTML) (Obsoletes RFC0833) (Obsoleted by RFC0835) (Status: UNKNOWN) (DOI: 10.17487/RFC0834) 0835 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT, HTML) (Obsoletes RFC0834) (Obsoleted by RFC0836) (Status: UNKNOWN) (DOI: 10.17487/RFC0835) 0836 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT, HTML) (Obsoletes RFC0835) (Obsoleted by RFC0837) (Status: UNKNOWN) (DOI: 10.17487/RFC0836) 0837 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT, HTML) (Obsoletes RFC0836) (Obsoleted by RFC0838) (Status: UNKNOWN) (DOI: 10.17487/RFC0837) 0838 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT, HTML) (Obsoletes RFC0837) (Obsoleted by RFC0839) (Status: UNKNOWN) (DOI: 10.17487/RFC0838) 0839 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT, HTML) (Obsoletes RFC0838) (Obsoleted by RFC0842) (Status: UNKNOWN) (DOI: 10.17487/RFC0839) 0840 Official protocols. J. Postel. April 1983. (Format: TXT, HTML) (Obsoleted by RFC0880) (Status: HISTORIC) (DOI: 10.17487/RFC0840) 0841 Specification for message format for Computer Based Message Systems. National Bureau of Standards. January 1983. (Format: TXT, HTML) (Obsoletes RFC0806) (Status: UNKNOWN) (DOI: 10.17487/RFC0841) 0842 Who talks TCP? - survey of 1 February 83. D. Smallberg. February 1983. (Format: TXT, HTML) (Obsoletes RFC0839) (Obsoleted by RFC0843) (Status: UNKNOWN) (DOI: 10.17487/RFC0842) 0843 Who talks TCP? - survey of 8 February 83. D. Smallberg. February 1983. (Format: TXT, HTML) (Obsoletes RFC0842) (Obsoleted by RFC0845) (Updated by RFC0844) (Status: UNKNOWN) (DOI: 10.17487/RFC0843) 0844 Who talks ICMP, too? - Survey of 18 February 1983. R. Clements. February 1983. (Format: TXT, HTML) (Updates RFC0843) (Status: UNKNOWN) (DOI: 10.17487/RFC0844) 0845 Who talks TCP? - survey of 15 February 1983. D. Smallberg. February 1983. (Format: TXT, HTML) (Obsoletes RFC0843) (Obsoleted by RFC0846) (Status: UNKNOWN) (DOI: 10.17487/RFC0845) 0846 Who talks TCP? - survey of 22 February 1983. D. Smallberg. February 1983. (Format: TXT, HTML) (Obsoletes RFC0845) (Obsoleted by RFC0847) (Status: UNKNOWN) (DOI: 10.17487/RFC0846) 0847 Summary of Smallberg surveys. A. Westine, D. Smallberg, J. Postel. February 1983. (Format: TXT, HTML) (Obsoletes RFC0846) (Status: UNKNOWN) (DOI: 10.17487/RFC0847) 0848 Who provides the "little" TCP services?. D. Smallberg. March 1983. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0848) 0849 Suggestions for improved host table distribution. M.R. Crispin. May 1983. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0849) 0850 Standard for interchange of USENET messages. M.R. Horton. June 1983. (Format: TXT, HTML) (Obsoleted by RFC1036) (Status: UNKNOWN) (DOI: 10.17487/RFC0850) 0851 ARPANET 1822L Host Access Protocol. A.G. Malis. April 1983. (Format: TXT, HTML) (Obsoletes RFC0802) (Obsoleted by RFC0878) (Status: UNKNOWN) (DOI: 10.17487/RFC0851) 0852 ARPANET short blocking feature. A.G. Malis. April 1983. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0852) 0853 Not Issued. 0854 Telnet Protocol Specification. J. Postel, J.K. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes RFC0764) (Updated by RFC5198) (Also STD0008) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0854) 0855 Telnet Option Specifications. J. Postel, J.K. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes NIC18640) (Also STD0008) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0855) 0856 Telnet Binary Transmission. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes NIC15389) (Also STD0027) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0856) 0857 Telnet Echo Option. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes NIC15390) (Also STD0028) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0857) 0858 Telnet Suppress Go Ahead Option. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes NIC15392) (Also STD0029) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0858) 0859 Telnet Status Option. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes RFC0651) (Also STD0030) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0859) 0860 Telnet Timing Mark Option. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes NIC16238) (Also STD0031) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0860) 0861 Telnet Extended Options: List Option. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes NIC16239) (Also STD0032) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0861) 0862 Echo Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0020) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0862) 0863 Discard Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0021) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0863) 0864 Character Generator Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0022) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0864) 0865 Quote of the Day Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0023) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0865) 0866 Active users. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0024) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0866) 0867 Daytime Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0025) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0867) 0868 Time Protocol. J. Postel, K. Harrenstien. May 1983. (Format: TXT, HTML) (Also STD0026) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0868) 0869 Host Monitoring Protocol. R. Hinden. December 1983. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0869) 0870 Assigned numbers. J.K. Reynolds, J. Postel. October 1983. (Format: TXT, HTML) (Obsoletes RFC0820) (Obsoleted by RFC0900) (Status: HISTORIC) (DOI: 10.17487/RFC0870) 0871 Perspective on the ARPANET reference model. M.A. Padlipsky. September 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0871) 0872 TCP-on-a-LAN. M.A. Padlipsky. September 1982. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0872) 0873 Illusion of vendor support. M.A. Padlipsky. September 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0873) 0874 Critique of X.25. M.A. Padlipsky. September 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0874) 0875 Gateways, architectures, and heffalumps. M.A. Padlipsky. September 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0875) 0876 Survey of SMTP implementations. D. Smallberg. September 1983. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0876) 0877 Standard for the transmission of IP datagrams over public data networks. J.T. Korb. September 1983. (Format: TXT, HTML) (Obsoleted by RFC1356) (Status: UNKNOWN) (DOI: 10.17487/RFC0877) 0878 ARPANET 1822L Host Access Protocol. A.G. Malis. December 1983. (Format: TXT, HTML) (Obsoletes RFC0851) (Status: UNKNOWN) (DOI: 10.17487/RFC0878) 0879 The TCP Maximum Segment Size and Related Topics. J. Postel. November 1983. (Format: TXT, HTML) (Obsoleted by RFC7805, RFC9293) (Updated by RFC6691) (Status: HISTORIC) (DOI: 10.17487/RFC0879) 0880 Official protocols. J.K. Reynolds, J. Postel. October 1983. (Format: TXT, HTML) (Obsoletes RFC0840) (Obsoleted by RFC0901) (Status: HISTORIC) (DOI: 10.17487/RFC0880) 0881 Domain names plan and schedule. J. Postel. November 1983. (Format: TXT, HTML) (Updated by RFC0897) (Status: UNKNOWN) (DOI: 10.17487/RFC0881) 0882 Domain names: Concepts and facilities. P. Mockapetris. November 1983. (Format: TXT, HTML) (Obsoleted by RFC1034, RFC1035) (Updated by RFC0973) (Status: UNKNOWN) (DOI: 10.17487/RFC0882) 0883 Domain names: Implementation specification. P. Mockapetris. November 1983. (Format: TXT, HTML) (Obsoleted by RFC1034, RFC1035) (Updated by RFC0973) (Status: UNKNOWN) (DOI: 10.17487/RFC0883) 0884 Telnet terminal type option. M. Solomon, E. Wimmers. December 1983. (Format: TXT, HTML) (Obsoleted by RFC0930) (Status: UNKNOWN) (DOI: 10.17487/RFC0884) 0885 Telnet end of record option. J. Postel. December 1983. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0885) 0886 Proposed standard for message header munging. M.T. Rose. December 1983. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0886) 0887 Resource Location Protocol. M. Accetta. December 1983. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0887) 0888 "STUB" Exterior Gateway Protocol. L. Seamonson, E.C. Rosen. January 1984. (Format: TXT, HTML) (Updated by RFC0904) (Status: UNKNOWN) (DOI: 10.17487/RFC0888) 0889 Internet Delay Experiments. D.L. Mills. December 1983. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0889) 0890 Exterior Gateway Protocol implementation schedule. J. Postel. February 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0890) 0891 DCN Local-Network Protocols. D.L. Mills. December 1983. (Format: TXT, HTML) (Also STD0044) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0891) 0892 ISO Transport Protocol specification. International Organization for Standardization. December 1983. (Format: TXT, HTML) (Obsoleted by RFC0905) (Status: UNKNOWN) (DOI: 10.17487/RFC0892) 0893 Trailer encapsulations. S. Leffler, M.J. Karels. April 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0893) 0894 A Standard for the Transmission of IP Datagrams over Ethernet Networks. C. Hornig. April 1984. (Format: TXT, HTML) (Also STD0041) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0894) 0895 Standard for the transmission of IP datagrams over experimental Ethernet networks. J. Postel. April 1984. (Format: TXT, HTML) (Also STD0042) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0895) 0896 Congestion Control in IP/TCP Internetworks. J. Nagle. January 1984. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0896) 0897 Domain name system implementation schedule. J. Postel. February 1984. (Format: TXT, HTML) (Updates RFC0881) (Updated by RFC0921) (Status: UNKNOWN) (DOI: 10.17487/RFC0897) 0898 Gateway special interest group meeting notes. R.M. Hinden, J. Postel, M. Muuss, J.K. Reynolds. April 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0898) 0899 Request For Comments summary notes: 800-899. J. Postel, A. Westine. May 1984. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0899) 0900 Assigned Numbers. J.K. Reynolds, J. Postel. June 1984. (Format: TXT, HTML) (Obsoletes RFC0870) (Obsoleted by RFC0923) (Status: HISTORIC) (DOI: 10.17487/RFC0900) 0901 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. June 1984. (Format: TXT, HTML) (Obsoletes RFC0880) (Obsoleted by RFC0924) (Status: UNKNOWN) (DOI: 10.17487/RFC0901) 0902 ARPA Internet Protocol policy. J.K. Reynolds, J. Postel. July 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0902) 0903 A Reverse Address Resolution Protocol. R. Finlayson, T. Mann, J.C. Mogul, M. Theimer. June 1984. (Format: TXT, HTML) (Also STD0038) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0903) 0904 Exterior Gateway Protocol formal specification. D.L. Mills. April 1984. (Format: TXT, HTML) (Updates RFC0827, RFC0888) (Status: HISTORIC) (DOI: 10.17487/RFC0904) 0905 ISO Transport Protocol specification ISO DP 8073. ISO. April 1984. (Format: TXT, HTML) (Obsoletes RFC0892) (Status: UNKNOWN) (DOI: 10.17487/RFC0905) 0906 Bootstrap loading using TFTP. R. Finlayson. June 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0906) 0907 Host Access Protocol specification. Bolt Beranek and Newman Laboratories. July 1984. (Format: TXT, HTML) (Updated by RFC1221) (Also STD0040) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0907) 0908 Reliable Data Protocol. D. Velten, R.M. Hinden, J. Sax. July 1984. (Format: TXT, HTML) (Updated by RFC1151) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0908) 0909 Loader Debugger Protocol. C. Welles, W. Milliken. July 1984. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0909) 0910 Multimedia mail meeting notes. H.C. Forsdick. August 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0910) 0911 EGP Gateway under Berkeley UNIX 4.2. P. Kirton. August 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0911) 0912 Authentication service. M. St. Johns. September 1984. (Format: TXT, HTML) (Obsoleted by RFC0931) (Status: UNKNOWN) (DOI: 10.17487/RFC0912) 0913 Simple File Transfer Protocol. M. Lottor. September 1984. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0913) 0914 Thinwire protocol for connecting personal computers to the Internet. D.J. Farber, G. Delp, T.M. Conte. September 1984. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0914) 0915 Network mail path service. M.A. Elvy, R. Nedved. December 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0915) 0916 Reliable Asynchronous Transfer Protocol (RATP). G.G. Finn. October 1984. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0916) 0917 Internet subnets. J.C. Mogul. October 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0917) 0918 Post Office Protocol. J.K. Reynolds. October 1984. (Format: TXT, HTML) (Obsoleted by RFC0937) (Status: UNKNOWN) (DOI: 10.17487/RFC0918) 0919 Broadcasting Internet Datagrams. J.C. Mogul. October 1984. (Format: TXT, HTML) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0919) 0920 Domain requirements. J. Postel, J.K. Reynolds. October 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0920) 0921 Domain name system implementation schedule - revised. J. Postel. October 1984. (Format: TXT, HTML) (Updates RFC0897) (Status: UNKNOWN) (DOI: 10.17487/RFC0921) 0922 Broadcasting Internet datagrams in the presence of subnets. J.C. Mogul. October 1984. (Format: TXT, HTML) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0922) 0923 Assigned numbers. J.K. Reynolds, J. Postel. October 1984. (Format: TXT, HTML) (Obsoletes RFC0900) (Obsoleted by RFC0943) (Status: HISTORIC) (DOI: 10.17487/RFC0923) 0924 Official ARPA-Internet protocols for connecting personal computers to the Internet. J.K. Reynolds, J. Postel. October 1984. (Format: TXT, HTML) (Obsoletes RFC0901) (Obsoleted by RFC0944) (Status: UNKNOWN) (DOI: 10.17487/RFC0924) 0925 Multi-LAN address resolution. J. Postel. October 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0925) 0926 Protocol for providing the connectionless mode network services. International Organization for Standardization. December 1984. (Format: TXT, HTML) (Obsoleted by RFC0994) (Status: UNKNOWN) (DOI: 10.17487/RFC0926) 0927 TACACS user identification Telnet option. B.A. Anderson. December 1984. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0927) 0928 Introduction to proposed DoD standard H-FP. M.A. Padlipsky. December 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0928) 0929 Proposed Host-Front End Protocol. J. Lilienkamp, R. Mandell, M.A. Padlipsky. December 1984. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0929) 0930 Telnet terminal type option. M. Solomon, E. Wimmers. January 1985. (Format: TXT, HTML) (Obsoletes RFC0884) (Obsoleted by RFC1091) (Status: UNKNOWN) (DOI: 10.17487/RFC0930) 0931 Authentication server. M. St. Johns. January 1985. (Format: TXT, HTML) (Obsoletes RFC0912) (Obsoleted by RFC1413) (Status: UNKNOWN) (DOI: 10.17487/RFC0931) 0932 Subnetwork addressing scheme. D.D. Clark. January 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0932) 0933 Output marking Telnet option. S. Silverman. January 1985. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0933) 0934 Proposed standard for message encapsulation. M.T. Rose, E.A. Stefferud. January 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0934) 0935 Reliable link layer protocols. J.G. Robinson. January 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0935) 0936 Another Internet subnet addressing scheme. M.J. Karels. February 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0936) 0937 Post Office Protocol: Version 2. M. Butler, J. Postel, D. Chase, J. Goldberger, J.K. Reynolds. February 1985. (Format: TXT, HTML) (Obsoletes RFC0918) (Status: HISTORIC) (DOI: 10.17487/RFC0937) 0938 Internet Reliable Transaction Protocol functional and interface specification. T. Miller. February 1985. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0938) 0939 Executive summary of the NRC report on transport protocols for Department of Defense data networks. National Research Council. February 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0939) 0940 Toward an Internet standard scheme for subnetting. Gateway Algorithms and Data Structures Task Force. April 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0940) 0941 Addendum to the network service definition covering network layer addressing. International Organization for Standardization. April 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0941) 0942 Transport protocols for Department of Defense data networks. National Research Council. February 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0942) 0943 Assigned numbers. J.K. Reynolds, J. Postel. April 1985. (Format: TXT, HTML) (Obsoletes RFC0923) (Obsoleted by RFC0960) (Status: HISTORIC) (DOI: 10.17487/RFC0943) 0944 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. April 1985. (Format: TXT, HTML) (Obsoletes RFC0924) (Obsoleted by RFC0961) (Status: UNKNOWN) (DOI: 10.17487/RFC0944) 0945 DoD statement on the NRC report. J. Postel. May 1985. (Format: TXT, HTML) (Obsoleted by RFC1039) (Status: UNKNOWN) (DOI: 10.17487/RFC0945) 0946 Telnet terminal location number option. R. Nedved. May 1985. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0946) 0947 Multi-network broadcasting within the Internet. K. Lebowitz, D. Mankins. June 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0947) 0948 Two methods for the transmission of IP datagrams over IEEE 802.3 networks. I. Winston. June 1985. (Format: TXT, HTML) (Obsoleted by RFC1042) (Status: UNKNOWN) (DOI: 10.17487/RFC0948) 0949 FTP unique-named store command. M.A. Padlipsky. July 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0949) 0950 Internet Standard Subnetting Procedure. J.C. Mogul, J. Postel. August 1985. (Format: TXT, HTML) (Updates RFC0792) (Updated by RFC6918) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0950) 0951 Bootstrap Protocol. W.J. Croft, J. Gilmore. September 1985. (Format: TXT, HTML) (Updated by RFC1395, RFC1497, RFC1532, RFC1542, RFC5494) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC0951) 0952 DoD Internet host table specification. K. Harrenstien, M.K. Stahl, E.J. Feinler. October 1985. (Format: TXT, HTML) (Obsoletes RFC0810) (Updated by RFC1123) (Status: UNKNOWN) (DOI: 10.17487/RFC0952) 0953 Hostname Server. K. Harrenstien, M.K. Stahl, E.J. Feinler. October 1985. (Format: TXT, HTML) (Obsoletes RFC0811) (Status: HISTORIC) (DOI: 10.17487/RFC0953) 0954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. October 1985. (Format: TXT, HTML) (Obsoletes RFC0812) (Obsoleted by RFC3912) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC0954) 0955 Towards a transport service for transaction processing applications. R.T. Braden. September 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0955) 0956 Algorithms for synchronizing network clocks. D.L. Mills. September 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0956) 0957 Experiments in network clock synchronization. D.L. Mills. September 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0957) 0958 Network Time Protocol (NTP). D.L. Mills. September 1985. (Format: TXT, HTML) (Obsoleted by RFC1059, RFC1119, RFC1305) (Status: UNKNOWN) (DOI: 10.17487/RFC0958) 0959 File Transfer Protocol. J. Postel, J. Reynolds. October 1985. (Format: TXT, HTML) (Obsoletes RFC0765) (Updated by RFC2228, RFC2640, RFC2773, RFC3659, RFC5797, RFC7151) (Also STD0009) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0959) 0960 Assigned numbers. J.K. Reynolds, J. Postel. December 1985. (Format: TXT, HTML) (Obsoletes RFC0943) (Obsoleted by RFC0990) (Status: HISTORIC) (DOI: 10.17487/RFC0960) 0961 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. December 1985. (Format: TXT, HTML) (Obsoletes RFC0944) (Obsoleted by RFC0991) (Status: UNKNOWN) (DOI: 10.17487/RFC0961) 0962 TCP-4 prime. M.A. Padlipsky. November 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0962) 0963 Some problems with the specification of the Military Standard Internet Protocol. D.P. Sidhu. November 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0963) 0964 Some problems with the specification of the Military Standard Transmission Control Protocol. D.P. Sidhu, T. Blumer. November 1985. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0964) 0965 Format for a graphical communication protocol. L. Aguilar. December 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0965) 0966 Host groups: A multicast extension to the Internet Protocol. S.E. Deering, D.R. Cheriton. December 1985. (Format: TXT, HTML) (Obsoleted by RFC0988) (Status: UNKNOWN) (DOI: 10.17487/RFC0966) 0967 All victims together. M.A. Padlipsky. December 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0967) 0968 Twas the night before start-up. V.G. Cerf. December 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0968) 0969 NETBLT: A bulk data transfer protocol. D.D. Clark, M.L. Lambert, L. Zhang. December 1985. (Format: TXT, HTML) (Obsoleted by RFC0998) (Status: UNKNOWN) (DOI: 10.17487/RFC0969) 0970 On Packet Switches With Infinite Storage. J. Nagle. December 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0970) 0971 Survey of data representation standards. A.L. DeSchon. January 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0971) 0972 Password Generator Protocol. F.J. Wancho. January 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0972) 0973 Domain system changes and observations. P. Mockapetris. January 1986. (Format: TXT, HTML) (Obsoleted by RFC1034, RFC1035) (Updates RFC0882, RFC0883) (Status: UNKNOWN) (DOI: 10.17487/RFC0973) 0974 Mail routing and the domain system. C. Partridge. January 1986. (Format: TXT, HTML) (Obsoleted by RFC2821) (Also STD0010) (Status: HISTORIC) (DOI: 10.17487/RFC0974) 0975 Autonomous confederations. D.L. Mills. February 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0975) 0976 UUCP mail interchange format standard. M.R. Horton. February 1986. (Format: TXT, HTML) (Updated by RFC1137) (Status: UNKNOWN) (DOI: 10.17487/RFC0976) 0977 Network News Transfer Protocol. B. Kantor, P. Lapsley. February 1986. (Format: TXT, HTML) (Obsoleted by RFC3977) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0977) 0978 Voice File Interchange Protocol (VFIP). J.K. Reynolds, R. Gillman, W.A. Brackenridge, A. Witkowski, J. Postel. February 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0978) 0979 PSN End-to-End functional specification. A.G. Malis. March 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0979) 0980 Protocol document order information. O.J. Jacobsen, J. Postel. March 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0980) 0981 Experimental multiple-path routing algorithm. D.L. Mills. March 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0981) 0982 Guidelines for the specification of the structure of the Domain Specific Part (DSP) of the ISO standard NSAP address. H.W. Braun. April 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0982) 0983 ISO transport arrives on top of the TCP. D.E. Cass, M.T. Rose. April 1986. (Format: TXT, HTML) (Obsoleted by RFC1006) (Status: UNKNOWN) (DOI: 10.17487/RFC0983) 0984 PCMAIL: A distributed mail system for personal computers. D.D. Clark, M.L. Lambert. May 1986. (Format: TXT, HTML) (Obsoleted by RFC0993) (Status: UNKNOWN) (DOI: 10.17487/RFC0984) 0985 Requirements for Internet gateways - draft. National Science Foundation, Network Technical Advisory Group. May 1986. (Format: TXT, HTML) (Obsoleted by RFC1009) (Status: UNKNOWN) (DOI: 10.17487/RFC0985) 0986 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol. R. Callon, H.W. Braun. June 1986. (Format: TXT, HTML) (Obsoleted by RFC1069) (Status: UNKNOWN) (DOI: 10.17487/RFC0986) 0987 Mapping between X.400 and RFC 822. S.E. Kille. June 1986. (Format: TXT, HTML) (Obsoleted by RFC2156, RFC1327) (Updated by RFC1026, RFC1138, RFC1148) (Status: UNKNOWN) (DOI: 10.17487/RFC0987) 0988 Host extensions for IP multicasting. S.E. Deering. July 1986. (Format: TXT, HTML) (Obsoletes RFC0966) (Obsoleted by RFC1054, RFC1112) (Status: UNKNOWN) (DOI: 10.17487/RFC0988) 0989 Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures. J. Linn. February 1987. (Format: TXT, HTML) (Obsoleted by RFC1040, RFC1113) (Status: UNKNOWN) (DOI: 10.17487/RFC0989) 0990 Assigned numbers. J.K. Reynolds, J. Postel. November 1986. (Format: TXT, HTML) (Obsoletes RFC0960) (Obsoleted by RFC1010) (Updated by RFC0997) (Status: HISTORIC) (DOI: 10.17487/RFC0990) 0991 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. November 1986. (Format: TXT, HTML) (Obsoletes RFC0961) (Obsoleted by RFC1011) (Status: UNKNOWN) (DOI: 10.17487/RFC0991) 0992 On communication support for fault tolerant process groups. K.P. Birman, T.A. Joseph. November 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0992) 0993 PCMAIL: A distributed mail system for personal computers. D.D. Clark, M.L. Lambert. December 1986. (Format: TXT, HTML) (Obsoletes RFC0984) (Obsoleted by RFC1056) (Status: UNKNOWN) (DOI: 10.17487/RFC0993) 0994 Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service. International Organization for Standardization. March 1986. (Format: TXT, HTML) (Obsoletes RFC0926) (Status: UNKNOWN) (DOI: 10.17487/RFC0994) 0995 End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473. International Organization for Standardization. April 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0995) 0996 Statistics server. D.L. Mills. February 1987. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0996) 0997 Internet numbers. J.K. Reynolds, J. Postel. March 1987. (Format: TXT, HTML) (Obsoleted by RFC1020, RFC1117) (Updates RFC0990) (Status: UNKNOWN) (DOI: 10.17487/RFC0997) 0998 NETBLT: A bulk data transfer protocol. D.D. Clark, M.L. Lambert, L. Zhang. March 1987. (Format: TXT, HTML) (Obsoletes RFC0969) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0998) 0999 Requests For Comments summary notes: 900-999. A. Westine, J. Postel. April 1987. (Format: TXT, HTML) (Obsoletes RFC0160) (Obsoleted by RFC1000) (Status: UNKNOWN) (DOI: 10.17487/RFC0999) 1000 Request For Comments reference guide. J.K. Reynolds, J. Postel. August 1987. (Format: TXT, HTML) (Obsoletes RFC0999) (Status: UNKNOWN) (DOI: 10.17487/RFC1000) 1001 Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods. NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, End-to-End Services Task Force. March 1987. (Format: TXT, HTML) (Also STD0019) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1001) 1002 Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications. NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, End-to-End Services Task Force. March 1987. (Format: TXT, HTML) (Also STD0019) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1002) 1003 Issues in defining an equations representation standard. A.R. Katz. March 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1003) 1004 Distributed-protocol authentication scheme. D.L. Mills. April 1987. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1004) 1005 ARPANET AHIP-E Host Access Protocol (enhanced AHIP). A. Khanna, A.G. Malis. May 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1005) 1006 ISO Transport Service on top of the TCP Version: 3. M.T. Rose, D.E. Cass. May 1987. (Format: TXT, HTML) (Obsoletes RFC0983) (Updated by RFC2126) (Also STD0035) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1006) 1007 Military supplement to the ISO Transport Protocol. W. McCoy. June 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1007) 1008 Implementation guide for the ISO Transport Protocol. W. McCoy. June 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1008) 1009 Requirements for Internet gateways. R.T. Braden, J. Postel. June 1987. (Format: TXT, HTML) (Obsoletes RFC0985) (Obsoleted by RFC1812) (Status: HISTORIC) (DOI: 10.17487/RFC1009) 1010 Assigned numbers. J.K. Reynolds, J. Postel. May 1987. (Format: TXT, HTML) (Obsoletes RFC0990) (Obsoleted by RFC1060) (Status: HISTORIC) (DOI: 10.17487/RFC1010) 1011 Official Internet protocols. J.K. Reynolds, J. Postel. May 1987. (Format: TXT, HTML) (Obsoletes RFC0991) (Updated by RFC6093, RFC9293) (Status: UNKNOWN) (DOI: 10.17487/RFC1011) 1012 Bibliography of Request For Comments 1 through 999. J.K. Reynolds, J. Postel. June 1987. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1012) 1013 X Window System Protocol, version 11: Alpha update April 1987. R.W. Scheifler. June 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1013) 1014 XDR: External Data Representation standard. Sun Microsystems. June 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1014) 1015 Implementation plan for interagency research Internet. B.M. Leiner. July 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1015) 1016 Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID). W. Prue, J. Postel. July 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1016) 1017 Network requirements for scientific research: Internet task force on scientific computing. B.M. Leiner. August 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1017) 1018 Some comments on SQuID. A.M. McKenzie. August 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1018) 1019 Report of the Workshop on Environments for Computational Mathematics. D. Arnon. September 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1019) 1020 Internet numbers. S. Romano, M.K. Stahl. November 1987. (Format: TXT, HTML) (Obsoletes RFC0997) (Obsoleted by RFC1062, RFC1117, RFC1166) (Status: UNKNOWN) (DOI: 10.17487/RFC1020) 1021 High-level Entity Management System (HEMS). C. Partridge, G. Trewitt. October 1987. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1021) 1022 High-level Entity Management Protocol (HEMP). C. Partridge, G. Trewitt. October 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1022) 1023 HEMS monitoring and control language. G. Trewitt, C. Partridge. October 1987. (Format: TXT, HTML) (Obsoleted by RFC1076) (Status: UNKNOWN) (DOI: 10.17487/RFC1023) 1024 HEMS variable definitions. C. Partridge, G. Trewitt. October 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1024) 1025 TCP and IP bake off. J. Postel. September 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1025) 1026 Addendum to RFC 987: (Mapping between X.400 and RFC-822). S.E. Kille. September 1987. (Format: TXT, HTML) (Obsoleted by RFC2156, RFC1327) (Updates RFC0987) (Updated by RFC1138, RFC1148) (Status: UNKNOWN) (DOI: 10.17487/RFC1026) 1027 Using ARP to implement transparent subnet gateways. S. Carl-Mitchell, J.S. Quarterman. October 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1027) 1028 Simple Gateway Monitoring Protocol. J. Davin, J.D. Case, M. Fedor, M.L. Schoffstall. November 1987. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1028) 1029 More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets. G. Parr. May 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1029) 1030 On testing the NETBLT Protocol over divers networks. M.L. Lambert. November 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1030) 1031 MILNET name domain transition. W.D. Lazear. November 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1031) 1032 Domain administrators guide. M.K. Stahl. November 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1032) 1033 Domain Administrators Operations Guide. M. Lottor. November 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1033) 1034 Domain names - concepts and facilities. P. Mockapetris. November 1987. (Format: TXT, HTML) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181, RFC2308, RFC2535, RFC4033, RFC4034, RFC4035, RFC4343, RFC4035, RFC4592, RFC5936, RFC8020, RFC8482, RFC8767) (Also STD0013) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1034) 1035 Domain names - implementation and specification. P. Mockapetris. November 1987. (Format: TXT, HTML) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181, RFC2137, RFC2308, RFC2535, RFC2673, RFC2845, RFC3425, RFC3658, RFC4033, RFC4034, RFC4035, RFC4343, RFC5936, RFC5966, RFC6604, RFC7766, RFC8482, RFC8490, RFC8767) (Also STD0013) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1035) 1036 Standard for interchange of USENET messages. M.R. Horton, R. Adams. December 1987. (Format: TXT, HTML) (Obsoletes RFC0850) (Obsoleted by RFC5536, RFC5537) (Status: UNKNOWN) (DOI: 10.17487/RFC1036) 1037 NFILE - a file access protocol. B. Greenberg, S. Keene. December 1987. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1037) 1038 Draft revised IP security option. M. St. Johns. January 1988. (Format: TXT, HTML) (Obsoleted by RFC1108) (Status: UNKNOWN) (DOI: 10.17487/RFC1038) 1039 DoD statement on Open Systems Interconnection protocols. D. Latham. January 1988. (Format: TXT, HTML) (Obsoletes RFC0945) (Status: UNKNOWN) (DOI: 10.17487/RFC1039) 1040 Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures. J. Linn. January 1988. (Format: TXT, HTML) (Obsoletes RFC0989) (Obsoleted by RFC1113) (Status: UNKNOWN) (DOI: 10.17487/RFC1040) 1041 Telnet 3270 regime option. Y. Rekhter. January 1988. (Format: TXT, HTML) (Updated by RFC6270) (Status: HISTORIC) (DOI: 10.17487/RFC1041) 1042 Standard for the transmission of IP datagrams over IEEE 802 networks. J. Postel, J.K. Reynolds. February 1988. (Format: TXT, HTML) (Obsoletes RFC0948) (Also STD0043) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1042) 1043 Telnet Data Entry Terminal option: DODIIS implementation. A. Yasuda, T. Thompson. February 1988. (Format: TXT, HTML) (Updates RFC0732) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1043) 1044 Internet Protocol on Network System's HYPERchannel: Protocol Specification. K. Hardwick, J. Lekashman. February 1988. (Format: TXT, HTML) (Updated by RFC5494) (Also STD0045) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1044) 1045 VMTP: Versatile Message Transaction Protocol: Protocol specification. D.R. Cheriton. February 1988. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1045) 1046 Queuing algorithm to provide type-of-service for IP links. W. Prue, J. Postel. February 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1046) 1047 Duplicate messages and SMTP. C. Partridge. February 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1047) 1048 BOOTP vendor information extensions. P.A. Prindeville. February 1988. (Format: TXT, HTML) (Obsoleted by RFC1084, RFC1395, RFC1497, RFC1533) (Status: UNKNOWN) (DOI: 10.17487/RFC1048) 1049 Content-type header field for Internet messages. M.A. Sirbu. March 1988. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1049) 1050 RPC: Remote Procedure Call Protocol specification. Sun Microsystems. April 1988. (Format: TXT, HTML) (Obsoleted by RFC1057) (Status: HISTORIC) (DOI: 10.17487/RFC1050) 1051 Standard for the transmission of IP datagrams and ARP packets over ARCNET networks. P.A. Prindeville. March 1988. (Format: TXT, HTML) (Obsoleted by RFC1201) (Status: HISTORIC) (DOI: 10.17487/RFC1051) 1052 IAB recommendations for the development of Internet network management standards. V.G. Cerf. April 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1052) 1053 Telnet X.3 PAD option. S. Levy, T. Jacobson. April 1988. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1053) 1054 Host extensions for IP multicasting. S.E. Deering. May 1988. (Format: TXT, HTML) (Obsoletes RFC0988) (Obsoleted by RFC1112) (Status: UNKNOWN) (DOI: 10.17487/RFC1054) 1055 Nonstandard for transmission of IP datagrams over serial lines: SLIP. J.L. Romkey. June 1988. (Format: TXT, HTML) (Also STD0047) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1055) 1056 PCMAIL: A distributed mail system for personal computers. M.L. Lambert. June 1988. (Format: TXT, HTML) (Obsoletes RFC0993) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1056) 1057 RPC: Remote Procedure Call Protocol specification: Version 2. Sun Microsystems. June 1988. (Format: TXT, HTML) (Obsoletes RFC1050) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1057) 1058 Routing Information Protocol. C.L. Hedrick. June 1988. (Format: TXT, HTML) (Updated by RFC1388, RFC1723) (Status: HISTORIC) (DOI: 10.17487/RFC1058) 1059 Network Time Protocol (version 1) specification and implementation. D.L. Mills. July 1988. (Format: TXT, HTML) (Obsoletes RFC0958) (Obsoleted by RFC1119, RFC1305) (Status: UNKNOWN) (DOI: 10.17487/RFC1059) 1060 Assigned numbers. J.K. Reynolds, J. Postel. March 1990. (Format: TXT, HTML) (Obsoletes RFC1010) (Obsoleted by RFC1340) (Updated by RFC1349) (Status: HISTORIC) (DOI: 10.17487/RFC1060) 1061 Not Issued. 1062 Internet numbers. S. Romano, M.K. Stahl, M. Recker. August 1988. (Format: TXT, HTML) (Obsoletes RFC1020) (Obsoleted by RFC1117, RFC1166) (Status: UNKNOWN) (DOI: 10.17487/RFC1062) 1063 IP MTU discovery options. J.C. Mogul, C.A. Kent, C. Partridge, K. McCloghrie. July 1988. (Format: TXT, HTML) (Obsoleted by RFC1191) (Status: UNKNOWN) (DOI: 10.17487/RFC1063) 1064 Interactive Mail Access Protocol: Version 2. M.R. Crispin. July 1988. (Format: TXT, HTML) (Obsoleted by RFC1176, RFC1203) (Status: UNKNOWN) (DOI: 10.17487/RFC1064) 1065 Structure and identification of management information for TCP/IP-based internets. K. McCloghrie, M.T. Rose. August 1988. (Format: TXT, HTML) (Obsoleted by RFC1155) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1065) 1066 Management Information Base for network management of TCP/IP-based internets. K. McCloghrie, M.T. Rose. August 1988. (Format: TXT, HTML) (Obsoleted by RFC1156) (Status: UNKNOWN) (DOI: 10.17487/RFC1066) 1067 Simple Network Management Protocol. J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin. August 1988. (Format: TXT, HTML) (Obsoleted by RFC1098) (Status: UNKNOWN) (DOI: 10.17487/RFC1067) 1068 Background File Transfer Program (BFTP). A.L. DeSchon, R.T. Braden. August 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1068) 1069 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol. R. Callon, H.W. Braun. February 1989. (Format: TXT, HTML) (Obsoletes RFC0986) (Status: UNKNOWN) (DOI: 10.17487/RFC1069) 1070 Use of the Internet as a subnetwork for experimentation with the OSI network layer. R.A. Hagens, N.E. Hall, M.T. Rose. February 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1070) 1071 Computing the Internet checksum. R.T. Braden, D.A. Borman, C. Partridge. September 1988. (Format: TXT, HTML) (Updated by RFC1141) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1071) 1072 TCP extensions for long-delay paths. V. Jacobson, R.T. Braden. October 1988. (Format: TXT, HTML) (Obsoleted by RFC1323, RFC2018, RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1072) 1073 Telnet window size option. D. Waitzman. October 1988. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1073) 1074 NSFNET backbone SPF based Interior Gateway Protocol. J. Rekhter. October 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1074) 1075 Distance Vector Multicast Routing Protocol. D. Waitzman, C. Partridge, S.E. Deering. November 1988. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1075) 1076 HEMS monitoring and control language. G. Trewitt, C. Partridge. November 1988. (Format: TXT, HTML) (Obsoletes RFC1023) (Status: UNKNOWN) (DOI: 10.17487/RFC1076) 1077 Critical issues in high bandwidth networking. B.M. Leiner. November 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1077) 1078 TCP port service Multiplexer (TCPMUX). M. Lottor. November 1988. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC1078) 1079 Telnet terminal speed option. C.L. Hedrick. December 1988. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1079) 1080 Telnet remote flow control option. C.L. Hedrick. November 1988. (Format: TXT, HTML) (Obsoleted by RFC1372) (Status: UNKNOWN) (DOI: 10.17487/RFC1080) 1081 Post Office Protocol: Version 3. M.T. Rose. November 1988. (Format: TXT, HTML) (Obsoleted by RFC1225) (Status: UNKNOWN) (DOI: 10.17487/RFC1081) 1082 Post Office Protocol: Version 3: Extended service offerings. M.T. Rose. November 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1082) 1083 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. December 1988. (Format: TXT, HTML) (Obsoleted by RFC1100) (Status: HISTORIC) (DOI: 10.17487/RFC1083) 1084 BOOTP vendor information extensions. J.K. Reynolds. December 1988. (Format: TXT, HTML) (Obsoletes RFC1048) (Obsoleted by RFC1395, RFC1497, RFC1533) (Status: UNKNOWN) (DOI: 10.17487/RFC1084) 1085 ISO presentation services on top of TCP/IP based internets. M.T. Rose. December 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1085) 1086 ISO-TP0 bridge between TCP and X.25. J.P. Onions, M.T. Rose. December 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1086) 1087 Ethics and the Internet. Defense Advanced Research Projects Agency, Internet Activities Board. January 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1087) 1088 Standard for the transmission of IP datagrams over NetBIOS networks. L.J. McLaughlin. February 1989. (Format: TXT, HTML) (Also STD0048) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1088) 1089 SNMP over Ethernet. M. Schoffstall, C. Davin, M. Fedor, J. Case. February 1989. (Format: TXT, HTML) (Obsoleted by RFC4789) (Status: UNKNOWN) (DOI: 10.17487/RFC1089) 1090 SMTP on X.25. R. Ullmann. February 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1090) 1091 Telnet terminal-type option. J. VanBokkelen. February 1989. (Format: TXT, HTML) (Obsoletes RFC0930) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1091) 1092 EGP and policy based routing in the new NSFNET backbone. J. Rekhter. February 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1092) 1093 NSFNET routing architecture. H.W. Braun. February 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1093) 1094 NFS: Network File System Protocol specification. B. Nowicki. March 1989. (Format: TXT, HTML) (Also RFC1813) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1094) 1095 Common Management Information Services and Protocol over TCP/IP (CMOT). U.S. Warrier, L. Besaw. April 1989. (Format: TXT, HTML) (Obsoleted by RFC1189) (Status: UNKNOWN) (DOI: 10.17487/RFC1095) 1096 Telnet X display location option. G.A. Marcy. March 1989. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1096) 1097 Telnet subliminal-message option. B. Miller. 1 April 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1097) 1098 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin. April 1989. (Format: TXT, HTML) (Obsoletes RFC1067) (Obsoleted by RFC1157) (Status: UNKNOWN) (DOI: 10.17487/RFC1098) 1099 Request for Comments Summary: RFC Numbers 1000-1099. J. Reynolds. December 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1099) 1100 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. April 1989. (Format: TXT, HTML) (Obsoletes RFC1083) (Obsoleted by RFC1130) (Status: HISTORIC) (DOI: 10.17487/RFC1100) 1101 DNS encoding of network names and other types. P. Mockapetris. April 1989. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Status: UNKNOWN) (DOI: 10.17487/RFC1101) 1102 Policy routing in Internet protocols. D.D. Clark. May 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1102) 1103 Proposed standard for the transmission of IP datagrams over FDDI Networks. D. Katz. June 1989. (Format: TXT, HTML) (Obsoleted by RFC1188) (Status: UNKNOWN) (DOI: 10.17487/RFC1103) 1104 Models of policy based routing. H.W. Braun. June 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1104) 1105 Border Gateway Protocol (BGP). K. Lougheed, Y. Rekhter. June 1989. (Format: TXT, HTML) (Obsoleted by RFC1163) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1105) 1106 TCP big window and NAK options. R. Fox. June 1989. (Format: TXT, HTML) (Obsoleted by RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1106) 1107 Plan for Internet directory services. K.R. Sollins. July 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1107) 1108 U.S. Department of Defense Security Options for the Internet Protocol. S. Kent. November 1991. (Format: TXT, HTML) (Obsoletes RFC1038) (Status: HISTORIC) (DOI: 10.17487/RFC1108) 1109 Report of the second Ad Hoc Network Management Review Group. V.G. Cerf. August 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1109) 1110 Problem with the TCP big window option. A.M. McKenzie. August 1989. (Format: TXT, HTML) (Obsoleted by RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1110) 1111 Request for comments on Request for Comments: Instructions to RFC authors. J. Postel. August 1989. (Format: TXT, HTML) (Obsoletes RFC0825) (Obsoleted by RFC1543, RFC2223) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1111) 1112 Host extensions for IP multicasting. S.E. Deering. August 1989. (Format: TXT, HTML) (Obsoletes RFC0988, RFC1054) (Updated by RFC2236) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1112) 1113 Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures. J. Linn. August 1989. (Format: TXT, HTML) (Obsoletes RFC0989, RFC1040) (Obsoleted by RFC1421) (Status: HISTORIC) (DOI: 10.17487/RFC1113) 1114 Privacy enhancement for Internet electronic mail: Part II - certificate-based key management. S.T. Kent, J. Linn. August 1989. (Format: TXT, HTML) (Obsoleted by RFC1422) (Status: HISTORIC) (DOI: 10.17487/RFC1114) 1115 Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers. J. Linn. August 1989. (Format: TXT, HTML) (Obsoleted by RFC1423) (Status: HISTORIC) (DOI: 10.17487/RFC1115) 1116 Telnet Linemode option. D.A. Borman. August 1989. (Format: TXT, HTML) (Obsoleted by RFC1184) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1116) 1117 Internet numbers. S. Romano, M.K. Stahl, M. Recker. August 1989. (Format: TXT, HTML) (Obsoletes RFC1062, RFC1020, RFC0997) (Obsoleted by RFC1166) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1117) 1118 Hitchhikers guide to the Internet. E. Krol. September 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1118) 1119 Network Time Protocol (version 2) specification and implementation. D.L. Mills. September 1989. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC0958, RFC1059) (Obsoleted by RFC1305) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1119) 1120 Internet Activities Board. V. Cerf. September 1989. (Format: TXT, HTML) (Obsoleted by RFC1160) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1120) 1121 Act one - the poems. J. Postel, L. Kleinrock, V.G. Cerf, B. Boehm. September 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1121) 1122 Requirements for Internet Hosts - Communication Layers. R. Braden, Ed.. October 1989. (Format: TXT, HTML) (Updates RFC0793) (Updated by RFC1349, RFC4379, RFC5884, RFC6093, RFC6298, RFC6633, RFC6864, RFC8029, RFC9293) (Also STD0003) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1122) 1123 Requirements for Internet Hosts - Application and Support. R. Braden, Ed.. October 1989. (Format: TXT, HTML) (Updates RFC0822, RFC0952) (Updated by RFC1349, RFC2181, RFC5321, RFC5966, RFC7766, RFC9210) (Also STD0003) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1123) 1124 Policy issues in interconnecting networks. B.M. Leiner. September 1989. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1124) 1125 Policy requirements for inter Administrative Domain routing. D. Estrin. November 1989. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1125) 1126 Goals and functional requirements for inter-autonomous system routing. M. Little. October 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1126) 1127 Perspective on the Host Requirements RFCs. R.T. Braden. October 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1127) 1128 Measured performance of the Network Time Protocol in the Internet system. D.L. Mills. October 1989. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1128) 1129 Internet Time Synchronization: The Network Time Protocol. D.L. Mills. October 1989. (Format: TXT, PS, PDF, HTML) (Also RFC1119) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1129) 1130 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. October 1989. (Format: TXT, HTML) (Obsoletes RFC1100) (Obsoleted by RFC1140) (Status: HISTORIC) (DOI: 10.17487/RFC1130) 1131 OSPF specification. J. Moy. October 1989. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC1247) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1131) 1132 Standard for the transmission of 802.2 packets over IPX networks. L.J. McLaughlin. November 1989. (Format: TXT, HTML) (Also STD0049) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1132) 1133 Routing between the NSFNET and the DDN. J.Y. Yu, H.W. Braun. November 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1133) 1134 Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links. D. Perkins. November 1989. (Format: TXT, HTML) (Obsoleted by RFC1171) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1134) 1135 Helminthiasis of the Internet. J.K. Reynolds. December 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1135) 1136 Administrative Domains and Routing Domains: A model for routing in the Internet. S. Hares, D. Katz. December 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1136) 1137 Mapping between full RFC 822 and RFC 822 with restricted encoding. S. Kille. December 1989. (Format: TXT, HTML) (Updates RFC0976) (Status: HISTORIC) (DOI: 10.17487/RFC1137) 1138 Mapping between X.400(1988) / ISO 10021 and RFC 822. S.E. Kille. December 1989. (Format: TXT, HTML) (Obsoleted by RFC2156, RFC1327) (Updates RFC1026, RFC0987, RFC0822) (Updated by RFC1148) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1138) 1139 Echo function for ISO 8473. R.A. Hagens. January 1990. (Format: TXT, HTML) (Obsoleted by RFC1574, RFC1575) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1139) 1140 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. May 1990. (Format: TXT, HTML) (Obsoletes RFC1130) (Obsoleted by RFC1200) (Status: HISTORIC) (DOI: 10.17487/RFC1140) 1141 Incremental updating of the Internet checksum. T. Mallory, A. Kullberg. January 1990. (Format: TXT, HTML) (Updates RFC1071) (Updated by RFC1624) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1141) 1142 OSI IS-IS Intra-domain Routing Protocol. D. Oran, Ed.. February 1990. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC7142) (Status: HISTORIC) (DOI: 10.17487/RFC1142) 1143 The Q Method of Implementing TELNET Option Negotiation. D.J. Bernstein. February 1990. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1143) 1144 Compressing TCP/IP Headers for Low-Speed Serial Links. V. Jacobson. February 1990. (Format: TXT, PS, PDF, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1144) 1145 TCP alternate checksum options. J. Zweig, C. Partridge. February 1990. (Format: TXT, HTML) (Obsoleted by RFC1146, RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1145) 1146 TCP alternate checksum options. J. Zweig, C. Partridge. March 1990. (Format: TXT, HTML) (Obsoletes RFC1145) (Obsoleted by RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1146) 1147 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices. R.H. Stine. April 1990. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC1470) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1147) 1148 Mapping between X.400(1988) / ISO 10021 and RFC 822. S.E. Kille. March 1990. (Format: TXT, HTML) (Obsoleted by RFC2156, RFC1327) (Updates RFC1026, RFC0987, RFC1138, RFC0822) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1148) 1149 Standard for the transmission of IP datagrams on avian carriers. D. Waitzman. 1 April 1990. (Format: TXT, HTML) (Updated by RFC2549, RFC6214) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1149) 1150 FYI on FYI: Introduction to the FYI Notes. G.S. Malkin, J.K. Reynolds. March 1990. (Format: TXT, HTML) (Obsoleted by RFC6360) (Status: HISTORIC) (DOI: 10.17487/RFC1150) 1151 Version 2 of the Reliable Data Protocol (RDP). C. Partridge, R.M. Hinden. April 1990. (Format: TXT, HTML) (Updates RFC0908) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1151) 1152 Workshop report: Internet research steering group workshop on very-high-speed networks. C. Partridge. April 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1152) 1153 Digest message format. F.J. Wancho. April 1990. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1153) 1154 Encoding header field for internet messages. D. Robinson, R. Ullmann. April 1990. (Format: TXT, HTML) (Obsoleted by RFC1505) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1154) 1155 Structure and identification of management information for TCP/IP-based internets. M.T. Rose, K. McCloghrie. May 1990. (Format: TXT, HTML) (Obsoletes RFC1065) (Also STD0016) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1155) 1156 Management Information Base for network management of TCP/IP-based internets. K. McCloghrie, M.T. Rose. May 1990. (Format: TXT, HTML) (Obsoletes RFC1066) (Status: HISTORIC) (DOI: 10.17487/RFC1156) 1157 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin. May 1990. (Format: TXT, HTML) (Obsoletes RFC1098) (Status: HISTORIC) (DOI: 10.17487/RFC1157) 1158 Management Information Base for network management of TCP/IP-based internets: MIB-II. M.T. Rose. May 1990. (Format: TXT, HTML) (Obsoleted by RFC1213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1158) 1159 Message Send Protocol. R. Nelson. June 1990. (Format: TXT, HTML) (Obsoleted by RFC1312) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1159) 1160 Internet Activities Board. V. Cerf. May 1990. (Format: TXT, HTML) (Obsoletes RFC1120) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1160) 1161 SNMP over OSI. M.T. Rose. June 1990. (Format: TXT, HTML) (Obsoleted by RFC1418) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1161) 1162 Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base. G. Satz. June 1990. (Format: TXT, HTML) (Obsoleted by RFC1238) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1162) 1163 Border Gateway Protocol (BGP). K. Lougheed, Y. Rekhter. June 1990. (Format: TXT, HTML) (Obsoletes RFC1105) (Obsoleted by RFC1267) (Status: HISTORIC) (DOI: 10.17487/RFC1163) 1164 Application of the Border Gateway Protocol in the Internet. J.C. Honig, D. Katz, M. Mathis, Y. Rekhter, J.Y. Yu. June 1990. (Format: TXT, HTML) (Obsoleted by RFC1268) (Status: HISTORIC) (DOI: 10.17487/RFC1164) 1165 Network Time Protocol (NTP) over the OSI Remote Operations Service. J. Crowcroft, J.P. Onions. June 1990. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1165) 1166 Internet numbers. S. Kirkpatrick, M.K. Stahl, M. Recker. July 1990. (Format: TXT, HTML) (Obsoletes RFC1117, RFC1062, RFC1020) (Updated by RFC5737) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1166) 1167 Thoughts on the National Research and Education Network. V.G. Cerf. July 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1167) 1168 Intermail and Commercial Mail Relay services. A. Westine, A.L. DeSchon, J. Postel, C.E. Ward. July 1990. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1168) 1169 Explaining the role of GOSIP. V.G. Cerf, K.L. Mills. August 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1169) 1170 Public key standards and licenses. R.B. Fougner. January 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1170) 1171 Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links. D. Perkins. July 1990. (Format: TXT, HTML) (Obsoletes RFC1134) (Obsoleted by RFC1331) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1171) 1172 Point-to-Point Protocol (PPP) initial configuration options. D. Perkins, R. Hobby. July 1990. (Format: TXT, HTML) (Obsoleted by RFC1331, RFC1332) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1172) 1173 Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet. J. VanBokkelen. August 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1173) 1174 IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet "connected" status. V.G. Cerf. August 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1174) 1175 FYI on where to start: A bibliography of internetworking information. K.L. Bowers, T.L. LaQuey, J.K. Reynolds, K. Roubicek, M.K. Stahl, A. Yuan. August 1990. (Format: TXT, HTML) (Also FYI0003) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1175) 1176 Interactive Mail Access Protocol: Version 2. M.R. Crispin. August 1990. (Format: TXT, HTML) (Obsoletes RFC1064) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1176) 1177 FYI on Questions and Answers: Answers to commonly asked "new internet user" questions. G.S. Malkin, A.N. Marine, J.K. Reynolds. August 1990. (Format: TXT, HTML) (Obsoleted by RFC1206) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1177) 1178 Choosing a name for your computer. D. Libes. August 1990. (Format: TXT, HTML) (Also FYI0005) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1178) 1179 Line printer daemon protocol. L. McLaughlin. August 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1179) 1180 TCP/IP tutorial. T.J. Socolofsky, C.J. Kale. January 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1180) 1181 RIPE Terms of Reference. R. Blokzijl. September 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1181) 1182 Not Issued. 1183 New DNS RR Definitions. C. Everhart, L. Mamakos, R. Ullmann, P. Mockapetris, Ed.. October 1990. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Updated by RFC5395, RFC5864, RFC6195, RFC6895) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1183) 1184 Telnet Linemode Option. D.A. Borman. October 1990. (Format: TXT, HTML) (Obsoletes RFC1116) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1184) 1185 TCP Extension for High-Speed Paths. V. Jacobson, R.T. Braden, L. Zhang. October 1990. (Format: TXT, HTML) (Obsoleted by RFC1323) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1185) 1186 MD4 Message Digest Algorithm. R.L. Rivest. October 1990. (Format: TXT, HTML) (Obsoleted by RFC1320) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1186) 1187 Bulk Table Retrieval with the SNMP. M.T. Rose, K. McCloghrie, J.R. Davin. October 1990. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1187) 1188 Proposed Standard for the Transmission of IP Datagrams over FDDI Networks. D. Katz. October 1990. (Format: TXT, HTML) (Obsoletes RFC1103) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1188) 1189 Common Management Information Services and Protocols for the Internet (CMOT and CMIP). U.S. Warrier, L. Besaw, L. LaBarre, B.D. Handspicker. October 1990. (Format: TXT, HTML) (Obsoletes RFC1095) (Status: HISTORIC) (DOI: 10.17487/RFC1189) 1190 Experimental Internet Stream Protocol: Version 2 (ST-II). C. Topolcic. October 1990. (Format: TXT, HTML) (Obsoletes IEN119) (Obsoleted by RFC1819) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1190) 1191 Path MTU discovery. J. Mogul, S. Deering. November 1990. (Format: TXT, HTML) (Obsoletes RFC1063) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1191) 1192 Commercialization of the Internet summary report. B. Kahin. November 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1192) 1193 Client requirements for real-time communication services. D. Ferrari. November 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1193) 1194 Finger User Information Protocol. D.P. Zimmerman. November 1990. (Format: TXT, HTML) (Obsoletes RFC0742) (Obsoleted by RFC1196, RFC1288) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1194) 1195 Use of OSI IS-IS for routing in TCP/IP and dual environments. R. Callon. December 1990. (Format: TXT, PS, HTML) (Updated by RFC1349, RFC5302, RFC5304) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1195) 1196 Finger User Information Protocol. D.P. Zimmerman. December 1990. (Format: TXT, HTML) (Obsoletes RFC1194, RFC0742) (Obsoleted by RFC1288) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1196) 1197 Using ODA for translating multimedia information. M. Sherman. December 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1197) 1198 FYI on the X window system. R.W. Scheifler. January 1991. (Format: TXT, HTML) (Also FYI0006) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1198) 1199 Request for Comments Summary Notes: 1100-1199. J. Reynolds. December 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1199) 1200 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. April 1991. (Format: TXT, HTML) (Obsoletes RFC1140) (Obsoleted by RFC1250) (Status: HISTORIC) (DOI: 10.17487/RFC1200) 1201 Transmitting IP traffic over ARCNET networks. D. Provan. February 1991. (Format: TXT, HTML) (Obsoletes RFC1051) (Also STD0046) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1201) 1202 Directory Assistance service. M.T. Rose. February 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1202) 1203 Interactive Mail Access Protocol: Version 3. J. Rice. February 1991. (Format: TXT, HTML) (Obsoletes RFC1064) (Status: HISTORIC) (DOI: 10.17487/RFC1203) 1204 Message Posting Protocol (MPP). S. Yeh, D. Lee. February 1991. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1204) 1205 5250 Telnet interface. P. Chmielewski. February 1991. (Format: TXT, HTML) (Updated by RFC2877) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1205) 1206 FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions. G.S. Malkin, A.N. Marine. February 1991. (Format: TXT, HTML) (Obsoletes RFC1177) (Obsoleted by RFC1325) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1206) 1207 FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions. G.S. Malkin, A.N. Marine, J.K. Reynolds. February 1991. (Format: TXT, HTML) (Also FYI0007) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1207) 1208 A Glossary of Networking Terms. O.J. Jacobsen, D.C. Lynch. March 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1208) 1209 The Transmission of IP Datagrams over the SMDS Service. D. Piscitello, J. Lawrence. March 1991. (Format: TXT, HTML) (Also STD0052) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1209) 1210 Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990. V.G. Cerf, P.T. Kirstein, B. Randell. March 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1210) 1211 Problems with the maintenance of large mailing lists. A. Westine, J. Postel. March 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1211) 1212 Concise MIB definitions. M.T. Rose, K. McCloghrie. March 1991. (Format: TXT, HTML) (Also STD0016) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1212) 1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II. K. McCloghrie, M. Rose. March 1991. (Format: TXT, HTML) (Obsoletes RFC1158) (Updated by RFC2011, RFC2012, RFC2013) (Also STD0017) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1213) 1214 OSI internet management: Management Information Base. L. LaBarre. April 1991. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1214) 1215 Convention for defining traps for use with the SNMP. M.T. Rose. March 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1215) 1216 Gigabit network economics and paradigm shifts. P. Richard, P. Kynikos. 1 April 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1216) 1217 Memo from the Consortium for Slow Commotion Research (CSCR). V.G. Cerf. 1 April 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1217) 1218 Naming scheme for c=US. North American Directory Forum. April 1991. (Format: TXT, HTML) (Obsoleted by RFC1255, RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1218) 1219 On the assignment of subnet numbers. P.F. Tsuchiya. April 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1219) 1220 Point-to-Point Protocol extensions for bridging. F. Baker. April 1991. (Format: TXT, HTML) (Obsoleted by RFC1638) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1220) 1221 Host Access Protocol (HAP) specification: Version 2. W. Edmond. April 1991. (Format: TXT, HTML) (Updates RFC0907) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1221) 1222 Advancing the NSFNET routing architecture. H.W. Braun, Y. Rekhter. May 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1222) 1223 OSI CLNS and LLC1 protocols on Network Systems HYPERchannel. J.M. Halpern. May 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1223) 1224 Techniques for managing asynchronously generated alerts. L. Steinberg. May 1991. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1224) 1225 Post Office Protocol: Version 3. M.T. Rose. May 1991. (Format: TXT, HTML) (Obsoletes RFC1081) (Obsoleted by RFC1460) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1225) 1226 Internet protocol encapsulation of AX.25 frames. B. Kantor. May 1991. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1226) 1227 SNMP MUX protocol and MIB. M.T. Rose. May 1991. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1227) 1228 SNMP-DPI: Simple Network Management Protocol Distributed Program Interface. G. Carpenter, B. Wijnen. May 1991. (Format: TXT, HTML) (Obsoleted by RFC1592) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1228) 1229 Extensions to the generic-interface MIB. K. McCloghrie. May 1991. (Format: TXT, HTML) (Obsoleted by RFC1573) (Updated by RFC1239) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1229) 1230 IEEE 802.4 Token Bus MIB. K. McCloghrie, R. Fox. May 1991. (Format: TXT, HTML) (Updated by RFC1239) (Status: HISTORIC) (DOI: 10.17487/RFC1230) 1231 IEEE 802.5 Token Ring MIB. K. McCloghrie, R. Fox, E. Decker. May 1991. (Format: TXT, HTML) (Obsoleted by RFC1743, RFC1748) (Updated by RFC1239) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1231) 1232 Definitions of managed objects for the DS1 Interface type. F. Baker, C.P. Kolb. May 1991. (Format: TXT, HTML) (Obsoleted by RFC1406) (Updated by RFC1239) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1232) 1233 Definitions of managed objects for the DS3 Interface type. T.A. Cox, K. Tesink. May 1991. (Format: TXT, HTML) (Obsoleted by RFC1407) (Updated by RFC1239) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1233) 1234 Tunneling IPX traffic through IP networks. D. Provan. June 1991. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1234) 1235 Coherent File Distribution Protocol. J. Ioannidis, G. Maguire. June 1991. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1235) 1236 IP to X.121 address mapping for DDN. L. Morales, P. Hasse. June 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1236) 1237 Guidelines for OSI NSAP Allocation in the Internet. R. Colella, E. Gardner, R. Callon. July 1991. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC1629) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1237) 1238 CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542). G. Satz. June 1991. (Format: TXT, HTML) (Obsoletes RFC1162) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1238) 1239 Reassignment of experimental MIBs to standard MIBs. J.K. Reynolds. June 1991. (Format: TXT, HTML) (Updates RFC1229, RFC1230, RFC1231, RFC1232, RFC1233) (Status: HISTORIC) (DOI: 10.17487/RFC1239) 1240 OSI connectionless transport services on top of UDP: Version 1. C. Shue, W. Haggerty, K. Dobbins. June 1991. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1240) 1241 Scheme for an internet encapsulation protocol: Version 1. R.A. Woodburn, D.L. Mills. July 1991. (Format: TXT, PS, PDF, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1241) 1242 Benchmarking Terminology for Network Interconnection Devices. S. Bradner. July 1991. (Format: TXT, HTML) (Updated by RFC6201) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1242) 1243 AppleTalk Management Information Base. S. Waldbusser. July 1991. (Format: TXT, HTML) (Obsoleted by RFC1742) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1243) 1244 Site Security Handbook. J.P. Holbrook, J.K. Reynolds. July 1991. (Format: TXT, HTML) (Obsoleted by RFC2196) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1244) 1245 OSPF Protocol Analysis. J. Moy. July 1991. (Format: TXT, PS, PDF, HTML) (Also RFC1246, RFC1247) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1245) 1246 Experience with the OSPF Protocol. J. Moy. July 1991. (Format: TXT, PS, PDF, HTML) (Also RFC1245, RFC1247) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1246) 1247 OSPF Version 2. J. Moy. July 1991. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1131) (Obsoleted by RFC1583) (Updated by RFC1349) (Also RFC1245, RFC1246) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1247) 1248 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. July 1991. (Format: TXT, HTML) (Obsoleted by RFC1252) (Updated by RFC1349) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1248) 1249 DIXIE Protocol Specification. T. Howes, M. Smith, B. Beecher. August 1991. (Format: TXT, HTML) (Also RFC1202) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1249) 1250 IAB Official Protocol Standards. J. Postel. August 1991. (Format: TXT, HTML) (Obsoletes RFC1200) (Obsoleted by RFC2200, RFC1280) (Status: HISTORIC) (DOI: 10.17487/RFC1250) 1251 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members. G. Malkin. August 1991. (Format: TXT, HTML) (Obsoleted by RFC1336) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1251) 1252 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. August 1991. (Format: TXT, HTML) (Obsoletes RFC1248) (Obsoleted by RFC1253) (Also RFC1245, RFC1247) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1252) 1253 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. August 1991. (Format: TXT, HTML) (Obsoletes RFC1252) (Obsoleted by RFC1850) (Also RFC1245, RFC1246, RFC1247) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1253) 1254 Gateway Congestion Control Survey. A. Mankin, K. Ramakrishnan. August 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1254) 1255 A Naming Scheme for c=US. The North American Directory Forum. September 1991. (Format: TXT, HTML) (Obsoletes RFC1218) (Obsoleted by RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1255) 1256 ICMP Router Discovery Messages. S. Deering, Ed.. September 1991. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1256) 1257 Isochronous applications do not require jitter-controlled networks. C. Partridge. September 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1257) 1258 BSD Rlogin. B. Kantor. September 1991. (Format: TXT, HTML) (Obsoleted by RFC1282) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1258) 1259 Building the open road: The NREN as test-bed for the national public network. M. Kapor. September 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1259) 1260 Not Issued. 1261 Transition of Nic Services. S. Williamson, L. Nobile. September 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1261) 1262 Guidelines for Internet Measurement Activities. V.G. Cerf. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1262) 1263 TCP Extensions Considered Harmful. S. O'Malley, L.L. Peterson. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1263) 1264 Internet Engineering Task Force Internet Routing Protocol Standardization Criteria. R.M. Hinden. October 1991. (Format: TXT, HTML) (Obsoleted by RFC4794) (Status: HISTORIC) (DOI: 10.17487/RFC1264) 1265 BGP Protocol Analysis. Y. Rekhter. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1265) 1266 Experience with the BGP Protocol. Y. Rekhter. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1266) 1267 Border Gateway Protocol 3 (BGP-3). K. Lougheed, Y. Rekhter. October 1991. (Format: TXT, HTML) (Obsoletes RFC1163) (Status: HISTORIC) (DOI: 10.17487/RFC1267) 1268 Application of the Border Gateway Protocol in the Internet. Y. Rekhter, P. Gross. October 1991. (Format: TXT, HTML) (Obsoletes RFC1164) (Obsoleted by RFC1655) (Status: HISTORIC) (DOI: 10.17487/RFC1268) 1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3. S. Willis, J.W. Burruss. October 1991. (Format: TXT, HTML) (Obsoleted by RFC4273) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1269) 1270 SNMP Communications Services. F. Kastenholz. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1270) 1271 Remote Network Monitoring Management Information Base. S. Waldbusser. November 1991. (Format: TXT, HTML) (Obsoleted by RFC1757) (Updated by RFC1513) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1271) 1272 Internet Accounting: Background. C. Mills, D. Hirsh, G.R. Ruth. November 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1272) 1273 Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations. M.F. Schwartz. November 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1273) 1274 The COSINE and Internet X.500 Schema. P. Barker, S. Kille. November 1991. (Format: TXT, HTML) (Obsoleted by RFC4524) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1274) 1275 Replication Requirements to provide an Internet Directory using X.500. S.E. Hardcastle-Kille. November 1991. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1275) 1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500. S.E. Hardcastle-Kille. November 1991. (Format: TXT, PS, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1276) 1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers. S.E. Hardcastle-Kille. November 1991. (Format: TXT, PS, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1277) 1278 A string encoding of Presentation Address. S.E. Hardcastle-Kille. November 1991. (Format: TXT, PS, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1278) 1279 X.500 and Domains. S.E. Hardcastle-Kille. November 1991. (Format: TXT, PS, PDF, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1279) 1280 IAB Official Protocol Standards. J. Postel. March 1992. (Format: TXT, HTML) (Obsoletes RFC1250) (Obsoleted by RFC1360) (Status: HISTORIC) (DOI: 10.17487/RFC1280) 1281 Guidelines for the Secure Operation of the Internet. R. Pethia, S. Crocker, B. Fraser. November 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1281) 1282 BSD Rlogin. B. Kantor. December 1991. (Format: TXT, HTML) (Obsoletes RFC1258) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1282) 1283 SNMP over OSI. M. Rose. December 1991. (Format: TXT, HTML) (Obsoleted by RFC1418) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1283) 1284 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Cook, Ed.. December 1991. (Format: TXT, HTML) (Obsoleted by RFC1398) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1284) 1285 FDDI Management Information Base. J. Case. January 1992. (Format: TXT, HTML) (Updated by RFC1512) (Status: HISTORIC) (DOI: 10.17487/RFC1285) 1286 Definitions of Managed Objects for Bridges. E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie. December 1991. (Format: TXT, HTML) (Obsoleted by RFC1493, RFC1525) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1286) 1287 Towards the Future Internet Architecture. D. Clark, L. Chapin, V. Cerf, R. Braden, R. Hobby. December 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1287) 1288 The Finger User Information Protocol. D. Zimmerman. December 1991. (Format: TXT, HTML) (Obsoletes RFC1196, RFC1194, RFC0742) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1288) 1289 DECnet Phase IV MIB Extensions. J. Saperia. December 1991. (Format: TXT, HTML) (Obsoleted by RFC1559) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1289) 1290 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places. J. Martin. December 1991. (Format: TXT, HTML) (Obsoleted by RFC1402) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1290) 1291 Mid-Level Networks Potential Technical Services. V. Aggarwal. December 1991. (Format: TXT, PS, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1291) 1292 A Catalog of Available X.500 Implementations. R. Lang, R. Wright. January 1992. (Format: TXT, HTML) (Obsoleted by RFC1632) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1292) 1293 Inverse Address Resolution Protocol. T. Bradley, C. Brown. January 1992. (Format: TXT, HTML) (Obsoleted by RFC2390) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1293) 1294 Multiprotocol Interconnect over Frame Relay. T. Bradley, C. Brown, A. Malis. January 1992. (Format: TXT, HTML) (Obsoleted by RFC1490, RFC2427) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1294) 1295 User Bill of Rights for entries and listings in the Public Directory. The North American Directory Forum. January 1992. (Format: TXT, HTML) (Obsoleted by RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1295) 1296 Internet Growth (1981-1991). M. Lottor. January 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1296) 1297 NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS"). D. Johnson. January 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1297) 1298 SNMP over IPX. R. Wormley, S. Bostock. February 1992. (Format: TXT, HTML) (Obsoleted by RFC1420) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1298) 1299 Summary of 1200-1299. M. Kennedy. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1299) 1300 Remembrances of Things Past. S. Greenfield. February 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1300) 1301 Multicast Transport Protocol. S. Armstrong, A. Freier, K. Marzullo. February 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1301) 1302 Building a Network Information Services Infrastructure. D. Sitzler, P. Smith, A. Marine. February 1992. (Format: TXT, HTML) (Also FYI0012) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1302) 1303 A Convention for Describing SNMP-based Agents. K. McCloghrie, M. Rose. February 1992. (Format: TXT, HTML) (Also RFC1155, RFC1157, RFC1212, RFC1213) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1303) 1304 Definitions of Managed Objects for the SIP Interface Type. T. Cox, Ed., K. Tesink, Ed.. February 1992. (Format: TXT, HTML) (Obsoleted by RFC1694) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1304) 1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis. D. Mills. March 1992. (Format: TXT, PDF, HTML) (Obsoletes RFC0958, RFC1059, RFC1119) (Obsoleted by RFC5905) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1305) 1306 Experiences Supporting By-Request Circuit-Switched T3 Networks. A. Nicholson, J. Young. March 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1306) 1307 Dynamically Switched Link Control Protocol. J. Young, A. Nicholson. March 1992. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1307) 1308 Executive Introduction to Directory Services Using the X.500 Protocol. C. Weider, J. Reynolds. March 1992. (Format: TXT, HTML) (Also FYI0013) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1308) 1309 Technical Overview of Directory Services Using the X.500 Protocol. C. Weider, J. Reynolds, S. Heker. March 1992. (Format: TXT, HTML) (Also FYI0014) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1309) 1310 The Internet Standards Process. L. Chapin. March 1992. (Format: TXT, HTML) (Obsoleted by RFC1602) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1310) 1311 Introduction to the STD Notes. J. Postel. March 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1311) 1312 Message Send Protocol 2. R. Nelson, G. Arnold. April 1992. (Format: TXT, HTML) (Obsoletes RFC1159) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1312) 1313 Today's Programming for KRFC AM 1313 Internet Talk Radio. C. Partridge. 1 April 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1313) 1314 A File Format for the Exchange of Images in the Internet. A. Katz, D. Cohen. April 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1314) 1315 Management Information Base for Frame Relay DTEs. C. Brown, F. Baker, C. Carvalho. April 1992. (Format: TXT, HTML) (Obsoleted by RFC2115) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1315) 1316 Definitions of Managed Objects for Character Stream Devices. B. Stewart. April 1992. (Format: TXT, HTML) (Obsoleted by RFC1658) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1316) 1317 Definitions of Managed Objects for RS-232-like Hardware Devices. B. Stewart. April 1992. (Format: TXT, HTML) (Obsoleted by RFC1659) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1317) 1318 Definitions of Managed Objects for Parallel-printer-like Hardware Devices. B. Stewart. April 1992. (Format: TXT, HTML) (Obsoleted by RFC1660) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1318) 1319 The MD2 Message-Digest Algorithm. B. Kaliski. April 1992. (Format: TXT, HTML) (Obsoleted by RFC6149) (Status: HISTORIC) (DOI: 10.17487/RFC1319) 1320 The MD4 Message-Digest Algorithm. R. Rivest. April 1992. (Format: TXT, HTML) (Obsoletes RFC1186) (Obsoleted by RFC6150) (Status: HISTORIC) (DOI: 10.17487/RFC1320) 1321 The MD5 Message-Digest Algorithm. R. Rivest. April 1992. (Format: TXT, HTML) (Updated by RFC6151) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1321) 1322 A Unified Approach to Inter-Domain Routing. D. Estrin, Y. Rekhter, S. Hotz. May 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1322) 1323 TCP Extensions for High Performance. V. Jacobson, R. Braden, D. Borman. May 1992. (Format: TXT, HTML) (Obsoletes RFC1072, RFC1185) (Obsoleted by RFC7323) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1323) 1324 A Discussion on Computer Network Conferencing. D. Reed. May 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1324) 1325 FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions. G. Malkin, A. Marine. May 1992. (Format: TXT, HTML) (Obsoletes RFC1206) (Obsoleted by RFC1594) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1325) 1326 Mutual Encapsulation Considered Dangerous. P. Tsuchiya. May 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1326) 1327 Mapping between X.400(1988) / ISO 10021 and RFC 822. S. Hardcastle-Kille. May 1992. (Format: TXT, HTML) (Obsoletes RFC0987, RFC1026, RFC1138, RFC1148) (Obsoleted by RFC2156) (Updates RFC0822) (Updated by RFC1495) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1327) 1328 X.400 1988 to 1984 downgrading. S. Hardcastle-Kille. May 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1328) 1329 Thoughts on Address Resolution for Dual MAC FDDI Networks. P. Kuehn. May 1992. (Format: TXT, HTML) (Updated by RFC5494) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1329) 1330 Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community. ESCC X.500/X.400 Task Force, ESnet Site Coordinating Comittee (ESCC), Energy Sciences Network (ESnet). May 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1330) 1331 The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links. W. Simpson. May 1992. (Format: TXT, HTML) (Obsoletes RFC1171, RFC1172) (Obsoleted by RFC1548) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1331) 1332 The PPP Internet Protocol Control Protocol (IPCP). G. McGregor. May 1992. (Format: TXT, HTML) (Obsoletes RFC1172) (Updated by RFC3241) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1332) 1333 PPP Link Quality Monitoring. W. Simpson. May 1992. (Format: TXT, HTML) (Obsoleted by RFC1989) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1333) 1334 PPP Authentication Protocols. B. Lloyd, W. Simpson. October 1992. (Format: TXT, HTML) (Obsoleted by RFC1994) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1334) 1335 A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion. Z. Wang, J. Crowcroft. May 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1335) 1336 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members. G. Malkin. May 1992. (Format: TXT, HTML) (Obsoletes RFC1251) (Also FYI0009) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1336) 1337 TIME-WAIT Assassination Hazards in TCP. R. Braden. May 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1337) 1338 Supernetting: an Address Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. June 1992. (Format: TXT, HTML) (Obsoleted by RFC1519) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1338) 1339 Remote Mail Checking Protocol. S. Dorner, P. Resnick. June 1992. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1339) 1340 Assigned Numbers. J. Reynolds, J. Postel. July 1992. (Format: TXT, HTML) (Obsoletes RFC1060) (Obsoleted by RFC1700) (Status: HISTORIC) (DOI: 10.17487/RFC1340) 1341 MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies. N. Borenstein, N. Freed. June 1992. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC1521) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1341) 1342 Representation of Non-ASCII Text in Internet Message Headers. K. Moore. June 1992. (Format: TXT, HTML) (Obsoleted by RFC1522) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1342) 1343 A User Agent Configuration Mechanism for Multimedia Mail Format Information. N. Borenstein. June 1992. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1343) 1344 Implications of MIME for Internet Mail Gateways. N. Borenstein. June 1992. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1344) 1345 Character Mnemonics and Character Sets. K. Simonsen. June 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1345) 1346 Resource Allocation, Control, and Accounting for the Use of Network Resources. P. Jones. June 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1346) 1347 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing. R. Callon. June 1992. (Format: TXT, PS, PDF, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1347) 1348 DNS NSAP RRs. B. Manning. July 1992. (Format: TXT, HTML) (Obsoleted by RFC1637) (Updates RFC1034, RFC1035) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1348) 1349 Type of Service in the Internet Protocol Suite. P. Almquist. July 1992. (Format: TXT, HTML) (Obsoleted by RFC2474) (Updates RFC1248, RFC1247, RFC1195, RFC1123, RFC1122, RFC1060, RFC0791) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1349) 1350 The TFTP Protocol (Revision 2). K. Sollins. July 1992. (Format: TXT, HTML) (Obsoletes RFC0783) (Updated by RFC1782, RFC1783, RFC1784, RFC1785, RFC2347, RFC2348, RFC2349) (Also STD0033) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1350) 1351 SNMP Administrative Model. J. Davin, J. Galvin, K. McCloghrie. July 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1351) 1352 SNMP Security Protocols. J. Galvin, K. McCloghrie, J. Davin. July 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1352) 1353 Definitions of Managed Objects for Administration of SNMP Parties. K. McCloghrie, J. Davin, J. Galvin. July 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1353) 1354 IP Forwarding Table MIB. F. Baker. July 1992. (Format: TXT, HTML) (Obsoleted by RFC2096) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1354) 1355 Privacy and Accuracy Issues in Network Information Center Databases. J. Curran, A. Marine. August 1992. (Format: TXT, HTML) (Also FYI0015) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1355) 1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode. A. Malis, D. Robinson, R. Ullmann. August 1992. (Format: TXT, HTML) (Obsoletes RFC0877) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1356) 1357 A Format for E-mailing Bibliographic Records. D. Cohen. July 1992. (Format: TXT, HTML) (Obsoleted by RFC1807) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1357) 1358 Charter of the Internet Architecture Board (IAB). L. Chapin. August 1992. (Format: TXT, HTML) (Obsoleted by RFC1601) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1358) 1359 Connecting to the Internet - What Connecting Institutions Should Anticipate. ACM SIGUCCS. August 1992. (Format: TXT, HTML) (Also FYI0016) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1359) 1360 IAB Official Protocol Standards. J. Postel. September 1992. (Format: TXT, HTML) (Obsoletes RFC1280) (Obsoleted by RFC1410) (Status: HISTORIC) (DOI: 10.17487/RFC1360) 1361 Simple Network Time Protocol (SNTP). D. Mills. August 1992. (Format: TXT, HTML) (Obsoleted by RFC1769) (Also RFC1305) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1361) 1362 Novell IPX over Various WAN Media (IPXWAN). M. Allen. September 1992. (Format: TXT, HTML) (Obsoleted by RFC1634) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1362) 1363 A Proposed Flow Specification. C. Partridge. September 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1363) 1364 BGP OSPF Interaction. K. Varadhan. September 1992. (Format: TXT, HTML) (Obsoleted by RFC1403) (Also RFC1247, RFC1267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1364) 1365 An IP Address Extension Proposal. K. Siyan. September 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1365) 1366 Guidelines for Management of IP Address Space. E. Gerich. October 1992. (Format: TXT, HTML) (Obsoleted by RFC1466) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1366) 1367 Schedule for IP Address Space Management Guidelines. C. Topolcic. October 1992. (Format: TXT, HTML) (Obsoleted by RFC1467) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1367) 1368 Definition of Managed Objects for IEEE 802.3 Repeater Devices. D. McMaster, K. McCloghrie. October 1992. (Format: TXT, HTML) (Obsoleted by RFC1516) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1368) 1369 Implementation Notes and Experience for the Internet Ethernet MIB. F. Kastenholz. October 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1369) 1370 Applicability Statement for OSPF. Internet Architecture Board, L. Chapin. October 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1370) 1371 Choosing a Common IGP for the IP Internet. P. Gross. October 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1371) 1372 Telnet Remote Flow Control Option. C. Hedrick, D. Borman. October 1992. (Format: TXT, HTML) (Obsoletes RFC1080) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1372) 1373 Portable DUAs. T. Tignor. October 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1373) 1374 IP and ARP on HIPPI. J. Renwick, A. Nicholson. October 1992. (Format: TXT, HTML) (Obsoleted by RFC2834) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1374) 1375 Suggestion for New Classes of IP Addresses. P. Robinson. October 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1375) 1376 The PPP DECnet Phase IV Control Protocol (DNCP). S. Senum. November 1992. (Format: TXT, HTML) (Obsoleted by RFC1762) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1376) 1377 The PPP OSI Network Layer Control Protocol (OSINLCP). D. Katz. November 1992. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1377) 1378 The PPP AppleTalk Control Protocol (ATCP). B. Parker. November 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1378) 1379 Extending TCP for Transactions -- Concepts. R. Braden. November 1992. (Format: TXT, HTML) (Obsoleted by RFC6247) (Updated by RFC1644) (Status: HISTORIC) (DOI: 10.17487/RFC1379) 1380 IESG Deliberations on Routing and Addressing. P. Gross, P. Almquist. November 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1380) 1381 SNMP MIB Extension for X.25 LAPB. D. Throop, F. Baker. November 1992. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1381) 1382 SNMP MIB Extension for the X.25 Packet Layer. D. Throop, Ed.. November 1992. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1382) 1383 An Experiment in DNS Based IP Routing. C. Huitema. December 1992. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1383) 1384 Naming Guidelines for Directory Pilots. P. Barker, S.E. Hardcastle-Kille. January 1993. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC1617, RTR0011) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1384) 1385 EIP: The Extended Internet Protocol. Z. Wang. November 1992. (Format: TXT, HTML) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1385) 1386 The US Domain. A. Cooper, J. Postel. December 1992. (Format: TXT, HTML) (Obsoleted by RFC1480) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1386) 1387 RIP Version 2 Protocol Analysis. G. Malkin. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1721) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1387) 1388 RIP Version 2 Carrying Additional Information. G. Malkin. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1723) (Updates RFC1058) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1388) 1389 RIP Version 2 MIB Extensions. G. Malkin, F. Baker. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1724) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1389) 1390 Transmission of IP and ARP over FDDI Networks. D. Katz. January 1993. (Format: TXT, HTML) (Also STD0036) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1390) 1391 The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force. G. Malkin. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1539) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1391) 1392 Internet Users' Glossary. G. Malkin, T. LaQuey Parker. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1983) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1392) 1393 Traceroute Using an IP Option. G. Malkin. January 1993. (Format: TXT, HTML) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1393) 1394 Relationship of Telex Answerback Codes to Internet Domains. P. Robinson. January 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1394) 1395 BOOTP Vendor Information Extensions. J. Reynolds. January 1993. (Format: TXT, HTML) (Obsoletes RFC1084, RFC1048) (Obsoleted by RFC1497, RFC1533) (Updates RFC0951) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1395) 1396 The Process for Organization of Internet Standards Working Group (POISED). S. Crocker. January 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1396) 1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol. D. Haskin. January 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1397) 1398 Definitions of Managed Objects for the Ethernet-Like Interface Types. F. Kastenholz. January 1993. (Format: TXT, HTML) (Obsoletes RFC1284) (Obsoleted by RFC1623) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1398) 1399 Summary of 1300-1399. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1399) 1400 Transition and Modernization of the Internet Registration Service. S. Williamson. March 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1400) 1401 Correspondence between the IAB and DISA on the use of DNS. Internet Architecture Board. January 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1401) 1402 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places. J. Martin. January 1993. (Format: TXT, HTML) (Obsoletes RFC1290) (Also FYI0010) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1402) 1403 BGP OSPF Interaction. K. Varadhan. January 1993. (Format: TXT, HTML) (Obsoletes RFC1364) (Status: HISTORIC) (DOI: 10.17487/RFC1403) 1404 A Model for Common Operational Statistics. B. Stockman. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1857) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1404) 1405 Mapping between X.400(1984/1988) and Mail-11 (DECnet mail). C. Allocchio. January 1993. (Format: TXT, HTML) (Obsoleted by RFC2162) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1405) 1406 Definitions of Managed Objects for the DS1 and E1 Interface Types. F. Baker, Ed., J. Watt, Ed.. January 1993. (Format: TXT, HTML) (Obsoletes RFC1232) (Obsoleted by RFC2495) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1406) 1407 Definitions of Managed Objects for the DS3/E3 Interface Type. T. Cox, K. Tesink. January 1993. (Format: TXT, HTML) (Obsoletes RFC1233) (Obsoleted by RFC2496) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1407) 1408 Telnet Environment Option. D. Borman, Ed.. January 1993. (Format: TXT, HTML) (Updated by RFC1571) (Status: HISTORIC) (DOI: 10.17487/RFC1408) 1409 Telnet Authentication Option. D. Borman, Ed.. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1416) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1409) 1410 IAB Official Protocol Standards. J. Postel, Ed.. March 1993. (Format: TXT, HTML) (Obsoletes RFC1360) (Obsoleted by RFC1500) (Status: HISTORIC) (DOI: 10.17487/RFC1410) 1411 Telnet Authentication: Kerberos Version 4. D. Borman, Ed.. January 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1411) 1412 Telnet Authentication: SPX. K. Alagappan. January 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1412) 1413 Identification Protocol. M. St. Johns. February 1993. (Format: TXT, HTML) (Obsoletes RFC0931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1413) 1414 Identification MIB. M. St. Johns, M. Rose. February 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1414) 1415 FTP-FTAM Gateway Specification. J. Mindel, R. Slaski. January 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1415) 1416 Telnet Authentication Option. D. Borman, Ed.. February 1993. (Format: TXT, HTML) (Obsoletes RFC1409) (Obsoleted by RFC2941) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1416) 1417 NADF Standing Documents: A Brief Overview. The North American Directory Forum. February 1993. (Format: TXT, HTML) (Obsoletes RFC1295, RFC1255, RFC1218) (Obsoleted by RFC1758) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1417) 1418 SNMP over OSI. M. Rose. March 1993. (Format: TXT, HTML) (Obsoletes RFC1161, RFC1283) (Status: HISTORIC) (DOI: 10.17487/RFC1418) 1419 SNMP over AppleTalk. G. Minshall, M. Ritter. March 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1419) 1420 SNMP over IPX. S. Bostock. March 1993. (Format: TXT, HTML) (Obsoletes RFC1298) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1420) 1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures. J. Linn. February 1993. (Format: TXT, HTML) (Obsoletes RFC1113) (Status: HISTORIC) (DOI: 10.17487/RFC1421) 1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management. S. Kent. February 1993. (Format: TXT, HTML) (Obsoletes RFC1114) (Status: HISTORIC) (DOI: 10.17487/RFC1422) 1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers. D. Balenson. February 1993. (Format: TXT, HTML) (Obsoletes RFC1115) (Status: HISTORIC) (DOI: 10.17487/RFC1423) 1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services. B. Kaliski. February 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1424) 1425 SMTP Service Extensions. J. Klensin, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. February 1993. (Format: TXT, HTML) (Obsoleted by RFC1651) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1425) 1426 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. February 1993. (Format: TXT, HTML) (Obsoleted by RFC1652) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1426) 1427 SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, Ed., K. Moore. February 1993. (Format: TXT, HTML) (Obsoleted by RFC1653) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1427) 1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME. G. Vaudreuil. February 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1428) 1429 Listserv Distribute Protocol. E. Thomas. February 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1429) 1430 A Strategic Plan for Deploying an Internet X.500 Directory Service. S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby, S. Kent. February 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1430) 1431 DUA Metrics (OSI-DS 33 (v2)). P. Barker. February 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1431) 1432 Recent Internet Books. J. Quarterman. March 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1432) 1433 Directed ARP. J. Garrett, J. Hagan, J. Wong. March 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1433) 1434 Data Link Switching: Switch-to-Switch Protocol. R. Dixon, D. Kushi. March 1993. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC1795) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1434) 1435 IESG Advice from Experience with Path MTU Discovery. S. Knowles. March 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1435) 1436 The Internet Gopher Protocol (a distributed document search and retrieval protocol). F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, B. Albert. March 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1436) 1437 The Extension of MIME Content-Types to a New Medium. N. Borenstein, M. Linimon. 1 April 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1437) 1438 Internet Engineering Task Force Statements Of Boredom (SOBs). A. Lyman Chapin, C. Huitema. 1 April 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1438) 1439 The Uniqueness of Unique Identifiers. C. Finseth. March 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1439) 1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer. R. Troth. July 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1440) 1441 Introduction to version 2 of the Internet-standard Network Management Framework. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1441) 1442 Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Obsoleted by RFC1902) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1442) 1443 Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Obsoleted by RFC1903) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1443) 1444 Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Obsoleted by RFC1904) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1444) 1445 Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2). J. Galvin, K. McCloghrie. April 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1445) 1446 Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2). J. Galvin, K. McCloghrie. April 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1446) 1447 Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2). K. McCloghrie, J. Galvin. April 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1447) 1448 Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Obsoleted by RFC1905) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1448) 1449 Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Obsoleted by RFC1906) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1449) 1450 Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Obsoleted by RFC1907) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1450) 1451 Manager-to-Manager Management Information Base. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1451) 1452 Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Obsoleted by RFC1908) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1452) 1453 A Comment on Packet Video Remote Conferencing and the Transport/Network Layers. W. Chimiak. April 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1453) 1454 Comparison of Proposals for Next Version of IP. T. Dixon. May 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1454) 1455 Physical Link Security Type of Service. D. Eastlake 3rd. May 1993. (Format: TXT, HTML) (Obsoleted by RFC2474) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1455) 1456 Conventions for Encoding the Vietnamese Language VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification. Vietnamese Standardization Working Group. May 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1456) 1457 Security Label Framework for the Internet. R. Housley. May 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1457) 1458 Requirements for Multicast Protocols. R. Braudes, S. Zabele. May 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1458) 1459 Internet Relay Chat Protocol. J. Oikarinen, D. Reed. May 1993. (Format: TXT, HTML) (Updated by RFC2810, RFC2811, RFC2812, RFC2813, RFC7194) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1459) 1460 Post Office Protocol - Version 3. M. Rose. June 1993. (Format: TXT, HTML) (Obsoletes RFC1225) (Obsoleted by RFC1725) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1460) 1461 SNMP MIB extension for Multiprotocol Interconnect over X.25. D. Throop. May 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1461) 1462 FYI on "What is the Internet?". E. Krol, E. Hoffman. May 1993. (Format: TXT, HTML) (Also FYI0020) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1462) 1463 FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings. E. Hoffman, L. Jackson. May 1993. (Format: TXT, HTML) (Also FYI0019) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1463) 1464 Using the Domain Name System To Store Arbitrary String Attributes. R. Rosenbaum. May 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1464) 1465 Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing. D. Eppenberger. May 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1465) 1466 Guidelines for Management of IP Address Space. E. Gerich. May 1993. (Format: TXT, HTML) (Obsoletes RFC1366) (Obsoleted by RFC2050) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1466) 1467 Status of CIDR Deployment in the Internet. C. Topolcic. August 1993. (Format: TXT, HTML) (Obsoletes RFC1367) (Status: HISTORIC) (DOI: 10.17487/RFC1467) 1468 Japanese Character Encoding for Internet Messages. J. Murai, M. Crispin, E. van der Poel. June 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1468) 1469 IP Multicast over Token-Ring Local Area Networks. T. Pusateri. June 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1469) 1470 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices. R. Enger, J. Reynolds. June 1993. (Format: TXT, HTML) (Obsoletes RFC1147) (Also FYI0002) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1470) 1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol. F. Kastenholz. June 1993. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1471) 1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol. F. Kastenholz. June 1993. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1472) 1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol. F. Kastenholz. June 1993. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1473) 1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol. F. Kastenholz. June 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1474) 1475 TP/IX: The Next Internet. R. Ullmann. June 1993. (Format: TXT, HTML) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1475) 1476 RAP: Internet Route Access Protocol. R. Ullmann. June 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1476) 1477 IDPR as a Proposed Standard. M. Steenstrup. July 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1477) 1478 An Architecture for Inter-Domain Policy Routing. M. Steenstrup. June 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1478) 1479 Inter-Domain Policy Routing Protocol Specification: Version 1. M. Steenstrup. July 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1479) 1480 The US Domain. A. Cooper, J. Postel. June 1993. (Format: TXT, HTML) (Obsoletes RFC1386) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1480) 1481 IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling. C. Huitema. July 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1481) 1482 Aggregation Support in the NSFNET Policy-Based Routing Database. M. Knopper, S. Richardson. June 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1482) 1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5. J. Heinanen. July 1993. (Format: TXT, HTML) (Obsoleted by RFC2684) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1483) 1484 Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2)). S. Hardcastle-Kille. July 1993. (Format: TXT, HTML) (Obsoleted by RFC1781, RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1484) 1485 A String Representation of Distinguished Names (OSI-DS 23 (v5)). S. Hardcastle-Kille. July 1993. (Format: TXT, HTML) (Obsoleted by RFC1779, RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1485) 1486 An Experiment in Remote Printing. M. Rose, C. Malamud. July 1993. (Format: TXT, HTML) (Obsoleted by RFC1528, RFC1529) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1486) 1487 X.500 Lightweight Directory Access Protocol. W. Yeong, T. Howes, S. Kille. July 1993. (Format: TXT, HTML) (Obsoleted by RFC1777, RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1487) 1488 The X.500 String Representation of Standard Attribute Syntaxes. T. Howes, S. Kille, W. Yeong, C. Robbins. July 1993. (Format: TXT, HTML) (Obsoleted by RFC1778) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1488) 1489 Registration of a Cyrillic Character Set. A. Chernov. July 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1489) 1490 Multiprotocol Interconnect over Frame Relay. T. Bradley, C. Brown, A. Malis. July 1993. (Format: TXT, HTML) (Obsoletes RFC1294) (Obsoleted by RFC2427) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1490) 1491 A Survey of Advanced Usages of X.500. C. Weider, R. Wright. July 1993. (Format: TXT, HTML) (Also FYI0021) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1491) 1492 An Access Control Protocol, Sometimes Called TACACS. C. Finseth. July 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1492) 1493 Definitions of Managed Objects for Bridges. E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie. July 1993. (Format: TXT, HTML) (Obsoletes RFC1286) (Obsoleted by RFC4188) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1493) 1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies. H. Alvestrand, S. Thompson. August 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1494) 1495 Mapping between X.400 and RFC-822 Message Bodies. H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson. August 1993. (Format: TXT, HTML) (Obsoleted by RFC2156) (Updates RFC1327) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1495) 1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages. H. Alvestrand, J. Romaguera, K. Jordan. August 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1496) 1497 BOOTP Vendor Information Extensions. J. Reynolds. August 1993. (Format: TXT, HTML) (Obsoletes RFC1395, RFC1084, RFC1048) (Obsoleted by RFC1533) (Updates RFC0951) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1497) 1498 On the Naming and Binding of Network Destinations. J. Saltzer. August 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1498) 1499 Summary of 1400-1499. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1499) 1500 Internet Official Protocol Standards. J. Postel. August 1993. (Format: TXT, HTML) (Obsoletes RFC1410) (Obsoleted by RFC1540) (Status: HISTORIC) (DOI: 10.17487/RFC1500) 1501 OS/2 User Group. E. Brunsen. August 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1501) 1502 X.400 Use of Extended Character Sets. H. Alvestrand. August 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1502) 1503 Algorithms for Automating Administration in SNMPv2 Managers. K. McCloghrie, M. Rose. August 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1503) 1504 Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing. A. Oppenheimer. August 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1504) 1505 Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, R. Ullmann. August 1993. (Format: TXT, HTML) (Obsoletes RFC1154) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1505) 1506 A Tutorial on Gatewaying between X.400 and Internet Mail. J. Houttuin. August 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1506) 1507 DASS - Distributed Authentication Security Service. C. Kaufman. September 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1507) 1508 Generic Security Service Application Program Interface. J. Linn. September 1993. (Format: TXT, HTML) (Obsoleted by RFC2078) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1508) 1509 Generic Security Service API : C-bindings. J. Wray. September 1993. (Format: TXT, HTML) (Obsoleted by RFC2744) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1509) 1510 The Kerberos Network Authentication Service (V5). J. Kohl, C. Neuman. September 1993. (Format: TXT, HTML) (Obsoleted by RFC4120, RFC6649) (Status: HISTORIC) (DOI: 10.17487/RFC1510) 1511 Common Authentication Technology Overview. J. Linn. September 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1511) 1512 FDDI Management Information Base. J. Case, A. Rijsinghani. September 1993. (Format: TXT, HTML) (Updates RFC1285) (Status: HISTORIC) (DOI: 10.17487/RFC1512) 1513 Token Ring Extensions to the Remote Network Monitoring MIB. S. Waldbusser. September 1993. (Format: TXT, HTML) (Updates RFC1271) (Status: HISTORIC) (DOI: 10.17487/RFC1513) 1514 Host Resources MIB. P. Grillo, S. Waldbusser. September 1993. (Format: TXT, HTML) (Obsoleted by RFC2790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1514) 1515 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs). D. McMaster, K. McCloghrie, S. Roberts. September 1993. (Format: TXT, HTML) (Obsoleted by RFC3636) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1515) 1516 Definitions of Managed Objects for IEEE 802.3 Repeater Devices. D. McMaster, K. McCloghrie. September 1993. (Format: TXT, HTML) (Obsoletes RFC1368) (Obsoleted by RFC2108) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1516) 1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR). Internet Engineering Steering Group, R. Hinden. September 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1517) 1518 An Architecture for IP Address Allocation with CIDR. Y. Rekhter, T. Li. September 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1518) 1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. September 1993. (Format: TXT, HTML) (Obsoletes RFC1338) (Obsoleted by RFC4632) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1519) 1520 Exchanging Routing Information Across Provider Boundaries in the CIDR Environment. Y. Rekhter, C. Topolcic. September 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1520) 1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. N. Borenstein, N. Freed. September 1993. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1341) (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) (Updated by RFC1590) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1521) 1522 MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text. K. Moore. September 1993. (Format: TXT, HTML) (Obsoletes RFC1342) (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1522) 1523 The text/enriched MIME Content-type. N. Borenstein. September 1993. (Format: TXT, HTML) (Obsoleted by RFC1563, RFC1896) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1523) 1524 A User Agent Configuration Mechanism For Multimedia Mail Format Information. N. Borenstein. September 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1524) 1525 Definitions of Managed Objects for Source Routing Bridges. E. Decker, K. McCloghrie, P. Langille, A. Rijsinghani. September 1993. (Format: TXT, HTML) (Obsoletes RFC1286) (Status: HISTORIC) (DOI: 10.17487/RFC1525) 1526 Assignment of System Identifiers for TUBA/CLNP Hosts. D. Piscitello. September 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1526) 1527 What Should We Plan Given the Dilemma of the Network?. G. Cook. September 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1527) 1528 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures. C. Malamud, M. Rose. October 1993. (Format: TXT, HTML) (Obsoletes RFC1486) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1528) 1529 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies. C. Malamud, M. Rose. October 1993. (Format: TXT, HTML) (Obsoletes RFC1486) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1529) 1530 Principles of Operation for the TPC.INT Subdomain: General Principles and Policy. C. Malamud, M. Rose. October 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1530) 1531 Dynamic Host Configuration Protocol. R. Droms. October 1993. (Format: TXT, HTML) (Obsoleted by RFC1541) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1531) 1532 Clarifications and Extensions for the Bootstrap Protocol. W. Wimer. October 1993. (Format: TXT, HTML) (Obsoleted by RFC1542) (Updates RFC0951) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1532) 1533 DHCP Options and BOOTP Vendor Extensions. S. Alexander, R. Droms. October 1993. (Format: TXT, HTML) (Obsoletes RFC1497, RFC1395, RFC1084, RFC1048) (Obsoleted by RFC2132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1533) 1534 Interoperation Between DHCP and BOOTP. R. Droms. October 1993. (Format: TXT, HTML) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1534) 1535 A Security Problem and Proposed Correction With Widely Deployed DNS Software. E. Gavron. October 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1535) 1536 Common DNS Implementation Errors and Suggested Fixes. A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller. October 1993. (Format: TXT, HTML) (Updated by RFC9210) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1536) 1537 Common DNS Data File Configuration Errors. P. Beertema. October 1993. (Format: TXT, HTML) (Obsoleted by RFC1912) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1537) 1538 Advanced SNA/IP : A Simple SNA Transport Protocol. W. Behl, B. Sterling, W. Teskey. October 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1538) 1539 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force. G. Malkin. October 1993. (Format: TXT, HTML) (Obsoletes RFC1391) (Obsoleted by RFC1718) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1539) 1540 Internet Official Protocol Standards. J. Postel. October 1993. (Format: TXT, HTML) (Obsoletes RFC1500) (Obsoleted by RFC1600) (Status: HISTORIC) (DOI: 10.17487/RFC1540) 1541 Dynamic Host Configuration Protocol. R. Droms. October 1993. (Format: TXT, HTML) (Obsoletes RFC1531) (Obsoleted by RFC2131) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1541) 1542 Clarifications and Extensions for the Bootstrap Protocol. W. Wimer. October 1993. (Format: TXT, HTML) (Obsoletes RFC1532) (Updates RFC0951) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1542) 1543 Instructions to RFC Authors. J. Postel. October 1993. (Format: TXT, HTML) (Obsoletes RFC1111, RFC0825) (Obsoleted by RFC2223) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1543) 1544 The Content-MD5 Header Field. M. Rose. November 1993. (Format: TXT, HTML) (Obsoleted by RFC1864) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1544) 1545 FTP Operation Over Big Address Records (FOOBAR). D. Piscitello. November 1993. (Format: TXT, HTML) (Obsoleted by RFC1639) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1545) 1546 Host Anycasting Service. C. Partridge, T. Mendez, W. Milliken. November 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1546) 1547 Requirements for an Internet Standard Point-to-Point Protocol. D. Perkins. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1547) 1548 The Point-to-Point Protocol (PPP). W. Simpson. December 1993. (Format: TXT, HTML) (Obsoletes RFC1331) (Obsoleted by RFC1661) (Updated by RFC1570) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1548) 1549 PPP in HDLC Framing. W. Simpson, Ed.. December 1993. (Format: TXT, HTML) (Obsoleted by RFC1662) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1549) 1550 IP: Next Generation (IPng) White Paper Solicitation. S. Bradner, A. Mankin. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1550) 1551 Novell IPX Over Various WAN Media (IPXWAN). M. Allen. December 1993. (Format: TXT, HTML) (Obsoleted by RFC1634) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1551) 1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP). W. Simpson. December 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1552) 1553 Compressing IPX Headers Over WAN Media (CIPX). S. Mathur, M. Lewis. December 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1553) 1554 ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP. M. Ohta, K. Handa. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1554) 1555 Hebrew Character Encoding for Internet Messages. H. Nussbacher, Y. Bourvine. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1555) 1556 Handling of Bi-directional Texts in MIME. H. Nussbacher. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1556) 1557 Korean Character Encoding for Internet Messages. U. Choi, K. Chon, H. Park. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1557) 1558 A String Representation of LDAP Search Filters. T. Howes. December 1993. (Format: TXT, HTML) (Obsoleted by RFC1960) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1558) 1559 DECnet Phase IV MIB Extensions. J. Saperia. December 1993. (Format: TXT, HTML) (Obsoletes RFC1289) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1559) 1560 The MultiProtocol Internet. B. Leiner, Y. Rekhter. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1560) 1561 Use of ISO CLNP in TUBA Environments. D. Piscitello. December 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1561) 1562 Naming Guidelines for the AARNet X.500 Directory Service. G. Michaelson, M. Prior. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1562) 1563 The text/enriched MIME Content-type. N. Borenstein. January 1994. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1523) (Obsoleted by RFC1896) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1563) 1564 DSA Metrics (OSI-DS 34 (v3)). P. Barker, R. Hedberg. January 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1564) 1565 Network Services Monitoring MIB. S. Kille, N. Freed. January 1994. (Format: TXT, HTML) (Obsoleted by RFC2248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1565) 1566 Mail Monitoring MIB. S. Kille, N. Freed. January 1994. (Format: TXT, HTML) (Obsoleted by RFC2249, RFC2789) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1566) 1567 X.500 Directory Monitoring MIB. G. Mansfield, S. Kille. January 1994. (Format: TXT, HTML) (Obsoleted by RFC2605) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1567) 1568 Simple Network Paging Protocol - Version 1(b). A. Gwinn. January 1994. (Format: TXT, HTML) (Obsoleted by RFC1645) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1568) 1569 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures. M. Rose. January 1994. (Format: TXT, HTML) (Obsoleted by RFC1703) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1569) 1570 PPP LCP Extensions. W. Simpson, Ed.. January 1994. (Format: TXT, HTML) (Updates RFC1548) (Updated by RFC2484) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1570) 1571 Telnet Environment Option Interoperability Issues. D. Borman. January 1994. (Format: TXT, HTML) (Updates RFC1408) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1571) 1572 Telnet Environment Option. S. Alexander, Ed.. January 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1572) 1573 Evolution of the Interfaces Group of MIB-II. K. McCloghrie, F. Kastenholz. January 1994. (Format: TXT, HTML) (Obsoletes RFC1229) (Obsoleted by RFC2233) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1573) 1574 Essential Tools for the OSI Internet. S. Hares, C. Wittbrodt. February 1994. (Format: TXT, HTML) (Obsoletes RFC1139) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1574) 1575 An Echo Function for CLNP (ISO 8473). S. Hares, C. Wittbrodt. February 1994. (Format: TXT, HTML) (Obsoletes RFC1139) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1575) 1576 TN3270 Current Practices. J. Penner. January 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1576) 1577 Classical IP and ARP over ATM. M. Laubach. January 1994. (Format: TXT, HTML) (Obsoleted by RFC2225) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1577) 1578 FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions. J. Sellers. February 1994. (Format: TXT, HTML) (Obsoleted by RFC1941) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1578) 1579 Firewall-Friendly FTP. S. Bellovin. February 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1579) 1580 Guide to Network Resource Tools. EARN Staff. March 1994. (Format: TXT, HTML) (Also FYI0023) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1580) 1581 Protocol Analysis for Extensions to RIP to Support Demand Circuits. G. Meyer. February 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1581) 1582 Extensions to RIP to Support Demand Circuits. G. Meyer. February 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1582) 1583 OSPF Version 2. J. Moy. March 1994. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1247) (Obsoleted by RFC2178) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1583) 1584 Multicast Extensions to OSPF. J. Moy. March 1994. (Format: TXT, PS, PDF, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1584) 1585 MOSPF: Analysis and Experience. J. Moy. March 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1585) 1586 Guidelines for Running OSPF Over Frame Relay Networks. O. deSouza, M. Rodrigues. March 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1586) 1587 The OSPF NSSA Option. R. Coltun, V. Fuller. March 1994. (Format: TXT, HTML) (Obsoleted by RFC3101) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1587) 1588 White Pages Meeting Report. J. Postel, C. Anderson. February 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1588) 1589 A Kernel Model for Precision Timekeeping. D. Mills. March 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1589) 1590 Media Type Registration Procedure. J. Postel. March 1994. (Format: TXT, HTML) (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) (Updates RFC1521) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1590) 1591 Domain Name System Structure and Delegation. J. Postel. March 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1591) 1592 Simple Network Management Protocol Distributed Protocol Interface Version 2.0. B. Wijnen, G. Carpenter, K. Curran, A. Sehgal, G. Waters. March 1994. (Format: TXT, HTML) (Obsoletes RFC1228) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1592) 1593 SNA APPN Node MIB. W. McKenzie, J. Cheng. March 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1593) 1594 FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions. A. Marine, J. Reynolds, G. Malkin. March 1994. (Format: TXT, HTML) (Obsoletes RFC1325) (Obsoleted by RFC2664) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1594) 1595 Definitions of Managed Objects for the SONET/SDH Interface Type. T. Brown, K. Tesink. March 1994. (Format: TXT, HTML) (Obsoleted by RFC2558) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1595) 1596 Definitions of Managed Objects for Frame Relay Service. T. Brown, Ed.. March 1994. (Format: TXT, HTML) (Obsoleted by RFC1604) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1596) 1597 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot. March 1994. (Format: TXT, HTML) (Obsoleted by RFC1918) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1597) 1598 PPP in X.25. W. Simpson. March 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1598) 1599 Summary of 1500-1599. M. Kennedy. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1599) 1600 Internet Official Protocol Standards. J. Postel. March 1994. (Format: TXT, HTML) (Obsoletes RFC1540) (Obsoleted by RFC1610) (Status: HISTORIC) (DOI: 10.17487/RFC1600) 1601 Charter of the Internet Architecture Board (IAB). C. Huitema. March 1994. (Format: TXT, HTML) (Obsoletes RFC1358) (Obsoleted by RFC2850) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1601) 1602 The Internet Standards Process -- Revision 2. Internet Architecture Board, Internet Engineering Steering Group. March 1994. (Format: TXT, HTML) (Obsoletes RFC1310) (Obsoleted by RFC2026) (Updated by RFC1871) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1602) 1603 IETF Working Group Guidelines and Procedures. E. Huizer, D. Crocker. March 1994. (Format: TXT, HTML) (Obsoleted by RFC2418) (Updated by RFC1871) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1603) 1604 Definitions of Managed Objects for Frame Relay Service. T. Brown, Ed.. March 1994. (Format: TXT, HTML) (Obsoletes RFC1596) (Obsoleted by RFC2954) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1604) 1605 SONET to Sonnet Translation. W. Shakespeare. 1 April 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1605) 1606 A Historical Perspective On The Usage Of IP Version 9. J. Onions. 1 April 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1606) 1607 A VIEW FROM THE 21ST CENTURY. V. Cerf. 1 April 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1607) 1608 Representing IP Information in the X.500 Directory. T. Johannsen, G. Mansfield, M. Kosters, S. Sataluri. March 1994. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1608) 1609 Charting Networks in the X.500 Directory. G. Mansfield, T. Johannsen, M. Knopper. March 1994. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1609) 1610 Internet Official Protocol Standards. J. Postel. July 1994. (Format: TXT, HTML) (Obsoletes RFC1600) (Obsoleted by RFC1720) (Status: HISTORIC) (DOI: 10.17487/RFC1610) 1611 DNS Server MIB Extensions. R. Austein, J. Saperia. May 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1611) 1612 DNS Resolver MIB Extensions. R. Austein, J. Saperia. May 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1612) 1613 cisco Systems X.25 over TCP (XOT). J. Forster, G. Satz, G. Glick, R. Day. May 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1613) 1614 Network Access to Multimedia Information. C. Adie. May 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1614) 1615 Migrating from X.400(84) to X.400(88). J. Houttuin, J. Craigie. May 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1615) 1616 X.400(1988) for the Academic and Research Community in Europe. RARE WG-MSG Task Force 88, E. Huizer, Ed., J. Romaguera, Ed.. May 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1616) 1617 Naming and Structuring Guidelines for X.500 Directory Pilots. P. Barker, S. Kille, T. Lenggenhager. May 1994. (Format: TXT, HTML) (Obsoletes RFC1384) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1617) 1618 PPP over ISDN. W. Simpson. May 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1618) 1619 PPP over SONET/SDH. W. Simpson. May 1994. (Format: TXT, HTML) (Obsoleted by RFC2615) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1619) 1620 Internet Architecture Extensions for Shared Media. B. Braden, J. Postel, Y. Rekhter. May 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1620) 1621 Pip Near-term Architecture. P. Francis. May 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1621) 1622 Pip Header Processing. P. Francis. May 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1622) 1623 Definitions of Managed Objects for the Ethernet-like Interface Types. F. Kastenholz. May 1994. (Format: TXT, HTML) (Obsoletes RFC1398) (Obsoleted by RFC1643) (Status: HISTORIC) (DOI: 10.17487/RFC1623) 1624 Computation of the Internet Checksum via Incremental Update. A. Rijsinghani, Ed.. May 1994. (Format: TXT, HTML) (Updates RFC1141) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1624) 1625 WAIS over Z39.50-1988. M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman, B. Kahle, J. Kunze, H. Morris, F. Schiettecatte. June 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1625) 1626 Default IP MTU for use over ATM AAL5. R. Atkinson. May 1994. (Format: TXT, HTML) (Obsoleted by RFC2225) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1626) 1627 Network 10 Considered Harmful (Some Practices Shouldn't be Codified). E. Lear, E. Fair, D. Crocker, T. Kessler. July 1994. (Format: TXT, HTML) (Obsoleted by RFC1918) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1627) 1628 UPS Management Information Base. J. Case, Ed.. May 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1628) 1629 Guidelines for OSI NSAP Allocation in the Internet. R. Colella, R. Callon, E. Gardner, Y. Rekhter. May 1994. (Format: TXT, HTML) (Obsoletes RFC1237) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1629) 1630 Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web. T. Berners-Lee. June 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1630) 1631 The IP Network Address Translator (NAT). K. Egevang, P. Francis. May 1994. (Format: TXT, HTML) (Obsoleted by RFC3022) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1631) 1632 A Revised Catalog of Available X.500 Implementations. A. Getchell, Ed., S. Sataluri, Ed.. May 1994. (Format: TXT, HTML) (Obsoletes RFC1292) (Obsoleted by RFC2116) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1632) 1633 Integrated Services in the Internet Architecture: an Overview. R. Braden, D. Clark, S. Shenker. June 1994. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1633) 1634 Novell IPX Over Various WAN Media (IPXWAN). M. Allen. May 1994. (Format: TXT, HTML) (Obsoletes RFC1551, RFC1362) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1634) 1635 How to Use Anonymous FTP. P. Deutsch, A. Emtage, A. Marine. May 1994. (Format: TXT, HTML) (Also FYI0024) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1635) 1636 Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994. R. Braden, D. Clark, S. Crocker, C. Huitema. June 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1636) 1637 DNS NSAP Resource Records. B. Manning, R. Colella. June 1994. (Format: TXT, HTML) (Obsoletes RFC1348) (Obsoleted by RFC1706) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1637) 1638 PPP Bridging Control Protocol (BCP). F. Baker, R. Bowen. June 1994. (Format: TXT, HTML) (Obsoletes RFC1220) (Obsoleted by RFC2878) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1638) 1639 FTP Operation Over Big Address Records (FOOBAR). D. Piscitello. June 1994. (Format: TXT, HTML) (Obsoletes RFC1545) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1639) 1640 The Process for Organization of Internet Standards Working Group (POISED). S. Crocker. June 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1640) 1641 Using Unicode with MIME. D. Goldsmith, M. Davis. July 1994. (Format: TXT, PS, PDF, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1641) 1642 UTF-7 - A Mail-Safe Transformation Format of Unicode. D. Goldsmith, M. Davis. July 1994. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC2152) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1642) 1643 Definitions of Managed Objects for the Ethernet-like Interface Types. F. Kastenholz. July 1994. (Format: TXT, HTML) (Obsoletes RFC1623) (Obsoleted by RFC3638) (Status: HISTORIC) (DOI: 10.17487/RFC1643) 1644 T/TCP -- TCP Extensions for Transactions Functional Specification. R. Braden. July 1994. (Format: TXT, HTML) (Obsoleted by RFC6247) (Updates RFC1379) (Status: HISTORIC) (DOI: 10.17487/RFC1644) 1645 Simple Network Paging Protocol - Version 2. A. Gwinn. July 1994. (Format: TXT, HTML) (Obsoletes RFC1568) (Obsoleted by RFC1861) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1645) 1646 TN3270 Extensions for LUname and Printer Selection. C. Graves, T. Butts, M. Angel. July 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1646) 1647 TN3270 Enhancements. B. Kelly. July 1994. (Format: TXT, HTML) (Obsoleted by RFC2355) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1647) 1648 Postmaster Convention for X.400 Operations. A. Cargille. July 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1648) 1649 Operational Requirements for X.400 Management Domains in the GO-MHS Community. R. Hagens, A. Hansen. July 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1649) 1650 Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2. F. Kastenholz. August 1994. (Format: TXT, HTML) (Obsoleted by RFC2358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1650) 1651 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. July 1994. (Format: TXT, HTML) (Obsoletes RFC1425) (Obsoleted by RFC1869) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1651) 1652 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. July 1994. (Format: TXT, HTML) (Obsoletes RFC1426) (Obsoleted by RFC6152) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1652) 1653 SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, K. Moore. July 1994. (Format: TXT, HTML) (Obsoletes RFC1427) (Obsoleted by RFC1870) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1653) 1654 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, Ed., T. Li, Ed.. July 1994. (Format: TXT, HTML) (Obsoleted by RFC1771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1654) 1655 Application of the Border Gateway Protocol in the Internet. Y. Rekhter, Ed., P. Gross, Ed.. July 1994. (Format: TXT, HTML) (Obsoletes RFC1268) (Obsoleted by RFC1772) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1655) 1656 BGP-4 Protocol Document Roadmap and Implementation Experience. P. Traina. July 1994. (Format: TXT, HTML) (Obsoleted by RFC1773) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1656) 1657 Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2. S. Willis, J. Burruss, J. Chu, Ed.. July 1994. (Format: TXT, HTML) (Obsoleted by RFC4273) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1657) 1658 Definitions of Managed Objects for Character Stream Devices using SMIv2. B. Stewart. July 1994. (Format: TXT, HTML) (Obsoletes RFC1316) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1658) 1659 Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2. B. Stewart. July 1994. (Format: TXT, HTML) (Obsoletes RFC1317) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1659) 1660 Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2. B. Stewart. July 1994. (Format: TXT, HTML) (Obsoletes RFC1318) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1660) 1661 The Point-to-Point Protocol (PPP). W. Simpson, Ed.. July 1994. (Format: TXT, HTML) (Obsoletes RFC1548) (Updated by RFC2153) (Also STD0051) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1661) 1662 PPP in HDLC-like Framing. W. Simpson, Ed.. July 1994. (Format: TXT, HTML) (Obsoletes RFC1549) (Also STD0051) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1662) 1663 PPP Reliable Transmission. D. Rand. July 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1663) 1664 Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables. C. Allocchio, A. Bonito, B. Cole, S. Giordano, R. Hagens. August 1994. (Format: TXT, HTML) (Obsoleted by RFC2163) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1664) 1665 Definitions of Managed Objects for SNA NAUs using SMIv2. Z. Kielczewski, Ed., D. Kostick, Ed., K. Shih, Ed.. July 1994. (Format: TXT, HTML) (Obsoleted by RFC1666) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1665) 1666 Definitions of Managed Objects for SNA NAUs using SMIv2. Z. Kielczewski, Ed., D. Kostick, Ed., K. Shih, Ed.. August 1994. (Format: TXT, HTML) (Obsoletes RFC1665) (Status: HISTORIC) (DOI: 10.17487/RFC1666) 1667 Modeling and Simulation Requirements for IPng. S. Symington, D. Wood, M. Pullen. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1667) 1668 Unified Routing Requirements for IPng. D. Estrin, T. Li, Y. Rekhter. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1668) 1669 Market Viability as a IPng Criteria. J. Curran. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1669) 1670 Input to IPng Engineering Considerations. D. Heagerty. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1670) 1671 IPng White Paper on Transition and Other Considerations. B. Carpenter. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1671) 1672 Accounting Requirements for IPng. N. Brownlee. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1672) 1673 Electric Power Research Institute Comments on IPng. R. Skelton. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1673) 1674 A Cellular Industry View of IPng. M. Taylor. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1674) 1675 Security Concerns for IPng. S. Bellovin. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1675) 1676 INFN Requirements for an IPng. A. Ghiselli, D. Salomoni, C. Vistoli. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1676) 1677 Tactical Radio Frequency Communication Requirements for IPng. B. Adamson. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1677) 1678 IPng Requirements of Large Corporate Networks. E. Britton, J. Tavs. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1678) 1679 HPN Working Group Input to the IPng Requirements Solicitation. D. Green, P. Irey, D. Marlow, K. O'Donoghue. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1679) 1680 IPng Support for ATM Services. C. Brazdziunas. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1680) 1681 On Many Addresses per Host. S. Bellovin. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1681) 1682 IPng BSD Host Implementation Analysis. J. Bound. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1682) 1683 Multiprotocol Interoperability In IPng. R. Clark, M. Ammar, K. Calvert. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1683) 1684 Introduction to White Pages Services based on X.500. P. Jurg. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1684) 1685 Writing X.400 O/R Names. H. Alvestrand. August 1994. (Format: TXT, HTML) (Also RTR0012) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1685) 1686 IPng Requirements: A Cable Television Industry Viewpoint. M. Vecchi. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1686) 1687 A Large Corporate User's View of IPng. E. Fleischman. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1687) 1688 IPng Mobility Considerations. W. Simpson. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1688) 1689 A Status Report on Networked Information Retrieval: Tools and Groups. J. Foster, Ed.. August 1994. (Format: TXT, HTML) (Also FYI0025) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1689) 1690 Introducing the Internet Engineering and Planning Group (IEPG). G. Huston. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1690) 1691 The Document Architecture for the Cornell Digital Library. W. Turner. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1691) 1692 Transport Multiplexing Protocol (TMux). P. Cameron, D. Crocker, D. Cohen, J. Postel. August 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1692) 1693 An Extension to TCP : Partial Order Service. T. Connolly, P. Amer, P. Conrad. November 1994. (Format: TXT, HTML) (Obsoleted by RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1693) 1694 Definitions of Managed Objects for SMDS Interfaces using SMIv2. T. Brown, Ed., K. Tesink, Ed.. August 1994. (Format: TXT, HTML) (Obsoletes RFC1304) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1694) 1695 Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2. M. Ahmed, Ed., K. Tesink, Ed.. August 1994. (Format: TXT, HTML) (Obsoleted by RFC2515) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1695) 1696 Modem Management Information Base (MIB) using SMIv2. J. Barnes, L. Brown, R. Royston, S. Waldbusser. August 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1696) 1697 Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2. D. Brower, Ed., B. Purvy, A. Daniel, M. Sinykin, J. Smith. August 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1697) 1698 Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications. P. Furniss. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1698) 1699 Summary of 1600-1699. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1699) 1700 Assigned Numbers. J. Reynolds, J. Postel. October 1994. (Format: TXT, HTML) (Obsoletes RFC1340) (Obsoleted by RFC3232) (Status: HISTORIC) (DOI: 10.17487/RFC1700) 1701 Generic Routing Encapsulation (GRE). S. Hanks, T. Li, D. Farinacci, P. Traina. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1701) 1702 Generic Routing Encapsulation over IPv4 networks. S. Hanks, T. Li, D. Farinacci, P. Traina. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1702) 1703 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures. M. Rose. October 1994. (Format: TXT, HTML) (Obsoletes RFC1569) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1703) 1704 On Internet Authentication. N. Haller, R. Atkinson. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1704) 1705 Six Virtual Inches to the Left: The Problem with IPng. R. Carlson, D. Ficarella. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1705) 1706 DNS NSAP Resource Records. B. Manning, R. Colella. October 1994. (Format: TXT, HTML) (Obsoletes RFC1637) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1706) 1707 CATNIP: Common Architecture for the Internet. M. McGovern, R. Ullmann. October 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1707) 1708 NTP PICS PROFORMA - For the Network Time Protocol Version 3. D. Gowin. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1708) 1709 K-12 Internetworking Guidelines. J. Gargano, D. Wasley. November 1994. (Format: TXT, PS, PDF, HTML) (Also FYI0026) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1709) 1710 Simple Internet Protocol Plus White Paper. R. Hinden. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1710) 1711 Classifications in E-mail Routing. J. Houttuin. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1711) 1712 DNS Encoding of Geographical Location. C. Farrell, M. Schulze, S. Pleitner, D. Baldoni. November 1994. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1712) 1713 Tools for DNS debugging. A. Romao. November 1994. (Format: TXT, HTML) (Also FYI0027) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1713) 1714 Referral Whois Protocol (RWhois). S. Williamson, M. Kosters. November 1994. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC2167) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1714) 1715 The H Ratio for Address Assignment Efficiency. C. Huitema. November 1994. (Format: TXT, HTML) (Updated by RFC3194) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1715) 1716 Towards Requirements for IP Routers. P. Almquist, F. Kastenholz. November 1994. (Format: TXT, HTML) (Obsoleted by RFC1812) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1716) 1717 The PPP Multilink Protocol (MP). K. Sklower, B. Lloyd, G. McGregor, D. Carr. November 1994. (Format: TXT, HTML) (Obsoleted by RFC1990) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1717) 1718 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force. IETF Secretariat, G. Malkin. November 1994. (Format: TXT, HTML) (Obsoletes RFC1539) (Obsoleted by RFC3160) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1718) 1719 A Direction for IPng. P. Gross. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1719) 1720 Internet Official Protocol Standards. J. Postel. November 1994. (Format: TXT, HTML) (Obsoletes RFC1610) (Obsoleted by RFC1780) (Status: HISTORIC) (DOI: 10.17487/RFC1720) 1721 RIP Version 2 Protocol Analysis. G. Malkin. November 1994. (Format: TXT, HTML) (Obsoletes RFC1387) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1721) 1722 RIP Version 2 Protocol Applicability Statement. G. Malkin. November 1994. (Format: TXT, HTML) (Also STD0057) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1722) 1723 RIP Version 2 - Carrying Additional Information. G. Malkin. November 1994. (Format: TXT, HTML) (Obsoletes RFC1388) (Obsoleted by RFC2453) (Updates RFC1058) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1723) 1724 RIP Version 2 MIB Extension. G. Malkin, F. Baker. November 1994. (Format: TXT, HTML) (Obsoletes RFC1389) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1724) 1725 Post Office Protocol - Version 3. J. Myers, M. Rose. November 1994. (Format: TXT, HTML) (Obsoletes RFC1460) (Obsoleted by RFC1939) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1725) 1726 Technical Criteria for Choosing IP The Next Generation (IPng). C. Partridge, F. Kastenholz. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1726) 1727 A Vision of an Integrated Internet Information Service. C. Weider, P. Deutsch. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1727) 1728 Resource Transponders. C. Weider. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1728) 1729 Using the Z39.50 Information Retrieval Protocol. C. Lynch. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1729) 1730 Internet Message Access Protocol - Version 4. M. Crispin. December 1994. (Format: TXT, HTML) (Obsoleted by RFC2060, RFC2061) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1730) 1731 IMAP4 Authentication Mechanisms. J. Myers. December 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1731) 1732 IMAP4 Compatibility with IMAP2 and IMAP2bis. M. Crispin. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1732) 1733 Distributed Electronic Mail Models in IMAP4. M. Crispin. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1733) 1734 POP3 AUTHentication command. J. Myers. December 1994. (Format: TXT, HTML) (Obsoleted by RFC5034) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1734) 1735 NBMA Address Resolution Protocol (NARP). J. Heinanen, R. Govindan. December 1994. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1735) 1736 Functional Recommendations for Internet Resource Locators. J. Kunze. February 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1736) 1737 Functional Requirements for Uniform Resource Names. K. Sollins, L. Masinter. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1737) 1738 Uniform Resource Locators (URL). T. Berners-Lee, L. Masinter, M. McCahill. December 1994. (Format: TXT, HTML) (Obsoleted by RFC4248, RFC4266) (Updated by RFC1808, RFC2368, RFC2396, RFC3986, RFC6196, RFC6270, RFC8089) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1738) 1739 A Primer On Internet and TCP/IP Tools. G. Kessler, S. Shepard. December 1994. (Format: TXT, HTML) (Obsoleted by RFC2151) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1739) 1740 MIME Encapsulation of Macintosh Files - MacMIME. P. Faltstrom, D. Crocker, E. Fair. December 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1740) 1741 MIME Content Type for BinHex Encoded Files. P. Faltstrom, D. Crocker, E. Fair. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1741) 1742 AppleTalk Management Information Base II. S. Waldbusser, K. Frisa. January 1995. (Format: TXT, HTML) (Obsoletes RFC1243) (Status: HISTORIC) (DOI: 10.17487/RFC1742) 1743 IEEE 802.5 MIB using SMIv2. K. McCloghrie, E. Decker. December 1994. (Format: TXT, HTML) (Obsoletes RFC1231) (Obsoleted by RFC1748) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1743) 1744 Observations on the Management of the Internet Address Space. G. Huston. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1744) 1745 BGP4/IDRP for IP---OSPF Interaction. K. Varadhan, S. Hares, Y. Rekhter. December 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1745) 1746 Ways to Define User Expectations. B. Manning, D. Perkins. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1746) 1747 Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2. J. Hilgeman, S. Nix, A. Bartky, W. Clark, Ed.. January 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1747) 1748 IEEE 802.5 MIB using SMIv2. K. McCloghrie, E. Decker. December 1994. (Format: TXT, HTML) (Obsoletes RFC1743, RFC1231) (Updated by RFC1749) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1748) 1749 IEEE 802.5 Station Source Routing MIB using SMIv2. K. McCloghrie, F. Baker, E. Decker. December 1994. (Format: TXT, HTML) (Updates RFC1748) (Status: HISTORIC) (DOI: 10.17487/RFC1749) 1750 Randomness Recommendations for Security. D. Eastlake 3rd, S. Crocker, J. Schiller. December 1994. (Format: TXT, HTML) (Obsoleted by RFC4086) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1750) 1751 A Convention for Human-Readable 128-bit Keys. D. McDonald. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1751) 1752 The Recommendation for the IP Next Generation Protocol. S. Bradner, A. Mankin. January 1995. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1752) 1753 IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture. N. Chiappa. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1753) 1754 IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1. M. Laubach. January 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1754) 1755 ATM Signaling Support for IP over ATM. M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis. February 1995. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1755) 1756 Remote Write Protocol - Version 1.0. T. Rinne. January 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1756) 1757 Remote Network Monitoring Management Information Base. S. Waldbusser. February 1995. (Format: TXT, HTML) (Obsoletes RFC1271) (Obsoleted by RFC2819) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1757) 1758 NADF Standing Documents: A Brief Overview. The North American Directory Forum. February 1995. (Format: TXT, HTML) (Obsoletes RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1758) 1759 Printer MIB. R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog. March 1995. (Format: TXT, HTML) (Obsoleted by RFC3805) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1759) 1760 The S/KEY One-Time Password System. N. Haller. February 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1760) 1761 Snoop Version 2 Packet Capture File Format. B. Callaghan, R. Gilligan. February 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1761) 1762 The PPP DECnet Phase IV Control Protocol (DNCP). S. Senum. March 1995. (Format: TXT, HTML) (Obsoletes RFC1376) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1762) 1763 The PPP Banyan Vines Control Protocol (BVCP). S. Senum. March 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1763) 1764 The PPP XNS IDP Control Protocol (XNSCP). S. Senum. March 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1764) 1765 OSPF Database Overflow. J. Moy. March 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1765) 1766 Tags for the Identification of Languages. H. Alvestrand. March 1995. (Format: TXT, HTML) (Obsoleted by RFC3066, RFC3282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1766) 1767 MIME Encapsulation of EDI Objects. D. Crocker. March 1995. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1767) 1768 Host Group Extensions for CLNP Multicasting. D. Marlow. March 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1768) 1769 Simple Network Time Protocol (SNTP). D. Mills. March 1995. (Format: TXT, HTML) (Obsoletes RFC1361) (Obsoleted by RFC2030, RFC4330) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1769) 1770 IPv4 Option for Sender Directed Multi-Destination Delivery. C. Graff. March 1995. (Format: TXT, HTML) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1770) 1771 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li. March 1995. (Format: TXT, HTML) (Obsoletes RFC1654) (Obsoleted by RFC4271) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1771) 1772 Application of the Border Gateway Protocol in the Internet. Y. Rekhter, P. Gross. March 1995. (Format: TXT, HTML) (Obsoletes RFC1655) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1772) 1773 Experience with the BGP-4 protocol. P. Traina. March 1995. (Format: TXT, HTML) (Obsoletes RFC1656) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1773) 1774 BGP-4 Protocol Analysis. P. Traina, Ed.. March 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1774) 1775 To Be "On" the Internet. D. Crocker. March 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1775) 1776 The Address is the Message. S. Crocker. 1 April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1776) 1777 Lightweight Directory Access Protocol. W. Yeong, T. Howes, S. Kille. March 1995. (Format: TXT, HTML) (Obsoletes RFC1487) (Obsoleted by RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1777) 1778 The String Representation of Standard Attribute Syntaxes. T. Howes, S. Kille, W. Yeong, C. Robbins. March 1995. (Format: TXT, HTML) (Obsoletes RFC1488) (Obsoleted by RFC3494) (Updated by RFC2559) (Status: HISTORIC) (DOI: 10.17487/RFC1778) 1779 A String Representation of Distinguished Names. S. Kille. March 1995. (Format: TXT, HTML) (Obsoletes RFC1485) (Obsoleted by RFC2253, RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1779) 1780 Internet Official Protocol Standards. J. Postel, Ed.. March 1995. (Format: TXT, HTML) (Obsoletes RFC1720) (Obsoleted by RFC1800) (Status: HISTORIC) (DOI: 10.17487/RFC1780) 1781 Using the OSI Directory to Achieve User Friendly Naming. S. Kille. March 1995. (Format: TXT, HTML) (Obsoletes RFC1484) (Obsoleted by RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1781) 1782 TFTP Option Extension. G. Malkin, A. Harkin. March 1995. (Format: TXT, HTML) (Obsoleted by RFC2347) (Updates RFC1350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1782) 1783 TFTP Blocksize Option. G. Malkin, A. Harkin. March 1995. (Format: TXT, HTML) (Obsoleted by RFC2348) (Updates RFC1350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1783) 1784 TFTP Timeout Interval and Transfer Size Options. G. Malkin, A. Harkin. March 1995. (Format: TXT, HTML) (Obsoleted by RFC2349) (Updates RFC1350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1784) 1785 TFTP Option Negotiation Analysis. G. Malkin, A. Harkin. March 1995. (Format: TXT, HTML) (Updates RFC1350) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1785) 1786 Representation of IP Routing Policies in a Routing Registry (ripe-81++). T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, J. Yu. March 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1786) 1787 Routing in a Multi-provider Internet. Y. Rekhter. April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1787) 1788 ICMP Domain Name Messages. W. Simpson. April 1995. (Format: TXT, HTML) (Obsoleted by RFC6918) (Status: HISTORIC) (DOI: 10.17487/RFC1788) 1789 INETPhone: Telephone Services and Servers on Internet. C. Yang. April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1789) 1790 An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols. V. Cerf. April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1790) 1791 TCP And UDP Over IPX Networks With Fixed Path MTU. T. Sung. April 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1791) 1792 TCP/IPX Connection Mib Specification. T. Sung. April 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1792) 1793 Extending OSPF to Support Demand Circuits. J. Moy. April 1995. (Format: TXT, HTML) (Updated by RFC3883) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1793) 1794 DNS Support for Load Balancing. T. Brisco. April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1794) 1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1. L. Wells, A. Bartky, Ed.. April 1995. (Format: TXT, HTML) (Obsoletes RFC1434) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1795) 1796 Not All RFCs are Standards. C. Huitema, J. Postel, S. Crocker. April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1796) 1797 Class A Subnet Experiment. Internet Assigned Numbers Authority (IANA). April 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1797) 1798 Connection-less Lightweight X.500 Directory Access Protocol. A. Young. June 1995. (Format: TXT, HTML) (Obsoleted by RFC3352) (Status: HISTORIC) (DOI: 10.17487/RFC1798) 1799 Request for Comments Summary RFC Numbers 1700-1799. M. Kennedy. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1799) 1800 Internet Official Protocol Standards. J. Postel, Ed.. July 1995. (Format: TXT, HTML) (Obsoletes RFC1780) (Obsoleted by RFC1880) (Status: HISTORIC) (DOI: 10.17487/RFC1800) 1801 MHS use of the X.500 Directory to support MHS Routing. S. Kille. June 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1801) 1802 Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing. H. Alvestrand, K. Jordan, S. Langlois, J. Romaguera. June 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1802) 1803 Recommendations for an X.500 Production Directory Service. R. Wright, A. Getchell, T. Howes, S. Sataluri, P. Yee, W. Yeong. June 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1803) 1804 Schema Publishing in X.500 Directory. G. Mansfield, P. Rajeev, S. Raghavan, T. Howes. June 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1804) 1805 Location-Independent Data/Software Integrity Protocol. A. Rubin. June 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1805) 1806 Communicating Presentation Information in Internet Messages: The Content-Disposition Header. R. Troost, S. Dorner. June 1995. (Format: TXT, HTML) (Obsoleted by RFC2183) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1806) 1807 A Format for Bibliographic Records. R. Lasher, D. Cohen. June 1995. (Format: TXT, HTML) (Obsoletes RFC1357) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1807) 1808 Relative Uniform Resource Locators. R. Fielding. June 1995. (Format: TXT, HTML) (Obsoleted by RFC3986) (Updates RFC1738) (Updated by RFC2368, RFC2396) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1808) 1809 Using the Flow Label Field in IPv6. C. Partridge. June 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1809) 1810 Report on MD5 Performance. J. Touch. June 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1810) 1811 U.S. Government Internet Domain Names. Federal Networking Council. June 1995. (Format: TXT, HTML) (Obsoleted by RFC1816) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1811) 1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995. (Format: TXT, HTML) (Obsoletes RFC1716, RFC1009) (Updated by RFC2644, RFC6633) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1812) 1813 NFS Version 3 Protocol Specification. B. Callaghan, B. Pawlowski, P. Staubach. June 1995. (Format: TXT, HTML) (Also RFC1094) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1813) 1814 Unique Addresses are Good. E. Gerich. June 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1814) 1815 Character Sets ISO-10646 and ISO-10646-J-1. M. Ohta. July 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1815) 1816 U.S. Government Internet Domain Names. Federal Networking Council. August 1995. (Format: TXT, HTML) (Obsoletes RFC1811) (Obsoleted by RFC2146) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1816) 1817 CIDR and Classful Routing. Y. Rekhter. August 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1817) 1818 Best Current Practices. J. Postel, T. Li, Y. Rekhter. August 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1818) 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+. L. Delgrossi, Ed., L. Berger, Ed.. August 1995. (Format: TXT, HTML) (Obsoletes RFC1190, IEN119) (Status: HISTORIC) (DOI: 10.17487/RFC1819) 1820 Multimedia E-mail (MIME) User Agent Checklist. E. Huizer. August 1995. (Format: TXT, HTML) (Obsoleted by RFC1844) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1820) 1821 Integration of Real-time Services in an IP-ATM Network Architecture. M. Borden, E. Crawley, B. Davie, S. Batsell. August 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1821) 1822 A Grant of Rights to Use a Specific IBM patent with Photuris. J. Lowe. August 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1822) 1823 The LDAP Application Program Interface. T. Howes, M. Smith. August 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1823) 1824 The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4). H. Danisch. August 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1824) 1825 Security Architecture for the Internet Protocol. R. Atkinson. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2401) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1825) 1826 IP Authentication Header. R. Atkinson. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1826) 1827 IP Encapsulating Security Payload (ESP). R. Atkinson. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2406) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1827) 1828 IP Authentication using Keyed MD5. P. Metzger, W. Simpson. August 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1828) 1829 The ESP DES-CBC Transform. P. Karn, P. Metzger, W. Simpson. August 1995. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1829) 1830 SMTP Service Extensions for Transmission of Large and Binary MIME Messages. G. Vaudreuil. August 1995. (Format: TXT, HTML) (Obsoleted by RFC3030) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1830) 1831 RPC: Remote Procedure Call Protocol Specification Version 2. R. Srinivasan. August 1995. (Format: TXT, HTML) (Obsoleted by RFC5531) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1831) 1832 XDR: External Data Representation Standard. R. Srinivasan. August 1995. (Format: TXT, HTML) (Obsoleted by RFC4506) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1832) 1833 Binding Protocols for ONC RPC Version 2. R. Srinivasan. August 1995. (Format: TXT, HTML) (Updated by RFC5665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1833) 1834 Whois and Network Information Lookup Service, Whois++. J. Gargano, K. Weiss. August 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1834) 1835 Architecture of the WHOIS++ service. P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider. August 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1835) 1836 Representing the O/R Address hierarchy in the X.500 Directory Information Tree. S. Kille. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2294) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1836) 1837 Representing Tables and Subtrees in the X.500 Directory. S. Kille. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2293) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1837) 1838 Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses. S. Kille. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2164) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1838) 1839 Not Issued. 1840 Not Issued. 1841 PPP Network Control Protocol for LAN Extension. J. Chapman, D. Coli, A. Harvey, B. Jensen, K. Rowett. September 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1841) 1842 ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages. Y. Wei, Y. Zhang, J. Li, J. Ding, Y. Jiang. August 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1842) 1843 HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters. F. Lee. August 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1843) 1844 Multimedia E-mail (MIME) User Agent Checklist. E. Huizer. August 1995. (Format: TXT, HTML) (Obsoletes RFC1820) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1844) 1845 SMTP Service Extension for Checkpoint/Restart. D. Crocker, N. Freed, A. Cargille. September 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1845) 1846 SMTP 521 Reply Code. A. Durand, F. Dupont. September 1995. (Format: TXT, HTML) (Updated by RFC7504) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1846) 1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. J. Galvin, S. Murphy, S. Crocker, N. Freed. October 1995. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1847) 1848 MIME Object Security Services. S. Crocker, N. Freed, J. Galvin, S. Murphy. October 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1848) 1849 "Son of 1036": News Article Format and Transmission. H. Spencer. March 2010. (Format: TXT, HTML) (Obsoleted by RFC5536, RFC5537) (Status: HISTORIC) (DOI: 10.17487/RFC1849) 1850 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. November 1995. (Format: TXT, HTML) (Obsoletes RFC1253) (Obsoleted by RFC4750) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1850) 1851 The ESP Triple DES Transform. P. Karn, P. Metzger, W. Simpson. September 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1851) 1852 IP Authentication using Keyed SHA. P. Metzger, W. Simpson. September 1995. (Format: TXT, HTML) (Obsoleted by RFC2841) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1852) 1853 IP in IP Tunneling. W. Simpson. October 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1853) 1854 SMTP Service Extension for Command Pipelining. N. Freed. October 1995. (Format: TXT, HTML) (Obsoleted by RFC2197) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1854) 1855 Netiquette Guidelines. S. Hambridge. October 1995. (Format: TXT, HTML) (Also FYI0028) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1855) 1856 The Opstat Client-Server Model for Statistics Retrieval. H. Clark. September 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1856) 1857 A Model for Common Operational Statistics. M. Lambert. October 1995. (Format: TXT, HTML) (Obsoletes RFC1404) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1857) 1858 Security Considerations for IP Fragment Filtering. G. Ziemba, D. Reed, P. Traina. October 1995. (Format: TXT, HTML) (Updated by RFC3128) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1858) 1859 ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension. Y. Pouffary. October 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1859) 1860 Variable Length Subnet Table For IPv4. T. Pummill, B. Manning. October 1995. (Format: TXT, HTML) (Obsoleted by RFC1878) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1860) 1861 Simple Network Paging Protocol - Version 3 -Two-Way Enhanced. A. Gwinn. October 1995. (Format: TXT, HTML) (Obsoletes RFC1645) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1861) 1862 Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994. M. McCahill, J. Romkey, M. Schwartz, K. Sollins, T. Verschuren, C. Weider. November 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1862) 1863 A BGP/IDRP Route Server alternative to a full mesh routing. D. Haskin. October 1995. (Format: TXT, HTML) (Obsoleted by RFC4223) (Status: HISTORIC) (DOI: 10.17487/RFC1863) 1864 The Content-MD5 Header Field. J. Myers, M. Rose. October 1995. (Format: TXT, HTML) (Obsoletes RFC1544) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1864) 1865 EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet. W. Houser, J. Griffin, C. Hage. January 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1865) 1866 Hypertext Markup Language - 2.0. T. Berners-Lee, D. Connolly. November 1995. (Format: TXT, HTML) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC1866) 1867 Form-based File Upload in HTML. E. Nebel, L. Masinter. November 1995. (Format: TXT, HTML) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC1867) 1868 ARP Extension - UNARP. G. Malkin. November 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1868) 1869 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. November 1995. (Format: TXT, HTML) (Obsoletes RFC1651) (Obsoleted by RFC2821) (Also STD0010) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1869) 1870 SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, K. Moore. November 1995. (Format: TXT, HTML) (Obsoletes RFC1653) (Also STD0010) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1870) 1871 Addendum to RFC 1602 -- Variance Procedure. J. Postel. November 1995. (Format: TXT, HTML) (Obsoleted by RFC2026) (Updates RFC1602, RFC1603) (Status: HISTORIC) (DOI: 10.17487/RFC1871) 1872 The MIME Multipart/Related Content-type. E. Levinson. December 1995. (Format: TXT, HTML) (Obsoleted by RFC2112) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1872) 1873 Message/External-Body Content-ID Access Type. E. Levinson. December 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1873) 1874 SGML Media Types. E. Levinson. December 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1874) 1875 UNINETT PCA Policy Statements. N. Berge. December 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1875) 1876 A Means for Expressing Location Information in the Domain Name System. C. Davis, P. Vixie, T. Goodwin, I. Dickinson. January 1996. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1876) 1877 PPP Internet Protocol Control Protocol Extensions for Name Server Addresses. S. Cobb. December 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1877) 1878 Variable Length Subnet Table For IPv4. T. Pummill, B. Manning. December 1995. (Format: TXT, HTML) (Obsoletes RFC1860) (Status: HISTORIC) (DOI: 10.17487/RFC1878) 1879 Class A Subnet Experiment Results and Recommendations. B. Manning, Ed.. January 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1879) 1880 Internet Official Protocol Standards. J. Postel, Ed.. November 1995. (Format: TXT, HTML) (Obsoletes RFC1800) (Obsoleted by RFC1920) (Status: HISTORIC) (DOI: 10.17487/RFC1880) 1881 IPv6 Address Allocation Management. IAB, IESG. December 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1881) 1882 The 12-Days of Technology Before Christmas. B. Hancock. December 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1882) 1883 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. December 1995. (Format: TXT, HTML) (Obsoleted by RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1883) 1884 IP Version 6 Addressing Architecture. R. Hinden, Ed., S. Deering, Ed.. December 1995. (Format: TXT, HTML) (Obsoleted by RFC2373) (Status: HISTORIC) (DOI: 10.17487/RFC1884) 1885 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6). A. Conta, S. Deering. December 1995. (Format: TXT, HTML) (Obsoleted by RFC2463) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1885) 1886 DNS Extensions to support IP version 6. S. Thomson, C. Huitema. December 1995. (Format: TXT, HTML) (Obsoleted by RFC3596) (Updated by RFC2874, RFC3152) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1886) 1887 An Architecture for IPv6 Unicast Address Allocation. Y. Rekhter, Ed., T. Li, Ed.. December 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1887) 1888 OSI NSAPs and IPv6. J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd. August 1996. (Format: TXT, HTML) (Obsoleted by RFC4048) (Updated by RFC4548) (Status: HISTORIC) (DOI: 10.17487/RFC1888) 1889 RTP: A Transport Protocol for Real-Time Applications. Audio-Video Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. January 1996. (Format: TXT, HTML) (Obsoleted by RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1889) 1890 RTP Profile for Audio and Video Conferences with Minimal Control. Audio-Video Transport Working Group, H. Schulzrinne. January 1996. (Format: TXT, HTML) (Obsoleted by RFC3551) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1890) 1891 SMTP Service Extension for Delivery Status Notifications. K. Moore. January 1996. (Format: TXT, HTML) (Obsoleted by RFC3461) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1891) 1892 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages. G. Vaudreuil. January 1996. (Format: TXT, HTML) (Obsoleted by RFC3462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1892) 1893 Enhanced Mail System Status Codes. G. Vaudreuil. January 1996. (Format: TXT, HTML) (Obsoleted by RFC3463) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1893) 1894 An Extensible Message Format for Delivery Status Notifications. K. Moore, G. Vaudreuil. January 1996. (Format: TXT, HTML) (Obsoleted by RFC3464) (Updated by RFC2852) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1894) 1895 The Application/CALS-1840 Content-type. E. Levinson. February 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1895) 1896 The text/enriched MIME Content-type. P. Resnick, A. Walker. February 1996. (Format: TXT, PS, HTML) (Obsoletes RFC1523, RFC1563) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1896) 1897 IPv6 Testing Address Allocation. R. Hinden, J. Postel. January 1996. (Format: TXT, HTML) (Obsoleted by RFC2471) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1897) 1898 CyberCash Credit Card Protocol Version 0.8. D. Eastlake 3rd, B. Boesch, S. Crocker, M. Yesil. February 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1898) 1899 Request for Comments Summary RFC Numbers 1800-1899. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1899) 1900 Renumbering Needs Work. B. Carpenter, Y. Rekhter. February 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1900) 1901 Introduction to Community-based SNMPv2. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1901) 1902 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Obsoletes RFC1442) (Obsoleted by RFC2578) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1902) 1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Obsoletes RFC1443) (Obsoleted by RFC2579) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1903) 1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Obsoletes RFC1444) (Obsoleted by RFC2580) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1904) 1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Obsoletes RFC1448) (Obsoleted by RFC3416) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1905) 1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Obsoletes RFC1449) (Obsoleted by RFC3417) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1906) 1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Obsoletes RFC1450) (Obsoleted by RFC3418) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1907) 1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Obsoletes RFC1452) (Obsoleted by RFC2576) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1908) 1909 An Administrative Infrastructure for SNMPv2. K. McCloghrie, Ed.. February 1996. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1909) 1910 User-based Security Model for SNMPv2. G. Waters, Ed.. February 1996. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1910) 1911 Voice Profile for Internet Mail. G. Vaudreuil. February 1996. (Format: TXT, HTML) (Obsoleted by RFC2421, RFC2422, RFC2423) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1911) 1912 Common DNS Operational and Configuration Errors. D. Barr. February 1996. (Format: TXT, HTML) (Obsoletes RFC1537) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1912) 1913 Architecture of the Whois++ Index Service. C. Weider, J. Fullton, S. Spero. February 1996. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1913) 1914 How to Interact with a Whois++ Mesh. P. Faltstrom, R. Schoultz, C. Weider. February 1996. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1914) 1915 Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol. F. Kastenholz. February 1996. (Format: TXT, HTML) (Also BCP0003) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1915) 1916 Enterprise Renumbering: Experience and Information Solicitation. H. Berkowitz, P. Ferguson, W. Leland, P. Nesser. February 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1916) 1917 An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA. P. Nesser II. February 1996. (Format: TXT, HTML) (Also BCP0004) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1917) 1918 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996. (Format: TXT, HTML) (Obsoletes RFC1627, RFC1597) (Updated by RFC6761) (Also BCP0005) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1918) 1919 Classical versus Transparent IP Proxies. M. Chatel. March 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1919) 1920 Internet Official Protocol Standards. J. Postel. March 1996. (Format: TXT, HTML) (Obsoletes RFC1880) (Obsoleted by RFC2000) (Status: HISTORIC) (DOI: 10.17487/RFC1920) 1921 TNVIP Protocol. J. Dujonc. March 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1921) 1922 Chinese Character Encoding for Internet Messages. HF. Zhu, DY. Hu, ZG. Wang, TC. Kao, WCH. Chang, M. Crispin. March 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1922) 1923 RIPv1 Applicability Statement for Historic Status. J. Halpern, S. Bradner. March 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1923) 1924 A Compact Representation of IPv6 Addresses. R. Elz. 1 April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1924) 1925 The Twelve Networking Truths. R. Callon. 1 April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1925) 1926 An Experimental Encapsulation of IP Datagrams on Top of ATM. J. Eriksson. 1 April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1926) 1927 Suggested Additional MIME Types for Associating Documents. C. Rogers. 1 April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1927) 1928 SOCKS Protocol Version 5. M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones. March 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1928) 1929 Username/Password Authentication for SOCKS V5. M. Leech. March 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1929) 1930 Guidelines for creation, selection, and registration of an Autonomous System (AS). J. Hawkinson, T. Bates. March 1996. (Format: TXT, HTML) (Updated by RFC6996, RFC7300) (Also BCP0006) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1930) 1931 Dynamic RARP Extensions for Automatic Network Address Acquisition. D. Brownell. April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1931) 1932 IP over ATM: A Framework Document. R. Cole, D. Shur, C. Villamizar. April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1932) 1933 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. Nordmark. April 1996. (Format: TXT, HTML) (Obsoleted by RFC2893) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1933) 1934 Ascend's Multilink Protocol Plus (MP+). K. Smith. April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1934) 1935 What is the Internet, Anyway?. J. Quarterman, S. Carl-Mitchell. April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1935) 1936 Implementing the Internet Checksum in Hardware. J. Touch, B. Parham. April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1936) 1937 "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks. Y. Rekhter, D. Kandlur. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1937) 1938 A One-Time Password System. N. Haller, C. Metz. May 1996. (Format: TXT, HTML) (Obsoleted by RFC2289) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1938) 1939 Post Office Protocol - Version 3. J. Myers, M. Rose. May 1996. (Format: TXT, HTML) (Obsoletes RFC1725) (Updated by RFC1957, RFC2449, RFC6186, RFC8314) (Also STD0053) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1939) 1940 Source Demand Routing: Packet Format and Forwarding Specification (Version 1). D. Estrin, T. Li, Y. Rekhter, K. Varadhan, D. Zappala. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1940) 1941 Frequently Asked Questions for Schools. J. Sellers, J. Robichaux. May 1996. (Format: TXT, HTML) (Obsoletes RFC1578) (Also FYI0022) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1941) 1942 HTML Tables. D. Raggett. May 1996. (Format: TXT, HTML) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC1942) 1943 Building an X.500 Directory Service in the US. B. Jennings. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1943) 1944 Benchmarking Methodology for Network Interconnect Devices. S. Bradner, J. McQuaid. May 1996. (Format: TXT, HTML) (Obsoleted by RFC2544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1944) 1945 Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R. Fielding, H. Frystyk. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1945) 1946 Native ATM Support for ST2+. S. Jackowski. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1946) 1947 Greek Character Encoding for Electronic Mail Messages. D. Spinellis. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1947) 1948 Defending Against Sequence Number Attacks. S. Bellovin. May 1996. (Format: TXT, HTML) (Obsoleted by RFC6528) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1948) 1949 Scalable Multicast Key Distribution. A. Ballardie. May 1996. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1949) 1950 ZLIB Compressed Data Format Specification version 3.3. P. Deutsch, J-L. Gailly. May 1996. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1950) 1951 DEFLATE Compressed Data Format Specification version 1.3. P. Deutsch. May 1996. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1951) 1952 GZIP file format specification version 4.3. P. Deutsch. May 1996. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1952) 1953 Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1953) 1954 Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1954) 1955 New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG. R. Hinden. June 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1955) 1956 Registration in the MIL Domain. D. Engebretson, R. Plzak. June 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1956) 1957 Some Observations on Implementations of the Post Office Protocol (POP3). R. Nelson. June 1996. (Format: TXT, HTML) (Updates RFC1939) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1957) 1958 Architectural Principles of the Internet. B. Carpenter, Ed.. June 1996. (Format: TXT, HTML) (Updated by RFC3439) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1958) 1959 An LDAP URL Format. T. Howes, M. Smith. June 1996. (Format: TXT, HTML) (Obsoleted by RFC2255) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1959) 1960 A String Representation of LDAP Search Filters. T. Howes. June 1996. (Format: TXT, HTML) (Obsoletes RFC1558) (Obsoleted by RFC2254) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1960) 1961 GSS-API Authentication Method for SOCKS Version 5. P. McMahon. June 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1961) 1962 The PPP Compression Control Protocol (CCP). D. Rand. June 1996. (Format: TXT, HTML) (Updated by RFC2153) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1962) 1963 PPP Serial Data Transport Protocol (SDTP). K. Schneider, S. Venters. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1963) 1964 The Kerberos Version 5 GSS-API Mechanism. J. Linn. June 1996. (Format: TXT, HTML) (Updated by RFC4121, RFC6649) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1964) 1965 Autonomous System Confederations for BGP. P. Traina. June 1996. (Format: TXT, HTML) (Obsoleted by RFC3065) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1965) 1966 BGP Route Reflection An alternative to full mesh IBGP. T. Bates, R. Chandra. June 1996. (Format: TXT, HTML) (Obsoleted by RFC4456) (Updated by RFC2796) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1966) 1967 PPP LZS-DCP Compression Protocol (LZS-DCP). K. Schneider, R. Friend. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1967) 1968 The PPP Encryption Control Protocol (ECP). G. Meyer. June 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1968) 1969 The PPP DES Encryption Protocol (DESE). K. Sklower, G. Meyer. June 1996. (Format: TXT, HTML) (Obsoleted by RFC2419) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1969) 1970 Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson. August 1996. (Format: TXT, HTML) (Obsoleted by RFC2461) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1970) 1971 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. August 1996. (Format: TXT, HTML) (Obsoleted by RFC2462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1971) 1972 A Method for the Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. August 1996. (Format: TXT, HTML) (Obsoleted by RFC2464) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1972) 1973 PPP in Frame Relay. W. Simpson. June 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1973) 1974 PPP Stac LZS Compression Protocol. R. Friend, W. Simpson. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1974) 1975 PPP Magnalink Variable Resource Compression. D. Schremp, J. Black, J. Weiss. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1975) 1976 PPP for Data Compression in Data Circuit-Terminating Equipment (DCE). K. Schneider, S. Venters. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1976) 1977 PPP BSD Compression Protocol. V. Schryver. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1977) 1978 PPP Predictor Compression Protocol. D. Rand. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1978) 1979 PPP Deflate Protocol. J. Woods. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1979) 1980 A Proposed Extension to HTML : Client-Side Image Maps. J. Seidman. August 1996. (Format: TXT, HTML) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC1980) 1981 Path MTU Discovery for IP version 6. J. McCann, S. Deering, J. Mogul. August 1996. (Format: TXT, HTML) (Obsoleted by RFC8201) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1981) 1982 Serial Number Arithmetic. R. Elz, R. Bush. August 1996. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1982) 1983 Internet Users' Glossary. G. Malkin, Ed.. August 1996. (Format: TXT, HTML) (Obsoletes RFC1392) (Also FYI0018) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1983) 1984 IAB and IESG Statement on Cryptographic Technology and the Internet. IAB, IESG. August 1996. (Format: TXT, HTML) (Also BCP0200) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1984) 1985 SMTP Service Extension for Remote Message Queue Starting. J. De Winter. August 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1985) 1986 Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP). W. Polites, W. Wollman, D. Woo, R. Langan. August 1996. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1986) 1987 Ipsilon's General Switch Management Protocol Specification Version 1.1. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. August 1996. (Format: TXT, HTML) (Updated by RFC2297) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1987) 1988 Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework. G. McAnally, D. Gilbert, J. Flick. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1988) 1989 PPP Link Quality Monitoring. W. Simpson. August 1996. (Format: TXT, HTML) (Obsoletes RFC1333) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1989) 1990 The PPP Multilink Protocol (MP). K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti. August 1996. (Format: TXT, HTML) (Obsoletes RFC1717) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1990) 1991 PGP Message Exchange Formats. D. Atkins, W. Stallings, P. Zimmermann. August 1996. (Format: TXT, HTML) (Obsoleted by RFC4880) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1991) 1992 The Nimrod Routing Architecture. I. Castineyra, N. Chiappa, M. Steenstrup. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1992) 1993 PPP Gandalf FZA Compression Protocol. A. Barbir, D. Carr, W. Simpson. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1993) 1994 PPP Challenge Handshake Authentication Protocol (CHAP). W. Simpson. August 1996. (Format: TXT, HTML) (Obsoletes RFC1334) (Updated by RFC2484) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1994) 1995 Incremental Zone Transfer in DNS. M. Ohta. August 1996. (Format: TXT, HTML) (Updates RFC1035) (Updated by RFC9103) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1995) 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY). P. Vixie. August 1996. (Format: TXT, HTML) (Updates RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1996) 1997 BGP Communities Attribute. R. Chandra, P. Traina, T. Li. August 1996. (Format: TXT, HTML) (Updated by RFC7606, RFC8642) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1997) 1998 An Application of the BGP Community Attribute in Multi-home Routing. E. Chen, T. Bates. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1998) 1999 Request for Comments Summary RFC Numbers 1900-1999. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1999) 2000 Internet Official Protocol Standards. J. Postel, Ed.. February 1997. (Format: TXT, HTML) (Obsoletes RFC1920) (Obsoleted by RFC2200) (Status: HISTORIC) (DOI: 10.17487/RFC2000) 2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2581) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2001) 2002 IP Mobility Support. C. Perkins, Ed.. October 1996. (Format: TXT, HTML) (Obsoleted by RFC3220) (Updated by RFC2290) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2002) 2003 IP Encapsulation within IP. C. Perkins. October 1996. (Format: TXT, HTML) (Updated by RFC3168, RFC6864) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2003) 2004 Minimal Encapsulation within IP. C. Perkins. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2004) 2005 Applicability Statement for IP Mobility Support. J. Solomon. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2005) 2006 The Definitions of Managed Objects for IP Mobility Support using SMIv2. D. Cong, M. Hamlen, C. Perkins. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2006) 2007 Catalogue of Network Training Materials. J. Foster, M. Isaacs, M. Prior. October 1996. (Format: TXT, HTML) (Also FYI0029) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2007) 2008 Implications of Various Address Allocation Policies for Internet Routing. Y. Rekhter, T. Li. October 1996. (Format: TXT, HTML) (Also BCP0007) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2008) 2009 GPS-Based Addressing and Routing. T. Imielinski, J. Navas. November 1996. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2009) 2010 Operational Criteria for Root Name Servers. B. Manning, P. Vixie. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2870) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2010) 2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2. K. McCloghrie, Ed.. November 1996. (Format: TXT, HTML) (Obsoleted by RFC4293) (Updates RFC1213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2011) 2012 SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2. K. McCloghrie, Ed.. November 1996. (Format: TXT, HTML) (Obsoleted by RFC4022) (Updates RFC1213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2012) 2013 SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2. K. McCloghrie, Ed.. November 1996. (Format: TXT, HTML) (Obsoleted by RFC4113) (Updates RFC1213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2013) 2014 IRTF Research Group Guidelines and Procedures. A. Weinrib, J. Postel. October 1996. (Format: TXT, HTML) (Also BCP0008) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2014) 2015 MIME Security with Pretty Good Privacy (PGP). M. Elkins. October 1996. (Format: TXT, HTML) (Updated by RFC3156) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2015) 2016 Uniform Resource Agents (URAs). L. Daigle, P. Deutsch, B. Heelan, C. Alpaugh, M. Maclachlan. October 1996. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2016) 2017 Definition of the URL MIME External-Body Access-Type. N. Freed, K. Moore, A. Cargille. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2017) 2018 TCP Selective Acknowledgment Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. October 1996. (Format: TXT, HTML) (Obsoletes RFC1072) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2018) 2019 Transmission of IPv6 Packets Over FDDI. M. Crawford. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2467) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2019) 2020 IEEE 802.12 Interface MIB. J. Flick. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2020) 2021 Remote Network Monitoring Management Information Base Version 2 using SMIv2. S. Waldbusser. January 1997. (Format: TXT, HTML) (Obsoleted by RFC4502) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2021) 2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks. G. Armitage. November 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2022) 2023 IP Version 6 over PPP. D. Haskin, E. Allen. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2472) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2023) 2024 Definitions of Managed Objects for Data Link Switching using SMIv2. D. Chen, Ed., P. Gayek, S. Nix. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2024) 2025 The Simple Public-Key GSS-API Mechanism (SPKM). C. Adams. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2025) 2026 The Internet Standards Process -- Revision 3. S. Bradner. October 1996. (Format: TXT, HTML) (Obsoletes RFC1602, RFC1871) (Updated by RFC3667, RFC3668, RFC3932, RFC3978, RFC3979, RFC5378, RFC5657, RFC5742, RFC6410, RFC7100, RFC7127, RFC7475, RFC8179, RFC8789, RFC9282) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2026) 2027 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. J. Galvin. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2282) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2027) 2028 The Organizations Involved in the IETF Standards Process. R. Hovey, S. Bradner. October 1996. (Format: TXT, HTML) (Obsoleted by RFC9281) (Updated by RFC3668, RFC3979, RFC8717) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2028) 2029 RTP Payload Format of Sun's CellB Video Encoding. M. Speer, D. Hoffman. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2029) 2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. D. Mills. October 1996. (Format: TXT, HTML) (Obsoletes RFC1769) (Obsoleted by RFC4330) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2030) 2031 IETF-ISOC relationship. E. Huizer. October 1996. (Format: TXT, HTML) (Obsoleted by RFC8712) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2031) 2032 RTP Payload Format for H.261 Video Streams. T. Turletti, C. Huitema. October 1996. (Format: TXT, HTML) (Obsoleted by RFC4587) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2032) 2033 Local Mail Transfer Protocol. J. Myers. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2033) 2034 SMTP Service Extension for Returning Enhanced Error Codes. N. Freed. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2034) 2035 RTP Payload Format for JPEG-compressed Video. L. Berc, W. Fenner, R. Frederick, S. McCanne. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2435) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2035) 2036 Observations on the use of Components of the Class A Address Space within the Internet. G. Huston. October 1996. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2036) 2037 Entity MIB using SMIv2. K. McCloghrie, A. Bierman. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2737) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2037) 2038 RTP Payload Format for MPEG1/MPEG2 Video. D. Hoffman, G. Fernando, V. Goyal. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2250) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2038) 2039 Applicability of Standards Track MIBs to Management of World Wide Web Servers. C. Kalbfleisch. November 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2039) 2040 The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms. R. Baldwin, R. Rivest. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2040) 2041 Mobile Network Tracing. B. Noble, G. Nguyen, M. Satyanarayanan, R. Katz. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2041) 2042 Registering New BGP Attribute Types. B. Manning. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2042) 2043 The PPP SNA Control Protocol (SNACP). A. Fuqua. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2043) 2044 UTF-8, a transformation format of Unicode and ISO 10646. F. Yergeau. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2279) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2044) 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed, N. Borenstein. November 1996. (Format: TXT, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2184, RFC2231, RFC5335, RFC6532) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2045) 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed, N. Borenstein. November 1996. (Format: TXT, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2646, RFC3798, RFC5147, RFC6657, RFC8098) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2046) 2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. K. Moore. November 1996. (Format: TXT, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2184, RFC2231) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2047) 2048 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. N. Freed, J. Klensin, J. Postel. November 1996. (Format: TXT, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Obsoleted by RFC4288, RFC4289) (Updated by RFC3023) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2048) 2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996. (Format: TXT, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2049) 2050 Internet Registry IP Allocation Guidelines. K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel. November 1996. (Format: TXT, HTML) (Obsoletes RFC1466) (Obsoleted by RFC7020) (Status: HISTORIC) (DOI: 10.17487/RFC2050) 2051 Definitions of Managed Objects for APPC using SMIv2. M. Allen, B. Clouston, Z. Kielczewski, W. Kwan, B. Moore. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2051) 2052 A DNS RR for specifying the location of services (DNS SRV). A. Gulbrandsen, P. Vixie. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2782) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2052) 2053 The AM (Armenia) Domain. E. Der-Danieliantz. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2053) 2054 WebNFS Client Specification. B. Callaghan. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2054) 2055 WebNFS Server Specification. B. Callaghan. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2055) 2056 Uniform Resource Locators for Z39.50. R. Denenberg, J. Kunze, D. Lynch. November 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2056) 2057 Source Directed Access Control on the Internet. S. Bradner. November 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2057) 2058 Remote Authentication Dial In User Service (RADIUS). C. Rigney, A. Rubens, W. Simpson, S. Willens. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2138) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2058) 2059 RADIUS Accounting. C. Rigney. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2139) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2059) 2060 Internet Message Access Protocol - Version 4rev1. M. Crispin. December 1996. (Format: TXT, HTML) (Obsoletes RFC1730) (Obsoleted by RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2060) 2061 IMAP4 Compatibility with IMAP2bis. M. Crispin. December 1996. (Format: TXT, HTML) (Obsoletes RFC1730) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2061) 2062 Internet Message Access Protocol - Obsolete Syntax. M. Crispin. December 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2062) 2063 Traffic Flow Measurement: Architecture. N. Brownlee, C. Mills, G. Ruth. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2722) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2063) 2064 Traffic Flow Measurement: Meter MIB. N. Brownlee. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2720) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2064) 2065 Domain Name System Security Extensions. D. Eastlake 3rd, C. Kaufman. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2535) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2065) 2066 TELNET CHARSET Option. R. Gellens. January 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2066) 2067 IP over HIPPI. J. Renwick. January 1997. (Format: TXT, HTML) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2067) 2068 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2068) 2069 An Extension to HTTP : Digest Access Authentication. J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, L. Stewart. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2617) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2069) 2070 Internationalization of the Hypertext Markup Language. F. Yergeau, G. Nicol, G. Adams, M. Duerst. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC2070) 2071 Network Renumbering Overview: Why would I want it and what is it anyway?. P. Ferguson, H. Berkowitz. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2071) 2072 Router Renumbering Guide. H. Berkowitz. January 1997. (Format: TXT, HTML) (Updated by RFC4192) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2072) 2073 An IPv6 Provider-Based Unicast Address Format. Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2374) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2073) 2074 Remote Network Monitoring MIB Protocol Identifiers. A. Bierman, R. Iddon. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2074) 2075 IP Echo Host Service. C. Partridge. January 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2075) 2076 Common Internet Message Headers. J. Palme. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2076) 2077 The Model Primary Content Type for Multipurpose Internet Mail Extensions. S. Nelson, C. Parks, Mitra. January 1997. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2077) 2078 Generic Security Service Application Program Interface, Version 2. J. Linn. January 1997. (Format: TXT, HTML) (Obsoletes RFC1508) (Obsoleted by RFC2743) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2078) 2079 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs). M. Smith. January 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2079) 2080 RIPng for IPv6. G. Malkin, R. Minnear. January 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2080) 2081 RIPng Protocol Applicability Statement. G. Malkin. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2081) 2082 RIP-2 MD5 Authentication. F. Baker, R. Atkinson. January 1997. (Format: TXT, HTML) (Obsoleted by RFC4822) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2082) 2083 PNG (Portable Network Graphics) Specification Version 1.0. T. Boutell. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2083) 2084 Considerations for Web Transaction Security. G. Bossert, S. Cooper, W. Drummond. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2084) 2085 HMAC-MD5 IP Authentication with Replay Prevention. M. Oehler, R. Glenn. February 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2085) 2086 IMAP4 ACL extension. J. Myers. January 1997. (Format: TXT, HTML) (Obsoleted by RFC4314) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2086) 2087 IMAP4 QUOTA extension. J. Myers. January 1997. (Format: TXT, HTML) (Obsoleted by RFC9208) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2087) 2088 IMAP4 non-synchronizing literals. J. Myers. January 1997. (Format: TXT, HTML) (Obsoleted by RFC7888) (Updated by RFC4466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2088) 2089 V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent. B. Wijnen, D. Levi. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2576) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2089) 2090 TFTP Multicast Option. A. Emberson. February 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2090) 2091 Triggered Extensions to RIP to Support Demand Circuits. G. Meyer, S. Sherry. January 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2091) 2092 Protocol Analysis for Triggered RIP. S. Sherry, G. Meyer. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2092) 2093 Group Key Management Protocol (GKMP) Specification. H. Harney, C. Muckenhirn. July 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2093) 2094 Group Key Management Protocol (GKMP) Architecture. H. Harney, C. Muckenhirn. July 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2094) 2095 IMAP/POP AUTHorize Extension for Simple Challenge/Response. J. Klensin, R. Catoe, P. Krumviede. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2195) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2095) 2096 IP Forwarding Table MIB. F. Baker. January 1997. (Format: TXT, HTML) (Obsoletes RFC1354) (Obsoleted by RFC4292) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2096) 2097 The PPP NetBIOS Frames Control Protocol (NBFCP). G. Pall. January 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2097) 2098 Toshiba's Router Architecture Extensions for ATM : Overview. Y. Katsube, K. Nagami, H. Esaki. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2098) 2099 Request for Comments Summary RFC Numbers 2000-2099. J. Elliott. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2099) 2100 The Naming of Hosts. J. Ashworth. 1 April 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2100) 2101 IPv4 Address Behaviour Today. B. Carpenter, J. Crowcroft, Y. Rekhter. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2101) 2102 Multicast Support for Nimrod : Requirements and Solution Approaches. R. Ramanathan. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2102) 2103 Mobility Support for Nimrod : Challenges and Solution Approaches. R. Ramanathan. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2103) 2104 HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997. (Format: TXT, HTML) (Updated by RFC6151) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2104) 2105 Cisco Systems' Tag Switching Architecture Overview. Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2105) 2106 Data Link Switching Remote Access Protocol. S. Chiang, J. Lee, H. Yasuda. February 1997. (Format: TXT, HTML) (Obsoleted by RFC2114) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2106) 2107 Ascend Tunnel Management Protocol - ATMP. K. Hamzeh. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2107) 2108 Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2. K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie. February 1997. (Format: TXT, HTML) (Obsoletes RFC1516) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2108) 2109 HTTP State Management Mechanism. D. Kristol, L. Montulli. February 1997. (Format: TXT, HTML) (Obsoleted by RFC2965) (Status: HISTORIC) (DOI: 10.17487/RFC2109) 2110 MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML). J. Palme, A. Hopmann. March 1997. (Format: TXT, HTML) (Obsoleted by RFC2557) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2110) 2111 Content-ID and Message-ID Uniform Resource Locators. E. Levinson. March 1997. (Format: TXT, HTML) (Obsoleted by RFC2392) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2111) 2112 The MIME Multipart/Related Content-type. E. Levinson. March 1997. (Format: TXT, HTML) (Obsoletes RFC1872) (Obsoleted by RFC2387) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2112) 2113 IP Router Alert Option. D. Katz. February 1997. (Format: TXT, HTML) (Updated by RFC5350, RFC6398) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2113) 2114 Data Link Switching Client Access Protocol. S. Chiang, J. Lee, H. Yasuda. February 1997. (Format: TXT, HTML) (Obsoletes RFC2106) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2114) 2115 Management Information Base for Frame Relay DTEs Using SMIv2. C. Brown, F. Baker. September 1997. (Format: TXT, HTML) (Obsoletes RFC1315) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2115) 2116 X.500 Implementations Catalog-96. C. Apple, K. Rossen. April 1997. (Format: TXT, HTML) (Obsoletes RFC1632) (Also FYI0011) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2116) 2117 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June 1997. (Format: TXT, HTML) (Obsoleted by RFC2362) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2117) 2118 Microsoft Point-To-Point Compression (MPPC) Protocol. G. Pall. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2118) 2119 Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. (Format: TXT, HTML) (Updated by RFC8174) (Also BCP0014) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2119) 2120 Managing the X.500 Root Naming Context. D. Chadwick. March 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2120) 2121 Issues affecting MARS Cluster Size. G. Armitage. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2121) 2122 VEMMI URL Specification. D. Mavrakis, H. Layec, K. Kartmann. March 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2122) 2123 Traffic Flow Measurement: Experiences with NeTraMet. N. Brownlee. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2123) 2124 Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0. P. Amsden, J. Amweg, P. Calato, S. Bensley, G. Lyons. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2124) 2125 The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP). C. Richards, K. Smith. March 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2125) 2126 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A. Young. March 1997. (Format: TXT, HTML) (Updates RFC1006) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2126) 2127 ISDN Management Information Base using SMIv2. G. Roeck, Ed.. March 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2127) 2128 Dial Control Management Information Base using SMIv2. G. Roeck, Ed.. March 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2128) 2129 Toshiba's Flow Attribute Notification Protocol (FANP) Specification. K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, T. Jinmei, H. Esaki. April 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2129) 2130 The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996. C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. Atkinson, M. Crispin, P. Svanberg. April 1997. (Format: TXT, HTML) (Updated by RFC6055) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2130) 2131 Dynamic Host Configuration Protocol. R. Droms. March 1997. (Format: TXT, HTML) (Obsoletes RFC1541) (Updated by RFC3396, RFC4361, RFC5494, RFC6842) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2131) 2132 DHCP Options and BOOTP Vendor Extensions. S. Alexander, R. Droms. March 1997. (Format: TXT, HTML) (Obsoletes RFC1533) (Updated by RFC3442, RFC3942, RFC4361, RFC4833, RFC5494) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2132) 2133 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. April 1997. (Format: TXT, HTML) (Obsoleted by RFC2553) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2133) 2134 Articles of Incorporation of Internet Society. ISOC Board of Trustees. April 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2134) 2135 Internet Society By-Laws. ISOC Board of Trustees. April 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2135) 2136 Dynamic Updates in the Domain Name System (DNS UPDATE). P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. (Format: TXT, HTML) (Updates RFC1035) (Updated by RFC3007, RFC4035, RFC4033, RFC4034) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2136) 2137 Secure Domain Name System Dynamic Update. D. Eastlake 3rd. April 1997. (Format: TXT, HTML) (Obsoleted by RFC3007) (Updates RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2137) 2138 Remote Authentication Dial In User Service (RADIUS). C. Rigney, A. Rubens, W. Simpson, S. Willens. April 1997. (Format: TXT, HTML) (Obsoletes RFC2058) (Obsoleted by RFC2865) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2138) 2139 RADIUS Accounting. C. Rigney. April 1997. (Format: TXT, HTML) (Obsoletes RFC2059) (Obsoleted by RFC2866) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2139) 2140 TCP Control Block Interdependence. J. Touch. April 1997. (Format: TXT, HTML) (Obsoleted by RFC9040) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2140) 2141 URN Syntax. R. Moats. May 1997. (Format: TXT, HTML) (Obsoleted by RFC8141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2141) 2142 Mailbox Names for Common Services, Roles and Functions. D. Crocker. May 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2142) 2143 Encapsulating IP with the Small Computer System Interface. B. Elliston. May 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2143) 2144 The CAST-128 Encryption Algorithm. C. Adams. May 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2144) 2145 Use and Interpretation of HTTP Version Numbers. J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk. May 1997. (Format: TXT, HTML) (Obsoleted by RFC7230) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2145) 2146 U.S. Government Internet Domain Names. Federal Networking Council. May 1997. (Format: TXT, HTML) (Obsoletes RFC1816) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2146) 2147 TCP and UDP over IPv6 Jumbograms. D. Borman. May 1997. (Format: TXT, HTML) (Obsoleted by RFC2675) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2147) 2148 Deployment of the Internet White Pages Service. H. Alvestrand, P. Jurg. September 1997. (Format: TXT, HTML) (Also BCP0015) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2148) 2149 Multicast Server Architectures for MARS-based ATM multicasting. R. Talpade, M. Ammar. May 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2149) 2150 Humanities and Arts: Sharing Center Stage on the Internet. J. Max, W. Stickle. October 1997. (Format: TXT, HTML) (Also FYI0031) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2150) 2151 A Primer On Internet and TCP/IP Tools and Utilities. G. Kessler, S. Shepard. June 1997. (Format: TXT, HTML) (Obsoletes RFC1739) (Also FYI0030) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2151) 2152 UTF-7 A Mail-Safe Transformation Format of Unicode. D. Goldsmith, M. Davis. May 1997. (Format: TXT, HTML) (Obsoletes RFC1642) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2152) 2153 PPP Vendor Extensions. W. Simpson. May 1997. (Format: TXT, HTML) (Updates RFC1661, RFC1962) (Updated by RFC5342, RFC7042) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2153) 2154 OSPF with Digital Signatures. S. Murphy, M. Badger, B. Wellington. June 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2154) 2155 Definitions of Managed Objects for APPN using SMIv2. B. Clouston, B. Moore. June 1997. (Format: TXT, HTML) (Obsoleted by RFC2455) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2155) 2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME. S. Kille. January 1998. (Format: TXT, HTML) (Obsoletes RFC0987, RFC1026, RFC1138, RFC1148, RFC1327, RFC1495) (Updates RFC0822) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2156) 2157 Mapping between X.400 and RFC-822/MIME Message Bodies. H. Alvestrand. January 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2157) 2158 X.400 Image Body Parts. H. Alvestrand. January 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2158) 2159 A MIME Body Part for FAX. H. Alvestrand. January 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2159) 2160 Carrying PostScript in X.400 and MIME. H. Alvestrand. January 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2160) 2161 A MIME Body Part for ODA. H. Alvestrand. January 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2161) 2162 MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail. C. Allocchio. January 1998. (Format: TXT, HTML) (Obsoletes RFC1405) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2162) 2163 Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM). C. Allocchio. January 1998. (Format: TXT, HTML) (Obsoletes RFC1664) (Updated by RFC3597) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2163) 2164 Use of an X.500/LDAP directory to support MIXER address mapping. S. Kille. January 1998. (Format: TXT, HTML) (Obsoletes RFC1838) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2164) 2165 Service Location Protocol. J. Veizades, E. Guttman, C. Perkins, S. Kaplan. June 1997. (Format: TXT, HTML) (Updated by RFC2608, RFC2609) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2165) 2166 APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements. D. Bryant, P. Brittain. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2166) 2167 Referral Whois (RWhois) Protocol V1.5. S. Williamson, M. Kosters, D. Blacka, J. Singh, K. Zeilstra. June 1997. (Format: TXT, HTML) (Obsoletes RFC1714) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2167) 2168 Resolution of Uniform Resource Identifiers using the Domain Name System. R. Daniel, M. Mealling. June 1997. (Format: TXT, HTML) (Obsoleted by RFC3401, RFC3402, RFC3403, RFC3404) (Updated by RFC2915) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2168) 2169 A Trivial Convention for using HTTP in URN Resolution. R. Daniel. June 1997. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2169) 2170 Application REQuested IP over ATM (AREQUIPA). W. Almesberger, J. Le Boudec, P. Oechslin. July 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2170) 2171 MAPOS - Multiple Access Protocol over SONET/SDH Version 1. K. Murakami, M. Maruyama. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2171) 2172 MAPOS Version 1 Assigned Numbers. M. Maruyama, K. Murakami. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2172) 2173 A MAPOS version 1 Extension - Node Switch Protocol. K. Murakami, M. Maruyama. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2173) 2174 A MAPOS version 1 Extension - Switch-Switch Protocol. K. Murakami, M. Maruyama. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2174) 2175 MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing. K. Murakami, M. Maruyama. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2175) 2176 IPv4 over MAPOS Version 1. K. Murakami, M. Maruyama. June 1997. (Format: TXT, HTML) (Updated by RFC5494) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2176) 2177 IMAP4 IDLE command. B. Leiba. June 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2177) 2178 OSPF Version 2. J. Moy. July 1997. (Format: TXT, HTML) (Obsoletes RFC1583) (Obsoleted by RFC2328) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2178) 2179 Network Security For Trade Shows. A. Gwinn. July 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2179) 2180 IMAP4 Multi-Accessed Mailbox Practice. M. Gahrns. July 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2180) 2181 Clarifications to the DNS Specification. R. Elz, R. Bush. July 1997. (Format: TXT, HTML) (Updates RFC1034, RFC1035, RFC1123) (Updated by RFC4035, RFC2535, RFC4343, RFC4033, RFC4034, RFC5452, RFC8767) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2181) 2182 Selection and Operation of Secondary DNS Servers. R. Elz, R. Bush, S. Bradner, M. Patton. July 1997. (Format: TXT, HTML) (Also BCP0016) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2182) 2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field. R. Troost, S. Dorner, K. Moore, Ed.. August 1997. (Format: TXT, HTML) (Obsoletes RFC1806) (Updated by RFC2184, RFC2231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2183) 2184 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. August 1997. (Format: TXT, HTML) (Obsoleted by RFC2231) (Updates RFC2045, RFC2047, RFC2183) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2184) 2185 Routing Aspects of IPv6 Transition. R. Callon, D. Haskin. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2185) 2186 Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2186) 2187 Application of Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2187) 2188 AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2. M. Banan, M. Taylor, J. Cheng. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2188) 2189 Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --. A. Ballardie. September 1997. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2189) 2190 RTP Payload Format for H.263 Video Streams. C. Zhu. September 1997. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2190) 2191 VENUS - Very Extensive Non-Unicast Service. G. Armitage. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2191) 2192 IMAP URL Scheme. C. Newman. September 1997. (Format: TXT, HTML) (Obsoleted by RFC5092) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2192) 2193 IMAP4 Mailbox Referrals. M. Gahrns. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2193) 2194 Review of Roaming Implementations. B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2194) 2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response. J. Klensin, R. Catoe, P. Krumviede. September 1997. (Format: TXT, HTML) (Obsoletes RFC2095) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2195) 2196 Site Security Handbook. B. Fraser. September 1997. (Format: TXT, HTML) (Obsoletes RFC1244) (Also FYI0008) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2196) 2197 SMTP Service Extension for Command Pipelining. N. Freed. September 1997. (Format: TXT, HTML) (Obsoletes RFC1854) (Obsoleted by RFC2920) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2197) 2198 RTP Payload for Redundant Audio Data. C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. Bolot, A. Vega-Garcia, S. Fosse-Parisis. September 1997. (Format: TXT, HTML) (Updated by RFC6354) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2198) 2199 Request for Comments Summary RFC Numbers 2100-2199. A. Ramos. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2199) 2200 Internet Official Protocol Standards. J. Postel. June 1997. (Format: TXT, HTML) (Obsoletes RFC1250, RFC2000) (Obsoleted by RFC2300) (Status: HISTORIC) (DOI: 10.17487/RFC2200) 2201 Core Based Trees (CBT) Multicast Routing Architecture. A. Ballardie. September 1997. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2201) 2202 Test Cases for HMAC-MD5 and HMAC-SHA-1. P. Cheng, R. Glenn. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2202) 2203 RPCSEC_GSS Protocol Specification. M. Eisler, A. Chiu, L. Ling. September 1997. (Format: TXT, HTML) (Updated by RFC5403) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2203) 2204 ODETTE File Transfer Protocol. D. Nash. September 1997. (Format: TXT, HTML) (Obsoleted by RFC5024) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2204) 2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin. September 1997. (Format: TXT, HTML) (Updated by RFC2750, RFC3936, RFC4495, RFC5946, RFC6437, RFC6780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2205) 2206 RSVP Management Information Base using SMIv2. F. Baker, J. Krawczyk, A. Sastry. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2206) 2207 RSVP Extensions for IPSEC Data Flows. L. Berger, T. O'Malley. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2207) 2208 Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment. A. Mankin, Ed., F. Baker, B. Braden, S. Bradner, M. O'Dell, A. Romanow, A. Weinrib, L. Zhang. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2208) 2209 Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules. R. Braden, L. Zhang. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2209) 2210 The Use of RSVP with IETF Integrated Services. J. Wroclawski. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2210) 2211 Specification of the Controlled-Load Network Element Service. J. Wroclawski. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2211) 2212 Specification of Guaranteed Quality of Service. S. Shenker, C. Partridge, R. Guerin. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2212) 2213 Integrated Services Management Information Base using SMIv2. F. Baker, J. Krawczyk, A. Sastry. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2213) 2214 Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2. F. Baker, J. Krawczyk, A. Sastry. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2214) 2215 General Characterization Parameters for Integrated Service Network Elements. S. Shenker, J. Wroclawski. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2215) 2216 Network Element Service Specification Template. S. Shenker, J. Wroclawski. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2216) 2217 Telnet Com Port Control Option. G. Clark. October 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2217) 2218 A Common Schema for the Internet White Pages Service. T. Genovese, B. Jennings. October 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2218) 2219 Use of DNS Aliases for Network Services. M. Hamilton, R. Wright. October 1997. (Format: TXT, HTML) (Also BCP0017) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2219) 2220 The Application/MARC Content-type. R. Guenther. October 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2220) 2221 IMAP4 Login Referrals. M. Gahrns. October 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2221) 2222 Simple Authentication and Security Layer (SASL). J. Myers. October 1997. (Format: TXT, HTML) (Obsoleted by RFC4422, RFC4752) (Updated by RFC2444) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2222) 2223 Instructions to RFC Authors. J. Postel, J. Reynolds. October 1997. (Format: TXT, HTML) (Obsoletes RFC1543, RFC1111, RFC0825) (Obsoleted by RFC7322) (Updated by RFC5741, RFC6949) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2223) 2224 NFS URL Scheme. B. Callaghan. October 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2224) 2225 Classical IP and ARP over ATM. M. Laubach, J. Halpern. April 1998. (Format: TXT, HTML) (Obsoletes RFC1626, RFC1577) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2225) 2226 IP Broadcast over ATM Networks. T. Smith, G. Armitage. October 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2226) 2227 Simple Hit-Metering and Usage-Limiting for HTTP. J. Mogul, P. Leach. October 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2227) 2228 FTP Security Extensions. M. Horowitz, S. Lunt. October 1997. (Format: TXT, HTML) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2228) 2229 A Dictionary Server Protocol. R. Faith, B. Martin. October 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2229) 2230 Key Exchange Delegation Record for the DNS. R. Atkinson. November 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2230) 2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. November 1997. (Format: TXT, HTML) (Obsoletes RFC2184) (Updates RFC2045, RFC2047, RFC2183) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2231) 2232 Definitions of Managed Objects for DLUR using SMIv2. B. Clouston, Ed., B. Moore, Ed.. November 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2232) 2233 The Interfaces Group MIB using SMIv2. K. McCloghrie, F. Kastenholz. November 1997. (Format: TXT, HTML) (Obsoletes RFC1573) (Obsoleted by RFC2863) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2233) 2234 Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., P. Overell. November 1997. (Format: TXT, HTML) (Obsoleted by RFC4234) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2234) 2235 Hobbes' Internet Timeline. R. Zakon. November 1997. (Format: TXT, HTML) (Also FYI0032) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2235) 2236 Internet Group Management Protocol, Version 2. W. Fenner. November 1997. (Format: TXT, HTML) (Updates RFC1112) (Updated by RFC3376) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2236) 2237 Japanese Character Encoding for Internet Messages. K. Tamaru. November 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2237) 2238 Definitions of Managed Objects for HPR using SMIv2. B. Clouston, Ed., B. Moore, Ed.. November 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2238) 2239 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2. K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. November 1997. (Format: TXT, HTML) (Obsoleted by RFC2668) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2239) 2240 A Legal Basis for Domain Name Allocation. O. Vaughan. November 1997. (Format: TXT, HTML) (Obsoleted by RFC2352) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2240) 2241 DHCP Options for Novell Directory Services. D. Provan. November 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2241) 2242 NetWare/IP Domain Name and Information. R. Droms, K. Fong. November 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2242) 2243 OTP Extended Responses. C. Metz. November 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2243) 2244 ACAP -- Application Configuration Access Protocol. C. Newman, J. G. Myers. November 1997. (Format: TXT, HTML) (Updated by RFC6075) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2244) 2245 Anonymous SASL Mechanism. C. Newman. November 1997. (Format: TXT, HTML) (Obsoleted by RFC4505) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2245) 2246 The TLS Protocol Version 1.0. T. Dierks, C. Allen. January 1999. (Format: TXT, HTML) (Obsoleted by RFC4346) (Updated by RFC3546, RFC5746, RFC6176, RFC7465, RFC7507, RFC7919) (Status: HISTORIC) (DOI: 10.17487/RFC2246) 2247 Using Domains in LDAP/X.500 Distinguished Names. S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri. January 1998. (Format: TXT, HTML) (Updated by RFC4519, RFC4524) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2247) 2248 Network Services Monitoring MIB. N. Freed, S. Kille. January 1998. (Format: TXT, HTML) (Obsoletes RFC1565) (Obsoleted by RFC2788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2248) 2249 Mail Monitoring MIB. N. Freed, S. Kille. January 1998. (Format: TXT, HTML) (Obsoletes RFC1566) (Obsoleted by RFC2789) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2249) 2250 RTP Payload Format for MPEG1/MPEG2 Video. D. Hoffman, G. Fernando, V. Goyal, M. Civanlar. January 1998. (Format: TXT, HTML) (Obsoletes RFC2038) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2250) 2251 Lightweight Directory Access Protocol (v3). M. Wahl, T. Howes, S. Kille. December 1997. (Format: TXT, HTML) (Obsoleted by RFC4510, RFC4511, RFC4513, RFC4512) (Updated by RFC3377, RFC3771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2251) 2252 Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions. M. Wahl, A. Coulbeck, T. Howes, S. Kille. December 1997. (Format: TXT, HTML) (Obsoleted by RFC4510, RFC4517, RFC4523, RFC4512) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2252) 2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. M. Wahl, S. Kille, T. Howes. December 1997. (Format: TXT, HTML) (Obsoletes RFC1779) (Obsoleted by RFC4510, RFC4514) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2253) 2254 The String Representation of LDAP Search Filters. T. Howes. December 1997. (Format: TXT, HTML) (Obsoletes RFC1960) (Obsoleted by RFC4510, RFC4515) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2254) 2255 The LDAP URL Format. T. Howes, M. Smith. December 1997. (Format: TXT, HTML) (Obsoletes RFC1959) (Obsoleted by RFC4510, RFC4516) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2255) 2256 A Summary of the X.500(96) User Schema for use with LDAPv3. M. Wahl. December 1997. (Format: TXT, HTML) (Obsoleted by RFC4517, RFC4519, RFC4523, RFC4512, RFC4510) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2256) 2257 Agent Extensibility (AgentX) Protocol Version 1. M. Daniele, B. Wijnen, D. Francisco. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2741) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2257) 2258 Internet Nomenclator Project. J. Ordille. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2258) 2259 Simple Nomenclator Query Protocol (SNQP). J. Elliott, J. Ordille. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2259) 2260 Scalable Support for Multi-homed Multi-provider Connectivity. T. Bates, Y. Rekhter. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2260) 2261 An Architecture for Describing SNMP Management Frameworks. D. Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2261) 2262 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2272) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2262) 2263 SNMPv3 Applications. D. Levi, P. Meyer, B. Stewart. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2273) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2263) 2264 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2264) 2265 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2275) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2265) 2266 Definitions of Managed Objects for IEEE 802.12 Repeater Devices. J. Flick. January 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2266) 2267 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. P. Ferguson, D. Senie. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2827) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2267) 2268 A Description of the RC2(r) Encryption Algorithm. R. Rivest. March 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2268) 2269 Using the MARS Model in non-ATM NBMA Networks. G. Armitage. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2269) 2270 Using a Dedicated AS for Sites Homed to a Single Provider. J. Stewart, T. Bates, R. Chandra, E. Chen. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2270) 2271 An Architecture for Describing SNMP Management Frameworks. D. Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT, HTML) (Obsoletes RFC2261) (Obsoleted by RFC2571) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2271) 2272 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT, HTML) (Obsoletes RFC2262) (Obsoleted by RFC2572) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2272) 2273 SNMPv3 Applications. D. Levi, P. Meyer, B. Stewart. January 1998. (Format: TXT, HTML) (Obsoletes RFC2263) (Obsoleted by RFC2573) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2273) 2274 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. January 1998. (Format: TXT, HTML) (Obsoletes RFC2264) (Obsoleted by RFC2574) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2274) 2275 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. January 1998. (Format: TXT, HTML) (Obsoletes RFC2265) (Obsoleted by RFC2575) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2275) 2276 Architectural Principles of Uniform Resource Name Resolution. K. Sollins. January 1998. (Format: TXT, HTML) (Updated by RFC3401) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2276) 2277 IETF Policy on Character Sets and Languages. H. Alvestrand. January 1998. (Format: TXT, HTML) (Also BCP0018) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2277) 2278 IANA Charset Registration Procedures. N. Freed, J. Postel. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2978) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2278) 2279 UTF-8, a transformation format of ISO 10646. F. Yergeau. January 1998. (Format: TXT, HTML) (Obsoletes RFC2044) (Obsoleted by RFC3629) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2279) 2280 Routing Policy Specification Language (RPSL). C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra, C. Villamizar. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2280) 2281 Cisco Hot Standby Router Protocol (HSRP). T. Li, B. Cole, P. Morton, D. Li. March 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2281) 2282 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. J. Galvin. February 1998. (Format: TXT, HTML) (Obsoletes RFC2027) (Obsoleted by RFC2727) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2282) 2283 Multiprotocol Extensions for BGP-4. T. Bates, R. Chandra, D. Katz, Y. Rekhter. February 1998. (Format: TXT, HTML) (Obsoleted by RFC2858) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2283) 2284 PPP Extensible Authentication Protocol (EAP). L. Blunk, J. Vollbrecht. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3748) (Updated by RFC2484) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2284) 2285 Benchmarking Terminology for LAN Switching Devices. R. Mandeville. February 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2285) 2286 Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128. J. Kapp. February 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2286) 2287 Definitions of System-Level Managed Objects for Applications. C. Krupczak, J. Saperia. February 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2287) 2288 Using Existing Bibliographic Identifiers as Uniform Resource Names. C. Lynch, C. Preston, R. Daniel. February 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2288) 2289 A One-Time Password System. N. Haller, C. Metz, P. Nesser, M. Straw. February 1998. (Format: TXT, HTML) (Obsoletes RFC1938) (Also STD0061) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2289) 2290 Mobile-IPv4 Configuration Option for PPP IPCP. J. Solomon, S. Glass. February 1998. (Format: TXT, HTML) (Updates RFC2002) (Updated by RFC2794) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2290) 2291 Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web. J. Slein, F. Vitali, E. Whitehead, D. Durand. February 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2291) 2292 Advanced Sockets API for IPv6. W. Stevens, M. Thomas. February 1998. (Format: TXT, HTML) (Obsoleted by RFC3542) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2292) 2293 Representing Tables and Subtrees in the X.500 Directory. S. Kille. March 1998. (Format: TXT, HTML) (Obsoletes RFC1837) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2293) 2294 Representing the O/R Address hierarchy in the X.500 Directory Information Tree. S. Kille. March 1998. (Format: TXT, HTML) (Obsoletes RFC1836) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2294) 2295 Transparent Content Negotiation in HTTP. K. Holtman, A. Mutz. March 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2295) 2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0. K. Holtman, A. Mutz. March 1998. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2296) 2297 Ipsilon's General Switch Management Protocol Specification Version 2.0. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. March 1998. (Format: TXT, HTML) (Updates RFC1987) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2297) 2298 An Extensible Message Format for Message Disposition Notifications. R. Fajman. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3798) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2298) 2299 Request for Comments Summary. A. Ramos. January 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2299) 2300 Internet Official Protocol Standards. J. Postel. May 1998. (Format: TXT, HTML) (Obsoletes RFC2200) (Obsoleted by RFC2400) (Status: HISTORIC) (DOI: 10.17487/RFC2300) 2301 File Format for Internet Fax. L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3949) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2301) 2302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration. G. Parsons, J. Rafferty, S. Zilles. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3302) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2302) 2303 Minimal PSTN address format in Internet Mail. C. Allocchio. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3191) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2303) 2304 Minimal FAX address format in Internet Mail. C. Allocchio. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3192) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2304) 2305 A Simple Mode of Facsimile Using Internet Mail. K. Toyoda, H. Ohno, J. Murai, D. Wing. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3965) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2305) 2306 Tag Image File Format (TIFF) - F Profile for Facsimile. G. Parsons, J. Rafferty. March 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2306) 2307 An Approach for Using LDAP as a Network Information Service. L. Howard. March 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2307) 2308 Negative Caching of DNS Queries (DNS NCACHE). M. Andrews. March 1998. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Updated by RFC4035, RFC4033, RFC4034, RFC6604, RFC8020, RFC8499) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2308) 2309 Recommendations on Queue Management and Congestion Avoidance in the Internet. B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang. April 1998. (Format: TXT, HTML) (Obsoleted by RFC7567) (Updated by RFC7141) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2309) 2310 The Safe Response Header Field. K. Holtman. April 1998. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2310) 2311 S/MIME Version 2 Message Specification. S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka. March 1998. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2311) 2312 S/MIME Version 2 Certificate Handling. S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. March 1998. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2312) 2313 PKCS #1: RSA Encryption Version 1.5. B. Kaliski. March 1998. (Format: TXT, HTML) (Obsoleted by RFC2437) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2313) 2314 PKCS #10: Certification Request Syntax Version 1.5. B. Kaliski. March 1998. (Format: TXT, HTML) (Obsoleted by RFC2986) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2314) 2315 PKCS #7: Cryptographic Message Syntax Version 1.5. B. Kaliski. March 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2315) 2316 Report of the IAB Security Architecture Workshop. S. Bellovin. April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2316) 2317 Classless IN-ADDR.ARPA delegation. H. Eidnes, G. de Groot, P. Vixie. March 1998. (Format: TXT, HTML) (Also BCP0020) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2317) 2318 The text/css Media Type. H. Lie, B. Bos, C. Lilley. March 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2318) 2319 Ukrainian Character Set KOI8-U. KOI8-U Working Group. April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2319) 2320 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB). M. Greene, J. Luciani, K. White, T. Kuo. April 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2320) 2321 RITA -- The Reliable Internetwork Troubleshooting Agent. A. Bressen. 1 April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2321) 2322 Management of IP numbers by peg-dhcp. K. van den Hout, A. Koopal, R. van Mook. 1 April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2322) 2323 IETF Identification and Security Guidelines. A. Ramos. 1 April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2323) 2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). L. Masinter. 1 April 1998. (Format: TXT, HTML) (Updated by RFC7168) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2324) 2325 Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2. M. Slavitch. 1 April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2325) 2326 Real Time Streaming Protocol (RTSP). H. Schulzrinne, A. Rao, R. Lanphier. April 1998. (Format: TXT, HTML) (Obsoleted by RFC7826) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2326) 2327 SDP: Session Description Protocol. M. Handley, V. Jacobson. April 1998. (Format: TXT, HTML) (Obsoleted by RFC4566) (Updated by RFC3266) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2327) 2328 OSPF Version 2. J. Moy. April 1998. (Format: TXT, HTML) (Obsoletes RFC2178) (Updated by RFC5709, RFC6549, RFC6845, RFC6860, RFC7474, RFC8042) (Also STD0054) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2328) 2329 OSPF Standardization Report. J. Moy. April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2329) 2330 Framework for IP Performance Metrics. V. Paxson, G. Almes, J. Mahdavi, M. Mathis. May 1998. (Format: TXT, HTML) (Updated by RFC7312, RFC8468, RFC9198) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2330) 2331 ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update. M. Maher. April 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2331) 2332 NBMA Next Hop Resolution Protocol (NHRP). J. Luciani, D. Katz, D. Piscitello, B. Cole, N. Doraswamy. April 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2332) 2333 NHRP Protocol Applicability Statement. D. Cansever. April 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2333) 2334 Server Cache Synchronization Protocol (SCSP). J. Luciani, G. Armitage, J. Halpern, N. Doraswamy. April 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2334) 2335 A Distributed NHRP Service Using SCSP. J. Luciani. April 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2335) 2336 Classical IP and ARP over ATM to NHRP Transition. J. Luciani. July 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2336) 2337 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM. D. Farinacci, D. Meyer, Y. Rekhter. April 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2337) 2338 Virtual Router Redundancy Protocol. S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem. April 1998. (Format: TXT, HTML) (Obsoleted by RFC3768) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2338) 2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols. The Internet Society, Sun Microsystems. May 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2339) 2340 Nortel's Virtual Network Switching (VNS) Overview. B. Jamoussi, D. Jamieson, D. Williston, S. Gabe. May 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2340) 2341 Cisco Layer Two Forwarding (Protocol) "L2F". A. Valencia, M. Littlewood, T. Kolar. May 1998. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2341) 2342 IMAP4 Namespace. M. Gahrns, C. Newman. May 1998. (Format: TXT, HTML) (Updated by RFC4466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2342) 2343 RTP Payload Format for Bundled MPEG. M. Civanlar, G. Cash, B. Haskell. May 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2343) 2344 Reverse Tunneling for Mobile IP. G. Montenegro, Ed.. May 1998. (Format: TXT, HTML) (Obsoleted by RFC3024) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2344) 2345 Domain Names and Company Name Retrieval. J. Klensin, T. Wolf, G. Oglesby. May 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2345) 2346 Making Postscript and PDF International. J. Palme. May 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2346) 2347 TFTP Option Extension. G. Malkin, A. Harkin. May 1998. (Format: TXT, HTML) (Obsoletes RFC1782) (Updates RFC1350) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2347) 2348 TFTP Blocksize Option. G. Malkin, A. Harkin. May 1998. (Format: TXT, HTML) (Obsoletes RFC1783) (Updates RFC1350) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2348) 2349 TFTP Timeout Interval and Transfer Size Options. G. Malkin, A. Harkin. May 1998. (Format: TXT, HTML) (Obsoletes RFC1784) (Updates RFC1350) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2349) 2350 Expectations for Computer Security Incident Response. N. Brownlee, E. Guttman. June 1998. (Format: TXT, HTML) (Also BCP0021) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2350) 2351 Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP. A. Robert. May 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2351) 2352 A Convention For Using Legal Names as Domain Names. O. Vaughan. May 1998. (Format: TXT, HTML) (Obsoletes RFC2240) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2352) 2353 APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document. G. Dudley. May 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2353) 2354 Options for Repair of Streaming Media. C. Perkins, O. Hodson. June 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2354) 2355 TN3270 Enhancements. B. Kelly. June 1998. (Format: TXT, HTML) (Obsoletes RFC1647) (Updated by RFC6270) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2355) 2356 Sun's SKIP Firewall Traversal for Mobile IP. G. Montenegro, V. Gupta. June 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2356) 2357 IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols. A. Mankin, A. Romanow, S. Bradner, V. Paxson. June 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2357) 2358 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Flick, J. Johnson. June 1998. (Format: TXT, HTML) (Obsoletes RFC1650) (Obsoleted by RFC2665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2358) 2359 IMAP4 UIDPLUS extension. J. Myers. June 1998. (Format: TXT, HTML) (Obsoleted by RFC4315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2359) 2360 Guide for Internet Standards Writers. G. Scott. June 1998. (Format: TXT, HTML) (Also BCP0022) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2360) 2361 WAVE and AVI Codec Registries. E. Fleischman. June 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2361) 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June 1998. (Format: TXT, HTML) (Obsoletes RFC2117) (Obsoleted by RFC4601, RFC5059) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2362) 2363 PPP Over FUNI. G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. July 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2363) 2364 PPP Over AAL5. G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. July 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2364) 2365 Administratively Scoped IP Multicast. D. Meyer. July 1998. (Format: TXT, HTML) (Also BCP0023) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2365) 2366 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks. C. Chung, M. Greene. July 1998. (Format: TXT, HTML) (Obsoleted by RFC2417) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2366) 2367 PF_KEY Key Management API, Version 2. D. McDonald, C. Metz, B. Phan. July 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2367) 2368 The mailto URL scheme. P. Hoffman, L. Masinter, J. Zawinski. July 1998. (Format: TXT, HTML) (Obsoleted by RFC6068) (Updates RFC1738, RFC1808) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2368) 2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields. G. Neufeld, J. Baer. July 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2369) 2370 The OSPF Opaque LSA Option. R. Coltun. July 1998. (Format: TXT, HTML) (Obsoleted by RFC5250) (Updated by RFC3630) (Also RFC2328) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2370) 2371 Transaction Internet Protocol Version 3.0. J. Lyon, K. Evans, J. Klein. July 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2371) 2372 Transaction Internet Protocol - Requirements and Supplemental Information. K. Evans, J. Klein, J. Lyon. July 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2372) 2373 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. July 1998. (Format: TXT, HTML) (Obsoletes RFC1884) (Obsoleted by RFC3513) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2373) 2374 An IPv6 Aggregatable Global Unicast Address Format. R. Hinden, M. O'Dell, S. Deering. July 1998. (Format: TXT, HTML) (Obsoletes RFC2073) (Obsoleted by RFC3587) (Status: HISTORIC) (DOI: 10.17487/RFC2374) 2375 IPv6 Multicast Address Assignments. R. Hinden, S. Deering. July 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2375) 2376 XML Media Types. E. Whitehead, M. Murata. July 1998. (Format: TXT, HTML) (Obsoleted by RFC3023) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2376) 2377 Naming Plan for Internet Directory-Enabled Applications. A. Grimstad, R. Huber, S. Sataluri, M. Wahl. September 1998. (Format: TXT, HTML) (Updated by RFC4519) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2377) 2378 The CCSO Nameserver (Ph) Architecture. R. Hedberg, P. Pomes. September 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2378) 2379 RSVP over ATM Implementation Guidelines. L. Berger. August 1998. (Format: TXT, HTML) (Also BCP0024) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2379) 2380 RSVP over ATM Implementation Requirements. L. Berger. August 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2380) 2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM. M. Garrett, M. Borden. August 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2381) 2382 A Framework for Integrated Services and RSVP over ATM. E. Crawley, Ed., L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk. August 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2382) 2383 ST2+ over ATM Protocol Specification - UNI 3.1 Version. M. Suzuki. August 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2383) 2384 POP URL Scheme. R. Gellens. August 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2384) 2385 Protection of BGP Sessions via the TCP MD5 Signature Option. A. Heffernan. August 1998. (Format: TXT, HTML) (Obsoleted by RFC5925) (Updated by RFC6691) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2385) 2386 A Framework for QoS-based Routing in the Internet. E. Crawley, R. Nair, B. Rajagopalan, H. Sandick. August 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2386) 2387 The MIME Multipart/Related Content-type. E. Levinson. August 1998. (Format: TXT, HTML) (Obsoletes RFC2112) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2387) 2388 Returning Values from Forms: multipart/form-data. L. Masinter. August 1998. (Format: TXT, HTML) (Obsoleted by RFC7578) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2388) 2389 Feature negotiation mechanism for the File Transfer Protocol. P. Hethmon, R. Elz. August 1998. (Format: TXT, HTML) (Also RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2389) 2390 Inverse Address Resolution Protocol. T. Bradley, C. Brown, A. Malis. September 1998. (Format: TXT, HTML) (Obsoletes RFC1293) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2390) 2391 Load Sharing using IP Network Address Translation (LSNAT). P. Srisuresh, D. Gan. August 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2391) 2392 Content-ID and Message-ID Uniform Resource Locators. E. Levinson. August 1998. (Format: TXT, HTML) (Obsoletes RFC2111) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2392) 2393 IP Payload Compression Protocol (IPComp). A. Shacham, R. Monsour, R. Pereira, M. Thomas. December 1998. (Format: TXT, HTML) (Obsoleted by RFC3173) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2393) 2394 IP Payload Compression Using DEFLATE. R. Pereira. December 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2394) 2395 IP Payload Compression Using LZS. R. Friend, R. Monsour. December 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2395) 2396 Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. August 1998. (Format: TXT, HTML) (Obsoleted by RFC3986) (Updates RFC1808, RFC1738) (Updated by RFC2732) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2396) 2397 The "data" URL scheme. L. Masinter. August 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2397) 2398 Some Testing Tools for TCP Implementors. S. Parker, C. Schmechel. August 1998. (Format: TXT, HTML) (Also FYI0033) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2398) 2399 Request for Comments Summary. A. Ramos. January 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2399) 2400 Internet Official Protocol Standards. J. Postel, J. Reynolds. September 1998. (Format: TXT, HTML) (Obsoletes RFC2300) (Obsoleted by RFC2500) (Status: HISTORIC) (DOI: 10.17487/RFC2400) 2401 Security Architecture for the Internet Protocol. S. Kent, R. Atkinson. November 1998. (Format: TXT, HTML) (Obsoletes RFC1825) (Obsoleted by RFC4301) (Updated by RFC3168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2401) 2402 IP Authentication Header. S. Kent, R. Atkinson. November 1998. (Format: TXT, HTML) (Obsoletes RFC1826) (Obsoleted by RFC4302, RFC4305) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2402) 2403 The Use of HMAC-MD5-96 within ESP and AH. C. Madson, R. Glenn. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2403) 2404 The Use of HMAC-SHA-1-96 within ESP and AH. C. Madson, R. Glenn. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2404) 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV. C. Madson, N. Doraswamy. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2405) 2406 IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson. November 1998. (Format: TXT, HTML) (Obsoletes RFC1827) (Obsoleted by RFC4303, RFC4305) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2406) 2407 The Internet IP Security Domain of Interpretation for ISAKMP. D. Piper. November 1998. (Format: TXT, HTML) (Obsoleted by RFC4306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2407) 2408 Internet Security Association and Key Management Protocol (ISAKMP). D. Maughan, M. Schertler, M. Schneider, J. Turner. November 1998. (Format: TXT, HTML) (Obsoleted by RFC4306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2408) 2409 The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November 1998. (Format: TXT, HTML) (Obsoleted by RFC4306) (Updated by RFC4109) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2409) 2410 The NULL Encryption Algorithm and Its Use With IPsec. R. Glenn, S. Kent. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2410) 2411 IP Security Document Roadmap. R. Thayer, N. Doraswamy, R. Glenn. November 1998. (Format: TXT, HTML) (Obsoleted by RFC6071) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2411) 2412 The OAKLEY Key Determination Protocol. H. Orman. November 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2412) 2413 Dublin Core Metadata for Resource Discovery. S. Weibel, J. Kunze, C. Lagoze, M. Wolf. September 1998. (Format: TXT, HTML) (Obsoleted by RFC5013) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2413) 2414 Increasing TCP's Initial Window. M. Allman, S. Floyd, C. Partridge. September 1998. (Format: TXT, HTML) (Obsoleted by RFC3390) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2414) 2415 Simulation Studies of Increased Initial TCP Window Size. K. Poduri, K. Nichols. September 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2415) 2416 When TCP Starts Up With Four Packets Into Only Three Buffers. T. Shepard, C. Partridge. September 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2416) 2417 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks. C. Chung, M. Greene. September 1998. (Format: TXT, HTML) (Obsoletes RFC2366) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2417) 2418 IETF Working Group Guidelines and Procedures. S. Bradner. September 1998. (Format: TXT, HTML) (Obsoletes RFC1603) (Updated by RFC3934, RFC7475, RFC7776, RFC8717, RFC9141) (Also BCP0025) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2418) 2419 The PPP DES Encryption Protocol, Version 2 (DESE-bis). K. Sklower, G. Meyer. September 1998. (Format: TXT, HTML) (Obsoletes RFC1969) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2419) 2420 The PPP Triple-DES Encryption Protocol (3DESE). H. Kummert. September 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2420) 2421 Voice Profile for Internet Mail - version 2. G. Vaudreuil, G. Parsons. September 1998. (Format: TXT, HTML) (Obsoletes RFC1911) (Obsoleted by RFC3801) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2421) 2422 Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration. G. Vaudreuil, G. Parsons. September 1998. (Format: TXT, HTML) (Obsoletes RFC1911) (Obsoleted by RFC3802) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2422) 2423 VPIM Voice Message MIME Sub-type Registration. G. Vaudreuil, G. Parsons. September 1998. (Format: TXT, HTML) (Obsoletes RFC1911) (Obsoleted by RFC3801) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2423) 2424 Content Duration MIME Header Definition. G. Vaudreuil, G. Parsons. September 1998. (Format: TXT, HTML) (Obsoleted by RFC3803) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2424) 2425 A MIME Content-Type for Directory Information. T. Howes, M. Smith, F. Dawson. September 1998. (Format: TXT, HTML) (Obsoleted by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2425) 2426 vCard MIME Directory Profile. F. Dawson, T. Howes. September 1998. (Format: TXT, HTML) (Obsoleted by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2426) 2427 Multiprotocol Interconnect over Frame Relay. C. Brown, A. Malis. September 1998. (Format: TXT, HTML) (Obsoletes RFC1490, RFC1294) (Also STD0055) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2427) 2428 FTP Extensions for IPv6 and NATs. M. Allman, S. Ostermann, C. Metz. September 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2428) 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. October 1998. (Format: TXT, HTML) (Obsoleted by RFC4629) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2429) 2430 A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE). T. Li, Y. Rekhter. October 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2430) 2431 RTP Payload Format for BT.656 Video Encoding. D. Tynan. October 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2431) 2432 Terminology for IP Multicast Benchmarking. K. Dubray. October 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2432) 2433 Microsoft PPP CHAP Extensions. G. Zorn, S. Cobb. October 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2433) 2434 Guidelines for Writing an IANA Considerations Section in RFCs. T. Narten, H. Alvestrand. October 1998. (Format: TXT, HTML) (Obsoleted by RFC5226) (Updated by RFC3692) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2434) 2435 RTP Payload Format for JPEG-compressed Video. L. Berc, W. Fenner, R. Frederick, S. McCanne, P. Stewart. October 1998. (Format: TXT, HTML) (Obsoletes RFC2035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2435) 2436 Collaboration between ISOC/IETF and ITU-T. R. Brett, S. Bradner, G. Parsons. October 1998. (Format: TXT, HTML) (Obsoleted by RFC3356) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2436) 2437 PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski, J. Staddon. October 1998. (Format: TXT, HTML) (Obsoletes RFC2313) (Obsoleted by RFC3447) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2437) 2438 Advancement of MIB specifications on the IETF Standards Track. M. O'Dell, H. Alvestrand, B. Wijnen, S. Bradner. October 1998. (Format: TXT, HTML) (Also BCP0027) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2438) 2439 BGP Route Flap Damping. C. Villamizar, R. Chandra, R. Govindan. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2439) 2440 OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, R. Thayer. November 1998. (Format: TXT, HTML) (Obsoleted by RFC4880) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2440) 2441 Working with Jon, Tribute delivered at UCLA, October 30, 1998. D. Cohen. November 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2441) 2442 The Batch SMTP Media Type. N. Freed, D. Newman, J. Belissent, M. Hoy. November 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2442) 2443 A Distributed MARS Service Using SCSP. J. Luciani, A. Gallo. November 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2443) 2444 The One-Time-Password SASL Mechanism. C. Newman. October 1998. (Format: TXT, HTML) (Updates RFC2222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2444) 2445 Internet Calendaring and Scheduling Core Object Specification (iCalendar). F. Dawson, D. Stenerson. November 1998. (Format: TXT, HTML) (Obsoleted by RFC5545) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2445) 2446 iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries. S. Silverberg, S. Mansour, F. Dawson, R. Hopson. November 1998. (Format: TXT, HTML) (Obsoleted by RFC5546) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2446) 2447 iCalendar Message-Based Interoperability Protocol (iMIP). F. Dawson, S. Mansour, S. Silverberg. November 1998. (Format: TXT, HTML) (Obsoleted by RFC6047) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2447) 2448 AT&T's Error Resilient Video Transmission Technique. M. Civanlar, G. Cash, B. Haskell. November 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2448) 2449 POP3 Extension Mechanism. R. Gellens, C. Newman, L. Lundblade. November 1998. (Format: TXT, HTML) (Updates RFC1939) (Updated by RFC5034) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2449) 2450 Proposed TLA and NLA Assignment Rule. R. Hinden. December 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2450) 2451 The ESP CBC-Mode Cipher Algorithms. R. Pereira, R. Adams. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2451) 2452 IP Version 6 Management Information Base for the Transmission Control Protocol. M. Daniele. December 1998. (Format: TXT, HTML) (Obsoleted by RFC4022, RFC8096) (Status: HISTORIC) (DOI: 10.17487/RFC2452) 2453 RIP Version 2. G. Malkin. November 1998. (Format: TXT, HTML) (Obsoletes RFC1723) (Updated by RFC4822) (Also STD0056) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2453) 2454 IP Version 6 Management Information Base for the User Datagram Protocol. M. Daniele. December 1998. (Format: TXT, HTML) (Obsoleted by RFC4113, RFC8096) (Status: HISTORIC) (DOI: 10.17487/RFC2454) 2455 Definitions of Managed Objects for APPN. B. Clouston, B. Moore. November 1998. (Format: TXT, HTML) (Obsoletes RFC2155) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2455) 2456 Definitions of Managed Objects for APPN TRAPS. B. Clouston, B. Moore. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2456) 2457 Definitions of Managed Objects for Extended Border Node. B. Clouston, B. Moore. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2457) 2458 Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations. H. Lu, M. Krishnaswamy, L. Conroy, S. Bellovin, F. Burg, A. DeSimone, K. Tewani, P. Davidson, H. Schulzrinne, K. Vishwanathan. November 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2458) 2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile. R. Housley, W. Ford, W. Polk, D. Solo. January 1999. (Format: TXT, HTML) (Obsoleted by RFC3280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2459) 2460 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. December 1998. (Format: TXT, HTML) (Obsoletes RFC1883) (Obsoleted by RFC8200) (Updated by RFC5095, RFC5722, RFC5871, RFC6437, RFC6564, RFC6935, RFC6946, RFC7045, RFC7112) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2460) 2461 Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson. December 1998. (Format: TXT, HTML) (Obsoletes RFC1970) (Obsoleted by RFC4861) (Updated by RFC4311) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2461) 2462 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. December 1998. (Format: TXT, HTML) (Obsoletes RFC1971) (Obsoleted by RFC4862) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2462) 2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering. December 1998. (Format: TXT, HTML) (Obsoletes RFC1885) (Obsoleted by RFC4443) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2463) 2464 Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. December 1998. (Format: TXT, HTML) (Obsoletes RFC1972) (Updated by RFC6085, RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2464) 2465 Management Information Base for IP Version 6: Textual Conventions and General Group. D. Haskin, S. Onishi. December 1998. (Format: TXT, HTML) (Obsoleted by RFC4293, RFC8096) (Status: HISTORIC) (DOI: 10.17487/RFC2465) 2466 Management Information Base for IP Version 6: ICMPv6 Group. D. Haskin, S. Onishi. December 1998. (Format: TXT, HTML) (Obsoleted by RFC4293, RFC8096) (Status: HISTORIC) (DOI: 10.17487/RFC2466) 2467 Transmission of IPv6 Packets over FDDI Networks. M. Crawford. December 1998. (Format: TXT, HTML) (Obsoletes RFC2019) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2467) 2468 I REMEMBER IANA. V. Cerf. October 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2468) 2469 A Caution On The Canonical Ordering Of Link-Layer Addresses. T. Narten, C. Burton. December 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2469) 2470 Transmission of IPv6 Packets over Token Ring Networks. M. Crawford, T. Narten, S. Thomas. December 1998. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2470) 2471 IPv6 Testing Address Allocation. R. Hinden, R. Fink, J. Postel. December 1998. (Format: TXT, HTML) (Obsoletes RFC1897) (Obsoleted by RFC3701) (Status: HISTORIC) (DOI: 10.17487/RFC2471) 2472 IP Version 6 over PPP. D. Haskin, E. Allen. December 1998. (Format: TXT, HTML) (Obsoletes RFC2023) (Obsoleted by RFC5072, RFC5172) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2472) 2473 Generic Packet Tunneling in IPv6 Specification. A. Conta, S. Deering. December 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2473) 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, D. Black. December 1998. (Format: TXT, HTML) (Obsoletes RFC1455, RFC1349) (Updates RFC0791) (Updated by RFC3168, RFC3260, RFC8436) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2474) 2475 An Architecture for Differentiated Services. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. December 1998. (Format: TXT, HTML) (Updated by RFC3260) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2475) 2476 Message Submission. R. Gellens, J. Klensin. December 1998. (Format: TXT, HTML) (Obsoleted by RFC4409) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2476) 2477 Criteria for Evaluating Roaming Protocols. B. Aboba, G. Zorn. January 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2477) 2478 The Simple and Protected GSS-API Negotiation Mechanism. E. Baize, D. Pinkas. December 1998. (Format: TXT, HTML) (Obsoleted by RFC4178) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2478) 2479 Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API). C. Adams. December 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2479) 2480 Gateways and MIME Security Multiparts. N. Freed. January 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2480) 2481 A Proposal to add Explicit Congestion Notification (ECN) to IP. K. Ramakrishnan, S. Floyd. January 1999. (Format: TXT, HTML) (Obsoleted by RFC3168) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2481) 2482 Language Tagging in Unicode Plain Text. K. Whistler, G. Adams. January 1999. (Format: TXT, HTML) (Obsoleted by RFC6082) (Status: HISTORIC) (DOI: 10.17487/RFC2482) 2483 URI Resolution Services Necessary for URN Resolution. M. Mealling, R. Daniel. January 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2483) 2484 PPP LCP Internationalization Configuration Option. G. Zorn. January 1999. (Format: TXT, HTML) (Updates RFC2284, RFC1994, RFC1570) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2484) 2485 DHCP Option for The Open Group's User Authentication Protocol. S. Drach. January 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2485) 2486 The Network Access Identifier. B. Aboba, M. Beadles. January 1999. (Format: TXT, HTML) (Obsoleted by RFC4282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2486) 2487 SMTP Service Extension for Secure SMTP over TLS. P. Hoffman. January 1999. (Format: TXT, HTML) (Obsoleted by RFC3207) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2487) 2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms. M. Allman, D. Glover, L. Sanchez. January 1999. (Format: TXT, HTML) (Also BCP0028) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2488) 2489 Procedure for Defining New DHCP Options. R. Droms. January 1999. (Format: TXT, HTML) (Obsoleted by RFC2939) (Also BCP0029) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2489) 2490 A Simulation Model for IP Multicast with RSVP. M. Pullen, R. Malghan, L. Lavu, G. Duan, J. Ma, H. Nah. January 1999. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2490) 2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks. G. Armitage, P. Schulter, M. Jork, G. Harter. January 1999. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2491) 2492 IPv6 over ATM Networks. G. Armitage, P. Schulter, M. Jork. January 1999. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2492) 2493 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals. K. Tesink, Ed.. January 1999. (Format: TXT, HTML) (Obsoleted by RFC3593) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2493) 2494 Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type. D. Fowler, Ed.. January 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2494) 2495 Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types. D. Fowler, Ed.. January 1999. (Format: TXT, HTML) (Obsoletes RFC1406) (Obsoleted by RFC3895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2495) 2496 Definitions of Managed Object for the DS3/E3 Interface Type. D. Fowler, Ed.. January 1999. (Format: TXT, HTML) (Obsoletes RFC1407) (Obsoleted by RFC3896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2496) 2497 Transmission of IPv6 Packets over ARCnet Networks. I. Souvatzis. January 1999. (Format: TXT, HTML) (Updated by RFC8064) (Also RFC1201) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2497) 2498 IPPM Metrics for Measuring Connectivity. J. Mahdavi, V. Paxson. January 1999. (Format: TXT, HTML) (Obsoleted by RFC2678) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2498) 2499 Request for Comments Summary. A. Ramos. July 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2499) 2500 Internet Official Protocol Standards. J. Reynolds, R. Braden. June 1999. (Format: TXT, HTML) (Obsoletes RFC2400) (Obsoleted by RFC2600) (Status: HISTORIC) (DOI: 10.17487/RFC2500) 2501 Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations. S. Corson, J. Macker. January 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2501) 2502 Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment. M. Pullen, M. Myjak, C. Bouwens. February 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2502) 2503 MIME Types for Use with the ISO ILL Protocol. R. Moulton, M. Needleman. February 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2503) 2504 Users' Security Handbook. E. Guttman, L. Leong, G. Malkin. February 1999. (Format: TXT, HTML) (Also FYI0034) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2504) 2505 Anti-Spam Recommendations for SMTP MTAs. G. Lindberg. February 1999. (Format: TXT, HTML) (Also BCP0030) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2505) 2506 Media Feature Tag Registration Procedure. K. Holtman, A. Mutz, T. Hardie. March 1999. (Format: TXT, HTML) (Also BCP0031) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2506) 2507 IP Header Compression. M. Degermark, B. Nordgren, S. Pink. February 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2507) 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. S. Casner, V. Jacobson. February 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2508) 2509 IP Header Compression over PPP. M. Engan, S. Casner, C. Bormann. February 1999. (Format: TXT, HTML) (Obsoleted by RFC3544) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2509) 2510 Internet X.509 Public Key Infrastructure Certificate Management Protocols. C. Adams, S. Farrell. March 1999. (Format: TXT, HTML) (Obsoleted by RFC4210) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2510) 2511 Internet X.509 Certificate Request Message Format. M. Myers, C. Adams, D. Solo, D. Kemp. March 1999. (Format: TXT, HTML) (Obsoleted by RFC4211) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2511) 2512 Accounting Information for ATM Networks. K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. February 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2512) 2513 Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks. K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. February 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2513) 2514 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management. M. Noto, E. Spiegel, K. Tesink. February 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2514) 2515 Definitions of Managed Objects for ATM Management. K. Tesink, Ed.. February 1999. (Format: TXT, HTML) (Obsoletes RFC1695) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2515) 2516 A Method for Transmitting PPP Over Ethernet (PPPoE). L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler. February 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2516) 2517 Building Directories from DNS: Experiences from WWWSeeker. R. Moats, R. Huber. February 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2517) 2518 HTTP Extensions for Distributed Authoring -- WEBDAV. Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen. February 1999. (Format: TXT, HTML) (Obsoleted by RFC4918) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2518) 2519 A Framework for Inter-Domain Route Aggregation. E. Chen, J. Stewart. February 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2519) 2520 NHRP with Mobile NHCs. J. Luciani, H. Suzuki, N. Doraswamy, D. Horton. February 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2520) 2521 ICMP Security Failures Messages. P. Karn, W. Simpson. March 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2521) 2522 Photuris: Session-Key Management Protocol. P. Karn, W. Simpson. March 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2522) 2523 Photuris: Extended Schemes and Attributes. P. Karn, W. Simpson. March 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2523) 2524 Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3. M. Banan. February 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2524) 2525 Known TCP Implementation Problems. V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, I. Heavens, K. Lahey, J. Semke, B. Volz. March 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2525) 2526 Reserved IPv6 Subnet Anycast Addresses. D. Johnson, S. Deering. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2526) 2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. S. Chokhani, W. Ford. March 1999. (Format: TXT, HTML) (Obsoleted by RFC3647) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2527) 2528 Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates. R. Housley, W. Polk. March 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2528) 2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. B. Carpenter, C. Jung. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2529) 2530 Indicating Supported Media Features Using Extensions to DSN and MDN. D. Wing. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2530) 2531 Content Feature Schema for Internet Fax. G. Klyne, L. McIntyre. March 1999. (Format: TXT, HTML) (Obsoleted by RFC2879) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2531) 2532 Extended Facsimile Using Internet Mail. L. Masinter, D. Wing. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2532) 2533 A Syntax for Describing Media Feature Sets. G. Klyne. March 1999. (Format: TXT, HTML) (Updated by RFC2738, RFC2938) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2533) 2534 Media Features for Display, Print, and Fax. L. Masinter, D. Wing, A. Mutz, K. Holtman. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2534) 2535 Domain Name System Security Extensions. D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (Obsoletes RFC2065) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC2181, RFC1035, RFC1034) (Updated by RFC2931, RFC3007, RFC3008, RFC3090, RFC3226, RFC3445, RFC3597, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2535) 2536 DSA KEYs and SIGs in the Domain Name System (DNS). D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2536) 2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS). D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (Obsoleted by RFC3110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2537) 2538 Storing Certificates in the Domain Name System (DNS). D. Eastlake 3rd, O. Gudmundsson. March 1999. (Format: TXT, HTML) (Obsoleted by RFC4398) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2538) 2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS). D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2539) 2540 Detached Domain Name System (DNS) Information. D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2540) 2541 DNS Security Operational Considerations. D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (Obsoleted by RFC4641) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2541) 2542 Terminology and Goals for Internet Fax. L. Masinter. March 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2542) 2543 SIP: Session Initiation Protocol. M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg. March 1999. (Format: TXT, HTML) (Obsoleted by RFC3261, RFC3262, RFC3263, RFC3264, RFC3265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2543) 2544 Benchmarking Methodology for Network Interconnect Devices. S. Bradner, J. McQuaid. March 1999. (Format: TXT, HTML) (Obsoletes RFC1944) (Updated by RFC6201, RFC6815, RFC9004) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2544) 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing. P. Marques, F. Dupont. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2545) 2546 6Bone Routing Practice. A. Durand, B. Buclin. March 1999. (Format: TXT, HTML) (Obsoleted by RFC2772) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2546) 2547 BGP/MPLS VPNs. E. Rosen, Y. Rekhter. March 1999. (Format: TXT, HTML) (Obsoleted by RFC4364) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2547) 2548 Microsoft Vendor-specific RADIUS Attributes. G. Zorn. March 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2548) 2549 IP over Avian Carriers with Quality of Service. D. Waitzman. 1 April 1999. (Format: TXT, HTML) (Updates RFC1149) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2549) 2550 Y10K and Beyond. S. Glassman, M. Manasse, J. Mogul. 1 April 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2550) 2551 The Roman Standards Process -- Revision III. S. Bradner. 1 April 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2551) 2552 Architecture for the Information Brokerage in the ACTS Project GAIA. M. Blinov, M. Bessonov, C. Clissmann. April 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2552) 2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. March 1999. (Format: TXT, HTML) (Obsoletes RFC2133) (Obsoleted by RFC3493) (Updated by RFC3152) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2553) 2554 SMTP Service Extension for Authentication. J. Myers. March 1999. (Format: TXT, HTML) (Obsoleted by RFC4954) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2554) 2555 30 Years of RFCs. RFC Editor, et al.. April 1999. (Format: TXT, HTML) (Updated by RFC8700) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2555) 2556 OSI connectionless transport services on top of UDP Applicability Statement for Historic Status. S. Bradner. March 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2556) 2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML). J. Palme, A. Hopmann, N. Shelness. March 1999. (Format: TXT, HTML) (Obsoletes RFC2110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2557) 2558 Definitions of Managed Objects for the SONET/SDH Interface Type. K. Tesink. March 1999. (Format: TXT, HTML) (Obsoletes RFC1595) (Obsoleted by RFC3592) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2558) 2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2. S. Boeyen, T. Howes, P. Richard. April 1999. (Format: TXT, HTML) (Obsoleted by RFC3494) (Updates RFC1778) (Status: HISTORIC) (DOI: 10.17487/RFC2559) 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. June 1999. (Format: TXT, HTML) (Obsoleted by RFC6960) (Updated by RFC6277) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2560) 2561 Base Definitions of Managed Objects for TN3270E Using SMIv2. K. White, R. Moore. April 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2561) 2562 Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB). K. White, R. Moore. April 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2562) 2563 DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients. R. Troll. May 1999. (Format: TXT, HTML) (Updated by RFC8925) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2563) 2564 Application Management MIB. C. Kalbfleisch, C. Krupczak, R. Presuhn, J. Saperia. May 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2564) 2565 Internet Printing Protocol/1.0: Encoding and Transport. R. Herriot, Ed., S. Butler, P. Moore, R. Turner. April 1999. (Format: TXT, HTML) (Obsoleted by RFC2910) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2565) 2566 Internet Printing Protocol/1.0: Model and Semantics. R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell. April 1999. (Format: TXT, HTML) (Obsoleted by RFC2911) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2566) 2567 Design Goals for an Internet Printing Protocol. F. Wright. April 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2567) 2568 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol. S. Zilles. April 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2568) 2569 Mapping between LPD and IPP Protocols. R. Herriot, Ed., T. Hastings, N. Jacobs, J. Martin. April 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2569) 2570 Introduction to Version 3 of the Internet-standard Network Management Framework. J. Case, R. Mundy, D. Partain, B. Stewart. April 1999. (Format: TXT, HTML) (Obsoleted by RFC3410) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2570) 2571 An Architecture for Describing SNMP Management Frameworks. B. Wijnen, D. Harrington, R. Presuhn. April 1999. (Format: TXT, HTML) (Obsoletes RFC2271) (Obsoleted by RFC3411) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2571) 2572 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. April 1999. (Format: TXT, HTML) (Obsoletes RFC2272) (Obsoleted by RFC3412) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2572) 2573 SNMP Applications. D. Levi, P. Meyer, B. Stewart. April 1999. (Format: TXT, HTML) (Obsoletes RFC2273) (Obsoleted by RFC3413) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2573) 2574 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. April 1999. (Format: TXT, HTML) (Obsoletes RFC2274) (Obsoleted by RFC3414) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2574) 2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. April 1999. (Format: TXT, HTML) (Obsoletes RFC2275) (Obsoleted by RFC3415) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2575) 2576 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework. R. Frye, D. Levi, S. Routhier, B. Wijnen. March 2000. (Format: TXT, HTML) (Obsoletes RFC1908, RFC2089) (Obsoleted by RFC3584) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2576) 2577 FTP Security Considerations. M. Allman, S. Ostermann. May 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2577) 2578 Structure of Management Information Version 2 (SMIv2). K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed.. April 1999. (Format: TXT, HTML) (Obsoletes RFC1902) (Also STD0058) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2578) 2579 Textual Conventions for SMIv2. K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed.. April 1999. (Format: TXT, HTML) (Obsoletes RFC1903) (Also STD0058) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2579) 2580 Conformance Statements for SMIv2. K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed.. April 1999. (Format: TXT, HTML) (Obsoletes RFC1904) (Also STD0058) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2580) 2581 TCP Congestion Control. M. Allman, V. Paxson, W. Stevens. April 1999. (Format: TXT, HTML) (Obsoletes RFC2001) (Obsoleted by RFC5681) (Updated by RFC3390) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2581) 2582 The NewReno Modification to TCP's Fast Recovery Algorithm. S. Floyd, T. Henderson. April 1999. (Format: TXT, HTML) (Obsoleted by RFC3782) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2582) 2583 Guidelines for Next Hop Client (NHC) Developers. R. Carlson, L. Winkler. May 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2583) 2584 Definitions of Managed Objects for APPN/HPR in IP Networks. B. Clouston, B. Moore. May 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2584) 2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP. R. Housley, P. Hoffman. May 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2585) 2586 The Audio/L16 MIME content type. J. Salsman, H. Alvestrand. May 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2586) 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema. S. Boeyen, T. Howes, P. Richard. June 1999. (Format: TXT, HTML) (Obsoleted by RFC4523) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2587) 2588 IP Multicast and Firewalls. R. Finlayson. May 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2588) 2589 Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services. Y. Yaacovi, M. Wahl, T. Genovese. May 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2589) 2590 Transmission of IPv6 Packets over Frame Relay Networks Specification. A. Conta, A. Malis, M. Mueller. May 1999. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2590) 2591 Definitions of Managed Objects for Scheduling Management Operations. D. Levi, J. Schoenwaelder. May 1999. (Format: TXT, HTML) (Obsoleted by RFC3231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2591) 2592 Definitions of Managed Objects for the Delegation of Management Script. D. Levi, J. Schoenwaelder. May 1999. (Format: TXT, HTML) (Obsoleted by RFC3165) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2592) 2593 Script MIB Extensibility Protocol Version 1.0. J. Schoenwaelder, J. Quittek. May 1999. (Format: TXT, HTML) (Obsoleted by RFC3179) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2593) 2594 Definitions of Managed Objects for WWW Services. H. Hazewinkel, C. Kalbfleisch, J. Schoenwaelder. May 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2594) 2595 Using TLS with IMAP, POP3 and ACAP. C. Newman. June 1999. (Format: TXT, HTML) (Updated by RFC4616, RFC7817, RFC8314) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2595) 2596 Use of Language Codes in LDAP. M. Wahl, T. Howes. May 1999. (Format: TXT, HTML) (Obsoleted by RFC3866) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2596) 2597 Assured Forwarding PHB Group. J. Heinanen, F. Baker, W. Weiss, J. Wroclawski. June 1999. (Format: TXT, HTML) (Updated by RFC3260) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2597) 2598 An Expedited Forwarding PHB. V. Jacobson, K. Nichols, K. Poduri. June 1999. (Format: TXT, HTML) (Obsoleted by RFC3246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2598) 2599 Request for Comments Summary RFC Numbers 2500-2599. A. DeLaCruz. March 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2599) 2600 Internet Official Protocol Standards. J. Reynolds, R. Braden. March 2000. (Format: TXT, HTML) (Obsoletes RFC2500) (Obsoleted by RFC2700) (Status: HISTORIC) (DOI: 10.17487/RFC2600) 2601 ILMI-Based Server Discovery for ATMARP. M. Davison. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2601) 2602 ILMI-Based Server Discovery for MARS. M. Davison. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2602) 2603 ILMI-Based Server Discovery for NHRP. M. Davison. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2603) 2604 Wireless Device Configuration (OTASP/OTAPA) via ACAP. R. Gellens. June 1999. (Format: TXT, HTML) (Obsoleted by RFC2636) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2604) 2605 Directory Server Monitoring MIB. G. Mansfield, S. Kille. June 1999. (Format: TXT, HTML) (Obsoletes RFC1567) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2605) 2606 Reserved Top Level DNS Names. D. Eastlake 3rd, A. Panitz. June 1999. (Format: TXT, HTML) (Updated by RFC6761) (Also BCP0032) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2606) 2607 Proxy Chaining and Policy Implementation in Roaming. B. Aboba, J. Vollbrecht. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2607) 2608 Service Location Protocol, Version 2. E. Guttman, C. Perkins, J. Veizades, M. Day. June 1999. (Format: TXT, HTML) (Updates RFC2165) (Updated by RFC3224) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2608) 2609 Service Templates and Service: Schemes. E. Guttman, C. Perkins, J. Kempf. June 1999. (Format: TXT, HTML) (Updates RFC2165) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2609) 2610 DHCP Options for Service Location Protocol. C. Perkins, E. Guttman. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2610) 2611 URN Namespace Definition Mechanisms. L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. June 1999. (Format: TXT, HTML) (Obsoleted by RFC3406) (Also BCP0033) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2611) 2612 The CAST-256 Encryption Algorithm. C. Adams, J. Gilchrist. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2612) 2613 Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0. R. Waterman, B. Lahaye, D. Romascanu, S. Waldbusser. June 1999. (Format: TXT, HTML) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2613) 2614 An API for Service Location. J. Kempf, E. Guttman. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2614) 2615 PPP over SONET/SDH. A. Malis, W. Simpson. June 1999. (Format: TXT, HTML) (Obsoletes RFC1619) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2615) 2616 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC2068) (Obsoleted by RFC7230, RFC7231, RFC7232, RFC7233, RFC7234, RFC7235) (Updated by RFC2817, RFC5785, RFC6266, RFC6585) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2616) 2617 HTTP Authentication: Basic and Digest Access Authentication. J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart. June 1999. (Format: TXT, HTML) (Obsoletes RFC2069) (Obsoleted by RFC7235, RFC7615, RFC7616, RFC7617) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2617) 2618 RADIUS Authentication Client MIB. B. Aboba, G. Zorn. June 1999. (Format: TXT, HTML) (Obsoleted by RFC4668) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2618) 2619 RADIUS Authentication Server MIB. G. Zorn, B. Aboba. June 1999. (Format: TXT, HTML) (Obsoleted by RFC4669) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2619) 2620 RADIUS Accounting Client MIB. B. Aboba, G. Zorn. June 1999. (Format: TXT, HTML) (Obsoleted by RFC4670) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2620) 2621 RADIUS Accounting Server MIB. G. Zorn, B. Aboba. June 1999. (Format: TXT, HTML) (Obsoleted by RFC4671) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2621) 2622 Routing Policy Specification Language (RPSL). C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra. June 1999. (Format: TXT, HTML) (Obsoletes RFC2280) (Updated by RFC4012, RFC7909) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2622) 2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5. M. Eisler. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2623) 2624 NFS Version 4 Design Considerations. S. Shepler. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2624) 2625 IP and ARP over Fibre Channel. M. Rajagopal, R. Bhagwat, W. Rickard. June 1999. (Format: TXT, HTML) (Obsoleted by RFC4338) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2625) 2626 The Internet and the Millennium Problem (Year 2000). P. Nesser II. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2626) 2627 Key Management for Multicast: Issues and Architectures. D. Wallner, E. Harder, R. Agee. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2627) 2628 Simple Cryptographic Program Interface (Crypto API). V. Smyslov. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2628) 2629 Writing I-Ds and RFCs using XML. M. Rose. June 1999. (Format: TXT, HTML) (Obsoleted by RFC7749) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2629) 2630 Cryptographic Message Syntax. R. Housley. June 1999. (Format: TXT, HTML) (Obsoleted by RFC3369, RFC3370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2630) 2631 Diffie-Hellman Key Agreement Method. E. Rescorla. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2631) 2632 S/MIME Version 3 Certificate Handling. B. Ramsdell, Ed.. June 1999. (Format: TXT, HTML) (Obsoleted by RFC3850) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2632) 2633 S/MIME Version 3 Message Specification. B. Ramsdell, Ed.. June 1999. (Format: TXT, HTML) (Obsoleted by RFC3851) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2633) 2634 Enhanced Security Services for S/MIME. P. Hoffman, Ed.. June 1999. (Format: TXT, HTML) (Updated by RFC5035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2634) 2635 DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*). S. Hambridge, A. Lunde. June 1999. (Format: TXT, HTML) (Also FYI0035) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2635) 2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP. R. Gellens. July 1999. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC2604) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2636) 2637 Point-to-Point Tunneling Protocol (PPTP). K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn. July 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2637) 2638 A Two-bit Differentiated Services Architecture for the Internet. K. Nichols, V. Jacobson, L. Zhang. July 1999. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2638) 2639 Internet Printing Protocol/1.0: Implementer's Guide. T. Hastings, C. Manros. July 1999. (Format: TXT, HTML) (Obsoleted by RFC3196) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2639) 2640 Internationalization of the File Transfer Protocol. B. Curtin. July 1999. (Format: TXT, HTML) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2640) 2641 Cabletron's VlanHello Protocol Specification Version 4. D. Hamilton, D. Ruffen. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2641) 2642 Cabletron's VLS Protocol Specification. L. Kane. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2642) 2643 Cabletron's SecureFast VLAN Operational Model. D. Ruffen, T. Len, J. Yanacek. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2643) 2644 Changing the Default for Directed Broadcasts in Routers. D. Senie. August 1999. (Format: TXT, HTML) (Updates RFC1812) (Also BCP0034) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2644) 2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses. R. Gellens. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2645) 2646 The Text/Plain Format Parameter. R. Gellens, Ed.. August 1999. (Format: TXT, HTML) (Obsoleted by RFC3676) (Updates RFC2046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2646) 2647 Benchmarking Terminology for Firewall Performance. D. Newman. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2647) 2648 A URN Namespace for IETF Documents. R. Moats. August 1999. (Format: TXT, HTML) (Updated by RFC6924, RFC9141) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2648) 2649 An LDAP Control and Schema for Holding Operation Signatures. B. Greenblatt, P. Richard. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2649) 2650 Using RPSL in Practice. D. Meyer, J. Schmitz, C. Orange, M. Prior, C. Alaettinoglu. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2650) 2651 The Architecture of the Common Indexing Protocol (CIP). J. Allen, M. Mealling. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2651) 2652 MIME Object Definitions for the Common Indexing Protocol (CIP). J. Allen, M. Mealling. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2652) 2653 CIP Transport Protocols. J. Allen, P. Leach, R. Hedberg. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2653) 2654 A Tagged Index Object for use in the Common Indexing Protocol. R. Hedberg, B. Greenblatt, R. Moats, M. Wahl. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2654) 2655 CIP Index Object Format for SOIF Objects. T. Hardie, M. Bowman, D. Hardy, M. Schwartz, D. Wessels. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2655) 2656 Registration Procedures for SOIF Template Types. T. Hardie. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2656) 2657 LDAPv2 Client vs. the Index Mesh. R. Hedberg. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2657) 2658 RTP Payload Format for PureVoice(tm) Audio. K. McKay. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2658) 2659 Security Extensions For HTML. E. Rescorla, A. Schiffman. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2659) 2660 The Secure HyperText Transfer Protocol. E. Rescorla, A. Schiffman. August 1999. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2660) 2661 Layer Two Tunneling Protocol "L2TP". W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2661) 2662 Definitions of Managed Objects for the ADSL Lines. G. Bathrick, F. Ly. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2662) 2663 IP Network Address Translator (NAT) Terminology and Considerations. P. Srisuresh, M. Holdrege. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2663) 2664 FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions. R. Plzak, A. Wells, E. Krol. August 1999. (Format: TXT, HTML) (Obsoletes RFC1594) (Also FYI0004) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2664) 2665 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Flick, J. Johnson. August 1999. (Format: TXT, HTML) (Obsoletes RFC2358) (Obsoleted by RFC3635) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2665) 2666 Definitions of Object Identifiers for Identifying Ethernet Chip Sets. J. Flick. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2666) 2667 IP Tunnel MIB. D. Thaler. August 1999. (Format: TXT, HTML) (Obsoleted by RFC4087) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2667) 2668 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs). A. Smith, J. Flick, K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. August 1999. (Format: TXT, HTML) (Obsoletes RFC2239) (Obsoleted by RFC3636) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2668) 2669 DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems. M. St. Johns, Ed.. August 1999. (Format: TXT, HTML) (Obsoleted by RFC4639) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2669) 2670 Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces. M. St. Johns, Ed.. August 1999. (Format: TXT, HTML) (Obsoleted by RFC4546) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2670) 2671 Extension Mechanisms for DNS (EDNS0). P. Vixie. August 1999. (Format: TXT, HTML) (Obsoleted by RFC6891) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2671) 2672 Non-Terminal DNS Name Redirection. M. Crawford. August 1999. (Format: TXT, HTML) (Obsoleted by RFC6672) (Updated by RFC4592, RFC6604) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2672) 2673 Binary Labels in the Domain Name System. M. Crawford. August 1999. (Format: TXT, HTML) (Obsoleted by RFC6891) (Updates RFC1035) (Updated by RFC3363, RFC3364) (Status: HISTORIC) (DOI: 10.17487/RFC2673) 2674 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions. E. Bell, A. Smith, P. Langille, A. Rijhsinghani, K. McCloghrie. August 1999. (Format: TXT, HTML) (Obsoleted by RFC4363) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2674) 2675 IPv6 Jumbograms. D. Borman, S. Deering, R. Hinden. August 1999. (Format: TXT, HTML) (Obsoletes RFC2147) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2675) 2676 QoS Routing Mechanisms and OSPF Extensions. G. Apostolopoulos, S. Kama, D. Williams, R. Guerin, A. Orda, T. Przygienda. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2676) 2677 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP). M. Greene, J. Cucchiara, J. Luciani. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2677) 2678 IPPM Metrics for Measuring Connectivity. J. Mahdavi, V. Paxson. September 1999. (Format: TXT, HTML) (Obsoletes RFC2498) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2678) 2679 A One-way Delay Metric for IPPM. G. Almes, S. Kalidindi, M. Zekauskas. September 1999. (Format: TXT, HTML) (Obsoleted by RFC7679) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2679) 2680 A One-way Packet Loss Metric for IPPM. G. Almes, S. Kalidindi, M. Zekauskas. September 1999. (Format: TXT, HTML) (Obsoleted by RFC7680) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2680) 2681 A Round-trip Delay Metric for IPPM. G. Almes, S. Kalidindi, M. Zekauskas. September 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2681) 2682 Performance Issues in VC-Merge Capable ATM LSRs. I. Widjaja, A. Elwalid. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2682) 2683 IMAP4 Implementation Recommendations. B. Leiba. September 1999. (Format: TXT, HTML) (Updated by RFC7162) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2683) 2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5. D. Grossman, J. Heinanen. September 1999. (Format: TXT, HTML) (Obsoletes RFC1483) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2684) 2685 Virtual Private Networks Identifier. B. Fox, B. Gleeson. September 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2685) 2686 The Multi-Class Extension to Multi-Link PPP. C. Bormann. September 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2686) 2687 PPP in a Real-time Oriented HDLC-like Framing. C. Bormann. September 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2687) 2688 Integrated Services Mappings for Low Speed Networks. S. Jackowski, D. Putzolu, E. Crawley, B. Davie. September 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2688) 2689 Providing Integrated Services over Low-bitrate Links. C. Bormann. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2689) 2690 A Proposal for an MOU-Based ICANN Protocol Support Organization. S. Bradner. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2690) 2691 A Memorandum of Understanding for an ICANN Protocol Support Organization. S. Bradner. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2691) 2692 SPKI Requirements. C. Ellison. September 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2692) 2693 SPKI Certificate Theory. C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen. September 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2693) 2694 DNS extensions to Network Address Translators (DNS_ALG). P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2694) 2695 Authentication Mechanisms for ONC RPC. A. Chiu. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2695) 2696 LDAP Control Extension for Simple Paged Results Manipulation. C. Weider, A. Herron, A. Anantha, T. Howes. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2696) 2697 A Single Rate Three Color Marker. J. Heinanen, R. Guerin. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2697) 2698 A Two Rate Three Color Marker. J. Heinanen, R. Guerin. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2698) 2699 Request for Comments Summary RFC Numbers 2600-2699. S. Ginoza. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2699) 2700 Internet Official Protocol Standards. J. Reynolds, R. Braden. August 2000. (Format: TXT, HTML) (Obsoletes RFC2600) (Obsoleted by RFC2800) (Status: HISTORIC) (DOI: 10.17487/RFC2700) 2701 Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol. G. Malkin. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2701) 2702 Requirements for Traffic Engineering Over MPLS. D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2702) 2703 Protocol-independent Content Negotiation Framework. G. Klyne. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2703) 2704 The KeyNote Trust-Management System Version 2. M. Blaze, J. Feigenbaum, J. Ioannidis, A. Keromytis. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2704) 2705 Media Gateway Control Protocol (MGCP) Version 1.0. M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett. October 1999. (Format: TXT, HTML) (Obsoleted by RFC3435) (Updated by RFC3660) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2705) 2706 ECML v1: Field Names for E-Commerce. D. Eastlake 3rd, T. Goldstein. October 1999. (Format: TXT, HTML) (Obsoleted by RFC3106) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2706) 2707 Job Monitoring MIB - V1.0. R. Bergman, T. Hastings, S. Isaacson, H. Lewis. November 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2707) 2708 Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB. R. Bergman. November 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2708) 2709 Security Model with Tunnel-mode IPsec for NAT Domains. P. Srisuresh. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2709) 2710 Multicast Listener Discovery (MLD) for IPv6. S. Deering, W. Fenner, B. Haberman. October 1999. (Format: TXT, HTML) (Updated by RFC3590, RFC3810) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2710) 2711 IPv6 Router Alert Option. C. Partridge, A. Jackson. October 1999. (Format: TXT, HTML) (Updated by RFC6398) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2711) 2712 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS). A. Medvinsky, M. Hur. October 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2712) 2713 Schema for Representing Java(tm) Objects in an LDAP Directory. V. Ryan, S. Seligman, R. Lee. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2713) 2714 Schema for Representing CORBA Object References in an LDAP Directory. V. Ryan, R. Lee, S. Seligman. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2714) 2715 Interoperability Rules for Multicast Routing Protocols. D. Thaler. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2715) 2716 PPP EAP TLS Authentication Protocol. B. Aboba, D. Simon. October 1999. (Format: TXT, HTML) (Obsoleted by RFC5216) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2716) 2717 Registration Procedures for URL Scheme Names. R. Petke, I. King. November 1999. (Format: TXT, HTML) (Obsoleted by RFC4395) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2717) 2718 Guidelines for new URL Schemes. L. Masinter, H. Alvestrand, D. Zigmond, R. Petke. November 1999. (Format: TXT, HTML) (Obsoleted by RFC4395) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2718) 2719 Framework Architecture for Signaling Transport. L. Ong, I. Rytina, M. Garcia, H. Schwarzbauer, L. Coene, H. Lin, I. Juhasz, M. Holdrege, C. Sharp. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2719) 2720 Traffic Flow Measurement: Meter MIB. N. Brownlee. October 1999. (Format: TXT, HTML) (Obsoletes RFC2064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2720) 2721 RTFM: Applicability Statement. N. Brownlee. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2721) 2722 Traffic Flow Measurement: Architecture. N. Brownlee, C. Mills, G. Ruth. October 1999. (Format: TXT, HTML) (Obsoletes RFC2063) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2722) 2723 SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups. N. Brownlee. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2723) 2724 RTFM: New Attributes for Traffic Flow Measurement. S. Handelman, S. Stibler, N. Brownlee, G. Ruth. October 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2724) 2725 Routing Policy System Security. C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy. December 1999. (Format: TXT, HTML) (Updated by RFC4012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2725) 2726 PGP Authentication for RIPE Database Updates. J. Zsako. December 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2726) 2727 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. J. Galvin. February 2000. (Format: TXT, HTML) (Obsoletes RFC2282) (Obsoleted by RFC3777) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2727) 2728 The Transmission of IP Over the Vertical Blanking Interval of a Television Signal. R. Panabaker, S. Wegerif, D. Zigmond. November 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2728) 2729 Taxonomy of Communication Requirements for Large-scale Multicast Applications. P. Bagnall, R. Briscoe, A. Poppitt. December 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2729) 2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP). S. Hanna, B. Patel, M. Shah. December 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2730) 2731 Encoding Dublin Core Metadata in HTML. J. Kunze. December 1999. (Format: TXT, HTML) (Obsoleted by RFC5791) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2731) 2732 Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. December 1999. (Format: TXT, HTML) (Obsoleted by RFC3986) (Updates RFC2396) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2732) 2733 An RTP Payload Format for Generic Forward Error Correction. J. Rosenberg, H. Schulzrinne. December 1999. (Format: TXT, HTML) (Obsoleted by RFC5109) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2733) 2734 IPv4 over IEEE 1394. P. Johansson. December 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2734) 2735 NHRP Support for Virtual Private Networks. B. Fox, B. Petri. December 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2735) 2736 Guidelines for Writers of RTP Payload Format Specifications. M. Handley, C. Perkins. December 1999. (Format: TXT, HTML) (Updated by RFC8088) (Also BCP0036) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2736) 2737 Entity MIB (Version 2). K. McCloghrie, A. Bierman. December 1999. (Format: TXT, HTML) (Obsoletes RFC2037) (Obsoleted by RFC4133) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2737) 2738 Corrections to "A Syntax for Describing Media Feature Sets". G. Klyne. December 1999. (Format: TXT, HTML) (Updates RFC2533) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2738) 2739 Calendar Attributes for vCard and LDAP. T. Small, D. Hennessy, F. Dawson. January 2000. (Format: TXT, HTML) (Updated by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2739) 2740 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy. December 1999. (Format: TXT, HTML) (Obsoleted by RFC5340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2740) 2741 Agent Extensibility (AgentX) Protocol Version 1. M. Daniele, B. Wijnen, M. Ellison, D. Francisco. January 2000. (Format: TXT, HTML) (Obsoletes RFC2257) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2741) 2742 Definitions of Managed Objects for Extensible SNMP Agents. L. Heintz, S. Gudur, M. Ellison. January 2000. (Format: TXT, HTML) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2742) 2743 Generic Security Service Application Program Interface Version 2, Update 1. J. Linn. January 2000. (Format: TXT, HTML) (Obsoletes RFC2078) (Updated by RFC5554, RFC5896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2743) 2744 Generic Security Service API Version 2 : C-bindings. J. Wray. January 2000. (Format: TXT, HTML) (Obsoletes RFC1509) (Updated by RFC5896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2744) 2745 RSVP Diagnostic Messages. A. Terzis, B. Braden, S. Vincent, L. Zhang. January 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2745) 2746 RSVP Operation Over IP Tunnels. A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang. January 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2746) 2747 RSVP Cryptographic Authentication. F. Baker, B. Lindell, M. Talwar. January 2000. (Format: TXT, HTML) (Updated by RFC3097) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2747) 2748 The COPS (Common Open Policy Service) Protocol. D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry. January 2000. (Format: TXT, HTML) (Updated by RFC4261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2748) 2749 COPS usage for RSVP. S. Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A. Sastry. January 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2749) 2750 RSVP Extensions for Policy Control. S. Herzog. January 2000. (Format: TXT, HTML) (Updates RFC2205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2750) 2751 Signaled Preemption Priority Policy Element. S. Herzog. January 2000. (Format: TXT, HTML) (Obsoleted by RFC3181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2751) 2752 Identity Representation for RSVP. S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog. January 2000. (Format: TXT, HTML) (Obsoleted by RFC3182) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2752) 2753 A Framework for Policy-based Admission Control. R. Yavatkar, D. Pendarakis, R. Guerin. January 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2753) 2754 RPS IANA Issues. C. Alaettinoglu, C. Villamizar, R. Govindan. January 2000. (Format: TXT, HTML) (Obsoleted by RFC6254) (Status: HISTORIC) (DOI: 10.17487/RFC2754) 2755 Security Negotiation for WebNFS. A. Chiu, M. Eisler, B. Callaghan. January 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2755) 2756 Hyper Text Caching Protocol (HTCP/0.0). P. Vixie, D. Wessels. January 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2756) 2757 Long Thin Networks. G. Montenegro, S. Dawkins, M. Kojo, V. Magret, N. Vaidya. January 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2757) 2758 Definitions of Managed Objects for Service Level Agreements Performance Monitoring. K. White. February 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2758) 2759 Microsoft PPP CHAP Extensions, Version 2. G. Zorn. January 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2759) 2760 Ongoing TCP Research Related to Satellites. M. Allman, Ed., S. Dawkins, D. Glover, J. Griner, D. Tran, T. Henderson, J. Heidemann, J. Touch, H. Kruse, S. Ostermann, K. Scott, J. Semke. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2760) 2761 Terminology for ATM Benchmarking. J. Dunn, C. Martin. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2761) 2762 Sampling of the Group Membership in RTP. J. Rosenberg, H. Schulzrinne. February 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2762) 2763 Dynamic Hostname Exchange Mechanism for IS-IS. N. Shen, H. Smit. February 2000. (Format: TXT, HTML) (Obsoleted by RFC5301) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2763) 2764 A Framework for IP Based Virtual Private Networks. B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2764) 2765 Stateless IP/ICMP Translation Algorithm (SIIT). E. Nordmark. February 2000. (Format: TXT, HTML) (Obsoleted by RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2765) 2766 Network Address Translation - Protocol Translation (NAT-PT). G. Tsirtsis, P. Srisuresh. February 2000. (Format: TXT, HTML) (Obsoleted by RFC4966) (Updated by RFC3152) (Status: HISTORIC) (DOI: 10.17487/RFC2766) 2767 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS). K. Tsuchiya, H. Higuchi, Y. Atarashi. February 2000. (Format: TXT, HTML) (Obsoleted by RFC6535) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2767) 2768 Network Policy and Services: A Report of a Workshop on Middleware. B. Aiken, J. Strassner, B. Carpenter, I. Foster, C. Lynch, J. Mambretti, R. Moore, B. Teitelbaum. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2768) 2769 Routing Policy System Replication. C. Villamizar, C. Alaettinoglu, R. Govindan, D. Meyer. February 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2769) 2770 GLOP Addressing in 233/8. D. Meyer, P. Lothberg. February 2000. (Format: TXT, HTML) (Obsoleted by RFC3180) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2770) 2771 An Abstract API for Multicast Address Allocation. R. Finlayson. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2771) 2772 6Bone Backbone Routing Guidelines. R. Rockell, R. Fink. February 2000. (Format: TXT, HTML) (Obsoletes RFC2546) (Updated by RFC3152) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2772) 2773 Encryption using KEA and SKIPJACK. R. Housley, P. Yee, W. Nace. February 2000. (Format: TXT, HTML) (Updates RFC0959) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2773) 2774 An HTTP Extension Framework. H. Nielsen, P. Leach, S. Lawrence. February 2000. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2774) 2775 Internet Transparency. B. Carpenter. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2775) 2776 Multicast-Scope Zone Announcement Protocol (MZAP). M. Handley, D. Thaler, R. Kermode. February 2000. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2776) 2777 Publicly Verifiable Nomcom Random Selection. D. Eastlake 3rd. February 2000. (Format: TXT, HTML) (Obsoleted by RFC3797) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2777) 2778 A Model for Presence and Instant Messaging. M. Day, J. Rosenberg, H. Sugano. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2778) 2779 Instant Messaging / Presence Protocol Requirements. M. Day, S. Aggarwal, G. Mohr, J. Vincent. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2779) 2780 IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers. S. Bradner, V. Paxson. March 2000. (Format: TXT, HTML) (Updated by RFC4443, RFC5237, RFC5771, RFC6335, RFC7045) (Also BCP0037) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2780) 2781 UTF-16, an encoding of ISO 10646. P. Hoffman, F. Yergeau. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2781) 2782 A DNS RR for specifying the location of services (DNS SRV). A. Gulbrandsen, P. Vixie, L. Esibov. February 2000. (Format: TXT, HTML) (Obsoletes RFC2052) (Updated by RFC6335, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2782) 2783 Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0. J. Mogul, D. Mills, J. Brittenson, J. Stone, U. Windl. March 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2783) 2784 Generic Routing Encapsulation (GRE). D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina. March 2000. (Format: TXT, HTML) (Updated by RFC2890) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2784) 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME. R. Zuccherato. March 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2785) 2786 Diffie-Helman USM Key Management Information Base and Textual Convention. M. St. Johns. March 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2786) 2787 Definitions of Managed Objects for the Virtual Router Redundancy Protocol. B. Jewell, D. Chuang. March 2000. (Format: TXT, HTML) (Obsoleted by RFC6527) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2787) 2788 Network Services Monitoring MIB. N. Freed, S. Kille. March 2000. (Format: TXT, HTML) (Obsoletes RFC2248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2788) 2789 Mail Monitoring MIB. N. Freed, S. Kille. March 2000. (Format: TXT, HTML) (Obsoletes RFC2249, RFC1566) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2789) 2790 Host Resources MIB. S. Waldbusser, P. Grillo. March 2000. (Format: TXT, HTML) (Obsoletes RFC1514) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2790) 2791 Scalable Routing Design Principles. J. Yu. July 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2791) 2792 DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System. M. Blaze, J. Ioannidis, A. Keromytis. March 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2792) 2793 RTP Payload for Text Conversation. G. Hellstrom. May 2000. (Format: TXT, HTML) (Obsoleted by RFC4103) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2793) 2794 Mobile IP Network Access Identifier Extension for IPv4. P. Calhoun, C. Perkins. March 2000. (Format: TXT, HTML) (Updates RFC2290) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2794) 2795 The Infinite Monkey Protocol Suite (IMPS). S. Christey. 1 April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2795) 2796 BGP Route Reflection - An Alternative to Full Mesh IBGP. T. Bates, R. Chandra, E. Chen. April 2000. (Format: TXT, HTML) (Obsoleted by RFC4456) (Updates RFC1966) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2796) 2797 Certificate Management Messages over CMS. M. Myers, X. Liu, J. Schaad, J. Weinstein. April 2000. (Format: TXT, HTML) (Obsoleted by RFC5272) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2797) 2798 Definition of the inetOrgPerson LDAP Object Class. M. Smith. April 2000. (Format: TXT, HTML) (Updated by RFC3698, RFC4519, RFC4524) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2798) 2799 Request for Comments Summary RFC Numbers 2700-2799. S. Ginoza. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2799) 2800 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza. May 2001. (Format: TXT, HTML) (Obsoletes RFC2700) (Obsoleted by RFC2900) (Status: HISTORIC) (DOI: 10.17487/RFC2800) 2801 Internet Open Trading Protocol - IOTP Version 1.0. D. Burdett. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2801) 2802 Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP). K. Davidson, Y. Kawatsura. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2802) 2803 Digest Values for DOM (DOMHASH). H. Maruyama, K. Tamura, N. Uramoto. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2803) 2804 IETF Policy on Wiretapping. IAB, IESG. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2804) 2805 Media Gateway Control Protocol Architecture and Requirements. N. Greene, M. Ramalho, B. Rosen. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2805) 2806 URLs for Telephone Calls. A. Vaha-Sipila. April 2000. (Format: TXT, HTML) (Obsoleted by RFC3966) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2806) 2807 XML Signature Requirements. J. Reagle. July 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2807) 2808 The SecurID(r) SASL Mechanism. M. Nystrom. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2808) 2809 Implementation of L2TP Compulsory Tunneling via RADIUS. B. Aboba, G. Zorn. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2809) 2810 Internet Relay Chat: Architecture. C. Kalt. April 2000. (Format: TXT, HTML) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2810) 2811 Internet Relay Chat: Channel Management. C. Kalt. April 2000. (Format: TXT, HTML) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2811) 2812 Internet Relay Chat: Client Protocol. C. Kalt. April 2000. (Format: TXT, HTML) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2812) 2813 Internet Relay Chat: Server Protocol. C. Kalt. April 2000. (Format: TXT, HTML) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2813) 2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks. R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer. May 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2814) 2815 Integrated Service Mappings on IEEE 802 Networks. M. Seaman, A. Smith, E. Crawley, J. Wroclawski. May 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2815) 2816 A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies. A. Ghanwani, J. Pace, V. Srinivasan, A. Smith, M. Seaman. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2816) 2817 Upgrading to TLS Within HTTP/1.1. R. Khare, S. Lawrence. May 2000. (Format: TXT, HTML) (Updates RFC2616) (Updated by RFC7230, RFC7231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2817) 2818 HTTP Over TLS. E. Rescorla. May 2000. (Format: TXT, HTML) (Obsoleted by RFC9110) (Updated by RFC5785, RFC7230) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2818) 2819 Remote Network Monitoring Management Information Base. S. Waldbusser. May 2000. (Format: TXT, HTML) (Obsoletes RFC1757) (Also STD0059) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2819) 2820 Access Control Requirements for LDAP. E. Stokes, D. Byrne, B. Blakley, P. Behera. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2820) 2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001. (Format: TXT, HTML) (Obsoletes RFC0821, RFC0974, RFC1869) (Obsoleted by RFC5321) (Updated by RFC5336) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2821) 2822 Internet Message Format. P. Resnick, Ed.. April 2001. (Format: TXT, HTML) (Obsoletes RFC0822) (Obsoleted by RFC5322) (Updated by RFC5335, RFC5336) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2822) 2823 PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing. J. Carlson, P. Langner, E. Hernandez-Valencia, J. Manchester. May 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2823) 2824 Call Processing Language Framework and Requirements. J. Lennox, H. Schulzrinne. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2824) 2825 A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols. IAB, L. Daigle, Ed.. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2825) 2826 IAB Technical Comment on the Unique DNS Root. Internet Architecture Board. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2826) 2827 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. P. Ferguson, D. Senie. May 2000. (Format: TXT, HTML) (Obsoletes RFC2267) (Updated by RFC3704) (Also BCP0038) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2827) 2828 Internet Security Glossary. R. Shirey. May 2000. (Format: TXT, HTML) (Obsoleted by RFC4949) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2828) 2829 Authentication Methods for LDAP. M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. May 2000. (Format: TXT, HTML) (Obsoleted by RFC4513, RFC4510) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2829) 2830 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security. J. Hodges, R. Morgan, M. Wahl. May 2000. (Format: TXT, HTML) (Obsoleted by RFC4511, RFC4513, RFC4510) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2830) 2831 Using Digest Authentication as a SASL Mechanism. P. Leach, C. Newman. May 2000. (Format: TXT, HTML) (Obsoleted by RFC6331) (Status: HISTORIC) (DOI: 10.17487/RFC2831) 2832 NSI Registry Registrar Protocol (RRP) Version 1.1.0. S. Hollenbeck, M. Srivastava. May 2000. (Format: TXT, HTML) (Updated by RFC3632) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2832) 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. H. Schulzrinne, S. Petrack. May 2000. (Format: TXT, HTML) (Obsoleted by RFC4733, RFC4734) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2833) 2834 ARP and IP Broadcast over HIPPI-800. J.-M. Pittet. May 2000. (Format: TXT, HTML) (Obsoletes RFC1374) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2834) 2835 IP and ARP over HIPPI-6400 (GSN). J.-M. Pittet. May 2000. (Format: TXT, HTML) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2835) 2836 Per Hop Behavior Identification Codes. S. Brim, B. Carpenter, F. Le Faucheur. May 2000. (Format: TXT, HTML) (Obsoleted by RFC3140) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2836) 2837 Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard. K. Teow. May 2000. (Format: TXT, HTML) (Obsoleted by RFC4044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2837) 2838 Uniform Resource Identifiers for Television Broadcasts. D. Zigmond, M. Vickers. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2838) 2839 Internet Kermit Service. F. da Cruz, J. Altman. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2839) 2840 TELNET KERMIT OPTION. J. Altman, F. da Cruz. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2840) 2841 IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC). P. Metzger, W. Simpson. November 2000. (Format: TXT, HTML) (Obsoletes RFC1852) (Status: HISTORIC) (DOI: 10.17487/RFC2841) 2842 Capabilities Advertisement with BGP-4. R. Chandra, J. Scudder. May 2000. (Format: TXT, HTML) (Obsoleted by RFC3392) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2842) 2843 Proxy-PAR. P. Droz, T. Przygienda. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2843) 2844 OSPF over ATM and Proxy-PAR. T. Przygienda, P. Droz, R. Haas. May 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2844) 2845 Secret Key Transaction Authentication for DNS (TSIG). P. Vixie, O. Gudmundsson, D. Eastlake 3rd, B. Wellington. May 2000. (Format: TXT, HTML) (Obsoleted by RFC8945) (Updates RFC1035) (Updated by RFC3645, RFC4635, RFC6895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2845) 2846 GSTN Address Element Extensions in E-mail Services. C. Allocchio. June 2000. (Format: TXT, HTML) (Updated by RFC3191, RFC3192) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2846) 2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM. M. Eisler. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2847) 2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services. S. Petrack, L. Conroy. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2848) 2849 The LDAP Data Interchange Format (LDIF) - Technical Specification. G. Good. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2849) 2850 Charter of the Internet Architecture Board (IAB). Internet Architecture Board, B. Carpenter, Ed.. May 2000. (Format: TXT, HTML) (Obsoletes RFC1601) (Updated by RFC9283) (Also BCP0039) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2850) 2851 Textual Conventions for Internet Network Addresses. M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. June 2000. (Format: TXT, HTML) (Obsoleted by RFC3291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2851) 2852 Deliver By SMTP Service Extension. D. Newman. June 2000. (Format: TXT, HTML) (Updates RFC1894) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2852) 2853 Generic Security Service API Version 2 : Java Bindings. J. Kabat, M. Upadhyay. June 2000. (Format: TXT, HTML) (Obsoleted by RFC5653) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2853) 2854 The 'text/html' Media Type. D. Connolly, L. Masinter. June 2000. (Format: TXT, HTML) (Obsoletes RFC2070, RFC1980, RFC1942, RFC1867, RFC1866) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2854) 2855 DHCP for IEEE 1394. K. Fujisawa. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2855) 2856 Textual Conventions for Additional High Capacity Data Types. A. Bierman, K. McCloghrie, R. Presuhn. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2856) 2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH. A. Keromytis, N. Provos. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2857) 2858 Multiprotocol Extensions for BGP-4. T. Bates, Y. Rekhter, R. Chandra, D. Katz. June 2000. (Format: TXT, HTML) (Obsoletes RFC2283) (Obsoleted by RFC4760) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2858) 2859 A Time Sliding Window Three Colour Marker (TSWTCM). W. Fang, N. Seddigh, B. Nandy. June 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2859) 2860 Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority. B. Carpenter, F. Baker, M. Roberts. June 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2860) 2861 TCP Congestion Window Validation. M. Handley, J. Padhye, S. Floyd. June 2000. (Format: TXT, HTML) (Obsoleted by RFC7661) (Status: HISTORIC) (DOI: 10.17487/RFC2861) 2862 RTP Payload Format for Real-Time Pointers. M. Civanlar, G. Cash. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2862) 2863 The Interfaces Group MIB. K. McCloghrie, F. Kastenholz. June 2000. (Format: TXT, HTML) (Obsoletes RFC2233) (Updated by RFC8892) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2863) 2864 The Inverted Stack Table Extension to the Interfaces Group MIB. K. McCloghrie, G. Hanson. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2864) 2865 Remote Authentication Dial In User Service (RADIUS). C. Rigney, S. Willens, A. Rubens, W. Simpson. June 2000. (Format: TXT, HTML) (Obsoletes RFC2138) (Updated by RFC2868, RFC3575, RFC5080, RFC6929, RFC8044) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2865) 2866 RADIUS Accounting. C. Rigney. June 2000. (Format: TXT, HTML) (Obsoletes RFC2139) (Updated by RFC2867, RFC5080, RFC5997) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2866) 2867 RADIUS Accounting Modifications for Tunnel Protocol Support. G. Zorn, B. Aboba, D. Mitton. June 2000. (Format: TXT, HTML) (Updates RFC2866) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2867) 2868 RADIUS Attributes for Tunnel Protocol Support. G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret. June 2000. (Format: TXT, HTML) (Updates RFC2865) (Updated by RFC3575) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2868) 2869 RADIUS Extensions. C. Rigney, W. Willats, P. Calhoun. June 2000. (Format: TXT, HTML) (Updated by RFC3579, RFC5080) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2869) 2870 Root Name Server Operational Requirements. R. Bush, D. Karrenberg, M. Kosters, R. Plzak. June 2000. (Format: TXT, HTML) (Obsoletes RFC2010) (Obsoleted by RFC7720) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2870) 2871 A Framework for Telephony Routing over IP. J. Rosenberg, H. Schulzrinne. June 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2871) 2872 Application and Sub Application Identity Policy Element for Use with RSVP. Y. Bernet, R. Pabbati. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2872) 2873 TCP Processing of the IPv4 Precedence Field. X. Xiao, A. Hannan, V. Paxson, E. Crabbe. June 2000. (Format: TXT, HTML) (Obsoleted by RFC9293) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2873) 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering. M. Crawford, C. Huitema. July 2000. (Format: TXT, HTML) (Updates RFC1886) (Updated by RFC3152, RFC3226, RFC3363, RFC3364) (Status: HISTORIC) (DOI: 10.17487/RFC2874) 2875 Diffie-Hellman Proof-of-Possession Algorithms. H. Prafullchandra, J. Schaad. July 2000. (Format: TXT, HTML) (Obsoleted by RFC6955) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2875) 2876 Use of the KEA and SKIPJACK Algorithms in CMS. J. Pawling. July 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2876) 2877 5250 Telnet Enhancements. T. Murphy Jr., P. Rieth, J. Stevens. July 2000. (Format: TXT, HTML) (Obsoleted by RFC4777) (Updates RFC1205) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2877) 2878 PPP Bridging Control Protocol (BCP). M. Higashiyama, F. Baker. July 2000. (Format: TXT, HTML) (Obsoletes RFC1638) (Obsoleted by RFC3518) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2878) 2879 Content Feature Schema for Internet Fax (V2). G. Klyne, L. McIntyre. August 2000. (Format: TXT, HTML) (Obsoletes RFC2531) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2879) 2880 Internet Fax T.30 Feature Mapping. L. McIntyre, G. Klyne. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2880) 2881 Network Access Server Requirements Next Generation (NASREQNG) NAS Model. D. Mitton, M. Beadles. July 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2881) 2882 Network Access Servers Requirements: Extended RADIUS Practices. D. Mitton. July 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2882) 2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP. S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. July 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2883) 2884 Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks. J. Hadi Salim, U. Ahmed. July 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2884) 2885 Megaco Protocol version 0.8. F. Cuervo, N. Greene, C. Huitema, A. Rayhan, B. Rosen, J. Segers. August 2000. (Format: TXT, HTML) (Obsoleted by RFC3015) (Status: HISTORIC) (DOI: 10.17487/RFC2885) 2886 Megaco Errata. T. Taylor. August 2000. (Format: TXT, HTML) (Obsoleted by RFC3015) (Status: HISTORIC) (DOI: 10.17487/RFC2886) 2887 The Reliable Multicast Design Space for Bulk Data Transfer. M. Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano, M. Luby. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2887) 2888 Secure Remote Access with L2TP. P. Srisuresh. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2888) 2889 Benchmarking Methodology for LAN Switching Devices. R. Mandeville, J. Perser. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2889) 2890 Key and Sequence Number Extensions to GRE. G. Dommety. September 2000. (Format: TXT, HTML) (Updates RFC2784) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2890) 2891 LDAP Control Extension for Server Side Sorting of Search Results. T. Howes, M. Wahl, A. Anantha. August 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2891) 2892 The Cisco SRP MAC Layer Protocol. D. Tsiang, G. Suwala. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2892) 2893 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. Nordmark. August 2000. (Format: TXT, HTML) (Obsoletes RFC1933) (Obsoleted by RFC4213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2893) 2894 Router Renumbering for IPv6. M. Crawford. August 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2894) 2895 Remote Network Monitoring MIB Protocol Identifier Reference. A. Bierman, C. Bucci, R. Iddon. August 2000. (Format: TXT, HTML) (Obsoletes RFC2074) (Updated by RFC3395) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2895) 2896 Remote Network Monitoring MIB Protocol Identifier Macros. A. Bierman, C. Bucci, R. Iddon. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2896) 2897 Proposal for an MGCP Advanced Audio Package. D. Cromwell. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2897) 2898 PKCS #5: Password-Based Cryptography Specification Version 2.0. B. Kaliski. September 2000. (Format: TXT, HTML) (Obsoleted by RFC8018) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2898) 2899 Request for Comments Summary RFC Numbers 2800-2899. S. Ginoza. May 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2899) 2900 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza. August 2001. (Format: TXT, HTML) (Obsoletes RFC2800) (Obsoleted by RFC3000) (Status: HISTORIC) (DOI: 10.17487/RFC2900) 2901 Guide to Administrative Procedures of the Internet Infrastructure. Z. Wenzel, J. Klensin, R. Bush, S. Huter. August 2000. (Format: TXT, HTML) (Also FYI0037) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2901) 2902 Overview of the 1998 IAB Routing Workshop. S. Deering, S. Hares, C. Perkins, R. Perlman. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2902) 2903 Generic AAA Architecture. C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence. August 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2903) 2904 AAA Authorization Framework. J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2904) 2905 AAA Authorization Application Examples. J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2905) 2906 AAA Authorization Requirements. S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2906) 2907 MADCAP Multicast Scope Nesting State Option. R. Kermode. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2907) 2908 The Internet Multicast Address Allocation Architecture. D. Thaler, M. Handley, D. Estrin. September 2000. (Format: TXT, HTML) (Obsoleted by RFC6308) (Status: HISTORIC) (DOI: 10.17487/RFC2908) 2909 The Multicast Address-Set Claim (MASC) Protocol. P. Radoslavov, D. Estrin, R. Govindan, M. Handley, S. Kumar, D. Thaler. September 2000. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2909) 2910 Internet Printing Protocol/1.1: Encoding and Transport. R. Herriot, Ed., S. Butler, P. Moore, R. Turner, J. Wenn. September 2000. (Format: TXT, HTML) (Obsoletes RFC2565) (Obsoleted by RFC8010) (Updated by RFC3380, RFC3381, RFC3382, RFC3510, RFC3995, RFC7472) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2910) 2911 Internet Printing Protocol/1.1: Model and Semantics. T. Hastings, Ed., R. Herriot, R. deBry, S. Isaacson, P. Powell. September 2000. (Format: TXT, HTML) (Obsoletes RFC2566) (Obsoleted by RFC8011) (Updated by RFC3380, RFC3382, RFC3996, RFC3995, RFC7472) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2911) 2912 Indicating Media Features for MIME Content. G. Klyne. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2912) 2913 MIME Content Types in Media Feature Expressions. G. Klyne. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2913) 2914 Congestion Control Principles. S. Floyd. September 2000. (Format: TXT, HTML) (Updated by RFC7141) (Also BCP0041) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2914) 2915 The Naming Authority Pointer (NAPTR) DNS Resource Record. M. Mealling, R. Daniel. September 2000. (Format: TXT, HTML) (Obsoleted by RFC3401, RFC3402, RFC3403, RFC3404) (Updates RFC2168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2915) 2916 E.164 number and DNS. P. Faltstrom. September 2000. (Format: TXT, HTML) (Obsoleted by RFC3761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2916) 2917 A Core MPLS IP VPN Architecture. K. Muthukrishnan, A. Malis. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2917) 2918 Route Refresh Capability for BGP-4. E. Chen. September 2000. (Format: TXT, HTML) (Updated by RFC7313) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2918) 2919 List-Id: A Structured Field and Namespace for the Identification of Mailing Lists. R. Chandhok, G. Wenger. March 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2919) 2920 SMTP Service Extension for Command Pipelining. N. Freed. September 2000. (Format: TXT, HTML) (Obsoletes RFC2197) (Also STD0060) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2920) 2921 6BONE pTLA and pNLA Formats (pTLA). B. Fink. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2921) 2922 Physical Topology MIB. A. Bierman, K. Jones. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2922) 2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2923) 2924 Accounting Attributes and Record Formats. N. Brownlee, A. Blount. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2924) 2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations. K. White. September 2000. (Format: TXT, HTML) (Obsoleted by RFC4560) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2925) 2926 Conversion of LDAP Schemas to and from SLP Templates. J. Kempf, R. Moats, P. St. Pierre. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2926) 2927 MIME Directory Profile for LDAP Schema. M. Wahl. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2927) 2928 Initial IPv6 Sub-TLA ID Assignments. R. Hinden, S. Deering, R. Fink, T. Hain. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2928) 2929 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd, E. Brunner-Williams, B. Manning. September 2000. (Format: TXT, HTML) (Obsoleted by RFC5395) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2929) 2930 Secret Key Establishment for DNS (TKEY RR). D. Eastlake 3rd. September 2000. (Format: TXT, HTML) (Updated by RFC6895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2930) 2931 DNS Request and Transaction Signatures ( SIG(0)s ). D. Eastlake 3rd. September 2000. (Format: TXT, HTML) (Updates RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2931) 2932 IPv4 Multicast Routing MIB. K. McCloghrie, D. Farinacci, D. Thaler. October 2000. (Format: TXT, HTML) (Obsoleted by RFC5132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2932) 2933 Internet Group Management Protocol MIB. K. McCloghrie, D. Farinacci, D. Thaler. October 2000. (Format: TXT, HTML) (Obsoleted by RFC5519) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2933) 2934 Protocol Independent Multicast MIB for IPv4. K. McCloghrie, D. Farinacci, D. Thaler, B. Fenner. October 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2934) 2935 Internet Open Trading Protocol (IOTP) HTTP Supplement. D. Eastlake 3rd, C. Smith. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2935) 2936 HTTP MIME Type Handler Detection. D. Eastlake 3rd, C. Smith, D. Soroka. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2936) 2937 The Name Service Search Option for DHCP. C. Smith. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2937) 2938 Identifying Composite Media Features. G. Klyne, L. Masinter. September 2000. (Format: TXT, HTML) (Updates RFC2533) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2938) 2939 Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types. R. Droms. September 2000. (Format: TXT, HTML) (Obsoletes RFC2489) (Also BCP0043) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2939) 2940 Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients. A. Smith, D. Partain, J. Seligson. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2940) 2941 Telnet Authentication Option. T. Ts'o, Ed., J. Altman. September 2000. (Format: TXT, HTML) (Obsoletes RFC1416) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2941) 2942 Telnet Authentication: Kerberos Version 5. T. Ts'o. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2942) 2943 TELNET Authentication Using DSA. R. Housley, T. Horting, P. Yee. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2943) 2944 Telnet Authentication: SRP. T. Wu. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2944) 2945 The SRP Authentication and Key Exchange System. T. Wu. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2945) 2946 Telnet Data Encryption Option. T. Ts'o. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2946) 2947 Telnet Encryption: DES3 64 bit Cipher Feedback. J. Altman. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2947) 2948 Telnet Encryption: DES3 64 bit Output Feedback. J. Altman. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2948) 2949 Telnet Encryption: CAST-128 64 bit Output Feedback. J. Altman. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2949) 2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback. J. Altman. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2950) 2951 TELNET Authentication Using KEA and SKIPJACK. R. Housley, T. Horting, P. Yee. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2951) 2952 Telnet Encryption: DES 64 bit Cipher Feedback. T. Ts'o. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2952) 2953 Telnet Encryption: DES 64 bit Output Feedback. T. Ts'o. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2953) 2954 Definitions of Managed Objects for Frame Relay Service. K. Rehbehn, D. Fowler. October 2000. (Format: TXT, HTML) (Obsoletes RFC1604) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2954) 2955 Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function. K. Rehbehn, O. Nicklass, G. Mouradian. October 2000. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2955) 2956 Overview of 1999 IAB Network Layer Workshop. M. Kaat. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2956) 2957 The application/whoispp-query Content-Type. L. Daigle, P. Faltstrom. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2957) 2958 The application/whoispp-response Content-type. L. Daigle, P. Faltstrom. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2958) 2959 Real-Time Transport Protocol Management Information Base. M. Baugher, B. Strahm, I. Suconick. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2959) 2960 Stream Control Transmission Protocol. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson. October 2000. (Format: TXT, HTML) (Obsoleted by RFC4960) (Updated by RFC3309) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2960) 2961 RSVP Refresh Overhead Reduction Extensions. L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini. April 2001. (Format: TXT, HTML) (Updated by RFC5063) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2961) 2962 An SNMP Application Level Gateway for Payload Address Translation. D. Raz, J. Schoenwaelder, B. Sugla. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2962) 2963 A Rate Adaptive Shaper for Differentiated Services. O. Bonaventure, S. De Cnodder. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2963) 2964 Use of HTTP State Management. K. Moore, N. Freed. October 2000. (Format: TXT, HTML) (Also BCP0044) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2964) 2965 HTTP State Management Mechanism. D. Kristol, L. Montulli. October 2000. (Format: TXT, HTML) (Obsoletes RFC2109) (Obsoleted by RFC6265) (Status: HISTORIC) (DOI: 10.17487/RFC2965) 2966 Domain-wide Prefix Distribution with Two-Level IS-IS. T. Li, T. Przygienda, H. Smit. October 2000. (Format: TXT, HTML) (Obsoleted by RFC5302) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2966) 2967 TISDAG - Technical Infrastructure for Swedish Directory Access Gateways. L. Daigle, R. Hedberg. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2967) 2968 Mesh of Multiple DAG servers - Results from TISDAG. L. Daigle, T. Eklof. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2968) 2969 Wide Area Directory Deployment - Experiences from TISDAG. T. Eklof, L. Daigle. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2969) 2970 Architecture for Integrated Directory Services - Result from TISDAG. L. Daigle, T. Eklof. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2970) 2971 IMAP4 ID extension. T. Showalter. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2971) 2972 Context and Goals for Common Name Resolution. N. Popp, M. Mealling, L. Masinter, K. Sollins. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2972) 2973 IS-IS Mesh Groups. R. Balay, D. Katz, J. Parker. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2973) 2974 Session Announcement Protocol. M. Handley, C. Perkins, E. Whelan. October 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2974) 2975 Introduction to Accounting Management. B. Aboba, J. Arkko, D. Harrington. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2975) 2976 The SIP INFO Method. S. Donovan. October 2000. (Format: TXT, HTML) (Obsoleted by RFC6086) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2976) 2977 Mobile IP Authentication, Authorization, and Accounting Requirements. S. Glass, T. Hiller, S. Jacobs, C. Perkins. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2977) 2978 IANA Charset Registration Procedures. N. Freed, J. Postel. October 2000. (Format: TXT, HTML) (Obsoletes RFC2278) (Also BCP0019) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2978) 2979 Behavior of and Requirements for Internet Firewalls. N. Freed. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2979) 2980 Common NNTP Extensions. S. Barber. October 2000. (Format: TXT, HTML) (Updated by RFC3977, RFC4643, RFC4644, RFC6048) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2980) 2981 Event MIB. R. Kavasseri, Ed.. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2981) 2982 Distributed Management Expression MIB. R. Kavasseri, Ed.. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2982) 2983 Differentiated Services and Tunnels. D. Black. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2983) 2984 Use of the CAST-128 Encryption Algorithm in CMS. C. Adams. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2984) 2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0. M. Nystrom, B. Kaliski. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2985) 2986 PKCS #10: Certification Request Syntax Specification Version 1.7. M. Nystrom, B. Kaliski. November 2000. (Format: TXT, HTML) (Obsoletes RFC2314) (Updated by RFC5967) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2986) 2987 Registration of Charset and Languages Media Features Tags. P. Hoffman. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2987) 2988 Computing TCP's Retransmission Timer. V. Paxson, M. Allman. November 2000. (Format: TXT, HTML) (Obsoleted by RFC6298) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2988) 2989 Criteria for Evaluating AAA Protocols for Network Access. B. Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann, H. Shiino, P. Walsh, G. Zorn, G. Dommety, C. Perkins, B. Patil, D. Mitton, S. Manning, M. Beadles, X. Chen, S. Sivalingham, A. Hameed, M. Munson, S. Jacobs, B. Lim, B. Hirschman, R. Hsu, H. Koo, M. Lipford, E. Campbell, Y. Xu, S. Baba, E. Jaques. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2989) 2990 Next Steps for the IP QoS Architecture. G. Huston. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2990) 2991 Multipath Issues in Unicast and Multicast Next-Hop Selection. D. Thaler, C. Hopps. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2991) 2992 Analysis of an Equal-Cost Multi-Path Algorithm. C. Hopps. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2992) 2993 Architectural Implications of NAT. T. Hain. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2993) 2994 A Description of the MISTY1 Encryption Algorithm. H. Ohta, M. Matsui. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2994) 2995 Pre-Spirits Implementations of PSTN-initiated Services. H. Lu, Ed., I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J. Yoakum, L. Robart. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2995) 2996 Format of the RSVP DCLASS Object. Y. Bernet. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2996) 2997 Specification of the Null Service Type. Y. Bernet, A. Smith, B. Davie. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2997) 2998 A Framework for Integrated Services Operation over Diffserv Networks. Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. Braden, B. Davie, J. Wroclawski, E. Felstaine. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2998) 2999 Request for Comments Summary RFC Numbers 2900-2999. S. Ginoza. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2999) 3000 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza, L. Shiota. November 2001. (Format: TXT, HTML) (Obsoletes RFC2900) (Obsoleted by RFC3300) (Status: HISTORIC) (DOI: 10.17487/RFC3000) 3001 A URN Namespace of Object Identifiers. M. Mealling. November 2000. (Format: TXT, HTML) (Obsoleted by RFC3061) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3001) 3002 Overview of 2000 IAB Wireless Internetworking Workshop. D. Mitzel. December 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3002) 3003 The audio/mpeg Media Type. M. Nilsson. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3003) 3004 The User Class Option for DHCP. G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3004) 3005 IETF Discussion List Charter. S. Harris. November 2000. (Format: TXT, HTML) (Obsoleted by RFC9245) (Updated by RFC8717) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3005) 3006 Integrated Services in the Presence of Compressible Flows. B. Davie, C. Iturralde, D. Oran, S. Casner, J. Wroclawski. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3006) 3007 Secure Domain Name System (DNS) Dynamic Update. B. Wellington. November 2000. (Format: TXT, HTML) (Obsoletes RFC2137) (Updates RFC2535, RFC2136) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3007) 3008 Domain Name System Security (DNSSEC) Signing Authority. B. Wellington. November 2000. (Format: TXT, HTML) (Obsoleted by RFC4035, RFC4033, RFC4034) (Updates RFC2535) (Updated by RFC3658) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3008) 3009 Registration of parityfec MIME types. J. Rosenberg, H. Schulzrinne. November 2000. (Format: TXT, HTML) (Obsoleted by RFC5109) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3009) 3010 NFS version 4 Protocol. S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck. December 2000. (Format: TXT, HTML) (Obsoleted by RFC3530) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3010) 3011 The IPv4 Subnet Selection Option for DHCP. G. Waters. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3011) 3012 Mobile IPv4 Challenge/Response Extensions. C. Perkins, P. Calhoun. November 2000. (Format: TXT, HTML) (Obsoleted by RFC4721) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3012) 3013 Recommended Internet Service Provider Security Services and Procedures. T. Killalea. November 2000. (Format: TXT, HTML) (Also BCP0046) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3013) 3014 Notification Log MIB. R. Kavasseri. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3014) 3015 Megaco Protocol Version 1.0. F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers. November 2000. (Format: TXT, HTML) (Obsoletes RFC2885, RFC2886) (Obsoleted by RFC3525) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3015) 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams. Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata. November 2000. (Format: TXT, HTML) (Obsoleted by RFC6416) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3016) 3017 XML DTD for Roaming Access Phone Book. M. Riegel, G. Zorn. December 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3017) 3018 Unified Memory Space Protocol Specification. A. Bogdanov. December 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3018) 3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol. B. Haberman, R. Worzella. January 2001. (Format: TXT, HTML) (Obsoleted by RFC5519) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3019) 3020 Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function. P. Pate, B. Lynch, K. Rehbehn. December 2000. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3020) 3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links. A. Retana, R. White, V. Fuller, D. McPherson. December 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3021) 3022 Traditional IP Network Address Translator (Traditional NAT). P. Srisuresh, K. Egevang. January 2001. (Format: TXT, HTML) (Obsoletes RFC1631) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3022) 3023 XML Media Types. M. Murata, S. St. Laurent, D. Kohn. January 2001. (Format: TXT, HTML) (Obsoletes RFC2376) (Obsoleted by RFC7303) (Updates RFC2048) (Updated by RFC6839) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3023) 3024 Reverse Tunneling for Mobile IP, revised. G. Montenegro, Ed.. January 2001. (Format: TXT, HTML) (Obsoletes RFC2344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3024) 3025 Mobile IP Vendor/Organization-Specific Extensions. G. Dommety, K. Leung. February 2001. (Format: TXT, HTML) (Obsoleted by RFC3115) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3025) 3026 Liaison to IETF/ISOC on ENUM. R. Blane. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3026) 3027 Protocol Complications with the IP Network Address Translator. M. Holdrege, P. Srisuresh. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3027) 3028 Sieve: A Mail Filtering Language. T. Showalter. January 2001. (Format: TXT, HTML) (Obsoleted by RFC5228, RFC5429) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3028) 3029 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols. C. Adams, P. Sylvester, M. Zolotarev, R. Zuccherato. February 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3029) 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages. G. Vaudreuil. December 2000. (Format: TXT, HTML) (Obsoletes RFC1830) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3030) 3031 Multiprotocol Label Switching Architecture. E. Rosen, A. Viswanathan, R. Callon. January 2001. (Format: TXT, HTML) (Updated by RFC6178, RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3031) 3032 MPLS Label Stack Encoding. E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. January 2001. (Format: TXT, HTML) (Updated by RFC3443, RFC4182, RFC5332, RFC3270, RFC5129, RFC5462, RFC5586, RFC7274, RFC9017) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3032) 3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol. M. Suzuki. January 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3033) 3034 Use of Label Switching on Frame Relay Networks Specification. A. Conta, P. Doolan, A. Malis. January 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3034) 3035 MPLS using LDP and ATM VC Switching. B. Davie, J. Lawrence, K. McCloghrie, E. Rosen, G. Swallow, Y. Rekhter, P. Doolan. January 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3035) 3036 LDP Specification. L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas. January 2001. (Format: TXT, HTML) (Obsoleted by RFC5036) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3036) 3037 LDP Applicability. B. Thomas, E. Gray. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3037) 3038 VCID Notification over ATM link for LDP. K. Nagami, Y. Katsube, N. Demizu, H. Esaki, P. Doolan. January 2001. (Format: TXT, HTML) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3038) 3039 Internet X.509 Public Key Infrastructure Qualified Certificates Profile. S. Santesson, W. Polk, P. Barzin, M. Nystrom. January 2001. (Format: TXT, HTML) (Obsoleted by RFC3739) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3039) 3040 Internet Web Replication and Caching Taxonomy. I. Cooper, I. Melve, G. Tomlinson. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3040) 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves. January 2001. (Format: TXT, HTML) (Obsoleted by RFC4941) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3041) 3042 Enhancing TCP's Loss Recovery Using Limited Transmit. M. Allman, H. Balakrishnan, S. Floyd. January 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3042) 3043 The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations. M. Mealling. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3043) 3044 Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace. S. Rozenfeld. January 2001. (Format: TXT, HTML) (Obsoleted by RFC8254) (Status: HISTORIC) (DOI: 10.17487/RFC3044) 3045 Storing Vendor Information in the LDAP root DSE. M. Meredith. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3045) 3046 DHCP Relay Agent Information Option. M. Patrick. January 2001. (Format: TXT, HTML) (Updated by RFC6607) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3046) 3047 RTP Payload Format for ITU-T Recommendation G.722.1. P. Luthi. January 2001. (Format: TXT, HTML) (Obsoleted by RFC5577) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3047) 3048 Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer. B. Whetten, L. Vicisano, R. Kermode, M. Handley, S. Floyd, M. Luby. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3048) 3049 TN3270E Service Location and Session Balancing. J. Naugle, K. Kasthurirangan, G. Ledford. January 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3049) 3050 Common Gateway Interface for SIP. J. Lennox, H. Schulzrinne, J. Rosenberg. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3050) 3051 IP Payload Compression Using ITU-T V.44 Packet Method. J. Heath, J. Border. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3051) 3052 Service Management Architectures Issues and Review. M. Eder, S. Nag. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3052) 3053 IPv6 Tunnel Broker. A. Durand, P. Fasano, I. Guardini, D. Lento. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3053) 3054 Megaco IP Phone Media Gateway Application Profile. P. Blatherwick, R. Bell, P. Holland. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3054) 3055 Management Information Base for the PINT Services Architecture. M. Krishnaswamy, D. Romascanu. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3055) 3056 Connection of IPv6 Domains via IPv4 Clouds. B. Carpenter, K. Moore. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3056) 3057 ISDN Q.921-User Adaptation Layer. K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. February 2001. (Format: TXT, HTML) (Obsoleted by RFC4233) (Updated by RFC3807) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3057) 3058 Use of the IDEA Encryption Algorithm in CMS. S. Teiwes, P. Hartmann, D. Kuenzi. February 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3058) 3059 Attribute List Extension for the Service Location Protocol. E. Guttman. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3059) 3060 Policy Core Information Model -- Version 1 Specification. B. Moore, E. Ellesson, J. Strassner, A. Westerinen. February 2001. (Format: TXT, HTML) (Updated by RFC3460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3060) 3061 A URN Namespace of Object Identifiers. M. Mealling. February 2001. (Format: TXT, HTML) (Obsoletes RFC3001) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3061) 3062 LDAP Password Modify Extended Operation. K. Zeilenga. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3062) 3063 MPLS Loop Prevention Mechanism. Y. Ohba, Y. Katsube, E. Rosen, P. Doolan. February 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3063) 3064 MGCP CAS Packages. B. Foster. February 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3064) 3065 Autonomous System Confederations for BGP. P. Traina, D. McPherson, J. Scudder. February 2001. (Format: TXT, HTML) (Obsoletes RFC1965) (Obsoleted by RFC5065) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3065) 3066 Tags for the Identification of Languages. H. Alvestrand. January 2001. (Format: TXT, HTML) (Obsoletes RFC1766) (Obsoleted by RFC4646, RFC4647) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3066) 3067 TERENA'S Incident Object Description and Exchange Format Requirements. J. Arvidsson, A. Cormack, Y. Demchenko, J. Meijer. February 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3067) 3068 An Anycast Prefix for 6to4 Relay Routers. C. Huitema. June 2001. (Format: TXT, HTML) (Obsoleted by RFC7526) (Status: HISTORIC) (DOI: 10.17487/RFC3068) 3069 VLAN Aggregation for Efficient IP Address Allocation. D. McPherson, B. Dykes. February 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3069) 3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay. V. Rawat, R. Tio, S. Nanji, R. Verma. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3070) 3071 Reflections on the DNS, RFC 1591, and Categories of Domains. J. Klensin. February 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3071) 3072 Structured Data Exchange Format (SDXF). M. Wildgrube. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3072) 3073 Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration. J. Collins. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3073) 3074 DHC Load Balancing Algorithm. B. Volz, S. Gonczi, T. Lemon, R. Stevens. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3074) 3075 XML-Signature Syntax and Processing. D. Eastlake 3rd, J. Reagle, D. Solo. March 2001. (Format: TXT, HTML) (Obsoleted by RFC3275) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3075) 3076 Canonical XML Version 1.0. J. Boyer. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3076) 3077 A Link-Layer Tunneling Mechanism for Unidirectional Links. E. Duros, W. Dabbous, H. Izumiyama, N. Fujii, Y. Zhang. March 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3077) 3078 Microsoft Point-To-Point Encryption (MPPE) Protocol. G. Pall, G. Zorn. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3078) 3079 Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE). G. Zorn. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3079) 3080 The Blocks Extensible Exchange Protocol Core. M. Rose. March 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3080) 3081 Mapping the BEEP Core onto TCP. M. Rose. March 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3081) 3082 Notification and Subscription for SLP. J. Kempf, J. Goldschmidt. March 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3082) 3083 Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems. R. Woundy. March 2001. (Format: TXT, HTML) (Updated by RFC9141) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3083) 3084 COPS Usage for Policy Provisioning (COPS-PR). K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith. March 2001. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3084) 3085 URN Namespace for NewsML Resources. A. Coates, D. Allen, D. Rivers-Moore. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3085) 3086 Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification. K. Nichols, B. Carpenter. April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3086) 3087 Control of Service Context using SIP Request-URI. B. Campbell, R. Sparks. April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3087) 3088 OpenLDAP Root Service An experimental LDAP referral service. K. Zeilenga. April 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3088) 3089 A SOCKS-based IPv6/IPv4 Gateway Mechanism. H. Kitamura. April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3089) 3090 DNS Security Extension Clarification on Zone Status. E. Lewis. March 2001. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC2535) (Updated by RFC3658) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3090) 3091 Pi Digit Generation Protocol. H. Kennedy. 1 April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3091) 3092 Etymology of "Foo". D. Eastlake 3rd, C. Manros, E. Raymond. 1 April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3092) 3093 Firewall Enhancement Protocol (FEP). M. Gaynor, S. Bradner. 1 April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3093) 3094 Tekelec's Transport Adapter Layer Interface. D. Sprague, R. Benedyk, D. Brendes, J. Keller. April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3094) 3095 RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed. C. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T. Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T. Wiebke, T. Yoshimura, H. Zheng. July 2001. (Format: TXT, HTML) (Updated by RFC3759, RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3095) 3096 Requirements for robust IP/UDP/RTP header compression. M. Degermark, Ed.. July 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3096) 3097 RSVP Cryptographic Authentication -- Updated Message Type Value. R. Braden, L. Zhang. April 2001. (Format: TXT, HTML) (Updates RFC2747) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3097) 3098 How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$. T. Gavin, D. Eastlake 3rd, S. Hambridge. April 2001. (Format: TXT, HTML) (Also FYI0038) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3098) 3099 Request for Comments Summary RFC Numbers 3000-3099. S. Ginoza. November 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3099) 3100 Not Issued. 3101 The OSPF Not-So-Stubby Area (NSSA) Option. P. Murphy. January 2003. (Format: TXT, HTML) (Obsoletes RFC1587) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3101) 3102 Realm Specific IP: Framework. M. Borella, J. Lo, D. Grabelsky, G. Montenegro. October 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3102) 3103 Realm Specific IP: Protocol Specification. M. Borella, D. Grabelsky, J. Lo, K. Taniguchi. October 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3103) 3104 RSIP Support for End-to-end IPsec. G. Montenegro, M. Borella. October 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3104) 3105 Finding an RSIP Server with SLP. J. Kempf, G. Montenegro. October 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3105) 3106 ECML v1.1: Field Specifications for E-Commerce. D. Eastlake 3rd, T. Goldstein. April 2001. (Format: TXT, HTML) (Obsoletes RFC2706) (Updated by RFC4112) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3106) 3107 Carrying Label Information in BGP-4. Y. Rekhter, E. Rosen. May 2001. (Format: TXT, HTML) (Obsoleted by RFC8277) (Updated by RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3107) 3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections. R. Kumar, M. Mostafa. May 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3108) 3109 Request to Move STD 39 to Historic Status. R. Braden, R. Bush, J. Klensin. May 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3109) 3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS). D. Eastlake 3rd. May 2001. (Format: TXT, HTML) (Obsoletes RFC2537) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3110) 3111 Service Location Protocol Modifications for IPv6. E. Guttman. May 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3111) 3112 LDAP Authentication Password Schema. K. Zeilenga. May 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3112) 3113 3GPP-IETF Standardization Collaboration. K. Rosenbrock, R. Sanmugam, S. Bradner, J. Klensin. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3113) 3114 Implementing Company Classification Policy with the S/MIME Security Label. W. Nicolls. May 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3114) 3115 Mobile IP Vendor/Organization-Specific Extensions. G. Dommety, K. Leung. April 2001. (Format: TXT, HTML) (Obsoletes RFC3025) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3115) 3116 Methodology for ATM Benchmarking. J. Dunn, C. Martin. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3116) 3117 On the Design of Application Protocols. M. Rose. November 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3117) 3118 Authentication for DHCP Messages. R. Droms, Ed., W. Arbaugh, Ed.. June 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3118) 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio. R. Finlayson. June 2001. (Format: TXT, HTML) (Obsoleted by RFC5219) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3119) 3120 A URN Namespace for XML.org. K. Best, N. Walsh. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3120) 3121 A URN Namespace for OASIS. K. Best, N. Walsh. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3121) 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification. A. Conta. June 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3122) 3123 A DNS RR Type for Lists of Address Prefixes (APL RR). P. Koch. June 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3123) 3124 The Congestion Manager. H. Balakrishnan, S. Seshan. June 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3124) 3125 Electronic Signature Policies. J. Ross, D. Pinkas, N. Pope. September 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3125) 3126 Electronic Signature Formats for long term electronic signatures. D. Pinkas, J. Ross, N. Pope. September 2001. (Format: TXT, HTML) (Obsoleted by RFC5126) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3126) 3127 Authentication, Authorization, and Accounting: Protocol Evaluation. D. Mitton, M. St.Johns, S. Barkley, D. Nelson, B. Patil, M. Stevens, B. Wolff. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3127) 3128 Protection Against a Variant of the Tiny Fragment Attack (RFC 1858). I. Miller. June 2001. (Format: TXT, HTML) (Updates RFC1858) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3128) 3129 Requirements for Kerberized Internet Negotiation of Keys. M. Thomas. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3129) 3130 Notes from the State-Of-The-Technology: DNSSEC. E. Lewis. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3130) 3131 3GPP2-IETF Standardization Collaboration. S. Bradner, P. Calhoun, H. Cuschieri, S. Dennett, G. Flynn, M. Lipford, M. McPheters. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3131) 3132 Dormant Mode Host Alerting ("IP Paging") Problem Statement. J. Kempf. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3132) 3133 Terminology for Frame Relay Benchmarking. J. Dunn, C. Martin. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3133) 3134 Terminology for ATM ABR Benchmarking. J. Dunn, C. Martin. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3134) 3135 Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations. J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3135) 3136 The SPIRITS Architecture. L. Slutsman, Ed., I. Faynberg, H. Lu, M. Weissman. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3136) 3137 OSPF Stub Router Advertisement. A. Retana, L. Nguyen, R. White, A. Zinin, D. McPherson. June 2001. (Format: TXT, HTML) (Obsoleted by RFC6987) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3137) 3138 Extended Assignments in 233/8. D. Meyer. June 2001. (Format: TXT, HTML) (Obsoleted by RFC5771) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3138) 3139 Requirements for Configuration Management of IP-based Networks. L. Sanchez, K. McCloghrie, J. Saperia. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3139) 3140 Per Hop Behavior Identification Codes. D. Black, S. Brim, B. Carpenter, F. Le Faucheur. June 2001. (Format: TXT, HTML) (Obsoletes RFC2836) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3140) 3141 CDMA2000 Wireless Data Requirements for AAA. T. Hiller, P. Walsh, X. Chen, M. Munson, G. Dommety, S. Sivalingham, B. Lim, P. McCann, H. Shiino, B. Hirschman, S. Manning, R. Hsu, H. Koo, M. Lipford, P. Calhoun, C. Lo, E. Jaques, E. Campbell, Y. Xu, S. Baba, T. Ayaki, T. Seki, A. Hameed. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3141) 3142 An IPv6-to-IPv4 Transport Relay Translator. J. Hagino, K. Yamamoto. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3142) 3143 Known HTTP Proxy/Caching Problems. I. Cooper, J. Dilley. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3143) 3144 Remote Monitoring MIB Extensions for Interface Parameters Monitoring. D. Romascanu. August 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3144) 3145 L2TP Disconnect Cause Information. R. Verma, M. Verma, J. Carlson. July 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3145) 3146 Transmission of IPv6 Packets over IEEE 1394 Networks. K. Fujisawa, A. Onoe. October 2001. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3146) 3147 Generic Routing Encapsulation over CLNS Networks. P. Christian. July 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3147) 3148 A Framework for Defining Empirical Bulk Transfer Capacity Metrics. M. Mathis, M. Allman. July 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3148) 3149 MGCP Business Phone Packages. A. Srinath, G. Levendel, K. Fritz, R. Kalyanaram. September 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3149) 3150 End-to-end Performance Implications of Slow Links. S. Dawkins, G. Montenegro, M. Kojo, V. Magret. July 2001. (Format: TXT, HTML) (Also BCP0048) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3150) 3151 A URN Namespace for Public Identifiers. N. Walsh, J. Cowan, P. Grosso. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3151) 3152 Delegation of IP6.ARPA. R. Bush. August 2001. (Format: TXT, HTML) (Obsoleted by RFC3596) (Updates RFC2874, RFC2772, RFC2766, RFC2553, RFC1886) (Also BCP0049) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3152) 3153 PPP Multiplexing. R. Pazhyannur, I. Ali, C. Fox. August 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3153) 3154 Requirements and Functional Architecture for an IP Host Alerting Protocol. J. Kempf, C. Castelluccia, P. Mutaf, N. Nakajima, Y. Ohba, R. Ramjee, Y. Saifullah, B. Sarikaya, X. Xu. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3154) 3155 End-to-end Performance Implications of Links with Errors. S. Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya. August 2001. (Format: TXT, HTML) (Also BCP0050) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3155) 3156 MIME Security with OpenPGP. M. Elkins, D. Del Torto, R. Levien, T. Roessler. August 2001. (Format: TXT, HTML) (Updates RFC2015) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3156) 3157 Securely Available Credentials - Requirements. A. Arsenault, S. Farrell. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3157) 3158 RTP Testing Strategies. C. Perkins, J. Rosenberg, H. Schulzrinne. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3158) 3159 Structure of Policy Provisioning Information (SPPI). K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer. August 2001. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3159) 3160 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force. S. Harris. August 2001. (Format: TXT, HTML) (Obsoletes RFC1718) (Obsoleted by RFC4677) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3160) 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). C. Adams, P. Cain, D. Pinkas, R. Zuccherato. August 2001. (Format: TXT, HTML) (Updated by RFC5816) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3161) 3162 RADIUS and IPv6. B. Aboba, G. Zorn, D. Mitton. August 2001. (Format: TXT, HTML) (Updated by RFC8044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3162) 3163 ISO/IEC 9798-3 Authentication SASL Mechanism. R. Zuccherato, M. Nystrom. August 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3163) 3164 The BSD Syslog Protocol. C. Lonvick. August 2001. (Format: TXT, HTML) (Obsoleted by RFC5424) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3164) 3165 Definitions of Managed Objects for the Delegation of Management Scripts. D. Levi, J. Schoenwaelder. August 2001. (Format: TXT, HTML) (Obsoletes RFC2592) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3165) 3166 Request to Move RFC 1403 to Historic Status. D. Meyer, J. Scudder. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3166) 3167 Request to Move RFC 1745 to Historic Status. D. Meyer, J. Scudder. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3167) 3168 The Addition of Explicit Congestion Notification (ECN) to IP. K. Ramakrishnan, S. Floyd, D. Black. September 2001. (Format: TXT, HTML) (Obsoletes RFC2481) (Updates RFC2003, RFC2474, RFC2401, RFC0793) (Updated by RFC4301, RFC6040, RFC8311) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3168) 3169 Criteria for Evaluating Network Access Server Protocols. M. Beadles, D. Mitton. September 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3169) 3170 IP Multicast Applications: Challenges and Solutions. B. Quinn, K. Almeroth. September 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3170) 3171 IANA Guidelines for IPv4 Multicast Address Assignments. Z. Albanna, K. Almeroth, D. Meyer, M. Schipper. August 2001. (Format: TXT, HTML) (Obsoleted by RFC5771) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3171) 3172 Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa"). G. Huston, Ed.. September 2001. (Format: TXT, HTML) (Updated by RFC9120) (Also BCP0052) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3172) 3173 IP Payload Compression Protocol (IPComp). A. Shacham, B. Monsour, R. Pereira, M. Thomas. September 2001. (Format: TXT, HTML) (Obsoletes RFC2393) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3173) 3174 US Secure Hash Algorithm 1 (SHA1). D. Eastlake 3rd, P. Jones. September 2001. (Format: TXT, HTML) (Updated by RFC4634, RFC6234) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3174) 3175 Aggregation of RSVP for IPv4 and IPv6 Reservations. F. Baker, C. Iturralde, F. Le Faucheur, B. Davie. September 2001. (Format: TXT, HTML) (Updated by RFC5350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3175) 3176 InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks. P. Phaal, S. Panchen, N. McKee. September 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3176) 3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites. IAB, IESG. September 2001. (Format: TXT, HTML) (Obsoleted by RFC6177) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3177) 3178 IPv6 Multihoming Support at Site Exit Routers. J. Hagino, H. Snyder. October 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3178) 3179 Script MIB Extensibility Protocol Version 1.1. J. Schoenwaelder, J. Quittek. October 2001. (Format: TXT, HTML) (Obsoletes RFC2593) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3179) 3180 GLOP Addressing in 233/8. D. Meyer, P. Lothberg. September 2001. (Format: TXT, HTML) (Obsoletes RFC2770) (Also BCP0053) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3180) 3181 Signaled Preemption Priority Policy Element. S. Herzog. October 2001. (Format: TXT, HTML) (Obsoletes RFC2751) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3181) 3182 Identity Representation for RSVP. S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, R. Hess. October 2001. (Format: TXT, HTML) (Obsoletes RFC2752) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3182) 3183 Domain Security Services using S/MIME. T. Dean, W. Ottaway. October 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3183) 3184 IETF Guidelines for Conduct. S. Harris. October 2001. (Format: TXT, HTML) (Obsoleted by RFC7154) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3184) 3185 Reuse of CMS Content Encryption Keys. S. Farrell, S. Turner. October 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3185) 3186 MAPOS/PPP Tunneling mode. S. Shimizu, T. Kawano, K. Murakami, E. Beier. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3186) 3187 Using International Standard Book Numbers as Uniform Resource Names. J. Hakala, H. Walravens. October 2001. (Format: TXT, HTML) (Obsoleted by RFC8254) (Status: HISTORIC) (DOI: 10.17487/RFC3187) 3188 Using National Bibliography Numbers as Uniform Resource Names. J. Hakala. October 2001. (Format: TXT, HTML) (Obsoleted by RFC8458) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3188) 3189 RTP Payload Format for DV (IEC 61834) Video. K. Kobayashi, A. Ogawa, S. Casner, C. Bormann. January 2002. (Format: TXT, HTML) (Obsoleted by RFC6469) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3189) 3190 RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio. K. Kobayashi, A. Ogawa, S. Casner, C. Bormann. January 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3190) 3191 Minimal GSTN address format in Internet Mail. C. Allocchio. October 2001. (Format: TXT, HTML) (Obsoletes RFC2303) (Updates RFC2846) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3191) 3192 Minimal FAX address format in Internet Mail. C. Allocchio. October 2001. (Format: TXT, HTML) (Obsoletes RFC2304) (Updates RFC2846) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3192) 3193 Securing L2TP using IPsec. B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth. November 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3193) 3194 The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio. A. Durand, C. Huitema. November 2001. (Format: TXT, HTML) (Updates RFC1715) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3194) 3195 Reliable Delivery for syslog. D. New, M. Rose. November 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3195) 3196 Internet Printing Protocol/1.1: Implementor's Guide. T. Hastings, C. Manros, P. Zehler, C. Kugler, H. Holst. November 2001. (Format: TXT, HTML) (Obsoletes RFC2639) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3196) 3197 Applicability Statement for DNS MIB Extensions. R. Austein. November 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3197) 3198 Terminology for Policy-Based Management. A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A. Huynh, M. Carlson, J. Perry, S. Waldbusser. November 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3198) 3199 Request for Comments Summary RFC Numbers 3100-3199. S. Ginoza. February 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3199) 3200 Not Issued. 3201 Definitions of Managed Objects for Circuit to Interface Translation. R. Steinberger, O. Nicklass. January 2002. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3201) 3202 Definitions of Managed Objects for Frame Relay Service Level Definitions. R. Steinberger, O. Nicklass. January 2002. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3202) 3203 DHCP reconfigure extension. Y. T'Joens, C. Hublet, P. De Schrijver. December 2001. (Format: TXT, HTML) (Updated by RFC6704) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3203) 3204 MIME media types for ISUP and QSIG Objects. E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M. Watson, M. Zonoun. December 2001. (Format: TXT, HTML) (Updated by RFC3459, RFC5621) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3204) 3205 On the use of HTTP as a Substrate. K. Moore. February 2002. (Format: TXT, HTML) (Obsoleted by RFC9205) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3205) 3206 The SYS and AUTH POP Response Codes. R. Gellens. February 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3206) 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security. P. Hoffman. February 2002. (Format: TXT, HTML) (Obsoletes RFC2487) (Updated by RFC7817) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3207) 3208 PGM Reliable Transport Protocol Specification. T. Speakman, J. Crowcroft, J. Gemmell, D. Farinacci, S. Lin, D. Leshchiner, M. Luby, T. Montgomery, L. Rizzo, A. Tweedly, N. Bhaskar, R. Edmonstone, R. Sumanasekera, L. Vicisano. December 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3208) 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels. D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. December 2001. (Format: TXT, HTML) (Updated by RFC3936, RFC4420, RFC4874, RFC5151, RFC5420, RFC5711, RFC6780, RFC6790, RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3209) 3210 Applicability Statement for Extensions to RSVP for LSP-Tunnels. D. Awduche, A. Hannan, X. Xiao. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3210) 3211 Password-based Encryption for CMS. P. Gutmann. December 2001. (Format: TXT, HTML) (Obsoleted by RFC3369, RFC3370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3211) 3212 Constraint-Based LSP Setup using LDP. B. Jamoussi, Ed., L. Andersson, R. Callon, R. Dantu, L. Wu, P. Doolan, T. Worster, N. Feldman, A. Fredette, M. Girish, E. Gray, J. Heinanen, T. Kilty, A. Malis. January 2002. (Format: TXT, HTML) (Updated by RFC3468, RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3212) 3213 Applicability Statement for CR-LDP. J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3213) 3214 LSP Modification Using CR-LDP. J. Ash, Y. Lee, P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki, L. Li. January 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3214) 3215 LDP State Machine. C. Boscher, P. Cheval, L. Wu, E. Gray. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3215) 3216 SMIng Objectives. C. Elliott, D. Harrington, J. Jason, J. Schoenwaelder, F. Strauss, W. Weiss. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3216) 3217 Triple-DES and RC2 Key Wrapping. R. Housley. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3217) 3218 Preventing the Million Message Attack on Cryptographic Message Syntax. E. Rescorla. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3218) 3219 Telephony Routing over IP (TRIP). J. Rosenberg, H. Salama, M. Squire. January 2002. (Format: TXT, HTML) (Updated by RFC8602) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3219) 3220 IP Mobility Support for IPv4. C. Perkins, Ed.. January 2002. (Format: TXT, HTML) (Obsoletes RFC2002) (Obsoleted by RFC3344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3220) 3221 Commentary on Inter-Domain Routing in the Internet. G. Huston. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3221) 3222 Terminology for Forwarding Information Base (FIB) based Router Performance. G. Trotter. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3222) 3223 Not Issued. 3224 Vendor Extensions for Service Location Protocol, Version 2. E. Guttman. January 2002. (Format: TXT, HTML) (Updates RFC2608) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3224) 3225 Indicating Resolver Support of DNSSEC. D. Conrad. December 2001. (Format: TXT, HTML) (Updated by RFC4033, RFC4034, RFC4035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3225) 3226 DNSSEC and IPv6 A6 aware server/resolver message size requirements. O. Gudmundsson. December 2001. (Format: TXT, HTML) (Updates RFC2535, RFC2874) (Updated by RFC4033, RFC4034, RFC4035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3226) 3227 Guidelines for Evidence Collection and Archiving. D. Brezinski, T. Killalea. February 2002. (Format: TXT, HTML) (Also BCP0055) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3227) 3228 IANA Considerations for IPv4 Internet Group Management Protocol (IGMP). B. Fenner. February 2002. (Format: TXT, HTML) (Also BCP0057) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3228) 3229 Delta encoding in HTTP. J. Mogul, B. Krishnamurthy, F. Douglis, A. Feldmann, Y. Goland, A. van Hoff, D. Hellerstein. January 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3229) 3230 Instance Digests in HTTP. J. Mogul, A. Van Hoff. January 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3230) 3231 Definitions of Managed Objects for Scheduling Management Operations. D. Levi, J. Schoenwaelder. January 2002. (Format: TXT, HTML) (Obsoletes RFC2591) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3231) 3232 Assigned Numbers: RFC 1700 is Replaced by an On-line Database. J. Reynolds, Ed.. January 2002. (Format: TXT, HTML) (Obsoletes RFC1700) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3232) 3233 Defining the IETF. P. Hoffman, S. Bradner. February 2002. (Format: TXT, HTML) (Also BCP0058) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3233) 3234 Middleboxes: Taxonomy and Issues. B. Carpenter, S. Brim. February 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3234) 3235 Network Address Translator (NAT)-Friendly Application Design Guidelines. D. Senie. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3235) 3236 The 'application/xhtml+xml' Media Type. M. Baker, P. Stark. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3236) 3237 Requirements for Reliable Server Pooling. M. Tuexen, Q. Xie, R. Stewart, M. Shore, L. Ong, J. Loughney, M. Stillman. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3237) 3238 IAB Architectural and Policy Considerations for Open Pluggable Edge Services. S. Floyd, L. Daigle. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3238) 3239 Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations. C. Kugler, H. Lewis, T. Hastings. February 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3239) 3240 Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration. D. Clunie, E. Cordonnier. February 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3240) 3241 Robust Header Compression (ROHC) over PPP. C. Bormann. April 2002. (Format: TXT, HTML) (Updates RFC1332) (Updated by RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3241) 3242 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP. L-E. Jonsson, G. Pelletier. April 2002. (Format: TXT, HTML) (Obsoleted by RFC4362) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3242) 3243 RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression. L-E. Jonsson. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3243) 3244 Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols. M. Swift, J. Trostle, J. Brezak. February 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3244) 3245 The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2). J. Klensin, Ed., IAB. March 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3245) 3246 An Expedited Forwarding PHB (Per-Hop Behavior). B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis. March 2002. (Format: TXT, HTML) (Obsoletes RFC2598) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3246) 3247 Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior). A. Charny, J. Bennet, K. Benson, J. Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C. Kalmanek, K. Ramakrishnan. March 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3247) 3248 A Delay Bound alternative revision of RFC 2598. G. Armitage, B. Carpenter, A. Casati, J. Crowcroft, J. Halpern, B. Kumar, J. Schnizlein. March 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3248) 3249 Implementers Guide for Facsimile Using Internet Mail. V. Cancio, M. Moldovan, H. Tamura, D. Wing. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3249) 3250 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration. L. McIntyre, G. Parsons, J. Rafferty. September 2002. (Format: TXT, HTML) (Obsoleted by RFC3950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3250) 3251 Electricity over IP. B. Rajagopalan. 1 April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3251) 3252 Binary Lexical Octet Ad-hoc Transport. H. Kennedy. 1 April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3252) 3253 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning). G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead. March 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3253) 3254 Definitions for talking about directories. H. Alvestrand. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3254) 3255 Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads. N. Jones, C. Murton. April 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3255) 3256 The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option. D. Jones, R. Woundy. April 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3256) 3257 Stream Control Transmission Protocol Applicability Statement. L. Coene. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3257) 3258 Distributing Authoritative Name Servers via Shared Unicast Addresses. T. Hardie. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3258) 3259 A Message Bus for Local Coordination. J. Ott, C. Perkins, D. Kutscher. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3259) 3260 New Terminology and Clarifications for Diffserv. D. Grossman. April 2002. (Format: TXT, HTML) (Updates RFC2474, RFC2475, RFC2597) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3260) 3261 SIP: Session Initiation Protocol. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. June 2002. (Format: TXT, HTML) (Obsoletes RFC2543) (Updated by RFC3265, RFC3853, RFC4320, RFC4916, RFC5393, RFC5621, RFC5626, RFC5630, RFC5922, RFC5954, RFC6026, RFC6141, RFC6665, RFC6878, RFC7462, RFC7463, RFC8217, RFC8591, RFC8760, RFC8898, RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3261) 3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne. June 2002. (Format: TXT, HTML) (Obsoletes RFC2543) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3262) 3263 Session Initiation Protocol (SIP): Locating SIP Servers. J. Rosenberg, H. Schulzrinne. June 2002. (Format: TXT, HTML) (Obsoletes RFC2543) (Updated by RFC7984, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3263) 3264 An Offer/Answer Model with Session Description Protocol (SDP). J. Rosenberg, H. Schulzrinne. June 2002. (Format: TXT, HTML) (Obsoletes RFC2543) (Updated by RFC6157, RFC8843, RFC9143) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3264) 3265 Session Initiation Protocol (SIP)-Specific Event Notification. A. B. Roach. June 2002. (Format: TXT, HTML) (Obsoletes RFC2543) (Obsoleted by RFC6665) (Updates RFC3261) (Updated by RFC5367, RFC5727, RFC6446) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3265) 3266 Support for IPv6 in Session Description Protocol (SDP). S. Olson, G. Camarillo, A. B. Roach. June 2002. (Format: TXT, HTML) (Obsoleted by RFC4566) (Updates RFC2327) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3266) 3267 Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs. J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie. June 2002. (Format: TXT, HTML) (Obsoleted by RFC4867) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3267) 3268 Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS). P. Chown. June 2002. (Format: TXT, HTML) (Obsoleted by RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3268) 3269 Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents. R. Kermode, L. Vicisano. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3269) 3270 Multi-Protocol Label Switching (MPLS) Support of Differentiated Services. F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen. May 2002. (Format: TXT, HTML) (Updates RFC3032) (Updated by RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3270) 3271 The Internet is for Everyone. V. Cerf. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3271) 3272 Overview and Principles of Internet Traffic Engineering. D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao. May 2002. (Format: TXT, HTML) (Updated by RFC5462) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3272) 3273 Remote Network Monitoring Management Information Base for High Capacity Networks. S. Waldbusser. July 2002. (Format: TXT, HTML) (Updated by RFC4502) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3273) 3274 Compressed Data Content Type for Cryptographic Message Syntax (CMS). P. Gutmann. June 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3274) 3275 (Extensible Markup Language) XML-Signature Syntax and Processing. D. Eastlake 3rd, J. Reagle, D. Solo. March 2002. (Format: TXT, HTML) (Obsoletes RFC3075) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3275) 3276 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing. B. Ray, R. Abbi. May 2002. (Format: TXT, HTML) (Obsoleted by RFC4319) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3276) 3277 Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance. D. McPherson. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3277) 3278 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS). S. Blake-Wilson, D. Brown, P. Lambert. April 2002. (Format: TXT, HTML) (Obsoleted by RFC5753) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3278) 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. L. Bassham, W. Polk, R. Housley. April 2002. (Format: TXT, HTML) (Updated by RFC4055, RFC4491, RFC5480, RFC5758, RFC8692) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3279) 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. R. Housley, W. Polk, W. Ford, D. Solo. April 2002. (Format: TXT, HTML) (Obsoletes RFC2459) (Obsoleted by RFC5280) (Updated by RFC4325, RFC4630) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3280) 3281 An Internet Attribute Certificate Profile for Authorization. S. Farrell, R. Housley. April 2002. (Format: TXT, HTML) (Obsoleted by RFC5755) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3281) 3282 Content Language Headers. H. Alvestrand. May 2002. (Format: TXT, HTML) (Obsoletes RFC1766) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3282) 3283 Guide to Internet Calendaring. B. Mahoney, G. Babics, A. Taler. June 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3283) 3284 The VCDIFF Generic Differencing and Compression Data Format. D. Korn, J. MacDonald, J. Mogul, K. Vo. June 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3284) 3285 Using Microsoft Word to create Internet Drafts and RFCs. M. Gahrns, T. Hain. May 2002. (Format: TXT, HTML) (Obsoleted by RFC5385) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3285) 3286 An Introduction to the Stream Control Transmission Protocol (SCTP). L. Ong, J. Yoakum. May 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3286) 3287 Remote Monitoring MIB Extensions for Differentiated Services. A. Bierman. July 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3287) 3288 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP). E. O'Tuathail, M. Rose. June 2002. (Format: TXT, HTML) (Obsoleted by RFC4227) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3288) 3289 Management Information Base for the Differentiated Services Architecture. F. Baker, K. Chan, A. Smith. May 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3289) 3290 An Informal Management Model for Diffserv Routers. Y. Bernet, S. Blake, D. Grossman, A. Smith. May 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3290) 3291 Textual Conventions for Internet Network Addresses. M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. May 2002. (Format: TXT, HTML) (Obsoletes RFC2851) (Obsoleted by RFC4001) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3291) 3292 General Switch Management Protocol (GSMP) V3. A. Doria, F. Hellstrand, K. Sundell, T. Worster. June 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3292) 3293 General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP). T. Worster, A. Doria, J. Buerkle. June 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3293) 3294 General Switch Management Protocol (GSMP) Applicability. A. Doria, K. Sundell. June 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3294) 3295 Definitions of Managed Objects for the General Switch Management Protocol (GSMP). H. Sjostrand, J. Buerkle, B. Srinivasan. June 2002. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3295) 3296 Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories. K. Zeilenga. July 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3296) 3297 Content Negotiation for Messaging Services based on Email. G. Klyne, R. Iwazaki, D. Crocker. July 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3297) 3298 Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements. I. Faynberg, J. Gato, H. Lu, L. Slutsman. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3298) 3299 Request for Comments Summary RFC Numbers 3200-3299. S. Ginoza. December 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3299) 3300 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza, A. De La Cruz. November 2002. (Format: TXT, HTML) (Obsoletes RFC3000) (Obsoleted by RFC3600) (Status: HISTORIC) (DOI: 10.17487/RFC3300) 3301 Layer Two Tunnelling Protocol (L2TP): ATM access network extensions. Y. T'Joens, P. Crivellari, B. Sales. June 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3301) 3302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration. G. Parsons, J. Rafferty. September 2002. (Format: TXT, HTML) (Obsoletes RFC2302) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3302) 3303 Middlebox communication architecture and framework. P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3303) 3304 Middlebox Communications (midcom) Protocol Requirements. R. P. Swale, P. A. Mart, P. Sijben, S. Brim, M. Shore. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3304) 3305 Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations. M. Mealling, Ed., R. Denenberg, Ed.. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3305) 3306 Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman, D. Thaler. August 2002. (Format: TXT, HTML) (Updated by RFC3956, RFC4489, RFC7371) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3306) 3307 Allocation Guidelines for IPv6 Multicast Addresses. B. Haberman. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3307) 3308 Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension. P. Calhoun, W. Luo, D. McPherson, K. Peirce. November 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3308) 3309 Stream Control Transmission Protocol (SCTP) Checksum Change. J. Stone, R. Stewart, D. Otis. September 2002. (Format: TXT, HTML) (Obsoleted by RFC4960) (Updates RFC2960) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3309) 3310 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA). A. Niemi, J. Arkko, V. Torvinen. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3310) 3311 The Session Initiation Protocol (SIP) UPDATE Method. J. Rosenberg. October 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3311) 3312 Integration of Resource Management and Session Initiation Protocol (SIP). G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg. October 2002. (Format: TXT, PS, PDF, HTML) (Updated by RFC4032, RFC5027) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3312) 3313 Private Session Initiation Protocol (SIP) Extensions for Media Authorization. W. Marshall, Ed.. January 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3313) 3314 Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards. M. Wasserman, Ed.. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3314) 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July 2003. (Format: TXT, HTML) (Obsoleted by RFC8415) (Updated by RFC4361, RFC5494, RFC6221, RFC6422, RFC6644, RFC7083, RFC7227, RFC7283, RFC7550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3315) 3316 Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts. J. Arkko, G. Kuijpers, H. Soliman, J. Loughney, J. Wiljakka. April 2003. (Format: TXT, HTML) (Obsoleted by RFC7066) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3316) 3317 Differentiated Services Quality of Service Policy Information Base. K. Chan, R. Sahita, S. Hahn, K. McCloghrie. March 2003. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3317) 3318 Framework Policy Information Base. R. Sahita, Ed., S. Hahn, K. Chan, K. McCloghrie. March 2003. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3318) 3319 Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers. H. Schulzrinne, B. Volz. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3319) 3320 Signaling Compression (SigComp). R. Price, C. Bormann, J. Christoffersson, H. Hannu, Z. Liu, J. Rosenberg. January 2003. (Format: TXT, HTML) (Updated by RFC4896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3320) 3321 Signaling Compression (SigComp) - Extended Operations. H. Hannu, J. Christoffersson, S. Forsgren, K.-C. Leung, Z. Liu, R. Price. January 2003. (Format: TXT, HTML) (Updated by RFC4896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3321) 3322 Signaling Compression (SigComp) Requirements & Assumptions. H. Hannu. January 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3322) 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP). J. Peterson. November 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3323) 3324 Short Term Requirements for Network Asserted Identity. M. Watson. November 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3324) 3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks. C. Jennings, J. Peterson, M. Watson. November 2002. (Format: TXT, HTML) (Updated by RFC5876, RFC8217) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3325) 3326 The Reason Header Field for the Session Initiation Protocol (SIP). H. Schulzrinne, D. Oran, G. Camarillo. December 2002. (Format: TXT, HTML) (Updated by RFC8606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3326) 3327 Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts. D. Willis, B. Hoeneisen. December 2002. (Format: TXT, HTML) (Updated by RFC5626) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3327) 3328 Not Issued. 3329 Security Mechanism Agreement for the Session Initiation Protocol (SIP). J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, T. Haukka. January 2003. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3329) 3330 Special-Use IPv4 Addresses. IANA. September 2002. (Format: TXT, HTML) (Obsoleted by RFC5735) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3330) 3331 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer. K. Morneault, R. Dantu, G. Sidebottom, B. Bidulock, J. Heitz. September 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3331) 3332 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA). G. Sidebottom, Ed., K. Morneault, Ed., J. Pastor-Balbas, Ed.. September 2002. (Format: TXT, HTML) (Obsoleted by RFC4666) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3332) 3333 Not Issued. 3334 Policy-Based Accounting. T. Zseby, S. Zander, C. Carle. October 2002. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3334) 3335 MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet. T. Harding, R. Drummond, C. Shih. September 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3335) 3336 PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2). B. Thompson, T. Koren, B. Buffam. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3336) 3337 Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2. B. Thompson, T. Koren, B. Buffam. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3337) 3338 Dual Stack Hosts Using "Bump-in-the-API" (BIA). S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand. October 2002. (Format: TXT, HTML) (Obsoleted by RFC6535) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3338) 3339 Date and Time on the Internet: Timestamps. G. Klyne, C. Newman. July 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3339) 3340 The Application Exchange Core. M. Rose, G. Klyne, D. Crocker. July 2002. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3340) 3341 The Application Exchange (APEX) Access Service. M. Rose, G. Klyne, D. Crocker. July 2002. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3341) 3342 The Application Exchange (APEX) Option Party Pack, Part Deux!. E. Dixon, H. Franklin, J. Kint, G. Klyne, D. New, S. Pead, M. Rose, M. Schwartz. July 2002. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3342) 3343 The Application Exchange (APEX) Presence Service. M. Rose, G. Klyne, D. Crocker. April 2003. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3343) 3344 IP Mobility Support for IPv4. C. Perkins, Ed.. August 2002. (Format: TXT, HTML) (Obsoletes RFC3220) (Obsoleted by RFC5944) (Updated by RFC4636, RFC4721) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3344) 3345 Border Gateway Protocol (BGP) Persistent Route Oscillation Condition. D. McPherson, V. Gill, D. Walton, A. Retana. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3345) 3346 Applicability Statement for Traffic Engineering with MPLS. J. Boyle, V. Gill, A. Hannan, D. Cooper, D. Awduche, B. Christian, W.S. Lai. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3346) 3347 Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations. M. Krueger, R. Haagens. July 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3347) 3348 The Internet Message Action Protocol (IMAP4) Child Mailbox Extension. M. Gahrns, R. Cheng. July 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3348) 3349 A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force. M. Rose. July 2002. (Format: TXT, HTML) (Also BCP0059) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3349) 3350 Not Issued. 3351 User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals. N. Charlton, M. Gasson, G. Gybels, M. Spanner, A. van Wijk. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3351) 3352 Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status. K. Zeilenga. March 2003. (Format: TXT, HTML) (Obsoletes RFC1798) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3352) 3353 Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment. D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul, F. Ansari. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3353) 3354 Internet Open Trading Protocol Version 2 Requirements. D. Eastlake 3rd. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3354) 3355 Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5). A. Singh, R. Turner, R. Tio, S. Nanji. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3355) 3356 Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines. G. Fishman, S. Bradner. August 2002. (Format: TXT, HTML) (Obsoletes RFC2436) (Obsoleted by RFC6756) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3356) 3357 One-way Loss Pattern Sample Metrics. R. Koodli, R. Ravikanth. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3357) 3358 Optional Checksums in Intermediate System to Intermediate System (ISIS). T. Przygienda. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3358) 3359 Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System. T. Przygienda. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3359) 3360 Inappropriate TCP Resets Considered Harmful. S. Floyd. August 2002. (Format: TXT, HTML) (Also BCP0060) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3360) 3361 Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers. H. Schulzrinne. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3361) 3362 Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration. G. Parsons. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3362) 3363 Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS). R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain. August 2002. (Format: TXT, HTML) (Updates RFC2673, RFC2874) (Updated by RFC6672) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3363) 3364 Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6). R. Austein. August 2002. (Format: TXT, HTML) (Updates RFC2673, RFC2874) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3364) 3365 Strong Security Requirements for Internet Engineering Task Force Standard Protocols. J. Schiller. August 2002. (Format: TXT, HTML) (Also BCP0061) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3365) 3366 Advice to link designers on link Automatic Repeat reQuest (ARQ). G. Fairhurst, L. Wood. August 2002. (Format: TXT, HTML) (Also BCP0062) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3366) 3367 Common Name Resolution Protocol (CNRP). N. Popp, M. Mealling, M. Moseley. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3367) 3368 The 'go' URI Scheme for the Common Name Resolution Protocol. M. Mealling. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3368) 3369 Cryptographic Message Syntax (CMS). R. Housley. August 2002. (Format: TXT, HTML) (Obsoletes RFC2630, RFC3211) (Obsoleted by RFC3852) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3369) 3370 Cryptographic Message Syntax (CMS) Algorithms. R. Housley. August 2002. (Format: TXT, HTML) (Obsoletes RFC2630, RFC3211) (Updated by RFC5754, RFC8702) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3370) 3371 Layer Two Tunneling Protocol "L2TP" Management Information Base. E. Caves, P. Calhoun, R. Wheeler. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3371) 3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures. A. Vemuri, J. Peterson. September 2002. (Format: TXT, HTML) (Also BCP0063) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3372) 3373 Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies. D. Katz, R. Saluja. September 2002. (Format: TXT, HTML) (Obsoleted by RFC5303) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3373) 3374 Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network. J. Kempf, Ed.. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3374) 3375 Generic Registry-Registrar Protocol Requirements. S. Hollenbeck. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3375) 3376 Internet Group Management Protocol, Version 3. B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan. October 2002. (Format: TXT, HTML) (Updates RFC2236) (Updated by RFC4604) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3376) 3377 Lightweight Directory Access Protocol (v3): Technical Specification. J. Hodges, R. Morgan. September 2002. (Format: TXT, HTML) (Obsoleted by RFC4510) (Updates RFC2251, RFC2252, RFC2253, RFC2254, RFC2255, RFC2256, RFC2829, RFC2830) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3377) 3378 EtherIP: Tunneling Ethernet Frames in IP Datagrams. R. Housley, S. Hollenbeck. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3378) 3379 Delegated Path Validation and Delegated Path Discovery Protocol Requirements. D. Pinkas, R. Housley. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3379) 3380 Internet Printing Protocol (IPP): Job and Printer Set Operations. T. Hastings, R. Herriot, C. Kugler, H. Lewis. September 2002. (Format: TXT, HTML) (Updates RFC2910, RFC2911) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3380) 3381 Internet Printing Protocol (IPP): Job Progress Attributes. T. Hastings, H. Lewis, R. Bergman. September 2002. (Format: TXT, HTML) (Obsoleted by RFC8011) (Updates RFC2910) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3381) 3382 Internet Printing Protocol (IPP): The 'collection' attribute syntax. R. deBry, T. Hastings, R. Herriot, K. Ocke, P. Zehler. September 2002. (Format: TXT, HTML) (Obsoleted by RFC8010, RFC8011) (Updates RFC2910, RFC2911) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3382) 3383 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. September 2002. (Format: TXT, HTML) (Obsoleted by RFC4520) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3383) 3384 Lightweight Directory Access Protocol (version 3) Replication Requirements. E. Stokes, R. Weiser, R. Moats, R. Huber. October 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3384) 3385 Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations. D. Sheinwald, J. Satran, P. Thaler, V. Cavanna. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3385) 3386 Network Hierarchy and Multilayer Survivability. W. Lai, Ed., D. McDysan, Ed.. November 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3386) 3387 Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network. M. Eder, H. Chaskar, S. Nag. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3387) 3388 Grouping of Media Lines in the Session Description Protocol (SDP). G. Camarillo, G. Eriksson, J. Holler, H. Schulzrinne. December 2002. (Format: TXT, HTML) (Obsoleted by RFC5888) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3388) 3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN). R. Zopf. September 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3389) 3390 Increasing TCP's Initial Window. M. Allman, S. Floyd, C. Partridge. October 2002. (Format: TXT, HTML) (Obsoletes RFC2414) (Updates RFC2581) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3390) 3391 The MIME Application/Vnd.pwg-multiplexed Content-Type. R. Herriot. December 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3391) 3392 Capabilities Advertisement with BGP-4. R. Chandra, J. Scudder. November 2002. (Format: TXT, HTML) (Obsoletes RFC2842) (Obsoleted by RFC5492) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3392) 3393 IP Packet Delay Variation Metric for IP Performance Metrics (IPPM). C. Demichelis, P. Chimento. November 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3393) 3394 Advanced Encryption Standard (AES) Key Wrap Algorithm. J. Schaad, R. Housley. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3394) 3395 Remote Network Monitoring MIB Protocol Identifier Reference Extensions. A. Bierman, C. Bucci, R. Dietz, A. Warth. September 2002. (Format: TXT, HTML) (Updates RFC2895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3395) 3396 Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4). T. Lemon, S. Cheshire. November 2002. (Format: TXT, HTML) (Updates RFC2131) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3396) 3397 Dynamic Host Configuration Protocol (DHCP) Domain Search Option. B. Aboba, S. Cheshire. November 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3397) 3398 Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping. G. Camarillo, A. B. Roach, J. Peterson, L. Ong. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3398) 3399 Not Issued. 3400 Not Issued. 3401 Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS. M. Mealling. October 2002. (Format: TXT, HTML) (Obsoletes RFC2915, RFC2168) (Updates RFC2276) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3401) 3402 Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm. M. Mealling. October 2002. (Format: TXT, HTML) (Obsoletes RFC2915, RFC2168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3402) 3403 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database. M. Mealling. October 2002. (Format: TXT, HTML) (Obsoletes RFC2915, RFC2168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3403) 3404 Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI). M. Mealling. October 2002. (Format: TXT, HTML) (Obsoletes RFC2915, RFC2168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3404) 3405 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures. M. Mealling. October 2002. (Format: TXT, HTML) (Updated by RFC8958) (Also BCP0065) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3405) 3406 Uniform Resource Names (URN) Namespace Definition Mechanisms. L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. October 2002. (Format: TXT, HTML) (Obsoletes RFC2611) (Obsoleted by RFC8141) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3406) 3407 Session Description Protocol (SDP) Simple Capability Declaration. F. Andreasen. October 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3407) 3408 Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile. Z. Liu, K. Le. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3408) 3409 Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression. K. Svanbro. December 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3409) 3410 Introduction and Applicability Statements for Internet-Standard Management Framework. J. Case, R. Mundy, D. Partain, B. Stewart. December 2002. (Format: TXT, HTML) (Obsoletes RFC2570) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3410) 3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks. D. Harrington, R. Presuhn, B. Wijnen. December 2002. (Format: TXT, HTML) (Obsoletes RFC2571) (Updated by RFC5343, RFC5590) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3411) 3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. December 2002. (Format: TXT, HTML) (Obsoletes RFC2572) (Updated by RFC5590) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3412) 3413 Simple Network Management Protocol (SNMP) Applications. D. Levi, P. Meyer, B. Stewart. December 2002. (Format: TXT, HTML) (Obsoletes RFC2573) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3413) 3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. December 2002. (Format: TXT, HTML) (Obsoletes RFC2574) (Updated by RFC5590) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3414) 3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. December 2002. (Format: TXT, HTML) (Obsoletes RFC2575) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3415) 3416 Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP). R. Presuhn, Ed.. December 2002. (Format: TXT, HTML) (Obsoletes RFC1905) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3416) 3417 Transport Mappings for the Simple Network Management Protocol (SNMP). R. Presuhn, Ed.. December 2002. (Format: TXT, HTML) (Obsoletes RFC1906) (Updated by RFC4789, RFC5590) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3417) 3418 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP). R. Presuhn, Ed.. December 2002. (Format: TXT, HTML) (Obsoletes RFC1907) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3418) 3419 Textual Conventions for Transport Addresses. M. Daniele, J. Schoenwaelder. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3419) 3420 Internet Media Type message/sipfrag. R. Sparks. November 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3420) 3421 Select and Sort Extensions for the Service Location Protocol (SLP). W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome. November 2002. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3421) 3422 Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS). O. Okamoto, M. Maruyama, T. Sajima. November 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3422) 3423 XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0. K. Zhang, E. Elkin. November 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3423) 3424 IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation. L. Daigle, Ed., IAB. November 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3424) 3425 Obsoleting IQUERY. D. Lawrence. November 2002. (Format: TXT, HTML) (Updates RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3425) 3426 General Architectural and Policy Considerations. S. Floyd. November 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3426) 3427 Change Process for the Session Initiation Protocol (SIP). A. Mankin, S. Bradner, R. Mahy, D. Willis, J. Ott, B. Rosen. December 2002. (Format: TXT, HTML) (Obsoleted by RFC5727) (Updated by RFC3968, RFC3969) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3427) 3428 Session Initiation Protocol (SIP) Extension for Instant Messaging. B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle. December 2002. (Format: TXT, HTML) (Updated by RFC8591) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3428) 3429 Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions. H. Ohta. November 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3429) 3430 Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping. J. Schoenwaelder. December 2002. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3430) 3431 Sieve Extension: Relational Tests. W. Segmuller. December 2002. (Format: TXT, HTML) (Obsoleted by RFC5231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3431) 3432 Network performance measurement with periodic streams. V. Raisanen, G. Grotefeld, A. Morton. November 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3432) 3433 Entity Sensor Management Information Base. A. Bierman, D. Romascanu, K.C. Norseth. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3433) 3434 Remote Monitoring MIB Extensions for High Capacity Alarms. A. Bierman, K. McCloghrie. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3434) 3435 Media Gateway Control Protocol (MGCP) Version 1.0. F. Andreasen, B. Foster. January 2003. (Format: TXT, HTML) (Obsoletes RFC2705) (Updated by RFC3661) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3435) 3436 Transport Layer Security over Stream Control Transmission Protocol. A. Jungmaier, E. Rescorla, M. Tuexen. December 2002. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3436) 3437 Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation. W. Palter, W. Townsley. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3437) 3438 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update. W. Townsley. December 2002. (Format: TXT, HTML) (Also BCP0068) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3438) 3439 Some Internet Architectural Guidelines and Philosophy. R. Bush, D. Meyer. December 2002. (Format: TXT, HTML) (Updates RFC1958) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3439) 3440 Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines. F. Ly, G. Bathrick. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3440) 3441 Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP). R. Kumar. January 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3441) 3442 The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4. T. Lemon, S. Cheshire, B. Volz. December 2002. (Format: TXT, HTML) (Updates RFC2132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3442) 3443 Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks. P. Agarwal, B. Akyol. January 2003. (Format: TXT, HTML) (Updates RFC3032) (Updated by RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3443) 3444 On the Difference between Information Models and Data Models. A. Pras, J. Schoenwaelder. January 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3444) 3445 Limiting the Scope of the KEY Resource Record (RR). D. Massey, S. Rose. December 2002. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3445) 3446 Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP). D. Kim, D. Meyer, H. Kilmer, D. Farinacci. January 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3446) 3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1. J. Jonsson, B. Kaliski. February 2003. (Format: TXT, HTML) (Obsoletes RFC2437) (Obsoleted by RFC8017) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3447) 3448 TCP Friendly Rate Control (TFRC): Protocol Specification. M. Handley, S. Floyd, J. Padhye, J. Widmer. January 2003. (Format: TXT, HTML) (Obsoleted by RFC5348) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3448) 3449 TCP Performance Implications of Network Path Asymmetry. H. Balakrishnan, V. Padmanabhan, G. Fairhurst, M. Sooriyabandara. December 2002. (Format: TXT, HTML) (Also BCP0069) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3449) 3450 Asynchronous Layered Coding (ALC) Protocol Instantiation. M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft. December 2002. (Format: TXT, HTML) (Obsoleted by RFC5775) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3450) 3451 Layered Coding Transport (LCT) Building Block. M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, J. Crowcroft. December 2002. (Format: TXT, HTML) (Obsoleted by RFC5651) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3451) 3452 Forward Error Correction (FEC) Building Block. M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft. December 2002. (Format: TXT, HTML) (Obsoleted by RFC5052, RFC5445) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3452) 3453 The Use of Forward Error Correction (FEC) in Reliable Multicast. M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft. December 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3453) 3454 Preparation of Internationalized Strings ("stringprep"). P. Hoffman, M. Blanchet. December 2002. (Format: TXT, HTML) (Obsoleted by RFC7564) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3454) 3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP). M. Garcia-Martin, E. Henrikson, D. Mills. January 2003. (Format: TXT, HTML) (Obsoleted by RFC7315) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3455) 3456 Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode. B. Patel, B. Aboba, S. Kelly, V. Gupta. January 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3456) 3457 Requirements for IPsec Remote Access Scenarios. S. Kelly, S. Ramamoorthi. January 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3457) 3458 Message Context for Internet Mail. E. Burger, E. Candell, C. Eliot, G. Klyne. January 2003. (Format: TXT, HTML) (Updated by RFC3938) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3458) 3459 Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter. E. Burger. January 2003. (Format: TXT, HTML) (Updates RFC3204) (Updated by RFC5621) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3459) 3460 Policy Core Information Model (PCIM) Extensions. B. Moore, Ed.. January 2003. (Format: TXT, HTML) (Updates RFC3060) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3460) 3461 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs). K. Moore. January 2003. (Format: TXT, HTML) (Obsoletes RFC1891) (Updated by RFC3798, RFC3885, RFC5337, RFC6533, RFC8098) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3461) 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages. G. Vaudreuil. January 2003. (Format: TXT, HTML) (Obsoletes RFC1892) (Obsoleted by RFC6522) (Updated by RFC5337) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3462) 3463 Enhanced Mail System Status Codes. G. Vaudreuil. January 2003. (Format: TXT, HTML) (Obsoletes RFC1893) (Updated by RFC3886, RFC4468, RFC4865, RFC4954, RFC5248) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3463) 3464 An Extensible Message Format for Delivery Status Notifications. K. Moore, G. Vaudreuil. January 2003. (Format: TXT, HTML) (Obsoletes RFC1894) (Updated by RFC4865, RFC5337, RFC6533) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3464) 3465 TCP Congestion Control with Appropriate Byte Counting (ABC). M. Allman. February 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3465) 3466 A Model for Content Internetworking (CDI). M. Day, B. Cain, G. Tomlinson, P. Rzewski. February 2003. (Format: TXT, HTML) (Obsoleted by RFC7336) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3466) 3467 Role of the Domain Name System (DNS). J. Klensin. February 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3467) 3468 The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols. L. Andersson, G. Swallow. February 2003. (Format: TXT, HTML) (Updates RFC3212, RFC3472, RFC3475, RFC3476) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3468) 3469 Framework for Multi-Protocol Label Switching (MPLS)-based Recovery. V. Sharma, Ed., F. Hellstrand, Ed.. February 2003. (Format: TXT, HTML) (Updated by RFC5462) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3469) 3470 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols. S. Hollenbeck, M. Rose, L. Masinter. January 2003. (Format: TXT, HTML) (Updated by RFC8996) (Also BCP0070) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3470) 3471 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description. L. Berger, Ed.. January 2003. (Format: TXT, HTML) (Updated by RFC4201, RFC4328, RFC4872, RFC6002, RFC6003, RFC6205, RFC7074, RFC7699, RFC8359) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3471) 3472 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions. P. Ashwood-Smith, Ed., L. Berger, Ed.. January 2003. (Format: TXT, HTML) (Updated by RFC3468, RFC4201) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3472) 3473 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions. L. Berger, Ed.. January 2003. (Format: TXT, HTML) (Updated by RFC4003, RFC4201, RFC4420, RFC4783, RFC4874, RFC4873, RFC4974, RFC5063, RFC5151, RFC5420, RFC6002, RFC6003, RFC6780, RFC8359) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3473) 3474 Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON). Z. Lin, D. Pendarakis. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3474) 3475 Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON). O. Aboul-Magd. March 2003. (Format: TXT, HTML) (Updated by RFC3468) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3475) 3476 Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling. B. Rajagopalan. March 2003. (Format: TXT, HTML) (Updated by RFC3468) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3476) 3477 Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE). K. Kompella, Y. Rekhter. January 2003. (Format: TXT, HTML) (Updated by RFC6107) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3477) 3478 Graceful Restart Mechanism for Label Distribution Protocol. M. Leelanivas, Y. Rekhter, R. Aggarwal. February 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3478) 3479 Fault Tolerance for the Label Distribution Protocol (LDP). A. Farrel, Ed.. February 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3479) 3480 Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol). K. Kompella, Y. Rekhter, A. Kullberg. February 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3480) 3481 TCP over Second (2.5G) and Third (3G) Generation Wireless Networks. H. Inamura, Ed., G. Montenegro, Ed., R. Ludwig, A. Gurtov, F. Khafizov. February 2003. (Format: TXT, HTML) (Also BCP0071) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3481) 3482 Number Portability in the Global Switched Telephone Network (GSTN): An Overview. M. Foster, T. McGarry, J. Yu. February 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3482) 3483 Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR). D. Rawlins, A. Kulkarni, M. Bokaemper, K. Chan. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3483) 3484 Default Address Selection for Internet Protocol version 6 (IPv6). R. Draves. February 2003. (Format: TXT, HTML) (Obsoleted by RFC6724) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3484) 3485 The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp). M. Garcia-Martin, C. Bormann, J. Ott, R. Price, A. B. Roach. February 2003. (Format: TXT, HTML) (Updated by RFC4896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3485) 3486 Compressing the Session Initiation Protocol (SIP). G. Camarillo. February 2003. (Format: TXT, HTML) (Updated by RFC5049) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3486) 3487 Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP). H. Schulzrinne. February 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3487) 3488 Cisco Systems Router-port Group Management Protocol (RGMP). I. Wu, T. Eckert. February 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3488) 3489 STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs). J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy. March 2003. (Format: TXT, HTML) (Obsoleted by RFC5389) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3489) 3490 Internationalizing Domain Names in Applications (IDNA). P. Faltstrom, P. Hoffman, A. Costello. March 2003. (Format: TXT, HTML) (Obsoleted by RFC5890, RFC5891) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3490) 3491 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN). P. Hoffman, M. Blanchet. March 2003. (Format: TXT, HTML) (Obsoleted by RFC5891) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3491) 3492 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello. March 2003. (Format: TXT, HTML) (Updated by RFC5891) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3492) 3493 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. February 2003. (Format: TXT, HTML) (Obsoletes RFC2553) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3493) 3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status. K. Zeilenga. March 2003. (Format: TXT, HTML) (Obsoletes RFC1484, RFC1485, RFC1487, RFC1777, RFC1778, RFC1779, RFC1781, RFC2559) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3494) 3495 Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration. B. Beser, P. Duffy, Ed.. March 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3495) 3496 Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering. A. G. Malis, T. Hsiao. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3496) 3497 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video. L. Gharai, C. Perkins, G. Goncher, A. Mankin. March 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3497) 3498 Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures. J. Kuhfeld, J. Johnson, M. Thatcher. March 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3498) 3499 Request for Comments Summary RFC Numbers 3400-3499. S. Ginoza. December 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3499) 3500 Not Issued. 3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1. M. Crispin. March 2003. (Format: TXT, HTML) (Obsoletes RFC2060) (Obsoleted by RFC9051) (Updated by RFC4466, RFC4469, RFC4551, RFC5032, RFC5182, RFC5738, RFC6186, RFC6858, RFC7817, RFC8314, RFC8437, RFC8474, RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3501) 3502 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension. M. Crispin. March 2003. (Format: TXT, HTML) (Updated by RFC4466, RFC4469) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3502) 3503 Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP). A. Melnikov. March 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3503) 3504 Internet Open Trading Protocol (IOTP) Version 1, Errata. D. Eastlake. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3504) 3505 Electronic Commerce Modeling Language (ECML): Version 2 Requirements. D. Eastlake. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3505) 3506 Requirements and Design for Voucher Trading System (VTS). K. Fujimura, D. Eastlake. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3506) 3507 Internet Content Adaptation Protocol (ICAP). J. Elson, A. Cerpa. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3507) 3508 H.323 Uniform Resource Locator (URL) Scheme Registration. O. Levin. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3508) 3509 Alternative Implementations of OSPF Area Border Routers. A. Zinin, A. Lindem, D. Yeung. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3509) 3510 Internet Printing Protocol/1.1: IPP URL Scheme. R. Herriot, I. McDonald. April 2003. (Format: TXT, HTML) (Updates RFC2910) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3510) 3511 Benchmarking Methodology for Firewall Performance. B. Hickman, D. Newman, S. Tadjudin, T. Martin. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3511) 3512 Configuring Networks and Devices with Simple Network Management Protocol (SNMP). M. MacFaden, D. Partain, J. Saperia, W. Tackabury. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3512) 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture. R. Hinden, S. Deering. April 2003. (Format: TXT, HTML) (Obsoletes RFC2373) (Obsoleted by RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3513) 3514 The Security Flag in the IPv4 Header. S. Bellovin. 1 April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3514) 3515 The Session Initiation Protocol (SIP) Refer Method. R. Sparks. April 2003. (Format: TXT, HTML) (Updated by RFC7647, RFC8217) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3515) 3516 IMAP4 Binary Content Extension. L. Nerenberg. April 2003. (Format: TXT, HTML) (Updated by RFC4466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3516) 3517 A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP. E. Blanton, M. Allman, K. Fall, L. Wang. April 2003. (Format: TXT, HTML) (Obsoleted by RFC6675) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3517) 3518 Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP). M. Higashiyama, F. Baker, T. Liao. April 2003. (Format: TXT, HTML) (Obsoletes RFC2878) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3518) 3519 Mobile IP Traversal of Network Address Translation (NAT) Devices. H. Levkowetz, S. Vaarala. April 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3519) 3520 Session Authorization Policy Element. L-N. Hamer, B. Gage, B. Kosinski, H. Shieh. April 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3520) 3521 Framework for Session Set-up with Media Authorization. L-N. Hamer, B. Gage, H. Shieh. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3521) 3522 The Eifel Detection Algorithm for TCP. R. Ludwig, M. Meyer. April 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3522) 3523 Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology. J. Polk. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3523) 3524 Mapping of Media Streams to Resource Reservation Flows. G. Camarillo, A. Monrad. April 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3524) 3525 Gateway Control Protocol Version 1. C. Groves, Ed., M. Pantaleo, Ed., T. Anderson, Ed., T. Taylor, Ed.. June 2003. (Format: TXT, HTML) (Obsoletes RFC3015) (Obsoleted by RFC5125) (Status: HISTORIC) (DOI: 10.17487/RFC3525) 3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). T. Kivinen, M. Kojo. May 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3526) 3527 Link Selection sub-option for the Relay Agent Information Option for DHCPv4. K. Kinnear, M. Stapp, R. Johnson, J. Kumarasamy. April 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3527) 3528 Mesh-enhanced Service Location Protocol (mSLP). W. Zhao, H. Schulzrinne, E. Guttman. April 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3528) 3529 Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP). W. Harold. April 2003. (Format: TXT, HTML) (Updated by RFC8553) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3529) 3530 Network File System (NFS) version 4 Protocol. S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck. April 2003. (Format: TXT, HTML) (Obsoletes RFC3010) (Obsoleted by RFC7530) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3530) 3531 A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block. M. Blanchet. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3531) 3532 Requirements for the Dynamic Partitioning of Switching Elements. T. Anderson, J. Buerkle. May 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3532) 3533 The Ogg Encapsulation Format Version 0. S. Pfeiffer. May 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3533) 3534 The application/ogg Media Type. L. Walleij. May 2003. (Format: TXT, HTML) (Obsoleted by RFC5334) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3534) 3535 Overview of the 2002 IAB Network Management Workshop. J. Schoenwaelder. May 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3535) 3536 Terminology Used in Internationalization in the IETF. P. Hoffman. May 2003. (Format: TXT, HTML) (Obsoleted by RFC6365) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3536) 3537 Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key. J. Schaad, R. Housley. May 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3537) 3538 Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP). Y. Kawatsura. June 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3538) 3539 Authentication, Authorization and Accounting (AAA) Transport Profile. B. Aboba, J. Wood. June 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3539) 3540 Robust Explicit Congestion Notification (ECN) Signaling with Nonces. N. Spring, D. Wetherall, D. Ely. June 2003. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3540) 3541 A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D). A. Walsh. May 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3541) 3542 Advanced Sockets Application Program Interface (API) for IPv6. W. Stevens, M. Thomas, E. Nordmark, T. Jinmei. May 2003. (Format: TXT, HTML) (Obsoletes RFC2292) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3542) 3543 Registration Revocation in Mobile IPv4. S. Glass, M. Chandra. August 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3543) 3544 IP Header Compression over PPP. T. Koren, S. Casner, C. Bormann. July 2003. (Format: TXT, HTML) (Obsoletes RFC2509) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3544) 3545 Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering. T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3545) 3546 Transport Layer Security (TLS) Extensions. S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright. June 2003. (Format: TXT, HTML) (Obsoleted by RFC4366) (Updates RFC2246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3546) 3547 The Group Domain of Interpretation. M. Baugher, B. Weis, T. Hardjono, H. Harney. July 2003. (Format: TXT, HTML) (Obsoleted by RFC6407) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3547) 3548 The Base16, Base32, and Base64 Data Encodings. S. Josefsson, Ed.. July 2003. (Format: TXT, HTML) (Obsoleted by RFC4648) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3548) 3549 Linux Netlink as an IP Services Protocol. J. Salim, H. Khosravi, A. Kleen, A. Kuznetsov. July 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3549) 3550 RTP: A Transport Protocol for Real-Time Applications. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. July 2003. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1889) (Updated by RFC5506, RFC5761, RFC6051, RFC6222, RFC7022, RFC7160, RFC7164, RFC8083, RFC8108, RFC8860) (Also STD0064) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3550) 3551 RTP Profile for Audio and Video Conferences with Minimal Control. H. Schulzrinne, S. Casner. July 2003. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1890) (Updated by RFC5761, RFC7007, RFC8860) (Also STD0065) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3551) 3552 Guidelines for Writing RFC Text on Security Considerations. E. Rescorla, B. Korver. July 2003. (Format: TXT, HTML) (Updated by RFC8996) (Also BCP0072) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3552) 3553 An IETF URN Sub-namespace for Registered Protocol Parameters. M. Mealling, L. Masinter, T. Hardie, G. Klyne. June 2003. (Format: TXT, HTML) (Also BCP0073) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3553) 3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec. S. Bellovin, J. Ioannidis, A. Keromytis, R. Stewart. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3554) 3555 MIME Type Registration of RTP Payload Formats. S. Casner, P. Hoschka. July 2003. (Format: TXT, HTML) (Obsoleted by RFC4855, RFC4856) (Updated by RFC3625, RFC4629) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3555) 3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth. S. Casner. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3556) 3557 RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding. Q. Xie, Ed.. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3557) 3558 RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV). A. Li. July 2003. (Format: TXT, HTML) (Updated by RFC4788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3558) 3559 Multicast Address Allocation MIB. D. Thaler. June 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3559) 3560 Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS). R. Housley. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3560) 3561 Ad hoc On-Demand Distance Vector (AODV) Routing. C. Perkins, E. Belding-Royer, S. Das. July 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3561) 3562 Key Management Considerations for the TCP MD5 Signature Option. M. Leech. July 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3562) 3563 Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development. A. Zinin. July 2003. (Format: TXT, HTML) (Updated by RFC6233) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3563) 3564 Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering. F. Le Faucheur, W. Lai. July 2003. (Format: TXT, HTML) (Updated by RFC5462) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3564) 3565 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS). J. Schaad. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3565) 3566 The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec. S. Frankel, H. Herbert. September 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3566) 3567 Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication. T. Li, R. Atkinson. July 2003. (Format: TXT, HTML) (Obsoleted by RFC5304) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3567) 3568 Known Content Network (CN) Request-Routing Mechanisms. A. Barbir, B. Cain, R. Nair, O. Spatscheck. July 2003. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3568) 3569 An Overview of Source-Specific Multicast (SSM). S. Bhattacharyya, Ed.. July 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3569) 3570 Content Internetworking (CDI) Scenarios. P. Rzewski, M. Day, D. Gilletti. July 2003. (Format: TXT, HTML) (Obsoleted by RFC6770) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3570) 3571 Framework Policy Information Base for Usage Feedback. D. Rawlins, A. Kulkarni, K. Ho Chan, M. Bokaemper, D. Dutt. August 2003. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3571) 3572 Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH). T. Ogura, M. Maruyama, T. Yoshida. July 2003. (Format: TXT, HTML) (Updated by RFC8064) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3572) 3573 Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP). I. Goyret. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3573) 3574 Transition Scenarios for 3GPP Networks. J. Soininen, Ed.. August 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3574) 3575 IANA Considerations for RADIUS (Remote Authentication Dial In User Service). B. Aboba. July 2003. (Format: TXT, HTML) (Updates RFC2865, RFC2868) (Updated by RFC6929) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3575) 3576 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS). M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba. July 2003. (Format: TXT, HTML) (Obsoleted by RFC5176) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3576) 3577 Introduction to the Remote Monitoring (RMON) Family of MIB Modules. S. Waldbusser, R. Cole, C. Kalbfleisch, D. Romascanu. August 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3577) 3578 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP). G. Camarillo, A. B. Roach, J. Peterson, L. Ong. August 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3578) 3579 RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP). B. Aboba, P. Calhoun. September 2003. (Format: TXT, HTML) (Updates RFC2869) (Updated by RFC5080) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3579) 3580 IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines. P. Congdon, B. Aboba, A. Smith, G. Zorn, J. Roese. September 2003. (Format: TXT, HTML) (Updated by RFC7268) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3580) 3581 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing. J. Rosenberg, H. Schulzrinne. August 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3581) 3582 Goals for IPv6 Site-Multihoming Architectures. J. Abley, B. Black, V. Gill. August 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3582) 3583 Requirements of a Quality of Service (QoS) Solution for Mobile IP. H. Chaskar, Ed.. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3583) 3584 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework. R. Frye, D. Levi, S. Routhier, B. Wijnen. August 2003. (Format: TXT, HTML) (Obsoletes RFC2576) (Also BCP0074) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3584) 3585 IPsec Configuration Policy Information Model. J. Jason, L. Rafalow, E. Vyncke. August 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3585) 3586 IP Security Policy (IPSP) Requirements. M. Blaze, A. Keromytis, M. Richardson, L. Sanchez. August 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3586) 3587 IPv6 Global Unicast Address Format. R. Hinden, S. Deering, E. Nordmark. August 2003. (Format: TXT, HTML) (Obsoletes RFC2374) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3587) 3588 Diameter Base Protocol. P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko. September 2003. (Format: TXT, HTML) (Obsoleted by RFC6733) (Updated by RFC5729, RFC5719, RFC6408) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3588) 3589 Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5. J. Loughney. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3589) 3590 Source Address Selection for the Multicast Listener Discovery (MLD) Protocol. B. Haberman. September 2003. (Format: TXT, HTML) (Updates RFC2710) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3590) 3591 Definitions of Managed Objects for the Optical Interface Type. H-K. Lam, M. Stewart, A. Huynh. September 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3591) 3592 Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type. K. Tesink. September 2003. (Format: TXT, HTML) (Obsoletes RFC2558) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3592) 3593 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals. K. Tesink, Ed.. September 2003. (Format: TXT, HTML) (Obsoletes RFC2493) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3593) 3594 PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option. P. Duffy. September 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3594) 3595 Textual Conventions for IPv6 Flow Label. B. Wijnen. September 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3595) 3596 DNS Extensions to Support IP Version 6. S. Thomson, C. Huitema, V. Ksinant, M. Souissi. October 2003. (Format: TXT, HTML) (Obsoletes RFC3152, RFC1886) (Also STD0088) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3596) 3597 Handling of Unknown DNS Resource Record (RR) Types. A. Gustafsson. September 2003. (Format: TXT, HTML) (Updates RFC2163, RFC2535) (Updated by RFC4033, RFC4034, RFC4035, RFC5395, RFC6195, RFC6895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3597) 3598 Sieve Email Filtering -- Subaddress Extension. K. Murchison. September 2003. (Format: TXT, HTML) (Obsoleted by RFC5233) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3598) 3599 Request for Comments Summary RFC Numbers 3500-3599. S. Ginoza. December 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3599) 3600 Internet Official Protocol Standards. J. Reynolds, Ed., S. Ginoza, Ed.. November 2003. (Format: TXT, HTML) (Obsoletes RFC3300) (Obsoleted by RFC3700) (Status: HISTORIC) (DOI: 10.17487/RFC3600) 3601 Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses. C. Allocchio. September 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3601) 3602 The AES-CBC Cipher Algorithm and Its Use with IPsec. S. Frankel, R. Glenn, S. Kelly. September 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3602) 3603 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture. W. Marshall, Ed., F. Andreasen, Ed.. October 2003. (Format: TXT, HTML) (Obsoleted by RFC5503) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3603) 3604 Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3). H. Khosravi, G. Kullgren, S. Shew, J. Sadler, A. Watanabe. October 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3604) 3605 Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP). C. Huitema. October 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3605) 3606 Definitions of Supplemental Managed Objects for ATM Interface. F. Ly, M. Noto, A. Smith, E. Spiegel, K. Tesink. November 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3606) 3607 Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool. M. Leech. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3607) 3608 Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration. D. Willis, B. Hoeneisen. October 2003. (Format: TXT, HTML) (Updated by RFC5630) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3608) 3609 Tracing Requirements for Generic Tunnels. R. Bonica, K. Kompella, D. Meyer. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3609) 3610 Counter with CBC-MAC (CCM). D. Whiting, R. Housley, N. Ferguson. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3610) 3611 RTP Control Protocol Extended Reports (RTCP XR). T. Friedman, Ed., R. Caceres, Ed., A. Clark, Ed.. November 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3611) 3612 Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP). A. Farrel. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3612) 3613 Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE). R. Morgan, K. Hazelton. October 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3613) 3614 A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG). J. Smith. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3614) 3615 A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging. J. Gustin, A. Goyens. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3615) 3616 A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA). F. Bellifemine, I. Constantinescu, S. Willmott. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3616) 3617 Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP). E. Lear. October 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3617) 3618 Multicast Source Discovery Protocol (MSDP). B. Fenner, Ed., D. Meyer, Ed.. October 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3618) 3619 Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1. S. Shah, M. Yip. October 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3619) 3620 The TUNNEL Profile. D. New. October 2003. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3620) 3621 Power Ethernet MIB. A. Berger, D. Romascanu. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3621) 3622 A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project. M. Mealling. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3622) 3623 Graceful OSPF Restart. J. Moy, P. Pillay-Esnault, A. Lindem. November 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3623) 3624 The Media Gateway Control Protocol (MGCP) Bulk Audit Package. B. Foster, D. Auerbach, F. Andreasen. November 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3624) 3625 The QCP File Format and Media Types for Speech Data. R. Gellens, H. Garudadri. September 2003. (Format: TXT, HTML) (Updates RFC3555) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3625) 3626 Optimized Link State Routing Protocol (OLSR). T. Clausen, Ed., P. Jacquet, Ed.. October 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3626) 3627 Use of /127 Prefix Length Between Routers Considered Harmful. P. Savola. September 2003. (Format: TXT, HTML) (Obsoleted by RFC6547) (Status: HISTORIC) (DOI: 10.17487/RFC3627) 3628 Policy Requirements for Time-Stamping Authorities (TSAs). D. Pinkas, N. Pope, J. Ross. November 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3628) 3629 UTF-8, a transformation format of ISO 10646. F. Yergeau. November 2003. (Format: TXT, HTML) (Obsoletes RFC2279) (Also STD0063) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3629) 3630 Traffic Engineering (TE) Extensions to OSPF Version 2. D. Katz, K. Kompella, D. Yeung. September 2003. (Format: TXT, HTML) (Updates RFC2370) (Updated by RFC4203, RFC5786) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3630) 3631 Security Mechanisms for the Internet. S. Bellovin, Ed., J. Schiller, Ed., C. Kaufman, Ed.. December 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3631) 3632 VeriSign Registry Registrar Protocol (RRP) Version 2.0.0. S. Hollenbeck, S. Veeramachaneni, S. Yalamanchilli. November 2003. (Format: TXT, HTML) (Updates RFC2832) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3632) 3633 IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6. O. Troan, R. Droms. December 2003. (Format: TXT, HTML) (Obsoleted by RFC8415) (Updated by RFC6603, RFC7550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3633) 3634 Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option. K. Luehrs, R. Woundy, J. Bevilacqua, N. Davoust. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3634) 3635 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Flick. September 2003. (Format: TXT, HTML) (Obsoletes RFC2665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3635) 3636 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs). J. Flick. September 2003. (Format: TXT, HTML) (Obsoletes RFC2668, RFC1515) (Obsoleted by RFC4836) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3636) 3637 Definitions of Managed Objects for the Ethernet WAN Interface Sublayer. C.M. Heard, Ed.. September 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3637) 3638 Applicability Statement for Reclassification of RFC 1643 to Historic Status. J. Flick, C. M. Heard. September 2003. (Format: TXT, HTML) (Obsoletes RFC1643) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3638) 3639 Considerations on the use of a Service Identifier in Packet Headers. M. St. Johns, Ed., G. Huston, Ed., IAB. October 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3639) 3640 RTP Payload Format for Transport of MPEG-4 Elementary Streams. J. van der Meer, D. Mackie, V. Swaminathan, D. Singer, P. Gentric. November 2003. (Format: TXT, HTML) (Updated by RFC5691) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3640) 3641 Generic String Encoding Rules (GSER) for ASN.1 Types. S. Legg. October 2003. (Format: TXT, HTML) (Updated by RFC4792) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3641) 3642 Common Elements of Generic String Encoding Rules (GSER) Encodings. S. Legg. October 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3642) 3643 Fibre Channel (FC) Frame Encapsulation. R. Weber, M. Rajagopal, F. Travostino, M. O'Donnell, C. Monia, M. Merhar. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3643) 3644 Policy Quality of Service (QoS) Information Model. Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, B. Moore. November 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3644) 3645 Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG). S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, R. Hall. October 2003. (Format: TXT, HTML) (Updates RFC2845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3645) 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms, Ed.. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3646) 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. S. Chokhani, W. Ford, R. Sabett, C. Merrill, S. Wu. November 2003. (Format: TXT, HTML) (Obsoletes RFC2527) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3647) 3648 Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol. J. Whitehead, J. Reschke, Ed.. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3648) 3649 HighSpeed TCP for Large Congestion Windows. S. Floyd. December 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3649) 3650 Handle System Overview. S. Sun, L. Lannom, B. Boesch. November 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3650) 3651 Handle System Namespace and Service Definition. S. Sun, S. Reilly, L. Lannom. November 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3651) 3652 Handle System Protocol (ver 2.1) Specification. S. Sun, S. Reilly, L. Lannom, J. Petrone. November 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3652) 3653 XML-Signature XPath Filter 2.0. J. Boyer, M. Hughes, J. Reagle. December 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3653) 3654 Requirements for Separation of IP Control and Forwarding. H. Khosravi, Ed., T. Anderson, Ed.. November 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3654) 3655 Redefinition of DNS Authenticated Data (AD) bit. B. Wellington, O. Gudmundsson. November 2003. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3655) 3656 The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol. R. Siemborski. December 2003. (Format: TXT, HTML) (Updated by RFC8996) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3656) 3657 Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS). S. Moriai, A. Kato. January 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3657) 3658 Delegation Signer (DS) Resource Record (RR). O. Gudmundsson. December 2003. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC3090, RFC3008, RFC2535, RFC1035) (Updated by RFC3755) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3658) 3659 Extensions to FTP. P. Hethmon. March 2007. (Format: TXT, HTML) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3659) 3660 Basic Media Gateway Control Protocol (MGCP) Packages. B. Foster, F. Andreasen. December 2003. (Format: TXT, HTML) (Updates RFC2705) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3660) 3661 Media Gateway Control Protocol (MGCP) Return Code Usage. B. Foster, C. Sivachelvan. December 2003. (Format: TXT, HTML) (Updates RFC3435) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3661) 3662 A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services. R. Bless, K. Nichols, K. Wehrle. December 2003. (Format: TXT, HTML) (Obsoleted by RFC8622) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3662) 3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP). A. Newton. December 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3663) 3664 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE). P. Hoffman. January 2004. (Format: TXT, HTML) (Obsoleted by RFC4434) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3664) 3665 Session Initiation Protocol (SIP) Basic Call Flow Examples. A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. December 2003. (Format: TXT, HTML) (Also BCP0075) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3665) 3666 Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows. A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. December 2003. (Format: TXT, HTML) (Also BCP0076) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3666) 3667 IETF Rights in Contributions. S. Bradner. February 2004. (Format: TXT, HTML) (Obsoleted by RFC3978) (Updates RFC2026) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3667) 3668 Intellectual Property Rights in IETF Technology. S. Bradner. February 2004. (Format: TXT, HTML) (Obsoleted by RFC3979) (Updates RFC2026, RFC2028) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3668) 3669 Guidelines for Working Groups on Intellectual Property Issues. S. Brim. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3669) 3670 Information Model for Describing Network Device QoS Datapath Mechanisms. B. Moore, D. Durham, J. Strassner, A. Westerinen, W. Weiss. January 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3670) 3671 Collective Attributes in the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3671) 3672 Subentries in the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3672) 3673 Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes. K. Zeilenga. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3673) 3674 Feature Discovery in Lightweight Directory Access Protocol (LDAP). K. Zeilenga. December 2003. (Format: TXT, HTML) (Obsoleted by RFC4512) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3674) 3675 .sex Considered Dangerous. D. Eastlake 3rd. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3675) 3676 The Text/Plain Format and DelSp Parameters. R. Gellens. February 2004. (Format: TXT, HTML) (Obsoletes RFC2646) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3676) 3677 IETF ISOC Board of Trustee Appointment Procedures. L. Daigle, Ed., Internet Architecture Board. December 2003. (Format: TXT, HTML) (Also BCP0077) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3677) 3678 Socket Interface Extensions for Multicast Source Filters. D. Thaler, B. Fenner, B. Quinn. January 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3678) 3679 Unused Dynamic Host Configuration Protocol (DHCP) Option Codes. R. Droms. January 2004. (Format: TXT, HTML) (Updated by RFC8910) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3679) 3680 A Session Initiation Protocol (SIP) Event Package for Registrations. J. Rosenberg. March 2004. (Format: TXT, HTML) (Updated by RFC6140) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3680) 3681 Delegation of E.F.F.3.IP6.ARPA. R. Bush, R. Fink. January 2004. (Format: TXT, HTML) (Also BCP0080) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3681) 3682 The Generalized TTL Security Mechanism (GTSM). V. Gill, J. Heasley, D. Meyer. February 2004. (Format: TXT, HTML) (Obsoleted by RFC5082) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3682) 3683 A Practice for Revoking Posting Rights to IETF Mailing Lists. M. Rose. March 2004. (Format: TXT, HTML) (Updated by RFC9245) (Also BCP0083) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3683) 3684 Topology Dissemination Based on Reverse-Path Forwarding (TBRPF). R. Ogier, F. Templin, M. Lewis. February 2004. (Format: TXT, HTML) (Updated by RFC9141) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3684) 3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions. C. Daboo. February 2004. (Format: TXT, HTML) (Obsoleted by RFC5235) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3685) 3686 Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP). R. Housley. January 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3686) 3687 Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules. S. Legg. February 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3687) 3688 The IETF XML Registry. M. Mealling. January 2004. (Format: TXT, HTML) (Also BCP0081) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3688) 3689 General Requirements for Emergency Telecommunication Service (ETS). K. Carlberg, R. Atkinson. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3689) 3690 IP Telephony Requirements for Emergency Telecommunication Service (ETS). K. Carlberg, R. Atkinson. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3690) 3691 Internet Message Access Protocol (IMAP) UNSELECT command. A. Melnikov. February 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3691) 3692 Assigning Experimental and Testing Numbers Considered Useful. T. Narten. January 2004. (Format: TXT, HTML) (Updates RFC2434) (Also BCP0082) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3692) 3693 Geopriv Requirements. J. Cuellar, J. Morris, D. Mulligan, J. Peterson, J. Polk. February 2004. (Format: TXT, HTML) (Updated by RFC6280, RFC7459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3693) 3694 Threat Analysis of the Geopriv Protocol. M. Danley, D. Mulligan, J. Morris, J. Peterson. February 2004. (Format: TXT, HTML) (Updated by RFC6280) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3694) 3695 Compact Forward Error Correction (FEC) Schemes. M. Luby, L. Vicisano. February 2004. (Format: TXT, HTML) (Obsoleted by RFC5445) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3695) 3696 Application Techniques for Checking and Transformation of Names. J. Klensin. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3696) 3697 IPv6 Flow Label Specification. J. Rajahalme, A. Conta, B. Carpenter, S. Deering. March 2004. (Format: TXT, HTML) (Obsoleted by RFC6437) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3697) 3698 Lightweight Directory Access Protocol (LDAP): Additional Matching Rules. K. Zeilenga, Ed.. February 2004. (Format: TXT, HTML) (Updates RFC2798) (Updated by RFC4517) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3698) 3699 Not Issued. 3700 Internet Official Protocol Standards. J. Reynolds, Ed., S. Ginoza, Ed.. July 2004. (Format: TXT, HTML) (Obsoletes RFC3600) (Obsoleted by RFC5000) (Status: HISTORIC) (DOI: 10.17487/RFC3700) 3701 6bone (IPv6 Testing Address Allocation) Phaseout. R. Fink, R. Hinden. March 2004. (Format: TXT, HTML) (Obsoletes RFC2471) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3701) 3702 Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP). J. Loughney, G. Camarillo. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3702) 3703 Policy Core Lightweight Directory Access Protocol (LDAP) Schema. J. Strassner, B. Moore, R. Moats, E. Ellesson. February 2004. (Format: TXT, HTML) (Updated by RFC4104) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3703) 3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola. March 2004. (Format: TXT, HTML) (Updates RFC2827) (Updated by RFC8704) (Also BCP0084) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3704) 3705 High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals. B. Ray, R. Abbi. February 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3705) 3706 A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers. G. Huang, S. Beaulieu, D. Rochefort. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3706) 3707 Cross Registry Internet Service Protocol (CRISP) Requirements. A. Newton. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3707) 3708 Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions. E. Blanton, M. Allman. February 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3708) 3709 Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates. S. Santesson, R. Housley, T. Freeman. February 2004. (Format: TXT, HTML) (Updated by RFC6170) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3709) 3710 An IESG charter. H. Alvestrand. February 2004. (Format: TXT, HTML) (Updated by RFC3932, RFC5742, RFC8717) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3710) 3711 The Secure Real-time Transport Protocol (SRTP). M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman. March 2004. (Format: TXT, HTML) (Updated by RFC5506, RFC6904) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3711) 3712 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services. P. Fleming, I. McDonald. February 2004. (Format: TXT, HTML) (Obsoleted by RFC7612) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3712) 3713 A Description of the Camellia Encryption Algorithm. M. Matsui, J. Nakajima, S. Moriai. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3713) 3714 IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet. S. Floyd, Ed., J. Kempf, Ed.. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3714) 3715 IPsec-Network Address Translation (NAT) Compatibility Requirements. B. Aboba, W. Dixon. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3715) 3716 IETF in the Large: Administration and Execution. IAB Advisory Committee. March 2004. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3716) 3717 IP over Optical Networks: A Framework. B. Rajagopalan, J. Luciani, D. Awduche. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3717) 3718 A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access. R. McGowan. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3718) 3719 Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS). J. Parker, Ed.. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3719) 3720 Internet Small Computer Systems Interface (iSCSI). J. Satran, K. Meth, C. Sapuntzakis, M. Chadalapaka, E. Zeidner. April 2004. (Format: TXT, HTML) (Obsoleted by RFC7143) (Updated by RFC3980, RFC4850, RFC5048, RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3720) 3721 Internet Small Computer Systems Interface (iSCSI) Naming and Discovery. M. Bakke, J. Hafner, J. Hufferd, K. Voruganti, M. Krueger. April 2004. (Format: TXT, HTML) (Updated by RFC7143) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3721) 3722 String Profile for Internet Small Computer Systems Interface (iSCSI) Names. M. Bakke. April 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3722) 3723 Securing Block Storage Protocols over IP. B. Aboba, J. Tseng, J. Walker, V. Rangan, F. Travostino. April 2004. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3723) 3724 The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture. J. Kempf, Ed., R. Austein, Ed., IAB. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3724) 3725 Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP). J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo. April 2004. (Format: TXT, HTML) (Also BCP0085) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3725) 3726 Requirements for Signaling Protocols. M. Brunner, Ed.. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3726) 3727 ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules. S. Legg. February 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3727) 3728 Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL). B. Ray, R. Abbi. February 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3728) 3729 Application Performance Measurement MIB. S. Waldbusser. March 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3729) 3730 Extensible Provisioning Protocol (EPP). S. Hollenbeck. March 2004. (Format: TXT, HTML) (Obsoleted by RFC4930) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3730) 3731 Extensible Provisioning Protocol (EPP) Domain Name Mapping. S. Hollenbeck. March 2004. (Format: TXT, HTML) (Obsoleted by RFC4931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3731) 3732 Extensible Provisioning Protocol (EPP) Host Mapping. S. Hollenbeck. March 2004. (Format: TXT, HTML) (Obsoleted by RFC4932) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3732) 3733 Extensible Provisioning Protocol (EPP) Contact Mapping. S. Hollenbeck. March 2004. (Format: TXT, HTML) (Obsoleted by RFC4933) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3733) 3734 Extensible Provisioning Protocol (EPP) Transport Over TCP. S. Hollenbeck. March 2004. (Format: TXT, HTML) (Obsoleted by RFC4934) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3734) 3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP). S. Hollenbeck. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3735) 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6. R. Droms. April 2004. (Format: TXT, HTML) (Obsoleted by RFC8415) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3736) 3737 IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules. B. Wijnen, A. Bierman. April 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3737) 3738 Wave and Equation Based Rate Control (WEBRC) Building Block. M. Luby, V. Goyal. April 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3738) 3739 Internet X.509 Public Key Infrastructure: Qualified Certificates Profile. S. Santesson, M. Nystrom, T. Polk. March 2004. (Format: TXT, HTML) (Obsoletes RFC3039) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3739) 3740 The Multicast Group Security Architecture. T. Hardjono, B. Weis. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3740) 3741 Exclusive XML Canonicalization, Version 1.0. J. Boyer, D. Eastlake 3rd, J. Reagle. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3741) 3742 Limited Slow-Start for TCP with Large Congestion Windows. S. Floyd. March 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3742) 3743 Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean. K. Konishi, K. Huang, H. Qian, Y. Ko. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3743) 3744 Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol. G. Clemm, J. Reschke, E. Sedlar, J. Whitehead. May 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3744) 3745 MIME Type Registrations for JPEG 2000 (ISO/IEC 15444). D. Singer, R. Clark, D. Lee. April 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3745) 3746 Forwarding and Control Element Separation (ForCES) Framework. L. Yang, R. Dantu, T. Anderson, R. Gopal. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3746) 3747 The Differentiated Services Configuration MIB. H. Hazewinkel, Ed., D. Partain, Ed.. April 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3747) 3748 Extensible Authentication Protocol (EAP). B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, Ed.. June 2004. (Format: TXT, HTML) (Obsoletes RFC2284) (Updated by RFC5247, RFC7057) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3748) 3749 Transport Layer Security Protocol Compression Methods. S. Hollenbeck. May 2004. (Format: TXT, HTML) (Updated by RFC8447, RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3749) 3750 Unmanaged Networks IPv6 Transition Scenarios. C. Huitema, R. Austein, S. Satapati, R. van der Pol. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3750) 3751 Omniscience Protocol Requirements. S. Bradner. 1 April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3751) 3752 Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios. A. Barbir, E. Burger, R. Chen, S. McHenry, H. Orman, R. Penno. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3752) 3753 Mobility Related Terminology. J. Manner, Ed., M. Kojo, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3753) 3754 IP Multicast in Differentiated Services (DS) Networks. R. Bless, K. Wehrle. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3754) 3755 Legacy Resolver Compatibility for Delegation Signer (DS). S. Weiler. May 2004. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC3658, RFC2535) (Updated by RFC3757, RFC3845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3755) 3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats. P. Nikander, Ed., J. Kempf, E. Nordmark. May 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3756) 3757 Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag. O. Kolkman, J. Schlyter, E. Lewis. April 2004. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC3755, RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3757) 3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension. R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad. May 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3758) 3759 RObust Header Compression (ROHC): Terminology and Channel Mapping Examples. L-E. Jonsson. April 2004. (Format: TXT, HTML) (Updates RFC3095) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3759) 3760 Securely Available Credentials (SACRED) - Credential Server Framework. D. Gustafson, M. Just, M. Nystrom. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3760) 3761 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM). P. Faltstrom, M. Mealling. April 2004. (Format: TXT, HTML) (Obsoletes RFC2916) (Obsoleted by RFC6116, RFC6117) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3761) 3762 Telephone Number Mapping (ENUM) Service Registration for H.323. O. Levin. April 2004. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3762) 3763 One-way Active Measurement Protocol (OWAMP) Requirements. S. Shalunov, B. Teitelbaum. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3763) 3764 enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record. J. Peterson. April 2004. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3764) 3765 NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control. G. Huston. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3765) 3766 Determining Strengths For Public Keys Used For Exchanging Symmetric Keys. H. Orman, P. Hoffman. April 2004. (Format: TXT, HTML) (Also BCP0086) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3766) 3767 Securely Available Credentials Protocol. S. Farrell, Ed.. June 2004. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3767) 3768 Virtual Router Redundancy Protocol (VRRP). R. Hinden, Ed.. April 2004. (Format: TXT, HTML) (Obsoletes RFC2338) (Obsoleted by RFC5798) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3768) 3769 Requirements for IPv6 Prefix Delegation. S. Miyakawa, R. Droms. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3769) 3770 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN). R. Housley, T. Moore. May 2004. (Format: TXT, HTML) (Obsoleted by RFC4334) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3770) 3771 The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message. R. Harrison, K. Zeilenga. April 2004. (Format: TXT, HTML) (Obsoleted by RFC4511, RFC4510) (Updates RFC2251) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3771) 3772 Point-to-Point Protocol (PPP) Vendor Protocol. J. Carlson, R. Winslow. May 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3772) 3773 High-Level Requirements for Internet Voice Mail. E. Candell. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3773) 3774 IETF Problem Statement. E. Davies, Ed.. May 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3774) 3775 Mobility Support in IPv6. D. Johnson, C. Perkins, J. Arkko. June 2004. (Format: TXT, HTML) (Obsoleted by RFC6275) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3775) 3776 Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents. J. Arkko, V. Devarapalli, F. Dupont. June 2004. (Format: TXT, HTML) (Updated by RFC4877) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3776) 3777 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. J. Galvin, Ed.. June 2004. (Format: TXT, HTML) (Obsoletes RFC2727) (Obsoleted by RFC7437) (Updated by RFC5078, RFC5633, RFC5680, RFC6859) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3777) 3778 The application/pdf Media Type. E. Taft, J. Pravetz, S. Zilles, L. Masinter. May 2004. (Format: TXT, HTML) (Obsoleted by RFC8118) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3778) 3779 X.509 Extensions for IP Addresses and AS Identifiers. C. Lynn, S. Kent, K. Seo. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3779) 3780 SMIng - Next Generation Structure of Management Information. F. Strauss, J. Schoenwaelder. May 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3780) 3781 Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP). F. Strauss, J. Schoenwaelder. May 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3781) 3782 The NewReno Modification to TCP's Fast Recovery Algorithm. S. Floyd, T. Henderson, A. Gurtov. April 2004. (Format: TXT, HTML) (Obsoletes RFC2582) (Obsoleted by RFC6582) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3782) 3783 Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI. M. Chadalapaka, R. Elliott. May 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3783) 3784 Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE). H. Smit, T. Li. June 2004. (Format: TXT, HTML) (Obsoleted by RFC5305) (Updated by RFC4205) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3784) 3785 Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric. F. Le Faucheur, R. Uppili, A. Vedrenne, P. Merckx, T. Telkamp. May 2004. (Format: TXT, HTML) (Also BCP0087) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3785) 3786 Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit. A. Hermelin, S. Previdi, M. Shand. May 2004. (Format: TXT, HTML) (Obsoleted by RFC5311) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3786) 3787 Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS). J. Parker, Ed.. May 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3787) 3788 Security Considerations for Signaling Transport (SIGTRAN) Protocols. J. Loughney, M. Tuexen, Ed., J. Pastor-Balbas. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3788) 3789 Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3789) 3790 Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents. C. Mickles, Ed., P. Nesser, II. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3790) 3791 Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents. C. Olvera, P. Nesser, II. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3791) 3792 Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3792) 3793 Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3793) 3794 Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3794) 3795 Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents. R. Sofia, P. Nesser, II. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3795) 3796 Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3796) 3797 Publicly Verifiable Nominations Committee (NomCom) Random Selection. D. Eastlake 3rd. June 2004. (Format: TXT, HTML) (Obsoletes RFC2777) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3797) 3798 Message Disposition Notification. T. Hansen, Ed., G. Vaudreuil, Ed.. May 2004. (Format: TXT, HTML) (Obsoletes RFC2298) (Obsoleted by RFC8098) (Updates RFC3461, RFC2046) (Updated by RFC5337, RFC6533) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3798) 3799 Not Issued. 3800 Not Issued. 3801 Voice Profile for Internet Mail - version 2 (VPIMv2). G. Vaudreuil, G. Parsons. June 2004. (Format: TXT, HTML) (Obsoletes RFC2421, RFC2423) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3801) 3802 Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration. G. Vaudreuil, G. Parsons. June 2004. (Format: TXT, HTML) (Obsoletes RFC2422) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3802) 3803 Content Duration MIME Header Definition. G. Vaudreuil, G. Parsons. June 2004. (Format: TXT, HTML) (Obsoletes RFC2424) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3803) 3804 Voice Profile for Internet Mail (VPIM) Addressing. G. Parsons. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3804) 3805 Printer MIB v2. R. Bergman, H. Lewis, I. McDonald. June 2004. (Format: TXT, HTML) (Obsoletes RFC1759) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3805) 3806 Printer Finishing MIB. R. Bergman, H. Lewis, I. McDonald. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3806) 3807 V5.2-User Adaptation Layer (V5UA). E. Weilandt, N. Khanchandani, S. Rao. June 2004. (Format: TXT, HTML) (Updates RFC3057) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3807) 3808 IANA Charset MIB. I. McDonald. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3808) 3809 Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN). A. Nagarajan, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3809) 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6. R. Vida, Ed., L. Costa, Ed.. June 2004. (Format: TXT, HTML) (Updates RFC2710) (Updated by RFC4604) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3810) 3811 Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management. T. Nadeau, Ed., J. Cucchiara, Ed.. June 2004. (Format: TXT, HTML) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3811) 3812 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB). C. Srinivasan, A. Viswanathan, T. Nadeau. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3812) 3813 Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB). C. Srinivasan, A. Viswanathan, T. Nadeau. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3813) 3814 Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB). T. Nadeau, C. Srinivasan, A. Viswanathan. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3814) 3815 Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP). J. Cucchiara, H. Sjostrand, J. Luciani. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3815) 3816 Definitions of Managed Objects for RObust Header Compression (ROHC). J. Quittek, M. Stiemerling, H. Hartenstein. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3816) 3817 Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE). W. Townsley, R. da Silva. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3817) 3818 IANA Considerations for the Point-to-Point Protocol (PPP). V. Schryver. June 2004. (Format: TXT, HTML) (Also BCP0088) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3818) 3819 Advice for Internet Subnetwork Designers. P. Karn, Ed., C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood. July 2004. (Format: TXT, HTML) (Also BCP0089) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3819) 3820 Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile. S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3820) 3821 Fibre Channel Over TCP/IP (FCIP). M. Rajagopal, E. Rodriguez, R. Weber. July 2004. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3821) 3822 Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2). D. Peterson. July 2004. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3822) 3823 MIME Media Type for the Systems Biology Markup Language (SBML). B. Kovitz. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3823) 3824 Using E.164 numbers with the Session Initiation Protocol (SIP). J. Peterson, H. Liu, J. Yu, B. Campbell. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3824) 3825 Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information. J. Polk, J. Schnizlein, M. Linsner. July 2004. (Format: TXT, HTML) (Obsoleted by RFC6225) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3825) 3826 The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model. U. Blumenthal, F. Maino, K. McCloghrie. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3826) 3827 Additional Snoop Datalink Types. K. Sarcar. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3827) 3828 The Lightweight User Datagram Protocol (UDP-Lite). L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson, Ed., G. Fairhurst, Ed.. July 2004. (Format: TXT, HTML) (Updated by RFC6335) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3828) 3829 Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls. R. Weltman, M. Smith, M. Wahl. July 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3829) 3830 MIKEY: Multimedia Internet KEYing. J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman. August 2004. (Format: TXT, HTML) (Updated by RFC4738, RFC6309) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3830) 3831 Transmission of IPv6 Packets over Fibre Channel. C. DeSanti. July 2004. (Format: TXT, HTML) (Obsoleted by RFC4338) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3831) 3832 Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV. W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome. July 2004. (Format: TXT, HTML) (Updated by RFC8553) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3832) 3833 Threat Analysis of the Domain Name System (DNS). D. Atkins, R. Austein. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3833) 3834 Recommendations for Automatic Responses to Electronic Mail. K. Moore. August 2004. (Format: TXT, HTML) (Updated by RFC5436) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3834) 3835 An Architecture for Open Pluggable Edge Services (OPES). A. Barbir, R. Penno, R. Chen, M. Hofmann, H. Orman. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3835) 3836 Requirements for Open Pluggable Edge Services (OPES) Callout Protocols. A. Beck, M. Hofmann, H. Orman, R. Penno, A. Terzis. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3836) 3837 Security Threats and Risks for Open Pluggable Edge Services (OPES). A. Barbir, O. Batuner, B. Srinivas, M. Hofmann, H. Orman. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3837) 3838 Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES). A. Barbir, O. Batuner, A. Beck, T. Chan, H. Orman. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3838) 3839 MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files. R. Castagno, D. Singer. July 2004. (Format: TXT, HTML) (Updated by RFC6381) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3839) 3840 Indicating User Agent Capabilities in the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne, P. Kyzivat. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3840) 3841 Caller Preferences for the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne, P. Kyzivat. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3841) 3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP). R. Mahy. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3842) 3843 RObust Header Compression (ROHC): A Compression Profile for IP. L-E. Jonsson, G. Pelletier. June 2004. (Format: TXT, HTML) (Updated by RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3843) 3844 IETF Problem Resolution Process. E. Davies, Ed., J. Hofmann, Ed.. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3844) 3845 DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format. J. Schlyter, Ed.. August 2004. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC3755, RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3845) 3846 Mobile IPv4 Extension for Carrying Network Access Identifiers. F. Johansson, T. Johansson. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3846) 3847 Restart Signaling for Intermediate System to Intermediate System (IS-IS). M. Shand, L. Ginsberg. July 2004. (Format: TXT, HTML) (Obsoleted by RFC5306) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3847) 3848 ESMTP and LMTP Transmission Types Registration. C. Newman. July 2004. (Format: TXT, HTML) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3848) 3849 IPv6 Address Prefix Reserved for Documentation. G. Huston, A. Lord, P. Smith. July 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3849) 3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling. B. Ramsdell, Ed.. July 2004. (Format: TXT, HTML) (Obsoletes RFC2632) (Obsoleted by RFC5750) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3850) 3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. July 2004. (Format: TXT, HTML) (Obsoletes RFC2633) (Obsoleted by RFC5751) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3851) 3852 Cryptographic Message Syntax (CMS). R. Housley. July 2004. (Format: TXT, HTML) (Obsoletes RFC3369) (Obsoleted by RFC5652) (Updated by RFC4853, RFC5083) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3852) 3853 S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP). J. Peterson. July 2004. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3853) 3854 Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME). P. Hoffman, C. Bonatti, A. Eggen. July 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3854) 3855 Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400. P. Hoffman, C. Bonatti. July 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3855) 3856 A Presence Event Package for the Session Initiation Protocol (SIP). J. Rosenberg. August 2004. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3856) 3857 A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP). J. Rosenberg. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3857) 3858 An Extensible Markup Language (XML) Based Format for Watcher Information. J. Rosenberg. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3858) 3859 Common Profile for Presence (CPP). J. Peterson. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3859) 3860 Common Profile for Instant Messaging (CPIM). J. Peterson. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3860) 3861 Address Resolution for Instant Messaging and Presence. J. Peterson. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3861) 3862 Common Presence and Instant Messaging (CPIM): Message Format. G. Klyne, D. Atkins. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3862) 3863 Presence Information Data Format (PIDF). H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3863) 3864 Registration Procedures for Message Header Fields. G. Klyne, M. Nottingham, J. Mogul. September 2004. (Format: TXT, HTML) (Updated by RFC9110) (Also BCP0090) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3864) 3865 A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension. C. Malamud. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3865) 3866 Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). K. Zeilenga, Ed.. July 2004. (Format: TXT, HTML) (Obsoletes RFC2596) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3866) 3867 Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP). Y. Kawatsura, M. Hiroya, H. Beykirch. November 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3867) 3868 Signalling Connection Control Part User Adaptation Layer (SUA). J. Loughney, Ed., G. Sidebottom, L. Coene, G. Verwimp, J. Keller, B. Bidulock. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3868) 3869 IAB Concerns and Recommendations Regarding Internet Research and Evolution. R. Atkinson, Ed., S. Floyd, Ed., Internet Architecture Board. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3869) 3870 application/rdf+xml Media Type Registration. A. Swartz. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3870) 3871 Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure. G. Jones, Ed.. September 2004. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3871) 3872 Management Information Base for Telephony Routing over IP (TRIP). D. Zinman, D. Walker, J. Jiang. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3872) 3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB). J. Pastor, M. Belinchon. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3873) 3874 A 224-bit One-way Hash Function: SHA-224. R. Housley. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3874) 3875 The Common Gateway Interface (CGI) Version 1.1. D. Robinson, K. Coar. October 2004. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3875) 3876 Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3). D. Chadwick, S. Mullan. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3876) 3877 Alarm Management Information Base (MIB). S. Chisholm, D. Romascanu. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3877) 3878 Alarm Reporting Control Management Information Base (MIB). H. Lam, A. Huynh, D. Perkins. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3878) 3879 Deprecating Site Local Addresses. C. Huitema, B. Carpenter. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3879) 3880 Call Processing Language (CPL): A Language for User Control of Internet Telephony Services. J. Lennox, X. Wu, H. Schulzrinne. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3880) 3881 Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications. G. Marshall. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3881) 3882 Configuring BGP to Block Denial-of-Service Attacks. D. Turk. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3882) 3883 Detecting Inactive Neighbors over OSPF Demand Circuits (DC). S. Rao, A. Zinin, A. Roy. October 2004. (Format: TXT, HTML) (Updates RFC1793) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3883) 3884 Use of IPsec Transport Mode for Dynamic Routing. J. Touch, L. Eggert, Y. Wang. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3884) 3885 SMTP Service Extension for Message Tracking. E. Allman, T. Hansen. September 2004. (Format: TXT, HTML) (Updates RFC3461) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3885) 3886 An Extensible Message Format for Message Tracking Responses. E. Allman. September 2004. (Format: TXT, HTML) (Updates RFC3463) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3886) 3887 Message Tracking Query Protocol. T. Hansen. September 2004. (Format: TXT, HTML) (Updated by RFC8553, RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3887) 3888 Message Tracking Model and Requirements. T. Hansen. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3888) 3889 Not Issued. 3890 A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP). M. Westerlund. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3890) 3891 The Session Initiation Protocol (SIP) "Replaces" Header. R. Mahy, B. Biggs, R. Dean. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3891) 3892 The Session Initiation Protocol (SIP) Referred-By Mechanism. R. Sparks. September 2004. (Format: TXT, HTML) (Updated by RFC8217) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3892) 3893 Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format. J. Peterson. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3893) 3894 Sieve Extension: Copying Without Side Effects. J. Degener. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3894) 3895 Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types. O. Nicklass, Ed.. September 2004. (Format: TXT, HTML) (Obsoletes RFC2495) (Obsoleted by RFC4805) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3895) 3896 Definitions of Managed Objects for the DS3/E3 Interface Type. O. Nicklass, Ed.. September 2004. (Format: TXT, HTML) (Obsoletes RFC2496) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3896) 3897 Open Pluggable Edge Services (OPES) Entities and End Points Communication. A. Barbir. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3897) 3898 Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). V. Kalusivalingam. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3898) 3899 Not Issued. 3900 Not Issued. 3901 DNS IPv6 Transport Operational Guidelines. A. Durand, J. Ihren. September 2004. (Format: TXT, HTML) (Also BCP0091) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3901) 3902 The "application/soap+xml" media type. M. Baker, M. Nottingham. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3902) 3903 Session Initiation Protocol (SIP) Extension for Event State Publication. A. Niemi, Ed.. October 2004. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3903) 3904 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks. C. Huitema, R. Austein, S. Satapati, R. van der Pol. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3904) 3905 A Template for IETF Patent Disclosures and Licensing Declarations. V. See, Ed.. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3905) 3906 Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels. N. Shen, H. Smit. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3906) 3907 Not Issued. 3908 Not Issued. 3909 Lightweight Directory Access Protocol (LDAP) Cancel Operation. K. Zeilenga. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3909) 3910 The SPIRITS (Services in PSTN requesting Internet Services) Protocol. V. Gurbani, Ed., A. Brusilovsky, I. Faynberg, J. Gato, H. Lu, M. Unmehopa. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3910) 3911 The Session Initiation Protocol (SIP) "Join" Header. R. Mahy, D. Petrie. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3911) 3912 WHOIS Protocol Specification. L. Daigle. September 2004. (Format: TXT, HTML) (Obsoletes RFC0954, RFC0812) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3912) 3913 Border Gateway Multicast Protocol (BGMP): Protocol Specification. D. Thaler. September 2004. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3913) 3914 Open Pluggable Edge Services (OPES) Treatment of IAB Considerations. A. Barbir, A. Rousskov. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3914) 3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP). S. Hollenbeck. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3915) 3916 Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3). X. Xiao, Ed., D. McPherson, Ed., P. Pate, Ed.. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3916) 3917 Requirements for IP Flow Information Export (IPFIX). J. Quittek, T. Zseby, B. Claise, S. Zander. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3917) 3918 Methodology for IP Multicast Benchmarking. D. Stopp, B. Hickman. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3918) 3919 Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS). E. Stephan, J. Palet. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3919) 3920 Extensible Messaging and Presence Protocol (XMPP): Core. P. Saint-Andre, Ed.. October 2004. (Format: TXT, HTML) (Obsoleted by RFC6120) (Updated by RFC6122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3920) 3921 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence. P. Saint-Andre, Ed.. October 2004. (Format: TXT, HTML) (Obsoleted by RFC6121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3921) 3922 Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM). P. Saint-Andre. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3922) 3923 End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3923) 3924 Cisco Architecture for Lawful Intercept in IP Networks. F. Baker, B. Foster, C. Sharp. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3924) 3925 Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4). J. Littlefield. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3925) 3926 FLUTE - File Delivery over Unidirectional Transport. T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh. October 2004. (Format: TXT, HTML) (Obsoleted by RFC6726) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3926) 3927 Dynamic Configuration of IPv4 Link-Local Addresses. S. Cheshire, B. Aboba, E. Guttman. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3927) 3928 Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). R. Megginson, Ed., M. Smith, O. Natkovich, J. Parham. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3928) 3929 Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF. T. Hardie. October 2004. (Format: TXT, HTML) (Updated by RFC8717) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3929) 3930 The Protocol versus Document Points of View in Computer Protocols. D. Eastlake 3rd. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3930) 3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3). J. Lau, Ed., M. Townsley, Ed., I. Goyret, Ed.. March 2005. (Format: TXT, HTML) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3931) 3932 The IESG and RFC Editor Documents: Procedures. H. Alvestrand. October 2004. (Format: TXT, HTML) (Obsoleted by RFC5742) (Updates RFC2026, RFC3710) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3932) 3933 A Model for IETF Process Experiments. J. Klensin, S. Dawkins. November 2004. (Format: TXT, HTML) (Also BCP0093) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3933) 3934 Updates to RFC 2418 Regarding the Management of IETF Mailing Lists. M. Wasserman. October 2004. (Format: TXT, HTML) (Updates RFC2418) (Also BCP0025) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3934) 3935 A Mission Statement for the IETF. H. Alvestrand. October 2004. (Format: TXT, HTML) (Also BCP0095) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3935) 3936 Procedures for Modifying the Resource reSerVation Protocol (RSVP). K. Kompella, J. Lang. October 2004. (Format: TXT, HTML) (Updates RFC3209, RFC2205) (Also BCP0096) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3936) 3937 A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC). M. Steidl. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3937) 3938 Video-Message Message-Context. T. Hansen. October 2004. (Format: TXT, HTML) (Updates RFC3458) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3938) 3939 Calling Line Identification for Voice Mail Messages. G. Parsons, J. Maruszak. December 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3939) 3940 Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol. B. Adamson, C. Bormann, M. Handley, J. Macker. November 2004. (Format: TXT, HTML) (Obsoleted by RFC5740) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3940) 3941 Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks. B. Adamson, C. Bormann, M. Handley, J. Macker. November 2004. (Format: TXT, HTML) (Obsoleted by RFC5401) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3941) 3942 Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options. B. Volz. November 2004. (Format: TXT, HTML) (Updates RFC2132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3942) 3943 Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS). R. Friend. November 2004. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3943) 3944 H.350 Directory Services. T. Johnson, S. Okubo, S. Campos. December 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3944) 3945 Generalized Multi-Protocol Label Switching (GMPLS) Architecture. E. Mannie, Ed.. October 2004. (Format: TXT, HTML) (Updated by RFC6002) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3945) 3946 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control. E. Mannie, D. Papadimitriou. October 2004. (Format: TXT, HTML) (Obsoleted by RFC4606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3946) 3947 Negotiation of NAT-Traversal in the IKE. T. Kivinen, B. Swander, A. Huttunen, V. Volpe. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3947) 3948 UDP Encapsulation of IPsec ESP Packets. A. Huttunen, B. Swander, V. Volpe, L. DiBurro, M. Stenberg. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3948) 3949 File Format for Internet Fax. R. Buckley, D. Venable, L. McIntyre, G. Parsons, J. Rafferty. February 2005. (Format: TXT, HTML) (Obsoletes RFC2301) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3949) 3950 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration. L. McIntyre, G. Parsons, J. Rafferty. February 2005. (Format: TXT, HTML) (Obsoletes RFC3250) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3950) 3951 Internet Low Bit Rate Codec (iLBC). S. Andersen, A. Duric, H. Astrom, R. Hagen, W. Kleijn, J. Linden. December 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3951) 3952 Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech. A. Duric, S. Andersen. December 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3952) 3953 Telephone Number Mapping (ENUM) Service Registration for Presence Services. J. Peterson. January 2005. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3953) 3954 Cisco Systems NetFlow Services Export Version 9. B. Claise, Ed.. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3954) 3955 Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX). S. Leinen. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3955) 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. P. Savola, B. Haberman. November 2004. (Format: TXT, HTML) (Updates RFC3306) (Updated by RFC7371) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3956) 3957 Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4. C. Perkins, P. Calhoun. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3957) 3958 Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS). L. Daigle, A. Newton. January 2005. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3958) 3959 The Early Session Disposition Type for the Session Initiation Protocol (SIP). G. Camarillo. December 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3959) 3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP). G. Camarillo, H. Schulzrinne. December 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3960) 3961 Encryption and Checksum Specifications for Kerberos 5. K. Raeburn. February 2005. (Format: TXT, HTML) (Updated by RFC8429) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3961) 3962 Advanced Encryption Standard (AES) Encryption for Kerberos 5. K. Raeburn. February 2005. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3962) 3963 Network Mobility (NEMO) Basic Support Protocol. V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3963) 3964 Security Considerations for 6to4. P. Savola, C. Patel. December 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3964) 3965 A Simple Mode of Facsimile Using Internet Mail. K. Toyoda, H. Ohno, J. Murai, D. Wing. December 2004. (Format: TXT, HTML) (Obsoletes RFC2305) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3965) 3966 The tel URI for Telephone Numbers. H. Schulzrinne. December 2004. (Format: TXT, HTML) (Obsoletes RFC2806) (Updated by RFC5341) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3966) 3967 Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level. R. Bush, T. Narten. December 2004. (Format: TXT, HTML) (Updated by RFC4897, RFC8067) (Also BCP0097) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3967) 3968 The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP). G. Camarillo. December 2004. (Format: TXT, HTML) (Updates RFC3427) (Also BCP0098) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3968) 3969 The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP). G. Camarillo. December 2004. (Format: TXT, HTML) (Updates RFC3427) (Updated by RFC5727) (Also BCP0099) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3969) 3970 A Traffic Engineering (TE) MIB. K. Kompella. January 2005. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3970) 3971 SEcure Neighbor Discovery (SEND). J. Arkko, Ed., J. Kempf, B. Zill, P. Nikander. March 2005. (Format: TXT, HTML) (Updated by RFC6494, RFC6495, RFC6980) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3971) 3972 Cryptographically Generated Addresses (CGA). T. Aura. March 2005. (Format: TXT, HTML) (Updated by RFC4581, RFC4982) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3972) 3973 Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). A. Adams, J. Nicholas, W. Siadak. January 2005. (Format: TXT, HTML) (Updated by RFC8736) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3973) 3974 SMTP Operational Experience in Mixed IPv4/v6 Environments. M. Nakamura, J. Hagino. January 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3974) 3975 OMA-IETF Standardization Collaboration. G. Huston, Ed., I. Leuca, Ed.. January 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3975) 3976 Interworking SIP and Intelligent Network (IN) Applications. V. K. Gurbani, F. Haerens, V. Rastogi. January 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3976) 3977 Network News Transfer Protocol (NNTP). C. Feather. October 2006. (Format: TXT, HTML) (Obsoletes RFC0977) (Updates RFC2980) (Updated by RFC6048) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3977) 3978 IETF Rights in Contributions. S. Bradner, Ed.. March 2005. (Format: TXT, HTML) (Obsoletes RFC3667) (Obsoleted by RFC5378) (Updates RFC2026) (Updated by RFC4748) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3978) 3979 Intellectual Property Rights in IETF Technology. S. Bradner, Ed.. March 2005. (Format: TXT, HTML) (Obsoletes RFC3668) (Obsoleted by RFC8179) (Updates RFC2026, RFC2028) (Updated by RFC4879) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3979) 3980 T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names. M. Krueger, M. Chadalapaka, R. Elliott. February 2005. (Format: TXT, HTML) (Obsoleted by RFC7143) (Updates RFC3720) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3980) 3981 IRIS: The Internet Registry Information Service (IRIS) Core Protocol. A. Newton, M. Sanz. January 2005. (Format: TXT, HTML) (Updated by RFC4992) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3981) 3982 IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS). A. Newton, M. Sanz. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3982) 3983 Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP). A. Newton, M. Sanz. January 2005. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3983) 3984 RTP Payload Format for H.264 Video. S. Wenger, M.M. Hannuksela, T. Stockhammer, M. Westerlund, D. Singer. February 2005. (Format: TXT, HTML) (Obsoleted by RFC6184) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3984) 3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture. S. Bryant, Ed., P. Pate, Ed.. March 2005. (Format: TXT, HTML) (Updated by RFC5462) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3985) 3986 Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. January 2005. (Format: TXT, HTML) (Obsoletes RFC2732, RFC2396, RFC1808) (Updates RFC1738) (Updated by RFC6874, RFC7320, RFC8820) (Also STD0066) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3986) 3987 Internationalized Resource Identifiers (IRIs). M. Duerst, M. Suignard. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3987) 3988 Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol. B. Black, K. Kompella. January 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3988) 3989 Middlebox Communications (MIDCOM) Protocol Semantics. M. Stiemerling, J. Quittek, T. Taylor. February 2005. (Format: TXT, HTML) (Obsoleted by RFC5189) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3989) 3990 Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement. B. O'Hara, P. Calhoun, J. Kempf. February 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3990) 3991 Media Gateway Control Protocol (MGCP) Redirect and Reset Package. B. Foster, F. Andreasen. February 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3991) 3992 Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism. B. Foster, F. Andreasen. February 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3992) 3993 Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option. R. Johnson, T. Palaniappan, M. Stapp. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3993) 3994 Indication of Message Composition for Instant Messaging. H. Schulzrinne. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3994) 3995 Internet Printing Protocol (IPP): Event Notifications and Subscriptions. R. Herriot, T. Hastings. March 2005. (Format: TXT, HTML) (Updates RFC2911, RFC2910) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3995) 3996 Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications. R. Herriot, T. Hastings, H. Lewis. March 2005. (Format: TXT, HTML) (Updates RFC2911) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3996) 3997 Internet Printing Protocol (IPP): Requirements for IPP Notifications. T. Hastings, Ed., R. K. deBry, H. Lewis. March 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3997) 3998 Internet Printing Protocol (IPP): Job and Printer Administrative Operations. C. Kugler, H. Lewis, T. Hastings, Ed.. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3998) 3999 Not Issued. 4000 Not Issued. 4001 Textual Conventions for Internet Network Addresses. M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. February 2005. (Format: TXT, HTML) (Obsoletes RFC3291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4001) 4002 IANA Registration for Enumservice 'web' and 'ft'. R. Brandner, L. Conroy, R. Stastny. February 2005. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4002) 4003 GMPLS Signaling Procedure for Egress Control. L. Berger. February 2005. (Format: TXT, HTML) (Updates RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4003) 4004 Diameter Mobile IPv4 Application. P. Calhoun, T. Johansson, C. Perkins, T. Hiller, Ed., P. McCann. August 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4004) 4005 Diameter Network Access Server Application. P. Calhoun, G. Zorn, D. Spence, D. Mitton. August 2005. (Format: TXT, HTML) (Obsoleted by RFC7155) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4005) 4006 Diameter Credit-Control Application. H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney. August 2005. (Format: TXT, HTML) (Obsoleted by RFC8506) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4006) 4007 IPv6 Scoped Address Architecture. S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill. March 2005. (Format: TXT, HTML) (Updated by RFC7346) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4007) 4008 Definitions of Managed Objects for Network Address Translators (NAT). R. Rohit, P. Srisuresh, R. Raghunarayan, N. Pai, C. Wang. March 2005. (Format: TXT, HTML) (Obsoleted by RFC7658) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4008) 4009 The SEED Encryption Algorithm. J. Park, S. Lee, J. Kim, J. Lee. February 2005. (Format: TXT, HTML) (Obsoleted by RFC4269) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4009) 4010 Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS). J. Park, S. Lee, J. Kim, J. Lee. February 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4010) 4011 Policy Based Management MIB. S. Waldbusser, J. Saperia, T. Hongal. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4011) 4012 Routing Policy Specification Language next generation (RPSLng). L. Blunk, J. Damas, F. Parent, A. Robachevsky. March 2005. (Format: TXT, HTML) (Updates RFC2725, RFC2622) (Updated by RFC7909) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4012) 4013 SASLprep: Stringprep Profile for User Names and Passwords. K. Zeilenga. February 2005. (Format: TXT, HTML) (Obsoleted by RFC7613) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4013) 4014 Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option. R. Droms, J. Schnizlein. February 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4014) 4015 The Eifel Response Algorithm for TCP. R. Ludwig, A. Gurtov. February 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4015) 4016 Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements. M. Parthasarathy. March 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4016) 4017 Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs. D. Stanley, J. Walker, B. Aboba. March 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4017) 4018 Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2). M. Bakke, J. Hufferd, K. Voruganti, M. Krueger, T. Sperry. April 2005. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4018) 4019 RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite. G. Pelletier. April 2005. (Format: TXT, HTML) (Updated by RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4019) 4020 Early IANA Allocation of Standards Track Code Points. K. Kompella, A. Zinin. February 2005. (Format: TXT, HTML) (Obsoleted by RFC7120) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4020) 4021 Registration of Mail and MIME Header Fields. G. Klyne, J. Palme. March 2005. (Format: TXT, HTML) (Updated by RFC5322) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4021) 4022 Management Information Base for the Transmission Control Protocol (TCP). R. Raghunarayan, Ed.. March 2005. (Format: TXT, HTML) (Obsoletes RFC2452, RFC2012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4022) 4023 Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE). T. Worster, Y. Rekhter, E. Rosen, Ed.. March 2005. (Format: TXT, HTML) (Updated by RFC5332) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4023) 4024 Voice Messaging Client Behaviour. G. Parsons, J. Maruszak. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4024) 4025 A Method for Storing IPsec Keying Material in DNS. M. Richardson. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4025) 4026 Provider Provisioned Virtual Private Network (VPN) Terminology. L. Andersson, T. Madsen. March 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4026) 4027 Domain Name System Media Types. S. Josefsson. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4027) 4028 Session Timers in the Session Initiation Protocol (SIP). S. Donovan, J. Rosenberg. April 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4028) 4029 Scenarios and Analysis for Introducing IPv6 into ISP Networks. M. Lind, V. Ksinant, S. Park, A. Baudot, P. Savola. March 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4029) 4030 The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option. M. Stapp, T. Lemon. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4030) 4031 Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs). M. Carugi, Ed., D. McDysan, Ed.. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4031) 4032 Update to the Session Initiation Protocol (SIP) Preconditions Framework. G. Camarillo, P. Kyzivat. March 2005. (Format: TXT, HTML) (Updates RFC3312) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4032) 4033 DNS Security Introduction and Requirements. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT, HTML) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3597, RFC3226) (Updated by RFC6014, RFC6840) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4033) 4034 Resource Records for the DNS Security Extensions. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT, HTML) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3597, RFC3226) (Updated by RFC4470, RFC6014, RFC6840, RFC6944, RFC9077) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4034) 4035 Protocol Modifications for the DNS Security Extensions. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT, HTML) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3597, RFC3226) (Updated by RFC4470, RFC6014, RFC6840, RFC8198, RFC9077) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4035) 4036 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management. W. Sawyer. April 2005. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4036) 4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core. A. Rousskov. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4037) 4038 Application Aspects of IPv6 Transition. M-K. Shin, Ed., Y-G. Hong, J. Hagino, P. Savola, E. M. Castro. March 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4038) 4039 Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4). S. Park, P. Kim, B. Volz. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4039) 4040 RTP Payload Format for a 64 kbit/s Transparent Call. R. Kreuter. April 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4040) 4041 Requirements for Morality Sections in Routing Area Drafts. A. Farrel. 1 April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4041) 4042 UTF-9 and UTF-18 Efficient Transformation Formats of Unicode. M. Crispin. 1 April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4042) 4043 Internet X.509 Public Key Infrastructure Permanent Identifier. D. Pinkas, T. Gindin. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4043) 4044 Fibre Channel Management MIB. K. McCloghrie. May 2005. (Format: TXT, HTML) (Obsoletes RFC2837) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4044) 4045 Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP). G. Bourdon. April 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4045) 4046 Multicast Security (MSEC) Group Key Management Architecture. M. Baugher, R. Canetti, L. Dondeti, F. Lindholm. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4046) 4047 MIME Sub-type Registrations for Flexible Image Transport System (FITS). S. Allen, D. Wells. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4047) 4048 RFC 1888 Is Obsolete. B. Carpenter. April 2005. (Format: TXT, HTML) (Obsoletes RFC1888) (Updated by RFC4548) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4048) 4049 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1. R. Housley. April 2005. (Format: TXT, HTML) (Obsoleted by RFC6019) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4049) 4050 Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures. S. Blake-Wilson, G. Karlinger, T. Kobayashi, Y. Wang. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4050) 4051 Additional XML Security Uniform Resource Identifiers (URIs). D. Eastlake 3rd. April 2005. (Format: TXT, HTML) (Obsoleted by RFC6931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4051) 4052 IAB Processes for Management of IETF Liaison Relationships. L. Daigle, Ed., Internet Architecture Board. April 2005. (Format: TXT, HTML) (Also BCP0102) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4052) 4053 Procedures for Handling Liaison Statements to and from the IETF. S. Trowbridge, S. Bradner, F. Baker. April 2005. (Format: TXT, HTML) (Also BCP0103) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4053) 4054 Impairments and Other Constraints on Optical Layer Routing. J. Strand, Ed., A. Chiu, Ed.. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4054) 4055 Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. J. Schaad, B. Kaliski, R. Housley. June 2005. (Format: TXT, HTML) (Updates RFC3279) (Updated by RFC5756) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4055) 4056 Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS). J. Schaad. June 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4056) 4057 IPv6 Enterprise Network Scenarios. J. Bound, Ed.. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4057) 4058 Protocol for Carrying Authentication for Network Access (PANA) Requirements. A. Yegin, Ed., Y. Ohba, R. Penno, G. Tsirtsis, C. Wang. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4058) 4059 Internet X.509 Public Key Infrastructure Warranty Certificate Extension. D. Linsenbardt, S. Pontius, A. Sturgeon. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4059) 4060 RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding. Q. Xie, D. Pearce. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4060) 4061 Benchmarking Basic OSPF Single Router Control Plane Convergence. V. Manral, R. White, A. Shaikh. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4061) 4062 OSPF Benchmarking Terminology and Concepts. V. Manral, R. White, A. Shaikh. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4062) 4063 Considerations When Using Basic OSPF Convergence Benchmarks. V. Manral, R. White, A. Shaikh. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4063) 4064 Experimental Message, Extensions, and Error Codes for Mobile IPv4. A. Patel, K. Leung. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4064) 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations. J. Kempf. July 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4065) 4066 Candidate Access Router Discovery (CARD). M. Liebsch, Ed., A. Singh, Ed., H. Chaskar, D. Funato, E. Shim. July 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4066) 4067 Context Transfer Protocol (CXTP). J. Loughney, Ed., M. Nakhjiri, C. Perkins, R. Koodli. July 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4067) 4068 Fast Handovers for Mobile IPv6. R. Koodli, Ed.. July 2005. (Format: TXT, HTML) (Obsoleted by RFC5268) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4068) 4069 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding. M. Dodge, B. Ray. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4069) 4070 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding. M. Dodge, B. Ray. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4070) 4071 Structure of the IETF Administrative Support Activity (IASA). R. Austein, Ed., B. Wijnen, Ed.. April 2005. (Format: TXT, HTML) (Obsoleted by RFC8711) (Updated by RFC4371, RFC7691) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4071) 4072 Diameter Extensible Authentication Protocol (EAP) Application. P. Eronen, Ed., T. Hiller, G. Zorn. August 2005. (Format: TXT, HTML) (Updated by RFC7268, RFC8044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4072) 4073 Protecting Multiple Contents with the Cryptographic Message Syntax (CMS). R. Housley. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4073) 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses. Y. Morishita, T. Jinmei. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4074) 4075 Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6. V. Kalusivalingam. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4075) 4076 Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6). T. Chown, S. Venaas, A. Vijayabhaskar. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4076) 4077 A Negative Acknowledgement Mechanism for Signaling Compression. A.B. Roach. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4077) 4078 The TV-Anytime Content Reference Identifier (CRID). N. Earnshaw, S. Aoki, A. Ashley, W. Kameyama. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4078) 4079 A Presence Architecture for the Distribution of GEOPRIV Location Objects. J. Peterson. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4079) 4080 Next Steps in Signaling (NSIS): Framework. R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4080) 4081 Security Threats for Next Steps in Signaling (NSIS). H. Tschofenig, D. Kroeselberg. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4081) 4082 Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction. A. Perrig, D. Song, R. Canetti, J. D. Tygar, B. Briscoe. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4082) 4083 Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP). M. Garcia-Martin. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4083) 4084 Terminology for Describing Internet Connectivity. J. Klensin. May 2005. (Format: TXT, HTML) (Also BCP0104) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4084) 4085 Embedding Globally-Routable Internet Addresses Considered Harmful. D. Plonka. June 2005. (Format: TXT, HTML) (Also BCP0105) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4085) 4086 Randomness Requirements for Security. D. Eastlake 3rd, J. Schiller, S. Crocker. June 2005. (Format: TXT, HTML) (Obsoletes RFC1750) (Also BCP0106) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4086) 4087 IP Tunnel MIB. D. Thaler. June 2005. (Format: TXT, HTML) (Obsoletes RFC2667) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4087) 4088 Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP). D. Black, K. McCloghrie, J. Schoenwaelder. June 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4088) 4089 IAB and IESG Recommendation for IETF Administrative Restructuring. S. Hollenbeck, Ed., IAB and IESG. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4089) 4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels. P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed.. May 2005. (Format: TXT, HTML) (Updated by RFC8271, RFC8537, RFC8796) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4090) 4091 The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework. G. Camarillo, J. Rosenberg. June 2005. (Format: TXT, HTML) (Obsoleted by RFC5245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4091) 4092 Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP). G. Camarillo, J. Rosenberg. June 2005. (Format: TXT, HTML) (Obsoleted by RFC5245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4092) 4093 Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways. F. Adrangi, Ed., H. Levkowetz, Ed.. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4093) 4094 Analysis of Existing Quality-of-Service Signaling Protocols. J. Manner, X. Fu. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4094) 4095 Attaching Meaning to Solicitation Class Keywords. C. Malamud. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4095) 4096 Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best. C. Malamud. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4096) 4097 Middlebox Communications (MIDCOM) Protocol Evaluation. M. Barnes, Ed.. June 2005. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4097) 4098 Terminology for Benchmarking BGP Device Convergence in the Control Plane. H. Berkowitz, E. Davies, Ed., S. Hares, P. Krishnaswamy, M. Lepp. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4098) 4099 Not Issued. 4100 Not Issued. 4101 Writing Protocol Models. E. Rescorla, IAB. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4101) 4102 Registration of the text/red MIME Sub-Type. P. Jones. June 2005. (Format: TXT, HTML) (Updated by RFC6354) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4102) 4103 RTP Payload for Text Conversation. G. Hellstrom, P. Jones. June 2005. (Format: TXT, HTML) (Obsoletes RFC2793) (Updated by RFC9071) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4103) 4104 Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS). M. Pana, Ed., A. Reyes, A. Barba, D. Moron, M. Brunner. June 2005. (Format: TXT, HTML) (Updates RFC3703) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4104) 4105 Requirements for Inter-Area MPLS Traffic Engineering. J.-L. Le Roux, Ed., J.-P. Vasseur, Ed., J. Boyle, Ed.. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4105) 4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP). J. Viega, D. McGrew. June 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4106) 4107 Guidelines for Cryptographic Key Management. S. Bellovin, R. Housley. June 2005. (Format: TXT, HTML) (Also BCP0107) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4107) 4108 Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages. R. Housley. August 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4108) 4109 Algorithms for Internet Key Exchange version 1 (IKEv1). P. Hoffman. May 2005. (Format: TXT, HTML) (Updates RFC2409) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4109) 4110 A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). R. Callon, M. Suzuki. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4110) 4111 Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs). L. Fang, Ed.. July 2005. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4111) 4112 Electronic Commerce Modeling Language (ECML) Version 2 Specification. D. Eastlake 3rd. June 2005. (Format: TXT, HTML) (Updates RFC3106) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4112) 4113 Management Information Base for the User Datagram Protocol (UDP). B. Fenner, J. Flick. June 2005. (Format: TXT, HTML) (Obsoletes RFC2454, RFC2013) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4113) 4114 E.164 Number Mapping for the Extensible Provisioning Protocol (EPP). S. Hollenbeck. June 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4114) 4115 A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic. O. Aboul-Magd, S. Rabie. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4115) 4116 IPv4 Multihoming Practices and Limitations. J. Abley, K. Lindqvist, E. Davies, B. Black, V. Gill. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4116) 4117 Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc). G. Camarillo, E. Burger, H. Schulzrinne, A. van Wijk. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4117) 4118 Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP). L. Yang, P. Zerfos, E. Sadot. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4118) 4119 A Presence-based GEOPRIV Location Object Format. J. Peterson. December 2005. (Format: TXT, HTML) (Updated by RFC5139, RFC5491, RFC7459) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4119) 4120 The Kerberos Network Authentication Service (V5). C. Neuman, T. Yu, S. Hartman, K. Raeburn. July 2005. (Format: TXT, HTML) (Obsoletes RFC1510) (Updated by RFC4537, RFC5021, RFC5896, RFC6111, RFC6112, RFC6113, RFC6649, RFC6806, RFC7751, RFC8062, RFC8129, RFC8429, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4120) 4121 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2. L. Zhu, K. Jaganathan, S. Hartman. July 2005. (Format: TXT, HTML) (Updates RFC1964) (Updated by RFC5896, RFC6112, RFC6542, RFC6649, RFC8062) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4121) 4122 A Universally Unique IDentifier (UUID) URN Namespace. P. Leach, M. Mealling, R. Salz. July 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4122) 4123 Session Initiation Protocol (SIP)-H.323 Interworking Requirements. H. Schulzrinne, C. Agboh. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4123) 4124 Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering. F. Le Faucheur, Ed.. June 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4124) 4125 Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering. F. Le Faucheur, W. Lai. June 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4125) 4126 Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons. J. Ash. June 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4126) 4127 Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering. F. Le Faucheur, Ed.. June 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4127) 4128 Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation. W. Lai. June 2005. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4128) 4129 Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol. R. Mukundan, K. Morneault, N. Mangalpally. September 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4129) 4130 MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2). D. Moberg, R. Drummond. July 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4130) 4131 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus. S. Green, K. Ozawa, E. Cardona, Ed., A. Katsnelson. September 2005. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4131) 4132 Addition of Camellia Cipher Suites to Transport Layer Security (TLS). S. Moriai, A. Kato, M. Kanda. July 2005. (Format: TXT, HTML) (Obsoleted by RFC5932) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4132) 4133 Entity MIB (Version 3). A. Bierman, K. McCloghrie. August 2005. (Format: TXT, HTML) (Obsoletes RFC2737) (Obsoleted by RFC6933) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4133) 4134 Examples of S/MIME Messages. P. Hoffman, Ed.. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4134) 4135 Goals of Detecting Network Attachment in IPv6. JH. Choi, G. Daley. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4135) 4136 OSPF Refresh and Flooding Reduction in Stable Topologies. P. Pillay-Esnault. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4136) 4137 State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator. J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba. August 2005. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4137) 4138 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP). P. Sarolahti, M. Kojo. August 2005. (Format: TXT, HTML) (Updated by RFC5682) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4138) 4139 Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON). D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4139) 4140 Hierarchical Mobile IPv6 Mobility Management (HMIPv6). H. Soliman, C. Castelluccia, K. El Malki, L. Bellier. August 2005. (Format: TXT, HTML) (Obsoleted by RFC5380) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4140) 4141 SMTP and MIME Extensions for Content Conversion. K. Toyoda, D. Crocker. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4141) 4142 Full-mode Fax Profile for Internet Mail (FFPIM). D. Crocker, G. Klyne. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4142) 4143 Facsimile Using Internet Mail (IFAX) Service of ENUM. K. Toyoda, D. Crocker. November 2005. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4143) 4144 How to Gain Prominence and Influence in Standards Organizations. D. Eastlake 3rd. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4144) 4145 TCP-Based Media Transport in the Session Description Protocol (SDP). D. Yon, G. Camarillo. September 2005. (Format: TXT, HTML) (Updated by RFC4572) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4145) 4146 Simple New Mail Notification. R. Gellens. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4146) 4147 Proposed Changes to the Format of the IANA IPv6 Registry. G. Huston. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4147) 4148 IP Performance Metrics (IPPM) Metrics Registry. E. Stephan. August 2005. (Format: TXT, HTML) (Obsoleted by RFC6248) (Also BCP0108) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4148) 4149 Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms. C. Kalbfleisch, R. Cole, D. Romascanu. August 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4149) 4150 Transport Performance Metrics MIB. R. Dietz, R. Cole. August 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4150) 4151 The 'tag' URI Scheme. T. Kindberg, S. Hawke. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4151) 4152 A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code. K. Tesink, R. Fox. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4152) 4153 XML Voucher: Generic Voucher Language. K. Fujimura, M. Terada, D. Eastlake 3rd. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4153) 4154 Voucher Trading System Application Programming Interface (VTS-API). M. Terada, K. Fujimura. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4154) 4155 The application/mbox Media Type. E. Hall. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4155) 4156 The wais URI Scheme. P. Hoffman. August 2005. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4156) 4157 The prospero URI Scheme. P. Hoffman. August 2005. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4157) 4158 Internet X.509 Public Key Infrastructure: Certification Path Building. M. Cooper, Y. Dzambasow, P. Hesse, S. Joseph, R. Nicholas. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4158) 4159 Deprecation of "ip6.int". G. Huston. August 2005. (Format: TXT, HTML) (Also BCP0109) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4159) 4160 Internet Fax Gateway Requirements. K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide, C. Allocchio. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4160) 4161 Guidelines for Optional Services for Internet Fax Gateways. K. Mimura, K. Yokoyama, T. Satoh, K. Watanabe, C. Kanaide. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4161) 4162 Addition of SEED Cipher Suites to Transport Layer Security (TLS). H.J. Lee, J.H. Yoon, J.I. Lee. August 2005. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4162) 4163 RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression. L-E. Jonsson. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4163) 4164 RObust Header Compression (ROHC): Context Replication for ROHC Profiles. G. Pelletier. August 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4164) 4165 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA). T. George, B. Bidulock, R. Dantu, H. Schwarzbauer, K. Morneault. September 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4165) 4166 Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement. L. Coene, J. Pastor-Balbas. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4166) 4167 Graceful OSPF Restart Implementation Report. A. Lindem. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4167) 4168 The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne, G. Camarillo. October 2005. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4168) 4169 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2. V. Torvinen, J. Arkko, M. Naslund. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4169) 4170 Tunneling Multiplexed Compressed RTP (TCRTP). B. Thompson, T. Koren, D. Wing. November 2005. (Format: TXT, HTML) (Also BCP0110) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4170) 4171 Internet Storage Name Service (iSNS). J. Tseng, K. Gibbons, F. Travostino, C. Du Laney, J. Souza. September 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4171) 4172 iFCP - A Protocol for Internet Fibre Channel Storage Networking. C. Monia, R. Mullendore, F. Travostino, W. Jeong, M. Edwards. September 2005. (Format: TXT, HTML) (Updated by RFC6172, RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4172) 4173 Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol. P. Sarkar, D. Missimer, C. Sapuntzakis. September 2005. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4173) 4174 The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service. C. Monia, J. Tseng, K. Gibbons. September 2005. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4174) 4175 RTP Payload Format for Uncompressed Video. L. Gharai, C. Perkins. September 2005. (Format: TXT, HTML) (Updated by RFC4421) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4175) 4176 Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management. Y. El Mghazli, Ed., T. Nadeau, M. Boucadair, K. Chan, A. Gonguet. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4176) 4177 Architectural Approaches to Multi-homing for IPv6. G. Huston. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4177) 4178 The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism. L. Zhu, P. Leach, K. Jaganathan, W. Ingersoll. October 2005. (Format: TXT, HTML) (Obsoletes RFC2478) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4178) 4179 Using Universal Content Identifier (UCI) as Uniform Resource Names (URN). S. Kang. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4179) 4180 Common Format and MIME Type for Comma-Separated Values (CSV) Files. Y. Shafranovich. October 2005. (Format: TXT, HTML) (Updated by RFC7111) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4180) 4181 Guidelines for Authors and Reviewers of MIB Documents. C. Heard, Ed.. September 2005. (Format: TXT, HTML) (Updated by RFC4841) (Also BCP0111) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4181) 4182 Removing a Restriction on the use of MPLS Explicit NULL. E. Rosen. September 2005. (Format: TXT, HTML) (Updates RFC3032) (Updated by RFC5462, RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4182) 4183 A Suggested Scheme for DNS Resolution of Networks and Gateways. E. Warnicke. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4183) 4184 RTP Payload Format for AC-3 Audio. B. Link, T. Hager, J. Flaks. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4184) 4185 National and Local Characters for DNS Top Level Domain (TLD) Names. J. Klensin. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4185) 4186 Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM). H. Haverinen, Ed., J. Salowey, Ed.. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4186) 4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA). J. Arkko, H. Haverinen. January 2006. (Format: TXT, HTML) (Updated by RFC5448, RFC9048) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4187) 4188 Definitions of Managed Objects for Bridges. K. Norseth, Ed., E. Bell, Ed.. September 2005. (Format: TXT, HTML) (Obsoletes RFC1493) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4188) 4189 Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP). K. Ono, S. Tachimoto. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4189) 4190 Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony. K. Carlberg, I. Brown, C. Beard. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4190) 4191 Default Router Preferences and More-Specific Routes. R. Draves, D. Thaler. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4191) 4192 Procedures for Renumbering an IPv6 Network without a Flag Day. F. Baker, E. Lear, R. Droms. September 2005. (Format: TXT, HTML) (Updates RFC2072) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4192) 4193 Unique Local IPv6 Unicast Addresses. R. Hinden, B. Haberman. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4193) 4194 The S Hexdump Format. J. Strombergson, L. Walleij, P. Faltstrom. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4194) 4195 A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum. W. Kameyama. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4195) 4196 The SEED Cipher Algorithm and Its Use with IPsec. H.J. Lee, J.H. Yoon, S.L. Lee, J.I. Lee. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4196) 4197 Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks. M. Riegel, Ed.. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4197) 4198 A Uniform Resource Name (URN) Namespace for Federated Content. D. Tessman. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4198) 4199 Not Issued. 4200 Not Issued. 4201 Link Bundling in MPLS Traffic Engineering (TE). K. Kompella, Y. Rekhter, L. Berger. October 2005. (Format: TXT, HTML) (Updates RFC3471, RFC3472, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4201) 4202 Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). K. Kompella, Ed., Y. Rekhter, Ed.. October 2005. (Format: TXT, HTML) (Updated by RFC6001, RFC6002, RFC7074) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4202) 4203 OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). K. Kompella, Ed., Y. Rekhter, Ed.. October 2005. (Format: TXT, HTML) (Updates RFC3630) (Updated by RFC6001, RFC6002, RFC7074) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4203) 4204 Link Management Protocol (LMP). J. Lang, Ed.. October 2005. (Format: TXT, HTML) (Updated by RFC6898) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4204) 4205 Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). K. Kompella, Ed., Y. Rekhter, Ed.. October 2005. (Format: TXT, HTML) (Obsoleted by RFC5307) (Updates RFC3784) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4205) 4206 Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE). K. Kompella, Y. Rekhter. October 2005. (Format: TXT, HTML) (Updated by RFC6001, RFC6107) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4206) 4207 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages. J. Lang, D. Papadimitriou. October 2005. (Format: TXT, HTML) (Updated by RFC6898) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4207) 4208 Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model. G. Swallow, J. Drake, H. Ishimatsu, Y. Rekhter. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4208) 4209 Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems. A. Fredette, Ed., J. Lang, Ed.. October 2005. (Format: TXT, HTML) (Updated by RFC6898) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4209) 4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP). C. Adams, S. Farrell, T. Kause, T. Mononen. September 2005. (Format: TXT, HTML) (Obsoletes RFC2510) (Updated by RFC6712) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4210) 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF). J. Schaad. September 2005. (Format: TXT, HTML) (Obsoletes RFC2511) (Updated by RFC9045) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4211) 4212 Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols. M. Blinov, C. Adams. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4212) 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E. Nordmark, R. Gilligan. October 2005. (Format: TXT, HTML) (Obsoletes RFC2893) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4213) 4214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). F. Templin, T. Gleeson, M. Talwar, D. Thaler. October 2005. (Format: TXT, HTML) (Obsoleted by RFC5214) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4214) 4215 Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks. J. Wiljakka, Ed.. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4215) 4216 MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements. R. Zhang, Ed., J.-P. Vasseur, Ed.. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4216) 4217 Securing FTP with TLS. P. Ford-Hutchinson. October 2005. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4217) 4218 Threats Relating to IPv6 Multihoming Solutions. E. Nordmark, T. Li. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4218) 4219 Things Multihoming in IPv6 (MULTI6) Developers Should Think About. E. Lear. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4219) 4220 Traffic Engineering Link Management Information Base. M. Dubuc, T. Nadeau, J. Lang. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4220) 4221 Multiprotocol Label Switching (MPLS) Management Overview. T. Nadeau, C. Srinivasan, A. Farrel. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4221) 4222 Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance. G. Choudhury, Ed.. October 2005. (Format: TXT, HTML) (Also BCP0112) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4222) 4223 Reclassification of RFC 1863 to Historic. P. Savola. October 2005. (Format: TXT, HTML) (Obsoletes RFC1863) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4223) 4224 RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets. G. Pelletier, L-E. Jonsson, K. Sandlund. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4224) 4225 Mobile IP Version 6 Route Optimization Security Design Background. P. Nikander, J. Arkko, T. Aura, G. Montenegro, E. Nordmark. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4225) 4226 HOTP: An HMAC-Based One-Time Password Algorithm. D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache, O. Ranen. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4226) 4227 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP). E. O'Tuathail, M. Rose. January 2006. (Format: TXT, HTML) (Obsoletes RFC3288) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4227) 4228 Requirements for an IETF Draft Submission Toolset. A. Rousskov. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4228) 4229 HTTP Header Field Registrations. M. Nottingham, J. Mogul. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4229) 4230 RSVP Security Properties. H. Tschofenig, R. Graveman. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4230) 4231 Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. M. Nystrom. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4231) 4232 Not Issued. 4233 Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer. K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. January 2006. (Format: TXT, HTML) (Obsoletes RFC3057) (Updated by RFC5133) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4233) 4234 Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., P. Overell. October 2005. (Format: TXT, HTML) (Obsoletes RFC2234) (Obsoleted by RFC5234) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4234) 4235 An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne, R. Mahy, Ed.. November 2005. (Format: TXT, HTML) (Updated by RFC7463, RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4235) 4236 HTTP Adaptation with Open Pluggable Edge Services (OPES). A. Rousskov, M. Stecher. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4236) 4237 Voice Messaging Directory Service. G. Vaudreuil. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4237) 4238 Voice Message Routing Service. G. Vaudreuil. October 2005. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4238) 4239 Internet Voice Messaging (IVM). S. McRae, G. Parsons. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4239) 4240 Basic Network Media Services with SIP. E. Burger, Ed., J. Van Dyke, A. Spitzer. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4240) 4241 A Model of IPv6/IPv4 Dual Stack Internet Access Service. Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4241) 4242 Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). S. Venaas, T. Chown, B. Volz. November 2005. (Format: TXT, HTML) (Obsoleted by RFC8415) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4242) 4243 Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option. M. Stapp, R. Johnson, T. Palaniappan. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4243) 4244 An Extension to the Session Initiation Protocol (SIP) for Request History Information. M. Barnes, Ed.. November 2005. (Format: TXT, HTML) (Obsoleted by RFC7044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4244) 4245 High-Level Requirements for Tightly Coupled SIP Conferencing. O. Levin, R. Even. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4245) 4246 International Standard Audiovisual Number (ISAN) URN Definition. M. Dolan. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4246) 4247 Requirements for Header Compression over MPLS. J. Ash, B. Goode, J. Hand, R. Zhang. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4247) 4248 The telnet URI Scheme. P. Hoffman. October 2005. (Format: TXT, HTML) (Obsoletes RFC1738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4248) 4249 Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components. B. Lilly. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4249) 4250 The Secure Shell (SSH) Protocol Assigned Numbers. S. Lehtinen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC8268, RFC9142) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4250) 4251 The Secure Shell (SSH) Protocol Architecture. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC8308, RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4251) 4252 The Secure Shell (SSH) Authentication Protocol. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC8308, RFC8332) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4252) 4253 The Secure Shell (SSH) Transport Layer Protocol. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC6668, RFC8268, RFC8308, RFC8332, RFC8709, RFC8758, RFC9142) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4253) 4254 The Secure Shell (SSH) Connection Protocol. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC8308) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4254) 4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints. J. Schlyter, W. Griffin. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4255) 4256 Generic Message Exchange Authentication for the Secure Shell Protocol (SSH). F. Cusack, M. Forssen. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4256) 4257 Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks. G. Bernstein, E. Mannie, V. Sharma, E. Gray. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4257) 4258 Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON). D. Brungard, Ed.. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4258) 4259 A Framework for Transmission of IP Datagrams over MPEG-2 Networks. M.-J. Montpetit, G. Fairhurst, H. Clausen, B. Collini-Nocker, H. Linder. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4259) 4260 Mobile IPv6 Fast Handovers for 802.11 Networks. P. McCann. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4260) 4261 Common Open Policy Service (COPS) Over Transport Layer Security (TLS). J. Walker, A. Kulkarni, Ed.. December 2005. (Format: TXT, HTML) (Updates RFC2748) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4261) 4262 X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities. S. Santesson. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4262) 4263 Media Subtype Registration for Media Type text/troff. B. Lilly. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4263) 4264 BGP Wedgies. T. Griffin, G. Huston. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4264) 4265 Definition of Textual Conventions for Virtual Private Network (VPN) Management. B. Schliesser, T. Nadeau. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4265) 4266 The gopher URI Scheme. P. Hoffman. November 2005. (Format: TXT, HTML) (Obsoletes RFC1738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4266) 4267 The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml. M. Froumentin. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4267) 4268 Entity State MIB. S. Chisholm, D. Perkins. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4268) 4269 The SEED Encryption Algorithm. H.J. Lee, S.J. Lee, J.H. Yoon, D.H. Cheon, J.I. Lee. December 2005. (Format: TXT, HTML) (Obsoletes RFC4009) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4269) 4270 Attacks on Cryptographic Hashes in Internet Protocols. P. Hoffman, B. Schneier. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4270) 4271 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed.. January 2006. (Format: TXT, HTML) (Obsoletes RFC1771) (Updated by RFC6286, RFC6608, RFC6793, RFC7606, RFC7607, RFC7705, RFC8212, RFC8654, RFC9072) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4271) 4272 BGP Security Vulnerabilities Analysis. S. Murphy. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4272) 4273 Definitions of Managed Objects for BGP-4. J. Haas, Ed., S. Hares, Ed.. January 2006. (Format: TXT, HTML) (Obsoletes RFC1269, RFC1657) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4273) 4274 BGP-4 Protocol Analysis. D. Meyer, K. Patel. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4274) 4275 BGP-4 MIB Implementation Survey. S. Hares, D. Hares. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4275) 4276 BGP-4 Implementation Report. S. Hares, A. Retana. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4276) 4277 Experience with the BGP-4 Protocol. D. McPherson, K. Patel. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4277) 4278 Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification. S. Bellovin, A. Zinin. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4278) 4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). P. Eronen, Ed., H. Tschofenig, Ed.. December 2005. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4279) 4280 Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers. K. Chowdhury, P. Yegani, L. Madour. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4280) 4281 The Codecs Parameter for "Bucket" Media Types. R. Gellens, D. Singer, P. Frojdh. November 2005. (Format: TXT, HTML) (Obsoleted by RFC6381) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4281) 4282 The Network Access Identifier. B. Aboba, M. Beadles, J. Arkko, P. Eronen. December 2005. (Format: TXT, HTML) (Obsoletes RFC2486) (Obsoleted by RFC7542) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4282) 4283 Mobile Node Identifier Option for Mobile IPv6 (MIPv6). A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4283) 4284 Identity Selection Hints for the Extensible Authentication Protocol (EAP). F. Adrangi, V. Lortz, F. Bari, P. Eronen. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4284) 4285 Authentication Protocol for Mobile IPv6. A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4285) 4286 Multicast Router Discovery. B. Haberman, J. Martin. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4286) 4287 The Atom Syndication Format. M. Nottingham, Ed., R. Sayre, Ed.. December 2005. (Format: TXT, HTML) (Updated by RFC5988) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4287) 4288 Media Type Specifications and Registration Procedures. N. Freed, J. Klensin. December 2005. (Format: TXT, HTML) (Obsoletes RFC2048) (Obsoleted by RFC6838) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4288) 4289 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. N. Freed, J. Klensin. December 2005. (Format: TXT, HTML) (Obsoletes RFC2048) (Also BCP0013) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4289) 4290 Suggested Practices for Registration of Internationalized Domain Names (IDN). J. Klensin. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4290) 4291 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. February 2006. (Format: TXT, HTML) (Obsoletes RFC3513) (Updated by RFC5952, RFC6052, RFC7136, RFC7346, RFC7371, RFC8064) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4291) 4292 IP Forwarding Table MIB. B. Haberman. April 2006. (Format: TXT, HTML) (Obsoletes RFC2096) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4292) 4293 Management Information Base for the Internet Protocol (IP). S. Routhier, Ed.. April 2006. (Format: TXT, HTML) (Obsoletes RFC2011, RFC2465, RFC2466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4293) 4294 IPv6 Node Requirements. J. Loughney, Ed.. April 2006. (Format: TXT, HTML) (Obsoleted by RFC6434) (Updated by RFC5095) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4294) 4295 Mobile IPv6 Management Information Base. G. Keeni, K. Koide, K. Nagami, S. Gundavelli. April 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4295) 4296 The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols. S. Bailey, T. Talpey. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4296) 4297 Remote Direct Memory Access (RDMA) over IP Problem Statement. A. Romanow, J. Mogul, T. Talpey, S. Bailey. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4297) 4298 RTP Payload Format for BroadVoice Speech Codecs. J.-H. Chen, W. Lee, J. Thyssen. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4298) 4299 Not Issued. 4300 Not Issued. 4301 Security Architecture for the Internet Protocol. S. Kent, K. Seo. December 2005. (Format: TXT, HTML) (Obsoletes RFC2401) (Updates RFC3168) (Updated by RFC6040, RFC7619) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4301) 4302 IP Authentication Header. S. Kent. December 2005. (Format: TXT, HTML) (Obsoletes RFC2402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4302) 4303 IP Encapsulating Security Payload (ESP). S. Kent. December 2005. (Format: TXT, HTML) (Obsoletes RFC2406) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4303) 4304 Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP). S. Kent. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4304) 4305 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH). D. Eastlake 3rd. December 2005. (Format: TXT, HTML) (Obsoletes RFC2402, RFC2406) (Obsoleted by RFC4835) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4305) 4306 Internet Key Exchange (IKEv2) Protocol. C. Kaufman, Ed.. December 2005. (Format: TXT, HTML) (Obsoletes RFC2407, RFC2408, RFC2409) (Obsoleted by RFC5996) (Updated by RFC5282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4306) 4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2). J. Schiller. December 2005. (Format: TXT, HTML) (Obsoleted by RFC8247) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4307) 4308 Cryptographic Suites for IPsec. P. Hoffman. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4308) 4309 Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP). R. Housley. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4309) 4310 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP). S. Hollenbeck. December 2005. (Format: TXT, HTML) (Obsoleted by RFC5910) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4310) 4311 IPv6 Host-to-Router Load Sharing. R. Hinden, D. Thaler. November 2005. (Format: TXT, HTML) (Updates RFC2461) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4311) 4312 The Camellia Cipher Algorithm and Its Use With IPsec. A. Kato, S. Moriai, M. Kanda. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4312) 4313 Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources. D. Oran. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4313) 4314 IMAP4 Access Control List (ACL) Extension. A. Melnikov. December 2005. (Format: TXT, HTML) (Obsoletes RFC2086) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4314) 4315 Internet Message Access Protocol (IMAP) - UIDPLUS extension. M. Crispin. December 2005. (Format: TXT, HTML) (Obsoletes RFC2359) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4315) 4316 Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties. J. Reschke. December 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4316) 4317 Session Description Protocol (SDP) Offer/Answer Examples. A. Johnston, R. Sparks. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4317) 4318 Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol. D. Levi, D. Harrington. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4318) 4319 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines. C. Sikes, B. Ray, R. Abbi. December 2005. (Format: TXT, HTML) (Obsoletes RFC3276) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4319) 4320 Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction. R. Sparks. January 2006. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4320) 4321 Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction. R. Sparks. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4321) 4322 Opportunistic Encryption using the Internet Key Exchange (IKE). M. Richardson, D.H. Redelmeier. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4322) 4323 Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB). M. Patrick, W. Murwin. January 2006. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4323) 4324 Calendar Access Protocol (CAP). D. Royer, G. Babics, S. Mansour. December 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4324) 4325 Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension. S. Santesson, R. Housley. December 2005. (Format: TXT, HTML) (Obsoleted by RFC5280) (Updates RFC3280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4325) 4326 Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS). G. Fairhurst, B. Collini-Nocker. December 2005. (Format: TXT, HTML) (Updated by RFC7280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4326) 4327 Link Management Protocol (LMP) Management Information Base (MIB). M. Dubuc, T. Nadeau, J. Lang, E. McGinnis. January 2006. (Format: TXT, HTML) (Obsoleted by RFC4631) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4327) 4328 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control. D. Papadimitriou, Ed.. January 2006. (Format: TXT, HTML) (Updates RFC3471) (Updated by RFC7139) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4328) 4329 Scripting Media Types. B. Hoehrmann. April 2006. (Format: TXT, HTML) (Obsoleted by RFC9239) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4329) 4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. D. Mills. January 2006. (Format: TXT, HTML) (Obsoletes RFC2030, RFC1769) (Obsoleted by RFC5905) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4330) 4331 Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections. B. Korver, L. Dusseault. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4331) 4332 Cisco's Mobile IPv4 Host Configuration Extensions. K. Leung, A. Patel, G. Tsirtsis, E. Klovning. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4332) 4333 The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process. G. Huston, Ed., B. Wijnen, Ed.. December 2005. (Format: TXT, HTML) (Obsoleted by RFC8711) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4333) 4334 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN). R. Housley, T. Moore. February 2006. (Format: TXT, HTML) (Obsoletes RFC3770) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4334) 4335 The Secure Shell (SSH) Session Channel Break Extension. J. Galbraith, P. Remaker. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4335) 4336 Problem Statement for the Datagram Congestion Control Protocol (DCCP). S. Floyd, M. Handley, E. Kohler. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4336) 4337 MIME Type Registration for MPEG-4. Y. Lim, D. Singer. March 2006. (Format: TXT, HTML) (Updated by RFC6381) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4337) 4338 Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel. C. DeSanti, C. Carlson, R. Nixon. January 2006. (Format: TXT, HTML) (Obsoletes RFC3831, RFC2625) (Updated by RFC5494, RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4338) 4339 IPv6 Host Configuration of DNS Server Information Approaches. J. Jeong, Ed.. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4339) 4340 Datagram Congestion Control Protocol (DCCP). E. Kohler, M. Handley, S. Floyd. March 2006. (Format: TXT, HTML) (Updated by RFC5595, RFC5596, RFC6335, RFC6773) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4340) 4341 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control. S. Floyd, E. Kohler. March 2006. (Format: TXT, HTML) (Updated by RFC8311) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4341) 4342 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC). S. Floyd, E. Kohler, J. Padhye. March 2006. (Format: TXT, HTML) (Updated by RFC5348, RFC6323, RFC8311) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4342) 4343 Domain Name System (DNS) Case Insensitivity Clarification. D. Eastlake 3rd. January 2006. (Format: TXT, HTML) (Updates RFC1034, RFC1035, RFC2181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4343) 4344 The Secure Shell (SSH) Transport Layer Encryption Modes. M. Bellare, T. Kohno, C. Namprempre. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4344) 4345 Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol. B. Harris. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4345) 4346 The Transport Layer Security (TLS) Protocol Version 1.1. T. Dierks, E. Rescorla. April 2006. (Format: TXT, HTML) (Obsoletes RFC2246) (Obsoleted by RFC5246) (Updated by RFC4366, RFC4680, RFC4681, RFC5746, RFC6176, RFC7465, RFC7507, RFC7919) (Status: HISTORIC) (DOI: 10.17487/RFC4346) 4347 Datagram Transport Layer Security. E. Rescorla, N. Modadugu. April 2006. (Format: TXT, HTML) (Obsoleted by RFC6347) (Updated by RFC5746, RFC7507) (Status: HISTORIC) (DOI: 10.17487/RFC4347) 4348 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec. S. Ahmadi. January 2006. (Format: TXT, HTML) (Updated by RFC4424) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4348) 4349 High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3). C. Pignataro, M. Townsley. February 2006. (Format: TXT, HTML) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4349) 4350 A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government. F. Hendrikx, C. Wallis. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4350) 4351 Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream. G. Hellstrom, P. Jones. January 2006. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4351) 4352 RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec. J. Sjoberg, M. Westerlund, A. Lakaniemi, S. Wenger. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4352) 4353 A Framework for Conferencing with the Session Initiation Protocol (SIP). J. Rosenberg. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4353) 4354 A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service. M. Garcia-Martin. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4354) 4355 IANA Registration for Enumservices email, fax, mms, ems, and sms. R. Brandner, L. Conroy, R. Stastny. January 2006. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4355) 4356 Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail. R. Gellens. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4356) 4357 Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms. V. Popov, I. Kurepkin, S. Leontiev. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4357) 4358 A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA). D. Smith. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4358) 4359 The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH). B. Weis. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4359) 4360 BGP Extended Communities Attribute. S. Sangli, D. Tappan, Y. Rekhter. February 2006. (Format: TXT, HTML) (Updated by RFC7153, RFC7606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4360) 4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4). T. Lemon, B. Sommerfeld. February 2006. (Format: TXT, HTML) (Updates RFC2131, RFC2132, RFC3315) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4361) 4362 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP. L-E. Jonsson, G. Pelletier, K. Sandlund. January 2006. (Format: TXT, HTML) (Obsoletes RFC3242) (Updated by RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4362) 4363 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions. D. Levi, D. Harrington. January 2006. (Format: TXT, HTML) (Obsoletes RFC2674) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4363) 4364 BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen, Y. Rekhter. February 2006. (Format: TXT, HTML) (Obsoletes RFC2547) (Updated by RFC4577, RFC4684, RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4364) 4365 Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4365) 4366 Transport Layer Security (TLS) Extensions. S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright. April 2006. (Format: TXT, HTML) (Obsoletes RFC3546) (Obsoleted by RFC5246, RFC6066) (Updates RFC4346) (Updated by RFC5746) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4366) 4367 What's in a Name: False Assumptions about DNS Names. J. Rosenberg, Ed., IAB. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4367) 4368 Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition. T. Nadeau, S. Hegde. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4368) 4369 Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP). K. Gibbons, C. Monia, J. Tseng, F. Travostino. January 2006. (Format: TXT, HTML) (Obsoleted by RFC6173) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4369) 4370 Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control. R. Weltman. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4370) 4371 BCP 101 Update for IPR Trust. B. Carpenter, Ed., L. Lynch, Ed.. January 2006. (Format: TXT, HTML) (Obsoleted by RFC8714) (Updates RFC4071) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4371) 4372 Chargeable User Identity. F. Adrangi, A. Lior, J. Korhonen, J. Loughney. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4372) 4373 Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP). R. Harrison, J. Sermersheim, Y. Dong. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4373) 4374 The application/xv+xml Media Type. G. McCobb. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4374) 4375 Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain. K. Carlberg. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4375) 4376 Requirements for Floor Control Protocols. P. Koskelainen, J. Ott, H. Schulzrinne, X. Wu. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4376) 4377 Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks. T. Nadeau, M. Morrow, G. Swallow, D. Allan, S. Matsushima. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4377) 4378 A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM). D. Allan, Ed., T. Nadeau, Ed.. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4378) 4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. K. Kompella, G. Swallow. February 2006. (Format: TXT, HTML) (Obsoleted by RFC8029) (Updates RFC1122) (Updated by RFC5462, RFC6424, RFC6425, RFC6426, RFC6829, RFC7506, RFC7537, RFC7743) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4379) 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs). C. Huitema. February 2006. (Format: TXT, HTML) (Updated by RFC5991, RFC6081) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4380) 4381 Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs). M. Behringer. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4381) 4382 MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base. T. Nadeau, Ed., H. van der Linde, Ed.. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4382) 4383 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP). M. Baugher, E. Carrara. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4383) 4384 BGP Communities for Data Collection. D. Meyer. February 2006. (Format: TXT, HTML) (Also BCP0114) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4384) 4385 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN. S. Bryant, G. Swallow, L. Martini, D. McPherson. February 2006. (Format: TXT, HTML) (Updated by RFC5586) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4385) 4386 Internet X.509 Public Key Infrastructure Repository Locator Service. S. Boeyen, P. Hallam-Baker. February 2006. (Format: TXT, HTML) (Updated by RFC8553) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4386) 4387 Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP. P. Gutmann, Ed.. February 2006. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4387) 4388 Dynamic Host Configuration Protocol (DHCP) Leasequery. R. Woundy, K. Kinnear. February 2006. (Format: TXT, HTML) (Updated by RFC6148) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4388) 4389 Neighbor Discovery Proxies (ND Proxy). D. Thaler, M. Talwar, C. Patel. April 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4389) 4390 Dynamic Host Configuration Protocol (DHCP) over InfiniBand. V. Kashyap. April 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4390) 4391 Transmission of IP over InfiniBand (IPoIB). J. Chu, V. Kashyap. April 2006. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4391) 4392 IP over InfiniBand (IPoIB) Architecture. V. Kashyap. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4392) 4393 MIME Type Registrations for 3GPP2 Multimedia Files. H. Garudadri. March 2006. (Format: TXT, HTML) (Updated by RFC6381) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4393) 4394 A Transport Network View of the Link Management Protocol (LMP). D. Fedyk, O. Aboul-Magd, D. Brungard, J. Lang, D. Papadimitriou. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4394) 4395 Guidelines and Registration Procedures for New URI Schemes. T. Hansen, T. Hardie, L. Masinter. February 2006. (Format: TXT, HTML) (Obsoletes RFC2717, RFC2718) (Obsoleted by RFC7595) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4395) 4396 RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text. J. Rey, Y. Matsui. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4396) 4397 A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture. I. Bryskin, A. Farrel. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4397) 4398 Storing Certificates in the Domain Name System (DNS). S. Josefsson. March 2006. (Format: TXT, HTML) (Obsoletes RFC2538) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4398) 4399 Not Issued. 4400 Not Issued. 4401 A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API). N. Williams. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4401) 4402 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism. N. Williams. February 2006. (Format: TXT, HTML) (Obsoleted by RFC7802) (Status: HISTORIC) (DOI: 10.17487/RFC4402) 4403 Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3). B. Bergeson, K. Boogert, V. Nanjundaswamy. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4403) 4404 Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP). R. Natarajan, A. Rijhsinghani. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4404) 4405 SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message. E. Allman, H. Katz. April 2006. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4405) 4406 Sender ID: Authenticating E-Mail. J. Lyon, M. Wong. April 2006. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4406) 4407 Purported Responsible Address in E-Mail Messages. J. Lyon. April 2006. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4407) 4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1. M. Wong, W. Schlitt. April 2006. (Format: TXT, HTML) (Obsoleted by RFC7208) (Updated by RFC6652) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4408) 4409 Message Submission for Mail. R. Gellens, J. Klensin. April 2006. (Format: TXT, HTML) (Obsoletes RFC2476) (Obsoleted by RFC6409) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4409) 4410 Selectively Reliable Multicast Protocol (SRMP). M. Pullen, F. Zhao, D. Cohen. February 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4410) 4411 Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events. J. Polk. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4411) 4412 Communications Resource Priority for the Session Initiation Protocol (SIP). H. Schulzrinne, J. Polk. February 2006. (Format: TXT, HTML) (Updated by RFC7134) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4412) 4413 TCP/IP Field Behavior. M. West, S. McCann. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4413) 4414 An ENUM Registry Type for the Internet Registry Information Service (IRIS). A. Newton. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4414) 4415 IANA Registration for Enumservice Voice. R. Brandner, L. Conroy, R. Stastny. February 2006. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4415) 4416 Goals for Internet Messaging to Support Diverse Service Environments. J. Wong, Ed.. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4416) 4417 Report of the 2004 IAB Messaging Workshop. P. Resnick, Ed., P. Saint-Andre, Ed.. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4417) 4418 UMAC: Message Authentication Code using Universal Hashing. T. Krovetz, Ed.. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4418) 4419 Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol. M. Friedl, N. Provos, W. Simpson. March 2006. (Format: TXT, HTML) (Updated by RFC8270) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4419) 4420 Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE). A. Farrel, Ed., D. Papadimitriou, J.-P. Vasseur, A. Ayyangar. February 2006. (Format: TXT, HTML) (Obsoleted by RFC5420) (Updates RFC3209, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4420) 4421 RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes. C. Perkins. February 2006. (Format: TXT, HTML) (Updates RFC4175) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4421) 4422 Simple Authentication and Security Layer (SASL). A. Melnikov, Ed., K. Zeilenga, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4422) 4423 Host Identity Protocol (HIP) Architecture. R. Moskowitz, P. Nikander. May 2006. (Format: TXT, HTML) (Obsoleted by RFC9063) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4423) 4424 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec. S. Ahmadi. February 2006. (Format: TXT, HTML) (Updates RFC4348) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4424) 4425 RTP Payload Format for Video Codec 1 (VC-1). A. Klemets. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4425) 4426 Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification. J. Lang, Ed., B. Rajagopalan, Ed., D. Papadimitriou, Ed.. March 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4426) 4427 Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS). E. Mannie, Ed., D. Papadimitriou, Ed.. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4427) 4428 Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration). D. Papadimitriou, Ed., E. Mannie, Ed.. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4428) 4429 Optimistic Duplicate Address Detection (DAD) for IPv6. N. Moore. April 2006. (Format: TXT, HTML) (Updated by RFC7527) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4429) 4430 Kerberized Internet Negotiation of Keys (KINK). S. Sakane, K. Kamada, M. Thomas, J. Vilhuber. March 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4430) 4431 The DNSSEC Lookaside Validation (DLV) DNS Resource Record. M. Andrews, S. Weiler. February 2006. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4431) 4432 RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol. B. Harris. March 2006. (Format: TXT, HTML) (Updated by RFC9142) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4432) 4433 Mobile IPv4 Dynamic Home Agent (HA) Assignment. M. Kulkarni, A. Patel, K. Leung. March 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4433) 4434 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE). P. Hoffman. February 2006. (Format: TXT, HTML) (Obsoletes RFC3664) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4434) 4435 A Framework for the Usage of Internet Media Guides (IMGs). Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, H. Schulzrinne. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4435) 4436 Detecting Network Attachment in IPv4 (DNAv4). B. Aboba, J. Carlson, S. Cheshire. March 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4436) 4437 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources. J. Whitehead, G. Clemm, J. Reschke, Ed.. March 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4437) 4438 Fibre-Channel Name Server MIB. C. DeSanti, V. Gaonkar, H.K. Vivek, K. McCloghrie, S. Gai. April 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4438) 4439 Fibre Channel Fabric Address Manager MIB. C. DeSanti, V. Gaonkar, K. McCloghrie, S. Gai. March 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4439) 4440 IAB Thoughts on the Role of the Internet Research Task Force (IRTF). S. Floyd, Ed., V. Paxson, Ed., A. Falk, Ed., IAB. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4440) 4441 The IEEE 802/IETF Relationship. B. Aboba, Ed.. March 2006. (Format: TXT, HTML) (Obsoleted by RFC7241) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4441) 4442 Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA). S. Fries, H. Tschofenig. March 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4442) 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering, M. Gupta, Ed.. March 2006. (Format: TXT, HTML) (Obsoletes RFC2463) (Updates RFC2780) (Updated by RFC4884) (Also STD0089) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC4443) 4444 Management Information Base for Intermediate System to Intermediate System (IS-IS). J. Parker, Ed.. April 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4444) 4445 A Proposed Media Delivery Index (MDI). J. Welch, J. Clark. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4445) 4446 IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3). L. Martini. April 2006. (Format: TXT, HTML) (Also BCP0116) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4446) 4447 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP). L. Martini, Ed., E. Rosen, N. El-Aawar, T. Smith, G. Heron. April 2006. (Format: TXT, HTML) (Obsoleted by RFC8077) (Updated by RFC6723, RFC6870, RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4447) 4448 Encapsulation Methods for Transport of Ethernet over MPLS Networks. L. Martini, Ed., E. Rosen, N. El-Aawar, G. Heron. April 2006. (Format: TXT, HTML) (Updated by RFC5462, RFC8469) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4448) 4449 Securing Mobile IPv6 Route Optimization Using a Static Shared Key. C. Perkins. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4449) 4450 Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents. E. Lear, H. Alvestrand. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4450) 4451 BGP MULTI_EXIT_DISC (MED) Considerations. D. McPherson, V. Gill. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4451) 4452 The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces. H. Van de Sompel, T. Hammond, E. Neylon, S. Weibel. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4452) 4453 Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP). J. Rosenberg, G. Camarillo, Ed., D. Willis. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4453) 4454 Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3). S. Singh, M. Townsley, C. Pignataro. May 2006. (Format: TXT, HTML) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4454) 4455 Definition of Managed Objects for Small Computer System Interface (SCSI) Entities. M. Hallak-Stamler, M. Bakke, Y. Lederman, M. Krueger, K. McCloghrie. April 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4455) 4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP). T. Bates, E. Chen, R. Chandra. April 2006. (Format: TXT, HTML) (Obsoletes RFC2796, RFC1966) (Updated by RFC7606) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4456) 4457 The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header). G. Camarillo, G. Blanco. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4457) 4458 Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR). C. Jennings, F. Audet, J. Elwell. April 2006. (Format: TXT, HTML) (Updated by RFC8119) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4458) 4459 MTU and Fragmentation Issues with In-the-Network Tunneling. P. Savola. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4459) 4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues. R. Stewart, I. Arias-Rodriguez, K. Poon, A. Caro, M. Tuexen. April 2006. (Format: TXT, HTML) (Obsoleted by RFC9260) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4460) 4461 Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs). S. Yasukawa, Ed.. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4461) 4462 Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol. J. Hutzelman, J. Salowey, J. Galbraith, V. Welch. May 2006. (Format: TXT, HTML) (Updated by RFC8732, RFC9142) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4462) 4463 A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks. S. Shanmugham, P. Monaco, B. Eberman. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4463) 4464 Signaling Compression (SigComp) Users' Guide. A. Surtees, M. West. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4464) 4465 Signaling Compression (SigComp) Torture Tests. A. Surtees, M. West. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4465) 4466 Collected Extensions to IMAP4 ABNF. A. Melnikov, C. Daboo. April 2006. (Format: TXT, HTML) (Updates RFC2088, RFC2342, RFC3501, RFC3502, RFC3516) (Updated by RFC6237, RFC7377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4466) 4467 Internet Message Access Protocol (IMAP) - URLAUTH Extension. M. Crispin. May 2006. (Format: TXT, HTML) (Updated by RFC5092, RFC5550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4467) 4468 Message Submission BURL Extension. C. Newman. May 2006. (Format: TXT, HTML) (Updates RFC3463) (Updated by RFC5248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4468) 4469 Internet Message Access Protocol (IMAP) CATENATE Extension. P. Resnick. April 2006. (Format: TXT, HTML) (Updates RFC3501, RFC3502) (Updated by RFC5550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4469) 4470 Minimally Covering NSEC Records and DNSSEC On-line Signing. S. Weiler, J. Ihren. April 2006. (Format: TXT, HTML) (Updates RFC4035, RFC4034) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4470) 4471 Derivation of DNS Name Predecessor and Successor. G. Sisson, B. Laurie. September 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4471) 4472 Operational Considerations and Issues with IPv6 DNS. A. Durand, J. Ihren, P. Savola. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4472) 4473 Requirements for Internet Media Guides (IMGs). Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H. Schulzrinne. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4473) 4474 Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP). J. Peterson, C. Jennings. August 2006. (Format: TXT, HTML) (Obsoleted by RFC8224) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4474) 4475 Session Initiation Protocol (SIP) Torture Test Messages. R. Sparks, Ed., A. Hawrylyshen, A. Johnston, J. Rosenberg, H. Schulzrinne. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4475) 4476 Attribute Certificate (AC) Policies Extension. C. Francis, D. Pinkas. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4476) 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues. T. Chown, S. Venaas, C. Strauf. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4477) 4478 Repeated Authentication in Internet Key Exchange (IKEv2) Protocol. Y. Nir. April 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4478) 4479 A Data Model for Presence. J. Rosenberg. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4479) 4480 RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF). H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4480) 4481 Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals. H. Schulzrinne. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4481) 4482 CIPID: Contact Information for the Presence Information Data Format. H. Schulzrinne. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4482) 4483 A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages. E. Burger, Ed.. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4483) 4484 Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP). J. Peterson, J. Polk, D. Sicker, H. Tschofenig. August 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4484) 4485 Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4485) 4486 Subcodes for BGP Cease Notification Message. E. Chen, V. Gillet. April 2006. (Format: TXT, HTML) (Updated by RFC8203, RFC9003) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4486) 4487 Mobile IPv6 and Firewalls: Problem Statement. F. Le, S. Faccin, B. Patil, H. Tschofenig. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4487) 4488 Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription. O. Levin. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4488) 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses. J-S. Park, M-K. Shin, H-J. Kim. April 2006. (Format: TXT, HTML) (Updates RFC3306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4489) 4490 Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS). S. Leontiev, Ed., G. Chudov, Ed.. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4490) 4491 Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S. Leontiev, Ed., D. Shefanovski, Ed.. May 2006. (Format: TXT, HTML) (Updates RFC3279) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4491) 4492 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS). S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller. May 2006. (Format: TXT, HTML) (Obsoleted by RFC8422) (Updated by RFC5246, RFC7027, RFC7919) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4492) 4493 The AES-CMAC Algorithm. JH. Song, R. Poovendran, J. Lee, T. Iwata. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4493) 4494 The AES-CMAC-96 Algorithm and Its Use with IPsec. JH. Song, R. Poovendran, J. Lee. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4494) 4495 A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow. J. Polk, S. Dhesikan. May 2006. (Format: TXT, HTML) (Updates RFC2205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4495) 4496 Open Pluggable Edge Services (OPES) SMTP Use Cases. M. Stecher, A. Barbir. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4496) 4497 Interworking between the Session Initiation Protocol (SIP) and QSIG. J. Elwell, F. Derks, P. Mourot, O. Rousseau. May 2006. (Format: TXT, HTML) (Updated by RFC8996) (Also BCP0117) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4497) 4498 The Managed Object Aggregation MIB. G. Keeni. May 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4498) 4499 Not Issued. 4500 Not Issued. 4501 Domain Name System Uniform Resource Identifiers. S. Josefsson. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4501) 4502 Remote Network Monitoring Management Information Base Version 2. S. Waldbusser. May 2006. (Format: TXT, HTML) (Obsoletes RFC2021) (Updates RFC3273) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4502) 4503 A Description of the Rabbit Stream Cipher Algorithm. M. Boesgaard, M. Vesterager, E. Zenner. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4503) 4504 SIP Telephony Device Requirements and Configuration. H. Sinnreich, Ed., S. Lass, C. Stredicke. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4504) 4505 Anonymous Simple Authentication and Security Layer (SASL) Mechanism. K. Zeilenga. June 2006. (Format: TXT, HTML) (Obsoletes RFC2245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4505) 4506 XDR: External Data Representation Standard. M. Eisler, Ed.. May 2006. (Format: TXT, HTML) (Obsoletes RFC1832) (Also STD0067) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC4506) 4507 Transport Layer Security (TLS) Session Resumption without Server-Side State. J. Salowey, H. Zhou, P. Eronen, H. Tschofenig. May 2006. (Format: TXT, HTML) (Obsoleted by RFC5077) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4507) 4508 Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method. O. Levin, A. Johnston. May 2006. (Format: TXT, HTML) (Updated by RFC8217) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4508) 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs). W. Hardaker. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4509) 4510 Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map. K. Zeilenga, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2251, RFC2252, RFC2253, RFC2254, RFC2255, RFC2256, RFC2829, RFC2830, RFC3377, RFC3771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4510) 4511 Lightweight Directory Access Protocol (LDAP): The Protocol. J. Sermersheim, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2251, RFC2830, RFC3771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4511) 4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models. K. Zeilenga, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2251, RFC2252, RFC2256, RFC3674) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4512) 4513 Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms. R. Harrison, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2251, RFC2829, RFC2830) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4513) 4514 Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names. K. Zeilenga, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4514) 4515 Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters. M. Smith, Ed., T. Howes. June 2006. (Format: TXT, HTML) (Obsoletes RFC2254) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4515) 4516 Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator. M. Smith, Ed., T. Howes. June 2006. (Format: TXT, HTML) (Obsoletes RFC2255) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4516) 4517 Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules. S. Legg, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2252, RFC2256) (Updates RFC3698) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4517) 4518 Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4518) 4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications. A. Sciberras, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2256) (Updates RFC2247, RFC2798, RFC2377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4519) 4520 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. June 2006. (Format: TXT, HTML) (Obsoletes RFC3383) (Also BCP0064) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4520) 4521 Considerations for Lightweight Directory Access Protocol (LDAP) Extensions. K. Zeilenga. June 2006. (Format: TXT, HTML) (Also BCP0118) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4521) 4522 Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option. S. Legg. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4522) 4523 Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates. K. Zeilenga. June 2006. (Format: TXT, HTML) (Obsoletes RFC2252, RFC2256, RFC2587) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4523) 4524 COSINE LDAP/X.500 Schema. K. Zeilenga, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC1274) (Updates RFC2247, RFC2798) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4524) 4525 Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4525) 4526 Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4526) 4527 Lightweight Directory Access Protocol (LDAP) Read Entry Controls. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4527) 4528 Lightweight Directory Access Protocol (LDAP) Assertion Control. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4528) 4529 Requesting Attributes by Object Class in the Lightweight Directory Access Protocol. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4529) 4530 Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4530) 4531 Lightweight Directory Access Protocol (LDAP) Turn Operation. K. Zeilenga. June 2006. (Format: TXT, HTML) (Updated by RFC8996) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4531) 4532 Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4532) 4533 The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation. K. Zeilenga, J.H. Choi. June 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4533) 4534 Group Security Policy Token v1. A. Colegrove, H. Harney. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4534) 4535 GSAKMP: Group Secure Association Key Management Protocol. H. Harney, U. Meth, A. Colegrove, G. Gross. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4535) 4536 The application/smil and application/smil+xml Media Types. P. Hoschka. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4536) 4537 Kerberos Cryptosystem Negotiation Extension. L. Zhu, P. Leach, K. Jaganathan. June 2006. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4537) 4538 Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP). J. Rosenberg. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4538) 4539 Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF). T. Edwards. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4539) 4540 NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0. M. Stiemerling, J. Quittek, C. Cadar. May 2006. (Format: TXT, HTML) (Updated by RFC8996) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4540) 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches. M. Christensen, K. Kimball, F. Solensky. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4541) 4542 Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite. F. Baker, J. Polk. May 2006. (Format: TXT, HTML) (Updated by RFC5865) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4542) 4543 The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH. D. McGrew, J. Viega. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4543) 4544 Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI). M. Bakke, M. Krueger, T. McSweeney, J. Muchow. May 2006. (Format: TXT, HTML) (Obsoleted by RFC7147) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4544) 4545 Definitions of Managed Objects for IP Storage User Identity Authorization. M. Bakke, J. Muchow. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4545) 4546 Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces. D. Raftus, E. Cardona. June 2006. (Format: TXT, HTML) (Obsoletes RFC2670) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4546) 4547 Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems. A. Ahmad, G. Nakanishi. June 2006. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4547) 4548 Internet Code Point (ICP) Assignments for NSAP Addresses. E. Gray, J. Rutemiller, G. Swallow. May 2006. (Format: TXT, HTML) (Updates RFC1888, RFC4048) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4548) 4549 Synchronization Operations for Disconnected IMAP4 Clients. A. Melnikov, Ed.. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4549) 4550 Internet Email to Support Diverse Service Environments (Lemonade) Profile. S. Maes, A. Melnikov. June 2006. (Format: TXT, HTML) (Obsoleted by RFC5550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4550) 4551 IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization. A. Melnikov, S. Hole. June 2006. (Format: TXT, HTML) (Obsoleted by RFC7162) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4551) 4552 Authentication/Confidentiality for OSPFv3. M. Gupta, N. Melam. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4552) 4553 Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP). A. Vainshtein, Ed., YJ. Stein, Ed.. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4553) 4554 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks. T. Chown. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4554) 4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE). P. Eronen. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4555) 4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). L. Zhu, B. Tung. June 2006. (Format: TXT, HTML) (Updated by RFC6112, RFC8062, RFC8636) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4556) 4557 Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). L. Zhu, K. Jaganathan, N. Williams. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4557) 4558 Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement. Z. Ali, R. Rahman, D. Prairie, D. Papadimitriou. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4558) 4559 SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows. K. Jaganathan, L. Zhu, J. Brezak. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4559) 4560 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations. J. Quittek, Ed., K. White, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2925) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4560) 4561 Definition of a Record Route Object (RRO) Node-Id Sub-Object. J.-P. Vasseur, Ed., Z. Ali, S. Sivabalan. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4561) 4562 MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network. T. Melsen, S. Blake. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4562) 4563 The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY). E. Carrara, V. Lehtovirta, K. Norrman. June 2006. (Format: TXT, HTML) (Updated by RFC6309) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4563) 4564 Objectives for Control and Provisioning of Wireless Access Points (CAPWAP). S. Govindan, Ed., H. Cheng, ZH. Yao, WH. Zhou, L. Yang. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4564) 4565 Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols. D. Loher, D. Nelson, O. Volinsky, B. Sarikaya. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4565) 4566 SDP: Session Description Protocol. M. Handley, V. Jacobson, C. Perkins. July 2006. (Format: TXT, HTML) (Obsoletes RFC2327, RFC3266) (Obsoleted by RFC8866) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4566) 4567 Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP). J. Arkko, F. Lindholm, M. Naslund, K. Norrman, E. Carrara. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4567) 4568 Session Description Protocol (SDP) Security Descriptions for Media Streams. F. Andreasen, M. Baugher, D. Wing. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4568) 4569 Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag. G. Camarillo. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4569) 4570 Session Description Protocol (SDP) Source Filters. B. Quinn, R. Finlayson. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4570) 4571 Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport. J. Lazzaro. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4571) 4572 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP). J. Lennox. July 2006. (Format: TXT, HTML) (Obsoleted by RFC8122) (Updates RFC4145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4572) 4573 MIME Type Registration for RTP Payload Format for H.224. R. Even, A. Lochbaum. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4573) 4574 The Session Description Protocol (SDP) Label Attribute. O. Levin, G. Camarillo. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4574) 4575 A Session Initiation Protocol (SIP) Event Package for Conference State. J. Rosenberg, H. Schulzrinne, O. Levin, Ed.. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4575) 4576 Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen, P. Psenak, P. Pillay-Esnault. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4576) 4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen, P. Psenak, P. Pillay-Esnault. June 2006. (Format: TXT, HTML) (Updates RFC4364) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4577) 4578 Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE). M. Johnston, S. Venaas, Ed.. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4578) 4579 Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents. A. Johnston, O. Levin. August 2006. (Format: TXT, HTML) (Also BCP0119) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4579) 4580 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option. B. Volz. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4580) 4581 Cryptographically Generated Addresses (CGA) Extension Field Format. M. Bagnulo, J. Arkko. October 2006. (Format: TXT, HTML) (Updates RFC3972) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4581) 4582 The Binary Floor Control Protocol (BFCP). G. Camarillo, J. Ott, K. Drage. November 2006. (Format: TXT, HTML) (Obsoleted by RFC8855) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4582) 4583 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams. G. Camarillo. November 2006. (Format: TXT, HTML) (Obsoleted by RFC8856) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4583) 4584 Extension to Sockets API for Mobile IPv6. S. Chakrabarti, E. Nordmark. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4584) 4585 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF). J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey. July 2006. (Format: TXT, HTML) (Updated by RFC5506, RFC8108) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4585) 4586 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations. C. Burmeister, R. Hakenberg, A. Miyazaki, J. Ott, N. Sato, S. Fukunaga. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4586) 4587 RTP Payload Format for H.261 Video Streams. R. Even. August 2006. (Format: TXT, HTML) (Obsoletes RFC2032) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4587) 4588 RTP Retransmission Payload Format. J. Rey, D. Leon, A. Miyazaki, V. Varsa, R. Hakenberg. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4588) 4589 Location Types Registry. H. Schulzrinne, H. Tschofenig. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4589) 4590 RADIUS Extension for Digest Authentication. B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck. July 2006. (Format: TXT, HTML) (Obsoleted by RFC5090) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4590) 4591 Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3). M. Townsley, G. Wilkie, S. Booth, S. Bryant, J. Lau. August 2006. (Format: TXT, HTML) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4591) 4592 The Role of Wildcards in the Domain Name System. E. Lewis. July 2006. (Format: TXT, HTML) (Updates RFC1034, RFC2672) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4592) 4593 Generic Threats to Routing Protocols. A. Barbir, S. Murphy, Y. Yang. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4593) 4594 Configuration Guidelines for DiffServ Service Classes. J. Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT, HTML) (Updated by RFC5865, RFC8622) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4594) 4595 Use of IKEv2 in the Fibre Channel Security Association Management Protocol. F. Maino, D. Black. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4595) 4596 Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension. J. Rosenberg, P. Kyzivat. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4596) 4597 Conferencing Scenarios. R. Even, N. Ismail. August 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4597) 4598 Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio. B. Link. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4598) 4599 Not Issued. 4600 Not Issued. 4601 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). B. Fenner, M. Handley, H. Holbrook, I. Kouvelas. August 2006. (Format: TXT, PDF, HTML) (Obsoletes RFC2362) (Obsoleted by RFC7761) (Updated by RFC5059, RFC5796, RFC6226) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4601) 4602 Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis. T. Pusateri. August 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4602) 4603 Additional Values for the NAS-Port-Type Attribute. G. Zorn, G. Weber, R. Foltak. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4603) 4604 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast. H. Holbrook, B. Cain, B. Haberman. August 2006. (Format: TXT, HTML) (Updates RFC3376, RFC3810) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4604) 4605 Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying"). B. Fenner, H. He, B. Haberman, H. Sandick. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4605) 4606 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control. E. Mannie, D. Papadimitriou. August 2006. (Format: TXT, HTML) (Obsoletes RFC3946) (Updated by RFC6344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4606) 4607 Source-Specific Multicast for IP. H. Holbrook, B. Cain. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4607) 4608 Source-Specific Protocol Independent Multicast in 232/8. D. Meyer, R. Rockell, G. Shepherd. August 2006. (Format: TXT, HTML) (Also BCP0120) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4608) 4609 Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements. P. Savola, R. Lehtonen, D. Meyer. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4609) 4610 Anycast-RP Using Protocol Independent Multicast (PIM). D. Farinacci, Y. Cai. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4610) 4611 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios. M. McBride, J. Meylor, D. Meyer. August 2006. (Format: TXT, HTML) (Also BCP0121) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4611) 4612 Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration. P. Jones, H. Tamura. August 2006. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4612) 4613 Media Type Registrations for Downloadable Sounds for Musical Instrument Digital Interface (MIDI). P. Frojdh, U. Lindgren, M. Westerlund. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4613) 4614 A Roadmap for Transmission Control Protocol (TCP) Specification Documents. M. Duke, R. Braden, W. Eddy, E. Blanton. September 2006. (Format: TXT, HTML) (Obsoleted by RFC7414) (Updated by RFC6247) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4614) 4615 The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE). J. Song, R. Poovendran, J. Lee, T. Iwata. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4615) 4616 The PLAIN Simple Authentication and Security Layer (SASL) Mechanism. K. Zeilenga, Ed.. August 2006. (Format: TXT, HTML) (Updates RFC2595) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4616) 4617 A Uniform Resource Name (URN) Formal Namespace for the Latvian National Government Integration Project. J. Kornijenko. August 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4617) 4618 Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks. L. Martini, E. Rosen, G. Heron, A. Malis. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4618) 4619 Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks. L. Martini, Ed., C. Kawa, Ed., A. Malis, Ed.. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4619) 4620 IPv6 Node Information Queries. M. Crawford, B. Haberman, Ed.. August 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4620) 4621 Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol. T. Kivinen, H. Tschofenig. August 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4621) 4622 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre. July 2006. (Format: TXT, HTML) (Obsoleted by RFC5122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4622) 4623 Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly. A. Malis, M. Townsley. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4623) 4624 Multicast Source Discovery Protocol (MSDP) MIB. B. Fenner, D. Thaler. October 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4624) 4625 Fibre Channel Routing Information MIB. C. DeSanti, K. McCloghrie, S. Kode, S. Gai. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4625) 4626 MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol. C. DeSanti, V. Gaonkar, K. McCloghrie, S. Gai. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4626) 4627 The application/json Media Type for JavaScript Object Notation (JSON). D. Crockford. July 2006. (Format: TXT, HTML) (Obsoleted by RFC7159) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4627) 4628 RTP Payload Format for H.263 Moving RFC 2190 to Historic Status. R. Even. January 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4628) 4629 RTP Payload Format for ITU-T Rec. H.263 Video. J. Ott, C. Bormann, G. Sullivan, S. Wenger, R. Even, Ed.. January 2007. (Format: TXT, HTML) (Obsoletes RFC2429) (Updates RFC3555) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4629) 4630 Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. R. Housley, S. Santesson. August 2006. (Format: TXT, HTML) (Obsoleted by RFC5280) (Updates RFC3280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4630) 4631 Link Management Protocol (LMP) Management Information Base (MIB). M. Dubuc, T. Nadeau, J. Lang, E. McGinnis, A. Farrel. September 2006. (Format: TXT, HTML) (Obsoletes RFC4327) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4631) 4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. V. Fuller, T. Li. August 2006. (Format: TXT, HTML) (Obsoletes RFC1519) (Also BCP0122) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4632) 4633 Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists. S. Hartman. August 2006. (Format: TXT, HTML) (Updated by RFC8717) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4633) 4634 US Secure Hash Algorithms (SHA and HMAC-SHA). D. Eastlake 3rd, T. Hansen. July 2006. (Format: TXT, HTML) (Obsoleted by RFC6234) (Updates RFC3174) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4634) 4635 HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers. D. Eastlake 3rd. August 2006. (Format: TXT, HTML) (Obsoleted by RFC8945) (Updates RFC2845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4635) 4636 Foreign Agent Error Extension for Mobile IPv4. C. Perkins. October 2006. (Format: TXT, HTML) (Updates RFC3344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4636) 4637 Not Issued. 4638 Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE). P. Arberg, D. Kourkouzelis, M. Duckett, T. Anschutz, J. Moisand. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4638) 4639 Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems. R. Woundy, K. Marez. December 2006. (Format: TXT, HTML) (Obsoletes RFC2669) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4639) 4640 Problem Statement for bootstrapping Mobile IPv6 (MIPv6). A. Patel, Ed., G. Giaretta, Ed.. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4640) 4641 DNSSEC Operational Practices. O. Kolkman, R. Gieben. September 2006. (Format: TXT, HTML) (Obsoletes RFC2541) (Obsoleted by RFC6781) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4641) 4642 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP). K. Murchison, J. Vinocur, C. Newman. October 2006. (Format: TXT, HTML) (Updated by RFC8143, RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4642) 4643 Network News Transfer Protocol (NNTP) Extension for Authentication. J. Vinocur, K. Murchison. October 2006. (Format: TXT, HTML) (Updates RFC2980) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4643) 4644 Network News Transfer Protocol (NNTP) Extension for Streaming Feeds. J. Vinocur, K. Murchison. October 2006. (Format: TXT, HTML) (Updates RFC2980) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4644) 4645 Initial Language Subtag Registry. D. Ewell. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4645) 4646 Tags for Identifying Languages. A. Phillips, M. Davis. September 2006. (Format: TXT, HTML) (Obsoletes RFC3066) (Obsoleted by RFC5646) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4646) 4647 Matching of Language Tags. A. Phillips, Ed., M. Davis, Ed.. September 2006. (Format: TXT, HTML) (Obsoletes RFC3066) (Also BCP0047) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4647) 4648 The Base16, Base32, and Base64 Data Encodings. S. Josefsson. October 2006. (Format: TXT, HTML) (Obsoletes RFC3548) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4648) 4649 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option. B. Volz. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4649) 4650 HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY). M. Euchner. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4650) 4651 A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization. C. Vogt, J. Arkko. February 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4651) 4652 Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements. D. Papadimitriou, Ed., L. Ong, J. Sadler, S. Shew, D. Ward. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4652) 4653 Improving the Robustness of TCP to Non-Congestion Events. S. Bhandarkar, A. L. N. Reddy, M. Allman, E. Blanton. August 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4653) 4654 TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification. J. Widmer, M. Handley. August 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4654) 4655 A Path Computation Element (PCE)-Based Architecture. A. Farrel, J.-P. Vasseur, J. Ash. August 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4655) 4656 A One-way Active Measurement Protocol (OWAMP). S. Shalunov, B. Teitelbaum, A. Karp, J. Boote, M. Zekauskas. September 2006. (Format: TXT, HTML) (Updated by RFC7717, RFC7718, RFC8545) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4656) 4657 Path Computation Element (PCE) Communication Protocol Generic Requirements. J. Ash, Ed., J.L. Le Roux, Ed.. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4657) 4658 Not Issued. 4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN. J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4659) 4660 Functional Description of Event Notification Filtering. H. Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena. September 2006. (Format: TXT, HTML) (Updated by RFC6665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4660) 4661 An Extensible Markup Language (XML)-Based Format for Event Notification Filtering. H. Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4661) 4662 A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists. A. B. Roach, B. Campbell, J. Rosenberg. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4662) 4663 Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG. D. Harrington. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4663) 4664 Framework for Layer 2 Virtual Private Networks (L2VPNs). L. Andersson, Ed., E. Rosen, Ed.. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4664) 4665 Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks. W. Augustyn, Ed., Y. Serbest, Ed.. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4665) 4666 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA). K. Morneault, Ed., J. Pastor-Balbas, Ed.. September 2006. (Format: TXT, HTML) (Obsoletes RFC3332) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4666) 4667 Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP). W. Luo. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4667) 4668 RADIUS Authentication Client MIB for IPv6. D. Nelson. August 2006. (Format: TXT, HTML) (Obsoletes RFC2618) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4668) 4669 RADIUS Authentication Server MIB for IPv6. D. Nelson. August 2006. (Format: TXT, HTML) (Obsoletes RFC2619) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4669) 4670 RADIUS Accounting Client MIB for IPv6. D. Nelson. August 2006. (Format: TXT, HTML) (Obsoletes RFC2620) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4670) 4671 RADIUS Accounting Server MIB for IPv6. D. Nelson. August 2006. (Format: TXT, HTML) (Obsoletes RFC2621) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4671) 4672 RADIUS Dynamic Authorization Client MIB. S. De Cnodder, N. Jonnala, M. Chiba. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4672) 4673 RADIUS Dynamic Authorization Server MIB. S. De Cnodder, N. Jonnala, M. Chiba. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4673) 4674 Requirements for Path Computation Element (PCE) Discovery. J.L. Le Roux, Ed.. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4674) 4675 RADIUS Attributes for Virtual LAN and Priority Support. P. Congdon, M. Sanchez, B. Aboba. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4675) 4676 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information. H. Schulzrinne. October 2006. (Format: TXT, HTML) (Obsoleted by RFC4776) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4676) 4677 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force. P. Hoffman, S. Harris. September 2006. (Format: TXT, HTML) (Obsoletes RFC3160) (Obsoleted by RFC6722) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4677) 4678 Server/Application State Protocol v1. A. Bivens. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4678) 4679 DSL Forum Vendor-Specific RADIUS Attributes. V. Mammoliti, G. Zorn, P. Arberg, R. Rennison. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4679) 4680 TLS Handshake Message for Supplemental Data. S. Santesson. October 2006. (Format: TXT, HTML) (Updates RFC4346) (Updated by RFC8447, RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4680) 4681 TLS User Mapping Extension. S. Santesson, A. Medvinsky, J. Ball. October 2006. (Format: TXT, HTML) (Updates RFC4346) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4681) 4682 Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices. E. Nechamkin, J-F. Mule. December 2006. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4682) 4683 Internet X.509 Public Key Infrastructure Subject Identification Method (SIM). J. Park, J. Lee, H. Lee, S. Park, T. Polk. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4683) 4684 Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs). P. Marques, R. Bonica, L. Fang, L. Martini, R. Raszuk, K. Patel, J. Guichard. November 2006. (Format: TXT, HTML) (Updates RFC4364) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4684) 4685 Atom Threading Extensions. J. Snell. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4685) 4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM). J. Fenton. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4686) 4687 Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks. S. Yasukawa, A. Farrel, D. King, T. Nadeau. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4687) 4688 A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D. S. Rushing. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4688) 4689 Terminology for Benchmarking Network-layer Traffic Control Mechanisms. S. Poretsky, J. Perser, S. Erramilli, S. Khurana. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4689) 4690 Review and Recommendations for Internationalized Domain Names (IDNs). J. Klensin, P. Faltstrom, C. Karp, IAB. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4690) 4691 Guidelines for Acting as an IETF Liaison to Another Organization. L. Andersson, Ed.. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4691) 4692 Considerations on the IPv6 Host Density Metric. G. Huston. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4692) 4693 IETF Operational Notes. H. Alvestrand. October 2006. (Format: TXT, HTML) (Obsoleted by RFC6393) (Status: HISTORIC) (DOI: 10.17487/RFC4693) 4694 Number Portability Parameters for the "tel" URI. J. Yu. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4694) 4695 RTP Payload Format for MIDI. J. Lazzaro, J. Wawrzynek. November 2006. (Format: TXT, HTML) (Obsoleted by RFC6295) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4695) 4696 An Implementation Guide for RTP MIDI. J. Lazzaro, J. Wawrzynek. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4696) 4697 Observed DNS Resolution Misbehavior. M. Larson, P. Barber. October 2006. (Format: TXT, HTML) (Also BCP0123) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4697) 4698 IRIS: An Address Registry (areg) Type for the Internet Registry Information Service. E. Gunduz, A. Newton, S. Kerr. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4698) 4699 Not Issued. 4700 Not Issued. 4701 A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR). M. Stapp, T. Lemon, A. Gustafsson. October 2006. (Format: TXT, HTML) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4701) 4702 The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option. M. Stapp, B. Volz, Y. Rekhter. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4702) 4703 Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients. M. Stapp, B. Volz. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4703) 4704 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option. B. Volz. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4704) 4705 GigaBeam High-Speed Radio Link Encryption. R. Housley, A. Corry. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4705) 4706 Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2). M. Morgenstern, M. Dodge, S. Baillie, U. Bonollo. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4706) 4707 Netnews Administration System (NAS). P. Grau, V. Heinau, H. Schlichting, R. Schuettler. October 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4707) 4708 CellML Media Type. A. Miller. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4708) 4709 Mounting Web Distributed Authoring and Versioning (WebDAV) Servers. J. Reschke. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4709) 4710 Real-time Application Quality-of-Service Monitoring (RAQMON) Framework. A. Siddiqui, D. Romascanu, E. Golovinsky. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4710) 4711 Real-time Application Quality-of-Service Monitoring (RAQMON) MIB. A. Siddiqui, D. Romascanu, E. Golovinsky. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4711) 4712 Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU). A. Siddiqui, D. Romascanu, E. Golovinsky, M. Rahman, Y. Kim. October 2006. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4712) 4713 Registration and Administration Recommendations for Chinese Domain Names. X. Lee, W. Mao, E. Chen, N. Hsu, J. Klensin. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4713) 4714 Requirements for IETF Technical Publication Service. A. Mankin, S. Hayes. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4714) 4715 The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI. M. Munakata, S. Schubert, T. Ohba. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4715) 4716 The Secure Shell (SSH) Public Key File Format. J. Galbraith, R. Thayer. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4716) 4717 Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks. L. Martini, J. Jayakumar, M. Bocci, N. El-Aawar, J. Brayley, G. Koleyni. December 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4717) 4718 IKEv2 Clarifications and Implementation Guidelines. P. Eronen, P. Hoffman. October 2006. (Format: TXT, HTML) (Obsoleted by RFC5996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4718) 4719 Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3). R. Aggarwal, Ed., M. Townsley, Ed., M. Dos Santos, Ed.. November 2006. (Format: TXT, HTML) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4719) 4720 Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention. A. Malis, D. Allan, N. Del Regno. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4720) 4721 Mobile IPv4 Challenge/Response Extensions (Revised). C. Perkins, P. Calhoun, J. Bharatia. January 2007. (Format: TXT, HTML) (Obsoletes RFC3012) (Updates RFC3344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4721) 4722 Media Server Control Markup Language (MSCML) and Protocol. J. Van Dyke, E. Burger, Ed., A. Spitzer. November 2006. (Format: TXT, HTML) (Obsoleted by RFC5022) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4722) 4723 Registration of Media Type audio/mobile-xmf. T. Kosonen, T. White. December 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4723) 4724 Graceful Restart Mechanism for BGP. S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter. January 2007. (Format: TXT, HTML) (Updated by RFC8538) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4724) 4725 ENUM Validation Architecture. A. Mayrhofer, B. Hoeneisen. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4725) 4726 A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering. A. Farrel, J.-P. Vasseur, A. Ayyangar. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4726) 4727 Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers. B. Fenner. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4727) 4728 The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4. D. Johnson, Y. Hu, D. Maltz. February 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4728) 4729 A Uniform Resource Name (URN) Namespace for the Near Field Communication (NFC) Forum. M. Abel. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4729) 4730 A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML). E. Burger, M. Dolly. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4730) 4731 IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned. A. Melnikov, D. Cridland. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4731) 4732 Internet Denial-of-Service Considerations. M. Handley, Ed., E. Rescorla, Ed., IAB. December 2006. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4732) 4733 RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals. H. Schulzrinne, T. Taylor. December 2006. (Format: TXT, HTML) (Obsoletes RFC2833) (Updated by RFC4734, RFC5244) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4733) 4734 Definition of Events for Modem, Fax, and Text Telephony Signals. H. Schulzrinne, T. Taylor. December 2006. (Format: TXT, HTML) (Obsoletes RFC2833) (Updates RFC4733) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4734) 4735 Example Media Types for Use in Documentation. T. Taylor. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4735) 4736 Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP). JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4736) 4737 Packet Reordering Metrics. A. Morton, L. Ciavattone, G. Ramachandran, S. Shalunov, J. Perser. November 2006. (Format: TXT, HTML) (Updated by RFC6248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4737) 4738 MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY). D. Ignjatic, L. Dondeti, F. Audet, P. Lin. November 2006. (Format: TXT, HTML) (Updates RFC3830) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4738) 4739 Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol. P. Eronen, J. Korhonen. November 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4739) 4740 Diameter Session Initiation Protocol (SIP) Application. M. Garcia-Martin, Ed., M. Belinchon, M. Pallares-Lopez, C. Canales-Valenzuela, K. Tammi. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4740) 4741 NETCONF Configuration Protocol. R. Enns, Ed.. December 2006. (Format: TXT, HTML) (Obsoleted by RFC6241) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4741) 4742 Using the NETCONF Configuration Protocol over Secure SHell (SSH). M. Wasserman, T. Goddard. December 2006. (Format: TXT, HTML) (Obsoleted by RFC6242) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4742) 4743 Using NETCONF over the Simple Object Access Protocol (SOAP). T. Goddard. December 2006. (Format: TXT, HTML) (Updated by RFC8996) (Status: HISTORIC) (DOI: 10.17487/RFC4743) 4744 Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP). E. Lear, K. Crozier. December 2006. (Format: TXT, HTML) (Updated by RFC8996) (Status: HISTORIC) (DOI: 10.17487/RFC4744) 4745 Common Policy: A Document Format for Expressing Privacy Preferences. H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. Polk, J. Rosenberg. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4745) 4746 Extensible Authentication Protocol (EAP) Password Authenticated Exchange. T. Clancy, W. Arbaugh. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4746) 4747 The Virtual Fabrics MIB. S. Kipp, G. Ramkumar, K. McCloghrie. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4747) 4748 RFC 3978 Update to Recognize the IETF Trust. S. Bradner, Ed.. October 2006. (Format: TXT, HTML) (Obsoleted by RFC5378) (Updates RFC3978) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4748) 4749 RTP Payload Format for the G.729.1 Audio Codec. A. Sollaud. October 2006. (Format: TXT, HTML) (Updated by RFC5459) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4749) 4750 OSPF Version 2 Management Information Base. D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, Ed., R. Coltun, F. Baker. December 2006. (Format: TXT, HTML) (Obsoletes RFC1850) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4750) 4751 Not Issued. 4752 The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism. A. Melnikov, Ed.. November 2006. (Format: TXT, HTML) (Obsoletes RFC2222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4752) 4753 ECP Groups For IKE and IKEv2. D. Fu, J. Solinas. January 2007. (Format: TXT, HTML) (Obsoleted by RFC5903) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4753) 4754 IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA). D. Fu, J. Solinas. January 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4754) 4755 IP over InfiniBand: Connected Mode. V. Kashyap. December 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4755) 4756 Forward Error Correction Grouping Semantics in Session Description Protocol. A. Li. November 2006. (Format: TXT, HTML) (Obsoleted by RFC5956) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4756) 4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows. K. Jaganathan, L. Zhu, J. Brezak. December 2006. (Format: TXT, HTML) (Updated by RFC6649) (Status: HISTORIC) (DOI: 10.17487/RFC4757) 4758 Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1. M. Nystroem. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4758) 4759 The ENUM Dip Indicator Parameter for the "tel" URI. R. Stastny, R. Shockey, L. Conroy. December 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4759) 4760 Multiprotocol Extensions for BGP-4. T. Bates, R. Chandra, D. Katz, Y. Rekhter. January 2007. (Format: TXT, HTML) (Obsoletes RFC2858) (Updated by RFC7606) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4760) 4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling. K. Kompella, Ed., Y. Rekhter, Ed.. January 2007. (Format: TXT, HTML) (Updated by RFC5462, RFC8395, RFC8614) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4761) 4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling. M. Lasserre, Ed., V. Kompella, Ed.. January 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4762) 4763 Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE). M. Vanderveen, H. Soliman. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4763) 4764 The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method. F. Bersani, H. Tschofenig. January 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4764) 4765 The Intrusion Detection Message Exchange Format (IDMEF). H. Debar, D. Curry, B. Feinstein. March 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4765) 4766 Intrusion Detection Message Exchange Requirements. M. Wood, M. Erlinger. March 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4766) 4767 The Intrusion Detection Exchange Protocol (IDXP). B. Feinstein, G. Matthews. March 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4767) 4768 Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming. S. Hartman. December 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4768) 4769 IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information. J. Livingood, R. Shockey. November 2006. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4769) 4770 vCard Extensions for Instant Messaging (IM). C. Jennings, J. Reschke, Ed.. January 2007. (Format: TXT, HTML) (Obsoleted by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4770) 4771 Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP). V. Lehtovirta, M. Naslund, K. Norrman. January 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4771) 4772 Security Implications of Using the Data Encryption Standard (DES). S. Kelly. December 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4772) 4773 Administration of the IANA Special Purpose IPv6 Address Block. G. Huston. December 2006. (Format: TXT, HTML) (Obsoleted by RFC6890) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4773) 4774 Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field. S. Floyd. November 2006. (Format: TXT, HTML) (Updated by RFC6040) (Also BCP0124) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4774) 4775 Procedures for Protocol Extensions and Variations. S. Bradner, B. Carpenter, Ed., T. Narten. December 2006. (Format: TXT, HTML) (Also BCP0125) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4775) 4776 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information. H. Schulzrinne. November 2006. (Format: TXT, HTML) (Obsoletes RFC4676) (Updated by RFC5774, RFC6848) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4776) 4777 IBM's iSeries Telnet Enhancements. T. Murphy Jr., P. Rieth, J. Stevens. November 2006. (Format: TXT, HTML) (Obsoletes RFC2877) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4777) 4778 Operational Security Current Practices in Internet Service Provider Environments. M. Kaeo. January 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4778) 4779 ISP IPv6 Deployment Scenarios in Broadband Access Networks. S. Asadullah, A. Ahmed, C. Popoviciu, P. Savola, J. Palet. January 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4779) 4780 Management Information Base for the Session Initiation Protocol (SIP). K. Lingle, J-F. Mule, J. Maeng, D. Walker. April 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4780) 4781 Graceful Restart Mechanism for BGP with MPLS. Y. Rekhter, R. Aggarwal. January 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4781) 4782 Quick-Start for TCP and IP. S. Floyd, M. Allman, A. Jain, P. Sarolahti. January 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4782) 4783 GMPLS - Communication of Alarm Information. L. Berger, Ed.. December 2006. (Format: TXT, HTML) (Updates RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4783) 4784 Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks. C. Carroll, F. Quick. June 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4784) 4785 Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS). U. Blumenthal, P. Goel. January 2007. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4785) 4786 Operation of Anycast Services. J. Abley, K. Lindqvist. December 2006. (Format: TXT, HTML) (Also BCP0126) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4786) 4787 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP. F. Audet, Ed., C. Jennings. January 2007. (Format: TXT, HTML) (Updated by RFC6888, RFC7857) (Also BCP0127) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4787) 4788 Enhancements to RTP Payload Formats for EVRC Family Codecs. Q. Xie, R. Kapoor. January 2007. (Format: TXT, HTML) (Updates RFC3558) (Updated by RFC5188) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4788) 4789 Simple Network Management Protocol (SNMP) over IEEE 802 Networks. J. Schoenwaelder, T. Jeffree. November 2006. (Format: TXT, HTML) (Obsoletes RFC1089) (Updates RFC3417) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4789) 4790 Internet Application Protocol Collation Registry. C. Newman, M. Duerst, A. Gulbrandsen. March 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4790) 4791 Calendaring Extensions to WebDAV (CalDAV). C. Daboo, B. Desruisseaux, L. Dusseault. March 2007. (Format: TXT, HTML) (Updated by RFC5689, RFC6638, RFC6764, RFC7809, RFC7953, RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4791) 4792 Encoding Instructions for the Generic String Encoding Rules (GSER). S. Legg. January 2007. (Format: TXT, HTML) (Updates RFC3641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4792) 4793 The EAP Protected One-Time Password Protocol (EAP-POTP). M. Nystroem. February 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4793) 4794 RFC 1264 Is Obsolete. B. Fenner. December 2006. (Format: TXT, HTML) (Obsoletes RFC1264) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4794) 4795 Link-local Multicast Name Resolution (LLMNR). B. Aboba, D. Thaler, L. Esibov. January 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4795) 4796 The Session Description Protocol (SDP) Content Attribute. J. Hautakorpi, G. Camarillo. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4796) 4797 Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks. Y. Rekhter, R. Bonica, E. Rosen. January 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4797) 4798 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE). J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4798) 4799 Not Issued. 4800 Not Issued. 4801 Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management. T. Nadeau, Ed., A. Farrel, Ed.. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4801) 4802 Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base. T. Nadeau, Ed., A. Farrel, Ed.. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4802) 4803 Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base. T. Nadeau, Ed., A. Farrel, Ed.. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4803) 4804 Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels. F. Le Faucheur, Ed.. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4804) 4805 Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types. O. Nicklass, Ed.. March 2007. (Format: TXT, HTML) (Obsoletes RFC3895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4805) 4806 Online Certificate Status Protocol (OCSP) Extensions to IKEv2. M. Myers, H. Tschofenig. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4806) 4807 IPsec Security Policy Database Configuration MIB. M. Baer, R. Charlet, W. Hardaker, R. Story, C. Wang. March 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4807) 4808 Key Change Strategies for TCP-MD5. S. Bellovin. March 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4808) 4809 Requirements for an IPsec Certificate Management Profile. C. Bonatti, Ed., S. Turner, Ed., G. Lebovitz, Ed.. February 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4809) 4810 Long-Term Archive Service Requirements. C. Wallace, U. Pordesch, R. Brandner. March 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4810) 4811 OSPF Out-of-Band Link State Database (LSDB) Resynchronization. L. Nguyen, A. Roy, A. Zinin. March 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4811) 4812 OSPF Restart Signaling. L. Nguyen, A. Roy, A. Zinin. March 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4812) 4813 OSPF Link-Local Signaling. B. Friedman, L. Nguyen, A. Roy, D. Yeung, A. Zinin. March 2007. (Format: TXT, HTML) (Obsoleted by RFC5613) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4813) 4814 Hash and Stuffing: Overlooked Factors in Network Device Benchmarking. D. Newman, T. Player. March 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4814) 4815 RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095. L-E. Jonsson, K. Sandlund, G. Pelletier, P. Kremer. February 2007. (Format: TXT, HTML) (Updates RFC3095, RFC3241, RFC3843, RFC4019, RFC4362) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4815) 4816 Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service. A. Malis, L. Martini, J. Brayley, T. Walsh. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4816) 4817 Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3. M. Townsley, C. Pignataro, S. Wainner, T. Seely, J. Young. March 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4817) 4818 RADIUS Delegated-IPv6-Prefix Attribute. J. Salowey, R. Droms. April 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4818) 4819 Secure Shell Public Key Subsystem. J. Galbraith, J. Van Dyke, J. Bright. March 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4819) 4820 Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP). M. Tuexen, R. Stewart, P. Lei. March 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4820) 4821 Packetization Layer Path MTU Discovery. M. Mathis, J. Heffner. March 2007. (Format: TXT, HTML) (Updated by RFC8899) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4821) 4822 RIPv2 Cryptographic Authentication. R. Atkinson, M. Fanto. February 2007. (Format: TXT, HTML) (Obsoletes RFC2082) (Updates RFC2453) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4822) 4823 FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet. T. Harding, R. Scott. April 2007. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4823) 4824 The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS). J. Hofmueller, Ed., A. Bachmann, Ed., IO. zmoelnig, Ed.. 1 April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4824) 4825 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP). J. Rosenberg. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4825) 4826 Extensible Markup Language (XML) Formats for Representing Resource Lists. J. Rosenberg. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4826) 4827 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents. M. Isomaki, E. Leppanen. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4827) 4828 TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant. S. Floyd, E. Kohler. April 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4828) 4829 Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering. J. de Oliveira, Ed., JP. Vasseur, Ed., L. Chen, C. Scoglio. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4829) 4830 Problem Statement for Network-Based Localized Mobility Management (NETLMM). J. Kempf, Ed.. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4830) 4831 Goals for Network-Based Localized Mobility Management (NETLMM). J. Kempf, Ed.. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4831) 4832 Security Threats to Network-Based Localized Mobility Management (NETLMM). C. Vogt, J. Kempf. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4832) 4833 Timezone Options for DHCP. E. Lear, P. Eggert. April 2007. (Format: TXT, HTML) (Updates RFC2132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4833) 4834 Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). T. Morin, Ed.. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4834) 4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH). V. Manral. April 2007. (Format: TXT, HTML) (Obsoletes RFC4305) (Obsoleted by RFC7321) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4835) 4836 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs). E. Beili. April 2007. (Format: TXT, HTML) (Obsoletes RFC3636) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4836) 4837 Managed Objects of Ethernet Passive Optical Networks (EPON). L. Khermosh. July 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4837) 4838 Delay-Tolerant Networking Architecture. V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. Scott, K. Fall, H. Weiss. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4838) 4839 Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF). G. Conboy, J. Rivlin, J. Ferraiolo. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4839) 4840 Multiple Encapsulation Methods Considered Harmful. B. Aboba, Ed., E. Davies, D. Thaler. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4840) 4841 RFC 4181 Update to Recognize the IETF Trust. C. Heard, Ed.. March 2007. (Format: TXT, HTML) (Updates RFC4181) (Also BCP0111) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4841) 4842 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP). A. Malis, P. Pate, R. Cohen, Ed., D. Zelig. April 2007. (Format: TXT, HTML) (Obsoletes RFC5143) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4842) 4843 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID). P. Nikander, J. Laganier, F. Dupont. April 2007. (Format: TXT, HTML) (Obsoleted by RFC7343) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4843) 4844 The RFC Series and RFC Editor. L. Daigle, Ed., Internet Architecture Board. July 2007. (Format: TXT, HTML) (Obsoleted by RFC8729) (Updated by RFC5741) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4844) 4845 Process for Publication of IAB RFCs. L. Daigle, Ed., Internet Architecture Board. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4845) 4846 Independent Submissions to the RFC Editor. J. Klensin, Ed., D. Thaler, Ed.. July 2007. (Format: TXT, HTML) (Updated by RFC5744) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4846) 4847 Framework and Requirements for Layer 1 Virtual Private Networks. T. Takeda, Ed.. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4847) 4848 Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS). L. Daigle. April 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4848) 4849 RADIUS Filter Rule Attribute. P. Congdon, M. Sanchez, B. Aboba. April 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4849) 4850 Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture. D. Wysochanski. April 2007. (Format: TXT, HTML) (Obsoleted by RFC7143) (Updates RFC3720) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4850) 4851 The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST). N. Cam-Winget, D. McGrew, J. Salowey, H. Zhou. May 2007. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4851) 4852 IPv6 Enterprise Network Analysis - IP Layer 3 Focus. J. Bound, Y. Pouffary, S. Klynsma, T. Chown, D. Green. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4852) 4853 Cryptographic Message Syntax (CMS) Multiple Signer Clarification. R. Housley. April 2007. (Format: TXT, HTML) (Updates RFC3852) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4853) 4854 A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4854) 4855 Media Type Registration of RTP Payload Formats. S. Casner. February 2007. (Format: TXT, HTML) (Obsoletes RFC3555) (Updated by RFC8851) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4855) 4856 Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences. S. Casner. February 2007. (Format: TXT, HTML) (Obsoletes RFC3555) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4856) 4857 Mobile IPv4 Regional Registration. E. Fogelstroem, A. Jonsson, C. Perkins. June 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4857) 4858 Document Shepherding from Working Group Last Call to Publication. H. Levkowetz, D. Meyer, L. Eggert, A. Mankin. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4858) 4859 Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object. A. Farrel. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4859) 4860 Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations. F. Le Faucheur, B. Davie, P. Bose, C. Christou, M. Davenport. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4860) 4861 Neighbor Discovery for IP version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson, H. Soliman. September 2007. (Format: TXT, HTML) (Obsoletes RFC2461) (Updated by RFC5942, RFC6980, RFC7048, RFC7527, RFC7559, RFC8028, RFC8319, RFC8425, RFC9131) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4861) 4862 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten, T. Jinmei. September 2007. (Format: TXT, HTML) (Obsoletes RFC2462) (Updated by RFC7527) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4862) 4863 Wildcard Pseudowire Type. L. Martini, G. Swallow. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4863) 4864 Local Network Protection for IPv6. G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4864) 4865 SMTP Submission Service Extension for Future Message Release. G. White, G. Vaudreuil. May 2007. (Format: TXT, HTML) (Updates RFC3463, RFC3464) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4865) 4866 Enhanced Route Optimization for Mobile IPv6. J. Arkko, C. Vogt, W. Haddad. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4866) 4867 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs. J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie. April 2007. (Format: TXT, HTML) (Obsoletes RFC3267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4867) 4868 Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec. S. Kelly, S. Frankel. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4868) 4869 Suite B Cryptographic Suites for IPsec. L. Law, J. Solinas. May 2007. (Format: TXT, HTML) (Obsoleted by RFC6379) (Status: HISTORIC) (DOI: 10.17487/RFC4869) 4870 Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys). M. Delany. May 2007. (Format: TXT, HTML) (Obsoleted by RFC4871) (Status: HISTORIC) (DOI: 10.17487/RFC4870) 4871 DomainKeys Identified Mail (DKIM) Signatures. E. Allman, J. Callas, M. Delany, M. Libbey, J. Fenton, M. Thomas. May 2007. (Format: TXT, HTML) (Obsoletes RFC4870) (Obsoleted by RFC6376) (Updated by RFC5672) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4871) 4872 RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery. J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed.. May 2007. (Format: TXT, HTML) (Updates RFC3471) (Updated by RFC4873, RFC6780, RFC9270) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4872) 4873 GMPLS Segment Recovery. L. Berger, I. Bryskin, D. Papadimitriou, A. Farrel. May 2007. (Format: TXT, HTML) (Updates RFC3473, RFC4872) (Updated by RFC9270) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4873) 4874 Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE). CY. Lee, A. Farrel, S. De Cnodder. April 2007. (Format: TXT, HTML) (Updates RFC3209, RFC3473) (Updated by RFC6001, RFC8390) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4874) 4875 Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs). R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.. May 2007. (Format: TXT, HTML) (Updated by RFC6510) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4875) 4876 A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents. B. Neal-Joslin, Ed., L. Howard, M. Ansari. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4876) 4877 Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture. V. Devarapalli, F. Dupont. April 2007. (Format: TXT, HTML) (Updates RFC3776) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4877) 4878 Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces. M. Squire. June 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4878) 4879 Clarification of the Third Party Disclosure Procedure in RFC 3979. T. Narten. April 2007. (Format: TXT, HTML) (Obsoleted by RFC8179) (Updates RFC3979) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4879) 4880 OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, D. Shaw, R. Thayer. November 2007. (Format: TXT, HTML) (Obsoletes RFC1991, RFC2440) (Updated by RFC5581) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4880) 4881 Low-Latency Handoffs in Mobile IPv4. K. El Malki, Ed.. June 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4881) 4882 IP Address Location Privacy and Mobile IPv6: Problem Statement. R. Koodli. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4882) 4883 Benchmarking Terminology for Resource Reservation Capable Routers. G. Feher, K. Nemeth, A. Korn, I. Cselenyi. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4883) 4884 Extended ICMP to Support Multi-Part Messages. R. Bonica, D. Gan, D. Tappan, C. Pignataro. April 2007. (Format: TXT, HTML) (Updates RFC0792, RFC4443) (Updated by RFC8335) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4884) 4885 Network Mobility Support Terminology. T. Ernst, H-Y. Lach. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4885) 4886 Network Mobility Support Goals and Requirements. T. Ernst. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4886) 4887 Network Mobility Home Network Models. P. Thubert, R. Wakikawa, V. Devarapalli. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4887) 4888 Network Mobility Route Optimization Problem Statement. C. Ng, P. Thubert, M. Watari, F. Zhao. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4888) 4889 Network Mobility Route Optimization Solution Space Analysis. C. Ng, F. Zhao, M. Watari, P. Thubert. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4889) 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls. E. Davies, J. Mohacsi. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4890) 4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels. R. Graveman, M. Parthasarathy, P. Savola, H. Tschofenig. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4891) 4892 Requirements for a Mechanism Identifying a Name Server Instance. S. Woolf, D. Conrad. June 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4892) 4893 BGP Support for Four-octet AS Number Space. Q. Vohra, E. Chen. May 2007. (Format: TXT, HTML) (Obsoleted by RFC6793) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4893) 4894 Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec. P. Hoffman. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4894) 4895 Authenticated Chunks for the Stream Control Transmission Protocol (SCTP). M. Tuexen, R. Stewart, P. Lei, E. Rescorla. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4895) 4896 Signaling Compression (SigComp) Corrections and Clarifications. A. Surtees, M. West, A.B. Roach. June 2007. (Format: TXT, HTML) (Updates RFC3320, RFC3321, RFC3485) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4896) 4897 Handling Normative References to Standards-Track Documents. J. Klensin, S. Hartman. June 2007. (Format: TXT, HTML) (Updates RFC3967) (Also BCP0097) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4897) 4898 TCP Extended Statistics MIB. M. Mathis, J. Heffner, R. Raghunarayan. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4898) 4899 Not Issued. 4900 Not Issued. 4901 Protocol Extensions for Header Compression over MPLS. J. Ash, Ed., J. Hand, Ed., A. Malis, Ed.. June 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4901) 4902 Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP. M. Stecher. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4902) 4903 Multi-Link Subnet Issues. D. Thaler. June 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4903) 4904 Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs). V. Gurbani, C. Jennings. June 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4904) 4905 Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks. L. Martini, Ed., E. Rosen, Ed., N. El-Aawar, Ed.. June 2007. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4905) 4906 Transport of Layer 2 Frames Over MPLS. L. Martini, Ed., E. Rosen, Ed., N. El-Aawar, Ed.. June 2007. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4906) 4907 Architectural Implications of Link Indications. B. Aboba, Ed.. June 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4907) 4908 Multi-homing for small scale fixed network Using Mobile IP and NEMO. K. Nagami, S. Uda, N. Ogashiwa, H. Esaki, R. Wakikawa, H. Ohnishi. June 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4908) 4909 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport. L. Dondeti, Ed., D. Castleford, F. Hartung. June 2007. (Format: TXT, HTML) (Obsoleted by RFC5410, RFC6309) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4909) 4910 Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1). S. Legg, D. Prager. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4910) 4911 Encoding Instructions for the Robust XML Encoding Rules (RXER). S. Legg. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4911) 4912 Abstract Syntax Notation X (ASN.X). S. Legg. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4912) 4913 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER). S. Legg. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4913) 4914 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER). S. Legg. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4914) 4915 Multi-Topology (MT) Routing in OSPF. P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, P. Pillay-Esnault. June 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4915) 4916 Connected Identity in the Session Initiation Protocol (SIP). J. Elwell. June 2007. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4916) 4917 Mobile IPv4 Message String Extension. V. Sastry, K. Leung, A. Patel. June 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4917) 4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). L. Dusseault, Ed.. June 2007. (Format: TXT, HTML) (Obsoletes RFC2518) (Updated by RFC5689) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4918) 4919 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals. N. Kushalnagar, G. Montenegro, C. Schumacher. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4919) 4920 Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE. A. Farrel, Ed., A. Satyanarayana, A. Iwata, N. Fujita, G. Ash. July 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4920) 4921 Not Issued. 4922 Not Issued. 4923 Quality of Service (QoS) Signaling in a Nested Virtual Private Network. F. Baker, P. Bose. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4923) 4924 Reflections on Internet Transparency. B. Aboba, Ed., E. Davies. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4924) 4925 Softwire Problem Statement. X. Li, Ed., S. Dawkins, Ed., D. Ward, Ed., A. Durand, Ed.. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4925) 4926 A URN Namespace for GEANT. T. Kalin, M. Molina. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4926) 4927 Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering. J.-L. Le Roux, Ed.. June 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4927) 4928 Avoiding Equal Cost Multipath Treatment in MPLS Networks. G. Swallow, S. Bryant, L. Andersson. June 2007. (Format: TXT, HTML) (Updated by RFC7274) (Also BCP0128) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4928) 4929 Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures. L. Andersson, Ed., A. Farrel, Ed.. June 2007. (Format: TXT, HTML) (Also BCP0129) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4929) 4930 Extensible Provisioning Protocol (EPP). S. Hollenbeck. May 2007. (Format: TXT, HTML) (Obsoletes RFC3730) (Obsoleted by RFC5730) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4930) 4931 Extensible Provisioning Protocol (EPP) Domain Name Mapping. S. Hollenbeck. May 2007. (Format: TXT, HTML) (Obsoletes RFC3731) (Obsoleted by RFC5731) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4931) 4932 Extensible Provisioning Protocol (EPP) Host Mapping. S. Hollenbeck. May 2007. (Format: TXT, HTML) (Obsoletes RFC3732) (Obsoleted by RFC5732) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4932) 4933 Extensible Provisioning Protocol (EPP) Contact Mapping. S. Hollenbeck. May 2007. (Format: TXT, HTML) (Obsoletes RFC3733) (Obsoleted by RFC5733) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4933) 4934 Extensible Provisioning Protocol (EPP) Transport Over TCP. S. Hollenbeck. May 2007. (Format: TXT, HTML) (Obsoletes RFC3734) (Obsoleted by RFC5734) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4934) 4935 Fibre Channel Fabric Configuration Server MIB. C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4935) 4936 Fibre Channel Zone Server MIB. C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4936) 4937 IANA Considerations for PPP over Ethernet (PPPoE). P. Arberg, V. Mammoliti. June 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4937) 4938 PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics. B. Berry, H. Holgate. June 2007. (Format: TXT, HTML) (Obsoleted by RFC5578) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4938) 4939 Definitions of Managed Objects for iSNS (Internet Storage Name Service). K. Gibbons, G. Ramkumar, S. Kipp. July 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4939) 4940 IANA Considerations for OSPF. K. Kompella, B. Fenner. July 2007. (Format: TXT, HTML) (Also BCP0130) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4940) 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves, S. Krishnan. September 2007. (Format: TXT, HTML) (Obsoletes RFC3041) (Obsoleted by RFC8981) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4941) 4942 IPv6 Transition/Co-existence Security Considerations. E. Davies, S. Krishnan, P. Savola. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4942) 4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful. S. Roy, A. Durand, J. Paugh. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4943) 4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks. G. Montenegro, N. Kushalnagar, J. Hui, D. Culler. September 2007. (Format: TXT, HTML) (Updated by RFC6282, RFC6775, RFC8025, RFC8066, RFC8931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4944) 4945 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX. B. Korver. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4945) 4946 Atom License Extension. J. Snell. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4946) 4947 Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks. G. Fairhurst, M. Montpetit. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4947) 4948 Report from the IAB workshop on Unwanted Traffic March 9-10, 2006. L. Andersson, E. Davies, L. Zhang. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4948) 4949 Internet Security Glossary, Version 2. R. Shirey. August 2007. (Format: TXT, HTML) (Obsoletes RFC2828) (Also FYI0036) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4949) 4950 ICMP Extensions for Multiprotocol Label Switching. R. Bonica, D. Gan, D. Tappan, C. Pignataro. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4950) 4951 Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover". V. Jain, Ed.. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4951) 4952 Overview and Framework for Internationalized Email. J. Klensin, Y. Ko. July 2007. (Format: TXT, HTML) (Obsoleted by RFC6530) (Updated by RFC5336) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4952) 4953 Defending TCP Against Spoofing Attacks. J. Touch. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4953) 4954 SMTP Service Extension for Authentication. R. Siemborski, Ed., A. Melnikov, Ed.. July 2007. (Format: TXT, HTML) (Obsoletes RFC2554) (Updates RFC3463) (Updated by RFC5248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4954) 4955 DNS Security (DNSSEC) Experiments. D. Blacka. July 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4955) 4956 DNS Security (DNSSEC) Opt-In. R. Arends, M. Kosters, D. Blacka. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4956) 4957 Link-Layer Event Notifications for Detecting Network Attachments. S. Krishnan, Ed., N. Montavont, E. Njedjou, S. Veerepalli, A. Yegin, Ed.. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4957) 4958 A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain. K. Carlberg. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4958) 4959 IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response. R. Siemborski, A. Gulbrandsen. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4959) 4960 Stream Control Transmission Protocol. R. Stewart, Ed.. September 2007. (Format: TXT, HTML) (Obsoletes RFC2960, RFC3309) (Obsoleted by RFC9260) (Updated by RFC6096, RFC6335, RFC7053, RFC8899) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4960) 4961 Symmetric RTP / RTP Control Protocol (RTCP). D. Wing. July 2007. (Format: TXT, HTML) (Also BCP0131) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4961) 4962 Guidance for Authentication, Authorization, and Accounting (AAA) Key Management. R. Housley, B. Aboba. July 2007. (Format: TXT, HTML) (Also BCP0132) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4962) 4963 IPv4 Reassembly Errors at High Data Rates. J. Heffner, M. Mathis, B. Chandler. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4963) 4964 The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular. A. Allen, Ed., J. Holm, T. Hallin. September 2007. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4964) 4965 CableLabs - IETF Standardization Collaboration. J-F. Mule, W. Townsley. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4965) 4966 Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status. C. Aoun, E. Davies. July 2007. (Format: TXT, HTML) (Obsoletes RFC2766) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4966) 4967 Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier. B. Rosen. July 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4967) 4968 Analysis of IPv6 Link Models for 802.16 Based Networks. S. Madanapalli, Ed.. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4968) 4969 IANA Registration for vCard Enumservice. A. Mayrhofer. August 2007. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4969) 4970 Extensions to OSPF for Advertising Optional Router Capabilities. A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer. July 2007. (Format: TXT, HTML) (Obsoleted by RFC7770) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4970) 4971 Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information. JP. Vasseur, Ed., N. Shen, Ed., R. Aggarwal, Ed.. July 2007. (Format: TXT, HTML) (Obsoleted by RFC7981) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4971) 4972 Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership. JP. Vasseur, Ed., JL. Leroux, Ed., S. Yasukawa, S. Previdi, P. Psenak, P. Mabbey. July 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4972) 4973 OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering. P. Srisuresh, P. Joseph. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4973) 4974 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls. D. Papadimitriou, A. Farrel. August 2007. (Format: TXT, HTML) (Updates RFC3473) (Updated by RFC6001) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4974) 4975 The Message Session Relay Protocol (MSRP). B. Campbell, Ed., R. Mahy, Ed., C. Jennings, Ed.. September 2007. (Format: TXT, HTML) (Updated by RFC7977, RFC8591, RFC8873, RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4975) 4976 Relay Extensions for the Message Sessions Relay Protocol (MSRP). C. Jennings, R. Mahy, A. B. Roach. September 2007. (Format: TXT, HTML) (Updated by RFC7977, RFC8553, RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4976) 4977 Problem Statement: Dual Stack Mobility. G. Tsirtsis, H. Soliman. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4977) 4978 The IMAP COMPRESS Extension. A. Gulbrandsen. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4978) 4979 IANA Registration for Enumservice 'XMPP'. A. Mayrhofer. August 2007. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4979) 4980 Analysis of Multihoming in Network Mobility Support. C. Ng, T. Ernst, E. Paik, M. Bagnulo. October 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4980) 4981 Survey of Research towards Robust Peer-to-Peer Networks: Search Methods. J. Risson, T. Moors. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4981) 4982 Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs). M. Bagnulo, J. Arkko. July 2007. (Format: TXT, HTML) (Updates RFC3972) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4982) 4983 Fibre Channel Registered State Change Notification (RSCN) MIB. C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4983) 4984 Report from the IAB Workshop on Routing and Addressing. D. Meyer, Ed., L. Zhang, Ed., K. Fall, Ed.. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4984) 4985 Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name. S. Santesson. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4985) 4986 Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover. H. Eland, R. Mundy, S. Crocker, S. Krishnaswamy. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4986) 4987 TCP SYN Flooding Attacks and Common Mitigations. W. Eddy. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4987) 4988 Mobile IPv4 Fast Handovers. R. Koodli, C. Perkins. October 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4988) 4989 Not Issued. 4990 Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks. K. Shiomoto, R. Papneja, R. Rabbat. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4990) 4991 A Common Schema for Internet Registry Information Service Transfer Protocols. A. Newton. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4991) 4992 XML Pipelining with Chunks for the Internet Registry Information Service. A. Newton. August 2007. (Format: TXT, HTML) (Updates RFC3981) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4992) 4993 A Lightweight UDP Transfer Protocol for the Internet Registry Information Service. A. Newton. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4993) 4994 DHCPv6 Relay Agent Echo Request Option. S. Zeng, B. Volz, K. Kinnear, J. Brzozowski. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4994) 4995 The RObust Header Compression (ROHC) Framework. L-E. Jonsson, G. Pelletier, K. Sandlund. July 2007. (Format: TXT, HTML) (Obsoleted by RFC5795) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4995) 4996 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP). G. Pelletier, K. Sandlund, L-E. Jonsson, M. West. July 2007. (Format: TXT, HTML) (Obsoleted by RFC6846) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4996) 4997 Formal Notation for RObust Header Compression (ROHC-FN). R. Finking, G. Pelletier. July 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4997) 4998 Evidence Record Syntax (ERS). T. Gondrom, R. Brandner, U. Pordesch. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4998) 4999 Not Issued. 5000 Internet Official Protocol Standards. RFC Editor. May 2008. (Format: TXT, HTML) (Obsoletes RFC3700) (Obsoleted by RFC7100) (Status: HISTORIC) (DOI: 10.17487/RFC5000) 5001 DNS Name Server Identifier (NSID) Option. R. Austein. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5001) 5002 The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header). G. Camarillo, G. Blanco. August 2007. (Format: TXT, HTML) (Updated by RFC8217) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5002) 5003 Attachment Individual Identifier (AII) Types for Aggregation. C. Metz, L. Martini, F. Balus, J. Sugimoto. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5003) 5004 Avoid BGP Best Path Transitions from One External to Another. E. Chen, S. Sangli. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5004) 5005 Feed Paging and Archiving. M. Nottingham. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5005) 5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong, Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format: TXT, HTML) (Obsoleted by RFC6106) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5006) 5007 DHCPv6 Leasequery. J. Brzozowski, K. Kinnear, B. Volz, S. Zeng. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5007) 5008 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME). R. Housley, J. Solinas. September 2007. (Format: TXT, HTML) (Obsoleted by RFC6318) (Status: HISTORIC) (DOI: 10.17487/RFC5008) 5009 Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media. R. Ejza. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5009) 5010 The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption. K. Kinnear, M. Normoyle, M. Stapp. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5010) 5011 Automated Updates of DNS Security (DNSSEC) Trust Anchors. M. StJohns. September 2007. (Format: TXT, HTML) (Also STD0074) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5011) 5012 Requirements for Emergency Context Resolution with Internet Technologies. H. Schulzrinne, R. Marshall, Ed.. January 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5012) 5013 The Dublin Core Metadata Element Set. J. Kunze, T. Baker. August 2007. (Format: TXT, HTML) (Obsoletes RFC2413) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5013) 5014 IPv6 Socket API for Source Address Selection. E. Nordmark, S. Chakrabarti, J. Laganier. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5014) 5015 Bidirectional Protocol Independent Multicast (BIDIR-PIM). M. Handley, I. Kouvelas, T. Speakman, L. Vicisano. October 2007. (Format: TXT, HTML) (Updated by RFC8736) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5015) 5016 Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol. M. Thomas. October 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5016) 5017 MIB Textual Conventions for Uniform Resource Identifiers (URIs). D. McWalter, Ed.. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5017) 5018 Connection Establishment in the Binary Floor Control Protocol (BFCP). G. Camarillo. September 2007. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5018) 5019 The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. A. Deacon, R. Hurst. September 2007. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5019) 5020 The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute. K. Zeilenga. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5020) 5021 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP. S. Josefsson. August 2007. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5021) 5022 Media Server Control Markup Language (MSCML) and Protocol. J. Van Dyke, E. Burger, Ed., A. Spitzer. September 2007. (Format: TXT, HTML) (Obsoletes RFC4722) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5022) 5023 The Atom Publishing Protocol. J. Gregorio, Ed., B. de hOra, Ed.. October 2007. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5023) 5024 ODETTE File Transfer Protocol 2.0. I. Friend. November 2007. (Format: TXT, HTML) (Obsoletes RFC2204) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5024) 5025 Presence Authorization Rules. J. Rosenberg. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5025) 5026 Mobile IPv6 Bootstrapping in Split Scenario. G. Giaretta, Ed., J. Kempf, V. Devarapalli, Ed.. October 2007. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5026) 5027 Security Preconditions for Session Description Protocol (SDP) Media Streams. F. Andreasen, D. Wing. October 2007. (Format: TXT, HTML) (Updates RFC3312) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5027) 5028 A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services. R. Mahy. October 2007. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5028) 5029 Definition of an IS-IS Link Attribute Sub-TLV. JP. Vasseur, S. Previdi. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5029) 5030 Mobile IPv4 RADIUS Requirements. M. Nakhjiri, Ed., K. Chowdhury, A. Lior, K. Leung. October 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5030) 5031 A Uniform Resource Name (URN) for Emergency and Other Well-Known Services. H. Schulzrinne. January 2008. (Format: TXT, HTML) (Updated by RFC7163) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5031) 5032 WITHIN Search Extension to the IMAP Protocol. E. Burger, Ed.. September 2007. (Format: TXT, HTML) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5032) 5033 Specifying New Congestion Control Algorithms. S. Floyd, M. Allman. August 2007. (Format: TXT, HTML) (Also BCP0133) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5033) 5034 The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism. R. Siemborski, A. Menon-Sen. July 2007. (Format: TXT, HTML) (Obsoletes RFC1734) (Updates RFC2449) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5034) 5035 Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility. J. Schaad. August 2007. (Format: TXT, HTML) (Updates RFC2634) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5035) 5036 LDP Specification. L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed.. October 2007. (Format: TXT, HTML) (Obsoletes RFC3036) (Updated by RFC6720, RFC6790, RFC7358, RFC7552) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5036) 5037 Experience with the Label Distribution Protocol (LDP). L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed.. October 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5037) 5038 The Label Distribution Protocol (LDP) Implementation Survey Results. B. Thomas, L. Andersson. October 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5038) 5039 The Session Initiation Protocol (SIP) and Spam. J. Rosenberg, C. Jennings. January 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5039) 5040 A Remote Direct Memory Access Protocol Specification. R. Recio, B. Metzler, P. Culley, J. Hilland, D. Garcia. October 2007. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5040) 5041 Direct Data Placement over Reliable Transports. H. Shah, J. Pinkerton, R. Recio, P. Culley. October 2007. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5041) 5042 Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security. J. Pinkerton, E. Deleganes. October 2007. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5042) 5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation. C. Bestler, Ed., R. Stewart, Ed.. October 2007. (Format: TXT, HTML) (Updated by RFC6581, RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5043) 5044 Marker PDU Aligned Framing for TCP Specification. P. Culley, U. Elzur, R. Recio, S. Bailey, J. Carrier. October 2007. (Format: TXT, HTML) (Updated by RFC6581, RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5044) 5045 Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP). C. Bestler, Ed., L. Coene. October 2007. (Format: TXT, HTML) (Updated by RFC7146) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5045) 5046 Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA). M. Ko, M. Chadalapaka, J. Hufferd, U. Elzur, H. Shah, P. Thaler. October 2007. (Format: TXT, HTML) (Obsoleted by RFC7145) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5046) 5047 DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI). M. Chadalapaka, J. Hufferd, J. Satran, H. Shah. October 2007. (Format: TXT, HTML) (Updated by RFC7146) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5047) 5048 Internet Small Computer System Interface (iSCSI) Corrections and Clarifications. M. Chadalapaka, Ed.. October 2007. (Format: TXT, HTML) (Obsoleted by RFC7143) (Updates RFC3720) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5048) 5049 Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP). C. Bormann, Z. Liu, R. Price, G. Camarillo, Ed.. December 2007. (Format: TXT, HTML) (Updates RFC3486) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5049) 5050 Bundle Protocol Specification. K. Scott, S. Burleigh. November 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5050) 5051 i;unicode-casemap - Simple Unicode Collation Algorithm. M. Crispin. October 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5051) 5052 Forward Error Correction (FEC) Building Block. M. Watson, M. Luby, L. Vicisano. August 2007. (Format: TXT, HTML) (Obsoletes RFC3452) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5052) 5053 Raptor Forward Error Correction Scheme for Object Delivery. M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer. October 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5053) 5054 Using the Secure Remote Password (SRP) Protocol for TLS Authentication. D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin. November 2007. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5054) 5055 Server-Based Certificate Validation Protocol (SCVP). T. Freeman, R. Housley, A. Malpani, D. Cooper, W. Polk. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5055) 5056 On the Use of Channel Bindings to Secure Channels. N. Williams. November 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5056) 5057 Multiple Dialog Usages in the Session Initiation Protocol. R. Sparks. November 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5057) 5058 Explicit Multicast (Xcast) Concepts and Options. R. Boivie, N. Feldman, Y. Imai, W. Livens, D. Ooms. November 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5058) 5059 Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM). N. Bhaskar, A. Gall, J. Lingard, S. Venaas. January 2008. (Format: TXT, PDF, HTML) (Obsoletes RFC2362) (Updates RFC4601) (Updated by RFC8736) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5059) 5060 Protocol Independent Multicast MIB. R. Sivaramu, J. Lingard, D. McWalter, B. Joshi, A. Kessler. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5060) 5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration. R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, M. Kozuka. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5061) 5062 Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures. R. Stewart, M. Tuexen, G. Camarillo. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5062) 5063 Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart. A. Satyanarayana, Ed., R. Rahman, Ed.. October 2007. (Format: TXT, HTML) (Updates RFC2961, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5063) 5064 The Archived-At Message Header Field. M. Duerst. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5064) 5065 Autonomous System Confederations for BGP. P. Traina, D. McPherson, J. Scudder. August 2007. (Format: TXT, HTML) (Obsoletes RFC3065) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5065) 5066 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB. E. Beili. November 2007. (Format: TXT, HTML) (Updated by RFC7124) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5066) 5067 Infrastructure ENUM Requirements. S. Lind, P. Pfautz. November 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5067) 5068 Email Submission Operations: Access and Accountability Requirements. C. Hutzler, D. Crocker, P. Resnick, E. Allman, T. Finch. November 2007. (Format: TXT, HTML) (Updated by RFC8314) (Also BCP0134) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5068) 5069 Security Threats and Requirements for Emergency Call Marking and Mapping. T. Taylor, Ed., H. Tschofenig, H. Schulzrinne, M. Shanmugam. January 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5069) 5070 The Incident Object Description Exchange Format. R. Danyliw, J. Meijer, Y. Demchenko. December 2007. (Format: TXT, HTML) (Obsoleted by RFC7970) (Updated by RFC6685) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5070) 5071 Dynamic Host Configuration Protocol Options Used by PXELINUX. D. Hankins. December 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5071) 5072 IP Version 6 over PPP. S. Varada, Ed., D. Haskins, E. Allen. September 2007. (Format: TXT, HTML) (Obsoletes RFC2472) (Updated by RFC8064) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5072) 5073 IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities. J.P. Vasseur, Ed., J.L. Le Roux, Ed.. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5073) 5074 DNSSEC Lookaside Validation (DLV). S. Weiler. November 2007. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5074) 5075 IPv6 Router Advertisement Flags Option. B. Haberman, Ed., R. Hinden. November 2007. (Format: TXT, HTML) (Obsoleted by RFC5175) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5075) 5076 ENUM Validation Information Mapping for the Extensible Provisioning Protocol. B. Hoeneisen. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5076) 5077 Transport Layer Security (TLS) Session Resumption without Server-Side State. J. Salowey, H. Zhou, P. Eronen, H. Tschofenig. January 2008. (Format: TXT, HTML) (Obsoletes RFC4507) (Obsoleted by RFC8446) (Updated by RFC8447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5077) 5078 IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline. S. Dawkins. October 2007. (Format: TXT, HTML) (Obsoleted by RFC7437) (Updates RFC3777) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5078) 5079 Rejecting Anonymous Requests in the Session Initiation Protocol (SIP). J. Rosenberg. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5079) 5080 Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes. D. Nelson, A. DeKok. December 2007. (Format: TXT, HTML) (Updates RFC2865, RFC2866, RFC2869, RFC3579) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5080) 5081 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication. N. Mavrogiannopoulos. November 2007. (Format: TXT, HTML) (Obsoleted by RFC6091) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5081) 5082 The Generalized TTL Security Mechanism (GTSM). V. Gill, J. Heasley, D. Meyer, P. Savola, Ed., C. Pignataro. October 2007. (Format: TXT, HTML) (Obsoletes RFC3682) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5082) 5083 Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type. R. Housley. November 2007. (Format: TXT, HTML) (Updates RFC3852) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5083) 5084 Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS). R. Housley. November 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5084) 5085 Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires. T. Nadeau, Ed., C. Pignataro, Ed.. December 2007. (Format: TXT, HTML) (Updated by RFC5586) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5085) 5086 Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN). A. Vainshtein, Ed., I. Sasson, E. Metz, T. Frost, P. Pate. December 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5086) 5087 Time Division Multiplexing over IP (TDMoIP). Y(J). Stein, R. Shashoua, R. Insler, M. Anavi. December 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5087) 5088 OSPF Protocol Extensions for Path Computation Element (PCE) Discovery. JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. January 2008. (Format: TXT, HTML) (Updated by RFC9353) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5088) 5089 IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery. JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. January 2008. (Format: TXT, HTML) (Updated by RFC9353) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5089) 5090 RADIUS Extension for Digest Authentication. B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck. February 2008. (Format: TXT, HTML) (Obsoletes RFC4590) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5090) 5091 Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems. X. Boyen, L. Martin. December 2007. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5091) 5092 IMAP URL Scheme. A. Melnikov, Ed., C. Newman. November 2007. (Format: TXT, HTML) (Obsoletes RFC2192) (Updates RFC4467) (Updated by RFC5593) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5092) 5093 BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ). G. Hunt. December 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5093) 5094 Mobile IPv6 Vendor Specific Option. V. Devarapalli, A. Patel, K. Leung. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5094) 5095 Deprecation of Type 0 Routing Headers in IPv6. J. Abley, P. Savola, G. Neville-Neil. December 2007. (Format: TXT, HTML) (Updates RFC2460, RFC4294) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5095) 5096 Mobile IPv6 Experimental Messages. V. Devarapalli. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5096) 5097 MIB for the UDP-Lite protocol. G. Renker, G. Fairhurst. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5097) 5098 Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs). G. Beacham, S. Kumar, S. Channabasappa. February 2008. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5098) 5099 Not Issued. 5100 Not Issued. 5101 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information. B. Claise, Ed.. January 2008. (Format: TXT, HTML) (Obsoleted by RFC7011) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5101) 5102 Information Model for IP Flow Information Export. J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer. January 2008. (Format: TXT, HTML) (Obsoleted by RFC7012) (Updated by RFC6313) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5102) 5103 Bidirectional Flow Export Using IP Flow Information Export (IPFIX). B. Trammell, E. Boschi. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5103) 5104 Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF). S. Wenger, U. Chandra, M. Westerlund, B. Burman. February 2008. (Format: TXT, HTML) (Updated by RFC7728, RFC8082) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5104) 5105 ENUM Validation Token Format Definition. O. Lendl. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5105) 5106 The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method. H. Tschofenig, D. Kroeselberg, A. Pashalidis, Y. Ohba, F. Bersani. February 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5106) 5107 DHCP Server Identifier Override Suboption. R. Johnson, J. Kumarasamy, K. Kinnear, M. Stapp. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5107) 5108 Not Issued. 5109 RTP Payload Format for Generic Forward Error Correction. A. Li, Ed.. December 2007. (Format: TXT, HTML) (Obsoletes RFC2733, RFC3009) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5109) 5110 Overview of the Internet Multicast Routing Architecture. P. Savola. January 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5110) 5111 Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF). B. Aboba, L. Dondeti. January 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5111) 5112 The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp). M. Garcia-Martin. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5112) 5113 Network Discovery and Selection Problem. J. Arkko, B. Aboba, J. Korhonen, Ed., F. Bari. January 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5113) 5114 Additional Diffie-Hellman Groups for Use with IETF Standards. M. Lepinski, S. Kent. January 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5114) 5115 Telephony Routing over IP (TRIP) Attribute for Resource Priority. K. Carlberg, P. O'Hanlon. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5115) 5116 An Interface and Algorithms for Authenticated Encryption. D. McGrew. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5116) 5117 RTP Topologies. M. Westerlund, S. Wenger. January 2008. (Format: TXT, HTML) (Obsoleted by RFC7667) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5117) 5118 Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6). V. Gurbani, C. Boulton, R. Sparks. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5118) 5119 A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE). T. Edwards. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5119) 5120 M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs). T. Przygienda, N. Shen, N. Sheth. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5120) 5121 Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks. B. Patil, F. Xia, B. Sarikaya, JH. Choi, S. Madanapalli. February 2008. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5121) 5122 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre. February 2008. (Format: TXT, HTML) (Obsoletes RFC4622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5122) 5123 Considerations in Validating the Path in BGP. R. White, B. Akyol. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5123) 5124 Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF). J. Ott, E. Carrara. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5124) 5125 Reclassification of RFC 3525 to Historic. T. Taylor. February 2008. (Format: TXT, HTML) (Obsoletes RFC3525) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5125) 5126 CMS Advanced Electronic Signatures (CAdES). D. Pinkas, N. Pope, J. Ross. March 2008. (Format: TXT, HTML) (Obsoletes RFC3126) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5126) 5127 Aggregation of Diffserv Service Classes. K. Chan, J. Babiarz, F. Baker. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5127) 5128 State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs). P. Srisuresh, B. Ford, D. Kegel. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5128) 5129 Explicit Congestion Marking in MPLS. B. Davie, B. Briscoe, J. Tay. January 2008. (Format: TXT, HTML) (Updates RFC3032) (Updated by RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5129) 5130 A Policy Control Mechanism in IS-IS Using Administrative Tags. S. Previdi, M. Shand, Ed., C. Martin. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5130) 5131 A MIB Textual Convention for Language Tags. D. McWalter, Ed.. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5131) 5132 IP Multicast MIB. D. McWalter, D. Thaler, A. Kessler. December 2007. (Format: TXT, HTML) (Obsoletes RFC2932) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5132) 5133 Terminal Endpoint Identifier (TEI) Query Request Number Change. M. Tuexen, K. Morneault. December 2007. (Format: TXT, HTML) (Updates RFC4233) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5133) 5134 A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards. M. Mealling. January 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5134) 5135 IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT). D. Wing, T. Eckert. February 2008. (Format: TXT, HTML) (Also BCP0135) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5135) 5136 Defining Network Capacity. P. Chimento, J. Ishac. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5136) 5137 ASCII Escaping of Unicode Characters. J. Klensin. February 2008. (Format: TXT, HTML) (Also BCP0137) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5137) 5138 A Uniform Resource Name (URN) Namespace for the Commission for the Management and Application of Geoscience Information (CGI). S. Cox. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5138) 5139 Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO). M. Thomson, J. Winterbottom. February 2008. (Format: TXT, HTML) (Updates RFC4119) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5139) 5140 A Telephony Gateway REgistration Protocol (TGREP). M. Bangalore, R. Kumar, J. Rosenberg, H. Salama, D.N. Shah. March 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5140) 5141 A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO). J. Goodwin, H. Apel. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5141) 5142 Mobility Header Home Agent Switch Message. B. Haley, V. Devarapalli, H. Deng, J. Kempf. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5142) 5143 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation. A. Malis, J. Brayley, J. Shirron, L. Martini, S. Vogelsang. February 2008. (Format: TXT, HTML) (Obsoleted by RFC4842) (Status: HISTORIC) (DOI: 10.17487/RFC5143) 5144 A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS). A. Newton, M. Sanz. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5144) 5145 Framework for MPLS-TE to GMPLS Migration. K. Shiomoto, Ed.. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5145) 5146 Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks. K. Kumaki, Ed.. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5146) 5147 URI Fragment Identifiers for the text/plain Media Type. E. Wilde, M. Duerst. April 2008. (Format: TXT, HTML) (Updates RFC2046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5147) 5148 Jitter Considerations in Mobile Ad Hoc Networks (MANETs). T. Clausen, C. Dearlove, B. Adamson. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5148) 5149 Service Selection for Mobile IPv6. J. Korhonen, U. Nilsson, V. Devarapalli. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5149) 5150 Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE). A. Ayyangar, K. Kompella, JP. Vasseur, A. Farrel. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5150) 5151 Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions. A. Farrel, Ed., A. Ayyangar, JP. Vasseur. February 2008. (Format: TXT, HTML) (Updates RFC3209, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5151) 5152 A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs). JP. Vasseur, Ed., A. Ayyangar, Ed., R. Zhang. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5152) 5153 IP Flow Information Export (IPFIX) Implementation Guidelines. E. Boschi, L. Mark, J. Quittek, M. Stiemerling, P. Aitken. April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5153) 5154 IP over IEEE 802.16 Problem Statement and Goals. J. Jee, Ed., S. Madanapalli, J. Mandin. April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5154) 5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. B. Laurie, G. Sisson, R. Arends, D. Blacka. March 2008. (Format: TXT, HTML) (Updated by RFC6840, RFC6944, RFC9077, RFC9157, RFC9276) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5155) 5156 Special-Use IPv6 Addresses. M. Blanchet. April 2008. (Format: TXT, HTML) (Obsoleted by RFC6890) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5156) 5157 IPv6 Implications for Network Scanning. T. Chown. March 2008. (Format: TXT, HTML) (Obsoleted by RFC7707) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5157) 5158 6to4 Reverse DNS Delegation Specification. G. Huston. March 2008. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5158) 5159 Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection. L. Dondeti, Ed., A. Jerichow. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5159) 5160 Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS). P. Levis, M. Boucadair. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5160) 5161 The IMAP ENABLE Extension. A. Gulbrandsen, Ed., A. Melnikov, Ed.. March 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5161) 5162 IMAP4 Extensions for Quick Mailbox Resynchronization. A. Melnikov, D. Cridland, C. Wilson. March 2008. (Format: TXT, HTML) (Obsoleted by RFC7162) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5162) 5163 Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE). G. Fairhurst, B. Collini-Nocker. April 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5163) 5164 Mobility Services Transport: Problem Statement. T. Melia, Ed.. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5164) 5165 A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC). C. Reed. April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5165) 5166 Metrics for the Evaluation of Congestion Control Mechanisms. S. Floyd, Ed.. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5166) 5167 Media Server Control Protocol Requirements. M. Dolly, R. Even. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5167) 5168 XML Schema for Media Control. O. Levin, R. Even, P. Hagendorf. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5168) 5169 Handover Key Management and Re-Authentication Problem Statement. T. Clancy, M. Nakhjiri, V. Narayanan, L. Dondeti. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5169) 5170 Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes. V. Roca, C. Neumann, D. Furodet. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5170) 5171 Cisco Systems UniDirectional Link Detection (UDLD) Protocol. M. Foschiano. April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5171) 5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol. S. Varada, Ed.. March 2008. (Format: TXT, HTML) (Obsoletes RFC2472) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5172) 5173 Sieve Email Filtering: Body Extension. J. Degener, P. Guenther. April 2008. (Format: TXT, HTML) (Updates RFC5229) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5173) 5174 A Uniform Resource Name (URN) Namespace for the European Broadcasting Union (EBU). J-P. Evain. May 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5174) 5175 IPv6 Router Advertisement Flags Option. B. Haberman, Ed., R. Hinden. March 2008. (Format: TXT, HTML) (Obsoletes RFC5075) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5175) 5176 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS). M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba. January 2008. (Format: TXT, HTML) (Obsoletes RFC3576) (Updated by RFC8559) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5176) 5177 Network Mobility (NEMO) Extensions for Mobile IPv4. K. Leung, G. Dommety, V. Narayanan, A. Petrescu. April 2008. (Format: TXT, HTML) (Updated by RFC6626) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5177) 5178 Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type. N. Williams, A. Melnikov. May 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5178) 5179 Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism. N. Williams. May 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5179) 5180 IPv6 Benchmarking Methodology for Network Interconnect Devices. C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin. May 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5180) 5181 IPv6 Deployment Scenarios in 802.16 Networks. M-K. Shin, Ed., Y-H. Han, S-E. Kim, D. Premec. May 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5181) 5182 IMAP Extension for Referencing the Last SEARCH Result. A. Melnikov. March 2008. (Format: TXT, HTML) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5182) 5183 Sieve Email Filtering: Environment Extension. N. Freed. May 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5183) 5184 Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover. F. Teraoka, K. Gogo, K. Mitsuya, R. Shibui, K. Mitani. May 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5184) 5185 OSPF Multi-Area Adjacency. S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal. May 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5185) 5186 Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction. B. Haberman, J. Martin. May 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5186) 5187 OSPFv3 Graceful Restart. P. Pillay-Esnault, A. Lindem. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5187) 5188 RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec. H. Desineni, Q. Xie. February 2008. (Format: TXT, HTML) (Updates RFC4788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5188) 5189 Middlebox Communication (MIDCOM) Protocol Semantics. M. Stiemerling, J. Quittek, T. Taylor. March 2008. (Format: TXT, HTML) (Obsoletes RFC3989) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5189) 5190 Definitions of Managed Objects for Middlebox Communication. J. Quittek, M. Stiemerling, P. Srisuresh. March 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5190) 5191 Protocol for Carrying Authentication for Network Access (PANA). D. Forsberg, Y. Ohba, Ed., B. Patil, H. Tschofenig, A. Yegin. May 2008. (Format: TXT, HTML) (Updated by RFC5872) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5191) 5192 DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents. L. Morand, A. Yegin, S. Kumar, S. Madanapalli. May 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5192) 5193 Protocol for Carrying Authentication for Network Access (PANA) Framework. P. Jayaraman, R. Lopez, Y. Ohba, Ed., M. Parthasarathy, A. Yegin. May 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5193) 5194 Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP). A. van Wijk, Ed., G. Gybels, Ed.. June 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5194) 5195 BGP-Based Auto-Discovery for Layer-1 VPNs. H. Ould-Brahim, D. Fedyk, Y. Rekhter. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5195) 5196 Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF). M. Lonnfors, K. Kiss. September 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5196) 5197 On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions. S. Fries, D. Ignjatic. June 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5197) 5198 Unicode Format for Network Interchange. J. Klensin, M. Padlipsky. March 2008. (Format: TXT, HTML) (Obsoletes RFC0698) (Updates RFC0854) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5198) 5199 Not Issued. 5200 Not Issued. 5201 Host Identity Protocol. R. Moskowitz, P. Nikander, P. Jokela, Ed., T. Henderson. April 2008. (Format: TXT, HTML) (Obsoleted by RFC7401) (Updated by RFC6253) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5201) 5202 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP). P. Jokela, R. Moskowitz, P. Nikander. April 2008. (Format: TXT, HTML) (Obsoleted by RFC7402) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5202) 5203 Host Identity Protocol (HIP) Registration Extension. J. Laganier, T. Koponen, L. Eggert. April 2008. (Format: TXT, HTML) (Obsoleted by RFC8003) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5203) 5204 Host Identity Protocol (HIP) Rendezvous Extension. J. Laganier, L. Eggert. April 2008. (Format: TXT, HTML) (Obsoleted by RFC8004) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5204) 5205 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions. P. Nikander, J. Laganier. April 2008. (Format: TXT, HTML) (Obsoleted by RFC8005) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5205) 5206 End-Host Mobility and Multihoming with the Host Identity Protocol. P. Nikander, T. Henderson, Ed., C. Vogt, J. Arkko. April 2008. (Format: TXT, HTML) (Obsoleted by RFC8046) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5206) 5207 NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication. M. Stiemerling, J. Quittek, L. Eggert. April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5207) 5208 Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2. B. Kaliski. May 2008. (Format: TXT, HTML) (Obsoleted by RFC5958) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5208) 5209 Network Endpoint Assessment (NEA): Overview and Requirements. P. Sangster, H. Khosravi, M. Mani, K. Narayan, J. Tardo. June 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5209) 5210 A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience. J. Wu, J. Bi, X. Li, G. Ren, K. Xu, M. Williams. June 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5210) 5211 An Internet Transition Plan. J. Curran. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5211) 5212 Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN). K. Shiomoto, D. Papadimitriou, JL. Le Roux, M. Vigoureux, D. Brungard. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5212) 5213 Proxy Mobile IPv6. S. Gundavelli, Ed., K. Leung, V. Devarapalli, K. Chowdhury, B. Patil. August 2008. (Format: TXT, HTML) (Updated by RFC6543, RFC7864) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5213) 5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). F. Templin, T. Gleeson, D. Thaler. March 2008. (Format: TXT, HTML) (Obsoletes RFC4214) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5214) 5215 RTP Payload Format for Vorbis Encoded Audio. L. Barbato. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5215) 5216 The EAP-TLS Authentication Protocol. D. Simon, B. Aboba, R. Hurst. March 2008. (Format: TXT, HTML) (Obsoletes RFC2716) (Updated by RFC8996, RFC9190) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5216) 5217 Memorandum for Multi-Domain Public Key Infrastructure Interoperability. M. Shimaoka, Ed., N. Hastings, R. Nielsen. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5217) 5218 What Makes for a Successful Protocol?. D. Thaler, B. Aboba. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5218) 5219 A More Loss-Tolerant RTP Payload Format for MP3 Audio. R. Finlayson. February 2008. (Format: TXT, HTML) (Obsoletes RFC3119) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5219) 5220 Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules. A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5220) 5221 Requirements for Address Selection Mechanisms. A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5221) 5222 LoST: A Location-to-Service Translation Protocol. T. Hardie, A. Newton, H. Schulzrinne, H. Tschofenig. August 2008. (Format: TXT, HTML) (Updated by RFC6848, RFC8917, RFC9036) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5222) 5223 Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP). H. Schulzrinne, J. Polk, H. Tschofenig. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5223) 5224 Diameter Policy Processing Application. M. Brenner. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5224) 5225 RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite. G. Pelletier, K. Sandlund. April 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5225) 5226 Guidelines for Writing an IANA Considerations Section in RFCs. T. Narten, H. Alvestrand. May 2008. (Format: TXT, HTML) (Obsoletes RFC2434) (Obsoleted by RFC8126) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5226) 5227 IPv4 Address Conflict Detection. S. Cheshire. July 2008. (Format: TXT, HTML) (Updates RFC0826) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5227) 5228 Sieve: An Email Filtering Language. P. Guenther, Ed., T. Showalter, Ed.. January 2008. (Format: TXT, HTML) (Obsoletes RFC3028) (Updated by RFC5229, RFC5429, RFC6785, RFC9042) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5228) 5229 Sieve Email Filtering: Variables Extension. K. Homme. January 2008. (Format: TXT, HTML) (Updates RFC5228) (Updated by RFC5173) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5229) 5230 Sieve Email Filtering: Vacation Extension. T. Showalter, N. Freed, Ed.. January 2008. (Format: TXT, HTML) (Updated by RFC8580) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5230) 5231 Sieve Email Filtering: Relational Extension. W. Segmuller, B. Leiba. January 2008. (Format: TXT, HTML) (Obsoletes RFC3431) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5231) 5232 Sieve Email Filtering: Imap4flags Extension. A. Melnikov. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5232) 5233 Sieve Email Filtering: Subaddress Extension. K. Murchison. January 2008. (Format: TXT, HTML) (Obsoletes RFC3598) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5233) 5234 Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., P. Overell. January 2008. (Format: TXT, HTML) (Obsoletes RFC4234) (Updated by RFC7405) (Also STD0068) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5234) 5235 Sieve Email Filtering: Spamtest and Virustest Extensions. C. Daboo. January 2008. (Format: TXT, HTML) (Obsoletes RFC3685) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5235) 5236 Improved Packet Reordering Metrics. A. Jayasumana, N. Piratla, T. Banka, A. Bare, R. Whitner. June 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5236) 5237 IANA Allocation Guidelines for the Protocol Field. J. Arkko, S. Bradner. February 2008. (Format: TXT, HTML) (Updates RFC2780) (Also BCP0037) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5237) 5238 Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). T. Phelan. May 2008. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5238) 5239 A Framework for Centralized Conferencing. M. Barnes, C. Boulton, O. Levin. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5239) 5240 Protocol Independent Multicast (PIM) Bootstrap Router MIB. B. Joshi, R. Bijlani. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5240) 5241 Naming Rights in IETF Protocols. A. Falk, S. Bradner. 1 April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5241) 5242 A Generalized Unified Character Code: Western European and CJK Sections. J. Klensin, H. Alvestrand. 1 April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5242) 5243 OSPF Database Exchange Summary List Optimization. R. Ogier. May 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5243) 5244 Definition of Events for Channel-Oriented Telephony Signalling. H. Schulzrinne, T. Taylor. June 2008. (Format: TXT, HTML) (Updates RFC4733) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5244) 5245 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. J. Rosenberg. April 2010. (Format: TXT, HTML) (Obsoletes RFC4091, RFC4092) (Obsoleted by RFC8445, RFC8839) (Updated by RFC6336) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5245) 5246 The Transport Layer Security (TLS) Protocol Version 1.2. T. Dierks, E. Rescorla. August 2008. (Format: TXT, HTML) (Obsoletes RFC3268, RFC4346, RFC4366) (Obsoleted by RFC8446) (Updates RFC4492) (Updated by RFC5746, RFC5878, RFC6176, RFC7465, RFC7507, RFC7568, RFC7627, RFC7685, RFC7905, RFC7919, RFC8447, RFC9155) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5246) 5247 Extensible Authentication Protocol (EAP) Key Management Framework. B. Aboba, D. Simon, P. Eronen. August 2008. (Format: TXT, HTML) (Updates RFC3748) (Updated by RFC8940) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5247) 5248 A Registry for SMTP Enhanced Mail System Status Codes. T. Hansen, J. Klensin. June 2008. (Format: TXT, HTML) (Updates RFC3463, RFC4468, RFC4954) (Also BCP0138) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5248) 5249 Templates for Internet-Drafts Containing MIB Modules. D. Harrington, Ed.. July 2008. (Format: TXT, HTML) (Also BCP0139) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5249) 5250 The OSPF Opaque LSA Option. L. Berger, I. Bryskin, A. Zinin, R. Coltun. July 2008. (Format: TXT, HTML) (Obsoletes RFC2370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5250) 5251 Layer 1 VPN Basic Mode. D. Fedyk, Ed., Y. Rekhter, Ed., D. Papadimitriou, R. Rabbat, L. Berger. July 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5251) 5252 OSPF-Based Layer 1 VPN Auto-Discovery. I. Bryskin, L. Berger. July 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5252) 5253 Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode. T. Takeda, Ed.. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5253) 5254 Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3). N. Bitar, Ed., M. Bocci, Ed., L. Martini, Ed.. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5254) 5255 Internet Message Access Protocol Internationalization. C. Newman, A. Gulbrandsen, A. Melnikov. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5255) 5256 Internet Message Access Protocol - SORT and THREAD Extensions. M. Crispin, K. Murchison. June 2008. (Format: TXT, HTML) (Updated by RFC5957) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5256) 5257 Internet Message Access Protocol - ANNOTATE Extension. C. Daboo, R. Gellens. June 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5257) 5258 Internet Message Access Protocol version 4 - LIST Command Extensions. B. Leiba, A. Melnikov. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5258) 5259 Internet Message Access Protocol - CONVERT Extension. A. Melnikov, Ed., P. Coates, Ed.. July 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5259) 5260 Sieve Email Filtering: Date and Index Extensions. N. Freed. July 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5260) 5261 An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors. J. Urpalainen. September 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5261) 5262 Presence Information Data Format (PIDF) Extension for Partial Presence. M. Lonnfors, E. Leppanen, H. Khartabil, J. Urpalainen. September 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5262) 5263 Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information. M. Lonnfors, J. Costa-Requena, E. Leppanen, H. Khartabil. September 2008. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5263) 5264 Publication of Partial Presence Information. A. Niemi, M. Lonnfors, E. Leppanen. September 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5264) 5265 Mobile IPv4 Traversal across IPsec-Based VPN Gateways. S. Vaarala, E. Klovning. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5265) 5266 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE). V. Devarapalli, P. Eronen. June 2008. (Format: TXT, HTML) (Also BCP0136) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5266) 5267 Contexts for IMAP4. D. Cridland, C. King. July 2008. (Format: TXT, HTML) (Updated by RFC5465) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5267) 5268 Mobile IPv6 Fast Handovers. R. Koodli, Ed.. June 2008. (Format: TXT, HTML) (Obsoletes RFC4068) (Obsoleted by RFC5568) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5268) 5269 Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND). J. Kempf, R. Koodli. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5269) 5270 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks. H. Jang, J. Jee, Y. Han, S. Park, J. Cha. June 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5270) 5271 Mobile IPv6 Fast Handovers for 3G CDMA Networks. H. Yokota, G. Dommety. June 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5271) 5272 Certificate Management over CMS (CMC). J. Schaad, M. Myers. June 2008. (Format: TXT, HTML) (Obsoletes RFC2797) (Updated by RFC6402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5272) 5273 Certificate Management over CMS (CMC): Transport Protocols. J. Schaad, M. Myers. June 2008. (Format: TXT, HTML) (Updated by RFC6402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5273) 5274 Certificate Management Messages over CMS (CMC): Compliance Requirements. J. Schaad, M. Myers. June 2008. (Format: TXT, HTML) (Updated by RFC6402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5274) 5275 CMS Symmetric Key Management and Distribution. S. Turner. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5275) 5276 Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records. C. Wallace. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5276) 5277 NETCONF Event Notifications. S. Chisholm, H. Trevino. July 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5277) 5278 IANA Registration of Enumservices for Voice and Video Messaging. J. Livingood, D. Troshynski. July 2008. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5278) 5279 A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP). A. Monrad, S. Loreto. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5279) 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk. May 2008. (Format: TXT, HTML) (Obsoletes RFC3280, RFC4325, RFC4630) (Updated by RFC6818, RFC8398, RFC8399) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5280) 5281 Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0). P. Funk, S. Blake-Wilson. August 2008. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5281) 5282 Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol. D. Black, D. McGrew. August 2008. (Format: TXT, HTML) (Updates RFC4306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5282) 5283 LDP Extension for Inter-Area Label Switched Paths (LSPs). B. Decraene, JL. Le Roux, I. Minei. July 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5283) 5284 User-Defined Errors for RSVP. G. Swallow, A. Farrel. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5284) 5285 A General Mechanism for RTP Header Extensions. D. Singer, H. Desineni. July 2008. (Format: TXT, HTML) (Obsoleted by RFC8285) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5285) 5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates. A. Atlas, Ed., A. Zinin, Ed.. September 2008. (Format: TXT, HTML) (Updated by RFC8518) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5286) 5287 Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks. A. Vainshtein, Y(J). Stein. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5287) 5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS. J. Salowey, A. Choudhury, D. McGrew. August 2008. (Format: TXT, HTML) (Updated by RFC9325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5288) 5289 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM). E. Rescorla. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5289) 5290 Comments on the Usefulness of Simple Best-Effort Traffic. S. Floyd, M. Allman. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5290) 5291 Outbound Route Filtering Capability for BGP-4. E. Chen, Y. Rekhter. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5291) 5292 Address-Prefix-Based Outbound Route Filter for BGP-4. E. Chen, S. Sangli. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5292) 5293 Sieve Email Filtering: Editheader Extension. J. Degener, P. Guenther. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5293) 5294 Host Threats to Protocol Independent Multicast (PIM). P. Savola, J. Lingard. August 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5294) 5295 Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK). J. Salowey, L. Dondeti, V. Narayanan, M. Nakhjiri. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5295) 5296 EAP Extensions for EAP Re-authentication Protocol (ERP). V. Narayanan, L. Dondeti. August 2008. (Format: TXT, HTML) (Obsoleted by RFC6696) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5296) 5297 Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES). D. Harkins. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5297) 5298 Analysis of Inter-Domain Label Switched Path (LSP) Recovery. T. Takeda, Ed., A. Farrel, Ed., Y. Ikejiri, JP. Vasseur. August 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5298) 5299 Not Issued. 5300 Not Issued. 5301 Dynamic Hostname Exchange Mechanism for IS-IS. D. McPherson, N. Shen. October 2008. (Format: TXT, HTML) (Obsoletes RFC2763) (Updated by RFC6232) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5301) 5302 Domain-Wide Prefix Distribution with Two-Level IS-IS. T. Li, H. Smit, T. Przygienda. October 2008. (Format: TXT, HTML) (Obsoletes RFC2966) (Updates RFC1195) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5302) 5303 Three-Way Handshake for IS-IS Point-to-Point Adjacencies. D. Katz, R. Saluja, D. Eastlake 3rd. October 2008. (Format: TXT, HTML) (Obsoletes RFC3373) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5303) 5304 IS-IS Cryptographic Authentication. T. Li, R. Atkinson. October 2008. (Format: TXT, HTML) (Obsoletes RFC3567) (Updates RFC1195) (Updated by RFC6233, RFC6232) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5304) 5305 IS-IS Extensions for Traffic Engineering. T. Li, H. Smit. October 2008. (Format: TXT, HTML) (Obsoletes RFC3784) (Updated by RFC5307, RFC8918) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5305) 5306 Restart Signaling for IS-IS. M. Shand, L. Ginsberg. October 2008. (Format: TXT, HTML) (Obsoletes RFC3847) (Obsoleted by RFC8706) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5306) 5307 IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). K. Kompella, Ed., Y. Rekhter, Ed.. October 2008. (Format: TXT, HTML) (Obsoletes RFC4205) (Updates RFC5305) (Updated by RFC6001, RFC6002, RFC7074) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5307) 5308 Routing IPv6 with IS-IS. C. Hopps. October 2008. (Format: TXT, HTML) (Updated by RFC7775) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5308) 5309 Point-to-Point Operation over LAN in Link State Routing Protocols. N. Shen, Ed., A. Zinin, Ed.. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5309) 5310 IS-IS Generic Cryptographic Authentication. M. Bhatia, V. Manral, T. Li, R. Atkinson, R. White, M. Fanto. February 2009. (Format: TXT, HTML) (Updated by RFC6233, RFC6232) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5310) 5311 Simplified Extension of Link State PDU (LSP) Space for IS-IS. D. McPherson, Ed., L. Ginsberg, S. Previdi, M. Shand. February 2009. (Format: TXT, HTML) (Obsoletes RFC3786) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5311) 5312 Not Issued. 5313 Not Issued. 5314 Not Issued. 5315 Not Issued. 5316 ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering. M. Chen, R. Zhang, X. Duan. December 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5316) 5317 Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile. S. Bryant, Ed., L. Andersson, Ed.. February 2009. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5317) 5318 The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header). J. Hautakorpi, G. Camarillo. December 2008. (Format: TXT, HTML) (Updated by RFC8217) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5318) 5319 Not Issued. 5320 The Subnetwork Encapsulation and Adaptation Layer (SEAL). F. Templin, Ed.. February 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5320) 5321 Simple Mail Transfer Protocol. J. Klensin. October 2008. (Format: TXT, HTML) (Obsoletes RFC2821) (Updates RFC1123) (Updated by RFC7504) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5321) 5322 Internet Message Format. P. Resnick, Ed.. October 2008. (Format: TXT, HTML) (Obsoletes RFC2822) (Updates RFC4021) (Updated by RFC6854) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5322) 5323 Web Distributed Authoring and Versioning (WebDAV) SEARCH. J. Reschke, Ed., S. Reddy, J. Davis, A. Babich. November 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5323) 5324 MIB for Fibre-Channel Security Protocols (FC-SP). C. DeSanti, F. Maino, K. McCloghrie. September 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5324) 5325 Licklider Transmission Protocol - Motivation. S. Burleigh, M. Ramadas, S. Farrell. September 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5325) 5326 Licklider Transmission Protocol - Specification. M. Ramadas, S. Burleigh, S. Farrell. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5326) 5327 Licklider Transmission Protocol - Security Extensions. S. Farrell, M. Ramadas, S. Burleigh. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5327) 5328 A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB). A. Adolf, P. MacAvock. September 2008. (Format: TXT, HTML) (Updated by RFC7354, RFC8553) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5328) 5329 Traffic Engineering Extensions to OSPF Version 3. K. Ishiguro, V. Manral, A. Davey, A. Lindem, Ed.. September 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5329) 5330 A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link. JP. Vasseur, Ed., M. Meyer, K. Kumaki, A. Bonda. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5330) 5331 MPLS Upstream Label Assignment and Context-Specific Label Space. R. Aggarwal, Y. Rekhter, E. Rosen. August 2008. (Format: TXT, HTML) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5331) 5332 MPLS Multicast Encapsulations. T. Eckert, E. Rosen, Ed., R. Aggarwal, Y. Rekhter. August 2008. (Format: TXT, HTML) (Updates RFC3032, RFC4023) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5332) 5333 IANA Registration of Enumservices for Internet Calendaring. R. Mahy, B. Hoeneisen. October 2009. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5333) 5334 Ogg Media Types. I. Goncalves, S. Pfeiffer, C. Montgomery. September 2008. (Format: TXT, HTML) (Obsoletes RFC3534) (Updated by RFC7845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5334) 5335 Internationalized Email Headers. A. Yang, Ed.. September 2008. (Format: TXT, HTML) (Obsoleted by RFC6532) (Updates RFC2045, RFC2822) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5335) 5336 SMTP Extension for Internationalized Email Addresses. J. Yao, Ed., W. Mao, Ed.. September 2008. (Format: TXT, HTML) (Obsoleted by RFC6531) (Updates RFC2821, RFC2822, RFC4952) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5336) 5337 Internationalized Delivery Status and Disposition Notifications. C. Newman, A. Melnikov, Ed.. September 2008. (Format: TXT, HTML) (Obsoleted by RFC6533) (Updates RFC3461, RFC3462, RFC3464, RFC3798) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5337) 5338 Using the Host Identity Protocol with Legacy Applications. T. Henderson, P. Nikander, M. Komu. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5338) 5339 Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN). JL. Le Roux, Ed., D. Papadimitriou, Ed.. September 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5339) 5340 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy, A. Lindem. July 2008. (Format: TXT, HTML) (Obsoletes RFC2740) (Updated by RFC6845, RFC6860, RFC7503, RFC8362) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5340) 5341 The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry. C. Jennings, V. Gurbani. September 2008. (Format: TXT, HTML) (Updates RFC3966) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5341) 5342 IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters. D. Eastlake 3rd. September 2008. (Format: TXT, HTML) (Obsoleted by RFC7042) (Updates RFC2153) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5342) 5343 Simple Network Management Protocol (SNMP) Context EngineID Discovery. J. Schoenwaelder. September 2008. (Format: TXT, HTML) (Updates RFC3411) (Also STD0078) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5343) 5344 Presence and Instant Messaging Peering Use Cases. A. Houri, E. Aoki, S. Parameswar. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5344) 5345 Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats. J. Schoenwaelder. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5345) 5346 Operational Requirements for ENUM-Based Softswitch Use. J. Lim, W. Kim, C. Park, L. Conroy. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5346) 5347 Media Gateway Control Protocol Fax Package. F. Andreasen, D. Hancock. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5347) 5348 TCP Friendly Rate Control (TFRC): Protocol Specification. S. Floyd, M. Handley, J. Padhye, J. Widmer. September 2008. (Format: TXT, HTML) (Obsoletes RFC3448) (Updates RFC4342) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5348) 5349 Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). L. Zhu, K. Jaganathan, K. Lauter. September 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5349) 5350 IANA Considerations for the IPv4 and IPv6 Router Alert Options. J. Manner, A. McDonald. September 2008. (Format: TXT, HTML) (Updates RFC2113, RFC3175) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5350) 5351 An Overview of Reliable Server Pooling Protocols. P. Lei, L. Ong, M. Tuexen, T. Dreibholz. September 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5351) 5352 Aggregate Server Access Protocol (ASAP). R. Stewart, Q. Xie, M. Stillman, M. Tuexen. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5352) 5353 Endpoint Handlespace Redundancy Protocol (ENRP). Q. Xie, R. Stewart, M. Stillman, M. Tuexen, A. Silverton. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5353) 5354 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters. R. Stewart, Q. Xie, M. Stillman, M. Tuexen. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5354) 5355 Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats. M. Stillman, Ed., R. Gopal, E. Guttman, S. Sengodan, M. Holdrege. September 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5355) 5356 Reliable Server Pooling Policies. T. Dreibholz, M. Tuexen. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5356) 5357 A Two-Way Active Measurement Protocol (TWAMP). K. Hedayat, R. Krzanowski, A. Morton, K. Yum, J. Babiarz. October 2008. (Format: TXT, HTML) (Updated by RFC5618, RFC5938, RFC6038, RFC7717, RFC7750, RFC8545) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5357) 5358 Preventing Use of Recursive Nameservers in Reflector Attacks. J. Damas, F. Neves. October 2008. (Format: TXT, HTML) (Also BCP0140) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5358) 5359 Session Initiation Protocol Service Examples. A. Johnston, Ed., R. Sparks, C. Cunningham, S. Donovan, K. Summers. October 2008. (Format: TXT, HTML) (Also BCP0144) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5359) 5360 A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP). J. Rosenberg, G. Camarillo, Ed., D. Willis. October 2008. (Format: TXT, HTML) (Updated by RFC8217) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5360) 5361 A Document Format for Requesting Consent. G. Camarillo. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5361) 5362 The Session Initiation Protocol (SIP) Pending Additions Event Package. G. Camarillo. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5362) 5363 Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services. G. Camarillo, A.B. Roach. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5363) 5364 Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists. M. Garcia-Martin, G. Camarillo. October 2008. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5364) 5365 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP). M. Garcia-Martin, G. Camarillo. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5365) 5366 Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP). G. Camarillo, A. Johnston. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5366) 5367 Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP). G. Camarillo, A.B. Roach, O. Levin. October 2008. (Format: TXT, HTML) (Updates RFC3265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5367) 5368 Referring to Multiple Resources in the Session Initiation Protocol (SIP). G. Camarillo, A. Niemi, M. Isomaki, M. Garcia-Martin, H. Khartabil. October 2008. (Format: TXT, HTML) (Updated by RFC8262) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5368) 5369 Framework for Transcoding with the Session Initiation Protocol (SIP). G. Camarillo. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5369) 5370 The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model. G. Camarillo. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5370) 5371 RTP Payload Format for JPEG 2000 Video Streams. S. Futemma, E. Itakura, A. Leung. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5371) 5372 Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery. A. Leung, S. Futemma, E. Itakura. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5372) 5373 Requesting Answering Modes for the Session Initiation Protocol (SIP). D. Willis, Ed., A. Allen. November 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5373) 5374 Multicast Extensions to the Security Architecture for the Internet Protocol. B. Weis, G. Gross, D. Ignjatic. November 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5374) 5375 IPv6 Unicast Address Assignment Considerations. G. Van de Velde, C. Popoviciu, T. Chown, O. Bonness, C. Hahn. December 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5375) 5376 Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP). N. Bitar, R. Zhang, K. Kumaki. November 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5376) 5377 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents. J. Halpern, Ed.. November 2008. (Format: TXT, HTML) (Obsoleted by RFC8721) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5377) 5378 Rights Contributors Provide to the IETF Trust. S. Bradner, Ed., J. Contreras, Ed.. November 2008. (Format: TXT, HTML) (Obsoletes RFC3978, RFC4748) (Updates RFC2026) (Also BCP0078) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5378) 5379 Guidelines for Using the Privacy Mechanism for SIP. M. Munakata, S. Schubert, T. Ohba. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5379) 5380 Hierarchical Mobile IPv6 (HMIPv6) Mobility Management. H. Soliman, C. Castelluccia, K. ElMalki, L. Bellier. October 2008. (Format: TXT, HTML) (Obsoletes RFC4140) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5380) 5381 Experience of Implementing NETCONF over SOAP. T. Iijima, Y. Atarashi, H. Kimura, M. Kitani, H. Okita. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5381) 5382 NAT Behavioral Requirements for TCP. S. Guha, Ed., K. Biswas, B. Ford, S. Sivakumar, P. Srisuresh. October 2008. (Format: TXT, HTML) (Updated by RFC7857) (Also BCP0142) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5382) 5383 Deployment Considerations for Lemonade-Compliant Mobile Email. R. Gellens. October 2008. (Format: TXT, HTML) (Also BCP0143) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5383) 5384 The Protocol Independent Multicast (PIM) Join Attribute Format. A. Boers, I. Wijnands, E. Rosen. November 2008. (Format: TXT, HTML) (Updated by RFC7887) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5384) 5385 Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs. J. Touch. February 2010. (Format: TXT, HTML) (Obsoletes RFC3285) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5385) 5386 Better-Than-Nothing Security: An Unauthenticated Mode of IPsec. N. Williams, M. Richardson. November 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5386) 5387 Problem and Applicability Statement for Better-Than-Nothing Security (BTNS). J. Touch, D. Black, Y. Wang. November 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5387) 5388 Information Model and XML Data Model for Traceroute Measurements. S. Niccolini, S. Tartarelli, J. Quittek, T. Dietz, M. Swany. December 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5388) 5389 Session Traversal Utilities for NAT (STUN). J. Rosenberg, R. Mahy, P. Matthews, D. Wing. October 2008. (Format: TXT, HTML) (Obsoletes RFC3489) (Obsoleted by RFC8489) (Updated by RFC7350, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5389) 5390 Requirements for Management of Overload in the Session Initiation Protocol. J. Rosenberg. December 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5390) 5391 RTP Payload Format for ITU-T Recommendation G.711.1. A. Sollaud. November 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5391) 5392 OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering. M. Chen, R. Zhang, X. Duan. January 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5392) 5393 Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies. R. Sparks, Ed., S. Lawrence, A. Hawrylyshen, B. Campen. December 2008. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5393) 5394 Policy-Enabled Path Computation Framework. I. Bryskin, D. Papadimitriou, L. Berger, J. Ash. December 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5394) 5395 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd. November 2008. (Format: TXT, HTML) (Obsoletes RFC2929) (Obsoleted by RFC6195) (Updates RFC1183, RFC3597) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5395) 5396 Textual Representation of Autonomous System (AS) Numbers. G. Huston, G. Michaelson. December 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5396) 5397 WebDAV Current Principal Extension. W. Sanchez, C. Daboo. December 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5397) 5398 Autonomous System (AS) Number Reservation for Documentation Use. G. Huston. December 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5398) 5399 Not Issued. 5400 Not Issued. 5401 Multicast Negative-Acknowledgment (NACK) Building Blocks. B. Adamson, C. Bormann, M. Handley, J. Macker. November 2008. (Format: TXT, HTML) (Obsoletes RFC3941) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5401) 5402 Compressed Data within an Internet Electronic Data Interchange (EDI) Message. T. Harding, Ed.. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5402) 5403 RPCSEC_GSS Version 2. M. Eisler. February 2009. (Format: TXT, HTML) (Updates RFC2203) (Updated by RFC7861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5403) 5404 RTP Payload Format for G.719. M. Westerlund, I. Johansson. January 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5404) 5405 Unicast UDP Usage Guidelines for Application Designers. L. Eggert, G. Fairhurst. November 2008. (Format: TXT, HTML) (Obsoleted by RFC8085) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5405) 5406 Guidelines for Specifying the Use of IPsec Version 2. S. Bellovin. February 2009. (Format: TXT, HTML) (Also BCP0146) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5406) 5407 Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP). M. Hasebe, J. Koshiko, Y. Suzuki, T. Yoshikawa, P. Kyzivat. December 2008. (Format: TXT, HTML) (Also BCP0147) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5407) 5408 Identity-Based Encryption Architecture and Supporting Data Structures. G. Appenzeller, L. Martin, M. Schertler. January 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5408) 5409 Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS). L. Martin, M. Schertler. January 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5409) 5410 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0. A. Jerichow, Ed., L. Piron. January 2009. (Format: TXT, HTML) (Obsoletes RFC4909) (Updated by RFC6309) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5410) 5411 A Hitchhiker's Guide to the Session Initiation Protocol (SIP). J. Rosenberg. February 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5411) 5412 Lightweight Access Point Protocol. P. Calhoun, R. Suri, N. Cam-Winget, M. Williams, S. Hares, B. O'Hara, S. Kelly. February 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5412) 5413 SLAPP: Secure Light Access Point Protocol. P. Narasimhan, D. Harkins, S. Ponnuswamy. February 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5413) 5414 Wireless LAN Control Protocol (WiCoP). S. Iino, S. Govindan, M. Sugiura, H. Cheng. February 2010. (Format: TXT, HTML) (Obsoleted by RFC5415) (Status: HISTORIC) (DOI: 10.17487/RFC5414) 5415 Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification. P. Calhoun, Ed., M. Montemurro, Ed., D. Stanley, Ed.. March 2009. (Format: TXT, HTML) (Obsoletes RFC5414) (Updated by RFC8553, RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5415) 5416 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11. P. Calhoun, Ed., M. Montemurro, Ed., D. Stanley, Ed.. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5416) 5417 Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option. P. Calhoun. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5417) 5418 Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments. S. Kelly, T. Clancy. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5418) 5419 Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6). B. Patil, G. Dommety. January 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5419) 5420 Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE). A. Farrel, Ed., D. Papadimitriou, JP. Vasseur, A. Ayyangar. February 2009. (Format: TXT, HTML) (Obsoletes RFC4420) (Updates RFC3209, RFC3473) (Updated by RFC6510) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5420) 5421 Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST). N. Cam-Winget, H. Zhou. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5421) 5422 Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST). N. Cam-Winget, D. McGrew, J. Salowey, H. Zhou. March 2009. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5422) 5423 Internet Message Store Events. R. Gellens, C. Newman. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5423) 5424 The Syslog Protocol. R. Gerhards. March 2009. (Format: TXT, HTML) (Obsoletes RFC3164) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5424) 5425 Transport Layer Security (TLS) Transport Mapping for Syslog. F. Miao, Ed., Y. Ma, Ed., J. Salowey, Ed.. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5425) 5426 Transmission of Syslog Messages over UDP. A. Okmianski. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5426) 5427 Textual Conventions for Syslog Management. G. Keeni. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5427) 5428 Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices. S. Channabasappa, W. De Ketelaere, E. Nechamkin. April 2009. (Format: TXT, HTML) (Updated by RFC9141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5428) 5429 Sieve Email Filtering: Reject and Extended Reject Extensions. A. Stone, Ed.. March 2009. (Format: TXT, HTML) (Obsoletes RFC3028) (Updates RFC5228) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5429) 5430 Suite B Profile for Transport Layer Security (TLS). M. Salter, E. Rescorla, R. Housley. March 2009. (Format: TXT, HTML) (Obsoleted by RFC6460) (Status: HISTORIC) (DOI: 10.17487/RFC5430) 5431 Diameter ITU-T Rw Policy Enforcement Interface Application. D. Sun. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5431) 5432 Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP). J. Polk, S. Dhesikan, G. Camarillo. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5432) 5433 Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method. T. Clancy, H. Tschofenig. February 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5433) 5434 Considerations for Having a Successful Birds-of-a-Feather (BOF) Session. T. Narten. February 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5434) 5435 Sieve Email Filtering: Extension for Notifications. A. Melnikov, Ed., B. Leiba, Ed., W. Segmuller, T. Martin. January 2009. (Format: TXT, HTML) (Updated by RFC8580) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5435) 5436 Sieve Notification Mechanism: mailto. B. Leiba, M. Haardt. January 2009. (Format: TXT, HTML) (Updates RFC3834) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5436) 5437 Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre, A. Melnikov. January 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5437) 5438 Instant Message Disposition Notification (IMDN). E. Burger, H. Khartabil. February 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5438) 5439 An Analysis of Scaling Issues in MPLS-TE Core Networks. S. Yasukawa, A. Farrel, O. Komolafe. February 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5439) 5440 Path Computation Element (PCE) Communication Protocol (PCEP). JP. Vasseur, Ed., JL. Le Roux, Ed.. March 2009. (Format: TXT, HTML) (Updated by RFC7896, RFC8253, RFC8356) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5440) 5441 A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths. JP. Vasseur, Ed., R. Zhang, N. Bitar, JL. Le Roux. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5441) 5442 LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail. E. Burger, G. Parsons. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5442) 5443 LDP IGP Synchronization. M. Jork, A. Atlas, L. Fang. March 2009. (Format: TXT, HTML) (Updated by RFC6138) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5443) 5444 Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format. T. Clausen, C. Dearlove, J. Dean, C. Adjih. February 2009. (Format: TXT, HTML) (Updated by RFC7631, RFC8245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5444) 5445 Basic Forward Error Correction (FEC) Schemes. M. Watson. March 2009. (Format: TXT, HTML) (Obsoletes RFC3452, RFC3695) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5445) 5446 Service Selection for Mobile IPv4. J. Korhonen, U. Nilsson. February 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5446) 5447 Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction. J. Korhonen, Ed., J. Bournelle, H. Tschofenig, C. Perkins, K. Chowdhury. February 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5447) 5448 Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA'). J. Arkko, V. Lehtovirta, P. Eronen. May 2009. (Format: TXT, HTML) (Updates RFC4187) (Updated by RFC9048) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5448) 5449 OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks. E. Baccelli, P. Jacquet, D. Nguyen, T. Clausen. February 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5449) 5450 Transmission Time Offsets in RTP Streams. D. Singer, H. Desineni. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5450) 5451 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. April 2009. (Format: TXT, HTML) (Obsoleted by RFC7001) (Updated by RFC6577) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5451) 5452 Measures for Making DNS More Resilient against Forged Answers. A. Hubert, R. van Mook. January 2009. (Format: TXT, HTML) (Updates RFC2181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5452) 5453 Reserved IPv6 Interface Identifiers. S. Krishnan. February 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5453) 5454 Dual-Stack Mobile IPv4. G. Tsirtsis, V. Park, H. Soliman. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5454) 5455 Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol. S. Sivabalan, Ed., J. Parker, S. Boutros, K. Kumaki. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5455) 5456 IAX: Inter-Asterisk eXchange Version 2. M. Spencer, B. Capouch, E. Guy, Ed., F. Miller, K. Shumard. February 2010. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5456) 5457 IANA Considerations for IAX: Inter-Asterisk eXchange Version 2. E. Guy, Ed.. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5457) 5458 Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol. H. Cruickshank, P. Pillai, M. Noisternig, S. Iyengar. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5458) 5459 G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support. A. Sollaud. January 2009. (Format: TXT, HTML) (Updates RFC4749) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5459) 5460 DHCPv6 Bulk Leasequery. M. Stapp. February 2009. (Format: TXT, HTML) (Updated by RFC7653) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5460) 5461 TCP's Reaction to Soft Errors. F. Gont. February 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5461) 5462 Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field. L. Andersson, R. Asati. February 2009. (Format: TXT, HTML) (Updates RFC3032, RFC3270, RFC3272, RFC3443, RFC3469, RFC3564, RFC3985, RFC4182, RFC4364, RFC4379, RFC4448, RFC4761, RFC5129) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5462) 5463 Sieve Email Filtering: Ihave Extension. N. Freed. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5463) 5464 The IMAP METADATA Extension. C. Daboo. February 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5464) 5465 The IMAP NOTIFY Extension. A. Gulbrandsen, C. King, A. Melnikov. February 2009. (Format: TXT, HTML) (Updates RFC5267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5465) 5466 IMAP4 Extension for Named Searches (Filters). A. Melnikov, C. King. February 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5466) 5467 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). L. Berger, A. Takacs, D. Caviglia, D. Fedyk, J. Meuric. March 2009. (Format: TXT, HTML) (Obsoleted by RFC6387) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5467) 5468 Performance Analysis of Inter-Domain Path Computation Methodologies. S. Dasgupta, J. de Oliveira, JP. Vasseur. April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5468) 5469 DES and IDEA Cipher Suites for Transport Layer Security (TLS). P. Eronen, Ed.. February 2009. (Format: TXT, HTML) (Obsoleted by RFC8996) (Status: HISTORIC) (DOI: 10.17487/RFC5469) 5470 Architecture for IP Flow Information Export. G. Sadasivan, N. Brownlee, B. Claise, J. Quittek. March 2009. (Format: TXT, HTML) (Updated by RFC6183) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5470) 5471 Guidelines for IP Flow Information Export (IPFIX) Testing. C. Schmoll, P. Aitken, B. Claise. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5471) 5472 IP Flow Information Export (IPFIX) Applicability. T. Zseby, E. Boschi, N. Brownlee, B. Claise. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5472) 5473 Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports. E. Boschi, L. Mark, B. Claise. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5473) 5474 A Framework for Packet Selection and Reporting. N. Duffield, Ed., D. Chiou, B. Claise, A. Greenberg, M. Grossglauser, J. Rexford. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5474) 5475 Sampling and Filtering Techniques for IP Packet Selection. T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. Raspall. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5475) 5476 Packet Sampling (PSAMP) Protocol Specifications. B. Claise, Ed., A. Johnson, J. Quittek. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5476) 5477 Information Model for Packet Sampling Exports. T. Dietz, B. Claise, P. Aitken, F. Dressler, G. Carle. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5477) 5478 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces. J. Polk. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5478) 5479 Requirements and Analysis of Media Security Management Protocols. D. Wing, Ed., S. Fries, H. Tschofenig, F. Audet. April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5479) 5480 Elliptic Curve Cryptography Subject Public Key Information. S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk. March 2009. (Format: TXT, HTML) (Updates RFC3279) (Updated by RFC8813) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5480) 5481 Packet Delay Variation Applicability Statement. A. Morton, B. Claise. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5481) 5482 TCP User Timeout Option. L. Eggert, F. Gont. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5482) 5483 ENUM Implementation Issues and Experiences. L. Conroy, K. Fujiwara. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5483) 5484 Associating Time-Codes with RTP Streams. D. Singer. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5484) 5485 Digital Signatures on Internet-Draft Documents. R. Housley. March 2009. (Format: TXT, HTML) (Updated by RFC8358) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5485) 5486 Session Peering for Multimedia Interconnect (SPEERMINT) Terminology. D. Malas, Ed., D. Meyer, Ed.. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5486) 5487 Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode. M. Badra. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5487) 5488 Network Mobility (NEMO) Management Information Base. S. Gundavelli, G. Keeni, K. Koide, K. Nagami. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5488) 5489 ECDHE_PSK Cipher Suites for Transport Layer Security (TLS). M. Badra, I. Hajjeh. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5489) 5490 The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata. A. Melnikov. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5490) 5491 GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations. J. Winterbottom, M. Thomson, H. Tschofenig. March 2009. (Format: TXT, HTML) (Updates RFC4119) (Updated by RFC7459) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5491) 5492 Capabilities Advertisement with BGP-4. J. Scudder, R. Chandra. February 2009. (Format: TXT, HTML) (Obsoletes RFC3392) (Updated by RFC8810) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5492) 5493 Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network. D. Caviglia, D. Bramanti, D. Li, D. McDysan. April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5493) 5494 IANA Allocation Guidelines for the Address Resolution Protocol (ARP). J. Arkko, C. Pignataro. April 2009. (Format: TXT, HTML) (Updates RFC0826, RFC0951, RFC1044, RFC1329, RFC2131, RFC2132, RFC2176, RFC2225, RFC2834, RFC2835, RFC3315, RFC4338, RFC4361, RFC4701) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5494) 5495 Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures. D. Li, J. Gao, A. Satyanarayana, S. Bardalai. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5495) 5496 The Reverse Path Forwarding (RPF) Vector TLV. IJ. Wijnands, A. Boers, E. Rosen. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5496) 5497 Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs). T. Clausen, C. Dearlove. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5497) 5498 IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols. I. Chakeres. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5498) 5499 Not Issued. 5500 Not Issued. 5501 Requirements for Multicast Support in Virtual Private LAN Services. Y. Kamite, Ed., Y. Wada, Y. Serbest, T. Morin, L. Fang. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5501) 5502 The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem. J. van Elburg. April 2009. (Format: TXT, HTML) (Updated by RFC8217, RFC8498) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5502) 5503 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture. F. Andreasen, B. McKibben, B. Marshall. March 2009. (Format: TXT, HTML) (Obsoletes RFC3603) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5503) 5504 Downgrading Mechanism for Email Address Internationalization. K. Fujiwara, Ed., Y. Yoneya, Ed.. March 2009. (Format: TXT, HTML) (Obsoleted by RFC6530) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5504) 5505 Principles of Internet Host Configuration. B. Aboba, D. Thaler, L. Andersson, S. Cheshire. May 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5505) 5506 Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences. I. Johansson, M. Westerlund. April 2009. (Format: TXT, HTML) (Updates RFC3550, RFC3711, RFC4585) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5506) 5507 Design Choices When Expanding the DNS. IAB, P. Faltstrom, Ed., R. Austein, Ed., P. Koch, Ed.. April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5507) 5508 NAT Behavioral Requirements for ICMP. P. Srisuresh, B. Ford, S. Sivakumar, S. Guha. April 2009. (Format: TXT, HTML) (Updated by RFC7857) (Also BCP0148) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5508) 5509 Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP). S. Loreto. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5509) 5510 Reed-Solomon Forward Error Correction (FEC) Schemes. J. Lacan, V. Roca, J. Peltotalo, S. Peltotalo. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5510) 5511 Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications. A. Farrel. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5511) 5512 The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute. P. Mohapatra, E. Rosen. April 2009. (Format: TXT, HTML) (Obsoleted by RFC9012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5512) 5513 IANA Considerations for Three Letter Acronyms. A. Farrel. 1 April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5513) 5514 IPv6 over Social Networks. E. Vyncke. 1 April 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5514) 5515 Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions. V. Mammoliti, C. Pignataro, P. Arberg, J. Gibbons, P. Howard. May 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5515) 5516 Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). M. Jones, L. Morand. April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5516) 5517 Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment. S. HomChaudhuri, M. Foschiano. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5517) 5518 Vouch By Reference. P. Hoffman, J. Levine, A. Hathcock. April 2009. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5518) 5519 Multicast Group Membership Discovery MIB. J. Chesterfield, B. Haberman, Ed.. April 2009. (Format: TXT, HTML) (Obsoletes RFC2933, RFC3019) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5519) 5520 Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism. R. Bradford, Ed., JP. Vasseur, A. Farrel. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5520) 5521 Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions. E. Oki, T. Takeda, A. Farrel. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5521) 5522 Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks. W. Eddy, W. Ivancic, T. Davis. October 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5522) 5523 OSPFv3-Based Layer 1 VPN Auto-Discovery. L. Berger. April 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5523) 5524 Extended URLFETCH for Binary and Converted Parts. D. Cridland. May 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5524) 5525 Reliable Server Pooling MIB Module Definition. T. Dreibholz, J. Mulik. April 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5525) 5526 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM. J. Livingood, P. Pfautz, R. Stastny. April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5526) 5527 Combined User and Infrastructure ENUM in the e164.arpa Tree. M. Haberler, O. Lendl, R. Stastny. May 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5527) 5528 Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms. A. Kato, M. Kanda, S. Kanno. April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5528) 5529 Modes of Operation for Camellia for Use with IPsec. A. Kato, M. Kanda, S. Kanno. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5529) 5530 IMAP Response Codes. A. Gulbrandsen. May 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5530) 5531 RPC: Remote Procedure Call Protocol Specification Version 2. R. Thurlow. May 2009. (Format: TXT, HTML) (Obsoletes RFC1831) (Updated by RFC9289) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5531) 5532 Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement. T. Talpey, C. Juszczak. May 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5532) 5533 Shim6: Level 3 Multihoming Shim Protocol for IPv6. E. Nordmark, M. Bagnulo. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5533) 5534 Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming. J. Arkko, I. van Beijnum. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5534) 5535 Hash-Based Addresses (HBA). M. Bagnulo. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5535) 5536 Netnews Article Format. K. Murchison, Ed., C. Lindsey, D. Kohn. November 2009. (Format: TXT, HTML) (Obsoletes RFC1036, RFC1849) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5536) 5537 Netnews Architecture and Protocols. R. Allbery, Ed., C. Lindsey. November 2009. (Format: TXT, HTML) (Obsoletes RFC1036, RFC1849) (Updated by RFC8315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5537) 5538 The 'news' and 'nntp' URI Schemes. F. Ellermann. April 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5538) 5539 NETCONF over Transport Layer Security (TLS). M. Badra. May 2009. (Format: TXT, HTML) (Obsoleted by RFC7589) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5539) 5540 40 Years of RFCs. RFC Editor. April 2009. (Format: TXT, HTML) (Updated by RFC8700) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5540) 5541 Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP). JL. Le Roux, JP. Vasseur, Y. Lee. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5541) 5542 Definitions of Textual Conventions for Pseudowire (PW) Management. T. Nadeau, Ed., D. Zelig, Ed., O. Nicklass, Ed.. May 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5542) 5543 BGP Traffic Engineering Attribute. H. Ould-Brahim, D. Fedyk, Y. Rekhter. May 2009. (Format: TXT, HTML) (Updated by RFC7606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5543) 5544 Syntax for Binding Documents with Time-Stamps. A. Santoni. February 2010. (Format: TXT, HTML) (Updated by RFC5955) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5544) 5545 Internet Calendaring and Scheduling Core Object Specification (iCalendar). B. Desruisseaux, Ed.. September 2009. (Format: TXT, HTML) (Obsoletes RFC2445) (Updated by RFC5546, RFC6868, RFC7529, RFC7953, RFC7986, RFC9073, RFC9074, RFC9253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5545) 5546 iCalendar Transport-Independent Interoperability Protocol (iTIP). C. Daboo, Ed.. December 2009. (Format: TXT, HTML) (Obsoletes RFC2446) (Updates RFC5545) (Updated by RFC6638) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5546) 5547 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer. M. Garcia-Martin, M. Isomaki, G. Camarillo, S. Loreto, P. Kyzivat. May 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5547) 5548 Routing Requirements for Urban Low-Power and Lossy Networks. M. Dohler, Ed., T. Watteyne, Ed., T. Winter, Ed., D. Barthel, Ed.. May 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5548) 5549 Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop. F. Le Faucheur, E. Rosen. May 2009. (Format: TXT, HTML) (Obsoleted by RFC8950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5549) 5550 The Internet Email to Support Diverse Service Environments (Lemonade) Profile. D. Cridland, Ed., A. Melnikov, Ed., S. Maes, Ed.. August 2009. (Format: TXT, HTML) (Obsoletes RFC4550) (Updates RFC4469, RFC4467) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5550) 5551 Lemonade Notifications Architecture. R. Gellens, Ed.. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5551) 5552 SIP Interface to VoiceXML Media Services. D. Burke, M. Scott. May 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5552) 5553 Resource Reservation Protocol (RSVP) Extensions for Path Key Support. A. Farrel, Ed., R. Bradford, JP. Vasseur. May 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5553) 5554 Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings. N. Williams. May 2009. (Format: TXT, HTML) (Updates RFC2743) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5554) 5555 Mobile IPv6 Support for Dual Stack Hosts and Routers. H. Soliman, Ed.. June 2009. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5555) 5556 Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement. J. Touch, R. Perlman. May 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5556) 5557 Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization. Y. Lee, JL. Le Roux, D. King, E. Oki. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5557) 5558 Virtual Enterprise Traversal (VET). F. Templin, Ed.. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5558) 5559 Pre-Congestion Notification (PCN) Architecture. P. Eardley, Ed.. June 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5559) 5560 A One-Way Packet Duplication Metric. H. Uijterwaal. May 2009. (Format: TXT, HTML) (Updated by RFC6248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5560) 5561 LDP Capabilities. B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5561) 5562 Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets. A. Kuzmanovic, A. Mondal, S. Floyd, K. Ramakrishnan. June 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5562) 5563 WiMAX Forum / 3GPP2 Proxy Mobile IPv4. K. Leung, G. Dommety, P. Yegani, K. Chowdhury. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5563) 5564 Linguistic Guidelines for the Use of the Arabic Language in Internet Domains. A. El-Sherbiny, M. Farah, I. Oueichek, A. Al-Zoman. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5564) 5565 Softwire Mesh Framework. J. Wu, Y. Cui, C. Metz, E. Rosen. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5565) 5566 BGP IPsec Tunnel Encapsulation Attribute. L. Berger, R. White, E. Rosen. June 2009. (Format: TXT, HTML) (Obsoleted by RFC9012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5566) 5567 An Architectural Framework for Media Server Control. T. Melanchuk, Ed.. June 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5567) 5568 Mobile IPv6 Fast Handovers. R. Koodli, Ed.. July 2009. (Format: TXT, HTML) (Obsoletes RFC5268) (Updated by RFC7411) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5568) 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd). R. Despres. January 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5569) 5570 Common Architecture Label IPv6 Security Option (CALIPSO). M. StJohns, R. Atkinson, G. Thomas. July 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5570) 5571 Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2). B. Storer, C. Pignataro, Ed., M. Dos Santos, B. Stevant, Ed., L. Toutain, J. Tremblay. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5571) 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP). M. Blanchet, F. Parent. February 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5572) 5573 Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP). M. Thomson. June 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5573) 5574 RTP Payload Format for the Speex Codec. G. Herlein, J. Valin, A. Heggestad, A. Moizard. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5574) 5575 Dissemination of Flow Specification Rules. P. Marques, N. Sheth, R. Raszuk, B. Greene, J. Mauch, D. McPherson. August 2009. (Format: TXT, HTML) (Obsoleted by RFC8955) (Updated by RFC7674) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5575) 5576 Source-Specific Media Attributes in the Session Description Protocol (SDP). J. Lennox, J. Ott, T. Schierl. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5576) 5577 RTP Payload Format for ITU-T Recommendation G.722.1. P. Luthi, R. Even. July 2009. (Format: TXT, HTML) (Obsoletes RFC3047) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5577) 5578 PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics. B. Berry, Ed., S. Ratliff, E. Paradise, T. Kaiser, M. Adams. February 2010. (Format: TXT, HTML) (Obsoletes RFC4938) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5578) 5579 Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces. F. Templin, Ed.. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5579) 5580 Carrying Location Objects in RADIUS and Diameter. H. Tschofenig, Ed., F. Adrangi, M. Jones, A. Lior, B. Aboba. August 2009. (Format: TXT, HTML) (Updated by RFC8559) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5580) 5581 The Camellia Cipher in OpenPGP. D. Shaw. June 2009. (Format: TXT, HTML) (Updates RFC4880) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5581) 5582 Location-to-URL Mapping Architecture and Framework. H. Schulzrinne. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5582) 5583 Signaling Media Decoding Dependency in the Session Description Protocol (SDP). T. Schierl, S. Wenger. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5583) 5584 RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family. M. Hatanaka, J. Matsumoto. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5584) 5585 DomainKeys Identified Mail (DKIM) Service Overview. T. Hansen, D. Crocker, P. Hallam-Baker. July 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5585) 5586 MPLS Generic Associated Channel. M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed.. June 2009. (Format: TXT, HTML) (Updates RFC3032, RFC4385, RFC5085) (Updated by RFC6423, RFC7026, RFC7214, RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5586) 5587 Extended Generic Security Service Mechanism Inquiry APIs. N. Williams. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5587) 5588 Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials. N. Williams. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5588) 5589 Session Initiation Protocol (SIP) Call Control - Transfer. R. Sparks, A. Johnston, Ed., D. Petrie. June 2009. (Format: TXT, HTML) (Also BCP0149) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5589) 5590 Transport Subsystem for the Simple Network Management Protocol (SNMP). D. Harrington, J. Schoenwaelder. June 2009. (Format: TXT, HTML) (Updates RFC3411, RFC3412, RFC3414, RFC3417) (Also STD0078) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5590) 5591 Transport Security Model for the Simple Network Management Protocol (SNMP). D. Harrington, W. Hardaker. June 2009. (Format: TXT, HTML) (Also STD0078) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5591) 5592 Secure Shell Transport Model for the Simple Network Management Protocol (SNMP). D. Harrington, J. Salowey, W. Hardaker. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5592) 5593 Internet Message Access Protocol (IMAP) - URL Access Identifier Extension. N. Cook. June 2009. (Format: TXT, HTML) (Updates RFC5092) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5593) 5594 Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008. J. Peterson, A. Cooper. July 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5594) 5595 The Datagram Congestion Control Protocol (DCCP) Service Codes. G. Fairhurst. September 2009. (Format: TXT, HTML) (Updates RFC4340) (Updated by RFC6335) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5595) 5596 Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal. G. Fairhurst. September 2009. (Format: TXT, HTML) (Updates RFC4340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5596) 5597 Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol. R. Denis-Courmont. September 2009. (Format: TXT, HTML) (Also BCP0150) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5597) 5598 Internet Mail Architecture. D. Crocker. July 2009. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5598) 5599 Not Issued. 5600 Not Issued. 5601 Pseudowire (PW) Management Information Base (MIB). T. Nadeau, Ed., D. Zelig, Ed.. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5601) 5602 Pseudowire (PW) over MPLS PSN Management Information Base (MIB). D. Zelig, Ed., T. Nadeau, Ed.. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5602) 5603 Ethernet Pseudowire (PW) Management Information Base (MIB). D. Zelig, Ed., T. Nadeau, Ed.. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5603) 5604 Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs). O. Nicklass. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5604) 5605 Managed Objects for ATM over Packet Switched Networks (PSNs). O. Nicklass, T. Nadeau. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5605) 5606 Implications of 'retransmission-allowed' for SIP Location Conveyance. J. Peterson, T. Hardie, J. Morris. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5606) 5607 Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management. D. Nelson, G. Weber. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5607) 5608 Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models. K. Narayan, D. Nelson. August 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5608) 5609 State Machines for the Protocol for Carrying Authentication for Network Access (PANA). V. Fajardo, Ed., Y. Ohba, R. Marin-Lopez. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5609) 5610 Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements. E. Boschi, B. Trammell, L. Mark, T. Zseby. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5610) 5611 Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires. A. Vainshtein, S. Galtzur. August 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5611) 5612 Enterprise Number for Documentation Use. P. Eronen, D. Harrington. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5612) 5613 OSPF Link-Local Signaling. A. Zinin, A. Roy, L. Nguyen, B. Friedman, D. Yeung. August 2009. (Format: TXT, HTML) (Obsoletes RFC4813) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5613) 5614 Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding. R. Ogier, P. Spagnolo. August 2009. (Format: TXT, HTML) (Updated by RFC7038) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5614) 5615 H.248/MEGACO Registration Procedures. C. Groves, Y. Lin. August 2009. (Format: TXT, HTML) (Also BCP0151) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5615) 5616 Streaming Internet Messaging Attachments. N. Cook. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5616) 5617 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP). E. Allman, J. Fenton, M. Delany, J. Levine. August 2009. (Format: TXT, HTML) (Updated by RFC8553) (Status: HISTORIC) (DOI: 10.17487/RFC5617) 5618 Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP). A. Morton, K. Hedayat. August 2009. (Format: TXT, HTML) (Updates RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5618) 5619 Softwire Security Analysis and Requirements. S. Yamamoto, C. Williams, H. Yokota, F. Parent. August 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5619) 5620 RFC Editor Model (Version 1). O. Kolkman, Ed., IAB. August 2009. (Format: TXT, HTML) (Obsoleted by RFC6548, RFC6635) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5620) 5621 Message Body Handling in the Session Initiation Protocol (SIP). G. Camarillo. September 2009. (Format: TXT, HTML) (Updates RFC3204, RFC3261, RFC3459) (Updated by RFC8262) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5621) 5622 Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP). S. Floyd, E. Kohler. August 2009. (Format: TXT, HTML) (Updated by RFC6323, RFC8311) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5622) 5623 Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering. E. Oki, T. Takeda, JL. Le Roux, A. Farrel. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5623) 5624 Quality of Service Parameters for Usage with Diameter. J. Korhonen, Ed., H. Tschofenig, E. Davies. August 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5624) 5625 DNS Proxy Implementation Guidelines. R. Bellis. August 2009. (Format: TXT, HTML) (Also BCP0152) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5625) 5626 Managing Client-Initiated Connections in the Session Initiation Protocol (SIP). C. Jennings, Ed., R. Mahy, Ed., F. Audet, Ed.. October 2009. (Format: TXT, HTML) (Updates RFC3261, RFC3327) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5626) 5627 Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP). J. Rosenberg. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5627) 5628 Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs). P. Kyzivat. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5628) 5629 A Framework for Application Interaction in the Session Initiation Protocol (SIP). J. Rosenberg. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5629) 5630 The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP). F. Audet. October 2009. (Format: TXT, HTML) (Updates RFC3261, RFC3608) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5630) 5631 Session Initiation Protocol (SIP) Session Mobility. R. Shacham, H. Schulzrinne, S. Thakolsri, W. Kellerer. October 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5631) 5632 Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial. C. Griffiths, J. Livingood, L. Popkin, R. Woundy, Y. Yang. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5632) 5633 Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers. S. Dawkins, Ed.. August 2009. (Format: TXT, HTML) (Obsoleted by RFC7437) (Updates RFC3777) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5633) 5634 Quick-Start for the Datagram Congestion Control Protocol (DCCP). G. Fairhurst, A. Sathiaseelan. August 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5634) 5635 Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF). W. Kumari, D. McPherson. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5635) 5636 Traceable Anonymous Certificate. S. Park, H. Park, Y. Won, J. Lee, S. Kent. August 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5636) 5637 Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6. G. Giaretta, I. Guardini, E. Demaria, J. Bournelle, R. Lopez. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5637) 5638 Simple SIP Usage Scenario for Applications in the Endpoints. H. Sinnreich, Ed., A. Johnston, E. Shim, K. Singh. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5638) 5639 Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation. M. Lochter, J. Merkle. March 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5639) 5640 Load-Balancing for Mesh Softwires. C. Filsfils, P. Mohapatra, C. Pignataro. August 2009. (Format: TXT, HTML) (Updated by RFC9012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5640) 5641 Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values. N. McGill, C. Pignataro. August 2009. (Format: TXT, HTML) (Updates RFC3931, RFC4349, RFC4454, RFC4591, RFC4719) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5641) 5642 Dynamic Hostname Exchange Mechanism for OSPF. S. Venkata, S. Harwani, C. Pignataro, D. McPherson. August 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5642) 5643 Management Information Base for OSPFv3. D. Joyal, Ed., V. Manral, Ed.. August 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5643) 5644 IP Performance Metrics (IPPM): Spatial and Multicast. E. Stephan, L. Liang, A. Morton. October 2009. (Format: TXT, HTML) (Updated by RFC6248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5644) 5645 Update to the Language Subtag Registry. D. Ewell, Ed.. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5645) 5646 Tags for Identifying Languages. A. Phillips, Ed., M. Davis, Ed.. September 2009. (Format: TXT, HTML) (Obsoletes RFC4646) (Also BCP0047) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5646) 5647 AES Galois Counter Mode for the Secure Shell Transport Layer Protocol. K. Igoe, J. Solinas. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5647) 5648 Multiple Care-of Addresses Registration. R. Wakikawa, Ed., V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami. October 2009. (Format: TXT, HTML) (Updated by RFC6089) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5648) 5649 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm. R. Housley, M. Dworkin. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5649) 5650 Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2). M. Morgenstern, S. Baillie, U. Bonollo. September 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5650) 5651 Layered Coding Transport (LCT) Building Block. M. Luby, M. Watson, L. Vicisano. October 2009. (Format: TXT, HTML) (Obsoletes RFC3451) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5651) 5652 Cryptographic Message Syntax (CMS). R. Housley. September 2009. (Format: TXT, HTML) (Obsoletes RFC3852) (Updated by RFC8933) (Also STD0070) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5652) 5653 Generic Security Service API Version 2: Java Bindings Update. M. Upadhyay, S. Malkani. August 2009. (Format: TXT, HTML) (Obsoletes RFC2853) (Obsoleted by RFC8353) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5653) 5654 Requirements of an MPLS Transport Profile. B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed., N. Sprecher, S. Ueno. September 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5654) 5655 Specification of the IP Flow Information Export (IPFIX) File Format. B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5655) 5656 Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer. D. Stebila, J. Green. December 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5656) 5657 Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard. L. Dusseault, R. Sparks. September 2009. (Format: TXT, HTML) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5657) 5658 Addressing Record-Route Issues in the Session Initiation Protocol (SIP). T. Froment, C. Lebel, B. Bonnaerens. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5658) 5659 An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge. M. Bocci, S. Bryant. October 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5659) 5660 IPsec Channels: Connection Latching. N. Williams. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5660) 5661 Network File System (NFS) Version 4 Minor Version 1 Protocol. S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed.. January 2010. (Format: TXT, HTML) (Obsoleted by RFC8881) (Updated by RFC8178, RFC8434) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5661) 5662 Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description. S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed.. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5662) 5663 Parallel NFS (pNFS) Block/Volume Layout. D. Black, S. Fridella, J. Glasgow. January 2010. (Format: TXT, HTML) (Updated by RFC6688) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5663) 5664 Object-Based Parallel NFS (pNFS) Operations. B. Halevy, B. Welch, J. Zelenka. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5664) 5665 IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats. M. Eisler. January 2010. (Format: TXT, HTML) (Updates RFC1833) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5665) 5666 Remote Direct Memory Access Transport for Remote Procedure Call. T. Talpey, B. Callaghan. January 2010. (Format: TXT, HTML) (Obsoleted by RFC8166) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5666) 5667 Network File System (NFS) Direct Data Placement. T. Talpey, B. Callaghan. January 2010. (Format: TXT, HTML) (Obsoleted by RFC8267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5667) 5668 4-Octet AS Specific BGP Extended Community. Y. Rekhter, S. Sangli, D. Tappan. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5668) 5669 The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP). S. Yoon, J. Kim, H. Park, H. Jeong, Y. Won. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5669) 5670 Metering and Marking Behaviour of PCN-Nodes. P. Eardley, Ed.. November 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5670) 5671 Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE). S. Yasukawa, A. Farrel, Ed.. October 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5671) 5672 RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update. D. Crocker, Ed.. August 2009. (Format: TXT, HTML) (Obsoleted by RFC6376) (Updates RFC4871) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5672) 5673 Industrial Routing Requirements in Low-Power and Lossy Networks. K. Pister, Ed., P. Thubert, Ed., S. Dwars, T. Phinney. October 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5673) 5674 Alarms in Syslog. S. Chisholm, R. Gerhards. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5674) 5675 Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages. V. Marinov, J. Schoenwaelder. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5675) 5676 Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications. J. Schoenwaelder, A. Clemm, A. Karmakar. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5676) 5677 IEEE 802.21 Mobility Services Framework Design (MSFD). T. Melia, Ed., G. Bajko, S. Das, N. Golmie, JC. Zuniga. December 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5677) 5678 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery. G. Bajko, S. Das. December 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5678) 5679 Locating IEEE 802.21 Mobility Services Using DNS. G. Bajko. December 2009. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5679) 5680 The Nominating Committee Process: Open Disclosure of Willing Nominees. S. Dawkins, Ed.. October 2009. (Format: TXT, HTML) (Obsoleted by RFC7437) (Updates RFC3777) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5680) 5681 TCP Congestion Control. M. Allman, V. Paxson, E. Blanton. September 2009. (Format: TXT, HTML) (Obsoletes RFC2581) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5681) 5682 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP. P. Sarolahti, M. Kojo, K. Yamamoto, M. Hata. September 2009. (Format: TXT, HTML) (Updates RFC4138) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5682) 5683 Password-Authenticated Key (PAK) Diffie-Hellman Exchange. A. Brusilovsky, I. Faynberg, Z. Zeltsan, S. Patel. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5683) 5684 Unintended Consequences of NAT Deployments with Overlapping Address Space. P. Srisuresh, B. Ford. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5684) 5685 Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2). V. Devarapalli, K. Weniger. November 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5685) 5686 RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec. Y. Hiwasaki, H. Ohmuro. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5686) 5687 GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements. H. Tschofenig, H. Schulzrinne. March 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5687) 5688 A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes. J. Rosenberg. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5688) 5689 Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV). C. Daboo. September 2009. (Format: TXT, HTML) (Updates RFC4791, RFC4918) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5689) 5690 Adding Acknowledgement Congestion Control to TCP. S. Floyd, A. Arcia, D. Ros, J. Iyengar. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5690) 5691 RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio. F. de Bont, S. Doehla, M. Schmidt, R. Sperschneider. October 2009. (Format: TXT, HTML) (Updates RFC3640) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5691) 5692 Transmission of IP over Ethernet over IEEE 802.16 Networks. H. Jeon, S. Jeong, M. Riegel. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5692) 5693 Application-Layer Traffic Optimization (ALTO) Problem Statement. J. Seedorf, E. Burger. October 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5693) 5694 Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability. G. Camarillo, Ed., IAB. November 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5694) 5695 MPLS Forwarding Benchmarking Methodology for IP Flows. A. Akhter, R. Asati, C. Pignataro. November 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5695) 5696 Baseline Encoding and Transport of Pre-Congestion Information. T. Moncaster, B. Briscoe, M. Menth. November 2009. (Format: TXT, HTML) (Obsoleted by RFC6660) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5696) 5697 Other Certificates Extension. S. Farrell. November 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5697) 5698 Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC). T. Kunz, S. Okunick, U. Pordesch. November 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5698) 5699 Not Issued. 5700 Not Issued. 5701 IPv6 Address Specific BGP Extended Community Attribute. Y. Rekhter. November 2009. (Format: TXT, HTML) (Updated by RFC7153, RFC7606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5701) 5702 Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC. J. Jansen. October 2009. (Format: TXT, HTML) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5702) 5703 Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure. T. Hansen, C. Daboo. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5703) 5704 Uncoordinated Protocol Development Considered Harmful. S. Bryant, Ed., M. Morrow, Ed., IAB. November 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5704) 5705 Keying Material Exporters for Transport Layer Security (TLS). E. Rescorla. March 2010. (Format: TXT, HTML) (Updated by RFC8446, RFC8447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5705) 5706 Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions. D. Harrington. November 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5706) 5707 Media Server Markup Language (MSML). A. Saleem, Y. Xin, G. Sharratt. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5707) 5708 X.509 Key and Signature Encoding for the KeyNote Trust Management System. A. Keromytis. January 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5708) 5709 OSPFv2 HMAC-SHA Cryptographic Authentication. M. Bhatia, V. Manral, M. Fanto, R. White, M. Barnes, T. Li, R. Atkinson. October 2009. (Format: TXT, HTML) (Updates RFC2328) (Updated by RFC7474) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5709) 5710 PathErr Message Triggered MPLS and GMPLS LSP Reroutes. L. Berger, D. Papadimitriou, JP. Vasseur. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5710) 5711 Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages. JP. Vasseur, Ed., G. Swallow, I. Minei. January 2010. (Format: TXT, HTML) (Updates RFC3209) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5711) 5712 MPLS Traffic Engineering Soft Preemption. M. Meyer, Ed., JP. Vasseur, Ed.. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5712) 5713 Security Threats and Security Requirements for the Access Node Control Protocol (ANCP). H. Moustafa, H. Tschofenig, S. De Cnodder. January 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5713) 5714 IP Fast Reroute Framework. M. Shand, S. Bryant. January 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5714) 5715 A Framework for Loop-Free Convergence. M. Shand, S. Bryant. January 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5715) 5716 Requirements for Federated File Systems. J. Lentini, C. Everhart, D. Ellard, R. Tewari, M. Naik. January 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5716) 5717 Partial Lock Remote Procedure Call (RPC) for NETCONF. B. Lengyel, M. Bjorklund. December 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5717) 5718 An In-Band Data Communication Network For the MPLS Transport Profile. D. Beller, A. Farrel. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5718) 5719 Updated IANA Considerations for Diameter Command Code Allocations. D. Romascanu, H. Tschofenig. January 2010. (Format: TXT, HTML) (Obsoleted by RFC6733) (Updates RFC3588) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5719) 5720 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER). F. Templin. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5720) 5721 POP3 Support for UTF-8. R. Gellens, C. Newman. February 2010. (Format: TXT, HTML) (Obsoleted by RFC6856) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5721) 5722 Handling of Overlapping IPv6 Fragments. S. Krishnan. December 2009. (Format: TXT, HTML) (Updates RFC2460) (Updated by RFC6946) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5722) 5723 Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption. Y. Sheffer, H. Tschofenig. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5723) 5724 URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS). E. Wilde, A. Vaha-Sipila. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5724) 5725 Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs). A. Begen, D. Hsu, M. Lague. February 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5725) 5726 Mobile IPv6 Location Privacy Solutions. Y. Qiu, F. Zhao, Ed., R. Koodli. February 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5726) 5727 Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area. J. Peterson, C. Jennings, R. Sparks. March 2010. (Format: TXT, HTML) (Obsoletes RFC3427) (Updates RFC3265, RFC3969) (Updated by RFC7957) (Also BCP0067) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5727) 5728 The SatLabs Group DVB-RCS MIB. S. Combes, P. Amundsen, M. Lambert, H-P. Lexow. March 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5728) 5729 Clarifications on the Routing of Diameter Requests Based on the Username and the Realm. J. Korhonen, Ed., M. Jones, L. Morand, T. Tsou. December 2009. (Format: TXT, HTML) (Updates RFC3588) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5729) 5730 Extensible Provisioning Protocol (EPP). S. Hollenbeck. August 2009. (Format: TXT, HTML) (Obsoletes RFC4930) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5730) 5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping. S. Hollenbeck. August 2009. (Format: TXT, HTML) (Obsoletes RFC4931) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5731) 5732 Extensible Provisioning Protocol (EPP) Host Mapping. S. Hollenbeck. August 2009. (Format: TXT, HTML) (Obsoletes RFC4932) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5732) 5733 Extensible Provisioning Protocol (EPP) Contact Mapping. S. Hollenbeck. August 2009. (Format: TXT, HTML) (Obsoletes RFC4933) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5733) 5734 Extensible Provisioning Protocol (EPP) Transport over TCP. S. Hollenbeck. August 2009. (Format: TXT, HTML) (Obsoletes RFC4934) (Updated by RFC8996) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5734) 5735 Special Use IPv4 Addresses. M. Cotton, L. Vegoda. January 2010. (Format: TXT, HTML) (Obsoletes RFC3330) (Obsoleted by RFC6890) (Updated by RFC6598) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5735) 5736 IANA IPv4 Special Purpose Address Registry. G. Huston, M. Cotton, L. Vegoda. January 2010. (Format: TXT, HTML) (Obsoleted by RFC6890) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5736) 5737 IPv4 Address Blocks Reserved for Documentation. J. Arkko, M. Cotton, L. Vegoda. January 2010. (Format: TXT, HTML) (Updates RFC1166) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5737) 5738 IMAP Support for UTF-8. P. Resnick, C. Newman. March 2010. (Format: TXT, HTML) (Obsoleted by RFC6855) (Updates RFC3501) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5738) 5739 IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2). P. Eronen, J. Laganier, C. Madson. February 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5739) 5740 NACK-Oriented Reliable Multicast (NORM) Transport Protocol. B. Adamson, C. Bormann, M. Handley, J. Macker. November 2009. (Format: TXT, HTML) (Obsoletes RFC3940) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5740) 5741 RFC Streams, Headers, and Boilerplates. L. Daigle, Ed., O. Kolkman, Ed., IAB. December 2009. (Format: TXT, HTML) (Obsoleted by RFC7841) (Updates RFC2223, RFC4844) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5741) 5742 IESG Procedures for Handling of Independent and IRTF Stream Submissions. H. Alvestrand, R. Housley. December 2009. (Format: TXT, HTML) (Obsoletes RFC3932) (Updates RFC2026, RFC3710) (Also BCP0092) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5742) 5743 Definition of an Internet Research Task Force (IRTF) Document Stream. A. Falk. December 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5743) 5744 Procedures for Rights Handling in the RFC Independent Submission Stream. R. Braden, J. Halpern. December 2009. (Format: TXT, HTML) (Updates RFC4846) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5744) 5745 Procedures for Rights Handling in the RFC IAB Stream. A. Malis, Ed., IAB. December 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5745) 5746 Transport Layer Security (TLS) Renegotiation Indication Extension. E. Rescorla, M. Ray, S. Dispensa, N. Oskov. February 2010. (Format: TXT, HTML) (Updates RFC5246, RFC4366, RFC4347, RFC4346, RFC2246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5746) 5747 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions. J. Wu, Y. Cui, X. Li, M. Xu, C. Metz. March 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5747) 5748 IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY). S. Yoon, J. Jeong, H. Kim, H. Jeong, Y. Won. August 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5748) 5749 Distribution of EAP-Based Keys for Handover and Re-Authentication. K. Hoeper, Ed., M. Nakhjiri, Y. Ohba, Ed.. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5749) 5750 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling. B. Ramsdell, S. Turner. January 2010. (Format: TXT, HTML) (Obsoletes RFC3850) (Obsoleted by RFC8550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5750) 5751 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification. B. Ramsdell, S. Turner. January 2010. (Format: TXT, HTML) (Obsoletes RFC3851) (Obsoleted by RFC8551) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5751) 5752 Multiple Signatures in Cryptographic Message Syntax (CMS). S. Turner, J. Schaad. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5752) 5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS). S. Turner, D. Brown. January 2010. (Format: TXT, HTML) (Obsoletes RFC3278) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5753) 5754 Using SHA2 Algorithms with Cryptographic Message Syntax. S. Turner. January 2010. (Format: TXT, HTML) (Updates RFC3370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5754) 5755 An Internet Attribute Certificate Profile for Authorization. S. Farrell, R. Housley, S. Turner. January 2010. (Format: TXT, HTML) (Obsoletes RFC3281) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5755) 5756 Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters. S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk. January 2010. (Format: TXT, HTML) (Updates RFC4055) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5756) 5757 Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey. T. Schmidt, M. Waehlisch, G. Fairhurst. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5757) 5758 Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA. Q. Dang, S. Santesson, K. Moriarty, D. Brown, T. Polk. January 2010. (Format: TXT, HTML) (Updates RFC3279) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5758) 5759 Suite B Certificate and Certificate Revocation List (CRL) Profile. J. Solinas, L. Zieglar. January 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5759) 5760 RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback. J. Ott, J. Chesterfield, E. Schooler. February 2010. (Format: TXT, HTML) (Updated by RFC6128) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5760) 5761 Multiplexing RTP Data and Control Packets on a Single Port. C. Perkins, M. Westerlund. April 2010. (Format: TXT, HTML) (Updates RFC3550, RFC3551) (Updated by RFC8035, RFC8858) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5761) 5762 RTP and the Datagram Congestion Control Protocol (DCCP). C. Perkins. April 2010. (Format: TXT, HTML) (Updated by RFC6773) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5762) 5763 Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS). J. Fischl, H. Tschofenig, E. Rescorla. May 2010. (Format: TXT, HTML) (Updated by RFC8842) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5763) 5764 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP). D. McGrew, E. Rescorla. May 2010. (Format: TXT, HTML) (Updated by RFC7983) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5764) 5765 Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications. H. Schulzrinne, E. Marocco, E. Ivov. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5765) 5766 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). R. Mahy, P. Matthews, J. Rosenberg. April 2010. (Format: TXT, HTML) (Obsoleted by RFC8656) (Updated by RFC8155, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5766) 5767 User-Agent-Driven Privacy Mechanism for SIP. M. Munakata, S. Schubert, T. Ohba. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5767) 5768 Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP). J. Rosenberg. April 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5768) 5769 Test Vectors for Session Traversal Utilities for NAT (STUN). R. Denis-Courmont. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5769) 5770 Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators. M. Komu, T. Henderson, H. Tschofenig, J. Melen, A. Keranen, Ed.. April 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5770) 5771 IANA Guidelines for IPv4 Multicast Address Assignments. M. Cotton, L. Vegoda, D. Meyer. March 2010. (Format: TXT, HTML) (Obsoletes RFC3138, RFC3171) (Updates RFC2780) (Also BCP0051) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5771) 5772 A Set of Possible Requirements for a Future Routing Architecture. A. Doria, E. Davies, F. Kastenholz. February 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5772) 5773 Analysis of Inter-Domain Routing Requirements and History. E. Davies, A. Doria. February 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5773) 5774 Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition. K. Wolf, A. Mayrhofer. March 2010. (Format: TXT, HTML) (Updates RFC4776) (Also BCP0154) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5774) 5775 Asynchronous Layered Coding (ALC) Protocol Instantiation. M. Luby, M. Watson, L. Vicisano. April 2010. (Format: TXT, HTML) (Obsoletes RFC3450) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5775) 5776 Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols. V. Roca, A. Francillon, S. Faurite. April 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5776) 5777 Traffic Classification and Quality of Service (QoS) Attributes for Diameter. J. Korhonen, H. Tschofenig, M. Arumaithurai, M. Jones, Ed., A. Lior. February 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5777) 5778 Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction. J. Korhonen, Ed., H. Tschofenig, J. Bournelle, G. Giaretta, M. Nakhjiri. February 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5778) 5779 Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server. J. Korhonen, Ed., J. Bournelle, K. Chowdhury, A. Muhanna, U. Meyer. February 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5779) 5780 NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN). D. MacDonald, B. Lowekamp. May 2010. (Format: TXT, HTML) (Updated by RFC8553) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5780) 5781 The rsync URI Scheme. S. Weiler, D. Ward, R. Housley. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5781) 5782 DNS Blacklists and Whitelists. J. Levine. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5782) 5783 Congestion Control in the RFC Series. M. Welzl, W. Eddy. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5783) 5784 Sieve Email Filtering: Sieves and Display Directives in XML. N. Freed, S. Vedam. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5784) 5785 Defining Well-Known Uniform Resource Identifiers (URIs). M. Nottingham, E. Hammer-Lahav. April 2010. (Format: TXT, HTML) (Obsoleted by RFC8615) (Updates RFC2616, RFC2818) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5785) 5786 Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions. R. Aggarwal, K. Kompella. March 2010. (Format: TXT, HTML) (Updates RFC3630) (Updated by RFC6827, RFC8687) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5786) 5787 OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing. D. Papadimitriou. March 2010. (Format: TXT, HTML) (Obsoleted by RFC6827) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5787) 5788 IMAP4 Keyword Registry. A. Melnikov, D. Cridland. March 2010. (Format: TXT, HTML) (Updated by RFC8621) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5788) 5789 PATCH Method for HTTP. L. Dusseault, J. Snell. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5789) 5790 Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols. H. Liu, W. Cao, H. Asaeda. February 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5790) 5791 RFC 2731 ("Encoding Dublin Core Metadata in HTML") Is Obsolete. J. Reschke, J. Kunze. February 2010. (Format: TXT, HTML) (Obsoletes RFC2731) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5791) 5792 PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC). P. Sangster, K. Narayan. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5792) 5793 PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC). R. Sahita, S. Hanna, R. Hurst, K. Narayan. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5793) 5794 A Description of the ARIA Encryption Algorithm. J. Lee, J. Lee, J. Kim, D. Kwon, C. Kim. March 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5794) 5795 The RObust Header Compression (ROHC) Framework. K. Sandlund, G. Pelletier, L-E. Jonsson. March 2010. (Format: TXT, HTML) (Obsoletes RFC4995) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5795) 5796 Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages. W. Atwood, S. Islam, M. Siami. March 2010. (Format: TXT, HTML) (Updates RFC4601) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5796) 5797 FTP Command and Extension Registry. J. Klensin, A. Hoenes. March 2010. (Format: TXT, HTML) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5797) 5798 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6. S. Nadas, Ed.. March 2010. (Format: TXT, HTML) (Obsoletes RFC3768) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5798) 5799 Not Issued. 5800 Not Issued. 5801 Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family. S. Josefsson, N. Williams. July 2010. (Format: TXT, HTML) (Updated by RFC9266) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5801) 5802 Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms. C. Newman, A. Menon-Sen, A. Melnikov, N. Williams. July 2010. (Format: TXT, HTML) (Updated by RFC7677, RFC9266) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5802) 5803 Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets. A. Melnikov. July 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5803) 5804 A Protocol for Remotely Managing Sieve Scripts. A. Melnikov, Ed., T. Martin. July 2010. (Format: TXT, HTML) (Updated by RFC7817, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5804) 5805 Lightweight Directory Access Protocol (LDAP) Transactions. K. Zeilenga. March 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5805) 5806 Diversion Indication in SIP. S. Levy, M. Mohali, Ed.. March 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5806) 5807 Definition of Master Key between PANA Client and Enforcement Point. Y. Ohba, A. Yegin. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5807) 5808 Requirements for a Location-by-Reference Mechanism. R. Marshall, Ed.. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5808) 5809 Not Issued. 5810 Forwarding and Control Element Separation (ForCES) Protocol Specification. A. Doria, Ed., J. Hadi Salim, Ed., R. Haas, Ed., H. Khosravi, Ed., W. Wang, Ed., L. Dong, R. Gopal, J. Halpern. March 2010. (Format: TXT, HTML) (Updated by RFC7121, RFC7391) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5810) 5811 SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol. J. Hadi Salim, K. Ogawa. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5811) 5812 Forwarding and Control Element Separation (ForCES) Forwarding Element Model. J. Halpern, J. Hadi Salim. March 2010. (Format: TXT, HTML) (Updated by RFC7408) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5812) 5813 Forwarding and Control Element Separation (ForCES) MIB. R. Haas. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5813) 5814 Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks. W. Sun, Ed., G. Zhang, Ed.. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5814) 5815 Definitions of Managed Objects for IP Flow Information Export. T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz. April 2010. (Format: TXT, HTML) (Obsoleted by RFC6615) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5815) 5816 ESSCertIDv2 Update for RFC 3161. S. Santesson, N. Pope. April 2010. (Format: TXT, HTML) (Updates RFC3161) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5816) 5817 Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks. Z. Ali, JP. Vasseur, A. Zamfir, J. Newton. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5817) 5818 Data Channel Status Confirmation Extensions for the Link Management Protocol. D. Li, H. Xu, S. Bardalai, J. Meuric, D. Caviglia. April 2010. (Format: TXT, HTML) (Updated by RFC6898) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5818) 5819 IMAP4 Extension for Returning STATUS Information in Extended LIST. A. Melnikov, T. Sirainen. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5819) 5820 Extensions to OSPF to Support Mobile Ad Hoc Networking. A. Roy, Ed., M. Chandra, Ed.. March 2010. (Format: TXT, HTML) (Updated by RFC7137) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5820) 5821 Not Issued. 5822 Not Issued. 5823 Not Issued. 5824 Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN. K. Kumaki, Ed., R. Zhang, Y. Kamite. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5824) 5825 Displaying Downgraded Messages for Email Address Internationalization. K. Fujiwara, B. Leiba. April 2010. (Format: TXT, HTML) (Obsoleted by RFC6530) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5825) 5826 Home Automation Routing Requirements in Low-Power and Lossy Networks. A. Brandt, J. Buron, G. Porcu. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5826) 5827 Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP). M. Allman, K. Avrachenkov, U. Ayesta, J. Blanton, P. Hurtig. May 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5827) 5828 Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework. D. Fedyk, L. Berger, L. Andersson. March 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5828) 5829 Link Relation Types for Simple Version Navigation between Web Resources. A. Brown, G. Clemm, J. Reschke, Ed.. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5829) 5830 GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms. V. Dolmatov, Ed.. March 2010. (Format: TXT, HTML) (Updated by RFC8891) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5830) 5831 GOST R 34.11-94: Hash Function Algorithm. V. Dolmatov, Ed.. March 2010. (Format: TXT, HTML) (Updated by RFC6986) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5831) 5832 GOST R 34.10-2001: Digital Signature Algorithm. V. Dolmatov, Ed.. March 2010. (Format: TXT, HTML) (Updated by RFC7091) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5832) 5833 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB. Y. Shi, Ed., D. Perkins, Ed., C. Elliott, Ed., Y. Zhang, Ed.. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5833) 5834 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11. Y. Shi, Ed., D. Perkins, Ed., C. Elliott, Ed., Y. Zhang, Ed.. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5834) 5835 Framework for Metric Composition. A. Morton, Ed., S. Van den Berghe, Ed.. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5835) 5836 Extensible Authentication Protocol (EAP) Early Authentication Problem Statement. Y. Ohba, Ed., Q. Wu, Ed., G. Zorn, Ed.. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5836) 5837 Extending ICMP for Interface and Next-Hop Identification. A. Atlas, Ed., R. Bonica, Ed., C. Pignataro, Ed., N. Shen, JR. Rivers. April 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5837) 5838 Support of Address Families in OSPFv3. A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. Aggarwal. April 2010. (Format: TXT, HTML) (Updated by RFC6969, RFC7949, RFC8362) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5838) 5839 An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification. A. Niemi, D. Willis, Ed.. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5839) 5840 Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility. K. Grewal, G. Montenegro, M. Bhatia. April 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5840) 5841 TCP Option to Denote Packet Mood. R. Hay, W. Turkal. 1 April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5841) 5842 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV). G. Clemm, J. Crawford, J. Reschke, Ed., J. Whitehead. April 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5842) 5843 Additional Hash Algorithms for HTTP Instance Digests. A. Bryan. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5843) 5844 IPv4 Support for Proxy Mobile IPv6. R. Wakikawa, S. Gundavelli. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5844) 5845 Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6. A. Muhanna, M. Khalil, S. Gundavelli, K. Leung. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5845) 5846 Binding Revocation for IPv6 Mobility. A. Muhanna, M. Khalil, S. Gundavelli, K. Chowdhury, P. Yegani. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5846) 5847 Heartbeat Mechanism for Proxy Mobile IPv6. V. Devarapalli, Ed., R. Koodli, Ed., H. Lim, N. Kant, S. Krishnan, J. Laganier. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5847) 5848 Signed Syslog Messages. J. Kelsey, J. Callas, A. Clemm. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5848) 5849 The OAuth 1.0 Protocol. E. Hammer-Lahav, Ed.. April 2010. (Format: TXT, HTML) (Obsoleted by RFC6749) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5849) 5850 A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP). R. Mahy, R. Sparks, J. Rosenberg, D. Petrie, A. Johnston, Ed.. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5850) 5851 Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks. S. Ooghe, N. Voigt, M. Platnic, T. Haag, S. Wadhwa. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5851) 5852 RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network. D. Caviglia, D. Ceccarelli, D. Bramanti, D. Li, S. Bardalai. April 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5852) 5853 Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments. J. Hautakorpi, Ed., G. Camarillo, R. Penfield, A. Hawrylyshen, M. Bhatia. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5853) 5854 The Metalink Download Description Format. A. Bryan, T. Tsujikawa, N. McNab, P. Poeml. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5854) 5855 Nameservers for IPv4 and IPv6 Reverse Zones. J. Abley, T. Manderson. May 2010. (Format: TXT, HTML) (Also BCP0155) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5855) 5856 Integration of Robust Header Compression over IPsec Security Associations. E. Ertekin, R. Jasani, C. Christou, C. Bormann. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5856) 5857 IKEv2 Extensions to Support Robust Header Compression over IPsec. E. Ertekin, C. Christou, R. Jasani, T. Kivinen, C. Bormann. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5857) 5858 IPsec Extensions to Support Robust Header Compression over IPsec. E. Ertekin, C. Christou, C. Bormann. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5858) 5859 TFTP Server Address Option for DHCPv4. R. Johnson. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5859) 5860 Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks. M. Vigoureux, Ed., D. Ward, Ed., M. Betts, Ed.. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5860) 5861 HTTP Cache-Control Extensions for Stale Content. M. Nottingham. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5861) 5862 Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE. S. Yasukawa, A. Farrel. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5862) 5863 DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations. T. Hansen, E. Siegel, P. Hallam-Baker, D. Crocker. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5863) 5864 DNS SRV Resource Records for AFS. R. Allbery. April 2010. (Format: TXT, HTML) (Updates RFC1183) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5864) 5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic. F. Baker, J. Polk, M. Dolly. May 2010. (Format: TXT, HTML) (Updates RFC4542, RFC4594) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5865) 5866 Diameter Quality-of-Service Application. D. Sun, Ed., P. McCann, H. Tschofenig, T. Tsou, A. Doria, G. Zorn, Ed.. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5866) 5867 Building Automation Routing Requirements in Low-Power and Lossy Networks. J. Martocci, Ed., P. De Mil, N. Riou, W. Vermeylen. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5867) 5868 Problem Statement on the Cross-Realm Operation of Kerberos. S. Sakane, K. Kamada, S. Zrelli, M. Ishiyama. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5868) 5869 HMAC-based Extract-and-Expand Key Derivation Function (HKDF). H. Krawczyk, P. Eronen. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5869) 5870 A Uniform Resource Identifier for Geographic Locations ('geo' URI). A. Mayrhofer, C. Spanring. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5870) 5871 IANA Allocation Guidelines for the IPv6 Routing Header. J. Arkko, S. Bradner. May 2010. (Format: TXT, HTML) (Updates RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5871) 5872 IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA). J. Arkko, A. Yegin. May 2010. (Format: TXT, HTML) (Updates RFC5191) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5872) 5873 Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA). Y. Ohba, A. Yegin. May 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5873) 5874 An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources. J. Rosenberg, J. Urpalainen. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5874) 5875 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package. J. Urpalainen, D. Willis, Ed.. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5875) 5876 Updates to Asserted Identity in the Session Initiation Protocol (SIP). J. Elwell. April 2010. (Format: TXT, HTML) (Updates RFC3325) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5876) 5877 The application/pkix-attr-cert Media Type for Attribute Certificates. R. Housley. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5877) 5878 Transport Layer Security (TLS) Authorization Extensions. M. Brown, R. Housley. May 2010. (Format: TXT, HTML) (Updates RFC5246) (Updated by RFC8447, RFC8996) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5878) 5879 Heuristics for Detecting ESP-NULL Packets. T. Kivinen, D. McDonald. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5879) 5880 Bidirectional Forwarding Detection (BFD). D. Katz, D. Ward. June 2010. (Format: TXT, HTML) (Updated by RFC7419, RFC7880, RFC8562) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5880) 5881 Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop). D. Katz, D. Ward. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5881) 5882 Generic Application of Bidirectional Forwarding Detection (BFD). D. Katz, D. Ward. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5882) 5883 Bidirectional Forwarding Detection (BFD) for Multihop Paths. D. Katz, D. Ward. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5883) 5884 Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs). R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow. June 2010. (Format: TXT, HTML) (Updates RFC1122) (Updated by RFC7726) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5884) 5885 Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV). T. Nadeau, Ed., C. Pignataro, Ed.. June 2010. (Format: TXT, HTML) (Updated by RFC6478, RFC7885) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5885) 5886 A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture. JP. Vasseur, Ed., JL. Le Roux, Y. Ikejiri. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5886) 5887 Renumbering Still Needs Work. B. Carpenter, R. Atkinson, H. Flinck. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5887) 5888 The Session Description Protocol (SDP) Grouping Framework. G. Camarillo, H. Schulzrinne. June 2010. (Format: TXT, HTML) (Obsoletes RFC3388) (Updated by RFC8843, RFC9143) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5888) 5889 IP Addressing Model in Ad Hoc Networks. E. Baccelli, Ed., M. Townsley, Ed.. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5889) 5890 Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. August 2010. (Format: TXT, HTML) (Obsoletes RFC3490) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5890) 5891 Internationalized Domain Names in Applications (IDNA): Protocol. J. Klensin. August 2010. (Format: TXT, HTML) (Obsoletes RFC3490, RFC3491) (Updates RFC3492) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5891) 5892 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA). P. Faltstrom, Ed.. August 2010. (Format: TXT, HTML) (Updated by RFC8753) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5892) 5893 Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA). H. Alvestrand, Ed., C. Karp. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5893) 5894 Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale. J. Klensin. August 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5894) 5895 Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008. P. Resnick, P. Hoffman. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5895) 5896 Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy. L. Hornquist Astrand, S. Hartman. June 2010. (Format: TXT, HTML) (Updates RFC2743, RFC2744, RFC4120, RFC4121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5896) 5897 Identification of Communications Services in the Session Initiation Protocol (SIP). J. Rosenberg. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5897) 5898 Connectivity Preconditions for Session Description Protocol (SDP) Media Streams. F. Andreasen, G. Camarillo, D. Oran, D. Wing. July 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5898) 5899 Not Issued. 5900 Not Issued. 5901 Extensions to the IODEF-Document Class for Reporting Phishing. P. Cain, D. Jevans. July 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5901) 5902 IAB Thoughts on IPv6 Network Address Translation. D. Thaler, L. Zhang, G. Lebovitz. July 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5902) 5903 Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2. D. Fu, J. Solinas. June 2010. (Format: TXT, HTML) (Obsoletes RFC4753) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5903) 5904 RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support. G. Zorn. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5904) 5905 Network Time Protocol Version 4: Protocol and Algorithms Specification. D. Mills, J. Martin, Ed., J. Burbank, W. Kasch. June 2010. (Format: TXT, HTML) (Obsoletes RFC1305, RFC4330) (Updated by RFC7822, RFC8573, RFC9109) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5905) 5906 Network Time Protocol Version 4: Autokey Specification. B. Haberman, Ed., D. Mills. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5906) 5907 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4). H. Gerstung, C. Elliott, B. Haberman, Ed.. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5907) 5908 Network Time Protocol (NTP) Server Option for DHCPv6. R. Gayraud, B. Lourdelet. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5908) 5909 Securing Neighbor Discovery Proxy: Problem Statement. J-M. Combes, S. Krishnan, G. Daley. July 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5909) 5910 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP). J. Gould, S. Hollenbeck. May 2010. (Format: TXT, HTML) (Obsoletes RFC4310) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5910) 5911 New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME. P. Hoffman, J. Schaad. June 2010. (Format: TXT, HTML) (Updated by RFC6268) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5911) 5912 New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX). P. Hoffman, J. Schaad. June 2010. (Format: TXT, HTML) (Updated by RFC6960) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5912) 5913 Clearance Attribute and Authority Clearance Constraints Certificate Extension. S. Turner, S. Chokhani. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5913) 5914 Trust Anchor Format. R. Housley, S. Ashmore, C. Wallace. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5914) 5915 Elliptic Curve Private Key Structure. S. Turner, D. Brown. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5915) 5916 Device Owner Attribute. S. Turner. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5916) 5917 Clearance Sponsor Attribute. S. Turner. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5917) 5918 Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC). R. Asati, I. Minei, B. Thomas. August 2010. (Format: TXT, HTML) (Updated by RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5918) 5919 Signaling LDP Label Advertisement Completion. R. Asati, P. Mohapatra, E. Chen, B. Thomas. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5919) 5920 Security Framework for MPLS and GMPLS Networks. L. Fang, Ed.. July 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5920) 5921 A Framework for MPLS in Transport Networks. M. Bocci, Ed., S. Bryant, Ed., D. Frost, Ed., L. Levrau, L. Berger. July 2010. (Format: TXT, HTML) (Updated by RFC6215, RFC7274) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5921) 5922 Domain Certificates in the Session Initiation Protocol (SIP). V. Gurbani, S. Lawrence, A. Jeffrey. June 2010. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5922) 5923 Connection Reuse in the Session Initiation Protocol (SIP). V. Gurbani, Ed., R. Mahy, B. Tate. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5923) 5924 Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates. S. Lawrence, V. Gurbani. June 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5924) 5925 The TCP Authentication Option. J. Touch, A. Mankin, R. Bonica. June 2010. (Format: TXT, HTML) (Obsoletes RFC2385) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5925) 5926 Cryptographic Algorithms for the TCP Authentication Option (TCP-AO). G. Lebovitz, E. Rescorla. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5926) 5927 ICMP Attacks against TCP. F. Gont. July 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5927) 5928 Traversal Using Relays around NAT (TURN) Resolution Mechanism. M. Petit-Huguenin. August 2010. (Format: TXT, HTML) (Updated by RFC7350, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5928) 5929 Channel Bindings for TLS. J. Altman, N. Williams, L. Zhu. July 2010. (Format: TXT, HTML) (Updated by RFC9266) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5929) 5930 Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol. S. Shen, Y. Mao, NSS. Murthy. July 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5930) 5931 Extensible Authentication Protocol (EAP) Authentication Using Only a Password. D. Harkins, G. Zorn. August 2010. (Format: TXT, HTML) (Updated by RFC8146) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5931) 5932 Camellia Cipher Suites for TLS. A. Kato, M. Kanda, S. Kanno. June 2010. (Format: TXT, HTML) (Obsoletes RFC4132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5932) 5933 Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC. V. Dolmatov, Ed., A. Chuprina, I. Ustinov. July 2010. (Format: TXT, HTML) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5933) 5934 Trust Anchor Management Protocol (TAMP). R. Housley, S. Ashmore, C. Wallace. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5934) 5935 Expressing SNMP SMI Datatypes in XML Schema Definition Language. M. Ellison, B. Natale. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5935) 5936 DNS Zone Transfer Protocol (AXFR). E. Lewis, A. Hoenes, Ed.. June 2010. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Updated by RFC9103) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5936) 5937 Using Trust Anchor Constraints during Certification Path Processing. S. Ashmore, C. Wallace. August 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5937) 5938 Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP). A. Morton, M. Chiba. August 2010. (Format: TXT, HTML) (Updates RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5938) 5939 Session Description Protocol (SDP) Capability Negotiation. F. Andreasen. September 2010. (Format: TXT, HTML) (Updated by RFC6871) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5939) 5940 Additional Cryptographic Message Syntax (CMS) Revocation Information Choices. S. Turner, R. Housley. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5940) 5941 Sharing Transaction Fraud Data. D. M'Raihi, S. Boeyen, M. Grandcolas, S. Bajaj. August 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5941) 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes. H. Singh, W. Beebee, E. Nordmark. July 2010. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5942) 5943 A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing. B. Haberman, Ed.. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5943) 5944 IP Mobility Support for IPv4, Revised. C. Perkins, Ed.. November 2010. (Format: TXT, HTML) (Obsoletes RFC3344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5944) 5945 Resource Reservation Protocol (RSVP) Proxy Approaches. F. Le Faucheur, J. Manner, D. Wing, A. Guillou. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5945) 5946 Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy. F. Le Faucheur, J. Manner, A. Narayanan, A. Guillou, H. Malik. October 2010. (Format: TXT, HTML) (Updates RFC2205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5946) 5947 Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP). J. Elwell, H. Kaplan. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5947) 5948 Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16. S. Madanapalli, S. Park, S. Chakrabarti, G. Montenegro. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5948) 5949 Fast Handovers for Proxy Mobile IPv6. H. Yokota, K. Chowdhury, R. Koodli, B. Patil, F. Xia. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5949) 5950 Network Management Framework for MPLS-based Transport Networks. S. Mansfield, Ed., E. Gray, Ed., K. Lam, Ed.. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5950) 5951 Network Management Requirements for MPLS-based Transport Networks. K. Lam, S. Mansfield, E. Gray. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5951) 5952 A Recommendation for IPv6 Address Text Representation. S. Kawamura, M. Kawashima. August 2010. (Format: TXT, HTML) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5952) 5953 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP). W. Hardaker. August 2010. (Format: TXT, HTML) (Obsoleted by RFC6353) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5953) 5954 Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261. V. Gurbani, Ed., B. Carpenter, Ed., B. Tate, Ed.. August 2010. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5954) 5955 The application/timestamped-data Media Type. A. Santoni. August 2010. (Format: TXT, HTML) (Updates RFC5544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5955) 5956 Forward Error Correction Grouping Semantics in the Session Description Protocol. A. Begen. September 2010. (Format: TXT, HTML) (Obsoletes RFC4756) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5956) 5957 Display-Based Address Sorting for the IMAP4 SORT Extension. D. Karp. July 2010. (Format: TXT, HTML) (Updates RFC5256) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5957) 5958 Asymmetric Key Packages. S. Turner. August 2010. (Format: TXT, HTML) (Obsoletes RFC5208) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5958) 5959 Algorithms for Asymmetric Key Package Content Type. S. Turner. August 2010. (Format: TXT, HTML) (Updated by RFC6162) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5959) 5960 MPLS Transport Profile Data Plane Architecture. D. Frost, Ed., S. Bryant, Ed., M. Bocci, Ed.. August 2010. (Format: TXT, HTML) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5960) 5961 Improving TCP's Robustness to Blind In-Window Attacks. A. Ramaiah, R. Stewart, M. Dalal. August 2010. (Format: TXT, HTML) (Updated by RFC9293) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5961) 5962 Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO). H. Schulzrinne, V. Singh, H. Tschofenig, M. Thomson. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5962) 5963 IPv6 Deployment in Internet Exchange Points (IXPs). R. Gagliano. August 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5963) 5964 Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries. J. Winterbottom, M. Thomson. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5964) 5965 An Extensible Format for Email Feedback Reports. Y. Shafranovich, J. Levine, M. Kucherawy. August 2010. (Format: TXT, HTML) (Updated by RFC6650) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5965) 5966 DNS Transport over TCP - Implementation Requirements. R. Bellis. August 2010. (Format: TXT, HTML) (Obsoleted by RFC7766) (Updates RFC1035, RFC1123) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5966) 5967 The application/pkcs10 Media Type. S. Turner. August 2010. (Format: TXT, HTML) (Updates RFC2986) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5967) 5968 Guidelines for Extending the RTP Control Protocol (RTCP). J. Ott, C. Perkins. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5968) 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification. W. Townsley, O. Troan. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5969) 5970 DHCPv6 Options for Network Boot. T. Huth, J. Freimann, V. Zimmer, D. Thaler. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5970) 5971 GIST: General Internet Signalling Transport. H. Schulzrinne, R. Hancock. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5971) 5972 General Internet Signaling Transport (GIST) State Machine. T. Tsenov, H. Tschofenig, X. Fu, Ed., C. Aoun, E. Davies. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5972) 5973 NAT/Firewall NSIS Signaling Layer Protocol (NSLP). M. Stiemerling, H. Tschofenig, C. Aoun, E. Davies. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5973) 5974 NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling. J. Manner, G. Karagiannis, A. McDonald. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5974) 5975 QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP). G. Ash, Ed., A. Bader, Ed., C. Kappler, Ed., D. Oran, Ed.. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5975) 5976 Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes. G. Ash, A. Morton, M. Dolly, P. Tarapore, C. Dvorak, Y. El Mghazli. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5976) 5977 RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv. A. Bader, L. Westberg, G. Karagiannis, C. Kappler, T. Phelan. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5977) 5978 Using and Extending the NSIS Protocol Family. J. Manner, R. Bless, J. Loughney, E. Davies, Ed.. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5978) 5979 NSIS Operation over IP Tunnels. C. Shen, H. Schulzrinne, S. Lee, J. Bang. March 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5979) 5980 NSIS Protocol Operation in Mobile Environments. T. Sanda, Ed., X. Fu, S. Jeong, J. Manner, H. Tschofenig. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5980) 5981 Authorization for NSIS Signaling Layer Protocols. J. Manner, M. Stiemerling, H. Tschofenig, R. Bless, Ed.. February 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5981) 5982 IP Flow Information Export (IPFIX) Mediation: Problem Statement. A. Kobayashi, Ed., B. Claise, Ed.. August 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5982) 5983 Mailing Lists and Internationalized Email Addresses. R. Gellens. October 2010. (Format: TXT, HTML) (Obsoleted by RFC6783) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5983) 5984 Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding. K-M. Moller. 1 April 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5984) 5985 HTTP-Enabled Location Delivery (HELD). M. Barnes, Ed.. September 2010. (Format: TXT, HTML) (Updated by RFC7840) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5985) 5986 Discovering the Local Location Information Server (LIS). M. Thomson, J. Winterbottom. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5986) 5987 Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters. J. Reschke. August 2010. (Format: TXT, HTML) (Obsoleted by RFC8187) (Status: HISTORIC) (DOI: 10.17487/RFC5987) 5988 Web Linking. M. Nottingham. October 2010. (Format: TXT, HTML) (Obsoleted by RFC8288) (Updates RFC4287) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5988) 5989 A SIP Event Package for Subscribing to Changes to an HTTP Resource. A.B. Roach. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5989) 5990 Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS). J. Randall, B. Kaliski, J. Brainard, S. Turner. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5990) 5991 Teredo Security Updates. D. Thaler, S. Krishnan, J. Hoagland. September 2010. (Format: TXT, HTML) (Updates RFC4380) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5991) 5992 Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic. S. Sharikov, D. Miloshevic, J. Klensin. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5992) 5993 RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR). X. Duan, S. Wang, M. Westerlund, K. Hellwig, I. Johansson. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5993) 5994 Application of Ethernet Pseudowires to MPLS Transport Networks. S. Bryant, Ed., M. Morrow, G. Swallow, R. Cherukuri, T. Nadeau, N. Harrison, B. Niven-Jenkins. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5994) 5995 Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections. J. Reschke. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5995) 5996 Internet Key Exchange Protocol Version 2 (IKEv2). C. Kaufman, P. Hoffman, Y. Nir, P. Eronen. September 2010. (Format: TXT, HTML) (Obsoletes RFC4306, RFC4718) (Obsoleted by RFC7296) (Updated by RFC5998, RFC6989) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5996) 5997 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol. A. DeKok. August 2010. (Format: TXT, HTML) (Updates RFC2866) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5997) 5998 An Extension for EAP-Only Authentication in IKEv2. P. Eronen, H. Tschofenig, Y. Sheffer. September 2010. (Format: TXT, HTML) (Updates RFC5996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5998) 5999 Not Issued. 6000 Not Issued. 6001 Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN). D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, JL. Le Roux. October 2010. (Format: TXT, HTML) (Updates RFC4202, RFC4203, RFC4206, RFC4874, RFC4974, RFC5307) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6001) 6002 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions. L. Berger, D. Fedyk. October 2010. (Format: TXT, HTML) (Updates RFC3471, RFC3473, RFC3945, RFC4202, RFC4203, RFC5307) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6002) 6003 Ethernet Traffic Parameters. D. Papadimitriou. October 2010. (Format: TXT, HTML) (Updates RFC3471, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6003) 6004 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching. L. Berger, D. Fedyk. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6004) 6005 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI). L. Berger, D. Fedyk. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6005) 6006 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths. Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric. September 2010. (Format: TXT, HTML) (Obsoleted by RFC8306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6006) 6007 Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations. I. Nishioka, D. King. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6007) 6008 Authentication-Results Registration for Differentiating among Cryptographic Results. M. Kucherawy. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6008) 6009 Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions. N. Freed. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6009) 6010 Cryptographic Message Syntax (CMS) Content Constraints Extension. R. Housley, S. Ashmore, C. Wallace. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6010) 6011 Session Initiation Protocol (SIP) User Agent Configuration. S. Lawrence, Ed., J. Elwell. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6011) 6012 Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog. J. Salowey, T. Petch, R. Gerhards, H. Feng. October 2010. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6012) 6013 TCP Cookie Transactions (TCPCT). W. Simpson. January 2011. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC6013) 6014 Cryptographic Algorithm Identifier Allocation for DNSSEC. P. Hoffman. November 2010. (Format: TXT, HTML) (Updates RFC4033, RFC4034, RFC4035) (Updated by RFC9157) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6014) 6015 RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC). A. Begen. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6015) 6016 Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs. B. Davie, F. Le Faucheur, A. Narayanan. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6016) 6017 Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field. K. Meadors, Ed.. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6017) 6018 IPv4 and IPv6 Greynets. F. Baker, W. Harrop, G. Armitage. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6018) 6019 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1. R. Housley. September 2010. (Format: TXT, HTML) (Obsoletes RFC4049) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6019) 6020 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF). M. Bjorklund, Ed.. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6020) 6021 Common YANG Data Types. J. Schoenwaelder, Ed.. October 2010. (Format: TXT, HTML) (Obsoleted by RFC6991) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6021) 6022 YANG Module for NETCONF Monitoring. M. Scott, M. Bjorklund. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6022) 6023 A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA). Y. Nir, H. Tschofenig, H. Deng, R. Singh. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6023) 6024 Trust Anchor Management Requirements. R. Reddy, C. Wallace. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6024) 6025 ASN.1 Translation. C. Wallace, C. Gardiner. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6025) 6026 Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests. R. Sparks, T. Zourzouvillys. September 2010. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6026) 6027 IPsec Cluster Problem Statement. Y. Nir. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6027) 6028 Host Identity Protocol (HIP) Multi-Hop Routing Extension. G. Camarillo, A. Keranen. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6028) 6029 A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem. I. Rimac, V. Hilt, M. Tomsu, V. Gurbani, E. Marocco. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6029) 6030 Portable Symmetric Key Container (PSKC). P. Hoyer, M. Pei, S. Machani. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6030) 6031 Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type. S. Turner, R. Housley. December 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6031) 6032 Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type. S. Turner, R. Housley. December 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6032) 6033 Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type. S. Turner. December 2010. (Format: TXT, HTML) (Updated by RFC6161) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6033) 6034 Unicast-Prefix-Based IPv4 Multicast Addresses. D. Thaler. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6034) 6035 Session Initiation Protocol Event Package for Voice Quality Reporting. A. Pendleton, A. Clark, A. Johnston, H. Sinnreich. November 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6035) 6036 Emerging Service Provider Scenarios for IPv6 Deployment. B. Carpenter, S. Jiang. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6036) 6037 Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs. E. Rosen, Ed., Y. Cai, Ed., IJ. Wijnands. October 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6037) 6038 Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features. A. Morton, L. Ciavattone. October 2010. (Format: TXT, HTML) (Updates RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6038) 6039 Issues with Existing Cryptographic Protection Methods for Routing Protocols. V. Manral, M. Bhatia, J. Jaeggli, R. White. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6039) 6040 Tunnelling of Explicit Congestion Notification. B. Briscoe. November 2010. (Format: TXT, HTML) (Updates RFC3168, RFC4301, RFC4774) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6040) 6041 Forwarding and Control Element Separation (ForCES) Applicability Statement. A. Crouch, H. Khosravi, A. Doria, Ed., X. Wang, K. Ogawa. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6041) 6042 Transport Layer Security (TLS) Authorization Using KeyNote. A. Keromytis. October 2010. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6042) 6043 MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY). J. Mattsson, T. Tian. March 2011. (Format: TXT, HTML) (Updated by RFC6309) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6043) 6044 Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP). M. Mohali. October 2010. (Format: TXT, HTML) (Obsoleted by RFC7544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6044) 6045 Real-time Inter-network Defense (RID). K. Moriarty. November 2010. (Format: TXT, HTML) (Obsoleted by RFC6545) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6045) 6046 Transport of Real-time Inter-network Defense (RID) Messages. K. Moriarty, B. Trammell. November 2010. (Format: TXT, HTML) (Obsoleted by RFC6546) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6046) 6047 iCalendar Message-Based Interoperability Protocol (iMIP). A. Melnikov, Ed.. December 2010. (Format: TXT, HTML) (Obsoletes RFC2447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6047) 6048 Network News Transfer Protocol (NNTP) Additions to LIST Command. J. Elie. November 2010. (Format: TXT, HTML) (Updates RFC2980, RFC3977) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6048) 6049 Spatial Composition of Metrics. A. Morton, E. Stephan. January 2011. (Format: TXT, HTML) (Updated by RFC6248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6049) 6050 A Session Initiation Protocol (SIP) Extension for the Identification of Services. K. Drage. November 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6050) 6051 Rapid Synchronisation of RTP Flows. C. Perkins, T. Schierl. November 2010. (Format: TXT, HTML) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6051) 6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT, HTML) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6052) 6053 Implementation Report for Forwarding and Control Element Separation (ForCES). E. Haleplidis, K. Ogawa, W. Wang, J. Hadi Salim. November 2010. (Format: TXT, HTML) (Updated by RFC6984) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6053) 6054 Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic. D. McGrew, B. Weis. November 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6054) 6055 IAB Thoughts on Encodings for Internationalized Domain Names. D. Thaler, J. Klensin, S. Cheshire. February 2011. (Format: TXT, HTML) (Updates RFC2130) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6055) 6056 Recommendations for Transport-Protocol Port Randomization. M. Larsen, F. Gont. January 2011. (Format: TXT, HTML) (Also BCP0156) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6056) 6057 Comcast's Protocol-Agnostic Congestion Management System. C. Bastian, T. Klieber, J. Livingood, J. Mills, R. Woundy. December 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6057) 6058 Transient Binding for Proxy Mobile IPv6. M. Liebsch, Ed., A. Muhanna, O. Blume. March 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6058) 6059 Simple Procedures for Detecting Network Attachment in IPv6. S. Krishnan, G. Daley. November 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6059) 6060 Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE). D. Fedyk, H. Shah, N. Bitar, A. Takacs. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6060) 6061 Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA). B. Rosen. January 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6061) 6062 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations. S. Perreault, Ed., J. Rosenberg. November 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6062) 6063 Dynamic Symmetric Key Provisioning Protocol (DSKPP). A. Doherty, M. Pei, S. Machani, M. Nystrom. December 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6063) 6064 SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service. M. Westerlund, P. Frojdh. January 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6064) 6065 Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings. K. Narayan, D. Nelson, R. Presuhn, Ed.. December 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6065) 6066 Transport Layer Security (TLS) Extensions: Extension Definitions. D. Eastlake 3rd. January 2011. (Format: TXT, HTML) (Obsoletes RFC4366) (Updated by RFC8446, RFC8449, RFC9325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6066) 6067 BCP 47 Extension U. M. Davis, A. Phillips, Y. Umaoka. December 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6067) 6068 The 'mailto' URI Scheme. M. Duerst, L. Masinter, J. Zawinski. October 2010. (Format: TXT, HTML) (Obsoletes RFC2368) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6068) 6069 Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD). A. Zimmermann, A. Hannemann. December 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6069) 6070 PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors. S. Josefsson. January 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6070) 6071 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap. S. Frankel, S. Krishnan. February 2011. (Format: TXT, HTML) (Obsoletes RFC2411) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6071) 6072 Certificate Management Service for the Session Initiation Protocol (SIP). C. Jennings, J. Fischl, Ed.. February 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6072) 6073 Segmented Pseudowire. L. Martini, C. Metz, T. Nadeau, M. Bocci, M. Aissaoui. January 2011. (Format: TXT, HTML) (Updated by RFC6723, RFC7267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6073) 6074 Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs). E. Rosen, B. Davie, V. Radoaca, W. Luo. January 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6074) 6075 The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry. D. Cridland. December 2010. (Format: TXT, HTML) (Updates RFC2244) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6075) 6076 Basic Telephony SIP End-to-End Performance Metrics. D. Malas, A. Morton. January 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6076) 6077 Open Research Issues in Internet Congestion Control. D. Papadimitriou, Ed., M. Welzl, M. Scharf, B. Briscoe. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6077) 6078 Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS). G. Camarillo, J. Melen. January 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6078) 6079 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE). G. Camarillo, P. Nikander, J. Hautakorpi, A. Keranen, A. Johnston. January 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6079) 6080 A Framework for Session Initiation Protocol User Agent Profile Delivery. D. Petrie, S. Channabasappa, Ed.. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6080) 6081 Teredo Extensions. D. Thaler. January 2011. (Format: TXT, HTML) (Updates RFC4380) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6081) 6082 Deprecating Unicode Language Tag Characters: RFC 2482 is Historic. K. Whistler, G. Adams, M. Duerst, R. Presuhn, Ed., J. Klensin. November 2010. (Format: TXT, HTML) (Obsoletes RFC2482) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6082) 6083 Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP). M. Tuexen, R. Seggelmann, E. Rescorla. January 2011. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6083) 6084 General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS). X. Fu, C. Dickmann, J. Crowcroft. January 2011. (Format: TXT, HTML) (Updated by RFC8996) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6084) 6085 Address Mapping of IPv6 Multicast Packets on Ethernet. S. Gundavelli, M. Townsley, O. Troan, W. Dec. January 2011. (Format: TXT, HTML) (Updates RFC2464) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6085) 6086 Session Initiation Protocol (SIP) INFO Method and Package Framework. C. Holmberg, E. Burger, H. Kaplan. January 2011. (Format: TXT, HTML) (Obsoletes RFC2976) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6086) 6087 Guidelines for Authors and Reviewers of YANG Data Model Documents. A. Bierman. January 2011. (Format: TXT, HTML) (Obsoleted by RFC8407) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6087) 6088 Traffic Selectors for Flow Bindings. G. Tsirtsis, G. Giarreta, H. Soliman, N. Montavont. January 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6088) 6089 Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support. G. Tsirtsis, H. Soliman, N. Montavont, G. Giaretta, K. Kuladinithi. January 2011. (Format: TXT, HTML) (Updates RFC5648) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6089) 6090 Fundamental Elliptic Curve Cryptography Algorithms. D. McGrew, K. Igoe, M. Salter. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6090) 6091 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication. N. Mavrogiannopoulos, D. Gillmor. February 2011. (Format: TXT, HTML) (Obsoletes RFC5081) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6091) 6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service. J. Woodyatt, Ed.. January 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6092) 6093 On the Implementation of the TCP Urgent Mechanism. F. Gont, A. Yourtchenko. January 2011. (Format: TXT, HTML) (Obsoleted by RFC9293) (Updates RFC0793, RFC1011, RFC1122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6093) 6094 Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols. M. Bhatia, V. Manral. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6094) 6095 Extending YANG with Language Abstractions. B. Linowski, M. Ersue, S. Kuryla. March 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6095) 6096 Stream Control Transmission Protocol (SCTP) Chunk Flags Registration. M. Tuexen, R. Stewart. January 2011. (Format: TXT, HTML) (Obsoleted by RFC9260) (Updates RFC4960) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6096) 6097 Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6. J. Korhonen, V. Devarapalli. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6097) 6098 Generic Notification Message for Mobile IPv4. H. Deng, H. Levkowetz, V. Devarapalli, S. Gundavelli, B. Haley. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6098) 6099 Not Issued. 6100 Not Issued. 6101 The Secure Sockets Layer (SSL) Protocol Version 3.0. A. Freier, P. Karlton, P. Kocher. August 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6101) 6102 Not Issued. 6103 Not Issued. 6104 Rogue IPv6 Router Advertisement Problem Statement. T. Chown, S. Venaas. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6104) 6105 IPv6 Router Advertisement Guard. E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi. February 2011. (Format: TXT, HTML) (Updated by RFC7113) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6105) 6106 IPv6 Router Advertisement Options for DNS Configuration. J. Jeong, S. Park, L. Beloeil, S. Madanapalli. November 2010. (Format: TXT, HTML) (Obsoletes RFC5006) (Obsoleted by RFC8106) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6106) 6107 Procedures for Dynamically Signaled Hierarchical Label Switched Paths. K. Shiomoto, Ed., A. Farrel, Ed.. February 2011. (Format: TXT, HTML) (Updates RFC3477, RFC4206) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6107) 6108 Comcast's Web Notification System Design. C. Chung, A. Kasyanov, J. Livingood, N. Mody, B. Van Lieu. February 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6108) 6109 La Posta Elettronica Certificata - Italian Certified Electronic Mail. C. Petrucci, F. Gennai, A. Shahin, A. Vinciarelli. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6109) 6110 Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content. L. Lhotka, Ed.. February 2011. (Format: TXT, HTML) (Updated by RFC7952) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6110) 6111 Additional Kerberos Naming Constraints. L. Zhu. April 2011. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6111) 6112 Anonymity Support for Kerberos. L. Zhu, P. Leach, S. Hartman. April 2011. (Format: TXT, HTML) (Obsoleted by RFC8062) (Updates RFC4120, RFC4121, RFC4556) (Status: HISTORIC) (DOI: 10.17487/RFC6112) 6113 A Generalized Framework for Kerberos Pre-Authentication. S. Hartman, L. Zhu. April 2011. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6113) 6114 The 128-Bit Blockcipher CLEFIA. M. Katagi, S. Moriai. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6114) 6115 Recommendation for a Routing Architecture. T. Li, Ed.. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6115) 6116 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM). S. Bradner, L. Conroy, K. Fujiwara. March 2011. (Format: TXT, HTML) (Obsoletes RFC3761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6116) 6117 IANA Registration of Enumservices: Guide, Template, and IANA Considerations. B. Hoeneisen, A. Mayrhofer, J. Livingood. March 2011. (Format: TXT, HTML) (Obsoletes RFC3761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6117) 6118 Update of Legacy IANA Registrations of Enumservices. B. Hoeneisen, A. Mayrhofer. March 2011. (Format: TXT, HTML) (Updates RFC3762, RFC3764, RFC3953, RFC4143, RFC4002, RFC4238, RFC4355, RFC4415, RFC4769, RFC4969, RFC4979, RFC5028, RFC5278, RFC5333) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6118) 6119 IPv6 Traffic Engineering in IS-IS. J. Harrison, J. Berger, M. Bartlett. February 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6119) 6120 Extensible Messaging and Presence Protocol (XMPP): Core. P. Saint-Andre. March 2011. (Format: TXT, HTML) (Obsoletes RFC3920) (Updated by RFC7590, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6120) 6121 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence. P. Saint-Andre. March 2011. (Format: TXT, HTML) (Obsoletes RFC3921) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6121) 6122 Extensible Messaging and Presence Protocol (XMPP): Address Format. P. Saint-Andre. March 2011. (Format: TXT, HTML) (Obsoleted by RFC7622) (Updates RFC3920) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6122) 6123 Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts. A. Farrel. February 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6123) 6124 An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol. Y. Sheffer, G. Zorn, H. Tschofenig, S. Fluhrer. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6124) 6125 Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS). P. Saint-Andre, J. Hodges. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6125) 6126 The Babel Routing Protocol. J. Chroboczek. April 2011. (Format: TXT, HTML) (Obsoleted by RFC8966) (Updated by RFC7298, RFC7557) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6126) 6127 IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios. J. Arkko, M. Townsley. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6127) 6128 RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions. A. Begen. February 2011. (Format: TXT, HTML) (Updates RFC5760) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6128) 6129 The 'application/tei+xml' Media Type. L. Romary, S. Lundberg. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6129) 6130 Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP). T. Clausen, C. Dearlove, J. Dean. April 2011. (Format: TXT, HTML) (Updated by RFC7183, RFC7188, RFC7466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6130) 6131 Sieve Vacation Extension: "Seconds" Parameter. R. George, B. Leiba. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6131) 6132 Sieve Notification Using Presence Information. R. George, B. Leiba. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6132) 6133 Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality. R. George, B. Leiba, A. Melnikov. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6133) 6134 Sieve Extension: Externally Stored Lists. A. Melnikov, B. Leiba. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6134) 6135 An Alternative Connection Model for the Message Session Relay Protocol (MSRP). C. Holmberg, S. Blau. February 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6135) 6136 Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework. A. Sajassi, Ed., D. Mohan, Ed.. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6136) 6137 The Network Trouble Ticket Data Model (NTTDM). D. Zisiadis, Ed., S. Kopsidas, Ed., M. Tsavli, Ed., G. Cessieux, Ed.. February 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6137) 6138 LDP IGP Synchronization for Broadcast Networks. S. Kini, Ed., W. Lu, Ed.. February 2011. (Format: TXT, HTML) (Updates RFC5443) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6138) 6139 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios. S. Russert, Ed., E. Fleischman, Ed., F. Templin, Ed.. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6139) 6140 Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP). A.B. Roach. March 2011. (Format: TXT, HTML) (Updates RFC3680) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6140) 6141 Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP). G. Camarillo, Ed., C. Holmberg, Y. Gao. March 2011. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6141) 6142 ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP. A. Moise, J. Brodkin. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6142) 6143 The Remote Framebuffer Protocol. T. Richardson, J. Levine. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6143) 6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K. Yin. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6144) 6145 IP/ICMP Translation Algorithm. X. Li, C. Bao, F. Baker. April 2011. (Format: TXT, HTML) (Obsoletes RFC2765) (Obsoleted by RFC7915) (Updated by RFC6791, RFC7757) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6145) 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, I. van Beijnum. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6146) 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6147) 6148 DHCPv4 Lease Query by Relay Agent Remote ID. P. Kurapati, R. Desetti, B. Joshi. February 2011. (Format: TXT, HTML) (Updates RFC4388) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6148) 6149 MD2 to Historic Status. S. Turner, L. Chen. March 2011. (Format: TXT, HTML) (Obsoletes RFC1319) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6149) 6150 MD4 to Historic Status. S. Turner, L. Chen. March 2011. (Format: TXT, HTML) (Obsoletes RFC1320) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6150) 6151 Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms. S. Turner, L. Chen. March 2011. (Format: TXT, HTML) (Updates RFC1321, RFC2104) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6151) 6152 SMTP Service Extension for 8-bit MIME Transport. J. Klensin, N. Freed, M. Rose, D. Crocker, Ed.. March 2011. (Format: TXT, HTML) (Obsoletes RFC1652) (Also STD0071) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6152) 6153 DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery. S. Das, G. Bajko. February 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6153) 6154 IMAP LIST Extension for Special-Use Mailboxes. B. Leiba, J. Nicolson. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6154) 6155 Use of Device Identity in HTTP-Enabled Location Delivery (HELD). J. Winterbottom, M. Thomson, H. Tschofenig, R. Barnes. March 2011. (Format: TXT, HTML) (Updated by RFC6915) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6155) 6156 Traversal Using Relays around NAT (TURN) Extension for IPv6. G. Camarillo, O. Novo, S. Perreault, Ed.. April 2011. (Format: TXT, HTML) (Obsoleted by RFC8656) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6156) 6157 IPv6 Transition in the Session Initiation Protocol (SIP). G. Camarillo, K. El Malki, V. Gurbani. April 2011. (Format: TXT, HTML) (Updates RFC3264) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6157) 6158 RADIUS Design Guidelines. A. DeKok, Ed., G. Weber. March 2011. (Format: TXT, HTML) (Updated by RFC6929, RFC8044) (Also BCP0158) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6158) 6159 Session-Specific Explicit Diameter Request Routing. T. Tsou, G. Zorn, T. Taylor, Ed.. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6159) 6160 Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types. S. Turner. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6160) 6161 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type. S. Turner. April 2011. (Format: TXT, HTML) (Updates RFC6033) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6161) 6162 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type. S. Turner. April 2011. (Format: TXT, HTML) (Updates RFC5959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6162) 6163 Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs). Y. Lee, Ed., G. Bernstein, Ed., W. Imajuku. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6163) 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links. M. Kohno, B. Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten. April 2011. (Format: TXT, HTML) (Updated by RFC6547) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6164) 6165 Extensions to IS-IS for Layer-2 Systems. A. Banerjee, D. Ward. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6165) 6166 A Registry for PIM Message Types. S. Venaas. April 2011. (Format: TXT, HTML) (Obsoleted by RFC8736) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6166) 6167 URI Scheme for Java(tm) Message Service 1.0. M. Phillips, P. Adams, D. Rokicki, E. Johnson. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6167) 6168 Requirements for Management of Name Servers for the DNS. W. Hardaker. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6168) 6169 Security Concerns with IP Tunneling. S. Krishnan, D. Thaler, J. Hoagland. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6169) 6170 Internet X.509 Public Key Infrastructure -- Certificate Image. S. Santesson, R. Housley, S. Bajaj, L. Rosenthol. May 2011. (Format: TXT, HTML) (Updates RFC3709) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6170) 6171 The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control. K. Zeilenga. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6171) 6172 Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode. D. Black, D. Peterson. March 2011. (Format: TXT, HTML) (Updates RFC4172) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6172) 6173 Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP). P. Venkatesen, Ed.. March 2011. (Format: TXT, HTML) (Obsoletes RFC4369) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6173) 6174 Definition of IETF Working Group Document States. E. Juskevicius. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6174) 6175 Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors. E. Juskevicius. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6175) 6176 Prohibiting Secure Sockets Layer (SSL) Version 2.0. S. Turner, T. Polk. March 2011. (Format: TXT, HTML) (Updates RFC2246, RFC4346, RFC5246) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6176) 6177 IPv6 Address Assignment to End Sites. T. Narten, G. Huston, L. Roberts. March 2011. (Format: TXT, HTML) (Obsoletes RFC3177) (Also BCP0157) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6177) 6178 Label Edge Router Forwarding of IPv4 Option Packets. D. Smith, J. Mullooly, W. Jaeger, T. Scholl. March 2011. (Format: TXT, HTML) (Updates RFC3031) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6178) 6179 The Internet Routing Overlay Network (IRON). F. Templin, Ed.. March 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6179) 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6180) 6181 Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses. M. Bagnulo. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6181) 6182 Architectural Guidelines for Multipath TCP Development. A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6182) 6183 IP Flow Information Export (IPFIX) Mediation: Framework. A. Kobayashi, B. Claise, G. Muenz, K. Ishibashi. April 2011. (Format: TXT, HTML) (Updates RFC5470) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6183) 6184 RTP Payload Format for H.264 Video. Y.-K. Wang, R. Even, T. Kristensen, R. Jesup. May 2011. (Format: TXT, HTML) (Obsoletes RFC3984) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6184) 6185 RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video. T. Kristensen, P. Luthi. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6185) 6186 Use of SRV Records for Locating Email Submission/Access Services. C. Daboo. March 2011. (Format: TXT, HTML) (Updates RFC1939, RFC3501) (Updated by RFC8314, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6186) 6187 X.509v3 Certificates for Secure Shell Authentication. K. Igoe, D. Stebila. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6187) 6188 The Use of AES-192 and AES-256 in Secure RTP. D. McGrew. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6188) 6189 ZRTP: Media Path Key Agreement for Unicast Secure RTP. P. Zimmermann, A. Johnston, Ed., J. Callas. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6189) 6190 RTP Payload Format for Scalable Video Coding. S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6190) 6191 Reducing the TIME-WAIT State Using TCP Timestamps. F. Gont. April 2011. (Format: TXT, HTML) (Also BCP0159) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6191) 6192 Protecting the Router Control Plane. D. Dugal, C. Pignataro, R. Dunn. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6192) 6193 Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP). M. Saito, D. Wing, M. Toyama. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6193) 6194 Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms. T. Polk, L. Chen, S. Turner, P. Hoffman. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6194) 6195 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd. March 2011. (Format: TXT, HTML) (Obsoletes RFC5395) (Obsoleted by RFC6895) (Updates RFC1183, RFC3597) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6195) 6196 Moving mailserver: URI Scheme to Historic. A. Melnikov. March 2011. (Format: TXT, HTML) (Updates RFC1738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6196) 6197 Location-to-Service Translation (LoST) Service List Boundary Extension. K. Wolf. April 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6197) 6198 Requirements for the Graceful Shutdown of BGP Sessions. B. Decraene, P. Francois, C. Pelsser, Z. Ahmad, A.J. Elizondo Armengol, T. Takeda. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6198) 6199 Not Issued. 6200 Not Issued. 6201 Device Reset Characterization. R. Asati, C. Pignataro, F. Calabria, C. Olvera. March 2011. (Format: TXT, HTML) (Updates RFC1242, RFC2544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6201) 6202 Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP. S. Loreto, P. Saint-Andre, S. Salsano, G. Wilkins. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6202) 6203 IMAP4 Extension for Fuzzy Search. T. Sirainen. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6203) 6204 Basic Requirements for IPv6 Customer Edge Routers. H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, Ed.. April 2011. (Format: TXT, HTML) (Obsoleted by RFC7084) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6204) 6205 Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers. T. Otani, Ed., D. Li, Ed.. March 2011. (Format: TXT, HTML) (Updates RFC3471) (Updated by RFC7699, RFC8359) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6205) 6206 The Trickle Algorithm. P. Levis, T. Clausen, J. Hui, O. Gnawali, J. Ko. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6206) 6207 The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml. R. Denenberg, Ed.. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6207) 6208 Cloud Data Management Interface (CDMI) Media Types. K. Sankar, Ed., A. Jones. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6208) 6209 Addition of the ARIA Cipher Suites to Transport Layer Security (TLS). W. Kim, J. Lee, J. Park, D. Kwon. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6209) 6210 Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME. J. Schaad. April 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6210) 6211 Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute. J. Schaad. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6211) 6212 Authentication-Results Registration for Vouch by Reference Results. M. Kucherawy. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6212) 6213 IS-IS BFD-Enabled TLV. C. Hopps, L. Ginsberg. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6213) 6214 Adaptation of RFC 1149 for IPv6. B. Carpenter, R. Hinden. 1 April 2011. (Format: TXT, HTML) (Updates RFC1149) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6214) 6215 MPLS Transport Profile User-to-Network and Network-to-Network Interfaces. M. Bocci, L. Levrau, D. Frost. April 2011. (Format: TXT, HTML) (Updates RFC5921) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6215) 6216 Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms. C. Jennings, K. Ono, R. Sparks, B. Hibbard, Ed.. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6216) 6217 Regional Broadcast Using an Atmospheric Link Layer. T. Ritter. 1 April 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6217) 6218 Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material. G. Zorn, T. Zhang, J. Walker, J. Salowey. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6218) 6219 The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition. X. Li, C. Bao, M. Chen, H. Zhang, J. Wu. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6219) 6220 Defining the Role and Function of IETF Protocol Parameter Registry Operators. D. McPherson, Ed., O. Kolkman, Ed., J. Klensin, Ed., G. Huston, Ed., Internet Architecture Board. April 2011. (Format: TXT, HTML) (Obsoleted by RFC8722) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6220) 6221 Lightweight DHCPv6 Relay Agent. D. Miles, Ed., S. Ooghe, W. Dec, S. Krishnan, A. Kavanagh. May 2011. (Format: TXT, HTML) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6221) 6222 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs). A. Begen, C. Perkins, D. Wing. April 2011. (Format: TXT, HTML) (Obsoleted by RFC7022) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6222) 6223 Indication of Support for Keep-Alive. C. Holmberg. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6223) 6224 Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains. T. Schmidt, M. Waehlisch, S. Krishnan. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6224) 6225 Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information. J. Polk, M. Linsner, M. Thomson, B. Aboba, Ed.. July 2011. (Format: TXT, HTML) (Obsoletes RFC3825) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6225) 6226 PIM Group-to-Rendezvous-Point Mapping. B. Joshi, A. Kessler, D. McWalter. May 2011. (Format: TXT, HTML) (Updates RFC4601) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6226) 6227 Design Goals for Scalable Internet Routing. T. Li, Ed.. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6227) 6228 Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog. C. Holmberg. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6228) 6229 Test Vectors for the Stream Cipher RC4. J. Strombergson, S. Josefsson. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6229) 6230 Media Control Channel Framework. C. Boulton, T. Melanchuk, S. McGlashan. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6230) 6231 An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework. S. McGlashan, T. Melanchuk, C. Boulton. May 2011. (Format: TXT, HTML) (Updated by RFC6623) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6231) 6232 Purge Originator Identification TLV for IS-IS. F. Wei, Y. Qin, Z. Li, T. Li, J. Dong. May 2011. (Format: TXT, HTML) (Updates RFC5301, RFC5304, RFC5310) (Updated by RFC8918) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6232) 6233 IS-IS Registry Extension for Purges. T. Li, L. Ginsberg. May 2011. (Format: TXT, HTML) (Updates RFC3563, RFC5304, RFC5310) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6233) 6234 US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF). D. Eastlake 3rd, T. Hansen. May 2011. (Format: TXT, HTML) (Obsoletes RFC4634) (Updates RFC3174) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6234) 6235 IP Flow Anonymization Support. E. Boschi, B. Trammell. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6235) 6236 Negotiation of Generic Image Attributes in the Session Description Protocol (SDP). I. Johansson, K. Jung. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6236) 6237 IMAP4 Multimailbox SEARCH Extension. B. Leiba, A. Melnikov. May 2011. (Format: TXT, HTML) (Obsoleted by RFC7377) (Updates RFC4466) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6237) 6238 TOTP: Time-Based One-Time Password Algorithm. D. M'Raihi, S. Machani, M. Pei, J. Rydell. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6238) 6239 Suite B Cryptographic Suites for Secure Shell (SSH). K. Igoe. May 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6239) 6240 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2. D. Zelig, Ed., R. Cohen, Ed., T. Nadeau, Ed.. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6240) 6241 Network Configuration Protocol (NETCONF). R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed.. June 2011. (Format: TXT, HTML) (Obsoletes RFC4741) (Updated by RFC7803, RFC8526) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6241) 6242 Using the NETCONF Protocol over Secure Shell (SSH). M. Wasserman. June 2011. (Format: TXT, HTML) (Obsoletes RFC4742) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6242) 6243 With-defaults Capability for NETCONF. A. Bierman, B. Lengyel. June 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6243) 6244 An Architecture for Network Management Using NETCONF and YANG. P. Shafer. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6244) 6245 Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4. P. Yegani, K. Leung, A. Lior, K. Chowdhury, J. Navali. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6245) 6246 Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges. A. Sajassi, Ed., F. Brockners, D. Mohan, Ed., Y. Serbest. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6246) 6247 Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status. L. Eggert. May 2011. (Format: TXT, HTML) (Obsoletes RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1379, RFC1644, RFC1693) (Updates RFC4614) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6247) 6248 RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete. A. Morton. April 2011. (Format: TXT, HTML) (Obsoletes RFC4148) (Updates RFC4737, RFC5560, RFC5644, RFC6049) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6248) 6249 Metalink/HTTP: Mirrors and Hashes. A. Bryan, N. McNab, T. Tsujikawa, P. Poeml, H. Nordstrom. June 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6249) 6250 Evolution of the IP Model. D. Thaler. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6250) 6251 Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol. S. Josefsson. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6251) 6252 A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization. A. Dutta, Ed., V. Fajardo, Y. Ohba, K. Taniuchi, H. Schulzrinne. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6252) 6253 Host Identity Protocol Certificates. T. Heer, S. Varjonen. May 2011. (Format: TXT, HTML) (Obsoleted by RFC8002) (Updates RFC5201) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6253) 6254 Request to Move RFC 2754 to Historic Status. M. McFadden. May 2011. (Format: TXT, HTML) (Obsoletes RFC2754) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6254) 6255 Delay-Tolerant Networking Bundle Protocol IANA Registries. M. Blanchet. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6255) 6256 Using Self-Delimiting Numeric Values in Protocols. W. Eddy, E. Davies. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6256) 6257 Bundle Security Protocol Specification. S. Symington, S. Farrell, H. Weiss, P. Lovell. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6257) 6258 Delay-Tolerant Networking Metadata Extension Block. S. Symington. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6258) 6259 Delay-Tolerant Networking Previous-Hop Insertion Block. S. Symington. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6259) 6260 Compressed Bundle Header Encoding (CBHE). S. Burleigh. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6260) 6261 Encrypted Signaling Transport Modes for the Host Identity Protocol. A. Keranen. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6261) 6262 RTP Payload Format for IP-MR Speech Codec. S. Ikonin. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6262) 6263 Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows. X. Marjou, A. Sollaud. June 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6263) 6264 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition. S. Jiang, D. Guo, B. Carpenter. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6264) 6265 HTTP State Management Mechanism. A. Barth. April 2011. (Format: TXT, HTML) (Obsoletes RFC2965) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6265) 6266 Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP). J. Reschke. June 2011. (Format: TXT, HTML) (Updates RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6266) 6267 MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY). V. Cakulev, G. Sundaram. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6267) 6268 Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX). J. Schaad, S. Turner. July 2011. (Format: TXT, HTML) (Updates RFC5911) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6268) 6269 Issues with IP Address Sharing. M. Ford, Ed., M. Boucadair, A. Durand, P. Levis, P. Roberts. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6269) 6270 The 'tn3270' URI Scheme. M. Yevstifeyev. June 2011. (Format: TXT, HTML) (Updates RFC2355, RFC1738, RFC1041) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6270) 6271 Requirements for SIP-Based Session Peering. J-F. Mule. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6271) 6272 Internet Protocols for the Smart Grid. F. Baker, D. Meyer. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6272) 6273 The Secure Neighbor Discovery (SEND) Hash Threat Analysis. A. Kukec, S. Krishnan, S. Jiang. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6273) 6274 Security Assessment of the Internet Protocol Version 4. F. Gont. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6274) 6275 Mobility Support in IPv6. C. Perkins, Ed., D. Johnson, J. Arkko. July 2011. (Format: TXT, HTML) (Obsoletes RFC3775) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6275) 6276 DHCPv6 Prefix Delegation for Network Mobility (NEMO). R. Droms, P. Thubert, F. Dupont, W. Haddad, C. Bernardos. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6276) 6277 Online Certificate Status Protocol Algorithm Agility. S. Santesson, P. Hallam-Baker. June 2011. (Format: TXT, HTML) (Obsoleted by RFC6960) (Updates RFC2560) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6277) 6278 Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax. J. Herzog, R. Khazan. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6278) 6279 Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement. M. Liebsch, Ed., S. Jeong, Q. Wu. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6279) 6280 An Architecture for Location and Location Privacy in Internet Applications. R. Barnes, M. Lepinski, A. Cooper, J. Morris, H. Tschofenig, H. Schulzrinne. July 2011. (Format: TXT, HTML) (Updates RFC3693, RFC3694) (Also BCP0160) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6280) 6281 Understanding Apple's Back to My Mac (BTMM) Service. S. Cheshire, Z. Zhu, R. Wakikawa, L. Zhang. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6281) 6282 Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks. J. Hui, Ed., P. Thubert. September 2011. (Format: TXT, HTML) (Updates RFC4944) (Updated by RFC8066) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6282) 6283 Extensible Markup Language Evidence Record Syntax (XMLERS). A. Jerman Blazic, S. Saljic, T. Gondrom. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6283) 6284 Port Mapping between Unicast and Multicast RTP Sessions. A. Begen, D. Wing, T. Van Caenegem. June 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6284) 6285 Unicast-Based Rapid Acquisition of Multicast RTP Sessions. B. Ver Steeg, A. Begen, T. Van Caenegem, Z. Vax. June 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6285) 6286 Autonomous-System-Wide Unique BGP Identifier for BGP-4. E. Chen, J. Yuan. June 2011. (Format: TXT, HTML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6286) 6287 OCRA: OATH Challenge-Response Algorithm. D. M'Raihi, J. Rydell, S. Bajaj, S. Machani, D. Naccache. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6287) 6288 URN Namespace for the Defence Geospatial Information Working Group (DGIWG). C. Reed. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6288) 6289 A Uniform Resource Name (URN) Namespace for CableLabs. E. Cardona, S. Channabasappa, J-F. Mule. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6289) 6290 A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE). Y. Nir, Ed., D. Wierbowski, F. Detienne, P. Sethi. June 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6290) 6291 Guidelines for the Use of the "OAM" Acronym in the IETF. L. Andersson, H. van Helvoort, R. Bonica, D. Romascanu, S. Mansfield. June 2011. (Format: TXT, HTML) (Also BCP0161) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6291) 6292 Requirements for a Working Group Charter Tool. P. Hoffman. June 2011. (Format: TXT, HTML) (Updated by RFC6433) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6292) 6293 Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker. P. Hoffman. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6293) 6294 Survey of Proposed Use Cases for the IPv6 Flow Label. Q. Hu, B. Carpenter. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6294) 6295 RTP Payload Format for MIDI. J. Lazzaro, J. Wawrzynek. June 2011. (Format: TXT, HTML) (Obsoletes RFC4695) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6295) 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker. June 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6296) 6297 A Survey of Lower-than-Best-Effort Transport Protocols. M. Welzl, D. Ros. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6297) 6298 Computing TCP's Retransmission Timer. V. Paxson, M. Allman, J. Chu, M. Sargent. June 2011. (Format: TXT, HTML) (Obsoletes RFC2988) (Updates RFC1122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6298) 6299 Not Issued. 6300 Not Issued. 6301 A Survey of Mobility Support in the Internet. Z. Zhu, R. Wakikawa, L. Zhang. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6301) 6302 Logging Recommendations for Internet-Facing Servers. A. Durand, I. Gashinsky, D. Lee, S. Sheppard. June 2011. (Format: TXT, HTML) (Also BCP0162) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6302) 6303 Locally Served DNS Zones. M. Andrews. July 2011. (Format: TXT, HTML) (Also BCP0163) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6303) 6304 AS112 Nameserver Operations. J. Abley, W. Maton. July 2011. (Format: TXT, HTML) (Obsoleted by RFC7534) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6304) 6305 I'm Being Attacked by PRISONER.IANA.ORG!. J. Abley, W. Maton. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6305) 6306 Hierarchical IPv4 Framework. P. Frejborg. July 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6306) 6307 Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks. D. Black, Ed., L. Dunbar, Ed., M. Roth, R. Solomon. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6307) 6308 Overview of the Internet Multicast Addressing Architecture. P. Savola. June 2011. (Format: TXT, HTML) (Obsoletes RFC2908) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6308) 6309 IANA Rules for MIKEY (Multimedia Internet KEYing). J. Arkko, A. Keranen, J. Mattsson. August 2011. (Format: TXT, HTML) (Obsoletes RFC4909) (Updates RFC3830, RFC4563, RFC5410, RFC6043) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6309) 6310 Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping. M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, Y(J). Stein. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6310) 6311 Protocol Support for High Availability of IKEv2/IPsec. R. Singh, Ed., G. Kalyani, Y. Nir, Y. Sheffer, D. Zhang. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6311) 6312 Mobile Networks Considerations for IPv6 Deployment. R. Koodli. July 2011. (Format: TXT, HTML) (Obsoleted by RFC6342) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6312) 6313 Export of Structured Data in IP Flow Information Export (IPFIX). B. Claise, G. Dhandapani, P. Aitken, S. Yates. July 2011. (Format: TXT, HTML) (Updates RFC5102) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6313) 6314 NAT Traversal Practices for Client-Server SIP. C. Boulton, J. Rosenberg, G. Camarillo, F. Audet. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6314) 6315 IANA Registration for Enumservice 'iax'. E. Guy, K. Darilion. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6315) 6316 Sockets Application Program Interface (API) for Multihoming Shim. M. Komu, M. Bagnulo, K. Slavov, S. Sugimoto, Ed.. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6316) 6317 Basic Socket Interface Extensions for the Host Identity Protocol (HIP). M. Komu, T. Henderson. July 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6317) 6318 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME). R. Housley, J. Solinas. June 2011. (Format: TXT, HTML) (Obsoletes RFC5008) (Status: HISTORIC) (DOI: 10.17487/RFC6318) 6319 Issues Associated with Designating Additional Private IPv4 Address Space. M. Azinger, L. Vegoda. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6319) 6320 Protocol for Access Node Control Mechanism in Broadband Networks. S. Wadhwa, J. Moisand, T. Haag, N. Voigt, T. Taylor, Ed.. October 2011. (Format: TXT, HTML) (Updated by RFC7256) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6320) 6321 xCal: The XML Format for iCalendar. C. Daboo, M. Douglass, S. Lees. August 2011. (Format: TXT, HTML) (Updated by RFC6868, RFC7529) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6321) 6322 Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams. P. Hoffman. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6322) 6323 Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP). G. Renker, G. Fairhurst. July 2011. (Format: TXT, HTML) (Updates RFC4342, RFC5622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6323) 6324 Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations. G. Nakibly, F. Templin. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6324) 6325 Routing Bridges (RBridges): Base Protocol Specification. R. Perlman, D. Eastlake 3rd, D. Dutt, S. Gai, A. Ghanwani. July 2011. (Format: TXT, HTML) (Updated by RFC6327, RFC6439, RFC7172, RFC7177, RFC7357, RFC7179, RFC7180, RFC7455, RFC7780, RFC7783, RFC8139, RFC8249, RFC8361, RFC8377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6325) 6326 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS. D. Eastlake, A. Banerjee, D. Dutt, R. Perlman, A. Ghanwani. July 2011. (Format: TXT, HTML) (Obsoleted by RFC7176) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6326) 6327 Routing Bridges (RBridges): Adjacency. D. Eastlake 3rd, R. Perlman, A. Ghanwani, D. Dutt, V. Manral. July 2011. (Format: TXT, HTML) (Obsoleted by RFC7177) (Updates RFC6325) (Updated by RFC7180) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6327) 6328 IANA Considerations for Network Layer Protocol Identifiers. D. Eastlake 3rd. July 2011. (Format: TXT, HTML) (Also BCP0164) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6328) 6329 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging. D. Fedyk, Ed., P. Ashwood-Smith, Ed., D. Allan, A. Bragg, P. Unbehagen. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6329) 6330 RaptorQ Forward Error Correction Scheme for Object Delivery. M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer, L. Minder. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6330) 6331 Moving DIGEST-MD5 to Historic. A. Melnikov. July 2011. (Format: TXT, HTML) (Obsoletes RFC2831) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6331) 6332 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs). A. Begen, E. Friedrich. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6332) 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion. A. Durand, R. Droms, J. Woodyatt, Y. Lee. August 2011. (Format: TXT, HTML) (Updated by RFC7335) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6333) 6334 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite. D. Hankins, T. Mrugalski. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6334) 6335 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry. M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. Cheshire. August 2011. (Format: TXT, HTML) (Updates RFC2780, RFC2782, RFC3828, RFC4340, RFC4960, RFC5595) (Also BCP0165) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6335) 6336 IANA Registry for Interactive Connectivity Establishment (ICE) Options. M. Westerlund, C. Perkins. July 2011. (Format: TXT, HTML) (Obsoleted by RFC8839) (Updates RFC5245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6336) 6337 Session Initiation Protocol (SIP) Usage of the Offer/Answer Model. S. Okumura, T. Sawada, P. Kyzivat. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6337) 6338 Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC). V. Giralt, R. McDuff. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6338) 6339 Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API). S. Josefsson, L. Hornquist Astrand. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6339) 6340 Textual Conventions for the Representation of Floating-Point Numbers. R. Presuhn. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6340) 6341 Use Cases and Requirements for SIP-Based Media Recording (SIPREC). K. Rehor, Ed., L. Portman, Ed., A. Hutton, R. Jain. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6341) 6342 Mobile Networks Considerations for IPv6 Deployment. R. Koodli. August 2011. (Format: TXT, HTML) (Obsoletes RFC6312) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6342) 6343 Advisory Guidelines for 6to4 Deployment. B. Carpenter. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6343) 6344 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS). G. Bernstein, Ed., D. Caviglia, R. Rabbat, H. van Helvoort. August 2011. (Format: TXT, HTML) (Updates RFC4606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6344) 6345 Protocol for Carrying Authentication for Network Access (PANA) Relay Element. P. Duffy, S. Chakrabarti, R. Cragie, Y. Ohba, Ed., A. Yegin. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6345) 6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage. R. Bush, Ed.. August 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6346) 6347 Datagram Transport Layer Security Version 1.2. E. Rescorla, N. Modadugu. January 2012. (Format: TXT, HTML) (Obsoletes RFC4347) (Obsoleted by RFC9147) (Updated by RFC7507, RFC7905, RFC8996, RFC9146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6347) 6348 Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol. JL. Le Roux, Ed., T. Morin, Ed.. September 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6348) 6349 Framework for TCP Throughput Testing. B. Constantine, G. Forget, R. Geib, R. Schrage. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6349) 6350 vCard Format Specification. S. Perreault. August 2011. (Format: TXT, HTML) (Obsoletes RFC2425, RFC2426, RFC4770) (Updates RFC2739) (Updated by RFC6868) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6350) 6351 xCard: vCard XML Representation. S. Perreault. August 2011. (Format: TXT, HTML) (Updated by RFC6868) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6351) 6352 CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV). C. Daboo. August 2011. (Format: TXT, HTML) (Updated by RFC6764) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6352) 6353 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP). W. Hardaker. July 2011. (Format: TXT, HTML) (Obsoletes RFC5953) (Updated by RFC8996) (Also STD0078) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6353) 6354 Forward-Shifted RTP Redundancy Payload Support. Q. Xie. August 2011. (Format: TXT, HTML) (Updates RFC2198, RFC4102) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6354) 6355 Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID). T. Narten, J. Johnson. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6355) 6356 Coupled Congestion Control for Multipath Transport Protocols. C. Raiciu, M. Handley, D. Wischik. October 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6356) 6357 Design Considerations for Session Initiation Protocol (SIP) Overload Control. V. Hilt, E. Noel, C. Shen, A. Abdelal. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6357) 6358 Additional Master Secret Inputs for TLS. P. Hoffman. January 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6358) 6359 Datatracker Extensions to Include IANA and RFC Editor Processing Information. S. Ginoza, M. Cotton, A. Morris. September 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6359) 6360 Conclusion of FYI RFC Sub-Series. R. Housley. August 2011. (Format: TXT, HTML) (Obsoletes RFC1150) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6360) 6361 PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol. J. Carlson, D. Eastlake 3rd. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6361) 6362 Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT). K. Meadors, Ed.. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6362) 6363 Forward Error Correction (FEC) Framework. M. Watson, A. Begen, V. Roca. October 2011. (Format: TXT, HTML) (Updated by RFC8680) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6363) 6364 Session Description Protocol Elements for the Forward Error Correction (FEC) Framework. A. Begen. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6364) 6365 Terminology Used in Internationalization in the IETF. P. Hoffman, J. Klensin. September 2011. (Format: TXT, HTML) (Obsoletes RFC3536) (Also BCP0166) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6365) 6366 Requirements for an Internet Audio Codec. J. Valin, K. Vos. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6366) 6367 Addition of the Camellia Cipher Suites to Transport Layer Security (TLS). S. Kanno, M. Kanda. September 2011. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6367) 6368 Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs). P. Marques, R. Raszuk, K. Patel, K. Kumaki, T. Yamagata. September 2011. (Format: TXT, HTML) (Updated by RFC7606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6368) 6369 Forwarding and Control Element Separation (ForCES) Implementation Experience. E. Haleplidis, O. Koufopavlou, S. Denazis. September 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6369) 6370 MPLS Transport Profile (MPLS-TP) Identifiers. M. Bocci, G. Swallow, E. Gray. September 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6370) 6371 Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks. I. Busi, Ed., D. Allan, Ed.. September 2011. (Format: TXT, HTML) (Updated by RFC6435) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6371) 6372 MPLS Transport Profile (MPLS-TP) Survivability Framework. N. Sprecher, Ed., A. Farrel, Ed.. September 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6372) 6373 MPLS Transport Profile (MPLS-TP) Control Plane Framework. L. Andersson, Ed., L. Berger, Ed., L. Fang, Ed., N. Bitar, Ed., E. Gray, Ed.. September 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6373) 6374 Packet Loss and Delay Measurement for MPLS Networks. D. Frost, S. Bryant. September 2011. (Format: TXT, HTML) (Updated by RFC7214) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6374) 6375 A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks. D. Frost, Ed., S. Bryant, Ed.. September 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6375) 6376 DomainKeys Identified Mail (DKIM) Signatures. D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed.. September 2011. (Format: TXT, HTML) (Obsoletes RFC4871, RFC5672) (Updated by RFC8301, RFC8463, RFC8553, RFC8616) (Also STD0076) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6376) 6377 DomainKeys Identified Mail (DKIM) and Mailing Lists. M. Kucherawy. September 2011. (Format: TXT, HTML) (Also BCP0167) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6377) 6378 MPLS Transport Profile (MPLS-TP) Linear Protection. Y. Weingarten, Ed., S. Bryant, E. Osborne, N. Sprecher, A. Fulignoli, Ed.. October 2011. (Format: TXT, HTML) (Updated by RFC7214, RFC7271, RFC7324) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6378) 6379 Suite B Cryptographic Suites for IPsec. L. Law, J. Solinas. October 2011. (Format: TXT, HTML) (Obsoletes RFC4869) (Status: HISTORIC) (DOI: 10.17487/RFC6379) 6380 Suite B Profile for Internet Protocol Security (IPsec). K. Burgin, M. Peck. October 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6380) 6381 The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types. R. Gellens, D. Singer, P. Frojdh. August 2011. (Format: TXT, HTML) (Obsoletes RFC4281) (Updates RFC3839, RFC4393, RFC4337) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6381) 6382 Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services. D. McPherson, R. Donnelly, F. Scalzo. October 2011. (Format: TXT, HTML) (Also BCP0169) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6382) 6383 Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE. K. Shiomoto, A. Farrel. September 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6383) 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation. I. van Beijnum. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6384) 6385 General Area Review Team (Gen-ART) Experiences. M. Barnes, A. Doria, H. Alvestrand, B. Carpenter. October 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6385) 6386 VP8 Data Format and Decoding Guide. J. Bankoski, J. Koleszar, L. Quillio, J. Salonen, P. Wilkins, Y. Xu. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6386) 6387 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). A. Takacs, L. Berger, D. Caviglia, D. Fedyk, J. Meuric. September 2011. (Format: TXT, HTML) (Obsoletes RFC5467) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6387) 6388 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths. IJ. Wijnands, Ed., I. Minei, Ed., K. Kompella, B. Thomas. November 2011. (Format: TXT, HTML) (Updated by RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6388) 6389 MPLS Upstream Label Assignment for LDP. R. Aggarwal, JL. Le Roux. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6389) 6390 Guidelines for Considering New Performance Metric Development. A. Clark, B. Claise. October 2011. (Format: TXT, HTML) (Also BCP0170) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6390) 6391 Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network. S. Bryant, Ed., C. Filsfils, U. Drafz, V. Kompella, J. Regan, S. Amante. November 2011. (Format: TXT, HTML) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6391) 6392 A Survey of In-Network Storage Systems. R. Alimi, Ed., A. Rahman, Ed., Y. Yang, Ed.. October 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6392) 6393 Moving RFC 4693 to Historic. M. Yevstifeyev. September 2011. (Format: TXT, HTML) (Obsoletes RFC4693) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6393) 6394 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE). R. Barnes. October 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6394) 6395 An Interface Identifier (ID) Hello Option for PIM. S. Gulrajani, S. Venaas. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6395) 6396 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format. L. Blunk, M. Karir, C. Labovitz. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6396) 6397 Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions. T. Manderson. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6397) 6398 IP Router Alert Considerations and Usage. F. Le Faucheur, Ed.. October 2011. (Format: TXT, HTML) (Updates RFC2113, RFC2711) (Also BCP0168) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6398) 6399 Not Issued. 6400 Not Issued. 6401 RSVP Extensions for Admission Priority. F. Le Faucheur, J. Polk, K. Carlberg. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6401) 6402 Certificate Management over CMS (CMC) Updates. J. Schaad. November 2011. (Format: TXT, HTML) (Updates RFC5272, RFC5273, RFC5274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6402) 6403 Suite B Profile of Certificate Management over CMS. L. Zieglar, S. Turner, M. Peck. November 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6403) 6404 Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures. J. Seedorf, S. Niccolini, E. Chen, H. Scholz. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6404) 6405 Voice over IP (VoIP) SIP Peering Use Cases. A. Uzelac, Ed., Y. Lee, Ed.. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6405) 6406 Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture. D. Malas, Ed., J. Livingood, Ed.. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6406) 6407 The Group Domain of Interpretation. B. Weis, S. Rowles, T. Hardjono. October 2011. (Format: TXT, HTML) (Obsoletes RFC3547) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6407) 6408 Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage. M. Jones, J. Korhonen, L. Morand. November 2011. (Format: TXT, HTML) (Updates RFC3588) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6408) 6409 Message Submission for Mail. R. Gellens, J. Klensin. November 2011. (Format: TXT, HTML) (Obsoletes RFC4409) (Updated by RFC8314) (Also STD0072) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6409) 6410 Reducing the Standards Track to Two Maturity Levels. R. Housley, D. Crocker, E. Burger. October 2011. (Format: TXT, HTML) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6410) 6411 Applicability of Keying Methods for RSVP Security. M. Behringer, F. Le Faucheur, B. Weis. October 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6411) 6412 Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence. S. Poretsky, B. Imhoff, K. Michielsen. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6412) 6413 Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence. S. Poretsky, B. Imhoff, K. Michielsen. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6413) 6414 Benchmarking Terminology for Protection Performance. S. Poretsky, R. Papneja, J. Karthik, S. Vapiwala. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6414) 6415 Web Host Metadata. E. Hammer-Lahav, Ed., B. Cook. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6415) 6416 RTP Payload Format for MPEG-4 Audio/Visual Streams. M. Schmidt, F. de Bont, S. Doehla, J. Kim. October 2011. (Format: TXT, HTML) (Obsoletes RFC3016) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6416) 6417 How to Contribute Research Results to Internet Standardization. P. Eardley, L. Eggert, M. Bagnulo, R. Winter. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6417) 6418 Multiple Interfaces and Provisioning Domains Problem Statement. M. Blanchet, P. Seite. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6418) 6419 Current Practices for Multiple-Interface Hosts. M. Wasserman, P. Seite. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6419) 6420 PIM Multi-Topology ID (MT-ID) Join Attribute. Y. Cai, H. Ou. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6420) 6421 Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS). D. Nelson, Ed.. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6421) 6422 Relay-Supplied DHCP Options. T. Lemon, Q. Wu. December 2011. (Format: TXT, HTML) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6422) 6423 Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP). H. Li, L. Martini, J. He, F. Huang. November 2011. (Format: TXT, HTML) (Updates RFC5586) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6423) 6424 Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels. N. Bahadur, K. Kompella, G. Swallow. November 2011. (Format: TXT, HTML) (Obsoleted by RFC8029) (Updates RFC4379) (Updated by RFC7537) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6424) 6425 Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping. S. Saxena, Ed., G. Swallow, Z. Ali, A. Farrel, S. Yasukawa, T. Nadeau. November 2011. (Format: TXT, HTML) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6425) 6426 MPLS On-Demand Connectivity Verification and Route Tracing. E. Gray, N. Bahadur, S. Boutros, R. Aggarwal. November 2011. (Format: TXT, HTML) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6426) 6427 MPLS Fault Management Operations, Administration, and Maintenance (OAM). G. Swallow, Ed., A. Fulignoli, Ed., M. Vigoureux, Ed., S. Boutros, D. Ward. November 2011. (Format: TXT, HTML) (Updated by RFC7214) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6427) 6428 Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile. D. Allan, Ed., G. Swallow, Ed., J. Drake, Ed.. November 2011. (Format: TXT, HTML) (Updated by RFC7214) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6428) 6429 TCP Sender Clarification for Persist Condition. M. Bashyam, M. Jethanandani, A. Ramaiah. December 2011. (Format: TXT, HTML) (Obsoleted by RFC9293) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6429) 6430 Email Feedback Report Type Value: not-spam. K. Li, B. Leiba. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6430) 6431 Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP). M. Boucadair, P. Levis, G. Bajko, T. Savolainen, T. Tsou. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6431) 6432 Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses. R. Jesske, L. Liess. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6432) 6433 Requirements for a Working Group Milestones Tool. P. Hoffman. November 2011. (Format: TXT, HTML) (Updates RFC6292) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6433) 6434 IPv6 Node Requirements. E. Jankiewicz, J. Loughney, T. Narten. December 2011. (Format: TXT, HTML) (Obsoletes RFC4294) (Obsoleted by RFC8504) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6434) 6435 MPLS Transport Profile Lock Instruct and Loopback Functions. S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. Vigoureux, Ed., X. Dai, Ed.. November 2011. (Format: TXT, HTML) (Updates RFC6371) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6435) 6436 Rationale for Update to the IPv6 Flow Label Specification. S. Amante, B. Carpenter, S. Jiang. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6436) 6437 IPv6 Flow Label Specification. S. Amante, B. Carpenter, S. Jiang, J. Rajahalme. November 2011. (Format: TXT, HTML) (Obsoletes RFC3697) (Updates RFC2205, RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6437) 6438 Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels. B. Carpenter, S. Amante. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6438) 6439 Routing Bridges (RBridges): Appointed Forwarders. R. Perlman, D. Eastlake, Y. Li, A. Banerjee, F. Hu. November 2011. (Format: TXT, HTML) (Obsoleted by RFC8139) (Updates RFC6325) (Updated by RFC7180) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6439) 6440 The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option. G. Zorn, Q. Wu, Y. Wang. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6440) 6441 Time to Remove Filters for Previously Unallocated IPv4 /8s. L. Vegoda. November 2011. (Format: TXT, HTML) (Also BCP0171) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6441) 6442 Location Conveyance for the Session Initiation Protocol. J. Polk, B. Rosen, J. Peterson. December 2011. (Format: TXT, HTML) (Updated by RFC8262, RFC8787) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6442) 6443 Framework for Emergency Calling Using Internet Multimedia. B. Rosen, H. Schulzrinne, J. Polk, A. Newton. December 2011. (Format: TXT, HTML) (Updated by RFC7852) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6443) 6444 Location Hiding: Problem Statement and Requirements. H. Schulzrinne, L. Liess, H. Tschofenig, B. Stark, A. Kuett. January 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6444) 6445 Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute. T. Nadeau, Ed., A. Koushik, Ed., R. Cetin, Ed.. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6445) 6446 Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control. A. Niemi, K. Kiss, S. Loreto. January 2012. (Format: TXT, HTML) (Updates RFC3265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6446) 6447 Filtering Location Notifications in the Session Initiation Protocol (SIP). R. Mahy, B. Rosen, H. Tschofenig. January 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6447) 6448 The Unencrypted Form of Kerberos 5 KRB-CRED Message. R. Yount. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6448) 6449 Complaint Feedback Loop Operational Recommendations. J. Falk, Ed.. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6449) 6450 Multicast Ping Protocol. S. Venaas. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6450) 6451 Location-to-Service Translation (LoST) Protocol Extensions. A. Forte, H. Schulzrinne. December 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6451) 6452 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0. P. Faltstrom, Ed., P. Hoffman, Ed.. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6452) 6453 A URN Namespace for the Open Grid Forum (OGF). F. Dijkstra, R. Hughes-Jones. December 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6453) 6454 The Web Origin Concept. A. Barth. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6454) 6455 The WebSocket Protocol. I. Fette, A. Melnikov. December 2011. (Format: TXT, HTML) (Updated by RFC7936, RFC8307, RFC8441) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6455) 6456 Multi-Segment Pseudowires in Passive Optical Networks. H. Li, R. Zheng, A. Farrel. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6456) 6457 PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering. T. Takeda, Ed., A. Farrel. December 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6457) 6458 Sockets API Extensions for the Stream Control Transmission Protocol (SCTP). R. Stewart, M. Tuexen, K. Poon, P. Lei, V. Yasevich. December 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6458) 6459 IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS). J. Korhonen, Ed., J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila. January 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6459) 6460 Suite B Profile for Transport Layer Security (TLS). M. Salter, R. Housley. January 2012. (Format: TXT, HTML) (Obsoletes RFC5430) (Updated by RFC8996) (Status: HISTORIC) (DOI: 10.17487/RFC6460) 6461 Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements. S. Channabasappa, Ed.. January 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6461) 6462 Report from the Internet Privacy Workshop. A. Cooper. January 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6462) 6463 Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6. J. Korhonen, Ed., S. Gundavelli, H. Yokota, X. Cui. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6463) 6464 A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication. J. Lennox, Ed., E. Ivov, E. Marocco. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6464) 6465 A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication. E. Ivov, Ed., E. Marocco, Ed., J. Lennox. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6465) 6466 IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP). G. Salgueiro. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6466) 6467 Secure Password Framework for Internet Key Exchange Version 2 (IKEv2). T. Kivinen. December 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6467) 6468 Sieve Notification Mechanism: SIP MESSAGE. A. Melnikov, B. Leiba, K. Li. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6468) 6469 RTP Payload Format for DV (IEC 61834) Video. K. Kobayashi, K. Mishima, S. Casner, C. Bormann. December 2011. (Format: TXT, HTML) (Obsoletes RFC3189) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6469) 6470 Network Configuration Protocol (NETCONF) Base Notifications. A. Bierman. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6470) 6471 Overview of Best Email DNS-Based List (DNSBL) Operational Practices. C. Lewis, M. Sergeant. January 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6471) 6472 Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP. W. Kumari, K. Sriram. December 2011. (Format: TXT, HTML) (Also BCP0172) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6472) 6473 vCard KIND:application. P. Saint-Andre. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6473) 6474 vCard Format Extensions: Place of Birth, Place and Date of Death. K. Li, B. Leiba. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6474) 6475 Proxy Mobile IPv6 Management Information Base. G. Keeni, K. Koide, S. Gundavelli, R. Wakikawa. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6475) 6476 Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS). P. Gutmann. January 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6476) 6477 Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail. A. Melnikov, G. Lunt. January 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6477) 6478 Pseudowire Status for Static Pseudowires. L. Martini, G. Swallow, G. Heron, M. Bocci. May 2012. (Format: TXT, HTML) (Updates RFC5885) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6478) 6479 IPsec Anti-Replay Algorithm without Bit Shifting. X. Zhang, T. Tsou. January 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6479) 6480 An Infrastructure to Support Secure Internet Routing. M. Lepinski, S. Kent. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6480) 6481 A Profile for Resource Certificate Repository Structure. G. Huston, R. Loomans, G. Michaelson. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6481) 6482 A Profile for Route Origin Authorizations (ROAs). M. Lepinski, S. Kent, D. Kong. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6482) 6483 Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs). G. Huston, G. Michaelson. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6483) 6484 Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI). S. Kent, D. Kong, K. Seo, R. Watro. February 2012. (Format: TXT, HTML) (Also BCP0173) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6484) 6485 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI). G. Huston. February 2012. (Format: TXT, HTML) (Obsoleted by RFC7935) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6485) 6486 Manifests for the Resource Public Key Infrastructure (RPKI). R. Austein, G. Huston, S. Kent, M. Lepinski. February 2012. (Format: TXT, HTML) (Obsoleted by RFC9286) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6486) 6487 A Profile for X.509 PKIX Resource Certificates. G. Huston, G. Michaelson, R. Loomans. February 2012. (Format: TXT, HTML) (Updated by RFC7318, RFC8209) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6487) 6488 Signed Object Template for the Resource Public Key Infrastructure (RPKI). M. Lepinski, A. Chi, S. Kent. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6488) 6489 Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI). G. Huston, G. Michaelson, S. Kent. February 2012. (Format: TXT, HTML) (Also BCP0174) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6489) 6490 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator. G. Huston, S. Weiler, G. Michaelson, S. Kent. February 2012. (Format: TXT, HTML) (Obsoleted by RFC7730) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6490) 6491 Resource Public Key Infrastructure (RPKI) Objects Issued by IANA. T. Manderson, L. Vegoda, S. Kent. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6491) 6492 A Protocol for Provisioning Resource Certificates. G. Huston, R. Loomans, B. Ellacott, R. Austein. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6492) 6493 The Resource Public Key Infrastructure (RPKI) Ghostbusters Record. R. Bush. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6493) 6494 Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND). R. Gagliano, S. Krishnan, A. Kukec. February 2012. (Format: TXT, HTML) (Updates RFC3971) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6494) 6495 Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields. R. Gagliano, S. Krishnan, A. Kukec. February 2012. (Format: TXT, HTML) (Updates RFC3971) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6495) 6496 Secure Proxy ND Support for SEcure Neighbor Discovery (SEND). S. Krishnan, J. Laganier, M. Bonola, A. Garcia-Martinez. February 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6496) 6497 BCP 47 Extension T - Transformed Content. M. Davis, A. Phillips, Y. Umaoka, C. Falk. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6497) 6498 Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package. J. Stone, R. Kumar, F. Andreasen. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6498) 6499 Not Issued. 6500 Not Issued. 6501 Conference Information Data Model for Centralized Conferencing (XCON). O. Novo, G. Camarillo, D. Morgan, J. Urpalainen. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6501) 6502 Conference Event Package Data Format Extension for Centralized Conferencing (XCON). G. Camarillo, S. Srinivasan, R. Even, J. Urpalainen. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6502) 6503 Centralized Conferencing Manipulation Protocol. M. Barnes, C. Boulton, S. Romano, H. Schulzrinne. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6503) 6504 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples. M. Barnes, L. Miniero, R. Presta, S P. Romano. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6504) 6505 A Mixer Control Package for the Media Control Channel Framework. S. McGlashan, T. Melanchuk, C. Boulton. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6505) 6506 Supporting Authentication Trailer for OSPFv3. M. Bhatia, V. Manral, A. Lindem. February 2012. (Format: TXT, HTML) (Obsoleted by RFC7166) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6506) 6507 Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI). M. Groves. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6507) 6508 Sakai-Kasahara Key Encryption (SAKKE). M. Groves. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6508) 6509 MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY). M. Groves. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6509) 6510 Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects. L. Berger, G. Swallow. February 2012. (Format: TXT, HTML) (Updates RFC4875, RFC5420) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6510) 6511 Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths. Z. Ali, G. Swallow, R. Aggarwal. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6511) 6512 Using Multipoint LDP When the Backbone Has No Route to the Root. IJ. Wijnands, E. Rosen, M. Napierala, N. Leymann. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6512) 6513 Multicast in MPLS/BGP IP VPNs. E. Rosen, Ed., R. Aggarwal, Ed.. February 2012. (Format: TXT, HTML) (Updated by RFC7582, RFC7900, RFC7988) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6513) 6514 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs. R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter. February 2012. (Format: TXT, HTML) (Updated by RFC6515, RFC6625, RFC7385, RFC7441, RFC7582, RFC7899, RFC7900, RFC7902, RFC7988, RFC8534, RFC9081) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6514) 6515 IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN. R. Aggarwal, E. Rosen. February 2012. (Format: TXT, HTML) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6515) 6516 IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages. Y. Cai, E. Rosen, Ed., I. Wijnands. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6516) 6517 Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution. T. Morin, Ed., B. Niven-Jenkins, Ed., Y. Kamite, R. Zhang, N. Leymann, N. Bitar. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6517) 6518 Keying and Authentication for Routing Protocols (KARP) Design Guidelines. G. Lebovitz, M. Bhatia. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6518) 6519 RADIUS Extensions for Dual-Stack Lite. R. Maglione, A. Durand. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6519) 6520 Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension. R. Seggelmann, M. Tuexen, M. Williams. February 2012. (Format: TXT, HTML) (Updated by RFC8447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6520) 6521 Home Agent-Assisted Route Optimization between Mobile IPv4 Networks. A. Makela, J. Korhonen. February 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6521) 6522 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages. M. Kucherawy, Ed.. January 2012. (Format: TXT, HTML) (Obsoletes RFC3462) (Updated by RFC6533) (Also STD0073) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6522) 6523 Not Issued. 6524 Not Issued. 6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration. R. Stewart, M. Tuexen, P. Lei. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6525) 6526 IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream. B. Claise, P. Aitken, A. Johnson, G. Muenz. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6526) 6527 Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3). K. Tata. March 2012. (Format: TXT, HTML) (Obsoletes RFC2787) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6527) 6528 Defending against Sequence Number Attacks. F. Gont, S. Bellovin. February 2012. (Format: TXT, HTML) (Obsoletes RFC1948) (Obsoleted by RFC9293) (Updates RFC0793) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6528) 6529 Host/Host Protocol for the ARPA Network. A. McKenzie, S. Crocker. April 2012. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6529) 6530 Overview and Framework for Internationalized Email. J. Klensin, Y. Ko. February 2012. (Format: TXT, HTML) (Obsoletes RFC4952, RFC5504, RFC5825) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6530) 6531 SMTP Extension for Internationalized Email. J. Yao, W. Mao. February 2012. (Format: TXT, HTML) (Obsoletes RFC5336) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6531) 6532 Internationalized Email Headers. A. Yang, S. Steele, N. Freed. February 2012. (Format: TXT, HTML) (Obsoletes RFC5335) (Updates RFC2045) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6532) 6533 Internationalized Delivery Status and Disposition Notifications. T. Hansen, Ed., C. Newman, A. Melnikov. February 2012. (Format: TXT, HTML) (Obsoletes RFC5337) (Updates RFC3461, RFC3464, RFC3798, RFC6522) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6533) 6534 Loss Episode Metrics for IP Performance Metrics (IPPM). N. Duffield, A. Morton, J. Sommers. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6534) 6535 Dual-Stack Hosts Using "Bump-in-the-Host" (BIH). B. Huang, H. Deng, T. Savolainen. February 2012. (Format: TXT, HTML) (Obsoletes RFC2767, RFC3338) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6535) 6536 Network Configuration Protocol (NETCONF) Access Control Model. A. Bierman, M. Bjorklund. March 2012. (Format: TXT, HTML) (Obsoleted by RFC8341) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6536) 6537 Host Identity Protocol Distributed Hash Table Interface. J. Ahrenholz. February 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6537) 6538 The Host Identity Protocol (HIP) Experiment Report. T. Henderson, A. Gurtov. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6538) 6539 IBAKE: Identity-Based Authenticated Key Exchange. V. Cakulev, G. Sundaram, I. Broustis. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6539) 6540 IPv6 Support Required for All IP-Capable Nodes. W. George, C. Donley, C. Liljenstolpe, L. Howard. April 2012. (Format: TXT, HTML) (Also BCP0177) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6540) 6541 DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures. M. Kucherawy. February 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6541) 6542 Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility. S. Emery. March 2012. (Format: TXT, HTML) (Updates RFC4121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6542) 6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6. S. Gundavelli. May 2012. (Format: TXT, HTML) (Updates RFC5213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6543) 6544 TCP Candidates with Interactive Connectivity Establishment (ICE). J. Rosenberg, A. Keranen, B. B. Lowekamp, A. B. Roach. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6544) 6545 Real-time Inter-network Defense (RID). K. Moriarty. April 2012. (Format: TXT, HTML) (Obsoletes RFC6045) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6545) 6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS. B. Trammell. April 2012. (Format: TXT, HTML) (Obsoletes RFC6046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6546) 6547 RFC 3627 to Historic Status. W. George. February 2012. (Format: TXT, HTML) (Obsoletes RFC3627) (Updates RFC6164) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6547) 6548 Independent Submission Editor Model. N. Brownlee, Ed., IAB. June 2012. (Format: TXT, HTML) (Obsoletes RFC5620) (Obsoleted by RFC8730) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6548) 6549 OSPFv2 Multi-Instance Extensions. A. Lindem, A. Roy, S. Mirtorabi. March 2012. (Format: TXT, HTML) (Updates RFC2328) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6549) 6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander. March 2012. (Format: TXT, HTML) (Updated by RFC9008, RFC9010) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6550) 6551 Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks. JP. Vasseur, Ed., M. Kim, Ed., K. Pister, N. Dejean, D. Barthel. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6551) 6552 Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL). P. Thubert, Ed.. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6552) 6553 The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams. J. Hui, JP. Vasseur. March 2012. (Format: TXT, HTML) (Updated by RFC9008) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6553) 6554 An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL). J. Hui, JP. Vasseur, D. Culler, V. Manral. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6554) 6555 Happy Eyeballs: Success with Dual-Stack Hosts. D. Wing, A. Yourtchenko. April 2012. (Format: TXT, HTML) (Obsoleted by RFC8305) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6555) 6556 Testing Eyeball Happiness. F. Baker. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6556) 6557 Procedures for Maintaining the Time Zone Database. E. Lear, P. Eggert. February 2012. (Format: TXT, HTML) (Also BCP0175) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6557) 6558 Sieve Extension for Converting Messages before Delivery. A. Melnikov, B. Leiba, K. Li. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6558) 6559 A Reliable Transport Mechanism for PIM. D. Farinacci, IJ. Wijnands, S. Venaas, M. Napierala. March 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6559) 6560 One-Time Password (OTP) Pre-Authentication. G. Richards. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6560) 6561 Recommendations for the Remediation of Bots in ISP Networks. J. Livingood, N. Mody, M. O'Reirdan. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6561) 6562 Guidelines for the Use of Variable Bit Rate Audio with Secure RTP. C. Perkins, JM. Valin. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6562) 6563 Moving A6 to Historic Status. S. Jiang, D. Conrad, B. Carpenter. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6563) 6564 A Uniform Format for IPv6 Extension Headers. S. Krishnan, J. Woodyatt, E. Kline, J. Hoagland, M. Bhatia. April 2012. (Format: TXT, HTML) (Updates RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6564) 6565 OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol. P. Pillay-Esnault, P. Moyer, J. Doyle, E. Ertekin, M. Lundberg. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6565) 6566 A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments. Y. Lee, Ed., G. Bernstein, Ed., D. Li, G. Martinelli. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6566) 6567 Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP. A. Johnston, L. Liess. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6567) 6568 Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). E. Kim, D. Kaspar, JP. Vasseur. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6568) 6569 Guidelines for Development of an Audio Codec within the IETF. JM. Valin, S. Borilin, K. Vos, C. Montgomery, R. Chen. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6569) 6570 URI Template. J. Gregorio, R. Fielding, M. Hadley, M. Nottingham, D. Orchard. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6570) 6571 Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks. C. Filsfils, Ed., P. Francois, Ed., M. Shand, B. Decraene, J. Uttaro, N. Leymann, M. Horneffer. June 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6571) 6572 RADIUS Support for Proxy Mobile IPv6. F. Xia, B. Sarikaya, J. Korhonen, Ed., S. Gundavelli, D. Damic. June 2012. (Format: TXT, HTML) (Updated by RFC8044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6572) 6573 The Item and Collection Link Relations. M. Amundsen. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6573) 6574 Report from the Smart Object Workshop. H. Tschofenig, J. Arkko. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6574) 6575 Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs. H. Shah, Ed., E. Rosen, Ed., G. Heron, Ed., V. Kompella, Ed.. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6575) 6576 IP Performance Metrics (IPPM) Standard Advancement Testing. R. Geib, Ed., A. Morton, R. Fardid, A. Steinmitz. March 2012. (Format: TXT, HTML) (Also BCP0176) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6576) 6577 Authentication-Results Registration Update for Sender Policy Framework (SPF) Results. M. Kucherawy. March 2012. (Format: TXT, HTML) (Obsoleted by RFC7001) (Updates RFC5451) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6577) 6578 Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV). C. Daboo, A. Quillaud. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6578) 6579 The 'disclosure' Link Relation Type. M. Yevstifeyev. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6579) 6580 IANA Registries for the Remote Direct Data Placement (RDDP) Protocols. M. Ko, D. Black. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6580) 6581 Enhanced Remote Direct Memory Access (RDMA) Connection Establishment. A. Kanevsky, Ed., C. Bestler, Ed., R. Sharp, S. Wise. April 2012. (Format: TXT, HTML) (Updates RFC5043, RFC5044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6581) 6582 The NewReno Modification to TCP's Fast Recovery Algorithm. T. Henderson, S. Floyd, A. Gurtov, Y. Nishida. April 2012. (Format: TXT, HTML) (Obsoletes RFC3782) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6582) 6583 Operational Neighbor Discovery Problems. I. Gashinsky, J. Jaeggli, W. Kumari. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6583) 6584 Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols. V. Roca. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6584) 6585 Additional HTTP Status Codes. M. Nottingham, R. Fielding. April 2012. (Format: TXT, HTML) (Updates RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6585) 6586 Experiences from an IPv6-Only Network. J. Arkko, A. Keranen. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6586) 6587 Transmission of Syslog Messages over TCP. R. Gerhards, C. Lonvick. April 2012. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6587) 6588 A URN Namespace for ucode. C. Ishikawa. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6588) 6589 Considerations for Transitioning Content to IPv6. J. Livingood. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6589) 6590 Redaction of Potentially Sensitive Data from Mail Abuse Reports. J. Falk, Ed., M. Kucherawy, Ed.. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6590) 6591 Authentication Failure Reporting Using the Abuse Reporting Format. H. Fontana. April 2012. (Format: TXT, HTML) (Updated by RFC6692) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6591) 6592 The Null Packet. C. Pignataro. 1 April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6592) 6593 Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS). C. Pignataro, J. Clarke, G. Salgueiro. 1 April 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6593) 6594 Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records. O. Sury. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6594) 6595 A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML). K. Wierenga, E. Lear, S. Josefsson. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6595) 6596 The Canonical Link Relation. M. Ohye, J. Kupke. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6596) 6597 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data. J. Downs, Ed., J. Arbeiter, Ed.. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6597) 6598 IANA-Reserved IPv4 Prefix for Shared Address Space. J. Weil, V. Kuarsingh, C. Donley, C. Liljenstolpe, M. Azinger. April 2012. (Format: TXT, HTML) (Updates RFC5735) (Also BCP0153) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6598) 6599 Not Issued. 6600 Not Issued. 6601 Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks. G. Ash, Ed., D. McDysan. April 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6601) 6602 Bulk Binding Update Support for Proxy Mobile IPv6. F. Abinader, Ed., S. Gundavelli, Ed., K. Leung, S. Krishnan, D. Premec. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6602) 6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation. J. Korhonen, Ed., T. Savolainen, S. Krishnan, O. Troan. May 2012. (Format: TXT, HTML) (Updates RFC3633) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6603) 6604 xNAME RCODE and Status Bits Clarification. D. Eastlake 3rd. April 2012. (Format: TXT, HTML) (Updates RFC1035, RFC2308, RFC2672) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6604) 6605 Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC. P. Hoffman, W.C.A. Wijngaards. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6605) 6606 Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing. E. Kim, D. Kaspar, C. Gomez, C. Bormann. May 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6606) 6607 Virtual Subnet Selection Options for DHCPv4 and DHCPv6. K. Kinnear, R. Johnson, M. Stapp. April 2012. (Format: TXT, HTML) (Updates RFC3046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6607) 6608 Subcodes for BGP Finite State Machine Error. J. Dong, M. Chen, A. Suryanarayana. May 2012. (Format: TXT, HTML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6608) 6609 Sieve Email Filtering: Include Extension. C. Daboo, A. Stone. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6609) 6610 DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6). H. Jang, A. Yegin, K. Chowdhury, J. Choi, T. Lemon. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6610) 6611 Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario. K. Chowdhury, Ed., A. Yegin. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6611) 6612 Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues. G. Giaretta, Ed.. May 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6612) 6613 RADIUS over TCP. A. DeKok. May 2012. (Format: TXT, HTML) (Updated by RFC7930) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6613) 6614 Transport Layer Security (TLS) Encryption for RADIUS. S. Winter, M. McCauley, S. Venaas, K. Wierenga. May 2012. (Format: TXT, HTML) (Updated by RFC8996) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6614) 6615 Definitions of Managed Objects for IP Flow Information Export. T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz. June 2012. (Format: TXT, HTML) (Obsoletes RFC5815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6615) 6616 A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID. E. Lear, H. Tschofenig, H. Mauldin, S. Josefsson. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6616) 6617 Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE). D. Harkins. June 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6617) 6618 Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent. J. Korhonen, Ed., B. Patil, H. Tschofenig, D. Kroeselberg. May 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6618) 6619 Scalable Operation of Address Translators with Per-Interface Bindings. J. Arkko, L. Eggert, M. Townsley. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6619) 6620 FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses. E. Nordmark, M. Bagnulo, E. Levy-Abegnoli. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6620) 6621 Simplified Multicast Forwarding. J. Macker, Ed.. May 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6621) 6622 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs). U. Herberg, T. Clausen. May 2012. (Format: TXT, HTML) (Obsoleted by RFC7182) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6622) 6623 IANA Registry for MEDIACTRL Interactive Voice Response Control Package. E. Burger. May 2012. (Format: TXT, HTML) (Updates RFC6231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6623) 6624 Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling. K. Kompella, B. Kothari, R. Cherukuri. May 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6624) 6625 Wildcards in Multicast VPN Auto-Discovery Routes. E. Rosen, Ed., Y. Rekhter, Ed., W. Hendrickx, R. Qiu. May 2012. (Format: TXT, HTML) (Updates RFC6514) (Updated by RFC7582, RFC7900, RFC8534) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6625) 6626 Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4). G. Tsirtsis, V. Park, V. Narayanan, K. Leung. May 2012. (Format: TXT, HTML) (Updates RFC5177) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6626) 6627 Overview of Pre-Congestion Notification Encoding. G. Karagiannis, K. Chan, T. Moncaster, M. Menth, P. Eardley, B. Briscoe. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6627) 6628 Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2. S. Shin, K. Kobara. June 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6628) 6629 Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6). J. Abley, M. Bagnulo, A. Garcia-Martinez. June 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6629) 6630 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK). Z. Cao, H. Deng, Q. Wu, G. Zorn, Ed.. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6630) 6631 Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2). D. Kuegler, Y. Sheffer. June 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6631) 6632 An Overview of the IETF Network Management Standards. M. Ersue, Ed., B. Claise. June 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6632) 6633 Deprecation of ICMP Source Quench Messages. F. Gont. May 2012. (Format: TXT, HTML) (Updates RFC0792, RFC1122, RFC1812) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6633) 6634 Not Issued. 6635 RFC Editor Model (Version 2). O. Kolkman, Ed., J. Halpern, Ed., IAB. June 2012. (Format: TXT, HTML) (Obsoletes RFC5620) (Obsoleted by RFC8728) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6635) 6636 Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks. H. Asaeda, H. Liu, Q. Wu. May 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6636) 6637 Elliptic Curve Cryptography (ECC) in OpenPGP. A. Jivsov. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6637) 6638 Scheduling Extensions to CalDAV. C. Daboo, B. Desruisseaux. June 2012. (Format: TXT, HTML) (Updates RFC4791, RFC5546) (Updated by RFC7953) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6638) 6639 Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview. D. King, Ed., M. Venkatesan, Ed.. June 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6639) 6640 IETF Meeting Attendees' Frequently Asked (Travel) Questions. W. George. June 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6640) 6641 Using DNS SRV to Specify a Global File Namespace with NFS Version 4. C. Everhart, W. Adamson, J. Zhang. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6641) 6642 RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report. Q. Wu, Ed., F. Xia, R. Even. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6642) 6643 Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules. J. Schoenwaelder. July 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6643) 6644 Rebind Capability in DHCPv6 Reconfigure Messages. D. Evans, R. Droms, S. Jiang. July 2012. (Format: TXT, HTML) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6644) 6645 IP Flow Information Accounting and Export Benchmarking Methodology. J. Novak. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6645) 6646 DECoupled Application Data Enroute (DECADE) Problem Statement. H. Song, N. Zong, Y. Yang, R. Alimi. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6646) 6647 Email Greylisting: An Applicability Statement for SMTP. M. Kucherawy, D. Crocker. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6647) 6648 Deprecating the "X-" Prefix and Similar Constructs in Application Protocols. P. Saint-Andre, D. Crocker, M. Nottingham. June 2012. (Format: TXT, HTML) (Also BCP0178) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6648) 6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos. L. Hornquist Astrand, T. Yu. July 2012. (Format: TXT, HTML) (Obsoletes RFC1510) (Updates RFC1964, RFC4120, RFC4121, RFC4757) (Also BCP0179) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6649) 6650 Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF). J. Falk, M. Kucherawy, Ed.. June 2012. (Format: TXT, HTML) (Updates RFC5965) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6650) 6651 Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting. M. Kucherawy. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6651) 6652 Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format. S. Kitterman. June 2012. (Format: TXT, HTML) (Updates RFC4408) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6652) 6653 DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks. B. Sarikaya, F. Xia, T. Lemon. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6653) 6654 Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd). T. Tsou, C. Zhou, T. Taylor, Q. Chen. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6654) 6655 AES-CCM Cipher Suites for Transport Layer Security (TLS). D. McGrew, D. Bailey. July 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6655) 6656 Description of Cisco Systems' Subnet Allocation Option for DHCPv4. R. Johnson, K. Kinnear, M. Stapp. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6656) 6657 Update to MIME regarding "charset" Parameter Handling in Textual Media Types. A. Melnikov, J. Reschke. July 2012. (Format: TXT, HTML) (Updates RFC2046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6657) 6658 Packet Pseudowire Encapsulation over an MPLS PSN. S. Bryant, Ed., L. Martini, G. Swallow, A. Malis. July 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6658) 6659 Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method. A. Begen. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6659) 6660 Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP). B. Briscoe, T. Moncaster, M. Menth. July 2012. (Format: TXT, HTML) (Obsoletes RFC5696) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6660) 6661 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation. A. Charny, F. Huang, G. Karagiannis, M. Menth, T. Taylor, Ed.. July 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6661) 6662 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation. A. Charny, J. Zhang, G. Karagiannis, M. Menth, T. Taylor, Ed.. July 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6662) 6663 Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain. G. Karagiannis, T. Taylor, K. Chan, M. Menth, P. Eardley. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6663) 6664 S/MIME Capabilities for Public Key Definitions. J. Schaad. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6664) 6665 SIP-Specific Event Notification. A.B. Roach. July 2012. (Format: TXT, HTML) (Obsoletes RFC3265) (Updates RFC3261, RFC4660) (Updated by RFC7621) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6665) 6666 A Discard Prefix for IPv6. N. Hilliard, D. Freedman. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6666) 6667 LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements. K. Raza, S. Boutros, C. Pignataro. July 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6667) 6668 SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol. D. Bider, M. Baushke. July 2012. (Format: TXT, HTML) (Updates RFC4253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6668) 6669 An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks. N. Sprecher, L. Fang. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6669) 6670 The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM). N. Sprecher, KY. Hong. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6670) 6671 Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM). M. Betts. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6671) 6672 DNAME Redirection in the DNS. S. Rose, W. Wijngaards. June 2012. (Format: TXT, HTML) (Obsoletes RFC2672) (Updates RFC3363) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6672) 6673 Round-Trip Packet Loss Metrics. A. Morton. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6673) 6674 Gateway-Initiated Dual-Stack Lite Deployment. F. Brockners, S. Gundavelli, S. Speicher, D. Ward. July 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6674) 6675 A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP. E. Blanton, M. Allman, L. Wang, I. Jarvinen, M. Kojo, Y. Nishida. August 2012. (Format: TXT, HTML) (Obsoletes RFC3517) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6675) 6676 Multicast Addresses for Documentation. S. Venaas, R. Parekh, G. Van de Velde, T. Chown, M. Eubanks. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6676) 6677 Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods. S. Hartman, Ed., T. Clancy, K. Hoeper. July 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6677) 6678 Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method. K. Hoeper, S. Hanna, H. Zhou, J. Salowey, Ed.. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6678) 6679 Explicit Congestion Notification (ECN) for RTP over UDP. M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg. August 2012. (Format: TXT, HTML) (Updated by RFC8311) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6679) 6680 Generic Security Service Application Programming Interface (GSS-API) Naming Extensions. N. Williams, L. Johansson, S. Hartman, S. Josefsson. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6680) 6681 Raptor Forward Error Correction (FEC) Schemes for FECFRAME. M. Watson, T. Stockhammer, M. Luby. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6681) 6682 RTP Payload Format for Raptor Forward Error Correction (FEC). M. Watson, T. Stockhammer, M. Luby. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6682) 6683 Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection. A. Begen, T. Stockhammer. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6683) 6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF). B. Trammell. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6684) 6685 Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry. B. Trammell. July 2012. (Format: TXT, HTML) (Obsoleted by RFC7970) (Updates RFC5070) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6685) 6686 Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments. M. Kucherawy. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6686) 6687 Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL). J. Tripathi, Ed., J. de Oliveira, Ed., JP. Vasseur, Ed.. October 2012. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6687) 6688 Parallel NFS (pNFS) Block Disk Protection. D. Black, Ed., J. Glasgow, S. Faibish. July 2012. (Format: TXT, HTML) (Updates RFC5663) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6688) 6689 Usage of the RSVP ASSOCIATION Object. L. Berger. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6689) 6690 Constrained RESTful Environments (CoRE) Link Format. Z. Shelby. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6690) 6691 TCP Options and Maximum Segment Size (MSS). D. Borman. July 2012. (Format: TXT, HTML) (Obsoleted by RFC9293) (Updates RFC0879, RFC2385) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6691) 6692 Source Ports in Abuse Reporting Format (ARF) Reports. R. Clayton, M. Kucherawy. July 2012. (Format: TXT, HTML) (Updates RFC6591) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6692) 6693 Probabilistic Routing Protocol for Intermittently Connected Networks. A. Lindgren, A. Doria, E. Davies, S. Grasic. August 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6693) 6694 The "about" URI Scheme. S. Moonesamy, Ed.. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6694) 6695 Methods to Convey Forward Error Correction (FEC) Framework Configuration Information. R. Asati. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6695) 6696 EAP Extensions for the EAP Re-authentication Protocol (ERP). Z. Cao, B. He, Y. Shi, Q. Wu, Ed., G. Zorn, Ed.. July 2012. (Format: TXT, HTML) (Obsoletes RFC5296) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6696) 6697 Handover Keying (HOKEY) Architecture Design. G. Zorn, Ed., Q. Wu, T. Taylor, Y. Nir, K. Hoeper, S. Decugis. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6697) 6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. P. Hoffman, J. Schlyter. August 2012. (Format: TXT, HTML) (Updated by RFC7218, RFC7671, RFC8749) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6698) 6699 Not Issued. 6700 Not Issued. 6701 Sanctions Available for Application to Violators of IETF IPR Policy. A. Farrel, P. Resnick. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6701) 6702 Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules. T. Polk, P. Saint-Andre. August 2012. (Format: TXT, HTML) (Updated by RFC8717) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6702) 6703 Reporting IP Network Performance Metrics: Different Points of View. A. Morton, G. Ramachandran, G. Maguluri. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6703) 6704 Forcerenew Nonce Authentication. D. Miles, W. Dec, J. Bristow, R. Maglione. August 2012. (Format: TXT, HTML) (Updates RFC3203) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6704) 6705 Localized Routing for Proxy Mobile IPv6. S. Krishnan, R. Koodli, P. Loureiro, Q. Wu, A. Dutta. September 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6705) 6706 Asymmetric Extended Route Optimization (AERO). F. Templin, Ed.. August 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6706) 6707 Content Distribution Network Interconnection (CDNI) Problem Statement. B. Niven-Jenkins, F. Le Faucheur, N. Bitar. September 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6707) 6708 Application-Layer Traffic Optimization (ALTO) Requirements. S. Kiesel, Ed., S. Previdi, M. Stiemerling, R. Woundy, Y. Yang. September 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6708) 6709 Design Considerations for Protocol Extensions. B. Carpenter, B. Aboba, Ed., S. Cheshire. September 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6709) 6710 Simple Mail Transfer Protocol Extension for Message Transfer Priorities. A. Melnikov, K. Carlberg. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6710) 6711 An IANA Registry for Level of Assurance (LoA) Profiles. L. Johansson. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6711) 6712 Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP). T. Kause, M. Peylo. September 2012. (Format: TXT, HTML) (Updates RFC4210) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6712) 6713 The 'application/zlib' and 'application/gzip' Media Types. J. Levine. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6713) 6714 Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP). C. Holmberg, S. Blau, E. Burger. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6714) 6715 vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group. D. Cauchie, B. Leiba, K. Li. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6715) 6716 Definition of the Opus Audio Codec. JM. Valin, K. Vos, T. Terriberry. September 2012. (Format: TXT, HTML) (Updated by RFC8251) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6716) 6717 kx509 Kerberized Certificate Issuance Protocol in Use in 2012. H. Hotz, R. Allbery. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6717) 6718 Pseudowire Redundancy. P. Muley, M. Aissaoui, M. Bocci. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6718) 6719 The Minimum Rank with Hysteresis Objective Function. O. Gnawali, P. Levis. September 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6719) 6720 The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP). C. Pignataro, R. Asati. August 2012. (Format: TXT, HTML) (Updates RFC5036) (Updated by RFC7552) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6720) 6721 The Atom "deleted-entry" Element. J. Snell. September 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6721) 6722 Publishing the "Tao of the IETF" as a Web Page. P. Hoffman, Ed.. August 2012. (Format: TXT, HTML) (Obsoletes RFC4677) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6722) 6723 Update of the Pseudowire Control-Word Negotiation Mechanism. L. Jin, Ed., R. Key, Ed., S. Delord, T. Nadeau, S. Boutros. September 2012. (Format: TXT, HTML) (Obsoleted by RFC8077) (Updates RFC4447, RFC6073) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6723) 6724 Default Address Selection for Internet Protocol Version 6 (IPv6). D. Thaler, Ed., R. Draves, A. Matsumoto, T. Chown. September 2012. (Format: TXT, HTML) (Obsoletes RFC3484) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6724) 6725 DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates. S. Rose. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6725) 6726 FLUTE - File Delivery over Unidirectional Transport. T. Paila, R. Walsh, M. Luby, V. Roca, R. Lehtonen. November 2012. (Format: TXT, HTML) (Obsoletes RFC3926) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6726) 6727 Definitions of Managed Objects for Packet Sampling. T. Dietz, Ed., B. Claise, J. Quittek. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6727) 6728 Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols. G. Muenz, B. Claise, P. Aitken. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6728) 6729 Indicating Email Handling States in Trace Fields. D. Crocker, M. Kucherawy. September 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6729) 6730 Requirements for IETF Nominations Committee Tools. S. Krishnan, J. Halpern. September 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6730) 6731 Improved Recursive DNS Server Selection for Multi-Interfaced Nodes. T. Savolainen, J. Kato, T. Lemon. December 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6731) 6732 6to4 Provider Managed Tunnels. V. Kuarsingh, Ed., Y. Lee, O. Vautrin. September 2012. (Format: TXT, HTML) (Obsoleted by RFC7526) (Status: HISTORIC) (DOI: 10.17487/RFC6732) 6733 Diameter Base Protocol. V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.. October 2012. (Format: TXT, HTML) (Obsoletes RFC3588, RFC5719) (Updated by RFC7075, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6733) 6734 Diameter Attribute-Value Pairs for Cryptographic Key Transport. G. Zorn, Q. Wu, V. Cakulev. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6734) 6735 Diameter Priority Attribute-Value Pairs. K. Carlberg, Ed., T. Taylor. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6735) 6736 Diameter Network Address and Port Translation Control Application. F. Brockners, S. Bhandari, V. Singh, V. Fajardo. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6736) 6737 The Diameter Capabilities Update Application. K. Jiao, G. Zorn. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6737) 6738 Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers. V. Cakulev, A. Lior, S. Mizikovsky. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6738) 6739 Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol. H. Schulzrinne, H. Tschofenig. October 2012. (Format: TXT, HTML) (Updated by RFC8996) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6739) 6740 Identifier-Locator Network Protocol (ILNP) Architectural Description. RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6740) 6741 Identifier-Locator Network Protocol (ILNP) Engineering Considerations. RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6741) 6742 DNS Resource Records for the Identifier-Locator Network Protocol (ILNP). RJ Atkinson, SN Bhatti, S. Rose. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6742) 6743 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6743) 6744 IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6744) 6745 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6745) 6746 IPv4 Options for the Identifier-Locator Network Protocol (ILNP). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6746) 6747 Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6747) 6748 Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6748) 6749 The OAuth 2.0 Authorization Framework. D. Hardt, Ed.. October 2012. (Format: TXT, HTML) (Obsoletes RFC5849) (Updated by RFC8252, RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6749) 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage. M. Jones, D. Hardt. October 2012. (Format: TXT, HTML) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6750) 6751 Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44). R. Despres, Ed., B. Carpenter, D. Wing, S. Jiang. October 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6751) 6752 Issues with Private IP Addressing in the Internet. A. Kirkham. September 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6752) 6753 A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD). J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6753) 6754 Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect. Y. Cai, L. Wei, H. Ou, V. Arya, S. Jethwani. October 2012. (Format: TXT, HTML) (Updated by RFC8736) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6754) 6755 An IETF URN Sub-Namespace for OAuth. B. Campbell, H. Tschofenig. October 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6755) 6756 Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines. S. Trowbridge, Ed., E. Lear, Ed., G. Fishman, Ed., S. Bradner, Ed.. September 2012. (Format: TXT, HTML) (Obsoletes RFC3356) (Updated by RFC9141) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6756) 6757 Access Network Identifier (ANI) Option for Proxy Mobile IPv6. S. Gundavelli, Ed., J. Korhonen, Ed., M. Grayson, K. Leung, R. Pazhyannur. October 2012. (Format: TXT, HTML) (Updated by RFC7563) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6757) 6758 Tunneling of SMTP Message Transfer Priorities. A. Melnikov, K. Carlberg. October 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6758) 6759 Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX). B. Claise, P. Aitken, N. Ben-Dvora. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6759) 6760 Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP). S. Cheshire, M. Krochmal. February 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6760) 6761 Special-Use Domain Names. S. Cheshire, M. Krochmal. February 2013. (Format: TXT, HTML) (Updates RFC1918, RFC2606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6761) 6762 Multicast DNS. S. Cheshire, M. Krochmal. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6762) 6763 DNS-Based Service Discovery. S. Cheshire, M. Krochmal. February 2013. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6763) 6764 Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV). C. Daboo. February 2013. (Format: TXT, HTML) (Updates RFC4791, RFC6352) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6764) 6765 xDSL Multi-Pair Bonding (G.Bond) MIB. E. Beili, M. Morgenstern. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6765) 6766 xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB. E. Beili. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6766) 6767 Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB. E. Beili, M. Morgenstern. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6767) 6768 ATM-Based xDSL Bonded Interfaces MIB. E. Beili. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6768) 6769 Simple Virtual Aggregation (S-VA). R. Raszuk, J. Heitz, A. Lo, L. Zhang, X. Xu. October 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6769) 6770 Use Cases for Content Delivery Network Interconnection. G. Bertrand, Ed., E. Stephan, T. Burbridge, P. Eardley, K. Ma, G. Watson. November 2012. (Format: TXT, HTML) (Obsoletes RFC3570) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6770) 6771 Considerations for Having a Successful "Bar BOF" Side Meeting. L. Eggert, G. Camarillo. October 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6771) 6772 Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information. H. Schulzrinne, Ed., H. Tschofenig, Ed., J. Cuellar, J. Polk, J. Morris, M. Thomson. January 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6772) 6773 DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal. T. Phelan, G. Fairhurst, C. Perkins. November 2012. (Format: TXT, HTML) (Updates RFC4340, RFC5762) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6773) 6774 Distribution of Diverse BGP Paths. R. Raszuk, Ed., R. Fernando, K. Patel, D. McPherson, K. Kumaki. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6774) 6775 Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). Z. Shelby, Ed., S. Chakrabarti, E. Nordmark, C. Bormann. November 2012. (Format: TXT, HTML) (Updates RFC4944) (Updated by RFC8505, RFC8929, RFC9010) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6775) 6776 Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block. A. Clark, Q. Wu. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6776) 6777 Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks. W. Sun, Ed., G. Zhang, Ed., J. Gao, G. Xie, R. Papneja. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6777) 6778 Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching. R. Sparks. October 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6778) 6779 Definition of Managed Objects for the Neighborhood Discovery Protocol. U. Herberg, R. Cole, I. Chakeres. October 2012. (Format: TXT, HTML) (Obsoleted by RFC7939) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6779) 6780 RSVP ASSOCIATION Object Extensions. L. Berger, F. Le Faucheur, A. Narayanan. October 2012. (Format: TXT, HTML) (Updates RFC2205, RFC3209, RFC3473, RFC4872) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6780) 6781 DNSSEC Operational Practices, Version 2. O. Kolkman, W. Mekking, R. Gieben. December 2012. (Format: TXT, HTML) (Obsoletes RFC4641) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6781) 6782 Wireline Incremental IPv6. V. Kuarsingh, Ed., L. Howard. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6782) 6783 Mailing Lists and Non-ASCII Addresses. J. Levine, R. Gellens. November 2012. (Format: TXT, HTML) (Obsoletes RFC5983) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6783) 6784 Kerberos Options for DHCPv6. S. Sakane, M. Ishiyama. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6784) 6785 Support for Internet Message Access Protocol (IMAP) Events in Sieve. B. Leiba. November 2012. (Format: TXT, HTML) (Updates RFC5228) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6785) 6786 Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs. A. Yegin, R. Cragie. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6786) 6787 Media Resource Control Protocol Version 2 (MRCPv2). D. Burnett, S. Shanmugham. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6787) 6788 The Line-Identification Option. S. Krishnan, A. Kavanagh, B. Varga, S. Ooghe, E. Nordmark. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6788) 6789 Congestion Exposure (ConEx) Concepts and Use Cases. B. Briscoe, Ed., R. Woundy, Ed., A. Cooper, Ed.. December 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6789) 6790 The Use of Entropy Labels in MPLS Forwarding. K. Kompella, J. Drake, S. Amante, W. Henderickx, L. Yong. November 2012. (Format: TXT, HTML) (Updates RFC3031, RFC3107, RFC3209, RFC5036) (Updated by RFC7274, RFC7447, RFC8012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6790) 6791 Stateless Source Address Mapping for ICMPv6 Packets. X. Li, C. Bao, D. Wing, R. Vaithianathan, G. Huston. November 2012. (Format: TXT, HTML) (Updates RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6791) 6792 Guidelines for Use of the RTP Monitoring Framework. Q. Wu, Ed., G. Hunt, P. Arden. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6792) 6793 BGP Support for Four-Octet Autonomous System (AS) Number Space. Q. Vohra, E. Chen. December 2012. (Format: TXT, HTML) (Obsoletes RFC4893) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6793) 6794 A Framework for Session Initiation Protocol (SIP) Session Policies. V. Hilt, G. Camarillo, J. Rosenberg. December 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6794) 6795 A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies. V. Hilt, G. Camarillo. December 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6795) 6796 A User Agent Profile Data Set for Media Policy. V. Hilt, G. Camarillo, J. Rosenberg, D. Worley. December 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6796) 6797 HTTP Strict Transport Security (HSTS). J. Hodges, C. Jackson, A. Barth. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6797) 6798 RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting. A. Clark, Q. Wu. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6798) 6799 Not Issued. 6800 Not Issued. 6801 Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework. U. Kozat, A. Begen. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6801) 6802 Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets. S. Baillargeon, C. Flinta, A. Johnsson. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6802) 6803 Camellia Encryption for Kerberos 5. G. Hudson. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6803) 6804 DISCOVER: Supporting Multicast DNS Queries. B. Manning. November 2012. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6804) 6805 The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS. D. King, Ed., A. Farrel, Ed.. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6805) 6806 Kerberos Principal Name Canonicalization and Cross-Realm Referrals. S. Hartman, Ed., K. Raeburn, L. Zhu. November 2012. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6806) 6807 Population Count Extensions to Protocol Independent Multicast (PIM). D. Farinacci, G. Shepherd, S. Venaas, Y. Cai. December 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6807) 6808 Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track. L. Ciavattone, R. Geib, A. Morton, M. Wieser. December 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6808) 6809 Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP). C. Holmberg, I. Sedlacek, H. Kaplan. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6809) 6810 The Resource Public Key Infrastructure (RPKI) to Router Protocol. R. Bush, R. Austein. January 2013. (Format: TXT, HTML) (Updated by RFC8210) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6810) 6811 BGP Prefix Origin Validation. P. Mohapatra, J. Scudder, D. Ward, R. Bush, R. Austein. January 2013. (Format: TXT, HTML) (Updated by RFC8481, RFC8893) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6811) 6812 Cisco Service-Level Assurance Protocol. M. Chiba, A. Clemm, S. Medley, J. Salowey, S. Thombare, E. Yedavalli. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6812) 6813 The Network Endpoint Assessment (NEA) Asokan Attack Analysis. J. Salowey, S. Hanna. December 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6813) 6814 Formally Deprecating Some IPv4 Options. C. Pignataro, F. Gont. November 2012. (Format: TXT, HTML) (Obsoletes RFC1385, RFC1393, RFC1475, RFC1770) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6814) 6815 Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful. S. Bradner, K. Dubray, J. McQuaid, A. Morton. November 2012. (Format: TXT, HTML) (Updates RFC2544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6815) 6816 Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME. V. Roca, M. Cunche, J. Lacan. December 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6816) 6817 Low Extra Delay Background Transport (LEDBAT). S. Shalunov, G. Hazel, J. Iyengar, M. Kuehlewind. December 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6817) 6818 Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. P. Yee. January 2013. (Format: TXT, HTML) (Updates RFC5280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6818) 6819 OAuth 2.0 Threat Model and Security Considerations. T. Lodderstedt, Ed., M. McGloin, P. Hunt. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6819) 6820 Address Resolution Problems in Large Data Center Networks. T. Narten, M. Karir, I. Foo. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6820) 6821 Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality. E. Marocco, A. Fusco, I. Rimac, V. Gurbani. December 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6821) 6822 IS-IS Multi-Instance. S. Previdi, Ed., L. Ginsberg, M. Shand, A. Roy, D. Ward. December 2012. (Format: TXT, HTML) (Obsoleted by RFC8202) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6822) 6823 Advertising Generic Information in IS-IS. L. Ginsberg, S. Previdi, M. Shand. December 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6823) 6824 TCP Extensions for Multipath Operation with Multiple Addresses. A. Ford, C. Raiciu, M. Handley, O. Bonaventure. January 2013. (Format: TXT, HTML) (Obsoleted by RFC8684) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6824) 6825 Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS. M. Miyazawa, T. Otani, K. Kumaki, T. Nadeau. January 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6825) 6826 Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths. IJ. Wijnands, Ed., T. Eckert, N. Leymann, M. Napierala. January 2013. (Format: TXT, HTML) (Updated by RFC7438) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6826) 6827 Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols. A. Malis, Ed., A. Lindem, Ed., D. Papadimitriou, Ed.. January 2013. (Format: TXT, HTML) (Obsoletes RFC5787) (Updates RFC5786) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6827) 6828 Content Splicing for RTP Sessions. J. Xia. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6828) 6829 Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6. M. Chen, P. Pan, C. Pignataro, R. Asati. January 2013. (Format: TXT, HTML) (Obsoleted by RFC8029) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6829) 6830 The Locator/ID Separation Protocol (LISP). D. Farinacci, V. Fuller, D. Meyer, D. Lewis. January 2013. (Format: TXT, HTML) (Obsoleted by RFC9300, RFC9301) (Updated by RFC8113) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6830) 6831 The Locator/ID Separation Protocol (LISP) for Multicast Environments. D. Farinacci, D. Meyer, J. Zwiebel, S. Venaas. January 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6831) 6832 Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites. D. Lewis, D. Meyer, D. Farinacci, V. Fuller. January 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6832) 6833 Locator/ID Separation Protocol (LISP) Map-Server Interface. V. Fuller, D. Farinacci. January 2013. (Format: TXT, HTML) (Obsoleted by RFC9301) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6833) 6834 Locator/ID Separation Protocol (LISP) Map-Versioning. L. Iannone, D. Saucez, O. Bonaventure. January 2013. (Format: TXT, HTML) (Obsoleted by RFC9302) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6834) 6835 The Locator/ID Separation Protocol Internet Groper (LIG). D. Farinacci, D. Meyer. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6835) 6836 Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT). V. Fuller, D. Farinacci, D. Meyer, D. Lewis. January 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6836) 6837 NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database. E. Lear. January 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6837) 6838 Media Type Specifications and Registration Procedures. N. Freed, J. Klensin, T. Hansen. January 2013. (Format: TXT, HTML) (Obsoletes RFC4288) (Also BCP0013) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6838) 6839 Additional Media Type Structured Syntax Suffixes. T. Hansen, A. Melnikov. January 2013. (Format: TXT, HTML) (Updates RFC3023) (Updated by RFC7303) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6839) 6840 Clarifications and Implementation Notes for DNS Security (DNSSEC). S. Weiler, Ed., D. Blacka, Ed.. February 2013. (Format: TXT, HTML) (Updates RFC4033, RFC4034, RFC4035, RFC5155) (Updated by RFC8749) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6840) 6841 A Framework for DNSSEC Policies and DNSSEC Practice Statements. F. Ljunggren, AM. Eklund Lowinder, T. Okubo. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6841) 6842 Client Identifier Option in DHCP Server Replies. N. Swamy, G. Halwasia, P. Jhingran. January 2013. (Format: TXT, HTML) (Updates RFC2131) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6842) 6843 RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting. A. Clark, K. Gross, Q. Wu. January 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6843) 6844 DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, R. Stradling. January 2013. (Format: TXT, HTML) (Obsoleted by RFC8659) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6844) 6845 OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type. N. Sheth, L. Wang, J. Zhang. January 2013. (Format: TXT, HTML) (Updates RFC2328, RFC5340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6845) 6846 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP). G. Pelletier, K. Sandlund, L-E. Jonsson, M. West. January 2013. (Format: TXT, HTML) (Obsoletes RFC4996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6846) 6847 Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL). D. Melman, T. Mizrahi, D. Eastlake 3rd. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6847) 6848 Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO). J. Winterbottom, M. Thomson, R. Barnes, B. Rosen, R. George. January 2013. (Format: TXT, HTML) (Updates RFC4776, RFC5222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6848) 6849 An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback. H. Kaplan, Ed., K. Hedayat, N. Venna, P. Jones, N. Stratton. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6849) 6850 Definitions of Managed Objects for Routing Bridges (RBridges). A. Rijhsinghani, K. Zebrose. January 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6850) 6851 Internet Message Access Protocol (IMAP) - MOVE Extension. A. Gulbrandsen, N. Freed, Ed.. January 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6851) 6852 Affirmation of the Modern Paradigm for Standards. R. Housley, S. Mills, J. Jaffe, B. Aboba, L. St.Amour. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6852) 6853 DHCPv6 Redundancy Deployment Considerations. J. Brzozowski, J. Tremblay, J. Chen, T. Mrugalski. February 2013. (Format: TXT, HTML) (Also BCP0180) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6853) 6854 Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields. B. Leiba. March 2013. (Format: TXT, HTML) (Updates RFC5322) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6854) 6855 IMAP Support for UTF-8. P. Resnick, Ed., C. Newman, Ed., S. Shen, Ed.. March 2013. (Format: TXT, HTML) (Obsoletes RFC5738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6855) 6856 Post Office Protocol Version 3 (POP3) Support for UTF-8. R. Gellens, C. Newman, J. Yao, K. Fujiwara. March 2013. (Format: TXT, HTML) (Obsoletes RFC5721) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6856) 6857 Post-Delivery Message Downgrading for Internationalized Email Messages. K. Fujiwara. March 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6857) 6858 Simplified POP and IMAP Downgrading for Internationalized Email. A. Gulbrandsen. March 2013. (Format: TXT, HTML) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6858) 6859 Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership. B. Leiba. January 2013. (Format: TXT, HTML) (Obsoleted by RFC7437) (Updates RFC3777) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6859) 6860 Hiding Transit-Only Networks in OSPF. Y. Yang, A. Retana, A. Roy. January 2013. (Format: TXT, HTML) (Updates RFC2328, RFC5340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6860) 6861 The "create-form" and "edit-form" Link Relations. I. Dzmanashvili. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6861) 6862 Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements. G. Lebovitz, M. Bhatia, B. Weis. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6862) 6863 Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide. S. Hartman, D. Zhang. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6863) 6864 Updated Specification of the IPv4 ID Field. J. Touch. February 2013. (Format: TXT, HTML) (Updates RFC0791, RFC1122, RFC2003) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6864) 6865 Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME. V. Roca, M. Cunche, J. Lacan, A. Bouabdallah, K. Matsuzono. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6865) 6866 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks. B. Carpenter, S. Jiang. February 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6866) 6867 An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP). Y. Nir, Q. Wu. January 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6867) 6868 Parameter Value Encoding in iCalendar and vCard. C. Daboo. February 2013. (Format: TXT, HTML) (Updates RFC5545, RFC6321, RFC6350, RFC6351) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6868) 6869 vCard KIND:device. G. Salgueiro, J. Clarke, P. Saint-Andre. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6869) 6870 Pseudowire Preferential Forwarding Status Bit. P. Muley, Ed., M. Aissaoui, Ed.. February 2013. (Format: TXT, HTML) (Updates RFC4447) (Updated by RFC7771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6870) 6871 Session Description Protocol (SDP) Media Capabilities Negotiation. R. Gilman, R. Even, F. Andreasen. February 2013. (Format: TXT, HTML) (Updates RFC5939) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6871) 6872 The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model. V. Gurbani, Ed., E. Burger, Ed., T. Anjali, H. Abdelnur, O. Festor. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6872) 6873 Format for the Session Initiation Protocol (SIP) Common Log Format (CLF). G. Salgueiro, V. Gurbani, A. B. Roach. February 2013. (Format: TXT, HTML) (Updated by RFC7355) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6873) 6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers. B. Carpenter, S. Cheshire, R. Hinden. February 2013. (Format: TXT, HTML) (Updates RFC3986) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6874) 6875 The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan. S. Kamei, T. Momose, T. Inoue, T. Nishitani. February 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6875) 6876 A Posture Transport Protocol over TLS (PT-TLS). P. Sangster, N. Cam-Winget, J. Salowey. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6876) 6877 464XLAT: Combination of Stateful and Stateless Translation. M. Mawatari, M. Kawashima, C. Byrne. April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6877) 6878 IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field. A.B. Roach. March 2013. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6878) 6879 IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods. S. Jiang, B. Liu, B. Carpenter. February 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6879) 6880 An Information Model for Kerberos Version 5. L. Johansson. March 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6880) 6881 Best Current Practice for Communications Services in Support of Emergency Calling. B. Rosen, J. Polk. March 2013. (Format: TXT, HTML) (Updated by RFC7840, RFC7852) (Also BCP0181) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6881) 6882 Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs). K. Kumaki, Ed., T. Murai, D. Cheng, S. Matsushima, P. Jiang. March 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6882) 6883 IPv6 Guidance for Internet Content Providers and Application Service Providers. B. Carpenter, S. Jiang. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6883) 6884 RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Z. Fang. March 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6884) 6885 Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS). M. Blanchet, A. Sullivan. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6885) 6886 NAT Port Mapping Protocol (NAT-PMP). S. Cheshire, M. Krochmal. April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6886) 6887 Port Control Protocol (PCP). D. Wing, Ed., S. Cheshire, M. Boucadair, R. Penno, P. Selkirk. April 2013. (Format: TXT, HTML) (Updated by RFC7488, RFC7652, RFC7843) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6887) 6888 Common Requirements for Carrier-Grade NATs (CGNs). S. Perreault, Ed., I. Yamagata, S. Miyakawa, A. Nakagawa, H. Ashida. April 2013. (Format: TXT, HTML) (Updates RFC4787) (Also BCP0127) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6888) 6889 Analysis of Stateful 64 Translation. R. Penno, T. Saxena, M. Boucadair, S. Sivakumar. April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6889) 6890 Special-Purpose IP Address Registries. M. Cotton, L. Vegoda, R. Bonica, Ed., B. Haberman. April 2013. (Format: TXT, HTML) (Obsoletes RFC4773, RFC5156, RFC5735, RFC5736) (Updated by RFC8190) (Also BCP0153) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6890) 6891 Extension Mechanisms for DNS (EDNS(0)). J. Damas, M. Graff, P. Vixie. April 2013. (Format: TXT, HTML) (Obsoletes RFC2671, RFC2673) (Also STD0075) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6891) 6892 The 'describes' Link Relation Type. E. Wilde. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6892) 6893 A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF). P. Higgs, P. Szucs. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6893) 6894 Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection. R. Papneja, S. Vapiwala, J. Karthik, S. Poretsky, S. Rao, JL. Le Roux. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6894) 6895 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd. April 2013. (Format: TXT, HTML) (Obsoletes RFC6195) (Updates RFC1183, RFC2845, RFC2930, RFC3597) (Also BCP0042) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6895) 6896 SCS: KoanLogic's Secure Cookie Sessions for HTTP. S. Barbato, S. Dorigotti, T. Fossati, Ed.. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6896) 6897 Multipath TCP (MPTCP) Application Interface Considerations. M. Scharf, A. Ford. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6897) 6898 Link Management Protocol Behavior Negotiation and Configuration Modifications. D. Li, D. Ceccarelli, L. Berger. March 2013. (Format: TXT, HTML) (Updates RFC4204, RFC4207, RFC4209, RFC5818) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6898) 6899 Not Issued. 6900 Not Issued. 6901 JavaScript Object Notation (JSON) Pointer. P. Bryan, Ed., K. Zyp, M. Nottingham, Ed.. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6901) 6902 JavaScript Object Notation (JSON) Patch. P. Bryan, Ed., M. Nottingham, Ed.. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6902) 6903 Additional Link Relation Types. J. Snell. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6903) 6904 Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP). J. Lennox. April 2013. (Format: TXT, HTML) (Updates RFC3711) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6904) 6905 Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL). T. Senevirathne, D. Bond, S. Aldrin, Y. Li, R. Watve. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6905) 6906 The 'profile' Link Relation Type. E. Wilde. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6906) 6907 Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties. T. Manderson, K. Sriram, R. White. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6907) 6908 Deployment Considerations for Dual-Stack Lite. Y. Lee, R. Maglione, C. Williams, C. Jacquenet, M. Boucadair. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6908) 6909 IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6. S. Gundavelli, Ed., X. Zhou, J. Korhonen, G. Feige, R. Koodli. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6909) 6910 Completion of Calls for the Session Initiation Protocol (SIP). D. Worley, M. Huelsemann, R. Jesske, D. Alexeitsev. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6910) 6911 RADIUS Attributes for IPv6 Access Networks. W. Dec, Ed., B. Sarikaya, G. Zorn, Ed., D. Miles, B. Lourdelet. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6911) 6912 Principles for Unicode Code Point Inclusion in Labels in the DNS. A. Sullivan, D. Thaler, J. Klensin, O. Kolkman. April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6912) 6913 Indicating Fax over IP Capability in the Session Initiation Protocol (SIP). D. Hanes, G. Salgueiro, K. Fleming. March 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6913) 6914 SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP). J. Rosenberg. April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6914) 6915 Flow Identity Extension for HTTP-Enabled Location Delivery (HELD). R. Bellis. April 2013. (Format: TXT, HTML) (Updates RFC6155) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6915) 6916 Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI). R. Gagliano, S. Kent, S. Turner. April 2013. (Format: TXT, HTML) (Also BCP0182) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6916) 6917 Media Resource Brokering. C. Boulton, L. Miniero, G. Munson. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6917) 6918 Formally Deprecating Some ICMPv4 Message Types. F. Gont, C. Pignataro. April 2013. (Format: TXT, HTML) (Obsoletes RFC1788) (Updates RFC0792, RFC0950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6918) 6919 Further Key Words for Use in RFCs to Indicate Requirement Levels. R. Barnes, S. Kent, E. Rescorla. 1 April 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6919) 6920 Naming Things with Hashes. S. Farrell, D. Kutscher, C. Dannewitz, B. Ohlman, A. Keranen, P. Hallam-Baker. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6920) 6921 Design Considerations for Faster-Than-Light (FTL) Communication. R. Hinden. 1 April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6921) 6922 The application/sql Media Type. Y. Shafranovich. April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6922) 6923 MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions. R. Winter, E. Gray, H. van Helvoort, M. Betts. May 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6923) 6924 Registration of Second-Level URN Namespaces under "ietf". B. Leiba. April 2013. (Format: TXT, HTML) (Updates RFC2648) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6924) 6925 The DHCPv4 Relay Agent Identifier Sub-Option. B. Joshi, R. Desetti, M. Stapp. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6925) 6926 DHCPv4 Bulk Leasequery. K. Kinnear, M. Stapp, R. Desetti, B. Joshi, N. Russell, P. Kurapati, B. Volz. April 2013. (Format: TXT, HTML) (Updated by RFC7724) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6926) 6927 Variants in Second-Level Names Registered in Top-Level Domains. J. Levine, P. Hoffman. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6927) 6928 Increasing TCP's Initial Window. J. Chu, N. Dukkipati, Y. Cheng, M. Mathis. April 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6928) 6929 Remote Authentication Dial In User Service (RADIUS) Protocol Extensions. A. DeKok, A. Lior. April 2013. (Format: TXT, HTML) (Updates RFC2865, RFC3575, RFC6158) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6929) 6930 RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd). D. Guo, S. Jiang, Ed., R. Despres, R. Maglione. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6930) 6931 Additional XML Security Uniform Resource Identifiers (URIs). D. Eastlake 3rd. April 2013. (Format: TXT, HTML) (Obsoletes RFC4051) (Obsoleted by RFC9231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6931) 6932 Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry. D. Harkins, Ed.. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6932) 6933 Entity MIB (Version 4). A. Bierman, D. Romascanu, J. Quittek, M. Chandramouli. May 2013. (Format: TXT, HTML) (Obsoletes RFC4133) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6933) 6934 Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs). N. Bitar, Ed., S. Wadhwa, Ed., T. Haag, H. Li. June 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6934) 6935 IPv6 and UDP Checksums for Tunneled Packets. M. Eubanks, P. Chimento, M. Westerlund. April 2013. (Format: TXT, HTML) (Updates RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6935) 6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums. G. Fairhurst, M. Westerlund. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6936) 6937 Proportional Rate Reduction for TCP. M. Mathis, N. Dukkipati, Y. Cheng. May 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6937) 6938 Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID. J. Scudder. May 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6938) 6939 Client Link-Layer Address Option in DHCPv6. G. Halwasia, S. Bhandari, W. Dec. May 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6939) 6940 REsource LOcation And Discovery (RELOAD) Base Protocol. C. Jennings, B. Lowekamp, Ed., E. Rescorla, S. Baset, H. Schulzrinne. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6940) 6941 MPLS Transport Profile (MPLS-TP) Security Framework. L. Fang, Ed., B. Niven-Jenkins, Ed., S. Mansfield, Ed., R. Graveman, Ed.. April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6941) 6942 Diameter Support for the EAP Re-authentication Protocol (ERP). J. Bournelle, L. Morand, S. Decugis, Q. Wu, G. Zorn. May 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6942) 6943 Issues in Identifier Comparison for Security Purposes. D. Thaler, Ed.. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6943) 6944 Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status. S. Rose. April 2013. (Format: TXT, HTML) (Obsoleted by RFC8624) (Updates RFC2536, RFC2539, RFC3110, RFC4034, RFC4398, RFC5155, RFC5702, RFC5933) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6944) 6945 Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol. R. Bush, B. Wijnen, K. Patel, M. Baer. May 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6945) 6946 Processing of IPv6 "Atomic" Fragments. F. Gont. May 2013. (Format: TXT, HTML) (Updates RFC2460, RFC5722) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6946) 6947 The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute. M. Boucadair, H. Kaplan, R. Gilman, S. Veikkolainen. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6947) 6948 Some Measurements on World IPv6 Day from an End-User Perspective. A. Keranen, J. Arkko. July 2013. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6948) 6949 RFC Series Format Requirements and Future Development. H. Flanagan, N. Brownlee. May 2013. (Format: TXT, HTML) (Updates RFC2223) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6949) 6950 Architectural Considerations on Application Features in the DNS. J. Peterson, O. Kolkman, H. Tschofenig, B. Aboba. October 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6950) 6951 UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication. M. Tuexen, R. Stewart. May 2013. (Format: TXT, HTML) (Updated by RFC8899) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6951) 6952 Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide. M. Jethanandani, K. Patel, L. Zheng. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6952) 6953 Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements. A. Mancuso, Ed., S. Probasco, B. Patil. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6953) 6954 Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2). J. Merkle, M. Lochter. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6954) 6955 Diffie-Hellman Proof-of-Possession Algorithms. J. Schaad, H. Prafullchandra. May 2013. (Format: TXT, HTML) (Obsoletes RFC2875) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6955) 6956 Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library. W. Wang, E. Haleplidis, K. Ogawa, C. Li, J. Halpern. June 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6956) 6957 Duplicate Address Detection Proxy. F. Costa, J-M. Combes, Ed., X. Pougnard, H. Li. June 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6957) 6958 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting. A. Clark, S. Zhang, J. Zhao, Q. Wu, Ed.. May 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6958) 6959 Source Address Validation Improvement (SAVI) Threat Scope. D. McPherson, F. Baker, J. Halpern. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6959) 6960 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. June 2013. (Format: TXT, HTML) (Obsoletes RFC2560, RFC6277) (Updates RFC5912) (Updated by RFC8954) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6960) 6961 The Transport Layer Security (TLS) Multiple Certificate Status Request Extension. Y. Pettersen. June 2013. (Format: TXT, HTML) (Obsoleted by RFC8446) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6961) 6962 Certificate Transparency. B. Laurie, A. Langley, E. Kasper. June 2013. (Format: TXT, HTML) (Obsoleted by RFC9162) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6962) 6963 A Uniform Resource Name (URN) Namespace for Examples. P. Saint-Andre. May 2013. (Format: TXT, HTML) (Also BCP0183) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6963) 6964 Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). F. Templin. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6964) 6965 MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design. L. Fang, Ed., N. Bitar, R. Zhang, M. Daikoku, P. Pan. August 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6965) 6966 Not Issued. 6967 Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments. M. Boucadair, J. Touch, P. Levis, R. Penno. June 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6967) 6968 FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols. V. Roca, B. Adamson. July 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6968) 6969 OSPFv3 Instance ID Registry Update. A. Retana, D. Cheng. July 2013. (Format: TXT, HTML) (Updates RFC5838) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6969) 6970 Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF). M. Boucadair, R. Penno, D. Wing. July 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6970) 6971 Depth-First Forwarding (DFF) in Unreliable Networks. U. Herberg, Ed., A. Cardenas, T. Iwao, M. Dow, S. Cespedes. June 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6971) 6972 Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP). Y. Zhang, N. Zong. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6972) 6973 Privacy Considerations for Internet Protocols. A. Cooper, H. Tschofenig, B. Aboba, J. Peterson, J. Morris, M. Hansen, R. Smith. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6973) 6974 Applicability of MPLS Transport Profile for Ring Topologies. Y. Weingarten, S. Bryant, D. Ceccarelli, D. Caviglia, F. Fondelli, M. Corsi, B. Wu, X. Dai. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6974) 6975 Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC). S. Crocker, S. Rose. July 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6975) 6976 Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach. M. Shand, S. Bryant, S. Previdi, C. Filsfils, P. Francois, O. Bonaventure. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6976) 6977 Triggering DHCPv6 Reconfiguration from Relay Agents. M. Boucadair, X. Pougnard. July 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6977) 6978 A TCP Authentication Option Extension for NAT Traversal. J. Touch. July 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6978) 6979 Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA). T. Pornin. August 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6979) 6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery. F. Gont. August 2013. (Format: TXT, HTML) (Updates RFC3971, RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6980) 6981 A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses. S. Bryant, S. Previdi, M. Shand. August 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6981) 6982 Improving Awareness of Running Code: The Implementation Status Section. Y. Sheffer, A. Farrel. July 2013. (Format: TXT, HTML) (Obsoleted by RFC7942) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6982) 6983 Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI). R. van Brandenburg, O. van Deventer, F. Le Faucheur, K. Leung. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6983) 6984 Interoperability Report for Forwarding and Control Element Separation (ForCES). W. Wang, K. Ogawa, E. Haleplidis, M. Gao, J. Hadi Salim. August 2013. (Format: TXT, HTML) (Updates RFC6053) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6984) 6985 IMIX Genome: Specification of Variable Packet Sizes for Additional Testing. A. Morton. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6985) 6986 GOST R 34.11-2012: Hash Function. V. Dolmatov, Ed., A. Degtyarev. August 2013. (Format: TXT, HTML) (Updates RFC5831) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6986) 6987 OSPF Stub Router Advertisement. A. Retana, L. Nguyen, A. Zinin, R. White, D. McPherson. September 2013. (Format: TXT, HTML) (Obsoletes RFC3137) (Updated by RFC8770) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6987) 6988 Requirements for Energy Management. J. Quittek, Ed., M. Chandramouli, R. Winter, T. Dietz, B. Claise. September 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6988) 6989 Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2). Y. Sheffer, S. Fluhrer. July 2013. (Format: TXT, HTML) (Updates RFC5996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6989) 6990 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting. R. Huang, Q. Wu, H. Asaeda, G. Zorn. August 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6990) 6991 Common YANG Data Types. J. Schoenwaelder, Ed.. July 2013. (Format: TXT, HTML) (Obsoletes RFC6021) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6991) 6992 Routing for IPv4-Embedded IPv6 Packets. D. Cheng, M. Boucadair, A. Retana. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6992) 6993 Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP). P. Saint-Andre. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6993) 6994 Shared Use of Experimental TCP Options. J. Touch. August 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6994) 6995 Not Issued. 6996 Autonomous System (AS) Reservation for Private Use. J. Mitchell. July 2013. (Format: TXT, HTML) (Updates RFC1930) (Also BCP0006) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6996) 6997 Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks. M. Goyal, Ed., E. Baccelli, M. Philipp, A. Brandt, J. Martocci. August 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6997) 6998 A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network. M. Goyal, Ed., E. Baccelli, A. Brandt, J. Martocci. August 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6998) 6999 Not Issued. 7000 Not Issued. 7001 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. September 2013. (Format: TXT, HTML) (Obsoletes RFC5451, RFC6577) (Obsoleted by RFC7601) (Updated by RFC7410) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7001) 7002 RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting. A. Clark, G. Zorn, Q. Wu. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7002) 7003 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting. A. Clark, R. Huang, Q. Wu, Ed.. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7003) 7004 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting. G. Zorn, R. Schott, Q. Wu, Ed., R. Huang. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7004) 7005 RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting. A. Clark, V. Singh, Q. Wu. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7005) 7006 Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP). M. Garcia-Martin, S. Veikkolainen, R. Gilman. September 2013. (Format: TXT, PDF, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7006) 7007 Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP). T. Terriberry. August 2013. (Format: TXT, HTML) (Updates RFC3551) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7007) 7008 A Description of the KCipher-2 Encryption Algorithm. S. Kiyomoto, W. Shin. August 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7008) 7009 OAuth 2.0 Token Revocation. T. Lodderstedt, Ed., S. Dronia, M. Scurtescu. August 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7009) 7010 IPv6 Site Renumbering Gap Analysis. B. Liu, S. Jiang, B. Carpenter, S. Venaas, W. George. September 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7010) 7011 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information. B. Claise, Ed., B. Trammell, Ed., P. Aitken. September 2013. (Format: TXT, HTML) (Obsoletes RFC5101) (Also STD0077) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7011) 7012 Information Model for IP Flow Information Export (IPFIX). B. Claise, Ed., B. Trammell, Ed.. September 2013. (Format: TXT, HTML) (Obsoletes RFC5102) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7012) 7013 Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements. B. Trammell, B. Claise. September 2013. (Format: TXT, HTML) (Also BCP0184) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7013) 7014 Flow Selection Techniques. S. D'Antonio, T. Zseby, C. Henke, L. Peluso. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7014) 7015 Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol. B. Trammell, A. Wagner, B. Claise. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7015) 7016 Adobe's Secure Real-Time Media Flow Protocol. M. Thornburgh. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7016) 7017 IMAP Access to IETF Email List Archives. R. Sparks. August 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7017) 7018 Auto-Discovery VPN Problem Statement and Requirements. V. Manral, S. Hanna. September 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7018) 7019 Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD). J. Buford, M. Kolberg, Ed.. September 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7019) 7020 The Internet Numbers Registry System. R. Housley, J. Curran, G. Huston, D. Conrad. August 2013. (Format: TXT, HTML) (Obsoletes RFC2050) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7020) 7021 Assessing the Impact of Carrier-Grade NAT on Network Applications. C. Donley, Ed., L. Howard, V. Kuarsingh, J. Berg, J. Doshi. September 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7021) 7022 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs). A. Begen, C. Perkins, D. Wing, E. Rescorla. September 2013. (Format: TXT, HTML) (Obsoletes RFC6222) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7022) 7023 MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking. D. Mohan, Ed., N. Bitar, Ed., A. Sajassi, Ed., S. DeLord, P. Niger, R. Qiu. October 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7023) 7024 Virtual Hub-and-Spoke in BGP/MPLS VPNs. H. Jeng, J. Uttaro, L. Jalil, B. Decraene, Y. Rekhter, R. Aggarwal. October 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7024) 7025 Requirements for GMPLS Applications of PCE. T. Otani, K. Ogaki, D. Caviglia, F. Zhang, C. Margaria. September 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7025) 7026 Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel. A. Farrel, S. Bryant. September 2013. (Format: TXT, HTML) (Updates RFC5586) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7026) 7027 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS). J. Merkle, M. Lochter. October 2013. (Format: TXT, HTML) (Updates RFC4492) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7027) 7028 Multicast Mobility Routing Optimizations for Proxy Mobile IPv6. JC. Zuniga, LM. Contreras, CJ. Bernardos, S. Jeon, Y. Kim. September 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7028) 7029 Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding. S. Hartman, M. Wasserman, D. Zhang. October 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7029) 7030 Enrollment over Secure Transport. M. Pritikin, Ed., P. Yee, Ed., D. Harkins, Ed.. October 2013. (Format: TXT, HTML) (Updated by RFC8951, RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7030) 7031 DHCPv6 Failover Requirements. T. Mrugalski, K. Kinnear. September 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7031) 7032 LDP Downstream-on-Demand in Seamless MPLS. T. Beckhaus, Ed., B. Decraene, K. Tiruveedhula, M. Konstantynowicz, Ed., L. Martini. October 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7032) 7033 WebFinger. P. Jones, G. Salgueiro, M. Jones, J. Smarr. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7033) 7034 HTTP Header Field X-Frame-Options. D. Ross, T. Gondrom. October 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7034) 7035 Relative Location Representation. M. Thomson, B. Rosen, D. Stanley, G. Bajko, A. Thomson. October 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7035) 7036 Object Identifier Registry for the Long-Term Archive and Notary Services (LTANS) Working Group. R. Housley. October 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7036) 7037 RADIUS Option for the DHCPv6 Relay Agent. L. Yeh, M. Boucadair. October 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7037) 7038 Use of OSPF-MDR in Single-Hop Broadcast Networks. R. Ogier. October 2013. (Format: TXT, HTML) (Updates RFC5614) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7038) 7039 Source Address Validation Improvement (SAVI) Framework. J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt, Ed.. October 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7039) 7040 Public IPv4-over-IPv6 Access Network. Y. Cui, J. Wu, P. Wu, O. Vautrin, Y. Lee. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7040) 7041 Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging. F. Balus, Ed., A. Sajassi, Ed., N. Bitar, Ed.. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7041) 7042 IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters. D. Eastlake 3rd, J. Abley. October 2013. (Format: TXT, HTML) (Obsoletes RFC5342) (Updates RFC2153) (Also BCP0141) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7042) 7043 Resource Records for EUI-48 and EUI-64 Addresses in the DNS. J. Abley. October 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7043) 7044 An Extension to the Session Initiation Protocol (SIP) for Request History Information. M. Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg. February 2014. (Format: TXT, HTML) (Obsoletes RFC4244) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7044) 7045 Transmission and Processing of IPv6 Extension Headers. B. Carpenter, S. Jiang. December 2013. (Format: TXT, HTML) (Updates RFC2460, RFC2780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7045) 7046 A Common API for Transparent Hybrid Multicast. M. Waehlisch, T. Schmidt, S. Venaas. December 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7046) 7047 The Open vSwitch Database Management Protocol. B. Pfaff, B. Davie, Ed.. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7047) 7048 Neighbor Unreachability Detection Is Too Impatient. E. Nordmark, I. Gashinsky. January 2014. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7048) 7049 Concise Binary Object Representation (CBOR). C. Bormann, P. Hoffman. October 2013. (Format: TXT, HTML) (Obsoleted by RFC8949) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7049) 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis. T. Savolainen, J. Korhonen, D. Wing. November 2013. (Format: TXT, HTML) (Updated by RFC8880) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7050) 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix. J. Korhonen, Ed., T. Savolainen, Ed.. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7051) 7052 Locator/ID Separation Protocol (LISP) MIB. G. Schudel, A. Jain, V. Moreno. October 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7052) 7053 SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol. M. Tuexen, I. Ruengeler, R. Stewart. November 2013. (Format: TXT, HTML) (Obsoleted by RFC9260) (Updates RFC4960) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7053) 7054 Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs). A. Farrel, H. Endo, R. Winter, Y. Koike, M. Paul. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7054) 7055 A GSS-API Mechanism for the Extensible Authentication Protocol. S. Hartman, Ed., J. Howlett. December 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7055) 7056 Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism. S. Hartman, J. Howlett. December 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7056) 7057 Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB). S. Winter, J. Salowey. December 2013. (Format: TXT, HTML) (Updates RFC3748) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7057) 7058 Media Control Channel Framework (CFW) Call Flow Examples. A. Amirante, T. Castaldi, L. Miniero, S P. Romano. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7058) 7059 A Comparison of IPv6-over-IPv4 Tunnel Mechanisms. S. Steffann, I. van Beijnum, R. van Rein. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7059) 7060 Using LDP Multipoint Extensions on Targeted LDP Sessions. M. Napierala, E. Rosen, IJ. Wijnands. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7060) 7061 eXtensible Access Control Markup Language (XACML) XML Media Type. R. Sinnema, E. Wilde. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7061) 7062 Framework for GMPLS and PCE Control of G.709 Optical Transport Networks. F. Zhang, Ed., D. Li, H. Li, S. Belotti, D. Ceccarelli. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7062) 7063 Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments. L. Zheng, J. Zhang, R. Parekh. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7063) 7064 URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol. S. Nandakumar, G. Salgueiro, P. Jones, M. Petit-Huguenin. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7064) 7065 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers. M. Petit-Huguenin, S. Nandakumar, G. Salgueiro, P. Jones. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7065) 7066 IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts. J. Korhonen, Ed., J. Arkko, Ed., T. Savolainen, S. Krishnan. November 2013. (Format: TXT, HTML) (Obsoletes RFC3316) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7066) 7067 Directory Assistance Problem and High-Level Design Proposal. L. Dunbar, D. Eastlake 3rd, R. Perlman, I. Gashinsky. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7067) 7068 Diameter Overload Control Requirements. E. McMurry, B. Campbell. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7068) 7069 DECoupled Application Data Enroute (DECADE). R. Alimi, A. Rahman, D. Kutscher, Y. Yang, H. Song, K. Pentikousis. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7069) 7070 An Architecture for Reputation Reporting. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7070) 7071 A Media Type for Reputation Interchange. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7071) 7072 A Reputation Query Protocol. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7072) 7073 A Reputation Response Set for Email Identifiers. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7073) 7074 Revised Definition of the GMPLS Switching Capability and Type Fields. L. Berger, J. Meuric. November 2013. (Format: TXT, HTML) (Updates RFC3471, RFC4202, RFC4203, RFC5307) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7074) 7075 Realm-Based Redirection In Diameter. T. Tsou, R. Hao, T. Taylor, Ed.. November 2013. (Format: TXT, HTML) (Updates RFC6733) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7075) 7076 P6R's Secure Shell Public Key Subsystem. M. Joseph, J. Susoy. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7076) 7077 Update Notifications for Proxy Mobile IPv6. S. Krishnan, S. Gundavelli, M. Liebsch, H. Yokota, J. Korhonen. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7077) 7078 Distributing Address Selection Policy Using DHCPv6. A. Matsumoto, T. Fujisaki, T. Chown. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7078) 7079 The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results. N. Del Regno, Ed., A. Malis, Ed.. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7079) 7080 Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges. A. Sajassi, S. Salam, N. Bitar, F. Balus. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7080) 7081 CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). E. Ivov, P. Saint-Andre, E. Marocco. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7081) 7082 Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP). R. Shekh-Yusef, M. Barnes. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7082) 7083 Modification to Default Values of SOL_MAX_RT and INF_MAX_RT. R. Droms. November 2013. (Format: TXT, HTML) (Obsoleted by RFC8415) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7083) 7084 Basic Requirements for IPv6 Customer Edge Routers. H. Singh, W. Beebee, C. Donley, B. Stark. November 2013. (Format: TXT, HTML) (Obsoletes RFC6204) (Updated by RFC9096) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7084) 7085 Top-Level Domains That Are Already Dotless. J. Levine, P. Hoffman. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7085) 7086 Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD). A. Keranen, G. Camarillo, J. Maenpaa. January 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7086) 7087 A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations. H. van Helvoort, Ed., L. Andersson, Ed., N. Sprecher, Ed.. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7087) 7088 Session Initiation Protocol Service Example -- Music on Hold. D. Worley. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7088) 7089 HTTP Framework for Time-Based Access to Resource States -- Memento. H. Van de Sompel, M. Nelson, R. Sanderson. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7089) 7090 Public Safety Answering Point (PSAP) Callback. H. Schulzrinne, H. Tschofenig, C. Holmberg, M. Patel. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7090) 7091 GOST R 34.10-2012: Digital Signature Algorithm. V. Dolmatov, Ed., A. Degtyarev. December 2013. (Format: TXT, HTML) (Updates RFC5832) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7091) 7092 A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents. H. Kaplan, V. Pascual. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7092) 7093 Additional Methods for Generating Key Identifiers Values. S. Turner, S. Kent, J. Manger. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7093) 7094 Architectural Considerations of IP Anycast. D. McPherson, D. Oran, D. Thaler, E. Osterweil. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7094) 7095 jCard: The JSON Format for vCard. P. Kewisch. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7095) 7096 Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs). S. Belotti, Ed., P. Grandi, D. Ceccarelli, Ed., D. Caviglia, F. Zhang, D. Li. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7096) 7097 RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets. J. Ott, V. Singh, Ed., I. Curcio. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7097) 7098 Using the IPv6 Flow Label for Load Balancing in Server Farms. B. Carpenter, S. Jiang, W. Tarreau. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7098) 7099 Not Issued. 7100 Retirement of the "Internet Official Protocol Standards" Summary Document. P. Resnick. December 2013. (Format: TXT, HTML) (Obsoletes RFC5000) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7100) 7101 List of Internet Official Protocol Standards: Replaced by a Web Page. S. Ginoza. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7101) 7102 Terms Used in Routing for Low-Power and Lossy Networks. JP. Vasseur. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7102) 7103 Advice for Safe Handling of Malformed Messages. M. Kucherawy, G. Shapiro, N. Freed. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7103) 7104 Duplication Grouping Semantics in the Session Description Protocol. A. Begen, Y. Cai, H. Ou. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7104) 7105 Using Device-Provided Location-Related Measurements in Location Configuration Protocols. M. Thomson, J. Winterbottom. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7105) 7106 A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State. E. Ivov. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7106) 7107 Object Identifier Registry for the S/MIME Mail Security Working Group. R. Housley. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7107) 7108 A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes. J. Abley, T. Manderson. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7108) 7109 Flow Bindings Initiated by Home Agents for Mobile IPv6. H. Yokota, D. Kim, B. Sarikaya, F. Xia. February 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7109) 7110 Return Path Specified Label Switched Path (LSP) Ping. M. Chen, W. Cao, S. Ning, F. Jounay, S. Delord. January 2014. (Format: TXT, HTML) (Updated by RFC7737) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7110) 7111 URI Fragment Identifiers for the text/csv Media Type. M. Hausenblas, E. Wilde, J. Tennison. January 2014. (Format: TXT, HTML) (Updates RFC4180) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7111) 7112 Implications of Oversized IPv6 Header Chains. F. Gont, V. Manral, R. Bonica. January 2014. (Format: TXT, HTML) (Updates RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7112) 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard). F. Gont. February 2014. (Format: TXT, HTML) (Updates RFC6105) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7113) 7114 Creation of a Registry for smime-type Parameter Values. B. Leiba. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7114) 7115 Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI). R. Bush. January 2014. (Format: TXT, HTML) (Also BCP0185) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7115) 7116 Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries. K. Scott, M. Blanchet. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7116) 7117 Multicast in Virtual Private LAN Service (VPLS). R. Aggarwal, Ed., Y. Kamite, L. Fang, Y. Rekhter, C. Kodeboniya. February 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7117) 7118 The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP). I. Baz Castillo, J. Millan Villegas, V. Pascual. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7118) 7119 Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators. B. Claise, A. Kobayashi, B. Trammell. February 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7119) 7120 Early IANA Allocation of Standards Track Code Points. M. Cotton. January 2014. (Format: TXT, HTML) (Obsoletes RFC4020) (Also BCP0100) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7120) 7121 High Availability within a Forwarding and Control Element Separation (ForCES) Network Element. K. Ogawa, W. Wang, E. Haleplidis, J. Hadi Salim. February 2014. (Format: TXT, HTML) (Updates RFC5810) (Updated by RFC7391) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7121) 7122 Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP). H. Kruse, S. Jero, S. Ostermann. March 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7122) 7123 Security Implications of IPv6 on IPv4 Networks. F. Gont, W. Liu. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7123) 7124 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB. E. Beili. February 2014. (Format: TXT, HTML) (Updates RFC5066) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7124) 7125 Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element. B. Trammell, P. Aitken. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7125) 7126 Recommendations on Filtering of IPv4 Packets Containing IPv4 Options. F. Gont, R. Atkinson, C. Pignataro. February 2014. (Format: TXT, HTML) (Also BCP0186) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7126) 7127 Characterization of Proposed Standards. O. Kolkman, S. Bradner, S. Turner. January 2014. (Format: TXT, HTML) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7127) 7128 Resource Public Key Infrastructure (RPKI) Router Implementation Report. R. Bush, R. Austein, K. Patel, H. Gredler, M. Waehlisch. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7128) 7129 Authenticated Denial of Existence in the DNS. R. Gieben, W. Mekking. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7129) 7130 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces. M. Bhatia, Ed., M. Chen, Ed., S. Boutros, Ed., M. Binderberger, Ed., J. Haas, Ed.. February 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7130) 7131 Session Initiation Protocol (SIP) History-Info Header Call Flow Examples. M. Barnes, F. Audet, S. Schubert, H. van Elburg, C. Holmberg. March 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7131) 7132 Threat Model for BGP Path Security. S. Kent, A. Chi. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7132) 7133 Information Elements for Data Link Layer Traffic Measurement. S. Kashima, A. Kobayashi, Ed., P. Aitken. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7133) 7134 The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review". B. Rosen. March 2014. (Format: TXT, HTML) (Updates RFC4412) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7134) 7135 Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications. J. Polk. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7135) 7136 Significance of IPv6 Interface Identifiers. B. Carpenter, S. Jiang. February 2014. (Format: TXT, HTML) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7136) 7137 Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks. A. Retana, S. Ratliff. February 2014. (Format: TXT, HTML) (Updates RFC5820) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7137) 7138 Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks. D. Ceccarelli, Ed., F. Zhang, S. Belotti, R. Rao, J. Drake. March 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7138) 7139 GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks. F. Zhang, Ed., G. Zhang, S. Belotti, D. Ceccarelli, K. Pithewan. March 2014. (Format: TXT, HTML) (Updates RFC4328) (Updated by RFC7892) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7139) 7140 LDP Extensions for Hub and Spoke Multipoint Label Switched Path. L. Jin, F. Jounay, IJ. Wijnands, N. Leymann. March 2014. (Format: TXT, HTML) (Updated by RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7140) 7141 Byte and Packet Congestion Notification. B. Briscoe, J. Manner. February 2014. (Format: TXT, HTML) (Updates RFC2309, RFC2914) (Also BCP0041) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7141) 7142 Reclassification of RFC 1142 to Historic. M. Shand, L. Ginsberg. February 2014. (Format: TXT, HTML) (Obsoletes RFC1142) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7142) 7143 Internet Small Computer System Interface (iSCSI) Protocol (Consolidated). M. Chadalapaka, J. Satran, K. Meth, D. Black. April 2014. (Format: TXT, HTML) (Obsoletes RFC3720, RFC3980, RFC4850, RFC5048) (Updates RFC3721) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7143) 7144 Internet Small Computer System Interface (iSCSI) SCSI Features Update. F. Knight, M. Chadalapaka. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7144) 7145 Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification. M. Ko, A. Nezhinsky. April 2014. (Format: TXT, HTML) (Obsoletes RFC5046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7145) 7146 Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3. D. Black, P. Koning. April 2014. (Format: TXT, HTML) (Updates RFC3720, RFC3723, RFC3821, RFC3822, RFC4018, RFC4172, RFC4173, RFC4174, RFC5040, RFC5041, RFC5042, RFC5043, RFC5044, RFC5045, RFC5046, RFC5047, RFC5048) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7146) 7147 Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI). M. Bakke, P. Venkatesen. April 2014. (Format: TXT, HTML) (Obsoletes RFC4544) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7147) 7148 Prefix Delegation Support for Proxy Mobile IPv6. X. Zhou, J. Korhonen, C. Williams, S. Gundavelli, CJ. Bernardos. March 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7148) 7149 Software-Defined Networking: A Perspective from within a Service Provider Environment. M. Boucadair, C. Jacquenet. March 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7149) 7150 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol. F. Zhang, A. Farrel. March 2014. (Format: TXT, HTML) (Obsoleted by RFC7470) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7150) 7151 File Transfer Protocol HOST Command for Virtual Hosts. P. Hethmon, R. McMurray. March 2014. (Format: TXT, HTML) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7151) 7152 Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN). R. Key, Ed., S. DeLord, F. Jounay, L. Huang, Z. Liu, M. Paul. March 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7152) 7153 IANA Registries for BGP Extended Communities. E. Rosen, Y. Rekhter. March 2014. (Format: TXT, HTML) (Updates RFC4360, RFC5701) (Updated by RFC9184) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7153) 7154 IETF Guidelines for Conduct. S. Moonesamy, Ed.. March 2014. (Format: TXT, HTML) (Obsoletes RFC3184) (Also BCP0054) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7154) 7155 Diameter Network Access Server Application. G. Zorn, Ed.. April 2014. (Format: TXT, HTML) (Obsoletes RFC4005) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7155) 7156 Diameter Support for Proxy Mobile IPv6 Localized Routing. G. Zorn, Q. Wu, J. Korhonen. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7156) 7157 IPv6 Multihoming without Network Address Translation. O. Troan, Ed., D. Miles, S. Matsushima, T. Okimoto, D. Wing. March 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7157) 7158 The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. March 2014. (Format: TXT, HTML) (Obsoleted by RFC7159) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7158) 7159 The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. March 2014. (Format: TXT, HTML) (Obsoletes RFC4627, RFC7158) (Obsoleted by RFC8259) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7159) 7160 Support for Multiple Clock Rates in an RTP Session. M. Petit-Huguenin, G. Zorn, Ed.. April 2014. (Format: TXT, HTML) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7160) 7161 Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL). LM. Contreras, CJ. Bernardos, I. Soto. March 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7161) 7162 IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC). A. Melnikov, D. Cridland. May 2014. (Format: TXT, HTML) (Obsoletes RFC4551, RFC5162) (Updates RFC2683) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7162) 7163 URN for Country-Specific Emergency Services. C. Holmberg, I. Sedlacek. March 2014. (Format: TXT, HTML) (Updates RFC5031) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7163) 7164 RTP and Leap Seconds. K. Gross, R. Brandenburg. March 2014. (Format: TXT, HTML) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7164) 7165 Use Cases and Requirements for JSON Object Signing and Encryption (JOSE). R. Barnes. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7165) 7166 Supporting Authentication Trailer for OSPFv3. M. Bhatia, V. Manral, A. Lindem. March 2014. (Format: TXT, HTML) (Obsoletes RFC6506) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7166) 7167 A Framework for Point-to-Multipoint MPLS in Transport Networks. D. Frost, S. Bryant, M. Bocci, L. Berger. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7167) 7168 The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA). I. Nazar. 1 April 2014. (Format: TXT, HTML) (Updates RFC2324) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7168) 7169 The NSA (No Secrecy Afforded) Certificate Extension. S. Turner. 1 April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7169) 7170 Tunnel Extensible Authentication Protocol (TEAP) Version 1. H. Zhou, N. Cam-Winget, J. Salowey, S. Hanna. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7170) 7171 PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods. N. Cam-Winget, P. Sangster. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7171) 7172 Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling. D. Eastlake 3rd, M. Zhang, P. Agarwal, R. Perlman, D. Dutt. May 2014. (Format: TXT, HTML) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7172) 7173 Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires. L. Yong, D. Eastlake 3rd, S. Aldrin, J. Hudson. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7173) 7174 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework. S. Salam, T. Senevirathne, S. Aldrin, D. Eastlake 3rd. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7174) 7175 Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support. V. Manral, D. Eastlake 3rd, D. Ward, A. Banerjee. May 2014. (Format: TXT, HTML) (Updated by RFC8564) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7175) 7176 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS. D. Eastlake 3rd, T. Senevirathne, A. Ghanwani, D. Dutt, A. Banerjee. May 2014. (Format: TXT, HTML) (Obsoletes RFC6326) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7176) 7177 Transparent Interconnection of Lots of Links (TRILL): Adjacency. D. Eastlake 3rd, R. Perlman, A. Ghanwani, H. Yang, V. Manral. May 2014. (Format: TXT, HTML) (Obsoletes RFC6327) (Updates RFC6325) (Updated by RFC7780, RFC8139, RFC8249, RFC8377, RFC8564) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7177) 7178 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support. D. Eastlake 3rd, V. Manral, Y. Li, S. Aldrin, D. Ward. May 2014. (Format: TXT, HTML) (Updated by RFC7978) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7178) 7179 Transparent Interconnection of Lots of Links (TRILL): Header Extension. D. Eastlake 3rd, A. Ghanwani, V. Manral, Y. Li, C. Bestler. May 2014. (Format: TXT, HTML) (Updates RFC6325) (Updated by RFC7780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7179) 7180 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates. D. Eastlake 3rd, M. Zhang, A. Ghanwani, V. Manral, A. Banerjee. May 2014. (Format: TXT, HTML) (Obsoleted by RFC7780) (Updates RFC6325, RFC6327, RFC6439) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7180) 7181 The Optimized Link State Routing Protocol Version 2. T. Clausen, C. Dearlove, P. Jacquet, U. Herberg. April 2014. (Format: TXT, HTML) (Updated by RFC7183, RFC7187, RFC7188, RFC7466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7181) 7182 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs). U. Herberg, T. Clausen, C. Dearlove. April 2014. (Format: TXT, HTML) (Obsoletes RFC6622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7182) 7183 Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2). U. Herberg, C. Dearlove, T. Clausen. April 2014. (Format: TXT, HTML) (Updates RFC6130, RFC7181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7183) 7184 Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2. U. Herberg, R. Cole, T. Clausen. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7184) 7185 Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale. C. Dearlove, T. Clausen, P. Jacquet. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7185) 7186 Security Threats for the Neighborhood Discovery Protocol (NHDP). J. Yi, U. Herberg, T. Clausen. April 2014. (Format: TXT, HTML) (Updated by RFC7985) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7186) 7187 Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2). C. Dearlove, T. Clausen. April 2014. (Format: TXT, HTML) (Updates RFC7181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7187) 7188 Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs. C. Dearlove, T. Clausen. April 2014. (Format: TXT, HTML) (Updates RFC6130, RFC7181) (Updated by RFC7722) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7188) 7189 Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP). G. Mirsky. March 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7189) 7190 Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP). C. Villamizar. March 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7190) 7191 Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types. R. Housley. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7191) 7192 Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types. S. Turner. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7192) 7193 The application/cms Media Type. S. Turner, R. Housley, J. Schaad. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7193) 7194 Default Port for Internet Relay Chat (IRC) via TLS/SSL. R. Hartmann. August 2014. (Format: TXT, HTML) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7194) 7195 Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN). M. Garcia-Martin, S. Veikkolainen. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7195) 7196 Making Route Flap Damping Usable. C. Pelsser, R. Bush, K. Patel, P. Mohapatra, O. Maennel. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7196) 7197 Duplication Delay Attribute in the Session Description Protocol. A. Begen, Y. Cai, H. Ou. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7197) 7198 Duplicating RTP Streams. A. Begen, C. Perkins. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7198) 7199 Location Configuration Extensions for Policy Management. R. Barnes, M. Thomson, J. Winterbottom, H. Tschofenig. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7199) 7200 A Session Initiation Protocol (SIP) Load-Control Event Package. C. Shen, H. Schulzrinne, A. Koike. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7200) 7201 Options for Securing RTP Sessions. M. Westerlund, C. Perkins. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7201) 7202 Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution. C. Perkins, M. Westerlund. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7202) 7203 An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information. T. Takahashi, K. Landfield, Y. Kadobayashi. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7203) 7204 Requirements for Labeled NFS. T. Haynes. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7204) 7205 Use Cases for Telepresence Multistreams. A. Romanow, S. Botzko, M. Duckworth, R. Even, Ed.. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7205) 7206 Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks. P. Jones, G. Salgueiro, J. Polk, L. Liess, H. Kaplan. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7206) 7207 A Uniform Resource Name (URN) Namespace for Eurosystem Messaging. M. Ortseifen, G. Dickfeld. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7207) 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. S. Kitterman. April 2014. (Format: TXT, HTML) (Obsoletes RFC4408) (Updated by RFC7372, RFC8553, RFC8616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7208) 7209 Requirements for Ethernet VPN (EVPN). A. Sajassi, R. Aggarwal, J. Uttaro, N. Bitar, W. Henderickx, A. Isaac. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7209) 7210 Database of Long-Lived Symmetric Cryptographic Keys. R. Housley, T. Polk, S. Hartman, D. Zhang. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7210) 7211 Operations Model for Router Keying. S. Hartman, D. Zhang. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7211) 7212 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol. D. Frost, S. Bryant, M. Bocci. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7212) 7213 MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing. D. Frost, S. Bryant, M. Bocci. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7213) 7214 Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry. L. Andersson, C. Pignataro. May 2014. (Format: TXT, HTML) (Updates RFC5586, RFC6374, RFC6378, RFC6427, RFC6428) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7214) 7215 Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations. L. Jakab, A. Cabellos-Aparicio, F. Coras, J. Domingo-Pascual, D. Lewis. April 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7215) 7216 Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS. M. Thomson, R. Bellis. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7216) 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC). F. Gont. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7217) 7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE). O. Gudmundsson. April 2014. (Format: TXT, HTML) (Updates RFC6698) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7218) 7219 SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI). M. Bagnulo, A. Garcia-Martinez. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7219) 7220 Description Option for the Port Control Protocol (PCP). M. Boucadair, R. Penno, D. Wing. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7220) 7221 Handling of Internet-Drafts by IETF Working Groups. A. Farrel, D. Crocker, Ed.. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7221) 7222 Quality-of-Service Option for Proxy Mobile IPv6. M. Liebsch, P. Seite, H. Yokota, J. Korhonen, S. Gundavelli. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7222) 7223 A YANG Data Model for Interface Management. M. Bjorklund. May 2014. (Format: TXT, HTML) (Obsoleted by RFC8343) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7223) 7224 IANA Interface Type YANG Module. M. Bjorklund. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7224) 7225 Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP). M. Boucadair. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7225) 7226 Requirements for Advanced Multipath in MPLS Networks. C. Villamizar, Ed., D. McDysan, Ed., S. Ning, A. Malis, L. Yong. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7226) 7227 Guidelines for Creating New DHCPv6 Options. D. Hankins, T. Mrugalski, M. Siodelski, S. Jiang, S. Krishnan. May 2014. (Format: TXT, HTML) (Updates RFC3315) (Also BCP0187) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7227) 7228 Terminology for Constrained-Node Networks. C. Bormann, M. Ersue, A. Keranen. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7228) 7229 Object Identifiers for Test Certificate Policies. R. Housley. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7229) 7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed., J. Reschke, Ed.. June 2014. (Format: TXT, HTML) (Obsoletes RFC2145, RFC2616) (Obsoleted by RFC9110, RFC9112) (Updates RFC2817, RFC2818) (Updated by RFC8615) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7230) 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed., J. Reschke, Ed.. June 2014. (Format: TXT, HTML) (Obsoletes RFC2616) (Obsoleted by RFC9110) (Updates RFC2817) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7231) 7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. R. Fielding, Ed., J. Reschke, Ed.. June 2014. (Format: TXT, HTML) (Obsoletes RFC2616) (Obsoleted by RFC9110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7232) 7233 Hypertext Transfer Protocol (HTTP/1.1): Range Requests. R. Fielding, Ed., Y. Lafon, Ed., J. Reschke, Ed.. June 2014. (Format: TXT, HTML) (Obsoletes RFC2616) (Obsoleted by RFC9110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7233) 7234 Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.. June 2014. (Format: TXT, HTML) (Obsoletes RFC2616) (Obsoleted by RFC9111) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7234) 7235 Hypertext Transfer Protocol (HTTP/1.1): Authentication. R. Fielding, Ed., J. Reschke, Ed.. June 2014. (Format: TXT, HTML) (Obsoletes RFC2616, RFC2617) (Obsoleted by RFC9110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7235) 7236 Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations. J. Reschke. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7236) 7237 Initial Hypertext Transfer Protocol (HTTP) Method Registrations. J. Reschke. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7237) 7238 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. June 2014. (Format: TXT, HTML) (Obsoleted by RFC7538) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7238) 7239 Forwarded HTTP Extension. A. Petersson, M. Nilsson. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7239) 7240 Prefer Header for HTTP. J. Snell. June 2014. (Format: TXT, HTML) (Updated by RFC8144) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7240) 7241 The IEEE 802/IETF Relationship. S. Dawkins, P. Thaler, D. Romascanu, B. Aboba, Ed.. July 2014. (Format: TXT, HTML) (Obsoletes RFC4441) (Updated by RFC9141) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7241) 7242 Delay-Tolerant Networking TCP Convergence-Layer Protocol. M. Demmer, J. Ott, S. Perreault. June 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7242) 7243 RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric. V. Singh, Ed., J. Ott, I. Curcio. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7243) 7244 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting. H. Asaeda, Q. Wu, R. Huang. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7244) 7245 An Architecture for Media Recording Using the Session Initiation Protocol. A. Hutton, Ed., L. Portman, Ed., R. Jain, K. Rehor. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7245) 7246 Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context. IJ. Wijnands, Ed., P. Hitchen, N. Leymann, W. Henderickx, A. Gulko, J. Tantsura. June 2014. (Format: TXT, HTML) (Updated by RFC7438) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7246) 7247 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling. P. Saint-Andre, A. Houri, J. Hildebrand. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7247) 7248 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence. P. Saint-Andre, A. Houri, J. Hildebrand. May 2014. (Format: TXT, HTML) (Obsoleted by RFC8048) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7248) 7249 Internet Numbers Registries. R. Housley. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7249) 7250 Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, S. Weiler, T. Kivinen. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7250) 7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS. D. McGrew, D. Bailey, M. Campagna, R. Dugal. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7251) 7252 The Constrained Application Protocol (CoAP). Z. Shelby, K. Hartke, C. Bormann. June 2014. (Format: TXT, HTML) (Updated by RFC7959, RFC8613, RFC8974, RFC9175) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7252) 7253 The OCB Authenticated-Encryption Algorithm. T. Krovetz, P. Rogaway. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7253) 7254 A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI). M. Montemurro, Ed., A. Allen, D. McDonald, P. Gosden. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7254) 7255 Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID. A. Allen, Ed.. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7255) 7256 Multicast Control Extensions for the Access Node Control Protocol (ANCP). F. Le Faucheur, R. Maglione, T. Taylor. July 2014. (Format: TXT, HTML) (Updates RFC6320) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7256) 7257 Virtual Private LAN Service (VPLS) Management Information Base. T. Nadeau, Ed., A. Kiran Koushik, Ed., R. Mediratta, Ed.. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7257) 7258 Pervasive Monitoring Is an Attack. S. Farrell, H. Tschofenig. May 2014. (Format: TXT, HTML) (Also BCP0188) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7258) 7259 The Jabber-ID Header Field. P. Saint-Andre. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7259) 7260 GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration. A. Takacs, D. Fedyk, J. He. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7260) 7261 Offer/Answer Considerations for G723 Annex A and G729 Annex B. M. Perumal, P. Ravindran. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7261) 7262 Requirements for Telepresence Multistreams. A. Romanow, S. Botzko, M. Barnes. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7262) 7263 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing. N. Zong, X. Jiang, R. Even, Y. Zhang. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7263) 7264 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing. N. Zong, X. Jiang, R. Even, Y. Zhang. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7264) 7265 jCal: The JSON Format for iCalendar. P. Kewisch, C. Daboo, M. Douglass. May 2014. (Format: TXT, HTML) (Updated by RFC7529) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7265) 7266 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting. A. Clark, Q. Wu, R. Schott, G. Zorn. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7266) 7267 Dynamic Placement of Multi-Segment Pseudowires. L. Martini, Ed., M. Bocci, Ed., F. Balus, Ed.. June 2014. (Format: TXT, HTML) (Updates RFC6073) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7267) 7268 RADIUS Attributes for IEEE 802 Networks. B. Aboba, J. Malinen, P. Congdon, J. Salowey, M. Jones. July 2014. (Format: TXT, HTML) (Updates RFC3580, RFC4072) (Updated by RFC8044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7268) 7269 NAT64 Deployment Options and Experience. G. Chen, Z. Cao, C. Xie, D. Binet. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7269) 7270 Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX). A. Yourtchenko, P. Aitken, B. Claise. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7270) 7271 MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators. J. Ryoo, Ed., E. Gray, Ed., H. van Helvoort, A. D'Alessandro, T. Cheung, E. Osborne. June 2014. (Format: TXT, HTML) (Updates RFC6378) (Updated by RFC8234) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7271) 7272 Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP). R. van Brandenburg, H. Stokking, O. van Deventer, F. Boronat, M. Montagud, K. Gross. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7272) 7273 RTP Clock Source Signalling. A. Williams, K. Gross, R. van Brandenburg, H. Stokking. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7273) 7274 Allocating and Retiring Special-Purpose MPLS Labels. K. Kompella, L. Andersson, A. Farrel. June 2014. (Format: TXT, HTML) (Updates RFC3032, RFC3038, RFC3209, RFC3811, RFC4182, RFC4928, RFC5331, RFC5586, RFC5921, RFC5960, RFC6391, RFC6478, RFC6790) (Updated by RFC9017) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7274) 7275 Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy. L. Martini, S. Salam, A. Sajassi, M. Bocci, S. Matsushima, T. Nadeau. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7275) 7276 An Overview of Operations, Administration, and Maintenance (OAM) Tools. T. Mizrahi, N. Sprecher, E. Bellagamba, Y. Weingarten. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7276) 7277 A YANG Data Model for IP Management. M. Bjorklund. June 2014. (Format: TXT, HTML) (Obsoleted by RFC8344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7277) 7278 Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link. C. Byrne, D. Drown, A. Vizdal. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7278) 7279 An Acceptable Use Policy for New ICMP Types and Codes. M. Shore, C. Pignataro. May 2014. (Format: TXT, HTML) (Also BCP0189) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7279) 7280 IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry. G. Fairhurst. June 2014. (Format: TXT, HTML) (Updates RFC4326) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7280) 7281 Authentication-Results Registration for S/MIME Signature Verification. A. Melnikov. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7281) 7282 On Consensus and Humming in the IETF. P. Resnick. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7282) 7283 Handling Unknown DHCPv6 Messages. Y. Cui, Q. Sun, T. Lemon. July 2014. (Format: TXT, HTML) (Obsoleted by RFC8415) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7283) 7284 The Profile URI Registry. M. Lanthaler. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7284) 7285 Application-Layer Traffic Optimization (ALTO) Protocol. R. Alimi, Ed., R. Penno, Ed., Y. Yang, Ed., S. Kiesel, S. Previdi, W. Roome, S. Shalunov, R. Woundy. September 2014. (Format: TXT, HTML) (Updated by RFC9274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7285) 7286 Application-Layer Traffic Optimization (ALTO) Server Discovery. S. Kiesel, M. Stiemerling, N. Schwan, M. Scharf, H. Song. November 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7286) 7287 Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains. T. Schmidt, Ed., S. Gao, H. Zhang, M. Waehlisch. June 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7287) 7288 Reflections on Host Firewalls. D. Thaler. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7288) 7289 Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs. V. Kuarsingh, Ed., J. Cianfarani. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7289) 7290 Test Plan and Results for Advancing RFC 2680 on the Standards Track. L. Ciavattone, R. Geib, A. Morton, M. Wieser. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7290) 7291 DHCP Options for the Port Control Protocol (PCP). M. Boucadair, R. Penno, D. Wing. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7291) 7292 PKCS #12: Personal Information Exchange Syntax v1.1. K. Moriarty, Ed., M. Nystrom, S. Parkinson, A. Rusch, M. Scott. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7292) 7293 The Require-Recipient-Valid-Since Header Field and SMTP Service Extension. W. Mills, M. Kucherawy. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7293) 7294 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications. A. Clark, G. Zorn, C. Bi, Q. Wu. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7294) 7295 Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication. H. Tschofenig, L. Eggert, Z. Sarker. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7295) 7296 Internet Key Exchange Protocol Version 2 (IKEv2). C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen. October 2014. (Format: TXT, HTML) (Obsoletes RFC5996) (Updated by RFC7427, RFC7670, RFC8247, RFC8983) (Also STD0079) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7296) 7297 IP Connectivity Provisioning Profile (CPP). M. Boucadair, C. Jacquenet, N. Wang. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7297) 7298 Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication. D. Ovsienko. July 2014. (Format: TXT, HTML) (Obsoleted by RFC8967) (Updates RFC6126) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7298) 7299 Object Identifier Registry for the PKIX Working Group. R. Housley. July 2014. (Format: TXT, HTML) (Updated by RFC9158) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7299) 7300 Reservation of Last Autonomous System (AS) Numbers. J. Haas, J. Mitchell. July 2014. (Format: TXT, HTML) (Updates RFC1930) (Also BCP0006) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7300) 7301 Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension. S. Friedl, A. Popov, A. Langley, E. Stephan. July 2014. (Format: TXT, HTML) (Updated by RFC8447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7301) 7302 Entertainment Identifier Registry (EIDR) URN Namespace Definition. P. Lemieux. July 2014. (Format: TXT, HTML) (Obsoleted by RFC7972) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7302) 7303 XML Media Types. H. Thompson, C. Lilley. July 2014. (Format: TXT, HTML) (Obsoletes RFC3023) (Updates RFC6839) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7303) 7304 A Method for Mitigating Namespace Collisions. W. Kumari. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7304) 7305 Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT). E. Lear, Ed.. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7305) 7306 Remote Direct Memory Access (RDMA) Protocol Extensions. H. Shah, F. Marti, W. Noureddine, A. Eiriksson, R. Sharp. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7306) 7307 LDP Extensions for Multi-Topology. Q. Zhao, K. Raza, C. Zhou, L. Fang, L. Li, D. King. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7307) 7308 Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE). E. Osborne. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7308) 7309 Redundancy Mechanism for Inter-domain VPLS Service. Z. Liu, L. Jin, R. Chen, D. Cai, S. Salam. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7309) 7310 RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs. J. Lindsay, H. Foerster. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7310) 7311 The Accumulated IGP Metric Attribute for BGP. P. Mohapatra, R. Fernando, E. Rosen, J. Uttaro. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7311) 7312 Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM). J. Fabini, A. Morton. August 2014. (Format: TXT, HTML) (Updates RFC2330) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7312) 7313 Enhanced Route Refresh Capability for BGP-4. K. Patel, E. Chen, B. Venkatachalapathy. July 2014. (Format: TXT, HTML) (Updates RFC2918) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7313) 7314 Extension Mechanisms for DNS (EDNS) EXPIRE Option. M. Andrews. July 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7314) 7315 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP. R. Jesske, K. Drage, C. Holmberg. July 2014. (Format: TXT, HTML) (Obsoletes RFC3455) (Updated by RFC7913, RFC7976) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7315) 7316 The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header). J. van Elburg, K. Drage, M. Ohsugi, S. Schubert, K. Arai. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7316) 7317 A YANG Data Model for System Management. A. Bierman, M. Bjorklund. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7317) 7318 Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates. A. Newton, G. Huston. July 2014. (Format: TXT, HTML) (Updates RFC6487) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7318) 7319 IANA Considerations for Connectivity Fault Management (CFM) Code Points. D. Eastlake 3rd. July 2014. (Format: TXT, HTML) (Also BCP0191) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7319) 7320 URI Design and Ownership. M. Nottingham. July 2014. (Format: TXT, HTML) (Obsoleted by RFC8820) (Updates RFC3986) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7320) 7321 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH). D. McGrew, P. Hoffman. August 2014. (Format: TXT, HTML) (Obsoletes RFC4835) (Obsoleted by RFC8221) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7321) 7322 RFC Style Guide. H. Flanagan, S. Ginoza. September 2014. (Format: TXT, HTML) (Obsoletes RFC2223) (Updated by RFC7997) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7322) 7323 TCP Extensions for High Performance. D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, Ed.. September 2014. (Format: TXT, HTML) (Obsoletes RFC1323) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7323) 7324 Updates to MPLS Transport Profile Linear Protection. E. Osborne. July 2014. (Format: TXT, HTML) (Updates RFC6378) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7324) 7325 MPLS Forwarding Compliance and Performance Requirements. C. Villamizar, Ed., K. Kompella, S. Amante, A. Malis, C. Pignataro. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7325) 7326 Energy Management Framework. J. Parello, B. Claise, B. Schoening, J. Quittek. September 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7326) 7327 Not Issued. 7328 Writing I-Ds and RFCs Using Pandoc and a Bit of XML. R. Gieben. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7328) 7329 A Session Identifier for the Session Initiation Protocol (SIP). H. Kaplan. August 2014. (Format: TXT, HTML) (Obsoleted by RFC7989) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7329) 7330 Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management. T. Nadeau, Z. Ali, N. Akiya. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7330) 7331 Bidirectional Forwarding Detection (BFD) Management Information Base. T. Nadeau, Z. Ali, N. Akiya. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7331) 7332 Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs). H. Kaplan, V. Pascual. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7332) 7333 Requirements for Distributed Mobility Management. H. Chan, Ed., D. Liu, P. Seite, H. Yokota, J. Korhonen. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7333) 7334 PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths. Q. Zhao, D. Dhody, D. King, Z. Ali, R. Casellas. August 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7334) 7335 IPv4 Service Continuity Prefix. C. Byrne. August 2014. (Format: TXT, HTML) (Updates RFC6333) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7335) 7336 Framework for Content Distribution Network Interconnection (CDNI). L. Peterson, B. Davie, R. van Brandenburg, Ed.. August 2014. (Format: TXT, HTML) (Obsoletes RFC3466) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7336) 7337 Content Distribution Network Interconnection (CDNI) Requirements. K. Leung, Ed., Y. Lee, Ed.. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7337) 7338 Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks. F. Jounay, Ed., Y. Kamite, Ed., G. Heron, M. Bocci. September 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7338) 7339 Session Initiation Protocol (SIP) Overload Control. V. Gurbani, Ed., V. Hilt, H. Schulzrinne. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7339) 7340 Secure Telephone Identity Problem Statement and Requirements. J. Peterson, H. Schulzrinne, H. Tschofenig. September 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7340) 7341 DHCPv4-over-DHCPv6 (DHCP 4o6) Transport. Q. Sun, Y. Cui, M. Siodelski, S. Krishnan, I. Farrer. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7341) 7342 Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers. L. Dunbar, W. Kumari, I. Gashinsky. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7342) 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2). J. Laganier, F. Dupont. September 2014. (Format: TXT, HTML) (Obsoletes RFC4843) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7343) 7344 Automating DNSSEC Delegation Trust Maintenance. W. Kumari, O. Gudmundsson, G. Barwood. September 2014. (Format: TXT, HTML) (Updated by RFC8078) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7344) 7345 UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS). C. Holmberg, I. Sedlacek, G. Salgueiro. August 2014. (Format: TXT, HTML) (Updated by RFC8842) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7345) 7346 IPv6 Multicast Address Scopes. R. Droms. August 2014. (Format: TXT, HTML) (Updates RFC4007, RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7346) 7347 Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP). H. van Helvoort, Ed., J. Ryoo, Ed., H. Zhang, F. Huang, H. Li, A. D'Alessandro. September 2014. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7347) 7348 Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks. M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7348) 7349 LDP Hello Cryptographic Authentication. L. Zheng, M. Chen, M. Bhatia. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7349) 7350 Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN). M. Petit-Huguenin, G. Salgueiro. August 2014. (Format: TXT, HTML) (Updates RFC5389, RFC5928) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7350) 7351 A Media Type for XML Patch Operations. E. Wilde. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7351) 7352 Sieve Email Filtering: Detecting Duplicate Deliveries. S. Bosch. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7352) 7353 Security Requirements for BGP Path Validation. S. Bellovin, R. Bush, D. Ward. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7353) 7354 Update to the Registrant Information for the Digital Video Broadcasting Project (DVB) Uniform Resource Name (URN) Namespace. A. Adolf, P. Siebert. September 2014. (Format: TXT, HTML) (Updates RFC5328) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7354) 7355 Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF). G. Salgueiro, V. Pascual, A. Roman, S. Garcia. September 2014. (Format: TXT, HTML) (Updates RFC6873) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7355) 7356 IS-IS Flooding Scope Link State PDUs (LSPs). L. Ginsberg, S. Previdi, Y. Yang. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7356) 7357 Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol. H. Zhai, F. Hu, R. Perlman, D. Eastlake 3rd, O. Stokes. September 2014. (Format: TXT, HTML) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7357) 7358 Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs). K. Raza, S. Boutros, L. Martini, N. Leymann. October 2014. (Format: TXT, HTML) (Updates RFC3212, RFC4447, RFC5036, RFC5918, RFC6388, RFC7140) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7358) 7359 Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks. F. Gont. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7359) 7360 Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS. A. DeKok. September 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7360) 7361 LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS). P. Dutta, F. Balus, O. Stokes, G. Calvignac, D. Fedyk. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7361) 7362 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication. E. Ivov, H. Kaplan, D. Wing. September 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7362) 7363 Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD). J. Maenpaa, G. Camarillo. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7363) 7364 Problem Statement: Overlays for Network Virtualization. T. Narten, Ed., E. Gray, Ed., D. Black, L. Fang, L. Kreeger, M. Napierala. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7364) 7365 Framework for Data Center (DC) Network Virtualization. M. Lasserre, F. Balus, T. Morin, N. Bitar, Y. Rekhter. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7365) 7366 Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). P. Gutmann. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7366) 7367 Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process. R. Cole, J. Macker, B. Adamson. October 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7367) 7368 IPv6 Home Networking Architecture Principles. T. Chown, Ed., J. Arkko, A. Brandt, O. Troan, J. Weil. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7368) 7369 GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration. A. Takacs, B. Gero, H. Long. October 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7369) 7370 Updates to the IS-IS TLV Codepoints Registry. L. Ginsberg. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7370) 7371 Updates to the IPv6 Multicast Addressing Architecture. M. Boucadair, S. Venaas. September 2014. (Format: TXT, HTML) (Updates RFC3306, RFC3956, RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7371) 7372 Email Authentication Status Codes. M. Kucherawy. September 2014. (Format: TXT, HTML) (Updates RFC7208) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7372) 7373 Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types. B. Trammell. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7373) 7374 Service Discovery Usage for REsource LOcation And Discovery (RELOAD). J. Maenpaa, G. Camarillo. October 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7374) 7375 Secure Telephone Identity Threat Model. J. Peterson. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7375) 7376 Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN). T. Reddy, R. Ravindranath, M. Perumal, A. Yegin. September 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7376) 7377 IMAP4 Multimailbox SEARCH Extension. B. Leiba, A. Melnikov. October 2014. (Format: TXT, HTML) (Obsoletes RFC6237) (Updates RFC4466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7377) 7378 Trustworthy Location. H. Tschofenig, H. Schulzrinne, B. Aboba, Ed.. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7378) 7379 Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge. Y. Li, W. Hao, R. Perlman, J. Hudson, H. Zhai. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7379) 7380 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting. J. Tong, C. Bi, Ed., R. Even, Q. Wu, Ed., R. Huang. November 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7380) 7381 Enterprise IPv6 Deployment Guidelines. K. Chittimaneni, T. Chown, L. Howard, V. Kuarsingh, Y. Pouffary, E. Vyncke. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7381) 7382 Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI). S. Kent, D. Kong, K. Seo. April 2015. (Format: TXT, HTML) (Also BCP0173) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7382) 7383 Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation. V. Smyslov. November 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7383) 7384 Security Requirements of Time Protocols in Packet Switched Networks. T. Mizrahi. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7384) 7385 IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points. L. Andersson, G. Swallow. October 2014. (Format: TXT, HTML) (Updates RFC6514) (Updated by RFC8317, RFC8338) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7385) 7386 JSON Merge Patch. P. Hoffman, J. Snell. October 2014. (Format: TXT, HTML) (Obsoleted by RFC7396) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7386) 7387 A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network. R. Key, Ed., L. Yong, Ed., S. Delord, F. Jounay, L. Jin. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7387) 7388 Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). J. Schoenwaelder, A. Sehgal, T. Tsou, C. Zhou. October 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7388) 7389 Separation of Control and User Plane for Proxy Mobile IPv6. R. Wakikawa, R. Pazhyannur, S. Gundavelli, C. Perkins. October 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7389) 7390 Group Communication for the Constrained Application Protocol (CoAP). A. Rahman, Ed., E. Dijk, Ed.. October 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7390) 7391 Forwarding and Control Element Separation (ForCES) Protocol Extensions. J. Hadi Salim. October 2014. (Format: TXT, HTML) (Updates RFC5810, RFC7121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7391) 7392 Explicit Path Routing for Dynamic Multi-Segment Pseudowires. P. Dutta, M. Bocci, L. Martini. December 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7392) 7393 Using the Port Control Protocol (PCP) to Update Dynamic DNS. X. Deng, M. Boucadair, Q. Zhao, J. Huang, C. Zhou. November 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7393) 7394 Definition of Time to Live TLV for LSP-Ping Mechanisms. S. Boutros, S. Sivabalan, G. Swallow, S. Saxena, V. Manral, S. Aldrin. November 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7394) 7395 An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket. L. Stout, Ed., J. Moffitt, E. Cestari. October 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7395) 7396 JSON Merge Patch. P. Hoffman, J. Snell. October 2014. (Format: TXT, HTML) (Obsoletes RFC7386) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7396) 7397 Report from the Smart Object Security Workshop. J. Gilger, H. Tschofenig. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7397) 7398 A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance. M. Bagnulo, T. Burbridge, S. Crawford, P. Eardley, A. Morton. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7398) 7399 Unanswered Questions in the Path Computation Element Architecture. A. Farrel, D. King. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7399) 7400 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). C. Bormann. November 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7400) 7401 Host Identity Protocol Version 2 (HIPv2). R. Moskowitz, Ed., T. Heer, P. Jokela, T. Henderson. April 2015. (Format: TXT, HTML) (Obsoletes RFC5201) (Updated by RFC8002) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7401) 7402 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP). P. Jokela, R. Moskowitz, J. Melen. April 2015. (Format: TXT, HTML) (Obsoletes RFC5202) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7402) 7403 A Media-Based Traceroute Function for the Session Initiation Protocol (SIP). H. Kaplan. November 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7403) 7404 Using Only Link-Local Addressing inside an IPv6 Network. M. Behringer, E. Vyncke. November 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7404) 7405 Case-Sensitive String Support in ABNF. P. Kyzivat. December 2014. (Format: TXT, HTML) (Updates RFC5234) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7405) 7406 Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices. H. Schulzrinne, S. McCann, G. Bajko, H. Tschofenig, D. Kroeselberg. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7406) 7407 A YANG Data Model for SNMP Configuration. M. Bjorklund, J. Schoenwaelder. December 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7407) 7408 Forwarding and Control Element Separation (ForCES) Model Extension. E. Haleplidis. November 2014. (Format: TXT, HTML) (Updates RFC5812) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7408) 7409 Forwarding and Control Element Separation (ForCES) Packet Parallelization. E. Haleplidis, J. Halpern. November 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7409) 7410 A Property Types Registry for the Authentication-Results Header Field. M. Kucherawy. December 2014. (Format: TXT, HTML) (Obsoleted by RFC7601) (Updates RFC7001) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7410) 7411 Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers. T. Schmidt, Ed., M. Waehlisch, R. Koodli, G. Fairhurst, D. Liu. November 2014. (Format: TXT, HTML) (Updates RFC5568) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7411) 7412 Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection. Y. Weingarten, S. Aldrin, P. Pan, J. Ryoo, G. Mirsky. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7412) 7413 TCP Fast Open. Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain. December 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7413) 7414 A Roadmap for Transmission Control Protocol (TCP) Specification Documents. M. Duke, R. Braden, W. Eddy, E. Blanton, A. Zimmermann. February 2015. (Format: TXT, HTML) (Obsoletes RFC4614) (Updated by RFC7805) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7414) 7415 Session Initiation Protocol (SIP) Rate Control. E. Noel, P. Williams. February 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7415) 7416 A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs). T. Tsao, R. Alexander, M. Dohler, V. Daza, A. Lozano, M. Richardson, Ed.. January 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7416) 7417 Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains. G. Karagiannis, A. Bhargava. December 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7417) 7418 An IRTF Primer for IETF Participants. S. Dawkins, Ed.. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7418) 7419 Common Interval Support in Bidirectional Forwarding Detection. N. Akiya, M. Binderberger, G. Mirsky. December 2014. (Format: TXT, HTML) (Updates RFC5880) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7419) 7420 Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module. A. Koushik, E. Stephan, Q. Zhao, D. King, J. Hardwick. December 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7420) 7421 Analysis of the 64-bit Boundary in IPv6 Addressing. B. Carpenter, Ed., T. Chown, F. Gont, S. Jiang, A. Petrescu, A. Yourtchenko. January 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7421) 7422 Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments. C. Donley, C. Grundemann, V. Sarawat, K. Sundaresan, O. Vautrin. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7422) 7423 Diameter Applications Design Guidelines. L. Morand, Ed., V. Fajardo, H. Tschofenig. November 2014. (Format: TXT, HTML) (Also BCP0193) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7423) 7424 Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks. R. Krishnan, L. Yong, A. Ghanwani, N. So, B. Khasnabish. January 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7424) 7425 Adobe's RTMFP Profile for Flash Communication. M. Thornburgh. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7425) 7426 Software-Defined Networking (SDN): Layers and Architecture Terminology. E. Haleplidis, Ed., K. Pentikousis, Ed., S. Denazis, J. Hadi Salim, D. Meyer, O. Koufopavlou. January 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7426) 7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2). T. Kivinen, J. Snyder. January 2015. (Format: TXT, HTML) (Updates RFC7296) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7427) 7428 Transmission of IPv6 Packets over ITU-T G.9959 Networks. A. Brandt, J. Buron. February 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7428) 7429 Distributed Mobility Management: Current Practices and Gap Analysis. D. Liu, Ed., JC. Zuniga, Ed., P. Seite, H. Chan, CJ. Bernardos. January 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7429) 7430 Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP). M. Bagnulo, C. Paasch, F. Gont, O. Bonaventure, C. Raiciu. July 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7430) 7431 Multicast-Only Fast Reroute. A. Karan, C. Filsfils, IJ. Wijnands, Ed., B. Decraene. August 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7431) 7432 BGP MPLS-Based Ethernet VPN. A. Sajassi, Ed., R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. Drake, W. Henderickx. February 2015. (Format: TXT, HTML) (Updated by RFC8584, RFC9161) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7432) 7433 A Mechanism for Transporting User-to-User Call Control Information in SIP. A. Johnston, J. Rafferty. January 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7433) 7434 Interworking ISDN Call Control User Information with SIP. K. Drage, Ed., A. Johnston. January 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7434) 7435 Opportunistic Security: Some Protection Most of the Time. V. Dukhovni. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7435) 7436 IP-Only LAN Service (IPLS). H. Shah, E. Rosen, F. Le Faucheur, G. Heron. January 2015. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC7436) 7437 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. M. Kucherawy, Ed.. January 2015. (Format: TXT, HTML) (Obsoletes RFC3777, RFC5078, RFC5633, RFC5680, RFC6859) (Obsoleted by RFC8713) (Updated by RFC8318) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7437) 7438 Multipoint LDP (mLDP) In-Band Signaling with Wildcards. IJ. Wijnands, Ed., E. Rosen, A. Gulko, U. Joorde, J. Tantsura. January 2015. (Format: TXT, HTML) (Updates RFC6826, RFC7246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7438) 7439 Gap Analysis for Operating IPv6-Only MPLS Networks. W. George, Ed., C. Pignataro, Ed.. January 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7439) 7440 TFTP Windowsize Option. P. Masotta. January 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7440) 7441 Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes. IJ. Wijnands, E. Rosen, U. Joorde. January 2015. (Format: TXT, HTML) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7441) 7442 Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP). Y. Rekhter, R. Aggarwal, N. Leymann, W. Henderickx, Q. Zhao, R. Li. February 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7442) 7443 Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages. P. Patil, T. Reddy, G. Salgueiro, M. Petit-Huguenin. January 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7443) 7444 Security Labels in Internet Email. K. Zeilenga, A. Melnikov. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7444) 7445 Analysis of Failure Cases in IPv6 Roaming Scenarios. G. Chen, H. Deng, D. Michaud, J. Korhonen, M. Boucadair. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7445) 7446 Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks. Y. Lee, Ed., G. Bernstein, Ed., D. Li, W. Imajuku. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7446) 7447 Deprecation of BGP Entropy Label Capability Attribute. J. Scudder, K. Kompella. February 2015. (Format: TXT, HTML) (Updates RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7447) 7448 MIB Transfer from the IETF to the IEEE 802.3 WG. T. Taylor, Ed., D. Romascanu. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7448) 7449 Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment. Y. Lee, Ed., G. Bernstein, Ed., J. Martensson, T. Takeda, T. Tsuritani, O. Gonzalez de Dios. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7449) 7450 Automatic Multicast Tunneling. G. Bumgardner. February 2015. (Format: TXT, HTML) (Updated by RFC8777) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7450) 7451 Extension Registry for the Extensible Provisioning Protocol. S. Hollenbeck. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7451) 7452 Architectural Considerations in Smart Object Networking. H. Tschofenig, J. Arkko, D. Thaler, D. McPherson. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7452) 7453 MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB). V. Mahalingam, K. Sampath, S. Aldrin, T. Nadeau. February 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7453) 7454 BGP Operations and Security. J. Durand, I. Pepelnjak, G. Doering. February 2015. (Format: TXT, HTML) (Also BCP0194) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7454) 7455 Transparent Interconnection of Lots of Links (TRILL): Fault Management. T. Senevirathne, N. Finn, S. Salam, D. Kumar, D. Eastlake 3rd, S. Aldrin, Y. Li. March 2015. (Format: TXT, HTML) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7455) 7456 Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL). T. Mizrahi, T. Senevirathne, S. Salam, D. Kumar, D. Eastlake 3rd. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7456) 7457 Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS). Y. Sheffer, R. Holz, P. Saint-Andre. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7457) 7458 Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core. R. Valmikam, R. Koodli. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7458) 7459 Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO). M. Thomson, J. Winterbottom. February 2015. (Format: TXT, HTML) (Updates RFC3693, RFC4119, RFC5491) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7459) 7460 Monitoring and Control MIB for Power and Energy. M. Chandramouli, B. Claise, B. Schoening, J. Quittek, T. Dietz. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7460) 7461 Energy Object Context MIB. J. Parello, B. Claise, M. Chandramouli. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7461) 7462 URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP). L. Liess, Ed., R. Jesske, A. Johnston, D. Worley, P. Kyzivat. March 2015. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7462) 7463 Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR). A. Johnston, Ed., M. Soroushnejad, Ed., V. Venkataramanan. March 2015. (Format: TXT, HTML) (Updates RFC3261, RFC4235) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7463) 7464 JavaScript Object Notation (JSON) Text Sequences. N. Williams. February 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7464) 7465 Prohibiting RC4 Cipher Suites. A. Popov. February 2015. (Format: TXT, HTML) (Updates RFC5246, RFC4346, RFC2246) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7465) 7466 An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP). C. Dearlove, T. Clausen. March 2015. (Format: TXT, HTML) (Updates RFC6130, RFC7181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7466) 7467 URN Namespace for the North Atlantic Treaty Organization (NATO). A. Murdock. April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7467) 7468 Textual Encodings of PKIX, PKCS, and CMS Structures. S. Josefsson, S. Leonard. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7468) 7469 Public Key Pinning Extension for HTTP. C. Evans, C. Palmer, R. Sleevi. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7469) 7470 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol. F. Zhang, A. Farrel. March 2015. (Format: TXT, HTML) (Obsoletes RFC7150) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7470) 7471 OSPF Traffic Engineering (TE) Metric Extensions. S. Giacalone, D. Ward, J. Drake, A. Atlas, S. Previdi. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7471) 7472 Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme. I. McDonald, M. Sweet. March 2015. (Format: TXT, HTML) (Updates RFC2910, RFC2911) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7472) 7473 Controlling State Advertisements of Non-negotiated LDP Applications. K. Raza, S. Boutros. March 2015. (Format: TXT, HTML) (Updated by RFC8223) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7473) 7474 Security Extension for OSPFv2 When Using Manual Key Management. M. Bhatia, S. Hartman, D. Zhang, A. Lindem, Ed.. April 2015. (Format: TXT, HTML) (Updates RFC2328, RFC5709) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7474) 7475 Increasing the Number of Area Directors in an IETF Area. S. Dawkins. March 2015. (Format: TXT, HTML) (Updates RFC2026, RFC2418) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7475) 7476 Information-Centric Networking: Baseline Scenarios. K. Pentikousis, Ed., B. Ohlman, D. Corujo, G. Boggia, G. Tyson, E. Davies, A. Molinaro, S. Eum. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7476) 7477 Child-to-Parent Synchronization in DNS. W. Hardaker. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7477) 7478 Web Real-Time Communication Use Cases and Requirements. C. Holmberg, S. Hakansson, G. Eriksson. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7478) 7479 Using Ed25519 in SSHFP Resource Records. S. Moonesamy. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7479) 7480 HTTP Usage in the Registration Data Access Protocol (RDAP). A. Newton, B. Ellacott, N. Kong. March 2015. (Format: TXT, HTML) (Also STD0095) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7480) 7481 Security Services for the Registration Data Access Protocol (RDAP). S. Hollenbeck, N. Kong. March 2015. (Format: TXT, HTML) (Also STD0095) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7481) 7482 Registration Data Access Protocol (RDAP) Query Format. A. Newton, S. Hollenbeck. March 2015. (Format: TXT, HTML) (Obsoleted by RFC9082) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7482) 7483 JSON Responses for the Registration Data Access Protocol (RDAP). A. Newton, S. Hollenbeck. March 2015. (Format: TXT, HTML) (Obsoleted by RFC9083) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7483) 7484 Finding the Authoritative Registration Data (RDAP) Service. M. Blanchet. March 2015. (Format: TXT, HTML) (Obsoleted by RFC9224) (Updated by RFC8521) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7484) 7485 Inventory and Analysis of WHOIS Registration Objects. L. Zhou, N. Kong, S. Shen, S. Sheng, A. Servin. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7485) 7486 HTTP Origin-Bound Authentication (HOBA). S. Farrell, P. Hoffman, M. Thomas. March 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7486) 7487 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE. E. Bellagamba, A. Takacs, G. Mirsky, L. Andersson, P. Skoldstrom, D. Ward. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7487) 7488 Port Control Protocol (PCP) Server Selection. M. Boucadair, R. Penno, D. Wing, P. Patil, T. Reddy. March 2015. (Format: TXT, HTML) (Updates RFC6887) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7488) 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC). M. Kucherawy, Ed., E. Zwicky, Ed.. March 2015. (Format: TXT, HTML) (Updated by RFC8553, RFC8616) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7489) 7490 Remote Loop-Free Alternate (LFA) Fast Reroute (FRR). S. Bryant, C. Filsfils, S. Previdi, M. Shand, N. So. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7490) 7491 A PCE-Based Architecture for Application-Based Network Operations. D. King, A. Farrel. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7491) 7492 Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines. M. Bhatia, D. Zhang, M. Jethanandani. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7492) 7493 The I-JSON Message Format. T. Bray, Ed.. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7493) 7494 IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP). C. Shao, H. Deng, R. Pazhyannur, F. Bari, R. Zhang, S. Matsushima. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7494) 7495 Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF). A. Montville, D. Black. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7495) 7496 Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension. M. Tuexen, R. Seggelmann, R. Stewart, S. Loreto. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7496) 7497 Rate Measurement Test Protocol Problem Statement and Requirements. A. Morton. April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7497) 7498 Problem Statement for Service Function Chaining. P. Quinn, Ed., T. Nadeau, Ed.. April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7498) 7499 Support of Fragmentation of RADIUS Packets. A. Perez-Mendez, Ed., R. Marin-Lopez, F. Pereniguez-Garcia, G. Lopez-Millan, D. Lopez, A. DeKok. April 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7499) 7500 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries. R. Housley, Ed., O. Kolkman, Ed.. April 2015. (Format: TXT, HTML) (Obsoleted by RFC8720) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7500) 7501 Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration. C. Davids, V. Gurbani, S. Poretsky. April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7501) 7502 Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration. C. Davids, V. Gurbani, S. Poretsky. April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7502) 7503 OSPFv3 Autoconfiguration. A. Lindem, J. Arkko. April 2015. (Format: TXT, HTML) (Updates RFC5340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7503) 7504 SMTP 521 and 556 Reply Codes. J. Klensin. June 2015. (Format: TXT, HTML) (Updates RFC1846, RFC5321) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7504) 7505 A "Null MX" No Service Resource Record for Domains That Accept No Mail. J. Levine, M. Delany. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7505) 7506 IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM). K. Raza, N. Akiya, C. Pignataro. April 2015. (Format: TXT, HTML) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7506) 7507 TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks. B. Moeller, A. Langley. April 2015. (Format: TXT, HTML) (Obsoleted by RFC8996) (Updates RFC2246, RFC4346, RFC4347, RFC5246, RFC6347) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7507) 7508 Securing Header Fields with S/MIME. L. Cailleux, C. Bonatti. April 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7508) 7509 RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics. R. Huang, V. Singh. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7509) 7510 Encapsulating MPLS in UDP. X. Xu, N. Sheth, L. Yong, R. Callon, D. Black. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7510) 7511 Scenic Routing for IPv6. M. Wilhelm. 1 April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7511) 7512 The PKCS #11 URI Scheme. J. Pechanec, D. Moffat. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7512) 7513 Source Address Validation Improvement (SAVI) Solution for DHCP. J. Bi, J. Wu, G. Yao, F. Baker. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7513) 7514 Really Explicit Congestion Notification (RECN). M. Luckie. 1 April 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7514) 7515 JSON Web Signature (JWS). M. Jones, J. Bradley, N. Sakimura. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7515) 7516 JSON Web Encryption (JWE). M. Jones, J. Hildebrand. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7516) 7517 JSON Web Key (JWK). M. Jones. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7517) 7518 JSON Web Algorithms (JWA). M. Jones. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7518) 7519 JSON Web Token (JWT). M. Jones, J. Bradley, N. Sakimura. May 2015. (Format: TXT, HTML) (Updated by RFC7797, RFC8725) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7519) 7520 Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE). M. Miller. May 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7520) 7521 Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants. B. Campbell, C. Mortimore, M. Jones, Y. Goland. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7521) 7522 Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants. B. Campbell, C. Mortimore, M. Jones. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7522) 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. M. Jones, B. Campbell, C. Mortimore. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7523) 7524 Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs). Y. Rekhter, E. Rosen, R. Aggarwal, T. Morin, I. Grosclaude, N. Leymann, S. Saad. May 2015. (Format: TXT, HTML) (Updated by RFC8534) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7524) 7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). Y. Sheffer, R. Holz, P. Saint-Andre. May 2015. (Format: TXT, HTML) (Obsoleted by RFC9325) (Updated by RFC8996) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7525) 7526 Deprecating the Anycast Prefix for 6to4 Relay Routers. O. Troan, B. Carpenter, Ed.. May 2015. (Format: TXT, HTML) (Obsoletes RFC3068, RFC6732) (Also BCP0196) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7526) 7527 Enhanced Duplicate Address Detection. R. Asati, H. Singh, W. Beebee, C. Pignataro, E. Dart, W. George. April 2015. (Format: TXT, HTML) (Updates RFC4429, RFC4861, RFC4862) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7527) 7528 A Uniform Resource Name (URN) Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association. P. Higgs, J. Piesing. April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7528) 7529 Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar). C. Daboo, G. Yakushev. May 2015. (Format: TXT, HTML) (Updates RFC5545, RFC6321, RFC7265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7529) 7530 Network File System (NFS) Version 4 Protocol. T. Haynes, Ed., D. Noveck, Ed.. March 2015. (Format: TXT, HTML) (Obsoletes RFC3530) (Updated by RFC7931, RFC8587) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7530) 7531 Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description. T. Haynes, Ed., D. Noveck, Ed.. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7531) 7532 Namespace Database (NSDB) Protocol for Federated File Systems. J. Lentini, R. Tewari, C. Lever, Ed.. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7532) 7533 Administration Protocol for Federated File Systems. J. Lentini, R. Tewari, C. Lever, Ed.. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7533) 7534 AS112 Nameserver Operations. J. Abley, W. Sotomayor. May 2015. (Format: TXT, HTML) (Obsoletes RFC6304) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7534) 7535 AS112 Redirection Using DNAME. J. Abley, B. Dickson, W. Kumari, G. Michaelson. May 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7535) 7536 Large-Scale Broadband Measurement Use Cases. M. Linsner, P. Eardley, T. Burbridge, F. Sorensen. May 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7536) 7537 IANA Registries for LSP Ping Code Points. B. Decraene, N. Akiya, C. Pignataro, L. Andersson, S. Aldrin. May 2015. (Format: TXT, HTML) (Obsoleted by RFC8029) (Updates RFC4379, RFC6424) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7537) 7538 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. April 2015. (Format: TXT, HTML) (Obsoletes RFC7238) (Obsoleted by RFC9110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7538) 7539 ChaCha20 and Poly1305 for IETF Protocols. Y. Nir, A. Langley. May 2015. (Format: TXT, HTML) (Obsoleted by RFC8439) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7539) 7540 Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe, R. Peon, M. Thomson, Ed.. May 2015. (Format: TXT, HTML) (Obsoleted by RFC9113) (Updated by RFC8740) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7540) 7541 HPACK: Header Compression for HTTP/2. R. Peon, H. Ruellan. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7541) 7542 The Network Access Identifier. A. DeKok. May 2015. (Format: TXT, HTML) (Obsoletes RFC4282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7542) 7543 Covering Prefixes Outbound Route Filter for BGP-4. H. Jeng, L. Jalil, R. Bonica, K. Patel, L. Yong. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7543) 7544 Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP). M. Mohali. August 2015. (Format: TXT, HTML) (Obsoletes RFC6044) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7544) 7545 Protocol to Access White-Space (PAWS) Databases. V. Chen, Ed., S. Das, L. Zhu, J. Malyar, P. McCann. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7545) 7546 Structure of the Generic Security Service (GSS) Negotiation Loop. B. Kaduk. May 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7546) 7547 Management of Networks with Constrained Devices: Problem Statement and Requirements. M. Ersue, Ed., D. Romascanu, J. Schoenwaelder, U. Herberg. May 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7547) 7548 Management of Networks with Constrained Devices: Use Cases. M. Ersue, Ed., D. Romascanu, J. Schoenwaelder, A. Sehgal. May 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7548) 7549 3GPP SIP URI Inter-Operator Traffic Leg Parameter. C. Holmberg, J. Holm, R. Jesske, M. Dolly. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7549) 7550 Issues and Recommendations with Multiple Stateful DHCPv6 Options. O. Troan, B. Volz, M. Siodelski. May 2015. (Format: TXT, HTML) (Obsoleted by RFC8415) (Updates RFC3315, RFC3633) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7550) 7551 RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs). F. Zhang, Ed., R. Jing, R. Gandhi, Ed.. May 2015. (Format: TXT, HTML) (Updated by RFC8537) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7551) 7552 Updates to LDP for IPv6. R. Asati, C. Pignataro, K. Raza, V. Manral, R. Papneja. June 2015. (Format: TXT, HTML) (Updates RFC5036, RFC6720) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7552) 7553 The Uniform Resource Identifier (URI) DNS Resource Record. P. Faltstrom, O. Kolkman. June 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7553) 7554 Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement. T. Watteyne, Ed., M. Palattella, L. Grieco. May 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7554) 7555 Proxy MPLS Echo Request. G. Swallow, V. Lim, S. Aldrin. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7555) 7556 Multiple Provisioning Domain Architecture. D. Anipko, Ed.. June 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7556) 7557 Extension Mechanism for the Babel Routing Protocol. J. Chroboczek. May 2015. (Format: TXT, HTML) (Obsoleted by RFC8966) (Updates RFC6126) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7557) 7558 Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions. K. Lynn, S. Cheshire, M. Blanchet, D. Migault. July 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7558) 7559 Packet-Loss Resiliency for Router Solicitations. S. Krishnan, D. Anipko, D. Thaler. May 2015. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7559) 7560 Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback. M. Kuehlewind, Ed., R. Scheffenegger, B. Briscoe. August 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7560) 7561 Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN. J. Kaippallimalil, R. Pazhyannur, P. Yegani. June 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7561) 7562 Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates. D. Thakore. July 2015. (Format: TXT, HTML) (Updated by RFC8996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7562) 7563 Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option. R. Pazhyannur, S. Speicher, S. Gundavelli, J. Korhonen, J. Kaippallimalil. June 2015. (Format: TXT, HTML) (Updates RFC6757) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7563) 7564 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols. P. Saint-Andre, M. Blanchet. May 2015. (Format: TXT, HTML) (Obsoletes RFC3454) (Obsoleted by RFC8264) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7564) 7565 The 'acct' URI Scheme. P. Saint-Andre. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7565) 7566 Enumservice Registration for 'acct' URI. L. Goix, K. Li. June 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7566) 7567 IETF Recommendations Regarding Active Queue Management. F. Baker, Ed., G. Fairhurst, Ed.. July 2015. (Format: TXT, HTML) (Obsoletes RFC2309) (Also BCP0197) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7567) 7568 Deprecating Secure Sockets Layer Version 3.0. R. Barnes, M. Thomson, A. Pironti, A. Langley. June 2015. (Format: TXT, HTML) (Updates RFC5246) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7568) 7569 Registry Specification for Mandatory Access Control (MAC) Security Label Formats. D. Quigley, J. Lu, T. Haynes. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7569) 7570 Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO). C. Margaria, Ed., G. Martinelli, S. Balls, B. Wright. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7570) 7571 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback. J. Dong, M. Chen, Z. Li, D. Ceccarelli. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7571) 7572 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging. P. Saint-Andre, A. Houri, J. Hildebrand. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7572) 7573 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions. P. Saint-Andre, S. Loreto. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7573) 7574 Peer-to-Peer Streaming Peer Protocol (PPSPP). A. Bakker, R. Petrocco, V. Grishchenko. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7574) 7575 Autonomic Networking: Definitions and Design Goals. M. Behringer, M. Pritikin, S. Bjarnason, A. Clemm, B. Carpenter, S. Jiang, L. Ciavaglia. June 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7575) 7576 General Gap Analysis for Autonomic Networking. S. Jiang, B. Carpenter, M. Behringer. June 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7576) 7577 Definition of Managed Objects for Battery Monitoring. J. Quittek, R. Winter, T. Dietz. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7577) 7578 Returning Values from Forms: multipart/form-data. L. Masinter. July 2015. (Format: TXT, HTML) (Obsoletes RFC2388) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7578) 7579 General Network Element Constraint Encoding for GMPLS-Controlled Networks. G. Bernstein, Ed., Y. Lee, Ed., D. Li, W. Imajuku, J. Han. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7579) 7580 OSPF-TE Extensions for General Network Element Constraints. F. Zhang, Y. Lee, J. Han, G. Bernstein, Y. Xu. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7580) 7581 Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks. G. Bernstein, Ed., Y. Lee, Ed., D. Li, W. Imajuku, J. Han. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7581) 7582 Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels. E. Rosen, IJ. Wijnands, Y. Cai, A. Boers. July 2015. (Format: TXT, HTML) (Updates RFC6513, RFC6514, RFC6625) (Updated by RFC8534) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7582) 7583 DNSSEC Key Rollover Timing Considerations. S. Morris, J. Ihren, J. Dickinson, W. Mekking. October 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7583) 7584 Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs). R. Ravindranath, T. Reddy, G. Salgueiro. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7584) 7585 Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI). S. Winter, M. McCauley. October 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7585) 7586 The Scalable Address Resolution Protocol (SARP) for Large Data Centers. Y. Nachum, L. Dunbar, I. Yerushalmi, T. Mizrahi. June 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7586) 7587 RTP Payload Format for the Opus Speech and Audio Codec. J. Spittka, K. Vos, JM. Valin. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7587) 7588 A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem. R. Bonica, C. Pignataro, J. Touch. July 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7588) 7589 Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication. M. Badra, A. Luchuk, J. Schoenwaelder. June 2015. (Format: TXT, HTML) (Obsoletes RFC5539) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7589) 7590 Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre, T. Alkemade. June 2015. (Format: TXT, HTML) (Updates RFC6120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7590) 7591 OAuth 2.0 Dynamic Client Registration Protocol. J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7591) 7592 OAuth 2.0 Dynamic Client Registration Management Protocol. J. Richer, Ed., M. Jones, J. Bradley, M. Machulak. July 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7592) 7593 The eduroam Architecture for Network Roaming. K. Wierenga, S. Winter, T. Wolniewicz. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7593) 7594 A Framework for Large-Scale Measurement of Broadband Performance (LMAP). P. Eardley, A. Morton, M. Bagnulo, T. Burbridge, P. Aitken, A. Akhter. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7594) 7595 Guidelines and Registration Procedures for URI Schemes. D. Thaler, Ed., T. Hansen, T. Hardie. June 2015. (Format: TXT, HTML) (Obsoletes RFC4395) (Updated by RFC8615) (Also BCP0035) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7595) 7596 Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture. Y. Cui, Q. Sun, M. Boucadair, T. Tsou, Y. Lee, I. Farrer. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7596) 7597 Mapping of Address and Port with Encapsulation (MAP-E). O. Troan, Ed., W. Dec, X. Li, C. Bao, S. Matsushima, T. Murakami, T. Taylor, Ed.. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7597) 7598 DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients. T. Mrugalski, O. Troan, I. Farrer, S. Perreault, W. Dec, C. Bao, L. Yeh, X. Deng. July 2015. (Format: TXT, HTML) (Updated by RFC8539) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7598) 7599 Mapping of Address and Port using Translation (MAP-T). X. Li, C. Bao, W. Dec, Ed., O. Troan, S. Matsushima, T. Murakami. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7599) 7600 IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd). R. Despres, S. Jiang, Ed., R. Penno, Y. Lee, G. Chen, M. Chen. July 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7600) 7601 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. August 2015. (Format: TXT, HTML) (Obsoletes RFC7001, RFC7410) (Obsoleted by RFC8601) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7601) 7602 IS-IS Extended Sequence Number TLV. U. Chunduri, W. Lu, A. Tian, N. Shen. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7602) 7603 Energy Management (EMAN) Applicability Statement. B. Schoening, M. Chandramouli, B. Nordman. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7603) 7604 Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP). M. Westerlund, T. Zeng. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7604) 7605 Recommendations on Using Assigned Transport Port Numbers. J. Touch. August 2015. (Format: TXT, HTML) (Also BCP0165) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7605) 7606 Revised Error Handling for BGP UPDATE Messages. E. Chen, Ed., J. Scudder, Ed., P. Mohapatra, K. Patel. August 2015. (Format: TXT, HTML) (Updates RFC1997, RFC4271, RFC4360, RFC4456, RFC4760, RFC5543, RFC5701, RFC6368) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7606) 7607 Codification of AS 0 Processing. W. Kumari, R. Bush, H. Schiller, K. Patel. August 2015. (Format: TXT, HTML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7607) 7608 IPv6 Prefix Length Recommendation for Forwarding. M. Boucadair, A. Petrescu, F. Baker. July 2015. (Format: TXT, HTML) (Also BCP0198) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7608) 7609 IBM's Shared Memory Communications over RDMA (SMC-R) Protocol. M. Fox, C. Kassimis, J. Stevens. August 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7609) 7610 DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers. F. Gont, W. Liu, G. Van de Velde. August 2015. (Format: TXT, HTML) (Also BCP0199) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7610) 7611 BGP ACCEPT_OWN Community Attribute. J. Uttaro, P. Mohapatra, D. Smith, R. Raszuk, J. Scudder. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7611) 7612 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services. P. Fleming, I. McDonald. June 2015. (Format: TXT, HTML) (Obsoletes RFC3712) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7612) 7613 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords. P. Saint-Andre, A. Melnikov. August 2015. (Format: TXT, HTML) (Obsoletes RFC4013) (Obsoleted by RFC8265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7613) 7614 Explicit Subscriptions for the REFER Method. R. Sparks. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7614) 7615 HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields. J. Reschke. September 2015. (Format: TXT, HTML) (Obsoletes RFC2617) (Obsoleted by RFC9110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7615) 7616 HTTP Digest Access Authentication. R. Shekh-Yusef, Ed., D. Ahrens, S. Bremer. September 2015. (Format: TXT, HTML) (Obsoletes RFC2617) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7616) 7617 The 'Basic' HTTP Authentication Scheme. J. Reschke. September 2015. (Format: TXT, HTML) (Obsoletes RFC2617) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7617) 7618 Dynamic Allocation of Shared IPv4 Addresses. Y. Cui, Q. Sun, I. Farrer, Y. Lee, Q. Sun, M. Boucadair. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7618) 7619 The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2). V. Smyslov, P. Wouters. August 2015. (Format: TXT, HTML) (Updates RFC4301) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7619) 7620 Scenarios with Host Identification Complications. M. Boucadair, Ed., B. Chatras, T. Reddy, B. Williams, B. Sarikaya. August 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7620) 7621 A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework. A.B. Roach. August 2015. (Format: TXT, HTML) (Updates RFC6665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7621) 7622 Extensible Messaging and Presence Protocol (XMPP): Address Format. P. Saint-Andre. September 2015. (Format: TXT, HTML) (Obsoletes RFC6122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7622) 7623 Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN). A. Sajassi, Ed., S. Salam, N. Bitar, A. Isaac, W. Henderickx. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7623) 7624 Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement. R. Barnes, B. Schneier, C. Jennings, T. Hardie, B. Trammell, C. Huitema, D. Borkmann. August 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7624) 7625 Architecture of an IP/MPLS Network with Hardened Pipes. J. T. Hao, P. Maheshwari, R. Huang, L. Andersson, M. Chen. August 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7625) 7626 DNS Privacy Considerations. S. Bortzmeyer. August 2015. (Format: TXT, HTML) (Obsoleted by RFC9076) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7626) 7627 Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension. K. Bhargavan, Ed., A. Delignat-Lavaud, A. Pironti, A. Langley, M. Ray. September 2015. (Format: TXT, HTML) (Updates RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7627) 7628 A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth. W. Mills, T. Showalter, H. Tschofenig. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7628) 7629 Flow-Binding Support for Mobile IP. S. Gundavelli, Ed., K. Leung, G. Tsirtsis, A. Petrescu. August 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7629) 7630 HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3. J. Merkle, Ed., M. Lochter. October 2015. (Format: TXT, HTML) (Obsoleted by RFC7860) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7630) 7631 TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format. C. Dearlove, T. Clausen. September 2015. (Format: TXT, HTML) (Updates RFC5444) (Updated by RFC7722) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7631) 7632 Endpoint Security Posture Assessment: Enterprise Use Cases. D. Waltermire, D. Harrington. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7632) 7633 X.509v3 Transport Layer Security (TLS) Feature Extension. P. Hallam-Baker. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7633) 7634 ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec. Y. Nir. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7634) 7635 Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization. T. Reddy, P. Patil, R. Ravindranath, J. Uberti. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7635) 7636 Proof Key for Code Exchange by OAuth Public Clients. N. Sakimura, Ed., J. Bradley, N. Agarwal. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7636) 7637 NVGRE: Network Virtualization Using Generic Routing Encapsulation. P. Garg, Ed., Y. Wang, Ed.. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7637) 7638 JSON Web Key (JWK) Thumbprint. M. Jones, N. Sakimura. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7638) 7639 The ALPN HTTP Header Field. A. Hutton, J. Uberti, M. Thomson. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7639) 7640 Traffic Management Benchmarking. B. Constantine, R. Krishnan. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7640) 7641 Observing Resources in the Constrained Application Protocol (CoAP). K. Hartke. September 2015. (Format: TXT, HTML) (Updated by RFC8323) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7641) 7642 System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements. K. LI, Ed., P. Hunt, B. Khasnabish, A. Nadalin, Z. Zeltsan. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7642) 7643 System for Cross-domain Identity Management: Core Schema. P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7643) 7644 System for Cross-domain Identity Management: Protocol. P. Hunt, Ed., K. Grizzle, M. Ansari, E. Wahlstroem, C. Mortimore. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7644) 7645 The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis. U. Chunduri, A. Tian, W. Lu. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7645) 7646 Definition and Use of DNSSEC Negative Trust Anchors. P. Ebersman, W. Kumari, C. Griffiths, J. Livingood, R. Weber. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7646) 7647 Clarifications for the Use of REFER with RFC 6665. R. Sparks, A.B. Roach. September 2015. (Format: TXT, HTML) (Updates RFC3515) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7647) 7648 Port Control Protocol (PCP) Proxy Function. S. Perreault, M. Boucadair, R. Penno, D. Wing, S. Cheshire. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7648) 7649 The Jabber Scribe Role at IETF Meetings. P. Saint-Andre, D. York. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7649) 7650 A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD). J. Jimenez, J. Lopez-Vega, J. Maenpaa, G. Camarillo. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7650) 7651 3GPP IP Multimedia Subsystems (IMS) Option for the Internet Key Exchange Protocol Version 2 (IKEv2). A. Dodd-Noble, S. Gundavelli, J. Korhonen, F. Baboescu, B. Weis. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7651) 7652 Port Control Protocol (PCP) Authentication Mechanism. M. Cullen, S. Hartman, D. Zhang, T. Reddy. September 2015. (Format: TXT, HTML) (Updates RFC6887) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7652) 7653 DHCPv6 Active Leasequery. D. Raghuvanshi, K. Kinnear, D. Kukrety. October 2015. (Format: TXT, HTML) (Updates RFC5460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7653) 7654 Benchmarking Methodology for In-Service Software Upgrade (ISSU). S. Banks, F. Calabria, G. Czirjak, R. Machat. October 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7654) 7655 RTP Payload Format for G.711.0. M. Ramalho, Ed., P. Jones, N. Harada, M. Perumal, L. Miao. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7655) 7656 A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources. J. Lennox, K. Gross, S. Nandakumar, G. Salgueiro, B. Burman, Ed.. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7656) 7657 Differentiated Services (Diffserv) and Real-Time Communication. D. Black, Ed., P. Jones. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7657) 7658 Deprecation of MIB Module NAT-MIB: Managed Objects for Network Address Translators (NATs). S. Perreault, T. Tsou, S. Sivakumar, T. Taylor. October 2015. (Format: TXT, HTML) (Obsoletes RFC4008) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7658) 7659 Definitions of Managed Objects for Network Address Translators (NATs). S. Perreault, T. Tsou, S. Sivakumar, T. Taylor. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7659) 7660 Diameter Congestion and Filter Attributes. L. Bertz, S. Manning, B. Hirschman. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7660) 7661 Updating TCP to Support Rate-Limited Traffic. G. Fairhurst, A. Sathiaseelan, R. Secchi. October 2015. (Format: TXT, HTML) (Obsoletes RFC2861) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7661) 7662 OAuth 2.0 Token Introspection. J. Richer, Ed.. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7662) 7663 Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI). B. Trammell, Ed., M. Kuehlewind, Ed.. October 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7663) 7664 Dragonfly Key Exchange. D. Harkins, Ed.. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7664) 7665 Service Function Chaining (SFC) Architecture. J. Halpern, Ed., C. Pignataro, Ed.. October 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7665) 7666 Management Information Base for Virtual Machines Controlled by a Hypervisor. H. Asai, M. MacFaden, J. Schoenwaelder, K. Shima, T. Tsou. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7666) 7667 RTP Topologies. M. Westerlund, S. Wenger. November 2015. (Format: TXT, HTML) (Obsoletes RFC5117) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7667) 7668 IPv6 over BLUETOOTH(R) Low Energy. J. Nieminen, T. Savolainen, M. Isomaki, B. Patil, Z. Shelby, C. Gomez. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7668) 7669 Assigning Digital Object Identifiers to RFCs. J. Levine. October 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7669) 7670 Generic Raw Public-Key Support for IKEv2. T. Kivinen, P. Wouters, H. Tschofenig. January 2016. (Format: TXT, HTML) (Updates RFC7296) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7670) 7671 The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance. V. Dukhovni, W. Hardaker. October 2015. (Format: TXT, HTML) (Updates RFC6698) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7671) 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS). V. Dukhovni, W. Hardaker. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7672) 7673 Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records. T. Finch, M. Miller, P. Saint-Andre. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7673) 7674 Clarification of the Flowspec Redirect Extended Community. J. Haas, Ed.. October 2015. (Format: TXT, HTML) (Obsoleted by RFC8955) (Updates RFC5575) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7674) 7675 Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness. M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7675) 7676 IPv6 Support for Generic Routing Encapsulation (GRE). C. Pignataro, R. Bonica, S. Krishnan. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7676) 7677 SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms. T. Hansen. November 2015. (Format: TXT, HTML) (Updates RFC5802) (Updated by RFC9266) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7677) 7678 Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions. C. Zhou, T. Taylor, Q. Sun, M. Boucadair. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7678) 7679 A One-Way Delay Metric for IP Performance Metrics (IPPM). G. Almes, S. Kalidindi, M. Zekauskas, A. Morton, Ed.. January 2016. (Format: TXT, HTML) (Obsoletes RFC2679) (Also STD0081) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7679) 7680 A One-Way Loss Metric for IP Performance Metrics (IPPM). G. Almes, S. Kalidindi, M. Zekauskas, A. Morton, Ed.. January 2016. (Format: TXT, HTML) (Obsoletes RFC2680) (Also STD0082) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7680) 7681 Email Exchange of Secondary School Transcripts. J. Davin. October 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7681) 7682 Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration. D. McPherson, S. Amante, E. Osterweil, L. Blunk, D. Mitchell. December 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7682) 7683 Diameter Overload Indication Conveyance. J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L. Morand. October 2015. (Format: TXT, HTML) (Updated by RFC8581) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7683) 7684 OSPFv2 Prefix/Link Attribute Advertisement. P. Psenak, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura, A. Lindem. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7684) 7685 A Transport Layer Security (TLS) ClientHello Padding Extension. A. Langley. October 2015. (Format: TXT, HTML) (Updates RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7685) 7686 The ".onion" Special-Use Domain Name. J. Appelbaum, A. Muffett. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7686) 7687 Report from the Strengthening the Internet (STRINT) Workshop. S. Farrell, R. Wenning, B. Bos, M. Blanchet, H. Tschofenig. December 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7687) 7688 GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks. Y. Lee, Ed., G. Bernstein, Ed.. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7688) 7689 Signaling Extensions for Wavelength Switched Optical Networks. G. Bernstein, Ed., S. Xu, Y. Lee, Ed., G. Martinelli, H. Harai. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7689) 7690 Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)). M. Byerly, M. Hite, J. Jaeggli. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7690) 7691 Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members. S. Bradner, Ed.. November 2015. (Format: TXT, HTML) (Obsoleted by RFC8711) (Updates RFC4071) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7691) 7692 Compression Extensions for WebSocket. T. Yoshino. December 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7692) 7693 The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC). M-J. Saarinen, Ed., J-P. Aumasson. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7693) 7694 Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding. J. Reschke. November 2015. (Format: TXT, HTML) (Obsoleted by RFC9110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7694) 7695 Distributed Prefix Assignment Algorithm. P. Pfister, B. Paterson, J. Arkko. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7695) 7696 Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms. R. Housley. November 2015. (Format: TXT, HTML) (Also BCP0201) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7696) 7697 MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB). P. Pan, S. Aldrin, M. Venkatesan, K. Sampath, T. Nadeau, S. Boutros. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7697) 7698 Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks. O. Gonzalez de Dios, Ed., R. Casellas, Ed., F. Zhang, X. Fu, D. Ceccarelli, I. Hussain. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7698) 7699 Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers. A. Farrel, D. King, Y. Li, F. Zhang. November 2015. (Format: TXT, HTML) (Updates RFC3471, RFC6205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7699) 7700 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames. P. Saint-Andre. December 2015. (Format: TXT, HTML) (Obsoleted by RFC8266) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7700) 7701 Multi-party Chat Using the Message Session Relay Protocol (MSRP). A. Niemi, M. Garcia-Martin, G. Sandbakken. December 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7701) 7702 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat. P. Saint-Andre, S. Ibarra, S. Loreto. December 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7702) 7703 Experience with Testing of Mapping of Address and Port Using Translation (MAP-T). E. Cordeiro, R. Carnier, A. Moreiras. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7703) 7704 An IETF with Much Diversity and Professional Conduct. D. Crocker, N. Clark. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7704) 7705 Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute. W. George, S. Amante. November 2015. (Format: TXT, HTML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7705) 7706 Decreasing Access Time to Root Servers by Running One on Loopback. W. Kumari, P. Hoffman. November 2015. (Format: TXT, HTML) (Obsoleted by RFC8806) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7706) 7707 Network Reconnaissance in IPv6 Networks. F. Gont, T. Chown. March 2016. (Format: TXT, HTML) (Obsoletes RFC5157) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7707) 7708 Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator. T. Nadeau, L. Martini, S. Bryant. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7708) 7709 Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs). A. Malis, Ed., B. Wilson, G. Clapp, V. Shukla. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7709) 7710 Captive-Portal Identification Using DHCP or Router Advertisements (RAs). W. Kumari, O. Gudmundsson, P. Ebersman, S. Sheng. December 2015. (Format: TXT, HTML) (Obsoleted by RFC8910) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7710) 7711 PKIX over Secure HTTP (POSH). M. Miller, P. Saint-Andre. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7711) 7712 Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre, M. Miller, P. Hancke. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7712) 7713 Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements. M. Mathis, B. Briscoe. December 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7713) 7714 AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP). D. McGrew, K. Igoe. December 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7714) 7715 Multipoint LDP (mLDP) Node Protection. IJ. Wijnands, Ed., K. Raza, A. Atlas, J. Tantsura, Q. Zhao. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7715) 7716 Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures. J. Zhang, L. Giuliano, E. Rosen, Ed., K. Subramanian, D. Pacella. December 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7716) 7717 IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP). K. Pentikousis, Ed., E. Zhang, Y. Cui. December 2015. (Format: TXT, HTML) (Updates RFC4656, RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7717) 7718 Registries for the One-Way Active Measurement Protocol (OWAMP). A. Morton. December 2015. (Format: TXT, HTML) (Updates RFC4656) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7718) 7719 DNS Terminology. P. Hoffman, A. Sullivan, K. Fujiwara. December 2015. (Format: TXT, HTML) (Obsoleted by RFC8499) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7719) 7720 DNS Root Name Service Protocol and Deployment Requirements. M. Blanchet, L-J. Liman. December 2015. (Format: TXT, HTML) (Obsoletes RFC2870) (Also BCP0040) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7720) 7721 Security and Privacy Considerations for IPv6 Address Generation Mechanisms. A. Cooper, F. Gont, D. Thaler. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7721) 7722 Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2). C. Dearlove, T. Clausen. December 2015. (Format: TXT, HTML) (Updates RFC7188, RFC7631) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7722) 7723 Port Control Protocol (PCP) Anycast Addresses. S. Kiesel, R. Penno. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7723) 7724 Active DHCPv4 Lease Query. K. Kinnear, M. Stapp, B. Volz, N. Russell. December 2015. (Format: TXT, HTML) (Updates RFC6926) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7724) 7725 An HTTP Status Code to Report Legal Obstacles. T. Bray. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7725) 7726 Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs). V. Govindan, K. Rajaraman, G. Mirsky, N. Akiya, S. Aldrin. January 2016. (Format: TXT, HTML) (Updates RFC5884) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7726) 7727 Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP). M. Zhang, H. Wen, J. Hu. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7727) 7728 RTP Stream Pause and Resume. B. Burman, A. Akram, R. Even, M. Westerlund. February 2016. (Format: TXT, HTML) (Updates RFC5104) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7728) 7729 Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management. B. Khasnabish, E. Haleplidis, J. Hadi Salim, Ed.. December 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7729) 7730 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator. G. Huston, S. Weiler, G. Michaelson, S. Kent. January 2016. (Format: TXT, HTML) (Obsoletes RFC6490) (Obsoleted by RFC8630) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7730) 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL). J. Hui, R. Kelsey. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7731) 7732 Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL). P. van der Stok, R. Cragie. February 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7732) 7733 Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control. A. Brandt, E. Baccelli, R. Cragie, P. van der Stok. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7733) 7734 Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN). D. Allan, Ed., J. Tantsura, D. Fedyk, A. Sajassi. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7734) 7735 Tracking Reviews of Documents. R. Sparks, T. Kivinen. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7735) 7736 Content Delivery Network Interconnection (CDNI) Media Type Registration. K. Ma. December 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7736) 7737 Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification. N. Akiya, G. Swallow, C. Pignataro, L. Andersson, M. Chen. January 2016. (Format: TXT, HTML) (Updates RFC7110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7737) 7738 A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS). M. Blanchet, A. Schiltknecht, P. Shames. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7738) 7739 Security Implications of Predictable Fragment Identification Values. F. Gont. February 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7739) 7740 Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication. Z. Zhang, Y. Rekhter, A. Dolganow. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7740) 7741 RTP Payload Format for VP8 Video. P. Westin, H. Lundin, M. Glover, J. Uberti, F. Galligan. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7741) 7742 WebRTC Video Processing and Codec Requirements. A.B. Roach. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7742) 7743 Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping. J. Luo, Ed., L. Jin, Ed., T. Nadeau, Ed., G. Swallow, Ed.. January 2016. (Format: TXT, HTML) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7743) 7744 Use Cases for Authentication and Authorization in Constrained Environments. L. Seitz, Ed., S. Gerdes, Ed., G. Selander, M. Mani, S. Kumar. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7744) 7745 XML Schemas for Reverse DNS Management. T. Manderson. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7745) 7746 Label Switched Path (LSP) Self-Ping. R. Bonica, I. Minei, M. Conn, D. Pacella, L. Tomotaki. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7746) 7747 Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence. R. Papneja, B. Parise, S. Hares, D. Lee, I. Varlashkin. April 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7747) 7748 Elliptic Curves for Security. A. Langley, M. Hamburg, S. Turner. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7748) 7749 The "xml2rfc" Version 2 Vocabulary. J. Reschke. February 2016. (Format: TXT, HTML) (Obsoletes RFC2629) (Obsoleted by RFC7991) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7749) 7750 Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP). J. Hedin, G. Mirsky, S. Baillargeon. February 2016. (Format: TXT, HTML) (Updates RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7750) 7751 Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs). S. Sorce, T. Yu. March 2016. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7751) 7752 North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP. H. Gredler, Ed., J. Medved, S. Previdi, A. Farrel, S. Ray. March 2016. (Format: TXT, HTML) (Updated by RFC9029) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7752) 7753 Port Control Protocol (PCP) Extension for Port-Set Allocation. Q. Sun, M. Boucadair, S. Sivakumar, C. Zhou, T. Tsou, S. Perreault. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7753) 7754 Technical Considerations for Internet Service Blocking and Filtering. R. Barnes, A. Cooper, O. Kolkman, D. Thaler, E. Nordmark. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7754) 7755 SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments. T. Anderson. February 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7755) 7756 Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode. T. Anderson, S. Steffann. February 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7756) 7757 Explicit Address Mappings for Stateless IP/ICMP Translation. T. Anderson, A. Leiva Popper. February 2016. (Format: TXT, HTML) (Updates RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7757) 7758 Time Capability in NETCONF. T. Mizrahi, Y. Moses. February 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7758) 7759 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping. E. Bellagamba, G. Mirsky, L. Andersson, P. Skoldstrom, D. Ward, J. Drake. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7759) 7760 Statement of Work for Extensions to the IETF Datatracker for Author Statistics. R. Housley. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7760) 7761 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, R. Parekh, Z. Zhang, L. Zheng. March 2016. (Format: TXT, HTML) (Obsoletes RFC4601) (Updated by RFC8736) (Also STD0083) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7761) 7762 Initial Assignment for the Content Security Policy Directives Registry. M. West. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7762) 7763 The text/markdown Media Type. S. Leonard. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7763) 7764 Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations. S. Leonard. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7764) 7765 TCP and Stream Control Transmission Protocol (SCTP) RTO Restart. P. Hurtig, A. Brunstrom, A. Petlund, M. Welzl. February 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7765) 7766 DNS Transport over TCP - Implementation Requirements. J. Dickinson, S. Dickinson, R. Bellis, A. Mankin, D. Wessels. March 2016. (Format: TXT, HTML) (Obsoletes RFC5966) (Updates RFC1035, RFC1123) (Updated by RFC8490, RFC9103) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7766) 7767 Application-Initiated Check-Pointing via the Port Control Protocol (PCP). S. Vinapamula, S. Sivakumar, M. Boucadair, T. Reddy. February 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7767) 7768 Port Management to Reduce Logging in Large-Scale NATs. T. Tsou, W. Li, T. Taylor, J. Huang. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7768) 7769 Media Access Control (MAC) Address Withdrawal over Static Pseudowire. S. Sivabalan, S. Boutros, H. Shah, S. Aldrin, M. Venkatesan. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7769) 7770 Extensions to OSPF for Advertising Optional Router Capabilities. A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer. February 2016. (Format: TXT, HTML) (Obsoletes RFC4970) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7770) 7771 Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires. A. Malis, Ed., L. Andersson, H. van Helvoort, J. Shin, L. Wang, A. D'Alessandro. January 2016. (Format: TXT, HTML) (Updates RFC6870) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7771) 7772 Reducing Energy Consumption of Router Advertisements. A. Yourtchenko, L. Colitti. February 2016. (Format: TXT, HTML) (Also BCP0202) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7772) 7773 Authentication Context Certificate Extension. S. Santesson. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7773) 7774 Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6. Y. Doi, M. Gillmore. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7774) 7775 IS-IS Route Preference for Extended IP and IPv6 Reachability. L. Ginsberg, S. Litkowski, S. Previdi. February 2016. (Format: TXT, HTML) (Updates RFC5308) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7775) 7776 IETF Anti-Harassment Procedures. P. Resnick, A. Farrel. March 2016. (Format: TXT, HTML) (Updates RFC2418) (Updated by RFC8716) (Also BCP0025) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7776) 7777 Advertising Node Administrative Tags in OSPF. S. Hegde, R. Shakir, A. Smirnov, Z. Li, B. Decraene. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7777) 7778 Mobile Communication Congestion Exposure Scenario. D. Kutscher, F. Mir, R. Winter, S. Krishnan, Y. Zhang, CJ. Bernardos. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7778) 7779 Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2). H. Rogge, E. Baccelli. April 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7779) 7780 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates. D. Eastlake 3rd, M. Zhang, R. Perlman, A. Banerjee, A. Ghanwani, S. Gupta. February 2016. (Format: TXT, HTML) (Obsoletes RFC7180) (Updates RFC6325, RFC7177, RFC7179) (Updated by RFC8249) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7780) 7781 Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access. H. Zhai, T. Senevirathne, R. Perlman, M. Zhang, Y. Li. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7781) 7782 Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments. M. Zhang, R. Perlman, H. Zhai, M. Durrani, S. Gupta. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7782) 7783 Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL). T. Senevirathne, J. Pathangi, J. Hudson. February 2016. (Format: TXT, HTML) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7783) 7784 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB. D. Kumar, S. Salam, T. Senevirathne. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7784) 7785 Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite. S. Vinapamula, M. Boucadair. February 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7785) 7786 TCP Modifications for Congestion Exposure (ConEx). M. Kuehlewind, Ed., R. Scheffenegger. May 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7786) 7787 Distributed Node Consensus Protocol. M. Stenberg, S. Barth. April 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7787) 7788 Home Networking Control Protocol. M. Stenberg, S. Barth, P. Pfister. April 2016. (Format: TXT, HTML) (Updated by RFC8375) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7788) 7789 Impact of BGP Filtering on Inter-Domain Routing Policies. C. Cardona, P. Francois, P. Lucente. April 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7789) 7790 Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS). Y. Yoneya, T. Nemoto. February 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7790) 7791 Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2). D. Migault, Ed., V. Smyslov. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7791) 7792 RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks. F. Zhang, X. Zhang, A. Farrel, O. Gonzalez de Dios, D. Ceccarelli. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7792) 7793 Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry. M. Andrews. May 2016. (Format: TXT, HTML) (Also BCP0163) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7793) 7794 IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability. L. Ginsberg, Ed., B. Decraene, S. Previdi, X. Xu, U. Chunduri. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7794) 7795 Pseudowire Redundancy on the Switching Provider Edge (S-PE). J. Dong, H. Wang. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7795) 7796 Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS). Y. Jiang, Ed., L. Yong, M. Paul. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7796) 7797 JSON Web Signature (JWS) Unencoded Payload Option. M. Jones. February 2016. (Format: TXT, HTML) (Updates RFC7519) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7797) 7798 RTP Payload Format for High Efficiency Video Coding (HEVC). Y.-K. Wang, Y. Sanchez, T. Schierl, S. Wenger, M. M. Hannuksela. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7798) 7799 Active and Passive Metrics and Methods (with Hybrid Types In-Between). A. Morton. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7799) 7800 Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs). M. Jones, J. Bradley, H. Tschofenig. April 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7800) 7801 GOST R 34.12-2015: Block Cipher "Kuznyechik". V. Dolmatov, Ed.. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7801) 7802 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism. S. Emery, N. Williams. March 2016. (Format: TXT, HTML) (Obsoletes RFC4402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7802) 7803 Changing the Registration Policy for the NETCONF Capability URNs Registry. B. Leiba. February 2016. (Format: TXT, HTML) (Updates RFC6241) (Also BCP0203) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7803) 7804 Salted Challenge Response HTTP Authentication Mechanism. A. Melnikov. March 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7804) 7805 Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status. A. Zimmermann, W. Eddy, L. Eggert. April 2016. (Format: TXT, HTML) (Obsoletes RFC0675, RFC0721, RFC0761, RFC0813, RFC0816, RFC0879, RFC0896, RFC1078, RFC6013) (Updates RFC7414) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7805) 7806 On Queuing, Marking, and Dropping. F. Baker, R. Pan. April 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7806) 7807 Problem Details for HTTP APIs. M. Nottingham, E. Wilde. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7807) 7808 Time Zone Data Distribution Service. M. Douglass, C. Daboo. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7808) 7809 Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference. C. Daboo. March 2016. (Format: TXT, HTML) (Updates RFC4791) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7809) 7810 IS-IS Traffic Engineering (TE) Metric Extensions. S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu. May 2016. (Format: TXT, HTML) (Obsoleted by RFC8570) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7810) 7811 An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR). G. Enyedi, A. Csaszar, A. Atlas, C. Bowers, A. Gopalan. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7811) 7812 An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR). A. Atlas, C. Bowers, G. Enyedi. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7812) 7813 IS-IS Path Control and Reservation. J. Farkas, Ed., N. Bragg, P. Unbehagen, G. Parsons, P. Ashwood-Smith, C. Bowers. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7813) 7814 Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution. X. Xu, C. Jacquenet, R. Raszuk, T. Boyes, B. Fee. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7814) 7815 Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation. T. Kivinen. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7815) 7816 DNS Query Name Minimisation to Improve Privacy. S. Bortzmeyer. March 2016. (Format: TXT, HTML) (Obsoleted by RFC9156) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7816) 7817 Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols. A. Melnikov. March 2016. (Format: TXT, HTML) (Updates RFC2595, RFC3207, RFC3501, RFC5804) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7817) 7818 URN Namespace for MEF Documents. M. Jethanandani. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7818) 7819 Privacy Considerations for DHCP. S. Jiang, S. Krishnan, T. Mrugalski. April 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7819) 7820 UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP). T. Mizrahi. March 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7820) 7821 UDP Checksum Complement in the Network Time Protocol (NTP). T. Mizrahi. March 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7821) 7822 Network Time Protocol Version 4 (NTPv4) Extension Fields. T. Mizrahi, D. Mayer. March 2016. (Format: TXT, HTML) (Updates RFC5905) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7822) 7823 Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions. A. Atlas, J. Drake, S. Giacalone, S. Previdi. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7823) 7824 Privacy Considerations for DHCPv6. S. Krishnan, T. Mrugalski, S. Jiang. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7824) 7825 A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP). J. Goldberg, M. Westerlund, T. Zeng. December 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7825) 7826 Real-Time Streaming Protocol Version 2.0. H. Schulzrinne, A. Rao, R. Lanphier, M. Westerlund, M. Stiemerling, Ed.. December 2016. (Format: TXT, HTML) (Obsoletes RFC2326) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7826) 7827 The Role of the IRTF Chair. L. Eggert. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7827) 7828 The edns-tcp-keepalive EDNS0 Option. P. Wouters, J. Abley, S. Dickinson, R. Bellis. April 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7828) 7829 SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol. Y. Nishida, P. Natarajan, A. Caro, P. Amer, K. Nielsen. April 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7829) 7830 The EDNS(0) Padding Option. A. Mayrhofer. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7830) 7831 Application Bridging for Federated Access Beyond Web (ABFAB) Architecture. J. Howlett, S. Hartman, H. Tschofenig, J. Schaad. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7831) 7832 Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases. R. Smith, Ed.. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7832) 7833 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML). J. Howlett, S. Hartman, A. Perez-Mendez, Ed.. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7833) 7834 Locator/ID Separation Protocol (LISP) Impact. D. Saucez, L. Iannone, A. Cabellos, F. Coras. April 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7834) 7835 Locator/ID Separation Protocol (LISP) Threat Analysis. D. Saucez, L. Iannone, O. Bonaventure. April 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7835) 7836 Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012. S. Smyshlyaev, Ed., E. Alekseev, I. Oshkin, V. Popov, S. Leontiev, V. Podobaev, D. Belyavsky. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7836) 7837 IPv6 Destination Option for Congestion Exposure (ConEx). S. Krishnan, M. Kuehlewind, B. Briscoe, C. Ralli. May 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7837) 7838 HTTP Alternative Services. M. Nottingham, P. McManus, J. Reschke. April 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7838) 7839 Access-Network-Identifier Option in DHCP. S. Bhandari, S. Gundavelli, M. Grayson, B. Volz, J. Korhonen. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7839) 7840 A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol. J. Winterbottom, H. Tschofenig, L. Liess. May 2016. (Format: TXT, HTML) (Updates RFC5985, RFC6881) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7840) 7841 RFC Streams, Headers, and Boilerplates. J. Halpern, Ed., L. Daigle, Ed., O. Kolkman, Ed.. May 2016. (Format: TXT, HTML) (Obsoletes RFC5741) (Updated by RFC9280) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7841) 7842 Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool. R. Sparks. April 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7842) 7843 Port Control Protocol (PCP) Third-Party ID Option. A. Ripke, R. Winter, T. Dietz, J. Quittek, R. da Silva. May 2016. (Format: TXT, HTML) (Updates RFC6887) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7843) 7844 Anonymity Profiles for DHCP Clients. C. Huitema, T. Mrugalski, S. Krishnan. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7844) 7845 Ogg Encapsulation for the Opus Audio Codec. T. Terriberry, R. Lee, R. Giles. April 2016. (Format: TXT, HTML) (Updates RFC5334) (Updated by RFC8486) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7845) 7846 Peer-to-Peer Streaming Tracker Protocol (PPSTP). R. Cruz, M. Nunes, J. Xia, R. Huang, Ed., J. Taveira, D. Lingli. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7846) 7847 Logical-Interface Support for IP Hosts with Multi-Access Support. T. Melia, Ed., S. Gundavelli, Ed.. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7847) 7848 Mark and Signed Mark Objects Mapping. G. Lozano. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7848) 7849 An IPv6 Profile for 3GPP Mobile Devices. D. Binet, M. Boucadair, A. Vizdal, G. Chen, N. Heatley, R. Chandler, D. Michaud, D. Lopez, W. Haeffner. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7849) 7850 Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles. S. Nandakumar. April 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7850) 7851 Peer-to-Peer (P2P) Overlay Diagnostics. H. Song, X. Jiang, R. Even, D. Bryan, Y. Sun. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7851) 7852 Additional Data Related to an Emergency Call. R. Gellens, B. Rosen, H. Tschofenig, R. Marshall, J. Winterbottom. July 2016. (Format: TXT, HTML) (Updates RFC6443, RFC6881) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7852) 7853 A URN Namespace for Globus. S. Martin, S. Tuecke, B. McCollam, M. Lidman. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7853) 7854 BGP Monitoring Protocol (BMP). J. Scudder, Ed., R. Fernando, S. Stuart. June 2016. (Format: TXT, HTML) (Updated by RFC8671, RFC9069) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7854) 7855 Source Packet Routing in Networking (SPRING) Problem Statement and Requirements. S. Previdi, Ed., C. Filsfils, Ed., B. Decraene, S. Litkowski, M. Horneffer, R. Shakir. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7855) 7856 Softwire Mesh Management Information Base (MIB). Y. Cui, J. Dong, P. Wu, M. Xu, A. Yla-Jaaski. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7856) 7857 Updates to Network Address Translation (NAT) Behavioral Requirements. R. Penno, S. Perreault, M. Boucadair, Ed., S. Sivakumar, K. Naito. April 2016. (Format: TXT, HTML) (Updates RFC4787, RFC5382, RFC5508) (Also BCP0127) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7857) 7858 Specification for DNS over Transport Layer Security (TLS). Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels, P. Hoffman. May 2016. (Format: TXT, HTML) (Updated by RFC8310) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7858) 7859 Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols. C. Dearlove. May 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7859) 7860 HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3. J. Merkle, Ed., M. Lochter. April 2016. (Format: TXT, HTML) (Obsoletes RFC7630) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7860) 7861 Remote Procedure Call (RPC) Security Version 3. A. Adamson, N. Williams. November 2016. (Format: TXT, HTML) (Updates RFC5403) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7861) 7862 Network File System (NFS) Version 4 Minor Version 2 Protocol. T. Haynes. November 2016. (Format: TXT, HTML) (Updated by RFC8178) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7862) 7863 Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description. T. Haynes. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7863) 7864 Proxy Mobile IPv6 Extensions to Support Flow Mobility. CJ. Bernardos, Ed.. May 2016. (Format: TXT, HTML) (Updates RFC5213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7864) 7865 Session Initiation Protocol (SIP) Recording Metadata. R. Ravindranath, P. Ravindran, P. Kyzivat. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7865) 7866 Session Recording Protocol. L. Portman, H. Lum, Ed., C. Eckel, A. Johnston, A. Hutton. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7866) 7867 RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications. R. Huang. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7867) 7868 Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP). D. Savage, J. Ng, S. Moore, D. Slice, P. Paluch, R. White. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7868) 7869 The "vnc" URI Scheme. D. Warden, I. Iordanov. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7869) 7870 Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs). Y. Fu, S. Jiang, J. Dong, Y. Chen. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7870) 7871 Client Subnet in DNS Queries. C. Contavalli, W. van der Gaast, D. Lawrence, W. Kumari. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7871) 7872 Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World. F. Gont, J. Linkova, T. Chown, W. Liu. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7872) 7873 Domain Name System (DNS) Cookies. D. Eastlake 3rd, M. Andrews. May 2016. (Format: TXT, HTML) (Updated by RFC9018) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7873) 7874 WebRTC Audio Codec and Processing Requirements. JM. Valin, C. Bran. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7874) 7875 Additional WebRTC Audio Codecs for Interoperability. S. Proust, Ed.. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7875) 7876 UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks. S. Bryant, S. Sivabalan, S. Soni. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7876) 7877 Session Peering Provisioning Framework (SPPF). K. Cartwright, V. Bhatia, S. Ali, D. Schwartz. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7877) 7878 Session Peering Provisioning (SPP) Protocol over SOAP. K. Cartwright, V. Bhatia, J-F. Mule, A. Mayrhofer. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7878) 7879 DTLS-SRTP Handling in SIP Back-to-Back User Agents. R. Ravindranath, T. Reddy, G. Salgueiro, V. Pascual, P. Ravindran. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7879) 7880 Seamless Bidirectional Forwarding Detection (S-BFD). C. Pignataro, D. Ward, N. Akiya, M. Bhatia, S. Pallagatti. July 2016. (Format: TXT, HTML) (Updates RFC5880) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7880) 7881 Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS. C. Pignataro, D. Ward, N. Akiya. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7881) 7882 Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases. S. Aldrin, C. Pignataro, G. Mirsky, N. Kumar. July 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7882) 7883 Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS. L. Ginsberg, N. Akiya, M. Chen. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7883) 7884 OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators. C. Pignataro, M. Bhatia, S. Aldrin, T. Ranganath. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7884) 7885 Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV). V. Govindan, C. Pignataro. July 2016. (Format: TXT, HTML) (Updates RFC5885) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7885) 7886 Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3). V. Govindan, C. Pignataro. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7886) 7887 Hierarchical Join/Prune Attributes. S. Venaas, J. Arango, I. Kouvelas. June 2016. (Format: TXT, HTML) (Updates RFC5384) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7887) 7888 IMAP4 Non-synchronizing Literals. A. Melnikov, Ed.. May 2016. (Format: TXT, HTML) (Obsoletes RFC2088) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7888) 7889 The IMAP APPENDLIMIT Extension. J. SrimushnamBoovaraghamoorthy, N. Bisht. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7889) 7890 Concepts and Terminology for Peer-to-Peer SIP (P2PSIP). D. Bryan, P. Matthews, E. Shim, D. Willis, S. Dawkins. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7890) 7891 Explicit Reverse Path Forwarding (RPF) Vector. J. Asghar, IJ. Wijnands, Ed., S. Krishnaswamy, A. Karan, V. Arya. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7891) 7892 IANA Allocation Procedures for the GMPLS OTN Signal Type Registry. Z. Ali, A. Bonfanti, M. Hartley, F. Zhang. May 2016. (Format: TXT, HTML) (Updates RFC7139) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7892) 7893 Pseudowire Congestion Considerations. Y(J) Stein, D. Black, B. Briscoe. June 2016. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7893) 7894 Alternative Challenge Password Attributes for Enrollment over Secure Transport. M. Pritikin, C. Wallace. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7894) 7895 YANG Module Library. A. Bierman, M. Bjorklund, K. Watsen. June 2016. (Format: TXT, HTML) (Obsoleted by RFC8525) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7895) 7896 Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP). D. Dhody. June 2016. (Format: TXT, HTML) (Updates RFC5440) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7896) 7897 Domain Subobjects for the Path Computation Element Communication Protocol (PCEP). D. Dhody, U. Palle, R. Casellas. June 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7897) 7898 Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE). D. Dhody, U. Palle, V. Kondreddy, R. Casellas. June 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7898) 7899 Multicast VPN State Damping. T. Morin, Ed., S. Litkowski, K. Patel, Z. Zhang, R. Kebler, J. Haas. June 2016. (Format: TXT, HTML) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7899) 7900 Extranet Multicast in BGP/IP MPLS VPNs. Y. Rekhter, Ed., E. Rosen, Ed., R. Aggarwal, Y. Cai, T. Morin. June 2016. (Format: TXT, HTML) (Updates RFC6513, RFC6514, RFC6625) (Updated by RFC8534) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7900) 7901 CHAIN Query Requests in DNS. P. Wouters. June 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7901) 7902 Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags. E. Rosen, T. Morin. June 2016. (Format: TXT, HTML) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7902) 7903 Windows Image Media Types. S. Leonard. September 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7903) 7904 A SIP Usage for REsource LOcation And Discovery (RELOAD). C. Jennings, B. Lowekamp, E. Rescorla, S. Baset, H. Schulzrinne, T. Schmidt, Ed.. October 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7904) 7905 ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS). A. Langley, W. Chang, N. Mavrogiannopoulos, J. Strombergson, S. Josefsson. June 2016. (Format: TXT, HTML) (Updates RFC5246, RFC6347) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7905) 7906 NSA's Cryptographic Message Syntax (CMS) Key Management Attributes. P. Timmel, R. Housley, S. Turner. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7906) 7907 Not Issued. 7908 Problem Definition and Classification of BGP Route Leaks. K. Sriram, D. Montgomery, D. McPherson, E. Osterweil, B. Dickson. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7908) 7909 Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures. R. Kisteleki, B. Haberman. June 2016. (Format: TXT, HTML) (Updates RFC2622, RFC4012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7909) 7910 Interoperability between the Virtual Router Redundancy Protocol and PIM. W. Zhou. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7910) 7911 Advertisement of Multiple Paths in BGP. D. Walton, A. Retana, E. Chen, J. Scudder. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7911) 7912 Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure. A. Melnikov. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7912) 7913 P-Access-Network-Info ABNF Update. C. Holmberg. June 2016. (Format: TXT, HTML) (Updates RFC7315) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7913) 7914 The scrypt Password-Based Key Derivation Function. C. Percival, S. Josefsson. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7914) 7915 IP/ICMP Translation Algorithm. C. Bao, X. Li, F. Baker, T. Anderson, F. Gont. June 2016. (Format: TXT, HTML) (Obsoletes RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7915) 7916 Operational Management of Loop-Free Alternates. S. Litkowski, Ed., B. Decraene, C. Filsfils, K. Raza, M. Horneffer, P. Sarkar. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7916) 7917 Advertising Node Administrative Tags in IS-IS. P. Sarkar, Ed., H. Gredler, S. Hegde, S. Litkowski, B. Decraene. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7917) 7918 Transport Layer Security (TLS) False Start. A. Langley, N. Modadugu, B. Moeller. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7918) 7919 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS). D. Gillmor. August 2016. (Format: TXT, HTML) (Updates RFC2246, RFC4346, RFC4492, RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7919) 7920 Problem Statement for the Interface to the Routing System. A. Atlas, Ed., T. Nadeau, Ed., D. Ward. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7920) 7921 An Architecture for the Interface to the Routing System. A. Atlas, J. Halpern, S. Hares, D. Ward, T. Nadeau. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7921) 7922 Interface to the Routing System (I2RS) Traceability: Framework and Information Model. J. Clarke, G. Salgueiro, C. Pignataro. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7922) 7923 Requirements for Subscription to YANG Datastores. E. Voit, A. Clemm, A. Gonzalez Prieto. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7923) 7924 Transport Layer Security (TLS) Cached Information Extension. S. Santesson, H. Tschofenig. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7924) 7925 Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things. H. Tschofenig, Ed., T. Fossati. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7925) 7926 Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks. A. Farrel, Ed., J. Drake, N. Bitar, G. Swallow, D. Ceccarelli, X. Zhang. July 2016. (Format: TXT, HTML) (Also BCP0206) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7926) 7927 Information-Centric Networking (ICN) Research Challenges. D. Kutscher, Ed., S. Eum, K. Pentikousis, I. Psaras, D. Corujo, D. Saucez, T. Schmidt, M. Waehlisch. July 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7927) 7928 Characterization Guidelines for Active Queue Management (AQM). N. Kuhn, Ed., P. Natarajan, Ed., N. Khademi, Ed., D. Ros. July 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7928) 7929 DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP. P. Wouters. August 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7929) 7930 Larger Packets for RADIUS over TCP. S. Hartman. August 2016. (Format: TXT, HTML) (Updates RFC6613) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7930) 7931 NFSv4.0 Migration: Specification Update. D. Noveck, Ed., P. Shivam, C. Lever, B. Baker. July 2016. (Format: TXT, HTML) (Updates RFC7530) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7931) 7932 Brotli Compressed Data Format. J. Alakuijala, Z. Szabadka. July 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7932) 7933 Adaptive Video Streaming over Information-Centric Networking (ICN). C. Westphal, Ed., S. Lederer, D. Posch, C. Timmerer, A. Azgin, W. Liu, C. Mueller, A. Detti, D. Corujo, J. Wang, M. Montpetit, N. Murray. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7933) 7934 Host Address Availability Recommendations. L. Colitti, V. Cerf, S. Cheshire, D. Schinazi. July 2016. (Format: TXT, HTML) (Also BCP0204) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7934) 7935 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure. G. Huston, G. Michaelson, Ed.. August 2016. (Format: TXT, HTML) (Obsoletes RFC6485) (Updated by RFC8208, RFC8608) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7935) 7936 Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry. T. Hardie. July 2016. (Format: TXT, HTML) (Updates RFC6455) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7936) 7937 Content Distribution Network Interconnection (CDNI) Logging Interface. F. Le Faucheur, Ed., G. Bertrand, Ed., I. Oprescu, Ed., R. Peterkofsky. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7937) 7938 Use of BGP for Routing in Large-Scale Data Centers. P. Lapukhov, A. Premji, J. Mitchell, Ed.. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7938) 7939 Definition of Managed Objects for the Neighborhood Discovery Protocol. U. Herberg, R. Cole, I. Chakeres, T. Clausen. August 2016. (Format: TXT, HTML) (Obsoletes RFC6779) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7939) 7940 Representing Label Generation Rulesets Using XML. K. Davies, A. Freytag. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7940) 7941 RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items. M. Westerlund, B. Burman, R. Even, M. Zanaty. August 2016. (Format: TXT, HTML) (Updated by RFC8843, RFC9143) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7941) 7942 Improving Awareness of Running Code: The Implementation Status Section. Y. Sheffer, A. Farrel. July 2016. (Format: TXT, HTML) (Obsoletes RFC6982) (Also BCP0205) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7942) 7943 A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). F. Gont, W. Liu. September 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7943) 7944 Diameter Routing Message Priority. S. Donovan. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7944) 7945 Information-Centric Networking: Evaluation and Security Considerations. K. Pentikousis, Ed., B. Ohlman, E. Davies, S. Spirou, G. Boggia. September 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7945) 7946 The GeoJSON Format. H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7946) 7947 Internet Exchange BGP Route Server. E. Jasinska, N. Hilliard, R. Raszuk, N. Bakker. September 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7947) 7948 Internet Exchange BGP Route Server Operations. N. Hilliard, E. Jasinska, R. Raszuk, N. Bakker. September 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7948) 7949 OSPFv3 over IPv4 for IPv6 Transition. I. Chen, A. Lindem, R. Atkinson. August 2016. (Format: TXT, HTML) (Updates RFC5838) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7949) 7950 The YANG 1.1 Data Modeling Language. M. Bjorklund, Ed.. August 2016. (Format: TXT, HTML) (Updated by RFC8342, RFC8526) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7950) 7951 JSON Encoding of Data Modeled with YANG. L. Lhotka. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7951) 7952 Defining and Using Metadata with YANG. L. Lhotka. August 2016. (Format: TXT, HTML) (Updates RFC6110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7952) 7953 Calendar Availability. C. Daboo, M. Douglass. August 2016. (Format: TXT, HTML) (Updates RFC4791, RFC5545, RFC6638) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7953) 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block. L. Iannone, D. Lewis, D. Meyer, V. Fuller. September 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7954) 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block. L. Iannone, R. Jorgensen, D. Conrad, G. Huston. September 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7955) 7956 Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway. W. Hao, Y. Li, A. Qu, M. Durrani, P. Sivamurugan. September 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7956) 7957 DISPATCH-Style Working Groups and the SIP Change Process. B. Campbell, Ed., A. Cooper, B. Leiba. August 2016. (Format: TXT, HTML) (Updates RFC5727) (Also BCP0067) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7957) 7958 DNSSEC Trust Anchor Publication for the Root Zone. J. Abley, J. Schlyter, G. Bailey, P. Hoffman. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7958) 7959 Block-Wise Transfers in the Constrained Application Protocol (CoAP). C. Bormann, Z. Shelby, Ed.. August 2016. (Format: TXT, HTML) (Updates RFC7252) (Updated by RFC8323) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7959) 7960 Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows. F. Martin, Ed., E. Lear, Ed., T. Draegen, Ed., E. Zwicky, Ed., K. Andersen, Ed.. September 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7960) 7961 Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV. D. Eastlake 3rd, L. Yizhou. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7961) 7962 Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures. J. Saldana, Ed., A. Arcia-Moret, B. Braem, E. Pietrosemoli, A. Sathiaseelan, M. Zennaro. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7962) 7963 RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs). Z. Ali, A. Bonfanti, M. Hartley, F. Zhang. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7963) 7964 Solutions for BGP Persistent Route Oscillation. D. Walton, A. Retana, E. Chen, J. Scudder. September 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7964) 7965 LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels. M. Chen, W. Cao, A. Takacs, P. Pan. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7965) 7966 Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements. H. Tschofenig, J. Korhonen, Ed., G. Zorn, K. Pillay. September 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7966) 7967 Constrained Application Protocol (CoAP) Option for No Server Response. A. Bhattacharyya, S. Bandyopadhyay, A. Pal, T. Bose. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7967) 7968 Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data. Y. Li, D. Eastlake 3rd, W. Hao, H. Chen, S. Chatterjee. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7968) 7969 Customizing DHCP Configuration on the Basis of Network Topology. T. Lemon, T. Mrugalski. October 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7969) 7970 The Incident Object Description Exchange Format Version 2. R. Danyliw. November 2016. (Format: TXT, HTML) (Obsoletes RFC5070, RFC6685) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7970) 7971 Application-Layer Traffic Optimization (ALTO) Deployment Considerations. M. Stiemerling, S. Kiesel, M. Scharf, H. Seidel, S. Previdi. October 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7971) 7972 Entertainment Identifier Registry (EIDR) URN Namespace Definition. P. Lemieux. September 2016. (Format: TXT, HTML) (Obsoletes RFC7302) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7972) 7973 Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation. R. Droms, P. Duffy. November 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7973) 7974 An Experimental TCP Option for Host Identification. B. Williams, M. Boucadair, D. Wing. October 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7974) 7975 Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection. B. Niven-Jenkins, Ed., R. van Brandenburg, Ed.. October 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7975) 7976 Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses. C. Holmberg, N. Biondic, G. Salgueiro. September 2016. (Format: TXT, HTML) (Updates RFC7315) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7976) 7977 The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP). P. Dunkley, G. Llewellyn, V. Pascual, G. Salgueiro, R. Ravindranath. September 2016. (Format: TXT, HTML) (Updates RFC4975, RFC4976) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7977) 7978 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension. D. Eastlake 3rd, M. Umair, Y. Li. September 2016. (Format: TXT, HTML) (Updates RFC7178) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7978) 7979 Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries. E. Lear, Ed., R. Housley, Ed.. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7979) 7980 A Framework for Defining Network Complexity. M. Behringer, A. Retana, R. White, G. Huston. October 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7980) 7981 IS-IS Extensions for Advertising Router Information. L. Ginsberg, S. Previdi, M. Chen. October 2016. (Format: TXT, HTML) (Obsoletes RFC4971) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7981) 7982 Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN). P. Martinsen, T. Reddy, D. Wing, V. Singh. September 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7982) 7983 Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS). M. Petit-Huguenin, G. Salgueiro. September 2016. (Format: TXT, HTML) (Updates RFC5764) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7983) 7984 Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network. O. Johansson, G. Salgueiro, V. Gurbani, D. Worley, Ed.. September 2016. (Format: TXT, HTML) (Updates RFC3263) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7984) 7985 Security Threats to Simplified Multicast Forwarding (SMF). J. Yi, T. Clausen, U. Herberg. November 2016. (Format: TXT, HTML) (Updates RFC7186) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7985) 7986 New Properties for iCalendar. C. Daboo. October 2016. (Format: TXT, HTML) (Updates RFC5545) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7986) 7987 IS-IS Minimum Remaining Lifetime. L. Ginsberg, P. Wells, B. Decraene, T. Przygienda, H. Gredler. October 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7987) 7988 Ingress Replication Tunnels in Multicast VPN. E. Rosen, Ed., K. Subramanian, Z. Zhang. October 2016. (Format: TXT, HTML) (Updates RFC6513, RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7988) 7989 End-to-End Session Identification in IP-Based Multimedia Communication Networks. P. Jones, G. Salgueiro, C. Pearce, P. Giralt. October 2016. (Format: TXT, HTML) (Obsoletes RFC7329) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7989) 7990 RFC Format Framework. H. Flanagan. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7990) 7991 The "xml2rfc" Version 3 Vocabulary. P. Hoffman. December 2016. (Format: TXT, HTML) (Obsoletes RFC7749) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7991) 7992 HTML Format for RFCs. J. Hildebrand, Ed., P. Hoffman. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7992) 7993 Cascading Style Sheets (CSS) Requirements for RFCs. H. Flanagan. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7993) 7994 Requirements for Plain-Text RFCs. H. Flanagan. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7994) 7995 PDF Format for RFCs. T. Hansen, Ed., L. Masinter, M. Hardy. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7995) 7996 SVG Drawings for RFCs: SVG 1.2 RFC. N. Brownlee. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7996) 7997 The Use of Non-ASCII Characters in RFCs. H. Flanagan, Ed.. December 2016. (Format: TXT, PDF, HTML) (Updates RFC7322) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7997) 7998 "xml2rfc" Version 3 Preparation Tool Description. P. Hoffman, J. Hildebrand. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7998) 7999 BLACKHOLE Community. T. King, C. Dietzel, J. Snijders, G. Doering, G. Hankins. October 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7999) 8000 Requirements for NFSv4 Multi-Domain Namespace Deployment. A. Adamson, N. Williams. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8000) 8001 RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information. F. Zhang, Ed., O. Gonzalez de Dios, Ed., C. Margaria, M. Hartley, Z. Ali. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8001) 8002 Host Identity Protocol Certificates. T. Heer, S. Varjonen. October 2016. (Format: TXT, HTML) (Obsoletes RFC6253) (Updates RFC7401) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8002) 8003 Host Identity Protocol (HIP) Registration Extension. J. Laganier, L. Eggert. October 2016. (Format: TXT, HTML) (Obsoletes RFC5203) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8003) 8004 Host Identity Protocol (HIP) Rendezvous Extension. J. Laganier, L. Eggert. October 2016. (Format: TXT, HTML) (Obsoletes RFC5204) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8004) 8005 Host Identity Protocol (HIP) Domain Name System (DNS) Extension. J. Laganier. October 2016. (Format: TXT, HTML) (Obsoletes RFC5205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8005) 8006 Content Delivery Network Interconnection (CDNI) Metadata. B. Niven-Jenkins, R. Murray, M. Caulfield, K. Ma. December 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8006) 8007 Content Delivery Network Interconnection (CDNI) Control Interface / Triggers. R. Murray, B. Niven-Jenkins. December 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8007) 8008 Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics. J. Seedorf, J. Peterson, S. Previdi, R. van Brandenburg, K. Ma. December 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8008) 8009 AES Encryption with HMAC-SHA2 for Kerberos 5. M. Jenkins, M. Peck, K. Burgin. October 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8009) 8010 Internet Printing Protocol/1.1: Encoding and Transport. M. Sweet, I. McDonald. January 2017. (Format: TXT, HTML) (Obsoletes RFC2910, RFC3382) (Also STD0092) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8010) 8011 Internet Printing Protocol/1.1: Model and Semantics. M. Sweet, I. McDonald. January 2017. (Format: TXT, HTML) (Obsoletes RFC2911, RFC3381, RFC3382) (Also STD0092) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8011) 8012 Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs). N. Akiya, G. Swallow, C. Pignataro, A. Malis, S. Aldrin. November 2016. (Format: TXT, HTML) (Updates RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8012) 8013 Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB). D. Joachimpillai, J. Hadi Salim. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8013) 8014 An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3). D. Black, J. Hudson, L. Kreeger, M. Lasserre, T. Narten. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8014) 8015 RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics. V. Singh, C. Perkins, A. Clark, R. Huang. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8015) 8016 Mobility with Traversal Using Relays around NAT (TURN). T. Reddy, D. Wing, P. Patil, P. Martinsen. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8016) 8017 PKCS #1: RSA Cryptography Specifications Version 2.2. K. Moriarty, Ed., B. Kaliski, J. Jonsson, A. Rusch. November 2016. (Format: TXT, HTML) (Obsoletes RFC3447) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8017) 8018 PKCS #5: Password-Based Cryptography Specification Version 2.1. K. Moriarty, Ed., B. Kaliski, A. Rusch. January 2017. (Format: TXT, HTML) (Obsoletes RFC2898) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8018) 8019 Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks. Y. Nir, V. Smyslov. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8019) 8020 NXDOMAIN: There Really Is Nothing Underneath. S. Bortzmeyer, S. Huque. November 2016. (Format: TXT, HTML) (Updates RFC1034, RFC2308) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8020) 8021 Generation of IPv6 Atomic Fragments Considered Harmful. F. Gont, W. Liu, T. Anderson. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8021) 8022 A YANG Data Model for Routing Management. L. Lhotka, A. Lindem. November 2016. (Format: TXT, HTML) (Obsoleted by RFC8349) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8022) 8023 Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions. M. Thomas, A. Mankin, L. Zhang. November 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8023) 8024 Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS. Y. Jiang, Ed., Y. Luo, E. Mallette, Ed., Y. Shen, W. Cheng. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8024) 8025 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch. P. Thubert, Ed., R. Cragie. November 2016. (Format: TXT, HTML) (Updates RFC4944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8025) 8026 Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism. M. Boucadair, I. Farrer. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8026) 8027 DNSSEC Roadblock Avoidance. W. Hardaker, O. Gudmundsson, S. Krishnaswamy. November 2016. (Format: TXT, HTML) (Also BCP0207) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8027) 8028 First-Hop Router Selection by Hosts in a Multi-Prefix Network. F. Baker, B. Carpenter. November 2016. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8028) 8029 Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures. K. Kompella, G. Swallow, C. Pignataro, Ed., N. Kumar, S. Aldrin, M. Chen. March 2017. (Format: TXT, HTML) (Obsoletes RFC4379, RFC6424, RFC6829, RFC7537) (Updates RFC1122) (Updated by RFC8611, RFC9041) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8029) 8030 Generic Event Delivery Using HTTP Push. M. Thomson, E. Damaggio, B. Raymor, Ed.. December 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8030) 8031 Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement. Y. Nir, S. Josefsson. December 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8031) 8032 Edwards-Curve Digital Signature Algorithm (EdDSA). S. Josefsson, I. Liusvaara. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8032) 8033 Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem. R. Pan, P. Natarajan, F. Baker, G. White. February 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8033) 8034 Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced (PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems. G. White, R. Pan. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8034) 8035 Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing. C. Holmberg. November 2016. (Format: TXT, HTML) (Updates RFC5761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8035) 8036 Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks. N. Cam-Winget, Ed., J. Hui, D. Popa. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8036) 8037 CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE). I. Liusvaara. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8037) 8038 Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol. P. Aitken, Ed., B. Claise, S. B S, C. McDowall, J. Schoenwaelder. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8038) 8039 Multipath Time Synchronization. A. Shpiner, R. Tse, C. Schelp, T. Mizrahi. December 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8039) 8040 RESTCONF Protocol. A. Bierman, M. Bjorklund, K. Watsen. January 2017. (Format: TXT, HTML) (Updated by RFC8527) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8040) 8041 Use Cases and Operational Experience with Multipath TCP. O. Bonaventure, C. Paasch, G. Detal. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8041) 8042 OSPF Two-Part Metric. Z. Zhang, L. Wang, A. Lindem. December 2016. (Format: TXT, HTML) (Updates RFC2328) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8042) 8043 Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space. B. Sarikaya, M. Boucadair. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8043) 8044 Data Types in RADIUS. A. DeKok. January 2017. (Format: TXT, HTML) (Updates RFC2865, RFC3162, RFC4072, RFC6158, RFC6572, RFC7268) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8044) 8045 RADIUS Extensions for IP Port Configuration and Reporting. D. Cheng, J. Korhonen, M. Boucadair, S. Sivakumar. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8045) 8046 Host Mobility with the Host Identity Protocol. T. Henderson, Ed., C. Vogt, J. Arkko. February 2017. (Format: TXT, HTML) (Obsoletes RFC5206) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8046) 8047 Host Multihoming with the Host Identity Protocol. T. Henderson, Ed., C. Vogt, J. Arkko. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8047) 8048 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence. P. Saint-Andre. December 2016. (Format: TXT, HTML) (Obsoletes RFC7248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8048) 8049 YANG Data Model for L3VPN Service Delivery. S. Litkowski, L. Tomotaki, K. Ogaki. February 2017. (Format: TXT, HTML) (Obsoleted by RFC8299) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8049) 8050 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions. C. Petrie, T. King. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8050) 8051 Applicability of a Stateful Path Computation Element (PCE). X. Zhang, Ed., I. Minei, Ed.. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8051) 8052 Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services. B. Weis, M. Seewald, H. Falk. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8052) 8053 HTTP Authentication Extensions for Interactive Clients. Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. January 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8053) 8054 Network News Transfer Protocol (NNTP) Extension for Compression. K. Murchison, J. Elie. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8054) 8055 Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm. C. Holmberg, Y. Jiang. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8055) 8056 Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping. J. Gould. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8056) 8057 Uniform Resource Name (URN) Namespaces for Broadband Forum. B. Stark, D. Sinicrope, W. Lupton. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8057) 8058 Signaling One-Click Functionality for List Email Headers. J. Levine, T. Herkula. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8058) 8059 PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments. J. Arango, S. Venaas, I. Kouvelas, D. Farinacci. January 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8059) 8060 LISP Canonical Address Format (LCAF). D. Farinacci, D. Meyer, J. Snijders. February 2017. (Format: TXT, HTML) (Updated by RFC9306) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8060) 8061 Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality. D. Farinacci, B. Weis. February 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8061) 8062 Anonymity Support for Kerberos. L. Zhu, P. Leach, S. Hartman, S. Emery, Ed.. February 2017. (Format: TXT, HTML) (Obsoletes RFC6112) (Updates RFC4120, RFC4121, RFC4556) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8062) 8063 Key Relay Mapping for the Extensible Provisioning Protocol. H.W. Ribbers, M.W. Groeneweg, R. Gieben, A.L.J. Verschuren. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8063) 8064 Recommendation on Stable IPv6 Interface Identifiers. F. Gont, A. Cooper, D. Thaler, W. Liu. February 2017. (Format: TXT, HTML) (Updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC5072, RFC5121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8064) 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms. D. Thaler. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8065) 8066 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines. S. Chakrabarti, G. Montenegro, R. Droms, J. Woodyatt. February 2017. (Format: TXT, HTML) (Updates RFC4944, RFC6282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8066) 8067 Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level. B. Leiba. January 2017. (Format: TXT, HTML) (Updates RFC3967) (Also BCP0097) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8067) 8068 Session Initiation Protocol (SIP) Recording Call Flows. R. Ravindranath, P. Ravindran, P. Kyzivat. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8068) 8069 URN Namespace for IEEE. A. Thomas. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8069) 8070 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension. M. Short, Ed., S. Moore, P. Miller. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8070) 8071 NETCONF Call Home and RESTCONF Call Home. K. Watsen. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8071) 8072 YANG Patch Media Type. A. Bierman, M. Bjorklund, K. Watsen. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8072) 8073 Coordinating Attack Response at Internet Scale (CARIS) Workshop Report. K. Moriarty, M. Ford. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8073) 8074 Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario. J. Bi, G. Yao, J. Halpern, E. Levy-Abegnoli, Ed.. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8074) 8075 Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP). A. Castellani, S. Loreto, A. Rahman, T. Fossati, E. Dijk. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8075) 8076 A Usage for Shared Resources in RELOAD (ShaRe). A. Knauf, T. Schmidt, Ed., G. Hege, M. Waehlisch. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8076) 8077 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP). L. Martini, Ed., G. Heron, Ed.. February 2017. (Format: TXT, HTML) (Obsoletes RFC4447, RFC6723) (Also STD0084) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8077) 8078 Managing DS Records from the Parent via CDS/CDNSKEY. O. Gudmundsson, P. Wouters. March 2017. (Format: TXT, HTML) (Updates RFC7344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8078) 8079 Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs). L. Miniero, S. Garcia Murillo, V. Pascual. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8079) 8080 Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC. O. Sury, R. Edmonds. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8080) 8081 The "font" Top-Level Media Type. C. Lilley. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8081) 8082 Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs. S. Wenger, J. Lennox, B. Burman, M. Westerlund. March 2017. (Format: TXT, HTML) (Updates RFC5104) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8082) 8083 Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions. C. Perkins, V. Singh. March 2017. (Format: TXT, HTML) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8083) 8084 Network Transport Circuit Breakers. G. Fairhurst. March 2017. (Format: TXT, HTML) (Also BCP0208) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8084) 8085 UDP Usage Guidelines. L. Eggert, G. Fairhurst, G. Shepherd. March 2017. (Format: TXT, HTML) (Obsoletes RFC5405) (Updated by RFC8899) (Also BCP0145) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8085) 8086 GRE-in-UDP Encapsulation. L. Yong, Ed., E. Crabbe, X. Xu, T. Herbert. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8086) 8087 The Benefits of Using Explicit Congestion Notification (ECN). G. Fairhurst, M. Welzl. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8087) 8088 How to Write an RTP Payload Format. M. Westerlund. May 2017. (Format: TXT, HTML) (Updates RFC2736) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8088) 8089 The "file" URI Scheme. M. Kerwin. February 2017. (Format: TXT, HTML) (Updates RFC1738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8089) 8090 Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG). R. Housley. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8090) 8091 A Media Type Structured Syntax Suffix for JSON Text Sequences. E. Wilde. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8091) 8092 BGP Large Communities Attribute. J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8092) 8093 Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243. J. Snijders. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8093) 8094 DNS over Datagram Transport Layer Security (DTLS). T. Reddy, D. Wing, P. Patil. February 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8094) 8095 Services Provided by IETF Transport Protocols and Congestion Control Mechanisms. G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed.. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8095) 8096 The IPv6-Specific MIB Modules Are Obsolete. B. Fenner. April 2017. (Format: TXT, HTML) (Obsoletes RFC2452, RFC2454, RFC2465, RFC2466) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8096) 8097 BGP Prefix Origin Validation State Extended Community. P. Mohapatra, K. Patel, J. Scudder, D. Ward, R. Bush. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8097) 8098 Message Disposition Notification. T. Hansen, Ed., A. Melnikov, Ed.. February 2017. (Format: TXT, HTML) (Obsoletes RFC3798) (Updates RFC2046, RFC3461) (Also STD0085) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8098) 8099 OSPF Topology-Transparent Zone. H. Chen, R. Li, A. Retana, Y. Yang, Z. Liu. February 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8099) 8100 Diffserv-Interconnection Classes and Practice. R. Geib, Ed., D. Black. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8100) 8101 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk Service. C. Holmberg, J. Axell. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8101) 8102 Remote-LFA Node Protection and Manageability. P. Sarkar, Ed., S. Hegde, C. Bowers, H. Gredler, S. Litkowski. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8102) 8103 Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). R. Housley. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8103) 8104 Pseudowire (PW) Endpoint Fast Failure Protection. Y. Shen, R. Aggarwal, W. Henderickx, Y. Jiang. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8104) 8105 Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE). P. Mariager, J. Petersen, Ed., Z. Shelby, M. Van de Logt, D. Barthel. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8105) 8106 IPv6 Router Advertisement Options for DNS Configuration. J. Jeong, S. Park, L. Beloeil, S. Madanapalli. March 2017. (Format: TXT, HTML) (Obsoletes RFC6106) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8106) 8107 Advertising Digital Identifier (Ad-ID) URN Namespace Definition. J. Wold. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8107) 8108 Sending Multiple RTP Streams in a Single RTP Session. J. Lennox, M. Westerlund, Q. Wu, C. Perkins. March 2017. (Format: TXT, HTML) (Updates RFC3550, RFC4585) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8108) 8109 Initializing a DNS Resolver with Priming Queries. P. Koch, M. Larson, P. Hoffman. March 2017. (Format: TXT, HTML) (Also BCP0209) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8109) 8110 Opportunistic Wireless Encryption. D. Harkins, Ed., W. Kumari, Ed.. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8110) 8111 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT). V. Fuller, D. Lewis, V. Ermagan, A. Jain, A. Smirnov. May 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8111) 8112 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG). D. Farinacci, A. Jain, I. Kouvelas, D. Lewis. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8112) 8113 Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations. M. Boucadair, C. Jacquenet. March 2017. (Format: TXT, HTML) (Obsoleted by RFC9304) (Updates RFC6830) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8113) 8114 Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network. M. Boucadair, C. Qin, C. Jacquenet, Y. Lee, Q. Wang. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8114) 8115 DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes. M. Boucadair, J. Qin, T. Tsou, X. Deng. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8115) 8116 Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2). T. Clausen, U. Herberg, J. Yi. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8116) 8117 Current Hostname Practice Considered Harmful. C. Huitema, D. Thaler, R. Winter. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8117) 8118 The application/pdf Media Type. M. Hardy, L. Masinter, D. Markovic, D. Johnson, M. Bailey. March 2017. (Format: TXT, HTML) (Obsoletes RFC3778) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8118) 8119 SIP "cause" URI Parameter for Service Number Translation. M. Mohali, M. Barnes. March 2017. (Format: TXT, HTML) (Updates RFC4458) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8119) 8120 Mutual Authentication Protocol for HTTP. Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. April 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8120) 8121 Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3). Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. April 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8121) 8122 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP). J. Lennox, C. Holmberg. March 2017. (Format: TXT, HTML) (Obsoletes RFC4572) (Updated by RFC8844) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8122) 8123 Requirements for Marking SIP Messages to be Logged. P. Dawes, C. Arunachalam. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8123) 8124 The Session Description Protocol (SDP) WebSocket Connection URI Attribute. R. Ravindranath, G. Salgueiro. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8124) 8125 Requirements for Password-Authenticated Key Agreement (PAKE) Schemes. J. Schmidt. April 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8125) 8126 Guidelines for Writing an IANA Considerations Section in RFCs. M. Cotton, B. Leiba, T. Narten. June 2017. (Format: TXT, HTML) (Obsoletes RFC5226) (Also BCP0026) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8126) 8127 Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor. D. Patki, S. Gundavelli, J. Lee, Q. Fu, L. Bertz. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8127) 8128 IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee. C. Morgan. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8128) 8129 Authentication Indicator in Kerberos Tickets. A. Jain, N. Kinder, N. McCallum. March 2017. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8129) 8130 RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec. V. Demjanenko, D. Satterlee. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8130) 8131 RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing. X. Zhang, H. Zheng, Ed., R. Gandhi, Ed., Z. Ali, P. Brzozowski. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8131) 8132 PATCH and FETCH Methods for the Constrained Application Protocol (CoAP). P. van der Stok, C. Bormann, A. Sehgal. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8132) 8133 The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol. S. Smyshlyaev, Ed., E. Alekseev, I. Oshkin, V. Popov. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8133) 8134 Management Incident Lightweight Exchange (MILE) Implementation Report. C. Inacio, D. Miyamoto. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8134) 8135 Complex Addressing in IPv6. M. Danielson, M. Nilsson. 1 April 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8135) 8136 Additional Transition Functionality for IPv6. B. Carpenter, R. Hinden. 1 April 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8136) 8137 IEEE 802.15.4 Information Element for the IETF. T. Kivinen, P. Kinney. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8137) 8138 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header. P. Thubert, Ed., C. Bormann, L. Toutain, R. Cragie. April 2017. (Format: TXT, HTML) (Updated by RFC9008, RFC9035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8138) 8139 Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders. D. Eastlake 3rd, Y. Li, M. Umair, A. Banerjee, F. Hu. June 2017. (Format: TXT, HTML) (Obsoletes RFC6439) (Updates RFC6325, RFC7177) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8139) 8140 The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character. A. Farrel. 1 April 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8140) 8141 Uniform Resource Names (URNs). P. Saint-Andre, J. Klensin. April 2017. (Format: TXT, HTML) (Obsoletes RFC2141, RFC3406) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8141) 8142 GeoJSON Text Sequences. S. Gillies. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8142) 8143 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP). J. Elie. April 2017. (Format: TXT, HTML) (Updates RFC4642) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8143) 8144 Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV). K. Murchison. April 2017. (Format: TXT, HTML) (Updates RFC7240) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8144) 8145 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC). D. Wessels, W. Kumari, P. Hoffman. April 2017. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8145) 8146 Adding Support for Salted Password Databases to EAP-pwd. D. Harkins. April 2017. (Format: TXT, HTML) (Updates RFC5931) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8146) 8147 Next-Generation Pan-European eCall. R. Gellens, H. Tschofenig. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8147) 8148 Next-Generation Vehicle-Initiated Emergency Calls. R. Gellens, B. Rosen, H. Tschofenig. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8148) 8149 RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs). T. Saad, Ed., R. Gandhi, Ed., Z. Ali, R. Venator, Y. Kamite. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8149) 8150 MPLS Transport Profile Linear Protection MIB. S. Kingston Smiler, M. Venkatesan, D. King, S. Aldrin, J. Ryoo. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8150) 8151 Use Cases for Data Center Network Virtualization Overlay Networks. L. Yong, L. Dunbar, M. Toy, A. Isaac, V. Manral. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8151) 8152 CBOR Object Signing and Encryption (COSE). J. Schaad. July 2017. (Format: TXT, HTML) (Obsoleted by RFC9052, RFC9053) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8152) 8153 Digital Preservation Considerations for the RFC Series. H. Flanagan. April 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8153) 8154 Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout. C. Hellwig. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8154) 8155 Traversal Using Relays around NAT (TURN) Server Auto Discovery. P. Patil, T. Reddy, D. Wing. April 2017. (Format: TXT, HTML) (Updates RFC5766) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8155) 8156 DHCPv6 Failover Protocol. T. Mrugalski, K. Kinnear. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8156) 8157 Huawei's GRE Tunnel Bonding Protocol. N. Leymann, C. Heidemann, M. Zhang, B. Sarikaya, M. Cullen. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8157) 8158 IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events. S. Sivakumar, R. Penno. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8158) 8159 Keyed IPv6 Tunnel. M. Konstantynowicz, Ed., G. Heron, Ed., R. Schatzmayr, W. Henderickx. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8159) 8160 IUTF8 Terminal Mode in Secure Shell (SSH). S. Tatham, D. Tucker. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8160) 8161 Benchmarking the Neighbor Discovery Protocol. W. Cerveny, R. Bonica, R. Thomas. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8161) 8162 Using Secure DNS to Associate Certificates with Domain Names for S/MIME. P. Hoffman, J. Schlyter. May 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8162) 8163 Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks. K. Lynn, Ed., J. Martocci, C. Neilson, S. Donaldson. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8163) 8164 Opportunistic Security for HTTP/2. M. Nottingham, M. Thomson. May 2017. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC8164) 8165 Design Considerations for Metadata Insertion. T. Hardie. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8165) 8166 Remote Direct Memory Access Transport for Remote Procedure Call Version 1. C. Lever, Ed., W. Simpson, T. Talpey. June 2017. (Format: TXT, HTML) (Obsoletes RFC5666) (Updated by RFC8797) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8166) 8167 Bidirectional Remote Procedure Call on RPC-over-RDMA Transports. C. Lever. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8167) 8168 DHCPv6 Prefix-Length Hint Issues. T. Li, C. Liu, Y. Cui. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8168) 8169 Residence Time Measurement in MPLS Networks. G. Mirsky, S. Ruffini, E. Gray, J. Drake, S. Bryant, A. Vainshtein. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8169) 8170 Planning for Protocol Adoption and Subsequent Transitions. D. Thaler, Ed.. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8170) 8171 Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms. D. Eastlake 3rd, L. Dunbar, R. Perlman, Y. Li. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8171) 8172 Considerations for Benchmarking Virtual Network Functions and Their Infrastructure. A. Morton. July 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8172) 8173 Precision Time Protocol Version 2 (PTPv2) Management Information Base. V. Shankarkumar, L. Montini, T. Frost, G. Dowd. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8173) 8174 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. May 2017. (Format: TXT, HTML) (Updates RFC2119) (Also BCP0014) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8174) 8175 Dynamic Link Exchange Protocol (DLEP). S. Ratliff, S. Jury, D. Satterwhite, R. Taylor, B. Berry. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8175) 8176 Authentication Method Reference Values. M. Jones, P. Hunt, A. Nadalin. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8176) 8177 YANG Data Model for Key Chains. A. Lindem, Ed., Y. Qu, D. Yeung, I. Chen, J. Zhang. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8177) 8178 Rules for NFSv4 Extensions and Minor Versions. D. Noveck. July 2017. (Format: TXT, HTML) (Updates RFC5661, RFC7862) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8178) 8179 Intellectual Property Rights in IETF Technology. S. Bradner, J. Contreras. May 2017. (Format: TXT, HTML) (Obsoletes RFC3979, RFC4879) (Updates RFC2026) (Also BCP0079) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8179) 8180 Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration. X. Vilajosana, Ed., K. Pister, T. Watteyne. May 2017. (Format: TXT, HTML) (Also BCP0210) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8180) 8181 A Publication Protocol for the Resource Public Key Infrastructure (RPKI). S. Weiler, A. Sonalker, R. Austein. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8181) 8182 The RPKI Repository Delta Protocol (RRDP). T. Bruijnzeels, O. Muravskiy, B. Weber, R. Austein. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8182) 8183 An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services. R. Austein. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8183) 8184 Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires. W. Cheng, L. Wang, H. Li, S. Davari, J. Dong. June 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8184) 8185 Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection. W. Cheng, L. Wang, H. Li, J. Dong, A. D'Alessandro. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8185) 8186 Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP). G. Mirsky, I. Meilik. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8186) 8187 Indicating Character Encoding and Language for HTTP Header Field Parameters. J. Reschke. September 2017. (Format: TXT, HTML) (Obsoletes RFC5987) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8187) 8188 Encrypted Content-Encoding for HTTP. M. Thomson. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8188) 8189 Multi-Cost Application-Layer Traffic Optimization (ALTO). S. Randriamasy, W. Roome, N. Schwan. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8189) 8190 Updates to the Special-Purpose IP Address Registries. R. Bonica, M. Cotton, B. Haberman, L. Vegoda. June 2017. (Format: TXT, HTML) (Updates RFC6890) (Also BCP0153) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8190) 8191 Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6). Z. Yan, J. Lee, X. Lee. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8191) 8192 Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases. S. Hares, D. Lopez, M. Zarny, C. Jacquenet, R. Kumar, J. Jeong. July 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8192) 8193 Information Model for Large-Scale Measurement Platforms (LMAPs). T. Burbridge, P. Eardley, M. Bagnulo, J. Schoenwaelder. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8193) 8194 A YANG Data Model for LMAP Measurement Agents. J. Schoenwaelder, V. Bajpai. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8194) 8195 Use of BGP Large Communities. J. Snijders, J. Heasley, M. Schmidt. June 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8195) 8196 IS-IS Autoconfiguration. B. Liu, Ed., L. Ginsberg, B. Decraene, I. Farrer, M. Abrahamsson. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8196) 8197 A SIP Response Code for Unwanted Calls. H. Schulzrinne. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8197) 8198 Aggressive Use of DNSSEC-Validated Cache. K. Fujiwara, A. Kato, W. Kumari. July 2017. (Format: TXT, HTML) (Updates RFC4035) (Updated by RFC9077) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8198) 8199 YANG Module Classification. D. Bogdanovic, B. Claise, C. Moberg. July 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8199) 8200 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. July 2017. (Format: TXT, HTML) (Obsoletes RFC2460) (Also STD0086) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8200) 8201 Path MTU Discovery for IP version 6. J. McCann, S. Deering, J. Mogul, R. Hinden, Ed.. July 2017. (Format: TXT, HTML) (Obsoletes RFC1981) (Also STD0087) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8201) 8202 IS-IS Multi-Instance. L. Ginsberg, S. Previdi, W. Henderickx. June 2017. (Format: TXT, HTML) (Obsoletes RFC6822) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8202) 8203 BGP Administrative Shutdown Communication. J. Snijders, J. Heitz, J. Scudder. July 2017. (Format: TXT, HTML) (Obsoleted by RFC9003) (Updates RFC4486) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8203) 8204 Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV). M. Tahhan, B. O'Mahony, A. Morton. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8204) 8205 BGPsec Protocol Specification. M. Lepinski, Ed., K. Sriram, Ed.. September 2017. (Format: TXT, HTML) (Updated by RFC8206) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8205) 8206 BGPsec Considerations for Autonomous System (AS) Migration. W. George, S. Murphy. September 2017. (Format: TXT, HTML) (Updates RFC8205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8206) 8207 BGPsec Operational Considerations. R. Bush. September 2017. (Format: TXT, HTML) (Also BCP0211) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8207) 8208 BGPsec Algorithms, Key Formats, and Signature Formats. S. Turner, O. Borchert. September 2017. (Format: TXT, HTML) (Obsoleted by RFC8608) (Updates RFC7935) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8208) 8209 A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests. M. Reynolds, S. Turner, S. Kent. September 2017. (Format: TXT, HTML) (Updates RFC6487) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8209) 8210 The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1. R. Bush, R. Austein. September 2017. (Format: TXT, HTML) (Updates RFC6810) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8210) 8211 Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI). S. Kent, D. Ma. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8211) 8212 Default External BGP (EBGP) Route Propagation Behavior without Policies. J. Mauch, J. Snijders, G. Hankins. July 2017. (Format: TXT, HTML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8212) 8213 Security of Messages Exchanged between Servers and Relay Agents. B. Volz, Y. Pal. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8213) 8214 Virtual Private Wire Service Support in Ethernet VPN. S. Boutros, A. Sajassi, S. Salam, J. Drake, J. Rabadan. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8214) 8215 Local-Use IPv4/IPv6 Translation Prefix. T. Anderson. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8215) 8216 HTTP Live Streaming. R. Pantos, Ed., W. May. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8216) 8217 Clarifications for When to Use the name-addr Production in SIP Messages. R. Sparks. August 2017. (Format: TXT, HTML) (Updates RFC3261, RFC3325, RFC3515, RFC3892, RFC4508, RFC5002, RFC5318, RFC5360, RFC5502) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8217) 8218 Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2). J. Yi, B. Parrein. August 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8218) 8219 Benchmarking Methodology for IPv6 Transition Technologies. M. Georgescu, L. Pislaru, G. Lencse. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8219) 8220 Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS). O. Dornon, J. Kotalwar, V. Hemige, R. Qiu, Z. Zhang. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8220) 8221 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH). P. Wouters, D. Migault, J. Mattsson, Y. Nir, T. Kivinen. October 2017. (Format: TXT, HTML) (Obsoletes RFC7321) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8221) 8222 Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery. A. Sullivan. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8222) 8223 Application-Aware Targeted LDP. S. Esale, R. Torvi, L. Jalil, U. Chunduri, K. Raza. August 2017. (Format: TXT, HTML) (Updates RFC7473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8223) 8224 Authenticated Identity Management in the Session Initiation Protocol (SIP). J. Peterson, C. Jennings, E. Rescorla, C. Wendt. February 2018. (Format: TXT, HTML) (Obsoletes RFC4474) (Updated by RFC8946) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8224) 8225 PASSporT: Personal Assertion Token. C. Wendt, J. Peterson. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8225) 8226 Secure Telephone Identity Credentials: Certificates. J. Peterson, S. Turner. February 2018. (Format: TXT, HTML) (Updated by RFC9118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8226) 8227 MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology. W. Cheng, L. Wang, H. Li, H. van Helvoort, J. Dong. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8227) 8228 Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels. A. Freytag. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8228) 8229 TCP Encapsulation of IKE and IPsec Packets. T. Pauly, S. Touati, R. Mantha. August 2017. (Format: TXT, HTML) (Obsoleted by RFC9329) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8229) 8230 Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages. M. Jones. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8230) 8231 Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE. E. Crabbe, I. Minei, J. Medved, R. Varga. September 2017. (Format: TXT, HTML) (Updated by RFC8786, RFC9353) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8231) 8232 Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE. E. Crabbe, I. Minei, J. Medved, R. Varga, X. Zhang, D. Dhody. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8232) 8233 Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs). D. Dhody, Q. Wu, V. Manral, Z. Ali, K. Kumaki. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8233) 8234 Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode. J. Ryoo, T. Cheung, H. van Helvoort, I. Busi, G. Wen. August 2017. (Format: TXT, HTML) (Updates RFC7271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8234) 8235 Schnorr Non-interactive Zero-Knowledge Proof. F. Hao, Ed.. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8235) 8236 J-PAKE: Password-Authenticated Key Exchange by Juggling. F. Hao, Ed.. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8236) 8237 MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs. L. Martini, G. Swallow, E. Bellagamba. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8237) 8238 Data Center Benchmarking Terminology. L. Avramov, J. Rapp. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8238) 8239 Data Center Benchmarking Methodology. L. Avramov, J. Rapp. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8239) 8240 Report from the Internet of Things Software Update (IoTSU) Workshop 2016. H. Tschofenig, S. Farrell. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8240) 8241 Interface to the Routing System (I2RS) Security-Related Requirements. S. Hares, D. Migault, J. Halpern. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8241) 8242 Interface to the Routing System (I2RS) Ephemeral State Requirements. J. Haas, S. Hares. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8242) 8243 Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL). R. Perlman, D. Eastlake 3rd, M. Zhang, A. Ghanwani, H. Zhai. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8243) 8244 Special-Use Domain Names Problem Statement. T. Lemon, R. Droms, W. Kumari. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8244) 8245 Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444. T. Clausen, C. Dearlove, U. Herberg, H. Rogge. October 2017. (Format: TXT, HTML) (Updates RFC5444) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8245) 8246 HTTP Immutable Responses. P. McManus. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8246) 8247 Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2). Y. Nir, T. Kivinen, P. Wouters, D. Migault. September 2017. (Format: TXT, HTML) (Obsoletes RFC4307) (Updates RFC7296) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8247) 8248 Security Automation and Continuous Monitoring (SACM) Requirements. N. Cam-Winget, L. Lorenzin. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8248) 8249 Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation. M. Zhang, X. Zhang, D. Eastlake 3rd, R. Perlman, S. Chatterjee. September 2017. (Format: TXT, HTML) (Updates RFC6325, RFC7177, RFC7780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8249) 8250 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option. N. Elkins, R. Hamilton, M. Ackermann. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8250) 8251 Updates to the Opus Audio Codec. JM. Valin, K. Vos. October 2017. (Format: TXT, HTML) (Updates RFC6716) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8251) 8252 OAuth 2.0 for Native Apps. W. Denniss, J. Bradley. October 2017. (Format: TXT, HTML) (Updates RFC6749) (Also BCP0212) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8252) 8253 PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP). D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody. October 2017. (Format: TXT, HTML) (Updates RFC5440) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8253) 8254 Uniform Resource Name (URN) Namespace Registration Transition. J. Klensin, J. Hakala. October 2017. (Format: TXT, HTML) (Obsoletes RFC3044, RFC3187) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8254) 8255 Multiple Language Content Type. N. Tomkinson, N. Borenstein. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8255) 8256 Requirements for Hitless MPLS Path Segment Monitoring. A. D'Alessandro, L. Andersson, S. Ueno, K. Arai, Y. Koike. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8256) 8257 Data Center TCP (DCTCP): TCP Congestion Control for Data Centers. S. Bensley, D. Thaler, P. Balasubramanian, L. Eggert, G. Judd. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8257) 8258 Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI). D. Ceccarelli, L. Berger. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8258) 8259 The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. December 2017. (Format: TXT, HTML) (Obsoletes RFC7159) (Also STD0090) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8259) 8260 Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol. R. Stewart, M. Tuexen, S. Loreto, R. Seggelmann. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8260) 8261 Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets. M. Tuexen, R. Stewart, R. Jesup, S. Loreto. November 2017. (Format: TXT, HTML) (Updated by RFC8899, RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8261) 8262 Content-ID Header Field in the Session Initiation Protocol (SIP). C. Holmberg, I. Sedlacek. October 2017. (Format: TXT, HTML) (Updates RFC5621, RFC5368, RFC6442) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8262) 8263 Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message. B. Weis, U. Mangla, T. Karl, N. Maheshwari. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8263) 8264 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols. P. Saint-Andre, M. Blanchet. October 2017. (Format: TXT, HTML) (Obsoletes RFC7564) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8264) 8265 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords. P. Saint-Andre, A. Melnikov. October 2017. (Format: TXT, HTML) (Obsoletes RFC7613) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8265) 8266 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames. P. Saint-Andre. October 2017. (Format: TXT, HTML) (Obsoletes RFC7700) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8266) 8267 Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1. C. Lever. October 2017. (Format: TXT, HTML) (Obsoletes RFC5667) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8267) 8268 More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH). M. Baushke. December 2017. (Format: TXT, HTML) (Updates RFC4250, RFC4253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8268) 8269 The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP). W. Kim, J. Lee, J. Park, D. Kwon, D. Kim. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8269) 8270 Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits. L. Velvindron, M. Baushke. December 2017. (Format: TXT, HTML) (Updates RFC4419) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8270) 8271 Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs). M. Taillon, T. Saad, Ed., R. Gandhi, Ed., Z. Ali, M. Bhatia. October 2017. (Format: TXT, HTML) (Updates RFC4090) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8271) 8272 TinyIPFIX for Smart Meters in Constrained Networks. C. Schmitt, B. Stiller, B. Trammell. November 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8272) 8273 Unique IPv6 Prefix per Host. J. Brzozowski, G. Van de Velde. December 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8273) 8274 Incident Object Description Exchange Format Usage Guidance. P. Kampanakis, M. Suzuki. November 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8274) 8275 Allowing Inheritable NFSv4 Access Control Entries to Override the Umask. J. Fields, A. Gruenbacher. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8275) 8276 File System Extended Attributes in NFSv4. M. Naik, M. Eshel. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8276) 8277 Using BGP to Bind MPLS Labels to Address Prefixes. E. Rosen. October 2017. (Format: TXT, HTML) (Obsoletes RFC3107) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8277) 8278 Mobile Access Gateway (MAG) Multipath Options. P. Seite, A. Yegin, S. Gundavelli. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8278) 8279 Multicast Using Bit Index Explicit Replication (BIER). IJ. Wijnands, Ed., E. Rosen, Ed., A. Dolganow, T. Przygienda, S. Aldrin. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8279) 8280 Research into Human Rights Protocol Considerations. N. ten Oever, C. Cath. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8280) 8281 Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model. E. Crabbe, I. Minei, S. Sivabalan, R. Varga. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8281) 8282 Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering. E. Oki, T. Takeda, A. Farrel, F. Zhang. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8282) 8283 An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control. A. Farrel, Ed., Q. Zhao, Ed., Z. Li, C. Zhou. December 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8283) 8284 Lightweight Directory Access Protocol (LDAP) Schema for Supporting the Extensible Messaging and Presence Protocol (XMPP) in White Pages. S. Kille. November 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8284) 8285 A General Mechanism for RTP Header Extensions. D. Singer, H. Desineni, R. Even, Ed.. October 2017. (Format: TXT, HTML) (Obsoletes RFC5285) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8285) 8286 RTP/RTCP Extension for RTP Splicing Notification. J. Xia, R. Even, R. Huang, L. Deng. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8286) 8287 Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes. N. Kumar, Ed., C. Pignataro, Ed., G. Swallow, N. Akiya, S. Kini, M. Chen. December 2017. (Format: TXT, HTML) (Updated by RFC8690, RFC9214) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8287) 8288 Web Linking. M. Nottingham. October 2017. (Format: TXT, HTML) (Obsoletes RFC5988) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8288) 8289 Controlled Delay Active Queue Management. K. Nichols, V. Jacobson, A. McGregor, Ed., J. Iyengar, Ed.. January 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8289) 8290 The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm. T. Hoeiland-Joergensen, P. McKenney, D. Taht, J. Gettys, E. Dumazet. January 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8290) 8291 Message Encryption for Web Push. M. Thomson. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8291) 8292 Voluntary Application Server Identification (VAPID) for Web Push. M. Thomson, P. Beverloo. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8292) 8293 A Framework for Multicast in Network Virtualization over Layer 3. A. Ghanwani, L. Dunbar, M. McBride, V. Bannai, R. Krishnan. January 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8293) 8294 Common YANG Data Types for the Routing Area. X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8294) 8295 EST (Enrollment over Secure Transport) Extensions. S. Turner. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8295) 8296 Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks. IJ. Wijnands, Ed., E. Rosen, Ed., A. Dolganow, J. Tantsura, S. Aldrin, I. Meilik. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8296) 8297 An HTTP Status Code for Indicating Hints. K. Oku. December 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8297) 8298 Self-Clocked Rate Adaptation for Multimedia. I. Johansson, Z. Sarker. December 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8298) 8299 YANG Data Model for L3VPN Service Delivery. Q. Wu, Ed., S. Litkowski, L. Tomotaki, K. Ogaki. January 2018. (Format: TXT, HTML) (Obsoletes RFC8049) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8299) 8300 Network Service Header (NSH). P. Quinn, Ed., U. Elzur, Ed., C. Pignataro, Ed.. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8300) 8301 Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM). S. Kitterman. January 2018. (Format: TXT, HTML) (Updates RFC6376) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8301) 8302 Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization. Y. Li, D. Eastlake 3rd, L. Dunbar, R. Perlman, M. Umair. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8302) 8303 On the Usage of Transport Features Provided by IETF Transport Protocols. M. Welzl, M. Tuexen, N. Khademi. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8303) 8304 Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite). G. Fairhurst, T. Jones. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8304) 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency. D. Schinazi, T. Pauly. December 2017. (Format: TXT, HTML) (Obsoletes RFC6555) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8305) 8306 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths. Q. Zhao, D. Dhody, Ed., R. Palleti, D. King. November 2017. (Format: TXT, HTML) (Obsoletes RFC6006) (Updated by RFC9353) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8306) 8307 Well-Known URIs for the WebSocket Protocol. C. Bormann. January 2018. (Format: TXT, HTML) (Updates RFC6455) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8307) 8308 Extension Negotiation in the Secure Shell (SSH) Protocol. D. Bider. March 2018. (Format: TXT, HTML) (Updates RFC4251, RFC4252, RFC4253, RFC4254) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8308) 8309 Service Models Explained. Q. Wu, W. Liu, A. Farrel. January 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8309) 8310 Usage Profiles for DNS over TLS and DNS over DTLS. S. Dickinson, D. Gillmor, T. Reddy. March 2018. (Format: TXT, HTML) (Updates RFC7858) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8310) 8311 Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation. D. Black. January 2018. (Format: TXT, HTML) (Updates RFC3168, RFC4341, RFC4342, RFC5622, RFC6679) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8311) 8312 CUBIC for Fast Long-Distance Networks. I. Rhee, L. Xu, S. Ha, A. Zimmermann, L. Eggert, R. Scheffenegger. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8312) 8313 Use of Multicast across Inter-domain Peering Points. P. Tarapore, Ed., R. Sayko, G. Shepherd, T. Eckert, Ed., R. Krishnan. January 2018. (Format: TXT, HTML) (Also BCP0213) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8313) 8314 Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. K. Moore, C. Newman. January 2018. (Format: TXT, HTML) (Updates RFC1939, RFC2595, RFC3501, RFC5068, RFC6186, RFC6409) (Updated by RFC8997) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8314) 8315 Cancel-Locks in Netnews Articles. M. Baeuerle. February 2018. (Format: TXT, HTML) (Updates RFC5537) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8315) 8316 Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations. J. Nobre, L. Granville, A. Clemm, A. Gonzalez Prieto. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8316) 8317 Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN). A. Sajassi, Ed., S. Salam, J. Drake, J. Uttaro, S. Boutros, J. Rabadan. January 2018. (Format: TXT, HTML) (Updates RFC7385) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8317) 8318 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee. S. Dawkins. January 2018. (Format: TXT, HTML) (Obsoleted by RFC8713) (Updates RFC7437) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8318) 8319 Support for Adjustable Maximum Router Lifetimes per Link. S. Krishnan, J. Korhonen, S. Chakrabarti, E. Nordmark, A. Yourtchenko. February 2018. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8319) 8320 LDP Extensions to Support Maximally Redundant Trees. A. Atlas, K. Tiruveedhula, C. Bowers, J. Tantsura, IJ. Wijnands. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8320) 8321 Alternate-Marking Method for Passive and Hybrid Performance Monitoring. G. Fioccola, Ed., A. Capello, M. Cociglio, L. Castaldelli, M. Chen, L. Zheng, G. Mirsky, T. Mizrahi. January 2018. (Format: TXT, HTML) (Obsoleted by RFC9341) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8321) 8322 Resource-Oriented Lightweight Information Exchange (ROLIE). J. Field, S. Banghart, D. Waltermire. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8322) 8323 CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets. C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, B. Raymor, Ed.. February 2018. (Format: TXT, HTML) (Updates RFC7641, RFC7959) (Updated by RFC8974) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8323) 8324 DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?. J. Klensin. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8324) 8325 Mapping Diffserv to IEEE 802.11. T. Szigeti, J. Henry, F. Baker. February 2018. (Format: TXT, HTML) (Updated by RFC8622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8325) 8326 Graceful BGP Session Shutdown. P. Francois, Ed., B. Decraene, Ed., C. Pelsser, K. Patel, C. Filsfils. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8326) 8327 Mitigating the Negative Impact of Maintenance through BGP Session Culling. W. Hargrave, M. Griswold, J. Snijders, N. Hilliard. March 2018. (Format: TXT, HTML) (Also BCP0214) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8327) 8328 Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA). W. Liu, C. Xie, J. Strassner, G. Karagiannis, M. Klyus, J. Bi, Y. Cheng, D. Zhang. March 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8328) 8329 Framework for Interface to Network Security Functions. D. Lopez, E. Lopez, L. Dunbar, J. Strassner, R. Kumar. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8329) 8330 OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth. H. Long, M. Ye, G. Mirsky, A. D'Alessandro, H. Shah. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8330) 8331 RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data. T. Edwards. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8331) 8332 Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol. D. Bider. March 2018. (Format: TXT, HTML) (Updates RFC4252, RFC4253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8332) 8333 Micro-loop Prevention by Introducing a Local Convergence Delay. S. Litkowski, B. Decraene, C. Filsfils, P. Francois. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8333) 8334 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP). J. Gould, W. Tan, G. Brown. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8334) 8335 PROBE: A Utility for Probing Interfaces. R. Bonica, R. Thomas, J. Linkova, C. Lenart, M. Boucadair. February 2018. (Format: TXT, HTML) (Updates RFC4884) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8335) 8336 The ORIGIN HTTP/2 Frame. M. Nottingham, E. Nygren. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8336) 8337 Model-Based Metrics for Bulk Transport Capacity. M. Mathis, A. Morton. March 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8337) 8338 Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP. S. Boutros, Ed., S. Sivabalan, Ed.. March 2018. (Format: TXT, HTML) (Updates RFC7385) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8338) 8339 Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms. P. Jain, Ed., S. Boutros, S. Aldrin. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8339) 8340 YANG Tree Diagrams. M. Bjorklund, L. Berger, Ed.. March 2018. (Format: TXT, HTML) (Updated by RFC8791) (Also BCP0215) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8340) 8341 Network Configuration Access Control Model. A. Bierman, M. Bjorklund. March 2018. (Format: TXT, HTML) (Obsoletes RFC6536) (Also STD0091) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8341) 8342 Network Management Datastore Architecture (NMDA). M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. March 2018. (Format: TXT, HTML) (Updates RFC7950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8342) 8343 A YANG Data Model for Interface Management. M. Bjorklund. March 2018. (Format: TXT, HTML) (Obsoletes RFC7223) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8343) 8344 A YANG Data Model for IP Management. M. Bjorklund. March 2018. (Format: TXT, HTML) (Obsoletes RFC7277) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8344) 8345 A YANG Data Model for Network Topologies. A. Clemm, J. Medved, R. Varga, N. Bahadur, H. Ananthakrishnan, X. Liu. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8345) 8346 A YANG Data Model for Layer 3 Topologies. A. Clemm, J. Medved, R. Varga, X. Liu, H. Ananthakrishnan, N. Bahadur. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8346) 8347 A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP). X. Liu, Ed., A. Kyparlis, R. Parikh, A. Lindem, M. Zhang. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8347) 8348 A YANG Data Model for Hardware Management. A. Bierman, M. Bjorklund, J. Dong, D. Romascanu. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8348) 8349 A YANG Data Model for Routing Management (NMDA Version). L. Lhotka, A. Lindem, Y. Qu. March 2018. (Format: TXT, HTML) (Obsoletes RFC8022) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8349) 8350 Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP). R. Zhang, R. Pazhyannur, S. Gundavelli, Z. Cao, H. Deng, Z. Du. April 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8350) 8351 The PKCS #8 EncryptedPrivateKeyInfo Media Type. S. Leonard. June 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8351) 8352 Energy-Efficient Features of Internet of Things Protocols. C. Gomez, M. Kovatsch, H. Tian, Z. Cao, Ed.. April 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8352) 8353 Generic Security Service API Version 2: Java Bindings Update. M. Upadhyay, S. Malkani, W. Wang. May 2018. (Format: TXT, HTML) (Obsoletes RFC5653) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8353) 8354 Use Cases for IPv6 Source Packet Routing in Networking (SPRING). J. Brzozowski, J. Leddy, C. Filsfils, R. Maglione, Ed., M. Townsley. March 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8354) 8355 Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks. C. Filsfils, Ed., S. Previdi, Ed., B. Decraene, R. Shakir. March 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8355) 8356 Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP). D. Dhody, D. King, A. Farrel. March 2018. (Format: TXT, HTML) (Updates RFC5440) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8356) 8357 Generalized UDP Source Port for DHCP Relay. N. Shen, E. Chen. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8357) 8358 Update to Digital Signatures on Internet-Draft Documents. R. Housley. March 2018. (Format: TXT, HTML) (Updates RFC5485) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8358) 8359 Network-Assigned Upstream Label. X. Zhang, Ed., V. Beeram, Ed., I. Bryskin, D. Ceccarelli, O. Gonzalez de Dios. March 2018. (Format: TXT, HTML) (Updates RFC3471, RFC3473, RFC6205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8359) 8360 Resource Public Key Infrastructure (RPKI) Validation Reconsidered. G. Huston, G. Michaelson, C. Martinez, T. Bruijnzeels, A. Newton, D. Shaw. April 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8360) 8361 Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic. W. Hao, Y. Li, M. Durrani, S. Gupta, A. Qu. April 2018. (Format: TXT, HTML) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8361) 8362 OSPFv3 Link State Advertisement (LSA) Extensibility. A. Lindem, A. Roy, D. Goethals, V. Reddy Vallem, F. Baker. April 2018. (Format: TXT, HTML) (Updates RFC5340, RFC5838) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8362) 8363 GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks. X. Zhang, H. Zheng, R. Casellas, O. Gonzalez de Dios, D. Ceccarelli. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8363) 8364 PIM Flooding Mechanism (PFM) and Source Discovery (SD). IJ. Wijnands, S. Venaas, M. Brig, A. Jonasson. March 2018. (Format: TXT, HTML) (Updated by RFC8736) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8364) 8365 A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN). A. Sajassi, Ed., J. Drake, Ed., N. Bitar, R. Shekhar, J. Uttaro, W. Henderickx. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8365) 8366 A Voucher Artifact for Bootstrapping Protocols. K. Watsen, M. Richardson, M. Pritikin, T. Eckert. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8366) 8367 Wrongful Termination of Internet Protocol (IP) Packets. T. Mizrahi, J. Yallouz. 1 April 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8367) 8368 Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM). T. Eckert, Ed., M. Behringer. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8368) 8369 Internationalizing IPv6 Using 128-Bit Unicode. H. Kaplan. 1 April 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8369) 8370 Techniques to Improve the Scalability of RSVP-TE Deployments. V. Beeram, Ed., I. Minei, R. Shakir, D. Pacella, T. Saad. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8370) 8371 Mobile Node Identifier Types for MIPv6. C. Perkins, V. Devarapalli. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8371) 8372 MPLS Flow Identification Considerations. S. Bryant, C. Pignataro, M. Chen, Z. Li, G. Mirsky. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8372) 8373 Negotiating Human Language in Real-Time Communications. R. Gellens. May 2018. (Format: TXT, HTML) (Updated by RFC8865) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8373) 8374 BGPsec Design Choices and Summary of Supporting Discussions. K. Sriram, Ed.. April 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8374) 8375 Special-Use Domain 'home.arpa.'. P. Pfister, T. Lemon. May 2018. (Format: TXT, HTML) (Updates RFC7788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8375) 8376 Low-Power Wide Area Network (LPWAN) Overview. S. Farrell, Ed.. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8376) 8377 Transparent Interconnection of Lots of Links (TRILL): Multi-Topology. D. Eastlake 3rd, M. Zhang, A. Banerjee. July 2018. (Format: TXT, HTML) (Updates RFC6325, RFC7177) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8377) 8378 Signal-Free Locator/ID Separation Protocol (LISP) Multicast. V. Moreno, D. Farinacci. May 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8378) 8379 OSPF Graceful Link Shutdown. S. Hegde, P. Sarkar, H. Gredler, M. Nanduri, L. Jalil. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8379) 8380 Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation. L. Dunbar, D. Eastlake 3rd, R. Perlman. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8380) 8381 Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol. D. Eastlake 3rd, Y. Li, W. Hao, A. Banerjee. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8381) 8382 Shared Bottleneck Detection for Coupled Congestion Control for RTP Media. D. Hayes, Ed., S. Ferlin, M. Welzl, K. Hiorth. June 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8382) 8383 Transparent Interconnection of Lots of Links (TRILL): Address Flush Message. W. Hao, D. Eastlake 3rd, Y. Li, M. Umair. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8383) 8384 Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes. R. Perlman, F. Hu, D. Eastlake 3rd, T. Liao. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8384) 8385 Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLS. M. Umair, S. Kingston Smiler, D. Eastlake 3rd, L. Yong. June 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8385) 8386 Privacy Considerations for Protocols Relying on IP Broadcast or Multicast. R. Winter, M. Faath, F. Weisshaar. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8386) 8387 Practical Considerations and Implementation Experiences in Securing Smart Object Networks. M. Sethi, J. Arkko, A. Keranen, H. Back. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8387) 8388 Usage and Applicability of BGP MPLS-Based Ethernet VPN. J. Rabadan, Ed., S. Palislamovic, W. Henderickx, A. Sajassi, J. Uttaro. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8388) 8389 Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E). Y. Fu, S. Jiang, B. Liu, J. Dong, Y. Chen. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8389) 8390 RSVP-TE Path Diversity Using Exclude Route. Z. Ali, Ed., G. Swallow, Ed., F. Zhang, Ed., D. Beller, Ed.. July 2018. (Format: TXT, HTML) (Updates RFC4874) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8390) 8391 XMSS: eXtended Merkle Signature Scheme. A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A. Mohaisen. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8391) 8392 CBOR Web Token (CWT). M. Jones, E. Wahlstroem, S. Erdtman, H. Tschofenig. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8392) 8393 Operating the Network Service Header (NSH) with Next Protocol "None". A. Farrel, J. Drake. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8393) 8394 Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements. Y. Li, D. Eastlake 3rd, L. Kreeger, T. Narten, D. Black. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8394) 8395 Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels. K. Patel, S. Boutros, J. Liste, B. Wen, J. Rabadan. June 2018. (Format: TXT, HTML) (Updates RFC4761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8395) 8396 Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework. J. Peterson, T. McGarry. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8396) 8397 Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames. M. Zhang, D. Eastlake 3rd, R. Perlman, H. Zhai, D. Liu. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8397) 8398 Internationalized Email Addresses in X.509 Certificates. A. Melnikov, Ed., W. Chuang, Ed.. May 2018. (Format: TXT, HTML) (Updates RFC5280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8398) 8399 Internationalization Updates to RFC 5280. R. Housley. May 2018. (Format: TXT, HTML) (Updates RFC5280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8399) 8400 Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection. H. Chen, A. Liu, T. Saad, F. Xu, L. Huang. June 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8400) 8401 Bit Index Explicit Replication (BIER) Support via IS-IS. L. Ginsberg, Ed., T. Przygienda, S. Aldrin, Z. Zhang. June 2018. (Format: TXT, HTML) (Updated by RFC9272) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8401) 8402 Segment Routing Architecture. C. Filsfils, Ed., S. Previdi, Ed., L. Ginsberg, B. Decraene, S. Litkowski, R. Shakir. July 2018. (Format: TXT, HTML) (Updated by RFC9256) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8402) 8403 A Scalable and Topology-Aware MPLS Data-Plane Monitoring System. R. Geib, Ed., C. Filsfils, C. Pignataro, Ed., N. Kumar. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8403) 8404 Effects of Pervasive Encryption on Operators. K. Moriarty, Ed., A. Morton, Ed.. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8404) 8405 Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs. B. Decraene, S. Litkowski, H. Gredler, A. Lindem, P. Francois, C. Bowers. June 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8405) 8406 Taxonomy of Coding Techniques for Efficient Network Communications. B. Adamson, C. Adjih, J. Bilbao, V. Firoiu, F. Fitzek, S. Ghanem, E. Lochin, A. Masucci, M-J. Montpetit, M. Pedersen, G. Peralta, V. Roca, Ed., P. Saxena, S. Sivakumar. June 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8406) 8407 Guidelines for Authors and Reviewers of Documents Containing YANG Data Models. A. Bierman. October 2018. (Format: TXT, HTML) (Obsoletes RFC6087) (Updated by RFC8819) (Also BCP0216) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8407) 8408 Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages. S. Sivabalan, J. Tantsura, I. Minei, R. Varga, J. Hardwick. July 2018. (Format: TXT, HTML) (Updated by RFC8664) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8408) 8409 The Entity Category Security Assertion Markup Language (SAML) Attribute Types. I. Young, Ed., L. Johansson, S. Cantor. August 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8409) 8410 Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure. S. Josefsson, J. Schaad. August 2018. (Format: TXT, HTML) (Updated by RFC9295) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8410) 8411 IANA Registration for the Cryptographic Algorithm Object Identifier Range. J. Schaad, R. Andrews. August 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8411) 8412 Software Inventory Message and Attributes (SWIMA) for PA-TNC. C. Schmidt, D. Haynes, C. Coffin, D. Waltermire, J. Fitzgerald-McKay. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8412) 8413 Framework for Scheduled Use of Resources. Y. Zhuang, Q. Wu, H. Chen, A. Farrel. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8413) 8414 OAuth 2.0 Authorization Server Metadata. M. Jones, N. Sakimura, J. Bradley. June 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8414) 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). T. Mrugalski, M. Siodelski, B. Volz, A. Yourtchenko, M. Richardson, S. Jiang, T. Lemon, T. Winters. November 2018. (Format: TXT, HTML) (Obsoletes RFC3315, RFC3633, RFC3736, RFC4242, RFC7083, RFC7283, RFC7550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8415) 8416 Simplified Local Internet Number Resource Management with the RPKI (SLURM). D. Ma, D. Mandelberg, T. Bruijnzeels. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8416) 8417 Security Event Token (SET). P. Hunt, Ed., M. Jones, W. Denniss, M. Ansari. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8417) 8418 Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS). R. Housley. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8418) 8419 Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS). R. Housley. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8419) 8420 Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2). Y. Nir. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8420) 8421 Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE). P. Martinsen, T. Reddy, P. Patil. July 2018. (Format: TXT, HTML) (Also BCP0217) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8421) 8422 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier. Y. Nir, S. Josefsson, M. Pegourie-Gonnard. August 2018. (Format: TXT, HTML) (Obsoletes RFC4492) (Updated by RFC8996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8422) 8423 Reclassification of Suite B Documents to Historic Status. R. Housley, L. Zieglar. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8423) 8424 Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection. H. Chen, Ed., R. Torvi, Ed.. August 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8424) 8425 IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags. O. Troan. July 2018. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8425) 8426 Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence. H. Sitaraman, Ed., V. Beeram, I. Minei, S. Sivabalan. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8426) 8427 Representing DNS Messages in JSON. P. Hoffman. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8427) 8428 Sensor Measurement Lists (SenML). C. Jennings, Z. Shelby, J. Arkko, A. Keranen, C. Bormann. August 2018. (Format: TXT, HTML) (Updated by RFC9100) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8428) 8429 Deprecate Triple-DES (3DES) and RC4 in Kerberos. B. Kaduk, M. Short. October 2018. (Format: TXT, HTML) (Updates RFC3961, RFC4120) (Also BCP0218) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8429) 8430 RIB Information Model. N. Bahadur, Ed., S. Kini, Ed., J. Medved. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8430) 8431 A YANG Data Model for the Routing Information Base (RIB). L. Wang, M. Chen, A. Dass, H. Ananthakrishnan, S. Kini, N. Bahadur. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8431) 8432 A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters. J. Ahlberg, Ed., M. Ye, Ed., X. Li, LM. Contreras, CJ. Bernardos. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8432) 8433 A Simpler Method for Resolving Alert-Info URNs. D. Worley. August 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8433) 8434 Requirements for Parallel NFS (pNFS) Layout Types. T. Haynes. August 2018. (Format: TXT, HTML) (Updates RFC5661) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8434) 8435 Parallel NFS (pNFS) Flexible File Layout. B. Halevy, T. Haynes. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8435) 8436 Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry. G. Fairhurst. August 2018. (Format: TXT, HTML) (Updates RFC2474) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8436) 8437 IMAP UNAUTHENTICATE Extension for Connection Reuse. C. Newman. August 2018. (Format: TXT, HTML) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8437) 8438 IMAP Extension for STATUS=SIZE. S. Bosch. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8438) 8439 ChaCha20 and Poly1305 for IETF Protocols. Y. Nir, A. Langley. June 2018. (Format: TXT, HTML) (Obsoletes RFC7539) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8439) 8440 IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST. K. Murchison, B. Gondwana. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8440) 8441 Bootstrapping WebSockets with HTTP/2. P. McManus. September 2018. (Format: TXT, HTML) (Updates RFC6455) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8441) 8442 ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2. J. Mattsson, D. Migault. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8442) 8443 Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization. R. Singh, M. Dolly, S. Das, A. Nguyen. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8443) 8444 OSPFv2 Extensions for Bit Index Explicit Replication (BIER). P. Psenak, Ed., N. Kumar, IJ. Wijnands, A. Dolganow, T. Przygienda, J. Zhang, S. Aldrin. November 2018. (Format: TXT, HTML) (Updated by RFC9272) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8444) 8445 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal. A. Keranen, C. Holmberg, J. Rosenberg. July 2018. (Format: TXT, HTML) (Obsoletes RFC5245) (Updated by RFC8863) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8445) 8446 The Transport Layer Security (TLS) Protocol Version 1.3. E. Rescorla. August 2018. (Format: TXT, HTML) (Obsoletes RFC5077, RFC5246, RFC6961) (Updates RFC5705, RFC6066) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8446) 8447 IANA Registry Updates for TLS and DTLS. J. Salowey, S. Turner. August 2018. (Format: TXT, HTML) (Updates RFC3749, RFC4680, RFC5077, RFC5246, RFC5705, RFC5878, RFC6520, RFC7301) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8447) 8448 Example Handshake Traces for TLS 1.3. M. Thomson. January 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8448) 8449 Record Size Limit Extension for TLS. M. Thomson. August 2018. (Format: TXT, HTML) (Updates RFC6066) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8449) 8450 RTP Payload Format for VC-2 High Quality (HQ) Profile. J. Weaver. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8450) 8451 Considerations for Selecting RTP Control Protocol (RTCP) Extended Report (XR) Metrics for the WebRTC Statistics API. V. Singh, R. Huang, R. Even, D. Romascanu, L. Deng. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8451) 8452 AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption. S. Gueron, A. Langley, Y. Lindell. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8452) 8453 Framework for Abstraction and Control of TE Networks (ACTN). D. Ceccarelli, Ed., Y. Lee, Ed.. August 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8453) 8454 Information Model for Abstraction and Control of TE Networks (ACTN). Y. Lee, S. Belotti, D. Dhody, D. Ceccarelli, B. Yoon. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8454) 8455 Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance. V. Bhuvaneswaran, A. Basil, M. Tassinari, V. Manral, S. Banks. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8455) 8456 Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance. V. Bhuvaneswaran, A. Basil, M. Tassinari, V. Manral, S. Banks. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8456) 8457 IMAP "$Important" Keyword and "\Important" Special-Use Attribute. B. Leiba, Ed.. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8457) 8458 Using National Bibliography Numbers as Uniform Resource Names. J. Hakala. October 2018. (Format: TXT, HTML) (Obsoletes RFC3188) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8458) 8459 Hierarchical Service Function Chaining (hSFC). D. Dolson, S. Homma, D. Lopez, M. Boucadair. September 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8459) 8460 SMTP TLS Reporting. D. Margolis, A. Brotman, B. Ramakrishnan, J. Jones, M. Risher. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8460) 8461 SMTP MTA Strict Transport Security (MTA-STS). D. Margolis, M. Risher, B. Ramakrishnan, A. Brotman, J. Jones. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8461) 8462 Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW). N. Rooney, S. Dawkins, Ed.. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8462) 8463 A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM). J. Levine. September 2018. (Format: TXT, HTML) (Updates RFC6376) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8463) 8464 A URN Namespace for Device Identity and Mobile Equipment Identity (MEID). R. Atarius. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8464) 8465 Using the Mobile Equipment Identity (MEID) URN as an Instance ID. R. Atarius, Ed.. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8465) 8466 A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery. B. Wen, G. Fioccola, Ed., C. Xie, L. Jalil. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8466) 8467 Padding Policies for Extension Mechanisms for DNS (EDNS(0)). A. Mayrhofer. October 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8467) 8468 IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework. A. Morton, J. Fabini, N. Elkins, M. Ackermann, V. Hegde. November 2018. (Format: TXT, HTML) (Updates RFC2330) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8468) 8469 Recommendation to Use the Ethernet Control Word. S. Bryant, A. Malis, I. Bagdonas. November 2018. (Format: TXT, HTML) (Updates RFC4448) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8469) 8470 Using Early Data in HTTP. M. Thomson, M. Nottingham, W. Tarreau. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8470) 8471 The Token Binding Protocol Version 1.0. A. Popov, Ed., M. Nystroem, D. Balfanz, J. Hodges. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8471) 8472 Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation. A. Popov, Ed., M. Nystroem, D. Balfanz. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8472) 8473 Token Binding over HTTP. A. Popov, M. Nystroem, D. Balfanz, Ed., N. Harper, J. Hodges. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8473) 8474 IMAP Extension for Object Identifiers. B. Gondwana, Ed.. September 2018. (Format: TXT, HTML) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8474) 8475 Using Conditional Router Advertisements for Enterprise Multihoming. J. Linkova, M. Stucchi. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8475) 8476 Signaling Maximum SID Depth (MSD) Using OSPF. J. Tantsura, U. Chunduri, S. Aldrin, P. Psenak. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8476) 8477 Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016. J. Jimenez, H. Tschofenig, D. Thaler. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8477) 8478 Zstandard Compression and the application/zstd Media Type. Y. Collet, M. Kucherawy, Ed.. October 2018. (Format: TXT, HTML) (Obsoleted by RFC8878) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8478) 8479 Storing Validation Parameters in PKCS#8. N. Mavrogiannopoulos. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8479) 8480 6TiSCH Operation Sublayer (6top) Protocol (6P). Q. Wang, Ed., X. Vilajosana, T. Watteyne. November 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8480) 8481 Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI). R. Bush. September 2018. (Format: TXT, HTML) (Updates RFC6811) (Updated by RFC9324) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8481) 8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY. J. Abley, O. Gudmundsson, M. Majkowski, E. Hunt. January 2019. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8482) 8483 Yeti DNS Testbed. L. Song, Ed., D. Liu, P. Vixie, A. Kato, S. Kerr. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8483) 8484 DNS Queries over HTTPS (DoH). P. Hoffman, P. McManus. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8484) 8485 Vectors of Trust. J. Richer, Ed., L. Johansson. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8485) 8486 Ambisonics in an Ogg Opus Container. J. Skoglund, M. Graczyk. October 2018. (Format: TXT, HTML) (Updates RFC7845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8486) 8487 Mtrace Version 2: Traceroute Facility for IP Multicast. H. Asaeda, K. Meyer, W. Lee, Ed.. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8487) 8488 RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation. O. Muravskiy, T. Bruijnzeels. December 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8488) 8489 Session Traversal Utilities for NAT (STUN). M. Petit-Huguenin, G. Salgueiro, J. Rosenberg, D. Wing, R. Mahy, P. Matthews. February 2020. (Format: TXT, HTML) (Obsoletes RFC5389) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8489) 8490 DNS Stateful Operations. R. Bellis, S. Cheshire, J. Dickinson, S. Dickinson, T. Lemon, T. Pusateri. March 2019. (Format: TXT, HTML) (Updates RFC1035, RFC7766) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8490) 8491 Signaling Maximum SID Depth (MSD) Using IS-IS. J. Tantsura, U. Chunduri, S. Aldrin, L. Ginsberg. November 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8491) 8492 Secure Password Ciphersuites for Transport Layer Security (TLS). D. Harkins, Ed.. February 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8492) 8493 The BagIt File Packaging Format (V1.0). J. Kunze, J. Littman, E. Madden, J. Scancella, C. Adams. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8493) 8494 Multicast Email (MULE) over Allied Communications Publication (ACP) 142. D. Wilson, A. Melnikov, Ed.. November 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8494) 8495 Allocation Token Extension for the Extensible Provisioning Protocol (EPP). J. Gould, K. Feher. November 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8495) 8496 P-Charge-Info: A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP). D. York, T. Asveren. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8496) 8497 Marking SIP Messages to Be Logged. P. Dawes, C. Arunachalam. November 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8497) 8498 A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP). M. Mohali. February 2019. (Format: TXT, HTML) (Updates RFC5502) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8498) 8499 DNS Terminology. P. Hoffman, A. Sullivan, K. Fujiwara. January 2019. (Format: TXT, HTML) (Obsoletes RFC7719) (Updates RFC2308) (Also BCP0219) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8499) 8500 IS-IS Routing with Reverse Metric. N. Shen, S. Amante, M. Abrahamsson. February 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8500) 8501 Reverse DNS in IPv6 for Internet Service Providers. L. Howard. November 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8501) 8502 L2L3 VPN Multicast MIB. Z. Zhang, H. Tsunoda. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8502) 8503 BGP/MPLS Layer 3 VPN Multicast Management Information Base. H. Tsunoda. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8503) 8504 IPv6 Node Requirements. T. Chown, J. Loughney, T. Winters. January 2019. (Format: TXT, HTML) (Obsoletes RFC6434) (Also BCP0220) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8504) 8505 Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery. P. Thubert, Ed., E. Nordmark, S. Chakrabarti, C. Perkins. November 2018. (Format: TXT, HTML) (Updates RFC6775) (Updated by RFC8928, RFC8929, RFC9010) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8505) 8506 Diameter Credit-Control Application. L. Bertz, Ed., D. Dolson, Ed., Y. Lifshitz, Ed.. March 2019. (Format: TXT, HTML) (Obsoletes RFC4006) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8506) 8507 Simple Internet Protocol (SIP) Specification. S. Deering, R. Hinden, Ed.. December 2018. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC8507) 8508 IMAP REPLACE Extension. S. Brandt. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8508) 8509 A Root Key Trust Anchor Sentinel for DNSSEC. G. Huston, J. Damas, W. Kumari. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8509) 8510 OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement. P. Psenak, Ed., K. Talaulikar, W. Henderickx, P. Pillay-Esnault. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8510) 8511 TCP Alternative Backoff with ECN (ABE). N. Khademi, M. Welzl, G. Armitage, G. Fairhurst. December 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8511) 8512 A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT). M. Boucadair, Ed., S. Sivakumar, C. Jacquenet, S. Vinapamula, Q. Wu. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8512) 8513 A YANG Data Model for Dual-Stack Lite (DS-Lite). M. Boucadair, C. Jacquenet, S. Sivakumar. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8513) 8514 Internet Message Access Protocol (IMAP) - SAVEDATE Extension. S. Bosch. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8514) 8515 URN Namespace for ETSI Documents. M. Jethanandani, M.A. Reina Ortega. February 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8515) 8516 "Too Many Requests" Response Code for the Constrained Application Protocol. A. Keranen. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8516) 8517 An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective. D. Dolson, Ed., J. Snellman, M. Boucadair, Ed., C. Jacquenet. February 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8517) 8518 Selection of Loop-Free Alternates for Multi-Homed Prefixes. P. Sarkar, Ed., U. Chunduri, Ed., S. Hegde, J. Tantsura, H. Gredler. March 2019. (Format: TXT, HTML) (Updates RFC5286) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8518) 8519 YANG Data Model for Network Access Control Lists (ACLs). M. Jethanandani, S. Agarwal, L. Huang, D. Blair. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8519) 8520 Manufacturer Usage Description Specification. E. Lear, R. Droms, D. Romascanu. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8520) 8521 Registration Data Access Protocol (RDAP) Object Tagging. S. Hollenbeck, A. Newton. November 2018. (Format: TXT, HTML) (Updates RFC7484) (Also BCP0221) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8521) 8522 Looking Glass Command Set. M. Stubbig. February 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8522) 8523 Not Issued. 8524 Not Issued. 8525 YANG Library. A. Bierman, M. Bjorklund, J. Schoenwaelder, K. Watsen, R. Wilton. March 2019. (Format: TXT, HTML) (Obsoletes RFC7895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8525) 8526 NETCONF Extensions to Support the Network Management Datastore Architecture. M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. March 2019. (Format: TXT, HTML) (Updates RFC6241, RFC7950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8526) 8527 RESTCONF Extensions to Support the Network Management Datastore Architecture. M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. March 2019. (Format: TXT, HTML) (Updates RFC8040) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8527) 8528 YANG Schema Mount. M. Bjorklund, L. Lhotka. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8528) 8529 YANG Data Model for Network Instances. L. Berger, C. Hopps, A. Lindem, D. Bogdanovic, X. Liu. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8529) 8530 YANG Model for Logical Network Elements. L. Berger, C. Hopps, A. Lindem, D. Bogdanovic, X. Liu. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8530) 8531 Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols. D. Kumar, Q. Wu, Z. Wang. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8531) 8532 Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications. D. Kumar, Z. Wang, Q. Wu, Ed., R. Rahman, S. Raghavan. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8532) 8533 A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications. D. Kumar, M. Wang, Q. Wu, Ed., R. Rahman, S. Raghavan. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8533) 8534 Explicit Tracking with Wildcard Routes in Multicast VPN. A. Dolganow, J. Kotalwar, E. Rosen, Ed., Z. Zhang. February 2019. (Format: TXT, HTML) (Updates RFC6514, RFC6625, RFC7524, RFC7582, RFC7900) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8534) 8535 Not Issued. 8536 The Time Zone Information Format (TZif). A. Olson, P. Eggert, K. Murchison. February 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8536) 8537 Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs). R. Gandhi, Ed., H. Shah, J. Whittaker. February 2019. (Format: TXT, HTML) (Updates RFC4090, RFC7551) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8537) 8538 Notification Message Support for BGP Graceful Restart. K. Patel, R. Fernando, J. Scudder, J. Haas. March 2019. (Format: TXT, HTML) (Updates RFC4724) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8538) 8539 Softwire Provisioning Using DHCPv4 over DHCPv6. I. Farrer, Q. Sun, Y. Cui, L. Sun. March 2019. (Format: TXT, HTML) (Updates RFC7598) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8539) 8540 Stream Control Transmission Protocol: Errata and Issues in RFC 4960. R. Stewart, M. Tuexen, M. Proshin. February 2019. (Format: TXT, HTML) (Obsoleted by RFC9260) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8540) 8541 Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops. S. Litkowski, B. Decraene, M. Horneffer. March 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8541) 8542 A YANG Data Model for Fabric Topology in Data-Center Networks. Y. Zhuang, D. Shi, R. Gu, H. Ananthakrishnan. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8542) 8543 Extensible Provisioning Protocol (EPP) Organization Mapping. L. Zhou, N. Kong, J. Yao, J. Gould, G. Zhou. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8543) 8544 Organization Extension for the Extensible Provisioning Protocol (EPP). L. Zhou, N. Kong, J. Wei, J. Yao, J. Gould. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8544) 8545 Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP). A. Morton, Ed., G. Mirsky, Ed.. March 2019. (Format: TXT, HTML) (Updates RFC4656, RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8545) 8546 The Wire Image of a Network Protocol. B. Trammell, M. Kuehlewind. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8546) 8547 TCP-ENO: Encryption Negotiation Option. A. Bittau, D. Giffin, M. Handley, D. Mazieres, E. Smith. May 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8547) 8548 Cryptographic Protection of TCP Streams (tcpcrypt). A. Bittau, D. Giffin, M. Handley, D. Mazieres, Q. Slack, E. Smith. May 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8548) 8549 Export of BGP Community Information in IP Flow Information Export (IPFIX). Z. Li, R. Gu, J. Dong. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8549) 8550 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling. J. Schaad, B. Ramsdell, S. Turner. April 2019. (Format: TXT, HTML) (Obsoletes RFC5750) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8550) 8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification. J. Schaad, B. Ramsdell, S. Turner. April 2019. (Format: TXT, HTML) (Obsoletes RFC5751) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8551) 8552 Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves. D. Crocker. March 2019. (Format: TXT, HTML) (Also BCP0222) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8552) 8553 DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names. D. Crocker. March 2019. (Format: TXT, HTML) (Updates RFC2782, RFC3263, RFC3529, RFC3620, RFC3832, RFC3887, RFC3958, RFC4120, RFC4227, RFC4386, RFC4387, RFC4976, RFC5026, RFC5328, RFC5389, RFC5415, RFC5518, RFC5555, RFC5617, RFC5679, RFC5766, RFC5780, RFC5804, RFC5864, RFC5928, RFC6120, RFC6186, RFC6376, RFC6733, RFC6763, RFC7208, RFC7489, RFC8145) (Also BCP0222) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8553) 8554 Leighton-Micali Hash-Based Signatures. D. McGrew, M. Curcio, S. Fluhrer. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8554) 8555 Automatic Certificate Management Environment (ACME). R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8555) 8556 Multicast VPN Using Bit Index Explicit Replication (BIER). E. Rosen, Ed., M. Sivakumar, T. Przygienda, S. Aldrin, A. Dolganow. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8556) 8557 Deterministic Networking Problem Statement. N. Finn, P. Thubert. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8557) 8558 Transport Protocol Path Signals. T. Hardie, Ed.. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8558) 8559 Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol. A. DeKok, J. Korhonen. April 2019. (Format: TXT, HTML) (Updates RFC5176, RFC5580) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8559) 8560 Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents. A. Sajassi, Ed., S. Salam, N. Del Regno, J. Rabadan. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8560) 8561 A YANG Data Model for Microwave Radio Link. J. Ahlberg, M. Ye, X. Li, D. Spreafico, M. Vaupotic. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8561) 8562 Bidirectional Forwarding Detection (BFD) for Multipoint Networks. D. Katz, D. Ward, S. Pallagatti, Ed., G. Mirsky, Ed.. April 2019. (Format: TXT, HTML) (Updates RFC5880) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8562) 8563 Bidirectional Forwarding Detection (BFD) Multipoint Active Tails. D. Katz, D. Ward, S. Pallagatti, Ed., G. Mirsky, Ed.. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8563) 8564 Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL). M. Zhang, S. Pallagatti, V. Govindan. April 2019. (Format: TXT, HTML) (Updates RFC7175, RFC7177) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8564) 8565 Hypertext Jeopardy Protocol (HTJP/1.0). E. Fokschaner. 1 April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8565) 8566 Not Issued. 8567 Customer Management DNS Resource Records. E. Rye, R. Beverly. 1 April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8567) 8568 Network Virtualization Research Challenges. CJ. Bernardos, A. Rahman, JC. Zuniga, LM. Contreras, P. Aranda, P. Lynch. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8568) 8569 Content-Centric Networking (CCNx) Semantics. M. Mosko, I. Solis, C. Wood. July 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8569) 8570 IS-IS Traffic Engineering (TE) Metric Extensions. L. Ginsberg, Ed., S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu. March 2019. (Format: TXT, HTML) (Obsoletes RFC7810) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8570) 8571 BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions. L. Ginsberg, Ed., S. Previdi, Q. Wu, J. Tantsura, C. Filsfils. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8571) 8572 Secure Zero Touch Provisioning (SZTP). K. Watsen, I. Farrer, M. Abrahamsson. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8572) 8573 Message Authentication Code for the Network Time Protocol. A. Malhotra, S. Goldberg. June 2019. (Format: TXT, HTML) (Updates RFC5905) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8573) 8574 cite-as: A Link Relation to Convey a Preferred URI for Referencing. H. Van de Sompel, M. Nelson, G. Bilder, J. Kunze, S. Warner. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8574) 8575 YANG Data Model for the Precision Time Protocol (PTP). Y. Jiang, Ed., X. Liu, J. Xu, R. Cummings, Ed.. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8575) 8576 Internet of Things (IoT) Security: State of the Art and Challenges. O. Garcia-Morchon, S. Kumar, M. Sethi. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8576) 8577 Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane. H. Sitaraman, V. Beeram, T. Parikh, T. Saad. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8577) 8578 Deterministic Networking Use Cases. E. Grossman, Ed.. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8578) 8579 Sieve Email Filtering: Delivering to Special-Use Mailboxes. S. Bosch. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8579) 8580 Sieve Extension: File Carbon Copy (FCC). K. Murchison, B. Gondwana. May 2019. (Format: TXT, HTML) (Updates RFC5230, RFC5435) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8580) 8581 Diameter Agent Overload and the Peer Overload Report. S. Donovan. August 2019. (Format: TXT, HTML) (Updates RFC7683) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8581) 8582 Diameter Overload Rate Control. S. Donovan, Ed., E. Noel. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8582) 8583 Diameter Load Information Conveyance. B. Campbell, S. Donovan, Ed., JJ. Trottin. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8583) 8584 Framework for Ethernet VPN Designated Forwarder Election Extensibility. J. Rabadan, Ed., S. Mohanty, Ed., A. Sajassi, J. Drake, K. Nagaraj, S. Sathappan. April 2019. (Format: TXT, HTML) (Updates RFC7432) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8584) 8585 Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service. J. Palet Martinez, H. M.-H. Liu, M. Kawashima. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8585) 8586 Loop Detection in Content Delivery Networks (CDNs). S. Ludin, M. Nottingham, N. Sullivan. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8586) 8587 NFS Version 4.0 Trunking Update. C. Lever, Ed., D. Noveck. May 2019. (Format: TXT, HTML) (Updates RFC7530) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8587) 8588 Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN). C. Wendt, M. Barnes. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8588) 8589 The 'leaptofrogans' URI Scheme. A. Tamas, B. Phister, Ed., J-E. Rodriguez. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8589) 8590 Change Poll Extension for the Extensible Provisioning Protocol (EPP). J. Gould, K. Feher. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8590) 8591 SIP-Based Messaging with S/MIME. B. Campbell, R. Housley. April 2019. (Format: TXT, HTML) (Updates RFC3261, RFC3428, RFC4975) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8591) 8592 Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH). R. Browne, A. Chilikin, T. Mizrahi. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8592) 8593 Video Traffic Models for RTP Congestion Control Evaluations. X. Zhu, S. Mena, Z. Sarker. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8593) 8594 The Sunset HTTP Header Field. E. Wilde. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8594) 8595 An MPLS-Based Forwarding Plane for Service Function Chaining. A. Farrel, S. Bryant, J. Drake. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8595) 8596 MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH). A. Malis, S. Bryant, J. Halpern, W. Henderickx. June 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8596) 8597 Cooperating Layered Architecture for Software-Defined Networking (CLAS). LM. Contreras, CJ. Bernardos, D. Lopez, M. Boucadair, P. Iovanna. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8597) 8598 Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2). T. Pauly, P. Wouters. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8598) 8599 Push Notification with the Session Initiation Protocol (SIP). C. Holmberg, M. Arnold. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8599) 8600 Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange. N. Cam-Winget, Ed., S. Appala, S. Pope, P. Saint-Andre. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8600) 8601 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. May 2019. (Format: TXT, HTML) (Obsoletes RFC7601) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8601) 8602 Update to the Telephony Routing over IP (TRIP) IANA Registry Rules regarding Postal Addresses. J. Arkko, T. Hardie. July 2019. (Format: TXT, HTML) (Updates RFC3219) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8602) 8603 Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile. M. Jenkins, L. Zieglar. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8603) 8604 Interconnecting Millions of Endpoints with Segment Routing. C. Filsfils, Ed., S. Previdi, G. Dawra, Ed., W. Henderickx, D. Cooper. June 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8604) 8605 vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP). S. Hollenbeck, R. Carney. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8605) 8606 ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field. R. Jesske. June 2019. (Format: TXT, HTML) (Updates RFC3326) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8606) 8607 Calendaring Extensions to WebDAV (CalDAV): Managed Attachments. C. Daboo, A. Quillaud, K. Murchison, Ed.. June 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8607) 8608 BGPsec Algorithms, Key Formats, and Signature Formats. S. Turner, O. Borchert. June 2019. (Format: TXT, HTML) (Obsoletes RFC8208) (Updates RFC7935) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8608) 8609 Content-Centric Networking (CCNx) Messages in TLV Format. M. Mosko, I. Solis, C. Wood. July 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8609) 8610 Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures. H. Birkholz, C. Vigano, C. Bormann. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8610) 8611 Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces. N. Akiya, G. Swallow, S. Litkowski, B. Decraene, J. Drake, M. Chen. June 2019. (Format: TXT, HTML) (Updates RFC8029) (Updated by RFC9041) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8611) 8612 DDoS Open Threat Signaling (DOTS) Requirements. A. Mortensen, T. Reddy, R. Moskowitz. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8612) 8613 Object Security for Constrained RESTful Environments (OSCORE). G. Selander, J. Mattsson, F. Palombini, L. Seitz. July 2019. (Format: TXT, HTML) (Updates RFC7252) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8613) 8614 Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS). R. Singh, K. Kompella, S. Palislamovic. June 2019. (Format: TXT, HTML) (Updates RFC4761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8614) 8615 Well-Known Uniform Resource Identifiers (URIs). M. Nottingham. May 2019. (Format: TXT, HTML) (Obsoletes RFC5785) (Updates RFC7230, RFC7595) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8615) 8616 Email Authentication for Internationalized Mail. J. Levine. June 2019. (Format: TXT, HTML) (Updates RFC6376, RFC7208, RFC7489) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8616) 8617 The Authenticated Received Chain (ARC) Protocol. K. Andersen, B. Long, Ed., S. Blank, Ed., M. Kucherawy, Ed.. July 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8617) 8618 Compacted-DNS (C-DNS): A Format for DNS Packet Capture. J. Dickinson, J. Hague, S. Dickinson, T. Manderson, J. Bond. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8618) 8619 Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF). R. Housley. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8619) 8620 The JSON Meta Application Protocol (JMAP). N. Jenkins, C. Newman. July 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8620) 8621 The JSON Meta Application Protocol (JMAP) for Mail. N. Jenkins, C. Newman. August 2019. (Format: TXT, HTML) (Updates RFC5788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8621) 8622 A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services. R. Bless. June 2019. (Format: TXT, HTML) (Obsoletes RFC3662) (Updates RFC4594, RFC8325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8622) 8623 Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs). U. Palle, D. Dhody, Y. Tanaka, V. Beeram. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8623) 8624 Algorithm Implementation Requirements and Usage Guidance for DNSSEC. P. Wouters, O. Sury. June 2019. (Format: TXT, HTML) (Obsoletes RFC6944) (Updated by RFC9157) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8624) 8625 Ethernet Traffic Parameters with Availability Information. H. Long, M. Ye, Ed., G. Mirsky, Ed., A. D'Alessandro, H. Shah. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8625) 8626 Not Issued. 8627 RTP Payload Format for Flexible Forward Error Correction (FEC). M. Zanaty, V. Singh, A. Begen, G. Mandyam. July 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8627) 8628 OAuth 2.0 Device Authorization Grant. W. Denniss, J. Bradley, M. Jones, H. Tschofenig. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8628) 8629 Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension. B. Cheng, L. Berger, Ed.. July 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8629) 8630 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator. G. Huston, S. Weiler, G. Michaelson, S. Kent, T. Bruijnzeels. August 2019. (Format: TXT, HTML) (Obsoletes RFC7730) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8630) 8631 Link Relation Types for Web Services. E. Wilde. July 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8631) 8632 A YANG Data Model for Alarm Management. S. Vallin, M. Bjorklund. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8632) 8633 Network Time Protocol Best Current Practices. D. Reilly, H. Stenn, D. Sibold. July 2019. (Format: TXT, HTML) (Also BCP0223) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8633) 8634 BGPsec Router Certificate Rollover. B. Weis, R. Gagliano, K. Patel. August 2019. (Format: TXT, HTML) (Also BCP0224) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8634) 8635 Router Keying for BGPsec. R. Bush, S. Turner, K. Patel. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8635) 8636 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility. L. Hornquist Astrand, L. Zhu, M. Cullen, G. Hudson. July 2019. (Format: TXT, HTML) (Updates RFC4556) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8636) 8637 Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN). D. Dhody, Y. Lee, D. Ceccarelli. July 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8637) 8638 IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks. M. Xu, Y. Cui, J. Wu, S. Yang, C. Metz. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8638) 8639 Subscription to YANG Notifications. E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8639) 8640 Dynamic Subscription to YANG Events and Datastores over NETCONF. E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8640) 8641 Subscription to YANG Notifications for Datastore Updates. A. Clemm, E. Voit. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8641) 8642 Policy Behavior for Well-Known BGP Communities. J. Borkenhagen, R. Bush, R. Bonica, S. Bayraktar. August 2019. (Format: TXT, HTML) (Updates RFC1997) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8642) 8643 An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP). A. Johnston, B. Aboba, A. Hutton, R. Jesske, T. Stach. August 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8643) 8644 Not Issued. 8645 Re-keying Mechanisms for Symmetric Keys. S. Smyshlyaev, Ed.. August 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8645) 8646 Not Issued. 8647 Not Issued. 8648 Not Issued. 8649 Hash Of Root Key Certificate Extension. R. Housley. August 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8649) 8650 Dynamic Subscription to YANG Events and Datastores over RESTCONF. E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A. Bierman. November 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8650) 8651 Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension. B. Cheng, D. Wiggins, L. Berger, Ed.. October 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8651) 8652 A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD). X. Liu, F. Guo, M. Sivakumar, P. McAllister, A. Peter. November 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8652) 8653 On-Demand Mobility Management. A. Yegin, D. Moses, S. Jeon. October 2019. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8653) 8654 Extended Message Support for BGP. R. Bush, K. Patel, D. Ward. October 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8654) 8655 Deterministic Networking Architecture. N. Finn, P. Thubert, B. Varga, J. Farkas. October 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8655) 8656 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). T. Reddy, Ed., A. Johnston, Ed., P. Matthews, J. Rosenberg. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC5766, RFC6156) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8656) 8657 Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding. H. Landau. November 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8657) 8658 RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P). S. Jiang, Ed., Y. Fu, Ed., C. Xie, T. Li, M. Boucadair, Ed.. November 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8658) 8659 DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, R. Stradling, J. Hoffman-Andrews. November 2019. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6844) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8659) 8660 Segment Routing with the MPLS Data Plane. A. Bashandy, Ed., C. Filsfils, Ed., S. Previdi, B. Decraene, S. Litkowski, R. Shakir. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8660) 8661 Segment Routing MPLS Interworking with LDP. A. Bashandy, Ed., C. Filsfils, Ed., S. Previdi, B. Decraene, S. Litkowski. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8661) 8662 Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels. S. Kini, K. Kompella, S. Sivabalan, S. Litkowski, R. Shakir, J. Tantsura. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8662) 8663 MPLS Segment Routing over IP. X. Xu, S. Bryant, A. Farrel, S. Hassan, W. Henderickx, Z. Li. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8663) 8664 Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing. S. Sivabalan, C. Filsfils, J. Tantsura, W. Henderickx, J. Hardwick. December 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC8408) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8664) 8665 OSPF Extensions for Segment Routing. P. Psenak, Ed., S. Previdi, Ed., C. Filsfils, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8665) 8666 OSPFv3 Extensions for Segment Routing. P. Psenak, Ed., S. Previdi, Ed.. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8666) 8667 IS-IS Extensions for Segment Routing. S. Previdi, Ed., L. Ginsberg, Ed., C. Filsfils, A. Bashandy, H. Gredler, B. Decraene. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8667) 8668 Advertising Layer 2 Bundle Member Link Attributes in IS-IS. L. Ginsberg, Ed., A. Bashandy, C. Filsfils, M. Nanduri, E. Aries. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8668) 8669 Segment Routing Prefix Segment Identifier Extensions for BGP. S. Previdi, C. Filsfils, A. Lindem, Ed., A. Sreekantiah, H. Gredler. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8669) 8670 BGP Prefix Segment in Large-Scale Data Centers. C. Filsfils, Ed., S. Previdi, G. Dawra, E. Aries, P. Lapukhov. December 2019. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8670) 8671 Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP). T. Evens, S. Bayraktar, P. Lucente, P. Mi, S. Zhuang. November 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC7854) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8671) 8672 TLS Server Identity Pinning with Tickets. Y. Sheffer, D. Migault. October 2019. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8672) 8673 HTTP Random Access and Live Content. C. Pratt, D. Thakore, B. Stark. November 2019. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8673) 8674 The "safe" HTTP Preference. M. Nottingham. December 2019. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8674) 8675 A YANG Data Model for Tunnel Interface Types. M. Boucadair, I. Farrer, R. Asati. November 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8675) 8676 YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires. I. Farrer, Ed., M. Boucadair, Ed.. November 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8676) 8677 Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework. D. Trossen, D. Purkayastha, A. Rahman. November 2019. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8677) 8678 Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions. F. Baker, C. Bowers, J. Linkova. December 2019. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8678) 8679 MPLS Egress Protection Framework. Y. Shen, M. Jeganathan, B. Decraene, H. Gredler, C. Michel, H. Chen. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8679) 8680 Forward Error Correction (FEC) Framework Extension to Sliding Window Codes. V. Roca, A. Begen. January 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC6363) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8680) 8681 Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME. V. Roca, B. Teibi. January 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8681) 8682 TinyMT32 Pseudorandom Number Generator (PRNG). M. Saito, M. Matsumoto, V. Roca, Ed., E. Baccelli. January 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8682) 8683 Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks. J. Palet Martinez. November 2019. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8683) 8684 TCP Extensions for Multipath Operation with Multiple Addresses. A. Ford, C. Raiciu, M. Handley, O. Bonaventure, C. Paasch. March 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6824) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8684) 8685 Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture. F. Zhang, Q. Zhao, O. Gonzalez de Dios, R. Casellas, D. King. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8685) 8686 Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery. S. Kiesel, M. Stiemerling. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8686) 8687 OSPF Routing with Cross-Address Family Traffic Engineering Tunnels. A. Smirnov, A. Retana, M. Barnes. November 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC5786) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8687) 8688 A Session Initiation Protocol (SIP) Response Code for Rejected Calls. E.W. Burger, B. Nagda. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8688) 8689 SMTP Require TLS Option. J. Fenton. November 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8689) 8690 Clarification of Segment ID Sub-TLV Length for RFC 8287. N. Nainar, C. Pignataro, F. Iqbal, A. Vainshtein. December 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC8287) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8690) 8691 Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11. N. Benamar, J. Härri, J. Lee, T. Ernst. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8691) 8692 Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs. P. Kampanakis, Q. Dang. December 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC3279) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8692) 8693 OAuth 2.0 Token Exchange. M. Jones, A. Nadalin, B. Campbell, Ed., J. Bradley, C. Mortimore. January 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8693) 8694 Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering. D. King, H. Zheng. December 2019. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8694) 8695 A YANG Data Model for the Routing Information Protocol (RIP). X. Liu, P. Sarda, V. Choudhary. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8695) 8696 Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS). R. Housley. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8696) 8697 Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs). I. Minei, E. Crabbe, S. Sivabalan, H. Ananthakrishnan, D. Dhody, Y. Tanaka. January 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8697) 8698 Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media. X. Zhu, R. Pan, M. Ramalho, S. Mena. February 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8698) 8699 Coupled Congestion Control for RTP Media. S. Islam, M. Welzl, S. Gjessing. January 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8699) 8700 Fifty Years of RFCs. H. Flanagan, Ed.. December 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC2555, RFC5540) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8700) 8701 Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility. D. Benjamin. January 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8701) 8702 Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS). P. Kampanakis, Q. Dang. January 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC3370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8702) 8703 Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension. R. Taylor, S. Ratliff. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8703) 8704 Enhanced Feasible-Path Unicast Reverse Path Forwarding. K. Sriram, D. Montgomery, J. Haas. February 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC3704) (Also BCP0084) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8704) 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens. B. Campbell, J. Bradley, N. Sakimura, T. Lodderstedt. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8705) 8706 Restart Signaling for IS-IS. L. Ginsberg, P. Wells. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC5306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8706) 8707 Resource Indicators for OAuth 2.0. B. Campbell, J. Bradley, H. Tschofenig. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8707) 8708 Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS). R. Housley. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8708) 8709 Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol. B. Harris, L. Velvindron. February 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC4253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8709) 8710 Multipart Content-Format for the Constrained Application Protocol (CoAP). T. Fossati, K. Hartke, C. Bormann. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8710) 8711 Structure of the IETF Administrative Support Activity, Version 2.0. B. Haberman, J. Hall, J. Livingood. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC4071, RFC4333, RFC7691) (Also BCP0101) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8711) 8712 The IETF-ISOC Relationship. G. Camarillo, J. Livingood. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC2031) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8712) 8713 IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees. M. Kucherawy, Ed., R. Hinden, Ed., J. Livingood, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7437, RFC8318) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8713) 8714 Update to the Process for Selection of Trustees for the IETF Trust. J. Arkko, T. Hardie. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC4371) (Also BCP0101) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8714) 8715 IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust. J. Arkko. February 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8715) 8716 Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC. P. Resnick, A. Farrel. February 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC7776) (Also BCP0025) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8716) 8717 IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology. J. Klensin, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC2028, RFC2418, RFC3005, RFC3710, RFC3929, RFC4633, RFC6702) (Also BCP0101) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8717) 8718 IETF Plenary Meeting Venue Selection Process. E. Lear, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0226) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8718) 8719 High-Level Guidance for the Meeting Policy of the IETF. S. Krishnan. February 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0226) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8719) 8720 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries. R. Housley, Ed., O. Kolkman, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7500) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8720) 8721 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents. J. Halpern, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC5377) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8721) 8722 Defining the Role and Function of IETF Protocol Parameter Registry Operators. D. McPherson, Ed., O. Kolkman, Ed., J. Klensin, Ed., G. Huston, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6220) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8722) 8723 Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP). C. Jennings, P. Jones, R. Barnes, A.B. Roach. April 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8723) 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation. A. Minaburo, L. Toutain, C. Gomez, D. Barthel, JC. Zuniga. April 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8724) 8725 JSON Web Token Best Current Practices. Y. Sheffer, D. Hardt, M. Jones. February 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC7519) (Also BCP0225) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8725) 8726 How Requests for IANA Action Will Be Handled on the Independent Stream. A. Farrel. November 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8726) 8727 JSON Binding of the Incident Object Description Exchange Format. T. Takahashi, R. Danyliw, M. Suzuki. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8727) 8728 RFC Editor Model (Version 2). O. Kolkman, Ed., J. Halpern, Ed., R. Hinden, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6635) (Obsoleted by RFC9280) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8728) 8729 The RFC Series and RFC Editor. R. Housley, Ed., L. Daigle, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC4844) (Updated by RFC9280) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8729) 8730 Independent Submission Editor Model. N. Brownlee, Ed., B. Hinden, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6548) (Updated by RFC9280) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8730) 8731 Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448. A. Adamantiadis, S. Josefsson, M. Baushke. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8731) 8732 Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2. S. Sorce, H. Kario. February 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC4462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8732) 8733 Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE. D. Dhody, Ed., R. Gandhi, Ed., U. Palle, R. Singh, L. Fang. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8733) 8734 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3. L. Bruckert, J. Merkle, M. Lochter. February 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8734) 8735 Scenarios and Simulation Results of PCE in a Native IP Network. A. Wang, X. Huang, C. Kou, Z. Li, P. Mi. February 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8735) 8736 PIM Message Type Space Extension and Reserved Bits. S. Venaas, A. Retana. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6166) (Updates RFC3973, RFC5015, RFC5059, RFC6754, RFC7761, RFC8364) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8736) 8737 Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension. R.B. Shoemaker. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8737) 8738 Automated Certificate Management Environment (ACME) IP Identifier Validation Extension. R.B. Shoemaker. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8738) 8739 Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME). Y. Sheffer, D. Lopez, O. Gonzalez de Dios, A. Pastor Perales, T. Fossati. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8739) 8740 Using TLS 1.3 with HTTP/2. D. Benjamin. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoleted by RFC9113) (Updates RFC7540) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8740) 8741 Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP). A. Raghuram, A. Goddard, J. Karthik, S. Sivabalan, M. Negi. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8741) 8742 Concise Binary Object Representation (CBOR) Sequences. C. Bormann. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8742) 8743 Multiple Access Management Services Multi-Access Management Services (MAMS). S. Kanugovi, F. Baboescu, J. Zhu, S. Seo. March 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8743) 8744 Issues and Requirements for Server Name Identification (SNI) Encryption in TLS. C. Huitema. July 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8744) 8745 Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE. H. Ananthakrishnan, S. Sivabalan, C. Barth, I. Minei, M. Negi. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8745) 8746 Concise Binary Object Representation (CBOR) Tags for Typed Arrays. C. Bormann, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8746) 8747 Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs). M. Jones, L. Seitz, G. Selander, S. Erdtman, H. Tschofenig. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8747) 8748 Registry Fee Extension for the Extensible Provisioning Protocol (EPP). R. Carney, G. Brown, J. Frakes. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8748) 8749 Moving DNSSEC Lookaside Validation (DLV) to Historic Status. W. Mekking, D. Mahoney. March 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC6698, RFC6840) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8749) 8750 Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP). D. Migault, T. Guggemos, Y. Nir. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8750) 8751 Hierarchical Stateful Path Computation Element (PCE). D. Dhody, Y. Lee, D. Ceccarelli, J. Shin, D. King. March 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8751) 8752 Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE). M. Thomson, M. Nottingham. March 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8752) 8753 Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions. J. Klensin, P. Fältström. April 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5892) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8753) 8754 IPv6 Segment Routing Header (SRH). C. Filsfils, Ed., D. Dukes, Ed., S. Previdi, J. Leddy, S. Matsushima, D. Voyer. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8754) 8755 Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions. M. Jenkins. March 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8755) 8756 Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS. M. Jenkins, L. Zieglar. March 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8756) 8757 Dynamic Link Exchange Protocol (DLEP) Latency Range Extension. B. Cheng, L. Berger, Ed.. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8757) 8758 Deprecating RC4 in Secure Shell (SSH). L. Velvindron. April 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC4253) (Also BCP0227) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8758) 8759 RTP Payload for Timed Text Markup Language (TTML). J. Sandford. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8759) 8760 The Session Initiation Protocol (SIP) Digest Access Authentication Scheme. R. Shekh-Yusef. March 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8760) 8761 Video Codec Requirements and Evaluation Methodology. A. Filippov, A. Norkin, J.R. Alvarez. April 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8761) 8762 Simple Two-Way Active Measurement Protocol. G. Mirsky, G. Jun, H. Nydell, R. Foote. March 2020. (Format: HTML, TXT, PDF, XML) (Updated by RFC8972) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8762) 8763 Deployment Considerations for Information-Centric Networking (ICN). A. Rahman, D. Trossen, D. Kutscher, R. Ravindran. April 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8763) 8764 Apple's DNS Long-Lived Queries Protocol. S. Cheshire, M. Krochmal. June 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8764) 8765 DNS Push Notifications. T. Pusateri, S. Cheshire. June 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8765) 8766 Discovery Proxy for Multicast DNS-Based Service Discovery. S. Cheshire. June 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8766) 8767 Serving Stale Data to Improve DNS Resiliency. D. Lawrence, W. Kumari, P. Sood. March 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC1034, RFC1035, RFC2181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8767) 8768 Constrained Application Protocol (CoAP) Hop-Limit Option. M. Boucadair, T. Reddy.K, J. Shallow. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8768) 8769 Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR). J. Schaad. March 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8769) 8770 Host Router Support for OSPFv2. K. Patel, P. Pillay-Esnault, M. Bhardwaj, S. Bayraktar. April 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC6987) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8770) 8771 The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO). A. Mayrhofer, J. Hague. 1 April 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8771) 8772 The China Mobile, Huawei, and ZTE Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP). S. Hu, D. Eastlake, F. Qin, T. Chua, D. Huang. May 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8772) 8773 TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key. R. Housley. March 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8773) 8774 The Quantum Bug. M. Welzl. 1 April 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8774) 8775 PIM Designated Router Load Balancing. Y. Cai, H. Ou, S. Vallepalli, M. Mishra, S. Venaas, A. Green. April 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8775) 8776 Common YANG Data Types for Traffic Engineering. T. Saad, R. Gandhi, X. Liu, V. Beeram, I. Bryskin. June 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8776) 8777 DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery. J. Holland. April 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC7450) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8777) 8778 Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE). R. Housley. April 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8778) 8779 Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS. C. Margaria, Ed., O. Gonzalez de Dios, Ed., F. Zhang, Ed.. July 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8779) 8780 The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA). Y. Lee, Ed., R. Casellas, Ed.. July 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8780) 8781 Discovering PREF64 in Router Advertisements. L. Colitti, J. Linkova. April 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8781) 8782 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification. T. Reddy.K, Ed., M. Boucadair, Ed., P. Patil, A. Mortensen, N. Teague. May 2020. (Format: HTML, TXT, PDF, XML) (Obsoleted by RFC9132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8782) 8783 Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification. M. Boucadair, Ed., T. Reddy.K, Ed.. May 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8783) 8784 Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security. S. Fluhrer, P. Kampanakis, D. McGrew, V. Smyslov. June 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8784) 8785 JSON Canonicalization Scheme (JCS). A. Rundgren, B. Jordan, S. Erdtman. June 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8785) 8786 Updated Rules for Processing Stateful PCE Request Parameters Flags. A. Farrel. May 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC8231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8786) 8787 Location Source Parameter for the SIP Geolocation Header Field. J. Winterbottom, R. Jesske, B. Chatras, A. Hutton. May 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC6442) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8787) 8788 Eligibility for the 2020-2021 Nominating Committee. B. Leiba. May 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8788) 8789 IETF Stream Documents Require IETF Rough Consensus. J. Halpern, Ed., E. Rescorla, Ed.. June 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8789) 8790 FETCH and PATCH with Sensor Measurement Lists (SenML). A. Keränen, M. Mohajer. June 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8790) 8791 YANG Data Structure Extensions. A. Bierman, M. Björklund, K. Watsen. June 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC8340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8791) 8792 Handling Long Lines in Content of Internet-Drafts and RFCs. K. Watsen, E. Auerswald, A. Farrel, Q. Wu. June 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8792) 8793 Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology. B. Wissingh, C. Wood, A. Afanasyev, L. Zhang, D. Oran, C. Tschudin. June 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8793) 8794 Extensible Binary Meta Language. S. Lhomme, D. Rice, M. Bunkus. July 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8794) 8795 YANG Data Model for Traffic Engineering (TE) Topologies. X. Liu, I. Bryskin, V. Beeram, T. Saad, H. Shah, O. Gonzalez de Dios. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8795) 8796 RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels. M. Taillon, T. Saad, Ed., R. Gandhi, A. Deshmukh, M. Jork, V. Beeram. July 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC4090) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8796) 8797 Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1. C. Lever. June 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC8166) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8797) 8798 Additional Units for Sensor Measurement Lists (SenML). C. Bormann. June 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8798) 8799 Limited Domains and Internet Protocols. B. Carpenter, B. Liu. July 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8799) 8800 Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling. S. Litkowski, S. Sivabalan, C. Barth, M. Negi. July 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8800) 8801 Discovering Provisioning Domain Names and Data. P. Pfister, É. Vyncke, T. Pauly, D. Schinazi, W. Shao. July 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8801) 8802 The Quality for Service (Q4S) Protocol. J.J. Aranda, M. Cortes, J. Salvachúa, M. Narganes, I. Martínez-Sarriegui. July 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8802) 8803 0-RTT TCP Convert Protocol. O. Bonaventure, Ed., M. Boucadair, Ed., S. Gundavelli, S. Seo, B. Hesmans. July 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8803) 8804 Content Delivery Network Interconnection (CDNI) Request Routing Extensions. O. Finkelman, S. Mishra. September 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8804) 8805 A Format for Self-Published IP Geolocation Feeds. E. Kline, K. Duleba, Z. Szamonek, S. Moser, W. Kumari. August 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8805) 8806 Running a Root Server Local to a Resolver. W. Kumari, P. Hoffman. June 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7706) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8806) 8807 Login Security Extension for the Extensible Provisioning Protocol (EPP). J. Gould, M. Pozun. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8807) 8808 A YANG Data Model for Factory Default Settings. Q. Wu, B. Lengyel, Y. Niu. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8808) 8809 Registries for Web Authentication (WebAuthn). J. Hodges, G. Mandyam, M. Jones. August 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8809) 8810 Revision to Capability Codes Registration Procedures. J. Scudder. August 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5492) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8810) 8811 DDoS Open Threat Signaling (DOTS) Architecture. A. Mortensen, Ed., T. Reddy.K, Ed., F. Andreasen, N. Teague, R. Compton. August 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8811) 8812 CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms. M. Jones. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8812) 8813 Clarifications for Elliptic Curve Cryptography Subject Public Key Information. T. Ito, S. Turner. August 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5480) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8813) 8814 Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State. J. Tantsura, U. Chunduri, K. Talaulikar, G. Mirsky, N. Triantafillis. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8814) 8815 Deprecating Any-Source Multicast (ASM) for Interdomain Multicast. M. Abrahamsson, T. Chown, L. Giuliano, T. Eckert. August 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0229) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8815) 8816 Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases. E. Rescorla, J. Peterson. February 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8816) 8817 RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec. V. Demjanenko, J. Punaro, D. Satterlee. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8817) 8818 Distributed Mobility Anchoring. H. Chan, Ed., X. Wei, J. Lee, S. Jeon, CJ. Bernardos, Ed.. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8818) 8819 YANG Module Tags. C. Hopps, L. Berger, D. Bogdanovic. January 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC8407) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8819) 8820 URI Design and Ownership. M. Nottingham. June 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7320) (Updates RFC3986) (Also BCP0190) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8820) 8821 PCE-Based Traffic Engineering (TE) in Native IP Networks. A. Wang, B. Khasanov, Q. Zhao, H. Chen. April 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8821) 8822 5G Wireless Wireline Convergence User Plane Encapsulation (5WE). D. Allan, Ed., D. Eastlake, D. Woolley. April 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8822) 8823 Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates. A. Melnikov. April 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8823) 8824 Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP). A. Minaburo, L. Toutain, R. Andreasen. June 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8824) 8825 Overview: Real-Time Protocols for Browser-Based Applications. H. Alvestrand. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8825) 8826 Security Considerations for WebRTC. E. Rescorla. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8826) 8827 WebRTC Security Architecture. E. Rescorla. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8827) 8828 WebRTC IP Address Handling Requirements. J. Uberti, G. Shieh. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8828) 8829 JavaScript Session Establishment Protocol (JSEP). J. Uberti, C. Jennings, E. Rescorla, Ed.. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8829) 8830 WebRTC MediaStream Identification in the Session Description Protocol. H. Alvestrand. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8830) 8831 WebRTC Data Channels. R. Jesup, S. Loreto, M. Tüxen. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8831) 8832 WebRTC Data Channel Establishment Protocol. R. Jesup, S. Loreto, M. Tüxen. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8832) 8833 Application-Layer Protocol Negotiation (ALPN) for WebRTC. M. Thomson. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8833) 8834 Media Transport and Use of RTP in WebRTC. C. Perkins, M. Westerlund, J. Ott. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8834) 8835 Transports for WebRTC. H. Alvestrand. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8835) 8836 Congestion Control Requirements for Interactive Real-Time Media. R. Jesup, Z. Sarker, Ed.. January 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8836) 8837 Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS. P. Jones, S. Dhesikan, C. Jennings, D. Druta. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8837) 8838 Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol. E. Ivov, J. Uberti, P. Saint-Andre. January 2021. (Format: HTML, TXT, PDF, XML) (Updated by RFC8863) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8838) 8839 Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE). M. Petit-Huguenin, S. Nandakumar, C. Holmberg, A. Keränen, R. Shpount. January 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC5245, RFC6336) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8839) 8840 A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE). E. Ivov, T. Stach, E. Marocco, C. Holmberg. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8840) 8841 Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. C. Holmberg, R. Shpount, S. Loreto, G. Camarillo. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8841) 8842 Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS). C. Holmberg, R. Shpount. January 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC5763, RFC7345) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8842) 8843 Negotiating Media Multiplexing Using the Session Description Protocol (SDP). C. Holmberg, H. Alvestrand, C. Jennings. January 2021. (Format: HTML, TXT, PDF, XML) (Obsoleted by RFC9143) (Updates RFC3264, RFC5888, RFC7941) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8843) 8844 Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP). M. Thomson, E. Rescorla. January 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC8122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8844) 8845 Framework for Telepresence Multi-Streams. M. Duckworth, Ed., A. Pepperell, S. Wenger. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8845) 8846 An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model. R. Presta, S P. Romano. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8846) 8847 Protocol for Controlling Multiple Streams for Telepresence (CLUE). R. Presta, S P. Romano. January 2021. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8847) 8848 Session Signaling for Controlling Multiple Streams for Telepresence (CLUE). R. Hanton, P. Kyzivat, L. Xiao, C. Groves. January 2021. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8848) 8849 Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures. R. Even, J. Lennox. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8849) 8850 Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel. C. Holmberg. January 2021. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8850) 8851 RTP Payload Format Restrictions. A.B. Roach, Ed.. January 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC4855) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8851) 8852 RTP Stream Identifier Source Description (SDES). A.B. Roach, S. Nandakumar, P. Thatcher. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8852) 8853 Using Simulcast in Session Description Protocol (SDP) and RTP Sessions. B. Burman, M. Westerlund, S. Nandakumar, M. Zanaty. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8853) 8854 WebRTC Forward Error Correction Requirements. J. Uberti. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8854) 8855 The Binary Floor Control Protocol (BFCP). G. Camarillo, K. Drage, T. Kristensen, J. Ott, C. Eckel. January 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC4582) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8855) 8856 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams. G. Camarillo, T. Kristensen, C. Holmberg. January 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC4583) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8856) 8857 The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP). V. Pascual, A. Román, S. Cazeaux, G. Salgueiro, R. Ravindranath. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8857) 8858 Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP). C. Holmberg. January 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC5761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8858) 8859 A Framework for Session Description Protocol (SDP) Attributes When Multiplexing. S. Nandakumar. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8859) 8860 Sending Multiple Types of Media in a Single RTP Session. M. Westerlund, C. Perkins, J. Lennox. January 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC3550, RFC3551) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8860) 8861 Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback. J. Lennox, M. Westerlund, Q. Wu, C. Perkins. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8861) 8862 Best Practices for Securing RTP Media Signaled with SIP. J. Peterson, R. Barnes, R. Housley. January 2021. (Format: HTML, TXT, PDF, XML) (Also BCP0228) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8862) 8863 Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC). C. Holmberg, J. Uberti. January 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC8445, RFC8838) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8863) 8864 Negotiation Data Channels Using the Session Description Protocol (SDP). K. Drage, M. Makaraju, R. Ejzak, J. Marcon, R. Even, Ed.. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8864) 8865 T.140 Real-Time Text Conversation over WebRTC Data Channels. C. Holmberg, G. Hellström. January 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC8373) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8865) 8866 SDP: Session Description Protocol. A. Begen, P. Kyzivat, C. Perkins, M. Handley. January 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC4566) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8866) 8867 Test Cases for Evaluating Congestion Control for Interactive Real-Time Media. Z. Sarker, V. Singh, X. Zhu, M. Ramalho. January 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8867) 8868 Evaluating Congestion Control for Interactive Real-Time Media. V. Singh, J. Ott, S. Holmer. January 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8868) 8869 Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks. Z. Sarker, X. Zhu, J. Fu. January 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8869) 8870 Encrypted Key Transport for DTLS and Secure RTP. C. Jennings, J. Mattsson, D. McGrew, D. Wing, F. Andreasen. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8870) 8871 A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC). P. Jones, D. Benham, C. Groves. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8871) 8872 Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams. M. Westerlund, B. Burman, C. Perkins, H. Alvestrand, R. Even. January 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8872) 8873 Message Session Relay Protocol (MSRP) over Data Channels. JM. Recio, Ed., C. Holmberg. January 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC4975) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8873) 8874 Working Group GitHub Usage Guidance. M. Thomson, B. Stark. August 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8874) 8875 Working Group GitHub Administration. A. Cooper, P. Hoffman. August 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8875) 8876 Non-interactive Emergency Calls. B. Rosen, H. Schulzrinne, H. Tschofenig, R. Gellens. September 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8876) 8877 Guidelines for Defining Packet Timestamps. T. Mizrahi, J. Fabini, A. Morton. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8877) 8878 Zstandard Compression and the 'application/zstd' Media Type. Y. Collet, M. Kucherawy, Ed.. February 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC8478) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8878) 8879 TLS Certificate Compression. A. Ghedini, V. Vasiliev. December 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8879) 8880 Special Use Domain Name 'ipv4only.arpa'. S. Cheshire, D. Schinazi. August 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC7050) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8880) 8881 Network File System (NFS) Version 4 Minor Version 1 Protocol. D. Noveck, Ed., C. Lever. August 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC5661) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8881) 8882 DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements. C. Huitema, D. Kaiser. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8882) 8883 ICMPv6 Errors for Discarding Packets Due to Processing Limits. T. Herbert. September 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8883) 8884 Research Directions for Using Information-Centric Networking (ICN) in Disaster Scenarios. J. Seedorf, M. Arumaithurai, A. Tagami, K. Ramakrishnan, N. Blefari-Melazzi. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8884) 8885 Proxy Mobile IPv6 Extensions for Distributed Mobility Management. CJ. Bernardos, A. de la Oliva, F. Giust, JC. Zúñiga, A. Mourad. October 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8885) 8886 Secure Device Install. W. Kumari, C. Doyle. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8886) 8887 A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket. K. Murchison. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8887) 8888 RTP Control Protocol (RTCP) Feedback for Congestion Control. Z. Sarker, C. Perkins, V. Singh, M. Ramalho. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8888) 8889 Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring. G. Fioccola, Ed., M. Cociglio, A. Sapio, R. Sisto. August 2020. (Format: HTML, TXT, PDF, XML) (Obsoleted by RFC9342) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8889) 8890 The Internet is for End Users. M. Nottingham. August 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8890) 8891 GOST R 34.12-2015: Block Cipher "Magma". V. Dolmatov, Ed., D. Baryshkov. September 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5830) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8891) 8892 Guidelines and Registration Procedures for Interface Types and Tunnel Types. D. Thaler, D. Romascanu. August 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC2863) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8892) 8893 Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export. R. Bush, R. Volk, J. Heitz. September 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC6811) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8893) 8894 Simple Certificate Enrolment Protocol. P. Gutmann. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8894) 8895 Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE). W. Roome, Y. Yang. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8895) 8896 Application-Layer Traffic Optimization (ALTO) Cost Calendar. S. Randriamasy, R. Yang, Q. Wu, L. Deng, N. Schwan. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8896) 8897 Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties. D. Ma, S. Kent. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8897) 8898 Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP). R. Shekh-Yusef, C. Holmberg, V. Pascual. September 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8898) 8899 Packetization Layer Path MTU Discovery for Datagram Transports. G. Fairhurst, T. Jones, M. Tüxen, I. Rüngeler, T. Völker. September 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC4821, RFC4960, RFC6951, RFC8085, RFC8261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8899) 8900 IP Fragmentation Considered Fragile. R. Bonica, F. Baker, G. Huston, R. Hinden, O. Troan, F. Gont. September 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0230) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8900) 8901 Multi-Signer DNSSEC Models. S. Huque, P. Aras, J. Dickinson, J. Vcelak, D. Blacka. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8901) 8902 TLS Authentication Using Intelligent Transport System (ITS) Certificates. M. Msahli, Ed., N. Cam-Winget, Ed., W. Whyte, Ed., A. Serhrouchni, H. Labiod. September 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8902) 8903 Use Cases for DDoS Open Threat Signaling. R. Dobbins, D. Migault, R. Moskowitz, N. Teague, L. Xia, K. Nishizuka. May 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8903) 8904 DNS Whitelist (DNSWL) Email Authentication Method Extension. A. Vesely. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8904) 8905 The 'payto' URI Scheme for Payments. F. Dold, C. Grothoff. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8905) 8906 A Common Operational Problem in DNS Servers: Failure to Communicate. M. Andrews, R. Bellis. September 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0231) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8906) 8907 The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol. T. Dahm, A. Ota, D.C. Medway Gash, D. Carrel, L. Grant. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8907) 8908 Captive Portal API. T. Pauly, Ed., D. Thakore, Ed.. September 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8908) 8909 Registry Data Escrow Specification. G. Lozano. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8909) 8910 Captive-Portal Identification in DHCP and Router Advertisements (RAs). W. Kumari, E. Kline. September 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7710) (Updates RFC3679) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8910) 8911 Registry for Performance Metrics. M. Bagnulo, B. Claise, P. Eardley, A. Morton, A. Akhter. November 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8911) 8912 Initial Performance Metrics Registry Entries. A. Morton, M. Bagnulo, P. Eardley, K. D'Souza. November 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8912) 8913 Two-Way Active Measurement Protocol (TWAMP) YANG Data Model. R. Civil, A. Morton, R. Rahman, M. Jethanandani, K. Pentikousis, Ed.. November 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8913) 8914 Extended DNS Errors. W. Kumari, E. Hunt, R. Arends, W. Hardaker, D. Lawrence. October 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8914) 8915 Network Time Security for the Network Time Protocol. D. Franke, D. Sibold, K. Teichel, M. Dansarie, R. Sundblad. September 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8915) 8916 A YANG Data Model for the Multicast Source Discovery Protocol (MSDP). X. Liu, Z. Zhang, Ed., A. Peter, M. Sivakumar, F. Guo, P. McAllister. October 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8916) 8917 The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag. R. Gellens, B. Rosen. October 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8917) 8918 Invalid TLV Handling in IS-IS. L. Ginsberg, P. Wells, T. Li, T. Przygienda, S. Hegde. September 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5305, RFC6232) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8918) 8919 IS-IS Application-Specific Link Attributes. L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake. October 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8919) 8920 OSPF Application-Specific Link Attributes. P. Psenak, Ed., L. Ginsberg, W. Henderickx, J. Tantsura, J. Drake. October 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8920) 8921 Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP). M. Boucadair, Ed., C. Jacquenet, D. Zhang, P. Georgatsos. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8921) 8922 A Survey of the Interaction between Security Protocols and Transport Services. T. Enghardt, T. Pauly, C. Perkins, K. Rose, C. Wood. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8922) 8923 A Minimal Set of Transport Services for End Systems. M. Welzl, S. Gjessing. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8923) 8924 Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework. S. Aldrin, C. Pignataro, Ed., N. Kumar, Ed., R. Krishnan, A. Ghanwani. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8924) 8925 IPv6-Only Preferred Option for DHCPv4. L. Colitti, J. Linkova, M. Richardson, T. Mrugalski. October 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC2563) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8925) 8926 Geneve: Generic Network Virtualization Encapsulation. J. Gross, Ed., I. Ganga, Ed., T. Sridhar, Ed.. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8926) 8927 JSON Type Definition. U. Carion. November 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8927) 8928 Address-Protected Neighbor Discovery for Low-Power and Lossy Networks. P. Thubert, Ed., B. Sarikaya, M. Sethi, R. Struik. November 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC8505) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8928) 8929 IPv6 Backbone Router. P. Thubert, Ed., C.E. Perkins, E. Levy-Abegnoli. November 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC6775, RFC8505) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8929) 8930 On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network. T. Watteyne, Ed., P. Thubert, Ed., C. Bormann. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8930) 8931 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery. P. Thubert, Ed.. November 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC4944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8931) 8932 Recommendations for DNS Privacy Service Operators. S. Dickinson, B. Overeinder, R. van Rijswijk-Deij, A. Mankin. October 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0232) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8932) 8933 Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection. R. Housley. October 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5652) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8933) 8934 PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE. H. Chen, Ed., Y. Zhuang, Ed., Q. Wu, D. Ceccarelli. October 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8934) 8935 Push-Based Security Event Token (SET) Delivery Using HTTP. A. Backman, Ed., M. Jones, Ed., M. Scurtescu, M. Ansari, A. Nadalin. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8935) 8936 Poll-Based Security Event Token (SET) Delivery Using HTTP. A. Backman, Ed., M. Jones, Ed., M. Scurtescu, M. Ansari, A. Nadalin. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8936) 8937 Randomness Improvements for Security Protocols. C. Cremers, L. Garratt, S. Smyshlyaev, N. Sullivan, C. Wood. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8937) 8938 Deterministic Networking (DetNet) Data Plane Framework. B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant. November 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8938) 8939 Deterministic Networking (DetNet) Data Plane: IP. B. Varga, Ed., J. Farkas, L. Berger, D. Fedyk, S. Bryant. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8939) 8940 Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP). A. DeKok. October 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5247) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8940) 8941 Structured Field Values for HTTP. M. Nottingham, P-H. Kamp. February 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8941) 8942 HTTP Client Hints. I. Grigorik, Y. Weiss. February 2021. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8942) 8943 Concise Binary Object Representation (CBOR) Tags for Date. M. Jones, A. Nadalin, J. Richter. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8943) 8944 A YANG Data Model for Layer 2 Network Topologies. J. Dong, X. Wei, Q. Wu, M. Boucadair, A. Liu. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8944) 8945 Secret Key Transaction Authentication for DNS (TSIG). F. Dupont, S. Morris, P. Vixie, D. Eastlake 3rd, O. Gudmundsson, B. Wellington. November 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC2845, RFC4635) (Also STD0093) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8945) 8946 Personal Assertion Token (PASSporT) Extension for Diverted Calls. J. Peterson. February 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC8224) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8946) 8947 Link-Layer Address Assignment Mechanism for DHCPv6. B. Volz, T. Mrugalski, C. Bernardos. December 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8947) 8948 Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6. CJ. Bernardos, A. Mourad. December 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8948) 8949 Concise Binary Object Representation (CBOR). C. Bormann, P. Hoffman. December 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7049) (Also STD0094) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8949) 8950 Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop. S. Litkowski, S. Agrawal, K. Ananthamurthy, K. Patel. November 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC5549) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8950) 8951 Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1. M. Richardson, T. Werner, W. Pan. November 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC7030) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8951) 8952 Captive Portal Architecture. K. Larose, D. Dolson, H. Liu. November 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8952) 8953 Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report. K. Moriarty. December 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8953) 8954 Online Certificate Status Protocol (OCSP) Nonce Extension. M. Sahni, Ed.. November 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC6960) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8954) 8955 Dissemination of Flow Specification Rules. C. Loibl, S. Hares, R. Raszuk, D. McPherson, M. Bacher. December 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC5575, RFC7674) (Updated by RFC8956, RFC9117, RFC9184) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8955) 8956 Dissemination of Flow Specification Rules for IPv6. C. Loibl, Ed., R. Raszuk, Ed., S. Hares, Ed.. December 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC8955) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8956) 8957 Synonymous Flow Label Framework. S. Bryant, M. Chen, G. Swallow, S. Sivabalan, G. Mirsky. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8957) 8958 Updated Registration Rules for URI.ARPA. T. Hardie. December 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC3405) (Also BCP0065) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8958) 8959 The "secret-token" URI Scheme. M. Nottingham. January 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8959) 8960 A YANG Data Model for MPLS Base. T. Saad, K. Raza, R. Gandhi, X. Liu, V. Beeram. December 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8960) 8961 Requirements for Time-Based Loss Detection. M. Allman. November 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0233) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8961) 8962 Establishing the Protocol Police. G. Grover, N. ten Oever, C. Cath, S. Sahib. 1 April 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8962) 8963 Evaluation of a Sample of RFCs Produced in 2018. C. Huitema. January 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8963) 8964 Deterministic Networking (DetNet) Data Plane: MPLS. B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant, J. Korhonen. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8964) 8965 Applicability of the Babel Routing Protocol. J. Chroboczek. January 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8965) 8966 The Babel Routing Protocol. J. Chroboczek, D. Schinazi. January 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6126, RFC7557) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8966) 8967 MAC Authentication for the Babel Routing Protocol. C. Dô, W. Kolodziejak, J. Chroboczek. January 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7298) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8967) 8968 Babel Routing Protocol over Datagram Transport Layer Security. A. Décimo, D. Schinazi, J. Chroboczek. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8968) 8969 A Framework for Automating Service and Network Management with YANG. Q. Wu, Ed., M. Boucadair, Ed., D. Lopez, C. Xie, L. Geng. January 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8969) 8970 IMAP4 Extension: Message Preview Generation. M. Slusarz. December 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8970) 8971 Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN). S. Pallagatti, Ed., G. Mirsky, Ed., S. Paragiri, V. Govindan, M. Mudigonda. December 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8971) 8972 Simple Two-Way Active Measurement Protocol Optional Extensions. G. Mirsky, X. Min, H. Nydell, R. Foote, A. Masputra, E. Ruffini. January 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC8762) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8972) 8973 DDoS Open Threat Signaling (DOTS) Agent Discovery. M. Boucadair, T. Reddy.K. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8973) 8974 Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP). K. Hartke, M. Richardson. January 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC7252, RFC8323) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8974) 8975 Network Coding for Satellite Systems. N. Kuhn, Ed., E. Lochin, Ed.. January 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8975) 8976 Message Digest for DNS Zones. D. Wessels, P. Barber, M. Weinberg, W. Kumari, W. Hardaker. February 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8976) 8977 Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging. M. Loffredo, M. Martinelli, S. Hollenbeck. January 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8977) 8978 Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events. F. Gont, J. Žorž, R. Patterson. March 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8978) 8979 Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH). B. Sarikaya, D. von Hugo, M. Boucadair. February 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8979) 8980 Report from the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol Development. J. Arkko, T. Hardie. February 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8980) 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6. F. Gont, S. Krishnan, T. Narten, R. Draves. February 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC4941) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8981) 8982 Registration Data Access Protocol (RDAP) Partial Response. M. Loffredo, M. Martinelli. February 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8982) 8983 Internet Key Exchange Protocol Version 2 (IKEv2) Notification Status Types for IPv4/IPv6 Coexistence. M. Boucadair. February 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC7296) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8983) 8984 JSCalendar: A JSON Representation of Calendar Data. N. Jenkins, R. Stepanek. July 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8984) 8985 The RACK-TLP Loss Detection Algorithm for TCP. Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha. February 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8985) 8986 Segment Routing over IPv6 (SRv6) Network Programming. C. Filsfils, Ed., P. Camarillo, Ed., J. Leddy, D. Voyer, S. Matsushima, Z. Li. February 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8986) 8987 DHCPv6 Prefix Delegating Relay Requirements. I. Farrer, N. Kottapalli, M. Hunek, R. Patterson. February 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8987) 8989 Additional Criteria for Nominating Committee Eligibility. B. Carpenter, S. Farrell. February 2021. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8989) 8990 GeneRic Autonomic Signaling Protocol (GRASP). C. Bormann, B. Carpenter, Ed., B. Liu, Ed.. May 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8990) 8991 GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API). B. Carpenter, B. Liu, Ed., W. Wang, X. Gong. May 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8991) 8992 Autonomic IPv6 Edge Prefix Management in Large-Scale Networks. S. Jiang, Ed., Z. Du, B. Carpenter, Q. Sun. May 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8992) 8993 A Reference Model for Autonomic Networking. M. Behringer, Ed., B. Carpenter, T. Eckert, L. Ciavaglia, J. Nobre. May 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8993) 8994 An Autonomic Control Plane (ACP). T. Eckert, Ed., M. Behringer, Ed., S. Bjarnason. May 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8994) 8995 Bootstrapping Remote Secure Key Infrastructure (BRSKI). M. Pritikin, M. Richardson, T. Eckert, M. Behringer, K. Watsen. May 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8995) 8996 Deprecating TLS 1.0 and TLS 1.1. K. Moriarty, S. Farrell. March 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC5469, RFC7507) (Updates RFC3261, RFC3329, RFC3436, RFC3470, RFC3501, RFC3552, RFC3568, RFC3656, RFC3749, RFC3767, RFC3856, RFC3871, RFC3887, RFC3903, RFC3943, RFC3983, RFC4097, RFC4111, RFC4162, RFC4168, RFC4217, RFC4235, RFC4261, RFC4279, RFC4497, RFC4513, RFC4531, RFC4540, RFC4582, RFC4616, RFC4642, RFC4680, RFC4681, RFC4712, RFC4732, RFC4743, RFC4744, RFC4785, RFC4791, RFC4823, RFC4851, RFC4964, RFC4975, RFC4976, RFC4992, RFC5018, RFC5019, RFC5023, RFC5024, RFC5049, RFC5054, RFC5091, RFC5158, RFC5216, RFC5238, RFC5263, RFC5281, RFC5364, RFC5415, RFC5422, RFC5456, RFC5734, RFC5878, RFC5953, RFC6012, RFC6042, RFC6083, RFC6084, RFC6176, RFC6347, RFC6353, RFC6367, RFC6460, RFC6614, RFC6739, RFC6749, RFC6750, RFC7030, RFC7465, RFC7525, RFC7562, RFC7568, RFC8261, RFC8422) (Also BCP0195) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8996) 8997 Deprecation of TLS 1.1 for Email Submission and Access. L. Velvindron, S. Farrell. March 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC8314) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8997) 8998 ShangMi (SM) Cipher Suites for TLS 1.3. P. Yang. March 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8998) 8999 Version-Independent Properties of QUIC. M. Thomson. May 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8999) 9000 QUIC: A UDP-Based Multiplexed and Secure Transport. J. Iyengar, Ed., M. Thomson, Ed.. May 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9000) 9001 Using TLS to Secure QUIC. M. Thomson, Ed., S. Turner, Ed.. May 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9001) 9002 QUIC Loss Detection and Congestion Control. J. Iyengar, Ed., I. Swett, Ed.. May 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9002) 9003 Extended BGP Administrative Shutdown Communication. J. Snijders, J. Heitz, J. Scudder, A. Azimov. January 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC8203) (Updates RFC4486) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9003) 9004 Updates for the Back-to-Back Frame Benchmark in RFC 2544. A. Morton. May 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC2544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9004) 9005 Path Computation Element Communication Protocol (PCEP) Extension for Associating Policies and Label Switched Paths (LSPs). S. Litkowski, S. Sivabalan, J. Tantsura, J. Hardwick, C. Li. March 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9005) 9006 TCP Usage Guidance in the Internet of Things (IoT). C. Gomez, J. Crowcroft, M. Scharf. March 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9006) 9007 Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP). R. Ouazana, Ed.. March 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9007) 9008 Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane. M.I. Robles, M. Richardson, P. Thubert. April 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC6553, RFC6550, RFC8138) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9008) 9009 Efficient Route Invalidation. R.A. Jadhav, Ed., P. Thubert, R.N. Sahoo, Z. Cao. April 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9009) 9010 Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves. P. Thubert, Ed., M. Richardson. April 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC6550, RFC6775, RFC8505) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9010) 9011 Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN. O. Gimenez, Ed., I. Petrov, Ed.. April 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9011) 9012 The BGP Tunnel Encapsulation Attribute. K. Patel, G. Van de Velde, S. Sangli, J. Scudder. April 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC5512, RFC5566) (Updates RFC5640) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9012) 9013 OSPF Advertisement of Tunnel Encapsulations. X. Xu, Ed., B. Decraene, Ed., R. Raszuk, L. Contreras, L. Jalil. April 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9013) 9014 Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks. J. Rabadan, Ed., S. Sathappan, W. Henderickx, A. Sajassi, J. Drake. May 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9014) 9015 BGP Control Plane for the Network Service Header in Service Function Chaining. A. Farrel, J. Drake, E. Rosen, J. Uttaro, L. Jalil. June 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9015) 9016 Flow and Service Information Model for Deterministic Networking (DetNet). B. Varga, J. Farkas, R. Cummings, Y. Jiang, D. Fedyk. March 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9016) 9017 Special-Purpose Label Terminology. L. Andersson, K. Kompella, A. Farrel. April 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC3032, RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9017) 9018 Interoperable Domain Name System (DNS) Server Cookies. O. Sury, W. Toorop, D. Eastlake 3rd, M. Andrews. April 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC7873) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9018) 9019 A Firmware Update Architecture for Internet of Things. B. Moran, H. Tschofenig, D. Brown, M. Meriac. April 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9019) 9020 YANG Data Model for Segment Routing. S. Litkowski, Y. Qu, A. Lindem, P. Sarkar, J. Tantsura. May 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9020) 9021 Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE). D. Atkins. May 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9021) 9022 Domain Name Registration Data (DNRD) Objects Mapping. G. Lozano, J. Gould, C. Thippeswamy. May 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9022) 9023 Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN). B. Varga, Ed., J. Farkas, A. Malis, S. Bryant. June 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9023) 9024 Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS. B. Varga, Ed., J. Farkas, A. Malis, S. Bryant, D. Fedyk. June 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9024) 9025 Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP. B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant. April 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9025) 9026 Multicast VPN Fast Upstream Failover. T. Morin, Ed., R. Kebler, Ed., G. Mirsky, Ed.. April 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9026) 9027 Assertion Values for Resource Priority Header and SIP Priority Header Claims in Support of Emergency Services Networks. M. Dolly, C. Wendt. June 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9027) 9028 Native NAT Traversal Mode for the Host Identity Protocol. A. Keränen, J. Melén, M. Komu, Ed.. July 2021. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9028) 9029 Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries. A. Farrel. June 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC7752) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9029) 9030 An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH). P. Thubert, Ed.. May 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9030) 9031 Constrained Join Protocol (CoJP) for 6TiSCH. M. Vučinić, Ed., J. Simon, K. Pister, M. Richardson. May 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9031) 9032 Encapsulation of 6TiSCH Join and Enrollment Information Elements. D. Dujovne, Ed., M. Richardson. May 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9032) 9033 6TiSCH Minimal Scheduling Function (MSF). T. Chang, Ed., M. Vučinić, X. Vilajosana, S. Duquennoy, D. Dujovne. May 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9033) 9034 Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). L. Thomas, S. Anamalamudi, S.V.R. Anand, M. Hegde, C. Perkins. June 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9034) 9035 A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header. P. Thubert, Ed., L. Zhao. April 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC8138) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9035) 9036 Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy. R. Gellens. June 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC5222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9036) 9037 Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN). B. Varga, Ed., J. Farkas, A. Malis, S. Bryant. June 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9037) 9038 Extensible Provisioning Protocol (EPP) Unhandled Namespaces. J. Gould, M. Casanova. May 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9038) 9039 Uniform Resource Names for Device Identifiers. J. Arkko, C. Jennings, Z. Shelby. June 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9039) 9040 TCP Control Block Interdependence. J. Touch, M. Welzl, S. Islam. July 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC2140) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9040) 9041 Updating the MPLS Label Switched Paths (LSPs) Ping Parameters IANA Registry. L. Andersson, M. Chen, C. Pignataro, T. Saad. July 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC8029, RFC8611) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9041) 9042 Sieve Email Filtering: Delivery by MAILBOXID. B. Gondwana, Ed.. June 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC5228) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9042) 9043 FFV1 Video Coding Format Versions 0, 1, and 3. M. Niedermayer, D. Rice, J. Martinez. August 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9043) 9044 Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS). R. Housley. June 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9044) 9045 Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF). R. Housley. June 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC4211) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9045) 9046 Babel Information Model. B. Stark, M. Jethanandani. June 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9046) 9047 Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN). J. Rabadan, Ed., S. Sathappan, K. Nagaraj, W. Lin. June 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9047) 9048 Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA'). J. Arkko, V. Lehtovirta, V. Torvinen, P. Eronen. October 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC5448, RFC4187) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9048) 9049 Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken). S. Dawkins, Ed.. June 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9049) 9050 Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs. Z. Li, S. Peng, M. Negi, Q. Zhao, C. Zhou. July 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9050) 9051 Internet Message Access Protocol (IMAP) - Version 4rev2. A. Melnikov, Ed., B. Leiba, Ed.. August 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9051) 9052 CBOR Object Signing and Encryption (COSE): Structures and Process. J. Schaad. August 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC8152) (Updated by RFC9338) (Also STD0096) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC9052) 9053 CBOR Object Signing and Encryption (COSE): Initial Algorithms. J. Schaad. August 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC8152) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9053) 9054 CBOR Object Signing and Encryption (COSE): Hash Algorithms. J. Schaad. August 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9054) 9055 Deterministic Networking (DetNet) Security Considerations. E. Grossman, Ed., T. Mizrahi, A. Hacker. June 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9055) 9056 Deterministic Networking (DetNet) Data Plane: IP over MPLS. B. Varga, Ed., L. Berger, D. Fedyk, S. Bryant, J. Korhonen. October 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9056) 9057 Email Author Header Field. D. Crocker. June 2021. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9057) 9058 Multilinear Galois Mode (MGM). S. Smyshlyaev, Ed., V. Nozdrunov, V. Shishkin, E. Griboedova. June 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9058) 9059 Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs). R. Gandhi, Ed., C. Barth, B. Wen. June 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9059) 9060 Secure Telephone Identity Revisited (STIR) Certificate Delegation. J. Peterson. September 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9060) 9061 A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN). R. Marin-Lopez, G. Lopez-Millan, F. Pereniguez-Garcia. July 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9061) 9062 Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM). S. Salam, A. Sajassi, S. Aldrin, J. Drake, D. Eastlake 3rd. June 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9062) 9063 Host Identity Protocol Architecture. R. Moskowitz, Ed., M. Komu. July 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC4423) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9063) 9064 Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols. D. Oran. June 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9064) 9065 Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols. G. Fairhurst, C. Perkins. July 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9065) 9066 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home. T. Reddy.K, M. Boucadair, Ed., J. Shallow. December 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9066) 9067 A YANG Data Model for Routing Policy. Y. Qu, J. Tantsura, A. Lindem, X. Liu. October 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9067) 9068 JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens. V. Bertocci. October 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9068) 9069 Support for Local RIB in the BGP Monitoring Protocol (BMP). T. Evens, S. Bayraktar, M. Bhardwaj, P. Lucente. February 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC7854) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9069) 9070 YANG Data Model for MPLS LDP. K. Raza, Ed., R. Asati, X. Liu, S. Esale, X. Chen, H. Shah. March 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9070) 9071 RTP-Mixer Formatting of Multiparty Real-Time Text. G. Hellström. July 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC4103) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9071) 9072 Extended Optional Parameters Length for BGP OPEN Message. E. Chen, J. Scudder. July 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9072) 9073 Event Publishing Extensions to iCalendar. M. Douglass. August 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC5545) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9073) 9074 "VALARM" Extensions for iCalendar. C. Daboo, K. Murchison, Ed.. August 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC5545) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9074) 9075 Report from the IAB COVID-19 Network Impacts Workshop 2020. J. Arkko, S. Farrell, M. Kühlewind, C. Perkins. July 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9075) 9076 DNS Privacy Considerations. T. Wicinski, Ed.. July 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7626) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9076) 9077 NSEC and NSEC3: TTLs and Aggressive Use. P. van Dijk. July 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC4034, RFC4035, RFC5155, RFC8198) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9077) 9078 Reaction: Indicating Summary Reaction to a Message. D. Crocker, R. Signes, N. Freed. August 2021. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9078) 9079 Source-Specific Routing in the Babel Routing Protocol. M. Boutier, J. Chroboczek. August 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9079) 9080 Homenet Profile of the Babel Routing Protocol. J. Chroboczek. August 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9080) 9081 Interoperation between Multicast Virtual Private Network (MVPN) and Multicast Source Directory Protocol (MSDP) Source-Active Routes. Z. Zhang, L. Giuliano. July 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9081) 9082 Registration Data Access Protocol (RDAP) Query Format. S. Hollenbeck, A. Newton. June 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7482) (Also STD0095) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC9082) 9083 JSON Responses for the Registration Data Access Protocol (RDAP). S. Hollenbeck, A. Newton. June 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7483) (Also STD0095) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC9083) 9084 OSPF Prefix Originator Extensions. A. Wang, A. Lindem, J. Dong, P. Psenak, K. Talaulikar, Ed.. August 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9084) 9085 Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing. S. Previdi, K. Talaulikar, Ed., C. Filsfils, H. Gredler, M. Chen. August 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9085) 9086 Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering. S. Previdi, K. Talaulikar, Ed., C. Filsfils, K. Patel, S. Ray, J. Dong. August 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9086) 9087 Segment Routing Centralized BGP Egress Peer Engineering. C. Filsfils, Ed., S. Previdi, G. Dawra, Ed., E. Aries, D. Afanasiev. August 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9087) 9088 Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS. X. Xu, S. Kini, P. Psenak, C. Filsfils, S. Litkowski, M. Bocci. August 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9088) 9089 Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF. X. Xu, S. Kini, P. Psenak, C. Filsfils, S. Litkowski, M. Bocci. August 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9089) 9090 Concise Binary Object Representation (CBOR) Tags for Object Identifiers. C. Bormann. July 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9090) 9091 Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains. S. Kitterman, T. Wicinski, Ed.. July 2021. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9091) 9092 Finding and Using Geofeed Data. R. Bush, M. Candela, W. Kumari, R. Housley. July 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9092) 9093 A YANG Data Model for Layer 0 Types. H. Zheng, Y. Lee, A. Guo, V. Lopez, D. King. August 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9093) 9094 A YANG Data Model for Wavelength Switched Optical Networks (WSONs). H. Zheng, Y. Lee, A. Guo, V. Lopez, D. King. August 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9094) 9095 Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration. J. Yao, L. Zhou, H. Li, N. Kong, J. Xie. July 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9095) 9096 Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events. F. Gont, J. Žorž, R. Patterson, B. Volz. August 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC7084) (Also BCP0234) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC9096) 9097 Metrics and Methods for One-Way IP Capacity. A. Morton, R. Geib, L. Ciavattone. November 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9097) 9098 Operational Implications of IPv6 Packets with Extension Headers. F. Gont, N. Hilliard, G. Doering, W. Kumari, G. Huston, W. Liu. September 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9098) 9099 Operational Security Considerations for IPv6 Networks. É. Vyncke, K. Chittimaneni, M. Kaeo, E. Rey. August 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9099) 9100 Sensor Measurement Lists (SenML) Features and Versions. C. Bormann. August 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC8428) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9100) 9101 The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR). N. Sakimura, J. Bradley, M. Jones. August 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9101) 9102 TLS DNSSEC Chain Extension. V. Dukhovni, S. Huque, W. Toorop, P. Wouters, M. Shore. August 2021. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9102) 9103 DNS Zone Transfer over TLS. W. Toorop, S. Dickinson, S. Sahib, P. Aras, A. Mankin. August 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC1995, RFC5936, RFC7766) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9103) 9104 Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS). J. Tantsura, Z. Wang, Q. Wu, K. Talaulikar. August 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9104) 9105 A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+). B. Wu, Ed., G. Zheng, M. Wang, Ed.. August 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9105) 9106 Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications. A. Biryukov, D. Dinu, D. Khovratovich, S. Josefsson. September 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9106) 9107 BGP Optimal Route Reflection (BGP ORR). R. Raszuk, Ed., B. Decraene, Ed., C. Cassar, E. Åman, K. Wang. August 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9107) 9108 YANG Types for DNS Classes and Resource Record Types. L. Lhotka, P. Špaček. September 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9108) 9109 Network Time Protocol Version 4: Port Randomization. F. Gont, G. Gont, M. Lichvar. August 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC5905) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9109) 9110 HTTP Semantics. R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.. June 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC2818, RFC7230, RFC7231, RFC7232, RFC7233, RFC7235, RFC7538, RFC7615, RFC7694) (Updates RFC3864) (Also STD0097) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC9110) 9111 HTTP Caching. R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.. June 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7234) (Also STD0098) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC9111) 9112 HTTP/1.1. R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.. June 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7230) (Also STD0099) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC9112) 9113 HTTP/2. M. Thomson, Ed., C. Benfield, Ed.. June 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7540, RFC8740) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9113) 9114 HTTP/3. M. Bishop, Ed.. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9114) 9115 An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates. Y. Sheffer, D. López, A. Pastor Perales, T. Fossati. September 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9115) 9116 A File Format to Aid in Security Vulnerability Disclosure. E. Foudil, Y. Shafranovich. April 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9116) 9117 Revised Validation Procedure for BGP Flow Specifications. J. Uttaro, J. Alcaide, C. Filsfils, D. Smith, P. Mohapatra. August 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC8955) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9117) 9118 Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates. R. Housley. August 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC8226) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9118) 9119 Multicast Considerations over IEEE 802 Wireless Media. C. Perkins, M. McBride, D. Stanley, W. Kumari, JC. Zúñiga. October 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9119) 9120 Nameservers for the Address and Routing Parameter Area ("arpa") Domain. K. Davies, J. Arkko. October 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC3172) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9120) 9124 A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices. B. Moran, H. Tschofenig, H. Birkholz. January 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9124) 9125 Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing. A. Farrel, J. Drake, E. Rosen, K. Patel, L. Jalil. August 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9125) 9126 OAuth 2.0 Pushed Authorization Requests. T. Lodderstedt, B. Campbell, N. Sakimura, D. Tonge, F. Skokan. September 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9126) 9127 YANG Data Model for Bidirectional Forwarding Detection (BFD). R. Rahman, Ed., L. Zheng, Ed., M. Jethanandani, Ed., S. Pallagatti, G. Mirsky. October 2021. (Format: HTML, TXT, PDF, XML) (Updated by RFC9314) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9127) 9128 YANG Data Model for Protocol Independent Multicast (PIM). X. Liu, P. McAllister, A. Peter, M. Sivakumar, Y. Liu, F. Hu. October 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9128) 9129 YANG Data Model for the OSPF Protocol. D. Yeung, Y. Qu, Z. Zhang, I. Chen, A. Lindem. October 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9129) 9130 YANG Data Model for the IS-IS Protocol. S. Litkowski, Ed., D. Yeung, A. Lindem, J. Zhang, L. Lhotka. October 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9130) 9131 Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers. J. Linkova. October 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9131) 9132 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification. M. Boucadair, Ed., J. Shallow, T. Reddy.K. September 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC8782) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9132) 9133 Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel. K. Nishizuka, M. Boucadair, T. Reddy.K, T. Nagata. September 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9133) 9134 RTP Payload Format for ISO/IEC 21122 (JPEG XS). T. Bruylants, A. Descampe, C. Damman, T. Richter. October 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9134) 9135 Integrated Routing and Bridging in Ethernet VPN (EVPN). A. Sajassi, S. Salam, S. Thoria, J. Drake, J. Rabadan. October 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9135) 9136 IP Prefix Advertisement in Ethernet VPN (EVPN). J. Rabadan, Ed., W. Henderickx, J. Drake, W. Lin, A. Sajassi. October 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9136) 9137 Considerations for Cancellation of IETF Meetings. M. Duke. October 2021. (Format: HTML, TXT, PDF, XML) (Also BCP0226) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC9137) 9138 Design Considerations for Name Resolution Service in Information-Centric Networking (ICN). J. Hong, T. You, L. Dong, C. Westphal, B. Ohlman. December 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9138) 9139 Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs). C. Gündoğan, T. Schmidt, M. Wählisch, C. Scherb, C. Marxer, C. Tschudin. November 2021. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9139) 9140 Nimble Out-of-Band Authentication for EAP (EAP-NOOB). T. Aura, M. Sethi, A. Peltonen. December 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9140) 9141 Updating References to the IETF FTP Service. R. Danyliw. November 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC2077, RFC2418, RFC2648, RFC2954, RFC2955, RFC3020, RFC3083, RFC3201, RFC3202, RFC3295, RFC3684, RFC3962, RFC3970, RFC4036, RFC4131, RFC4251, RFC4323, RFC4546, RFC4547, RFC4639, RFC4682, RFC5098, RFC5428, RFC6756, RFC7241) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9141) 9142 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH). M. Baushke. January 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC4250, RFC4253, RFC4432, RFC4462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9142) 9143 Negotiating Media Multiplexing Using the Session Description Protocol (SDP). C. Holmberg, H. Alvestrand, C. Jennings. February 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC8843) (Updates RFC3264, RFC5888, RFC7941) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9143) 9144 Comparison of Network Management Datastore Architecture (NMDA) Datastores. A. Clemm, Y. Qu, J. Tantsura, A. Bierman. December 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9144) 9145 Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers. M. Boucadair, T. Reddy.K, D. Wing. December 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9145) 9146 Connection Identifier for DTLS 1.2. E. Rescorla, Ed., H. Tschofenig, Ed., T. Fossati, A. Kraus. March 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC6347) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9146) 9147 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3. E. Rescorla, H. Tschofenig, N. Modadugu. April 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6347) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9147) 9148 EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol. P. van der Stok, P. Kampanakis, M. Richardson, S. Raza. April 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9148) 9149 TLS Ticket Requests. T. Pauly, D. Schinazi, C.A. Wood. April 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9149) 9150 TLS 1.3 Authentication and Integrity-Only Cipher Suites. N. Cam-Winget, J. Visoky. April 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9150) 9151 Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3. D. Cooley. April 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9151) 9152 Secure Object Delivery Protocol (SODP) Server Interfaces: NSA's Profile for Delivery of Certificates, Certificate Revocation Lists (CRLs), and Symmetric Keys to Clients. M. Jenkins, S. Turner. April 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9152) 9153 Drone Remote Identification Protocol (DRIP) Requirements and Terminology. S. Card, Ed., A. Wiethuechter, R. Moskowitz, A. Gurtov. February 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9153) 9154 Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer. J. Gould, R. Wilhelm. December 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9154) 9155 Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2. L. Velvindron, K. Moriarty, A. Ghedini. December 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9155) 9156 DNS Query Name Minimisation to Improve Privacy. S. Bortzmeyer, R. Dolmans, P. Hoffman. November 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7816) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9156) 9157 Revised IANA Considerations for DNSSEC. P. Hoffman. December 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC5155, RFC6014, RFC8624) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9157) 9158 Update to the Object Identifier Registry for the PKIX Working Group. R. Housley. November 2021. (Format: HTML, TXT, PDF, XML) (Updates RFC7299) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9158) 9159 IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP). C. Gomez, S.M. Darroudi, T. Savolainen, M. Spoerk. December 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9159) 9160 Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX). T. Graf. December 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9160) 9161 Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks. J. Rabadan, Ed., S. Sathappan, K. Nagaraj, G. Hankins, T. King. January 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC7432) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9161) 9162 Certificate Transparency Version 2.0. B. Laurie, E. Messeri, R. Stradling. December 2021. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6962) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9162) 9163 Expect-CT Extension for HTTP. E. Stark. June 2022. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9163) 9164 Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes. M. Richardson, C. Bormann. December 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9164) 9165 Additional Control Operators for the Concise Data Definition Language (CDDL). C. Bormann. December 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9165) 9166 A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping. H. Zhao, X. Liu, Y. Liu, A. Peter, M. Sivakumar. February 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9166) 9167 Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP). T. Sattler, R. Carney, J. Kolker. December 2021. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9167) 9168 Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification. D. Dhody, A. Farrel, Z. Li. January 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9168) 9169 New ASN.1 Modules for the Evidence Record Syntax (ERS). R. Housley, C. Wallace. December 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9169) 9170 Long-Term Viability of Protocol Extension Mechanisms. M. Thomson, T. Pauly. December 2021. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9170) 9171 Bundle Protocol Version 7. S. Burleigh, K. Fall, E. Birrane, III. January 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9171) 9172 Bundle Protocol Security (BPSec). E. Birrane, III, K. McKeever. January 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9172) 9173 Default Security Contexts for Bundle Protocol Security (BPSec). E. Birrane, III, A. White, S. Heiner. January 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9173) 9174 Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4. B. Sipos, M. Demmer, J. Ott, S. Perreault. January 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9174) 9175 Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing. C. Amsüss, J. Preuß Mattsson, G. Selander. February 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC7252) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9175) 9176 Constrained RESTful Environments (CoRE) Resource Directory. C. Amsüss, Ed., Z. Shelby, M. Koster, C. Bormann, P. van der Stok. April 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9176) 9177 Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission. M. Boucadair, J. Shallow. March 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9177) 9178 Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks. J. Arkko, A. Eriksson, A. Keränen. May 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9178) 9179 A YANG Grouping for Geographic Locations. C. Hopps. February 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9179) 9180 Hybrid Public Key Encryption. R. Barnes, K. Bhargavan, B. Lipp, C. Wood. February 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9180) 9181 A Common YANG Data Model for Layer 2 and Layer 3 VPNs. S. Barguil, O. Gonzalez de Dios, Ed., M. Boucadair, Ed., Q. Wu. February 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9181) 9182 A YANG Network Data Model for Layer 3 VPNs. S. Barguil, O. Gonzalez de Dios, Ed., M. Boucadair, Ed., L. Munoz, A. Aguado. February 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9182) 9183 Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL). M. Zhang, D. Eastlake 3rd, R. Perlman, M. Cullen, H. Zhai. February 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9183) 9184 BGP Extended Community Registries Update. C. Loibl. January 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC7153, RFC8955) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9184) 9185 DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange. P. Jones, P. Ellenbogen, N. Ohlmeier. April 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9185) 9186 Fast Failover in Protocol Independent Multicast - Sparse Mode (PIM-SM) Using Bidirectional Forwarding Detection (BFD) for Multipoint Networks. G. Mirsky, X. Ji. January 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9186) 9187 Sequence Number Extension for Windowed Protocols. J. Touch. January 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9187) 9188 Generic Multi-Access (GMA) Encapsulation Protocol. J. Zhu, S. Kanugovi. February 2022. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9188) 9189 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2. S. Smyshlyaev, Ed., D. Belyavsky, E. Alekseev. March 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9189) 9190 EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3. J. Preuß Mattsson, M. Sethi. February 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC5216) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9190) 9191 Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods. M. Sethi, J. Preuß Mattsson, S. Turner. February 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9191) 9192 Network Service Header (NSH) Fixed-Length Context Header Allocation. T. Mizrahi, I. Yerushalmi, D. Melman, R. Browne. February 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9192) 9193 Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format. A. Keränen, C. Bormann. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9193) 9194 A YANG Module for IS-IS Reverse Metric. C. Hopps. October 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9194) 9195 A File Format for YANG Instance Data. B. Lengyel, B. Claise. February 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9195) 9196 YANG Modules Describing Capabilities for Systems and Datastore Update Notifications. B. Lengyel, A. Clemm, B. Claise. February 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9196) 9197 Data Fields for In Situ Operations, Administration, and Maintenance (IOAM). F. Brockners, Ed., S. Bhandari, Ed., T. Mizrahi, Ed.. May 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9197) 9198 Advanced Unidirectional Route Assessment (AURA). J. Alvarez-Hamelin, A. Morton, J. Fabini, C. Pignataro, R. Geib. May 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC2330) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9198) 9199 Considerations for Large Authoritative DNS Server Operators. G. Moura, W. Hardaker, J. Heidemann, M. Davids. March 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9199) 9200 Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth). L. Seitz, G. Selander, E. Wahlstroem, S. Erdtman, H. Tschofenig. August 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9200) 9201 Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE). L. Seitz. August 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9201) 9202 Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE). S. Gerdes, O. Bergmann, C. Bormann, G. Selander, L. Seitz. August 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9202) 9203 The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework. F. Palombini, L. Seitz, G. Selander, M. Gunnarsson. August 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9203) 9204 QPACK: Field Compression for HTTP/3. C. Krasic, M. Bishop, A. Frindell, Ed.. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9204) 9205 Building Protocols with HTTP. M. Nottingham. June 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC3205) (Also BCP0056) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC9205) 9206 Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec). L. Corcoran, M. Jenkins. February 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9206) 9207 OAuth 2.0 Authorization Server Issuer Identification. K. Meyer zu Selhausen, D. Fett. March 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9207) 9208 IMAP QUOTA Extension. A. Melnikov. March 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC2087) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9208) 9209 The Proxy-Status HTTP Response Header Field. M. Nottingham, P. Sikora. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9209) 9210 DNS Transport over TCP - Operational Requirements. J. Kristoff, D. Wessels. March 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC1123, RFC1536) (Also BCP0235) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC9210) 9211 The Cache-Status HTTP Response Header Field. M. Nottingham. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9211) 9212 Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH). N. Gajcowski, M. Jenkins. March 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9212) 9213 Targeted HTTP Cache Control. S. Ludin, M. Nottingham, Y. Wu. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9213) 9214 OSPFv3 Code Point for MPLS LSP Ping. N. Nainar, C. Pignataro, M. Aissaoui. April 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC8287) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9214) 9215 Using GOST R 34.10-2012 and GOST R 34.11-2012 Algorithms with the Internet X.509 Public Key Infrastructure. D. Baryshkov, Ed., V. Nikolaev, A. Chelpanov. March 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9215) 9216 S/MIME Example Keys and Certificates. D. K. Gillmor, Ed.. April 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9216) 9217 Current Open Questions in Path-Aware Networking. B. Trammell. March 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9217) 9218 Extensible Prioritization Scheme for HTTP. K. Oku, L. Pardue. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9218) 9219 S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP). A. Melnikov. April 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9219) 9220 Bootstrapping WebSockets with HTTP/3. R. Hamilton. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9220) 9221 An Unreliable Datagram Extension to QUIC. T. Pauly, E. Kinnear, D. Schinazi. March 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9221) 9222 Guidelines for Autonomic Service Agents. B. E. Carpenter, L. Ciavaglia, S. Jiang, P. Peloso. March 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9222) 9223 Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE). W. Zia, T. Stockhammer, L. Chaponniere, G. Mandyam, M. Luby. April 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9223) 9224 Finding the Authoritative Registration Data Access Protocol (RDAP) Service. M. Blanchet. March 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7484) (Also STD0095) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC9224) 9225 Software Defects Considered Harmful. J. Snijders, C. Morrow, R. van Mook. 1 April 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9225) 9226 Bioctal: Hexadecimal 2.0. M. Breen. 1 April 2022. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9226) 9227 Using GOST Ciphers in the Encapsulating Security Payload (ESP) and Internet Key Exchange Version 2 (IKEv2) Protocols. V. Smyslov. March 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9227) 9228 Delivered-To Email Header Field. D. Crocker, Ed.. April 2022. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9228) 9229 IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol. J. Chroboczek. May 2022. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9229) 9230 Oblivious DNS over HTTPS. E. Kinnear, P. McManus, T. Pauly, T. Verma, C.A. Wood. June 2022. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9230) 9231 Additional XML Security Uniform Resource Identifiers (URIs). D. Eastlake 3rd. July 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9231) 9232 Network Telemetry Framework. H. Song, F. Qin, P. Martinez-Julia, L. Ciavaglia, A. Wang. May 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9232) 9233 Internationalized Domain Names for Applications 2008 (IDNA2008) and Unicode 12.0.0. P. Fältström. March 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9233) 9234 Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages. A. Azimov, E. Bogomazov, R. Bush, K. Patel, K. Sriram. May 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9234) 9235 TCP Authentication Option (TCP-AO) Test Vectors. J. Touch, J. Kuusisaari. May 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9235) 9236 Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service. J. Hong, T. You, V. Kafle. April 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9236) 9237 An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE). C. Bormann. August 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9237) 9238 Loading Manufacturer Usage Description (MUD) URLs from QR Codes. M. Richardson, J. Latour, H. Habibi Gharakheili. May 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9238) 9239 Updates to ECMAScript Media Types. M. Miller, M. Borins, M. Bynens, B. Farias. May 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC4329) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9239) 9240 An Extension for Application-Layer Traffic Optimization (ALTO): Entity Property Maps. W. Roome, S. Randriamasy, Y. Yang, J. Zhang, K. Gao. July 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9240) 9241 Content Delivery Network Interconnection (CDNI) Footprint and Capabilities Advertisement Using Application-Layer Traffic Optimization (ALTO). J. Seedorf, Y. Yang, K. Ma, J. Peterson, J. Zhang. July 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9241) 9242 Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2). V. Smyslov. May 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9242) 9243 A YANG Data Model for DHCPv6 Configuration. I. Farrer, Ed.. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9243) 9244 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry. M. Boucadair, Ed., T. Reddy.K, Ed., E. Doron, M. Chen, J. Shallow. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9244) 9245 IETF Discussion List Charter. L. Eggert, S. Harris. June 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC3005) (Updates RFC3683) (Also BCP0045) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC9245) 9246 URI Signing for Content Delivery Network Interconnection (CDNI). R. van Brandenburg, K. Leung, P. Sorber. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9246) 9247 BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD). Z. Li, S. Zhuang, K. Talaulikar, Ed., S. Aldrin, J. Tantsura, G. Mirsky. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9247) 9248 Interoperability Profile for Relay User Equipment. B. Rosen. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9248) 9249 A YANG Data Model for NTP. N. Wu, D. Dhody, Ed., A. Sinha, Ed., A. Kumar S N, Y. Zhao. July 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9249) 9250 DNS over Dedicated QUIC Connections. C. Huitema, S. Dickinson, A. Mankin. May 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9250) 9251 Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN). A. Sajassi, S. Thoria, M. Mishra, K. Patel, J. Drake, W. Lin. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9251) 9252 BGP Overlay Services Based on Segment Routing over IPv6 (SRv6). G. Dawra, Ed., K. Talaulikar, Ed., R. Raszuk, B. Decraene, S. Zhuang, J. Rabadan. July 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9252) 9253 Support for iCalendar Relationships. M. Douglass. August 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC5545) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9253) 9254 Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR). M. Veillette, Ed., I. Petrov, Ed., A. Pelov, C. Bormann, M. Richardson. July 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9254) 9255 The 'I' in RPKI Does Not Stand for Identity. R. Bush, R. Housley. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9255) 9256 Segment Routing Policy Architecture. C. Filsfils, K. Talaulikar, Ed., D. Voyer, A. Bogdanov, P. Mattes. July 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC8402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9256) 9257 Guidance for External Pre-Shared Key (PSK) Usage in TLS. R. Housley, J. Hoyland, M. Sethi, C. A. Wood. July 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9257) 9258 Importing External Pre-Shared Keys (PSKs) for TLS 1.3. D. Benjamin, C. A. Wood. July 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9258) 9259 Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6). Z. Ali, C. Filsfils, S. Matsushima, D. Voyer, M. Chen. June 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9259) 9260 Stream Control Transmission Protocol. R. Stewart, M. Tüxen, K. Nielsen. June 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC4460, RFC4960, RFC6096, RFC7053, RFC8540) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9260) 9261 Exported Authenticators in TLS. N. Sullivan. July 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9261) 9262 Tree Engineering for Bit Index Explicit Replication (BIER-TE). T. Eckert, Ed., M. Menth, G. Cauchie. October 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9262) 9263 Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers. Y. Wei, Ed., U. Elzur, S. Majee, C. Pignataro, D. Eastlake 3rd. August 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9263) 9264 Linkset: Media Types and a Link Relation Type for Link Sets. E. Wilde, H. Van de Sompel. July 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9264) 9265 Forward Erasure Correction (FEC) Coding and Congestion Control in Transport. N. Kuhn, E. Lochin, F. Michel, M. Welzl. July 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9265) 9266 Channel Bindings for TLS 1.3. S. Whited. July 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC5801, RFC5802, RFC5929, RFC7677) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9266) 9267 Common Implementation Anti-Patterns Related to Domain Name System (DNS) Resource Record (RR) Processing. S. Dashevskyi, D. dos Santos, J. Wetzels, A. Amri. July 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9267) 9268 IPv6 Minimum Path MTU Hop-by-Hop Option. R. Hinden, G. Fairhurst. August 2022. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9268) 9269 Experimental Scenarios of Information-Centric Networking (ICN) Integration in 4G Mobile Networks. P. Suthar, M. Stolic, A. Jangam, Ed., D. Trossen, R. Ravindran. August 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9269) 9270 GMPLS Signaling Extensions for Shared Mesh Protection. J. He, I. Busi, J. Ryoo, B. Yoon, P. Park. August 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC4872, RFC4873) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9270) 9271 Uninterruptible Power Supply (UPS) Management Protocol -- Commands and Responses. R. Price, Ed.. August 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9271) 9272 Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER). Z. Zhang, T. Przygienda, A. Dolganow, H. Bidgoli, IJ. Wijnands, A. Gulko. September 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC8401, RFC8444) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9272) 9273 Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges. K. Matsuzono, H. Asaeda, C. Westphal. August 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9273) 9274 A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol. M. Boucadair, Q. Wu. July 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC7285) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9274) 9275 An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector. K. Gao, Y. Lee, S. Randriamasy, Y. Yang, J. Zhang. September 2022. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9275) 9276 Guidance for NSEC3 Parameter Settings. W. Hardaker, V. Dukhovni. August 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC5155) (Also BCP0236) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC9276) 9277 On Stable Storage for Items in Concise Binary Object Representation (CBOR). M. Richardson, C. Bormann. August 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9277) 9278 JWK Thumbprint URI. M. Jones, K. Yasuda. August 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9278) 9279 Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Message Extension. M. Sivakumar, S. Venaas, Z. Zhang, H. Asaeda. August 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9279) 9280 RFC Editor Model (Version 3). P. Saint-Andre, Ed.. June 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC8728) (Updates RFC7841, RFC8729, RFC8730) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9280) 9281 Entities Involved in the IETF Standards Process. R. Salz. June 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC2028) (Also BCP0011) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC9281) 9282 Responsibility Change for the RFC Series. B. Rosen. June 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC9282) 9283 IAB Charter Update for RFC Editor Model. B. Carpenter, Ed.. June 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC2850) (Also BCP0039) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC9283) 9284 Multihoming Deployment Considerations for DDoS Open Threat Signaling (DOTS). M. Boucadair, T. Reddy.K, W. Pan. August 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9284) 9285 The Base45 Data Encoding. P. Fältström, F. Ljunggren, D.W. van Gulik. August 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9285) 9286 Manifests for the Resource Public Key Infrastructure (RPKI). R. Austein, G. Huston, S. Kent, M. Lepinski. June 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6486) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9286) 9287 Greasing the QUIC Bit. M. Thomson. August 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9287) 9288 Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers. F. Gont, W. Liu. August 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9288) 9289 Towards Remote Procedure Call Encryption by Default. T. Myklebust, C. Lever, Ed.. September 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC5531) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9289) 9290 Concise Problem Details for Constrained Application Protocol (CoAP) APIs. T. Fossati, C. Bormann. October 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9290) 9291 A YANG Network Data Model for Layer 2 VPNs. M. Boucadair, Ed., O. Gonzalez de Dios, Ed., S. Barguil, L. Munoz. September 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9291) 9292 Binary Representation of HTTP Messages. M. Thomson, C. A. Wood. August 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9292) 9293 Transmission Control Protocol (TCP). W. Eddy, Ed.. August 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC0793, RFC0879, RFC2873, RFC6093, RFC6429, RFC6528, RFC6691) (Updates RFC1011, RFC1122, RFC5961) (Also STD0007) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC9293) 9294 Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS). K. Talaulikar, Ed., P. Psenak, J. Tantsura. August 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9294) 9295 Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers. S. Turner, S. Josefsson, D. McCarney, T. Ito. September 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC8410) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9295) 9296 ifStackTable for the Point-to-Point (P2P) Interface over a LAN Type: Definition and Examples. D. Liu, J. Halpern, C. Zhang. August 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9296) 9297 HTTP Datagrams and the Capsule Protocol. D. Schinazi, L. Pardue. August 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9297) 9298 Proxying UDP in HTTP. D. Schinazi. August 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9298) 9299 An Architectural Introduction to the Locator/ID Separation Protocol (LISP). A. Cabellos, D. Saucez, Ed.. October 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9299) 9300 The Locator/ID Separation Protocol (LISP). D. Farinacci, V. Fuller, D. Meyer, D. Lewis, A. Cabellos, Ed.. October 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6830) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9300) 9301 Locator/ID Separation Protocol (LISP) Control Plane. D. Farinacci, F. Maino, V. Fuller, A. Cabellos, Ed.. October 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6830, RFC6833) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9301) 9302 Locator/ID Separation Protocol (LISP) Map-Versioning. L. Iannone, D. Saucez, O. Bonaventure. October 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6834) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9302) 9303 Locator/ID Separation Protocol Security (LISP-SEC). F. Maino, V. Ermagan, A. Cabellos, D. Saucez. October 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9303) 9304 Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations. M. Boucadair, C. Jacquenet. October 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC8113) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9304) 9305 Locator/ID Separation Protocol (LISP) Generic Protocol Extension. F. Maino, Ed., J. Lemon, P. Agarwal, D. Lewis, M. Smith. October 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9305) 9306 Vendor-Specific LISP Canonical Address Format (LCAF). A. Rodriguez-Natal, V. Ermagan, A. Smirnov, V. Ashtaputre, D. Farinacci. October 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC8060) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9306) 9307 Report from the IAB Workshop on Analyzing IETF Data (AID) 2021. N. ten Oever, C. Cath, M. Kühlewind, C. S. Perkins. September 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9307) 9308 Applicability of the QUIC Transport Protocol. M. Kühlewind, B. Trammell. September 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9308) 9309 Robots Exclusion Protocol. M. Koster, G. Illyes, H. Zeller, L. Sassman. September 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9309) 9310 X.509 Certificate Extension for 5G Network Function Types. R. Housley, S. Turner, J. Preuß Mattsson, D. Migault. January 2023. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9310) 9311 Running an IETF Hackathon. C. Eckel. September 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9311) 9312 Manageability of the QUIC Transport Protocol. M. Kühlewind, B. Trammell. September 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9312) 9313 Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS). G. Lencse, J. Palet Martinez, L. Howard, R. Patterson, I. Farrer. October 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9313) 9314 YANG Data Model for Bidirectional Forwarding Detection (BFD). M. Jethanandani, Ed., R. Rahman, Ed., L. Zheng, Ed., S. Pallagatti, G. Mirsky. September 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC9127) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9314) 9315 Intent-Based Networking - Concepts and Definitions. A. Clemm, L. Ciavaglia, L. Z. Granville, J. Tantsura. October 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9315) 9316 Intent Classification. C. Li, O. Havel, A. Olariu, P. Martinez-Julia, J. Nobre, D. Lopez. October 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9316) 9317 Operational Considerations for Streaming Media. J. Holland, A. Begen, S. Dawkins. October 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9317) 9318 IAB Workshop Report: Measuring Network Quality for End-Users. W. Hardaker, O. Shapira. October 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9318) 9319 The Use of maxLength in the Resource Public Key Infrastructure (RPKI). Y. Gilad, S. Goldberg, K. Sriram, J. Snijders, B. Maddison. October 2022. (Format: HTML, TXT, PDF, XML) (Also BCP0185) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC9319) 9320 Deterministic Networking (DetNet) Bounded Latency. N. Finn, J.-Y. Le Boudec, E. Mohammadpour, J. Zhang, B. Varga. November 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9320) 9321 Signature Validation Token. S. Santesson, R. Housley. October 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9321) 9322 In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags. T. Mizrahi, F. Brockners, S. Bhandari, B. Gafni, M. Spiegel. November 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9322) 9323 A Profile for RPKI Signed Checklists (RSCs). J. Snijders, T. Harrison, B. Maddison. November 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9323) 9324 Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh. R. Bush, K. Patel, P. Smith, M. Tinka. December 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC8481) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9324) 9325 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). Y. Sheffer, P. Saint-Andre, T. Fossati. November 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7525) (Updates RFC5288, RFC6066) (Also BCP0195) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC9325) 9326 In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting. H. Song, B. Gafni, F. Brockners, S. Bhandari, T. Mizrahi. November 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9326) 9327 Control Messages Protocol for Use with Network Time Protocol Version 4. B. Haberman, Ed.. November 2022. (Format: HTML, TXT, PDF, XML) (Status: HISTORIC) (DOI: 10.17487/RFC9327) 9328 RTP Payload Format for Versatile Video Coding (VVC). S. Zhao, S. Wenger, Y. Sanchez, Y.-K. Wang, M. M Hannuksela. December 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9328) 9329 TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets. T. Pauly, V. Smyslov. November 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC8229) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9329) 9330 Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture. B. Briscoe, Ed., K. De Schepper, M. Bagnulo, G. White. January 2023. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9330) 9331 The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S). K. De Schepper, B. Briscoe, Ed.. January 2023. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9331) 9332 Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S). K. De Schepper, B. Briscoe, Ed., G. White. January 2023. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC9332) 9333 Minimal IP Encapsulating Security Payload (ESP). D. Migault, T. Guggemos. January 2023. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9333) 9334 Remote ATtestation procedureS (RATS) Architecture. H. Birkholz, D. Thaler, M. Richardson, N. Smith, W. Pan. January 2023. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9334) 9336 X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing. T. Ito, T. Okubo, S. Turner. December 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9336) 9337 Generating Password-Based Keys Using the GOST Algorithms. E. Karelina, Ed.. December 2022. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC9337) 9338 CBOR Object Signing and Encryption (COSE): Countersignatures. J. Schaad. December 2022. (Format: HTML, TXT, PDF, XML) (Updates RFC9052) (Also STD0096) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC9338) 9339 OSPF Reverse Metric. K. Talaulikar, Ed., P. Psenak, H. Johnston. December 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9339) 9341 Alternate-Marking Method. G. Fioccola, Ed., M. Cociglio, G. Mirsky, T. Mizrahi, T. Zhou. December 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC8321) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9341) 9342 Clustered Alternate-Marking Method. G. Fioccola, Ed., M. Cociglio, A. Sapio, R. Sisto, T. Zhou. December 2022. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC8889) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9342) 9343 IPv6 Application of the Alternate-Marking Method. G. Fioccola, T. Zhou, M. Cociglio, F. Qin, R. Pang. December 2022. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9343) 9353 IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED). D. Lopez, Q. Wu, D. Dhody, Q. Ma, D. King. January 2023. (Format: HTML, TXT, PDF, XML) (Updates RFC5088, RFC5089, RFC8231, RFC8306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9353) 9354 Transmission of IPv6 Packets over Power Line Communication (PLC) Networks. J. Hou, B. Liu, Y-G. Hong, X. Tang, C. Perkins. January 2023. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC9354) ./rfc-index.xml0000644000764400076440006471113014362467611013273 0ustar iustiniustin BCP0001 BCP0002 BCP0003 RFC1915 BCP0004 RFC1917 BCP0005 RFC1918 BCP0006 RFC1930 RFC6996 RFC7300 BCP0007 RFC2008 BCP0008 RFC2014 BCP0009 RFC2026 RFC5657 RFC6410 RFC7100 RFC7127 RFC7475 RFC8789 RFC9282 BCP0010 RFC8713 RFC8788 BCP0011 RFC9281 BCP0012 BCP0013 RFC4289 RFC6838 BCP0014 RFC2119 RFC8174 BCP0015 RFC2148 BCP0016 RFC2182 BCP0017 RFC2219 BCP0018 RFC2277 BCP0019 RFC2978 BCP0020 RFC2317 BCP0021 RFC2350 BCP0022 RFC2360 BCP0023 RFC2365 BCP0024 RFC2379 BCP0025 RFC2418 RFC3934 RFC7776 RFC8716 BCP0026 RFC8126 BCP0027 RFC2438 BCP0028 RFC2488 BCP0029 RFC2489 BCP0030 RFC2505 BCP0031 RFC2506 BCP0032 RFC2606 BCP0033 RFC2611 BCP0034 RFC2644 BCP0035 RFC7595 BCP0036 RFC2736 BCP0037 RFC2780 RFC5237 BCP0038 RFC2827 BCP0039 RFC2850 RFC9283 BCP0040 RFC7720 BCP0041 RFC2914 RFC7141 BCP0042 RFC6895 BCP0043 RFC2939 BCP0044 RFC2964 BCP0045 RFC9245 BCP0046 RFC3013 BCP0047 RFC4647 RFC5646 BCP0048 RFC3150 BCP0049 RFC3152 BCP0050 RFC3155 BCP0051 RFC5771 BCP0052 RFC3172 BCP0053 RFC3180 BCP0054 RFC7154 BCP0055 RFC3227 BCP0056 RFC9205 BCP0057 RFC3228 BCP0058 RFC3233 BCP0059 RFC3349 BCP0060 RFC3360 BCP0061 RFC3365 BCP0062 RFC3366 BCP0063 RFC3372 BCP0064 RFC4520 BCP0065 RFC3405 RFC8958 BCP0067 RFC5727 RFC7957 BCP0068 RFC3438 BCP0069 RFC3449 BCP0070 RFC3470 BCP0071 RFC3481 BCP0072 RFC3552 BCP0073 RFC3553 BCP0074 RFC3584 BCP0075 RFC3665 BCP0076 RFC3666 BCP0077 RFC3677 BCP0078 RFC5378 BCP0079 RFC8179 BCP0080 RFC3681 BCP0081 RFC3688 BCP0082 RFC3692 BCP0083 RFC3683 BCP0084 RFC3704 RFC8704 BCP0085 RFC3725 BCP0086 RFC3766 BCP0087 RFC3785 BCP0088 RFC3818 BCP0089 RFC3819 BCP0090 RFC3864 BCP0091 RFC3901 BCP0092 RFC5742 BCP0093 RFC3933 BCP0094 BCP0095 RFC3935 BCP0096 RFC3936 BCP0097 RFC3967 RFC4897 RFC8067 BCP0098 RFC3968 BCP0099 RFC3969 BCP0100 RFC7120 BCP0101 RFC8711 RFC8714 RFC8717 BCP0102 RFC4052 BCP0103 RFC4053 BCP0104 RFC4084 BCP0105 RFC4085 BCP0106 RFC4086 BCP0107 RFC4107 BCP0108 RFC4148 BCP0109 RFC4159 BCP0110 RFC4170 BCP0111 RFC4181 RFC4841 BCP0112 RFC4222 BCP0114 RFC4384 BCP0115 BCP0116 RFC4446 BCP0117 RFC4497 BCP0118 RFC4521 BCP0119 RFC4579 BCP0120 RFC4608 BCP0121 RFC4611 BCP0122 RFC4632 BCP0123 RFC4697 BCP0124 RFC4774 BCP0125 RFC4775 BCP0126 RFC4786 BCP0127 RFC4787 RFC6888 RFC7857 BCP0128 RFC4928 BCP0129 RFC4929 BCP0130 RFC4940 BCP0131 RFC4961 BCP0132 RFC4962 BCP0133 RFC5033 BCP0134 RFC5068 BCP0135 RFC5135 BCP0136 RFC5266 BCP0137 RFC5137 BCP0138 RFC5248 BCP0139 RFC5249 BCP0140 RFC5358 BCP0141 RFC7042 BCP0142 RFC5382 BCP0143 RFC5383 BCP0144 RFC5359 BCP0145 RFC8085 BCP0146 RFC5406 BCP0147 RFC5407 BCP0148 RFC5508 BCP0149 RFC5589 BCP0150 RFC5597 BCP0151 RFC5615 BCP0152 RFC5625 BCP0153 RFC6598 RFC6890 RFC8190 BCP0154 RFC5774 BCP0155 RFC5855 BCP0156 RFC6056 BCP0157 RFC6177 BCP0158 RFC6158 BCP0159 RFC6191 BCP0160 RFC6280 BCP0161 RFC6291 BCP0162 RFC6302 BCP0163 RFC6303 RFC7793 BCP0164 RFC6328 BCP0165 RFC6335 RFC7605 BCP0166 RFC6365 BCP0167 RFC6377 BCP0168 RFC6398 BCP0169 RFC6382 BCP0170 RFC6390 BCP0171 RFC6441 BCP0172 RFC6472 BCP0173 RFC6484 RFC7382 BCP0174 RFC6489 BCP0175 RFC6557 BCP0176 RFC6576 BCP0177 RFC6540 BCP0178 RFC6648 BCP0179 RFC6649 BCP0180 RFC6853 BCP0181 RFC6881 BCP0182 RFC6916 BCP0183 RFC6963 BCP0184 RFC7013 BCP0185 RFC7115 RFC9319 BCP0186 RFC7126 BCP0187 RFC7227 BCP0188 RFC7258 BCP0189 RFC7279 BCP0190 RFC8820 BCP0191 RFC7319 BCP0193 RFC7423 BCP0194 RFC7454 BCP0195 RFC8996 RFC9325 BCP0196 RFC7526 BCP0197 RFC7567 BCP0198 RFC7608 BCP0199 RFC7610 BCP0200 RFC1984 BCP0201 RFC7696 BCP0202 RFC7772 BCP0203 RFC7803 BCP0204 RFC7934 BCP0205 RFC7942 BCP0206 RFC7926 BCP0207 RFC8027 BCP0208 RFC8084 BCP0209 RFC8109 BCP0210 RFC8180 BCP0211 RFC8207 BCP0212 RFC8252 BCP0213 RFC8313 BCP0214 RFC8327 BCP0215 RFC8340 BCP0216 RFC8407 BCP0217 RFC8421 BCP0218 RFC8429 BCP0219 RFC8499 BCP0220 RFC8504 BCP0221 RFC8521 BCP0222 RFC8552 RFC8553 BCP0223 RFC8633 BCP0224 RFC8634 BCP0225 RFC8725 BCP0226 RFC8718 RFC8719 RFC9137 BCP0227 RFC8758 BCP0228 RFC8862 BCP0229 RFC8815 BCP0230 RFC8900 BCP0231 RFC8906 BCP0232 RFC8932 BCP0233 RFC8961 BCP0234 RFC9096 BCP0235 RFC9210 BCP0236 RFC9276 FYI0002 RFC1470 FYI0003 RFC1175 FYI0004 RFC2664 FYI0005 RFC1178 FYI0006 RFC1198 FYI0007 RFC1207 FYI0008 RFC2196 FYI0009 RFC1336 FYI0010 RFC1402 FYI0011 RFC2116 FYI0012 RFC1302 FYI0013 RFC1308 FYI0014 RFC1309 FYI0015 RFC1355 FYI0016 RFC1359 FYI0018 RFC1983 FYI0019 RFC1463 FYI0020 RFC1462 FYI0021 RFC1491 FYI0022 RFC1941 FYI0023 RFC1580 FYI0024 RFC1635 FYI0025 RFC1689 FYI0026 RFC1709 FYI0027 RFC1713 FYI0028 RFC1855 FYI0029 RFC2007 FYI0030 RFC2151 FYI0031 RFC2150 FYI0032 RFC2235 FYI0033 RFC2398 FYI0034 RFC2504 FYI0035 RFC2635 FYI0036 RFC4949 FYI0037 RFC2901 FYI0038 RFC3098 RFC0001 Host Software S. Crocker April 1969 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0001 RFC0002 Host software B. Duvall April 1969 ASCII PDF HTML 10 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=2 10.17487/RFC0002 RFC0003 Documentation conventions S.D. Crocker April 1969 ASCII HTML 2 RFC0010 UNKNOWN UNKNOWN Legacy 10.17487/RFC0003 RFC0004 Network timetable E.B. Shapiro March 1969 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0004 RFC0005 Decode Encode Language (DEL) J. Rulifson June 1969 ASCII HTML 17 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=5 10.17487/RFC0005 RFC0006 Conversation with Bob Kahn S.D. Crocker April 1969 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0006 RFC0007 Host-IMP interface G. Deloche May 1969 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0007 RFC0008 ARPA Network Functional Specifications G. Deloche May 1969 PDF HTML 0 UNKNOWN UNKNOWN Legacy 10.17487/RFC0008 RFC0009 Host Software G. Deloche May 1969 PDF HTML 15 UNKNOWN UNKNOWN Legacy 10.17487/RFC0009 RFC0010 Documentation conventions S.D. Crocker July 1969 ASCII HTML 3 RFC0003 RFC0016 RFC0024 RFC0027 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0010 RFC0011 Implementation of the Host - Host Software Procedures in GORDO G. Deloche August 1969 ASCII PDF HTML 23 RFC0033 UNKNOWN UNKNOWN Legacy 10.17487/RFC0011 RFC0012 IMP-Host interface flow diagrams M. Wingfield August 1969 ASCII PS PDF HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0012 RFC0013 Zero Text Length EOF Message V. Cerf August 1969 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0013 RFC0014 RFC0015 Network subsystem for time sharing hosts C.S. Carr September 1969 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0015 RFC0016 M.I.T S. Crocker August 1969 ASCII HTML 1 RFC0010 RFC0024 RFC0024 RFC0027 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0016 RFC0017 Some questions re: Host-IMP Protocol J.E. Kreznar August 1969 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0017 RFC0018 IMP-IMP and HOST-HOST Control Links V. Cerf September 1969 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0018 RFC0019 Two protocol suggestions to reduce congestion at swap bound nodes J.E. Kreznar October 1969 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0019 RFC0020 ASCII format for network interchange V.G. Cerf October 1969 ASCII PDF HTML 9 STD0080 INTERNET STANDARD UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=20 10.17487/RFC0020 RFC0021 Network meeting V.G. Cerf October 1969 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0021 RFC0022 Host-host control message formats V.G. Cerf October 1969 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0022 RFC0023 Transmission of Multiple Control Messages G. Gregg October 1969 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0023 RFC0024 Documentation Conventions S.D. Crocker November 1969 ASCII HTML 3 RFC0016 RFC0010 RFC0016 RFC0027 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0024 RFC0025 No High Link Numbers S.D. Crocker October 1969 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0025 RFC0026 RFC0027 Documentation Conventions S.D. Crocker December 1969 ASCII HTML 3 RFC0010 RFC0016 RFC0024 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0027 RFC0028 Time Standards W.K. English January 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0028 RFC0029 Response to RFC 28 R.E. Kahn January 1970 ASCII HTML 1 RFC0028 UNKNOWN UNKNOWN Legacy 10.17487/RFC0029 RFC0030 Documentation Conventions S.D. Crocker February 1970 ASCII HTML 3 RFC0010 RFC0016 RFC0024 RFC0027 UNKNOWN UNKNOWN Legacy 10.17487/RFC0030 RFC0031 Binary Message Forms in Computer D. Bobrow W.R. Sutherland February 1968 ASCII HTML 7 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=31 10.17487/RFC0031 RFC0032 Some Thoughts on SRI's Proposed Real Time Clock J. Cole February 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0032 RFC0033 New Host-Host Protocol S.D. Crocker February 1970 ASCII HTML 19 RFC0011 RFC0036 RFC0047 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=33 10.17487/RFC0033 RFC0034 Some Brief Preliminary Notes on the Augmentation Research Center Clock W.K. English February 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0034 RFC0035 Network Meeting S.D. Crocker March 1970 ASCII HTML 1 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0035 RFC0036 Protocol Notes S.D. Crocker March 1970 ASCII HTML 8 RFC0033 RFC0039 RFC0044 UNKNOWN UNKNOWN Legacy 10.17487/RFC0036 RFC0037 Network Meeting Epilogue, etc S.D. Crocker March 1970 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0037 RFC0038 Comments on Network Protocol from NWG/RFC #36 S.M. Wolfe March 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0038 RFC0039 Comments on Protocol Re: NWG/RFC #36 E. Harslem J.F. Heafner March 1970 ASCII HTML 3 RFC0036 UNKNOWN UNKNOWN Legacy 10.17487/RFC0039 RFC0040 More Comments on the Forthcoming Protocol E. Harslem J.F. Heafner March 1970 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0040 RFC0041 IMP-IMP Teletype Communication J.T. Melvin March 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0041 RFC0042 Message Data Types E. Ancona March 1970 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0042 RFC0043 Proposed Meeting A.G. Nemeth April 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0043 RFC0044 Comments on NWG/RFC 33 and 36 A. Shoshani R. Long A. Landsberg April 1970 ASCII HTML 3 RFC0036 UNKNOWN UNKNOWN Legacy 10.17487/RFC0044 RFC0045 New Protocol is Coming J. Postel S.D. Crocker April 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0045 RFC0046 ARPA Network protocol notes E. Meyer April 1970 ASCII HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0046 RFC0047 BBN's Comments on NWG/RFC #33 J. Postel S. Crocker April 1970 ASCII HTML 4 RFC0033 UNKNOWN UNKNOWN Legacy 10.17487/RFC0047 RFC0048 Possible protocol plateau J. Postel S.D. Crocker April 1970 ASCII HTML 18 UNKNOWN UNKNOWN Legacy 10.17487/RFC0048 RFC0049 Conversations with S. Crocker (UCLA) E. Meyer April 1970 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0049 RFC0050 Comments on the Meyer Proposal E. Harslen J. Heafner April 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0050 RFC0051 Proposal for a Network Interchange Language M. Elie May 1970 PDF HTML 0 UNKNOWN UNKNOWN Legacy 10.17487/RFC0051 RFC0052 Updated distribution list J. Postel S.D. Crocker July 1970 ASCII HTML 3 RFC0069 UNKNOWN UNKNOWN Legacy 10.17487/RFC0052 RFC0053 Official protocol mechanism S.D. Crocker June 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0053 RFC0054 Official Protocol Proffering S.D. Crocker J. Postel J. Newkirk M. Kraley June 1970 ASCII HTML 9 RFC0057 UNKNOWN UNKNOWN Legacy 10.17487/RFC0054 RFC0055 Prototypical implementation of the NCP J. Newkirk M. Kraley J. Postel S.D. Crocker June 1970 ASCII HTML 23 UNKNOWN UNKNOWN Legacy 10.17487/RFC0055 RFC0056 Third Level Protocol: Logger Protocol E. Belove D. Black R. Flegal L.G. Farquar June 1970 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0056 RFC0057 Thoughts and Reflections on NWG/RFC 54 M. Kraley J. Newkirk June 1970 ASCII HTML 5 RFC0054 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=57 10.17487/RFC0057 RFC0058 Logical Message Synchronization T.P. Skinner June 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0058 RFC0059 Flow Control - Fixed Versus Demand Allocation E. Meyer June 1970 ASCII HTML 7 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=59 10.17487/RFC0059 RFC0060 A Simplified NCP Protocol R. Kalin July 1970 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0060 RFC0061 Note on Interprocess Communication in a Resource Sharing Computer Network D.C. Walden July 1970 ASCII HTML 18 RFC0062 UNKNOWN UNKNOWN Legacy 10.17487/RFC0061 RFC0062 Systems for Interprocess Communication in a Resource Sharing Computer Network D.C. Walden August 1970 ASCII HTML 20 RFC0061 UNKNOWN UNKNOWN Legacy 10.17487/RFC0062 RFC0063 Belated Network Meeting Report V.G. Cerf July 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0063 RFC0064 Getting rid of marking M. Elie July 1970 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0064 RFC0065 Comments on Host/Host Protocol document #1 D.C. Walden August 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0065 RFC0066 NIC - third level ideas and other noise S.D. Crocker August 1970 ASCII HTML 3 RFC0123 RFC0080 RFC0093 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=66 10.17487/RFC0066 RFC0067 Proposed Change to Host/IMP Spec to Eliminate Marking W.R. Crowther January 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0067 RFC0068 Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM M. Elie August 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0068 RFC0069 Distribution List Change for MIT A.K. Bhushan September 1970 ASCII HTML 1 RFC0052 UNKNOWN UNKNOWN Legacy 10.17487/RFC0069 RFC0070 Note on Padding S.D. Crocker October 1970 ASCII HTML 9 RFC0228 UNKNOWN UNKNOWN Legacy 10.17487/RFC0070 RFC0071 Reallocation in Case of Input Error T. Schipper September 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0071 RFC0072 Proposed Moratorium on Changes to Network Protocol R.D. Bressler September 1970 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0072 RFC0073 Response to NWG/RFC 67 S.D. Crocker September 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0073 RFC0074 Specifications for Network Use of the UCSB On-Line System J.E. White October 1970 ASCII PDF HTML 9 RFC0217 RFC0225 UNKNOWN UNKNOWN Legacy 10.17487/RFC0074 RFC0075 Network Meeting S.D. Crocker October 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0075 RFC0076 Connection by name: User oriented protocol J. Bouknight J. Madden G.R. Grossman October 1970 ASCII HTML 15 UNKNOWN UNKNOWN Legacy 10.17487/RFC0076 RFC0077 Network meeting report J. Postel November 1970 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0077 RFC0078 NCP Status Report: UCSB/Rand E. Harslem J.F. Heafner J.E. White October 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0078 RFC0079 Logger Protocol error E. Meyer November 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0079 RFC0080 Protocols and Data Formats E. Harslem J.F. Heafner December 1970 ASCII HTML 9 RFC0123 RFC0066 RFC0093 UNKNOWN UNKNOWN Legacy 10.17487/RFC0080 RFC0081 Request for Reference Information J. Bouknight December 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0081 RFC0082 Network Meeting Notes E. Meyer December 1970 ASCII HTML 18 UNKNOWN UNKNOWN Legacy 10.17487/RFC0082 RFC0083 Language-machine for data reconfiguration R.H. Anderson E. Harslem J.F. Heafner December 1970 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0083 RFC0084 List of NWG/RFC's 1-80 J.B. North December 1970 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0084 RFC0085 Network Working Group meeting S.D. Crocker December 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0085 RFC0086 Proposal for a Network Standard Format for a Data Stream to Control Graphics Display S.D. Crocker January 1971 ASCII HTML 6 RFC0125 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=86 10.17487/RFC0086 RFC0087 Topic for Discussion at the Next Network Working Group Meeting A. Vezza January 1971 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0087 RFC0088 NETRJS: A third level protocol for Remote Job Entry R.T. Braden S.M. Wolfe January 1971 ASCII HTML 9 RFC0189 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=88 10.17487/RFC0088 RFC0089 Some historic moments in networking R.M. Metcalfe January 1971 ASCII HTML 7 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=89 10.17487/RFC0089 RFC0090 CCN as a Network Service Center R.T. Braden January 1971 ASCII HTML 6 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=90 10.17487/RFC0090 RFC0091 Proposed User-User Protocol G.H. Mealy December 1970 ASCII HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0091 RFC0092 RFC0093 Initial Connection Protocol A.M. McKenzie January 1971 ASCII HTML 1 RFC0066 RFC0080 UNKNOWN UNKNOWN Legacy 10.17487/RFC0093 RFC0094 Some thoughts on Network Graphics E. Harslem J.F. Heafner February 1971 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0094 RFC0095 Distribution of NWG/RFC's through the NIC S. Crocker February 1971 ASCII HTML 5 RFC0155 UNKNOWN UNKNOWN Legacy 10.17487/RFC0095 RFC0096 An Interactive Network Experiment to Study Modes of Access the Network Information Center R.W. Watson February 1971 ASCII HTML 5 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0096 RFC0097 First Cut at a Proposed Telnet Protocol J.T. Melvin R.W. Watson February 1971 ASCII PDF HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0097 RFC0098 Logger Protocol Proposal E. Meyer T. Skinner February 1971 ASCII HTML 10 RFC0123 UNKNOWN UNKNOWN Legacy 10.17487/RFC0098 RFC0099 Network Meeting P.M. Karp February 1971 ASCII HTML 1 RFC0116 UNKNOWN UNKNOWN Legacy 10.17487/RFC0099 RFC0100 Categorization and guide to NWG/RFCs P.M. Karp February 1971 ASCII HTML 37 UNKNOWN UNKNOWN Legacy 10.17487/RFC0100 RFC0101 Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971 R.W. Watson February 1971 ASCII HTML 14 RFC0108 RFC0123 UNKNOWN UNKNOWN Legacy 10.17487/RFC0101 RFC0102 Output of the Host-Host Protocol glitch cleaning committee S.D. Crocker February 1971 ASCII HTML 4 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0102 RFC0103 Implementation of Interrupt Keys R.B. Kalin February 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0103 RFC0104 Link 191 J.B. Postel S.D. Crocker February 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0104 RFC0105 Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB J.E. White March 1971 ASCII HTML 9 RFC0217 UNKNOWN UNKNOWN Legacy 10.17487/RFC0105 RFC0106 User/Server Site Protocol Network Host Questionnaire T.C. O'Sullivan March 1971 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0106 RFC0107 Output of the Host-Host Protocol Glitch Cleaning Committee R.D. Bressler S.D. Crocker W.R. Crowther G.R. Grossman R.S. Tomlinson J.E. White March 1971 ASCII HTML 12 RFC0102 RFC0111 RFC0124 RFC0132 RFC0154 RFC0179 UNKNOWN UNKNOWN Legacy 10.17487/RFC0107 RFC0108 Attendance list at the Urbana NWG meeting, February 17-19, 1971 R.W. Watson March 1971 ASCII HTML 2 RFC0101 UNKNOWN UNKNOWN Legacy 10.17487/RFC0108 RFC0109 Level III Server Protocol for the Lincoln Laboratory 360/67 Host J. Winett March 1971 ASCII PDF HTML 12 RFC0393 UNKNOWN UNKNOWN Legacy 10.17487/RFC0109 RFC0110 Conventions for Using an IBM 2741 Terminal as a User Console for Access to Network Server Hosts J. Winett March 1971 ASCII PDF HTML 4 RFC0135 UNKNOWN UNKNOWN Legacy 10.17487/RFC0110 RFC0111 Pressure from the Chairman S.D. Crocker March 1971 ASCII HTML 2 RFC0107 RFC0130 UNKNOWN UNKNOWN Legacy 10.17487/RFC0111 RFC0112 User/Server Site Protocol: Network Host Questionnaire T.C. O'Sullivan April 1971 ASCII PDF HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0112 RFC0113 Network activity report: UCSB Rand E. Harslem J.F. Heafner J.E. White April 1971 ASCII HTML 2 RFC0227 UNKNOWN UNKNOWN Legacy 10.17487/RFC0113 RFC0114 File Transfer Protocol A.K. Bhushan April 1971 ASCII HTML 17 FTP RFC0133 RFC0141 RFC0171 RFC0172 UNKNOWN UNKNOWN Legacy 10.17487/RFC0114 RFC0115 Some Network Information Center policies on handling documents R.W. Watson J.B. North April 1971 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0115 RFC0116 Structure of the May NWG Meeting S.D. Crocker April 1971 ASCII HTML 1 RFC0099 RFC0131 RFC0156 UNKNOWN UNKNOWN Legacy 10.17487/RFC0116 RFC0117 Some comments on the official protocol J. Wong April 1971 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0117 RFC0118 Recommendations for facility documentation R.W. Watson April 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0118 RFC0119 Network Fortran Subprograms M. Krilanovich April 1971 ASCII PDF HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0119 RFC0120 Network PL1 subprograms M. Krilanovich April 1971 ASCII HTML 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0120 RFC0121 Network on-line operators M. Krilanovich April 1971 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0121 RFC0122 Network specifications for UCSB's Simple-Minded File System J.E. White April 1971 ASCII HTML 21 RFC0217 RFC0269 RFC0399 RFC0431 UNKNOWN UNKNOWN Legacy 10.17487/RFC0122 RFC0123 Proffered Official ICP S.D. Crocker April 1971 ASCII HTML 3 RFC0066 RFC0080 RFC0165 RFC0098 RFC0101 RFC0127 RFC0143 RFC0148 UNKNOWN UNKNOWN Legacy 10.17487/RFC0123 RFC0124 Typographical error in RFC 107 J.T. Melvin April 1971 ASCII HTML 1 RFC0107 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=124 10.17487/RFC0124 RFC0125 Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream J. McConnell April 1971 ASCII HTML 4 RFC0086 RFC0177 UNKNOWN UNKNOWN Legacy 10.17487/RFC0125 RFC0126 Graphics Facilities at Ames Research Center J. McConnell April 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0126 RFC0127 Comments on RFC 123 J. Postel April 1971 ASCII HTML 2 RFC0145 RFC0123 RFC0151 UNKNOWN UNKNOWN Legacy 10.17487/RFC0127 RFC0128 Bytes J. Postel April 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0128 RFC0129 Request for comments on socket name structure E. Harslem J. Heafner E. Meyer April 1971 ASCII HTML 6 RFC0147 UNKNOWN UNKNOWN Legacy 10.17487/RFC0129 RFC0130 Response to RFC 111: Pressure from the chairman J.F. Heafner April 1971 ASCII HTML 1 RFC0111 UNKNOWN UNKNOWN Legacy 10.17487/RFC0130 RFC0131 Response to RFC 116: May NWG meeting E. Harslem J.F. Heafner April 1971 ASCII HTML 3 RFC0116 UNKNOWN UNKNOWN Legacy 10.17487/RFC0131 RFC0132 Typographical Error in RFC 107 J.E. White April 1971 ASCII HTML 1 RFC0154 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0132 RFC0133 File Transfer and Error Recovery R.L. Sunberg April 1971 ASCII HTML 4 FTP RFC0114 UNKNOWN UNKNOWN Legacy 10.17487/RFC0133 RFC0134 Network Graphics meeting A. Vezza April 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0134 RFC0135 Response to NWG/RFC 110 W. Hathaway April 1971 ASCII HTML 3 RFC0110 UNKNOWN UNKNOWN Legacy 10.17487/RFC0135 RFC0136 Host accounting and administrative procedures R.E. Kahn April 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0136 RFC0137 Telnet Protocol - a proposed document T.C. O'Sullivan April 1971 ASCII HTML 11 RFC0139 UNKNOWN UNKNOWN Legacy 10.17487/RFC0137 RFC0138 Status report on proposed Data Reconfiguration Service R.H. Anderson V.G. Cerf E. Harslem J.F. Heafner J. Madden R.M. Metcalfe A. Shoshani J.E. White D.C.M. Wood April 1971 ASCII HTML 23 UNKNOWN UNKNOWN Legacy 10.17487/RFC0138 RFC0139 Discussion of Telnet Protocol T.C. O'Sullivan May 1971 ASCII HTML 11 RFC0137 RFC0158 RFC0393 UNKNOWN UNKNOWN Legacy 10.17487/RFC0139 RFC0140 Agenda for the May NWG meeting S.D. Crocker May 1971 ASCII HTML 4 RFC0149 UNKNOWN UNKNOWN Legacy 10.17487/RFC0140 RFC0141 Comments on RFC 114: A File Transfer Protocol E. Harslem J.F. Heafner April 1971 ASCII HTML 2 FTP RFC0114 UNKNOWN UNKNOWN Legacy 10.17487/RFC0141 RFC0142 Time-Out Mechanism in the Host-Host Protocol C. Kline J. Wong May 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0142 RFC0143 Regarding proffered official ICP W. Naylor J. Wong C. Kline J. Postel May 1971 ASCII HTML 4 RFC0165 RFC0123 RFC0145 UNKNOWN UNKNOWN Legacy 10.17487/RFC0143 RFC0144 Data sharing on computer networks A. Shoshani April 1971 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0144 RFC0145 Initial Connection Protocol Control Commands J. Postel May 1971 ASCII PS PDF HTML 2 RFC0127 RFC0165 RFC0143 UNKNOWN UNKNOWN Legacy 10.17487/RFC0145 RFC0146 Views on issues relevant to data sharing on computer networks P.M. Karp D.B. McKay D.C.M. Wood May 1971 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0146 RFC0147 Definition of a socket J.M. Winett May 1971 ASCII HTML 3 RFC0129 UNKNOWN UNKNOWN Legacy 10.17487/RFC0147 RFC0148 Comments on RFC 123 A.K. Bhushan May 1971 ASCII HTML 1 RFC0123 UNKNOWN UNKNOWN Legacy 10.17487/RFC0148 RFC0149 Best Laid Plans S.D. Crocker May 1971 ASCII HTML 1 RFC0140 UNKNOWN UNKNOWN Legacy 10.17487/RFC0149 RFC0150 Use of IPC Facilities: A Working Paper R.B. Kalin May 1971 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0150 RFC0151 Comments on a proffered official ICP: RFCs 123, 127 A. Shoshani May 1971 ASCII HTML 2 RFC0127 UNKNOWN UNKNOWN Legacy 10.17487/RFC0151 RFC0152 SRI Artificial Intelligence status report M. Wilber May 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0152 RFC0153 SRI ARC-NIC status J.T. Melvin R.W. Watson May 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0153 RFC0154 Exposition Style S.D. Crocker May 1971 ASCII HTML 1 RFC0132 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0154 RFC0155 ARPA Network mailing lists J.B. North May 1971 ASCII HTML 13 RFC0095 RFC0168 UNKNOWN UNKNOWN Legacy 10.17487/RFC0155 RFC0156 Status of the Illinois site: Response to RFC 116 J. Bouknight April 1971 ASCII HTML 1 RFC0116 UNKNOWN UNKNOWN Legacy 10.17487/RFC0156 RFC0157 Invitation to the Second Symposium on Problems in the Optimization of Data Communications Systems V.G. Cerf May 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0157 RFC0158 Telnet Protocol: A Proposed Document T.C. O'Sullivan May 1971 ASCII PDF HTML 11 RFC0495 RFC0139 RFC0318 RFC0393 UNKNOWN UNKNOWN Legacy 10.17487/RFC0158 RFC0159 RFC0160 RFC brief list Network Information Center. Stanford Research Institute May 1971 ASCII HTML 4 RFC0200 RFC0999 NIC6716 UNKNOWN UNKNOWN Legacy 10.17487/RFC0160 RFC0161 Solution to the race condition in the ICP A. Shoshani May 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0161 RFC0162 NETBUGGER3 M. Kampe May 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=162 10.17487/RFC0162 RFC0163 Data transfer protocols V.G. Cerf May 1971 ASCII HTML 3 FTP DTP data manager UNKNOWN UNKNOWN Legacy 10.17487/RFC0163 RFC0164 Minutes of Network Working Group meeting, 5/16 through 5/19/71 J.F. Heafner May 1971 ASCII HTML 32 UNKNOWN UNKNOWN Legacy 10.17487/RFC0164 RFC0165 Proffered Official Initial Connection Protocol J. Postel May 1971 ASCII PDF HTML 5 RFC0145 RFC0143 RFC0123 NIC7101 UNKNOWN UNKNOWN Legacy 10.17487/RFC0165 RFC0166 Data Reconfiguration Service: An implementation specification R.H. Anderson V.G. Cerf E. Harslem J.F. Heafner J. Madden R.M. Metcalfe A. Shoshani J.E. White D.C.M. Wood May 1971 ASCII HTML 20 UNKNOWN UNKNOWN Legacy 10.17487/RFC0166 RFC0167 Socket conventions reconsidered A.K. Bhushan R.M. Metcalfe J.M. Winett May 1971 ASCII HTML 4 RFC0129 RFC0147 UNKNOWN UNKNOWN Legacy 10.17487/RFC0167 RFC0168 ARPA Network mailing lists J.B. North May 1971 ASCII HTML 7 RFC0155 RFC0211 UNKNOWN UNKNOWN Legacy 10.17487/RFC0168 RFC0169 COMPUTER NETWORKS S.D. Crocker May 1971 ASCII PDF HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0169 RFC0170 RFC List by Number Network Information Center. Stanford Research Institute June 1971 ASCII HTML 6 RFC0200 UNKNOWN UNKNOWN Legacy 10.17487/RFC0170 RFC0171 The Data Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenize J. Melvin B. Sundberg D. Watson J. White June 1971 ASCII HTML 9 FTP DTP RFC0264 RFC0114 RFC0238 UNKNOWN UNKNOWN Legacy 10.17487/RFC0171 RFC0172 The File Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenzie J. Melvin B. Sundberg D. Watson J. White June 1971 ASCII HTML 12 FTP RFC0265 RFC0114 RFC0238 UNKNOWN UNKNOWN Legacy 10.17487/RFC0172 RFC0173 Network Data Management Committee Meeting Announcement P.M. Karp D.B. McKay June 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0173 RFC0174 UCLA - Computer Science Graphics Overview J. Postel V.G. Cerf June 1971 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0174 RFC0175 Comments on "Socket Conventions Reconsidered" E. Harslem J.F. Heafner June 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0175 RFC0176 Comments on "Byte size for connections" A.K. Bhushan R. Kanodia R.M. Metcalfe J. Postel June 1971 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0176 RFC0177 Device independent graphical display description J. McConnell June 1971 ASCII HTML 9 RFC0125 RFC0181 UNKNOWN UNKNOWN Legacy 10.17487/RFC0177 RFC0178 Network graphic attention handling I.W. Cotton June 1971 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0178 RFC0179 Link Number Assignments A.M. McKenzie June 1971 ASCII HTML 1 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0179 RFC0180 File system questionnaire A.M. McKenzie June 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0180 RFC0181 Modifications to RFC 177 J. McConnell July 1971 ASCII HTML 3 RFC0177 UNKNOWN UNKNOWN Legacy 10.17487/RFC0181 RFC0182 Compilation of list of relevant site reports J.B. North June 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0182 RFC0183 EBCDIC Codes and Their Mapping to ASCII J.M. Winett July 1971 ASCII PDF HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0183 RFC0184 Proposed graphic display modes K.C. Kelley July 1971 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0184 RFC0185 NIC distribution of manuals and handbooks J.B. North July 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0185 RFC0186 Network graphics loader J.C. Michener July 1971 ASCII HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0186 RFC0187 Network/440 Protocol Concept D.B. McKay D.P. Karp July 1971 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0187 RFC0188 Data management meeting announcement P.M. Karp D.B. McKay January 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0188 RFC0189 Interim NETRJS specifications R.T. Braden July 1971 ASCII HTML 19 RFC0088 RFC0599 RFC0283 UNKNOWN UNKNOWN Legacy 10.17487/RFC0189 RFC0190 DEC PDP-10-IMLAC communications system L.P. Deutsch July 1971 ASCII HTML 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0190 RFC0191 Graphics implementation and conceptualization at Augmentation Research Center C.H. Irby July 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0191 RFC0192 Some factors which a Network Graphics Protocol must consider R.W. Watson July 1971 ASCII HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0192 RFC0193 NETWORK CHECKOUT E. Harslem J.F. Heafner July 1971 ASCII HTML 2 RFC0198 RFC0198 UNKNOWN UNKNOWN Legacy 10.17487/RFC0193 RFC0194 The Data Reconfiguration Service -- Compiler/Interpreter Implementation Notes V. Cerf E. Harslem J. Heafner B. Metcalfe J. White July 1971 ASCII HTML 18 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=194 10.17487/RFC0194 RFC0195 Data computers-data descriptions and access language G.H. Mealy July 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0195 RFC0196 Mail Box Protocol R.W. Watson July 1971 ASCII HTML 4 RFC0221 UNKNOWN UNKNOWN Legacy 10.17487/RFC0196 RFC0197 Initial Connection Protocol - Reviewed A. Shoshani E. Harslem July 1971 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0197 RFC0198 Site Certification - Lincoln Labs 360/67 J.F. Heafner July 1971 ASCII HTML 1 RFC0193 RFC0214 RFC0193 UNKNOWN UNKNOWN Legacy 10.17487/RFC0198 RFC0199 Suggestions for a Network Data-Tablet Graphics Protocol T. Williams July 1971 ASCII PDF HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0199 RFC0200 RFC list by number J.B. North August 1971 ASCII HTML 7 RFC0170 RFC0160 NIC7724 UNKNOWN UNKNOWN Legacy 10.17487/RFC0200 RFC0201 RFC0202 Possible Deadlock in ICP S.M. Wolfe J. Postel July 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0202 RFC0203 Achieving reliable communication R.B. Kalin August 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0203 RFC0204 Sockets in use J. Postel August 1971 ASCII HTML 1 RFC0234 UNKNOWN UNKNOWN Legacy 10.17487/RFC0204 RFC0205 NETCRT - a character display protocol R.T. Braden August 1971 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0205 RFC0206 A User TELNET Description of an Initial Implementation J. White August 1971 ASCII PDF HTML 14 UNKNOWN UNKNOWN Legacy 10.17487/RFC0206 RFC0207 September Network Working Group meeting A. Vezza August 1971 ASCII HTML 2 RFC0212 UNKNOWN UNKNOWN Legacy 10.17487/RFC0207 RFC0208 Address tables A.M. McKenzie August 1971 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0208 RFC0209 Host/IMP interface documentation B. Cosell August 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0209 RFC0210 Improvement of Flow Control W. Conrad August 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0210 RFC0211 ARPA Network Mailing Lists J.B. North August 1971 ASCII PDF HTML 13 RFC0168 RFC0300 UNKNOWN UNKNOWN Legacy 10.17487/RFC0211 RFC0212 NWG meeting on network usage Information Sciences Institute University of Southern California August 1971 ASCII HTML 2 RFC0207 RFC0222 UNKNOWN UNKNOWN Legacy 10.17487/RFC0212 RFC0213 IMP System change notification B. Cosell August 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0213 RFC0214 Network checkpoint E. Harslem August 1971 ASCII HTML 2 RFC0198 UNKNOWN UNKNOWN Legacy 10.17487/RFC0214 RFC0215 NCP, ICP, and Telnet: The Terminal IMP implementation A.M. McKenzie August 1971 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0215 RFC0216 Telnet Access to UCSB's On-Line System J.E. White September 1971 ASCII PDF HTML 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0216 RFC0217 Specifications changes for OLS, RJE/RJOR, and SMFS J.E. White September 1971 ASCII HTML 2 RFC0074 RFC0105 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0217 RFC0218 Changing the IMP status reporting facility B. Cosell September 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0218 RFC0219 User's View of the Datacomputer R. Winter September 1971 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0219 RFC0220 RFC0221 Mail Box Protocol: Version 2 R.W. Watson August 1971 ASCII HTML 5 RFC0196 RFC0278 UNKNOWN UNKNOWN Legacy 10.17487/RFC0221 RFC0222 Subject: System programmer's workshop R.M. Metcalfe September 1971 ASCII HTML 2 RFC0212 RFC0234 UNKNOWN UNKNOWN Legacy 10.17487/RFC0222 RFC0223 Network Information Center schedule for network users J.T. Melvin R.W. Watson September 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0223 RFC0224 Comments on Mailbox Protocol A.M. McKenzie September 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0224 RFC0225 Rand/UCSB network graphics experiment E. Harslem R. Stoughton September 1971 ASCII HTML 5 RFC0074 UNKNOWN UNKNOWN Legacy 10.17487/RFC0225 RFC0226 Standardization of host mnemonics P.M. Karp September 1971 ASCII HTML 1 RFC0247 UNKNOWN UNKNOWN Legacy 10.17487/RFC0226 RFC0227 Data transfer rates (Rand/UCLA) J.F. Heafner E. Harslem September 1971 ASCII HTML 2 RFC0113 UNKNOWN UNKNOWN Legacy 10.17487/RFC0227 RFC0228 Clarification D.C. Walden September 1971 ASCII HTML 1 RFC0070 UNKNOWN UNKNOWN Legacy 10.17487/RFC0228 RFC0229 Standard host names J. Postel September 1971 ASCII HTML 3 RFC0236 UNKNOWN UNKNOWN Legacy 10.17487/RFC0229 RFC0230 Toward reliable operation of minicomputer-based terminals on a TIP T. Pyke September 1971 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0230 RFC0231 Service center standards for remote usage: A user's view J.F. Heafner E. Harslem September 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0231 RFC0232 Postponement of network graphics meeting A. Vezza September 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0232 RFC0233 Standardization of host call letters A. Bhushan R. Metcalfe September 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0233 RFC0234 Network Working Group meeting schedule A. Vezza October 1971 ASCII HTML 1 RFC0222 RFC0204 UNKNOWN UNKNOWN Legacy 10.17487/RFC0234 RFC0235 Site status E. Westheimer September 1971 ASCII HTML 5 RFC0240 UNKNOWN UNKNOWN Legacy 10.17487/RFC0235 RFC0236 Standard host names J. Postel September 1971 ASCII HTML 2 RFC0229 UNKNOWN UNKNOWN Legacy 10.17487/RFC0236 RFC0237 NIC view of standard host names R.W. Watson October 1971 ASCII HTML 1 RFC0273 UNKNOWN UNKNOWN Legacy 10.17487/RFC0237 RFC0238 Comments on DTP and FTP proposals R.T. Braden September 1971 ASCII HTML 2 FTP RFC0171 RFC0172 UNKNOWN UNKNOWN Legacy 10.17487/RFC0238 RFC0239 Host mnemonics proposed in RFC 226 (NIC 7625) R.T. Braden September 1971 ASCII HTML 1 RFC0226 RFC0229 RFC0236 UNKNOWN UNKNOWN Legacy 10.17487/RFC0239 RFC0240 Site Status A.M. McKenzie September 1971 ASCII HTML 4 RFC0235 RFC0252 UNKNOWN UNKNOWN Legacy 10.17487/RFC0240 RFC0241 Connecting computers to MLC ports A.M. McKenzie September 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0241 RFC0242 Data Descriptive Language for Shared Data L. Haibt A.P. Mullery July 1971 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0242 RFC0243 Network and data sharing bibliography A.P. Mullery October 1971 ASCII HTML 7 RFC0290 UNKNOWN UNKNOWN Legacy 10.17487/RFC0243 RFC0244 RFC0245 Reservations for Network Group meeting C. Falls October 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0245 RFC0246 Network Graphics meeting A. Vezza October 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0246 RFC0247 Proffered set of standard host names P.M. Karp October 1971 ASCII HTML 4 RFC0226 UNKNOWN UNKNOWN Legacy 10.17487/RFC0247 RFC0248 RFC0249 Coordination of equipment and supplies purchase R.F. Borelli October 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0249 RFC0250 Some thoughts on file transfer H. Brodie October 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0250 RFC0251 Weather data D. Stern October 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0251 RFC0252 Network host status E. Westheimer October 1971 ASCII HTML 3 RFC0240 RFC0255 UNKNOWN UNKNOWN Legacy 10.17487/RFC0252 RFC0253 Second Network Graphics meeting details J.A. Moorer October 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0253 RFC0254 Scenarios for using ARPANET computers A. Bhushan October 1971 ASCII PDF HTML 0 UNKNOWN UNKNOWN Legacy 10.17487/RFC0254 RFC0255 Status of network hosts E. Westheimer October 1971 ASCII HTML 2 RFC0252 RFC0266 UNKNOWN UNKNOWN Legacy 10.17487/RFC0255 RFC0256 IMPSYS change notification B. Cosell November 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0256 RFC0257 RFC0258 RFC0259 RFC0260 RFC0261 RFC0262 RFC0263 "Very Distant" Host interface A.M. McKenzie December 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0263 RFC0264 The Data Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenize B. Sundberg D. Watson J. White January 1972 ASCII HTML 9 FTP DTP RFC0171 RFC0354 RFC0310 RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0264 RFC0265 The File Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenzie J. Melvin B. Sundberg D. Watson J. White November 1971 ASCII HTML 12 FTP RFC0172 RFC0354 RFC0281 RFC0294 RFC0310 RFC0264 UNKNOWN UNKNOWN Legacy 10.17487/RFC0265 RFC0266 Network host status E. Westheimer November 1971 ASCII HTML 2 RFC0255 RFC0267 UNKNOWN UNKNOWN Legacy 10.17487/RFC0266 RFC0267 Network Host Status E. Westheimer November 1971 ASCII HTML 4 RFC0266 RFC0287 UNKNOWN UNKNOWN Legacy 10.17487/RFC0267 RFC0268 Graphics facilities information J. Postel November 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0268 RFC0269 Some Experience with File Transfer H. Brodie December 1971 ASCII HTML 3 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0269 RFC0270 Correction to BBN Report No. 1822 (NIC NO 7958) A.M. McKenzie January 1972 ASCII PDF HTML 1 NIC7959 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=270 10.17487/RFC0270 RFC0271 IMP System change notifications B. Cosell January 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0271 RFC0272 RFC0273 More on standard host names R.W. Watson October 1971 ASCII HTML 3 RFC0237 UNKNOWN UNKNOWN Legacy 10.17487/RFC0273 RFC0274 Establishing a local guide for network usage E. Forman November 1971 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0274 RFC0275 RFC0276 NIC course R.W. Watson November 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0276 RFC0277 RFC0278 Revision of the Mail Box Protocol A.K. Bhushan R.T. Braden E. Harslem J.F. Heafner A.M. McKenzie J.T. Melvin R.L. Sundberg R.W. Watson J.E. White November 1971 ASCII HTML 4 RFC0221 UNKNOWN UNKNOWN Legacy 10.17487/RFC0278 RFC0279 RFC0280 A Draft of Host Names R.W. Watson November 1971 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0280 RFC0281 Suggested addition to File Transfer Protocol A.M. McKenzie December 1971 ASCII HTML 8 FTP RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0281 RFC0282 Graphics meeting report M.A. Padlipsky December 1971 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0282 RFC0283 NETRJT: Remote Job Service Protocol for TIPS R.T. Braden December 1971 ASCII HTML 9 RFC0189 UNKNOWN UNKNOWN Legacy 10.17487/RFC0283 RFC0284 RFC0285 Network graphics D. Huff December 1971 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0285 RFC0286 Network Library Information System E. Forman December 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0286 RFC0287 Status of Network Hosts E. Westheimer December 1971 ASCII HTML 5 RFC0267 RFC0288 UNKNOWN UNKNOWN Legacy 10.17487/RFC0287 RFC0288 Network host status E. Westheimer January 1972 ASCII HTML 4 RFC0287 RFC0293 RFC0293 UNKNOWN UNKNOWN Legacy 10.17487/RFC0288 RFC0289 What we hope is an official list of host names R.W. Watson December 1971 ASCII HTML 3 RFC0384 UNKNOWN UNKNOWN Legacy 10.17487/RFC0289 RFC0290 Computer networks and data sharing: A bibliography A.P. Mullery January 1972 ASCII HTML 15 RFC0243 UNKNOWN UNKNOWN Legacy 10.17487/RFC0290 RFC0291 Data Management Meeting Announcement D.B. McKay January 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0291 RFC0292 Graphics Protocol: Level 0 only J.C. Michener I.W. Cotton K.C. Kelley D.E. Liddle E. Meyer January 1972 ASCII HTML 10 RFC0493 UNKNOWN UNKNOWN Legacy 10.17487/RFC0292 RFC0293 Network Host Status E. Westheimer January 1972 ASCII HTML 4 RFC0288 RFC0298 RFC0288 UNKNOWN UNKNOWN Legacy 10.17487/RFC0293 RFC0294 The Use of "Set Data Type" Transaction in File Transfer Protocol A.K. Bhushan January 1972 ASCII HTML 2 FTP RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0294 RFC0295 Report of the Protocol Workshop, 12 October 1971 J. Postel January 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0295 RFC0296 DS-1 Display System D.E. Liddle January 1972 ASCII PDF HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0296 RFC0297 TIP Message Buffers D.C. Walden January 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0297 RFC0298 Network host status E. Westheimer February 1972 ASCII HTML 4 RFC0293 RFC0306 UNKNOWN UNKNOWN Legacy 10.17487/RFC0298 RFC0299 Information Management System D. Hopkin February 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0299 RFC0300 ARPA Network mailing lists J.B. North January 1972 ASCII HTML 9 RFC0211 RFC0303 UNKNOWN UNKNOWN Legacy 10.17487/RFC0300 RFC0301 BBN IMP (#5) and NCC Schedule March 4, 1971 R. Alter February 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0301 RFC0302 Exercising The ARPANET R.F. Bryan February 1972 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0302 RFC0303 ARPA Network mailing lists Network Information Center. Stanford Research Institute March 1972 ASCII HTML 11 RFC0300 RFC0329 UNKNOWN UNKNOWN Legacy 10.17487/RFC0303 RFC0304 Data Management System Proposal for the ARPA Network D.B. McKay February 1972 ASCII PDF HTML 8 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=304 10.17487/RFC0304 RFC0305 Unknown Host Numbers R. Alter February 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0305 RFC0306 Network host status E. Westheimer February 1972 ASCII HTML 4 RFC0298 RFC0315 UNKNOWN UNKNOWN Legacy 10.17487/RFC0306 RFC0307 Using network Remote Job Entry E. Harslem February 1972 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0307 RFC0308 ARPANET host availability data M. Seriff March 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0308 RFC0309 Data and File Transfer Workshop Announcement A.K. Bhushan March 1972 ASCII HTML 6 FTP DTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0309 RFC0310 Another Look at Data and File Transfer Protocols A.K. Bhushan April 1972 ASCII HTML 7 FTP RFC0264 RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0310 RFC0311 New Console Attachments to the USCB Host R.F. Bryan February 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0311 RFC0312 Proposed Change in IMP-to-Host Protocol A.M. McKenzie March 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0312 RFC0313 Computer based instruction T.C. O'Sullivan March 1972 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0313 RFC0314 Network Graphics Working Group Meeting I.W. Cotton March 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0314 RFC0315 Network Host Status E. Westheimer March 1972 ASCII HTML 4 RFC0306 RFC0319 UNKNOWN UNKNOWN Legacy 10.17487/RFC0315 RFC0316 ARPA Network Data Management Working Group D.B. McKay A.P. Mullery February 1972 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0316 RFC0317 Official Host-Host Protocol Modification: Assigned Link Numbers J. Postel March 1972 ASCII HTML 1 RFC0604 UNKNOWN UNKNOWN Legacy 10.17487/RFC0317 RFC0318 Telnet Protocols J. Postel April 1972 ASCII HTML 16 RFC0158 RFC0435 RFC0139 RFC0158 UNKNOWN UNKNOWN Legacy 10.17487/RFC0318 RFC0319 Network Host Status E. Westheimer March 1972 ASCII HTML 4 RFC0315 RFC0326 UNKNOWN UNKNOWN Legacy 10.17487/RFC0319 RFC0320 Workshop on Hard Copy Line Graphics R. Reddy March 1972 ASCII PDF HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0320 RFC0321 CBI Networking Activity at MITRE P.M. Karp March 1972 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0321 RFC0322 Well known socket numbers V. Cerf J. Postel March 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0322 RFC0323 Formation of Network Measurement Group (NMG) V. Cerf March 1972 ASCII HTML 9 RFC0388 UNKNOWN UNKNOWN Legacy 10.17487/RFC0323 RFC0324 RJE Protocol meeting J. Postel April 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0324 RFC0325 Network Remote Job Entry program - NETRJS G. Hicks April 1972 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0325 RFC0326 Network Host Status E. Westheimer April 1972 ASCII HTML 4 RFC0330 RFC0319 UNKNOWN UNKNOWN Legacy 10.17487/RFC0326 RFC0327 Data and File Transfer workshop notes A.K. Bhushan April 1972 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0327 RFC0328 Suggested Telnet Protocol Changes J. Postel April 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0328 RFC0329 ARPA Network Mailing Lists Network Information Center. Stanford Research Institute May 1972 ASCII HTML 13 RFC0303 RFC0363 UNKNOWN UNKNOWN Legacy 10.17487/RFC0329 RFC0330 Network Host Status E. Westheimer April 1972 ASCII HTML 3 RFC0326 RFC0332 UNKNOWN UNKNOWN Legacy 10.17487/RFC0330 RFC0331 IMP System Change Notification J.M. McQuillan April 1972 ASCII HTML 1 RFC0343 UNKNOWN UNKNOWN Legacy 10.17487/RFC0331 RFC0332 Network Host Status E. Westheimer April 1972 ASCII HTML 4 RFC0342 RFC0330 UNKNOWN UNKNOWN Legacy 10.17487/RFC0332 RFC0333 Proposed experiment with a Message Switching Protocol R.D. Bressler D. Murphy D.C. Walden May 1972 ASCII HTML 26 UNKNOWN UNKNOWN Legacy 10.17487/RFC0333 RFC0334 Network Use on May 8 A.M. McKenzie May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0334 RFC0335 New Interface - IMP/360 R.F. Bryan May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0335 RFC0336 Level 0 Graphic Input Protocol I.W. Cotton May 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0336 RFC0337 RFC0338 EBCDIC/ASCII Mapping for Network RJE R.T. Braden May 1972 ASCII PS PDF HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0338 RFC0339 MLTNET: A "Multi Telnet" Subsystem for Tenex R. Thomas May 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0339 RFC0340 Proposed Telnet Changes T.C. O'Sullivan May 1972 ASCII HTML 2 RFC0328 UNKNOWN UNKNOWN Legacy 10.17487/RFC0340 RFC0341 RFC0342 Network Host Status E. Westheimer May 1972 ASCII HTML 4 RFC0332 RFC0344 UNKNOWN UNKNOWN Legacy 10.17487/RFC0342 RFC0343 IMP System change notification A.M. McKenzie May 1972 ASCII HTML 2 RFC0331 RFC0359 UNKNOWN UNKNOWN Legacy 10.17487/RFC0343 RFC0344 Network Host Status E. Westheimer May 1972 ASCII HTML 4 RFC0342 RFC0353 UNKNOWN UNKNOWN Legacy 10.17487/RFC0344 RFC0345 Interest in Mixed Integer Programming (MPSX on NIC 360/91 at CCN) K.C. Kelley May 1972 ASCII HTML 1 MIP UNKNOWN UNKNOWN Legacy 10.17487/RFC0345 RFC0346 Satellite Considerations J. Postel May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0346 RFC0347 Echo process J. Postel May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0347 RFC0348 Discard Process J. Postel May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0348 RFC0349 Proposed Standard Socket Numbers J. Postel May 1972 ASCII HTML 1 RFC0433 RFC0204 RFC0322 UNKNOWN UNKNOWN Legacy 10.17487/RFC0349 RFC0350 User Accounts for UCSB On-Line System R. Stoughton May 1972 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0350 RFC0351 Graphics information form for the ARPANET graphics resources notebook D. Crocker June 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0351 RFC0352 TIP Site Information Form D. Crocker June 1972 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0352 RFC0353 Network host status E. Westheimer June 1972 ASCII HTML 5 RFC0344 RFC0362 UNKNOWN UNKNOWN Legacy 10.17487/RFC0353 RFC0354 File Transfer Protocol A.K. Bhushan July 1972 ASCII HTML 25 FTP RFC0264 RFC0265 RFC0542 RFC0385 RFC0454 RFC0683 UNKNOWN UNKNOWN Legacy 10.17487/RFC0354 RFC0355 Response to NWG/RFC 346 J. Davidson June 1972 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0355 RFC0356 ARPA Network Control Center R. Alter June 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0356 RFC0357 Echoing strategy for satellite links J. Davidson June 1972 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0357 RFC0358 RFC0359 Status of the Release of the New IMP System (2600) D.C. Walden June 1972 ASCII HTML 1 RFC0343 UNKNOWN UNKNOWN Legacy 10.17487/RFC0359 RFC0360 Proposed Remote Job Entry Protocol C. Holland June 1972 ASCII PDF HTML 18 RFC0407 UNKNOWN UNKNOWN Legacy 10.17487/RFC0360 RFC0361 Deamon Processes on Host 106 R.D. Bressler July 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0361 RFC0362 Network Host Status E. Westheimer June 1972 ASCII HTML 4 RFC0353 RFC0366 UNKNOWN UNKNOWN Legacy 10.17487/RFC0362 RFC0363 ARPA Network mailing lists Network Information Center. Stanford Research Institute August 1972 ASCII HTML 13 RFC0329 RFC0402 UNKNOWN UNKNOWN Legacy 10.17487/RFC0363 RFC0364 Serving remote users on the ARPANET M.D. Abrams July 1972 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0364 RFC0365 Letter to All TIP Users D.C. Walden July 1972 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0365 RFC0366 Network Host Status E. Westheimer July 1972 ASCII HTML 4 RFC0362 RFC0367 UNKNOWN UNKNOWN Legacy 10.17487/RFC0366 RFC0367 Network host status E. Westheimer July 1972 ASCII HTML 4 RFC0366 RFC0370 UNKNOWN UNKNOWN Legacy 10.17487/RFC0367 RFC0368 Comments on "Proposed Remote Job Entry Protocol" R.T. Braden July 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0368 RFC0369 Evaluation of ARPANET services January-March, 1972 J.R. Pickens July 1972 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0369 RFC0370 Network Host Status E. Westheimer July 1972 ASCII HTML 5 RFC0367 RFC0376 UNKNOWN UNKNOWN Legacy 10.17487/RFC0370 RFC0371 Demonstration at International Computer Communications Conference R.E. Kahn July 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0371 RFC0372 Notes on a Conversation with Bob Kahn on the ICCC R.W. Watson July 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0372 RFC0373 Arbitrary Character Sets J. McCarthy July 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0373 RFC0374 IMP System Announcement A.M. McKenzie July 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0374 RFC0375 RFC0376 Network Host Status E. Westheimer August 1972 ASCII HTML 5 RFC0370 UNKNOWN UNKNOWN Legacy 10.17487/RFC0376 RFC0377 Using TSO via ARPA Network Virtual Terminal R.T. Braden August 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0377 RFC0378 Traffic statistics (July 1972) A.M. McKenzie August 1972 ASCII HTML 3 RFC0391 UNKNOWN UNKNOWN Legacy 10.17487/RFC0378 RFC0379 Using TSO at CCN R. Braden August 1972 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0379 RFC0380 RFC0381 Three aids to improved network operation J.M. McQuillan July 1972 ASCII HTML 4 RFC0394 UNKNOWN UNKNOWN Legacy 10.17487/RFC0381 RFC0382 Mathematical Software on the ARPA Network L. McDaniel August 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0382 RFC0383 RFC0384 Official site idents for organizations in the ARPA Network J.B. North August 1972 ASCII HTML 4 RFC0289 UNKNOWN UNKNOWN Legacy 10.17487/RFC0384 RFC0385 Comments on the File Transfer Protocol A.K. Bhushan August 1972 ASCII HTML 6 FTP RFC0354 RFC0414 UNKNOWN UNKNOWN Legacy 10.17487/RFC0385 RFC0386 Letter to TIP users-2 B. Cosell D.C. Walden August 1972 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0386 RFC0387 Some experiences in implementing Network Graphics Protocol Level 0 K.C. Kelley J. Meir August 1972 ASCII HTML 5 RFC0401 UNKNOWN UNKNOWN Legacy 10.17487/RFC0387 RFC0388 NCP statistics V. Cerf August 1972 ASCII HTML 5 RFC0323 UNKNOWN UNKNOWN Legacy 10.17487/RFC0388 RFC0389 UCLA Campus Computing Network Liaison Staff for ARPA Network B. Noble August 1972 ASCII HTML 2 RFC0423 UNKNOWN UNKNOWN Legacy 10.17487/RFC0389 RFC0390 TSO Scenario R.T. Braden September 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0390 RFC0391 Traffic statistics (August 1972) A.M. McKenzie September 1972 ASCII HTML 3 RFC0378 UNKNOWN UNKNOWN Legacy 10.17487/RFC0391 RFC0392 Measurement of host costs for transmitting network data G. Hicks B.D. Wessler September 1972 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0392 RFC0393 Comments on Telnet Protocol Changes J.M. Winett October 1972 ASCII HTML 4 RFC0109 RFC0139 RFC0158 RFC0318 RFC0328 UNKNOWN UNKNOWN Legacy 10.17487/RFC0393 RFC0394 Two Proposed Changes to the IMP-Host Protocol J.M. McQuillan September 1972 ASCII HTML 3 RFC0381 UNKNOWN UNKNOWN Legacy 10.17487/RFC0394 RFC0395 Switch Settings on IMPs and TIPs J.M. McQuillan October 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0395 RFC0396 Network Graphics Working Group Meeting - Second Iteration S. Bunch November 1972 ASCII HTML 1 RFC0474 UNKNOWN UNKNOWN Legacy 10.17487/RFC0396 RFC0397 RFC0398 UCSB Online Graphics J.R. Pickens E. Faeh September 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0398 RFC0399 SMFS Login and Logout M. Krilanovich September 1972 ASCII HTML 2 RFC0431 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0399 RFC0400 Traffic Statistics (September 1972) A.M. McKenzie October 1972 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0400 RFC0401 Conversion of NGP-0 Coordinates to Device Specific Coordinates J. Hansen October 1972 ASCII HTML 2 RFC0387 UNKNOWN UNKNOWN Legacy 10.17487/RFC0401 RFC0402 ARPA Network Mailing Lists J.B. North October 1972 ASCII HTML 16 RFC0363 UNKNOWN UNKNOWN Legacy 10.17487/RFC0402 RFC0403 Desirability of a Network 1108 Service G. Hicks January 1973 ASCII PDF HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0403 RFC0404 Host Address Changes Involving Rand and ISI A.M. McKenzie October 1972 ASCII HTML 1 RFC0405 UNKNOWN UNKNOWN Legacy 10.17487/RFC0404 RFC0405 Correction to RFC 404 A.M. McKenzie October 1972 ASCII HTML 1 RFC0404 UNKNOWN UNKNOWN Legacy 10.17487/RFC0405 RFC0406 Scheduled IMP Software Releases J.M. McQuillan October 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0406 RFC0407 Remote Job Entry Protocol R.D. Bressler R. Guida A.M. McKenzie October 1972 ASCII HTML 21 RJE RFC0360 HISTORIC HISTORIC Legacy 10.17487/RFC0407 RFC0408 NETBANK A.D. Owen J. Postel October 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0408 RFC0409 Tenex interface to UCSB's Simple-Minded File System J.E. White December 1972 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0409 RFC0410 Removal of the 30-Second Delay When Hosts Come Up J.M. McQuillan November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0410 RFC0411 New MULTICS Network Software Features M.A. Padlipsky November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0411 RFC0412 User FTP Documentation G. Hicks November 1972 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0412 RFC0413 Traffic statistics (October 1972) A.M. McKenzie November 1972 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0413 RFC0414 File Transfer Protocol (FTP) status and further comments A.K. Bhushan December 1972 ASCII HTML 5 RFC0385 UNKNOWN UNKNOWN Legacy 10.17487/RFC0414 RFC0415 Tenex bandwidth H. Murray November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0415 RFC0416 ARC System Will Be Unavailable for Use During Thanksgiving Week J.C. Norton November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0416 RFC0417 Link usage violation J. Postel C. Kline December 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0417 RFC0418 Server File Transfer Under TSS/360 At NASA-Ames Research Center W. Hathaway November 1972 PDF HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0418 RFC0419 To: Network liaisons and station agents A. Vezza December 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0419 RFC0420 CCA ICCC weather demo H. Murray January 1973 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0420 RFC0421 Software Consulting Service for Network Users A.M. McKenzie November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0421 RFC0422 Traffic statistics (November 1972) A.M. McKenzie December 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0422 RFC0423 UCLA Campus Computing Network Liaison Staff for ARPANET B. Noble December 1972 ASCII HTML 2 RFC0389 UNKNOWN UNKNOWN Legacy 10.17487/RFC0423 RFC0424 RFC0425 "But my NCP costs $500 a day" R.D. Bressler December 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0425 RFC0426 Reconnection Protocol R. Thomas January 1973 ASCII HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0426 RFC0427 RFC0428 RFC0429 Character Generator Process J. Postel December 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0429 RFC0430 Comments on File Transfer Protocol R.T. Braden February 1973 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0430 RFC0431 Update on SMFS Login and Logout M. Krilanovich December 1972 ASCII HTML 3 RFC0399 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0431 RFC0432 Network logical map N. Neigus December 1972 ASCII PDF PS HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0432 RFC0433 Socket number list J. Postel December 1972 ASCII HTML 5 RFC0349 RFC0503 UNKNOWN UNKNOWN Legacy 10.17487/RFC0433 RFC0434 IMP/TIP memory retrofit schedule A.M. McKenzie January 1973 ASCII HTML 2 RFC0447 UNKNOWN UNKNOWN Legacy 10.17487/RFC0434 RFC0435 Telnet issues B. Cosell D.C. Walden January 1973 ASCII HTML 10 RFC0318 UNKNOWN UNKNOWN Legacy 10.17487/RFC0435 RFC0436 Announcement of RJS at UCSB M. Krilanovich January 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0436 RFC0437 Data Reconfiguration Service at UCSB E. Faeh June 1973 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0437 RFC0438 FTP server-server interaction R. Thomas R. Clements January 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0438 RFC0439 PARRY encounters the DOCTOR V. Cerf January 1973 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0439 RFC0440 Scheduled network software maintenance D.C. Walden January 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0440 RFC0441 Inter-Entity Communication - an experiment R.D. Bressler R. Thomas January 1973 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0441 RFC0442 Current flow-control scheme for IMPSYS V. Cerf January 1973 ASCII HTML 7 RFC0449 UNKNOWN UNKNOWN Legacy 10.17487/RFC0442 RFC0443 Traffic statistics (December 1972) A.M. McKenzie January 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0443 RFC0444 RFC0445 IMP/TIP preventive maintenance schedule A.M. McKenzie January 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0445 RFC0446 Proposal to consider a network program resource notebook L.P. Deutsch January 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0446 RFC0447 IMP/TIP memory retrofit schedule A.M. McKenzie January 1973 ASCII HTML 2 RFC0434 RFC0476 UNKNOWN UNKNOWN Legacy 10.17487/RFC0447 RFC0448 Print files in FTP R.T. Braden February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0448 RFC0449 Current flow-control scheme for IMPSYS D.C. Walden January 1973 ASCII HTML 1 RFC0442 UNKNOWN UNKNOWN Legacy 10.17487/RFC0449 RFC0450 MULTICS sampling timeout change M.A. Padlipsky February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0450 RFC0451 Tentative proposal for a Unified User Level Protocol M.A. Padlipsky February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0451 RFC0452 TELNET Command at Host LL J. Winett February 1973 ASCII PDF HTML 14 UNKNOWN UNKNOWN Legacy 10.17487/RFC0452 RFC0453 Meeting announcement to discuss a network mail system M.D. Kudlick February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0453 RFC0454 File Transfer Protocol - meeting announcement and a new proposed document A.M. McKenzie February 1973 ASCII HTML 35 FTP RFC0354 UNKNOWN UNKNOWN Legacy 10.17487/RFC0454 RFC0455 Traffic statistics (January 1973) A.M. McKenzie February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0455 RFC0456 Memorandum: Date change of mail meeting M.D. Kudlick February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0456 RFC0457 TIPUG D.C. Walden February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0457 RFC0458 Mail retrieval via FTP R.D. Bressler R. Thomas February 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0458 RFC0459 Network questionnaires W. Kantrowitz February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0459 RFC0460 NCP survey C. Kline February 1973 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0460 RFC0461 Telnet Protocol meeting announcement A.M. McKenzie February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0461 RFC0462 Responding to user needs J. Iseli D. Crocker February 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0462 RFC0463 FTP comments and response to RFC 430 A.K. Bhushan February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0463 RFC0464 Resource notebook framework M.D. Kudlick February 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0464 RFC0465 RFC0466 Telnet logger/server for host LL-67 J.M. Winett February 1973 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0466 RFC0467 Proposed change to Host-Host Protocol: Resynchronization of connection status J.D. Burchfiel R.S. Tomlinson February 1973 ASCII HTML 7 RFC0492 UNKNOWN UNKNOWN Legacy 10.17487/RFC0467 RFC0468 FTP data compression R.T. Braden March 1973 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0468 RFC0469 Network mail meeting summary M.D. Kudlick March 1973 ASCII HTML 10 network mail meeting UNKNOWN UNKNOWN Legacy 10.17487/RFC0469 RFC0470 Change in socket for TIP news facility R. Thomas March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0470 RFC0471 Workshop on multi-site executive programs R. Thomas March 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0471 RFC0472 Illinois' reply to Maxwell's request for graphics information (NIC 14925) S. Bunch March 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0472 RFC0473 MIX and MIXAL? D.C. Walden February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0473 RFC0474 Announcement of NGWG meeting: Call for papers S. Bunch March 1973 ASCII HTML 2 RFC0396 UNKNOWN UNKNOWN Legacy 10.17487/RFC0474 RFC0475 FTP and Network Mail System A.K. Bhushan March 1973 ASCII PDF HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0475 RFC0476 IMP/TIP memory retrofit schedule (rev 2) A.M. McKenzie March 1973 ASCII HTML 2 RFC0447 UNKNOWN UNKNOWN Legacy 10.17487/RFC0476 RFC0477 Remote Job Service at UCSB M. Krilanovich May 1973 ASCII HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0477 RFC0478 FTP server-server interaction - II R.D. Bressler R. Thomas March 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0478 RFC0479 Use of FTP by the NIC Journal J.E. White March 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0479 RFC0480 Host-dependent FTP parameters J.E. White March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0480 RFC0481 RFC0482 Traffic statistics (February 1973) A.M. McKenzie March 1973 ASCII HTML 4 RFC0497 UNKNOWN UNKNOWN Legacy 10.17487/RFC0482 RFC0483 Cancellation of the resource notebook framework meeting M.D. Kudlick March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0483 RFC0484 RFC0485 MIX and MIXAL at UCSB J.R. Pickens March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0485 RFC0486 Data transfer revisited R.D. Bressler March 1973 ASCII HTML 2 RJE FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0486 RFC0487 Free file transfer R.D. Bressler April 1973 ASCII HTML 2 FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0487 RFC0488 NLS classes at network sites M.F. Auerbach March 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0488 RFC0489 Comment on resynchronization of connection status proposal J. Postel March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0489 RFC0490 Surrogate RJS for UCLA-CCN J.R. Pickens March 1973 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0490 RFC0491 What is "Free"? M.A. Padlipsky April 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0491 RFC0492 Response to RFC 467 E. Meyer April 1973 ASCII HTML 7 RFC0467 UNKNOWN UNKNOWN Legacy 10.17487/RFC0492 RFC0493 GRAPHICS PROTOCOL J.C. Michener I.W. Cotton K.C. Kelley D.E. Liddle E. Meyer April 1973 ASCII PDF HTML 28 RFC0292 UNKNOWN UNKNOWN Legacy 10.17487/RFC0493 RFC0494 Availability of MIX and MIXAL in the Network D.C. Walden April 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0494 RFC0495 Telnet Protocol specifications A.M. McKenzie May 1973 ASCII HTML 2 RFC0158 RFC0562 UNKNOWN UNKNOWN Legacy 10.17487/RFC0495 RFC0496 TNLS quick reference card is available M.F. Auerbach April 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0496 RFC0497 Traffic Statistics (March 1973) A.M. McKenzie April 1973 ASCII PDF HTML 4 RFC0482 UNKNOWN UNKNOWN Legacy 10.17487/RFC0497 RFC0498 On mail service to CCN R.T. Braden April 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0498 RFC0499 Harvard's network RJE B.R. Reussow April 1973 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0499 RFC0500 Integration of data management systems on a computer network A. Shoshani I. Spiegler April 1973 PDF HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0500 RFC0501 Un-muddling "free file transfer" K.T. Pogran May 1973 ASCII HTML 5 FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0501 RFC0502 RFC0503 Socket number list N. Neigus J. Postel April 1973 ASCII HTML 8 RFC0433 RFC0739 UNKNOWN UNKNOWN Legacy 10.17487/RFC0503 RFC0504 Distributed resources workshop announcement R. Thomas April 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0504 RFC0505 Two solutions to a file transfer access problem M.A. Padlipsky June 1973 ASCII HTML 3 FTP free UNKNOWN UNKNOWN Legacy 10.17487/RFC0505 RFC0506 FTP command naming problem M.A. Padlipsky June 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0506 RFC0507 RFC0508 Real-time data transmission on the ARPANET L. Pfeifer J. McAfee May 1973 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0508 RFC0509 Traffic statistics (April 1973) A.M. McKenzie April 1973 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0509 RFC0510 Request for network mailbox addresses J.E. White May 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0510 RFC0511 Enterprise phone service to NIC from ARPANET sites J.B. North May 1973 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0511 RFC0512 More on lost message detection W. Hathaway May 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0512 RFC0513 Comments on the new Telnet specifications W. Hathaway May 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0513 RFC0514 Network make-work W. Kantrowitz June 1973 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0514 RFC0515 Specifications for Datalanguage, Version 0/9 R. Winter June 1973 ASCII HTML 31 UNKNOWN UNKNOWN Legacy 10.17487/RFC0515 RFC0516 Lost message detection J. Postel May 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0516 RFC0517 RFC0518 ARPANET accounts N. Vaughan E.J. Feinler June 1973 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0518 RFC0519 Resource Evaluation J.R. Pickens June 1973 ASCII PDF HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0519 RFC0520 Memo to FTP group: Proposal for File Access Protocol J.D. Day June 1973 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0520 RFC0521 Restricted use of IMP DDT A.M. McKenzie May 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0521 RFC0522 Traffic Statistics (May 1973) A.M. McKenzie June 1973 ASCII PDF HTML 4 RFC0509 UNKNOWN UNKNOWN Legacy 10.17487/RFC0522 RFC0523 SURVEY is in operation again A.K. Bhushan June 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0523 RFC0524 Proposed Mail Protocol J.E. White June 1973 ASCII HTML 40 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=524 10.17487/RFC0524 RFC0525 MIT-MATHLAB meets UCSB-OLS -an example of resource sharing W. Parrish J.R. Pickens June 1973 ASCII PS PDF HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0525 RFC0526 Technical meeting: Digital image processing software systems W.K. Pratt June 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0526 RFC0527 ARPAWOCKY R. Merryman May 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0527 RFC0528 Software checksumming in the IMP and network reliability J.M. McQuillan June 1973 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0528 RFC0529 Note on protocol synch sequences A.M. McKenzie R. Thomas R.S. Tomlinson K.T. Pogran June 1973 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0529 RFC0530 Report on the Survey Project A.K. Bhushan June 1973 PDF HTML 0 RFC0308 RFC0523 UNKNOWN UNKNOWN Legacy 10.17487/RFC0530 RFC0531 Feast or famine? A response to two recent RFC's about network information M.A. Padlipsky June 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0531 RFC0532 UCSD-CC Server-FTP facility R.G. Merryman July 1973 ASCII HTML 4 FTP server UNKNOWN UNKNOWN Legacy 10.17487/RFC0532 RFC0533 Message-ID numbers D.C. Walden July 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0533 RFC0534 Lost message detection D.C. Walden July 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0534 RFC0535 Comments on File Access Protocol R. Thomas July 1973 ASCII PDF HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0535 RFC0536 RFC0537 Announcement of NGG meeting July 16-17 S. Bunch June 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0537 RFC0538 Traffic statistics (June 1973) A.M. McKenzie July 1973 ASCII HTML 4 RFC0556 UNKNOWN UNKNOWN Legacy 10.17487/RFC0538 RFC0539 Thoughts on the mail protocol proposed in RFC 524 D. Crocker J. Postel July 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0539 RFC0540 RFC0541 RFC0542 File Transfer Protocol N. Neigus August 1973 ASCII HTML 40 FTP RFC0354 RFC0765 RFC0614 RFC0640 RFC0454 RFC0495 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=542 10.17487/RFC0542 RFC0543 Network journal submission and delivery N.D. Meyer July 1973 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0543 RFC0544 Locating on-line documentation at SRI-ARC N.D. Meyer K. Kelley July 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0544 RFC0545 Of what quality be the UCSB resources evaluators? J.R. Pickens July 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0545 RFC0546 Tenex load averages for July 1973 R. Thomas August 1973 ASCII PS PDF HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0546 RFC0547 Change to the Very Distant Host specification D.C. Walden August 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0547 RFC0548 Hosts using the IMP Going Down message D.C. Walden August 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0548 RFC0549 Minutes of Network Graphics Group meeting, 15-17 July 1973 J.C. Michener July 1973 ASCII HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0549 RFC0550 NIC NCP experiment L.P. Deutsch August 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0550 RFC0551 NYU, ANL, and LBL Joining the Net Y. Feinroth R. Fink August 1973 ASCII PDF HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0551 RFC0552 Single access to standard protocols A.D. Owen July 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0552 RFC0553 Draft design for a text/graphics protocol C.H. Irby K. Victor July 1973 ASCII HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0553 RFC0554 RFC0555 Responses to critiques of the proposed mail protocol J.E. White July 1973 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0555 RFC0556 Traffic Statistics (July 1973) A.M. McKenzie August 1973 ASCII PDF HTML 4 RFC0538 UNKNOWN UNKNOWN Legacy 10.17487/RFC0556 RFC0557 REVELATIONS IN NETWORK HOST MEASUREMENTS B.D. Wessler August 1973 ASCII PDF HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0557 RFC0558 RFC0559 Comments on The New Telnet Protocol and its Implementation A.K. Bushan August 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0559 RFC0560 Remote Controlled Transmission and Echoing Telnet option D. Crocker J. Postel August 1973 ASCII PDF HTML 12 RFC0581 UNKNOWN UNKNOWN Legacy 10.17487/RFC0560 RFC0561 Standardizing Network Mail Headers A.K. Bhushan K.T. Pogran R.S. Tomlinson J.E. White September 1973 ASCII HTML 3 RFC0680 UNKNOWN UNKNOWN Legacy 10.17487/RFC0561 RFC0562 Modifications to the TELNET Specification A.M. McKenzie August 1973 ASCII PDF HTML 2 RFC0495 UNKNOWN UNKNOWN Legacy 10.17487/RFC0562 RFC0563 Comments on the RCTE Telnet option J. Davidson August 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0563 RFC0564 RFC0565 Storing network survey data at the datacomputer D. Cantor August 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0565 RFC0566 Traffic statistics (August 1973) A.M. McKenzie September 1973 ASCII HTML 4 RFC0579 UNKNOWN UNKNOWN Legacy 10.17487/RFC0566 RFC0567 Cross Country Network Bandwidth L.P. Deutsch September 1973 ASCII HTML 1 RFC0568 UNKNOWN UNKNOWN Legacy 10.17487/RFC0567 RFC0568 Response to RFC 567 - cross country network bandwidth J.M. McQuillan September 1973 ASCII HTML 3 RFC0567 UNKNOWN UNKNOWN Legacy 10.17487/RFC0568 RFC0569 NETED: A Common Editor for the ARPA Network M.A. Padlipsky October 1973 ASCII HTML 6 NETED HISTORIC HISTORIC Legacy 10.17487/RFC0569 RFC0570 Experimental input mapping between NVT ASCII and UCSB On Line System J.R. Pickens October 1973 ASCII PS PDF HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0570 RFC0571 TENEX FTP PROBLEM R. Braden November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0571 RFC0572 RFC0573 DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS A. Bhushan September 1973 ASCII PDF HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0573 RFC0574 Announcement of a Mail Facility at UCSB M. Krilanovich September 1973 ASCII PDF HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0574 RFC0575 RFC0576 Proposal for modifying linking K. Victor September 1973 ASCII PDF HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0576 RFC0577 Mail priority D. Crocker October 1973 ASCII PDF HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0577 RFC0578 Using MIT-Mathlab MACSYMA from MIT-DMS Muddle A.K. Bhushan N.D. Ryan October 1973 ASCII PDF HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0578 RFC0579 Traffic statistics (September 1973) A.M. McKenzie November 1973 ASCII PDF HTML 5 RFC0566 RFC0586 UNKNOWN UNKNOWN Legacy 10.17487/RFC0579 RFC0580 Note to Protocol Designers and Implementers J. Postel October 1973 ASCII HTML 1 RFC0582 UNKNOWN UNKNOWN Legacy 10.17487/RFC0580 RFC0581 Corrections to RFC 560: Remote Controlled Transmission and Echoing Telnet Option D. Crocker J. Postel November 1973 ASCII PDF HTML 5 RFC0560 UNKNOWN UNKNOWN Legacy 10.17487/RFC0581 RFC0582 Comments on RFC 580: Machine readable protocols R. Clements November 1973 ASCII HTML 1 RFC0580 UNKNOWN UNKNOWN Legacy 10.17487/RFC0582 RFC0583 RFC0584 Charter for ARPANET Users Interest Working Group J. Iseli D. Crocker N. Neigus November 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0584 RFC0585 ARPANET users interest working group meeting D. Crocker N. Neigus E.J. Feinler J. Iseli November 1973 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0585 RFC0586 Traffic statistics (October 1973) A.M. McKenzie November 1973 ASCII PDF HTML 5 RFC0579 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=586 10.17487/RFC0586 RFC0587 Announcing New Telnet Options J. Postel November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0587 RFC0588 London Node Is Now Up A. Stokes October 1973 ASCII PDF HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0588 RFC0589 CCN NETRJS server messages to remote user R.T. Braden November 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0589 RFC0590 MULTICS address change M.A. Padlipsky November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0590 RFC0591 Addition to the Very Distant Host specifications D.C. Walden November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0591 RFC0592 Some thoughts on system design to facilitate resource sharing R.W. Watson November 1973 ASCII PDF HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0592 RFC0593 Telnet and FTP implementation schedule change A.M. McKenzie J. Postel November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0593 RFC0594 Speedup of Host-IMP interface J.D. Burchfiel December 1973 ASCII PDF HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0594 RFC0595 Second thoughts in defense of the Telnet Go-Ahead W. Hathaway December 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0595 RFC0596 Second thoughts on Telnet Go-Ahead E.A. Taft December 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0596 RFC0597 Host status N. Neigus E.J. Feinler December 1973 ASCII HTML 6 RFC0603 UNKNOWN UNKNOWN Legacy 10.17487/RFC0597 RFC0598 RFC index - December 5, 1973 Network Information Center. Stanford Research Institute December 1973 PDF HTML 0 UNKNOWN UNKNOWN Legacy 10.17487/RFC0598 RFC0599 Update on NETRJS R.T. Braden December 1973 ASCII HTML 9 RFC0189 RFC0740 UNKNOWN UNKNOWN Legacy 10.17487/RFC0599 RFC0600 Interfacing an Illinois plasma terminal to the ARPANET A. Berggreen November 1973 ASCII PDF HTML 3

Discusses some unusual interface issues for the Plato terminal.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0600 RFC0601 Traffic statistics (November 1973) A.M. McKenzie December 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0601 RFC0602 "The stockings were hung by the chimney with care" R.M. Metcalfe December 1973 ASCII HTML 1 security violations TIP arpanet

Susceptibility of ARPANET to security violations.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0602 RFC0603 Response to RFC 597: Host status J.D. Burchfiel December 1973 ASCII HTML 1

Questions about the ARPANET topology described in RFC 597.

 RFC0597 RFC0613 UNKNOWN UNKNOWN Legacy 10.17487/RFC0603 RFC0604 Assigned link numbers J. Postel December 1973 ASCII HTML 2

Modifies official host-host protocol. Replaces RFC 377.

 RFC0317 RFC0739 UNKNOWN UNKNOWN Legacy 10.17487/RFC0604 RFC0605 RFC0606 Host names on-line L.P. Deutsch December 1973 ASCII HTML 3 lists names host addresses

Resolving differences in hostname-address mappings; see also RFCs 627, 625, 623 and 608.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0606 RFC0607 Comments on the File Transfer Protocol M. Krilanovich G. Gregg January 1974 ASCII HTML 3 solutions weakness ftp

An old version; see RFC 624; see also RFCs 614, 542 and 640.

 RFC0624 RFC0614 UNKNOWN UNKNOWN Legacy 10.17487/RFC0607 RFC0608 Host names on-line M.D. Kudlick January 1974 ASCII HTML 4

Response to RFC 606; see also RFCs 627, 625 and 623.

 RFC0810 UNKNOWN UNKNOWN Legacy 10.17487/RFC0608 RFC0609 Statement of upcoming move of NIC/NLS service B. Ferguson January 1974 ASCII HTML 2

See also RFCs 621 and 620.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0609 RFC0610 Further datalanguage design concepts R. Winter J. Hill W. Greiff December 1973 ASCII HTML 88

Preliminary results of the language design; a model for data languagea semantics; future considerations.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0610 RFC0611 Two changes to the IMP/Host Protocol to improve user/network communications D.C. Walden February 1974 ASCII HTML 4

Expansion of Host-Going-Down and addition of Dead-Host-Status Message.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0611 RFC0612 Traffic statistics (December 1973) A.M. McKenzie January 1974 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0612 RFC0613 Network connectivity: A response to RFC 603 A.M. McKenzie January 1974 ASCII HTML 1 RFC0603 UNKNOWN UNKNOWN Legacy 10.17487/RFC0613 RFC0614 Response to RFC 607: "Comments on the File Transfer Protocol" K.T. Pogran N. Neigus January 1974 ASCII HTML 3 ftp weakness solutions

See also RFCs 624, 542 and 640.

 RFC0542 RFC0607 UNKNOWN UNKNOWN Legacy 10.17487/RFC0614 RFC0615 Proposed Network Standard Data Pathname syntax D. Crocker March 1974 ASCII HTML 4 RFC0645 UNKNOWN UNKNOWN Legacy 10.17487/RFC0615 RFC0616 LATEST NETWORK MAPS D. Walden February 1973 ASCII PDF HTML 1 Network maps UNKNOWN UNKNOWN Legacy 10.17487/RFC0616 RFC0617 Note on socket number assignment E.A. Taft February 1974 ASCII HTML 3 telnet

Danger of imposing more fixed socket number requirements; see also RFCs 542, 503 and 451.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0617 RFC0618 Few observations on NCP statistics E.A. Taft February 1974 ASCII HTML 3

Distribution of NCP and IMP message types by actual measurement.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0618 RFC0619 Mean round-trip times in the ARPANET W. Naylor H. Opderbeck March 1974 ASCII HTML 14

Actual measurements of round-trip times.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0619 RFC0620 Request for monitor host table updates B. Ferguson March 1974 ASCII HTML 1 tenex

In conjunction with moving NIC users to OFFICE-1; see also RFCs 621 and 609.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0620 RFC0621 NIC user directories at SRI ARC M.D. Kudlick March 1974 ASCII HTML 1

See also RFCs 620 and 609.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0621 RFC0622 Scheduling IMP/TIP down time A.M. McKenzie March 1974 ASCII HTML 3

Modification of previous policy.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0622 RFC0623 Comments on on-line host name service M. Krilanovich February 1974 ASCII HTML 2

See also RFCs 627, 625, 608 and 606.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0623 RFC0624 Comments on the File Transfer Protocol M. Krilanovich G. Gregg W. Hathaway J.E. White February 1974 ASCII HTML 3 ftp telnet

Design changes and slight modifications. Replaces RFC 607; see also RFCs 614, 542 and 640.

 RFC0607 UNKNOWN UNKNOWN Legacy 10.17487/RFC0624 RFC0625 On-line hostnames service M.D. Kudlick E.J. Feinler March 1974 ASCII HTML 1

See also RFCs 606, 608, 623 and 627.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0625 RFC0626 On a possible lockup condition in IMP subnet due to message sequencing L. Kleinrock H. Opderbeck March 1974 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0626 RFC0627 ASCII text file of hostnames M.D. Kudlick E.J. Feinler March 1974 ASCII HTML 1

See also RFCs 606, 608, 623 and 625.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0627 RFC0628 Status of RFC numbers and a note on pre-assigned journal numbers M.L. Keeney March 1974 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0628 RFC0629 Scenario for using the Network Journal J.B. North March 1974 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0629 RFC0630 FTP error code usage for more reliable mail service J. Sussman April 1974 ASCII HTML 3

Describes FTP reply-code usage in TENEX mail processing.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0630 RFC0631 International meeting on minicomputers and data communication: Call for papers A. Danthine April 1974 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0631 RFC0632 Throughput degradations for single packet messages H. Opderbeck May 1974 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0632 RFC0633 IMP/TIP preventive maintenance schedule A.M. McKenzie March 1974 ASCII HTML 4

An old version; see RFC 638.

 RFC0638 UNKNOWN UNKNOWN Legacy 10.17487/RFC0633 RFC0634 Change in network address for Haskins Lab A.M. McKenzie April 1974 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0634 RFC0635 Assessment of ARPANET protocols V. Cerf April 1974 ASCII PDF HTML 1

Theoretical and practical motivation for redesign. Multipacket messages; host retransmission; duplicate detection; sequencing; acknowledgement.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0635 RFC0636 TIP/Tenex reliability improvements J.D. Burchfiel B. Cosell R.S. Tomlinson D.C. Walden June 1974 ASCII HTML 8

Obtaining/maintaining connections; recovery from lost connections; connection-state changes.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0636 RFC0637 Change of network address for SU-DSL A.M. McKenzie April 1974 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0637 RFC0638 IMP/TIP preventive maintenance schedule A.M. McKenzie April 1974 ASCII HTML 4

Corrects RFC 633.

 RFC0633 UNKNOWN UNKNOWN Legacy 10.17487/RFC0638 RFC0639 RFC0640 Revised FTP reply codes J. Postel June 1974 ASCII HTML 17

Updates RFC 542.

 RFC0542 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=640 10.17487/RFC0640 RFC0641 RFC0642 Ready line philosophy and implementation J.D. Burchfiel July 1974 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0642 RFC0643 Network Debugging Protocol E. Mader July 1974 ASCII HTML 7

To be used in an implementation of a PDP-11 network bootstrap device and a cross-network debugger.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0643 RFC0644 On the problem of signature authentication for network mail R. Thomas July 1974 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0644 RFC0645 Network Standard Data Specification syntax D. Crocker June 1974 ASCII PDF HTML 9

Providing a mechanism for specifying all attributes of a collection of bits; see also RFC 615.

 RFC0615 UNKNOWN UNKNOWN Legacy 10.17487/RFC0645 RFC0646 RFC0647 Proposed protocol for connecting host computers to ARPA-like networks via front end processors M.A. Padlipsky November 1974 ASCII PDF HTML 20

Approaches to Front-End protocol processing using available hardware and software.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0647 RFC0648 RFC0649 RFC0650 RFC0651 Revised Telnet status option D. Crocker October 1974 ASCII HTML 2 RFC0859 UNKNOWN UNKNOWN Legacy 10.17487/RFC0651 RFC0652 Telnet output carriage-return disposition option D. Crocker October 1974 ASCII HTML 4 TOPT-OCRD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0652 RFC0653 Telnet output horizontal tabstops option D. Crocker October 1974 ASCII HTML 1 TOPT-OHT HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0653 RFC0654 Telnet output horizontal tab disposition option D. Crocker October 1974 ASCII HTML 1 TOPT-OHTD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0654 RFC0655 Telnet output formfeed disposition option D. Crocker October 1974 ASCII HTML 1 TOPT-OFD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0655 RFC0656 Telnet output vertical tabstops option D. Crocker October 1974 ASCII HTML 1 TOPT-OVT HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0656 RFC0657 Telnet output vertical tab disposition option D. Crocker October 1974 ASCII HTML 1 TOPT-OVTD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0657 RFC0658 Telnet output linefeed disposition D. Crocker October 1974 ASCII HTML 2 TOPT-OLD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0658 RFC0659 Announcing additional Telnet options J. Postel October 1974 ASCII HTML 1

Options defined in RFCs 651-658.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0659 RFC0660 Some changes to the IMP and the IMP/Host interface D.C. Walden October 1974 ASCII HTML 1

Decoupling of message number sequences of hosts; host-host access control; message number window; messages outside normal mechanism; see also BBN 1822.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0660 RFC0661 Protocol information J. Postel November 1974 ASCII PDF HTML 21

An old version; see RFC 694.

 RFC0694 UNKNOWN UNKNOWN Legacy 10.17487/RFC0661 RFC0662 Performance improvement in ARPANET file transfers from Multics R. Kanodia November 1974 ASCII HTML 2

Experimenting with host output buffers to improve throughput.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0662 RFC0663 Lost message detection and recovery protocol R. Kanodia November 1974 ASCII HTML 22 ARPANET Host

Proposed extension of host-host protocol; see also RFCs 534, 516, 512, 492 and 467.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0663 RFC0664 RFC0665 RFC0666 Specification of the Unified User-Level Protocol M.A. Padlipsky November 1974 ASCII HTML 19

Discusses and proposes a common command language.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0666 RFC0667 Host Ports S.G. Chipman December 1974 ASCII PDF HTML 2

Approved scheme to connect host ports to the network.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0667 RFC0668 RFC0669 November, 1974, survey of New-Protocol Telnet servers D.W. Dodds December 1974 ASCII PDF HTML 3

An earlier poll of Telnet server implementation status. Updates RFC 702; see also RFCs 703 and 679.

 RFC0702 RFC0679 UNKNOWN UNKNOWN Legacy 10.17487/RFC0669 RFC0670 RFC0671 Note on Reconnection Protocol R. Schantz December 1974 ASCII PDF HTML 9

Experience with implementation in RSEXEC context.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0671 RFC0672 Multi-site data collection facility R. Schantz December 1974 ASCII HTML 9

Applicability of TIP/TENEX protocols beyond TIP accounting.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0672 RFC0673 RFC0674 Procedure call documents: Version 2 J. Postel J.E. White December 1974 ASCII HTML 6

Host level protocol used in the NSW--a slightly constrained version of ARPANET Host-to-Host protocol, affecting allocation, RFNM wait, and retransmission; see also RFC 684.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0674 RFC0675 Specification of Internet Transmission Control Program V. Cerf Y. Dalal C. Sunshine December 1974 ASCII HTML 70

The first detailed specification of TCP; see RFC 793.

 RFC7805 HISTORIC UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=675 10.17487/RFC0675 RFC0676 RFC0677 Maintenance of duplicate databases P.R. Johnson R. Thomas January 1975 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0677 RFC0678 Standard file formats J. Postel December 1974 ASCII HTML 9

For transmission of documents across different environments.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0678 RFC0679 February, 1975, survey of New-Protocol Telnet servers D.W. Dodds February 1975 ASCII PDF HTML 3

An earlier poll of Telnet server implementation status. Updates RFCs 701, 702 and 669; see also RFC 703.

 RFC0669 RFC0703 UNKNOWN UNKNOWN Legacy 10.17487/RFC0679 RFC0680 Message Transmission Protocol T.H. Myer D.A. Henderson April 1975 ASCII HTML 6

Extends message field definition beyond RFC 561 attempts to establish syntactic and semantic standards for ARPANET; see also RFCs 733 and 822.

 RFC0561 UNKNOWN UNKNOWN Legacy 10.17487/RFC0680 RFC0681 Network UNIX S. Holmgren March 1975 ASCII HTML 8

Capabilities as an ARPANET Mini-Host: standard I/O, Telnet, NCP, Hardware/Software requirements, reliability, availability.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0681 RFC0682 RFC0683 FTPSRV - Tenex extension for paged files R. Clements April 1975 ASCII HTML 3 FTP paged file transfer Tenex

Defines an extension to FTP for page-mode transfers between TENEX systems; also discusses file transfer reliability.

 RFC0354 UNKNOWN UNKNOWN Legacy 10.17487/RFC0683 RFC0684 Commentary on procedure calling as a network protocol R. Schantz April 1975 ASCII HTML 9

Issues in designing distributed computing systems. Shortcomings of RFC 674; see also RFCs 542 and 354.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0684 RFC0685 Response time in cross network debugging M. Beeler April 1975 ASCII HTML 3

The contribution of ARPANET communication to response time.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0685 RFC0686 Leaving well enough alone B. Harvey May 1975 ASCII HTML 9

Discusses difference between early and later versions of FTP; see also RFCs 691, 640, 630, 542, 454, 448, 414, 385 and 354.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0686 RFC0687 IMP/Host and Host/IMP Protocol changes D.C. Walden June 1975 ASCII HTML 2

Addressing hosts on more than 63 IMPs, and other backwards compatible expansions; see also RFCs 690 and 692.

 RFC0704 RFC0690 UNKNOWN UNKNOWN Legacy 10.17487/RFC0687 RFC0688 Tentative schedule for the new Telnet implementation for the TIP D.C. Walden June 1975 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0688 RFC0689 Tenex NCP finite state machine for connections R. Clements May 1975 ASCII HTML 5

Describes the internal states of an NCP connection in the TENEX implementation.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0689 RFC0690 Comments on the proposed Host/IMP Protocol changes J. Postel June 1975 ASCII HTML 3

Comments on suggestions in RFC 687; see also RFCs 692 and 696.

 RFC0687 RFC0692 UNKNOWN UNKNOWN Legacy 10.17487/RFC0690 RFC0691 One more try on the FTP B. Harvey June 1975 ASCII HTML 14

Slight revision of RFC 686, on the subject of print files; see also RFCs 640, 630, 542, 454, 448, 414, 385 and 354.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0691 RFC0692 Comments on IMP/Host Protocol changes (RFCs 687 and 690) S.M. Wolfe June 1975 ASCII HTML 2

A proposed solution to the problem of combined length of IMP and Host leaders; see also RFCs 696, 690 and 687.

 RFC0690 UNKNOWN UNKNOWN Legacy 10.17487/RFC0692 RFC0693 RFC0694 Protocol information J. Postel June 1975 ASCII PDF HTML 36

References to documents and contacts concerning the various protocols used in the ARPANET, as well as recent developments; updates RFC 661.

 RFC0661 UNKNOWN UNKNOWN Legacy 10.17487/RFC0694 RFC0695 Official change in Host-Host Protocol M. Krilanovich July 1975 ASCII HTML 3

Corrects ambiguity concerning the ERR command; changes NIC 8246 and NIC 7104.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0695 RFC0696 Comments on the IMP/Host and Host/IMP Protocol changes V.G. Cerf July 1975 ASCII PDF HTML 2

Observations on current international standards recommendations from IFIP working group 6.1; see also RFCs 692, 690, 687.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0696 RFC0697 CWD command of FTP J. Lieb July 1975 ASCII HTML 2

Discusses FTP login access to "files only" directories.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0697 RFC0698 Telnet extended ASCII option T. Mock July 1975 ASCII HTML 3 TOPT-EXT

Describes an option to allow transmission of a special kind of extended ASCII used at the Stanford AI and MIT AI Labs.

 RFC5198 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0698 RFC0699 Request For Comments summary notes: 600-699 J. Postel J. Vernon November 1982 ASCII HTML 9 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0699 RFC0700 Protocol experiment E. Mader W.W. Plummer R.S. Tomlinson August 1974 ASCII HTML 7 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0700 RFC0701 August, 1974, survey of New-Protocol Telnet servers D.W. Dodds August 1974 ASCII HTML 1 RFC0702 UNKNOWN UNKNOWN Legacy 10.17487/RFC0701 RFC0702 September, 1974, survey of New-Protocol Telnet servers D.W. Dodds September 1974 ASCII HTML 3 RFC0701 RFC0669 UNKNOWN UNKNOWN Legacy 10.17487/RFC0702 RFC0703 July, 1975, survey of New-Protocol Telnet Servers D.W. Dodds July 1975 ASCII HTML 3 RFC0679 UNKNOWN UNKNOWN Legacy 10.17487/RFC0703 RFC0704 IMP/Host and Host/IMP Protocol change P.J. Santos September 1975 ASCII HTML 2 RFC0687 UNKNOWN UNKNOWN Legacy 10.17487/RFC0704 RFC0705 Front-end Protocol B6700 version R.F. Bryan November 1975 ASCII HTML 39 UNKNOWN UNKNOWN Legacy 10.17487/RFC0705 RFC0706 On the junk mail problem J. Postel November 1975 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0706 RFC0707 High-level framework for network-based resource sharing J.E. White December 1975 ASCII HTML 29 UNKNOWN UNKNOWN Legacy 10.17487/RFC0707 RFC0708 Elements of a Distributed Programming System J.E. White January 1976 ASCII HTML 30 UNKNOWN UNKNOWN Legacy 10.17487/RFC0708 RFC0709 RFC0710 RFC0711 RFC0712 Distributed Capability Computing System (DCCS) J.E. Donnelley February 1976 ASCII PDF HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0712 RFC0713 MSDTP-Message Services Data Transmission Protocol J. Haverty April 1976 ASCII HTML 21 UNKNOWN UNKNOWN Legacy 10.17487/RFC0713 RFC0714 Host-Host Protocol for an ARPANET-Type Network A.M. McKenzie April 1976 ASCII PDF HTML 22 UNKNOWN UNKNOWN Legacy 10.17487/RFC0714 RFC0715 RFC0716 Interim Revision to Appendix F of BBN 1822 D.C. Walden J. Levin May 1976 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0716 RFC0717 Assigned Network Numbers J. Postel July 1976 ASCII HTML 1 HISTORIC UNKNOWN Legacy 10.17487/RFC0717 RFC0718 Comments on RCTE from the Tenex Implementation Experience J. Postel June 1976 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0718 RFC0719 Discussion on RCTE J. Postel July 1976 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0719 RFC0720 Address Specification Syntax for Network Mail D. Crocker August 1976 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0720 RFC0721 Out-of-Band Control Signals in a Host-to-Host Protocol L.L. Garlick September 1976 ASCII HTML 7 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0721 RFC0722 Thoughts on Interactions in Distributed Services J. Haverty September 1976 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0722 RFC0723 RFC0724 Proposed official standard for the format of ARPA Network messages D. Crocker K.T. Pogran J. Vittal D.A. Henderson May 1977 ASCII HTML 36 RFC0733 UNKNOWN UNKNOWN Legacy 10.17487/RFC0724 RFC0725 RJE protocol for a resource sharing network J.D. Day G.R. Grossman March 1977 ASCII HTML 27 UNKNOWN UNKNOWN Legacy 10.17487/RFC0725 RFC0726 Remote Controlled Transmission and Echoing Telnet option J. Postel D. Crocker March 1977 ASCII HTML 16 TOPT-REM PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0726 RFC0727 Telnet logout option M.R. Crispin April 1977 ASCII HTML 3 TOPT-LOGO PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0727 RFC0728 Minor pitfall in the Telnet Protocol J.D. Day April 1977 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0728 RFC0729 Telnet byte macro option D. Crocker May 1977 ASCII HTML 3 RFC0735 UNKNOWN UNKNOWN Legacy 10.17487/RFC0729 RFC0730 Extensible field addressing J. Postel May 1977 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0730 RFC0731 Telnet Data Entry Terminal option J.D. Day June 1977 ASCII HTML 28 RFC0732 UNKNOWN UNKNOWN Legacy 10.17487/RFC0731 RFC0732 Telnet Data Entry Terminal option J.D. Day September 1977 ASCII HTML 30 RFC0731 RFC1043 UNKNOWN UNKNOWN Legacy 10.17487/RFC0732 RFC0733 Standard for the format of ARPA network text messages D. Crocker J. Vittal K.T. Pogran D.A. Henderson November 1977 ASCII HTML 38 RFC0724 RFC0822 UNKNOWN UNKNOWN Legacy 10.17487/RFC0733 RFC0734 SUPDUP Protocol M.R. Crispin October 1977 ASCII HTML 13 SUPDUP HISTORIC HISTORIC Legacy 10.17487/RFC0734 RFC0735 Revised Telnet byte macro option D. Crocker R.H. Gumpertz November 1977 ASCII HTML 5 TOPT-BYTE RFC0729 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0735 RFC0736 Telnet SUPDUP option M.R. Crispin October 1977 ASCII HTML 1 TOPT-SUP PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0736 RFC0737 FTP extension: XSEN K. Harrenstien October 1977 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0737 RFC0738 Time server K. Harrenstien October 1977 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0738 RFC0739 Assigned numbers J. Postel November 1977 ASCII HTML 11 RFC0604 RFC0503 RFC0750 HISTORIC UNKNOWN Legacy 10.17487/RFC0739 RFC0740 NETRJS Protocol R.T. Braden November 1977 ASCII HTML 19 NETRJS RFC0599 HISTORIC HISTORIC Legacy 10.17487/RFC0740 RFC0741 Specifications for the Network Voice Protocol (NVP) D. Cohen November 1977 ASCII HTML 34 UNKNOWN UNKNOWN Legacy 10.17487/RFC0741 RFC0742 NAME/FINGER Protocol K. Harrenstien December 1977 ASCII HTML 7 RFC1288 RFC1196 RFC1194 UNKNOWN UNKNOWN Legacy 10.17487/RFC0742 RFC0743 FTP extension: XRSQ/XRCP K. Harrenstien December 1977 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0743 RFC0744 MARS - a Message Archiving and Retrieval Service J. Sattley January 1978 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0744 RFC0745 JANUS interface specifications M. Beeler March 1978 ASCII HTML 10 JANUS interface specifications UNKNOWN UNKNOWN Legacy 10.17487/RFC0745 RFC0746 SUPDUP graphics extension R. Stallman March 1978 ASCII HTML 15 UNKNOWN UNKNOWN Legacy 10.17487/RFC0746 RFC0747 Recent extensions to the SUPDUP Protocol M.R. Crispin March 1978 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0747 RFC0748 Telnet randomly-lose option M.R. Crispin April 1 1978 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0748 RFC0749 Telnet SUPDUP-Output option B. Greenberg September 1978 ASCII HTML 4 TOPT-SUPO PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0749 RFC0750 Assigned numbers J. Postel September 1978 ASCII HTML 12 RFC0739 RFC0755 HISTORIC UNKNOWN Legacy 10.17487/RFC0750 RFC0751 Survey of FTP mail and MLFL P.D. Lebling December 1978 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0751 RFC0752 Universal host table M.R. Crispin January 1979 ASCII HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0752 RFC0753 Internet Message Protocol J. Postel March 1979 ASCII HTML 62 UNKNOWN UNKNOWN Legacy 10.17487/RFC0753 RFC0754 Out-of-net host addresses for mail J. Postel April 1979 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0754 RFC0755 Assigned numbers J. Postel May 1979 ASCII HTML 12 RFC0750 RFC0758 HISTORIC UNKNOWN Legacy 10.17487/RFC0755 RFC0756 NIC name server - a datagram-based information utility J.R. Pickens E.J. Feinler J.E. Mathis July 1979 ASCII HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0756 RFC0757 Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems D.P. Deutsch September 1979 ASCII HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0757 RFC0758 Assigned numbers J. Postel August 1979 ASCII HTML 12 RFC0755 RFC0762 HISTORIC UNKNOWN Legacy 10.17487/RFC0758 RFC0759 Internet Message Protocol J. Postel August 1980 ASCII HTML 77 MPM HISTORIC HISTORIC Legacy 10.17487/RFC0759 RFC0760 DoD standard Internet Protocol J. Postel January 1980 ASCII HTML 46 IEN123 RFC0791 RFC0777 UNKNOWN UNKNOWN Legacy 10.17487/RFC0760 RFC0761 DoD standard Transmission Control Protocol J. Postel January 1980 ASCII HTML 88 TCP RFC0793 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0761 RFC0762 Assigned numbers J. Postel January 1980 ASCII HTML 13 RFC0758 RFC0770 HISTORIC UNKNOWN Legacy 10.17487/RFC0762 RFC0763 Role mailboxes M.D. Abrams May 1980 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0763 RFC0764 Telnet Protocol specification J. Postel June 1980 ASCII HTML 15 RFC0854 UNKNOWN UNKNOWN Legacy 10.17487/RFC0764 RFC0765 File Transfer Protocol specification J. Postel June 1980 ASCII HTML 70 RFC0542 RFC0959 UNKNOWN UNKNOWN Legacy 10.17487/RFC0765 RFC0766 Internet Protocol Handbook: Table of contents J. Postel July 1980 ASCII HTML 2 RFC0774 UNKNOWN UNKNOWN Legacy 10.17487/RFC0766 RFC0767 Structured format for transmission of multi-media documents J. Postel August 1980 ASCII HTML 40 UNKNOWN UNKNOWN Legacy 10.17487/RFC0767 RFC0768 User Datagram Protocol J. Postel August 1980 ASCII HTML 3 UDP STD0006 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0768 RFC0769 Rapicom 450 facsimile file format J. Postel September 1980 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0769 RFC0770 Assigned numbers J. Postel September 1980 ASCII HTML 15 RFC0762 RFC0776 HISTORIC UNKNOWN Legacy 10.17487/RFC0770 RFC0771 Mail transition plan V.G. Cerf J. Postel September 1980 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0771 RFC0772 Mail Transfer Protocol S. Sluizer J. Postel September 1980 ASCII HTML 31 MTP email RFC0780 UNKNOWN UNKNOWN Legacy 10.17487/RFC0772 RFC0773 Comments on NCP/TCP mail service transition strategy V.G. Cerf October 1980 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0773 RFC0774 Internet Protocol Handbook: Table of contents J. Postel October 1980 ASCII HTML 3 RFC0766 UNKNOWN UNKNOWN Legacy 10.17487/RFC0774 RFC0775 Directory oriented FTP commands D. Mankins D. Franklin A.D. Owen December 1980 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0775 RFC0776 Assigned numbers J. Postel January 1981 ASCII HTML 13 RFC0770 RFC0790 HISTORIC UNKNOWN Legacy 10.17487/RFC0776 RFC0777 Internet Control Message Protocol J. Postel April 1981 ASCII HTML 14 RFC0792 RFC0760 UNKNOWN UNKNOWN Legacy 10.17487/RFC0777 RFC0778 DCNET Internet Clock Service D.L. Mills April 1981 ASCII HTML 4 CLOCK HISTORIC HISTORIC Legacy 10.17487/RFC0778 RFC0779 Telnet send-location option E. Killian April 1981 ASCII HTML 2 TOPT-SNDL PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0779 RFC0780 Mail Transfer Protocol S. Sluizer J. Postel May 1981 ASCII HTML 47 MTP email RFC0772 RFC0788 UNKNOWN UNKNOWN Legacy 10.17487/RFC0780 RFC0781 Specification of the Internet Protocol (IP) timestamp option Z. Su May 1981 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0781 RFC0782 Virtual Terminal management model J. Nabielsky A.P. Skelton January 1981 ASCII HTML 23 UNKNOWN UNKNOWN Legacy 10.17487/RFC0782 RFC0783 TFTP Protocol (revision 2) K.R. Sollins June 1981 ASCII HTML 18 IEN133 RFC1350 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=783 10.17487/RFC0783 RFC0784 Mail Transfer Protocol: ISI TOPS20 implementation S. Sluizer J. Postel July 1981 ASCII HTML 3 MTP email UNKNOWN UNKNOWN Legacy 10.17487/RFC0784 RFC0785 Mail Transfer Protocol: ISI TOPS20 file definitions S. Sluizer J. Postel July 1981 ASCII HTML 3 MTP email UNKNOWN UNKNOWN Legacy 10.17487/RFC0785 RFC0786 Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL interface S. Sluizer J. Postel July 1981 ASCII HTML 2 MTP NIMAIL TOPS20 UNKNOWN UNKNOWN Legacy 10.17487/RFC0786 RFC0787 Connectionless data transmission survey/tutorial A.L. Chapin July 1981 ASCII HTML 40 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=787 10.17487/RFC0787 RFC0788 Simple Mail Transfer Protocol J. Postel November 1981 ASCII HTML 64 SMTP email RFC0780 RFC0821 UNKNOWN UNKNOWN Legacy 10.17487/RFC0788 RFC0789 Vulnerabilities of network control protocols: An example E.C. Rosen July 1981 ASCII HTML 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0789 RFC0790 Assigned numbers J. Postel September 1981 ASCII HTML 15 RFC0776 RFC0820 HISTORIC UNKNOWN Legacy 10.17487/RFC0790 RFC0791 Internet Protocol J. Postel September 1981 ASCII HTML 51 IP IPv4 RFC0760 RFC1349 RFC2474 RFC6864 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=791 10.17487/RFC0791 RFC0792 Internet Control Message Protocol J. Postel September 1981 ASCII HTML 21 ICMP RFC0777 RFC0950 RFC4884 RFC6633 RFC6918 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=792 10.17487/RFC0792 RFC0793 Transmission Control Protocol J. Postel September 1981 ASCII HTML 91 TCP RFC0761 RFC9293 RFC1122 RFC3168 RFC6093 RFC6528 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=793 10.17487/RFC0793 RFC0794 Pre-emption V.G. Cerf September 1981 ASCII HTML 2 IEN125 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0794 RFC0795 Service mappings J. Postel September 1981 ASCII HTML 4 HISTORIC UNKNOWN Legacy 10.17487/RFC0795 RFC0796 Address mappings J. Postel September 1981 ASCII HTML 7 IEN115 HISTORIC UNKNOWN Legacy 10.17487/RFC0796 RFC0797 Format for Bitmap files A.R. Katz September 1981 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0797 RFC0798 Decoding facsimile data from the Rapicom 450 A.R. Katz September 1981 ASCII HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0798 RFC0799 Internet name domains D.L. Mills September 1981 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0799 RFC0800 Request For Comments summary notes: 700-799 J. Postel J. Vernon November 1982 ASCII HTML 10

This RFC is a slightly annotated list of the 100 RFCs from RFC 700 through RFC 799. This is a status report on these RFCs.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0800 RFC0801 NCP/TCP transition plan J. Postel November 1981 ASCII HTML 21

This RFC discusses the conversion of hosts from NCP to TCP. And making available the principle services: Telnet, File Transfer, and Mail. These protocols allow all hosts in the ARPA community to share a common interprocess communication environment.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0801 RFC0802 ARPANET 1822L Host Access Protocol A.G. Malis November 1981 ASCII HTML 45

This document proposed two major changes to the current ARPANET host access protocol. The first change will allow hosts to use logical addressing (i.e., host addresses that are independent of their physical location on the ARPANET) to communicate with each other, and the second will allow a host to shorten the amount of time that it may be blocked by its IMP after it presents a message to the network (currently, the IMP can block further input from a host for up to 15 seconds). See RFCs 852 and 851.

 RFC0851 UNKNOWN UNKNOWN Legacy 10.17487/RFC0802 RFC0803 Dacom 450/500 facsimile data transcoding A. Agarwal M.J. O'Connor D.L. Mills November 1981 ASCII HTML 14

The first part of this RFC describes in detail the Dacom 450 data compression algorithms and is an update and correction to an earlier memorandum. The second part of this RFC describes briefly the Dacom 500 data compression algorithm as used by the INTELPOST electronic-mail network under development by the US Postal Service and several foreign administrators.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0803 RFC0804 CCITT draft recommendation T.4 International Telegraph and Telephone Consultative Committee of the International Telecommunication Union January 1981 ASCII HTML 12

This is the CCITT standard for group 3 facsimile encoding. This is useful for data compression of bit map data.

 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=804 10.17487/RFC0804 RFC0805 Computer mail meeting notes J. Postel February 1982 ASCII HTML 6

This RFC consists of notes from a meeting that was held at USC Information Sciences Institute on 11 January 1982, to discuss addressing issues in computer mail. The major conclusion reached at the meeting is to extend the "username@hostname" mailbox format to "username@host.domain", where the domain itself can be further strutured.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0805 RFC0806 Proposed Federal Information Processing Standard: Specification for message format for computer based message systems National Bureau of Standards September 1981 ASCII HTML 107

This RFC deals with Computer Based Message systems which provides a basis for interaction between different CBMS by defining the format of messages passed between them. This RFC is replaced by RFC 841.

 RFC0841 UNKNOWN UNKNOWN Legacy 10.17487/RFC0806 RFC0807 Multimedia mail meeting notes J. Postel February 1982 ASCII HTML 6

This RFC consists of notes from a meeting held at USC Information Sciences Institute on the 12th of January to discuss common interests in multimedia computer mail issues and to agree on some specific initial experiments.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0807 RFC0808 Summary of computer mail services meeting held at BBN on 10 January 1979 J. Postel March 1982 ASCII HTML 8

This RFC is a very belated attempt to document a meeting that was held three years earlier to discuss the state of computer mail in the ARPA community and to reach some conclusions to guide the further development of computer mail systems such that a coherent total mail service would continue to be provided.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0808 RFC0809 UCL facsimile system T. Chang February 1982 ASCII HTML 99

This RFC describes the features of the computerised facsimile system developed in the Department of Computer Science at UCL. First its functions are considered and the related experimental work are reported. Then the disciplines for system design are discussed. Finally, the implementation of the system are described, while detailed description are given as appendices.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0809 RFC0810 DoD Internet host table specification E.J. Feinler K. Harrenstien Z. Su V. White March 1982 ASCII HTML 8

This RFC specifies a new host table format applicable to both ARPANET and Internet needs. In addition to host name to host address translation and selected protocol information, we have also included network and gateway name to address correspondence, and host operating system information. This RFC obsoletes the host table described in RFC 608.

 RFC0608 RFC0952 UNKNOWN UNKNOWN Legacy 10.17487/RFC0810 RFC0811 Hostnames Server K. Harrenstien V. White E.J. Feinler March 1982 ASCII HTML 4

This RFC gives a description of what the Hostnames Server is and how to access it. The function of this particular server is to deliver machine-readable name/address information describing networks, gateways, hosts, and eventually domains, within the internet environment.

 RFC0953 UNKNOWN UNKNOWN Legacy 10.17487/RFC0811 RFC0812 NICNAME/WHOIS K. Harrenstien V. White March 1982 ASCII HTML 2

This RFC gives a description of what the NICNAME/WHOIS Server is and how to access it. This server together with the corresponding Identification Data Base provides online directory look-up equivalent to the ARPANET Directory.

 RFC0954 RFC3912 UNKNOWN UNKNOWN Legacy 10.17487/RFC0812 RFC0813 Window and Acknowledgement Strategy in TCP D.D. Clark July 1982 ASCII HTML 21

This RFC describes implementation strategies to deal with two mechanisms in TCP, the window and the acknowledgement. It also presents a particular set of algorithms which have received testing in the field, and which appear to work properly with each other. With more experience, these algorithms may become part of the formal specification, until such time their use is recommended.

 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0813 RFC0814 Name, addresses, ports, and routes D.D. Clark July 1982 ASCII HTML 13

This RFC gives suggestions and guidance for the design of the tables and algorithms necessary to keep track of these various sorts of identifiers inside a host implementation of TCP/IP.

 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0814 RFC0815 IP datagram reassembly algorithms D.D. Clark July 1982 ASCII HTML 8

This RFC describes an alternate approach of dealing with reassembly which reduces the bookkeeping problem to a minimum, and requires only one buffer for storage equal in size to the final datagram being reassembled, which can reassemble a datagram from any number of fragments arriving in any order with any possible pattern of overlap and duplication, and which is appropriate for almost any sort of operating system.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0815 RFC0816 Fault isolation and recovery D.D. Clark July 1982 ASCII HTML 11

This RFC describes the portion of fault isolation and recovery which is the responsibility of the host.

 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0816 RFC0817 Modularity and efficiency in protocol implementation D.D. Clark July 1982 ASCII HTML 25

This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly.

 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0817 RFC0818 Remote User Telnet service J. Postel November 1982 ASCII HTML 2 RTELNET

This RFC is the specification of an application protocol. Any host that implements this application level service must follow this protocol.

 HISTORIC HISTORIC Legacy 10.17487/RFC0818 RFC0819 The Domain Naming Convention for Internet User Applications Z. Su J. Postel August 1982 ASCII HTML 18

This RFC is an attempt to clarify the generalization of the Domain Naming Convention, the Internet Naming Convention, and to explore the implications of its adoption for Internet name service and user applications.

 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=819 10.17487/RFC0819 RFC0820 Assigned numbers J. Postel August 1982 ASCII HTML 22

This RFC is an old version, see RFC 870.

 RFC0790 RFC0870 HISTORIC UNKNOWN Legacy 10.17487/RFC0820 RFC0821 Simple Mail Transfer Protocol J. Postel August 1982 ASCII HTML 72 SMTP

The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Obsoletes RFC 788, 780, and 772.

 RFC0788 RFC2821 STD0010 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0821 RFC0822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES D. Crocker August 1982 ASCII HTML 49 MAIL

This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced. Obsoletes RFC 733, NIC 41952.

 RFC0733 RFC2822 RFC1123 RFC2156 RFC1327 RFC1138 RFC1148 STD0011 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=822 10.17487/RFC0822 RFC0823 DARPA Internet gateway R.M. Hinden A. Sheltzer September 1982 ASCII HTML 45 GGP

This RFC is a status report on the Internet Gateway developed by BBN. It describes the Internet Gateway as of September 1982. This memo presents detailed descriptions of message formats and gateway procedures, however, this is not an implementation specification, and such details are subject to change.

 IEN109 IEN30 HISTORIC HISTORIC Legacy http://www.rfc-editor.org/errata_search.php?rfc=823 10.17487/RFC0823 RFC0824 CRONUS Virtual Local Network W.I. MacGregor D.C. Tappan August 1982 ASCII HTML 41

The purpose of this note is to describe the CRONUS Virtual Local Network, especially the addressing related features. These features include a method for mapping between Internet Addresses and Local Network addresses. This is a topic of current concern in the ARPA Internet community. This note is intended to stimulate discussion. This is not a specification of an Internet Standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0824 RFC0825 Request for comments on Requests For Comments J. Postel November 1982 ASCII HTML 2

This RFC is intended to clarify the status of RFCs and to provide some guidance for the authors of RFCs in the future. It is in a sense a specification for RFCs.

 RFC1111 RFC1543 RFC2223 UNKNOWN UNKNOWN Legacy 10.17487/RFC0825 RFC0826 An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware D. Plummer November 1982 ASCII HTML 10 ARP

The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an Internet Standard.

 RFC5227 RFC5494 STD0037 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0826 RFC0827 Exterior Gateway Protocol (EGP) E.C. Rosen October 1982 ASCII HTML 46

This RFC is proposed to establish a standard for Gateway to Gateway procedures that allow the Gateways to be mutually suspicious. This document is a DRAFT for that standard. Your comments are strongly encouraged.

 RFC0904 UNKNOWN UNKNOWN Legacy 10.17487/RFC0827 RFC0828 Data communications: IFIP's international "network" of experts K. Owen August 1982 ASCII HTML 11

This RFC is distributed to inform the ARPA Internet community of the activities of the IFIP technical committee on Data Communications, and to encourage participation in those activities.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0828 RFC0829 Packet satellite technology reference sources V.G. Cerf November 1982 ASCII HTML 5

This RFC describes briefly the packet satellite technology developed by the Defense Advanced Research Projects Agency and several other participating organizations in the U.K. and Norway and provides a bibliography of relevant papers for researchers interested in experimental and operational experience with this dynamic satellite-sharing technique.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0829 RFC0830 Distributed system for Internet name service Z. Su October 1982 ASCII HTML 18

This RFC proposes a distributed name service for DARPA Internet. Its purpose is to focus discussion on the subject. It is hoped that a general consensus will emerge leading eventually to the adoption of standards.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0830 RFC0831 Backup access to the European side of SATNET R.T. Braden December 1982 ASCII HTML 6

The purpose of this RFC is to focus discussion on a particular Internet problem: a backup path for software maintenance of the European sector of the Internet, for use when SATNET is partitioned. We propose a mechanism, based upon the Source Routing option of IP, to reach European Internet sites via the VAN Gateway and UCL. This proposal is not intended as a standard at this time.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0831 RFC0832 Who talks TCP? D. Smallberg December 1982 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 7-Dec-82.

 RFC0833 UNKNOWN UNKNOWN Legacy 10.17487/RFC0832 RFC0833 Who talks TCP? D. Smallberg December 1982 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 14-Dec-82.

 RFC0832 RFC0834 UNKNOWN UNKNOWN Legacy 10.17487/RFC0833 RFC0834 Who talks TCP? D. Smallberg December 1982 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 22-Dec-82.

 RFC0833 RFC0835 UNKNOWN UNKNOWN Legacy 10.17487/RFC0834 RFC0835 Who talks TCP? D. Smallberg December 1982 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 28-Dec-82 through 5-Jan-83.

 RFC0834 RFC0836 UNKNOWN UNKNOWN Legacy 10.17487/RFC0835 RFC0836 Who talks TCP? D. Smallberg January 1983 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 20-Dec-82. The tests were run on 4-Jan-83 through 5-Jan-83.

 RFC0835 RFC0837 UNKNOWN UNKNOWN Legacy 10.17487/RFC0836 RFC0837 Who talks TCP? D. Smallberg January 1983 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 11-Jan-83.

 RFC0836 RFC0838 UNKNOWN UNKNOWN Legacy 10.17487/RFC0837 RFC0838 Who talks TCP? D. Smallberg January 1983 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 18-Jan-83.

 RFC0837 RFC0839 UNKNOWN UNKNOWN Legacy 10.17487/RFC0838 RFC0839 Who talks TCP? D. Smallberg January 1983 ASCII HTML 14

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 25-Jan-83.

 RFC0838 RFC0842 UNKNOWN UNKNOWN Legacy 10.17487/RFC0839 RFC0840 Official protocols J. Postel April 1983 ASCII HTML 23

This RFC has been revised, see RFC 880.

 RFC0880 HISTORIC UNKNOWN Legacy 10.17487/RFC0840 RFC0841 Specification for message format for Computer Based Message Systems National Bureau of Standards January 1983 ASCII HTML 117

This RFC is FIPS 98. The purpose of distributing this document as an RFC is to make it easily accessible to the ARPA research community. This RFC does not specify a standard for the ARPA Internet. Obsoletes RFC 806.

 RFC0806 UNKNOWN UNKNOWN Legacy 10.17487/RFC0841 RFC0842 Who talks TCP? - survey of 1 February 83 D. Smallberg February 1983 ASCII HTML 12

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 28-Jan-83. The tests were run on 1-Feb-83 and on 2-Feb-83 ISI-VAXA.ARPA.

 RFC0839 RFC0843 UNKNOWN UNKNOWN Legacy 10.17487/RFC0842 RFC0843 Who talks TCP? - survey of 8 February 83 D. Smallberg February 1983 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 8-Feb-83 and on 9-Feb-83 from ISI-VAXA.ARPA.

 RFC0842 RFC0845 RFC0844 UNKNOWN UNKNOWN Legacy 10.17487/RFC0843 RFC0844 Who talks ICMP, too? - Survey of 18 February 1983 R. Clements February 1983 ASCII HTML 5

This survey determines how many hosts are able to respond to TELENET connections from a user at a class C site. This requires, in addition to IP and TCP, participation in gateway routing via ICMP and handling of Class C addresses. The list of hosts was taken from RFC 843, extracting only those hosts which are listed there as accepting TELNET connection. The tests were run on 18-Feb-83.

 RFC0843 UNKNOWN UNKNOWN Legacy 10.17487/RFC0844 RFC0845 Who talks TCP? - survey of 15 February 1983 D. Smallberg February 1983 ASCII HTML 14

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 15-Feb-83 from ISI-VAXA.ARPA.

 RFC0843 RFC0846 UNKNOWN UNKNOWN Legacy 10.17487/RFC0845 RFC0846 Who talks TCP? - survey of 22 February 1983 D. Smallberg February 1983 ASCII HTML 14

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 18-Feb-83. The tests were run on 22-Feb-83 from ISI-VAXA.ARPA.

 RFC0845 RFC0847 UNKNOWN UNKNOWN Legacy 10.17487/RFC0846 RFC0847 Summary of Smallberg surveys A. Westine D. Smallberg J. Postel February 1983 ASCII HTML 2

This is a summary of the surveys of Telnet, FTP and Mail (SMTP) servers conducted by David Smallberg in December 1982, January and February 1983 as reported in RFC 832-843, 845-846. This memo extracts the number of hosts that accepted the connection to their server for each of Telnet, FTP, and SMTP, and compares it to the total host in the Internet (not counting TACs or ECHOS).

 RFC0846 UNKNOWN UNKNOWN Legacy 10.17487/RFC0847 RFC0848 Who provides the "little" TCP services? D. Smallberg March 1983 ASCII HTML 5

This RFC lists those hosts which provide any of these "little" TCP services: The list of hosts were taken from the NIC hostname table of 24-Feb-83. The tests were run on February 23 and 24, and March 3 and 5 from ISI-VAXA.ARPA.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0848 RFC0849 Suggestions for improved host table distribution M.R. Crispin May 1983 ASCII HTML 2

This RFC actually is a request for comments. The issue dealt with is that of a naming registry update procedure, both as exists currently and what could exist in the future. None of the proposed solutions are intended as standards at this time; rather it is hoped that a general consensus will emerge as the appropriate solution, leaving eventually to the adoption of standards.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0849 RFC0850 Standard for interchange of USENET messages M.R. Horton June 1983 ASCII HTML 17

This memo is distributed as an RFC only to make this information easily accessible to researchers in the ARPA community. It does not specify an Internet standard. This RFC defines the standard format for interchange of Network News articles among USENET sites. It describes the format for articles themselves, and gives partial standards for transmission of news. The news transmission is not entirely standardized in order to give a good deal of flexibility to the individual hosts to choose transmission hardware and software, whether to batch news and so on.

 RFC1036 UNKNOWN UNKNOWN Legacy 10.17487/RFC0850 RFC0851 ARPANET 1822L Host Access Protocol A.G. Malis April 1983 ASCII HTML 47

This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. 1822L allows ARPANET hosts to use logical names as well as 1822's physical port locations to address each other. This RFC is also being presented as a solicitation of comments on 1822L, especially from host network software implementers and maintainers. Obsoletes RFC 802.

 RFC0802 RFC0878 UNKNOWN UNKNOWN Legacy 10.17487/RFC0851 RFC0852 ARPANET short blocking feature A.G. Malis April 1983 ASCII HTML 13

This RFC specifies the ARPANET Short Blocking Feature, which will allow ARPANET hosts to optionally shorten the IMP's host blocking timer. This Feature is a replacement of the ARPANET non-blocking host interface, which was never implemented, and will be available to hosts using either the 1822 or 1822L Host Access Protocol. This RFC is also being presented as a solicitation of comments on the Short Blocking Feature, especially from host network software implementers and maintainers.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0852 RFC0853 RFC0854 Telnet Protocol Specification J. Postel J.K. Reynolds May 1983 ASCII HTML 15 TELNET

This is the specification of the Telnet protocol used for remote terminal access in the ARPA Internet. The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication ("linking") and process-process communication (distributed computation). This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 18639.

 RFC0764 RFC5198 STD0008 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=854 10.17487/RFC0854 RFC0855 Telnet Option Specifications J. Postel J.K. Reynolds May 1983 ASCII HTML 3 TELNET

This memo specifies the general form for Telnet options and the directions for their specification. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651, NIC 18640.

 NIC18640 STD0008 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0855 RFC0856 Telnet Binary Transmission J. Postel J. Reynolds May 1983 ASCII HTML 4 TOPT-BIN

This Telnet Option enables a binary data mode between the Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15389.

 NIC15389 STD0027 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0856 RFC0857 Telnet Echo Option J. Postel J. Reynolds May 1983 ASCII HTML 5 TOPT-ECHO

This Telnet Option enables remote echoing by the other Telnet module. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15390.

 NIC15390 STD0028 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0857 RFC0858 Telnet Suppress Go Ahead Option J. Postel J. Reynolds May 1983 ASCII HTML 2 TOPT-SUPP

This Telnet Option disables the exchange of go-ahead signals between the Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15392.

 NIC15392 STD0029 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0858 RFC0859 Telnet Status Option J. Postel J. Reynolds May 1983 ASCII HTML 3 TOPT-STAT

This Telnet Option provides a way to determine the other Telnet module's view of the status of options. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651 (NIC 31154).

 RFC0651 STD0030 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0859 RFC0860 Telnet Timing Mark Option J. Postel J. Reynolds May 1983 ASCII HTML 4 TOPT-TIM

This Telnet Option provides a way to check the roundtrip path between two Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 16238.

 NIC16238 STD0031 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0860 RFC0861 Telnet Extended Options: List Option J. Postel J. Reynolds May 1983 ASCII HTML 2 TOPT-EXTOP

This Telnet Option provides a mechanism for extending the set of possible options. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 16239.

 NIC16239 STD0032 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0861 RFC0862 Echo Protocol J. Postel May 1983 ASCII HTML 1 ECHO

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Echo Protocol are expected to adopt and implement this standard. The Echo service simply sends back to the originating source any data it receives.

 STD0020 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0862 RFC0863 Discard Protocol J. Postel May 1983 ASCII HTML 1 DISCARD

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Discard Protocol are expected to adopt and implement this standard. The Discard service simply throws away any data it receives.

 STD0021 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0863 RFC0864 Character Generator Protocol J. Postel May 1983 ASCII HTML 3 CHARGEN

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Character Generator Protocol are expected to adopt and implement this standard. The Character Generator service simply sends data without regard to the input.

 STD0022 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=864 10.17487/RFC0864 RFC0865 Quote of the Day Protocol J. Postel May 1983 ASCII HTML 1 QUOTE

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Quote of the Day Protocol are expected to adopt and implement this standard. The Quote of the Day service simply sends a short message without regard to the input.

 STD0023 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=865 10.17487/RFC0865 RFC0866 Active users J. Postel May 1983 ASCII HTML 1 USERS

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement an Active Users Protocol are expected to adopt and implement this standard. The Active Users service simply sends a list of the currently active users on the host without regard to the input.

 STD0024 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0866 RFC0867 Daytime Protocol J. Postel May 1983 ASCII HTML 2 DAYTIME

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Daytime Protocol are expected to adopt and implement this standard. The Daytime service simply sends the current date and time as a character string without regard to the input.

 STD0025 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0867 RFC0868 Time Protocol J. Postel K. Harrenstien May 1983 ASCII HTML 2 TIME

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Time Protocol are expected to adopt and implement this standard. This protocol provides a site-independent, machine readable date and time. The Time service sends back to the originating source the time in seconds since midnight on January first 1900.

 STD0026 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=868 10.17487/RFC0868 RFC0869 Host Monitoring Protocol R. Hinden December 1983 ASCII HTML 72 HMP

This RFC specifies the Host Monitoring Protocol used to collect information from various types of hosts in the Internet. Designers of Internet communications software are encouraged to consider this protocol as a means of monitoring the behavior of their creations.

 HISTORIC HISTORIC Legacy 10.17487/RFC0869 RFC0870 Assigned numbers J.K. Reynolds J. Postel October 1983 ASCII HTML 26

This RFC documents the list of numbers assigned for networks, protocols, etc. Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755, 750, 739, 604.

 RFC0820 RFC0900 HISTORIC UNKNOWN Legacy 10.17487/RFC0870 RFC0871 Perspective on the ARPANET reference model M.A. Padlipsky September 1982 ASCII HTML 29

This RFC is primarily intended as a perspective on the ARM and points out some of the differences between the ARM and the ISORM which were expressed by members in NWG general meetings, NWG protocol design committee meetings, the ARPA Internet Working Group, and private conversations over the intervening years. Originally published as M82-47 by the MITRE Corporation, Bedford, Massachusetts.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0871 RFC0872 TCP-on-a-LAN M.A. Padlipsky September 1982 ASCII HTML 10 TCP LAN

This memo attacks the notion that TCP cannot be appropriate for use on a Local Area Network. Originally published as M82-48 by the MITRE Corporation, Bedford Massachusetts.

 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0872 RFC0873 Illusion of vendor support M.A. Padlipsky September 1982 ASCII HTML 12

This memo takes issue with the claim that international standards in computer protocols presently provide a basis for low cost vendor supported protocol implementations. Originally published as M82-49 by the MITRE Corporation, Bedford, Massachusetts.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0873 RFC0874 Critique of X.25 M.A. Padlipsky September 1982 ASCII HTML 17

This RFC is an analysis of X.25 pointing out some problems in the conceptual model, particularly the conflict between the interface aspects and the end-to-end aspects. The memo also touches on security, and implementation issues. Originally published as M82-50 by the MITRE Corporation, Bedford, Massachusetts.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0874 RFC0875 Gateways, architectures, and heffalumps M.A. Padlipsky September 1982 ASCII HTML 10

This RFC is a discussion about the role of gateways in an internetwork, especially the problems of translating or mapping protocols between different protocol suites. The discussion notes possible functionality mis-matches, undesirable routing "singularity points", flow control issues, and high cost of translating gateways. Originally published as M82-51 by the MITRE Corporation, Bedford, Massachusetts.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0875 RFC0876 Survey of SMTP implementations D. Smallberg September 1983 ASCII HTML 13

This RFC is a survey of implementation status. It does not specify an official protocol, but rather notes the status of implementation of aspects of a protocol. It is expected that the status of the hosts reported on will change. This information must be treated as a snapshot of the state of these implemetations.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0876 RFC0877 Standard for the transmission of IP datagrams over public data networks J.T. Korb September 1983 ASCII HTML 2

This RFC specifies a standard adopted by CSNET, the VAN gateway, and other organizations for the transmission of IP datagrams over the X.25-based public data networks.

 RFC1356 UNKNOWN UNKNOWN Legacy 10.17487/RFC0877 RFC0878 ARPANET 1822L Host Access Protocol A.G. Malis December 1983 ASCII HTML 51

This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. The 1822L procedure allows ARPANET hosts to use logical identifiers as well as 1822 physical interface identifiers to address each other.

 RFC0851 UNKNOWN UNKNOWN Legacy 10.17487/RFC0878 RFC0879 The TCP Maximum Segment Size and Related Topics J. Postel November 1983 ASCII HTML 11

This RFC discusses the TCP Maximum Segment Size Option and related topics. The purposes is to clarify some aspects of TCP and its interaction with IP. This memo is a clarification to the TCP specification, and contains information that may be considered as "advice to implementers".

 RFC7805 RFC9293 RFC6691 HISTORIC UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=879 10.17487/RFC0879 RFC0880 Official protocols J.K. Reynolds J. Postel October 1983 ASCII HTML 26

This RFC identifies the documents specifying the official protocols used in the ARPA Internet. Annotations identify any revisions or changes planned. Obsoletes RFC 840.

 RFC0840 RFC0901 HISTORIC UNKNOWN Legacy 10.17487/RFC0880 RFC0881 Domain names plan and schedule J. Postel November 1983 ASCII HTML 10

This RFC outlines a plan and schedule for the implementation of domain style names throughout the DDN/ARPA Internet community. The introduction of domain style names will impact all hosts on the DDN/ARPA Internet.

 RFC0897 UNKNOWN UNKNOWN Legacy 10.17487/RFC0881 RFC0882 Domain names: Concepts and facilities P. Mockapetris November 1983 ASCII HTML 31

This RFC introduces domain style names, their use for ARPA Internet mail and host address support, and the protocol and servers used to implement domain name facilities.

 RFC1034 RFC1035 RFC0973 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=882 10.17487/RFC0882 RFC0883 Domain names: Implementation specification P. Mockapetris November 1983 ASCII HTML 74

This RFC discusses the implementation of domain name servers and resolvers, specifies the format of transactions, and discusses the use of domain names in the context of existing mail systems and other network software.

 RFC1034 RFC1035 RFC0973 UNKNOWN UNKNOWN Legacy 10.17487/RFC0883 RFC0884 Telnet terminal type option M. Solomon E. Wimmers December 1983 ASCII HTML 5

This RFC specifies a standard for the ARPA Internet community. It specifies a method for exchanging terminal type information in the Telnet protocol.

 RFC0930 UNKNOWN UNKNOWN Legacy 10.17487/RFC0884 RFC0885 Telnet end of record option J. Postel December 1983 ASCII HTML 2 TOPT-EOR

This RFC specifies a standard for the ARPA Internet community. It specifies a method for marking the end of records in data transmitted on Telnet connections.

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0885 RFC0886 Proposed standard for message header munging M.T. Rose December 1983 ASCII HTML 16

This RFC specifies a draft standard for the ARPA Internet community. It describes the rules to be used when transforming mail from the conventions of one message system to those of another message system. In particular, the treatment of header fields, and recipient addresses is specified.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0886 RFC0887 Resource Location Protocol M. Accetta December 1983 ASCII HTML 16 RLP

This RFC specifies a draft standard for the ARPA Internet community. It describes a resource location protocol for use in the ARPA Internet. It is most useful on networks employing technologies which support some method of broadcast addressing, however it may also be used on other types of networks. For maximum benefit, all hosts which provide significant resources or services to other hosts on the Internet should implement this protocol. Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the Internet.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0887 RFC0888 "STUB" Exterior Gateway Protocol L. Seamonson E.C. Rosen January 1984 ASCII HTML 39

This RFC describes the Exterior Gateway Protocol used to connect Stub Gateways to an Autonomous System of core Gateways. This document specifies the working protocol, and defines an ARPA official protocol. All implementers of Gateways should carefully review this document.

 RFC0904 UNKNOWN UNKNOWN Legacy 10.17487/RFC0888 RFC0889 Internet Delay Experiments D.L. Mills December 1983 ASCII HTML 12

This memo reports on some measurements of round-trip times in the Internet and suggests some possible improvements to the TCP retransmission timeout calculation. This memo is both a status report on the Internet and advice to TCP implementers.

 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0889 RFC0890 Exterior Gateway Protocol implementation schedule J. Postel February 1984 ASCII HTML 3 EGP

This memo is a policy statement on the implementation of the Exterior Gateway Protocol in the Internet. This is an official policy statement of ICCB and DARPA. After 1-Aug-84 there shall be no dumb gateways in the Internet. Every gateway must be a member of some autonomous system. Some gateway of each autonomous system must exchange routing information with some gateway of the core autonomous system using the Exterior Gateway Protocol.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0890 RFC0891 DCN Local-Network Protocols D.L. Mills December 1983 ASCII HTML 26 IP-DC

This RFC provides a description of the DCN protocols for maintaining connectivity, routing, and clock information in a local network. These procedures may be of interest to the designers and implementers of other local networks.

 STD0044 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0891 RFC0892 ISO Transport Protocol specification International Organization for Standardization December 1983 ASCII HTML 82

This is a draft version of the transport protocol being standardized by the ISO. This version also appeared in the ACM SIGCOMM Computer Communication Review (V.12, N.3-4) July-October 1982. This version is now out of date.

 RFC0905 UNKNOWN UNKNOWN Legacy 10.17487/RFC0892 RFC0893 Trailer encapsulations S. Leffler M.J. Karels April 1984 ASCII HTML 6

This RFC discusses the motivation for use of "trailer encapsulations" on local-area networks and describes the implementation of such an encapsulation on various media. This document is for information only. This is NOT an official protocol for the ARPA Internet community.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0893 RFC0894 A Standard for the Transmission of IP Datagrams over Ethernet Networks C. Hornig April 1984 ASCII HTML 3 IP-E

This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Ethernet. This RFC specifies a standard protocol for the ARPA-Internet community.

 STD0041 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=894 10.17487/RFC0894 RFC0895 Standard for the transmission of IP datagrams over experimental Ethernet networks J. Postel April 1984 ASCII HTML 3 IP-EE

This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Experimental Ethernet. This RFC specifies a standard protocol for the ARPA Internet community.

 STD0042 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0895 RFC0896 Congestion Control in IP/TCP Internetworks J. Nagle January 1984 ASCII HTML 9

This memo discusses some aspects of congestion control in IP/TCP Internetworks. It is intended to stimulate thought and further discussion of this topic. While some specific suggestions are made for improved congestion control implementation, this memo does not specify any standards.

 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0896 RFC0897 Domain name system implementation schedule J. Postel February 1984 ASCII HTML 8

This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is a partial update of RFC 881. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The names of hosts will be changed to domain style names. Hosts will begin to use domain style names on 14-Mar-84, and the use of old style names will be completely phased out before 2-May-84. This applies to both the ARPA research hosts and the DDN operational hosts. This is an official policy statement of the ICCB and the DARPA.

 RFC0881 RFC0921 UNKNOWN UNKNOWN Legacy 10.17487/RFC0897 RFC0898 Gateway special interest group meeting notes R.M. Hinden J. Postel M. Muuss J.K. Reynolds April 1984 ASCII HTML 24

This memo is a report on the Gateway Special Interest Group Meeting that was held at ISI on 28 and 29 February 1984. Robert Hinden of BBNCC chaired, and Jon Postel of ISI hosted the meeting. Approximately 35 gateway designers and implementors attended. These notes are based on the recollections of Jon Postel and Mike Muuss. Under each topic area are Jon Postel's brief notes, and additional details from Mike Muuss. This memo is a report on a meeting. No conclusions, decisions, or policy statements are documented in this note.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0898 RFC0899 Request For Comments summary notes: 800-899 J. Postel A. Westine May 1984 ASCII HTML 18 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0899 RFC0900 Assigned Numbers J.K. Reynolds J. Postel June 1984 ASCII HTML 43

This RFC specifies parameter values use in the Internet family of protocols, such as network numbers, well known ports, protocol types, and version numbers. This memo is an official status report on the protocol parameters used in the Internet protocol system. See RFC-990 and 997.

 RFC0870 RFC0923 HISTORIC UNKNOWN Legacy 10.17487/RFC0900 RFC0901 Official ARPA-Internet protocols J.K. Reynolds J. Postel June 1984 ASCII HTML 28

This RFC identifies the documents specifying the official protocols used in the ARPA-Internet. Annotations identify any revisions or changes planned. This memo is an official status report on the protocols used in the DARPA research community. See RFC-991.

 RFC0880 RFC0924 UNKNOWN UNKNOWN Legacy 10.17487/RFC0901 RFC0902 ARPA Internet Protocol policy J.K. Reynolds J. Postel July 1984 ASCII HTML 5

The purpose of this memo is to explain how protocol standards are adopted for the ARPA-Internet and the DARPA research community. There are three important aspects to be discussed: the process, the authority, and the complex relationship between the DARPA community and the DDN community. This memo is a policy statement on how protocols become official standards for the ARPA-Internet and the DARPA research community. This is an official policy statement of the ICCB and the DARPA.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0902 RFC0903 A Reverse Address Resolution Protocol R. Finlayson T. Mann J.C. Mogul M. Theimer June 1984 ASCII HTML 4 RARP

This RFC suggests a method for workstations to dynamically find their protocol address (e.g., their Internet Address), when they know only their hardware address (e.g., their attached physical network address). This RFC specifies a proposed protocol for the ARPA Internet community, and requests discussion and suggestions for improvements.

 STD0038 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0903 RFC0904 Exterior Gateway Protocol formal specification D.L. Mills April 1984 ASCII HTML 30 EGP

RFC-904 is the specification of the Exterior Gateway Protocol (EGP). This memo updates portions of RFC-888 and RFC-827. This RFC specifies an official protocol of the DARPA community for use between gateways of different autonomous systems in the ARPA-Internet.

 RFC0827 RFC0888 HISTORIC HISTORIC Legacy 10.17487/RFC0904 RFC0905 ISO Transport Protocol specification ISO DP 8073 ISO April 1984 ASCII HTML 164

This is the current specification of the ISO Transport Protocol. This document is the text of ISO/TC97/SC16/N1576 as corrected by ISO/TC97/SC16/N1695. This is the specification currently being voted on in ISO as a Draft International Standard (DIS). This document is distributed as an RFC for your information only, it does not specify a standard for the ARPA-Internet or DARPA research community. Our thanks to Alex McKenzie of BBN for making this online version available. Please note the size of this document, the file contains 258,729 characters.

 RFC0892 UNKNOWN UNKNOWN Legacy 10.17487/RFC0905 RFC0906 Bootstrap loading using TFTP R. Finlayson June 1984 ASCII HTML 4

It is often convenient to be able to bootstrap a computer system from a communications network. This RFC proposes the use of the IP TFTP protocol for bootstrap loading in this case.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0906 RFC0907 Host Access Protocol specification Bolt Beranek and Newman Laboratories July 1984 ASCII HTML 75 IP-WB

This document specifies the Host Access Protocol (HAP). Although HAP was originally designed as the network-access level protocol for the DARPA/DCA sponsored Wideband Packet Satellite Network, it is intended that it evolve into a standard interface SATNET and TACNET (aka MATNET) as well as the Wideband Network. HAP is an experimental protocol, and will undergo further revision as new capabilities are added and/or different satellite networks are suported. Implementations of HAP should be performed in coordination with satellite network development and operations personnel.

 RFC1221 STD0040 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0907 RFC0908 Reliable Data Protocol D. Velten R.M. Hinden J. Sax July 1984 ASCII HTML 62 RDP

The Reliable Data Protocol (RDP) is designed to provide a reliable data transport service for packet-based applications. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.

 RFC1151 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0908 RFC0909 Loader Debugger Protocol C. Welles W. Milliken July 1984 ASCII HTML 135 LDP

The Loader Debugger Protocol (LDP) is an application layer protocol for loading, dumping, and debugging target machines from hosts in a network environment. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0909 RFC0910 Multimedia mail meeting notes H.C. Forsdick August 1984 ASCII HTML 11

This memo is a report on a meeting about the experimental multimedia mail system (and in a sense a status report on that experiment). The meeting was held at Bolt Beranek and Newman on 23-24 July 1984 to discuss recent progress by groups who are building multimedia mail systems and to discuss a variety of issues related to the further development of multimedia systems. Representatives were present from BBN, ISI, SRI and Linkabit.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0910 RFC0911 EGP Gateway under Berkeley UNIX 4.2 P. Kirton August 1984 ASCII HTML 23

This memo describes an implementation of the Exterior Gateway Protocol (EGP) (in that sense it is a status report). The memo also discusses some possible extentions and some design issues (in that sense it is an invitation for further discussion).

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0911 RFC0912 Authentication service M. St. Johns September 1984 ASCII HTML 3

This memo describes a proposed authentication protocol for verifying the identity of a user of a TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. Suggested uses include automatic identification and verification of a user during an FTP session, additional verification of a TAC dial up user, and access verification for a generalized network file server.

 RFC0931 UNKNOWN UNKNOWN Legacy 10.17487/RFC0912 RFC0913 Simple File Transfer Protocol M. Lottor September 1984 ASCII HTML 15 SFTP FTP

This memo describes a proposed Simple File Transfer Protocol (SFTP). It fills the need of people wanting a protocol that is more useful than TFTP but easier to implement (and less powerful) than FTP. SFTP supports user access control, file transfers, directory listing, directory changing, file renaming and deleting. Discussion of this proposal is encouraged, and suggestions for improvements may be sent to the author.

 HISTORIC HISTORIC Legacy 10.17487/RFC0913 RFC0914 Thinwire protocol for connecting personal computers to the Internet D.J. Farber G. Delp T.M. Conte September 1984 ASCII HTML 22 THINWIRE

This RFC focuses discussion on the particular problems in the ARPA-Internet of low speed network interconnection with personal computers, and possible methods of solution. None of the proposed solutions in this document are intended as standards for the ARPA-Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to the problems, leading eventually to the adoption of standards.

 HISTORIC HISTORIC Legacy 10.17487/RFC0914 RFC0915 Network mail path service M.A. Elvy R. Nedved December 1984 ASCII HTML 11

This RFC proposed a new service for the ARPA-Internet community and requests discussion and suggestions for improvements. The network mail path service fills the current need of people to determine mailbox addresses for hosts that are not part of the ARPA-Internet but can be reached by one or more relay hosts that have Unix to Unix Copy (UUCP) mail, CSNET mail, MAILNET mail, BITNET mail, etc. Anyone can use the service if they have TCP/TELENET to one of the hosts with a mail path server.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0915 RFC0916 Reliable Asynchronous Transfer Protocol (RATP) G.G. Finn October 1984 ASCII HTML 54 RATP

This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This paper proposes and specifies a protocol which allows two programs to reliably communicate over a communication link. It ensures that the data entering one end of the link if received arrives at the other end intact and unaltered. The protocol, named RATP, is designed to operate over a full duplex point-to-point connection. It contains some features which tailor it to the RS-232 links now in common use.

 HISTORIC HISTORIC Legacy 10.17487/RFC0916 RFC0917 Internet subnets J.C. Mogul October 1984 ASCII HTML 22

This memo discusses subnets and proposes procedures for the use of subnets, including approaches to solving the problems that arise, particularly that of routing. A subnet of an Internet network is a logically visible sub-section of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=917 10.17487/RFC0917 RFC0918 Post Office Protocol J.K. Reynolds October 1984 ASCII HTML 5

This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. The intent of the Post Office Protocol (POP) is to allow a user's workstation to access mail from a mailbox server. It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP). This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. The status of this protocol is experimental, and this protocol is dependent upon TCP.

 RFC0937 UNKNOWN UNKNOWN Legacy 10.17487/RFC0918 RFC0919 Broadcasting Internet Datagrams J.C. Mogul October 1984 ASCII HTML 8

This RFC proposes simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0919 RFC0920 Domain requirements J. Postel J.K. Reynolds October 1984 ASCII HTML 14

This memo states the requirements on establishing a Domain, and introduces the limited set of top level domains. This memo is a policy statement on the requirements of establishing a new domain in the ARPA-Internet and the DARPA research community. This is an official policy statement of the IAB and the DARPA.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0920 RFC0921 Domain name system implementation schedule - revised J. Postel October 1984 ASCII HTML 13

This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is an update of RFC-881, and RFC-897. This is an official policy statement of the IAB and the DARPA. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The explanation of how this system works is to be found in the references.

 RFC0897 UNKNOWN UNKNOWN Legacy 10.17487/RFC0921 RFC0922 Broadcasting Internet datagrams in the presence of subnets J.C. Mogul October 1984 ASCII HTML 12

We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0922 RFC0923 Assigned numbers J.K. Reynolds J. Postel October 1984 ASCII HTML 47

This RFC documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers obsoletes RFC-900 and earlier editions. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990, and 997.

 RFC0900 RFC0943 HISTORIC UNKNOWN Legacy 10.17487/RFC0923 RFC0924 Official ARPA-Internet protocols for connecting personal computers to the Internet J.K. Reynolds J. Postel October 1984 ASCII HTML 35

This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-900 and earlier editions. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.

 RFC0901 RFC0944 UNKNOWN UNKNOWN Legacy 10.17487/RFC0924 RFC0925 Multi-LAN address resolution J. Postel October 1984 ASCII HTML 15

The problem of treating a set of local area networks (LANs) as one Internet network has generated some interest and concern. It is inappropriate to give each LAN within an site a distinct Internet network number. It is desirable to hide the details of the interconnections between the LANs within an site from people, gateways, and hosts outside the site. The question arises on how to best do this, and even how to do it at all. In RFC-917 Jeffery Mogul makes a case for the use of "explicit subnets" in a multi-LAN environment. The explicit subnet scheme is a call to recursively apply the mechanisms the Internet uses to manage networks to the problem of managing LANs within one network. In this note I urge another approach: the use of "transparent subnets" supported by a multi-LAN extension of the Address Resolution Protocol. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0925 RFC0926 Protocol for providing the connectionless mode network services International Organization for Standardization December 1984 ASCII HTML 107

This note is the draft ISO protocol roughly similar to the DOD Internet Protocol. This document has been prepared by retyping the text of ISO DIS 8473 of May 1984, which is currently undergoing voting within ISO as a Draft International Standard (DIS). This document is distributred as an RFC for information only. It does not specify a standard for the ARPA-Internet.

 RFC0994 UNKNOWN UNKNOWN Legacy 10.17487/RFC0926 RFC0927 TACACS user identification Telnet option B.A. Anderson December 1984 ASCII HTML 4 TOPT-TACACS

The following is the description of a TELNET option designed to facilitate double login avoidance. It is intended primarily for TAC connections to target hosts on behalf of TAC users, but it can be used between any two consenting hosts. For example, all hosts at one site (e.g., BBN) can use this option to avoid double login when TELNETing to one another. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0927 RFC0928 Introduction to proposed DoD standard H-FP M.A. Padlipsky December 1984 ASCII HTML 21

The broad outline of the Host-Front End Protocol introduced here and described in RFC-929 is the result of the deliberations of a number of experienced H-FP designers, who sat as a committee of the DoD Protocol Standards Technical Panel. It is the intent of the designers that the protocol be subjected to multiple test implementations and probable iteration before being agreed upon as any sort of "standard". Therefore, the first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0928 RFC0929 Proposed Host-Front End Protocol J. Lilienkamp R. Mandell M.A. Padlipsky December 1984 ASCII HTML 56 HFEP

The Host-Front End Protocol introduced in RFC-928 is described in detail in this memo. The first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 HISTORIC HISTORIC Legacy 10.17487/RFC0929 RFC0930 Telnet terminal type option M. Solomon E. Wimmers January 1985 ASCII HTML 4

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC-884. The only change is to specify that the TERMINAL-TYPE IS sub-negotiation should be sent only in response to the TERMINAL-TYPE SEND sub-negotiation.

 RFC0884 RFC1091 UNKNOWN UNKNOWN Legacy 10.17487/RFC0930 RFC0931 Authentication server M. St. Johns January 1985 ASCII HTML 5

This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is the second draft of this proposal (superseding RFC-912) and incorporates a more formal description of the syntax for the request and response dialog, as well as a change to specify the type of user identification returned.

 RFC0912 RFC1413 UNKNOWN UNKNOWN Legacy 10.17487/RFC0931 RFC0932 Subnetwork addressing scheme D.D. Clark January 1985 ASCII HTML 4

This RFC proposes an alternative addressing scheme for subnets which, in most cases, requires no modification to host software whatsoever. The drawbacks of this scheme are that the total number of subnets in any one network are limited, and that modification is required to all gateways.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0932 RFC0933 Output marking Telnet option S. Silverman January 1985 ASCII HTML 4 TOPT-OM

This proposed option would allow a Server-Telnet to send a banner to a User-Telnet so that this banner would be displayed on the workstation screen independently of the application software running in the Server-Telnet.

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0933 RFC0934 Proposed standard for message encapsulation M.T. Rose E.A. Stefferud January 1985 ASCII HTML 10

This memo concerns itself with message forwarding. Forwarding can be thought of as encapsulating one or more messages inside another. Although this is useful for transfer of past correspondence to new recipients, without a decapsulation process (which this memo terms "bursting"), the forwarded messages are of little use to the recipients because they can not be distributed, forwarded, replied-to, or otherwise processed as separate individual messages. In order to burst a message it is necessary to know how the component messages were encapsulated in the draft. At present there is no unambiguous standard for interest group digests. This RFC proposes a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0934 RFC0935 Reliable link layer protocols J.G. Robinson January 1985 ASCII HTML 12

This RFC discusses protocols proposed recently in RFCs 914 and 916, and suggests a proposed protocol that could meet the same needs addressed in those memos. The stated need is reliable communication between two programs over a full-duplex, point-to-point communication link, and in particular the RFCs address the need for such communication over an asynchronous link at relatively low speeds. The suggested protocol uses the methods of existing national and international data link layer standards. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0935 RFC0936 Another Internet subnet addressing scheme M.J. Karels February 1985 ASCII HTML 4

There have been several proposals for schemes to allow the use of a single Internet network number to refer to a collection of physical networks under common administration which are reachable from the rest of the Internet by a common route. Such schemes allow a simplified view of an otherwise complicated topology from hosts and gateways outside of this collection. They allow the complexity of the number and type of these networks, and routing to them, to be localized. Additions and changes in configuration thus cause no detectable change, and no interruption of service, due to slow propagation of routing and other information outside of the local environment. These schemes also simplify the administration of the network, as changes do not require allocation of new network numbers for each new cable installed. This proposal discusses an alternative scheme, one that has been in use at the University of California, Berkeley since April 1984. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0936 RFC0937 Post Office Protocol: Version 2 M. Butler J. Postel D. Chase J. Goldberger J.K. Reynolds February 1985 ASCII HTML 24 POP2 Post Office Protocol Version 2

This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. This memo is a revision of RFC-918.

 RFC0918 HISTORIC HISTORIC Legacy 10.17487/RFC0937 RFC0938 Internet Reliable Transaction Protocol functional and interface specification T. Miller February 1985 ASCII HTML 19 IRTP

This RFC is being distributed to members of the DARPA research community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the DARPA community, they may be interesting to a number of researchers and implementors. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0938 RFC0939 Executive summary of the NRC report on transport protocols for Department of Defense data networks National Research Council February 1985 ASCII HTML 20

This RFC reproduces the material from the "front pages" of the National Research Council report resulting from a study of the DOD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4). The point of this RFC is to make the text of the Executive Summary widely available in a timely way. The order of presentation has been altered, and the pagination changed. This RFC is distributed for information only. This RFC does not establish any policy for the DARPA research community or the DDN operational community.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0939 RFC0940 Toward an Internet standard scheme for subnetting Gateway Algorithms and Data Structures Task Force April 1985 ASCII HTML 3

Several sites now contain a complex of local links connected to the Internet via a gateway. The details of the internal connectivity are of little interest to the rest of the Internet. One way of organizing these local complexes of links is to use the same strategy as the Internet uses to organize networks, that is, to declare each link to be an entity (like a network) and to interconnect the links with devices that perform routing functions (like gateways). This general scheme is called subnetting, the individual links are called subnets, and the connecting devices are called subgateways (or bridges, or gateways). This RFC discusses standardizing the protocol used in subnetted environments in the ARPA-Internet.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0940 RFC0941 Addendum to the network service definition covering network layer addressing International Organization for Standardization April 1985 ASCII HTML 34

This Addendum to the Network Service Definition Standard, ISO 8348, defines the abstract syntax and semantics of the Network Address (Network Service Access Point Address). The Network Address defined in this Addendum is the address that appears in the primitives of the connection-mode Network Service as the calling address, called address, and responding address parameters, and in the primitives of the connectionless-mode Network Service as the source address and destination address parameters. This document is distributed as an RFC for information only. It does not specify a standard for the ARPA-Internet.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0941 RFC0942 Transport protocols for Department of Defense data networks National Research Council February 1985 ASCII HTML 88

This RFC reproduces the National Research Council report resulting from a study of the DoD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4).

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0942 RFC0943 Assigned numbers J.K. Reynolds J. Postel April 1985 ASCII HTML 50

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.

 RFC0923 RFC0960 HISTORIC UNKNOWN Legacy 10.17487/RFC0943 RFC0944 Official ARPA-Internet protocols J.K. Reynolds J. Postel April 1985 ASCII HTML 40

This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-924 and earlier editions. This RFC will be updated periodically, and current information can be obtained from Joyce Reynolds. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.

 RFC0924 RFC0961 UNKNOWN UNKNOWN Legacy 10.17487/RFC0944 RFC0945 DoD statement on the NRC report J. Postel May 1985 ASCII HTML 2

In May 1983 the National Research Council (NRC) was asked jointly by DoD and NBS to study the issues and recommend a course of action. The final report of the NRC committee was published in February 1985 (see RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to DCA transmitting the NRC report and requesting specific actions relative to the recommendations of the report. This RFC reproduces a letter from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC3I) to the Director of the Defense Communications Agency (DCA). This letter is distributed for information only.

 RFC1039 UNKNOWN UNKNOWN Legacy 10.17487/RFC0945 RFC0946 Telnet terminal location number option R. Nedved May 1985 ASCII HTML 4 TOPT-TLN

Many systems provide a mechanism for finding out where a user is logged in from usually including information about telephone extension and office occupants names. The information is useful for physically locating people and/or calling them on the phone. In 1982 CMU designed and implemented a terminal location database and modified existing network software to handle a 64-bit number called the Terminal Location Number (or TTYLOC). It now seems appropriate to incorporate this mechanism into the TCP-based network protocol family. The mechanism is not viewed as a replacement for the Terminal Location Telnet Option (SEND-LOCATION) but as a shorthand mechansim for communicating terminal location information between hosts in a localized community. This RFC proposes a new option for Telnet for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0946 RFC0947 Multi-network broadcasting within the Internet K. Lebowitz D. Mankins June 1985 ASCII HTML 5

This RFC describes the extension of a network's broadcast domain to include more than one physical network through the use of a broadcast packet repeater.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0947 RFC0948 Two methods for the transmission of IP datagrams over IEEE 802.3 networks I. Winston June 1985 ASCII HTML 7

This RFC describes two methods of encapsulating Internet Protocol (IP) datagrams on an IEEE 802.3 network. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 RFC1042 UNKNOWN UNKNOWN Legacy 10.17487/RFC0948 RFC0949 FTP unique-named store command M.A. Padlipsky July 1985 ASCII HTML 2

There are various contexts in which it would be desirable to have an FTP command that had the effect of the present STOR but rather than requiring the sender to specify a file name istead caused the resultant file to have a unique name relative to the current directory. This RFC proposes an extension to the File Transfer Protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. See RFC-959.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0949 RFC0950 Internet Standard Subnetting Procedure J.C. Mogul J. Postel August 1985 ASCII HTML 18 Address

This memo discusses the utility of "subnets" of Internet networks, which are logically visible sub-sections of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This memo specifies procedures for the use of subnets. These procedures are for hosts (e.g., workstations). The procedures used in and between subnet gateways are not fully described. Important motivation and background information for a subnetting standard is provided in RFC-940. This RFC specifies a protocol for the ARPA-Internet community. If subnetting is implemented it is strongly recommended that these procedures be followed.

 RFC0792 RFC6918 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0950 RFC0951 Bootstrap Protocol W.J. Croft J. Gilmore September 1985 ASCII HTML 12 BOOTP

This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 RFC1395 RFC1497 RFC1532 RFC1542 RFC5494 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=951 10.17487/RFC0951 RFC0952 DoD Internet host table specification K. Harrenstien M.K. Stahl E.J. Feinler October 1985 ASCII HTML 6

This RFC is the official specification of the format of the Internet Host Table. This edition of the specification includes minor revisions to RFC-810 which brings it up to date.

 RFC0810 RFC1123 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=952 10.17487/RFC0952 RFC0953 Hostname Server K. Harrenstien M.K. Stahl E.J. Feinler October 1985 ASCII HTML 5 HOSTNAME

This RFC is the official specification of the Hostname Server Protocol. This edition of the specification includes minor revisions to RFC-811 which brings it up to date.

 RFC0811 HISTORIC HISTORIC Legacy 10.17487/RFC0953 RFC0954 NICNAME/WHOIS K. Harrenstien M.K. Stahl E.J. Feinler October 1985 ASCII HTML 4 NICNAME

This RFC is the official specification of the NICNAME/WHOIS protocol. This memo describes the protocol and the service. This is an update of RFC-812.

 RFC0812 RFC3912 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC0954 RFC0955 Towards a transport service for transaction processing applications R.T. Braden September 1985 ASCII HTML 10

The DoD Internet protocol suite includes two alternative transport service protocols, TCP and UDP, which provide virtual circuit and datagram service, respectively. These two protocols represent points in the space of possible transport service attributes which are quite "far apart". We want to examine an important class of applications, those which perform what is often called "transaction processing". We will see that the communication needs for these applications fall into the gap "between" TCP and UDP -- neither protocol is very appropriate. This RFC is concerned with the possible design of one or more new protocols for the ARPA-Internet, to support kinds of applications which are not well supported at present. The RFC is intended to spur discussion in the Internet research community towards the development of new protocols and/or concepts, in order to meet these unmet application requirements. It does not represent a standard, nor even a concrete protocol proposal.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0955 RFC0956 Algorithms for synchronizing network clocks D.L. Mills September 1985 ASCII HTML 26

This RFC discussed clock synchronization algorithms for the ARPA-Internet community, and requests discussion and suggestions for improvements. The recent interest within the Internet community in determining accurate time from a set of mutually suspicious network clocks has been prompted by several occasions in which errors were found in usually reliable, accurate clock servers after thunderstorms which disrupted their power supply. To these sources of error should be added those due to malfunctioning hardware, defective software and operator mistakes, as well as random errors in the mechanism used to set and synchronize clocks. This report suggests a stochastic model and algorithms for computing a good estimator from time-offset samples measured between clocks connected via network links. Included in this report are descriptions of certain experiments which give an indication of the effectiveness of the algorithms.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0956 RFC0957 Experiments in network clock synchronization D.L. Mills September 1985 ASCII HTML 27

This RFC discusses some experiments in clock synchronization in the ARPA-Internet community, and requests discussion and suggestions for improvements. One of the services frequently neglected in computer network design is a high-quality, time-of-day clock capable of generating accurate timestamps with small errors compared to one-way network delays. Such a service would be useful for tracing the progress of complex transactions, synchronizing cached data bases, monitoring network performance and isolating problems. In this memo one such clock service design will be described and its performance assessed. This design has been incorporated as an integral part of the network routing and control protocols of the Distributed Computer Network (DCnet) architecture.

 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=957 10.17487/RFC0957 RFC0958 Network Time Protocol (NTP) D.L. Mills September 1985 ASCII HTML 14 NTP time clock synchronization

This document describes the Network Time Protocol (NTP), a protocol for synchronizing a set of network clocks using a set of distributed clients and servers. NTP is built on the User Datagram Protocol (UDP), which provides a connectionless transport mechanism. It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 RFC1059 RFC1119 RFC1305 UNKNOWN UNKNOWN Legacy 10.17487/RFC0958 RFC0959 File Transfer Protocol J. Postel J. Reynolds October 1985 ASCII HTML 69 FTP

This memo is the official specification of the File Transfer Protocol (FTP) for the DARPA Internet community. The primary intent is to clarify and correct the documentation of the FTP specification, not to change the protocol. The following new optional commands are included in this edition of the specification: Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST). Note that this specification is compatible with the previous edition.

 RFC0765 RFC2228 RFC2640 RFC2773 RFC3659 RFC5797 RFC7151 STD0009 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=959 10.17487/RFC0959 RFC0960 Assigned numbers J.K. Reynolds J. Postel December 1985 ASCII HTML 60

This memo documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers updates and obsoletes RFC-943. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.

 RFC0943 RFC0990 HISTORIC UNKNOWN Legacy 10.17487/RFC0960 RFC0961 Official ARPA-Internet protocols J.K. Reynolds J. Postel December 1985 ASCII HTML 38

This memo identifies the documents specifying the official protocols used in the Internet, and comments on any revisions or changes planned. This edition of the Official Protocols updates and obsoletes RFC-944. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.

 RFC0944 RFC0991 UNKNOWN UNKNOWN Legacy 10.17487/RFC0961 RFC0962 TCP-4 prime M.A. Padlipsky November 1985 ASCII HTML 2

This memo is in response to Bob Braden's call for a transaction oriented protocol (RFC-955), and continues the discussion of a possible transaction oriented transport protocol. This memo does not propose a standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0962 RFC0963 Some problems with the specification of the Military Standard Internet Protocol D.P. Sidhu November 1985 ASCII HTML 19

The purpose of this RFC is to provide helpful information on the Military Standard Internet Protocol (MIL-STD-1777) so that one can obtain a reliable implementation of this protocol. This paper points out several problems in this specification. This note also proposes solutions to these problems.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0963 RFC0964 Some problems with the specification of the Military Standard Transmission Control Protocol D.P. Sidhu T. Blumer November 1985 ASCII HTML 10

The purpose of this RFC is to provide helpful information on the Military Standard Transmission Control Protocol (MIL-STD-1778) so that one can obtain a reliable implementation of this protocol standard. This note points out three errors with this specification. This note also proposes solutions to these problems.

 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0964 RFC0965 Format for a graphical communication protocol L. Aguilar December 1985 ASCII HTML 51

This RFC describes the requirements for a graphical format on which to base a graphical on-line communication protocol, and proposes an Interactive Graphical Communication Format using the GKSM session metafile. We hope this contribution will encourage the discussion of multimedia data exchange and the proposal of solutions.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0965 RFC0966 Host groups: A multicast extension to the Internet Protocol S.E. Deering D.R. Cheriton December 1985 ASCII HTML 27

This RFC defines a model of service for Internet multicasting and proposes an extension to the Internet Protocol (IP) to support such a multicast service. Discussion and suggestions for improvements are requested. See RFC-988.

 RFC0988 UNKNOWN UNKNOWN Legacy 10.17487/RFC0966 RFC0967 All victims together M.A. Padlipsky December 1985 ASCII HTML 2

This RFC proposes a new set of RFCs on how the networking code is integrated with various operating systems. It appears that this topic has not received enough exposure in the literature. Comments and suggestions are encouraged.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0967 RFC0968 Twas the night before start-up V.G. Cerf December 1985 ASCII HTML 2

This memo discusses problems that arise and debugging techniques used in bringing a new network into operation.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0968 RFC0969 NETBLT: A bulk data transfer protocol D.D. Clark M.L. Lambert L. Zhang December 1985 ASCII HTML 15

This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is a preliminary discussion of the Network Block Transfer (NETBLT) protocol. NETBLT is intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is structured to provide maximum throughput over a wide variety of networks. This description is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-998.

 RFC0998 UNKNOWN UNKNOWN Legacy 10.17487/RFC0969 RFC0970 On Packet Switches With Infinite Storage J. Nagle December 1985 ASCII HTML 9

The purpose of this RFC is to focus discussion on a particular problem in the ARPA-Internet and possible methods of solution. Most prior work on congestion in datagram systems focuses on buffer management. In this memo the case of a packet switch with infinite storage is considered. Such a packet switch can never run out of buffers. It can, however, still become congested. The meaning of congestion in an infinite-storage system is explored. An unexpected result is found that shows a datagram network with infinite storage, first-in-first-out queuing, at least two packet switches, and a finite packet lifetime will, under overload, drop all packets. By attacking the problem of congestion for the infinite-storage case, new solutions applicable to switches with finite storage may be found. No proposed solutions this document are intended as standards for the ARPA-Internet at this time.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0970 RFC0971 Survey of data representation standards A.L. DeSchon January 1986 ASCII HTML 9

This RFC is a comparison of several data representation standards that are currently in use. The standards discussed are the CCITT X.409 recommendation, the NBS Computer Based Message System (CBMS) standard, DARPA Multimedia Mail system, the Courier remote procedure call protocol, and the SUN Remote Procedure Call package. No proposals in this document are intended as standards for the ARPA-Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate approach to a data representation standard, leading eventually to the adoption of an ARPA-Internet standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0971 RFC0972 Password Generator Protocol F.J. Wancho January 1986 ASCII HTML 2

This RFC specifies a standard for the ARPA Internet community. The Password Generator Service (PWDGEN) provides a set of six randomly generated eight-character "words" with a reasonable level of pronounceability, using a multi-level algorithm. Hosts on the ARPA Internet that choose to implement a password generator service are expected to adopt and implement this standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0972 RFC0973 Domain system changes and observations P. Mockapetris January 1986 ASCII HTML 10

This RFC documents updates to Domain Name System specifications RFC-882 and RFC-883, suggests some operational guidelines, and discusses some experiences and problem areas in the present system.

 RFC1034 RFC1035 RFC0882 RFC0883 UNKNOWN UNKNOWN Legacy 10.17487/RFC0973 RFC0974 Mail routing and the domain system C. Partridge January 1986 ASCII HTML 7 DNS-MX

This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing.

 RFC2821 STD0010 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC0974 RFC0975 Autonomous confederations D.L. Mills February 1986 ASCII HTML 10

This RFC proposes enhancements to the Exterior Gateway Protocol (EGP) to support a simple, multiple-level routing capability while preserving the robustness features of the current EGP model. The enhancements generalize the concept of core system to include multiple communities of autonomous systems, called autonomous confederations. Discussion and suggestions for improvement are requested.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0975 RFC0976 UUCP mail interchange format standard M.R. Horton February 1986 ASCII HTML 12

This document defines the standard format for the transmission of mail messages between computers in the UUCP Project. It does not however, address the format for storage of messages on one machine, nor the lower level transport mechanisms used to get the date from one machine to the next. It represents a standard for conformance by hosts in the UUCP zone.

 RFC1137 UNKNOWN UNKNOWN Legacy 10.17487/RFC0976 RFC0977 Network News Transfer Protocol B. Kantor P. Lapsley February 1986 ASCII HTML 27 NNTP

NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 RFC3977 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0977 RFC0978 Voice File Interchange Protocol (VFIP) J.K. Reynolds R. Gillman W.A. Brackenridge A. Witkowski J. Postel February 1986 ASCII HTML 5

The purpose of the Voice File Interchange Protocol (VFIP) is to permit the interchange of various types of speech files between different systems in the ARPA-Internet community. Suggestions for improvement are encouraged.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0978 RFC0979 PSN End-to-End functional specification A.G. Malis March 1986 ASCII HTML 15

This memo is an updated version of BBN Report 5775, "End-to-End Functional Specification and describes important changes to the functionality of the interface between a Host and the PSN, and should be carefully reviewed by anyone involved in supporting a host on either the ARPANET or MILNET". The new End-to-End protocol (EE) is being developed in order to correct a number of deficiencies in the old EE, to improve its performance and overall throughput, and to better equip the Packet Switch Node (PSN, also known as the IMP) to support its current and anticipated host population.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0979 RFC0980 Protocol document order information O.J. Jacobsen J. Postel March 1986 ASCII HTML 12

This RFC indicates how to obtain various protocol documents used in the DARPA research community. Included is an overview of the new 1985 DDN Protocol Handbook and available sources for obtaining related documents (such as DOD, ISO, and CCITT).

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0980 RFC0981 Experimental multiple-path routing algorithm D.L. Mills March 1986 ASCII HTML 22

This document introduces wiretap algorithms, a class of experimental, multiple routing algorithms that compute quasi-optimum routes for stations sharing a packet-radio broadcast channel. The primary route (a minimum-distance path), and additional paths ordered by distance, which serve as alternate routes should the primary route fail, are computed. This prototype is presented as an example of a class of routing algorithms and data-base management techniques that may find wider application in the Internet community. Discussions and suggestions for improvements are welcomed.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0981 RFC0982 Guidelines for the specification of the structure of the Domain Specific Part (DSP) of the ISO standard NSAP address H.W. Braun April 1986 ASCII HTML 11

This RFC is a draft working document of the ANSI "Guidelines for the Specification of the Structure of the Domain Specific Part (DSP) of the ISO Standard NSAP Address". It provides guidance to private address administration authorities on preferred formats and semantics for the Domain Specific Part (DSP) of an NSAP address. This RFC specifies the way in which the DSP may be constructed so as to facilitate efficient address assignment. This RFC is for informational purposes only and its distribution is unlimited and does not specify a standard of the ARPA-Internet.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0982 RFC0983 ISO transport arrives on top of the TCP D.E. Cass M.T. Rose April 1986 ASCII HTML 27

This memo describes a proposed protocol standard for the ARPA Internet community. The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors. To the largest extent possible, it is desirable to offer these higher level services directly in the ARPA Internet, without disrupting existing facilities. This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet. The intention is that hosts in the ARPA-Internet that choose to implement ISO TSAP services on top of the TCP be expected to adopt and implement this standard. Suggestions for improvement are encouraged.

 RFC1006 UNKNOWN UNKNOWN Legacy 10.17487/RFC0983 RFC0984 PCMAIL: A distributed mail system for personal computers D.D. Clark M.L. Lambert May 1986 ASCII HTML 31

This document is a preliminary discussion of the design of a personal-computer-based distributed mail system. Pcmail is a distributed mail system that provides mail service to an arbitrary number of users, each of which owns one or more personal computers (PCs). The system is divided into two halves. The first consists of a single entity called the "repository". The repository is a storage center for incoming mail. Mail for a Pcmail user can arrive externally from the Internet or internally from other repository users. The repository also maintains a stable copy of each user's mail state. The repository is therefore typically a computer with a large amount of disk storage. It is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-993.

 RFC0993 UNKNOWN UNKNOWN Legacy 10.17487/RFC0984 RFC0985 Requirements for Internet gateways - draft National Science Foundation Network Technical Advisory Group May 1986 ASCII HTML 23 Requirements Internet gateways

This RFC summarizes the requirements for gateways to be used on networks supporting the DARPA Internet protocols. While it applies specifically to National Science Foundation research programs, the requirements are stated in a general context and are believed applicable throughout the Internet community. The purpose of this document is to present guidance for vendors offering products that might be used or adapted for use in an Internet application. It enumerates the protocols required and gives references to RFCs and other documents describing the current specification.

 RFC1009 UNKNOWN UNKNOWN Legacy 10.17487/RFC0985 RFC0986 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol R. Callon H.W. Braun June 1986 ASCII HTML 7

This RFC suggests a method to allow the existing IP addressing, including the IP protocol field, to be used for the ISO Connectionless Network Protocol (CLNP). This is a draft solution to one of the problems inherent in the use of "ISO-grams" in the DOD Internet. Related issues will be discussed in subsequent RFCs. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 RFC1069 UNKNOWN UNKNOWN Legacy 10.17487/RFC0986 RFC0987 Mapping between X.400 and RFC 822 S.E. Kille June 1986 ASCII HTML 69

The X.400 series protocols have been defined by CCITT to provide an Interpersonal Messaging Service (IPMS), making use of a store and forward Message Transfer Service. It is expected that this standard will be implemented very widely. This document describes a set of mappings which will enable interworking between systems operating the X.400 protocols and systems using RFC-822 mail protocol or protocols derived from RFC-822. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

 RFC2156 RFC1327 RFC1026 RFC1138 RFC1148 UNKNOWN UNKNOWN Legacy 10.17487/RFC0987 RFC0988 Host extensions for IP multicasting S.E. Deering July 1986 ASCII HTML 20 multicast Internet

This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet. The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here.

 RFC0966 RFC1054 RFC1112 UNKNOWN UNKNOWN Legacy 10.17487/RFC0988 RFC0989 Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures J. Linn February 1987 ASCII HTML 23

This RFC suggests a proposed protocol for the Internet community and requests discussion and suggestions for improvements. This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This RFC defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. It is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or authentication is anticipated.

 RFC1040 RFC1113 UNKNOWN UNKNOWN Legacy 10.17487/RFC0989 RFC0990 Assigned numbers J.K. Reynolds J. Postel November 1986 ASCII HTML 75

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900.

 RFC0960 RFC1010 RFC0997 HISTORIC UNKNOWN Legacy 10.17487/RFC0990 RFC0991 Official ARPA-Internet protocols J.K. Reynolds J. Postel November 1986 ASCII HTML 46

This RFC identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. Obsoletes RFC-961, 944 and 924.

 RFC0961 RFC1011 UNKNOWN UNKNOWN Legacy 10.17487/RFC0991 RFC0992 On communication support for fault tolerant process groups K.P. Birman T.A. Joseph November 1986 ASCII HTML 18

This memo describes a collection of multicast communication primitives integrated with a mechanism for handling process failure and recovery. These primitives facilitate the implementation of fault-tolerant process groups, which can be used to provide distributed services in an environment subject to non-malicious crash failures.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0992 RFC0993 PCMAIL: A distributed mail system for personal computers D.D. Clark M.L. Lambert December 1986 ASCII HTML 28

This document is a discussion of the Pcmail workstation-based distributed mail system. It is a revision of the design published in NIC RFC-984. The revision is based on discussion and comment fromm a variety of sources, as well as further research into the design of interactive Pcmail clients and the use of client code on machines other than IBM PCs. As this design may change, implementation of this document is not advised. Obsoletes RFC-984.

 RFC0984 RFC1056 UNKNOWN UNKNOWN Legacy 10.17487/RFC0993 RFC0994 Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service International Organization for Standardization March 1986 ASCII HTML 52

This Protocol Standard is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol Standard is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498). In particular, it is a protocol of the Network Layer. This Protocol may be used between network-entities in end systems or in Network Layer relay systems (or both). It provides the Connectionless-mode Network Service as defined in Addendum 1 to the Network Service Definition Covering Connectionless-mode Transmission (ISO 8348/AD1).

 RFC0926 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=994 10.17487/RFC0994 RFC0995 End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473 International Organization for Standardization April 1986 ASCII HTML 41

This Protocol is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498) and by the structure defined in the Internal Organization of the Network Layer (DIS 8648). In particular, it is a protocol of the Network Layer. This Protocol permits End Systems and Intermediate Systems to exchange configuration and routing information to facilitate the operation of the routing and relaying functions of the Network Layer.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC0995 RFC0996 Statistics server D.L. Mills February 1987 ASCII HTML 3 STATSRV

This RFC specifies a standard for the ARPA Internet community. Hosts and gateways on the DARPA Internet that choose to implement a remote statistics monitoring facility may use this protocol to send statistics data upon request to a monitoring center or debugging host.

 HISTORIC HISTORIC Legacy 10.17487/RFC0996 RFC0997 Internet numbers J.K. Reynolds J. Postel March 1987 ASCII HTML 42

This memo is an official status report on the network numbers used in the Internet community. As of 1-Mar-87 the Network Information Center (NIC) at SRI International has assumed responsibility for assignment of Network Numbers and Autonomous System Numbers. This RFC documents the current assignments of these numbers at the time of this transfer of responsibility. Obsoletes RFC-990, 960, 943, 923 and 900.

 RFC1020 RFC1117 RFC0990 UNKNOWN UNKNOWN Legacy 10.17487/RFC0997 RFC0998 NETBLT: A bulk data transfer protocol D.D. Clark M.L. Lambert L. Zhang March 1987 ASCII HTML 21 NETBLT

This document is a description of, and a specification for, the NETBLT protocol. It is a revision of the specification published in RFC-969. NETBLT (NETwork BLock Transfer) is a transport level protocol intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is designed to provide maximum throughput over a wide variety of networks. Although NETBLT currently runs on top of the Internet Protocol (IP), it should be able to operate on top of any datagram protocol similar in function to IP. This document is published for discussion and comment, and does not constitute a standard. The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised. Obsoletes RFC-969.

 RFC0969 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0998 RFC0999 Requests For Comments summary notes: 900-999 A. Westine J. Postel April 1987 ASCII HTML 22 RFC0160 RFC1000 UNKNOWN UNKNOWN Legacy 10.17487/RFC0999 RFC1000 Request For Comments reference guide J.K. Reynolds J. Postel August 1987 ASCII HTML 149

This RFC Reference Guide is intended to provide a historical account by categorizing and summarizing of the Request for Comments numbers 1 through 999 issued between the years 1969-1987. These documents have been crossed referenced to indicate which RFCs are current, obsolete, or revised.

 RFC0999 UNKNOWN UNKNOWN Legacy 10.17487/RFC1000 RFC1001 Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods NetBIOS Working Group in the Defense Advanced Research Projects Agency Internet Activities Board End-to-End Services Task Force March 1987 ASCII HTML 68 NETBIOS

This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC describes the NetBIOS-over-TCP protocols in a general manner, emphasizing the underlying ideas and techniques. Detailed specifications are found in a companion RFC, "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications".

 STD0019 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1001 10.17487/RFC1001 RFC1002 Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications NetBIOS Working Group in the Defense Advanced Research Projects Agency Internet Activities Board End-to-End Services Task Force March 1987 ASCII HTML 84 NETBIOS

This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC gives the detailed specifications of the netBIOS-over-TCP packets, protocols, and defined constants and variables. A more general overview is found in a companion RFC, "Protocol Standard For NetBIOS Service on TCP/UDP Transport: Concepts and Methods".

 STD0019 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1002 10.17487/RFC1002 RFC1003 Issues in defining an equations representation standard A.R. Katz March 1987 ASCII HTML 7

This memo is intended to identify and explore issues in defining a standard for the exchange of mathematical equations. No attempt is made at a complete definition and more questions are asked than are answered. Questions about the user interface are only addressed to the extent that they affect interchange issues.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1003 RFC1004 Distributed-protocol authentication scheme D.L. Mills April 1987 ASCII HTML 8 COOKIE-JAR

The purpose of this RFC is to focus discussion on authentication problems in the Internet and possible methods of solution. The proposed solutions this document are not intended as standards for the Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to authentication problems, leading eventually to the adoption of standards. This document suggests mediated access-control and authentication procedures suitable for those cases when an association is to be set up between users belonging to different trust environments.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1004 RFC1005 ARPANET AHIP-E Host Access Protocol (enhanced AHIP) A. Khanna A.G. Malis May 1987 ASCII HTML 34

This RFC is a proposed specification for the encoding of Class A IP addresses for use on ARPANET-style networks such as the Milnet and Arpanet, and for enhancements to the ARPANET AHIP Host Access Protocol (AHIP; formerly known as 1822). These enhancements increase the size of the PSN field, allow ARPANET hosts to use logical names to address each other, allow for the communication of type-of-service information from the host to the PSN and enable the PSN to provide congestion feedback to the host on a connection basis.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1005 RFC1006 ISO Transport Service on top of the TCP Version: 3 M.T. Rose D.E. Cass May 1987 ASCII HTML 19 TP-TCP

This memo specifies a standard for the Internet community. Hosts on the Internet that choose to implement ISO transport services on top of the TCP are expected to adopt and implement this standard. TCP port 102 is reserved for hosts which implement this standard. This memo specifies version 3 of the protocol and supersedes RFC-983. Changes between the protocol is described in RFC-983 and this memo are minor, but unfortunately incompatible.

 RFC0983 RFC2126 STD0035 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1006 RFC1007 Military supplement to the ISO Transport Protocol W. McCoy June 1987 ASCII HTML 23

This document supplements the Transport Service and Protocol of the International Standards Organization (ISO), IS 8072 and IS 8073, respectively, and their formal descriptions by providing conventions, option selections and parameter values. This RFC is being distributed to members of the Internet community in order to solicit comments on the Draft Military Supplement. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1007 RFC1008 Implementation guide for the ISO Transport Protocol W. McCoy June 1987 ASCII HTML 73

This RFC is being distributed to members of the Internet community in order to solicit comments on the Implementors Guide. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1008 RFC1009 Requirements for Internet gateways R.T. Braden J. Postel June 1987 ASCII HTML 54

This RFC summarizes the requirements for gateways to be used between networks supporting the Internet protocols. This document is a formal statement of the requirements to be met by gateways used in the Internet system. As such, it is an official specification for the Internet community.

 RFC0985 RFC1812 HISTORIC HISTORIC Legacy 10.17487/RFC1009 RFC1010 Assigned numbers J.K. Reynolds J. Postel May 1987 ASCII HTML 44

This memo is an official status report on the numbers used in protocols in the Internet community. It documents the currently assigned values from several series of numbers including link, socket, port, and protocol, used in network protocol implementations.

 RFC0990 RFC1060 HISTORIC UNKNOWN Legacy 10.17487/RFC1010 RFC1011 Official Internet protocols J.K. Reynolds J. Postel May 1987 ASCII HTML 52

This memo is an official status report on the protocols used in the Internet community. It identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned.

 RFC0991 RFC6093 RFC9293 UNKNOWN UNKNOWN Legacy 10.17487/RFC1011 RFC1012 Bibliography of Request For Comments 1 through 999 J.K. Reynolds J. Postel June 1987 ASCII HTML 64

This RFC is a reference guide for the Internet community which provides a bibliographic summary of the Request for Comments numbers 1 through 999 issued between the years 1969-1987.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1012 RFC1013 X Window System Protocol, version 11: Alpha update April 1987 R.W. Scheifler June 1987 ASCII HTML 101

This RFC is distributed to the Internet community for information only. It does not establish an Internet standard. The X window system has been widely reviewed and tested. The Internet community is encouraged to experiment with it.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1013 RFC1014 XDR: External Data Representation standard Sun Microsystems June 1987 ASCII HTML 20

XDR is a standard for the description and encoding of data. It is useful for transferring data between different computer architectures. XDR fits into ISO presentation layer, and is roughly analogous in purpose to X.409, ISO Abstract Syntax Notation. The major difference between these two is that XDR uses implicit typing, while X.409 uses explicit typing. This RFC is distributed for information only, it does not establish a Internet standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1014 RFC1015 Implementation plan for interagency research Internet B.M. Leiner July 1987 ASCII HTML 24

This RFC proposes an Interagency Research Internet as the natural outgrowth of the current Internet. This is an "idea paper" and discussion is strongly encouraged.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1015 RFC1016 Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID) W. Prue J. Postel July 1987 ASCII HTML 18

The memo is intended to explore the issue of what a host could do with a source quench. The proposal is for each source host IP module to introduce some delay between datagrams sent to the same destination host. This is a "crazy idea paper" and discussion is essential.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1016 RFC1017 Network requirements for scientific research: Internet task force on scientific computing B.M. Leiner August 1987 ASCII HTML 19

This RFC identifies the requirements on communication networks for supporting scientific research. It proposes some specific areas for near term work, as well as some long term goals. This is an "idea" paper and discussion is strongly encouraged.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1017 RFC1018 Some comments on SQuID A.M. McKenzie August 1987 ASCII HTML 3

This memo is a discussion of some of the ideas expressed in RFC-1016 on Source Quench. This memo introduces the distinction of the cause of congestion in a gateway between the effects of "Funneling" and "Mismatch". It is offered in the same spirit as RFC-1016; to stimulate discussion. The opinions offered are personal, not corporate, opinions. Distribution of this memo is unlimited.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1018 RFC1019 Report of the Workshop on Environments for Computational Mathematics D. Arnon September 1987 ASCII HTML 8

This memo is a report on the discussion of the representation of equations in a workshop at the ACM SIGGRAPH Conference held in Anaheim, California on 30 July 1987.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1019 RFC1020 Internet numbers S. Romano M.K. Stahl November 1987 ASCII HTML 51

This RFC is a list of the Assigned IP Network Numbers and EGP Autonomous System Numbers. This RFC obsoletes RFC-997.

 RFC0997 RFC1062 RFC1117 RFC1166 UNKNOWN UNKNOWN Legacy 10.17487/RFC1020 RFC1021 High-level Entity Management System (HEMS) C. Partridge G. Trewitt October 1987 ASCII HTML 5 HEMS

This memo provides a general overview of the High-level Entity management system (HEMS). This system is experimental, and is currently being tested in portions of the Internet.

 HISTORIC HISTORIC Legacy 10.17487/RFC1021 RFC1022 High-level Entity Management Protocol (HEMP) C. Partridge G. Trewitt October 1987 ASCII HTML 12

This memo presents an application protocol for managing network entities such as hosts, gateways, and front end machines. This protocol is a component of the High-level Entity Management System HEMS), described is RFC-1021. This memo also assumes a knowledge of the ISO data encoding standard, ASN.1.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1022 RFC1023 HEMS monitoring and control language G. Trewitt C. Partridge October 1987 ASCII HTML 17

This RFC specifies the High-Level Entity Management System (HEMS) Monitoring and Control Language. This language defines the requests and replies used in HEMS. This memo assumes knowledge of the HEMS system described in RFC-1021, and of the ISO data encoding standard, ASN.1.

 RFC1076 UNKNOWN UNKNOWN Legacy 10.17487/RFC1023 RFC1024 HEMS variable definitions C. Partridge G. Trewitt October 1987 ASCII HTML 74

This memo assigns instruction codes, defines object formats and object semantics for use with the High-Level Monitoring and Control Language, defined in RFC-1023. A general system has been described in previous memos (RFC-1021, RFC-1022). This system is called the High-Level Entity Management System (HEMS). This memo is provisional and the definitions are subject to change. Readers should confirm with the authors that they have the most recent version. This RFC assumes a working knowledge of the ISO data encoding standard, ASN.1, and a general understanding of the IP protocol suite.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1024 RFC1025 TCP and IP bake off J. Postel September 1987 ASCII HTML 6

This memo describes some of the procedures, scoring and tests used in the TCP and IP bake offs held in the early development of these protocols. These procedures and tests may still be of use in testing newly implemented TCP and IP modules.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1025 RFC1026 Addendum to RFC 987: (Mapping between X.400 and RFC-822) S.E. Kille September 1987 ASCII HTML 4

This memo suggest a proposed protocol for the Internet community, and request discussion and suggestions for improvements.

 RFC2156 RFC1327 RFC0987 RFC1138 RFC1148 UNKNOWN UNKNOWN Legacy 10.17487/RFC1026 RFC1027 Using ARP to implement transparent subnet gateways S. Carl-Mitchell J.S. Quarterman October 1987 ASCII HTML 8

This RFC describes the use of the Address Resolution Protocol (ARP) by subnet gateways to permit hosts on the connected subnets to communicate without being aware of the existence of subnets, using the technique of "Proxy ARP".

 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=1027 10.17487/RFC1027 RFC1028 Simple Gateway Monitoring Protocol J. Davin J.D. Case M. Fedor M.L. Schoffstall November 1987 ASCII HTML 35 SGMP

This memo defines a simple application-layer protocol by which management information for a gateway may be inspected or altered by remote users. This proposal is intended only as an interim response to immediate gateway monitoring needs.

 HISTORIC HISTORIC Legacy 10.17487/RFC1028 RFC1029 More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets G. Parr May 1988 ASCII HTML 17 arp

This memo discusses an extension to a Bridge Protocol to detect and disclose changes in heighbouring host address parameters in a Multi-Lan system of Ethernets. The problem is one which is appearing more and more regularly as the interconnected systems grow larger on Campuses and in Commercial Institutions. This RFC suggests a protocol enhancement for the Internet community, and requests discussion and suggestions for improvements.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1029 RFC1030 On testing the NETBLT Protocol over divers networks M.L. Lambert November 1987 ASCII HTML 16

This memo describes the results gathered from testing NETBLT over three networks of different bandwidths and round-trip delays. The results are not complete, but the information gathered so far has not been promising. The NETBLT protocol is specified in RFC-998; this document assumes an understanding of the specification as described in RFC-998.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1030 RFC1031 MILNET name domain transition W.D. Lazear November 1987 ASCII HTML 10

This RFC consolidates information necessary for the implementation of domain style names throughout the DDN/MILNET Internet community. The introduction of domain style names will impact all hosts in the DDN/MILNET Internet. This RFC is designed as an aid to implementors and administrators by providing: 1) an overview of the transition process from host tables to domains, 2) a timetable for the transition, and 3) references to documentation and software relating to the domain system.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1031 RFC1032 Domain administrators guide M.K. Stahl November 1987 ASCII HTML 14

Domains are administrative entities that provide decentralized management of host naming and addressing. The domain-naming system is distributed and hierarchical. This memo describes procedures for registering a domain with the Network Information Center (NIC) of Defense Data Network (DDN), and offers guidelines on the establishment and administration of a domain in accordance with the requirements specified in RFC-920. It is recommended that the guidelines described in this document be used by domain administrators in the establishment and control of second-level domains. The role of the domain administrator (DA) is that of coordinator, manager, and technician. If his domain is established at the second level or lower in the tree, the domain administrator must register by interacting with the management of the domain directly above this.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1032 RFC1033 Domain Administrators Operations Guide M. Lottor November 1987 ASCII HTML 22

This RFC provides guidelines for domain administrators in operating a domain server and maintaining their portion of the hierarchical database. Familiarity with the domain system is assumed (see RFCs 1031, 1032, 1034, and 1035).

 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=1033 10.17487/RFC1033 RFC1034 Domain names - concepts and facilities P. Mockapetris November 1987 ASCII HTML 55 DOMAIN

This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.

 RFC0973 RFC0882 RFC0883 RFC1101 RFC1183 RFC1348 RFC1876 RFC1982 RFC2065 RFC2181 RFC2308 RFC2535 RFC4033 RFC4034 RFC4035 RFC4343 RFC4035 RFC4592 RFC5936 RFC8020 RFC8482 RFC8767 STD0013 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1034 10.17487/RFC1034 RFC1035 Domain names - implementation and specification P. Mockapetris November 1987 ASCII HTML 55 DOMAIN DNS

This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.

 RFC0973 RFC0882 RFC0883 RFC1101 RFC1183 RFC1348 RFC1876 RFC1982 RFC1995 RFC1996 RFC2065 RFC2136 RFC2181 RFC2137 RFC2308 RFC2535 RFC2673 RFC2845 RFC3425 RFC3658 RFC4033 RFC4034 RFC4035 RFC4343 RFC5936 RFC5966 RFC6604 RFC7766 RFC8482 RFC8490 RFC8767 STD0013 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1035 10.17487/RFC1035 RFC1036 Standard for interchange of USENET messages M.R. Horton R. Adams December 1987 ASCII HTML 19

This RFC defines the standard format for the interchange of network News messages among USENET hosts. It updates and replaces RFC-850, reflecting version B2.11 of the News program. This memo is distributed as an RFC to make this information easily accessible to the Internet community. It does not specify an Internet standard.

 RFC0850 RFC5536 RFC5537 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=1036 10.17487/RFC1036 RFC1037 NFILE - a file access protocol B. Greenberg S. Keene December 1987 ASCII HTML 86 NFILE

This document includes a specification of the NFILE file access protocol and its underlying levels of protocol, the Token List Transport Layer and Byte Stream with Mark. The goal of this specification is to promote discussion of the ideas described here, and to encourage designers of future file protocols to take advantage of these ideas. A secondary goal is to make the specification available to sites that might benefit from implementing NFILE.

 HISTORIC HISTORIC Legacy 10.17487/RFC1037 RFC1038 Draft revised IP security option M. St. Johns January 1988 ASCII HTML 7

This memo is a pre-publication draft of the revised Internet Protocol Security Option. This RFC reflects the version as approved by the Protocol Standards Steering group, and is provided for informational purposes only. The final version of this document will be available from Navy publications and should not differ from this document in any major fashion. This document will be published as a change to the MIL- STD 1777, "Internet Protocol".

 RFC1108 UNKNOWN UNKNOWN Legacy 10.17487/RFC1038 RFC1039 DoD statement on Open Systems Interconnection protocols D. Latham January 1988 ASCII HTML 3

This RFC reproduces a memorandum issued on 2-JUL-87 from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC31) to the Director of the Defense Communications Agency (DCA). This memo is distributed for information only.

 RFC0945 UNKNOWN UNKNOWN Legacy 10.17487/RFC1039 RFC1040 Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures J. Linn January 1988 ASCII HTML 29

This RFC is the Outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This memo defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. Detailed key management mechanisms to support these procedures will be defined in a subsequent RFC. As a goal of this initial phase, it is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or integrity check computation is anticipated.

 RFC0989 RFC1113 UNKNOWN UNKNOWN Legacy 10.17487/RFC1040 RFC1041 Telnet 3270 regime option Y. Rekhter January 1988 ASCII HTML 6 TOPT-3270

This RFC specifies a proposed standard for the Internet community. Hosts on the Internet that want to support 3270 data stream within the Telnet protocol, are expected to adopt and implement this standard.

 RFC6270 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1041 RFC1042 Standard for the transmission of IP datagrams over IEEE 802 networks J. Postel J.K. Reynolds February 1988 ASCII HTML 15 IP-IEEE

This RFC specifies a standard method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on IEEE 802 Networks to allow compatible and interoperable implementations. This RFC specifies a protocol standard for the Internet community.

 RFC0948 STD0043 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1042 10.17487/RFC1042 RFC1043 Telnet Data Entry Terminal option: DODIIS implementation A. Yasuda T. Thompson February 1988 ASCII HTML 26 TOPT-DATA

This RFC suggests a proposed protocol on the TELNET Data Entry Terminal (DET) Option - DODIIS Implementation for the Internet community. It is intended that this specification be capatible with the specification of DET Option in RFC-732. Discussion and suggests for improvements are encouraged.

 RFC0732 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1043 RFC1044 Internet Protocol on Network System's HYPERchannel: Protocol Specification K. Hardwick J. Lekashman February 1988 ASCII HTML 43 IP-HC

This memo intends to provide a complete discussion of the protocols and techniques used to embed DoD standard Internet Protocol datagrams (and its associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment. This document is directed toward network planners and implementors who are already familiar with the TCP/IP protocol suite and the techniques used to carry TCP/IP traffic on common networks such as the DDN or the Ethernet. No great familiarity with NSC products is assumed; an appendix is devoted to a review of NSC technologies and protocols.

 RFC5494 STD0045 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1044 RFC1045 VMTP: Versatile Message Transaction Protocol: Protocol specification D.R. Cheriton February 1988 ASCII HTML 128 VMTP

This memo specifies the Versatile Message Transaction Protocol (VMTP) [Version 0.7 of 19-Feb-88], a transport protocol specifically designed to support the transaction model of communication, as exemplified by remote procedure call (RPC). The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level. Subsettability allows the VMTP module for particular clients and servers to be specialized and simplified to the services actually required. Examples of such simple clients and servers include PROM network bootload programs, network boot servers, data sensors and simple controllers, to mention but a few examples. This RFC describes a protocol proposed as a standard for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1045 RFC1046 Queuing algorithm to provide type-of-service for IP links W. Prue J. Postel February 1988 ASCII HTML 11

This memo is intended to explore how Type-of-Service might be implemented in the Internet. The proposal describes a method of queuing which can provide the different classes of service. The technique also prohibits one class of service from consuming excessive resources or excluding other classes of service. This is an "idea paper" and discussion is strongly encouraged.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1046 RFC1047 Duplicate messages and SMTP C. Partridge February 1988 ASCII HTML 3

An examination of a synchronization problem in the Simple Mail Transfer Protocol (SMTP) is presented. This synchronization problem can cause a message to be delivered multiple times. A method for avoiding this problem is suggested. Nodding familiarity with the SMTP specification, RFC-821, is required.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1047 RFC1048 BOOTP vendor information extensions P.A. Prindeville February 1988 ASCII HTML 7

This memo proposes an addition to the Bootstrap Protocol (BOOTP). Comments and suggestions for improvements are sought.

 RFC1084 RFC1395 RFC1497 RFC1533 UNKNOWN UNKNOWN Legacy 10.17487/RFC1048 RFC1049 Content-type header field for Internet messages M.A. Sirbu March 1988 ASCII HTML 8 CONTENT

This memo suggests proposed additions to the Internet Mail Protocol, RFC-822, for the Internet community, and requests discussion and suggestions for improvements.

 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1049 RFC1050 RPC: Remote Procedure Call Protocol specification Sun Microsystems April 1988 ASCII HTML 24 SUN-RPC

This memo specifies a message protocol used in implementing Sun's Remote Procedure Call (RPC) package. This RFC describes a standard that Sun Microsystems and others are using and is one they wish to propose for the Internet's consideration. It is not an Internet standard at this time.

 RFC1057 HISTORIC HISTORIC Legacy 10.17487/RFC1050 RFC1051 Standard for the transmission of IP datagrams and ARP packets over ARCNET networks P.A. Prindeville March 1988 ASCII HTML 4

This memo specifies a standard method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams on an ARCNET. This RFC is a standard protocol for the Internet community.

 RFC1201 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1051 RFC1052 IAB recommendations for the development of Internet network management standards V.G. Cerf April 1988 ASCII HTML 14

This RFC is intended to convey to the Internet community and other interested parties the recommendations of the Internet Activities Board (IAB) for the development of network management protocols for use in the TCP/IP environment. This memo does NOT, in and of itself, define or propose an Official Internet Protocol. It does reflect, however, the policy of the IAB with respect to further network management development in the short and long term.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1052 RFC1053 Telnet X.3 PAD option S. Levy T. Jacobson April 1988 ASCII HTML 21 TOPT-X.3

This RFC proposes a new option to Telnet for the Internet community, and requests discussion and suggestions for improvements.

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1053 RFC1054 Host extensions for IP multicasting S.E. Deering May 1988 ASCII HTML 19

This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. IP multicasting is the transmission of an IP datagram to a "host group", a set hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams. It is proposed as a standard for IP multicasting in the Internet. This specification is a major revision of RFC-988.

 RFC0988 RFC1112 UNKNOWN UNKNOWN Legacy 10.17487/RFC1054 RFC1055 Nonstandard for transmission of IP datagrams over serial lines: SLIP J.L. Romkey June 1988 ASCII HTML 6 IP-SLIP

The TCP/IP protocol family runs over a variety of network media: IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines, satellite links, and serial lines. There are standard encapsulations for IP packets defined for many of these networks, but there is no standard for serial lines. SLIP, Serial Line IP, is a currently a de facto standard, commonly used for point-to-point serial connections running TCP/IP. It is not an Internet standard.

 STD0047 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1055 10.17487/RFC1055 RFC1056 PCMAIL: A distributed mail system for personal computers M.L. Lambert June 1988 ASCII HTML 38 PCMAIL

This memo is a discussion of the Pcmail workstation based distributed mail system. It is identical to the discussion in RFC-993, save that a new, much simpler mail transport protocol is described. The new transport protocol is the result of continued research into ease of protocol implementation and use issues.

 RFC0993 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1056 RFC1057 RPC: Remote Procedure Call Protocol specification: Version 2 Sun Microsystems June 1988 ASCII HTML 25 SUN-RPC

This RFC describes a standard that Sun Microsystems and others are using, and is one we wish to propose for the Internet's consideration. This memo is not an Internet standard at this time.

 RFC1050 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1057 RFC1058 Routing Information Protocol C.L. Hedrick June 1988 ASCII HTML 33 RIP

This RFC describes an existing protocol for exchanging routing information among gateways and other hosts. It is intended to be used as a basis for developing gateway software for use in the Internet community.

 RFC1388 RFC1723 HISTORIC HISTORIC Legacy 10.17487/RFC1058 RFC1059 Network Time Protocol (version 1) specification and implementation D.L. Mills July 1988 ASCII HTML 58 NTP NTPv1 time clock synchronization

This memo describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical master-slave configuration synchronizes logical clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. The NTP architectures, algorithms and protocols which have evolved over several years of implementation and refinement are described in this document. The prototype system, which has been in regular operation in the Internet for the last two years, is described in an Appendix along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even the cases of failure or disruption of clocks, time servers or nets. This is a Draft Standard for an Elective protocol.

 RFC0958 RFC1119 RFC1305 UNKNOWN UNKNOWN Legacy 10.17487/RFC1059 RFC1060 Assigned numbers J.K. Reynolds J. Postel March 1990 ASCII HTML 86

This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. Distribution of this memo is unlimited.

 RFC1010 RFC1340 RFC1349 HISTORIC UNKNOWN Legacy 10.17487/RFC1060 RFC1061 RFC1062 Internet numbers S. Romano M.K. Stahl M. Recker August 1988 ASCII HTML 65

This memo is an official status report on the network numbers and gateway autonomous system numbers used in the Internet community.

 RFC1020 RFC1117 RFC1166 UNKNOWN UNKNOWN Legacy 10.17487/RFC1062 RFC1063 IP MTU discovery options J.C. Mogul C.A. Kent C. Partridge K. McCloghrie July 1988 ASCII HTML 11

A pair of IP options that can be used to learn the minimum MTU of a path through an internet is described, along with its possible uses. This is a proposal for an Experimental protocol.

 RFC1191 UNKNOWN UNKNOWN Legacy 10.17487/RFC1063 RFC1064 Interactive Mail Access Protocol: Version 2 M.R. Crispin July 1988 ASCII HTML 26

This memo suggests a method for workstations to dynamically access mail from a mailbox server ("respository"). This RFC specifies a standard for the SUMEX-AIM community and a proposed experimental protocol for the Internet community. Discussion and suggestions for improvement are requested.

 RFC1176 RFC1203 UNKNOWN UNKNOWN Legacy 10.17487/RFC1064 RFC1065 Structure and identification of management information for TCP/IP-based internets K. McCloghrie M.T. Rose August 1988 ASCII HTML 21

This RFC provides the common definitions for the structure and identification of management information for TCP/IP-based internets. In particular, together with its companion memos, which describe the initial management information base along with the initial network management protocol, these documents provide a simple, working architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementation in the Internet which are network manageable are expected to adopt and implement this specification.

 RFC1155 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1065 10.17487/RFC1065 RFC1066 Management Information Base for network management of TCP/IP-based internets K. McCloghrie M.T. Rose August 1988 ASCII HTML 90

This RFC provides the initial version of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets in the short-term. In particular, together with its companion memos which describe the structure of management information along with the initial network management protocol, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets, and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification.

 RFC1156 UNKNOWN UNKNOWN Legacy 10.17487/RFC1066 RFC1067 Simple Network Management Protocol J.D. Case M. Fedor M.L. Schoffstall J. Davin August 1988 ASCII HTML 33

This RFC defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification.

 RFC1098 UNKNOWN UNKNOWN Legacy 10.17487/RFC1067 RFC1068 Background File Transfer Program (BFTP) A.L. DeSchon R.T. Braden August 1988 ASCII HTML 27 FTP

This RFC describes an Internet background file transfer service that is built upon the third-party transfer model of FTP. No new protocols are involved. The purpose of this memo is to stimulate discussions on new Internet service modes.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1068 RFC1069 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol R. Callon H.W. Braun February 1989 ASCII HTML 10

This RFC suggests an addressing scheme for use with the ISO Connectionless Network Protocol (CLNP) in the Internet. This is a solution to one of the problems inherent in the use of "ISO-grams" in the Internet. This memo is a revision of RFC 986. This RFC suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements.

 RFC0986 UNKNOWN UNKNOWN Legacy 10.17487/RFC1069 RFC1070 Use of the Internet as a subnetwork for experimentation with the OSI network layer R.A. Hagens N.E. Hall M.T. Rose February 1989 ASCII HTML 17

This RFC proposes a scenario for experimentation with the International Organization for Standardization (ISO) Open Systems Interconnection (OSI) network layer protocols over the Internet and requests discussion and suggestions for improvements to this scenario. This RFC also proposes the creation of an experimental OSI internet. To participate in the experimental OSI internet, a system must abide by the agreements set forth in this RFC.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1070 RFC1071 Computing the Internet checksum R.T. Braden D.A. Borman C. Partridge September 1988 ASCII HTML 24

This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques.

 RFC1141 INFORMATIONAL UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=1071 10.17487/RFC1071 RFC1072 TCP extensions for long-delay paths V. Jacobson R.T. Braden October 1988 ASCII HTML 16

This RFC proposes a set of extensions to the TCP protocol to provide efficient operation over a path with a high bandwidth*delay product. These extensions are not proposed as an Internet standard at this time. Instead, they are intended as a basis for further experimentation and research on transport protocol performance.

 RFC1323 RFC2018 RFC6247 HISTORIC UNKNOWN Legacy 10.17487/RFC1072 RFC1073 Telnet window size option D. Waitzman October 1988 ASCII HTML 4 TOPT-NAWS

This RFC describes a proposed Telnet option to allow a client to convey window size to a Telnet server.

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1073 RFC1074 NSFNET backbone SPF based Interior Gateway Protocol J. Rekhter October 1988 ASCII HTML 5

This RFC is an implementation description of the standard ANSI IS-IS and ISO ES-IS routing protocols within the NSFNET backbone network.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1074 RFC1075 Distance Vector Multicast Routing Protocol D. Waitzman C. Partridge S.E. Deering November 1988 ASCII HTML 24 IP-DVMRP

This RFC describes a distance-vector-style routing protocol for routing multicast datagrams through an internet. It is derived from the Routing Information Protocol (RIP), and implements multicasting as described in RFC-1054. This is an experimental protocol, and its implementation is not recommended at this time.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1075 RFC1076 HEMS monitoring and control language G. Trewitt C. Partridge November 1988 ASCII HTML 42

This RFC specifies a query language for monitoring and control of network entities. This RFC supercedes RFC 1023, extending the query language and providing more discussion of the underlying issues. This language is a component of the High-Level Entity Monitoring System (HEMS) described in RFC 1021 and RFC 1022. Readers may wish to consult these RFCs when reading this memo. RFC 1024 contains detailed assignments of numbers and structures used in this system. Portions of RFC 1024 that define query language structures are superceded by definitions in this memo. This memo assumes a knowledge of the ISO data encoding standard, ASN.1.

 RFC1023 UNKNOWN UNKNOWN Legacy 10.17487/RFC1076 RFC1077 Critical issues in high bandwidth networking B.M. Leiner November 1988 ASCII HTML 46

This memo presents the results of a working group on High Bandwidth Networking. This RFC is for your information and you are encouraged to comment on the issues presented.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1077 RFC1078 TCP port service Multiplexer (TCPMUX) M. Lottor November 1988 ASCII HTML 2

This RFC proposes an Internet standard which can be used by future TCP services instead of using 'well-known ports'.

 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC1078 RFC1079 Telnet terminal speed option C.L. Hedrick December 1988 ASCII HTML 3 TOPT-TS

This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal speed information within the Telnet protocol are expected to adopt and implement this standard.

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1079 RFC1080 Telnet remote flow control option C.L. Hedrick November 1988 ASCII HTML 4

This RFC specifies a standard for the Internet community. Hosts on the Internet that do remote flow control within the Telnet protocol are expected to adopt and implement this standard.

 RFC1372 UNKNOWN UNKNOWN Legacy 10.17487/RFC1080 RFC1081 Post Office Protocol: Version 3 M.T. Rose November 1988 ASCII HTML 16

This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements.

 RFC1225 UNKNOWN UNKNOWN Legacy 10.17487/RFC1081 RFC1082 Post Office Protocol: Version 3: Extended service offerings M.T. Rose November 1988 ASCII HTML 11

This memo suggests a simple method for workstations to dynamically access mail from a discussion group server, as an extension to an earlier memo which dealt with dynamically accessing mail from a mailbox server using the Post Office Protocol - Version 3 (POP3). This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. All of the extensions described in this memo to the POP3 are OPTIONAL.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1082 RFC1083 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board December 1988 ASCII HTML 12 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months.

 RFC1100 HISTORIC UNKNOWN Legacy 10.17487/RFC1083 RFC1084 BOOTP vendor information extensions J.K. Reynolds December 1988 ASCII HTML 8

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville. This memo will be updated as additional tags are are defined. This edition introduces Tag 13 for Boot File Size. Comments and suggestions for improvements are sought.

 RFC1048 RFC1395 RFC1497 RFC1533 UNKNOWN UNKNOWN Legacy 10.17487/RFC1084 RFC1085 ISO presentation services on top of TCP/IP based internets M.T. Rose December 1988 ASCII HTML 32

RFC 1006 describes a mechanism for providing the ISO transport service on top of TCP/IP. Once this method is applied, one may implement "real" ISO applications on top of TCP/IP-based internets, by simply implementing OSI session, presentation, and application services on top of the transport service access point which is provided on top of the TCP. Although straight-forward, there are some environments in which the richness provided by the OSI application layer is desired, but it is nonetheless impractical to implement the underlying OSI infrastructure (i.e., the presentation, session, and transport services on top of the TCP). This memo describes an approach for providing "stream-lined" support of OSI application services on top of TCP/IP-based internets for such constrained environments. This memo proposes a standard for the Internet community.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1085 RFC1086 ISO-TP0 bridge between TCP and X.25 J.P. Onions M.T. Rose December 1988 ASCII HTML 9

This memo proposes a standard for the Internet community. Hosts on the Internet that choose to implement ISO TP0 transport connectivity between TCP and X.25 based hosts are expected to experiment with this proposal. TCP port 146 is reserved for this proposal.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1086 RFC1087 Ethics and the Internet Defense Advanced Research Projects Agency Internet Activities Board January 1989 ASCII HTML 2 Ethics Internet

This memo is a statement of policy by the Internet Activities Board (IAB) concerning the proper use of the resources of the Internet.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1087 RFC1088 Standard for the transmission of IP datagrams over NetBIOS networks L.J. McLaughlin February 1989 ASCII HTML 3 IP-NETBIOS

This document specifies a standard method of encapsulating the Internet Protocol (IP) datagrams on NetBIOS networks.

 STD0048 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1088 RFC1089 SNMP over Ethernet M. Schoffstall C. Davin M. Fedor J. Case February 1989 ASCII HTML 3

This memo describes an experimental method by which the Simple Network Management Protocol (SNMP) can be used over Ethernet MAC layer framing instead of the Internet UDP/IP protocol stack. This specification is useful for LAN based network elements that support no higher layer protocols beyond the MAC sub-layer.

 RFC4789 UNKNOWN UNKNOWN Legacy 10.17487/RFC1089 RFC1090 SMTP on X.25 R. Ullmann February 1989 ASCII HTML 4

This memo proposes a standard for SMTP on the virtual circuit facility provided by the X.25 standard of the CCITT.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1090 RFC1091 Telnet terminal-type option J. VanBokkelen February 1989 ASCII HTML 7 TOPT-TERM

This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC 930. A change is made to permit cycling through a list of possible terminal types and selecting the most appropriate

 RFC0930 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1091 RFC1092 EGP and policy based routing in the new NSFNET backbone J. Rekhter February 1989 ASCII HTML 5

This memo discusses implementation decisions for routing issues in the NSFNET, especially in the NSFNET Backbone. Of special concern is the restriction of routing information to advertize the best route as established by a policy decision.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1092 RFC1093 NSFNET routing architecture H.W. Braun February 1989 ASCII HTML 9

This document describes the routing architecture for the NSFNET centered around the new NSFNET Backbone, with specific emphasis on the interface between the backbone and its attached networks.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1093 RFC1094 NFS: Network File System Protocol specification B. Nowicki March 1989 ASCII HTML 27 SUN-NFS

This RFC describes a protocol that Sun Microsystems, Inc., and others are using. A new version of the protocol is under development, but others may benefit from the descriptions of the current protocol, and discussion of some of the design issues.

 RFC1813 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1094 RFC1095 Common Management Information Services and Protocol over TCP/IP (CMOT) U.S. Warrier L. Besaw April 1989 ASCII HTML 67

This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in a TCP/IP environment. This architecture provides a means by which control and monitoring information can be exchanged between a manager and a remote network element. In particular, this memo defines the means for implementing the Draft International Standard (DIS) version of CMIS/CMIP on top of Internet transport protocols for the purpose of carrying management information defined in the Internet-standard management information base. DIS CMIS/CMIP is suitable for deployment in TCP/IP networks while CMIS/CMIP moves toward becoming an International Standard. Together with the relevant ISO standards and the companion RFCs that describe the initial structure of management information and management information base, these documents provide the basis for a comprehensive architecture and system for managing TCP/IP- based internets, and in particular the Internet.

 RFC1189 UNKNOWN UNKNOWN Legacy 10.17487/RFC1095 RFC1096 Telnet X display location option G.A. Marcy March 1989 ASCII HTML 3 TOPT-XDL

This RFC specifies a standard for the Internet community. Hosts on the Internet that transmit the X display location within the Telnet protocol are expected to adopt and implement this standard.

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1096 RFC1097 Telnet subliminal-message option B. Miller April 1 1989 ASCII HTML 3

This RFC specifies a standard for the Internet community. Hosts on the Internet that display subliminal messages within the Telnet protocol are expected to adopt and implement this standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1097 RFC1098 Simple Network Management Protocol (SNMP) J.D. Case M. Fedor M.L. Schoffstall J. Davin April 1989 ASCII HTML 34

This RFC is a re-release of RFC 1067, with a changed "Status of this Memo" section. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet.

 RFC1067 RFC1157 UNKNOWN UNKNOWN Legacy 10.17487/RFC1098 RFC1099 Request for Comments Summary: RFC Numbers 1000-1099 J. Reynolds December 1991 ASCII HTML 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1099 RFC1100 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board April 1989 ASCII HTML 14 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority (see the contact information at the end of this memo). Do not use this memo after 31-July-89.

 RFC1083 RFC1130 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1100 RFC1101 DNS encoding of network names and other types P. Mockapetris April 1989 ASCII HTML 14

This RFC proposes two extensions to the Domain Name System: - A specific method for entering and retrieving RRs which map between network names and numbers. - Ideas for a general method for describing mappings between arbitrary identifiers and numbers. The method for mapping between network names and addresses is a proposed standard, the ideas for a general method are experimental.

 RFC1034 RFC1035 UNKNOWN UNKNOWN Legacy 10.17487/RFC1101 RFC1102 Policy routing in Internet protocols D.D. Clark May 1989 ASCII HTML 22

The purpose of this RFC is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions in this document are intended as standards for the Internet.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1102 RFC1103 Proposed standard for the transmission of IP datagrams over FDDI Networks D. Katz June 1989 ASCII HTML 9

This RFC specifies a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]

 RFC1188 UNKNOWN UNKNOWN Legacy 10.17487/RFC1103 RFC1104 Models of policy based routing H.W. Braun June 1989 ASCII HTML 10

The purpose of this RFC is to outline a variety of models for policy based routing. The relative benefits of the different approaches are reviewed. Discussions and comments are explicitly encouraged to move toward the best policy based routing model that scales well within a large internetworking environment.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1104 RFC1105 Border Gateway Protocol (BGP) K. Lougheed Y. Rekhter June 1989 ASCII HTML 17 BGP

This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems. Updated by RFCs 1163 and 1164. [STANDARDS-TRACK]

 RFC1163 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1105 RFC1106 TCP big window and NAK options R. Fox June 1989 ASCII HTML 13

This memo discusses two extensions to the TCP protocol to provide a more efficient operation over a network with a high bandwidth*delay product. The extensions described in this document have been implemented and shown to work using resources at NASA. This memo describes an Experimental Protocol, these extensions are not proposed as an Internet standard, but as a starting point for further research.

 RFC6247 HISTORIC UNKNOWN Legacy 10.17487/RFC1106 RFC1107 Plan for Internet directory services K.R. Sollins July 1989 ASCII HTML 19

This memo proposes a program to develop a directory service for the Internet. It reports the results of a meeting held in February 1989, which was convened to review requirements and options for such a service. This proposal is offered for comment, and does not represent a committed research activity of the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1107 RFC1108 U.S. Department of Defense Security Options for the Internet Protocol S. Kent November 1991 ASCII HTML 17 IPSO

This RFC specifies the U.S. Department of Defense Basic Security Option and the top-level description of the Extended Security Option for use with the Internet Protocol. This RFC obsoletes RFC 1038, "Revised IP Security Option", dated January 1988. [STANDARDS-TRACK]

 RFC1038 HISTORIC HISTORIC Legacy 10.17487/RFC1108 RFC1109 Report of the second Ad Hoc Network Management Review Group V.G. Cerf August 1989 ASCII HTML 8

This RFC reports an official Internet Activities Board (IAB) policy position on the treatment of Network Management in the Internet. This RFC presents the results and recommendations of the second Ad Hoc Network Management Review on June 12, 1989. The results of the first such meeting were reported in RFC 1052.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1109 RFC1110 Problem with the TCP big window option A.M. McKenzie August 1989 ASCII HTML 3

This memo comments on the TCP Big Window option described in RFC 1106.

 RFC6247 HISTORIC UNKNOWN Legacy 10.17487/RFC1110 RFC1111 Request for comments on Request for Comments: Instructions to RFC authors J. Postel August 1989 ASCII HTML 6

This RFC specifies a standard for the Internet community. Authors of RFCs are expected to adopt and implement this standard.

 RFC0825 RFC1543 RFC2223 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1111 RFC1112 Host extensions for IP multicasting S.E. Deering August 1989 ASCII HTML 17 IGMP multicast

This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK]

 RFC0988 RFC1054 RFC2236 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1112 RFC1113 Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures J. Linn August 1989 ASCII HTML 34

This RFC specifies features for private electronic mail based on encryption technology. [STANDARDS-TRACK]

 RFC0989 RFC1040 RFC1421 HISTORIC HISTORIC Legacy 10.17487/RFC1113 RFC1114 Privacy enhancement for Internet electronic mail: Part II - certificate-based key management S.T. Kent J. Linn August 1989 ASCII HTML 25

This RFC specifies the key management aspects of Privacy Enhanced Mail. [STANDARDS-TRACK]

 RFC1422 HISTORIC HISTORIC Legacy 10.17487/RFC1114 RFC1115 Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers J. Linn August 1989 ASCII HTML 8

This RFC provides definitions, references, and citations for algorithms, usage modes, and associated identifiers used in RFC-1113 and RFC-1114 in support of privacy-enhanced electronic mail. [STANDARDS-TRACK]

 RFC1423 HISTORIC HISTORIC Legacy 10.17487/RFC1115 RFC1116 Telnet Linemode option D.A. Borman August 1989 ASCII HTML 21

Hosts on the Internet that support Linemode within the Telnet protocol are expected to adopt and implement this protocol. Obsoleted by RFC 1184. [STANDARDS-TRACK]

 RFC1184 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1116 RFC1117 Internet numbers S. Romano M.K. Stahl M. Recker August 1989 ASCII HTML 109

This memo is an official status report on the network numbers and the autonomous system numbers used in the Internet community.

 RFC1062 RFC1020 RFC0997 RFC1166 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1117 RFC1118 Hitchhikers guide to the Internet E. Krol September 1989 ASCII HTML 24

This RFC is being distributed to members of the Internet community in order to make available some "hints" which will allow new network participants to understand how the direction of the Internet is set, how to acquire online information and how to be a good Internet neighbor. While the information discussed may not be relevant to the research problems of the Internet, it may be interesting to a number of researchers and implementors. No standards are defined or specified in this memo.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1118 RFC1119 Network Time Protocol (version 2) specification and implementation D.L. Mills September 1989 ASCII PS PDF HTML 1 NTP NTPv2 time clock synchronization

This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical-master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. [STANDARDS-TRACK]

 RFC0958 RFC1059 RFC1305 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1119 RFC1120 Internet Activities Board V. Cerf September 1989 ASCII HTML 11

This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard.

 RFC1160 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1120 RFC1121 Act one - the poems J. Postel L. Kleinrock V.G. Cerf B. Boehm September 1989 ASCII HTML 6

This RFC presents a collection of poems that were presented at "Act One", a symposium held partially in celebration of the 20th anniversary of the ARPANET.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1121 RFC1122 Requirements for Internet Hosts - Communication Layers R. Braden Editor October 1989 ASCII HTML 116 applicability

This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]

 RFC0793 RFC1349 RFC4379 RFC5884 RFC6093 RFC6298 RFC6633 RFC6864 RFC8029 RFC9293 STD0003 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1122 10.17487/RFC1122 RFC1123 Requirements for Internet Hosts - Application and Support R. Braden Editor October 1989 ASCII HTML 98 applicability

This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]

 RFC0822 RFC0952 RFC1349 RFC2181 RFC5321 RFC5966 RFC7766 RFC9210 STD0003 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1123 10.17487/RFC1123 RFC1124 Policy issues in interconnecting networks B.M. Leiner September 1989 ASCII PS PDF HTML 1

To support the activities of the Federal Research Internet Coordinating Committee (FRICC) in creating an interconnected set of networks to serve the research community, two workshops were held to address the technical support of policy issues that arise when interconnecting such networks. Held under the suspices of the Internet Activities Board at the request of the FRICC, and sponsored by NASA through RIACS, the workshops addressed the required and feasible technologies and architectures that could be used to satisfy the desired policies for interconnection. The purpose of this RFC is to report the results of these workshops.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1124 RFC1125 Policy requirements for inter Administrative Domain routing D. Estrin November 1989 ASCII PS PDF HTML 21

The purpose of this memo is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions in this document are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the development and adoption of standards.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1125 RFC1126 Goals and functional requirements for inter-autonomous system routing M. Little October 1989 ASCII HTML 25

This document describes the functional requirements for a routing protocol to be used between autonomous systems. This document is intended as a necessary precursor to the design of a new inter- autonomous system routing protocol and specifies requirements for the Internet applicable for use with the current DoD IP, the ISO IP, and future Internet Protocols. It is intended that these requirements will form the basis for the future development of a new inter-autonomous systems routing architecture and protocol. This memo does not specify a standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1126 RFC1127 Perspective on the Host Requirements RFCs R.T. Braden October 1989 ASCII HTML 20

This RFC is for information only; it does not constitute a standard, draft standard, or proposed standard, and it does not define a protocol.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1127 RFC1128 Measured performance of the Network Time Protocol in the Internet system D.L. Mills October 1989 ASCII PS PDF HTML 1

This paper describes a series of experiments involving over 100,000 hosts of the Internet system and located in the U.S., Europe and the Pacific. The experiments are designed to evaluate the availability, accuracy and reliability of international standard time distribution using the DARPA/NSF Internet and the Network Time Protocol (NTP), which is specified in RFC-1119. NTP is designed specifically for use in a large, diverse internet system operating at speeds from mundane to lightwave. In NTP a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration exchange precision timestamps in order to synchronize subnet clocks to each other and national time standards via wire or radio. The experiments are designed to locate Internet hosts and gateways that provide time by one of three time distribution protocols and evaluate the accuracy of their indications. For those hosts that support NTP, the experiments determine the distribution of errors and other statistics over paths spanning major portions of the globe. Finally, the experiments evaluate the accuracy and reliability of precision timekeeping using NTP and typical Internet paths involving DARPA, NSFNET and other agency networks. The experiments demonstrate that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks. This memo does not specify a standard.

 UNKNOWN UNKNOWN Legacy 10.17487/RFC1128 RFC1129 Internet Time Synchronization: The Network Time Protocol D.L. Mills October 1989 ASCII PS PDF HTML 1 NTP

This memo describes the Network Time Protocol (NTP) designed to distribute time information in a large, diverse internet system operating at speeds from mundane to lightwave. It uses a returnable- time architecture in which a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute time information within a network via local routing algorithms and time daemons. The architectures, algorithms and protocols which have evolved to NTP over several years of implementation and refinement are described in this paper. The synchronization subnet which has been in regular operation in the Internet for the last several years is described along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks. This memo describes the Network Time Protocol in RFC-1119.

 RFC1119 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1129 RFC1130 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board October 1989 ASCII HTML 17 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).

 RFC1100 RFC1140 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1130 RFC1131 OSPF specification J. Moy October 1989 ASCII PS PDF HTML 1

This RFC is the specification of the Open Shortest Path First (OSPF) Internet routing protocol. OSPF is in the class of Internal Gateway Protocols (IGPs) for distributing routing information between gateways of a single Autonomous System. This routing protocol is based on the link-state approach (in contrast to the distance-vector approach). This specification was developed by the OSPF Working Group of the Internet Engineering Task Force. [STANDARDS-TRACK]

 RFC1247 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1131 RFC1132 Standard for the transmission of 802.2 packets over IPX networks L.J. McLaughlin November 1989 ASCII HTML 4 IP-IPX

This document specifies a standard method of encapsulating 802.2 packets on networks supporting Novell's Internet Packet Exchange Protocol (IPX). It obsoletes earlier documents detailing the transmission of Internet packets over IPX networks. It differs from these earlier documents in that it allows for the transmission of multiple network protocols over IPX and for the transmission of packets through IPX bridges.

 STD0049 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1132 RFC1133 Routing between the NSFNET and the DDN J.Y. Yu H.W. Braun November 1989 ASCII HTML 10

This document is a case study of the implementation of routing between the NSFNET and the DDN components (the MILNET and the ARPANET). We hope that it can be used to expand towards interconnection of other Administrative Domains. We would welcome discussion and suggestions about the methods employed for the interconnections. No standards are specified in this memo.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1133 RFC1134 Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links D. Perkins November 1989 ASCII HTML 38

This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the IETF Point-to-Point Protocol Working Group chair by January 15, 1990. Comments will be reviewed at the February 1990 IETF meeting, with the goal of advancing PPP to draft standard status. [STANDARDS-TRACK]

 RFC1171 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1134 RFC1135 Helminthiasis of the Internet J.K. Reynolds December 1989 ASCII HTML 33

This memo takes a look back at the helminthiasis (infestation with, or disease caused by parasitic worms) of the Internet that was unleashed the evening of 2 November 1988. This RFC provides information about an event that occurred in the life of the Internet. This memo does not specify any standard. This document provides a glimpse at the infection, its festering, and cure. The impact of the worm on the Internet community, ethics statements, the role of the news media, crime in the computer world, and future prevention is discussed. A documentation review presents four publications that describe in detail this particular parasitic computer program. Reference and bibliography sections are also included.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1135 RFC1136 Administrative Domains and Routing Domains: A model for routing in the Internet S. Hares D. Katz December 1989 ASCII HTML 10

This RFC proposes a model for describing routing within the Internet. The model is an adaptation of the "OSI Routeing Framework". This memo does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1136 RFC1137 Mapping between full RFC 822 and RFC 822 with restricted encoding S. Kille December 1989 ASCII HTML 3

This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard.

 RFC0976 HISTORIC HISTORIC Legacy 10.17487/RFC1137 RFC1138 Mapping between X.400(1988) / ISO 10021 and RFC 822 S.E. Kille December 1989 ASCII HTML 92

Ths RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This memo updates RFCs 822, 987, and 1026.

 RFC2156 RFC1327 RFC1026 RFC0987 RFC0822 RFC1148 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1138 10.17487/RFC1138 RFC1139 Echo function for ISO 8473 R.A. Hagens January 1990 ASCII HTML 6

This memo defines an echo function for the connection-less network layer protocol. Two mechanisms are introduced that may be used to implement the echo function. The first mechanism is recommended as an interim solution for the Internet community. The second mechanism will be progressed to the ANSI X3S3.3 working group for consideration as a work item. When an ISO standard is adopted that provides functionality similar to that described by this memo, then this memo will become obsolete and superceded by the ISO standard. This memo is not intended to compete with an ISO standard. [STANDARDS-TRACK]

 RFC1574 RFC1575 PROPOSED STANDARD PROPOSED STANDARD IETF osigen 10.17487/RFC1139 RFC1140 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board May 1990 ASCII HTML 27 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority. Do not use this edition after 31-Aug-90.

 RFC1130 RFC1200 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1140 RFC1141 Incremental updating of the Internet checksum T. Mallory A. Kullberg January 1990 ASCII HTML 2

This memo correctly describes the incremental update procedure for use with the standard Internet checksum. It is intended to replace the description of Incremental Update in RFC 1071. This is not a standard but rather, an implementation technique.

 RFC1071 RFC1624 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1141 10.17487/RFC1141 RFC1142 OSI IS-IS Intra-domain Routing Protocol D. Oran Editor February 1990 ASCII PS PDF HTML 517 Domain Routing ISO

This RFC is a republication of ISO DP 10589 as a service to the Internet community. This is not an Internet standard.

 RFC7142 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1142 RFC1143 The Q Method of Implementing TELNET Option Negotiation D.J. Bernstein February 1990 ASCII HTML 10

This is RFC discusses an implementation approach to option negotiation in the Telnet protocol (RFC 854). It does not propose any changes to the TELNET protocol. Rather, it discusses the implementation of the protocol of one feature, only. This is not a protocol specification. This is an experimental method of implementing a protocol.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1143 RFC1144 Compressing TCP/IP Headers for Low-Speed Serial Links V. Jacobson February 1990 ASCII PS PDF HTML 49 IP-CMPRS

This RFC describes a method for compressing the headers of TCP/IP datagrams to improve performance over low speed serial links. The motivation, implementation and performance of the method are described. C code for a sample implementation is given for reference. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1144 RFC1145 TCP alternate checksum options J. Zweig C. Partridge February 1990 ASCII HTML 5

This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use.

 RFC1146 RFC6247 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1145 RFC1146 TCP alternate checksum options J. Zweig C. Partridge March 1990 ASCII HTML 5 TCP-ACO

This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use. Note: This RFC corrects errors introduced in the editing process in RFC 1145.

 RFC1145 RFC6247 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1146 RFC1147 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices R.H. Stine April 1990 ASCII PS PDF HTML 177

The goal of this FYI memo is to provide practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations. [Also FYI 2.] This catalog contains descriptions of several tools available to assist network managers in debugging and maintaining TCP/IP internets and interconnected communications resources. Entries in the catalog tell what a tool does, how it works, and how it can be obtained.

 RFC1470 INFORMATIONAL INFORMATIONAL IETF noctools 10.17487/RFC1147 RFC1148 Mapping between X.400(1988) / ISO 10021 and RFC 822 S.E. Kille March 1990 ASCII HTML 94

This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This edition includes material lost in editing.

 RFC2156 RFC1327 RFC1026 RFC0987 RFC1138 RFC0822 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1148 10.17487/RFC1148 RFC1149 Standard for the transmission of IP datagrams on avian carriers D. Waitzman April 1 1990 ASCII HTML 2 avian carrier april fools

This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers. This specification is primarily useful in Metropolitan Area Networks. This is an experimental, not recommended standard.

 RFC2549 RFC6214 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1149 10.17487/RFC1149 RFC1150 FYI on FYI: Introduction to the FYI Notes G.S. Malkin J.K. Reynolds March 1990 ASCII HTML 4

This memo is the first in a new sub-series of RFCs called FYIs (For Your Information). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 1.]

 RFC6360 HISTORIC INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1150 10.17487/RFC1150 RFC1151 Version 2 of the Reliable Data Protocol (RDP) C. Partridge R.M. Hinden April 1990 ASCII HTML 4 RDP

This RFC suggests several updates to the specification of the Reliable Data Protocol (RDP) in RFC-908 based on experience with the protocol. This revised version of the protocol is experimental.

 RFC0908 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1151 RFC1152 Workshop report: Internet research steering group workshop on very-high-speed networks C. Partridge April 1990 ASCII HTML 23

This memo is a report on a workshop sponsored by the Internet Research Steering Group. This memo is for information only. This RFC does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1152 RFC1153 Digest message format F.J. Wancho April 1990 ASCII HTML 4 DMF-MAIL

This memo describes the de facto standard Digest Message Format. This is an elective experimental protocol.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1153 RFC1154 Encoding header field for internet messages D. Robinson R. Ullmann April 1990 ASCII HTML 7

This RFC proposes an elective experimental Encoding header field to permit the mailing of multi-part, multi-structured messages. The use of Encoding updates RFC 1049 (Content-Type), and is a suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement).

 RFC1505 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1154 RFC1155 Structure and identification of management information for TCP/IP-based internets M.T. Rose K. McCloghrie May 1990 ASCII HTML 22 SMI

This RFC is a re-release of RFC 1065, with a changed "Status of this Memo", plus a few minor typographical corrections. The technical content of the document is unchanged from RFC 1065. [STANDARDS-TRACK]

 RFC1065 STD0016 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1155 10.17487/RFC1155 RFC1156 Management Information Base for network management of TCP/IP-based internets K. McCloghrie M.T. Rose May 1990 ASCII HTML 91 MIB-I

This RFC is a re-release of RFC 1066, with a changed "Status of this Memo", "IAB Policy Statement", and "Introduction" sections plus a few minor typographical corrections. The technical content of the document is unchanged from RFC 1066. [STANDARDS-TRACK]

 RFC1066 HISTORIC HISTORIC Legacy 10.17487/RFC1156 RFC1157 Simple Network Management Protocol (SNMP) J.D. Case M. Fedor M.L. Schoffstall J. Davin May 1990 ASCII HTML 36 SNMP

This RFC is a re-release of RFC 1098, with a changed "Status of this Memo" section plus a few minor typographical corrections. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. [STANDARDS-TRACK]

 RFC1098 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1157 RFC1158 Management Information Base for network management of TCP/IP-based internets: MIB-II M.T. Rose May 1990 ASCII HTML 133

This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets. In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP- based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community. This document on MIB-II incorporates all of the technical content of RFC 1156 on MIB-I and extends it, without loss of compatibilty. [STANDARDS-TRACK]

 RFC1213 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1158 10.17487/RFC1158 RFC1159 Message Send Protocol R. Nelson June 1990 ASCII HTML 2

This RFC suggests an Experimental Protocol for the Internet community. Hosts on the Internet that choose to implement a Message Send Protocol may experiment with this protocol.

 RFC1312 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1159 RFC1160 Internet Activities Board V. Cerf May 1990 ASCII HTML 11

This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard. This is a revision of RFC 1120.

 RFC1120 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1160 RFC1161 SNMP over OSI M.T. Rose June 1990 ASCII HTML 8

This memo defines an experimental means for running the Simple Network Management Protocol (SNMP) over OSI transports. This memo does not specify a standard for the Internet community,

 RFC1418 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1161 RFC1162 Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base G. Satz June 1990 ASCII HTML 70

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This memo does not specify a standard for the Internet community.

 RFC1238 EXPERIMENTAL EXPERIMENTAL IETF snmp 10.17487/RFC1162 RFC1163 Border Gateway Protocol (BGP) K. Lougheed Y. Rekhter June 1990 ASCII HTML 29 BGP

This RFC, together with its companion RFC-1164, "Application of the Border Gateway Protocol in the Internet", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

 RFC1105 RFC1267 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1163 RFC1164 Application of the Border Gateway Protocol in the Internet J.C. Honig D. Katz M. Mathis Y. Rekhter J.Y. Yu June 1990 ASCII HTML 23 BGP

This RFC, together with its companion RFC-1163, "A Border Gateway Protocol (BGP)", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

 RFC1268 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1164 RFC1165 Network Time Protocol (NTP) over the OSI Remote Operations Service J. Crowcroft J.P. Onions June 1990 ASCII HTML 10 NTP-OSI

This memo suggests an Experimental Protocol for the OSI and Internet communities. Hosts in either community, and in particular those on both are encouraged to experiment with this mechanism.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1165 RFC1166 Internet numbers S. Kirkpatrick M.K. Stahl M. Recker July 1990 ASCII HTML 182

This memo is a status report on the network numbers and autonomous system numbers used in the Internet community.

 RFC1117 RFC1062 RFC1020 RFC5737 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1166 RFC1167 Thoughts on the National Research and Education Network V.G. Cerf July 1990 ASCII HTML 8

The memo provides a brief outline of a National Research and Education Network (NREN). This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1167 RFC1168 Intermail and Commercial Mail Relay services A. Westine A.L. DeSchon J. Postel C.E. Ward July 1990 ASCII PS PDF HTML 18

This RFC discusses the history and evolution of the Intermail and Commercial mail systems. The problems encountered in operating a store-and-forward mail relay between commercial systems such as Telemail, MCI Mail and Dialcom are also discussed. This RFC provides information for the Internet community, and does not specify any standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1168 RFC1169 Explaining the role of GOSIP V.G. Cerf K.L. Mills August 1990 ASCII HTML 15

This informational RFC represents the official view of the Internet Activities Board (IAB), after coordination with the Federal Networking Council (FNC). This RFC does not specify a standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1169 RFC1170 Public key standards and licenses R.B. Fougner January 1991 ASCII HTML 2

This RFC is a public statement by Public Key Partners regarding Public Key Standards and Licenses. This memo is for informational use only, and does not constitute an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1170 RFC1171 Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links D. Perkins July 1990 ASCII HTML 51

This memo specifies the Point-to-Point Protocol (PPP) as a Draft Standard Protocol for the Internet community. When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links.

 RFC1134 RFC1331 DRAFT STANDARD DRAFT STANDARD IETF int ppp 10.17487/RFC1171 RFC1172 Point-to-Point Protocol (PPP) initial configuration options D. Perkins R. Hobby July 1990 ASCII HTML 40

This memo specifies the Point-to-Point Protocol (PPP) Initial Configuration Options as a Proposed Standard Protocol for the Internet community. When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links.

 RFC1331 RFC1332 PROPOSED STANDARD PROPOSED STANDARD IETF int ppp http://www.rfc-editor.org/errata_search.php?rfc=1172 10.17487/RFC1172 RFC1173 Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet J. VanBokkelen August 1990 ASCII HTML 5

This informational RFC describes the conventions to be followed by those in charge of networks and hosts in the Internet. It is a summary of the "oral tradition" of the Internet on this subject. [RFC Editor's note: This memo is a contribution by the author of his view of these conventions. It is expected that this RFC will provide a basis for the development of official policies in the future.] These conventions may be supplemented or amended by the policies of specific local and regional components of the Internet. This RFC does not specify a standard, or a policy of the IAB.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1173 RFC1174 IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet "connected" status V.G. Cerf August 1990 ASCII HTML 9

This informational RFC represents the official view of the Internet Activities Board (IAB), and describes the recommended policies and procedures on distributing Internet identifier assignments and dropping the connected status requirement. This RFC does not specify a standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1174 RFC1175 FYI on where to start: A bibliography of internetworking information K.L. Bowers T.L. LaQuey J.K. Reynolds K. Roubicek M.K. Stahl A. Yuan August 1990 ASCII HTML 43

This FYI RFC is a bibliography of information about TCP/IP internetworking, prepared by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 3.]

 FYI0003 INFORMATIONAL INFORMATIONAL IETF userdoc 10.17487/RFC1175 RFC1176 Interactive Mail Access Protocol: Version 2 M.R. Crispin August 1990 ASCII HTML 30 IMAP2

This RFC suggests a method for personal computers and workstations to dynamically access mail from a mailbox server ("repository"). It obosoletes RFC 1064. This RFC specifies an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

 RFC1064 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1176 RFC1177 FYI on Questions and Answers: Answers to commonly asked "new internet user" questions G.S. Malkin A.N. Marine J.K. Reynolds August 1990 ASCII HTML 24

This FYI RFC is one of three FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 4.]

 RFC1206 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1177 RFC1178 Choosing a name for your computer D. Libes August 1990 ASCII HTML 8

This FYI RFC is a republication of a Communications of the ACM article on guidelines on what to do and what not to do when naming your computer. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 5.]

 FYI0005 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1178 RFC1179 Line printer daemon protocol L. McLaughlin August 1990 ASCII HTML 14 LPDP

This RFC describes an existing print server protocol widely used on the Internet for communicating between line printer daemons (both clients and servers). This memo is for informational purposes only, and does not specify an Internet standard. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1179 RFC1180 TCP/IP tutorial T.J. Socolofsky C.J. Kale January 1991 ASCII HTML 28

This RFC is a tutorial on the TCP-IP protocol suite, focusing particularly on the steps in forwarding an IP datagram from source host to destination host through a router. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1180 10.17487/RFC1180 RFC1181 RIPE Terms of Reference R. Blokzijl September 1990 ASCII HTML 2

This RFC describes the Terms of Reference of RIPE (Reseaux IP Europeens), the cooperation of European IP networks. This memo provides information for the Internet community. It does not specify any standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1181 RFC1182 RFC1183 New DNS RR Definitions C. Everhart L. Mamakos R. Ullmann P. Mockapetris Editor October 1990 ASCII HTML 11 DNS-RR

This memo defines five new DNS types for experimental purposes. This RFC describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements.

 RFC1034 RFC1035 RFC5395 RFC5864 RFC6195 RFC6895 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1183 10.17487/RFC1183 RFC1184 Telnet Linemode Option D.A. Borman October 1990 ASCII HTML 23 TOPT-LINE

This RFC specifies a procedure for line at a time terminal interaction based on the Telnet Protocol. It obsoletes RFC 1116. [STANDARDS-TRACK]

 RFC1116 DRAFT STANDARD DRAFT STANDARD IETF app telnet 10.17487/RFC1184 RFC1185 TCP Extension for High-Speed Paths V. Jacobson R.T. Braden L. Zhang October 1990 ASCII HTML 21

This memo describes an Experimental Protocol extension to TCP for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

 RFC1323 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1185 RFC1186 MD4 Message Digest Algorithm R.L. Rivest October 1990 ASCII HTML 18

This RFC is the specification of the MD4 Digest Algorithm. If you are going to implement MD4, it is suggested you do it this way. This memo is for informational use and does not constitute a standard.

 RFC1320 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1186 RFC1187 Bulk Table Retrieval with the SNMP M.T. Rose K. McCloghrie J.R. Davin October 1990 ASCII HTML 12 SNMP-BULK

This memo reports an interesting family of algorithms for bulk table retrieval using the Simple Network Management Protocol (SNMP). This memo describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements. This memo does not specify a standard for the Internet community. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1187 RFC1188 Proposed Standard for the Transmission of IP Datagrams over FDDI Networks D. Katz October 1990 ASCII HTML 11

This memo defines a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]

 RFC1103 DRAFT STANDARD DRAFT STANDARD IETF int fddi 10.17487/RFC1188 RFC1189 Common Management Information Services and Protocols for the Internet (CMOT and CMIP) U.S. Warrier L. Besaw L. LaBarre B.D. Handspicker October 1990 ASCII HTML 15 CMOT

This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in the Internet. [STANDARDS-TRACK]

 RFC1095 HISTORIC HISTORIC IETF oim 10.17487/RFC1189 RFC1190 Experimental Internet Stream Protocol: Version 2 (ST-II) C. Topolcic October 1990 ASCII HTML 148

This memo defines a revised version of the Internet Stream Protocol, originally defined in IEN-119 [8], based on results from experiments with the original version, and subsequent requests, discussion, and suggestions for improvements. This is a Limited-Use Experimental Protocol. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

 IEN119 RFC1819 EXPERIMENTAL EXPERIMENTAL IETF int cip 10.17487/RFC1190 RFC1191 Path MTU discovery J. Mogul S. Deering November 1990 ASCII HTML 19 IP-MTU

This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK]

 RFC1063 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1191 RFC1192 Commercialization of the Internet summary report B. Kahin November 1990 ASCII HTML 13

This memo is based on a workshop held by the Science, Technology and Public Policy Program of the John F. Kennedy School of Government, Harvard University, March 1-3, 1990. This memo provides information for the Internet community. It does not specify any standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1192 RFC1193 Client requirements for real-time communication services D. Ferrari November 1990 ASCII HTML 24

This memo describes client requirements for real-time communication services. This memo provides information for the Internet community, and requests discussion and suggestions for improvements. It does not specify any standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1193 RFC1194 Finger User Information Protocol D.P. Zimmerman November 1990 ASCII HTML 12

This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. [STANDARDS-TRACK]

 RFC0742 RFC1196 RFC1288 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1194 RFC1195 Use of OSI IS-IS for routing in TCP/IP and dual environments R. Callon December 1990 ASCII PS HTML 85 IS-IS

This memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK]

 RFC1349 RFC5302 RFC5304 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1195 10.17487/RFC1195 RFC1196 Finger User Information Protocol D.P. Zimmerman December 1990 ASCII HTML 12

This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. This edition corrects and clarifies in a minor way, RFC 1194. [STANDARDS-TRACK]

 RFC1194 RFC0742 RFC1288 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1196 RFC1197 Using ODA for translating multimedia information M. Sherman December 1990 ASCII HTML 2

The purpose of this RFC is to inform implementors of multimedia systems about our experiences using ISO 8613: Office Document Architecture (ODA). Because ODA is being proposed as an encoding format for use in multimedia mail and file exchange, implementors wishing to use ODA in an open systems environment may profit from our experiences. This memo provides information for the Internet community. It does not specify any standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1197 RFC1198 FYI on the X window system R.W. Scheifler January 1991 ASCII HTML 3

This FYI RFC provides pointers to the published standards of the MIT X Consortium. This memo provides information for the Internet community. It does not specify any Internet standard.

 FYI0006 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1198 RFC1199 Request for Comments Summary Notes: 1100-1199 J. Reynolds December 1991 ASCII HTML 22 Summary RFC INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1199 RFC1200 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board April 1991 ASCII HTML 31 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information.

 RFC1140 RFC1250 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1200 RFC1201 Transmitting IP traffic over ARCNET networks D. Provan February 1991 ASCII HTML 7 IP-ARC

This memo defines a protocol for the transmission of IP and ARP packets over the ARCnet Local Area Network.This memo specifies a method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams for transmission across ARCNET using the "ARCNET Packet Header Definition Standard". [STANDARDS-TRACK]

 RFC1051 STD0046 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1201 RFC1202 Directory Assistance service M.T. Rose February 1991 ASCII HTML 11 DAS

This document defines a mechanism by which a user-interface may access a textual DAP-like interface over a TCP/IP connection. This is a local mechanism. This memo provides information for the Internet community. It does not specify any standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1202 RFC1203 Interactive Mail Access Protocol: Version 3 J. Rice February 1991 ASCII HTML 49 IMAP3

This RFC suggests a method for workstations to access mail dynamically from a mailbox server ("repository"). The following document is a modified version of RFC 1064, the definition of the IMAP2 protocol. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.

 RFC1064 HISTORIC HISTORIC Legacy 10.17487/RFC1203 RFC1204 Message Posting Protocol (MPP) S. Yeh D. Lee February 1991 ASCII HTML 6 MPP

This memo describes a protocol for posting messages from workstations (e.g., PCs) to a mail service host. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1204 RFC1205 5250 Telnet interface P. Chmielewski February 1991 ASCII HTML 12

This RFC is being distributed in order to document the interface to the IBM 5250 Telnet implementation. This memo provides information for the Internet community. It does not specify any standard.

 RFC2877 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1205 RFC1206 FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions G.S. Malkin A.N. Marine February 1991 ASCII HTML 32

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [FYI 4]

 RFC1177 RFC1325 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1206 RFC1207 FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions G.S. Malkin A.N. Marine J.K. Reynolds February 1991 ASCII HTML 15

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard.

 FYI0007 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1207 RFC1208 A Glossary of Networking Terms O.J. Jacobsen D.C. Lynch March 1991 ASCII HTML 18

This RFC is a glossary adapted from "The INTEROP Pocket Glossary of Networking Terms" distributed at Interop '90. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1208 RFC1209 The Transmission of IP Datagrams over the SMDS Service D. Piscitello J. Lawrence March 1991 ASCII HTML 11 IP-SMDS Switched Multi-megabit Data Service

This memo defines a protocol for the transmission of IP and ARP packets over a Switched Multi-megabit Data Service Network configured as a logical IP subnetwork. [STANDARDS-TRACK]

 STD0052 INTERNET STANDARD INTERNET STANDARD IETF int smds 10.17487/RFC1209 RFC1210 Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990 V.G. Cerf P.T. Kirstein B. Randell March 1991 ASCII HTML 36

This report complements a shorter printed version which appeared in a summary report of all the committees which met in Brussels and Washington last July, 1990. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1210 RFC1211 Problems with the maintenance of large mailing lists A. Westine J. Postel March 1991 ASCII HTML 54

This RFC discusses problems with maintaining large mailing lists, especially the processing of error reports. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1211 RFC1212 Concise MIB definitions M.T. Rose K. McCloghrie March 1991 ASCII HTML 19 Concise-MIB

This memo describes a straight-forward approach toward producing concise, yet descriptive, MIB modules. This memo defines a format for producing MIB modules. [STANDARDS-TRACK]

 STD0016 INTERNET STANDARD INTERNET STANDARD IETF snmp 10.17487/RFC1212 RFC1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II K. McCloghrie M. Rose March 1991 ASCII HTML 70 MIB-II

This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]

 RFC1158 RFC2011 RFC2012 RFC2013 STD0017 INTERNET STANDARD INTERNET STANDARD IETF snmp 10.17487/RFC1213 RFC1214 OSI internet management: Management Information Base L. LaBarre April 1991 ASCII HTML 83 OIM-MIB-II

This RFC documents a MIB for use with CMIP, either over pure OSI stacks or with the CMIP over TCP specification. It redefines objects comprised by the second revision of the Management Information Base for Network Management of TCP/IP-based internets: MIB-II so as to conform to the OSI structure of management information. [STANDARDS-TRACK]

 HISTORIC HISTORIC IETF oim 10.17487/RFC1214 RFC1215 Convention for defining traps for use with the SNMP M.T. Rose March 1991 ASCII HTML 9 SNMP-TRAPS

This memo suggests a straight-forward approach towards defining traps used with the SNMP. This memo provides information for the Internet community. It does not specify any standard.

 INFORMATIONAL INFORMATIONAL IETF snmp 10.17487/RFC1215 RFC1216 Gigabit network economics and paradigm shifts P. Richard P. Kynikos April 1 1991 ASCII HTML 4

This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track. [STANDARDS-TRACK]

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1216 RFC1217 Memo from the Consortium for Slow Commotion Research (CSCR) V.G. Cerf April 1 1991 ASCII HTML 5

This RFC is in response to RFC 1216, "Gigabit Network Economics and Paradigm Shifts". This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1217 RFC1218 Naming scheme for c=US North American Directory Forum April 1991 ASCII HTML 23

This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1255 RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1218 RFC1219 On the assignment of subnet numbers P.F. Tsuchiya April 1991 ASCII HTML 13 SUBNETASGN

This memo suggests a new procedure for assigning subnet numbers. Use of this assignment technique within a network would be a purely local matter, and would not effect other networks. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1219 RFC1220 Point-to-Point Protocol extensions for bridging F. Baker April 1991 ASCII HTML 18

This document defines an extension of the Internet Point-to-Point Protocol (PPP) described in RFC 1171, targeting the use of Point-to- Point lines for Remote Bridging. [STANDARDS-TRACK]

 RFC1638 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1220 RFC1221 Host Access Protocol (HAP) specification: Version 2 W. Edmond April 1991 ASCII HTML 68 HAP2

This memo describes the Host Access Protocol implemented in the Terrestrial Wideband Network (TWBNET). This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC0907 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1221 RFC1222 Advancing the NSFNET routing architecture H.W. Braun Y. Rekhter May 1991 ASCII HTML 6

This RFC suggests improvements in the NSFNET routing architecture to accommodate a more flexible interface to the Backbone clients. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1222 RFC1223 OSI CLNS and LLC1 protocols on Network Systems HYPERchannel J.M. Halpern May 1991 ASCII HTML 12 OSI-HYPER

The intent of this document is to provide a complete discussion of the protocols and techniques used to transmit OSI CLNS and LLC1 datagrams (and any associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment.This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1223 RFC1224 Techniques for managing asynchronously generated alerts L. Steinberg May 1991 ASCII HTML 22 ALERTS

This memo defines common mechanisms for managing asynchronously produced alerts in a manner consistent with current network management protocols. This memo specifies an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 EXPERIMENTAL EXPERIMENTAL IETF alertman 10.17487/RFC1224 RFC1225 Post Office Protocol: Version 3 M.T. Rose May 1991 ASCII HTML 16

This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. [STANDARDS-TRACK]

 RFC1081 RFC1460 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1225 RFC1226 Internet protocol encapsulation of AX.25 frames B. Kantor May 1991 ASCII HTML 2 IP-AX.25

This memo describes a method for the encapsulation of AX.25 (the Amateur Packet-Radio Link-Layer Protocol) frames within IP packets. This technique is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1226 RFC1227 SNMP MUX protocol and MIB M.T. Rose May 1991 ASCII HTML 13 SNMP-MUX

This memo suggests a mechanism by which a user process may associate itself with the local SNMP agent on a host, in order to implement portions of the MIB. This mechanism would be local to the host.This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 HISTORIC HISTORIC Legacy http://www.rfc-editor.org/errata_search.php?rfc=1227 10.17487/RFC1227 RFC1228 SNMP-DPI: Simple Network Management Protocol Distributed Program Interface G. Carpenter B. Wijnen May 1991 ASCII HTML 50

This RFC describes a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 RFC1592 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1228 RFC1229 Extensions to the generic-interface MIB K. McCloghrie May 1991 ASCII HTML 16

This RFC contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. [STANDARDS-TRACK]

 RFC1573 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1229 RFC1230 IEEE 802.4 Token Bus MIB K. McCloghrie R. Fox May 1991 ASCII HTML 23 802.4-MIP

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.4 Token Bus technology described in 802.4 Token-Passing Bus Access Method and Physical Layer Specifications, IEEE Standard 802.4. [STANDARDS-TRACK]

 RFC1239 HISTORIC HISTORIC IETF snmp 10.17487/RFC1230 RFC1231 IEEE 802.5 Token Ring MIB K. McCloghrie R. Fox E. Decker May 1991 ASCII HTML 23

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]

 RFC1743 RFC1748 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1231 RFC1232 Definitions of managed objects for the DS1 Interface type F. Baker C.P. Kolb May 1991 ASCII HTML 28 RFC1406 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1232 RFC1233 Definitions of managed objects for the DS3 Interface type T.A. Cox K. Tesink May 1991 ASCII HTML 23

This memo defines objects for managing DS3 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]

 RFC1407 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1233 RFC1234 Tunneling IPX traffic through IP networks D. Provan June 1991 ASCII HTML 6 IPX-IP

This memo describes a method of encapsulating IPX datagrams within UDP packets so that IPX traffic can travel across an IP internet. [STANDARDS-TRACK] This memo defines objects for managing DS1 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1234 RFC1235 Coherent File Distribution Protocol J. Ioannidis G. Maguire June 1991 ASCII HTML 12 CFDP

This memo describes the Coherent File Distribution Protocol (CFDP). This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1235 RFC1236 IP to X.121 address mapping for DDN L. Morales P. Hasse June 1991 ASCII HTML 7 IP-X.121

This memo defines a standard way of converting IP addresses to CCITT X.121 addresses and is the recommended standard for use on the Internet, specifically for the Defense Data Network (DDN). This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1236 RFC1237 Guidelines for OSI NSAP Allocation in the Internet R. Colella E. Gardner R. Callon July 1991 ASCII PS PDF HTML 48

This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK]

 RFC1629 PROPOSED STANDARD PROPOSED STANDARD IETF osinsap 10.17487/RFC1237 RFC1238 CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) G. Satz June 1991 ASCII HTML 32 CLNS-MIB

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 RFC1162 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1238 RFC1239 Reassignment of experimental MIBs to standard MIBs J.K. Reynolds June 1991 ASCII HTML 2 STD-MIBs

This memo specifically updates RFC 1229, RFC 1230, RFC 1231, RFC 1232 and RFC 1233 with new codes. [STANDARDS-TRACK]

 RFC1229 RFC1230 RFC1231 RFC1232 RFC1233 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1239 RFC1240 OSI connectionless transport services on top of UDP: Version 1 C. Shue W. Haggerty K. Dobbins June 1991 ASCII HTML 8 OSI-UDP

This document describes a protocol for running OSI Connectionless service on UDP. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1240 RFC1241 Scheme for an internet encapsulation protocol: Version 1 R.A. Woodburn D.L. Mills July 1991 ASCII PS PDF HTML 17 IN-ENCAP

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1241 RFC1242 Benchmarking Terminology for Network Interconnection Devices S. Bradner July 1991 ASCII HTML 12

This memo discusses and defines a number of terms that are used in describing performance benchmarking tests and the results of such tests. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC6201 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC1242 RFC1243 AppleTalk Management Information Base S. Waldbusser July 1991 ASCII HTML 29

This memo defines objects for managing AppleTalk objects for use with the SNMP protocol. [STANDARDS-TRACK]

 RFC1742 PROPOSED STANDARD PROPOSED STANDARD IETF int appleip 10.17487/RFC1243 RFC1244 Site Security Handbook J.P. Holbrook J.K. Reynolds July 1991 ASCII HTML 101

This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. This FYI RFC provides information for the Internet community. It does not specify an Internet standard. [FYI 8]

 RFC2196 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1244 RFC1245 OSPF Protocol Analysis J. Moy July 1991 ASCII PS PDF HTML 12 OSPF SPF routing TOS LSA flooding

This report attempts to summarize the key features of OSPF V2. It also attempts to analyze how the protocol will perform and scale in the Internet. This memo provides information for the Internet community. It does not specify any Internet standard.

 RFC1246 RFC1247 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC1245 RFC1246 Experience with the OSPF Protocol J. Moy July 1991 ASCII PS PDF HTML 31 OSPF SPF routing MIB experience testing

This report documents experience with OSPF V2. This includes reports on interoperability testing, field experience, simulations and the current state of OSPF implementations. This memo provides information for the Internet community. It does not specify any Internet standard.

 RFC1245 RFC1247 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC1246 RFC1247 OSPF Version 2 J. Moy July 1991 ASCII PS PDF HTML 189 equal-cost multipath link state LSA

This memo documents version 2 of the OSPF protocol. OSPF is a link- state based routing protocol. [STANDARDS-TRACK]

 RFC1131 RFC1583 RFC1349 RFC1245 RFC1246 DRAFT STANDARD DRAFT STANDARD IETF rtg ospf 10.17487/RFC1247 RFC1248 OSPF Version 2 Management Information Base F. Baker R. Coltun July 1991 ASCII HTML 42 OSPF SPF MIB routing network management

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]

 RFC1252 RFC1349 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1248 RFC1249 DIXIE Protocol Specification T. Howes M. Smith B. Beecher August 1991 ASCII HTML 10 DIXIE DIXIE protocol directory services X.500 DAP

This RFC defines a mechanism by which TCP/UDP based clients can access OSI Directory Service without the overhead of the ISO transport and presentation protocols required to implement full-blown DAP. This memo provides information for the Internet community. It does not specify any standard.

 RFC1202 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1249 RFC1250 IAB Official Protocol Standards J. Postel August 1991 ASCII HTML 28 standards protocol IAB

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1200 RFC2200 RFC1280 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1250 RFC1251 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members G. Malkin August 1991 ASCII HTML 26 IESG IRSG IAB

This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 9]

 RFC1336 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1251 RFC1252 OSPF Version 2 Management Information Base F. Baker R. Coltun August 1991 ASCII HTML 42 OSPF SPF MIB routing network management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]

 RFC1248 RFC1253 RFC1245 RFC1247 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC1252 RFC1253 OSPF Version 2 Management Information Base F. Baker R. Coltun August 1991 ASCII HTML 42

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]

 RFC1252 RFC1850 RFC1245 RFC1246 RFC1247 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1253 RFC1254 Gateway Congestion Control Survey A. Mankin K. Ramakrishnan August 1991 ASCII HTML 25 gateway congestion SQ source quench fiar queueing random drop

The purpose of this paper is to present a review of the congestion control approaches, as a way of encouraging new discussion and experimentation. Included in the survey are Source Quench, Random Drop, Congestion Indication (DEC Bit), and Fair Queueing.

 INFORMATIONAL INFORMATIONAL IETF int pcc 10.17487/RFC1254 RFC1255 A Naming Scheme for c=US The North American Directory Forum September 1991 ASCII HTML 25 naming NADF X.500 directory services c=us

This memo documents the NADF's agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1218 RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1255 RFC1256 ICMP Router Discovery Messages S. Deering Editor September 1991 ASCII HTML 19 ICMP-ROUT ICMP router gateway discovery standard protocol

This document specifies an extension of the Internet Control Message Protocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int rdisc 10.17487/RFC1256 RFC1257 Isochronous applications do not require jitter-controlled networks C. Partridge September 1991 ASCII HTML 5

This memo argues that jitter control is not required for networks to support isochronous applications. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1257 RFC1258 BSD Rlogin B. Kantor September 1991 ASCII HTML 5

The rlogin facility provides a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output.This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1282 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1258 10.17487/RFC1258 RFC1259 Building the open road: The NREN as test-bed for the national public network M. Kapor September 1991 ASCII HTML 23 NREN test-bed network policy

This memo discusses the background and importance of NREN. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1259 RFC1260 RFC1261 Transition of Nic Services S. Williamson L. Nobile September 1991 ASCII HTML 3 NIC transition

This memo outlines the transition of NIC Services. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1261 RFC1262 Guidelines for Internet Measurement Activities V.G. Cerf October 1991 ASCII HTML 3

This RFC represents IAB guidance for researchers considering measurement experiments on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1262 RFC1263 TCP Extensions Considered Harmful S. O'Malley L.L. Peterson October 1991 ASCII HTML 19

This RFC comments on recent proposals to extend TCP. It argues that the backward compatible extensions proposed in RFC's 1072 and 1185 should not be pursued, and proposes an alternative way to evolve the Internet protocol suite. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1263 RFC1264 Internet Engineering Task Force Internet Routing Protocol Standardization Criteria R.M. Hinden October 1991 ASCII HTML 8

This informational RFC presents procedures for creating and documenting Internet standards on routing protocols. These procedures have been established by the Internet Activities Board (IAB) in consultation with the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. It does not specifiy an Internet standard.

 RFC4794 HISTORIC INFORMATIONAL IETF IESG 10.17487/RFC1264 RFC1265 BGP Protocol Analysis Y. Rekhter October 1991 ASCII HTML 8

This report summarizes the key feature of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1265 RFC1266 Experience with the BGP Protocol Y. Rekhter October 1991 ASCII HTML 9

The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol (BGP). This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1266 RFC1267 Border Gateway Protocol 3 (BGP-3) K. Lougheed Y. Rekhter October 1991 ASCII HTML 35 BGP3

This memo, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

 RFC1163 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1267 RFC1268 Application of the Border Gateway Protocol in the Internet Y. Rekhter P. Gross October 1991 ASCII HTML 13 BGP3

This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK]

 RFC1164 RFC1655 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1268 RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 S. Willis J.W. Burruss October 1991 ASCII HTML 13 BGP-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Border Gateway Protocol. [STANDARDS-TRACK]

 RFC4273 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1269 RFC1270 SNMP Communications Services F. Kastenholz October 1991 ASCII HTML 11

This document discusses various issues to be considered when determining the underlying communications services to be used by an SNMP implementation. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1270 RFC1271 Remote Network Monitoring Management Information Base S. Waldbusser November 1991 ASCII HTML 81

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

 RFC1757 RFC1513 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC1271 RFC1272 Internet Accounting: Background C. Mills D. Hirsh G.R. Ruth November 1991 ASCII HTML 19

This document provides background information for the "Internet Accounting Architecture". This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF acct 10.17487/RFC1272 RFC1273 Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations M.F. Schwartz November 1991 ASCII HTML 8

This memo describes plans to carry out a longitudinal measurement study of changes in service-level reachability in the global TCP/IP Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1273 RFC1274 The COSINE and Internet X.500 Schema P. Barker S. Kille November 1991 ASCII HTML 60 Naming

This document suggests an X.500 Directory Schema, or Naming Architecture, for use in the COSINE and Internet X.500 pilots. [STANDARDS-TRACK]

 RFC4524 PROPOSED STANDARD PROPOSED STANDARD IETF app osids 10.17487/RFC1274 RFC1275 Replication Requirements to provide an Internet Directory using X.500 S.E. Hardcastle-Kille November 1991 ASCII PS PDF HTML 3

This RFC considers certain deficiencies of the 1988 X.500 standard, which need to be addressed before an effective open Internet Directory can be established using these protocols and services [CCI88]. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1275 RFC1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500 S.E. Hardcastle-Kille November 1991 ASCII PS HTML 17

Some requirements on extensions to X.500 are described in the RFC[HK91b], in order to build an Internet Directory using X.500(1988). This document specifies a set of solutions to the problems raised. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1276 RFC1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers S.E. Hardcastle-Kille November 1991 ASCII PS HTML 12 address ISO OSI

This document defines a new network address format, and rules for using some existing network address formats. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app osids 10.17487/RFC1277 RFC1278 A string encoding of Presentation Address S.E. Hardcastle-Kille November 1991 ASCII PS HTML 7 OSI ASN.1

There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1278 RFC1279 X.500 and Domains S.E. Hardcastle-Kille November 1991 ASCII PS PDF HTML 15 Domain Name naming

This RFC considers X.500 in relation to Internet and UK Domains. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 EXPERIMENTAL EXPERIMENTAL IETF app osids 10.17487/RFC1279 RFC1280 IAB Official Protocol Standards J. Postel March 1992 ASCII HTML 32

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1250 RFC1360 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1280 RFC1281 Guidelines for the Secure Operation of the Internet R. Pethia S. Crocker B. Fraser November 1991 ASCII HTML 10 security privacy protection guideline

The purpose of this document is to provide a set of guidelines to aid in the secure operation of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF sec spwg 10.17487/RFC1281 RFC1282 BSD Rlogin B. Kantor December 1991 ASCII HTML 5 BSD Login Unix remote-login remote-logon

This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1258 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1282 RFC1283 SNMP over OSI M. Rose December 1991 ASCII HTML 8 ISO Management MIB

This memo describes mappings from the SNMP onto both the COTS and the CLTS. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet Standard.

 RFC1418 EXPERIMENTAL EXPERIMENTAL IETF snmp 10.17487/RFC1283 RFC1284 Definitions of Managed Objects for the Ethernet-like Interface Types J. Cook Editor December 1991 ASCII HTML 21 SNMP MIB Management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

 RFC1398 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1284 RFC1285 FDDI Management Information Base J. Case January 1992 ASCII HTML 46 FDDI-MIB standard standards MIB SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing devices which implement the FDDI. [STANDARDS-TRACK]

 RFC1512 HISTORIC PROPOSED STANDARD IETF fddimib 10.17487/RFC1285 RFC1286 Definitions of Managed Objects for Bridges E. Decker P. Langille A. Rijsinghani K. McCloghrie December 1991 ASCII HTML 40 SNMP MIB standard standards

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing bridges based on the IEEE 802.1d draft standard between Local Area Network (LAN) segments. This memo is an extension to the SNMP MIB. [STANDARDS-TRACK]

 RFC1493 RFC1525 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge 10.17487/RFC1286 RFC1287 Towards the Future Internet Architecture D. Clark L. Chapin V. Cerf R. Braden R. Hobby December 1991 ASCII HTML 29

This informational RFC discusses important directions for possible future evolution of the Internet architecture, and suggests steps towards the desired goals. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1287 RFC1288 The Finger User Information Protocol D. Zimmerman December 1991 ASCII HTML 12 FINGER

This memo describes the Finger user information protocol.This is a simple protocol which provides an interface to a remote user information program. [STANDARDS-TRACK]

 RFC1196 RFC1194 RFC0742 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1288 10.17487/RFC1288 RFC1289 DECnet Phase IV MIB Extensions J. Saperia December 1991 ASCII HTML 64 SNMP Management protocol standard standards

This memo is an extension to the SNMP MIB. This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. [STANDARDS-TRACK]

 RFC1559 PROPOSED STANDARD PROPOSED STANDARD IETF decnetiv 10.17487/RFC1289 RFC1290 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places J. Martin December 1991 ASCII HTML 27 SIGUCCS User Services Help Internet

This paper will present some of the "gold nuggets" of information and file repositories on the network that could be of use to end users. This RFC provides information for the Internet community. It does not specify an Internet standard.

 RFC1402 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1290 RFC1291 Mid-Level Networks Potential Technical Services V. Aggarwal December 1991 ASCII PS HTML 10 statistics connectivity management

This document proposes a set of technical services that each Internet mid-level network can offer within the mid-level network itself and and to its peer networks. This RFC provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1291 RFC1292 A Catalog of Available X.500 Implementations R. Lang R. Wright January 1992 ASCII HTML 103

The goal of this document is to provide information regarding the availability and capability of implementations of X.500. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1632 INFORMATIONAL INFORMATIONAL IETF disi 10.17487/RFC1292 RFC1293 Inverse Address Resolution Protocol T. Bradley C. Brown January 1992 ASCII HTML 6 standard standards ARP DLCI

This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]

 RFC2390 PROPOSED STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1293 RFC1294 Multiprotocol Interconnect over Frame Relay T. Bradley C. Brown A. Malis January 1992 ASCII HTML 28 standard standards

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]

 RFC1490 RFC2427 PROPOSED STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1294 RFC1295 User Bill of Rights for entries and listings in the Public Directory The North American Directory Forum January 1992 ASCII HTML 2 NADF-265 NADF X.500

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 and RFC1407. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1295 RFC1296 Internet Growth (1981-1991) M. Lottor January 1992 ASCII HTML 9 statistics ZONE

This document illustrates the growth of the Internet by examination of entries in the Domain Name System (DNS) and pre-DNS host tables. This memo provides information for the Internet community. It does not specify an Internet standard. This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK]

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1296 RFC1297 NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS") D. Johnson January 1992 ASCII HTML 12 problems tracking operations NOC

This document explores competing uses, architectures, and desirable features of integrated internal trouble ticket systems for Network and other Operations Centers. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF ucp 10.17487/RFC1297 RFC1298 SNMP over IPX R. Wormley S. Bostock February 1992 ASCII HTML 5

This memo defines a convention for encapsulating Simple Network Management Protocol (SNMP) packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1420 INFORMATIONAL INFORMATIONAL IETF snmp 10.17487/RFC1298 RFC1299 Summary of 1200-1299 M. Kennedy January 1997 ASCII HTML 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1299 RFC1300 Remembrances of Things Past S. Greenfield February 1992 ASCII HTML 4 poem

Poem. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1300 RFC1301 Multicast Transport Protocol S. Armstrong A. Freier K. Marzullo February 1992 ASCII HTML 38 MTP MTP reliable transport multicast broadcast collaboration networking

This memo describes a protocol for reliable transport that utilizes the multicast capability of applicable lower layer networking architectures. The transport definition permits an arbitrary number of transport providers to perform realtime collaborations without requiring networking clients (aka, applications) to possess detailed knowledge of the population or geographical dispersion of the participating members. It is not network architectural specific, but does implicitly require some form of multicasting (or broadcasting) at the data link level, as well as some means of communicating that capability up through the layers to the transport. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1301 RFC1302 Building a Network Information Services Infrastructure D. Sitzler P. Smith A. Marine February 1992 ASCII HTML 13 NISI NIC User Services

This FYI RFC document is intended for existing Internet Network Information Center (NIC) personnel, people interested in establishing a new NIC, Internet Network Operations Centers (NOCs), and funding agencies interested in contributing to user support facilities. This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0012 INFORMATIONAL INFORMATIONAL IETF nisi 10.17487/RFC1302 RFC1303 A Convention for Describing SNMP-based Agents K. McCloghrie M. Rose February 1992 ASCII HTML 12 SNMP MIB Network Management,

This memo suggests a straight-forward approach towards describing SNMP- based agents. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1155 RFC1157 RFC1212 RFC1213 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1303 RFC1304 Definitions of Managed Objects for the SIP Interface Type T. Cox Editor K. Tesink Editor February 1992 ASCII HTML 25 Standard MIB Network Management SMDS

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing SIP (SMDS Interface Protocol) objects. [STANDARDS-TRACK]

 RFC1694 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1304 RFC1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis D. Mills March 1992 ASCII PDF HTML 109 NTPV3 NTP

This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. [STANDARDS-TRACK]

 RFC0958 RFC1059 RFC1119 RFC5905 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1305 RFC1306 Experiences Supporting By-Request Circuit-Switched T3 Networks A. Nicholson J. Young March 1992 ASCII HTML 10 WAN Wide Area Net FDDI

This memo describes the experiences of a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers. This RFC provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1306 RFC1307 Dynamically Switched Link Control Protocol J. Young A. Nicholson March 1992 ASCII HTML 13 DSLCP Experimental Protocol T3 FDDI

This memo describes an experimental protocol developed by a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services. The protocol is used for the control of network connections external to a host, but known to the host. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1307 RFC1308 Executive Introduction to Directory Services Using the X.500 Protocol C. Weider J. Reynolds March 1992 ASCII HTML 4

This document is an Executive Introduction to Directory Services using the X.500 protocol. It briefly discusses the deficiencies in currently deployed Internet Directory Services, and then illustrates the solutions provided by X.500. This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0013 INFORMATIONAL INFORMATIONAL IETF disi 10.17487/RFC1308 RFC1309 Technical Overview of Directory Services Using the X.500 Protocol C. Weider J. Reynolds S. Heker March 1992 ASCII HTML 16

This document is an overview of the X.500 standard for people not familiar with the technology. It compares and contrasts Directory Services based on X.500 with several of the other Directory services currently in use in the Internet. This paper also describes the status of the standard and provides references for further information on X.500 implementations and technical information. This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0014 INFORMATIONAL INFORMATIONAL IETF disi 10.17487/RFC1309 RFC1310 The Internet Standards Process L. Chapin March 1992 ASCII HTML 23

This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK]

 RFC1602 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1310 RFC1311 Introduction to the STD Notes J. Postel March 1992 ASCII HTML 5 new IAB

The STDs are a subseries of notes within the RFC series that are the Internet standards. The intent is to identify clearly for the Internet community those RFCs which document Internet standards. [STANDARDS-TRACK]

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1311 RFC1312 Message Send Protocol 2 R. Nelson G. Arnold April 1992 ASCII HTML 8 MSP2 MSP talk

The Message Send Protocol is used to send a short message to a given user on a given terminal on a given host. This memo defines an Experimental Protocol for the Internet community.

 RFC1159 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1312 RFC1313 Today's Programming for KRFC AM 1313 Internet Talk Radio C. Partridge April 1 1992 ASCII HTML 3

Hi and welcome to KRFC Internet Talk Radio, your place on the AM dial for lively talk and just-breaking news on internetworking. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1313 RFC1314 A File Format for the Exchange of Images in the Internet A. Katz D. Cohen April 1992 ASCII HTML 23 NETFAX TIFF facsimile

This document defines a standard file format for the exchange of fax- like black and white images within the Internet. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF app netfax 10.17487/RFC1314 RFC1315 Management Information Base for Frame Relay DTEs C. Brown F. Baker C. Carvalho April 1992 ASCII HTML 19 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Frame Relay. [STANDARDS-TRACK]

 RFC2115 PROPOSED STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1315 RFC1316 Definitions of Managed Objects for Character Stream Devices B. Stewart April 1992 ASCII HTML 17 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for the management of character stream devices. [STANDARDS-TRACK]

 RFC1658 PROPOSED STANDARD PROPOSED STANDARD IETF charmib 10.17487/RFC1316 RFC1317 Definitions of Managed Objects for RS-232-like Hardware Devices B. Stewart April 1992 ASCII HTML 17 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]

 RFC1659 PROPOSED STANDARD PROPOSED STANDARD IETF charmib 10.17487/RFC1317 RFC1318 Definitions of Managed Objects for Parallel-printer-like Hardware Devices B. Stewart April 1992 ASCII HTML 11 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of parallel-printer- like devices. [STANDARDS-TRACK]

 RFC1660 PROPOSED STANDARD PROPOSED STANDARD IETF charmib 10.17487/RFC1318 RFC1319 The MD2 Message-Digest Algorithm B. Kaliski April 1992 ASCII HTML 17 security encryption signature

This document describes the MD2 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC6149 HISTORIC INFORMATIONAL IETF sec pem http://www.rfc-editor.org/errata_search.php?rfc=1319 10.17487/RFC1319 RFC1320 The MD4 Message-Digest Algorithm R. Rivest April 1992 ASCII HTML 20 MD4 security encryption signature

This document describes the MD4 message-digest algorithm [1]. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1186 RFC6150 HISTORIC INFORMATIONAL IETF sec pem http://www.rfc-editor.org/errata_search.php?rfc=1320 10.17487/RFC1320 RFC1321 The MD5 Message-Digest Algorithm R. Rivest April 1992 ASCII HTML 21 security signature eneryption

This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC6151 INFORMATIONAL INFORMATIONAL IETF sec pem http://www.rfc-editor.org/errata_search.php?rfc=1321 10.17487/RFC1321 RFC1322 A Unified Approach to Inter-Domain Routing D. Estrin Y. Rekhter S. Hotz May 1992 ASCII HTML 38 path vector routing source demand routing

This memo is an informational RFC which outlines one potential approach for inter-domain routing in future global internets. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF rtg bgp http://www.rfc-editor.org/errata_search.php?rfc=1322 10.17487/RFC1322 RFC1323 TCP Extensions for High Performance V. Jacobson R. Braden D. Borman May 1992 ASCII HTML 37 TCP-EXT options PAWS window scale window scale Protect Against Wrapped Sequence numbers

This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. [STANDARDS-TRACK]

 RFC1072 RFC1185 RFC7323 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcplw http://www.rfc-editor.org/errata_search.php?rfc=1323 10.17487/RFC1323 RFC1324 A Discussion on Computer Network Conferencing D. Reed May 1992 ASCII HTML 11 talk real time chat

This memo is intended to make more people aware of the present developments in the Computer Conferencing field as well as put forward ideas on what should be done to formalize this work so that there is a common standard for programmers and others who are involved in this field to work with. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1324 RFC1325 FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions G. Malkin A. Marine May 1992 ASCII HTML 42 documentation help information

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1206 RFC1594 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1325 RFC1326 Mutual Encapsulation Considered Dangerous P. Tsuchiya May 1992 ASCII HTML 5 protocol layering wrapping

This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A). This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1326 RFC1327 Mapping between X.400(1988) / ISO 10021 and RFC 822 S. Hardcastle-Kille May 1992 ASCII HTML 113 Electronic-mail,Message handling systems

This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on the DARPA Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected. [STANDARDS-TRACK]

 RFC0987 RFC1026 RFC1138 RFC1148 RFC2156 RFC0822 RFC1495 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1327 RFC1328 X.400 1988 to 1984 downgrading S. Hardcastle-Kille May 1992 ASCII HTML 5 Electronic-mail message handling systems,mail

This document considers issues of downgrading from X.400(1988) to X.400(1984) [MHS88a, MHS84]. Annexe B of X.419 specifies some downgrading rules [MHS88b], but these are not sufficient for provision of service in an environment containing both 1984 and 1988 components. This document defines a number of extensions to this annexe. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1328 RFC1329 Thoughts on Address Resolution for Dual MAC FDDI Networks P. Kuehn May 1992 ASCII HTML 28

In this document an idea is submitted how IP and ARP can be used on inhomogeneous FDDI networks (FDDI networks with single MAC and dual MAC stations) by introducing a new protocol layer in the protocol suite of the dual MAC stations. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC5494 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1329 RFC1330 Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community ESCC X.500/X.400 Task Force ESnet Site Coordinating Comittee (ESCC) Energy Sciences Network (ESnet) May 1992 ASCII HTML 87

This RFC is a near verbatim copy of the whitepaper produced by the ESnet Site Coordinating Committee's X.500/X.400 Task Force. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1330 RFC1331 The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links W. Simpson May 1992 ASCII HTML 69 serial line IP over serial dial-up

This document defines the PPP encapsulation scheme, together with the PPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]

 RFC1171 RFC1172 RFC1548 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1331 RFC1332 The PPP Internet Protocol Control Protocol (IPCP) G. McGregor May 1992 ASCII HTML 14 PPP-IPCP serial line IP over serial dial-up

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. [STANDARDS-TRACK]

 RFC1172 RFC3241 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1332 RFC1333 PPP Link Quality Monitoring W. Simpson May 1992 ASCII HTML 17 serial line IP over serial dial-up

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link. [STANDARDS-TRACK]

 RFC1989 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1333 RFC1334 PPP Authentication Protocols B. Lloyd W. Simpson October 1992 ASCII HTML 16 point serial line dial-up

This document defines two protocols for Authentication: the Password Authentication Protocol and the Challenge-Handshake Authentication Protocol. [STANDARDS-TRACK]

 RFC1994 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1334 RFC1335 A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion Z. Wang J. Crowcroft May 1992 ASCII HTML 7 internet protocol IP

This RFC presents a solution to problem of address space exhaustion in the Internet. It proposes a two-tier address structure for the Internet. This is an "idea" paper and discussion is strongly encouraged. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1335 RFC1336 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members G. Malkin May 1992 ASCII HTML 33 Almquist Braden Braun Callon Cerf Chiappa Chapin Clark Crocker Davin Estrin Hobby Huitema Huizer Kent Lauck Leiner Lynch Piscitello Postel Reynolds Schwartz Stockman Vaudreuil

This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify any standard.

 RFC1251 FYI0009 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1336 RFC1337 TIME-WAIT Assassination Hazards in TCP R. Braden May 1992 ASCII HTML 11 TCP protocol protocol state graceful close reset

This note describes some theoretically-possible failure modes for TCP connections and discusses possible remedies. In particular, one very simple fix is identified. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1337 10.17487/RFC1337 RFC1338 Supernetting: an Address Assignment and Aggregation Strategy V. Fuller T. Li J. Yu K. Varadhan June 1992 ASCII HTML 20 internet address routing

This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1519 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1338 RFC1339 Remote Mail Checking Protocol S. Dorner P. Resnick June 1992 ASCII HTML 6 RMCP email remote mail

This RFC defines a protocol to provide a mail checking service to be used between a client and server pair. Typically, a small program on a client workstation would use the protocol to query a server in order to find out whether new mail has arrived for a specified user. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1339 RFC1340 Assigned Numbers J. Reynolds J. Postel July 1992 ASCII HTML 139

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.

 RFC1060 RFC1700 HISTORIC INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1340 10.17487/RFC1340 RFC1341 MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies N. Borenstein N. Freed June 1992 ASCII PS PDF HTML 80 EMail Multimedia

This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. [STANDARDS-TRACK]

 RFC1521 PROPOSED STANDARD PROPOSED STANDARD IETF app 822ext 10.17487/RFC1341 RFC1342 Representation of Non-ASCII Text in Internet Message Headers K. Moore June 1992 ASCII HTML 7 EMail Character Sets

This memo describes an extension to the message format defined in [1] (known to the IETF Mail Extensions Working Group as "RFC 1341"), to allow the representation of character sets other than ASCII in RFC 822 message headers. [STANDARDS-TRACK]

 RFC1522 PROPOSED STANDARD PROPOSED STANDARD IETF app 822ext 10.17487/RFC1342 RFC1343 A User Agent Configuration Mechanism for Multimedia Mail Format Information N. Borenstein June 1992 ASCII PS PDF HTML 10 EMail Multimedia

This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1343 RFC1344 Implications of MIME for Internet Mail Gateways N. Borenstein June 1992 ASCII PS PDF HTML 9 EMail Forwarding Relaying Fragmentation Multimedia

While MIME was carefully designed so that it does not require any changes to Internet electronic message transport facilities, there are several ways in which message transport systems may want to take advantage of MIME. These opportunities are the subject of this memo. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1344 RFC1345 Character Mnemonics and Character Sets K. Simonsen June 1992 ASCII HTML 103

This memo lists a selection of characters and their presence in some coded character sets. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=1345 10.17487/RFC1345 RFC1346 Resource Allocation, Control, and Accounting for the Use of Network Resources P. Jones June 1992 ASCII HTML 6

The purpose of this RFC is to focus discussion on particular challenges in large service networks in general, and the International IP Internet in particular. No solution discussed in this document is intended as a standard. Rather, it is hoped that a general consensus will emerge as to the appropriate solutions, leading eventually to the adoption of standards. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1346 RFC1347 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing R. Callon June 1992 ASCII PS PDF HTML 8

This paper describes a simple proposal which provides a long-term solution to Internet addressing, routing, and scaling. This memo provides information for the Internet community. It does not specify an Internet standard.

 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1347 RFC1348 DNS NSAP RRs B. Manning July 1992 ASCII HTML 4 domain names CLNP resource records

This RFC defines the format of two new Resource Records (RRs) for the Domain Name System (DNS), and reserves corresponding DNS type mnemonic and numerical codes. This memo defines an Experimental Protocol for the Internet community.

 RFC1637 RFC1034 RFC1035 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1348 RFC1349 Type of Service in the Internet Protocol Suite P. Almquist July 1992 ASCII HTML 28 TOS TOS IP

This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK]

 RFC2474 RFC1248 RFC1247 RFC1195 RFC1123 RFC1122 RFC1060 RFC0791 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rreq http://www.rfc-editor.org/errata_search.php?rfc=1349 10.17487/RFC1349 RFC1350 The TFTP Protocol (Revision 2) K. Sollins July 1992 ASCII HTML 11 TFTP trivial file transfer booting

TFTP is a very simple protocol used to transfer files. It is from this that its name comes, Trivial File Transfer Protocol or TFTP. Each nonterminal packet is acknowledged separately. This document describes the protocol and its types of packets. The document also explains the reasons behind some of the design decisions. [STANDARDS-TRACK]

 RFC0783 RFC1782 RFC1783 RFC1784 RFC1785 RFC2347 RFC2348 RFC2349 STD0033 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1350 10.17487/RFC1350 RFC1351 SNMP Administrative Model J. Davin J. Galvin K. McCloghrie July 1992 ASCII HTML 35 SNMP-ADMIN network management authentication

This memo presents an elaboration of the SNMP administrative model set forth in [1]. This model provides a unified conceptual basis for administering SNMP protocol entities to support: authenticaiton and integrity, privacy, access control, and cooperation of protocol entities. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF sec snmpsec 10.17487/RFC1351 RFC1352 SNMP Security Protocols J. Galvin K. McCloghrie J. Davin July 1992 ASCII HTML 41 SNMP-SEC network management authentication

The Simple Network Management Protocol (SNMP) specification [1] allows for the protection of network management operations by a variety of security protocols. The SNMP administrative model described in [2] provides a framework for securing SNMP network management. In the context of that framework, this memo defines protocols to support the following three security services: data integrity, data origin authentication and data confidentiality. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF sec snmpsec 10.17487/RFC1352 RFC1353 Definitions of Managed Objects for Administration of SNMP Parties K. McCloghrie J. Davin J. Galvin July 1992 ASCII HTML 26 SNMP-PARTY-MIB network management authentication

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes a representation of the SNMP parties defined in [8] as objects defined according to the Internet Standard SMI [1]. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF sec snmpsec 10.17487/RFC1353 RFC1354 IP Forwarding Table MIB F. Baker July 1992 ASCII HTML 12 Network Management Route Table

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing routes in the IP Internet. [STANDARDS-TRACK]

 RFC2096 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rreq 10.17487/RFC1354 RFC1355 Privacy and Accuracy Issues in Network Information Center Databases J. Curran A. Marine August 1992 ASCII HTML 4 NIC data privacy accuracy

This document provides a set of guidelines for the administration and operation of public Network Information Center (NIC) databases. This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0015 INFORMATIONAL INFORMATIONAL IETF nisi 10.17487/RFC1355 RFC1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode A. Malis D. Robinson R. Ullmann August 1992 ASCII HTML 14 IP-X.25 IP on X.25

This document specifies the encapsulation of IP and other network layer protocols over X.25 networks, in accordance and alignment with ISO/IEC and CCITT standards. It is a replacement for RFC 877, "A Standard for the Transmission of IP Datagrams Over Public Data Networks" [1]. [STANDARDS-TRACK]

 RFC0877 DRAFT STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1356 RFC1357 A Format for E-mailing Bibliographic Records D. Cohen July 1992 ASCII HTML 13 library technical reports email services

This memo defines a format for E-mailing bibliographic records of technical reports. It is intended to accelerate the dissemination of information about new Computer Science Technical Reports (CS-TR). This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1807 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1357 RFC1358 Charter of the Internet Architecture Board (IAB) L. Chapin August 1992 ASCII HTML 5 ISOC Internet Society IETF IRTF

The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1601 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1358 RFC1359 Connecting to the Internet - What Connecting Institutions Should Anticipate ACM SIGUCCS August 1992 ASCII HTML 25 Internet access

This FYI RFC outlines the major issues an institution should consider in the decision and implementation of a campus connection to the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0016 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1359 RFC1360 IAB Official Protocol Standards J. Postel September 1992 ASCII HTML 33 proposed draft experimental informational historic full RFC1280 RFC1410 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1360 RFC1361 Simple Network Time Protocol (SNTP) D. Mills August 1992 ASCII HTML 10 Clocks Synchronization NTP

This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memorandum does not obsolete or update any RFC. This memo provides information for the Internet community. It does not specify an Internet standard. Discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.9 contain the lists of protocols in each stage of standardization. Finally come pointers to references and contacts for further information. [STANDARDS-TRACK]

 RFC1769 RFC1305 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1361 10.17487/RFC1361 RFC1362 Novell IPX over Various WAN Media (IPXWAN) M. Allen September 1992 ASCII HTML 13 IPX on X.25 IPX on PPP IPX on Frame Relay

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1634 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1362 RFC1363 A Proposed Flow Specification C. Partridge September 1992 ASCII HTML 20 flow spec resource reservation stream type of service quality of service INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1363 RFC1364 BGP OSPF Interaction K. Varadhan September 1992 ASCII HTML 14 autonomous system border router open shortest path first routing protocol domain route exchange exporting importing RFC1403 RFC1247 RFC1267 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1364 RFC1365 An IP Address Extension Proposal K. Siyan September 1992 ASCII HTML 6 class F addresses INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1365 10.17487/RFC1365 RFC1366 Guidelines for Management of IP Address Space E. Gerich October 1992 ASCII HTML 8 routing tables allocation registry IR IANA

This document has been reviewed by the Federal Engineering Task Force (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. This memo provides information for the Internet community. It does not specify an Internet standard. This RFC suggests an extension to the IP protocol to solve the shortage of IP address problem, and requests discussion and suggestions for improvements. This memo provides information for the Internet community. It does not specify an Internet standard. This memo defines the various criteria to be used when designing Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK] 1363 Partridge Spt 92 A Proposed Flow Specification The flow specification defined in this memo is intended for information and possible experimentation (i.e., experimental use by consenting routers and applications only). This RFC is a product of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1466 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1366 RFC1367 Schedule for IP Address Space Management Guidelines C. Topolcic October 1992 ASCII HTML 3 routing tables allocation registry IR IANA

This memo suggests a schedule for the implementation of the IP network number allocation plan described in RFC 1366. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1467 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1367 RFC1368 Definition of Managed Objects for IEEE 802.3 Repeater Devices D. McMaster K. McCloghrie October 1992 ASCII HTML 40 MIB hub management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as "hubs". [STANDARDS-TRACK]

 RFC1516 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC1368 RFC1369 Implementation Notes and Experience for the Internet Ethernet MIB F. Kastenholz October 1992 ASCII HTML 7 management

This document reflects the currently known status of 11 different implementations of the MIB by 7 different vendors on 7 different Ethernet interface chips. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL PROPOSED STANDARD IETF ethermib 10.17487/RFC1369 RFC1370 Applicability Statement for OSPF Internet Architecture Board L. Chapin October 1992 ASCII HTML 2 routing open shortest path first

This Applicability Statement places a requirement on vendors claiming conformance to this standard, in order to assure that users will have the option of deploying OSPF when they need a multivendor, interoperable IGP in their environment. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1370 RFC1371 Choosing a Common IGP for the IP Internet P. Gross October 1992 ASCII HTML 9 routing recommendation interior gateway protocol

This memo presents motivation, rationale and other surrounding background information leading to the IESG's recommendation to the IAB for a single "common IGP" for the IP portions of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1371 RFC1372 Telnet Remote Flow Control Option C. Hedrick D. Borman October 1992 ASCII HTML 6 TOPT-RFC terminal access

This document specifies an extended version of the Telnet Remote Flow Control Option, RFC 1080, with the addition of the RESTART-ANY and RESTART-XON suboptions. [STANDARDS-TRACK]

 RFC1080 PROPOSED STANDARD PROPOSED STANDARD IETF app telnet 10.17487/RFC1372 RFC1373 Portable DUAs T. Tignor October 1992 ASCII HTML 12 directory user agents whois de dixie ud doog ISODE X.500

This document comes in two parts. The first part is for regular people who wish to set up their own DUAs (Directory User Interfaces) to access the Directory. The second part is for ISODE-maintainers wishing to provide portable DUAs to users. This part gives instructions in a similar but longer, step-by-step format. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1373 RFC1374 IP and ARP on HIPPI J. Renwick A. Nicholson October 1992 ASCII HTML 43

The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. Another X3T9.3 draft describes the operation of HIPPI physical switches. X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks. This memo is intended to become an Internet Standard. [STANDARDS-TRACK]

 RFC2834 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1374 RFC1375 Suggestion for New Classes of IP Addresses P. Robinson October 1992 ASCII HTML 7 network numbers

This RFC suggests a change in the method of specifying the IP address to add new classes of networks to be called F, G, H, and K, to reduce the amount of wasted address space, and to increase the available IP address number space, especially for smaller organizations or classes of connectors that do not need or do not want a full Class C IP address. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1375 RFC1376 The PPP DECnet Phase IV Control Protocol (DNCP) S. Senum November 1992 ASCII HTML 6 point DNA DDCMP

This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc.). [STANDARDS-TRACK]

 RFC1762 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1376 RFC1377 The PPP OSI Network Layer Control Protocol (OSINLCP) D. Katz November 1992 ASCII HTML 10 PPP-OSINLCP point open systems interconnection

This document defines the NCP for establishing and configuring OSI Network Layer Protocols. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1377 RFC1378 The PPP AppleTalk Control Protocol (ATCP) B. Parker November 1992 ASCII HTML 16 PPP-ATCP point

This document defines the NCP for establishing and configuring the AppleTalk Protocol [3] over PPP. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1378 RFC1379 Extending TCP for Transactions -- Concepts R. Braden November 1992 ASCII HTML 38 transmission control protocol

This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC6247 RFC1644 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1379 RFC1380 IESG Deliberations on Routing and Addressing P. Gross P. Almquist November 1992 ASCII HTML 22 ROAD

This memo summarizes issues surrounding the routing and addressing scaling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1380 RFC1381 SNMP MIB Extension for X.25 LAPB D. Throop F. Baker November 1992 ASCII HTML 33 SNMP-LAPB management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Link Layer of X.25, LAPB. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF x25mib 10.17487/RFC1381 RFC1382 SNMP MIB Extension for the X.25 Packet Layer D. Throop Editor November 1992 ASCII HTML 69 SNMP-X.25 management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF x25mib 10.17487/RFC1382 RFC1383 An Experiment in DNS Based IP Routing C. Huitema December 1992 ASCII HTML 14 DNS-IP

Potential solutions to the routing explosion. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1383 RFC1384 Naming Guidelines for Directory Pilots P. Barker S.E. Hardcastle-Kille January 1993 ASCII PS PDF HTML 12 X.500 Multinational

This document defines a number of naming guidelines. Alignment to these guidelines is recommended for directory pilots. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1617 RTR0011 INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1384 RFC1385 EIP: The Extended Internet Protocol Z. Wang November 1992 ASCII HTML 17 addressing

EIP can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an "idea" paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC6814 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1385 RFC1386 The US Domain A. Cooper J. Postel December 1992 ASCII HTML 31 DNS top-level

This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1480 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1386 RFC1387 RIP Version 2 Protocol Analysis G. Malkin January 1993 ASCII HTML 3 RIP-2

As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1721 INFORMATIONAL INFORMATIONAL IETF rtg ripv2 10.17487/RFC1387 RFC1388 RIP Version 2 Carrying Additional Information G. Malkin January 1993 ASCII HTML 7 RIP-2

This document specifies an extension of the Routing Information Protocol (RIP), as defined in [STANDARDS-TRACK]

 RFC1723 RFC1058 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ripv2 10.17487/RFC1388 RFC1389 RIP Version 2 MIB Extensions G. Malkin F. Baker January 1993 ASCII HTML 13 RIP-2 Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]

 RFC1724 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ripv2 10.17487/RFC1389 RFC1390 Transmission of IP and ARP over FDDI Networks D. Katz January 1993 ASCII HTML 11 IP-FDDI IEEE 802 MAC

This memo defines a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]

 STD0036 INTERNET STANDARD INTERNET STANDARD IETF int fddi 10.17487/RFC1390 RFC1391 The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force G. Malkin January 1993 ASCII HTML 19 meetings

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1539 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1391 RFC1392 Internet Users' Glossary G. Malkin T. LaQuey Parker January 1993 ASCII HTML 53

There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1983 INFORMATIONAL INFORMATIONAL IETF userglos 10.17487/RFC1392 RFC1393 Traceroute Using an IP Option G. Malkin January 1993 ASCII HTML 7 TRACE-IP ICMP MTU Line Speed

This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time. This memo defines an Experimental Protocol for the Internet community.

 RFC6814 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1393 RFC1394 Relationship of Telex Answerback Codes to Internet Domains P. Robinson January 1993 ASCII HTML 15 DNS Country

This RFC gives the list, as best known, of all common Internet domains and the conversion between specific country telex answerback codes and Internet country domain identifiers. It also lists the telex code and international dialing code, wherever it is available. It will also list major Internet "Public" E-Mail addresses. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1394 RFC1395 BOOTP Vendor Information Extensions J. Reynolds January 1993 ASCII HTML 8 TAGS

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo will be updated as additional tags are defined. This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain Name, Tag 16 for Swap Server and Tag 17 for Root Path. This memo is a status report on the vendor information extensions used int the Bootstrap Protocol (BOOTP).

 RFC1084 RFC1048 RFC1497 RFC1533 RFC0951 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1395 RFC1396 The Process for Organization of Internet Standards Working Group (POISED) S. Crocker January 1993 ASCII HTML 10 IAB IESG ISOC

This report provides a summary of the POISED Working Group (WG), starting from the events leading to the formation of the WG to the end of 1992. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1396 RFC1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol D. Haskin January 1993 ASCII HTML 2 BGP

This document speficies the recommendation of the BGP Working Group on default route advertisement support in BGP2 [1] and BGP3 [2] versions of the Border Gateway Protocol. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF rtg idr 10.17487/RFC1397 RFC1398 Definitions of Managed Objects for the Ethernet-Like Interface Types F. Kastenholz January 1993 ASCII HTML 17 MIB Management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ehternet-like objects. [STANDARDS-TRACK]

 RFC1284 RFC1623 DRAFT STANDARD DRAFT STANDARD IETF ethermib 10.17487/RFC1398 RFC1399 Summary of 1300-1399 J. Elliott January 1997 ASCII HTML 22 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1399 RFC1400 Transition and Modernization of the Internet Registration Service S. Williamson March 1993 ASCII HTML 7 INTERNIC IR

As a result of the NREN NIS award by National Science Foundation, non- DDN registration services will soon be transferred from the DDN NIC to the new Internet Registration Service, which is a part of an entity referred to as the InterNIC. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1400 RFC1401 Correspondence between the IAB and DISA on the use of DNS Internet Architecture Board January 1993 ASCII HTML 8 Domain Name Milnet

This memo reproduces three letters exchanged between the Internet Activities Board (IAB) and the Defense Information Systems Agency (DISA) regarding the importance of using the Domain Name System (DNS) throughout the Internet, and phasing out the use of older host name to address tables, such as "hosts.txt". This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1401 RFC1402 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places J. Martin January 1993 ASCII HTML 39 information introduction SIGUCCS User Services Help

The ultimate goal is to make the route to these sources of information invisible to you. At present, this is not easy to do. I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we all can be richer. This RFC provides information for the Internet community. It does not specify an Internet standard.

 RFC1290 FYI0010 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1402 RFC1403 BGP OSPF Interaction K. Varadhan January 1993 ASCII HTML 17 BGP-OSPF border gateway protocol open shortest path first routing

This memo defines the various criteria to be used when designing an Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK]

 RFC1364 HISTORIC PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1403 10.17487/RFC1403 RFC1404 A Model for Common Operational Statistics B. Stockman January 1993 ASCII HTML 27 Management Operations

This memo describes a model for operational statistics in the Internet. It gives recommendations for metrics, measurements, polling periods, storage formats and presentation formats. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1857 INFORMATIONAL INFORMATIONAL IETF opstat 10.17487/RFC1404 RFC1405 Mapping between X.400(1984/1988) and Mail-11 (DECnet mail) C. Allocchio January 1993 ASCII HTML 19 SMTP EMail 822

This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 ( 1984 / 1988 ) Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail) protocol. This memo defines an Experimental Protocol for the Internet community.

 RFC2162 EXPERIMENTAL EXPERIMENTAL IETF app x400ops 10.17487/RFC1405 RFC1406 Definitions of Managed Objects for the DS1 and E1 Interface Types F. Baker Editor J. Watt Editor January 1993 ASCII HTML 50 DS1/E1-MIB T1 MIB Management SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS1 Interfaces -- including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links. [STANDARDS-TRACK]

 RFC1232 RFC2495 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC1406 RFC1407 Definitions of Managed Objects for the DS3/E3 Interface Type T. Cox K. Tesink January 1993 ASCII HTML 43 DS3/E3-MIB T3 MIB Management SNMP

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS3 and E3 Interfaces. [STANDARDS-TRACK]

 RFC1233 RFC2496 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC1407 RFC1408 Telnet Environment Option D. Borman Editor January 1993 ASCII HTML 7 TOPT-ENVIR Negotiation

This document specifies a mechanism for passing environment information between a telnet client and server. [STANDARDS-TRACK]

 RFC1571 HISTORIC HISTORIC IETF app telnet 10.17487/RFC1408 RFC1409 Telnet Authentication Option D. Borman Editor January 1993 ASCII HTML 7 security

This memo defines an Experimental Protocol for the Internet community.

 RFC1416 EXPERIMENTAL EXPERIMENTAL IETF app telnet 10.17487/RFC1409 RFC1410 IAB Official Protocol Standards J. Postel Editor March 1993 ASCII HTML 35 proposed draft experimental informational historic full

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB).

 RFC1360 RFC1500 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1410 RFC1411 Telnet Authentication: Kerberos Version 4 D. Borman Editor January 1993 ASCII HTML 4 TEL-KER Security option

This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app telnet 10.17487/RFC1411 RFC1412 Telnet Authentication: SPX K. Alagappan January 1993 ASCII HTML 4 TEL-SPX Security option

This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app telnet 10.17487/RFC1412 RFC1413 Identification Protocol M. St. Johns February 1993 ASCII HTML 8 IDENT Authentication

The Identification Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. [STANDARDS-TRACK]

 RFC0931 PROPOSED STANDARD PROPOSED STANDARD IETF sec ident http://www.rfc-editor.org/errata_search.php?rfc=1413 10.17487/RFC1413 RFC1414 Identification MIB M. St. Johns M. Rose February 1993 ASCII HTML 7 IDENT-MIB Management SNMP

This memo defines a MIB for use with identifying the users associated with TCP connections. It provides functionality approximately equivalent to that provided by the protocol defined in RFC 1413 [1]. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF sec ident 10.17487/RFC1414 RFC1415 FTP-FTAM Gateway Specification J. Mindel R. Slaski January 1993 ASCII HTML 58 FTP FTAM transfer ISO OSI

This memo describes a dual protocol stack application layer gateway that performs protocol translation, in an interactive environment, between the FTP and FTAM file transfer protocols. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1415 RFC1416 Telnet Authentication Option D. Borman Editor February 1993 ASCII HTML 7 TOPT-AUTH Security

This RFC 1416 replaces RFC 1409, which has an important typographical error in the example on page 6 (one occurance of "REPLY" should be "IS"). This memo defines an Experimental Protocol for the Internet community.

 RFC1409 RFC2941 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1416 RFC1417 NADF Standing Documents: A Brief Overview The North American Directory Forum February 1993 ASCII HTML 4 X.500 Directory

The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1295 RFC1255 RFC1218 RFC1758 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1417 RFC1418 SNMP over OSI M. Rose March 1993 ASCII HTML 4 SNMP-OSI Management

This memo addresses some concerns by defining a framework for running the SNMP in an environment which supports the OSI connectionless-mode transport service. [STANDARDS-TRACK]

 RFC1161 RFC1283 HISTORIC PROPOSED STANDARD IETF int mpsnmp 10.17487/RFC1418 RFC1419 SNMP over AppleTalk G. Minshall M. Ritter March 1993 ASCII HTML 7 SNMP-AT Management

This memo describes the method by which the Simple Network Management Protocol (SNMP) as specified in [1] can be used over AppleTalk protocols [2] instead of the Internet UDP/IP protocol stack. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int mpsnmp 10.17487/RFC1419 RFC1420 SNMP over IPX S. Bostock March 1993 ASCII HTML 4 SNMP-IPX Management

This document defines a convention for encapsulating Simple Network Management Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2]. [STANDARDS-TRACK]

 RFC1298 PROPOSED STANDARD PROPOSED STANDARD IETF int mpsnmp 10.17487/RFC1420 RFC1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures J. Linn February 1993 ASCII HTML 42 PEM-ENC PEM

This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. [STANDARDS-TRACK]

 RFC1113 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1421 RFC1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management S. Kent February 1993 ASCII HTML 32 PEM-CKM PEM

This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. [STANDARDS-TRACK]

 RFC1114 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1422 RFC1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers D. Balenson February 1993 ASCII HTML 14 PEM-ALG PEM

This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail (PEM) in the Internet community. [STANDARDS-TRACK]

 RFC1115 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1423 RFC1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services B. Kaliski February 1993 ASCII HTML 9 PEM-KEY PEM

This document describes three types of service in support of Internet Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate- revocation list (CRL) storage, and CRL retrieval. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1424 RFC1425 SMTP Service Extensions J. Klensin N. Freed Editor M. Rose E. Stefferud D. Crocker February 1993 ASCII HTML 10 Mail

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

 RFC1651 PROPOSED STANDARD PROPOSED STANDARD IETF app smtpext 10.17487/RFC1425 RFC1426 SMTP Service Extension for 8bit-MIMEtransport J. Klensin N. Freed Editor M. Rose E. Stefferud D. Crocker February 1993 ASCII HTML 6 Mail

This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex 00-7F) may be relayed using SMTP.

 RFC1652 PROPOSED STANDARD PROPOSED STANDARD IETF app smtpext 10.17487/RFC1426 RFC1427 SMTP Service Extension for Message Size Declaration J. Klensin N. Freed Editor K. Moore February 1993 ASCII HTML 8 Mail

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]

 RFC1653 PROPOSED STANDARD PROPOSED STANDARD IETF app smtpext 10.17487/RFC1427 RFC1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME G. Vaudreuil February 1993 ASCII HTML 6 Mail

This document outlines the problems in this environment and an approach to minimizing the cost of transition from current usage of non-MIME 8bit messages to MIME. This RFC provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF app smtpext 10.17487/RFC1428 RFC1429 Listserv Distribute Protocol E. Thomas February 1993 ASCII HTML 8 LISTSERV Mail

This memo specifies a subset of the distribution protocol used by the BITNET LISTSERV to deliver mail messages to large amounts of recipients. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1429 RFC1430 A Strategic Plan for Deploying an Internet X.500 Directory Service S. Hardcastle-Kille E. Huizer V. Cerf R. Hobby S. Kent February 1993 ASCII HTML 20 X.500

This document describes an overall strategy for deploying a Directory Service on the Internet, based on the OSI X.500 Directory Service. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1430 RFC1431 DUA Metrics (OSI-DS 33 (v2)) P. Barker February 1993 ASCII HTML 19 Directory User Agent Measurement Statistics Survey X.500

This document defines a set of criteria by which a DUA implementation, or more precisely a Directory user interface, may be judged. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1431 RFC1432 Recent Internet Books J. Quarterman March 1993 ASCII HTML 15 bibiography

Here is a list of books related to using the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1432 RFC1433 Directed ARP J. Garrett J. Hagan J. Wong March 1993 ASCII HTML 18 DIR-ARP public networks SMDS

Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF int iplpdn 10.17487/RFC1433 RFC1434 Data Link Switching: Switch-to-Switch Protocol R. Dixon D. Kushi March 1993 ASCII PS PDF HTML 33 IBM SNA DLS SSP NetBIos

This RFC describes IBM's support of Data Link Switching over TCP/IP. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1795 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1434 RFC1435 IESG Advice from Experience with Path MTU Discovery S. Knowles March 1993 ASCII HTML 2 Maximum Transmission Unit

In the course of reviewing the MTU Discovery protocol for possible elevation to Draft Standard, a specific operational problem was uncovered. The problem results from the optional suppression of ICMP messages implemented in some routers. This memo outlines a modification to this practice to allow the correct functioning of MTU Discovery. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1435 RFC1436 The Internet Gopher Protocol (a distributed document search and retrieval protocol) F. Anklesaria M. McCahill P. Lindner D. Johnson D. Torrey B. Albert March 1993 ASCII HTML 16 GOPHER information locating

This document describes the protocol, lists some of the implementations currently available, and has an overview of how to implement new client and server applications. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1436 RFC1437 The Extension of MIME Content-Types to a New Medium N. Borenstein M. Linimon April 1 1993 ASCII HTML 6 life form Matter transport Sentient

This document defines one particular type of MIME data, the matter- transport/sentient-life-form type. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1437 RFC1438 Internet Engineering Task Force Statements Of Boredom (SOBs) A. Lyman Chapin C. Huitema April 1 1993 ASCII HTML 2 process policy

This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs). This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1438 10.17487/RFC1438 RFC1439 The Uniqueness of Unique Identifiers C. Finseth March 1993 ASCII HTML 11 names

This RFC provides information that may be useful when selecting a method to use for assigning unique identifiers to people. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1439 RFC1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer R. Troth July 1993 ASCII HTML 9 SIFT UFT Send FTP

This document describes a Sender-Initiated File Transfer (SIFT) protocol, also commonly called Unsolicited File Transfer (UFT) protocol. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1440 RFC1441 Introduction to version 2 of the Internet-standard Network Management Framework J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 13 SNMPv2 SNMP Management Framework

The purpose of this document is to provide an overview of version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2). [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF snmpv2 10.17487/RFC1441 RFC1442 Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 56 SNMP Management Framework SMI

Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that subset. [STANDARDS-TRACK]

 RFC1902 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1442 RFC1443 Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 31 SNMP Management Framework

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

 RFC1903 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1443 RFC1444 Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 33 SNMP Management Framework

It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

 RFC1904 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1444 RFC1445 Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2) J. Galvin K. McCloghrie April 1993 ASCII HTML 48 SNMP Management Framework

It is the purpose of this document, the Administrative Model for SNMPv2, to define how the administrative framework is applied to realize effective network management in a variety of configurations and environments. [STANDARDS-TRACK]

 HISTORIC HISTORIC IETF sec snmpsec 10.17487/RFC1445 RFC1446 Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2) J. Galvin K. McCloghrie April 1993 ASCII HTML 52 SNMP Management Framework

It is the purpose of this document, Security Protocols for SNMPv2, to define one such authentication and one such privacy protocol. [STANDARDS-TRACK]

 HISTORIC HISTORIC IETF sec snmpsec 10.17487/RFC1446 RFC1447 Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2) K. McCloghrie J. Galvin April 1993 ASCII HTML 50 SNMP Management Framework

The Administrative Model for SNMPv2 document [3] defines the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies. It is the purpose of this document, the Party MIB for SNMPv2, to define managed objects which correspond to these properties. [STANDARDS-TRACK]

 HISTORIC HISTORIC IETF sec snmpsec 10.17487/RFC1447 RFC1448 Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 36 SNMP Management Framework

It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]

 RFC1905 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1448 RFC1449 Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 25 SNMP Management Framework

It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]

 RFC1906 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1449 RFC1450 Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 27 SNMP Management Framework

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]

 RFC1907 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1450 RFC1451 Manager-to-Manager Management Information Base J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 36 SNMP Management Framework

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity acting in both a manager role and an agent role. [STANDARDS-TRACK]

 HISTORIC HISTORIC IETF snmpv2 10.17487/RFC1451 RFC1452 Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 17 SNMP Management Framework

The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2) [1], and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]

 RFC1908 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1452 RFC1453 A Comment on Packet Video Remote Conferencing and the Transport/Network Layers W. Chimiak April 1993 ASCII HTML 10 XTP

This RFC is a vehicle to inform the Internet community about XTP as it benefits from past Internet activity and targets general-purpose applications and multimedia applications with the emerging ATM networks in mind. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1453 RFC1454 Comparison of Proposals for Next Version of IP T. Dixon May 1993 ASCII HTML 15 IPng PIP TUBA SIP

This is a slightly edited reprint of RARE Technical Report (RTC(93)004). This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1454 RFC1455 Physical Link Security Type of Service D. Eastlake 3rd May 1993 ASCII HTML 6 TOS-LS TOS

This RFC documents an experimental protocol providing a Type of Service (TOS) to request maximum physical link security. This is an addition to the types of service enumerated in RFC 1349: Type of Service in the Internet Protocol Suite. This memo defines an Experimental Protocol for the Internet community.

 RFC2474 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1455 RFC1456 Conventions for Encoding the Vietnamese Language VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification Vietnamese Standardization Working Group May 1993 ASCII HTML 7 Character Set

This document provides information to the Internet community on the currently used conventions for encoding Vietnamese characters into 7-bit US ASCII and in an 8-bit form. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1456 RFC1457 Security Label Framework for the Internet R. Housley May 1993 ASCII HTML 14

This memo presents a security labeling framework for the Internet. The framework is intended to help protocol designers determine what, if any, security labeling should be supported by their protocols. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1457 RFC1458 Requirements for Multicast Protocols R. Braudes S. Zabele May 1993 ASCII HTML 19 Real-Time

This memo discusses some of these unresolved issues, and provides a high-level design for a new multicast transport protocol, group address and membership authority, and modifications to existing routing protocols. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1458 RFC1459 Internet Relay Chat Protocol J. Oikarinen D. Reed May 1993 ASCII HTML 65 IRCP IRC

The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server. This memo defines an Experimental Protocol for the Internet community.

 RFC2810 RFC2811 RFC2812 RFC2813 RFC7194 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1459 10.17487/RFC1459 RFC1460 Post Office Protocol - Version 3 M. Rose June 1993 ASCII HTML 17 Email

This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS-TRACK]

 RFC1225 RFC1725 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1460 RFC1461 SNMP MIB extension for Multiprotocol Interconnect over X.25 D. Throop May 1993 ASCII HTML 21 X25-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Multiprotocol Interconnect (including IP) traffic carried over X.25. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF x25mib 10.17487/RFC1461 RFC1462 FYI on "What is the Internet?" E. Krol E. Hoffman May 1993 ASCII HTML 11 Introduction

This FYI RFC answers the question, "What is the Internet?" and is produced by the User Services Working Group of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0020 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC1462 RFC1463 FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings E. Hoffman L. Jackson May 1993 ASCII HTML 4

This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history. This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0019 INFORMATIONAL INFORMATIONAL IETF userdoc2 10.17487/RFC1463 RFC1464 Using the Domain Name System To Store Arbitrary String Attributes R. Rosenbaum May 1993 ASCII HTML 4 DNS TXT

This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1464 10.17487/RFC1464 RFC1465 Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing D. Eppenberger May 1993 ASCII HTML 31 X400

This document proposes short term solutions for maintaining and distributing routing information and shows how messages can travel over different networks by using multi stack MTAs as relays. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app x400ops 10.17487/RFC1465 RFC1466 Guidelines for Management of IP Address Space E. Gerich May 1993 ASCII HTML 10 CIDR

This document proposes a plan which will forward the implementation of RFC 1174 and which defines the allocation and assignment of the network number space. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1366 RFC2050 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1466 RFC1467 Status of CIDR Deployment in the Internet C. Topolcic August 1993 ASCII HTML 9 routing tables allocation registry IR IANA classless

This document describes the current status of the development and deployment of CIDR technology into the Internet. This document replaces RFC 1367, which was a schedule for the deployment of IP address space management procedures to support route aggregation. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1367 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1467 RFC1468 Japanese Character Encoding for Internet Messages J. Murai M. Crispin E. van der Poel June 1993 ASCII HTML 6 Set

This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF app 822ext 10.17487/RFC1468 RFC1469 IP Multicast over Token-Ring Local Area Networks T. Pusateri June 1993 ASCII HTML 4 IP-TR-MC 802.2 802.5

This document specifies a method for the transmission of IP multicast datagrams over Token-Ring Local Area Networks. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1469 RFC1470 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices R. Enger J. Reynolds June 1993 ASCII HTML 192 NOCTOOLS

The goal of this FYI memo is to provide an update to FYI 2, RFC 1147 [1], which provided practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1147 FYI0002 INFORMATIONAL INFORMATIONAL IETF noctool2 10.17487/RFC1470 RFC1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII HTML 25 PPP/LCP MIB Management Framework PPP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Link Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1471 RFC1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII HTML 13 PPP/SEC MIB Management Framework PPP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Security Protocols on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1472 RFC1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII HTML 10 PPP/IP MIB Management Framework PPP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the IP Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1473 RFC1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII HTML 15 PPP/Bridge Management Framework PPP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the bridge Network Control Protocol [10] on subnetwork interfaces using the family of Point-to-Point Protocols. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1474 RFC1475 TP/IX: The Next Internet R. Ullmann June 1993 ASCII HTML 35 TP-IX IPv7 IPng

This memo presents the specification for version 7 of the Internet Protocol, as well as version 7 of the TCP and the user datagram protocol. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 RFC6814 HISTORIC EXPERIMENTAL IETF int tpix 10.17487/RFC1475 RFC1476 RAP: Internet Route Access Protocol R. Ullmann June 1993 ASCII HTML 20 RAP Routing

This RFC describes an open distance vector routing protocol for use at all levels of the internet, from isolated LANs to the major routers of an international commercial network provider. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 EXPERIMENTAL EXPERIMENTAL IETF int tpix 10.17487/RFC1476 RFC1477 IDPR as a Proposed Standard M. Steenstrup July 1993 ASCII HTML 13 Routing Policy

This document contains a discussion of inter-domain policy routing (IDPR), including an overview of functionality and a discussion of experiments. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL PROPOSED STANDARD IETF rtg idpr 10.17487/RFC1477 RFC1478 An Architecture for Inter-Domain Policy Routing M. Steenstrup June 1993 ASCII HTML 35 IDPR-ARCH IDPR

We present an architecture for inter-domain policy routing (IDPR). [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF rtg idpr 10.17487/RFC1478 RFC1479 Inter-Domain Policy Routing Protocol Specification: Version 1 M. Steenstrup July 1993 ASCII HTML 108 IDPR

We present the set of protocols and procedures that constitute Inter- Domain Policy Routing (IDPR). [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF rtg idpr 10.17487/RFC1479 RFC1480 The US Domain A. Cooper J. Postel June 1993 ASCII HTML 47 DNS top-level

This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1386 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1480 RFC1481 IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling C. Huitema July 1993 ASCII HTML 2 CIDR

CIDR is proposed as an immediate term strategy to extend the life of the current 32 bit IP address space. This memo provides information for the Internet community. It does not specify an Internet standard.

 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1481 RFC1482 Aggregation Support in the NSFNET Policy-Based Routing Database M. Knopper S. Richardson June 1993 ASCII HTML 11 CIDR

This document describes plans for support of route aggregation, as specified in the descriptions of Classless Inter-Domain Routing (CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone Network Service. This memo provides information for the Internet community. It does not specify an Internet standard.

 HISTORIC INFORMATIONAL IETF bgpdepl 10.17487/RFC1482 RFC1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5 J. Heinanen July 1993 ASCII HTML 16 ATM-ENCAP IP AAL5 over

This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. [STANDARDS-TRACK]

 RFC2684 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1483 RFC1484 Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2)) S. Hardcastle-Kille July 1993 ASCII HTML 25 X.500 directory names representing names

This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 RFC1781 RFC3494 HISTORIC EXPERIMENTAL IETF app osids 10.17487/RFC1484 RFC1485 A String Representation of Distinguished Names (OSI-DS 23 (v5)) S. Hardcastle-Kille July 1993 ASCII HTML 7 X.500 directory names representing names

When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. [STANDARDS-TRACK]

 RFC1779 RFC3494 HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1485 RFC1486 An Experiment in Remote Printing M. Rose C. Malamud July 1993 ASCII HTML 14 electronic mail facsimile

This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 RFC1528 RFC1529 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1486 RFC1487 X.500 Lightweight Directory Access Protocol W. Yeong T. Howes S. Kille July 1993 ASCII HTML 21 X.500 DAP interactive access

The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]

 RFC1777 RFC3494 HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1487 RFC1488 The X.500 String Representation of Standard Attribute Syntaxes T. Howes S. Kille W. Yeong C. Robbins July 1993 ASCII HTML 11 X.500 LDAP lightweight directory protocol

This document defines the requirements that must be satisfied by encoding rules used to render Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3]. [STANDARDS-TRACK]

 RFC1778 PROPOSED STANDARD PROPOSED STANDARD IETF app osids 10.17487/RFC1488 RFC1489 Registration of a Cyrillic Character Set A. Chernov July 1993 ASCII HTML 5

Though the proposed character set "koi8-r" is not currently an international standard, there is very large user community (including Relcom Net) supporting it. Factually, "koi8-r" is de-facto standard for Unix and global network applications in the former Soviet Union. This is the reason the Society of Unix User Groups (SUUG) believes "koi8-r" should be registered. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1489 RFC1490 Multiprotocol Interconnect over Frame Relay T. Bradley C. Brown A. Malis July 1993 ASCII HTML 35 standard standards IP over

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. Additionally, it describes a simple fragmentation procedure for carrying large frames over a frame relay network with a smaller MTU. [STANDARDS-TRACK]

 RFC1294 RFC2427 DRAFT STANDARD DRAFT STANDARD IETF int iplpdn 10.17487/RFC1490 RFC1491 A Survey of Advanced Usages of X.500 C. Weider R. Wright July 1993 ASCII HTML 18 directory

This document is the result of a survey asking people to detail their advanced usages of X.500. It is intended to show how various organizations are using X.500 in ways which extend the view of X.500 as a "White Pages" service. This RFC is a product of the Integrated Directory Services Working Group of the Application and User Services Areas of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard.

 FYI0021 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1491 RFC1492 An Access Control Protocol, Sometimes Called TACACS C. Finseth July 1993 ASCII HTML 21 TACACS Terminal Server TAC

This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1492 RFC1493 Definitions of Managed Objects for Bridges E. Decker P. Langille A. Rijsinghani K. McCloghrie July 1993 ASCII HTML 34 BRIDGE-MIB SNMP MIB standard standards

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing MAC bridges based on the IEEE 802.1D-1990 standard between Local Area Network (LAN) segments. [STANDARDS-TRACK]

 RFC1286 RFC4188 DRAFT STANDARD DRAFT STANDARD IETF ops bridge 10.17487/RFC1493 RFC1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies H. Alvestrand S. Thompson August 1993 ASCII HTML 19 Equiv Mail

This document describes the content of the "IANA MHS/MIME Equivalence table", and defines the initial configuration of this table. Mappings for new MIME content-types and/or X.400 body part types should be registered with the IANA to minimize redundancy and promote interoperability. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF app mimemhs 10.17487/RFC1494 RFC1495 Mapping between X.400 and RFC-822 Message Bodies H. Alvestrand S. Kille R. Miles M. Rose S. Thompson August 1993 ASCII HTML 11 Mail

Since the introduction of X.400(84), there has been work ongoing for defining mappings between MHS and RFC-822. The most recent work in this area is RFC-1327 [3], which focuses primarily on translation of envelope and headers. This document is complimentary to RFC-1327 as it focuses on translation of the message body. [STANDARDS-TRACK]

 RFC2156 RFC1327 PROPOSED STANDARD PROPOSED STANDARD IETF app mimemhs 10.17487/RFC1495 RFC1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages H. Alvestrand J. Romaguera K. Jordan August 1993 ASCII HTML 5 HARPOON Mail

This document describes how RFC-1328 must be modified in order to provide adequate support for the scenarios: It replaces chapter 6 of RFC-1328. The rest of RFC-1328 is NOT obsoleted. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF app mimemhs 10.17487/RFC1496 RFC1497 BOOTP Vendor Information Extensions J. Reynolds August 1993 ASCII HTML 8 TAGS Boot

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP).

 RFC1395 RFC1084 RFC1048 RFC1533 RFC0951 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1497 RFC1498 On the Naming and Binding of Network Destinations J. Saltzer August 1993 ASCII HTML 10 NAMES Addresses Routes Objects Nodes Paths

This brief paper offers a perspective on the subject of names of destinations in data communication networks. It suggests two ideas: First, it is helpful to distinguish among four different kinds of objects that may be named as the destination of a packet in a network. Second, the operating system concept of binding is a useful way to describe the relations among the four kinds of objects. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1498 10.17487/RFC1498 RFC1499 Summary of 1400-1499 J. Elliott January 1997 ASCII HTML 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1499 RFC1500 Internet Official Protocol Standards J. Postel August 1993 ASCII HTML 36 IAB

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]

 RFC1410 RFC1540 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1500 RFC1501 OS/2 User Group E. Brunsen August 1993 ASCII HTML 2

Memo soliciting reactions to the proposal of a OS/2 User Group. This memo provides information for the Internet community. This memo does not specify an IAB standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1501 RFC1502 X.400 Use of Extended Character Sets H. Alvestrand August 1993 ASCII HTML 14 Mail

This RFC defines a suggested method of using "GeneralText" in order to harmonize as much as possible the usage of this body part. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF app x400ops 10.17487/RFC1502 RFC1503 Algorithms for Automating Administration in SNMPv2 Managers K. McCloghrie M. Rose August 1993 ASCII HTML 14 Management SNMP

When a user invokes an SNMPv2 management application, it may be desirable for the user to specify the minimum amount of information necessary to establish and maintain SNMPv2 communications. This memo suggests an approach to achieve this goal. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1503 RFC1504 Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing A. Oppenheimer August 1993 ASCII HTML 82 AVRP

This document provides detailed information about the AppleTalk Update- based Routing Protocol (AURP) and wide area routing. AURP provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1504 RFC1505 Encoding Header Field for Internet Messages A. Costanzo D. Robinson R. Ullmann August 1993 ASCII HTML 36 EHF-MAIL Mail

This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages. It replaces RFC 1154. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 RFC1154 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1505 RFC1506 A Tutorial on Gatewaying between X.400 and Internet Mail J. Houttuin August 1993 ASCII HTML 39 822 email RTR

This tutorial was produced especially to help new gateway managers find their way into the complicated subject of mail gatewaying according to RFC 1327. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1506 RFC1507 DASS - Distributed Authentication Security Service C. Kaufman September 1993 ASCII HTML 119 DASS CAT

The goal of DASS is to provide authentication services in a distributed environment which are both more secure and easier to use than existing mechanisms. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 EXPERIMENTAL EXPERIMENTAL IETF sec cat 10.17487/RFC1507 RFC1508 Generic Security Service Application Program Interface J. Linn September 1993 ASCII HTML 49 CAT,GSS,API

This Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK]

 RFC2078 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC1508 RFC1509 Generic Security Service API : C-bindings J. Wray September 1993 ASCII HTML 48 GSSAPI CAT,GSS

This document specifies C language bindings for the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other documents. [STANDARDS-TRACK]

 RFC2744 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC1509 RFC1510 The Kerberos Network Authentication Service (V5) J. Kohl C. Neuman September 1993 ASCII HTML 112 KERBEROS CAT Security

This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. [STANDARDS-TRACK]

 RFC4120 RFC6649 HISTORIC PROPOSED STANDARD IETF sec cat http://www.rfc-editor.org/errata_search.php?rfc=1510 10.17487/RFC1510 RFC1511 Common Authentication Technology Overview J. Linn September 1993 ASCII HTML 2 CAT,Security

This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1511 RFC1512 FDDI Management Information Base J. Case A. Rijsinghani September 1993 ASCII HTML 51 FDDI-MIB MIB SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing devices which implement the FDDI based on the ANSI FDDI SMT 7.3 draft standard, which has been forwarded for publication by the X3T9.5 committee.

 RFC1285 HISTORIC PROPOSED STANDARD IETF fddimib 10.17487/RFC1512 RFC1513 Token Ring Extensions to the Remote Network Monitoring MIB S. Waldbusser September 1993 ASCII HTML 55 Monitoring SNMP

This memo defines extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks. [STANDARDS-TRACK]

 RFC1271 HISTORIC PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC1513 RFC1514 Host Resources MIB P. Grillo S. Waldbusser September 1993 ASCII HTML 33 HOST-MIB Management SNMP

This memo defines a MIB for use with managing host systems. [STANDARDS-TRACK]

 RFC2790 PROPOSED STANDARD PROPOSED STANDARD IETF hostmib 10.17487/RFC1514 RFC1515 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) D. McMaster K. McCloghrie S. Roberts September 1993 ASCII HTML 25 MIB Management SNMP

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). [STANDARDS-TRACK]

 RFC3636 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC1515 RFC1516 Definitions of Managed Objects for IEEE 802.3 Repeater Devices D. McMaster K. McCloghrie September 1993 ASCII HTML 40 Management SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as "hubs." [STANDARDS-TRACK]

 RFC1368 RFC2108 DRAFT STANDARD DRAFT STANDARD IETF ops hubmib 10.17487/RFC1516 RFC1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) Internet Engineering Steering Group R. Hinden September 1993 ASCII HTML 4 CIDR Address

Classless Inter-Domain Routing (CIDR) defines a mechanism to slow the growth of routing tables and reduce the need to allocate new IP network numbers. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF IESG http://www.rfc-editor.org/errata_search.php?rfc=1517 10.17487/RFC1517 RFC1518 An Architecture for IP Address Allocation with CIDR Y. Rekhter T. Li September 1993 ASCII HTML 27 CIDR-ARCH Classless Routing

This paper provides an architecture and a plan for allocating IP addresses in the Internet. This architecture and the plan are intended to play an important role in steering the Internet towards the Address Assignment and Aggregating Strategy. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1518 RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy V. Fuller T. Li J. Yu K. Varadhan September 1993 ASCII HTML 24 CIDR-STRA

This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers. [STANDARDS-TRACK]

 RFC1338 RFC4632 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1519 10.17487/RFC1519 RFC1520 Exchanging Routing Information Across Provider Boundaries in the CIDR Environment Y. Rekhter C. Topolcic September 1993 ASCII HTML 9 Classless Routing

The purpose of this document is twofold. First, it describes various alternatives for exchanging inter-domain routing information across domain boundaries, where one of the peering domain is CIDR-capable and another is not. Second, it addresses the implications of running CIDR- capable inter-domain routing protocols (e.g., BGP-4, IDRP) on intra- domain routing. This memo provides information for the Internet community. It does not specify an Internet standard.

 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1520 RFC1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies N. Borenstein N. Freed September 1993 ASCII PS PDF HTML 81 email multimedia

This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work. [STANDARDS-TRACK]

 RFC1341 RFC2045 RFC2046 RFC2047 RFC2048 RFC2049 RFC1590 DRAFT STANDARD DRAFT STANDARD IETF app 822ext 10.17487/RFC1521 RFC1522 MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text K. Moore September 1993 ASCII HTML 10 email character

This memo describes an extension to the message format defined in RFC 1521, to allow the representation of character sets other than ASCII in RFC 822 (STD 11) message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521.

 RFC1342 RFC2045 RFC2046 RFC2047 RFC2048 RFC2049 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=1522 10.17487/RFC1522 RFC1523 The text/enriched MIME Content-type N. Borenstein September 1993 ASCII HTML 15 email mail richtext

MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1563 RFC1896 INFORMATIONAL INFORMATIONAL IETF app 822ext 10.17487/RFC1523 RFC1524 A User Agent Configuration Mechanism For Multimedia Mail Format Information N. Borenstein September 1993 ASCII HTML 12 MIME email mailcap

This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1524 10.17487/RFC1524 RFC1525 Definitions of Managed Objects for Source Routing Bridges E. Decker K. McCloghrie P. Langille A. Rijsinghani September 1993 ASCII HTML 18 SRB-MIB MIB Management SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing source routing and source routing transparent bridges. These bridges are also required to implement relevant groups in the Bridge MIB. [STANDARDS-TRACK]

 RFC1286 HISTORIC PROPOSED STANDARD IETF ops bridge 10.17487/RFC1525 RFC1526 Assignment of System Identifiers for TUBA/CLNP Hosts D. Piscitello September 1993 ASCII HTML 8 NSAP Address

This document describes conventions whereby the system identifier portion of an RFC 1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF int tuba 10.17487/RFC1526 RFC1527 What Should We Plan Given the Dilemma of the Network? G. Cook September 1993 ASCII HTML 17

The Internet community needs to be asking what the most important policy issues facing the network are. And given agreement on any particular set of policy issues, the next thing we should be asking is, what would be some of the political choices that would follow for Congress to make? This memo is a shortened version of the suggested policy draft. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1527 RFC1528 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures C. Malamud M. Rose October 1993 ASCII HTML 12 REM-PRINT FAX Facsimile

This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

 RFC1486 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1528 RFC1529 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies C. Malamud M. Rose October 1993 ASCII HTML 5 FAX Facsimile

This document defines the administrative policies for the operation of remote printer facilities within the context of the tpc.int subdomain. The document describes different approaches to resource recovery for remote printer server sites and includes discussions of issues pertaining to auditing, security, and denial of access. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1486 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1529 RFC1530 Principles of Operation for the TPC.INT Subdomain: General Principles and Policy C. Malamud M. Rose October 1993 ASCII HTML 7 FAX Facsimile

This document defines the initial principles of operation for the tpc.int subdomain, a collection of service listings accessible over the Internet infrastructure through an administered namespace contained within the Domain Name System. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1530 RFC1531 Dynamic Host Configuration Protocol R. Droms October 1993 ASCII HTML 39 DHCP

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. [STANDARDS-TRACK]

 RFC1541 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=1531 10.17487/RFC1531 RFC1532 Clarifications and Extensions for the Bootstrap Protocol W. Wimer October 1993 ASCII HTML 22 BOOTP

Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK]

 RFC1542 RFC0951 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC1532 RFC1533 DHCP Options and BOOTP Vendor Extensions S. Alexander R. Droms October 1993 ASCII HTML 30 Dynamic Host Configuration Bootstrap

This document specifies the current set of DHCP options. [STANDARDS-TRACK]

 RFC1497 RFC1395 RFC1084 RFC1048 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=1533 10.17487/RFC1533 RFC1534 Interoperation Between DHCP and BOOTP R. Droms October 1993 ASCII HTML 4 DHCP-BOOTP Dynamic Host Configuration Bootstrap

DHCP provides a superset of the functions provided by BOOTP. This document describes the interactions between DHCP and BOOTP network participants. [STANDARDS-TRACK]

 DRAFT STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=1534 10.17487/RFC1534 RFC1535 A Security Problem and Proposed Correction With Widely Deployed DNS Software E. Gavron October 1993 ASCII HTML 5 Domain Name System

This document discusses a flaw in some of the currently distributed name resolver clients. The flaw exposes a security weakness related to the search heuristic invoked by these same resolvers when users provide a partial domain name, and which is easy to exploit. This document points out the flaw, a case in point, and a solution. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1535 10.17487/RFC1535 RFC1536 Common DNS Implementation Errors and Suggested Fixes A. Kumar J. Postel C. Neuman P. Danzig S. Miller October 1993 ASCII HTML 12 Domain Name System

This memo describes common errors seen in DNS implementations and suggests some fixes. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC9210 INFORMATIONAL INFORMATIONAL IETF int dns 10.17487/RFC1536 RFC1537 Common DNS Data File Configuration Errors P. Beertema October 1993 ASCII HTML 9 Domain Name System

This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time. This memo provides information for the Internet community. It does not specify an Internet standard.

 RFC1912 INFORMATIONAL INFORMATIONAL IETF int dns 10.17487/RFC1537 RFC1538 Advanced SNA/IP : A Simple SNA Transport Protocol W. Behl B. Sterling W. Teskey October 1993 ASCII HTML 10 ADSNA-IP Domain Name System

This RFC provides information for the Internet community about a method for establishing and maintaining SNA sessions over an IP internet. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1538 RFC1539 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force G. Malkin October 1993 ASCII HTML 22 Introduction

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 17]

 RFC1391 RFC1718 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1539 RFC1540 Internet Official Protocol Standards J. Postel October 1993 ASCII HTML 34 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]

 RFC1500 RFC1600 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1540 RFC1541 Dynamic Host Configuration Protocol R. Droms October 1993 ASCII HTML 39 DHCP

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP) adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]

 RFC1531 RFC2131 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1541 RFC1542 Clarifications and Extensions for the Bootstrap Protocol W. Wimer October 1993 ASCII HTML 23 BOOTP

Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called "BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK]

 RFC1532 RFC0951 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1542 10.17487/RFC1542 RFC1543 Instructions to RFC Authors J. Postel October 1993 ASCII HTML 16 Request For Comment

This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1111 RFC0825 RFC2223 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1543 RFC1544 The Content-MD5 Header Field M. Rose November 1993 ASCII HTML 3 MIME EMail Integrity MIC Digest

This memo defines the use of an optional header field, Content-MD5, which may be used as a message integrity check (MIC), to verify that the decoded data are the same data that were initially sent. [STANDARDS-TRACK]

 RFC1864 PROPOSED STANDARD PROPOSED STANDARD IETF app 822ext 10.17487/RFC1544 RFC1545 FTP Operation Over Big Address Records (FOOBAR) D. Piscitello November 1993 ASCII HTML 5 FTP File Transfer PORT PASV LPRT LPSV

This RFC specifies a method for assigning long addresses in the HOST- PORT specification for the data port to be used in establishing a data connection for File Transfer Protocol, FTP (STD 9, RFC 959). This is a general solution, applicable for all "next generation" IP alternatives, and can also be extended to allow FTP operation over transport interfaces other than TCP. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1639 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1545 RFC1546 Host Anycasting Service C. Partridge T. Mendez W. Milliken November 1993 ASCII HTML 9 Resource Location Multicasting

This RFC describes an internet anycasting service for IP. The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC1546 RFC1547 Requirements for an Internet Standard Point-to-Point Protocol D. Perkins December 1993 ASCII HTML 21 PPP link serial line

This document discusses the evaluation criteria for an Internet Standard Data Link Layer protocol to be used with point-to-point links. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1547 RFC1548 The Point-to-Point Protocol (PPP) W. Simpson December 1993 ASCII HTML 53 link serial line

This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]

 RFC1331 RFC1661 RFC1570 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1548 RFC1549 PPP in HDLC Framing W. Simpson Editor December 1993 ASCII HTML 18 point link serial line

This document describes the use of HDLC for framing PPP encapsulated packets. [STANDARDS-TRACK]

 RFC1662 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1549 RFC1550 IP: Next Generation (IPng) White Paper Solicitation S. Bradner A. Mankin December 1993 ASCII HTML 6

This memo solicits white papers on topics related to the IPng requirements and selection criteria. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1550 RFC1551 Novell IPX Over Various WAN Media (IPXWAN) M. Allen December 1993 ASCII HTML 22 Internetworking Packet Exchange

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1634 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1551 RFC1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP) W. Simpson December 1993 ASCII HTML 16 IPXCP IPX point serial line link

This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1552 RFC1553 Compressing IPX Headers Over WAN Media (CIPX) S. Mathur M. Lewis December 1993 ASCII HTML 23 CIPX Internetworking Packet Exchange

This document describes a method for compressing the headers of IPX datagrams (CIPX). [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1553 RFC1554 ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP M. Ohta K. Handa December 1993 ASCII HTML 6 Character Set Japanese

This memo describes a text encoding scheme: "ISO-2022-JP-2", which is used experimentally for electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. The encoding is a multilingual extension of "ISO-2022-JP", the existing encoding for Japanese [2022JP]. The encoding is supported by an Emacs based multilingual text editor: MULE [MULE]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1554 RFC1555 Hebrew Character Encoding for Internet Messages H. Nussbacher Y. Bourvine December 1993 ASCII HTML 5 Character Set

This document describes the encoding used in electronic mail [RFC822] for transferring Hebrew. The standard devised makes use of MIME [RFC1521] and ISO-8859-8. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1555 RFC1556 Handling of Bi-directional Texts in MIME H. Nussbacher December 1993 ASCII HTML 3 Character Set

This document describes the format and syntax of the "direction" keyword to be used with bi-directional texts in MIME. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1556 RFC1557 Korean Character Encoding for Internet Messages U. Choi K. Chon H. Park December 1993 ASCII HTML 5 Character Set

This document describes the encoding method being used to represent Korean characters in both header and body part of the Internet mail messages [RFC822]. This encoding method was specified in 1991, and has since then been used. It has now widely being used in Korean IP networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1557 10.17487/RFC1557 RFC1558 A String Representation of LDAP Search Filters T. Howes December 1993 ASCII HTML 3 X.500 Directory

The Lightweight Directory Access Protocol (LDAP) defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1960 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1558 RFC1559 DECnet Phase IV MIB Extensions J. Saperia December 1993 ASCII HTML 69 DECNET-MIB Management SNMP

This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. It reflects changes which are the result of operational experience based on RFC 1289. [STANDARDS-TRACK]

 RFC1289 DRAFT STANDARD DRAFT STANDARD IETF decnetiv 10.17487/RFC1559 RFC1560 The MultiProtocol Internet B. Leiner Y. Rekhter December 1993 ASCII HTML 7 Architecture Protocol

There has recently been considerable discussion on two topics: MultiProtocol approaches in the Internet and the selection of a next generation Internet Protocol. This document suggests a strawman position for goals and approaches for the IETF/IESG/IAB in these areas. It takes the view that these two topics are related, and proposes directions for the IETF/IESG/IAB to pursue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1560 RFC1561 Use of ISO CLNP in TUBA Environments D. Piscitello December 1993 ASCII HTML 25 CLNP-TUBA OSI IP Internet Protocol

This memo specifies a profile of the ISO/IEC 8473 Connectionless-mode Network Layer Protocol for use in conjunction with RFC 1347, TCP/UDP over Bigger Addresses. It describes the use of CLNP to provide the lower-level service expected by Transmission Control Protocol and User Datagram Protocol. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL IETF int tuba 10.17487/RFC1561 RFC1562 Naming Guidelines for the AARNet X.500 Directory Service G. Michaelson M. Prior December 1993 ASCII HTML 4 Australia

This document is an AARNet (Australian Academic and Research Network) Engineering Note (AEN-001). AARNet Engineering Notes are engineering documents of the AARNet Engineering Working Group, and record current or proposed operational practices related to the provision of Internetworking services within Australia, and AARNet in particular. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1562 RFC1563 The text/enriched MIME Content-type N. Borenstein January 1994 ASCII PS PDF HTML 16 email mail richtext

MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1523 RFC1896 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1563 RFC1564 DSA Metrics (OSI-DS 34 (v3)) P. Barker R. Hedberg January 1994 ASCII HTML 21 x.500 Directory Service Agent

This document defines a set of criteria by which a DSA implementation may be judged. Particular issues covered include conformance to standards; performance; demonstrated interoperability. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1564 RFC1565 Network Services Monitoring MIB S. Kille N. Freed January 1994 ASCII HTML 17 Management Information Base

This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. [STANDARDS-TRACK]

 RFC2248 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC1565 RFC1566 Mail Monitoring MIB S. Kille N. Freed January 1994 ASCII HTML 20 Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this memo extends the basic Network Services Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS-TRACK]

 RFC2249 RFC2789 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC1566 RFC1567 X.500 Directory Monitoring MIB G. Mansfield S. Kille January 1994 ASCII HTML 18 X500-MIB Management Information Base

This document defines a portion of the Management Information Base (MIB). It defines the MIB for monitoring Directory System Agents (DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs. [STANDARDS-TRACK]

 RFC2605 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC1567 RFC1568 Simple Network Paging Protocol - Version 1(b) A. Gwinn January 1994 ASCII HTML 8 Beeper

This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1645 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1568 RFC1569 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures M. Rose January 1994 ASCII HTML 6 Beeper

This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1703 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1569 RFC1570 PPP LCP Extensions W. Simpson Editor January 1994 ASCII HTML 19 PPP-LCP Point-to Point Link Control Protocol serial line

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines several additional LCP features which have been suggested over the past few years. [STANDARDS-TRACK]

 RFC1548 RFC2484 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1570 RFC1571 Telnet Environment Option Interoperability Issues D. Borman January 1994 ASCII HTML 4

This document describes a method for allowing implementors to ensure that their implementation of the Environment option will be interoperable with as many other implementations as possible, by providing a set of heuristics that can be used to help identify which definitions for VAR and VALUE are being used by the other side of the connection. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1408 INFORMATIONAL INFORMATIONAL IETF app telnet 10.17487/RFC1571 RFC1572 Telnet Environment Option S. Alexander Editor January 1994 ASCII HTML 7 TOPT-ENVIR

This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app telnet 10.17487/RFC1572 RFC1573 Evolution of the Interfaces Group of MIB-II K. McCloghrie F. Kastenholz January 1994 ASCII HTML 55 Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANARDS-TRACK]

 RFC1229 RFC2233 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC1573 RFC1574 Essential Tools for the OSI Internet S. Hares C. Wittbrodt February 1994 ASCII HTML 13 Echo Traceroute Routing Table CLNP

This document specifies the following three necessary tools to debug problems in the deployment and maintenance of networks using ISO 8473 (CLNP): ping or OSI Echo function, traceroute function which uses the OSI Echo function, and routing table dump function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1139 INFORMATIONAL INFORMATIONAL IETF noop 10.17487/RFC1574 RFC1575 An Echo Function for CLNP (ISO 8473) S. Hares C. Wittbrodt February 1994 ASCII HTML 9 ISO-TS-ECHO

This memo defines an echo function for the connection-less network layer protocol. The mechanism that is mandated here is in the final process of being standardized by ISO as "Amendment X: Addition of an Echo function to ISO 8473" an integral part of Version 2 of ISO 8473. [STANDARDS-TRACK]

 RFC1139 DRAFT STANDARD DRAFT STANDARD IETF noop 10.17487/RFC1575 RFC1576 TN3270 Current Practices J. Penner January 1994 ASCII HTML 12 Telnet Option Terminal Type EOR Binary

This document describes the existing implementation of transferring 3270 display terminal data using currently available telnet capabilities. The name traditionally associated with this implementation is TN3270. This memo provides information for the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app tn3270e 10.17487/RFC1576 RFC1577 Classical IP and ARP over ATM M. Laubach January 1994 ASCII HTML 17 Internet Protocol Address Resolution Asynchronous Transmission Mode

This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]

 RFC2225 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1577 RFC1578 FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions J. Sellers February 1994 ASCII HTML 53 K12

The goal of this FYI RFC is to document the questions most commonly asked about the Internet by those in the primary and secondary school community, and to provide pointers to sources which answer those questions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 22]

 RFC1941 INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1578 RFC1579 Firewall-Friendly FTP S. Bellovin February 1994 ASCII HTML 4 file transfer PORT PASV Security

This memo describes a suggested change to the behavior of FTP client programs. This document provides information for the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1579 RFC1580 Guide to Network Resource Tools EARN Staff March 1994 ASCII HTML 107 EARN BITNET Gopher World-Wide Web WWW WAIS Archie Whois X.500 Netfind Trickle BIFTP Listserv Netnews Astra NetServ Mail Base Prospero IRC Relay

The purpose of this guide is to supply the basic information that anyone on the network needs to try out and begin using tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 23]

 FYI0023 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1580 RFC1581 Protocol Analysis for Extensions to RIP to Support Demand Circuits G. Meyer February 1994 ASCII HTML 4 routing Protocol

As required by Routing Protocol Criteria, this report documents the key features of Routing over Demand Circuits on Wide Area Networks - RIP and the current implementation experience. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1581 RFC1582 Extensions to RIP to Support Demand Circuits G. Meyer February 1994 ASCII HTML 29 RIP-DC routing Protocol

This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1582 RFC1583 OSPF Version 2 J. Moy March 1994 ASCII PS PDF HTML 216 equal-cost multipath link state LSA

This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]

 RFC1247 RFC2178 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1583 RFC1584 Multicast Extensions to OSPF J. Moy March 1994 ASCII PS PDF HTML 102 OSPF-Multi Open Shortest Path First

This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1584 RFC1585 MOSPF: Analysis and Experience J. Moy March 1994 ASCII HTML 13 Multicast Open Shortest Path First OSPF

This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by "Internet Engineering Task Force internet routing protocol standardization criteria" ([RFC 1264]). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1585 RFC1586 Guidelines for Running OSPF Over Frame Relay Networks O. deSouza M. Rodrigues March 1994 ASCII HTML 6 FR Open Shortest Path First

This memo specifies guidelines for implementors and users of the Open Shortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC1586 RFC1587 The OSPF NSSA Option R. Coltun V. Fuller March 1994 ASCII HTML 17 OSPF-NSSA Open Shortest Path First not so stubby area routing protocol

This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. [STANDARDS-TRACK]

 RFC3101 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC1587 RFC1588 White Pages Meeting Report J. Postel C. Anderson February 1994 ASCII HTML 35 X-500 directory

This report describes the results of a meeting held at the November IETF (Internet Engineering Task Force) in Houston, TX, on November 2, 1993, to discuss the future of and approaches to a white pages directory services for the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1588 RFC1589 A Kernel Model for Precision Timekeeping D. Mills March 1994 ASCII HTML 37 Time NTP Clock

This memorandum describes an engineering model which implements a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators and phase-lock loops (PLL) often found in the engineering literature. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1589 RFC1590 Media Type Registration Procedure J. Postel March 1994 ASCII HTML 7 email multimedia

Several questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications. This document addresses these issues and specifies a procedure for the registration of new Media Types (content-type/subtypes). It also generalizes the scope of use of these Media Types to make it appropriate to use the same registrations and specifications with other applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2045 RFC2046 RFC2047 RFC2048 RFC2049 RFC1521 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1590 RFC1591 Domain Name System Structure and Delegation J. Postel March 1994 ASCII HTML 7 DNS Policy Top-Level TLD

This memo provides some information on the structure of the names in the Domain Name System (DNS), specifically the top-level domain names; and on the administration of domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1591 RFC1592 Simple Network Management Protocol Distributed Protocol Interface Version 2.0 B. Wijnen G. Carpenter K. Curran A. Sehgal G. Waters March 1994 ASCII HTML 54 SNMP-DPI SNMP DPT IBM

This RFC describes version 2.0 of a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1228 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1592 RFC1593 SNA APPN Node MIB W. McKenzie J. Cheng March 1994 ASCII HTML 120 IBM Management

This RFC describes IBM's SNMP support for SNA Advanced Peer-to-Peer Networking (APPN) nodes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1593 RFC1594 FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions A. Marine J. Reynolds G. Malkin March 1994 ASCII HTML 44 documentation help information FAQ

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 4]

 RFC1325 RFC2664 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC1594 RFC1595 Definitions of Managed Objects for the SONET/SDH Interface Type T. Brown K. Tesink March 1994 ASCII HTML 59 SONET-MIB MIB Management SNMP RFC2558 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC1595 RFC1596 Definitions of Managed Objects for Frame Relay Service T. Brown Editor March 1994 ASCII HTML 46 FR MIB Management SNMP RFC1604 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC1596 RFC1597 Address Allocation for Private Internets Y. Rekhter B. Moskowitz D. Karrenberg G. de Groot March 1994 ASCII HTML 8 IP Network Number Local

This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1918 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1597 RFC1598 PPP in X.25 W. Simpson March 1994 ASCII HTML 8 PPP-X25 point

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of X.25 for framing PPP encapsulated packets. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1598 RFC1599 Summary of 1500-1599 M. Kennedy January 1997 ASCII HTML 22 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1599 RFC1600 Internet Official Protocol Standards J. Postel March 1994 ASCII HTML 36 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

 RFC1540 RFC1610 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1600 RFC1601 Charter of the Internet Architecture Board (IAB) C. Huitema March 1994 ASCII HTML 6 ISOC Internet Society IETF IRTF

This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1358 RFC2850 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1601 RFC1602 The Internet Standards Process -- Revision 2 Internet Architecture Board Internet Engineering Steering Group March 1994 ASCII HTML 37

This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1310 RFC2026 RFC1871 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1602 RFC1603 IETF Working Group Guidelines and Procedures E. Huizer D. Crocker March 1994 ASCII HTML 29 WG

This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2418 RFC1871 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1603 RFC1604 Definitions of Managed Objects for Frame Relay Service T. Brown Editor March 1994 ASCII HTML 46 FR-MIB MIB Management SNMP Network

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK]

 RFC1596 RFC2954 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1604 RFC1605 SONET to Sonnet Translation W. Shakespeare April 1 1994 ASCII HTML 3 Humor

Because Synchronous Optical Network (SONET) transmits data in frames of bytes, it is fairly easy to envision ways to compress SONET frames to yield higher bandwidth over a given fiber optic link. This memo describes a particular method, SONET Over Novel English Translation (SONNET). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1605 RFC1606 A Historical Perspective On The Usage Of IP Version 9 J. Onions April 1 1994 ASCII HTML 4 Humor

This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1606 10.17487/RFC1606 RFC1607 A VIEW FROM THE 21ST CENTURY V. Cerf April 1 1994 ASCII HTML 14 V. Cerf

This document is a composition of letters discussing a possible future. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1607 RFC1608 Representing IP Information in the X.500 Directory T. Johannsen G. Mansfield M. Kosters S. Sataluri March 1994 ASCII HTML 20 X500-DIR Data Structure Schemo

This document describes the objects necessary to include information about IP networks and IP numbers in the X.500 Directory. It extends the work "Charting networks in the X.500 Directory" [1] where a general framework is presented for representing networks in the Directory by applying it to IP networks. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app osids 10.17487/RFC1608 RFC1609 Charting Networks in the X.500 Directory G. Mansfield T. Johannsen M. Knopper March 1994 ASCII HTML 15 X500-CHART Data Structure Schemo

This document presents a model in which a communication network with all its related details and descriptions can be represented in the X.500 Directory. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app osids http://www.rfc-editor.org/errata_search.php?rfc=1609 10.17487/RFC1609 RFC1610 Internet Official Protocol Standards J. Postel July 1994 ASCII HTML 36 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

 RFC1600 RFC1720 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1610 RFC1611 DNS Server MIB Extensions R. Austein J. Saperia May 1994 ASCII HTML 30 DNS-S-MIB Domain Name System Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS name server functions. This memo was produced by the DNS working group. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int dns 10.17487/RFC1611 RFC1612 DNS Resolver MIB Extensions R. Austein J. Saperia May 1994 ASCII HTML 32 DNS-R-MIB Domain Name System Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS resolver functions. This memo was produced by the DNS working group. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int dns 10.17487/RFC1612 RFC1613 cisco Systems X.25 over TCP (XOT) J. Forster G. Satz G. Glick R. Day May 1994 ASCII HTML 13 Transmission Control Protocol

This memo documents a method of sending X.25 packets over IP internets by encapsulating the X.25 Packet Level in TCP packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1613 RFC1614 Network Access to Multimedia Information C. Adie May 1994 ASCII HTML 79 RARE Technical Report

This report summarises the requirements of research and academic network users for network access to multimedia information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF tsv imm 10.17487/RFC1614 RFC1615 Migrating from X.400(84) to X.400(88) J. Houttuin J. Craigie May 1994 ASCII HTML 17 RARE Technical Report email

This document compares X.400(88) to X.400(84) and describes what problems can be anticipated in the migration, especially considering the migration from the existing X.400(84) infrastructure created by the COSINE MHS project to an X.400(88) infrastructure. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1615 RFC1616 X.400(1988) for the Academic and Research Community in Europe RARE WG-MSG Task Force 88 E. Huizer Editor J. Romaguera Editor May 1994 ASCII HTML 44 RARE Technical Report email

The report documents the results of a task force on X.400(1988) deployment of the RARE Mails and Messaging Work Group during the period from November 1992 until October 1993. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1616 RFC1617 Naming and Structuring Guidelines for X.500 Directory Pilots P. Barker S. Kille T. Lenggenhager May 1994 ASCII HTML 28 RARE Technical Report White Pages

This document defines a number of naming and structuring guidelines focused on White Pages usage. Alignment to these guidelines is recommended for directory pilots. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1384 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1617 RFC1618 PPP over ISDN W. Simpson May 1994 ASCII HTML 7 PPP-ISDN Point Integrated Services Digital Network

This document describes the use of PPP over Integrated Services Digital Network (ISDN) switched circuits. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1618 RFC1619 PPP over SONET/SDH W. Simpson May 1994 ASCII HTML 5 PPP-SONET Point Synchronous Optical Network Digital Heirarchy

This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Heirarchy (SDH) circuits. [STANDARDS-TRACK]

 RFC2615 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1619 RFC1620 Internet Architecture Extensions for Shared Media B. Braden J. Postel Y. Rekhter May 1994 ASCII HTML 19 Public data networks ARP address resolution protocol

This memo discusses alternative approaches to extending the Internet architecture to eliminate some or all unnecessary hops. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1620 RFC1621 Pip Near-term Architecture P. Francis May 1994 ASCII HTML 51 Internet Protocol IPng

The purpose of this RFC and the companion RFC "Pip Header Processing" are to record the ideas (good and bad) of Pip. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 HISTORIC INFORMATIONAL IETF int pip 10.17487/RFC1621 RFC1622 Pip Header Processing P. Francis May 1994 ASCII HTML 16 Internet Protocol IPng

The purpose of this RFC and the companion RFC "Pip Near-term Architecture" are to record the ideas (good and bad) of Pip. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 HISTORIC INFORMATIONAL IETF int pip 10.17487/RFC1622 RFC1623 Definitions of Managed Objects for the Ethernet-like Interface Types F. Kastenholz May 1994 ASCII HTML 19 MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

 RFC1398 RFC1643 HISTORIC INTERNET STANDARD IETF int ifmib 10.17487/RFC1623 RFC1624 Computation of the Internet Checksum via Incremental Update A. Rijsinghani Editor May 1994 ASCII HTML 6

This memo describes an updated technique for incremental computation of the standard Internet checksum. It updates the method described in RFC 1141. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1141 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1624 10.17487/RFC1624 RFC1625 WAIS over Z39.50-1988 M. St. Pierre J. Fullton K. Gamiel J. Goldman B. Kahle J. Kunze H. Morris F. Schiettecatte June 1994 ASCII HTML 7 Wide Area Information Servers Library

The purpose of this memo is to initiate a discussion for a migration path of the WAIS technology from Z39.50-1988 Information Retrieval Service Definitions and Protocol Specification for Library Applications [1] to Z39.50-1992 [2] and then to Z39.50-1994 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1625 RFC1626 Default IP MTU for use over ATM AAL5 R. Atkinson May 1994 ASCII HTML 5 Maximum Transmission Unit Asynchronous Transfer Mode Adaptation Layer Size Packet

There are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5. This paper presents the default IP MIU for use over ATM AAL5. [STANDARDS-TRACK]

 RFC2225 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1626 RFC1627 Network 10 Considered Harmful (Some Practices Shouldn't be Codified) E. Lear E. Fair D. Crocker T. Kessler July 1994 ASCII HTML 8 IP Network Number Local

This document restates the arguments for maintaining a unique address space. Concerns for Internet architecture and operations, as well as IETF procedure, are explored. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1918 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1627 RFC1628 UPS Management Information Base J. Case Editor May 1994 ASCII HTML 45 UPS-MIB Uninterruptible Power Supply MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing uninterruptible power supply (UPS) systems. [STANDARDS-TRACK]

 INFORMATIONAL PROPOSED STANDARD IETF ops upsmib http://www.rfc-editor.org/errata_search.php?rfc=1628 10.17487/RFC1628 RFC1629 Guidelines for OSI NSAP Allocation in the Internet R. Colella R. Callon E. Gardner Y. Rekhter May 1994 ASCII HTML 52 OSI-NSAP CLNP Address

This paper provides guidelines for allocating NSAP addresses in the Internet. The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and for address administration. [STANDARDS-TRACK]

 RFC1237 DRAFT STANDARD DRAFT STANDARD IETF osinsap 10.17487/RFC1629 RFC1630 Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web T. Berners-Lee June 1994 ASCII HTML 28 WWW World Wide Web URI

This document defines the syntax used by the World-Wide Web initiative to encode the names and addresses of objects on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1630 10.17487/RFC1630 RFC1631 The IP Network Address Translator (NAT) K. Egevang P. Francis May 1994 ASCII HTML 10 Internet Protocol

This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC3022 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1631 RFC1632 A Revised Catalog of Available X.500 Implementations A. Getchell Editor S. Sataluri Editor May 1994 ASCII HTML 94 Directory White Pages

This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. This document is a revision of RFC 1292. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1292 RFC2116 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1632 RFC1633 Integrated Services in the Internet Architecture: an Overview R. Braden D. Clark S. Shenker June 1994 ASCII PS PDF HTML 33 real time Multi-media reservations Protocol

This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real-time as well as the current non-real-time service of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1633 10.17487/RFC1633 RFC1634 Novell IPX Over Various WAN Media (IPXWAN) M. Allen May 1994 ASCII HTML 23 wide area network

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1551 RFC1362 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1634 RFC1635 How to Use Anonymous FTP P. Deutsch A. Emtage A. Marine May 1994 ASCII HTML 13 File Transfer Protocol

This document provides information for the novice Internet user about using the File Transfer Protocol (FTP). It explains what FTP is, what anonymous FTP is, and what an anonymous FTP archive site is. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 FYI0024 INFORMATIONAL INFORMATIONAL IETF iafa 10.17487/RFC1635 RFC1636 Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994 R. Braden D. Clark S. Crocker C. Huitema June 1994 ASCII HTML 52 Internet Architecture Board

This document is a report on an Internet architecture workshop, initiated by the IAB and held at USC Information Sciences Institute on February 8-10, 1994. This workshop generally focused on security issues in the Internet architecture. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1636 RFC1637 DNS NSAP Resource Records B. Manning R. Colella June 1994 ASCII HTML 11 domain Name System ISO OSI Address

This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. This memo defines an Experimental Protocol for the Internet community.

 RFC1348 RFC1706 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1637 RFC1638 PPP Bridging Control Protocol (BCP) F. Baker R. Bowen June 1994 ASCII HTML 28 PPP-BCP Point to Point

This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK]

 RFC1220 RFC2878 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1638 RFC1639 FTP Operation Over Big Address Records (FOOBAR) D. Piscitello June 1994 ASCII HTML 5 FOOBAR File Transfer Port

This RFC specifies a method for assigning addresses other than 32-bit IPv4 addresses to data ports through the specification of a "long Port (LPRT)" command and "Long Passive (LPSV)" reply, each having as its argument a <long-host-port>, which allows for additional address families, variable length network addresses and variable length port numbers. This memo defines an Experimental Protocol for the Internet community.

 RFC1545 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1639 RFC1640 The Process for Organization of Internet Standards Working Group (POISED) S. Crocker June 1994 ASCII HTML 10 IETF IESG IAB ISOC

This report, originally prepared in January 1993 provides a summary of the POISED WG, starting from the events leading to the formation of the WG to the end of 1992. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1640 RFC1641 Using Unicode with MIME D. Goldsmith M. Davis July 1994 ASCII PS PDF HTML 6 MIME-UNI Multipurpose Internet Mail Extension Character Set

This document specifies the usage of Unicode within MIME. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1641 RFC1642 UTF-7 - A Mail-Safe Transformation Format of Unicode D. Goldsmith M. Davis July 1994 ASCII PS PDF HTML 14 character Set

This document describes a new transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. This memo defines an Experimental Protocol for the Internet community.

 RFC2152 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1642 RFC1643 Definitions of Managed Objects for the Ethernet-like Interface Types F. Kastenholz July 1994 ASCII HTML 19 ETHER-MIB MIB Network Management SNMP Ethernet

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

 RFC1623 RFC3638 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1643 RFC1644 T/TCP -- TCP Extensions for Transactions Functional Specification R. Braden July 1994 ASCII HTML 38 T/TCP Transmission Control Protocol

This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service. This memo describes an Experimental Protocol for the Internet community.

 RFC6247 RFC1379 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1644 RFC1645 Simple Network Paging Protocol - Version 2 A. Gwinn July 1994 ASCII HTML 15 Beeper SNPP Mail

This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1568 RFC1861 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1645 RFC1646 TN3270 Extensions for LUname and Printer Selection C. Graves T. Butts M. Angel July 1994 ASCII HTML 13 Telnet Option

This document describes protocol extensions to TN3270. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app tn3270e 10.17487/RFC1646 RFC1647 TN3270 Enhancements B. Kelly July 1994 ASCII HTML 34 Telnet Option

This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. [STANDARDS-TRACK]

 RFC2355 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC1647 RFC1648 Postmaster Convention for X.400 Operations A. Cargille July 1994 ASCII HTML 4 Mail

This paper extends this concept to X.400 mail domains which have registered RFC 1327 mapping rules, and which therefore appear to have normal RFC822-style addresses. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF app x400ops 10.17487/RFC1648 RFC1649 Operational Requirements for X.400 Management Domains in the GO-MHS Community R. Hagens A. Hansen July 1994 ASCII HTML 14 Mail Global Open Message Handling System

The goal of this document is to unite regionally operated X.400 services on the various continents into one GO-MHS Community (as seen from an end-user's point of view). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app x400ops 10.17487/RFC1649 RFC1650 Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2 F. Kastenholz August 1994 ASCII HTML 20 MIB Management Information Base 802.3

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

 RFC2358 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC1650 RFC1651 SMTP Service Extensions J. Klensin N. Freed M. Rose E. Stefferud D. Crocker July 1994 ASCII HTML 11 Mail Simple Transfer

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

 RFC1425 RFC1869 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1651 RFC1652 SMTP Service Extension for 8bit-MIMEtransport J. Klensin N. Freed M. Rose E. Stefferud D. Crocker July 1994 ASCII HTML 6 SMTP Mail Simple Transfer

This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US- ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS-TRACK]

 RFC1426 RFC6152 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1652 RFC1653 SMTP Service Extension for Message Size Declaration J. Klensin N. Freed K. Moore July 1994 ASCII HTML 8 Mail Simple Transfer Protocol

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]

 RFC1427 RFC1870 DRAFT STANDARD DRAFT STANDARD IETF app smtpext 10.17487/RFC1653 RFC1654 A Border Gateway Protocol 4 (BGP-4) Y. Rekhter Editor T. Li Editor July 1994 ASCII HTML 56 routing

This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

 RFC1771 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1654 RFC1655 Application of the Border Gateway Protocol in the Internet Y. Rekhter Editor P. Gross Editor July 1994 ASCII HTML 19 BGP-4 Routing

This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

 RFC1268 RFC1772 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1655 RFC1656 BGP-4 Protocol Document Roadmap and Implementation Experience P. Traina July 1994 ASCII HTML 4 Border Gateway Protocol Routing

Border Gateway Protocol v4 (BGP-4) [1] is an inter-Autonomous System routing protocol. It is built on experience gained with BGP as defined in RFC-1267 [2] and BGP usage in the connected Internet as described in RFC-1268 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1773 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1656 RFC1657 Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 S. Willis J. Burruss J. Chu Editor July 1994 ASCII HTML 21 BGP-4-MIB MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower [1, 2]. [STANDARDS-TRACK]

 RFC4273 DRAFT STANDARD DRAFT STANDARD IETF rtg idr 10.17487/RFC1657 RFC1658 Definitions of Managed Objects for Character Stream Devices using SMIv2 B. Stewart July 1994 ASCII HTML 18 MIB Network Management Base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of character stream devices. [STANDARDS-TRACK]

 RFC1316 DRAFT STANDARD DRAFT STANDARD IETF charmib 10.17487/RFC1658 RFC1659 Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2 B. Stewart July 1994 ASCII HTML 21 MIB Network Management Base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]

 RFC1317 DRAFT STANDARD DRAFT STANDARD IETF charmib 10.17487/RFC1659 RFC1660 Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2 B. Stewart July 1994 ASCII HTML 10 MIB Network Management Base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of Parallel-printer- like devices. [STANDARDS-TRACK]

 RFC1318 DRAFT STANDARD DRAFT STANDARD IETF charmib 10.17487/RFC1660 RFC1661 The Point-to-Point Protocol (PPP) W. Simpson Editor July 1994 ASCII HTML 53 PPP Specification Standard link serial line

This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]

 RFC1548 RFC2153 STD0051 INTERNET STANDARD INTERNET STANDARD IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=1661 10.17487/RFC1661 RFC1662 PPP in HDLC-like Framing W. Simpson Editor July 1994 ASCII HTML 26 PPP-HDLC Point Protocol Specification Standard link serial line

This document describes the use of HDLC-like framing for PPP encapsulated packets. [STANDARDS-TRACK]

 RFC1549 STD0051 INTERNET STANDARD INTERNET STANDARD IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=1662 10.17487/RFC1662 RFC1663 PPP Reliable Transmission D. Rand July 1994 ASCII HTML 8 PPP-TRANS Point Protocol

This document defines a method for negotiating and using Numbered-Mode, as defined by ISO 7776 [2], to provide a reliable serial link. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1663 RFC1664 Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables C. Allocchio A. Bonito B. Cole S. Giordano R. Hagens August 1994 ASCII HTML 23 domain Name System X.400 Email

This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. This memo defines an Experimental Protocol for the Internet community.

 RFC2163 EXPERIMENTAL EXPERIMENTAL IETF app x400ops 10.17487/RFC1664 RFC1665 Definitions of Managed Objects for SNA NAUs using SMIv2 Z. Kielczewski Editor D. Kostick Editor K. Shih Editor July 1994 ASCII HTML 67 MIB Management Information Base System Network Architecture Addressable Units

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]

 RFC1666 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC1665 RFC1666 Definitions of Managed Objects for SNA NAUs using SMIv2 Z. Kielczewski Editor D. Kostick Editor K. Shih Editor August 1994 ASCII HTML 68 SNANAU-MIB Network Management SNMP MIB Protocol Units Architecture Addressable Information System

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]

 RFC1665 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1666 RFC1667 Modeling and Simulation Requirements for IPng S. Symington D. Wood M. Pullen August 1994 ASCII HTML 7 White Paper

This white paper summarizes the Distributed Interactive Simulation environment that is under development, with regard to its real-time nature, scope and magnitude of networking requirements. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1667 RFC1668 Unified Routing Requirements for IPng D. Estrin T. Li Y. Rekhter August 1994 ASCII HTML 3 White Paper

The document provides requirements on the IPng from the perspective of the Unified Routing Architecture, as described in RFC 1322. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1668 RFC1669 Market Viability as a IPng Criteria J. Curran August 1994 ASCII HTML 4 White Paper

"Viability in the Marketplace" is an important requirement for any IPng candidate and this paper is an attempt to summarize some important factors in determing market viability of IPng proposals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1669 RFC1670 Input to IPng Engineering Considerations D. Heagerty August 1994 ASCII HTML 3 White Paper

This white paper expresses some personal opinions on IPng engineering considerations, based on experience with DECnet Phase V transition. It suggests breaking down the IPng decisions and transition tasks into smaller parts so they can be tackled early by the relevant experts. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1670 RFC1671 IPng White Paper on Transition and Other Considerations B. Carpenter August 1994 ASCII HTML 8

This white paper outlines some general requirements for IPng in selected areas. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1671 RFC1672 Accounting Requirements for IPng N. Brownlee August 1994 ASCII HTML 3 White Paper

This white paper discusses accounting requirements for IPng. It recommends that all IPng packets carry accounting tags, which would vary in size. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1672 RFC1673 Electric Power Research Institute Comments on IPng R. Skelton August 1994 ASCII HTML 4 White Paper

This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1673 RFC1674 A Cellular Industry View of IPng M. Taylor August 1994 ASCII HTML 3 White Paper

This is a draft of the requirements for IPng as envisioned by representatives of the Cellular Digital Packet Data (CDPD) consortium of service providers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1674 RFC1675 Security Concerns for IPng S. Bellovin August 1994 ASCII HTML 4 White Paper

A number of the candidates for IPng have some features that are somewhat worrisome from a security perspective. While it is not necessary that IPng be an improvement over IPv4, it is mandatory that it not make things worse. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1675 RFC1676 INFN Requirements for an IPng A. Ghiselli D. Salomoni C. Vistoli August 1994 ASCII HTML 4 White Paper

With this paper we would like to emphasize the key points that we would to consider if charged with IPng plan. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1676 RFC1677 Tactical Radio Frequency Communication Requirements for IPng B. Adamson August 1994 ASCII HTML 9 White Paper

This paper describes requirements for Internet Protocol next generation (IPng) candidates with respect to their application to military tactical radio frequency (RF) communication networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1677 RFC1678 IPng Requirements of Large Corporate Networks E. Britton J. Tavs August 1994 ASCII HTML 8 White Paper

This draft summarizes some of the requirements of large corporate networks for the next generation of the Internet protcol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1678 RFC1679 HPN Working Group Input to the IPng Requirements Solicitation D. Green P. Irey D. Marlow K. O'Donoghue August 1994 ASCII HTML 10 White Paper

The purpose of this document is to provide what the HPN working group perceives as requirements for an IPng protocol set. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1679 RFC1680 IPng Support for ATM Services C. Brazdziunas August 1994 ASCII HTML 7 White Paper

This white paper describes engineering considerations for IPng as solicited by RFC 1550 [1]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1680 RFC1681 On Many Addresses per Host S. Bellovin August 1994 ASCII HTML 5 White Paper

This document was submitted to the IETF IPng area in response to RFC 1550.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1681 RFC1682 IPng BSD Host Implementation Analysis J. Bound August 1994 ASCII HTML 10 White Paper Unix

This IPng white paper, IPng BSD Host Implementation Analysis, was submitted to the IPng Directorate to provide a BSD host point of reference to assist with the engineering considerations during the IETF process to select an IPng proposal. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1682 RFC1683 Multiprotocol Interoperability In IPng R. Clark M. Ammar K. Calvert August 1994 ASCII HTML 12 White Paper

In this document, we identify several features that affect a protocol's ability to operate in a multiprotocol environment and propose the incorporation of these features into IPng. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1683 RFC1684 Introduction to White Pages Services based on X.500 P. Jurg August 1994 ASCII HTML 10 Directory

The document provides an introduction to the international ITU-T (formerly CCITT) X.500 and ISO 9594 standard, which is particularly suited for providing an integrated local and global electronic White Pages Service. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1684 RFC1685 Writing X.400 O/R Names H. Alvestrand August 1994 ASCII HTML 11 EMail Mail

There is a need for human beings who use X.400 systems to be able to write down O/R names in a uniform way. This memo is a discussion of this topic. This memo provides information for the Internet Community. It does not specify an Internet Standard of any kind.

 RTR0012 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1685 10.17487/RFC1685 RFC1686 IPng Requirements: A Cable Television Industry Viewpoint M. Vecchi August 1994 ASCII HTML 14 White Paper

This paper provides comments on topics related to the IPng requirements and selection criteria from a cable television industry viewpoint. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1686 RFC1687 A Large Corporate User's View of IPng E. Fleischman August 1994 ASCII HTML 13 White Paper

The goal of this paper is to examine the implications of IPng from the point of view of Fortune 100 corporations which have heavily invested in TCP/IP technology in order to achieve their (non-computer related) business goals.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1687 RFC1688 IPng Mobility Considerations W. Simpson August 1994 ASCII HTML 9 White Paper

This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1688 RFC1689 A Status Report on Networked Information Retrieval: Tools and Groups J. Foster Editor August 1994 ASCII HTML 226 NIR

The purpose of this report is to increase the awareness of Networked Information Retrieval by bringing together in one place information about the various networked information retrieval tools, their developers, interested organisations, and other activities that relate to the production, dissemination, and support of NIR tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 FYI0025 INFORMATIONAL INFORMATIONAL IETF nir 10.17487/RFC1689 RFC1690 Introducing the Internet Engineering and Planning Group (IEPG) G. Huston August 1994 ASCII HTML 2 charter

This memo introduces the IEPG to the Internet Community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1690 RFC1691 The Document Architecture for the Cornell Digital Library W. Turner August 1994 ASCII HTML 10

This memo defines an architecture for the storage and retrieval of the digital representations for books, journals, photographic images, etc., which are collected in a large organized digital library. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1691 RFC1692 Transport Multiplexing Protocol (TMux) P. Cameron D. Crocker D. Cohen J. Postel August 1994 ASCII HTML 12 TMUX Internet Protocol IP

One of the problems with the use of terminal servers is the large number of small packets they can generate. Frequently, most of these packets are destined for only one or two hosts. TMux is a protocol which allows multiple short transport segments, independent of application type, to be combined between a server and host pair.

 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1692 RFC1693 An Extension to TCP : Partial Order Service T. Connolly P. Amer P. Conrad November 1994 ASCII HTML 36 TCP-POS Transmission Control Protocol

This RFC introduces a new transport mechanism for TCP based upon partial ordering. The aim is to present the concepts of partial ordering and promote discussions on its usefulness in network communications. This memo defines an Experimental Protocol for the Internet community.

 RFC6247 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1693 RFC1694 Definitions of Managed Objects for SMDS Interfaces using SMIv2 T. Brown Editor K. Tesink Editor August 1994 ASCII HTML 35 SIP-MIB Standard MIB Network Management Switched Multimegabit Data Service Information Base SMDS

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing objects for SMDS access interfaces. [STANDARDS-TRACK]

 RFC1304 DRAFT STANDARD DRAFT STANDARD IETF int ifmib 10.17487/RFC1694 RFC1695 Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2 M. Ahmed Editor K. Tesink Editor August 1994 ASCII HTML 73 ATM-MIB MIB Management,Information,Base,Asychronous,Transmission,Mode

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]

 RFC2515 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC1695 RFC1696 Modem Management Information Base (MIB) using SMIv2 J. Barnes L. Brown R. Royston S. Waldbusser August 1994 ASCII HTML 31 MODEM-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing dial-up modems and similar dial-up devices. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF modemmgt 10.17487/RFC1696 RFC1697 Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2 D. Brower Editor B. Purvy A. Daniel M. Sinykin J. Smith August 1994 ASCII HTML 38 RDBMS-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing relational database (RDBMS) implementations. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rdbmsmib 10.17487/RFC1697 RFC1698 Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications P. Furniss October 1994 ASCII HTML 29 Protocol Headers

This document states particular octet sequences that comprise the OSI upper-layer protocols (Session, Presentation and ACSE) when used to support applications with "basic communications requirements". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF thinosi 10.17487/RFC1698 RFC1699 Summary of 1600-1699 J. Elliott January 1997 ASCII HTML 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1699 RFC1700 Assigned Numbers J. Reynolds J. Postel October 1994 ASCII HTML 230 status procedure index parameters registered allocated

This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite. To make the current information readily available the assignments are kept up-to- date in a set of online text files. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.

 RFC1340 RFC3232 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1700 RFC1701 Generic Routing Encapsulation (GRE) S. Hanks T. Li D. Farinacci P. Traina October 1994 ASCII HTML 8 GRE Internet Protocol IP

This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1701 RFC1702 Generic Routing Encapsulation over IPv4 networks S. Hanks T. Li D. Farinacci P. Traina October 1994 ASCII HTML 4 GRE-IPv4 Internet Protocol IP

This memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload. This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1702 RFC1703 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures M. Rose October 1994 ASCII HTML 9 RADIO-PAGE Beepers

This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1569 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1703 RFC1704 On Internet Authentication N. Haller R. Atkinson October 1994 ASCII HTML 17 Security Energyption Policy Guidelines

This document describes a spectrum of authentication technologies and provides suggestions to protocol developers on what kinds of authentication might be suitable for some kinds of protocols and applications used in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1704 RFC1705 Six Virtual Inches to the Left: The Problem with IPng R. Carlson D. Ficarella October 1994 ASCII HTML 27 IPng White paper

This document was submitted to the IETF IPng area in response to RFC 1550. This RFC suggests that a new version of TCP (TCPng), and UDP, be developed and deployed. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1705 RFC1706 DNS NSAP Resource Records B. Manning R. Colella October 1994 ASCII HTML 10 DNS-NSAP Domain Name System ISO OSI Address RR Record Resource

This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with any NSAP address format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1637 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1706 RFC1707 CATNIP: Common Architecture for the Internet M. McGovern R. Ullmann October 1994 ASCII HTML 16 IPng White Paper IPv7

This document was submitted to the IETF IPng area in response to RFC 1550. This paper describes a common architecture for the network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1707 RFC1708 NTP PICS PROFORMA - For the Network Time Protocol Version 3 D. Gowin October 1994 ASCII HTML 13

This RFC describes a PICS Proforma translated into an Internet acceptable form. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1708 RFC1709 K-12 Internetworking Guidelines J. Gargano D. Wasley November 1994 ASCII PS PDF HTML 26 school network education connection

The K-12 community traditionally has not had this level of staffing available for telecommunications planning. This document is intended to bridge that gap and provides a recommended technical direction, an introduction to the role the Internet now plays in K-12 education and technical guidelines for building a campus data communications infrastructure that provides internetworking services and connections to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 FYI0026 INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1709 RFC1710 Simple Internet Protocol Plus White Paper R. Hinden October 1994 ASCII HTML 23 SIPP IPng

This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF sipp 10.17487/RFC1710 RFC1711 Classifications in E-mail Routing J. Houttuin October 1994 ASCII HTML 19 Email Electronic Mail

This paper presents a classification for e-mail routing issues. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1711 RFC1712 DNS Encoding of Geographical Location C. Farrell M. Schulze S. Pleitner D. Baldoni November 1994 ASCII HTML 7 DNS-ENCODE Domain Names System GPOS

This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1712 10.17487/RFC1712 RFC1713 Tools for DNS debugging A. Romao November 1994 ASCII HTML 13 Domain Names System Host DNSWalk DOC DDT Checker

Although widely used (and most of the times unnoticed), DNS (Domain Name System) is too much overlooked, in the sense that people, especially administrators, tend to ignore possible anomalies as long as applications that need name-to-address mapping continue to work. This document presents some tools available for domain administrators to detect and correct those anomalies. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 FYI0027 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1713 RFC1714 Referral Whois Protocol (RWhois) S. Williamson M. Kosters November 1994 ASCII PS PDF HTML 46 White Pages Directory

This memo describes version 1.0 of the client/server interaction of RWhois. RWhois provides a distributed system for the display of hierarchical information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2167 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1714 RFC1715 The H Ratio for Address Assignment Efficiency C. Huitema November 1994 ASCII HTML 4 IPng White Paper

This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC3194 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1715 RFC1716 Towards Requirements for IP Routers P. Almquist F. Kastenholz November 1994 ASCII HTML 192 Gateway Internet Protocol

The goal of this work is to replace RFC-1009, Requirements for Internet Gateways ([INTRO:1]) with a new document. It defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1812 INFORMATIONAL INFORMATIONAL IETF rtg rreq 10.17487/RFC1716 RFC1717 The PPP Multilink Protocol (MP) K. Sklower B. Lloyd G. McGregor D. Carr November 1994 ASCII HTML 21 Point

This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]

 RFC1990 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1717 RFC1718 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force IETF Secretariat G. Malkin November 1994 ASCII HTML 23 Internet Engineering Task Force Meeting

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 17]

 RFC1539 RFC3160 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1718 RFC1719 A Direction for IPng P. Gross December 1994 ASCII HTML 6 IPng White Paper Internet Protocol

This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1719 RFC1720 Internet Official Protocol Standards J. Postel November 1994 ASCII HTML 41 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

 RFC1610 RFC1780 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1720 RFC1721 RIP Version 2 Protocol Analysis G. Malkin November 1994 ASCII HTML 4 RIP-2

As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This report is a prerequisite to advancing RIP-2 on the standards track. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1387 INFORMATIONAL INFORMATIONAL IETF rtg ripv2 10.17487/RFC1721 RFC1722 RIP Version 2 Protocol Applicability Statement G. Malkin November 1994 ASCII HTML 5 RIP2-APP RIP-2

As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIP-2 protocol within the Internet. This report is a prerequisite to advancing RIP-2 on the standards track. [STANDARDS-TRACK]

 STD0057 INTERNET STANDARD DRAFT STANDARD IETF rtg ripv2 10.17487/RFC1722 RFC1723 RIP Version 2 - Carrying Additional Information G. Malkin November 1994 ASCII HTML 9 RIP-2

This document specifies an extension of the Routing Information Protocol (RIP), o expand the amount of useful information carried in RIP messages and to add a measure of security. This memo obsoletes RFC 1388, which specifies an update to the "Routing Information Protocol" STD 34, RFC 1058. [STANDARDS-TRACK]

 RFC1388 RFC2453 RFC1058 INTERNET STANDARD DRAFT STANDARD IETF rtg ripv2 10.17487/RFC1723 RFC1724 RIP Version 2 MIB Extension G. Malkin F. Baker November 1994 ASCII HTML 18 RIP2-MIB RIP-2 Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing RIP Version 2. [STANDARDS-TRACK]

 RFC1389 DRAFT STANDARD DRAFT STANDARD IETF rtg ripv2 http://www.rfc-editor.org/errata_search.php?rfc=1724 10.17487/RFC1724 RFC1725 Post Office Protocol - Version 3 J. Myers M. Rose November 1994 ASCII HTML 18 POP Email Electronic Mail

This memo is a revision to RFC 1460, a Draft Standard. [STANDARDS-TRACK]

 RFC1460 RFC1939 INTERNET STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1725 10.17487/RFC1725 RFC1726 Technical Criteria for Choosing IP The Next Generation (IPng) C. Partridge F. Kastenholz December 1994 ASCII HTML 31 IPng White Paper Internet Protocol

This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1726 RFC1727 A Vision of an Integrated Internet Information Service C. Weider P. Deutsch December 1994 ASCII HTML 11 Universal Resource Names

This paper lays out a vision of how Internet information services might be integrated over the next few years, and discusses in some detail what steps will be needed to achieve this integration. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1727 RFC1728 Resource Transponders C. Weider December 1994 ASCII HTML 6 Universal Resource Names Location System

This paper describes an automatic mechanism, the resource transponder, for maintaining resource location information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1728 RFC1729 Using the Z39.50 Information Retrieval Protocol C. Lynch December 1994 ASCII HTML 8 Basic Endcoding Rules ASN1

This memo describes an approach to the implementation of the ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the TCP/IP environment which is currently in wide use by the Z39.50 implementor community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1729 RFC1730 Internet Message Access Protocol - Version 4 M. Crispin December 1994 ASCII HTML 77 IMAP IMAP4 EMail

The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server. IMAP4 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server. [STANDARDS-TRACK]

 RFC2060 RFC2061 PROPOSED STANDARD PROPOSED STANDARD IETF app imap 10.17487/RFC1730 RFC1731 IMAP4 Authentication Mechanisms J. Myers December 1994 ASCII HTML 6 IMAP4-AUTH Internet Message Access Protocol Email

The Internet Message Access Protocol, Version 4 [IMAP4] contains the AUTHENTICATE command, for identifying and authenticating a user to an IMAP4 server and for optionally negotiating a protection mechanism for subsequent protocol interactions. This document describes several authentication mechanisms for use by the IMAP4 AUTHENTICATE command. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app imap 10.17487/RFC1731 RFC1732 IMAP4 Compatibility with IMAP2 and IMAP2bis M. Crispin December 1994 ASCII HTML 5 Internet Message Access Protocol Email

This is a summary of hints and recommendations to enable an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app imap 10.17487/RFC1732 RFC1733 Distributed Electronic Mail Models in IMAP4 M. Crispin December 1994 ASCII HTML 3 Internet Message Access Protocol Email

There are three fundamental models of client/server email: offline, online, and disconnected use. IMAP4 can be used in any one of these three models. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app imap 10.17487/RFC1733 RFC1734 POP3 AUTHentication command J. Myers December 1994 ASCII HTML 5 POP3-AUTH Post Office Protocol Email

This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. [STANDARDS-TRACK]

 RFC5034 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1734 RFC1735 NBMA Address Resolution Protocol (NARP) J. Heinanen R. Govindan December 1994 ASCII HTML 11 NARP Non-Broadcast Multi Access Address Resolution Protocol

This document describes the NBMA Address Resolution Protocol (NARP). NARP can be used by a source terminal (host or router) connected to a Non-Broadcast, Multi-Access link layer (NBMA) network to find out the NBMA addresses of the a destination terminal provided that the destination terminal is connected to the same NBMA network. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL IETF rtg rolc 10.17487/RFC1735 RFC1736 Functional Recommendations for Internet Resource Locators J. Kunze February 1995 ASCII HTML 10 Uniform Resource URL

This document specifies a minimum set of requirements for Internet resource locators, which convey location and access information for resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1736 RFC1737 Functional Requirements for Uniform Resource Names K. Sollins L. Masinter December 1994 ASCII HTML 7

This document specifies a minimum set of requirements for a kind of Internet resource identifier known as Uniform Resource Names (URNs). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1737 RFC1738 Uniform Resource Locators (URL) T. Berners-Lee L. Masinter M. McCahill December 1994 ASCII HTML 25 URL

This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet. [STANDARDS-TRACK]

 RFC4248 RFC4266 RFC1808 RFC2368 RFC2396 RFC3986 RFC6196 RFC6270 RFC8089 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1738 10.17487/RFC1738 RFC1739 A Primer On Internet and TCP/IP Tools G. Kessler S. Shepard December 1994 ASCII HTML 46 NSlookup PING FINGER TRACEROUTE FTP TELNET WHOIS NICNAME KNOWBOT NETFIND ARCHIE Gopher Email Mailing Lists USENET

This memo is an introductory guide to some of the TCP/IP and Internet tools and utilities that allow users to access the wide variety of information on the network, from determining if a particular host is up to viewing a multimedia thesis on foreign policy. It also describes discussion lists accessible from the Internet, ways to obtain Internet documents, and resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2151 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1739 RFC1740 MIME Encapsulation of Macintosh Files - MacMIME P. Faltstrom D. Crocker E. Fair December 1994 ASCII HTML 16 MacMIME Multipurpose Internet Mail Extensions

This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1740 RFC1741 MIME Content Type for BinHex Encoded Files P. Faltstrom D. Crocker E. Fair December 1994 ASCII HTML 6 BINHEX Multipurpose Internet Mail Extensions

This memo describes the format to use when sending BinHex4.0 files via MIME [BORE93]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1741 RFC1742 AppleTalk Management Information Base II S. Waldbusser K. Frisa January 1995 ASCII HTML 84 AT-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing AppleTalk networks. [STANDARDS-TRACK]

 RFC1243 HISTORIC PROPOSED STANDARD IETF int appleip 10.17487/RFC1742 RFC1743 IEEE 802.5 MIB using SMIv2 K. McCloghrie E. Decker December 1994 ASCII HTML 25 Management Information Base SNMP,

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]

 RFC1231 RFC1748 DRAFT STANDARD DRAFT STANDARD IETF int ifmib 10.17487/RFC1743 RFC1744 Observations on the Management of the Internet Address Space G. Huston December 1994 ASCII HTML 12 IP Internet Protocol

This memo examines some of the issues associated with the current management practices of the Internet IPv4 address space, and examines the potential outcomes of these practices as the unallocated address pool shrinks in size. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1744 RFC1745 BGP4/IDRP for IP---OSPF Interaction K. Varadhan S. Hares Y. Rekhter December 1994 ASCII HTML 19 BGP4/IDRP Internet Inter-Domain Routing Protocol Border Gateway Open Shortest Path First

This memo defines the various criteria to be used when designing an Autonomous System Border Router (ASBR) that will run either BGP4 or IDRP for IP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF rtg idr 10.17487/RFC1745 RFC1746 Ways to Define User Expectations B. Manning D. Perkins December 1994 ASCII HTML 18

This paper covers basic fundamentals that must be understood when one defines, interprets, or implements methods to control user expectations on or over the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1746 RFC1747 Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2 J. Hilgeman S. Nix A. Bartky W. Clark Editor January 1995 ASCII HTML 67 SDLCSMIv2

This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for managing the configuration, monitoring and control of data link controls in an SNA environment. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF rtg snadlc 10.17487/RFC1747 RFC1748 IEEE 802.5 MIB using SMIv2 K. McCloghrie E. Decker December 1994 ASCII HTML 25 802.5-MIB Management Information Base SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]

 RFC1743 RFC1231 RFC1749 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1748 RFC1749 IEEE 802.5 Station Source Routing MIB using SMIv2 K. McCloghrie F. Baker E. Decker December 1994 ASCII HTML 10 802.5-SSR Management Information Base SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used by IEEE 802.5 end-stations for managing source routes on a Token Ring network where IEEE source- routing is in use. [STANDARDS-TRACK]

 RFC1748 HISTORIC PROPOSED STANDARD IETF int ifmib 10.17487/RFC1749 RFC1750 Randomness Recommendations for Security D. Eastlake 3rd S. Crocker J. Schiller December 1994 ASCII HTML 30 Random Numbers Seed

Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC4086 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1750 RFC1751 A Convention for Human-Readable 128-bit Keys D. McDonald December 1994 ASCII HTML 15 Security Password

This memo proposes a convention for use with Internet applications & protocols using 128-bit cryptographic keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1751 10.17487/RFC1751 RFC1752 The Recommendation for the IP Next Generation Protocol S. Bradner A. Mankin January 1995 ASCII HTML 52 IPNG IPng Internet

This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the Internet Protocol. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1752 RFC1753 IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture N. Chiappa December 1994 ASCII HTML 18 IPng White Paper Internet Protocol

This document presents the requirements that the Nimrod routing and addressing architecture has upon the internetwork layer protocol. To be most useful to Nimrod, any protocol selected as the IPng should satisfy these requirements. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1753 RFC1754 IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1 M. Laubach January 1995 ASCII HTML 7 Internet Asynchromous Transfer Mode

This document represents an initial list of requirements submitted to the ATM Forum's Multiprotocol BOF for the operation of IP over ATM networks as determined by the IETF IP over ATM Working Group and other working groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1754 RFC1755 ATM Signaling Support for IP over ATM M. Perez F. Liaw A. Mankin E. Hoffman D. Grossman A. Malis February 1995 ASCII HTML 32 ATM Asynchronous Transfer Mode

This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC 1577. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1755 RFC1756 Remote Write Protocol - Version 1.0 T. Rinne January 1995 ASCII HTML 11 RWP Application

This document describes a simple Remote Write Protocol (RWP). This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1756 RFC1757 Remote Network Monitoring Management Information Base S. Waldbusser February 1995 ASCII HTML 91 RMON-MIB MIB RMON

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

 RFC1271 RFC2819 DRAFT STANDARD DRAFT STANDARD IETF ops rmonmib 10.17487/RFC1757 RFC1758 NADF Standing Documents: A Brief Overview The North American Directory Forum February 1995 ASCII HTML 4 X.500 North American Directory Forum Public CCITT Providers

The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1758 RFC1759 Printer MIB R. Smith F. Wright T. Hastings S. Zilles J. Gyllenskog March 1995 ASCII HTML 113 Print-MIB Management Information Base

A printer is the physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied. The information needed in the management of the physical printer and the management of a printing job overlap highly and many of the tasks in each management area require the same or similar information. [STANDARDS-TRACK]

 RFC3805 PROPOSED STANDARD PROPOSED STANDARD IETF app printmib 10.17487/RFC1759 RFC1760 The S/KEY One-Time Password System N. Haller February 1995 ASCII HTML 12 Security

This document describes the S/KEY* One-Time Password system as released for public use by Bellcore. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1760 10.17487/RFC1760 RFC1761 Snoop Version 2 Packet Capture File Format B. Callaghan R. Gilligan February 1995 ASCII HTML 6 SNOOP Measurement debugging collecting data

This paper describes the file format used by "snoop", a packet monitoring and capture program developed by Sun. This paper is provided so that people can write compatible programs to generate and interpret snoop packet capture files. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1761 RFC1762 The PPP DECnet Phase IV Control Protocol (DNCP) S. Senum March 1995 ASCII HTML 7 PPP-DNCP Point Digital Equipment Corporation

This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc). [STANDARDS-TRACK]

 RFC1376 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1762 RFC1763 The PPP Banyan Vines Control Protocol (BVCP) S. Senum March 1995 ASCII HTML 10 BVCP Point

This document defines the Network Control Protocol for establishing and configuring the Banyan VINES protocol over PPP. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1763 RFC1764 The PPP XNS IDP Control Protocol (XNSCP) S. Senum March 1995 ASCII HTML 5 XNSCP Point Xerox Network Internetwork Datagram Service

This document defines the Network Control Protocol for establishing and configuring the Xerox Network Systems (XNS) Internet Datagram Protocol (IDP) over PPP. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1764 RFC1765 OSPF Database Overflow J. Moy March 1995 ASCII HTML 9 OSPF-OVFL

This memo details a way of gracefully handling unanticipated database overflows. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC1765 RFC1766 Tags for the Identification of Languages H. Alvestrand March 1995 ASCII HTML 9 Lang-Tag

This document describes a language tag for use in cases where it is desired to indicate the language used in an information object. [STANDARDS-TRACK]

 RFC3066 RFC3282 PROPOSED STANDARD PROPOSED STANDARD IETF app mailext 10.17487/RFC1766 RFC1767 MIME Encapsulation of EDI Objects D. Crocker March 1995 ASCII HTML 7 MIME-EDI Electronic Data Interchange Multipurpose Internet Mail Extensions delivery mechanism encapsulation

Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app edi 10.17487/RFC1767 RFC1768 Host Group Extensions for CLNP Multicasting D. Marlow March 1995 ASCII HTML 45 CLNP-MULT ISO OSI

This memo provides a specification for multicast extensions to the CLNP protocol similar to those provided to IP by RFC1112. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL IETF int tuba 10.17487/RFC1768 RFC1769 Simple Network Time Protocol (SNTP) D. Mills March 1995 ASCII HTML 14 Clocks Synchronization NTP

This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1361 RFC2030 RFC4330 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1769 RFC1770 IPv4 Option for Sender Directed Multi-Destination Delivery C. Graff March 1995 ASCII HTML 6 SDMD

This memo defines an IPv4 option to provide a sender directed multi- destination delivery mechanism called Selective Directed Broadcast Mode (SDBM). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC6814 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1770 RFC1771 A Border Gateway Protocol 4 (BGP-4) Y. Rekhter T. Li March 1995 ASCII HTML 57 BGP-4 routing

This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

 RFC1654 RFC4271 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1771 10.17487/RFC1771 RFC1772 Application of the Border Gateway Protocol in the Internet Y. Rekhter P. Gross March 1995 ASCII HTML 19 BGP-4-APP BGP-4 Routing

This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK]

 RFC1655 DRAFT STANDARD DRAFT STANDARD IETF rtg bgp 10.17487/RFC1772 RFC1773 Experience with the BGP-4 protocol P. Traina March 1995 ASCII HTML 9 BGP-4 Border Gateway Protocol Routing

The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report documents experience with BGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1656 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1773 RFC1774 BGP-4 Protocol Analysis P. Traina Editor March 1995 ASCII HTML 10 Border Gateway Routing

The purpose of this report is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by the Border Gateway Protocol version 4 (BGP-4). This report summarizes the key features of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=1774 10.17487/RFC1774 RFC1775 To Be "On" the Internet D. Crocker March 1995 ASCII HTML 4 access full Client Mediated Messaging

The Internet permits different levels of access for consumers and providers of service. The nature of those differences is quite important in the capabilities They afford. Hence, it is appropriate to provide terminology that distinguishes among the range, so that the Internet community can gain some clarity when distinguishing whether a user (or an organization) is "on" the Internet. This document suggests four terms, for distinguishing the major classes of access. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1775 RFC1776 The Address is the Message S. Crocker April 1 1995 ASCII HTML 2 IPng

Declaring that the address is the message, the IPng WG has selected a packet format which includes 1696 bytes of address space. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1776 RFC1777 Lightweight Directory Access Protocol W. Yeong T. Howes S. Kille March 1995 ASCII HTML 22 X.500 DAP interactive access

The protocol described in this document is designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP).This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500 Directory, and is intended to be a complement to the DAP itself. [STANDARDS-TRACK]

 RFC1487 RFC3494 HISTORIC DRAFT STANDARD IETF app asid 10.17487/RFC1777 RFC1778 The String Representation of Standard Attribute Syntaxes T. Howes S. Kille W. Yeong C. Robbins March 1995 ASCII HTML 12 X.500 LDAP lightweight directory protocol

The Lightweight Directory Access Protocol (LDAP) requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes. [STANDARDS-TRACK]

 RFC1488 RFC3494 RFC2559 HISTORIC DRAFT STANDARD IETF app asid 10.17487/RFC1778 RFC1779 A String Representation of Distinguished Names S. Kille March 1995 ASCII HTML 8 STR-REP X.500 directory names representing names

The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1. When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name. [STANDARDS-TRACK]

 RFC1485 RFC2253 RFC3494 HISTORIC DRAFT STANDARD IETF app asid 10.17487/RFC1779 RFC1780 Internet Official Protocol Standards J. Postel Editor March 1995 ASCII HTML 39 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

 RFC1720 RFC1800 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1780 RFC1781 Using the OSI Directory to Achieve User Friendly Naming S. Kille March 1995 ASCII HTML 26 OSI-Dir X.500 directory names representing names

This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. [STANDARDS-TRACK]

 RFC1484 RFC3494 HISTORIC PROPOSED STANDARD IETF app asid 10.17487/RFC1781 RFC1782 TFTP Option Extension G. Malkin A. Harkin March 1995 ASCII HTML 6 trivial file transfer booting

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer.

 RFC2347 RFC1350 PROPOSED STANDARD PROPOSED STANDARD IETF app tftpexts 10.17487/RFC1782 RFC1783 TFTP Blocksize Option G. Malkin A. Harkin March 1995 ASCII HTML 5 trivial file transfer booting

This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK]

 RFC2348 RFC1350 PROPOSED STANDARD PROPOSED STANDARD IETF app tftpexts 10.17487/RFC1783 RFC1784 TFTP Timeout Interval and Transfer Size Options G. Malkin A. Harkin March 1995 ASCII HTML 4 trivial file transfer booting

This document describes two TFTP options. The first allows the client and server to negotiate the Timeout Interval. The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. [STANDARDS-TRACK]

 RFC2349 RFC1350 PROPOSED STANDARD PROPOSED STANDARD IETF app tftpexts 10.17487/RFC1784 RFC1785 TFTP Option Negotiation Analysis G. Malkin A. Harkin March 1995 ASCII HTML 2 trivial file transfer booting

This document was written to allay concerns that the presence of options in a TFTP Request packet might cause pathological behavior on servers which do not support TFTP option negotiation. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1350 INFORMATIONAL INFORMATIONAL IETF app tftpexts 10.17487/RFC1785 RFC1786 Representation of IP Routing Policies in a Routing Registry (ripe-81++) T. Bates E. Gerich L. Joncheray J-M. Jouanigot D. Karrenberg M. Terpstra J. Yu March 1995 ASCII HTML 83

This document is an update to the original `ripe-81' proposal for representing and storing routing polices within the RIPE database. It incorporates several extensions proposed by Merit Inc. and gives details of a generalized IP routing policy representation to be used by all Internet routing registries. It acts as both tutorial and provides details of database objects and attributes that use and make up a routing registry. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1786 RFC1787 Routing in a Multi-provider Internet Y. Rekhter April 1995 ASCII HTML 8 Internet Protocol Architechure Board IAB

This document presents some of the issues related to network layer routing in a multi-provider Internet, and specifically to the unicast routing. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1787 RFC1788 ICMP Domain Name Messages W. Simpson April 1995 ASCII HTML 7 ICMP-DM Internet Control Message Protocol DNS Service

This document specifies ICMP messages for learning the Fully Qualified Domain Name associated with an IP address. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

 RFC6918 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1788 RFC1789 INETPhone: Telephone Services and Servers on Internet C. Yang April 1995 ASCII HTML 6

This RFC presents a true telephone service, called INETPhone, which supports voice communication through the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1789 RFC1790 An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols V. Cerf April 1995 ASCII HTML 4 ISOC

This RFC is an official public record of an agreement between SUN Microsystems and the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1790 RFC1791 TCP And UDP Over IPX Networks With Fixed Path MTU T. Sung April 1995 ASCII HTML 12 Transmission Control Protocol User Datagram Maximum Transmission Unit

TCP/IPX allows TCP/IP applications to run over IPX networks by letting TCP and UDP run over IPX. And this memo specifies the packet format and operational procedures for running TCP and UDP over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1791 RFC1792 TCP/IPX Connection Mib Specification T. Sung April 1995 ASCII HTML 9 TCP/IPXMIB Transmission Control Protocol Management Information Base

New MIB objects, tcpIpxConnTable, udpIpxTable, tcpUnspecConnTable and udpUnspecTable are presented in this paper, to be used in place of tcpConnTable and udpListenerTable when TCP and UDP are running over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1792 RFC1793 Extending OSPF to Support Demand Circuits J. Moy April 1995 ASCII HTML 32 OSPF-DC Open Shortest Path First

This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". [STANDARDS-TRACK]

 RFC3883 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC1793 RFC1794 DNS Support for Load Balancing T. Brisco April 1995 ASCII HTML 7 Domain Name System

This RFC is meant to first chronicle a foray into the IETF DNS Working Group, discuss other possible alternatives to provide/simulate load balancing support for DNS, and to provide an ultimate, flexible solution for providing DNS support for balancing loads of many types. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int dns 10.17487/RFC1794 RFC1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1 L. Wells A. Bartky Editor April 1995 ASCII HTML 91 IBM SNA DLS SSP NetBIos APPN

This RFC describes use of Data Link Switching over TCP/IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1434 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1795 RFC1796 Not All RFCs are Standards C. Huitema J. Postel S. Crocker April 1995 ASCII HTML 4

This document discusses the relationship of the Request for Comments (RFCs) notes to Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1796 RFC1797 Class A Subnet Experiment Internet Assigned Numbers Authority (IANA) April 1995 ASCII HTML 4 Network Address 39 Number

There appears to be some interest in experimenting with subnetting the class A addresses. It is suggested that conducting an experiment now to identify and fix any software that does not properly handle subnetted class A addresses would be useful and important. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1797 RFC1798 Connection-less Lightweight X.500 Directory Access Protocol A. Young June 1995 ASCII HTML 9 CLDAP CLDAP Presentation Address Application Entity Title

The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]

 RFC3352 HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1798 RFC1799 Request for Comments Summary RFC Numbers 1700-1799 M. Kennedy January 1997 ASCII HTML 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1799 RFC1800 Internet Official Protocol Standards J. Postel Editor July 1995 ASCII HTML 36 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

 RFC1780 RFC1880 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1800 RFC1801 MHS use of the X.500 Directory to support MHS Routing S. Kille June 1995 ASCII HTML 73 Routing Mail EMail Message Handling System X.400

The key problem in routing is to map from an O/R Address onto an MTA (next hop). This shall be an MTA which in some sense is "nearer" to the destination UA. This is done repeatedly until the message can be directly delivered to the recipient UA. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1801 RFC1802 Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing H. Alvestrand K. Jordan S. Langlois J. Romaguera June 1995 ASCII HTML 11 Mail EMail Message Handling System MHS

This memo describes a proposed Internet Pilot Project that seeks to prove the MHS-DS approach on a larger scale. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app mhsds 10.17487/RFC1802 RFC1803 Recommendations for an X.500 Production Directory Service R. Wright A. Getchell T. Howes S. Sataluri P. Yee W. Yeong June 1995 ASCII HTML 8 White Pages DSA Directory User Agent

This document contains a set of basic recommendations for a country- level X.500 DSA. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1803 RFC1804 Schema Publishing in X.500 Directory G. Mansfield P. Rajeev S. Raghavan T. Howes June 1995 ASCII HTML 10

In this document we propose a solution using the existing mechanisms of the directory [1] itself. We present a naming scheme for naming schema objects and a meta-schema for storing schema objects in the directory. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app asid 10.17487/RFC1804 RFC1805 Location-Independent Data/Software Integrity Protocol A. Rubin June 1995 ASCII HTML 6 Betsi Security Cryptography

This memo describes a protocol for adding integrity assurance to files that are distributed across the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1805 RFC1806 Communicating Presentation Information in Internet Messages: The Content-Disposition Header R. Troost S. Dorner June 1995 ASCII HTML 8 MIME EMail Mail

This memo provides a mechanism whereby messages conforming to the [RFC 1521] ("MIME") specification can convey presentational information. This memo defines an Experimental Protocol for the Internet community.

 RFC2183 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1806 RFC1807 A Format for Bibliographic Records R. Lasher D. Cohen June 1995 ASCII HTML 15 library technical reports email services

This RFC defines a format for bibliographic records describing technical reports. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1357 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1807 RFC1808 Relative Uniform Resource Locators R. Fielding June 1995 ASCII HTML 16 URL URL syntax semantics

In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance. This document defines the syntax and semantics for such Relative Uniform Resource Locators. [STANDARDS-TRACK]

 RFC3986 RFC1738 RFC2368 RFC2396 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1808 RFC1809 Using the Flow Label Field in IPv6 C. Partridge June 1995 ASCII HTML 6

The purpose of this memo is to distill various opinions and suggestions of the End-to-End Research Group regarding the handling of Flow Labels into a set of suggestions for IPv6. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1809 RFC1810 Report on MD5 Performance J. Touch June 1995 ASCII HTML 7 IPv6 Message Digest Algorithm Authentication

This RFC addresses how fast MD5 can be implemented in software and hardware, and whether it supports currently available IP bandwidth. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1810 10.17487/RFC1810 RFC1811 U.S. Government Internet Domain Names Federal Networking Council June 1995 ASCII HTML 3 GOV FNC IANA

This document describes the registration policies for the top-level domain ".GOV". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1816 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1811 RFC1812 Requirements for IP Version 4 Routers F. Baker Editor June 1995 ASCII HTML 175 routing IPv4

This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK]

 RFC1716 RFC1009 RFC2644 RFC6633 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rreq http://www.rfc-editor.org/errata_search.php?rfc=1812 10.17487/RFC1812 RFC1813 NFS Version 3 Protocol Specification B. Callaghan B. Pawlowski P. Staubach June 1995 ASCII HTML 126 NFSV3

This paper describes the NFS version 3 protocol. This paper is provided so that people can write compatible implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1094 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1813 RFC1814 Unique Addresses are Good E. Gerich June 1995 ASCII HTML 3 Internet Registries Protocol Private Network Numbers

The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1814 RFC1815 Character Sets ISO-10646 and ISO-10646-J-1 M. Ohta July 1995 ASCII HTML 6 Japanese Latin

For the practical use of ISO 10646, a lot of external profiling such as restriction of characters, restriction of combination of characters and addition of language information is necessary. This memo provides information on such profiling, along with charset names to each profiled instance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1815 RFC1816 U.S. Government Internet Domain Names Federal Networking Council August 1995 ASCII HTML 8 GOV FNC IANA

This memo provides an update and clarification to RFC 1811. This document describes the registration policies for the top-level domain ".GOV". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1811 RFC2146 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1816 RFC1817 CIDR and Classful Routing Y. Rekhter August 1995 ASCII HTML 2 Classless Inter Domain Routing

This document represents the IAB's (Internet Architecture Board) evaluation of the current and near term implications of CIDR on organizations that use Classful routing technology. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1817 RFC1818 Best Current Practices J. Postel T. Li Y. Rekhter August 1995 ASCII HTML 3 BCP

This document describes a new series of documents which describe best current practices for the Internet community. Documents in this series carry the endorsement of the Internet Engineering Steering Group (IESG).

 HISTORIC BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=1818 10.17487/RFC1818 RFC1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+ L. Delgrossi Editor L. Berger Editor August 1995 ASCII HTML 109 ST2

This memo contains a revised specification of the Internet STream Protocol Version 2 (ST2). This memo defines an Experimental Protocol for the Internet community.

 RFC1190 IEN119 HISTORIC EXPERIMENTAL IETF int st2 10.17487/RFC1819 RFC1820 Multimedia E-mail (MIME) User Agent Checklist E. Huizer August 1995 ASCII HTML 8 Multipurpose Internet Mail Extensions Media Types

This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1844 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1820 RFC1821 Integration of Real-time Services in an IP-ATM Network Architecture M. Borden E. Crawley B. Davie S. Batsell August 1995 ASCII HTML 24 Asynchronous Transfer Mode

The purpose of this paper is to provide a clear statement of what issues need to be addressed in interfacing the IP integrated services environment with an ATM service environment so as to create a seamless interface between the two in support of end users desiring real-time networking services. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1821 RFC1822 A Grant of Rights to Use a Specific IBM patent with Photuris J. Lowe August 1995 ASCII HTML 2 Internet Key Management Protocol IKMP IETF

This Request for Comments records a grant by IBM Corporation to permit the conditional free use of one of its patents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1822 RFC1823 The LDAP Application Program Interface T. Howes M. Smith August 1995 ASCII HTML 22 lightweight directory access protocol API X.500

This document defines a C language application program interface to the lightweight directory access protocol (LDAP). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1823 RFC1824 The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4) H. Danisch August 1995 ASCII HTML 21 TESS public keys

This informational RFC describes the basic mechanisms and functions of an identity based system for the secure authenticated exchange of cryptographic keys, the generation of signatures, and the authentic distribution of public keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1824 RFC1825 Security Architecture for the Internet Protocol R. Atkinson August 1995 ASCII HTML 22 IPv4 IPv6 IP-layer ipsec

This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS-TRACK]

 RFC2401 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1825 RFC1826 IP Authentication Header R. Atkinson August 1995 ASCII HTML 13 ipsec IPV6-AH Internet Protocol AH security IPv4 IPv6

This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK]

 RFC2402 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1826 RFC1827 IP Encapsulating Security Payload (ESP) R. Atkinson August 1995 ASCII HTML 12 ESP Internet Protocol IPv4 IPv6 ipsec

This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams. [STANDARDS-TRACK]

 RFC2406 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1827 RFC1828 IP Authentication using Keyed MD5 P. Metzger W. Simpson August 1995 ASCII HTML 6 ipsec Internet Protocol Authentication Header AH Message Digest MD5 Security

This document describes the use of keyed MD5 with the IP Authentication Header. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1828 RFC1829 The ESP DES-CBC Transform P. Karn P. Metzger W. Simpson August 1995 ASCII HTML 11 Encapsulating Security Payload US Data Encryption Standard Cipher Block Chaining IP Internet Protocol Security ipsec

This document describes the DES-CBC security transform for the IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1829 RFC1830 SMTP Service Extensions for Transmission of Large and Binary MIME Messages G. Vaudreuil August 1995 ASCII HTML 8 Simple Mail Transfer Multipurpose Mail Extensions

This memo defines two extensions to the SMTP service. The first service enables a SMTP client and server to negotiate the use of an alternate DATA command "BDAT" for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of unencoded binary data. This memo defines an Experimental Protocol for the Internet community.

 RFC3030 EXPERIMENTAL EXPERIMENTAL IETF app mailext 10.17487/RFC1830 RFC1831 RPC: Remote Procedure Call Protocol Specification Version 2 R. Srinivasan August 1995 ASCII HTML 18 RPC ONC Open Network Computing

This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]

 RFC5531 PROPOSED STANDARD PROPOSED STANDARD IETF tsv oncrpc 10.17487/RFC1831 RFC1832 XDR: External Data Representation Standard R. Srinivasan August 1995 ASCII HTML 24 XDR RPC ONC Open Network Computing

This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]

 RFC4506 DRAFT STANDARD PROPOSED STANDARD IETF tsv oncrpc 10.17487/RFC1832 RFC1833 Binding Protocols for ONC RPC Version 2 R. Srinivasan August 1995 ASCII HTML 14 ONC Open Network Computing

This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK]

 RFC5665 PROPOSED STANDARD PROPOSED STANDARD IETF tsv oncrpc 10.17487/RFC1833 RFC1834 Whois and Network Information Lookup Service, Whois++ J. Gargano K. Weiss August 1995 ASCII HTML 7 nicname TCP Transmission Control Protocol directory service server retrieval

This memo describes new features for WHOIS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF wnils 10.17487/RFC1834 RFC1835 Architecture of the WHOIS++ service P. Deutsch R. Schoultz P. Faltstrom C. Weider August 1995 ASCII HTML 41 WHOIS++ nicname TCP Transmission Control Protocol directory service server retrieval

This document describes WHOIS++, an extension to the trivial WHOIS service described in RFC 954 to permit WHOIS-like servers to make available more structured information to the Internet. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF wnils 10.17487/RFC1835 RFC1836 Representing the O/R Address hierarchy in the X.500 Directory Information Tree S. Kille August 1995 ASCII HTML 11 message handling

This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This memo defines an Experimental Protocol for the Internet community.

 RFC2294 EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1836 RFC1837 Representing Tables and Subtrees in the X.500 Directory S. Kille August 1995 ASCII HTML 7 message handling

This document defines techniques for representing two types of information mapping in the OSI Directory. This memo defines an Experimental Protocol for the Internet community.

 RFC2293 EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1837 RFC1838 Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses S. Kille August 1995 ASCII HTML 8 message handling

This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2]. This memo defines an Experimental Protocol for the Internet community.

 RFC2164 EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1838 RFC1839 RFC1840 RFC1841 PPP Network Control Protocol for LAN Extension J. Chapman D. Coli A. Harvey B. Jensen K. Rowett September 1995 ASCII HTML 66 point-to-point local area interface, INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1841 RFC1842 ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages Y. Wei Y. Zhang J. Li J. Ding Y. Jiang August 1995 ASCII HTML 12 electronic mail HZ-GB-2312

This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages over the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Telecommunications infrastructure is improving to offer higher bandwidth connections at lower cost. Access to the network is changing from modems to more intelligent devices. This informational RFC discusses a PPP Network Control Protocol for one such intelligent device. The protocol is the LAN extension interface protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1842 RFC1843 HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters F. Lee August 1995 ASCII HTML 5 GB2312-80 electronic mail

The content of this memo is identical to an article of the same title written by the author on September 4, 1989. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1843 RFC1844 Multimedia E-mail (MIME) User Agent Checklist E. Huizer August 1995 ASCII HTML 8 Multipurpose Internet Mail Extensions Media Types

This document presents a checklist to facilitate evaluation of MIME capable User Agents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1820 INFORMATIONAL INFORMATIONAL IETF app mailext 10.17487/RFC1844 RFC1845 SMTP Service Extension for Checkpoint/Restart D. Crocker N. Freed A. Cargille September 1995 ASCII HTML 7 simple mail transfer transaction EXPERIMENTAL EXPERIMENTAL IETF app mailext 10.17487/RFC1845 RFC1846 SMTP 521 Reply Code A. Durand F. Dupont September 1995 ASCII HTML 4 simple mail transfer RFC7504 EXPERIMENTAL EXPERIMENTAL IETF app mailext 10.17487/RFC1846 RFC1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted J. Galvin S. Murphy S. Crocker N. Freed October 1995 ASCII HTML 11 MIME-Encyp mail multipurpose extensions

This document defines a framework within which security services may be applied to MIME body parts. [STANDARDS-TRACK] This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail. This memo defines an Experimental Protocol for the Internet community. This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption. This memo defines an Experimental Protocol for the Internet community.

 PROPOSED STANDARD PROPOSED STANDARD IETF sec pem 10.17487/RFC1847 RFC1848 MIME Object Security Services S. Crocker N. Freed J. Galvin S. Murphy October 1995 ASCII HTML 48 MIME-Sec mail multipurpose extensions

This document defines MIME Object Security Services (MOSS), a protocol that uses the multipart/signed and multipart/encrypted framework [7] to apply digital signature and encryption services to MIME objects. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1848 RFC1849 "Son of 1036": News Article Format and Transmission H. Spencer March 2010 ASCII HTML 106 netnews usenet rfc 1036 usefor historic

By the early 1990s, it had become clear that RFC 1036, then the specification for the Interchange of USENET Messages, was badly in need of repair. This "Internet-Draft-to-be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adopted Proposed Standards for Netnews.

It is being published now in order to provide the historical background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations. This document defines a Historic Document for the Internet community.

 draft-spencer-usefor-son-of-1036-01 RFC5536 RFC5537 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC1849 RFC1850 OSPF Version 2 Management Information Base F. Baker R. Coltun November 1995 ASCII HTML 80 OSPF-MIB Open Shortest Path First SPF MIB routing network management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol. [STANDARDS-TRACK]

 RFC1253 RFC4750 DRAFT STANDARD DRAFT STANDARD IETF rtg ospf 10.17487/RFC1850 RFC1851 The ESP Triple DES Transform P. Karn P. Metzger W. Simpson September 1995 ASCII HTML 11 ESP3DES encryption encapsulating security payload cipher block chaining EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1851 RFC1852 IP Authentication using Keyed SHA P. Metzger W. Simpson September 1995 ASCII HTML 6 encryption secure hash algorithm RFC2841 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1852 RFC1853 IP in IP Tunneling W. Simpson October 1995 ASCII HTML 8 internet protocol payload encapsulation

This document discusses implementation techniques for using IP Protocol/Payload number 4 Encapsulation for tunneling with IP Security and other protocols. This memo provides information for the Internet community. It does not specify an Internet standard. This document describes the use of keyed SHA with the IP Authentication Header. This document defines an Experimental Protocol for the Internet community. This document describes the Triple DES-CBC security transform for the IP Encapsulating Security Payload (ESP). This document defines an Experimental Protocol for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1853 RFC1854 SMTP Service Extension for Command Pipelining N. Freed October 1995 ASCII HTML 7 simple mail transfer protocol

This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]

 RFC2197 PROPOSED STANDARD PROPOSED STANDARD IETF app mailext 10.17487/RFC1854 RFC1855 Netiquette Guidelines S. Hambridge October 1995 ASCII HTML 21 Network Etiquette

This document provides a minimum set of guidelines for Network Etiquette (Netiquette) which organizations may take and adapt for their own use. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 FYI0028 INFORMATIONAL INFORMATIONAL IETF run http://www.rfc-editor.org/errata_search.php?rfc=1855 10.17487/RFC1855 RFC1856 The Opstat Client-Server Model for Statistics Retrieval H. Clark September 1995 ASCII HTML 17 tools performance utilization INFORMATIONAL INFORMATIONAL IETF opstat 10.17487/RFC1856 RFC1857 A Model for Common Operational Statistics M. Lambert October 1995 ASCII HTML 27 metrics measurements polling periods

This memo describes a model for operational statistics in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document defines a model and protocol for a set of tools which could be used by NSPs and Network Operation Centers (NOCs) to share data among themselves and with customers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1404 INFORMATIONAL INFORMATIONAL IETF opstat 10.17487/RFC1857 RFC1858 Security Considerations for IP Fragment Filtering G. Ziemba D. Reed P. Traina October 1995 ASCII HTML 10 internet protocol tcp transmission control protocol routers hosts

IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC3128 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1858 RFC1859 ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension Y. Pouffary October 1995 ASCII HTML 8 International Standard Organizatio

This document is an extension to STD35, RFC1006, a standard for the Internet community. The document does not duplicate the protocol definitions contained in RFC1006 and in International Standard ISO 8073. It supplements that information with the description of how to implement ISO Transport Class 2 Non-use of Explicit Flow Control on top of TCP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1859 RFC1860 Variable Length Subnet Table For IPv4 T. Pummill B. Manning October 1995 ASCII HTML 3 values IPv4 subnets

This document itemizes the potential values for IPv4 subnets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1878 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1860 RFC1861 Simple Network Paging Protocol - Version 3 -Two-Way Enhanced A. Gwinn October 1995 ASCII HTML 23 SNPP SNPP wireless paging

This RFC suggests a simple way for delivering wireless messages, both one and two-way, to appropriate receiving devices. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1645 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1861 RFC1862 Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994 M. McCahill J. Romkey M. Schwartz K. Sollins T. Verschuren C. Weider November 1995 ASCII HTML 27 Internet Architecture Board

This document is a report on an Internet architecture workshop, initiated by the IAB and held at MCI on October 12-14, 1994. This workshop generally focused on aspects of the information infrastructure on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1862 RFC1863 A BGP/IDRP Route Server alternative to a full mesh routing D. Haskin October 1995 ASCII HTML 16 BGP-IDRP border gateway protocol inter-domain routing

This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers. This memo defines an Experimental Protocol for the Internet community.

 RFC4223 HISTORIC EXPERIMENTAL IETF rtg idr 10.17487/RFC1863 RFC1864 The Content-MD5 Header Field J. Myers M. Rose October 1995 ASCII HTML 4 CON-MD5 MIME EMail Integrity MIC Digest

This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. [STANDARDS-TRACK]

 RFC1544 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1864 RFC1865 EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet W. Houser J. Griffin C. Hage January 1996 ASCII HTML 41 FAQ

This memo is targeted towards the EDI community that is unfamiliar with the Internet, including EDI software developers, users, and service providers. The memo introduces the Internet and assumes a basic knowledge of EDI. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app edi http://www.rfc-editor.org/errata_search.php?rfc=1865 10.17487/RFC1865 RFC1866 Hypertext Markup Language - 2.0 T. Berners-Lee D. Connolly November 1995 ASCII HTML 77 HTML SGML Standard Generalized Language WWW World Wide Web

This document defines a HTML 2.0 (to distinguish it from the previous informal specifications). [STANDARDS-TRACK]

 RFC2854 HISTORIC PROPOSED STANDARD IETF app html 10.17487/RFC1866 RFC1867 Form-based File Upload in HTML E. Nebel L. Masinter November 1995 ASCII HTML 13 Hypertext Markup Language MIME Multipurpose Internet Mail Extensions

Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for file upload responses. This memo defines an Experimental Protocol for the Internet community.

 RFC2854 HISTORIC EXPERIMENTAL IETF app html http://www.rfc-editor.org/errata_search.php?rfc=1867 10.17487/RFC1867 RFC1868 ARP Extension - UNARP G. Malkin November 1995 ASCII HTML 4 UNARP Address Resolution Protocol delete entry

This document specifies a trivial modification to the ARP mechanism, not the packet format, which allows a node to announce that it is leaving the network and that all other nodes should modify their ARP tables accordingly. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1868 RFC1869 SMTP Service Extensions J. Klensin N. Freed M. Rose E. Stefferud D. Crocker November 1995 ASCII HTML 11 ESMTP Simple Mail Transfer Protocol

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

 RFC1651 RFC2821 STD0010 INTERNET STANDARD INTERNET STANDARD IETF app smtpext 10.17487/RFC1869 RFC1870 SMTP Service Extension for Message Size Declaration J. Klensin N. Freed K. Moore November 1995 ASCII HTML 9 SMTP-SIZE Simple Mail Transfer Protocol

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]

 RFC1653 STD0010 INTERNET STANDARD INTERNET STANDARD IETF app smtpext 10.17487/RFC1870 RFC1871 Addendum to RFC 1602 -- Variance Procedure J. Postel November 1995 ASCII HTML 4 BCP WG escape clause procedures

This document describes a modification to the IETF procedures to allow an escape from a situation where the existing procedures are not working or do not seem to apply. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC2026 RFC1602 RFC1603 HISTORIC BEST CURRENT PRACTICE Legacy 10.17487/RFC1871 RFC1872 The MIME Multipart/Related Content-type E. Levinson December 1995 ASCII HTML 8 multipurpose Internet Mail Extensions

The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. This memo defines an Experimental Protocol for the Internet community.

 RFC2112 EXPERIMENTAL EXPERIMENTAL IETF app mimesgml 10.17487/RFC1872 RFC1873 Message/External-Body Content-ID Access Type E. Levinson December 1995 ASCII HTML 4 CONT-MT Multipurpose Internet Mail Extensions

The existing MIME Content-Type Message/External-Body access-types allow a MIME entity (body-part) to refer to an object that is not in the message by specifying how to access that object. The Content-ID access method described in this document provides the capability to refer to an object within the message. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app mimesgml 10.17487/RFC1873 RFC1874 SGML Media Types E. Levinson December 1995 ASCII HTML 6 SGML-MT Multipurpose Internet Mail Extensions

This document proposes new media sub-types of Text/SGML and Application/SGML. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app mimesgml 10.17487/RFC1874 RFC1875 UNINETT PCA Policy Statements N. Berge December 1995 ASCII HTML 10 Policy Certification Authority Encryption

This document provides information about policy statements submitted by the UNINETT Policy Certification Authority (UNINETT PCA). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1875 RFC1876 A Means for Expressing Location Information in the Domain Name System C. Davis P. Vixie T. Goodwin I. Dickinson January 1996 ASCII HTML 18 DNS-LOC DNS Resource Record (RR) LOC

This memo defines a new DNS RR type for experimental purposes. This RFC describes a mechanism to allow the DNS to carry location information about hosts, networks, and subnets. This memo defines an Experimental Protocol for the Internet community.

 RFC1034 RFC1035 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1876 RFC1877 PPP Internet Protocol Control Protocol Extensions for Name Server Addresses S. Cobb December 1995 ASCII HTML 6 Point-to-Point Protocol Network Control Domain System NetBIOS

This document extends the NCP for establishing and configuring the Internet Protocol over PPP [2], defining the negotiation of primary and secondary Domain Name System (DNS) [3] and NetBIOS Name Server (NBNS) [4] addresses. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1877 RFC1878 Variable Length Subnet Table For IPv4 T. Pummill B. Manning December 1995 ASCII HTML 8 values IPv4 subnets

This memo clarifies issues surrounding subnetting IP networks by providing a standard subnet table. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1860 HISTORIC INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1878 10.17487/RFC1878 RFC1879 Class A Subnet Experiment Results and Recommendations B. Manning Editor January 1996 ASCII HTML 6 Internet Registry Operations

This memo documents some experiences with the RFC 1797 [1] subnet A experiment (performed by the Net39 Test Group (see credits)) and provides a number of recommendations on future direction for both the Internet Registries and the Operations community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1879 RFC1880 Internet Official Protocol Standards J. Postel Editor November 1995 ASCII HTML 38 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

 RFC1800 RFC1920 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1880 RFC1881 IPv6 Address Allocation Management IAB IESG December 1995 ASCII HTML 2 IANA Internet Assigned Numbers Authority

The IPv6 address space will be managed by the IANA for the good of the Internet community, with advice from the IAB and the IESG, by delegation to the regional registries. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1881 RFC1882 The 12-Days of Technology Before Christmas B. Hancock December 1995 ASCII HTML 5

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1882 RFC1883 Internet Protocol, Version 6 (IPv6) Specification S. Deering R. Hinden December 1995 ASCII HTML 37 IP Next Generation IPng

This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]

 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1883 RFC1884 IP Version 6 Addressing Architecture R. Hinden Editor S. Deering Editor December 1995 ASCII HTML 18 IPV6-Addr IP Next Generation IPng

This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]

 RFC2373 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1884 RFC1885 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) A. Conta S. Deering December 1995 ASCII HTML 20 IP Next Generation IPng Internet Group Management IGMP

This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]

 RFC2463 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1885 RFC1886 DNS Extensions to support IP version 6 S. Thomson C. Huitema December 1995 ASCII HTML 5 DNS-IPV6 IP Next Generation IPng Domain Name System

This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). [STANDARDS-TRACK]

 RFC3596 RFC2874 RFC3152 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1886 RFC1887 An Architecture for IPv6 Unicast Address Allocation Y. Rekhter Editor T. Li Editor December 1995 ASCII HTML 26 IP Next Generation IPng,

This document provides an architecture for allocating IPv6 [1] unicast addresses in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC1887 RFC1888 OSI NSAPs and IPv6 J. Bound B. Carpenter D. Harrington J. Houldsworth A. Lloyd August 1996 ASCII HTML 16 Internet Protocol Open Systems Interconnection

This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. This memo defines an Experimental Protocol for the Internet community.

 RFC4048 RFC4548 HISTORIC EXPERIMENTAL IETF int ipngwg 10.17487/RFC1888 RFC1889 RTP: A Transport Protocol for Real-Time Applications Audio-Video Transport Working Group H. Schulzrinne S. Casner R. Frederick V. Jacobson January 1996 ASCII HTML 75 RTP end-to-end network audio video RTCP

This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. [STANDARDS-TRACK]

 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC1889 RFC1890 RTP Profile for Audio and Video Conferences with Minimal Control Audio-Video Transport Working Group H. Schulzrinne January 1996 ASCII HTML 18 RTP-AV end-to-end network conference

This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. [STANDARDS-TRACK]

 RFC3551 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC1890 RFC1891 SMTP Service Extension for Delivery Status Notifications K. Moore January 1996 ASCII HTML 31 SMTP-DSN simple mail transfer protocol

This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]

 RFC3461 PROPOSED STANDARD PROPOSED STANDARD IETF app notary http://www.rfc-editor.org/errata_search.php?rfc=1891 10.17487/RFC1891 RFC1892 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages G. Vaudreuil January 1996 ASCII HTML 4 MIME-RPT Multipurpose Internet Mail Extensions

The Multipart/Report MIME content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. [STANDARDS-TRACK]

 RFC3462 PROPOSED STANDARD PROPOSED STANDARD IETF app notary 10.17487/RFC1892 RFC1893 Enhanced Mail System Status Codes G. Vaudreuil January 1996 ASCII HTML 15 EMS-CODE simple mail transfer protocol SMTP

There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages. There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes for this purpose. [STANDARDS-TRACK]

 RFC3463 PROPOSED STANDARD PROPOSED STANDARD IETF app notary 10.17487/RFC1893 RFC1894 An Extensible Message Format for Delivery Status Notifications K. Moore G. Vaudreuil January 1996 ASCII HTML 39 DSN Multipurpose Internet Mail Extensions Content Type

This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. [STANDARDS-TRACK]

 RFC3464 RFC2852 PROPOSED STANDARD PROPOSED STANDARD IETF app notary http://www.rfc-editor.org/errata_search.php?rfc=1894 10.17487/RFC1894 RFC1895 The Application/CALS-1840 Content-type E. Levinson February 1996 ASCII HTML 6 MIL-STD-1840 MIME Multipurpose Internet Mail Extensions

This memorandum provides guidelines for using the United States Department of Defense Military Standard MIL-STD-1840, "Automated Interchange of Technical Information," with the Internet electronic mail standards, RFC 822 and RFC 1521. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1895 RFC1896 The text/enriched MIME Content-type P. Resnick A. Walker February 1996 ASCII PS HTML 21 MIME Multipurpose Internet Mail Extensions

This document defines one particular type of MIME data, the text/enriched MIME type. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1523 RFC1563 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1896 RFC1897 IPv6 Testing Address Allocation R. Hinden J. Postel January 1996 ASCII HTML 4 Internet Protocol prototype software

This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This document specifies an Experimental protocol for the Internet community.

 RFC2471 EXPERIMENTAL EXPERIMENTAL IETF int ipngwg 10.17487/RFC1897 RFC1898 CyberCash Credit Card Protocol Version 0.8 D. Eastlake 3rd B. Boesch S. Crocker M. Yesil February 1996 ASCII HTML 52 general payments system

This document covers only the current CyberCash system which is one of the few operational systems in the rapidly evolving area of Internet payments. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1898 RFC1899 Request for Comments Summary RFC Numbers 1800-1899 J. Elliott January 1997 ASCII HTML 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1899 RFC1900 Renumbering Needs Work B. Carpenter Y. Rekhter February 1996 ASCII HTML 4 IP network number addressing

Hosts in an IP network are identified by IP addresses, and the IP address prefixes of subnets are advertised by routing protocols. A change in such IP addressing information associated with a host or subnet is known as "renumbering". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1900 RFC1901 Introduction to Community-based SNMPv2 J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 8 SNMPV2CB Simple Network Management Protocol Version 2

The purpose of this document is to define the Community-based Administrative Framework for the SNMP version 2 framework (SNMPv2). This document specifies an Experimental protocol for the Internet community.

 HISTORIC EXPERIMENTAL IETF snmpv2 10.17487/RFC1901 RFC1902 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 40 Simple Network Management Protocol Version 2

It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]

 RFC1442 RFC2578 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1902 RFC1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 23 Simple Network Management Protocol Version 2

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

 RFC1443 RFC2579 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1903 RFC1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 24 Simple Network Management Protocol Version 2

It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

 RFC1444 RFC2580 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1904 RFC1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 24 OPS-MIB Simple Network Management Protocol Version 2

It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]

 RFC1448 RFC3416 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1905 RFC1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 13 TRANS-MIB Simple Network Management Protocol Version 2

It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]

 RFC1449 RFC3417 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1906 RFC1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 20 SNMPv2-MIB Simple Network Management Protocol Version 2

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]

 RFC1450 RFC3418 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1907 RFC1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 10 COEX-MIB Simple Network Management Protocol Version 2

The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework [1-6], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]

 RFC1452 RFC2576 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1908 RFC1909 An Administrative Infrastructure for SNMPv2 K. McCloghrie Editor February 1996 ASCII HTML 19 SNMPV2AI Simple Network Management Protocol Version 2

It is the purpose of this document, An Administrative Infrastructure for SNMPv2, to define an administrative framework which realizes effective management in a variety of configurations and environments. This memo defines an Experimental Protocol for the Internet community.

 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1909 RFC1910 User-based Security Model for SNMPv2 G. Waters Editor February 1996 ASCII HTML 44 SNMPV2SM Simple Network Management Protocol Version 2

In this administrative framework, a security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions. Although many such security models might be defined, it is the purpose of this document, User-based Security Model for SNMPv2, to define the first, and, as of this writing, only, security model for this administrative framework. This memo defines an Experimental Protocol for the Internet community.

 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1910 RFC1911 Voice Profile for Internet Mail G. Vaudreuil February 1996 ASCII HTML 22 MIME Multipurpose Internet Mail Extensions ESMTP SMTP Service Extensions

The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol. This memo defines an Experimental Protocol for the Internet community.

 RFC2421 RFC2422 RFC2423 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1911 RFC1912 Common DNS Operational and Configuration Errors D. Barr February 1996 ASCII HTML 16 Domain Name System

This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1537 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1912 10.17487/RFC1912 RFC1913 Architecture of the Whois++ Index Service C. Weider J. Fullton S. Spero February 1996 ASCII HTML 16 WHOIS++A Bunyip Information Systems Inc. MCNC Center for Communications

The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol. [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF wnils 10.17487/RFC1913 RFC1914 How to Interact with a Whois++ Mesh P. Faltstrom R. Schoultz C. Weider February 1996 ASCII HTML 10 WHOIS++M distributed databases directory service

In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done by the client, since each server 'refers' the client to the next appropriate server(s). [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF wnils 10.17487/RFC1914 RFC1915 Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol F. Kastenholz February 1996 ASCII HTML 7 Point to Point Protocol

The PPP Working group has developed two protocols, one to control compression on PPP links; the Compression Control Protocol (CCP), documented in draft-ietf-pppext-compression-04.txt. The second is the Encryption Control Protocol (ECP), used to control encryption on serial links, documented in draft-ietf-pppext-encryption-03.txt. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0003 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=1915 10.17487/RFC1915 RFC1916 Enterprise Renumbering: Experience and Information Solicitation H. Berkowitz P. Ferguson W. Leland P. Nesser February 1996 ASCII HTML 8 tools applications

Because of the urgent need for, and substantial difficulty in, renumbering IP networks, the PIER working group is compiling a series of documents to assist sites in their renumbering efforts. The intent of these documents is to provide both educational and practical information to the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF ops pier 10.17487/RFC1916 RFC1917 An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA P. Nesser II February 1996 ASCII HTML 10 address space Internet Assigned Numbers Authority IANA

This document is an appeal to the Internet community to return unused address space, i.e. any block of consecutive IP prefixes, to the Internet Assigned Numbers Authority (IANA) or any of the delegated registries, for reapportionment. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0004 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF cidrd 10.17487/RFC1917 RFC1918 Address Allocation for Private Internets Y. Rekhter B. Moskowitz D. Karrenberg G. J. de Groot E. Lear February 1996 ASCII HTML 9 TCP/IP network host

This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC1627 RFC1597 RFC6761 BCP0005 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF cidrd http://www.rfc-editor.org/errata_search.php?rfc=1918 10.17487/RFC1918 RFC1919 Classical versus Transparent IP Proxies M. Chatel March 1996 ASCII HTML 35 firewalls security

This document explains "classical" and "transparent" proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1919 RFC1920 Internet Official Protocol Standards J. Postel March 1996 ASCII HTML 40 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

 RFC1880 RFC2000 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1920 RFC1921 TNVIP Protocol J. Dujonc March 1996 ASCII HTML 30

The goal of this document specifies a Telnet profile to support VIP terminal emulation allowing the access to the BULL hosts applications through a TCP/IP network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1921 RFC1922 Chinese Character Encoding for Internet Messages HF. Zhu DY. Hu ZG. Wang TC. Kao WCH. Chang M. Crispin March 1996 ASCII HTML 27 transport electronic mail telnet WWW

This memo describes methods of transporting Chinese characters in Internet services which transport text, such as electronic mail [RFC-822], network news [RFC-1036], telnet [RFC-854] and the World Wide Web [RFC-1866]. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1922 RFC1923 RIPv1 Applicability Statement for Historic Status J. Halpern S. Bradner March 1996 ASCII HTML 3 Routing Information Protocol

RIP Version 1 [RFC-1058] has been declared an historic document. This Applicability statement provides the supporting motivation for that declaration. The primary reason, as described below, is the Classful nature of RIPv1. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg rip 10.17487/RFC1923 RFC1924 A Compact Representation of IPv6 Addresses R. Elz April 1 1996 ASCII HTML 6 encoding

This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1924 RFC1925 The Twelve Networking Truths R. Callon April 1 1996 ASCII HTML 3 fundamentals

This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1925 10.17487/RFC1925 RFC1926 An Experimental Encapsulation of IP Datagrams on Top of ATM J. Eriksson April 1 1996 ASCII HTML 2 Acoustical Transmission Media (ATM)

This RFC describes a method of encapsulating IP datagrams on top of Acoustical Transmission Media (ATM). This is a non-recommended standard. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1926 RFC1927 Suggested Additional MIME Types for Associating Documents C. Rogers April 1 1996 ASCII HTML 3 media-type

Seven new types of MIME types are suggested in this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1927 10.17487/RFC1927 RFC1928 SOCKS Protocol Version 5 M. Leech M. Ganis Y. Lee R. Kuris D. Koblas L. Jones March 1996 ASCII HTML 9 SOCKSV5 firewalls authentication

This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec aft http://www.rfc-editor.org/errata_search.php?rfc=1928 10.17487/RFC1928 RFC1929 Username/Password Authentication for SOCKS V5 M. Leech March 1996 ASCII HTML 2 AUTH-SOCKS firewalls authentication

The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec aft 10.17487/RFC1929 RFC1930 Guidelines for creation, selection, and registration of an Autonomous System (AS) J. Hawkinson T. Bates March 1996 ASCII HTML 10 routing policy Exterior Gateway Protocol Border Inter-Domain Domain Identifier EGP BGP IDRP

This memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC6996 RFC7300 BCP0006 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC1930 RFC1931 Dynamic RARP Extensions for Automatic Network Address Acquisition D. Brownell April 1996 ASCII HTML 11 Reverse Address Resolution Protocol

This memo describes extensions to the Reverse Address Resolution Protocol (RARP [2]) and called Dynamic RARP (DRARP, pronounced D-RARP). This memo provides information for the Internet community. This memo does not define an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1931 RFC1932 IP over ATM: A Framework Document R. Cole D. Shur C. Villamizar April 1996 ASCII HTML 31 end-to-end connectivity

It is hoped that this document, in classifying ATM approaches and issues will help to focus the IP over ATM working group's direction.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ipatm 10.17487/RFC1932 RFC1933 Transition Mechanisms for IPv6 Hosts and Routers R. Gilligan E. Nordmark April 1996 ASCII HTML 22 TRANS-IPV6 IPv4

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]

 RFC2893 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC1933 RFC1934 Ascend's Multilink Protocol Plus (MP+) K. Smith April 1996 ASCII HTML 47 PPP

This document proposes an extension to the PPP Multilink Protocol (MP) [1]. Multilink Protocol Plus (MP+) is a new control protocol for managing multiple data links that are bundled by MP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1934 RFC1935 What is the Internet, Anyway? J. Quarterman S. Carl-Mitchell April 1996 ASCII HTML 11 information tutorial

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1935 RFC1936 Implementing the Internet Checksum in Hardware J. Touch B. Parham April 1996 ASCII HTML 21 PLD code UDP TCP

This memo presents a techniques for efficiently implementing the Internet Checksum in hardware. It includes PLD code for programming a single, low cost part to perform checksumming at 1.26 Gbps. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1936 10.17487/RFC1936 RFC1937 "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks Y. Rekhter D. Kandlur May 1996 ASCII HTML 8 IP subnet

This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by SVC-based Data Link subnetworks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg rolc 10.17487/RFC1937 RFC1938 A One-Time Password System N. Haller C. Metz May 1996 ASCII HTML 18 OTP authentication S/KEY

This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK]

 RFC2289 PROPOSED STANDARD PROPOSED STANDARD IETF sec otp 10.17487/RFC1938 RFC1939 Post Office Protocol - Version 3 J. Myers M. Rose May 1996 ASCII HTML 23 POP3

The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK]

 RFC1725 RFC1957 RFC2449 RFC6186 RFC8314 STD0053 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1939 10.17487/RFC1939 RFC1940 Source Demand Routing: Packet Format and Forwarding Specification (Version 1) D. Estrin T. Li Y. Rekhter K. Varadhan D. Zappala May 1996 ASCII HTML 27 SDRP

The purpose of SDRP is to support source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg sdr 10.17487/RFC1940 RFC1941 Frequently Asked Questions for Schools J. Sellers J. Robichaux May 1996 ASCII HTML 70 FAQ Internet Education

The goal of this FYI document, produced by the Internet School Networking (ISN) group in the User Services Area of the Internet Engineering Task Force (IETF), is to act as an introduction to the Internet for faculty, administration, and other school personnel in primary and secondary schools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1578 FYI0022 INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1941 RFC1942 HTML Tables D. Raggett May 1996 ASCII HTML 30 HTML-TBL HyperText Markup Language SGML

This specification extends HTML to support a wide variety of tables. This memo defines an Experimental Protocol for the Internet community.

 RFC2854 HISTORIC EXPERIMENTAL IETF app html 10.17487/RFC1942 RFC1943 Building an X.500 Directory Service in the US B. Jennings May 1996 ASCII HTML 22 White Pages

This document provides definition and recommends considerations that must be undertaken to operate a X.500 Directory Service in the United States. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1943 RFC1944 Benchmarking Methodology for Network Interconnect Devices S. Bradner J. McQuaid May 1996 ASCII HTML 30 testing performance

This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2544 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC1944 RFC1945 Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee R. Fielding H. Frystyk May 1996 ASCII HTML 60 HTTP-1.0 HTTP World-Wide Web application

The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app http 10.17487/RFC1945 RFC1946 Native ATM Support for ST2+ S. Jackowski May 1996 ASCII HTML 21 integrated services ATM Quality of Service QoS

This memo describes a working implementation which enables applications to directly invoke ATM services in the following environments: ATM to internet, internet to ATM, and internet to internet across ATM. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1946 RFC1947 Greek Character Encoding for Electronic Mail Messages D. Spinellis May 1996 ASCII HTML 7 character set ISO MIME

This document describes a standard encoding for electronic mail [RFC822] containing Greek text and provides implementation guide-lines. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1947 RFC1948 Defending Against Sequence Number Attacks S. Bellovin May 1996 ASCII HTML 6 crypgraphic authentication spoofing

IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC6528 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1948 10.17487/RFC1948 RFC1949 Scalable Multicast Key Distribution A. Ballardie May 1996 ASCII HTML 18 SMKD MBONE security authentication

This memo provides a scalable solution to the multicast key distribution problem. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF rtg idmr 10.17487/RFC1949 RFC1950 ZLIB Compressed Data Format Specification version 3.3 P. Deutsch J-L. Gailly May 1996 ASCII PS PDF HTML 11 ZLIB compressed data format checksum

This specification defines a lossless compressed data format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1950 RFC1951 DEFLATE Compressed Data Format Specification version 1.3 P. Deutsch May 1996 ASCII PS PDF HTML 17 DEFLATE compressed data format coding

This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1951 RFC1952 GZIP file format specification version 4.3 P. Deutsch May 1996 ASCII PS PDF HTML 12 GZIP compressed data format redundancy check

This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1952 RFC1953 Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall May 1996 ASCII HTML 20 IFMP IP flow routing information

The Ipsilon Flow Management Protocol (IFMP), is a protocol for allowing a node to instruct an adjacent node to attach a layer 2 label to a specified IP flow. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1953 RFC1954 Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall May 1996 ASCII HTML 8 datagrams IFMP

This document specifies the manner for transmitting IPv4 datagrams over an ATM data link, both in a default manner and in the presence of flow labelling via Ipsilon Flow Management Protocol [IFMP]. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1954 RFC1955 New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG R. Hinden June 1996 ASCII HTML 5 IPNG addressing routing

This paper proposes a new scheme which I believe is a good medium term solution to the routing and address problems of the internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1955 RFC1956 Registration in the MIL Domain D. Engebretson R. Plzak June 1996 ASCII HTML 2 DoD Department of Defense

This RFC describes the policy for the registration of second level domains under the ".MIL" domain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1956 RFC1957 Some Observations on Implementations of the Post Office Protocol (POP3) R. Nelson June 1996 ASCII HTML 2 client server

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1939 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1957 RFC1958 Architectural Principles of the Internet B. Carpenter Editor June 1996 ASCII HTML 8 IAB

The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC3439 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1958 RFC1959 An LDAP URL Format T. Howes M. Smith June 1996 ASCII HTML 4 LDAP-URL Lightweight Directory Access Protocol Uniform Resource Locator

This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. [STANDARDS-TRACK]

 RFC2255 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=1959 10.17487/RFC1959 RFC1960 A String Representation of LDAP Search Filters T. Howes June 1996 ASCII HTML 3 LDAP-STR Lightweight Directory Access Protocol

The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]

 RFC1558 RFC2254 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC1960 RFC1961 GSS-API Authentication Method for SOCKS Version 5 P. McMahon June 1996 ASCII HTML 9 GSSAPI-SOC Generic Security Service Application Program Interface

This document provides the specification for the SOCKS V5 GSS-API authentication protocol, and defines a GSS-API-based encapsulation for provision of integrity, authentication and optional confidentiality. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec aft 10.17487/RFC1961 RFC1962 The PPP Compression Control Protocol (CCP) D. Rand June 1996 ASCII HTML 9 PPP-CCP point-to-point protocol data links

This document defines a method for negotiating data compression over PPP links. [STANDARDS-TRACK]

 RFC2153 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1962 RFC1963 PPP Serial Data Transport Protocol (SDTP) K. Schneider S. Venters August 1996 ASCII HTML 20 Point-to-Point Protocol

This document describes a new Network level protocol (from the PPP point of view), PPP Serial Data Transport Protocol, that provides encapsulation and an associated control protocol for transporting serial data streams over a PPP link. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1963 RFC1964 The Kerberos Version 5 GSS-API Mechanism J. Linn June 1996 ASCII HTML 20 GSSAPI-KER Generic Security Service Application Program Interface

This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510). [STANDARDS-TRACK]

 RFC4121 RFC6649 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC1964 RFC1965 Autonomous System Confederations for BGP P. Traina June 1996 ASCII HTML 7 BGP-ASC Border Gateway Protocol

This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation. This memo defines an Experimental Protocol for the Internet community.

 RFC3065 EXPERIMENTAL EXPERIMENTAL IETF rtg idr 10.17487/RFC1965 RFC1966 BGP Route Reflection An alternative to full mesh IBGP T. Bates R. Chandra June 1996 ASCII HTML 7 BGP-RR Border Gateway Protocol autonomous system

This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. This memo defines an Experimental Protocol for the Internet community.

 RFC4456 RFC2796 EXPERIMENTAL EXPERIMENTAL IETF rtg idr 10.17487/RFC1966 RFC1967 PPP LZS-DCP Compression Protocol (LZS-DCP) K. Schneider R. Friend August 1996 ASCII HTML 18 Point-to-Point Protocol Compression Control CCP

This document describes the use of the Stac LZS data compression algorithm for compressing PPP encapsulated packets, using a DCP header [6]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1967 RFC1968 The PPP Encryption Control Protocol (ECP) G. Meyer June 1996 ASCII HTML 11 PPP-ECP Point-to-Point Protocol data

This document defines a method for negotiating data encryption over PPP links. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1968 RFC1969 The PPP DES Encryption Protocol (DESE) K. Sklower G. Meyer June 1996 ASCII HTML 10 Point-to-Point Protocol encapsulated packets

This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2419 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1969 RFC1970 Neighbor Discovery for IP Version 6 (IPv6) T. Narten E. Nordmark W. Simpson August 1996 ASCII HTML 82 Internet Protocol

This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]

 RFC2461 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1970 RFC1971 IPv6 Stateless Address Autoconfiguration S. Thomson T. Narten August 1996 ASCII HTML 23 Internet Protocol link-local address Duplicate Address Detection procedure

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]

 RFC2462 PROPOSED STANDARD PROPOSED STANDARD IETF int addrconf 10.17487/RFC1971 RFC1972 A Method for the Transmission of IPv6 Packets over Ethernet Networks M. Crawford August 1996 ASCII HTML 4 IPV6-ETHER Internet Protocol frame format transmission

This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK]

 RFC2464 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1972 RFC1973 PPP in Frame Relay W. Simpson June 1996 ASCII HTML 10 PPP-FRAME Point-to-Point Protocol encapsulated packets

This document describes the use of Frame Relay for framing PPP encapsulated packets. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1973 RFC1974 PPP Stac LZS Compression Protocol R. Friend W. Simpson August 1996 ASCII HTML 20 PPP-STAC Point-to-Point Protocol Compression Control CCP

This document describes the use of the Stac LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1974 RFC1975 PPP Magnalink Variable Resource Compression D. Schremp J. Black J. Weiss August 1996 ASCII HTML 6 PPP-MAG Point-to-Point Protocol MVRCA

The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1975 RFC1976 PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) K. Schneider S. Venters August 1996 ASCII HTML 10 PPP-DCE Point-to-Point Protocol LCP extension

This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-Terminating Equipment (DCE). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1976 RFC1977 PPP BSD Compression Protocol V. Schryver August 1996 ASCII HTML 25 PPP-BSD Point-to-Point Protocol Unix Compress

This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1977 RFC1978 PPP Predictor Compression Protocol D. Rand August 1996 ASCII HTML 9 PPP-PRED Point-to-Point Protocol

This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1978 RFC1979 PPP Deflate Protocol J. Woods August 1996 ASCII HTML 10 PPP-DEFL Point-to-Point Protocol Compression Control

This document describes the use of the PPP Deflate compression protocol for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=1979 10.17487/RFC1979 RFC1980 A Proposed Extension to HTML : Client-Side Image Maps J. Seidman August 1996 ASCII HTML 7 HyperText Markup Language Uniform Identifier URI

The markup language known as "HTML/2.0" provides for image maps. Image maps are document elements which allow clicking different areas of an image to reference different network resources, as specified by Uniform Identifier (URIs). The image map capability in HTML/2.0 is limited in several ways, such as the restriction that it only works with documents served via the "HTTP" protocol, and the lack of a viable fallback for users of text-only browsers. This document specifies an extension to the HTML language, referred to as "Client- Side Image Maps," which resolves these limitations.

 RFC2854 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1980 RFC1981 Path MTU Discovery for IP version 6 J. McCann S. Deering J. Mogul August 1996 ASCII HTML 15 MTU-IPV6 Internet Protocol

This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. [STANDARDS-TRACK]

 RFC8201 DRAFT STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=1981 10.17487/RFC1981 RFC1982 Serial Number Arithmetic R. Elz R. Bush August 1996 ASCII HTML 6 SNA domain name system DNS

The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035. [STANDARDS-TRACK]

 RFC1034 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC1982 RFC1983 Internet Users' Glossary G. Malkin Editor August 1996 ASCII HTML 62 basic terms acronyms

There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1392 FYI0018 INFORMATIONAL INFORMATIONAL IETF userglos 10.17487/RFC1983 RFC1984 IAB and IESG Statement on Cryptographic Technology and the Internet IAB IESG August 1996 ASCII HTML 5 security privacy

The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 BCP0200 BEST CURRENT PRACTICE INFORMATIONAL Legacy 10.17487/RFC1984 RFC1985 SMTP Service Extension for Remote Message Queue Starting J. De Winter August 1996 ASCII HTML 7 SMTP-ETRN Simple ETRN Mail Transfer Protocol

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1985 10.17487/RFC1985 RFC1986 Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP) W. Polites W. Wollman D. Woo R. Langan August 1996 ASCII HTML 21 ETFTP TFTP NETBLT

This document is a description of the Enhanced Trivial File Transfer Protocol (ETFTP). This protocol is an experimental implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file transfer application program. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1986 RFC1987 Ipsilon's General Switch Management Protocol Specification Version 1.1 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall August 1996 ASCII HTML 44 GSMP ATM switch

The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2297 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1987 RFC1988 Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework G. McAnally D. Gilbert J. Flick August 1996 ASCII HTML 2 HP

This grant is made to help facilitate inclusion of certain patented search address technology covering network device mapping in IETF standards-track Management Information Base (MIB) modules. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1988 RFC1989 PPP Link Quality Monitoring W. Simpson August 1996 ASCII HTML 16 PPP-LINK Point-to-Point Protocol

This document defines a protocol for generating Link-Quality-Reports. [STANDARDS-TRACK]

 RFC1333 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1989 RFC1990 The PPP Multilink Protocol (MP) K. Sklower B. Lloyd G. McGregor D. Carr T. Coradetti August 1996 ASCII HTML 24 PPP-MP Point-to-Point Protocol datagrams

This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]

 RFC1717 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1990 RFC1991 PGP Message Exchange Formats D. Atkins W. Stallings P. Zimmermann August 1996 ASCII HTML 21 PGP-MEF Pretty Good Privacy encryption electronic mail

This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed with PGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC4880 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1991 RFC1992 The Nimrod Routing Architecture I. Castineyra N. Chiappa M. Steenstrup August 1996 ASCII HTML 27 scalable internetwork

Nimrod is a scalable routing architecture designed to accommodate a continually expanding and diversifying internetwork. First suggested by Noel Chiappa, the Nimrod architecture has undergone revision and refinement through the efforts of the Nimrod working group of the IETF. In this document, we present a detailed description of this architecture. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF rtg nimrod 10.17487/RFC1992 RFC1993 PPP Gandalf FZA Compression Protocol A. Barbir D. Carr W. Simpson August 1996 ASCII HTML 7 Point-to-Point Protocol

This document describes the use of the Gandalf FZA data compression algorithm [3] for compressing PPP encapsulated packets. This memo provides information for the Internet community. It does not specify an Internet standard.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1993 RFC1994 PPP Challenge Handshake Authentication Protocol (CHAP) W. Simpson August 1996 ASCII HTML 13 PPP-CHAP Point-to-Point Protocol cryptology

This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key. [STANDARDS-TRACK]

 RFC1334 RFC2484 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1994 RFC1995 Incremental Zone Transfer in DNS M. Ohta August 1996 ASCII HTML 8 DNS-IZT Domain Name System IXFR

This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. [STANDARDS-TRACK]

 RFC1035 RFC9103 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=1995 10.17487/RFC1995 RFC1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) P. Vixie August 1996 ASCII HTML 7 DNS-NOTIFY Domain Name System

This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK]

 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC1996 RFC1997 BGP Communities Attribute R. Chandra P. Traina T. Li August 1996 ASCII HTML 5 BGP-COMM Border Gateway Protocol

This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. [STANDARDS-TRACK]

 RFC7606 RFC8642 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=1997 10.17487/RFC1997 RFC1998 An Application of the BGP Community Attribute in Multi-home Routing E. Chen T. Bates August 1996 ASCII HTML 9 Border Gateway Protocol

This document presents an application of the BGP community attribute [2] in simplifying the implementation and configuration of routing policies in the multi-provider Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1998 RFC1999 Request for Comments Summary RFC Numbers 1900-1999 J. Elliott January 1997 ASCII HTML 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1999 RFC2000 Internet Official Protocol Standards J. Postel Editor February 1997 ASCII HTML 56 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard.

 RFC1920 RFC2200 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2000 RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms W. Stevens January 1997 ASCII HTML 6 TCPSLOWSRT Transmission Control Protocol

Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery. [STANDARDS-TRACK]

 RFC2581 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2001 RFC2002 IP Mobility Support C. Perkins Editor October 1996 ASCII HTML 79 MOBILEIPSUPIP Internet Protocol

This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. [STANDARDS-TRACK]

 RFC3220 RFC2290 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2002 RFC2003 IP Encapsulation within IP C. Perkins October 1996 ASCII HTML 14 IPENCAPIP Internet Protocol

This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK]

 RFC3168 RFC6864 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=2003 10.17487/RFC2003 RFC2004 Minimal Encapsulation within IP C. Perkins October 1996 ASCII HTML 6 MINI-IP Internet Protocol

This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than "conventional" IP encapsulation that adds a second IP header to each encapsulated datagram. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=2004 10.17487/RFC2004 RFC2005 Applicability Statement for IP Mobility Support J. Solomon October 1996 ASCII HTML 5 Internet Protocol

As required by [RFC 1264], this report discusses the applicability of Mobile IP to provide host mobility in the Internet. In particular, this document describes the key features of Mobile IP and shows how the requirements for advancement to Proposed Standard RFC have been satisfied. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2005 RFC2006 The Definitions of Managed Objects for IP Mobility Support using SMIv2 D. Cong M. Hamlen C. Perkins October 1996 ASCII HTML 52 MOBILEIPMIB Mobile Internet Protocol MIB Managed Information Base

This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=2006 10.17487/RFC2006 RFC2007 Catalogue of Network Training Materials J. Foster M. Isaacs M. Prior October 1996 ASCII HTML 55 TRAINMAT IETF TERENA

The purpose of this document is to provide a catalogue of quality Network Training Materials for use by Internet trainers in training their users. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 FYI0029 INFORMATIONAL INFORMATIONAL IETF trainmat 10.17487/RFC2007 RFC2008 Implications of Various Address Allocation Policies for Internet Routing Y. Rekhter T. Li October 1996 ASCII HTML 13 IP unicast

The purpose of this document is to articulate certain relevant fundamental technical issues that must be considered in formulating unicast address allocation and management policies for the Public Internet, and to provide recommendations with respect to these policies. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0007 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF cidrd 10.17487/RFC2008 RFC2009 GPS-Based Addressing and Routing T. Imielinski J. Navas November 1996 ASCII HTML 27 GPS-AR domain names geographic

This document describes a possible experiment with geographic addresses. It uses several specific IP addresses and domain names in the discussion as concrete examples to aid in understanding the concepts. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2009 RFC2010 Operational Criteria for Root Name Servers B. Manning P. Vixie October 1996 ASCII HTML 7 host hardware

This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2870 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2010 RFC2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2 K. McCloghrie Editor November 1996 ASCII HTML 18 MIB-IP IP Simple Network Management Protocol MIB

This document is the MIB module which defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP). [STANDARDS-TRACK]

 RFC4293 RFC1213 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC2011 RFC2012 SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2 K. McCloghrie Editor November 1996 ASCII HTML 10 MIB-TCP TCP Simple Network Management Protocol MIB

This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). [STANDARDS-TRACK]

 RFC4022 RFC1213 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC2012 RFC2013 SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2 K. McCloghrie Editor November 1996 ASCII HTML 6 MIB-UDP Simple Network Management Protocol MIB UDP

This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). [STANDARDS-TRACK]

 RFC4113 RFC1213 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC2013 RFC2014 IRTF Research Group Guidelines and Procedures A. Weinrib J. Postel October 1996 ASCII HTML 13 Internet Research Task Force

This document describes the guidelines and procedures for formation and operation of IRTF Research Groups. It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group (IRSG) and the Internet Architecture Board (IAB). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0008 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2014 RFC2015 MIME Security with Pretty Good Privacy (PGP) M. Elkins October 1996 ASCII HTML 8 MIME-PGP Authentication Encryption

This document describes how Pretty Good Privacy (PGP) can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847. [STANDARDS-TRACK]

 RFC3156 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2015 10.17487/RFC2015 RFC2016 Uniform Resource Agents (URAs) L. Daigle P. Deutsch B. Heelan C. Alpaugh M. Maclachlan October 1996 ASCII HTML 21 URAS

This paper presents an experimental architecture for an agent system that provides sophisticated Internet information access and management. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2016 RFC2017 Definition of the URL MIME External-Body Access-Type N. Freed K. Moore A. Cargille October 1996 ASCII HTML 5 URL-ACC Uniform Resource Locators Multipurpose Internet Message Extensions

This memo defines a new access-type for message/external-body MIME parts for Uniform Resource Locators (URLs). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app mailext 10.17487/RFC2017 RFC2018 TCP Selective Acknowledgment Options M. Mathis J. Mahdavi S. Floyd A. Romanow October 1996 ASCII HTML 12 TCP-ACK Transmission Control Protocol SACK

This memo proposes an implementation of SACK and discusses its performance and related issues. [STANDARDS-TRACK]

 RFC1072 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcplw http://www.rfc-editor.org/errata_search.php?rfc=2018 10.17487/RFC2018 RFC2019 Transmission of IPv6 Packets Over FDDI M. Crawford October 1996 ASCII HTML 6 IPV6-FDDI frame format Fiber Distributed Data Interface

This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. [STANDARDS-TRACK]

 RFC2467 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2019 RFC2020 IEEE 802.12 Interface MIB J. Flick October 1996 ASCII HTML 31 802.12-MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network interfaces based on IEEE 802.12. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2020 RFC2021 Remote Network Monitoring Management Information Base Version 2 using SMIv2 S. Waldbusser January 1997 ASCII HTML 130 RMON-MIB RMON MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

 RFC4502 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib http://www.rfc-editor.org/errata_search.php?rfc=2021 10.17487/RFC2021 RFC2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks G. Armitage November 1996 ASCII HTML 82 MULTI-UNI Asynchronous Transfer Mode

This memo describes a mechanism to support the multicast needs of Layer 3 protocols in general, and describes its application to IP multicasting in particular. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC2022 RFC2023 IP Version 6 over PPP D. Haskin E. Allen October 1996 ASCII HTML 10 IPV6-PPP Internet Protocol Point IPv6

This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. [STANDARDS-TRACK]

 RFC2472 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2023 RFC2024 Definitions of Managed Objects for Data Link Switching using SMIv2 D. Chen Editor P. Gayek S. Nix October 1996 ASCII HTML 90 DLSW-MIB MIB DLSW Management Information Base

This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling Data Link Switches (DLSw). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg dlswmib 10.17487/RFC2024 RFC2025 The Simple Public-Key GSS-API Mechanism (SPKM) C. Adams October 1996 ASCII HTML 45 SPKM

This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using the Simple Public-Key Mechanism. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2025 RFC2026 The Internet Standards Process -- Revision 3 S. Bradner October 1996 ASCII HTML 36 Protocols copyrights intellectual property

This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC1602 RFC1871 RFC3667 RFC3668 RFC3932 RFC3978 RFC3979 RFC5378 RFC5657 RFC5742 RFC6410 RFC7100 RFC7127 RFC7475 RFC8179 RFC8789 RFC9282 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen poised95 http://www.rfc-editor.org/errata_search.php?rfc=2026 10.17487/RFC2026 RFC2027 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin October 1996 ASCII HTML 11 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled has been exercised four times since its formal creation. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self-consistent, organized compilation of the process as it is known today. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC2282 INFORMATIONAL BEST CURRENT PRACTICE IETF gen poised95 10.17487/RFC2027 RFC2028 The Organizations Involved in the IETF Standards Process R. Hovey S. Bradner October 1996 ASCII HTML 7 Internet Engineering Task Force

This document describes the individuals and organizations involved in the IETF. This includes descriptions of the IESG, the IETF Working Groups and the relationship between the IETF and the Internet Society. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC9281 RFC3668 RFC3979 RFC8717 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen poised95 http://www.rfc-editor.org/errata_search.php?rfc=2028 10.17487/RFC2028 RFC2029 RTP Payload Format of Sun's CellB Video Encoding M. Speer D. Hoffman October 1996 ASCII HTML 6 RTP-CELLB Real Time Transport Protocol

This memo describes a packetization scheme for the CellB video encoding. The scheme proposed allows applications to transport CellB video flows over protocols used by RTP. This document is meant for implementors of video applications that want to use RTP and CellB. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2029 RFC2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI D. Mills October 1996 ASCII HTML 18 NTP SNTP time computer clock synchronization

This memorandum describes the Simple Network Time Protocol (SNTP) Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1769 RFC4330 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2030 10.17487/RFC2030 RFC2031 IETF-ISOC relationship E. Huizer October 1996 ASCII HTML 4 Internet Society Engineering Task Force

This memo summarises the issues on IETF - ISOC relationships as the have been discussed by the Poised Working Group. The purpose of the document is to gauge consensus on these issues. And to allow further discussions where necessary. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC8712 INFORMATIONAL INFORMATIONAL IETF gen poised95 10.17487/RFC2031 RFC2032 RTP Payload Format for H.261 Video Streams T. Turletti C. Huitema October 1996 ASCII HTML 11 RTP-H.261 Real Time Transport Protocol

This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. [STANDARDS-TRACK]

 RFC4587 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2032 RFC2033 Local Mail Transfer Protocol J. Myers October 1996 ASCII HTML 7 LMTP SMTP Simple Mail Transfer Protocol

SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the SMTP protocol effectively requires the server to manage a mail delivery queue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2033 RFC2034 SMTP Service Extension for Returning Enhanced Error Codes N. Freed October 1996 ASCII HTML 6 SMTP-ENH Simple Mail Transfer Protocol

This memo defines an extension to the SMTP service [RFC-821, RFC-1869] whereby an SMTP server augments its responses with the enhanced mail system status codes defined in RFC 1893. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2034 RFC2035 RTP Payload Format for JPEG-compressed Video L. Berc W. Fenner R. Frederick S. McCanne October 1996 ASCII HTML 16 RTP-JPEG Real Time Transport Protocol Joint Photographic Experts Group

This memo describes the RTP payload format for JPEG video streams. The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame. [STANDARDS-TRACK]

 RFC2435 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2035 RFC2036 Observations on the use of Components of the Class A Address Space within the Internet G. Huston October 1996 ASCII HTML 9 Internet Assigned Numbers Authority IANA

This document is a commentary on the recommendation that IANA commence allocation of the presently unallocated components of the Class A address space to registries, for deployment within the Internet as class-less address blocks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 HISTORIC INFORMATIONAL IETF cidrd 10.17487/RFC2036 RFC2037 Entity MIB using SMIv2 K. McCloghrie A. Bierman October 1996 ASCII HTML 35 ENTITY-MIB Management Information Base SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]

 RFC2737 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib 10.17487/RFC2037 RFC2038 RTP Payload Format for MPEG1/MPEG2 Video D. Hoffman G. Fernando V. Goyal October 1996 ASCII HTML 11 Real Time Transport Protocol

This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. [STANDARDS-TRACK]

 RFC2250 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2038 RFC2039 Applicability of Standards Track MIBs to Management of World Wide Web Servers C. Kalbfleisch November 1996 ASCII HTML 14 Management Information Base HTTP

This document was produced at the request of the Network Management Area Director following the HTTP-MIB BOF at the 35th IETF meeting to report on the applicability of the existing standards track MIBs to management of WWW servers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2039 RFC2040 The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms R. Baldwin R. Rivest October 1996 ASCII HTML 29 RC5 Cipher Block Chaining CBC

This document defines four ciphers with enough detail to ensure interoperability between different implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2040 10.17487/RFC2040 RFC2041 Mobile Network Tracing B. Noble G. Nguyen M. Satyanarayanan R. Katz October 1996 ASCII HTML 27 IP Internet Protocol

This RFC argues that mobile network tracing provides both tools to improve our understanding of wireless channels, as well as to build realistic, repeatable testbeds for mobile software and systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2041 RFC2042 Registering New BGP Attribute Types B. Manning January 1997 ASCII HTML 3 Border Gateway Protocol

This document describes the process for creating new BGP attribute type codes. Basic attribute type codes are described in RFC 1771, pages 12 through 15. These, and new attribute type codes that are used in the Internet are registered with the IANA. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2042 10.17487/RFC2042 RFC2043 The PPP SNA Control Protocol (SNACP) A. Fuqua October 1996 ASCII HTML 7 PPP-SNACP Point-to-point protocol systems network architecture

This document defines the Network Control Protocols for establishing and configuring Systems Network Architecture (SNA) over PPP and SNA over LLC 802.2 over PPP. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2043 RFC2044 UTF-8, a transformation format of Unicode and ISO 10646 F. Yergeau October 1996 ASCII HTML 6 UCS Transformation Format

The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2279 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2044 RFC2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies N. Freed N. Borenstein November 1996 ASCII HTML 31 MIME media types headers

This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]

 RFC1521 RFC1522 RFC1590 RFC2184 RFC2231 RFC5335 RFC6532 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2045 10.17487/RFC2045 RFC2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types N. Freed N. Borenstein November 1996 ASCII HTML 44 MIME-MEDIA headers structure

This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]

 RFC1521 RFC1522 RFC1590 RFC2646 RFC3798 RFC5147 RFC6657 RFC8098 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2046 10.17487/RFC2046 RFC2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text K. Moore November 1996 ASCII HTML 15 MIME-MSG media type

This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. [STANDARDS-TRACK]

 RFC1521 RFC1522 RFC1590 RFC2184 RFC2231 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2047 10.17487/RFC2047 RFC2048 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures N. Freed J. Klensin J. Postel November 1996 ASCII HTML 21 media types external body access content-transfer-encodings

This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fourth document, RFC 2048, specifies various IANA registration procedures for some MIME facilities. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC1521 RFC1522 RFC1590 RFC4288 RFC4289 RFC3023 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app 822ext 10.17487/RFC2048 RFC2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples N. Freed N. Borenstein November 1996 ASCII HTML 24 MIME-CONF media type message formats

This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fifth and final document describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. [STANDARDS-TRACK]

 RFC1521 RFC1522 RFC1590 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2049 10.17487/RFC2049 RFC2050 Internet Registry IP Allocation Guidelines K. Hubbard M. Kosters D. Conrad D. Karrenberg J. Postel November 1996 ASCII HTML 13 Internet Addresses Network Numbers

This document describes the registry system for the distribution of globally unique Internet address space and registry operations. Particularly this document describes the rules and guidelines governing the distribution of this address space. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC1466 RFC7020 HISTORIC BEST CURRENT PRACTICE Legacy 10.17487/RFC2050 RFC2051 Definitions of Managed Objects for APPC using SMIv2 M. Allen B. Clouston Z. Kielczewski W. Kwan B. Moore October 1996 ASCII HTML 124 SNANAU-APP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and controlling of network devices with APPC (Advanced Program-to-Program Communications) capabilities. This memo identifies managed objects for the SNA LU6.2 protocols. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2051 RFC2052 A DNS RR for specifying the location of services (DNS SRV) A. Gulbrandsen P. Vixie October 1996 ASCII HTML 10 DNS-SRV Domain Name System

This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX). This memo defines an Experimental Protocol for the Internet community.

 RFC2782 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2052 RFC2053 The AM (Armenia) Domain E. Der-Danieliantz October 1996 ASCII HTML 3 Top Level Domain Country Code

The AM Domain is an official Internet top-level domain of Armenia. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2053 RFC2054 WebNFS Client Specification B. Callaghan October 1996 ASCII HTML 16 Network Fil System

This document describes a lightweight binding mechanism that allows NFS clients to obtain service from WebNFS-enabled servers with a minimum of protocol overhead. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2054 RFC2055 WebNFS Server Specification B. Callaghan October 1996 ASCII HTML 10 Network Fil System

This document describes the specifications for a server of WebNFS clients. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2055 RFC2056 Uniform Resource Locators for Z39.50 R. Denenberg J. Kunze D. Lynch November 1996 ASCII HTML 7 URLZ39.50 URL information retrieval

Z39.50 is an information retrieval protocol that does not fit neatly into a retrieval model designed primarily around the stateless fetch of data. Instead, it models a general user inquiry as a session-oriented, multi-step task, any step of which may be suspended temporarily while the server requests additional parameters from the client before continuing. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2056 RFC2057 Source Directed Access Control on the Internet S. Bradner November 1996 ASCII HTML 20 content regulation deposition

This memo was developed from a deposition that I submitted as part of a challenge to the Communications Decency Act of 1996, part of the Telecommunications Reform Act of 1996. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2057 RFC2058 Remote Authentication Dial In User Service (RADIUS) C. Rigney A. Rubens W. Simpson S. Willens January 1997 ASCII HTML 64 encryption NAS Network Access Server

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]

 RFC2138 PROPOSED STANDARD PROPOSED STANDARD IETF ops nasreq 10.17487/RFC2058 RFC2059 RADIUS Accounting C. Rigney January 1997 ASCII HTML 25 remote authentication dial in user service encryption

This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2139 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2059 RFC2060 Internet Message Access Protocol - Version 4rev1 M. Crispin December 1996 ASCII HTML 82 IMAPV4 IMAP electronic mail Internet Message Access Protocol

The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. [STANDARDS-TRACK]

 RFC1730 RFC3501 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2060 10.17487/RFC2060 RFC2061 IMAP4 Compatibility with IMAP2bis M. Crispin December 1996 ASCII HTML 3 IMAP electronic mail Internet Message Access Protocol

This document is intended to be read along with RFC 1176 and the most recent IMAP4 specification (RFC 2060) to assist implementors in creating an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1730 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2061 RFC2062 Internet Message Access Protocol - Obsolete Syntax M. Crispin December 1996 ASCII HTML 8 IMAP electronic mail

This document describes obsolete syntax which may be encountered by IMAP4 implementations which deal with older versions of the Internet Mail Access Protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2062 RFC2063 Traffic Flow Measurement: Architecture N. Brownlee C. Mills G. Ruth January 1997 ASCII HTML 37 TFM-ARCH network data

This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet. This memo defines an Experimental Protocol for the Internet community.

 RFC2722 EXPERIMENTAL EXPERIMENTAL IETF tsv rtfm 10.17487/RFC2063 RFC2064 Traffic Flow Measurement: Meter MIB N. Brownlee January 1997 ASCII HTML 38 METER-MIB Management Information Base Network Data

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for obtaining traffic flow information from network traffic meters. This memo defines an Experimental Protocol for the Internet community.

 RFC2720 EXPERIMENTAL EXPERIMENTAL IETF tsv rtfm 10.17487/RFC2064 RFC2065 Domain Name System Security Extensions D. Eastlake 3rd C. Kaufman January 1997 ASCII HTML 41 DNS-SEC DNS authentication encryption

The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. [STANDARDS-TRACK]

 RFC2535 RFC1034 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2065 RFC2066 TELNET CHARSET Option R. Gellens January 1997 ASCII HTML 12 TOPT-CHARSET character set application

This document specifies a mechanism for passing character set and translation information between a TELNET client and server. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2066 RFC2067 IP over HIPPI J. Renwick January 1997 ASCII HTML 30 IP-HIPPI ANSI High-Performance Parallel Interface Internet Protocol

ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. This memo is a revision of RFC 1374, "IP and ARP on HIPPI", and is intended to replace it in the Standards Track. [STANDARDS-TRACK]

 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2067 RFC2068 Hypertext Transfer Protocol -- HTTP/1.1 R. Fielding J. Gettys J. Mogul H. Frystyk T. Berners-Lee January 1997 ASCII HTML 162 HTTP-1.1 World Wide Web WWW hypermedia

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK]

 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app http 10.17487/RFC2068 RFC2069 An Extension to HTTP : Digest Access Authentication J. Franks P. Hallam-Baker J. Hostetler P. Leach A. Luotonen E. Sink L. Stewart January 1997 ASCII HTML 18 DAA Hypertext Transfer Protocol

The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text. A specification for a different authentication scheme is needed to address this severe limitation. This document provides specification for such a scheme, referred to as "Digest Access Authentication". [STANDARDS-TRACK]

 RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2069 10.17487/RFC2069 RFC2070 Internationalization of the Hypertext Markup Language F. Yergeau G. Nicol G. Adams M. Duerst January 1997 ASCII HTML 43 HTML-INT HTML WWW World Wide Web

This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. [STANDARDS-TRACK]

 RFC2854 HISTORIC PROPOSED STANDARD IETF app html 10.17487/RFC2070 RFC2071 Network Renumbering Overview: Why would I want it and what is it anyway? P. Ferguson H. Berkowitz January 1997 ASCII HTML 14 Internet Enterprise Connecting Routers

This document attempts to clearly define the concept of network renumbering and discuss some of the more pertinent reasons why an organization would have a need to do so. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF ops pier 10.17487/RFC2071 RFC2072 Router Renumbering Guide H. Berkowitz January 1997 ASCII HTML 48 Internet Enterprise Connecting Routers

Routers interact with numerous network infrastructure servers, including DNS and SNMP. These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC4192 INFORMATIONAL INFORMATIONAL IETF ops pier 10.17487/RFC2072 RFC2073 An IPv6 Provider-Based Unicast Address Format Y. Rekhter P. Lothberg R. Hinden S. Deering J. Postel January 1997 ASCII HTML 7 IPV6-UNI

This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK]

 RFC2374 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2073 RFC2074 Remote Network Monitoring MIB Protocol Identifiers A. Bierman R. Iddon January 1997 ASCII HTML 43 RMON-MIB RMON Management Information Base

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. [STANDARDS-TRACK]

 RFC2895 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC2074 RFC2075 IP Echo Host Service C. Partridge January 1997 ASCII HTML 5 IP-Echo Internet Protocol datagram

This memo describes how to implement an IP echo host. IP echo hosts send back IP datagrams after exchanging the source and destination IP addresses. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2075 RFC2076 Common Internet Message Headers J. Palme February 1997 ASCII HTML 27 email

This memo contains a table of commonly occurring headers in headings of e-mail messages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app mailext http://www.rfc-editor.org/errata_search.php?rfc=2076 10.17487/RFC2076 RFC2077 The Model Primary Content Type for Multipurpose Internet Mail Extensions S. Nelson C. Parks Mitra January 1997 ASCII HTML 13 MIME-MODEL MIME Media Type Content Type

The purpose of this memo is to propose an update to Internet RFC 2045 to include a new primary content-type to be known as "model". [STANDARDS-TRACK]

 RFC9141 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2077 RFC2078 Generic Security Service Application Program Interface, Version 2 J. Linn January 1997 ASCII HTML 85 GSSAP Authentication Cryptology Data integrity

The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK]

 RFC1508 RFC2743 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2078 RFC2079 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) M. Smith January 1997 ASCII HTML 5 URI-ATT URL Universal Resource Locators Directory

This document builds on the experimentation to date and defines a new attribute type and an auxiliary object class to allow URIs, including URLs, to be stored in directory entries in a standard way. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2079 RFC2080 RIPng for IPv6 G. Malkin R. Minnear January 1997 ASCII HTML 19 RIPNG-IPV6 Routing Information Protocol Internet

This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in the IPv4 Internet [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rip 10.17487/RFC2080 RFC2081 RIPng Protocol Applicability Statement G. Malkin January 1997 ASCII HTML 4 Routing Information Protocol Internet

As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIPng protocol within the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg rip 10.17487/RFC2081 RFC2082 RIP-2 MD5 Authentication F. Baker R. Atkinson January 1997 ASCII HTML 12 RIP2-MD5 Routing Information Protocol Encryption

Growth in the Internet has made us aware of the need for improved authentication of routing information. RIP-2 provides for unauthenticated service (as in classical RIP), or password authentication. [STANDARDS-TRACK]

 RFC4822 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ripv2 10.17487/RFC2082 RFC2083 PNG (Portable Network Graphics) Specification Version 1.0 T. Boutell March 1997 ASCII HTML 102 PNG file format bitmap

This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2083 RFC2084 Considerations for Web Transaction Security G. Bossert S. Cooper W. Drummond January 1997 ASCII HTML 6 authentication encryption World Wide Web WWW

This document specifies the requirements for the provision of security services to the HyperText Transport Protocol. These services include confidentiality, integrity, user authentication, and authentication of servers/services, including proxied or gatewayed services. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF sec wts 10.17487/RFC2084 RFC2085 HMAC-MD5 IP Authentication with Replay Prevention M. Oehler R. Glenn February 1997 ASCII HTML 6 HMAC-MD5 ipsec Message Digest Security Internet Protocol Encryption

This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2085 RFC2086 IMAP4 ACL extension J. Myers January 1997 ASCII HTML 8 IMAP4-ACL Internet Message Access Protocol Control List

The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK]

 RFC4314 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2086 RFC2087 IMAP4 QUOTA extension J. Myers January 1997 ASCII HTML 5 IMAP4-QUO Internet Message Access Protocol

The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. [STANDARDS-TRACK]

 RFC9208 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2087 RFC2088 IMAP4 non-synchronizing literals J. Myers January 1997 ASCII HTML 2 IMAP4-LIT Internet Message Access Protocol

The Internet Message Access Protocol [STANDARDS-TRACK]

 RFC7888 RFC4466 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2088 RFC2089 V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent B. Wijnen D. Levi January 1997 ASCII HTML 12

The goal of this memo is to document a common way of mapping an SNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2576 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2089 RFC2090 TFTP Multicast Option A. Emberson February 1997 ASCII HTML 6 TFTP-MULTI Trivial File Transfer Protocol

This document describes a new TFTP option. This new option will allow the multiple clients to receive the same file concurrently through the use of Multicast packets. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2090 RFC2091 Triggered Extensions to RIP to Support Demand Circuits G. Meyer S. Sherry January 1997 ASCII HTML 22 RIP-TRIG

This document defines a modification which can be applied to Bellman- Ford (distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rip 10.17487/RFC2091 RFC2092 Protocol Analysis for Triggered RIP S. Sherry G. Meyer January 1997 ASCII HTML 6

As required by Routing Protocol Criteria [1], this report documents the key features of Triggered Extensions to RIP to Support Demand Circuits [2] and the current implementation experience. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg rip http://www.rfc-editor.org/errata_search.php?rfc=2092 10.17487/RFC2092 RFC2093 Group Key Management Protocol (GKMP) Specification H. Harney C. Muckenhirn July 1997 ASCII HTML 23 GKMP-SPEC

This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2093 RFC2094 Group Key Management Protocol (GKMP) Architecture H. Harney C. Muckenhirn July 1997 ASCII HTML 22 GKMP-ARCH

This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2094 RFC2095 IMAP/POP AUTHorize Extension for Simple Challenge/Response J. Klensin R. Catoe P. Krumviede January 1997 ASCII HTML 5 Post Office Protocol Internet Message Access

This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]

 RFC2195 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2095 RFC2096 IP Forwarding Table MIB F. Baker January 1997 ASCII HTML 21 TABLE-MIB Management Information Base Internet Protocol

This memo defines an update to RFC 1354. The significant difference between this MIB and RFC 1354 is the recognition (explicitly discussed but by consensus left to future work) that CIDR routes may have the same network number but different network masks. [STANDARDS-TRACK]

 RFC1354 RFC4292 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC2096 RFC2097 The PPP NetBIOS Frames Control Protocol (NBFCP) G. Pall January 1997 ASCII HTML 13 PPP-NBFCP Point-to-Point Protocol

This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP. The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2097 RFC2098 Toshiba's Router Architecture Extensions for ATM : Overview Y. Katsube K. Nagami H. Esaki February 1997 ASCII HTML 18 Asynchronis Transfer Mode datagram IP Internet Protocol

This memo describes a new internetworking architecture which makes better use of the property of ATM. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2098 RFC2099 Request for Comments Summary RFC Numbers 2000-2099 J. Elliott March 1997 ASCII HTML 21 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2099 RFC2100 The Naming of Hosts J. Ashworth April 1 1997 ASCII HTML 3 April Fool's

This RFC is a commentary on the difficulty of deciding upon an acceptably distinctive hostname for one's computer, a problem which grows in direct proportion to the logarithmically increasing size of the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2100 10.17487/RFC2100 RFC2101 IPv4 Address Behaviour Today B. Carpenter J. Crowcroft Y. Rekhter February 1997 ASCII HTML 13 Internet Protocol Internet Architecture Board

The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2101 RFC2102 Multicast Support for Nimrod : Requirements and Solution Approaches R. Ramanathan February 1997 ASCII HTML 23 scalable routing architecture

Nimrod does not specify a particular solution for multicasting. Rather, Nimrod may use any of a number of emerging multicast techniques. We identify the requirements that Nimrod has of a solution for multicast support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg nimrod 10.17487/RFC2102 RFC2103 Mobility Support for Nimrod : Challenges and Solution Approaches R. Ramanathan February 1997 ASCII HTML 17 IP Internet Protocol routing addressing

We discuss the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. We identify the requirements that Nimrod has of any solution for mobility support. We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg nimrod 10.17487/RFC2103 RFC2104 HMAC: Keyed-Hashing for Message Authentication H. Krawczyk M. Bellare R. Canetti February 1997 ASCII HTML 11 ipsec Message Digest Internet Protocol Security encryption

This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind

 RFC6151 INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2104 10.17487/RFC2104 RFC2105 Cisco Systems' Tag Switching Architecture Overview Y. Rekhter B. Davie D. Katz E. Rosen G. Swallow February 1997 ASCII HTML 13 network layer packet ATM switches

This document provides an overview of a novel approach to network layer packet forwarding, called tag switching. The two main components of the tag switching architecture - forwarding and control - are described. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2105 RFC2106 Data Link Switching Remote Access Protocol S. Chiang J. Lee H. Yasuda February 1997 ASCII HTML 19 DLSRAP NetBios DLSW

This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2114 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2106 RFC2107 Ascend Tunnel Management Protocol - ATMP K. Hamzeh February 1997 ASCII HTML 21 RADIUS authentication

This document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2107 RFC2108 Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 K. de Graaf D. Romascanu D. McMaster K. McCloghrie February 1997 ASCII HTML 82 802.3-MIB MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 10 and 100 Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10 &

 RFC1516 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2108 RFC2109 HTTP State Management Mechanism D. Kristol L. Montulli February 1997 ASCII HTML 21 HTTP-STATE Hypertext Transfer Protocol cookie

This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. [STANDARDS-TRACK]

 RFC2965 HISTORIC PROPOSED STANDARD IETF app http 10.17487/RFC2109 RFC2110 MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) J. Palme A. Hopmann March 1997 ASCII HTML 19 MHTML Hyper Text Markup Language Multipurpose Internet Mail Extensions

This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. [STANDARDS-TRACK]

 RFC2557 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml 10.17487/RFC2110 RFC2111 Content-ID and Message-ID Uniform Resource Locators E. Levinson March 1997 ASCII HTML 5 Hyper Text Markup Language URL MIME

The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK]

 RFC2392 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml 10.17487/RFC2111 RFC2112 The MIME Multipart/Related Content-type E. Levinson March 1997 ASCII HTML 9 Hyper Text Markup Language Multipurpose Internet Mail Extensions

The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]

 RFC1872 RFC2387 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml 10.17487/RFC2112 RFC2113 IP Router Alert Option D. Katz February 1997 ASCII HTML 4 ROUT-ALERT

This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. [STANDARDS-TRACK]

 RFC5350 RFC6398 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2113 RFC2114 Data Link Switching Client Access Protocol S. Chiang J. Lee H. Yasuda February 1997 ASCII HTML 22 DLSCAP

This memo describes the Data Link Switching Client Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2106 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2114 RFC2115 Management Information Base for Frame Relay DTEs Using SMIv2 C. Brown F. Baker September 1997 ASCII HTML 32 FRAME-MIB MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, it defines objects for managing Frame Relay interfaces on DTEs. [STANDARDS-TRACK]

 RFC1315 DRAFT STANDARD DRAFT STANDARD IETF int ion 10.17487/RFC2115 RFC2116 X.500 Implementations Catalog-96 C. Apple K. Rossen April 1997 ASCII HTML 164 Directory Services DSA DUA Agent Interfaces

This document is a revision to [RFC 1632]: A Revised Catalog of Available X.500 Implementations and is based on the results of data collection via a WWW home page that enabled implementors to submit new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. [RFC 1632] is a revision of [RFC 1292]. This document contains detailed description of 31 X.500 implementations - DSAs, DUAs, and DUA interfaces. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1632 FYI0011 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2116 RFC2117 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification D. Estrin D. Farinacci A. Helmy D. Thaler S. Deering M. Handley V. Jacobson C. Liu P. Sharma L. Wei June 1997 ASCII HTML 66

This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community.

 RFC2362 EXPERIMENTAL EXPERIMENTAL IETF rtg idmr 10.17487/RFC2117 RFC2118 Microsoft Point-To-Point Compression (MPPC) Protocol G. Pall March 1997 ASCII HTML 9 Point-to-Point Protocol PPP

This document describes the use of the Microsoft Point to Point Compression protocol (also referred to as MPPC in this document) for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2118 RFC2119 Key words for use in RFCs to Indicate Requirement Levels S. Bradner March 1997 ASCII HTML 3 Standards Track Documents

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-bradner-key-words-03 RFC8174 BCP0014 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2119 10.17487/RFC2119 RFC2120 Managing the X.500 Root Naming Context D. Chadwick March 1997 ASCII HTML 14 X.500-NAME ISO International Standards Organization

This document describes the use of 1993 ISO X.500 Standard protocols for managing the root context. Whilst the ASN.1 is compatible with that of the X.500 Standard, the actual settings of the parameters are supplementary to that of the X.500 Standard. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app ids 10.17487/RFC2120 RFC2121 Issues affecting MARS Cluster Size G. Armitage March 1997 ASCII HTML 12 ATM Asynchronous Transfer Mode Multicast IP Internet Protocol

This document provides a qualitative look at the issues constraining a MARS Cluster's size, including the impact of VC limits in switches and NICs, geographical distribution of cluster members, and the use of VC Mesh or MCS modes to support multicast groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2121 RFC2122 VEMMI URL Specification D. Mavrakis H. Layec K. Kartmann March 1997 ASCII HTML 11 VEMMI-URL Uniform Resource Locator Enhanced Man-Machine Interface Videotex

A new URL scheme, "vemmi" is defined. VEMMI is a new international standard for on-line multimedia services, that is both an ITU-T (International Telecommunications Union, ex. CCITT) International Standard (T.107) and an European Standard (ETSI European Telecommunications Standard Institute) standard (ETS 300 382, obsoleted by ETS 300 709). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2122 RFC2123 Traffic Flow Measurement: Experiences with NeTraMet N. Brownlee March 1997 ASCII HTML 34 Meter Reader Network

This memo records experiences in implementing and using the Traffic Flow Measurement Architecture and Meter MIB. It discusses the implementation of NeTraMet (a traffic meter) and NeMaC (a combined manager and meter reader), considers the writing of meter rule sets and gives some guidance on setting up a traffic flow measurement system using NeTraMet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2123 RFC2124 Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0 P. Amsden J. Amweg P. Calato S. Bensley G. Lyons March 1997 ASCII HTML 21 LFAP

This document specifies the protocol between the switch Connection Control Entity (CCE) and the external FAS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2124 RFC2125 The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP) C. Richards K. Smith March 1997 ASCII HTML 24 BAP-BACP Point-to-Point datagram multilink

This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol. This is done by defining the Bandwidth Allocation Protocol (BAP), as well as its associated control protocol, the Bandwidth Allocation Control Protocol (BACP). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2125 RFC2126 ISO Transport Service on top of TCP (ITOT) Y. Pouffary A. Young March 1997 ASCII HTML 25 ITOT International Standards Organization Transmission Control Protocol

This document is a revision to STD35, RFC1006. This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006. [STANDARDS-TRACK]

 RFC1006 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2126 10.17487/RFC2126 RFC2127 ISDN Management Information Base using SMIv2 G. Roeck Editor March 1997 ASCII HTML 49 ISDN-MIB MIB ISDN Integrated Services Digital Network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a minimal set of managed objects for SNMP-based management of ISDN terminal interfaces. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int isdnmib http://www.rfc-editor.org/errata_search.php?rfc=2127 10.17487/RFC2127 RFC2128 Dial Control Management Information Base using SMIv2 G. Roeck Editor March 1997 ASCII HTML 34 DC-MIB MIB ISDN Integrated Services Digital Network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing demand access circuits, including ISDN. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int isdnmib 10.17487/RFC2128 RFC2129 Toshiba's Flow Attribute Notification Protocol (FANP) Specification K. Nagami Y. Katsube Y. Shobatake A. Mogi S. Matsuzawa T. Jinmei H. Esaki April 1997 ASCII HTML 19 packet flow datalink mapping

This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2129 RFC2130 The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996 C. Weider C. Preston K. Simonsen H. Alvestrand R. Atkinson M. Crispin P. Svanberg April 1997 ASCII HTML 31 Internet Architecture Board interoperability

This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to the IAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC6055 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2130 RFC2131 Dynamic Host Configuration Protocol R. Droms March 1997 ASCII HTML 45 DHCP DHCPv4

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]

 RFC1541 RFC3396 RFC4361 RFC5494 RFC6842 DRAFT STANDARD DRAFT STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2131 10.17487/RFC2131 RFC2132 DHCP Options and BOOTP Vendor Extensions S. Alexander R. Droms March 1997 ASCII HTML 34 DHCP-BOOTP Dynamic Host Configuration Protocol Bootstrap

This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK]

 RFC1533 RFC3442 RFC3942 RFC4361 RFC4833 RFC5494 DRAFT STANDARD DRAFT STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2132 10.17487/RFC2132 RFC2133 Basic Socket Interface Extensions for IPv6 R. Gilligan S. Thomson J. Bound W. Stevens April 1997 ASCII HTML 32 application program interface API Internet Protocol addresses

This memo defines a set of extensions to the socket interface to support the larger address size and new features of IPv6. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2553 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2133 RFC2134 Articles of Incorporation of Internet Society ISOC Board of Trustees April 1997 ASCII HTML 5 ISOC

These are the articles of incorporation of the Internet Society. They are published for the information of the IETF community at the request of the poisson working group. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2134 RFC2135 Internet Society By-Laws ISOC Board of Trustees April 1997 ASCII HTML 9 ISOC

These are the by-laws of the Internet Society, as amended, as of June 1996. They are published for the information of the IETF community at the request of the poisson working group. Please refer to the ISOC web page (www.isoc.org) for the current version of the by-laws. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2135 RFC2136 Dynamic Updates in the Domain Name System (DNS UPDATE) P. Vixie Editor S. Thomson Y. Rekhter J. Bound April 1997 ASCII HTML 26 DNS-UPDATE database opcode zone

Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK]

 RFC1035 RFC3007 RFC4035 RFC4033 RFC4034 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2136 10.17487/RFC2136 RFC2137 Secure Domain Name System Dynamic Update D. Eastlake 3rd April 1997 ASCII HTML 11 SDNSDU DNS digital signatures cryptographic

This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. [STANDARDS-TRACK]

 RFC3007 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2137 RFC2138 Remote Authentication Dial In User Service (RADIUS) C. Rigney A. Rubens W. Simpson S. Willens April 1997 ASCII HTML 65 RADIUS encryption NAS Network Access Server

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]

 RFC2058 RFC2865 PROPOSED STANDARD PROPOSED STANDARD IETF ops radius 10.17487/RFC2138 RFC2139 RADIUS Accounting C. Rigney April 1997 ASCII HTML 25 RADIUS-ACC remote authentication dial in user service encryption

This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC2059 RFC2866 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2139 RFC2140 TCP Control Block Interdependence J. Touch April 1997 ASCII HTML 11

This memo makes the case for interdependent TCP control blocks, where part of the TCP state is shared among similar concurrent connections, or across similar connection instances. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC9040 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2140 RFC2141 URN Syntax R. Moats May 1997 ASCII HTML 8 URN-SYNTAX Uniform Resource Names

Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. [STANDARDS-TRACK]

 RFC8141 PROPOSED STANDARD PROPOSED STANDARD IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=2141 10.17487/RFC2141 RFC2142 Mailbox Names for Common Services, Roles and Functions D. Crocker May 1997 ASCII HTML 6 MAIL-SERV email internet addresses

This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2142 10.17487/RFC2142 RFC2143 Encapsulating IP with the Small Computer System Interface B. Elliston May 1997 ASCII HTML 5 IP-SCSI SCSI

This document outlines a protocol for connecting hosts running the TCP/IP protocol suite over a Small Computer System Interface (SCSI) bus. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2143 RFC2144 The CAST-128 Encryption Algorithm C. Adams May 1997 ASCII HTML 15 CAST-128

There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols. This document describes an existing algorithm that can be used to satisfy this requirement. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2144 RFC2145 Use and Interpretation of HTTP Version Numbers J. C. Mogul R. Fielding J. Gettys H. Frystyk May 1997 ASCII HTML 7

HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC7230 INFORMATIONAL INFORMATIONAL IETF app http 10.17487/RFC2145 RFC2146 U.S. Government Internet Domain Names Federal Networking Council May 1997 ASCII HTML 12 Gov FED.US

This memo provides an update and clarification to RFC 1816. This document describes the registration policies for the top-level domain ".GOV". The purpose of the domain is to provide naming conventions that identify US Federal government agencies in order to facilitate access to their electronic resources. This memo provides guidance for registrations by Federal Agencies that avoids name duplication and facilitates responsiveness to the public. It restricts registrations to coincide with the approved structure of the US government and the advice of its Chief Information Officers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1816 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2146 RFC2147 TCP and UDP over IPv6 Jumbograms D. Borman May 1997 ASCII HTML 3 IPv6-Jumbo User Datagram Protocol Terminal Control Internet

IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. [STANDARDS-TRACK]

 RFC2675 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2147 RFC2148 Deployment of the Internet White Pages Service H. Alvestrand P. Jurg September 1997 ASCII HTML 15 X. 500 data structure naming scheme IWPS

This document describes the way in which the Internet White Pages Service is best exploited using today's experience, today's protocols, today's products and today's procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0015 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ids 10.17487/RFC2148 RFC2149 Multicast Server Architectures for MARS-based ATM multicasting R. Talpade M. Ammar May 1997 ASCII HTML 18

This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined in RFC 2022. It also provides a mechanism for using multiple MCSs per group for providing fault tolerance. This approach can be used with RFC 2022 based MARS server and clients, without needing any change in their functionality. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2149 RFC2150 Humanities and Arts: Sharing Center Stage on the Internet J. Max W. Stickle October 1997 ASCII HTML 62 informational infrastructure guide introduction

The purpose of this document is to provide members of the Arts and Humanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 FYI0031 INFORMATIONAL INFORMATIONAL IETF harts 10.17487/RFC2150 RFC2151 A Primer On Internet and TCP/IP Tools and Utilities G. Kessler S. Shepard June 1997 ASCII HTML 52 resource guide user

This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtain Internet and TCP/IP documents, and some resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1739 FYI0030 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2151 RFC2152 UTF-7 A Mail-Safe Transformation Format of Unicode D. Goldsmith M. Davis May 1997 ASCII HTML 15 UTF-7

This document describes a transformation format of Unicode that contains only 7-bit ASCII octets and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of MIME and RFC 1641, "Using Unicode with MIME". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1642 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2152 10.17487/RFC2152 RFC2153 PPP Vendor Extensions W. Simpson May 1997 ASCII HTML 6 PPP-EXT Point-to-Point Protocol

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC1661 RFC1962 RFC5342 RFC7042 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2153 RFC2154 OSPF with Digital Signatures S. Murphy M. Badger B. Wellington June 1997 ASCII HTML 29 OSPF-DIG

This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data. Added LSA processing and key management is detailed. A method for migration from, or co-existence with, standard OSPF V2 is described. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2154 10.17487/RFC2154 RFC2155 Definitions of Managed Objects for APPN using SMIv2 B. Clouston B. Moore June 1997 ASCII HTML 124 APPN-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS-TRACK]

 RFC2455 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2155 RFC2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME S. Kille January 1998 ASCII HTML 144 MIXER multipurpose internet mail extensions message transfer protocol

This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. [STANDARDS-TRACK]

 RFC0987 RFC1026 RFC1138 RFC1148 RFC1327 RFC1495 RFC0822 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2156 RFC2157 Mapping between X.400 and RFC-822/MIME Message Bodies H. Alvestrand January 1998 ASCII HTML 49 mixer multipurpose internet mail extensions

This document defines how to map body parts of X.400 messages into MIME entities and vice versa, including the handling of multipart messages and forwarded messages. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer http://www.rfc-editor.org/errata_search.php?rfc=2157 10.17487/RFC2157 RFC2158 X.400 Image Body Parts H. Alvestrand January 1998 ASCII HTML 4 mixer multipurpose internet mail extensions

This document contains the body parts defined in RFC 1495 for carrying image formats that were originally defined in MIME through an X.400 system. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2158 RFC2159 A MIME Body Part for FAX H. Alvestrand January 1998 ASCII HTML 7 mixer multipurpose internet mail extensions

This document contains the definitions, originally contained in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate it to its X.400 representation. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2159 RFC2160 Carrying PostScript in X.400 and MIME H. Alvestrand January 1998 ASCII HTML 5 mixer multipurpose internet mail extensions

This document describes methods for carrying PostScript information in the two standard mail systems MIME and X.400, and the conversion between them. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2160 RFC2161 A MIME Body Part for ODA H. Alvestrand January 1998 ASCII HTML 5 MIME-ODA mixer multipurpose internet mail extensions

This document contains the definitions, originally contained in RFC 1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it to its X.400 representation. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app mixer 10.17487/RFC2161 RFC2162 MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail C. Allocchio January 1998 ASCII HTML 34 MAP-MAIL mixer multipurpose internet mail extensions mime

The standard referred shortly into this document as "X.400" relates to the ISO/IEC 10021 - CCITT 1984, 1988 and 1992 X.400 Series Recommendations covering the Message Oriented Text Interchange Service (MOTIS). This document covers the Inter Personal Messaging System (IPMS) only. This memo defines an Experimental Protocol for the Internet community.

 RFC1405 EXPERIMENTAL EXPERIMENTAL IETF app mixer 10.17487/RFC2162 RFC2163 Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) C. Allocchio January 1998 ASCII HTML 26 DNS-MCGAM mime internet enhanced Relay Multipurpose internet mail extensions x.400 mixer

This memo is the complete technical specification to store in the Internet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. [STANDARDS-TRACK]

 RFC1664 RFC3597 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2163 RFC2164 Use of an X.500/LDAP directory to support MIXER address mapping S. Kille January 1998 ASCII HTML 10 lightweight directory access protocol mime internet x,.400 enhanced relay

This specification defines how to represent and maintain these mappings (MIXER Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP directory. [STANDARDS-TRACK]

 RFC1838 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2164 RFC2165 Service Location Protocol J. Veizades E. Guttman C. Perkins S. Kaplan June 1997 ASCII HTML 72 SLP

The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. [STANDARDS-TRACK]

 RFC2608 RFC2609 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2165 RFC2166 APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements D. Bryant P. Brittain June 1997 ASCII HTML 34

This document specifies a set of extensions to RFC 1795 designed to improve the scalability of DLSw clarifications to RFC 1795 in the light of the implementation experience to-date. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2166 RFC2167 Referral Whois (RWhois) Protocol V1.5 S. Williamson M. Kosters D. Blacka J. Singh K. Zeilstra June 1997 ASCII HTML 69 RWHOIS

This memo describes Version 1.5 of the client/server interaction of RWhois. RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1714 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2167 RFC2168 Resolution of Uniform Resource Identifiers using the Domain Name System R. Daniel M. Mealling June 1997 ASCII HTML 20

The requirements document for URN resolution systems defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. This memo defines an Experimental Protocol for the Internet community.

 RFC3401 RFC3402 RFC3403 RFC3404 RFC2915 EXPERIMENTAL EXPERIMENTAL IETF app urn 10.17487/RFC2168 RFC2169 A Trivial Convention for using HTTP in URN Resolution R. Daniel June 1997 ASCII HTML 9

The Uniform Resource Names Working Group (URN-WG) was formed to specify persistent, location-independent names for network accessible resources, as well as resolution mechanisms to retrieve the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal [1]. That proposal specifies how a client may find a "resolver" for a URN. A resolver is a database that can provide information about the resource identified by a URN, such as the resource's location, a bibliographic description, or even the resource itself. The protocol used for the client to communicate with the resolver is not specified in the NAPTR proposal. Instead, the NAPTR resource record provides a field that indicates the "resolution protocol" and "resolution service requests" offered by the resolver.

This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. The primary goal of THTTP is to be simple to implement so that existing HTTP servers may easily add support for URN resolution. We expect that the databases used by early resolvers will be useful when more sophisticated resolution protocols are developed later.

 draft-ietf-urn-http-conv-01 HISTORIC EXPERIMENTAL IETF app urn 10.17487/RFC2169 RFC2170 Application REQuested IP over ATM (AREQUIPA) W. Almesberger J. Le Boudec P. Oechslin July 1997 ASCII HTML 10 Internet Protocol

This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2170 RFC2171 MAPOS - Multiple Access Protocol over SONET/SDH Version 1 K. Murakami M. Maruyama June 1997 ASCII HTML 9 MAPOS-SONET

This memo documents a multiple access protocol for transmission of network-protocol datagrams, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2171 RFC2172 MAPOS Version 1 Assigned Numbers M. Maruyama K. Murakami June 1997 ASCII HTML 3

This memo documents the parameters used in the Multiple Access Protocol over SONET/SDH Version 1. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2172 RFC2173 A MAPOS version 1 Extension - Node Switch Protocol K. Murakami M. Maruyama June 1997 ASCII HTML 6

This document describes a MAPOS extension, Node Switch Protocol, for automatic node address assignment. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2173 RFC2174 A MAPOS version 1 Extension - Switch-Switch Protocol K. Murakami M. Maruyama June 1997 ASCII HTML 22

This memo documents a MAPOS (Multiple Access Protocol over SONET/SDH) version 1 extension, Switch Switch Protocol which provides dynamic routing for unicast, broadcast, and multicast. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2174 RFC2175 MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing K. Murakami M. Maruyama June 1997 ASCII HTML 6

This memo documents MAPOS 16, a multiple access protocol for transmission of network-protocol datagrams, encapsulated in HDLC frames with 16 bit addressing, over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2175 RFC2176 IPv4 over MAPOS Version 1 K. Murakami M. Maruyama June 1997 ASCII HTML 6 IPV4-MAPOS

This memo documents a mechanism for supporting Version 4 of the Internet Protocol (IPv4) on Version 1 of the Multiple Access Protocol over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC5494 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2176 RFC2177 IMAP4 IDLE command B. Leiba June 1997 ASCII HTML 4 IMAP4-IDLE

This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2177 RFC2178 OSPF Version 2 J. Moy July 1997 ASCII HTML 211 Open Shortest Path First routing Autonomous system AS

This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest-path tree.

OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated. [STANDARDS-TRACK]

 RFC1583 RFC2328 DRAFT STANDARD DRAFT STANDARD IETF rtg ospf 10.17487/RFC2178 RFC2179 Network Security For Trade Shows A. Gwinn July 1997 ASCII HTML 10 network system attacks

This document is designed to assist vendors and other participants in trade shows, such as Networld+Interop, in designing effective protection against network and system attacks by unauthorized individuals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2179 RFC2180 IMAP4 Multi-Accessed Mailbox Practice M. Gahrns July 1997 ASCII HTML 14 Internet Message Access Protocol Client Server

The behavior described in this document reflects the practice of some existing servers or behavior that the consensus of the IMAP mailing list has deemed to be reasonable. The behavior described within this document is believed to be [RFC-2060] compliant. However, this document is not meant to define IMAP4 compliance, nor is it an exhaustive list of valid IMAP4 behavior. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2180 RFC2181 Clarifications to the DNS Specification R. Elz R. Bush July 1997 ASCII HTML 14 DNS-CLAR Domain Name System

This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK]

 RFC1034 RFC1035 RFC1123 RFC4035 RFC2535 RFC4343 RFC4033 RFC4034 RFC5452 RFC8767 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2181 10.17487/RFC2181 RFC2182 Selection and Operation of Secondary DNS Servers R. Elz R. Bush S. Bradner M. Patton July 1997 ASCII HTML 11 Domain Name System delegated zone

This document discusses the selection of secondary servers for DNS zones.The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 BCP0016 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2182 10.17487/RFC2182 RFC2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field R. Troost S. Dorner K. Moore Editor August 1997 ASCII HTML 12 inline attachment MIME Mail Multimedia EMail

This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information. It specifies the "Content- Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). [STANDARDS-TRACK]

 RFC1806 RFC2184 RFC2231 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2183 10.17487/RFC2183 RFC2184 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations N. Freed K. Moore August 1997 ASCII HTML 9 mail Multimedia EMail

This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK]

 RFC2231 RFC2045 RFC2047 RFC2183 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2184 10.17487/RFC2184 RFC2185 Routing Aspects of IPv6 Transition R. Callon D. Haskin September 1997 ASCII HTML 13 address network tunneling

This document gives an overview of the routing aspects of the IPv6 transition. It is based on the protocols defined in the document "Transition Mechanisms for IPv6 Hosts and Routers." Readers should be familiar with the transition mechanisms before reading this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2185 RFC2186 Internet Cache Protocol (ICP), version 2 D. Wessels K. Claffy September 1997 ASCII HTML 9 ICP www web http hypertext transfer protocol

This document describes version 2 of the Internet Cache Protocol (ICPv2) as currently implemented in two World-Wide Web proxy cache packages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2186 RFC2187 Application of Internet Cache Protocol (ICP), version 2 D. Wessels K. Claffy September 1997 ASCII HTML 24 web www url uniform resource identifier

This document describes the application of ICPv2 (Internet Cache Protocol version 2, RFC2186) to Web caching. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2187 RFC2188 AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2 M. Banan M. Taylor J. Cheng September 1997 ASCII HTML 57 ESRO RPC Remote Procedure Call Wireless

This document specifies the service model, the notation and protocol for Efficient Short Remote Operations (ESRO). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2188 RFC2189 Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification -- A. Ballardie September 1997 ASCII HTML 23 Inter-Domain-Protocol IDMR

This document describes the Core Based Tree (CBT version 2) network layer multicast routing protocol. CBT builds a shared multicast distribution tree per group, and is suited to inter- and intra-domain multicast routing. This memo defines an Experimental Protocol for the Internet community.

 HISTORIC EXPERIMENTAL IETF rtg idmr 10.17487/RFC2189 RFC2190 RTP Payload Format for H.263 Video Streams C. Zhu September 1997 ASCII HTML 12 real-time transfer

This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]

 HISTORIC PROPOSED STANDARD IETF rai avt 10.17487/RFC2190 RFC2191 VENUS - Very Extensive Non-Unicast Service G. Armitage September 1997 ASCII HTML 12 multicast IP ATM

This document focuses exclusively on the problems associated with extending the MARS model to cover multiple clusters or clusters spanning more than one subnet. It describes a hypothetical solution, dubbed "Very Extensive NonUnicast Service" (VENUS), and shows how complex such a service would be. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2191 RFC2192 IMAP URL Scheme C. Newman September 1997 ASCII HTML 16 IMAP-URL Internet Message Access Protocol Uniform Resource Identifiers

This document defines a URL scheme for referencing objects on an IMAP server. [STANDARDS-TRACK]

 RFC5092 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2192 10.17487/RFC2192 RFC2193 IMAP4 Mailbox Referrals M. Gahrns September 1997 ASCII HTML 9 IMAP4MAIL Internet Mail Access Protocol messages

Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2193 RFC2194 Review of Roaming Implementations B. Aboba J. Lu J. Alsop J. Ding W. Wang September 1997 ASCII HTML 35 ISP Internet Server Provider

This document reviews the design and functionality of existing roaming implementations. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF ops roamops 10.17487/RFC2194 RFC2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response J. Klensin R. Catoe P. Krumviede September 1997 ASCII HTML 5 IMAPPOPAU Post Office Protocol Internet Message Access

This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]

 RFC2095 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2195 RFC2196 Site Security Handbook B. Fraser September 1997 ASCII HTML 75

This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet. The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services. The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC1244 FYI0008 INFORMATIONAL INFORMATIONAL IETF ssh http://www.rfc-editor.org/errata_search.php?rfc=2196 10.17487/RFC2196 RFC2197 SMTP Service Extension for Command Pipelining N. Freed September 1997 ASCII HTML 8 SMTP-Pipe simple mail transfer TCP transmission control protocol

This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]

 RFC1854 RFC2920 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2197 RFC2198 RTP Payload for Redundant Audio Data C. Perkins I. Kouvelas O. Hodson V. Hardman M. Handley J.C. Bolot A. Vega-Garcia S. Fosse-Parisis September 1997 ASCII HTML 11 RTP-RAD

This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. [STANDARDS-TRACK]

 RFC6354 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2198 RFC2199 Request for Comments Summary RFC Numbers 2100-2199 A. Ramos January 1998 ASCII HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2199 RFC2200 Internet Official Protocol Standards J. Postel June 1997 ASCII HTML 39 IAB official protocol standards

A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]

 RFC1250 RFC2000 RFC2300 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2200 RFC2201 Core Based Trees (CBT) Multicast Routing Architecture A. Ballardie September 1997 ASCII HTML 15 IP Internet Protocol IDMR Inter-Domain

CBT is a multicast routing architecture that builds a single delivery tree per group which is shared by all of the group's senders and receivers. This memo defines an Experimental Protocol for the Internet community.

 HISTORIC EXPERIMENTAL IETF rtg idmr 10.17487/RFC2201 RFC2202 Test Cases for HMAC-MD5 and HMAC-SHA-1 P. Cheng R. Glenn September 1997 ASCII HTML 9 Hash Message Authentications Codes message digest secure

This document provides two sets of test cases for HMAC-MD5 and HMAC- SHA-1, respectively. HMAC-MD5 and HMAC-SHA-1 are two constructs of the HMAC [HMAC] message authentication function using the MD5 [MD5] hash function and the SHA-1 [SHA] hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2202 10.17487/RFC2202 RFC2203 RPCSEC_GSS Protocol Specification M. Eisler A. Chiu L. Ling September 1997 ASCII HTML 23 RPCSEC-GSS Remote Procedure Call Generic Security Services API Application Programming Interface

This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services Application Programming Interface (referred to henceforth as GSS-API). [STANDARDS-TRACK]

 RFC5403 PROPOSED STANDARD PROPOSED STANDARD IETF tsv oncrpc http://www.rfc-editor.org/errata_search.php?rfc=2203 10.17487/RFC2203 RFC2204 ODETTE File Transfer Protocol D. Nash September 1997 ASCII HTML 74 ODETTE FTP Internet Motor Industry data exchange

This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC5024 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2204 RFC2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification R. Braden Editor L. Zhang S. Berson S. Herzog S. Jamin September 1997 ASCII HTML 112 RSVP integrated services multicast unicast QoS signaling

This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK]

 RFC2750 RFC3936 RFC4495 RFC5946 RFC6437 RFC6780 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp http://www.rfc-editor.org/errata_search.php?rfc=2205 10.17487/RFC2205 RFC2206 RSVP Management Information Base using SMIv2 F. Baker J. Krawczyk A. Sastry September 1997 ASCII HTML 64 RSVP-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2206 RFC2207 RSVP Extensions for IPSEC Data Flows L. Berger T. O'Malley September 1997 ASCII HTML 14 RSVP-IPSEC resource reservation QoS IP Security

This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826, IP Authentication Header (AH) or RFC 1827, IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2207 RFC2208 Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment A. Mankin Editor F. Baker B. Braden S. Bradner M. O'Dell A. Romanow A. Weinrib L. Zhang September 1997 ASCII HTML 6 RSVP

This document describes the applicability of RSVP along with the Integrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF tsv rsvp 10.17487/RFC2208 RFC2209 Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules R. Braden L. Zhang September 1997 ASCII HTML 25 RSVP-MPR QoS implementation algorithms

This memo contains an algorithmic description of the rules used by an RSVP implementation for processing messages. It is intended to clarify the version 1 RSVP protocol specification. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF tsv rsvp http://www.rfc-editor.org/errata_search.php?rfc=2209 10.17487/RFC2209 RFC2210 The Use of RSVP with IETF Integrated Services J. Wroclawski September 1997 ASCII HTML 33 RSVP-IS Resource Reservation Controlled Load QOS: Quality of Service

This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2210 RFC2211 Specification of the Controlled-Load Network Element Service J. Wroclawski September 1997 ASCII HTML 19 QOS: Quality of Service integrated services

This memo specifies the network element behavior required to deliver Controlled-Load service in the Internet. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2211 RFC2212 Specification of Guaranteed Quality of Service S. Shenker C. Partridge R. Guerin September 1997 ASCII HTML 20 GQOS QOS quality of service integrated services

This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2212 RFC2213 Integrated Services Management Information Base using SMIv2 F. Baker J. Krawczyk A. Sastry September 1997 ASCII HTML 21 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Integrated Services Model. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv http://www.rfc-editor.org/errata_search.php?rfc=2213 10.17487/RFC2213 RFC2214 Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2 F. Baker J. Krawczyk A. Sastry September 1997 ASCII HTML 9 MIB attributes interface network protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Guaranteed Service of the Integrated Services Model. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2214 RFC2215 General Characterization Parameters for Integrated Service Network Elements S. Shenker J. Wroclawski September 1997 ASCII HTML 16 QOS Quality of service

This memo defines a set of general control and characterization parameters for network elements supporting the IETF integrated services QoS control framework. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2215 RFC2216 Network Element Service Specification Template S. Shenker J. Wroclawski September 1997 ASCII HTML 22 QOS Quality of Service Control

This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a "template" which service specification documents should follow. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF tsv intserv 10.17487/RFC2216 RFC2217 Telnet Com Port Control Option G. Clark October 1997 ASCII HTML 14 TOPT-COMPORT remote login host

This memo proposes a protocol to allow greater use of modems attached to a network for outbound dialing purposes. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2217 10.17487/RFC2217 RFC2218 A Common Schema for the Internet White Pages Service T. Genovese B. Jennings October 1997 ASCII HTML 8 IWPS information user

This document specifies the minimum set of core attributes of a White Pages entry for an individual and describes how new objects with those attributes can be defined and published. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app ids 10.17487/RFC2218 RFC2219 Use of DNS Aliases for Network Services M. Hamilton R. Wright October 1997 ASCII HTML 8 domain name system symbolic

It has become a common practice to use symbolic names (usually CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to refer to network services such as anonymous FTP [RFC-959] servers, Gopher [RFC- 1436] servers, and most notably World-Wide Web HTTP [RFC-1945] servers. This is desirable for a number of reasons. It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programmatically discover that an organization runs, say, a World-Wide Web server. Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names. This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0017 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ids 10.17487/RFC2219 RFC2220 The Application/MARC Content-type R. Guenther October 1997 ASCII HTML 4 APP-MARC media-type machine readable cataloging records

This memorandum provides a mechanism for representing objects which are files of Machine-Readable Cataloging records (MARC). The MARC formats are standards for the representation and communication of bibliographic and related information. A MARC record contains metadata for an information resource following MARC format specifications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2220 RFC2221 IMAP4 Login Referrals M. Gahrns October 1997 ASCII HTML 5 IMAP4LOGIN Internet Message Access Protocol server

When dealing with large amounts of users and many IMAP4 [RFC-2060] servers, it is often necessary to move users from one IMAP4 server to another. Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2221 RFC2222 Simple Authentication and Security Layer (SASL) J. Myers October 1997 ASCII HTML 16 SASL encryption protocol specific

This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK]

 RFC4422 RFC4752 RFC2444 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2222 10.17487/RFC2222 RFC2223 Instructions to RFC Authors J. Postel J. Reynolds October 1997 ASCII HTML 20 Request For Comment

This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 RFC1543 RFC1111 RFC0825 RFC7322 RFC5741 RFC6949 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2223 RFC2224 NFS URL Scheme B. Callaghan October 1997 ASCII HTML 11 NFS-URL Universal Resource Locators Network File System syntax directories

A new URL scheme, 'nfs' is defined. It is used to refer to files and directories on NFS servers using the general URL syntax defined in RFC 1738, "Uniform Resource Locators (URL)". This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2224 RFC2225 Classical IP and ARP over ATM M. Laubach J. Halpern April 1998 ASCII HTML 28 IP-ATM Internet protocol address resolution asynchronous,transfer mode

This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]

 RFC1626 RFC1577 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2225 RFC2226 IP Broadcast over ATM Networks T. Smith G. Armitage October 1997 ASCII HTML 14 Internet Protocol Asynchronous Transfer Mode

This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2226 RFC2227 Simple Hit-Metering and Usage-Limiting for HTTP J. Mogul P. Leach October 1997 ASCII HTML 37 HTTP Hypertext Transfer Protocol extension

This document proposes a simple extension to HTTP, using a new "Meter" header. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app http 10.17487/RFC2227 RFC2228 FTP Security Extensions M. Horowitz S. Lunt October 1997 ASCII HTML 27 FTPSECEXT file transfer protocol authentication encoding

This document defines extensions to the FTP specification STD 9, RFC

 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2228 RFC2229 A Dictionary Server Protocol R. Faith B. Martin October 1997 ASCII HTML 30 DSP DICT TCP Transmission Control Protocol database definitions

The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2229 10.17487/RFC2229 RFC2230 Key Exchange Delegation Record for the DNS R. Atkinson November 1997 ASCII HTML 11 KEYX-DNS Domain Name System RR Resource Record KX

This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2230 RFC2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations N. Freed K. Moore November 1997 ASCII HTML 10 MIME-EXT Multipurpose Internet Mail Extensions Multimedia EMail

This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [STANDARDS-TRACK]

 RFC2184 RFC2045 RFC2047 RFC2183 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2231 10.17487/RFC2231 RFC2232 Definitions of Managed Objects for DLUR using SMIv2 B. Clouston Editor B. Moore Editor November 1997 ASCII HTML 21 DLUR-MIB Management Information Base MIB Dependent LU Requester APPN Advanced Peer-to-Peer Networking

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with DLUR (Dependent LU Requester) capabilities. This memo identifies managed objects for the DLUR protocol. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2232 RFC2233 The Interfaces Group MIB using SMIv2 K. McCloghrie F. Kastenholz November 1997 ASCII HTML 66 INTERGRMIB Management Information Base Network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANDARDS-TRACK]

 RFC1573 RFC2863 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC2233 RFC2234 Augmented BNF for Syntax Specifications: ABNF D. Crocker Editor P. Overell November 1997 ASCII HTML 14 ABNF Augmented Backus-Naur Form electronic mail

In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. [STANDARDS-TRACK]

 RFC4234 PROPOSED STANDARD PROPOSED STANDARD IETF app drums http://www.rfc-editor.org/errata_search.php?rfc=2234 10.17487/RFC2234 RFC2235 Hobbes' Internet Timeline R. Zakon November 1997 ASCII HTML 22 events technologies history

This document presents a history of the Internet in timeline fashion, highlighting some of the key events and technologies which helped shape the Internet as we know it today. A growth summary of the Internet and some associated technologies is also included. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 FYI0032 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2235 RFC2236 Internet Group Management Protocol, Version 2 W. Fenner November 1997 ASCII HTML 24 IGMP IGMP multicast routing IP Internet Protocol

This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112. [STANDARDS-TRACK]

 RFC1112 RFC3376 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr http://www.rfc-editor.org/errata_search.php?rfc=2236 10.17487/RFC2236 RFC2237 Japanese Character Encoding for Internet Messages K. Tamaru November 1997 ASCII HTML 6 eletronic mail character set scheme

This memo defines an encoding scheme for the Japanese Characters, describes "ISO-2022-JP-1", which is used in electronic mail [RFC-822], and network news [RFC 1036]. Also this memo provides a listing of the Japanese Character Set that can be used in this encoding scheme. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2237 RFC2238 Definitions of Managed Objects for HPR using SMIv2 B. Clouston Editor B. Moore Editor November 1997 ASCII HTML 35 HPR-MIB Management Information Base high performance routing

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with HPR (High Performance Routing) capabilities. This memo identifies managed objects for the HPR protocol. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2238 RFC2239 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2 K. de Graaf D. Romascanu D. McMaster K. McCloghrie S. Roberts November 1997 ASCII HTML 43 MAUS-MIB

This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing 10 and 100 Mb/second Medium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30, "10 & 100 Mb/s Management," October 26, 1995. [STANDARDS-TRACK]

 RFC2668 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2239 RFC2240 A Legal Basis for Domain Name Allocation O. Vaughan November 1997 ASCII HTML 7 DNS

The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC2352 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2240 RFC2241 DHCP Options for Novell Directory Services D. Provan November 1997 ASCII HTML 5 DHCP-NDS Dynamic Host Configuration Protocol Novell Directory Services

This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2241 RFC2242 NetWare/IP Domain Name and Information R. Droms K. Fong November 1997 ASCII HTML 6 NETWAREIP DHCP Dynamic Host Configuration Protocol NetWare/IP

This document defines options that carry NetWare/IP domain name and NetWare/IP sub-options to DHCP clients. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2242 RFC2243 OTP Extended Responses C. Metz November 1997 ASCII HTML 10 OTP-ER One Time Password Extended Responses

This document provides a specification for a type of response to an OTP [RFC 1938] challenge that carries explicit indication of the response's encoding. This document also provides a specification for a response that allows an OTP generator to request that a server re-initialize a sequence and change parameters such as the secret pass phrase. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec otp 10.17487/RFC2243 RFC2244 ACAP -- Application Configuration Access Protocol C. Newman J. G. Myers November 1997 ASCII HTML 71 ACAP Application Configuration Access Protocol URL Uniform Resource Locator

The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. [STANDARDS-TRACK]

 RFC6075 PROPOSED STANDARD PROPOSED STANDARD IETF app acap http://www.rfc-editor.org/errata_search.php?rfc=2244 10.17487/RFC2244 RFC2245 Anonymous SASL Mechanism C. Newman November 1997 ASCII HTML 5 SASL-ANON Simple Authentication Security Layer

As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework. [STANDARDS-TRACK]

 RFC4505 PROPOSED STANDARD PROPOSED STANDARD IETF app acap 10.17487/RFC2245 RFC2246 The TLS Protocol Version 1.0 T. Dierks C. Allen January 1999 ASCII HTML 80 transport protocol layer authentication privacy

This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.

 RFC4346 RFC3546 RFC5746 RFC6176 RFC7465 RFC7507 RFC7919 HISTORIC PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=2246 10.17487/RFC2246 RFC2247 Using Domains in LDAP/X.500 Distinguished Names S. Kille M. Wahl A. Grimstad R. Huber S. Sataluri January 1998 ASCII HTML 7 LDAP lightweight directory access protocol DNS domain name system

This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name. [STANDARDS-TRACK]

 RFC4519 RFC4524 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2247 RFC2248 Network Services Monitoring MIB N. Freed S. Kille January 1998 ASCII HTML 19 NSM-MIB Management Information Base SNMP Simple Network Management Protocol

This MIB may be used on its own for any application, and for most simple applications this will suffice. This MIB is also designed to serve as a building block which can be used in conjunction with application- specific monitoring and management. [STANDARDS-TRACK]

 RFC1565 RFC2788 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2248 RFC2249 Mail Monitoring MIB N. Freed S. Kille January 1998 ASCII HTML 28 MAIL-MIB Management Information Base Message Transfer Agents

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB [STANDARDS-TRACK]

 RFC1566 RFC2789 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2249 RFC2250 RTP Payload Format for MPEG1/MPEG2 Video D. Hoffman G. Fernando V. Goyal M. Civanlar January 1998 ASCII HTML 16 RTP-MPEG Real-Time Transport Protocol Audio System Streams

This memo describes a packetization scheme for MPEG video and audio streams. [STANDARDS-TRACK] The purpose of this document is to express the general Internet community's expectations of Computer Security Incident Response Teams (CSIRTs). It is not possible to define a set of requirements that would be appropriate for all teams, but it is possible and helpful to list and describe the general set of topics and issues which are of concern and interest to constituent communities. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC2038 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=2250 10.17487/RFC2250 RFC2251 Lightweight Directory Access Protocol (v3) M. Wahl T. Howes S. Kille December 1997 ASCII HTML 50 LDAPV3 Lightweight Directory Access Protocol x.500

The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK]

 RFC4510 RFC4511 RFC4513 RFC4512 RFC3377 RFC3771 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2251 RFC2252 Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions M. Wahl A. Coulbeck T. Howes S. Kille December 1997 ASCII HTML 32 LDAP3-ATD LDAv3 x.500 syntax

This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. [STANDARDS-TRACK]

 RFC4510 RFC4517 RFC4523 RFC4512 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2252 10.17487/RFC2252 RFC2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names M. Wahl S. Kille T. Howes December 1997 ASCII HTML 10 LDAP3-UTF8 LDAPv3 x.500 ASN.1 string format

This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK]

 RFC1779 RFC4510 RFC4514 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2253 10.17487/RFC2253 RFC2254 The String Representation of LDAP Search Filters T. Howes December 1997 ASCII HTML 8 STR-LDAP LDAPv3 x.500 ASN.1 string format

This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]

 RFC1960 RFC4510 RFC4515 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2254 10.17487/RFC2254 RFC2255 The LDAP URL Format T. Howes M. Smith December 1997 ASCII HTML 10 LDAP-URL Lightweight Directory Access Protocol Universal Resource Locator

This document describes a format for an LDAP Uniform Resource Locator. [STANDARDS-TRACK]

 RFC1959 RFC4510 RFC4516 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2255 RFC2256 A Summary of the X.500(96) User Schema for use with LDAPv3 M. Wahl December 1997 ASCII HTML 20 Lightweight Directory Access Protocol syntax

This document provides an overview of the attribute types and object classes defined by the ISO and ITU-T committees in the X.500 documents, in particular those intended for use by directory clients. [STANDARDS-TRACK]

 RFC4517 RFC4519 RFC4523 RFC4512 RFC4510 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2256 RFC2257 Agent Extensibility (AgentX) Protocol Version 1 M. Daniele B. Wijnen D. Francisco January 1998 ASCII HTML 80 AGENTX SNMP Simple Network Management Protocol MIB Information Base

This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. [STANDARDS-TRACK]

 RFC2741 PROPOSED STANDARD PROPOSED STANDARD IETF ops agentx 10.17487/RFC2257 RFC2258 Internet Nomenclator Project J. Ordille January 1998 ASCII HTML 15 Database Server CCSO Computer Communications Services Office

The goal of the Internet Nomenclator Project is to integrate the hundreds of publicly available CCSO servers from around the world. This document provides an overview of the Nomenclator system, describes how to register a CCSO server in the Internet Nomenclator Project, and how to use the Nomenclator search engine to find people on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2258 RFC2259 Simple Nomenclator Query Protocol (SNQP) J. Elliott J. Ordille January 1998 ASCII HTML 30 SNQP Data Repositories Client Server

The Simple Nomenclator Query Protocol (SNQP) allows a client to communicate with a descriptive name service or other relational-style query service. This memo provides information for the Internet community. It does not specify an Internet standard of any kind

 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2259 RFC2260 Scalable Support for Multi-homed Multi-provider Connectivity T. Bates Y. Rekhter January 1998 ASCII HTML 12 ISP Internet Service Provider Routing

This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2260 10.17487/RFC2260 RFC2261 An Architecture for Describing SNMP Management Frameworks D. Harrington R. Presuhn B. Wijnen January 1998 ASCII HTML 56 Simple Network Management Protocol Message Network Management Protocol security access control snmpv3

This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK]

 RFC2271 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2261 RFC2262 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen January 1998 ASCII HTML 39 architecture SNMPv3 multiple versions

This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2261]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]

 RFC2272 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2262 RFC2263 SNMPv3 Applications D. Levi P. Meyer B. Stewart January 1998 ASCII HTML 70 Simple Network Management Protocol operations notification filtering proxy forwarding

This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK]

 RFC2273 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2263 RFC2264 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen January 1998 ASCII HTML 76 architecture message level

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]

 RFC2274 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2264 RFC2265 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie January 1998 ASCII HTML 36 SNMPV3 Architecture

This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]

 RFC2275 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2265 RFC2266 Definitions of Managed Objects for IEEE 802.12 Repeater Devices J. Flick January 1998 ASCII HTML 56 MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network repeaters based on IEEE 802.12. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2266 RFC2267 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing P. Ferguson D. Senie January 1998 ASCII HTML 10 ISP Internet Service Provider Internet Protocol DOS

This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC2827 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2267 RFC2268 A Description of the RC2(r) Encryption Algorithm R. Rivest March 1998 ASCII HTML 11 RC2-ENCRP encryption secre key rsa

This memo describes a conventional (secret-key) block encryption algorithm, called RC2, which may be considered as a proposal for a DES replacement. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2268 10.17487/RFC2268 RFC2269 Using the MARS Model in non-ATM NBMA Networks G. Armitage January 1998 ASCII HTML 6 Asynchronous Transfer Mode Multicast Address Resolution Server IP Internet Protocol

This document is intended to state the obvious equivalences, and explain the less obvious implications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2269 RFC2270 Using a Dedicated AS for Sites Homed to a Single Provider J. Stewart T. Bates R. Chandra E. Chen January 1998 ASCII HTML 6 Autonomous System BGP4 Border Gateway Protocol ISP Internet Service

With the increased growth of the Internet, the number of customers using BGP4 has grown significantly. RFC1930 outlines a set of guidelines for when one needs and should use an AS. However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP. This paper proposes a solution to this problem in line with recommendations set forth in RFC1930. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC2270 RFC2271 An Architecture for Describing SNMP Management Frameworks D. Harrington R. Presuhn B. Wijnen January 1998 ASCII HTML 56 Simple Network Management Protocol Message Network Management Protocol security access control snmpv3

This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK]

 RFC2261 RFC2571 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2271 RFC2272 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen January 1998 ASCII HTML 39 SNMPv3 architecture SNMPv3 multiple versions

This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]

 RFC2262 RFC2572 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2272 RFC2273 SNMPv3 Applications D. Levi P. Meyer B. Stewart January 1998 ASCII HTML 70 Simple Network Management Protocol operations notification filtering proxy forwarding

This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK]

 RFC2263 RFC2573 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2273 RFC2274 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen January 1998 ASCII HTML 76 architecture message level

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]

 RFC2264 RFC2574 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2274 RFC2275 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie January 1998 ASCII HTML 36 SNMPV3 Architecture

This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]

 RFC2265 RFC2575 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2275 RFC2276 Architectural Principles of Uniform Resource Name Resolution K. Sollins January 1998 ASCII HTML 24 URCs URN URLs Uniform Resource Locators Characteristics

This document addresses the issues of the discovery of URN (Uniform Resource Name) resolver services that in turn will directly translate URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource Characteristics). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC3401 INFORMATIONAL INFORMATIONAL IETF app urn 10.17487/RFC2276 RFC2277 IETF Policy on Character Sets and Languages H. Alvestrand January 1998 ASCII HTML 9 charset

This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0018 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=2277 10.17487/RFC2277 RFC2278 IANA Charset Registration Procedures N. Freed J. Postel January 1998 ASCII HTML 10 character set mime multipurpose internet mail extensions

MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC2978 INFORMATIONAL BEST CURRENT PRACTICE Legacy 10.17487/RFC2278 RFC2279 UTF-8, a transformation format of ISO 10646 F. Yergeau January 1998 ASCII HTML 10 UTF-8 UCS Transformation Format

UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards. [STANDARDS-TRACK]

 RFC2044 RFC3629 DRAFT STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2279 RFC2280 Routing Policy Specification Language (RPSL) C. Alaettinoglu T. Bates E. Gerich D. Karrenberg D. Meyer M. Terpstra C. Villamizar January 1998 ASCII HTML 53 RPSL network operator AS autonomous system database

This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]

 RFC2622 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2280 RFC2281 Cisco Hot Standby Router Protocol (HSRP) T. Li B. Cole P. Morton D. Li March 1998 ASCII HTML 17 HSRP

The memo specifies the Hot Standby Router Protocol (HSRP). The goal of the protocol is to allow hosts to appear to use a single router and to maintain connectivity even if the actual first hop router they are using fails. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2281 10.17487/RFC2281 RFC2282 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin February 1998 ASCII HTML 14 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC2027 RFC2727 INFORMATIONAL BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC2282 RFC2283 Multiprotocol Extensions for BGP-4 T. Bates R. Chandra D. Katz Y. Rekhter February 1998 ASCII HTML 9 MEXT-BGP4 Border gateway protocol router network layer

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]

 RFC2858 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2283 RFC2284 PPP Extensible Authentication Protocol (EAP) L. Blunk J. Vollbrecht March 1998 ASCII HTML 15 PPP-EAP point-to-point authentication

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines the PPP Extensible Authentication Protocol. [STANDARDS-TRACK]

 RFC3748 RFC2484 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2284 RFC2285 Benchmarking Terminology for LAN Switching Devices R. Mandeville February 1998 ASCII HTML 25 local area network MAC Medium Access Control layer

This document is intended to provide terminology for the benchmarking of local area network (LAN) switching devices. It extends the terminology already defined for benchmarking network interconnect devices in RFCs 1242 and 1944 to switching devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2285 RFC2286 Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128 J. Kapp February 1998 ASCII HTML 7 has authentication message IP Internet Protocol codes

This document provides two sets of test cases for HMAC-RIPEMD160 and HMAC-RIPEMD128. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2286 10.17487/RFC2286 RFC2287 Definitions of System-Level Managed Objects for Applications C. Krupczak J. Saperia February 1998 ASCII HTML 44 SLM-APP System-Level Managed Objects for Applications mib management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a basic set of managed objects for fault, configuration and performance management of applications from a systems perspective. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app applmib 10.17487/RFC2287 RFC2288 Using Existing Bibliographic Identifiers as Uniform Resource Names C. Lynch C. Preston R. Daniel February 1998 ASCII HTML 10 URNs Syntax framework

This document discusses how three major bibliographic identifiers (the ISBN, ISSN and SICI) can be supported within the URN framework and the currently proposed syntax for URNs. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=2288 10.17487/RFC2288 RFC2289 A One-Time Password System N. Haller C. Metz P. Nesser M. Straw February 1998 ASCII HTML 25 ONE-PASS one-time password authentication system OTP replay attach

This document describes a one-time password authentication system (OTP). The system provides authentication for system access (login) and other applications requiring authentication that is secure against passive attacks based on replaying captured reusable passwords. [STANDARDS-TRACK]

 RFC1938 STD0061 INTERNET STANDARD DRAFT STANDARD IETF sec otp 10.17487/RFC2289 RFC2290 Mobile-IPv4 Configuration Option for PPP IPCP J. Solomon S. Glass February 1998 ASCII HTML 17 Mobile-IPv4 address PPP Point-to-Point Protocol IPCP Internet Protocol Control Protocol

Mobile IP [RFC 2002] defines media-independent procedures by which a Mobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point-to-point links. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed. [STANDARDS-TRACK]

 RFC2002 RFC2794 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2290 RFC2291 Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web J. Slein F. Vitali E. Whitehead D. Durand February 1998 ASCII HTML 21 WWW remote editing locking mechanism

This document presents a list of features in the form of requirements for a Web Distributed Authoring and Versioning protocol which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve link management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app webdav 10.17487/RFC2291 RFC2292 Advanced Sockets API for IPv6 W. Stevens M. Thomas February 1998 ASCII HTML 67 application program interface

The current document defines some the "advanced" features of the sockets API that are required for applications to take advantage of additional features of IPv6. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC3542 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2292 RFC2293 Representing Tables and Subtrees in the X.500 Directory S. Kille March 1998 ASCII HTML 8 SUBTABLE mapping distinguished name X.500

This document defines techniques for representing two types of information mapping in the OSI Directory: Mapping from a key to a value (or set of values), as might be done in a table lookup, and mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree. [STANDARDS-TRCK]

 RFC1837 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2293 RFC2294 Representing the O/R Address hierarchy in the X.500 Directory Information Tree S. Kille March 1998 ASCII HTML 13 OR-ADD O/R address routing mapping X.500 Directory Information Tree

This document defines a representation of the O/R Address hierarchy in the Directory Information Tree. [STANDARDS-TRACK]

 RFC1836 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2294 RFC2295 Transparent Content Negotiation in HTTP K. Holtman A. Mutz March 1998 ASCII HTML 58 TCN-HTTP Transparent Content Negotiation Hypertext Transfer Protocol URL Uniform Resource Locators

HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 EXPERIMENTAL EXPERIMENTAL IETF app http 10.17487/RFC2295 RFC2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0 K. Holtman A. Mutz March 1998 ASCII HTML 13 HTTP-RVSA Hyper Text Transfer protocol URL Uniform Resource Locators

HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0.

 draft-ietf-http-rvsa-v10-03 HISTORIC EXPERIMENTAL IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2296 10.17487/RFC2296 RFC2297 Ipsilon's General Switch Management Protocol Specification Version 2.0 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall March 1998 ASCII HTML 109 GSMP gsmp atm asynchronous transfer mode

This memo specifies enhancements to the General Switch Management Protocol (GSMP) [RFC1987]. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC1987 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2297 RFC2298 An Extensible Message Format for Message Disposition Notifications R. Fajman March 1998 ASCII HTML 28 EMF-MDN MDN media-type MIME multipurpose internet mail extensions

This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. [STANDARDS-TRACK]

 RFC3798 PROPOSED STANDARD PROPOSED STANDARD IETF app receipt 10.17487/RFC2298 RFC2299 Request for Comments Summary A. Ramos January 1999 ASCII HTML 24 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2299 RFC2300 Internet Official Protocol Standards J. Postel May 1998 ASCII HTML 59 IAB official protocol standards

A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]

 RFC2200 RFC2400 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2300 RFC2301 File Format for Internet Fax L. McIntyre S. Zilles R. Buckley D. Venable G. Parsons J. Rafferty March 1998 ASCII HTML 77 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. [STANDARDS-TRACK]

 RFC3949 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2301 RFC2302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration G. Parsons J. Rafferty S. Zilles March 1998 ASCII HTML 8 TIFF Multipurpose Internet Mail extensions

This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK]

 RFC3302 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2302 RFC2303 Minimal PSTN address format in Internet Mail C. Allocchio March 1998 ASCII HTML 8 MIN-PSTN e-mail service

This memo describes the MINIMAL addressing method to encode PSTN addresses into e-mail addresses and the standard extension mechanism to allow definition of further standard elements. [STANDARDS-TRACK]

 RFC3191 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2303 RFC2304 Minimal FAX address format in Internet Mail C. Allocchio March 1998 ASCII HTML 8 MINFAX-IM encoding facsimile e-mail

This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS-TRACK]

 RFC3192 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2304 RFC2305 A Simple Mode of Facsimile Using Internet Mail K. Toyoda H. Ohno J. Murai D. Wing March 1998 ASCII HTML 13 SMFAX-IM data file format e-mail

This specification provides for "simple mode" carriage of facsimile data over the Internet. [STANDARDS-TRACK]

 RFC3965 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2305 RFC2306 Tag Image File Format (TIFF) - F Profile for Facsimile G. Parsons J. Rafferty March 1998 ASCII HTML 25 file format storage

This document describes in detail the definition of TIFF-F that is used to store facsimile images. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC2306 RFC2307 An Approach for Using LDAP as a Network Information Service L. Howard March 1998 ASCII HTML 21 LDAP-NIS lightweight directory access protocol Network Information Service unix mapping

This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC2251]. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2307 10.17487/RFC2307 RFC2308 Negative Caching of DNS Queries (DNS NCACHE) M. Andrews March 1998 ASCII HTML 19 DNS-NCACHE Domain Name System negative queries

RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]

 RFC1034 RFC1035 RFC4035 RFC4033 RFC4034 RFC6604 RFC8020 RFC8499 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2308 10.17487/RFC2308 RFC2309 Recommendations on Queue Management and Congestion Avoidance in the Internet B. Braden D. Clark J. Crowcroft B. Davie S. Deering D. Estrin S. Floyd V. Jacobson G. Minshall C. Partridge L. Peterson K. Ramakrishnan S. Shenker J. Wroclawski L. Zhang April 1998 ASCII HTML 17 performance router deployment

This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC7567 RFC7141 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2309 RFC2310 The Safe Response Header Field K. Holtman April 1998 ASCII HTML 5 http hyper text transfer protocol

This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. Such an indication will allow user agents to handle retries of some safe requests, in particular safe POST requests, in a more user-friendly way.

 draft-holtman-http-safe-03 HISTORIC EXPERIMENTAL IETF app http 10.17487/RFC2310 RFC2311 S/MIME Version 2 Message Specification S. Dusse P. Hoffman B. Ramsdell L. Lundblade L. Repka March 1998 ASCII HTML 37 SMIME-MSG secure multipurpose internet mail extensions

This document describes a protocol for adding cryptographic signature and encryption services to MIME data. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 HISTORIC INFORMATIONAL Legacy 10.17487/RFC2311 RFC2312 S/MIME Version 2 Certificate Handling S. Dusse P. Hoffman B. Ramsdell J. Weinstein March 1998 ASCII HTML 20 SMIME-CERT secure multipurpose internet mail extensions

This memo describes the mechanisms S/MIME uses to create and validate keys using certificates. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 HISTORIC INFORMATIONAL Legacy 10.17487/RFC2312 RFC2313 PKCS #1: RSA Encryption Version 1.5 B. Kaliski March 1998 ASCII HTML 19 PKCS-1 data public key cryptosystem

This document describes a method for encrypting data using the RSA public-key cryptosystem. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC2437 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2313 RFC2314 PKCS #10: Certification Request Syntax Version 1.5 B. Kaliski March 1998 ASCII HTML 8 PKCS-10 public key distinguished name encryption data

This document describes a syntax for certification requests. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC2986 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2314 RFC2315 PKCS #7: Cryptographic Message Syntax Version 1.5 B. Kaliski March 1998 ASCII HTML 32 PKCS-7 data authentication PEM privacy enhanced mail

This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2315 RFC2316 Report of the IAB Security Architecture Workshop S. Bellovin April 1998 ASCII HTML 9 Internet Board protocols tools

On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. We identified the core security components of the architecture, and specified several documents that need to be written. Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2316 RFC2317 Classless IN-ADDR.ARPA delegation H. Eidnes G. de Groot P. Vixie March 1998 ASCII HTML 10 routing mapping addresses zone files

This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0020 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2317 10.17487/RFC2317 RFC2318 The text/css Media Type H. Lie B. Bos C. Lilley March 1998 ASCII HTML 5 TEXT-CSS MIME multipurpose Internet mail extension

This memo provides information about the text/css Media Type. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2318 RFC2319 Ukrainian Character Set KOI8-U KOI8-U Working Group April 1998 ASCII HTML 9 KOI8-U encoding mail information resources

This document provides information about character encoding KOI8-U (KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet community. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=2319 10.17487/RFC2319 RFC2320 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB) M. Greene J. Luciani K. White T. Kuo April 1998 ASCII HTML 52 IPOA-MIB Classical IP and ARP over ATM management information base internet protocol address resolution asynchronous transfer mode

The purpose of this memo is to define the Management Information Base (MIB) for supporting Classical IP and ARP over ATM as specified in Classical IP and ARP over ATM. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2320 RFC2321 RITA -- The Reliable Internetwork Troubleshooting Agent A. Bressen April 1 1998 ASCII HTML 6 networking environments

A Description of the usage of Nondeterministic Troubleshooting and Diagnostic Methodologies as applied to today's complex nondeterministic networks and environments. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2321 RFC2322 Management of IP numbers by peg-dhcp K. van den Hout A. Koopal R. van Mook April 1 1998 ASCII HTML 7 Internet Protocol HIP Hacking in progress

This RFC describes a protocol to dynamically hand out ip-numbers on field networks and small events that don't necessarily have a clear organisational body. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2322 10.17487/RFC2322 RFC2323 IETF Identification and Security Guidelines A. Ramos April 1 1998 ASCII HTML 5 facial hairius extremis FHE

This RFC is meant to represent a guideline by which the IETF conferences may run more effeciently with regards to identification and security protocols, with specific attention paid to a particular sub-group within the IETF: "facial hairius extremis". This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2323 RFC2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) L. Masinter April 1 1998 ASCII HTML 10 controlling monitoring diagnosing

This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC7168 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2324 10.17487/RFC2324 RFC2325 Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2 M. Slavitch April 1 1998 ASCII HTML 8 MIB management information base coffee brewing

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of coffee-brewing and maintenance devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2325 10.17487/RFC2325 RFC2326 Real Time Streaming Protocol (RTSP) H. Schulzrinne A. Rao R. Lanphier April 1998 ASCII HTML 92 RTSP Real Time Streaming Protocol audio video data delivery application level

The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. [STANDARDS-TRACK]

 RFC7826 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=2326 10.17487/RFC2326 RFC2327 SDP: Session Description Protocol M. Handley V. Jacobson April 1998 ASCII HTML 42 SDP mbone internet multicast backbone multimedia

This document defines the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]

 RFC4566 RFC3266 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=2327 10.17487/RFC2327 RFC2328 OSPF Version 2 J. Moy April 1998 ASCII HTML 244 OSPF2 Open Shortest Path First routing Autonomous system AS

This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]

 RFC2178 RFC5709 RFC6549 RFC6845 RFC6860 RFC7474 RFC8042 STD0054 INTERNET STANDARD INTERNET STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=2328 10.17487/RFC2328 RFC2329 OSPF Standardization Report J. Moy April 1998 ASCII HTML 9 open shortest path first

This memo documents how the requirements for advancing a routing protocol to Full Standard have been met for OSPFv2. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC2329 RFC2330 Framework for IP Performance Metrics V. Paxson G. Almes J. Mahdavi M. Mathis May 1998 ASCII HTML 40 Internet Protocol measurement statistics

The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC7312 RFC8468 RFC9198 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC2330 RFC2331 ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update M. Maher April 1998 ASCII HTML 26 UNI-SIG signalling ATM asynchronous transfer mode IP internet protocol

This memo describes how to efficiently use the ATM call control signalling procedures defined in UNI Signalling 4.0 to support IP over ATM environments as described in RFC 2225 and in RFC 2332. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2331 RFC2332 NBMA Next Hop Resolution Protocol (NHRP) J. Luciani D. Katz D. Piscitello B. Cole N. Doraswamy April 1998 ASCII HTML 52 NHRP Next Hop Resolution Protocol internetworking layer address subnetwork multiprotocol NBMA non-broadcast multiple-access

This document describes the NBMA Next Hop Resolution Protocol (NHRP). NHRP can be used by a source station (host or router) connected to a Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer address and NBMA subnetwork addresses of the "NBMA next hop" towards a destination station. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2332 RFC2333 NHRP Protocol Applicability Statement D. Cansever April 1998 ASCII HTML 9 NHRP next hop resolution protocol routing IP internet protocol NBMA non-broadcast multiple-access internetworking

As required by the Routing Protocol Criteria [RFC 1264], this memo discusses the applicability of the Next Hop Resolution Protocol (NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access (NBMA) networks, such as ATM, SMDS and X.25. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2333 RFC2334 Server Cache Synchronization Protocol (SCSP) J. Luciani G. Armitage J. Halpern N. Doraswamy April 1998 ASCII HTML 40 SCSP Server Cache Synchronization Protocol replication NBMA non-broadcast multiple access

This document describes the Server Cache Synchronization Protocol (SCSP) and is written in terms of SCSP's use within Non Broadcast Multiple Access (NBMA) networks; although, a somewhat straight forward usage is applicable to BMA networks. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion http://www.rfc-editor.org/errata_search.php?rfc=2334 10.17487/RFC2334 RFC2335 A Distributed NHRP Service Using SCSP J. Luciani April 1998 ASCII HTML 7 NHRP-SCSP next hop resolution protocol server cache synchronization protocol

This document describes a method for distributing an NHRP service within a LIS. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2335 RFC2336 Classical IP and ARP over ATM to NHRP Transition J. Luciani July 1998 ASCII HTML 5

This document describes methods and procedures for the graceful transition from an ATMARP LIS to an NHRP LIS network model over ATM. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2336 RFC2337 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM D. Farinacci D. Meyer Y. Rekhter April 1998 ASCII HTML 8 IP internet protocol ATM asynchronous transfer mode PIM Protocol Independent Multicast

This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 EXPERIMENTAL EXPERIMENTAL IETF int ion 10.17487/RFC2337 RFC2338 Virtual Router Redundancy Protocol S. Knight D. Weaver D. Whipple R. Hinden D. Mitzel P. Hunt P. Higginson M. Shand A. Lindem April 1998 ASCII HTML 27 VRRP vrrp lan local area network ip internet protocol

This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. [STANDARDS-TRACK]

 RFC3768 PROPOSED STANDARD PROPOSED STANDARD IETF rtg vrrp 10.17487/RFC2338 RFC2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols The Internet Society Sun Microsystems May 1998 ASCII HTML 5 ISOC network file system internet engineering task force

This Request for Comments records an agreement between Sun Microsystems, Inc. and the Internet Society to permit the flow of Sun's Network File System specifications into the Internet Standards process conducted by the Internet Engineering Task Force. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2339 RFC2340 Nortel's Virtual Network Switching (VNS) Overview B. Jamoussi D. Jamieson D. Williston S. Gabe May 1998 ASCII HTML 14 routing packet switching multi-protocol

This document provides an overview of Virtual Network Switching (VNS). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2340 RFC2341 Cisco Layer Two Forwarding (Protocol) "L2F" A. Valencia M. Littlewood T. Kolar May 1998 ASCII HTML 29 L2F Layer Two Forwarding protocol tunneling dial-up network

This document describes the Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. This memo describes a historic protocol for the Internet community. It does not specify an Internet standard of any kind.

 HISTORIC HISTORIC Legacy 10.17487/RFC2341 RFC2342 IMAP4 Namespace M. Gahrns C. Newman May 1998 ASCII HTML 10 IMAP4NAME internet message access protocol namespace mailbox

This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. [STANDARDS-TRACK]

 RFC4466 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2342 RFC2343 RTP Payload Format for Bundled MPEG M. Civanlar G. Cash B. Haskell May 1998 ASCII HTML 8 RTP-MPEG real-time transport protocol audio video

This document describes a payload type for bundled, MPEG-2 encoded video and audio data that may be used with RTP, version 2. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC2343 RFC2344 Reverse Tunneling for Mobile IP G. Montenegro Editor May 1998 ASCII HTML 19 MOBILIPREV internet protocol extensions home foreign agent encapsulating delivery style

This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. [STANDARDS-TRACK]

 RFC3024 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2344 RFC2345 Domain Names and Company Name Retrieval J. Klensin T. Wolf G. Oglesby May 1998 ASCII HTML 14 URL mapping service whois dns domain name system

This document proposes a company name to URL mapping service based on the oldest and least complex of Internet directory protocols, whois, in order to explore whether an extremely simple and widely-deployed protocol can succeed where more complex and powerful options have failed or been excessively delayed. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2345 RFC2346 Making Postscript and PDF International J. Palme May 1998 ASCII HTML 6 portable document format document

Certain text formats, for example Postscript (MIME-Type: application/postscript; file extension .ps) and Portable Document Format (MIME-Type: application/pdf; file extension .pdf) specify exactly the page layout of the printed document. The commonly used paper format is different in North America and the rest of the world. North America uses the 'Letter' format, while the rest of the world mostly uses the ISO-standard 'A4' format. This means that documents formatted on one continent may not be easily printable on another continent. This memo gives advice on how to produce documents which are equally well printable with the Letter and the A4 formats. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2346 RFC2347 TFTP Option Extension G. Malkin A. Harkin May 1998 ASCII HTML 7 TFTP-Ext trivial file transfer protocol extension booting client server

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer. [STANDARDS-TRACK]

 RFC1782 RFC1350 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2347 10.17487/RFC2347 RFC2348 TFTP Blocksize Option G. Malkin A. Harkin May 1998 ASCII HTML 5 TFTP-Blk trivial file transfer protocol booting client server extension

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK]

 RFC1783 RFC1350 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2348 RFC2349 TFTP Timeout Interval and Transfer Size Options G. Malkin A. Harkin May 1998 ASCII HTML 5 TFTP-Opt trivial file transfer protocol booting client server extension

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes two TFTP options. [STANDARDS-TRACK]

 RFC1784 RFC1350 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2349 RFC2350 Expectations for Computer Security Incident Response N. Brownlee E. Guttman June 1998 ASCII HTML 38 CSIRT guidelines user BCP0021 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grip http://www.rfc-editor.org/errata_search.php?rfc=2350 10.17487/RFC2350 RFC2351 Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP A. Robert May 1998 ASCII HTML 23 IP internet protocol encapsulation transactional traffic messaging

This memo specifies a protocol for the encapsulation of the airline specific protocol over IP. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2351 RFC2352 A Convention For Using Legal Names as Domain Names O. Vaughan May 1998 ASCII HTML 8 DNS

The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC2240 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2352 RFC2353 APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document G. Dudley May 1998 ASCII HTML 48 internet protocol advanced peer-to-peer networking high performance routing

This memo defines a method with which HPR nodes can use IP networks for communication, and the enhancements to APPN required by this method. This memo also describes an option set that allows the use of the APPN connection network model to allow HPR nodes to use IP networks for communication without having to predefine link connections. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2353 RFC2354 Options for Repair of Streaming Media C. Perkins O. Hodson June 1998 ASCII HTML 12 packets UDP user datagram protocol

This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC2354 RFC2355 TN3270 Enhancements B. Kelly June 1998 ASCII HTML 38 TN3270E Telnet option client

This document describes a protocol that more fully supports 3270 devices than do traditional tn3270 practices. [STANDARDS-TRACK]

 RFC1647 RFC6270 DRAFT STANDARD DRAFT STANDARD IETF app tn3270e 10.17487/RFC2355 RFC2356 Sun's SKIP Firewall Traversal for Mobile IP G. Montenegro V. Gupta June 1998 ASCII HTML 24 Internet Protocol security traffic

The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. The mechanisms described in this document allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int mobileip 10.17487/RFC2356 RFC2357 IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols A. Mankin A. Romanow S. Bradner V. Paxson June 1998 ASCII HTML 11 internet engineering task force rmtp procedures

This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF. Within today's Internet, important applications exist for a reliable multicast service. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2357 RFC2358 Definitions of Managed Objects for the Ethernet-like Interface Types J. Flick J. Johnson June 1998 ASCII HTML 39 MIB Management Information Base 802.3

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1650 "Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2". This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces. [STANDARDS-TRACK]

 RFC1650 RFC2665 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2358 RFC2359 IMAP4 UIDPLUS extension J. Myers June 1998 ASCII HTML 6 IMAP4UIDPL internet message access protocol disconnected operation

The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. [STANDARDS-TRACK]

 RFC4315 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2359 RFC2360 Guide for Internet Standards Writers G. Scott June 1998 ASCII HTML 20 specification multiple implementations

This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0022 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF stdguide 10.17487/RFC2360 RFC2361 WAVE and AVI Codec Registries E. Fleischman June 1998 ASCII HTML 71 multimedia parameter audio video microsoft

The purpose of this paper is to establish a mechanism by which codecs registered within Microsoft's WAVE and AVI Registries may be referenced within the IANA Namespace by Internet applications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2361 10.17487/RFC2361 RFC2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification D. Estrin D. Farinacci A. Helmy D. Thaler S. Deering M. Handley V. Jacobson C. Liu P. Sharma L. Wei June 1998 ASCII HTML 66 PIM-SM Protocol Independent Multicast-Sparse Mode routing message type timers flags

This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

 RFC2117 RFC4601 RFC5059 EXPERIMENTAL EXPERIMENTAL IETF rtg idmr http://www.rfc-editor.org/errata_search.php?rfc=2362 10.17487/RFC2362 RFC2363 PPP Over FUNI G. Gross M. Kaycee A. Li A. Malis J. Stephens July 1998 ASCII HTML 12 PPP-FUNI point-to-point protocol Frame User Interface ATM asynchronous transfer mode

This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2363 RFC2364 PPP Over AAL5 G. Gross M. Kaycee A. Li A. Malis J. Stephens July 1998 ASCII HTML 12 PPP-AAL point-to-point protocol ATM Adaption Layer 5 link control network-layer authentication compression

This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2364 RFC2365 Administratively Scoped IP Multicast D. Meyer July 1998 ASCII HTML 8 internet protocol IPv4 ipv6 address classes

This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0023 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC2365 RFC2366 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks C. Chung M. Greene July 1998 ASCII HTML 76 MIB management information base asynchronous transfer mode

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI 3.0/3.1 based ATM Networks'. [STANDARDS-TRACK]

 RFC2417 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2366 RFC2367 PF_KEY Key Management API, Version 2 D. McDonald C. Metz B. Phan July 1998 ASCII HTML 68 IP internet protocol security application programming interface

A generic key management API that can be used not only for IP Security but also for other network security services is presented in this document. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2367 10.17487/RFC2367 RFC2368 The mailto URL scheme P. Hoffman L. Masinter J. Zawinski July 1998 ASCII HTML 10 URLMAILTO uniform resource locator electronic mail addresses

This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. [STANDARDS-TRACK]

 RFC6068 RFC1738 RFC1808 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2368 RFC2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields G. Neufeld J. Baer July 1998 ASCII HTML 15 URL uniform resource locator email header fields

The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2369 RFC2370 The OSPF Opaque LSA Option R. Coltun July 1998 ASCII HTML 15 OSPF-LSA open shortest path first link state advertisement

This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. [STANDARDS-TRACK]

 RFC5250 RFC3630 RFC2328 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC2370 RFC2371 Transaction Internet Protocol Version 3.0 J. Lyon K. Evans J. Klein July 1998 ASCII HTML 31 TIPV3 Transaction Internet Protocol commit electronic commerce

In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures. This document proposes a simple, easily-implemented protocol for achieving this end. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app tip 10.17487/RFC2371 RFC2372 Transaction Internet Protocol - Requirements and Supplemental Information K. Evans J. Klein J. Lyon July 1998 ASCII HTML 24 TIP commit protocol electronic commerce

This document describes the purpose (usage scenarios), and requirements for the Transaction Internet Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app tip 10.17487/RFC2372 RFC2373 IP Version 6 Addressing Architecture R. Hinden S. Deering July 1998 ASCII HTML 26 internet protocol unicast anycast multicast node

This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]

 RFC1884 RFC3513 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2373 10.17487/RFC2373 RFC2374 An IPv6 Aggregatable Global Unicast Address Format R. Hinden M. O'Dell S. Deering July 1998 ASCII HTML 12 IPv6 internet protocol address architecture routing

This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK]

 RFC2073 RFC3587 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2374 RFC2375 IPv6 Multicast Address Assignments R. Hinden S. Deering July 1998 ASCII HTML 8 internet protocol multicast scope value

This document defines the initial assignment of IPv6 multicast addresses. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2375 RFC2376 XML Media Types E. Whitehead M. Murata July 1998 ASCII HTML 15 extensible markup language web authority hypertext transfer protocol

This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC3023 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2376 RFC2377 Naming Plan for Internet Directory-Enabled Applications A. Grimstad R. Huber S. Sataluri M. Wahl September 1998 ASCII HTML 18 x.500 applications iwps white pages service

Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 RFC4519 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2377 RFC2378 The CCSO Nameserver (Ph) Architecture R. Hedberg P. Pomes September 1998 ASCII HTML 22 computing communications services office database

The Ph Nameserver from the Computing and Communications Services Office (CCSO), University of Illinois at Urbana-Champaign has for some time now been used by several organizations as their choice of publicly available database for information about people as well as other things. This document provides a formal definition of the client-server protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2378 RFC2379 RSVP over ATM Implementation Guidelines L. Berger August 1998 ASCII HTML 8 asynchronous transfer mode resource reservation protocol switched circuits

This memo presents specific implementation guidelines for running RSVP over ATM switched virtual circuits (SVCs). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0024 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv issll 10.17487/RFC2379 RFC2380 RSVP over ATM Implementation Requirements L. Berger August 1998 ASCII HTML 14 RSVP resource reservation protocol ATM asynchronous transfer mode switched circuits

This memo presents specific implementation requirements for running RSVP over ATM switched virtual circuits (SVCs). It presents requirements that ensure interoperability between multiple implementations and conformance to the RSVP and Integrated Services specifications. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2380 RFC2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM M. Garrett M. Borden August 1998 ASCII HTML 43 ATM asynchronous transfer mode mapping traffic parameters

This document provides guidelines for mapping service classes, and traffic management features and parameters between Internet and ATM technologies. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2381 RFC2382 A Framework for Integrated Services and RSVP over ATM E. Crawley Editor L. Berger S. Berson F. Baker M. Borden J. Krawczyk August 1998 ASCII HTML 30

This document outlines the issues and framework related to providing IP Integrated Services with RSVP over ATM. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2382 RFC2383 ST2+ over ATM Protocol Specification - UNI 3.1 Version M. Suzuki August 1998 ASCII HTML 50 asynchronous transfer mode stream resource reservation

This document specifies an ATM-based protocol for communication between ST2+ agents. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2383 RFC2384 POP URL Scheme R. Gellens August 1998 ASCII HTML 8 POP-URL post office protocol uniform resource locator identifier string encapsulation

This memo defines a URL scheme for referencing a POP mailbox. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2384 10.17487/RFC2384 RFC2385 Protection of BGP Sessions via the TCP MD5 Signature Option A. Heffernan August 1998 ASCII HTML 6 BGP border gateway protocol TCP transmission control protocol message digest algorithm

This memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK]

 RFC5925 RFC6691 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=2385 10.17487/RFC2385 RFC2386 A Framework for QoS-based Routing in the Internet E. Crawley R. Nair B. Rajagopalan H. Sandick August 1998 ASCII HTML 37 quality of service interdomain intradomain

This document describes some of the QoS-based routing issues and requirements, and proposes a framework for QoS-based routing in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF rtg qosr 10.17487/RFC2386 RFC2387 The MIME Multipart/Related Content-type E. Levinson August 1998 ASCII HTML 10 MIME-RELAT multipurpose internet mail extensions body parts media-type

This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]

 RFC2112 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml http://www.rfc-editor.org/errata_search.php?rfc=2387 10.17487/RFC2387 RFC2388 Returning Values from Forms: multipart/form-data L. Masinter August 1998 ASCII HTML 9 media-type MIME multipurpose internet mail extensions

This specification defines an Internet Media Type, multipart/form-data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. [STANDARDS-TRACK]

 RFC7578 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2388 10.17487/RFC2388 RFC2389 Feature negotiation mechanism for the File Transfer Protocol P. Hethmon R. Elz August 1998 ASCII HTML 9 FTP File Transfer Protocol catalogue

This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server. [STANDARDS-TRACK]

 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext 10.17487/RFC2389 RFC2390 Inverse Address Resolution Protocol T. Bradley C. Brown A. Malis September 1998 ASCII HTML 10 IARP Inverse Address Resolution Protocol hardware frame relay

This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]

 RFC1293 DRAFT STANDARD DRAFT STANDARD IETF int ion 10.17487/RFC2390 RFC2391 Load Sharing using IP Network Address Translation (LSNAT) P. Srisuresh D. Gan August 1998 ASCII HTML 18 internet protocol datagram server

In this document, we extend the use of NATs to offer Load share feature, where session load can be distributed across a pool of servers, instead of directing to a single server. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2391 10.17487/RFC2391 RFC2392 Content-ID and Message-ID Uniform Resource Locators E. Levinson August 1998 ASCII HTML 6 CIDMID-URL HTML Hypertext Markup Language URL Uniform Resource Locator MIME Multipurpose Internet Mail Extensions

The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK]

 RFC2111 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml http://www.rfc-editor.org/errata_search.php?rfc=2392 10.17487/RFC2392 RFC2393 IP Payload Compression Protocol (IPComp) A. Shacham R. Monsour R. Pereira M. Thomas December 1998 ASCII HTML 10 IPCOMP internet protocol datagram lossless

This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]

 RFC3173 PROPOSED STANDARD PROPOSED STANDARD IETF int ippcp 10.17487/RFC2393 RFC2394 IP Payload Compression Using DEFLATE R. Pereira December 1998 ASCII HTML 6 internet protocol algorithm datagram format

This document describes a compression method based on the DEFLATE compression algorithm. This document defines the application of the DEFLATE algorithm to the IP Payload Compression Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ippcp 10.17487/RFC2394 RFC2395 IP Payload Compression Using LZS R. Friend R. Monsour December 1998 ASCII HTML 9 internet protocol algorithm datagram lossless

This document describes a compression method based on the LZS compression algorithm. This document defines the application of the LZS algorithm to the IP Payload Compression Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 INFORMATIONAL INFORMATIONAL IETF int ippcp http://www.rfc-editor.org/errata_search.php?rfc=2395 10.17487/RFC2395 RFC2396 Uniform Resource Identifiers (URI): Generic Syntax T. Berners-Lee R. Fielding L. Masinter August 1998 ASCII HTML 40 URI-GEN characters string absolute relative

This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. [STANDARDS-TRACK]

 RFC3986 RFC1808 RFC1738 RFC2732 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2396 10.17487/RFC2396 RFC2397 The "data" URL scheme L. Masinter August 1998 ASCII HTML 5 DATA-URL uniform resource locator identifiers media type

A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2397 10.17487/RFC2397 RFC2398 Some Testing Tools for TCP Implementors S. Parker C. Schmechel August 1998 ASCII HTML 15 transmission control protocol catalogue

This document lists only tools which can evaluate one or more TCP implementations, or which can privde some specific results which describe or evaluate the TCP being tested. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

 FYI0033 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2398 RFC2399 Request for Comments Summary A. Ramos January 1999 ASCII HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2399 RFC2400 Internet Official Protocol Standards J. Postel J. Reynolds September 1998 ASCII HTML 47 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. [STANDARDS-TRACK]

 RFC2300 RFC2500 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2400 RFC2401 Security Architecture for the Internet Protocol S. Kent R. Atkinson November 1998 ASCII HTML 66 IPSEC ipsec authentication encapsulation IP IPv4 IPv6 IP-layer

This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK]

 RFC1825 RFC4301 RFC3168 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2401 RFC2402 IP Authentication Header S. Kent R. Atkinson November 1998 ASCII HTML 22 IP-AUTH ipsec Internet Protocol AH security IPv4 IPv6

The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. [STANDARDS-TRACK]

 RFC1826 RFC4302 RFC4305 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2402 10.17487/RFC2402 RFC2403 The Use of HMAC-MD5-96 within ESP and AH C. Madson R. Glenn November 1998 ASCII HTML 7 HMAC MD5 IPSEC Internet Protocol Security AH Authentication Header ESP Encapsulating Security Payload mechanism architecture

This memo describes the use of the HMAC algorithm in conjunction with the MD5 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload and the revised IPSEC Authentication Header. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2403 RFC2404 The Use of HMAC-SHA-1-96 within ESP and AH C. Madson R. Glenn November 1998 ASCII HTML 7 ipsec authentication mechanism header security architecture payload

This memo describes the use of the HMAC algorithm in conjunction with the SHA-1 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload and the revised IPSEC Authentication Header. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2404 RFC2405 The ESP DES-CBC Cipher Algorithm With Explicit IV C. Madson N. Doraswamy November 1998 ASCII HTML 10 ESPDES-CBC IPSEC Internet Protocol Security Encapsulating Security Payload architecture encryption

This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2405 RFC2406 IP Encapsulating Security Payload (ESP) S. Kent R. Atkinson November 1998 ASCII HTML 22 ESP ipsec internet protocol encapsulating security ipv4 ipv6

The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK]

 RFC1827 RFC4303 RFC4305 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2406 RFC2407 The Internet IP Security Domain of Interpretation for ISAKMP D. Piper November 1998 ASCII HTML 32 ISAKMPSEC ipsec internet protocol security association key management

This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. [STANDARDS-TRACK]

 RFC4306 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2407 10.17487/RFC2407 RFC2408 Internet Security Association and Key Management Protocol (ISAKMP) D. Maughan M. Schertler M. Schneider J. Turner November 1998 ASCII HTML 86 ISAKMP ipsec cryptography authentication

This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. [STANDARDS-TRACK]

 RFC4306 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2408 10.17487/RFC2408 RFC2409 The Internet Key Exchange (IKE) D. Harkins D. Carrel November 1998 ASCII HTML 41 IKE ipsec oakley authentication isakmp internet security key management

This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK]

 RFC4306 RFC4109 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2409 RFC2410 The NULL Encryption Algorithm and Its Use With IPsec R. Glenn S. Kent November 1998 ASCII HTML 6 ipsec internet protocol security esp encapsulating security payload NULL

This memo defines the NULL encryption algorithm and its use with the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2410 10.17487/RFC2410 RFC2411 IP Security Document Roadmap R. Thayer N. Doraswamy R. Glenn November 1998 ASCII HTML 11 ipsec internet protocol privacy authentication

This document is intended to provide guidelines for the development of collateral specifications describing the use of new encryption and authentication algorithms with the ESP protocol, described in and new authentication algorithms used with the AH protocol. This memo provides information for the Internet community.

 RFC6071 INFORMATIONAL INFORMATIONAL IETF sec ipsec 10.17487/RFC2411 RFC2412 The OAKLEY Key Determination Protocol H. Orman November 1998 ASCII HTML 55 ipsec authentication crytographic secure scalable

This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2412 10.17487/RFC2412 RFC2413 Dublin Core Metadata for Resource Discovery S. Weibel J. Kunze C. Lagoze M. Wolf September 1998 ASCII HTML 8 workshop electronic librarians network

This is the first of a set of Informational RFCs describing the Dublin Core. Its purpose is to introduce the Dublin Core and to describe the consensus reached on the semantics of each of the 15 elements. This memo provides information for the Internet community.

 RFC5013 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2413 RFC2414 Increasing TCP's Initial Window M. Allman S. Floyd C. Partridge September 1998 ASCII HTML 14 TCP-WIN transmission control protocol

This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes. This memo defines an Experimental Protocol for the Internet community.

 RFC3390 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpimpl 10.17487/RFC2414 RFC2415 Simulation Studies of Increased Initial TCP Window Size K. Poduri K. Nichols September 1998 ASCII HTML 11 transmission control protocol file transfer

This document covers some simulation studies of the effects of increasing the initial window size of TCP. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2415 RFC2416 When TCP Starts Up With Four Packets Into Only Three Buffers T. Shepard C. Partridge September 1998 ASCII HTML 7 transmission control protocol performance

This memo is to document a simple experiment. The experiment showed that in the case of a TCP receiver behind a 9600 bps modem link at the edge of a fast Internet where there are only 3 buffers before the modem (and the fourth packet of a four-packet start will surely be dropped), no significant degradation in performance is experienced by a TCP sending with a four-packet start when compared with a normal slow start (which starts with just one packet). This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2416 RFC2417 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks C. Chung M. Greene September 1998 ASCII HTML 76 MIB management information base ATM asynchronous transfer mode

This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. [STANDARDS-TRACK]

 RFC2366 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2417 10.17487/RFC2417 RFC2418 IETF Working Group Guidelines and Procedures S. Bradner September 1998 ASCII HTML 26 BCP WG escape clause procedures

This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC1603 RFC3934 RFC7475 RFC7776 RFC8717 RFC9141 BCP0025 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson http://www.rfc-editor.org/errata_search.php?rfc=2418 10.17487/RFC2418 RFC2419 The PPP DES Encryption Protocol, Version 2 (DESE-bis) K. Sklower G. Meyer September 1998 ASCII HTML 12 DESE-bis PPP point-to-point protocol DES Encryption Protocol ECP PPP Encryption Control Protocol

This document provides specific details for the use of the DES standard for encrypting PPP encapsulated packets. [STANDARDS-TRACK]

 RFC1969 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2419 RFC2420 The PPP Triple-DES Encryption Protocol (3DESE) H. Kummert September 1998 ASCII HTML 8 3DESE PPP Triple-DES Encryption Protocol point-to-point protocol ecp PPP Encryption Control Protocol

This document provides specific details for the use of the Triple-DES standard (3DES) for encrypting PPP encapsulated packets. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2420 RFC2421 Voice Profile for Internet Mail - version 2 G. Vaudreuil G. Parsons September 1998 ASCII HTML 56 MIME-VP2 vpim messaging

This document profiles Internet mail for voice messaging. [STANDARDS-TRACK]

 RFC1911 RFC3801 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2421 10.17487/RFC2421 RFC2422 Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration G. Vaudreuil G. Parsons September 1998 ASCII HTML 6 MIME-ADPCM multipurpose internet mail extensions audio

This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK]

 RFC1911 RFC3802 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2422 RFC2423 VPIM Voice Message MIME Sub-type Registration G. Vaudreuil G. Parsons September 1998 ASCII HTML 6 MIME-VPIM multipurpose internet mail extensions Voice Profile for Internet Mail

This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). [STANDARDS-TRACK]

 RFC1911 RFC3801 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2423 RFC2424 Content Duration MIME Header Definition G. Vaudreuil G. Parsons September 1998 ASCII HTML 4 CONT-DUR multipurpose internet mail extensions time media

This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK]

 RFC3803 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2424 RFC2425 A MIME Content-Type for Directory Information T. Howes M. Smith F. Dawson September 1998 ASCII HTML 33 TXT-DIR MIME multipurpose internet mail extensions profiles

This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK]

 RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2425 RFC2426 vCard MIME Directory Profile F. Dawson T. Howes September 1998 ASCII HTML 42 MIME-VCARD multipurpose internet mail extensions white-pages electronic business card

This memo defines the profile of the MIME Content-Type for directory information for a white-pages person object, based on a vCard electronic business card. [STANDARDS-TRACK]

 RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2426 10.17487/RFC2426 RFC2427 Multiprotocol Interconnect over Frame Relay C. Brown A. Malis September 1998 ASCII HTML 34 IP-FR Internet Protocol Frame Relay bridging routing

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]

 RFC1490 RFC1294 STD0055 INTERNET STANDARD INTERNET STANDARD IETF int ion 10.17487/RFC2427 RFC2428 FTP Extensions for IPv6 and NATs M. Allman S. Ostermann C. Metz September 1998 ASCII HTML 8 FTP file transfer protocol IPv6 internet protocol version 6 NATs network address translators extensions

This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext http://www.rfc-editor.org/errata_search.php?rfc=2428 10.17487/RFC2428 RFC2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) C. Bormann L. Cline G. Deisher T. Gardos C. Maciocco D. Newell J. Ott G. Sullivan S. Wenger C. Zhu October 1998 ASCII HTML 17 real time transport protocol multicast unicast

This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263. [STANDARDS-TRACK]

 RFC4629 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2429 RFC2430 A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) T. Li Y. Rekhter October 1998 ASCII HTML 16 isp internet service provider packet flow multiprotocol label switching mpls resource reservation protocol rsvp

This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs). This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2430 RFC2431 RTP Payload Format for BT.656 Video Encoding D. Tynan October 1998 ASCII HTML 10 RTP real-time transport protocol ITU International Telecommunication Union multicast unicast

This document specifies the RTP payload format for encapsulating ITU Recommendation BT.656-3 video streams in the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2431 RFC2432 Terminology for IP Multicast Benchmarking K. Dubray October 1998 ASCII HTML 16 internet protocol network forwarding devices

The purpose of this document is to define terminology specific to the benchmarking of multicast IP forwarding devices. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2432 RFC2433 Microsoft PPP CHAP Extensions G. Zorn S. Cobb October 1998 ASCII HTML 20 point to point protocol challenge handshake authentication

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2433 RFC2434 Guidelines for Writing an IANA Considerations Section in RFCs T. Narten H. Alvestrand October 1998 ASCII HTML 11 internet assigned numbers authority values implementations

This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC5226 RFC3692 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC2434 RFC2435 RTP Payload Format for JPEG-compressed Video L. Berc W. Fenner R. Frederick S. McCanne P. Stewart October 1998 ASCII HTML 27 RTP Real-Time Transport Protocol JPEG Joint Photographic Experts Group

This memo describes the RTP payload format for JPEG video streams. [STANDARDS-TRACK]

 RFC2035 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=2435 10.17487/RFC2435 RFC2436 Collaboration between ISOC/IETF and ITU-T R. Brett S. Bradner G. Parsons October 1998 ASCII HTML 14 internet society engineering task force

This document describes the collaboration process between the ITU-T and ISOC/IETF. This memo provides information for the Internet community.

 RFC3356 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2436 RFC2437 PKCS #1: RSA Cryptography Specifications Version 2.0 B. Kaliski J. Staddon October 1998 ASCII HTML 39 data public key cryptosystem

This memo is the successor to RFC 2313. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm. This memo provides information for the Internet community.

 RFC2313 RFC3447 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2437 RFC2438 Advancement of MIB specifications on the IETF Standards Track M. O'Dell H. Alvestrand B. Wijnen S. Bradner October 1998 ASCII HTML 7 management information base internet engineering task force

This document specifies the process which the IESG will use to determine if a MIB specification document meets these requirements. It also discusses the rationale for this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0027 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC2438 RFC2439 BGP Route Flap Damping C. Villamizar R. Chandra R. Govindan November 1998 ASCII HTML 37 BGP Border Gateway Protocol IDRP Internet-Domain Routing Protocol

A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=2439 10.17487/RFC2439 RFC2440 OpenPGP Message Format J. Callas L. Donnerhacke H. Finney R. Thayer November 1998 ASCII HTML 65 PGP pretty good privacy encryption authentication

This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. [STANDARDS-TRACK]

 RFC4880 PROPOSED STANDARD PROPOSED STANDARD IETF sec openpgp 10.17487/RFC2440 RFC2441 Working with Jon, Tribute delivered at UCLA, October 30, 1998 D. Cohen November 1998 ASCII HTML 6 Jonathan B Postel

This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2441 RFC2442 The Batch SMTP Media Type N. Freed D. Newman J. Belissent M. Hoy November 1998 ASCII HTML 9 simple transfer protocol mime multipurpose internet mail extensions tunneling

This document defines a MIME content type suitable for tunneling an ESMTP transaction through any MIME-capable transport. This memo provides information for the Internet community

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2442 RFC2443 A Distributed MARS Service Using SCSP J. Luciani A. Gallo November 1998 ASCII HTML 18 MARS-SCSP server cache synchronization protocol ATM asynchronous transfer mode

This document describes a method for distributing a MARS service within a LIS. This method uses the Server Cache Synchronization Protocol (SCSP) to synchronize the MARS Server databases within a LIS. When SCSP is used to synchronize the caches of MARS Servers in a LIS, the LIS defines the boundary of an SCSP Server Group (SG). [STANDARDS-TRACK]

 EXPERIMENTAL EXPERIMENTAL IETF int ion 10.17487/RFC2443 RFC2444 The One-Time-Password SASL Mechanism C. Newman October 1998 ASCII HTML 7 OTP-SASL One-Time Password simple authentication security layer

OTP provides a useful authentication mechanism for situations where there is limited client or server trust. Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing. This specification defines an OTP SASL mechanism so it can be easily and formally integrated into many application protocols. [STANDARDS-TRACK]

 RFC2222 PROPOSED STANDARD PROPOSED STANDARD IETF sec otp 10.17487/RFC2444 RFC2445 Internet Calendaring and Scheduling Core Object Specification (iCalendar) F. Dawson D. Stenerson November 1998 ASCII HTML 148 ICALENDAR interoperable mime multipurpose internet mail extensions

This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. [STANDARDS-TRACK]

 RFC5545 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch http://www.rfc-editor.org/errata_search.php?rfc=2445 10.17487/RFC2445 RFC2446 iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries S. Silverberg S. Mansour F. Dawson R. Hopson November 1998 ASCII HTML 109 ITIP iCalendar Transport-Independent Interoperability Protocol internet systems

This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems. [STANDARDS-TRACK]

 RFC5546 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch http://www.rfc-editor.org/errata_search.php?rfc=2446 10.17487/RFC2446 RFC2447 iCalendar Message-Based Interoperability Protocol (iMIP) F. Dawson S. Mansour S. Silverberg November 1998 ASCII HTML 18 IMIP iCalendar Message-Based Interoperability Protocol internet electronic mail transport

This document specifies a binding from the iCalendar Transport- independent Interoperability Protocol (iTIP) to Internet email-based transports. [STANDARDS-TRACK]

 RFC6047 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch 10.17487/RFC2447 RFC2448 AT&T's Error Resilient Video Transmission Technique M. Civanlar G. Cash B. Haskell November 1998 ASCII HTML 7 packets network bitstreams

This document describes a set of techniques for packet loss resilient transmission of compressed video bitstreams based on reliable delivery of their vital information-carrying segments. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2448 RFC2449 POP3 Extension Mechanism R. Gellens C. Newman L. Lundblade November 1998 ASCII HTML 19 POP3-EXT post office protocol server extension

This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK]

 RFC1939 RFC5034 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2449 RFC2450 Proposed TLA and NLA Assignment Rule R. Hinden December 1998 ASCII HTML 11 top-level aggregation identifiers next-level ipv6 internet protocols addresses

This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID). This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2450 RFC2451 The ESP CBC-Mode Cipher Algorithms R. Pereira R. Adams November 1998 ASCII HTML 14 ESP encapsulating security payload ipsec Internet Protocol Security

This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2451 RFC2452 IP Version 6 Management Information Base for the Transmission Control Protocol M. Daniele December 1998 ASCII HTML 10 mib internet protocol tcp ipv6

This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the Transmission Control Protocol (TCP) over IP Version 6 (IPv6). [STANDARDS-TRACK]

 RFC4022 RFC8096 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2452 RFC2453 RIP Version 2 G. Malkin November 1998 ASCII HTML 39 RIP2 RIP-2 Routing Information Protocol

This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP messages and to add a measure of security. [STANDARDS-TRACK]

 RFC1723 RFC4822 STD0056 INTERNET STANDARD INTERNET STANDARD IETF rtg ripv2 http://www.rfc-editor.org/errata_search.php?rfc=2453 10.17487/RFC2453 RFC2454 IP Version 6 Management Information Base for the User Datagram Protocol M. Daniele December 1998 ASCII HTML 9 MIB management information base ipv6 internet protocol UDP User Datagram Protocol

This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). [STANDARDS-TRACK]

 RFC4113 RFC8096 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2454 RFC2455 Definitions of Managed Objects for APPN B. Clouston B. Moore November 1998 ASCII HTML 140 APPN-MIB Advanced Peer-to-Peer Networking MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS-TRACK]

 RFC2155 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2455 RFC2456 Definitions of Managed Objects for APPN TRAPS B. Clouston B. Moore November 1998 ASCII HTML 21 MIB management information base APPN advanced peer-to-peer networking

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for receiving notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR (Dependent LU Requester) capabilities. This memo identifies notifications for the APPN and DLUR architecture. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2456 RFC2457 Definitions of Managed Objects for Extended Border Node B. Clouston B. Moore November 1998 ASCII HTML 28 EBN-MIB Extended Border Node management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Network) EBN (Extended Border Node) capabilities. This memo identifies managed objects for the EBN architecture. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2457 RFC2458 Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations H. Lu M. Krishnaswamy L. Conroy S. Bellovin F. Burg A. DeSimone K. Tewani P. Davidson H. Schulzrinne K. Vishwanathan November 1998 ASCII HTML 60

This document contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF tsv pint 10.17487/RFC2458 RFC2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile R. Housley W. Ford W. Polk D. Solo January 1999 ASCII HTML 129 digital signatures encryption authentication

This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. [STANDARDS-TRACK]

 RFC3280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2459 10.17487/RFC2459 RFC2460 Internet Protocol, Version 6 (IPv6) Specification S. Deering R. Hinden December 1998 ASCII HTML 39 IPV6 internet protocol next generation ipng

This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]

 draft-ietf-ipngwg-ipv6-spec-v2-02 RFC1883 RFC8200 RFC5095 RFC5722 RFC5871 RFC6437 RFC6564 RFC6935 RFC6946 RFC7045 RFC7112 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2460 10.17487/RFC2460 RFC2461 Neighbor Discovery for IP Version 6 (IPv6) T. Narten E. Nordmark W. Simpson December 1998 ASCII HTML 93 IPV6-ND internet protocol link-layer

This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]

 RFC1970 RFC4861 RFC4311 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg 10.17487/RFC2461 RFC2462 IPv6 Stateless Address Autoconfiguration S. Thomson T. Narten December 1998 ASCII HTML 25 IPV6-AUTO internet protocol host link-local

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]

 RFC1971 RFC4862 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2462 10.17487/RFC2462 RFC2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification A. Conta S. Deering December 1998 ASCII HTML 18 ICMPv6 Internet Control Message Protocol link-local autoconfigured addresses

This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]

 RFC1885 RFC4443 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg 10.17487/RFC2463 RFC2464 Transmission of IPv6 Packets over Ethernet Networks M. Crawford December 1998 ASCII HTML 7 IPv6 internet protocol link-local autoconfigured addresses

This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK]

 RFC1972 RFC6085 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2464 10.17487/RFC2464 RFC2465 Management Information Base for IP Version 6: Textual Conventions and General Group D. Haskin S. Onishi December 1998 ASCII HTML 38 mib internet protocol ipv6

This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. [STANDARDS-TRACK]

 RFC4293 RFC8096 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2465 RFC2466 Management Information Base for IP Version 6: ICMPv6 Group D. Haskin S. Onishi December 1998 ASCII HTML 16 ICMPv6-MIB mib internet protocol ipv6

This document is one in the series of documents that define various MIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document. [STANDARDS-TRACK]

 RFC4293 RFC8096 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2466 RFC2467 Transmission of IPv6 Packets over FDDI Networks M. Crawford December 1998 ASCII HTML 9 IPv6 internet protocol link-local addresses autoconfiguration FDDI Fiber Distributed Data Interface

This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. [STANDARDS-TRACK]

 RFC2019 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2467 RFC2468 I REMEMBER IANA V. Cerf October 1998 ASCII HTML 4 jonathan b postel

A long time ago, in a network, far far away, a great adventure took place!. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2468 RFC2469 A Caution On The Canonical Ordering Of Link-Layer Addresses T. Narten C. Burton December 1998 ASCII HTML 5 address resolution protocol data fields

Protocols such as ARP and Neighbor Discovery have data fields that contain link-layer addresses. In order to interoperate properly, a sender setting such a field must insure that the receiver extracts those bits and interprets them correctly. In most cases, such fields must be in "canonical form". Unfortunately, not all LAN adaptors are consistent in their use of canonical form, and implementations may need to explicitly bit swap individual bytes in order to obtain the correct format. This document provides information to implementors to help them avoid the pitfall of using non-canonical forms when canonical forms are required. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2469 RFC2470 Transmission of IPv6 Packets over Token Ring Networks M. Crawford T. Narten S. Thomas December 1998 ASCII HTML 11 IPv6 internet protocol frame format link-local addresses

This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK]

 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2470 RFC2471 IPv6 Testing Address Allocation R. Hinden R. Fink J. Postel December 1998 ASCII HTML 5 IPv6 internet protocol protocol type software architecture

This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This memo defines an Experimental Protocol for the Internet community.

 RFC1897 RFC3701 HISTORIC EXPERIMENTAL IETF int ipngwg 10.17487/RFC2471 RFC2472 IP Version 6 over PPP D. Haskin E. Allen December 1998 ASCII HTML 14 IPv6-PPP internet protocol point-to-point ipv6

This document defines the method for transmission of IP Version 6 packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. [STANDARDS-TRACK]

 draft-ietf-ipngwg-ipv6-over-ppp-06 RFC2023 RFC5072 RFC5172 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2472 RFC2473 Generic Packet Tunneling in IPv6 Specification A. Conta S. Deering December 1998 ASCII HTML 36 IPv6 internet protocol encapsulation

This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2473 RFC2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers K. Nichols S. Blake F. Baker D. Black December 1998 ASCII HTML 20 internet protocol network nodes

This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK]

 RFC1455 RFC1349 RFC0791 RFC3168 RFC3260 RFC8436 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=2474 10.17487/RFC2474 RFC2475 An Architecture for Differentiated Services S. Blake D. Black M. Carlson E. Davies Z. Wang W. Weiss December 1998 ASCII HTML 36 DIFFSRV Differentiated Services scalability IP internet protocol architecture

This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community.

 RFC3260 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC2475 RFC2476 Message Submission R. Gellens J. Klensin December 1998 ASCII HTML 15 SMTP simple mail transfer protocol user agent

This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server. [STANDARDS-TRACK]

 RFC4409 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2476 RFC2477 Criteria for Evaluating Roaming Protocols B. Aboba G. Zorn January 1999 ASCII HTML 12 ISP internet service providers operations

This document describes requirements for the provisioning of "roaming capability" for dialup Internet users. "Roaming capability" is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF ops roamops 10.17487/RFC2477 RFC2478 The Simple and Protected GSS-API Negotiation Mechanism E. Baize D. Pinkas December 1998 ASCII HTML 18 generic service application security program interface

This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API). [STANDARDS-TRACK]

 RFC4178 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2478 RFC2479 Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API) C. Adams December 1998 ASCII HTML 70 data unit authentication

The IDUP-GSS-API extends the GSS-API for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated "receivers" of the data unit. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF sec cat 10.17487/RFC2479 RFC2480 Gateways and MIME Security Multiparts N. Freed January 1999 ASCII HTML 6 MIME multipurpose internet mail extensions

This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2480 RFC2481 A Proposal to add Explicit Congestion Notification (ECN) to IP K. Ramakrishnan S. Floyd January 1999 ASCII HTML 25 ECN-IP internet protocol tcp transmission control transport

This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. This memo defines an Experimental Protocol for the Internet community.

 RFC3168 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2481 RFC2482 Language Tagging in Unicode Plain Text K. Whistler G. Adams January 1999 ASCII HTML 14 characters strings ASCII

This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community.

 RFC6082 HISTORIC INFORMATIONAL Legacy 10.17487/RFC2482 RFC2483 URI Resolution Services Necessary for URN Resolution M. Mealling R. Daniel January 1999 ASCII HTML 16 URI uniform resource identifier URN uniform resource names locators characteristics

Retrieving the resource identified by a Uniform Resource Identifier (URI) is only one of the operations that can be performed on a URI. One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example. This applies to both Uniform Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers. This memo defines an Experimental Protocol for the Internet community.

 EXPERIMENTAL EXPERIMENTAL IETF app urn 10.17487/RFC2483 RFC2484 PPP LCP Internationalization Configuration Option G. Zorn January 1999 ASCII HTML 5 PPP point-to-point protocol LCP Link Control Protocol authentication

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. [STANDARDS-TRACK]

 RFC2284 RFC1994 RFC1570 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2484 RFC2485 DHCP Option for The Open Group's User Authentication Protocol S. Drach January 1999 ASCII HTML 4 DHCP dynamic host configuration protocol UAP User Authentication Protocol

This document defines a DHCP option that contains a list of pointers to User Authentication Protocol servers that provide user authentication services for clients that conform to The Open Group Network Computing Client Technical Standard. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2485 RFC2486 The Network Access Identifier B. Aboba M. Beadles January 1999 ASCII HTML 8 NAI tunneling roaming

This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. [STANDARDS-TRACK]

 RFC4282 PROPOSED STANDARD PROPOSED STANDARD IETF ops roamops http://www.rfc-editor.org/errata_search.php?rfc=2486 10.17487/RFC2486 RFC2487 SMTP Service Extension for Secure SMTP over TLS P. Hoffman January 1999 ASCII HTML 8 simple mail transfer protocol transport layer security ssl

This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]

 RFC3207 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2487 RFC2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms M. Allman D. Glover L. Sanchez January 1999 ASCII HTML 19 transmission control protocol network

The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 BCP0028 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tcpsat http://www.rfc-editor.org/errata_search.php?rfc=2488 10.17487/RFC2488 RFC2489 Procedure for Defining New DHCP Options R. Droms January 1999 ASCII HTML 5 mutipurpose internet mail extensions

This document describes the procedure for defining new DHCP options. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC2939 BCP0029 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2489 10.17487/RFC2489 RFC2490 A Simulation Model for IP Multicast with RSVP M. Pullen R. Malghan L. Lavu G. Duan J. Ma H. Nah January 1999 ASCII PS PDF HTML 31 internet protocol resource reservation ipv4

This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package, with protocol procedures defined in the C language. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2490 RFC2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks G. Armitage P. Schulter M. Jork G. Harter January 1999 ASCII HTML 44 IPv6-NBMA internet protocol Non-Broadcast Multiple Access routing host

This document describes a general architecture for IPv6 over NBMA networks. [STANDARDS-TRACK]

 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2491 RFC2492 IPv6 over ATM Networks G. Armitage P. Schulter M. Jork January 1999 ASCII HTML 12 IPv6ATMNET internet protocol ATM asynchronous transfer mode host

This document is a companion to the ION working group's architecture document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks". It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths (when using SVCs). Operation over administratively configured Point to Point PVCs is also supported. [STANDARDS-TRACK]

 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ion http://www.rfc-editor.org/errata_search.php?rfc=2492 10.17487/RFC2492 RFC2493 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals K. Tesink Editor January 1999 ASCII HTML 9 management information base data

This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals. [STANDARDS-TRACK]

 RFC3593 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2493 RFC2494 Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type D. Fowler Editor January 1999 ASCII HTML 25 MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS0 and DS0 Bundle interfaces. This document is a companion document with Definitions of Managed Objects for the DS1/E1/DS2/E2 (RFC 2495), DS3/E3 (RFC 2496), and the work in progress, SONET/SDH Interface Types. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC2494 RFC2495 Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types D. Fowler Editor January 1999 ASCII HTML 75 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494), DS3/E3 (RFC 2496), and the work in progress, SONET/SDH Interface Types. [STANDARDS-TRACK]

 RFC1406 RFC3895 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC2495 RFC2496 Definitions of Managed Object for the DS3/E3 Interface Type D. Fowler Editor January 1999 ASCII HTML 60 DS3-E3-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494), DS1/E1/DS2/E2 (RFC 2495), and the work in progress SONET/SDH Interface Types. [STANDARDS-TRACK]

 RFC1407 RFC3896 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC2496 RFC2497 Transmission of IPv6 Packets over ARCnet Networks I. Souvatzis January 1999 ASCII HTML 6 IPv6 internet protocol frame format link-local

This memo specifies a frame format for transmission of IPv6 packets and the method of forming IPv6 link-local and statelessly autoconfigured addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in, when those messages are transmitted on an ARCnet. [STANDARDS-TRACK]

 draft-souvatzis-ipv6-arcnet-05 RFC8064 RFC1201 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2497 RFC2498 IPPM Metrics for Measuring Connectivity J. Mahdavi V. Paxson January 1999 ASCII HTML 10 IPPM-MET internet protocol performance metrics

This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. This memo defines an Experimental Protocol for the Internet community.

 RFC2678 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2498 RFC2499 Request for Comments Summary A. Ramos July 1999 ASCII HTML 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2499 RFC2500 Internet Official Protocol Standards J. Reynolds R. Braden June 1999 ASCII HTML 28 IAB official protocol standards

This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK]

 RFC2400 RFC2600 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2500 RFC2501 Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations S. Corson J. Macker January 1999 ASCII HTML 12 MANET packet network hardwire wireless

This memo first describes the characteristics of Mobile Ad hoc Networks (MANETs), and their idiosyncrasies with respect to traditional, hardwired packet networks. It then discusses the effect these differences have on the design and evaluation of network control protocols with an emphasis on routing performance evaluation considerations. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF rtg manet 10.17487/RFC2501 RFC2502 Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment M. Pullen M. Myjak C. Bouwens February 1999 ASCII HTML 11 IP DIS distributed applications

This memo defines services that LSMA has found to be required, and aspects of the Internet protocols that LSMA has found to need further development in order to meet these requirements. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF app lsma 10.17487/RFC2502 RFC2503 MIME Types for Use with the ISO ILL Protocol R. Moulton M. Needleman February 1999 ASCII HTML 6 multipurpose mail internet extensions media type interlibrary loan

This memorandum describes a set of MIME types for use with the ISO Interlibrary Loan Protocol (ISO 10160/10161). This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2503 RFC2504 Users' Security Handbook E. Guttman L. Leong G. Malkin February 1999 ASCII HTML 33 encryption networks systems

The Users' Security Handbook is the companion to the Site Security Handbook (SSH). It is intended to provide users with the information they need to help keep their networks and systems secure. This memo provides information for the Internet community.

 FYI0034 INFORMATIONAL INFORMATIONAL IETF ssh 10.17487/RFC2504 RFC2505 Anti-Spam Recommendations for SMTP MTAs G. Lindberg February 1999 ASCII HTML 24 simple mail transfer protocol agents sendmail

This memo gives a number of implementation recommendations for SMTP, MTAs (Mail Transfer Agents, e.g. sendmail,) to make them more capable of reducing the impact of spam. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-lindberg-anti-spam-mta-08 BCP0030 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2505 RFC2506 Media Feature Tag Registration Procedure K. Holtman A. Mutz T. Hardie March 1999 ASCII HTML 12 data formats vocabulary negotiation mechanism

This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-conneg-feature-reg-03 BCP0031 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app conneg 10.17487/RFC2506 RFC2507 IP Header Compression M. Degermark B. Nordgren S. Pink February 1999 ASCII HTML 47 IP internet protocol tcp transmission control protocol bandwidth

This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2507 RFC2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links S. Casner V. Jacobson February 1999 ASCII HTML 24 IP internet protocol UDP user datagram protocol RTP real-time transport protocol interoperability

This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2508 RFC2509 IP Header Compression over PPP M. Engan S. Casner C. Bormann February 1999 ASCII HTML 10 IPCOM-PPP internet protocol point-to-point datagrams

This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol. It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS-TRACK]

 RFC3544 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2509 RFC2510 Internet X.509 Public Key Infrastructure Certificate Management Protocols C. Adams S. Farrell March 1999 ASCII HTML 72 PKICMP pki security cryptographic authentication

This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. [STANDARDS-TRACK]

 draft-ietf-pkix-ipki3cmp-09 RFC4210 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2510 RFC2511 Internet X.509 Certificate Request Message Format M. Myers C. Adams D. Solo D. Kemp March 1999 ASCII HTML 25 X.509-CRMF crmf security encryption authenticaion

This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK]

 draft-ietf-pkix-crmf-01 RFC4211 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2511 RFC2512 Accounting Information for ATM Networks K. McCloghrie J. Heinanen W. Greene A. Prasad February 1999 ASCII HTML 15 mib management information base ATM autonomous transfer mode

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. [STANDARDS-TRACK]

 draft-ietf-atommib-atmacct-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2512 RFC2513 Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks K. McCloghrie J. Heinanen W. Greene A. Prasad February 1999 ASCII HTML 29 mib management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for controlling the collection and storage of accounting information for connection-oriented networks such as ATM. [STANDARDS-TRACK]

 draft-ietf-atommib-acct-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2513 RFC2514 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management M. Noto E. Spiegel K. Tesink February 1999 ASCII HTML 20 ATM-TC-OID asynchronous transfer mode MIB management information base

This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]

 draft-ietf-atommib-atm2TC-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2514 RFC2515 Definitions of Managed Objects for ATM Management K. Tesink Editor February 1999 ASCII HTML 87 ATM-MIBMAN asynchronous transfer mode MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]

 draft-ietf-atommib-atm1ng-06 RFC1695 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2515 RFC2516 A Method for Transmitting PPP Over Ethernet (PPPoE) L. Mamakos K. Lidl J. Evarts D. Carrel D. Simone R. Wheeler February 1999 ASCII HTML 17 PPPOE point-to-point protocol link control network layer

This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2516 10.17487/RFC2516 RFC2517 Building Directories from DNS: Experiences from WWWSeeker R. Moats R. Huber February 1999 ASCII HTML 7 domain name system internet world wide web

This memo discusses lessons that were learned during InterNIC Directory and Database Services' development and operation of WWWSeeker, an application that finds a web site given information about the name and location of an organization. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2517 RFC2518 HTTP Extensions for Distributed Authoring -- WEBDAV Y. Goland E. Whitehead A. Faizi S. Carter D. Jensen February 1999 ASCII HTML 94 WEBDAV hypertext transfer protocol web content

This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). [STANDARDS-TRACK]

 RFC4918 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav http://www.rfc-editor.org/errata_search.php?rfc=2518 10.17487/RFC2518 RFC2519 A Framework for Inter-Domain Route Aggregation E. Chen J. Stewart February 1999 ASCII HTML 13 IDRA bgp border gateway protocol address ip internet

This document presents a framework for inter-domain route aggregation and shows an example router configuration which 'implements' this framework. This memo provides information for the Internet community

 draft-ietf-idr-aggregation-framework-04 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC2519 RFC2520 NHRP with Mobile NHCs J. Luciani H. Suzuki N. Doraswamy D. Horton February 1999 ASCII HTML 8 NHRP-MNHCS next hop resolution protocol authentication extension

is document describes an extension to NHRP which would allow Mobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ion-nhrp-mobile-nhc-01 EXPERIMENTAL EXPERIMENTAL IETF int ion 10.17487/RFC2520 RFC2521 ICMP Security Failures Messages P. Karn W. Simpson March 1999 ASCII HTML 9 ICMP-SEC internet control message protocol ip security

This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP). This document defines an Experimental Protocol for the Internet community.

 draft-simpson-icmp-ipsec-fail-02 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2521 RFC2522 Photuris: Session-Key Management Protocol P. Karn W. Simpson March 1999 ASCII HTML 80 PHOTURIS-S ip internet protocol ah esp encapsulating security payload

This document defines the basic protocol mechanisms. This document defines an Experimental Protocol for the Internet community.

 draft-simpson-photuris-18 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2522 RFC2523 Photuris: Extended Schemes and Attributes P. Karn W. Simpson March 1999 ASCII HTML 21 PHOTURIS-E ip internet protocol security

Photuris is a session-key management protocol. Extensible Exchange- Schemes are provided to enable future implementation changes without affecting the basic protocol. This document defines an Experimental Protocol for the Internet community.

 draft-simpson-photuris-schemes-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2523 RFC2524 Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3 M. Banan February 1999 ASCII HTML 83 EMSD wireless IP internet protocol

This specification narrowly focuses on submission and delivery of short mail messages with a clear emphasis on efficiency. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2524 RFC2525 Known TCP Implementation Problems V. Paxson M. Allman S. Dawson W. Fenner J. Griner I. Heavens K. Lahey J. Semke B. Volz March 1999 ASCII HTML 61 transmission control protocol

This memo catalogs a number of known TCP implementation problems. This memo provides information for the Internet community.

 draft-ietf-tcpimpl-prob-05 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2525 RFC2526 Reserved IPv6 Subnet Anycast Addresses D. Johnson S. Deering March 1999 ASCII HTML 7 IPv6 internet protocol routing architecture

This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses. [STANDARDS-TRACK]

 draft-ietf-ipngwg-resv-anycast-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2526 RFC2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework S. Chokhani W. Ford March 1999 ASCII HTML 45 pkix encryption security authentication

This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement. This memo provides information for the Internet community.

 draft-ietf-pkix-ipki-part4-03 RFC3647 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2527 10.17487/RFC2527 RFC2528 Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates R. Housley W. Polk March 1999 ASCII HTML 9 security authentication cryptology

This specification contains guidance on the use of the Internet Public Key Infrastructure certificates to convey Key Exchange Algorithm (KEA) keys. This memo provides information for the Internet community.

 draft-ietf-pkix-ipki-kea-02 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC2528 RFC2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels B. Carpenter C. Jung March 1999 ASCII HTML 10 IPv6 link-local link local addresses internet protocol ip

This memo specifies the frame format for transmission of IPv6 (IPV6) packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network. [STANDARDS-TRACK]

 draft-ietf-ipngwg-6over4-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2529 RFC2530 Indicating Supported Media Features Using Extensions to DSN and MDN D. Wing March 1999 ASCII HTML 5 DSN MDN message disposition notification delivery status notification

This memo describes a format for generating Message Disposition Notifications and Delivery Status Notifications which contain such information. [STANDARDS-TRACK]

 draft-ietf-fax-reporting-extensions-05 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2530 RFC2531 Content Feature Schema for Internet Fax G. Klyne L. McIntyre March 1999 ASCII HTML 51 media features mechanism

This document defines a content feature schema that is a profile of the media feature registration mechanisms for use in performing capability identification between extended Internet fax systems. [STANDARDS-TRACK]

 draft-ietf-fax-feature-schema-05 RFC2879 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2531 RFC2532 Extended Facsimile Using Internet Mail L. Masinter D. Wing March 1999 ASCII HTML 12 mail user fax

This document describes extensions to "Simple Mode of Facsimile Using Internet Mail", and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing. [STANDARDS-TRACK]

 draft-ietf-fax-eifax-12 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2532 RFC2533 A Syntax for Describing Media Feature Sets G. Klyne March 1999 ASCII HTML 37 message senders recipients file format

This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. [STANDARDS-TRACK]

 draft-ietf-conneg-feature-syntax-04 RFC2738 RFC2938 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2533 RFC2534 Media Features for Display, Print, and Fax L. Masinter D. Wing A. Mutz K. Holtman March 1999 ASCII HTML 9 data format vocabulary negotiation mechanisms

This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications. [STANDARDS-TRACK]

 draft-ietf-conneg-media-features-05 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2534 RFC2535 Domain Name System Security Extensions D. Eastlake 3rd March 1999 ASCII HTML 47 DNS-SECEXT dns authentication

This document incorporates feedback on RFC 2065 from early implementers and potential users. [STANDARDS-TRACK]

 draft-ietf-dnssec-secext2-07 RFC2065 RFC4033 RFC4034 RFC4035 RFC2181 RFC1035 RFC1034 RFC2931 RFC3007 RFC3008 RFC3090 RFC3226 RFC3445 RFC3597 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec http://www.rfc-editor.org/errata_search.php?rfc=2535 10.17487/RFC2535 RFC2536 DSA KEYs and SIGs in the Domain Name System (DNS) D. Eastlake 3rd March 1999 ASCII HTML 6 DSA digital signature algorithm signatures cryptology

A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK]

 draft-ietf-dnssec-dss-03 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2536 RFC2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) D. Eastlake 3rd March 1999 ASCII HTML 6 message digest signatures cryptology security

A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK]

 draft-ietf-dnssec-rsa-01 RFC3110 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2537 RFC2538 Storing Certificates in the Domain Name System (DNS) D. Eastlake 3rd O. Gudmundsson March 1999 ASCII HTML 10 SC-DNS cryptology authenticity

Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [STANDARDS-TRACK]

 draft-ietf-dnssec-certs-04 RFC4398 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2538 RFC2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS) D. Eastlake 3rd March 1999 ASCII HTML 7 DHK-DNS Diffie-Hellman Keys Domain Name System cryptology authentication security signatures digital

A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records. [STANDARDS-TRACK]

 draft-ietf-dnssec-dhk-03 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2539 RFC2540 Detached Domain Name System (DNS) Information D. Eastlake 3rd March 1999 ASCII HTML 6 DNS-INFO Domain Name System security digital signatures authentication

A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-dnssec-ddi-06 EXPERIMENTAL EXPERIMENTAL IETF sec dnssec 10.17487/RFC2540 RFC2541 DNS Security Operational Considerations D. Eastlake 3rd March 1999 ASCII HTML 7 DNS-SOC domain name system cryptology resource records rrs

This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records. This memo provides information for the Internet community.

 draft-ietf-dnssec-secops-02 RFC4641 INFORMATIONAL INFORMATIONAL IETF sec dnssec 10.17487/RFC2541 RFC2542 Terminology and Goals for Internet Fax L. Masinter March 1999 ASCII HTML 20 real-time real time session store forward

This document defines a number of terms useful for the discussion of Internet Fax. In addition, it describes the goals of the Internet Fax working group and establishes a baseline of desired functionality against which protocols for Internet Fax can be judged. This memo provides information for the Internet community.

 draft-ietf-fax-goals-04 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC2542 RFC2543 SIP: Session Initiation Protocol M. Handley H. Schulzrinne E. Schooler J. Rosenberg March 1999 ASCII HTML 151 SIP application-layer application layer multimedia multicast unicast

The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. [STANDARDS-TRACK]

 draft-ietf-mmusic-sip-12 RFC3261 RFC3262 RFC3263 RFC3264 RFC3265 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC2543 RFC2544 Benchmarking Methodology for Network Interconnect Devices S. Bradner J. McQuaid March 1999 ASCII HTML 31 testing performance

This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment. This memo provides information for the Internet community.

 RFC1944 RFC6201 RFC6815 RFC9004 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2544 10.17487/RFC2544 RFC2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing P. Marques F. Dupont March 1999 ASCII HTML 5 BGP-4 border gateway protocol idr Inter-Domain Routing internet

BGP-4 Multiprotocol Extensions (BGP-MP) defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2545 RFC2546 6Bone Routing Practice A. Durand B. Buclin March 1999 ASCII HTML 10 IPv6 internet protocol

This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols and Exterior Gateway Protocols. This memo provides information for the Internet community.

 draft-ietf-ngtrans-6bone-routing-01 RFC2772 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2546 RFC2547 BGP/MPLS VPNs E. Rosen Y. Rekhter March 1999 ASCII HTML 25 border gateway protocol multiprotocol label switching architecture virtual private networks

This document describes a method by which a Service Provider with an IP backbone may provide VPNs (Virtual Private Networks) for its customers. This memo provides information for the Internet community.

 RFC4364 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2547 RFC2548 Microsoft Vendor-specific RADIUS Attributes G. Zorn March 1999 ASCII HTML 41 attributes remote access dialin user service dial-in

This document describes the set of Microsoft vendor-specific RADIUS attributes. This memo provides information for the Internet community.

 draft-ietf-radius-ms-vsa-01 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2548 10.17487/RFC2548 RFC2549 IP over Avian Carriers with Quality of Service D. Waitzman April 1 1999 ASCII HTML 6 avian carrier april fools qos

This memo amends RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers", with Quality of Service information. This is an experimental, not recommended standard. This memo defines an Experimental Protocol for the Internet community.

 RFC1149 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2549 10.17487/RFC2549 RFC2550 Y10K and Beyond S. Glassman M. Manasse J. Mogul April 1 1999 ASCII HTML 14 years dates formats april fools

This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals). This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2550 10.17487/RFC2550 RFC2551 The Roman Standards Process -- Revision III S. Bradner April 1 1999 ASCII HTML 37 numerals protocols procedures april fools

This memo documents the process used by the Roman community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2551 RFC2552 Architecture for the Information Brokerage in the ACTS Project GAIA M. Blinov M. Bessonov C. Clissmann April 1999 ASCII HTML 30 electronic systems products

This memo introduces a domain and supplier independent generic architecture for information brokerage, designed as part of the ACTS project GAIA (Generic Architecture for Information Availability). This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2552 RFC2553 Basic Socket Interface Extensions for IPv6 R. Gilligan S. Thomson J. Bound W. Stevens March 1999 ASCII HTML 41 internet protocol api application program interface tcp transmission control

TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. This memo provides information for the Internet community.

 draft-ietf-ipngwg-bsd-api-new-06 RFC2133 RFC3493 RFC3152 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2553 RFC2554 SMTP Service Extension for Authentication J. Myers March 1999 ASCII HTML 11 simple mail transfer protocol security layer sasl

This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. [STANDARDS-TRACK]

 draft-myers-smtp-auth-12 RFC4954 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2554 RFC2555 30 Years of RFCs RFC Editor, et al. April 1999 ASCII HTML 18 request for comments series documents publication

The rest of this document contains a brief recollection from the present RFC Editor Joyce K. Reynolds, followed by recollections from three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-range vision continues to guide us, and Jake Feinler who played a key role in the middle years of the RFC series. This memo provides information for the Internet community.

 RFC8700 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2555 RFC2556 OSI connectionless transport services on top of UDP Applicability Statement for Historic Status S. Bradner March 1999 ASCII HTML 4 user datagram protocol ISO international organization for standardization

RFC 1240, "OSI connectionless transport services on top of UDP", was published as a Proposed Standard in June 1991 but at this time there do not seem to be any implementations which follow RFC 1240. In addition there is a growing concern over using UDP-based transport protocols in environments where congestion is a possibility This memo provides information for the Internet community.

 draft-bradner-1240.his-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2556 RFC2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) J. Palme A. Hopmann N. Shelness March 1999 ASCII HTML 28 MHTML Hypertext Markup Language MIME multipurpose internet mail extensions multimedia uri uniform resource identifiers

This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. [STANDARDS-TRACK]

 draft-ietf-mhtml-rev-07 RFC2110 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml http://www.rfc-editor.org/errata_search.php?rfc=2557 10.17487/RFC2557 RFC2558 Definitions of Managed Objects for the SONET/SDH Interface Type K. Tesink March 1999 ASCII HTML 74 MIB Management SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. [STANDARDS-TRACK]

 draft-ietf-atommib-sonetng-05 RFC1595 RFC3592 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2558 RFC2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 S. Boeyen T. Howes P. Richard April 1999 ASCII HTML 13 X.509 LDAP lightweight directory access protocol IPKI Internet X.509 Public Key Infrastructure

Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. [STANDARDS-TRACK]

 draft-ietf-pkix-ipki2opp-08 RFC3494 RFC1778 HISTORIC PROPOSED STANDARD IETF sec pkix 10.17487/RFC2559 RFC2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP M. Myers R. Ankney A. Malpani S. Galperin C. Adams June 1999 ASCII HTML 23 PKIX Public Key Infrastructure X.509 digital security

This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS-TRACK]

 draft-ietf-pkix-ocsp-07 RFC6960 RFC6277 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2560 10.17487/RFC2560 RFC2561 Base Definitions of Managed Objects for TN3270E Using SMIv2 K. White R. Moore April 1999 ASCII HTML 56 MIB management information base structure telnet

This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers. The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. [STANDARDS-TRACK]

 draft-ietf-tn3270e-tn3270-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC2561 RFC2562 Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB) K. White R. Moore April 1999 ASCII HTML 49 TN2370E-RT-MIB MIB management information base structure telnet

This memo defines the protocol and the Management Information Base (MIB) for performing response time data collection on TN3270 and TN3270E sessions by a TN3270E server. [STANDARDS-TRACK]

 draft-ietf-tn3270e-rt-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC2562 RFC2563 DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients R. Troll May 1999 ASCII HTML 9 DHCP dynamic host configuration protocol internet address

This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own. [STANDARDS-TRACK]

 draft-ietf-dhc-autoconfig-04 RFC8925 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2563 RFC2564 Application Management MIB C. Kalbfleisch C. Krupczak R. Presuhn J. Saperia May 1999 ASCII HTML 86 APP-MIB application management information base

This memo defines a standards track portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. [STANDARDS-TRACK]

 draft-ietf-applmib-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF app applmib 10.17487/RFC2564 RFC2565 Internet Printing Protocol/1.0: Encoding and Transport R. Herriot Editor S. Butler P. Moore R. Turner April 1999 ASCII HTML 37 IPP-E-T IPP application media-type media type

This document defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines an Experimental protocol for the Internet community.

 draft-ietf-ipp-protocol-07 RFC2910 EXPERIMENTAL EXPERIMENTAL IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=2565 10.17487/RFC2565 RFC2566 Internet Printing Protocol/1.0: Model and Semantics R. deBry T. Hastings R. Herriot S. Isaacson P. Powell April 1999 ASCII HTML 173 IPP-M-S IPP application media-type job

This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. This document also addresses security, internationalization, and directory issues. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ipp-model-11 RFC2911 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2566 RFC2567 Design Goals for an Internet Printing Protocol F. Wright April 1999 ASCII HTML 43 IPP-DG Internet Printing Protocol application media type

This document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ipp-req-03 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2567 RFC2568 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol S. Zilles April 1999 ASCII HTML 10 IPP-RAT Internet Printing Protocol application media type

This document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ipp-rat-04 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2568 RFC2569 Mapping between LPD and IPP Protocols R. Herriot Editor T. Hastings N. Jacobs J. Martin April 1999 ASCII HTML 28 IPP Internet Printing Protocol application media type LPD line printer daemon

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ipp-lpd-ipp-map-05 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2569 RFC2570 Introduction to Version 3 of the Internet-standard Network Management Framework J. Case R. Mundy D. Partain B. Stewart April 1999 ASCII HTML 23 snmp simple protocol

The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This memo provides information for the Internet community.

 draft-ietf-snmpv3-intro-04 RFC3410 INFORMATIONAL INFORMATIONAL IETF ops snmpv3 10.17487/RFC2570 RFC2571 An Architecture for Describing SNMP Management Frameworks B. Wijnen D. Harrington R. Presuhn April 1999 ASCII HTML 62 ARCH-SNMP simple protocol network management

This document describes an architecture for describing SNMP Management Frameworks. [STANDARDS-TRACK]

 draft-ietf-snmpv3-arch-05 RFC2271 RFC3411 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2571 RFC2572 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen April 1999 ASCII HTML 44 MPD-SNMP processing models multiple

This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]

 RFC2272 RFC3412 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2572 RFC2573 SNMP Applications D. Levi P. Meyer B. Stewart April 1999 ASCII HTML 72 SNMP-APP simple network management protocol proxy operations command

This memo describes five types of SNMP applications which make use of an SNMP engine. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy fowarding. [STANDARDS-TRACK]

 draft-ietf-snmpv3-appl-v2-03 RFC2273 RFC3413 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2573 RFC2574 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen April 1999 ASCII HTML 86 USM-SNMPV3 message level mib information base

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]

 draft-ietf-snmpv3-usm-v2-05 RFC2274 RFC3414 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2574 RFC2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie April 1999 ASCII HTML 38 VACM-SNMP mib information base

This document describes the View-based Access Control Model for use in the SNMP architecture (RFC2571). It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]

 draft-ietf-snmpv3-vacm-04 RFC2275 RFC3415 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2575 RFC2576 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework R. Frye D. Levi S. Routhier B. Wijnen March 2000 ASCII HTML 44 SNMP simple network management protocol mib information base

The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]

 draft-ietf-snmpv3-coex-08 RFC1908 RFC2089 RFC3584 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=2576 10.17487/RFC2576 RFC2577 FTP Security Considerations M. Allman S. Ostermann May 1999 ASCII HTML 8 FTP-SEC file transfer protocol bounce attack password server

This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP. This memo provides information for the Internet community.

 draft-ietf-ftpext-sec-consider-02 INFORMATIONAL INFORMATIONAL IETF app ftpext 10.17487/RFC2577 RFC2578 Structure of Management Information Version 2 (SMIv2) K. McCloghrie Editor D. Perkins Editor J. Schoenwaelder Editor April 1999 ASCII HTML 42 SMIv2 Structure of Management Information Version 2 SNMP Simple Network Management Protocol

It is the purpose of this document, the Structure of Management Information Version 2 (SMIv2), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]

 draft-ops-smiv2-smi-01 RFC1902 STD0058 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC2578 RFC2579 Textual Conventions for SMIv2 K. McCloghrie Editor D. Perkins Editor J. Schoenwaelder Editor April 1999 ASCII HTML 25 CONV-MIB Management Information Base SMIv2 Structure of Management Information Version 2 SNMPv2 Simple Network Management Protocol Version 2

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

 draft-ops-smiv2-tc-01 RFC1903 STD0058 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2579 10.17487/RFC2579 RFC2580 Conformance Statements for SMIv2 K. McCloghrie Editor D. Perkins Editor J. Schoenwaelder Editor April 1999 ASCII HTML 29 CONF-MIB Management Information Base SNMPv2 Simple Network Management Protocol Version 2

Collections of related objects are defined in MIB modules. It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

 draft-ops-smiv2-conf-01 RFC1904 STD0058 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC2580 RFC2581 TCP Congestion Control M. Allman V. Paxson W. Stevens April 1999 ASCII HTML 14 TCP-CC Transmission Control Protocol Congestion Control

This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. [STANDARDS-TRACK]

 draft-ietf-tcpimpl-cong-control-05 RFC2001 RFC5681 RFC3390 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpimpl http://www.rfc-editor.org/errata_search.php?rfc=2581 10.17487/RFC2581 RFC2582 The NewReno Modification to TCP's Fast Recovery Algorithm S. Floyd T. Henderson April 1999 ASCII HTML 12 Transmission Control Protocol

This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tcpimpl-newreno-02 RFC3782 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpimpl 10.17487/RFC2582 RFC2583 Guidelines for Next Hop Client (NHC) Developers R. Carlson L. Winkler May 1999 ASCII HTML 9 NHRP resolution protocol IP internet

This document provides guidelines for developers of the Next Hop Resolution Protocol Clients (NHC). The intent is to define the interaction between the NHC code and the TCP/IP protocol stack of the local host operating system. This memo provides information for the Internet community.

 draft-carlson-nhrp-03 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2583 RFC2584 Definitions of Managed Objects for APPN/HPR in IP Networks B. Clouston B. Moore May 1999 ASCII HTML 21 IP internet protocol MIB management information base APPN Advanced Peer-to-Peer Network HPR high performance routing

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling HPR (High Performance Routing) network devices which have the capability to communicate in IP (Internet Protocol) networks. [STANDARDS-TRACK]

 draft-ietf-snanau-hpripmib-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2584 RFC2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP R. Housley P. Hoffman May 1999 ASCII HTML 8 X.509 FTP file transfer protocol HTTP hypertext transfer protocol PKI Public Key Infrastructure

The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. [STANDARDS-TRACK]

 draft-ietf-pkix-opp-ftp-http-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2585 10.17487/RFC2585 RFC2586 The Audio/L16 MIME content type J. Salsman H. Alvestrand May 1999 ASCII HTML 5 AUDIO/L16 media-type application multipurpose internet mail extensions

This document defines the audio/L16 MIME type, a reasonable quality audio format for use in Internet applications. This memo provides information for the Internet community.

 draft-alvestrand-audio-l16-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2586 RFC2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema S. Boeyen T. Howes P. Richard June 1999 ASCII HTML 8 lightweight directory access protocol pkix

The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-specific components are specified here. [STANDARDS-TRACK]

 draft-ietf-pkix-ldapv2-schema-02 RFC4523 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2587 RFC2588 IP Multicast and Firewalls R. Finlayson May 1999 ASCII HTML 12 Internet Protocol security gateway traffic

In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast. This memo provides information for the Internet community.

 draft-ietf-mboned-mcast-firewall-02 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC2588 RFC2589 Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services Y. Yaacovi M. Wahl T. Genovese May 1999 ASCII HTML 12 LDAPv3 Lightweight Directory Access Protocol request response operations

This document defines the requirements for dynamic directory services and specifies the format of request and response extended operations for supporting client-server interoperation in a dynamic directories environment. [STANDARDS-TRACK]

 draft-ietf-asid-ldapv3-dynamic-08 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2589 RFC2590 Transmission of IPv6 Packets over Frame Relay Networks Specification A. Conta A. Malis M. Mueller May 1999 ASCII HTML 19 IPv6 internet Protocol format link-local

This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks. [STANDARDS-TRACK]

 draft-ietf-ion-ipv6-fr-02 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2590 RFC2591 Definitions of Managed Objects for Scheduling Management Operations D. Levi J. Schoenwaelder May 1999 ASCII HTML 25 mib information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

 draft-ietf-disman-schedule-mib-06 RFC3231 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC2591 RFC2592 Definitions of Managed Objects for the Delegation of Management Script D. Levi J. Schoenwaelder May 1999 ASCII HTML 53 mib information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. [STANDARDS-TRACK]

 draft-ietf-disman-script-mib-08 RFC3165 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC2592 RFC2593 Script MIB Extensibility Protocol Version 1.0 J. Schoenwaelder J. Quittek May 1999 ASCII HTML 22 management information base smx language specific

The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. This memo defines an Experimental Protocol for the Internet community.

 draft-schoenw-smx-00 RFC3179 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2593 RFC2594 Definitions of Managed Objects for WWW Services H. Hazewinkel C. Kalbfleisch J. Schoenwaelder May 1999 ASCII HTML 43 MIB management information base WWW world wide web

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular it describes a set of objects for managing World Wide Web (WWW) services. [STANDARDS-TRACK]

 draft-ietf-applmib-wwwmib-11 PROPOSED STANDARD PROPOSED STANDARD IETF app applmib 10.17487/RFC2594 RFC2595 Using TLS with IMAP, POP3 and ACAP C. Newman June 1999 ASCII HTML 15 ACAP application configuration access protocol POP3 post office protocol IMAP internet message access protocol transport layer security

Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. [STANDARDS-TRACK]

 draft-newman-tls-imappop-09 RFC4616 RFC7817 RFC8314 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2595 10.17487/RFC2595 RFC2596 Use of Language Codes in LDAP M. Wahl T. Howes May 1999 ASCII HTML 9 lightweight directory access protocol servers

This document describes how language codes are carried in LDAP and are to be interpreted by LDAP servers. [STANDARDS-TRACK]

 draft-ietf-ldapext-lang-01 RFC3866 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2596 RFC2597 Assured Forwarding PHB Group J. Heinanen F. Baker W. Weiss J. Wroclawski June 1999 ASCII HTML 11 PHB per-hop-behaviour DS differentiated services AF assured forwarding

This document defines a general use Differentiated Services (DS) Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [STANDARDS-TRACK]

 draft-ietf-diffserv-af-06 RFC3260 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=2597 10.17487/RFC2597 RFC2598 An Expedited Forwarding PHB V. Jacobson K. Nichols K. Poduri June 1999 ASCII HTML 11 PHB per-hop-forwarding behavior DS differentiated services EF Expedited Forwarding

The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. [STANDARDS-TRACK]

 draft-ietf-diffserv-phb-ef-02 RFC3246 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=2598 10.17487/RFC2598 RFC2599 Request for Comments Summary RFC Numbers 2500-2599 A. DeLaCruz March 2000 ASCII HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2599 RFC2600 Internet Official Protocol Standards J. Reynolds R. Braden March 2000 ASCII HTML 31 IAB official protocol standards

This memo is published by the RFC Editor in accordance with Section 2.1 of "The Internet Standards Process -- Revision 3", RFC 2026, which specifies the rules and procedures by which all Internet standards are set. This memo is prepared by the RFC Editor for the IESG and IAB. Please see http://www.rfc-editor.org for later updates to this document. [STANDARDS-TRACK]

 RFC2500 RFC2700 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2600 RFC2601 ILMI-Based Server Discovery for ATMARP M. Davison June 1999 ASCII HTML 6 ILMI integrated local management interface ATMARP asynchronous transfer mode address resolution protocol

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate ATMARP servers. [STANDARDS-TRACK]

 draft-ietf-ion-discov-atmarp-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2601 RFC2602 ILMI-Based Server Discovery for MARS M. Davison June 1999 ASCII HTML 6 ILMI integrated local management interface ATM asynchronous transfer mode MARS Multicast Address Resolution Server

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate MARS servers. [STANDARDS-TRACK]

 draft-ietf-ion-discov-mars-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2602 RFC2603 ILMI-Based Server Discovery for NHRP M. Davison June 1999 ASCII HTML 6 ILMI integrated local management interface NHRP next hop resolution protocol

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers. [STANDARDS-TRACK]

 draft-ietf-ion-discov-nhrp-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2603 RFC2604 Wireless Device Configuration (OTASP/OTAPA) via ACAP R. Gellens June 1999 ASCII HTML 29 over-the-air ota application configuration access protocol

This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol. This memo provides information for the Internet community.

 draft-gellens-otasp-acap-01 RFC2636 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2604 RFC2605 Directory Server Monitoring MIB G. Mansfield S. Kille June 1999 ASCII HTML 26 MIB management information base network services

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

 draft-ietf-madman-dsa-mib-1 RFC1567 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2605 RFC2606 Reserved Top Level DNS Names D. Eastlake 3rd A. Panitz June 1999 ASCII HTML 5 domain name system private

To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsind-test-tlds-13 RFC6761 BCP0032 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2606 10.17487/RFC2606 RFC2607 Proxy Chaining and Policy Implementation in Roaming B. Aboba J. Vollbrecht June 1999 ASCII HTML 15 network access server identifier radius

This document describes how proxy chaining and policy implementation can be supported in roaming systems. This memo provides information for the Internet community.

 draft-ietf-roamops-auth-10 INFORMATIONAL INFORMATIONAL IETF ops roamops 10.17487/RFC2607 RFC2608 Service Location Protocol, Version 2 E. Guttman C. Perkins J. Veizades M. Day June 1999 ASCII HTML 54 SLP network services

The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. [STANDARDS-TRACK]

 draft-ietf-svrloc-protocol-v2-15 RFC2165 RFC3224 PROPOSED STANDARD PROPOSED STANDARD IETF int svrloc http://www.rfc-editor.org/errata_search.php?rfc=2608 10.17487/RFC2608 RFC2609 Service Templates and Service: Schemes E. Guttman C. Perkins J. Kempf June 1999 ASCII HTML 33 SLP service location protocol URL universal resource locator

This document describes a formal procedure for defining and standardizing new service types and attributes for use with the "service:" scheme. [STANDARDS-TRACK]

 draft-ietf-svrloc-service-scheme-14 RFC2165 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2609 RFC2610 DHCP Options for Service Location Protocol C. Perkins E. Guttman June 1999 ASCII HTML 6 DHCP dynamic host configuration protocol SLP Service Location Protocol

The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network. Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages. Another option provides an assignment of scope for configuration of SLP User and Service Agents. [STANDARDS-TRACK]

 draft-ietf-dhc-slp-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2610 RFC2611 URN Namespace Definition Mechanisms L. Daigle D. van Gulik R. Iannella P. Faltstrom June 1999 ASCII HTML 14 uniform resource names namespaces syntax

This document lays out general definitions of and mechanisms for establishing URN "namespaces". This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-urn-nid-req-08 RFC3406 BCP0033 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urn 10.17487/RFC2611 RFC2612 The CAST-256 Encryption Algorithm C. Adams J. Gilchrist June 1999 ASCII HTML 19 security cryptology

This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A). This memo provides information for the Internet community.

 draft-adams-cast-256-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2612 RFC2613 Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0 R. Waterman B. Lahaye D. Romascanu S. Waldbusser June 1999 ASCII HTML 44 smon MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices in switched networks environments. [STANDARDS-TRACK]

 draft-ietf-rmonmib-smon-07 DRAFT STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC2613 RFC2614 An API for Service Location J. Kempf E. Guttman June 1999 ASCII HTML 91 slp application program interface

This document describes standardized APIs for SLP in C and Java. This memo provides information for the Internet community.

 draft-ietf-svrloc-api-09 INFORMATIONAL INFORMATIONAL IETF int svrloc 10.17487/RFC2614 RFC2615 PPP over SONET/SDH A. Malis W. Simpson June 1999 ASCII HTML 10 PPP point-to-point protocol SONET/SDH synchronous optical network synchronous digital hierarchy

This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. [STANDARDS-TRACK]

 draft-ietf-pppext-pppoversonet-update-04 RFC1619 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2615 RFC2616 Hypertext Transfer Protocol -- HTTP/1.1 R. Fielding J. Gettys J. Mogul H. Frystyk L. Masinter P. Leach T. Berners-Lee June 1999 ASCII PS PDF HTML 176 HTTP Hypertext Transfer Protocol World Wide Web WWW hypermedia

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068. [STANDARDS-TRACK]

 draft-ietf-http-v11-spec-rev-06 RFC2068 RFC7230 RFC7231 RFC7232 RFC7233 RFC7234 RFC7235 RFC2817 RFC5785 RFC6266 RFC6585 DRAFT STANDARD DRAFT STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2616 10.17487/RFC2616 RFC2617 HTTP Authentication: Basic and Digest Access Authentication J. Franks P. Hallam-Baker J. Hostetler S. Lawrence P. Leach A. Luotonen L. Stewart June 1999 ASCII HTML 34 HTTP security encryption hypertext transfer protocol

This document provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "Digest Access Authentication". [STANDARDS-TRACK]

 draft-ietf-http-authentication-03 RFC2069 RFC7235 RFC7615 RFC7616 RFC7617 DRAFT STANDARD DRAFT STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2617 10.17487/RFC2617 RFC2618 RADIUS Authentication Client MIB B. Aboba G. Zorn June 1999 ASCII HTML 14 RADIUS Remote Authentication Dial-In User Service MIB management information base security

This memo defines a set of extensions which instrument RADIUS authentication client functions. [STANDARDS-TRACK]

 draft-ietf-radius-auth-clientmib-05 RFC4668 PROPOSED STANDARD PROPOSED STANDARD IETF ops radius 10.17487/RFC2618 RFC2619 RADIUS Authentication Server MIB G. Zorn B. Aboba June 1999 ASCII HTML 16 management information base security remote access dialin user service

This memo defines a set of extensions which instrument RADIUS authentication server functions. [STANDARDS-TRACK]

 draft-ietf-radius-auth-servmib-05 RFC4669 PROPOSED STANDARD PROPOSED STANDARD IETF ops radius 10.17487/RFC2619 RFC2620 RADIUS Accounting Client MIB B. Aboba G. Zorn June 1999 ASCII HTML 13 management information base security remote access dialin user service

This memo defines a set of extensions which instrument RADIUS accounting client functions. This memo provides information for the Internet community.

 draft-ietf-radius-acc-clientmib-05 RFC4670 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2620 RFC2621 RADIUS Accounting Server MIB G. Zorn B. Aboba June 1999 ASCII HTML 15 management information base security remote access,dialin user service

This memo defines a set of extensions which instrument RADIUS accounting server functions. This memo provides information for the Internet community.

 draft-ietf-radius-acc-servmib-05 RFC4671 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2621 RFC2622 Routing Policy Specification Language (RPSL) C. Alaettinoglu C. Villamizar E. Gerich D. Kessens D. Meyer T. Bates D. Karrenberg M. Terpstra June 1999 ASCII HTML 69 RPSL Routing Policy Specification Language internet policy hierarchy network configuration

RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]

 draft-ietf-rps-rpsl-v2-03 RFC2280 RFC4012 RFC7909 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps http://www.rfc-editor.org/errata_search.php?rfc=2622 10.17487/RFC2622 RFC2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 M. Eisler June 1999 ASCII HTML 19 NFSV4 network file system version 4 RPC remote procedure call architecture

This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how the Version 2 and Version 3 of the NFS protocol use the RPCSEC_GSS security flavor protocol and Kerberos V5. [STANDARDS-TRACK]

 draft-ietf-nfsv4-nfssec-01 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC2623 RFC2624 NFS Version 4 Design Considerations S. Shepler June 1999 ASCII HTML 22 network file system

This design considerations document is meant to present more detail than the working group charter. Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4. This memo provides information for the Internet community.

 draft-ietf-nfsv4-designconsider-03 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC2624 RFC2625 IP and ARP over Fibre Channel M. Rajagopal R. Bhagwat W. Rickard June 1999 ASCII HTML 63 IP internet protocol ARP address resolution protocol

The purpose of this document is to specify a way of encapsulating IP and Address Resolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution. [STANDARDS-TRACK]

 draft-ietf-ipfc-fibre-channel-06 RFC4338 PROPOSED STANDARD PROPOSED STANDARD IETF int ipfc http://www.rfc-editor.org/errata_search.php?rfc=2625 10.17487/RFC2625 RFC2626 The Internet and the Millennium Problem (Year 2000) P. Nesser II June 1999 ASCII HTML 275 Y2K

The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols. This investigation only targeted the protocols as documented in the Request For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost all Internet protocols were given a clean bill of health. Several cases of "period" problems were discovered, where a time field would "roll over" as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation. This memo provides information for the Internet community.

 draft-ietf-2000-issue-06 INFORMATIONAL INFORMATIONAL IETF ops 2000 http://www.rfc-editor.org/errata_search.php?rfc=2626 10.17487/RFC2626 RFC2627 Key Management for Multicast: Issues and Architectures D. Wallner E. Harder R. Agee June 1999 ASCII HTML 23 communication sessions net key rekey

This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. This memo provides information for the Internet community.

 draft-wallner-key-arch-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2627 RFC2628 Simple Cryptographic Program Interface (Crypto API) V. Smyslov June 1999 ASCII HTML 30 application security

This document describes a simple Application Program Interface to cryptographic functions. This memo provides information for the Internet community.

 draft-smyslov-crypto-api-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2628 RFC2629 Writing I-Ds and RFCs using XML M. Rose June 1999 ASCII HTML 31 internet-drafts extensible markup language source format

This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo provides information for the Internet community.

 draft-mrose-writing-rfcs-02 RFC7749 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2629 RFC2630 Cryptographic Message Syntax R. Housley June 1999 ASCII HTML 60 encryption certificate key management

This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. [STANDARDS-TRACK]

 draft-ietf-smime-cms-13 RFC3369 RFC3370 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2630 10.17487/RFC2630 RFC2631 Diffie-Hellman Key Agreement Method E. Rescorla June 1999 ASCII HTML 13 Diffie-Hellman encryption management certificate

This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. [STANDARDS-TRACK]

 draft-ietf-smime-x942-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2631 10.17487/RFC2631 RFC2632 S/MIME Version 3 Certificate Handling B. Ramsdell Editor June 1999 ASCII HTML 13 encryption certificate multipurpose internet mail extensions secure

S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile. [STANDARDS-TRACK]

 draft-ietf-smime-cert-08 RFC3850 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC2632 RFC2633 S/MIME Version 3 Message Specification B. Ramsdell Editor June 1999 ASCII HTML 32 secure multipurpose internet mail extensions encryption

This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK]

 draft-ietf-smime-msg-08 RFC3851 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2633 10.17487/RFC2633 RFC2634 Enhanced Security Services for S/MIME P. Hoffman Editor June 1999 ASCII HTML 58 S/MIME secure multipurpose internet mail extensions encryption

This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK]

 draft-ietf-smime-ess-12 RFC5035 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2634 10.17487/RFC2634 RFC2635 DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*) S. Hambridge A. Lunde June 1999 ASCII HTML 18 electronic mail email users administrators managers

This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community. This memo provides information for the Internet community.

 draft-ietf-run-spew-08 FYI0035 INFORMATIONAL INFORMATIONAL IETF run 10.17487/RFC2635 RFC2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP R. Gellens July 1999 ASCII PS PDF HTML 29 over-the-air ota application configuration access protocol

This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol. This memo provides information for the Internet community.

 RFC2604 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2636 RFC2637 Point-to-Point Tunneling Protocol (PPTP) K. Hamzeh G. Pall W. Verthein J. Taarud W. Little G. Zorn July 1999 ASCII HTML 57 IP tunnel encapsulation

This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. This memo provides information for the Internet community.

 draft-ietf-pppext-pptp-10 INFORMATIONAL INFORMATIONAL IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=2637 10.17487/RFC2637 RFC2638 A Two-bit Differentiated Services Architecture for the Internet K. Nichols V. Jacobson L. Zhang July 1999 ASCII PS PDF HTML 26 IP internet protocol header packets

This document presents a differentiated services architecture for the internet. This memo provides information for the Internet community.

 draft-nichols-diff-svc-arch-02 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2638 10.17487/RFC2638 RFC2639 Internet Printing Protocol/1.0: Implementer's Guide T. Hastings C. Manros July 1999 ASCII HTML 64 IPP client object

This document contains information that supplements the IPP Model and Semantics and the IPP Transport and Encoding documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. This memo provides information for the Internet community.

 draft-ietf-ipp-implementers-guide-01 RFC3196 INFORMATIONAL INFORMATIONAL IETF app ipp 10.17487/RFC2639 RFC2640 Internationalization of the File Transfer Protocol B. Curtin July 1999 ASCII HTML 27 ftp File Transfer Protocol character sets languages

This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets and languages found throughout the Internet community. This is achieved by extending the FTP specification and giving recommendations for proper internationalization support. [STANDARDS-TRACK]

 draft-ietf-ftpext-intl-ftp-06 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext http://www.rfc-editor.org/errata_search.php?rfc=2640 10.17487/RFC2640 RFC2641 Cabletron's VlanHello Protocol Specification Version 4 D. Hamilton D. Ruffen August 1999 ASCII HTML 17 ISMP inter switch message protocol switches

The VlanHello protocol is part of the InterSwitch Message Protocol (ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. Switches use the VlanHello protocol to discover their neighboring switches and establish the topology of the switch fabric. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2641 RFC2642 Cabletron's VLS Protocol Specification L. Kane August 1999 ASCII HTML 95 Virtual LAN link ISMP inter switch message routing

VLSP provides support for equal-cost multipath routing, and recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2642 RFC2643 Cabletron's SecureFast VLAN Operational Model D. Ruffen T. Len J. Yanacek August 1999 ASCII HTML 60 SFVLAN switching data packets vitrual LANs

Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer. The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC2643 RFC2644 Changing the Default for Directed Broadcasts in Routers D. Senie August 1999 ASCII HTML 4 smurf amplifiers denial of service

This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community.

 draft-senie-directed-broadcast-03 RFC1812 BCP0034 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2644 RFC2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses R. Gellens August 1999 ASCII HTML 9 ODMR-SMTP On-Demand Mail Relay simple mail transfer protocol internet

This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem. [STANDARDS-TRACK]

 draft-gellens-on-demand-07 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2645 10.17487/RFC2645 RFC2646 The Text/Plain Format Parameter R. Gellens Editor August 1999 ASCII HTML 14 media type mime multipurpose internet mail extension

This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK]

 draft-gellens-format-06 RFC3676 RFC2046 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2646 RFC2647 Benchmarking Terminology for Firewall Performance D. Newman August 1999 ASCII HTML 26 routers switches measurement

This document defines terms used in measuring the performance of firewalls. It extends the terminology already used for benchmarking routers and switches with definitions specific to firewalls. [STANDARDS-TRACK]

 draft-ietf-bmwg-secperf-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2647 RFC2648 A URN Namespace for IETF Documents R. Moats August 1999 ASCII HTML 30 uniform resource names internet engineering task force

This document proposes the "ietf" namespace, which consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor and the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences. [STANDARDS-TRACK]

 draft-ietf-urn-ietf-09 RFC6924 RFC9141 INFORMATIONAL INFORMATIONAL IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=2648 10.17487/RFC2648 RFC2649 An LDAP Control and Schema for Holding Operation Signatures B. Greenblatt P. Richard August 1999 ASCII HTML 10 LDAP lightweight directory access protocol client server

This document describes an LDAP message control which allows for the retrieval of digitally signed information. This document defines an LDAP v3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ldapext-sigops-04 EXPERIMENTAL EXPERIMENTAL IETF app ldapext 10.17487/RFC2649 RFC2650 Using RPSL in Practice D. Meyer J. Schmitz C. Orange M. Prior C. Alaettinoglu August 1999 ASCII HTML 26 routing policy specification language IRR internet routing registry configurations

This document is a tutorial on using the Routing Policy Specification Language (RPSL) to describe routing policies in the Internet Routing Registry (IRR). This memo provides information for the Internet community.

 draft-ietf-rps-appl-rpsl-06 INFORMATIONAL INFORMATIONAL IETF ops rps 10.17487/RFC2650 RFC2651 The Architecture of the Common Indexing Protocol (CIP) J. Allen M. Mealling August 1999 ASCII HTML 19 CIP Common Indexing Protocol query routing database servers

This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices. [STANDARDS-TRACK]

 draft-ietf-find-cip-arch-02 PROPOSED STANDARD PROPOSED STANDARD IETF app find 10.17487/RFC2651 RFC2652 MIME Object Definitions for the Common Indexing Protocol (CIP) J. Allen M. Mealling August 1999 ASCII HTML 22 MIME multipurpose internet mail extensions database CIP Common Indexing Protocol

This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type. [STANDARDS-TRACK]

 draft-ietf-find-cip-mime-03 PROPOSED STANDARD PROPOSED STANDARD IETF app find 10.17487/RFC2652 RFC2653 CIP Transport Protocols J. Allen P. Leach R. Hedberg August 1999 ASCII HTML 11 CIP common indexing protocol message formats

This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP. [STANDARDS-TRACK]

 draft-ietf-find-cip-trans-01 PROPOSED STANDARD PROPOSED STANDARD IETF app find 10.17487/RFC2653 RFC2654 A Tagged Index Object for use in the Common Indexing Protocol R. Hedberg B. Greenblatt R. Moats M. Wahl August 1999 ASCII HTML 24 CIP Common Indexing Protocol information servers database

This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the Common Indexing Protocol. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-find-cip-tagged-07 EXPERIMENTAL EXPERIMENTAL IETF app find 10.17487/RFC2654 RFC2655 CIP Index Object Format for SOIF Objects T. Hardie M. Bowman D. Hardy M. Schwartz D. Wessels August 1999 ASCII HTML 17 CIP SOIF summary object interchange format common indexing protocol

This document describes SOIF, the Summary Object Interchange Format, as an index object type in the context of the CIP framework. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-find-cip-soif-02 EXPERIMENTAL EXPERIMENTAL IETF app find http://www.rfc-editor.org/errata_search.php?rfc=2655 10.17487/RFC2655 RFC2656 Registration Procedures for SOIF Template Types T. Hardie August 1999 ASCII HTML 9 SOIF summary object interchange format stream

The registration procedure described in this document is specific to SOIF template types. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-find-soif-registry-00 EXPERIMENTAL EXPERIMENTAL IETF app find http://www.rfc-editor.org/errata_search.php?rfc=2656 10.17487/RFC2656 RFC2657 LDAPv2 Client vs. the Index Mesh R. Hedberg August 1999 ASCII HTML 12 LDAPv2 lightweight directory access protocol version 2 CIP common indexing protocol

LDAPv2 clients as implemented according to RFC 1777 have no notion on referral. The integration between such a client and an Index Mesh, as defined by the Common Indexing Protocol, heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-find-cip-ldapv2-02 EXPERIMENTAL EXPERIMENTAL IETF app find 10.17487/RFC2657 RFC2658 RTP Payload Format for PureVoice(tm) Audio K. McKay August 1999 ASCII HTML 10 RTP real-time transport protocol packet end-to-end

This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK]

 draft-mckay-qcelp-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2658 RFC2659 Security Extensions For HTML E. Rescorla A. Schiffman August 1999 ASCII HTML 4 HTML hyper-text markup language cryptology

This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-wts-shtml-05 EXPERIMENTAL EXPERIMENTAL IETF sec wts 10.17487/RFC2659 RFC2660 The Secure HyperText Transfer Protocol E. Rescorla A. Schiffman August 1999 ASCII HTML 45 WWW world wide web http authentication

This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web. Secure HTTP (S-HTTP) provides independently applicable security services for transaction confidentiality, authenticity/integrity and non-repudiability of origin.

The protocol emphasizes maximum flexibility in choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction.

 draft-ietf-wts-shttp-06 HISTORIC EXPERIMENTAL IETF sec wts 10.17487/RFC2660 RFC2661 Layer Two Tunneling Protocol "L2TP" W. Townsley A. Valencia A. Rubens G. Pall G. Zorn B. Palter August 1999 ASCII HTML 80 L2TP Layer Two Tunneling Protocol ppp point-to-point protocol packets

This document describes the Layer Two Tunneling Protocol (L2TP). [STANDARDS-TRACK]

 draft-ietf-pppext-l2tp-16 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=2661 10.17487/RFC2661 RFC2662 Definitions of Managed Objects for the ADSL Lines G. Bathrick F. Ly August 1999 ASCII HTML 115 MIB management information base ADSL Asymmetric Bit-Rate DSL

This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model. [STANDARDS-TRACK]

 draft-ietf-adslmib-adsllinemib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=2662 10.17487/RFC2662 RFC2663 IP Network Address Translator (NAT) Terminology and Considerations P. Srisuresh M. Holdrege August 1999 ASCII HTML 30 network address translator IP internet protocol addresses

This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT. This memo provides information for the Internet community.

 draft-ietf-nat-terminology-03 INFORMATIONAL INFORMATIONAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=2663 10.17487/RFC2663 RFC2664 FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions R. Plzak A. Wells E. Krol August 1999 ASCII HTML 11 documentation help information FAQ

This memo provides an overview to the new Internet User. The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic. This memo provides information for the Internet community.

 draft-ietf-uswg-fyi4-bis-01 RFC1594 FYI0004 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC2664 RFC2665 Definitions of Managed Objects for the Ethernet-like Interface Types J. Flick J. Johnson August 1999 ASCII HTML 47 MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

 draft-ietf-hubmib-etherif-mib-v2-04 RFC2358 RFC3635 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2665 RFC2666 Definitions of Object Identifiers for Identifying Ethernet Chip Sets J. Flick August 1999 ASCII HTML 18 mib management information base

This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. This memo provides information for the Internet community.

 draft-ietf-hubmib-ether-chipsets-02 INFORMATIONAL INFORMATIONAL IETF ops hubmib 10.17487/RFC2666 RFC2667 IP Tunnel MIB D. Thaler August 1999 ASCII HTML 16 internet protocol management information base

This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. [STANDARDS-TRACK]

 draft-ietf-ifmib-tunnel-mib-06 RFC4087 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC2667 RFC2668 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) A. Smith J. Flick K. de Graaf D. Romascanu D. McMaster K. McCloghrie S. Roberts August 1999 ASCII HTML 56 MAU-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

 draft-ietf-hubmib-mau-mib-v2-04 RFC2239 RFC3636 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2668 RFC2669 DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems M. St. Johns Editor August 1999 ASCII HTML 55 MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of DOCSIS 1.0 compliant Cable Modems and Cable Modem Termination Systems. [STANDARDS-TRACK]

 draft-ietf-ipcdn-cable-device-mib-08 RFC4639 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC2669 RFC2670 Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces M. St. Johns Editor August 1999 ASCII HTML 72 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces. [STANDARDS-TRACK]

 draft-ietf-ipcdn-rf-interface-mib-07 RFC4546 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC2670 RFC2671 Extension Mechanisms for DNS (EDNS0) P. Vixie August 1999 ASCII HTML 7 EDNS0 domain name system RR resource records opt

The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. [STANDARDS-TRACK]

 draft-ietf-dnsind-edns0-02 RFC6891 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC2671 RFC2672 Non-Terminal DNS Name Redirection M. Crawford August 1999 ASCII HTML 9 DNS domain name system dname RR resource records

This document defines a new DNS Resource Record called "DNAME", which provides the capability to map an entire subtree of the DNS name space to another domain. [STANDARDS-TRACK]

 draft-ietf-dnsind-dname-03 RFC6672 RFC4592 RFC6604 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC2672 RFC2673 Binary Labels in the Domain Name System M. Crawford August 1999 ASCII HTML 7 DNS domain name system data

This document defines a "Bit-String Label" which may appear within domain names. This new label type compactly represents a sequence of "One-Bit Labels" and enables resource records to be stored at any bit- boundary in a binary-named section of the domain name tree. [STANDARDS-TRACK]

 draft-ietf-dnsind-binary-labels-05 RFC6891 RFC1035 RFC3363 RFC3364 HISTORIC PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2673 10.17487/RFC2673 RFC2674 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions E. Bell A. Smith P. Langille A. Rijhsinghani K. McCloghrie August 1999 ASCII HTML 86 MIB management information base local area network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. [STANDARDS-TRACK]

 draft-ietf-bridge-bridgemib-06 RFC4363 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge 10.17487/RFC2674 RFC2675 IPv6 Jumbograms D. Borman S. Deering R. Hinden August 1999 ASCII HTML 9 IPv6 internet protocol packet payload link

This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms. [STANDARDS-TRACK]

 draft-ietf-ipngwg-jumbograms-01 RFC2147 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2675 10.17487/RFC2675 RFC2676 QoS Routing Mechanisms and OSPF Extensions G. Apostolopoulos S. Kama D. Williams R. Guerin A. Orda T. Przygienda August 1999 ASCII HTML 50 QoS quality of service OSPF open shortest path first routing

This memo describes extensions to the OSPF protocol to support QoS routes. The focus of this document is on the algorithms used to compute QoS routes and on the necessary modifications to OSPF to support this function, e.g., the information needed, its format, how it is distributed, and how it is used by the QoS path selection process. This memo defines an Experimental Protocol for the Internet community.

 draft-guerin-qos-routing-ospf-05 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=2676 10.17487/RFC2676 RFC2677 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP) M. Greene J. Cucchiara J. Luciani August 1999 ASCII HTML 67 NHRP-MIB Next Hop Resolution Protocol MIB management information base NBMA Non-Broadcast Multi-Access

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

 draft-ietf-ion-nhrp-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2677 RFC2678 IPPM Metrics for Measuring Connectivity J. Mahdavi V. Paxson September 1999 ASCII HTML 10 IPPM-MET internet protocol performance metrics

This memo defines a series of metrics for connectivity between a pair of Internet hosts. [STANDARDS-TRACK]

 RFC2498 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2678 RFC2679 A One-way Delay Metric for IPPM G. Almes S. Kalidindi M. Zekauskas September 1999 ASCII HTML 20 IPPM internet protocol performance metrics packets

This memo defines a metric for one-way delay of packets across Internet paths. [STANDARDS-TRACK]

 draft-ietf-ippm-delay-07 RFC7679 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=2679 10.17487/RFC2679 RFC2680 A One-way Packet Loss Metric for IPPM G. Almes S. Kalidindi M. Zekauskas September 1999 ASCII HTML 15 IPPM internet protocol performance metrics

This memo defines a metric for one-way packet loss across Internet paths. [STANDARDS-TRACK]

 draft-ietf-ippm-loss-07 RFC7680 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=2680 10.17487/RFC2680 RFC2681 A Round-trip Delay Metric for IPPM G. Almes S. Kalidindi M. Zekauskas September 1999 ASCII HTML 20 IPPM internet protocol performance metrics packets

This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK]

 draft-ietf-ippm-rt-delay-01 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=2681 10.17487/RFC2681 RFC2682 Performance Issues in VC-Merge Capable ATM LSRs I. Widjaja A. Elwalid September 1999 ASCII HTML 12 asynchronous transfer mode routing

This document investigates the impact of VC merging on the additional buffer required for the reassembly buffers and other buffers. This memo provides information for the Internet community.

 draft-widjaja-mpls-vc-merge-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2682 RFC2683 IMAP4 Implementation Recommendations B. Leiba September 1999 ASCII HTML 23 internet message access protocol clients servers

The IMAP4 specification describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible. This memo provides information for the Internet community.

 draft-leiba-imap-implement-guide-10 RFC7162 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2683 10.17487/RFC2683 RFC2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5 D. Grossman J. Heinanen September 1999 ASCII HTML 23 ATM asynchronous transfer mode multiplexing

This memo replaces RFC 1483. It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM. [STANDARDS-TRACK]

 draft-ietf-ion-multiprotocol-atm-04 RFC1483 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2684 RFC2685 Virtual Private Networks Identifier B. Fox B. Gleeson September 1999 ASCII HTML 6 VPNI Virtual Private Networks Identifier IP internet protocol

This document proposes a format for a globally unique VPN identifier. [STANDARDS-TRACK]

 draft-ietf-ion-vpn-id-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2685 RFC2686 The Multi-Class Extension to Multi-Link PPP C. Bormann September 1999 ASCII HTML 11 PPP point-to-point protocol encapsulation

This document proposes the fragment-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK]

 draft-ietf-issll-isslow-mcml-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2686 RFC2687 PPP in a Real-time Oriented HDLC-like Framing C. Bormann September 1999 ASCII HTML 13 PPP point-to-point protocol encapsulation HDLC high-level data link control

This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK]

 draft-ietf-issll-isslow-rtf-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2687 RFC2688 Integrated Services Mappings for Low Speed Networks S. Jackowski D. Putzolu E. Crawley B. Davie September 1999 ASCII HTML 16 controlled load guaranteed services

This document defines the service mappings of the IETF Integrated Services for low-bitrate links, specifically the controlled load and guaranteed services. [STANDARDS-TRACK]

 draft-ietf-issll-isslow-svcmap-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2688 RFC2689 Providing Integrated Services over Low-bitrate Links C. Bormann September 1999 ASCII HTML 14 asynchronous synchronous real-time

This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links. This memo provides information for the Internet community.

 draft-ietf-issll-isslow-06 INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2689 RFC2690 A Proposal for an MOU-Based ICANN Protocol Support Organization S. Bradner September 1999 ASCII HTML 8 pso memorandum of understanding internet corporation for assigned names and numbers

This is a copy of the proposal for an MOU-based Protocol Supporting Organization that was submitted to ICANN on April 23, 1999. This memo provides information for the Internet community.

 draft-ietf-poisson-mou-pso-00 INFORMATIONAL INFORMATIONAL IETF gen Poisson 10.17487/RFC2690 RFC2691 A Memorandum of Understanding for an ICANN Protocol Support Organization S. Bradner September 1999 ASCII HTML 9 mou pso internet corporation for assigned names and numbers

This is the text of the Memorandum of Understanding (MoU) that was signed by ICANN, the IETF, the ITU-T, W3C and ETSI on July 14, 1999 in Oslo. This MoU creates the Protocol Support Organization (PSO) within the Internet Corporation for Assigned Names and Numbers (ICANN). This memo provides information for the Internet community.

 draft-ietf-poisson-pso-mou-01 INFORMATIONAL INFORMATIONAL IETF gen Poisson 10.17487/RFC2691 RFC2692 SPKI Requirements C. Ellison September 1999 ASCII HTML 14 SPKI simple public key infrastructure authentication

The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-spki-cert-req-03 EXPERIMENTAL EXPERIMENTAL IETF sec spki 10.17487/RFC2692 RFC2693 SPKI Certificate Theory C. Ellison B. Frantz B. Lampson R. Rivest B. Thomas T. Ylonen September 1999 ASCII HTML 43 SPKI simple public key infrastructure authentication

This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-spki-cert-theory-05 EXPERIMENTAL EXPERIMENTAL IETF sec spki 10.17487/RFC2693 RFC2694 DNS extensions to Network Address Translators (DNS_ALG) P. Srisuresh G. Tsirtsis P. Akkiraju A. Heffernan September 1999 ASCII HTML 29 domain name system NATs mapping

This document identifies the need for DNS extensions to NATs and outlines how a DNS Application Level Gateway (DNS_ALG) can meet the need. This memo provides information for the Internet community.

 draft-ietf-nat-dns-alg-04 INFORMATIONAL INFORMATIONAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=2694 10.17487/RFC2694 RFC2695 Authentication Mechanisms for ONC RPC A. Chiu September 1999 ASCII HTML 18 remote procedure call open network computing

This document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol. This memo provides information for the Internet community.

 draft-ietf-oncrpc-auth-06 INFORMATIONAL INFORMATIONAL IETF tsv oncrpc 10.17487/RFC2695 RFC2696 LDAP Control Extension for Simple Paged Results Manipulation C. Weider A. Herron A. Anantha T. Howes September 1999 ASCII HTML 7 lightweight directory access protocol client server

This document describes an LDAPv3 control extension for simple paging of search results. This memo provides information for the Internet community.

 draft-ietf-asid-ldapv3-simplepaged-03 INFORMATIONAL INFORMATIONAL IETF app ldapext http://www.rfc-editor.org/errata_search.php?rfc=2696 10.17487/RFC2696 RFC2697 A Single Rate Three Color Marker J. Heinanen R. Guerin September 1999 ASCII HTML 6 srtcm stream ip internet protocol packet

This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner. This memo provides information for the Internet community.

 draft-heinanen-diffserv-srtcm-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2697 RFC2698 A Two Rate Three Color Marker J. Heinanen R. Guerin September 1999 ASCII HTML 5 trTCM stream ip internet protocol packet

This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community.

 draft-heinanen-diffserv-trtcm-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2698 RFC2699 Request for Comments Summary RFC Numbers 2600-2699 S. Ginoza May 2000 ASCII HTML 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2699 RFC2700 Internet Official Protocol Standards J. Reynolds R. Braden August 2000 ASCII HTML 32

This memo describes the current state of standardization of protocols used in the Internet as determined by the Internet Engineering Task Force (IETF). [STANDARDS-TRACK]

 RFC2600 RFC2800 HISTORIC INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2700 10.17487/RFC2700 RFC2701 Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol G. Malkin September 1999 ASCII HTML 9 point-to-point POP presence RAS remote access server

This document specifies a standard way for Multi-link PPP to operate across multiple nodes. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2701 RFC2702 Requirements for Traffic Engineering Over MPLS D. Awduche J. Malcolm J. Agogbua M. O'Dell J. McManus September 1999 ASCII HTML 29 multiprotocol label switching

This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. This memo provides information for the Internet community.

 draft-ietf-mpls-traffic-eng-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=2702 10.17487/RFC2702 RFC2703 Protocol-independent Content Negotiation Framework G. Klyne September 1999 ASCII HTML 20 feature resource media syntax

This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed. This memo provides information for the Internet community.

 draft-ietf-conneg-requirements-02 INFORMATIONAL INFORMATIONAL IETF app conneg 10.17487/RFC2703 RFC2704 The KeyNote Trust-Management System Version 2 M. Blaze J. Feigenbaum J. Ioannidis A. Keromytis September 1999 ASCII HTML 37 security policy maker system credentials

This memo describes version 2 of the KeyNote trust-management system.It specifies the syntax and semantics of KeyNote `assertions', describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. This memo provides information for the Internet community.

 draft-blaze-ietf-trustmgt-keynote-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2704 RFC2705 Media Gateway Control Protocol (MGCP) Version 1.0 M. Arango A. Dugan I. Elliott C. Huitema S. Pickett October 1999 ASCII HTML 134 voice IP internet VoIP

This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP) Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements. This memo provides information for the Internet community.

 draft-huitema-megaco-mgcp-v1-00 RFC3435 RFC3660 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2705 RFC2706 ECML v1: Field Names for E-Commerce D. Eastlake 3rd T. Goldstein October 1999 ASCII HTML 13 electronic commerce modeling language merchant site. web

A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. This memo provides information for the Internet community.

 draft-eastlake-ecom-fields-01 RFC3106 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2706 RFC2707 Job Monitoring MIB - V1.0 R. Bergman T. Hastings S. Isaacson H. Lewis November 1999 ASCII HTML 114 management information base

This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This memo provides information for the Internet community.

 draft-ietf-printmib-job-monitor-08 INFORMATIONAL INFORMATIONAL IETF app printmib 10.17487/RFC2707 RFC2708 Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB R. Bergman November 1999 ASCII HTML 26 management information base

This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the Job Monitoring MIB. This memo provides information for the Internet community.

 draft-ietf-printmib-job-protomap-04 INFORMATIONAL INFORMATIONAL IETF app printmib 10.17487/RFC2708 RFC2709 Security Model with Tunnel-mode IPsec for NAT Domains P. Srisuresh October 1999 ASCII HTML 11 internet protocol network address translator

This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. This memo provides information for the Internet community.

 draft-ietf-nat-security-02 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC2709 RFC2710 Multicast Listener Discovery (MLD) for IPv6 S. Deering W. Fenner B. Haberman October 1999 ASCII HTML 22 MLD-IPv6 Multicast Listener Discovery internet protocol router packets

This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. [STANDARDS-TRACK]

 draft-ietf-ipngwg-mld-02 RFC3590 RFC3810 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2710 RFC2711 IPv6 Router Alert Option C. Partridge A. Jackson October 1999 ASCII HTML 6 IPv6 internet protocol datagram router hop-by-hop

This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. [STANDARDS-TRACK]

 draft-ietf-ipngwg-ipv6router-alert-06 RFC6398 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2711 RFC2712 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) A. Medvinsky M. Hur October 1999 ASCII HTML 7 TLS Transport Layer Security authentication cryptography

This document proposes the addition of new cipher suites to the TLS protocol to support Kerberos-based authentication. [STANDARDS-TRACK]

 draft-ietf-tls-kerb-cipher-suites-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=2712 10.17487/RFC2712 RFC2713 Schema for Representing Java(tm) Objects in an LDAP Directory V. Ryan S. Seligman R. Lee October 1999 ASCII HTML 21 lightweight directory access protocol

This document defines the schema for representing Java(tm) objects in an LDAP directory. This memo provides information for the Internet community.

 draft-ryan-java-schema-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2713 RFC2714 Schema for Representing CORBA Object References in an LDAP Directory V. Ryan R. Lee S. Seligman October 1999 ASCII HTML 10 lightweight directory access protocol

This document defines the schema for representing CORBA object references in an LDAP directory. This memo provides information for the Internet community.

 draft-ryan-corba-schema-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2714 RFC2715 Interoperability Rules for Multicast Routing Protocols D. Thaler October 1999 ASCII HTML 22 border router MBRs autonomous

The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains. This memo provides information for the Internet community.

 draft-thaler-multicast-interop-03 INFORMATIONAL INFORMATIONAL IETF rtg idmr 10.17487/RFC2715 RFC2716 PPP EAP TLS Authentication Protocol B. Aboba D. Simon October 1999 ASCII HTML 24 PPP point-to-point protocol EAP Extensible Authentication Protocol LCP link control protocol CCP compression control protocol TLS transport level security

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-pppext-eaptls-06 RFC5216 EXPERIMENTAL EXPERIMENTAL IETF int pppext 10.17487/RFC2716 RFC2717 Registration Procedures for URL Scheme Names R. Petke I. King November 1999 ASCII HTML 10 uniform resource locator syntax semantics

This document defines the process by which new URL scheme names are registered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-urlreg-procedures-08 RFC4395 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urlreg 10.17487/RFC2717 RFC2718 Guidelines for new URL Schemes L. Masinter H. Alvestrand D. Zigmond R. Petke November 1999 ASCII HTML 10 uniform resource locator syntax semantics

This document provides guidelines for the definition of new URL schemes. This memo provides information for the Internet community.

 draft-ietf-urlreg-guide-05 RFC4395 INFORMATIONAL INFORMATIONAL IETF app urlreg 10.17487/RFC2718 RFC2719 Framework Architecture for Signaling Transport L. Ong I. Rytina M. Garcia H. Schwarzbauer L. Coene H. Lin I. Juhasz M. Holdrege C. Sharp October 1999 ASCII HTML 24 IP Internet Protocol gateway media circuit

This document defines an architecture framework and functional requirements for transport of signaling information over IP. This memo provides information for the Internet community.

 draft-ietf-sigtran-framework-arch-03 INFORMATIONAL INFORMATIONAL IETF rai sigtran 10.17487/RFC2719 RFC2720 Traffic Flow Measurement: Meter MIB N. Brownlee October 1999 ASCII HTML 55 MIB management information base

This document defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured. It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised. [STANDARDS-TRACK]

 draft-ietf-rtfm-meter-mib-11 RFC2064 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rtfm 10.17487/RFC2720 RFC2721 RTFM: Applicability Statement N. Brownlee October 1999 ASCII HTML 10 real-time traffic flow measurement

This document provides an overview covering all aspects of Realtime Traffic Flow Measurement, including its area of applicability and its limitations. This memo provides information for the Internet community.

 draft-ietf-rtfm-applicability-statement-04 INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2721 RFC2722 Traffic Flow Measurement: Architecture N. Brownlee C. Mills G. Ruth October 1999 ASCII HTML 48 network meters data

This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within the Internet. This memo provides information for the Internet community.

 draft-ietf-rtfm-architecture-08 RFC2063 INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2722 RFC2723 SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups N. Brownlee October 1999 ASCII HTML 22 simple ruleset RTFM real-time network measurement

This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow. This memo provides information for the Internet community.

 draft-ietf-rtfm-ruleset-language-07 INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2723 RFC2724 RTFM: New Attributes for Traffic Flow Measurement S. Handelman S. Stibler N. Brownlee G. Ruth October 1999 ASCII HTML 18 RTFM real-time traffic flow measurement network

This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rtfm-new-traffic-flow-10 EXPERIMENTAL EXPERIMENTAL IETF tsv rtfm 10.17487/RFC2724 RFC2725 Routing Policy System Security C. Villamizar C. Alaettinoglu D. Meyer S. Murphy December 1999 ASCII HTML 41 RPSL Routing Policy Specification Language system security database registry authentication

The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model. [STANDARDS-TRACK]

 draft-ietf-rps-auth-04 RFC4012 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2725 RFC2726 PGP Authentication for RIPE Database Updates J. Zsako December 1999 ASCII HTML 11 PGP pretty good privacy security digital signatures

This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. [STANDARDS-TRACK]

 draft-ietf-rps-dbsec-pgp-authent-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2726 RFC2727 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin February 2000 ASCII HTML 15 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-poisson-nomcom-v2-01 RFC2282 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC2727 RFC2728 The Transmission of IP Over the Vertical Blanking Interval of a Television Signal R. Panabaker S. Wegerif D. Zigmond November 1999 ASCII HTML 23 IP internet protocol IPVBI IP Over the Vertical Blanking Interval of Television Signal

This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals. [STANDARDS-TRACK]

 draft-ietf-ipvbi-nabts-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ipvbi 10.17487/RFC2728 RFC2729 Taxonomy of Communication Requirements for Large-scale Multicast Applications P. Bagnall R. Briscoe A. Poppitt December 1999 ASCII HTML 27 LSMA dynamic protocol mapping

The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). This memo provides information for the Internet community.

 draft-ietf-lsma-requirements-04 INFORMATIONAL INFORMATIONAL IETF app lsma 10.17487/RFC2729 RFC2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP) S. Hanna B. Patel M. Shah December 1999 ASCII HTML 53 MADCAP Multicast Address Dynamic Client Allocation Protocol server scope zone host

This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. [STANDARDS-TRACK]

 draft-ietf-malloc-madcap-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC2730 RFC2731 Encoding Dublin Core Metadata in HTML J. Kunze December 1999 ASCII HTML 23 hypertext markup language xml extensible

The Dublin Core is a small set of metadata elements for describing information resources. This document explains how these elements are expressed using the META and LINK tags of HTML. This memo provides information for the Internet community.

 draft-kunze-dchtml-02 RFC5791 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2731 10.17487/RFC2731 RFC2732 Format for Literal IPv6 Addresses in URL's R. Hinden B. Carpenter L. Masinter December 1999 ASCII HTML 5 Internet protocol uniform resource identifier www world wide web

This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. [STANDARDS-TRACK]

 draft-ietf-ipngwg-url-literal-04 RFC3986 RFC2396 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2732 10.17487/RFC2732 RFC2733 An RTP Payload Format for Generic Forward Error Correction J. Rosenberg H. Schulzrinne December 1999 ASCII HTML 26 FEC Forward Error Correction RTP real-time protocol stream

This document specifies a payload format for generic forward error correction of media encapsulated in RTP. [STANDARDS-TRACK]

 draft-ietf-avt-fec-08 RFC5109 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2733 RFC2734 IPv4 over IEEE 1394 P. Johansson December 1999 ASCII HTML 29 IPv4 internet protocol datagrams packet encapsulation ARP address resolution multicast IEEE Institute of Electrical and Electronics Engineers

This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams; it defines the necessary methods, data structures and codes for that purpose. [STANDARDS-TRACK]

 draft-ietf-ip1394-ipv4-19 PROPOSED STANDARD PROPOSED STANDARD IETF int ip1394 10.17487/RFC2734 RFC2735 NHRP Support for Virtual Private Networks B. Fox B. Petri December 1999 ASCII HTML 12 NHRP next hop resolution protocol VPN Virtual Private Network addresses

The NBMA Next Hop Resolution Protocol (NHRP) is used to determine the NBMA subnetwork addresses of the "NBMA next hop" towards a public internetworking layer address. This document describes the enhancements necessary to enable NHRP to perform the same function for private internetworking layer addresses available within the framework of a Virtual Private Network (VPN) service on a shared NBMA network. [STANDARDS-TRACK]

 draft-ietf-ion-nhrp-vpn-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2735 RFC2736 Guidelines for Writers of RTP Payload Format Specifications M. Handley C. Perkins December 1999 ASCII HTML 10 real-time transport protocol data types audio video codecs

This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-avt-rtp-format-guidelines-04 RFC8088 BCP0036 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai avt 10.17487/RFC2736 RFC2737 Entity MIB (Version 2) K. McCloghrie A. Bierman December 1999 ASCII HTML 56 management information base SNMP simple network protocol

This memo defines a portion of the Management Information Base (M for use with network management protocols in the Internet communi In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]

 draft-ietf-entmib-v2-06 RFC2037 RFC4133 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=2737 10.17487/RFC2737 RFC2738 Corrections to "A Syntax for Describing Media Feature Sets" G. Klyne December 1999 ASCII HTML 5 FEC Forward Error Correction real-time protocol stream

In RFC 2533, "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags. This memo contains two corrections to that specification: one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates. [STANDARDS-TRACK]

 draft-ietf-conneg-feature-syntax-er-00 RFC2533 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2738 RFC2739 Calendar Attributes for vCard and LDAP T. Small D. Hennessy F. Dawson January 2000 ASCII HTML 16 LDAP lightweight directory access protocol calendar

This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. [STANDARDS-TRACK]

 draft-ietf-calsch-locating-03 RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch http://www.rfc-editor.org/errata_search.php?rfc=2739 10.17487/RFC2739 RFC2740 OSPF for IPv6 R. Coltun D. Ferguson J. Moy December 1999 ASCII HTML 80 IPv6 internet protocol OSPF open shortest path first

This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]

 draft-ietf-ospf-ospfv6-08 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=2740 10.17487/RFC2740 RFC2741 Agent Extensibility (AgentX) Protocol Version 1 M. Daniele B. Wijnen M. Ellison D. Francisco January 2000 ASCII HTML 91 SNMP simple network management protocol

This memo defines a standardized framework for extensible SNMP agents. [STANDARDS-TRACK]

 draft-ietf-agentx-rfc-update-03 RFC2257 DRAFT STANDARD PROPOSED STANDARD IETF ops agentx 10.17487/RFC2741 RFC2742 Definitions of Managed Objects for Extensible SNMP Agents L. Heintz S. Gudur M. Ellison January 2000 ASCII HTML 20 SNMP Simple Network Management Protocol MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. [STANDARDS-TRACK]

 draft-ietf-agentx-mib-05 DRAFT STANDARD PROPOSED STANDARD IETF ops agentx 10.17487/RFC2742 RFC2743 Generic Security Service Application Program Interface Version 2, Update 1 J. Linn January 2000 ASCII HTML 101 GSS-API Generic Security Service Application Program Interface authentication cryptology

This memo obsoletes [STANDARDS-TRACK]

 draft-ietf-cat-rfc2078bis-08 RFC2078 RFC5554 RFC5896 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat http://www.rfc-editor.org/errata_search.php?rfc=2743 10.17487/RFC2743 RFC2744 Generic Security Service API Version 2 : C-bindings J. Wray January 2000 ASCII HTML 101 GSS-API Generic Security Service Application Program Interface cryptology authentication

This document specifies C language bindings for Version 2, Update 1 of the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in RFC 2743. [STANDARDS-TRACK]

 draft-ietf-cat-gssv2-cbind-09 RFC1509 RFC5896 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat http://www.rfc-editor.org/errata_search.php?rfc=2744 10.17487/RFC2744 RFC2745 RSVP Diagnostic Messages A. Terzis B. Braden S. Vincent L. Zhang January 2000 ASCII HTML 23 RSVP resource reservation protocol network management

This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. [STANDARDS-TRACK]

 draft-ietf-rsvp-diagnostic-msgs-08 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2745 RFC2746 RSVP Operation Over IP Tunnels A. Terzis J. Krawczyk J. Wroclawski L. Zhang January 2000 ASCII HTML 25 RSVP resource reservation protocol IP internet protocol

This document describes an approach for providing RSVP protocol services over IP tunnels. [STANDARDS-TRACK]

 draft-ietf-rsvp-tunnel-04 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2746 RFC2747 RSVP Cryptographic Authentication F. Baker B. Lindell M. Talwar January 2000 ASCII HTML 21 RSVP resource reservation protocol security

This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. [STANDARDS-TRACK]

 draft-ietf-rsvp-md5-08 RFC3097 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib http://www.rfc-editor.org/errata_search.php?rfc=2747 10.17487/RFC2747 RFC2748 The COPS (Common Open Policy Service) Protocol D. Durham Editor J. Boyle R. Cohen S. Herzog R. Rajan A. Sastry January 2000 ASCII HTML 38 COPS Common Open Policy Service qos quality of service signaling

This document describes a simple client/server model for supporting policy control over QoS signaling protocols. [STANDARDS-TRACK]

 draft-ietf-rap-cops-08 RFC4261 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2748 RFC2749 COPS usage for RSVP S. Herzog Editor J. Boyle R. Cohen D. Durham R. Rajan A. Sastry January 2000 ASCII HTML 17 COPS common open policy service RSVP resource reservation protocol

This document describes usage directives for supporting COPS policy services in RSVP environments. [STANDARDS-TRACK]

 draft-ietf-rap-cops-rsvp-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2749 RFC2750 RSVP Extensions for Policy Control S. Herzog January 2000 ASCII HTML 13 RSVP resource reservation protocol admission

This memo presents a set of extensions for supporting generic policy based admission control in RSVP. [STANDARDS-TRACK]

 draft-ietf-rap-rsvp-ext-06 RFC2205 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2750 RFC2751 Signaled Preemption Priority Policy Element S. Herzog January 2000 ASCII HTML 12 RSVP COPS resource reservation protocol common open service

This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as RSVP and COPS). [STANDARDS-TRACK]

 draft-ietf-rap-signaled-priority-04 RFC3181 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2751 RFC2752 Identity Representation for RSVP S. Yadav R. Yavatkar R. Pabbati P. Ford T. Moore S. Herzog January 2000 ASCII HTML 17 resource reservation protocol admission authentication

This document describes the representation of identity information in POLICY_DATA object for supporting policy based admission control in RSVP. [STANDARDS-TRACK]

 draft-ietf-rap-rsvp-identity-05 RFC3182 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2752 RFC2753 A Framework for Policy-based Admission Control R. Yavatkar D. Pendarakis R. Guerin January 2000 ASCII HTML 20

This document is concerned with specifying a framework for providing policy-based control over admission control decisions. This memo provides information for the Internet community.

 draft-ietf-rap-framework-03 INFORMATIONAL INFORMATIONAL IETF ops rap 10.17487/RFC2753 RFC2754 RPS IANA Issues C. Alaettinoglu C. Villamizar R. Govindan January 2000 ASCII HTML 7 internet assigned numbers authority routing policy specification system security

RPS Security requires certain RPSL objects in the IRR to be hierarchically delegated. The set of objects that are at the root of this hierarchy needs to be created and digitally signed by IANA. This paper presents these seed objects and lists operations required from IANA. This memo provides information for the Internet community.

 draft-ietf-rps-iana-02 RFC6254 HISTORIC INFORMATIONAL IETF ops rps 10.17487/RFC2754 RFC2755 Security Negotiation for WebNFS A. Chiu M. Eisler B. Callaghan January 2000 ASCII HTML 12 RSVP QOS resource reservation protocol quality of service

This document describes a protocol for a WebNFS client (RFC2054) to negotiate the desired security mechanism with a WebNFS server (RFC2055) before the WebNFS client falls back to the MOUNT v3 protocol (RFC1813). This document is provided so that people can write compatible implementations. This memo provides information for the Internet community.

 draft-chiu-network-wnfs-sec-nego-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2755 RFC2756 Hyper Text Caching Protocol (HTCP/0.0) P. Vixie D. Wessels January 2000 ASCII HTML 15 HTCP Hyper Text Cashing Protocol HTTP hypertext transfer protocol caches data

This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. This is an experimental protocol, one among several proposals to perform these functions. This memo defines an Experimental Protocol for the Internet community.

 draft-vixie-htcp-proto-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2756 RFC2757 Long Thin Networks G. Montenegro S. Dawkins M. Kojo V. Magret N. Vaidya January 2000 ASCII HTML 46 wireless WAN wide area networks TCP transmission control protocol

Our goal is to identify a TCP that works for all users, including users of long thin networks. This memo provides information for the Internet community.

 draft-montenegro-pilc-ltn-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2757 RFC2758 Definitions of Managed Objects for Service Level Agreements Performance Monitoring K. White February 2000 ASCII HTML 71 MIB management information base SLAs Service Level Agreements

This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. This memo defines an Experimental Protocol for the Internet community.

 draft-white-slapm-mib-06 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2758 RFC2759 Microsoft PPP CHAP Extensions, Version 2 G. Zorn January 2000 ASCII HTML 20 point-to-point protocol challenge handshake authentication

This document describes version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1). This memo provides information for the Internet community.

 draft-ietf-pppext-mschap-v2-04 INFORMATIONAL INFORMATIONAL IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=2759 10.17487/RFC2759 RFC2760 Ongoing TCP Research Related to Satellites M. Allman Editor S. Dawkins D. Glover J. Griner D. Tran T. Henderson J. Heidemann J. Touch H. Kruse S. Ostermann K. Scott J. Semke February 2000 ASCII HTML 46 transmission control protocol bandwidth network links

This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. This memo provides information for the Internet community.

 draft-ietf-tcpsat-res-issues-12 INFORMATIONAL INFORMATIONAL IETF tsv tcpsat 10.17487/RFC2760 RFC2761 Terminology for ATM Benchmarking J. Dunn C. Martin February 2000 ASCII HTML 32 asynchronous transfer mode performance

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices. This memo provides information for the Internet community.

 draft-ietf-bmwg-atm-term-00 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2761 RFC2762 Sampling of the Group Membership in RTP J. Rosenberg H. Schulzrinne February 2000 ASCII HTML 12 RTP real-time transport protocol packets

This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-avt-rtpsample-06 EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC2762 RFC2763 Dynamic Hostname Exchange Mechanism for IS-IS N. Shen H. Smit February 2000 ASCII HTML 5 intermediate system routers TLV

This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network. This memo provides information for the Internet community.

 draft-ietf-isis-dyname-02 RFC5301 INFORMATIONAL INFORMATIONAL IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=2763 10.17487/RFC2763 RFC2764 A Framework for IP Based Virtual Private Networks B. Gleeson A. Lin J. Heinanen G. Armitage A. Malis February 2000 ASCII HTML 62 VPN internet protocol backbone

This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. This memo provides information for the Internet community.

 draft-gleeson-vpn-framework-03 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2764 10.17487/RFC2764 RFC2765 Stateless IP/ICMP Translation Algorithm (SIIT) E. Nordmark February 2000 ASCII HTML 26 SIIT Stateless IP/ICMP Translation Algorithm internet protocol internet control message protocol IPv4 IPv6

This document specifies a transition mechanism algorithm in addition to the mechanisms already specified. [STANDARDS-TRACK]

 draft-ietf-ngtrans-siit-08 RFC6145 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC2765 RFC2766 Network Address Translation - Protocol Translation (NAT-PT) G. Tsirtsis P. Srisuresh February 2000 ASCII HTML 21 NAT-PT IPv4 IPv6 internet

This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified. [STANDARDS-TRACK]

 draft-ietf-ngtrans-natpt-07 RFC4966 RFC3152 HISTORIC PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC2766 RFC2767 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS) K. Tsuchiya H. Higuchi Y. Atarashi February 2000 ASCII HTML 13 IPv4 IPv6 internet protocol applications

This memo proposes a mechanism of dual stack hosts using the technique called "Bump-in-the-Stack" in the IP security area. This memo provides information for the Internet community.

 draft-ietf-ngtrans-bis-00 RFC6535 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2767 RFC2768 Network Policy and Services: A Report of a Workshop on Middleware B. Aiken J. Strassner B. Carpenter I. Foster C. Lynch J. Mambretti R. Moore B. Teitelbaum February 2000 ASCII HTML 29 protocols internet applications

An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998. The need for a more organized framework for middleware R&D was recognized, and a list of specific topics needing further work was identified. This memo provides information for the Internet community.

 draft-aiken-middleware-reqndef-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2768 RFC2769 Routing Policy System Replication C. Villamizar C. Alaettinoglu R. Govindan D. Meyer February 2000 ASCII HTML 42 RPSL Routing Policy Specification Language Routing Policy System Security database

This document addresses the need to distribute data over multiple repositories and delegate authority for data subsets to other repositories without compromising the authorization model established in Routing Policy System Security RFC. [STANDARDS-TRACK]

 draft-ietf-rps-dist-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2769 RFC2770 GLOP Addressing in 233/8 D. Meyer P. Lothberg February 2000 ASCII HTML 5 multicast allocation global

This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mboned-glop-addressing-02 RFC3180 EXPERIMENTAL EXPERIMENTAL IETF ops mboned 10.17487/RFC2770 RFC2771 An Abstract API for Multicast Address Allocation R. Finlayson February 2000 ASCII HTML 11 application programming interfaces service

This document describes the "abstract service interface" for the dynamic multicast address allocation service, as seen by applications. This memo provides information for the Internet community.

 draft-ietf-malloc-api-07 INFORMATIONAL INFORMATIONAL IETF tsv malloc 10.17487/RFC2771 RFC2772 6Bone Backbone Routing Guidelines R. Rockell R. Fink February 2000 ASCII HTML 14 IP internet protocol routing

This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. This memo provides information for the Internet community.

 draft-ietf-ngtrans-harden-04 RFC2546 RFC3152 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2772 RFC2773 Encryption using KEA and SKIPJACK R. Housley P. Yee W. Nace February 2000 ASCII HTML 9 KEA key exchange algorithm SKIPJACK symmetric

This document defines a method to encrypt a file transfer using the FTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)", (October

 draft-ietf-cat-ftpkeasj-01 RFC0959 EXPERIMENTAL EXPERIMENTAL IETF sec cat 10.17487/RFC2773 RFC2774 An HTTP Extension Framework H. Nielsen P. Leach S. Lawrence February 2000 ASCII HTML 20 hyper-text transfer protocol

A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.

 draft-frystyk-http-extensions-03 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC2774 RFC2775 Internet Transparency B. Carpenter February 2000 ASCII HTML 18 end-to-end network layer connectivity

This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency.

 draft-carpenter-transparency-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2775 RFC2776 Multicast-Scope Zone Announcement Protocol (MZAP) M. Handley D. Thaler R. Kermode February 2000 ASCII HTML 27 MZAP Multicast-Scope Zone Announcement Protocol packets addresses service location

This document defines a protocol, the Multicast-Scope Zone Announcement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. [STANDARDS-TRACK]

 draft-ietf-mboned-mzap-06 HISTORIC PROPOSED STANDARD IETF ops mboned 10.17487/RFC2776 RFC2777 Publicly Verifiable Nomcom Random Selection D. Eastlake 3rd February 2000 ASCII HTML 16 Internet Engineering Task Force IETF

This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. This memo provides information for the Internet community.

 draft-eastlake-selection-04 RFC3797 INFORMATIONAL INFORMATIONAL IETF gen Poisson 10.17487/RFC2777 RFC2778 A Model for Presence and Instant Messaging M. Day J. Rosenberg H. Sugano February 2000 ASCII HTML 17 service users MIME multipurpose Internet mail extensions

This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. This memo provides information for the Internet community.

 draft-ietf-impp-model-03 INFORMATIONAL INFORMATIONAL IETF app impp 10.17487/RFC2778 RFC2779 Instant Messaging / Presence Protocol Requirements M. Day S. Aggarwal G. Mohr J. Vincent February 2000 ASCII HTML 26 MIME multipurpose Internet mail extensions service users

This document defines a minimal set of requirements that IMPP must meet. This memo provides information for the Internet community.

 draft-ietf-impp-reqts-04 INFORMATIONAL INFORMATIONAL IETF app impp 10.17487/RFC2779 RFC2780 IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers S. Bradner V. Paxson March 2000 ASCII HTML 10 internet assigned numbers authority IP

This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-bradner-iana-allocation-05 RFC4443 RFC5237 RFC5771 RFC6335 RFC7045 BCP0037 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2780 RFC2781 UTF-16, an encoding of ISO 10646 P. Hoffman F. Yergeau February 2000 ASCII HTML 14 unicode character data code point

This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little- endian), and UTF-16. This memo provides information for the Internet community.

 draft-hoffman-utf16-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2781 RFC2782 A DNS RR for specifying the location of services (DNS SRV) A. Gulbrandsen P. Vixie L. Esibov February 2000 ASCII HTML 12 DNS-SRV domain name system service RR resource record

This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]

 draft-ietf-dnsind-rfc2052bis-05 RFC2052 RFC6335 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=2782 10.17487/RFC2782 RFC2783 Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0 J. Mogul D. Mills J. Brittenson J. Stone U. Windl March 2000 ASCII HTML 31 NTP time clock synchronization

RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources. This document specifies such an API. This memo provides information for the Internet community.

 draft-mogul-pps-api-06 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2783 RFC2784 Generic Routing Encapsulation (GRE) D. Farinacci T. Li S. Hanks D. Meyer P. Traina March 2000 ASCII HTML 9 GRE Generic Routing Encapsulation packet size payload

This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. [STANDARDS-TRACK]

 draft-meyer-gre-update-03 RFC2890 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2784 10.17487/RFC2784 RFC2785 Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME R. Zuccherato March 2000 ASCII HTML 11 security multipurpose internet mail extensions

This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks. This memo provides information for the Internet community.

 draft-ietf-smime-small-subgroup-03 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC2785 RFC2786 Diffie-Helman USM Key Management Information Base and Textual Convention M. St. Johns March 2000 ASCII HTML 20 mib management information base USM user-based security model Diffie-Hellman

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols the Internet community. In particular, it defines a textual convention for doing Diffie-Helman key agreement key exchanges an set of objects which extend the usmUserTable to permit the use of DH key exchange in addition to the key change method. This memo defines an Experimental Protocol for the Internet community.

 draft-stjohns-snmpv3-dhkeychange-mib-02 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2786 10.17487/RFC2786 RFC2787 Definitions of Managed Objects for the Virtual Router Redundancy Protocol B. Jewell D. Chuang March 2000 ASCII HTML 31 MIB management information base VRRP Virtual Router Redundancy Protocol

This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP). [STANDARDS-TRACK]

 draft-ietf-vrrp-mib-09 RFC6527 PROPOSED STANDARD PROPOSED STANDARD IETF rtg vrrp 10.17487/RFC2787 RFC2788 Network Services Monitoring MIB N. Freed S. Kille March 2000 ASCII HTML 22 MIB management information base

This document defines a MIB which contains the elements common to the monitoring of any network service application. [STANDARDS-TRACK]

 draft-ietf-madman-netsm-mib-07 RFC2248 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2788 RFC2789 Mail Monitoring MIB N. Freed S. Kille March 2000 ASCII HTML 33 MIB management information base mail monitoring

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB defined in RFC 2788 [STANDARDS-TRACK]

 draft-ietf-madman-email-mib-06 RFC2249 RFC1566 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2789 RFC2790 Host Resources MIB S. Waldbusser P. Grillo March 2000 ASCII HTML 50 MIB management information base host resources

This memo obsoletes RFC 1514, the "Host Resources MIB". This memo extends that specification by clarifying changes based on implementation and deployment experience and documenting the Host Resources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. [STANDARDS-TRACK]

 draft-ops-hostmib-01 RFC1514 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2790 RFC2791 Scalable Routing Design Principles J. Yu July 2000 ASCII HTML 26 network packets

This document identifies major factors affecting routing scalability as well as basic principles of designing scalable routing for large networks. This memo provides information for the Internet community.

 draft-yu-routing-scaling-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC2791 RFC2792 DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System M. Blaze J. Ioannidis A. Keromytis March 2000 ASCII HTML 7 cryptology digial signatures

This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system. This memo provides information for the Internet community.

 draft-angelos-keynote-dsa-rsa-encoding-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2792 RFC2793 RTP Payload for Text Conversation G. Hellstrom May 2000 ASCII HTML 10 real-time applications video audio packets

This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-text-05 RFC4103 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2793 RFC2794 Mobile IP Network Access Identifier Extension for IPv4 P. Calhoun C. Perkins March 2000 ASCII HTML 9 IPv4 internet protocol NAI Network Access Identifier

Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC 2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero. [STANDARDS-TRACK]

 draft-ietf-mobileip-mn-nai-07 RFC2290 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2794 RFC2795 The Infinite Monkey Protocol Suite (IMPS) S. Christey April 1 2000 ASCII HTML 20 control packet client

This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show. This memo provides information for the Internet community.

 draft-christey-imps-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2795 RFC2796 BGP Route Reflection - An Alternative to Full Mesh IBGP T. Bates R. Chandra E. Chen April 2000 ASCII HTML 11 BGP border gateway protocol

This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. [STANDARDS-TRACK]

 draft-ietf-idr-route-reflect-v2-03 RFC4456 RFC1966 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2796 RFC2797 Certificate Management Messages over CMS M. Myers X. Liu J. Schaad J. Weinstein April 2000 ASCII HTML 47 CMS CMC certificate management protocol cryptology syntax

This document defines a Certificate Management protocol using CMS (CMC). [STANDARDS-TRACK]

 draft-ietf-pkix-cmc-05 RFC5272 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2797 10.17487/RFC2797 RFC2798 Definition of the inetOrgPerson LDAP Object Class M. Smith April 2000 ASCII HTML 20 lightweight directory access protocol directory services

We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs. This memo provides information for the Internet community.

 draft-smith-ldap-inetorgperson-03 RFC3698 RFC4519 RFC4524 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2798 RFC2799 Request for Comments Summary RFC Numbers 2700-2799 S. Ginoza September 2000 ASCII HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2799 RFC2800 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza May 2001 ASCII HTML 38

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of April 17, 2001. It lists only official protocol standards RFCs; it is not a complete index to the RFC series. [STANDARDS-TRACK]

 RFC2700 RFC2900 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2800 RFC2801 Internet Open Trading Protocol - IOTP Version 1.0 D. Burdett April 2000 ASCII HTML 290 commerce payment system merchant

This document discusses the Internet Open Trading Protocol (IOTP) and its provision of an interoperable framework for Internet commerce. This memo provides information for the Internet community.

 draft-ietf-trade-iotp-v1.0-protocol-07 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC2801 RFC2802 Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP) K. Davidson Y. Kawatsura April 2000 ASCII HTML 29 commerce payment system xml extensible markup language security

This document describes the syntax and procedures for the computation and verification of digital signatures for use within Version 1.0 of the Internet Open Trading Protocol (IOTP). This memo provides information for the Internet community.

 draft-ietf-trade-iotp-v1.0-dsig-05 INFORMATIONAL INFORMATIONAL IETF app trade http://www.rfc-editor.org/errata_search.php?rfc=2802 10.17487/RFC2802 RFC2803 Digest Values for DOM (DOMHASH) H. Maruyama K. Tamura N. Uramoto April 2000 ASCII HTML 11 xml extensible markup language secruity

This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML. This memo provides information for the Internet community.

 draft-ietf-trade-hiroshi-dom-hash-03 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC2803 RFC2804 IETF Policy on Wiretapping IAB IESG May 2000 ASCII HTML 10 internet engineering task force

This document describes the position that the Internet Engineering Task Force (IETF) has taken regarding the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping. This memo explains what the IETF thinks the question means, why its answer is "no", and what that answer means. This memo provides information for the Internet community.

 draft-iab-raven-01 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=2804 10.17487/RFC2804 RFC2805 Media Gateway Control Protocol Architecture and Requirements N. Greene M. Ramalho B. Rosen April 2000 ASCII HTML 45 MG mapping transcoding network

This document describes protocol requirements for the Media Gateway Control Protocol between a Media Gateway Controller and a Media Gateway. This memo provides information for the Internet community.

 draft-ietf-megaco-reqs-10 INFORMATIONAL INFORMATIONAL IETF rai megaco 10.17487/RFC2805 RFC2806 URLs for Telephone Calls A. Vaha-Sipila April 2000 ASCII HTML 21 uniform resource locator schemes

This document specifies URL (Uniform Resource Locator) schemes "tel", "fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. [STANDARDS-TRACK]

 draft-antti-telephony-url-12 RFC3966 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2806 RFC2807 XML Signature Requirements J. Reagle July 2000 ASCII HTML 9 digital extensible markup language

This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. This memo provides information for the Internet community.

 draft-ietf-xmldsig-requirements-03 INFORMATIONAL INFORMATIONAL IETF sec xmldsig 10.17487/RFC2807 RFC2808 The SecurID(r) SASL Mechanism M. Nystrom April 2000 ASCII HTML 11 simple authentication security layer

This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism using SecurID (a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication), thereby providing a means for such tokens to be used in SASL environments. This mechanism is only is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services. This memo provides information for the Internet community.

 draft-nystrom-securid-sasl-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2808 RFC2809 Implementation of L2TP Compulsory Tunneling via RADIUS B. Aboba G. Zorn April 2000 ASCII HTML 23 remote authentication dial-in user service layer two

This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using the L2TP (Layer Two Tunneling Protocol) protocol. This memo provides information for the Internet community.

 draft-ietf-radius-tunnel-imp-05 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2809 RFC2810 Internet Relay Chat: Architecture C. Kalt April 2000 ASCII HTML 10 IRC text based conferencing

This document is an update describing the architecture of the current IRC protocol and the role of its different components. Other documents describe in detail the protocol used between the various components defined here. This memo provides information for the Internet community.

 draft-kalt-irc-arch-00 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2810 10.17487/RFC2810 RFC2811 Internet Relay Chat: Channel Management C. Kalt April 2000 ASCII HTML 19 IRC text based conferencing

This document specifies how channels, their characteristics and properties are managed by IRC servers. This memo provides information for the Internet community.

 draft-kalt-irc-chan-01 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC2811 RFC2812 Internet Relay Chat: Client Protocol C. Kalt April 2000 ASCII HTML 63 IRC text based conferencing

This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture. This memo provides information for the Internet community.

 draft-kalt-irc-client-03 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2812 10.17487/RFC2812 RFC2813 Internet Relay Chat: Server Protocol C. Kalt April 2000 ASCII HTML 26 IRC text based conferencing

This document defines the protocol used by servers to talk to each other. This memo provides information for the Internet community.

 draft-kalt-irc-server-02 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2813 10.17487/RFC2813 RFC2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks R. Yavatkar D. Hoffman Y. Bernet F. Baker M. Speer May 2000 ASCII HTML 60 SBM Subnet Bandwidth Manager LAN local area network RSVP resource reservation protocol

This document describes a signaling method and protocol for RSVP-based admission control over IEEE 802-style LANs. [STANDARDS-TRACK]

 draft-ietf-issll-is802-sbm-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2814 RFC2815 Integrated Service Mappings on IEEE 802 Networks M. Seaman A. Smith E. Crawley J. Wroclawski May 2000 ASCII HTML 17 LAN local area network resource reservation

This document describes mappings of IETF Integrated Services over LANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). [STANDARDS-TRACK]

 draft-ietf-issll-is802-svc-mapping-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2815 RFC2816 A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies A. Ghanwani J. Pace V. Srinivasan A. Smith M. Seaman May 2000 ASCII HTML 47 LAN local area network parameter switches

This memo describes a framework for supporting IETF Integrated Services on shared and switched LAN infrastructure. This memo provides information for the Internet community.

 draft-ietf-issll-is802-framework-07 INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2816 RFC2817 Upgrading to TLS Within HTTP/1.1 R. Khare S. Lawrence May 2000 ASCII HTML 13 HTTP hypertext transfer protocol TLS transport layer security

This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. [STANDARDS-TRACK]

 draft-ietf-tls-http-upgrade-05 RFC2616 RFC7230 RFC7231 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=2817 10.17487/RFC2817 RFC2818 HTTP Over TLS E. Rescorla May 2000 ASCII HTML 7 hypertext transfer protocol transport layer security

This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.

 draft-ietf-tls-https-04 RFC9110 RFC5785 RFC7230 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=2818 10.17487/RFC2818 RFC2819 Remote Network Monitoring Management Information Base S. Waldbusser May 2000 ASCII HTML 98 RMON-MIB Management Information Base Remote Monitoring

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

 draft-ietf-rmonmib-rmonfull-02 RFC1757 STD0059 INTERNET STANDARD INTERNET STANDARD IETF ops rmonmib http://www.rfc-editor.org/errata_search.php?rfc=2819 10.17487/RFC2819 RFC2820 Access Control Requirements for LDAP E. Stokes D. Byrne B. Blakley P. Behera May 2000 ASCII HTML 9 lightweight directory access protocol

This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. This memo provides information for the Internet community.

 draft-ietf-ldapext-acl-reqts-03 INFORMATIONAL INFORMATIONAL IETF app ldapext http://www.rfc-editor.org/errata_search.php?rfc=2820 10.17487/RFC2820 RFC2821 Simple Mail Transfer Protocol J. Klensin Editor April 2001 ASCII HTML 79 SMTP Simple Mail Transfer Protocol

This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. [STANDARDS-TRACK]

 draft-ietf-drums-smtpupd-13 RFC0821 RFC0974 RFC1869 RFC5321 RFC5336 PROPOSED STANDARD PROPOSED STANDARD IETF app drums http://www.rfc-editor.org/errata_search.php?rfc=2821 10.17487/RFC2821 RFC2822 Internet Message Format P. Resnick Editor April 2001 ASCII HTML 51 MAIL

This document specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. [STANDARDS-TRACK]

 draft-ietf-drums-msg-fmt-09 RFC0822 RFC5322 RFC5335 RFC5336 PROPOSED STANDARD PROPOSED STANDARD IETF app drums http://www.rfc-editor.org/errata_search.php?rfc=2822 10.17487/RFC2822 RFC2823 PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing J. Carlson P. Langner E. Hernandez-Valencia J. Manchester May 2000 ASCII HTML 28 PPP-SDL point-to-point protocol Simple Data Link SONET synchronous optical network SDH synchronous digital hierarchy

This document extends methods found in the Point-to-Point Protocol (PPP) and RFCs 1662 and 2615 to include a new encapsulation for PPP called Simple Data Link (SDL). SDL provides a standard method for transporting multi-protocol datagrams over point-to-point links, and RFCs 1662 and 2615 provide a means to carry PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. SDL provides a very low overhead alternative to HDLC-like encapsulation, and can also be used on SONET/SDH links. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-pppext-sdl-06 EXPERIMENTAL EXPERIMENTAL IETF int pppext 10.17487/RFC2823 RFC2824 Call Processing Language Framework and Requirements J. Lennox H. Schulzrinne May 2000 ASCII HTML 25 CPL-F telephony signalling network devices

This document describes an architectural framework we call a processing language, as a simple and standardized way for implementing and deploying Internet telephony. A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. It also outlines requirements for such a language. This memo provides information for the Internet community.

 draft-ietf-iptel-cpl-framework-02 INFORMATIONAL INFORMATIONAL IETF rai iptel 10.17487/RFC2824 RFC2825 A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols IAB L. Daigle Editor May 2000 ASCII HTML 7 character sets e-commerce interoperability

This document is a statement by the Internet Architecture Board. It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces. This memo provides information for the Internet community.

 draft-iab-i18n-dns-01 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=2825 10.17487/RFC2825 RFC2826 IAB Technical Comment on the Unique DNS Root Internet Architecture Board May 2000 ASCII HTML 6 Internet Architecture Board domain name system

This document discusses the existence of a globally unique public name space in the Internet called the DNS (Domain Name System). This name space is a hierarchical name space derived from a single, globally unique root. It is a technical constraint inherent in the design of the DNS. One root must be supported by a set of coordinated root servers administered by a unique naming authority. It is not technically feasible for there to be more than one root in the public DNS. This memo provides information for the Internet community.

 draft-iab-unique-dns-root-00 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=2826 10.17487/RFC2826 RFC2827 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing P. Ferguson D. Senie May 2000 ASCII HTML 10 ISP Internet Service Provider IP Internet Protocol DOS Denial of Service

This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC2267 RFC3704 BCP0038 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2827 10.17487/RFC2827 RFC2828 Internet Security Glossary R. Shirey May 2000 ASCII HTML 212 information system ISD internet standard documents

This Glossary provides abbreviations, explanations, and recommendations for use of information system security terminology. This memo provides information for the Internet community.

 draft-shirey-security-glossary-02 RFC4949 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2828 RFC2829 Authentication Methods for LDAP M. Wahl H. Alvestrand J. Hodges R. Morgan May 2000 ASCII HTML 16 lightweight directory access protocol security

This document specifies particular combinations of security mechanisms which are required and recommended in LDAP implementations. [STANDARDS-TRACK]

 draft-ietf-ldapext-authmeth-04 RFC4513 RFC4510 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2829 RFC2830 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security J. Hodges R. Morgan M. Wahl May 2000 ASCII HTML 12 LDAP TLS

This document defines the "Start Transport Layer Security (TLS) Operation" for LDAP. [STANDARDS-TRACK]

 draft-ietf-ldapext-ldapv3-tls-06 RFC4511 RFC4513 RFC4510 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2830 RFC2831 Using Digest Authentication as a SASL Mechanism P. Leach C. Newman May 2000 ASCII HTML 27 http hypertext transfer protocol SASL Simple Authentication and Security Layer

This specification defines how HTTP Digest Authentication can be used as a SASL mechanism for any protocol that has a SASL (Simple Authentication and Security Layer) profile. [STANDARDS-TRACK]

 draft-leach-digest-sasl-05 RFC6331 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC2831 RFC2832 NSI Registry Registrar Protocol (RRP) Version 1.1.0 S. Hollenbeck M. Srivastava May 2000 ASCII HTML 39 RRP shared registration system gLTD ccTLD top level domain

This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) and country code Top Level Domains (ccTLDs). This memo provides information for the Internet community.

 draft-hollenbeck-rrp-01 RFC3632 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2832 RFC2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals H. Schulzrinne S. Petrack May 2000 ASCII HTML 30 RTP real-time application protocol DTMF dual-tone multifrequency

This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. [STANDARDS-TRACK]

 draft-ietf-avt-tones-07 RFC4733 RFC4734 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2833 RFC2834 ARP and IP Broadcast over HIPPI-800 J.-M. Pittet May 2000 ASCII HTML 34 ARP address resolution protocol IP internet protocol high-performance parallel interface

This document specifies a method for resolving IP addresses to ANSI High-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP (hardware addresses). This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System Network, GSN). This document (when combined with RFC 2067 "IP over HIPPI") obsoletes RFC 1374. [STANDARDS-TRACK]

 draft-pittet-hippiarp-05 RFC1374 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2834 10.17487/RFC2834 RFC2835 IP and ARP over HIPPI-6400 (GSN) J.-M. Pittet May 2000 ASCII HTML 33 GSN Gigabyte System Network ARP address resolution protocol internet HIPPI high-performance parallel interface

This document further specifies a method for resolving IP addresses to HIPPI-6400 (High-Performance Parallel Interface) hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore, it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks. [STANDARDS-TRACK]

 draft-pittet-gsnlan-04 RFC5494 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2835 RFC2836 Per Hop Behavior Identification Codes S. Brim B. Carpenter F. Le Faucheur May 2000 ASCII HTML 7 PHB differentiated services codepoint DSCP

This document defines a binary encoding to uniquely identify PHBs (Per Hop Behaviors) and/or sets of PHBs in protocol messages. [STANDARDS-TRACK]

 draft-ietf-diffserv-phbid-00 RFC3140 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv 10.17487/RFC2836 RFC2837 Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard K. Teow May 2000 ASCII HTML 48 MIB management information base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. [STANDARDS-TRACK]

 draft-ietf-ipfc-fabric-element-mib-07 RFC4044 PROPOSED STANDARD PROPOSED STANDARD IETF int ipfc 10.17487/RFC2837 RFC2838 Uniform Resource Identifiers for Television Broadcasts D. Zigmond M. Vickers May 2000 ASCII HTML 6 URI TV WWW world wide web

This document describes a widely-implemented URI scheme, as World-Wide Web browsers are starting to appear on a variety of consumer electronic devices, such as television sets and television set-top boxes, which are capable of receiving television programming from either terrestrial broadcast, satellite broadcast, or cable. In this context there is a need to reference television broadcasts using the URI format described in RFC 2396. This memo provides information for the Internet community.

 draft-zigmond-tv-url-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2838 RFC2839 Internet Kermit Service F. da Cruz J. Altman May 2000 ASCII HTML 20 file transfer management service

This document describes a new file transfer service for the Internet based on Telnet Protocol for option negotiation and Kermit Protocol for file transfer and management. This memo provides information for the Internet community.

 draft-columbia-kermit-service-03 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2839 10.17487/RFC2839 RFC2840 TELNET KERMIT OPTION J. Altman F. da Cruz May 2000 ASCII HTML 12 file transfer management service

This document describes an extension to the Telnet protocol to allow the negotiation, coordination, and use of the Kermit file transfer and management protocol over an existing Telnet protocol connection. This memo provides information for the Internet community.

 draft-altman-telnet-kermit-server-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2840 RFC2841 IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC) P. Metzger W. Simpson November 2000 ASCII HTML 9 IP-MAC encryption SHA1 secure hash algorithm

This document describes the use of keyed SHA1 (Secure Hash Algorithm) with the IP Authentication Header. This memo defines a Historic Document for the Internet community.

 draft-simpson-ah-sha-kdp-00 RFC1852 HISTORIC HISTORIC Legacy 10.17487/RFC2841 RFC2842 Capabilities Advertisement with BGP-4 R. Chandra J. Scudder May 2000 ASCII HTML 5 border gateway protocol

This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability advertisement without requiring that BGP peering be terminated. [STANDARDS-TRACK]

 draft-ietf-idr-bgp4-cap-neg-06 RFC3392 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2842 RFC2843 Proxy-PAR P. Droz T. Przygienda May 2000 ASCII HTML 13 PNNI augmented Routing ATM asynchronous transfer mode

The intention of this document is to provide general information about Proxy-PAR (PNNI Augmented Routing). [STANDARDS-TRACK]

 draft-ietf-ion-proxypar-arch-02 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2843 RFC2844 OSPF over ATM and Proxy-PAR T. Przygienda P. Droz R. Haas May 2000 ASCII HTML 14 PNNI Augmented Routing ATM asynchronous transfer mode OSPF open shortest-path first

This memo specifies, for OSPF implementors and users, mechanisms describing how the protocol operates in ATM networks over PVC (Permanent Virtual Connections) and SVC (Switched Virtual Circuit) meshes with the presence of Proxy-PAR (PNNI Augmented Routing). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ospf-atm-04 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC2844 RFC2845 Secret Key Transaction Authentication for DNS (TSIG) P. Vixie O. Gudmundsson D. Eastlake 3rd B. Wellington May 2000 ASCII HTML 15 domain name system transaction signature

This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. [STANDARDS-TRACK]

 draft-ietf-dnsext-tsig-00 RFC8945 RFC1035 RFC3645 RFC4635 RFC6895 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC2845 RFC2846 GSTN Address Element Extensions in E-mail Services C. Allocchio June 2000 ASCII HTML 35 GSTN global switched telephone network

This memo defines a full syntax for a specific application in which there is a need to represent GSTN (Global Switched Telephone Network) addressing and Internet addressing. [STANDARDS-TRACK]

 draft-ietf-fax-fulladdr-06 RFC3191 RFC3192 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=2846 10.17487/RFC2846 RFC2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM M. Eisler June 2000 ASCII HTML 22 LIPKEY Low Infrastructure Public Key SPKM Simple Public Key Mechanism client server authentication

This memorandum describes a method whereby one can use GSS-API (Generic Security Service Application Program Interface) to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. [STANDARDS-TRACK]

 draft-ietf-cat-lipkey-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2847 RFC2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services S. Petrack L. Conroy June 2000 ASCII HTML 73 PINT PSTN/Internet Interworking SIP session initiation protocol SDP Session Description Protocol internet

This document contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. [STANDARDS-TRACK]

 draft-ietf-pint-protocol-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec trans 10.17487/RFC2848 RFC2849 The LDAP Data Interchange Format (LDIF) - Technical Specification G. Good June 2000 ASCII HTML 14 LDIF LDAP lightweight directory access protocol Data Interchange Format file

This document describes a file format suitable for describing directory information or modifications made to directory information. [STANDARDS-TRACK]

 draft-good-ldap-ldif-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2849 10.17487/RFC2849 RFC2850 Charter of the Internet Architecture Board (IAB) Internet Architecture Board B. Carpenter Editor May 2000 ASCII HTML 8 ISOC Internet Society IETF IRTF

This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-iab-rfc1601bis-04 RFC1601 RFC9283 BCP0039 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC2850 RFC2851 Textual Conventions for Internet Network Addresses M. Daniele B. Haberman S. Routhier J. Schoenwaelder June 2000 ASCII HTML 16 layer management information base inet address mib

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. [STANDARDS-TRACK]

 draft-ops-endpoint-mib-08 RFC3291 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2851 RFC2852 Deliver By SMTP Service Extension D. Newman June 2000 ASCII HTML 13 SMTP simple mail transfer protocol client server

This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. [STANDARDS-TRACK]

 draft-newman-deliver-03 RFC1894 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2852 10.17487/RFC2852 RFC2853 Generic Security Service API Version 2 : Java Bindings J. Kabat M. Upadhyay June 2000 ASCII HTML 96 GSS-API Generic Security Service Application Program Interface

This document specifies the Java bindings for GSS-API (Generic Security Service Application Program Interface) which is described at a language independent conceptual level in RFC 2743. [STANDARDS-TRACK]

 draft-ietf-cat-gssv2-javabind-05 RFC5653 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2853 RFC2854 The 'text/html' Media Type D. Connolly L. Masinter June 2000 ASCII HTML 8 HTML-INT HTML WWW World Wide Web

This document summarizes the history of HTML development, and defines the "text/html" MIME type by pointing to the relevant W3C recommendations. This memo provides information for the Internet community.

 draft-connolly-text-html-02 RFC2070 RFC1980 RFC1942 RFC1867 RFC1866 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2854 RFC2855 DHCP for IEEE 1394 K. Fujisawa June 2000 ASCII HTML 5 DHCP dynamic host configuration protocol high performance serial bus

This memo describes specific usage of some fields of DHCP (Dynamic Host Configuration Protocol) messages. IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. Since 1394 uses a different link-layer addressing method than conventional IEEE802/Ethernet, the usage of some fields must be clarified to achieve interoperability. [STANDARDS-TRACK]

 draft-ietf-ip1394-dhcp-04 PROPOSED STANDARD PROPOSED STANDARD IETF int ip1394 10.17487/RFC2855 RFC2856 Textual Conventions for Additional High Capacity Data Types A. Bierman K. McCloghrie R. Presuhn June 2000 ASCII HTML 10 SNMP simple network management protocol

This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. [STANDARDS-TRACK]

 draft-kzm-hcdata-types-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2856 RFC2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH A. Keromytis N. Provos June 2000 ASCII HTML 7 ipsec Internet Protocol Security ESP encapsulating security payload AH authentication header

This memo describes the use of the HMAC algorithm in conjunction with the RIPEMD-160 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload (ESP) and the revised IPSEC Authentication Header (AH). [STANDARDS-TRACK]

 draft-ietf-ipsec-auth-hmac-ripemd-160-96-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2857 RFC2858 Multiprotocol Extensions for BGP-4 T. Bates Y. Rekhter R. Chandra D. Katz June 2000 ASCII HTML 11 MEXT-BGP4 Border gateway protocol router network layer

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). [STANDARDS-TRACK]

 draft-ietf-idr-bgp4-multiprotocol-v2-05 RFC2283 RFC4760 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=2858 10.17487/RFC2858 RFC2859 A Time Sliding Window Three Colour Marker (TSWTCM) W. Fang N. Seddigh B. Nandy June 2000 ASCII HTML 9 TSWTCM Time Sliding Window Three Colour Marker packets traffic stream routers

This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner. This memo defines an Experimental Protocol for the Internet community.

 draft-fang-diffserv-tc-tswtcm-01 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2859 RFC2860 Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority B. Carpenter F. Baker M. Roberts June 2000 ASCII HTML 7 mou iana ietf icann engineering task force corporation names

This document places on record the text of the Memorandum of Understanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. This memo provides information for the Internet community.

 draft-iab-iana-mou-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2860 RFC2861 TCP Congestion Window Validation M. Handley J. Padhye S. Floyd June 2000 ASCII HTML 11 TCP transmission control protocol

This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window. This memo defines an Experimental Protocol for the Internet community.

 draft-handley-tcp-cwv-02 RFC7661 HISTORIC EXPERIMENTAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=2861 10.17487/RFC2861 RFC2862 RTP Payload Format for Real-Time Pointers M. Civanlar G. Cash June 2000 ASCII HTML 7 RTP Transport Protocol for Real Time Applications view graphs resolution audio video signals

This document describes an RTP payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. [STANDARDS-TRACK]

 draft-ietf-avt-pointer-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2862 RFC2863 The Interfaces Group MIB K. McCloghrie F. Kastenholz June 2000 ASCII HTML 69 INTERGRMIB Interfaces Group Management Information Base Network

This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. [STANDARDS-TRACK]

 draft-ietf-ifmib-ifmib2-03 RFC2233 RFC8892 DRAFT STANDARD DRAFT STANDARD IETF int ifmib http://www.rfc-editor.org/errata_search.php?rfc=2863 10.17487/RFC2863 RFC2864 The Inverted Stack Table Extension to the Interfaces Group MIB K. McCloghrie G. Hanson June 2000 ASCII HTML 11 MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects which provide an inverted mapping of the interface stack table used for managing network interfaces. [STANDARDS-TRACK]

 draft-ietf-ifmib-invstackmib-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC2864 RFC2865 Remote Authentication Dial In User Service (RADIUS) C. Rigney S. Willens A. Rubens W. Simpson June 2000 ASCII HTML 76 RADIUS Remote Authentication Dial In User Service encryption NAS Network Access Server

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]

 draft-ietf-radius-radius-v2-06 RFC2138 RFC2868 RFC3575 RFC5080 RFC6929 RFC8044 DRAFT STANDARD DRAFT STANDARD IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2865 10.17487/RFC2865 RFC2866 RADIUS Accounting C. Rigney June 2000 ASCII HTML 28 RADIUS-ACC remote authentication dial in user service encryption

This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community.

 draft-ietf-radius-accounting-v2-05 RFC2139 RFC2867 RFC5080 RFC5997 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2866 10.17487/RFC2866 RFC2867 RADIUS Accounting Modifications for Tunnel Protocol Support G. Zorn B. Aboba D. Mitton June 2000 ASCII HTML 11 RADIUS Remote Authentication Dial In User Service encryption NAS Network Access Server

This document defines new RADIUS (Remote Authentication Dial In User Service) accounting Attributes and new values for the existing Acct- Status-Type Attribute designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community.

 draft-ietf-radius-tunnel-acct-05 RFC2866 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2867 10.17487/RFC2867 RFC2868 RADIUS Attributes for Tunnel Protocol Support G. Zorn D. Leifer A. Rubens J. Shriver M. Holdrege I. Goyret June 2000 ASCII HTML 20 RADIUS encryption NAS Network Access Server

This document defines a set of RADIUS (Remote Authentication Dial In User Service) attributes designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community.

 draft-ietf-radius-tunnel-auth-09 RFC2865 RFC3575 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2868 10.17487/RFC2868 RFC2869 RADIUS Extensions C. Rigney W. Willats P. Calhoun June 2000 ASCII HTML 47 RADIUS encryption NAS Network Access Server

This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 and RFC 2866. This memo provides information for the Internet community.

 draft-ietf-radius-ext-07 RFC3579 RFC5080 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2869 RFC2870 Root Name Server Operational Requirements R. Bush D. Karrenberg M. Kosters R. Plzak June 2000 ASCII HTML 10 infrastructure domain names security

The primary focus of this document is to provide guidelines for operation of the root name servers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsop-root-opreq-05 RFC2010 RFC7720 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC2870 RFC2871 A Framework for Telephony Routing over IP J. Rosenberg H. Schulzrinne June 2000 ASCII HTML 25 internet protocol TRIP gateway

This document serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. This memo provides information for the Internet community.

 draft-ietf-iptel-gwloc-framework-06 INFORMATIONAL INFORMATIONAL IETF rai iptel 10.17487/RFC2871 RFC2872 Application and Sub Application Identity Policy Element for Use with RSVP Y. Bernet R. Pabbati June 2000 ASCII HTML 6 RSVP resource reservation protocol

RSVP signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used by RSVP aware network elements to apply appropriate policy decisions to a traffic flow. This memo details the usage of policy elements that provide application information. [STANDARDS-TRACK]

 draft-ietf-rap-rsvp-appid-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2872 RFC2873 TCP Processing of the IPv4 Precedence Field X. Xiao A. Hannan V. Paxson E. Crabbe June 2000 ASCII HTML 8 TCP transmission control protocol IPv4 internet

This memo describes a conflict between TCP and DiffServ on the use of the three leftmost bits in the TOS octet of an IPv4 header. [STANDARDS-TRACK]

 draft-xiao-tcp-prec-03 RFC9293 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2873 10.17487/RFC2873 RFC2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering M. Crawford C. Huitema July 2000 ASCII HTML 20 DNS IPv6 internet protocol domain name system

This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. [STANDARDS-TRACK]

 draft-ietf-ipngwg-dns-lookups-08 RFC1886 RFC3152 RFC3226 RFC3363 RFC3364 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2874 RFC2875 Diffie-Hellman Proof-of-Possession Algorithms H. Prafullchandra J. Schaad July 2000 ASCII HTML 23 Diffie-Hellman certificate security encryption

This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. [STANDARDS-TRACK]

 draft-ietf-pkix-dhpop-03 RFC6955 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2875 RFC2876 Use of the KEA and SKIPJACK Algorithms in CMS J. Pawling July 2000 ASCII HTML 13 encryption cryptographic message syntax

This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted- data content types. This memo provides information for the Internet community.

 draft-ietf-smime-cmskea-05 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2876 10.17487/RFC2876 RFC2877 5250 Telnet Enhancements T. Murphy Jr. P. Rieth J. Stevens July 2000 ASCII HTML 36 client server printer

This memo describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. This memo provides information for the Internet community.

 draft-ietf-tn3270e-tn5250e-05 RFC4777 RFC1205 INFORMATIONAL INFORMATIONAL IETF app tn3270e 10.17487/RFC2877 RFC2878 PPP Bridging Control Protocol (BCP) M. Higashiyama F. Baker July 2000 ASCII HTML 38 PPP-BCP point-to-point datagrams network

This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK]

 draft-ietf-pppext-bcp-04 RFC1638 RFC3518 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2878 RFC2879 Content Feature Schema for Internet Fax (V2) G. Klyne L. McIntyre August 2000 ASCII HTML 58 media features mechanism

This document defines a content media feature schema for Internet fax. [STANDARDS-TRACK]

 draft-ietf-fax-feature-schema-v2-01 RFC2531 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2879 RFC2880 Internet Fax T.30 Feature Mapping L. McIntyre G. Klyne August 2000 ASCII HTML 37 schema media tags

This document describes how to map Group 3 fax capability identification bits, described in ITU T.30, into the Internet fax feature schema described in "Content feature schema for Internet fax". This memo provides information for the Internet community.

 draft-ietf-fax-feature-T30-mapping-03 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC2880 RFC2881 Network Access Server Requirements Next Generation (NASREQNG) NAS Model D. Mitton M. Beadles July 2000 ASCII HTML 20 RADIUS remote authentication dial-up user service

This document describes the terminology and gives a model of typical Network Access Server (NAS). This memo provides information for the Internet community.

 draft-ietf-nasreq-nasmodel-02 INFORMATIONAL INFORMATIONAL IETF ops nasreq 10.17487/RFC2881 RFC2882 Network Access Servers Requirements: Extended RADIUS Practices D. Mitton July 2000 ASCII HTML 16 NAS remote authentication dial-in user service

This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS (Remote Authentication Dial In User Service) RFCs 2138, 2139. This memo provides information for the Internet community.

 draft-ietf-nasreq-ext-radiuspract-03 INFORMATIONAL INFORMATIONAL IETF ops nasreq 10.17487/RFC2882 RFC2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP S. Floyd J. Mahdavi M. Mathis M. Podolsky July 2000 ASCII HTML 17 SACK Extension to the Selective Acknowledgement TCP transmission control protocol packets sender receiver

This note defines an extension of the Selective Acknowledgement (SACK) Option for TCP. [STANDARDS-TRACK]

 draft-floyd-sack-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=2883 10.17487/RFC2883 RFC2884 Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks J. Hadi Salim U. Ahmed July 2000 ASCII HTML 18 internet protocol end-to-end TCP transmission control

This memo presents a performance study of the Explicit Congestion Notification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. This memo provides information for the Internet community.

 draft-hadi-jhsua-ecnperf-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2884 RFC2885 Megaco Protocol version 0.8 F. Cuervo N. Greene C. Huitema A. Rayhan B. Rosen J. Segers August 2000 ASCII HTML 170 H.248 media gateway control

This document is common text with Recommendation H.248 as redetermined in Geneva, February 2000. It must be read in conjunction with the Megaco Errata, RFC 2886. [STANDARDS-TRACK]

 draft-ietf-megaco-protocol-08 RFC3015 HISTORIC PROPOSED STANDARD IETF rai megaco 10.17487/RFC2885 RFC2886 Megaco Errata T. Taylor August 2000 ASCII HTML 21 H.248 media gateway control

This document records the errors found in the Megaco/H.248 protocol document, along with the changes proposed in the text of that document to resolve them. [STANDARDS-TRACK]

 draft-ietf-megaco-errata-03 RFC3015 HISTORIC PROPOSED STANDARD IETF rai megaco 10.17487/RFC2886 RFC2887 The Reliable Multicast Design Space for Bulk Data Transfer M. Handley S. Floyd B. Whetten R. Kermode L. Vicisano M. Luby August 2000 ASCII HTML 22 application RM congestion control data

This document provides an overview of the design space and the ways in which application constraints affect possible solutions. This memo provides information for the Internet community.

 draft-ietf-rmt-design-space-01 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC2887 RFC2888 Secure Remote Access with L2TP P. Srisuresh August 2000 ASCII HTML 19 layer two tunneling protocol

The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This memo provides information for the Internet community.

 draft-srisuresh-secure-ra-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2888 RFC2889 Benchmarking Methodology for LAN Switching Devices R. Mandeville J. Perser August 2000 ASCII HTML 35 local area network MAC medium access control

This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices. This memo provides information for the Internet community.

 draft-ietf-bmwg-mswitch-04 INFORMATIONAL INFORMATIONAL IETF ops bmwg http://www.rfc-editor.org/errata_search.php?rfc=2889 10.17487/RFC2889 RFC2890 Key and Sequence Number Extensions to GRE G. Dommety September 2000 ASCII HTML 7 GRE generic routing encapsulation

This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header. [STANDARDS-TRACK]

 draft-dommety-gre-ext-04 RFC2784 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2890 RFC2891 LDAP Control Extension for Server Side Sorting of Search Results T. Howes M. Wahl A. Anantha August 2000 ASCII HTML 8 LDAP lightweight directory access protocol

This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. [STANDARDS-TRACK]

 draft-ietf-ldapext-sorting-03 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2891 RFC2892 The Cisco SRP MAC Layer Protocol D. Tsiang G. Suwala August 2000 ASCII HTML 52 spatial reuse

This document specifies the MAC layer protocol, "Spatial Reuse Protocol" (SRP) for use with ring based media. This is a second version of the protocol (V2). This memo provides information for the Internet community.

 draft-tsiang-srp-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2892 RFC2893 Transition Mechanisms for IPv6 Hosts and Routers R. Gilligan E. Nordmark August 2000 ASCII HTML 29 TRANS-IPV6 IPv4

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]

 draft-ietf-ngtrans-mech-06 RFC1933 RFC4213 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC2893 RFC2894 Router Renumbering for IPv6 M. Crawford August 2000 ASCII HTML 32 IPv6 internet protocol operations scalability applicability

This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. [STANDARDS-TRACK]

 draft-ietf-ipngwg-router-renum-10 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2894 RFC2895 Remote Network Monitoring MIB Protocol Identifier Reference A. Bierman C. Bucci R. Iddon August 2000 ASCII HTML 42 RMON-MIB Remote Network Monitoring management information base

This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding ``INDEX`` values for the protocolDirTable, found in the RMON-2 MIB. [STANDARDS-TRACK]

 draft-ietf-rmonmib-rmonprot-ref-01 RFC2074 RFC3395 DRAFT STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC2895 RFC2896 Remote Network Monitoring MIB Protocol Identifier Macros A. Bierman C. Bucci R. Iddon August 2000 ASCII HTML 84 RMON management information base

This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable ``INDEX`` encodings, as defined by the Remote Network Monitoring MIB and the RMON Protocol Identifier Reference. This memo provides information for the Internet community.

 draft-ietf-rmonmib-rmonprot-mac-02 INFORMATIONAL INFORMATIONAL IETF ops rmonmib 10.17487/RFC2896 RFC2897 Proposal for an MGCP Advanced Audio Package D. Cromwell August 2000 ASCII HTML 34 media gateway control protocol IVR interactive voice response

This document is a proposal to add a new event/signal package to the MGCP (Media Gateway Control Protocol) protocol to control an ARF (Audio Resource Function) which may reside on a Media Gateway or specialized Audio Server. This memo provides information for the Internet community.

 draft-cromwell-mgcp-advanced-audio-pkg-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2897 RFC2898 PKCS #5: Password-Based Cryptography Specification Version 2.0 B. Kaliski September 2000 ASCII HTML 34 public-key authentication encryption

This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. This memo provides information for the Internet community.

 draft-kaliski-pkcs5-v2-04 RFC8018 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2898 10.17487/RFC2898 RFC2899 Request for Comments Summary RFC Numbers 2800-2899 S. Ginoza May 2001 ASCII HTML 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2899 RFC2900 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza August 2001 ASCII HTML 42

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 17, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. This memo is an Internet Standard.

 RFC2800 RFC3000 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2900 RFC2901 Guide to Administrative Procedures of the Internet Infrastructure Z. Wenzel J. Klensin R. Bush S. Huter August 2000 ASCII HTML 31 address space routing database domain name registration

This document describes the administrative procedures for networks seeking to connect to the global Internet. This memo provides information for the Internet community.

 draft-wenzel-nsrc-02 FYI0037 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2901 RFC2902 Overview of the 1998 IAB Routing Workshop S. Deering S. Hares C. Perkins R. Perlman August 2000 ASCII HTML 16 internet architecture board

This document is an overview of a Routing workshop held by the Internet Architecture Board (IAB) during March 25-27, 1998. This memo provides information for the Internet community.

 draft-iab-rtrws-over-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2902 RFC2903 Generic AAA Architecture C. de Laat G. Gross L. Gommans J. Vollbrecht D. Spence August 2000 ASCII HTML 26 AAA authentication authorization accounting

This memo proposes an Authentication, Authorization, Accounting (AAA) architecture that would incorporate a generic AAA server along with an application interface to a set of Application Specific Modules that could perform application specific AAA functions. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-aaaarch-generic-01 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2903 RFC2904 AAA Authorization Framework J. Vollbrecht P. Calhoun S. Farrell L. Gommans G. Gross B. de Bruijn C. de Laat M. Holdrege D. Spence August 2000 ASCII HTML 35 authentication authorization accounting

This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols. This memo provides information for the Internet community.

 draft-irtf-aaaarch-authorization-framework-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2904 RFC2905 AAA Authorization Application Examples J. Vollbrecht P. Calhoun S. Farrell L. Gommans G. Gross B. de Bruijn C. de Laat M. Holdrege D. Spence August 2000 ASCII HTML 53 authentication authorization accounting

This memo describes several examples of applications requiring authorization. This memo provides information for the Internet community.

 draft-irtf-aaaarch-authorization-apps-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2905 RFC2906 AAA Authorization Requirements S. Farrell J. Vollbrecht P. Calhoun L. Gommans G. Gross B. de Bruijn C. de Laat M. Holdrege D. Spence August 2000 ASCII HTML 23 authentication authorization accounting

This document specifies the requirements that Authentication Authorization Accounting (AAA) protocols must meet in order to support authorization services in the Internet. This memo provides information for the Internet community.

 draft-irtf-aaaarch-authorization-reqs-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2906 RFC2907 MADCAP Multicast Scope Nesting State Option R. Kermode September 2000 ASCII HTML 13 MADCAP multicast address dynamic client allocation protocol

This document defines a new option to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) to support nested scoping. [STANDARDS-TRACK]

 draft-ietf-malloc-madcap-nest-opt-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC2907 RFC2908 The Internet Multicast Address Allocation Architecture D. Thaler M. Handley D. Estrin September 2000 ASCII HTML 13 MALLOC host server intra-domain inter-domain

This document proposes a multicast address allocation architecture (MALLOC) for the Internet. This memo provides information for the Internet community.

 draft-ietf-malloc-arch-05 RFC6308 HISTORIC INFORMATIONAL IETF tsv malloc 10.17487/RFC2908 RFC2909 The Multicast Address-Set Claim (MASC) Protocol P. Radoslavov D. Estrin R. Govindan M. Handley S. Kumar D. Thaler September 2000 ASCII HTML 56 MASC Multicast Address-Set Claim Protocol inter-domain router

This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-malloc-masc-06 HISTORIC EXPERIMENTAL IETF tsv malloc 10.17487/RFC2909 RFC2910 Internet Printing Protocol/1.1: Encoding and Transport R. Herriot Editor S. Butler P. Moore R. Turner J. Wenn September 2000 ASCII HTML 46 IPP-E-T Internet Printing Protocol Encoding Transport application media type

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS-TRACK]

 draft-ietf-ipp-protocol-v11-06 RFC2565 RFC8010 RFC3380 RFC3381 RFC3382 RFC3510 RFC3995 RFC7472 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=2910 10.17487/RFC2910 RFC2911 Internet Printing Protocol/1.1: Model and Semantics T. Hastings Editor R. Herriot R. deBry S. Isaacson P. Powell September 2000 ASCII HTML 224 IPP-M-S Internet Printing Protocol Model Semantics application media type job

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS-TRACK]

 draft-ietf-ipp-model-v11-07 RFC2566 RFC8011 RFC3380 RFC3382 RFC3996 RFC3995 RFC7472 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=2911 10.17487/RFC2911 RFC2912 Indicating Media Features for MIME Content G. Klyne September 2000 ASCII HTML 11 MIME multipurpose internet mail extensions tag format

This memo defines a Multipurpose Internet Mail Extensions (MIME) ' Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used. [STANDARDS-TRACK]

 draft-ietf-conneg-content-features-03 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2912 RFC2913 MIME Content Types in Media Feature Expressions G. Klyne September 2000 ASCII HTML 9 MIME multipurpose internet mail extensions tag format

This memo defines a media feature tag whose value is a Multipurpose Internet Mail Extensions (MIME) content type. [STANDARDS-TRACK]

 draft-ietf-conneg-feature-type-03 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2913 RFC2914 Congestion Control Principles S. Floyd September 2000 ASCII HTML 17 end-to-end

The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-floyd-cong-04 RFC7141 BCP0041 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv ecm 10.17487/RFC2914 RFC2915 The Naming Authority Pointer (NAPTR) DNS Resource Record M. Mealling R. Daniel September 2000 ASCII HTML 18 NAPTR domain name system RR

This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label or Uniform Resource Identifier (URI). [STANDARDS-TRACK]

 draft-ietf-urn-naptr-rr-04 RFC3401 RFC3402 RFC3403 RFC3404 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn 10.17487/RFC2915 RFC2916 E.164 number and DNS P. Faltstrom September 2000 ASCII HTML 10 DNS domain name system E.164

This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. [STANDARDS-TRACK]

 draft-ietf-enum-e164-dns-03 RFC3761 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum http://www.rfc-editor.org/errata_search.php?rfc=2916 10.17487/RFC2916 RFC2917 A Core MPLS IP VPN Architecture K. Muthukrishnan A. Malis September 2000 ASCII HTML 16 internet protocol virtual private networks multiprotocol label switching

This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This memo provides information for the Internet community.

 draft-muthukrishnan-mpls-corevpn-arch-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2917 RFC2918 Route Refresh Capability for BGP-4 E. Chen September 2000 ASCII HTML 4 BGP border gateway protocol

This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. [STANDARDS-TRACK]

 draft-ietf-idr-bgp-route-refresh-01 RFC7313 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2918 RFC2919 List-Id: A Structured Field and Namespace for the Identification of Mailing Lists R. Chandhok G. Wenger March 2001 ASCII HTML 9 server clients user agents

Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time. [STANDARDS-TRACK]

 draft-chandhok-listid-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2919 10.17487/RFC2919 RFC2920 SMTP Service Extension for Command Pipelining N. Freed September 2000 ASCII HTML 9 SMTP-Pipe simple mail transfer protocol TCP transmission control protocol

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission Control Protocol (TCP) send operation. [STANDARDS-TRACK]

 draft-freed-smtp-pipe-01 RFC2197 STD0060 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC2920 RFC2921 6BONE pTLA and pNLA Formats (pTLA) B. Fink September 2000 ASCII HTML 7 IPv6 internet protocol pseudo top-level next-level aggregation identifiers

This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471, "IPv6 Testing Address Allocation", to create pseudo Top-Level Aggregation Identifiers (pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's). This memo provides information for the Internet community.

 draft-ietf-ngtrans-6bone-ptla-00 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2921 RFC2922 Physical Topology MIB A. Bierman K. Jones September 2000 ASCII HTML 32 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing physical topology identification and discovery. This memo provides information for the Internet community.

 draft-ietf-ptopomib-mib-05 INFORMATIONAL INFORMATIONAL IETF ops ptopomib 10.17487/RFC2922 RFC2923 TCP Problems with Path MTU Discovery K. Lahey September 2000 ASCII HTML 15 transmission control protocol maximum unit

This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU. This memo provides information for the Internet community.

 draft-ietf-tcpimpl-pmtud-04 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2923 RFC2924 Accounting Attributes and Record Formats N. Brownlee A. Blount September 2000 ASCII HTML 36 data transport integrated

This document summarises Internet Engineering Task Force (IETF) and International Telecommunication Union (ITU-T) documents related to Accounting. This memo provides information for the Internet community.

 draft-ietf-aaa-accounting-attributes-04 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC2924 RFC2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations K. White September 2000 ASCII HTML 77 mib management information base

This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. [STANDARDS-TRACK]

 draft-ietf-disman-remops-mib-08 RFC4560 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=2925 10.17487/RFC2925 RFC2926 Conversion of LDAP Schemas to and from SLP Templates J. Kempf R. Moats P. St. Pierre September 2000 ASCII HTML 27 service location protocol lightweight directory access

This document describes a procedure for mapping between Service Location Protocol (SLP) service advertisements and lightweight directory access protocol (LDAP) descriptions of services. This memo provides information for the Internet community.

 draft-ietf-svrloc-template-conversion-08 INFORMATIONAL INFORMATIONAL IETF int svrloc 10.17487/RFC2926 RFC2927 MIME Directory Profile for LDAP Schema M. Wahl September 2000 ASCII HTML 10 lightweight directory access protocol multipurpose internet mail extensions

This document defines a multipurpose internet mail extensions (MIME) directory profile for holding a lightweight directory access protocol (LDAP) schema. This memo provides information for the Internet community.

 draft-ietf-schema-ldap-01 INFORMATIONAL INFORMATIONAL IETF app schema http://www.rfc-editor.org/errata_search.php?rfc=2927 10.17487/RFC2927 RFC2928 Initial IPv6 Sub-TLA ID Assignments R. Hinden S. Deering R. Fink T. Hain September 2000 ASCII HTML 7 internet protocol sub-top-level aggregation identifiers address registries

This document defines initial assignments of IPv6 Sub-Top-Level Aggregation Identifiers (Sub-TLA ID) to the Address Registries. This memo provides information for the Internet community.

 draft-ietf-ipngwg-iana-tla-03 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2928 RFC2929 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd E. Brunner-Williams B. Manning September 2000 ASCII HTML 12 internet assigned numbers authority resource records RRs

This document discusses the Internet Assigned Number Authority (IANA) parameter assignment considerations given for the allocation of Domain Name System (DNS) classes, Resource Record (RR) types, operation codes, error codes, etc. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsext-iana-dns-01 RFC5395 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC2929 RFC2930 Secret Key Establishment for DNS (TKEY RR) D. Eastlake 3rd September 2000 ASCII HTML 16 TKEY-RR DNS domain name system resource record transaction key

This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. [STANDARDS-TRACK]

 draft-ietf-dnsext-tkey-04 RFC6895 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC2930 RFC2931 DNS Request and Transaction Signatures ( SIG(0)s ) D. Eastlake 3rd September 2000 ASCII HTML 10 DNS domain name system data security

This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK]

 draft-ietf-dnsext-sig-zero-02 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC2931 RFC2932 IPv4 Multicast Routing MIB K. McCloghrie D. Farinacci D. Thaler October 2000 ASCII HTML 27 IPv4 internet protocol MIB management information base multicast

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing IP Multicast Routing for IPv4, independent of the specific multicast routing protocol in use. [STANDARDS-TRACK]

 draft-ietf-idmr-multicast-routmib-13 RFC5132 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr 10.17487/RFC2932 RFC2933 Internet Group Management Protocol MIB K. McCloghrie D. Farinacci D. Thaler October 2000 ASCII HTML 19 igmp Internet Group Management Protocol MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP). [STANDARDS-TRACK]

 draft-ietf-idmr-igmp-mib-14 RFC5519 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr 10.17487/RFC2933 RFC2934 Protocol Independent Multicast MIB for IPv4 K. McCloghrie D. Farinacci D. Thaler B. Fenner October 2000 ASCII HTML 27 PIM Protocol Independent Multicast MIB management information base internet

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol for IPv4. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-idmr-pim-mib-11 EXPERIMENTAL EXPERIMENTAL IETF rtg idmr 10.17487/RFC2934 RFC2935 Internet Open Trading Protocol (IOTP) HTTP Supplement D. Eastlake 3rd C. Smith September 2000 ASCII HTML 8 IOTP-HTTP Internet Open Trading Protocol hypertext transport protocol XML extensible markup language transfer

The goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties. This document describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1. [STANDARDS-TRACK]

 draft-ietf-trade-iotp-http-07 PROPOSED STANDARD PROPOSED STANDARD IETF app trade 10.17487/RFC2935 RFC2936 HTTP MIME Type Handler Detection D. Eastlake 3rd C. Smith D. Soroka September 2000 ASCII HTML 13 multipurpose internet mail extensions hypertext transfer protocol

Entities composing web pages to provide services over the Hypertext Transfer Protocol (HTTP) frequently have the problem of not knowing what Multipurpose Internet Mail Extensions (MIME) types have handlers installed at a user's browser. This document summarizes reasonable techniques to solve this problem for most of the browsers actually deployed on the Internet as of early 2000. This memo provides information for the Internet community.

 draft-ietf-trade-mime-detector-03 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC2936 RFC2937 The Name Service Search Option for DHCP C. Smith September 2000 ASCII HTML 5 DHCP dynamic host configuration protocol

This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information. [STANDARDS-TRACK]

 draft-ietf-dhc-nsso-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2937 RFC2938 Identifying Composite Media Features G. Klyne L. Masinter September 2000 ASCII HTML 18 tags expression hash

This document describes an abbreviated format for a composite media feature set, based upon a hash of the feature expression describing that composite. [STANDARDS-TRACK]

 draft-ietf-conneg-feature-hash-05 RFC2533 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg http://www.rfc-editor.org/errata_search.php?rfc=2938 10.17487/RFC2938 RFC2939 Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types R. Droms September 2000 ASCII HTML 7 dynamic host configuration protocol internet assigned numbers authority

This document describes the procedure for defining new DHCP options and message types. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dhc-new-opt-msg-02 RFC2489 BCP0043 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2939 10.17487/RFC2939 RFC2940 Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients A. Smith D. Partain J. Seligson October 2000 ASCII HTML 27 cops Common Open Policy Service mib management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a client of the Common Open Policy Service (COPS) protocol. [STANDARDS-TRACK]

 draft-ietf-rap-cops-client-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2940 RFC2941 Telnet Authentication Option T. Ts'o Editor J. Altman September 2000 ASCII HTML 15 TOPT-AUTH Telnet Authentication Option encryption Security

This document describes the authentication option to the telnet protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. [STANDARDS-TRACK]

 draft-tso-telnet-auth-enc-05 RFC1416 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2941 RFC2942 Telnet Authentication: Kerberos Version 5 T. Ts'o September 2000 ASCII HTML 7 Telnet Authentication encryption Kerberos

This document describes how Kerberos Version 5 is used with the telnet protocol. It describes an telnet authentication suboption to be used with the telnet authentication option. [STANDARDS-TRACK]

 draft-tso-telnet-krb5-04 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2942 RFC2943 TELNET Authentication Using DSA R. Housley T. Horting P. Yee September 2000 ASCII HTML 12 TELNET DSA digital signature algorithm

This document defines a telnet authentication mechanism using the Digital Signature Algorithm (DSA). It relies on the Telnet Authentication Option. [STANDARDS-TRACK]

 draft-housley-telnet-auth-dsa-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2943 RFC2944 Telnet Authentication: SRP T. Wu September 2000 ASCII HTML 7 Telnet SRP secure remote password protocol

This document specifies an authentication scheme for the Telnet protocol under the framework described in RFC 2941, using the Secure Remote Password Protocol (SRP) authentication mechanism. [STANDARDS-TRACK]

 draft-wu-telnet-auth-srp-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2944 RFC2945 The SRP Authentication and Key Exchange System T. Wu September 2000 ASCII HTML 8 SRP secure remote password protocol

This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. [STANDARDS-TRACK]

 draft-wu-srp-auth-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2945 RFC2946 Telnet Data Encryption Option T. Ts'o September 2000 ASCII HTML 8 Telnet stream authentication

This document describes a the telnet encryption option as a generic method of providing data confidentiality services for the telnet data stream. [STANDARDS-TRACK]

 draft-tso-telnet-encryption-04 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2946 RFC2947 Telnet Encryption: DES3 64 bit Cipher Feedback J. Altman September 2000 ASCII HTML 6 Telnet Triple-DES data encryption standard

This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in cipher feedback mode with the telnet encryption option. [STANDARDS-TRACK]

 draft-altman-telnet-enc-des3-cfb-01 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2947 RFC2948 Telnet Encryption: DES3 64 bit Output Feedback J. Altman September 2000 ASCII HTML 6 Telnet DES data encryption standard

This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in output feedback mode with the telnet encryption option. [STANDARDS-TRACK]

 draft-altman-telnet-enc-des3-ofb-01 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2948 RFC2949 Telnet Encryption: CAST-128 64 bit Output Feedback J. Altman September 2000 ASCII HTML 5 CAST-128 Telnet encryption algorithm option

This document specifies how to use the CAST-128 encryption algorithm in output feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit. [STANDARDS-TRACK]

 draft-altman-telnet-enc-cast128-ofb-00 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2949 RFC2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback J. Altman September 2000 ASCII HTML 5 CAST-128 Telnet encryption algorithm option

This document specifies how to use the CAST-128 encryption algorithm in cipher feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit. [STANDARDS-TRACK]

 draft-altman-telnet-enc-cast128-cfb-00 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2950 RFC2951 TELNET Authentication Using KEA and SKIPJACK R. Housley T. Horting P. Yee September 2000 ASCII HTML 11 key exchange algorithm encryption

This document defines a method to authenticate TELNET using the Key Exchange Algorithm (KEA), and encryption of the TELNET stream using SKIPJACK. This memo provides information for the Internet community.

 draft-housley-telnet-auth-keasj-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2951 RFC2952 Telnet Encryption: DES 64 bit Cipher Feedback T. Ts'o September 2000 ASCII HTML 5 data encryption standard

This document specifies how to use the DES encryption algorithm in cipher feedback mode with the telnet encryption option. This memo provides information for the Internet community.

 draft-tso-telnet-enc-des-cfb-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2952 RFC2953 Telnet Encryption: DES 64 bit Output Feedback T. Ts'o September 2000 ASCII HTML 5 data encryption standard

This document specifies how to use the data encryption standard (DES) encryption algorithm in output feedback mode with the telnet encryption option. This memo provides information for the Internet community.

 draft-tso-telnet-enc-des-ofb-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2953 RFC2954 Definitions of Managed Objects for Frame Relay Service K. Rehbehn D. Fowler October 2000 ASCII HTML 76 FR-MIB Frame Relay Service management information base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in Transmission Control Protocol/Internet Protocol-based (TCP/IP) internets. In particular, it defines objects for managing the frame relay service. [STANDARDS-TRACK]

 draft-ietf-frnetmib-frs-mib-12 RFC1604 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC2954 RFC2955 Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function K. Rehbehn O. Nicklass G. Mouradian October 2000 ASCII HTML 39 ATM asynchronous transfer mode PVC permanent virtual connections MIB management information base

This memo defines a Management Information Base (MIB) to configure, monitor, and control a service interworking function (IWF) for Permanent Virtual Connections (PVC) between Frame Relay and Asynchronous Transfer Mode (ATM) technologies. [STANDARDS-TRACK]

 draft-ietf-frnetmib-atmiwf-06 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC2955 RFC2956 Overview of 1999 IAB Network Layer Workshop M. Kaat October 2000 ASCII HTML 16 intenret architecture board

This document is an overview of a workshop held by the Internet Architecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet. This memo provides information for the Internet community.

 draft-iab-ntwlyrws-over-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2956 RFC2957 The application/whoispp-query Content-Type L. Daigle P. Faltstrom October 2000 ASCII HTML 6 mime multipurpose internet mail extensions media-types

The intention of this document, in conjunction with RFC 2958, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. This memo provides information for the Internet community.

 draft-daigle-wppquery-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2957 RFC2958 The application/whoispp-response Content-type L. Daigle P. Faltstrom October 2000 ASCII HTML 6 mime multipurpose internet mail extensions media-types

The intention of this document, in conjunction with RFC 2957, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. This memo provides information for the Internet community.

 draft-daigle-wppresp-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2958 RFC2959 Real-Time Transport Protocol Management Information Base M. Baugher B. Strahm I. Suconick October 2000 ASCII HTML 31 RTP Real-Time Transport Protocol MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-mib-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2959 RFC2960 Stream Control Transmission Protocol R. Stewart Q. Xie K. Morneault C. Sharp H. Schwarzbauer T. Taylor I. Rytina M. Kalla L. Zhang V. Paxson October 2000 ASCII HTML 134 SCTP IP internet transport packet network

This document describes the Stream Control Transmission Protocol (SCTP). [STANDARDS-TRACK]

 draft-ietf-sigtran-sctp-13 RFC4960 RFC3309 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=2960 10.17487/RFC2960 RFC2961 RSVP Refresh Overhead Reduction Extensions L. Berger D. Gan G. Swallow P. Pan F. Tommasi S. Molendini April 2001 ASCII HTML 34 RSVP resource reservation protocol messages

This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP (Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages. [STANDARDS-TRACK]

 draft-ietf-rsvp-refresh-reduct-05 RFC5063 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2961 RFC2962 An SNMP Application Level Gateway for Payload Address Translation D. Raz J. Schoenwaelder B. Sugla October 2000 ASCII HTML 20 simple network management protocol

This document describes the ALG (Application Level Gateway) for the SNMP (Simple Network Management Protocol) by which IP (Internet Protocol) addresses in the payload of SNMP packets are statically mapped from one group to another. This memo provides information for the Internet community.

 draft-ietf-nat-snmp-alg-05 INFORMATIONAL INFORMATIONAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=2962 10.17487/RFC2962 RFC2963 A Rate Adaptive Shaper for Differentiated Services O. Bonaventure S. De Cnodder October 2000 ASCII HTML 19 RAS TCP transmission control protocol diffserv

This memo describes several Rate Adaptive Shapers (RAS) that can be used in combination with the single rate Three Color Markers (srTCM) and the two rate Three Color Marker (trTCM) described in RFC2697 and RFC2698, respectively. This memo provides information for the Internet community.

 draft-bonaventure-diffserv-rashaper-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2963 RFC2964 Use of HTTP State Management K. Moore N. Freed October 2000 ASCII HTML 8 hypertext transfer protocol

This memo identifies specific uses of Hypertext Transfer Protocol (HTTP) State Management protocol which are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged. This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-iesg-http-cookies-03 BCP0044 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC2964 RFC2965 HTTP State Management Mechanism D. Kristol L. Montulli October 2000 ASCII HTML 26 HTTP hypertext transfer protocol

This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. [STANDARDS-TRACK]

 draft-ietf-http-state-man-mec-12 RFC2109 RFC6265 HISTORIC PROPOSED STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2965 10.17487/RFC2965 RFC2966 Domain-wide Prefix Distribution with Two-Level IS-IS T. Li T. Przygienda H. Smit October 2000 ASCII HTML 14 intermediate system routers loops IP internet protocol

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. This memo provides information for the Internet community.

 draft-ietf-isis-domain-wide-03 RFC5302 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC2966 RFC2967 TISDAG - Technical Infrastructure for Swedish Directory Access Gateways L. Daigle R. Hedberg October 2000 ASCII HTML 105 single point service

The overarching goal of this project is to develop the necessary technical infrastructure to provide a single-access-point service for searching for whitepages information on Swedish Internet users. This memo provides information for the Internet community.

 draft-daigle-tisdag-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2967 RFC2968 Mesh of Multiple DAG servers - Results from TISDAG L. Daigle T. Eklof October 2000 ASCII HTML 9 technical infrastructure swedish directory access gateways mesh index

This document defines the basic principle for establishing a mesh, that interoperating services should exchange index objects, according to the architecture of the mesh (e.g., hierarchical, or graph-like, preferably without loops!). The Common Indexing Protocol (CIP) is designed to facilitate the creation not only of query referral indexes, but also of meshes of (loosely) affiliated referral indexes. The purpose of such a mesh of servers is to implement some kind of distributed sharing of indexing and/or searching tasks across different servers. So far, the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project has focused on creating a single referral index; the obvious next step is to integrate that into a larger set of interoperating services. This memo provides information for the Internet community.

 draft-daigle-dag-mesh-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2968 RFC2969 Wide Area Directory Deployment - Experiences from TISDAG T. Eklof L. Daigle October 2000 ASCII HTML 19 technical infrastructure swedish access gateways

This document catalogues some of the experiences gained in developing the necessary infrastructure for a national (i.e., multi-organizational) directory service and pilot deployment of the service in an environment with off-the-shelf directory service products. This memo provides information for the Internet community.

 draft-eklof-dag-experiences-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2969 RFC2970 Architecture for Integrated Directory Services - Result from TISDAG L. Daigle T. Eklof October 2000 ASCII HTML 18 ids whitepages technical infrastructure swedish access gateways

Drawing from experiences with the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project, this document outlines an approach to providing the necessary infrastructure for integrating such widely-scattered servers into a single service, rather than attempting to mandate a single protocol and schema set for all participating servers to use. This memo provides information for the Internet community.

 draft-daigle-arch-ids-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC2970 RFC2971 IMAP4 ID extension T. Showalter October 2000 ASCII HTML 8 IMAP4 internet message access protocol client server

This document describes an ID extension which will enable Internet Message Access Protocol - Version 4rev1 (IMAP4rev1) to advertise what program a client or server uses to provide service. The ID extension allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete. [STANDARDS-TRACK]

 draft-showalter-imap-id-04 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2971 RFC2972 Context and Goals for Common Name Resolution N. Popp M. Mealling L. Masinter K. Sollins October 2000 ASCII HTML 11 CNRP

This document establishes the context and goals for a Common Name Resolution Protocol. This memo provides information for the Internet community.

 draft-ietf-cnrp-goals-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2972 RFC2973 IS-IS Mesh Groups R. Balay D. Katz J. Parker October 2000 ASCII HTML 8 intermediate system PDU protocol data unit

This document describes a mechanism to reduce redundant packet transmissions for the Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This memo provides information for the Internet community.

 draft-ietf-isis-wg-mesh-group-01 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC2973 RFC2974 Session Announcement Protocol M. Handley C. Perkins E. Whelan October 2000 ASCII HTML 18 SAP Session Announcement Protocol

This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mmusic-sap-v2-06 EXPERIMENTAL EXPERIMENTAL IETF rai mmusic 10.17487/RFC2974 RFC2975 Introduction to Accounting Management B. Aboba J. Arkko D. Harrington October 2000 ASCII HTML 54 resource consumption data cost allocation

This document describes and discusses the issues involved in the design of the modern accounting systems. The field of Accounting Management is concerned with the collection the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This memo provides information for the Internet community.

 draft-ietf-aaa-acct-06 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC2975 RFC2976 The SIP INFO Method S. Donovan October 2000 ASCII HTML 9 SIP session initiation protocol information extension

This document proposes an extension to the Session Initiation Protocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. [STANDARDS-TRACK]

 draft-ietf-sip-info-method-05 RFC6086 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC2976 RFC2977 Mobile IP Authentication, Authorization, and Accounting Requirements S. Glass T. Hiller S. Jacobs C. Perkins October 2000 ASCII HTML 27 AAA internet protocol

This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services. This memo provides information for the Internet community.

 draft-ietf-mobileip-aaa-reqs-04 INFORMATIONAL INFORMATIONAL IETF int mobileip 10.17487/RFC2977 RFC2978 IANA Charset Registration Procedures N. Freed J. Postel October 2000 ASCII HTML 11 character set mime multipurpose internet mail extensions

Multipurpose Internet Mail Extensions (MIME) and various other Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-freed-charset-regist-03 RFC2278 BCP0019 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=2978 10.17487/RFC2978 RFC2979 Behavior of and Requirements for Internet Firewalls N. Freed October 2000 ASCII HTML 7 security intranet network

This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls. This memo provides information for the Internet community.

 draft-iab-firewall-req-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2979 RFC2980 Common NNTP Extensions S. Barber October 2000 ASCII HTML 27 network news transfer protocol

In this document, a number of popular extensions to the Network News Transfer Protocol (NNTP) protocol defined in RFC 977 are documented and discussed. While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol. This memo provides information for the Internet community.

 draft-ietf-nntpext-imp-04 RFC3977 RFC4643 RFC4644 RFC6048 INFORMATIONAL INFORMATIONAL IETF app nntpext 10.17487/RFC2980 RFC2981 Event MIB R. Kavasseri Editor October 2000 ASCII HTML 50 MIB management information base Event

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects that can be used to manage and monitor MIB objects and take action through events. [STANDARDS-TRACK]

 draft-ietf-disman-event-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=2981 10.17487/RFC2981 RFC2982 Distributed Management Expression MIB R. Kavasseri Editor October 2000 ASCII HTML 41 MIB management information base Distributed Management Expression

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing expressions of MIB objects. [STANDARDS-TRACK]

 draft-ietf-disman-express-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC2982 RFC2983 Differentiated Services and Tunnels D. Black October 2000 ASCII HTML 14 internet protocol encapsulation

This document considers the interaction of Differentiated Services (diffserv) with IP tunnels of various forms. This memo provides information for the Internet community.

 draft-ietf-diffserv-tunnels-02 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC2983 RFC2984 Use of the CAST-128 Encryption Algorithm in CMS C. Adams October 2000 ASCII HTML 6 CAST-128 CMS cryptographic message syntax security cipher

This document specifies how to incorporate CAST-128 into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. [STANDARDS-TRACK]

 draft-ietf-smime-cast-128-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC2984 RFC2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0 M. Nystrom B. Kaliski November 2000 ASCII HTML 42 public-key cryptography standards LDAP lightweight directory access protocol

This memo represents a republication of PKCS #9 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification. This memo provides information for the Internet community.

 draft-nystrom-pkcs9-v2-01 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2985 10.17487/RFC2985 RFC2986 PKCS #10: Certification Request Syntax Specification Version 1.7 M. Nystrom B. Kaliski November 2000 ASCII HTML 14 public-key cryptography standards PKCS-10 public key distinguished name encryption data

This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community.

 draft-nystrom-pkcs10-v1-7-00 RFC2314 RFC5967 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2986 RFC2987 Registration of Charset and Languages Media Features Tags P. Hoffman November 2000 ASCII HTML 6 Charset character sets human languages devices

This document contains the registration for two media feature tags: "charset" and "language". [STANDARDS-TRACK]

 draft-hoffman-char-lang-media-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2987 RFC2988 Computing TCP's Retransmission Timer V. Paxson M. Allman November 2000 ASCII HTML 8 TCP transmission control protocol algorithm

This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. [STANDARDS-TRACK]

 draft-paxson-tcp-rto-01 RFC6298 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=2988 10.17487/RFC2988 RFC2989 Criteria for Evaluating AAA Protocols for Network Access B. Aboba P. Calhoun S. Glass T. Hiller P. McCann H. Shiino P. Walsh G. Zorn G. Dommety C. Perkins B. Patil D. Mitton S. Manning M. Beadles X. Chen S. Sivalingham A. Hameed M. Munson S. Jacobs B. Lim B. Hirschman R. Hsu H. Koo M. Lipford E. Campbell Y. Xu S. Baba E. Jaques November 2000 ASCII HTML 28 authentication authorization accounting

This document represents a summary of Authentication, Authorization, Accounting (AAA) protocol requirements for network access. This memo provides information for the Internet community.

 draft-ietf-aaa-na-reqts-07 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC2989 RFC2990 Next Steps for the IP QoS Architecture G. Huston November 2000 ASCII HTML 24 internet protocol quality of service end-to-end

This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets. This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board. This memo provides information for the Internet community.

 draft-iab-qos-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2990 RFC2991 Multipath Issues in Unicast and Multicast Next-Hop Selection D. Thaler C. Hopps November 2000 ASCII HTML 9 routing forwarding packets ECMP

The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next-hop should be used for a given data packet. This memo summarizes current practices, problems, and solutions. This memo provides information for the Internet community.

 draft-thaler-multipath-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2991 RFC2992 Analysis of an Equal-Cost Multi-Path Algorithm C. Hopps November 2000 ASCII HTML 8 ECMP routing packets forwarding

Equal-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost. The forwarding engine identifies paths by next-hop. When forwarding a packet the router must decide which next-hop (path) to use. This document gives an analysis of one method for making that decision. The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops. This memo provides information for the Internet community.

 draft-hopps-ecmp-algo-analysis-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2992 RFC2993 Architectural Implications of NAT T. Hain November 2000 ASCII HTML 29 network address translation

This document discusses some of the architectural implications and guidelines for implementations of Network Address Translation (NAT). This memo provides information for the Internet community.

 draft-iab-nat-implications-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2993 RFC2994 A Description of the MISTY1 Encryption Algorithm H. Ohta M. Matsui November 2000 ASCII HTML 10 cryptosystem security data stream

This document describes a secret-key cryptosystem MISTY1, which is block cipher with a 128-bit key, a 64-bit block and a variable number of rounds. It documents the algorithm description including key scheduling part and data randomizing part. This memo provides information for the Internet community.

 draft-ohta-misty1desc-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2994 RFC2995 Pre-Spirits Implementations of PSTN-initiated Services H. Lu Editor I. Faynberg J. Voelker M. Weissman W. Zhang S. Rhim J. Hwang S. Ago S. Moeenuddin S. Hadvani S. Nyckelgard J. Yoakum L. Robart November 2000 ASCII HTML 44 public switched telephone network

This document describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN. This memo provides information for the Internet community.

 draft-ietf-spirits-implementations-02 INFORMATIONAL INFORMATIONAL IETF tsv spirits 10.17487/RFC2995 RFC2996 Format of the RSVP DCLASS Object Y. Bernet November 2000 ASCII HTML 9 RSVP resource reservation protocol QoS Quality of Service

This document specifies the format of the DCLASS object and briefly discusses its use. [STANDARDS-TRACK]

 draft-ietf-issll-dclass-01 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2996 RFC2997 Specification of the Null Service Type Y. Bernet A. Smith B. Davie November 2000 ASCII HTML 12 RSVP resource reservation protocol QoS Quality of Service

The Null Service allows applications to identify themselves to network Quality of Service (QoS) policy agents, using RSVP signaling. However, it does not require them to specify resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service. [STANDARDS-TRACK]

 draft-ietf-issll-nullservice-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2997 RFC2998 A Framework for Integrated Services Operation over Diffserv Networks Y. Bernet P. Ford R. Yavatkar F. Baker L. Zhang M. Speer R. Braden B. Davie J. Wroclawski E. Felstaine November 2000 ASCII HTML 31 intserv QoS Quality of Service end-to-end

This document describes a framework by which Integrated Services may be supported over Diffserv networks. This memo provides information for the Internet community.

 draft-ietf-issll-diffserv-rsvp-05 INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2998 RFC2999 Request for Comments Summary RFC Numbers 2900-2999 S. Ginoza August 2001 ASCII HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2999 RFC3000 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza L. Shiota November 2001 ASCII HTML 43

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 25, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. [STANDARDS-TRACK]

 RFC2900 RFC3300 HISTORIC INTERNET STANDARD INDEPENDENT 10.17487/RFC3000 RFC3001 A URN Namespace of Object Identifiers M. Mealling November 2000 ASCII HTML 5 uniform resource names OIDs

This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community.

 draft-mealling-oid-urn-01 RFC3061 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3001 RFC3002 Overview of 2000 IAB Wireless Internetworking Workshop D. Mitzel December 2000 ASCII HTML 42 internet architecture board

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on wireless internetworking. This memo provides information for the Internet community.

 draft-iab-wirelessws-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3002 RFC3003 The audio/mpeg Media Type M. Nilsson November 2000 ASCII HTML 5 audio/mpeg MIME multipurpose internet mail extensions Media Type

The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform Multipurpose Internet Mail Extension (MIME) type for these files. The intention of this document is to define the media type audio/mpeg to refer to this kind of contents. [STANDARDS-TRACK]

 draft-nilsson-audio-mpeg-03 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3003 10.17487/RFC3003 RFC3004 The User Class Option for DHCP G. Stump R. Droms Y. Gu R. Vyaghrapuri A. Demirtjis B. Beser J. Privat November 2000 ASCII HTML 6 DHCP dynamic host configuration protocol

This option is used by a Dynamic Host Configuration Protocol (DHCP) client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user. [STANDARDS-TRACK]

 draft-ietf-dhc-userclass-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3004 RFC3005 IETF Discussion List Charter S. Harris November 2000 ASCII HTML 3 internet engineering task force

The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through discussion of technical issues, and hosts discussions of IETF direction, policy, meetings, and procedures. As this is the most general IETF mailing list, considerable latitude is allowed. Advertising, whether to solicit business or promote employment opportunities, falls well outside the range of acceptable topics, as do discussions of a personal nature. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-poisson-listaup-02 RFC9245 RFC8717 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC3005 RFC3006 Integrated Services in the Presence of Compressible Flows B. Davie C. Iturralde D. Oran S. Casner J. Wroclawski November 2000 ASCII HTML 13 routing resource allocation int-serv

This specification describes an extension to the TSpec which enables a sender of potentially compressible data to provide hints to int-serv routers about the compressibility they may obtain. [STANDARDS-TRACK]

 draft-ietf-intserv-compress-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC3006 RFC3007 Secure Domain Name System (DNS) Dynamic Update B. Wellington November 2000 ASCII HTML 9 security authentication validation DNSSEC Domain Name System

This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK]

 draft-ietf-dnsext-simple-secure-update-02 RFC2137 RFC2535 RFC2136 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3007 RFC3008 Domain Name System Security (DNSSEC) Signing Authority B. Wellington November 2000 ASCII HTML 7 DNSSEC authentication validation SIG signature

This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. [STANDARDS-TRACK]

 draft-ietf-dnsext-signing-auth-02 RFC4035 RFC4033 RFC4034 RFC2535 RFC3658 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3008 RFC3009 Registration of parityfec MIME types J. Rosenberg H. Schulzrinne November 2000 ASCII HTML 10 parityfec media type MIME multimedia internet mail extensions

The RTP (Real-time Transport Protocol) payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity-based channel codes. This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec. This document serves as the MIME type registration for those formats. [STANDARDS-TRACK]

 draft-ietf-avt-fecmime-01 RFC5109 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3009 RFC3010 NFS version 4 Protocol S. Shepler B. Callaghan D. Robinson R. Thurlow C. Beame M. Eisler D. Noveck December 2000 ASCII HTML 212 NFSv4 network file system

NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [STANDARDS-TRACK]

 draft-ietf-nfsv4-07 RFC3530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=3010 10.17487/RFC3010 RFC3011 The IPv4 Subnet Selection Option for DHCP G. Waters November 2000 ASCII HTML 7 IPv4 internet protocol DHCP dynamic host configuration protocol

This memo defines a new Dynamic Host Configuration Protocol (DHCP) option for selecting the subnet on which to allocate an address. [STANDARDS-TRACK]

 draft-ietf-dhc-subnet-option-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3011 RFC3012 Mobile IPv4 Challenge/Response Extensions C. Perkins P. Calhoun November 2000 ASCII HTML 17 internet protocol authentication foreign agent

In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. [STANDARDS-TRACK]

 draft-ietf-mobileip-challenge-13 RFC4721 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3012 RFC3013 Recommended Internet Service Provider Security Services and Procedures T. Killalea November 2000 ASCII HTML 13 ISPs

The purpose of this document is to express what the engineering community as represented by the IETF expects of Internet Service Providers (ISPs) with respect to security. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-grip-isp-expectations-06 BCP0046 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grip 10.17487/RFC3013 RFC3014 Notification Log MIB R. Kavasseri November 2000 ASCII HTML 26 MIB management information base Notification Log

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging Simple Network Management Protocol (SNMP) Notifications. [STANDARDS-TRACK]

 draft-ietf-disman-notif-log-mib-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC3014 RFC3015 Megaco Protocol Version 1.0 F. Cuervo N. Greene A. Rayhan C. Huitema B. Rosen J. Segers November 2000 ASCII HTML 179 MEGACO H.248 media gateway control

This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and a Media Gateway Controller. [STANDARDS-TRACK]

 draft-ietf-megaco-merged-01 RFC2885 RFC2886 RFC3525 PROPOSED STANDARD PROPOSED STANDARD IETF rai megaco http://www.rfc-editor.org/errata_search.php?rfc=3015 10.17487/RFC3015 RFC3016 RTP Payload Format for MPEG-4 Audio/Visual Streams Y. Kikuchi T. Nomura S. Fukunaga Y. Matsui H. Kimata November 2000 ASCII HTML 21 RTP real-time transport protocol media type

This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-mpeg4-es-05 RFC6416 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3016 RFC3017 XML DTD for Roaming Access Phone Book M. Riegel G. Zorn December 2000 ASCII HTML 33 XML extensible markup language DTD document type declaration

This document defines the syntax as well as the semantics of the information to be included in the phone book for roaming applications. [STANDARDS-TRACK]

 draft-ietf-roamops-phonebook-xml-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops roamops 10.17487/RFC3017 RFC3018 Unified Memory Space Protocol Specification A. Bogdanov December 2000 ASCII HTML 81 UMSP Unified Memory Space Protocol network connection oriented

This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes. This memo defines an Experimental Protocol for the Internet community.

 draft-bogdanov-umsp EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3018 RFC3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol B. Haberman R. Worzella January 2001 ASCII HTML 15 IPv6 Internet Protocol MIB Management Information Base MLD Multicast Listener Discovery Protocol

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the Multicast Listener Discovery Protocol [STANDARDS-TRACK]

 draft-ietf-ipngwg-mld-mib-05 RFC5519 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC3019 RFC3020 Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function P. Pate B. Lynch K. Rehbehn December 2000 ASCII HTML 36 MIB management information base

This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. [STANDARDS-TRACK]

 draft-ietf-frnetmib-mfrmib-04 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC3020 RFC3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links A. Retana R. White V. Fuller D. McPherson December 2000 ASCII HTML 10 IPv4 internet protocol addresses subnet masks

With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. [STANDARDS-TRACK]

 draft-retana-31bits-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3021 RFC3022 Traditional IP Network Address Translator (Traditional NAT) P. Srisuresh K. Egevang January 2001 ASCII HTML 16 internet protocol ports private

The NAT operation described in this document extends address translation introduced in RFC 1631 and includes a new type of network address and TCP/UDP port translation. In addition, this document corrects the Checksum adjustment algorithm published in RFC 1631 and attempts to discuss NAT operation and limitations in detail. This memo provides information for the Internet community.

 draft-ietf-nat-traditional-05 RFC1631 INFORMATIONAL INFORMATIONAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=3022 10.17487/RFC3022 RFC3023 XML Media Types M. Murata S. St. Laurent D. Kohn January 2001 ASCII HTML 39 XML extensible markup language web authority HTTP hypertext transfer protocol media type

This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities. [STANDARDS-TRACK]

 draft-murata-xml-09 RFC2376 RFC7303 RFC2048 RFC6839 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3023 10.17487/RFC3023 RFC3024 Reverse Tunneling for Mobile IP, revised G. Montenegro Editor January 2001 ASCII HTML 30 Mobile IP internet protocol node care-of-address

This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. [STANDARDS-TRACK]

 draft-ietf-mobileip-rfc2344-bis-02 RFC2344 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3024 10.17487/RFC3024 RFC3025 Mobile IP Vendor/Organization-Specific Extensions G. Dommety K. Leung February 2001 ASCII HTML 8 internet protocol

This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. [STANDARDS-TRACK]

 draft-ietf-mobileip-vendor-ext-11 RFC3115 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3025 RFC3026 Liaison to IETF/ISOC on ENUM R. Blane January 2001 ASCII HTML 6 dns domain name system internet security engineering task force E.164 number

Working Party 1/2, of the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) held a meeting of its collaborators in Berlin Germany 19-26 October 2000. This liaison from WP1/2 to the IETF/ISOC conveys the understandings of the WP1/2 collaborators resulting from the discussions. This memo provides information for the Internet community.

 draft-itu-sg2-liason-enum-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3026 RFC3027 Protocol Complications with the IP Network Address Translator M. Holdrege P. Srisuresh January 2001 ASCII HTML 20 IP internet protocol network address translator

The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. This memo provides information for the Internet community.

 draft-ietf-nat-protocol-complications-06 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC3027 RFC3028 Sieve: A Mail Filtering Language T. Showalter January 2001 ASCII HTML 36 Sieve client server

This document describes a language for filtering e-mail messages at time of final delivery. [STANDARDS-TRACK]

 draft-showalter-sieve-12 RFC5228 RFC5429 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3028 10.17487/RFC3028 RFC3029 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols C. Adams P. Sylvester M. Zolotarev R. Zuccherato February 2001 ASCII HTML 51 X.509 PKI Public Key Infrastructure DVCS Data Validation and Certification Server TTP trusted third party

This document describes a general Data Validation and Certification Server (DVCS) and the protocols to be used when communicating with it. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-pkix-dcs-07 EXPERIMENTAL EXPERIMENTAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3029 10.17487/RFC3029 RFC3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages G. Vaudreuil December 2000 ASCII HTML 12 SMTP simple mail transfer protocol multipurpose internet

This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. [STANDARDS-TRACK]

 draft-vaudreuil-esmtp-binary2-03 RFC1830 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3030 10.17487/RFC3030 RFC3031 Multiprotocol Label Switching Architecture E. Rosen A. Viswanathan R. Callon January 2001 ASCII HTML 61 MPLS Multiprotocol Label Switching

This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]

 draft-ietf-mpls-arch-06 RFC6178 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3031 10.17487/RFC3031 RFC3032 MPLS Label Stack Encoding E. Rosen D. Tappan G. Fedorkow Y. Rekhter D. Farinacci T. Li A. Conta January 2001 ASCII HTML 23 MPLS multi-protocol label switching

This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK]

 draft-ietf-mpls-label-encaps-07 RFC3443 RFC4182 RFC5332 RFC3270 RFC5129 RFC5462 RFC5586 RFC7274 RFC9017 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3032 10.17487/RFC3032 RFC3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol M. Suzuki January 2001 ASCII HTML 25 IP Internet Protocol

The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol. [STANDARDS-TRACK]

 draft-ietf-mpls-git-uus-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3033 RFC3034 Use of Label Switching on Frame Relay Networks Specification A. Conta P. Doolan A. Malis January 2001 ASCII HTML 24 MPLS multi-protocol label switching

This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. [STANDARDS-TRACK]

 draft-ietf-mpls-fr-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3034 RFC3035 MPLS using LDP and ATM VC Switching B. Davie J. Lawrence K. McCloghrie E. Rosen G. Swallow Y. Rekhter P. Doolan January 2001 ASCII HTML 20 MPLS multi-protocol label switching ATM asynchronous transfer mode LDP label distribution protocol

This document extends and clarifies the relevant portions of RFC 3031 and RFC 3036 by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see RFC 3031) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. [STANDARDS-TRACK]

 draft-ietf-mpls-atm-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3035 RFC3036 LDP Specification L. Andersson P. Doolan N. Feldman A. Fredette B. Thomas January 2001 ASCII HTML 132 label distribution protocol

A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-11 RFC5036 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3036 10.17487/RFC3036 RFC3037 LDP Applicability B. Thomas E. Gray January 2001 ASCII HTML 7 label distribution protocol

A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document describes the applicability of a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. This memo provides information for the Internet community.

 draft-ietf-mpls-ldp-applic-02 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3037 10.17487/RFC3037 RFC3038 VCID Notification over ATM link for LDP K. Nagami Y. Katsube N. Demizu H. Esaki P. Doolan January 2001 ASCII HTML 19 VCID Virtual Connection Identifier ATM asynchronous transfer mode LDP label distribution protocol

This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. [STANDARDS-TRACK]

 draft-ietf-mpls-vcid-atm-05 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3038 RFC3039 Internet X.509 Public Key Infrastructure Qualified Certificates Profile S. Santesson W. Polk P. Barzin M. Nystrom January 2001 ASCII HTML 35 syntax

This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The goal of this document is to define a general syntax independent of local legal requirements. [STANDARDS-TRACK]

 draft-ietf-pkix-qc-06 RFC3739 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC3039 RFC3040 Internet Web Replication and Caching Taxonomy I. Cooper I. Melve G. Tomlinson January 2001 ASCII HTML 32 infrastructure www world wide

This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure as deployed today. It introduces standard concepts, and protocols used today within this application domain. This memo provides information for the Internet community.

 draft-ietf-wrec-taxonomy-06 INFORMATIONAL INFORMATIONAL IETF app wrec 10.17487/RFC3040 RFC3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 T. Narten R. Draves January 2001 ASCII HTML 17 internet protocol interface identifier

This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. [STANDARDS-TRACK]

 draft-ietf-ipngwg-addrconf-privacy-04 RFC4941 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=3041 10.17487/RFC3041 RFC3042 Enhancing TCP's Loss Recovery Using Limited Transmit M. Allman H. Balakrishnan S. Floyd January 2001 ASCII HTML 9 TCP transmission control protocol

This document proposes a new Transmission Control Protocol (TCP) mechanism that can be used to more effectively recover lost segments when a connection's congestion window is small, or when a large number of segments are lost in a single transmission window. [STANDARDS-TRACK]

 draft-ietf-tsvwg-limited-xmit-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3042 RFC3043 The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations M. Mealling January 2001 ASCII HTML 5 uniform resource name

This document describes a Uniform Resource Name (URN) namespace that is engineered by Network Solutions, Inc. for naming people and organizations. This memo provides information for the Internet community.

 draft-mealling-pin-urn-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3043 RFC3044 Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace S. Rozenfeld January 2001 ASCII HTML 15 serials identifier

This document presents how the ISSN - International Standard Serial Number - which is a persistent number for unique identification of serials widely recognised and used in the bibliographic world, can be supported within the Uniform Resource Name (URN) framework as a specific URN namespace identifier. This memo provides information for the Internet community.

 draft-rozenfeld-urn-issn-00 RFC8254 HISTORIC INFORMATIONAL Legacy 10.17487/RFC3044 RFC3045 Storing Vendor Information in the LDAP root DSE M. Meredith January 2001 ASCII HTML 6 lightweight directory access protocol DSA-specific entry

This document specifies two Lightweight Directory Access Protocol (LDAP) attributes, vendorName and vendorVersion that MAY be included in the root DSA-specific Entry (DSE) to advertise vendor-specific information. This memo provides information for the Internet community.

 draft-mmeredith-rootdse-vendor-info-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3045 RFC3046 DHCP Relay Agent Information Option M. Patrick January 2001 ASCII HTML 14 DHCP dynamic host configuration protocol

Newer high-speed public Internet access technologies call for a high- speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such "public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132. [STANDARDS-TRACK]

 draft-ietf-dhc-agent-options-12 RFC6607 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3046 RFC3047 RTP Payload Format for ITU-T Recommendation G.722.1 P. Luthi January 2001 ASCII HTML 8 ITU-T international telecommunication union RTP real-time transport protocol

This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. Also included here are the necessary details for the use of G.722.1 with MIME and SDP. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-g7221-01 RFC5577 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3047 10.17487/RFC3047 RFC3048 Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer B. Whetten L. Vicisano R. Kermode M. Handley S. Floyd M. Luby January 2001 ASCII HTML 20 RMT protocol core

This document describes a framework for the standardization of bulk-data reliable multicast transport. This memo provides information for the Internet community.

 draft-ietf-rmt-buildingblocks-03 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC3048 RFC3049 TN3270E Service Location and Session Balancing J. Naugle K. Kasthurirangan G. Ledford January 2001 ASCII HTML 21 SLP Service Location Protocol

This document discusses the implementation of Service Location Protocol (SLP) and session balancing with a TN3270E emulator in a client server implementation with a TN3270E server. [STANDARDS-TRACK]

 draft-ietf-tn3270e-service-loc-06 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC3049 RFC3050 Common Gateway Interface for SIP J. Lennox H. Schulzrinne J. Rosenberg January 2001 ASCII HTML 35 session initiation protocol

This document defines a SIP CGI interface for providing SIP services on a SIP server. This memo provides information for the Internet community.

 draft-lennox-sip-cgi-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3050 RFC3051 IP Payload Compression Using ITU-T V.44 Packet Method J. Heath J. Border January 2001 ASCII HTML 8 internet protocol international telecommunication union

This document describes a compression method based on the data compression algorithm described in International Telecommunication Union (ITU-T) Recommendation V.44. This document defines the application of V.44 Packet Method to the Internet Protocol (IP) Payload Compression Protocol (RFC 2393). This memo provides information for the Internet community.

 draft-heath-ipcomp-v44-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3051 RFC3052 Service Management Architectures Issues and Review M. Eder S. Nag January 2001 ASCII HTML 12 framework packets network

The purpose of this document is to explore the problems of defining a Service management framework and to examine some of the issues that still need to be resolved. This memo provides information for the Internet community.

 draft-irtf-nsmrg-sm-issues-00 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3052 10.17487/RFC3052 RFC3053 IPv6 Tunnel Broker A. Durand P. Fasano I. Guardini D. Lento January 2001 ASCII HTML 13 internet protocol infrastructure

The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network (e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented at Orlando's IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng & NGtrans interim meeting in February 1999. This memo provides information for the Internet community.

 draft-ietf-ngtrans-broker-06 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC3053 RFC3054 Megaco IP Phone Media Gateway Application Profile P. Blatherwick R. Bell P. Holland January 2001 ASCII HTML 14 internet protocol H.248 telephone MG

This document specifies a particular application of the Megaco/H.248 Protocol for control of Internet telephones and similar appliances: the Megaco IP Phone Media Gateway. This memo provides information for the Internet community.

 draft-ietf-megaco-ipphone-03 INFORMATIONAL INFORMATIONAL IETF rai megaco 10.17487/RFC3054 RFC3055 Management Information Base for the PINT Services Architecture M. Krishnaswamy D. Romascanu February 2001 ASCII HTML 21 MIB Management Information Base PINT PSTN/Internet Interworking Services Architecture

This memo describes a proposed Management Information Base (MIB) for the PSTN/Internet Interworking (PINT) Services Architecture. [STANDARDS-TRACK]

 draft-ietf-pint-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pint 10.17487/RFC3055 RFC3056 Connection of IPv6 Domains via IPv4 Clouds B. Carpenter K. Moore February 2001 ASCII HTML 23 IPv6 IPv4 internet protocol WAN wide area network unicast point-to-point

This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. [STANDARDS-TRACK]

 draft-ietf-ngtrans-6to4-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans http://www.rfc-editor.org/errata_search.php?rfc=3056 10.17487/RFC3056 RFC3057 ISDN Q.921-User Adaptation Layer K. Morneault S. Rengasami M. Kalla G. Sidebottom February 2001 ASCII HTML 66 SCTP signaling media gateway interface

This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). [STANDARDS-TRACK]

 draft-ietf-sigtran-iua-10 RFC4233 RFC3807 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3057 RFC3058 Use of the IDEA Encryption Algorithm in CMS S. Teiwes P. Hartmann D. Kuenzi February 2001 ASCII HTML 8 international data encryption algorithm cryptic message syntax s/mime multipurpose internet mail extensions

This memo specifies how to incorporate International Data Encryption Algorithm (IDEA) into CMS or S/MIME as an additional strong algorithm for symmetric encryption. This memo provides information for the Internet community.

 draft-ietf-smime-idea-08 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3058 10.17487/RFC3058 RFC3059 Attribute List Extension for the Service Location Protocol E. Guttman February 2001 ASCII HTML 6 SLPv2 Service Location Protocol messages user agent

This document specifies a SLPv2 extension which allows a User Agent (UA) to request a service's attributes be included as an extension to Service Reply messages. This will eliminate the need for multiple round trip messages for a UA to acquire all service information. [STANDARDS-TRACK]

 draft-guttman-svrloc-attrlist-ext-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3059 RFC3060 Policy Core Information Model -- Version 1 Specification B. Moore E. Ellesson J. Strassner A. Westerinen February 2001 ASCII HTML 100 CIM common information model schema object-oriented

This document presents the object-oriented information model for representing policy information developed jointly in the IETF Policy Framework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). [STANDARDS-TRACK]

 draft-ietf-policy-core-info-model-08 RFC3460 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3060 RFC3061 A URN Namespace of Object Identifiers M. Mealling February 2001 ASCII HTML 6 uniform resource names OIDs

This document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community.

 draft-mealling-rfc3001bis-01 RFC3001 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3061 10.17487/RFC3061 RFC3062 LDAP Password Modify Extended Operation K. Zeilenga February 2001 ASCII HTML 6 LDAP lightweight directory access protocol

This document describes an LDAP extended operation to allow modification of user passwords which is not dependent upon the form of the authentication identity nor the password storage mechanism used. [STANDARDS-TRACK]

 draft-zeilenga-ldap-passwd-exop-05 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3062 10.17487/RFC3062 RFC3063 MPLS Loop Prevention Mechanism Y. Ohba Y. Katsube E. Rosen P. Doolan February 2001 ASCII HTML 44 MPLS multiprotocol label switching path LSPs

This paper presents a simple mechanism, based on "threads", which can be used to prevent Multiprotocol Label Switching (MPLS) from setting up label switched path (LSPs) which have loops. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mpls-loop-prevention-03 EXPERIMENTAL EXPERIMENTAL IETF rtg mpls 10.17487/RFC3063 RFC3064 MGCP CAS Packages B. Foster February 2001 ASCII HTML 56 media gateway controllers

This document contains a collection of media gateway Channel Associated Signaling (CAS) packages for R1 CAS, North American CAS, CAS PBX interconnect as well as basic FXO support. This memo provides information for the Internet community.

 draft-foster-mgcp-cas-packages-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3064 RFC3065 Autonomous System Confederations for BGP P. Traina D. McPherson J. Scudder February 2001 ASCII HTML 11 BGP-ASC Autonomous System Confederations border gateway protocol

This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. [STANDARDS-TRACK]

 draft-ietf-idr-bgp-confed-rfc1965bis-01 RFC1965 RFC5065 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=3065 10.17487/RFC3065 RFC3066 Tags for the Identification of Languages H. Alvestrand January 2001 ASCII HTML 13 Lang-Tag

This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-alvestrand-lang-tag-v2-05 RFC1766 RFC4646 RFC4647 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=3066 10.17487/RFC3066 RFC3067 TERENA'S Incident Object Description and Exchange Format Requirements J. Arvidsson A. Cormack Y. Demchenko J. Meijer February 2001 ASCII HTML 17 IEDEF data archiving

The purpose of the Incident Object Description and Exchange Format is to define a common data format for the description, archiving and exchange of information about incidents between CSIRTs (Computer Security Incident Response Teams) (including alert, incident in investigation, archiving, statistics, reporting, etc.). This document describes the high-level requirements for such a description and exchange format, including the reasons for those requirements. This memo provides information for the Internet community.

 draft-terena-itdwg-iodef-requirements-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3067 RFC3068 An Anycast Prefix for 6to4 Relay Routers C. Huitema June 2001 ASCII HTML 9 6to4 exterior gateway protocol EGP IGP interior

This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned Numbers Authority) of the "6to4 relay anycast prefix." [STANDARDS-TRACK]

 draft-ietf-ngtrans-6to4anycast-03 RFC7526 HISTORIC PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC3068 RFC3069 VLAN Aggregation for Efficient IP Address Allocation D. McPherson B. Dykes February 2001 ASCII HTML 7 virtual local area network internet protocol

This document introduces the concept of Virtual Local Area Network (VLAN) aggregation as it relates to IPv4 address allocation. This memo provides information for the Internet community.

 draft-mcpherson-vlan-ipagg-02 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3069 10.17487/RFC3069 RFC3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay V. Rawat R. Tio S. Nanji R. Verma February 2001 ASCII HTML 7 L2TP-FR Layer Two Tunneling Protocol Frame Relay point-to-point PVCs Permanent Virtual Circuits SVCs Switched Virtual Circuits

This document describes how L2TP is implemented over Frame Relay Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs). [STANDARDS-TRACK]

 draft-ietf-l2tpext-fr-01 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3070 RFC3071 Reflections on the DNS, RFC 1591, and Categories of Domains J. Klensin February 2001 ASCII HTML 10 DNS Policy Top-Level TLD

This document is being published primarily for historical context and comparative purposes, essentially to document some thoughts about how 1591 might have been interpreted and adjusted by the Internet Assigned Numbers Authority (IANA) and ICANN to better reflect today's world while retaining characteristics and policies that have proven to be effective in supporting Internet growth and stability. This memo provides information for the Internet community.

 draft-klensin-1591-reflections-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3071 RFC3072 Structured Data Exchange Format (SDXF) M. Wildgrube March 2001 ASCII HTML 26 chunks file datatype

This specification describes an all-purpose interchange format for use as a file format or for net-working. This memo provides information for the Internet community.

 draft-wildgrube-sdxf-08 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3072 RFC3073 Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration J. Collins March 2001 ASCII HTML 6 multipurpose internet mail extensions

This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-type application/font-tdpfr. The encoding is defined by the PFR Specification. This memo provides information for the Internet community.

 draft-collins-pfr-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3073 RFC3074 DHC Load Balancing Algorithm B. Volz S. Gonczi T. Lemon R. Stevens February 2001 ASCII HTML 10 DHC dynamic host configuration protocol

This document proposes a method of algorithmic load balancing. [STANDARDS-TRACK]

 draft-ietf-dhc-loadb-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3074 RFC3075 XML-Signature Syntax and Processing D. Eastlake 3rd J. Reagle D. Solo March 2001 ASCII HTML 64 extensible markup language

This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK]

 draft-ietf-xmldsig-core-11 RFC3275 PROPOSED STANDARD PROPOSED STANDARD IETF sec xmldsig 10.17487/RFC3075 RFC3076 Canonical XML Version 1.0 J. Boyer March 2001 ASCII HTML 28 extensible markup language

This specification describes a method for generating a physical representation, the canonical form, of an XML document that accounts for the permissible changes. This memo provides information for the Internet community.

 draft-ietf-xmldsig-canonical-01 INFORMATIONAL INFORMATIONAL IETF sec xmldsig 10.17487/RFC3076 RFC3077 A Link-Layer Tunneling Mechanism for Unidirectional Links E. Duros W. Dabbous H. Izumiyama N. Fujii Y. Zhang March 2001 ASCII HTML 25 LL Link-Layer udl Unidirectional link bidirectional connectivity ip internet protocol

This document describes a mechanism to emulate full bidirectional connectivity between all nodes that are directly connected by a unidirectional link. [STANDARDS-TRACK]

 draft-ietf-udlr-lltunnel-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg udlr 10.17487/RFC3077 RFC3078 Microsoft Point-To-Point Encryption (MPPE) Protocol G. Pall G. Zorn March 2001 ASCII HTML 12 security ppp

This document describes the use of the Microsoft Point to Point Encryption (MPPE) to enhance the confidentiality of PPP-encapsulated packets. This memo provides information for the Internet community.

 draft-ietf-pppext-mppe-05 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC3078 RFC3079 Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE) G. Zorn March 2001 ASCII HTML 21 security ppp

This document describes the method used to derive initial MPPE session keys from a variety of credential types. It is expected that this memo will be updated whenever Microsoft defines a new key derivation method for MPPE, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products. This memo provides information for the Internet community.

 draft-ietf-pppext-mppe-keys-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3079 RFC3080 The Blocks Extensible Exchange Protocol Core M. Rose March 2001 ASCII HTML 58 BEEP Blocks Extensible Exchange Protocol text binary messages kernel

This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP (Blocks Extensible Exchange Protocol) core. [STANDARDS-TRACK]

 draft-ietf-beep-framework-11 PROPOSED STANDARD PROPOSED STANDARD IETF app beep http://www.rfc-editor.org/errata_search.php?rfc=3080 10.17487/RFC3080 RFC3081 Mapping the BEEP Core onto TCP M. Rose March 2001 ASCII HTML 8 TCP transmission control protocol BEEP blocks extensible exchange protocol

This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection. [STANDARDS-TRACK]

 draft-ietf-beep-tcpmapping-06 PROPOSED STANDARD PROPOSED STANDARD IETF app beep 10.17487/RFC3081 RFC3082 Notification and Subscription for SLP J. Kempf J. Goldschmidt March 2001 ASCII HTML 14 SLP service location protocol

The Service Location Protocol (SLP) provides mechanisms whereby service agent clients can advertise and user agent clients can query for services. The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it. There exists another class of user agent applications, however, that requires notification when a new service appears or disappears. In the RFC 2608 design, these applications are forced to poll the network to catch changes. In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling. This memo defines an Experimental Protocol for the Internet community.

 draft-kempf-srvloc-notify-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3082 RFC3083 Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems R. Woundy March 2001 ASCII HTML 45 MIB BPI data-over-cable service interface specifications

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based (Simple Network Management Protocol) management of the Baseline Privacy Interface (BPI), which provides data privacy for DOCSIS 1.0 (Data-Over- Cable Service Interface Specifications) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670. This memo provides information for the Internet community.

 draft-ietf-ipcdn-mcns-bpi-mib-02 RFC9141 INFORMATIONAL INFORMATIONAL IETF ops ipcdn http://www.rfc-editor.org/errata_search.php?rfc=3083 10.17487/RFC3083 RFC3084 COPS Usage for Policy Provisioning (COPS-PR) K. Chan J. Seligson D. Durham S. Gai K. McCloghrie S. Herzog F. Reichmeyer R. Yavatkar A. Smith March 2001 ASCII HTML 34 COPS-PR common open policy service security quality provisioning

This document describes the use of the Common Open Policy Service (COPS) protocol for support of policy provisioning (COPS-PR). [STANDARDS-TRACK]

 draft-ietf-rap-pr-05 HISTORIC PROPOSED STANDARD IETF ops rap 10.17487/RFC3084 RFC3085 URN Namespace for NewsML Resources A. Coates D. Allen D. Rivers-Moore March 2001 ASCII HTML 6 uniform resource name newsitems iptc

This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems. This memo provides information for the Internet community.

 draft-iptc-newsml-urn-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3085 RFC3086 Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification K. Nichols B. Carpenter April 2001 ASCII HTML 24 diffserv QoS quality of service

This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to the Diffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions. This memo provides information for the Internet community.

 draft-ietf-diffserv-pdb-def-03 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC3086 RFC3087 Control of Service Context using SIP Request-URI B. Campbell R. Sparks April 2001 ASCII HTML 39 session initiation protocol uniform resource identifier

This memo describes a useful way to conceptualize the use of the standard SIP (Session Initiation Protocol) Request-URI (Uniform Resource Identifier) that the authors and many members of the SIP community think is suitable as a convention. It does not define any new protocol with respect to RFC 2543. This memo provides information for the Internet community.

 draft-campbell-sip-service-control-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3087 RFC3088 OpenLDAP Root Service An experimental LDAP referral service K. Zeilenga April 2001 ASCII HTML 11 OpenLDAP lightweight directory access protocol dns domain name system

The OpenLDAP Project is operating an experimental LDAP (Lightweight Directory Access Protocol) referral service known as the "OpenLDAP Root Service". The automated system generates referrals based upon service location information published in DNS SRV RRs (Domain Name System location of services resource records). This document describes this service. This memo defines an Experimental Protocol for the Internet community.

 draft-zeilenga-ldap-root-02 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3088 RFC3089 A SOCKS-based IPv6/IPv4 Gateway Mechanism H. Kitamura April 2001 ASCII HTML 12 internet protocol application layer

This document describes a SOCKS-based IPv6/IPv4 gateway mechanism that enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes. This memo provides information for the Internet community.

 draft-ietf-ngtrans-socks-gateway-06 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC3089 RFC3090 DNS Security Extension Clarification on Zone Status E. Lewis March 2001 ASCII HTML 11 domain name system rsa dsa

The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated. [STANDARDS-TRACK]

 draft-ietf-dnsext-zone-status-05 RFC4033 RFC4034 RFC4035 RFC2535 RFC3658 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3090 RFC3091 Pi Digit Generation Protocol H. Kennedy April 1 2001 ASCII HTML 6

This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3091 10.17487/RFC3091 RFC3092 Etymology of "Foo" D. Eastlake 3rd C. Manros E. Raymond April 1 2001 ASCII HTML 14

Approximately 212 RFCs so far, starting with RFC 269, contain the terms `foo', `bar', or `foobar' as metasyntactic variables without any proper explanation or definition. This document rectifies that deficiency. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3092 10.17487/RFC3092 RFC3093 Firewall Enhancement Protocol (FEP) M. Gaynor S. Bradner April 1 2001 ASCII HTML 11

Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1]. However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propose the Firewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3093 RFC3094 Tekelec's Transport Adapter Layer Interface D. Sprague R. Benedyk D. Brendes J. Keller April 2001 ASCII HTML 106 signaling gatewa circuit network internet protocol

This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. This memo provides information for the Internet community.

 draft-benedyk-sigtran-tali-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3094 RFC3095 RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed C. Bormann C. Burmeister M. Degermark H. Fukushima H. Hannu L-E. Jonsson R. Hakenberg T. Koren K. Le Z. Liu A. Martensson A. Miyazaki K. Svanbro T. Wiebke T. Yoshimura H. Zheng July 2001 ASCII HTML 168 ROHC RObust Header Compression ESP encapsulating security payload RTP real-time transport protocol UDP user datagram protocol

This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers. [STANDARDS-TRACK]

 draft-ietf-rohc-rtp-09 RFC3759 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3095 RFC3096 Requirements for robust IP/UDP/RTP header compression M. Degermark Editor July 2001 ASCII HTML 8 real-time transport internet protocol user datagram

This document contains requirements for robust IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression) WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as contributions from 3G.IP. This memo provides information for the Internet community.

 draft-ietf-rohc-rtp-requirements-05 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3096 RFC3097 RSVP Cryptographic Authentication -- Updated Message Type Value R. Braden L. Zhang April 2001 ASCII HTML 4 RSVP resource reservation protocol security

This memo resolves a duplication in the assignment of RSVP Message Types, by changing the Message Types assigned by RFC 2747 to Challenge and Integrity Response messages. [STANDARDS-TRACK]

 draft-ietf-rsvp-fix-iana-00 RFC2747 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC3097 RFC3098 How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$ T. Gavin D. Eastlake 3rd S. Hambridge April 2001 ASCII HTML 28 internet marketing users service providers isps

This memo offers useful suggestions for responsible advertising techniques that can be used via the internet in an environment where the advertiser, recipients, and the Internet Community can coexist in a productive and mutually respectful fashion. This memo provides information for the Internet community.

 draft-ietf-run-adverts-02 FYI0038 INFORMATIONAL INFORMATIONAL IETF run 10.17487/RFC3098 RFC3099 Request for Comments Summary RFC Numbers 3000-3099 S. Ginoza November 2001 ASCII HTML 25 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3099 RFC3100 RFC3101 The OSPF Not-So-Stubby Area (NSSA) Option P. Murphy January 2003 ASCII HTML 33 OSPF-NSSA Open Shortest Path First Not-So-Stubby Area external routes backward compatible

This memo documents an optional type of Open Shortest Path First (OSPF) area that is somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. The OSPF NSSA Option was originally defined in RFC 1587. The functional differences between this memo and RFC 1587 are explained in Appendix F. All differences, while expanding capability, are backward-compatible in nature. Implementations of this memo and of RFC 1587 will interoperate. [STANDARDS-TRACK]

 draft-ietf-ospf-nssa-update-11 RFC1587 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=3101 10.17487/RFC3101 RFC3102 Realm Specific IP: Framework M. Borella J. Lo D. Grabelsky G. Montenegro October 2001 ASCII HTML 30 RSIP Realm Specific Internet Protocol end-to-end NAT addressing requirements

This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end-to- end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-nat-rsip-framework-05 EXPERIMENTAL EXPERIMENTAL IETF tsv nat 10.17487/RFC3102 RFC3103 Realm Specific IP: Protocol Specification M. Borella D. Grabelsky J. Lo K. Taniguchi October 2001 ASCII HTML 54 RSIP Realm Specific Internet Protocol host gateway NAT requirements

This document presents a protocol with which to implement Realm Specific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port. In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-nat-rsip-protocol-07 EXPERIMENTAL EXPERIMENTAL IETF tsv nat 10.17487/RFC3103 RFC3104 RSIP Support for End-to-end IPsec G. Montenegro M. Borella October 2001 ASCII HTML 19 RSIP realm specific internet protocol NAT addressing requirements

This document proposes mechanisms that enable Realm Specific IP (RSIP) to handle end-to-end IPsec (IP Security). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-nat-rsip-ipsec-04 EXPERIMENTAL EXPERIMENTAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=3104 10.17487/RFC3104 RFC3105 Finding an RSIP Server with SLP J. Kempf G. Montenegro October 2001 ASCII HTML 11 RSIP realm specific internet protocol SLP service location protocol NAT addressing requirements

This document contains an SLP service type template that describes the advertisements made by RSIP servers for their services. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-nat-rsip-slp-00 EXPERIMENTAL EXPERIMENTAL IETF tsv nat 10.17487/RFC3105 RFC3106 ECML v1.1: Field Specifications for E-Commerce D. Eastlake 3rd T. Goldstein April 2001 ASCII HTML 20 electronic modeling language

Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields. In addition, some fields are defined for merchant to consumer communication. This memo provides information for the Internet community.

 draft-eastlake-ecom-fields2-05 RFC2706 RFC4112 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3106 RFC3107 Carrying Label Information in BGP-4 Y. Rekhter E. Rosen May 2001 ASCII HTML 8 SDP Session Description Protocol BGP Border Gateway Protocol ATM asynchronous transfer mode AAL ATM Adaptation Layer syntax adaption layer

This document specifies the way in which the label mapping information for a particular route is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the route itself. [STANDARDS-TRACK]

 draft-ietf-mpls-bgp4-mpls-04 RFC8277 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3107 10.17487/RFC3107 RFC3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections R. Kumar M. Mostafa May 2001 ASCII HTML 110 SDP Session Description Protocol ATM asynchronous transfer mode AAL ATM Adaptation Layer syntax

This document describes conventions for using the Session Description Protocol (SDP) described in RFC 2327 for controlling ATM Bearer Connections, and any associated ATM Adaptation Layer (AAL). The AALs addressed are Type 1, Type 2 and Type 5. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-atm-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3108 10.17487/RFC3108 RFC3109 Request to Move STD 39 to Historic Status R. Braden R. Bush J. Klensin May 2001 ASCII HTML 4 BBN 1822 host imp arpanet

This memo changes the status of STD 39, BBN Report 1822, "Specification of the Interconnection of a Host and an IMP", from Standard to Historic. This memo provides information for the Internet community.

 draft-ymbk-std39-historic-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3109 RFC3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) D. Eastlake 3rd May 2001 ASCII HTML 7 RSA/SHA1 RRs resource records security DNS Domain Name System

This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2. [STANDARDS-TRACK]

 draft-ietf-dnsext-rsa-03 RFC2537 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3110 10.17487/RFC3110 RFC3111 Service Location Protocol Modifications for IPv6 E. Guttman May 2001 ASCII HTML 13 SLP Service Location Protocol IPv6 internet protocol

This document defines the Service Location Protocol Version 2's (SLPv2) use over IPv6 networks. Since this protocol relies on UDP and TCP, the changes to support its use over IPv6 are minor. [STANDARDS-TRACK]

 draft-ietf-svrloc-ipv6-12 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC3111 RFC3112 LDAP Authentication Password Schema K. Zeilenga May 2001 ASCII HTML 9 lightweight directory access protocol

This document describes schema in support of user/password authentication in a LDAP (Lightweight Directory Access Protocol) directory including the authPassword attribute type. This memo provides information for the Internet community.

 draft-zeilenga-ldap-authpasswd-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3112 RFC3113 3GPP-IETF Standardization Collaboration K. Rosenbrock R. Sanmugam S. Bradner J. Klensin June 2001 ASCII HTML 7 internet engineering task force third generation partnership project

This document describes the standardization collaboration between 3GPP and IETF. This memo provides information for the Internet community.

 draft-3gpp-collaboration-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3113 RFC3114 Implementing Company Classification Policy with the S/MIME Security Label W. Nicolls May 2002 ASCII HTML 14 data multipurpose internet mail extensions access control information classification security category

This document discusses how company security policy for data classification can be mapped to the S/MIME security label. Actual policies from three companies provide worked examples. This memo provides information for the Internet community.

 draft-ietf-smime-seclabel-03 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC3114 RFC3115 Mobile IP Vendor/Organization-Specific Extensions G. Dommety K. Leung April 2001 ASCII HTML 9 Mobile IP internet protocol

This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. [STANDARDS-TRACK]

 RFC3025 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3115 RFC3116 Methodology for ATM Benchmarking J. Dunn C. Martin June 2001 ASCII HTML 127 asynchronous transfer mode formats switching

This document discusses and defines a number of tests that may be used to describe the performance characteristics of ATM (Asynchronous Transfer Mode) based switching devices. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community.

 draft-ietf-bmwg-atm-method-03 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3116 RFC3117 On the Design of Application Protocols M. Rose November 2001 ASCII HTML 27 beep bxxp blocks extensible exchange text binary

This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). This memo provides information for the Internet community.

 draft-mrose-beep-design-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3117 RFC3118 Authentication for DHCP Messages R. Droms Editor W. Arbaugh Editor June 2001 ASCII HTML 17 DHCP dynamic host configuration protocol verification

This document defines a new Dynamic Host Configuration Protocol (DHCP) option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. [STANDARDS-TRACK]

 draft-ietf-dhc-authentication-16 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3118 10.17487/RFC3118 RFC3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio R. Finlayson June 2001 ASCII HTML 19 RTP real-time protocol MPEG moving picture experts group

This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-mp3-06 RFC5219 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3119 10.17487/RFC3119 RFC3120 A URN Namespace for XML.org K. Best N. Walsh June 2001 ASCII HTML 5 uniform resource name extensible markup language

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources stored in the XML.org repository (such as XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). This memo provides information for the Internet community.

 draft-best-xmlorg-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3120 RFC3121 A URN Namespace for OASIS K. Best N. Walsh June 2001 ASCII HTML 7 uniform resource name organization for the advancement of structured information standards

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources published by OASIS (such as OASIS Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). This memo provides information for the Internet community.

 draft-best-urn-oasis-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3121 RFC3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification A. Conta June 2001 ASCII HTML 20 IPv6 internet protocol IND Inverse Neighbor Discovery link-layer

This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. [STANDARDS-TRACK]

 draft-ietf-ion-ipv6-ind-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=3122 10.17487/RFC3122 RFC3123 A DNS RR Type for Lists of Address Prefixes (APL RR) P. Koch June 2001 ASCII HTML 8 DNS domain name system RR resource record APL address prefix lists

The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-dnsext-apl-rr-02 EXPERIMENTAL EXPERIMENTAL IETF int dnsext 10.17487/RFC3123 RFC3124 The Congestion Manager H. Balakrishnan S. Seshan June 2001 ASCII HTML 22 CM Congestion Manager network stream end-system module

This document describes the Congestion Manager (CM), an end-system module that enables an ensemble of multiple concurrent streams from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and allows applications to easily adapt to network congestion. [STANDARDS-TRACK]

 draft-ietf-ecm-cm-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ecm 10.17487/RFC3124 RFC3125 Electronic Signature Policies J. Ross D. Pinkas N. Pope September 2001 ASCII HTML 44 electronic signature signer purchase contract invoice transactions applications

This document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-smime-espolicies-00 EXPERIMENTAL EXPERIMENTAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3125 10.17487/RFC3125 RFC3126 Electronic Signature Formats for long term electronic signatures D. Pinkas J. Ross N. Pope September 2001 ASCII HTML 84 purchase contract invoice application smart cards data

This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates the validity of the signature). This memo provides information for the Internet community.

 draft-ietf-smime-esformats-03 RFC5126 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3126 10.17487/RFC3126 RFC3127 Authentication, Authorization, and Accounting: Protocol Evaluation D. Mitton M. St.Johns S. Barkley D. Nelson B. Patil M. Stevens B. Wolff June 2001 ASCII HTML 84 AAA network access requirements

This memo represents the process and findings of the Authentication, Authorization, and Accounting Working Group (AAA WG) panel evaluating protocols proposed against the AAA Network Access Requirements, RFC 2989. This memo provides information for the Internet community.

 draft-ietf-aaa-proto-eval-02 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC3127 RFC3128 Protection Against a Variant of the Tiny Fragment Attack (RFC 1858) I. Miller June 2001 ASCII HTML 5 firewalls internet

This document discusses how RFC 1858 compliant filters can be vulnerable to a variant of the "Tiny Fragment Attack" described in section 3.1 of the RFC. This document describes the attack and recommends corrective action. This memo provides information for the Internet community.

 draft-miller-rfc1858-cmts-00 RFC1858 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3128 RFC3129 Requirements for Kerberized Internet Negotiation of Keys M. Thomas June 2001 ASCII HTML 6 KINK cryptographic security authentication

The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key. This memo provides information for the Internet community.

 draft-ietf-kink-reqmt-03 INFORMATIONAL INFORMATIONAL IETF sec kink 10.17487/RFC3129 RFC3130 Notes from the State-Of-The-Technology: DNSSEC E. Lewis June 2001 ASCII HTML 10 domain name system security extensions report

This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting. This memo provides information for the Internet community.

 draft-lewis-state-of-dnssec-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3130 RFC3131 3GPP2-IETF Standardization Collaboration S. Bradner P. Calhoun H. Cuschieri S. Dennett G. Flynn M. Lipford M. McPheters June 2001 ASCII HTML 8 internet engineering task force third generation partnership project

This document describes the standardization collaboration between 3GPP2 and IETF. This memo provides information for the Internet community.

 draft-bradner-3gpp2-collaboration-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3131 RFC3132 Dormant Mode Host Alerting ("IP Paging") Problem Statement J. Kempf June 2001 ASCII HTML 14 molulity radio link internet protocl

This memo describes paging, assesses the need for IP paging, and presents a list of recommendations for Seamoby charter items regarding work on paging. This memo provides information for the Internet community.

 draft-ietf-seamoby-paging-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3132 RFC3133 Terminology for Frame Relay Benchmarking J. Dunn C. Martin June 2001 ASCII HTML 24 switching devices signaling

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of frame relay switching devices. This memo provides information for the Internet community.

 draft-ietf-bmwg-fr-term-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3133 RFC3134 Terminology for ATM ABR Benchmarking J. Dunn C. Martin June 2001 ASCII HTML 16 asynchronous transfer mode available bit rate

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices supporting ABR (Available Bit Rate). This memo provides information for the Internet community.

 draft-ietf-bmwg-atm-term-abr-03 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3134 RFC3135 Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations J. Border M. Kojo J. Griner G. Montenegro Z. Shelby June 2001 ASCII HTML 45 PEP PILC TCP transmission control protocol

This document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. This memo provides information for the Internet community.

 draft-ietf-pilc-pep-07 INFORMATIONAL INFORMATIONAL IETF tsv pilc 10.17487/RFC3135 RFC3136 The SPIRITS Architecture L. Slutsman Editor I. Faynberg H. Lu M. Weissman June 2001 ASCII HTML 10 PSTN public switched telephone network

This document describes the architecture for supporting SPIRITS services, which are those originating in the PSTN (Public Switched Telephone Network)and necessitating the interactions between the PSTN and the Internet. This memo provides information for the Internet community.

 draft-ietf-spirits-architecture-03 INFORMATIONAL INFORMATIONAL IETF tsv spirits 10.17487/RFC3136 RFC3137 OSPF Stub Router Advertisement A. Retana L. Nguyen R. White A. Zinin D. McPherson June 2001 ASCII HTML 5 open shortest path first

This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. This memo provides information for the Internet community.

 draft-ietf-ospf-stub-adv-02 RFC6987 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC3137 RFC3138 Extended Assignments in 233/8 D. Meyer June 2001 ASCII HTML 4 internet address AS autonomous system number

This memo provides describes the mapping of the GLOP addresses corresponding to the private AS space. This memo provides information for the Internet community.

 draft-ietf-mboned-glop-extensions-02 RFC5771 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC3138 RFC3139 Requirements for Configuration Management of IP-based Networks L. Sanchez K. McCloghrie J. Saperia June 2001 ASCII HTML 11 internet protocol

This memo discusses different approaches to configure networks and identifies a set of configuration management requirements for IP-based networks. This memo provides information for the Internet community.

 draft-ops-ip-config-management-reqmnts-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3139 RFC3140 Per Hop Behavior Identification Codes D. Black S. Brim B. Carpenter F. Le Faucheur June 2001 ASCII HTML 8 PHB Per Hop Behavior differentiated services codepoint DSCP

This document defines a 16 bit encoding mechanism for the identification of differentiated services Per Hop Behaviors in protocol messages. It replaces RFC 2836. [STANDARDS-TRACK]

 draft-ietf-diffserv-2836bis-02 RFC2836 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv 10.17487/RFC3140 RFC3141 CDMA2000 Wireless Data Requirements for AAA T. Hiller P. Walsh X. Chen M. Munson G. Dommety S. Sivalingham B. Lim P. McCann H. Shiino B. Hirschman S. Manning R. Hsu H. Koo M. Lipford P. Calhoun C. Lo E. Jaques E. Campbell Y. Xu S. Baba T. Ayaki T. Seki A. Hameed June 2001 ASCII HTML 16 authentication authorization accounting

This memo specifies cdma2000 wireless data AAA (Authentication, Authorization, Accounting) requirements associated with third generation wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services. This memo provides information for the Internet community.

 draft-hiller-cdma2000-aaa-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3141 RFC3142 An IPv6-to-IPv4 Transport Relay Translator J. Hagino K. Yamamoto June 2001 ASCII HTML 11 TRT internet protocol

The document describes an IPv6-to-IPv4 transport relay translator (TRT). This memo provides information for the Internet community.

 draft-ietf-ngtrans-tcpudp-relay-04 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC3142 RFC3143 Known HTTP Proxy/Caching Problems I. Cooper J. Dilley June 2001 ASCII HTML 32 www world wide web hypertext transfer protocol

This document catalogs a number of known problems with World Wide Web (WWW) (caching) proxies and cache servers. The goal of the document is to provide a discussion of the problems and proposed workarounds, and ultimately to improve conditions by illustrating problems. This memo provides information for the Internet community.

 draft-cooper-wrec-known-prob-01 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3143 10.17487/RFC3143 RFC3144 Remote Monitoring MIB Extensions for Interface Parameters Monitoring D. Romascanu August 2001 ASCII HTML 30 MIB management information base remote monitoring

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB with a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface. [STANDARDS-TRACK]

 draft-ietf-rmonmib-iftopn-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3144 RFC3145 L2TP Disconnect Cause Information R. Verma M. Verma J. Carlson July 2001 ASCII HTML 10 L2TP layer 2 tunneling protocol PPP point-to-point accounting debugging

This document provides an extension to the Layer 2 Tunneling Protocol ("L2TP"), a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3145 RFC3146 Transmission of IPv6 Packets over IEEE 1394 Networks K. Fujisawa A. Onoe October 2001 ASCII HTML 8 IPv6 link-local addresses statelessly autoconfigured

This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. [STANDARDS-TRACK]

 draft-ietf-ipngwg-1394-02 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC3146 RFC3147 Generic Routing Encapsulation over CLNS Networks P. Christian July 2001 ASCII HTML 8 connectionless network service GRE layer protocol

This document proposes a method for transporting an arbitrary protocol over a CLNS (Connectionless Network Service) network using GRE (Generic Routing Encapsulation). This may then be used as a method to tunnel IPv4 or IPv6 over CLNS. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3147 RFC3148 A Framework for Defining Empirical Bulk Transfer Capacity Metrics M. Mathis M. Allman July 2001 ASCII HTML 16 BTC transport data

This document defines a framework for standardizing multiple BTC (Bulk Transport Capacity) metrics that parallel the permitted transport diversity. This memo provides information for the Internet community.

 draft-ietf-ippm-btc-framework-06 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC3148 RFC3149 MGCP Business Phone Packages A. Srinath G. Levendel K. Fritz R. Kalyanaram September 2001 ASCII HTML 41 media gateway control packages

This document describes a collection of MGCP (Media Gateway Control Protocol) packages that can be used to take advantage of the feature keys and displays on digital business phones and IP-Phones. This memo provides information for the Internet community.

 draft-srinath-mgcp-bus-packages-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3149 RFC3150 End-to-end Performance Implications of Slow Links S. Dawkins G. Montenegro M. Kojo V. Magret July 2001 ASCII HTML 17 PILC data applications header compression

This document makes performance-related recommendations for users of network paths that traverse "very low bit-rate" links. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-pilc-slow-06 BCP0048 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3150 RFC3151 A URN Namespace for Public Identifiers N. Walsh J. Cowan P. Grosso August 2001 ASCII HTML 9 uniform resource name publicid

This document describes a URN (Uniform Resource Name) namespace that is designed to allow Public Identifiers to be expressed in URI (Uniform Resource Identifiers) syntax. This memo provides information for the Internet community.

 draft-walsh-urn-publicid-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3151 RFC3152 Delegation of IP6.ARPA R. Bush August 2001 ASCII HTML 4 internet protocol domain name system DNS zone

This document discusses the need for delegation of the IP6.ARPA DNS zone, and specifies a plan for the technical operation thereof. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ymbk-ip6-arpa-delegation-02 RFC3596 RFC2874 RFC2772 RFC2766 RFC2553 RFC1886 BCP0049 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3152 RFC3153 PPP Multiplexing R. Pazhyannur I. Ali C. Fox August 2001 ASCII HTML 9 PPP point-to-point protocol multiplexing

This document describes a method to reduce the PPP (Point-to-Point Protocol) framing overhead used to transport small packets over slow links. [STANDARDS-TRACK]

 draft-ietf-pppext-pppmux-03 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3153 RFC3154 Requirements and Functional Architecture for an IP Host Alerting Protocol J. Kempf C. Castelluccia P. Mutaf N. Nakajima Y. Ohba R. Ramjee Y. Saifullah B. Sarikaya X. Xu August 2001 ASCII HTML 16 internet protocol paging mobile hosts

This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging. This memo provides information for the Internet community.

 draft-ietf-seamoby-paging-requirements-01 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3154 RFC3155 End-to-end Performance Implications of Links with Errors S. Dawkins G. Montenegro M. Kojo V. Magret N. Vaidya August 2001 ASCII HTML 16 TCP transmission control protocol

This document discusses the specific TCP mechanisms that are problematic in environments with high uncorrected error rates, and discusses what can be done to mitigate the problems without introducing intermediate devices into the connection. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-pilc-error-08 BCP0050 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3155 RFC3156 MIME Security with OpenPGP M. Elkins D. Del Torto R. Levien T. Roessler August 2001 ASCII HTML 15 MIME-PGP Multipurpose Internet Mail Extensions Pretty Good Privacy Authentication Encryption

This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK]

 draft-ietf-openpgp-mime-07 RFC2015 PROPOSED STANDARD PROPOSED STANDARD IETF sec openpgp http://www.rfc-editor.org/errata_search.php?rfc=3156 10.17487/RFC3156 RFC3157 Securely Available Credentials - Requirements A. Arsenault S. Farrell August 2001 ASCII HTML 20 SACRED trusted roots private keys PSE personal security environment

This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols. This memo provides information for the Internet community.

 draft-ietf-sacred-reqs-03 INFORMATIONAL INFORMATIONAL IETF sec sacred 10.17487/RFC3157 RFC3158 RTP Testing Strategies C. Perkins J. Rosenberg H. Schulzrinne August 2001 ASCII HTML 22 real-time transport protocol

This memo describes a possible testing strategy for RTP (real-time transport protocol) implementations. This memo provides information for the Internet community.

 draft-ietf-avt-rtptest-06 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC3158 RFC3159 Structure of Policy Provisioning Information (SPPI) K. McCloghrie M. Fine J. Seligson K. Chan S. Hahn R. Sahita A. Smith F. Reichmeyer August 2001 ASCII HTML 40 PIB Policy Information Base SNMP simple network management protocol SPPI Structure of Policy Provisioning Information SMI Structure of Management Information

This document, the Structure of Policy Provisioning Information (SPPI), defines the adapted subset of SNMP's Structure of Management Information (SMI) used to write Policy Information Base (PIB) modules. [STANDARDS-TRACK]

 draft-ietf-rap-sppi-07 HISTORIC PROPOSED STANDARD IETF ops rap 10.17487/RFC3159 RFC3160 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force S. Harris August 2001 ASCII HTML 38 Internet Engineering Task Force Meeting

This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. This memo provides information for the Internet community.

 draft-ietf-uswg-tao-06 RFC1718 RFC4677 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC3160 RFC3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) C. Adams P. Cain D. Pinkas R. Zuccherato August 2001 ASCII HTML 26 TSA Time Stamping Authority TSP Time-Stamp Protocol security request response

This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK]

 draft-ietf-pkix-time-stamp-15 RFC5816 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3161 10.17487/RFC3161 RFC3162 RADIUS and IPv6 B. Aboba G. Zorn D. Mitton August 2001 ASCII HTML 12 RADIUS remote authentication dial in user service attributes IPv6

This document specifies the operation of RADIUS (Remote Authentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access. [STANDARDS-TRACK]

 draft-aboba-radius-ipv6-10 RFC8044 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3162 10.17487/RFC3162 RFC3163 ISO/IEC 9798-3 Authentication SASL Mechanism R. Zuccherato M. Nystrom August 2001 ASCII HTML 17 SASL simple authentication security layer

This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB 196 entity authentication. This memo defines an Experimental Protocol for the Internet community.

 draft-zuccherato-9798-3-sasl-03 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3163 RFC3164 The BSD Syslog Protocol C. Lonvick August 2001 ASCII HTML 29 berkeley software distribution transmission messages

This document describes the observed behavior of the syslog protocol. This memo provides information for the Internet community.

 draft-ietf-syslog-syslog-12 RFC5424 INFORMATIONAL INFORMATIONAL IETF sec syslog 10.17487/RFC3164 RFC3165 Definitions of Managed Objects for the Delegation of Management Scripts D. Levi J. Schoenwaelder August 2001 ASCII HTML 64 MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. [STANDARDS-TRACK]

 draft-ietf-disman-script-mib-v2-04 RFC2592 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=3165 10.17487/RFC3165 RFC3166 Request to Move RFC 1403 to Historic Status D. Meyer J. Scudder August 2001 ASCII HTML 3 BGP-OSPF Border gateway protocol Open shortest path first routing

RFC 1403, "BGP OSPF Interaction", describes technology which is no longer used. This document requests that RFC 1403 be moved to Historic status. This memo provides information for the Internet community.

 draft-meyer-rfc1403-historic-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3166 RFC3167 Request to Move RFC 1745 to Historic Status D. Meyer J. Scudder August 2001 ASCII HTML 3 BGP4/IDRP Internet Inter-Domain Routing Protocol Border Gateway Open Shortest Path First

RFC 1745, "BGP4/IDRP for IP---OSPF Interaction", describes technology which was never deployed in the public internet. This document requests that RFC 1745 be moved to Historic status. This memo provides information for the Internet community.

 draft-meyer-rfc1745-historic-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3167 RFC3168 The Addition of Explicit Congestion Notification (ECN) to IP K. Ramakrishnan S. Floyd D. Black September 2001 ASCII HTML 63 IP internet protocol header ECN Explicit Congestion Notification

This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]

 draft-ietf-tsvwg-ecn-04 RFC2481 RFC2003 RFC2474 RFC2401 RFC0793 RFC4301 RFC6040 RFC8311 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3168 10.17487/RFC3168 RFC3169 Criteria for Evaluating Network Access Server Protocols M. Beadles D. Mitton September 2001 ASCII HTML 17 NAS network device AAA authentication authorization accounting

This document defines requirements for protocols used by Network Access Servers (NAS). This memo provides information for the Internet community.

 draft-ietf-nasreq-criteria-06 INFORMATIONAL INFORMATIONAL IETF ops nasreq 10.17487/RFC3169 RFC3170 IP Multicast Applications: Challenges and Solutions B. Quinn K. Almeroth September 2001 ASCII HTML 28 internet protocol unicast

This document describes the challenges involved with designing and implementing multicast applications. It is an introductory guide for application developers that highlights the unique considerations of multicast applications as compared to unicast applications. This memo provides information for the Internet community.

 draft-ietf-mboned-mcast-apps-02 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC3170 RFC3171 IANA Guidelines for IPv4 Multicast Address Assignments Z. Albanna K. Almeroth D. Meyer M. Schipper August 2001 ASCII HTML 8 internet assigned numbers authority protocol parameters

This memo provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-mboned-iana-ipv4-mcast-guidelines-04 RFC5771 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned http://www.rfc-editor.org/errata_search.php?rfc=3171 10.17487/RFC3171 RFC3172 Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa") G. Huston Editor September 2001 ASCII HTML 8 database DNS domain name system

This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-iab-arpa-03 RFC9120 BCP0052 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC3172 RFC3173 IP Payload Compression Protocol (IPComp) A. Shacham B. Monsour R. Pereira M. Thomas September 2001 ASCII HTML 13 IPCOMP internet protocol payload compression protocol datagram lossless

This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]

 draft-shacham-ippcp-rfc2393bis-08 RFC2393 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3173 RFC3174 US Secure Hash Algorithm 1 (SHA1) D. Eastlake 3rd P. Jones September 2001 ASCII HTML 22 FIPS federal information processing standard

The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community. This memo provides information for the Internet community.

 draft-eastlake-sha1-02 RFC4634 RFC6234 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3174 10.17487/RFC3174 RFC3175 Aggregation of RSVP for IPv4 and IPv6 Reservations F. Baker C. Iturralde F. Le Faucheur B. Davie September 2001 ASCII HTML 36 RSVP resource reservation protocol internet ATM asynchronous transfer mode

This document describes the use of a single RSVP (Resource ReSerVation Protocol) reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM (Asynchronous Transfer Mode) network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations. [STANDARDS-TRACK]

 draft-ietf-issll-rsvp-aggr-04 RFC5350 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC3175 RFC3176 InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks P. Phaal S. Panchen N. McKee September 2001 ASCII HTML 31 agent data MIB management information base

This memo defines InMon Corporation's sFlow system. sFlow is a technology for monitoring traffic in data networks containing switches and routers. In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector. This memo provides information for the Internet community.

 draft-phaal-sflow-montraffic-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3176 RFC3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites IAB IESG September 2001 ASCII HTML 10 internet architecture board engineering steering group protocol

This document provides recommendations to the addressing registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.

 draft-iesg-ipv6-addressing-recommendations-03 RFC6177 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC3177 RFC3178 IPv6 Multihoming Support at Site Exit Routers J. Hagino H. Snyder October 2001 ASCII HTML 12 internet protocol ISP Service Provider Routing

The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. This memo provides information for the Internet community.

 draft-ietf-ipngwg-ipv6-2260-02 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC3178 RFC3179 Script MIB Extensibility Protocol Version 1.1 J. Schoenwaelder J. Quittek October 2001 ASCII HTML 25 SMX Script MIB extensibility protocol language management information base

The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. This memo defines an Experimental Protocol for the Internet community.

 draft-schoenw-rfc-2593-update-04 RFC2593 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3179 RFC3180 GLOP Addressing in 233/8 D. Meyer P. Lothberg September 2001 ASCII HTML 5 static multicast

This document defines the policy for the use of 233/8 for statically e assigned multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-mboned-glop-update-01 RFC2770 BCP0053 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned http://www.rfc-editor.org/errata_search.php?rfc=3180 10.17487/RFC3180 RFC3181 Signaled Preemption Priority Policy Element S. Herzog October 2001 ASCII HTML 12 rsvp resource reservation protocol cops common open policy service

This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as the Resource ReSerVation Protocol (RSVP) and Common Open Policy Service (COPS). [STANDARDS-TRACK]

 draft-ietf-rap-signaled-priority-v2-00 RFC2751 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC3181 RFC3182 Identity Representation for RSVP S. Yadav R. Yavatkar R. Pabbati P. Ford T. Moore S. Herzog R. Hess October 2001 ASCII HTML 18 RSVP resource reservation protocol

This document describes the representation of identity information in POLICY_DATA object for supporting policy based admission control in the Resource ReSerVation Protocol (RSVP). The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g., user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. [STANDARDS-TRACK]

 draft-ietf-rap-rsvp-newidentity-01 RFC2752 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap http://www.rfc-editor.org/errata_search.php?rfc=3182 10.17487/RFC3182 RFC3183 Domain Security Services using S/MIME T. Dean W. Ottaway October 2001 ASCII HTML 24 S/MIME secure/multipurpose internet mail extensions

This document describes how the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-smime-domsec-09 EXPERIMENTAL EXPERIMENTAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3183 10.17487/RFC3183 RFC3184 IETF Guidelines for Conduct S. Harris October 2001 ASCII HTML 4 internet engineering task force

This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-poisson-code-04 RFC7154 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC3184 RFC3185 Reuse of CMS Content Encryption Keys S. Farrell S. Turner October 2001 ASCII HTML 10 CMS Content Encryption Keys cryptographic message syntax data packets

This document describes a way to include a key identifier in a CMS (Cryptographic Message Syntax) enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets. [STANDARDS-TRACK]

 draft-ietf-smime-rcek-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3185 RFC3186 MAPOS/PPP Tunneling mode S. Shimizu T. Kawano K. Murakami E. Beier December 2001 ASCII HTML 14 multiple access protocol over SONET/SDH point-to-point

This document specifies tunneling configuration over MAPOS (Multiple Access Protocol over SONET/SDH) networks. Using this mode, a MAPOS network can provide transparent point-to-point link for PPP over SONET/SDH (Packet over SONET/SDH, POS) without any additional overhead. This memo provides information for the Internet community.

 draft-shimizu-ppp-mapos-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3186 RFC3187 Using International Standard Book Numbers as Uniform Resource Names J. Hakala H. Walravens October 2001 ASCII HTML 11 isbn urn bibliographic identifiers

This document discusses how International Standard Book Numbers (ISBN) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion below is based on the ideas expressed in RFC 2288. This memo provides information for the Internet community.

 draft-hakala-isbn-01 RFC8254 HISTORIC INFORMATIONAL Legacy 10.17487/RFC3187 RFC3188 Using National Bibliography Numbers as Uniform Resource Names J. Hakala October 2001 ASCII HTML 13 urn nbn national libraries

This document discusses how national bibliography numbers (persistent and unique identifiers assigned by the national libraries) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion is based on the ideas expressed in RFC 2288. This memo provides information for the Internet community.

 draft-hakala-nbn-01 RFC8458 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3188 RFC3189 RTP Payload Format for DV (IEC 61834) Video K. Kobayashi A. Ogawa S. Casner C. Bormann January 2002 ASCII HTML 13 RTP real-time transport protocol

This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]

 draft-ietf-avt-dv-video-04 RFC6469 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3189 10.17487/RFC3189 RFC3190 RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio K. Kobayashi A. Ogawa S. Casner C. Bormann January 2002 ASCII HTML 17 RTP real-time transport protocol digital audio tape

This document specifies a packetization scheme for encapsulating 12-bit nonlinear, 20-bit linear, and 24-bit linear audio data streams using the Real-time Transport Protocol (RTP). This document also specifies the format of a Session Description Protocol (SDP) parameter to indicate when audio data is preemphasized before sampling. The parameter may be used with other audio payload formats, in particular L16 (16-bit linear). [STANDARDS-TRACK]

 draft-ietf-avt-dv-audio-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3190 RFC3191 Minimal GSTN address format in Internet Mail C. Allocchio October 2001 ASCII HTML 13 MIN-PSTN Minimal GSTN global switched telephone network email

This memo describes a simple method of encoding Global Switched Telephone Network (GSTN) addresses (commonly called "telephone numbers") in the local-part of Internet email addresses, along with an extension mechanism to allow encoding of additional standard attributes needed for email gateways to GSTN-based services. [STANDARDS-TRACK]

 draft-ietf-fax-minaddr-v2-04 RFC2303 RFC2846 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3191 RFC3192 Minimal FAX address format in Internet Mail C. Allocchio October 2001 ASCII HTML 11 MINFAX-IM Minimal FAX Internet Mail facsimile GSTN global switched telephone network

This memo describes a simple method of encoding Global Switched Telephone Network (GSTN) addresses of facsimile devices in the local- part of Internet email addresses. [STANDARDS-TRACK]

 draft-ietf-fax-faxaddr-v2-04 RFC2304 RFC2846 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3192 RFC3193 Securing L2TP using IPsec B. Patel B. Aboba W. Dixon G. Zorn S. Booth November 2001 ASCII HTML 28 L2TP layer two tunneling protocol authentication IP Security

This document discusses how L2TP (Layer Two Tunneling Protocol) may utilize IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed. [STANDARDS-TRACK]

 draft-ietf-l2tpext-security-08 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3193 RFC3194 The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio A. Durand C. Huitema November 2001 ASCII HTML 7 IPng White Paper

This document provides an update on the "H ratio" defined in RFC 1715. It defines a new ratio which the authors claim is easier to understand. This memo provides information for the Internet community.

 draft-durand-huitema-h-density-ratio-01 RFC1715 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3194 RFC3195 Reliable Delivery for syslog D. New M. Rose November 2001 ASCII HTML 36 mappings encryption authentication beep blocks extensible exchange

The BSD Syslog Protocol describes a number of service options related to propagating event messages. This memo describes two mappings of the syslog protocol to TCP connections, both useful for reliable delivery of event messages. [STANDARDS-TRACK]

 draft-ietf-syslog-reliable-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC3195 RFC3196 Internet Printing Protocol/1.1: Implementor's Guide T. Hastings C. Manros P. Zehler C. Kugler H. Holst November 2001 ASCII HTML 96 IPP client object

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). This memo provides information for the Internet community.

 draft-ietf-ipp-implementers-guide-v11-03 RFC2639 INFORMATIONAL INFORMATIONAL IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3196 10.17487/RFC3196 RFC3197 Applicability Statement for DNS MIB Extensions R. Austein November 2001 ASCII HTML 5 DNS-R-MIB Domain Name System Management Information Base

This document explains why, after more than six years as proposed standards, the DNS Server and Resolver MIB extensions were never deployed, and recommends retiring these MIB extensions by moving them to Historical status. This memo provides information for the Internet community.

 draft-ietf-dnsext-dnsmib-historical-00 INFORMATIONAL INFORMATIONAL IETF int dnsext 10.17487/RFC3197 RFC3198 Terminology for Policy-Based Management A. Westerinen J. Schnizlein J. Strassner M. Scherling B. Quinn S. Herzog A. Huynh M. Carlson J. Perry S. Waldbusser November 2001 ASCII HTML 21 glossary network ISDs internet standard documents

This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs). This memo provides information for the Internet community.

 draft-ietf-policy-terminology-04 INFORMATIONAL INFORMATIONAL IETF ops policy 10.17487/RFC3198 RFC3199 Request for Comments Summary RFC Numbers 3100-3199 S. Ginoza February 2003 ASCII HTML 24 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3199 RFC3200 RFC3201 Definitions of Managed Objects for Circuit to Interface Translation R. Steinberger O. Nicklass January 2002 ASCII HTML 23 mib management information base

This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existing MIB modules. [STANDARDS-TRACK]

 draft-ietf-frnetmib-frsi-04 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC3201 RFC3202 Definitions of Managed Objects for Frame Relay Service Level Definitions R. Steinberger O. Nicklass January 2002 ASCII HTML 64 mib management information base

This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service Level Definitions. [STANDARDS-TRACK]

 draft-ietf-frnetmib-frmrelay-service-06 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC3202 RFC3203 DHCP reconfigure extension Y. T'Joens C. Hublet P. De Schrijver December 2001 ASCII HTML 6 dynamic host configuration protocol forcerenew

This document defines extensions to DHCP (Dynamic Host Configuration Protocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). [STANDARDS-TRACK]

 draft-ietf-dhc-pv4-reconfigure-06 RFC6704 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3203 RFC3204 MIME media types for ISUP and QSIG Objects E. Zimmerer J. Peterson A. Vemuri L. Ong F. Audet M. Watson M. Zonoun December 2001 ASCII HTML 10 MIME multipart internet mail extensions

This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN. [STANDARDS-TRACK]

 draft-ietf-sip-isup-mime-10 RFC3459 RFC5621 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3204 10.17487/RFC3204 RFC3205 On the use of HTTP as a Substrate K. Moore February 2002 ASCII HTML 14 hypertext transfer protocol layering

Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-moore-using-http-01 RFC9205 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=3205 10.17487/RFC3205 RFC3206 The SYS and AUTH POP Response Codes R. Gellens February 2002 ASCII HTML 6 security authentication

This memo proposes two response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP-CODE) is defined. [STANDARDS-TRACK]

 draft-gellens-pop-err-01 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3206 RFC3207 SMTP Service Extension for Secure SMTP over Transport Layer Security P. Hoffman February 2002 ASCII HTML 9 SMTP simple mail transfer protocol ssl tls Transport Layer Security

This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]

 draft-hoffman-rfc2487bis-06 RFC2487 RFC7817 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3207 10.17487/RFC3207 RFC3208 PGM Reliable Transport Protocol Specification T. Speakman J. Crowcroft J. Gemmell D. Farinacci S. Lin D. Leshchiner M. Luby T. Montgomery L. Rizzo A. Tweedly N. Bhaskar R. Edmonstone R. Sumanasekera L. Vicisano December 2001 ASCII HTML 111 PGM pragmatic general multicast

Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate- free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency. This memo defines an Experimental Protocol for the Internet community.

 draft-speakman-pgm-spec-07 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3208 10.17487/RFC3208 RFC3209 RSVP-TE: Extensions to RSVP for LSP Tunnels D. Awduche L. Berger D. Gan T. Li V. Srinivasan G. Swallow December 2001 ASCII HTML 61 RSVP resource reservation protocol LSP label switched paths

This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]

 draft-ietf-mpls-rsvp-lsp-tunnel-09 RFC3936 RFC4420 RFC4874 RFC5151 RFC5420 RFC5711 RFC6780 RFC6790 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3209 10.17487/RFC3209 RFC3210 Applicability Statement for Extensions to RSVP for LSP-Tunnels D. Awduche A. Hannan X. Xiao December 2001 ASCII HTML 8 resource reservation protocol label switched paths

This memo discusses the applicability of "Extensions to RSVP (Resource ReSerVation Protocol) for LSP Tunnels". It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track. This memo provides information for the Internet community.

 draft-ietf-mpls-rsvp-tunnel-applicability-02 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3210 RFC3211 Password-based Encryption for CMS P. Gutmann December 2001 ASCII HTML 17 cryptographic message syntax S/MIME key wrap derivation passwordrecipientinfo PWRI

This document provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption. [STANDARDS-TRACK]

 draft-ietf-smime-password-06 RFC3369 RFC3370 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3211 RFC3212 Constraint-Based LSP Setup using LDP B. Jamoussi Editor L. Andersson R. Callon R. Dantu L. Wu P. Doolan T. Worster N. Feldman A. Fredette M. Girish E. Gray J. Heinanen T. Kilty A. Malis January 2002 ASCII HTML 42 CR-LSPs constraint-based routed Label Switched Path LDP Label Distribution Protocol

This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol). [STANDARDS-TRACK]

 draft-ietf-mpls-cr-ldp-06 RFC3468 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3212 RFC3213 Applicability Statement for CR-LDP J. Ash M. Girish E. Gray B. Jamoussi G. Wright January 2002 ASCII HTML 7 constraint-based label distribution protocol

This document discusses the applicability of Constraint-Based LSP Setup using LDP. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track. This memo provides information for the Internet community.

 draft-ietf-mpls-crldp-applic-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3213 RFC3214 LSP Modification Using CR-LDP J. Ash Y. Lee P. Ashwood-Smith B. Jamoussi D. Fedyk D. Skalecki L. Li January 2002 ASCII HTML 11 LSP label switching protocol CR-LDP constraint-based routed label switched paths distribution

This document presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP (Constraint-based Routed Label Switched Paths) using CR-LDP (Constraint-based Routed Label Distribution Protocol) without service interruption. [STANDARDS-TRACK]

 draft-ietf-mpls-crlsp-modify-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3214 RFC3215 LDP State Machine C. Boscher P. Cheval L. Wu E. Gray January 2002 ASCII HTML 78 label distribution protocol

This document provides state machine tables for ATM (Asynchronous Transfer Mode) switch LSRs. In the current LDP specification, there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations. This memo provides information for the Internet community.

 draft-ietf-mpls-ldp-state-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3215 RFC3216 SMIng Objectives C. Elliott D. Harrington J. Jason J. Schoenwaelder F. Strauss W. Weiss December 2001 ASCII HTML 33 SNMP simple network management protocol COPS-PR common open policy service provisioning

This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations. This memo provides information for the Internet community.

 draft-ietf-sming-reqs-06 INFORMATIONAL INFORMATIONAL IETF ops sming 10.17487/RFC3216 RFC3217 Triple-DES and RC2 Key Wrapping R. Housley December 2001 ASCII HTML 9 algorithm data encryption standard

This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key. This memo provides information for the Internet community.

 draft-ietf-smime-key-wrap-01 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3217 10.17487/RFC3217 RFC3218 Preventing the Million Message Attack on Cryptographic Message Syntax E. Rescorla January 2002 ASCII HTML 7 cryptographic syntax

This memo describes a strategy for resisting the Million Message Attack. This memo provides information for the Internet community.

 draft-ietf-smime-pkcs1-01 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3218 10.17487/RFC3218 RFC3219 Telephony Routing over IP (TRIP) J. Rosenberg H. Salama M. Squire January 2002 ASCII HTML 79 TRIP Telephony Routing over IP inter-administrative BGP border gateway protocol

This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. [STANDARDS-TRACK]

 draft-ietf-iptel-trip-09 RFC8602 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel http://www.rfc-editor.org/errata_search.php?rfc=3219 10.17487/RFC3219 RFC3220 IP Mobility Support for IPv4 C. Perkins Editor January 2002 ASCII HTML 98 MOBILEIPSUPIP Internet Protocol

This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS-TRACK]

 draft-ietf-mobileip-rfc2002-bis-08 RFC2002 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3220 10.17487/RFC3220 RFC3221 Commentary on Inter-Domain Routing in the Internet G. Huston December 2001 ASCII HTML 25 BGP border gateway protocol

This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined. This memo provides information for the Internet community.

 draft-iab-bgparch-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3221 RFC3222 Terminology for Forwarding Information Base (FIB) based Router Performance G. Trotter December 2001 ASCII HTML 15 internet protocol routing table benchmark

This document describes the terms to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within a router. The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router. This memo provides information for the Internet community.

 draft-ietf-bmwg-fib-term-04 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3222 RFC3223 RFC3224 Vendor Extensions for Service Location Protocol, Version 2 E. Guttman January 2002 ASCII HTML 10 SLP Service Location Protocol SVRLOC Service Location Protocol opaque

This document specifies how the features of the Service Location Protocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions. The specification introduces a new SLPv2 extension: The Vendor Opaque Extension. While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. This document udpates RFC 2608, "The Service Location Protocol." [STANDARDS-TRACK]

 RFC2608 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3224 10.17487/RFC3224 RFC3225 Indicating Resolver Support of DNSSEC D. Conrad December 2001 ASCII HTML 6 DNSSEC domain name system security extensions

In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-okbit-02 RFC4033 RFC4034 RFC4035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3225 RFC3226 DNSSEC and IPv6 A6 aware server/resolver message size requirements O. Gudmundsson December 2001 ASCII HTML 6 DNSSEC domain name system security extensions space security extensions EDNS0 Extension Mechanisms for DNSEx

This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updates RFC 2535 and RFC 2874, by adding new requirements. [STANDARDS-TRACK]

 draft-ietf-dnsext-message-size-04 RFC2535 RFC2874 RFC4033 RFC4034 RFC4035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3226 10.17487/RFC3226 RFC3227 Guidelines for Evidence Collection and Archiving D. Brezinski T. Killalea February 2002 ASCII HTML 10 security incident

A "security incident" as defined in the "Internet Security Glossary", RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-grip-prot-evidence-05 BCP0055 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grip 10.17487/RFC3227 RFC3228 IANA Considerations for IPv4 Internet Group Management Protocol (IGMP) B. Fenner February 2002 ASCII HTML 4 assigned numbers authority

This memo requests that the IANA create a registry for fields in the IGMP (Internet Group Management Protocol) protocol header, and provides guidance for the IANA to use in assigning parameters for those fields. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-magma-igmp-iana-01 BCP0057 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int magma 10.17487/RFC3228 RFC3229 Delta encoding in HTTP J. Mogul B. Krishnamurthy F. Douglis A. Feldmann Y. Goland A. van Hoff D. Hellerstein January 2002 ASCII HTML 49 HTTP hypertext transfer protocol

This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. [STANDARDS-TRACK]

 draft-mogul-http-delta-10 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3229 RFC3230 Instance Digests in HTTP J. Mogul A. Van Hoff January 2002 ASCII HTML 13 HTTP hypertext transfer protocol

HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. [STANDARDS-TRACK]

 draft-mogul-http-digest-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3230 RFC3231 Definitions of Managed Objects for Scheduling Management Operations D. Levi J. Schoenwaelder January 2002 ASCII HTML 29 mib management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. [STANDARDS-TRACK]

 draft-ietf-disman-schedule-mib-v2-04 RFC2591 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC3231 RFC3232 Assigned Numbers: RFC 1700 is Replaced by an On-line Database J. Reynolds Editor January 2002 ASCII HTML 3 IANA internet assigned numbers authority parameters

This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. This memo provides information for the Internet community.

 RFC1700 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3232 RFC3233 Defining the IETF P. Hoffman S. Bradner February 2002 ASCII HTML 4 internet engineering task force

This document gives a more concrete definition of "the IETF" as it understood today. Many RFCs refer to "the IETF". Many important IETF documents speak of the IETF as if it were an already-defined entity. However, no IETF document correctly defines what the IETF is. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-hoffman-what-is-ietf-05 BCP0058 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3233 RFC3234 Middleboxes: Taxonomy and Issues B. Carpenter S. Brim February 2002 ASCII HTML 27 internet protocol router data path host

This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. This memo provides information for the Internet community.

 draft-carpenter-midtax-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3234 RFC3235 Network Address Translator (NAT)-Friendly Application Design Guidelines D. Senie January 2002 ASCII HTML 13 NAPT ALG firewall

This document discusses those things that application designers might wish to consider when designing new protocols. While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation). This memo provides information for the Internet community.

 draft-ietf-nat-app-guide-07 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC3235 RFC3236 The 'application/xhtml+xml' Media Type M. Baker P. Stark January 2002 ASCII HTML 8 mime multipurpose internet mail extensions

This document defines the 'application/xhtml+xml' MIME media type for XHTML based markup languages; it is not intended to obsolete any previous IETF documents, in particular RFC 2854 which registers 'text/html'. This memo provides information for the Internet community.

 draft-baker-xhtml-media-reg-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3236 RFC3237 Requirements for Reliable Server Pooling M. Tuexen Q. Xie R. Stewart M. Shore L. Ong J. Loughney M. Stillman January 2002 ASCII HTML 10 rserpool application

This document defines a basic set of requirements for reliable server pooling. This memo provides information for the Internet community.

 draft-ietf-rserpool-reqts-03 INFORMATIONAL INFORMATIONAL IETF tsv rserpool 10.17487/RFC3237 RFC3238 IAB Architectural and Policy Considerations for Open Pluggable Edge Services S. Floyd L. Daigle January 2002 ASCII HTML 17 OPES internet architecture board

This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of Open Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user. This memo provides information for the Internet community.

 draft-iab-opes-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3238 RFC3239 Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations C. Kugler H. Lewis T. Hastings February 2002 ASCII HTML 15 object device

This document specifies the requirements and uses cases for some optional administrative operations for use with the Internet Printing Protocol (IPP) version 1.0 and version 1.1. Some of these administrative operations operate on the IPP Job and Printer objects. The remaining operations operate on a new Device object that more closely models a single output device. This memo provides information for the Internet community.

 draft-ietf-ipp-ops-admin-req-01 INFORMATIONAL INFORMATIONAL IETF app ipp 10.17487/RFC3239 RFC3240 Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration D. Clunie E. Cordonnier February 2002 ASCII HTML 6 multipurpose internet mail extensions

This document describes the registration of the MIME sub-type application/dicom (Digital Imaging and Communications in Medicine). The baseline encoding is defined by the DICOM Standards Committee in "Digital Imaging and Communications in Medicine". This memo provides information for the Internet community.

 draft-dicom-media-type-00 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3240 10.17487/RFC3240 RFC3241 Robust Header Compression (ROHC) over PPP C. Bormann April 2002 ASCII HTML 12 ROHC Robust Header Compression PPP point-to-point protocol datagram packets

This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over the Point- to-Point Protocol (PPP). It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS-TRACK]

 draft-ietf-rohc-over-ppp-04 RFC1332 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3241 RFC3242 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP L-E. Jonsson G. Pelletier April 2002 ASCII HTML 21 ROHC RObust Header Compression IP internet protocol UDP user datagram protocol RTP real-time transport protocol application

This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet. [STANDARDS-TRACK]

 draft-ietf-rohc-rtp-lla-03 RFC4362 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3242 RFC3243 RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression L-E. Jonsson April 2002 ASCII HTML 6 internet protocol user datagram real-time application transport applications LLA link-layer assisted

This document contains requirements for the 0-byte IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression scheme to be developed by the Robust Header Compression (ROHC) Working Group. It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general.

 draft-ietf-rohc-rtp-0-byte-requirements-02 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3243 RFC3244 Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols M. Swift J. Trostle J. Brezak February 2002 ASCII HTML 7 security message codes

This memo specifies Microsoft's Windows 2000 Kerberos change password and set password protocols. The Windows 2000 Kerberos change password protocol interoperates with the original Kerberos change password protocol. Change password is a request reply protocol that includes a KRB_PRIV message that contains the new password for the user. This memo provides information for the Internet community.

 draft-trostle-win2k-cat-kerberos-set-passwd-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3244 RFC3245 The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2) J. Klensin Editor IAB March 2002 ASCII HTML 10 IAB ARPA

RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB. It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T Study Group 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community.

 draft-iab-itu-enum-notes-00 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=3245 10.17487/RFC3245 RFC3246 An Expedited Forwarding PHB (Per-Hop Behavior) B. Davie A. Charny J.C.R. Bennet K. Benson J.Y. Le Boudec W. Courtney S. Davari V. Firoiu D. Stiliadis March 2002 ASCII HTML 16 PHB per-hop behavior expedited forwarding differentiated services delay jitter

This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK]

 draft-ietf-diffserv-rfc2598bis-02 RFC2598 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv 10.17487/RFC3246 RFC3247 Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior) A. Charny J. Bennet K. Benson J. Boudec A. Chiu W. Courtney S. Davari V. Firoiu C. Kalmanek K. Ramakrishnan March 2002 ASCII HTML 24 differentiated services fifo fair queuing delay jitter

This document was written during the process of clarification of RFC2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revised EF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures. This memo provides information for the Internet community.

 draft-ietf-diffserv-ef-supplemental-01 INFORMATIONAL INFORMATIONAL IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=3247 10.17487/RFC3247 RFC3248 A Delay Bound alternative revision of RFC 2598 G. Armitage B. Carpenter A. Casati J. Crowcroft J. Halpern B. Kumar J. Schnizlein March 2002 ASCII HTML 11 per hop behavior phb expedited forwarding ef db

For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in the DiffServ group. At the San Diego IETF meeting in December 2000 the DiffServ working group decided to pursue an alternative re-expression of the EF PHB. This memo provides information for the Internet community.

 draft-ietf-diffserv-efresolve-01 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC3248 RFC3249 Implementers Guide for Facsimile Using Internet Mail V. Cancio M. Moldovan H. Tamura D. Wing September 2002 ASCII HTML 21 fax tiff tiff-fx ifax e-mail email esmtp dsn mdn

This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents. This memo provides information for the Internet community.

 draft-ietf-fax-implementers-guide-07 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC3249 RFC3250 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration L. McIntyre G. Parsons J. Rafferty September 2002 ASCII HTML 7 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS-TRACK]

 draft-ietf-fax-tiff-fx-reg-01 RFC3950 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC3250 RFC3251 Electricity over IP B. Rajagopalan April 1 2002 ASCII HTML 9 Internet Protocol

Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity. This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors). Readers of the previous work have been observed scratching their heads and muttering, "What next?". This document answers that question. This memo provides information for the Internet community.

 draft-bala-mplamps-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3251 RFC3252 Binary Lexical Octet Ad-hoc Transport H. Kennedy April 1 2002 ASCII HTML 16 bloat

This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3252 RFC3253 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) G. Clemm J. Amsden T. Ellison C. Kaler J. Whitehead March 2002 ASCII HTML 118 HTTP hypertext transfer protocol clients label configuration management WebDAV Web Distributed Authoring and Versioning

This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. [STANDARDS-TRACK]

 draft-ietf-deltav-versioning-20 PROPOSED STANDARD PROPOSED STANDARD IETF app deltav http://www.rfc-editor.org/errata_search.php?rfc=3253 10.17487/RFC3253 RFC3254 Definitions for talking about directories H. Alvestrand April 2002 ASCII HTML 11 domain name system lightweight access protocol

When discussing systems for making information accessible through the Internet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use. For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency. On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability. This document discusses one group of such systems which is known under the term, "directories". This memo provides information for the Internet community.

 draft-alvestrand-directory-defs-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3254 RFC3255 Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads N. Jones C. Murton April 2002 ASCII HTML 8 PPP Point-to-Point Protocol SONET/SDH Synchronous Optical NETwork/Synchronous Digital Hierarchy

This document describes an extension to the mapping of Point-to-Point Protocol (PPP) into Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) to include the use of SONET/SDH SPE/VC virtual concatenation and the use of both high order and low order payloads. [STANDARDS-TRACK]

 draft-ietf-pppext-posvcholo-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3255 RFC3256 The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option D. Jones R. Woundy April 2002 ASCII HTML 5 DOCSIS Data-Over-Cable Service Interface Specification DHCP Dynamic Host Configuration Protocol

This document proposes a new sub-option to the DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Option. [STANDARDS-TRACK]

 draft-ietf-dhc-agentoptions-device-class-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3256 RFC3257 Stream Control Transmission Protocol Applicability Statement L. Coene April 2002 ASCII HTML 13 sctp udp tcp rtp transport security transport nat multihoming

This document describes the applicability of the Stream Control Transmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) & Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP. This memo provides information for the Internet community.

 draft-ietf-sigtran-sctp-applicability-08 INFORMATIONAL INFORMATIONAL IETF rai sigtran 10.17487/RFC3257 RFC3258 Distributing Authoritative Name Servers via Shared Unicast Addresses T. Hardie April 2002 ASCII HTML 11 dns network topology latency

This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under- served areas of the network topology and to reduce the latency for DNS query responses in those areas. This memo provides information for the Internet community.

 draft-ietf-dnsop-hardie-shared-root-server-07 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC3258 RFC3259 A Message Bus for Local Coordination J. Ott C. Perkins D. Kutscher April 2002 ASCII HTML 39 mbus message ip multicast addressing transport syntax

The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms. This memo provides information for the Internet community.

 draft-ietf-mmusic-mbus-transport-06 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC3259 RFC3260 New Terminology and Clarifications for Diffserv D. Grossman April 2002 ASCII HTML 10 DIFFSRV scalability IP internet protocol

This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. This memo provides information for the Internet community.

 draft-ietf-diffserv-new-terms-08 RFC2474 RFC2475 RFC2597 INFORMATIONAL INFORMATIONAL IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=3260 10.17487/RFC3260 RFC3261 SIP: Session Initiation Protocol J. Rosenberg H. Schulzrinne G. Camarillo A. Johnston J. Peterson R. Sparks M. Handley E. Schooler June 2002 ASCII HTML 269 SIP Session Initiation Protocol application-layer multimedia multicast unicast

This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]

 draft-ietf-sip-rfc2543bis-09 RFC2543 RFC3265 RFC3853 RFC4320 RFC4916 RFC5393 RFC5621 RFC5626 RFC5630 RFC5922 RFC5954 RFC6026 RFC6141 RFC6665 RFC6878 RFC7462 RFC7463 RFC8217 RFC8591 RFC8760 RFC8898 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3261 10.17487/RFC3261 RFC3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne June 2002 ASCII HTML 14 SIP Session Initiation Protocol application-layer multimedia multicast unicast

This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method. [STANDARDS-TRACK]

 draft-ietf-sip-100rel-06 RFC2543 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3262 10.17487/RFC3262 RFC3263 Session Initiation Protocol (SIP): Locating SIP Servers J. Rosenberg H. Schulzrinne June 2002 ASCII HTML 17 SIP Session Initiation Protocol application-layer multimedia multicast unicast

The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. [STANDARDS-TRACK]

 draft-ietf-sip-srv-06 RFC2543 RFC7984 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3263 RFC3264 An Offer/Answer Model with Session Description Protocol (SDP) J. Rosenberg H. Schulzrinne June 2002 ASCII HTML 25 SDP Session Description Protocol application-layer multimedia multicast unicast

This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-offer-answer-02 RFC2543 RFC6157 RFC8843 RFC9143 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3264 10.17487/RFC3264 RFC3265 Session Initiation Protocol (SIP)-Specific Event Notification A. B. Roach June 2002 ASCII HTML 38 SIP Session Initiation Protocol application-layer multimedia multicast unicast

This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. [STANDARDS-TRACK]

 draft-ietf-sip-events-05 RFC2543 RFC6665 RFC3261 RFC5367 RFC5727 RFC6446 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3265 10.17487/RFC3265 RFC3266 Support for IPv6 in Session Description Protocol (SDP) S. Olson G. Camarillo A. B. Roach June 2002 ASCII HTML 5 internet addresses syntax

This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP). Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-ipv6-03 RFC4566 RFC2327 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3266 10.17487/RFC3266 RFC3267 Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs J. Sjoberg M. Westerlund A. Lakaniemi Q. Xie June 2002 ASCII HTML 49 RTP Real-Time Transport Protocol Adaptive Multi-Rate AMR Adaptive Multi-Rate Wideband AMR-WB interoperate applications

This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-amr-13 RFC4867 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3267 10.17487/RFC3267 RFC3268 Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) P. Chown June 2002 ASCII HTML 7 AES Advanced Encryption Standard TLS Transport Layer Security idea international data algorithm symmetric

This document proposes several new ciphersuites. At present, the symmetric ciphers supported by Transport Layer Security (TLS) are RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES), and triple DES. The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites. [STANDARDS-TRACK]

 draft-ietf-tls-ciphersuite-06 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC3268 RFC3269 Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents R. Kermode L. Vicisano April 2002 ASCII HTML 12 definitions operation

This document provides general guidelines to assist the authors of Reliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed. This memo provides information for the Internet community.

 draft-ietf-rmt-author-guidelines-03 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC3269 RFC3270 Multi-Protocol Label Switching (MPLS) Support of Differentiated Services F. Le Faucheur L. Wu B. Davie S. Davari P. Vaananen R. Krishnan P. Cheval J. Heinanen May 2002 ASCII HTML 64 MPLS Multi-Protocol Label Switching diff-serv Differentiated Services BA behaviour aggregate LSP label switched paths

This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. [STANDARDS-TRACK]

 draft-ietf-mpls-diff-ext-09 RFC3032 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3270 10.17487/RFC3270 RFC3271 The Internet is for Everyone V. Cerf April 2002 ASCII HTML 6 isoc internet society policy issues social impact economic impact international policy use and abuse of the internet

This document expresses the Internet Society's ideology that the Internet really is for everyone. However, it will only be such if we make it so. This memo provides information for the Internet community.

 draft-isoc-internet-for-everyone-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3271 10.17487/RFC3271 RFC3272 Overview and Principles of Internet Traffic Engineering D. Awduche A. Chiu A. Elwalid I. Widjaja X. Xiao May 2002 ASCII HTML 71 te ip networks

This memo describes the principles of Traffic Engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document. This memo provides information for the Internet community.

 draft-ietf-tewg-principles-02 RFC5462 INFORMATIONAL INFORMATIONAL IETF subip tewg http://www.rfc-editor.org/errata_search.php?rfc=3272 10.17487/RFC3272 RFC3273 Remote Network Monitoring Management Information Base for High Capacity Networks S. Waldbusser July 2002 ASCII HTML 77 rmon Remote Network Monitoring mib management information base high speed networks

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring (RMON) devices for use on high speed networks. This document contains a MIB Module that defines these new objects and also contains definitions of some updated objects from the RMON-MIB in RFC 2819 and the RMON2-MIB in RFC 2021. [PROPOSED STANDARD]

 draft-ietf-rmonmib-hcrmon-10 RFC4502 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3273 RFC3274 Compressed Data Content Type for Cryptographic Message Syntax (CMS) P. Gutmann June 2002 ASCII HTML 6 CMS Cryptographic Message Syntax content info type

This document defines a format for using compressed data as a Cryptographic Message Syntax (CMS) content type. Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). [STANDARDS-TRACK]

 draft-ietf-smime-compression-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3274 RFC3275 (Extensible Markup Language) XML-Signature Syntax and Processing D. Eastlake 3rd J. Reagle D. Solo March 2002 ASCII HTML 73 XML extensible markup language

This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK]

 draft-ietf-xmldsig-core-2-03 RFC3075 DRAFT STANDARD DRAFT STANDARD IETF sec xmldsig http://www.rfc-editor.org/errata_search.php?rfc=3275 10.17487/RFC3275 RFC3276 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing B. Ray R. Abbi May 2002 ASCII HTML 66 mib interfaces

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. [STANDARDS-TRACK]

 draft-ietf-adslmib-hdsl2-12 RFC4319 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC3276 RFC3277 Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance D. McPherson April 2002 ASCII HTML 6 router

This document describes a simple, interoperable mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. This memo provides information for the Internet community.

 draft-ietf-isis-transient-02 INFORMATIONAL INFORMATIONAL IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=3277 10.17487/RFC3277 RFC3278 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) S. Blake-Wilson D. Brown P. Lambert April 2002 ASCII HTML 16 public key digital signatures authentication

This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard. This memo provides information for the Internet community.

 draft-ietf-smime-ecc-06 RFC5753 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3278 10.17487/RFC3278 RFC3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile L. Bassham W. Polk R. Housley April 2002 ASCII HTML 27 ASN.1 X.509 PKI Public Key Infrastructure CRL Certificate Revocation List

This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS-TRACK]

 draft-ietf-pkix-ipki-pkalgs-05 RFC4055 RFC4491 RFC5480 RFC5758 RFC8692 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3279 10.17487/RFC3279 RFC3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile R. Housley W. Polk W. Ford D. Solo April 2002 ASCII HTML 129 X.509 PKI Public Key Infrastructure CRL Certificate Revocation List

This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. [STANDARDS-TRACK]

 draft-ietf-pkix-new-part1-12 RFC2459 RFC5280 RFC4325 RFC4630 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3280 10.17487/RFC3280 RFC3281 An Internet Attribute Certificate Profile for Authorization S. Farrell R. Housley April 2002 ASCII HTML 40 electronic mail email ipsec www security

This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. [STANDARDS-TRACK]

 draft-ietf-pkix-ac509prof-09 RFC5755 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3281 10.17487/RFC3281 RFC3282 Content Language Headers H. Alvestrand May 2002 ASCII HTML 8 Content-language Accept-Language header

This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an "Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language. [STANDARDS-TRACK]

 draft-alvestrand-content-language-03 RFC1766 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC3282 RFC3283 Guide to Internet Calendaring B. Mahoney G. Babics A. Taler June 2002 ASCII HTML 16 scheduling systems cap calendar access protocool itip imip

This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The work in progress addressed is "Calendar Access Protocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work. This memo provides information for the Internet community.

 draft-ietf-calsch-inetcal-guide-02 INFORMATIONAL INFORMATIONAL IETF app calsch 10.17487/RFC3283 RFC3284 The VCDIFF Generic Differencing and Compression Data Format D. Korn J. MacDonald J. Mogul K. Vo June 2002 ASCII HTML 29 VCDIFF transport portable at&t encoding

This memo describes VCDIFF, a general, efficient and portable data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers. [STANDARDS-TRACK]

 draft-korn-vcdiff-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3284 RFC3285 Using Microsoft Word to create Internet Drafts and RFCs M. Gahrns T. Hain May 2002 ASCII HTML 19

This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format. This memo provides information for the Internet community.

 draft-hain-msword-template-04 RFC5385 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3285 RFC3286 An Introduction to the Stream Control Transmission Protocol (SCTP) L. Ong J. Yoakum May 2002 ASCII HTML 10 transport layer telephony signaling

This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP). It is intended as a guide for potential users of SCTP as a general purpose transport protocol. This memo provides information for the Internet community.

 draft-ong-sigtran-sctpover-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3286 RFC3287 Remote Monitoring MIB Extensions for Differentiated Services A. Bierman July 2002 ASCII HTML 120 rmon Remote Monitoring MIB management information base diffserv Differentiated Services

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring Differentiated Services (DS) Codepoint usage in packets which contain a DS field, utilizing the monitoring framework defined in the RMON-2 (Remote Network Monitoring Management Version 2) MIB. [STANDARDS-TRACK]

 draft-ietf-rmonmib-dsmon-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3287 RFC3288 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) E. O'Tuathail M. Rose June 2002 ASCII HTML 20 binding markup language xml

This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network. [STANDARDS-TRACK]

 draft-etal-beep-soap-06 RFC4227 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3288 RFC3289 Management Information Base for the Differentiated Services Architecture F. Baker K. Chan A. Smith May 2002 ASCII HTML 116 mib Management Information Base diffserv Differentiated Services Architecture router

This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. [STANDARDS-TRACK]

 draft-ietf-diffserv-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=3289 10.17487/RFC3289 RFC3290 An Informal Management Model for Diffserv Routers Y. Bernet S. Blake D. Grossman A. Smith May 2002 ASCII HTML 56 differentiated services

This document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture. This memo provides information for the Internet community.

 draft-ietf-diffserv-model-06 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC3290 RFC3291 Textual Conventions for Internet Network Addresses M. Daniele B. Haberman S. Routhier J. Schoenwaelder May 2002 ASCII HTML 20 tc textual conventions mib layer management information base

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-ops-rfc2851-update-06 RFC2851 RFC4001 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC3291 RFC3292 General Switch Management Protocol (GSMP) V3 A. Doria F. Hellstrand K. Sundell T. Worster June 2002 ASCII HTML 137 GSMP general switch label protocol unicast multicast qos quality of service

This document describes the General Switch Management Protocol Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch such as, an ATM, frame relay or MPLS switch. The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources and QoS features. [STANDARDS-TRACK]

 draft-ietf-gsmp-11 PROPOSED STANDARD PROPOSED STANDARD IETF subip gsmp 10.17487/RFC3292 RFC3293 General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP) T. Worster A. Doria J. Buerkle June 2002 ASCII HTML 9 GSMP General Switch Management Protocol ATM Asynchronous Transfer Mode TCP Transmission Control Protocol

This memo specifies the encapsulation of GSMP (General Switch Management Protocol) packets in ATM (Asynchronous Transfer Mode), Ethernet and TCP (Transmission Control Protocol). [STANDARDS-TRACK]

 draft-ietf-gsmp-encaps-05 PROPOSED STANDARD PROPOSED STANDARD IETF subip gsmp 10.17487/RFC3293 RFC3294 General Switch Management Protocol (GSMP) Applicability A. Doria K. Sundell June 2002 ASCII HTML 9 internet

This memo provides an overview of the GSMP (General Switch Management Protocol) and includes information relating to its deployment in a IP network in an MPLS environment. It does not discuss deployment in an ATM (Asynchronous Transfer Mode) network or in a raw ethernet configuration. This memo provides information for the Internet community.

 draft-ietf-gsmp-applicability-02 INFORMATIONAL INFORMATIONAL IETF subip gsmp 10.17487/RFC3294 RFC3295 Definitions of Managed Objects for the General Switch Management Protocol (GSMP) H. Sjostrand J. Buerkle B. Srinivasan June 2002 ASCII HTML 47 mib management information base controller gsmp-mib General Switch Management Protocol

This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community. In particular, it describes managed objects for the General Switch Management Protocol (GSMP). [STANDARDS-TRACK]

 draft-ietf-gsmp-mib-07 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF subip gsmp 10.17487/RFC3295 RFC3296 Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories K. Zeilenga July 2002 ASCII HTML 14 LDAP Lightweight Directory Access Protocol schema elements description formats

This document details schema and protocol elements for representing and managing named subordinate references in Lightweight Directory Access Protocol (LDAP) Directories. [STANDARDS-TRACK]

 draft-zeilenga-ldap-namedref-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3296 RFC3297 Content Negotiation for Messaging Services based on Email G. Klyne R. Iwazaki D. Crocker July 2002 ASCII HTML 46 content negotiation facsimile

This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email. [STANDARDS-TRACK]

 draft-ietf-fax-content-negotiation-05 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=3297 10.17487/RFC3297 RFC3298 Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements I. Faynberg J. Gato H. Lu L. Slutsman August 2002 ASCII HTML 17 support

This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN. To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. This memo provides information for the Internet community.

 draft-ietf-spirits-reqs-04 INFORMATIONAL INFORMATIONAL IETF tsv spirits 10.17487/RFC3298 RFC3299 Request for Comments Summary RFC Numbers 3200-3299 S. Ginoza December 2003 ASCII HTML 30 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3299 RFC3300 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza A. De La Cruz November 2002 ASCII HTML 49 RFC3000 RFC3600 HISTORIC INTERNET STANDARD INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3300 10.17487/RFC3300 RFC3301 Layer Two Tunnelling Protocol (L2TP): ATM access network extensions Y. T'Joens P. Crivellari B. Sales June 2002 ASCII HTML 19 L2TP Layer Two Tunneling Protocol draft-ietf-l2tpext-atmext-04 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3301 RFC3302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration G. Parsons J. Rafferty September 2002 ASCII HTML 8 TIFF Tag Image File Format MIME Multipurpose Internet Mail Extensions draft-ietf-fax-tiff-regbis-05 RFC2302 DRAFT STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC3302 RFC3303 Middlebox communication architecture and framework P. Srisuresh J. Kuthan J. Rosenberg A. Molitor A. Rayhan August 2002 ASCII HTML 34 midcom draft-ietf-midcom-framework-07 INFORMATIONAL INFORMATIONAL IETF tsv midcom 10.17487/RFC3303 RFC3304 Middlebox Communications (midcom) Protocol Requirements R. P. Swale P. A. Mart P. Sijben S. Brim M. Shore August 2002 ASCII HTML 9 nat network address protocol firewall middleboxes draft-ietf-midcom-requirements-05 INFORMATIONAL INFORMATIONAL IETF tsv midcom http://www.rfc-editor.org/errata_search.php?rfc=3304 10.17487/RFC3304 RFC3305 Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations M. Mealling Editor R. Denenberg Editor August 2002 ASCII HTML 11 internet engineering task force draft-mealling-uri-ig-02 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3305 10.17487/RFC3305 RFC3306 Unicast-Prefix-based IPv6 Multicast Addresses B. Haberman D. Thaler August 2002 ASCII HTML 7 IPv6 internet protocol multicast draft-ietf-ipngwg-uni-based-mcast-03 RFC3956 RFC4489 RFC7371 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3306 RFC3307 Allocation Guidelines for IPv6 Multicast Addresses B. Haberman August 2002 ASCII HTML 8 IPv6 internet protocol multicast draft-ietf-malloc-ipv6-guide-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC3307 RFC3308 Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension P. Calhoun W. Luo D. McPherson K. Peirce November 2002 ASCII HTML 10 L2TP Layer Two Tunneling Protocol per hop behavior phb diffserv Differentiated Services Extension draft-ietf-l2tpext-ds-05 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3308 RFC3309 Stream Control Transmission Protocol (SCTP) Checksum Change J. Stone R. Stewart D. Otis September 2002 ASCII HTML 17 adler-32 checksum error detection draft-ietf-tsvwg-sctpcsum-07 RFC4960 RFC2960 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3309 RFC3310 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) A. Niemi J. Arkko V. Torvinen September 2002 ASCII HTML 18 one-time password generation mechanism umts universal mobile telecommunications system draft-ietf-sip-digest-aka-03 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC3310 RFC3311 The Session Initiation Protocol (SIP) UPDATE Method J. Rosenberg October 2002 ASCII HTML 13 SIP Session Initiation Protocol parameters media streams draft-ietf-sip-update-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3311 RFC3312 Integration of Resource Management and Session Initiation Protocol (SIP) G. Camarillo Editor W. Marshall Editor J. Rosenberg October 2002 ASCII PS PDF HTML 30 SIP Session Initiation Protocol qos quality of service precondition draft-ietf-sip-manyfolks-resource-07 RFC4032 RFC5027 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3312 10.17487/RFC3312 RFC3313 Private Session Initiation Protocol (SIP) Extensions for Media Authorization W. Marshall Editor January 2003 ASCII HTML 16 qos quality of service draft-ietf-sip-call-auth-06 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC3313 RFC3314 Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards M. Wasserman Editor September 2002 ASCII HTML 23 internet protocol draft-ietf-ipv6-3gpp-recommend-02 INFORMATIONAL INFORMATIONAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=3314 10.17487/RFC3314 RFC3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) R. Droms Editor J. Bound B. Volz T. Lemon C. Perkins M. Carney July 2003 ASCII HTML 101 DHCPv6 Dynamic Host Configuration Protocol for IPv6 internet protocol parameters addresses draft-ietf-dhc-dhcpv6-28 RFC8415 RFC4361 RFC5494 RFC6221 RFC6422 RFC6644 RFC7083 RFC7227 RFC7283 RFC7550 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3315 10.17487/RFC3315 RFC3316 Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts J. Arkko G. Kuijpers H. Soliman J. Loughney J. Wiljakka April 2003 ASCII HTML 22 links bandwidth draft-ietf-ipv6-cellular-host-03 RFC7066 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3316 RFC3317 Differentiated Services Quality of Service Policy Information Base K. Chan R. Sahita S. Hahn K. McCloghrie March 2003 ASCII HTML 96 pib differentiated services architecture draft-ietf-diffserv-pib-08 HISTORIC INFORMATIONAL IETF tsv diffserv 10.17487/RFC3317 RFC3318 Framework Policy Information Base R. Sahita Editor S. Hahn K. Chan K. McCloghrie March 2003 ASCII HTML 70

This document defines a set of PRovisioning Classes (PRCs) and textual conventions that are common to all clients that provision policy using Common Open Policy Service (COPS) protocol for Provisioning.

Structure of Policy Provisioning Information (SPPI) describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well-defined (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB).

One way to provision policy is by means of the (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security.

As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules. However, some PRovisioning Classes are common to all subject-categories (client-types) and need to be present in each.

 draft-ietf-rap-frameworkpib-09 HISTORIC INFORMATIONAL IETF ops rap 10.17487/RFC3318 RFC3319 Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers H. Schulzrinne B. Volz July 2003 ASCII HTML 7 DHCPv6 Dynamic Host Configuration Protocol SIP Session Initiation Protocol outbound proxy servers draft-ietf-sip-dhcpv6-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3319 RFC3320 Signaling Compression (SigComp) R. Price C. Bormann J. Christoffersson H. Hannu Z. Liu J. Rosenberg January 2003 ASCII HTML 62 sip session initiation protocol udvm universal decompressor virtual machine SigComp Signaling Compression draft-ietf-rohc-sigcomp-07 RFC4896 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3320 RFC3321 Signaling Compression (SigComp) - Extended Operations H. Hannu J. Christoffersson S. Forsgren K.-C. Leung Z. Liu R. Price January 2003 ASCII HTML 19 sip session initiation protocol udvm universal decompressor virtual machine SigComp Signaling Compression draft-ietf-rohc-sigcomp-extended-04 RFC4896 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3321 RFC3322 Signaling Compression (SigComp) Requirements & Assumptions H. Hannu January 2003 ASCII HTML 13 sip session initiation protocol wireless cellular sdp session description protocol SigComp Signaling Compression draft-ietf-rohc-signaling-req-assump-06 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3322 RFC3323 A Privacy Mechanism for the Session Initiation Protocol (SIP) J. Peterson November 2002 ASCII HTML 22 SIP Session Initiation Protocol privacy service draft-ietf-sip-privacy-general-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3323 10.17487/RFC3323 RFC3324 Short Term Requirements for Network Asserted Identity M. Watson November 2002 ASCII HTML 11 session initiation protocol sip ua user agent draft-ietf-sipping-nai-reqs-02 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3324 RFC3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks C. Jennings J. Peterson M. Watson November 2002 ASCII HTML 18 trust domain draft-ietf-sip-asserted-identity-01 RFC5876 RFC8217 INFORMATIONAL INFORMATIONAL IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3325 10.17487/RFC3325 RFC3326 The Reason Header Field for the Session Initiation Protocol (SIP) H. Schulzrinne D. Oran G. Camarillo December 2002 ASCII HTML 8 SIP Session Initiation Protocol heterogeneous error response forking problem herfp

The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism. [STANDARDS-TRACK]

 draft-ietf-sip-reason-01 RFC8606 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3326 RFC3327 Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts D. Willis B. Hoeneisen December 2002 ASCII HTML 17 SIP Session Initiation Protocol 3gpp register contact path registrar user agent ua draft-willis-sip-path-08 RFC5626 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3327 10.17487/RFC3327 RFC3328 RFC3329 Security Mechanism Agreement for the Session Initiation Protocol (SIP) J. Arkko V. Torvinen G. Camarillo A. Niemi T. Haukka January 2003 ASCII HTML 24 SIP Session Initiation Protocol UA user agent draft-ietf-sip-sec-agree-05 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3329 10.17487/RFC3329 RFC3330 Special-Use IPv4 Addresses IANA September 2002 ASCII HTML 7 internet protocol space assignments draft-iana-special-ipv4-05 RFC5735 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3330 10.17487/RFC3330 RFC3331 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer K. Morneault R. Dantu G. Sidebottom B. Bidulock J. Heitz September 2002 ASCII HTML 94 sctp stream control transmission protocol sg signaling gateway media gateway controller mgc draft-ietf-sigtran-m2ua-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=3331 10.17487/RFC3331 RFC3332 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) G. Sidebottom Editor K. Morneault Editor J. Pastor-Balbas Editor September 2002 ASCII HTML 120 isup sccp sctp stream control tranmission protocol mgc media gateway protocol st signalling gateway draft-ietf-sigtran-m3ua-12 RFC4666 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3332 RFC3333 RFC3334 Policy-Based Accounting T. Zseby S. Zander C. Carle October 2002 ASCII HTML 44 measurement metering meter configuration qos auditing aaa architecture inter-domain accounting draft-irtf-aaaarch-pol-acct-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3334 RFC3335 MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet T. Harding R. Drummond C. Shih September 2002 ASCII HTML 29 MIME multipurpose internet mail extensions edi Electronic Data Interchange-Internet Integration draft-ietf-ediint-as1-17 PROPOSED STANDARD PROPOSED STANDARD IETF app ediint 10.17487/RFC3335 RFC3336 PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2) B. Thompson T. Koren B. Buffam December 2002 ASCII HTML 16 PPP point-to-point protocol atm Asynchronous Transfer Mode aal2 datagram packets draft-ietf-pppext-ppp-over-aal2-03 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3336 RFC3337 Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2 B. Thompson T. Koren B. Buffam December 2002 ASCII HTML 7 PPP point-to-point protocol ATM Asynchronous Transfer Mode Adaptation Layer 2 aal2 encapsulation draft-ietf-pppext-ppp-over-aal2-class-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3337 RFC3338 Dual Stack Hosts Using "Bump-in-the-API" (BIA) S. Lee M-K. Shin Y-J. Kim E. Nordmark A. Durand October 2002 ASCII HTML 17 BIA Bump-in-the-API draft-ietf-ngtrans-bia-05 RFC6535 EXPERIMENTAL EXPERIMENTAL IETF ops ngtrans 10.17487/RFC3338 RFC3339 Date and Time on the Internet: Timestamps G. Klyne C. Newman July 2002 ASCII HTML 18 Timestamps gregorian calendar iso International Organization for Standardization

This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.

 draft-ietf-impp-datetime-05 PROPOSED STANDARD PROPOSED STANDARD IETF app impp http://www.rfc-editor.org/errata_search.php?rfc=3339 10.17487/RFC3339 RFC3340 The Application Exchange Core M. Rose G. Klyne D. Crocker July 2002 ASCII HTML 40 APEX Application Exchange Core draft-ietf-apex-core-06 HISTORIC PROPOSED STANDARD IETF app apex 10.17487/RFC3340 RFC3341 The Application Exchange (APEX) Access Service M. Rose G. Klyne D. Crocker July 2002 ASCII HTML 26 APEX Application Exchange draft-ietf-apex-access-08 HISTORIC PROPOSED STANDARD IETF app apex 10.17487/RFC3341 RFC3342 The Application Exchange (APEX) Option Party Pack, Part Deux! E. Dixon H. Franklin J. Kint G. Klyne D. New S. Pead M. Rose M. Schwartz July 2002 ASCII HTML 22 APEX Application Exchange datagram service core relaying mesh draft-ietf-apex-party-04 HISTORIC PROPOSED STANDARD IETF app apex 10.17487/RFC3342 RFC3343 The Application Exchange (APEX) Presence Service M. Rose G. Klyne D. Crocker April 2003 ASCII HTML 23 APEX Application Exchange endpoint draft-ietf-apex-presence-06 HISTORIC EXPERIMENTAL IETF app apex 10.17487/RFC3343 RFC3344 IP Mobility Support for IPv4 C. Perkins Editor August 2002 ASCII HTML 99 MOBILEIPSUPIP Internet Protocol Mobility Support for IPv4 RFC3220 RFC5944 RFC4636 RFC4721 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3344 10.17487/RFC3344 RFC3345 Border Gateway Protocol (BGP) Persistent Route Oscillation Condition D. McPherson V. Gill D. Walton A. Retana August 2002 ASCII HTML 19 idr ibgp draft-ietf-idr-route-oscillation-01 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=3345 10.17487/RFC3345 RFC3346 Applicability Statement for Traffic Engineering with MPLS J. Boyle V. Gill A. Hannan D. Cooper D. Awduche B. Christian W.S. Lai August 2002 ASCII HTML 14 multiprotocol label switching te draft-ietf-tewg-te-applicability-01 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC3346 RFC3347 Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations M. Krueger R. Haagens July 2002 ASCII HTML 26 iSCSI Small Computer Systems Interface TCP Transmission Control Protocol storage fibre channel draft-ietf-ips-iscsi-reqmts-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3347 RFC3348 The Internet Message Action Protocol (IMAP4) Child Mailbox Extension M. Gahrns R. Cheng July 2002 ASCII HTML 6 children draft-gahrns-imap-child-mailbox-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3348 10.17487/RFC3348 RFC3349 A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force M. Rose July 2002 ASCII HTML 6 beep draft-mrose-beep-transientid-02 BCP0059 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3349 RFC3350 RFC3351 User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals N. Charlton M. Gasson G. Gybels M. Spanner A. van Wijk August 2002 ASCII HTML 17 relay service transcoding service textphone draft-ietf-sipping-deaf-req-03 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3351 RFC3352 Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status K. Zeilenga March 2003 ASCII HTML 4 CLDAP CLDAP Presentation Address Application Entity Title draft-zeilenga-cldap-02 RFC1798 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3352 RFC3353 Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment D. Ooms B. Sales W. Livens A. Acharya F. Griffoul F. Ansari August 2002 ASCII HTML 30 inrternet protocol l2 multicast routing protocoln draft-ietf-mpls-multicast-08 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3353 RFC3354 Internet Open Trading Protocol Version 2 Requirements D. Eastlake 3rd August 2002 ASCII HTML 6 payment ecommerce merchant customer delivery signature messaging commerce sale draft-ietf-trade-iotp2-req-02 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3354 RFC3355 Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5) A. Singh R. Turner R. Tio S. Nanji August 2002 ASCII HTML 13 L2TP Layer Two Tunneling Protocol link dial-up server ATM asynchronous transfer mode adaptation layer draft-ietf-l2tpext-l2tp-atm-03 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3355 RFC3356 Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines G. Fishman S. Bradner August 2002 ASCII HTML 12 internet society engineering task force draft-fishman-2436bis-02 RFC2436 RFC6756 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3356 RFC3357 One-way Loss Pattern Sample Metrics R. Koodli R. Ravikanth August 2002 ASCII HTML 15 packets voice video stream draft-ietf-ippm-loss-pattern-07 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC3357 RFC3358 Optional Checksums in Intermediate System to Intermediate System (ISIS) T. Przygienda August 2002 ASCII HTML 4 type length value complete sequence number partial data draft-ietf-isis-wg-snp-checksum-03 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3358 RFC3359 Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System T. Przygienda August 2002 ASCII HTML 5 is-is igp osi complete sequence number partial data draft-ietf-isis-wg-tlv-codepoints-01 INFORMATIONAL INFORMATIONAL IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=3359 10.17487/RFC3359 RFC3360 Inappropriate TCP Resets Considered Harmful S. Floyd August 2002 ASCII HTML 19 transmission control protocol rst bit connection draft-floyd-tcp-reset-04 BCP0060 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3360 RFC3361 Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers H. Schulzrinne August 2002 ASCII HTML 7 DHCP Dynamic Host Configuration Protocol SIP Session Initiation Protocol proxy servers draft-ietf-sip-dhcp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3361 RFC3362 Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration G. Parsons August 2002 ASCII HTML 5 T.38 Real-time Facsimile MIME Multipurpose Internet Mail Extensions image/t38 draft-parsons-itu-t38-reg-00 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3362 RFC3363 Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) R. Bush A. Durand B. Fink O. Gudmundsson T. Hain August 2002 ASCII HTML 6 reverse mapping label binary draft-ietf-dnsext-ipv6-addresses-02 RFC2673 RFC2874 RFC6672 INFORMATIONAL INFORMATIONAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3363 10.17487/RFC3363 RFC3364 Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) R. Austein August 2002 ASCII HTML 11 reverse mapping rrs resource records draft-ietf-dnsext-ipv6-dns-tradeoffs-02 RFC2673 RFC2874 INFORMATIONAL INFORMATIONAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3364 10.17487/RFC3364 RFC3365 Strong Security Requirements for Internet Engineering Task Force Standard Protocols J. Schiller August 2002 ASCII HTML 8 ietf draft-ietf-saag-whyenc-00 BCP0061 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3365 RFC3366 Advice to link designers on link Automatic Repeat reQuest (ARQ) G. Fairhurst L. Wood August 2002 ASCII HTML 27 tcp/ip subnetworks draft-ietf-pilc-link-arq-issues-04 BCP0062 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3366 RFC3367 Common Name Resolution Protocol (CNRP) N. Popp M. Mealling M. Moseley August 2002 ASCII HTML 42 CNRP Common Name Resolution Protocol unique resource locators client applications draft-ietf-cnrp-12 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3367 RFC3368 The 'go' URI Scheme for the Common Name Resolution Protocol M. Mealling August 2002 ASCII HTML 8 URI uniform resource identifier CNRP Common Name Resolution Protocol draft-ietf-cnrp-uri-07 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3368 RFC3369 Cryptographic Message Syntax (CMS) R. Housley August 2002 ASCII HTML 52 digitally sign authenticate encrypt arbitrary message content draft-ietf-smime-rfc2630bis-08 RFC2630 RFC3211 RFC3852 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3369 10.17487/RFC3369 RFC3370 Cryptographic Message Syntax (CMS) Algorithms R. Housley August 2002 ASCII HTML 24 CMS Cryptographic Message Syntax algorithms digitally sign authenticate encrypt arbitrary message content draft-ietf-smime-cmsalg-08 RFC2630 RFC3211 RFC5754 RFC8702 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3370 10.17487/RFC3370 RFC3371 Layer Two Tunneling Protocol "L2TP" Management Information Base E. Caves P. Calhoun R. Wheeler August 2002 ASCII HTML 70 L2TP Layer Two Tunneling Protocol MIB Management Information Base draft-ietf-l2tpext-l2tp-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3371 RFC3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures A. Vemuri J. Peterson September 2002 ASCII HTML 23 pstn public switch telephone network draft-ietf-sipping-sipt-04 BCP0063 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3372 10.17487/RFC3372 RFC3373 Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies D. Katz R. Saluja September 2002 ASCII HTML 9 links handshake draft-ietf-isis-3way-06 RFC5303 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3373 RFC3374 Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network J. Kempf Editor September 2002 ASCII HTML 14 aaa qos authentication authorization accounting quality of service header compression draft-ietf-seamoby-context-transfer-problem-stat-04 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3374 RFC3375 Generic Registry-Registrar Protocol Requirements S. Hollenbeck September 2002 ASCII HTML 21 rrp client server domain names draft-ietf-provreg-grrp-reqs-06 INFORMATIONAL INFORMATIONAL IETF app provreg 10.17487/RFC3375 RFC3376 Internet Group Management Protocol, Version 3 B. Cain S. Deering I. Kouvelas B. Fenner A. Thyagarajan October 2002 ASCII HTML 53 IGMP Internet Group Management Protocol multicast routing IP Internet Protocol draft-ietf-idmr-igmp-v3-11 RFC2236 RFC4604 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr http://www.rfc-editor.org/errata_search.php?rfc=3376 10.17487/RFC3376 RFC3377 Lightweight Directory Access Protocol (v3): Technical Specification J. Hodges R. Morgan September 2002 ASCII HTML 6 ldap ldapv3 draft-ietf-ldapbis-ldapv3-ts-01 RFC4510 RFC2251 RFC2252 RFC2253 RFC2254 RFC2255 RFC2256 RFC2829 RFC2830 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=3377 10.17487/RFC3377 RFC3378 EtherIP: Tunneling Ethernet Frames in IP Datagrams R. Housley S. Hollenbeck September 2002 ASCII HTML 9 internet protocol ip 97 draft-housley-etherip-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3378 RFC3379 Delegated Path Validation and Delegated Path Discovery Protocol Requirements D. Pinkas R. Housley September 2002 ASCII HTML 15 dpv Delegated Path Validation dpd Delegated Path Discovery public key certificates draft-ietf-pkix-dpv-dpd-req-05 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC3379 RFC3380 Internet Printing Protocol (IPP): Job and Printer Set Operations T. Hastings R. Herriot C. Kugler H. Lewis September 2002 ASCII HTML 59 IPP-E-T Internet Printing Protocol application media type draft-ietf-ipp-job-printer-set-ops-05 RFC2910 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3380 10.17487/RFC3380 RFC3381 Internet Printing Protocol (IPP): Job Progress Attributes T. Hastings H. Lewis R. Bergman September 2002 ASCII HTML 17 IPP-E-T Internet Printing Protocol application media type draft-ietf-ipp-job-prog-02 RFC8011 RFC2910 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3381 10.17487/RFC3381 RFC3382 Internet Printing Protocol (IPP): The 'collection' attribute syntax R. deBry T. Hastings R. Herriot K. Ocke P. Zehler September 2002 ASCII HTML 38 IPP-E-T Internet Printing Protocol application media type draft-ietf-ipp-collection-05 RFC8010 RFC8011 RFC2910 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3382 10.17487/RFC3382 RFC3383 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) K. Zeilenga September 2002 ASCII HTML 23 guidelines extensible values draft-ietf-ldapbis-iana-09 RFC4520 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ldapbis 10.17487/RFC3383 RFC3384 Lightweight Directory Access Protocol (version 3) Replication Requirements E. Stokes R. Weiser R. Moats R. Huber October 2002 ASCII HTML 31 ldapv3 data interoperability synchronization multi-master draft-ietf-ldup-replica-req-12 INFORMATIONAL INFORMATIONAL IETF app ldup 10.17487/RFC3384 RFC3385 Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations D. Sheinwald J. Satran P. Thaler V. Cavanna September 2002 ASCII HTML 23 error detection code draft-sheinwald-iscsi-crc-02 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3385 10.17487/RFC3385 RFC3386 Network Hierarchy and Multilayer Survivability W. Lai Editor D. McDysan Editor November 2002 ASCII HTML 27 service provider packet networks protection restoration recovery draft-ietf-tewg-restore-hierarchy-01 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC3386 RFC3387 Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network M. Eder H. Chaskar S. Nag September 2002 ASCII HTML 19 internet protocol packts fuel-service draft-irtf-smrg-ipsmf-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3387 RFC3388 Grouping of Media Lines in the Session Description Protocol (SDP) G. Camarillo G. Eriksson J. Holler H. Schulzrinne December 2002 ASCII HTML 11 SDP Session Description Protocol formats attribute port host interfaces fid flow identification lip synchronization ls draft-ietf-mmusic-fid-06 RFC5888 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC3388 RFC3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN) R. Zopf September 2002 ASCII HTML 8 RTP Real-time Transport Protocol CN Comfort Noise codecs audio multimedia draft-ietf-avt-rtp-cn-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3389 10.17487/RFC3389 RFC3390 Increasing TCP's Initial Window M. Allman S. Floyd C. Partridge October 2002 ASCII HTML 15 TCP transmission control protocol draft-ietf-tsvwg-initwin-04 RFC2414 RFC2581 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3390 10.17487/RFC3390 RFC3391 The MIME Application/Vnd.pwg-multiplexed Content-Type R. Herriot December 2002 ASCII HTML 25 multipurpose internet mail extensions media type draft-herriot-application-multiplexed-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3391 RFC3392 Capabilities Advertisement with BGP-4 R. Chandra J. Scudder November 2002 ASCII HTML 6 BGP border gateway protocol draft-ietf-idr-rfc2842bis-02 RFC2842 RFC5492 DRAFT STANDARD DRAFT STANDARD IETF rtg idr 10.17487/RFC3392 RFC3393 IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) C. Demichelis P. Chimento November 2002 ASCII HTML 21 IPPM IP Performance Metrics internet protocol ipdv IP Packet Delay Variation draft-ietf-ippm-ipdv-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=3393 10.17487/RFC3393 RFC3394 Advanced Encryption Standard (AES) Key Wrap Algorithm J. Schaad R. Housley September 2002 ASCII HTML 41 security draft-ietf-smime-aes-keywrap-00 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3394 10.17487/RFC3394 RFC3395 Remote Network Monitoring MIB Protocol Identifier Reference Extensions A. Bierman C. Bucci R. Dietz A. Warth September 2002 ASCII HTML 21 RMON-MIB Remote Network Monitoring management information base draft-ietf-rmonmib-appverbs-04 RFC2895 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3395 RFC3396 Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) T. Lemon S. Cheshire November 2002 ASCII HTML 9 DHCPv4 Dynamic Host Configuration Protocol octet packet code draft-ietf-dhc-concat-05 RFC2131 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3396 RFC3397 Dynamic Host Configuration Protocol (DHCP) Domain Search Option B. Aboba S. Cheshire November 2002 ASCII HTML 8 DHCP Dynamic Host Configuration Protocol dns Domain Name System client server draft-aboba-dhc-domsearch-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3397 RFC3398 Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping G. Camarillo A. B. Roach J. Peterson L. Ong December 2002 ASCII HTML 68 ISDN Integrated Services Digital Network ISUP User Part signaling system no. 7 ss7 pstn public switched telephone network SIP Session Initiation Protocol draft-ietf-sipping-isup-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3398 10.17487/RFC3398 RFC3399 RFC3400 RFC3401 Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS M. Mealling October 2002 ASCII HTML 6 NAPTR domain name system RR

This document specifies the exact documents that make up the complete Dynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC 2168 and RFC 2915, as well as updates RFC 2276. This memo provides information for the Internet community.

 draft-ietf-urn-ddds-toc-03 RFC2915 RFC2168 RFC2276 INFORMATIONAL INFORMATIONAL IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3401 10.17487/RFC3401 RFC3402 Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm M. Mealling October 2002 ASCII HTML 17 NAPTR DNS domain name system RR Resource Record

This document describes the Dynamic Delegation Discovery System (DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This document is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]

 draft-ietf-urn-ddds-07 RFC2915 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3402 10.17487/RFC3402 RFC3403 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database M. Mealling October 2002 ASCII HTML 14 NAPTR DNS domain name system RR Resource Record

This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR). Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]

 draft-ietf-urn-dns-ddds-database-09 RFC2915 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3403 10.17487/RFC3403 RFC3404 Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) M. Mealling October 2002 ASCII HTML 18 NAPTR DNS domain name system RR Resource Record

This document describes a specification for taking Uniform Resource Identifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document is part of a series that is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]

 draft-ietf-urn-uri-res-ddds-07 RFC2915 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3404 10.17487/RFC3404 RFC3405 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures M. Mealling October 2002 ASCII HTML 10 uniform resource identifiers

This document is fifth in a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-urn-net-procedures-11 RFC8958 BCP0065 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3405 10.17487/RFC3405 RFC3406 Uniform Resource Names (URN) Namespace Definition Mechanisms L. Daigle D. van Gulik R. Iannella P. Faltstrom October 2002 ASCII HTML 22 namespaces applications structure

This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications in RFC 3401 and RFC 3405. The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-urn-rfc2611bis-04 RFC2611 RFC8141 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3406 10.17487/RFC3406 RFC3407 Session Description Protocol (SDP) Simple Capability Declaration F. Andreasen October 2002 ASCII HTML 10 SDPng Session Description Protocol

This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document. This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng. [STANDARDS-TRACK]

 draft-andreasen-mmusic-sdp-simcap-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3407 10.17487/RFC3407 RFC3408 Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile Z. Liu K. Le December 2002 ASCII HTML 7 ROHC RObust Header Compression single-octet packet size

This document defines an additional mode of the link-layer assisted RObust Header Compression (ROHC) profile, also known as the zero-byte profile, beyond the two defined in RFC 3242. Zero-byte header compression exists in order to prevent the single-octet ROHC header from pushing a packet voice stream into the next higher fixed packet size for the radio. It is usable in certain widely deployed older air interfaces. This document adds the zero-byte operation for ROHC Bidirectional Reliable mode (R-mode) to the ones specified for Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242. [STANDARDS-TRACK]

 draft-ietf-rohc-rtp-lla-r-mode-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3408 RFC3409 Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression K. Svanbro December 2002 ASCII HTML 11 rohc algorithms

This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers. The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified by Third Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2), European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP and UDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document. This memo provides information for the Internet community.

 draft-ietf-rohc-rtp-lower-layer-guidelines-03 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3409 RFC3410 Introduction and Applicability Statements for Internet-Standard Management Framework J. Case R. Mundy D. Partain B. Stewart December 2002 ASCII HTML 27 snmp simple protocol snmpv3

The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2). The architecture is designed to be modular to allow the evolution of the Framework over time. The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570. This memo provides information for the Internet community.

 draft-ietf-snmpv3-rfc2570bis-03 RFC2570 INFORMATIONAL INFORMATIONAL IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3410 10.17487/RFC3410 RFC3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks D. Harrington R. Presuhn B. Wijnen December 2002 ASCII HTML 64 ARCH-SNMP Architecture simple network management protocol

This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. [STANDARDS-TRACK]

 draft-ietf-snmpv3-arch-v2-02 RFC2571 RFC5343 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 10.17487/RFC3411 RFC3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen December 2002 ASCII HTML 43 MPD-SNMP Message Processing and Dispatching Simple Network Management Protocol processing models multiple

This document describes the Message Processing and Dispatching for Simple Network Management Protocol (SNMP) messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. This document obsoletes RFC 2572. [STANDARDS-TRACK]

 draft-ietf-snmpv3-mpd-v2-02 RFC2572 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3412 10.17487/RFC3412 RFC3413 Simple Network Management Protocol (SNMP) Applications D. Levi P. Meyer B. Stewart December 2002 ASCII HTML 74 SNMP-APP simple network management protocol applications proxy operations command

This document describes five types of Simple Network Management Protocol (SNMP) applications which make use of an SNMP engine as described in STD 62, RFC 3411. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This document also defines Management Information Base (MIB) modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. This document obsoletes RFC 2573. [STANDARDS-TRACK]

 draft-ietf-snmpv3-appl-v3-01 RFC2573 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3413 10.17487/RFC3413 RFC3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen December 2002 ASCII HTML 88 USM-SNMPV3 User-based Security Model Simple Network Management Protocol message level mib management information base

This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574. [STANDARDS-TRACK]

 draft-ietf-snmpv3-usm-v2-rfc2574bis-01 RFC2574 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3414 10.17487/RFC3414 RFC3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie December 2002 ASCII HTML 39 VACM-SNMP View-based Access Control Model Simple Network Management Protocol mib management information base

This document describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture. It defines the Elements of Procedure for controlling access to management information. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for the View- based Access Control Model. This document obsoletes RFC 2575. [STANDARDS-TRACK]

 draft-ietf-snmpv3-vacm-v2-01 RFC2575 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3415 10.17487/RFC3415 RFC3416 Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) R. Presuhn Editor December 2002 ASCII HTML 31 OPS-MIB SNMP Simple Network Management Protocol Version 2 Management Information Base operations

This document defines version 2 of the protocol operations for the Simple Network Management Protocol (SNMP). It defines the syntax and elements of procedure for sending, receiving, and processing SNMP PDUs. This document obsoletes RFC 1905. [STANDARDS-TRACK]

 draft-ietf-snmpv3-update-proto-08 RFC1905 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3416 10.17487/RFC3416 RFC3417 Transport Mappings for the Simple Network Management Protocol (SNMP) R. Presuhn Editor December 2002 ASCII HTML 19 TRANS-MIB Transport SNMP Simple Network Management Protocol Version 2 Management Information Base

This document defines the transport of Simple Network Management Protocol (SNMP) messages over various protocols. This document obsoletes RFC 1906. [STANDARDS-TRACK]

 draft-ietf-snmpv3-update-transmap-08 RFC1906 RFC4789 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 10.17487/RFC3417 RFC3418 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) R. Presuhn Editor December 2002 ASCII HTML 26 SNMPv2-MIB Simple Network Management Protocol Version 2 Management Information Base

This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [STANDARDS-TRACK]

 draft-ietf-snmpv3-update-mib-07 RFC1907 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3418 10.17487/RFC3418 RFC3419 Textual Conventions for Transport Addresses M. Daniele J. Schoenwaelder December 2002 ASCII HTML 18 mib management information base

This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6. [STANDARDS-TRACK]

 draft-ietf-ops-taddress-mib-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3419 RFC3420 Internet Media Type message/sipfrag R. Sparks November 2002 ASCII HTML 8 mime multipurpose internet mail extensions

This document registers the message/sipfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed Session Initiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request. [STANDARDS-TRACK]

 draft-ietf-sip-sipfrag-00 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3420 10.17487/RFC3420 RFC3421 Select and Sort Extensions for the Service Location Protocol (SLP) W. Zhao H. Schulzrinne E. Guttman C. Bisdikian W. Jerome November 2002 ASCII HTML 8 SLP Service Location Protocol UA user agent URL Uniform Resource Locator service reply svrrply

This document defines two extensions (Select and Sort) for the Service Location Protocol (SLP). These extensions allow a User Agent (UA) to request that the Uniform Resource Locator (URL) entries in a Service Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list. Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load. This memo defines an Experimental Protocol for the Internet community.

 draft-zhao-slp-customization-05 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3421 RFC3422 Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS) O. Okamoto M. Maruyama T. Sajima November 2002 ASCII HTML 19 tunneling ethernet frames

This memo describes a method for forwarding media access control (MAC) frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS), thus providing a way to unify MAPOS network environment and MAC-based Local Area Network (LAN) environment. This memo provides information for the Internet community.

 draft-okamoto-mac-over-mapos-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3422 RFC3423 XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0 K. Zhang E. Elkin November 2002 ASCII HTML 45 data delivery message format template-based client/server

This document defines the Common Reliable Accounting for Network Element (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems (BSS)/ Operations Support Systems (OSS). The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources. This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations. This memo provides information for the Internet community.

 draft-kzhang-crane-protocol-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3423 RFC3424 IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation L. Daigle Editor IAB November 2002 ASCII HTML 9 nat middleboxes

As a result of the nature of Network Address Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-Address Fixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g., to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal. This memo provides information for the Internet community.

 draft-iab-unsaf-considerations-02 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=3424 10.17487/RFC3424 RFC3425 Obsoleting IQUERY D. Lawrence November 2002 ASCII HTML 5 dns lookups domain name system

The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete. This document updates RFC 1035. [STANDARDS-TRACK]

 draft-ietf-dnsext-obsolete-iquery-04 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3425 RFC3426 General Architectural and Policy Considerations S. Floyd November 2002 ASCII HTML 23 internet architecture

This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols. We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed. This memo provides information for the Internet community.

 draft-iab-considerations-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3426 RFC3427 Change Process for the Session Initiation Protocol (SIP) A. Mankin S. Bradner R. Mahy D. Willis J. Ott B. Rosen December 2002 ASCII HTML 12 sipping

This memo documents a process intended to apply architectural discipline to the future development of the Session Initiation Protocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-tsvarea-sipchange-03 RFC5727 RFC3968 RFC3969 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3427 RFC3428 Session Initiation Protocol (SIP) Extension for Instant Messaging B. Campbell Editor J. Rosenberg H. Schulzrinne C. Huitema D. Gurle December 2002 ASCII HTML 18 SIP Session Initiation Protocol IM Instant Messaging message method

Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. [STANDARDS-TRACK]

 draft-ietf-sip-message-07 RFC8591 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3428 10.17487/RFC3428 RFC3429 Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions H. Ohta November 2002 ASCII HTML 6 reserved lavel values

This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the 'Operation and Maintenance (OAM) Alert Label' that is used by user-plane Multiprotocol Label Switching Architecture (MPLS) OAM functions for identification of MPLS OAM packets. This memo provides information for the Internet community.

 draft-ohta-mpls-label-value-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3429 RFC3430 Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping J. Schoenwaelder December 2002 ASCII HTML 10 SNMP Simple Network Management Protocol TCP Transmission Control Protocol

This memo defines a transport mapping for using the Simple Network Management Protocol (SNMP) over TCP. The transport mapping can be used with any version of SNMP. This document extends the transport mappings defined in STD 62, RFC 3417. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-nmrg-snmp-tcp-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3430 RFC3431 Sieve Extension: Relational Tests W. Segmuller December 2002 ASCII HTML 8 sieve mail filtering language

This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. [STANDARDS-TRACK]

 draft-segmuller-sieve-relation-02 RFC5231 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3431 RFC3432 Network performance measurement with periodic streams V. Raisanen G. Grotefeld A. Morton November 2002 ASCII HTML 23 cbr constant bit rate periodic sampling poisson sampling

This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations. [STANDARDS-TRACK]

 draft-ietf-ippm-npmps-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC3432 RFC3433 Entity Sensor Management Information Base A. Bierman D. Romascanu K.C. Norseth December 2002 ASCII HTML 17 MIB Management Information Base physical sensors SNMP Simple Network Management Protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the Entity MIB (RFC 2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment (such as chassis temperature, fan RPM, power supply voltage). [STANDARDS-TRACK]

 draft-ietf-entmib-sensor-mib-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=3433 10.17487/RFC3433 RFC3434 Remote Monitoring MIB Extensions for High Capacity Alarms A. Bierman K. McCloghrie December 2002 ASCII HTML 24 RMON Remote Monitoring MIB Management Information Base counter64 smiv2 Structure of Management Information Version 2 SNMP Simple Network Management Protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the alarm thresholding capabilities found in the Remote Monitoring (RMON) MIB (RFC 2819), to provide similar threshold monitoring of objects based on the Counter64 data type. [STANDARDS-TRACK]

 draft-ietf-rmonmib-hc-alarm-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3434 RFC3435 Media Gateway Control Protocol (MGCP) Version 1.0 F. Andreasen B. Foster January 2003 ASCII HTML 210 voice IP internet VoIP

This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control "intelligence", and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP. Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals. The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints. The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways. Such packages are defined in separate documents. This memo provides information for the Internet community.

 draft-andreasen-mgcp-rfc2705bis-05 RFC2705 RFC3661 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3435 10.17487/RFC3435 RFC3436 Transport Layer Security over Stream Control Transmission Protocol A. Jungmaier E. Rescorla M. Tuexen December 2002 ASCII HTML 9 SCTP Stream Control Transmission Protocol TLS Transport Layer Security

This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309. The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance. Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses. [STANDARDS-TRACK]

 draft-ietf-tsvwg-tls-over-sctp-00 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3436 RFC3437 Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation W. Palter W. Townsley December 2002 ASCII HTML 10 L2TP Layer-Two Tunneling Protocol LCP Link Control Protocol

This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for enhanced support of link-specific Point to Point Protocol (PPP) options. PPP endpoints typically have direct access to the common physical media connecting them and thus have detailed knowledge about the media that is in use. When the L2TP is used, the two PPP peers are no longer directly connected over the same physical media. Instead, L2TP inserts a virtual connection over some or all of the PPP connection by tunneling PPP frames over a packet switched network such as IP. Under some conditions, an L2TP endpoint may need to negotiate PPP Link Control Protocol (LCP) options at a location which may not have access to all of the media information necessary for proper participation in the LCP negotiation. This document provides a mechanism for communicating desired LCP options between L2TP endpoints in advance of PPP LCP negotiation at the far end of an L2TP tunnel, as well as a mechanism for communicating the negotiated LCP options back to where the native PPP link resides. [STANDARDS-TRACK]

 draft-ietf-l2tpext-link-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3437 RFC3438 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update W. Townsley December 2002 ASCII HTML 5 L2TP ppp point-to-point protocol packets

This document describes updates to the Internet Assigned Numbers Authority (IANA) considerations for the Layer Two Tunneling Protocol (L2TP). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-l2tpext-rfc2661-iana-01 BCP0068 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int l2tpext 10.17487/RFC3438 RFC3439 Some Internet Architectural Guidelines and Philosophy R. Bush D. Meyer December 2002 ASCII HTML 28 IAB

This document extends RFC 1958 by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere. We describe the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling, and discuss its implications on the architecture, design and engineering issues found in large scale Internet backbones. This memo provides information for the Internet community.

 draft-ymbk-arch-guidelines-03 RFC1958 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3439 10.17487/RFC3439 RFC3440 Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines F. Ly G. Bathrick December 2002 ASCII HTML 36 SNMP simple network management protocol MIB Management Information Base ADSL asymmetric digital subscriber line

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects used for managing Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the ADSL Line MIB (RFC 2662). [STANDARDS-TRACK]

 draft-ietf-adslmib-adslext-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC3440 RFC3441 Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP) R. Kumar January 2003 ASCII HTML 50 connection codec profile

This document describes an Asynchronous Transfer Mode (ATM) package for the Media Gateway Control Protocol (MGCP). This package includes new Local Connection Options, ATM-specific events and signals, and ATM connection parameters. Also included is a description of codec and profile negotiation. It extends the MGCP that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, which are currently working on a potential successor to this protocol. This memo provides information for the Internet community.

 draft-rajeshkumar-mgcp-atm-package-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3441 RFC3442 The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 T. Lemon S. Cheshire B. Volz December 2002 ASCII HTML 9 DHCP Dynamic Host Configuration Protocol Bootstrap

This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask. [STANDARDS-TRACK]

 draft-ietf-dhc-csr-07 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3442 RFC3443 Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks P. Agarwal B. Akyol January 2003 ASCII HTML 10 TTL Time To Live label stack encoding uniform model pipe model MPLS Multi-Protocol Label Switching

This document describes Time To Live (TTL) processing in hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label Stack Encoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and "pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. [STANDARDS-TRACK]

 draft-ietf-mpls-ttl-04 RFC3032 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3443 RFC3444 On the Difference between Information Models and Data Models A. Pras J. Schoenwaelder January 2003 ASCII HTML 8 network management

There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community.

 draft-irtf-nmrg-im-dm-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3444 RFC3445 Limiting the Scope of the KEY Resource Record (RR) D. Massey S. Rose December 2002 ASCII HTML 10 DNS-SECEXT dns authentication

This document limits the Domain Name System (DNS) KEY Resource Record (RR) to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. [STANDARDS-TRACK]

 draft-ietf-dnsext-restrict-key-for-dnssec-04 RFC4033 RFC4034 RFC4035 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3445 10.17487/RFC3445 RFC3446 Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) D. Kim D. Meyer H. Kilmer D. Farinacci January 2003 ASCII HTML 7 sparse mode single shared-tree

This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree Protocol Independent Multicast-Sparse Mode (PIM-SM) domain. This memo provides information for the Internet community.

 draft-ietf-mboned-anycast-rp-08 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC3446 RFC3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 J. Jonsson B. Kaliski February 2003 ASCII HTML 72 data public key cryptosystem

This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. This memo provides information for the Internet community.

 draft-jonsson-pkcs1-v2dot1-00 RFC2437 RFC8017 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3447 10.17487/RFC3447 RFC3448 TCP Friendly Rate Control (TFRC): Protocol Specification M. Handley S. Floyd J. Padhye J. Widmer January 2003 ASCII HTML 24 TFRC TCP Friendly Rate Control congestion unicast streaming media

This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. [STANDARDS-TRACK]

 draft-ietf-tsvwg-tfrc-05 RFC5348 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3448 10.17487/RFC3448 RFC3449 TCP Performance Implications of Network Path Asymmetry H. Balakrishnan V. Padmanabhan G. Fairhurst M. Sooriyabandara December 2002 ASCII HTML 41 links sender receiver ack

This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender. The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link- layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self- clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic. Each technique is described, together with known issues, and recommendations for use. A summary of the recommendations is provided at the end of the document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-pilc-asym-08 BCP0069 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3449 RFC3450 Asynchronous Layered Coding (ALC) Protocol Instantiation M. Luby J. Gemmell L. Vicisano L. Rizzo J. Crowcroft December 2002 ASCII HTML 34 content delivery congestion control receivers

This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-pi-alc-08 RFC5775 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3450 RFC3451 Layered Coding Transport (LCT) Building Block M. Luby J. Gemmell L. Vicisano L. Rizzo M. Handley J. Crowcroft December 2002 ASCII HTML 29 LCT Layered Coding Transport content stream delivery multicast internet protocol

Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-bb-lct-04 RFC5651 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3451 RFC3452 Forward Error Correction (FEC) Building Block M. Luby L. Vicisano J. Gemmell L. Rizzo M. Handley J. Crowcroft December 2002 ASCII HTML 16 FEC Forward Error Correction content stream delivery multicast internet protocol

This document generally describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport using IP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry. The procedures for specifying FEC codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward Error Correction (FEC) in Reliable Multicast". This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-bb-fec-07 RFC5052 RFC5445 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3452 RFC3453 The Use of Forward Error Correction (FEC) in Reliable Multicast M. Luby L. Vicisano J. Gemmell L. Rizzo M. Handley J. Crowcroft December 2002 ASCII HTML 18 ip internet protocol data transport

This memo describes the use of Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for one-to-many reliable data transport using IP multicast. One of the key properties of FEC codes in this context is the ability to use the same packets containing FEC data to simultaneously repair different packet loss patterns at multiple receivers. Different classes of FEC codes and some of their basic properties are described and terminology relevant to implementing FEC in a reliable multicast protocol is introduced. Examples are provided of possible abstract formats for packets carrying FEC. This memo provides information for the Internet community.

 draft-ietf-rmt-info-fec-03 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC3453 RFC3454 Preparation of Internationalized Strings ("stringprep") P. Hoffman M. Blanchet December 2002 ASCII HTML 91 unicode text internationalization

This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings. This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. [STANDARDS-TRACK]

 draft-hoffman-stringprep-07 RFC7564 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3454 10.17487/RFC3454 RFC3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) M. Garcia-Martin E. Henrikson D. Mills January 2003 ASCII HTML 34

This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. This memo provides information for the Internet community.

 draft-garcia-sipping-3gpp-p-headers-02 RFC7315 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3455 10.17487/RFC3455 RFC3456 Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode B. Patel B. Aboba S. Kelly V. Gupta January 2003 ASCII HTML 18 DHCPv4 Dynamic Host Configuration Protocol security internet protocol

This memo explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (DHCPv4) may be leveraged for configuration. In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a "virtual" address from the corporate network, and then tunneling traffic via IPsec from the host's ISP-assigned address to the corporate security gateway. In IPv4, DHCP provides for such remote host configuration. [STANDARDS-TRACK]

 draft-ietf-ipsec-dhcp-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsra 10.17487/RFC3456 RFC3457 Requirements for IPsec Remote Access Scenarios S. Kelly S. Ramamoorthi January 2003 ASCII HTML 31 ipsra common remote access scenarios

IPsec offers much promise as a secure remote access mechanism. However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios. This memo provides information for the Internet community.

 draft-ietf-ipsra-reqmts-05 INFORMATIONAL INFORMATIONAL IETF sec ipsra 10.17487/RFC3457 RFC3458 Message Context for Internet Mail E. Burger E. Candell C. Eliot G. Klyne January 2003 ASCII HTML 17 user agent UA

This memo describes a new RFC 2822 message header, "Message-Context". This header provides information about the context and presentation characteristics of a message. A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]

 draft-ietf-vpim-hint-08 RFC3938 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC3458 RFC3459 Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter E. Burger January 2003 ASCII HTML 24 MIME Multi-purpose Internet Mail Extensions body parts content-disposition

This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204. By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward. It can indicate how hard a gateway should try to deliver a body part. It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process. [STANDARDS-TRACK]

 draft-ietf-vpim-cc-08 RFC3204 RFC5621 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC3459 RFC3460 Policy Core Information Model (PCIM) Extensions B. Moore Editor January 2003 ASCII HTML 93 PCIM Policy Core Information Model common schema object-oriented

This document specifies a number of changes to the Policy Core Information Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060. [STANDARDS-TRACK]

 draft-ietf-policy-pcim-ext-08 RFC3060 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3460 RFC3461 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) K. Moore January 2003 ASCII HTML 38 SMTP-DSN Simple Mail Transfer Protocol Delivery Status Notifications

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]

 draft-moore-rfc1891bis-02 RFC1891 RFC3798 RFC3885 RFC5337 RFC6533 RFC8098 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3461 10.17487/RFC3461 RFC3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages G. Vaudreuil January 2003 ASCII HTML 7 MIME-RPT Multipurpose Internet Mail Extensions Report

The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. This document is part of a four document set describing the delivery status report service. This collection includes the Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. [STANDARDS-TRACK]

 draft-vaudreuil-1892bis-02 RFC1892 RFC6522 RFC5337 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC3462 RFC3463 Enhanced Mail System Status Codes G. Vaudreuil January 2003 ASCII HTML 16 EMS-CODE Enhanced Mail System Status Codes simple mail transfer protocol SMTP

This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. [STANDARDS-TRACK]

 draft-vaudreuil-1893bis-03 RFC1893 RFC3886 RFC4468 RFC4865 RFC4954 RFC5248 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3463 10.17487/RFC3463 RFC3464 An Extensible Message Format for Delivery Status Notifications K. Moore G. Vaudreuil January 2003 ASCII HTML 40 DSN Delivery Status Notifications MIME Multipurpose Internet Mail Extensions Content Type

This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Local Area Network (LAN)-based" systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail. [STANDARDS-TRACK]

 draft-vaudreuil-1894bis-02 RFC1894 RFC4865 RFC5337 RFC6533 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3464 10.17487/RFC3464 RFC3465 TCP Congestion Control with Appropriate Byte Counting (ABC) M. Allman February 2003 ASCII HTML 10 TCP transmission control protocol security performance ABC Appropriate Byte Counting

This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly. This memo defines an Experimental Protocol for the Internet community.

 draft-allman-tcp-abc-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3465 RFC3466 A Model for Content Internetworking (CDI) M. Day B. Cain G. Tomlinson P. Rzewski February 2003 ASCII HTML 17 distribution peering

Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called "content peering" or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary. This memo provides information for the Internet community.

 draft-ietf-cdi-model-02 RFC7336 INFORMATIONAL INFORMATIONAL IETF app cdi 10.17487/RFC3466 RFC3467 Role of the Domain Name System (DNS) J. Klensin February 2003 ASCII HTML 31 history internationalization unicode ascii multilingual names

This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them. This memo provides information for the Internet community.

 draft-klensin-dns-role-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3467 RFC3468 The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols L. Andersson G. Swallow February 2003 ASCII HTML 11 rsvp-te ldp resource reservation protocol label distribution

This document documents the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label- Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to "Constraint-Based LSP Setup using Label Distribution Protocol (LDP)" (RFC 3212). The recommendations of section 6 have been accepted by the IESG. This memo provides information for the Internet community.

 draft-andersson-mpls-sig-decision-03 RFC3212 RFC3472 RFC3475 RFC3476 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3468 10.17487/RFC3468 RFC3469 Framework for Multi-Protocol Label Switching (MPLS)-based Recovery V. Sharma Editor F. Hellstrand Editor February 2003 ASCII HTML 40 routing traffic

Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework. This memo provides information for the Internet community.

 draft-ietf-mpls-recovery-frmwrk-08 RFC5462 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3469 RFC3470 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols S. Hollenbeck M. Rose L. Masinter January 2003 ASCII HTML 28 data documents structure

The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data. There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-hollenbeck-ietf-xml-guidelines-07 RFC8996 BCP0070 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3470 10.17487/RFC3470 RFC3471 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description L. Berger Editor January 2003 ASCII HTML 34 GMPLS Generalized Multi-Protocol Label Switching SONET/SDH Synchronous Optical Network Synchronous Digital Hierarchy

This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS-TRACK]

 draft-ietf-mpls-generalized-signaling-09 RFC4201 RFC4328 RFC4872 RFC6002 RFC6003 RFC6205 RFC7074 RFC7699 RFC8359 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=3471 10.17487/RFC3471 RFC3472 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions P. Ashwood-Smith Editor L. Berger Editor January 2003 ASCII HTML 23 GMPLS Generalized Multi-Protocol Label Switching SONET/SDH Synchronous Optical Network Synchronous Digital Hierarchy CR-LDP Constraint-based Routed Label Distribution Protocol

This document describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]

 draft-ietf-mpls-generalized-cr-ldp-07 RFC3468 RFC4201 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC3472 RFC3473 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions L. Berger Editor January 2003 ASCII HTML 42 GMPLS Generalized Multi-Protocol Label Switching SONET/SDH Synchronous Optical Network Synchronous Digital Hierarchy RSVP-TE Resource ReserVation Protocol Traffic Engineering

This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]

 draft-ietf-mpls-generalized-rsvp-te-09 RFC4003 RFC4201 RFC4420 RFC4783 RFC4874 RFC4873 RFC4974 RFC5063 RFC5151 RFC5420 RFC6002 RFC6003 RFC6780 RFC8359 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=3473 10.17487/RFC3473 RFC3474 Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON) Z. Lin D. Pendarakis March 2003 ASCII HTML 25 sonet sdh

The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using Resource Reservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network. This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T Study Group 15 in support of ITU's ASON standardization effort. This memo provides information for the Internet community.

 draft-lin-ccamp-gmpls-ason-rsvpte-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3474 10.17487/RFC3474 RFC3475 Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON) O. Aboul-Magd March 2003 ASCII HTML 13 label switching protocol itu-t

Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks. The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities. Signaling over interfaces defined in those reference points can make use of protocols that are defined by the IETF in the context of Generalized Multi-Protocol Label Switching (GMPLS) work. This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points. The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions. The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents. This memo provides information for the Internet community.

 draft-aboulmagd-ccamp-crldp-ason-ext-02 RFC3468 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3475 RFC3476 Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling B. Rajagopalan March 2003 ASCII HTML 11 oif optical interworking forum uni user network interface

The Optical Interworking Forum (OIF) has defined extensions to the Label Distribution Protocol (LDP) and the Resource ReSerVation Protocol (RSVP) for optical User Network Interface (UNI) signaling. These extensions consist of a set of new data objects and error codes. This document describes these extensions. This memo provides information for the Internet community.

 draft-bala-uni-ldp-rsvp-extensions-04 RFC3468 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3476 RFC3477 Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) K. Kompella Y. Rekhter January 2003 ASCII HTML 9 MPLS-TE Multi-Protocol Label Switching Traffic Engineering RSVP Resource ReSerVation Protocol

Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. [STANDARDS-TRACK]

 draft-ietf-mpls-rsvp-unnum-08 RFC6107 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3477 RFC3478 Graceful Restart Mechanism for Label Distribution Protocol M. Leelanivas Y. Rekhter R. Aggarwal February 2003 ASCII HTML 12 LDP Label Distribution Protocol MPLS Multi-Protocol Label Switching

This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart. The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-restart-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3478 RFC3479 Fault Tolerance for the Label Distribution Protocol (LDP) A. Farrel Editor February 2003 ASCII HTML 52 MPLS multiprotocol label switching LDP Label Distribution Protocol high availability restart

Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDP Specification", that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations. The issues and extensions described here are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP). [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-ft-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3479 RFC3480 Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) K. Kompella Y. Rekhter A. Kullberg February 2003 ASCII HTML 8 mpls multiprotocol label switching traffic engineering mpls-te Traffic Engineering CR-LDP Constraint-Routing Label Distribution Protocol

Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links. [STANDARDS-TRACK]

 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3480 RFC3481 TCP over Second (2.5G) and Third (3G) Generation Wireless Networks H. Inamura Editor G. Montenegro Editor R. Ludwig A. Gurtov F. Khafizov February 2003 ASCII HTML 26 paths algorithm stacks

This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-pilc-2.5g3g-12 BCP0071 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3481 RFC3482 Number Portability in the Global Switched Telephone Network (GSTN): An Overview M. Foster T. McGarry J. Yu February 2003 ASCII HTML 30 e.164 telephony routing

This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF. This memo provides information for the Internet community.

 draft-ietf-enum-e164-gstn-np-05 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC3482 RFC3483 Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR) D. Rawlins A. Kulkarni M. Bokaemper K. Chan March 2003 ASCII HTML 10 accounting policy decision point bdp

Common Open Policy Services (COPS) Protocol (RFC 2748), defines the capability of reporting information to the Policy Decision Point (PDP). The types of report information are success, failure and accounting of an installed state. This document focuses on the COPS Report Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state. This memo provides information for the Internet community.

 draft-ietf-rap-feedback-frwk-04 INFORMATIONAL INFORMATIONAL IETF ops rap 10.17487/RFC3483 RFC3484 Default Address Selection for Internet Protocol version 6 (IPv6) R. Draves February 2003 ASCII HTML 24 IPv6 source address destination

This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. [STANDARDS-TRACK]

 draft-ietf-ipv6-default-addr-select-09 RFC6724 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3484 RFC3485 The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp) M. Garcia-Martin C. Bormann J. Ott R. Price A. B. Roach February 2003 ASCII HTML 30 SIP Session Initiation Protocol SDP Session Description Protocol SigComp Static Dictionary for Signaling Compression algorithm

The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. [STANDARDS-TRACK]

 draft-ietf-sipping-sigcomp-sip-dictionary-05 RFC4896 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC3485 RFC3486 Compressing the Session Initiation Protocol (SIP) G. Camarillo February 2003 ASCII HTML 12 SIP Session Initiation Protocol

This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. [STANDARDS-TRACK]

 draft-ietf-sip-compression-02 RFC5049 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3486 RFC3487 Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) H. Schulzrinne February 2003 ASCII HTML 17 circuit switched network resources end system resources proxy resources emergency preparedness communications

This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). This memo provides information for the Internet community.

 draft-ietf-ieprep-sip-reqs-03 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3487 RFC3488 Cisco Systems Router-port Group Management Protocol (RGMP) I. Wu T. Eckert February 2003 ASCII HTML 17 multicast switches packet

This document describes the Router-port Group Management Protocol (RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed. RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected. This memo provides information for the Internet community.

 draft-wu-rgmp-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3488 RFC3489 STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) J. Rosenberg J. Weinberger C. Huitema R. Mahy March 2003 ASCII HTML 47 STUN Simple Traversal of User Datagram Protocol UDP NATs Network Address Translators lightweight applications firewalls

Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. [STANDARDS-TRACK]

 draft-ietf-midcom-stun-05 RFC5389 PROPOSED STANDARD PROPOSED STANDARD IETF tsv midcom 10.17487/RFC3489 RFC3490 Internationalizing Domain Names in Applications (IDNA) P. Faltstrom P. Hoffman A. Costello March 2003 ASCII HTML 22 IDNs Internationalized Domain Names ascii characters

Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]

 draft-ietf-idn-idna-14 RFC5890 RFC5891 PROPOSED STANDARD PROPOSED STANDARD IETF int idn http://www.rfc-editor.org/errata_search.php?rfc=3490 10.17487/RFC3490 RFC3491 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) P. Hoffman M. Blanchet March 2003 ASCII HTML 7 IDN Internationalized Domain Name applications

This document describes how to prepare internationalized domain name (IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). [STANDARDS-TRACK]

 draft-ietf-idn-nameprep-11 RFC5891 PROPOSED STANDARD PROPOSED STANDARD IETF int idn 10.17487/RFC3491 RFC3492 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) A. Costello March 2003 ASCII HTML 35 IDNA Internationalized Domain Names in Applications syntax string host label

Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS-TRACK]

 draft-ietf-idn-punycode-03 RFC5891 PROPOSED STANDARD PROPOSED STANDARD IETF int idn http://www.rfc-editor.org/errata_search.php?rfc=3492 10.17487/RFC3492 RFC3493 Basic Socket Interface Extensions for IPv6 R. Gilligan S. Thomson J. Bound J. McCann W. Stevens February 2003 ASCII HTML 39 internet protocol api application program interface tcp transmission control

The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community.

 RFC2553 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3493 RFC3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status K. Zeilenga March 2003 ASCII HTML 5 DAP interactive access X.500 LDAP lightweight directory protocol STR-REP directory names representing names

This document recommends the retirement of version 2 of the Lightweight Directory Access Protocol (LDAPv2) and other dependent specifications, and discusses the reasons for doing so. This document recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded) be moved to Historic status. This memo provides information for the Internet community.

 draft-zeilenga-ldapv2-04 RFC1484 RFC1485 RFC1487 RFC1777 RFC1778 RFC1779 RFC1781 RFC2559 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3494 10.17487/RFC3494 RFC3495 Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration B. Beser P. Duffy Editor March 2003 ASCII HTML 13 DHCP Dynamic Host Configuration Protocol packetcable MTA Media Terminal Adapter

This document defines a Dynamic Host Configuration Protocol (DHCP) option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. [STANDARDS-TRACK]

 draft-ietf-dhc-packetcable-06 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3495 10.17487/RFC3495 RFC3496 Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering A. G. Malis T. Hsiao March 2003 ASCII HTML 6 diff-serv diffserv rsvp-te resource reservation protocol

This document specifies a Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) signaling extension for support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering. This memo provides information for the Internet community.

 draft-malis-diff-te-serviceclass-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3496 RFC3497 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video L. Gharai C. Perkins G. Goncher A. Mankin March 2003 ASCII HTML 12 RTP real-time transport protocol hdtv high definition television SMPTE Society of Motion Picture and Television Engineers

This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport. [STANDARDS-TRACK]

 draft-ietf-avt-smpte292-video-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3497 RFC3498 Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures J. Kuhfeld J. Johnson M. Thatcher March 2003 ASCII HTML 43 MIB management information base tcp/ip transmission control protocol internet protocol Synchronous Optical Network SONET Automatic Protection Switching APS

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Synchronous Optical Network (SONET) linear Automatic Protection Switching (APS) architectures. [STANDARDS-TRACK]

 draft-ietf-atommib-sonetaps-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC3498 RFC3499 Request for Comments Summary RFC Numbers 3400-3499 S. Ginoza December 2003 ASCII HTML 38 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3499 RFC3500 RFC3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 M. Crispin March 2003 ASCII HTML 108 IMAPv4 Internet Message Access Protocol Version 4rev1 imapv4rev1

The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK]

 draft-crispin-imapv-20 RFC2060 RFC9051 RFC4466 RFC4469 RFC4551 RFC5032 RFC5182 RFC5738 RFC6186 RFC6858 RFC7817 RFC8314 RFC8437 RFC8474 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3501 10.17487/RFC3501 RFC3502 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension M. Crispin March 2003 ASCII HTML 7 IMAPv4 imap imapv4rev1

This document describes the multiappending extension to the Internet Message Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of "MULTIAPPEND". [STANDARDS-TRACK]

 draft-crispin-imap-multiappend-07 RFC4466 RFC4469 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3502 RFC3503 Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP) A. Melnikov March 2003 ASCII HTML 9 MUA mail user agent imap4 Internet Message Access Protocol MDN Message Disposition Notification

The Message Disposition Notification (MDN) facility defined in RFC 2298 provides a means by which a message can request that message processing by the recipient be acknowledged as well as a format to be used for such acknowledgements. However, it doesn't describe how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment. This document describes how to handle MDNs in such an environment and provides guidelines for implementers of IMAP4 that want to add MDN support to their products. [STANDARDS-TRACK]

 draft-melnikov-imap-mdn-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3503 RFC3504 Internet Open Trading Protocol (IOTP) Version 1, Errata D. Eastlake March 2003 ASCII HTML 6 commerce payment system merchant system xml extensible markup language security

Since the publication of the RFCs specifying Version 1.0 of the Internet Open Trading Protocol (IOTP), some errors have been noted. This informational document lists these errors and provides corrections for them. This memo provides information for the Internet community.

 draft-ietf-trade-iotp-v1-errata-01 INFORMATIONAL INFORMATIONAL IETF app trade http://www.rfc-editor.org/errata_search.php?rfc=3504 10.17487/RFC3504 RFC3505 Electronic Commerce Modeling Language (ECML): Version 2 Requirements D. Eastlake March 2003 ASCII HTML 8 xml extensible markup language

This document lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 specification. It includes requirements as they relate to Extensible Markup Language (XML) syntax, data model, format, and payment processing. This memo provides information for the Internet community.

 draft-ietf-trade-ecml2-req-05 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3505 RFC3506 Requirements and Design for Voucher Trading System (VTS) K. Fujimura D. Eastlake March 2003 ASCII HTML 15 generic voucher language gvl

Crediting loyalty points and collecting digital coupons or gift certificates are common functions in purchasing and trading transactions. These activities can be generalized using the concept of a "voucher", which is a digital representation of the right to claim goods or services. This document presents a Voucher Trading System (VTS) that circulates vouchers securely and its terminology; it lists design principles and requirements for VTS and the Generic Voucher Language (GVL), with which diverse types of vouchers can be described. This memo provides information for the Internet community.

 draft-ietf-trade-drt-requirements-04 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3506 RFC3507 Internet Content Adaptation Protocol (ICAP) J. Elson A. Cerpa April 2003 ASCII HTML 49 http hyper-text markup protocol request response client server

ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services. ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. It allows ICAP clients to pass HTTP messages to ICAP servers for some sort of transformation or other processing ("adaptation"). The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. Typically, the adapted messages are either HTTP requests or HTTP responses. This memo provides information for the Internet community.

 draft-elson-icap-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3507 10.17487/RFC3507 RFC3508 H.323 Uniform Resource Locator (URL) Scheme Registration O. Levin April 2003 ASCII HTML 6 itu-t packet networks

ITU-T Recommendation H.323 version 4 introduced an H.323-specific Uniform Resource Locator (URL). This document reproduces the H323-URL definition found in H.323, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority (IANA). This memo provides information for the Internet community.

 draft-levin-iptel-h323-url-scheme-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3508 RFC3509 Alternative Implementations of OSPF Area Border Routers A. Zinin A. Lindem D. Yeung April 2003 ASCII HTML 12 traffic backbone

Open Shortest Path First (OSPF) is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers. This memo provides information for the Internet community.

 draft-ietf-ospf-abr-alt-05 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC3509 RFC3510 Internet Printing Protocol/1.1: IPP URL Scheme R. Herriot I. McDonald April 2003 ASCII HTML 16 IPP-E-T Internet Printing Protocol application media type URL Uniform Resource Locator

This memo defines the "ipp" URL (Uniform Resource Locator) scheme. This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910. An "ipp" URL is used to specify the network location of a print service that supports the IPP Protocol (RFC 2910), or of a network resource (for example, a print job) managed by such a print service. [STANDARDS-TRACK]

 draft-ietf-ipp-url-scheme-05 RFC2910 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp 10.17487/RFC3510 RFC3511 Benchmarking Methodology for Firewall Performance B. Hickman D. Newman S. Tadjudin T. Martin April 2003 ASCII HTML 34 client server traffic authentication web caching

This document discusses and defines a number of tests that may be used to describe the performance characteristics of firewalls. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests. This document is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community.

 draft-ietf-bmwg-firewall-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3511 RFC3512 Configuring Networks and Devices with Simple Network Management Protocol (SNMP) M. MacFaden D. Partain J. Saperia W. Tackabury April 2003 ASCII HTML 83 internet standard framework

This document is written for readers interested in the Internet Standard Management Framework and its protocol, the Simple Network Management Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks. This memo provides information for the Internet community.

 draft-ietf-snmpconf-bcp-12 INFORMATIONAL INFORMATIONAL IETF ops snmpconf 10.17487/RFC3512 RFC3513 Internet Protocol Version 6 (IPv6) Addressing Architecture R. Hinden S. Deering April 2003 ASCII HTML 26 internet protocol unicast anycast multicast node

This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. [STANDARDS-TRACK]

 draft-ietf-ipngwg-addr-arch-v3-11 RFC2373 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3513 RFC3514 The Security Flag in the IPv4 Header S. Bellovin April 1 2003 ASCII HTML 6 evil evil bit

Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3514 10.17487/RFC3514 RFC3515 The Session Initiation Protocol (SIP) Refer Method R. Sparks April 2003 ASCII HTML 23 SIP Session Initiation Protocol resource request call transfer

This document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the refer event package and the Refer-To request header. [STANDARDS-TRACK]

 draft-ietf-sip-refer-07 RFC7647 RFC8217 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3515 10.17487/RFC3515 RFC3516 IMAP4 Binary Content Extension L. Nerenberg April 2003 ASCII HTML 8 internet message acess procotol

This memo defines the Binary extension to the Internet Message Access Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content-transfer- encoding. [STANDARDS-TRACK]

 draft-nerenberg-imap-binary-07 RFC4466 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3516 10.17487/RFC3516 RFC3517 A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP E. Blanton M. Allman K. Fall L. Wang April 2003 ASCII HTML 13 TCP transmission control protocol retransmission congestion control

This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. [STANDARDS-TRACK]

 draft-allman-tcp-sack-13 RFC6675 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3517 RFC3518 Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP) M. Higashiyama F. Baker T. Liao April 2003 ASCII HTML 40 PPP-BCP point-to-point protocol Bridging Control Protocol datagrams network

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) and proposes a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring Remote Bridging for PPP links. This document obsoletes RFC 2878, which was based on the IEEE 802.1D- 1993 MAC Bridge. This document extends that specification by improving support for bridge control packets. [STANDARDS-TRACK]

 draft-ietf-pppext-rfc2878bis-01 RFC2878 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3518 RFC3519 Mobile IP Traversal of Network Address Translation (NAT) Devices H. Levkowetz S. Vaarala April 2003 ASCII HTML 34 Internet Protocol datagram traffic Mobile IP NAT NAPT traversal tunnelling tunneling UDP private address space keepalives port 434 MIP MIPv4 network address translation

Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. [STANDARDS-TRACK]

 draft-ietf-mobileip-nat-traversal-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3519 10.17487/RFC3519 RFC3520 Session Authorization Policy Element L-N. Hamer B. Gage B. Kosinski H. Shieh April 2003 ASCII HTML 30 session authorization policy admission control resource reservation

This document describes the representation of a session authorization policy element for supporting policy-based per-session authorization and admission control. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the signaling and transport planes. This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into a resource reservation protocol (e.g., the Resource ReSerVation Protocol (RSVP) PATH message) to facilitate proper and secure reservation of those resources within the network. We describe the encoding of session authorization information as a policy element conforming to the format of a Policy Data object (RFC 2750) and provide details relating to operations, processing rules and error scenarios. [STANDARDS-TRACK]

 draft-ietf-rap-rsvp-authsession-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC3520 RFC3521 Framework for Session Set-up with Media Authorization L-N. Hamer B. Gage H. Shieh April 2003 ASCII HTML 25 qos quality of service streams linkage policy control admission theft service resource reservation token

Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host. To prevent fraud and to ensure accurate billing, this document describes various scenarios and mechanisms that provide the linkage required to verify that the resources being used to provide a requested QoS are in- line with the media streams requested (and authorized) for the session. This memo provides information for the Internet community.

 draft-ietf-rap-session-auth-04 INFORMATIONAL INFORMATIONAL IETF ops rap 10.17487/RFC3521 RFC3522 The Eifel Detection Algorithm for TCP R. Ludwig M. Meyer April 2003 ASCII HTML 14 TCP transmission control protocol loss recovery timestamps

The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tsvwg-tcp-eifel-alg-07 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3522 RFC3523 Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology J. Polk April 2003 ASCII HTML 6 naming convetions phone

This document defines the topology naming conventions that are to be used in reference to Internet Emergency Preparedness (IEPREP) phone calls. These naming conventions should be used to focus the IEPREP Working Group during discussions and when writing requirements, gap analysis and other solutions documents. This memo provides information for the Internet community.

 draft-polk-ieprep-scenarios-03 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3523 RFC3524 Mapping of Media Streams to Resource Reservation Flows G. Camarillo A. Monrad April 2003 ASCII HTML 6 SDP session description protocol SRF single reservation flow

This document defines an extension to the Session Description Protocol (SDP) grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow. The SDP syntax needed is defined, as well as a new "semantics" attribute called Single Reservation Flow (SRF). [STANDARDS-TRACK]

 draft-ietf-mmusic-reservation-flows-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC3524 RFC3525 Gateway Control Protocol Version 1 C. Groves Editor M. Pantaleo Editor T. Anderson Editor T. Taylor Editor June 2003 ASCII HTML 213 MEGACO H.248 media gateway control

This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and a Media Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. This document replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E-mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1. Because of ITU-T renumbering, it was published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. Users of this specification are advised to consult the H.248 Sub-series Implementors' Guide at http://www.itu.int/itudoc/itu-t/com16/implgd for additional corrections and clarifications. [STANDARDS-TRACK]

 draft-ietf-megaco-3015corr-02 RFC3015 RFC5125 HISTORIC PROPOSED STANDARD IETF rai megaco http://www.rfc-editor.org/errata_search.php?rfc=3525 10.17487/RFC3525 RFC3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) T. Kivinen M. Kojo May 2003 ASCII HTML 10 MODP More Modular Exponential IKE Internet Key Exchange bit groups

This document defines new Modular Exponential (MODP) Groups for the Internet Key Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups numbered starting at 14. The selection of the primes for theses groups follows the criteria established by Richard Schroeppel. [STANDARDS-TRACK]

 draft-ietf-ipsec-ike-modp-groups-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=3526 10.17487/RFC3526 RFC3527 Link Selection sub-option for the Relay Agent Information Option for DHCPv4 K. Kinnear M. Stapp R. Johnson J. Kumarasamy April 2003 ASCII HTML 9 DHCPv4 dynamic host configuration protocol

This document describes the link selection sub-option of the relay- agent-information option for the Dynamic Host Configuration Protocol (DHCPv4). The giaddr specifies an IP address which determines both a subnet, and thereby a link on which a Dynamic Host Configuration Protocol (DHCP) client resides as well as an IP address that can be used to communicate with the relay agent. The subnet-selection option allows the functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet/link from which to allocate an IP address, which is different from the IP address with which it desires to communicate with the DHCP server. Analogous situations exist where the relay agent needs to specify the subnet/link on which a DHCP client resides, which is different from an IP address that can be used to communicate with the relay agent. [STANDARDS-TRACK]

 draft-ietf-dhc-agent-subnet-selection-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3527 RFC3528 Mesh-enhanced Service Location Protocol (mSLP) W. Zhao H. Schulzrinne E. Guttman April 2003 ASCII HTML 15 DA directory agent slpda service agent SA slpv2 Mesh-enhanced Service Location Protocol mSLP

This document describes the Mesh-enhanced Service Location Protocol (mSLP). mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture. Peer DAs exchange new service registrations in shared scopes via anti- entropy and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally. This memo defines an Experimental Protocol for the Internet community.

 draft-zhao-slp-da-interaction-16 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3528 RFC3529 Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP) W. Harold April 2003 ASCII HTML 15 XML-RPC Extensible Markup Language-Remote Procedure Calling format messages clients servers BEEP Blocks Extensible Exchange Protocol

Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP. An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures. This document specifies a how to use the Blocks Extensible Exchange Protocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers. This memo defines an Experimental Protocol for the Internet community.

 draft-harold-beep-xmlrpc-03 RFC8553 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3529 RFC3530 Network File System (NFS) version 4 Protocol S. Shepler B. Callaghan D. Robinson R. Thurlow C. Beame M. Eisler D. Noveck April 2003 ASCII HTML 275 NFSv4 network file system

The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document replaces RFC 3010 as the definition of the NFS version 4 protocol. [STANDARDS-TRACK]

 draft-ietf-nfsv4-rfc3010bis-04 RFC3010 RFC7530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=3530 10.17487/RFC3530 RFC3531 A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block M. Blanchet April 2003 ASCII HTML 7 address plan addressing range space internet protocol

This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC 1219 and can be used for IPv6 assignments. This memo provides information for the Internet community.

 draft-ietf-ipv6-ipaddressassign-06 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3531 RFC3532 Requirements for the Dynamic Partitioning of Switching Elements T. Anderson J. Buerkle May 2003 ASCII HTML 11 atm asynchronous transfer mode

This document identifies a set of requirements for the mechanisms used to dynamically reallocate the resources of a switching element (e.g., an ATM switch) to its partitions. These requirements are particularly critical in the case of an operator creating a switch partition and then leasing control of that partition to a third party. This memo provides information for the Internet community.

 draft-ietf-gsmp-dyn-part-reqs-03 INFORMATIONAL INFORMATIONAL IETF subip gsmp 10.17487/RFC3532 RFC3533 The Ogg Encapsulation Format Version 0 S. Pfeiffer May 2003 ASCII HTML 15 bitstream media streams video audio xiph.org multimedia media interleading format video bitstream packaging audio bitstream packaging free encapsulation format stream based storage of codec data framed bitstream

This document describes the Ogg bitstream format version 0, which is a general, freely-available encapsulation format for media streams. It is able to encapsulate any kind and number of video and audio encoding formats as well as other data streams in a single bitstream. This memo provides information for the Internet community. This memo provides information for the Internet community.

 draft-pfeiffer-ogg-fileformat-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3533 10.17487/RFC3533 RFC3534 The application/ogg Media Type L. Walleij May 2003 ASCII HTML 6 mime multipurpose internet mail extenstions

The Ogg Bitstream Format aims at becoming a general, freely-available standard for transporting multimedia content across computing platforms and networks. The intention of this document is to define the MIME media type application/ogg to refer to this kind of content when transported across the Internet. It is the intention of the Ogg Bitstream Format developers that it be usable without intellectual property concerns. [STANDARDS-TRACK]

 draft-walleij-ogg-mediatype-08 RFC5334 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3534 RFC3535 Overview of the 2002 IAB Network Management Workshop J. Schoenwaelder May 2003 ASCII HTML 20 Internet Architecture Board

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. This memo provides information for the Internet community.

 draft-iab-nm-workshop-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3535 RFC3536 Terminology Used in Internationalization in the IETF P. Hoffman May 2003 ASCII HTML 30 internet engineering task force

This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo provides information for the Internet community.

 draft-hoffman-i18n-terms-11 RFC6365 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3536 RFC3537 Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key J. Schaad R. Housley May 2003 ASCII HTML 9 HMAC Hashed Message Authentication Code DES Data Encryption Standard AES Advanced Encryption Standard

This document defines two methods for wrapping an HMAC (Hashed Message Authentication Code) key. The first method defined uses a Triple DES (Data Encryption Standard) key to encrypt the HMAC key. The second method defined uses an AES (Advanced Encryption Standard) key to encrypt the HMAC key. One place that such an algorithm is used is for the Authenticated Data type in CMS (Cryptographic Message Syntax). [PROPOSED STANDARD]

 draft-ietf-smime-hmac-key-wrap-02 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib http://www.rfc-editor.org/errata_search.php?rfc=3537 10.17487/RFC3537 RFC3538 Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP) Y. Kawatsura June 2003 ASCII HTML 56 payment input output parameter

This document describes detailed Input/Output parameters for the Internet Open Trading Protocol (IOTP) Payment Application Programming Interface (API). It also describes procedures in the Payment Bridge for the use of SET (SET Secure Electronic Transaction) as the payment protocol within Version 1.0 of the IOTP. This memo provides information for the Internet community.

 draft-ietf-trade-iotp-v1.0-set-02 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3538 RFC3539 Authentication, Authorization and Accounting (AAA) Transport Profile B. Aboba J. Wood June 2003 ASCII HTML 41 AAA Authentication Authorization Accounting

This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals. [STANDARDS-TRACK]

 draft-ietf-aaa-transport-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa 10.17487/RFC3539 RFC3540 Robust Explicit Congestion Notification (ECN) Signaling with Nonces N. Spring D. Wetherall D. Ely June 2003 ASCII HTML 13 ECN explicit congestion notification TCP transmission control protocol

This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tsvwg-tcp-nonce-04 HISTORIC EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3540 RFC3541 A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D) A. Walsh May 2003 ASCII HTML 6 virtual reality monitoring language vrml extensible markup language x3d xml dtd document type definition

This document describes a Uniform Resource Name (URN) namespace for the Web3D Consortium (Web3D) for naming persistent resources such as technical documents and specifications, Virtual Reality Modeling Language (VRML) and Extensible 3D (X3D) files and resources, Extensible Markup Language (XML) Document Type Definitions (DTDs), XML Schemas, namespaces, style sheets, media assets, and other resources produced or managed by Web3D. This memo provides information for the Internet community.

 draft-walsh-urn-web3d-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3541 RFC3542 Advanced Sockets Application Program Interface (API) for IPv6 W. Stevens M. Thomas E. Nordmark T. Jinmei May 2003 ASCII HTML 77 application program interface

This document provides sockets Application Program Interface (API) to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable. This memo provides information for the Internet community.

 draft-ietf-ipngwg-rfc2292bis-09 RFC2292 INFORMATIONAL INFORMATIONAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=3542 10.17487/RFC3542 RFC3543 Registration Revocation in Mobile IPv4 S. Glass M. Chandra August 2003 ASCII HTML 33 IPv4 internet protocol mobile

This document defines a Mobile IPv4 Registration Revocation mechanism whereby a mobility agent involved in providing Mobile IP services to a mobile node can notify the other mobility agent providing Mobile IP services to the same mobile node of the termination of this registration. The mechanism is also usable by a home agent to notify a co-located mobile node of the termination of its binding as well. Moreover, the mechanism provides for this notification to be acknowledged. A signaling mechanism already defined by the Mobile IPv4 protocol is leveraged as a way to inform a mobile node of the revocation of its binding. [STANDARDS-TRACK]

 draft-ietf-mobileip-reg-revok-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3543 RFC3544 IP Header Compression over PPP T. Koren S. Casner C. Bormann July 2003 ASCII HTML 14 IPCOM-PPP internet protocol header compression point-to-point datagrams

This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol (RFC 1661). It defines extensions to the PPP Control Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 and RFC 3545. [STANDARDS-TRACK]

 draft-koren-pppext-rfc2509bis-03 RFC2509 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3544 RFC3545 Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering T. Koren S. Casner J. Geevarghese B. Thompson P. Ruddy July 2003 ASCII HTML 22 Compressed Real-time Transport Protocol CRTP PPP point to point header

This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays. [STANDARDS-TRACK]

 draft-ietf-avt-crtp-enhance-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3545 RFC3546 Transport Layer Security (TLS) Extensions S. Blake-Wilson M. Nystrom D. Hopwood J. Mikkelsen T. Wright June 2003 ASCII HTML 29 TLS transport layer security authentication privacy

This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]

 draft-ietf-tls-extensions-06 RFC4366 RFC2246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC3546 RFC3547 The Group Domain of Interpretation M. Baugher B. Weis T. Hardjono H. Harney July 2003 ASCII HTML 48 ISAMKP Internet Security Association and Key Management Protocol DOI Domain of Interpretation key management security encryption

This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. [STANDARDS-TRACK]

 draft-ietf-msec-gdoi-07 RFC6407 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC3547 RFC3548 The Base16, Base32, and Base64 Data Encodings S. Josefsson Editor July 2003 ASCII HTML 13 schemes data line-feeds alphabets base encoding hex

This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. This memo provides information for the Internet community.

 draft-josefsson-base-encoding-04 RFC4648 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3548 10.17487/RFC3548 RFC3549 Linux Netlink as an IP Services Protocol J. Salim H. Khosravi A. Kleen A. Kuznetsov July 2003 ASCII HTML 33 internet protocol messaging system

This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter- process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.). This document is intended as informational in the context of prior art for the ForCES IETF working group. This memo provides information for the Internet community.

 draft-ietf-forces-netlink-04 INFORMATIONAL INFORMATIONAL IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=3549 10.17487/RFC3549 RFC3550 RTP: A Transport Protocol for Real-Time Applications H. Schulzrinne S. Casner R. Frederick V. Jacobson July 2003 ASCII PS PDF HTML 104 RTP Real-Time Transport Protocol end-to-end network audio video RTCP RTP Control Protocol

This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-new-12 RFC1889 RFC5506 RFC5761 RFC6051 RFC6222 RFC7022 RFC7160 RFC7164 RFC8083 RFC8108 RFC8860 STD0064 INTERNET STANDARD DRAFT STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3550 10.17487/RFC3550 RFC3551 RTP Profile for Audio and Video Conferences with Minimal Control H. Schulzrinne S. Casner July 2003 ASCII PS PDF HTML 44 RTP-AV Real-time Transport Protocol audio video end-to-end network conference

This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]

 draft-ietf-avt-profile-new-13 RFC1890 RFC5761 RFC7007 RFC8860 STD0065 INTERNET STANDARD DRAFT STANDARD IETF rai avt 10.17487/RFC3551 RFC3552 Guidelines for Writing RFC Text on Security Considerations E. Rescorla B. Korver July 2003 ASCII HTML 44 RFC Request for Comment Security Considerations

All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-iab-sec-cons-03 RFC8996 BCP0072 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB http://www.rfc-editor.org/errata_search.php?rfc=3552 10.17487/RFC3552 RFC3553 An IETF URN Sub-namespace for Registered Protocol Parameters M. Mealling L. Masinter T. Hardie G. Klyne June 2003 ASCII HTML 8 syntax uniform resource names

This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF- defined resources. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-mealling-iana-urn-04 BCP0073 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3553 RFC3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec S. Bellovin J. Ioannidis A. Keromytis R. Stewart July 2003 ASCII HTML 9 IKE internet key exchange security SCTP Stream Control Transmission Protocol

This document describes functional requirements for IPsec (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in securing SCTP (RFC 2960) traffic. [STANDARDS-TRACK]

 draft-ietf-ipsec-sctp-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3554 RFC3555 MIME Type Registration of RTP Payload Formats S. Casner P. Hoschka July 2003 ASCII HTML 45 RTP real time transport protocol MIME multipurpose internet mail extensions

This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text- based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-mime-06 RFC4855 RFC4856 RFC3625 RFC4629 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3555 RFC3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth S. Casner July 2003 ASCII HTML 8 RTP real time transport protocol SDP Session Description Protocol RTCP RTP Control Protocol

This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session. [STANDARDS-TRACK]

 draft-ietf-avt-rtcp-bw-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3556 RFC3557 RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding Q. Xie Editor July 2003 ASCII HTML 15 RTP real time transport protocol DSR distributed speech recognition

This document specifies an RTP payload format for encapsulating European Telecommunications Standards Institute (ETSI) European Standard (ES) 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS-TRACK]

 draft-ietf-avt-dsr-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3557 RFC3558 RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV) A. Li July 2003 ASCII HTML 23 RTP real time transport protocol bundled interleaved EVRC Enhanced Variable Rate Codecs SMV Selectable Mode Vocoders

This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications. [STANDARDS-TRACK]

 draft-ietf-avt-evrc-smv-03 RFC4788 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3558 RFC3559 Multicast Address Allocation MIB D. Thaler June 2003 ASCII HTML 37 maas multicast address allocation servers MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multicast address allocation. [STANDARDS-TRACK]

 draft-ietf-malloc-malloc-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC3559 RFC3560 Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS) R. Housley July 2003 ASCII HTML 18 CMS Cryptographic Message Syntax security encryption

This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). The CMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients. [STANDARDS-TRACK]

 draft-ietf-smime-cms-rsaes-oaep-07 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC3560 RFC3561 Ad hoc On-Demand Distance Vector (AODV) Routing C. Perkins E. Belding-Royer S. Das July 2003 ASCII HTML 37 AODV Ad hoc On-Demand Distance Vector unicast multiple nodes

The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-manet-aodv-13 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC3561 RFC3562 Key Management Considerations for the TCP MD5 Signature Option M. Leech July 2003 ASCII HTML 7 bgp border gateway protocol security encryption

The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature. This document addresses the security requirements of that keying material. This memo provides information for the Internet community.

 draft-ietf-idr-md5-keys-00 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC3562 RFC3563 Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development A. Zinin July 2003 ASCII HTML 8

This document contains the text of the agreement signed between ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines. This memo provides information for the Internet community.

 draft-zinin-ietf-jtc1-aggr-01 RFC6233 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3563 RFC3564 Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering F. Le Faucheur W. Lai July 2003 ASCII HTML 22 multi-protocol label switching bandwidth constraints model overbooking

This document presents Service Provider requirements for support of Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS- TE). Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document. A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short and Diff-Serv-aware Traffic Engineering can address the needs. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution. This memo provides information for the Internet community.

 draft-ietf-tewg-diff-te-reqts-07 RFC5462 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC3564 RFC3565 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS) J. Schaad July 2003 ASCII HTML 14 AES Advanced Encryption Standard CMS Cryptographic Message Syntax security data encoding

This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]

 draft-ietf-smime-aes-alg-07 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC3565 RFC3566 The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec S. Frankel H. Herbert September 2003 ASCII HTML 11 IPsec Internet Protocol Security authentication hash security

A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. [STANDARDS-TRACK]

 draft-ietf-ipsec-ciph-aes-xcbc-mac-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3566 RFC3567 Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication T. Li R. Atkinson July 2003 ASCII HTML 6 iso international standards organization

This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. This memo provides information for the Internet community.

 draft-ietf-isis-hmac-04 RFC5304 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3567 RFC3568 Known Content Network (CN) Request-Routing Mechanisms A. Barbir B. Cain R. Nair O. Spatscheck July 2003 ASCII HTML 19 metrics routing redirection

This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or before December 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing. This memo provides information for the Internet community.

 draft-ietf-cdi-known-request-routing-03 RFC8996 INFORMATIONAL INFORMATIONAL IETF app cdi 10.17487/RFC3568 RFC3569 An Overview of Source-Specific Multicast (SSM) S. Bhattacharyya Editor July 2003 ASCII HTML 14 routing applications deployment interoperability

The purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models. This memo provides information for the Internet community.

 draft-ietf-ssm-overview-05 INFORMATIONAL INFORMATIONAL IETF rtg ssm 10.17487/RFC3569 RFC3570 Content Internetworking (CDI) Scenarios P. Rzewski M. Day D. Gilletti July 2003 ASCII HTML 20 production networks

In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals. This memo provides information for the Internet community.

 draft-ietf-cdi-scenarios-01 RFC6770 INFORMATIONAL INFORMATIONAL IETF app cdi 10.17487/RFC3570 RFC3571 Framework Policy Information Base for Usage Feedback D. Rawlins A. Kulkarni K. Ho Chan M. Bokaemper D. Dutt August 2003 ASCII HTML 35 pib

This document describes a portion of the Policy Information Base (PIB) to control policy usage collection and reporting in a device. The provisioning classes specified here allow a Policy Decision Point (PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported. This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects from which usage information is collected. This memo provides information for the Internet community.

 draft-ietf-rap-feedback-fr-pib-06 HISTORIC INFORMATIONAL IETF ops rap 10.17487/RFC3571 RFC3572 Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH) T. Ogura M. Maruyama T. Yoshida July 2003 ASCII HTML 14 ipv6 synchronous optical network synchronous digital hierarchy

Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link- layer protocol that provides multiple access capability over a Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH). This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of forming IPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages. This memo provides information for the Internet community.

 draft-ogura-ipv6-mapos-02 RFC8064 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3572 RFC3573 Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) I. Goyret July 2003 ASCII HTML 13 ppp point-to-point pstn public switched telephone network. L2TP Layer 2 Tunneling Protocol

The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. It is common for these PPP sessions to be established using modems connected over the public switched telephone network. One of the standards governing modem operation defines procedures that enable a client modem to put the call on hold and later, re-establish the modem link with minimal delay and without having to redial. While the modem call is on hold, the client phone line can be used to place or receive other calls. The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled. This document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold. [STANDARDS-TRACK]

 draft-ietf-l2tpext-v92-moh-05 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3573 RFC3574 Transition Scenarios for 3GPP Networks J. Soininen Editor August 2003 ASCII HTML 12 third generation parnership project packet ipv6 ipv4 internet

This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e., General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study. This memo provides information for the Internet community.

 draft-ietf-v6ops-3gpp-cases-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3574 RFC3575 IANA Considerations for RADIUS (Remote Authentication Dial In User Service) B. Aboba July 2003 ASCII HTML 8 IANA Internet Assigned Numbers Authority encryption NAS Network Access Server RADIUS Remote Authentication Dial In User Service

This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS). [STANDARDS-TRACK]

 draft-aboba-radius-iana-07 RFC2865 RFC2868 RFC6929 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3575 10.17487/RFC3575 RFC3576 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) M. Chiba G. Dommety M. Eklund D. Mitton B. Aboba July 2003 ASCII HTML 30 nas network access server

This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community.

 draft-chiba-radius-dynamic-authorization-20 RFC5176 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3576 RFC3577 Introduction to the Remote Monitoring (RMON) Family of MIB Modules S. Waldbusser R. Cole C. Kalbfleisch D. Romascanu August 2003 ASCII HTML 31 management information base

The Remote Monitoring (RMON) Framework consists of a number of interrelated documents. This memo describes these documents and how they relate to one another. This memo provides information for the Internet community.

 draft-ietf-rmonmib-framework-05 INFORMATIONAL INFORMATIONAL IETF ops rmonmib 10.17487/RFC3577 RFC3578 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP) G. Camarillo A. B. Roach J. Peterson L. Ong August 2003 ASCII HTML 13 pstn public switched telephone network ISDN Integrated Services Digital Network ISUP User Part SIP Session Initiation Protocol

This document describes a way to map Integrated Services Digital Network User Part (ISUP) overlap signalling to Session Initiation Protocol (SIP). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN). [STANDARDS-TRACK]

 draft-ietf-sipping-overlap-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC3578 RFC3579 RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP) B. Aboba P. Calhoun September 2003 ASCII HTML 46 RADIUS encryption NAS Network Access Server

This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This memo provides information for the Internet community.

 draft-aboba-radius-rfc2869bis-22 RFC2869 RFC5080 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3579 10.17487/RFC3579 RFC3580 IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines P. Congdon B. Aboba A. Smith G. Zorn J. Roese September 2003 ASCII HTML 30 AAA authentication authorization and accounting

This document provides suggestions on Remote Authentication Dial In User Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community.

 draft-congdon-radius-8021x-29 RFC7268 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3580 10.17487/RFC3580 RFC3581 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing J. Rosenberg H. Schulzrinne August 2003 ASCII HTML 13 SIP Session Initiation Protocol Symmetric Response Routing report client server

The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated. [STANDARDS-TRACK]

 draft-ietf-sip-symmetric-response-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3581 RFC3582 Goals for IPv6 Site-Multihoming Architectures J. Abley B. Black V. Gill August 2003 ASCII HTML 9 internet protocol multi6

This document outlines a set of goals for proposed new IPv6 site- multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here. This memo provides information for the Internet community.

 draft-ietf-multi6-multihoming-requirements-07 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC3582 RFC3583 Requirements of a Quality of Service (QoS) Solution for Mobile IP H. Chaskar Editor September 2003 ASCII HTML 10 internet protocol routing packets node

Mobile IP ensures correct routing of packets to a mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper Quality of Service (QoS) forwarding treatment to the mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP. This memo provides information for the Internet community.

 draft-ietf-nsis-qos-requirements-01 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC3583 RFC3584 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework R. Frye D. Levi S. Routhier B. Wijnen August 2003 ASCII HTML 51 SNMP simple network management protocol mib information base

The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-snmpv3-coex-v2-04 RFC2576 BCP0074 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops snmpv3 10.17487/RFC3584 RFC3585 IPsec Configuration Policy Information Model J. Jason L. Rafalow E. Vyncke August 2003 ASCII HTML 88 IPsec Internet Protocol Security ike internet key exchange protocol core Constrained RESTful Environments pcim Policy Core Information Model

This document presents an object-oriented information model of IP Security (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task- specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints. The information model described in this document models the configuration parameters defined by IPSec. The information model also covers the parameters found by the Internet Key Exchange protocol (IKE). Other key exchange protocols could easily be added to the information model by a simple extension. Further extensions can further be added easily due to the object-oriented nature of the model. This information model is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) and in the Policy Core Information Model Extensions (PCIMe). [STANDARDS-TRACK]

 draft-ietf-ipsp-config-policy-model-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsp 10.17487/RFC3585 RFC3586 IP Security Policy (IPSP) Requirements M. Blaze A. Keromytis M. Richardson L. Sanchez August 2003 ASCII HTML 10 IPSP Internet Protocol Security Policy data integrity authentication host network

This document describes the problem space and solution requirements for developing an IP Security Policy (IPSP) configuration and management framework. The IPSP architecture provides a scalable, decentralized framework for managing, discovering and negotiating the host and network security policies that govern access, authorization, authentication, confidentiality, data integrity, and other IP Security properties. This document highlights such architectural components and presents their functional requirements. [STANDARDS-TRACK]

 draft-ietf-ipsp-requirements-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsp 10.17487/RFC3586 RFC3587 IPv6 Global Unicast Address Format R. Hinden S. Deering E. Nordmark August 2003 ASCII HTML 5 internet protocol architecture routing

This document obsoletes RFC 2374, "An IPv6 Aggregatable Global Unicast Address Format". It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic. This memo provides information for the Internet community.

 draft-ietf-ipv6-unicast-aggr-v2-03 RFC2374 INFORMATIONAL INFORMATIONAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=3587 10.17487/RFC3587 RFC3588 Diameter Base Protocol P. Calhoun J. Loughney E. Guttman G. Zorn J. Arkko September 2003 ASCII HTML 147 aaa authentication authorization accounting ip mobility Diameter Base Protocol

The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. [STANDARDS-TRACK]

 draft-ietf-aaa-diameter-17 RFC6733 RFC5729 RFC5719 RFC6408 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=3588 10.17487/RFC3588 RFC3589 Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5 J. Loughney September 2003 ASCII HTML 5 iana allocation

This document describes the IANA's allocation of a block of Diameter Command Codes for the Third Generation Partnership Project (3GPP) Release 5. This document does not pass judgment on the usage of these command codes. Further more, these command codes are for use for Release 5. For future releases, these codes cannot be reused, but must be allocated according to the Diameter Base specification. This memo provides information for the Internet community.

 draft-loughney-aaa-cc-3gpp-01 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3589 10.17487/RFC3589 RFC3590 Source Address Selection for the Multicast Listener Discovery (MLD) Protocol B. Haberman September 2003 ASCII HTML 6 MLD-IPv6 Multicast Listener Discovery internet protocol router packets

It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery (MLD) messages when a node is performing stateless address autoconfiguration. This document is intended to clarify the rules on selecting an IPv6 address to use for MLD messages. [STANDARDS-TRACK]

 draft-ietf-magma-mld-source-07 RFC2710 PROPOSED STANDARD PROPOSED STANDARD IETF int magma 10.17487/RFC3590 RFC3591 Definitions of Managed Objects for the Optical Interface Type H-K. Lam M. Stewart A. Huynh September 2003 ASCII HTML 174 MIB management information base snmp simple network management protocol otn optical transport network itu-t performance monitoring configuration dwdm optical transmission session optical multiplex section optical channel otuk odukt oduk

This memo defines a portion of the Management Information Base (MIB) for use with Simple Network Management Protocol (SNMP) in TCP/IP-based internets. In particular, it defines objects for managing Optical Interfaces associated with WavelengthDivision Multiplexing systems or characterized by the Optical Transport Network (OTN) in accordance with the OTN architecture defined in ITU-T Recommendation G.872. The MIB module defined in this memo can be used for performance monitoring and/or configuration of such optical interface. [STANDARDS-TRACK]

 draft-ietf-atommib-opticalmib-08 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib http://www.rfc-editor.org/errata_search.php?rfc=3591 10.17487/RFC3591 RFC3592 Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type K. Tesink September 2003 ASCII HTML 73 MIB Management Information Base SNMP Simple Network Management Protocol Synchronous Optical Network Synchronous Digital Hierarchy SONET SDH

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. This memo replaces RFC 2558. Changes relative to RFC 2558 are summarized in the MIB module's REVISION clause. [STANDARDS-TRACK]

 draft-ietf-atommib-rfc2558bis-01 RFC2558 DRAFT STANDARD DRAFT STANDARD IETF int vgmib http://www.rfc-editor.org/errata_search.php?rfc=3592 10.17487/RFC3592 RFC3593 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals K. Tesink Editor September 2003 ASCII HTML 10 MIB management information base data

This document defines a set of Textual Conventions for MIB modules that make use of performance history data based on 15 minute intervals. This memo replaces RFC 2493. Changes relative to RFC 2493 are summarized in the MIB module's REVISION clause. [STANDARDS-TRACK]

 draft-ietf-atommib-rfc2493bis-01 RFC2493 DRAFT STANDARD DRAFT STANDARD IETF int vgmib 10.17487/RFC3593 RFC3594 PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option P. Duffy September 2003 ASCII HTML 7 DHCP dynamic host configuration protocol CCC CableLabs Client Configuration

This document defines a new sub-option for the DHCP CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate security tickets stored in CCD non volatile memory (i.e., locally persisted security tickets). [STANDARDS-TRACK]

 draft-ietf-dhc-pktc-kerb-tckt-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3594 RFC3595 Textual Conventions for IPv6 Flow Label B. Wijnen September 2003 ASCII HTML 6 mib management information base

This MIB module defines textual conventions to represent the commonly used IPv6 Flow Label. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-ops-ipv6-flowlabel-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC3595 RFC3596 DNS Extensions to Support IP Version 6 S. Thomson C. Huitema V. Ksinant M. Souissi October 2003 ASCII HTML 8 internet protocol domain name system DNS zone

This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK]

 draft-ietf-dnsext-rfc1886bis-03 RFC3152 RFC1886 STD0088 INTERNET STANDARD DRAFT STANDARD IETF int dnsext 10.17487/RFC3596 RFC3597 Handling of Unknown DNS Resource Record (RR) Types A. Gustafsson September 2003 ASCII HTML 8 DNS domain name system name server software compression transparency RR Resource Record

Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK]

 draft-ietf-dnsext-unknown-rrs-06 RFC2163 RFC2535 RFC4033 RFC4034 RFC4035 RFC5395 RFC6195 RFC6895 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3597 10.17487/RFC3597 RFC3598 Sieve Email Filtering -- Subaddress Extension K. Murchison September 2003 ASCII HTML 6 users detailed addressing language address part test detail filter mailbox

On email systems that allow for "subaddressing" or "detailed addressing" (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address. [STANDARDS-TRACK]

 draft-murchison-sieve-subaddress-06 RFC5233 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3598 RFC3599 Request for Comments Summary RFC Numbers 3500-3599 S. Ginoza December 2003 ASCII HTML 34

This RFC is a slightly annotated list of the 100 RFCs from RFC 3500 through RFC 3599. This is a status report on these RFCs.

 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3599 RFC3600 Internet Official Protocol Standards J. Reynolds Editor S. Ginoza Editor November 2003 ASCII HTML 50

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 2, 2003. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.

 RFC3300 RFC3700 HISTORIC INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3600 10.17487/RFC3600 RFC3601 Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses C. Allocchio September 2003 ASCII HTML 10 notations dtmf dual tone multifrequency telephony e-mail addresses urls integrated messaging 3gpp

This memo describes the full set of notations needed to represent a text string in a Dial Sequence. A Dial Sequence is normally composed of Dual Tone Multi Frequency (DTMF) elements, plus separators and additional "actions" (such as "wait for dialtone", "pause for N secs", etc.) which could be needed to successfully establish the connection with the target service: this includes the cases where subaddresses or DTMF menu navigation apply.

 draft-allocchio-gstn-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3601 RFC3602 The AES-CBC Cipher Algorithm and Its Use with IPsec S. Frankel R. Glenn S. Kelly September 2003 ASCII HTML 15 ipsec Internet Protocol Security encapsulating security payload

This document describes the use of the Advanced Encryption Standard (AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).

 draft-ietf-ipsec-ciph-aes-cbc-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3602 RFC3603 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture W. Marshall Editor F. Andreasen Editor October 2003 ASCII HTML 28 network access coordination

In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.

 draft-dcsgroup-sipping-proxy-proxy-03 RFC5503 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3603 RFC3604 Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3) H. Khosravi G. Kullgren S. Shew J. Sadler A. Watanabe October 2003 ASCII HTML 16 controllers routers formats codes

This memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP). It also contains clarifications and suggested changes to the GSMPv3 specification.

 draft-ietf-gsmp-reqs-06 INFORMATIONAL INFORMATIONAL IETF subip gsmp 10.17487/RFC3604 RFC3605 Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) C. Huitema October 2003 ASCII HTML 8 RTCP Real Time Control Protocol SDP Session Description Protocol nat network access translation port mapping

The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP.

 draft-ietf-mmusic-sdp4nat-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3605 10.17487/RFC3605 RFC3606 Definitions of Supplemental Managed Objects for ATM Interface F. Ly M. Noto A. Smith E. Spiegel K. Tesink November 2003 ASCII HTML 94 ATM asynchronous transfer mode MIB management information base

This memo defines objects used for managing ATM-based interfaces, devices, and services, in addition to those defined in RFC 2515, the ATM-MIB, to provide additional support for the management of ATM Switched Virtual Connections (SVCs) and ATM Permanent Virtual Connections (PVCs).

 draft-ietf-atommib-atm2-19 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC3606 RFC3607 Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool M. Leech September 2003 ASCII HTML 8 security encryption des data standard distributed cryptanalysis computer virus network worm codebreaking

This document revisits the so-called Chinese Lottery massively-parallel cryptanalytic attack. It explores Internet-based analogues to the Chinese Lottery, and their potentially-serious consequences.

 draft-leech-chinese-lottery-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3607 RFC3608 Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration D. Willis B. Hoeneisen October 2003 ASCII HTML 17 SIP Session Initiation Protocol user agent domain register

This document defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain.

 draft-ietf-sip-scvrtdisco-04 RFC5630 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3608 RFC3609 Tracing Requirements for Generic Tunnels R. Bonica K. Kompella D. Meyer September 2003 ASCII HTML 9 traceroute application IP internet protocol

This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support that application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They will also use the application to discover details regarding tunnels that support IP forwarding. The generic route-tracing application, specified herein, supports a superset of the functionality that "traceroute" currently offers. Like traceroute, the generic route-tracing application can discover the forwarding path between two interfaces that are contained by an IP network. Unlike traceroute, this application can reveal details regarding tunnels that support the IP forwarding path.

 draft-ietf-ccamp-tracereq-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC3609 RFC3610 Counter with CBC-MAC (CCM) D. Whiting R. Housley N. Ferguson September 2003 ASCII HTML 26 authentication encryption security ciphers

Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES).

 draft-housley-ccm-mode-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3610 10.17487/RFC3610 RFC3611 RTP Control Protocol Extended Reports (RTCP XR) T. Friedman Editor R. Caceres Editor A. Clark Editor November 2003 ASCII HTML 55 RTP real time transport protocol packet type SDP session description protocol blocks XR Extended Report

This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.

 draft-ietf-avt-rtcp-report-extns-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3611 10.17487/RFC3611 RFC3612 Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) A. Farrel September 2003 ASCII HTML 16 mpls fault tolerence high availability multiprotocol label switching cr-ldp high availability restart

This document provides guidance on when it is advisable to implement some form of Label Distribution Protocol (LDP) restart mechanism and which approach might be more suitable. The issues and extensions described in this document are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP".

 draft-ietf-mpls-ldp-restart-applic-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3612 RFC3613 Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE) R. Morgan K. Hazelton October 2003 ASCII HTML 8 internet2 middleware

This document describes a Uniform Resource Name (URN) namespace for the Internet2 Middleware Architecture Committee for Education (MACE). This namespace is for naming persistent resources defined by MACE, its working groups and other designated subordinates.

 draft-hazelton-mace-urn-namespace-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3613 RFC3614 A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG) J. Smith September 2003 ASCII HTML 6 iso international organization standardization multimedia metadata xml classification schemes digital rights management

This document describes a Uniform Resource Name (URN) namespace for the Motion Picture Experts Group (MPEG) for naming persistent resources as part of the MPEG standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by MPEG.

 draft-smith-urn-mpeg-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3614 RFC3615 A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging J. Gustin A. Goyens September 2003 ASCII HTML 5 messaging service interface software

This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT for usage within messages standardized by SWIFT.

 draft-gustin-goyens-urn-id-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3615 RFC3616 A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA) F. Bellifemine I. Constantinescu S. Willmott September 2003 ASCII HTML 8 URN NID Uniform Resource Name Namespace Identification

This document describes a Uniform Resource Name Namespace Identification (URN NID) for the Foundation for Intelligent Physical Agents (FIPA). This URN NID will be used for identification of standard components published by the FIPA standards body in the area of Agent technology.

 draft-bellifemine-urn-fipa-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3616 RFC3617 Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP) E. Lear October 2003 ASCII HTML 7

The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL protocol that has been in use on the Internet for quite a long time. While this document discourages its continued use, largely due to security concerns, we do define a Uniform Resource Identifier (URI) scheme, as well as discuss the protocol's applicability.

 draft-lear-tftp-uri-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3617 RFC3618 Multicast Source Discovery Protocol (MSDP) B. Fenner Editor D. Meyer Editor October 2003 ASCII HTML 19 MSDP Multicast Source Discovery Protocol ipv4 pim-sm independent multicast sparse-mode rp rendezvous point

The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains. This document reflects existing MSDP implementations.

 draft-ietf-msdp-spec-20 EXPERIMENTAL EXPERIMENTAL IETF rtg msdp http://www.rfc-editor.org/errata_search.php?rfc=3618 10.17487/RFC3618 RFC3619 Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1 S. Shah M. Yip October 2003 ASCII HTML 7 ethernet rings robust

This document describes the Ethernet Automatic Protection Switching (EAPS) (tm) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings. An Ethernet ring built using EAPS can have resilience comparable to that provided by SONET rings, at a lower cost and with fewer constraints (e.g., ring size).

 draft-shah-extreme-eaps-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3619 RFC3620 The TUNNEL Profile D. New October 2003 ASCII HTML 18 TUNNEL beep blocks extensible exchange protocol firewall application layer

This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall.

 draft-ietf-idwg-beep-tunnel-05 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF sec idwg 10.17487/RFC3620 RFC3621 Power Ethernet MIB A. Berger D. Romascanu December 2003 ASCII HTML 20 MIB management information base data terminal equipment dte power sourcing equipment pse

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This document proposes an extension to the Ethernet-like Interfaces MIB with a set of objects for managing Power Sourcing Equipment (PSE).

 draft-ietf-hubmib-power-ethernet-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3621 RFC3622 A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project M. Mealling February 2004 ASCII HTML 7 federated network identity

This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity.

 draft-mealling-liberty-urn-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3622 RFC3623 Graceful OSPF Restart J. Moy P. Pillay-Esnault A. Lindem November 2003 ASCII HTML 18 OSPF open shortest path first non-stop forwarding

This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called "graceful restart" or "non-stop forwarding". A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops, the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented.

 draft-ietf-ospf-hitless-restart-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC3623 RFC3624 The Media Gateway Control Protocol (MGCP) Bulk Audit Package B. Foster D. Auerbach F. Andreasen November 2003 ASCII HTML 19 call agent endpoints naming conventions

The base Media Gateway Control Protocol (MGCP) includes audit commands that only allow a Call Agent to audit endpoint and/or connection state one endpoint at a time. This document describes a new MGCP package for bulk auditing of a group of gateway endpoints. It allows a Call Agent to determine the endpoint naming convention, the list of instantiated endpoints as well connection and endpoint state for the group of endpoints.

 draft-foster-mgcp-bulkaudits-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3624 RFC3625 The QCP File Format and Media Types for Speech Data R. Gellens H. Garudadri September 2003 ASCII HTML 15 13k qcelp audio multimedia voip real time transport protocol multipurpose internet mail extensions

RFC 2658 specifies the streaming format for 3GPP2 13KK vocoder (High Rate Speech Service Option 17 for Wideband Spread Spectrum Communications Systems, also known as QCELP 13K vocoder) data, but does not specify a storage format. Many implementations have been using the "QCP" file format (named for its file extension) for exchanging QCELP 13K data as well as Enhanced Variable Rate Coder (EVRC) and Selectable Mode Vocoders (SMV) data. (For example, Eudora(r), QuickTime(r), and cmda2000(r) handsets). This document specifies the QCP file format and updates the audio/qcelp media registration to specify this format for storage, and registers the audio/evrc-qcp and audio/smv-qcp media types for EVRC and SMV (respectively) data stored in this format.

 draft-gellens-qcp-01 RFC3555 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3625 10.17487/RFC3625 RFC3626 Optimized Link State Routing Protocol (OLSR) T. Clausen Editor P. Jacquet Editor October 2003 ASCII HTML 75 OLSR Optimized Link State Routing mobile ad hoc wireless multipoint relays mpr mprs

This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.

 draft-ietf-manet-olsr-11 EXPERIMENTAL EXPERIMENTAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=3626 10.17487/RFC3626 RFC3627 Use of /127 Prefix Length Between Routers Considered Harmful P. Savola September 2003 ASCII HTML 6 address space anycast

In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.

 draft-savola-ipv6-127-prefixlen-04 RFC6547 HISTORIC INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3627 10.17487/RFC3627 RFC3628 Policy Requirements for Time-Stamping Authorities (TSAs) D. Pinkas N. Pope J. Ross November 2003 ASCII HTML 43 tokens public key certificates

This document defines requirements for a baseline time-stamp policy for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, supported by public key certificates, with an accuracy of one second or better. A TSA may define its own policy which enhances the policy defined in this document. Such a policy shall incorporate or further constrain the requirements identified in this document.

 draft-ietf-pkix-pr-tsa-05 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC3628 RFC3629 UTF-8, a transformation format of ISO 10646 F. Yergeau November 2003 ASCII HTML 14 UTF-8 UCS Universal Character Set Transformation Format

ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.

 draft-yergeau-rfc2279bis-05 RFC2279 STD0063 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP 10.17487/RFC3629 RFC3630 Traffic Engineering (TE) Extensions to OSPF Version 2 D. Katz K. Kompella D. Yeung September 2003 ASCII HTML 14 OSPF open-shortest path first ink state advertisement

This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.

 draft-katz-yeung-ospf-traffic-10 RFC2370 RFC4203 RFC5786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC3630 RFC3631 Security Mechanisms for the Internet S. Bellovin Editor J. Schiller Editor C. Kaufman Editor December 2003 ASCII HTML 20 protocol host compromise dos denial of service

Security must be built into Internet Protocols for those protocols to offer their services securely. Many security problems can be traced to improper implementations. However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable. Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself. However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each.

 draft-iab-secmech-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3631 RFC3632 VeriSign Registry Registrar Protocol (RRP) Version 2.0.0 S. Hollenbeck S. Veeramachaneni S. Yalamanchilli November 2003 ASCII HTML 8 RRP shared registration system gLTD ccTLD top level domain

This document updates version 1.1.0 of the Network Solutions Inc. (NSI) Registry Registrar Protocol (RRP) specified in RFC 2832. The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of the VeriSign Registry Registrar Protocol.

 draft-hollenbeck-rfc2832bis-02 RFC2832 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3632 RFC3633 IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 O. Troan R. Droms December 2003 ASCII HTML 19 DHCP Dynamic Host Configuration Protocol automated delegation router

The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP). This mechanism is intended for delegating a long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.

 draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05 RFC8415 RFC6603 RFC7550 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3633 10.17487/RFC3633 RFC3634 Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option K. Luehrs R. Woundy J. Bevilacqua N. Davoust December 2003 ASCII HTML 7 DHCP Dynamic Host Configuration Protocol KDC Key Distribution Center CCC CableLabs Client Configuration

This document defines a new sub-option for the CableLabs Client Configuration (CCC) Dynamic Host Configuration Protocol (DHCP) option code for conveying the network addresses of Key Distribution Center (KDC) servers.

 draft-ietf-dhc-suboptions-kdc-serveraddress-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3634 RFC3635 Definitions of Managed Objects for the Ethernet-like Interface Types J. Flick September 2003 ASCII HTML 64 MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces.

 draft-ietf-hubmib-etherif-mib-v3-03 RFC2665 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3635 RFC3636 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) J. Flick September 2003 ASCII HTML 62 MAU-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). This memo obsoletes RFC 2668. This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515.

 draft-ietf-hubmib-mau-mib-v3-04 RFC2668 RFC1515 RFC4836 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3636 RFC3637 Definitions of Managed Objects for the Ethernet WAN Interface Sublayer C.M. Heard Editor September 2003 ASCII HTML 37 MIB Management Information Base

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS). The MIB module defined in this memo is an extension of the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface MIB and is implemented in conjunction with it and with the Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB.

 draft-ietf-hubmib-wis-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3637 RFC3638 Applicability Statement for Reclassification of RFC 1643 to Historic Status J. Flick C. M. Heard September 2003 ASCII HTML 5 ETHER-MIB MIB Network Management SNMP Ethernet

This memo recommends that RFC 1643 be reclassified as an Historic document and provides the supporting motivation for that recommendation.

 draft-ietf-hubmib-1643-to-historic-01 RFC1643 INFORMATIONAL INFORMATIONAL IETF ops hubmib 10.17487/RFC3638 RFC3639 Considerations on the use of a Service Identifier in Packet Headers M. St. Johns Editor G. Huston Editor IAB October 2003 ASCII HTML 8 port fields protocol number

This memo describes some considerations relating to the use of IP protocol number fields and payload protocol (e.g., TCP) port fields to identify particular services that may be associated with that port number or protocol number.

 draft-iab-service-id-considerations-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3639 RFC3640 RTP Payload Format for Transport of MPEG-4 Elementary Streams J. van der Meer D. Mackie V. Swaminathan D. Singer P. Gentric November 2003 ASCII HTML 43 RTP real time transport protocol audio video streams

The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29 WG11) is a working group in ISO that produced the MPEG-4 standard. MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non-multiplexed MPEG-4 elementary stream.

 draft-ietf-avt-mpeg4-simple-08 RFC5691 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3640 RFC3641 Generic String Encoding Rules (GSER) for ASN.1 Types S. Legg October 2003 ASCII HTML 16 asn.1 abstract syntax notation

This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Generic String Encoding Rules (GSER), that produce a human readable text encoding for values of any given ASN.1 data type.

 draft-legg-ldap-gser-04 RFC4792 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3641 RFC3642 Common Elements of Generic String Encoding Rules (GSER) Encodings S. Legg October 2003 ASCII HTML 13 asn.1 abstract syntax notation

The Generic String Encoding Rules (GSER) describe a human readable text encoding for an Abstract Syntax Notation One (ASN.1) value of any ASN.1 type. Specifications making use of GSER may wish to provide an equivalent Augmented Backus-Naur Form (ABNF) description of the GSER encoding for a particular ASN.1 type as a convenience for implementors. This document supports such specifications by providing equivalent ABNF for the GSER encodings for ASN.1 types that commonly occur in Lightweight Directory Access Protocol (LDAP) syntaxes.

 draft-legg-ldap-gser-abnf-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3642 10.17487/RFC3642 RFC3643 Fibre Channel (FC) Frame Encapsulation R. Weber M. Rajagopal F. Travostino M. O'Donnell C. Monia M. Merhar December 2003 ASCII HTML 20 FC Fibre Channel ips ip storage frame header

This document describes the common Fibre Channel (FC) frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates FC frames.

 draft-ietf-ips-fcencapsulation-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3643 RFC3644 Policy Quality of Service (QoS) Information Model Y. Snir Y. Ramberg J. Strassner R. Cohen B. Moore November 2003 ASCII HTML 73 QoS Quality of Service integrated differentiated object oriented

This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies. This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.

 draft-ietf-policy-qos-info-model-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3644 RFC3645 Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) S. Kwan P. Garg J. Gilroy L. Esibov J. Westhead R. Hall October 2003 ASCII HTML 26 GSS-TSIG Generic Security Service Algorithm Secret Key Transaction Authentication for DNS domain name system signature

The Secret Key Transaction Authentication for DNS (TSIG) protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). This document updates RFC 2845.

 draft-ietf-dnsext-gss-tsig-06 RFC2845 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3645 RFC3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) R. Droms Editor December 2003 ASCII HTML 7 DNS domain name system service server client DHCP Dynamic Host Configuration Protocol

This document describes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client.

 draft-ietf-dhc-dhcpv6-opt-dnsconfig-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3646 RFC3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework S. Chokhani W. Ford R. Sabett C. Merrill S. Wu November 2003 ASCII HTML 94 pkix encryption security authentication

This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527.

 draft-ietf-pkix-ipki-new-rfc2527-02 RFC2527 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3647 10.17487/RFC3647 RFC3648 Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol J. Whitehead J. Reschke Editor December 2003 ASCII HTML 30 WebDAV Web Distribution Authoring and Versioning server client semantics ordering orderpatch method position header ordering-type header

This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.

 draft-ietf-webdav-ordering-protocol-10 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav 10.17487/RFC3648 RFC3649 HighSpeed TCP for Large Congestion Windows S. Floyd December 2003 ASCII HTML 34 TCP transmission control protocol round-trip rate packet

The proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals. This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address his limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community.

 draft-ietf-tsvwg-highspeed-01 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3649 RFC3650 Handle System Overview S. Sun L. Lannom B. Boesch November 2003 ASCII HTML 21 name service

This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URNs. The Handle System is a general-purpose global name service that allows secured name resolution and administration over networks such as the Internet. The Handle System manages handles, which are unique names for digital objects and other Internet resources.

 draft-sun-handle-system-12 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3650 10.17487/RFC3650 RFC3651 Handle System Namespace and Service Definition S. Sun S. Reilly L. Lannom November 2003 ASCII HTML 41 name service

The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document provides a detailed description of the Handle System namespace, and its data, service, and operation models. The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by the Handle System protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol.

 draft-sun-handle-system-def-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3651 10.17487/RFC3651 RFC3652 Handle System Protocol (ver 2.1) Specification S. Sun S. Reilly L. Lannom J. Petrone November 2003 ASCII HTML 53 name service

The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document describes the protocol used for client software to access the Handle System for both handle resolution and administration. The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle. It also defines the messages exchanged between the client and server for any handle operation.

 draft-sun-handle-system-protocol-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3652 RFC3653 XML-Signature XPath Filter 2.0 J. Boyer M. Hughes J. Reagle December 2003 ASCII HTML 15 extensible markup language digital signature

XML Signature recommends a standard means for specifying information content to be digitally signed and for representing the resulting digital signatures in XML. Some applications require the ability to specify a subset of a given XML document as the information content to be signed. The XML Signature specification meets this requirement with the XPath transform. However, this transform can be difficult to implement efficiently with existing technologies. This specification defines a new XML Signature transform to facilitate the development of efficient document subsetting implementations that interoperate under similar performance profiles. This document is the W3C XML Signature XPath-Filter 2.0 Recommendation. This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

 draft-ietf-xmldsig-xpf2-01 INFORMATIONAL INFORMATIONAL IETF sec xmldsig 10.17487/RFC3653 RFC3654 Requirements for Separation of IP Control and Forwarding H. Khosravi Editor T. Anderson Editor November 2003 ASCII HTML 18 forces forwarding control element separation data

This document introduces the Forwarding and Control Element Separation (ForCES) architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device.

 draft-ietf-forces-requirements-10 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC3654 RFC3655 Redefinition of DNS Authenticated Data (AD) bit B. Wellington O. Gudmundsson November 2003 ASCII HTML 8 DNS-SECEXT dns authentication

This document alters the specification defined in RFC 2535. Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful. This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy.

 draft-ietf-dnsext-ad-is-secure-06 RFC4033 RFC4034 RFC4035 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3655 RFC3656 The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol R. Siemborski December 2003 ASCII HTML 19 Mailbox Update MUPDATE Distributed Mailbox Database Protocol imap pop3 post office protocol internet message access protocol

As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery. The Mailbox Update (MUPDATE) protocol allows a group of Internet Message Access Protocol (IMAP) or Post Office Protocol - Version 3 (POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol.

 draft-siemborski-mupdate-04 RFC8996 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3656 RFC3657 Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS) S. Moriai A. Kato January 2004 ASCII HTML 14 CMS Cryptographic Message Syntax security mail content key

This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).

 draft-ietf-smime-camellia-05 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC3657 RFC3658 Delegation Signer (DS) Resource Record (RR) O. Gudmundsson December 2003 ASCII HTML 19 zone cut zone key security dns domain name system

The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035, RFC 2535, RFC 3008 and RFC 3090.

 draft-ietf-dnsext-delegation-signer-15 RFC4033 RFC4034 RFC4035 RFC3090 RFC3008 RFC2535 RFC1035 RFC3755 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3658 RFC3659 Extensions to FTP P. Hethmon March 2007 ASCII HTML 61 FTP file transfer protocol stream mode data transfer storage

This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure. [STANDARDS-TRACK]

 draft-ietf-ftpext-mlst-16 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext http://www.rfc-editor.org/errata_search.php?rfc=3659 10.17487/RFC3659 RFC3660 Basic Media Gateway Control Protocol (MGCP) Packages B. Foster F. Andreasen December 2003 ASCII HTML 64 generic line trunk handset dtmf dual tone multifrequency

This document provides a basic set of Media Gateway Control Protocol (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF (Dual Tone Multifrequency), announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages.

 draft-foster-mgcp-basic-packages-10 RFC2705 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3660 RFC3661 Media Gateway Control Protocol (MGCP) Return Code Usage B. Foster C. Sivachelvan December 2003 ASCII HTML 24 guidelines call agent implementation

This document provides implementation guidelines for the use of return codes in RFC 3435, Media Gateway Control Protocol (MGCP) Version 1.0. Return codes in RFC 3435 do not cover all possible specific situations that may ever occur in a gateway. That is not possible and not necessary. What is important is to ensure that the Call Agent that receives a return code behaves appropriately and consistently for the given situation. The purpose of this document is to provide implementation guidelines to ensure that consistency.

 draft-foster-mgcp-returncodes-03 RFC3435 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3661 RFC3662 A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services R. Bless K. Nichols K. Wehrle December 2003 ASCII HTML 17 traffic network ds le

This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best-effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic.

 draft-bless-diffserv-pdb-le-01 RFC8622 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3662 RFC3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP) A. Newton December 2003 ASCII HTML 21 LDAP Lightweight Directory Access Protocol referral types well-known

Domain registration data has typically been exposed to the general public via Nicname/Whois for administrative purposes. This document describes the Referral Lightweight Directory Access Protocol (LDAP) Service, an experimental service using LDAP and well-known LDAP types to make domain administrative data available.

 draft-newton-ldap-whois-03 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3663 RFC3664 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) P. Hoffman January 2004 ASCII HTML 4 IKE Internet Key Exchange Protocol ipsec IP Security AES advanced encryption standard mac message authentication code

Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128.

 draft-ietf-ipsec-aes-xcbc-prf-01 RFC4434 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3664 RFC3665 Session Initiation Protocol (SIP) Basic Call Flow Examples A. Johnston S. Donovan R. Sparks C. Cunningham K. Summers December 2003 ASCII HTML 94 user agent client proxy redirect

This document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. Call flow diagrams and message details are shown.

 draft-ietf-sipping-basic-call-flows-02 BCP0075 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3665 10.17487/RFC3665 RFC3666 Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows A. Johnston S. Donovan R. Sparks C. Cunningham K. Summers December 2003 ASCII HTML 118 user proxy gateway telephony

This document contains best current practice examples of Session Initiation Protocol (SIP) call flows showing interworking with the Public Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown.

 draft-ietf-sipping-pstn-call-flows-02 BCP0076 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3666 10.17487/RFC3666 RFC3667 IETF Rights in Contributions S. Bradner February 2004 ASCII HTML 18 intellectual property rights copyright ipr

The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ipr-submission-rights-08 RFC3978 RFC2026 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC3667 RFC3668 Intellectual Property Rights in IETF Technology S. Bradner February 2004 ASCII HTML 17 ipr copyright

The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ipr-technology-rights-12 RFC3979 RFC2026 RFC2028 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC3668 RFC3669 Guidelines for Working Groups on Intellectual Property Issues S. Brim February 2004 ASCII HTML 17 ipr copyright

This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues. It documents specific examples of how IPR issues have been dealt with in the IETF. This memo provides information for the Internet community.

 draft-ietf-ipr-wg-guidelines-05 INFORMATIONAL INFORMATIONAL IETF gen ipr 10.17487/RFC3669 RFC3670 Information Model for Describing Network Device QoS Datapath Mechanisms B. Moore D. Durham J. Strassner A. Westerinen W. Weiss January 2004 ASCII HTML 97 QoS quality of service host network devices traffic

The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services. This document should be used with the QoS Policy Information Model (QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices. This document, as well as QPIM, are information models. That is, they represent information independent of a binding to a specific type of repository

 draft-ietf-policy-qos-device-info-model-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3670 RFC3671 Collective Attributes in the Lightweight Directory Access Protocol (LDAP) K. Zeilenga December 2003 ASCII HTML 10 x.500 information model schema

X.500 collective attributes allow common characteristics to be shared between collections of entries. This document summarizes the X.500 information model for collective attributes and describes use of collective attributes in LDAP (Lightweight Directory Access Protocol). This document provides schema definitions for collective attributes for use in LDAP.

 draft-zeilenga-ldap-collective-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3671 RFC3672 Subentries in the Lightweight Directory Access Protocol (LDAP) K. Zeilenga December 2003 ASCII HTML 12 special subtree

In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with the Lightweight Directory Access Protocol (LDAP).

 draft-zeilenga-ldap-subentry-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3672 RFC3673 Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes K. Zeilenga December 2003 ASCII HTML 5 user mechanisms extension

The Lightweight Directory Access Protocol (LDAP) supports a mechanism for requesting the return of all user attributes but not all operational attributes. This document describes an LDAP extension which clients may use to request the return of all operational attributes.

 draft-zeilenga-ldap-opattrs-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3673 RFC3674 Feature Discovery in Lightweight Directory Access Protocol (LDAP) K. Zeilenga December 2003 ASCII HTML 5 elective extensions mechanisms

The Lightweight Directory Access Protocol (LDAP) is an extensible protocol with numerous elective features. This document introduces a general mechanism for discovery of elective features and extensions which cannot be discovered using existing mechanisms.

 draft-zeilenga-ldap-features-05 RFC4512 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3674 RFC3675 .sex Considered Dangerous D. Eastlake 3rd February 2004 ASCII HTML 22 top level domains tld ip addresses internet protocol filters

Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view.

 draft-eastlake-xxx-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3675 RFC3676 The Text/Plain Format and DelSp Parameters R. Gellens February 2004 ASCII HTML 20 media type mime multipurpose internet mail extension

This specification establishes two parameters (Format and DelSP) to be used with the Text/Plain media type. In the presence of these parameters, trailing whitespace is used to indicate flowed lines and a canonical quote indicator is used to indicate quoted lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain, yet provides for superior wrapping/flowing, and quoting. This document supersedes the one specified in RFC 2646, "The Text/Plain Format Parameter", and adds the DelSp parameter to accommodate languages/coded character sets in which ASCII spaces are not used or appear rarely. [STANDARDS-TRACK]

 draft-gellens-format-bis-04 RFC2646 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3676 RFC3677 IETF ISOC Board of Trustee Appointment Procedures L. Daigle Editor Internet Architecture Board December 2003 ASCII HTML 7 IETF Internet Engineering Task Force ISOC Internet Society Board of Trustees

This memo outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment.

 draft-iab-isocbot-01 BCP0077 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB http://www.rfc-editor.org/errata_search.php?rfc=3677 10.17487/RFC3677 RFC3678 Socket Interface Extensions for Multicast Source Filters D. Thaler B. Fenner B. Quinn January 2004 ASCII HTML 18 ip internet protocol application program interface apis input output

The Internet Group Management Protocol (IGMPv3) for IPv4 and the Multicast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications. This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs). These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications.

 draft-ietf-magma-msf-api-05 INFORMATIONAL INFORMATIONAL IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=3678 10.17487/RFC3678 RFC3679 Unused Dynamic Host Configuration Protocol (DHCP) Option Codes R. Droms January 2004 ASCII HTML 8 dynamic host configuration protocol internet assigned numbers authority

Prior to the publication of RFC 2489 (which was updated by RFC 2939), several option codes were assigned to proposed Dynamic Host Configuration Protocol (DHCP) options that were subsequently never used. This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future. The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options.

 draft-ietf-dhc-unused-optioncodes-07 RFC8910 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC3679 RFC3680 A Session Initiation Protocol (SIP) Event Package for Registrations J. Rosenberg March 2004 ASCII HTML 26 SIP Session Initiation Protocol REGISTER event package name event package parameters

This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications. [STANDARDS-TRACK]

 draft-ietf-sipping-reg-event-00 RFC6140 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3680 10.17487/RFC3680 RFC3681 Delegation of E.F.F.3.IP6.ARPA R. Bush R. Fink January 2004 ASCII HTML 4 dns domain name system

This document discusses the need for delegation of the E.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for 6bone addresses, and makes specific recommendations for the process needed to accomplish this.

 draft-ymbk-6bone-arpa-delegation-01 BCP0080 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3681 RFC3682 The Generalized TTL Security Mechanism (GTSM) V. Gill J. Heasley D. Meyer February 2004 ASCII HTML 11 time to live packet hop limit

The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP), Bidirectional Forwarding Detection, and Label Distribution Protocol (LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis. This memo defines an Experimental Protocol for the Internet community.

 draft-gill-gtsh-04 RFC5082 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3682 RFC3683 A Practice for Revoking Posting Rights to IETF Mailing Lists M. Rose March 2004 ASCII HTML 13

All self-governing bodies have ways of managing the scope of participant interaction. The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion. An important part of this consensus-driven process is the pervasive use of mailing lists for discussion. Notably, in a small number of cases, a participant has engaged in a "denial-of-service" attack to disrupt the consensus-driven process. Regrettably, as these bad faith attacks become more common, the IETF needs to establish a practice that reduces or eliminates these attacks. This memo recommends such a practice for use by the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-mrose-ietf-posting-04 RFC9245 BCP0083 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3683 RFC3684 Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) R. Ogier F. Templin M. Lewis February 2004 ASCII HTML 46 TBRPF Topology Dissemination Based on Reverse-Path Forwarding proactive routing ad-hoc networks neighbor discovery link-state routing mobile ad-hoc network mobile mesh network packet radio network wireless communications

Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-manet-tbrpf-11 RFC9141 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC3684 RFC3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions C. Daboo February 2004 ASCII HTML 9 messages portable commands

The SIEVE mail filtering language "spamtest" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests. [PROPOSED STANDARD]

 draft-daboo-sieve-spamtest-04 RFC5235 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3685 RFC3686 Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP) R. Housley January 2004 ASCII HTML 19 AES Advanced Encryption Standard IPsec Internet Protocol Security ESP Encapsulating Security Payload authentication vector cipher block

This document describes the use of Advanced Encryption Standard (AES) Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism.

 draft-ietf-ipsec-ciph-aes-ctr-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3686 RFC3687 Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules S. Legg February 2004 ASCII HTML 42 syntax data schema

The syntaxes of attributes in a Lightweight Directory Access Protocol (LDAP) or X.500 directory range from simple data types, such as text string, integer, or boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes. Matching rules defined for the complex syntaxes usually only provide the most immediately useful matching capability. This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax. [PROPOSED STANDARD]

 draft-legg-ldapext-component-matching-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3687 RFC3688 The IETF XML Registry M. Mealling January 2004 ASCII HTML 8 XML extensible markup language

This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.

 draft-mealling-iana-xmlns-registry-05 BCP0081 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3688 RFC3689 General Requirements for Emergency Telecommunication Service (ETS) K. Carlberg R. Atkinson February 2004 ASCII HTML 10

This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). This memo provides information for the Internet community.

 draft-ietf-ieprep-ets-general-04 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3689 RFC3690 IP Telephony Requirements for Emergency Telecommunication Service (ETS) K. Carlberg R. Atkinson February 2004 ASCII HTML 7

This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. This memo provides information for the Internet community.

 draft-ietf-ieprep-ets-telephony-07 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3690 RFC3691 Internet Message Access Protocol (IMAP) UNSELECT command A. Melnikov February 2004 ASCII HTML 5 IMAP Internet Message Access Protocol mailbox session client

This document defines an UNSELECT command that can be used to close the current mailbox in an Internet Message Access Protocol - version 4 (IMAP4) session without expunging it. Certain types of IMAP clients need to release resources associated with the selected mailbox without selecting a different mailbox. While IMAP4 provides this functionality (via a SELECT command with a nonexistent mailbox name or reselecting the same mailbox with EXAMINE command), a more clean solution is desirable. [STANDARDS-TRACK]

 draft-melnikov-imap-unselect-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3691 RFC3692 Assigning Experimental and Testing Numbers Considered Useful T. Narten January 2004 ASCII HTML 7 IANA Internet Assigned Numbers Authority values implementations

When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.

 draft-narten-iana-experimental-allocations-05 RFC2434 BCP0082 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3692 RFC3693 Geopriv Requirements J. Cuellar J. Morris D. Mulligan J. Peterson J. Polk February 2004 ASCII HTML 30 security privacy lo location object

Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved. This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data. This memo provides information for the Internet community.

 draft-ietf-geopriv-reqs-04 RFC6280 RFC7459 INFORMATIONAL INFORMATIONAL IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=3693 10.17487/RFC3693 RFC3694 Threat Analysis of the Geopriv Protocol M. Danley D. Mulligan J. Morris J. Peterson February 2004 ASCII HTML 18 privacy security data information

This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements. This memo provides information for the Internet community.

 draft-ietf-geopriv-threat-analysis-01 RFC6280 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC3694 RFC3695 Compact Forward Error Correction (FEC) Schemes M. Luby L. Vicisano February 2004 ASCII HTML 13 FEC Forward Error Correction content stream delivery multicast internet protocol compact schemes

This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FEC Payload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead. This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-bb-fec-supp-compact-01 RFC5445 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3695 RFC3696 Application Techniques for Checking and Transformation of Names J. Klensin February 2004 ASCII HTML 16 top-level domains tlds

Many Internet applications have been designed to deduce top-level domains (or other domain name labels) from partial information. The introduction of new top-level domains, especially non-country-code ones, has exposed flaws in some of the methods used by these applications. These flaws make it more difficult, or impossible, for users of the applications to access the full Internet. This memo discusses some of the techniques that have been used and gives some guidance for minimizing their negative impact as the domain name environment evolves. This document draws summaries of the applicable rules together in one place and supplies references to the actual standards. This memo provides information for the Internet community.

 draft-klensin-name-filters-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3696 10.17487/RFC3696 RFC3697 IPv6 Flow Label Specification J. Rajahalme A. Conta B. Carpenter S. Deering March 2004 ASCII HTML 9 IPv6 Flow Label nodes packets

This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]

 draft-ietf-ipv6-flow-label-09 RFC6437 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3697 RFC3698 Lightweight Directory Access Protocol (LDAP): Additional Matching Rules K. Zeilenga Editor February 2004 ASCII HTML 9 LDAP lightweight directory access protocol directory services

This document provides a collection of matching rules for use with the Lightweight Directory Access Protocol (LDAP). As these matching rules are simple adaptations of matching rules specified for use with the X.500 Directory, most are already in wide use. [STANDARDS-TRACK]

 draft-zeilenga-ldap-user-schema-mr-00 RFC2798 RFC4517 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3698 RFC3699 RFC3700 Internet Official Protocol Standards J. Reynolds Editor S. Ginoza Editor July 2004 ASCII HTML 54 Official Protocols

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 22, 2004. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. [STANDARDS-TRACK]

 RFC3600 RFC5000 HISTORIC INTERNET STANDARD INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3700 10.17487/RFC3700 RFC3701 6bone (IPv6 Testing Address Allocation) Phaseout R. Fink R. Hinden March 2004 ASCII HTML 6 internet protocol protocotype software architecture

The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to enable various IPv6 testing as well as to assist in the transitioning of IPv6 into the Internet. It operates under the IPv6 address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its production deployment it is appropriate to plan for the phaseout of the 6bone. This document establishes a plan for a multi-year phaseout of the 6bone and its address allocation on the assumption that the IETF is the appropriate place to determine this. This document obsoletes RFC 2471, "IPv6 Testing Address Allocation", December, 1998. RFC 2471 will become historic. This memo provides information for the Internet community.

 draft-fink-6bone-phaseout-04 RFC2471 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3701 RFC3702 Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP) J. Loughney G. Camarillo February 2004 ASCII HTML 15

As Session Initiation Protocol (SIP) services are deployed on the Internet, there is a need for authentication, authorization, and accounting of SIP sessions. This document sets out the basic requirements for this work. This memo provides information for the Internet community.

 draft-ietf-sipping-aaa-req-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3702 RFC3703 Policy Core Lightweight Directory Access Protocol (LDAP) Schema J. Strassner B. Moore R. Moats E. Ellesson February 2004 ASCII HTML 61 LDAP Lightweight Directory Access Protocol Policy Core mapping classes

This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that uses Lightweight Directory Access Protocol (LDAP) as its access protocol. This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC 3060, and relationship classes that indicate how instances of the structural classes are related to each other. Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information. These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them. [STANDARDS-TRACK]

 draft-ietf-policy-core-schema-16 RFC4104 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3703 RFC3704 Ingress Filtering for Multihomed Networks F. Baker P. Savola March 2004 ASCII HTML 16 ISP Internet Service Provider Internet Protocol DOS Denial of Service

BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-savola-bcp38-multihoming-update-03 RFC2827 RFC8704 BCP0084 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3704 RFC3705 High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals B. Ray R. Abbi February 2004 ASCII HTML 11 MIB Management Information Base High Capacity Textual Conventions

This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals. The Textual Conventions defined in this document extend the conventions presented in RFC 3593 to 64 bit resolution using the conventions presented in RFC 2856. [STANDARDS-TRACK]

 draft-ietf-adslmib-hc-tc-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC3705 RFC3706 A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers G. Huang S. Beaulieu D. Rochefort February 2004 ASCII HTML 13 security authentication dead peer detection dpd keepalive

This document describes the method detecting a dead Internet Key Exchange (IKE) peer that is presently in use by a number of vendors. The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to minimize the number of IKE messages that are needed to confirm liveness. DPD, like other keepalive mechanisms, is needed to determine when to perform IKE peer failover, and to reclaim lost resources. This memo provides information for the Internet community.

 draft-ietf-ipsec-dpd-04 INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=3706 10.17487/RFC3706 RFC3707 Cross Registry Internet Service Protocol (CRISP) Requirements A. Newton February 2004 ASCII HTML 26 directory services domain

Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries. This memo provides information for the Internet community.

 draft-ietf-crisp-requirements-06 INFORMATIONAL INFORMATIONAL IETF app crisp 10.17487/RFC3707 RFC3708 Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions E. Blanton M. Allman February 2004 ASCII HTML 9 DSACK Duplicate Selective Acknowledgement SCTP Stream Control Transmission Protocol TSN Transmission Sequence Number

TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate Selective Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number (TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tsvwg-dsack-use-02 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3708 RFC3709 Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates S. Santesson R. Housley T. Freeman February 2004 ASCII HTML 21 X.509 Public Key Infrastructure authentication security identification certificates

This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. [STANDARDS-TRACK]

 draft-ietf-pkix-logotypes-13 RFC6170 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3709 10.17487/RFC3709 RFC3710 An IESG charter H. Alvestrand February 2004 ASCII HTML 12 internet engineering steering group

This memo provides a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). It is meant to document the charter of the IESG as it is presently understood. This memo provides information for the Internet community.

 draft-iesg-charter-03 RFC3932 RFC5742 RFC8717 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC3710 RFC3711 The Secure Real-time Transport Protocol (SRTP) M. Baugher D. McGrew M. Naslund E. Carrara K. Norrman March 2004 ASCII HTML 56 SRTP Secure Real-time Transport Protocol authentication traffic cryptographic

This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]

 draft-ietf-avt-srtp-09 RFC5506 RFC6904 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3711 10.17487/RFC3711 RFC3712 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services P. Fleming I. McDonald February 2004 ASCII HTML 33 object classes attributes

This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that support Lightweight Directory Access Protocol v3 (LDAP-TS). This document is based on the printer attributes listed in Appendix E of Internet Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759). This memo provides information for the Internet community.

 draft-fleming-ldap-printer-schema-02 RFC7612 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3712 10.17487/RFC3712 RFC3713 A Description of the Camellia Encryption Algorithm M. Matsui J. Nakajima S. Moriai April 2004 ASCII HTML 15 security key cryptographic

This document describes the Camellia encryption algorithm. Camellia is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The algorithm description is presented together with key scheduling part and data randomizing part. This memo provides information for the Internet community.

 draft-nakajima-camellia-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3713 RFC3714 IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet S. Floyd Editor J. Kempf Editor March 2004 ASCII HTML 32 end-to-end qos qualify of service voip internet protocol

This document discusses IAB concerns about effective end-to-end congestion control for best-effort voice traffic in the Internet. These concerns have to do with fairness, user quality, and with the dangers of congestion collapse. The concerns are particularly relevant in light of the absence of a widespread Quality of Service (QoS) deployment in the Internet, and the likelihood that this situation will not change much in the near term. This document is not making any recommendations about deployment paths for Voice over Internet Protocol (VoIP) in terms of QoS support, and is not claiming that best-effort service can be relied upon to give acceptable performance for VoIP. We are merely observing that voice traffic is occasionally deployed as best-effort traffic over some links in the Internet, that we expect this occasional deployment to continue, and that we have concerns about the lack of effective end-to-end congestion control for this best-effort voice traffic. This memo provides information for the Internet community.

 draft-iab-congestion-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3714 RFC3715 IPsec-Network Address Translation (NAT) Compatibility Requirements B. Aboba W. Dixon March 2004 ASCII HTML 18 virtual private networks vpns intranet

This document describes known incompatibilities between Network Address Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses. This memo provides information for the Internet community.

 draft-ietf-ipsec-nat-reqts-06 INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=3715 10.17487/RFC3715 RFC3716 IETF in the Large: Administration and Execution IAB Advisory Committee March 2004 ASCII HTML 40

In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB Advisory Committee (AdvComm), with a mandate to review the existing IETF administrative structure and relationships (RFC Editor, IETF Secretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF. The AdvComm mandate did not include the standards process itself. This memo provides information for the Internet community.

 draft-iab-advcomm-01 HISTORIC INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=3716 10.17487/RFC3716 RFC3717 IP over Optical Networks: A Framework B. Rajagopalan J. Luciani D. Awduche March 2004 ASCII HTML 48 transport infrastructure routers high-speed

The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. The architectural choices for the interaction between IP and optical network layers, specifically, the routing and signaling aspects, are maturing. At the same time, a consensus has emerged in the industry on utilizing IP-based protocols for the optical control plane. This document defines a framework for IP over Optical networks, considering both the IP-based control plane for optical networks as well as IP-optical network interactions (together referred to as "IP over optical networks"). This memo provides information for the Internet community.

 draft-ietf-ipo-framework-05 INFORMATIONAL INFORMATIONAL IETF subip ipo 10.17487/RFC3717 RFC3718 A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access R. McGowan February 2004 ASCII HTML 11

This memo describes various internal workings of the Unicode Consortium for the benefit of participants in the IETF. It is intended solely for informational purposes. Included are discussions of how the decision-making bodies of the Consortium work and their procedures, as well as information on public access to the character encoding & standardization processes.

 draft-rmcgowan-unicode-procs-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3718 RFC3719 Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS) J. Parker Editor February 2004 ASCII HTML 15 routing routeing interior gateway protocol igp conformance ip traffic

This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol as described in ISO 10589 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol. A companion document discusses differences between the protocol described in RFC 1195 and the protocol as it is deployed today for routing IP traffic. This memo provides information for the Internet community.

 draft-ietf-isis-iso-interoperable-02 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3719 RFC3720 Internet Small Computer Systems Interface (iSCSI) J. Satran K. Meth C. Sapuntzakis M. Chadalapaka E. Zeidner April 2004 ASCII HTML 257 iSCSI Internet Small Computer Systems Interface transport protocol tcp transmission control protocol

This document describes a transport protocol for Internet Small Computer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model. SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.). As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to "carry" SCSI. [STANDARDS-TRACK]

 draft-ietf-ips-iscsi-20 RFC7143 RFC3980 RFC4850 RFC5048 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=3720 10.17487/RFC3720 RFC3721 Internet Small Computer Systems Interface (iSCSI) Naming and Discovery M. Bakke J. Hafner J. Hufferd K. Voruganti M. Krueger April 2004 ASCII HTML 22 targets environments scalibilty target initiator scsi device name

This document provides examples of the Internet Small Computer Systems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. This memo provides information for the Internet community.

 draft-ietf-ips-iscsi-name-disc-10 RFC7143 INFORMATIONAL INFORMATIONAL IETF tsv ips 10.17487/RFC3721 RFC3722 String Profile for Internet Small Computer Systems Interface (iSCSI) Names M. Bakke April 2004 ASCII HTML 8 iSCSI Internet Small Computer Systems Interface transport unique global

This document describes how to prepare internationalized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world. The Internet Small Computer Systems Interface (iSCSI) protocol provides a way for hosts to access SCSI devices over an IP network. The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared. [STANDARDS-TRACK]

 draft-ietf-ips-iscsi-string-prep-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3722 RFC3723 Securing Block Storage Protocols over IP B. Aboba J. Tseng J. Walker V. Rangan F. Travostino April 2004 ASCII HTML 70 internet threat models performance security

This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small Computer System Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (Internet Storage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed. [STANDARDS-TRACK]

 draft-ietf-ips-security-19 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3723 RFC3724 The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture J. Kempf Editor R. Austein Editor IAB March 2004 ASCII HTML 14 architectural guideline

The end-to-end principle is the core architectural guideline of the Internet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends. This memo provides information for the Internet community.

 draft-iab-e2e-futures-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3724 RFC3725 Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) J. Rosenberg J. Peterson H. Schulzrinne G. Camarillo April 2004 ASCII HTML 31 3pcc Third Party Call Control SIP Session Initiation Protocol

Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sipping-3pcc-06 BCP0085 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC3725 RFC3726 Requirements for Signaling Protocols M. Brunner Editor April 2004 ASCII HTML 42 rsvp resource reservation protocol middleboxes nsis

This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP). However, in recent years, several other applications of signaling have been defined. For example, signaling for label distribution in Multiprotocol Label Switching (MPLS) or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. This memo provides information for the Internet community.

 draft-ietf-nsis-req-09 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC3726 RFC3727 ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules S. Legg February 2004 ASCII HTML 5 LDAP lightweight directory access protocol X.500

This document updates the specification of the component matching rules for Lightweight Directory Access Protocol (LDAP) and X.500 directories (RFC3687) by collecting the Abstract Syntax Notation One (ASN.1) definitions of the component matching rules into an appropriately identified ASN.1 module so that other specifications may reference the component matching rule definitions from within their own ASN.1 modules. [STANDARDS-TRACK]

 draft-legg-ldap-cmr-module-00 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3727 RFC3728 Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) B. Ray R. Abbi February 2004 ASCII HTML 76 Management Information Base MIB VDSL Very High Speed Digital Subscriber Lines

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing Very High Speed Digital Subscriber Line (VDSL) interfaces. [STANDARDS-TRACK]

 draft-ietf-adslmib-vdsl-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=3728 10.17487/RFC3728 RFC3729 Application Performance Measurement MIB S. Waldbusser March 2004 ASCII HTML 61 MIB Management Information Base application performance

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for measuring the application performance as experienced by end-users. [STANDARDS-TRACK]

 draft-ietf-rmonmib-apm-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3729 RFC3730 Extensible Provisioning Protocol (EPP) S. Hollenbeck March 2004 ASCII HTML 69 shared framework mapping

This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. [STANDARDS-TRACK]

 draft-ietf-provreg-epp-09 RFC4930 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg http://www.rfc-editor.org/errata_search.php?rfc=3730 10.17487/RFC3730 RFC3731 Extensible Provisioning Protocol (EPP) Domain Name Mapping S. Hollenbeck March 2004 ASCII HTML 45 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. [STANDARDS-TRACK]

 draft-ietf-provreg-epp-domain-07 RFC4931 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg 10.17487/RFC3731 RFC3732 Extensible Provisioning Protocol (EPP) Host Mapping S. Hollenbeck March 2004 ASCII HTML 28 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. [STANDARDS-TRACK]

 draft-ietf-provreg-epp-host-07 RFC4932 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg 10.17487/RFC3732 RFC3733 Extensible Provisioning Protocol (EPP) Contact Mapping S. Hollenbeck March 2004 ASCII HTML 41 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. [STANDARDS-TRACK]

 draft-ietf-provreg-epp-contact-07 RFC4933 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg http://www.rfc-editor.org/errata_search.php?rfc=3733 10.17487/RFC3733 RFC3734 Extensible Provisioning Protocol (EPP) Transport Over TCP S. Hollenbeck March 2004 ASCII HTML 9 mapping client server tls transport layer security

This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. [STANDARDS-TRACK]

 draft-ietf-provreg-epp-tcp-06 RFC4934 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg 10.17487/RFC3734 RFC3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP) S. Hollenbeck March 2004 ASCII HTML 13

The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document presents guidelines for use of EPP's extension mechanisms to define new features and object management capabilities. This memo provides information for the Internet community.

 draft-ietf-provreg-epp-ext-03 INFORMATIONAL INFORMATIONAL IETF app provreg 10.17487/RFC3735 RFC3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 R. Droms April 2004 ASCII HTML 9 DHCP Dynamic Host Configuration Protocol IPv6

Stateless Dynamic Host Configuration Protocol service for IPv6 (DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-stateless-04 RFC8415 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3736 10.17487/RFC3736 RFC3737 IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules B. Wijnen A. Bierman April 2004 ASCII HTML 7 MIB Management Information Base IANA Internet Assigned Numbers Authority RMON Registry of Remote Monitoring

This document defines the procedures for IANA to administer and maintain the Object Identifier (OID) tree under the Remote Monitoring (rmon) root. This memo also documents the currently assigned values. [STANDARDS-TRACK]

 draft-ietf-rmonmib-rmon-oid-assignments-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3737 RFC3738 Wave and Equation Based Rate Control (WEBRC) Building Block M. Luby V. Goyal April 2004 ASCII HTML 32 WEBRC Wave and Equation Based Rate Control congestion control data delivery multicast ip internet protocol

This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery. WEBRC is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender. Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-bb-webrc-04 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3738 RFC3739 Internet X.509 Public Key Infrastructure: Qualified Certificates Profile S. Santesson M. Nystrom T. Polk March 2004 ASCII HTML 34 X.509 Public Key Infrastructure syntax

This document forms a certificate profile, based on RFC 3280, for identity certificates issued to natural persons. The profile defines specific conventions for certificates that are qualified within a defined legal framework, named Qualified Certificates. However, the profile does not define any legal requirements for such Qualified Certificates. The goal of this document is to define a certificate profile that supports the issuance of Qualified Certificates independent of local legal requirements. The profile is however not limited to Qualified Certificates and further profiling may facilitate specific local needs. [STANDARDS-TRACK]

 draft-ietf-pkix-sonof3039-06 RFC3039 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3739 10.17487/RFC3739 RFC3740 The Multicast Group Security Architecture T. Hardjono B. Weis March 2004 ASCII HTML 26 data packets

This document provides an overview and rationale of the multicast security architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast Security Reference Framework, and proceeds to identify the security services that may be part of a secure multicast solution. This memo provides information for the Internet community.

 draft-ietf-msec-arch-05 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC3740 RFC3741 Exclusive XML Canonicalization, Version 1.0 J. Boyer D. Eastlake 3rd J. Reagle March 2004 ASCII HTML 16 extensible markup language namespace

Canonical XML specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the "xml:" namespace. However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument. For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context. This requirement is satisfied by Exclusive XML Canonicalization. This memo provides information for the Internet community.

 draft-ietf-xmldsig-xc14n-02 INFORMATIONAL INFORMATIONAL IETF sec xmldsig http://www.rfc-editor.org/errata_search.php?rfc=3741 10.17487/RFC3741 RFC3742 Limited Slow-Start for TCP with Large Congestion Windows S. Floyd March 2004 ASCII HTML 7 TCP transmission control protocol congestion

This document describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describes Limited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tsvwg-slowstart-00 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3742 10.17487/RFC3742 RFC3743 Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean K. Konishi K. Huang H. Qian Y. Ko April 2004 ASCII HTML 33

Achieving internationalized access to domain names raises many complex issues. These are associated not only with basic protocol design, such as how names are represented on the network, compared, and converted to appropriate forms, but also with issues and options for deployment, transition, registration, and administration. The IETF Standards for Internationalized Domain Names, known as "IDNA", focuses on access to domain names in a range of scripts that is broader in scope than the original ASCII. The development process made it clear that use of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition. The conclusion was that, while those issues were important, they could best be addressed administratively rather than through restrictions embedded in the protocols. This document defines a set of guidelines for applying restrictions of that type for Chinese, Japanese and Korean (CJK) scripts and the zones that use them and, perhaps, the beginning of a framework for thinking about other zones, languages, and scripts. This memo provides information for the Internet community.

 draft-jseng-idn-admin-05 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3743 10.17487/RFC3743 RFC3744 Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol G. Clemm J. Reschke E. Sedlar J. Whitehead May 2004 ASCII HTML 72 WebDAV Web Distributed Authoring and Versioning Access Control

This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names. [STANDARDS-TRACK]

 draft-ietf-webdav-acl-13 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav http://www.rfc-editor.org/errata_search.php?rfc=3744 10.17487/RFC3744 RFC3745 MIME Type Registrations for JPEG 2000 (ISO/IEC 15444) D. Singer R. Clark D. Lee April 2004 ASCII HTML 14 MIME multipurpose internet mail extensions JPEG joint photographic experts group

This document serves to register and document the standard MIME types associated with the ISO/IEC 15444 standards, commonly known as JPEG 2000 (Joint Photographic Experts Group). [STANDARDS-TRACK]

 draft-singer-jp2-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3745 RFC3746 Forwarding and Control Element Separation (ForCES) Framework L. Yang R. Dantu T. Anderson R. Gopal April 2004 ASCII HTML 40 network elements

This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and their interactions. This is memo provides information for the Internet community.

 draft-ietf-forces-framework-13 INFORMATIONAL INFORMATIONAL IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=3746 10.17487/RFC3746 RFC3747 The Differentiated Services Configuration MIB H. Hazewinkel Editor D. Partain Editor April 2004 ASCII HTML 24 MIB management information base diffserv differentiated services

This memo describes a MIB module that provides a conceptual layer between high-level "network-wide" policy definitions that effect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring differentiated services at a conceptually higher layer than that of the Differentiated Services MIB. [PROPOSED STANDARD]

 draft-ietf-snmpconf-diffpolicy-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpconf 10.17487/RFC3747 RFC3748 Extensible Authentication Protocol (EAP) B. Aboba L. Blunk J. Vollbrecht J. Carlson H. Levkowetz Editor June 2004 ASCII HTML 67 PPP-EAP Extensible Authentication Protocol data link layers point-to-point ieee 802

This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]

 draft-ietf-eap-rfc2284bis-09 RFC2284 RFC5247 RFC7057 PROPOSED STANDARD PROPOSED STANDARD IETF int eap http://www.rfc-editor.org/errata_search.php?rfc=3748 10.17487/RFC3748 RFC3749 Transport Layer Security Protocol Compression Methods S. Hollenbeck May 2004 ASCII HTML 8 TLS Transport Layer Security lossless data compression handshake protocol

The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods. [STANDARDS-TRACK]

 draft-ietf-tls-compression-07 RFC8447 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC3749 RFC3750 Unmanaged Networks IPv6 Transition Scenarios C. Huitema R. Austein S. Satapati R. van der Pol April 2004 ASCII HTML 20 single subnet gateway isp internet service provider

This document defines the scenarios in which IPv6 transition mechanisms are to be used in unmanaged networks. In order to evaluate the suitability of these mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged network", which typically corresponds to a home or small office network. The scenarios are specific to a single subnet, and are defined in terms of IP connectivity supported by the gateway and the Internet Service Provider (ISP). We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6. This memo provides information for the Internet community.

 draft-ietf-v6ops-unman-scenarios-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3750 RFC3751 Omniscience Protocol Requirements S. Bradner April 1 2004 ASCII HTML 9

There have been a number of legislative initiatives in the U.S. and elsewhere over the past few years to use the Internet to actively interfere with allegedly illegal activities of Internet users. This memo proposes a number of requirements for a new protocol, the Omniscience Protocol, that could be used to enable such efforts. This memo provides information for the Internet community.

 draft-bradner-op-req-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3751 RFC3752 Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios A. Barbir E. Burger R. Chen S. McHenry H. Orman R. Penno April 2004 ASCII HTML 14 application data services

This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses. This memo provides information for the Internet community.

 draft-ietf-opes-scenarios-01 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3752 RFC3753 Mobility Related Terminology J. Manner Editor M. Kojo Editor June 2004 ASCII HTML 36 networks ip internet protocol

There is a need for common definitions of terminology in the work to be done around IP mobility. This document defines terms for mobility related terminology. The document originated out of work done in the Seamoby Working Group but has broader applicability for terminology used in IETF-wide discourse on technology for mobility and IP networks. Other working groups dealing with mobility may want to take advantage of this terminology. This memo provides information for the Internet community.

 draft-ietf-seamoby-mobility-terminology-06 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3753 RFC3754 IP Multicast in Differentiated Services (DS) Networks R. Bless K. Wehrle April 2004 ASCII HTML 34 internet protocol

This document discusses the problems of IP Multicast use in Differentiated Services (DS) networks, expanding on the discussion in RFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results. This memo provides information for the Internet community.

 draft-bless-diffserv-multicast-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3754 RFC3755 Legacy Resolver Compatibility for Delegation Signer (DS) S. Weiler May 2004 ASCII HTML 9 dnssec DNS Security rr resource record DNS-SECEXT dns authentication nsec nextsecure

As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-2535typecode-change-06 RFC4033 RFC4034 RFC4035 RFC3658 RFC2535 RFC3757 RFC3845 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3755 RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats P. Nikander Editor J. Kempf E. Nordmark May 2004 ASCII HTML 23 authentication security key management

The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery. This memo provides information for the Internet community.

 draft-ietf-send-psreq-04 INFORMATIONAL INFORMATIONAL IETF int send http://www.rfc-editor.org/errata_search.php?rfc=3756 10.17487/RFC3756 RFC3757 Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag O. Kolkman J. Schlyter E. Lewis April 2004 ASCII HTML 8 dnssec

With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the Domain Name System KEY (DNSKEY) resource record set. A flag bit in the DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3755. [STANDARDS-TRACK]

 draft-ietf-dnsext-keyrr-key-signing-flag-12 RFC4033 RFC4034 RFC4035 RFC3755 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3757 10.17487/RFC3757 RFC3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension R. Stewart M. Ramalho Q. Xie M. Tuexen P. Conrad May 2004 ASCII HTML 22 SCTP Stream Control Transmission Protocol init init ack forward tsn

This memo describes an extension to the Stream Control Transmission Protocol (SCTP) that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one example of a partially reliable service that can be provided to the upper layer via this mechanism. [STANDARDS-TRACK]

 draft-ietf-tsvwg-prsctp-03 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3758 RFC3759 RObust Header Compression (ROHC): Terminology and Channel Mapping Examples L-E. Jonsson April 2004 ASCII HTML 20 encapsulating security payload real-time transport protocol user datagram

This document aims to clarify terms and concepts presented in RFC 3095. RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms, like network elements and IP interfaces, commonly used, for example, when addressing MIB issues. This memo provides information for the Internet community.

 draft-ietf-rohc-terminology-and-examples-02 RFC3095 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3759 RFC3760 Securely Available Credentials (SACRED) - Credential Server Framework D. Gustafson M. Just M. Nystrom April 2004 ASCII HTML 22

As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This document responds to the requirements on protocols for secure exchange of credentials listed in RFC 3157, by presenting an abstract protocol framework. This memo provides information for the Internet community.

 draft-ietf-sacred-framework-07 INFORMATIONAL INFORMATIONAL IETF sec sacred 10.17487/RFC3760 RFC3761 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) P. Faltstrom M. Mealling April 2004 ASCII HTML 18 E.164 URI Uniform Resource Identifier DDDS Dynamic Delegation Discovery System DNS domain name system

This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. [STANDARDS-TRACK]

 draft-ietf-enum-rfc2916bis-07 RFC2916 RFC6116 RFC6117 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3761 RFC3762 Telephone Number Mapping (ENUM) Service Registration for H.323 O. Levin April 2004 ASCII HTML 5 ENUM Telephone Number Mapping multimedia packet based network

The H.323 specification defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers a Telephone Number Mapping (ENUM) service for H.323 according to specifications and guidelines in RFC 3761. [STANDARDS-TRACK]

 draft-ietf-enum-h323-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3762 RFC3763 One-way Active Measurement Protocol (OWAMP) Requirements S. Shalunov B. Teitelbaum April 2004 ASCII HTML 11 performance metrics delay unidirectional

With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. This memo provides information for the Internet community.

 draft-ietf-ippm-owdp-reqs-06 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC3763 RFC3764 enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record J. Peterson April 2004 ASCII HTML 8 SIP Session Initiation Protocol aor Addresses-of-Record electronic number ENUM

This document registers an Electronic Number (ENUM) service for the Session Initiation Protocol (SIP), pursuant to the guidelines in RFC 3761. Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM. [STANDARDS-TRACK]

 draft-ietf-enum-sip-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3764 RFC3765 NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control G. Huston April 2004 ASCII HTML 7 peer connections propagated

This document describes the use of a scope control Border Gateway Protocol (BGP) community. This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections. This memo provides information for the Internet community.

 draft-ietf-ptomaine-nopeer-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3765 RFC3766 Determining Strengths For Public Keys Used For Exchanging Symmetric Keys H. Orman P. Hoffman April 2004 ASCII HTML 23 security cryptography algorithms integers

Implementors of systems that use public key cryptography to exchange symmetric keys need to make the public keys resistant to some predetermined level of attack. That level of attack resistance is the strength of the system, and the symmetric keys that are exchanged must be at least as strong as the system strength requirements. The three quantities, system strength, symmetric key strength, and public key strength, must be consistently matched for any network protocol usage. While it is fairly easy to express the system strength requirements in terms of a symmetric key length and to choose a cipher that has a key length equal to or exceeding that requirement, it is harder to choose a public key that has a cryptographic strength meeting a symmetric key strength requirement. This document explains how to determine the length of an asymmetric key as a function of a symmetric key strength requirement. Some rules of thumb for estimating equivalent resistance to large-scale attacks on various algorithms are given. The document also addresses how changing the sizes of the underlying large integers (moduli, group sizes, exponents, and so on) changes the time to use the algorithms for key exchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-orman-public-key-lengths-08 BCP0086 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3766 RFC3767 Securely Available Credentials Protocol S. Farrell Editor June 2004 ASCII HTML 25 beep blocks extensible exchange protocol xml extensible mark up language

This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration. The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP). [STANDARDS-TRACK]

 draft-ietf-sacred-protocol-bss-09 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec sacred 10.17487/RFC3767 RFC3768 Virtual Router Redundancy Protocol (VRRP) R. Hinden Editor April 2004 ASCII HTML 27 VRRP Virtual Router Redundancy Protocol lan local area network ip internet protocol

This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. [STANDARDS-TRACK]

 draft-ietf-vrrp-spec-v2-10 RFC2338 RFC5798 DRAFT STANDARD DRAFT STANDARD IETF rtg vrrp 10.17487/RFC3768 RFC3769 Requirements for IPv6 Prefix Delegation S. Miyakawa R. Droms June 2004 ASCII HTML 6 internet protocol version 6

This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or "site"). This memo provides information for the Internet community.

 draft-ietf-ipv6-prefix-delegation-requirement-04 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3769 RFC3770 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) R. Housley T. Moore May 2004 ASCII HTML 9 ssid system service identifiers eap

This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). [STANDARDS-TRACK]

 draft-ietf-pkix-wlan-extns-05 RFC4334 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3770 10.17487/RFC3770 RFC3771 The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message R. Harrison K. Zeilenga April 2004 ASCII HTML 8 LDAPv3 LDAv3 x.500

This document defines and describes the IntermediateResponse message, a general mechanism for defining single-request/multiple-response operations in Lightweight Directory Access Protocol (LDAP). The IntermediateResponse message is defined in such a way that the protocol behavior of existing LDAP operations is maintained. This message is intended to be used in conjunction with the LDAP ExtendedRequest and ExtendedResponse to define new single-request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information. [STANDARDS-TRACK]

 draft-rharrison-ldap-intermediate-resp-01 RFC4511 RFC4510 RFC2251 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3771 RFC3772 Point-to-Point Protocol (PPP) Vendor Protocol J. Carlson R. Winslow May 2004 ASCII HTML 10 PPP Point-to-Point link control protocol lcp

The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. The PPP Vendor Extensions document adds vendor-specific general-purpose Configuration Option and Code numbers. This document extends these features to cover vendor-specific Network, Authentication, and Control Protocols. [STANDARDS-TRACK]

 draft-ietf-pppext-vendor-protocol-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3772 RFC3773 High-Level Requirements for Internet Voice Mail E. Candell June 2004 ASCII HTML 9 ivm internet voice messaging voice profile for internet mail vpim

This document describes the high-level requirements for Internet Voice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged. IVM is an extension of the Voice Profile for Internet Mail (VPIM) version 2 designed to support interoperability with desktop clients. Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment. This document does not include goals that were met fully by VPIM version 2. This memo provides information for the Internet community.

 draft-ietf-vpim-ivm-goals-06 INFORMATIONAL INFORMATIONAL IETF app vpim 10.17487/RFC3773 RFC3774 IETF Problem Statement E. Davies Editor May 2004 ASCII HTML 22 ietf process problem analysis

This memo summarizes perceived problems in the structure, function, and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community. The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to September 2003. The problem list has been further analyzed in an attempt to determine the root causes at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to recommend the structures and processes that will carry out the corrections. This memo provides information for the Internet community.

 draft-ietf-problem-issue-statement-05 INFORMATIONAL INFORMATIONAL IETF gen problem 10.17487/RFC3774 RFC3775 Mobility Support in IPv6 D. Johnson C. Perkins J. Arkko June 2004 ASCII HTML 165 mobility internet protocol nodes

This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. [STANDARDS-TRACK]

 draft-ietf-mobileip-ipv6-24 RFC6275 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3775 RFC3776 Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents J. Arkko V. Devarapalli F. Dupont June 2004 ASCII HTML 40 IPsec security internet protocol

Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order. [STANDARDS-TRACK]

 draft-ietf-mobileip-mipv6-ha-ipsec-06 RFC4877 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3776 RFC3777 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin Editor June 2004 ASCII HTML 34 IAB IESG Internet Architecture Board Internet Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self-consistent, organized compilation of the process as it was known at the time of publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-nomcom-rfc2727bis-09 RFC2727 RFC7437 RFC5078 RFC5633 RFC5680 RFC6859 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen nomcom http://www.rfc-editor.org/errata_search.php?rfc=3777 10.17487/RFC3777 RFC3778 The application/pdf Media Type E. Taft J. Pravetz S. Zilles L. Masinter May 2004 ASCII HTML 14 portable document format document exchange digital signatures

PDF, the 'Portable Document Format', is a general document representation language that has been in use for document exchange on the Internet since 1993. This document provides an overview of the PDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of 'application/pdf'. This memo provides information for the Internet community.

 draft-zilles-pdf-03 RFC8118 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3778 RFC3779 X.509 Extensions for IP Addresses and AS Identifiers C. Lynn S. Kent K. Seo June 2004 ASCII HTML 27 X.509 allocation atrribute certificate authorization autonomous system number authorization certificate delegation internet registry ip address authorization public key infrastructure right-to-use secure allocation

This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK]

 draft-ietf-pkix-x509-ipaddr-as-extn-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3779 10.17487/RFC3779 RFC3780 SMIng - Next Generation Structure of Management Information F. Strauss J. Schoenwaelder May 2004 ASCII HTML 64 SMIng Structure of Management Information Next Generation data definition language

This memo defines the base SMIng (Structure of Management Information, Next Generation) language. SMIng is a data definition language that provides a protocol-independent representation for management information. Separate RFCs define mappings of SMIng to specific management protocols, including SNMP. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-nmrg-sming-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3780 RFC3781 Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP) F. Strauss J. Schoenwaelder May 2004 ASCII HTML 49 data definition language

SMIng (Structure of Management Information, Next Generation) (RFC3780), is a protocol-independent data definition language for management information. This memo defines an SMIng language extension that specifies the mapping of SMIng definitions of identities, classes, and their attributes and events to dedicated definitions of nodes, scalar objects, tables and columnar objects, and notifications, for application to the SNMP management framework. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-nmrg-sming-snmp-05 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3781 10.17487/RFC3781 RFC3782 The NewReno Modification to TCP's Fast Recovery Algorithm S. Floyd T. Henderson A. Gurtov April 2004 ASCII HTML 19 TCP Transmission Control Protocol

The purpose of this document is to advance NewReno TCP's Fast Retransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status. The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout. However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewReno TCP. [STANDARDS-TRACK]

 draft-ietf-tsvwg-newreno-02 RFC2582 RFC6582 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3782 10.17487/RFC3782 RFC3783 Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI M. Chadalapaka R. Elliott May 2004 ASCII HTML 14 Internet Small Computer Systems Interface iscsi

Internet Small Computer Systems Interface (iSCSI) is a Small Computer Systems Interface (SCSI) transport protocol designed to run on top of TCP. The iSCSI session abstraction is equivalent to the classic SCSI "I_T nexus", which represents the logical relationship between an Initiator and a Target (I and T) required in order to communicate via the SCSI family of protocols. The iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI. This memo provides information for the Internet community.

 draft-ietf-ips-command-ordering-02 INFORMATIONAL INFORMATIONAL IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=3783 10.17487/RFC3783 RFC3784 Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) H. Smit T. Li June 2004 ASCII HTML 13 link state protocol lsp

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. This memo provides information for the Internet community.

 draft-ietf-isis-traffic-05 RFC5305 RFC4205 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3784 RFC3785 Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric F. Le Faucheur R. Uppili A. Vedrenne P. Merckx T. Telkamp May 2004 ASCII HTML 8 IGP Interior Gateway Protocol MPLS MultiProtocol Label Switching TE Traffic Engineering link bandwidth router

This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-tewg-te-metric-igp-02 BCP0087 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF subip tewg 10.17487/RFC3785 RFC3786 Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit A. Hermelin S. Previdi M. Shand May 2004 ASCII HTML 14

This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. This memo provides information for the Internet community.

 draft-ietf-isis-ext-lsp-frags-02 RFC5311 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3786 RFC3787 Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS) J. Parker Editor May 2004 ASCII HTML 11 routing traffic

This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A companion document describes the differences between the protocol described in ISO 10589 and current practice. This memo provides information for the Internet community.

 draft-ietf-isis-ip-interoperable-02 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3787 RFC3788 Security Considerations for Signaling Transport (SIGTRAN) Protocols J. Loughney M. Tuexen Editor J. Pastor-Balbas June 2004 ASCII HTML 13 SIGTRAN Signaling Transport Security

This document discusses how Transport Layer Security (TLS) and IPsec can be used to secure communication for SIGTRAN protocols. The main goal is to recommend the minimum security means that a SIGTRAN node must implement in order to attain secured communication. The support of IPsec is mandatory for all nodes running SIGTRAN protocols. TLS support is optional. [STANDARDS-TRACK]

 draft-ietf-sigtran-security-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3788 RFC3789 Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents P. Nesser, II A. Bergstrom Editor June 2004 ASCII HTML 10

This document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in IETF standards track and experimental RFCs. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which types of RFCs have been documented, and provides a concatenated summary of results. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-intro-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3789 RFC3790 Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents C. Mickles Editor P. Nesser, II June 2004 ASCII HTML 49

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-int-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3790 RFC3791 Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents C. Olvera P. Nesser, II June 2004 ASCII HTML 15

This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-routing-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3791 RFC3792 Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents P. Nesser, II A. Bergstrom Editor June 2004 ASCII HTML 25

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-sec-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3792 RFC3793 Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents P. Nesser, II A. Bergstrom Editor June 2004 ASCII HTML 6

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-subip-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3793 RFC3794 Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents P. Nesser, II A. Bergstrom Editor June 2004 ASCII HTML 31

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-trans-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3794 RFC3795 Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents R. Sofia P. Nesser, II June 2004 ASCII HTML 50

This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, and Proposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-apps-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3795 RFC3796 Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents P. Nesser, II A. Bergstrom Editor June 2004 ASCII HTML 43

This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations & Management Area accepted standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipv4survey-ops-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3796 RFC3797 Publicly Verifiable Nominations Committee (NomCom) Random Selection D. Eastlake 3rd June 2004 ASCII HTML 19 Internet Engineering Task Force IETF

This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. As an example, the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases. This memo provides information for the Internet community.

 draft-eastlake-rfc2777bis-selection-04 RFC2777 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3797 10.17487/RFC3797 RFC3798 Message Disposition Notification T. Hansen Editor G. Vaudreuil Editor May 2004 ASCII HTML 30 EMF-MDN MDN Message Disposition Notifications media-type MIME multipurpose internet mail extensions

This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. [STANDARDS-TRACK]

 draft-vaudreuil-mdnbis-05 RFC2298 RFC8098 RFC3461 RFC2046 RFC5337 RFC6533 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3798 10.17487/RFC3798 RFC3799 RFC3800 RFC3801 Voice Profile for Internet Mail - version 2 (VPIMv2) G. Vaudreuil G. Parsons June 2004 ASCII HTML 55 MIME-VP2 vpim Voice Profile for Internet Mail messaging

This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. The profile is referred to as the Voice Profile for Internet Mail (VPIM) in this document. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems. This document obsoletes RFC 2421 and describes version 2 of the profile with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in Appendix F. Appendix A summarizes the protocol profiles of this version of VPIM. [STANDARDS-TRACK]

 draft-ietf-vpim-vpimv2r2-05 RFC2421 RFC2423 DRAFT STANDARD DRAFT STANDARD IETF app vpim 10.17487/RFC3801 RFC3802 Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration G. Vaudreuil G. Parsons June 2004 ASCII HTML 7 MIME-ADPCM multipurpose internet mail extensions Adaptive Differential Pulse Code Modulation audio

This document describes the registration of the MIME sub-type audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll quality audio. This audio encoding is defined by the ITU-T in Recommendation G.726. [STANDARDS-TRACK]

 draft-ietf-vpim-vpimv2r2-32k-03 RFC2422 DRAFT STANDARD DRAFT STANDARD IETF app vpim 10.17487/RFC3802 RFC3803 Content Duration MIME Header Definition G. Vaudreuil G. Parsons June 2004 ASCII HTML 5 CONT-DUR Content Duration multipurpose internet mail extensions time media

This document describes the MIME header Content-Duration that is intended for use with any time varying media content (typically audio/* or video/*). [STANDARDS-TRACK]

 draft-ietf-vpim-vpimv2r2-dur-03 RFC2424 DRAFT STANDARD DRAFT STANDARD IETF app vpim 10.17487/RFC3803 RFC3804 Voice Profile for Internet Mail (VPIM) Addressing G. Parsons June 2004 ASCII HTML 15 VPIM Voice Profile for Internet Mail formats

This document lists the various Voice Profile for Internet Mail (VPIM) email address formats that are currently in common use and defines several new address formats for special case usage. Requirements are imposed on the formats of addresses used in VPIM submission mode. [STANDARDS-TRACK]

 draft-ietf-vpim-address-03 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC3804 RFC3805 Printer MIB v2 R. Bergman H. Lewis I. McDonald June 2004 ASCII HTML 171 Print-MIB Printer Management Information Base snmp management

This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This document obsoletes RFC 1759. [STANDARDS-TRACK]

 draft-ietf-printmib-mib-info-15 RFC1759 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3805 RFC3806 Printer Finishing MIB R. Bergman H. Lewis I. McDonald June 2004 ASCII HTML 53 finisher snmp

This document defines a MIB module for the management of printer finishing device subunits. The finishing device subunits applicable to this MIB are an integral part of the Printer System. This MIB applies only to a Finisher Device that is connected to a Printer System. This memo provides information for the Internet community.

 draft-ietf-printmib-finishing-16 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3806 RFC3807 V5.2-User Adaptation Layer (V5UA) E. Weilandt N. Khanchandani S. Rao June 2004 ASCII HTML 24 v5 v5.1 v5.2 backhauling imap sctp isdn access network c-path c-channel efa envelope function address lapv5 pstn v5ptm mgc gateway controller gateway

This document defines a mechanism for the backhauling of V5.2 messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol may be used between a Signaling Gateway (SG) and a Media Gateway controller (MGC). It is assumed that the SG receives V5.2 signaling over a standard V5.2 interface. This document builds on the ISDN User Adaptation Layer Protocol (RFC 3057). It defines all necessary extensions to the IUA Protocol needed for the V5UA protocol implementation. [STANDARDS-TRACK]

 draft-ietf-sigtran-v5ua-04 RFC3057 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3807 RFC3808 IANA Charset MIB I. McDonald June 2004 ASCII HTML 14 management information base IANACharset

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This IANA Charset MIB is now an IANA registry. In particular, a single textual convention 'IANACharset' is defined that may be used to specify charset labels in MIB objects. 'IANACharset' was extracted from Printer MIB v2 (RFC 3805). 'IANACharset' was originally defined (and mis-named) as 'CodedCharSet' in Printer MIB v1 (RFC 1759). A tool has been written in C, that may be used by IANA to regenerate this IANA Charset MIB, when future charsets are registered in accordance with the IANA Charset Registration Procedures (RFC 2978). This memo provides information for the Internet community.

 draft-mcdonald-iana-charset-mib-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3808 RFC3809 Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN) A. Nagarajan Editor June 2004 ASCII HTML 25 service engineering

This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. This memo provides information for the Internet community.

 draft-ietf-l3vpn-generic-reqts-03 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC3809 RFC3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 R. Vida Editor L. Costa Editor June 2004 ASCII HTML 62 Multicast Listener Discovery ssm source filtering igmp group management mld

This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS-TRACK]

 draft-vida-mld-v2-08 RFC2710 RFC4604 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=3810 10.17487/RFC3810 RFC3811 Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management T. Nadeau Editor J. Cucchiara Editor June 2004 ASCII HTML 20 Textual Conventions TCs Multiprotocol Label Switching MPLS management information base

This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-mpls-tc-mib-10 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3811 10.17487/RFC3811 RFC3812 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) C. Srinivasan A. Viswanathan T. Nadeau June 2004 ASCII HTML 68 MPLS Multiprotocol Label Switching TE Traffic Engineering MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). [STANDARDS-TRACK]

 draft-ietf-mpls-te-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3812 RFC3813 Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) C. Srinivasan A. Viswanathan T. Nadeau June 2004 ASCII HTML 60

This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR). [STANDARDS-TRACK]

 draft-ietf-mpls-lsr-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3813 10.17487/RFC3813 RFC3814 Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) T. Nadeau C. Srinivasan A. Viswanathan June 2004 ASCII HTML 42 MPLS Multiprotocol Label Switching MIB Management Information Base FEC Forwarding Equivalence Class NHLFE Next Hop Label Forwarding Entry

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]

 draft-ietf-mpls-ftn-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3814 RFC3815 Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) J. Cucchiara H. Sjostrand J. Luciani June 2004 ASCII HTML 106 MPLS Multiprotocol Label Switching LDP Label Distribution Protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3815 10.17487/RFC3815 RFC3816 Definitions of Managed Objects for RObust Header Compression (ROHC) J. Quittek M. Stiemerling H. Hartenstein June 2004 ASCII HTML 53 ROHC Robust Header Compression mib management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring of running instances of RObust Header Compression (ROHC). The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP (Real-Time Transport Protocol) profile, the ROHC UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security Payload) profile, and the ROHC LLA (Link Layer Assisted) profile. [STANDARDS-TRACK]

 draft-ietf-rohc-mib-rtp-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=3816 10.17487/RFC3816 RFC3817 Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE) W. Townsley R. da Silva June 2004 ASCII HTML 17 point-to-point

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. Layer Two Tunneling Protocol (L2TP), facilitates the tunneling of PPP packets across an intervening packet-switched network. And yet a third protocol, PPP over Ethernet (PPPoE) describes how to build PPP sessions and to encapsulate PPP packets over Ethernet. L2TP Active Discovery Relay for PPPoE describes a method to relay Active Discovery and Service Selection functionality from PPPoE over the reliable control channel within L2TP. Two new L2TP control message types and associated PPPoE-specific Attribute Value Pairs (AVPs) for L2TP are defined. This relay mechanism provides enhanced integration of a specific feature in the PPPoE tunneling protocol with L2TP. This memo provides information for the Internet community.

 draft-dasilva-l2tp-relaysvc-08 INFORMATIONAL INFORMATIONAL IETF int l2tpext 10.17487/RFC3817 RFC3818 IANA Considerations for the Point-to-Point Protocol (PPP) V. Schryver June 2004 ASCII HTML 4 PPP Point-to-Point Protocol

The charter of the Point-to-Point Protocol (PPP) Extensions working group (pppext) includes the responsibility to "actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value." In support of that charter, the allocation of PPP protocol and other assigned numbers will no longer be "first come first served." This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-schryver-pppext-iana-01 BCP0088 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int pppext 10.17487/RFC3818 RFC3819 Advice for Internet Subnetwork Designers P. Karn Editor C. Bormann G. Fairhurst D. Grossman R. Ludwig J. Mahdavi G. Montenegro J. Touch L. Wood July 2004 ASCII HTML 60 digital communication equipment link-layer protocols packet-switched local networks

This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with the Internet architecture and the implications of their design choices on the performance and efficiency of the Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-pilc-link-design-15 BCP0089 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc http://www.rfc-editor.org/errata_search.php?rfc=3819 10.17487/RFC3819 RFC3820 Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile S. Tuecke V. Welch D. Engert L. Pearlman M. Thompson June 2004 ASCII HTML 37 X.509 PKI Public Key Infrastructure authentication security credentials restricted delegation single-signon delegation of rights

This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term Proxy Certificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system. [STANDARDS-TRACK]

 draft-ietf-pkix-proxy-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3820 10.17487/RFC3820 RFC3821 Fibre Channel Over TCP/IP (FCIP) M. Rajagopal E. Rodriguez R. Weber July 2004 ASCII HTML 74 FCIP Fibre Channel Over TCI/IP storage area networks IP-based networks unified storage area network

Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. [STANDARDS-TRACK]

 draft-ietf-ips-fcovertcpip-12 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3821 RFC3822 Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2) D. Peterson July 2004 ASCII HTML 11 FCIP Fibre Channel over TCP/IP SLP Service Location Protocol dynamic discovery

This document defines the use of Service Location Protocol version 2 (SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities. [STANDARDS-TRACK]

 draft-ietf-ips-fcip-slp-09 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=3822 10.17487/RFC3822 RFC3823 MIME Media Type for the Systems Biology Markup Language (SBML) B. Kovitz June 2004 ASCII HTML 8 sub-type application/sbml+xml systems biology community

This document registers the MIME sub-type application/sbml+xml, a media type for SBML, the Systems Biology Markup Language. SBML is defined by The SBML Team at the California Institute of Technology and interested members of the systems biology community. This memo provides information for the Internet community.

 draft-sbml-media-type-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3823 RFC3824 Using E.164 numbers with the Session Initiation Protocol (SIP) J. Peterson H. Liu J. Yu B. Campbell June 2004 ASCII HTML 16 telephone records applications

There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations. This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number. This memo provides information for the Internet community.

 draft-ietf-sipping-e164-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3824 RFC3825 Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information J. Polk J. Schnizlein M. Linsner July 2004 ASCII HTML 15 dhcp Dynamic Host Configuration Protocol lci geographic location LCI Location Configuration Information

This document specifies a Dynamic Host Configuration Protocol Option for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution indicators for each. The reference datum for these values is also included. [STANDARDS-TRACK]

 draft-ietf-geopriv-dhcp-lci-option-03 RFC6225 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC3825 RFC3826 The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model U. Blumenthal F. Maino K. McCloghrie June 2004 ASCII HTML 16 management information base simple network management protocol

This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]

 draft-blumenthal-aes-usm-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3826 RFC3827 Additional Snoop Datalink Types K. Sarcar June 2004 ASCII HTML 4

The snoop file format provides a way to store and exchange datalink layer packet traces. This document describes extensions to this file format to support new media. This memo provides information for the Internet community.

 draft-sarcar-snoop-new-types-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3827 RFC3828 The Lightweight User Datagram Protocol (UDP-Lite) L-A. Larzon M. Degermark S. Pink L-E. Jonsson Editor G. Fairhurst Editor July 2004 ASCII HTML 12 UDP-Lite Lightweight User Datagram Protocol

This document describes the Lightweight User Datagram Protocol (UDP-Lite), which is similar to the User Datagram Protocol (UDP) (RFC 768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP. [STANDARDS-TRACK]

 draft-ietf-tsvwg-udp-lite-02 RFC6335 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3828 RFC3829 Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls R. Weltman M. Smith M. Wahl July 2004 ASCII HTML 6 bind operation

This document extends the Lightweight Directory Access Protocol (LDAP) bind operation with a mechanism for requesting and returning the authorization identity it establishes. Specifically, this document defines the Authorization Identity Request and Response controls for use with the Bind operation. This memo provides information for the Internet community.

 draft-weltman-ldapv3-auth-response-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3829 10.17487/RFC3829 RFC3830 MIKEY: Multimedia Internet KEYing J. Arkko E. Carrara F. Lindholm M. Naslund K. Norrman August 2004 ASCII HTML 66 MIKEY Multimedia Internet KEYing key management scheme real-time applications

This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real-time Transport Protocol is described in detail. Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. [STANDARDS-TRACK]

 draft-ietf-msec-mikey-08 RFC4738 RFC6309 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=3830 10.17487/RFC3830 RFC3831 Transmission of IPv6 Packets over Fibre Channel C. DeSanti July 2004 ASCII HTML 24 addresses link-local internet protocol

This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks. [STANDARDS-TRACK]

 draft-ietf-imss-ipv6-over-fibre-channel-02 RFC4338 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC3831 RFC3832 Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV W. Zhao H. Schulzrinne E. Guttman C. Bisdikian W. Jerome July 2004 ASCII HTML 8 SLP Service Location Protocol DNS-SRV domain name system resource record

Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) via DNS SRV. It defines the DNS SRV Resource Records for SLP Directory Agent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains. This memo defines an Experimental Protocol for the Internet community.

 draft-zhao-slp-remote-da-discovery-06 RFC8553 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3832 RFC3833 Threat Analysis of the Domain Name System (DNS) D. Atkins R. Austein August 2004 ASCII HTML 16 data disclosure security authentication

Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. This memo provides information for the Internet community.

 draft-ietf-dnsext-dns-threats-07 INFORMATIONAL INFORMATIONAL IETF int dnsext 10.17487/RFC3833 RFC3834 Recommendations for Automatic Responses to Electronic Mail K. Moore August 2004 ASCII HTML 22 automatic mail responders

This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders. The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders. [STANDARDS-TRACK]

 draft-moore-auto-email-response-05 RFC5436 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3834 10.17487/RFC3834 RFC3835 An Architecture for Open Pluggable Edge Services (OPES) A. Barbir R. Penno R. Chen M. Hofmann H. Orman August 2004 ASCII HTML 17 application service data stream service data consumer data dispatcher architecture

This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service. This memo provides information for the Internet community.

 draft-ietf-opes-architecture-04 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3835 RFC3836 Requirements for Open Pluggable Edge Services (OPES) Callout Protocols A. Beck M. Hofmann H. Orman R. Penno A. Terzis August 2004 ASCII HTML 13 callout protocol remote execution OPES services

This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services. The requirements are intended to help evaluate possible protocol candidates, as well as to guide the development of such protocols. This memo provides information for the Internet community.

 draft-ietf-opes-protocol-reqs-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3836 RFC3837 Security Threats and Risks for Open Pluggable Edge Services (OPES) A. Barbir O. Batuner B. Srinivas M. Hofmann H. Orman August 2004 ASCII HTML 14 threat discovery threat analysis

The document investigates the security threats associated with the Open Pluggable Edge Services (OPES) and discusses the effects of security threats on the underlying architecture. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions. This memo provides information for the Internet community.

 draft-ietf-opes-threats-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3837 RFC3838 Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES) A. Barbir O. Batuner A. Beck T. Chan H. Orman August 2004 ASCII HTML 17 opes flow

This document describes policy, authorization, and enforcement requirements for the selection of the services to be applied to a given Open Pluggable Edge Services (OPES) flow. This memo provides information for the Internet community.

 draft-ietf-opes-authorization-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3838 RFC3839 MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files R. Castagno D. Singer July 2004 ASCII HTML 7 standard MIME types 3GPP multimedia file format ISO Media File Format

This document serves to register and document the standard MIME types associated with the 3GPP multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]

 draft-singer-avt-3gpp-mime-01 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3839 RFC3840 Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne P. Kyzivat August 2004 ASCII HTML 36 User Agent ua contact header field SIP Session Initiation Protocol

This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. [STANDARDS-TRACK]

 draft-ietf-sip-callee-caps-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3840 RFC3841 Caller Preferences for the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne P. Kyzivat August 2004 ASCII HTML 26 SIP Session Initiation Protocol Uniform Resource Identifiers URI Accept-Contact Reject-Contact Request-Disposition

This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request-Disposition, which specify the caller's preferences. [STANDARDS-TRACK]

 draft-ietf-sip-callerprefs-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3841 RFC3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP) R. Mahy August 2004 ASCII HTML 19 SIP Session Initiation Protocol message waiting status message summary

This document describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. [STANDARDS-TRACK]

 draft-ietf-sipping-mwi-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC3842 RFC3843 RObust Header Compression (ROHC): A Compression Profile for IP L-E. Jonsson G. Pelletier June 2004 ASCII HTML 16 ROHC RObust Header Compression compression protocols

The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines a ROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length. [STANDARDS-TRACK]

 draft-ietf-rohc-ip-only-05 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3843 RFC3844 IETF Problem Resolution Process E. Davies Editor J. Hofmann Editor August 2004 ASCII HTML 20 ietf process problem analysis

This Informational document records the history of discussions in the Problem WG during 2003 of how to resolve the problems described in the IETF Problem Statement. It decomposes each of the problems described into a few areas for improvement and categorizes them as either problems affecting the routine processes used to create standards or problems affecting the fundamental structure and practices of the IETF. Expeditious and non-disruptive solutions are proposed for the problems affecting routine processes. The document also lists suggested ways to handle the development of solutions for the structure and practices problems proposed in IETF discussions. Neither the working group nor the wider IETF has reached consensus on a recommendation for any of the proposals. This document therefore has no alternative but to suggest that the search for structure and practices solutions be handed back to the control of the IESG. While there was working group consensus on the processes for short-term and medium term improvements, there was no working group consensus on the proposals for longer-term improvements. This document therefore includes longer-term improvement proposals only as a matter of record; they must not be regarded as recommendations from the working group. This memo provides information for the Internet community.

 draft-ietf-problem-process-04 INFORMATIONAL INFORMATIONAL IETF gen problem 10.17487/RFC3844 RFC3845 DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format J. Schlyter Editor August 2004 ASCII HTML 7 dnssec DNS Security rr resource record DNS-SECEXT dns authentication nsec nextsecure

This document redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space. [STANDARDS-TRACK]

 draft-ietf-dnsext-nsec-rdata-06 RFC4033 RFC4034 RFC4035 RFC3755 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3845 RFC3846 Mobile IPv4 Extension for Carrying Network Access Identifiers F. Johansson T. Johansson June 2004 ASCII HTML 8 NAI Network Access Identifiers internet protocol home aaa server ha server home agents

When a mobile node moves between two foreign networks, it has to be re-authenticated. If the home network has both multiple Authentication Authorization and Accounting (AAA) servers and Home Agents (HAs) in use, the Home AAA server may not have sufficient information to process the re-authentication correctly (i.e., to ensure that the same HA continues to be used). This document defines a Mobile IP extension that carries identities for the Home AAA and HA servers in the form of Network Access Identifiers (NAIs). The extension allows a Home Agent to pass its identity (and that of the Home AAA server) to the mobile node, which can then pass it on to the local AAA server when changing its point of attachment. This extension may also be used in other situations requiring communication of a NAI between Mobile IP nodes. [STANDARDS-TRACK]

 draft-ietf-mip4-aaa-nai-02 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC3846 RFC3847 Restart Signaling for Intermediate System to Intermediate System (IS-IS) M. Shand L. Ginsberg July 2004 ASCII HTML 21 LSP database synchronization transient routing disruption database synchronization

This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This memo provides information for the Internet community.

 draft-ietf-isis-restart-05 RFC5306 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3847 RFC3848 ESMTP and LMTP Transmission Types Registration C. Newman July 2004 ASCII HTML 4 smtp simple mail transfer protocol

This registers seven new mail transmission types (ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" clause of a Received header in an Internet message. [STANDARDS-TRACK]

 draft-newman-esmtpsa-01 DRAFT STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3848 RFC3849 IPv6 Address Prefix Reserved for Documentation G. Huston A. Lord P. Smith July 2004 ASCII HTML 4 unicast site-local link-local

To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation. This memo provides information for the Internet community.

 draft-huston-ipv6-documentation-prefix-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3849 RFC3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling B. Ramsdell Editor July 2004 ASCII HTML 16 x.509 encryption certificate mime multipurpose internet mail extensions secure

This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 3280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 3280. [STANDARDS-TRACK]

 draft-ietf-smime-rfc2632bis-07 RFC2632 RFC5750 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3850 RFC3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification B. Ramsdell Editor July 2004 ASCII HTML 36 secure multipurpose internet mail extensions encryption

This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633. [STANDARDS-TRACK]

 draft-ietf-smime-rfc2633bis-09 RFC2633 RFC5751 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3851 RFC3852 Cryptographic Message Syntax (CMS) R. Housley July 2004 ASCII HTML 56 CMS Cryptographic Message Syntax digitally sign authenticate encrypt arbitrary message content

This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]

 draft-ietf-smime-rfc3369bis-04 RFC3369 RFC5652 RFC4853 RFC5083 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3852 10.17487/RFC3852 RFC3853 S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP) J. Peterson July 2004 ASCII HTML 6 SIP Session Initiation Protocol AES Advanced Encryption Standard application-layer application layer multimedia multicast unicast

RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session Initiation Protocol (SIP). This document updates the normative guidance of RFC 3261 to require the Advanced Encryption Standard (AES) for S/MIME. [STANDARDS-TRACK]

 draft-ietf-sip-smime-aes-01 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3853 RFC3854 Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME) P. Hoffman C. Bonatti A. Eggen July 2004 ASCII HTML 15 MIME secure Multipurpose Internet Mail Extensions encryption cryptographic signature

This document describes a protocol for adding cryptographic signature and encryption services to X.400 content with Secure/Multipurpose Internet Mail Extensions (S/MIME). [STANDARDS-TRACK]

 draft-ietf-smime-x400wrap-09 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC3854 RFC3855 Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400 P. Hoffman C. Bonatti July 2004 ASCII HTML 12 cms cryptographic message syntax message MIME Multipurpose Internet Mail Extensions secure

This document describes protocol options for conveying objects that have been protected using the Cryptographic Message Syntax (CMS) and Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 over an X.400 message transfer system. [STANDARDS-TRACK]

 draft-ietf-smime-x400transport-09 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib http://www.rfc-editor.org/errata_search.php?rfc=3855 10.17487/RFC3855 RFC3856 A Presence Event Package for the Session Initiation Protocol (SIP) J. Rosenberg August 2004 ASCII HTML 27 subscription notification

This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework. [STANDARDS-TRACK]

 draft-ietf-simple-presence-10 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=3856 10.17487/RFC3856 RFC3857 A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) J. Rosenberg August 2004 ASCII HTML 20

This document defines the watcher information template-package for the Session Initiation Protocol (SIP) event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself. [STANDARDS-TRACK]

 draft-ietf-simple-winfo-package-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC3857 RFC3858 An Extensible Markup Language (XML) Based Format for Watcher Information J. Rosenberg August 2004 ASCII HTML 13 Extensible Markup Language xml

Watchers are defined as entities that request (i.e., subscribe to) information about a resource. There is fairly complex state associated with these subscriptions. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. In order to enable this, a format is needed to describe the state of watchers on a resource. This specification describes an Extensible Markup Language (XML) document format for such state. [STANDARDS-TRACK]

 draft-ietf-simple-winfo-format-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3858 RFC3859 Common Profile for Presence (CPP) J. Peterson August 2004 ASCII HTML 15 CPP Common Profile for Presence data formats semantics instant messaging

At the time this document was written, numerous presence protocols were in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services. [STANDARDS-TRACK]

 draft-ietf-impp-pres-04 PROPOSED STANDARD PROPOSED STANDARD IETF app impp http://www.rfc-editor.org/errata_search.php?rfc=3859 10.17487/RFC3859 RFC3860 Common Profile for Instant Messaging (CPIM) J. Peterson August 2004 ASCII HTML 13 CPIM Common Profile for Instant Messaging data formats semantics instant messaging

At the time this document was written, numerous instant messaging protocols were in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. [STANDARDS-TRACK]

 draft-ietf-impp-im-04 PROPOSED STANDARD PROPOSED STANDARD IETF app impp 10.17487/RFC3860 RFC3861 Address Resolution for Instant Messaging and Presence J. Peterson August 2004 ASCII HTML 8 uri schemes universal resource identifier impp instant messaging and presence protocol presentity instant inbox

Presence and instant messaging are defined in RFC 2778. The Common Profiles for Presence and Instant Messaging define two Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. [STANDARDS-TRACK]

 draft-ietf-impp-srv-04 PROPOSED STANDARD PROPOSED STANDARD IETF app impp 10.17487/RFC3861 RFC3862 Common Presence and Instant Messaging (CPIM): Message Format G. Klyne D. Atkins August 2004 ASCII HTML 30 instant messaging and common presence protocol message/cpim

This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. [STANDARDS-TRACK]

 draft-ietf-impp-cpim-msgfmt-09 PROPOSED STANDARD PROPOSED STANDARD IETF app impp http://www.rfc-editor.org/errata_search.php?rfc=3862 10.17487/RFC3862 RFC3863 Presence Information Data Format (PIDF) H. Sugano S. Fujimoto G. Klyne A. Bateman W. Carr J. Peterson August 2004 ASCII HTML 28 instant messaging and presence protocol cpp common profile for presence presence data format application/pidf+xml

This memo specifies the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant Presence protocols, and also defines a new media type "application/pidf+xml" to represent the XML MIME entity for PIDF. [STANDARDS-TRACK]

 draft-ietf-impp-cpim-pidf-08 PROPOSED STANDARD PROPOSED STANDARD IETF app impp http://www.rfc-editor.org/errata_search.php?rfc=3863 10.17487/RFC3863 RFC3864 Registration Procedures for Message Header Fields G. Klyne M. Nottingham J. Mogul September 2004 ASCII HTML 17 Internet mail HTTP Netnews

This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-klyne-msghdr-registry-07 RFC9110 BCP0090 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3864 RFC3865 A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension C. Malamud September 2004 ASCII HTML 19 SMTP Simple Mail Transfer Protocol unsolicited bulk email ube no soliciting solicitation class keywords solicitation mail header trace fields

This document proposes an extension to Soliciting Simple Mail Transfer Protocol (SMTP) for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing "received" message header are described. [STANDARDS-TRACK]

 draft-malamud-no-soliciting-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3865 RFC3866 Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP) K. Zeilenga Editor July 2004 ASCII HTML 15 LDAP lightweight directory access protocol servers

It is often desirable to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs. This document details the use of Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). [STANDARDS-TRACK]

 draft-zeilenga-ldap-rfc2596-05 RFC2596 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3866 10.17487/RFC3866 RFC3867 Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP) Y. Kawatsura M. Hiroya H. Beykirch November 2004 ASCII HTML 106 modules data format exchange

The Internet Open Trading Protocol (IOTP) provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules.

This document addresses a common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in-mechanism in actual implementations of IOTP application cores.

Such interfaces exist at the Consumers', the Merchants' and the Payment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems. This memo provides information for the Internet community.

 draft-ietf-trade-iotp-v1.0-papi-06 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3867 RFC3868 Signalling Connection Control Part User Adaptation Layer (SUA) J. Loughney Editor G. Sidebottom L. Coene G. Verwimp J. Keller B. Bidulock October 2004 ASCII HTML 131 SUA Signaling Connection Control Part User Adaptation Layer sctp stream control transmission protocol modular symmetric signalling gateway signalling endpoint architecture

This document defines a protocol for the transport of any Signalling Connection Control Part-User signalling over IP using the Stream Control Transmission Protocol. The protocol is designed to be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway to IP Signalling Endpoint architecture as well as a peer-to-peer IP Signalling Endpoint architecture. [STANDARDS-TRACK]

 draft-ietf-sigtran-sua-16 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3868 RFC3869 IAB Concerns and Recommendations Regarding Internet Research and Evolution R. Atkinson Editor S. Floyd Editor Internet Architecture Board August 2004 ASCII HTML 30 internet architecture board internet infrastructure non-commercial funding

This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research. This memo provides information for the Internet community.

 draft-iab-research-funding-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3869 RFC3870 application/rdf+xml Media Type Registration A. Swartz September 2004 ASCII HTML 8 xml extensible markup language mime multipurpose internet mail extensions rdf resource description framework

This document describes a media type (application/rdf+xml) for use with the Extensible Markup Language (XML) serialization of the Resource Description Framework (RDF). RDF is a language designed to support the Semantic Web, by facilitating resource description and data exchange on the Web. RDF provides common structures that can be used for interoperable data exchange and follows the World Wide Web Consortium (W3C) design principles of interoperability, evolution, and decentralization. This memo provides information for the Internet community.

 draft-swartz-rdfcore-rdfxml-mediatype-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3870 RFC3871 Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure G. Jones Editor September 2004 ASCII HTML 81

This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors. This memo provides information for the Internet community.

 draft-jones-opsec-06 RFC8996 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3871 RFC3872 Management Information Base for Telephony Routing over IP (TRIP) D. Zinman D. Walker J. Jiang September 2004 ASCII HTML 53 mib management information base TRIP Telephony Routing over IP

This memo defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Telephony Routing over IP (TRIP) devices. [STANDARDS-TRACK]

 draft-ietf-iptel-trip-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC3872 RFC3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB) J. Pastor M. Belinchon September 2004 ASCII HTML 46 SCTP Stream Control Transmission Protocol MIB Management Information Base

The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport public switched telephone network (PSTN) signaling messages over the connectionless packet network, but is capable of broader applications.

This memo defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage the implementation of the SCTP. [STANDARDS-TRACK]

 draft-ietf-sigtran-sctp-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3873 RFC3874 A 224-bit One-way Hash Function: SHA-224 R. Housley September 2004 ASCII HTML 6 secure standard

This document specifies a 224-bit one-way hash function, called SHA-224. SHA-224 is based on SHA-256, but it uses a different initial value and the result is truncated to 224 bits. This memo provides information for the Internet community.

 draft-ietf-pkix-sha224-01 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC3874 RFC3875 The Common Gateway Interface (CGI) Version 1.1 D. Robinson K. Coar October 2004 ASCII PDF HTML 36 www world wide web

The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers.

The interface has been in use by the World-Wide Web (WWW) since 1993. This specification defines the 'current practice' parameters of the 'CGI/1.1' interface developed and documented at the U.S. National Centre for Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems. This memo provides information for the Internet community.

 draft-coar-cgi-v11-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3875 10.17487/RFC3875 RFC3876 Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3) D. Chadwick S. Mullan September 2004 ASCII HTML 12 LDAP Lightweight Directory Access Protocol attribute filter

This document describes a control for the Lightweight Directory Access Protocol version 3 that is used to return a subset of attribute values from an entry. Specifically, only those values that match a "values return" filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally. [STANDARDS-TRACK]

 draft-ietf-ldapext-matchedval-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3876 RFC3877 Alarm Management Information Base (MIB) S. Chisholm D. Romascanu September 2004 ASCII HTML 75 Management Information Base alarm mib iana-itu-alarm-tc-mib itu-alarm-tc-mib itu-alarm-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for modelling and storing alarms. [STANDARDS-TRACK]

 draft-ietf-disman-alarm-mib-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=3877 10.17487/RFC3877 RFC3878 Alarm Reporting Control Management Information Base (MIB) H. Lam A. Huynh D. Perkins September 2004 ASCII HTML 16 MIB Management Information Base alarm condition probably cause

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for controlling the reporting of alarm conditions. [STANDARDS-TRACK]

 draft-ietf-disman-conditionmib-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC3878 RFC3879 Deprecating Site Local Addresses C. Huitema B. Carpenter September 2004 ASCII HTML 10 Internet Protocol ipv6 architecture site-local

This document describes the issues surrounding the use of IPv6 site-local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented. [STANDARDS-TRACK]

 draft-ietf-ipv6-deprecate-site-local-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3879 RFC3880 Call Processing Language (CPL): A Language for User Control of Internet Telephony Services J. Lennox X. Wu H. Schulzrinne October 2004 ASCII HTML 74 CPL Call Processing Language

This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. [STANDARDS-TRACK]

 draft-ietf-iptel-cpl-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC3880 RFC3881 Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications G. Marshall September 2004 ASCII HTML 47

This document defines the format of data to be collected and minimum set of attributes that need to be captured for security auditing in healthcare application systems. The format is defined as an XML schema, which is intended as a reference for healthcare standards developers and application designers. It consolidates several previous documents on security auditing of healthcare data. This memo provides information for the Internet community.

 draft-marshall-security-audit-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3881 RFC3882 Configuring BGP to Block Denial-of-Service Attacks D. Turk September 2004 ASCII HTML 8 dos border gateway protocol

This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black-holing can be applied on a selection of routers rather than all BGP-speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis. This memo provides information for the Internet community.

 draft-turk-bgp-dos-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3882 RFC3883 Detecting Inactive Neighbors over OSPF Demand Circuits (DC) S. Rao A. Zinin A. Roy October 2004 ASCII HTML 6 OSPF-DC Open Shortest Path First Demand Circuits

OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits (DC) is optimized in RFC 1793 to minimize the amount of overhead traffic. A part of the OSPF demand circuit extensions is the Hello suppression mechanism. This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect an OSPF-inactive neighbor over such a link. This memo introduces a new mechanism called "neighbor probing" to address the above problem. [STANDARDS-TRACK]

 draft-ietf-ospf-dc-07 RFC1793 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC3883 RFC3884 Use of IPsec Transport Mode for Dynamic Routing J. Touch L. Eggert Y. Wang September 2004 ASCII HTML 25

IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of the VN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture. IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts. IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE). This memo provides information for the Internet community.

 draft-touch-ipsec-vpn-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3884 RFC3885 SMTP Service Extension for Message Tracking E. Allman T. Hansen September 2004 ASCII HTML 9 SMTP simple mail transfer protocol

This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. [STANDARDS-TRACK]

 draft-ietf-msgtrk-smtpext-05 RFC3461 PROPOSED STANDARD PROPOSED STANDARD IETF app msgtrk 10.17487/RFC3885 RFC3886 An Extensible Message Format for Message Tracking Responses E. Allman September 2004 ASCII HTML 11 Delivery Status Notifications DSN Message Disposition Notifications MDN

Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period.

This memo defines a MIME content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format for Delivery Status Notifications". It is to be issued upon a request as described in "Message Tracking Query Protocol". This memo defines only the format of the status information. An extension to SMTP to label messages for further tracking and request tracking status is defined in a separate memo. [STANDARDS-TRACK]

 draft-ietf-msgtrk-trkstat-05 RFC3463 PROPOSED STANDARD PROPOSED STANDARD IETF app msgtrk http://www.rfc-editor.org/errata_search.php?rfc=3886 10.17487/RFC3886 RFC3887 Message Tracking Query Protocol T. Hansen September 2004 ASCII HTML 23 Message Tracking Query Protocol MTQP ESMTP

Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet. [STANDARDS-TRACK]

 draft-ietf-msgtrk-mtqp-12 RFC8553 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF app msgtrk http://www.rfc-editor.org/errata_search.php?rfc=3887 10.17487/RFC3887 RFC3888 Message Tracking Model and Requirements T. Hansen September 2004 ASCII HTML 11 Message Tracking

Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding the Internet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions. This memo provides information for the Internet community.

 draft-ietf-msgtrk-model-07 INFORMATIONAL INFORMATIONAL IETF app msgtrk 10.17487/RFC3888 RFC3889 RFC3890 A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) M. Westerlund September 2004 ASCII HTML 22 SDP Session Description Protocol TIAS Transport Independent Application Specific Maximum

This document defines a Session Description Protocol (SDP) Transport Independent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used.

The existing SDP bandwidth modifiers and their values include the bandwidth needed for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), and the Real-Time Streaming Protocol (RTSP), and when the involved hosts has different transport overhead, for example due to different IP versions, the interpretation of what lower layer bandwidths are included is not clear. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-bwparam-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC3890 RFC3891 The Session Initiation Protocol (SIP) "Replaces" Header R. Mahy B. Biggs R. Dean September 2004 ASCII HTML 16 SIP Session Initiation Protocol multi-party applications call control

This document defines a new header for use with Session Initiation Protocol (SIP) multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "Call Pickup". Note that the definition of these example features is non-normative. [STANDARDS-TRACK]

 draft-ietf-sip-replaces-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3891 10.17487/RFC3891 RFC3892 The Session Initiation Protocol (SIP) Referred-By Mechanism R. Sparks September 2004 ASCII HTML 25 SIP Session Initiation Protocol REFER

The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. [STANDARDS-TRACK]

 draft-ietf-sip-referredby-05 RFC8217 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3892 RFC3893 Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format J. Peterson September 2004 ASCII HTML 13 SIP Session Initiation Protocol authenticated identity body digitally-signed SIP message message fragment Authenticated Identity Bodies AIB

RFC 3261 introduces the concept of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. [STANDARDS-TRACK]

 draft-ietf-sip-authid-body-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3893 RFC3894 Sieve Extension: Copying Without Side Effects J. Degener October 2004 ASCII HTML 5 Sieve client server

The Sieve scripting language allows users to control handling and disposal of their incoming e-mail. By default, an e-mail message that is processed by a Sieve script is saved in the owner's "inbox". Actions such as "fileinto" and "redirect" cancel this default behavior.

This document defines a new keyword parameter, ":copy", to be used with the Sieve "fileinto" and "redirect" actions. Adding ":copy" to an action suppresses cancellation of the default "inbox" save. It allows users to add commands to an existing script without changing the meaning of the rest of the script. [STANDARDS-TRACK]

 draft-degener-sieve-copy-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3894 RFC3895 Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types O. Nicklass Editor September 2004 ASCII HTML 84 MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 2495. [STANDARDS-TRACK]

 draft-ietf-atommib-rfc2495bis-06 RFC2495 RFC4805 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC3895 RFC3896 Definitions of Managed Objects for the DS3/E3 Interface Type O. Nicklass Editor September 2004 ASCII HTML 63 DS3-E3-MIB management information base Interface Type

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS1/E1/DS2/E2 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 2496. [STANDARDS-TRACK]

 draft-ietf-atommib-rfc2496bis-06 RFC2496 PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC3896 RFC3897 Open Pluggable Edge Services (OPES) Entities and End Points Communication A. Barbir September 2004 ASCII HTML 14 tracing non-blocking bypass

This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). This memo provides information for the Internet community.

 draft-ietf-opes-end-comm-08 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3897 RFC3898 Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) V. Kalusivalingam October 2004 ASCII HTML 7 Network Information Service NIS Servers NIS+ Servers NIS Client Domain Name NIS+ Client Domain name DHCPv6 Dynamic Host Configuration Protocol for IPV6

This document describes four options for Network Information Service (NIS) related configuration information in Dynamic Host Configuration Protocol for IPv6 (DHCPv6): NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-opt-nisconfig-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3898 RFC3899 RFC3900 RFC3901 DNS IPv6 Transport Operational Guidelines A. Durand J. Ihren September 2004 ASCII HTML 5 DNS domain name system internet protocol

This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsop-ipv6-transport-guidelines-02 BCP0091 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC3901 RFC3902 The "application/soap+xml" media type M. Baker M. Nottingham September 2004 ASCII HTML 5

This document defines the "application/soap+xml" media type which can be used to describe SOAP 1.2 messages serialized as XML 1.0. This memo provides information for the Internet community.

 draft-baker-soap-media-reg-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3902 RFC3903 Session Initiation Protocol (SIP) Extension for Event State Publication A. Niemi Editor October 2004 ASCII HTML 32 SIP Session Initiation Protocol presence information package

This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information.

The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose. [STANDARDS-TRACK]

 draft-ietf-sip-publish-04 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3903 RFC3904 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks C. Huitema R. Austein S. Satapati R. van der Pol September 2004 ASCII HTML 19 home office internet protocol

This document analyzes issues involved in the transition of "unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically correspond to home networks or small office networks. A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6. Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed. This memo provides information for the Internet community.

 draft-ietf-v6ops-unmaneval-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3904 RFC3905 A Template for IETF Patent Disclosures and Licensing Declarations V. See Editor September 2004 ASCII HTML 9 ipr

This document describes a proposal for one form of a template for IETF patent disclosures and licensing declarations. The optional use of this template is meant to simplify the process of such disclosures and licensing declarations and to assist disclosers in providing the necessary information to meet the obligations documented in RFC 3668. This memo provides information for the Internet community.

 draft-ietf-ipr-template-09 INFORMATIONAL INFORMATIONAL IETF gen ipr http://www.rfc-editor.org/errata_search.php?rfc=3905 10.17487/RFC3905 RFC3906 Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels N. Shen H. Smit October 2004 ASCII HTML 8 hop-by-hop link-state routing protocols SPF shortest path first

This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts. In particular, this document describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by Traffic Engineering. This memo provides information for the Internet community.

 draft-ietf-rtgwg-igp-shortcut-01 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC3906 RFC3907 RFC3908 RFC3909 Lightweight Directory Access Protocol (LDAP) Cancel Operation K. Zeilenga October 2004 ASCII HTML 7 LDAP Lightweight Directory Access Protocol abandon operation outstanding operation

This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation, but like the X.511 Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome. [STANDARDS-TRACK]

 draft-zeilenga-ldap-cancel-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3909 RFC3910 The SPIRITS (Services in PSTN requesting Internet Services) Protocol V. Gurbani Editor A. Brusilovsky I. Faynberg J. Gato H. Lu M. Unmehopa October 2004 ASCII HTML 50 SPIRTS pstn Public Switched Telephone Network sip services event notification eventpackages internet call waiting xml wireless intelligent network IN detection point dp

This document describes the Services in PSTN (Public Switched Telephone Network) requesting Internet Services (SPIRITS) protocol. The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline PSTN and necessitate interactions between the PSTN and the Internet. On the PSTN side, the SPIRITS services are most often initiated from the Intelligent Network (IN) entities. Internet Call Waiting and Internet Caller-ID Delivery are examples of SPIRITS services, as are location-based services on the cellular network. The protocol defines the building blocks from which many other services can be built. [STANDARDS-TRACK]

 draft-ietf-spirits-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv spirits 10.17487/RFC3910 RFC3911 The Session Initiation Protocol (SIP) "Join" Header R. Mahy D. Petrie October 2004 ASCII HTML 17 SIP Session Initiation Protocol Join header

This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call Center Monitoring". Note that definition of these example features is non-normative. [STANDARDS-TRACK]

 draft-ietf-sip-join-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3911 RFC3912 WHOIS Protocol Specification L. Daigle September 2004 ASCII HTML 4 WHOIS NICNAME

This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954. [STANDARDS-TRACK]

 draft-daigle-rfc954bis-01 RFC0954 RFC0812 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC3912 RFC3913 Border Gateway Multicast Protocol (BGMP): Protocol Specification D. Thaler September 2004 ASCII HTML 41 enter-domain source-specific multicast ssm

This document describes the Border Gateway Multicast Protocol (BGMP), a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed. BGMP natively supports "source-specific multicast" (SSM). To also support "any-source multicast" (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the multicast address space are associated (e.g., with Unicast-Prefix-Based Multicast addressing) with different domains. Each of these domains then becomes the root of the shared domain-trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants. This memo provides information for the Internet community.

 draft-ietf-bgmp-spec-06 HISTORIC INFORMATIONAL IETF rtg bgmp 10.17487/RFC3913 RFC3914 Open Pluggable Edge Services (OPES) Treatment of IAB Considerations A. Barbir A. Rousskov October 2004 ASCII HTML 16

IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. This memo provides information for the Internet community.

 draft-ietf-opes-iab-05 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3914 RFC3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) S. Hollenbeck September 2004 ASCII HTML 23 DNS Domain Name System EPP Extensible Provisioning Protocol

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing. [STANDARDS-TRACK]

 draft-hollenbeck-epp-rgp-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3915 RFC3916 Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) X. Xiao Editor D. McPherson Editor P. Pate Editor September 2004 ASCII HTML 19

This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e., "synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves. This memo provides information for the Internet community.

 draft-ietf-pwe3-requirements-08 INFORMATIONAL INFORMATIONAL IETF int pwe3 10.17487/RFC3916 RFC3917 Requirements for IP Flow Information Export (IPFIX) J. Quittek T. Zseby B. Claise S. Zander October 2004 ASCII HTML 33 ipfix routers measurment middleboxes

This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes. This memo provides information for the Internet community.

 draft-ietf-ipfix-reqs-16 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC3917 RFC3918 Methodology for IP Multicast Benchmarking D. Stopp B. Hickman October 2004 ASCII HTML 31

The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.

The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. This memo provides information for the Internet community.

 draft-ietf-bmwg-mcastm-14 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3918 RFC3919 Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS) E. Stephan J. Palet October 2004 ASCII HTML 8 mib

This memo defines additional (to those in RFC 2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable ``INDEX`` encodings, as defined by the Remote Network Monitoring MIB (Management Information Base) Version 2 [RFC2021] and the RMON Protocol Identifier Reference [RFC2895].

This document contains additional (to those in RFC 2896) protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard. It is published to encourage better interoperability between RMON-2 agent implementations, by providing RMON related IPv6 and MPLS protocol information. This memo provides information for the Internet community.

 draft-ietf-rmonmib-pi-ipv6-04 INFORMATIONAL INFORMATIONAL IETF ops rmonmib 10.17487/RFC3919 RFC3920 Extensible Messaging and Presence Protocol (XMPP): Core P. Saint-Andre Editor October 2004 ASCII HTML 30 instant messaging im extensible markup language xml jabber

This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. [STANDARDS-TRACK]

 draft-ietf-xmpp-core-24 RFC6120 RFC6122 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp http://www.rfc-editor.org/errata_search.php?rfc=3920 10.17487/RFC3920 RFC3921 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence P. Saint-Andre Editor October 2004 ASCII HTML 107 instant messaging im extensible markup language xml jabber

This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779. [STANDARDS-TRACK]

 draft-ietf-xmpp-im-22 RFC6121 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp 10.17487/RFC3921 RFC3922 Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM) P. Saint-Andre October 2004 ASCII HTML 34 xml extensible markup language im instant messaging jabber

This memo describes a mapping between the Extensible Messaging and Presence Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM) specifications. [STANDARDS-TRACK]

 draft-ietf-xmpp-cpim-05 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp 10.17487/RFC3922 RFC3923 End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre October 2004 ASCII HTML 27 xml extensible markup language im instant messaging jabber

This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]

 draft-ietf-xmpp-e2e-09 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp http://www.rfc-editor.org/errata_search.php?rfc=3923 10.17487/RFC3923 RFC3924 Cisco Architecture for Lawful Intercept in IP Networks F. Baker B. Foster C. Sharp October 2004 ASCII HTML 18

For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country. This memo provides information for the Internet community.

 draft-baker-slem-architecture-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3924 RFC3925 Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) J. Littlefield October 2004 ASCII HTML 9 dhc dhcp Dynamic Host Configuration Protocol class vendor-specific

The Dynamic Host Configuration Protocol (DHCP) options for Vendor Class and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity. [STANDARDS-TRACK]

 draft-ietf-dhc-vendor-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3925 RFC3926 FLUTE - File Delivery over Unidirectional Transport T. Paila M. Luby R. Lehtonen V. Roca R. Walsh October 2004 ASCII HTML 35 FLUTE File Delivery over Unidirectional Transport

This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-flute-08 RFC6726 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=3926 10.17487/RFC3926 RFC3927 Dynamic Configuration of IPv4 Link-Local Addresses S. Cheshire B. Aboba E. Guttman May 2005 ASCII HTML 33 Dynamic Configuration ip network ip address 169.254/16

To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.

IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS-TRACK]

 draft-ietf-zeroconf-ipv4-linklocal-17 PROPOSED STANDARD PROPOSED STANDARD IETF int zeroconf http://www.rfc-editor.org/errata_search.php?rfc=3927 10.17487/RFC3927 RFC3928 Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP) R. Megginson Editor M. Smith O. Natkovich J. Parham October 2004 ASCII HTML 30 LDAP Lightweight Directory Access Protocol LCUP Client Update Protocol

This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. [STANDARDS-TRACK]

 draft-ietf-ldup-lcup-06 PROPOSED STANDARD PROPOSED STANDARD IETF app ldup 10.17487/RFC3928 RFC3929 Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF T. Hardie October 2004 ASCII HTML 11

This document proposes an experimental set of alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. This memo defines an Experimental Protocol for the Internet community.

 draft-hardie-alt-consensus-02 RFC8717 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3929 10.17487/RFC3929 RFC3930 The Protocol versus Document Points of View in Computer Protocols D. Eastlake 3rd October 2004 ASCII HTML 15

This document contrasts two points of view: the "document" point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the "protocol" point of view where objects of interest are composite dynamic network messages. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced. This memo provides information for the Internet community.

 draft-eastlake-proto-doc-pov-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3930 RFC3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3) J. Lau Editor M. Townsley Editor I. Goyret Editor March 2005 ASCII HTML 94 L2TP Layer Two Tunneling Protocol ppp point-to-point protocol packets

This document describes "version 3" of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated. [STANDARDS-TRACK]

 draft-ietf-l2tpext-l2tp-base-15 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext http://www.rfc-editor.org/errata_search.php?rfc=3931 10.17487/RFC3931 RFC3932 The IESG and RFC Editor Documents: Procedures H. Alvestrand October 2004 ASCII HTML 8 IESG RFC Editor independent submission

This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004.

This document updates procedures described in RFC 2026 and RFC 3710. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-iesg-rfced-documents-03 RFC5742 RFC2026 RFC3710 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC3932 RFC3933 A Model for IETF Process Experiments J. Klensin S. Dawkins November 2004 ASCII HTML 7 Experiments

The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification. The first mechanism has often proven to be too lightweight, the second too heavyweight.

This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model rather than those previously attempted. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-klensin-process-july14-02 BCP0093 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3933 10.17487/RFC3933 RFC3934 Updates to RFC 2418 Regarding the Management of IETF Mailing Lists M. Wasserman October 2004 ASCII HTML 5 BCP WG escape clause procedures

This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-wasserman-rfc2418-ml-update-01 RFC2418 BCP0025 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3934 RFC3935 A Mission Statement for the IETF H. Alvestrand October 2004 ASCII HTML 7 Mission Statement

This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-alvestrand-ietf-mission-02 BCP0095 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3935 RFC3936 Procedures for Modifying the Resource reSerVation Protocol (RSVP) K. Kompella J. Lang October 2004 ASCII HTML 7 RSVP resource reservation protocol label switched paths

This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-kompella-rsvp-change-02 RFC3209 RFC2205 BCP0096 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3936 RFC3937 A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC) M. Steidl October 2004 ASCII HTML 9

This document describes a URN (Uniform Resource Name) namespace for identifying persistent resources published by the International Press Telecommunications Council (IPTC). These resources include XML Data Type Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets, other XML based document and documents of other data formats like PDF documents, Microsoft Office documents and others. This memo provides information for the Internet community.

 draft-steidl-iptc-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3937 RFC3938 Video-Message Message-Context T. Hansen October 2004 ASCII HTML 4 user agent ua

The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message or voice-message). This specification extends the Message-Context header with one additional context value: "video-message".

A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]

 draft-hansen-lemonade-msgctxt-videomsg-01 RFC3458 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3938 RFC3939 Calling Line Identification for Voice Mail Messages G. Parsons J. Maruszak December 2004 ASCII HTML 11 Voice Mail

This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller_ID and Called_Name. Caller_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message. Caller-name provides the name of the person sending the message. [STANDARDS-TRACK]

 draft-ema-vpim-clid-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3939 10.17487/RFC3939 RFC3940 Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol B. Adamson C. Bormann M. Handley J. Macker November 2004 ASCII HTML 80 NACK Negative-acknowledgement Oriented Reliable Multicast NORM

This document describes the messages and procedures of the Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-pi-norm-10 RFC5740 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3940 RFC3941 Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks B. Adamson C. Bormann M. Handley J. Macker November 2004 ASCII HTML 36 NACK Negative-acknowledgement Oriented Reliable Multicast NORM

This document discusses the creation of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-bb-norm-09 RFC5401 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3941 RFC3942 Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options B. Volz November 2004 ASCII HTML 7 DHCP-BOOTP Bootstrap Dynamic Host Configuration Protocol

This document updates RFC 2132 to reclassify Dynamic Host Configuration Protocol version 4 (DHCPv4) option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. [STANDARDS-TRACK]

 draft-ietf-dhc-reclassify-options-01 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3942 10.17487/RFC3942 RFC3943 Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS) R. Friend November 2004 ASCII HTML 13 lossless data compression algorithm TLS Record Protocol

The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol. This memo provides information for the Internet community.

 draft-friend-tls-lzs-compression-04 RFC8996 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3943 RFC3944 H.350 Directory Services T. Johnson S. Okubo S. Campos December 2004 ASCII HTML 30 ldap directory services h.350 h.323 h.320 h.235 sip

The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to 'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store. Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T Recommendations H.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version. This memo provides information for the Internet community.

 draft-johnson-h350-directory-serv-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3944 10.17487/RFC3944 RFC3945 Generalized Multi-Protocol Label Switching (GMPLS) Architecture E. Mannie Editor October 2004 ASCII HTML 69 GMPLS Generalized Multi-Protocol Label Switching

Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-architecture-07 RFC6002 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=3945 10.17487/RFC3945 RFC3946 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control E. Mannie D. Papadimitriou October 2004 ASCII HTML 26

This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-sonet-sdh-08 RFC4606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC3946 RFC3947 Negotiation of NAT-Traversal in the IKE T. Kivinen B. Swander A. Huttunen V. Volpe January 2005 ASCII HTML 16 IKE Internet Key Exchange

This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE). [STANDARDS-TRACK]

 draft-ietf-ipsec-nat-t-ike-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=3947 10.17487/RFC3947 RFC3948 UDP Encapsulation of IPsec ESP Packets A. Huttunen B. Swander V. Volpe L. DiBurro M. Stenberg January 2005 ASCII HTML 15 IPsec ESP Encapsulating Security Payload

This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE). [STANDARDS-TRACK]

 draft-ietf-ipsec-udp-encaps-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=3948 10.17487/RFC3948 RFC3949 File Format for Internet Fax R. Buckley D. Venable L. McIntyre G. Parsons J. Rafferty February 2005 ASCII HTML 84 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex B, are based on discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing.

This RFC 2301 revision describes the Tag Image File Format (TIFF) representation of image data specified by the International Telecommunication Union (ITU-T) Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF for Fax eXtended (TIFF-FX). It formally defines minimal, extended, and lossless Joint Bi-level Image experts Group (JBIG) profiles (Profiles S, F, J) for black-and-white fax and base JPEG, lossless JBIG, and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. [STANDARDS-TRACK]

 draft-ietf-fax-tiff-fx-14 RFC2301 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3949 RFC3950 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration L. McIntyre G. Parsons J. Rafferty February 2005 ASCII HTML 8 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS-TRACK]

 draft-ietf-fax-tiff-fx-reg-v2-01 RFC3250 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3950 RFC3951 Internet Low Bit Rate Codec (iLBC) S. Andersen A. Duric H. Astrom R. Hagen W. Kleijn J. Linden December 2004 ASCII HTML 194 iLBC Internet Low Bit Rate Codec

This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound (GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-avt-ilbc-codec-05 EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC3951 RFC3952 Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech A. Duric S. Andersen December 2004 ASCII HTML 13 RTP Real-time Transport Protocol iLBC internet Low Bit Rate Codec

This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME and Session Description Protocol (SDP). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-avt-rtp-ilbc-05 EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC3952 RFC3953 Telephone Number Mapping (ENUM) Service Registration for Presence Services J. Peterson January 2005 ASCII HTML 7 uniform resource identifier uri provisioning pres ENUM Telephone Number Mapping

This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning pres URIs in ENUM. [STANDARDS-TRACK]

 draft-ietf-enum-pres-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3953 RFC3954 Cisco Systems NetFlow Services Export Version 9 B. Claise Editor October 2004 ASCII HTML 33

This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics. This memo provides information for the Internet community.

 draft-claise-netflow-9-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3954 10.17487/RFC3954 RFC3955 Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) S. Leinen October 2004 ASCII HTML 23

This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification. This memo provides information for the Internet community.

 draft-leinen-ipfix-eval-contrib-03 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC3955 RFC3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address P. Savola B. Haberman November 2004 ASCII HTML 18 RP Rendezvous Point internet protocol

This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. [STANDARDS-TRACK]

 draft-ietf-mboned-embeddedrp-07 RFC3306 RFC7371 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC3956 RFC3957 Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4 C. Perkins P. Calhoun March 2005 ASCII HTML 27

Authentication, Authorization, and Accounting (AAA) servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent. When the mobile node shares an AAA Security Association with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility Security Associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent. [STANDARDS-TRACK]

 draft-ietf-mip4-aaa-key-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC3957 RFC3958 Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS) L. Daigle A. Newton January 2005 ASCII HTML 25 DDDS Dynamic Delegation Discovery System

This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. [STANDARDS-TRACK]

 draft-daigle-snaptr-01 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3958 10.17487/RFC3958 RFC3959 The Early Session Disposition Type for the Session Initiation Protocol (SIP) G. Camarillo December 2004 ASCII HTML 11 SIP Session Initiation Protocol

This document defines a new disposition type (early-session) for the Content-Disposition header field in the Session Initiation Protocol (SIP). The treatment of "early-session" bodies is similar to the treatment of "session" bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is "early-session" are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs. [STANDARDS-TRACK]

 draft-ietf-sipping-early-disposition-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3959 10.17487/RFC3959 RFC3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) G. Camarillo H. Schulzrinne December 2004 ASCII HTML 13

This document describes how to manage early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation. This memo provides information for the Internet community.

 draft-ietf-sipping-early-media-02 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3960 RFC3961 Encryption and Checksum Specifications for Kerberos 5 K. Raeburn February 2005 ASCII HTML 50

This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement". [STANDARDS-TRACK]

 draft-ietf-krb-wg-crypto-07 RFC8429 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=3961 10.17487/RFC3961 RFC3962 Advanced Encryption Standard (AES) Encryption for Kerberos 5 K. Raeburn February 2005 ASCII HTML 16 kerberos cryptosystem suite

The United States National Institute of Standards and Technology (NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the old Data Encryption Standard (DES) algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite. [STANDARDS-TRACK]

 draft-raeburn-krb-rijndael-krb-07 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC3962 RFC3963 Network Mobility (NEMO) Basic Support Protocol V. Devarapalli R. Wakikawa A. Petrescu P. Thubert January 2005 ASCII HTML 33 mobile ipv6 session continuity

This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network. [STANDARDS-TRACK]

 draft-ietf-nemo-basic-support-03 PROPOSED STANDARD PROPOSED STANDARD IETF int nemo 10.17487/RFC3963 RFC3964 Security Considerations for 6to4 P. Savola C. Patel December 2004 ASCII HTML 41

The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems. This memo provides information for the Internet community.

 draft-ietf-v6ops-6to4-security-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=3964 10.17487/RFC3964 RFC3965 A Simple Mode of Facsimile Using Internet Mail K. Toyoda H. Ohno J. Murai D. Wing December 2004 ASCII HTML 14 SMFAX-IM Simple Mode of Facsimile Using Internet Mail data file format e-mail

This specification provides for "simple mode" carriage of facsimile data using Internet mail. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, Multipurpose Internet Mail Extensions (MIME), and Tagged Image File Format (TIFF) for Facsimile. It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them.

This document is a revision of RFC 2305. There have been no technical changes. [STANDARDS-TRACK]

 draft-ietf-fax-service-v2-05 RFC2305 DRAFT STANDARD DRAFT STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=3965 10.17487/RFC3965 RFC3966 The tel URI for Telephone Numbers H. Schulzrinne December 2004 ASCII HTML 17 URI uniform resource identifier locator schemes tel

This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS-TRACK]

 draft-ietf-iptel-rfc2806bis-09 RFC2806 RFC5341 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel http://www.rfc-editor.org/errata_search.php?rfc=3966 10.17487/RFC3966 RFC3967 Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level R. Bush T. Narten December 2004 ASCII HTML 6

IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ymbk-downref-03 RFC4897 RFC8067 BCP0097 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3967 10.17487/RFC3967 RFC3968 The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP) G. Camarillo December 2004 ASCII HTML 8 SIP Session Initiation Protocol

This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sip-parameter-registry-02 RFC3427 BCP0098 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sip 10.17487/RFC3968 RFC3969 The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP) G. Camarillo December 2004 ASCII HTML 6 SIP Session Initiation Protocol

This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) and SIPS Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sip-uri-parameter-reg-02 RFC3427 RFC5727 BCP0099 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sip 10.17487/RFC3969 RFC3970 A Traffic Engineering (TE) MIB K. Kompella January 2005 ASCII HTML 44 MIB Management Information Base TE Traffic Engineering

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Traffic Engineered (TE) Tunnels; for example, Multi-Protocol Label Switched Paths. [STANDARDS-TRACK]

 draft-ietf-tewg-mib-08 RFC9141 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3970 10.17487/RFC3970 RFC3971 SEcure Neighbor Discovery (SEND) J. Arkko Editor J. Kempf B. Zill P. Nikander March 2005 ASCII HTML 56 Neighbor Discovery Protocol NDP

IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS-TRACK]

 draft-ietf-send-ndopt-06 RFC6494 RFC6495 RFC6980 PROPOSED STANDARD PROPOSED STANDARD IETF int send http://www.rfc-editor.org/errata_search.php?rfc=3971 10.17487/RFC3971 RFC3972 Cryptographically Generated Addresses (CGA) T. Aura March 2005 ASCII HTML 22 Secure Neighbor Discovery SEND

This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. [STANDARDS-TRACK]

 draft-ietf-send-cga-06 RFC4581 RFC4982 PROPOSED STANDARD PROPOSED STANDARD IETF int send 10.17487/RFC3972 RFC3973 Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) A. Adams J. Nicholas W. Siadak January 2005 ASCII HTML 61 multicast routing protocol prune messages

This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-pim-dm-new-v2-05 RFC8736 EXPERIMENTAL EXPERIMENTAL IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=3973 10.17487/RFC3973 RFC3974 SMTP Operational Experience in Mixed IPv4/v6 Environments M. Nakamura J. Hagino January 2005 ASCII HTML 10 simple mail transfer protocol dual stack dualstack ipv4 ipv6

This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation.

This document does not define any new protocol. This memo provides information for the Internet community.

 draft-motonori-dualstack-smtp-requirement-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3974 RFC3975 OMA-IETF Standardization Collaboration G. Huston Editor I. Leuca Editor January 2005 ASCII HTML 9 oopen mobile alliance ietf internet engineering task force

This document describes the standardization collaboration between the Open Mobile Alliance (OMA) and the Internet Engineering Task Force (IETF). This memo provides information for the Internet community.

 draft-iab-oma-liaison-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3975 RFC3976 Interworking SIP and Intelligent Network (IN) Applications V. K. Gurbani F. Haerens V. Rastogi January 2005 ASCII HTML 25 sip intelligent network call models call model mapping telephony services public switched telephone network pstn

Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call. The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP). This memo provides information for the Internet community.

 draft-gurbani-sin-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3976 RFC3977 Network News Transfer Protocol (NNTP) C. Feather October 2006 ASCII HTML 125 usenet netnews

The Network News Transfer Protocol (NNTP) has been in use in the Internet for a decade, and remains one of the most popular protocols (by volume) in use today. This document is a replacement for RFC 977, and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific mechanism to add standardized extensions to NNTP. [STANDARDS-TRACK]

 draft-ietf-nntpext-base-27 RFC0977 RFC2980 RFC6048 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=3977 10.17487/RFC3977 RFC3978 IETF Rights in Contributions S. Bradner Editor March 2005 ASCII HTML 18 Intellectual Property Rights IPR copyright

The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3979, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ipr-subm-rights-fix-00 RFC3667 RFC5378 RFC2026 RFC4748 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr http://www.rfc-editor.org/errata_search.php?rfc=3978 10.17487/RFC3978 RFC3979 Intellectual Property Rights in IETF Technology S. Bradner Editor March 2005 ASCII HTML 17 IPR Intellectual Property Rights copyright

The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 RFC3668 RFC8179 RFC2026 RFC2028 RFC4879 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC3979 RFC3980 T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names M. Krueger M. Chadalapaka R. Elliott February 2005 ASCII HTML 8 internet small computer systems interface scsi transport protocol

Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the "Network Address Authority" (NAA) worldwide naming format defined by the InterNational Committee for Information Technology Standards (INCITS) T11 - Fibre Channel (FC) protocols and used by Serial Attached SCSI (SAS). This document updates RFC 3720. [STANDARDS-TRACK]

 draft-ietf-ips-iscsi-name-ext-05 RFC7143 RFC3720 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3980 RFC3981 IRIS: The Internet Registry Information Service (IRIS) Core Protocol A. Newton M. Sanz January 2005 ASCII HTML 52

This document describes an application layer client-server protocol for a framework to represent the query and result operations of the information services of Internet registries. Specified in the Extensible Markup Language (XML), the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. [STANDARDS-TRACK]

 draft-ietf-crisp-iris-core-07 RFC4992 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=3981 10.17487/RFC3981 RFC3982 IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS) A. Newton M. Sanz January 2005 ASCII HTML 50

This document describes an Internet Registry Information Service (IRIS) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. [STANDARDS-TRACK]

 draft-ietf-crisp-iris-dreg-07 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=3982 10.17487/RFC3982 RFC3983 Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) A. Newton M. Sanz January 2005 ASCII HTML 12

This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS). [STANDARDS-TRACK]

 draft-ietf-crisp-iris-beep-07 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp 10.17487/RFC3983 RFC3984 RTP Payload Format for H.264 Video S. Wenger M.M. Hannuksela T. Stockhammer M. Westerlund D. Singer February 2005 ASCII HTML 83 ITU-T Recommendation H.264 ISO/IEC International Standard 14496-10

This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-h264-11 RFC6184 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3984 RFC3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture S. Bryant Editor P. Pate Editor March 2005 ASCII HTML 42

This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community.

 draft-ietf-pwe3-arch-07 RFC5462 INFORMATIONAL INFORMATIONAL IETF int pwe3 10.17487/RFC3985 RFC3986 Uniform Resource Identifier (URI): Generic Syntax T. Berners-Lee R. Fielding L. Masinter January 2005 ASCII HTML 61 Internet protocol IP uniform resource identifier URI www world wide web

A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]

 draft-fielding-uri-rfc2396bis-07 RFC2732 RFC2396 RFC1808 RFC1738 RFC6874 RFC7320 RFC8820 STD0066 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3986 10.17487/RFC3986 RFC3987 Internationalized Resource Identifiers (IRIs) M. Duerst M. Suignard January 2005 ASCII HTML 46 uri uniform resource identifier Universal Character Set

This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources.

The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.

 draft-duerst-iri-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3987 10.17487/RFC3987 RFC3988 Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol B. Black K. Kompella January 2005 ASCII HTML 9 mtu ldp lsp label switched path label switching router lsr

Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU) discovery requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, the Label Distribution Protocol (LDP) does not have the ability to signal the MTU for a Label Switched Path (LSP) to the ingress Label Switching Router (LSR). In the absence of this functionality, the MTU for each LSP must be statically configured by network operators or by equivalent off-line mechanisms. This document specifies experimental extensions to LDP in support of LSP MTU discovery. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mpls-ldp-mtu-extensions-03 EXPERIMENTAL EXPERIMENTAL IETF rtg mpls 10.17487/RFC3988 RFC3989 Middlebox Communications (MIDCOM) Protocol Semantics M. Stiemerling J. Quittek T. Taylor February 2005 ASCII HTML 70 nat network address translator firewall

This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This memo provides information for the Internet community.

 draft-ietf-midcom-semantics-08 RFC5189 INFORMATIONAL INFORMATIONAL IETF tsv midcom 10.17487/RFC3989 RFC3990 Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement B. O'Hara P. Calhoun J. Kempf February 2005 ASCII HTML 5

This document describes the Configuration and Provisioning for Wireless Access Points (CAPWAP) problem statement. This memo provides information for the Internet community.

 draft-ietf-capwap-problem-statement-02 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC3990 RFC3991 Media Gateway Control Protocol (MGCP) Redirect and Reset Package B. Foster F. Andreasen February 2005 ASCII HTML 11 voice IP internet VoIP

The base Media Gateway Control Protocol (MGCP) specification (RFC 3435) allows endpoints to be redirected one endpoint at a time. This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints. It also includes the ability to more accurately redirect endpoints by allowing a list of Call Agents to be specified in a preferred order. This memo provides information for the Internet community.

 draft-foster-mgcp-redirect-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3991 RFC3992 Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism B. Foster F. Andreasen February 2005 ASCII HTML 5 fault recovery

A Media Gateway Control Protocol (MGCP) endpoint that has encountered an adverse failure condition (such as being involved in a transient call when a Call Agent failover occurred) could be left in a lockstep state whereby events are quarantined but not notified. The MGCP package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures. This memo provides information for the Internet community.

 draft-foster-mgcp-lockstep-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3992 RFC3993 Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option R. Johnson T. Palaniappan M. Stapp March 2005 ASCII HTML 7

This memo defines a new Subscriber-ID suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable "Subscriber-ID" with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure. [STANDARDS-TRACK]

 draft-ietf-dhc-subscriber-id-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3993 RFC3994 Indication of Message Composition for Instant Messaging H. Schulzrinne January 2005 ASCII HTML 13 im status message content type xml extensible markup language

In instant messaging (IM) systems, it is useful to know during an IM conversation whether the other party is composing a message; e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice, or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves. [STANDARDS-TRACK]

 draft-ietf-simple-iscomposing-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC3994 RFC3995 Internet Printing Protocol (IPP): Event Notifications and Subscriptions R. Herriot T. Hastings March 2005 ASCII HTML 95 optional subscription events subscription objects asynchronous even notification

This document describes an OPTIONAL extension to the Internet Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). This extension allows a client to subscribe to printing related Events. Subscriptions are modeled as Subscription Objects. The Subscription Object specifies that when one of the specified Events occurs, the Printer delivers an asynchronous Event Notification to the specified Notification Recipient via the specified Push or Pull Delivery Method (i.e., protocol). A client associates Subscription Objects with a particular Job by performing the Create-Job-Subscriptions operation or by submitting a Job with subscription information. A client associates Subscription Objects with the Printer by performing a Create-Printer-Subscriptions operation. Four other operations are defined for Subscription Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, and Cancel-Subscription. [STANDARDS-TRACK]

 draft-ietf-ipp-not-spec-12 RFC2911 RFC2910 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp 10.17487/RFC3995 RFC3996 Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications R. Herriot T. Hastings H. Lewis March 2005 ASCII HTML 31 pull delivery method event notifications event subscriptions

This document describes an extension to the Internet Printing Protocol1.1: Model and Semantics (RFC 2911, RFC 2910). This document specifies the 'ippget' Pull Delivery Method for use with the "Internet Printing Protocol (IPP): Event Notifications and Subscriptions" specification (RFC 3995). This IPPGET Delivery Method is REQUIRED for all clients and Printers that support RFC 3995. The Notification Recipient, acting as a client, fetches (pulls) Event Notifications by using the Get-Notifications operation defined in this document. [STANDARDS-TRACK]

 draft-ietf-ipp-notify-get-10 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3996 10.17487/RFC3996 RFC3997 Internet Printing Protocol (IPP): Requirements for IPP Notifications T. Hastings Editor R. K. deBry H. Lewis March 2005 ASCII HTML 17 model directory services notification requirements

This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application-level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPP Service. This memo provides information for the Internet community.

 draft-ietf-ipp-not-07 INFORMATIONAL INFORMATIONAL IETF app ipp 10.17487/RFC3997 RFC3998 Internet Printing Protocol (IPP): Job and Printer Administrative Operations C. Kugler H. Lewis T. Hastings Editor March 2005 ASCII HTML 46 system administration operations Enable-Printer and Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs and Release-Held-New-Jobs Deactivate-Printer and Activate-Printer Restart-Printer Shutdown-Printer and Startup-Printer Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Promote-Job Schedule-Job-After

This document specifies the following 16 additional OPTIONAL system administration operations for use with the Internet Printing Protocol/1.1 (IPP), plus a few associated attributes, values, and status codes, and using the IPP Printer object to manage printer fan-out and fan-in. (Printer operations: Enable-Printer and Disable-Printer, Pause-Printer-After-Current-Job, Hold-New-Jobs and Release-Held-New-Jobs, Deactivate-Printer and Activate-Printer, Restart-Printer, Shutdown-Printer and Startup-Printer. Job operations: Reprocess-Job, Cancel-Current-Job, Suspend-Current-Job, Resume-Job, Promote-Job, Schedule-Job-After.) [STANDARDS-TRACK]

 draft-ietf-ipp-ops-set2-04 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3998 10.17487/RFC3998 RFC3999 RFC4000 RFC4001 Textual Conventions for Internet Network Addresses M. Daniele B. Haberman S. Routhier J. Schoenwaelder February 2005 ASCII HTML 22 MIB management information base internet network layer addressing information

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-ops-rfc3291bis-06 RFC3291 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4001 RFC4002 IANA Registration for Enumservice 'web' and 'ft' R. Brandner L. Conroy R. Stastny February 2005 ASCII HTML 10 URI schemes uniform resource identifier enum

This document registers the Enumservices 'web' and 'ft' by using the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification (RFC 3761). [STANDARDS-TRACK]

 draft-ietf-enum-webft-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4002 RFC4003 GMPLS Signaling Procedure for Egress Control L. Berger February 2005 ASCII HTML 5 lsp label switch path gmpls signaling

This document clarifies the procedures for the control of the label used on an output/downstream interface of the egress node of a Label Switched Path (LSP). This control is also known as "Egress Control". Support for Egress Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Signaling. This document clarifies the specification of GMPLS Signaling and does not modify GMPLS signaling mechanisms and procedures. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-egress-control-03 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4003 RFC4004 Diameter Mobile IPv4 Application P. Calhoun T. Johansson C. Perkins T. Hiller Editor P. McCann August 2005 ASCII HTML 53 internet protocol version 4 aaa authentication authorization accounting inter-realm diameter accounting

This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers. [STANDARDS-TRACK]

 draft-ietf-aaa-diameter-mobileip-20 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4004 10.17487/RFC4004 RFC4005 Diameter Network Access Server Application P. Calhoun G. Zorn D. Spence D. Mitton August 2005 ASCII HTML 85 aaa authentication authorization accounting nas diameter base transport profile extensible authentication protocol radius

This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements.

Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application has been carefully designed to ease the burden of protocol conversion between RADIUS and Diameter. This is achieved by including the RADIUS attribute space to eliminate the need to perform many attribute translations.

The interactions between Diameter applications and RADIUS specified in this document are to be applied to all Diameter applications. In this sense, this document extends the Base Diameter protocol. [STANDARDS-TRACK]

 draft-ietf-aaa-diameter-nasreq-17 RFC7155 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4005 10.17487/RFC4005 RFC4006 Diameter Credit-Control Application H. Hakala L. Mattila J-P. Koskinen M. Stura J. Loughney August 2005 ASCII HTML 114 real-time credit-control

This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. [STANDARDS-TRACK]

 draft-ietf-aaa-diameter-cc-06 RFC8506 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4006 10.17487/RFC4006 RFC4007 IPv6 Scoped Address Architecture S. Deering B. Haberman T. Jinmei E. Nordmark B. Zill March 2005 ASCII HTML 24 architectural characteristics expected behavior textual representation

This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. [STANDARDS-TRACK]

 draft-ietf-ipv6-scoping-arch-02 RFC7346 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4007 RFC4008 Definitions of Managed Objects for Network Address Translators (NAT) R. Rohit P. Srisuresh R. Raghunarayan N. Pai C. Wang March 2005 ASCII HTML 64 mib management information base

This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for configuration as well as monitoring of a device capable of NAT function. [STANDARDS-TRACK]

 draft-ietf-nat-natmib-09 RFC7658 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4008 RFC4009 The SEED Encryption Algorithm J. Park S. Lee J. Kim J. Lee February 2005 ASCII HTML 17 encryption algorithm seed cbc seed oid

This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea. Included are a description of the cipher and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B). This memo provides information for the Internet community.

 draft-park-seed-01 RFC4269 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4009 10.17487/RFC4009 RFC4010 Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS) J. Park S. Lee J. Kim J. Lee February 2005 ASCII HTML 13 smime secure/multipurpose internet mail extensions

This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).

SEED is added to the set of optional symmetric encryption algorithms in CMS by providing two classes of unique object identifiers (OIDs). One OID class defines the content encryption algorithms and the other defines the key encryption algorithms. [STANDARDS-TRACK]

 draft-ietf-smime-cms-seed-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4010 10.17487/RFC4010 RFC4011 Policy Based Management MIB S. Waldbusser J. Saperia T. Hongal March 2005 ASCII HTML 121 management information base Simple Network Management Protocol snmp infrastructures scripting language script execution environment

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this MIB defines objects that enable policy-based monitoring and management of Simple Network Management Protocol (SNMP) infrastructures, a scripting language, and a script execution environment. [STANDARDS-TRACK]

 draft-ietf-snmpconf-pm-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpconf 10.17487/RFC4011 RFC4012 Routing Policy Specification Language next generation (RPSLng) L. Blunk J. Damas F. Parent A. Robachevsky March 2005 ASCII HTML 16

This memo introduces a new set of simple extensions to the Routing Policy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. [STANDARDS-TRACK]

 draft-blunk-rpslng-08 RFC2725 RFC2622 RFC7909 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4012 RFC4013 SASLprep: Stringprep Profile for User Names and Passwords K. Zeilenga February 2005 ASCII HTML 6 unicode strings saslprep stringprep sasl simple authentication and security layer

This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the "SASLprep" profile of the "stringprep" algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols exchanging simple user names and/or passwords. [STANDARDS-TRACK]

 draft-ietf-sasl-saslprep-10 RFC7613 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=4013 10.17487/RFC4013 RFC4014 Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option R. Droms J. Schnizlein February 2005 ASCII HTML 8

The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client. [STANDARDS-TRACK]

 draft-ietf-dhc-agentopt-radius-08 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4014 RFC4015 The Eifel Response Algorithm for TCP R. Ludwig A. Gurtov February 2005 ASCII HTML 13 transmision control protocol

Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided. [STANDARDS-TRACK]

 draft-ietf-tsvwg-tcp-eifel-response-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4015 RFC4016 Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements M. Parthasarathy March 2005 ASCII HTML 15 authentication network access

This document discusses the threats to protocols used to carry authentication for network access. The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol. This memo provides information for the Internet community.

 draft-ietf-pana-threats-eval-07 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC4016 RFC4017 Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs D. Stanley J. Walker B. Aboba March 2005 ASCII HTML 11 IEEE 802.11 wireless lan

The IEEE 802.11i MAC Security Enhancements Amendment makes use of IEEE 802.1X, which in turn relies on the Extensible Authentication Protocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community.

 draft-walker-ieee802-req-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4017 RFC4018 Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2) M. Bakke J. Hufferd K. Voruganti M. Krueger T. Sperry April 2005 ASCII HTML 23 scsi slp

The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. [PROPOSED STANDARD]

 draft-ietf-ips-iscsi-slp-09 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4018 RFC4019 RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite G. Pelletier April 2005 ASCII HTML 23 rtp udp-lite ip real-time transport protocol user datagram protocol lite internet protocol

This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095. [STANDARDS-TRACK]

 draft-ietf-rohc-udp-lite-04 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4019 RFC4020 Early IANA Allocation of Standards Track Code Points K. Kompella A. Zinin February 2005 ASCII HTML 7

This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols for which, by the IETF process, implementation and deployment experience is desired or required prior to publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-kompella-zinin-early-allocation-02 RFC7120 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4020 RFC4021 Registration of Mail and MIME Header Fields G. Klyne J. Palme March 2005 ASCII HTML 54 IANA

This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864. [STANDARDS-TRACK]

 draft-klyne-hdrreg-mail-05 RFC5322 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4021 RFC4022 Management Information Base for the Transmission Control Protocol (TCP) R. Raghunarayan Editor March 2005 ASCII HTML 24 MIB-TCP TCP Simple Network Management Protocol MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2452 and 2012. [STANDARDS-TRACK]

 draft-ietf-ipv6-rfc2012-update-06 RFC2452 RFC2012 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4022 RFC4023 Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) T. Worster Y. Rekhter E. Rosen Editor March 2005 ASCII HTML 14

Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation). Each of these is applicable in some circumstances. [STANDARDS-TRACK]

 draft-ietf-mpls-in-ip-or-gre-08 RFC5332 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4023 RFC4024 Voice Messaging Client Behaviour G. Parsons J. Maruszak July 2005 ASCII HTML 9 vpim profile internet mail voice profile for internet mail fax message

This document defines the expected behaviour of a client to various aspects of a Voice Profile for Internet Mail (VPIM) message or any voice and/or fax message. This memo provides information for the Internet community.

 draft-ema-vpim-cb-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4024 RFC4025 A Method for Storing IPsec Keying Material in DNS M. Richardson March 2005 ASCII HTML 12

This document describes a new resource record for the Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question.

This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445. [STANDARDS-TRACK]

 draft-ietf-ipseckey-rr-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipseckey 10.17487/RFC4025 RFC4026 Provider Provisioned Virtual Private Network (VPN) Terminology L. Andersson T. Madsen March 2005 ASCII HTML 20 l3vpn l2vpn

The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services.

To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community.

 draft-ietf-l3vpn-ppvpn-terminology-04 INFORMATIONAL INFORMATIONAL IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4026 10.17487/RFC4026 RFC4027 Domain Name System Media Types S. Josefsson April 2005 ASCII HTML 6 media type application/dns text/dns

This document registers the media types application/dns and text/dns in accordance with RFC 2048. The application/dns media type is used to identify data on the detached Domain Name System (DNS) format described in RFC 2540. The text/dns media type is used to identify master files as described in RFC 1035. This memo provides information for the Internet community.

 draft-josefsson-mime-dns-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4027 RFC4028 Session Timers in the Session Initiation Protocol (SIP) S. Donovan J. Rosenberg April 2005 ASCII HTML 27 re-invite request update request session-expires min-se

This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a \%re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: \%Session-Expires, which conveys the lifetime of the session, and \%Min-SE, which conveys the minimum allowed value for the session timer. [STANDARDS-TRACK]

 draft-ietf-sip-session-timer-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4028 10.17487/RFC4028 RFC4029 Scenarios and Analysis for Introducing IPv6 into ISP Networks M. Lind V. Ksinant S. Park A. Baudot P. Savola March 2005 ASCII HTML 28 internet service provider internet protocol

This document describes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated. Known challenges are also identified. This memo provides information for the Internet community.

 draft-ietf-v6ops-isp-scenarios-analysis-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4029 10.17487/RFC4029 RFC4030 The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option M. Stapp T. Lemon March 2005 ASCII HTML 15

The Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages. [STANDARDS-TRACK]

 draft-ietf-dhc-auth-suboption-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4030 RFC4031 Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs) M. Carugi Editor D. McDysan Editor April 2005 ASCII HTML 50 l3vpn service provider vpn

This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider. This memo provides information for the Internet community.

 draft-ietf-l3vpn-requirements-02 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4031 RFC4032 Update to the Session Initiation Protocol (SIP) Preconditions Framework G. Camarillo P. Kyzivat March 2005 ASCII HTML 10 qos quality of service precondition

This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility. [STANDARDS-TRACK]

 draft-ietf-sip-rfc3312-update-03 RFC3312 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4032 RFC4033 DNS Security Introduction and Requirements R. Arends R. Austein M. Larson D. Massey S. Rose March 2005 ASCII HTML 21 domain name system authentication origin integrity dnssec domain name system security extensions

The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-intro-13 RFC2535 RFC3008 RFC3090 RFC3445 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 RFC1034 RFC1035 RFC2136 RFC2181 RFC2308 RFC3225 RFC3597 RFC3226 RFC6014 RFC6840 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4033 10.17487/RFC4033 RFC4034 Resource Records for the DNS Security Extensions R. Arends R. Austein M. Larson D. Massey S. Rose March 2005 ASCII HTML 29 domain name system authentication origin integrity dnssec domain name system security extensions

This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.

This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-records-11 RFC2535 RFC3008 RFC3090 RFC3445 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 RFC1034 RFC1035 RFC2136 RFC2181 RFC2308 RFC3225 RFC3597 RFC3226 RFC4470 RFC6014 RFC6840 RFC6944 RFC9077 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4034 10.17487/RFC4034 RFC4035 Protocol Modifications for the DNS Security Extensions R. Arends R. Austein M. Larson D. Massey S. Rose March 2005 ASCII HTML 53 domain name system authentication origin integrity dnssec domain name system security extensions

This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.

This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-protocol-09 RFC2535 RFC3008 RFC3090 RFC3445 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 RFC1034 RFC1035 RFC2136 RFC2181 RFC2308 RFC3225 RFC3597 RFC3226 RFC4470 RFC6014 RFC6840 RFC8198 RFC9077 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4035 10.17487/RFC4035 RFC4036 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management W. Sawyer April 2005 ASCII HTML 27 mib snmp simple network management protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. [STANDARDS-TRACK]

 draft-ietf-ipcdn-subscriber-mib-16 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4036 RFC4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core A. Rousskov March 2005 ASCII HTML 56 callout server

This document specifies the core of the Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: An OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). As defined in this document, the OCP Core consists of application-agnostic mechanisms essential for efficient support of typical adaptations. [STANDARDS-TRACK]

 draft-ietf-opes-ocp-core-05 PROPOSED STANDARD PROPOSED STANDARD IETF app opes 10.17487/RFC4037 RFC4038 Application Aspects of IPv6 Transition M-K. Shin Editor Y-G. Hong J. Hagino P. Savola E. M. Castro March 2005 ASCII HTML 33

As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. This memo provides information for the Internet community.

 draft-ietf-v6ops-application-transition-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4038 10.17487/RFC4038 RFC4039 Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) S. Park P. Kim B. Volz March 2005 ASCII HTML 10

This document defines a new Dynamic Host Configuration Protocol version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4-message exchange, expediting client configuration. [STANDARDS-TRACK]

 draft-ietf-dhc-rapid-commit-opt-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4039 RFC4040 RTP Payload Format for a 64 kbit/s Transparent Call R. Kreuter April 2005 ASCII HTML 8 realtime transport protocol

This document describes how to carry 64 kbit/s channel data transparently in RTP packets, using a pseudo-codec called "Clearmode". It also serves as registration for a related MIME type called "audio/clearmode".

"Clearmode" is a basic feature of VoIP Media Gateways. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-clearmode-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4040 RFC4041 Requirements for Morality Sections in Routing Area Drafts A. Farrel April 1 2005 ASCII HTML 8 moral values moral code

It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal.

This document specifies a requirement for all new Routing Area Internet-Drafts to include a "Morality Considerations" section, and gives guidance on what that section should contain. This memo provides information for the Internet community.

 draft-farrel-rtg-morality-requirements-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4041 RFC4042 UTF-9 and UTF-18 Efficient Transformation Formats of Unicode M. Crispin April 1 2005 ASCII HTML 9 universal character set ucs codeopints unicode utf-7 utf-8 utf-16

ISO-10646 defines a large character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. The same set of codepoints is defined by Unicode, which further defines additional character properties and other implementation details. By policy of the relevant standardization committees, changes to Unicode and amendments and additions to ISO/IEC 10646 track each other, so that the character repertoires and code point assignments remain in synchronization.

The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet.

This document describes a transformation format of Unicode that takes advantage of the nonet so that the format will be storage and computation efficient. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4042 RFC4043 Internet X.509 Public Key Infrastructure Permanent Identifier D. Pinkas T. Gindin May 2005 ASCII HTML 15 subjectAltName extension dn

This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity.

The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed.

The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. [STANDARDS-TRACK]

 draft-ietf-pkix-pi-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4043 10.17487/RFC4043 RFC4044 Fibre Channel Management MIB K. McCloghrie May 2005 ASCII HTML 69 management information base fc-mgmt-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel. [STANDARDS-TRACK]

 draft-ietf-ips-fcmgmt-mib-06 RFC2837 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4044 RFC4045 Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP) G. Bourdon April 2005 ASCII HTML 28 ppp point-to-point protocol

The Layer Two Tunneling Protocol (L2TP) provides a method for tunneling PPP packets. This document describes an extension to L2TP, to make efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by these tunnels. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-l2tpext-mcast-05 EXPERIMENTAL EXPERIMENTAL IETF int l2tpext 10.17487/RFC4045 RFC4046 Multicast Security (MSEC) Group Key Management Architecture M. Baugher R. Canetti L. Dondeti F. Lindholm April 2005 ASCII HTML 38 group security association gsa

This document defines the common architecture for Multicast Security (MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication. This memo provides information for the Internet community.

 draft-ietf-msec-gkmarch-08 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC4046 RFC4047 MIME Sub-type Registrations for Flexible Image Transport System (FITS) S. Allen D. Wells April 2005 ASCII HTML 23 multipurpose internet mail extensions astronomical observations

This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of Flexible Image Transport System (FITS) files. The encoding is defined by the published FITS standard documents. The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged by using FITS. This memo provides information for the Internet community.

 draft-allen-fitsmime-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4047 RFC4048 RFC 1888 Is Obsolete B. Carpenter April 2005 ASCII HTML 4 Internet Protocol Open Systems Interconnection

This document recommends that RFC 1888, on Open Systems Interconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty. This memo provides information for the Internet community.

 draft-carpenter-obsolete-1888-01 RFC1888 RFC4548 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4048 10.17487/RFC4048 RFC4049 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 R. Housley April 2005 ASCII HTML 7 signing-time attribute cryptographic message syntax cms SignedData AuthenticatedData

This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 3852. This memo defines an Experimental Protocol for the Internet community.

 draft-housley-binarytime-02 RFC6019 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4049 RFC4050 Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures S. Blake-Wilson G. Karlinger T. Kobayashi Y. Wang April 2005 ASCII HTML 19 elliptic curve digital signature algorithm ecdsa elliptic curve cryptography ecc xml digital signatures xml dsig xml

This document specifies how to use Elliptic Curve Digital Signature Algorithm (ECDSA) with XML Signatures. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference. This memo provides information for the Internet community.

 draft-blake-wilson-xmldsig-ecdsa-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4050 RFC4051 Additional XML Security Uniform Resource Identifiers (URIs) D. Eastlake 3rd April 2005 ASCII HTML 17 digital signatures encryption canonicalization

A number of Uniform Resource Identifiers (URIs) intended for use with XML Digital Signatures, Encryption, and Canonicalization are defined. These URIs identify algorithms and types of keying information. [STANDARDS-TRACK]

 draft-eastlake-xmldsig-uri-09 RFC6931 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4051 10.17487/RFC4051 RFC4052 IAB Processes for Management of IETF Liaison Relationships L. Daigle Editor Internet Architecture Board April 2005 ASCII HTML 9 internet architecture board sdo standards development organization

This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-iab-liaison-mgt-03 BCP0102 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB http://www.rfc-editor.org/errata_search.php?rfc=4052 10.17487/RFC4052 RFC4053 Procedures for Handling Liaison Statements to and from the IETF S. Trowbridge S. Bradner F. Baker April 2005 ASCII HTML 19 sdo standards develoopment organization

This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community.

The IETF expects that liaison statements might come from a variety of organizations, and it may choose to respond to many of those. The IETF is only obligated to respond if there is an agreed liaison relationship, however. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-baker-liaison-statements-04 BCP0103 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC4053 RFC4054 Impairments and Other Constraints on Optical Layer Routing J. Strand Editor A. Chiu Editor May 2005 ASCII HTML 29 diversity routing path selection impariment ase pmd optical control plane gmpls

Optical networking poses a number challenges for Generalized Multi-Protocol Label Switching (GMPLS). Fundamentally, optical technology is an analog rather than digital technology whereby the optical layer is lowest in the transport hierarchy and hence has an intimate relationship with the physical geography of the network. This contribution surveys some of the aspects of optical networks that impact routing and identifies possible GMPLS responses for each: (1) Constraints arising from the design of new software controllable network elements, (2) Constraints in a single all-optical domain without wavelength conversion, (3) Complications arising in more complex networks incorporating both all-optical and opaque architectures, and (4) Impacts of diversity constraints. This memo provides information for the Internet community.

 draft-ietf-ipo-impairments-04 INFORMATIONAL INFORMATIONAL IETF subip ipo 10.17487/RFC4054 RFC4055 Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile J. Schaad B. Kaliski R. Housley June 2005 ASCII HTML 25 ASN.1 RSASSA-PSS RSA probabilistic signature scheme signature algorithm RSAES-OAEP RSA encryption scheme optimal asymmetric encryption padding public-key cryptography standards PKCS pki

This document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. [STANDARDS-TRACK]

 draft-ietf-pkix-rsa-pkalgs-03 RFC3279 RFC5756 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4055 10.17487/RFC4055 RFC4056 Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS) J. Schaad June 2005 ASCII HTML 6 RSA probabilistic signature scheme digital signature

This document specifies the conventions for using the RSASSA-PSS (RSA Probabilistic Signature Scheme) digital signature algorithm with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]

 draft-ietf-smime-pss-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4056 10.17487/RFC4056 RFC4057 IPv6 Enterprise Network Scenarios J. Bound Editor June 2005 ASCII HTML 17 internet protocol version 6

This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document. This memo provides information for the Internet community.

 draft-ietf-v6ops-ent-scenarios-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4057 10.17487/RFC4057 RFC4058 Protocol for Carrying Authentication for Network Access (PANA) Requirements A. Yegin Editor Y. Ohba R. Penno G. Tsirtsis C. Wang May 2005 ASCII HTML 19 network connectivity link layer agnostic protocol

It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of the AAA infrastructure. This memo provides information for the Internet community.

 draft-ietf-pana-requirements-09 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC4058 RFC4059 Internet X.509 Public Key Infrastructure Warranty Certificate Extension D. Linsenbardt S. Pontius A. Sturgeon May 2005 ASCII HTML 9 certificate authority ca insurance policy

This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for the certificate containing the extension. This memo provides information for the Internet community.

 draft-ietf-pkix-warranty-extn-04 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC4059 RFC4060 RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding Q. Xie D. Pearce May 2005 ASCII HTML 19 real-time transport protocol dsr distributed speeech recognition xfe extended front-end xafe extended advanced front-end

This document specifies RTP payload formats for encapsulating European Telecommunications Standards Institute (ETSI) European Standard ES 202 050 DSR Advanced Front-end (AFE), ES 202 211 DSR Extended Front-end (XFE), and ES 202 212 DSR Extended Advanced Front-end (XAFE) signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-dsr-codecs-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4060 10.17487/RFC4060 RFC4061 Benchmarking Basic OSPF Single Router Control Plane Convergence V. Manral R. White A. Shaikh April 2005 ASCII HTML 16 spf time adjacency formation time

This document provides suggestions for measuring OSPF single router control plane convergence. Its initial emphasis is on the control plane of a single OSPF router. We do not address forwarding plane performance.

NOTE: In this document, the word "convergence" relates to single router control plane convergence only. This memo provides information for the Internet community.

 draft-ietf-bmwg-ospfconv-intraarea-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4061 RFC4062 OSPF Benchmarking Terminology and Concepts V. Manral R. White A. Shaikh April 2005 ASCII HTML 9 spf time adjacency formation time

This document explains the terminology and concepts used in OSPF benchmarking. Although some of these terms may be defined elsewhere (and we will refer the reader to those definitions in some cases) we include discussions concerning these terms, as they relate specifically to the tasks involved in benchmarking the OSPF protocol. This memo provides information for the Internet community.

 draft-ietf-bmwg-ospfconv-term-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4062 RFC4063 Considerations When Using Basic OSPF Convergence Benchmarks V. Manral R. White A. Shaikh April 2005 ASCII HTML 11 spf time adjacency formation time

This document discusses the applicability of various tests for measuring single router control plane convergence, specifically in regard to the Open Shortest First (OSPF) protocol. There are two general sections in this document, the first discusses advantages and limitations of specific OSPF convergence tests, and the second discusses more general pitfalls to be considered when routing protocol convergence is tested. This memo provides information for the Internet community.

 draft-ietf-bmwg-ospfconv-applicability-07 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4063 RFC4064 Experimental Message, Extensions, and Error Codes for Mobile IPv4 A. Patel K. Leung May 2005 ASCII HTML 11 internet protocol message types

Mobile IPv4 message types range from 0 to 255. This document reserves a message type for use by an individual, company, or organization for experimental purposes, to evaluate enhancements to Mobile IPv4 messages before a formal standards proposal is issued. [STANDARDS-TRACK]

 draft-ietf-mip4-experimental-messages-02 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC4064 RFC4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations J. Kempf July 2005 ASCII HTML 8 candidate access router discovery card context transfer protocol CXTP ICMP

The Seamoby Candidate Access Router Discovery (CARD) protocol and the Context Transfer Protocol (CXTP) are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP type and options, Stream Control Transmission Protocol (SCTP) Payload Protocol Identifiers, port numbers, and registries for certain formatted message options. This document contains instructions to IANA about which allocations are required for the Seamoby protocols. The ICMP subtype extension format for Seamoby has been additionally designed so that it can be utilized by other experimental mobility protocols, and the SCTP port number is also available for other experimental mobility protocols. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-seamoby-iana-02 EXPERIMENTAL EXPERIMENTAL IETF tsv seamoby 10.17487/RFC4065 RFC4066 Candidate Access Router Discovery (CARD) M. Liebsch Editor A. Singh Editor H. Chaskar D. Funato E. Shim July 2005 ASCII HTML 46 mobile node mn cars candidate ars

To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover. The act of discovery of CARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-seamoby-card-protocol-08 EXPERIMENTAL EXPERIMENTAL IETF tsv seamoby 10.17487/RFC4066 RFC4067 Context Transfer Protocol (CXTP) J. Loughney Editor M. Nakhjiri C. Perkins R. Koodli July 2005 ASCII HTML 33 mobile node mn

This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-seamoby-ctp-11 EXPERIMENTAL EXPERIMENTAL IETF tsv seamoby 10.17487/RFC4067 RFC4068 Fast Handovers for Mobile IPv6 R. Koodli Editor July 2005 ASCII HTML 42 internet protocol version 6 access router mobile node mn

Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mipshop-fast-mipv6-03 RFC5268 EXPERIMENTAL EXPERIMENTAL IETF int mipshop 10.17487/RFC4068 RFC4069 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding M. Dodge B. Ray May 2005 ASCII HTML 19 mib management information base VDSL-LINE-MIB VDSL-LINE-EXT-SCM-MIB

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Single Carrier Modulation (SCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]

 draft-ietf-adslmib-vdsl-ext-scm-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=4069 10.17487/RFC4069 RFC4070 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding M. Dodge B. Ray May 2005 ASCII HTML 24 management information base mib VDSL-LINE-MIB VDSL-LINE-EXT-MCM-MIB

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Multiple Carrier Modulation (MCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]

 draft-ietf-adslmib-vdsl-ext-mcm-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC4070 RFC4071 Structure of the IETF Administrative Support Activity (IASA) R. Austein Editor B. Wijnen Editor April 2005 ASCII HTML 20 isoc ietf administrative oversight committee IAOC ietf administrative director iad

This document describes the structure of the IETF Administrative Support Activity (IASA) as an activity housed within the Internet Society (ISOC). It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-iasa-bcp-07 RFC8711 RFC4371 RFC7691 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4071 RFC4072 Diameter Extensible Authentication Protocol (EAP) Application P. Eronen Editor T. Hiller G. Zorn August 2005 ASCII HTML 33 command codes avp nas network access server back-end autentication server

The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server. [STANDARDS-TRACK]

 draft-ietf-aaa-eap-10 RFC7268 RFC8044 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4072 10.17487/RFC4072 RFC4073 Protecting Multiple Contents with the Cryptographic Message Syntax (CMS) R. Housley May 2005 ASCII HTML 9 content collection

This document describes a convention for using the Cryptographic Message Syntax (CMS) to protect a content collection. If desired, attributes can be associated with the content. [STANDARDS-TRACK]

 draft-housley-contentcollection-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4073 10.17487/RFC4073 RFC4074 Common Misbehavior Against DNS Queries for IPv6 Addresses Y. Morishita T. Jinmei May 2005 ASCII HTML 6 resource records aaaa domain name service

There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can block IPv4 communication that should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of known cases and discusses their effects. This memo provides information for the Internet community.

 draft-ietf-dnsop-misbehavior-against-aaaa-02 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC4074 RFC4075 Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 V. Kalusivalingam May 2005 ASCII HTML 5 dynamic host configuration protocol server addresses

This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (SNTP) server addresses to a client. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-opt-sntp-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4075 RFC4076 Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) T. Chown S. Venaas A. Vijayabhaskar May 2005 ASCII HTML 8 internet protocol stateless address autoconfiguration

IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. This memo provides information for the Internet community.

 draft-ietf-dhc-stateless-dhcpv6-renumbering-02 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC4076 RFC4077 A Negative Acknowledgement Mechanism for Signaling Compression A.B. Roach May 2005 ASCII HTML 16 sigcomp negative feedback

This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. [STANDARDS-TRACK]

 draft-ietf-rohc-sigcomp-nack-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4077 RFC4078 The TV-Anytime Content Reference Identifier (CRID) N. Earnshaw S. Aoki A. Ashley W. Kameyama May 2005 ASCII HTML 10 digital broadcasting tv radio uri uniform resource identifier content referencing storage systems

The Uniform Resource Locator (URL) scheme "CRID:" has been devised to allow references to current or future scheduled publications of broadcast media content over television distribution platforms and the Internet.

The initial intended application is as an embedded link within scheduled programme description metadata that can be used by the home user or agent to associate a programme selection with the corresponding programme location information for subsequent automatic acquisition.

This document reproduces the \%TV-Anytime CRID definition found in the \%TV-Anytime content referencing specification, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority (IANA). This memo provides information for the Internet community.

 draft-earnshaw-tv-anytime-crid-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4078 RFC4079 A Presence Architecture for the Distribution of GEOPRIV Location Objects J. Peterson July 2005 ASCII HTML 7 using protocol

GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects. GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation of GEOPRIV. This memo provides information for the Internet community.

 draft-ietf-geopriv-pres-02 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC4079 RFC4080 Next Steps in Signaling (NSIS): Framework R. Hancock G. Karagiannis J. Loughney S. Van den Bosch June 2005 ASCII HTML 49 data flow architectural framework signaling protocols signaling application

The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols.

This document provides a model for the network entities that take part in such signaling, and for the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with separate upper layers for each specific signaling application. This memo provides information for the Internet community.

 draft-ietf-nsis-fw-07 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC4080 RFC4081 Security Threats for Next Steps in Signaling (NSIS) H. Tschofenig D. Kroeselberg June 2005 ASCII HTML 28

This threats document provides a detailed analysis of the security threats relevant to the Next Steps in Signaling (NSIS) protocol suite. It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals. This document does not describe vulnerabilities of specific parts of the NSIS protocol suite. This memo provides information for the Internet community.

 draft-ietf-nsis-threats-06 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC4081 RFC4082 Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction A. Perrig D. Song R. Canetti J. D. Tygar B. Briscoe June 2005 ASCII HTML 22 data streams

This document introduces Timed Efficient Stream Loss-tolerant Authentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties.

This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts. This memo provides information for the Internet community.

 draft-ietf-msec-tesla-intro-04 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC4082 RFC4083 Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP) M. Garcia-Martin May 2005 ASCII HTML 36 3GPP IP multimedia core network subsystem ims cellular networks

The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of Release 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks. This memo provides information for the Internet community.

 draft-ietf-sipping-3gpp-r5-requirements-00 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4083 RFC4084 Terminology for Describing Internet Connectivity J. Klensin May 2005 ASCII HTML 11

As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-klensin-ip-service-terms-04 BCP0104 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4084 10.17487/RFC4084 RFC4085 Embedding Globally-Routable Internet Addresses Considered Harmful D. Plonka June 2005 ASCII HTML 10

This document discourages the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives. This document is intended to clarify best current practices in this regard. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-grow-embed-addr-05 BCP0105 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC4085 RFC4086 Randomness Requirements for Security D. Eastlake 3rd J. Schiller S. Crocker June 2005 ASCII HTML 48 cryptographic algorithms passwords cryptographic keys pseudo-random random numbers seed

Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.

Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-eastlake-randomness2-10 RFC1750 BCP0106 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4086 10.17487/RFC4086 RFC4087 IP Tunnel MIB D. Thaler June 2005 ASCII HTML 25 management information base internet protocol tunnel-mib

This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects. This MIB module does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIB modules. This memo obsoletes RFC 2667. [STANDARDS-TRACK]

 draft-ietf-ipv6-inet-tunnel-mib-03 RFC2667 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4087 RFC4088 Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP) D. Black K. McCloghrie J. Schoenwaelder June 2005 ASCII HTML 18 uri uniform resource identifiers snmp-uri

The Simple Network Management Protocol (SNMP) and the Internet Standard Management Framework are widely used for the management of communication devices, creating a need to specify SNMP access (including access to SNMP MIB object instances) from non-SNMP management environments. For example, when out-of-band IP management is used via a separate management interface (e.g., for a device that does not support in-band IP access), a uniform way to indicate how to contact the device for management is needed. Uniform Resource Identifiers (URIs) fit this need well, as they allow a single text string to indicate a management access communication endpoint for a wide variety of IP-based protocols.

This document defines a URI scheme so that SNMP can be designated as the protocol used for management. The scheme also allows a URI to designate one or more MIB object instances. [STANDARDS-TRACK]

 draft-black-snmp-uri-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4088 RFC4089 IAB and IESG Recommendation for IETF Administrative Restructuring S. Hollenbeck Editor IAB and IESG May 2005 ASCII HTML 55 internet architecture board internet engineering steering group internet engineering task force

This document describes a joint recommendation of the Internet Architecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force. The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004. Further work has been done to revise and refine the structures proposed. The recommendation is being published for the record. This memo provides information for the Internet community.

 draft-iab-iesg-adminrest-rec-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4089 RFC4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels P. Pan Editor G. Swallow Editor A. Atlas Editor May 2005 ASCII HTML 38 resource reservation protocol traffic engineering lsp label switch path one-to-one backup facility backup

This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.

Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK]

 draft-ietf-mpls-rsvp-lsp-fastreroute-07 RFC8271 RFC8537 RFC8796 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4090 10.17487/RFC4090 RFC4091 The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework G. Camarillo J. Rosenberg June 2005 ASCII HTML 7

This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream. [STANDARDS-TRACK]

 draft-ietf-mmusic-anat-02 RFC5245 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4091 RFC4092 Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP) G. Camarillo J. Rosenberg June 2005 ASCII HTML 6 sdp-anat option-tag

This document describes how to use the Alternative Network Address Types (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT. [STANDARDS-TRACK]

 draft-ietf-sip-anat-usage-00 RFC5245 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4092 RFC4093 Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways F. Adrangi Editor H. Levkowetz Editor August 2005 ASCII HTML 19

Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions. This memo provides information for the Internet community.

 draft-ietf-mip4-vpn-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF int mip4 10.17487/RFC4093 RFC4094 Analysis of Existing Quality-of-Service Signaling Protocols J. Manner X. Fu May 2005 ASCII HTML 45 qos quality of service rsvp nsis yessir boomerang daris insignia bgrp sicap mobility performance security

This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area. This memo provides information for the Internet community.

 draft-ietf-nsis-signalling-analysis-05 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC4094 RFC4095 Attaching Meaning to Solicitation Class Keywords C. Malamud May 2005 ASCII HTML 11 uri uniform resource identifier no soliciting smtp service extension esmtp service extension dynamic delegation discovery system ddds no-solicit

This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new \%"No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender.

This document specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the "example.org" domain could use this mechanism to create a URI which contains detailed information about the "org.example.adv" solicitation class keyword. [STANDARDS-TRACK]

 draft-malamud-keyword-discovery-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4095 RFC4096 Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best C. Malamud May 2005 ASCII HTML 14

This memo discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, \%standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective. This memo provides information for the Internet community.

 draft-malamud-subject-line-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4096 RFC4097 Middlebox Communications (MIDCOM) Protocol Evaluation M. Barnes Editor June 2005 ASCII HTML 44 snmp simple network management protocol rsip realm specific internet protocol megaco diameter cops common open policy service

This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. This memo provides information for the Internet community.

 draft-ietf-midcom-protocol-eval-06 RFC8996 INFORMATIONAL INFORMATIONAL IETF tsv midcom 10.17487/RFC4097 RFC4098 Terminology for Benchmarking BGP Device Convergence in the Control Plane H. Berkowitz E. Davies Editor S. Hares P. Krishnaswamy M. Lepp June 2005 ASCII HTML 36 border gateway protocol benchmarking methodology ebgp

This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices.This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant. This memo provides information for the Internet community.

 draft-ietf-bmwg-conterm-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4098 RFC4099 RFC4100 RFC4101 Writing Protocol Models E. Rescorla IAB June 2005 ASCII HTML 22 document review

The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system. This memo provides information for the Internet community.

 draft-iab-model-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4101 RFC4102 Registration of the text/red MIME Sub-Type P. Jones June 2005 ASCII HTML 6 rtp real-time transport protocol

This document defines the text/red MIME sub-type. "Red" is short for redundant. The actual RTP packetization for this MIME type is specified in RFC 2198. [STANDARDS-TRACK]

 draft-ietf-avt-text-red-05 RFC6354 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4102 10.17487/RFC4102 RFC4103 RTP Payload for Text Conversation G. Hellstrom P. Jones June 2005 ASCII HTML 20 real-time applications video audio packets

This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.

One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text.

This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. [STANDARDS-TRACK]

 draft-ietf-avt-rfc2793bis-09 RFC2793 RFC9071 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4103 10.17487/RFC4103 RFC4104 Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS) M. Pana Editor A. Reyes A. Barba D. Moron M. Brunner June 2005 ASCII HTML 88 policy core lightweight directory access protocol pcim policy core information model mapping classes

This document defines a number of changes and extensions to the Policy Core Lightweight Directory Access Protocol (LDAP) Schema (RFC 3703) based on the model extensions defined by the Policy Core Information Model (PCIM) Extensions (RFC 3460). These changes and extensions consist of new LDAP object classes and attribute types. Some of the schema items defined in this document re-implement existing concepts in accordance with their new semantics introduced by RFC 3460. The other schema items implement new concepts, not covered by RFC 3703. This document updates RFC 3703. [STANDARDS-TRACK]

 draft-reyes-policy-core-ext-schema-07 RFC3703 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4104 RFC4105 Requirements for Inter-Area MPLS Traffic Engineering J.-L. Le Roux Editor J.-P. Vasseur Editor J. Boyle Editor June 2005 ASCII HTML 22 multiprotocol label switching mpls-te mpls te

This document lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE). It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS TE satisfy these requirements. This memo provides information for the Internet community.

 draft-ietf-tewg-interarea-mpls-te-req-03 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC4105 RFC4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) J. Viega D. McGrew June 2005 ASCII HTML 11 aes advanced encryption standard

This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK]

 draft-ietf-ipsec-ciph-aes-gcm-00 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4106 10.17487/RFC4106 RFC4107 Guidelines for Cryptographic Key Management S. Bellovin R. Housley June 2005 ASCII HTML 7 automated key management manual key management

The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient. This memo provides guidelines for making such decisions. When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-bellovin-mandate-keymgmt-03 BCP0107 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4107 RFC4108 Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages R. Housley August 2005 ASCII HTML 61 hardward module components digital signature

This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package. [STANDARDS-TRACK]

 draft-housley-cms-fw-wrap-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4108 10.17487/RFC4108 RFC4109 Algorithms for Internet Key Exchange version 1 (IKEv1) P. Hoffman May 2005 ASCII HTML 5 ike ipsec oakley authentication isakmp internet security key management

The required and suggested algorithms in the original Internet Key Exchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today. [STANDARDS-TRACK]

 draft-hoffman-ikev1-algorithms-03 RFC2409 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4109 RFC4110 A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) R. Callon M. Suzuki July 2005 ASCII HTML 82

This document provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. This memo provides information for the Internet community.

 draft-ietf-l3vpn-framework-00 INFORMATIONAL INFORMATIONAL IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4110 10.17487/RFC4110 RFC4111 Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) L. Fang Editor July 2005 ASCII HTML 45

This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements. In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology. This memo provides information for the Internet community.

 draft-ietf-l3vpn-security-framework-03 RFC8996 INFORMATIONAL INFORMATIONAL IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4111 10.17487/RFC4111 RFC4112 Electronic Commerce Modeling Language (ECML) Version 2 Specification D. Eastlake 3rd June 2005 ASCII HTML 34

Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate. A standard set of hierarchically-organized payment-related information field names in an XML syntax is defined so that this task can be more easily automated. This is the second version of an Electronic Commerce Modeling Language (ECML) and is intended to meet the requirements of RFC 3505. [STANDARDS-TRACK]

 draft-ietf-trade-ecml2-spec-13 RFC3106 PROPOSED STANDARD PROPOSED STANDARD IETF app trade 10.17487/RFC4112 RFC4113 Management Information Base for the User Datagram Protocol (UDP) B. Fenner J. Flick June 2005 ASCII HTML 19 MIB-UDP mib UDP-MIB internet protocol ip

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454. [STANDARDS-TRACK]

 draft-ietf-ipv6-rfc2013-update-04 RFC2454 RFC2013 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4113 10.17487/RFC4113 RFC4114 E.164 Number Mapping for the Extensible Provisioning Protocol (EPP) S. Hollenbeck June 2005 ASCII HTML 17 shared central repository

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers that represent domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. [STANDARDS-TRACK]

 draft-ietf-enum-epp-e164-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum http://www.rfc-editor.org/errata_search.php?rfc=4114 10.17487/RFC4114 RFC4115 A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic O. Aboul-Magd S. Rabie July 2005 ASCII HTML 6 data services service scenarios metering algorithm color-blind color-aware

This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices. This memo provides information for the Internet community.

 draft-aboulmagd-trtcm-inprofile-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4115 RFC4116 IPv4 Multihoming Practices and Limitations J. Abley K. Lindqvist E. Davies B. Black V. Gill July 2005 ASCII HTML 13 internet protocol

Multihoming is an essential component of service for many Internet sites. This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6). This memo provides information for the Internet community.

 draft-ietf-multi6-v4-multihoming-03 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4116 RFC4117 Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc) G. Camarillo E. Burger H. Schulzrinne A. van Wijk June 2005 ASCII HTML 19 deaf hard of hearing speech-impaired hearing-impaired

This document describes how to invoke transcoding services using Session Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. This memo provides information for the Internet community.

 draft-ietf-sipping-transc-3pcc-02 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4117 10.17487/RFC4117 RFC4118 Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP) L. Yang P. Zerfos E. Sadot June 2005 ASCII HTML 41 IEEE 802.11 wireless lan

This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzing Wireless LAN (WLAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities. This memo provides information for the Internet community.

 draft-ietf-capwap-arch-06 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC4118 RFC4119 A Presence-based GEOPRIV Location Object Format J. Peterson December 2005 ASCII HTML 24 pidf presence information data format

This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties. [STANDARDS-TRACK]

 draft-ietf-geopriv-pidf-lo-03 RFC5139 RFC5491 RFC7459 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=4119 10.17487/RFC4119 RFC4120 The Kerberos Network Authentication Service (V5) C. Neuman T. Yu S. Hartman K. Raeburn July 2005 ASCII HTML 138 KERBEROS CAT Security

This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. [STANDARDS-TRACK]

 draft-ietf-krb-wg-kerberos-clarifications-07 RFC1510 RFC4537 RFC5021 RFC5896 RFC6111 RFC6112 RFC6113 RFC6649 RFC6806 RFC7751 RFC8062 RFC8129 RFC8429 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=4120 10.17487/RFC4120 RFC4121 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2 L. Zhu K. Jaganathan S. Hartman July 2005 ASCII HTML 20 GSSAPI-KER cryptosystem

This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Kerberos Version 5 mechanism.

RFC 1964 is updated and incremental changes are proposed in response to recent developments such as the introduction of Kerberos cryptosystem framework. These changes support the inclusion of new cryptosystems, by defining new per-message tokens along with their encryption and checksum algorithms based on the cryptosystem profiles. [STANDARDS-TRACK]

 draft-ietf-krb-wg-gssapi-cfx-07 RFC1964 RFC5896 RFC6112 RFC6542 RFC6649 RFC8062 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC4121 RFC4122 A Universally Unique IDentifier (UUID) URN Namespace P. Leach M. Mealling R. Salz July 2005 ASCII HTML 32 uniform resource name guid globally unique identifier

This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.

This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]

 draft-mealling-uuid-urn-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4122 10.17487/RFC4122 RFC4123 Session Initiation Protocol (SIP)-H.323 Interworking Requirements H. Schulzrinne C. Agboh July 2005 ASCII HTML 16 SIP-H.323 IWF

This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP and H.323. This memo provides information for the Internet community.

 draft-agrawal-sip-h323-interworking-reqs-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4123 RFC4124 Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering F. Le Faucheur Editor June 2005 ASCII HTML 37 DS-TE igp interior gateway protocol extensions rsvp resource reservation protocol

This document specifies the protocol extensions for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes generalization of the semantics of a number of Interior Gateway Protocol (IGP) extensions already defined for existing MPLS Traffic Engineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those. This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS Traffic Engineering. These extensions address the requirements for DS-TE spelled out in RFC 3564. [STANDARDS-TRACK]

 draft-ietf-tewg-diff-te-proto-08 PROPOSED STANDARD PROPOSED STANDARD IETF subip tewg 10.17487/RFC4124 RFC4125 Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering F. Le Faucheur W. Lai June 2005 ASCII HTML 12 ds-te maximum allocation model

This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tewg-diff-te-mam-04 EXPERIMENTAL EXPERIMENTAL IETF subip tewg 10.17487/RFC4125 RFC4126 Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons J. Ash June 2005 ASCII HTML 22 diffserv-enabled mpls traffic engineering ds-te mar bandwidth reservation bandwidth allocation bandwidth protection performance evaluation cac network model

This document complements the Diffserv-aware MPLS Traffic Engineering (DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model. Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting a Bandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tewg-diff-te-mar-06 EXPERIMENTAL EXPERIMENTAL IETF subip tewg 10.17487/RFC4126 RFC4127 Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering F. Le Faucheur Editor June 2005 ASCII HTML 13 ds-te russian dolls model multi-protocol label switching

This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tewg-diff-te-russian-07 EXPERIMENTAL EXPERIMENTAL IETF subip tewg 10.17487/RFC4127 RFC4128 Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation W. Lai June 2005 ASCII PDF HTML 25 label switched path lsp lsp blocking lsp preemption lsp priority traffic overload bandwidth efficiency bandwidth sharing bandwidth protection class isolation maximum allocation model russian dolls model

"Differentiated Services (Diffserv)-aware MPLS Traffic Engineering Requirements", RFC 3564, specifies the requirements and selection criteria for Bandwidth Constraints Models. Two such models, the Maximum Allocation and the Russian Dolls, are described therein. This document complements RFC 3564 by presenting the results of a performance evaluation of these two models under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing. This memo provides information for the Internet community.

 draft-wlai-tewg-bcmodel-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4128 RFC4129 Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol R. Mukundan K. Morneault N. Mangalpally September 2005 ASCII HTML 15 backhauling isdn user adaptation pbx private branch exchanges

This document defines a mechanism for backhauling Digital Private Network Signaling System 1 (DPNSS 1) and Digital Access Signaling System 2 (DASS 2) messages over IP by extending the ISDN User Adaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1, specified in ND1301:2001/03 (formerly BTNR 188), is used to interconnect Private Branch Exchanges (PBX) in a private network. DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN. This document aims to become an Appendix to IUA and to be the base for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation. [STANDARDS-TRACK]

 draft-ietf-sigtran-dua-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC4129 RFC4130 MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) D. Moberg R. Drummond July 2005 ASCII HTML 47 hyper text transfer protocol simple mail transfer protocol

This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335. [STANDARDS-TRACK]

 draft-ietf-ediint-as2-20 PROPOSED STANDARD PROPOSED STANDARD IETF app ediint http://www.rfc-editor.org/errata_search.php?rfc=4130 10.17487/RFC4130 RFC4131 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus S. Green K. Ozawa E. Cardona Editor A. Katsnelson September 2005 ASCII HTML 85 mib snmp simple network management protocol docs-ietf-bpi2-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Baseline Privacy Plus features of DOCSIS 1.1 and DOCSIS 2.0 (Data-over-Cable Service Interface Specification) compliant Cable Modems and Cable Modem Termination Systems. [STANDARDS-TRACK]

 draft-ietf-ipcdn-bpiplus-mib-15 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4131 RFC4132 Addition of Camellia Cipher Suites to Transport Layer Security (TLS) S. Moriai A. Kato M. Kanda July 2005 ASCII HTML 7 camellia encryption algorithm

This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]

 draft-ietf-tls-camellia-06 RFC5932 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC4132 RFC4133 Entity MIB (Version 3) A. Bierman K. McCloghrie August 2005 ASCII HTML 62 management information base snmp simple network management protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version 3 of the Entity MIB, which obsoletes version 2 (RFC 2737). [STANDARDS-TRACK]

 draft-ietf-entmib-v3-07 RFC2737 RFC6933 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=4133 10.17487/RFC4133 RFC4134 Examples of S/MIME Messages P. Hoffman Editor July 2005 ASCII HTML 136

This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects and S/MIME messages (including the MIME formatting). It includes examples of many common CMS formats. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This memo provides information for the Internet community.

 draft-ietf-smime-examples-15 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4134 10.17487/RFC4134 RFC4135 Goals of Detecting Network Attachment in IPv6 JH. Choi G. Daley August 2005 ASCII HTML 9 dna detecting attachment links change detection

When a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change (i.e., determine whether a link change has occurred), and then, based on the result, it can automatically decide whether its IP configuration is still valid. During link identity detection, the host may also collect necessary information to initiate a new IP configuration if the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment (DNA). DNA schemes should be precise, sufficiently fast, secure, and of limited signaling. This memo provides information for the Internet community.

 draft-ietf-dna-goals-04 INFORMATIONAL INFORMATIONAL IETF int dna 10.17487/RFC4135 RFC4136 OSPF Refresh and Flooding Reduction in Stable Topologies P. Pillay-Esnault July 2005 ASCII HTML 5 open shortest path first link state advertisement lsa donotage

This document describes an extension to the OSPF protocol to reduce periodic flooding of Link State Advertisements (LSAs) in stable topologies.

Current OSPF behavior requires that all LSAs, except DoNotAge LSAs, to be refreshed every 30 minutes. This document proposes to generalize the use of DoNotAge LSAs in order to reduce protocol traffic in stable topologies. This memo provides information for the Internet community.

 draft-pillay-esnault-ospf-flooding-07 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC4136 RFC4137 State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator J. Vollbrecht P. Eronen N. Petroni Y. Ohba August 2005 ASCII PDF HTML 51 eap stand-alone authenticator eap backend authenticator eap full authenticator

This document describes a set of state machines for Extensible Authentication Protocol (EAP) peer, EAP stand-alone authenticator (non-pass-through), EAP backend authenticator (for use on Authentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-through authenticators illustrate how EAP/AAA protocol support defined in RFC 3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative.

The state machines are based on the EAP "Switch" model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section.

The state machine and associated model are informative only. Implementations may achieve the same results using different methods. This memo provides information for the Internet community.

 draft-ietf-eap-statemachine-06 INFORMATIONAL INFORMATIONAL IETF int eap 10.17487/RFC4137 RFC4138 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP) P. Sarolahti M. Kojo August 2005 ASCII HTML 23 tcp transmission control protocol

Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. The F-RTO algorithm can also be applied to the Stream Control Transmission Protocol (SCTP). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tcpm-frto-02 RFC5682 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC4138 RFC4139 Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) D. Papadimitriou J. Drake J. Ash A. Farrel L. Ong July 2005 ASCII HTML 16 tdm otn control plane call connection

The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies and different applications. These include support for requesting Time Division Multiplexing (TDM) connections, including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs).

This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the GMPLS signaling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements for the GMPLS signaling protocol to support the ASON functionality. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-ason-reqts-07 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4139 RFC4140 Hierarchical Mobile IPv6 Mobility Management (HMIPv6) H. Soliman C. Castelluccia K. El Malki L. Bellier August 2005 ASCII HTML 29 internet protocol version 6 neighbour discovery neighbor discovery mobility anchor point map

This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mipshop-hmipv6-04 RFC5380 EXPERIMENTAL EXPERIMENTAL IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=4140 10.17487/RFC4140 RFC4141 SMTP and MIME Extensions for Content Conversion K. Toyoda D. Crocker November 2005 ASCII HTML 26 esmtp simple mail transfer protocol extended simple mail transfer protocol multipurpose internet mail extensions

A message originator sometimes sends content in a form the recipient cannot process or would prefer not to process a form of lower quality than is preferred. Such content needs to be converted to an acceptable form, with the same information or constrained information (e.g., changing from color to black and white). In a store-and-forward environment, it may be convenient to have this conversion performed by an intermediary. This specification integrates two ESMTP extensions and three MIME content header fields, which defines a cooperative service that permits authorized, accountable content form conversion by intermediaries. [STANDARDS-TRACK]

 draft-ietf-fax-esmtp-conneg-13 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=4141 10.17487/RFC4141 RFC4142 Full-mode Fax Profile for Internet Mail (FFPIM) D. Crocker G. Klyne November 2005 ASCII HTML 9 facsimile full mode internet mail

Classic facsimile document exchange represents both a set of technical specifications and a class of service. Previous work has replicated some of that service class as a profile within Internet mail. The current specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability and capability negotiation for Internet mail, on a par with classic T.30 facsimile. These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates what is currently enjoyed by fax users. [PROPOSED STANDARD]

 draft-ietf-fax-ffpim-08 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC4142 RFC4143 Facsimile Using Internet Mail (IFAX) Service of ENUM K. Toyoda D. Crocker November 2005 ASCII HTML 5 naptr enum naming authority pointer facsimile using internet mail dns domain name system

This document describes the functional specification and definition of the ENUM Naming Authority Pointer (NAPTR) record for IFax service. IFax is "facsimile using Internet mail". For this use, the Domain Name System (DNS) returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers instead of requiring the sender to already know the recipient email address. [STANDARDS-TRACK]

 draft-ietf-fax-faxservice-enum-03 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=4143 10.17487/RFC4143 RFC4144 How to Gain Prominence and Influence in Standards Organizations D. Eastlake 3rd September 2005 ASCII HTML 9

This document provides simple guidelines that can make it easier for you to gain prominence and influence in most standards organizations. This memo provides information for the Internet community.

 draft-eastlake-prominence-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4144 RFC4145 TCP-Based Media Transport in the Session Description Protocol (SDP) D. Yon G. Camarillo September 2005 ASCII HTML 15 setup connection reestablishment

This document describes how to express media transport over TCP using the Session Description Protocol (SDP). It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-comedia-10 RFC4572 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4145 RFC4146 Simple New Mail Notification R. Gellens August 2005 ASCII HTML 5 mail client nm_notifyuser

This memo documents a long-standing technique, supported by a large number of mail servers, which allows users to be notified of new mail. In addition to server support, there are a number of clients that support this, ranging from full email clients to specialized clients whose only purpose is to receive new mail notifications and alert a mail client.

In brief, the server sends the string "nm_notifyuser" CRLF to the finger port on the IP address (either configured or last used) of the user who has received new mail. This memo provides information for the Internet community.

 draft-gellens-notify-mail-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4146 RFC4147 Proposed Changes to the Format of the IANA IPv6 Registry G. Huston August 2005 ASCII HTML 10 internet protocol version 6 address format address architecture

This document proposes a revised format for the IANA IPv6 address registries. Rather than providing a formal definition of the format, it is described by giving examples of the (current as of preparation of this document) contents of the registries in the proposed format. The proposed format would bring the IANA IPv6 address registries into alignment with the current IPv6 Address Architecture specification, as well as update it to a more useful and generally accepted format. This memo provides information for the Internet community.

 draft-huston-ip6-iana-registry-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4147 10.17487/RFC4147 RFC4148 IP Performance Metrics (IPPM) Metrics Registry E. Stephan August 2005 ASCII HTML 14 internet protocol object identities iana-ippm-metrics-registry-mib

This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF.

This memo also defines the rules for adding IP Performance Metrics that are defined in the future and for encouraging all IP performance metrics to be registered here.

IANA has been assigned to administer this new registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ippm-metrics-registry-08 RFC6248 BCP0108 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv ippm 10.17487/RFC4148 RFC4149 Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms C. Kalbfleisch R. Cole D. Romascanu August 2005 ASCII HTML 39 sspm mib management information base sspm mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring Synthetic Sources for Performance Monitoring (SSPM) algorithms. [STANDARDS-TRACK]

 draft-ietf-rmonmib-sspm-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4149 RFC4150 Transport Performance Metrics MIB R. Dietz R. Cole August 2005 ASCII HTML 57 managgement information base tpm tpm-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring selectable performance metrics and statistics derived from the monitoring of network packets and sub-application level transactions. The metrics can be defined through reference to existing IETF, ITU, and other standards organizations' documents. The monitoring covers both passive and active traffic generation sources. [STANDARDS-TRACK]

 draft-ietf-rmonmib-tpm-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4150 RFC4151 The 'tag' URI Scheme T. Kindberg S. Hawke October 2005 ASCII HTML 11 uniform resource identifier entity identifier

This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources. This memo provides information for the Internet community.

 draft-kindberg-tag-uri-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4151 10.17487/RFC4151 RFC4152 A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code K. Tesink R. Fox August 2005 ASCII HTML 7 ansi ansi t1.213

This document describes a Uniform Resource Name (URN) namespace (RFC 3406) for the assignment of the Common Language Equipment Identifier (CLEI) code, which is used in messages standardized by ANSI. The URN namespace is managed by Telcordia Technologies, Inc., as the maintenance agent for ANSI T1.213. The CLEI code is a globally unique, ten-character alphanumeric intelligent code assigned by Telcordia Technologies at the request of equipment suppliers. The CLEI code identifies communications equipment by specifying product type and features. There is a one-to-one relationship between a CLEI code and supplier's product ID (the manufacturer's name and the part number along with its version number). This memo provides information for the Internet community.

 draft-tesink-urn-clei-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4152 RFC4153 XML Voucher: Generic Voucher Language K. Fujimura M. Terada D. Eastlake 3rd September 2005 ASCII HTML 21 extensible markup language logical entity

This document specifies rules for defining voucher properties in XML syntax. A voucher is a logical entity that represents a right to claim goods or services. A voucher can be used to transfer a wide range of electronic values, including coupons, tickets, loyalty points, and gift certificates, which often have to be processed in the course of payment and/or delivery transactions. This memo provides information for the Internet community.

 draft-ietf-trade-voucher-lang-07 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC4153 RFC4154 Voucher Trading System Application Programming Interface (VTS-API) M. Terada K. Fujimura September 2005 ASCII HTML 32 wallet transfer redeem

This document specifies the Voucher Trading System Application Programming Interface (VTS-API). The VTS-API allows a wallet or other application to issue, transfer, and redeem vouchers in a uniform manner independent of the VTS implementation. The VTS is a system for securely transferring vouchers; e.g., coupons, tickets, loyalty points, and gift certificates. This process is often necessary in the course of payment and/or delivery transactions. This memo provides information for the Internet community.

 draft-ietf-trade-voucher-vtsapi-06 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC4154 RFC4155 The application/mbox Media Type E. Hall September 2005 ASCII HTML 9 mbox database

This memo requests that the application/mbox media type be authorized for allocation by the IESG, according to the terms specified in RFC 2048. This memo also defines a default format for the mbox database, which must be supported by all conformant implementations. This memo provides information for the Internet community.

 draft-hall-mime-app-mbox-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4155 RFC4156 The wais URI Scheme P. Hoffman August 2005 ASCII HTML 4 uniform resource identifier

This document specifies the wais Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. This memo defines a Historic Document for the Internet community.

 draft-hoffman-wais-uri-03 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4156 10.17487/RFC4156 RFC4157 The prospero URI Scheme P. Hoffman August 2005 ASCII HTML 4 uniform resource identifier

This document specifies the prospero Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. This memo defines a Historic Document for the Internet community.

 draft-hoffman-prospero-uri-03 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4157 10.17487/RFC4157 RFC4158 Internet X.509 Public Key Infrastructure: Certification Path Building M. Cooper Y. Dzambasow P. Hesse S. Joseph R. Nicholas September 2005 ASCII HTML 81 certification path discovery path discovery certificate path building certificate path discovery

This document provides guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths across a wide range of PKI environments. This memo provides information for the Internet community.

 draft-ietf-pkix-certpathbuild-05 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC4158 RFC4159 Deprecation of "ip6.int" G. Huston August 2005 ASCII HTML 3 ipv6 dns domain name system

This document advises of the deprecation of the use of "ip6.int" for Standards Conformant IPv6 implementations. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-huston-ip6-int-03 BCP0109 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4159 RFC4160 Internet Fax Gateway Requirements K. Mimura K. Yokoyama T. Satoh C. Kanaide C. Allocchio August 2005 ASCII HTML 13 general switched telephone network facsimile service gstn fax internet fax service i-fax onramp gateway

To allow connectivity between the General Switched Telephone Network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax) an "Internet Fax Gateway" is required. This document provides recommendations for the functionality of Internet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission form GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN Fax terminals on the GSTN. This memo provides information for the Internet community.

 draft-ietf-fax-gateway-protocol-13 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC4160 RFC4161 Guidelines for Optional Services for Internet Fax Gateways K. Mimura K. Yokoyama T. Satoh K. Watanabe C. Kanaide August 2005 ASCII HTML 12 general switched telephone network acsimile service gstn fax internet fax service i-fax offramp gateway onramp gateway

To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax), an "Internet Fax Gateway" is required. This document provides guidelines for the optional functionality of Internet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission from GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN fax terminals on the GSTN.

This document supplements the recommendation for minimal features of an Internet Fax Gateway. In particular, it covers techniques for dropping duplicated fax messages, automatic fax re-transmission, error, return notice, and log handling, and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways. This memo provides information for the Internet community.

 draft-ietf-fax-gateway-options-08 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC4161 RFC4162 Addition of SEED Cipher Suites to Transport Layer Security (TLS) H.J. Lee J.H. Yoon J.I. Lee August 2005 ASCII HTML 6 encryption algorithm ciphersuite

This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the SEED encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]

 draft-lee-tls-seed-01 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4162 RFC4163 RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression L-E. Jonsson August 2005 ASCII HTML 9 transmission control protocol internet protocol compression performance considerations intellectual property rights ipr

This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the RObust Header Compression (ROHC) Working Group. The document discusses the scope of TCP compression, performance considerations, assumptions about the surrounding environment, as well as Intellectual Property Rights concerns. The structure of this document is inherited from RFC 3096, which defines IP/UDP/RTP requirements for ROHC. This memo provides information for the Internet community.

 draft-ietf-rohc-tcp-requirements-08 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4163 RFC4164 RObust Header Compression (ROHC): Context Replication for ROHC Profiles G. Pelletier August 2005 ASCII HTML 21 context initialization short-lived

This document defines context replication, a complement to the context initialization procedure found in Robust Header Compression (ROHC), as specified in RFC 3095. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure. It may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as short-lived TCP flows. [STANDARDS-TRACK]

 draft-ietf-rohc-context-replication-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4164 RFC4165 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA) T. George B. Bidulock R. Dantu H. Schwarzbauer K. Morneault September 2005 ASCII HTML 53 ss7 over ip ss7/ip sigtran m2ua

This document defines a protocol supporting the transport of Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 signaling messages over Internet Protocol (IP) using the services of the Stream Control Transmission Protocol (SCTP). This protocol would be used between SS7 Signaling Points using the MTP Level 3 protocol. The SS7 Signaling Points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 3 signaling messages. The protocol operates in a manner similar to MTP Level 2 so as to provide peer-to-peer communication between SS7 endpoints. [STANDARDS-TRACK]

 draft-ietf-sigtran-m2pa-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=4165 10.17487/RFC4165 RFC4166 Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement L. Coene J. Pastor-Balbas February 2006 ASCII HTML 23

This document describes the applicability of the several protocols developed under the signalling transport framework. A description of the main issues regarding the use of the Stream Control Transmission Protocol (SCTP) and an explanation of each adaptation layer for transport of telephony signalling information over IP infrastructure are given. This memo provides information for the Internet community.

 draft-ietf-sigtran-signalling-over-sctp-applic-09 INFORMATIONAL INFORMATIONAL IETF rai sigtran 10.17487/RFC4166 RFC4167 Graceful OSPF Restart Implementation Report A. Lindem October 2005 ASCII HTML 6 open shortest path first

Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This document provides an implementation report for this extension to the base OSPF protocol. This memo provides information for the Internet community.

 draft-ietf-ospf-graceful-impl-report-05 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC4167 RFC4168 The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne G. Camarillo October 2005 ASCII HTML 10 transport mechanism

This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies. As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. [STANDARDS-TRACK]

 draft-ietf-sip-sctp-06 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4168 RFC4169 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2 V. Torvinen J. Arkko M. Naslund November 2005 ASCII HTML 13 tls transport layer security tunneled authentication man-in-the-middle attacks

HTTP Digest, as specified in RFC 2617, is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exists not just with HTTP Digest, but also with other IETF protocols that use tunneled authentication. This document specifies version 2 of the HTTP Digest AKA algorithm (RFC 3310). This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack. This memo provides information for the Internet community.

 draft-torvinen-http-digest-aka-v2-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4169 RFC4170 Tunneling Multiplexed Compressed RTP (TCRTP) B. Thompson T. Koren D. Wing November 2005 ASCII HTML 24 real-time transport protocol

This document describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple RTP streams are carried over that path. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-avt-tcrtp-08 BCP0110 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai avt 10.17487/RFC4170 RFC4171 Internet Storage Name Service (iSNS) J. Tseng K. Gibbons F. Travostino C. Du Laney J. Souza September 2005 ASCII HTML 123 isns servers isns clients fibre channel devices ifcp intelligent storage discovery

This document specifies the Internet Storage Name Service (iSNS) protocol, used for interaction between iSNS servers and iSNS clients, which facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a capacity similar to that of a storage area network. iSNS facilitates a seamless integration of IP and Fibre Channel networks due to its ability to emulate Fibre Channel fabric services and to manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof. [STANDARDS-TRACK]

 draft-ietf-ips-isns-22 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4171 10.17487/RFC4171 RFC4172 iFCP - A Protocol for Internet Fibre Channel Storage Networking C. Monia R. Mullendore F. Travostino W. Jeong M. Edwards September 2005 ASCII HTML 111 gateway-to-gateway fibre channel fabric tcp transport control protocol

This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network. [STANDARDS-TRACK]

 draft-ietf-ips-ifcp-14 RFC6172 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4172 RFC4173 Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol P. Sarkar D. Missimer C. Sapuntzakis September 2005 ASCII HTML 12 scsi tcp transport control protocol boot server

Internet Small Computer System Interface (iSCSI) is a proposed transport protocol for Small Computer Systems Interface (SCSI) that operates on top of TCP. This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server. [STANDARDS-TRACK]

 draft-ietf-ips-iscsi-boot-12 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4173 10.17487/RFC4173 RFC4174 The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service C. Monia J. Tseng K. Gibbons September 2005 ASCII HTML 13 isns internet storage name service iscsi internet scsi ifcp internet fibre channel storage devices

This document describes the Dynamic Host Configuration Protocol (DHCP) option to allow Internet Storage Name Service (iSNS) clients to discover the location of the iSNS server automatically through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity to that of a storage area network. [STANDARDS-TRACK]

 draft-ietf-dhc-isnsoption-13 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4174 RFC4175 RTP Payload Format for Uncompressed Video L. Gharai C. Perkins September 2005 ASCII HTML 18 packetization scheme real-time transport protocol real time transport protocol smpte society of motion picture television engineers video formats

This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time Transport Protocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITU BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed. [STANDARDS-TRACK]

 draft-ietf-avt-uncomp-video-06 RFC4421 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4175 10.17487/RFC4175 RFC4176 Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management Y. El Mghazli Editor T. Nadeau M. Boucadair K. Chan A. Gonguet October 2005 ASCII HTML 21

This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document. This memo provides information for the Internet community.

 draft-ietf-l3vpn-mgt-fwk-08 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4176 RFC4177 Architectural Approaches to Multi-homing for IPv6 G. Huston September 2005 ASCII HTML 36 internet protocol

This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing. This memo provides information for the Internet community.

 draft-ietf-multi6-architecture-04 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4177 RFC4178 The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism L. Zhu P. Leach K. Jaganathan W. Ingersoll October 2005 ASCII HTML 22 generic service application security program interface

This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API), which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. If per-message integrity services are available on the established mechanism context, then the negotiation is protected against an attacker that forces the selection of a mechanism not desired by the peers.

This mechanism replaces RFC 2478 in order to fix defects in that specification and to describe how to inter-operate with implementations of that specification that are commonly deployed on the Internet. [STANDARDS-TRACK]

 draft-ietf-kitten-2478bis-05 RFC2478 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC4178 RFC4179 Using Universal Content Identifier (UCI) as Uniform Resource Names (URN) S. Kang October 2005 ASCII HTML 7 nca national computerization agency digital resources

This document describes a Uniform Resource Name (URN) namespace for the National Computerization Agency (NCA) for naming persistent digital resources such as music, videos, texts, images, e-books, and other types of digital resources produced or managed by NCA. This memo provides information for the Internet community.

 draft-sangug-uci-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4179 RFC4180 Common Format and MIME Type for Comma-Separated Values (CSV) Files Y. Shafranovich October 2005 ASCII HTML 8 text/csv

This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv". This memo provides information for the Internet community.

 draft-shafranovich-mime-csv-05 RFC7111 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4180 10.17487/RFC4180 RFC4181 Guidelines for Authors and Reviewers of MIB Documents C. Heard Editor September 2005 ASCII HTML 42 standards-track specifications management information base review

This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may be used as a basis for reviews of other MIB documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ops-mib-review-guidelines-04 RFC4841 BCP0111 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4181 10.17487/RFC4181 RFC4182 Removing a Restriction on the use of MPLS Explicit NULL E. Rosen September 2005 ASCII HTML 7 multiprotocol label switching ipv4 explicit null

The label stack encoding for Multi-protocol Label Switching (MPLS) defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL". Previously, these labels were only legal when they occurred at the bottom of the MPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack.

This document updates RFC 3032. [STANDARDS-TRACK]

 draft-ietf-mpls-explicit-null-02 RFC3032 RFC5462 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4182 10.17487/RFC4182 RFC4183 A Suggested Scheme for DNS Resolution of Networks and Gateways E. Warnicke September 2005 ASCII HTML 9 domain name space ip address internet protocol address netmask first-hop router subnet

This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network. This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet. This memo provides information for the Internet community.

 draft-warnicke-network-dns-resolution-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4183 RFC4184 RTP Payload Format for AC-3 Audio B. Link T. Hager J. Flaks October 2005 ASCII HTML 13 real time transport protocol audio compression

This document describes an RTP payload format for transporting audio data using the AC-3 audio compression standard. AC-3 is a high quality, multichannel audio coding system that is used for United States HDTV, DVD, cable television, satellite television and other media. The RTP payload format presented in this document includes support for data fragmentation. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-ac3-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4184 RFC4185 National and Local Characters for DNS Top Level Domain (TLD) Names J. Klensin October 2005 ASCII HTML 19 domain name system multilingual internationalized local translation

In the context of work on internationalizing the Domain Name System (DNS), there have been extensive discussions about "multilingual" or "internationalized" top level domain names (TLDs), especially for countries whose predominant language is not written in a Roman-based script. This document reviews some of the motivations for such domains, several suggestions that have been made to provide needed functionality, and the constraints that the DNS imposes. It then suggests an alternative, local translation, that may solve a superset of the problem while avoiding protocol changes, serious deployment delays, and other difficulties. The suggestion utilizes a localization technique in applications to permit any TLD to be accessed using the vocabulary and characters of any language. It is not restricted to language- or country-specific "multilingual" TLDs in the language(s) and script(s) of that country. This memo provides information for the Internet community.

 draft-klensin-idn-tld-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4185 RFC4186 Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM) H. Haverinen Editor J. Salowey Editor January 2006 ASCII HTML 92 3gpp

This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is a second generation mobile network standard. The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure. This memo provides information for the Internet community.

 draft-haverinen-pppext-eap-sim-16 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4186 10.17487/RFC4186 RFC4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA) J. Arkko H. Haverinen January 2006 ASCII HTML 79 3gpp universal mobile telecommunications system umts

This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card.

EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. This memo provides information for the Internet community.

 draft-arkko-pppext-eap-aka-15 RFC5448 RFC9048 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4187 10.17487/RFC4187 RFC4188 Definitions of Managed Objects for Bridges K. Norseth Editor E. Bell Editor September 2005 ASCII HTML 44 BRIDGE-MIB SNMP MIB standard standards management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing MAC bridges based on the IEEE 802.1D-1998 standard between Local Area Network (LAN) segments. Provisions are made for the support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.

The MIB module presented in this memo is a translation of the BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax.

This memo obsoletes RFC 1493. [STANDARDS-TRACK]

 draft-ietf-bridge-bridgemib-smiv2-10 RFC1493 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge http://www.rfc-editor.org/errata_search.php?rfc=4188 10.17487/RFC4188 RFC4189 Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP) K. Ono S. Tachimoto October 2005 ASCII HTML 12 user agent ua intermediaries

A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security. This memo provides information for the Internet community.

 draft-ietf-sipping-e2m-sec-reqs-06 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4189 RFC4190 Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony K. Carlberg I. Brown C. Beard November 2005 ASCII HTML 28 disaster communications prioritized voip

This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. This memo provides information for the Internet community.

 draft-ietf-ieprep-framework-10 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC4190 RFC4191 Default Router Preferences and More-Specific Routes R. Draves D. Thaler November 2005 ASCII HTML 15 router advertisement

This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. [STANDARDS-TRACK]

 draft-ietf-ipv6-router-selection-07 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4191 10.17487/RFC4191 RFC4192 Procedures for Renumbering an IPv6 Network without a Flag Day F. Baker E. Lear R. Droms September 2005 ASCII HTML 22 prefix internet protocol network interface make-before-break enterprise connecting routers

This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. This memo provides information for the Internet community.

 draft-ietf-v6ops-renumbering-procedure-05 RFC2072 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4192 RFC4193 Unique Local IPv6 Unicast Addresses R. Hinden B. Haberman October 2005 ASCII HTML 16 internet protocol local communication

This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]

 draft-ietf-ipv6-unique-local-addr-09 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4193 RFC4194 The S Hexdump Format J. Strombergson L. Walleij P. Faltstrom October 2005 ASCII HTML 13 shf standard hex format secure hash standard shs sha-1 nist fips 180-2 binary data dump format hexadecimal intel hex format s-rec extensible markup language xml

This document specifies the S Hexdump Format (SHF), a new, XML-based open format for describing binary data in hexadecimal notation. SHF provides the ability to describe both small and large, simple and complex hexadecimal data dumps in an open, modern, transport- and vendor-neutral format. [STANDARDS-TRACK]

 draft-strombergson-shf-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4194 10.17487/RFC4194 RFC4195 A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum W. Kameyama October 2005 ASCII HTML 6 digital broadcasting tv radio storage systems metadata schemas

This document describes a Uniform Resource Name (URN) namespace that is engineered by the TV-Anytime Forum for naming persistent resources published by the TV-Anytime Forum including the TV-Anytime Forum Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, and other documents. This memo provides information for the Internet community.

 draft-kameyama-tv-anytime-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4195 RFC4196 The SEED Cipher Algorithm and Its Use with IPsec H.J. Lee J.H. Yoon S.L. Lee J.I. Lee October 2005 ASCII HTML 12 ipsec esp encryption algorithm

This document describes the use of the SEED block cipher algorithm in the Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

 draft-lee-ipsec-cipher-seed-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4196 RFC4197 Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks M. Riegel Editor October 2005 ASCII HTML 24 digital signatures plesiochronous digital hierarchy sonet synchronous optical network sdh synchronous digital hierarchy pwe3 pseudo wire emulation

This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits. This memo provides information for the Internet community.

 draft-ietf-pwe3-tdm-requirements-08 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4197 10.17487/RFC4197 RFC4198 A Uniform Resource Name (URN) Namespace for Federated Content D. Tessman November 2005 ASCII HTML 7 content resource content collections

This document describes a URN (Uniform Resource Name) namespace for identifying content resources within federated content collections. A federated content collection often does not have a strong centralized authority but relies upon shared naming, metadata, and access conventions to provide interoperability among its members. This memo provides information for the Internet community.

 draft-dtessman-urn-namespace-federated-content-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4198 RFC4199 RFC4200 RFC4201 Link Bundling in MPLS Traffic Engineering (TE) K. Kompella Y. Rekhter L. Berger October 2005 ASCII HTML 12 multiprotocol label switching generalized multiprotocol label switching gmpls lsp label switched path interface identification tlvs

For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of <link identifier, label> is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct, which is described in this document. This document updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description. [STANDARDS-TRACK]

 draft-ietf-mpls-bundle-06 RFC3471 RFC3472 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4201 RFC4202 Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2005 ASCII HTML 27 open shortest path first

This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-routing-09 RFC6001 RFC6002 RFC7074 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4202 RFC4203 OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2005 ASCII HTML 11 open shortest path first

This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]

 draft-ietf-ccamp-ospf-gmpls-extensions-12 RFC3630 RFC6001 RFC6002 RFC7074 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4203 RFC4204 Link Management Protocol (LMP) J. Lang Editor October 2005 ASCII HTML 86 gmpls sonet sdh discovery link verification fault managment control channel management link property correlation traffic engineering links trace monitoring

For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. [STANDARDS-TRACK]

 draft-ietf-ccamp-lmp-10 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4204 10.17487/RFC4204 RFC4205 Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2005 ASCII HTML 11

This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). This memo provides information for the Internet community.

 draft-ietf-isis-gmpls-extensions-19 RFC5307 RFC3784 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC4205 RFC4206 Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) K. Kompella Y. Rekhter October 2005 ASCII HTML 14 lsr label switching router te lsp fa forwarding adjacency

To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).

This document describes the mechanisms to accomplish this. [PROPOSED STANDARD]

 draft-ietf-mpls-lsp-hierarchy-08 RFC6001 RFC6107 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4206 RFC4207 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages J. Lang D. Papadimitriou October 2005 ASCII HTML 15 gmpls discovery link verification fault management control channel management link property correlation traffic engineering links trace monitoring

This document details the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages. [STANDARDS-TRACK]

 draft-ietf-ccamp-lmp-test-sonet-sdh-04 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4207 10.17487/RFC4207 RFC4208 Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model G. Swallow J. Drake H. Ishimatsu Y. Rekhter October 2005 ASCII HTML 13 lsp label switched paths routing protocol signaling protocol

Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-overlay-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4208 RFC4209 Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems A. Fredette Editor J. Lang Editor October 2005 ASCII HTML 16 te traffic engineering peer nodes ols optical link interface requirements

The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing. This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link Interface Requirements" described in a companion document. [STANDARDS-TRACK]

 draft-ietf-ccamp-lmp-wdm-03 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4209 RFC4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) C. Adams S. Farrell T. Kause T. Mononen September 2005 ASCII HTML 95 PKICMP cryptographic authentication pkix pki X.509v3 certificate creation certificate management ca certification authority

This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK]

 draft-ietf-pkix-rfc2510bis-09 RFC2510 RFC6712 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4210 10.17487/RFC4210 RFC4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) J. Schaad September 2005 ASCII HTML 40 X.509-CRMF certification authority ca registration authority ra pkix pki certificate production crmf security encryption authenticaion

This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK]

 draft-ietf-pkix-rfc2511bis-08 RFC2511 RFC9045 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4211 10.17487/RFC4211 RFC4212 Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols M. Blinov C. Adams October 2005 ASCII HTML 19 X.509v3 public-key certificates crmf certificate request message format pkix certificate management protocol pkix-cmp certificate management messages over cms cmc

The Public-Key Infrastructure using X.509 (PKIX) Working Group of the Internet Engineering Task Force (IETF) has defined a number of certificate management protocols. These protocols are primarily focused on X.509v3 public-key certificates. However, it is sometimes desirable to manage certificates in alternative formats as well. This document specifies how such certificates may be requested using the Certificate Request Message Format (CRMF) syntax that is used by several different protocols. It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX Certificate Management Protocol (PKIX-CMP) and Certificate Management Messages over CMS (CMC). This memo provides information for the Internet community.

 draft-adams-cmpaltcert-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4212 RFC4213 Basic Transition Mechanisms for IPv6 Hosts and Routers E. Nordmark R. Gilligan October 2005 ASCII HTML 27 TRANS-IPV6 ipv4 dual sack configured tunneling

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures.

This document obsoletes RFC 2893. [STANDARDS-TRACK]

 draft-ietf-v6ops-mech-v2-07 RFC2893 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4213 10.17487/RFC4213 RFC4214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) F. Templin T. Gleeson M. Talwar D. Thaler October 2005 ASCII HTML 14 ISATAP] ipv4 link layer nbma non-broadcast multiple access

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects IPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers. ISATAP supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ngtrans-isatap-22 RFC5214 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4214 RFC4215 Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks J. Wiljakka Editor October 2005 ASCII HTML 24 internet protocol gprs general packet radio service global system for mobile communications gsm universal mobile telecommunications system umts wideband code division multiple access wcdma

This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.

The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed. This memo provides information for the Internet community.

 draft-ietf-v6ops-3gpp-analysis-11 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4215 RFC4216 MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements R. Zhang Editor J.-P. Vasseur Editor November 2005 ASCII HTML 29 inter-as mpls-te

This document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection, and specification development for any technical solution(s) meeting these requirements and supporting the scenarios. This memo provides information for the Internet community.

 draft-ietf-tewg-interas-mpls-te-req-09 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC4216 RFC4217 Securing FTP with TLS P. Ford-Hutchinson October 2005 ASCII HTML 29 security authentication file transfer protocol transport layer security

This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extensions to the FTP protocol defined by RFC 2228, "FTP Security Extensions". It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for Secure SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".

This specification is in accordance with RFC 959, "File Transfer Protocol". It relies on RFC 2246, "The TLS Protocol Version 1.0.", and RFC 2228, "FTP Security Extensions". [STANDARDS-TRACK]

 draft-murray-auth-ftp-ssl-16 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4217 10.17487/RFC4217 RFC4218 Threats Relating to IPv6 Multihoming Solutions E. Nordmark T. Li October 2005 ASCII HTML 31 security threats internet protocol version 6

This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.

The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to all IPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. This memo provides information for the Internet community.

 draft-ietf-multi6-multihoming-threats-03 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4218 RFC4219 Things Multihoming in IPv6 (MULTI6) Developers Should Think About E. Lear October 2005 ASCII HTML 12 security threats internet protocol version 6

This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution. This memo provides information for the Internet community.

 draft-ietf-multi6-things-to-think-about-01 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4219 RFC4220 Traffic Engineering Link Management Information Base M. Dubuc T. Nadeau J. Lang November 2005 ASCII HTML 54 mib network management protocols te te-link-std-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering (TE) document. [STANDARDS-TRACK]

 draft-ietf-mpls-telink-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4220 RFC4221 Multiprotocol Label Switching (MPLS) Management Overview T. Nadeau C. Srinivasan A. Farrel November 2005 ASCII HTML 32 mib management information base management architecture network management

A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.

This document describes the management architecture for MPLS and indicates the interrelationships between the different MIB modules used for MPLS network management. This memo provides information for the Internet community.

 draft-ietf-mpls-mgmt-overview-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4221 RFC4222 Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance G. Choudhury Editor October 2005 ASCII HTML 15 open shortest path first lsa link state advertisement

This document recommends methods that are intended to improve the scalability and stability of large networks using Open Shortest Path First (OSPF) Version 2 protocol. The methods include processing OSPF Hellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ospf-scalability-09 BCP0112 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg ospf 10.17487/RFC4222 RFC4223 Reclassification of RFC 1863 to Historic P. Savola October 2005 ASCII HTML 3 BGP-IDRP border gateway protocol inter-domain routing

This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative to a full mesh routing, to Historic status. This memo also obsoletes RFC 1863. This memo provides information for the Internet community.

 draft-ietf-idr-rfc1863-historic-00 RFC1863 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC4223 RFC4224 RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets G. Pelletier L-E. Jonsson K. Sandlund January 2006 ASCII HTML 21

RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles. This memo provides information for the Internet community.

 draft-ietf-rohc-over-reordering-03 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4224 RFC4225 Mobile IP Version 6 Route Optimization Security Design Background P. Nikander J. Arkko T. Aura G. Montenegro E. Nordmark December 2005 ASCII HTML 37 mipv6 mip

This document is an account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization security design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 security design in 2001 - 2002.

The document has two target audiences: (1) helping MIPv6 implementors to better understand the design choices in MIPv6 security procedures, and (2) allowing people dealing with mobility or multi-homing to avoid a number of potential security pitfalls in their designs. This memo provides information for the Internet community.

 draft-ietf-mip6-ro-sec-03 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4225 RFC4226 HOTP: An HMAC-Based One-Time Password Algorithm D. M'Raihi M. Bellare F. Hoornaert D. Naccache O. Ranen December 2005 ASCII HTML 37 hashed message authentication code security analysis oath open authentication authentication OATH

This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network (VPN) access, Wi-Fi network logon to transaction-oriented Web applications.

This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This memo provides information for the Internet community.

 draft-mraihi-oath-hmac-otp-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4226 10.17487/RFC4226 RFC4227 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) E. O'Tuathail M. Rose January 2006 ASCII HTML 21 xml extensible markup language remote procedure calling rpc asynchronous event notification unacknowledged messages binding

This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core. A SOAP binding describes how SOAP messages are transmitted in the network.

The SOAP is an XML-based (eXtensible Markup Language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, Remote Procedure Calling (RPC), asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. [STANDARDS-TRACK]

 draft-mrose-rfc3288bis-02 RFC3288 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4227 10.17487/RFC4227 RFC4228 Requirements for an IETF Draft Submission Toolset A. Rousskov December 2005 ASCII HTML 31 automation tool

This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting. This memo provides information for the Internet community.

 draft-ietf-tools-draft-submission-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4228 RFC4229 HTTP Header Field Registrations M. Nottingham J. Mogul December 2005 ASCII HTML 53 hyper text transfer protocol

This document defines the initial contents of a permanent IANA registry for HTTP header fields and a provisional repository for HTTP header fields, per RFC 3864. This memo provides information for the Internet community.

 draft-nottingham-hdrreg-http-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4229 10.17487/RFC4229 RFC4230 RSVP Security Properties H. Tschofenig R. Graveman December 2005 ASCII HTML 48 resource reservation protocol

This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities. This memo provides information for the Internet community.

 draft-ietf-nsis-rsvp-sec-properties-06 INFORMATIONAL INFORMATIONAL IETF tsv nsis http://www.rfc-editor.org/errata_search.php?rfc=4230 10.17487/RFC4230 RFC4231 Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 M. Nystrom December 2005 ASCII HTML 9 message authentication codes message authentication schemes

This document provides test vectors for the HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication schemes. It also provides ASN.1 object identifiers and Uniform Resource Identifiers (URIs) to identify use of these schemes in protocols. The test vectors provided in this document may be used for conformance testing. [STANDARDS-TRACK]

 draft-nystrom-smime-hmac-sha-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4231 10.17487/RFC4231 RFC4232 RFC4233 Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer K. Morneault S. Rengasami M. Kalla G. Sidebottom January 2006 ASCII HTML 73 stream control transmission protocol sctp signaling gateway sg media gateway controller mgc signaling media gateway interface

This document defines a protocol for backhauling of Integrated Services Digital Network (ISDN) Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.

This document obsoletes RFC 3057. [STANDARDS-TRACK]

 draft-ietf-sigtran-rfc3057bis-02 RFC3057 RFC5133 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC4233 RFC4234 Augmented BNF for Syntax Specifications: ABNF D. Crocker Editor P. Overell October 2005 ASCII HTML 16 ABNF] backus-naur form augmented backus-naur form rule definitions encoding core lexical analyzer electronic mail

Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity, with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]

 draft-crocker-abnf-rfc2234bis-00 RFC2234 RFC5234 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4234 10.17487/RFC4234 RFC4235 An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne R. Mahy Editor November 2005 ASCII HTML 39 sip events dialog package

This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE-initiated dialog usages in which the subscribed-to user is involved. [STANDARDS-TRACK]

 draft-ietf-sipping-dialog-package-06 RFC7463 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4235 10.17487/RFC4235 RFC4236 HTTP Adaptation with Open Pluggable Edge Services (OPES) A. Rousskov M. Stecher November 2005 ASCII HTML 27 callout protocol ocp opes tracing opes bypass

Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document extends those generic mechanisms for Hypertext Transfer Protocol (HTTP) adaptation. Together, application-agnostic OPES documents and this HTTP profile constitute a complete specification for HTTP adaptation with OPES. [STANDARDS-TRACK]

 draft-ietf-opes-http-03 PROPOSED STANDARD PROPOSED STANDARD IETF app opes 10.17487/RFC4236 RFC4237 Voice Messaging Directory Service G. Vaudreuil October 2005 ASCII HTML 13 vpim voice profile for internet mail

This document provides details of the Voice Profile for Internet Mail (VPIM) directory service. The service provides the email address of the recipient that is given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient.

The VPIM directory Schema provides essential additional attributes to recreate the voice mail user experience using standardized directories. This user experience provides, at the time of addressing, basic assurances that the message will be delivered as intended. This document combines two earlier documents, one from Anne Brown and one from Greg Vaudreuil, that define a voice messaging schema into a single working group submission. [STANDARDS-TRACK]

 draft-ietf-vpim-vpimdir-11 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim http://www.rfc-editor.org/errata_search.php?rfc=4237 10.17487/RFC4237 RFC4238 Voice Message Routing Service G. Vaudreuil October 2005 ASCII HTML 10 vpim telephone number addressing voice profile and intenret mail vpim directory

Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The complete service uses the Voice Profile for Internet Mail (VPIM) Directory service to lookup a VPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient. However, this service will take time to become widely deployed in the near term. This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities. [STANDARDS-TRACK]

 draft-ietf-vpim-routing-10 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim http://www.rfc-editor.org/errata_search.php?rfc=4238 10.17487/RFC4238 RFC4239 Internet Voice Messaging (IVM) S. McRae G. Parsons November 2005 ASCII HTML 11 voicemail vpim voice profile for internet mail

This document describes the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure.

The Internet Voice Messaging (IVM) concept described in this document is not a successor format to VPIM v2 (Voice Profile for Internet Mail Version 2), but rather an alternative specification for a different application. [STANDARDS-TRACK]

 draft-ietf-vpim-ivm-06 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC4239 RFC4240 Basic Network Media Services with SIP E. Burger Editor J. Van Dyke A. Spitzer December 2005 ASCII HTML 24 session initiation protocol network media services media servers application servers

In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.

This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. This memo provides information for the Internet community.

 draft-burger-sipping-netann-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4240 10.17487/RFC4240 RFC4241 A Model of IPv6/IPv4 Dual Stack Internet Access Service Y. Shirasaki S. Miyakawa T. Yamasaki A. Takenouchi December 2005 ASCII HTML 10 user network specification ntt communications adsl cpe customer preises equipment

This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide a IPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically. This memo provides information for the Internet community.

 draft-shirasaki-dualstack-service-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4241 10.17487/RFC4241 RFC4242 Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) S. Venaas T. Chown B. Volz November 2005 ASCII HTML 8 internet protocol

This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration. [STANDARDS-TRACK]

 draft-ietf-dhc-lifetime-03 RFC8415 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4242 RFC4243 Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option M. Stapp R. Johnson T. Palaniappan December 2005 ASCII HTML 7

This memo defines a new Vendor-Specific Information suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to include vendor-specific information in the DHCP messages it forwards, as configured by its administrator. [STANDARDS-TRACK]

 draft-ietf-dhc-vendor-suboption-00 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4243 RFC4244 An Extension to the Session Initiation Protocol (SIP) for Request History Information M. Barnes Editor November 2005 ASCII HTML 44 history-info retarget enhanced services voicemail automatic call distribution

This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. [STANDARDS-TRACK]

 draft-ietf-sip-history-info-06 RFC7044 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4244 10.17487/RFC4244 RFC4245 High-Level Requirements for Tightly Coupled SIP Conferencing O. Levin R. Even November 2005 ASCII HTML 12 session initiation protocol

This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications. This memo provides information for the Internet community.

 draft-ietf-sipping-conferencing-requirements-01 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4245 RFC4246 International Standard Audiovisual Number (ISAN) URN Definition M. Dolan February 2006 ASCII HTML 6 numbering system international identification audiovisual uniform resource identifier

The International Standard Audiovisual Number (ISAN) is a standard numbering system for the unique and international identification of audiovisual works. This document is the definition of the formal Uniform Resource Name (URN) Namespace Identifier (NID) for ISAN. This memo provides information for the Internet community.

 draft-dolan-urn-isan-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4246 RFC4247 Requirements for Header Compression over MPLS J. Ash B. Goode J. Hand R. Zhang November 2005 ASCII HTML 11 multiprotocol label switching voip voice over ip

Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC). We consider using MPLS to route compressed packets over an MPLS Label Switched Path (LSP) without compression/decompression cycles at each router. This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router. In this document, we give a problem statement, goals and requirements, and an example scenario. This memo provides information for the Internet community.

 draft-ietf-avt-hc-mpls-reqs-03 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC4247 RFC4248 The telnet URI Scheme P. Hoffman October 2005 ASCII HTML 4 uniform resource identifier url uniform resource locators

This document specifies the telnet Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS-TRACK]

 draft-hoffman-telnet-uri-05 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4248 RFC4249 Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components B. Lilly January 2006 ASCII HTML 14 header field generator header field parser

Implementation of generators and parsers of header fields requires certain information about those fields. Interoperability is most likely when all such information is explicitly provided by the technical specification of the fields. Lacking such explicit information, implementers may guess, and interoperability may suffer. This memo identifies information useful to implementers of header field generators and parsers. This memo provides information for the Internet community.

 draft-lilly-field-specification-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4249 RFC4250 The Secure Shell (SSH) Protocol Assigned Numbers S. Lehtinen C. Lonvick Editor January 2006 ASCII HTML 20 remote login

This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. [STANDARDS-TRACK]

 draft-ietf-secsh-assignednumbers-12 RFC8268 RFC9142 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4250 RFC4251 The Secure Shell (SSH) Protocol Architecture T. Ylonen C. Lonvick Editor January 2006 ASCII HTML 30 remote login ssh algorithm

The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. [STANDARDS-TRACK]

 draft-ietf-secsh-architecture-22 RFC8308 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4251 RFC4252 The Secure Shell (SSH) Authentication Protocol T. Ylonen C. Lonvick Editor January 2006 ASCII HTML 17 remote login public key password host-based client authentication

The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]

 draft-ietf-secsh-userauth-27 RFC8308 RFC8332 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4252 10.17487/RFC4252 RFC4253 The Secure Shell (SSH) Transport Layer Protocol T. Ylonen C. Lonvick Editor January 2006 ASCII HTML 32 remote login encryption server authentication integrity protection diffie-hellman key exchange diffie hellman

The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression.

Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated.

This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK]

 draft-ietf-secsh-transport-24 RFC6668 RFC8268 RFC8308 RFC8332 RFC8709 RFC8758 RFC9142 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4253 10.17487/RFC4253 RFC4254 The Secure Shell (SSH) Connection Protocol T. Ylonen C. Lonvick Editor January 2006 ASCII HTML 24 remote login interactive login remote execution encrypted tunnel

Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel.

The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. [STANDARDS-TRACK]

 draft-ietf-secsh-connect-25 RFC8308 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4254 10.17487/RFC4254 RFC4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints J. Schlyter W. Griffin January 2006 ASCII HTML 9 domain name system dnssec domain name system security

This document describes a method of verifying Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC). The document defines a new DNS resource record that contains a standard SSH key fingerprint. [STANDARDS-TRACK]

 draft-ietf-secsh-dns-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4255 10.17487/RFC4255 RFC4256 Generic Message Exchange Authentication for the Secure Shell Protocol (SSH) F. Cusack M. Forssen January 2006 ASCII HTML 12 remote login alphanumeric input

The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device). The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). [STANDARDS-TRACK]

 draft-ietf-secsh-auth-kbdinteract-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4256 10.17487/RFC4256 RFC4257 Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks G. Bernstein E. Mannie V. Sharma E. Gray December 2005 ASCII HTML 35 mpls optical switching sdh sonet

Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. This memo provides information for the Internet community.

 draft-ietf-ccamp-sdhsonet-control-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4257 RFC4258 Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) D. Brungard Editor November 2005 ASCII HTML 22 control domain hierarchy multi-level multi-layer inter-domain intra-domain e-nni i-nni uni

The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs).

This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-ason-routing-reqts-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4258 RFC4259 A Framework for Transmission of IP Datagrams over MPEG-2 Networks M.-J. Montpetit G. Fairhurst H. Clausen B. Collini-Nocker H. Linder November 2005 ASCII HTML 42 digital television dvb digital video broadcast atsc advanced television systems committee

This document describes an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television.

The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS. This memo provides information for the Internet community.

 draft-ietf-ipdvb-arch-04 INFORMATIONAL INFORMATIONAL IETF int ipdvb 10.17487/RFC4259 RFC4260 Mobile IPv6 Fast Handovers for 802.11 Networks P. McCann November 2005 ASCII HTML 15 link layer

This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.11 suite of specifications. This memo provides information for the Internet community.

 draft-ietf-mipshop-80211fh-04 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC4260 RFC4261 Common Open Policy Service (COPS) Over Transport Layer Security (TLS) J. Walker A. Kulkarni Editor December 2005 ASCII HTML 14 client-accept message

This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet.

This document also updates RFC 2748 by modifying the contents of the Client-Accept message. [STANDARDS-TRACK]

 draft-ietf-rap-cops-tls-11 RFC2748 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC4261 RFC4262 X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities S. Santesson December 2005 ASCII HTML 5 cryptographic capabilities

This document defines a certificate extension for inclusion of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities in X.509 public key certificates, as defined by RFC 3280. This certificate extension provides an optional method to indicate the cryptographic capabilities of an entity as a complement to the S/MIME Capabilities signed attribute in S/MIME messages according to RFC 3851. [STANDARDS-TRACK]

 draft-ietf-smime-certcapa-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC4262 RFC4263 Media Subtype Registration for Media Type text/troff B. Lilly January 2006 ASCII HTML 16

A text media subtype for tagging content consisting of juxtaposed text and formatting directives as used by the troff series of programs and for conveying information about the intended processing steps necessary to produce formatted output is described. This memo provides information for the Internet community.

 draft-lilly-text-troff-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4263 RFC4264 BGP Wedgies T. Griffin G. Huston November 2005 ASCII HTML 10 border gateway protocol

It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable. Also, the stable state where BGP converges may be selected by BGP in a non-deterministic manner. These stable, but unintended, BGP states are termed here "BGP Wedgies". This memo provides information for the Internet community.

 draft-ietf-grow-bgp-wedgies-03 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC4264 RFC4265 Definition of Textual Conventions for Virtual Private Network (VPN) Management B. Schliesser T. Nadeau November 2005 ASCII HTML 6 tc

This document describes Textual Conventions used for managing Virtual Private Networks (VPNs). [STANDARDS-TRACK]

 draft-ietf-l3vpn-tc-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn 10.17487/RFC4265 RFC4266 The gopher URI Scheme P. Hoffman November 2005 ASCII HTML 6 uniform resource identifier url

This document specifies the gopher Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS-TRACK]

 draft-hoffman-gopher-uri-03 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4266 RFC4267 The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml M. Froumentin November 2005 ASCII HTML 9 voice browser voice extensible markup language voicexml speech synthesis markup language ssml speech recognition grammar specification srgs call control xml ccxml pronunciation lexicon specification pls

This document defines the media types for the languages of the W3C Speech Interface Framework, as designed by the Voice Browser Working Group in the following specifications: the Voice Extensible Markup Language (VoiceXML), the Speech Synthesis Markup Language (SSML), the Speech Recognition Grammar Specification (SRGS), the Call Control XML (CCXML), and the Pronunciation Lexicon Specification (PLS). This memo provides information for the Internet community.

 draft-froumentin-voice-mediatypes-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4267 RFC4268 Entity State MIB S. Chisholm D. Perkins November 2005 ASCII HTML 19 management information base snmp entity-state-tc-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the Entity MIB to provide information about the state of physical entities.

In addition, this memo defines a set of Textual Conventions to represent various states of an entity. The intent is that these Textual Conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-entmib-state-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=4268 10.17487/RFC4268 RFC4269 The SEED Encryption Algorithm H.J. Lee S.J. Lee J.H. Yoon D.H. Cheon J.I. Lee December 2005 ASCII HTML 16 encryption algorithm seed cbc seed oid

This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea. Included are a description of the encryption and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B).

This document obsoletes RFC 4009. This memo provides information for the Internet community.

 draft-lee-rfc4009bis-02 RFC4009 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4269 RFC4270 Attacks on Cryptographic Hashes in Internet Protocols P. Hoffman B. Schneier November 2005 ASCII HTML 12 collision attacks hash algorithms ip digital certificates

Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers. This memo provides information for the Internet community.

 draft-hoffman-hash-attacks-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4270 10.17487/RFC4270 RFC4271 A Border Gateway Protocol 4 (BGP-4) Y. Rekhter Editor T. Li Editor S. Hares Editor January 2006 ASCII HTML 104 BGP-4 routing

This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.

The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.

BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.

This document obsoletes RFC 1771. [STANDARDS-TRACK]

 draft-ietf-idr-bgp4-26 RFC1771 RFC6286 RFC6608 RFC6793 RFC7606 RFC7607 RFC7705 RFC8212 RFC8654 RFC9072 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4271 10.17487/RFC4271 RFC4272 BGP Security Vulnerabilities Analysis S. Murphy January 2006 ASCII HTML 22 border gateway protocol attacks risks insider threat

Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior.

This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. This memo provides information for the Internet community.

 draft-ietf-idr-bgp-vuln-01 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC4272 RFC4273 Definitions of Managed Objects for BGP-4 J. Haas Editor S. Hares Editor January 2006 ASCII HTML 32 BGP-4-MIB management information base mib border gateway protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower.

The origin of this memo is from RFC 1269 "Definitions of Managed Objects for the Border Gateway Protocol (Version 3)", which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents.

This memo is intended to document deployed implementations of this MIB module in a historical context, to provide clarifications of some items, and to note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of the BGP protocol and its extensions.

This document obsoletes RFC 1269 and RFC 1657. [STANDARDS-TRACK]

 draft-ietf-idr-bgp4-mib-15 RFC1269 RFC1657 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4273 10.17487/RFC4273 RFC4274 BGP-4 Protocol Analysis D. Meyer K. Patel January 2006 ASCII HTML 16 border gateway protocol

The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).

This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1774 and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community.

 draft-ietf-idr-bgp-analysis-07 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4274 10.17487/RFC4274 RFC4275 BGP-4 MIB Implementation Survey S. Hares D. Hares January 2006 ASCII HTML 37 border gateway protocol management information base

This document provides a survey of implementations of BGP-4 that support RFC 1657 MIB agents according to the BGP-4 v1 MIB specification. This memo provides information for the Internet community.

 draft-ietf-idr-bgp-mibagent-survey-02 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4275 10.17487/RFC4275 RFC4276 BGP-4 Implementation Report S. Hares A. Retana January 2006 ASCII HTML 97 border gateway protocol

This document reports the results of the BGP-4 implementation survey. The survey had 259 questions about implementations' support of BGP-4 as specified in RFC 4271. After a brief summary of the results, each response is listed. This document contains responses from the four implementers that completed the survey (Alcatel, Cisco, Laurel, and NextHop) and brief information from three that did not (Avici, Data Connection Ltd., and Nokia).

The editors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on. This memo provides information for the Internet community.

 draft-ietf-idr-bgp-implementation-02 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC4276 RFC4277 Experience with the BGP-4 Protocol D. McPherson K. Patel January 2006 ASCII HTML 19 border gateway protocol

The purpose of this memo is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).

This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. This memo provides information for the Internet community.

 draft-ietf-idr-bgp4-experience-protocol-05 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4277 10.17487/RFC4277 RFC4278 Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification S. Bellovin A. Zinin January 2006 ASCII HTML 7 border gateway protocol

The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization. RFC 2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. This document explains why the IESG is considering doing so for the revised version of the BGP-4 specification, which refers normatively to RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain at the Proposed Standard level. This memo provides information for the Internet community.

 draft-iesg-tcpmd5app-01 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC4278 RFC4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) P. Eronen Editor H. Tschofenig Editor December 2005 ASCII HTML 15 psk psks symmetric keys diffie-hellman

This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. [STANDARDS-TRACK]

 draft-ietf-tls-psk-09 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC4279 RFC4280 Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers K. Chowdhury P. Yegani L. Madour November 2005 ASCII HTML 11 bcmcs 3g third generation cellular telephone mobile node mn

This document defines new options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network. BCMCS is being developed for Third generation (3G) cellular telephone networks. Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive Broadcast and Multicast Service. Dynamic Host Configuration Protocol can be used to configure the MN to access a particular controller. This document defines the related options and option codes. [STANDARDS-TRACK]

 draft-ietf-dhc-bcmc-options-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4280 10.17487/RFC4280 RFC4281 The Codecs Parameter for "Bucket" Media Types R. Gellens D. Singer P. Frojdh November 2005 ASCII HTML 29 codec container audio video 3gpp 3gpp2

Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from the Content-Type alone if the content can be rendered.

This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs indicated by the media formats contained within.

By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) [STANDARDS-TRACK]

 draft-gellens-mime-bucket-04 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4281 10.17487/RFC4281 RFC4282 The Network Access Identifier B. Aboba M. Beadles J. Arkko P. Eronen December 2005 ASCII HTML 16 NAI nai roaming tunneling

In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, \%customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and \%ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. [STANDARDS-TRACK]

 draft-ietf-radext-rfc2486bis-06 RFC2486 RFC7542 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4282 10.17487/RFC4282 RFC4283 Mobile Node Identifier Option for Mobile IPv6 (MIPv6) A. Patel K. Leung M. Khalil H. Akhtar K. Chowdhury November 2005 ASCII HTML 8 mobility header mobile nodes correspondent nodes home agents

Mobile IPv6 (MIPv6) defines a new Mobility header that is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), International Mobile Station Identifier (IMSI), and Mobile Subscriber Number (MSISDN). This document defines a new mobility option that can be used by Mobile IPv6 entities to identify themselves in messages containing a mobility header. [STANDARDS-TRACK]

 draft-ietf-mip6-mn-ident-option-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4283 10.17487/RFC4283 RFC4284 Identity Selection Hints for the Extensible Authentication Protocol (EAP) F. Adrangi V. Lortz F. Bari P. Eronen January 2006 ASCII HTML 14 nai network access identifier

The Extensible Authentication Protocol (EAP) is defined in RFC 3748. This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer -- the end of the link that responds to the authenticator. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier (NAI). This is useful in situations where the peer does not receive a lower-layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker.

The mechanism defined in this document is limited in its scalability. It is intended for access networks that have a small to moderate number of direct roaming partners. This memo provides information for the Internet community.

 draft-adrangi-eap-network-discovery-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4284 RFC4285 Authentication Protocol for Mobile IPv6 A. Patel K. Leung M. Khalil H. Akhtar K. Chowdhury January 2006 ASCII HTML 19 ip security ipsec mip6 mobile node home agent

IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6). MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents. The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages. This memo provides information for the Internet community.

 draft-ietf-mip6-auth-protocol-07 INFORMATIONAL INFORMATIONAL IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4285 10.17487/RFC4285 RFC4286 Multicast Router Discovery B. Haberman J. Martin December 2005 ASCII HTML 18 igmp internet group management protocol mld multicast listener discovery mrd

The concept of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors.

This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols. [STANDARDS-TRACK]

 draft-ietf-magma-mrdisc-07 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=4286 10.17487/RFC4286 RFC4287 The Atom Syndication Format M. Nottingham Editor R. Sayre Editor December 2005 ASCII HTML 43 xml-basd web content metadata

This document specifies Atom, an XML-based Web content and metadata syndication format. [STANDARDS-TRACK]

 draft-ietf-atompub-format-11 RFC5988 PROPOSED STANDARD PROPOSED STANDARD IETF app atompub 10.17487/RFC4287 RFC4288 Media Type Specifications and Registration Procedures N. Freed J. Klensin December 2005 ASCII HTML 24 mime multipurpose internet mail extensions media types

This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-freed-media-type-reg-05 RFC2048 RFC6838 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4288 10.17487/RFC4288 RFC4289 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures N. Freed J. Klensin December 2005 ASCII HTML 11 media types external body access content-transfer-encodings

This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-freed-mime-p4-07 RFC2048 BCP0013 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4289 RFC4290 Suggested Practices for Registration of Internationalized Domain Names (IDN) J. Klensin December 2005 ASCII HTML 28 chinese domain names japanese domain names korean domain names

This document explores the issues in the registration of internationalized domain names (IDNs). The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar-looking names. To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed for Chinese, Japanese, and Korean domain names. This memo provides information for the Internet community.

 draft-klensin-reg-guidelines-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4290 10.17487/RFC4290 RFC4291 IP Version 6 Addressing Architecture R. Hinden S. Deering February 2006 ASCII HTML 25 internet protocol version 6 unicast anycast multicast node

This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.

This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]

 draft-ietf-ipv6-addr-arch-v4-04 RFC3513 RFC5952 RFC6052 RFC7136 RFC7346 RFC7371 RFC8064 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4291 10.17487/RFC4291 RFC4292 IP Forwarding Table MIB B. Haberman April 2006 ASCII HTML 34 TABLE-MIB Management Information Base Internet Protocol

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets in an IP version-independent manner. This document obsoletes RFC 2096. [STANDARDS-TRACK]

 draft-ietf-ipv6-rfc2096-update-07 RFC2096 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4292 RFC4293 Management Information Base for the Internet Protocol (IP) S. Routhier Editor April 2006 ASCII HTML 122 MIB-IP IP Simple Network Management Protocol MIB ipv6 ICMPv6-MIB| mib internet protocol ip mib ipv4 mib ipv6 mib icmp mib icmpv6 mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465, and 2466. [STANDARDS-TRACK]

 draft-ietf-ipv6-rfc2011-update-10 RFC2011 RFC2465 RFC2466 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4293 10.17487/RFC4293 RFC4294 IPv6 Node Requirements J. Loughney Editor April 2006 ASCII HTML 20 internet protocol version 6

This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This memo provides information for the Internet community.

 draft-ietf-ipv6-node-requirements-11 RFC6434 RFC5095 INFORMATIONAL INFORMATIONAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4294 10.17487/RFC4294 RFC4295 Mobile IPv6 Management Information Base G. Keeni K. Koide K. Nagami S. Gundavelli April 2006 ASCII HTML 109 mib mipv6

This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent, and correspondent node functions of a Mobile IPv6 (MIPv6) entity. [STANDARDS-TRACK]

 draft-ietf-mip6-mipv6-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4295 10.17487/RFC4295 RFC4296 The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols S. Bailey T. Talpey December 2005 ASCII HTML 22 rddp warp

This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g., RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements. This memo provides information for the Internet community.

 draft-ietf-rddp-arch-07 INFORMATIONAL INFORMATIONAL IETF tsv rddp http://www.rfc-editor.org/errata_search.php?rfc=4296 10.17487/RFC4296 RFC4297 Remote Direct Memory Access (RDMA) over IP Problem Statement A. Romanow J. Mogul T. Talpey S. Bailey December 2005 ASCII HTML 20 overhead copy avoidance

Overhead due to the movement of user data in the end-system network I/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks, and the Internet itself -- especially where high bandwidth, low latency, and/or low overhead are required by the hosted application.

This document examines this overhead, and addresses an architectural, IP-based "copy avoidance" solution for its elimination, by enabling Remote Direct Memory Access (RDMA). This memo provides information for the Internet community.

 draft-ietf-rddp-problem-statement-05 INFORMATIONAL INFORMATIONAL IETF tsv rddp 10.17487/RFC4297 RFC4298 RTP Payload Format for BroadVoice Speech Codecs J.-H. Chen W. Lee J. Thyssen December 2005 ASCII HTML 14 real time transport narroband wideband bv16 broadvoice16 sdp session description protocol

This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs. The narrowband codec, called BroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification. The document also provides specifications for the use of BroadVoice with MIME and the Session Description Protocol (SDP). [STANDARDS-TRACK]

 draft-ietf-avt-rtp-bv-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4298 RFC4299 RFC4300 RFC4301 Security Architecture for the Internet Protocol S. Kent K. Seo December 2005 ASCII HTML 101 IPSEC ipsec authentication encapsulation IP IPv4 IPv6 IP-layer ip authentication header ip security IPsec confidentiality authentication integrity anti-replay ah esp encapsulating security payload ike internet key exchange ikev2 esn extended sequence number

This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]

 draft-ietf-ipsec-rfc2401bis-06 RFC2401 RFC3168 RFC6040 RFC7619 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4301 10.17487/RFC4301 RFC4302 IP Authentication Header S. Kent December 2005 ASCII HTML 34 IP-AUTH ipsec Internet Protocol AH security IPv4 IPv6 ip security confidentiality authentication integrity anti-replay ah esp encapsulating security payload ike internet key exchange ikev2 esn extended sequence number

This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK]

 draft-ietf-ipsec-rfc2402bis-10 RFC2402 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4302 10.17487/RFC4302 RFC4303 IP Encapsulating Security Payload (ESP) S. Kent December 2005 ASCII HTML 44 ESP ipsec internet protocol encapsulating security ipv4 ipv6 ip security confidentiality authentication integrity anti-replay ah ip authentication header ike internet key exchange ikev2 esn extended sequence number

This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]

 draft-ietf-ipsec-esp-v3-10 RFC2406 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4303 10.17487/RFC4303 RFC4304 Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) S. Kent December 2005 ASCII HTML 5 ipsecurity anti-replay ah ip authentication header esp encapsulating security payload ike internet key exchange ikev2

The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol (ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended (64-bit) sequence numbers (ESNs) for a particular AH or ESP security association. [STANDARDS-TRACK]

 draft-ietf-ipsec-esn-addendum-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC4304 RFC4305 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) D. Eastlake 3rd December 2005 ASCII HTML 9 ESP ipsec authentication mechanism header security architecture payload internet protocol encapsulating ipv4 ipv6

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]

 draft-ietf-ipsec-esp-ah-algorithms-02 RFC2402 RFC2406 RFC4835 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4305 10.17487/RFC4305 RFC4306 Internet Key Exchange (IKEv2) Protocol C. Kaufman Editor December 2005 ASCII HTML 99 ISAKMPSEC ipsec internet protocol security association key management ipsec cryptography authentication IKE oakley isakmp

This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs).

This version of the IKE specification combines the contents of what were previously separate documents, including Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network Address Translation (NAT) Traversal, Legacy authentication, and remote address acquisition.

Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. [STANDARDS-TRACK]

 draft-ietf-ipsec-ikev2-17 RFC2407 RFC2408 RFC2409 RFC5996 RFC5282 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4306 10.17487/RFC4306 RFC4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) J. Schiller December 2005 ASCII HTML 6 ipsec ike internet key exchange

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate which algorithms should be used in any given association. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]

 draft-ietf-ipsec-ikev2-algorithms-05 RFC8247 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4307 10.17487/RFC4307 RFC4308 Cryptographic Suites for IPsec P. Hoffman December 2005 ASCII HTML 7 ike internet key exchange ikev2 security algorithms ikev1

The IPsec, Internet Key Exchange (IKE), and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKEv1 or with IKEv2. [STANDARDS-TRACK]

 draft-ietf-ipsec-ui-suites-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4308 10.17487/RFC4308 RFC4309 Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) R. Housley December 2005 ASCII HTML 13 cbc-mac mode initialization vector iv confidentiality data origin authentication connectionless integrity

This document describes the use of Advanced Encryption Standard (AES) in Counter with CBC-MAC (CCM) Mode, with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity. [STANDARDS-TRACK]

 draft-ietf-ipsec-ciph-aes-ccm-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4309 10.17487/RFC4309 RFC4310 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) S. Hollenbeck December 2005 ASCII HTML 22 dnssec domain name system security extensions

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. [STANDARDS-TRACK]

 draft-hollenbeck-epp-secdns-08 RFC5910 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4310 RFC4311 IPv6 Host-to-Router Load Sharing R. Hinden D. Thaler November 2005 ASCII HTML 5 internet protocol version 6 conceptual sending algorithm

The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion. [STANDARDS-TRACK]

 draft-ietf-ipv6-host-load-sharing-04 RFC2461 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4311 RFC4312 The Camellia Cipher Algorithm and Its Use With IPsec A. Kato S. Moriai M. Kanda December 2005 ASCII HTML 8 cipher block chaining mode initialization vector iv esp encapsulating security payload ip security

This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining Mode, with an explicit Initialization Vector, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

 draft-kato-ipsec-ciph-camellia-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4312 10.17487/RFC4312 RFC4313 Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources D. Oran December 2005 ASCII HTML 20 speech processing audio streams si speaker identification sv speaker verification tts text to speech

This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition -- which includes both speaker identification (SI) and speaker verification (SV) -- and text-to-speech (TTS). Other IETF protocols, such as SIP and Real Time Streaming Protocol (RTSP), address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. This memo provides information for the Internet community.

 draft-ietf-speechsc-reqts-07 INFORMATIONAL INFORMATIONAL IETF rai speechsc 10.17487/RFC4313 RFC4314 IMAP4 Access Control List (ACL) Extension A. Melnikov December 2005 ASCII HTML 27 IMAP4-ACL Control List interet message access protocol

The Access Control List (ACL) extension (RFC 2086) of the Internet Message Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol.

This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands. [STANDARDS-TRACK]

 draft-ietf-imapext-2086upd-08 RFC2086 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=4314 10.17487/RFC4314 RFC4315 Internet Message Access Protocol (IMAP) - UIDPLUS extension M. Crispin December 2005 ASCII HTML 8 IMAP4UIDPL internet message access protocol disconnected operation

The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. [STANDARDS-TRACK]

 draft-crispin-imap-rfc2359bis-04 RFC2359 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4315 RFC4316 Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties J. Reschke December 2005 ASCII HTML 11 datatying propfind

This specification extends the Web Distributed Authoring and Versioning Protocol (WebDAV) to support datatyping. Protocol elements are defined to let clients and servers specify the datatype, and to instruct the WebDAV method PROPFIND to return datatype information. This memo defines an Experimental Protocol for the Internet community.

 draft-reschke-webdav-property-datatypes-09 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4316 RFC4317 Session Description Protocol (SDP) Offer/Answer Examples A. Johnston R. Sparks December 2005 ASCII HTML 24

This document gives examples of Session Description Protocol (SDP) offer/answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types. Common Third Party Call Control (3pcc) examples are also given. This memo provides information for the Internet community.

 draft-ietf-mmusic-offer-answer-examples-06 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC4317 RFC4318 Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol D. Levi D. Harrington December 2005 ASCII HTML 14 management information base simple network management protocol transparent bridging rstp-mib

This memo defines an SMIv2 MIB module for managing the Rapid Spanning Tree capability defined by the IEEE P802.1t and P802.1w amendments to IEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) segments. The objects in this MIB are defined to apply both to transparent bridging and to bridges connected by subnetworks other than LAN segments. [STANDARDS-TRACK]

 draft-ietf-bridge-rstpmib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge 10.17487/RFC4318 RFC4319 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines C. Sikes B. Ray R. Abbi December 2005 ASCII HTML 75 mib management information base hdsl2-shdsl-line-mib interfaces

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate Digital Subscriber Line (DSL) - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. This document introduces extensions to several objects and textual conventions defined in HDSL2-SHDSL-Line MIB (RFC 3276). This document obsoletes RFC 3276. [STANDARDS-TRACK]

 draft-ietf-adslmib-gshdslbis-11 RFC3276 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=4319 10.17487/RFC4319 RFC4320 Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction R. Sparks January 2006 ASCII HTML 7

This document describes modifications to the Session Initiation Protocol (SIP) to address problems that have been identified with the SIP non-INVITE transaction. These modifications reduce the probability of messages losing the race condition inherent in the non-INVITE transaction and reduce useless network traffic. They also improve the robustness of SIP networks when elements stop responding. These changes update behavior defined in RFC 3261. [STANDARDS-TRACK]

 draft-sparks-sip-nit-actions-03 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4320 RFC4321 Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction R. Sparks January 2006 ASCII HTML 10

This document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction. This memo provides information for the Internet community.

 draft-sparks-sip-nit-problems-02 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC4321 RFC4322 Opportunistic Encryption using the Internet Key Exchange (IKE) M. Richardson D.H. Redelmeier December 2005 ASCII HTML 44 oe linux frees/wan ipsec dns domain name space dns security

This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet Key Exchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well.

As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance. This memo provides information for the Internet community.

 draft-richardson-ipsec-opportunistic-17 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4322 10.17487/RFC4322 RFC4323 Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB) M. Patrick W. Murwin January 2006 ASCII HTML 89 snmp simple network management protocol cm cable modem cmts cable modem termination system docs-ietf-qos-mib

This document defines a basic set of managed objects for SNMP-based management of extended QoS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) specifications versions 1.1 and 2.0. [STANDARDS-TRACK]

 draft-ietf-ipcdn-qos-mib-12 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4323 RFC4324 Calendar Access Protocol (CAP) D. Royer G. Babics S. Mansour December 2005 ASCII HTML 131 calendar user cu calendar user agent cua ical calender store cs

The Calendar Access Protocol (CAP) described in this memo permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS). At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols. This memo defines an Experimental Protocol for the Internet community.

 draft-royer-calsch-cap-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4324 RFC4325 Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension S. Santesson R. Housley December 2005 ASCII HTML 7 issuer certificate

This document updates RFC 3280 by defining the Authority Information Access Certificate Revocation List (CRL) extension. RFC 3280 defines the Authority Information Access certificate extension using the same syntax. The CRL extension provides a means of discovering and retrieving CRL issuer certificates. [STANDARDS-TRACK]

 draft-ietf-pkix-crlaia-03 RFC5280 RFC3280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4325 RFC4326 Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS) G. Fairhurst B. Collini-Nocker December 2005 ASCII HTML 42

The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks.

This document describes a Unidirectional Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing. [STANDARDS-TRACK]

 draft-ietf-ipdvb-ule-06 RFC7280 PROPOSED STANDARD PROPOSED STANDARD IETF int ipdvb http://www.rfc-editor.org/errata_search.php?rfc=4326 10.17487/RFC4326 RFC4327 Link Management Protocol (LMP) Management Information Base (MIB) M. Dubuc T. Nadeau J. Lang E. McGinnis January 2006 ASCII HTML 82 lmp-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). [STANDARDS-TRACK]

 draft-ietf-ccamp-lmp-mib-10 RFC4631 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4327 10.17487/RFC4327 RFC4328 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control D. Papadimitriou Editor January 2006 ASCII HTML 23 otn optical transport networks pre-otn

This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology-specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-g709-09 RFC3471 RFC7139 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4328 RFC4329 Scripting Media Types B. Hoehrmann April 2006 ASCII HTML 15 JavaScript EMACScript mime script subtype

This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This memo provides information for the Internet community.

 draft-hoehrmann-script-types-03 RFC9239 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4329 RFC4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI D. Mills January 2006 ASCII HTML 27 NTP time computer clock synchronization

This memorandum describes the Simple Network Time Protocol Version 4 (SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based on RFC 1305 is neither needed nor justified. When operating with current and previous NTP and SNTP versions, SNTPv4 requires no changes to the specifications or known implementations, but rather clarifies certain design features that allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868.

This memorandum obsoletes RFC 1769, which describes SNTP Version 3 (SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to correct certain inconsistencies in the previous documents and to clarify header formats and protocol operations for NTPv3 (IPv4) and SNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A further purpose is to provide guidance for home and business client implementations for routers and other consumer devices to protect the server population from abuse. A working knowledge of the NTPv3 specification, RFC 1305, is not required for an implementation of SNTP. This memo provides information for the Internet community.

 draft-mills-sntp-v4-01 RFC2030 RFC1769 RFC5905 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4330 10.17487/RFC4330 RFC4331 Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections B. Korver L. Dusseault February 2006 ASCII HTML 10 webdav

Web Distributed Authoring and Versioning (WebDAV) servers are frequently deployed with quota (size) limitations. This document discusses the properties and minor behaviors needed for clients to interoperate with quota (size) implementations on WebDAV repositories. [STANDARDS-TRACK]

 draft-ietf-webdav-quota-07 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav 10.17487/RFC4331 RFC4332 Cisco's Mobile IPv4 Host Configuration Extensions K. Leung A. Patel G. Tsirtsis E. Klovning December 2005 ASCII HTML 11 dynamic host configuration protocol dhcp point-to-point ip control protocol ppp ipcp

An IP device requires basic host configuration to be able to communicate. For example, it will typically require an IP address and the address of a DNS server. This information is configured statically or obtained dynamically using Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol/IP Control Protocol (PPP/IPCP). However, both DHCP and PPP/IPCP provide host configuration based on the access network. In Mobile IPv4, the registration process boots up a Mobile Node at an access network, also known as a foreign network. The information to configure the host needs to be based on the home network. This document describes the Cisco vendor-specific extensions to Mobile IPv4 to provide the base host configuration in Registration Request and Reply messages. This memo provides information for the Internet community.

 draft-leung-cisco-mip4-host-config-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4332 RFC4333 The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process G. Huston Editor B. Wijnen Editor December 2005 ASCII HTML 9 iad iasa ietf administrative support activity ietf administrative director

This memo outlines the guidelines for selection of members of the IETF Administrative Oversight Committee, and describes the selection process used by the IAB and the IESG. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-iab-iesg-iaoc-selection-03 RFC8711 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC4333 RFC4334 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) R. Housley T. Moore February 2006 ASCII HTML 11 eap extensible authentication protocol wireless lan wlan system service identifier ssid

This document defines two Extensible Authentication Protocol (EAP) extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). This document obsoletes RFC 3770. [STANDARDS-TRACK]

 draft-ietf-pkix-rfc3770bis-03 RFC3770 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4334 10.17487/RFC4334 RFC4335 The Secure Shell (SSH) Session Channel Break Extension J. Galbraith P. Remaker January 2006 ASCII HTML 6

The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session. [STANDARDS-TRACK]

 draft-ietf-secsh-break-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4335 10.17487/RFC4335 RFC4336 Problem Statement for the Datagram Congestion Control Protocol (DCCP) S. Floyd M. Handley E. Kohler March 2006 ASCII HTML 22

This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control. DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games. This memo provides information for the Internet community.

 draft-ietf-dccp-problem-03 INFORMATIONAL INFORMATIONAL IETF tsv dccp 10.17487/RFC4336 RFC4337 MIME Type Registration for MPEG-4 Y. Lim D. Singer March 2006 ASCII HTML 11

This document defines the standard MIME types associated with MP4 files. It also recommends use of registered MIME types according to the type of contents. [STANDARDS-TRACK]

 draft-lim-mpeg4-mime-03 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4337 10.17487/RFC4337 RFC4338 Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel C. DeSanti C. Carlson R. Nixon January 2006 ASCII HTML 33 link local address link-local address

This document specifies the way of encapsulating IPv6, IPv4, and Address Resolution Protocol (ARP) packets over Fibre Channel. This document also specifies the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks.

This document obsoletes RFC 2625 and RFC 3831. [STANDARDS-TRACK]

 draft-ietf-imss-ip-over-fibre-channel-03 RFC3831 RFC2625 RFC5494 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4338 RFC4339 IPv6 Host Configuration of DNS Server Information Approaches J. Jeong Editor February 2006 ASCII HTML 26 domain name server internet protocol address configuration dhcpv6 dynamic host configuration protocol

This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers. Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise, 3GPP, and unmanaged networks) considering multi-solution resolution. This memo provides information for the Internet community.

 draft-ietf-dnsop-ipv6-dns-configuration-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=4339 10.17487/RFC4339 RFC4340 Datagram Congestion Control Protocol (DCCP) E. Kohler M. Handley S. Floyd March 2006 ASCII HTML 129 transport protocol

The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. [STANDARDS-TRACK]

 draft-ietf-dccp-spec-11 RFC5595 RFC5596 RFC6335 RFC6773 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=4340 10.17487/RFC4340 RFC4341 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control S. Floyd E. Kohler March 2006 ASCII HTML 20 transport protocol amid additive increase multiplicative decrease

This document contains the profile for Congestion Control Identifier 2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion Control Protocol (DCCP). CCID 2 should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control. [STANDARDS-TRACK]

 draft-ietf-dccp-ccid2-10 RFC8311 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC4341 RFC4342 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC) S. Floyd E. Kohler J. Padhye March 2006 ASCII HTML 33 transport protocol ecn explicit congestion notification ccid3

This document contains the profile for Congestion Control Identifier 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 3 should be used by senders that want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. [STANDARDS-TRACK]

 draft-ietf-dccp-ccid3-11 RFC5348 RFC6323 RFC8311 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=4342 10.17487/RFC4342 RFC4343 Domain Name System (DNS) Case Insensitivity Clarification D. Eastlake 3rd January 2006 ASCII HTML 10

Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS-TRACK]

 draft-ietf-dnsext-insensitive-06 RFC1034 RFC1035 RFC2181 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4343 10.17487/RFC4343 RFC4344 The Secure Shell (SSH) Transport Layer Encryption Modes M. Bellare T. Kohno C. Namprempre January 2006 ASCII HTML 12 rekey

Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks.

This document describes new symmetric encryption methods for the Secure Shell (SSH) Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. [STANDARDS-TRACK]

 draft-ietf-secsh-newmodes-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4344 RFC4345 Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol B. Harris January 2006 ASCII HTML 5 arcfour cipher key scheduling algorithm

This document specifies methods of using the Arcfour cipher in the Secure Shell (SSH) protocol that mitigate the weakness of the cipher's key-scheduling algorithm. [STANDARDS-TRACK]

 draft-harris-ssh-arcfour-fixes-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4345 10.17487/RFC4345 RFC4346 The Transport Layer Security (TLS) Protocol Version 1.1 T. Dierks E. Rescorla April 2006 ASCII HTML 87

This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.

 draft-ietf-tls-rfc2246-bis-13 RFC2246 RFC5246 RFC4366 RFC4680 RFC4681 RFC5746 RFC6176 RFC7465 RFC7507 RFC7919 HISTORIC PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=4346 10.17487/RFC4346 RFC4347 Datagram Transport Layer Security E. Rescorla N. Modadugu April 2006 ASCII HTML 25 dtls

This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol.

 draft-rescorla-dtls-05 RFC6347 RFC5746 RFC7507 HISTORIC PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4347 10.17487/RFC4347 RFC4348 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec S. Ahmadi January 2006 ASCII HTML 32 speech codec variable-rate multicode wideband speech codec

This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. A media type registration is included for VMR-WB RTP payload format.

VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this document to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-vmr-wb-11 RFC4424 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4348 RFC4349 High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3) C. Pignataro M. Townsley February 2006 ASCII HTML 11 pseudowire

The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnel High-Level Data Link Control (HDLC) frames over L2TPv3. [STANDARDS-TRACK]

 draft-ietf-l2tpext-pwe3-hdlc-07 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4349 RFC4350 A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government F. Hendrikx C. Wallis February 2006 ASCII HTML 11 nid namespace identification

This document describes a Uniform Resource Name (URN) Namespace Identification (NID)convention as prescribed by the World Wide Web Consortium (W3C) for identifying, naming, assigning, and managing persistent resources and XML artefacts for the New Zealand Government. This memo provides information for the Internet community.

 draft-hendrikx-wallis-urn-nzl-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4350 RFC4351 Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream G. Hellstrom P. Jones January 2006 ASCII HTML 20 itu-t recommendation t.140

This memo describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.

One payload format is described for transmitting audio and text data within a single RTP session.

This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. This memo defines a Historic Document for the Internet community.

 draft-ietf-avt-audio-t140c-00 HISTORIC HISTORIC IETF rai avt 10.17487/RFC4351 RFC4352 RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec J. Sjoberg M. Westerlund A. Lakaniemi S. Wenger January 2006 ASCII HTML 38 real-time transport protocol audio signals

This document specifies a Real-time Transport Protocol (RTP) payload format for Extended Adaptive Multi-Rate Wideband (AMR-WB+) encoded audio signals. The AMR-WB+ codec is an audio extension of the AMR-WB speech codec. It encompasses the AMR-WB frame types and a number of new frame types designed to support high-quality music and speech. A media type registration for AMR-WB+ is included in this specification. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-amrwbplus-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4352 10.17487/RFC4352 RFC4353 A Framework for Conferencing with the Session Initiation Protocol (SIP) J. Rosenberg February 2006 ASCII HTML 29

The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing. This memo provides information for the Internet community.

 draft-ietf-sipping-conferencing-framework-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4353 RFC4354 A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service M. Garcia-Martin January 2006 ASCII HTML 21 oma open mobile alliance

The Open Mobile Alliance (OMA) is defining the Push-to-talk over Cellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants, to send instant messages, etc. This document defines a SIP event package to support publication, subscription, and notification of additional capabilities required by the PoC service. This SIP event package is applicable to the PoC service and may not be applicable to the general Internet. This memo provides information for the Internet community.

 draft-garcia-sipping-poc-isb-am-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4354 RFC4355 IANA Registration for Enumservices email, fax, mms, ems, and sms R. Brandner L. Conroy R. Stastny January 2006 ASCII HTML 16 domain name system

This document registers the Enumservices "email", "fax", "sms", "ems", and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC 3761. [STANDARDS-TRACK]

 draft-ietf-enum-msg-05 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4355 RFC4356 Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail R. Gellens January 2006 ASCII HTML 31 cellular telephone x-mms

The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols that are similar to, but differ in key ways from, those used in Internet mail.

One important difference between MMS and Internet Mail is that MMS uses headers that start with "X-Mms-" to carry a variety of user agent- and server-related information elements.

This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in SMTP and Internet message headers. [STANDARDS-TRACK]

 draft-ietf-lemonade-mms-mapping-06 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC4356 RFC4357 Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms V. Popov I. Kurepkin S. Leontiev January 2006 ASCII HTML 51 cpalgs public-key one-way hash block cipher encyption decryption mac hmac prf wrap unwrap ukm kek key parameter derivation digest cbc counter mode digital signature

This document describes the cryptographic algorithms and parameters supplementary to the original GOST specifications, GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94, for use in Internet applications. This memo provides information for the Internet community.

 draft-popov-cryptopro-cpalgs-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4357 10.17487/RFC4357 RFC4358 A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA) D. Smith January 2006 ASCII HTML 6 nid namespace identifier omna open mobile naming authority

This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the Open Mobile Alliance (OMA). OMA defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the Open Mobile Naming Authority (OMNA). This memo provides information for the Internet community.

 draft-smith-oma-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4358 RFC4359 The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) B. Weis January 2006 ASCII HTML 12 ip encapsulating security payload digital signature

This memo describes the use of the RSA digital signature algorithm as an authentication algorithm within the revised IP Encapsulating Security Payload (ESP) as described in RFC 4303 and the revised IP Authentication Header (AH) as described in RFC 4302. The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) does not provide this property. One example is the use of ESP and AH to authenticate the sender of an IP multicast packet. [STANDARDS-TRACK]

 draft-ietf-msec-ipsec-signatures-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4359 RFC4360 BGP Extended Communities Attribute S. Sangli D. Tappan Y. Rekhter February 2006 ASCII HTML 12

This document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. [STANDARDS-TRACK]

 draft-ietf-idr-bgp-ext-communities-09 RFC7153 RFC7606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4360 10.17487/RFC4360 RFC4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) T. Lemon B. Sommerfeld February 2006 ASCII HTML 12 dhcpv6

This document specifies the format that is to be used for encoding Dynamic Host Configuration Protocol Version Four (DHCPv4) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol. This document also addresses and corrects some problems in RFC 2131 and RFC 2132 with respect to the handling of DHCP client identifiers. [STANDARDS-TRACK]

 draft-ietf-dhc-3315id-for-v4-05 RFC2131 RFC2132 RFC3315 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4361 10.17487/RFC4361 RFC4362 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP L-E. Jonsson G. Pelletier K. Sandlund January 2006 ASCII HTML 23 internet protocol user datagram protocol real-time transport protocol

This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression related to the usage of the header-free packet format. This document is a replacement for RFC 3242, which it obsoletes. [STANDARDS-TRACK]

 draft-ietf-rohc-rfc3242bis-01 RFC3242 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4362 RFC4363 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions D. Levi D. Harrington January 2006 ASCII HTML 99 mib management information base mac bridges traffic classes enhanced multicast filtering p-bridge-mib q-bridge-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines two MIB modules for managing the capabilities of MAC bridges defined by the IEEE 802.1D-1998 (TM) MAC Bridges and the IEEE 802.1Q-2003 (TM) Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998 and P802.1t-2001 (TM). The other MIB module defines objects for managing VLANs, as specified in IEEE 802.1Q-2003, P802.1u (TM), and P802.1v (TM).

Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.

This memo supplements RFC 4188 and obsoletes RFC 2674. [STANDARDS-TRACK]

 draft-ietf-bridge-ext-v2-07 RFC2674 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge http://www.rfc-editor.org/errata_search.php?rfc=4363 10.17487/RFC4363 RFC4364 BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen Y. Rekhter February 2006 ASCII HTML 47 service provider ip backbone ce router pe router border gateway protocol multiprotocol label switching architecture virtual private networks

This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]

 draft-ietf-l3vpn-rfc2547bis-03 RFC2547 RFC4577 RFC4684 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4364 10.17487/RFC4364 RFC4365 Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen February 2006 ASCII HTML 32

This document provides an Applicability Statement for the Virtual Private Network (VPN) solution described in RFC 4364 and other documents listed in the References section. This memo provides information for the Internet community.

 draft-ietf-l3vpn-as2547-07 INFORMATIONAL INFORMATIONAL IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4365 10.17487/RFC4365 RFC4366 Transport Layer Security (TLS) Extensions S. Blake-Wilson M. Nystrom D. Hopwood J. Mikkelsen T. Wright April 2006 ASCII HTML 30 transport protocol layer authentication privacy

This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.

The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]

 draft-ietf-tls-rfc3546bis-02 RFC3546 RFC5246 RFC6066 RFC4346 RFC5746 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=4366 10.17487/RFC4366 RFC4367 What's in a Name: False Assumptions about DNS Names J. Rosenberg Editor IAB February 2006 ASCII HTML 17 domain name system

The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, Uniform Resource Identifiers (URIs), and other application-layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. There is a danger in this trend; the humans and automata that consume and use such names will associate specific semantics with some names and thereby make assumptions about the services that are, or should be, provided by the hosts associated with the names. Those assumptions can often be false, resulting in a variety of failure conditions. This document discusses this problem in more detail and makes recommendations on how it can be avoided. This memo provides information for the Internet community.

 draft-iab-dns-assumptions-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4367 10.17487/RFC4367 RFC4368 Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition T. Nadeau S. Hegde January 2006 ASCII HTML 22 management information base mpls-lc-atm-std-mib mpls-lc-fr-std-mib

This memo defines two MIB modules and corresponding MIB Object Definitions that describe how label-switching-controlled Frame-Relay and Asynchronous Transfer Mode (ATM) interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB. [STANDARDS-TRACK]

 draft-ietf-mpls-lc-if-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4368 10.17487/RFC4368 RFC4369 Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP) K. Gibbons C. Monia J. Tseng F. Travostino January 2006 ASCII HTML 29 mib management information base snmp simple network management protocol ifcp gateway ifcp-mgmt-mib

The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP. [STANDARDS-TRACK]

 draft-ietf-ips-ifcp-mib-07 RFC6173 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4369 RFC4370 Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control R. Weltman February 2006 ASCII HTML 5 proxy authorization control

This document defines the Lightweight Directory Access Protocol (LDAP) Proxy Authorization Control. The Proxy Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of under the current authorization identity associated with the connection. [STANDARDS-TRACK]

 draft-weltman-ldapv3-proxy-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4370 RFC4371 BCP 101 Update for IPR Trust B. Carpenter Editor L. Lynch Editor January 2006 ASCII HTML 4

This document updates BCP 101 to take account of the new IETF Intellectual Property Trust. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-carpenter-bcp101-update-03 RFC8714 RFC4071 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4371 RFC4372 Chargeable User Identity F. Adrangi A. Lior J. Korhonen J. Loughney January 2006 ASCII HTML 10 radius remote authentication dial-in user service roaming transaction home network

This document describes a new Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identity. This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network. [STANDARDS-TRACK]

 draft-ietf-radext-chargeable-user-id-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC4372 RFC4373 Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) R. Harrison J. Sermersheim Y. Dong January 2006 ASCII HTML 16

The Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) allows an LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set of update operations within a pair of LDAP extended operations to notify the server that the update operations in the framed set are related in such a way that the ordering of all operations can be preserved during processing even when they are sent asynchronously by the client. Update operations can be grouped within a single protocol message to maximize the efficiency of client-server communication.

The protocol is suitable for efficiently making a substantial set of updates to the entries in an LDAP server. This memo provides information for the Internet community.

 draft-rharrison-lburp-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4373 RFC4374 The application/xv+xml Media Type G. McCobb January 2006 ASCII HTML 6 mime sub-type media descriptor xhtml+voice

This document describes the registration of the MIME sub-type application/xv+xml. This sub-type is intended for use as a media descriptor for XHTML+Voice multimodal language documents. This memo provides information for the Internet community.

 draft-mccobb-xv-media-type-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4374 RFC4375 Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain K. Carlberg January 2006 ASCII HTML 8 resource transit domain stub domain

This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. This memo provides information for the Internet community.

 draft-ietf-ieprep-domain-req-05 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC4375 RFC4376 Requirements for Floor Control Protocols P. Koskelainen J. Ott H. Schulzrinne X. Wu February 2006 ASCII HTML 14 shared resources multiparty conferences

Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework. This memo provides information for the Internet community.

 draft-ietf-xcon-floor-control-req-03 INFORMATIONAL INFORMATIONAL IETF rai xcon 10.17487/RFC4376 RFC4377 Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks T. Nadeau M. Morrow G. Swallow D. Allan S. Matsushima February 2006 ASCII HTML 15

This document specifies Operations and Management (OAM) requirements for Multi-Protocol Label Switching (MPLS), as well as for applications of MPLS, such as pseudo-wire voice and virtual private network services. These requirements have been gathered from network operators who have extensive experience deploying MPLS networks. This memo provides information for the Internet community.

 draft-ietf-mpls-oam-requirements-07 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4377 10.17487/RFC4377 RFC4378 A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM) D. Allan Editor T. Nadeau Editor February 2006 ASCII HTML 11 data plane fcaps

This document is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-Protocol Label Switching (MPLS). The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. This memo provides information for the Internet community.

 draft-ietf-mpls-oam-frmwk-05 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4378 RFC4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures K. Kompella G. Swallow February 2006 ASCII HTML 50 data plane

This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. [STANDARDS-TRACK]

 draft-ietf-mpls-lsp-ping-13 RFC8029 RFC1122 RFC5462 RFC6424 RFC6425 RFC6426 RFC6829 RFC7506 RFC7537 RFC7743 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4379 10.17487/RFC4379 RFC4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) C. Huitema February 2006 ASCII HTML 53

We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4". [STANDARDS-TRACK]

 draft-huitema-v6ops-teredo-05 RFC5991 RFC6081 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4380 10.17487/RFC4380 RFC4381 Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs) M. Behringer February 2006 ASCII HTML 22 service provider atm asynchronous transfer mode frame relay

This document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users.

The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode (ATM) or Frame Relay. This memo provides information for the Internet community.

 draft-behringer-mpls-security-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4381 RFC4382 MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base T. Nadeau Editor H. van der Linde Editor February 2006 ASCII HTML 44 mib management information base multiprotocol label switching label switching router lsr mpls-l3vpn-std-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multiprotocol Label Switching Layer-3 Virtual Private Networks on a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) supporting this feature. [STANDARDS-TRACK]

 draft-ietf-l3vpn-mpls-vpn-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4382 10.17487/RFC4382 RFC4383 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP) M. Baugher E. Carrara February 2006 ASCII HTML 19 multicast data stream broadcast data stream

This memo describes the use of the Timed Efficient Stream Loss-tolerant Authentication (RFC 4082) transform within the Secure Real-time Transport Protocol (SRTP), to provide data origin authentication for multicast and broadcast data streams. [STANDARDS-TRACK]

 draft-ietf-msec-srtp-tesla-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4383 RFC4384 BGP Communities for Data Collection D. Meyer February 2006 ASCII HTML 12 border gateway protocol

BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes. Such tagging is typically used to control the scope of redistribution of routes within a provider's network and to its peers and customers. With the advent of large-scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system. This memo defines standard (outbound) communities and their encodings for export to BGP route collectors. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-grow-collection-communities-06 BCP0114 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=4384 10.17487/RFC4384 RFC4385 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN S. Bryant G. Swallow L. Martini D. McPherson February 2006 ASCII HTML 12 multiprotocol label switching packet switched network pseudowire associated channel header

This document describes the preferred design of a Pseudowire Emulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated Channel Header. The design of these fields is chosen so that an MPLS Label Switching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload. [STANDARDS-TRACK]

 draft-ietf-pwe3-cw-06 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4385 10.17487/RFC4385 RFC4386 Internet X.509 Public Key Infrastructure Repository Locator Service S. Boeyen P. Hallam-Baker February 2006 ASCII HTML 6 pki public key infrastructure dns srv

This document defines a Public Key Infrastructure (PKI) repository locator service. The service makes use of DNS SRV records defined in accordance with RFC 2782. The service enables certificate-using systems to locate PKI repositories.This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-pkix-pkixrep-04 RFC8553 EXPERIMENTAL EXPERIMENTAL IETF sec pkix 10.17487/RFC4386 RFC4387 Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP P. Gutmann Editor February 2006 ASCII HTML 25 pki hypertext transfer protocol

The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. [STANDARDS-TRACK]

 draft-ietf-pkix-certstore-http-09 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4387 RFC4388 Dynamic Host Configuration Protocol (DHCP) Leasequery R. Woundy K. Kinnear February 2006 ASCII HTML 27 dhcpv4 ip address

A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of IP addresses that it has provided to DHCPv4 clients. Other processes and devices that already make use of DHCPv4 may need to access this information. The leasequery protocol provides these processes and devices a lightweight way to access IP address information. [STANDARDS-TRACK]

 draft-ietf-dhc-leasequery-09 RFC6148 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4388 10.17487/RFC4388 RFC4389 Neighbor Discovery Proxies (ND Proxy) D. Thaler M. Talwar C. Patel April 2006 ASCII HTML 18 ndproxy

Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ipv6-ndproxy-04 EXPERIMENTAL EXPERIMENTAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4389 10.17487/RFC4389 RFC4390 Dynamic Host Configuration Protocol (DHCP) over InfiniBand V. Kashyap April 2006 ASCII HTML 6 bootstrap boot ipoib

IP over Infiniband (IPoIB) link-layer address is 20 octets long. This is larger than the 16 octets reserved for the hardware address in a Dynamic Host Configuration Protocol/Bootstrap Protocol (DHCP/BOOTP) message. The above inequality imposes restrictions on the use of the DHCP message fields when used over an IPoIB network. This document describes the use of DHCP message fields when implementing DHCP over IPoIB. [STANDARDS-TRACK]

 draft-ietf-ipoib-dhcp-over-infiniband-10 PROPOSED STANDARD PROPOSED STANDARD IETF int ipoib 10.17487/RFC4390 RFC4391 Transmission of IP over InfiniBand (IPoIB) J. Chu V. Kashyap April 2006 ASCII HTML 21 address resolution protocol arp ib

This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB). It describes the link-layer address to be used when resolving the IP addresses in IP over InfiniBand (IPoIB) subnets. The document also describes the mapping from IP multicast addresses to InfiniBand multicast addresses. In addition, this document defines the setup and configuration of IPoIB links. [STANDARDS-TRACK]

 draft-ietf-ipoib-ip-over-infiniband-09 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ipoib 10.17487/RFC4391 RFC4392 IP over InfiniBand (IPoIB) Architecture V. Kashyap April 2006 ASCII HTML 23 ib ipv4 ipv6

InfiniBand is a high-speed, channel-based interconnect between systems and devices.

This document presents an overview of the InfiniBand architecture. It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents. This memo provides information for the Internet community.

 draft-ietf-ipoib-architecture-04 INFORMATIONAL INFORMATIONAL IETF int ipoib 10.17487/RFC4392 RFC4393 MIME Type Registrations for 3GPP2 Multimedia Files H. Garudadri March 2006 ASCII HTML 7 third-generation partnership project 2

This document serves to register and document the standard MIME types associated with the 3GPP2 multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]

 draft-garudadri-avt-3gpp2-mime-02 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4393 RFC4394 A Transport Network View of the Link Management Protocol (LMP) D. Fedyk O. Aboul-Magd D. Brungard J. Lang D. Papadimitriou February 2006 ASCII HTML 18 gmpls ason discovery sdh otn sonet pdh

The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. This memo provides information for the Internet community.

 draft-ietf-ccamp-transport-lmp-02 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4394 RFC4395 Guidelines and Registration Procedures for New URI Schemes T. Hansen T. Hardie L. Masinter February 2006 ASCII HTML 15 uniform resource identifier syntax semantics

This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-hansen-2717bis-2718bis-uri-guidelines-06 RFC2717 RFC2718 RFC7595 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4395 10.17487/RFC4395 RFC4396 RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text J. Rey Y. Matsui February 2006 ASCII HTML 66 3GPP 3GPP timed text streaming real-time streaming titling decorated text scrolling text karaoke hyperlinked text highlighted text blinking text highlight color text delay text style text box text wrap text sample sample descriptions modifier boxes UTF-8 UTF-16

This document specifies an RTP payload format for the transmission of 3GPP (3rd Generation Partnership Project) timed text. 3GPP timed text is a time-lined, decorated text media format with defined storage in a 3GP file. Timed Text can be synchronized with audio/video contents and used in applications such as captioning, titling, and multimedia presentations. In the following sections, the problems of streaming timed text are addressed, and a payload format for streaming 3GPP timed text over RTP is specified. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-3gpp-timed-text-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4396 10.17487/RFC4396 RFC4397 A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture I. Bryskin A. Farrel February 2006 ASCII HTML 19

Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON).

This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture.

It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-ason-lexicography-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4397 10.17487/RFC4397 RFC4398 Storing Certificates in the Domain Name System (DNS) S. Josefsson March 2006 ASCII HTML 17 SC-DNS cryptology authenticity

Cryptographic public keys are frequently published, and their authenticity is demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [STANDARDS-TRACK]

 draft-ietf-dnsext-rfc2538bis-09 RFC2538 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4398 10.17487/RFC4398 RFC4399 RFC4400 RFC4401 A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API) N. Williams February 2006 ASCII HTML 8 secure session layer message integrity check mic

This document defines a Pseudo-Random Function (PRF) extension to the Generic Security Service Application Program Interface (GSS-API) for keying application protocols given an established GSS-API security context. The primary intended use of this function is to key secure session layers that do not or cannot use GSS-API per-message message integrity check (MIC) and wrap tokens for session protection. [STANDARDS-TRACK]

 draft-ietf-kitten-gssapi-prf-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC4401 RFC4402 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism N. Williams February 2006 ASCII HTML 5

This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. [STANDARDS-TRACK]

 draft-ietf-kitten-krb5-gssapi-prf-04 RFC7802 HISTORIC PROPOSED STANDARD IETF sec kitten http://www.rfc-editor.org/errata_search.php?rfc=4402 10.17487/RFC4402 RFC4403 Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3) B. Bergeson K. Boogert V. Nanjundaswamy February 2006 ASCII HTML 42 LDAPv3

This document defines the Lightweight Directory Access Protocol (LDAPv3) schema for representing Universal Description, Discovery, and Integration (UDDI) data types in an LDAP directory. It defines the LDAP object class and attribute definitions and containment rules to model UDDI entities, defined in the UDDI version 3 information model, in an LDAPv3-compliant directory. This memo provides information for the Internet community.

 draft-bergeson-uddi-ldap-schema-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4403 RFC4404 Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP) R. Natarajan A. Rijhsinghani February 2006 ASCII HTML 33 mib management information base fcip-mgmt-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Fibre Channel Over TCP/IP (FCIP) entities, which are used to interconnect Fibre Channel (FC) fabrics with IP networks. [STANDARDS-TRACK]

 draft-ietf-ips-fcip-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4404 10.17487/RFC4404 RFC4405 SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message E. Allman H. Katz April 2006 ASCII HTML 14 spam spoofing phishing

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service that allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain. This memo defines an Experimental Protocol for the Internet community.

 draft-katz-submitter-01 HISTORIC EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4405 RFC4406 Sender ID: Authenticating E-Mail J. Lyon M. Wong April 2006 ASCII HTML 19 simple mail transfer protocol spam spoofing

Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address. This memo defines an Experimental Protocol for the Internet community.

 draft-lyon-senderid-core-01 HISTORIC EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4406 RFC4407 Purported Responsible Address in E-Mail Messages J. Lyon April 2006 ASCII HTML 7 pra purported responsible address

This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the Purported Responsible Address (PRA).This memo defines an Experimental Protocol for the Internet community.

 draft-lyon-senderid-pra-01 HISTORIC EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4407 10.17487/RFC4407 RFC4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 M. Wong W. Schlitt April 2006 ASCII HTML 48 spoofing spf

E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the ender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization. This memo defines an Experimental Protocol for the Internet community.

 draft-schlitt-spf-classic-02 RFC7208 RFC6652 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4408 10.17487/RFC4408 RFC4409 Message Submission for Mail R. Gellens J. Klensin April 2006 ASCII HTML 17 smtp simle mail transfer protocol ua user agent

This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.

Message relay and final delivery are unaffected, and continue to use SMTP over port 25.

When conforming to this document, message submission uses the protocol specified here, normally over port 587.

This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]

 draft-gellens-submit-bis-02 RFC2476 RFC6409 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4409 10.17487/RFC4409 RFC4410 Selectively Reliable Multicast Protocol (SRMP) M. Pullen F. Zhao D. Cohen February 2006 ASCII HTML 30 transport best-effort srt selectively reliable transport

The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best-effort traffic occurs in significantly greater volume than the reliable traffic and therefore can carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. SRMP has two sublayers: a bundling sublayer handling message aggregation and congestion control, and a Selectively Reliable Transport (SRT) sublayer. Selection between reliable and best-effort messages is performed by the application. This memo defines an Experimental Protocol for the Internet community.

 draft-pullen-srmp-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4410 10.17487/RFC4410 RFC4411 Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events J. Polk February 2006 ASCII HTML 22 Resource-Priority preempt preempted Q.850 preconditions

This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. [STANDARDS-TRACK]

 draft-ietf-sipping-reason-header-for-preemption-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC4411 RFC4412 Communications Resource Priority for the Session Initiation Protocol (SIP) H. Schulzrinne J. Polk February 2006 ASCII HTML 36 RP RPH preferential preempt preempted preemption queue DSN DRSN WPS ETS Q.735 Q735 disaster I.255 flash flash-override

This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. [STANDARDS-TRACK]

 draft-ietf-sip-resource-priority-10 RFC7134 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4412 RFC4413 TCP/IP Field Behavior M. West S. McCann March 2006 ASCII HTML 44 transmission control protocol header compression

This memo describes TCP/IP field behavior in the context of header compression. Header compression is possible because most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When a header compression scheme is designed, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095. This memo performs a similar role for the compression of TCP/IP headers. This memo provides information for the Internet community.

 draft-ietf-rohc-tcp-field-behavior-04 INFORMATIONAL INFORMATIONAL IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=4413 10.17487/RFC4413 RFC4414 An ENUM Registry Type for the Internet Registry Information Service (IRIS) A. Newton February 2006 ASCII HTML 51

This document describes an Internet Registry Information Service (IRIS) registry schema for registered ENUM information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries. [STANDARDS-TRACK]

 draft-ietf-enum-iris-ereg-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4414 RFC4415 IANA Registration for Enumservice Voice R. Brandner L. Conroy R. Stastny February 2006 ASCII HTML 8 uniform resource identifier uri voice call audio call

This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in the ENUM specification RFC 3761. This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call. [STANDARDS-TRACK]

 draft-ietf-enum-voice-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4415 RFC4416 Goals for Internet Messaging to Support Diverse Service Environments J. Wong Editor February 2006 ASCII HTML 43 IMAP protocol extensions messaging wireless handheld telephone user interface multi-modal LEMONADE extension principles history background motivation cellular interworking constraints TUI WUI client MMS

This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process.

The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements to Internet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail.

The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments -- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols.

The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed. This memo provides information for the Internet community.

 draft-ietf-lemonade-goals-05 INFORMATIONAL INFORMATIONAL IETF app lemonade 10.17487/RFC4416 RFC4417 Report of the 2004 IAB Messaging Workshop P. Resnick Editor P. Saint-Andre Editor February 2006 ASCII HTML 20 internet architecture board internet messaging

This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on the future of Internet messaging. The workshop was held on 6 and 7 October 2004 in Burlingame, CA, USA. The goal of the workshop was to examine the current state of different messaging technologies on the Internet (including, but not limited to, electronic mail, instant messaging, and voice messaging), to look at their commonalities and differences, and to find engineering, research, and architectural topics on which future work could be done. This report summarizes the discussions and conclusions of the workshop and of the IAB. This memo provides information for the Internet community.

 draft-iab-messaging-report-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4417 RFC4418 UMAC: Message Authentication Code using Universal Hashing T. Krovetz Editor March 2006 ASCII HTML 27

This specification describes how to generate an authentication tag using the UMAC message authentication algorithm. UMAC is designed to be very fast to compute in software on contemporary uniprocessors. Measured speeds are as low as one cycle per byte. UMAC relies on addition of 32-bit and 64-bit numbers and multiplication of 32-bit numbers, operations well-supported by contemporary machines.

To generate the authentication tag on a given message, a "universal" hash function is applied to the message and key to produce a short, fixed-length hash value, and this hash value is then xor'ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis, and its only internal "cryptographic" component is a block cipher used to generate the pseudorandom pads and internal key material. This memo provides information for the Internet community.

 draft-krovetz-umac-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4418 10.17487/RFC4418 RFC4419 Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol M. Friedl N. Provos W. Simpson March 2006 ASCII HTML 10

This memo describes a new key exchange method for the Secure Shell (SSH) protocol. It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client. The proposed groups need not be fixed and can change with time. [STANDARDS-TRACK]

 draft-ietf-secsh-dh-group-exchange-05 RFC8270 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4419 10.17487/RFC4419 RFC4420 Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) A. Farrel Editor D. Papadimitriou J.-P. Vasseur A. Ayyangar February 2006 ASCII HTML 21 SESSION_ATTRIBUTE

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.

This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.

The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. [STANDARDS-TRACK]

 draft-ietf-mpls-rsvpte-attributes-05 RFC5420 RFC3209 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4420 RFC4421 RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes C. Perkins February 2006 ASCII HTML 4 realtime transport protocol video stream

The RFC Payload Format for Uncompressed Video, RFC 4175, defines a scheme to packetise uncompressed, studio-quality, video streams for transport using RTP. This memo extends the format to support additional colour sampling modes. [STANDARDS-TRACK]

 draft-ietf-avt-uncomp-video-ext-01 RFC4175 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4421 RFC4422 Simple Authentication and Security Layer (SASL) A. Melnikov Editor K. Zeilenga Editor June 2006 ASCII HTML 33 SASL encryption protocol specific

The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.

This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.

This document obsoletes RFC 2222. [STANDARDS-TRACK]

 draft-ietf-sasl-rfc2222bis-15 RFC2222 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl 10.17487/RFC4422 RFC4423 Host Identity Protocol (HIP) Architecture R. Moskowitz P. Nikander May 2006 ASCII HTML 24

This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol (HIP), between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since. This document represents one stable point in that evolution of understanding. This memo provides information for the Internet community.

 draft-ietf-hip-arch-03 RFC9063 INFORMATIONAL INFORMATIONAL IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=4423 10.17487/RFC4423 RFC4424 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec S. Ahmadi February 2006 ASCII HTML 8 speech codec variable-rate multicode wideband speech codec

This document is an addendum to RFC 4348, which specifies the RTP payload format for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. This document specifies some updates in RFC 4348 to enable support for the new operating mode of VMR-WB standard (i.e., VMR-WB mode 4). These updates do not affect the existing modes of VMR-WB already specified in RFC 4348.

The payload formats and their associated parameters, as well as all provisions, restrictions, use cases, features, etc., that are specified in RFC 4348 are applicable to the new operating mode with no exception. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-vmr-wb-extension-02 RFC4348 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4424 RFC4425 RTP Payload Format for Video Codec 1 (VC-1) A. Klemets February 2006 ASCII HTML 36 smpte 421m wmv wmv9 vc-9

This memo specifies an RTP payload format for encapsulating Video Codec 1 (VC-1) compressed bit streams, as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M. SMPTE is the main standardizing body in the motion imaging industry, and the SMPTE 421M standard defines a compressed video bit stream format and decoding process for television. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-vc1-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4425 10.17487/RFC4425 RFC4426 Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification J. Lang Editor B. Rajagopalan Editor D. Papadimitriou Editor March 2006 ASCII HTML 23

This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-recovery-functional-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4426 RFC4427 Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) E. Mannie Editor D. Papadimitriou Editor March 2006 ASCII HTML 22

This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-recovery-terminology-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4427 10.17487/RFC4427 RFC4428 Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) D. Papadimitriou Editor E. Mannie Editor March 2006 ASCII HTML 47

This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-recovery-analysis-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4428 10.17487/RFC4428 RFC4429 Optimistic Duplicate Address Detection (DAD) for IPv6 N. Moore April 2006 ASCII HTML 17 internet protocol version 6 stateless address autoconfiguration neighbor discovery

Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers. [STANDARDS-TRACK]

 draft-ietf-ipv6-optimistic-dad-07 RFC7527 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4429 10.17487/RFC4429 RFC4430 Kerberized Internet Negotiation of Keys (KINK) S. Sakane K. Kamada M. Thomas J. Vilhuber March 2006 ASCII HTML 40 ike internet key exchange

This document describes the Kerberized Internet Negotiation of Keys (KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations. [STANDARDS-TRACK]

 draft-ietf-kink-kink-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec kink http://www.rfc-editor.org/errata_search.php?rfc=4430 10.17487/RFC4430 RFC4431 The DNSSEC Lookaside Validation (DLV) DNS Resource Record M. Andrews S. Weiler February 2006 ASCII HTML 4 dns domain name space

This document defines a new DNS resource record, called the DNSSEC Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors outside of the DNS delegation chain. This memo provides information for the Internet community.

 draft-andrews-dlv-dns-rr-01 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4431 RFC4432 RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol B. Harris March 2006 ASCII HTML 8 rivest-sharmir-adleman public key encryption

This memo describes a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption. It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems. [STANDARDS-TRACK]

 draft-harris-ssh-rsa-kex-06 RFC9142 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4432 RFC4433 Mobile IPv4 Dynamic Home Agent (HA) Assignment M. Kulkarni A. Patel K. Leung March 2006 ASCII HTML 25 internet protocol messaging

Mobile IPv4 (RFC 3344) uses the home agent (HA) to anchor sessions of a roaming mobile node (MN). This document proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection. [STANDARDS-TRACK]

 draft-ietf-mip4-dynamic-assignment-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4433 10.17487/RFC4433 RFC4434 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) P. Hoffman February 2006 ASCII HTML 6 security ipsec advanced encryption standard mac message authentication code

Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128. [STANDARDS-TRACK]

 draft-hoffman-rfc3664bis-05 RFC3664 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4434 RFC4435 A Framework for the Usage of Internet Media Guides (IMGs) Y. Nomura R. Walsh J-P. Luoma H. Asaeda H. Schulzrinne April 2006 ASCII HTML 22 session description protocol sdp sdpng

This document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol (SDP), SDPng, or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure. This memo provides information for the Internet community.

 draft-ietf-mmusic-img-framework-09 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC4435 RFC4436 Detecting Network Attachment in IPv4 (DNAv4) B. Aboba J. Carlson S. Cheshire March 2006 ASCII HTML 15 internet protocol

The time required to detect movement between networks and to obtain (or to continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document synthesizes, from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses, a set of steps known as Detecting Network Attachment for IPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment. [STANDARDS-TRACK]

 draft-ietf-dhc-dna-ipv4-18 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4436 10.17487/RFC4436 RFC4437 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources J. Whitehead G. Clemm J. Reschke Editor March 2006 ASCII HTML 25 http hyper text transfer protocol

This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-webdav-redirectref-protocol-13 EXPERIMENTAL EXPERIMENTAL IETF app webdav 10.17487/RFC4437 RFC4438 Fibre-Channel Name Server MIB C. DeSanti V. Gaonkar H.K. Vivek K. McCloghrie S. Gai April 2006 ASCII HTML 36 management information base T11-fc-name-server-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Name Server function of a Fibre Channel network. The Fibre Channel Name Server provides a means for Fibre Channel ports to register and discover Fibre Channel names and attributes. [STANDARDS-TRACK]

 draft-ietf-imss-fc-nsm-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4438 10.17487/RFC4438 RFC4439 Fibre Channel Fabric Address Manager MIB C. DeSanti V. Gaonkar K. McCloghrie S. Gai March 2006 ASCII HTML 40 management information base t11-tc-mib t11-fc-fabric-addr-mgr-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel network's Fabric Address Manager. [STANDARDS-TRACK]

 draft-ietf-imss-fc-fam-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4439 10.17487/RFC4439 RFC4440 IAB Thoughts on the Role of the Internet Research Task Force (IRTF) S. Floyd Editor V. Paxson Editor A. Falk Editor IAB March 2006 ASCII HTML 13 internet architecture board

This document is an Internet Architecture Board (IAB) report on the role of the Internet Research Task Force (IRTF), both on its own and in relationship to the IETF. This document evolved from a discussion within the IAB as part of a process of appointing a new chair of the IRTF. This memo provides information for the Internet community.

 draft-iab-irtf-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4440 RFC4441 The IEEE 802/IETF Relationship B. Aboba Editor March 2006 ASCII HTML 22 snmp aaa simple network management protocol authentication authorization accounting

Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs and Authentication, Authorization, and Accounting (AAA) applications. This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history. This memo provides information for the Internet community.

 draft-iab-ieee-802-rel-05 RFC7241 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4441 RFC4442 Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA) S. Fries H. Tschofenig March 2006 ASCII HTML 18 authentication mikey multimedia internet keying protocol

TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol, provides source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead that scales to large numbers of receivers and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized in TESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published, targeting multicast authentication in scenarios where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms.

This document specifies payloads for the Multimedia Internet Keying (MIKEY) protocol for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast, or broadcast. [STANDARDS-TRACK]

 draft-ietf-msec-bootstrapping-tesla-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4442 RFC4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification A. Conta S. Deering M. Gupta Editor March 2006 ASCII HTML 24

This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]

 draft-ietf-ipngwg-icmp-v3-07 RFC2463 RFC2780 RFC4884 STD0089 INTERNET STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4443 10.17487/RFC4443 RFC4444 Management Information Base for Intermediate System to Intermediate System (IS-IS) J. Parker Editor April 2006 ASCII HTML 103 mib routing protocol isis-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this document describes a MIB for the Intermediate System to Intermediate System (IS-IS) Routing protocol when it is used to construct routing tables for IP networks. [STANDARDS-TRACK]

 draft-ietf-isis-wg-mib-26 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=4444 10.17487/RFC4444 RFC4445 A Proposed Media Delivery Index (MDI) J. Welch J. Clark April 2006 ASCII HTML 10

This memo defines a Media Delivery Index (MDI) measurement that can be used as a diagnostic tool or a quality indicator for monitoring a network intended to deliver applications such as streaming media, MPEG video, Voice over IP, or other information sensitive to arrival time and packet loss. It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and a data loss at-a-glance measure for a particular flow. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media. This memo provides information for the Internet community.

 draft-welch-mdi-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4445 RFC4446 IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) L. Martini April 2006 ASCII HTML 9

This document allocates the fixed pseudowire identifier and other fixed protocol values for protocols that have been defined in the Pseudo Wire Edge to Edge (PWE3) working group. Detailed IANA allocation instructions are also included in this document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-pwe3-iana-allocation-15 BCP0116 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4446 10.17487/RFC4446 RFC4447 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) L. Martini Editor E. Rosen N. El-Aawar T. Smith G. Heron April 2006 ASCII HTML 33 mpls multiprotocol label switching protocol pdu protocol data units

Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and a Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. [STANDARDS-TRACK]

 draft-ietf-pwe3-control-protocol-17 RFC8077 RFC6723 RFC6870 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4447 10.17487/RFC4447 RFC4448 Encapsulation Methods for Transport of Ethernet over MPLS Networks L. Martini Editor E. Rosen N. El-Aawar G. Heron April 2006 ASCII HTML 24 pw pseudowire pdu protocol data units

An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. [STANDARDS-TRACK]

 draft-ietf-pwe3-ethernet-encap-11 RFC5462 RFC8469 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4448 10.17487/RFC4448 RFC4449 Securing Mobile IPv6 Route Optimization Using a Static Shared Key C. Perkins June 2006 ASCII HTML 7 mobile node correspondent node binding management key binding updates

A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. [STANDARDS-TRACK]

 draft-ietf-mip6-precfgkbm-04 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4449 10.17487/RFC4449 RFC4450 Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents E. Lear H. Alvestrand March 2006 ASCII HTML 11

This memo documents an experiment to review and classify Proposed Standards as not reflecting documented practice within the world today. The results identify a set of documents that were marked as Proposed Standards that are now reclassified as Historic. This memo provides information for the Internet community.

 draft-ietf-newtrk-decruft-experiment-03 INFORMATIONAL INFORMATIONAL IETF gen newtrk http://www.rfc-editor.org/errata_search.php?rfc=4450 10.17487/RFC4450 RFC4451 BGP MULTI_EXIT_DISC (MED) Considerations D. McPherson V. Gill March 2006 ASCII HTML 13 border gateway protocol

The BGP MULTI_EXIT_DISC (MED) attribute provides a mechanism for BGP speakers to convey to an adjacent AS the optimal entry point into the local AS. While BGP MEDs function correctly in many scenarios, a number of issues may arise when utilizing MEDs in dynamic or complex topologies.

This document discusses implementation and deployment considerations regarding BGP MEDs and provides information with which implementers and network operators should be familiar. This memo provides information for the Internet community.

 draft-ietf-grow-bgp-med-considerations-05 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC4451 RFC4452 The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces H. Van de Sompel T. Hammond E. Neylon S. Weibel April 2006 ASCII HTML 17 uniform resource identifier

This document defines the "info" Uniform Resource Identifier (URI) scheme for information assets with identifiers in public namespaces. Namespaces participating in the "info" URI scheme are regulated by an "info" Registry mechanism. This memo provides information for the Internet community.

 draft-vandesompel-info-uri-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4452 10.17487/RFC4452 RFC4453 Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP) J. Rosenberg G. Camarillo Editor D. Willis April 2006 ASCII HTML 8 sip extensions

The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks. This document identifies a set of requirements for extensions to SIP that add consent-based communications. This memo provides information for the Internet community.

 draft-ietf-sipping-consent-reqs-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4453 RFC4454 Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3) S. Singh M. Townsley C. Pignataro May 2006 ASCII HTML 26 extensible tunneling protocol

The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines an extensible tunneling protocol to transport layer 2 services over IP networks. This document describes the specifics of how to use the L2TP control plane for Asynchronous Transfer Mode (ATM) Pseudowires and provides guidelines for transporting various ATM services over an IP network. [STANDARDS-TRACK]

 draft-ietf-l2tpext-pwe3-atm-04 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4454 RFC4455 Definition of Managed Objects for Small Computer System Interface (SCSI) Entities M. Hallak-Stamler M. Bakke Y. Lederman M. Krueger K. McCloghrie April 2006 ASCII HTML 88 mib management information base scsi-mib

This memo defines a portion of the Management Information Base (MIB), for use with network management protocols in the Internet community. In particular, it describes managed objects for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. [STANDARDS-TRACK]

 draft-ietf-ips-scsi-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4455 10.17487/RFC4455 RFC4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) T. Bates E. Chen R. Chandra April 2006 ASCII HTML 12 BGP-RR Border Gateway Protocol autonomous system

The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed.

This document describes the use and design of a method known as "route reflection" to alleviate the need for "full mesh" Internal BGP (IBGP).

This document obsoletes RFC 2796 and RFC 1966. [STANDARDS-TRACK]

 draft-ietf-idr-rfc2796bis-02 RFC2796 RFC1966 RFC7606 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4456 10.17487/RFC4456 RFC4457 The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header) G. Camarillo G. Blanco April 2006 ASCII HTML 8 3gpp third generation partnership project 3rd generation partnership project ims ip multimedia subsystem

This document specifies the Session Initiation Protocol (SIP) P-User-Database Private-Header (P-header). This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request. This memo provides information for the Internet community.

 draft-camarillo-sipping-user-database-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4457 RFC4458 Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR) C. Jennings F. Audet J. Elwell April 2006 ASCII HTML 21 universal resource identifiers

The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications. This memo provides information for the Internet community.

 draft-jennings-sip-voicemail-uri-06 RFC8119 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4458 10.17487/RFC4458 RFC4459 MTU and Fragmentation Issues with In-the-Network Tunneling P. Savola April 2006 ASCII HTML 14

Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided. This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length. This memo provides information for the Internet community.

 draft-savola-mtufrag-network-tunneling-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4459 RFC4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues R. Stewart I. Arias-Rodriguez K. Poon A. Caro M. Tuexen April 2006 ASCII HTML 109 SCTP IP internet transport packet network

This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using SCTP along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time-based way. The issues are listed in the order they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the delta, a description of the problem and the details of the solution are also provided. This memo provides information for the Internet community.

 draft-ietf-tsvwg-sctpimpguide-16 RFC9260 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC4460 RFC4461 Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) S. Yasukawa Editor April 2006 ASCII HTML 30 p2mp multiprotocol label switching

This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).

There is no intent to specify solution-specific details or application-specific requirements in this document.

The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), Time Division Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. This memo provides information for the Internet community.

 draft-ietf-mpls-p2mp-sig-requirement-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4461 RFC4462 Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol J. Hutzelman J. Salowey J. Galbraith V. Welch May 2006 ASCII HTML 29

The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion.

This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method that uses a specified GSS-API mechanism to authenticate a user, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange.

This memo also defines a new host public key algorithm that can be used when no operations are needed using a host's public key, and a new user authentication method that allows an authorization name to be used in conjunction with any authentication that has already occurred as a side-effect of GSS-API-based key exchange. [STANDARDS-TRACK]

 draft-ietf-secsh-gsskeyex-10 RFC8732 RFC9142 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4462 10.17487/RFC4462 RFC4463 A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks S. Shanmugham P. Monaco B. Eberman April 2006 ASCII HTML 86

This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. It is published as an RFC as input for further IETF development in this area.

MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, etc., over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP (Session Initiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms like RTP (Real Time Protocol). This memo provides information for the Internet community.

 draft-shanmugham-mrcp-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4463 RFC4464 Signaling Compression (SigComp) Users' Guide A. Surtees M. West May 2006 ASCII HTML 43

This document provides an informational guide for users of the Signaling Compression (SigComp) protocol. The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets. This memo provides information for the Internet community.

 draft-ietf-rohc-sigcomp-user-guide-04 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4464 RFC4465 Signaling Compression (SigComp) Torture Tests A. Surtees M. West June 2006 ASCII HTML 68 SigComp Universal Decompressor Virtual Machine

This document provides a set of "torture tests" for implementers of the Signaling Compression (SigComp) protocol. The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms. Tests are also provided for other SigComp entities such as the dispatcher and the state handler. This memo provides information for the Internet community.

 draft-ietf-rohc-sigcomp-torture-tests-03 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4465 RFC4466 Collected Extensions to IMAP4 ABNF A. Melnikov C. Daboo April 2006 ASCII HTML 17

Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place.

This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined in RFC 3501. The patterns provide for compatibility between existing and future extensions.

This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs. [STANDARDS-TRACK]

 draft-melnikov-imap-ext-abnf-08 RFC2088 RFC2342 RFC3501 RFC3502 RFC3516 RFC6237 RFC7377 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4466 RFC4467 Internet Message Access Protocol (IMAP) - URLAUTH Extension M. Crispin May 2006 ASCII HTML 18 imap url imapurl

This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server.

An IMAP server that supports this extension indicates this with a capability name of "URLAUTH". [STANDARDS-TRACK]

 draft-ietf-lemonade-urlauth-08 RFC5092 RFC5550 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC4467 RFC4468 Message Submission BURL Extension C. Newman May 2006 ASCII HTML 14 URLAUTH IMAP IMAPURL Forward-without-download mobile-client lemonade

The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server. [STANDARDS-TRACK]

 draft-ietf-lemonade-burl-04 RFC3463 RFC5248 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4468 10.17487/RFC4468 RFC4469 Internet Message Access Protocol (IMAP) CATENATE Extension P. Resnick April 2006 ASCII HTML 13 append

The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on the IMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server. [STANDARDS-TRACK]

 draft-ietf-lemonade-catenate-05 RFC3501 RFC3502 RFC5550 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4469 10.17487/RFC4469 RFC4470 Minimally Covering NSEC Records and DNSSEC On-line Signing S. Weiler J. Ihren April 2006 ASCII HTML 8 dns security domain name system

This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-online-signing-02 RFC4035 RFC4034 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4470 10.17487/RFC4470 RFC4471 Derivation of DNS Name Predecessor and Successor G. Sisson B. Laurie September 2006 ASCII HTML 23 domain namespace dynamic nsec dnssec

This document describes two methods for deriving the canonically-ordered predecessor and successor of a DNS name. These methods may be used for dynamic NSEC resource record synthesis, enabling security-aware name servers to provide authenticated denial of existence without disclosing other owner names in a DNSSEC secured zone. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-dnsext-dns-name-p-s-01 EXPERIMENTAL EXPERIMENTAL IETF int dnsext 10.17487/RFC4471 RFC4472 Operational Considerations and Issues with IPv6 DNS A. Durand J. Ihren P. Savola April 2006 ASCII HTML 29 domain name system internet protocol version 6

This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS. This memo provides information for the Internet community.

 draft-ietf-dnsop-ipv6-dns-issues-12 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC4472 RFC4473 Requirements for Internet Media Guides (IMGs) Y. Nomura R. Walsh J-P. Luoma J. Ott H. Schulzrinne May 2006 ASCII HTML 23 media-on-deman multicast

This memo specifies requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide choice and development of IMG protocols for efficient and scalable delivery. This memo provides information for the Internet community.

 draft-ietf-mmusic-img-req-08 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC4473 RFC4474 Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) J. Peterson C. Jennings August 2006 ASCII HTML 41 security identity identity-info

The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. [STANDARDS-TRACK]

 draft-ietf-sip-identity-06 RFC8224 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4474 10.17487/RFC4474 RFC4475 Session Initiation Protocol (SIP) Torture Test Messages R. Sparks Editor A. Hawrylyshen A. Johnston J. Rosenberg H. Schulzrinne May 2006 ASCII HTML 53

This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation. This memo provides information for the Internet community.

 draft-ietf-sipping-torture-tests-09 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4475 RFC4476 Attribute Certificate (AC) Policies Extension C. Francis D. Pinkas May 2006 ASCII HTML 11 acp attribute certificate policies

This document describes one certificate extension that explicitly states the Attribute Certificate Policies (ACPs) that apply to a given Attribute Certificate (AC). The goal of this document is to allow relying parties to perform an additional test when validating an AC, i.e., to assess whether a given AC carrying some attributes can be accepted on the basis of references to one or more specific ACPs. [STANDARDS-TRACK]

 draft-ietf-pkix-acpolicies-extn-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4476 RFC4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues T. Chown S. Venaas C. Strauf May 2006 ASCII HTML 14 internet protocol

A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP (RFC 2131) designed for IPv4 has now been complemented by a new DHCPv6 (RFC 3315) for IPv6. This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from both DHCPv4 and DHCPv6 servers. The document makes a recommendation on the general strategy on how best to handle such issues and identifies future work to be undertaken. This memo provides information for the Internet community.

 draft-ietf-dhc-dual-stack-04 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC4477 RFC4478 Repeated Authentication in Internet Key Exchange (IKEv2) Protocol Y. Nir April 2006 ASCII HTML 5 lifetime

This document extends the Internet Key Exchange (IKEv2) Protocol document [IKEv2]. With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer. This document describes a mechanism to perform this function. This memo defines an Experimental Protocol for the Internet community.

 draft-nir-ikev2-auth-lt-05 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4478 RFC4479 A Data Model for Presence J. Rosenberg July 2006 ASCII HTML 35 simple sip session initiation protocol

This document defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. [STANDARDS-TRACK]

 draft-ietf-simple-presence-data-model-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4479 10.17487/RFC4479 RFC4480 RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) H. Schulzrinne V. Gurbani P. Kyzivat J. Rosenberg July 2006 ASCII HTML 37

The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication. The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity.

This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity.

These extensions include presence information for persons, services (tuples), and devices. [STANDARDS-TRACK]

 draft-ietf-simple-rpid-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4480 10.17487/RFC4480 RFC4481 Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals H. Schulzrinne July 2006 ASCII HTML 9

The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. This document extends PIDF, adding a timed status extension (<timed-status> element) that allows a presentity to declare its status for a time interval fully in the future or the past. [STANDARDS-TRACK]

 draft-ietf-simple-future-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC4481 RFC4482 CIPID: Contact Information for the Presence Information Data Format H. Schulzrinne July 2006 ASCII HTML 11 pidf

The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for the Presence Information Data format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. [STANDARDS-TRACK]

 draft-ietf-simple-cipid-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC4482 RFC4483 A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages E. Burger Editor May 2006 ASCII HTML 17 universal resource locator mime external-body access-type

This document defines an extension to the URL MIME External-Body Access-Type to satisfy the content indirection requirements for the Session Initiation Protocol (SIP). These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. [STANDARDS-TRACK]

 draft-ietf-sip-content-indirect-mech-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4483 10.17487/RFC4483 RFC4484 Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP) J. Peterson J. Polk D. Sicker H. Tschofenig August 2006 ASCII HTML 15 policy decision

This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP). While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system. This memo provides information for the Internet community.

 draft-ietf-sipping-trait-authz-02 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4484 RFC4485 Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne May 2006 ASCII HTML 23 interactive communication

The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. This memo provides information for the Internet community.

 draft-ietf-sip-guidelines-09 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC4485 RFC4486 Subcodes for BGP Cease Notification Message E. Chen V. Gillet April 2006 ASCII HTML 6 border gateway protocol bgp peers

This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in correlating network events and diagnosing BGP peering issues. [STANDARDS-TRACK]

 draft-ietf-idr-cease-subcode-07 RFC8203 RFC9003 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC4486 RFC4487 Mobile IPv6 and Firewalls: Problem Statement F. Le S. Faccin B. Patil H. Tschofenig May 2006 ASCII HTML 16 3g mobile networks

This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as General Packet Radio Service / Universal Mobile Telecommunications System (GPRS/UMTS) and CDMA2000 networks.

The goal of this document is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions. This memo provides information for the Internet community.

 draft-ietf-mip6-firewalls-04 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4487 RFC4488 Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription O. Levin May 2006 ASCII HTML 8

The Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by the REFER. These notifications are not needed in all cases. This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request. [STANDARDS-TRACK]

 draft-ietf-sip-refer-with-norefersub-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4488 RFC4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses J-S. Park M-K. Shin H-J. Kim April 2006 ASCII HTML 6 iid interface identifiers

This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows the use of Interface Identifiers (IIDs) to allocate multicast addresses. When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined. After that, each node can generate its unique multicast addresses automatically without conflicts. The alternative method for creating link-local multicast addresses proposed in this document is better than known methods like unicast-prefix-based IPv6 multicast addresses. This memo updates RFC 3306. [STANDARDS-TRACK]

 draft-ietf-ipv6-link-scoped-mcast-09 RFC3306 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4489 RFC4490 Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS) S. Leontiev Editor G. Chudov Editor May 2006 ASCII HTML 29 CPCMS S/MIME PKIX X.509 certificate CRL revocation public-key one-way hash block cipher encryption decryption MAC HMAC PRF wrap unwrap UKM KEK key Diffie-Hellman agreement transport parameter derivation digest CBC counter mode digital signature

This document describes the conventions for using the cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 with the Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication, and encryption of arbitrary message contents. [STANDARDS-TRACK]

 draft-ietf-smime-gost-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4490 10.17487/RFC4490 RFC4491 Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile S. Leontiev Editor D. Shefanovski Editor May 2006 ASCII HTML 20 PKIX X.509 CPPK public-key one-way hash function block cipher encryption decryption key derivation parameter message digest digital signature 34.310 34.311 34.310-95 34.310-2004 34.311-95

This document supplements RFC 3279. It describes encoding formats, identifiers, and parameter formats for the algorithms GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 for use in Internet X.509 Public Key Infrastructure (PKI). [STANDARDS-TRACK]

 draft-ietf-pkix-gost-cppk-05 RFC3279 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4491 10.17487/RFC4491 RFC4492 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) S. Blake-Wilson N. Bolyard V. Gupta C. Hawk B. Moeller May 2006 ASCII HTML 35 ecdh elliptic curve diffie-hellman elliptic curve digital signature algorithm ecdsa

This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. This memo provides information for the Internet community.

 draft-ietf-tls-ecc-12 RFC8422 RFC5246 RFC7027 RFC7919 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=4492 10.17487/RFC4492 RFC4493 The AES-CMAC Algorithm JH. Song R. Poovendran J. Lee T. Iwata June 2006 ASCII HTML 20 cipher-based message authentication code omac1 one-key cbc mac1 advanced encryption algorithm

The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code (CMAC), which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This memo specifies an authentication algorithm based on CMAC with the 128-bit Advanced Encryption Standard (AES). This new authentication algorithm is named AES-CMAC. The purpose of this document is to make the AES-CMAC algorithm conveniently available to the Internet Community. This memo provides information for the Internet community.

 draft-songlee-aes-cmac-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4493 RFC4494 The AES-CMAC-96 Algorithm and Its Use with IPsec JH. Song R. Poovendran J. Lee June 2006 ASCII HTML 8 cipher-basd message authentication code one-key cbc-mac1 omac1 xcbc extended cipher block chaining advanced encryption standard

The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code (CMAC), which is equivalent to the One-Key CBC-MAC1 (OMAC1) algorithm submitted by Iwata and Kurosawa. OMAC1 efficiently reduces the key size of Extended Cipher Block Chaining mode (XCBC). This memo specifies the use of CMAC mode as an authentication mechanism of the IPsec Encapsulating Security Payload (ESP) and the Authentication Header (AH) protocols. This new algorithm is named AES-CMAC-96. [STANDARDS-TRACK]

 draft-songlee-aes-cmac-96-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4494 RFC4495 A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow J. Polk S. Dhesikan May 2006 ASCII HTML 21 rsvpv1

This document proposes an extension to the Resource Reservation Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation. This mechanism can be used to affect individual reservations, aggregate reservations, or other forms of RSVP tunnels. This specification is an extension of RFC 2205. [STANDARDS-TRACK]

 draft-ietf-tsvwg-rsvp-bw-reduction-02 RFC2205 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4495 RFC4496 Open Pluggable Edge Services (OPES) SMTP Use Cases M. Stecher A. Barbir May 2006 ASCII HTML 12

The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework. This document describes OPES SMTP use cases and deployment scenarios in preparation for SMTP adaptation with OPES. This memo provides information for the Internet community.

 draft-ietf-opes-smtp-use-cases-06 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC4496 RFC4497 Interworking between the Session Initiation Protocol (SIP) and QSIG J. Elwell F. Derks P. Mourot O. Rousseau May 2006 ASCII HTML 65 telecommunication networks enterprise networks signalling

This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) within Private Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sipping-qsig2sip-04 RFC8996 BCP0117 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC4497 RFC4498 The Managed Object Aggregation MIB G. Keeni May 2006 ASCII HTML 29 management information base aggregate mib time aggregate mib

This memo defines a portion of the Management Information Base (MIB), the Aggregation MIB modules, for use with network management protocols in the Internet community. In particular, the Aggregation MIB modules will be used to configure a network management agent to aggregate the values of a user-specified set of Managed Object instances and to service queries related to the aggregated Managed Object instances. This memo defines an Experimental Protocol for the Internet community.

 draft-glenn-mo-aggr-mib-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4498 RFC4499 RFC4500 RFC4501 Domain Name System Uniform Resource Identifiers S. Josefsson May 2006 ASCII HTML 10 dns uri

This document defines Uniform Resource Identifiers for Domain Name System resources. [STANDARDS-TRACK]

 draft-josefsson-dns-url-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4501 10.17487/RFC4501 RFC4502 Remote Network Monitoring Management Information Base Version 2 S. Waldbusser May 2006 ASCII HTML 142 RMON-MIB RMON MIB

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices.

This document obsoletes RFC 2021, updates RFC 3273, and contains a new version of the RMON2-MIB module. [STANDARDS-TRACK]

 draft-ietf-rmonmib-rmon2-v2-05 RFC2021 RFC3273 DRAFT STANDARD DRAFT STANDARD IETF ops rmonmib http://www.rfc-editor.org/errata_search.php?rfc=4502 10.17487/RFC4502 RFC4503 A Description of the Rabbit Stream Cipher Algorithm M. Boesgaard M. Vesterager E. Zenner May 2006 ASCII HTML 12 iv initialization vector encryption algorithm

This document describes the encryption algorithm Rabbit. It is a stream cipher algorithm with a 128-bit key and 64-bit initialization vector (IV). The method was published in 2003 and has been subject to public security and performance revision. Its high performance makes it particularly suited for the use with Internet protocols where large amounts of data have to be processed. This memo provides information for the Internet community.

 draft-zenner-rabbit-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4503 10.17487/RFC4503 RFC4504 SIP Telephony Device Requirements and Configuration H. Sinnreich Editor S. Lass C. Stredicke May 2006 ASCII HTML 37 session initiation protocol pc pda analog

This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones.

We present a glossary of the most common settings and some of the more widely used values for some settings. This memo provides information for the Internet community.

 draft-sinnreich-sipdev-req-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4504 RFC4505 Anonymous Simple Authentication and Security Layer (SASL) Mechanism K. Zeilenga June 2006 ASCII HTML 9 SASL-ANON Simple Authentication Security Layer

On the Internet, it is common practice to permit anonymous access to various services. Traditionally, this has been done with a plain-text password mechanism using "anonymous" as the user name and using optional trace information, such as an email address, as the password. As plain-text login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. [STANDARDS-TRACK]

 draft-ietf-sasl-anon-05 RFC2245 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl 10.17487/RFC4505 RFC4506 XDR: External Data Representation Standard M. Eisler Editor May 2006 ASCII HTML 27 XDR rpc onc open network computing

This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. This document obsoletes RFC 1832. [STANDARDS-TRACK]

 draft-ietf-nfsv4-rfc1832bis-06 RFC1832 STD0067 INTERNET STANDARD INTERNET STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=4506 10.17487/RFC4506 RFC4507 Transport Layer Security (TLS) Session Resumption without Server-Side State J. Salowey H. Zhou P. Eronen H. Tschofenig May 2006 ASCII HTML 17

This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping \%per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. [STANDARDS-TRACK]

 draft-salowey-tls-ticket-07 RFC5077 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4507 RFC4508 Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method O. Levin A. Johnston May 2006 ASCII HTML 6 caller preferences

The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism of RFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. [STANDARDS-TRACK]

 draft-ietf-sip-refer-feature-param-01 RFC8217 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4508 RFC4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) W. Hardaker May 2006 ASCII HTML 7 domain name system dns dnskey

This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS-TRACK]

 draft-ietf-dnsext-ds-sha256-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4509 10.17487/RFC4509 RFC4510 Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map K. Zeilenga Editor June 2006 ASCII HTML 7 LDAPV3 LDAv3 x.500 LDAP3-ATD syntax LDAP3-UTF8 x.500 ASN.1 string format STR-LDAP LDAP-URL Lightweight Directory Access Protocol Universal Resource Locator

The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document provides a road map of the LDAP Technical Specification. [STANDARDS-TRACK]

 draft-ietf-ldapbis-roadmap-08 RFC2251 RFC2252 RFC2253 RFC2254 RFC2255 RFC2256 RFC2829 RFC2830 RFC3377 RFC3771 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4510 10.17487/RFC4510 RFC4511 Lightweight Directory Access Protocol (LDAP): The Protocol J. Sermersheim Editor June 2006 ASCII HTML 68 LDAP TLS LDAPv3 LDAv3 x.500

This document describes the protocol elements, along with their semantics and encodings, of the Lightweight Directory Access Protocol (LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK]

 draft-ietf-ldapbis-protocol-32 RFC2251 RFC2830 RFC3771 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4511 10.17487/RFC4511 RFC4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models K. Zeilenga Editor June 2006 ASCII HTML 52 LDAv3 x.500 LDAPv3 LDAP3-ATD syntax elective extensions mechanisms

The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document describes the X.500 Directory Information Models, as used in LDAP. [STANDARDS-TRACK]

 draft-ietf-ldapbis-models-14 RFC2251 RFC2252 RFC2256 RFC3674 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4512 10.17487/RFC4512 RFC4513 Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms R. Harrison Editor June 2006 ASCII HTML 34 LDAP TLS

This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation.

This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and the Simple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism.

This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes.

This document, together with other documents in the LDAP Technical Specification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830. [STANDARDS-TRACK]

 draft-ietf-ldapbis-authmeth-19 RFC2251 RFC2829 RFC2830 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4513 10.17487/RFC4513 RFC4514 Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names K. Zeilenga Editor June 2006 ASCII HTML 15 LDAP3-UTF8 LDAPv3 x.500 ASN.1 string format

The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK]

 draft-ietf-ldapbis-dn-16 RFC2253 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4514 10.17487/RFC4514 RFC4515 Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters M. Smith Editor T. Howes June 2006 ASCII HTML 12 STR-LDAP STRLDAP LDAPv3 X.500 BER ASN.1

Lightweight Directory Access Protocol (LDAP) search filters are transmitted in the LDAP protocol using a binary representation that is appropriate for use on the network. This document defines a human-readable string representation of LDAP search filters that is appropriate for use in LDAP URLs (RFC 4516) and in other applications. [STANDARDS-TRACK]

 draft-ietf-ldapbis-filter-09 RFC2254 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4515 10.17487/RFC4515 RFC4516 Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator M. Smith Editor T. Howes June 2006 ASCII HTML 15 LDAP-URL LDAPURL LDAP search URL URI LDAPv3

This document describes a format for a Lightweight Directory Access Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed. [STANDARDS-TRACK]

 draft-ietf-ldapbis-url-09 RFC2255 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4516 10.17487/RFC4516 RFC4517 Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules S. Legg Editor June 2006 ASCII HTML 53 LDAP3-ATD LDAv3 x.500 syntax,

Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory, whose values may be transferred in the LDAP protocol, has a defined syntax that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories. [STANDARDS-TRACK]

 draft-ietf-ldapbis-syntaxes-11 RFC2252 RFC2256 RFC3698 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4517 10.17487/RFC4517 RFC4518 Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation K. Zeilenga June 2006 ASCII HTML 14

The previous Lightweight Directory Access Protocol (LDAP) technical specifications did not precisely define how character string matching is to be performed. This led to a number of usability and interoperability problems. This document defines string preparation algorithms for character-based matching rules defined for use in LDAP. [STANDARDS-TRACK]

 draft-ietf-ldapbis-strprep-07 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4518 10.17487/RFC4518 RFC4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications A. Sciberras Editor June 2006 ASCII HTML 35 Lightweight Directory Access Protocol syntax

This document is an integral part of the Lightweight Directory Access Protocol (LDAP) technical specification. It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as White Pages. These objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. [STANDARDS-TRACK]

 draft-ietf-ldapbis-user-schema-11 RFC2256 RFC2247 RFC2798 RFC2377 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4519 10.17487/RFC4519 RFC4520 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) K. Zeilenga June 2006 ASCII HTML 19

This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). The document also provides guidelines to the Internet Assigned Numbers Authority (IANA) describing conditions under which new values can be assigned. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ldapbis-bcp64-07 RFC3383 BCP0064 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4520 10.17487/RFC4520 RFC4521 Considerations for Lightweight Directory Access Protocol (LDAP) Extensions K. Zeilenga June 2006 ASCII HTML 16

The Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for adding new operations, extending existing operations, and expanding user and system schemas. This document discusses considerations for designers of LDAP extensions. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-zeilenga-ldap-ext-10 BCP0118 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4521 10.17487/RFC4521 RFC4522 Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option S. Legg June 2006 ASCII HTML 8 ber ldap-specific encoding

Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax (i.e., data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP\-specific encoding to distinguish it from other methods of encoding attribute values. This document defines an attribute option, the binary option, that can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories. [STANDARDS-TRACK]

 draft-legg-ldap-binary-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4522 RFC4523 Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates K. Zeilenga June 2006 ASCII HTML 24 LDAP3-ATD LDAv3 x.500 syntax pkix

This document describes schema for representing X.509 certificates, X.521 security information, and related elements in directories accessible using the Lightweight Directory Access Protocol (LDAP). The LDAP definitions for these X.509 and X.521 schema elements replace those provided in RFCs 2252 and 2256. [STANDARDS-TRACK]

 draft-zeilenga-ldap-x509-02 RFC2252 RFC2256 RFC2587 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4523 10.17487/RFC4523 RFC4524 COSINE LDAP/X.500 Schema K. Zeilenga Editor June 2006 ASCII HTML 25 Naming

This document provides a collection of schema elements for use with the Lightweight Directory Access Protocol (LDAP) from the COSINE and Internet X.500 pilot projects.

This document obsoletes RFC 1274 and updates RFCs 2247 and 2798. [STANDARDS-TRACK]

 draft-zeilenga-ldap-cosine-02 RFC1274 RFC2247 RFC2798 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4524 10.17487/RFC4524 RFC4525 Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension K. Zeilenga June 2006 ASCII HTML 6 pre-read post-read control extension

This document describes an extension to the Lightweight Directory Access Protocol (LDAP) Modify operation to support an increment capability. This extension is useful in provisioning applications, especially when combined with the assertion control and/or the pre-read or post-read control extension. This memo provides information for the Internet community.

 draft-zeilenga-ldap-incr-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4525 RFC4526 Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters K. Zeilenga June 2006 ASCII HTML 5 x.500 string representation

This document extends the Lightweight Directory Access Protocol (LDAP) to support absolute True and False filters based upon similar capabilities found in X.500 directory systems. The document also extends the String Representation of LDAP Search Filters to support these filters. [STANDARDS-TRACK]

 draft-zeilenga-ldap-t-f-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4526 10.17487/RFC4526 RFC4527 Lightweight Directory Access Protocol (LDAP) Read Entry Controls K. Zeilenga June 2006 ASCII HTML 8

This document specifies an extension to the Lightweight Directory Access Protocol (LDAP) to allow the client to read the target entry of an update operation. The client may request to read the entry before and/or after the modifications are applied. These reads are done as an atomic part of the update operation. [STANDARDS-TRACK]

 draft-zeilenga-ldap-readentry-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4527 10.17487/RFC4527 RFC4528 Lightweight Directory Access Protocol (LDAP) Assertion Control K. Zeilenga June 2006 ASCII HTML 6 test and set test and clear

This document defines the Lightweight Directory Access Protocol (LDAP) Assertion Control, which allows a client to specify that a directory operation should only be processed if an assertion applied to the target entry of the operation is true. It can be used to construct "test and set", "test and clear", and other conditional operations. [STANDARDS-TRACK]

 draft-zeilenga-ldap-assert-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4528 10.17487/RFC4528 RFC4529 Requesting Attributes by Object Class in the Lightweight Directory Access Protocol K. Zeilenga June 2006 ASCII HTML 6

The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, and/or attributes selected by their description. This document extends LDAP to support a mechanism that LDAP clients may use to request the return of all attributes of an object class. This memo provides information for the Internet community.

 draft-zeilenga-ldap-adlist-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4529 10.17487/RFC4529 RFC4530 Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute K. Zeilenga June 2006 ASCII HTML 8 x.500 universally unique identifier

This document describes the LDAP/X.500 \'entryUUID' operational attribute and associated matching rules and syntax. The attribute holds a server-assigned Universally Unique Identifier (UUID) for the object. Directory clients may use this attribute to distinguish objects identified by a distinguished name or to locate an object after renaming. [STANDARDS-TRACK]

 draft-zeilenga-ldap-uuid-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4530 RFC4531 Lightweight Directory Access Protocol (LDAP) Turn Operation K. Zeilenga June 2006 ASCII HTML 9 turn request turn response

This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other. This memo defines an Experimental Protocol for the Internet community.

 draft-zeilenga-ldap-turn-03 RFC8996 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4531 RFC4532 Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation K. Zeilenga June 2006 ASCII HTML 7 authorization identity

This specification provides a mechanism for Lightweight Directory Access Protocol (LDAP) clients to obtain the authorization identity the server has associated with the user or application entity. This mechanism is specified as an LDAP extended operation called the LDAP "Who am I?" operation. [STANDARDS-TRACK]

 draft-zeilenga-ldap-authzid-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4532 10.17487/RFC4532 RFC4533 The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation K. Zeilenga J.H. Choi June 2006 ASCII HTML 32 dit directory information tree

This specification describes the Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation. The operation allows a client to maintain a copy of a fragment of the Directory Information Tree (DIT). It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search Operation. This memo defines an Experimental Protocol for the Internet community.

 draft-zeilenga-ldup-sync-06 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4533 RFC4534 Group Security Policy Token v1 A. Colegrove H. Harney June 2006 ASCII HTML 33 cryptographic group

The Group Security Policy Token is a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group. Because the security of a group is composed of the totality of multiple security services, mechanisms, and attributes throughout the communications infrastructure, an authenticatable representation of the features that must be supported throughout the system is needed to ensure consistent security. This document specifies the structure of such a token. [STANDARDS-TRACK]

 draft-ietf-msec-policy-token-sec-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=4534 10.17487/RFC4534 RFC4535 GSAKMP: Group Secure Association Key Management Protocol H. Harney U. Meth A. Colegrove G. Gross June 2006 ASCII HTML 106 security framework cryptographic network

This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys. [STANDARDS-TRACK]

 draft-ietf-msec-gsakmp-sec-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4535 RFC4536 The application/smil and application/smil+xml Media Types P. Hoschka July 2006 ASCII HTML 8 synchronized multimedia integration language

This document specifies the media type for versions 1.0, 2.0, and 2.1 of the Synchronized Multimedia Integration Language (SMIL 1.0, SMIL 2.0, SMIL 2.1). SMIL allows integration of a set of independent multimedia objects into a synchronized multimedia presentation. This memo provides information for the Internet community.

 draft-hoschka-smil-media-type-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4536 RFC4537 Kerberos Cryptosystem Negotiation Extension L. Zhu P. Leach K. Jaganathan June 2006 ASCII HTML 6

This document specifies an extension to the Kerberos protocol as defined in RFC 4120, in which the client can send a list of supported encryption types in decreasing preference order, and the server then selects an encryption type that is supported by both the client and the server. [STANDARDS-TRACK]

 draft-zhu-kerb-enctype-nego-04 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC4537 RFC4538 Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) J. Rosenberg June 2006 ASCII HTML 17 tdialog

This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness. [STANDARDS-TRACK]

 draft-ietf-sip-target-dialog-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4538 RFC4539 Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF) T. Edwards May 2006 ASCII HTML 6

This document serves to register a media type for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF). MXF, defined by SMPTE 377M, is a standard wrapper format developed for the interchange of audiovisual material, including both audiovisual essence and rich metadata. This memo provides information for the Internet community.

 draft-edwards-mime-mxf-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4539 RFC4540 NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 M. Stiemerling J. Quittek C. Cadar May 2006 ASCII HTML 67 midcom

This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989. Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements. This memo defines an Experimental Protocol for the Internet community.

 draft-stiemerling-midcom-simco-08 RFC8996 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4540 RFC4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches M. Christensen K. Kimball F. Solensky May 2006 ASCII HTML 16 igmpv3 mldv2

This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered. This memo provides information for the Internet community.

 draft-ietf-magma-snoop-12 INFORMATIONAL INFORMATIONAL IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=4541 10.17487/RFC4541 RFC4542 Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite F. Baker J. Polk May 2006 ASCII HTML 42 ieps internet emergency preparedness service call admission control cac phb per hop behavior multi-level precedence and preemption mlpp government emergency telecommunication service gets

RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis.

This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. This memo provides information for the Internet community.

 draft-ietf-tsvwg-mlpp-that-works-04 RFC5865 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC4542 RFC4543 The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH D. McGrew J. Viega May 2006 ASCII HTML 14 encapsulating security payload gcm galois/counter mode authentication header

This memo describes the use of the Advanced Encryption Standard (AES) Galois Message Authentication Code (GMAC) as a mechanism to provide data origin authentication, but not confidentiality, within the IPsec Encapsulating Security Payload (ESP) and Authentication Header (AH). GMAC is based on the Galois/Counter Mode (GCM) of operation, and can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK]

 draft-mcgrew-aes-gmac-esp-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4543 10.17487/RFC4543 RFC4544 Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI) M. Bakke M. Krueger T. McSweeney J. Muchow May 2006 ASCII HTML 83 tcp/ip scsi

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). [STANDARDS-TRACK]

 draft-ietf-ips-iscsi-mib-11 RFC7147 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4544 10.17487/RFC4544 RFC4545 Definitions of Managed Objects for IP Storage User Identity Authorization M. Bakke J. Muchow May 2006 ASCII HTML 43 mib management information base snmp tcp/ip ips-auth-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing user identities and the names, addresses, and credentials required manage access control, for use with various protocols. This document was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB module provides only the set of identities to be used within access lists; it is the responsibility of other MIB modules making use of this one to tie them to their own access lists or other authorization control methods. [STANDARDS-TRACK]

 draft-ietf-ips-auth-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4545 10.17487/RFC4545 RFC4546 Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces D. Raftus E. Cardona June 2006 ASCII HTML 139 cmts cm upstream downstream tdma atdma scdma quality of service channel utilizazation

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Radio Frequency (RF) interfaces for systems compliant with the Data Over Cable Service Interface Specifications (DOCSIS). [STANDARDS-TRACK]

 draft-ietf-ipcdn-docs-rfmibv2-14 RFC2670 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4546 RFC4547 Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems A. Ahmad G. Nakanishi June 2006 ASCII HTML 40 snmp simple network management protocol mib smiv2 DOCS-IETF-CABLE-DEVICE-NOTIFICATION-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP) based event notification management of Data Over Cable Service Interface Specification (DOCSIS) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB.

This memo specifies a MIB module in a manner that is compliant to the Structure of Management Information Version 2 (SMIv2). The set of objects is consistent with the SNMP framework and existing SNMP standards. [STANDARDS-TRACK]

 draft-ietf-ipcdn-docsisevent-mib-06 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4547 RFC4548 Internet Code Point (ICP) Assignments for NSAP Addresses E. Gray J. Rutemiller G. Swallow May 2006 ASCII HTML 9 network service access point

This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service Access Point (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values. In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888. In the second task, this document incorporates wording and specifications from ITU-T Recommendation X.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments. [STANDARDS-TRACK]

 draft-gray-rfc1888bis-03 RFC1888 RFC4048 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4548 RFC4549 Synchronization Operations for Disconnected IMAP4 Clients A. Melnikov Editor June 2006 ASCII HTML 35 internet message access protocol

This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the "driver" portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy.

This note describes different strategies that can be used by disconnected clients and shows how to use IMAP protocol in order to minimize the time of the synchronization process.

This note also lists IMAP extensions that a server should implement in order to provide better synchronization facilities to disconnected clients. This memo provides information for the Internet community.

 draft-melnikov-imap-disc-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4549 RFC4550 Internet Email to Support Diverse Service Environments (Lemonade) Profile S. Maes A. Melnikov June 2006 ASCII HTML 23 internet message access protocol,

This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.

The Internet Email to Support Diverse Service Environments (Lemonade) profile relies upon extensions to IMAP and Mail Submission protocols; specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) extensions and the BURL extension to the SUBMIT protocol (RFC 4409). [STANDARDS-TRACK]

 draft-ietf-lemonade-profile-07 RFC5550 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4550 10.17487/RFC4550 RFC4551 IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization A. Melnikov S. Hole June 2006 ASCII HTML 25 internet mail access protocol

Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients.

The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients.

The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes.

This document defines an extension to IMAP (RFC 3501). [STANDARDS-TRACK]

 draft-ietf-imapext-condstore-09 RFC7162 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=4551 10.17487/RFC4551 RFC4552 Authentication/Confidentiality for OSPFv3 M. Gupta N. Melam June 2006 ASCII HTML 15 open shortest path first authentication header encapsulating security payload ah/esp

This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]

 draft-ietf-ospf-ospfv3-auth-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=4552 10.17487/RFC4552 RFC4553 Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) A. Vainshtein Editor YJ. Stein Editor June 2006 ASCII HTML 27 SAToP pseudowires circuit emulation structure-agnostic emulation

This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing. [STANDARDS-TRACK]

 draft-ietf-pwe3-satop-05 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4553 10.17487/RFC4553 RFC4554 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks T. Chown June 2006 ASCII HTML 11 Virtual Local Area Network

Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method, IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link. This memo provides information for the Internet community.

 draft-ietf-v6ops-vlan-usage-01 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4554 RFC4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE) P. Eronen June 2006 ASCII HTML 33 internet key exchange ipsec internet protocol security vpn virtual private networks

This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change. A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working. [STANDARDS-TRACK]

 draft-ietf-mobike-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec mobike 10.17487/RFC4555 RFC4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) L. Zhu B. Tung June 2006 ASCII HTML 42

This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields. [STANDARDS-TRACK]

 draft-ietf-cat-kerberos-pk-init-34 RFC6112 RFC8062 RFC8636 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=4556 10.17487/RFC4556 RFC4557 Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) L. Zhu K. Jaganathan N. Williams June 2006 ASCII HTML 6

This document defines a mechanism to enable in-band transmission of Online Certificate Status Protocol (OCSP) responses in the Kerberos network authentication protocol. These responses are used to verify the validity of the certificates used in Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), which is the Kerberos Version 5 extension that provides for the use of public key cryptography. [STANDARDS-TRACK]

 draft-ietf-krb-wg-ocsp-for-pkinit-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=4557 10.17487/RFC4557 RFC4558 Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement Z. Ali R. Rahman D. Prairie D. Papadimitriou June 2006 ASCII HTML 7 Multi-Protocol Label Switching mpls Generalized Multi-Protocol Label Switching gmpls Traffic Engineering te rsvp-te gr graceful restart

Use of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. [STANDARDS-TRACK]

 draft-ietf-ccamp-rsvp-node-id-based-hello-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4558 RFC4559 SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows K. Jaganathan L. Zhu J. Brezak June 2006 ASCII HTML 8 msie microsoft internet explorer iis internet information services simple and protected negotiate nt lan manager

This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 2000 use Kerberos for security enhancements of web transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of "negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed. This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism. Details of Simple And Protected Negotiate (SPNEGO) implementation are not provided in this document. This memo provides information for the Internet community.

 draft-jaganathan-kerberos-http-01 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4559 10.17487/RFC4559 RFC4560 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations J. Quittek Editor K. White Editor June 2006 ASCII HTML 100 mib management information base DISMAN-PING-MIB DEFINITIONS DISMAN-TRACEROUTE-MIB DEFINITIONS DISMAN-NSLOOKUP-MIB DEFINITIONS

This memo defines Management Information Bases (MIBs) for performing ping, traceroute, and lookup operations at a host. When managing a network, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host. A lookup capability is defined in order to enable resolution of either an IP address to an DNS name or a DNS name to an IP address at a remote host.

Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. [STANDARDS-TRACK]

 draft-ietf-disman-remops-mib-v2-09 RFC2925 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC4560 RFC4561 Definition of a Record Route Object (RRO) Node-Id Sub-Object J.-P. Vasseur Editor Z. Ali S. Sivabalan June 2006 ASCII HTML 10 multiprotocol label switching traffic engineering plr point of local repair igp interior gateway protocol as autonomous system abr area border router asbr autonomous system border router

In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an Area Border Router (ABR) or Autonomous System Border Router (ASBR). This document specifies the use of existing Record Route Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS Fast Reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. [STANDARDS-TRACK]

 draft-ietf-mpls-nodeid-subobject-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4561 RFC4562 MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network T. Melsen S. Blake June 2006 ASCII HTML 13 Ethernet Access Network ARP DHCP

This document describes a mechanism to ensure layer-2 separation of Local Area Network (LAN) stations accessing an IPv4 gateway over a bridged Ethernet segment.

The mechanism - called "MAC-Forced Forwarding" - implements an Address Resolution Protocol (ARP) proxy function that prohibits Ethernet Media Access Control (MAC) address resolution between hosts located within the same IPv4 subnet but at different customer premises, and in effect directs all upstream traffic to an IPv4 gateway. The IPv4 gateway provides IP-layer connectivity between these same hosts. This memo provides information for the Internet community.

 draft-melsen-mac-forced-fwd-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4562 RFC4563 The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY) E. Carrara V. Lehtovirta K. Norrman June 2006 ASCII HTML 10 security key management multicast broadcast MBMS

This memo specifies a new Type (the Key ID Information Type) for the General Extension Payload in the Multimedia Internet KEYing (MIKEY) Protocol. This is used in, for example, the Multimedia Broadcast/Multicast Service specified in the Third Generation Partnership Project. [STANDARDS-TRACK]

 draft-ietf-msec-newtype-keyid-05 RFC6309 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4563 RFC4564 Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) S. Govindan Editor H. Cheng ZH. Yao WH. Zhou L. Yang July 2006 ASCII HTML 32 wlan wireless local area network

This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability among Wireless Local Area Network (WLAN) devices of alternative designs. This memo provides information for the Internet community.

 draft-ietf-capwap-objectives-04 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC4564 RFC4565 Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols D. Loher D. Nelson O. Volinsky B. Sarikaya July 2006 ASCII HTML 31

This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26, 2005. his memo provides information for the Internet community.

 draft-ietf-capwap-eval-00 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC4565 RFC4566 SDP: Session Description Protocol M. Handley V. Jacobson C. Perkins July 2006 ASCII HTML 49 SDP mbone internet multicast backbone multimedia internet addresses syntax

This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-new-26 RFC2327 RFC3266 RFC8866 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4566 10.17487/RFC4566 RFC4567 Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) J. Arkko F. Lindholm M. Naslund K. Norrman E. Carrara July 2006 ASCII HTML 30 key management protocol multimedia internet keying mikey

This document defines general extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol.

General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined. [STANDARDS-TRACK]

 draft-ietf-mmusic-kmgmt-ext-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4567 10.17487/RFC4567 RFC4568 Session Description Protocol (SDP) Security Descriptions for Media Streams F. Andreasen M. Baugher D. Wing July 2006 ASCII HTML 44 srtp secure real-time transport protocol

This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdescriptions-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4568 10.17487/RFC4568 RFC4569 Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag G. Camarillo July 2006 ASCII HTML 4

This document registers with the IANA a new media feature tag associated with the 'message' media type. This media feature tag indicates that a particular device supports 'message' as a streaming media type. Media feature tags can be used to route calls to devices that support certain features. This memo provides information for the Internet community.

 draft-ietf-sipping-message-tag-00 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4569 RFC4570 Session Description Protocol (SDP) Source Filters B. Quinn R. Finlayson July 2006 ASCII HTML 14 internet protocol ip source-filter ssm source-specific multicast

This document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination "connection" addresses. It defines the syntax and semantics for an SDP "source-filter" attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-srcfilter-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4570 10.17487/RFC4570 RFC4571 Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport J. Lazzaro July 2006 ASCII HTML 9 TCP-based media transport TCP tunnel transmission control protocol

This memo defines a method for framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP). The memo also defines how session descriptions may specify RTP streams that use the framing method. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-framing-contrans-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4571 10.17487/RFC4571 RFC4572 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) J. Lennox July 2006 ASCII HTML 17 setup connection reestablishment

This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.

This document extends and updates RFC 4145. [STANDARDS-TRACK]

 draft-ietf-mmusic-comedia-tls-06 RFC8122 RFC4145 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4572 RFC4573 MIME Type Registration for RTP Payload Format for H.224 R. Even A. Lochbaum July 2006 ASCII HTML 7 real time transport protocol itu h.281 h.224 far-end camera control

In conversational video applications, far-end camera control protocol is used by participants to control the remote camera. The protocol that is commonly used is ITU H.281 over H.224. The document registers the H224 media type. It defines the syntax and the semantics of the Session Description Protocol (SDP) parameters needed to support far-end camera control protocol using H.224. [STANDARDS-TRACK]

 draft-ietf-avt-mime-h224-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4573 RFC4574 The Session Description Protocol (SDP) Label Attribute O. Levin G. Camarillo August 2006 ASCII HTML 8 media level attribute media stream

This document defines a new Session Description Protocol (SDP) media-level attribute: "label". The "label" attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the "label" attribute to a particular media stream or streams. The application can then use the provided pointer to refer to each particular media stream in its context. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-media-label-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4574 RFC4575 A Session Initiation Protocol (SIP) Event Package for Conference State J. Rosenberg H. Schulzrinne O. Levin Editor August 2006 ASCII HTML 48 conference event package uri uniform resource identifier

This document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI). Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. [STANDARDS-TRACK]

 draft-ietf-sipping-conference-package-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC4575 RFC4576 Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen P. Psenak P. Pillay-Esnault June 2006 ASCII HTML 7 service provider sp provider edge pe

This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides "BGP/MPLS IP VPN" service to a customer and the customer uses OSPFv2 to advertise its routes to the SP. In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFv2 from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of this conversion, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE that receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it. [STANDARDS-TRACK]

 draft-ietf-ospf-2547-dnbit-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC4576 RFC4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen P. Psenak P. Pillay-Esnault June 2006 ASCII HTML 25 ce open shortest path first mpls Multiprotocol Label Switching

Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (PE routers). The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol.

This document updates RFC 4364. [STANDARDS-TRACK]

 draft-ietf-l3vpn-ospf-2547-06 RFC4364 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4577 10.17487/RFC4577 RFC4578 Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) M. Johnston S. Venaas Editor November 2006 ASCII HTML 7 efi extensible firmware interface

We define Dynamic Host Configuration Protocol (DHCP) options being used by Preboot eXecution Environment (PXE) and Extensible Firmware Interface (EFI) clients to uniquely identify booting client machines and their pre-OS runtime environment so that the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client. This memo provides information for the Internet community.

 draft-ietf-dhc-pxe-options-03 INFORMATIONAL INFORMATIONAL IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4578 10.17487/RFC4578 RFC4579 Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents A. Johnston O. Levin August 2006 ASCII HTML 43 ua conference-unaware conference-aware focus

This specification defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from the perspective of different user agent (UA) types: conference-unaware, conference-aware, and focus UAs. The use of Uniform Resource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sipping-cc-conferencing-07 BCP0119 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC4579 RFC4580 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option B. Volz June 2006 ASCII HTML 6

This memo defines a new Relay Agent Subscriber-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to associate a stable "Subscriber-ID" with DHCPv6 client messages in a way that is independent of the client and of the underlying physical network infrastructure. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-subid-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4580 RFC4581 Cryptographically Generated Addresses (CGA) Extension Field Format M. Bagnulo J. Arkko October 2006 ASCII HTML 4 tlv

This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. This document updates RFC 3972. [STANDARDS-TRACK]

 draft-bagnulo-cga-ext-02 RFC3972 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4581 RFC4582 The Binary Floor Control Protocol (BFCP) G. Camarillo J. Ott K. Drage November 2006 ASCII HTML 65 conference

Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.

This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. [STANDARDS-TRACK]

 draft-ietf-xcon-bfcp-06 RFC8855 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC4582 RFC4583 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams G. Camarillo November 2006 ASCII HTML 12 bfcp stream

This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-bfcp-03 RFC8856 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4583 10.17487/RFC4583 RFC4584 Extension to Sockets API for Mobile IPv6 S. Chakrabarti E. Nordmark July 2006 ASCII HTML 25 advanced socket api mobility header messages hom address destination routing header type 2 socket applications

This document describes data structures and API support for Mobile IPv6 as an extension to the Advanced Socket API for IPv6.

Just as the Advanced Sockets API for IPv6 gives access to various extension headers and the ICMPv6 protocol, this document specifies the same level of access for Mobile IPv6 components. It specifies a mechanism for applications to retrieve and set information for Mobility Header messages, Home Address destination options, and Routing Header Type 2 extension headers. It also specifies the common data structures and definitions that might be used by certain advanced Mobile IPv6 socket applications. This memo provides information for the Internet community.

 draft-ietf-mip6-mipext-advapi-07 INFORMATIONAL INFORMATIONAL IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4584 10.17487/RFC4584 RFC4585 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) J. Ott S. Wenger N. Sato C. Burmeister J. Rey July 2006 ASCII HTML 51 media stream feedback based error audio visual profile

Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK]

 draft-ietf-avt-rtcp-feedback-11 RFC5506 RFC8108 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4585 10.17487/RFC4585 RFC4586 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations C. Burmeister R. Hakenberg A. Miyazaki J. Ott N. Sato S. Fukunaga July 2006 ASCII HTML 28 Real-time Transport Protocol

This document describes the results achieved when simulating the timing rules of the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback, denoted AVPF. Unicast and multicast topologies are considered as well as several protocol and environment configurations. The results show that the timing rules result in better performance regarding feedback delay and still preserve the well-accepted RTP rules regarding allowed bit rates for control traffic. This memo provides information for the Internet community.

 draft-burmeister-avt-rtcp-feedback-sim-06 INFORMATIONAL INFORMATIONAL IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4586 10.17487/RFC4586 RFC4587 RTP Payload Format for H.261 Video Streams R. Even August 2006 ASCII HTML 17 RTP-H.261 real-time transport protocol sdp session description protocol

This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP.

The memo also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.261 video codec. A media type registration is included for this payload format.

This specification obsoletes RFC 2032. [STANDARDS-TRACK]

 draft-ietf-avt-rfc2032-bis-13 RFC2032 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4587 10.17487/RFC4587 RFC4588 RTP Retransmission Payload Format J. Rey D. Leon A. Miyazaki V. Varsa R. Hakenberg July 2006 ASCII HTML 35 real time transport protocol rtcp real-time transport control protocol RTP/AVPF

RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-retransmission-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4588 10.17487/RFC4588 RFC4589 Location Types Registry H. Schulzrinne H. Tschofenig July 2006 ASCII HTML 12

This document creates a registry for describing the types of places a human or end system might be found. The registry is then referenced by other protocols that need a common set of location terms as protocol constants. Examples of location terms defined in this document include aircraft, office, and train station. [STANDARDS-TRACK]

 draft-ietf-geopriv-location-types-registry-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC4589 RFC4590 RADIUS Extension for Digest Authentication B. Sterman D. Sadolevsky D. Schwartz D. Williams W. Beck July 2006 ASCII HTML 32 remote authentication dial-in user service sip http

This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS-TRACK]

 draft-ietf-radext-digest-auth-09 RFC5090 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4590 10.17487/RFC4590 RFC4591 Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3) M. Townsley G. Wilkie S. Booth S. Bryant J. Lau August 2006 ASCII HTML 14 data link protocols frame encapsulation virtual-circuit creation and deletion status change notification

The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnel Frame Relay over L2TPv3, including frame encapsulation, virtual-circuit creation and deletion, and status change notification. [STANDARDS-TRACK]

 draft-ietf-l2tpext-pwe3-fr-07 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext http://www.rfc-editor.org/errata_search.php?rfc=4591 10.17487/RFC4591 RFC4592 The Role of Wildcards in the Domain Name System E. Lewis July 2006 ASCII HTML 20 cname

This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-TRACK]

 draft-ietf-dnsext-wcard-clarify-11 RFC1034 RFC2672 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4592 10.17487/RFC4592 RFC4593 Generic Threats to Routing Protocols A. Barbir S. Murphy Y. Yang October 2006 ASCII HTML 22 threat sources threat capability threat action threat consequences

Routing protocols are subject to attacks that can harm individual users or network operations as a whole. This document provides a description and a summary of generic threats that affect routing protocols in general. This work describes threats, including threat sources and capabilities, threat actions, and threat consequences, as well as a breakdown of routing functions that might be attacked separately. This memo provides information for the Internet community.

 draft-ietf-rpsec-routing-threats-07 INFORMATIONAL INFORMATIONAL IETF rtg rpsec 10.17487/RFC4593 RFC4594 Configuration Guidelines for DiffServ Service Classes J. Babiarz K. Chan F. Baker August 2006 ASCII HTML 57 differentiated services code points traffic conditioners per-hop behaviors phb dscp active queue management aqm

This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently. This memo provides information for the Internet community.

 draft-ietf-tsvwg-diffserv-service-classes-02 RFC5865 RFC8622 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4594 10.17487/RFC4594 RFC4595 Use of IKEv2 in the Fibre Channel Security Association Management Protocol F. Maino D. Black July 2006 ASCII HTML 16 internet key exchange

This document describes the use of IKEv2 to negotiate security protocols and transforms for Fibre Channel as part of the Fibre Channel Security Association Management Protocol. This usage requires that IKEv2 be extended with Fibre-Channel-specific security protocols, transforms, and name types. This document specifies these IKEv2 extensions and allocates identifiers for them. Using new IKEv2 identifiers for Fibre Channel security protocols avoids any possible confusion between IKEv2 negotiation for IP networks and IKEv2 negotiation for Fibre Channel. This memo provides information for the Internet community.

 draft-maino-fcsp-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4595 10.17487/RFC4595 RFC4596 Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension J. Rosenberg P. Kyzivat July 2006 ASCII HTML 40

This document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841. This memo provides information for the Internet community.

 draft-ietf-sipping-callerprefs-usecases-05 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4596 10.17487/RFC4596 RFC4597 Conferencing Scenarios R. Even N. Ismail August 2006 ASCII HTML 17 multimedia voice video text interactive text xcon

This document describes multimedia conferencing scenarios. It describes both basic and advanced conferencing scenarios involving voice, video, text, and interactive text sessions. These scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group. This memo provides information for the Internet community.

 draft-ietf-xcon-conference-scenarios-05 INFORMATIONAL INFORMATIONAL IETF rai xcon 10.17487/RFC4597 RFC4598 Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio B. Link July 2006 ASCII HTML 17 encoded audio data multichannel audio coding format

This document describes a Real-time Transport Protocol (RTP) payload format for transporting Enhanced AC-3 (E-AC-3) encoded audio data. E-AC-3 is a high-quality, multichannel audio coding format and is an extension of the AC-3 audio coding format, which is used in US High-Definition Television (HDTV), DVD, cable and satellite television, and other media. E-AC-3 is an optional audio format in US and world wide digital television and high-definition DVD formats. The RTP payload format as presented in this document includes support for data fragmentation. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-eac3-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4598 RFC4599 RFC4600 RFC4601 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) B. Fenner M. Handley H. Holbrook I. Kouvelas August 2006 ASCII PDF HTML 150 PIM-SM routing message type timers flags

This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source.

This document obsoletes RFC 2362, an Experimental version of PIM-SM. [STANDARDS-TRACK]

 draft-ietf-pim-sm-v2-new-12 RFC2362 RFC7761 RFC5059 RFC5796 RFC6226 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=4601 10.17487/RFC4601 RFC4602 Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis T. Pusateri August 2006 ASCII HTML 8

This document provides supporting documentation to advance the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Experimental status to Proposed Standard. This memo provides information for the Internet community.

 draft-ietf-pim-proposed-req-02 INFORMATIONAL INFORMATIONAL IETF rtg pim 10.17487/RFC4602 RFC4603 Additional Values for the NAS-Port-Type Attribute G. Zorn G. Weber R. Foltak July 2006 ASCII HTML 5 radius Remote Authentication Dial-In User Service

This document defines a set of values for the NAS-Port-Type RADIUS Attribute. This memo provides information for the Internet community.

 draft-zorn-radius-port-type-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4603 RFC4604 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast H. Holbrook B. Cain B. Haberman August 2006 ASCII HTML 11 ssm

The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an "SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications. [STANDARDS-TRACK]

 draft-holbrook-idmr-igmpv3-ssm-08 RFC3376 RFC3810 PROPOSED STANDARD PROPOSED STANDARD IETF int magma 10.17487/RFC4604 RFC4605 Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying") B. Fenner H. He B. Haberman H. Sandick August 2006 ASCII HTML 12

In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient for a device to learn and proxy group membership information and simply forward multicast packets based upon that information. This document describes a mechanism for forwarding based solely upon Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership information. [STANDARDS-TRACK]

 draft-ietf-magma-igmp-proxy-06 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=4605 10.17487/RFC4605 RFC4606 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control E. Mannie D. Papadimitriou August 2006 ASCII HTML 25

This document provides minor clarification to RFC 3946.

This document is a companion to the Generalized Multi-protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when GMPLS signaling is used. [STANDARDS-TRACK]

 draft-ietf-ccamp-rfc3946bis-01 RFC3946 RFC6344 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4606 10.17487/RFC4606 RFC4607 Source-Specific Multicast for IP H. Holbrook B. Cain August 2006 ASCII HTML 19 ipv4 ssm ipv6

IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK]

 draft-ietf-ssm-arch-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ssm http://www.rfc-editor.org/errata_search.php?rfc=4607 10.17487/RFC4607 RFC4608 Source-Specific Protocol Independent Multicast in 232/8 D. Meyer R. Rockell G. Shepherd August 2006 ASCII HTML 7 ip ssm

IP Multicast group addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast destination addresses and are reserved for use by source-specific multicast applications and protocols. This document defines operational recommendations to ensure source-specific behavior within the 232/8 range. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-mboned-ssm232-08 BCP0120 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC4608 RFC4609 Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements P. Savola R. Lehtonen D. Meyer October 2006 ASCII HTML 23 security threats intra-domain inter-domain any-source multicast asm source-specific multicast ssm embedded rendezvous point embedded-rp

This memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast (ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations that mitigate the identified threats. This memo provides information for the Internet community.

 draft-ietf-mboned-mroutesec-04 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC4609 RFC4610 Anycast-RP Using Protocol Independent Multicast (PIM) D. Farinacci Y. Cai August 2006 ASCII HTML 12 rendezvous point rp msdp register multicast source discovery register-stop

This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only. Other multicast protocols (such as Multicast Source Discovery Protocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP. [STANDARDS-TRACK]

 draft-ietf-pim-anycast-rp-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC4610 RFC4611 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios M. McBride J. Meylor D. Meyer August 2006 ASCII HTML 14 pim-sm protocol independent multicast sparse mode

This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode (PIM-SM). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-mboned-msdp-deploy-06 BCP0121 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC4611 RFC4612 Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration P. Jones H. Tamura August 2006 ASCII HTML 8 itu-t recommendation t.38 sdp session description protocol

This document defines the MIME sub-type audio/t38. The usage of this MIME type, which is intended for use within Session Description Protocol (SDP), is specified within ITU-T Recommendation T.38. This memo defines a Historic Document for the Internet community.

 draft-jones-avt-audio-t38-05 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4612 10.17487/RFC4612 RFC4613 Media Type Registrations for Downloadable Sounds for Musical Instrument Digital Interface (MIDI) P. Frojdh U. Lindgren M. Westerlund September 2006 ASCII HTML 6 dls

This document serves to register a media type for Downloadable Sounds. This memo provides information for the Internet community.

 draft-westerlund-mime-dls-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4613 RFC4614 A Roadmap for Transmission Control Protocol (TCP) Specification Documents M. Duke R. Braden W. Eddy E. Blanton September 2006 ASCII HTML 33

This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This memo provides information for the Internet community.

 draft-ietf-tcpm-tcp-roadmap-06 RFC7414 RFC6247 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC4614 RFC4615 The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE) J. Song R. Poovendran J. Lee T. Iwata August 2006 ASCII HTML 7 ipsec ip security pseudo-random function

Some implementations of IP Security (IPsec) may want to use a pseudo-random function (PRF) based on the Advanced Encryption Standard (AES). This memo describes such an algorithm, called AES-CMAC-PRF-128. It supports fixed and variable key sizes. [STANDARDS-TRACK]

 draft-songlee-aes-cmac-prf-128-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4615 RFC4616 The PLAIN Simple Authentication and Security Layer (SASL) Mechanism K. Zeilenga Editor August 2006 ASCII HTML 11 data confidentiality

This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command. [STANDARDS-TRACK]

 draft-ietf-sasl-plain-09 RFC2595 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=4616 10.17487/RFC4616 RFC4617 A Uniform Resource Name (URN) Formal Namespace for the Latvian National Government Integration Project J. Kornijenko August 2006 ASCII HTML 8 general contractor Olimps LTD subcontractors ABC software LTD Microsoft Latvia LTD Riga Internet eXchange Technologies LTD RIX Microlink LTD

This document describes a Uniform Resource Name (URN) namespace that is engineered by a consortium (general contractor, Olimps LTD, and subcontractors, ABC software LTD, Microsoft Latvia LTD, Riga Internet eXchange (RIX) Technologies LTD, and Microlink LTD) for naming information resources published and produced by the Latvian National Government Integration Project (Latvian abbreviation IVIS). This memo provides information for the Internet community.

 draft-kornijenko-ivis-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4617 RFC4618 Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks L. Martini E. Rosen G. Heron A. Malis September 2006 ASCII HTML 16 pw pseudowire point to point protocol pdu packet data unit

A pseudowire (PW) can be used to carry Point to Point Protocol (PPP) or High-Level Data Link Control (HDLC) Protocol Data Units over a Multiprotocol Label Switching (MPLS) network without terminating the PPP/HDLC protocol. This enables service providers to offer "emulated" HDLC, or PPP link services over existing MPLS networks. This document specifies the encapsulation of PPP/HDLC Packet Data Units (PDUs) within a pseudowire. [STANDARDS-TRACK]

 draft-ietf-pwe3-hdlc-ppp-encap-mpls-09 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4618 RFC4619 Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks L. Martini Editor C. Kawa Editor A. Malis Editor September 2006 ASCII HTML 19 pseudowire psn packet switched network pw

A frame relay pseudowire is a mechanism that exists between a provider's edge network nodes and that supports as faithfully as possible frame relay services over an MPLS packet switched network (PSN). This document describes the detailed encapsulation necessary to transport frame relay packets over an MPLS network. [STANDARDS-TRACK]

 draft-ietf-pwe3-frame-relay-07 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4619 10.17487/RFC4619 RFC4620 IPv6 Node Information Queries M. Crawford B. Haberman Editor August 2006 ASCII HTML 14 internet protocol version 6

This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ipngwg-icmp-name-lookups-15 EXPERIMENTAL EXPERIMENTAL IETF int ipv6 10.17487/RFC4620 RFC4621 Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol T. Kivinen H. Tschofenig August 2006 ASCII HTML 30 internet key exchange

The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility).

This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded. This memo provides information for the Internet community.

 draft-ietf-mobike-design-08 INFORMATIONAL INFORMATIONAL IETF sec mobike 10.17487/RFC4621 RFC4622 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre July 2006 ASCII HTML 23 Extensible Messaging and Presence Protocol Internationalized Resource Identifier Uniform Resource Identifier Jabber xmpp iri uri

This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]

 draft-saintandre-xmpp-iri-04 RFC5122 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4622 RFC4623 Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly A. Malis M. Townsley August 2006 ASCII HTML 17

This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services. [STANDARDS-TRACK]

 draft-ietf-pwe3-fragmentation-10 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4623 10.17487/RFC4623 RFC4624 Multicast Source Discovery Protocol (MSDP) MIB B. Fenner D. Thaler October 2006 ASCII HTML 32 management information base MSDP-MIB

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) (RFC 3618) speakers. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mboned-msdp-mib-01 EXPERIMENTAL EXPERIMENTAL IETF ops mboned 10.17487/RFC4624 RFC4625 Fibre Channel Routing Information MIB C. DeSanti K. McCloghrie S. Kode S. Gai September 2006 ASCII HTML 22 management information base T11-FC-ROUTE-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to routing within a Fibre Channel fabric, which is independent of the usage of a particular routing protocol. [STANDARDS-TRACK]

 draft-ietf-imss-fc-rtm-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4625 RFC4626 MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol C. DeSanti V. Gaonkar K. McCloghrie S. Gai September 2006 ASCII HTML 36 management information base T11-FC-FSPF-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Fabric Shortest Path First (FSPF) routing protocol. [STANDARDS-TRACK]

 draft-ietf-imss-fc-fspf-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4626 RFC4627 The application/json Media Type for JavaScript Object Notation (JSON) D. Crockford July 2006 ASCII HTML 10 data interchange format ECMAScript Programming Language Standard

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This memo provides information for the Internet community.

 draft-crockford-jsonorg-json-04 RFC7159 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4627 10.17487/RFC4627 RFC4628 RTP Payload Format for H.263 Moving RFC 2190 to Historic Status R. Even January 2007 ASCII HTML 5 real-time transport protocol itu-t itu telecommunication standardization sector transfer

The first RFC that describes RTP payload format for ITU Telecommunication Standardization Sector (ITU-T) recommendation H.263 is RFC 2190. This specification discusses why to move RFC 2190 to historic status. This memo provides information for the Internet community.

 draft-ietf-avt-rfc2190-to-historic-06 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC4628 RFC4629 RTP Payload Format for ITU-T Rec. H.263 Video J. Ott C. Bormann G. Sullivan S. Wenger R. Even Editor January 2007 ASCII HTML 29 real-time transport protocol multicast unicast sdp session description protocol

This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP.

The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.263 video codec.

The document obsoletes RFC 2429 and updates the H263-1998 and H263-2000 MIME media type in RFC 3555. [STANDARDS-TRACK]

 draft-ietf-avt-rfc2429-bis-09 RFC2429 RFC3555 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4629 RFC4630 Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile R. Housley S. Santesson August 2006 ASCII HTML 6 utf8string printablestring

This document updates the handling of DirectoryString in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, which is published in RFC 3280. The use of UTF8String and PrintableString are the preferred encoding. The requirement for exclusive use of UTF8String after December 31, 2003 is removed. [STANDARDS-TRACK]

 draft-ietf-pkix-cert-utf8-03 RFC5280 RFC3280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4630 RFC4631 Link Management Protocol (LMP) Management Information Base (MIB) M. Dubuc T. Nadeau J. Lang E. McGinnis A. Farrel September 2006 ASCII HTML 83 lmp-mib

This document provides minor corrections to and obsoletes RFC 4327.

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). [STANDARDS-TRACK]

 draft-ietf-ccamp-rfc4327bis-01 RFC4327 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4631 10.17487/RFC4631 RFC4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan V. Fuller T. Li August 2006 ASCII HTML 27 CIDR-STRA global routing state

This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-grow-rfc1519bis-04 RFC1519 BCP0122 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=4632 10.17487/RFC4632 RFC4633 Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists S. Hartman August 2006 ASCII HTML 7

Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managing Internet Engineering Task Force (IETF) mailing lists. This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools for mailing list management while trying to determine what the long-term guidelines should be. This memo defines an Experimental Protocol for the Internet community.

 draft-hartman-mailinglist-experiment-03 RFC8717 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4633 RFC4634 US Secure Hash Algorithms (SHA and HMAC-SHA) D. Eastlake 3rd T. Hansen July 2006 ASCII HTML 108 fips federal information processing standard sha-224 sha-256 sha-384 sha-512

The United States of America has adopted a suite of Secure Hash Algorithms (SHAs), including four beyond SHA-1, as part of a Federal Information Processing Standard (FIPS), specifically SHA-224 (RFC 3874), SHA-256, SHA-384, and SHA-512. The purpose of this document is to make source code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. SHA-1's sample code from RFC 3174 has also been updated to handle input strings of arbitrary bit length. Most of the text herein was adapted by the authors from FIPS 180-2.

Code to perform SHA-based HMACs, with arbitrary bit length text, is also included. This memo provides information for the Internet community.

 draft-eastlake-sha2-02 RFC6234 RFC3174 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4634 10.17487/RFC4634 RFC4635 HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers D. Eastlake 3rd August 2006 ASCII HTML 8 dns resource record rr cryptographic message authentication code cmac

Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code. Currently, identifiers have been specified only for HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) and GSS (Generic Security Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG. [STANDARDS-TRACK]

 draft-ietf-dnsext-tsig-sha-06 RFC8945 RFC2845 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4635 10.17487/RFC4635 RFC4636 Foreign Agent Error Extension for Mobile IPv4 C. Perkins October 2006 ASCII HTML 6 internet protocol

This document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4. Currently, a foreign agent cannot supply status information without destroying the ability for a mobile node to verify authentication data supplied by the home agent. The new extension solves this problem by making a better place for the foreign agent to provide its status information to the mobile node. [STANDARDS-TRACK]

 draft-ietf-mip4-faerr-02 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4636 10.17487/RFC4636 RFC4637 RFC4638 Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) P. Arberg D. Kourkouzelis M. Duckett T. Anschutz J. Moisand September 2006 ASCII HTML 9

The Point-to-Point Protocol over Ethernet (PPPoE), as described in RFC 2516, mandates a maximum negotiated Maximum Receive Unit (MRU) of 1492. This document outlines a solution that relaxes this restriction and allows a maximum negotiated MRU greater than 1492 to minimize fragmentation in next-generation broadband networks. This memo provides information for the Internet community.

 draft-arberg-pppoe-mtu-gt1492-03 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC4638 RFC4639 Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems R. Woundy K. Marez December 2006 ASCII HTML 88 snmp simple network management protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data Over Cable Service Interface Specification (DOCSIS)-compliant Cable Modems and Cable Modem Termination Systems.

This memo obsoletes RFC 2669. [STANDARDS-TRACK]

 draft-ietf-ipcdn-device-mibv2-11 RFC2669 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4639 RFC4640 Problem Statement for bootstrapping Mobile IPv6 (MIPv6) A. Patel Editor G. Giaretta Editor September 2006 ASCII HTML 22 internet protocol version 6 mobile node

A mobile node needs at least the following information: a home address, a home agent address, and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discusses issues involved with how the mobile node can be bootstrapped for Mobile IPv6 (MIPv6) and various potential deployment scenarios for mobile node bootstrapping. This memo provides information for the Internet community.

 draft-ietf-mip6-bootstrap-ps-05 INFORMATIONAL INFORMATIONAL IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4640 10.17487/RFC4640 RFC4641 DNSSEC Operational Practices O. Kolkman R. Gieben September 2006 ASCII HTML 35 dns domain name space security extensions zone administrator DNS-SOC cryptology resource records rrs

This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.

The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.

This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. This memo provides information for the Internet community.

 draft-ietf-dnsop-dnssec-operational-practices-08 RFC2541 RFC6781 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=4641 10.17487/RFC4641 RFC4642 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) K. Murchison J. Vinocur C. Newman October 2006 ASCII HTML 14 encryption single link confidentiality

This memo defines an extension to the Network News Transfer Protocol (NNTP) that allows an NNTP client and server to use Transport Layer Security (TLS). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible. [STANDARDS-TRACK]

 draft-ietf-nntpext-tls-nntp-09 RFC8143 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=4642 10.17487/RFC4642 RFC4643 Network News Transfer Protocol (NNTP) Extension for Authentication J. Vinocur K. Murchison October 2006 ASCII HTML 24 authinfo user/pass authinfo simple authinfo generic sasl simple authentication and security layer

This document defines an extension to the Network News Transfer Protocol (NNTP) that allows a client to indicate an authentication mechanism to the server, to perform an authentication protocol exchange, and optionally to negotiate a security layer for subsequent protocol interactions during the remainder of an NNTP session.

This document updates and formalizes the AUTHINFO USER/PASS authentication method specified in RFC 2980 and deprecates the AUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods. Additionally, this document defines a profile of the Simple Authentication and Security Layer (SASL) for NNTP. [STANDARDS-TRACK]

 draft-ietf-nntpext-authinfo-10 RFC2980 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=4643 10.17487/RFC4643 RFC4644 Network News Transfer Protocol (NNTP) Extension for Streaming Feeds J. Vinocur K. Murchison October 2006 ASCII HTML 14 check takethis mode stream

This memo defines an extension to the Network News Transfer Protocol (NNTP) to provide asynchronous (otherwise known as "streaming") transfer of articles. This allows servers to transfer articles to other servers with much greater efficiency.

This document updates and formalizes the CHECK and TAKETHIS commands specified in RFC 2980 and deprecates the MODE STREAM command. [STANDARDS-TRACK]

 draft-ietf-nntpext-streaming-06 RFC2980 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=4644 10.17487/RFC4644 RFC4645 Initial Language Subtag Registry D. Ewell September 2006 ASCII HTML 7 iana

This memo defined the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only served as a starting point for the registry, its actual contents have been removed before publication to avoid confusion. This memo provides information for the Internet community.

 draft-ietf-ltru-initial-06 INFORMATIONAL INFORMATIONAL IETF app ltru 10.17487/RFC4645 RFC4646 Tags for Identifying Languages A. Phillips M. Davis September 2006 ASCII HTML 59 Lang-Tag

This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ltru-registry-14 RFC3066 RFC5646 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ltru http://www.rfc-editor.org/errata_search.php?rfc=4646 10.17487/RFC4646 RFC4647 Matching of Language Tags A. Phillips Editor M. Davis Editor September 2006 ASCII HTML 20 Lang-Tag

This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 4646, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ltru-matching-15 RFC3066 BCP0047 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ltru 10.17487/RFC4647 RFC4648 The Base16, Base32, and Base64 Data Encodings S. Josefsson October 2006 ASCII HTML 18 schemes data line-feeds alphabets base encoding hex

This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]

 draft-josefsson-rfc3548bis-04 RFC3548 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4648 10.17487/RFC4648 RFC4649 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option B. Volz August 2006 ASCII HTML 6

This memo defines a new Relay Agent Remote-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). This option is the DHCPv6 equivalent for the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified in RFC 3046. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-remoteid-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4649 RFC4650 HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY) M. Euchner September 2006 ASCII HTML 27 Multicast security MIKEY key management Diffie-Hellman key agreement HMAC

This document describes a lightweight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) protocol MIKEY, as defined in RFC 3830. In particular, this variant deploys the classic Diffie-Hellman key agreement protocol for key establishment featuring perfect forward secrecy in conjunction with a keyed hash message authentication code for achieving mutual authentication and message integrity of the key management messages exchanged. This protocol addresses the security and performance constraints of multimedia key management in MIKEY. [STANDARDS-TRACK]

 draft-ietf-msec-mikey-dhhmac-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=4650 10.17487/RFC4650 RFC4651 A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization C. Vogt J. Arkko February 2007 ASCII HTML 31 Mobile IPv6 Route Optimization Enhancement Mobility Handoff IP Address Tests Protected Tunnels Optimistic Behavior Proactive IP Address Tests Concurrent Care-of Address Tests Diverted Routing Credit-Based Authorization Heuristic Monitoring Crypto-Based Identifiers Pre-Configuration Semi-Permanent Security Associations Delegation Mobile Networks Location Privacy

This document describes and evaluates strategies to enhance Mobile IPv6 Route Optimization, on the basis of existing proposals, in order to motivate and guide further research in this context. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This memo provides information for the Internet community.

 draft-irtf-mobopts-ro-enhancements-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC4651 RFC4652 Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements D. Papadimitriou Editor L. Ong J. Sadler S. Shew D. Ward October 2006 ASCII HTML 22 gmpls generalized multiprotocol label switching otn optical transport networks sonet sdh synchronous optical network synchronous digital hierarchy itu-t

The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Networks (OTNs).

This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-ason-routing-eval-03 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4652 RFC4653 Improving the Robustness of TCP to Non-Congestion Events S. Bhandarkar A. L. N. Reddy M. Allman E. Blanton August 2006 ASCII HTML 18 ncr non-congestion robustness transmission control protocol

This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP uses loss as an indication of congestion. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments. However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tcpm-tcp-dcr-07 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=4653 10.17487/RFC4653 RFC4654 TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification J. Widmer M. Handley August 2006 ASCII HTML 32 streaming media multicase ip internet protocol

This document specifies TCP-Friendly Multicast Congestion Control (TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions. TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rmt-bb-tfmcc-07 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=4654 10.17487/RFC4654 RFC4655 A Path Computation Element (PCE)-Based Architecture A. Farrel J.-P. Vasseur J. Ash August 2006 ASCII HTML 40 traffic engineering

Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.

This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.

 draft-ietf-pce-architecture-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4655 RFC4656 A One-way Active Measurement Protocol (OWAMP) S. Shalunov B. Teitelbaum A. Karp J. Boote M. Zekauskas September 2006 ASCII HTML 56 unidirectional characteristics one-way gps cdma

The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements. [STANDARDS-TRACK]

 draft-ietf-ippm-owdp-16 RFC7717 RFC7718 RFC8545 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC4656 RFC4657 Path Computation Element (PCE) Communication Protocol Generic Requirements J. Ash Editor J.L. Le Roux Editor September 2006 ASCII HTML 21 pce architecture pcc path computation client

The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. This memo provides information for the Internet community.

 draft-ietf-pce-comm-protocol-gen-reqs-07 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4657 RFC4658 RFC4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN J. De Clercq D. Ooms M. Carugi F. Le Faucheur September 2006 ASCII HTML 18 service provider border gateway protocol multiprotocol label switching

This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for support of IPv6. In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP".

This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. [STANDARDS-TRACK]

 draft-ietf-l3vpn-bgp-ipv6-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4659 10.17487/RFC4659 RFC4660 Functional Description of Event Notification Filtering H. Khartabil E. Leppanen M. Lonnfors J. Costa-Requena September 2006 ASCII HTML 31 event state subscription presence filter criteria

The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.

This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed. [STANDARDS-TRACK]

 draft-ietf-simple-event-filter-funct-05 RFC6665 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4660 10.17487/RFC4660 RFC4661 An Extensible Markup Language (XML)-Based Format for Event Notification Filtering H. Khartabil E. Leppanen M. Lonnfors J. Costa-Requena September 2006 ASCII HTML 24 event state subscription presence filter criteria

The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered. In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain. This document presents a format in the form of an XML document. [STANDARDS-TRACK]

 draft-ietf-simple-filter-format-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4661 10.17487/RFC4661 RFC4662 A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists A. B. Roach B. Campbell J. Rosenberg August 2006 ASCII HTML 39

This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes. [STANDARDS-TRACK]

 draft-ietf-simple-event-list-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4662 10.17487/RFC4662 RFC4663 Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG D. Harrington September 2006 ASCII HTML 22 management information base

This document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge MIB Working Group to the IEEE 802.1 Working Group, which develops the bridging technology the MIB modules are designed to manage. This memo provides information for the Internet community.

 draft-harrington-8021-mib-transition-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4663 RFC4664 Framework for Layer 2 Virtual Private Networks (L2VPNs) L. Andersson Editor E. Rosen Editor September 2006 ASCII HTML 44

This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. This memo provides information for the Internet community.

 draft-ietf-l2vpn-l2-framework-05 INFORMATIONAL INFORMATIONAL IETF int l2vpn http://www.rfc-editor.org/errata_search.php?rfc=4664 10.17487/RFC4664 RFC4665 Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks W. Augustyn Editor Y. Serbest Editor September 2006 ASCII HTML 32 l2vpn ppvpn virtual private wire service vpws virtual private lan service vpls

This document provides requirements for Layer 2 Provider-Provisioned Virtual Private Networks (L2VPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point-to-point VPNs, referred to as Virtual Private Wire Service (VPWS), as well as multipoint-to-multipoint VPNs, also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from both a customer as well as a service provider perspectives. This memo provides information for the Internet community.

 draft-ietf-l2vpn-requirements-07 INFORMATIONAL INFORMATIONAL IETF int l2vpn 10.17487/RFC4665 RFC4666 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) K. Morneault Editor J. Pastor-Balbas Editor September 2006 ASCII HTML 124 mtp isup sccp sctp stream control tranmission protocol mgc media gateway protocol st signalling gateway

This memo defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database, or between two IP-based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. This document obsoletes RFC 3332. [STANDARDS-TRACK]

 draft-ietf-sigtran-rfc3332bis-06 RFC3332 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=4666 10.17487/RFC4666 RFC4667 Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP) W. Luo September 2006 ASCII HTML 15 L2VPN L2TP L2TPv3 pseudowire forwarder

The Layer 2 Tunneling Protocol (L2TP) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. One of the reference models supported by L2TP describes the use of an L2TP session to connect two Layer 2 circuits attached to a pair of peering L2TP Access Concentrators (LACs), which is a basic form of Layer 2 Virtual Private Network (L2VPN). This document defines the protocol extensions for L2TP to set up different types of L2VPNs in a unified fashion. [STANDARDS-TRACK]

 draft-ietf-l2tpext-l2vpn-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4667 RFC4668 RADIUS Authentication Client MIB for IPv6 D. Nelson August 2006 ASCII HTML 24 management information base security remote access dialin user service RADIUS-AUTH-CLIENT-MIB

This memo defines a set of extensions that instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication clients.

This memo obsoletes RFC 2618 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2618 are carried forward into this document. The memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS-TRACK]

 draft-ietf-radext-rfc2618bis-04 RFC2618 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4668 10.17487/RFC4668 RFC4669 RADIUS Authentication Server MIB for IPv6 D. Nelson August 2006 ASCII HTML 25 management information base security remote access dialin user service RADIUS-AUTH-SERVER-MIB

This memo defines a set of extensions that instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication servers.

This memo obsoletes RFC 2619 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2619 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS-TRACK]

 draft-ietf-radext-rfc2619bis-04 RFC2619 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4669 10.17487/RFC4669 RFC4670 RADIUS Accounting Client MIB for IPv6 D. Nelson August 2006 ASCII HTML 23 management information base security remote access dialin user service RADIUS-ACC-CLIENT-MIB

This memo defines a set of extensions that instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting clients.

This memo obsoletes RFC 2620 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2620 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community.

 draft-ietf-radext-rfc2620bis-04 RFC2620 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4670 10.17487/RFC4670 RFC4671 RADIUS Accounting Server MIB for IPv6 D. Nelson August 2006 ASCII HTML 24 management information base security remote access dialin user service RADIUS-ACC-SERVER-MIB

This memo defines a set of extensions that instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting servers.

This memo obsoletes RFC 2621 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2621 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community.

 draft-ietf-radext-rfc2621bis-04 RFC2621 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4671 10.17487/RFC4671 RFC4672 RADIUS Dynamic Authorization Client MIB S. De Cnodder N. Jonnala M. Chiba September 2006 ASCII HTML 24 remote authentication dial-in user service dac dynamic authorization client RADIUS-DYNAUTH-CLIENT-MIB DEFINITIONS management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial-In User Service (RADIUS) (RFC2865) Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576. This memo provides information for the Internet community.

 draft-ietf-radext-dynauth-client-mib-06 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4672 10.17487/RFC4672 RFC4673 RADIUS Dynamic Authorization Server MIB S. De Cnodder N. Jonnala M. Chiba September 2006 ASCII HTML 24 management information base remote authentication dial-in user service RADIUS-DYNAUTH-SERVER-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial-In User Service (RADIUS) (RFC 2865) Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576. This memo provides information for the Internet community.

 draft-ietf-radext-dynauth-server-mib-06 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4673 10.17487/RFC4673 RFC4674 Requirements for Path Computation Element (PCE) Discovery J.L. Le Roux Editor October 2006 ASCII HTML 19 path computation client pcc

This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements. This memo provides information for the Internet community.

 draft-ietf-pce-discovery-reqs-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4674 RFC4675 RADIUS Attributes for Virtual LAN and Priority Support P. Congdon M. Sanchez B. Aboba September 2006 ASCII HTML 15 remote authentication dial-in user service local area network

This document proposes additional Remote Authentication Dial-In User Service (RADIUS) attributes for dynamic Virtual LAN assignment and prioritization, for use in provisioning of access to IEEE 802 local area networks. These attributes are usable within either RADIUS or Diameter. [STANDARDS-TRACK]

 draft-ietf-radext-vlan-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4675 10.17487/RFC4675 RFC4676 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information H. Schulzrinne October 2006 ASCII HTML 19 lci local configuration information

This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. [STANDARDS-TRACK]

 draft-ietf-geopriv-dhcp-civil-09 RFC4776 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=4676 10.17487/RFC4676 RFC4677 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force P. Hoffman S. Harris September 2006 ASCII HTML 50 meeting

This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. This memo provides information for the Internet community.

 draft-hoffman-taobis-08 RFC3160 RFC6722 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4677 10.17487/RFC4677 RFC4678 Server/Application State Protocol v1 A. Bivens September 2006 ASCII HTML 48 sasp server/application state protocol

Entities responsible for distributing work across a group of systems traditionally do not know a great deal about the ability of the applications on those systems to complete the work in a satisfactory fashion. Workload management systems traditionally know a great deal about the health of applications, but have little control over the rate in which these applications receive work. The Server/Application State Protocol (SASP) provides a mechanism for load balancers and workload management systems to communicate better ways of distributing the existing workload to the group members. This memo provides information for the Internet community.

 draft-bivens-sasp-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4678 10.17487/RFC4678 RFC4679 DSL Forum Vendor-Specific RADIUS Attributes V. Mammoliti G. Zorn P. Arberg R. Rennison September 2006 ASCII HTML 25 remote authentication dial-in user service vsa dsl digital subscriber line

This document describes the set of Remote Authentication Dial-In User Service Vendor-Specific Attributes (RADIUS VSAs) defined by the DSL Forum.

These attributes are designed to transport Digital Subscriber Line (DSL) information that is not supported by the standard RADIUS attribute set. It is expected that this document will be updated if and when the DSL Forum defines additional vendor-specific attributes, since its primary purpose is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. This memo provides information for the Internet community.

 draft-mammoliti-radius-dsl-vsa-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4679 10.17487/RFC4679 RFC4680 TLS Handshake Message for Supplemental Data S. Santesson October 2006 ASCII HTML 9 transport layer security

This specification defines a TLS handshake message for exchange of supplemental application data. TLS hello message extensions are used to determine which supplemental data types are supported by both the TLS client and the TLS server. Then, the supplemental data handshake message is used to exchange the data. Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types. [STANDARDS-TRACK]

 draft-santesson-tls-supp-02 RFC4346 RFC8447 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4680 RFC4681 TLS User Mapping Extension S. Santesson A. Medvinsky J. Ball October 2006 ASCII HTML 11 transport layer security handshake message upndomainhint

This document specifies a TLS extension that enables clients to send generic user mapping hints in a supplemental data handshake message defined in RFC 4680. One such mapping hint is defined in an informative section, the UpnDomainHint, which may be used by a server to locate a user in a directory database. Other mapping hints may be defined in other documents in the future. [STANDARDS-TRACK]

 draft-santesson-tls-ume-07 RFC4346 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4681 RFC4682 Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices E. Nechamkin J-F. Mule December 2006 ASCII HTML 60 mib snmp simple network management protocol PKTC-IETF-MTA-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]

 draft-ietf-ipcdn-pktc-mtamib-09 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4682 RFC4683 Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) J. Park J. Lee H. Lee S. Park T. Polk October 2006 ASCII HTML 20 subjectaltname privacy-sensitive identifiers pepsi

This document defines the Subject Identification Method (SIM) for including a privacy-sensitive identifier in the subjectAltName extension of a certificate.

The SIM is an optional feature that may be used by relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. [STANDARDS-TRACK]

 draft-ietf-pkix-sim-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4683 10.17487/RFC4683 RFC4684 Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) P. Marques R. Bonica L. Fang L. Martini R. Raszuk K. Patel J. Guichard November 2006 ASCII HTML 14 mp-bgp bgp speakers route target

This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates RFC 4364. [STANDARDS-TRACK]

 draft-ietf-l3vpn-rt-constrain-02 RFC4364 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4684 10.17487/RFC4684 RFC4685 Atom Threading Extensions J. Snell September 2006 ASCII HTML 12 atom syndication format extension threading syndication

This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format. [STANDARDS-TRACK]

 draft-snell-atompub-feed-thread-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4685 RFC4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) J. Fenton September 2006 ASCII HTML 29 email attack authentication signature ssp

This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail. It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks. This memo provides information for the Internet community.

 draft-ietf-dkim-threats-03 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC4686 RFC4687 Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks S. Yasukawa A. Farrel D. King T. Nadeau September 2006 ASCII HTML 14 multiprotocol label switching pwmp lsp p2mp mpls lsp

Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical.

For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects are important because such defects not only may affect the fundamentals of an MPLS network, but also may impact service level specification commitments for customers of their network.

This document describes requirements for data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs. This memo provides information for the Internet community.

 draft-ietf-mpls-p2mp-oam-reqs-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4687 RFC4688 A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D S. Rushing October 2006 ASCII HTML 8

This document describes a Uniform Resource Name (URN) namespace for naming persistent resources defined by Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D. This memo provides information for the Internet community.

 draft-rushing-s1000d-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4688 RFC4689 Terminology for Benchmarking Network-layer Traffic Control Mechanisms S. Poretsky J. Perser S. Erramilli S. Khurana October 2006 ASCII HTML 34 packet classification

This document describes terminology for the benchmarking of devices that implement traffic control using packet classification based on defined criteria. The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control mechanisms. Rules for packet classification can be based on any field in the IP header, such as the Differentiated Services Code Point (DSCP), or any field in the packet payload, such as port number. This memo provides information for the Internet community.

 draft-ietf-bmwg-dsmterm-13 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4689 RFC4690 Review and Recommendations for Internationalized Domain Names (IDNs) J. Klensin P. Faltstrom C. Karp IAB September 2006 ASCII HTML 37 dns domain namespace idna internationalizing domain names in applications

This note describes issues raised by the deployment and use of Internationalized Domain Names. It describes problems both at the time of registration and for use of those names in the DNS. It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for the Internationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed. This memo provides information for the Internet community.

 draft-iab-idn-nextsteps-06 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4690 10.17487/RFC4690 RFC4691 Guidelines for Acting as an IETF Liaison to Another Organization L. Andersson Editor October 2006 ASCII HTML 14 internet engineering task force sdo standards development organization consortium industrial forum

Whenever the IETF decides to enter into a liaison relationship with another organization, such as a Standards Development Organization (SDO), a consortium, or an industrial forum, a liaison manager is appointed. The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052. This document expands on the role of liaison managers and liaison representatives, giving guidelines on their mandate and the expectations, tasks, and responsibilities placed on them. This memo provides information for the Internet community.

 draft-iab-liaison-guidelines-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4691 RFC4692 Considerations on the IPv6 Host Density Metric G. Huston October 2006 ASCII HTML 17 internet protocol version 6 ipv6 unicast address blocks

This memo provides an analysis of the Host Density metric as it is currently used to guide registry allocations of IPv6 unicast address blocks. This document contrasts the address efficiency as currently adopted in the allocation of IPv4 network addresses and that used by the IPv6 protocol. Note that for large allocations there are very significant variations in the target efficiency metric between the two approaches. This memo provides information for the Internet community.

 draft-huston-hd-metric-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4692 RFC4693 IETF Operational Notes H. Alvestrand October 2006 ASCII HTML 10 ION

This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than Internet-Drafts, and with more clear handling procedures than a random Web page.

It proposes to establish this series as an RFC 3933 process experiment. This memo defines an Experimental Protocol for the Internet community.

 draft-alvestrand-ipod-03 RFC6393 HISTORIC EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4693 RFC4694 Number Portability Parameters for the "tel" URI J. Yu October 2006 ASCII HTML 15 uniform resource identifier np

This document defines five parameters in the "tel" Uniform Resource Identifier (URI) to carry the number portability (NP)-related information. Those parameters can be passed to the next-hop network node after an NP database dip has been performed. [STANDARDS-TRACK]

 draft-ietf-iptel-tel-np-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC4694 RFC4695 RTP Payload Format for MIDI J. Lazzaro J. Wawrzynek November 2006 ASCII HTML 169 asc content streaming DLS 2 General MIDI MIDI MIDI file MIDI file streaming MIDI light control MIDI rendering MIDI ringtone MIDI streaming MIDI sequencer MIDI time code MIDI timecode MIDI Manufacturers Association MMA mpeg4-generic MPEG 4 MPEG 4 Structured Audio MPEG 4 Synthetic Coding MTC musical notes network musical performance recovery journal Show Control sonification ringtone rtp-midi RTP RTP MIDI SMPTE time code SMPTE timecode Standard MIDI Files XMF

This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-midi-format-15 RFC6295 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4695 10.17487/RFC4695 RFC4696 An Implementation Guide for RTP MIDI J. Lazzaro J. Wawrzynek November 2006 ASCII HTML 38 checkpoint packet checkpoint history guard packets jitter keep-alive packets MIDI musical telepresence network musical performance NMP receiving algorithm recovery journal recovery journal receiving structure recovery journal sending structure RTP RTP MIDI queuing MIDI sending algorithm sending MIDI telepresence

This memo offers non-normative implementation guidance for the Real-time Protocol (RTP) MIDI (Musical Instrument Digital Interface) payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room. Underlying the performances are RTP MIDI sessions over unicast UDP. Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail. Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-midi-guidelines-15 INFORMATIONAL INFORMATIONAL IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4696 10.17487/RFC4696 RFC4697 Observed DNS Resolution Misbehavior M. Larson P. Barber October 2006 ASCII HTML 18 domain name system tld top level domain

This memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsop-bad-dns-res-06 BCP0123 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC4697 RFC4698 IRIS: An Address Registry (areg) Type for the Internet Registry Information Service E. Gunduz A. Newton S. Kerr October 2006 ASCII HTML 48 ip address autonomous system number internet protocol address

This document describes an IRIS registry schema for IP address and Autonomous System Number information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by Internet Protocol address registries. [STANDARDS-TRACK]

 draft-ietf-crisp-iris-areg-15 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4698 10.17487/RFC4698 RFC4699 RFC4700 RFC4701 A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) M. Stapp T. Lemon A. Gustafsson October 2006 ASCII HTML 12 dns fqdn fully qualified domain name

It is possible for Dynamic Host Configuration Protocol (DHCP) clients to attempt to update the same DNS Fully Qualified Domain Name (FQDN) or to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, RFC 4703 proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct Resource Record (RR) type for this purpose for use by DHCP clients and servers: the "DHCID" RR. [STANDARDS-TRACK]

 draft-ietf-dnsext-dhcid-rr-13 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4701 10.17487/RFC4701 RFC4702 The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option M. Stapp B. Volz Y. Rekhter October 2006 ASCII HTML 17 dhcpv4 dns rr

This document describes a Dynamic Host Configuration Protocol for IPv4 (DHCPv4) option that can be used to exchange information about a DHCPv4 client's fully qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. [STANDARDS-TRACK]

 draft-ietf-dhc-fqdn-option-13 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4702 RFC4703 Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients M. Stapp B. Volz October 2006 ASCII HTML 13 dynamic assignment dns dhcid dns rr

The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names. To maintain accurate name-to-IP-address and IP-address-to-name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names (FQDNs) require updates to the DNS. This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients and servers, and it describes a strategy for the use of the DHCID DNS resource record (RR) in resolving those conflicts. [STANDARDS-TRACK]

 draft-ietf-dhc-ddns-resolution-12 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4703 RFC4704 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option B. Volz October 2006 ASCII HTML 15 dns rr

This document specifies a new Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option that can be used to exchange information about a DHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-fqdn-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4704 RFC4705 GigaBeam High-Speed Radio Link Encryption R. Housley A. Corry October 2006 ASCII HTML 15 key management wifiber radio link

This document describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio link products. The security solution is documented in the hope that other wireless product development efforts will include comparable capabilities. This memo provides information for the Internet community.

 draft-housley-gigabeam-radio-link-encrypt-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4705 10.17487/RFC4705 RFC4706 Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) M. Morgenstern M. Dodge S. Baillie U. Bonollo November 2006 ASCII HTML 167 mib management information base adsl2+ ADSL2-LINE-TC-MIB ADSL2-LINE-MIB

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Asymmetric Digital Subscriber Line" family of interface types: ADSL, ADSL2, ADSL2+, and their variants. [STANDARDS-TRACK]

 draft-ietf-adslmib-adsl2-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC4706 RFC4707 Netnews Administration System (NAS) P. Grau V. Heinau H. Schlichting R. Schuettler October 2006 ASCII HTML 49 news servers news administrator news reader

The Netnews Administration System (NAS) is a framework to simplify the administration and usage of network news (also known as Netnews) on the Internet. Data for the administration of newsgroups and hierarchies are kept in a distributed hierarchical database and are available through a client-server protocol.

The database is accessible by news servers, news administrators, and news readers. News servers can update their configuration automatically; administrators are able to get the data manually. News reader programs are able to get certain information from an NAS server, automatically or at a user's discretion, which provides detailed information about groups and hierarchies to the user.

NAS is usable in coexistence with the current, established process of control messages; an unwanted interference is impossible. Furthermore, NAS is able to reflect the somewhat chaotic structure of Usenet in a hierarchical database. NAS can be used without modification of existing news relay, news server, or news reader software; however, some tasks will be better accomplished with NAS-compliant software. This memo defines an Experimental Protocol for the Internet community.

 draft-dfncis-netnews-admin-sys-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4707 10.17487/RFC4707 RFC4708 CellML Media Type A. Miller October 2006 ASCII HTML 7 media format mathematical model mathematical modelling mathematical modeling content MathML markup languages bioengineering biology

This document standardises a new media type -- application/cellml+xml -- for use in exchanging mathematical models represented in a CellML Umbrella 1.0 compliant markup language. This memo provides information for the Internet community.

 draft-miller-media-type-cellml-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4708 RFC4709 Mounting Web Distributed Authoring and Versioning (WebDAV) Servers J. Reschke October 2006 ASCII HTML 15 drag-and-drop

In current Web browsers, there is no uniform way to specify that a user clicking on a link will be presented with an editable view of a Web Distinguished Authoring and Versioning (WebDAV) server. For example, it is frequently desirable to be able to click on a link and have this link open a window that can handle drag-and-drop interaction with the resources of a WebDAV server.

This document specifies a mechanism and a document format that enables WebDAV servers to send "mounting" information to a WebDAV client. The mechanism is designed to work on any platform and with any combination of browser and WebDAV client, relying solely on the well-understood dispatch of documents through their MIME type. This memo provides information for the Internet community.

 draft-reschke-webdav-mount-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4709 RFC4710 Real-time Application Quality-of-Service Monitoring (RAQMON) Framework A. Siddiqui D. Romascanu E. Golovinsky October 2006 ASCII HTML 36 internet protocol end-devices qos quality of service snmp simple network management protocol

There is a need to monitor end-devices such as IP phones, pagers, Instant Messaging clients, mobile phones, and various other handheld computing devices. This memo extends the remote network monitoring (RMON) family of specifications to allow real-time quality-of-service (QoS) monitoring of various applications that run on these devices and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP). This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time QoS monitoring of applications. [STANDARDS-TRACK]

 draft-ietf-rmonmib-raqmon-framework-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4710 RFC4711 Real-time Application Quality-of-Service Monitoring (RAQMON) MIB A. Siddiqui D. Romascanu E. Golovinsky October 2006 ASCII HTML 38 management information base remote monitoring mib qos RAQMON-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB, RFC 2819. In particular, it describes managed objects used for real-time application Quality of Service (QoS) monitoring. [STANDARDS-TRACK]

 draft-ietf-rmonmib-raqmon-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4711 RFC4712 Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) A. Siddiqui D. Romascanu E. Golovinsky M. Rahman Y. Kim October 2006 ASCII HTML 48 mib management information base snmp simple network management protocol rds raqmon data source qos RAQMON-RDS-MIB

This memo specifies two transport mappings of the \%Real-Time Application Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the Simple Network Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). [STANDARDS-TRACK]

 draft-ietf-rmonmib-raqmon-pdu-14 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4712 RFC4713 Registration and Administration Recommendations for Chinese Domain Names X. Lee W. Mao E. Chen N. Hsu J. Klensin October 2006 ASCII HTML 9 cdn sc simplified chinese tc traditional chinese

Many Chinese characters in common use have variants, which makes most of the Chinese Domain Names (CDNs) have at least two different forms. The equivalence between Simplified Chinese (SC) and Traditional Chinese (TC) characters is very important for CDN registration. This memo builds on the basic concepts, general guidelines, and framework of RFC 3743 to specify proposed registration and administration procedures for Chinese domain names. The document provides the information needed for understanding and using the tables defined in the IANA table registrations for Simplified and Traditional Chinese. This memo provides information for the Internet community.

 draft-xdlee-idn-cdnadmin-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4713 RFC4714 Requirements for IETF Technical Publication Service A. Mankin S. Hayes October 2006 ASCII HTML 24 internet engineering task force

The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation. Technical publication is the process by which that output is disseminated to the community at large. As such, it is important to understand the requirements on the publication process. This memo provides information for the Internet community.

 draft-mankin-pub-req-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4714 RFC4715 The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI M. Munakata S. Schubert T. Ohba November 2006 ASCII HTML 14 uniform resource identifier isup isdn user part

Without a tel URI parameter to carry an encoding type of Integrated Services Digital Network (ISDN) subaddress, interworking between ISDN User Part (ISUP) network and a Session Initiation Protocol (SIP) network is impossible in some cases. To solve this problem, this document specifies a new optional tel URI parameter to carry the encoding type of ISDN subaddress. This memo provides information for the Internet community.

 draft-munakata-iptel-isub-type-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4715 RFC4716 The Secure Shell (SSH) Public Key File Format J. Galbraith R. Thayer November 2006 ASCII HTML 10

This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell (SSH) implementations.

In addition, this document defines a standard textual representation for SSH public key fingerprints. This memo provides information for the Internet community.

 draft-ietf-secsh-publickeyfile-13 INFORMATIONAL INFORMATIONAL IETF sec secsh 10.17487/RFC4716 RFC4717 Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks L. Martini J. Jayakumar M. Bocci N. El-Aawar J. Brayley G. Koleyni December 2006 ASCII HTML 40 pw pseudowire multiprotocol label switching

An Asynchronous Transfer Mode (ATM) Pseudowire (PW) is used to carry ATM cells over an MPLS network. This enables service providers to offer "emulated" ATM services over existing MPLS networks. This document specifies methods for the encapsulation of ATM cells within a pseudowire. It also specifies the procedures for using a PW to provide an ATM service. [STANDARDS-TRACK]

 draft-ietf-pwe3-atm-encap-11 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4717 10.17487/RFC4717 RFC4718 IKEv2 Clarifications and Implementation Guidelines P. Eronen P. Hoffman October 2006 ASCII HTML 58 internet key exchange

This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations. This memo provides information for the Internet community.

 draft-eronen-ipsec-ikev2-clarifications-09 RFC5996 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4718 10.17487/RFC4718 RFC4719 Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3) R. Aggarwal Editor M. Townsley Editor M. Dos Santos Editor November 2006 ASCII HTML 14 port-to-port vlan

This document describes the transport of Ethernet frames over the Layer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network. [STANDARDS-TRACK]

 draft-ietf-l2tpext-pwe3-ethernet-09 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext http://www.rfc-editor.org/errata_search.php?rfc=4719 10.17487/RFC4719 RFC4720 Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention A. Malis D. Allan N. Del Regno November 2006 ASCII HTML 9 fcs

This document defines a mechanism for preserving Frame Check Sequence (FCS) through Ethernet, Frame Relay, High-Level Data Link Control (HDLC), and PPP pseudowires. [STANDARDS-TRACK]

 draft-ietf-pwe3-fcs-retention-04 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4720 RFC4721 Mobile IPv4 Challenge/Response Extensions (Revised) C. Perkins P. Calhoun J. Bharatia January 2007 ASCII HTML 26 chap

Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, that extension does not provide the foreign agent any direct guarantee that the protocol is protected from replays and does not allow for the use of existing techniques (such as Challenge Handshake Authentication Protocol (CHAP)) for authenticating portable computer devices.

In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node.

Furthermore, this document updates RFC 3344 by including a new authentication extension called the Mobile-Authentication, Authorization, and Accounting (AAA) Authentication extension. This new extension is provided so that a mobile node can supply credentials for authorization, using commonly available AAA infrastructure elements. This authorization-enabling extension MAY co-exist in the same Registration Request with authentication extensions defined for Mobile IP Registration by RFC 3344. This document obsoletes RFC 3012. [STANDARDS-TRACK]

 draft-ietf-mip4-rfc3012bis-05 RFC3012 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4721 10.17487/RFC4721 RFC4722 Media Server Control Markup Language (MSCML) and Protocol J. Van Dyke E. Burger Editor A. Spitzer November 2006 ASCII HTML 81 sip ivr interactive voice response

Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. This memo provides information for the Internet community.

 draft-vandyke-mscml-09 RFC5022 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4722 RFC4723 Registration of Media Type audio/mobile-xmf T. Kosonen T. White December 2006 ASCII HTML 8 mma midi manufacturers association association of musical electronices industry amei MIDI Musical Instrument Digital Interface

The MIDI Manufacturers Association (MMA) and the Association of Musical Electronics Industry (AMEI) have produced the Mobile XMF standard, which was developed particularly for mobile MIDI applications. Mobile XMF is a very compact media type providing high-quality synthetic audio content for music downloading and messaging applications that require MIME registration. This document registers the media type audio/mobile-xmf. This memo provides information for the Internet community.

 draft-kosonen-mobile-xmf-mediatype-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4723 RFC4724 Graceful Restart Mechanism for BGP S. Sangli E. Chen R. Fernando J. Scudder Y. Rekhter January 2007 ASCII HTML 15 border gateway protocol end-of-rib bgp restart

This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment.

The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). [STANDARDS-TRACK]

 draft-ietf-idr-restart-13 RFC8538 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4724 10.17487/RFC4724 RFC4725 ENUM Validation Architecture A. Mayrhofer B. Hoeneisen November 2006 ASCII HTML 17 E.164 Registry Registrar Registrant Assignee

An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high-level architecture for an ENUM validation infrastructure. This memo provides information for the Internet community.

 draft-ietf-enum-validation-arch-04 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC4725 RFC4726 A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering A. Farrel J.-P. Vasseur A. Ayyangar November 2006 ASCII HTML 22 mpls mpls-te te lsp label switched path

This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks.

For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). This memo provides information for the Internet community.

 draft-ietf-ccamp-inter-domain-framework-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4726 RFC4727 Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers B. Fenner November 2006 ASCII HTML 11

When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents. [STANDARDS-TRACK]

 draft-fenner-iana-exp-2780-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4727 RFC4728 The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 D. Johnson Y. Hu D. Maltz February 2007 ASCII HTML 107 route discovery route maintenance

The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. The protocol is composed of the two main mechanisms of "Route Discovery" and "Route Maintenance", which work together to allow nodes to discover and maintain routes to arbitrary destinations in the ad hoc network. All aspects of the protocol operate entirely on demand, allowing the routing packet overhead of DSR to scale automatically to only what is needed to react to changes in the routes currently in use. The protocol allows multiple routes to any destination and allows each sender to select and control the routes used in routing its packets, for example, for use in load balancing or for increased robustness. Other advantages of the DSR protocol include easily guaranteed loop-free routing, operation in networks containing unidirectional links, use of only "soft state" in routing, and very rapid recovery when routes in the network change. The DSR protocol is designed mainly for mobile ad hoc networks of up to about two hundred nodes and is designed to work well even with very high rates of mobility. This document specifies the operation of the DSR protocol for routing unicast IPv4 packets. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-manet-dsr-10 EXPERIMENTAL EXPERIMENTAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=4728 10.17487/RFC4728 RFC4729 A Uniform Resource Name (URN) Namespace for the Near Field Communication (NFC) Forum M. Abel November 2006 ASCII HTML 7 forum technical committee

This document describes the Namespace Identifier (NID) for Uniform Resource Name (URN) resources published by the Near Field Communication (NFC) Forum. The NFC Forum defines and manages resources that utilize this URN identification model. Management activities for these and other resource types are provided by the NFC Forum Technical Committee. This memo provides information for the Internet community.

 draft-abel-nfc-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4729 RFC4730 A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML) E. Burger M. Dolly November 2006 ASCII HTML 56 ua user agent dtmf dual tone multi-frequency

This document describes a SIP Event Package "kpml" that enables monitoring of Dual Tone Multi-Frequency (DTMF) signals and uses Extensible Markup Language (XML) documents referred to as Key Press Markup Language (KPML). The kpml Event Package may be used to support applications consistent with the principles defined in the document titled "A Framework for Application Interaction in the Session Initiation Protocol (SIP)". The event package uses SUBSCRIBE messages and allows for XML documents that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA). The event package uses NOTIFY messages and allows for XML documents to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server. The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers). [STANDARDS-TRACK]

 draft-ietf-sipping-kpml-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4730 10.17487/RFC4730 RFC4731 IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned A. Melnikov D. Cridland November 2006 ASCII HTML 6 uid search uid

This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands with several result options, which can control what kind of information is returned. The following result options are defined: minimal value, maximal value, all found messages, and number of found messages. [STANDARDS-TRACK]

 draft-melnikov-imap-search-ret-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4731 RFC4732 Internet Denial-of-Service Considerations M. Handley Editor E. Rescorla Editor IAB December 2006 ASCII HTML 38 dos

This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. This memo provides information for the Internet community.

 draft-iab-dos-05 RFC8996 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4732 RFC4733 RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals H. Schulzrinne T. Taylor December 2006 ASCII HTML 49 real-time application protocol DTMF dual-tone multifrequency

This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833.

This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.

This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. [STANDARDS-TRACK]

 draft-ietf-avt-rfc2833bis-15 RFC2833 RFC4734 RFC5244 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4733 10.17487/RFC4733 RFC4734 Definition of Events for Modem, Fax, and Text Telephony Signals H. Schulzrinne T. Taylor December 2006 ASCII HTML 47 real-time application protocol DTMF dual-tone multifrequency

This memo updates RFC 4733 to add event codes for modem, fax, and text telephony signals when carried in the telephony event RTP payload. It supersedes the assignment of event codes for this purpose in RFC 2833, and therefore obsoletes that part of RFC 2833. [STANDARDS-TRACK]

 draft-ietf-avt-rfc2833bisdata-08 RFC2833 RFC4733 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4734 RFC4735 Example Media Types for Use in Documentation T. Taylor October 2006 ASCII HTML 6 media type example

This document is registration for the 'example' media type and 'example' subtypes within the standards tree. The 'example/*' and '*/example' media types are defined for documentation purposes only. [STANDARDS-TRACK]

 draft-taylor-types-example-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4735 RFC4736 Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) JP. Vasseur Editor Y. Ikejiri R. Zhang November 2006 ASCII HTML 14 rsvp-te te lsp path

This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with Resource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end Label Switching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path) or that the TE LSP must be reoptimized (because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (Interior Gateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. This memo provides information for the Internet community.

 draft-ietf-ccamp-loose-path-reopt-02 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4736 RFC4737 Packet Reordering Metrics A. Morton L. Ciavattone G. Ramachandran S. Shalunov J. Perser November 2006 ASCII HTML 45 ippm

This memo defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design. Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric oriented toward assessment of reordering effects on TCP. Several examples of evaluation using the various sample metrics are included. An appendix gives extended definitions for evaluating order with packet fragmentation. [STANDARDS-TRACK]

 draft-ietf-ippm-reordering-13 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC4737 RFC4738 MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) D. Ignjatic L. Dondeti F. Audet P. Lin November 2006 ASCII HTML 19 MIKEY SRTP key management group key distribution RSA-R

The Multimedia Internet Keying (MIKEY) specification describes several modes of key distribution solution that address multimedia scenarios (e.g., SIP calls and Real Time Streaming Protocol (RTSP) sessions) using pre-shared keys, public keys, and optionally a Diffie-Hellman key exchange. In the public-key mode, the Initiator encrypts a random key with the Responder's public key and sends it to the Responder. In many communication scenarios, the Initiator may not know the Responder's public key, or in some cases the Responder's ID (e.g., call forwarding) in advance. We propose a new MIKEY mode that works well in such scenarios. This mode also enhances the group key management support in MIKEY; it supports member-initiated group key download (in contrast to group manager pushing the group keys to all members). This document updates RFC 3830 with the RSA-R mode. [STANDARDS-TRACK]

 draft-ietf-msec-mikey-rsa-r-07 RFC3830 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4738 RFC4739 Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol P. Eronen J. Korhonen November 2006 ASCII HTML 11

The Internet Key Exchange (IKEv2) protocol supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and Extensible Authentication Protocol (EAP) methods. Currently, each endpoint uses only one of these mechanisms to authenticate itself. This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user. When backend authentication servers are used, they can belong to different administrative domains, such as the network access provider and the service provider. This memo defines an Experimental Protocol for the Internet community.

 draft-eronen-ipsec-ikev2-multiple-auth-02 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4739 RFC4740 Diameter Session Initiation Protocol (SIP) Application M. Garcia-Martin Editor M. Belinchon M. Pallares-Lopez C. Canales-Valenzuela K. Tammi November 2006 ASCII HTML 72 authentication authorization diameter client

This document specifies the Diameter Session Initiation Protocol (SIP) application. This is a Diameter application that allows a Diameter client to request authentication and authorization information. This application is designed to be used in conjunction with SIP and provides a Diameter client co-located with a SIP server, with the ability to request the authentication of users and authorization of SIP resources usage from a Diameter server. [STANDARDS-TRACK]

 draft-ietf-aaa-diameter-sip-app-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4740 10.17487/RFC4740 RFC4741 NETCONF Configuration Protocol R. Enns Editor December 2006 ASCII HTML 95 network configuration protocol network device xml extensible markup language rpc remote procedure call

The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. [STANDARDS-TRACK]

 draft-ietf-netconf-prot-12 RFC6241 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=4741 10.17487/RFC4741 RFC4742 Using the NETCONF Configuration Protocol over Secure SHell (SSH) M. Wasserman T. Goddard December 2006 ASCII HTML 10 network configuration protocol

This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. [STANDARDS-TRACK]

 draft-ietf-netconf-ssh-06 RFC6242 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=4742 10.17487/RFC4742 RFC4743 Using NETCONF over the Simple Object Access Protocol (SOAP) T. Goddard December 2006 ASCII HTML 20 NETCONF XMLCONF SOAP device managment XML Extensible Markup Language

The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. Web Services is one such environment and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange Extensible Protocol (BEEP) bindings for NETCONF. [STANDARDS-TRACK]

 draft-ietf-netconf-soap-08 RFC8996 HISTORIC PROPOSED STANDARD IETF ops netconf 10.17487/RFC4743 RFC4744 Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) E. Lear K. Crozier December 2006 ASCII HTML 10 XML Configuration Network Management Extensible Markup Language

This document specifies an application protocol mapping for the Network Configuration Protocol (NETCONF) over the Blocks Extensible Exchange Protocol (BEEP). [STANDARDS-TRACK]

 draft-ietf-netconf-beep-10 RFC8996 HISTORIC PROPOSED STANDARD IETF ops netconf 10.17487/RFC4744 RFC4745 Common Policy: A Document Format for Expressing Privacy Preferences H. Schulzrinne H. Tschofenig J. Morris J. Cuellar J. Polk J. Rosenberg February 2007 ASCII HTML 32 rules conditions permissions

This document defines a framework for authorization policies controlling access to application-specific data. This framework combines common location- and presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains. [STANDARDS-TRACK]

 draft-ietf-geopriv-common-policy-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=4745 10.17487/RFC4745 RFC4746 Extensible Authentication Protocol (EAP) Password Authenticated Exchange T. Clancy W. Arbaugh November 2006 ASCII HTML 30 EAP-PAX password authenticated exchange key exchange

This document defines an Extensible Authentication Protocol (EAP) method called EAP-PAX (Password Authenticated eXchange). This method is a lightweight shared-key authentication protocol with optional support for key provisioning, key management, identity protection, and authenticated data exchange. This memo provides information for the Internet community.

 draft-clancy-eap-pax-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4746 10.17487/RFC4746 RFC4747 The Virtual Fabrics MIB S. Kipp G. Ramkumar K. McCloghrie November 2006 ASCII HTML 20 management information base T11-FC-VIRTUAL-FABRIC-MIB fibre channel network virtual fabric

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Virtual Fabrics function. [STANDARDS-TRACK]

 draft-ietf-imss-fc-vf-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4747 10.17487/RFC4747 RFC4748 RFC 3978 Update to Recognize the IETF Trust S. Bradner Editor October 2006 ASCII HTML 4 ipr intellectual property rights copyright

This document updates RFC 3978 "IETF Rights in Contributions" to recognize that the IETF Trust is now the proper custodian of all IETF-related intellectual property rights.

This document does not constrain how the IETF Trust exercises those rights. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ipr-ietf-trust-update-03 RFC5378 RFC3978 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC4748 RFC4749 RTP Payload Format for the G.729.1 Audio Codec A. Sollaud October 2006 ASCII HTML 14 real-time transport protocol itu-t international telecommunication union

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.729.1 audio codec. A media type registration is included for this payload format. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-g729-scal-wb-ext-07 RFC5459 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4749 RFC4750 OSPF Version 2 Management Information Base D. Joyal Editor P. Galecki Editor S. Giacalone Editor R. Coltun F. Baker December 2006 ASCII HTML 121 OSPF-MIB Open Shortest Path First SPF MIB routing network management mib OSPF-MIB OSPF-TRAP-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing version 2 of the Open Shortest Path First Routing Protocol. Version 2 of the OSPF protocol is specific to the IPv4 address family. Version 3 of the OSPF protocol is specific to the IPv6 address family.

This memo obsoletes RFC 1850; however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1850 are explained in Appendix B. [STANDARDS-TRACK]

 draft-ietf-ospf-mib-update-11 RFC1850 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=4750 10.17487/RFC4750 RFC4751 RFC4752 The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism A. Melnikov Editor November 2006 ASCII HTML 10 SASL encryption protocol specific

The Simple Authentication and Security Layer (SASL) is a framework for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface (GSS-API) Kerberos V5 in the SASL.

This document replaces Section 7.2 of RFC 2222, the definition of the "GSSAPI" SASL mechanism. This document, together with RFC 4422, obsoletes RFC 2222. [STANDARDS-TRACK]

 draft-ietf-sasl-gssapi-08 RFC2222 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=4752 10.17487/RFC4752 RFC4753 ECP Groups For IKE and IKEv2 D. Fu J. Solinas January 2007 ASCII HTML 16 elliptic curve Diffie-Hellman suite b nist curve

This document describes new Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups. Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic. These new groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This memo provides information for the Internet community.

 draft-ietf-ipsec-ike-ecp-groups-03 RFC5903 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4753 10.17487/RFC4753 RFC4754 IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) D. Fu J. Solinas January 2007 ASCII HTML 15 suite b

This document describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols. ECDSA may provide benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods. This document adds ECDSA capability to IKE and IKEv2 without introducing any changes to existing IKE operation. [STANDARDS-TRACK]

 draft-ietf-ipsec-ike-auth-ecdsa-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4754 10.17487/RFC4754 RFC4755 IP over InfiniBand: Connected Mode V. Kashyap December 2006 ASCII HTML 13

This document specifies transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand. [STANDARDS-TRACK]

 draft-ietf-ipoib-connected-mode-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ipoib 10.17487/RFC4755 RFC4756 Forward Error Correction Grouping Semantics in Session Description Protocol A. Li November 2006 ASCII HTML 6 fec sdp media lines

This document defines the semantics that allow for grouping of Forward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document are to be used with "Grouping of Media Lines in the Session Description Protocol" (RFC 3388) to group together "m" lines in the same session. [STANDARDS-TRACK]

 draft-ietf-mmusic-fec-grouping-05 RFC5956 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4756 RFC4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows K. Jaganathan L. Zhu J. Brezak December 2006 ASCII HTML 18 md5 hmac

The Microsoft Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for checksum. This is offered as an alternative to using the existing DES-based encryption types.

The RC4-HMAC encryption types are used to ease upgrade of existing Windows NT environments, provide strong cryptography (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types. This memo provides information for the Internet community.

 draft-jaganathan-rc4-hmac-03 RFC6649 HISTORIC INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4757 10.17487/RFC4757 RFC4758 Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1 M. Nystroem November 2006 ASCII HTML 54 rsa laboratories one-time password specifications otps

This document constitutes Revision 1 of Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 from RSA Laboratories' One-Time Password Specifications (OTPS) series. The body of this document, except for the intellectual property considerations section, is taken from the CT-KIP Version 1.0 document, but comments received during the IETF review are reflected; hence, the status of a revised version. As no "bits-on-the-wire" have changed, the protocol specified herein is compatible with CT-KIP Version 1.0.

CT-KIP is a client-server protocol for initialization (and configuration) of cryptographic tokens. The protocol requires neither private-key capabilities in the cryptographic tokens, nor an established public-key infrastructure. Provisioned (or generated) secrets will only be available to the server and the cryptographic token itself. This memo provides information for the Internet community.

 draft-nystrom-ct-kip-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4758 10.17487/RFC4758 RFC4759 The ENUM Dip Indicator Parameter for the "tel" URI R. Stastny R. Shockey L. Conroy December 2006 ASCII HTML 8 DNS E.164 telephone number

This document defines a new parameter "enumdi" for the "tel" Uniform Resource Identifier (URI) to support the handling of ENUM queries in Voice over Internet Protocol (VoIP) network elements. A VoIP network element may receive a URI containing an E.164 number, where that URI contains an "enumdi" parameter. The presence of the "enumdi" parameter indicates that an ENUM query has already been performed on the E.164 number by a previous VoIP network element. Equally, if a VoIP network element sends such a URI, it asserts that an ENUM query has been carried out on this number. [STANDARDS-TRACK]

 draft-ietf-iptel-tel-enumdi-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC4759 RFC4760 Multiprotocol Extensions for BGP-4 T. Bates R. Chandra D. Katz Y. Rekhter January 2007 ASCII HTML 12 MEXT-BGP4 border gateway protocol network layer protocols

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]

 draft-ietf-idr-rfc2858bis-10 RFC2858 RFC7606 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4760 10.17487/RFC4760 RFC4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling K. Kompella Editor Y. Rekhter Editor January 2007 ASCII HTML 28 border gateway protocol transparent lan service virtual private switched network service provider

Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.

This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. [STANDARDS-TRACK]

 draft-ietf-l2vpn-vpls-bgp-08 RFC5462 RFC8395 RFC8614 PROPOSED STANDARD PROPOSED STANDARD IETF int l2vpn 10.17487/RFC4761 RFC4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling M. Lasserre Editor V. Kompella Editor January 2007 ASCII HTML 31 land area network transparent lan service

This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node.

This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448. [STANDARDS-TRACK]

 draft-ietf-l2vpn-vpls-ldp-09 PROPOSED STANDARD PROPOSED STANDARD IETF int l2vpn http://www.rfc-editor.org/errata_search.php?rfc=4762 10.17487/RFC4762 RFC4763 Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE) M. Vanderveen H. Soliman November 2006 ASCII HTML 46 IEEE 802.11i user anonymity

This document specifies an Extensible Authentication Protocol (EAP) mechanism for Shared-secret Authentication and Key Establishment (SAKE). This RFC is published as documentation for the IANA assignment of an EAP Type for a vendor's EAP method per RFC 3748. The specification has passed Designated Expert review for this IANA assignment. This memo provides information for the Internet community.

 draft-vanderveen-eap-sake-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4763 10.17487/RFC4763 RFC4764 The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method F. Bersani H. Tschofenig January 2007 ASCII HTML 64 pre-shared key

This document specifies EAP-PSK, an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11. This memo defines an Experimental Protocol for the Internet community.

 draft-bersani-eap-psk-11 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4764 RFC4765 The Intrusion Detection Message Exchange Format (IDMEF) H. Debar D. Curry B. Feinstein March 2007 ASCII HTML 157 intrusion detection security secure exchange intrusion IDS XML

The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.

This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-idwg-idmef-xml-16 EXPERIMENTAL EXPERIMENTAL IETF sec idwg 10.17487/RFC4765 RFC4766 Intrusion Detection Message Exchange Requirements M. Wood M. Erlinger March 2007 ASCII HTML 25 idmef idwg intrusion detection exchange format

The purpose of the Intrusion Detection Exchange Format Working Group (IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them. This document describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed. Scenarios are used to illustrate some requirements. This memo provides information for the Internet community.

 draft-ietf-idwg-requirements-10 INFORMATIONAL INFORMATIONAL IETF sec idwg 10.17487/RFC4766 RFC4767 The Intrusion Detection Exchange Protocol (IDXP) B. Feinstein G. Matthews March 2007 ASCII HTML 28 intrusion intrusion detection beep security ids security protocol secure protocol secure exchange idmef

This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described in RFC 4765, "The Intrusion Detection Message Exchange Format (IDMEF)", a companion document of the Intrusion Detection Exchange Format Working Group (IDWG) of the IETF. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-idwg-beep-idxp-07 EXPERIMENTAL EXPERIMENTAL IETF sec idwg 10.17487/RFC4767 RFC4768 Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming S. Hartman December 2006 ASCII HTML 12 acl access control list

The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists (ACLs) to make authorization decisions. Advances in security mechanisms and the way implementers wish to use GSS-API require this model to be extended for the next version of GSS-API. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms, such as public-key mechanisms, do not have a single name to be used across all environments. Other mechanisms, such as Kerberos, may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion. This memo provides information for the Internet community.

 draft-ietf-kitten-gss-naming-05 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC4768 RFC4769 IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information J. Livingood R. Shockey November 2006 ASCII HTML 13 tel uri uri scheme sip

This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype "sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists. [STANDARDS-TRACK]

 draft-ietf-enum-pstn-05 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4769 RFC4770 vCard Extensions for Instant Messaging (IM) C. Jennings J. Reschke Editor January 2007 ASCII HTML 7 impp instant messaging and presence protocol

This document describes an extension to vCard to support Instant Messaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. It allows a URI that is associated with IM or PP to be specified inside a vCard. [STANDARDS-TRACK]

 draft-jennings-impp-vcard-08 RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4770 RFC4771 Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP) V. Lehtovirta M. Naslund K. Norrman January 2007 ASCII HTML 12 roc

This document defines an integrity transform for Secure Real-time Transport Protocol (SRTP; see RFC 3711), which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag. The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session and needs to quickly and robustly synchronize. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization. [STANDARDS-TRACK]

 draft-lehtovirta-srtp-rcc-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4771 10.17487/RFC4771 RFC4772 Security Implications of Using the Data Encryption Standard (DES) S. Kelly December 2006 ASCII HTML 28

The Data Encryption Standard (DES) is susceptible to brute-force attacks, which are well within the reach of a modestly financed adversary. As a result, DES has been deprecated, and replaced by the Advanced Encryption Standard (AES). Nonetheless, many applications continue to rely on DES for security, and designers and implementers continue to support it in new applications. While this is not always inappropriate, it frequently is. This note discusses DES security implications in detail, so that designers and implementers have all the information they need to make judicious decisions regarding its use. This memo provides information for the Internet community.

 draft-kelly-saag-des-implications-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4772 RFC4773 Administration of the IANA Special Purpose IPv6 Address Block G. Huston December 2006 ASCII HTML 5

This is a direction to IANA concerning the management of the IANA Special Purpose IPv6 address assignment registry. This memo provides information for the Internet community.

 draft-huston-ipv6-iana-specials-01 RFC6890 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4773 RFC4774 Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field S. Floyd November 2006 ASCII HTML 15

There have been a number of proposals for alternate semantics for the Explicit Congestion Notification (ECN) field in the IP header RFC 3168. This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics. This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-tsvwg-ecn-alternates-02 RFC6040 BCP0124 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC4774 RFC4775 Procedures for Protocol Extensions and Variations S. Bradner B. Carpenter Editor T. Narten December 2006 ASCII HTML 14 sdo standards development organization

This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocols without early IETF review can carry risk. The document also recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF.

This document is directed principally at other Standards Development Organizations (SDOs) and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-carpenter-protocol-extensions-04 BCP0125 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4775 RFC4776 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information H. Schulzrinne November 2006 ASCII HTML 19 lci local configuration information

This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. [STANDARDS-TRACK]

 RFC4676 RFC5774 RFC6848 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC4776 RFC4777 IBM's iSeries Telnet Enhancements T. Murphy Jr. P. Rieth J. Stevens November 2006 ASCII HTML 47 midrange business computer telnet environment client server printer

This document describes the interface to the Telnet server on IBM's iSeries line of midrange business computers. This interface allows Telnet clients to request a Telnet terminal or printer session using specific session attributes related to device names, encryption, language support, auto-sign-on, response codes, session association, etc.

These support functions are implemented primarily using the Telnet Environment option negotiation RFC 1572 to define new USERVAR variables that will be recognized by iSeries Telnet server. This memo provides information for the Internet community.

 draft-murphy-iser-telnet-04 RFC2877 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4777 RFC4778 Operational Security Current Practices in Internet Service Provider Environments M. Kaeo January 2007 ASCII HTML 37 isp

This document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments. This memo provides information for the Internet community.

 draft-ietf-opsec-current-practices-07 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=4778 10.17487/RFC4778 RFC4779 ISP IPv6 Deployment Scenarios in Broadband Access Networks S. Asadullah A. Ahmed C. Popoviciu P. Savola J. Palet January 2007 ASCII HTML 81 v6ops isp ipv6 deployment scenarios broadband networks

This document provides a detailed description of IPv6 deployment and integration methods and scenarios in today\'s Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks, their differences from IPv4 BB networks, and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6. This memo provides information for the Internet community.

 draft-ietf-v6ops-bb-deployment-scenarios-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4779 10.17487/RFC4779 RFC4780 Management Information Base for the Session Initiation Protocol (SIP) K. Lingle J-F. Mule J. Maeng D. Walker April 2007 ASCII HTML 83 mib registrar services SIP-COMMON-MIB SIP-TC-MIB SIP-UA-MIB DEFINITIONS SIP-SERVER-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers. [STANDARDS-TRACK]

 draft-ietf-sip-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4780 RFC4781 Graceful Restart Mechanism for BGP with MPLS Y. Rekhter R. Aggarwal January 2007 ASCII HTML 10 border gateway protocol multiprotocol label switching nlri bgp network layer reachability information

A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document ("Graceful Restart Mechanism for BGP"). This document extends this mechanism to minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart.

The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such, it works in conjunction with any of the address families that could be carried in BGP (e.g., IPv4, IPv6, etc.). [STANDARDS-TRACK]

 draft-ietf-mpls-bgp-mpls-restart-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4781 RFC4782 Quick-Start for TCP and IP S. Floyd M. Allman A. Jain P. Sarolahti January 2007 ASCII HTML 82

This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.

This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick- Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tsvwg-quickstart-07 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4782 10.17487/RFC4782 RFC4783 GMPLS - Communication of Alarm Information L. Berger Editor December 2006 ASCII HTML 19 generalized multiprotocol label switching gmpls-rsvp

This document describes an extension to Generalized MPLS (Multi-Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object.

This document updates RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with, the procedures specified in RFC 3473. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-alarm-spec-06 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4783 10.17487/RFC4783 RFC4784 Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks C. Carroll F. Quick June 2007 ASCII HTML 45 mip cryptographic keys dmu

The Verizon Wireless Dynamic Mobile IP Key Update procedure is a mechanism for distributing and updating Mobile IP (MIP) cryptographic keys in cdma2000(R) networks (including High Rate Packet Data, which is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update (DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUS Authentication, Authorization and Accounting (AAA) Server via a cdma2000(R) Packet Data Serving Node (PDSN) that is acting as a Mobile IP Foreign Agent (FA).

cdma2000(R) is a registered trademark of the Telecommunications Industry Association (TIA). This memo provides information for the Internet community.

 draft-carroll-dynmobileip-cdma-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4784 RFC4785 Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) U. Blumenthal P. Goel January 2007 ASCII HTML 5 cipher suite

This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport Layer Security (TLS) protocol. These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted. [STANDARDS-TRACK]

 draft-ietf-tls-psk-null-03 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC4785 RFC4786 Operation of Anycast Services J. Abley K. Lindqvist December 2006 ASCII HTML 24 ROUTING LOAD-BALANCING LOAD-SHARING

As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely.

Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-grow-anycast-04 BCP0126 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC4786 RFC4787 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP F. Audet Editor C. Jennings January 2007 ASCII HTML 29 nat sip udp

This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-behave-nat-udp-08 RFC6888 RFC7857 BCP0127 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC4787 RFC4788 Enhancements to RTP Payload Formats for EVRC Family Codecs Q. Xie R. Kapoor January 2007 ASCII HTML 22 enhanced variable rate codec real time transmission protocol evrc-b dtx discontinuous transmission

This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth. [STANDARDS-TRACK]

 draft-ietf-avt-compact-bundled-evrc-11 RFC3558 RFC5188 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4788 RFC4789 Simple Network Management Protocol (SNMP) over IEEE 802 Networks J. Schoenwaelder T. Jeffree November 2006 ASCII HTML 9

This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks.

This document obsoletes RFC 1089. [STANDARDS-TRACK]

 draft-schoenw-snmp-ether-02 RFC1089 RFC3417 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4789 RFC4790 Internet Application Protocol Collation Registry C. Newman M. Duerst A. Gulbrandsen March 2007 ASCII HTML 26 collation sorting

Many Internet application protocols include string-based lookup, searching, or sorting operations. However, the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function, and the repertoire of comparison functions can be extended in the future. [STANDARDS-TRACK]

 draft-newman-i18n-comparator-14 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4790 10.17487/RFC4790 RFC4791 Calendaring Extensions to WebDAV (CalDAV) C. Daboo B. Desruisseaux L. Dusseault March 2007 ASCII HTML 107 calsched calsch calcav calendar calendaring scheduling webdav ical icalendar itip text/calendar http

This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV. [STANDARDS-TRACK]

 draft-dusseault-caldav-15 RFC5689 RFC6638 RFC6764 RFC7809 RFC7953 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4791 10.17487/RFC4791 RFC4792 Encoding Instructions for the Generic String Encoding Rules (GSER) S. Legg January 2007 ASCII HTML 9 ASN.1

Abstract Syntax Notation One (ASN.1) defines a general framework for annotating types in an ASN.1 specification with encoding instructions that alter how values of those types are encoded according to ASN.1 encoding rules. This document defines the supporting notation for encoding instructions that apply to the Generic String Encoding Rules (GSER) and, in particular, defines an encoding instruction to provide a machine-processable representation for the declaration of a GSER ChoiceOfStrings type. [STANDARDS-TRACK]

 draft-legg-ldap-gser-ei-02 RFC3641 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4792 RFC4793 The EAP Protected One-Time Password Protocol (EAP-POTP) M. Nystroem February 2007 ASCII HTML 82 otp extensible authentication protocol

This document describes a general Extensible Authentication Protocol (EAP) method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens with direct electronic interfaces to their associated clients. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet Key Exchange Protocol Version 2 (IKEv2). This memo provides information for the Internet community.

 draft-nystrom-eap-potp-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4793 RFC4794 RFC 1264 Is Obsolete B. Fenner December 2006 ASCII HTML 4

RFC 1264 was written during what was effectively a completely different time in the life of the Internet. It prescribed rules to protect the Internet against new routing protocols that may have various undesirable properties. In today's Internet, there are so many other pressures against deploying unreasonable protocols that we believe that existing controls suffice, and the RFC 1264 rules just get in the way. This memo provides information for the Internet community.

 draft-fenner-obsolete-1264-03 RFC1264 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4794 RFC4795 Link-local Multicast Name Resolution (LLMNR) B. Aboba D. Thaler L. Esibov January 2007 ASCII HTML 31

The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types, and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. This memo provides information for the Internet community.

 draft-ietf-dnsext-mdns-47 INFORMATIONAL INFORMATIONAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4795 10.17487/RFC4795 RFC4796 The Session Description Protocol (SDP) Content Attribute J. Hautakorpi G. Camarillo February 2007 ASCII HTML 11 media attribute content

This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-media-content-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4796 RFC4797 Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks Y. Rekhter R. Bonica E. Rosen January 2007 ASCII HTML 10 L3VPN GRE encapsulation

This document describes an implementation strategy for BGP/MPLS IP Virtual Private Networks (VPNs) in which the outermost MPLS label (i.e., the tunnel label) is replaced with either an IP header or an IP header with Generic Routing Encapsulation (GRE).

The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not. This memo provides information for the Internet community.

 draft-ietf-l3vpn-gre-ip-2547-05 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4797 RFC4798 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) J. De Clercq D. Ooms S. Prevost F. Le Faucheur February 2007 ASCII HTML 14 mp-bgp

This document explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are Dual Stack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. [STANDARDS-TRACK]

 draft-ooms-v6ops-bgp-tunnel-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC4798 RFC4799 RFC4800 RFC4801 Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management T. Nadeau Editor A. Farrel Editor February 2007 ASCII HTML 9 management information base mib GMPLS-TC-STD-MIB

This document defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information. The intent is that these textual conventions will be imported and used in GMPLS-related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-tc-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4801 RFC4802 Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base T. Nadeau Editor A. Farrel Editor February 2007 ASCII HTML 60 mib GMPLS-TE-STD-MIB IANA-GMPLS-TC-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS)-based traffic engineering. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-te-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4802 RFC4803 Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base T. Nadeau Editor A. Farrel Editor February 2007 ASCII HTML 42 mib GMPLS-LSR-STD-MIB GMPLS-LABEL-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-lsr-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4803 10.17487/RFC4803 RFC4804 Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels F. Le Faucheur Editor February 2007 ASCII HTML 31 multiprotocol label switching traffic engineering diffserv-aware mpls traffic engineering

RFC 3175 specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-end reservations over aggregate RSVP reservations. This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) tunnels. This approach is based on RFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations. This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels. [STANDARDS-TRACK]

 draft-ietf-tsvwg-rsvp-dste-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4804 10.17487/RFC4804 RFC4805 Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types O. Nicklass Editor March 2007 ASCII HTML 94 mib management information base DS1-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, J1, E1, DS2, and E2 interfaces. This document is a companion to the documents that define managed objects for the DS0, DS3/E3, and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types.

This document obsoletes RFC 3895. [STANDARDS-TRACK]

 draft-orly-atommib-rfc3895bis-01 RFC3895 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4805 RFC4806 Online Certificate Status Protocol (OCSP) Extensions to IKEv2 M. Myers H. Tschofenig February 2007 ASCII HTML 11 internet key exchange version 2

While the Internet Key Exchange Protocol version 2 (IKEv2) supports public key based authentication, the corresponding use of in-band Certificate Revocation Lists (CRL) is problematic due to unbounded CRL size. The size of an Online Certificate Status Protocol (OCSP) response is however well-bounded and small. This document defines the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP Content" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier.

When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies when OCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network. [STANDARDS-TRACK]

 draft-myers-ikev2-ocsp-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4806 RFC4807 IPsec Security Policy Database Configuration MIB M. Baer R. Charlet W. Hardaker R. Story C. Wang March 2007 ASCII HTML 71 management information base IPSEC-SPD-MIB

This document defines a Structure of Management Information Version 2 (SMIv2) Management Information Base (MIB) module for configuring the security policy database of a device implementing the IPsec protocol. The policy-based packet filtering and the corresponding execution of actions described in this document are of a more general nature than for IPsec configuration alone, such as for configuration of a firewall. This MIB module is designed to be extensible with other enterprise or standards-based defined packet filters and actions. [STANDARDS-TRACK]

 draft-ietf-ipsp-spd-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4807 10.17487/RFC4807 RFC4808 Key Change Strategies for TCP-MD5 S. Bellovin March 2007 ASCII HTML 8 bgp border gateway protocol

The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes. This memo provides information for the Internet community.

 draft-bellovin-keyroll2385-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4808 RFC4809 Requirements for an IPsec Certificate Management Profile C. Bonatti Editor S. Turner Editor G. Lebovitz Editor February 2007 ASCII HTML 45 internet protocol security

This informational document describes and identifies the requirements for transactions to handle Public Key Certificate (PKC) lifecycle transactions between Internet Protocol Security (IPsec) Virtual Private Network (VPN) Systems using Internet Key Exchange (IKE) (versions 1 and 2) and Public Key Infrastructure (PKI) Systems. These requirements are designed to meet the needs of enterprise-scale IPsec VPN deployments. It is intended that a standards track profile of a management protocol will be created to address many of these requirements. This memo provides information for the Internet community.

 draft-ietf-pki4ipsec-mgmt-profile-rqts-07 INFORMATIONAL INFORMATIONAL IETF sec pki4ipsec 10.17487/RFC4809 RFC4810 Long-Term Archive Service Requirements C. Wallace U. Pordesch R. Brandner March 2007 ASCII HTML 17 data integrity digital signatures

There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. This memo provides information for the Internet community.

 draft-ietf-ltans-reqs-10 INFORMATIONAL INFORMATIONAL IETF sec ltans 10.17487/RFC4810 RFC4811 OSPF Out-of-Band Link State Database (LSDB) Resynchronization L. Nguyen A. Roy A. Zinin March 2007 ASCII HTML 10 open shortest path first

OSPF is a link-state intra-domain routing protocol used in IP networks. Link State Database (LSDB) synchronization in OSPF is achieved via two methods -- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize their LSDBs. The OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network.

This memo describes a vendor-specific mechanism to perform such a form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community.

 draft-nguyen-ospf-oob-resync-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4811 RFC4812 OSPF Restart Signaling L. Nguyen A. Roy A. Zinin March 2007 ASCII HTML 7 open shortest path first

OSPF is a link-state intra-domain routing protocol used in IP networks. Routers find new and detect unreachable neighbors via the Hello subprotocol. Hello OSPF packets are also used to ensure two-way connectivity within time. When a router restarts its OSPF software, it may not know its neighbors. If such a router sends a Hello packet on an interface, its neighbors are going to reset the adjacency, which may not be desirable in certain conditions.

This memo describes a vendor-specific mechanism that allows OSPF routers to inform their neighbors about the restart process. Note that this mechanism requires support from neighboring routers. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community.

 draft-nguyen-ospf-restart-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4812 10.17487/RFC4812 RFC4813 OSPF Link-Local Signaling B. Friedman L. Nguyen A. Roy D. Yeung A. Zinin March 2007 ASCII HTML 10 open shortest path first

OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This memo defines an Experimental Protocol for the Internet community.

 draft-nguyen-ospf-lls-06 RFC5613 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4813 RFC4814 Hash and Stuffing: Overlooked Factors in Network Device Benchmarking D. Newman T. Player March 2007 ASCII HTML 26 bmwg benchmarking testing bit-stuffing byte-stuffing

Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results. First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic. This memo provides information for the Internet community.

 draft-ietf-bmwg-hash-stuffing-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4814 RFC4815 RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095 L-E. Jonsson K. Sandlund G. Pelletier P. Kremer February 2007 ASCII HTML 33 ip udp user datagram protocol rtp realtime transport protocol esp encapsulation security payload

RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security Payload). Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UDP-Lite profiles) are also provided. [STANDARDS-TRACK]

 draft-ietf-rohc-rtp-impl-guide-22 RFC3095 RFC3241 RFC3843 RFC4019 RFC4362 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4815 RFC4816 Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service A. Malis L. Martini J. Brayley T. Walsh February 2007 ASCII HTML 5

The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer-Mode (ATM) cell encapsulation. [STANDARDS-TRACK]

 draft-ietf-pwe3-cell-transport-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4816 RFC4817 Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 M. Townsley C. Pignataro S. Wainner T. Seely J. Young March 2007 ASCII HTML 12 l2tpv3 multiprotocol label switching label stack label stack

The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation. This enables an application that traditionally requires an MPLS-enabled core network, to utilize an L2TPv3 encapsulation over an IP network instead. [STANDARDS-TRACK]

 draft-ietf-mpls-over-l2tpv3-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4817 RFC4818 RADIUS Delegated-IPv6-Prefix Attribute J. Salowey R. Droms April 2007 ASCII HTML 7 remote authentication dial in user service diameter

This document defines a RADIUS (Remote Authentication Dial In User Service) attribute that carries an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter. [STANDARDS-TRACK]

 draft-ietf-radext-delegated-prefix-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC4818 RFC4819 Secure Shell Public Key Subsystem J. Galbraith J. Van Dyke J. Bright March 2007 ASCII HTML 17 ssh ssh2

Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration.

The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user.

A public key may also be associated with various restrictions, including a mandatory command or subsystem. [STANDARDS-TRACK]

 draft-ietf-secsh-publickey-subsystem-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4819 RFC4820 Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) M. Tuexen R. Stewart P. Lei March 2007 ASCII HTML 6

This document defines a padding chunk and a padding parameter and describes the required receiver side procedures. The padding chunk is used to pad a Stream Control Transmission Protocol (SCTP) packet to an arbitrary size. The padding parameter is used to pad an SCTP INIT chunk to an arbitrary size. [STANDARDS-TRACK]

 draft-ietf-tsvwg-sctp-padding-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4820 10.17487/RFC4820 RFC4821 Packetization Layer Path MTU Discovery M. Mathis J. Heffner March 2007 ASCII HTML 32 maximum transmission unit pmtud

This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK]

 draft-ietf-pmtud-method-11 RFC8899 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pmtud http://www.rfc-editor.org/errata_search.php?rfc=4821 10.17487/RFC4821 RFC4822 RIPv2 Cryptographic Authentication R. Atkinson M. Fanto February 2007 ASCII HTML 22 RIP2-MD5 Routing Information Protocol Encryption

This note describes a revision to the RIPv2 Cryptographic Authentication mechanism originally specified in RFC 2082. This document obsoletes RFC 2082 and updates RFC 2453. This document adds details of how the SHA family of hash algorithms can be used with RIPv2 Cryptographic Authentication, whereas the original document only specified the use of Keyed-MD5. Also, this document clarifies a potential issue with an active attack on this mechanism and adds significant text to the Security Considerations section. [STANDARDS-TRACK]

 draft-rja-ripv2-auth-06 RFC2082 RFC2453 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4822 RFC4823 FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet T. Harding R. Scott April 2007 ASCII HTML 40 applicability statement as business-to-business

This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. This memo provides information for the Internet community.

 draft-ietf-ediint-as3-04 RFC8996 INFORMATIONAL INFORMATIONAL IETF app ediint http://www.rfc-editor.org/errata_search.php?rfc=4823 10.17487/RFC4823 RFC4824 The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS) J. Hofmueller Editor A. Bachmann Editor IO. zmoelnig Editor April 1 2007 ASCII HTML 13 internet protocol april fools

This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS). This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4824 10.17487/RFC4824 RFC4825 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) J. Rosenberg May 2007 ASCII HTML 71 sip xml http rest buddy list simple presence data manipulation

This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. [STANDARDS-TRACK]

 draft-ietf-simple-xcap-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC4825 RFC4826 Extensible Markup Language (XML) Formats for Representing Resource Lists J. Rosenberg May 2007 ASCII HTML 31 http sip xml rest buddy list simple presence data manipulation

In multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services that are associated with a group of users. One example is a resource list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists that are referenced from the first. This list of users can be utilized by other applications and services. Both documents can be created and managed with the XML Configuration Access Protocol (XCAP). [STANDARDS-TRACK]

 draft-ietf-simple-xcap-list-usage-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4826 10.17487/RFC4826 RFC4827 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents M. Isomaki E. Leppanen May 2007 ASCII HTML 11 PIDF AUID hard state PUBLISH SIP Presence SIMPLE pidf-manipulation XCAP application usage

This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents. It is intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity. [STANDARDS-TRACK]

 draft-ietf-simple-xcap-pidf-manipulation-usage-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4827 10.17487/RFC4827 RFC4828 TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant S. Floyd E. Kohler April 2007 ASCII HTML 46 transmission control protocol

This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet.

TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment (RFC 3448). TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently.

Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small-packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-dccp-tfrc-voip-07 EXPERIMENTAL EXPERIMENTAL IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=4828 10.17487/RFC4828 RFC4829 Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering J. de Oliveira Editor JP. Vasseur Editor L. Chen C. Scoglio April 2007 ASCII HTML 19 traffic engineering label switched path te lsp multiprotocol label switching protocol

When the establishment of a higher priority (Traffic Engineering Label Switched Path) TE LSP requires the preemption of a set of lower priority TE LSPs, a node has to make a local decision to select which TE LSPs will be preempted. The preempted LSPs are then rerouted by their respective \%Head-end Label Switch Router (LSR). This document presents a flexible policy that can be used to achieve different objectives: preempt the lowest priority LSPs; preempt the minimum number of LSPs; preempt the set of TE LSPs that provide the closest amount of bandwidth to the required bandwidth for the preempting TE LSPs (to minimize bandwidth wastage); preempt the LSPs that will have the maximum chance to get rerouted. Simulation results are given and a comparison among several different policies, with respect to preemption cascading, number of preempted LSPs, priority, wasted bandwidth and blocking probability is also included. This memo provides information for the Internet community.

 draft-deoliveira-diff-te-preemption-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4829 RFC4830 Problem Statement for Network-Based Localized Mobility Management (NETLMM) J. Kempf Editor April 2007 ASCII HTML 13

Localized mobility management is a well-understood concept in the IETF, with a number of solutions already available. This document looks at the principal shortcomings of the existing solutions, all of which involve the host in mobility management, and makes a case for network-based local mobility management. This memo provides information for the Internet community.

 draft-ietf-netlmm-nohost-ps-05 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC4830 RFC4831 Goals for Network-Based Localized Mobility Management (NETLMM) J. Kempf Editor April 2007 ASCII HTML 14

In this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed. This memo provides information for the Internet community.

 draft-ietf-netlmm-nohost-req-05 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC4831 RFC4832 Security Threats to Network-Based Localized Mobility Management (NETLMM) C. Vogt J. Kempf April 2007 ASCII HTML 12 localized mobility anchor mobile access gateway compromise impersonation man in the middle denial of service IP spoofing

This document discusses security threats to network-based localized mobility management. Threats may occur on two interfaces: the interface between a localized mobility anchor and a mobile access gateway, as well as the interface between a mobile access gateway and a mobile node. Threats to the former interface impact the localized mobility management protocol itself. This memo provides information for the Internet community.

 draft-ietf-netlmm-threats-04 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC4832 RFC4833 Timezone Options for DHCP E. Lear P. Eggert April 2007 ASCII HTML 10 time offset posix tz database tz

Two common ways to communicate timezone information are POSIX 1003.1 timezone strings and timezone database names. This memo specifies DHCP options for each of those methods. The DHCPv4 time offset option is deprecated. [STANDARDS-TRACK]

 draft-ietf-dhc-timezone-option-05 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4833 RFC4834 Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) T. Morin Editor April 2007 ASCII HTML 37 vpn virtual private networks l3

This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within Layer 3 (L3) Provider-Provisioned Virtual Private Networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines. This memo provides information for the Internet community.

 draft-ietf-l3vpn-ppvpn-mcast-reqts-10 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4834 RFC4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) V. Manral April 2007 ASCII HTML 10 ESP ipsec authentication mechanism header security architecture payload internet protocol encapsulating ipv4 ipv6

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]

 draft-manral-ipsec-rfc4305-bis-errata-03 RFC4305 RFC7321 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4835 RFC4836 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) E. Beili April 2007 ASCII HTML 67 MAU-MIB IANA-MAU-MIB management information base,

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). This document obsoletes RFC 3636. It amends that specification by moving MAU type OBJECT-IDENTITY definitions and relevant textual conventions into a separate Internet Assigned Number Authority (IANA) maintained MIB module. In addition, management information is added to enable support for Ethernet in the First Mile (EFM) and 10GBASE-CX4 MAUs. [STANDARDS-TRACK]

 draft-ietf-hubmib-rfc3636bis-05 RFC3636 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib http://www.rfc-editor.org/errata_search.php?rfc=4836 10.17487/RFC4836 RFC4837 Managed Objects of Ethernet Passive Optical Networks (EPON) L. Khermosh July 2007 ASCII HTML 91 Ethernet Passive Optical Networks pon epon IEEE802.3ah 802.3ah p2mp mpcp llid onu olt optical access

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based Internets. In particular, it defines objects for managing interfaces that conform to the Ethernet Passive Optical Networks (EPON) standard as defined in the IEEE Std 802.3ah-2004, which are extended capabilities to the Ethernet like interfaces. [STANDARDS-TRACK]

 draft-ietf-hubmib-efm-epon-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC4837 RFC4838 Delay-Tolerant Networking Architecture V. Cerf S. Burleigh A. Hooke L. Torgerson R. Durst K. Scott K. Fall H. Weiss April 2007 ASCII HTML 35 disruption tolerant irtf interplanetary internet

This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. This memo provides information for the Internet community.

 draft-irtf-dtnrg-arch-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC4838 RFC4839 Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF) G. Conboy J. Rivlin J. Ferraiolo April 2007 ASCII HTML 5

This document serves to register a media type for the Open eBook Publication Structure (OEBPS) Package Files. This memo provides information for the Internet community.

 draft-conboy-mime-opf-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4839 RFC4840 Multiple Encapsulation Methods Considered Harmful B. Aboba Editor E. Davies D. Thaler April 2007 ASCII HTML 27 iab link-layer protocol ip encapsulation internet protocol encapsulation

This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods. This memo provides information for the Internet community.

 draft-iab-link-encaps-08 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4840 RFC4841 RFC 4181 Update to Recognize the IETF Trust C. Heard Editor March 2007 ASCII HTML 3 management information base standards-track specifications mib review

This document updates RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents", to recognize the creation of the IETF Trust. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-heard-rfc4181-update-00 RFC4181 BCP0111 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4841 RFC4842 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) A. Malis P. Pate R. Cohen Editor D. Zelig April 2007 ASCII HTML 43 multiprotocol label switching

This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS. [STANDARDS-TRACK]

 draft-ietf-pwe3-sonet-14 RFC5143 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4842 10.17487/RFC4842 RFC4843 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) P. Nikander J. Laganier F. Dupont April 2007 ASCII HTML 14

This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.

This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus. This memo defines an Experimental Protocol for the Internet community.

 draft-laganier-ipv6-khi-07 RFC7343 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4843 RFC4844 The RFC Series and RFC Editor L. Daigle Editor Internet Architecture Board July 2007 ASCII HTML 20 technical publisher

This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This memo provides information for the Internet community.

 draft-iab-rfc-editor-04 RFC8729 RFC5741 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4844 RFC4845 Process for Publication of IAB RFCs L. Daigle Editor Internet Architecture Board July 2007 ASCII HTML 5

From time to time, the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs). This document defines the process by which those documents are produced, reviewed, and published in the RFC Series. This memo provides information for the Internet community.

 draft-iab-publication-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4845 RFC4846 Independent Submissions to the RFC Editor J. Klensin Editor D. Thaler Editor July 2007 ASCII HTML 16

There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher. This memo provides information for the Internet community.

 draft-iab-rfc-independent-00 RFC5744 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4846 RFC4847 Framework and Requirements for Layer 1 Virtual Private Networks T. Takeda Editor April 2007 ASCII HTML 38 L1VPN

This document provides a framework and service level requirements for Layer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs.

The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs. This memo provides information for the Internet community.

 draft-ietf-l1vpn-framework-05 INFORMATIONAL INFORMATIONAL IETF rtg l1vpn 10.17487/RFC4847 RFC4848 Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS) L. Daigle April 2007 ASCII HTML 10 service-parms service parameters

The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application. [STANDARDS-TRACK]

 draft-daigle-unaptr-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4848 10.17487/RFC4848 RFC4849 RADIUS Filter Rule Attribute P. Congdon M. Sanchez B. Aboba April 2007 ASCII HTML 9 remote authentication dial in user service nas-filter-rule

While RFC 2865 defines the Filter-Id attribute, it requires that the Network Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS). This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588. [STANDARDS-TRACK]

 draft-ietf-radext-filter-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC4849 RFC4850 Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture D. Wysochanski April 2007 ASCII HTML 9 transport protocol tcp transmission control protocol

The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This document describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs. [STANDARDS-TRACK]

 draft-ietf-ips-iscsi-nodearch-key-03 RFC7143 RFC3720 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4850 RFC4851 The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) N. Cam-Winget D. McGrew J. Salowey H. Zhou May 2007 ASCII HTML 64 eap

This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server. This memo provides information for the Internet community.

 draft-cam-winget-eap-fast-06 RFC8996 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4851 10.17487/RFC4851 RFC4852 IPv6 Enterprise Network Analysis - IP Layer 3 Focus J. Bound Y. Pouffary S. Klynsma T. Chown D. Green April 2007 ASCII HTML 32 internet protocol version 6 notational network

This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity. The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network. This memo provides information for the Internet community.

 draft-ietf-v6ops-ent-analysis-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4852 10.17487/RFC4852 RFC4853 Cryptographic Message Syntax (CMS) Multiple Signer Clarification R. Housley April 2007 ASCII HTML 5 signeddata digitally sign authenticate encrypt arbitrary message content

This document updates the Cryptographic Message Syntax (CMS), which is published in RFC 3852. This document clarifies the proper handling of the SignedData protected content type when more than one digital signature is present. [STANDARDS-TRACK]

 draft-ietf-smime-cms-mult-sign-03 RFC3852 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4853 10.17487/RFC4853 RFC4854 A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre April 2007 ASCII HTML 9 Extensible Messaging and Presence Protocol XMPP Jabber Instant Messaging Presence Uniform Resource Name URN

This document describes a Uniform Resource Name (URN) namespace for uniquely identifying Extensible Markup Language (XML) formats and protocols that provide extensions to the Extensible Messaging and Presence Protocol (XMPP) and are defined in specifications published by the XMPP Standards Foundation (XSF). This memo provides information for the Internet community.

 draft-saintandre-xmpp-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4854 RFC4855 Media Type Registration of RTP Payload Formats S. Casner February 2007 ASCII HTML 11 realtime transport protocol multipurpose internet mail extensions

This document specifies the procedure to register RTP payload formats as audio, video, or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission. [STANDARDS-TRACK]

 draft-ietf-avt-rfc3555bis-05 RFC3555 RFC8851 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4855 RFC4856 Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences S. Casner February 2007 ASCII HTML 29 realtime transport protocol multipurpose internet mail extensions

This document specifies media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences. Some of these may also be used for transfer modes other than RTP. [STANDARDS-TRACK]

 draft-ietf-avt-rfc3555bis-part2-02 RFC3555 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4856 10.17487/RFC4856 RFC4857 Mobile IPv4 Regional Registration E. Fogelstroem A. Jonsson C. Perkins June 2007 ASCII HTML 35 GFA gateway foreign agent

Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e., registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mip4-reg-tunnel-04 EXPERIMENTAL EXPERIMENTAL IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4857 10.17487/RFC4857 RFC4858 Document Shepherding from Working Group Last Call to Publication H. Levkowetz D. Meyer L. Eggert A. Mankin May 2007 ASCII HTML 21 document shepherding ietf documents

This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication. Before this, the Area Director responsible for the working group has traditionally filled the shepherding role. This memo provides information for the Internet community.

 draft-ietf-proto-wgchair-doc-shepherding-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4858 RFC4859 Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object A. Farrel April 2007 ASCII HTML 5

This document provides instructions to IANA for the creation of a new codepoint registry for the flags field in the Session Attribute object of the Resource Reservation Protocol Traffic Engineering (RSVP-TE) signaling messages used in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) signaling. This memo provides information for the Internet community.

 draft-ietf-mpls-iana-rsvp-session-flags-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4859 RFC4860 Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations F. Le Faucheur B. Davie P. Bose C. Christou M. Davenport May 2007 ASCII HTML 32 session object session of interest phb per hop behavior

RFC 3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. RFC 3175 also defines how end-to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in RFC 3175. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network. [STANDARDS-TRACK]

 draft-ietf-tsvwg-rsvp-ipsec-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4860 RFC4861 Neighbor Discovery for IP version 6 (IPv6) T. Narten E. Nordmark W. Simpson H. Soliman September 2007 ASCII HTML 97 IPV6-ND internet protocol link-layer link-layer address

This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]

 draft-ietf-ipv6-2461bis-11 RFC2461 RFC5942 RFC6980 RFC7048 RFC7527 RFC7559 RFC8028 RFC8319 RFC8425 RFC9131 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4861 10.17487/RFC4861 RFC4862 IPv6 Stateless Address Autoconfiguration S. Thomson T. Narten T. Jinmei September 2007 ASCII HTML 30 IPV6-AUTO host link-local internet protocol version 6 link-local address duplicate address detection

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]

 draft-ietf-ipv6-rfc2462bis-08 RFC2462 RFC7527 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4862 10.17487/RFC4862 RFC4863 Wildcard Pseudowire Type L. Martini G. Swallow May 2007 ASCII HTML 6 pw type pw

Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions. For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint. In any form of LDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP. In order to allow the initiation of these two LSPs to remain independent, a means is needed for allowing the PW endpoint (lacking a priori knowledge of the PW Type) to initiate the creation of an LSP. This document defines a Wildcard PW Type to satisfy this need. [STANDARDS-TRACK]

 draft-ietf-pwe3-wildcard-pw-type-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4863 RFC4864 Local Network Protection for IPv6 G. Van de Velde T. Hain R. Droms B. Carpenter E. Klein May 2007 ASCII HTML 36 ipv6 address protection nat

Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation. This memo provides information for the Internet community.

 draft-ietf-v6ops-nap-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4864 RFC4865 SMTP Submission Service Extension for Future Message Release G. White G. Vaudreuil May 2007 ASCII HTML 11 simple mail transfer protocol future-release-integer

This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. [STANDARDS-TRACK]

 draft-vaudreuil-futuredelivery-04 RFC3463 RFC3464 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4865 10.17487/RFC4865 RFC4866 Enhanced Route Optimization for Mobile IPv6 J. Arkko C. Vogt W. Haddad May 2007 ASCII HTML 54 mobility cryptographically generated addresses cga credit-based authorization cba

This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead. [STANDARDS-TRACK]

 draft-ietf-mipshop-cga-cba-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=4866 10.17487/RFC4866 RFC4867 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs J. Sjoberg M. Westerlund A. Lakaniemi Q. Xie April 2007 ASCII HTML 59 interoperate applications

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-amr-bis-06 RFC3267 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4867 10.17487/RFC4867 RFC4868 Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec S. Kelly S. Frankel May 2007 ASCII HTML 21 hashed authentication mode data authentication integrity verification

This specification describes the use of Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512. [STANDARDS-TRACK]

 draft-kelly-ipsec-ciph-sha2-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4868 10.17487/RFC4868 RFC4869 Suite B Cryptographic Suites for IPsec L. Law J. Solinas May 2007 ASCII HTML 9 ui suites user interface suites elliptic curve ike

This document proposes four optional cryptographic user interface suites ("UI suites") for IPsec, similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. This memo provides information for the Internet community.

 draft-solinas-ui-suites-01 RFC6379 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4869 RFC4870 Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys) M. Delany May 2007 ASCII HTML 41

"DomainKeys" creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email.

This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today.

Proof and protection of email identity may assist in the global control of "spam" and "phishing". This memo defines a Historic Document for the Internet community.

 draft-delany-domainkeys-base-06 RFC4871 HISTORIC HISTORIC IETF NON WORKING GROUP 10.17487/RFC4870 RFC4871 DomainKeys Identified Mail (DKIM) Signatures E. Allman J. Callas M. Delany M. Libbey J. Fenton M. Thomas May 2007 ASCII HTML 71 internet mail authentication spam phishing spoofing digital signature

DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing". [STANDARDS-TRACK]

 draft-ietf-dkim-base-10 RFC4870 RFC6376 RFC5672 PROPOSED STANDARD PROPOSED STANDARD IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=4871 10.17487/RFC4871 RFC4872 RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery J.P. Lang Editor Y. Rekhter Editor D. Papadimitriou Editor May 2007 ASCII HTML 47 resource reservation protocol traffic engineering

This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04 RFC3471 RFC4873 RFC6780 RFC9270 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4872 10.17487/RFC4872 RFC4873 GMPLS Segment Recovery L. Berger I. Bryskin D. Papadimitriou A. Farrel May 2007 ASCII HTML 25 generalized multipoint label switching rsvp-te resource reservation protocol traffic engineering NOTIFY_REQUEST

This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). Implications and interactions with fast reroute are also addressed. This document also updates the handling of NOTIFY_REQUEST objects. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-segment-recovery-03 RFC3473 RFC4872 RFC9270 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4873 10.17487/RFC4873 RFC4874 Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) CY. Lee A. Farrel S. De Cnodder April 2007 ASCII HTML 27 srlg shared risk link groups

This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE).

The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded.

In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SRLGs) can be excluded is also specified in this document. [STANDARDS-TRACK]

 draft-ietf-ccamp-rsvp-te-exclude-route-06 RFC3209 RFC3473 RFC6001 RFC8390 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4874 10.17487/RFC4874 RFC4875 Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) R. Aggarwal Editor D. Papadimitriou Editor S. Yasukawa Editor May 2007 ASCII HTML 53 p2mp point-to-multipoint traffic engineering

This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.

There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK]

 draft-ietf-mpls-rsvp-te-p2mp-07 RFC6510 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4875 10.17487/RFC4875 RFC4876 A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents B. Neal-Joslin Editor L. Howard M. Ansari May 2007 ASCII HTML 39 ldap schema profile configuration nameservice nss pam_ldap nss_ldap rfc2307 rfc 2307

This document consists of two primary components, a schema for agents that make use of the Lightweight Directory Access protocol (LDAP) and a proposed use case of that schema, for distributed configuration of similar directory user agents. A set of attribute types and an object class are proposed. In the proposed use case, directory user agents (DUAs) can use this schema to determine directory data location and access parameters for specific services they support. In addition, in the proposed use case, attribute and object class mapping allows DUAs to reconfigure their expected (default) schema to match that of the end user's environment. This document is intended to be a skeleton for future documents that describe configuration of specific DUA services. This memo provides information for the Internet community.

 draft-joslin-config-schema-17 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4876 10.17487/RFC4876 RFC4877 Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture V. Devarapalli F. Dupont April 2007 ASCII HTML 26 Bootstrapping MIP6 Selector Granularity Mobility Header EAP Authentication

This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. [STANDARDS-TRACK]

 draft-ietf-mip6-ikev2-ipsec-08 RFC3776 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4877 10.17487/RFC4877 RFC4878 Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces M. Squire June 2007 ASCII HTML 58 efm ethernet in the first mile snmp DOT3-OAM-MIB

This document defines objects for managing Operations, Administration, and Maintenance (OAM) capabilities on Ethernet-like interfaces conformant to the Ethernet OAM functionality defined in the Ethernet in the First Mile (EFM) clauses of the Ethernet standards. The Ethernet OAM functionality is complementary to the Simple Network Management Protocol (SNMP) in that it is focused on a small set of link-specific functions for directly connected Ethernet interfaces. This document defines objects for controlling those link OAM functions and for providing results and status of the OAM functions to management entities. [STANDARDS-TRACK]

 draft-ietf-hubmib-efm-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC4878 RFC4879 Clarification of the Third Party Disclosure Procedure in RFC 3979 T. Narten April 2007 ASCII HTML 4 ipr copyright

This document clarifies and updates a single sentence in RFC 3979. Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is that the IETF Executive Director notify the IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC 3979 rules. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-narten-ipr-3979-3rd-party-fix-00 RFC8179 RFC3979 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC4879 RFC4880 OpenPGP Message Format J. Callas L. Donnerhacke H. Finney D. Shaw R. Thayer November 2007 ASCII HTML 90 public-key cryptography symmetric cryptography

This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.

OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK]

 draft-ietf-openpgp-rfc2440bis-22 RFC1991 RFC2440 RFC5581 PROPOSED STANDARD PROPOSED STANDARD IETF sec openpgp http://www.rfc-editor.org/errata_search.php?rfc=4880 10.17487/RFC4880 RFC4881 Low-Latency Handoffs in Mobile IPv4 K. El Malki Editor June 2007 ASCII HTML 64 mip4

Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mobileip-lowlatency-handoffs-v4-11 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC4881 RFC4882 IP Address Location Privacy and Mobile IPv6: Problem Statement R. Koodli May 2007 ASCII HTML 11 internet protocol home address care-of address

In this document, we discuss location privacy as applicable to Mobile IPv6. We document the concerns arising from revealing a Home Address to an onlooker and from disclosing a Care-of Address to a correspondent. This memo provides information for the Internet community.

 draft-ietf-mip6-location-privacy-ps-06 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4882 RFC4883 Benchmarking Terminology for Resource Reservation Capable Routers G. Feher K. Nemeth A. Korn I. Cselenyi July 2007 ASCII HTML 24 intserv integrated services benchmarking methodologies

The primary purpose of this document is to define terminology specific to the benchmarking of resource reservation signaling of Integrated Services (IntServ) IP routers. These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements. This memo provides information for the Internet community.

 draft-ietf-bmwg-benchres-term-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4883 RFC4884 Extended ICMP to Support Multi-Part Messages R. Bonica D. Gan D. Tappan C. Pignataro April 2007 ASCII HTML 19 internet control message protocol length attribute

This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.

Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format.

This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field.

The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented.

This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK]

 draft-bonica-internet-icmp-16 RFC0792 RFC4443 RFC8335 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4884 10.17487/RFC4884 RFC4885 Network Mobility Support Terminology T. Ernst H-Y. Lach July 2007 ASCII HTML 19 nemo

This document defines a terminology for discussing network mobility (NEMO) issues and solution requirements. This memo provides information for the Internet community.

 draft-ietf-nemo-terminology-06 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4885 10.17487/RFC4885 RFC4886 Network Mobility Support Goals and Requirements T. Ernst July 2007 ASCII HTML 13 nemo

Network mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such a type of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution. This memo provides information for the Internet community.

 draft-ietf-nemo-requirements-06 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4886 10.17487/RFC4886 RFC4887 Network Mobility Home Network Models P. Thubert R. Wakikawa V. Devarapalli July 2007 ASCII HTML 19 nemo mobile routers

This paper documents some of the usage patterns and the associated issues when deploying a Home Network for Network Mobility (NEMO)- enabled Mobile Routers, conforming to the NEMO Basic Support. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO-related mailing lists. This memo provides information for the Internet community.

 draft-ietf-nemo-home-network-models-06 INFORMATIONAL INFORMATIONAL IETF int nemo 10.17487/RFC4887 RFC4888 Network Mobility Route Optimization Problem Statement C. Ng P. Thubert M. Watari F. Zhao July 2007 ASCII HTML 26 nemo

With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems and provides the motivation behind Route Optimization (RO) for NEMO. This memo provides information for the Internet community.

 draft-ietf-nemo-ro-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4888 10.17487/RFC4888 RFC4889 Network Mobility Route Optimization Solution Space Analysis C. Ng F. Zhao M. Watari P. Thubert July 2007 ASCII HTML 38 nemo mrha mobile router and home agent ro

With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the Mobile Router and Home Agent (MRHA) tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization. This memo provides information for the Internet community.

 draft-ietf-nemo-ro-space-analysis-03 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4889 10.17487/RFC4889 RFC4890 Recommendations for Filtering ICMPv6 Messages in Firewalls E. Davies J. Mohacsi May 2007 ASCII HTML 38 Internet Control Message Protocol version 6 ipv6 security filter firewall icmpv6

In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning.

This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages that are potential security risks. This memo provides information for the Internet community.

 draft-ietf-v6ops-icmpv6-filtering-recs-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4890 10.17487/RFC4890 RFC4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels R. Graveman M. Parthasarathy P. Savola H. Tschofenig May 2007 ASCII HTML 23 internet protocol internet protocol security ip security

This document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec in transport mode. No additional protocol extensions are described beyond those available with the IPsec framework. This memo provides information for the Internet community.

 draft-ietf-v6ops-ipsec-tunnels-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4891 RFC4892 Requirements for a Mechanism Identifying a Name Server Instance S. Woolf D. Conrad June 2007 ASCII HTML 8 domain name service dns name server

With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid for administrators. Existing ad hoc mechanisms for addressing this need have some shortcomings, not the least of which is the lack of prior analysis of exactly how such a mechanism should be designed and deployed. This document describes the existing convention used in some widely deployed implementations of the DNS protocol, including advantages and disadvantages, and discusses some attributes of an improved mechanism. This memo provides information for the Internet community.

 draft-ietf-dnsop-serverid-08 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC4892 RFC4893 BGP Support for Four-octet AS Number Space Q. Vohra E. Chen May 2007 ASCII HTML 10 autonomous system border gateway protocol

Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. [STANDARDS-TRACK]

 draft-ietf-idr-as4bytes-13 RFC6793 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC4893 RFC4894 Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec P. Hoffman May 2007 ASCII HTML 11 md5 pkix certificates

This document describes how the IKEv1 (Internet Key Exchange version 1), IKEv2, and IPsec protocols use hash functions, and explains the level of vulnerability of these protocols to the reduced collision resistance of the MD5 and SHA-1 hash algorithms. This memo provides information for the Internet community.

 draft-hoffman-ike-ipsec-hash-use-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4894 RFC4895 Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) M. Tuexen R. Stewart P. Lei E. Rescorla August 2007 ASCII HTML 19 chunk type shared keys RANDOM CHUNKS HMAC-ALGO

This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. [STANDARDS-TRACK]

 draft-ietf-tsvwg-sctp-auth-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4895 10.17487/RFC4895 RFC4896 Signaling Compression (SigComp) Corrections and Clarifications A. Surtees M. West A.B. Roach June 2007 ASCII HTML 28 sip session initiation protocol udvm universal decompressor virtual machine algorithm

This document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document updates the following RFCs: RFC 3320, RFC 3321, and RFC 3485. [STANDARDS-TRACK]

 draft-ietf-rohc-sigcomp-impl-guide-10 RFC3320 RFC3321 RFC3485 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4896 RFC4897 Handling Normative References to Standards-Track Documents J. Klensin S. Hartman June 2007 ASCII HTML 6

The Internet Engineering Task Force (IETF) and Request for Comments (RFC) Editor have a long-standing rule that a document at a given maturity level cannot be published until all of the documents that it references as normative are at that maturity level or higher. This rule has sometimes resulted in very long publication delays for documents and some claims that it was a major obstruction to advancing documents in maturity level. The IETF agreed on a way to bypass this rule with RFC 3967. This document describes a simpler procedure for downward references to Standards-Track and Best Current Practice (BCP) documents, namely "note and move on". The procedure in RFC 3967 still applies for downward references to other classes of documents. In both cases, annotations should be added to such References. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-klensin-norm-ref-04 RFC3967 BCP0097 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4897 10.17487/RFC4897 RFC4898 TCP Extended Statistics MIB M. Mathis J. Heffner R. Raghunarayan May 2007 ASCII HTML 75 transmission control protocol management information base TCP-ESTATS-MIB

This document describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network-based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver, or the network itself. If the bottleneck is in the network, TCP can provide specific information about its nature. [STANDARDS-TRACK]

 draft-ietf-tsvwg-tcp-mib-extension-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4898 RFC4899 RFC4900 RFC4901 Protocol Extensions for Header Compression over MPLS J. Ash Editor J. Hand Editor A. Malis Editor June 2007 ASCII HTML 34 multiprotocol label switching hc

This specification defines how to use Multi-Protocol Label Switching (MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path. HC can significantly reduce packet-header overhead and, in combination with MPLS, can also increases bandwidth efficiency and processing scalability in terms of the maximum number of simultaneous compressed flows that use HC at each router). Here we define how MPLS pseudowires are used to transport the HC context and control messages between the ingress and egress MPLS label switching routers. This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP. This specification also describes extension mechanisms to allow support for future, as yet to be defined, HC protocols. In this specification, each HC protocol operates independently over a single pseudowire instance, very much as it would over a single point-to-point link. [STANDARDS-TRACK]

 draft-ietf-avt-hc-over-mpls-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4901 RFC4902 Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP M. Stecher May 2007 ASCII HTML 14

The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework. Previous work has focused on HTTP and work for SMTP is in progress. These protocols differ fundamentally in the way data flows, and it turns out that existing OPES requirements and IAB considerations for OPES need to be reviewed with regards to how well they fit for SMTP adaptation. This document analyzes aspects about the integrity of SMTP and mail message adaptation by OPES systems and about privacy and security issues when the OPES framework is adapted to SMTP. It also lists requirements that must be considered when creating the "SMTP adaptation with OPES" document.

The intent of this document is to capture this information before the current OPES working group shuts down. This is to provide input for subsequent working groups or individual contributors that may pick up the OPES/SMTP work at a later date. This memo provides information for the Internet community.

 draft-ietf-opes-smtp-security-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC4902 RFC4903 Multi-Link Subnet Issues D. Thaler June 2007 ASCII HTML 17

There have been several proposals around the notion that a subnet may span multiple links connected by routers. This memo documents the issues and potential problems that have been raised with such an approach. This memo provides information for the Internet community.

 draft-iab-multilink-subnet-issues-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4903 RFC4904 Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs) V. Gurbani C. Jennings June 2007 ASCII HTML 19 SIP TEL Trunk group trunkgroup PSTN

This document describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs). An extension to the tel URI is defined for this purpose. [STANDARDS-TRACK]

 draft-ietf-iptel-trunk-group-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC4904 RFC4905 Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks L. Martini Editor E. Rosen Editor N. El-Aawar Editor June 2007 ASCII HTML 20 multiprotocol label switching pdu protocol data unit draft-martini

This document describes methods for encapsulating the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM), or Ethernet for transport across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents. This memo defines a Historic Document for the Internet community.

 draft-martini-l2circuit-encap-mpls-12 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4905 10.17487/RFC4905 RFC4906 Transport of Layer 2 Frames Over MPLS L. Martini Editor E. Rosen Editor N. El-Aawar Editor June 2007 ASCII HTML 22 multiprotocol label switching pdu protocol data unit sonet synchronized optical network

This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for providing a Synchronized Optical Network (SONET) circuit emulation service across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents. This memo defines a Historic Document for the Internet community.

 draft-martini-l2circuit-trans-mpls-19 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4906 10.17487/RFC4906 RFC4907 Architectural Implications of Link Indications B. Aboba Editor June 2007 ASCII HTML 62

A link indication represents information provided by the link layer to higher layers regarding the state of the link. This document describes the role of link indications within the Internet architecture. While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance. This document summarizes current proposals, describes the architectural issues, and provides examples of appropriate and inappropriate uses of link indications. This memo provides information for the Internet community.

 draft-iab-link-indications-10 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4907 10.17487/RFC4907 RFC4908 Multi-homing for small scale fixed network Using Mobile IP and NEMO K. Nagami S. Uda N. Ogashiwa H. Esaki R. Wakikawa H. Ohnishi June 2007 ASCII HTML 10 care-of addresses

Multihoming technology improves the availability of host and network connectivity. Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed. This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963). The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care-of Addresses (CoAs) can be used. In addition, multiple Home Agents (HAs) that are located in different places are required for redundancy. This memo defines an Experimental Protocol for the Internet community.

 draft-nagami-mip6-nemo-multihome-fixed-network-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4908 RFC4909 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport L. Dondeti Editor D. Castleford F. Hartung June 2007 ASCII HTML 7 short-term key message long-term key message oma bac browser and content broadcast

This document specifies a new Multimedia Internet KEYing (MIKEY) General Extension payload (RFC 3830) to transport the short-term key message (STKM) and long-term key message (LTKM) payloads defined in the Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast (BCAST) group's Service and Content protection specification. This memo provides information for the Internet community.

 draft-dondeti-msec-mikey-genext-oma-04 RFC5410 RFC6309 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4909 10.17487/RFC4909 RFC4910 Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1) S. Legg D. Prager July 2007 ASCII HTML 80 extensible markup language canonical rxer crxer

This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type. Rules for producing a canonical RXER encoding are also defined. This memo defines an Experimental Protocol for the Internet community.

 draft-legg-xed-rxer-07 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4910 RFC4911 Encoding Instructions for the Robust XML Encoding Rules (RXER) S. Legg July 2007 ASCII HTML 91 extensible markup language asn.1 abstract syntax notation one robust xml encoding rules rxer canonical robust xml encoding rules crxer asn.x

This document defines encoding instructions that may be used in an Abstract Syntax Notation One (ASN.1) specification to alter how ASN.1 values are encoded by the Robust XML Encoding Rules (RXER) and Canonical Robust XML Encoding Rules (CRXER), for example, to encode a component of an ASN.1 value as an Extensible Markup Language (XML) attribute rather than as a child element. Some of these encoding instructions also affect how an ASN.1 specification is translated into an Abstract Syntax Notation X (ASN.X) specification. Encoding instructions that allow an ASN.1 specification to reference definitions in other XML schema languages are also defined. This memo defines an Experimental Protocol for the Internet community.

 draft-legg-xed-rxer-ei-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4911 RFC4912 Abstract Syntax Notation X (ASN.X) S. Legg July 2007 ASCII HTML 165 extensible markup language asn.1 abstract syntax notation one robust xml encoding rules rxer

Abstract Syntax Notation X (ASN.X) is a semantically equivalent Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications. ASN.X, together with the Robust XML Encoding Rules (RXER), constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents. This memo defines an Experimental Protocol for the Internet community.

 draft-legg-xed-asd-07 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4912 RFC4913 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER) S. Legg July 2007 ASCII HTML 9 extensible markup language

Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the Generic String Encoding Rules (GSER). This memo defines an Experimental Protocol for the Internet community.

 draft-legg-xed-asd-gserei-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4913 RFC4914 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER) S. Legg July 2007 ASCII HTML 38 extensible markup language

Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the XML Encoding Rules (XER). This memo defines an Experimental Protocol for the Internet community.

 draft-legg-xed-asd-xerei-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4914 RFC4915 Multi-Topology (MT) Routing in OSPF P. Psenak S. Mirtorabi A. Roy L. Nguyen P. Pillay-Esnault June 2007 ASCII HTML 20 open shortest path first

This document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi- Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology.

An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK]

 draft-ietf-ospf-mt-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC4915 RFC4916 Connected Identity in the Session Initiation Protocol (SIP) J. Elwell June 2007 ASCII HTML 24 user agent ua application-layer application layer multimedia multicast unicast

This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). [STANDARDS-TRACK]

 draft-ietf-sip-connected-identity-05 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4916 RFC4917 Mobile IPv4 Message String Extension V. Sastry K. Leung A. Patel June 2007 ASCII HTML 7 home agent foreign agent registration reply

This document specifies a new extension for use in Mobile IPv4. This extension can be added by the Home Agent and the Foreign Agent to Registration Reply messages. This extension carries a text string that is intended for the user of the Mobile Node. [STANDARDS-TRACK]

 draft-ietf-mip4-message-string-ext-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC4917 RFC4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) L. Dusseault Editor June 2007 ASCII HTML 127 WEBDAV hypertext transfer protocol web content

Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).

RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience. [STANDARDS-TRACK]

 draft-ietf-webdav-rfc2518bis-18 RFC2518 RFC5689 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav http://www.rfc-editor.org/errata_search.php?rfc=4918 10.17487/RFC4918 RFC4919 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals N. Kushalnagar G. Montenegro C. Schumacher August 2007 ASCII HTML 12 ieee 802.15.4

This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. This memo provides information for the Internet community.

 draft-ietf-6lowpan-problem-08 INFORMATIONAL INFORMATIONAL IETF int 6lowpan http://www.rfc-editor.org/errata_search.php?rfc=4919 10.17487/RFC4919 RFC4920 Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE A. Farrel Editor A. Satyanarayana A. Iwata N. Fujita G. Ash July 2007 ASCII HTML 38 multiprotocol label switching generalized multiprotocol label switching traffic engineered te lsp label switched path

In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node.

This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. [STANDARDS-TRACK]

 draft-ietf-ccamp-crankback-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4920 10.17487/RFC4920 RFC4921 RFC4922 RFC4923 Quality of Service (QoS) Signaling in a Nested Virtual Private Network F. Baker P. Bose August 2007 ASCII HTML 38 vpn nested vpn integrated services

Some networks require communication between an interior and exterior portion of a Virtual Private Network (VPN) or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions based on the framework for Integrated Services operation over Diffserv networks as described in RFC 2998. This memo provides information for the Internet community.

 draft-ietf-tsvwg-vpn-signaled-preemption-02 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC4923 RFC4924 Reflections on Internet Transparency B. Aboba Editor E. Davies July 2007 ASCII HTML 15

This document provides a review of previous IAB statements on Internet transparency, as well a discussion of new transparency issues. Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication. This document provides some specific illustrations of those potential impacts. This memo provides information for the Internet community.

 draft-iab-net-transparent-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4924 RFC4925 Softwire Problem Statement X. Li Editor S. Dawkins Editor D. Ward Editor A. Durand Editor July 2007 ASCII HTML 23

This document captures the problem statement for the Softwires Working Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks. The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope. This memo provides information for the Internet community.

 draft-ietf-softwire-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF int softwire 10.17487/RFC4925 RFC4926 A URN Namespace for GEANT T. Kalin M. Molina July 2007 ASCII HTML 9 uniform resource name dante

This document describes a proposed URN (Uniform Resource Name) namespace that would be managed by DANTE, representing European Research and academic networks, for naming persistent resources defined by GEANT, the Consortium of European Academic and Research Networks, its projects, activities, working groups, and other designated subordinates. This memo provides information for the Internet community.

 draft-kalin-geant-urn-namespace-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4926 RFC4927 Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering J.-L. Le Roux Editor June 2007 ASCII HTML 12 gmpls te-lsp traffic engineered label switched path pce path computation element

For scalability purposes, a network may comprise multiple Interior Gateway Protocol (IGP) areas. An inter-area Traffic Engineered Label Switched Path (TE-LSP) is an LSP that transits through at least two IGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end Label Switching Router (LSR) cannot compute an inter-area shortest constrained path. One key application of the Path Computation Element (PCE)-based architecture is the computation of inter-area TE-LSP paths. The PCE Communication Protocol (PCECP) is used to communicate computation requests from Path Computation Clients (PCCs) to PCEs, and to return computed paths in responses. This document lists a detailed set of PCECP-specific requirements for support of inter-area TE-LSP path computation. It complements the generic requirements for a PCE Communication Protocol. This memo provides information for the Internet community.

 draft-ietf-pce-pcecp-interarea-reqs-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4927 RFC4928 Avoiding Equal Cost Multipath Treatment in MPLS Networks G. Swallow S. Bryant L. Andersson June 2007 ASCII HTML 8 ecmp

This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. These recommendations rely on inspection of the IP version number field in packets. Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-mpls-ecmp-bcp-03 RFC7274 BCP0128 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4928 10.17487/RFC4928 RFC4929 Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures L. Andersson Editor A. Farrel Editor June 2007 ASCII HTML 23

This document provides guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS working groups' responsibility for the (G)MPLS protocols. This document is directed to multi-vendor fora and Standards Development Organizations (SDOs) to provide an understanding of (G)MPLS work in the IETF and documents the requisite use of IETF review procedures when considering (G)MPLS applications or protocol extensions in their work. This document does not modify IETF processes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-andersson-rtg-gmpls-change-08 BCP0129 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4929 RFC4930 Extensible Provisioning Protocol (EPP) S. Hollenbeck May 2007 ASCII HTML 72 shared framework mapping

This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 3730. [STANDARDS-TRACK]

 draft-hollenbeck-epp-rfc3730bis-04 RFC3730 RFC5730 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4930 RFC4931 Extensible Provisioning Protocol (EPP) Domain Name Mapping S. Hollenbeck May 2007 ASCII HTML 46 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 3731. [STANDARDS-TRACK]

 draft-hollenbeck-epp-rfc3731bis-05 RFC3731 RFC5731 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4931 RFC4932 Extensible Provisioning Protocol (EPP) Host Mapping S. Hollenbeck May 2007 ASCII HTML 30 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 3732. [STANDARDS-TRACK]

 draft-hollenbeck-epp-rfc3732bis-04 RFC3732 RFC5732 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4932 RFC4933 Extensible Provisioning Protocol (EPP) Contact Mapping S. Hollenbeck May 2007 ASCII HTML 43 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 3733. [STANDARDS-TRACK]

 draft-hollenbeck-epp-rfc3733bis-06 RFC3733 RFC5733 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4933 RFC4934 Extensible Provisioning Protocol (EPP) Transport Over TCP S. Hollenbeck May 2007 ASCII HTML 10 mapping client server tls transport layer security

This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 3734. [STANDARDS-TRACK]

 draft-hollenbeck-epp-rfc3734bis-05 RFC3734 RFC5734 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4934 RFC4935 Fibre Channel Fabric Configuration Server MIB C. DeSanti H.K. Vivek K. McCloghrie S. Gai August 2007 ASCII HTML 50 management information base T11-FC-FABRIC-CONFIG-SERVER-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fabric Configuration Server function of a Fibre Channel network. [STANDARDS-TRACK]

 draft-ietf-imss-fc-fcs-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4935 10.17487/RFC4935 RFC4936 Fibre Channel Zone Server MIB C. DeSanti H.K. Vivek K. McCloghrie S. Gai August 2007 ASCII HTML 84 management information base T11-FC-FABRIC-LOCK-MIB T11-FC-ZONE-SERVER-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel Zone Server. [STANDARDS-TRACK]

 draft-ietf-imss-fc-zs-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4936 RFC4937 IANA Considerations for PPP over Ethernet (PPPoE) P. Arberg V. Mammoliti June 2007 ASCII HTML 6

This document describes the IANA considerations for the PPP over Ethernet (PPPoE) protocol. This memo provides information for the Internet community.

 draft-arberg-pppoe-iana-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4937 RFC4938 PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics B. Berry H. Holgate June 2007 ASCII HTML 17

This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with a credit-based flow control mechanism and Link Quality Metric report. This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links. This memo provides information for the Internet community.

 draft-bberry-pppoe-credit-06 RFC5578 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4938 10.17487/RFC4938 RFC4939 Definitions of Managed Objects for iSNS (Internet Storage Name Service) K. Gibbons G. Ramkumar S. Kipp July 2007 ASCII HTML 80 mib management information base iscsi internet small computer system interface ifcp internet fibre channel protocol ISNS-MIB

The iSNS (Internet Storage Name Service) protocol provides storage name service functionality on an IP network that is being used for iSCSI (Internet Small Computer System Interface) or iFCP (Internet Fibre Channel Protocol) storage. This document provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server. [STANDARDS-TRACK]

 draft-ietf-ips-isns-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4939 10.17487/RFC4939 RFC4940 IANA Considerations for OSPF K. Kompella B. Fenner July 2007 ASCII HTML 15 open shortest path first

This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ospf-iana-03 BCP0130 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=4940 10.17487/RFC4940 RFC4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 T. Narten R. Draves S. Krishnan September 2007 ASCII HTML 23 privacy anonymity unlinkability crypto-based address changing

Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. [STANDARDS-TRACK]

 draft-ietf-ipv6-privacy-addrs-v2-05 RFC3041 RFC8981 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4941 10.17487/RFC4941 RFC4942 IPv6 Transition/Co-existence Security Considerations E. Davies S. Krishnan P. Savola September 2007 ASCII HTML 41 internet protocol version 6 dual-protocol network ipv4

The transition from a pure IPv4 network to a network where IPv4 and IPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories:

o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment.

This memo provides information for the Internet community.

 draft-ietf-v6ops-security-overview-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4942 RFC4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful S. Roy A. Durand J. Paugh September 2007 ASCII HTML 8 internet protocol version 6

This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending algorithm. This memo provides information for the Internet community.

 draft-ietf-v6ops-onlinkassumption-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4943 RFC4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks G. Montenegro N. Kushalnagar J. Hui D. Culler September 2007 ASCII HTML 30 internet protocol version 6 link-local address stateless autoconfiguration

This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]

 draft-ietf-6lowpan-format-13 RFC6282 RFC6775 RFC8025 RFC8066 RFC8931 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lowpan http://www.rfc-editor.org/errata_search.php?rfc=4944 10.17487/RFC4944 RFC4945 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX B. Korver August 2007 ASCII HTML 43 internet key exchange public key infrastructure for x.509 ipsec

The Internet Key Exchange (IKE) and Public Key Infrastructure for X.509 (PKIX) certificate profile both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec. The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. The intended audience is implementers of PKI for IPsec. [STANDARDS-TRACK]

 draft-ietf-pki4ipsec-ikecert-profile-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec pki4ipsec 10.17487/RFC4945 RFC4946 Atom License Extension J. Snell July 2007 ASCII HTML 8 atom syndication format atom feeds atom entries

This memo defines an extension to the Atom Syndication Format for describing licenses associated with Atom feeds and entries. This memo defines an Experimental Protocol for the Internet community.

 draft-snell-atompub-feed-license-11 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4946 RFC4947 Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks G. Fairhurst M. Montpetit July 2007 ASCII HTML 41 encapsulate motion picture experts group unidirectional link protocol UniDirectional Link Routing address resolution protocol

This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR) or Neighbor Discovery (ND). Such address resolution complements the higher-layer resource discovery tools that are used to advertise IP sessions.

In MPEG-2 Networks, an IP address must be associated with a Packet ID (PID) value and a specific Transmission Multiplex. This document reviews current methods appropriate to a range of technologies (such as DVB (Digital Video Broadcasting), ATSC (Advanced Television Systems Committee), DOCSIS (Data-Over-Cable Service Interface Specifications), and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol. This memo provides information for the Internet community.

 draft-ietf-ipdvb-ar-06 INFORMATIONAL INFORMATIONAL IETF int ipdvb 10.17487/RFC4947 RFC4948 Report from the IAB workshop on Unwanted Traffic March 9-10, 2006 L. Andersson E. Davies L. Zhang August 2007 ASCII HTML 43 spam botnet

This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on Unwanted Internet Traffic. The workshop was held on March 9-10, 2006 at USC/ISI in Marina del Rey, CA, USA. The primary goal of the workshop was to foster interchange between the operator, standards, and research communities on the topic of unwanted traffic, as manifested in, for example, Distributed Denial of Service (DDoS) attacks, spam, and phishing, to gain understandings on the ultimate sources of these unwanted traffic, and to assess their impact and the effectiveness of existing solutions. It was also a goal of the workshop to identify engineering and research topics that could be undertaken by the IAB, the IETF, the IRTF, and the network research and development community at large to develop effective countermeasures against the unwanted traffic. This memo provides information for the Internet community.

 draft-iab-iwout-report-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4948 10.17487/RFC4948 RFC4949 Internet Security Glossary, Version 2 R. Shirey August 2007 ASCII HTML 365 abbreviation clarity definition dictionary language punctuation synonym terminology writing

This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.

 draft-shirey-secgloss-v2-08 RFC2828 FYI0036 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4949 RFC4950 ICMP Extensions for Multiprotocol Label Switching R. Bonica D. Gan D. Tappan C. Pignataro August 2007 ASCII HTML 8 Internet Control Message Protocol

This memo defines an extension object that can be appended to selected multi-part ICMP messages. This extension permits Label Switching Routers to append MPLS information to ICMP messages, and has already been widely deployed. [STANDARDS-TRACK]

 draft-ietf-mpls-icmp-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4950 RFC4951 Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover" V. Jain Editor August 2007 ASCII HTML 26 control connection layer 2 connectivity

Layer 2 Tunneling Protocol (L2TP) is a connection-oriented protocol that has a shared state between active endpoints. Some of this shared state is vital for operation, but may be volatile in nature, such as packet sequence numbers used on the L2TP Control Connection. When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection. Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid for those parameters that are particularly difficult to have immediately available. Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network, and improving a remote system's layer 2 connectivity. [STANDARDS-TRACK]

 draft-ietf-l2tpext-failover-12 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4951 RFC4952 Overview and Framework for Internationalized Email J. Klensin Y. Ko July 2007 ASCII HTML 20 smtp

Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This memo provides information for the Internet community.

 draft-ietf-eai-framework-05 RFC6530 RFC5336 INFORMATIONAL INFORMATIONAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=4952 10.17487/RFC4952 RFC4953 Defending TCP Against Spoofing Attacks J. Touch July 2007 ASCII HTML 28 rst transport control protocol

Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. This memo provides information for the Internet community.

 draft-ietf-tcpm-tcp-antispoof-06 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC4953 RFC4954 SMTP Service Extension for Authentication R. Siemborski Editor A. Melnikov Editor July 2007 ASCII HTML 20 simple mail transport protocol security layer sasl

This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.

This document obsoletes RFC 2554. [STANDARDS-TRACK]

 draft-siemborski-rfc2554bis-09 RFC2554 RFC3463 RFC5248 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4954 10.17487/RFC4954 RFC4955 DNS Security (DNSSEC) Experiments D. Blacka July 2007 ASCII HTML 7 domain namespace

This document describes a methodology for deploying alternate, non-backwards-compatible, DNS Security (DNSSEC) methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-experiments-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC4955 RFC4956 DNS Security (DNSSEC) Opt-In R. Arends M. Kosters D. Blacka July 2007 ASCII HTML 17 domain namespace

In the DNS security (DNSSEC) extensions, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not always practical or necessary. This document describes an experimental "Opt-In" model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-dnsext-dnssec-opt-in-09 EXPERIMENTAL EXPERIMENTAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4956 10.17487/RFC4956 RFC4957 Link-Layer Event Notifications for Detecting Network Attachments S. Krishnan Editor N. Montavont E. Njedjou S. Veerepalli A. Yegin Editor August 2007 ASCII HTML 18

Certain network access technologies are capable of providing various types of link-layer status information to IP. Link-layer event notifications can help IP expeditiously detect configuration changes. This document provides a non-exhaustive catalogue of information available from well-known access technologies. This memo provides information for the Internet community.

 draft-ietf-dna-link-information-06 INFORMATIONAL INFORMATIONAL IETF int dna http://www.rfc-editor.org/errata_search.php?rfc=4957 10.17487/RFC4957 RFC4958 A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain K. Carlberg July 2007 ASCII HTML 28 priority prioritization preferential service

This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented. This memo provides information for the Internet community.

 draft-ietf-ieprep-domain-frame-08 INFORMATIONAL INFORMATIONAL IETF rai ieprep http://www.rfc-editor.org/errata_search.php?rfc=4958 10.17487/RFC4958 RFC4959 IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response R. Siemborski A. Gulbrandsen September 2007 ASCII HTML 7 imap authenticate internet message access protocol

To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round-trip costs are high.

This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. [STANDARDS-TRACK]

 draft-siemborski-imap-sasl-initial-response-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4959 10.17487/RFC4959 RFC4960 Stream Control Transmission Protocol R. Stewart Editor September 2007 ASCII HTML 152 SCTP IP internet transport packet network

This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.

SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:

-- acknowledged error-free non-duplicated transfer of user data,

-- data fragmentation to conform to discovered path MTU size,

-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,

-- optional bundling of multiple user messages into a single SCTP packet, and

-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.

The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK]

 draft-ietf-tsvwg-2960bis-05 RFC2960 RFC3309 RFC9260 RFC6096 RFC6335 RFC7053 RFC8899 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4960 10.17487/RFC4960 RFC4961 Symmetric RTP / RTP Control Protocol (RTCP) D. Wing July 2007 ASCII HTML 6 real time transport protocol symmetric rtcp

This document recommends using one UDP port pair for both communication directions of bidirectional RTP and RTP Control Protocol (RTCP) sessions, commonly called "symmetric RTP" and "symmetric RTCP". This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-wing-behave-symmetric-rtprtcp-03 BCP0131 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4961 RFC4962 Guidance for Authentication, Authorization, and Accounting (AAA) Key Management R. Housley B. Aboba July 2007 ASCII HTML 23

This document provides guidance to designers of Authentication, Authorization, and Accounting (AAA) key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols. Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization, and Accounting (AAA) protocols. The guidelines in this document apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-housley-aaa-key-mgmt-09 BCP0132 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4962 RFC4963 IPv4 Reassembly Errors at High Data Rates J. Heffner M. Mathis B. Chandler July 2007 ASCII HTML 10

IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. This memo provides information for the Internet community.

 draft-heffner-frag-harmful-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4963 RFC4964 The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular A. Allen Editor J. Holm T. Hallin September 2007 ASCII HTML 32 p-header oma open mobile alliance poc

This document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset, which is particular to the PoC application. This memo provides information for the Internet community.

 draft-allen-sipping-poc-p-answer-state-header-05 RFC8996 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4964 RFC4965 CableLabs - IETF Standardization Collaboration J-F. Mule W. Townsley September 2007 ASCII HTML 10 IETF CableLabs Collaboration liaison Cable Television Laboratories DOCSIS PacketCable OpenCable

This document describes the collaboration and liaison relationship between the Internet Engineering Task Force (IETF) and the Cable Television Laboratories, Inc. (CableLabs). This memo provides information for the Internet community.

 draft-mule-ietf-cablelabs-collaboration-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4965 RFC4966 Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status C. Aoun E. Davies July 2007 ASCII HTML 25 NAT-PT v6ops

This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status. This memo provides information for the Internet community.

 draft-ietf-v6ops-natpt-to-historic-00 RFC2766 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4966 10.17487/RFC4966 RFC4967 Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier B. Rosen July 2007 ASCII HTML 6 dialstring

RFC 3966 explicitly states that 'tel' URIs may not represent a dial string. That leaves no way specify a dial string in a standardized way. Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring", so that one may specify "user=dialstring" to encode a dial string as a 'sip:' or 'sips:' URI. [STANDARDS-TRACK]

 draft-rosen-iptel-dialstring-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4967 10.17487/RFC4967 RFC4968 Analysis of IPv6 Link Models for 802.16 Based Networks S. Madanapalli Editor August 2007 ASCII HTML 16 wimax

This document provides different IPv6 link models that are suitable for IEEE 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios. This document is the result of a design team (DT) that was formed to analyze the IPv6 link models for IEEE 802.16 based networks. This memo provides information for the Internet community.

 draft-ietf-16ng-ipv6-link-model-analysis-03 INFORMATIONAL INFORMATIONAL IETF int 16ng http://www.rfc-editor.org/errata_search.php?rfc=4968 10.17487/RFC4968 RFC4969 IANA Registration for vCard Enumservice A. Mayrhofer August 2007 ASCII HTML 7 enum e.164

This memo registers the Enumservice "vCard" using the URI schemes "http" and "https". This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number.

Information gathered from those vCards could be used before, during, or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. [STANDARDS-TRACK]

 draft-ietf-enum-vcard-06 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4969 RFC4970 Extensions to OSPF for Advertising Optional Router Capabilities A. Lindem Editor N. Shen JP. Vasseur R. Aggarwal S. Shaffer July 2007 ASCII HTML 13 ospfv2 ospfv3 open shortest path first ri router information lsa link state advertisement

It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. A new Router Information (RI) Link State Advertisement (LSA) is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a new LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). [STANDARDS-TRACK]

 draft-ietf-ospf-cap-11 RFC7770 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC4970 RFC4971 Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information JP. Vasseur Editor N. Shen Editor R. Aggarwal Editor July 2007 ASCII HTML 9 capabilty

This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. [STANDARDS-TRACK]

 draft-ietf-isis-caps-07 RFC7981 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC4971 RFC4972 Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership JP. Vasseur Editor JL. Leroux Editor S. Yasukawa S. Previdi P. Psenak P. Mabbey July 2007 ASCII HTML 15 mpls-te lsp label switched path igp is-is ospf

The setup of a full mesh of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSP) among a set of Label Switch Routers (LSR) is a common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of a potentially large number of TE LSPs (on the order of the square of the number of LSRs). This document specifies Interior Gateway Protocol (IGP) routing extensions for Intermediate System-to-Intermediate System (IS-IS) and Open Shortest Path First (OSPF) so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh of TE LSPs. [STANDARDS-TRACK]

 draft-ietf-ccamp-automesh-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4972 RFC4973 OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering P. Srisuresh P. Joseph July 2007 ASCII HTML 50 ospf-te link state advertisement lsa

This document defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF. OSPF-xTE defines new TE Link State Advertisements (LSAs) to disseminate TE metrics within an autonomous System (AS), which may consist of multiple areas. When an AS consists of TE and non-TE nodes, OSPF-xTE ensures that non-TE nodes in the AS are unaffected by the TE LSAs. OSPF-xTE generates a stand-alone TE Link State Database (TE-LSDB), distinct from the native OSPF LSDB, for computation of TE circuit paths. OSPF-xTE is versatile and extendible to non-packet networks such as Synchronous Optical Network (SONET) / Time Division Multiplexing (TDM) and optical networks. This memo defines an Experimental Protocol for the Internet community.

 draft-srisuresh-ospf-te-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4973 RFC4974 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls D. Papadimitriou A. Farrel August 2007 ASCII HTML 31

In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls.

A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In Generalized MPLS (GMPLS) such Connections are known as Label Switched Paths (LSPs).

This document specifies how GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation.

The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda, or fiber switching. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-rsvp-te-call-04 RFC3473 RFC6001 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4974 RFC4975 The Message Session Relay Protocol (MSRP) B. Campbell Editor R. Mahy Editor C. Jennings Editor September 2007 ASCII HTML 63 instant message

This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS-TRACK]

 draft-ietf-simple-message-sessions-19 RFC7977 RFC8591 RFC8873 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4975 10.17487/RFC4975 RFC4976 Relay Extensions for the Message Sessions Relay Protocol (MSRP) C. Jennings R. Mahy A. B. Roach September 2007 ASCII HTML 36 instante message page-mode session-mode relay intermediary

Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. [STANDARDS-TRACK]

 draft-ietf-simple-msrp-relays-10 RFC7977 RFC8553 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4976 10.17487/RFC4976 RFC4977 Problem Statement: Dual Stack Mobility G. Tsirtsis H. Soliman August 2007 ASCII HTML 8 mobility management protocol mipv4 mipv6 mobile ip

This document discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of problems. Deployment and operational issues motivate the use of a single mobility management protocol. This document discusses such motivations. The document also discusses requirements for the Mobile IPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can support mobility management for a dual stack node. This memo provides information for the Internet community.

 draft-ietf-mip6-dsmip-problem-03 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4977 RFC4978 The IMAP COMPRESS Extension A. Gulbrandsen August 2007 ASCII HTML 9 Internet Message Access Protocol

The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed. [STANDARDS-TRACK]

 draft-ietf-lemonade-compress-08 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4978 10.17487/RFC4978 RFC4979 IANA Registration for Enumservice 'XMPP' A. Mayrhofer August 2007 ASCII HTML 7 extensible messaging and presence protocol e.164

This document requests IANA registration of an Enumservice for XMPP, the Extensible Messaging and Presence Protocol. This Enumservice specifically allows the use of 'xmpp' Uniform Resource Identifiers (URIs) in the context of E.164 Number Mapping (ENUM). [STANDARDS-TRACK]

 draft-ietf-enum-xmpp-02 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4979 RFC4980 Analysis of Multihoming in Network Mobility Support C. Ng T. Ernst E. Paik M. Bagnulo October 2007 ASCII HTML 39 nemo ipv6 mobile networks

This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Recommendations are offered on how to address these issues. This memo provides information for the Internet community.

 draft-ietf-nemo-multihoming-issues-07 INFORMATIONAL INFORMATIONAL IETF int nemo 10.17487/RFC4980 RFC4981 Survey of Research towards Robust Peer-to-Peer Networks: Search Methods J. Risson T. Moors September 2007 ASCII HTML 91 Peer-to-peer network Distributed hash table Structured overlay Unstructured overlay Key-based routing Consistent hashing Scalable distributed data structure Dependability Hypercube Plaxton tree de Bruijn graph Skip graph Torus Butterfly network Vector model Latent semantic indexing

The pace of research on peer-to-peer (P2P) networking in the last five years warrants a critical survey. P2P has the makings of a disruptive technology -- it can aggregate enormous storage and processing resources while minimizing entry and scaling costs.

Failures are common amongst massive numbers of distributed peers, though the impact of individual failures may be less than in conventional architectures. Thus, the key to realizing P2P's potential in applications other than casual file sharing is robustness.

P2P search methods are first couched within an overall P2P taxonomy. P2P indexes for simple key lookup are assessed, including those based on Plaxton trees, rings, tori, butterflies, de Bruijn graphs, and skip graphs. Similarly, P2P indexes for keyword lookup, information retrieval and data management are explored. Finally, early efforts to optimize range, multi-attribute, join, and aggregation queries over P2P indexes are reviewed. Insofar as they are available in the primary literature, robustness mechanisms and metrics are highlighted throughout. However, the low-level mechanisms that most affect robustness are not well isolated in the literature. Recommendations are given for future research. This memo provides information for the Internet community.

 draft-irtf-p2prg-survey-search-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4981 RFC4982 Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs) M. Bagnulo J. Arkko July 2007 ASCII HTML 9

This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms. [STANDARDS-TRACK]

 draft-bagnulo-multiple-hash-cga-03 RFC3972 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4982 10.17487/RFC4982 RFC4983 Fibre Channel Registered State Change Notification (RSCN) MIB C. DeSanti H.K. Vivek K. McCloghrie S. Gai August 2007 ASCII HTML 28 management information base T11-FC-RSCN-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the management of Fibre Channel's Registered State Change Notifications (RSCNs). [STANDARDS-TRACK]

 draft-ietf-imss-fc-rscn-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4983 RFC4984 Report from the IAB Workshop on Routing and Addressing D. Meyer Editor L. Zhang Editor K. Fall Editor September 2007 ASCII HTML 39 routing and addressing workshop routing table growth addressing architecture

This document reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. This memo provides information for the Internet community.

 draft-iab-raws-report-02 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4984 10.17487/RFC4984 RFC4985 Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name S. Santesson August 2007 ASCII HTML 10 othername

This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. [STANDARDS-TRACK]

 draft-ietf-pkix-srvsan-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4985 10.17487/RFC4985 RFC4986 Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover H. Eland R. Mundy S. Crocker S. Krishnaswamy August 2007 ASCII HTML 11 dns signed zone

Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones. For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible, but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers. This memo provides information for the Internet community.

 draft-ietf-dnsext-rollover-requirements-04 INFORMATIONAL INFORMATIONAL IETF int dnsext 10.17487/RFC4986 RFC4987 TCP SYN Flooding Attacks and Common Mitigations W. Eddy August 2007 ASCII HTML 19 TCP SYN Flood TCP SYN Cookies denial-of-service DoS

This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations. This memo provides information for the Internet community.

 draft-ietf-tcpm-syn-flood-05 INFORMATIONAL INFORMATIONAL IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=4987 10.17487/RFC4987 RFC4988 Mobile IPv4 Fast Handovers R. Koodli C. Perkins October 2007 ASCII HTML 28 mip4 delay packet loss movement detection ip address configuration loation update latency care-of address care of address coa

This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations. Specifically, this document addresses movement detection, IP address configuration, and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-mip4-fmipv4-07 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC4988 RFC4989 RFC4990 Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks K. Shiomoto R. Papneja R. Rabbat September 2007 ASCII HTML 23 address field identifier field

This document clarifies the use of addresses in Generalized Multiprotocol Label Switching (GMPLS) networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers (LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment.

The document describes how to interpret address and identifier fields within GMPLS protocols, and how to choose which addresses to set in those fields for specific control plane usage models. It also discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules.

This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-addressing-08 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4990 RFC4991 A Common Schema for Internet Registry Information Service Transfer Protocols A. Newton August 2007 ASCII HTML 13 iris xml

This document describes an XML Schema for use by Internet Registry Information Service (IRIS) application transfer protocols that share common characteristics. It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms. [STANDARDS-TRACK]

 draft-ietf-crisp-iris-common-transport-05 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4991 10.17487/RFC4991 RFC4992 XML Pipelining with Chunks for the Internet Registry Information Service A. Newton August 2007 ASCII HTML 29 tcp transport control protocol iris

This document describes a simple TCP transfer protocol for the Internet Registry Information Service (IRIS). Data is transferred between clients and servers using chunks to achieve pipelining. [STANDARDS-TRACK]

 draft-ietf-crisp-iris-xpc-06 RFC3981 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4992 10.17487/RFC4992 RFC4993 A Lightweight UDP Transfer Protocol for the Internet Registry Information Service A. Newton August 2007 ASCII HTML 19 iris

This document describes a lightweight UDP transfer protocol for the Internet Registry Information Service (IRIS). This transfer protocol uses a single packet for every request and response, and optionally employs compression over the contents of the packet. [STANDARDS-TRACK]

 draft-ietf-crisp-iris-lwz-08 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4993 10.17487/RFC4993 RFC4994 DHCPv6 Relay Agent Echo Request Option S. Zeng B. Volz K. Kinnear J. Brzozowski September 2007 ASCII HTML 6 dynamic host configuration protocol relay agent option

This memo defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-ero-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4994 RFC4995 The RObust Header Compression (ROHC) Framework L-E. Jonsson G. Pelletier K. Sandlund July 2007 ASCII HTML 40

The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.

The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. [STANDARDS-TRACK]

 draft-ietf-rohc-rfc3095bis-framework-04 RFC5795 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=4995 10.17487/RFC4995 RFC4996 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) G. Pelletier K. Sandlund L-E. Jonsson M. West July 2007 ASCII HTML 94

This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps.

ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. [STANDARDS-TRACK]

 draft-ietf-rohc-tcp-16 RFC6846 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=4996 10.17487/RFC4996 RFC4997 Formal Notation for RObust Header Compression (ROHC-FN) R. Finking G. Pelletier July 2007 ASCII HTML 62 Robust Header Compression - Formal Notation

This document defines Robust Header Compression - Formal Notation (ROHC-FN), a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help to simplify future profile development work. [STANDARDS-TRACK]

 draft-ietf-rohc-formal-notation-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4997 RFC4998 Evidence Record Syntax (ERS) T. Gondrom R. Brandner U. Pordesch August 2007 ASCII HTML 32 long-term archive security timestamp evidence record archive timestamp

In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data. [STANDARDS-TRACK]

 draft-ietf-ltans-ers-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC4998 RFC4999 RFC5000 Internet Official Protocol Standards RFC Editor May 2008 ASCII HTML 75

This document is published by the RFC Editor to provide a summary of the current standards protocols (as of 18 February 2008). It lists those official protocol standards, Best Current Practice, and Experimental RFCs that have not been obsoleted; it is not a complete index to the RFC series. Newly published RFCs and RFCs whose status has changed are starred.

For an up-to-date list, see http://www.rfc-editor.org/rfcxx00.html, which is updated daily. This memo provides information for the Internet community.

 RFC3700 RFC7100 HISTORIC INFORMATIONAL INDEPENDENT 10.17487/RFC5000 RFC5001 DNS Name Server Identifier (NSID) Option R. Austein August 2007 ASCII HTML 11 domain name space namespace

With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. [STANDARDS-TRACK]

 draft-ietf-dnsext-nsid-02 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5001 RFC5002 The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header) G. Camarillo G. Blanco August 2007 ASCII HTML 7 3gpp ims ip multimedia subsystem

This document specifies the SIP P-Profile-Key P-header. This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the key of the profile corresponding to the destination SIP URI of a particular SIP request. This memo provides information for the Internet community.

 draft-camarillo-sipping-profile-key-02 RFC8217 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5002 10.17487/RFC5002 RFC5003 Attachment Individual Identifier (AII) Types for Aggregation C. Metz L. Martini F. Balus J. Sugimoto September 2007 ASCII HTML 7 tlv pseudowire

The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AIIs). This document defines AII structures in the form of new AII TLV fields that support AII aggregation for improved scalability and Virtual Private Network (VPN) auto-discovery. It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote provider edge (PE) nodes based on customer need. [STANDARDS-TRACK]

 draft-ietf-pwe3-aii-aggregate-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5003 10.17487/RFC5003 RFC5004 Avoid BGP Best Path Transitions from One External to Another E. Chen S. Sangli September 2007 ASCII HTML 6 border gateway protocol

In this document, we propose an extension to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed extension would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external path from one BGP speaker contributes to the churn. [STANDARDS-TRACK]

 draft-ietf-idr-avoid-transition-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC5004 RFC5005 Feed Paging and Archiving M. Nottingham September 2007 ASCII HTML 15 atom rss

This specification defines three types of syndicated Web feeds that enable publication of entries across one or more feed documents. This includes "paged" feeds for piecemeal access, "archived" feeds that allow reconstruction of the feed's contents, and feeds that are explicitly "complete". [STANDARDS-TRACK]

 draft-nottingham-atompub-feed-history-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5005 10.17487/RFC5005 RFC5006 IPv6 Router Advertisement Option for DNS Configuration J. Jeong Editor S. Park L. Beloeil S. Madanapalli September 2007 ASCII HTML 12 domain namespace

This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts. This memo defines an Experimental Protocol for the Internet community.

 draft-jeong-dnsop-ipv6-dns-discovery-12 RFC6106 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5006 RFC5007 DHCPv6 Leasequery J. Brzozowski K. Kinnear B. Volz S. Zeng September 2007 ASCII HTML 23 dhc dhcp ipv6

This document specifies a leasequery exchange for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) that can be used to obtain lease information about DHCPv6 clients from a DHCPv6 server. This document specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. This document extends DHCPv6. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-leasequery-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=5007 10.17487/RFC5007 RFC5008 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) R. Housley J. Solinas September 2007 ASCII HTML 15 nsa

This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 3851. This memo provides information for the Internet community.

 draft-housley-smime-suite-b-02 RFC6318 HISTORIC INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5008 10.17487/RFC5008 RFC5009 Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media R. Ejza September 2007 ASCII HTML 15 IMS NGN ETSI TISPAN Gating Cut-through Call progress Charging PSTN Interworking Gateway Ringback Trust domain

This document describes a private Session Initiation Protocol (SIP) header field (P-header) to be used by the European Telecommunications Standards Institute (ETSI) Telecommunications and Internet-converged Services and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation Partnership Project (3GPP) IP Multimedia Subsystems (IMS). This header field is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state. This memo provides information for the Internet community.

 draft-ejzak-sipping-p-em-auth-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5009 RFC5010 The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption K. Kinnear M. Normoyle M. Stapp September 2007 ASCII HTML 7 unicast flag broadcast flag

This memo defines a new suboption of the Dynamic Host Configuration Protocol (DHCP) relay agent information option that allows the DHCP relay to specify flags for the forwarded packet. One flag is defined to indicate whether the DHCP relay received the packet via a unicast or broadcast packet. This information may be used by the DHCP server to better serve clients based on whether their request was originally broadcast or unicast. [STANDARDS-TRACK]

 draft-ietf-dhc-relay-agent-flags-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5010 RFC5011 Automated Updates of DNS Security (DNSSEC) Trust Anchors M. StJohns September 2007 ASCII HTML 14 n-1 key n keys

This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).

This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK]

 draft-ietf-dnsext-trustupdate-timers-06 STD0074 INTERNET STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5011 RFC5012 Requirements for Emergency Context Resolution with Internet Technologies H. Schulzrinne R. Marshall Editor January 2008 ASCII HTML 23 emergency calling ecrit

This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end to end. This memo provides information for the Internet community.

 draft-ietf-ecrit-requirements-13 INFORMATIONAL INFORMATIONAL IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5012 10.17487/RFC5012 RFC5013 The Dublin Core Metadata Element Set J. Kunze T. Baker August 2007 ASCII HTML 9 resource description object descriptors digital library collections

This document defines fifteen metadata elements for resource description in a cross-disciplinary information environment. This memo provides information for the Internet community.

 draft-kunze-rfc2413bis-07 RFC2413 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5013 RFC5014 IPv6 Socket API for Source Address Selection E. Nordmark S. Chakrabarti J. Laganier September 2007 ASCII HTML 24 getaddrinfo()cga cryptographically generated address

The IPv6 default address selection document (RFC 3484) describes the rules for selecting source and destination IPv6 addresses, and indicates that applications should be able to reverse the sense of some of the address selection rules through some unspecified API. However, no such socket API exists in the basic (RFC 3493) or advanced (RFC 3542) IPv6 socket API documents. This document fills that gap partially by specifying new socket-level options for source address selection and flags for the getaddrinfo() API to specify address selection based on the source address preference in accordance with the socket-level options that modify the default source address selection algorithm. The socket API described in this document will be particularly useful for IPv6 applications that want to choose between temporary and public addresses, and for Mobile IPv6 aware applications that want to use the care-of address for communication. It also specifies socket options and flags for selecting Cryptographically Generated Address (CGA) or non-CGA source addresses. This memo provides information for the Internet community.

 draft-chakrabarti-ipv6-addrselect-api-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5014 RFC5015 Bidirectional Protocol Independent Multicast (BIDIR-PIM) M. Handley I. Kouvelas T. Speakman L. Vicisano October 2007 ASCII HTML 43 pim sparse-mode shared trees

This document discusses Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events. [STANDARDS-TRACK]

 draft-ietf-pim-bidir-09 RFC8736 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5015 10.17487/RFC5015 RFC5016 Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol M. Thomas October 2007 ASCII HTML 15 cryptographic

DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism, distinguishing between those that must be satisfied (MUST), and those that are highly desirable (SHOULD). This memo provides information for the Internet community.

 draft-ietf-dkim-ssp-requirements-05 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC5016 RFC5017 MIB Textual Conventions for Uniform Resource Identifiers (URIs) D. McWalter Editor September 2007 ASCII HTML 7 management information base URI-TC-MIB

This MIB module defines textual conventions to represent STD 66 Uniform Resource Identifiers (URIs). The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representation(s). [STANDARDS-TRACK]

 draft-mcwalter-uri-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5017 RFC5018 Connection Establishment in the Binary Floor Control Protocol (BFCP) G. Camarillo September 2007 ASCII HTML 9 floor control server tls transport layer security

This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS). [STANDARDS-TRACK]

 draft-ietf-xcon-bfcp-connection-05 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC5018 RFC5019 The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments A. Deacon R. Hurst September 2007 ASCII HTML 22 OCSP Online Certificate Status Protocol certificate status http caching http proxies efficient cacheable pre-produced

This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client-side processing. [STANDARDS-TRACK]

 draft-ietf-pkix-lightweight-ocsp-profile-11 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5019 10.17487/RFC5019 RFC5020 The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute K. Zeilenga August 2007 ASCII HTML 5 x.500

This document describes the Lightweight Directory Access Protocol (LDAP) / X.500 'entryDN' operational attribute. The attribute provides a copy of the entry's distinguished name for use in attribute value assertions. [STANDARDS-TRACK]

 draft-zeilenga-ldap-entrydn-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5020 RFC5021 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP S. Josefsson August 2007 ASCII HTML 7

This document describes an extensibility mechanism for the Kerberos V5 protocol when used over TCP transports. The mechanism uses the reserved high-bit in the length field. It can be used to negotiate TCP-specific Kerberos extensions. [STANDARDS-TRACK]

 draft-ietf-krb-wg-tcp-expansion-02 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC5021 RFC5022 Media Server Control Markup Language (MSCML) and Protocol J. Van Dyke E. Burger Editor A. Spitzer September 2007 ASCII HTML 81 sip ivr interactive voice response

Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. This memo provides information for the Internet community.

 RFC4722 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5022 10.17487/RFC5022 RFC5023 The Atom Publishing Protocol J. Gregorio Editor B. de hOra Editor October 2007 ASCII HTML 53 atompub http transfer atom syndication format

The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format. [STANDARDS-TRACK]

 draft-ietf-atompub-protocol-17 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF app atompub http://www.rfc-editor.org/errata_search.php?rfc=5023 10.17487/RFC5023 RFC5024 ODETTE File Transfer Protocol 2.0 I. Friend November 2007 ASCII HTML 135

This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2.

The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic Message Syntax, and provides signed receipts for the acknowledgement of received files.

The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used with TCP/IP, X.25, and ISDN-based networks. This memo provides information for the Internet community.

 draft-friend-oftp2-04 RFC2204 RFC8996 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5024 10.17487/RFC5024 RFC5025 Presence Authorization Rules J. Rosenberg December 2007 ASCII HTML 28 presence systems authorization policies xml extensible markup language

Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. [STANDARDS-TRACK]

 draft-ietf-simple-presence-rules-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=5025 10.17487/RFC5025 RFC5026 Mobile IPv6 Bootstrapping in Split Scenario G. Giaretta Editor J. Kempf V. Devarapalli Editor October 2007 ASCII HTML 28 mip6 bootstrapping problem statement

A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the Mobile Node. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers to the case where the Mobile Node's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. [STANDARDS-TRACK]

 draft-ietf-mip6-bootstrapping-split-07 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5026 RFC5027 Security Preconditions for Session Description Protocol (SDP) Media Streams F. Andreasen D. Wing October 2007 ASCII HTML 16 DTLS DTLS-SRTP TLS MIKEY Security Descriptions SRTP

This document defines a new security precondition for the Session Description Protocol (SDP) precondition framework described in RFCs 3312 and 4032. A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully. [STANDARDS-TRACK]

 draft-ietf-mmusic-securityprecondition-04 RFC3312 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5027 RFC5028 A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services R. Mahy October 2007 ASCII HTML 5 'im:' uri uniform resource identifier

This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs (Uniform Resource Identifiers) in ENUM. [STANDARDS-TRACK]

 draft-ietf-enum-im-service-03 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5028 RFC5029 Definition of an IS-IS Link Attribute Sub-TLV JP. Vasseur S. Previdi September 2007 ASCII HTML 6 link-attributes tlv 22

This document defines a sub-TLV called "Link-attributes" carried within the TLV 22 and used to flood some link characteristics. [STANDARDS-TRACK]

 draft-ietf-isis-link-attr-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5029 RFC5030 Mobile IPv4 RADIUS Requirements M. Nakhjiri Editor K. Chowdhury A. Lior K. Leung October 2007 ASCII HTML 9 remote authentication dial-in user service mip mipv4

This document provides an applicability statement as well as a scope definition for specifying Remote Authentication Dial-In User Service (RADIUS) extensions to support Mobile IPv4. The goal is to allow specification of RADIUS attributes to assist the Mobile IPv4 signaling procedures. This memo provides information for the Internet community.

 draft-ietf-mip4-radius-requirements-04 INFORMATIONAL INFORMATIONAL IETF int mip4 10.17487/RFC5030 RFC5031 A Uniform Resource Name (URN) for Emergency and Other Well-Known Services H. Schulzrinne January 2008 ASCII HTML 14 urn ecrit

The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified. Examples include emergency services, directory assistance, and call-before-you-dig hot lines. [STANDARDS-TRACK]

 draft-ietf-ecrit-service-urn-07 RFC7163 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5031 10.17487/RFC5031 RFC5032 WITHIN Search Extension to the IMAP Protocol E. Burger Editor September 2007 ASCII HTML 5 imap search older younger

This document describes the WITHIN extension to IMAP SEARCH. IMAP SEARCH returns messages whose internal date is within or outside a specified interval. The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date. WITHIN is useful for persistent searches where either the device does not have the capacity to perform the search at regular intervals or the network is of limited bandwidth and thus there is a desire to reduce network traffic from sending repeated requests and redundant responses. [STANDARDS-TRACK]

 draft-ietf-lemonade-search-within-05 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5032 RFC5033 Specifying New Congestion Control Algorithms S. Floyd M. Allman August 2007 ASCII HTML 10

The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-tsvwg-cc-alt-04 BCP0133 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC5033 RFC5034 The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism R. Siemborski A. Menon-Sen July 2007 ASCII HTML 12 POP3-AUTH Post Office Protocol Email

This document defines a profile of the Simple Authentication and Security Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session.

This document seeks to consolidate the information related to POP3 AUTH into a single document. To this end, this document obsoletes and replaces RFC 1734, and updates the information contained in Section 6.3 of RFC 2449. [STANDARDS-TRACK]

 draft-siemborski-rfc1734bis-11 RFC1734 RFC2449 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5034 RFC5035 Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility J. Schaad August 2007 ASCII HTML 17 validation signature certificate

In the original Enhanced Security Services for S/MIME document (RFC 2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose. [STANDARDS-TRACK]

 draft-ietf-smime-escertid-06 RFC2634 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5035 10.17487/RFC5035 RFC5036 LDP Specification L. Andersson Editor I. Minei Editor B. Thomas Editor October 2007 ASCII HTML 135 label distribution protocol

The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]

 draft-ietf-mpls-rfc3036bis-04 RFC3036 RFC6720 RFC6790 RFC7358 RFC7552 DRAFT STANDARD DRAFT STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5036 10.17487/RFC5036 RFC5037 Experience with the Label Distribution Protocol (LDP) L. Andersson Editor I. Minei Editor B. Thomas Editor October 2007 ASCII HTML 7

The purpose of this memo is to document how some of the requirements specified in RFC 1264 for advancing protocols developed by working groups within the IETF Routing Area to Draft Standard have been satisfied by LDP (Label Distribution Protocol). Specifically, this report documents operational experience with LDP, requirement 5 of section 5.0 in RFC 1264. This memo provides information for the Internet community.

 draft-ietf-mpls-ldp-experience-00 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5037 RFC5038 The Label Distribution Protocol (LDP) Implementation Survey Results B. Thomas L. Andersson October 2007 ASCII HTML 23 multiprotocol label switching mpls lsr label switched routers

Multiprotocol Label Switching (MPLS), described in RFC 3031, is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet next hops. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a Label Distribution Protocol (as described in RFC 3036) , by which one LSR informs another of label bindings it has made. One such protocol, called LDP, is used by LSRs to distribute labels to support MPLS forwarding along normally routed paths. This document reports on a survey of LDP implementations conducted in August 2002 as part of the process of advancing LDP from Proposed to Draft Standard. This memo provides information for the Internet community.

 draft-ietf-mpls-ldp-survey2002-00 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5038 RFC5039 The Session Initiation Protocol (SIP) and Spam J. Rosenberg C. Jennings January 2008 ASCII HTML 28

Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user-to-user communications. The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP. This memo provides information for the Internet community.

 draft-ietf-sipping-spam-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5039 RFC5040 A Remote Direct Memory Access Protocol Specification R. Recio B. Metzler P. Culley J. Hilland D. Garcia October 2007 ASCII HTML 66 rdmap ddp direct data placement protocol

This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol). RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) Buffers without intermediate data copies. It also enables a kernel bypass implementation. [STANDARDS-TRACK]

 draft-ietf-rddp-rdmap-07 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5040 RFC5041 Direct Data Placement over Reliable Transports H. Shah J. Pinkerton R. Recio P. Culley October 2007 ASCII HTML 38 ddp cpu

The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. [STANDARDS-TRACK]

 draft-ietf-rddp-ddp-07 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5041 RFC5042 Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security J. Pinkerton E. Deleganes October 2007 ASCII HTML 52 rdma network interface card rnic

This document analyzes security issues around implementation and use of the Direct Data Placement Protocol (DDP) and Remote Direct Memory Access Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into those that can be mitigated by using secure communication channels across the network, attacks from Remote Peers, and attacks from Local Peers. Attack categories include spoofing, tampering, information disclosure, denial of service, and elevation of privilege. [STANDARDS-TRACK]

 draft-ietf-rddp-security-10 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5042 RFC5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation C. Bestler Editor R. Stewart Editor October 2007 ASCII HTML 18 lower layer protocol llp

This document specifies an adaptation layer to provide a Lower Layer Protocol (LLP) service for Direct Data Placement (DDP) using the Stream Control Transmission Protocol (SCTP). [STANDARDS-TRACK]

 draft-ietf-rddp-sctp-07 RFC6581 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5043 RFC5044 Marker PDU Aligned Framing for TCP Specification P. Culley U. Elzur R. Recio S. Bailey J. Carrier October 2007 ASCII HTML 74 mpa adaaptation layer ddp direct data placement protocol transmission

Marker PDU Aligned Framing (MPA) is designed to work as an "adaptation layer" between TCP and the Direct Data Placement protocol (DDP) as described in RFC 5041. It preserves the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations. MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level. [STANDARDS-TRACK]

 draft-ietf-rddp-mpa-08 RFC6581 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp http://www.rfc-editor.org/errata_search.php?rfc=5044 10.17487/RFC5044 RFC5045 Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP) C. Bestler Editor L. Coene October 2007 ASCII HTML 22 rdmap

This document describes the applicability of Remote Direct Memory Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP). It compares and contrasts the different transport options over IP that DDP can use, provides guidance to ULP developers on choosing between available transports and/or how to be indifferent to the specific transport layer used, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality. This memo provides information for the Internet community.

 draft-ietf-rddp-applicability-08 RFC7146 INFORMATIONAL INFORMATIONAL IETF tsv rddp 10.17487/RFC5045 RFC5046 Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) M. Ko M. Chadalapaka J. Hufferd U. Elzur H. Shah P. Thaler October 2007 ASCII HTML 85 rdma data transfer

Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol, such as the iWARP protocol suite. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol, such as the iWARP protocol suite. [STANDARDS-TRACK]

 draft-ietf-ips-iser-06 RFC7145 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC5046 RFC5047 DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI) M. Chadalapaka J. Hufferd J. Satran H. Shah October 2007 ASCII HTML 49 scsi transport protocol tcp/ip

The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP. Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports. While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specific Datamover protocols. Each such Datamover protocol, defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself. This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and the Datamover layer that happen in order to transparently perform remote data movement within an IP fabric. It is intended that this definition will help map iSCSI to generic Remote Direct Memory Access (RDMA)-capable IP fabrics in the future comprising TCP, the Stream Control Transmission Protocol (SCTP), and possibly other underlying network transport layers, such as InfiniBand. This memo provides information for the Internet community.

 draft-ietf-ips-iwarp-da-05 RFC7146 INFORMATIONAL INFORMATIONAL IETF tsv ips 10.17487/RFC5047 RFC5048 Internet Small Computer System Interface (iSCSI) Corrections and Clarifications M. Chadalapaka Editor October 2007 ASCII HTML 38 scsi iscsi protocol

The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. [STANDARDS-TRACK]

 draft-ietf-ips-iscsi-impl-guide-09 RFC7143 RFC3720 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC5048 RFC5049 Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) C. Bormann Z. Liu R. Price G. Camarillo Editor December 2007 ASCII HTML 21

This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP and Session Description Protocol (SDP) static dictionary. [STANDARDS-TRACK]

 draft-ietf-rohc-sigcomp-sip-08 RFC3486 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC5049 RFC5050 Bundle Protocol Specification K. Scott S. Burleigh November 2007 ASCII HTML 50 delay tolerant networking dtn dtnrg exchange of messages

This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).

This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-bundle-spec-10 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5050 10.17487/RFC5050 RFC5051 i;unicode-casemap - Simple Unicode Collation Algorithm M. Crispin October 2007 ASCII HTML 7 unicode strings i;ascii-casemap

This document describes "i;unicode-casemap", a simple case-insensitive collation for Unicode strings. It provides equality, substring, and ordering operations. [STANDARDS-TRACK]

 draft-crispin-collation-unicasemap-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5051 RFC5052 Forward Error Correction (FEC) Building Block M. Watson M. Luby L. Vicisano August 2007 ASCII HTML 25 bulk data transfer

This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast. This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information. Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered. The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined. The companion document titled "The Use of Forward Error Correction (FEC) in Reliable Multicast" describes some applications of FEC codes for delivering content. This document obsoletes RFC 3452. [STANDARDS-TRACK]

 draft-ietf-rmt-fec-bb-revised-07 RFC3452 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=5052 10.17487/RFC5052 RFC5053 Raptor Forward Error Correction Scheme for Object Delivery M. Luby A. Shokrollahi M. Watson T. Stockhammer October 2007 ASCII HTML 46 fec fec encoding raptor code

This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 1, for the Raptor forward error correction code and its application to reliable delivery of data objects.

Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a source block of data. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols.

The Raptor code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK]

 draft-ietf-rmt-bb-fec-raptor-object-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5053 RFC5054 Using the Secure Remote Password (SRP) Protocol for TLS Authentication D. Taylor T. Wu N. Mavrogiannopoulos T. Perrin November 2007 ASCII HTML 24 secure remote password protocol transport layer security

This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. This memo provides information for the Internet community.

 draft-ietf-tls-srp-14 RFC8996 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5054 10.17487/RFC5054 RFC5055 Server-Based Certificate Validation Protocol (SCVP) T. Freeman R. Housley A. Malpani D. Cooper W. Polk December 2007 ASCII HTML 88 certification path construction certification path validation

The Server-Based Certificate Validation Protocol (SCVP) allows a client to delegate certification path construction and certification path validation to a server. The path construction or validation (e.g., making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies. [STANDARDS-TRACK]

 draft-ietf-pkix-scvp-33 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5055 RFC5056 On the Use of Channel Bindings to Secure Channels N. Williams November 2007 ASCII HTML 23

The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits.

This document discusses and formalizes the concept of channel binding to secure channels. [STANDARDS-TRACK]

 draft-williams-on-channel-binding-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5056 10.17487/RFC5056 RFC5057 Multiple Dialog Usages in the Session Initiation Protocol R. Sparks November 2007 ASCII HTML 26

Several methods in the Session Initiation Protocol (SIP) can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement.

This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them.

This is an informative document and makes no normative statements of any kind. This memo provides information for the Internet community.

 draft-ietf-sipping-dialogusage-06 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5057 RFC5058 Explicit Multicast (Xcast) Concepts and Options R. Boivie N. Feldman Y. Imai W. Livens D. Ooms November 2007 ASCII HTML 35 explicit multi-unicast

While traditional IP multicast schemes (RFC 1112) are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address.

This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification. This memo defines an Experimental Protocol for the Internet community.

 draft-ooms-xcast-basic-spec-13 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5058 10.17487/RFC5058 RFC5059 Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) N. Bhaskar A. Gall J. Lingard S. Venaas January 2008 ASCII PDF HTML 42 rendezvous point rp multicast router

This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure. [STANDARDS-TRACK]

 draft-ietf-pim-sm-bsr-12 RFC2362 RFC4601 RFC8736 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5059 10.17487/RFC5059 RFC5060 Protocol Independent Multicast MIB R. Sivaramu J. Lingard D. McWalter B. Joshi A. Kessler January 2008 ASCII HTML 90 PIM PIM-SM BIDIR-PIM PIM-DM Multicast Routing PIM-STD-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocols: PIM-SM (Sparse Mode), BIDIR-PIM (Bidirectional), and PIM-DM (Dense Mode). This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap. This document does not obsolete RFC 2934. [STANDARDS-TRACK]

 draft-ietf-pim-mib-v2-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5060 10.17487/RFC5060 RFC5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration R. Stewart Q. Xie M. Tuexen S. Maruyama M. Kozuka September 2007 ASCII HTML 41

A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. Stream Control Transmission Protocol (SCTP) (RFC 4960) was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures. This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP address to an SCTP association, dynamically delete an IP address from an SCTP association, and to request to set the primary address the peer will use when sending to an endpoint. [STANDARDS-TRACK]

 draft-ietf-tsvwg-addip-sctp-22 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5061 RFC5062 Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures R. Stewart M. Tuexen G. Camarillo September 2007 ASCII HTML 14

This document describes certain security threats to SCTP. It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo (RFC 4460). These techniques are included in RFC 4960, which obsoletes RFC 2960. It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Specification Errata and Issues and included in RFC 4960. This memo provides information for the Internet community.

 draft-ietf-tsvwg-sctpthreat-05 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC5062 RFC5063 Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart A. Satyanarayana Editor R. Rahman Editor October 2007 ASCII HTML 24 nodal faults rsvp hello state recovery

This document describes extensions to the Resource Reservation Protocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted.

Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.

The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node.

These extensions are not used to create or restore data plane state.

The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs). [STANDARDS-TRACK]

 draft-ietf-ccamp-rsvp-restart-ext-09 RFC2961 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5063 10.17487/RFC5063 RFC5064 The Archived-At Message Header Field M. Duerst December 2007 ASCII HTML 10

This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message. [STANDARDS-TRACK]

 draft-duerst-archived-at-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5064 RFC5065 Autonomous System Confederations for BGP P. Traina D. McPherson J. Scudder August 2007 ASCII HTML 14 border gateway protocol tcp/ip full mesh

The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.

This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.

This document obsoletes RFC 3065. [STANDARDS-TRACK]

 draft-ietf-idr-rfc3065bis-06 RFC3065 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5065 10.17487/RFC5065 RFC5066 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB E. Beili November 2007 ASCII HTML 90 Network Management Simple Network Management Protocol SNMP Management Information Base MIB Textual Conventions 2BASE-TL 10PASS-TS 802.3ah EFM PAF PME

This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP-based internets. This document describes extensions to the Ethernet-like Interfaces MIB and Medium Attachment Unit (MAU) MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004 (note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3- 2005). In addition, a set of objects is defined, describing cross- connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the Interfaces Group MIB and the Inverted Stack Table MIB modules. [STANDARDS-TRACK]

 draft-ietf-hubmib-efm-cu-mib-08 RFC7124 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC5066 RFC5067 Infrastructure ENUM Requirements S. Lind P. Pfautz November 2007 ASCII HTML 7 e.164 number mapping carrier

This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) This memo provides information for the Internet community.

 draft-ietf-enum-infrastructure-enum-reqs-04 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5067 RFC5068 Email Submission Operations: Access and Accountability Requirements C. Hutzler D. Crocker P. Resnick E. Allman T. Finch November 2007 ASCII HTML 12 spam email abuse phishing email e-mail service mime rfc2822 rfc 2822 rfc822 rfc 822 rfc2821 rfc 2821 rfc821 rfc 821 architecture mta mua msa mda user delivery relay header gateway agent sieve dsn mdn tussle mhs mail handling service message transfer agent message user agent mail submission agent mail delivery agent

Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services.

Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-hutzler-spamops-08 RFC8314 BCP0134 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5068 RFC5069 Security Threats and Requirements for Emergency Call Marking and Mapping T. Taylor Editor H. Tschofenig H. Schulzrinne M. Shanmugam January 2008 ASCII HTML 12 ecrit public safety answering points pasp

This document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to Universal Resource Identifiers (URIs) that point to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network.

Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. This memo provides information for the Internet community.

 draft-ietf-ecrit-security-threats-05 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC5069 RFC5070 The Incident Object Description Exchange Format R. Danyliw J. Meijer Y. Demchenko December 2007 ASCII HTML 92 incident data format compuer security incident computer security incident response team csirt cert security data sharing computer network defense service provider cndsp

The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. [STANDARDS-TRACK]

 draft-ietf-inch-iodef-14 RFC7970 RFC6685 PROPOSED STANDARD PROPOSED STANDARD IETF sec inch http://www.rfc-editor.org/errata_search.php?rfc=5070 10.17487/RFC5070 RFC5071 Dynamic Host Configuration Protocol Options Used by PXELINUX D. Hankins December 2007 ASCII HTML 14 dhcp dhcp option codes

This document describes the use by PXELINUX of some DHCP Option Codes numbering from 208-211. This memo provides information for the Internet community.

 draft-ietf-dhc-pxelinux-03 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC5071 RFC5072 IP Version 6 over PPP S. Varada Editor D. Haskins E. Allen September 2007 ASCII HTML 16 IPv6-PPP internet protocol point-to-point ipv6

The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP, and the method for forming IPv6 link-local addresses on PPP links.

It also specifies the conditions for performing Duplicate Address Detection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration.

This document obsoletes RFC 2472. [STANDARDS-TRACK]

 draft-ietf-ipv6-over-ppp-v2-03 RFC2472 RFC8064 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 10.17487/RFC5072 RFC5073 IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities J.P. Vasseur Editor J.L. Le Roux Editor December 2007 ASCII HTML 13 interior gateway protocol

It is highly desired, in several cases, to take into account Traffic Engineering (TE) node capabilities during Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered Label Switched Path (TE-LSP) selection, such as, for instance, the capability to act as a branch Label Switching Router (LSR) of a Point-To-MultiPoint (P2MP) LSP. This requires advertising these capabilities within the Interior Gateway Protocol (IGP). For that purpose, this document specifies Open Shortest Path First (OSPF) and Intermediate System-Intermediate System (IS-IS) traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. [STANDARDS-TRACK]

 draft-ietf-ccamp-te-node-cap-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5073 RFC5074 DNSSEC Lookaside Validation (DLV) S. Weiler November 2007 ASCII HTML 11 dns security trust anchors

DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNS Security (DNSSEC) trust anchors outside of the DNS delegation chain. It allows validating resolvers to validate DNSSEC-signed data from zones whose ancestors either aren't signed or don't publish Delegation Signer (DS) records for their children. This memo provides information for the Internet community.

 draft-weiler-dnssec-dlv-04 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5074 RFC5075 IPv6 Router Advertisement Flags Option B. Haberman Editor R. Hinden November 2007 ASCII HTML 7 neighbor discovery protocol ndp expanded flags option efo ndp router advertisement message

The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the available number of flag bits available. [STANDARDS-TRACK]

 draft-ietf-ipv6-ra-flags-option-02 RFC5175 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=5075 10.17487/RFC5075 RFC5076 ENUM Validation Information Mapping for the Extensible Provisioning Protocol B. Hoeneisen December 2007 ASCII HTML 24 epp validation process e.164 enum enum domain name

This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range) that the E.164 Number Mapping (ENUM) domain name is based on. Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM Domain Names. [STANDARDS-TRACK]

 draft-ietf-enum-validation-epp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5076 RFC5077 Transport Layer Security (TLS) Session Resumption without Server-Side State J. Salowey H. Zhou P. Eronen H. Tschofenig January 2008 ASCII HTML 20

This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]

 draft-salowey-tls-rfc4507bis-01 RFC4507 RFC8446 RFC8447 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5077 10.17487/RFC5077 RFC5078 IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline S. Dawkins October 2007 ASCII HTML 9 Internet Architecture Board Engineering Steering Group nomcom

RFC 3777 defines the Nominations and Recall Committee's (NomCom's) operation, and includes a sample timeline for major steps in the NomCom process that meets the minimum normative requirements for the process. Recent NomComs have been scheduling based on the sample timeline, and the chairs of the last three NomComs -- Danny McPherson (2004-2005), Ralph Droms (2005-2006), and Andrew Lange (2006-2007) -- have all reported that this timeline is very aggressive and suggested starting earlier. This document restructures the sample timeline, but makes no normative process changes. This memo provides information for the Internet community.

 draft-dawkins-nomcom-start-earlier-02 RFC7437 RFC3777 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5078 RFC5079 Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) J. Rosenberg December 2007 ASCII HTML 8 anonymous calls

The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose. [STANDARDS-TRACK]

 draft-ietf-sip-acr-code-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5079 RFC5080 Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes D. Nelson A. DeKok December 2007 ASCII HTML 28

This document describes common issues seen in Remote Authentication Dial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. [STANDARDS-TRACK]

 draft-ietf-radext-fixes-08 RFC2865 RFC2866 RFC2869 RFC3579 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5080 10.17487/RFC5080 RFC5081 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication N. Mavrogiannopoulos November 2007 ASCII HTML 8 tls handshake protocol handshake

This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tls-openpgp-keys-11 RFC6091 EXPERIMENTAL EXPERIMENTAL IETF sec tls 10.17487/RFC5081 RFC5082 The Generalized TTL Security Mechanism (GTSM) V. Gill J. Heasley D. Meyer P. Savola Editor C. Pignataro October 2007 ASCII HTML 16 time to live packet hop limit

The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK]

 draft-ietf-rtgwg-rfc3682bis-10 RFC3682 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC5082 RFC5083 Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type R. Housley November 2007 ASCII HTML 10 encryption mode

This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS-TRACK]

 draft-ietf-smime-cms-auth-enveloped-06 RFC3852 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC5083 RFC5084 Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS) R. Housley November 2007 ASCII HTML 11 authenticated encryption algorithm

This document specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. [STANDARDS-TRACK]

 draft-ietf-smime-cms-aes-ccm-and-gcm-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5084 10.17487/RFC5084 RFC5085 Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires T. Nadeau Editor C. Pignataro Editor December 2007 ASCII HTML 30 pw

This document describes Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. [STANDARDS-TRACK]

 draft-ietf-pwe3-vccv-15 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5085 10.17487/RFC5085 RFC5086 Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN) A. Vainshtein Editor I. Sasson E. Metz T. Frost P. Pate December 2007 ASCII HTML 38 nxds0 psn

This document describes a method for encapsulating structured (NxDS0) Time Division Multiplexed (TDM) signals as pseudowires over packet-switching networks (PSNs). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams (see RFC 4553). This memo provides information for the Internet community.

 draft-ietf-pwe3-cesopsn-07 INFORMATIONAL INFORMATIONAL IETF int pwe3 10.17487/RFC5086 RFC5087 Time Division Multiplexing over IP (TDMoIP) Y(J). Stein R. Shashoua R. Insler M. Anavi December 2007 ASCII HTML 50 TDM pseudowire PWE3 TDMoIP structure-aware TDM emulation

Time Division Multiplexing over IP (TDMoIP) is a structure-aware method for transporting Time Division Multiplexed (TDM) signals using pseudowires (PWs). Being structure-aware, TDMoIP is able to ensure TDM structure integrity, and thus withstand network degradations better than structure-agnostic transport. Structure-aware methods can distinguish individual channels, enabling packet loss concealment and bandwidth conservation. Accessibility of TDM signaling facilitates mechanisms that exploit or manipulate signaling. This memo provides information for the Internet community.

 draft-ietf-pwe3-tdmoip-06 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5087 10.17487/RFC5087 RFC5088 OSPF Protocol Extensions for Path Computation Element (PCE) Discovery JL. Le Roux Editor JP. Vasseur Editor Y. Ikejiri R. Zhang January 2008 ASCII HTML 20 pcc path computation client open shortest path first

There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within an OSPF area or within the entire OSPF routing domain. [STANDARDS-TRACK]

 draft-ietf-pce-disco-proto-ospf-08 RFC9353 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5088 10.17487/RFC5088 RFC5089 IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery JL. Le Roux Editor JP. Vasseur Editor Y. Ikejiri R. Zhang January 2008 ASCII HTML 17 path computation client pcc intermediate system to intermediate system

There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Intermediate System to Intermediate System (IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. [STANDARDS-TRACK]

 draft-ietf-pce-disco-proto-isis-08 RFC9353 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5089 10.17487/RFC5089 RFC5090 RADIUS Extension for Digest Authentication B. Sterman D. Sadolevsky D. Schwartz D. Williams W. Beck February 2008 ASCII HTML 33 remote authentication dial-in user service sip http

This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS-TRACK]

 draft-ietf-radext-rfc4590bis-02 RFC4590 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5090 10.17487/RFC5090 RFC5091 Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems X. Boyen L. Martin December 2007 ASCII HTML 63 Encryption Cryptography Security Elliptic Curves Elliptic Curve Cryptography Pairing-based Cryptography Identity-based Cryptography Identity-based Encryption Boneh-Franklin Encryption Scheme Boneh-Boyen Encryption Scheme

This document describes the algorithms that implement Boneh-Franklin (BF) and Boneh-Boyen (BB1) Identity-based Encryption. This document is in part based on IBCS #1 v2 of Voltage Security's Identity-based Cryptography Standards (IBCS) documents, from which some irrelevant sections have been removed to create the content of this document. This memo provides information for the Internet community.

 draft-martin-ibcs-07 RFC8996 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5091 10.17487/RFC5091 RFC5092 IMAP URL Scheme A. Melnikov Editor C. Newman November 2007 ASCII HTML 32 IMAP-URL remote access store Internet Message Access Protocol Uniform Resource Identifiers

IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server.

This document obsoletes RFC 2192. It also updates RFC 4467. [STANDARDS-TRACK]

 draft-ietf-lemonade-rfc2192bis-09 RFC2192 RFC4467 RFC5593 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5092 10.17487/RFC5092 RFC5093 BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ) G. Hunt December 2007 ASCII HTML 8 next-generation network rtcp xr real time control protocol extended reports transport metrics

This document describes an RTCP XR report block, which reports packet transport parameters. The report block was developed by BT for pre-standards use in BT's next-generation network. This document has been produced to describe the report block in sufficient detail to register the block type with IANA in accordance with the Specification Required policy of RFC 3611. This specification does not standardise the new report block for use outside BT's network. This memo provides information for the Internet community.

 draft-hunt-avt-rtcpxnq-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5093 RFC5094 Mobile IPv6 Vendor Specific Option V. Devarapalli A. Patel K. Leung December 2007 ASCII HTML 7 mobility header mip6 mipv6

There is a need for vendor-specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor-specific mobility option. [STANDARDS-TRACK]

 draft-ietf-mip6-vsm-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5094 RFC5095 Deprecation of Type 0 Routing Headers in IPv6 J. Abley P. Savola G. Neville-Neil December 2007 ASCII HTML 7 ipv6 type 0 routing header traffic amplification

The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light of this security concern. [STANDARDS-TRACK]

 draft-ietf-ipv6-deprecate-rh0-01 RFC2460 RFC4294 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC5095 RFC5096 Mobile IPv6 Experimental Messages V. Devarapalli December 2007 ASCII HTML 7 mip6 mobility header mobility option mipv6

This document defines a new experimental Mobility Header message and a Mobility option that can be used for experimental extensions to the Mobile IPv6 protocol. [STANDARDS-TRACK]

 draft-ietf-mip6-experimental-messages-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5096 RFC5097 MIB for the UDP-Lite protocol G. Renker G. Fairhurst January 2008 ASCII HTML 23 SMIv2 UDPLITE-MIB management information base lightweight user datagram protocol

This document specifies a Management Information Base (MIB) module for the Lightweight User Datagram Protocol (UDP-Lite). It defines a set of new MIB objects to characterise the behaviour and performance of transport layer endpoints deploying UDP-Lite. UDP-Lite resembles UDP, but differs from the semantics of UDP by the addition of a single option. This adds the capability for variable-length data checksum coverage, which can benefit a class of applications that prefer delivery of (partially) corrupted datagram payload data in preference to discarding the datagram. [STANDARDS-TRACK]

 draft-ietf-tsvwg-udplite-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5097 RFC5098 Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) G. Beacham S. Kumar S. Channabasappa February 2008 ASCII HTML 79 PKTC-IETF-SIG-MIB snmp simple network management protocol packetcable-compliant ipcablecom-compliant

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]

 draft-ietf-ipcdn-pktc-signaling-15 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn http://www.rfc-editor.org/errata_search.php?rfc=5098 10.17487/RFC5098 RFC5099 RFC5100 RFC5101 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information B. Claise Editor January 2008 ASCII HTML 63 exporting process collecting process template records

This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. [STANDARDS-TRACK]

 draft-ietf-ipfix-protocol-26 RFC7011 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5101 10.17487/RFC5101 RFC5102 Information Model for IP Flow Information Export J. Quittek S. Bryant B. Claise P. Aitken J. Meyer January 2008 ASCII HTML 171 ipfix ip flow information export protocol measured traffic observation point metering process exporting process

This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. [STANDARDS-TRACK]

 draft-ietf-ipfix-info-15 RFC7012 RFC6313 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5102 10.17487/RFC5102 RFC5103 Bidirectional Flow Export Using IP Flow Information Export (IPFIX) B. Trammell E. Boschi January 2008 ASCII HTML 24 flow record biflow

This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow Information Export (IPFIX) protocol, representing each Biflow using a single Flow Record. [STANDARDS-TRACK]

 draft-ietf-ipfix-biflow-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5103 10.17487/RFC5103 RFC5104 Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) S. Wenger U. Chandra M. Westerlund B. Burman February 2008 ASCII HTML 64 real time protocol real-time protocol itu-t rec. h271 video back channel full intra request temporary maximum media stream bit rate temporal-spatial trade-off

This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.

The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK]

 draft-ietf-avt-avpf-ccm-10 RFC7728 RFC8082 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5104 RFC5105 ENUM Validation Token Format Definition O. Lendl December 2007 ASCII HTML 17 telephone number mapping e.164

An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes a signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. [STANDARDS-TRACK]

 draft-ietf-enum-validation-token-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5105 RFC5106 The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method H. Tschofenig D. Kroeselberg A. Pashalidis Y. Ohba F. Bersani February 2008 ASCII HTML 33 cryptographic ciphersuite negotiation hash function agility identity confidentiality fragmentation fast reconnect mode

This document specifies EAP-IKEv2, an Extensible Authentication Protocol (EAP) method that is based on the Internet Key Exchange (IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates. EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional "fast reconnect" mode. This memo defines an Experimental Protocol for the Internet community.

 draft-tschofenig-eap-ikev2-15 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5106 10.17487/RFC5106 RFC5107 DHCP Server Identifier Override Suboption R. Johnson J. Kumarasamy K. Kinnear M. Stapp February 2008 ASCII HTML 7 xml extensible markup langauge dynamic host configuration protocol RENEW DHCPREQUEST DHCP RENEW

This memo defines a new suboption of the DHCP relay information option that allows the DHCP relay to specify a new value for the Server Identifier option, which is inserted by the DHCP Server. This allows the DHCP relay to act as the actual DHCP server such that RENEW DHCPREQUESTs will come to the relay instead of going to the server directly. This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on DHCP RENEW messages. [STANDARDS-TRACK]

 draft-ietf-dhc-server-override-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5107 RFC5108 RFC5109 RTP Payload Format for Generic Forward Error Correction A. Li Editor December 2007 ASCII HTML 44 fec realtime transport protocol

This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009. [STANDARDS-TRACK]

 draft-ietf-avt-ulp-23 RFC2733 RFC3009 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5109 10.17487/RFC5109 RFC5110 Overview of the Internet Multicast Routing Architecture P. Savola January 2008 ASCII HTML 25 RFC 3913 RFC 2189 RFC 2201 RFC 1584

This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications.

This memo also reclassifies several older RFCs to Historic. These RFCs describe multicast routing protocols that were never widely deployed or have fallen into disuse. This memo provides information for the Internet community.

 draft-ietf-mboned-routingarch-12 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC5110 RFC5111 Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF) B. Aboba L. Dondeti January 2008 ASCII HTML 8 working group formation bof birds of a feather

This document describes an RFC 3933 experiment in the Working Group formation process, known as the Exploratory Group. Exploratory Groups may be created as the first step toward Working Group formation, or as an intermediate step between a Birds of a Feather (BOF) session and Working Group creation. Exploratory Groups are focused on completion of prerequisites for Working Group formation, and as a result they have a short life-time, with limited opportunities for milestone extension. This memo defines an Experimental Protocol for the Internet community.

 draft-aboba-sg-experiment-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5111 RFC5112 The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp) M. Garcia-Martin January 2008 ASCII HTML 25 communication session event notification presence

The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol is extended by the SIP-events notification framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is presence, which is expressed in XML documents called presence documents. SIP can be compressed by using Signaling Compression (SigComp), which is enhanced by using the SIP/ Session Description Protocol (SDP) dictionary to achieve better compression rates. However, the SIP/SDP dictionary is not able to increase the compression factor of (typically lengthy) presence documents. This memo defines the presence-specific static dictionary that SigComp can use in order to compress presence documents to achieve higher efficiency. The dictionary is compression-algorithm independent. [STANDARDS-TRACK]

 draft-garcia-simple-presence-dictionary-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5112 RFC5113 Network Discovery and Selection Problem J. Arkko B. Aboba J. Korhonen Editor F. Bari January 2008 ASCII HTML 39

When multiple access networks are available, users may have difficulty in selecting which network to connect to and how to authenticate with that network. This document defines the network discovery and selection problem, dividing it into multiple sub- problems. Some constraints on potential solutions are outlined, and the limitations of several solutions (including existing ones) are discussed. This memo provides information for the Internet community.

 draft-ietf-eap-netsel-problem-09 INFORMATIONAL INFORMATIONAL IETF int eap 10.17487/RFC5113 RFC5114 Additional Diffie-Hellman Groups for Use with IETF Standards M. Lepinski S. Kent January 2008 ASCII HTML 23 elliptic curve ike tls ssh smime x.509

This document describes eight Diffie-Hellman groups that can be used in conjunction with IETF protocols to provide security for Internet communications. The groups allow implementers to use the same groups with a variety of security protocols, e.g., SMIME, Secure SHell (SSH), Transport Layer Security (TLS), and Internet Key Exchange (IKE).

All of these groups comply in form and structure with relevant standards from ISO, ANSI, NIST, and the IEEE. These groups are compatible with all IETF standards that make use of Diffie-Hellman or Elliptic Curve Diffie-Hellman cryptography.

These groups and the associated test data are defined by NIST on their web site [EX80056A], but have not yet (as of this writing) been published in a formal NIST document. Publication of these groups and associated test data, as well as describing how to use Diffie-Hellman and Elliptic Curve Diffie-Hellman for key agreement in all of the protocols cited below, in one RFC, will facilitate development of interoperable implementations and support the Federal Information Processing Standard (FIPS) validation of implementations that make use of these groups. This memo provides information for the Internet community.

 draft-lepinski-dh-groups-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5114 RFC5115 Telephony Routing over IP (TRIP) Attribute for Resource Priority K. Carlberg P. O'Hanlon January 2008 ASCII HTML 8 ip telephony ResourcePriority

This document defines a new attribute for the Telephony Routing over IP (TRIP) protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the Public Switched Telephone Network (PSTN) are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tuple defined for the SIP Resource-Priority field. [STANDARDS-TRACK]

 draft-carlberg-trip-attribute-rp-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5115 10.17487/RFC5115 RFC5116 An Interface and Algorithms for Authenticated Encryption D. McGrew January 2008 ASCII HTML 22 Encryption Authentication AEAD authenticated encryption with associated data

This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK]

 draft-mcgrew-auth-enc-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5116 10.17487/RFC5116 RFC5117 RTP Topologies M. Westerlund S. Wenger January 2008 ASCII HTML 21 multi-endpoint topologies real-time transport protocol

This document discusses multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This memo provides information for the Internet community.

 draft-ietf-avt-topologies-07 RFC7667 INFORMATIONAL INFORMATIONAL IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5117 10.17487/RFC5117 RFC5118 Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6) V. Gurbani C. Boulton R. Sparks February 2008 ASCII HTML 18 Torture test IPv6 SIP

This document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the code of an IPv6-enabled SIP implementation. This memo provides information for the Internet community.

 draft-ietf-sipping-ipv6-torture-tests-04 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=5118 10.17487/RFC5118 RFC5119 A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE) T. Edwards February 2008 ASCII HTML 9 persistent resources universal labels,

This document describes a Uniform Resource Name (URN) namespace for the Society of Motion Picture and Television Engineers (SMPTE) for naming persistent resources that SMPTE produces or manages. A subnamespace for Universal Labels is specifically described. This memo provides information for the Internet community.

 draft-edwards-urn-smpte-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5119 10.17487/RFC5119 RFC5120 M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) T. Przygienda N. Shen N. Sheth February 2008 ASCII HTML 14 is-is

This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK]

 draft-ietf-isis-wg-multi-topology-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5120 RFC5121 Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks B. Patil F. Xia B. Sarikaya JH. Choi S. Madanapalli February 2008 ASCII HTML 22 Neighbor Discovery Per-MS Perfix

IEEE Std 802.16 is an air interface specification for fixed and mobile Broadband Wireless Access Systems. Service-specific convergence sublayers to which upper-layer protocols interface are a part of the IEEE 802.16 MAC (Medium Access Control). The Packet convergence sublayer (CS) is used for the transport of all packet- based protocols such as Internet Protocol (IP) and IEEE 802.3 LAN/MAN CSMA/CD Access Method (Ethernet). IPv6 packets can be sent and received via the IP-specific part of the Packet CS. This document specifies the addressing and operation of IPv6 over the IP-specific part of the Packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated interface identifiers. [STANDARDS-TRACK]

 draft-ietf-16ng-ipv6-over-ipv6cs-11 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int 16ng http://www.rfc-editor.org/errata_search.php?rfc=5121 10.17487/RFC5121 RFC5122 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre February 2008 ASCII HTML 26 Extensible Messaging and Presence Protocol Internationalized Resource Identifier Uniform Resource Identifier Jabber xmpp iri uri

This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]

 draft-saintandre-rfc4622bis-01 RFC4622 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5122 RFC5123 Considerations in Validating the Path in BGP R. White B. Akyol February 2008 ASCII HTML 16 bgp autonomous system path bgp as path

This document examines the implications of hop-by-hop forwarding, route aggregation, and route filtering on the concept of validation within a BGP Autonomous System (AS) Path. This memo provides information for the Internet community.

 draft-white-pathconsiderations-09 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5123 10.17487/RFC5123 RFC5124 Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) J. Ott E. Carrara February 2008 ASCII HTML 18 avpf rtp communication

An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback. [STANDARDS-TRACK]

 draft-ietf-avt-profile-savpf-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5124 RFC5125 Reclassification of RFC 3525 to Historic T. Taylor February 2008 ASCII HTML 4 MEGACO H.248 media gateway control

This document reclassifies RFC 3525, Gateway Control Protocol Version 1, to Historic Status. This memo also obsoletes RFC 3525. This memo provides information for the Internet community.

 draft-taylor-megaco-obsol3525-01 RFC3525 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5125 RFC5126 CMS Advanced Electronic Signatures (CAdES) D. Pinkas N. Pope J. Ross March 2008 ASCII HTML 141 verifying party signer purchase contract invoice application smart cards data

This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates) the validity of the signature.

The format can be considered as an extension to RFC 3852 and RFC 2634, where, when appropriate, additional signed and unsigned attributes have been defined.

The contents of this Informational RFC amount to a transposition of the ETSI Technical Specification (TS) 101 733 V.1.7.4 (CMS Advanced Electronic Signatures -- CAdES) and is technically equivalent to it.

The technical contents of this specification are maintained by ETSI. The ETSI TS and further updates are available free of charge at: http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx This memo provides information for the Internet community.

 draft-ietf-smime-cades-07 RFC3126 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC5126 RFC5127 Aggregation of Diffserv Service Classes K. Chan J. Babiarz F. Baker February 2008 ASCII HTML 19 Treatment Aggregate forwarding treatment

In the core of a high-capacity network, service differentiation may still be needed to support applications' utilization of the network. Applications with similar traffic characteristics and performance requirements are mapped into Diffserv service classes based on end- to-end behavior requirements of the applications. However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes. In these cases, it may be desirable to aggregate two or more Diffserv service classes into a single forwarding treatment. This document provides guidelines for the aggregation of Diffserv service classes into forwarding treatments. This memo provides information for the Internet community.

 draft-ietf-tsvwg-diffserv-class-aggr-07 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC5127 RFC5128 State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs) P. Srisuresh B. Ford D. Kegel March 2008 ASCII HTML 32

This memo documents the various methods known to be in use by applications to establish direct communication in the presence of Network Address Translators (NATs) at the current time. Although this memo is intended to be mainly descriptive, the Security Considerations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described. This memo covers NAT traversal approaches used by both TCP- and UDP-based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. This memo provides information for the Internet community.

 draft-ietf-behave-p2p-state-06 INFORMATIONAL INFORMATIONAL IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5128 10.17487/RFC5128 RFC5129 Explicit Congestion Marking in MPLS B. Davie B. Briscoe J. Tay January 2008 ASCII HTML 21 Diffserv Differentiated Services QOS ECN tunnel

RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. [STANDARDS-TRACK]

 draft-ietf-tsvwg-ecn-mpls-02 RFC3032 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5129 RFC5130 A Policy Control Mechanism in IS-IS Using Administrative Tags S. Previdi M. Shand Editor C. Martin February 2008 ASCII HTML 8 intermediate systetm to intermediate system ip prefix distribution lsp link state protocol

This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link State Protocol (LSP) Data Units for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. [STANDARDS-TRACK]

 draft-ietf-isis-admin-tags-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5130 RFC5131 A MIB Textual Convention for Language Tags D. McWalter Editor December 2007 ASCII HTML 6 LANGTAG-TC-MIB

This MIB module defines a textual convention to represent BCP 47 language tags. The intent is that this textual convention will be imported and used in MIB modules that would otherwise define their own representation. [STANDARDS-TRACK]

 draft-mcwalter-langtag-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5131 RFC5132 IP Multicast MIB D. McWalter D. Thaler A. Kessler December 2007 ASCII HTML 59 managament information base IPMCAST-MIB,

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing multicast function, independent of the specific multicast protocol(s) in use. This document obsoletes RFC 2932. [STANDARDS-TRACK]

 draft-ietf-mboned-ip-mcast-mib-07 RFC2932 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC5132 RFC5133 Terminal Endpoint Identifier (TEI) Query Request Number Change M. Tuexen K. Morneault December 2007 ASCII HTML 4 isdn q.921-user adaptation layer iua

The Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer (IUA) Protocol, described in RFC 4233, defines the message type of Terminal Endpoint Identifier (TEI) Query Request messages as 5. However, this number is already being used by the Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions (DUA) to the IUA Protocol described in RFC 4129. This document updates RFC 4233 such that the message type of TEI Query Request messages is 8. [STANDARDS-TRACK]

 draft-ietf-sigtran-rfc4233update-02 RFC4233 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC5133 RFC5134 A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards M. Mealling January 2008 ASCII HTML 10 uniform resource name Auto-ID RFID EPCglobal EPC UPC supply chain management bar code

This document describes URN namespaces that will identify various objects within the EPCglobal system for identifying products within ecommerce and supply chain management applications. This memo provides information for the Internet community.

 draft-mealling-epc-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5134 10.17487/RFC5134 RFC5135 IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) D. Wing T. Eckert February 2008 ASCII HTML 16 multicast application multicast nat

This document specifies requirements for a for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) that support Any Source IP Multicast or Source-Specific IP Multicast. An IP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-behave-multicast-12 BCP0135 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5135 10.17487/RFC5135 RFC5136 Defining Network Capacity P. Chimento J. Ishac February 2008 ASCII HTML 14 bandwidth bandwidth estimation capacity estimation link capacity available capacity narrow link tight link

Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques. This memo provides information for the Internet community.

 draft-ietf-ippm-bw-capacity-05 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC5136 RFC5137 ASCII Escaping of Unicode Characters J. Klensin February 2008 ASCII HTML 13 Text internationalization ascii unicode utf-8 encoding

There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot be represented or transmitted directly. With ASCII coding, the traditional escape has been either the decimal or hexadecimal numeric value of the character, written in a variety of different ways. The move to Unicode, where characters occupy two or more octets and may be coded in several different forms, has further complicated the question of escapes. This document discusses some options now in use and discusses considerations for selecting one for use in new IETF protocols, and protocols that are now being internationalized. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-klensin-unicode-escapes-07 BCP0137 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5137 10.17487/RFC5137 RFC5138 A Uniform Resource Name (URN) Namespace for the Commission for the Management and Application of Geoscience Information (CGI) S. Cox February 2008 ASCII HTML 8

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Commission for the Management and Application of Geoscience Information (CGI) for naming (i) persistent resources published by the CGI and (ii) resources published by organizations that wish them to be used in the context of services conforming to protocols and agreements issued by CGI. The formal Namespace Identifier (NID) is "cgi". This memo provides information for the Internet community.

 draft-sjdcox-cgi-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5138 RFC5139 Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO) M. Thomson J. Winterbottom February 2008 ASCII HTML 14 location civic location pidf-lo civic address

This document defines an XML format for the representation of civic location. This format is designed for use with Presence Information Data Format Location Object (PIDF-LO) documents and replaces the civic location format in RFC 4119. The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for Dynamic Host Configuration Protocol (DHCP), and adds a hierarchy to address complex road identity schemes. The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate. [STANDARDS-TRACK]

 draft-ietf-geopriv-revised-civic-lo-07 RFC4119 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC5139 RFC5140 A Telephony Gateway REgistration Protocol (TGREP) M. Bangalore R. Kumar J. Rosenberg H. Salama D.N. Shah March 2008 ASCII HTML 28 telephony prefix soft switches telephony routing over ip trip internet telephony administrative domains itad

This document describes the Telephony Gateway Registration Protocol (TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a Telephony Routing over IP (TRIP) Location Server, which in turn can propagate that routing information within and between Internet Telephony Administrative Domains (ITADs). TGREP shares a lot of similarities with the TRIP protocol. It has similar procedures and finite state machine for session establishment. It also shares the same format for messages and a subset of attributes with TRIP. [STANDARDS-TRACK]

 draft-ietf-iptel-tgrep-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel http://www.rfc-editor.org/errata_search.php?rfc=5140 10.17487/RFC5140 RFC5141 A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO) J. Goodwin H. Apel March 2008 ASCII HTML 28 urn nid uniform resource name namespace identification NSS

This document describes a Uniform Resource Name Namespace Identification (URN NID) for the International Organization for Standardization (ISO). This URN NID is intended for use for the identification of persistent resources published by the ISO standards body (including documents, document metadata, extracted resources such as standard schemata and standard value sets, and other resources). This memo provides information for the Internet community.

 draft-goodwin-iso-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5141 10.17487/RFC5141 RFC5142 Mobility Header Home Agent Switch Message B. Haley V. Devarapalli H. Deng J. Kempf January 2008 ASCII HTML 13

This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal to a mobile node that it should acquire a new home agent. [STANDARDS-TRACK]

 draft-ietf-mip6-ha-switch-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5142 RFC5143 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation A. Malis J. Brayley J. Shirron L. Martini S. Vogelsang February 2008 ASCII HTML 24 psn packet switched network RFC4842

This document describes a historical method for encapsulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Path signals for transport across packet-switched networks (PSNs). The PSNs explicitly supported by this document include MPLS and IP. Note that RFC 4842 describes the standards-track protocol for this functionality, and new implementations must use RFC 4842 rather than this document except when interoperability with older implementations is desired. This memo defines a Historic Document for the Internet community.

 draft-malis-sonet-ces-mpls-09 RFC4842 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC5143 RFC5144 A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS) A. Newton M. Sanz February 2008 ASCII HTML 17 dreg iris domain registry

This document describes a lightweight domain availability service using the Internet Registry Information Service (IRIS) framework and the data model of the IRIS Domain Registry (DREG) service. [STANDARDS-TRACK]

 draft-ietf-crisp-iris-dchk-09 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=5144 10.17487/RFC5144 RFC5145 Framework for MPLS-TE to GMPLS Migration K. Shiomoto Editor March 2008 ASCII HTML 19 multiprotocol label switching traffic engineering control plane

The migration from Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) to Generalized MPLS (GMPLS) is the process of evolving an MPLS-TE control plane to a GMPLS control plane. An appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, and operational policy.

This document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE and GMPLS devices, or networks, may coexist that may require interworking between MPLS-TE and GMPLS protocols. Aspects of the required interworking are discussed as it will influence the choice of a migration strategy. This framework document provides a migration toolkit to aid the operator in selection of an appropriate strategy.

This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues. This memo provides information for the Internet community.

 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5145 RFC5146 Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks K. Kumaki Editor March 2008 ASCII HTML 15 multiprotocol label switching traffic engineering service provider requirements

Operation of a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network as a client network to a Generalized MPLS (GMPLS) network has enhanced operational capabilities compared to those provided by a coexistent protocol model (i.e., operation of MPLS-TE over an independently managed transport layer).

The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. An MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TE LSP.

This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks. This memo provides information for the Internet community.

 draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5146 RFC5147 URI Fragment Identifiers for the text/plain Media Type E. Wilde M. Duerst April 2008 ASCII HTML 17 uniform resource identifier mime entity

This memo defines URI fragment identifiers for text/plain MIME entities. These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, either identified by character position or range, or by line position or range. Fragment identifiers may also contain information for integrity checks to make them more robust. [STANDARDS-TRACK]

 draft-wilde-text-fragment-09 RFC2046 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5147 RFC5148 Jitter Considerations in Mobile Ad Hoc Networks (MANETs) T. Clausen C. Dearlove B. Adamson February 2008 ASCII HTML 12 randomly modifying timing control traffic transmission tranmission collision

This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hoc NETwork (MANET) routing protocols to reduce the probability of transmission collisions. This memo provides information for the Internet community.

 draft-ietf-manet-jitter-04 INFORMATIONAL INFORMATIONAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5148 10.17487/RFC5148 RFC5149 Service Selection for Mobile IPv6 J. Korhonen U. Nilsson V. Devarapalli February 2008 ASCII HTML 9 mipv6 service selection mobility option proxy mobile ipv6 mobilty service subscription binding registration procedure

In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents to make a specific service selection for the mobility service subscription during the binding registration procedure. This memo provides information for the Internet community.

 draft-korhonen-mip6-service-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5149 RFC5150 Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) A. Ayyangar K. Kompella JP. Vasseur A. Farrel February 2008 ASCII HTML 19 lsp label switched paths e2e lsp lsp stitching lsp segments s-lsp

In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs).

This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols.

It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK]

 draft-ietf-ccamp-lsp-stitching-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5150 10.17487/RFC5150 RFC5151 Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions A. Farrel Editor A. Ayyangar JP. Vasseur February 2008 ASCII HTML 25 multiprotocol label switching mpls-te

This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries.

For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks. [STANDARDS-TRACK]

 draft-ietf-ccamp-inter-domain-rsvp-te-07 RFC3209 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5151 10.17487/RFC5151 RFC5152 A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) JP. Vasseur Editor A. Ayyangar Editor R. Zhang February 2008 ASCII HTML 21 mpls gmpls

This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document, a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems.

Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. [STANDARDS-TRACK]

 draft-ietf-ccamp-inter-domain-pd-path-comp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5152 RFC5153 IP Flow Information Export (IPFIX) Implementation Guidelines E. Boschi L. Mark J. Quittek M. Stiemerling P. Aitken April 2008 ASCII HTML 35 template mangaement exporting processes collecting processes ipfix middleboxes

The IP Flow Information Export (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address Template management, transport-specific issues, implementation of Exporting and Collecting Processes, and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.). This memo provides information for the Internet community.

 draft-ietf-ipfix-implementation-guidelines-08 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5153 10.17487/RFC5153 RFC5154 IP over IEEE 802.16 Problem Statement and Goals J. Jee Editor S. Madanapalli J. Mandin April 2008 ASCII HTML 14 WiMAX Mobile WiMAX WiBro

This document specifies problems in running IP over IEEE 802.16 networks by identifying specific gaps in the IEEE 802.16 Media Access Control (MAC) for IPv4 and IPv6 support. This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers. Common terminology used for the base guideline while defining the solution framework is also presented. This memo provides information for the Internet community.

 draft-ietf-16ng-ps-goals-04 INFORMATIONAL INFORMATIONAL IETF int 16ng 10.17487/RFC5154 RFC5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence B. Laurie G. Sisson R. Arends D. Blacka March 2008 ASCII HTML 52 domain name system nsec resource record nsec3

The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK]

 draft-ietf-dnsext-nsec3-13 RFC6840 RFC6944 RFC9077 RFC9157 RFC9276 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=5155 10.17487/RFC5155 RFC5156 Special-Use IPv6 Addresses M. Blanchet April 2008 ASCII HTML 7 invalid routing prefix

This document is a compilation of special IPv6 addresses defined in other RFCs. It can be used as a checklist of invalid routing prefixes for developing filtering policies for routes and IP packets. It does not discuss addresses that are assigned to operators and users through the Regional Internet Registries. This memo provides information for the Internet community.

 draft-ietf-v6ops-rfc3330-for-ipv6-04 RFC6890 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5156 RFC5157 IPv6 Implications for Network Scanning T. Chown March 2008 ASCII HTML 13 subnet address space

The much larger default 64-bit subnet address space of IPv6 should in principle make traditional network (port) scanning techniques used by certain network worms or scanning tools less effective. While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware that attackers may use other techniques to discover IPv6 addresses on a target network, and thus they should also be aware of measures that are available to mitigate them. This informational document discusses approaches that administrators could take when planning their site address allocation and management strategies as part of a defence-in-depth approach to network security. This memo provides information for the Internet community.

 draft-ietf-v6ops-scanning-implications-04 RFC7707 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5157 RFC5158 6to4 Reverse DNS Delegation Specification G. Huston March 2008 ASCII HTML 12 dns domain name system

This memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file. The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain. In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested 6to4 delegation address block. This memo provides information for the Internet community.

 draft-huston-6to4-reverse-dns-07 RFC8996 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5158 10.17487/RFC5158 RFC5159 Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection L. Dondeti Editor A. Jerichow March 2008 ASCII HTML 8 SDP IANA registration OMA BCAST

This document provides descriptions of Session Description Protocol (SDP) attributes used by the Open Mobile Alliance's Broadcast Service and Content Protection specification. This memo provides information for the Internet community.

 draft-dondeti-oma-mmusic-sdp-attrs-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5159 RFC5160 Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS) P. Levis M. Boucadair March 2008 ASCII HTML 19 sls bgp peering diffserv parallel internet

This memo analyzes provider-to-provider Quality of Service (QoS) agreements suitable for a global QoS-enabled Internet. It defines terminology relevant to inter-domain QoS models. It proposes a new concept denoted by Meta-QoS-Class (MQC). This concept could potentially drive and federate the way QoS inter-domain relationships are built between providers. It opens up new perspectives for a QoS- enabled Internet that retains, as much as possible, the openness of the existing best-effort Internet. This memo provides information for the Internet community.

 draft-levis-provider-qos-agreement-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5160 RFC5161 The IMAP ENABLE Extension A. Gulbrandsen Editor A. Melnikov Editor March 2008 ASCII HTML 7 Internet Message Access Protocol

Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports. [STANDARDS-TRACK]

 draft-gulbrandsen-imap-enable-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5161 RFC5162 IMAP4 Extensions for Quick Mailbox Resynchronization A. Melnikov D. Cridland C. Wilson March 2008 ASCII HTML 23 Internet Message Access Protocol

This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). [STANDARDS-TRACK]

 draft-ietf-lemonade-reconnect-client-06 RFC7162 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5162 10.17487/RFC5162 RFC5163 Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) G. Fairhurst B. Collini-Nocker April 2008 ASCII HTML 18 digital video broadcasting dvb mpeg-2 ts-concat pdu-concat timestamp

This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC 4326.

The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic Stream Encapsulation (GSE) for the second-generation framing structure defined by the Digital Video Broadcasting (DVB) family of specifications. [STANDARDS-TRACK]

 draft-ietf-ipdvb-ule-ext-07 PROPOSED STANDARD PROPOSED STANDARD IETF int ipdvb 10.17487/RFC5163 RFC5164 Mobility Services Transport: Problem Statement T. Melia Editor March 2008 ASCII HTML 16 intelligent access selection ip handover mechanism

There are ongoing activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE 802.21. Intelligent access selection, taking into account link-layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network and vice-versa. The protocol requirements for this signalling have both transport and security issues that must be considered. The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem, which is within the scope of the IETF. This document presents a problem statement for this core problem. This memo provides information for the Internet community.

 draft-ietf-mipshop-mis-ps-05 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC5164 RFC5165 A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC) C. Reed April 2008 ASCII HTML 7 location geospatial namespace OGC URN Open Geospatial Consortium

This document describes a Uniform Resource Name (URN) namespace that is engineered by the Open Geospatial Consortium (OGC) for naming persistent resources published by the OGC. The formal Namespace IDentifier (NID) is "ogc". This memo provides information for the Internet community.

 draft-creed-ogc-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5165 RFC5166 Metrics for the Evaluation of Congestion Control Mechanisms S. Floyd Editor March 2008 ASCII HTML 23 transport protocol transport modeling research group tmrg

This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols.

This document is a product of the Transport Modeling Research Group (TMRG), and has received detailed feedback from many members of the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade-offs between a range of metrics, rather than in terms of optimizing for a single metric. This memo provides information for the Internet community.

 draft-irtf-tmrg-metrics-11 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5166 RFC5167 Media Server Control Protocol Requirements M. Dolly R. Even March 2008 ASCII HTML 9 logical entities mcp interactive voice response conferencing media services

This document addresses the communication between an application server and media server. The current work in IETF working groups shows these logical entities, but it does not address the physical decomposition and the protocol between the entities.

This document presents the requirements for a Media Server Control Protocol (MCP) that enables an application server to use a media server. It will address the aspects of announcements, Interactive Voice Response, and conferencing media services. This memo provides information for the Internet community.

 draft-ietf-mediactrl-requirements-04 INFORMATIONAL INFORMATIONAL IETF rai mediactrl 10.17487/RFC5167 RFC5168 XML Schema for Media Control O. Levin R. Even P. Hagendorf March 2008 ASCII HTML 10 extensible markup language video fast update

This document defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors. This document describes a method that has been deployed in Session Initiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. New implementations are discouraged from using the method described except for backward compatibility purposes. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel. This memo provides information for the Internet community.

 draft-levin-mmusic-xml-media-control-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5168 RFC5169 Handover Key Management and Re-Authentication Problem Statement T. Clancy M. Nakhjiri V. Narayanan L. Dondeti March 2008 ASCII HTML 15 hokey handover key management fast re-authentication mobility

This document describes the Handover Keying (HOKEY) re-authentication problem statement. The current Extensible Authentication Protocol (EAP) keying framework is not designed to support re-authentication and handovers without re-executing an EAP method. This often causes unacceptable latency in various mobile wireless environments. This document details the problem and defines design goals for a generic mechanism to reuse derived EAP keying material for handover. This memo provides information for the Internet community.

 draft-ietf-hokey-reauth-ps-09 INFORMATIONAL INFORMATIONAL IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5169 10.17487/RFC5169 RFC5170 Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes V. Roca C. Neumann D. Furodet June 2008 ASCII HTML 33 LDPC FEC

This document describes two Fully-Specified Forward Error Correction (FEC) Schemes, Low Density Parity Check (LDPC) Staircase and LDPC Triangle, and their application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). These systematic FEC codes belong to the well- known class of "Low Density Parity Check" codes, and are large block FEC codes in the sense of RFC 3453. [STANDARDS-TRACK]

 draft-ietf-rmt-bb-fec-ldpc-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5170 RFC5171 Cisco Systems UniDirectional Link Detection (UDLD) Protocol M. Foschiano April 2008 ASCII HTML 13 Ethernet switches LAN IEEE 802 spanning tree STP FEFI autonegotiation

This document describes a Cisco Systems protocol that can be used to detect and disable unidirectional Ethernet fiber or copper links caused, for instance, by mis-wiring of fiber strands, interface malfunctions, media converters' faults, etc. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms.

This document explains the protocol objectives and applications, illustrates the specific premises the protocol was based upon, and describes the protocol architecture and related deployment issues to serve as a possible base for future standardization. This memo provides information for the Internet community.

 draft-foschiano-udld-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5171 RFC5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol S. Varada Editor March 2008 ASCII HTML 7 IPv6-PPP internet protocol point-to-point ipv6

The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

The IPv6 Control Protocol (IPV6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for an IPv6 interface over PPP.

This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP. [STANDARDS-TRACK]

 draft-ietf-ipv6-compression-nego-v2-02 RFC2472 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC5172 RFC5173 Sieve Email Filtering: Body Extension J. Degener P. Guenther April 2008 ASCII HTML 10 search full text email

This document defines a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message. [STANDARDS-TRACK]

 draft-ietf-sieve-body-09 RFC5229 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5173 RFC5174 A Uniform Resource Name (URN) Namespace for the European Broadcasting Union (EBU) J-P. Evain May 2008 ASCII HTML 8 EBU namespace urn broadcast metadata classification schema

This document describes a Uniform Resource Name (URN) namespace for the European Broadcasting Union (EBU) for naming persistent resources defined within EBU technical documentation and Internet resources. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the EBU. This memo provides information for the Internet community.

 draft-evain-ebu-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5174 RFC5175 IPv6 Router Advertisement Flags Option B. Haberman Editor R. Hinden March 2008 ASCII HTML 7 neighbor discovery protocol ndp expanded flags option efo ndp router advertisement message

The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the number of flag bits available. [STANDARDS-TRACK]

 RFC5075 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC5175 RFC5176 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) M. Chiba G. Dommety M. Eklund D. Mitton B. Aboba January 2008 ASCII HTML 34 user session

This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community.

 draft-ietf-radext-rfc3576bis-13 RFC3576 RFC8559 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5176 10.17487/RFC5176 RFC5177 Network Mobility (NEMO) Extensions for Mobile IPv4 K. Leung G. Dommety V. Narayanan A. Petrescu April 2008 ASCII HTML 26 NEMOv4 Mobile Networks Moving Networks Mobile Router Local Fixed Node Prefix Table Mobile Network Prefix Nested Mobile Networks Nested Network Mobility

This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function.

Extensions to Mobile IPv4 are introduced to support Mobile Networks. [STANDARDS-TRACK]

 draft-ietf-mip4-nemo-v4-base-11 RFC6626 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC5177 RFC5178 Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type N. Williams A. Melnikov May 2008 ASCII HTML 9 domain-based-name gss-domain-based-services GSS_C_NT_DOMAINBASED_SERVICE

This document describes domain-name-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Internationalization of the GSS-API is also covered.

Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the "domain" which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names. [STANDARDS-TRACK]

 draft-ietf-kitten-gssapi-domain-based-names-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5178 RFC5179 Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism N. Williams May 2008 ASCII HTML 5 domain-name-based GSS_C_NT_DOMAINBASED_SERVICE

This document describes the mapping of Generic Security Service Application Program Interface (GSS-API) domain-name-based service principal names onto Kerberos V principal names. [STANDARDS-TRACK]

 draft-ietf-kitten-krb5-gssapi-domain-based-names-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5179 RFC5180 IPv6 Benchmarking Methodology for Network Interconnect Devices C. Popoviciu A. Hamza G. Van de Velde D. Dugatkin May 2008 ASCII HTML 20 rfc2544 ipv6 benchmarking guidelines

The benchmarking methodologies defined in RFC 2544 are IP version independent. However, RFC 2544 does not address some of the specificities of IPv6. This document provides additional benchmarking guidelines, which in conjunction with RFC 2544, lead to a more complete and realistic evaluation of the IPv6 performance of network interconnect devices. IPv6 transition mechanisms are outside the scope of this document. This memo provides information for the Internet community.

 draft-ietf-bmwg-ipv6-meth-05 INFORMATIONAL INFORMATIONAL IETF ops bmwg http://www.rfc-editor.org/errata_search.php?rfc=5180 10.17487/RFC5180 RFC5181 IPv6 Deployment Scenarios in 802.16 Networks M-K. Shin Editor Y-H. Han S-E. Kim D. Premec May 2008 ASCII HTML 16 Ethernet CS (Convergence Sublayer) IPv6 CS (Convergence Sublayer)

This document provides a detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document, we will discuss the main components of IPv6 IEEE 802.16 access networks and their differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies. This memo provides information for the Internet community.

 draft-ietf-v6ops-802-16-deployment-scenarios-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5181 RFC5182 IMAP Extension for Referencing the Last SEARCH Result A. Melnikov March 2008 ASCII HTML 13 uid unique identifier searchres internet message access protocol

Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox.

This can be achieved using standard IMAP operations described in RFC 3501; however, this would be suboptimal. The server will send the list of found messages to the client; after that, the client will have to parse the list, reformat it, and send it back to the server. The client can't pipeline the SEARCH command with the subsequent command, and, as a result, the server might not be able to perform some optimizations.

This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or Unique Identifier (UID) SEARCH) command as an input to any subsequent command. [STANDARDS-TRACK]

 draft-melnikov-imap-search-res-07 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5182 RFC5183 Sieve Email Filtering: Environment Extension N. Freed May 2008 ASCII HTML 10 vnd

This document describes the "environment" extension to the Sieve email filtering language. The "environment" extension gives a Sieve script access to information about the Sieve interpreter itself, where it is running, and about any transport connection currently involved in transferring the message. [STANDARDS-TRACK]

 draft-freed-sieve-environment-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5183 RFC5184 Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover F. Teraoka K. Gogo K. Mitsuya R. Shibui K. Mitani May 2008 ASCII HTML 29 l2 triggers primitives l3-driven fast handover ip mobility optimizations mobopts

This document proposes unified Layer 2 (L2) abstractions for Layer 3 (L3)-driven fast handovers. For efficient network communication, it is vital for a protocol layer to know or utilize other layers' information, such as the form of L2 triggers. However, each protocol layer is basically designed independently. Since each protocol layer is also implemented independently in current operating systems, it is very hard to exchange control information between protocol layers. This document defines nine kinds of L2 abstractions in the form of "primitives" to achieve fast handovers in the network layer as a means of solving the problem. This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the primitives. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-mobopts-l2-abstractions-07 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC5184 RFC5185 OSPF Multi-Area Adjacency S. Mirtorabi P. Psenak A. Lindem Editor A. Oswal May 2008 ASCII HTML 11 open shortest path first inter-area intra-area path

This document describes an extension to the Open Shortest Path First (OSPF) protocol to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra- area path in each of the corresponding areas sharing the same link. [STANDARDS-TRACK]

 draft-ietf-ospf-multi-area-adj-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5185 10.17487/RFC5185 RFC5186 Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction B. Haberman J. Martin May 2008 ASCII HTML 6 source information source-filtering group management

The definitions of the Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) require new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 and MLDv2 messages necessitates that multicast routing protocols manage and utilize the information. This document describes how multicast routing protocols will interact with these source-filtering group management protocols. This memo provides information for the Internet community.

 draft-ietf-magma-igmpv3-and-routing-05 INFORMATIONAL INFORMATIONAL IETF int magma 10.17487/RFC5186 RFC5187 OSPFv3 Graceful Restart P. Pillay-Esnault A. Lindem June 2008 ASCII HTML 7 open shortest path first

This document describes the OSPFv3 graceful restart. The OSPFv3 graceful restart is identical to that of OSPFv2 except for the differences described in this document. These differences include the format of the grace Link State Advertisements (LSAs) and other considerations. [STANDARDS-TRACK]

 draft-ietf-ospf-ospfv3-graceful-restart-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5187 10.17487/RFC5187 RFC5188 RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec H. Desineni Q. Xie February 2008 ASCII HTML 25

This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and updates the media type registrations for EVRC-B codec. Several media type registrations are included for EVRC-WB RTP payload formats. In addition, a file format is specified for transport of EVRC-WB speech data in storage mode applications such as email. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-evrc-wb-09 RFC4788 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5188 RFC5189 Middlebox Communication (MIDCOM) Protocol Semantics M. Stiemerling J. Quittek T. Taylor March 2008 ASCII HTML 70 nat network address translator firewall

This document specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This document obsoletes RFC 3989. [STANDARDS-TRACK]

 draft-ietf-midcom-rfc3989-bis-02 RFC3989 PROPOSED STANDARD PROPOSED STANDARD IETF tsv midcom 10.17487/RFC5189 RFC5190 Definitions of Managed Objects for Middlebox Communication J. Quittek M. Stiemerling P. Srisuresh March 2008 ASCII HTML 92 management information base mib midcom MIDCOM-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices. The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC 5189. [STANDARDS-TRACK]

 draft-ietf-midcom-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv midcom 10.17487/RFC5190 RFC5191 Protocol for Carrying Authentication for Network Access (PANA) D. Forsberg Y. Ohba Editor B. Patil H. Tschofenig A. Yegin May 2008 ASCII HTML 46 eap exensible authentication protocol

This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is a UDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator. [STANDARDS-TRACK]

 draft-ietf-pana-pana-18 RFC5872 PROPOSED STANDARD PROPOSED STANDARD IETF int pana http://www.rfc-editor.org/errata_search.php?rfc=5191 10.17487/RFC5191 RFC5192 DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents L. Morand A. Yegin S. Kumar S. Madanapalli May 2008 ASCII HTML 8 dynamic host configuration protocol pac pana client

This document defines new DHCPv4 and DHCPv6 options that contain a list of IP addresses to locate one or more PANA (Protocol for carrying Authentication for Network Access) Authentication Agents (PAAs). This is one of the methods that a PANA Client (PaC) can use to locate PAAs. [STANDARDS-TRACK]

 draft-ietf-dhc-paa-option-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5192 RFC5193 Protocol for Carrying Authentication for Network Access (PANA) Framework P. Jayaraman R. Lopez Y. Ohba Editor M. Parthasarathy A. Yegin May 2008 ASCII HTML 11

This document defines the general Protocol for Carrying Authentication for Network Access (PANA) framework functional elements, high-level call flow, and deployment environments. This memo provides information for the Internet community.

 draft-ietf-pana-framework-10 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC5193 RFC5194 Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP) A. van Wijk Editor G. Gybels Editor June 2008 ASCII HTML 31 text telephone textphone deaf hard-of-hearing speech-impaired interactive text transcoding speech-to-text user alerting emergency services gateway analog terminal adapters PSTN interworking text presentation user alerting instant messaging conversation conversational text interactivity total conversation user requirements text gateway relay relay service text relay TTY text transport text interworking combination gateway

This document lists the essential requirements for real-time Text-over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the Public Switched Telephone Network (PSTN) and other networks. This memo provides information for the Internet community.

 draft-ietf-sipping-toip-09 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5194 RFC5195 BGP-Based Auto-Discovery for Layer-1 VPNs H. Ould-Brahim D. Fedyk Y. Rekhter June 2008 ASCII HTML 10 import route target l1vpn single-end provisioning

The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs). The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of Provider Edges (PEs) having ports attached to Customer Edge (CE) members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections. One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. [STANDARDS-TRACK]

 draft-ietf-l1vpn-bgp-auto-discovery-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l1vpn 10.17487/RFC5195 RFC5196 Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) M. Lonnfors K. Kiss September 2008 ASCII HTML 30 common presence data format cpp common profile for presence

Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant presence protocols. This memo defines a PIDF extension to represent SIP User Agent capabilities. [STANDARDS-TRACK]

 draft-ietf-simple-prescaps-ext-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5196 RFC5197 On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions S. Fries D. Ignjatic June 2008 ASCII HTML 31 key management media stream security end-to-end SRTP

Multimedia Internet Keying (MIKEY) is a key management protocol that can be used for \%real-time applications. In particular, it has been defined focusing on the support of the Secure \%Real-time Transport Protocol (SRTP). MIKEY itself is standardized within RFC 3830 and defines four key distribution methods. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arise, especially in terms of additional key distribution methods but also in terms of payload enhancements.

This document provides an overview about the MIKEY base document in general as well as the existing extensions for MIKEY, which have been defined or are in the process of definition. It is intended as an additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are strongly related to dedicated SIP call scenarios providing challenges for key management in general, among them media before Session Description Protocol (SDP) answer, forking, and shared key conferencing. This memo provides information for the Internet community.

 draft-ietf-msec-mikey-applicability-09 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC5197 RFC5198 Unicode Format for Network Interchange J. Klensin M. Padlipsky March 2008 ASCII HTML 19 internationalized utf-8

The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK]

 draft-klensin-net-utf8-09 RFC0698 RFC0854 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5198 10.17487/RFC5198 RFC5199 RFC5200 RFC5201 Host Identity Protocol R. Moskowitz P. Nikander P. Jokela Editor T. Henderson April 2008 ASCII HTML 104 hip ip-layer state integrity protection optional encryption

This memo specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie- Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-base-10 RFC7401 RFC6253 EXPERIMENTAL EXPERIMENTAL IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=5201 10.17487/RFC5201 RFC5202 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) P. Jokela R. Moskowitz P. Nikander April 2008 ASCII HTML 30 user data packets

This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-esp-06 RFC7402 EXPERIMENTAL EXPERIMENTAL IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=5202 10.17487/RFC5202 RFC5203 Host Identity Protocol (HIP) Registration Extension J. Laganier T. Koponen L. Eggert April 2008 ASCII HTML 13 register

This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-registration-02 RFC8003 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5203 RFC5204 Host Identity Protocol (HIP) Rendezvous Extension J. Laganier L. Eggert April 2008 ASCII HTML 15 hip registration extension hip nodes hip redezvous server

This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-rvs-05 RFC8004 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5204 RFC5205 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions P. Nikander J. Laganier April 2008 ASCII HTML 17 hip host identity protocol host identity payload dns domain name system

This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-dns-09 RFC8005 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5205 RFC5206 End-Host Mobility and Multihoming with the Host Identity Protocol P. Nikander T. Henderson Editor C. Vogt J. Arkko April 2008 ASCII HTML 40 hip multihoming extensions mobility extentions locator

This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-mm-05 RFC8046 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5206 RFC5207 NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication M. Stiemerling J. Quittek L. Eggert April 2008 ASCII HTML 13 HIP host identity protocol host identity payload NAT traversal middlebox traversal firewall traversal ID locator split problem statement

The Host Identity Protocol (HIP) changes the way in which two Internet hosts communicate. One key advantage over other schemes is that HIP does not require modifications to the traditional network- layer functionality of the Internet, i.e., its routers. In the current Internet, however, many devices other than routers modify the traditional network-layer behavior of the Internet. These "middleboxes" are intermediary devices that perform functions other than the standard functions of an IP router on the datagram path between source and destination hosts. Whereas some types of middleboxes may not interfere with HIP at all, others can affect some aspects of HIP communication, and others can render HIP communication impossible. This document discusses the problems associated with HIP communication across network paths that include specific types of middleboxes, namely, network address translators and firewalls. It identifies and discusses issues in the current HIP specifications that affect communication across these types of middleboxes. This document is a product of the IRTF HIP Research Group. This memo provides information for the Internet community.

 draft-irtf-hiprg-nat-04 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5207 RFC5208 Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2 B. Kaliski May 2008 ASCII HTML 8 rsa laboratories private-key syntax change control

This document represents a republication of PKCS #8 v1.2 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS #8 v1.2 specification.

This document describes a syntax for private-key information. This memo provides information for the Internet community.

 draft-kaliski-pkcs8-00 RFC5958 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5208 10.17487/RFC5208 RFC5209 Network Endpoint Assessment (NEA): Overview and Requirements P. Sangster H. Khosravi M. Mani K. Narayan J. Tardo June 2008 ASCII HTML 53 Posture Remediation reassessment Validator Collector Broker compliance privacy disclosure replay trust policy

This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance-oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced. This memo provides information for the Internet community.

 draft-ietf-nea-requirements-07 INFORMATIONAL INFORMATIONAL IETF sec nea 10.17487/RFC5209 RFC5210 A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience J. Wu J. Bi X. Li G. Ren K. Xu M. Williams June 2008 ASCII HTML 25 Source Address Validation Source Addressing Spoofing Network Security Testbed IPv6

Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet with IP source address validation, a prototype implementation of the IP Source Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation. This memo defines an Experimental Protocol for the Internet community.

 draft-wu-sava-testbed-experience-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5210 RFC5211 An Internet Transition Plan J. Curran July 2008 ASCII HTML 8

This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantly IPv6-based connectivity model. This memo provides information for the Internet community.

 draft-jcurran-v6transitionplan-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5211 RFC5212 Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) K. Shiomoto D. Papadimitriou JL. Le Roux M. Vigoureux D. Brungard July 2008 ASCII HTML 28 generalized mpls switching technology

Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies.

In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-mln-reqs-11 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5212 RFC5213 Proxy Mobile IPv6 S. Gundavelli Editor K. Leung V. Devarapalli K. Chowdhury B. Patil August 2008 ASCII HTML 92 mobility management

Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility-related signaling. The network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6. [STANDARDS-TRACK]

 draft-ietf-netlmm-proxymip6-18 RFC6543 RFC7864 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm http://www.rfc-editor.org/errata_search.php?rfc=5213 10.17487/RFC5213 RFC5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) F. Templin T. Gleeson D. Thaler March 2008 ASCII HTML 15 ipv6 ipv4 non-broadcast multiple access nbma dual-stack

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects dual-stack (IPv6/IPv4) nodes over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. This memo provides information for the Internet community.

 draft-templin-rfc4214bis-05 RFC4214 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5214 RFC5215 RTP Payload Format for Vorbis Encoded Audio L. Barbato August 2008 ASCII HTML 26 realtime transport protocol codebook

This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and the delivery mechanisms for the decoder probability model (referred to as a codebook), as well as other setup information.

Also included within this memo are media type registrations and the details necessary for the use of Vorbis with the Session Description Protocol (SDP). [STANDARDS-TRACK]

 draft-ietf-avt-rtp-vorbis-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5215 10.17487/RFC5215 RFC5216 The EAP-TLS Authentication Protocol D. Simon B. Aboba R. Hurst March 2008 ASCII HTML 34 extensible authentication protocol point-to-point link control compression extensible transport level security

The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.

This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]

 draft-simon-emu-rfc2716bis-13 RFC2716 RFC8996 RFC9190 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu http://www.rfc-editor.org/errata_search.php?rfc=5216 10.17487/RFC5216 RFC5217 Memorandum for Multi-Domain Public Key Infrastructure Interoperability M. Shimaoka Editor N. Hastings R. Nielsen July 2008 ASCII HTML 29 pki multi-domain pki pki domain

The objective of this document is to establish a terminology framework and to suggest the operational requirements of Public Key Infrastructure (PKI) domain for interoperability of multi-domain Public Key Infrastructure, where each PKI domain is operated under a distinct policy. This document describes the relationships between Certification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi-domain PKI. This memo provides information for the Internet community.

 draft-shimaoka-multidomain-pki-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5217 RFC5218 What Makes for a Successful Protocol? D. Thaler B. Aboba July 2008 ASCII HTML 28

The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. This memo provides information for the Internet community.

 draft-iab-protocol-success-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5218 RFC5219 A More Loss-Tolerant RTP Payload Format for MP3 Audio R. Finlayson February 2008 ASCII HTML 22 real time protocol real-time protocol mpeg moving picture experts group,

This document describes an RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. This document obsoletes RFC 3119, correcting typographical errors in the "SDP usage" section and pseudo-code appendices. [STANDARDS-TRACK]

 draft-ietf-avt-rfc3119bis-05 RFC3119 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5219 RFC5220 Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules A. Matsumoto T. Fujisaki R. Hiromi K. Kanayama July 2008 ASCII HTML 17 multiple prefixes

A single physical link can have multiple prefixes assigned to it. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OSs. But, it has been too difficult to use operationally for several reasons. In some environments where multiple prefixes are assigned on a single physical link, the host using the default address selection rules will experience some trouble in communication. This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes. This memo provides information for the Internet community.

 draft-ietf-v6ops-addr-select-ps-09 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=5220 10.17487/RFC5220 RFC5221 Requirements for Address Selection Mechanisms A. Matsumoto T. Fujisaki R. Hiromi K. Kanayama July 2008 ASCII HTML 7 default address selection

There are some problematic cases when using the default address selection mechanism that RFC 3484 defines. This document describes additional requirements that operate with RFC 3484 to solve the problems. This memo provides information for the Internet community.

 draft-ietf-v6ops-addr-select-req-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5221 RFC5222 LoST: A Location-to-Service Translation Protocol T. Hardie A. Newton H. Schulzrinne H. Tschofenig August 2008 ASCII HTML 69 emergency services emergency call routing

This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. [STANDARDS-TRACK]

 draft-ietf-ecrit-lost-10 RFC6848 RFC8917 RFC9036 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5222 10.17487/RFC5222 RFC5223 Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) H. Schulzrinne J. Polk H. Tschofenig August 2008 ASCII HTML 8 mapping service emergency service emergency communication

The Location-to-Service Translation (LoST) Protocol describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere, but a placement closer to the end host, e.g., in the access network, is desirable. In disaster situations with intermittent network connectivity, such a LoST server placement provides benefits regarding the resiliency of emergency service communication.

This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). [STANDARDS-TRACK]

 draft-ietf-ecrit-dhc-lost-discovery-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC5223 RFC5224 Diameter Policy Processing Application M. Brenner March 2008 ASCII HTML 5 policy evaluation or evaluation and enforcement pem-1 peem oma open mobile alliance

This document describes the need for a new IANA Diameter Command Code to be used in a vendor-specific new application for invocation of Policy Processing (Policy Evaluation, or Evaluation and Enforcement). This application is needed as one of the implementations of the Open Mobile Alliance (OMA) Policy Evaluation, Enforcement and Management (PEEM) enabler, namely for the PEM-1 interface used to send a request/response for Policy Processing. This memo provides information for the Internet community.

 draft-brenner-dime-peem-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5224 RFC5225 RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite G. Pelletier K. Sandlund April 2008 ASCII HTML 124 rohc 3095 3843 4019

This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP (Encapsulating Security Payload) headers.

This specification defines a second version of the profiles found in RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but does not obsolete them.

The ROHCv2 profiles introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the ROHCv2 profiles define their own specific set of header formats, using the ROHC formal notation. [STANDARDS-TRACK]

 draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5225 10.17487/RFC5225 RFC5226 Guidelines for Writing an IANA Considerations Section in RFCs T. Narten H. Alvestrand May 2008 ASCII HTML 27 internet assigned numbers authority values implementations code point protocol constant protocol parameter

Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).

In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.

This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-narten-iana-considerations-rfc2434bis-09 RFC2434 RFC8126 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5226 10.17487/RFC5226 RFC5227 IPv4 Address Conflict Detection S. Cheshire July 2008 ASCII HTML 21 internet protocol version 4

When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination), problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect, after the fact, that it has happened, so that the host or administrator may respond to rectify the problem. [STANDARDS-TRACK]

 draft-cheshire-ipv4-acd-06 RFC0826 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5227 RFC5228 Sieve: An Email Filtering Language P. Guenther Editor T. Showalter Editor January 2008 ASCII HTML 42

This document describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs. [STANDARDS-TRACK]

 draft-ietf-sieve-3028bis-13 RFC3028 RFC5229 RFC5429 RFC6785 RFC9042 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5228 10.17487/RFC5228 RFC5229 Sieve Email Filtering: Variables Extension K. Homme January 2008 ASCII HTML 11

In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules. This document updates the Sieve filtering language (RFC 5228) with an extension to support variables. The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined. [STANDARDS-TRACK]

 draft-ietf-sieve-variables-08 RFC5228 RFC5173 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5229 10.17487/RFC5229 RFC5230 Sieve Email Filtering: Vacation Extension T. Showalter N. Freed Editor January 2008 ASCII HTML 16 autoresponder

This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops. [STANDARDS-TRACK]

 draft-ietf-sieve-vacation-06 RFC8580 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5230 10.17487/RFC5230 RFC5231 Sieve Email Filtering: Relational Extension W. Segmuller B. Leiba January 2008 ASCII HTML 9 relational operators

This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields.

This document obsoletes RFC 3431. [STANDARDS-TRACK]

 draft-ietf-sieve-3431bis-04 RFC3431 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5231 RFC5232 Sieve Email Filtering: Imap4flags Extension A. Melnikov January 2008 ASCII HTML 12 imap internet message access control protocol imap flags imap system flags imap keywords

Recent discussions have shown that it is desirable to set different IMAP (RFC 3501) flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent.

This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows setting of both IMAP system flags and IMAP keywords. [STANDARDS-TRACK]

 draft-ietf-sieve-imapflags-05 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5232 10.17487/RFC5232 RFC5233 Sieve Email Filtering: Subaddress Extension K. Murchison January 2008 ASCII HTML 7 subaddressing detailed addressing :user :detail

On email systems that allow for 'subaddressing' or 'detailed addressing' (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve Email Filtering Language that allows users to compare against the user and detail sub-parts of an address. [STANDARDS-TRACK]

 draft-ietf-sieve-rfc3598bis-05 RFC3598 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5233 10.17487/RFC5233 RFC5234 Augmented BNF for Syntax Specifications: ABNF D. Crocker Editor P. Overell January 2008 ASCII HTML 16 ABNF backus-naur form augmented backus-naur form rule definitions encoding core lexical analyzer

Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]

 draft-crocker-rfc4234bis-01 RFC4234 RFC7405 STD0068 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5234 10.17487/RFC5234 RFC5235 Sieve Email Filtering: Spamtest and Virustest Extensions C. Daboo January 2008 ASCII HTML 13 spamtest spamtestplus virustest scores

The Sieve email filtering language "spamtest", "spamtestplus", and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric "scores". It is the responsibility of the underlying Sieve implementation to do the actual checks that result in proper input to the tests. [STANDARDS-TRACK]

 draft-ietf-sieve-spamtestbis-05 RFC3685 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5235 RFC5236 Improved Packet Reordering Metrics A. Jayasumana N. Piratla T. Banka A. Bare R. Whitner June 2008 ASCII HTML 26 reorder density rd reorder buffer-occupancy density rbd

This document presents two improved metrics for packet reordering, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density (RBD). A threshold is used to clearly define when a packet is considered lost, to bound computational complexity at O(N), and to keep the memory requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering.

These metrics are simple to compute yet comprehensive in their characterization of packet reordering. The measures are robust and orthogonal to packet loss and duplication. This memo provides information for the Internet community.

 draft-jayasumana-reorder-density-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5236 RFC5237 IANA Allocation Guidelines for the Protocol Field J. Arkko S. Bradner February 2008 ASCII HTML 5 ipv4 header next header field internet assigned numbers authority IP

This document revises the IANA guidelines for allocating new Protocol field values in IPv4 header. It modifies the rules specified in RFC 2780 by removing the Expert Review option. The change will also affect the allocation of Next Header field values in IPv6. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-arkko-rfc2780-proto-update-02 RFC2780 BCP0037 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5237 10.17487/RFC5237 RFC5238 Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) T. Phelan May 2008 ASCII HTML 10 tls transport protocol

This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. [STANDARDS-TRACK]

 draft-ietf-dccp-dtls-06 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC5238 RFC5239 A Framework for Centralized Conferencing M. Barnes C. Boulton O. Levin June 2008 ASCII HTML 57 call signaling call signalling

This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part (ISUP), to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. [STANDARDS-TRACK]

 draft-ietf-xcon-framework-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon http://www.rfc-editor.org/errata_search.php?rfc=5239 10.17487/RFC5239 RFC5240 Protocol Independent Multicast (PIM) Bootstrap Router MIB B. Joshi R. Bijlani June 2008 ASCII HTML 23 management information base bootstrap router bsr PIM-BSR-MIB

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Bootstrap Router (BSR) mechanism for PIM (Protocol Independent Multicast). [STANDARDS-TRACK]

 draft-ietf-pim-bsr-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5240 10.17487/RFC5240 RFC5241 Naming Rights in IETF Protocols A. Falk S. Bradner April 1 2008 ASCII HTML 12 april fools field naming rights

This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields. This memo describes a process for assignment of rights and explores some of the issues associated with the process. Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5241 RFC5242 A Generalized Unified Character Code: Western European and CJK Sections J. Klensin H. Alvestrand April 1 2008 ASCII HTML 14 idn latin greek cyrilllic chinese internationalized domain names

Many issues have been identified with the use of general-purpose character sets for internationalized domain names and similar purposes. This memo describes a fully unified coded character set for scripts based on Latin, Greek, Cyrillic, and Chinese (CJK) characters. It is not a complete specification of that character set. This memo provides information for the Internet community.

 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5242 RFC5243 OSPF Database Exchange Summary List Optimization R. Ogier May 2008 ASCII HTML 5

This document describes a backward-compatible optimization for the Database Exchange process in OSPFv2 and OSPFv3. In this optimization, a router does not list a Link State Advertisement (LSA) in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor. This optimization reduces Database Description overhead by about 50% in large networks. This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets. This memo provides information for the Internet community.

 draft-ogier-ospf-dbex-opt-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5243 10.17487/RFC5243 RFC5244 Definition of Events for Channel-Oriented Telephony Signalling H. Schulzrinne T. Taylor June 2008 ASCII HTML 23 event code telephony event rtp payload

This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. It supersedes and adds to the original assignment of event codes for this purpose in Section 3.14 of RFC 2833. As documented in Appendix A of RFC 4733, some of the RFC 2833 events have been deprecated because their specification was ambiguous, erroneous, or redundant. In fact, the degree of change from Section 3.14 of RFC 2833 is such that implementations of the present document will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling. This document expands and improves the coverage of signalling systems compared to RFC 2833. [STANDARDS-TRACK]

 draft-ietf-avt-rfc2833biscas-05 RFC4733 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5244 RFC5245 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols J. Rosenberg April 2010 ASCII HTML 117

This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). [STANDARDS-TRACK]

 draft-ietf-mmusic-ice-19 RFC4091 RFC4092 RFC8445 RFC8839 RFC6336 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5245 10.17487/RFC5245 RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2 T. Dierks E. Rescorla August 2008 ASCII HTML 104 idea international data algorithm symmetric transport protocol layer authentication privacy

This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]

 draft-ietf-tls-rfc4346-bis-10 RFC3268 RFC4346 RFC4366 RFC8446 RFC4492 RFC5746 RFC5878 RFC6176 RFC7465 RFC7507 RFC7568 RFC7627 RFC7685 RFC7905 RFC7919 RFC8447 RFC9155 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5246 10.17487/RFC5246 RFC5247 Extensible Authentication Protocol (EAP) Key Management Framework B. Aboba D. Simon P. Eronen August 2008 ASCII HTML 79 extensible network access authentication key hierarchy methods

The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied. [STANDARDS-TRACK]

 draft-ietf-eap-keying-22 RFC3748 RFC8940 PROPOSED STANDARD PROPOSED STANDARD IETF int eap http://www.rfc-editor.org/errata_search.php?rfc=5247 10.17487/RFC5247 RFC5248 A Registry for SMTP Enhanced Mail System Status Codes T. Hansen J. Klensin June 2008 ASCII HTML 11 simple mail transfer protocol

The specification for enhanced mail system status codes, RFC 3463, establishes a new code model and lists a collection of status codes. While it anticipated that more codes would be added over time, it did not provide an explicit mechanism for registering and tracking those codes. This document specifies an IANA registry for mail system enhanced status codes, and initializes that registry with the codes so far established in published standards-track documents, as well as other codes that have become established in the industry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-hansen-4468upd-mailesc-registry-05 RFC3463 RFC4468 RFC4954 BCP0138 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5248 RFC5249 Templates for Internet-Drafts Containing MIB Modules D. Harrington Editor July 2008 ASCII HTML 4 network management management information base mib smiv2 template

This memo references three annotated templates for IETF documents that contain the definition of MIB modules. It is intended to reduce the work of the editors of such documents, making these documents more uniform and easier to read and review, thus furthering the quality of such documents and expediting their publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-harrington-text-mib-doc-template-06 BCP0139 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5249 RFC5250 The OSPF Opaque LSA Option L. Berger I. Bryskin A. Zinin R. Coltun July 2008 ASCII HTML 17 OSPF-LSA] open shortest path first link state advertisement opaque lsas

This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology.

This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs originated outside of the router's OSPF area. [STANDARDS-TRACK]

 draft-ietf-ospf-rfc2370bis-05 RFC2370 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5250 10.17487/RFC5250 RFC5251 Layer 1 VPN Basic Mode D. Fedyk Editor Y. Rekhter Editor D. Papadimitriou R. Rabbat L. Berger July 2008 ASCII HTML 24 virtual private network l1vpn l1vpn bm

This document describes the Basic Mode of Layer 1 VPNs (L1VPNs). L1VPN Basic Mode (L1VPN BM) is a port-based VPN. In L1VPN Basic Mode, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port topology. This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM. [STANDARDS-TRACK]

 draft-ietf-l1vpn-basic-mode-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l1vpn http://www.rfc-editor.org/errata_search.php?rfc=5251 10.17487/RFC5251 RFC5252 OSPF-Based Layer 1 VPN Auto-Discovery I. Bryskin L. Berger July 2008 ASCII HTML 11 open shortest path first l1vpn layer 1 virtual private network

This document defines an Open Shortest Path First (OSPF) based Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This mechanism enables provider edge (PE) devices using OSPF to dynamically learn about the existence of each other, and attributes of configured customer edge (CE) links and their associations with L1VPNs. This document builds on the L1VPN framework and requirements and provides a L1VPN basic mode auto-discovery mechanism. [STANDARDS-TRACK]

 draft-ietf-l1vpn-ospf-auto-discovery-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l1vpn http://www.rfc-editor.org/errata_search.php?rfc=5252 10.17487/RFC5252 RFC5253 Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode T. Takeda Editor July 2008 ASCII HTML 19 gmpls generalized multiprotocol label switching l1vpn bm

This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs).

L1VPNs provide customer services and connectivity at Layer 1 over Layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode, where the Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic Mode L1VPN. This memo provides information for the Internet community.

 draft-ietf-l1vpn-applicability-basic-mode-05 INFORMATIONAL INFORMATIONAL IETF rtg l1vpn 10.17487/RFC5253 RFC5254 Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) N. Bitar Editor M. Bocci Editor L. Martini Editor October 2008 ASCII HTML 27 Pseudowire PWE3 multi-segment MS-PW SS-PW S-PE T-PE

This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains. These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains. This memo provides information for the Internet community.

 draft-ietf-pwe3-ms-pw-requirements-07 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5254 10.17487/RFC5254 RFC5255 Internet Message Access Protocol Internationalization C. Newman A. Gulbrandsen A. Melnikov June 2008 ASCII HTML 20 imap imapv4 imap4

Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions that improve international support including language negotiation for international error text, translations for namespace prefixes, and comparator negotiation for search, sort, and thread. [STANDARDS-TRACK]

 draft-ietf-imapext-i18n-15 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=5255 10.17487/RFC5255 RFC5256 Internet Message Access Protocol - SORT and THREAD Extensions M. Crispin K. Murchison June 2008 ASCII HTML 19 ordered subject references imap capability

This document describes the base-level server-based sorting and threading extensions to the IMAP protocol. These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views. [STANDARDS-TRACK]

 draft-ietf-imapext-sort-20 RFC5957 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext 10.17487/RFC5256 RFC5257 Internet Message Access Protocol - ANNOTATE Extension C. Daboo R. Gellens June 2008 ASCII HTML 31 imap

The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.

Note that this document was the product of a WG that had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard. The IETF solicits implementations and implementation reports in order to make further progress.

Implementers should be aware that this specification may change in an incompatible manner when going to Proposed Standard status. However, any incompatible changes will result in a new capability name being used to prevent problems with any deployments of the experimental extension. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-imapext-annotate-16 EXPERIMENTAL EXPERIMENTAL IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=5257 10.17487/RFC5257 RFC5258 Internet Message Access Protocol version 4 - LIST Command Extensions B. Leiba A. Melnikov June 2008 ASCII HTML 31 imap4 ,list lsub extended list email

IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. [STANDARDS-TRACK]

 draft-ietf-imapext-list-extensions-18 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext 10.17487/RFC5258 RFC5259 Internet Message Access Protocol - CONVERT Extension A. Melnikov Editor P. Coates Editor July 2008 ASCII HTML 30 IMAP Lemonade CONVERT conversion transcoding

CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences, or on server settings. [STANDARDS-TRACK]

 draft-ietf-lemonade-convert-20 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5259 RFC5260 Sieve Email Filtering: Date and Index Extensions N. Freed July 2008 ASCII HTML 13 smtp esmtp date index

This document describes the "date" and "index" extensions to the Sieve email filtering language. The "date" extension gives Sieve the ability to test date and time values in various ways. The "index" extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated. [STANDARDS-TRACK]

 draft-freed-sieve-date-index-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5260 10.17487/RFC5260 RFC5261 An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors J. Urpalainen September 2008 ASCII HTML 40

Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic &lt;add&gt;, &lt;replace&gt;, and &lt;remove&gt; directives a set of patches can then be applied to update an existing XML document. [STANDARDS-TRACK]

 draft-ietf-simple-xml-patch-ops-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=5261 10.17487/RFC5261 RFC5262 Presence Information Data Format (PIDF) Extension for Partial Presence M. Lonnfors E. Leppanen H. Khartabil J. Urpalainen September 2008 ASCII HTML 16

The Presence Information Document Format (PIDF) specifies the baseline XML-based format for describing presence information. One of the characteristics of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist, it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type that enables transporting of either only the changed parts or the full PIDF-based presence information. [STANDARDS-TRACK]

 draft-ietf-simple-partial-pidf-format-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5262 RFC5263 Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information M. Lonnfors J. Costa-Requena E. Leppanen H. Khartabil September 2008 ASCII HTML 16 pidf presence information data format

By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed. [STANDARDS-TRACK]

 draft-ietf-simple-partial-notify-10 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5263 RFC5264 Publication of Partial Presence Information A. Niemi M. Lonnfors E. Leppanen September 2008 ASCII HTML 15

The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitute a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. [STANDARDS-TRACK]

 draft-ietf-simple-partial-publish-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5264 RFC5265 Mobile IPv4 Traversal across IPsec-Based VPN Gateways S. Vaarala E. Klovning June 2008 ASCII HTML 39 mobile ip mobile ipv4 ipsec mipv4

This document outlines a solution for the Mobile IPv4 (MIPv4) and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. [STANDARDS-TRACK]

 draft-ietf-mip4-vpn-problem-solution-05 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC5265 RFC5266 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) V. Devarapalli P. Eronen June 2008 ASCII HTML 15

Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-mip4-mobike-connectivity-03 BCP0136 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int mip4 10.17487/RFC5266 RFC5267 Contexts for IMAP4 D. Cridland C. King July 2008 ASCII HTML 18 imap4rev1 esort context

The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results that can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. [STANDARDS-TRACK]

 draft-cridland-imap-context-05 RFC5465 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5267 RFC5268 Mobile IPv6 Fast Handovers R. Koodli Editor June 2008 ASCII HTML 48 mipv6 handover latency

Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care-of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. [STANDARDS-TRACK]

 draft-ietf-mipshop-fmipv6-rfc4068bis-07 RFC4068 RFC5568 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5268 RFC5269 Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND) J. Kempf R. Koodli June 2008 ASCII HTML 14 fast binding update

Fast Mobile IPv6 requires that a Fast Binding Update is secured using a security association shared between an Access Router and a Mobile Node in order to avoid certain attacks. In this document, a method for provisioning a shared key from the Access Router to the Mobile Node is defined to protect this signaling. The Mobile Node generates a public/private key pair using the same public key algorithm as for SEND (RFC 3971). The Mobile Node sends the public key to the Access Router. The Access Router encrypts a shared handover key using the public key and sends it back to the Mobile Node. The Mobile Node decrypts the shared handover key using the matching private key, and the handover key is then available for generating an authenticator on a Fast Binding Update. The Mobile Node and Access Router use the Router Solicitation for Proxy Advertisement and Proxy Router Advertisement from Fast Mobile IPv6 for the key exchange. The key exchange messages are required to have SEND security; that is, the source address is a Cryptographically Generated Address (CGA) and the messages are signed using the CGA private key of the sending node. This allows the Access Router, prior to providing the shared handover key, to verify the authorization of the Mobile Node to claim the address so that the previous care-of CGA in the Fast Binding Update can act as the name of the key. [STANDARDS-TRACK]

 draft-ietf-mipshop-handover-key-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5269 RFC5270 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks H. Jang J. Jee Y. Han S. Park J. Cha June 2008 ASCII HTML 18 Mobile IPv6 Handover optimization Cross-layer design

This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the IEEE 802.16e suite of specifications. The proposed scheme tries to achieve seamless handover by exploiting the link-layer handover indicators and thereby synchronizing the IEEE 802.16e handover procedures with the Mobile IPv6 fast handover procedures efficiently. This memo provides information for the Internet community.

 draft-ietf-mipshop-fh80216e-07 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC5270 RFC5271 Mobile IPv6 Fast Handovers for 3G CDMA Networks H. Yokota G. Dommety June 2008 ASCII HTML 22 FMIP handoff 3GPP2

Mobile IPv6 is designed to maintain its connectivity while moving from one network to another. It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node (MN) moves between access routers. However, this handover procedure requires not only movement detection by the MN, but also the acquisition of a new Care-of Address and Mobile IPv6 registration with the new care-of address before the traffic can be sent or received in the target network. During this period, packets destined for the mobile node may be lost, which may not be acceptable for a real-time application such as Voice over IP (VoIP) or video telephony. This document specifies fast handover methods in the 3G CDMA networks in order to reduce latency and packet loss during handover. This memo provides information for the Internet community.

 draft-ietf-mipshop-3gfh-07 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC5271 RFC5272 Certificate Management over CMS (CMC) J. Schaad M. Myers June 2008 ASCII HTML 83 certificate management protocol cryptographic message syntax pki public key infrastructure

This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:

1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and

2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.

CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-TRACK]

 draft-ietf-pkix-2797-bis-07 RFC2797 RFC6402 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5272 10.17487/RFC5272 RFC5273 Certificate Management over CMS (CMC): Transport Protocols J. Schaad M. Myers June 2008 ASCII HTML 7 cryptographic message syntax http file mail tcp

This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. [STANDARDS-TRACK]

 draft-ietf-pkix-cmc-trans-08 RFC6402 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5273 10.17487/RFC5273 RFC5274 Certificate Management Messages over CMS (CMC): Compliance Requirements J. Schaad M. Myers June 2008 ASCII HTML 13 cryptographic message syntax cmc enrollment protocol

This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. [STANDARDS-TRACK]

 draft-ietf-pkix-cmc-compl-05 RFC6402 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5274 RFC5275 CMS Symmetric Key Management and Distribution S. Turner June 2008 ASCII HTML 89 cryptographic message syntax symmetric cryptographic algorithms certificate management over cms cmc

This document describes a mechanism to manage (i.e., set up, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanism uses the Cryptographic Message Syntax (CMS) protocol and Certificate Management over CMS (CMC) protocol to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support Secure/Multipurpose Internet Mail Extensions (S/MIME) Mail List Agents (MLAs). [STANDARDS-TRACK]

 draft-ietf-smime-symkeydist-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5275 10.17487/RFC5275 RFC5276 Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records C. Wallace August 2008 ASCII HTML 13 ERS Evidence Record SCVP Server-based Certificate Validation Protocol PKI artifact preservation

The Server-based Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support the non-repudiation of the existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust in the certificates can be established after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes usage of the SCVP WantBack feature to convey evidence records, enabling SCVP responders to provide preservation evidence for certificates and certificate revocation lists (CRLs). [STANDARDS-TRACK]

 draft-ietf-ltans-ers-scvp-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC5276 RFC5277 NETCONF Event Notifications S. Chisholm H. Trevino July 2008 ASCII HTML 35 XML Extensible Markup Language NETCONF Event Asynchronous Message Notification

This document defines mechanisms that provide an asynchronous message notification delivery service for the Network Configuration protocol (NETCONF). This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities and operations necessary to support this service. [STANDARDS-TRACK]

 draft-ietf-netconf-notification-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=5277 10.17487/RFC5277 RFC5278 IANA Registration of Enumservices for Voice and Video Messaging J. Livingood D. Troshynski July 2008 ASCII HTML 22 vmsg voicemsg videomsg unifmsg sip sips http https tel

This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and "unifmsg". Each type also registers the subtypes "sip", "sips", "http", and "https", as well as the subtype "tel" for the "voicemsg" type. [STANDARDS-TRACK]

 draft-ietf-enum-vmsg-02 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5278 RFC5279 A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP) A. Monrad S. Loreto July 2008 ASCII HTML 7 nid namespace identifier 3gpp

This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the 3rd Generation Partnership Project (3GPP). 3GPP defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the 3GPP Support Team. This memo provides information for the Internet community.

 draft-monrad-sipping-3gpp-urn-namespace-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5279 10.17487/RFC5279 RFC5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile D. Cooper S. Santesson S. Farrell S. Boeyen R. Housley W. Polk May 2008 ASCII HTML 151 X.509 v3 X.509 v2 certificate extensions

This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]

 draft-ietf-pkix-rfc3280bis-11 RFC3280 RFC4325 RFC4630 RFC6818 RFC8398 RFC8399 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5280 10.17487/RFC5280 RFC5281 Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) P. Funk S. Blake-Wilson August 2008 ASCII HTML 51 EAP AAA Authentication TLS

EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. This memo provides information for the Internet community.

 draft-funk-eap-ttls-v0-05 RFC8996 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5281 10.17487/RFC5281 RFC5282 Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol D. Black D. McGrew August 2008 ASCII HTML 19 encryption cipher combined mode algorithms aes gcm advanced encryption standard in galois/counter mode aes ccm aes in couner with cbc-mac mode

An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol.

The use of two specific authenticated encryption algorithms with the IKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload. [STANDARDS-TRACK]

 draft-black-ipsec-ikev2-aead-modes-01 RFC4306 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5282 10.17487/RFC5282 RFC5283 LDP Extension for Inter-Area Label Switched Paths (LSPs) B. Decraene JL. Le Roux I. Minei July 2008 ASCII HTML 12 LDP label mapping procedures longest-match prefix aggregation

To facilitate the establishment of Label Switched Paths (LSPs) that would span multiple IGP areas in a given Autonomous System (AS), this document describes a new optional Longest-Match Label Mapping Procedure for the Label Distribution Protocol (LDP).

This procedure allows the use of a label if the Forwarding Equivalence Class (FEC) Element matches an entry in the Routing Information Base (RIB). Matching is defined by an IP longest-match search and does not mandate an exact match. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-interarea-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5283 10.17487/RFC5283 RFC5284 User-Defined Errors for RSVP G. Swallow A. Farrel August 2008 ASCII HTML 9 resource reservation protocol user_error_spec error_spec

The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP.

This document defines a USER_ERROR_SPEC to be used in addition to the ERROR_SPEC to carry additional user information related to errors. [STANDARDS-TRACK]

 draft-ietf-tsvwg-rsvp-user-error-spec-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5284 RFC5285 A General Mechanism for RTP Header Extensions D. Singer H. Desineni July 2008 ASCII HTML 17 real-time transport protocol extmap

This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-hdrext-15 RFC8285 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5285 RFC5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates A. Atlas Editor A. Zinin Editor September 2008 ASCII HTML 31 FRR LFA recovery failure routing

This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK]

 draft-ietf-rtgwg-ipfrr-spec-base-12 RFC8518 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg http://www.rfc-editor.org/errata_search.php?rfc=5286 10.17487/RFC5286 RFC5287 Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks A. Vainshtein Y(J). Stein August 2008 ASCII HTML 16 pwe3 pseudowire emulation edge-to-edge tdmoip tdm options

This document defines extension to the Pseudowire Emulation Edge-to-Edge (PWE3) control protocol RFC 4447 and PWE3 IANA allocations RFC 4446 required for the setup of Time-Division Multiplexing (TDM) pseudowires in MPLS networks. [STANDARDS-TRACK]

 draft-ietf-pwe3-tdm-control-protocol-extensi-07 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5287 RFC5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS J. Salowey A. Choudhury D. McGrew August 2008 ASCII HTML 8 advanced encryption standard transport layer security data origin confidentiality

This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, and Diffie-Hellman-based key exchange mechanisms. [STANDARDS-TRACK]

 draft-ietf-tls-rsa-aes-gcm-03 RFC9325 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5288 10.17487/RFC5288 RFC5289 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) E. Rescorla August 2008 ASCII HTML 6 transport layer security mac algorithm

RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS). However, all those cipher suites use HMAC-SHA-1 as their Message Authentication Code (MAC) algorithm. This document describes sixteen new cipher suites for TLS that specify stronger MAC algorithms. Eight use Hashed Message Authentication Code (HMAC) with SHA-256 or SHA-384, and eight use AES in Galois Counter Mode (GCM). This memo provides information for the Internet community.

 draft-ietf-tls-ecc-new-mac-07 PROPOSED STANDARD INFORMATIONAL IETF sec tls 10.17487/RFC5289 RFC5290 Comments on the Usefulness of Simple Best-Effort Traffic S. Floyd M. Allman July 2008 ASCII HTML 20 flow-rate fairness

This document presents some observations on "simple best-effort traffic", defined loosely for the purposes of this document as Internet traffic that is not covered by Quality of Service (QOS) mechanisms, congestion-based pricing, cost-based fairness, admissions control, or the like. One observation is that simple best-effort traffic serves a useful role in the Internet, and is worth keeping. While differential treatment of traffic can clearly be useful, we believe such mechanisms are useful as *adjuncts* to simple best- effort traffic, not as *replacements* of simple best-effort traffic. A second observation is that for simple best-effort traffic, some form of rough flow-rate fairness is a useful goal for resource allocation, where "flow-rate fairness" is defined by the goal of equal flow rates for different flows over the same path. This memo provides information for the Internet community.

 draft-floyd-tsvwg-besteffort-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5290 RFC5291 Outbound Route Filtering Capability for BGP-4 E. Chen Y. Rekhter August 2008 ASCII HTML 12 border gatway protocol orf

This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of Outbound Route Filters (ORFs) that the peer would use to constrain/filter its outbound routing updates to the speaker. [STANDARDS-TRACK]

 draft-ietf-idr-route-filter-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5291 10.17487/RFC5291 RFC5292 Address-Prefix-Based Outbound Route Filter for BGP-4 E. Chen S. Sangli August 2008 ASCII HTML 6 orf border gateway protocol Address Prefix Outbound Route Filter

This document defines a new Outbound Router Filter (ORF) type for BGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address-prefix-based route filtering. This ORF-type supports prefix-length- or range-based matching, wild-card-based address prefix matching, as well as the exact address prefix matching for address families. [STANDARDS-TRACK]

 draft-ietf-idr-bgp-prefix-orf-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC5292 RFC5293 Sieve Email Filtering: Editheader Extension J. Degener P. Guenther August 2008 ASCII HTML 9 addheadaer deleteheader

This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields. [STANDARDS-TRACK]

 draft-ietf-sieve-editheader-11 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5293 RFC5294 Host Threats to Protocol Independent Multicast (PIM) P. Savola J. Lingard August 2008 ASCII HTML 12 security threat analysis

This memo complements the list of multicast infrastructure security threat analysis documents by describing Protocol Independent Multicast (PIM) threats specific to router interfaces connecting hosts. This memo provides information for the Internet community.

 draft-ietf-pim-lasthop-threats-04 INFORMATIONAL INFORMATIONAL IETF rtg pim 10.17487/RFC5294 RFC5295 Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) J. Salowey L. Dondeti V. Narayanan M. Nakhjiri August 2008 ASCII HTML 21 EAP keying EMSK DSRK DSUSRK Domain-Specific Key Derivation Usage-Specific Key Derivation

The Extensible Authentication Protocol (EAP) defined the Extended Master Session Key (EMSK) generation, but reserved it for unspecified future uses. This memo reserves the EMSK for the sole purpose of deriving root keys. Root keys are master keys that can be used for multiple purposes, identified by usage definitions. This document also specifies a mechanism for avoiding conflicts between root keys by deriving them in a manner that guarantees cryptographic separation. Finally, this document also defines one such root key usage: Domain-Specific Root Keys are root keys made available to and used within specific key management domains. [STANDARDS-TRACK]

 draft-ietf-hokey-emsk-hierarchy-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5295 10.17487/RFC5295 RFC5296 EAP Extensions for EAP Re-authentication Protocol (ERP) V. Narayanan L. Dondeti August 2008 ASCII HTML 43 extensible authentication protocol authentication modes

The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. [STANDARDS-TRACK]

 draft-ietf-hokey-erx-14 RFC6696 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5296 10.17487/RFC5296 RFC5297 Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES) D. Harkins October 2008 ASCII HTML 26 authenticated encryption key wrapping key derivation block cipher pseudo-random function

This memo describes SIV (Synthetic Initialization Vector), a block cipher mode of operation. SIV takes a key, a plaintext, and multiple variable-length octet strings that will be authenticated but not encrypted. It produces a ciphertext having the same length as the plaintext and a synthetic initialization vector. Depending on how it is used, SIV achieves either the goal of deterministic authenticated encryption or the goal of nonce-based, misuse-resistant authenticated encryption. This memo provides information for the Internet community.

 draft-dharkins-siv-aes-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5297 RFC5298 Analysis of Inter-Domain Label Switched Path (LSP) Recovery T. Takeda Editor A. Farrel Editor Y. Ikejiri JP. Vasseur August 2008 ASCII HTML 26 mpls gmpls multi-domain environment end-to-end diverse Traffic Engineering LSPs

Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments.

Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering".

This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. This memo provides information for the Internet community.

 draft-ietf-ccamp-inter-domain-recovery-analysis-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5298 10.17487/RFC5298 RFC5299 RFC5300 RFC5301 Dynamic Hostname Exchange Mechanism for IS-IS D. McPherson N. Shen October 2008 ASCII HTML 6 intermediate system to intermediate system routers tlv name-to-systemID

RFC 2763 defined a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. RFC 2763 defined a new TLV that allows the IS-IS routers to flood their name-to-systemID mapping information across the IS-IS network.

This document obsoletes RFC 2763. This document moves the capability provided by RFC 2763 to the Standards Track. [STANDARDS-TRACK]

 draft-ietf-isis-rfc2763bis-00 RFC2763 RFC6232 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5301 10.17487/RFC5301 RFC5302 Domain-Wide Prefix Distribution with Two-Level IS-IS T. Li H. Smit T. Przygienda October 2008 ASCII HTML 16 intermediate system to intermediate system routers loops IP internet protocol

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. This document replaces RFC 2966.

This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) (routers) can distribute IP prefixes between level 1 and level 2, and vice versa. This distribution requires certain restrictions to ensure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. [STANDARDS-TRACK]

 draft-ietf-isis-rfc2966bis-03 RFC2966 RFC1195 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5302 10.17487/RFC5302 RFC5303 Three-Way Handshake for IS-IS Point-to-Point Adjacencies D. Katz R. Saluja D. Eastlake 3rd October 2008 ASCII HTML 11 intermediate system to intermediate system

The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.

Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router.

This extension has been implemented by multiple router vendors; this paper is provided to the Internet community in order to allow interoperable implementations to be built by other vendors. [STANDARDS-TRACK]

 draft-ietf-isis-rfc3373bis-01 RFC3373 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5303 10.17487/RFC5303 RFC5304 IS-IS Cryptographic Authentication T. Li R. Atkinson October 2008 ASCII HTML 11 intermediate system to intermediate system IS-IS authentication MD5 HMAC-MD5 security routing iso international standards organization

This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567.

This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK]

 draft-ietf-isis-rfc3567bis-03 RFC3567 RFC1195 RFC6233 RFC6232 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5304 RFC5305 IS-IS Extensions for Traffic Engineering T. Li H. Smit October 2008 ASCII HTML 17 intermediate system to intermediate system te router lsp data units link state protocol data units

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]

 draft-ietf-isis-te-bis-00 RFC3784 RFC5307 RFC8918 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5305 RFC5306 Restart Signaling for IS-IS M. Shand L. Ginsberg October 2008 ASCII HTML 22 intermediate system to intermediate system LSP database synchronization Link State Routing

This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.

This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 3847. [STANDARDS-TRACK]

 draft-ietf-isis-rfc3847bis-00 RFC3847 RFC8706 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5306 RFC5307 IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2008 ASCII HTML 12 intermediate system to intermediate system

This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]

 draft-ietf-isis-rfc4205bis-00 RFC4205 RFC5305 RFC6001 RFC6002 RFC7074 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5307 10.17487/RFC5307 RFC5308 Routing IPv6 with IS-IS C. Hopps October 2008 ASCII HTML 7 intermediate system to intermediate system tlv osi

This document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes two new TLVs: a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method, one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. [STANDARDS-TRACK]

 draft-ietf-isis-ipv6-07 RFC7775 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5308 RFC5309 Point-to-Point Operation over LAN in Link State Routing Protocols N. Shen Editor A. Zinin Editor October 2008 ASCII HTML 10 broadcast

The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. This memo provides information for the Internet community.

 draft-ietf-isis-igp-p2p-over-lan-06 INFORMATIONAL INFORMATIONAL IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5309 10.17487/RFC5309 RFC5310 IS-IS Generic Cryptographic Authentication M. Bhatia V. Manral T. Li R. Atkinson R. White M. Fanto February 2009 ASCII HTML 12 IS-IS Security HMAC-SHA Cryptographic Authentication

This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.

Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK]

 draft-ietf-isis-hmac-sha-07 RFC6233 RFC6232 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5310 10.17487/RFC5310 RFC5311 Simplified Extension of Link State PDU (LSP) Space for IS-IS D. McPherson Editor L. Ginsberg S. Previdi M. Shand February 2009 ASCII HTML 12

This document describes a simplified method for extending the Link State PDU (LSP) space beyond the 256 LSP limit. This method is intended as a preferred replacement for the method defined in RFC 3786. [STANDARDS-TRACK]

 draft-ietf-isis-wg-extlsp-05 RFC3786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5311 RFC5312 RFC5313 RFC5314 RFC5315 RFC5316 ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering M. Chen R. Zhang X. Duan December 2008 ASCII HTML 19 multiprotocol label switching generalized mpls gmpls-te mpls-te isis-te flooding

This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter- AS TE path computation.

No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]

 draft-ietf-ccamp-isis-interas-te-extension-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5316 RFC5317 Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile S. Bryant Editor L. Andersson Editor February 2009 ASCII PDF HTML 10 ITU-T MPLS-TP JWT GMPLS agreement PWE3 OAM transport network

This RFC archives the report of the IETF - ITU-T Joint Working Team (JWT) on the application of MPLS to transport networks. The JWT recommended of Option 1: The IETF and the ITU-T jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM (Operations, Administration, and Management), survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process. This RFC is available in ASCII (which contains a summary of the slides) and in PDF (which contains the summary and a copy of the slides). This memo provides information for the Internet community.

 draft-bryant-mpls-tp-jwt-report-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5317 10.17487/RFC5317 RFC5318 The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header) J. Hautakorpi G. Camarillo December 2008 ASCII HTML 12 oma open mobile alliance push to talk over cellular poc

This document specifies the Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of incoming URI lists that have embedded URI lists. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI list that caused the rejection and the individual URIs that form such a URI list. This memo provides information for the Internet community.

 draft-hautakorpi-sipping-uri-list-handling-refused-03 RFC8217 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5318 10.17487/RFC5318 RFC5319 RFC5320 The Subnetwork Encapsulation and Adaptation Layer (SEAL) F. Templin Editor February 2010 ASCII HTML 29 virtual topologies mtu maximum transmission units

For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulating border nodes. These virtual topologies may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies. This document defines an Experimental Protocol for the Internet community.

 draft-templin-seal-23 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5320 10.17487/RFC5320 RFC5321 Simple Mail Transfer Protocol J. Klensin October 2008 ASCII HTML 95 SMTP]

This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]

 draft-klensin-rfc2821bis-11 RFC2821 RFC1123 RFC7504 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5321 10.17487/RFC5321 RFC5322 Internet Message Format P. Resnick Editor October 2008 ASCII HTML 57 MAIL] e-mail email electronic mail header address mailbox reply forward resend resent folding Date From Sender Reply-To To Cc Bcc Message-ID In-Reply-To References Subject Comments Keywords Resent-Date Resent-From Resent-Sender Resent-To Resent-Cc Resent-Bcc Resent-Reply-To Resent-Message-ID Return-Path Received

This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]

 draft-resnick-2822upd-06 RFC2822 RFC4021 RFC6854 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5322 10.17487/RFC5322 RFC5323 Web Distributed Authoring and Versioning (WebDAV) SEARCH J. Reschke Editor S. Reddy J. Davis A. Babich November 2008 ASCII HTML 49 HTTP Query Properties

This document specifies a set of methods, headers, and properties composing Web Distributed Authoring and Versioning (WebDAV) SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria. [STANDARDS-TRACK]

 draft-reschke-webdav-search-18 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5323 RFC5324 MIB for Fibre-Channel Security Protocols (FC-SP) C. DeSanti F. Maino K. McCloghrie September 2008 ASCII HTML 216 management information base T11-FC-SP-TC-MIB T11-FC-SP-AUTHENTICATION-MIB T11-FC-SP-ZONING-MIB T11-FC-SP-POLICY-MIB T11-FC-SP-SA-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to FC-SP, the Security Protocols defined for Fibre Channel. [STANDARDS-TRACK]

 draft-ietf-imss-fc-fcsp-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC5324 RFC5325 Licklider Transmission Protocol - Motivation S. Burleigh M. Ramadas S. Farrell September 2008 ASCII HTML 23 ltp round-trip times long-haul

This document describes the motivation for the development of the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.

In an Interplanetary Internet setting deploying the Bundle protocol, LTP is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes.

This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-ltp-motivation-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5325 RFC5326 Licklider Transmission Protocol - Specification M. Ramadas S. Burleigh S. Farrell September 2008 ASCII HTML 54 ltp round-trip times rtt long-haul

This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.

This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-ltp-10 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5326 10.17487/RFC5326 RFC5327 Licklider Transmission Protocol - Security Extensions S. Farrell M. Ramadas S. Burleigh September 2008 ASCII HTML 11 ltp radio frequency automatic repeat request arq

The Licklider Transmission Protocol (LTP) is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document describes security extensions to LTP, and is part of a series of related documents describing LTP.

This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-ltp-extensions-08 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC5327 RFC5328 A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB) A. Adolf P. MacAvock September 2008 ASCII HTML 12 tv television digital television mpeg-2 iptv multimedia content guide program guide metadata

This document describes a Uniform Resource Name (URN) namespace for the Digital Video Broadcasting Project (DVB) for naming persistent resources defined within DVB standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by DVB. This memo provides information for the Internet community.

 draft-adolf-dvb-urn-05 RFC7354 RFC8553 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5328 10.17487/RFC5328 RFC5329 Traffic Engineering Extensions to OSPF Version 3 K. Ishiguro V. Manral A. Davey A. Lindem Editor September 2008 ASCII HTML 12 open shortest path first ospfv3 te

This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. [STANDARDS-TRACK]

 draft-ietf-ospf-ospfv3-traffic-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5329 RFC5330 A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link JP. Vasseur Editor M. Meyer K. Kumaki A. Bonda October 2008 ASCII HTML 8 te lsp

Several Link-type sub-Type-Length-Values (sub-TLVs) have been defined for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) in the context of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE), in order to advertise some link characteristics such as the available bandwidth, traffic engineering metric, administrative group, and so on. By making statistical assumptions about the aggregated traffic carried onto a set of TE Label Switched Paths (LSPs) signalled with zero bandwidth (referred to as "unconstrained TE LSP" in this document), algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSP across a set of equal cost paths. This requires knowledge of the number of unconstrained TE LSPs signalled across a link. This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSPs signalled across a link. [STANDARDS-TRACK]

 draft-ietf-mpls-number-0-bw-te-lsps-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5330 RFC5331 MPLS Upstream Label Assignment and Context-Specific Label Space R. Aggarwal Y. Rekhter E. Rosen August 2008 ASCII HTML 13 upstream-assigned mpls labels

RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". [STANDARDS-TRACK]

 draft-ietf-mpls-upstream-label-07 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5331 10.17487/RFC5331 RFC5332 MPLS Multicast Encapsulations T. Eckert E. Rosen Editor R. Aggarwal Y. Rekhter August 2008 ASCII HTML 11 data link layer codepoint multiaccess media upstream-assigned label mac da medium access layer destination address

RFC 3032 established two data link layer codepoints for MPLS, used to distinguish whether the data link layer frame is carrying an MPLS unicast or an MPLS multicast packet. However, this usage was never deployed. This specification updates RFC 3032 by redefining the meaning of these two codepoints. Both codepoints can now be used to carry multicast packets. The second codepoint (formerly the "multicast codepoint") is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label".

RFC 3032 does not specify the destination address to be placed in the "MAC DA" (Medium Access Layer Destination Address) field of an ethernet frame that carries an MPLS multicast packet. This document provides that specification.

This document updates RFC 3032 and RFC 4023. [STANDARDS-TRACK]

 draft-ietf-mpls-multicast-encaps-10 RFC3032 RFC4023 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5332 RFC5333 IANA Registration of Enumservices for Internet Calendaring R. Mahy B. Hoeneisen October 2009 ASCII HTML 8 ENUM iCal iMIP i TIP CalDAV

This document registers Enumservices for Internet calendaring. Specifically, this document focuses on Enumservices for scheduling with iMIP (iCalendar Message-Based Interoperability Protocol) and for accessing Internet calendaring information with CalDAV (Calendaring Extensions to WebDAV). [STANDARDS-TRACK]

 draft-ietf-enum-calendar-service-04 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5333 RFC5334 Ogg Media Types I. Goncalves S. Pfeiffer C. Montgomery September 2008 ASCII HTML 14 Ogg MIME Video Audio Codecs

This document describes the registration of media types for the Ogg container format and conformance requirements for implementations of these types. This document obsoletes RFC 3534. [STANDARDS-TRACK]

 draft-goncalves-rfc3534bis-07 RFC3534 RFC7845 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5334 RFC5335 Internationalized Email Headers A. Yang Editor September 2008 ASCII HTML 14 unicode utf-8

Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-utf8headers-12 RFC6532 RFC2045 RFC2822 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5335 10.17487/RFC5335 RFC5336 SMTP Extension for Internationalized Email Addresses J. Yao Editor W. Mao Editor September 2008 ASCII HTML 22 EAI UTF8SMTP MAIL TRANSFER

This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-smtpext-13 RFC6531 RFC2821 RFC2822 RFC4952 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5336 10.17487/RFC5336 RFC5337 Internationalized Delivery Status and Disposition Notifications C. Newman A. Melnikov Editor September 2008 ASCII HTML 18 EAI DSN SMTP

Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.

This document experimentally extends RFC 3461, RFC 3464, and RFC 3798. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-dsn-06 RFC6533 RFC3461 RFC3462 RFC3464 RFC3798 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5337 10.17487/RFC5337 RFC5338 Using the Host Identity Protocol with Legacy Applications T. Henderson P. Nikander M. Komu September 2008 ASCII HTML 14 hip cryptographic name space network stack names api application programming interface

This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to using HIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP. This memo provides information for the Internet community.

 draft-ietf-hip-applications-04 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5338 RFC5339 Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN) JL. Le Roux Editor D. Papadimitriou Editor September 2008 ASCII HTML 25 general multiprotocol label switching

This document provides an evaluation of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms against the requirements for Multi-Layer Networks (MLNs) and Multi-Region Networks (MRNs). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy these requirements, and provides guidelines for potential extensions. This memo provides information for the Internet community.

 draft-ietf-ccamp-gmpls-mln-eval-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5339 10.17487/RFC5339 RFC5340 OSPF for IPv6 R. Coltun D. Ferguson J. Moy A. Lindem July 2008 ASCII HTML 94 open shortest path first ospfv3

This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).

Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).

Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.

All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]

 draft-ietf-ospf-ospfv3-update-23 RFC2740 RFC6845 RFC6860 RFC7503 RFC8362 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5340 10.17487/RFC5340 RFC5341 The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry C. Jennings V. Gurbani September 2008 ASCII HTML 7 uniform resource locator schemes

This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups. [STANDARDS-TRACK]

 draft-ietf-iptel-tel-reg-06 RFC3966 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC5341 RFC5342 IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters D. Eastlake 3rd September 2008 ASCII HTML 21 Ethernet Ethertype 802 OUI EUI LSAP

Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols and specifies IANA considerations for allocation of code points under the IANA OUI (Organizationally Unique Identifier). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-eastlake-ethernet-iana-considerations-08 RFC7042 RFC2153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5342 RFC5343 Simple Network Management Protocol (SNMP) Context EngineID Discovery J. Schoenwaelder September 2008 ASCII HTML 9 snmpv3 snmpengineid localengineid

The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity.

This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects.

This document updates RFC 3411. [STANDARDS-TRACK]

 draft-ietf-opsawg-snmp-engineid-discovery-03 RFC3411 STD0078 INTERNET STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC5343 RFC5344 Presence and Instant Messaging Peering Use Cases A. Houri E. Aoki S. Parameswar October 2008 ASCII HTML 9 non-voip collaboration service instant messaging im

This document describes several use cases of peering of non-VoIP (Voice over IP) services between two or more Service Providers. These Service Providers create a peering relationship between themselves, thus enabling their users to collaborate with users on the other Service Provider network. The target of this document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services with presence and, in particular, Instant Messaging (IM). This memo provides information for the Internet community.

 draft-ietf-speermint-consolidated-presence-im-usecases-05 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC5344 RFC5345 Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats J. Schoenwaelder October 2008 ASCII HTML 23 large-scale snmp irtf nmrg network management research group

The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control, and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are.

This document describes an approach to carrying out large-scale SNMP traffic measurements in order to develop a better understanding of how SNMP is used in real-world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study.

This document was produced within the IRTF's Network Management Research Group (NMRG), and it represents the consensus of all of the active contributors to this group. This memo provides information for the Internet community.

 draft-irtf-nmrg-snmp-measure-06 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5345 10.17487/RFC5345 RFC5346 Operational Requirements for ENUM-Based Softswitch Use J. Lim W. Kim C. Park L. Conroy October 2008 ASCII HTML 14 Applications ENUM DNS E.164 NAPTR Softswitch Field Trial

This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean Voice over IP (VoIP) carriers, gained during the ENUM pre-commercial trial hosted by the National Internet Development Agency of Korea (NIDA) in 2006.

These experiences show that an interim solution can maintain the stability of ongoing commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls. This memo provides information for the Internet community.

 draft-ietf-enum-softswitch-req-04 INFORMATIONAL INFORMATIONAL IETF rai enum http://www.rfc-editor.org/errata_search.php?rfc=5346 10.17487/RFC5346 RFC5347 Media Gateway Control Protocol Fax Package F. Andreasen D. Hancock October 2008 ASCII HTML 46 mgcp fax calls fax relay fax transmission

This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement. This memo provides information for the Internet community.

 draft-andreasen-mgcp-fax-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5347 10.17487/RFC5347 RFC5348 TCP Friendly Rate Control (TFRC): Protocol Specification S. Floyd M. Handley J. Padhye J. Widmer September 2008 ASCII HTML 58 tcp-friendly rate control congestion control

This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance.

This document obsoletes RFC 3448 and updates RFC 4342. [STANDARDS-TRACK]

 draft-ietf-dccp-rfc3448bis-06 RFC3448 RFC4342 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=5348 10.17487/RFC5348 RFC5349 Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) L. Zhu K. Jaganathan K. Lauter September 2008 ASCII HTML 10 ecdh elliptic curve diffie-hellman

This document describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT -- the Kerberos Version 5 extension that provides for the use of public key cryptography. This memo provides information for the Internet community.

 draft-zhu-pkinit-ecc-04 INFORMATIONAL INFORMATIONAL IETF sec krb-wg 10.17487/RFC5349 RFC5350 IANA Considerations for the IPv4 and IPv6 Router Alert Options J. Manner A. McDonald September 2008 ASCII HTML 8

This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values. [STANDARDS-TRACK]

 draft-manner-router-alert-iana-03 RFC2113 RFC3175 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5350 RFC5351 An Overview of Reliable Server Pooling Protocols P. Lei L. Ong M. Tuexen T. Dreibholz September 2008 ASCII HTML 15 rserpool

The Reliable Server Pooling effort (abbreviated "RSerPool") provides an application-independent set of services and protocols for building fault-tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in the Reliable Server Pooling suite. This memo provides information for the Internet community.

 draft-ietf-rserpool-overview-06 INFORMATIONAL INFORMATIONAL IETF tsv rserpool 10.17487/RFC5351 RFC5352 Aggregate Server Access Protocol (ASAP) R. Stewart Q. Xie M. Stillman M. Tuexen September 2008 ASCII HTML 53 rserpool enrp endpoint handlespace redundancy protocol

Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.

In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service.

ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol.

The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rserpool-asap-21 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5352 RFC5353 Endpoint Handlespace Redundancy Protocol (ENRP) Q. Xie R. Stewart M. Stillman M. Tuexen A. Silverton September 2008 ASCII HTML 39 rserpool asap aggregate server access protocol fault-tolerant registry

The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rserpool-enrp-21 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5353 RFC5354 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters R. Stewart Q. Xie M. Stillman M. Tuexen September 2008 ASCII HTML 23 rserpool

This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rserpool-common-param-18 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5354 RFC5355 Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats M. Stillman Editor R. Gopal E. Guttman S. Sengodan M. Holdrege September 2008 ASCII HTML 19

Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This document describes security threats to the RSerPool architecture and presents requirements for security to thwart these threats. This memo provides information for the Internet community.

 draft-ietf-rserpool-threats-15 INFORMATIONAL INFORMATIONAL IETF tsv rserpool 10.17487/RFC5355 RFC5356 Reliable Server Pooling Policies T. Dreibholz M. Tuexen September 2008 ASCII HTML 16 rserpool enrp endpoint handlespace redundancy protocol

This document describes server pool policies for Reliable Server Pooling (RSerPool) including considerations for implementing them at Endpoint Handlespace Redundancy Protocol (ENRP) servers and pool users. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rserpool-policies-10 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5356 RFC5357 A Two-Way Active Measurement Protocol (TWAMP) K. Hedayat R. Krzanowski A. Morton K. Yum J. Babiarz October 2008 ASCII HTML 26 two-way measaurement round-trip measurement

The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK]

 draft-ietf-ippm-twamp-09 RFC5618 RFC5938 RFC6038 RFC7717 RFC7750 RFC8545 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=5357 10.17487/RFC5357 RFC5358 Preventing Use of Recursive Nameservers in Reflector Attacks J. Damas F. Neves October 2008 ASCII HTML 7 denial of service dos

This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. It provides recommended configuration as measures to mitigate the attack. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsop-reflectors-are-evil-06 BCP0140 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC5358 RFC5359 Session Initiation Protocol Service Examples A. Johnston Editor R. Sparks C. Cunningham S. Donovan K. Summers October 2008 ASCII HTML 170 sip pbx centrex features hold transfer forwarding screening park pickup redial click call flows

This document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this document are implemented in the SIP user agents, although some require the assistance of a SIP proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join header fields. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sipping-service-examples-15 BCP0144 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC5359 RFC5360 A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP) J. Rosenberg G. Camarillo Editor D. Willis October 2008 ASCII HTML 31

SIP supports communications for several services, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification and DoS (Denial of Service) attacks. This document identifies a framework for consent-based communications in SIP. [STANDARDS-TRACK]

 draft-ietf-sip-consent-framework-04 RFC8217 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5360 10.17487/RFC5360 RFC5361 A Document Format for Requesting Consent G. Camarillo October 2008 ASCII HTML 14 xml extensible markup language premission document

This document defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request a specific recipient permission to perform a particular routing translation. [STANDARDS-TRACK]

 draft-ietf-sipping-consent-format-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5361 RFC5362 The Session Initiation Protocol (SIP) Pending Additions Event Package G. Camarillo October 2008 ASCII HTML 16 consent-related resource list

This document defines the SIP Pending Additions event package. This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list. [STANDARDS-TRACK]

 draft-ietf-sipping-pending-additions-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5362 RFC5363 Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services G. Camarillo A.B. Roach October 2008 ASCII HTML 10

This document describes the need for SIP URI-list services and provides requirements for their invocation. Additionally, it defines a framework for SIP URI-list services, which includes security considerations applicable to these services. [STANDARDS-TRACK]

 draft-ietf-sipping-uri-services-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5363 RFC5364 Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists M. Garcia-Martin G. Camarillo October 2008 ASCII HTML 17 XML copy control resource list

In certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems. [STANDARDS-TRACK]

 draft-ietf-sipping-capacity-attribute-07 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5364 RFC5365 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) M. Garcia-Martin G. Camarillo October 2008 ASCII HTML 18 user agent client uac sip message request uniform resource identifier list message uri list

This document specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service. The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list. [STANDARDS-TRACK]

 draft-ietf-sip-uri-list-message-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5365 RFC5366 Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP) G. Camarillo A. Johnston October 2008 ASCII HTML 13 sip uri list invite-contatined uri

This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a User Agent Client to provide a conference server with the initial list of participants using an INVITE-contained URI list. [STANDARDS-TRACK]

 draft-ietf-sip-uri-list-conferencing-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5366 RFC5367 Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP) G. Camarillo A.B. Roach O. Levin October 2008 ASCII HTML 9 subscribe request resrouce list

This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE request. Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' states using a single SUBSCRIBE dialog. [STANDARDS-TRACK]

 draft-ietf-sip-uri-list-subscribe-02 RFC3265 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5367 RFC5368 Referring to Multiple Resources in the Session Initiation Protocol (SIP) G. Camarillo A. Niemi M. Isomaki M. Garcia-Martin H. Khartabil October 2008 ASCII HTML 13 sip refer refer-to multipler-refer

This document defines extensions to the SIP REFER method so that it can be used to refer to multiple resources in a single request. These extensions include the use of pointers to Uniform Resource Identifier (URI) lists in the Refer-To header field and the "multiple-refer" SIP option-tag. [STANDARDS-TRACK]

 draft-ietf-sip-multiple-refer-03 RFC8262 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5368 RFC5369 Framework for Transcoding with the Session Initiation Protocol (SIP) G. Camarillo October 2008 ASCII HTML 10 transcoding services conference bridge model third-party call control model deaf hard of hearing speech-impaired

This document defines a framework for transcoding with SIP. This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third-party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. This memo provides information for the Internet community.

 draft-ietf-sipping-transc-framework-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5369 RFC5370 The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model G. Camarillo October 2008 ASCII HTML 11 transcoding service deaf hard of hearing speech-impaired

This document describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. [STANDARDS-TRACK]

 draft-ietf-sipping-transc-conf-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5370 RFC5371 RTP Payload Format for JPEG 2000 Video Streams S. Futemma E. Itakura A. Leung October 2008 ASCII HTML 31 JPEG 2000 video RTP Real-time Transport Protocol main header tile number Sony Corporation

This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, better known as JPEG 2000. JPEG 2000 features are considered in the design of this payload format. JPEG 2000 is a truly scalable compression technology allowing applications to encode once and decode many different ways. The JPEG 2000 video stream is formed by extending from a single image to a series of JPEG 2000 images. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-jpeg2000-20 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5371 RFC5372 Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery A. Leung S. Futemma E. Itakura October 2008 ASCII HTML 26 Real-time Transport Protocol main header compensation priority field priority mapping table packet-number-based ordering progression-based ordering layer-based ordering resolution-based ordering component-based ordering Sony Corporation

This memo describes extended uses for the payload header in "RTP Payload Format for JPEG 2000 Video Streams" as specified in RFC 5371, for better support of JPEG 2000 features such as scalability and main header recovery.

This memo must be accompanied with a complete implementation of "RTP Payload Format for JPEG 2000 Video Streams". That document is a complete description of the payload header and signaling, this document only describes additional processing for the payload header. There is an additional media type and Session Description Protocol (SDP) marker signaling for implementations of this document. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-jpeg2000-beam-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5372 RFC5373 Requesting Answering Modes for the Session Initiation Protocol (SIP) D. Willis Editor A. Allen November 2008 ASCII HTML 24 PoC PTT auto automatic manual answer loopback diagnostic answer-mode priv-answer-mode

This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or, instead, accepts the request without waiting on user input. The second header, "Priv-Answer-Mode", is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as push-to-talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. [STANDARDS-TRACK]

 draft-ietf-sip-answermode-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5373 RFC5374 Multicast Extensions to the Security Architecture for the Internet Protocol B. Weis G. Gross D. Ignjatic November 2008 ASCII HTML 38 ip ipsec ip multicast packets

The Security Architecture for the Internet Protocol describes security services for traffic at the IP layer. That architecture primarily defines services for Internet Protocol (IP) unicast packets. This document describes how the IPsec security services are applied to IP multicast packets. These extensions are relevant only for an IPsec implementation that supports multicast. [STANDARDS-TRACK]

 draft-ietf-msec-ipsec-extensions-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC5374 RFC5375 IPv6 Unicast Address Assignment Considerations G. Van de Velde C. Popoviciu T. Chown O. Bonness C. Hahn December 2008 ASCII HTML 35 internet protocol version 6 address architecture

One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network. This memo provides information for the Internet community.

 draft-ietf-v6ops-addcon-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=5375 10.17487/RFC5375 RFC5376 Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) N. Bitar R. Zhang K. Kumaki November 2008 ASCII HTML 14 PCE PCECP inter-AS PCE inter-provider PCE inter-AS MPLS-TE inter-provider MPLS-TE inter-AS PCECP inter-provider PCECP GMPLS path computation MPLS-TE path computation path computation element path computation communication protocol path computing element Interas Interas TE

Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label Switched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries.

The Path Computation Element (PCE) is a component that is capable of computing constrained paths for (G)MPLS TE LSPs. The PCE Communication Protocol (PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, as well as between PCEs. The PCECP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCECP are set out in "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLS TE. This memo provides information for the Internet community.

 draft-ietf-pce-interas-pcecp-reqs-06 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5376 RFC5377 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents J. Halpern Editor November 2008 ASCII HTML 8 contributors ietf contributions outbound rights

Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accepts direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions. This memo provides information for the Internet community.

 draft-ietf-ipr-outbound-rights-07 RFC8721 INFORMATIONAL INFORMATIONAL IETF gen ipr http://www.rfc-editor.org/errata_search.php?rfc=5377 10.17487/RFC5377 RFC5378 Rights Contributors Provide to the IETF Trust S. Bradner Editor J. Contreras Editor November 2008 ASCII HTML 16 intellectual property rights copyright ipr

The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ipr-3978-incoming-09 RFC3978 RFC4748 RFC2026 BCP0078 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr http://www.rfc-editor.org/errata_search.php?rfc=5378 10.17487/RFC5378 RFC5379 Guidelines for Using the Privacy Mechanism for SIP M. Munakata S. Schubert T. Ohba February 2010 ASCII HTML 23 SIP Privacy priv-value guideline

This is an informational document that provides guidelines for using the privacy mechanism for the Session Initiation Protocol (SIP) that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and the Session Description Protocol (SDP) parameters for each of the privacy header values (priv-values). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-munakata-sip-privacy-guideline-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5379 RFC5380 Hierarchical Mobile IPv6 (HMIPv6) Mobility Management H. Soliman C. Castelluccia K. ElMalki L. Bellier October 2008 ASCII HTML 26 mobile ipv6 ipv6 neighbor discovery map mobility anchor point

This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the mobile node, its correspondent nodes, and its home agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. [STANDARDS-TRACK]

 draft-ietf-mipshop-4140bis-05 RFC4140 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5380 RFC5381 Experience of Implementing NETCONF over SOAP T. Iijima Y. Atarashi H. Kimura M. Kitani H. Okita October 2008 ASCII HTML 22 simple object access protocol network configuration protocol mns network management system

This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF (Network Configuration Protocol) client and server. It describes an alternative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. This memo provides information for the Internet community.

 draft-iijima-netconf-soap-implementation-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5381 10.17487/RFC5381 RFC5382 NAT Behavioral Requirements for TCP S. Guha Editor K. Biswas B. Ford S. Sivakumar P. Srisuresh October 2008 ASCII HTML 31 network address translation

This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-behave-tcp-08 RFC7857 BCP0142 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC5382 RFC5383 Deployment Considerations for Lemonade-Compliant Mobile Email R. Gellens October 2008 ASCII HTML 12

This document discusses deployment issues and describes requirements for successful deployment of mobile email that are implicit in the IETF lemonade documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-lemonade-deployments-09 BCP0143 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app lemonade 10.17487/RFC5383 RFC5384 The Protocol Independent Multicast (PIM) Join Attribute Format A. Boers I. Wijnands E. Rosen November 2008 ASCII HTML 10 pim-sm multicast distribution tree pim join attribute attr_type

A "Protocol Independent Multicast - Sparse Mode" Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join. Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a "wild card"). Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree. However, there has been no way to do so until now. This document describes a modification of the Join message that allows a node to associate attributes with a particular tree. The attributes are encoded in Type-Length-Value format. [STANDARDS-TRACK]

 draft-ietf-pim-join-attributes-06 RFC7887 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5384 10.17487/RFC5384 RFC5385 Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs J. Touch February 2010 ASCII HTML 20 writing I-Ds writing RFCs authoring tools document preparation

This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It replaces the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. This version obsoletes RFC 3285.

The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-touch-msword-template-v2.0-07 RFC3285 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5385 10.17487/RFC5385 RFC5386 Better-Than-Nothing Security: An Unauthenticated Mode of IPsec N. Williams M. Richardson November 2008 ASCII HTML 11 internet protocol security ikev1 ikev2 sas esp ah pad spd btns unauthenticated ipsec

This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No changes to IKEv2 bits-on-the-wire are required, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better-Than-Nothing Security). [STANDARDS-TRACK]

 draft-ietf-btns-core-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec btns http://www.rfc-editor.org/errata_search.php?rfc=5386 10.17487/RFC5386 RFC5387 Problem and Applicability Statement for Better-Than-Nothing Security (BTNS) J. Touch D. Black Y. Wang November 2008 ASCII HTML 28 ipsec stand-alone btns sab channel-bound btns cbb

The Internet network security protocol suite, IPsec, requires authentication, usually of network-layer entities, to enable access control and provide security services. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates with associated asymmetric keys, or the use of Kerberos (via Kerberized Internet Negotiation of Keys (KINK)). The need to deploy authentication information and its associated identities can be a significant obstacle to the use of IPsec.

This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication. These extensions are intended to protect communication, providing "better-than-nothing security" (BTNS). The extensions may be used on their own (this use is called Stand-Alone BTNS, or SAB) or may be used to provide network-layer security that can be authenticated by higher layers in the protocol stack (this use is called Channel-Bound BTNS, or CBB). The document also explains situations for which use of SAB and/or CBB extensions are applicable. This memo provides information for the Internet community.

 draft-ietf-btns-prob-and-applic-07 INFORMATIONAL INFORMATIONAL IETF sec btns http://www.rfc-editor.org/errata_search.php?rfc=5387 10.17487/RFC5387 RFC5388 Information Model and XML Data Model for Traceroute Measurements S. Niccolini S. Tartarelli J. Quittek T. Dietz M. Swany December 2008 ASCII HTML 75 extensible markup language DISMAN-TRACEROUTE-MIB

This document describes a standard way to store the configuration and the results of traceroute measurements. This document first describes the terminology used in this document and the traceroute tool itself; afterwards, the common information model is defined, dividing the information elements into two semantically separated groups (configuration elements and results elements). Moreover, an additional element is defined to relate configuration elements and results elements by means of a common unique identifier. On the basis of the information model, a data model based on XML is defined to store the results of traceroute measurements. [STANDARDS-TRACK]

 draft-ietf-ippm-storetraceroutes-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC5388 RFC5389 Session Traversal Utilities for NAT (STUN) J. Rosenberg R. Mahy P. Matthews D. Wing October 2008 ASCII HTML 51 SIPs NAT STUN Traversal ICE firewall TURN VOIP

Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.

STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.

This document obsoletes RFC 3489. [STANDARDS-TRACK]

 draft-ietf-behave-rfc3489bis-18 RFC3489 RFC8489 RFC7350 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5389 10.17487/RFC5389 RFC5390 Requirements for Management of Overload in the Session Initiation Protocol J. Rosenberg December 2008 ASCII HTML 14 sip overload handling 503 response

Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insufficient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This document summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. This memo provides information for the Internet community.

 draft-ietf-sipping-overload-reqs-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5390 RFC5391 RTP Payload Format for ITU-T Recommendation G.711.1 A. Sollaud November 2008 ASCII HTML 14 real-time transport protocol itu telecommunication standardization sector audio coded pcmu-wb pcma-wb

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication Standardization Sector (ITU-T) G.711.1 audio codec. Two media type registrations are also included. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-g711wb-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5391 RFC5392 OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering M. Chen R. Zhang X. Duan January 2009 ASCII HTML 17 multiprotocol label switching generalized mpls gmpls-te mpls-te isis-te open shortest path first ospf-te

This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links that can be used to perform inter-AS TE path computation.

No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]

 draft-ietf-ccamp-ospf-interas-te-extension-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5392 RFC5393 Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies R. Sparks Editor S. Lawrence A. Hawrylyshen B. Campen December 2008 ASCII HTML 20 SIP application-layer application layer multimedia multicast unicast

This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic.

This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. [STANDARDS-TRACK]

 draft-ietf-sip-fork-loop-fix-08 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5393 RFC5394 Policy-Enabled Path Computation Framework I. Bryskin D. Papadimitriou L. Berger J. Ash December 2008 ASCII HTML 36 PCE pce policy

The Path Computation Element (PCE) architecture introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy. This memo provides information for the Internet community.

 draft-ietf-pce-policy-enabled-path-comp-04 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5394 RFC5395 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd November 2008 ASCII HTML 17 RRTYPE RCODE AFSDB

Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsext-2929bis-07 RFC2929 RFC6195 RFC1183 RFC3597 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=5395 10.17487/RFC5395 RFC5396 Textual Representation of Autonomous System (AS) Numbers G. Huston G. Michaelson December 2008 ASCII HTML 3 decimal value

A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS number. This textual representation is to be used by all documents, systems, and user interfaces referring to AS numbers. [STANDARDS-TRACK]

 draft-ietf-idr-as-representation-01 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC5396 RFC5397 WebDAV Current Principal Extension W. Sanchez C. Daboo December 2008 ASCII HTML 5 http webdav access control acl authentication

This specification defines a new WebDAV property that allows clients to quickly determine the principal corresponding to the current authenticated user. [STANDARDS-TRACK]

 draft-sanchez-webdav-current-principal-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5397 RFC5398 Autonomous System (AS) Number Reservation for Documentation Use G. Huston December 2008 ASCII HTML 4 autonomous system numbers asn

To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of Autonomous System numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like. This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation. This memo provides information for the Internet community.

 draft-ietf-idr-as-documentation-reservation-00 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC5398 RFC5399 RFC5400 RFC5401 Multicast Negative-Acknowledgment (NACK) Building Blocks B. Adamson C. Bormann M. Handley J. Macker November 2008 ASCII HTML 42

This document discusses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This document obsoletes RFC 3941. [STANDARDS-TRACK]

 draft-ietf-rmt-bb-norm-revised-07 RFC3941 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5401 RFC5402 Compressed Data within an Internet Electronic Data Interchange (EDI) Message T. Harding Editor February 2010 ASCII HTML 7 internet edi

This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ediint-compression-12 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5402 10.17487/RFC5402 RFC5403 RPCSEC_GSS Version 2 M. Eisler February 2009 ASCII HTML 14 Kerberos ONC RPC security authentication integrity GSS GSS-API privacy confidentiality encryption MIC NFS credential verifier mechanism context

This document describes version 2 of the RPCSEC_GSS protocol. Version 2 is the same as version 1 (specified in RFC 2203) except that support for channel bindings has been added. RPCSEC_GSS allows remote procedure call (RPC) protocols to access the Generic Security Services Application Programming Interface (GSS-API). [STANDARDS-TRACK]

 draft-ietf-nfsv4-rpcsec-gss-v2-06 RFC2203 RFC7861 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5403 RFC5404 RTP Payload Format for G.719 M. Westerlund I. Johansson January 2009 ASCII HTML 27 ITU-T g.719 full-band codec

This document specifies the payload format for packetization of the G.719 full-band codec encoded audio signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple channels, multiple frames per payload, and interleaving. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-g719-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5404 10.17487/RFC5404 RFC5405 Unicast UDP Usage Guidelines for Application Designers L. Eggert G. Fairhurst November 2008 ASCII HTML 27 user datagram protocol congestion control

The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of UDP for the designers of unicast applications and upper-layer protocols. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, and middlebox traversal. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-tsvwg-udp-guidelines-11 RFC8085 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC5405 RFC5406 Guidelines for Specifying the Use of IPsec Version 2 S. Bellovin February 2009 ASCII HTML 13 internet security security considerations

The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-bellovin-useipsec-10 BCP0146 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5406 RFC5407 Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP) M. Hasebe J. Koshiko Y. Suzuki T. Yoshikawa P. Kyzivat December 2008 ASCII HTML 60 sip user agents sip ua sip proxy servers

This document gives example call flows of race conditions in the Session Initiation Protocol (SIP). Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them. The elements in these call flows include SIP User Agents and SIP Proxy Servers. Call flow diagrams and message details are given. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sipping-race-examples-06 BCP0147 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC5407 RFC5408 Identity-Based Encryption Architecture and Supporting Data Structures G. Appenzeller L. Martin M. Schertler January 2009 ASCII HTML 30 public key public-key encryption technology

This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that can be used to implement the technology. This memo provides information for the Internet community.

 draft-ietf-smime-ibearch-09 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5408 10.17487/RFC5408 RFC5409 Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS) L. Martin M. Schertler January 2009 ASCII HTML 13 bf bbq content-encryption keys

This document describes the conventions for using the Boneh-Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. This memo provides information for the Internet community.

 draft-ietf-smime-bfibecms-10 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC5409 RFC5410 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0 A. Jerichow Editor L. Piron January 2009 ASCII HTML 7 MIKEY Extension IANA registration OMA BCAST draft-jerichow-msec-mikey-genext-oma-00 RFC4909 RFC6309 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5410 RFC5411 A Hitchhiker's Guide to the Session Initiation Protocol (SIP) J. Rosenberg February 2009 ASCII HTML 39 42 don't panic sip overview,

The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists a current snapshot of the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. This memo provides information for the Internet community.

 draft-ietf-sip-hitchhikers-guide-06 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC5411 RFC5412 Lightweight Access Point Protocol P. Calhoun R. Suri N. Cam-Winget M. Williams S. Hares B. O'Hara S. Kelly February 2010 ASCII HTML 125 lwapp capwap

In recent years, there has been a shift in wireless LAN (WLAN) product architectures from autonomous access points to centralized control of lightweight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility, and radio management out of the access point into a centralized controller.

The IETF's CAPWAP (Control and Provisioning of Wireless Access Points) WG has identified that a standards-based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Lightweight Access Points). This specification defines the Lightweight Access Point Protocol (LWAPP), which addresses the CAPWAP's (Control and Provisioning of Wireless Access Points) protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. This document defines a Historic Document for the Internet community.

 draft-ohara-capwap-lwapp-04 HISTORIC HISTORIC INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5412 10.17487/RFC5412 RFC5413 SLAPP: Secure Light Access Point Protocol P. Narasimhan D. Harkins S. Ponnuswamy February 2010 ASCII HTML 75 capwap

The Control and Provisioning of Wireless Access Points (CAPWAP) problem statement describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) that then enables an AC from one vendor to control and manage a WTP from another.

In this document, we present a protocol that forms the common technology-independent framework and the ability to negotiate and add, on top of this framework, a control protocol that contains a technology-dependent component to arrive at a complete solution. We have also presented two such control protocols -- an 802.11 Control protocol, and another, more generic image download protocol, in this document.

Even though the text in this document is written to specifically address the problem stated in RFC 3990, the solution can be applied to any problem that has a controller (equivalent to the AC) managing one or more network elements (equivalent to the WTP). This document defines a Historic Document for the Internet community.

 draft-narasimhan-ietf-slapp-01 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC5413 RFC5414 Wireless LAN Control Protocol (WiCoP) S. Iino S. Govindan M. Sugiura H. Cheng February 2010 ASCII HTML 54 wlan wireless local area network twp wireless termination points capwap control and provisioning of wireless access points

The popularity of wireless local area networks (WLANs) has led to widespread deployments across different establishments. It has also translated into an increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common.

The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the Control And Provisioning of Wireless Access Points (CAPWAP). This document defines a Historic Document for the Internet community.

 draft-iino-capwap-wicop-02 RFC5415 HISTORIC HISTORIC INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5414 10.17487/RFC5414 RFC5415 Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification P. Calhoun Editor M. Montemurro Editor D. Stanley Editor March 2009 ASCII HTML 155 LWAPP CAPWAP 802.11 IEEE Wireless LAN WiFi Access Point Access Controller Wireless Termination Point

This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. [STANDARDS-TRACK]

 draft-ietf-capwap-protocol-specification-15 RFC5414 RFC8553 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF ops capwap http://www.rfc-editor.org/errata_search.php?rfc=5415 10.17487/RFC5415 RFC5416 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11 P. Calhoun Editor M. Montemurro Editor D. Stanley Editor March 2009 ASCII HTML 76 Operations and Management LWAPP CAPWAP 802.11 IEEE Wireless LAN WiFi Access Point Access Controller Wireless Termination Point

Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller.

This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. [STANDARDS-TRACK]

 draft-ietf-capwap-protocol-binding-ieee80211-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops capwap http://www.rfc-editor.org/errata_search.php?rfc=5416 10.17487/RFC5416 RFC5417 Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option P. Calhoun March 2009 ASCII HTML 6 CAPWAP 802.11 IEEE Wireless LAN WiFi Access Point Access Controller Wireless Termination Point

The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover the Access Controllers to which it is to connect. This document describes the DHCP options to be used by the CAPWAP Protocol. [STANDARDS-TRACK]

 draft-ietf-capwap-dhc-ac-option-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops capwap 10.17487/RFC5417 RFC5418 Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments S. Kelly T. Clancy March 2009 ASCII HTML 34 WLAN security

Early Wireless Local Area Network (WLAN) deployments feature a "fat" Access Point (AP), which serves as a \%stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning of Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments. This memo provides information for the Internet community.

 draft-ietf-capwap-threat-analysis-04 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC5418 RFC5419 Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6) B. Patil G. Dommety January 2009 ASCII HTML 19 authentication signaling message mn ha

Mobile IPv6 defines a set of signaling messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec security association (SA) that is established between the MN and HA. The MIP6 working group has specified a mechanism to secure the Binding Update (BU) and Binding Acknowledgement (BAck) messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the signaling messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain environments. This memo provides information for the Internet community.

 draft-ietf-mip6-whyauthdataoption-07 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC5419 RFC5420 Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) A. Farrel Editor D. Papadimitriou JP. Vasseur A. Ayyangar February 2009 ASCII HTML 22 multiprotocol label switching label switched paths SESSION_ATTRIBUTE

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.

This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.

The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs.

This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. [STANDARDS-TRACK]

 draft-ietf-ccamp-rfc4420bis-03 RFC4420 RFC3209 RFC3473 RFC6510 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5420 10.17487/RFC5420 RFC5421 Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) N. Cam-Winget H. Zhou March 2009 ASCII HTML 10 generic token card eap-gtc

The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within this tunnel, a basic password exchange, based on the Generic Token Card method (EAP-GTC), may be executed to authenticate the peer. This memo provides information for the Internet community.

 draft-zhou-emu-fast-gtc-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5421 RFC5422 Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) N. Cam-Winget D. McGrew J. Salowey H. Zhou March 2009 ASCII HTML 39

The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP- FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning. This memo provides information for the Internet community.

 draft-cam-winget-eap-fast-provisioning-10 RFC8996 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5422 RFC5423 Internet Message Store Events R. Gellens C. Newman March 2009 ASCII HTML 17 imap

One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail) and devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events that interest real-world consumers of such a system.

This document describes events and event parameters that are useful for several cases, including notification to administrative systems and end users. This is not intended as a replacement for a message access facility such as IMAP. [STANDARDS-TRACK]

 draft-ietf-lemonade-msgevent-07 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5423 10.17487/RFC5423 RFC5424 The Syslog Protocol R. Gerhards March 2009 ASCII HTML 38 event notification message syslog message berkeley software distribution transmission messages

This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way.

This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. [STANDARDS-TRACK]

 draft-ietf-syslog-protocol-23 RFC3164 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog http://www.rfc-editor.org/errata_search.php?rfc=5424 10.17487/RFC5424 RFC5425 Transport Layer Security (TLS) Transport Mapping for Syslog F. Miao Editor Y. Ma Editor J. Salowey Editor March 2009 ASCII HTML 13 syslog message syslog security

This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to syslog and how TLS can be used to counter such threats. [STANDARDS-TRACK]

 draft-ietf-syslog-transport-tls-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog http://www.rfc-editor.org/errata_search.php?rfc=5425 10.17487/RFC5425 RFC5426 Transmission of Syslog Messages over UDP A. Okmianski March 2009 ASCII HTML 9 udp User Datagram Protocol

This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. [STANDARDS-TRACK]

 draft-ietf-syslog-transport-udp-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC5426 RFC5427 Textual Conventions for Syslog Management G. Keeni March 2009 ASCII HTML 8 syslog facility syslog severity MIB textual-convention

This MIB module defines textual conventions to represent Facility and Severity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-syslog-tc-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC5427 RFC5428 Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices S. Channabasappa W. De Ketelaere E. Nechamkin April 2009 ASCII HTML 37 snmp simple network management protocol multimedia terminal adapter PKTC-IETF-EVENT-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of events that can be generated by PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]

 draft-ietf-ipcdn-pktc-eventmess-14 RFC9141 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC5428 RFC5429 Sieve Email Filtering: Reject and Extended Reject Extensions A. Stone Editor March 2009 ASCII HTML 14 sieve refuse reject ereject joe-job smtp lmtp spam

This memo updates the definition of the Sieve mail filtering language "reject" extension, originally defined in RFC 3028.

A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces, Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs.

This memo updates the definition of the "reject" action to allow messages to be refused during the SMTP transaction, and defines the "ereject" action to require messages to be refused during the SMTP transaction, if possible.

The "ereject" action is intended to replace the "reject" action wherever possible. The "ereject" action is similar to "reject", but will always favor protocol-level message rejection. [STANDARDS-TRACK]

 draft-ietf-sieve-refuse-reject-09 RFC3028 RFC5228 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5429 10.17487/RFC5429 RFC5430 Suite B Profile for Transport Layer Security (TLS) M. Salter E. Rescorla R. Housley March 2009 ASCII HTML 12 nsa suite b cryptography

The United States government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document defines a profile of Transport Layer Security (TLS) version 1.2 that is fully conformant with Suite B. This document also defines a transitional profile for use with TLS version 1.0 and TLS version 1.1 which employs Suite B algorithms to the greatest extent possible. This memo provides information for the Internet community.

 draft-rescorla-tls-suiteb-11 RFC6460 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5430 RFC5431 Diameter ITU-T Rw Policy Enforcement Interface Application D. Sun March 2009 ASCII HTML 5 diameter command code itu-t ITU-T Rw Policy-Install-Request pir Policy-Install-Answer pia

This document describes the need for a new pair of IANA Diameter Command Codes to be used in a vendor-specific new application, namely for the ITU-T Rec. Q.3303.3 - Rw interface used to send a request/ response for authorizing network Quality of Service (QoS) resources and policy enforcement in a network element, as one of the recommendations of the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T). This memo provides information for the Internet community.

 draft-sun-dime-itu-t-rw-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5431 RFC5432 Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) J. Polk S. Dhesikan G. Camarillo March 2009 ASCII HTML 9 offer/answer media stream

The offer/answer model for the Session Description Protocol (SDP) assumes that endpoints somehow establish the Quality of Service (QoS) required for the media streams they establish. Endpoints in closed environments typically agree out-of-band (e.g., using configuration information) regarding which QoS mechanism to use. However, on the Internet, there is more than one QoS service available. Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism. [STANDARDS-TRACK]

 draft-ietf-mmusic-qos-identification-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5432 RFC5433 Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method T. Clancy H. Tschofenig February 2009 ASCII HTML 38 EAP EAP-GPSK pre-shared key

This memo defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. [STANDARDS-TRACK]

 draft-ietf-emu-eap-gpsk-17 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu 10.17487/RFC5433 RFC5434 Considerations for Having a Successful Birds-of-a-Feather (BOF) Session T. Narten February 2009 ASCII HTML 13 ietf bof working group

This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. [STANDARDS-TRACK]

 draft-narten-successful-bof-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5434 RFC5435 Sieve Email Filtering: Extension for Notifications A. Melnikov Editor B. Leiba Editor W. Segmuller T. Martin January 2009 ASCII HTML 17

Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method, but it is expected that using existing instant messaging infrastructure such as Extensible Messaging and Presence Protocol (XMPP), or Global System for Mobile Communications (GSM) Short Message Service (SMS) messages will be popular. This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. [STANDARDS-TRACK]

 draft-ietf-sieve-notify-12 RFC8580 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5435 RFC5436 Sieve Notification Mechanism: mailto B. Leiba M. Haardt January 2009 ASCII HTML 12 eletctronic mail notification

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. [STANDARDS-TRACK]

 draft-ietf-sieve-notify-mailto-10 RFC3834 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5436 RFC5437 Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre A. Melnikov January 2009 ASCII HTML 14 jabber

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the Extensible Messaging and Presence Protocol (XMPP), also known as Jabber. [STANDARDS-TRACK]

 draft-ietf-sieve-notify-xmpp-09 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5437 RFC5438 Instant Message Disposition Notification (IMDN) E. Burger H. Khartabil February 2009 ASCII HTML 38 im instant messaging cpim common presence and instant messaging

Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing, and display notifications, for page-mode instant messages.

The Common Presence and Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs.

This document also describes how SIP entities behave using this extension. [STANDARDS-TRACK]

 draft-ietf-simple-imdn-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=5438 10.17487/RFC5438 RFC5439 An Analysis of Scaling Issues in MPLS-TE Core Networks S. Yasukawa A. Farrel O. Komolafe February 2009 ASCII HTML 45 multiprotocol label switching traffic engineered scaling concerns lsp label switch path point-to-point mpls-te lsps

Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning.

This document presents an analysis of some of the scaling concerns for the number of Label Switching Paths (LSPs) in MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks.

This document only considers the question of achieving scalability for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint MPLS-TE LSPs are for future study. This memo provides information for the Internet community.

 draft-ietf-mpls-te-scaling-analysis-05 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5439 10.17487/RFC5439 RFC5440 Path Computation Element (PCE) Communication Protocol (PCEP) JP. Vasseur Editor JL. Le Roux Editor March 2009 ASCII HTML 87 MPLS GMPLS Traffic Engineering Label Switched Path

This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]

 draft-ietf-pce-pcep-19 RFC7896 RFC8253 RFC8356 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5440 10.17487/RFC5440 RFC5441 A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths JP. Vasseur Editor R. Zhang N. Bitar JL. Le Roux April 2009 ASCII HTML 18 te lsp path computation element

The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK]

 draft-ietf-pce-brpc-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5441 10.17487/RFC5441 RFC5442 LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail E. Burger G. Parsons March 2009 ASCII HTML 15 enhancements to internet email to supportt diverse service environments Phone

This document specifies the architecture for mobile email, as described by the Open Mobile Alliance (OMA), using Internet Mail protocols. This architecture was an important consideration for much of the work of the LEMONADE (Enhancements to Internet email to Support Diverse Service Environments) working group in the IETF. This document also describes how the LEMONADE architecture meets OMA's requirements for their Mobile Email (MEM) service. This memo provides information for the Internet community.

 draft-ietf-lemonade-architecture-04 INFORMATIONAL INFORMATIONAL IETF app lemonade 10.17487/RFC5442 RFC5443 LDP IGP Synchronization M. Jork A. Atlas L. Fang March 2009 ASCII HTML 7 label distribution protocol interior gateway protocol

In certain networks, there is dependency on the edge-to-edge Label Switched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) applications. For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol (IGP) is operational on a link on which LDP is not. While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border Gateway Protocol (BGP) route-free cores. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. This memo provides information for the Internet community.

 draft-ietf-mpls-ldp-igp-sync-04 RFC6138 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5443 10.17487/RFC5443 RFC5444 Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format T. Clausen C. Dearlove J. Dean C. Adjih February 2009 ASCII HTML 60 routing TLV address

This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. [STANDARDS-TRACK]

 draft-ietf-manet-packetbb-17 RFC7631 RFC8245 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5444 10.17487/RFC5444 RFC5445 Basic Forward Error Correction (FEC) Schemes M. Watson March 2009 ASCII HTML 19 content stream delivery multicast internet protocol

This document provides Forward Error Correction (FEC) Scheme specifications according to the Reliable Multicast Transport (RMT) FEC building block for the Compact No-Code FEC Scheme, the Small Block, Large Block, and Expandable FEC Scheme, the Small Block Systematic FEC Scheme, and the Compact FEC Scheme. This document obsoletes RFC 3695 and assumes responsibility for the FEC Schemes defined in RFC 3452. [STANDARDS-TRACK]

 draft-ietf-rmt-bb-fec-basic-schemes-revised-06 RFC3452 RFC3695 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=5445 10.17487/RFC5445 RFC5446 Service Selection for Mobile IPv4 J. Korhonen U. Nilsson February 2009 ASCII HTML 9 internet protocol version 4 host name agent mobility service subscription

In some Mobile IPv4 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish among the multiple services possibly provisioned to the mobile node. The capability to specify different services in addition to the mobile node's identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within a single mobility service subscription. This document describes a Service Selection extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for their mobility service subscriptions during the registration procedure. This memo provides information for the Internet community.

 draft-korhonen-mip4-service-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5446 RFC5447 Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction J. Korhonen Editor J. Bournelle H. Tschofenig C. Perkins K. Chowdhury February 2009 ASCII HTML 17 Diameter Mobile IPv6 Integrated Scenario

A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters be statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing Authentication, Authorization, and Accounting (AAA) infrastructures. This document describes MIPv6 bootstrapping using the Diameter Network Access Server to home AAA server interface. [STANDARDS-TRACK]

 draft-ietf-dime-mip6-integrated-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=5447 10.17487/RFC5447 RFC5448 Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') J. Arkko V. Lehtovirta P. Eronen May 2009 ASCII HTML 29 EAP AKA AKA' 3GPP

This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1.

This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. This memo provides information for the Internet community.

 draft-arkko-eap-aka-kdf-10 RFC4187 RFC9048 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5448 RFC5449 OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks E. Baccelli P. Jacquet D. Nguyen T. Clausen February 2009 ASCII HTML 31 open shortest path first interface type mobile ad hoc

This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, and is denoted the "OSPFv3 MANET interface type". This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ospf-manet-mpr-04 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5449 10.17487/RFC5449 RFC5450 Transmission Time Offsets in RTP Streams D. Singer H. Desineni March 2009 ASCII HTML 8 real-time transport IJ inter-arrival jitter

This document describes a method to inform Real-time Transport Protocol (RTP) clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-toffset-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5450 RFC5451 Message Header Field for Indicating Message Authentication Status M. Kucherawy April 2009 ASCII HTML 43 authentication-results email authentication result

This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. [STANDARDS-TRACK]

 draft-kucherawy-sender-auth-header-20 RFC7001 RFC6577 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5451 10.17487/RFC5451 RFC5452 Measures for Making DNS More Resilient against Forged Answers A. Hubert R. van Mook January 2009 ASCII HTML 18 spoofing source port hardening

The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder.

Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation.

By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. [STANDARDS-TRACK]

 draft-ietf-dnsext-forgery-resilience-10 RFC2181 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5452 RFC5453 Reserved IPv6 Interface Identifiers S. Krishnan February 2009 ASCII HTML 6 unicast address

Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet. Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them. An IPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences. Since there is no centralized repository for such reserved identifiers, this document aims to create one. [STANDARDS-TRACK]

 draft-ietf-6man-reserved-iids-03 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=5453 10.17487/RFC5453 RFC5454 Dual-Stack Mobile IPv4 G. Tsirtsis V. Park H. Soliman March 2009 ASCII HTML 18 ipv6 mipv4

This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual-stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. [STANDARDS-TRACK]

 draft-ietf-mip4-dsmipv4-10 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=5454 10.17487/RFC5454 RFC5455 Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol S. Sivabalan Editor J. Parker S. Boutros K. Kumaki March 2009 ASCII HTML 9 classtype ds-te diffserv-aware traffic engineering pce

This document specifies a CLASSTYPE object to support Diffserv-Aware Traffic Engineering (DS-TE) where path computation is performed with the aid of a Path Computation Element (PCE). [STANDARDS-TRACK]

 draft-ietf-pce-dste-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5455 10.17487/RFC5455 RFC5456 IAX: Inter-Asterisk eXchange Version 2 M. Spencer B. Capouch E. Guy Editor F. Miller K. Shumard February 2010 ASCII HTML 101 asterisk private branch exchange pbx voip voice over internet protocol

This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk Private Branch Exchange (PBX) and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia.

IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding that decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload type additions needed to support additional services. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-guy-iax-05 RFC8996 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5456 RFC5457 IANA Considerations for IAX: Inter-Asterisk eXchange Version 2 E. Guy Editor February 2010 ASCII HTML 21 asterisk private branch exchange pbx voip voice over internet protocol

This document establishes the IANA registries for IAX, the Inter- Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-guy-iaxiana-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5457 10.17487/RFC5457 RFC5458 Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol H. Cruickshank P. Pillai M. Noisternig S. Iyengar March 2009 ASCII HTML 26 iso 13818-1 transport stream ts ule stream gse generic stream encapsulation

The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a variety of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) defined in RFC 4326. The document also provides the motivation for link-layer security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission.

The analysis also describes applicability to the Generic Stream Encapsulation (GSE) defined by the Digital Video Broadcasting (DVB) Project. This memo provides information for the Internet community.

 draft-ietf-ipdvb-sec-req-09 INFORMATIONAL INFORMATIONAL IETF int ipdvb http://www.rfc-editor.org/errata_search.php?rfc=5458 10.17487/RFC5458 RFC5459 G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support A. Sollaud January 2009 ASCII HTML 7 real-time transport protocol rtp itu-t international telecommunication union g.729.1 audio codec

This document updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) Recommendation G.729.1 audio codec. It adds Discontinuous Transmission (DTX) support to the RFC 4749 specification, in a backward-compatible way. An updated media type registration is included for this payload format. [STANDARDS-TRACK]

 draft-ietf-avt-rfc4749-dtx-update-03 RFC4749 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5459 RFC5460 DHCPv6 Bulk Leasequery M. Stapp February 2009 ASCII HTML 18 dynamic hos configuration protocol ipv6 dhcpv6 bindings

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-bulk-leasequery-06 RFC7653 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=5460 10.17487/RFC5460 RFC5461 TCP's Reaction to Soft Errors F. Gont February 2009 ASCII HTML 13 icmp Internet Control Message Protocol

This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection-establishment attempts that may arise in a number of scenarios, including one in which dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. This memo provides information for the Internet community.

 draft-ietf-tcpm-tcp-soft-errors-09 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC5461 RFC5462 Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field L. Andersson R. Asati February 2009 ASCII HTML 9 exp class of service cos tc field

The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use".

Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field.

To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK]

 draft-ietf-mpls-cosfield-def-08 RFC3032 RFC3270 RFC3272 RFC3443 RFC3469 RFC3564 RFC3985 RFC4182 RFC4364 RFC4379 RFC4448 RFC4761 RFC5129 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5462 10.17487/RFC5462 RFC5463 Sieve Email Filtering: Ihave Extension N. Freed March 2009 ASCII HTML 6 SMTP ESMTP

This document describes the "ihave" extension to the Sieve email filtering language. The "ihave" extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available. The extension also defines a new error control command intended to be used to report situations where no combination of available extensions satisfies the needs of the script. [STANDARDS-TRACK]

 draft-freed-sieve-ihave-04 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5463 RFC5464 The IMAP METADATA Extension C. Daboo February 2009 ASCII HTML 20 internet message access protocol annotation metadata

The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "metadata" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. [STANDARDS-TRACK]

 draft-daboo-imap-annotatemore-17 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5464 10.17487/RFC5464 RFC5465 The IMAP NOTIFY Extension A. Gulbrandsen C. King A. Melnikov February 2009 ASCII HTML 22 Internet Message Access Protocol

This document defines an IMAP extension that allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from such mailboxes. [STANDARDS-TRACK]

 draft-ietf-lemonade-imap-notify-07 RFC5267 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5465 10.17487/RFC5465 RFC5466 IMAP4 Extension for Named Searches (Filters) A. Melnikov C. King February 2009 ASCII HTML 9 Internet Message Access Protocol

The document defines a way to persistently store named IMAP (RFC 3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criterion as a parameter. [STANDARDS-TRACK]

 draft-melnikov-imapext-filters-08 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5466 RFC5467 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) L. Berger A. Takacs D. Caviglia D. Fedyk J. Meuric March 2009 ASCII HTML 14 RSVP-TE TSPEC ADSPEC

This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. The procedures described in this document are experimental. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ccamp-asymm-bw-bidir-lsps-02 RFC6387 EXPERIMENTAL EXPERIMENTAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5467 10.17487/RFC5467 RFC5468 Performance Analysis of Inter-Domain Path Computation Methodologies S. Dasgupta J. de Oliveira JP. Vasseur April 2009 ASCII HTML 10 pce path computation element brpc backward recursive path computation

This document presents a performance comparison between the per-domain path computation method and the Path Computation Element (PCE) Architecture-based Backward Recursive Path Computation (BRPC) procedure. Metrics to capture the significant performance aspects are identified, and detailed simulations are carried out on realistic scenarios. A performance analysis for each of the path computation methods is then undertaken. This memo provides information for the Internet community.

 draft-dasgupta-ccamp-path-comp-analysis-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5468 RFC5469 DES and IDEA Cipher Suites for Transport Layer Security (TLS) P. Eronen Editor February 2009 ASCII HTML 4 ciphersuite data encryption standard international data encryption algorithm

Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346) include cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms. DES (when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS version 1.2 (RFC 5246). This document specifies these cipher suites for completeness and discusses reasons why their use is no longer recommended. This memo provides information for the Internet community.

 draft-ietf-tls-des-idea-02 RFC8996 HISTORIC INFORMATIONAL IETF sec tls 10.17487/RFC5469 RFC5470 Architecture for IP Flow Information Export G. Sadasivan N. Brownlee B. Claise J. Quittek March 2009 ASCII HTML 31 ipfix ipfix device ipfix collector

This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP Flows, and for the export of measured IP Flow information from an IPFIX Device to a Collector. This memo provides information for the Internet community.

 draft-ietf-ipfix-architecture-12 RFC6183 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC5470 RFC5471 Guidelines for IP Flow Information Export (IPFIX) Testing C. Schmoll P. Aitken B. Claise March 2009 ASCII HTML 32 exporting process collecting process

This document presents a list of tests for implementers of IP Flow Information eXport (IPFIX) compliant Exporting Processes and Collecting Processes. This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process and Collecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations. These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation. Therefore, they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes. This memo provides information for the Internet community.

 draft-ietf-ipfix-testing-05 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC5471 RFC5472 IP Flow Information Export (IPFIX) Applicability T. Zseby E. Boschi N. Brownlee B. Claise March 2009 ASCII HTML 31 ie information element PSAMP measurement QoS monitoring attack detection AAA ipfix framework

In this document, we describe the applicability of the IP Flow Information eXport (IPFIX) protocol for a variety of applications. We show how applications can use IPFIX, describe the relevant Information Elements (IEs) for those applications, and present opportunities and limitations of the protocol. Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks. This memo provides information for the Internet community.

 draft-ietf-ipfix-as-12 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5472 10.17487/RFC5472 RFC5473 Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports E. Boschi L. Mark B. Claise March 2009 ASCII HTML 27

This document describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well.

This method works by separating information common to several Flow Records from information specific to an individual Flow Record. Common Flow information is exported only once in a Data Record defined by an Options Template, while the rest of the specific Flow information is associated with the common information via a unique identifier. This memo provides information for the Internet community.

 draft-ietf-ipfix-reducing-redundancy-04 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5473 10.17487/RFC5473 RFC5474 A Framework for Packet Selection and Reporting N. Duffield Editor D. Chiou B. Claise A. Greenberg M. Grossglauser J. Rexford March 2009 ASCII HTML 38 psamp selector collector

This document specifies a framework for the PSAMP (Packet SAMPling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized Selectors, to form a stream of reports on the selected packets, and to export the reports to a Collector. This framework details the components of this architecture, then describes some generic requirements, motivated by the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting, and exporting are described, along with configuration requirements of the PSAMP functions. This memo provides information for the Internet community.

 draft-ietf-psamp-framework-13 INFORMATIONAL INFORMATIONAL IETF ops psamp 10.17487/RFC5474 RFC5475 Sampling and Filtering Techniques for IP Packet Selection T. Zseby M. Molina N. Duffield S. Niccolini F. Raspall March 2009 ASCII HTML 46 psamp metering process

This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore, it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. [STANDARDS-TRACK]

 draft-ietf-psamp-sample-tech-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops psamp 10.17487/RFC5475 RFC5476 Packet Sampling (PSAMP) Protocol Specifications B. Claise Editor A. Johnson J. Quittek March 2009 ASCII HTML 45 exporting process collecting process ipfix ip flow information export

This document specifies the export of packet information from a Packet SAMPling (PSAMP) Exporting Process to a PSAMP Collecting Process. For export of packet information, the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well, and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. [STANDARDS-TRACK]

 draft-ietf-psamp-protocol-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops psamp http://www.rfc-editor.org/errata_search.php?rfc=5476 10.17487/RFC5476 RFC5477 Information Model for Packet Sampling Exports T. Dietz B. Claise P. Aitken F. Dressler G. Carle March 2009 ASCII HTML 46 psamp ipfix ip flow information export

This memo defines an information model for the Packet SAMPling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process. As the PSAMP protocol is based on the IP Flow Information eXport (IPFIX) protocol, this information model is an extension to the IPFIX information model. [STANDARDS-TRACK]

 draft-ietf-psamp-info-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops psamp http://www.rfc-editor.org/errata_search.php?rfc=5477 10.17487/RFC5477 RFC5478 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces J. Polk March 2009 ASCII HTML 6 us defense information systems agency

This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the US Defense Information Systems Agency, and places these namespaces in the IANA registry. [STANDARDS-TRACK]

 draft-ietf-sip-rph-new-namespaces-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5478 RFC5479 Requirements and Analysis of Media Security Management Protocols D. Wing Editor S. Fries H. Tschofenig F. Audet April 2009 ASCII HTML 45 keying Secure RTP SRTP

This document describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document. This memo provides information for the Internet community.

 draft-ietf-sip-media-security-requirements-09 INFORMATIONAL INFORMATIONAL IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5479 10.17487/RFC5479 RFC5480 Elliptic Curve Cryptography Subject Public Key Information S. Turner D. Brown K. Yiu R. Housley T. Polk March 2009 ASCII HTML 20 x.509 asn.1 subjectPubicKeyInfo

This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK]

 draft-ietf-pkix-ecc-subpubkeyinfo-11 RFC3279 RFC8813 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5480 10.17487/RFC5480 RFC5481 Packet Delay Variation Applicability Statement A. Morton B. Claise March 2009 ASCII HTML 39 active measurement ipdv pdv inter-packet delay variation

Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions.

Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks. This memo provides information for the Internet community.

 draft-ietf-ippm-delay-var-as-02 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC5481 RFC5482 TCP User Timeout Option L. Eggert F. Gont March 2009 ASCII HTML 14 Transmission Control Protocol

The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. [STANDARDS-TRACK]

 draft-ietf-tcpm-tcp-uto-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC5482 RFC5483 ENUM Implementation Issues and Experiences L. Conroy K. Fujiwara March 2009 ASCII HTML 30 DNS E.164 NAPTR dynamic delegation discovery system

This document captures experiences in implementing systems based on the ENUM protocol and experiences of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards. Its aim is to help others by reporting both what is "out there" and potential pitfalls in interpreting the set of documents that specify the ENUM protocol. It does not revise the standards but is intended to provide technical input to future revisions of those documents. This memo provides information for the Internet community.

 draft-ietf-enum-experiences-11 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5483 RFC5484 Associating Time-Codes with RTP Streams D. Singer March 2009 ASCII HTML 13 smpte society of motion picture and television engineers media stream

This document describes a mechanism for associating \%time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams in a way that is independent of the RTP payload format of the media stream itself. [STANDARDS-TRACK]

 draft-ietf-avt-smpte-rtp-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5484 RFC5485 Digital Signatures on Internet-Draft Documents R. Housley March 2009 ASCII HTML 14 cms cryptographic message syntax detached signature

This document specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature. This memo provides information for the Internet community.

 draft-housley-internet-draft-sig-file-08 RFC8358 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5485 RFC5486 Session Peering for Multimedia Interconnect (SPEERMINT) Terminology D. Malas Editor D. Meyer Editor March 2009 ASCII HTML 10

This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). This memo provides information for the Internet community.

 draft-ietf-speermint-terminology-17 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC5486 RFC5487 Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode M. Badra March 2009 ASCII HTML 7 PSK Diffie-Hellman Key Exchange advanced encryption standard gcm digest algorithm ciphersuite

RFC 4279 and RFC 4785 describe pre-shared key cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 in their Message Authentication Code (MAC) algorithm. This document describes a set of pre-shared key cipher suites for TLS that uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another set that uses the Advanced Encryption Standard (AES) in Galois Counter Mode (GCM). [STANDARDS-TRACK]

 draft-ietf-tls-psk-new-mac-aes-gcm-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC5487 RFC5488 Network Mobility (NEMO) Management Information Base S. Gundavelli G. Keeni K. Koide K. Nagami April 2009 ASCII HTML 44 mib NEMO-MIB

This memo defines a portion of the Management Information Base (MIB), the Network Mobility (NEMO) support MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. [STANDARDS-TRACK]

 draft-ietf-mext-nemo-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC5488 RFC5489 ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) M. Badra I. Hajjeh March 2009 ASCII HTML 7 pre-shared key Diffie-Hellman Key Exchange Elliptic Curve Cryptography

This document extends RFC 4279, RFC 4492, and RFC 4785 and specifies a set of cipher suites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange with Ephemeral keys (ECDHE). These cipher suites provide Perfect Forward Secrecy (PFS). This memo provides information for the Internet community.

 draft-ietf-tls-ecdhe-psk-05 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC5489 RFC5490 The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata A. Melnikov March 2009 ASCII HTML 8 mail filtering fileinto

This memo defines an extension to the Sieve mail filtering language (RFC 5228) for accessing mailbox and server annotations, checking for mailbox existence, and controlling mailbox creation on "fileinto" action. [STANDARDS-TRACK]

 draft-melnikov-sieve-imapext-metadata-08 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5490 RFC5491 GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations J. Winterbottom M. Thomson H. Tschofenig March 2009 ASCII HTML 28 PIDF-LO civic geodetic location well-formed GeoShape

The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented. In these circumstances, the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent, and interpret locations in a PIDF-LO. It further recommends a subset of Geography Markup Language (GML) 3.1.1 that is mandatory to implement by applications involved in location-based routing. [STANDARDS-TRACK]

 draft-ietf-geopriv-pdif-lo-profile-14 RFC4119 RFC7459 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5491 10.17487/RFC5491 RFC5492 Capabilities Advertisement with BGP-4 J. Scudder R. Chandra February 2009 ASCII HTML 7 bgp idr border gateway protocol capabilities

This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.

This document obsoletes RFC 3392. [STANDARDS-TRACK]

 draft-ietf-idr-rfc3392bis-05 RFC3392 RFC8810 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5492 10.17487/RFC5492 RFC5493 Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network D. Caviglia D. Bramanti D. Li D. McDysan April 2009 ASCII HTML 11 pc spc soft permanent connection data plane traffic

From a carrier perspective, the possibility of turning a permanent connection (PC) into a soft permanent connection (SPC) and vice versa, without actually affecting data plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use data plane connection between the management plane and the control plane, leaving its data plane state untouched.

This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. This memo provides information for the Internet community.

 draft-ietf-ccamp-pc-and-sc-reqs-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5493 RFC5494 IANA Allocation Guidelines for the Address Resolution Protocol (ARP) J. Arkko C. Pignataro April 2009 ASCII HTML 7 IANA rules Address Resolution Protocol ARP

This document specifies the IANA guidelines for allocating new values in the Address Resolution Protocol (ARP). This document also reserves some numbers for experimentation purposes. The changes also affect other protocols that employ values from the ARP name spaces. [STANDARDS-TRACK]

 draft-arkko-arp-iana-rules-06 RFC0826 RFC0951 RFC1044 RFC1329 RFC2131 RFC2132 RFC2176 RFC2225 RFC2834 RFC2835 RFC3315 RFC4338 RFC4361 RFC4701 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5494 RFC5495 Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures D. Li J. Gao A. Satyanarayana S. Bardalai March 2009 ASCII HTML 18 Hello message gmpls

The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) networks for state recovery of control channel or nodal faults.

The GMPLS protocol definitions for RSVP also allow a restarting node to learn which label it previously allocated for use on a Label Switched Path (LSP).

Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchanging RSVP messages with its upstream and downstream neighbors.

This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different.

This document does not define any new processes or procedures. All protocol mechanisms are already defined in the referenced documents. This memo provides information for the Internet community.

 draft-ietf-ccamp-gr-description-04 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5495 RFC5496 The Reverse Path Forwarding (RPF) Vector TLV IJ. Wijnands A. Boers E. Rosen March 2009 ASCII HTML 8 pim protocol independent multicast join attribute

This document describes a use of the Protocol Independent Multicast (PIM) Join Attribute as defined in RFC 5384, which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. [STANDARDS-TRACK]

 draft-ietf-pim-rpf-vector-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5496 10.17487/RFC5496 RFC5497 Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) T. Clausen C. Dearlove March 2009 ASCII HTML 14 Routing Protocol TLV Fisheye FSR Fuzzy-Sighted extension packetbb RFC5444

This document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ message format. It defines two Message TLVs and two Address Block TLVs for representing validity and interval times for MANET routing protocols. [STANDARDS-TRACK]

 draft-ietf-manet-timetlv-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5497 10.17487/RFC5497 RFC5498 IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols I. Chakeres March 2009 ASCII HTML 5 manet protocols

This document enumerates several common IANA allocations for use by Mobile Ad hoc NETwork (MANET) protocols. The following well-known numbers are required: a UDP port number, an IP protocol number, and a link-local multicast group address. [STANDARDS-TRACK]

 draft-ietf-manet-iana-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5498 10.17487/RFC5498 RFC5499 RFC5500 RFC5501 Requirements for Multicast Support in Virtual Private LAN Services Y. Kamite Editor Y. Wada Y. Serbest T. Morin L. Fang March 2009 ASCII HTML 31 L2 VPN VPLS Ethernet P2MP IGMP MLD PIM

This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. This memo provides information for the Internet community.

 draft-ietf-l2vpn-vpls-mcast-reqts-07 INFORMATIONAL INFORMATIONAL IETF int l2vpn 10.17487/RFC5501 RFC5502 The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem J. van Elburg April 2009 ASCII HTML 14 SIP S-CSCF AS ISC

This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Service Control) interface. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation. This memo provides information for the Internet community.

 draft-vanelburg-sipping-served-user-08 RFC8217 RFC8498 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5502 10.17487/RFC5502 RFC5503 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture F. Andreasen B. McKibben B. Marshall March 2009 ASCII HTML 34 P-DCS-TRACE-PARTY-ID P-DCS-OSPS P-DCS-BILLING-INFO P-DCS-LAES P-DCS-Redirect P-DCS-INFO

In order to deploy a residential telephone service at a very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol, RFC 3261, for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. This memo provides information for the Internet community.

 draft-andreasen-sipping-rfc3603bis-07 RFC3603 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5503 RFC5504 Downgrading Mechanism for Email Address Internationalization K. Fujiwara Editor Y. Yoneya Editor March 2009 ASCII HTML 24 EAI Email Address Internationalization Downgrade MAIL

Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-downgrade-12 RFC6530 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5504 RFC5505 Principles of Internet Host Configuration B. Aboba D. Thaler L. Andersson S. Cheshire May 2009 ASCII HTML 25 internet-layer parameter higher-layer configuration

This document describes principles of Internet host configuration. It covers issues relating to configuration of Internet-layer parameters, as well as parameters affecting higher-layer protocols. This memo provides information for the Internet community.

 draft-iab-ip-config-11 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5505 RFC5506 Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences I. Johansson M. Westerlund April 2009 ASCII HTML 17 AVPF non-compound non compound compound

This memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed. Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). This document updates RFC 3550, RFC 3711, and RFC 4585. [STANDARDS-TRACK]

 draft-ietf-avt-rtcp-non-compound-09 RFC3550 RFC3711 RFC4585 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5506 10.17487/RFC5506 RFC5507 Design Choices When Expanding the DNS IAB P. Faltstrom Editor R. Austein Editor P. Koch Editor April 2009 ASCII HTML 18 domain name system resource record type

This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. This memo provides information for the Internet community.

 draft-iab-dns-choices-08 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5507 RFC5508 NAT Behavioral Requirements for ICMP P. Srisuresh B. Ford S. Sivakumar S. Guha April 2009 ASCII HTML 29 ICMP Error payload translation hairpin translation ICMP Query ICMP Error Ping Traceroute

This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP, and other protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-behave-nat-icmp-12 RFC7857 BCP0148 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC5508 RFC5509 Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP) S. Loreto April 2009 ASCII HTML 5 _sip

This document registers with IANA two new DNS SRV protocol labels for resolving Instant Messaging and Presence services with SIP. [STANDARDS TRACK]

 draft-loreto-simple-im-srv-label-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5509 RFC5510 Reed-Solomon Forward Error Correction (FEC) Schemes J. Lacan V. Roca J. Peltotalo S. Peltotalo April 2009 ASCII HTML 28 maximum distance separable MDS

This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), where m is in {2..16}, and its application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). This document also describes a Fully-Specified FEC Scheme for the special case of Reed-Solomon codes over GF(2^^8) when there is no encoding symbol group. Finally, in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding ID 129), this document assigns an FEC Instance ID to the special case of Reed-Solomon codes over GF(2^^8).

Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes, i.e., they enable a receiver to recover the k source symbols from any set of k received symbols. The schemes described here are compatible with the implementation from Luigi Rizzo. [STANDARDS-TRACK]

 draft-ietf-rmt-bb-fec-rs-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5510 RFC5511 Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications A. Farrel April 2009 ASCII HTML 14 routing bnf

Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF.

There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation.

Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work.

This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. [STANDARDS-TRACK]

 draft-farrel-rtg-common-bnf-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5511 RFC5512 The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute P. Mohapatra E. Rosen April 2009 ASCII HTML 13 BGP Encapsulation Encap SAFI Tunnel Softwire 4over6 6over4

In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.

The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing Encapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the Encapsulation Subsequent Address Family Identifier (SAFI) and the IPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. [STANDARDS-TRACK]

 draft-ietf-softwire-encaps-safi-05 RFC9012 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5512 RFC5513 IANA Considerations for Three Letter Acronyms A. Farrel April 1 2009 ASCII HTML 7 tla abbreviation

Three Letter Acronyms (TLAs) are commonly used to identify components of networks or protocols as designed or specified within the IETF. A common concern is that one acronym may have multiple expansions. While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity. This results in contention for acronyms, and confusion in interpretation. Such confusion has the potential to degrade the performance of the Internet as misunderstandings lead to misconfiguration or other operating errors.

Given the growing use of TLAs and the relatively small number available, this document specifies a Badly Construed Proposal (BCP) for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry. This memo provides information for the Internet community.

 draft-farrel-iana-tla-registry-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5513 10.17487/RFC5513 RFC5514 IPv6 over Social Networks E. Vyncke April 1 2009 ASCII HTML 6 facebook

There is a lack of IPv6 utilization in early 2009; this is partly linked to the fact that the number of IPv6 nodes is rather low. This document proposes to vastly increase the number of IPv6 hosts by transforming all Social Networking platforms into IPv6 networks. This will immediately add millions of IPv6 hosts to the existing IPv6 Internet. This document includes sections on addressing and transport of IPv6 over a Social Network. A working prototype has been developed. This memo defines an Experimental Protocol for the Internet community.

 draft-vyncke-ip-over-social-network-01 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5514 10.17487/RFC5514 RFC5515 Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions V. Mammoliti C. Pignataro P. Arberg J. Gibbons P. Howard May 2009 ASCII HTML 28 L2TP Acces Line Information DSLAM

This document describes a set of Layer 2 Tunneling Protocol (L2TP) Attribute Value Pair (AVP) extensions designed to carry the subscriber Access Line identification and characterization information that arrives at the Broadband Remote Access Server (BRAS) with L2TP Access Concentrator (LAC) functionality. It also describes a mechanism to report connection speed changes, after the initial connection speeds are sent during session establishment. The primary purpose of this document is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. The L2TP AVPs defined in this document are applicable to both L2TPv2 and L2TPv3. This memo provides information for the Internet community.

 draft-mammoliti-l2tp-accessline-avp-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5515 10.17487/RFC5515 RFC5516 Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS) M. Jones L. Morand April 2009 ASCII HTML 5 3GPP Release 8 Diameter command codes EPS

This document registers a set of IANA Diameter Command Codes to be used in new vendor-specific Diameter applications defined for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). These new Diameter applications are defined for Mobile Management Entity (MME)- and Serving GPRS (General Packet Radio Service) Support Node (SGSN)-related interfaces in the architecture for the Evolved 3GPP Packet Switched Domain, which is also known as the Evolved Packet System (EPS). This memo provides information for the Internet community.

 draft-jones-dime-3gpp-eps-command-codes-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5516 RFC5517 Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment S. HomChaudhuri M. Foschiano February 2010 ASCII HTML 12

This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such a mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead.

Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the-home-basement networks) are mentioned in the following text to exemplify the mechanism's possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-sanjib-private-vlan-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5517 RFC5518 Vouch By Reference P. Hoffman J. Levine A. Hathcock April 2009 ASCII HTML 12 VBR DKIM SenderID DK reputation

This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail. [STANDARDS-TRACK]

 draft-hoffman-dac-vbr-07 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5518 10.17487/RFC5518 RFC5519 Multicast Group Membership Discovery MIB J. Chesterfield B. Haberman Editor April 2009 ASCII HTML 41 management information base mgmd mld multicast listener discovery MGMD-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. [STANDARDS-TRACK]

 draft-ietf-magma-mgmd-mib-15 RFC2933 RFC3019 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=5519 10.17487/RFC5519 RFC5520 Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism R. Bradford Editor JP. Vasseur A. Farrel April 2009 ASCII HTML 19 confidential path segment cps pcep

Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity.

This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. [STANDARDS-TRACK]

 draft-ietf-pce-path-key-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5520 10.17487/RFC5520 RFC5521 Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions E. Oki T. Takeda A. Farrel April 2009 ASCII HTML 16 MPLS GMPLS Traffic Engineering Label Switched Path

The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed "route exclusions".

The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. [STANDARDS-TRACK]

 draft-ietf-pce-pcep-xro-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5521 10.17487/RFC5521 RFC5522 Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks W. Eddy W. Ivancic T. Davis October 2009 ASCII HTML 31 NEMO aeronautics space exploration route optimization mobility

This document describes the requirements and desired properties of Network Mobility (NEMO) Route Optimization techniques for use in global-networked communications systems for aeronautics and space exploration.

Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of the International Civil Aviation Organization (ICAO) and other aeronautical communications standards bodies. This memo provides information for the Internet community.

 draft-ietf-mext-aero-reqs-04 INFORMATIONAL INFORMATIONAL IETF int mext 10.17487/RFC5522 RFC5523 OSPFv3-Based Layer 1 VPN Auto-Discovery L. Berger April 2009 ASCII HTML 12 open shortest path first layer 1 virtual private network

This document defines an OSPFv3-based (Open Shortest Path First version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism. The notable functional difference is the support of IPv6. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-l1vpn-ospfv3-auto-discovery-03 EXPERIMENTAL EXPERIMENTAL IETF rtg l1vpn 10.17487/RFC5523 RFC5524 Extended URLFETCH for Binary and Converted Parts D. Cridland May 2009 ASCII HTML 9 IMAP Lemonade

The URLFETCH command defined as part of URLAUTH provides a mechanism for third parties to gain access to data held within messages in a user's private store; however, this data is sent verbatim, which is not suitable for a number of applications. This memo specifies a method for obtaining data in forms suitable for non-mail applications. [STANDARDS-TRACK]

 draft-cridland-urlfetch-binary-03 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5524 10.17487/RFC5524 RFC5525 Reliable Server Pooling MIB Module Definition T. Dreibholz J. Mulik April 2009 ASCII HTML 46 RSerPool Management Information Base asap aggregate server access protocol enrp endpoint handlespace redundancy protocol RSERPOOL-MIB

Reliable Server Pooling (RSerPool) is a framework to provide reliable server pooling. The RSerPool framework consists of two protocols: ASAP (Aggregate Server Access Protocol) and ENRP (Endpoint Handlespace Redundancy Protocol). This document defines an \%SMIv2- compliant (Structure of Management Information Version 2) Management Information Base (MIB) module providing access to managed objects in an RSerPool implementation. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-rserpool-mib-12 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5525 RFC5526 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM J. Livingood P. Pfautz R. Stastny April 2009 ASCII HTML 5 e164.arpa

This document defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to "e164.arpa", as defined in RFC 3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees). This memo provides information for the Internet community.

 draft-ietf-enum-infrastructure-07 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5526 RFC5527 Combined User and Infrastructure ENUM in the e164.arpa Tree M. Haberler O. Lendl R. Stastny May 2009 ASCII HTML 10 e164.arpa

This memo defines an interim solution for Infrastructure ENUM in order to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after implementation of the long-term solution. This memo provides information for the Internet community.

 draft-ietf-enum-combined-09 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5527 RFC5528 Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms A. Kato M. Kanda S. Kanno April 2009 ASCII HTML 22 Camellia Block Cipher Mode of operation

This document describes the algorithms and presents test vectors for the Camellia block cipher algorithm in Counter mode (CTR) and Counter with Cipher Block Chaining MAC mode (CCM). The purpose of this document is to make the Camellia-CTR and Camellia-CCM algorithm conveniently available to the Internet Community. This memo provides information for the Internet community.

 draft-kato-camellia-ctrccm-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5528 RFC5529 Modes of Operation for Camellia for Use with IPsec A. Kato M. Kanda S. Kanno April 2009 ASCII HTML 7 IPsec Camellia Block Cipher Mode of operation

This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, and Counter with CBC-MAC (CCM) mode as additional, optional-to- implement Internet Key Exchange Protocol version 2 (IKEv2) and Encapsulating Security Payload (ESP) mechanisms to provide confidentiality, data origin authentication, and connectionless integrity. [STANDARDS-TRACK]

 draft-kato-ipsec-camellia-modes-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5529 RFC5530 IMAP Response Codes A. Gulbrandsen May 2009 ASCII HTML 9 machine-readable response codes

IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text.

This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting. [STANDARDS-TRACK]

 draft-gulbrandsen-imap-response-codes-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5530 10.17487/RFC5530 RFC5531 RPC: Remote Procedure Call Protocol Specification Version 2 R. Thurlow May 2009 ASCII HTML 63 RPC ONC Open Network Computing

This document describes the Open Network Computing (ONC) Remote Procedure Call (RPC) version 2 protocol as it is currently deployed and accepted. This document obsoletes RFC 1831. [STANDARDS-TRACK]

 draft-ietf-nfsv4-rfc1831bis-13 RFC1831 RFC9289 DRAFT STANDARD DRAFT STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5531 10.17487/RFC5531 RFC5532 Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement T. Talpey C. Juszczak May 2009 ASCII HTML 15 RPC XDR ONC RDDP NFSv4

This document addresses enabling the use of Remote Direct Memory Access (RDMA) by the Network File System (NFS) protocols. NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other processing overhead. This document explores the potential benefits of RDMA to these implementations and evaluates the reasons why RDMA is especially well-suited to NFS and network file protocols in general. This memo provides information for the Internet community.

 draft-ietf-nfsv4-nfs-rdma-problem-statement-08 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC5532 RFC5533 Shim6: Level 3 Multihoming Shim Protocol for IPv6 E. Nordmark M. Bagnulo June 2009 ASCII HTML 124 locator pair

This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table. The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working. [STANDARDS-TRACK]

 draft-ietf-shim6-proto-12 PROPOSED STANDARD PROPOSED STANDARD IETF int shim6 10.17487/RFC5533 RFC5534 Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming J. Arkko I. van Beijnum June 2009 ASCII HTML 36 Shim6 reachability protocol REAP

This document specifies how the level 3 multihoming Shim6 protocol (Shim6) detects failures between two communicating nodes. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same nodes if a failure occurs and an operational pair can be found. [STANDARDS-TRACK]

 draft-ietf-shim6-failure-detection-13 PROPOSED STANDARD PROPOSED STANDARD IETF int shim6 10.17487/RFC5534 RFC5535 Hash-Based Addresses (HBA) M. Bagnulo June 2009 ASCII HTML 25 Shim6 multi-homing cryptographically generated addresses (cgas),

This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. This mechanism employs either Cryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses. The main idea in the new variant is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash-Based Addresses (HBAs), that are inherently bound to each other. [STANDARDS-TRACK]

 draft-ietf-shim6-hba-05 PROPOSED STANDARD PROPOSED STANDARD IETF int shim6 10.17487/RFC5535 RFC5536 Netnews Article Format K. Murchison Editor C. Lindsey D. Kohn November 2009 ASCII HTML 36 Usenet Usefor

This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose Internet Mail Extensions (MIME) (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. [STANDARDS-TRACK]

 draft-ietf-usefor-usefor-12 RFC1036 RFC1849 PROPOSED STANDARD PROPOSED STANDARD IETF app usefor http://www.rfc-editor.org/errata_search.php?rfc=5536 10.17487/RFC5536 RFC5537 Netnews Architecture and Protocols R. Allbery Editor C. Lindsey November 2009 ASCII HTML 48 usefor Usenet netnews

This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. [STANDARDS-TRACK]

 draft-ietf-usefor-usepro-14 RFC1036 RFC1849 RFC8315 PROPOSED STANDARD PROPOSED STANDARD IETF app usefor http://www.rfc-editor.org/errata_search.php?rfc=5537 10.17487/RFC5537 RFC5538 The 'news' and 'nntp' URI Schemes F. Ellermann April 2010 ASCII HTML 14

This memo specifies the 'news' and 'nntp' Uniform Resource Identifier (URI) schemes that were originally defined in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on the Standards Track. [STANDARDS-TRACK]

 draft-ellermann-news-nntp-uri-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5538 10.17487/RFC5538 RFC5539 NETCONF over Transport Layer Security (TLS) M. Badra May 2009 ASCII HTML 7 Authentication TLS RPC

The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. [STANDARDS-TRACK]

 draft-ietf-netconf-tls-07 RFC7589 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC5539 RFC5540 40 Years of RFCs RFC Editor April 2009 ASCII HTML 3

This RFC marks the 40th anniversary of the RFC document series. This memo provides information for the Internet community.

 draft-rfc-editor-40-anniversary-00 RFC8700 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5540 RFC5541 Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) JL. Le Roux JP. Vasseur Y. Lee June 2009 ASCII HTML 23 pcc path computation client

The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g., minimum cost path, widest path, etc.).

In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE.

This document defines extensions to the PCE communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation.

This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests. [STANDARDS-TRACK]

 draft-ietf-pce-of-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC5541 RFC5542 Definitions of Textual Conventions for Pseudowire (PW) Management T. Nadeau Editor D. Zelig Editor O. Nicklass Editor May 2009 ASCII HTML 11 Pseudowire PWE3 MIB PWE3-TC PW-TC

This memo defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used pseudowire (PW) management information. The intent is that these TCs will be imported and used in PW-related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

 draft-ietf-pwe3-pw-tc-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5542 RFC5543 BGP Traffic Engineering Attribute H. Ould-Brahim D. Fedyk Y. Rekhter May 2009 ASCII HTML 6 BGP-TE BGP-TE Attribute Traffic Engineering with BGP Inter-domain Traffic Engineering L1VPN BGP-TE BGP-TE-VPN VPN BGP Traffic Engineering Attribute

This document defines a new BGP attribute, the Traffic Engineering attribute, that enables BGP to carry Traffic Engineering information.

The scope and applicability of this attribute currently excludes its use for non-VPN reachability information. [STANDARDS-TRACK]

 draft-ietf-softwire-bgp-te-attribute-04 RFC7606 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5543 RFC5544 Syntax for Binding Documents with Time-Stamps A. Santoni February 2010 ASCII HTML 13 time-stamp token,

This document describes an envelope that can be used to bind a file (not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where "time-stamp token" has the meaning defined in RFC 3161 or its successors. Additional types of temporal evidence are also allowed.

The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 5652. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-santoni-timestampeddata-06 RFC5955 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5544 10.17487/RFC5544 RFC5545 Internet Calendaring and Scheduling Core Object Specification (iCalendar) B. Desruisseaux Editor September 2009 ASCII HTML 168 calsify calsched calsch caldav calendar calendaring meeting event task to-do journal appointment agenda schedule scheduling ical icalendar itip imip text/calendar ischedule xCalendar

This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK]

 draft-ietf-calsify-rfc2445bis-10 RFC2445 RFC5546 RFC6868 RFC7529 RFC7953 RFC7986 RFC9073 RFC9074 RFC9253 PROPOSED STANDARD PROPOSED STANDARD IETF app calsify http://www.rfc-editor.org/errata_search.php?rfc=5545 10.17487/RFC5545 RFC5546 iCalendar Transport-Independent Interoperability Protocol (iTIP) C. Daboo Editor December 2009 ASCII HTML 133 calendar scheduling

This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.

The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK]

 draft-ietf-calsify-2446bis-10 RFC2446 RFC5545 RFC6638 PROPOSED STANDARD PROPOSED STANDARD IETF app calsify http://www.rfc-editor.org/errata_search.php?rfc=5546 10.17487/RFC5546 RFC5547 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer M. Garcia-Martin M. Isomaki G. Camarillo S. Loreto P. Kyzivat May 2009 ASCII HTML 50 msrp message session relay protocol

This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can describe either the files it wants to send or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. [STANDARDS-TRACK]

 draft-ietf-mmusic-file-transfer-mech-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5547 10.17487/RFC5547 RFC5548 Routing Requirements for Urban Low-Power and Lossy Networks M. Dohler Editor T. Watteyne Editor T. Winter Editor D. Barthel Editor May 2009 ASCII HTML 21 u-lln roll routing over low-power and loss

The application-specific routing requirements for Urban Low-Power and Lossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve people's living conditions as well as to monitor compliance with increasingly strict environmental laws. These field nodes are expected to measure and report a wide gamut of data (for example, the data required by applications that perform smart-metering or that monitor meteorological, pollution, and allergy conditions). The majority of these nodes are expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, low-power IEEE 802.11, or IEEE 802.15.1 (Bluetooth), which given the limited radio range and the large number of nodes requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios. As such, for a wireless solution for Routing Over Low-Power and Lossy (ROLL) networks to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs' tailored characteristics. This memo provides information for the Internet community.

 draft-ietf-roll-urban-routing-reqs-05 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC5548 RFC5549 Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop F. Le Faucheur E. Rosen May 2009 ASCII HTML 10 BGP IPv6 IPv4

Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. [STANDARDS-TRACK]

 draft-ietf-softwire-v4nlri-v6nh-02 RFC8950 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=5549 10.17487/RFC5549 RFC5550 The Internet Email to Support Diverse Service Environments (Lemonade) Profile D. Cridland Editor A. Melnikov Editor S. Maes Editor August 2009 ASCII HTML 41 IMAP Sieve SMTP Lemonade mobile email low-bandwidth efficient

This document describes a profile (a set of required extensions, restrictions, and usage modes), dubbed Lemonade, of the IMAP, mail submission, and Sieve protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.

The Lemonade Profile relies upon several extensions to IMAP, Sieve, and Mail Submission protocols. The document also defines a new IMAP extension and registers several new IMAP keywords. [STANDARDS-TRACK]

 draft-ietf-lemonade-profile-bis-12 RFC4550 RFC4469 RFC4467 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5550 RFC5551 Lemonade Notifications Architecture R. Gellens Editor August 2009 ASCII HTML 12 notification filtering

Notification and filtering mechanisms can make email more enjoyable on mobile and other constrained devices (such as those with limited screen sizes, memory, data transfer rates, etc.). Notifications make the client aware of significant events (such as the arrival of new mail) so it can react (such as by fetching interesting mail immediately). Filtering reduces the visible mail to a set of messages that meet some criteria for "interesting". This functionality is included in the goals of the Lemonade (Enhancements to Internet email to Support Diverse Service Environments) Working Group.

This document also discusses the use of server-to-server notifications, and how server to server notifications fit into an architecture that provides server to client notifications. This memo provides information for the Internet community.

 draft-ietf-lemonade-notifications-10 INFORMATIONAL INFORMATIONAL IETF app lemonade 10.17487/RFC5551 RFC5552 SIP Interface to VoiceXML Media Services D. Burke M. Scott May 2009 ASCII HTML 36 VoiceXML SIP MRF IVR IMS

This document describes a SIP interface to VoiceXML media services. Commonly, Application Servers controlling Media Servers use this protocol for pure VoiceXML processing capabilities. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism. [STANDARDS-TRACK]

 draft-ietf-mediactrl-vxml-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl http://www.rfc-editor.org/errata_search.php?rfc=5552 10.17487/RFC5552 RFC5553 Resource Reservation Protocol (RSVP) Extensions for Path Key Support A. Farrel Editor R. Bradford JP. Vasseur May 2009 ASCII HTML 14 pks path key subobject ero explicit route object rro record route object

The paths taken by Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path.

To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) and embedding this subobject within the result of its path computation.

This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Objects (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. [STANDARDS-TRACK]

 draft-ietf-ccamp-path-key-ero-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5553 RFC5554 Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings N. Williams May 2009 ASCII HTML 4 GSS GSS-API channel binding and C-bindings

This document clarifies and generalizes the Generic Security Service Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. [STANDARDS-TRACK]

 draft-ietf-kitten-gssapi-channel-bindings-07 RFC2743 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5554 RFC5555 Mobile IPv6 Support for Dual Stack Hosts and Routers H. Soliman Editor June 2009 ASCII HTML 41 nemo mipv6 ipv4

The current Mobile IPv6 and Network Mobility (NEMO) specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the mobile node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. [STANDARDS-TRACK]

 draft-ietf-mext-nemo-v4traversal-10 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=5555 10.17487/RFC5555 RFC5556 Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement J. Touch R. Perlman May 2009 ASCII HTML 17 spanning tree protocol ieee 802.1

Current IEEE 802.1 LANs use spanning tree protocols that have a number of challenges. These protocols need to strictly avoid loops, even temporary ones, during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non-overlapping pairwise paths (in the case of spanning trees). This document addresses these concerns and suggests applying modern network-layer routing protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing IEEE 802.1 bridged links, but that a solution would be backward compatible with 802.1, including hubs, bridges, and their existing plug-and-play capabilities. This memo provides information for the Internet community.

 draft-ietf-trill-prob-06 INFORMATIONAL INFORMATIONAL IETF int trill http://www.rfc-editor.org/errata_search.php?rfc=5556 10.17487/RFC5556 RFC5557 Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization Y. Lee JL. Le Roux D. King E. Oki July 2009 ASCII HTML 26 pcc path communication client pce gco global concurrent optimization nms network management system

The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution.

This document provides application-specific requirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK]

 draft-ietf-pce-global-concurrent-optimization-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5557 10.17487/RFC5557 RFC5558 Virtual Enterprise Traversal (VET) F. Templin Editor February 2010 ASCII HTML 36 Enterprise MANET Encapsulation Tunneling Autoconfiguration Subnetwork Provider-Independent Provider-Aggregated

Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet. Enterprise network nodes require a means to automatically provision IP addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-templin-autoconf-dhcp-38 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5558 RFC5559 Pre-Congestion Notification (PCN) Architecture P. Eardley Editor June 2009 ASCII HTML 54 Quality of Service QoS Congestion Control Differentiated Services Admission Control Termination

This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established, inelastic flows within a single Diffserv domain. This memo provides information for the Internet community.

 draft-ietf-pcn-architecture-11 INFORMATIONAL INFORMATIONAL IETF tsv pcn http://www.rfc-editor.org/errata_search.php?rfc=5559 10.17487/RFC5559 RFC5560 A One-Way Packet Duplication Metric H. Uijterwaal May 2009 ASCII HTML 14 performance metrics packet duplication unidirectional

When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive.

In earlier work, a metric for packet loss was defined. This metric quantifies the case where a packet that is sent does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams. [STANDARDS-TRACK]

 draft-ietf-ippm-duplicate-08 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC5560 RFC5561 LDP Capabilities B. Thomas K. Raza S. Aggarwal R. Aggarwal JL. Le Roux July 2009 ASCII HTML 12 MPLS LDP Capabilities

A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements after LDP session establishment. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-capabilities-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5561 RFC5562 Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets A. Kuzmanovic A. Mondal S. Floyd K. Ramakrishnan June 2009 ASCII HTML 33 ecn-capable

The proposal in this document is Experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of Explicit Congestion Notification (ECN) in TCP SYN/ACK packets.

This document describes an optional, experimental modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 specifies setting an ECN-Capable codepoint on data packets, but not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document describes the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN-marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-tcpm-ecnsyn-10 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC5562 RFC5563 WiMAX Forum / 3GPP2 Proxy Mobile IPv4 K. Leung G. Dommety P. Yegani K. Chowdhury February 2010 ASCII HTML 41 mipv4 pmipv4

Mobile IPv4 is a standard mobility protocol that enables an IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-leung-mip4-proxy-mode-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5563 RFC5564 Linguistic Guidelines for the Use of the Arabic Language in Internet Domains A. El-Sherbiny M. Farah I. Oueichek A. Al-Zoman February 2010 ASCII HTML 11 arabic domain names

This document constitutes technical specifications for the use of Arabic in Internet domain names and provides linguistic guidelines for Arabic domain names. It addresses Arabic-specific linguistic issues pertaining to the use of Arabic language in domain names. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-farah-adntf-ling-guidelines-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5564 RFC5565 Softwire Mesh Framework J. Wu Y. Cui C. Metz E. Rosen June 2009 ASCII HTML 31

The Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single-protocol" networks. One kind of single-protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology. [STANDARDS-TRACK]

 draft-ietf-softwire-mesh-framework-06 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5565 RFC5566 BGP IPsec Tunnel Encapsulation Attribute L. Berger R. White E. Rosen June 2009 ASCII HTML 8 border gateway protocol safi subsequent address family identifier

The BGP Encapsulation Subsequent Address Family Identifier (SAFI) provides a method for the dynamic exchange of encapsulation information and for the indication of encapsulation protocol types to be used for different next hops. Currently, support for Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TPv3), and IP in IP tunnel types are defined. This document defines support for IPsec tunnel types. [STANDARDS-TRACK]

 draft-ietf-softwire-encaps-ipsec-03 RFC9012 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5566 RFC5567 An Architectural Framework for Media Server Control T. Melanchuk Editor June 2009 ASCII HTML 25

This document describes an architectural framework for Media Server control. The primary focus will be to define logical entities that exist within the context of Media Server control, and define the appropriate naming conventions and interactions between them. This memo provides information for the Internet community.

 draft-ietf-mediactrl-architecture-04 INFORMATIONAL INFORMATIONAL IETF rai mediactrl 10.17487/RFC5567 RFC5568 Mobile IPv6 Fast Handovers R. Koodli Editor July 2009 ASCII HTML 51 mpiv6 handover latency

Mobile IPv6 enables a mobile node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the mobile node is unable to send or receive packets because of link-switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures (namely, movement detection, new Care-of Address configuration, and Binding Update) is often unacceptable to real-time traffic such as Voice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link-switching latency.

This document updates the packet formats for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages to the Mobility Header Type. [STANDARDS-TRACK]

 draft-ietf-mipshop-rfc5268bis-01 RFC5268 RFC7411 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=5568 10.17487/RFC5568 RFC5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) R. Despres January 2010 ASCII HTML 10 IPv6 IPv4 migration transition 6to4 6rd

IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-despres-6rd-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5569 10.17487/RFC5569 RFC5570 Common Architecture Label IPv6 Security Option (CALIPSO) M. StJohns R. Atkinson G. Thomas July 2009 ASCII HTML 52 sensitivity labels mls multi-level secure

This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy. This memo provides information for the Internet community.

 draft-stjohns-sipso-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5570 10.17487/RFC5570 RFC5571 Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2) B. Storer C. Pignataro Editor M. Dos Santos B. Stevant Editor L. Toutain J. Tremblay June 2009 ASCII HTML 41 Softwire L2TP Softwire Hub and Spoke Softwire HnS 4over6 6over4 L2TP softwires L2TPv2 softwires

This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer Two Tunneling Protocol version 2 (L2TPv2). The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. [STANDARDS-TRACK]

 draft-ietf-softwire-hs-framework-l2tpv2-13 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5571 RFC5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) M. Blanchet F. Parent February 2010 ASCII HTML 32 IPv6 Tunnel Transition TSP

A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6, or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP within the model of the tunnel broker model. This document defines an Experimental Protocol for the Internet community.

 draft-blanchet-v6ops-tunnelbroker-tsp-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5572 10.17487/RFC5572 RFC5573 Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP) M. Thomson June 2009 ASCII HTML 8 asynchronous beep channels

The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes a BEEP feature that enables asynchrony for individual channels. This memo defines an Experimental Protocol for the Internet community.

 draft-thomson-beep-async-02 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5573 RFC5574 RTP Payload Format for the Speex Codec G. Herlein J. Valin A. Heggestad A. Moizard June 2009 ASCII HTML 14 Voip SDP audio CELLP Xiph.Org

Speex is an open-source voice codec suitable for use in VoIP (Voice over IP) type applications. This document describes the payload format for Speex-generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP). [STANDARDS-TRACK]

 draft-ietf-avt-rtp-speex-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5574 RFC5575 Dissemination of Flow Specification Rules P. Marques N. Sheth R. Raszuk B. Greene J. Mauch D. McPherson August 2009 ASCII HTML 22 IDR Inter-domain routing BGP DDOS Denial of Service ACL Firewall Filter

This document defines a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.

Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.

The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. [STANDARDS-TRACK]

 draft-ietf-idr-flow-spec-09 RFC8955 RFC7674 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5575 10.17487/RFC5575 RFC5576 Source-Specific Media Attributes in the Session Description Protocol (SDP) J. Lennox J. Ott T. Schierl June 2009 ASCII HTML 18 real-time transport protocol rtp synchronization source ssrc fid flow identification fec forward error correction

The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-source-attributes-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5576 RFC5577 RTP Payload Format for ITU-T Recommendation G.722.1 P. Luthi R. Even July 2009 ASCII HTML 11 international telecommunication union wide-band audio coded

International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1-generated bit streams within an RTP packet. The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support G.722.1 audio codec. [STANDARDS-TRACK]

 draft-ietf-avt-rfc3047-bis-09 RFC3047 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5577 10.17487/RFC5577 RFC5578 PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics B. Berry Editor S. Ratliff E. Paradise T. Kaiser M. Adams February 2010 ASCII HTML 24 point-to-point protocol over ethernet link quality metric

This document extends the Point-to-Point Protocol over Ethernet (PPPoE) with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-bberry-rfc4938bis-00 RFC4938 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5578 10.17487/RFC5578 RFC5579 Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces F. Templin Editor February 2010 ASCII HTML 9 ISATAP Tunnel Encapsulation Map-and-Encaps IPv4 IPv6

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-templin-isatapv4-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5579 RFC5580 Carrying Location Objects in RADIUS and Diameter H. Tschofenig Editor F. Adrangi M. Jones A. Lior B. Aboba August 2009 ASCII HTML 53 remote authentication dial-in user service location information

This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service (RADIUS) and Diameter.

The distribution of location information is a privacy-sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed in this document. [STANDARDS-TRACK]

 draft-ietf-geopriv-radius-lo-24 RFC8559 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5580 10.17487/RFC5580 RFC5581 The Camellia Cipher in OpenPGP D. Shaw June 2009 ASCII HTML 3 PGP GPG GnuPG Encryption Symmetric

This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol. This memo provides information for the Internet community.

 draft-ietf-openpgp-camellia-04 RFC4880 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5581 RFC5582 Location-to-URL Mapping Architecture and Framework H. Schulzrinne September 2009 ASCII HTML 17 ECRIT Mapping LoST Emergency calling

This document describes an architecture for a global, scalable, resilient, and administratively distributed system for mapping geographic location information to URLs, using the Location-to-Service Translation (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. This memo provides information for the Internet community.

 draft-ietf-ecrit-mapping-arch-04 INFORMATIONAL INFORMATIONAL IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5582 10.17487/RFC5582 RFC5583 Signaling Media Decoding Dependency in the Session Description Protocol (SDP) T. Schierl S. Wenger July 2009 ASCII HTML 18 media coding ddp decoding dependency

This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process.

A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). [STANDARDS-TRACK]

 draft-ietf-mmusic-decoding-dependency-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5583 10.17487/RFC5583 RFC5584 RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family M. Hatanaka J. Matsumoto July 2009 ASCII HTML 30 RTP audio fragmentation layered coding multiplexed multi-session multi-channel redundancy scalable ATRAC ATRAC3 ATRAC-X ATRAC Advanced Lossless AAL Sony Corporation

This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high-quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-atrac-family-24 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5584 10.17487/RFC5584 RFC5585 DomainKeys Identified Mail (DKIM) Service Overview T. Hansen D. Crocker P. Hallam-Baker July 2009 ASCII HTML 24 Email Electroni Mail Internet Mail Message Verification

This document provides an overview of the DomainKeys Identified Mail (DKIM) service and describes how it can fit into a messaging service. It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public-key cryptography, with the domain name service as its key server technology (RFC 4871). This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This memo provides information for the Internet community.

 draft-ietf-dkim-overview-12 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC5585 RFC5586 MPLS Generic Associated Channel M. Bocci Editor M. Vigoureux Editor S. Bryant Editor June 2009 ASCII HTML 19 mpls-tp oam g-ach ach associated channel header gal generic associated label

This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.

 draft-ietf-mpls-tp-gach-gal-06 RFC3032 RFC4385 RFC5085 RFC6423 RFC7026 RFC7214 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5586 10.17487/RFC5586 RFC5587 Extended Generic Security Service Mechanism Inquiry APIs N. Williams July 2009 ASCII HTML 16 GSS-API mechanism inquiry extension

This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications.

These interfaces include mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that possess given attributes, and a function for displaying mechanism attributes. [STANDARDS-TRACK]

 draft-ietf-kitten-extended-mech-inquiry-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5587 RFC5588 Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials N. Williams July 2009 ASCII HTML 7 GSS-API credential gss_store_cred

This document defines a new function for the Generic Security Service Application Program Interface (GSS-API), which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. [STANDARDS-TRACK]

 draft-ietf-kitten-gssapi-store-cred-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5588 RFC5589 Session Initiation Protocol (SIP) Call Control - Transfer R. Sparks A. Johnston Editor D. Petrie June 2009 ASCII HTML 58 REFER GRUU Attended Transfer Target-Dialog Out of Dialog REFER SIP SIP Services blind transfer SIP Features Replaces Referred-By

This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-sipping-cc-transfer-12 BCP0149 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5589 10.17487/RFC5589 RFC5590 Transport Subsystem for the Simple Network Management Protocol (SNMP) D. Harrington J. Schoenwaelder June 2009 ASCII HTML 34 Network Management Simple Network Management Protocol SNMP SNMP-TRANSPORT-MIB

This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models that is comparable to other subsystems in the RFC 3411 architecture. As work is being done to expand the transports to include secure transports, such as the Secure Shell (SSH) Protocol and Transport Layer Security (TLS), using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. [STANDARDS-TRACK]

 draft-ietf-isms-tmsm-18 RFC3411 RFC3412 RFC3414 RFC3417 STD0078 INTERNET STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC5590 RFC5591 Transport Security Model for the Simple Network Management Protocol (SNMP) D. Harrington W. Hardaker June 2009 ASCII HTML 28 Network Management Simple Network Management Protocol SNMP Transport Security Model Security Model

This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP).

This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. [STANDARDS-TRACK]

 draft-ietf-isms-transport-security-model-14 STD0078 INTERNET STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC5591 RFC5592 Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) D. Harrington J. Salowey W. Hardaker June 2009 ASCII HTML 36 Network Management Simple Network Management Protocol SNMP Secure Shell SSH

This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol.

This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. [STANDARDS-TRACK]

 draft-ietf-isms-secshell-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC5592 RFC5593 Internet Message Access Protocol (IMAP) - URL Access Identifier Extension N. Cook June 2009 ASCII HTML 10 urlauth imap url

The existing IMAP URL specification (RFC 5092) lists several <access> identifiers and <access> identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new <access> identifiers as well as an IANA mechanism to register new <access> identifiers for future applications.

This document updates RFC 5092. [STANDARDS-TRACK]

 draft-ncook-urlauth-accessid-02 RFC5092 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5593 RFC5594 Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008 J. Peterson A. Cooper July 2009 ASCII HTML 28 P2PI

This document reports the outcome of a workshop organized by the Real-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased Peer-to-Peer (P2P) traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Gaining an understanding of where in the IETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community. This memo provides information for the Internet community.

 draft-p2pi-cooper-workshop-report-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5594 RFC5595 The Datagram Congestion Control Protocol (DCCP) Service Codes G. Fairhurst September 2009 ASCII HTML 19 DCCP-Request Ports

This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of a Service Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls). This document updates the specification provided in RFC 4340. [STANDARDS-TRACK]

 draft-ietf-dccp-serv-codes-11 RFC4340 RFC6335 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=5595 10.17487/RFC5595 RFC5596 Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal G. Fairhurst September 2009 ASCII HTML 25 DCCP NAT traversal Middlebox Issues

This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g., a Network Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. [STANDARDS-TRACK]

 draft-ietf-dccp-simul-open-08 RFC4340 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC5596 RFC5597 Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol R. Denis-Courmont September 2009 ASCII HTML 9 dccp

This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements for NATs, which have already been published by the IETF. Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-behave-dccp-05 BCP0150 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC5597 RFC5598 Internet Mail Architecture D. Crocker July 2009 ASCII PDF HTML 54 email e-mail service mime architecture mta mua msa mda admd user originator recipient transfer message transfer deliver delivery relay header gateway agent gateway actor gateway sieve dsn mdn tussle mhs Message handling service message transfer agent message user agent mail submission agent mail delivery agent administrative management domain

Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community.

 draft-crocker-email-arch-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5598 10.17487/RFC5598 RFC5599 RFC5600 RFC5601 Pseudowire (PW) Management Information Base (MIB) T. Nadeau Editor D. Zelig Editor July 2009 ASCII HTML 67 pseudowire edge-to-edge services IANA-PWE3-MIB PW-STD-MIB

This memo defines a Standards Track portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a general Packet Switched Network. [STANDARDS-TRACK]

 draft-ietf-pwe3-pw-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5601 10.17487/RFC5601 RFC5602 Pseudowire (PW) over MPLS PSN Management Information Base (MIB) D. Zelig Editor T. Nadeau Editor July 2009 ASCII HTML 31 pw operation PW-MPLS-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for PW operation over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). [STANDARDS-TRACK]

 draft-ietf-pwe3-pw-mpls-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5602 RFC5603 Ethernet Pseudowire (PW) Management Information Base (MIB) D. Zelig Editor T. Nadeau Editor July 2009 ASCII HTML 23 ethernet pw PW-ENET-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet pseudowire (PW) services. [STANDARDS-TRACK]

 draft-ietf-pwe3-enet-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5603 RFC5604 Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs) O. Nicklass July 2009 ASCII HTML 41 mib management information base pseudowire encapsulation t1 e1 t3 e3

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudowire encapsulation for structured or unstructured Time-Division Multiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet Switched Network (PSN). [STANDARDS-TRACK]

 draft-ietf-pwe3-tdm-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5604 RFC5605 Managed Objects for ATM over Packet Switched Networks (PSNs) O. Nicklass T. Nadeau July 2009 ASCII HTML 36 mib management information base atm pseudowire

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switched Networks (PSNs). [STANDARDS-TRACK]

 draft-ietf-pwe3-pw-atm-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5605 RFC5606 Implications of 'retransmission-allowed' for SIP Location Conveyance J. Peterson T. Hardie J. Morris August 2009 ASCII HTML 11 pidf-lo presence information data format for location objects

This document explores an ambiguity in the interpretation of the <retransmission-allowed> element of the Presence Information Data Format for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to this ambiguity.

Documents standardizing the SIP location conveyance mechanisms will be Standards-Track documents processed according to the usual SIP process. This document is intended primarily to provide the SIP working group with a statement of the consensus of the GEOPRIV working group on this topic. It secondarily provides tutorial information on the problem space for the general reader. This memo provides information for the Internet community.

 draft-ietf-geopriv-sip-lo-retransmission-02 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC5606 RFC5607 Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management D. Nelson G. Weber July 2009 ASCII HTML 25 Network Management Device Management Simple Network Management Protocol SNMP Network Configuration Protocol NETCONF Access Control

This document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for authorizing management access to a Network Access Server (NAS). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via Framed Management protocols and for management access over a secure transport protocol. [STANDARDS-TRACK]

 draft-ietf-radext-management-authorization-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC5607 RFC5608 Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models K. Narayan D. Nelson August 2009 ASCII HTML 14 authorization service ssh transport model secure shell transport model

This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell (SSH) Transport Model. [STANDARDS-TRACK]

 draft-ietf-isms-radius-usage-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms http://www.rfc-editor.org/errata_search.php?rfc=5608 10.17487/RFC5608 RFC5609 State Machines for the Protocol for Carrying Authentication for Network Access (PANA) V. Fajardo Editor Y. Ohba R. Marin-Lopez August 2009 ASCII HTML 30 PANA State Machine EAP

This document defines the conceptual state machines for the Protocol for Carrying Authentication for Network Access (PANA). The state machines consist of the PANA Client (PaC) state machine and the PANA Authentication Agent (PAA) state machine. The two state machines show how PANA can interface with the Extensible Authentication Protocol (EAP) state machines. The state machines and associated models are informative only. Implementations may achieve the same results using different methods. This memo provides information for the Internet community.

 draft-ietf-pana-statemachine-12 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC5609 RFC5610 Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements E. Boschi B. Trammell L. Mark T. Zseby July 2009 ASCII HTML 20 enterprise-specific Information Element IPFIX Template type record type options template

This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. [STANDARDS-TRACK]

 draft-ietf-ipfix-exporting-type-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5610 10.17487/RFC5610 RFC5611 Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires A. Vainshtein S. Galtzur August 2009 ASCII HTML 11 l2tpv3 layer tow tunneling protocol version 3 structure-agnostic structure-aware cesopsn tdmoip

This document defines extensions to the Layer Two Tunneling Protocol version 3 (L2TPv3) for support of structure-agnostic and structure-aware (Circuit Emulation Service over Packet Switched Network (CESoPSN) style) Time-Division Multiplexing (TDM) pseudowires. Support of structure-aware (Time-Division Multiplexing over IP (TDMoIP) style) pseudowires over L2TPv3 is left for further study. [STANDARDS-TRACK]

 draft-ietf-l2tpext-tdm-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC5611 RFC5612 Enterprise Number for Documentation Use P. Eronen D. Harrington August 2009 ASCII HTML 4 smi network management private enterprise code

This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation. This memo provides information for the Internet community.

 draft-eronen-enterprise-number-documentation-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5612 RFC5613 OSPF Link-Local Signaling A. Zinin A. Roy L. Nguyen B. Friedman D. Yeung August 2009 ASCII HTML 12 open shortest path first intra-domain routing

OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well-defined fixed format. The format is not flexible enough to enable new features that need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track.

 draft-ietf-ospf-lls-08 RFC4813 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5613 RFC5614 Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding R. Ogier P. Spagnolo August 2009 ASCII HTML 71 MANET routing link-state routing CDS flooding mesh network MANET Designated Router MDR

This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-ospf-manet-mdr-05 RFC7038 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC5614 RFC5615 H.248/MEGACO Registration Procedures C. Groves Y. Lin August 2009 ASCII HTML 14 Package Error Code ServiceChange Reason Profile

This document updates the H.248/MEGACO IANA Package registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-groves-megaco-pkgereg-04 BCP0151 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5615 RFC5616 Streaming Internet Messaging Attachments N. Cook August 2009 ASCII HTML 28 IMAP SIP streaming stream email multimedia lemonade attachments video audio

This document describes a method for streaming multimedia attachments received by a resource- and/or network-constrained device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio email content.

The document describes a profile for making use of the URLAUTH- authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022). This memo provides information for the Internet community.

 draft-ietf-lemonade-streaming-13 INFORMATIONAL INFORMATIONAL IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5616 10.17487/RFC5616 RFC5617 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) E. Allman J. Fenton M. Delany J. Levine August 2009 ASCII HTML 21 email e-mail rfc 5322 rfc 5322 rfc 822 rfc 822 rfc 5321 rfc 5321 rfc 821 rfc 821 rfc 4871 rfc 4871 DKIM domain keys domainkeys ADSP ADSP SSP architecture mta user delivery smtp submission email e-mail smtp Internet mailfrom mail from author return address sender signing signing practices

DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record. [STANDARDS-TRACK]

 draft-ietf-dkim-ssp-10 RFC8553 HISTORIC PROPOSED STANDARD IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=5617 10.17487/RFC5617 RFC5618 Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP) A. Morton K. Hedayat August 2009 ASCII HTML 8 twamp-control protocol twamp-test protocol twamp modes

This memo describes a simple extension to TWAMP (the Two-Way Active Measurement Protocol). The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously. The memo also describes a new IANA registry for additional features, called the TWAMP Modes registry. [STANDARDS-TRACK]

 draft-ietf-ippm-more-twamp-02 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC5618 RFC5619 Softwire Security Analysis and Requirements S. Yamamoto C. Williams H. Yokota F. Parent August 2009 ASCII HTML 28 IPv6 Tunnel Softwire Transition

This document describes security guidelines for the softwire "Hubs and Spokes" and "Mesh" solutions. Together with discussion of the softwire deployment scenarios, the vulnerability to security attacks is analyzed to provide security protection mechanisms such as authentication, integrity, and confidentiality to the softwire control and data packets. [STANDARDS-TRACK]

 draft-ietf-softwire-security-requirements-09 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5619 RFC5620 RFC Editor Model (Version 1) O. Kolkman Editor IAB August 2009 ASCII HTML 19 RFC Series Editor Independent Stream Editor

The RFC Editor performs a number of functions that may be carried out by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent Submission Editor, the RFC Production Center, and the RFC Publisher. It also introduces the RFC Series Advisory Group and an (optional) Independent Submission Stream Editorial Board. The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality and timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency. This memo provides information for the Internet community.

 draft-iab-rfc-editor-model-07 RFC6548 RFC6635 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5620 RFC5621 Message Body Handling in the Session Initiation Protocol (SIP) G. Camarillo September 2009 ASCII HTML 19 Message body MIME SIP

This document specifies how message bodies are handled in SIP. Additionally, this document specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies. [STANDARDS-TRACK]

 draft-ietf-sip-body-handling-06 RFC3204 RFC3261 RFC3459 RFC8262 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5621 RFC5622 Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) S. Floyd E. Kohler August 2009 ASCII HTML 19 ccid 4 congestion control identifier 4

This document specifies a profile for Congestion Control Identifier 4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and uses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send small packets. CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time. The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion. CCID 4 is for use for senders that send small packets and would like a TCP- friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-dccp-ccid4-05 RFC6323 RFC8311 EXPERIMENTAL EXPERIMENTAL IETF tsv dccp 10.17487/RFC5622 RFC5623 Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering E. Oki T. Takeda JL. Le Roux A. Farrel September 2009 ASCII HTML 34 MPLS GMPLS Traffic Engineering Label Switched Path Virtual Network Topology

A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering.

This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). This memo provides information for the Internet community.

 draft-ietf-pce-inter-layer-frwk-10 INFORMATIONAL INFORMATIONAL IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5623 10.17487/RFC5623 RFC5624 Quality of Service Parameters for Usage with Diameter J. Korhonen Editor H. Tschofenig E. Davies August 2009 ASCII HTML 12 Diameter QoS Parameters

This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter.

The defined QoS information includes data traffic parameters for describing a token bucket filter, a bandwidth parameter, and a per-hop behavior class object. [STANDARDS-TRACK]

 draft-ietf-dime-qos-parameters-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5624 RFC5625 DNS Proxy Implementation Guidelines R. Bellis August 2009 ASCII HTML 12 DNS Proxy

This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-dnsext-dnsproxy-06 BCP0152 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC5625 RFC5626 Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) C. Jennings Editor R. Mahy Editor F. Audet Editor October 2009 ASCII HTML 50

The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar. [STANDARDS-TRACK]

 draft-ietf-sip-outbound-20 RFC3261 RFC3327 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5626 RFC5627 Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP) J. Rosenberg October 2009 ASCII HTML 40 SIP NAT outbound gruu registration traversal

Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. [STANDARDS-TRACK]

 draft-ietf-sip-gruu-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5627 10.17487/RFC5627 RFC5628 Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs) P. Kyzivat October 2009 ASCII HTML 14 registration

RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact.

However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI (GRUU), defined in RFC 5627, is a URI that is capable of reaching a particular contact. However this URI is not included in the document format defined in RFC 3680. This specification defines an extension to the registration event package to include GRUUs assigned by the registrar. [STANDARDS-TRACK]

 draft-ietf-sipping-gruu-reg-event-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=5628 10.17487/RFC5628 RFC5629 A Framework for Application Interaction in the Session Initiation Protocol (SIP) J. Rosenberg October 2009 ASCII HTML 38 sip dtmf

This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications. By interacting with applications, users can guide the way in which they operate. The focus of this framework is stimulus signaling, which allows a user agent (UA) to interact with an application without knowledge of the semantics of that application. Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual-Tone Multi- Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework. [STANDARDS-TRACK]

 draft-ietf-sipping-app-interaction-framework-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5629 RFC5630 The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) F. Audet October 2009 ASCII HTML 56 SIPS SIP TLS

This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. [STANDARDS-TRACK]

 draft-ietf-sip-sips-09 RFC3261 RFC3608 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5630 RFC5631 Session Initiation Protocol (SIP) Session Mobility R. Shacham H. Schulzrinne S. Thakolsri W. Kellerer October 2009 ASCII HTML 35 third party call control (3pcc) transfer voice over ip (voip)

Session mobility is the transfer of media of an ongoing communication session from one device to another. This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP). Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example. This document is an informational document. This memo provides information for the Internet community.

 draft-shacham-sipping-session-mobility-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5631 RFC5632 Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial C. Griffiths J. Livingood L. Popkin R. Woundy Y. Yang September 2009 ASCII HTML 12 ISP Internet Service Provider P2P Peer-to-Peer P4P Proactive Network Provider Partication for P2P DCIA Distributed Computing Industry Association

This document describes the experiences of Comcast, a large cable broadband Internet Service Provider (ISP) in the U.S., in a Proactive Network Provider Participation for P2P (P4P) technical trial in July 2008. This trial used P4P iTracker technology, which is being considered by the IETF as part of the Application Layer Transport Optimization (ALTO) working group. This memo provides information for the Internet community.

 draft-livingood-woundy-p4p-experiences-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5632 10.17487/RFC5632 RFC5633 Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers S. Dawkins Editor August 2009 ASCII HTML 5 Internet Architecture Board Engineering Steering Group

This document updates RFC 3777, Section 4, Bullet 13 to allow announcement of open positions and solicitation of volunteers to be issued before a Nominating and Recall Committee Chair has been named by the Internet Society President. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-dawkins-nomcom-dont-wait-04 RFC7437 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5633 RFC5634 Quick-Start for the Datagram Congestion Control Protocol (DCCP) G. Fairhurst A. Sathiaseelan August 2009 ASCII HTML 22 ccid congestion control identifier ccid 2 ccid 3 ccid 4

This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and online games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID 3, and CCID 4. Quick-Start enables a DCCP sender to cooperate with Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-dccp-quickstart-05 EXPERIMENTAL EXPERIMENTAL IETF tsv dccp 10.17487/RFC5634 RFC5635 Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) W. Kumari D. McPherson August 2009 ASCII HTML 15 rtbh

Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks. This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well. This memo provides information for the Internet community.

 draft-ietf-opsec-blackhole-urpf-04 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC5635 RFC5636 Traceable Anonymous Certificate S. Park H. Park Y. Won J. Lee S. Kent August 2009 ASCII HTML 31 x.509 certificate blind issuer anonymity issuer tacs end entity ee

This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request formats such as PKCS10 (RFC 2986) and CMC (RFC 5272). The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymity Issuer). The end entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs). This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-pkix-tac-04 EXPERIMENTAL EXPERIMENTAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5636 10.17487/RFC5636 RFC5637 Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6 G. Giaretta I. Guardini E. Demaria J. Bournelle R. Lopez September 2009 ASCII HTML 11 AAA MIPv6 Mobile IP

In commercial and enterprise deployments, Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case, all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the Authentication, Authorization, and Accounting (AAA) infrastructure (e.g., Network Access Server and AAA server) also offers a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface. This memo provides information for the Internet community.

 draft-ietf-mext-aaa-ha-goals-01 INFORMATIONAL INFORMATIONAL IETF int mext 10.17487/RFC5637 RFC5638 Simple SIP Usage Scenario for Applications in the Endpoints H. Sinnreich Editor A. Johnston E. Shim K. Singh September 2009 ASCII HTML 19 session initiation protocol rich internet application ria

For Internet-centric usage, the number of SIP-required standards for presence and IM and audio/video communications can be drastically smaller than what has been published by using only the rendezvous and session-initiation capabilities of SIP. The simplification is achieved by avoiding the emulation of telephony and its model of the intelligent network. 'Simple SIP' relies on powerful computing endpoints. Simple SIP desktop applications can be combined with rich Internet applications (RIAs). Significant telephony features may also be implemented in the endpoints.

This approach for SIP reduces the number of SIP standards with which to comply -- from roughly 100 currently, and still growing, to about 11.

References for NAT traversal and for security are also provided. This memo provides information for the Internet community.

 draft-sinnreich-sip-tools-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5638 RFC5639 Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation M. Lochter J. Merkle March 2010 ASCII HTML 27

This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-lochter-pkix-brainpool-ecc-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5639 10.17487/RFC5639 RFC5640 Load-Balancing for Mesh Softwires C. Filsfils P. Mohapatra C. Pignataro August 2009 ASCII HTML 6 bgp encapsulation subsequent address family identifier safi

Payloads transported over a Softwire mesh service (as defined by BGP Encapsulation Subsequent Address Family Identifier (SAFI) information exchange) often carry a number of identifiable, distinct flows. It can, in some circumstances, be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering the Softwire can only be interpreted by the ingress and egress routers. Thus, the load-balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load-balancing efficiency in a network carrying Softwire mesh service over Layer Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic Routing Encapsulation (GRE) encapsulation to what would be achieved without such encapsulation. [STANDARDS-TRACK]

 draft-ietf-softwire-lb-03 RFC9012 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5640 RFC5641 Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values N. McGill C. Pignataro August 2009 ASCII HTML 11 attachment circuits acs pseudowires pw active bit new bit circuit status avp

This document defines additional Layer 2 Tunneling Protocol Version 3 (L2TPv3) bit values to be used within the "Circuit Status" Attribute Value Pair (AVP) to communicate finer-grained error states for Attachment Circuits (ACs) and pseudowires (PWs). It also generalizes the Active bit and deprecates the use of the New bit in the Circuit Status AVP, updating RFC 3931, RFC 4349, RFC 4454, RFC 4591, and RFC 4719. [STANDARDS-TRACK]

 draft-ietf-l2tpext-circuit-status-extensions-05 RFC3931 RFC4349 RFC4454 RFC4591 RFC4719 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC5641 RFC5642 Dynamic Hostname Exchange Mechanism for OSPF S. Venkata S. Harwani C. Pignataro D. McPherson August 2009 ASCII HTML 8 open shortest path first router information ri ospf dynamic hostname

This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood their hostname-to-Router-ID mapping information across an OSPF network to provide a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames, just like for routers running IS-IS. This mechanism is applicable to both OSPFv2 and OSPFv3. [STANDARDS-TRACK]

 draft-ietf-ospf-dynamic-hostname-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5642 RFC5643 Management Information Base for OSPFv3 D. Joyal Editor V. Manral Editor August 2009 ASCII HTML 95 mib ipv6 open shortest path first routing protocol OSPFV3-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). [STANDARDS-TRACK]

 draft-ietf-ospf-ospfv3-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5643 10.17487/RFC5643 RFC5644 IP Performance Metrics (IPPM): Spatial and Multicast E. Stephan L. Liang A. Morton October 2009 ASCII HTML 57 Multiple point measurement relative performance group performance statistic per hop measurement segment performance

The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points. This memo defines two new categories of metrics that extend the coverage to multiple measurement points. It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). [STANDARDS-TRACK]

 draft-ietf-ippm-multimetrics-12 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=5644 10.17487/RFC5644 RFC5645 Update to the Language Subtag Registry D. Ewell Editor September 2009 ASCII HTML 13 language tags language tagging ltru registry

This memo defines the procedure used to update the IANA Language Subtag Registry, in conjunction with the publication of RFC 5646, for use in forming tags for identifying languages. This memo provides information for the Internet community.

 draft-ietf-ltru-4645bis-10 INFORMATIONAL INFORMATIONAL IETF app ltru 10.17487/RFC5645 RFC5646 Tags for Identifying Languages A. Phillips Editor M. Davis Editor September 2009 ASCII HTML 84 language tags private interchange

This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-ietf-ltru-4646bis-23 RFC4646 BCP0047 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ltru http://www.rfc-editor.org/errata_search.php?rfc=5646 10.17487/RFC5646 RFC5647 AES Galois Counter Mode for the Secure Shell Transport Layer Protocol K. Igoe J. Solinas August 2009 ASCII HTML 10 ssh remote-login

Secure shell (SSH) is a secure remote-login protocol. SSH provides for algorithms that provide authentication, key agreement, confidentiality, and data-integrity services. The purpose of this document is to show how the AES Galois Counter Mode can be used to provide both confidentiality and data integrity to the SSH Transport Layer Protocol. This memo provides information for the Internet community.

 draft-igoe-secsh-aes-gcm-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5647 RFC5648 Multiple Care-of Addresses Registration R. Wakikawa Editor V. Devarapalli G. Tsirtsis T. Ernst K. Nagami October 2009 ASCII HTML 36

According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by mobile routers using the NEMO (Network Mobility) Basic Support protocol as well. [STANDARDS-TRACK]

 draft-ietf-monami6-multiplecoa-14 RFC6089 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=5648 10.17487/RFC5648 RFC5649 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm R. Housley M. Dworkin September 2009 ASCII HTML 13

This document specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped be a multiple of 64 bits, allowing a key of any practical length to be wrapped. This memo provides information for the Internet community.

 draft-housley-aes-key-wrap-with-pad-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5649 10.17487/RFC5649 RFC5650 Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) M. Morgenstern S. Baillie U. Bonollo September 2009 ASCII HTML 218 mib management information base adsl asymmetric digital subscriber line VDSL2-LINE-TC-MIB VDSL2-LINE-MIB

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing Asymmetric Digital Subscriber Line (ADSL), ADSL2, and ADSL2+ interfaces. [STANDARDS-TRACK]

 draft-ietf-adslmib-vdsl2-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC5650 RFC5651 Layered Coding Transport (LCT) Building Block M. Luby M. Watson L. Vicisano October 2009 ASCII HTML 34 FEC reliable multicast

The Layered Coding Transport (LCT) Building Block provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but it also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This document obsoletes RFC 3451. [STANDARDS-TRACK]

 draft-ietf-rmt-bb-lct-revised-11 RFC3451 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=5651 10.17487/RFC5651 RFC5652 Cryptographic Message Syntax (CMS) R. Housley September 2009 ASCII HTML 56 digital signature message content

This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]

 draft-ietf-smime-rfc3852bis-00 RFC3852 RFC8933 STD0070 INTERNET STANDARD DRAFT STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5652 10.17487/RFC5652 RFC5653 Generic Security Service API Version 2: Java Bindings Update M. Upadhyay S. Malkani August 2009 ASCII HTML 99 gssapi application program interface gss-api GSI

The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2 : Java Bindings" (RFC 2853). This document obsoletes RFC 2853 by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience.

The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121). [STANDARDS-TRACK]

 draft-ietf-kitten-rfc2853bis-05 RFC2853 RFC8353 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5653 RFC5654 Requirements of an MPLS Transport Profile B. Niven-Jenkins Editor D. Brungard Editor M. Betts Editor N. Sprecher S. Ueno September 2009 ASCII HTML 31 MPLS-TP ITU ITU-T

This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T).

This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T.

The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-requirements-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5654 10.17487/RFC5654 RFC5655 Specification of the IP Flow Information Export (IPFIX) File Format B. Trammell E. Boschi L. Mark T. Zseby A. Wagner October 2009 ASCII HTML 64 flow file flow storage ipfix storage netflow storage

This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. [STANDARDS TRACK]

 draft-ietf-ipfix-file-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5655 10.17487/RFC5655 RFC5656 Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer D. Stebila J. Green December 2009 ASCII HTML 20 Key Agreement Cryptography

This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. [STANDARDS-TRACK]

 draft-green-secsh-ecc-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5656 10.17487/RFC5656 RFC5657 Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard L. Dusseault R. Sparks September 2009 ASCII HTML 12 rfc2026 2026 guidance interoperation implementation reports advancement draft standard

Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-dusseault-impl-reports-04 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5657 10.17487/RFC5657 RFC5658 Addressing Record-Route Issues in the Session Initiation Protocol (SIP) T. Froment C. Lebel B. Bonnaerens October 2009 ASCII HTML 18 multi-homed user agent proxy interoperability double record-routing

A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog-creating requests in order to make subsequent, in-dialog requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) or SIPS (secure SIP) URI indicating where and how the subsequent requests should be sent to reach the proxy. These SIP or SIPS URIs can contain IPv4 or IPv6 addresses and URI parameters that could influence the routing such as the transport parameter (for example, transport=tcp), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, or IPv4 to IPv6 scenarios, etc.), the question arises on what should be put in Record-Route header(s). It is not possible to make one header have the characteristics of both interfaces at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC 3261 text, which describes only a Record-Route rewriting solution. [STANDARDS-TRACK]

 draft-ietf-sip-record-route-fix-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5658 RFC5659 An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge M. Bocci S. Bryant October 2009 ASCII HTML 24 psn packet switched network

This document describes an architecture for extending pseudowire emulation across multiple packet switched network (PSN) segments. Scenarios are discussed where each segment of a given edge-to-edge emulated service spans a different provider's PSN, as are other scenarios where the emulated service originates and terminates on the same provider's PSN, but may pass through several PSN tunnel segments in that PSN. It presents an architectural framework for such multi-segment pseudowires, defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community.

 draft-ietf-pwe3-ms-pw-arch-07 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5659 10.17487/RFC5659 RFC5660 IPsec Channels: Connection Latching N. Williams October 2009 ASCII HTML 31 IPsec connection latching channel

This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.

Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes.

Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. [STANDARDS-TRACK]

 draft-ietf-btns-connection-latching-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec btns http://www.rfc-editor.org/errata_search.php?rfc=5660 10.17487/RFC5660 RFC5661 Network File System (NFS) Version 4 Minor Version 1 Protocol S. Shepler Editor M. Eisler Editor D. Noveck Editor January 2010 ASCII HTML 617 Access Control List ACL Communications Sessions Exactly Once Semantics File Access Protocol Global Namespace Network Authentication Network File Access Network File System Network Security NFS Parallel Storage pNFS Storage Cluster

This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version 1 include Sessions, Directory Delegations, and parallel NFS (pNFS). NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol. Thus, this document neither updates nor obsoletes RFC 3530. NFS minor version 1 is deemed superior to NFS minor version 0 with no loss of functionality, and its use is preferred over version 0. Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server. [STANDARDS-TRACK]

 draft-ietf-nfsv4-minorversion1-29 RFC8881 RFC8178 RFC8434 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5661 10.17487/RFC5661 RFC5662 Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description S. Shepler Editor M. Eisler Editor D. Noveck Editor January 2010 ASCII HTML 73 xdr nfsv4

This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. [STANDARDS-TRACK]

 draft-ietf-nfsv4-minorversion1-dot-x-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5662 RFC5663 Parallel NFS (pNFS) Block/Volume Layout D. Black S. Fridella J. Glasgow January 2010 ASCII HTML 28 nfsv4 network file sharing version 4

Parallel NFS (pNFS) extends Network File Sharing version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations document specifies storage-class-independent extensions to NFS; this document specifies the additional extensions (primarily data structures) for use of pNFS with block- and volume-based storage. [STANDARDS-TRACK]

 draft-ietf-nfsv4-pnfs-block-12 RFC6688 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5663 10.17487/RFC5663 RFC5664 Object-Based Parallel NFS (pNFS) Operations B. Halevy B. Welch J. Zelenka January 2010 ASCII HTML 35 OSD storage device

Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout- type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-Based pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification. [STANDARDS-TRACK]

 draft-ietf-nfsv4-pnfs-obj-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5664 10.17487/RFC5664 RFC5665 IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats M. Eisler January 2010 ASCII HTML 14 rpcbind portmap transport independent remote procedure call TI-RPC transport identifier protocol identifier

This document lists IANA Considerations for Remote Procedure Call (RPC) Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This document updates, but does not replace, RFC 1833. [STANDARDS-TRACK]

 draft-ietf-nfsv4-rpc-netid-06 RFC1833 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5665 10.17487/RFC5665 RFC5666 Remote Direct Memory Access Transport for Remote Procedure Call T. Talpey B. Callaghan January 2010 ASCII HTML 34 Network File System NFS ONC RPC RDMA RDDP iWARP InfiniBand

This document describes a protocol providing Remote Direct Memory Access (RDMA) as a new transport for Remote Procedure Call (RPC). The RDMA transport binding conveys the benefits of efficient, bulk-data transport over high-speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. [STANDARDS-TRACK]

 draft-ietf-nfsv4-rpcrdma-09 RFC8166 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5666 RFC5667 Network File System (NFS) Direct Data Placement T. Talpey B. Callaghan January 2010 ASCII HTML 10 Network File System NFS ONC RPC RDMA RDDP iWARP InfiniBand

This document defines the bindings of the various Network File System (NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol. It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2, 3, 4, and 4.1 over such an RDMA transport. [STANDARDS-TRACK]

 draft-ietf-nfsv4-nfsdirect-08 RFC8267 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5667 RFC5668 4-Octet AS Specific BGP Extended Community Y. Rekhter S. Sangli D. Tappan October 2009 ASCII HTML 5 border gateway protocol autonomous system

This document defines a new type of a BGP extended community, which carries a 4-octet Autonomous System (AS) number. [STANDARDS-TRACK]

 draft-ietf-l3vpn-as4octet-ext-community-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC5668 RFC5669 The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) S. Yoon J. Kim H. Park H. Jeong Y. Won August 2010 ASCII HTML 13

This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]

 draft-ietf-avt-seed-srtp-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5669 RFC5670 Metering and Marking Behaviour of PCN-Nodes P. Eardley Editor November 2009 ASCII HTML 20 pre-congestion notification threshold metering threshold marking pcn-threshold-rate pcn-excess-rate

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion. This document defines the two metering and marking behaviours of PCN-nodes. Threshold-metering and -marking marks all PCN-packets if the rate of PCN-traffic is greater than a configured rate ("PCN-threshold-rate"). Excess- traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the rate of PCN-traffic in excess of a configured rate ("PCN-excess-rate"). The level of marking allows PCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows. [STANDARDS-TRACK]

 draft-ietf-pcn-marking-behaviour-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pcn http://www.rfc-editor.org/errata_search.php?rfc=5670 10.17487/RFC5670 RFC5671 Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) S. Yasukawa A. Farrel Editor October 2009 ASCII HTML 15 multiprotocol label switching generalized mpls

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs).

This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths and examines which of the PCE architectural models are appropriate. This memo provides information for the Internet community.

 draft-ietf-pce-p2mp-app-02 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5671 RFC5672 RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update D. Crocker Editor August 2009 ASCII HTML 14 DKIM email authentication security spam abuse errata trust Signing Domain Identifier SDID AUID Agent or User Identifier

This document updates RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures". Specifically, the document clarifies the nature, roles, and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module. The Update is in the style of an Errata entry, albeit a rather long one. [STANDARDS-TRACK]

 draft-ietf-dkim-rfc4871-errata-07 RFC6376 RFC4871 PROPOSED STANDARD PROPOSED STANDARD IETF sec dkim 10.17487/RFC5672 RFC5673 Industrial Routing Requirements in Low-Power and Lossy Networks K. Pister Editor P. Thubert Editor S. Dwars T. Phinney October 2009 ASCII HTML 27 lln

The wide deployment of lower-cost wireless devices will significantly improve the productivity and safety of industrial plants while increasing the efficiency of plant workers by extending the information set available about the plant operations. The aim of this document is to analyze the functional requirements for a routing protocol used in industrial Low-power and Lossy Networks (LLNs) of field devices. This memo provides information for the Internet community.

 draft-ietf-roll-indus-routing-reqs-06 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC5673 RFC5674 Alarms in Syslog S. Chisholm R. Gerhards October 2009 ASCII HTML 7 SYSLOG alarm

This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields. It also includes a number of alarm-specific SD-PARAM definitions from X.733 and the IETF Alarm MIB. [STANDARDS-TRACK]

 draft-ietf-opsawg-syslog-alarm-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC5674 RFC5675 Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages V. Marinov J. Schoenwaelder October 2009 ASCII HTML 15 Network Management Simple Network Management Protocol SNMP Notifications Syslog

This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG messages. [STANDARDS-TRACK]

 draft-ietf-opsawg-syslog-snmp-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC5675 RFC5676 Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications J. Schoenwaelder A. Clemm A. Karmakar October 2009 ASCII HTML 22 Network Management Simple Network Management Protocol SNMP Notifications Syslog

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. [STANDARDS-TRACK]

 draft-ietf-opsawg-syslog-msg-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=5676 10.17487/RFC5676 RFC5677 IEEE 802.21 Mobility Services Framework Design (MSFD) T. Melia Editor G. Bajko S. Das N. Golmie JC. Zuniga December 2009 ASCII HTML 25 media independent handover mih mobility services mos

This document describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages. The document also describes mechanisms for Mobility Services (MoS) discovery and transport-layer mechanisms for the reliable delivery of MIH messages. This document does not provide mechanisms for securing the communication between a mobile node (MN) and the Mobility Server. Instead, it is assumed that either lower-layer (e.g., link-layer) security mechanisms or overall system-specific proprietary security solutions are used. [STANDARDS-TRACK]

 draft-ietf-mipshop-mstp-solution-12 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=5677 10.17487/RFC5677 RFC5678 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery G. Bajko S. Das December 2009 ASCII HTML 14 handover preparation handover decision media independent handover services

This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of IP addresses and a list of domain names that can be mapped to servers providing IEEE 802.21 type of Mobility Service (MoS) (see RFC 5677). These Mobility Services are used to assist a mobile node (MN) in handover preparation (network discovery) and handover decision (network selection). The services addressed in this document are the Media Independent Handover Services defined in IEEE 802.21. [STANDARDS-TRACK]

 draft-ietf-mipshop-mos-dhcp-options-14 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5678 RFC5679 Locating IEEE 802.21 Mobility Services Using DNS G. Bajko December 2009 ASCII HTML 9 domain name server handover preparation handover decision media independent handover services

This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers that provide IEEE 802.21-defined Mobility Services. Such Mobility Services are used to assist a Mobile Node (MN) supporting IEEE 802.21, in handover preparation (network discovery) and handover decision (network selection). The services addressed by this document are the Media Independent Handover Services defined in IEEE 802.21. [STANDARDS-TRACK]

 draft-ietf-mipshop-mos-dns-discovery-07 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5679 RFC5680 The Nominating Committee Process: Open Disclosure of Willing Nominees S. Dawkins Editor October 2009 ASCII HTML 7

This document updates RFC 3777, Section 3, Bullet 6 to allow a Nominating and Recall Committee to disclose the list of nominees who are willing to be considered to serve in positions the committee is responsible for filling. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

 draft-dawkins-nomcom-openlist-06 RFC7437 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5680 RFC5681 TCP Congestion Control M. Allman V. Paxson E. Blanton September 2009 ASCII HTML 18 slow start congestion avoidance fast retransmit fast recovery

This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]

 draft-ietf-tcpm-rfc2581bis-07 RFC2581 DRAFT STANDARD DRAFT STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=5681 10.17487/RFC5681 RFC5682 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP P. Sarolahti M. Kojo K. Yamamoto M. Hata September 2009 ASCII HTML 19 SACK transmission control protocol loss recovery

The purpose of this document is to move the F-RTO (Forward RTO-Recovery) functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F-RTO support for Stream Control Transmission Protocol (SCTP) in RFC 4138 remains with Experimental status. See Appendix B for the differences between this document and RFC 4138.

Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. [STANDARDS-TRACK]

 draft-ietf-tcpm-rfc4138bis-04 RFC4138 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC5682 RFC5683 Password-Authenticated Key (PAK) Diffie-Hellman Exchange A. Brusilovsky I. Faynberg Z. Zeltsan S. Patel February 2010 ASCII HTML 10

This document proposes to add mutual authentication, based on a human-memorizable password, to the basic, unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called the Password-Authenticated Key (PAK) exchange. PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange.

The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attacker to obtain any information that would enable an offline dictionary attack on the password. PAK provides Forward Secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-brusilovsky-pak-10 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5683 10.17487/RFC5683 RFC5684 Unintended Consequences of NAT Deployments with Overlapping Address Space P. Srisuresh B. Ford February 2010 ASCII HTML 26 network address translator

This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator (NAT) devices. First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces. Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide-spread use of Virtual Private Networks (VPNs) to access an enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. This document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ford-behave-top-07 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5684 10.17487/RFC5684 RFC5685 Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) V. Devarapalli K. Weniger November 2009 ASCII HTML 15 IKEv2 Redirect REDIRECT REDIRECTED_FROM anycast redirect home agent redirect VPN gateway direct

The Internet Key Exchange Protocol version 2 (IKEv2) is a protocol for setting up Virtual Private Network (VPN) tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. This document defines an IKEv2 extension that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. [STANDARDS-TRACK]

 draft-ietf-ipsecme-ikev2-redirect-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5685 RFC5686 RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec Y. Hiwasaki H. Ohmuro October 2009 ASCII HTML 21 RTP Payload type MIME UEMCLIP PCMU Speech Coding

This document describes the RTP payload format of a mU-law EMbedded Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-uemclip-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5686 RFC5687 GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements H. Tschofenig H. Schulzrinne March 2010 ASCII HTML 21 Location Information Location Information Server Location by Value Location by Reference

This document provides a problem statement, lists requirements, and captures design aspects for a GEOPRIV Layer 7 (L7) Location Configuration Protocol (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation (LoST) Protocol or to convey location within the Session Initiation Protocol (SIP) to other entities. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-geopriv-l7-lcp-ps-10 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC5687 RFC5688 A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes J. Rosenberg January 2010 ASCII HTML 7 SIP IMS

The caller preferences specification for the Session Initiation Protocol (SIP) allows a caller to express preferences that the call be routed to a User Agent (UA) with particular capabilities. Similarly, a specification exists to allow a UA to indicate its capabilities in a registration. Amongst those capabilities are the type of media streams the agent supports, described as top-level MIME types. The 'application' MIME type is used to describe a broad range of stream types, and it provides insufficient granularity as a capability. This specification allows a UA to indicate which application subtypes the agent supports. [STANDARDS-TRACK]

 draft-rosenberg-sip-app-media-tag-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5688 10.17487/RFC5688 RFC5689 Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) C. Daboo September 2009 ASCII HTML 12 webdav HTTP

This specification extends the Web Distributed Authoring and Versioning (WebDAV) MKCOL (Make Collection) method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. [STANDARDS-TRACK]

 draft-ietf-vcarddav-webdav-mkcol-06 RFC4791 RFC4918 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav 10.17487/RFC5689 RFC5690 Adding Acknowledgement Congestion Control to TCP S. Floyd A. Arcia D. Ros J. Iyengar February 2010 ASCII HTML 33 ackcc

This document describes a possible congestion control mechanism for acknowledgement (ACKs) traffic in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts: the TCP data sender and the TCP data receiver. The TCP data sender detects lost or Explicit Congestion Notification (ECN)-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in the Datagram Congestion Control Protocol's (DCCP's) Congestion Control Identifier (CCID) 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-floyd-tcpm-ackcc-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5690 RFC5691 RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio F. de Bont S. Doehla M. Schmidt R. Sperschneider October 2009 ASCII HTML 12 MPEG Surround RFC 3640 RTP MPEG-4 AAC

This memo describes extensions for the RTP payload format defined in RFC 3640 for the transport of MPEG Surround multi-channel audio. Additional Media Type parameters are defined to signal backwards- compatible transmission inside an MPEG-4 Audio elementary stream. In addition, a layered transmission scheme that doesn't use the MPEG-4 systems framework is presented to transport an MPEG Surround elementary stream via RTP in parallel with an RTP stream containing the downmixed audio data. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-mps-03 RFC3640 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5691 RFC5692 Transmission of IP over Ethernet over IEEE 802.16 Networks H. Jeon S. Jeong M. Riegel October 2009 ASCII HTML 21 Bridge WiMAX Ethernet-CS Cellular

This document describes the transmission of IPv4 over Ethernet, as well as IPv6 over Ethernet, in an access network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging connections that IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 Media Access Control (MAC) functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP-specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. [STANDARDS-TRACK]

 draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-12 PROPOSED STANDARD PROPOSED STANDARD IETF int 16ng 10.17487/RFC5692 RFC5693 Application-Layer Traffic Optimization (ALTO) Problem Statement J. Seedorf E. Burger October 2009 ASCII HTML 14 peer-to-peer p2p

Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources. Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology. Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data. Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices.

This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection. This memo provides information for the Internet community.

 draft-ietf-alto-problem-statement-04 INFORMATIONAL INFORMATIONAL IETF app alto 10.17487/RFC5693 RFC5694 Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability G. Camarillo Editor IAB November 2009 ASCII HTML 26 P2P decentralized architecture

In this document, we provide a survey of P2P (Peer-to-Peer) systems. The survey includes a definition and several taxonomies of P2P systems. This survey also includes a description of which types of applications can be built with P2P technologies and examples of P2P applications that are currently in use on the Internet. Finally, we discuss architectural trade-offs and provide guidelines for deciding whether or not a P2P architecture would be suitable to meet the requirements of a given application. This memo provides information for the Internet community.

 draft-iab-p2p-archs-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=5694 10.17487/RFC5694 RFC5695 MPLS Forwarding Benchmarking Methodology for IP Flows A. Akhter R. Asati C. Pignataro November 2009 ASCII HTML 27 multiprotocol label switching mpmls forwarding devices

This document describes a methodology specific to the benchmarking of Multiprotocol Label Switching (MPLS) forwarding devices, limited to the most common MPLS packet forwarding scenarios and delay measurements for each, considering IP flows. It builds upon the tenets set forth in RFC 2544, RFC 1242, and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. This memo provides information for the Internet community.

 draft-ietf-bmwg-mpls-forwarding-meth-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg http://www.rfc-editor.org/errata_search.php?rfc=5695 10.17487/RFC5695 RFC5696 Baseline Encoding and Transport of Pre-Congestion Information T. Moncaster B. Briscoe M. Menth November 2009 ASCII HTML 15 Quality of Service QoS Differentiated Services Admission Control Codepoint Protocol

The objective of the Pre-Congestion Notification (PCN) architecture is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. It achieves this by marking packets belonging to PCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains. The baseline encoding described here provides only two PCN encoding states: Not-marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity. [STANDARDS-TRACK]

 draft-ietf-pcn-baseline-encoding-07 RFC6660 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pcn http://www.rfc-editor.org/errata_search.php?rfc=5696 10.17487/RFC5696 RFC5697 Other Certificates Extension S. Farrell November 2009 ASCII HTML 8 template

Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates that belong to the same end entity and that can safely be considered equivalent to one another for the purposes of referencing that application-state information. This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit. This memo defines an Experimental Protocol for the Internet community.

 draft-ietf-pkix-other-certs-05 EXPERIMENTAL EXPERIMENTAL IETF sec pkix 10.17487/RFC5697 RFC5698 Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) T. Kunz S. Okunick U. Pordesch November 2009 ASCII HTML 40 long term archive security policy hash algorithm public key algorithm

Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered. This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time, which may be in the past, the present, or the future. [STANDARDS-TRACK]

 draft-ietf-ltans-dssc-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans http://www.rfc-editor.org/errata_search.php?rfc=5698 10.17487/RFC5698 RFC5699 RFC5700 RFC5701 IPv6 Address Specific BGP Extended Community Attribute Y. Rekhter November 2009 ASCII HTML 5 border gateway protocol

Current specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support an IPv6 Address Specific Extended Community. The lack of an IPv6 Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, the IPv6 Address Specific Extended Community, that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. [STANDARDS TRACK]

 draft-ietf-l3vpn-v6-ext-communities-02 RFC7153 RFC7606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC5701 RFC5702 Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC J. Jansen October 2009 ASCII HTML 10 DNSSEC RSA SHA-256 SHA-512

This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (RFC 4033, RFC 4034, and RFC 4035). [STANDARDS TRACK]

 draft-ietf-dnsext-dnssec-rsasha256-14 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=5702 10.17487/RFC5702 RFC5703 Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure T. Hansen C. Daboo October 2009 ASCII HTML 18 Email Electronic Mail Internet Mail Message Filtering

This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. [STANDARDS-TRACK]

 draft-ietf-sieve-mime-loop-09 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5703 10.17487/RFC5703 RFC5704 Uncoordinated Protocol Development Considered Harmful S. Bryant Editor M. Morrow Editor IAB November 2009 ASCII HTML 15 ITU-T MPLS-TP T-MPLS Joint working team JWT

This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.

This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team on MPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETF RFCs.

Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF. This memo provides information for the Internet community.

 draft-iab-mpls-tp-uncoord-harmful-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5704 RFC5705 Keying Material Exporters for Transport Layer Security (TLS) E. Rescorla March 2010 ASCII HTML 7 key establishment

A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK]

 draft-ietf-tls-extractor-07 RFC8446 RFC8447 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5705 10.17487/RFC5705 RFC5706 Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions D. Harrington November 2009 ASCII HTML 35 management operations

New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered. This memo provides information for the Internet community.

 draft-ietf-opsawg-operations-and-management-09 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC5706 RFC5707 Media Server Markup Language (MSML) A. Saleem Y. Xin G. Sharratt February 2010 ASCII HTML 184

The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP media servers. The MSML control interface was initially driven by RadiSys with subsequent significant contributions from Intel, Dialogic, and others in the industry. Clients can use it to define how multimedia sessions interact on a media server and to apply services to individuals or groups of users. MSML can be used, for example, to control media server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as interactive voice response (IVR) dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants using VoiceXMLThis document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-saleem-msml-09 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5707 10.17487/RFC5707 RFC5708 X.509 Key and Signature Encoding for the KeyNote Trust Management System A. Keromytis January 2010 ASCII HTML 6

This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system (RFC 2704). X.509 certificates (RFC 5280) can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication.

In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in RFC 2792). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-keromytis-keynote-x509-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5708 10.17487/RFC5708 RFC5709 OSPFv2 HMAC-SHA Cryptographic Authentication M. Bhatia V. Manral M. Fanto R. White M. Barnes T. Li R. Atkinson October 2009 ASCII HTML 14 open shortest path first nist secure hash standard hashed message authentication code

This document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. [STANDARDS-TRACK]

 draft-ietf-ospf-hmac-sha-07 RFC2328 RFC7474 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5709 10.17487/RFC5709 RFC5710 PathErr Message Triggered MPLS and GMPLS LSP Reroutes L. Berger D. Papadimitriou JP. Vasseur January 2010 ASCII HTML 12 resource reservation protocol rsvp multiprotocol label switching generalized mpls rsvp-te

This document describes how Resource ReserVation Protocol (RSVP) PathErr messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases, including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definitions can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute-application-specific error values. [STANDARDS-TRACK]

 draft-ietf-mpls-gmpls-lsp-reroute-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5710 RFC5711 Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages JP. Vasseur Editor G. Swallow I. Minei January 2010 ASCII HTML 7 rsvp-te

The aim of this document is to describe a common practice with regard to the behavior of nodes that send and receive a Resource Reservation Protocol (RSVP) Traffic Engineering (TE) Path Error messages for a preempted Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP). (For reference to the notion of TE LSP preemption, see RFC 3209.) This document does not define any new protocol extensions. [STANDARDS-TRACK]

 draft-ietf-mpls-3209-patherr-06 RFC3209 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5711 RFC5712 MPLS Traffic Engineering Soft Preemption M. Meyer Editor JP. Vasseur Editor January 2010 ASCII HTML 13 multiprotocol label switching mpls-te te lsp

This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be rerouted. For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities. [STANDARDS-TRACK]

 draft-ietf-mpls-soft-preemption-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5712 RFC5713 Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) H. Moustafa H. Tschofenig S. De Cnodder January 2010 ASCII HTML 18 ANCP security ANCP threats ANCP attacks

The Access Node Control Protocol (ANCP) aims to communicate Quality of Service (QoS)-related, service-related, and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage, and control access equipment, including the ability for the Access Nodes to report information to the NAS.

This present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security, with the aim of deciding which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ancp-security-threats-08 INFORMATIONAL INFORMATIONAL IETF int ancp 10.17487/RFC5713 RFC5714 IP Fast Reroute Framework M. Shand S. Bryant January 2010 ASCII HTML 15 IP Fast Reroute MPLS Fast Reroute Routing Convergence Network Topology loop-free-convergence

This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-rtgwg-ipfrr-framework-13 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC5714 RFC5715 A Framework for Loop-Free Convergence M. Shand S. Bryant January 2010 ASCII HTML 22 IP Fast Reroute MPLS Fast Reroute Routing Convergence Network Topology PLSN not-via Incremental Cost Packet Marking ordered fib ofib

A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.

This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-rtgwg-lf-conv-frmwk-07 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC5715 RFC5716 Requirements for Federated File Systems J. Lentini C. Everhart D. Ellard R. Tewari M. Naik January 2010 ASCII HTML 26 Federated File Systems Federated FA FedFS Fed-FS Federation

This document describes and lists the functional requirements of a federated file system and defines related terms. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-nfsv4-federated-fs-reqts-06 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC5716 RFC5717 Partial Lock Remote Procedure Call (RPC) for NETCONF B. Lengyel M. Bjorklund December 2009 ASCII HTML 23 YANG Network Management

The Network Configuration protocol (NETCONF) defines the lock and unlock Remote Procedure Calls (RPCs), used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. [STANDARDS-TRACK]

 draft-ietf-netconf-partial-lock-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=5717 10.17487/RFC5717 RFC5718 An In-Band Data Communication Network For the MPLS Transport Profile D. Beller A. Farrel January 2010 ASCII HTML 8 MPLS-TP DCN SCN MCN G-Ach GAL

The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices.

The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier-grade packet transport network based on MPLS packet switching technology.

This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management Communication Network (MCN) and a Signaling Communication Network (SCN). Collectively, the MCN and SCN may be referred to as the Data Communication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed for delivery to the management or signaling/routing control plane components on an MPLS-TP node. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-gach-dcn-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5718 RFC5719 Updated IANA Considerations for Diameter Command Code Allocations D. Romascanu H. Tschofenig January 2010 ASCII HTML 5 diameter application diameter commands

The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands.

This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. [STANDARDS-TRACK]

 draft-ietf-dime-diameter-cmd-iana-01 RFC6733 RFC3588 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5719 RFC5720 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) F. Templin February 2010 ASCII HTML 26 enterprise network

RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a Small Office, Home Office (SOHO) network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-templin-ranger-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5720 RFC5721 POP3 Support for UTF-8 R. Gellens C. Newman February 2010 ASCII HTML 13 POP UTF8 mail email internationalization charset

This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-pop-09 RFC6856 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5721 RFC5722 Handling of Overlapping IPv6 Fragments S. Krishnan December 2009 ASCII HTML 6 fragmentation overlapping fragments

The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. [STANDARDS-TRACK]

 draft-ietf-6man-overlap-fragment-03 RFC2460 RFC6946 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=5722 10.17487/RFC5722 RFC5723 Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption Y. Sheffer H. Tschofenig January 2010 ASCII HTML 26 IKE Internet Key Exchange session resumption failover high availability cryptographic ticket cryptographic token stateful resumption stateless resumption

The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency.

To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various endpoints. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment.

In order to avoid the need to re-run the key exchange protocol from scratch, it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA.

A client can reconnect to a gateway from which it was disconnected. The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided. [STANDARDS-TRACK]

 draft-ietf-ipsecme-ikev2-resumption-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5723 RFC5724 URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS) E. Wilde A. Vaha-Sipila January 2010 ASCII HTML 18 GSM SMS URI scheme

This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device. [STANDARDS-TRACK]

 draft-wilde-sms-uri-20 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5724 10.17487/RFC5724 RFC5725 Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) A. Begen D. Hsu M. Lague February 2010 ASCII HTML 9 Loss repair retransmission FEC

This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE report in the Session Description Protocol (SDP). [STANDARDS-TRACK]

 draft-ietf-avt-post-repair-rtcp-xr-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5725 10.17487/RFC5725 RFC5726 Mobile IPv6 Location Privacy Solutions Y. Qiu F. Zhao Editor R. Koodli February 2010 ASCII HTML 48 mobopts

Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-mobopts-location-privacy-solutions-16 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC5726 RFC5727 Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area J. Peterson C. Jennings R. Sparks March 2010 ASCII HTML 14 RAI sipping

This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space. This document obsoletes RFC 3427. This memo documents an Internet Best Current Practice.

 draft-peterson-rai-rfc3427bis-04 RFC3427 RFC3265 RFC3969 RFC7957 BCP0067 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5727 10.17487/RFC5727 RFC5728 The SatLabs Group DVB-RCS MIB S. Combes P. Amundsen M. Lambert H-P. Lexow March 2010 ASCII HTML 95 management information base digital video broadcasting return channel DVB-RCS-MIB

This document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group. It defines a set of MIB objects to characterize the behavior and performance of network-layer entities deploying DVB-RCS. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-combes-ipdvb-mib-rcs-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5728 10.17487/RFC5728 RFC5729 Clarifications on the Routing of Diameter Requests Based on the Username and the Realm J. Korhonen Editor M. Jones L. Morand T. Tsou December 2009 ASCII HTML 11 nai network access identifier decorated multi-realm

This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm, or "Decorated", Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. [STANDARDS-TRACK]

 draft-ietf-dime-nai-routing-04 RFC3588 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5729 RFC5730 Extensible Provisioning Protocol (EPP) S. Hollenbeck August 2009 ASCII HTML 67 shared framework mapping

This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK]

 draft-hollenbeck-rfc4930bis-02 RFC4930 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5730 10.17487/RFC5730 RFC5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping S. Hollenbeck August 2009 ASCII HTML 44 EPP Extensible Provisioning Protocol XML domain domain name

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 4931. [STANDARDS-TRACK]

 draft-hollenbeck-rfc4931bis-01 RFC4931 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5731 10.17487/RFC5731 RFC5732 Extensible Provisioning Protocol (EPP) Host Mapping S. Hollenbeck August 2009 ASCII HTML 29 EPP Extensible Provisioning Protocol XML host

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 4932. [STANDARDS-TRACK]

 draft-hollenbeck-rfc4932bis-01 RFC4932 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP 10.17487/RFC5732 RFC5733 Extensible Provisioning Protocol (EPP) Contact Mapping S. Hollenbeck August 2009 ASCII HTML 41 EPP Extensible Provisioning Protocol XML contact registrant

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933. [STANDARDS-TRACK]

 draft-hollenbeck-rfc4933bis-02 RFC4933 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP 10.17487/RFC5733 RFC5734 Extensible Provisioning Protocol (EPP) Transport over TCP S. Hollenbeck August 2009 ASCII HTML 13 EPP Extensible Provisioning Protocol XML TCP TLS

This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 4934. [STANDARDS-TRACK]

 draft-hollenbeck-rfc4934bis-01 RFC4934 RFC8996 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5734 10.17487/RFC5734 RFC5735 Special Use IPv4 Addresses M. Cotton L. Vegoda January 2010 ASCII HTML 10 internet protocol space assignments

This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. This memo documents an Internet Best Current Practice.

 draft-iana-rfc3330bis-11 RFC3330 RFC6890 RFC6598 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5735 10.17487/RFC5735 RFC5736 IANA IPv4 Special Purpose Address Registry G. Huston M. Cotton L. Vegoda January 2010 ASCII HTML 6

This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iana-special-ipv4-registry-02 RFC6890 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5736 RFC5737 IPv4 Address Blocks Reserved for Documentation J. Arkko M. Cotton L. Vegoda January 2010 ASCII HTML 4 example addresses IPv4

Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents. This document describes the use of these blocks. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iana-ipv4-examples-02 RFC1166 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5737 RFC5738 IMAP Support for UTF-8 P. Resnick C. Newman March 2010 ASCII HTML 15 internet message access protocol imap4rev1

This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-imap-utf8-09 RFC6855 RFC3501 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5738 10.17487/RFC5738 RFC5739 IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) P. Eronen J. Laganier C. Madson February 2010 ASCII HTML 32 remote vpn access vpn gateway virtual link

When Internet Key Exchange Protocol version 2 (IKEv2) is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4 but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link". This document defines an Experimental Protocol for the Internet community.

 draft-ietf-ipsecme-ikev2-ipv6-config-03 EXPERIMENTAL EXPERIMENTAL IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=5739 10.17487/RFC5739 RFC5740 NACK-Oriented Reliable Multicast (NORM) Transport Protocol B. Adamson C. Bormann M. Handley J. Macker November 2009 ASCII HTML 96 multicast reliable multicast transport negative-acknowledgment forward error correction packet erasure coding group communication

This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based (forward error correction) repair and other IETF Reliable Multicast Transport (RMT) building blocks in its design. This document obsoletes RFC 3940. [STANDARDS-TRACK]

 draft-ietf-rmt-pi-norm-revised-14 RFC3940 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=5740 10.17487/RFC5740 RFC5741 RFC Streams, Headers, and Boilerplates L. Daigle Editor O. Kolkman Editor IAB December 2009 ASCII HTML 16

RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-streams-headers-boilerplates-08 RFC7841 RFC2223 RFC4844 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=5741 10.17487/RFC5741 RFC5742 IESG Procedures for Handling of Independent and IRTF Stream Submissions H. Alvestrand R. Housley December 2009 ASCII HTML 9

This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams.

This document updates procedures described in RFC 2026 and RFC 3710. This memo documents an Internet Best Current Practice.

 draft-housley-iesg-rfc3932bis-12 RFC3932 RFC2026 RFC3710 BCP0092 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5742 RFC5743 Definition of an Internet Research Task Force (IRTF) Document Stream A. Falk December 2009 ASCII HTML 9 irtf stream

This memo defines the publication stream for RFCs from the Internet Research Task Force. Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-rfcs-05 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5743 RFC5744 Procedures for Rights Handling in the RFC Independent Submission Stream R. Braden J. Halpern December 2009 ASCII HTML 6 incoming rights outgoing rights ietf trust

This document specifies the procedures by which authors of RFC Independent Submission documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community.

 draft-braden-independent-submission-02 RFC4846 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5744 RFC5745 Procedures for Rights Handling in the RFC IAB Stream A. Malis Editor IAB December 2009 ASCII HTML 6 incoming rights outgoing rights ietf trust

This document specifies the procedures by which authors of RFC IAB stream documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community.

 draft-malis-iab-stream-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5745 RFC5746 Transport Layer Security (TLS) Renegotiation Indication Extension E. Rescorla M. Ray S. Dispensa N. Oskov February 2010 ASCII HTML 15 ssl secure socket layer

Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. [STANDARDS-TRACK]

 draft-ietf-tls-renegotiation-03 RFC5246 RFC4366 RFC4347 RFC4346 RFC2246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC5746 RFC5747 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions J. Wu Y. Cui X. Li M. Xu C. Metz March 2010 ASCII HTML 15 IPv4/IPv6 coexistence CNGI CERNET2 Softwire mesh

The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired. This document describes a mechanism for automatic discovery and creation of IPv4-over-IPv6 tunnels via extensions to multiprotocol BGP. It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels. The mechanisms described in this document have been implemented, tested, and deployed on the large research IPv6 network in China. This document defines an Experimental Protocol for the Internet community.

 draft-wu-softwire-4over6-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC5747 RFC5748 IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY) S. Yoon J. Jeong H. Kim H. Jeong Y. Won August 2010 ASCII HTML 5

This document updates IANA registries to support the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) in Multimedia Internet KEYing (MIKEY). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-seokung-msec-mikey-seed-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5748 10.17487/RFC5748 RFC5749 Distribution of EAP-Based Keys for Handover and Re-Authentication K. Hoeper Editor M. Nakhjiri Y. Ohba Editor March 2010 ASCII HTML 12 security authentication mobility EAP key management key distribution

This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage- specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication, Authorization, and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used. [STANDARDS-TRACK]

 draft-ietf-hokey-key-mgm-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5749 10.17487/RFC5749 RFC5750 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling B. Ramsdell S. Turner January 2010 ASCII HTML 21 encryption certificate multipurpose internet mail extensions secure

This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. [STANDARDS-TRACK]

 draft-ietf-smime-3850bis-11 RFC3850 RFC8550 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC5750 RFC5751 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification B. Ramsdell S. Turner January 2010 ASCII HTML 45 secure multipurpose internet mail extensions encryption

This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. [STANDARDS-TRACK]

 draft-ietf-smime-3851bis-11 RFC3851 RFC8551 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5751 10.17487/RFC5751 RFC5752 Multiple Signatures in Cryptographic Message Syntax (CMS) S. Turner J. Schaad January 2010 ASCII HTML 17 signeddata signerinfo downgrade attacks algorithm migration

Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the \'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo objects while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. [STANDARDS-TRACK]

 draft-ietf-smime-multisig-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5752 10.17487/RFC5752 RFC5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) S. Turner D. Brown January 2010 ASCII HTML 61 public key digital signatures authentication

This document describes how to use Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 4231 for message authentication code standards. This document obsoletes RFC 3278. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-smime-3278bis-09 RFC3278 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5753 10.17487/RFC5753 RFC5754 Using SHA2 Algorithms with Cryptographic Message Syntax S. Turner January 2010 ASCII HTML 10 secure hash algorithm message digest algorithm sha-224 sha-256 sha-384 sha-512 cms dsa digital signature algorithm rsa rivest sharmi adleman ecdsa elliptic curve dsa smimecapabilities

This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK]

 draft-ietf-smime-sha2-11 RFC3370 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5754 10.17487/RFC5754 RFC5755 An Internet Attribute Certificate Profile for Authorization S. Farrell R. Housley S. Turner January 2010 ASCII HTML 50 electronic mail email ipsec www security

This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. [STANDARDS-TRACK]

 draft-ietf-pkix-3281update-05 RFC3281 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5755 10.17487/RFC5755 RFC5756 Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters S. Turner D. Brown K. Yiu R. Housley T. Polk January 2010 ASCII HTML 6 rsa encryption scheme optical asymmetric encryption padding subjectpublickeyinfo

This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. [STANDARDS-TRACK]

 draft-ietf-pkix-rfc4055-update-02 RFC4055 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5756 10.17487/RFC5756 RFC5757 Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey T. Schmidt M. Waehlisch G. Fairhurst February 2010 ASCII HTML 37 PMIPv6 FMIPv6 HMIPv6 SSM ASM MLD Mobile Multicast Routing Hybrid Multicast Wireless Multipoint

This document discusses current mobility extensions to IP-layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and problems for mobile senders using Any Source Multicast and Source-Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual road map for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-mobopts-mmcastv6-ps-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5757 RFC5758 Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Q. Dang S. Santesson K. Moriarty D. Brown T. Polk January 2010 ASCII HTML 8 digital signature algorithm elliptic curve digital signature algorithm pki

This document updates RFC 3279 to specify algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384, or SHA-512 as the hashing algorithm. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). This document also identifies all four SHA2 hash algorithms for use in the Internet X.509 PKI. [STANDARDS-TRACK]

 draft-ietf-pkix-sha2-dsa-ecdsa-10 RFC3279 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5758 10.17487/RFC5758 RFC5759 Suite B Certificate and Certificate Revocation List (CRL) Profile J. Solinas L. Zieglar January 2010 ASCII HTML 11 x.509 v3 certificates x.509 v2 certificate revocation lists crl

This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Suite B Cryptography. The reader is assumed to have familiarity with RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-solinas-suiteb-cert-profile-04 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5759 RFC5760 RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback J. Ott J. Chesterfield E. Schooler February 2010 ASCII HTML 66 real-time transport protocol ssm

This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. [STANDARDS-TRACK]

 draft-ietf-avt-rtcpssm-19 RFC6128 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5760 10.17487/RFC5760 RFC5761 Multiplexing RTP Data and Control Packets on a Single Port C. Perkins M. Westerlund April 2010 ASCII HTML 13

This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-and-rtcp-mux-07 RFC3550 RFC3551 RFC8035 RFC8858 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5761 10.17487/RFC5761 RFC5762 RTP and the Datagram Congestion Control Protocol (DCCP) C. Perkins April 2010 ASCII HTML 16 real-time transport protocol

The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real- time applications can make use of the services provided by DCCP. [STANDARDS-TRACK]

 draft-ietf-dccp-rtp-07 RFC6773 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC5762 RFC5763 Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS) J. Fischl H. Tschofenig E. Rescorla May 2010 ASCII HTML 37 stip session initiation protocol fingerprint attribute dtls handshake

This 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 fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. [STANDARDS-TRACK]

 draft-ietf-sip-dtls-srtp-framework-07 RFC8842 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5763 10.17487/RFC5763 RFC5764 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) D. McGrew E. Rescorla May 2010 ASCII HTML 26 secure rtp control protocol srtcp

This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]

 draft-ietf-avt-dtls-srtp-07 RFC7983 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5764 10.17487/RFC5764 RFC5765 Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications H. Schulzrinne E. Marocco E. Ivov February 2010 ASCII HTML 28 p2p overlay rtc voip

Peer-to-peer (P2P) networks have become popular for certain applications and deployments for a variety of reasons, including fault tolerance, economics, and legal issues. It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P. Such a migration needs to address a new set of P2P-specific security problems. This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication. This document is a product of the P2P Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-p2prg-rtc-security-05 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5765 10.17487/RFC5765 RFC5766 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) R. Mahy P. Matthews J. Rosenberg April 2010 ASCII HTML 67 NAT TURN STUN ICE

If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. [STANDARDS-TRACK]

 draft-ietf-behave-turn-16 RFC8656 RFC8155 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5766 10.17487/RFC5766 RFC5767 User-Agent-Driven Privacy Mechanism for SIP M. Munakata S. Schubert T. Ohba April 2010 ASCII HTML 11 SIP IMS privacy guidelines

This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUUs) and Traversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sip-ua-privacy-08 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC5767 RFC5768 Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP) J. Rosenberg April 2010 ASCII HTML 6 SIP NAT

This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a User Agent (UA) to communicate to its registrar that it supports ICE. The option tag allows a UA to require support for ICE in order for a call to proceed. [STANDARDS-TRACK]

 draft-ietf-sip-ice-option-tag-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5768 RFC5769 Test Vectors for Session Traversal Utilities for NAT (STUN) R. Denis-Courmont April 2010 ASCII HTML 11 STUN test vectors fingerprint

The Session Traversal Utilities for NAT (STUN) protocol defines several STUN attributes. The content of some of these -- FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor). This document provides test vectors for those attributes. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-behave-stun-test-vectors-04 INFORMATIONAL INFORMATIONAL IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5769 10.17487/RFC5769 RFC5770 Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators M. Komu T. Henderson H. Tschofenig J. Melen A. Keranen Editor April 2010 ASCII HTML 34 ICE HIP relay

This document specifies extensions to the Host Identity Protocol (HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulating Encapsulating Security Payload (ESP) packets within the User Datagram Protocol (UDP). This document also defines elements of a procedure for NAT traversal, including the optional use of a HIP relay server. With these extensions HIP is able to work in environments that have NATs and provides a generic NAT traversal solution to higher-layer networking applications. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-nat-traversal-09 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5770 RFC5771 IANA Guidelines for IPv4 Multicast Address Assignments M. Cotton L. Vegoda D. Meyer March 2010 ASCII HTML 11 internet assigned numbers authority protocol parameters

This document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes RFC 3171 and RFC 3138 and updates RFC 2780. This memo documents an Internet Best Current Practice.

 draft-ietf-mboned-rfc3171bis-08 RFC3138 RFC3171 RFC2780 BCP0051 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned http://www.rfc-editor.org/errata_search.php?rfc=5771 10.17487/RFC5771 RFC5772 A Set of Possible Requirements for a Future Routing Architecture A. Doria E. Davies F. Kastenholz February 2010 ASCII HTML 68 Routing Research Group RRG IDR FDR

The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group (RRG) in 2001, with some editorial updates up to 2006. The two sub- groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for the Internet in the future.

The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. This document defines a Historic Document for the Internet community.

 draft-irtf-routing-reqs-11 HISTORIC HISTORIC IRTF 10.17487/RFC5772 RFC5773 Analysis of Inter-Domain Routing Requirements and History E. Davies A. Doria February 2010 ASCII HTML 51 History IRTF Routing Research Group RRG Routing Requirements IDR FDR

This document analyzes the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing. The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to "A Set of Possible Requirements for a Future Routing Architecture" (RFC 5772), which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols. This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. This document defines a Historic Document for the Internet community.

 draft-irtf-routing-history-10 HISTORIC HISTORIC IRTF http://www.rfc-editor.org/errata_search.php?rfc=5773 10.17487/RFC5773 RFC5774 Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition K. Wolf A. Mayrhofer March 2010 ASCII HTML 33

This document provides a guideline for creating civic address considerations documents for individual countries, as required by RFC 4776. Furthermore, this document also creates an IANA Registry referring to such address considerations documents and registers such address considerations for Austria. This memo documents an Internet Best Current Practice.

 draft-ietf-geopriv-civic-address-recommendations-03 RFC4776 BCP0154 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5774 10.17487/RFC5774 RFC5775 Asynchronous Layered Coding (ALC) Protocol Instantiation M. Luby M. Watson L. Vicisano April 2010 ASCII HTML 24 Forward Error Correction FEC Layered Coding Transport LCT Building Block WEBRC reliable +object delivery reliable file delivery broadcast multicast

This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This document obsoletes RFC 3450. [STANDARDS-TRACK]

 draft-ietf-rmt-pi-alc-revised-10 RFC3450 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5775 RFC5776 Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols V. Roca A. Francillon S. Faurite April 2010 ASCII HTML 58 TESLA FLUTE ALC NORM

This document details the Timed Efficient Stream \%Loss-Tolerant Authentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-msec-tesla-for-alc-norm-10 EXPERIMENTAL EXPERIMENTAL IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=5776 10.17487/RFC5776 RFC5777 Traffic Classification and Quality of Service (QoS) Attributes for Diameter J. Korhonen H. Tschofenig M. Arumaithurai M. Jones Editor A. Lior February 2010 ASCII HTML 43 Diameter Qos Attributes Traffic classification Filtering Firewalling

This document defines a number of Diameter attribute-value pairs (AVPs) for traffic classification with actions for filtering and Quality of Service (QoS) treatment. These AVPs can be used in existing and future Diameter applications where permitted by the Augmented Backus-Naur Form (ABNF) specification of the respective Diameter command extension policy. [STANDARDS-TRACK]

 draft-ietf-dime-qos-attributes-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=5777 10.17487/RFC5777 RFC5778 Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction J. Korhonen Editor H. Tschofenig J. Bournelle G. Giaretta M. Nakhjiri February 2010 ASCII HTML 34

Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the home agent and the Diameter server of the Mobile Service Provider. This document specifies the interaction between a Mobile IP home agent and a Diameter server.

This document defines the home agent to the Diameter server communication when the mobile node authenticates using the Internet Key Exchange v2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6- specific parameters and accounting is specified in this document. [STANDARDS-TRACK]

 draft-ietf-dime-mip6-split-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=5778 10.17487/RFC5778 RFC5779 Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server J. Korhonen Editor J. Bournelle K. Chowdhury A. Muhanna U. Meyer February 2010 ASCII HTML 20 aaa authentication authorization and accounting

This specification defines Authentication, Authorization, and Accounting (AAA) interactions between Proxy Mobile IPv6 entities (both Mobile Access Gateway and Local Mobility Anchor) and a AAA server within a Proxy Mobile IPv6 Domain. These AAA interactions are primarily used to download and update mobile node specific policy profile information between Proxy Mobile IPv6 entities and a remote policy store. [STANDARDS-TRACK]

 draft-ietf-dime-pmip6-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5779 RFC5780 NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) D. MacDonald B. Lowekamp May 2010 ASCII HTML 27 NAT type diagnostics

This specification defines an experimental usage of the Session Traversal Utilities for NAT (STUN) Protocol that discovers the presence and current behavior of NATs and firewalls between the STUN client and the STUN server. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-behave-nat-behavior-discovery-08 RFC8553 EXPERIMENTAL EXPERIMENTAL IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5780 10.17487/RFC5780 RFC5781 The rsync URI Scheme S. Weiler D. Ward R. Housley February 2010 ASCII HTML 4 rsyncuri

This document specifies the rsync Uniform Resource Identifier (URI) scheme. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-weiler-rsync-uri-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5781 RFC5782 DNS Blacklists and Whitelists J. Levine February 2010 ASCII HTML 11 mail electronic mail DNS spam blacklist whitelist

The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become the de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS-based blacklists and whitelists, and the protocol used to query them. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-asrg-dnsbl-08 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5782 10.17487/RFC5782 RFC5783 Congestion Control in the RFC Series M. Welzl W. Eddy February 2010 ASCII HTML 28

This document is an informational snapshot taken by the IRTF\'s Internet Congestion Control Research Group (ICCRG) in October 2008. It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status of the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-iccrg-cc-rfcs-07 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5783 10.17487/RFC5783 RFC5784 Sieve Email Filtering: Sieves and Display Directives in XML N. Freed S. Vedam March 2010 ASCII HTML 32 SMTP ESMTP Sieve

This document describes a way to represent Sieve email filtering language scripts in XML. Representing Sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools.

The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently. These elements are represented as specially structured comments in regular Sieve format. [STANDARDS-TRACK]

 draft-freed-sieve-in-xml-07 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5784 10.17487/RFC5784 RFC5785 Defining Well-Known Uniform Resource Identifiers (URIs) M. Nottingham E. Hammer-Lahav April 2010 ASCII HTML 8 well-known locations

This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK]

 draft-nottingham-site-meta-05 RFC8615 RFC2616 RFC2818 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5785 10.17487/RFC5785 RFC5786 Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions R. Aggarwal K. Kompella March 2010 ASCII HTML 7

OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE-enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE-enabled links, and the local address corresponding to the Router ID.

In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) Traffic Engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE.

This document describes procedures that enhance OSPF TE to advertise a router's local addresses. [STANDARDS-TRACK]

 draft-ietf-ospf-te-node-addr-07 RFC3630 RFC6827 RFC8687 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5786 10.17487/RFC5786 RFC5787 OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing D. Papadimitriou March 2010 ASCII HTML 29 itu-t ospfv2 link state routing protocol

The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).

The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks.

The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.

Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-ccamp-gmpls-ason-routing-ospf-09 RFC6827 EXPERIMENTAL EXPERIMENTAL IETF rtg ccamp 10.17487/RFC5787 RFC5788 IMAP4 Keyword Registry A. Melnikov D. Cridland March 2010 ASCII HTML 11 IMAP email tag label keyword

The aim of this document is to establish a new IANA registry for IMAP keywords and to define a procedure for keyword registration, in order to improve interoperability between different IMAP clients. [STANDARDS TRACK]

 draft-melnikov-imap-keywords-10 RFC8621 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5788 RFC5789 PATCH Method for HTTP L. Dusseault J. Snell March 2010 ASCII HTML 10 HTTP PATCH Hypertext Transfer Protocol

Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. [STANDARDS-TRACK]

 draft-dusseault-http-patch-16 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5789 10.17487/RFC5789 RFC5790 Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols H. Liu W. Cao H. Asaeda February 2010 ASCII HTML 17 IGMP MLD Lite lightweight

This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. [STANDARDS-TRACK]

 draft-ietf-mboned-lightweight-igmpv3-mldv2-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC5790 RFC5791 RFC 2731 ("Encoding Dublin Core Metadata in HTML") Is Obsolete J. Reschke J. Kunze February 2010 ASCII HTML 2 DCMI Dublin Core Metadata Initiative XHTML HTML metadata

This document obsoletes RFC 2731, "Encoding Dublin Core Metadata in HTML", as further development of this specification has moved to the Dublin Core Metadata Initiative (DCMI). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-reschke-rfc2731bis-05 RFC2731 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5791 10.17487/RFC5791 RFC5792 PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) P. Sangster K. Narayan March 2010 ASCII HTML 83

This document specifies PA-TNC, a Posture Attribute protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]

 draft-ietf-nea-pa-tnc-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea http://www.rfc-editor.org/errata_search.php?rfc=5792 10.17487/RFC5792 RFC5793 PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC) R. Sahita S. Hanna R. Hurst K. Narayan March 2010 ASCII HTML 76 NEA Network Endpoint Assessment

This document specifies PB-TNC, a Posture Broker protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]

 draft-ietf-nea-pb-tnc-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea http://www.rfc-editor.org/errata_search.php?rfc=5793 10.17487/RFC5793 RFC5794 A Description of the ARIA Encryption Algorithm J. Lee J. Lee J. Kim D. Kwon C. Kim March 2010 ASCII HTML 18 ARIA encryption block cipher

This document describes the ARIA encryption algorithm. ARIA is a 128-bit block cipher with 128-, 192-, and 256-bit keys. The algorithm consists of a key scheduling part and data randomizing part. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-nsri-aria-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5794 10.17487/RFC5794 RFC5795 The RObust Header Compression (ROHC) Framework K. Sandlund G. Pelletier L-E. Jonsson March 2010 ASCII HTML 41

The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.

The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.

This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. [STANDARDS-TRACK]

 draft-ietf-rohc-rfc4995bis-03 RFC4995 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5795 10.17487/RFC5795 RFC5796 Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages W. Atwood S. Islam M. Siami March 2010 ASCII HTML 21 security PIM-SM routing security multicast routing link-local message Protocol Independent Multicast Sparse Mode

RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, optional support for an automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601. [STANDARDS-TRACK]

 draft-ietf-pim-sm-linklocal-10 RFC4601 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC5796 RFC5797 FTP Command and Extension Registry J. Klensin A. Hoenes March 2010 ASCII HTML 10 FTP FEAT command FTP FEAT response

Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959. RFC 2389 established a mechanism for specifying and negotiating FTP extensions. The number of extensions, both those supported by the mechanism and some that are not, continues to increase. An IANA registry of FTP Command and Feature names is established to reduce the likelihood of conflict of names and the consequent ambiguity. This specification establishes that registry. [STANDARDS-TRACK]

 draft-klensin-ftp-registry-04 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5797 10.17487/RFC5797 RFC5798 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 S. Nadas Editor March 2010 ASCII HTML 40

This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. [STANDARDS-TRACK]

 draft-ietf-vrrp-unified-spec-05 RFC3768 PROPOSED STANDARD PROPOSED STANDARD IETF rtg vrrp http://www.rfc-editor.org/errata_search.php?rfc=5798 10.17487/RFC5798 RFC5799 RFC5800 RFC5801 Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family S. Josefsson N. Williams July 2010 ASCII HTML 26

This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/ GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding and mutual authentication are supported. [STANDARDS-TRACK]

 draft-ietf-sasl-gs2-20 RFC9266 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=5801 10.17487/RFC5801 RFC5802 Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms C. Newman A. Menon-Sen A. Melnikov N. Williams July 2010 ASCII HTML 28 simple authentication and security layer

The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use.

This specification describes a family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. [STANDARDS-TRACK]

 draft-ietf-sasl-scram-11 RFC7677 RFC9266 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=5802 10.17487/RFC5802 RFC5803 Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets A. Melnikov July 2010 ASCII HTML 4 authpassword simple authentication and security layer sasl

This memo describes how the "authPassword" Lightweight Directory Access Protocol (LDAP) attribute can be used for storing secrets used by the Salted Challenge Response Authentication Message (SCRAM) mechanism in the Simple Authentication and Security Layer (SASL) framework. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-melnikov-sasl-scram-ldap-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5803 10.17487/RFC5803 RFC5804 A Protocol for Remotely Managing Sieve Scripts A. Melnikov Editor T. Martin July 2010 ASCII HTML 49 managesieve

Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. [STANDARDS TRACK]

 draft-ietf-sieve-managesieve-09 RFC7817 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5804 10.17487/RFC5804 RFC5805 Lightweight Directory Access Protocol (LDAP) Transactions K. Zeilenga March 2010 ASCII HTML 11 acid atomic consistency isolation durability

Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. It is often desirable to update two or more entries in a single unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions. This document defines an Experimental Protocol for the Internet community.

 draft-zeilenga-ldap-txn-15 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5805 10.17487/RFC5805 RFC5806 Diversion Indication in SIP S. Levy M. Mohali Editor March 2010 ASCII HTML 53

This RFC, which contains the text of an Internet Draft that was submitted originally to the SIP Working Group, is being published now for the historical record and to provide a reference for later Informational RFCs. The original Abstract follows.

This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent.

This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies that receive diversion information may use this as supplemental information for feature invocation decisions. This document defines a Historic Document for the Internet community.

 draft-levy-sip-diversion-11 HISTORIC HISTORIC INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5806 10.17487/RFC5806 RFC5807 Definition of Master Key between PANA Client and Enforcement Point Y. Ohba A. Yegin March 2010 ASCII HTML 7 protocol for carrying authentication for network access

This document defines a master key used between a client of the Protocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering. The master key is derived from the Master Session Key of the Extensible Authentication Protocol as a result of successful PANA authentication. The master key guarantees cryptographic independence among enforcement points bootstrapped from PANA authentication across different address families. [STANDARDS-TRACK]

 draft-ohba-pana-pemk-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5807 RFC5808 Requirements for a Location-by-Reference Mechanism R. Marshall Editor May 2010 ASCII HTML 14

This document defines terminology and provides requirements relating to the Location-by-Reference approach using a location Uniform Resource Identifier (URI) to handle location information within signaling and other Internet messaging. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-geopriv-lbyr-requirements-09 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC5808 RFC5809 RFC5810 Forwarding and Control Element Separation (ForCES) Protocol Specification A. Doria Editor J. Hadi Salim Editor R. Haas Editor H. Khosravi Editor W. Wang Editor L. Dong R. Gopal J. Halpern March 2010 ASCII HTML 124 control elements forwarding elements fe ce network element ne tml transport mapping layer

This document specifies the Forwarding and Control Element Separation (ForCES) protocol. The ForCES protocol is used for communications between Control Elements (CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC 3654. Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML). [STANDARDS-TRACK]

 draft-ietf-forces-protocol-22 RFC7121 RFC7391 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=5810 10.17487/RFC5810 RFC5811 SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol J. Hadi Salim K. Ogawa March 2010 ASCII HTML 28 ForCES TML stream conrol transmission protocol

This document defines the SCTP-based TML (Transport Mapping Layer) for the ForCES (Forwarding and Control Element Separation) protocol. It explains the rationale for choosing the SCTP (Stream Control Transmission Protocol) and also describes how this TML addresses all the requirements required by and the ForCES protocol. [STANDARDS TRACK]

 draft-ietf-forces-sctptml-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC5811 RFC5812 Forwarding and Control Element Separation (ForCES) Forwarding Element Model J. Halpern J. Hadi Salim March 2010 ASCII HTML 134 forwarding element control element

This document defines the forwarding element (FE) model used in the Forwarding and Control Element Separation (ForCES) protocol. The model represents the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in RFC 3654. [STANDARDS-TRACK]

 draft-ietf-forces-model-16 RFC7408 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=5812 10.17487/RFC5812 RFC5813 Forwarding and Control Element Separation (ForCES) MIB R. Haas March 2010 ASCII HTML 17 management information base network element ne forces-mib

This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it defines managed objects for the Forwarding and Control Element Separation (ForCES) Network Element (NE). [STANDARDS-TRACK]

 draft-ietf-forces-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC5813 RFC5814 Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks W. Sun Editor G. Zhang Editor March 2010 ASCII HTML 44 Signaling performance RSVP-TE delay measurement control plane performance

Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for a future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. These physically diverse devices differ drastically from one another in dynamic provisioning ability. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other.

This document provides a series of performance metrics to evaluate the dynamic Label Switched Path (LSP) provisioning performance in GMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the features of GMPLS networks in LSP dynamic provisioning. [STANDARDS-TRACK]

 draft-ietf-ccamp-lsp-dppm-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5814 RFC5815 Definitions of Managed Objects for IP Flow Information Export T. Dietz Editor A. Kobayashi B. Claise G. Muenz April 2010 ASCII HTML 64 Selector Collector Exporter Sampling Filtering IPFIX IPFIX-MIB IPFIX-SELECTOR-MIB

This document defines managed objects for IP Flow Information eXport (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. [STANDARDS-TRACK]

 draft-ietf-ipfix-mib-10 RFC6615 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5815 10.17487/RFC5815 RFC5816 ESSCertIDv2 Update for RFC 3161 S. Santesson N. Pope April 2010 ASCII HTML 5 signer certificate secure hash algorithm sha-1

This document updates RFC 3161. It allows the use of ESSCertIDv2, as defined in RFC 5035, to specify the hash of a signer certificate when the hash is calculated with a function other than the Secure Hash Algorithm (SHA-1). [STANDARDS-TRACK]

 draft-ietf-pkix-rfc3161-update-09 RFC3161 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5816 RFC5817 Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks Z. Ali JP. Vasseur A. Zamfir J. Newton April 2010 ASCII HTML 11 mpls-te te

MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network.

This document provides requirements and protocol mechanisms to reduce or eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS-TE and its Generalized MPLS (GMPLS) extensions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ccamp-mpls-graceful-shutdown-13 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5817 10.17487/RFC5817 RFC5818 Data Channel Status Confirmation Extensions for the Link Management Protocol D. Li H. Xu S. Bardalai J. Meuric D. Caviglia April 2010 ASCII HTML 15 LMP

This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label-Switching Routers (LSRs) to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. [STANDARDS-TRACK]

 draft-ietf-ccamp-confirm-data-channel-status-09 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5818 RFC5819 IMAP4 Extension for Returning STATUS Information in Extended LIST A. Melnikov T. Sirainen March 2010 ASCII HTML 6 list lsub

Many IMAP clients display information about total number of messages / total number of unseen messages in IMAP mailboxes. In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command. [STANDARDS-TRACK]

 draft-ietf-morg-status-in-list-01 PROPOSED STANDARD PROPOSED STANDARD IETF app morg http://www.rfc-editor.org/errata_search.php?rfc=5819 10.17487/RFC5819 RFC5820 Extensions to OSPF to Support Mobile Ad Hoc Networking A. Roy Editor M. Chandra Editor March 2010 ASCII HTML 41 open shortest path first manet ospf-or ospf-overlapping relay link-local signaling lls ospf-manet

This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extensions, called OSPF-OR (OSPF-Overlapping Relay), include mechanisms for link-local signaling (LLS), an OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. OSPF-OR also provides a means to reduce unnecessary adjacencies to support larger MANETs. [STANDARDS-TRACK]

 draft-ietf-ospf-manet-or-03 RFC7137 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC5820 RFC5821 RFC5822 RFC5823 RFC5824 Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN K. Kumaki Editor R. Zhang Y. Kamite April 2010 ASCII HTML 27 triple-play service

Today, customers expect to run triple-play services through BGP/MPLS IP-VPNs. Some service providers will deploy services that request Quality of Service (QoS) guarantees from a local Customer Edge (CE) to a remote CE across the network. As a result, the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for an end-to-end QoS and reserving an adequate bandwidth continue to increase.

Service providers can use both an MPLS and an MPLS Traffic Engineering (MPLS-TE) Label Switched Path (LSP) to meet their service objectives. This document describes service-provider requirements for supporting a customer Resource ReSerVation Protocol (RSVP) and RSVP-TE over a BGP/MPLS IP-VPN. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05 INFORMATIONAL INFORMATIONAL IETF rtg l3vpn 10.17487/RFC5824 RFC5825 Displaying Downgraded Messages for Email Address Internationalization K. Fujiwara B. Leiba April 2010 ASCII HTML 14 EAI Email Address Internationalization Downgrade MAIL

This document describes a method for displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-downgraded-display-03 RFC6530 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5825 RFC5826 Home Automation Routing Requirements in Low-Power and Lossy Networks A. Brandt J. Buron G. Porcu April 2010 ASCII HTML 17 roll routing over low power and lossy

This document presents requirements specific to home control and automation applications for Routing Over Low power and Lossy (ROLL) networks. In the near future, many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure), and advanced controllers (radio-frequency-based AV remote control, central server for light and heat control). Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home-control and automation environment. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-roll-home-routing-reqs-11 INFORMATIONAL INFORMATIONAL IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=5826 10.17487/RFC5826 RFC5827 Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP) M. Allman K. Avrachenkov U. Ayesta J. Blanton P. Hurtig May 2010 ASCII HTML 15 transmission control protocol fast retransmission

This document proposes a new mechanism for TCP and Stream Control Transmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout. [STANDARDS-TRACK]

 draft-ietf-tcpm-early-rexmt-04 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC5827 RFC5828 Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework D. Fedyk L. Berger L. Andersson March 2010 ASCII HTML 20 transport networks

There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), Time-Division Multiplexing (TDM), and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized- MPLS-based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed, and this document provides a framework for these extensions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ccamp-gmpls-ethernet-arch-09 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5828 RFC5829 Link Relation Types for Simple Version Navigation between Web Resources A. Brown G. Clemm J. Reschke Editor April 2010 ASCII HTML 12

This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-brown-versioning-link-relations-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5829 RFC5830 GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms V. Dolmatov Editor March 2010 ASCII HTML 19 russian federal standard electronic encryption decryption message authentication russian cryptographic standard

This document is intended to be a source of information about the Russian Federal standard for electronic encryption, decryption, and message authentication algorithms (GOST 28147-89), which is one of the Russian cryptographic standard algorithms called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST 28147-89 for encryption, decryption, and message authentication. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-dolmatov-cryptocom-gost2814789-08 RFC8891 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5830 10.17487/RFC5830 RFC5831 GOST R 34.11-94: Hash Function Algorithm V. Dolmatov Editor March 2010 ASCII HTML 17 russian federal standard russian cryptographic standard russian cryptography

This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-94), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.11-94 for hash computation. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-dolmatov-cryptocom-gost341194-07 RFC6986 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5831 10.17487/RFC5831 RFC5832 GOST R 34.10-2001: Digital Signature Algorithm V. Dolmatov Editor March 2010 ASCII HTML 22 russian federal standard digital signature russian cryptographic standard russian cryptography

This document is intended to be a source of information about the Russian Federal standard for digital signatures (GOST R 34.10-2001), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.10-2001 for digital signature generation and verification.

 draft-dolmatov-cryptocom-gost34102001-08 RFC7091 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5832 10.17487/RFC5832 RFC5833 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB Y. Shi Editor D. Perkins Editor C. Elliott Editor Y. Zhang Editor May 2010 ASCII HTML 73 mib CAPWAP-BASE-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes the managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. This MIB module is presented as a basis for future work on the SNMP management of the CAPWAP protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-capwap-base-mib-09 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC5833 RFC5834 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11 Y. Shi Editor D. Perkins Editor C. Elliott Editor Y. Zhang Editor May 2010 ASCII HTML 25 mib CAPWAP-DOT11-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) protocol for IEEE 802.11 wireless binding. This MIB module is presented as a basis for future work on the management of the CAPWAP protocol using the Simple Network Management Protocol (SNMP). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-capwap-802dot11-mib-06 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC5834 RFC5835 Framework for Metric Composition A. Morton Editor S. Van den Berghe Editor April 2010 ASCII HTML 18

This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM), RFC 2330, and developed by the IETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics that are useful in practice. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ippm-framework-compagg-09 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC5835 RFC5836 Extensible Authentication Protocol (EAP) Early Authentication Problem Statement Y. Ohba Editor Q. Wu Editor G. Zorn Editor April 2010 ASCII HTML 20 eap early authentication

Extensible Authentication Protocol (EAP) early authentication may be defined as the use of EAP by a mobile device to establish authenticated keying material on a target attachment point prior to its arrival. This document discusses the EAP early authentication problem in detail. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-hokey-preauth-ps-12 INFORMATIONAL INFORMATIONAL IETF sec hokey 10.17487/RFC5836 RFC5837 Extending ICMP for Interface and Next-Hop Identification A. Atlas Editor R. Bonica Editor C. Pignataro Editor N. Shen JR. Rivers April 2010 ASCII HTML 18 Internet Control Message Protocol

This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, and the IP next hop to which the datagram would have been forwarded.

Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. [STANDARDS-TRACK]

 draft-atlas-icmp-unnumbered-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5837 RFC5838 Support of Address Families in OSPFv3 A. Lindem Editor S. Mirtorabi A. Roy M. Barnes R. Aggarwal April 2010 ASCII HTML 13 af instance id

This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances. It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs. [STANDARDS-TRACK]

 draft-ietf-ospf-af-alt-10 RFC6969 RFC7949 RFC8362 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5838 RFC5839 An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification A. Niemi D. Willis Editor May 2010 ASCII HTML 25 SIP events subnot-etags optimization

The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing, and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. [STANDARDS-TRACK]

 draft-ietf-sipcore-subnot-etags-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC5839 RFC5840 Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility K. Grewal G. Montenegro M. Bhatia April 2010 ASCII HTML 15 wesp

This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) RFC 4303 and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP, and if not, (2) inspect the IPsec packets for network monitoring and access control functions. Currently, in the IPsec ESP standard, there is no deterministic way to differentiate between encrypted and unencrypted payloads by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP. [STANDARDS-TRACK]

 draft-ietf-ipsecme-traffic-visibility-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5840 RFC5841 TCP Option to Denote Packet Mood R. Hay W. Turkal April 1 2010 ASCII HTML 9

This document proposes a new TCP option to denote packet mood. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-1april2010-tcp-option-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5841 10.17487/RFC5841 RFC5842 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) G. Clemm J. Crawford J. Reschke Editor J. Whitehead April 2010 ASCII HTML 45 HTTP WebDAV collections hard link

This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-webdav-bind-27 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5842 RFC5843 Additional Hash Algorithms for HTTP Instance Digests A. Bryan April 2010 ASCII HTML 5 Hypertext Transfer Protocol HTTP Digest Algorithm Values registry update

The IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" defines values for digest algorithms used by Instance Digests in HTTP. Instance Digests in HTTP provide a digest, also known as a checksum or hash, of an entire representation of the current state of a resource. This document adds new values to the registry and updates previous values. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-bryan-http-digest-algorithm-values-update-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5843 10.17487/RFC5843 RFC5844 IPv4 Support for Proxy Mobile IPv6 R. Wakikawa S. Gundavelli May 2010 ASCII HTML 49 NAT traversal Dual Stack Mobility IPv4 Support IPv4 Support for PMIPv6

This document specifies extensions to the Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node, and 2) allow the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport network. [STANDARDS-TRACK]

 draft-ietf-netlmm-pmip6-ipv4-support-18 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm 10.17487/RFC5844 RFC5845 Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6 A. Muhanna M. Khalil S. Gundavelli K. Leung June 2010 ASCII HTML 25 PMIP6 PMIPv6 Downlink GRE Key Uplink GRE Key TLV-Header Tunneling TLV-Header Tunneling GRE Key Exchange

This specification defines a new mobility option for allowing the mobile access gateway and the local mobility anchor to negotiate Generic Routing Encapsulation (GRE) encapsulation mode and exchange the downlink and uplink GRE keys that are used for marking the downlink and uplink traffic that belong to a specific mobility session. In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys. [STANDARDS-TRACK]

 draft-ietf-netlmm-grekey-option-09 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm 10.17487/RFC5845 RFC5846 Binding Revocation for IPv6 Mobility A. Muhanna M. Khalil S. Gundavelli K. Chowdhury P. Yegani June 2010 ASCII HTML 39 PMIP6 PMIPv6 Binding Revocation Indication BRI Binding Revocation Acknowledgement BRA MIP6 DSMIP6 Multiple Care-of Addresses PMIPv6 Revocation Bulk PMIPv6 Revocation

This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. This mechanism can be used both with base Mobile IPv6 and its extensions, such as Proxy Mobile IPv6. The mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified Binding Cache entries. [STANDARDS-TRACK]

 draft-ietf-mext-binding-revocation-14 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC5846 RFC5847 Heartbeat Mechanism for Proxy Mobile IPv6 V. Devarapalli Editor R. Koodli Editor H. Lim N. Kant S. Krishnan J. Laganier June 2010 ASCII HTML 11 Node Reachability Restarts Failure Detection

Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the mobile access gateway (MAG) and the local mobility anchor (LMA), set up tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes a heartbeat mechanism between the MAG and the LMA to detect failures, quickly inform peers in the event of a recovery from node failures, and allow a peer to take appropriate action. [STANDARDS TRACK]

 draft-ietf-netlmm-pmipv6-heartbeat-07 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm http://www.rfc-editor.org/errata_search.php?rfc=5847 10.17487/RFC5847 RFC5848 Signed Syslog Messages J. Kelsey J. Callas A. Clemm May 2010 ASCII HTML 40 syslog syslog-sign

This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". [STANDARDS-TRACK]

 draft-ietf-syslog-sign-29 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC5848 RFC5849 The OAuth 1.0 Protocol E. Hammer-Lahav Editor April 2010 ASCII HTML 38 authorization delegation

OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-hammer-oauth-10 RFC6749 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5849 10.17487/RFC5849 RFC5850 A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP) R. Mahy R. Sparks J. Rosenberg D. Petrie A. Johnston Editor May 2010 ASCII HTML 44 call control multiparty features mixing refer 3pcc Refer method Replaces header field Join header field conferencing

This document defines a framework and the requirements for call control and multi-party usage of the Session Initiation Protocol (SIP). To enable discussion of multi-party features and applications, we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually set up the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state and session history. This framework also describes other goals that embody the spirit of SIP applications as used on the Internet such as the definition of primitives (not services), invoker and participant oriented primitives, signaling and mixing model independence, and others. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sipping-cc-framework-12 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=5850 10.17487/RFC5850 RFC5851 Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks S. Ooghe N. Voigt M. Platnic T. Haag S. Wadhwa May 2010 ASCII HTML 47 Access Node Control Protocol Topology Discovery Loop Configuration Remote Connectivity Test Multicast Access Node Network Access Server

The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to service, quality of service, and subscribers. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device-device communication. This allows for performing access-link-related operations within those network elements, while avoiding impact on the existing Operational Support Systems.

This document first identifies a number of use cases for which the Access Node Control Mechanism may be appropriate. It then presents the requirements for the Access Node Control Protocol (ANCP) that must be taken into account during protocol design. Finally, it describes requirements for the network elements that need to support ANCP and the described use cases. These requirements should be seen as guidelines rather than as absolute requirements. RFC 2119 therefore does not apply to the nodal requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ancp-framework-13 INFORMATIONAL INFORMATIONAL IETF int ancp 10.17487/RFC5851 RFC5852 RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network D. Caviglia D. Ceccarelli D. Bramanti D. Li S. Bardalai April 2010 ASCII HTML 23 resource reservation protocol handover procedures

In a transport network scenario, Data Plane connections controlled by either a Generalized Multiprotocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or a Management System (Permanent Connections - PC) may independently coexist. The ability of transforming an existing PC into an SPC and vice versa -- without actually affecting Data Plane traffic being carried over it -- is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in RFC 5493.

This memo describes an extension to GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover-related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the Handover procedures must never impact an already established Data Plane connection. [STANDARDS-TRACK]

 draft-ietf-ccamp-pc-spc-rsvpte-ext-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5852 RFC5853 Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments J. Hautakorpi Editor G. Camarillo R. Penfield A. Hawrylyshen M. Bhatia April 2010 ASCII HTML 26

This document describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs). The goal of this document is to describe the commonly provided functions of SBCs. A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or if additional standards work is required. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sipping-sbc-funcs-09 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5853 RFC5854 The Metalink Download Description Format A. Bryan T. Tsujikawa N. McNab P. Poeml June 2010 ASCII HTML 39 file transfer mirrors data integrity hash xml http hypertext transfer protocol ftp file transfer protocol metadata torrent

This document specifies Metalink, an XML-based download description format. Metalink describes download locations (mirrors), cryptographic hashes, and other information. Clients can transparently use this information to reliably transfer files. [STANDARDS-TRACK]

 draft-bryan-metalink-28 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5854 RFC5855 Nameservers for IPv4 and IPv6 Reverse Zones J. Abley T. Manderson May 2010 ASCII HTML 12 IN-ADDR.ARPA IP6.ARPA reverse mapping

This document specifies a stable naming scheme for the nameservers that serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS. These zones contain data that facilitate reverse mapping (address to name). This memo documents an Internet Best Current Practice.

 draft-jabley-reverse-servers-01 BCP0155 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5855 RFC5856 Integration of Robust Header Compression over IPsec Security Associations E. Ertekin R. Jasani C. Christou C. Bormann May 2010 ASCII HTML 15 ROHC ROHCoIPsec

IP Security (IPsec) provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-rohc-hcoipsec-13 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC5856 RFC5857 IKEv2 Extensions to Support Robust Header Compression over IPsec E. Ertekin C. Christou R. Jasani T. Kivinen C. Bormann May 2010 ASCII HTML 13 ROHC ROHCoIPsec

In order to integrate Robust Header Compression (ROHC) with IPsec, a mechanism is needed to signal ROHC channel parameters between endpoints. Internet Key Exchange (IKE) is a mechanism that can be leveraged to exchange these parameters. This document specifies extensions to IKEv2 that will allow ROHC and its associated channel parameters to be signaled for IPsec Security Associations (SAs). [STANDARDS-TRACK]

 draft-ietf-rohc-ikev2-extensions-hcoipsec-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5857 10.17487/RFC5857 RFC5858 IPsec Extensions to Support Robust Header Compression over IPsec E. Ertekin C. Christou C. Bormann May 2010 ASCII HTML 15 ROHC ROHCoIPsec

Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. However, in order to integrate ROHC with IPsec, extensions to the Security Policy Database (SPD) and Security Association Database (SAD) are required. This document describes the IPsec extensions required to support ROHCoIPsec. [STANDARDS-TRACK]

 draft-ietf-rohc-ipsec-extensions-hcoipsec-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5858 10.17487/RFC5858 RFC5859 TFTP Server Address Option for DHCPv4 R. Johnson June 2010 ASCII HTML 6 voip

This memo documents existing usage for the "TFTP Server Address" option. The option number currently in use is 150. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any pre-existing usages of option numbers in the range 128-223 should be documented, and the Dynamic Host Configuration working group will try to officially assign those numbers to those options. The option is defined for DHCPv4 and works only with IPv4 addresses. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-raj-dhc-tftp-addr-option-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5859 RFC5860 Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks M. Vigoureux Editor D. Ward Editor M. Betts Editor May 2010 ASCII HTML 17 MPLS-TP OAM

This document lists architectural and functional requirements for the Operations, Administration, and Maintenance of MPLS Transport Profile. These requirements apply to pseudowires, Label Switched Paths, and Sections. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-oam-requirements-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5860 RFC5861 HTTP Cache-Control Extensions for Stale Content M. Nottingham May 2010 ASCII HTML 6

This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-nottingham-http-stale-controls-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5861 10.17487/RFC5861 RFC5862 Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE S. Yasukawa A. Farrel June 2010 ASCII HTML 11 mpls gmpls

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs.

Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pce-p2mp-req-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5862 RFC5863 DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations T. Hansen E. Siegel P. Hallam-Baker D. Crocker May 2010 ASCII HTML 51 Email Electronic Mail Internet Mail Message Verification

DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography and using the domain name service as its key server technology. This permits verification of a responsible organization, as well as the integrity of the message content. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational, and migration considerations for DKIM. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-dkim-deployment-11 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC5863 RFC5864 DNS SRV Resource Records for AFS R. Allbery April 2010 ASCII HTML 10 domain name system srv rr distributed file system afsdb rr

This document specifies how to use DNS (Domain Name Service) SRV RRs (Resource Records) to locate services for the AFS distributed file system and how the priority and weight values of the SRV RR should be interpreted in the server ranking system used by AFS. It updates RFC 1183 to deprecate the use of the AFSDB RR to locate AFS cell database servers and provides guidance for backward compatibility. [STANDARDS TRACK]

 draft-allbery-afs-srv-records-05 RFC1183 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5864 10.17487/RFC5864 RFC5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic F. Baker J. Polk M. Dolly May 2010 ASCII HTML 14 real-time traffic

This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic. This traffic class conforms to the Expedited Forwarding Per-Hop Behavior. This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission. This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission. [STANDARDS-TRACK]

 draft-ietf-tsvwg-admitted-realtime-dscp-07 RFC4542 RFC4594 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=5865 10.17487/RFC5865 RFC5866 Diameter Quality-of-Service Application D. Sun Editor P. McCann H. Tschofenig T. Tsou A. Doria G. Zorn Editor May 2010 ASCII HTML 51 Diameter AAA QoS Policy VoIP SIP

This document describes the framework, messages, and procedures for the Diameter Quality-of-Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation, namely "Pull" and "Push", are defined. [STANDARDS TRACK]

 draft-ietf-dime-diameter-qos-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5866 RFC5867 Building Automation Routing Requirements in Low-Power and Lossy Networks J. Martocci Editor P. De Mil N. Riou W. Vermeylen June 2010 ASCII HTML 26

The Routing Over Low-Power and Lossy (ROLL) networks Working Group has been chartered to work on routing solutions for Low-Power and Lossy Networks (LLNs) in various markets: industrial, commercial (building), home, and urban networks. Pursuant to this effort, this document defines the IPv6 routing requirements for building automation. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-roll-building-routing-reqs-09 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC5867 RFC5868 Problem Statement on the Cross-Realm Operation of Kerberos S. Sakane K. Kamada S. Zrelli M. Ishiyama May 2010 ASCII HTML 13

This document provides background information regarding large-scale Kerberos deployments in the industrial sector, with the aim of identifying issues in the current Kerberos cross-realm authentication model as defined in RFC 4120.

This document describes some examples of actual large-scale industrial systems, and lists requirements and restrictions regarding authentication operations in such environments. It also identifies a number of requirements derived from the industrial automation field. Although they are found in the field of industrial automation, these requirements are general enough and are applicable to the problem of Kerberos cross-realm operations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-krb-wg-cross-problem-statement-06 INFORMATIONAL INFORMATIONAL IETF sec krb-wg 10.17487/RFC5868 RFC5869 HMAC-based Extract-and-Expand Key Derivation Function (HKDF) H. Krawczyk P. Eronen May 2010 ASCII HTML 14

This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-krawczyk-hkdf-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5869 10.17487/RFC5869 RFC5870 A Uniform Resource Identifier for Geographic Locations ('geo' URI) A. Mayrhofer C. Spanring June 2010 ASCII HTML 23 geography geo uri scheme

This document specifies a Uniform Resource Identifier (URI) for geographic locations using the 'geo\' scheme name. A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way. The default coordinate reference system used is the World Geodetic System 1984 (WGS-84). [STANDARDS-TRACK]

 draft-ietf-geopriv-geo-uri-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5870 10.17487/RFC5870 RFC5871 IANA Allocation Guidelines for the IPv6 Routing Header J. Arkko S. Bradner May 2010 ASCII HTML 3 routing type field

This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header. [STANDARDS TRACK]

 draft-ietf-6man-iana-routing-header-00 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC5871 RFC5872 IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA) J. Arkko A. Yegin May 2010 ASCII HTML 5

This document relaxes the IANA rules for the Protocol for Carrying Authentication for Network Access (PANA). [STANDARDS-TRACK]

 draft-arkko-pana-iana-02 RFC5191 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5872 RFC5873 Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA) Y. Ohba A. Yegin May 2010 ASCII HTML 8

This document defines an extension to the Protocol for Carrying Authentication for Network Access (PANA) for proactively establishing a PANA Security Association between a PANA Client in one access network and a PANA Authentication Agent in another access network to which the PANA Client may move. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-pana-preauth-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5873 RFC5874 An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources J. Rosenberg J. Urpalainen May 2010 ASCII HTML 24 SIP Instant Messaging

This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format reports which document has changed and its former and new entity tags. It can report the differences between versions of the document, using an XML patch format. It can report existing element and attribute content when versions of an XCAP server document change. XCAP diff documents can be delivered to diff clients using a number of means, including a Session Initiation Protocol (SIP) event package. [STANDARDS-TRACK]

 draft-ietf-simple-xcap-diff-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5874 RFC5875 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package J. Urpalainen D. Willis Editor May 2010 ASCII HTML 27 xcap-diff xcap diff

This document describes an "xcap-diff" SIP (Session Initiation Protocol) event package for the SIP Event Notification Framework, which clients can use to receive notifications of changes to Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization information exchange and document updates are based on the XCAP Diff format. [STANDARDS TRACK]

 draft-ietf-sip-xcapevent-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5875 RFC5876 Updates to Asserted Identity in the Session Initiation Protocol (SIP) J. Elwell April 2010 ASCII HTML 11 SIP P-Asserted-Identity

The Session Initiation Protocol (SIP) has a mechanism for conveying the identity of the originator of a request by means of the P-Asserted-Identity and P-Preferred-Identity header fields. These header fields are specified for use in requests using a number of SIP methods, in particular the INVITE method. However, RFC 3325 does not specify the insertion of the P-Asserted-Identity header field by a trusted User Agent Client (UAC), does not specify the use of P-Asserted-Identity and P-Preferred-Identity header fields with certain SIP methods such as UPDATE, REGISTER, MESSAGE, and PUBLISH, and does not specify how to handle an unexpected number of URIs or unexpected URI schemes in these header fields. This document extends RFC 3325 to cover these situations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sipping-update-pai-09 RFC3325 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5876 RFC5877 The application/pkix-attr-cert Media Type for Attribute Certificates R. Housley May 2010 ASCII HTML 4

This document specifies a MIME media type used to carry a single attribute certificate as defined in RFC 5755. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pkix-attr-cert-mime-type-03 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5877 10.17487/RFC5877 RFC5878 Transport Layer Security (TLS) Authorization Extensions M. Brown R. Housley May 2010 ASCII HTML 19 handshake protocol

This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language (SAML) assertions, is exchanged in the supplemental data handshake message. This document defines an Experimental Protocol for the Internet community.

 draft-housley-tls-authz-extns-09 RFC5246 RFC8447 RFC8996 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5878 10.17487/RFC5878 RFC5879 Heuristics for Detecting ESP-NULL Packets T. Kivinen D. McDonald May 2010 ASCII HTML 32 IPsec Wrapped ESP (WESP) deep-inspection packet inspection

This document describes a set of heuristics for distinguishing IPsec ESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. These heuristics can be used on intermediate devices, like traffic analyzers, and deep-inspection engines, to quickly decide whether or not a given packet flow is encrypted, i.e., whether or not it can be inspected. Use of these heuristics does not require any changes made on existing IPsec hosts that are compliant with RFC 4303. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ipsecme-esp-null-heuristics-07 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC5879 RFC5880 Bidirectional Forwarding Detection (BFD) D. Katz D. Ward June 2010 ASCII HTML 49

This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]

 draft-ietf-bfd-base-11 RFC7419 RFC7880 RFC8562 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=5880 10.17487/RFC5880 RFC5881 Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) D. Katz D. Ward June 2010 ASCII HTML 7

This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over IPv4 and IPv6 for single IP hops. [STANDARDS-TRACK]

 draft-ietf-bfd-v4v6-1hop-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=5881 10.17487/RFC5881 RFC5882 Generic Application of Bidirectional Forwarding Detection (BFD) D. Katz D. Ward June 2010 ASCII HTML 17

This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. [STANDARDS-TRACK]

 draft-ietf-bfd-generic-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=5882 10.17487/RFC5882 RFC5883 Bidirectional Forwarding Detection (BFD) for Multihop Paths D. Katz D. Ward June 2010 ASCII HTML 6

This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links. [STANDARDS-TRACK]

 draft-ietf-bfd-multihop-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC5883 RFC5884 Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) R. Aggarwal K. Kompella T. Nadeau G. Swallow June 2010 ASCII HTML 12 Multiprotocol Label Switching lsp ping

One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) data plane failure. LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages. A combination of LSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP Ping for this application. It also describes procedures for using BFD in this environment. [STANDARDS-TRACK]

 draft-ietf-bfd-mpls-07 RFC1122 RFC7726 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=5884 10.17487/RFC5884 RFC5885 Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) T. Nadeau Editor C. Pignataro Editor June 2010 ASCII HTML 14 Pseudowire VCCV BFD VCCV-BFD PW OAM

This document describes Connectivity Verification (CV) Types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV). VCCV provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. [STANDARDS-TRACK]

 draft-ietf-pwe3-vccv-bfd-07 RFC6478 RFC7885 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5885 RFC5886 A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture JP. Vasseur Editor JL. Le Roux Y. Ikejiri June 2010 ASCII HTML 26

A Path Computation Element (PCE)-based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain".

In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. [STANDARDS-TRACK]

 draft-ietf-pce-monitoring-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC5886 RFC5887 Renumbering Still Needs Work B. Carpenter R. Atkinson H. Flinck May 2010 ASCII HTML 35

This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and it identifies operational issues with those mechanisms. It also summarises current technical proposals for additional mechanisms. Finally, there is a gap analysis identifying possible areas for future work. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-carpenter-renum-needs-work-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5887 RFC5888 The Session Description Protocol (SDP) Grouping Framework G. Camarillo H. Schulzrinne June 2010 ASCII HTML 21 SDP grouping SIP

In this specification, we define a framework to group "m" lines in the Session Description Protocol (SDP) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. This document obsoletes RFC 3388. [STANDARDS-TRACK]

 draft-ietf-mmusic-rfc3388bis-04 RFC3388 RFC8843 RFC9143 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5888 10.17487/RFC5888 RFC5889 IP Addressing Model in Ad Hoc Networks E. Baccelli Editor M. Townsley Editor September 2010 ASCII HTML 8 mobile network ad hoc network MANET network architecture addressing framework configuration routing IP networks

This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-autoconf-adhoc-addr-model-03 INFORMATIONAL INFORMATIONAL IETF int autoconf 10.17487/RFC5889 RFC5890 Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework J. Klensin August 2010 ASCII HTML 23 IDNA2008 idn ascii characters

This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]

 draft-ietf-idnabis-defs-13 RFC3490 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis http://www.rfc-editor.org/errata_search.php?rfc=5890 10.17487/RFC5890 RFC5891 Internationalized Domain Names in Applications (IDNA): Protocol J. Klensin August 2010 ASCII HTML 17 IDNA2008 idn ascii characters idna applications

This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]

 draft-ietf-idnabis-protocol-18 RFC3490 RFC3491 RFC3492 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis http://www.rfc-editor.org/errata_search.php?rfc=5891 10.17487/RFC5891 RFC5892 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) P. Faltstrom Editor August 2010 ASCII HTML 70 IDNA DNS IDN Unicode IDNA2008

This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).

It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS-TRACK]

 draft-ietf-idnabis-tables-09 RFC8753 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis http://www.rfc-editor.org/errata_search.php?rfc=5892 10.17487/RFC5892 RFC5893 Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA) H. Alvestrand Editor C. Karp August 2010 ASCII HTML 17 IDNA2008 idn ascii characters Bidi

The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges. This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS-TRACK]

 draft-ietf-idnabis-bidi-07 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis 10.17487/RFC5893 RFC5894 Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale J. Klensin August 2010 ASCII HTML 43 IDNA2008 idn ascii characters

Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-idnabis-rationale-17 INFORMATIONAL INFORMATIONAL IETF app idnabis 10.17487/RFC5894 RFC5895 Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008 P. Resnick P. Hoffman September 2010 ASCII HTML 7 user input character mapping locale user interface Unicode

In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS). The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-resman-idna2008-mappings-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5895 RFC5896 Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy L. Hornquist Astrand S. Hartman June 2010 ASCII HTML 6

Several Generic Security Service Application Program Interface (GSS-API) applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers. In effect, the server acts as an agent on behalf of the user. Examples include web applications that need to access e-mail or file servers, including CIFS (Common Internet File System) file servers. However, delegating the user credentials to a party who is not sufficiently trusted is problematic from a security standpoint. Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation. This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC 2743). [STANDARDS-TRACK]

 draft-lha-gssapi-delegate-policy-05 RFC2743 RFC2744 RFC4120 RFC4121 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5896 10.17487/RFC5896 RFC5897 Identification of Communications Services in the Session Initiation Protocol (SIP) J. Rosenberg June 2010 ASCII HTML 23 service identification

This document considers the problem of service identification in the Session Initiation Protocol (SIP). Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent (UA). This document discusses the uses of service identification, and outlines several architectural principles behind the process. It identifies perils when service identification is not done properly -- including fraud, interoperability failures, and stifling of innovation. It then outlines a set of recommended practices for service identification. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sipping-service-identification-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5897 RFC5898 Connectivity Preconditions for Session Description Protocol (SDP) Media Streams F. Andreasen G. Camarillo D. Oran D. Wing July 2010 ASCII HTML 17 SIP preconditions connection connectivity

This document defines a new connectivity precondition for the Session Description Protocol (SDP) precondition framework. A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified. The method of verification may vary depending on the type of transport used for the media. For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets. For reliable connection-oriented transports such as TCP, verification can be achieved simply by successful connection establishment or by probing the connection with data or control packets, depending on the situation. [STANDARDS-TRACK]

 draft-ietf-mmusic-connectivity-precon-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5898 RFC5899 RFC5900 RFC5901 Extensions to the IODEF-Document Class for Reporting Phishing P. Cain D. Jevans July 2010 ASCII HTML 51 Incident Object Description Exchange Format

This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to support the reporting of phishing events, which is a particular type of fraud. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle -- from receipt of the phishing lure to the disablement of the collection site. Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents. [STANDARDS-TRACK]

 draft-cain-post-inch-phishingextns-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5901 RFC5902 IAB Thoughts on IPv6 Network Address Translation D. Thaler L. Zhang G. Lebovitz July 2010 ASCII HTML 15 NAT IPv6 Transparency End-to-End Privacy Multihoming

There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs). This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB's thoughts on the current open issues and the solution space. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-ipv6-nat-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5902 RFC5903 Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2 D. Fu J. Solinas June 2010 ASCII HTML 16 Elliptic Curve Cryptography ECC Internet Key Exchange elliptic curve Diffie-Hellman suite b nist curve

This document describes three Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups. These groups are based on modular arithmetic rather than binary arithmetic. These groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This document obsoletes RFC 4753. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-solinas-rfc4753bis-01 RFC4753 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5903 10.17487/RFC5903 RFC5904 RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support G. Zorn June 2010 ASCII HTML 15 RADIUS AAA IEEE 802.16

This document defines a set of Remote Authentication Dial-In User Service (RADIUS) Attributes that are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-zorn-radius-pkmv1-12 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5904 RFC5905 Network Time Protocol Version 4: Protocol and Algorithms Specification D. Mills J. Martin Editor J. Burbank W. Kasch June 2010 ASCII HTML 110 NTP SNTP Synchronization

The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]

 draft-ietf-ntp-ntpv4-proto-13 RFC1305 RFC4330 RFC7822 RFC8573 RFC9109 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5905 10.17487/RFC5905 RFC5906 Network Time Protocol Version 4: Autokey Specification B. Haberman Editor D. Mills June 2010 ASCII HTML 58 ntp ntpv4 public key cryptography

This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions.

This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of the protocol states, events, and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested, and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual Memory System (VMS) operating systems at http://www.ntp.org. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ntp-autokey-08 INFORMATIONAL INFORMATIONAL IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5906 10.17487/RFC5906 RFC5907 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) H. Gerstung C. Elliott B. Haberman Editor June 2010 ASCII HTML 26

The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations, and other networked equipment. As time synchronization is more and more a mission-critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to set up a monitoring system that is platform- and vendor-independent. This document provides a standardized collection of data objects for monitoring the NTP entity of such a network participant and it is part of the NTP version 4 standardization effort. [STANDARDS-TRACK]

 draft-ietf-ntp-ntpv4-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5907 10.17487/RFC5907 RFC5908 Network Time Protocol (NTP) Server Option for DHCPv6 R. Gayraud B. Lourdelet June 2010 ASCII HTML 9 Dynamic Host Configuration Protocol for IPv6

The NTP Server Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides NTPv4 (Network Time Protocol version 4) server location information to DHCPv6 hosts. [STANDARDS-TRACK]

 draft-ietf-ntp-dhcpv6-ntp-opt-06 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5908 10.17487/RFC5908 RFC5909 Securing Neighbor Discovery Proxy: Problem Statement J-M. Combes S. Krishnan G. Daley July 2010 ASCII HTML 22 send secure neighbor discovery

Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform Neighbor Discovery operations on its behalf.

Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor Discovery messages.

Neighbor Discovery Proxy currently cannot be secured using Secure Neighbor Discovery (SEND). Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to SEND. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-csi-sndp-prob-04 INFORMATIONAL INFORMATIONAL IETF int csi 10.17487/RFC5909 RFC5910 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) J. Gould S. Hollenbeck May 2010 ASCII HTML 36 epp Extensible Provisioning Protocol xml dns security dnssec delegation signer ds

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. This document obsoletes RFC 4310. [STANDARDS-TRACK]

 draft-gould-rfc4310bis-07 RFC4310 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5910 10.17487/RFC5910 RFC5911 New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME P. Hoffman J. Schaad June 2010 ASCII HTML 59 S/MIME PKIX ASN.1 modules

The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-smime-new-asn1-07 RFC6268 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5911 10.17487/RFC5911 RFC5912 New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) P. Hoffman J. Schaad June 2010 ASCII HTML 117 S/MIME PKIX ASN.1 modules

The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pkix-new-asn1-08 RFC6960 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5912 10.17487/RFC5912 RFC5913 Clearance Attribute and Authority Clearance Constraints Certificate Extension S. Turner S. Chokhani June 2010 ASCII HTML 19 x.509 certificate

This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates. The Clearance attribute is used to indicate the clearance held by the subject. The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate. The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), in Certification Authority (CA) public key certificates, and in an Attribute Authority (AA) public key certificate in a certification path for a given subject constrain the effective Clearance of the subject. [STANDARDS-TRACK]

 draft-ietf-pkix-authorityclearanceconstraints-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5913 10.17487/RFC5913 RFC5914 Trust Anchor Format R. Housley S. Ashmore C. Wallace June 2010 ASCII HTML 14 trust anchor management

This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented by a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative. The structures defined in this document are intended to satisfy the format-related requirements defined in Trust Anchor Management Requirements. [STANDARDS-TRACK]

 draft-ietf-pkix-ta-format-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5914 10.17487/RFC5914 RFC5915 Elliptic Curve Private Key Structure S. Turner D. Brown June 2010 ASCII HTML 7 ec Standards for Efficient Cryptography Group SECG

This document specifies the syntax and semantics for conveying Elliptic Curve (EC) private key information. The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-ecprivatekey-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5915 10.17487/RFC5915 RFC5916 Device Owner Attribute S. Turner June 2010 ASCII HTML 6

This document defines the Device Owner attribute. It indicates the entity (e.g., company, organization, department, agency) that owns the device. This attribute may be included in public key certificates and attribute certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-deviceowner-attribute-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5916 RFC5917 Clearance Sponsor Attribute S. Turner June 2010 ASCII HTML 7

This document defines the clearance sponsor attribute. It indicates the entity that sponsored (i.e., granted) the clearance. This attribute is intended for use in public key certificates and attribute certificates that also include the clearance attribute. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-clearancesponsor-attribute-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5917 10.17487/RFC5917 RFC5918 Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) R. Asati I. Minei B. Thomas August 2010 ASCII HTML 10 Wildcard Typed Wildcard FEC Element Typed Wildcard FEC Capability

The Label Distribution Protocol (LDP) specification for the Wildcard Forward Equivalence Class (FEC) element has several limitations. This document addresses those limitations by defining a Typed Wildcard FEC Element and associated procedures. In addition, it defines a new LDP capability to address backward compatibility. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-typed-wildcard-07 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5918 10.17487/RFC5918 RFC5919 Signaling LDP Label Advertisement Completion R. Asati P. Mohapatra E. Chen B. Thomas August 2010 ASCII HTML 9 label distribution protocol End-of-LIB Unrecognized Notification

There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-end-of-lib-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5919 10.17487/RFC5919 RFC5920 Security Framework for MPLS and GMPLS Networks L. Fang Editor July 2010 ASCII HTML 66

This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-mpls-and-gmpls-security-framework-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5920 RFC5921 A Framework for MPLS in Transport Networks M. Bocci Editor S. Bryant Editor D. Frost Editor L. Levrau L. Berger July 2010 ASCII HTML 56 multiprotocol label switching mpls-tp transport profile oam itu-t

This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP.

This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-framework-12 RFC6215 RFC7274 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5921 RFC5922 Domain Certificates in the Session Initiation Protocol (SIP) V. Gurbani S. Lawrence A. Jeffrey June 2010 ASCII HTML 17 PKIX Authentication Mutual Authentication X.509 TLS

This document describes how to construct and interpret certain information in a PKIX-compliant (Public Key Infrastructure using X.509) certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of certificates. [STANDARDS-TRACK]

 draft-ietf-sip-domain-certs-07 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5922 RFC5923 Connection Reuse in the Session Initiation Protocol (SIP) V. Gurbani Editor R. Mahy B. Tate June 2010 ASCII HTML 19 TCP Connection SCTP Connection TLS Connection Transport Connection TLS Virtual Server Authentication

This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forwards and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through Transport Layer Security (TLS). For this reason, we only consider connection reuse for TLS over TCP and TLS over Stream Control Transmission Protocol (SCTP). This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. [STANDARDS-TRACK]

 draft-ietf-sip-connect-reuse-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5923 10.17487/RFC5923 RFC5924 Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates S. Lawrence V. Gurbani June 2010 ASCII HTML 8 PKIX SIP Domain X.509 Certificate

This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-sip-eku-08 EXPERIMENTAL EXPERIMENTAL IETF rai sip 10.17487/RFC5924 RFC5925 The TCP Authentication Option J. Touch A. Mankin R. Bonica June 2010 ASCII HTML 48 transmission control protocol border gateway protocol transmission control message digest algorithm

This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]

 draft-ietf-tcpm-tcp-auth-opt-11 RFC2385 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=5925 10.17487/RFC5925 RFC5926 Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) G. Lebovitz E. Rescorla June 2010 ASCII HTML 15 transmission control protocol

The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs). [STANDARDS-TRACK]

 draft-ietf-tcpm-tcp-ao-crypto-03 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=5926 10.17487/RFC5926 RFC5927 ICMP Attacks against TCP F. Gont July 2010 ASCII HTML 36 vulnerability blind attacks connection-reset attack performance-degrading attack throughput-reduction attack source quench PMTUD Path-MTU Discovery ICMP Destination Unreachable

This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-tcpm-icmp-attacks-12 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC5927 RFC5928 Traversal Using Relays around NAT (TURN) Resolution Mechanism M. Petit-Huguenin August 2010 ASCII HTML 11 NAT Traversal

This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation. [STANDARDS-TRACK]

 draft-ietf-behave-turn-uri-10 RFC7350 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC5928 RFC5929 Channel Bindings for TLS J. Altman N. Williams L. Zhu July 2010 ASCII HTML 15 TLS channel binding channel-binding tls-unique tls-server-end-point tls-unique-for-telnet

This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding).

Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. [STANDARDS-TRACK]

 draft-altman-tls-channel-bindings-10 RFC9266 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5929 RFC5930 Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol S. Shen Y. Mao NSS. Murthy July 2010 ASCII HTML 6 initialization vector IKE_SA_INIT

This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit Initialization Vector, by the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ipsecme-aes-ctr-ikev2-07 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC5930 RFC5931 Extensible Authentication Protocol (EAP) Authentication Using Only a Password D. Harkins G. Zorn August 2010 ASCII HTML 40 Password Authenticated Key Exchange Dictionary Attack Authentication EAP

This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-harkins-emu-eap-pwd-14 RFC8146 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5931 10.17487/RFC5931 RFC5932 Camellia Cipher Suites for TLS A. Kato M. Kanda S. Kanno June 2010 ASCII HTML 6 block cipher security camellia tls cbc sha2 camellia encryption algorithm

This document specifies a set of cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. It amends the cipher suites originally specified in RFC 4132 by introducing counterparts using the newer cryptographic hash algorithms from the SHA-2 family. This document obsoletes RFC 4132. [STANDARDS-TRACK]

 draft-kato-tls-rfc4132bis-05 RFC4132 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5932 RFC5933 Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC V. Dolmatov Editor A. Chuprina I. Ustinov July 2010 ASCII HTML 9 domain name system security extensions ECC

This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-gost-07 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5933 RFC5934 Trust Anchor Management Protocol (TAMP) R. Housley S. Ashmore C. Wallace August 2010 ASCII HTML 91 trust anchors TA

This document describes a transport independent protocol for the management of trust anchors (TAs) and community identifiers stored in a trust anchor store. The protocol makes use of the Cryptographic Message Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication. The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate, or TrustAnchorInfo objects. [STANDARDS-TRACK]

 draft-ietf-pkix-tamp-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5934 10.17487/RFC5934 RFC5935 Expressing SNMP SMI Datatypes in XML Schema Definition Language M. Ellison B. Natale August 2010 ASCII HTML 14 structure of management information

This memo defines the IETF standard expression of Structure of Management Information (SMI) base datatypes in XML Schema Definition (XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. [STANDARDS-TRACK]

 draft-ietf-opsawg-smi-datatypes-in-xsd-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=5935 10.17487/RFC5935 RFC5936 DNS Zone Transfer Protocol (AXFR) E. Lewis A. Hoenes Editor June 2010 ASCII HTML 29 authoritative transfer AXFR mechanism

The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035.

The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. [STANDARDS-TRACK]

 draft-ietf-dnsext-axfr-clarify-14 RFC1034 RFC1035 RFC9103 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5936 RFC5937 Using Trust Anchor Constraints during Certification Path Processing S. Ashmore C. Wallace August 2010 ASCII HTML 8 TA

This document describes how to use information associated with a trust anchor public key when validating certification paths. This information can be used to constrain the usage of a trust anchor. Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-wallace-using-ta-constraints-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5937 RFC5938 Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) A. Morton M. Chiba August 2010 ASCII HTML 17

The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol. This memo describes an OPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions that were previously requested and accepted to start and stop at the same time. [STANDARDS-TRACK]

 draft-ietf-ippm-twamp-session-cntrl-07 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=5938 10.17487/RFC5938 RFC5939 Session Description Protocol (SDP) Capability Negotiation F. Andreasen September 2010 ASCII HTML 77 multimedia session session announcement session invitation

The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation; however, over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g., RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as Secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation.

The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner.

The document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents. [STANDARDS-TRACK]

 draft-ietf-mmusic-sdp-capability-negotiation-13 RFC6871 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5939 10.17487/RFC5939 RFC5940 Additional Cryptographic Message Syntax (CMS) Revocation Information Choices S. Turner R. Housley August 2010 ASCII HTML 9 online certificate status protocol ocsp server-based certificate validation protocol scvp

The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData, AuthenticatedData, and AuthEnvelopedData content types. The preferred format for revocation information is the Certificate Revocation List (CRL), but an extension mechanism supports other revocation information formats. This document defines two additional revocation information formats for Online Certificate Status Protocol (OCSP) responses and Server-Based Certificate Validation Protocol (SCVP) requests and responses. [STANDARDS-TRACK]

 draft-turner-additional-cms-ri-choices-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5940 10.17487/RFC5940 RFC5941 Sharing Transaction Fraud Data D. M'Raihi S. Boeyen M. Grandcolas S. Bajaj August 2010 ASCII HTML 27 thraud incident object description exchange format iodef

This document describes a document format for exchanging transaction fraud (Thraud) information. It extends the Incident Handling Working Group (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mraihi-inch-thraud-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5941 RFC5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes H. Singh W. Beebee E. Nordmark July 2010 ASCII HTML 11

IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference: that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of "on-link" from RFC 4861. [STANDARDS-TRACK]

 draft-ietf-6man-ipv6-subnet-model-12 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=5942 10.17487/RFC5942 RFC5943 A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing B. Haberman Editor August 2010 ASCII HTML 4

The deployment of new IP connectivity typically results in intermittent reachability for numerous reasons that are outside the scope of this document. In order to aid in the debugging of these persistent problems, this document proposes the creation of a new Routing Policy Specification Language attribute that allows a network to advertise an IP address that is reachable and can be used as a target for diagnostic tests (e.g., pings). [STANDARDS-TRACK]

 draft-haberman-rpsl-reachable-test-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5943 RFC5944 IP Mobility Support for IPv4, Revised C. Perkins Editor November 2010 ASCII HTML 100 MOBILEIPSUPIP Internet Protocol MIPv4

This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS-TRACK]

 draft-ietf-mip4-rfc3344bis-10 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=5944 10.17487/RFC5944 RFC5945 Resource Reservation Protocol (RSVP) Proxy Approaches F. Le Faucheur J. Manner D. Wing A. Guillou October 2010 ASCII HTML 50

The Resource Reservation Protocol (RSVP) can be used to make end-to- end resource reservations in an IP network in order to guarantee the quality of service required by certain flows. RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. This document presents RSVP proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on a critical subset of the end-to-end path. This document reviews conceptual approaches for deploying RSVP proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP proxy are described. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-tsvwg-rsvp-proxy-approaches-09 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC5945 RFC5946 Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy F. Le Faucheur J. Manner A. Narayanan A. Guillou H. Malik October 2010 ASCII HTML 35

Resource Reservation Protocol (RSVP) signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the Quality of Service (QoS) required by certain flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP- capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to- end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document "RSVP Proxy Approaches", RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions. [STANDARDS-TRACK]

 draft-ietf-tsvwg-rsvp-proxy-proto-11 RFC2205 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5946 RFC5947 Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP) J. Elwell H. Kaplan September 2010 ASCII HTML 13 Trunking pbx private branch exchange

This document states requirements for a standardized SIP registration mechanism for multiple addresses of record (AORs), the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges (PBXs). The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-martini-reqs-09 INFORMATIONAL INFORMATIONAL IETF rai martini 10.17487/RFC5947 RFC5948 Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16 S. Madanapalli S. Park S. Chakrabarti G. Montenegro August 2010 ASCII HTML 13 packet cs

IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service-specific Convergence Sublayers for transmitting upper-layer protocols. The Packet CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as the Internet Protocol (IP) and IEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 Media Access Control (MAC) layer.

This document specifies the frame format, the Maximum Transmission Unit (MTU), and the address assignment procedures for transmitting IPv4 packets over the IP-specific part of the Packet Convergence Sublayer of IEEE 802.16. [STANDARDS-TRACK]

 draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-07 PROPOSED STANDARD PROPOSED STANDARD IETF int 16ng 10.17487/RFC5948 RFC5949 Fast Handovers for Proxy Mobile IPv6 H. Yokota K. Chowdhury R. Koodli B. Patil F. Xia September 2010 ASCII HTML 32 PFMIPv6 handoff PMIPv6 predictive reactive

Mobile IPv6 (MIPv6; RFC 3775) provides a mobile node with IP mobility when it performs a handover from one access router to another, and fast handovers for Mobile IPv6 (FMIPv6) are specified to enhance the handover performance in terms of latency and packet loss. While MIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6; RFC 5213) provides IP mobility to nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered no different from that of MIPv6.

When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network-based mobility management. This document specifies the usage of fast handovers for Mobile IPv6 (FMIPv6; RFC 5568) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations. [STANDARDS-TRACK]

 draft-ietf-mipshop-pfmipv6-14 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5949 RFC5950 Network Management Framework for MPLS-based Transport Networks S. Mansfield Editor E. Gray Editor K. Lam Editor September 2010 ASCII HTML 18 mpls-tp network management framework

This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP).

This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network.

The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-nm-framework-05 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5950 RFC5951 Network Management Requirements for MPLS-based Transport Networks K. Lam S. Mansfield E. Gray September 2010 ASCII HTML 24 MPLS Transport Profile mpls-tp

This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS Transport Profile is constructed. That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-nm-req-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5951 10.17487/RFC5951 RFC5952 A Recommendation for IPv6 Address Text Representation S. Kawamura M. Kawashima August 2010 ASCII HTML 14 IPv6 text representation canonical

As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK]

 draft-ietf-6man-text-addr-representation-07 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=5952 10.17487/RFC5952 RFC5953 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) W. Hardaker August 2010 ASCII HTML 65 dtls datagram transport layer security tls transport model tlstm SNMP-TLS-TM-MIB

This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way.

This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.

This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]

 draft-ietf-isms-dtls-tm-14 RFC6353 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms http://www.rfc-editor.org/errata_search.php?rfc=5953 10.17487/RFC5953 RFC5954 Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261 V. Gurbani Editor B. Carpenter Editor B. Tate Editor August 2010 ASCII HTML 7 SIP session initiation protocol Augmented Backus-Naur Form Uniform Resource Identifier IPv6reference IPv6address

This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. [STANDARDS-TRACK]

 draft-ietf-sip-ipv6-abnf-fix-05 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5954 10.17487/RFC5954 RFC5955 The application/timestamped-data Media Type A. Santoni August 2010 ASCII HTML 3 TimeStampedData envelopes

This document defines a new media type for TimeStampedData envelopes as described in RFC 5544. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-santoni-media-type-tsd-00 RFC5544 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5955 RFC5956 Forward Error Correction Grouping Semantics in the Session Description Protocol A. Begen September 2010 ASCII HTML 14 FEC loss repair grouping sdp media lines

This document defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework (RFC 5888). These semantics allow the description of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for Real-time Transport Protocol (RTP) streams using SSRC multiplexing. [STANDARDS-TRACK]

 draft-ietf-mmusic-rfc4756bis-10 RFC4756 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5956 RFC5957 Display-Based Address Sorting for the IMAP4 SORT Extension D. Karp July 2010 ASCII HTML 5 Internet Message Access Protocol

This document describes an IMAP protocol extension enabling server- side message sorting on the commonly displayed portion of the From and To header fields. [STANDARDS-TRACK]

 draft-ietf-morg-sortdisplay-03 RFC5256 PROPOSED STANDARD PROPOSED STANDARD IETF app morg 10.17487/RFC5957 RFC5958 Asymmetric Key Packages S. Turner August 2010 ASCII HTML 14 private key private-key information rsa laboratories private-key syntax change control

This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK]

 draft-turner-asymmetrickeyformat-05 RFC5208 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5958 10.17487/RFC5958 RFC5959 Algorithms for Asymmetric Key Package Content Type S. Turner August 2010 ASCII HTML 7 EncryptedPrivateKeyInfo AsymmetricKeyPackage

This document describes the conventions for using several cryptographic algorithms with the EncryptedPrivateKeyInfo structure, as defined in RFC 5958. It also includes conventions necessary to protect the AsymmetricKeyPackage content type with SignedData, EnvelopedData, EncryptedData, AuthenticatedData, and AuthEnvelopedData. [STANDARDS-TRACK]

 draft-turner-asymmetrickeyformat-algs-01 RFC6162 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5959 RFC5960 MPLS Transport Profile Data Plane Architecture D. Frost Editor S. Bryant Editor M. Bocci Editor August 2010 ASCII HTML 15 mpls-tp transport profile itu-t dataplane gal gach

The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-data-plane-04 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5960 10.17487/RFC5960 RFC5961 Improving TCP's Robustness to Blind In-Window Attacks A. Ramaiah R. Stewart M. Dalal August 2010 ASCII HTML 19 RST SYN FIN attack Data Injection vulnerability blind attacks BGP spoof mitigation

TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 or Border Gateway Protocol (BGP) [STANDARDS-TRACK]

 draft-ietf-tcpm-tcpsecure-13 RFC9293 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=5961 10.17487/RFC5961 RFC5962 Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO) H. Schulzrinne V. Singh H. Tschofenig M. Thomson September 2010 ASCII HTML 11 PIDF-LO,location,dynamic,speed,velocity,orientation

The Geopriv Location Object introduced by the Presence Information Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information of a presentity. This document defines PIDF-LO extensions to convey information about moving objects. Elements are defined that enable expression of spatial orientation, speed, and heading of the presentity. [STANDARDS TRACK]

 draft-singh-geopriv-pidf-lo-dynamic-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5962 RFC5963 IPv6 Deployment in Internet Exchange Points (IXPs) R. Gagliano August 2010 ASCII HTML 10 IPv6 IXP deployment exchange

This document provides guidance on IPv6 deployment in Internet Exchange Points (IXPs). It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks that need to be performed. IXPs are mainly a Layer 2 infrastructure, and, in many cases, the best recommendations suggest that the IPv6 data, control, and management plane should not be handled differently than in IPv4. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-v6inixp-09 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5963 RFC5964 Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries J. Winterbottom M. Thomson August 2010 ASCII HTML 11 hole polygon pidf-lo service boundary location LoST

This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a Location-to- Service Translation (LoST) server, is described. [STANDARDS-TRACK]

 draft-ietf-ecrit-specifying-holes-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC5964 RFC5965 An Extensible Format for Email Feedback Reports Y. Shafranovich J. Levine M. Kucherawy August 2010 ASCII HTML 25 feedback-report

This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. [STANDARDS-TRACK]

 draft-ietf-marf-base-06 RFC6650 PROPOSED STANDARD PROPOSED STANDARD IETF app marf http://www.rfc-editor.org/errata_search.php?rfc=5965 10.17487/RFC5965 RFC5966 DNS Transport over TCP - Implementation Requirements R. Bellis August 2010 ASCII HTML 7 DNS TCP/IP

This document updates the requirements for the support of TCP as a transport protocol for DNS implementations. [STANDARDS-TRACK]

 draft-ietf-dnsext-dns-tcp-requirements-03 RFC7766 RFC1035 RFC1123 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5966 RFC5967 The application/pkcs10 Media Type S. Turner August 2010 ASCII HTML 6

This document specifies a media type used to carry PKCS #10 certification requests as defined in RFC 2986. It carries over the original specification from RFC 2311, which recently has been moved to Historic status, and properly links it to RFC 2986. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-application-pkcs10-media-type-05 RFC2986 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5967 RFC5968 Guidelines for Extending the RTP Control Protocol (RTCP) J. Ott C. Perkins September 2010 ASCII HTML 17 real-time transport protocol

The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptation and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-avt-rtcp-guidelines-04 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC5968 RFC5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification W. Townsley O. Troan August 2010 ASCII HTML 18 6rd Provider 6to4 IPv6 softwire IPv6 Transition 6to4

This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service, which is equivalent to native IPv6 at the sites that are served by the mechanism. [STANDARDS-TRACK]

 draft-ietf-softwire-ipv6-6rd-10 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=5969 10.17487/RFC5969 RFC5970 DHCPv6 Options for Network Boot T. Huth J. Freimann V. Zimmer D. Thaler September 2010 ASCII HTML 11 boot IPv6 DHCPv6

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 that SHOULD be used for booting a node from the network. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-opt-netboot-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5970 RFC5971 GIST: General Internet Signalling Transport H. Schulzrinne R. Hancock October 2010 ASCII HTML 154 nsis next steps in signaling

This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-ntlp-20 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5971 RFC5972 General Internet Signaling Transport (GIST) State Machine T. Tsenov H. Tschofenig X. Fu Editor C. Aoun E. Davies October 2010 ASCII HTML 27 draft-ietf-nsis-ntlp-statemachine-10 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC5972 RFC5973 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) M. Stiemerling H. Tschofenig C. Aoun E. Davies October 2010 ASCII HTML 90 Next Steps in Signaling NSIS Path-coupled signaling Middlebox

This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-nslp-natfw-25 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5973 RFC5974 NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling J. Manner G. Karagiannis A. McDonald October 2010 ASCII HTML 102 QoS

This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with General Internet Signaling Transport (GIST), it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, describes the design decisions made, and provides examples. It specifies object, message formats, and processing rules. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-qos-nslp-18 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5974 RFC5975 QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP) G. Ash Editor A. Bader Editor C. Kappler Editor D. Oran Editor October 2010 ASCII HTML 64

The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models. The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-qspec-24 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5975 RFC5976 Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes G. Ash A. Morton M. Dolly P. Tarapore C. Dvorak Y. El Mghazli October 2010 ASCII HTML 19 qos-nslp qos-nslp quality-of-service model qspec

This document describes a QoS-NSLP Quality-of-Service model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related guidance on signaling. Y.1541 specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-y1541-qosm-10 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5976 RFC5977 RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv A. Bader L. Westberg G. Karagiannis C. Kappler T. Phelan October 2010 ASCII HTML 128 next steps in signaling resource managment in diffserv

This document describes a Next Steps in Signaling (NSIS) Quality-of-Service (QoS) Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to Edge nodes in the RMD network. The RMD Ingress Edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress Edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the Edge nodes. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-rmd-20 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5977 RFC5978 Using and Extending the NSIS Protocol Family J. Manner R. Bless J. Loughney E. Davies Editor October 2010 ASCII HTML 30 Signaling NTLP NSLP GIST QoS NSLP NAT/Firewall NSLP IP resources Extensibility

This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS Working Group during the period of 2001-2010. It also includes suggestions on how the industry can make use of the new protocols and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-nsis-ext-07 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC5978 RFC5979 NSIS Operation over IP Tunnels C. Shen H. Schulzrinne S. Lee J. Bang March 2011 ASCII HTML 27 nsis qos next steps in signaling

NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments. Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to corresponding QoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-tunnel-13 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5979 RFC5980 NSIS Protocol Operation in Mobile Environments T. Sanda Editor X. Fu S. Jeong J. Manner H. Tschofenig March 2011 ASCII HTML 32

Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This document discusses the effects mobility can cause to the Next Steps in Signaling (NSIS) protocol suite, and shows how the NSIS protocols operate in different scenarios with mobility management protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-nsis-applicability-mobility-signaling-20 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC5980 RFC5981 Authorization for NSIS Signaling Layer Protocols J. Manner M. Stiemerling H. Tschofenig R. Bless Editor February 2011 ASCII HTML 37 Next Steps in Signaling gist General Internet Signaling Transport

Signaling layer protocols specified within the Next Steps in Signaling (NSIS) framework may rely on the General Internet Signaling Transport (GIST) protocol to handle authorization. Still, the signaling layer protocol above GIST itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This document presents a generic model and object formats for session authorization within the NSIS signaling layer protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-nslp-auth-07 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis http://www.rfc-editor.org/errata_search.php?rfc=5981 10.17487/RFC5981 RFC5982 IP Flow Information Export (IPFIX) Mediation: Problem Statement A. Kobayashi Editor B. Claise Editor August 2010 ASCII HTML 25 flow-based measurement

Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IP Flow Information Export (IPFIX) Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then it describes IPFIX Mediation applicability examples along with the problems. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ipfix-mediators-problem-statement-09 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC5982 RFC5983 Mailing Lists and Internationalized Email Addresses R. Gellens October 2010 ASCII HTML 10

This document describes considerations for mailing lists with the introduction of internationalized email addresses.

This document makes some specific recommendations on how mailing lists should act in various situations. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-eai-mailinglist-07 RFC6783 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5983 RFC5984 Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding K-M. Moller April 1 2011 ASCII HTML 9 extra sensory perception

This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding. This document defines an Experimental Protocol for the Internet community.

 draft-moller-esp-based-forwarding-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5984 10.17487/RFC5984 RFC5985 HTTP-Enabled Location Delivery (HELD) M. Barnes Editor September 2010 ASCII HTML 39 layer 7 location configuration protocol l7 lcp

This document defines a Layer 7 Location Configuration Protocol (L7 LCP) and describes the use of HTTP and HTTP/TLS as transports for the L7 LCP. The L7 LCP is used for retrieving location information from a server within an access network. It includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of the session layer. [STANDARDS-TRACK]

 draft-ietf-geopriv-http-location-delivery-16 RFC7840 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC5985 RFC5986 Discovering the Local Location Information Server (LIS) M. Thomson J. Winterbottom September 2010 ASCII HTML 16 u-naptr uri-enabled naptr

Discovery of the correct Location Information Server (LIS) in the local access network is necessary for Devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a Device. Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process. [STANDARDS-TRACK]

 draft-ietf-geopriv-lis-discovery-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5986 10.17487/RFC5986 RFC5987 Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters J. Reschke August 2010 ASCII HTML 10 HTTP header field parameter internationalization

By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO- 8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231. [STANDARDS-TRACK]

 draft-reschke-rfc2231-in-http-12 RFC8187 HISTORIC PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5987 RFC5988 Web Linking M. Nottingham October 2010 ASCII HTML 23 Link linking http header link relation web

This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]

 draft-nottingham-http-link-header-10 RFC8288 RFC4287 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5988 10.17487/RFC5988 RFC5989 A SIP Event Package for Subscribing to Changes to an HTTP Resource A.B. Roach October 2010 ASCII HTML 19 Link Relations Syndication Atom

The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near real- time, when a specific HTTP resource is created, changed, or deleted. This document proposes a mechanism, based on the SIP Event Framework, for doing so. [STANDARDS-TRACK]

 draft-roach-sip-http-subscribe-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5989 RFC5990 Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS) J. Randall B. Kaliski J. Brainard S. Turner September 2010 ASCII HTML 27 key encapsulation mechanism generic hybrid cipher

The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. ("KEM" stands for "key encapsulation mechanism".) This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with an expected forthcoming change to American National Standard (ANS) X9.44.

 draft-ietf-smime-cms-rsa-kem-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5990 10.17487/RFC5990 RFC5991 Teredo Security Updates D. Thaler S. Krishnan J. Hoagland September 2010 ASCII HTML 10 teredo ipv6 address

The Teredo protocol defines a set of flags that are embedded in every Teredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backward compatible. [STANDARDS-TRACK]

 draft-krishnan-v6ops-teredo-update-10 RFC4380 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5991 RFC5992 Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic S. Sharikov D. Miloshevic J. Klensin October 2010 ASCII HTML 21 Bosnian and Serbian Bulgarian Byelorussian Belarusian Belarusan Kildin Sami Macedonian Montenegrin Russian Ukrainian

This document is a guideline for registries and registrars on registering internationalized domain names (IDNs) based on (in alphabetical order) Bosnian, Bulgarian, Byelorussian, Kildin Sami, Macedonian, Montenegrin, Russian, Serbian, and Ukrainian languages in a DNS zone. It describes appropriate characters for registration and variant considerations for characters from Greek and Latin scripts with similar appearances and/or derivations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-sharikov-idn-reg-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5992 RFC5993 RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR) X. Duan S. Wang M. Westerlund K. Hellwig I. Johansson October 2010 ASCII HTML 18 speech codec real-time transport protocol

This document specifies the payload format for packetization of Global System for Mobile Communications Half Rate (GSM-HR) speech codec data into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-gsm-hr-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5993 RFC5994 Application of Ethernet Pseudowires to MPLS Transport Networks S. Bryant Editor M. Morrow G. Swallow R. Cherukuri T. Nadeau N. Harrison B. Niven-Jenkins October 2010 ASCII HTML 11 mpls-tp

Ethernet pseudowires are widely deployed to support packet transport of Ethernet services. These services in-turn provide transport for a variety of client networks, e.g., IP and MPLS. This document uses procedures defined in the existing IETF specifications of Ethernet pseudowires carried over MPLS networks.

Many of the requirements for the services provided by the mechanisms explained in this document are also recognized by the MPLS transport profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T. The solution described here does not address all of the MPLS-TP requirements, but it provides a viable form of packet transport service using tools that are already available.

This document also serves as an indication that existing MPLS techniques form an appropriate basis for the design of a fully- featured packet transport solution addressing all of the requirements of MPLS-TP. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pwe3-mpls-transport-04 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5994 10.17487/RFC5994 RFC5995 Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections J. Reschke September 2010 ASCII HTML 12 HTTP POST WebDAV Collections Collection Members

The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST".

This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. In fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols, such as the Calendaring Extensions to WebDAV (CalDAV), frequently require clients to pick a unique URL, although the server could easily perform that task.

This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics. [STANDARDS-TRACK]

 draft-reschke-webdav-post-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5995 RFC5996 Internet Key Exchange Protocol Version 2 (IKEv2) C. Kaufman P. Hoffman Y. Nir P. Eronen September 2010 ASCII HTML 138 IKE IPsec

This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. [STANDARDS-TRACK]

 draft-ietf-ipsecme-ikev2bis-11 RFC4306 RFC4718 RFC7296 RFC5998 RFC6989 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=5996 10.17487/RFC5996 RFC5997 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol A. DeKok August 2010 ASCII HTML 24 status-server

This document describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-radext-status-server-09 RFC2866 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5997 10.17487/RFC5997 RFC5998 An Extension for EAP-Only Authentication in IKEv2 P. Eronen H. Tschofenig Y. Sheffer September 2010 ASCII HTML 16 mutual authentication password credentials AAA key agreement channel binding

IKEv2 specifies that Extensible Authentication Protocol (EAP) authentication must be used together with responder authentication based on public key signatures. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one- time passwords or token cards.

This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. [STANDARDS-TRACK]

 draft-ietf-ipsecme-eap-mutual-05 RFC5996 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5998 RFC5999 RFC6000 RFC6001 Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) D. Papadimitriou M. Vigoureux K. Shiomoto D. Brungard JL. Le Roux October 2010 ASCII HTML 24

There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN).

This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer / Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-mln-extensions-12 RFC4202 RFC4203 RFC4206 RFC4874 RFC4974 RFC5307 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6001 RFC6002 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions L. Berger D. Fedyk October 2010 ASCII HTML 10 Generalized Multi-Protocol Label Switching

This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching (GMPLS). The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path (LSP). [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-dcsc-channel-ext-04 RFC3471 RFC3473 RFC3945 RFC4202 RFC4203 RFC5307 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6002 RFC6003 Ethernet Traffic Parameters D. Papadimitriou October 2010 ASCII HTML 14 mef Metro Ethernet Forum MEF10.1

This document describes the support of Metro Ethernet Forum (MEF) Ethernet traffic parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. [STANDARDS-TRACK]

 draft-ietf-ccamp-ethernet-traffic-parameters-10 RFC3471 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=6003 10.17487/RFC6003 RFC6004 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching L. Berger D. Fedyk October 2010 ASCII HTML 15 Generalized Multi-Protocol Label Switching Metro Ethernet Forum MEF draft-ietf-ccamp-gmpls-ether-svcs-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6004 RFC6005 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI) L. Berger D. Fedyk October 2010 ASCII HTML 10 mef itu International Telecommunication Union i-nni internal nni

This document describes a method for controlling two specific types of Ethernet switching via a GMPLS-based User Network Interface (UNI). This document supports the types of switching required by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. [STANDARDS- TRACK]

 draft-ietf-ccamp-gmpls-mef-uni-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6005 RFC6006 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Q. Zhao Editor D. King Editor F. Verhaeghe T. Takeda Z. Ali J. Meuric September 2010 ASCII HTML 33 END-POINTS fragmentation

Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.

This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. [STANDARDS-TRACK]

 draft-ietf-pce-pcep-p2mp-extensions-11 RFC8306 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=6006 10.17487/RFC6006 RFC6007 Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations I. Nishioka D. King September 2010 ASCII HTML 18

A Path Computation Element (PCE) may be required to perform dependent path computations. Dependent path computations are requests that need to be synchronized in order to meet specific objectives. An example of a dependent request would be a PCE computing a set of services that are required to be diverse (disjointed) from each other. When a PCE computes sets of dependent path computation requests concurrently, use of the Synchronization VECtor (SVEC) list is required for association among the sets of dependent path computation requests. The SVEC object is optional and carried within the Path Computation Element Communication Protocol (PCEP) PCRequest (PCReq) message.

This document does not specify the PCEP SVEC object or procedure. This informational document clarifies the use of the SVEC list for synchronized path computations when computing dependent requests. The document also describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pce-pcep-svec-list-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC6007 RFC6008 Authentication-Results Registration for Differentiating among Cryptographic Results M. Kucherawy September 2010 ASCII HTML 7 DKIM DomainKeys SenderID SPF Authentication Reputation

This memo updates the registry of properties in Authentication- Results: message header fields to allow a multiple-result report to distinguish among one or more cryptographic signatures on a message, thus associating specific results with the signatures they represent. [STANDARDS-TRACK]

 draft-kucherawy-authres-header-b-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6008 RFC6009 Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions N. Freed October 2010 ASCII HTML 15 SMTP ESMTP Sieve

This document describes the "envelope-dsn", "redirect-dsn", "envelope-deliverby", and "redirect-deliverby" extensions to the Sieve email filtering language. The "envelope-dsn" and "envelope- deliverby" extensions provide access to additional envelope information provided by the delivery status notification (DSN) and Deliver-By SMTP extensions, respectively. The "redirect-dsn" and "redirect-deliverby" extensions extend Sieve's redirect action to provide control over delivery status notification and Deliver-By parameters, respectively. [STANDARDS-TRACK]

 draft-freed-sieve-notary-09 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=6009 10.17487/RFC6009 RFC6010 Cryptographic Message Syntax (CMS) Content Constraints Extension R. Housley S. Ashmore C. Wallace September 2010 ASCII HTML 38 authorization PKI certificate trust anchor TAMP,

This document specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints extension. This extension is used to determine whether a public key is appropriate to use in the processing of a protected content. In particular, the CMS content constraints extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this extension indicates the content types that the public key is authorized to validate. If the authorization check is successful, the CMS content constraints extension also provides default values for absent attributes. [STANDARDS-TRACK]

 draft-housley-cms-content-constraints-extn-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6010 10.17487/RFC6010 RFC6011 Session Initiation Protocol (SIP) User Agent Configuration S. Lawrence Editor J. Elwell October 2010 ASCII HTML 29 HTTP DHCP DHCPv6

This document defines procedures for how a SIP User Agent should locate, retrieve, and maintain current configuration information from a Configuration Service. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-lawrence-sipforum-user-agent-config-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6011 10.17487/RFC6011 RFC6012 Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog J. Salowey T. Petch R. Gerhards H. Feng October 2010 ASCII HTML 12 TLS

This document describes the transport of syslog messages over the Datagram Transport Layer Security (DTLS) protocol. It provides a secure transport for syslog messages in cases where a connectionless transport is desired. [STANDARDS-TRACK]

 draft-ietf-syslog-dtls-06 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC6012 RFC6013 TCP Cookie Transactions (TCPCT) W. Simpson January 2011 ASCII HTML 37

TCP Cookie Transactions (TCPCT) deter spoofing of connections and prevent resource exhaustion, eliminating Responder (server) state during the initial handshake. The Initiator (client) has sole responsibility for ensuring required delays between connections. The cookie exchange may carry data, limited to inhibit amplification and reflection denial of service attacks. This document defines an Experimental Protocol for the Internet community.

 draft-simpson-tcpct-03 RFC7805 HISTORIC EXPERIMENTAL INDEPENDENT 10.17487/RFC6013 RFC6014 Cryptographic Algorithm Identifier Allocation for DNSSEC P. Hoffman November 2010 ASCII HTML 6 DNSSEC digital signatures algorithms

This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the requirement from "standard required" to "RFC Required". It does not change the list of algorithms that are recommended or required for DNSSEC implementations. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-alg-allocation-03 RFC4033 RFC4034 RFC4035 RFC9157 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6014 RFC6015 RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC) A. Begen October 2010 ASCII HTML 31 FEC interleaving loss repair loss protection DVB AL-FEC

This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of reasonable complexity. The new payload format defined in this document should only be used (with some exceptions) as a part of the Digital Video Broadcasting-IPTV (DVB- IPTV) Application-layer FEC specification. [STANDARDS-TRACK]

 draft-ietf-fecframe-interleaved-fec-scheme-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6015 RFC6016 Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs B. Davie F. Le Faucheur A. Narayanan October 2010 ASCII HTML 38 l3vpn

RFC 4364 and RFC 4659 define an approach to building provider-provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6. It may be desirable to use Resource Reservation Protocol (RSVP) to perform admission control on the links between Customer Edge (CE) routers and Provider Edge (PE) routers. This document specifies procedures by which RSVP messages traveling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported. [STANDARDS-TRACK]

 draft-ietf-tsvwg-rsvp-l3vpn-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6016 10.17487/RFC6016 RFC6017 Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field K. Meadors Editor September 2010 ASCII HTML 5 EDIINT-Features

With the maturity of the Electronic Data Interchange - Internet Integration (EDIINT) standards of AS1, AS2, and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by all EDIINT applications and could cause potential problems with implementations. The EDIINT-Features header field provides a means to resolve these problems and support new functionality. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-meadors-ediint-features-header-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6017 RFC6018 IPv4 and IPv6 Greynets F. Baker W. Harrop G. Armitage September 2010 ASCII HTML 9 darknets

This note discusses a feature to support building Greynets for IPv4 and IPv6. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-baker-v6ops-greynet-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6018 RFC6019 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 R. Housley September 2010 ASCII HTML 6 signing-time attribute cryptographic message syntax cms SignedData AuthenticatedData

This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax (CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 5652. [STANDARDS-TRACK]

 rfc4049bis RFC4049 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6019 RFC6020 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) M. Bjorklund Editor October 2010 ASCII HTML 173 NETCONF XML data modelling

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]

 draft-ietf-netmod-yang-13 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6020 10.17487/RFC6020 RFC6021 Common YANG Data Types J. Schoenwaelder Editor October 2010 ASCII HTML 26 YANG NETCONF

This document introduces a collection of common data types to be used with the YANG data modeling language. [STANDARDS-TRACK]

 draft-ietf-netmod-yang-types-09 RFC6991 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC6021 RFC6022 YANG Module for NETCONF Monitoring M. Scott M. Bjorklund October 2010 ASCII HTML 28 XML NETCONF YANG monitoring

This document defines a Network Configuration Protocol (NETCONF) data model to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF <get-schema> operation to retrieve them. [STANDARDS-TRACK]

 draft-ietf-netconf-monitoring-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6022 10.17487/RFC6022 RFC6023 A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA) Y. Nir H. Tschofenig H. Deng R. Singh October 2010 ASCII HTML 7

This document describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association (SA) to be created and authenticated without generating a Child SA. This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

 draft-nir-ipsecme-childless-06 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6023 RFC6024 Trust Anchor Management Requirements R. Reddy C. Wallace October 2010 ASCII HTML 14 PKI certificates digital signatures

A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pkix-ta-mgmt-reqs-06 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC6024 RFC6025 ASN.1 Translation C. Wallace C. Gardiner October 2010 ASCII HTML 19 Basic Encoding Rules Distinguished Encoding Rules PKIX S/MIME

Abstract Syntax Notation One (ASN.1) is widely used throughout the IETF Security Area and has been for many years. Some specifications were written using a now deprecated version of ASN.1 and some were written using the current version of ASN.1. Not all ASN.1 compilers support both older and current syntax. This document is intended to provide guidance to specification authors and to implementers converting ASN.1 modules from one version of ASN.1 to another version without causing changes to the "bits on the wire". This document does not provide a comprehensive tutorial of any version of ASN.1. Instead, it addresses ASN.1 features that are used in IETF Security Area specifications with a focus on items that vary with the ASN.1 version. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pkix-asn1-translation-03 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC6025 RFC6026 Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests R. Sparks T. Zourzouvillys September 2010 ASCII HTML 20 state machine retransmission

This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (2xx class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. [STANDARDS-TRACK]

 draft-ietf-sipcore-invfix-01 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6026 10.17487/RFC6026 RFC6027 IPsec Cluster Problem Statement Y. Nir October 2010 ASCII HTML 12 IKE IKEv2 high-availability load-sharing failover hot-standby

This document defines the terminology, problem statement, and requirements for implementing Internet Key Exchange (IKE) and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled in order to allow peers to interoperate with clusters from different vendors. Agreed upon terminology, problem statement, and requirements will allow IETF working groups to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ipsecme-ipsec-ha-09 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC6027 RFC6028 Host Identity Protocol (HIP) Multi-Hop Routing Extension G. Camarillo A. Keranen October 2010 ASCII HTML 10 source routing route recording overlay network

This document specifies two extensions to the Host Identity Protocol (HIP) to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a node sending a HIP packet can define a set of nodes that the HIP packet should traverse. The second extension allows a HIP packet to carry and record the list of nodes that forwarded it. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-via-03 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6028 RFC6029 A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem I. Rimac V. Hilt M. Tomsu V. Gurbani E. Marocco October 2010 ASCII HTML 19 Peer-to-Peer topology estimation Internet coordinate system

A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used originally for file sharing, and more recently for real-time communications and live media streaming. Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. This document, a product of the P2P Research Group, presents a survey of existing literature on discovering and using network topology information for Application-Layer Traffic Optimization. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-p2prg-alto-survey-05 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6029 10.17487/RFC6029 RFC6030 Portable Symmetric Key Container (PSKC) P. Hoyer M. Pei S. Machani October 2010 ASCII HTML 58 Symmetric Key provisioning AES 3DES TDES OTP Key transport format key provisioning format symmetric key protection symmetric key transport PIN transport PIN provisioning PIN Policy key usage policy

This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules. For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices. A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. [STANDARDS-TRACK]

 draft-ietf-keyprov-pskc-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec keyprov http://www.rfc-editor.org/errata_search.php?rfc=6030 10.17487/RFC6030 RFC6031 Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type S. Turner R. Housley December 2010 ASCII HTML 29

This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type. [STANDARDS-TRACK]

 draft-ietf-keyprov-symmetrickeyformat-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec keyprov http://www.rfc-editor.org/errata_search.php?rfc=6031 10.17487/RFC6031 RFC6032 Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type S. Turner R. Housley December 2010 ASCII HTML 11 CCC CMS content constraints

This document defines the Cryptographic Message Syntax (CMS) encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package. It is transport independent. CMS can be used to digitally sign, digest, authenticate, or further encrypt this content type. It is designed to be used with the CMS Content Constraints (CCC) extension, which does not constrain the EncryptedData, EnvelopedData, and AuthEnvelopedData. [STANDARDS-TRACK]

 draft-turner-encryptedkeypackagecontenttype-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6032 RFC6033 Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type S. Turner December 2010 ASCII HTML 5

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement EnvelopedData, EncryptedData, and AuthEnvelopedData. [STANDARDS-TRACK]

 draft-turner-encryptedkeypackagecontenttype-algs-02 RFC6161 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6033 RFC6034 Unicast-Prefix-Based IPv4 Multicast Addresses D. Thaler October 2010 ASCII HTML 5 internet protocol

This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol. The extension presented in this document allows for unicast-prefix-based assignment of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. [STANDARDS-TRACK]

 draft-ietf-mboned-ipv4-uni-based-mcast-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC6034 RFC6035 Session Initiation Protocol Event Package for Voice Quality Reporting A. Pendleton A. Clark A. Johnston H. Sinnreich November 2010 ASCII HTML 41 sip Voice over Internet Protocol voip RTP Control Protocol Extended Reports RTCP-XR

This document defines a Session Initiation Protocol (SIP) event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions. Voice call quality information derived from RTP Control Protocol Extended Reports (RTCP-XR) and call information from SIP is conveyed from a User Agent (UA) in a session, known as a reporter, to a third party, known as a collector. A registration for the application/ vq-rtcpxr media type is also included. [STANDARDS-TRACK]

 draft-ietf-sipping-rtcp-summary-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=6035 10.17487/RFC6035 RFC6036 Emerging Service Provider Scenarios for IPv6 Deployment B. Carpenter S. Jiang October 2010 ASCII HTML 23 isp

This document describes practices and plans that are emerging among Internet Service Providers for the deployment of IPv6 services. They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010. This document identifies a number of technology gaps, but it does not make recommendations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-isp-scenarios-00 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=6036 10.17487/RFC6036 RFC6037 Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs E. Rosen Editor Y. Cai Editor IJ. Wijnands October 2010 ASCII HTML 25 mvpn

This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems. The procedures specified in this document are largely a subset of the generalized MVPN framework recently standardized by the IETF. However, as the deployment of the procedures specified herein predates the publication of IETF standards (in some cases by over five years), an implementation based on these procedures differs in some respects from a fully standards-compliant implementation. These differences are pointed out in the document. This document defines a Historic Document for the Internet community.

 draft-rosen-vpn-mcast-15 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC6037 RFC6038 Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features A. Morton L. Ciavattone October 2010 ASCII HTML 18 Testing Performance Metric

This memo describes two closely related features for the core specification of the Two-Way Active Measurement Protocol (TWAMP): an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. [STANDARDS-TRACK]

 draft-ietf-ippm-twamp-reflect-octets-09 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=6038 10.17487/RFC6038 RFC6039 Issues with Existing Cryptographic Protection Methods for Routing Protocols V. Manral M. Bhatia J. Jaeggli R. White October 2010 ASCII HTML 21

Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router.

The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet.

This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-opsec-routing-protocols-crypto-issues-07 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC6039 RFC6040 Tunnelling of Explicit Congestion Notification B. Briscoe November 2010 ASCII HTML 35 Congestion Control and Management Congestion Notification Information Security Tunnelling Encapsulation Decapsulation Protocol ECN IPsec

This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. [STANDARDS-TRACK]

 draft-ietf-tsvwg-ecn-tunnel-10 RFC3168 RFC4301 RFC4774 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6040 RFC6041 Forwarding and Control Element Separation (ForCES) Applicability Statement A. Crouch H. Khosravi A. Doria Editor X. Wang K. Ogawa October 2010 ASCII HTML 14 Routing Control Plane Management Protocol

The Forwarding and Control Element Separation (ForCES) protocol defines a standard framework and mechanism for the interconnection between control elements and forwarding elements in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-forces-applicability-09 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC6041 RFC6042 Transport Layer Security (TLS) Authorization Using KeyNote A. Keromytis October 2010 ASCII HTML 7 trust management authorization access control certificates

This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to guidelines in RFC 5878. Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-keromytis-tls-authz-keynote-07 RFC8996 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6042 RFC6043 MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY) J. Mattsson T. Tian March 2011 ASCII HTML 58 MIKEY MIKEY-TICKET KMS SRTP IMS key management ticket

The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications. In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service. Interest in such deployments is increasing. Therefore, a set of new MIKEY modes that work well in such scenarios are defined. The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos. The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mattsson-mikey-ticket-05 RFC6309 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6043 RFC6044 Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP) M. Mohali October 2010 ASCII HTML 24

Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call-diversion-related information in SIP signaling.

This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. The History-Info header is described in RFC 4244 and the non-standard Diversion header is described, as Historic, in RFC 5806.

Since the Diversion header is used in many existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This work is intended to enable the migration from non- standard implementations and deployment toward IETF specification- based implementations and deployment. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mohali-diversion-history-info-07 RFC7544 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6044 10.17487/RFC6044 RFC6045 Real-time Inter-network Defense (RID) K. Moriarty November 2010 ASCII HTML 75 Coordinated Incident Response CSIRT CIRT IODEF Incident Object Exchange Description Format

Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.

RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter-network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-moriarty-post-inch-rid-12 RFC6545 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6045 10.17487/RFC6045 RFC6046 Transport of Real-time Inter-network Defense (RID) Messages K. Moriarty B. Trammell November 2010 ASCII HTML 7 Coordinate Incident Response CSIRT CIRT IODEF Incident Object Exchange Description Format

The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS (Transport Layer Security). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-moriarty-post-inch-rid-transport-03 RFC6546 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6046 RFC6047 iCalendar Message-Based Interoperability Protocol (iMIP) A. Melnikov Editor December 2010 ASCII HTML 22 IMIP] electronic mail transport itip iCalendar Transport-independent Interoperability Protocol iCalendar Object Model

This document, "iCalendar Message-Based Interoperability Protocol (iMIP)", specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then transported over SMTP. [STANDARDS-TRACK]

 draft-ietf-calsify-rfc2447bis-11 RFC2447 PROPOSED STANDARD PROPOSED STANDARD IETF app calsify http://www.rfc-editor.org/errata_search.php?rfc=6047 10.17487/RFC6047 RFC6048 Network News Transfer Protocol (NNTP) Additions to LIST Command J. Elie November 2010 ASCII HTML 25 Usenet NetNews capabilities

This document defines a set of enhancements to the Network News Transfer Protocol (NNTP) that allow a client to request extended information from NNTP servers regarding server status, policy, and other aspects of local configuration. These enhancements are made as new keywords to the existing LIST capability described in RFC 3977.

This memo updates and formalizes the LIST DISTRIBUTIONS and LIST SUBSCRIPTIONS commands defined in RFC 2980. It also adds the LIST COUNTS, LIST MODERATORS, and LIST MOTD commands, and specifies additional values returned by the existing LIST ACTIVE command for the status of a newsgroup. [STANDARDS-TRACK]

 draft-elie-nntp-list-additions-05 RFC2980 RFC3977 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6048 RFC6049 Spatial Composition of Metrics A. Morton E. Stephan January 2011 ASCII HTML 29 Performance Measurement IPPM

This memo utilizes IP performance metrics that are applicable to both complete paths and sub-paths, and it defines relationships to compose a complete path metric from the sub-path metrics with some accuracy with regard to the actual metrics. This is called "spatial composition" in RFC 2330. The memo refers to the framework for metric composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. [STANDARDS-TRACK]

 draft-ietf-ippm-spatial-composition-16 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC6049 RFC6050 A Session Initiation Protocol (SIP) Extension for the Identification of Services K. Drage November 2010 ASCII HTML 19 SIP trust domain service identifier

This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains or for use in the Internet at large.

The document also defines a URN to identify both services and User Agent (UA) applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-drage-sipping-service-identification-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6050 RFC6051 Rapid Synchronisation of RTP Flows C. Perkins T. Schierl November 2010 ASCII HTML 22 rtcp rtp control protocol mcu multipoint conference units ssm source-specific multicast

This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs.

This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. Second, a new feedback packet is defined for use with the extended RTP profile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp-based decoding order recovery for layered codecs in the presence of clock skew. [STANDARDS-TRACK]

 draft-ietf-avt-rapid-rtp-sync-12 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6051 RFC6052 IPv6 Addressing of IPv4/IPv6 Translators C. Bao C. Huitema M. Bagnulo M. Boucadair X. Li October 2010 ASCII HTML 18 address prefix transition translation NAT NAT64 BEHAVE stateless stateful

This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK]

 draft-ietf-behave-address-format-10 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6052 10.17487/RFC6052 RFC6053 Implementation Report for Forwarding and Control Element Separation (ForCES) E. Haleplidis K. Ogawa W. Wang J. Hadi Salim November 2010 ASCII HTML 34 Stream Control Transmission Protocol-based Transport Mapping Layer SCTP TML forces Model

Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES network element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework.

This document is an implementation report for the ForCES Protocol, Model, and the Stream Control Transmission Protocol-based Transport Mapping Layer (SCTP TML) documents, and includes a report on interoperability testing and the current state of ForCES implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-forces-implementation-report-02 RFC6984 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC6053 RFC6054 Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic D. McGrew B. Weis November 2010 ASCII HTML 10

Counter modes have been defined for block ciphers such as the Advanced Encryption Standard (AES). Counter modes use a counter, which is typically assumed to be incremented by a single sender. This memo describes the use of counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. [STANDARDS-TRACK]

 draft-ietf-msec-ipsec-group-counter-modes-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC6054 RFC6055 IAB Thoughts on Encodings for Internationalized Domain Names D. Thaler J. Klensin S. Cheshire February 2011 ASCII HTML 24 Unicode UTF-8,

This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.

 draft-iab-idn-encoding-04 RFC2130 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=6055 10.17487/RFC6055 RFC6056 Recommendations for Transport-Protocol Port Randomization M. Larsen F. Gont January 2011 ASCII HTML 29 tcp transmission control protocl blind attacks

During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers). This memo documents an Internet Best Current Practice.

 draft-ietf-tsvwg-port-randomization-09 BCP0156 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6056 10.17487/RFC6056 RFC6057 Comcast's Protocol-Agnostic Congestion Management System C. Bastian T. Klieber J. Livingood J. Mills R. Woundy December 2010 ASCII HTML 29 ISP Internet Service Provider Network Management

This document describes the congestion management system of Comcast Cable, a large cable broadband Internet Service Provider (ISP) in the U.S. Comcast completed deployment of this congestion management system on December 31, 2008. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-livingood-woundy-congestion-mgmt-09 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6057 RFC6058 Transient Binding for Proxy Mobile IPv6 M. Liebsch Editor A. Muhanna O. Blume March 2011 ASCII HTML 35 PMIP handover optimization handover delay tBCE late path switch forwarding make-before-break dual radio handover single radio handover transient binding cache entry

This document specifies a mechanism that enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry that is used to optimize the performance of dual radio handover, as well as single radio handover. This mechanism is applicable to the mobile node's inter-MAG (Mobility Access Gateway) handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described. The specified extension to the Proxy Mobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-mipshop-transient-bce-pmipv6-07 EXPERIMENTAL EXPERIMENTAL IETF int mipshop 10.17487/RFC6058 RFC6059 Simple Procedures for Detecting Network Attachment in IPv6 S. Krishnan G. Daley November 2010 ASCII HTML 19 DNA DNAv6 ND IPv6 neighbor discovery neighbor discovery send secure neighbor discovery DHCPv6 stateless autoconfiguration change detection movement detection DNAv4 link detection mobility

Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for Detecting Network Attachment in IPv6 hosts, and procedures for routers to support such services. [STANDARDS-TRACK]

 draft-ietf-dna-simple-17 PROPOSED STANDARD PROPOSED STANDARD IETF int dna 10.17487/RFC6059 RFC6060 Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) D. Fedyk H. Shah N. Bitar A. Takacs March 2011 ASCII HTML 20 IEEE data plane

This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework and describes the technology-specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE). The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point (P2P) and point-to-multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-ethernet-pbb-te-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6060 RFC6061 Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA) B. Rosen January 2011 ASCII HTML 7

This document describes the Namespace Identifier (NID) "nena" for Uniform Resource Name (URN) resources published by the National Emergency Number Association (NENA). NENA defines and manages resources that utilize this URN model. Management activities for these and other resource types are provided by the NENA Registry System (NRS). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-rosen-urn-nena-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6061 RFC6062 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations S. Perreault Editor J. Rosenberg November 2010 ASCII HTML 13 NAT TURN STUN

This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for Network Address Translator (NAT) traversal. This extension allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client\'s peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general-purpose servers from ports obtained from the TURN server. [STANDARDS-TRACK]

 draft-ietf-behave-turn-tcp-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6062 10.17487/RFC6062 RFC6063 Dynamic Symmetric Key Provisioning Protocol (DSKPP) A. Doherty M. Pei S. Machani M. Nystrom December 2010 ASCII HTML 105 Cryptographic module Cryptographic Token key initialization credentials online provisioning

The Dynamic Symmetric Key Provisioning Protocol (DSKPP) is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private key capabilities in the cryptographic modules and with or without an established public key infrastructure.

Two variations of the protocol support multiple usage scenarios. With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. The two-pass variant enables secure and efficient download and installation of pre-generated symmetric keys to a cryptographic module. [STANDARDS-TRACK]

 draft-ietf-keyprov-dskpp-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec keyprov http://www.rfc-editor.org/errata_search.php?rfc=6063 10.17487/RFC6063 RFC6064 SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service M. Westerlund P. Frojdh January 2011 ASCII HTML 22 3GPP PSS MBMS SDP RTSP IANA

The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use the Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-westerlund-mmusic-3gpp-sdp-rtsp-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6064 RFC6065 Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings K. Narayan D. Nelson R. Presuhn Editor December 2010 ASCII HTML 19 Network Management Security Management Information Base MIB SMIv2 RADIUS AAA VACM

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. It describes the use of information provided by Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), to dynamically update user-to-group mappings in the View-based Access Control Model (VACM). [STANDARDS-TRACK]

 draft-ietf-isms-radius-vacm-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC6065 RFC6066 Transport Layer Security (TLS) Extensions: Extension Definitions D. Eastlake 3rd January 2011 ASCII HTML 25 server_name max_fragment_length client_certificate_url trusted_ca_keys truncated_hmac status_request

This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]

 draft-ietf-tls-rfc4366-bis-12 RFC4366 RFC8446 RFC8449 RFC9325 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=6066 10.17487/RFC6066 RFC6067 BCP 47 Extension U M. Davis A. Phillips Y. Umaoka December 2010 ASCII HTML 8 locale bcp 47

This document specifies an Extension to BCP 47 that provides subtags that specify language and/or locale-based behavior or refinements to language tags, according to work done by the Unicode Consortium. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-davis-u-langtag-ext-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6067 10.17487/RFC6067 RFC6068 The 'mailto' URI Scheme M. Duerst L. Masinter J. Zawinski October 2010 ASCII HTML 17 mailto email address URI scheme IRI

This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK]

 draft-duerst-mailto-bis-10 RFC2368 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6068 10.17487/RFC6068 RFC6069 Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) A. Zimmermann A. Hannemann December 2010 ASCII HTML 23 Internet Control Message Protocol (ICMP) Retranmission Timeout (RTO)

Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission.

This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in the case of connectivity disruptions. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-tcpm-tcp-lcd-03 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC6069 RFC6070 PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors S. Josefsson January 2011 ASCII HTML 5

This document contains test vectors for the Public-Key Cryptography Standards (PKCS) #5 Password-Based Key Derivation Function 2 (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm (SHA-1) pseudorandom function. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-josefsson-pbkdf2-test-vectors-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6070 RFC6071 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap S. Frankel S. Krishnan February 2011 ASCII HTML 63 internet protocol privacy authentication

Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic.

This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IP Security Document Roadmap."

The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents. The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ipsecme-roadmap-10 RFC2411 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC6071 RFC6072 Certificate Management Service for the Session Initiation Protocol (SIP) C. Jennings J. Fischl Editor February 2011 ASCII HTML 30 credential service aor address of record

This document defines a credential service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users. This mechanism allows User Agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the credential service, which returns an authenticated response containing that certificate. The credential service also allows users to store and retrieve their own certificates and private keys. [STANDARDS-TRACK]

 draft-ietf-sip-certs-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=6072 10.17487/RFC6072 RFC6073 Segmented Pseudowire L. Martini C. Metz T. Nadeau M. Bocci M. Aissaoui January 2011 ASCII HTML 43 pws psn packet switched network pw control plane domain

This document describes how to connect pseudowires (PWs) between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains, where a control plane domain uses a common control plane protocol or instance of that protocol for a given PW. The different PW control plane domains may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. [STANDARDS-TRACK]

 draft-ietf-pwe3-segmented-pw-18 RFC6723 RFC7267 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6073 RFC6074 Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs) E. Rosen B. Davie V. Radoaca W. Luo January 2011 ASCII HTML 32

Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP), and the Layer 2 Tunneling Protocol version 3 (L2TPv3). [STANDARDS- TRACK]

 draft-ietf-l2vpn-signaling-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC6074 RFC6075 The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry D. Cridland December 2010 ASCII HTML 7 annotate metadata

The original Application Configuration Access Protocol (ACAP) specification included a vendor registry now used in other protocols. This document updates the description of this registry, removing the need for a direct normative reference to ACAP and removing ambiguity. [STANDARDS-TRACK]

 draft-cridland-acap-vendor-registry-02 RFC2244 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6075 RFC6076 Basic Telephony SIP End-to-End Performance Metrics D. Malas A. Morton January 2011 ASCII HTML 27 Benchmarking Lab Test Time Measurement Service Session Protocol

This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) for telephony services in both production and testing environments. The purpose of this document is to combine a standard set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. [STANDARDS-TRACK]

 draft-ietf-pmol-sip-perf-metrics-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops pmol 10.17487/RFC6076 RFC6077 Open Research Issues in Internet Congestion Control D. Papadimitriou Editor M. Welzl M. Scharf B. Briscoe February 2011 ASCII HTML 51 Signalling Performance Robustness Fairness Stability Misbehaviour Architecture

This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet-scale solutions can be confidently engineered and deployed. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-iccrg-welzl-congestion-control-open-research-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6077 RFC6078 Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) G. Camarillo J. Melen January 2011 ASCII HTML 17 HIP DATA

This document defines a new Host Identity Protocol (HIP) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-hiccups-05 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6078 RFC6079 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) G. Camarillo P. Nikander J. Hautakorpi A. Keranen A. Johnston January 2011 ASCII HTML 21

This document specifies a framework to build HIP-based (Host Identity Protocol) overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as "peer protocols". This document defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-bone-07 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6079 RFC6080 A Framework for Session Initiation Protocol User Agent Profile Delivery D. Petrie S. Channabasappa Editor March 2011 ASCII HTML 54 SIP Configuration Framework User Agent profile

This document specifies a framework to enable configuration of Session Initiation Protocol (SIP) user agents (UAs) in SIP deployments. The framework provides a means to deliver profile data that user agents need to be functional, automatically and with minimal or no User and Administrative intervention. The framework describes how SIP user agents can discover sources, request profiles, and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides minimal data retrieval options to ensure interoperability. The framework does not include specification of the profile data within its scope. [STANDARDS-TRACK]

 draft-ietf-sipping-config-framework-18 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC6080 RFC6081 Teredo Extensions D. Thaler January 2011 ASCII HTML 59 IPv6 NAT traversal transition translation translator

This document specifies a set of extensions to the Teredo protocol. These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs) and support for more efficient communication. [STANDARDS-TRACK]

 draft-thaler-v6ops-teredo-extensions-08 RFC4380 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6081 10.17487/RFC6081 RFC6082 Deprecating Unicode Language Tag Characters: RFC 2482 is Historic K. Whistler G. Adams M. Duerst R. Presuhn Editor J. Klensin November 2010 ASCII HTML 4 characters strings ASCII

RFC 2482, "Language Tagging in Unicode Plain Text", describes a mechanism for using special Unicode language tag characters to identify languages when needed without more general markup such as that provided by XML. The Unicode Consortium has deprecated that facility and strongly recommends against its use. RFC 2482 has been moved to Historic status to reduce the possibility that Internet implementers would consider that system an appropriate mechanism for identifying languages. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-presuhn-rfc2482-historic-02 RFC2482 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6082 RFC6083 Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) M. Tuexen R. Seggelmann E. Rescorla January 2011 ASCII HTML 9

This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP).

DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.

Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. [STANDARDS-TRACK]

 draft-ietf-tsvwg-dtls-for-sctp-06 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6083 10.17487/RFC6083 RFC6084 General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS) X. Fu C. Dickmann J. Crowcroft January 2011 ASCII HTML 12 Multihoming Signaling Partial Reliability

The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS). This document defines an Experimental Protocol for the Internet community.

 draft-ietf-nsis-ntlp-sctp-15 RFC8996 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC6084 RFC6085 Address Mapping of IPv6 Multicast Packets on Ethernet S. Gundavelli M. Townsley O. Troan W. Dec January 2011 ASCII HTML 3

When transmitting an IPv6 packet with a multicast destination address, the IPv6 destination address is mapped to an Ethernet link-layer multicast address. This document clarifies that a mapping of an IPv6 packet with a multicast destination address may in some circumstances map to an Ethernet link-layer unicast address. [STANDARDS-TRACK]

 draft-gundavelli-v6ops-l2-unicast-06 RFC2464 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6085 RFC6086 Session Initiation Protocol (SIP) INFO Method and Package Framework C. Holmberg E. Burger H. Kaplan January 2011 ASCII HTML 36 Info Package Info-Package Recv-Info

This document defines a method, INFO, for the Session Initiation Protocol (SIP), and an Info Package mechanism. This document obsoletes RFC 2976. For backward compatibility, this document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as "legacy INFO Usage" in this document. [STANDARDS-TRACK]

 draft-ietf-sipcore-info-events-10 RFC2976 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6086 10.17487/RFC6086 RFC6087 Guidelines for Authors and Reviewers of YANG Data Model Documents A. Bierman January 2011 ASCII HTML 26 NETMOD NETCONF XML YANG

This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) implementations that utilize YANG data model modules. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-netmod-yang-usage-11 RFC8407 INFORMATIONAL INFORMATIONAL IETF ops netmod 10.17487/RFC6087 RFC6088 Traffic Selectors for Flow Bindings G. Tsirtsis G. Giarreta H. Soliman N. Montavont January 2011 ASCII HTML 13 Mobile IPv6 Binary Traffic Selectors

This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6. [STANDARDS-TRACK]

 draft-ietf-mext-binary-ts-05 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC6088 RFC6089 Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support G. Tsirtsis H. Soliman N. Montavont G. Giaretta K. Kuladinithi January 2011 ASCII HTML 31 Flow Identification Flow Summary Binding Reference Traffic Selector Flow Binding Entry

This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. [STANDARDS- TRACK]

 draft-ietf-mext-flow-binding-11 RFC5648 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC6089 RFC6090 Fundamental Elliptic Curve Cryptography Algorithms D. McGrew K. Igoe M. Salter February 2011 ASCII HTML 34 ECC

This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mcgrew-fundamental-ecc-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6090 10.17487/RFC6090 RFC6091 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication N. Mavrogiannopoulos D. Gillmor February 2011 ASCII HTML 9 Certificate type negotiation tls handshake protocol handshake

This memo defines Transport Layer Security (TLS) extensions and associated semantics that allow clients and servers to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. It also defines the registry for non-X.509 certificate types. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mavrogiannopoulos-rfc5081bis-09 RFC5081 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6091 RFC6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service J. Woodyatt Editor January 2011 ASCII HTML 36 cpe firewall filter

This document identifies a set of recommendations for the makers of devices and describes how to provide for "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-cpe-simple-security-16 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=6092 10.17487/RFC6092 RFC6093 On the Implementation of the TCP Urgent Mechanism F. Gont A. Yourtchenko January 2011 ASCII HTML 12 Transmission Control Protocol

This document analyzes how current TCP implementations process TCP urgent indications and how the behavior of some widely deployed middleboxes affects how end systems process urgent indications. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet, and recommends against the use of urgent indications (but provides advice to applications that do). [STANDARDS-TRACK]

 draft-ietf-tcpm-urgent-data-07 RFC9293 RFC0793 RFC1011 RFC1122 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=6093 10.17487/RFC6093 RFC6094 Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols M. Bhatia V. Manral February 2011 ASCII HTML 11 IGP security

The routing protocols Open Shortest Path First version 2 (OSPFv2), Intermediate System to Intermediate System (IS-IS), and Routing Information Protocol (RIP) currently define cleartext and MD5 (Message Digest 5) methods for authenticating protocol packets. Recently, effort has been made to add support for the SHA (Secure Hash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS, and OSPF.

To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms, thereby ensuring that there is at least one algorithm that all implementations will have in common.

Similarly, RIP for IPv6 (RIPng) and OSPFv3 support IPsec algorithms for authenticating their protocol packets.

This document examines the current set of available algorithms, with interoperability and effective cryptographic authentication protection being the principal considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-opsec-igp-crypto-requirements-04 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC6094 RFC6095 Extending YANG with Language Abstractions B. Linowski M. Ersue S. Kuryla March 2011 ASCII HTML 75 YANG model complex-type Complex Types Typed Instance Resource Model Inheritance class

YANG -- the Network Configuration Protocol (NETCONF) Data Modeling Language -- supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests enhancing YANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse. This document defines an Experimental Protocol for the Internet community.

 draft-linowski-netmod-yang-abstract-05 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6095 RFC6096 Stream Control Transmission Protocol (SCTP) Chunk Flags Registration M. Tuexen R. Stewart January 2011 ASCII HTML 8

This document defines the procedure for registering chunk flags with the Internet Assigned Numbers Authority (IANA) for the Stream Control Transmission Protocol (SCTP). It updates RFC 4960 and also defines the IANA registry for contents for currently defined chunk types. It does not change SCTP in any other way. [STANDARDS-TRACK]

 draft-ietf-tsvwg-sctp-chunk-flags-02 RFC9260 RFC4960 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6096 RFC6097 Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6 J. Korhonen V. Devarapalli February 2011 ASCII HTML 10 PMIPv6 3GPP DNS AAA

Large Proxy Mobile IPv6 deployments would benefit from a functionality where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to a Proxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the Mobile Access Gateway. This document describes several possible dynamic Local Mobility Anchor discovery solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-netlmm-lma-discovery-08 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC6097 RFC6098 Generic Notification Message for Mobile IPv4 H. Deng H. Levkowetz V. Devarapalli S. Gundavelli B. Haley April 2012 ASCII HTML 33 mipv4

This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using a Mobile IPv4 message type designed for this purpose. [STANDARDS-TRACK]

 draft-ietf-mip4-generic-notification-message-16 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC6098 RFC6099 RFC6100 RFC6101 The Secure Sockets Layer (SSL) Protocol Version 3.0 A. Freier P. Karlton P. Kocher August 2011 ASCII HTML 67 Transport layer security

This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows.

This document specifies version 3.0 of the Secure Sockets Layer (SSL 3.0) protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. This document defines a Historic Document for the Internet community.

 draft-mavrogiannopoulos-ssl-version3-06 HISTORIC HISTORIC IETF NON WORKING GROUP 10.17487/RFC6101 RFC6102 RFC6103 RFC6104 Rogue IPv6 Router Advertisement Problem Statement T. Chown S. Venaas February 2011 ASCII HTML 16 RA rogue ra

When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements (RAs) to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the RA message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-rogue-ra-02 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6104 RFC6105 IPv6 Router Advertisement Guard E. Levy-Abegnoli G. Van de Velde C. Popoviciu J. Mohacsi February 2011 ASCII HTML 10 SEcure Neighbor Discovery Stateless Address Autoconfiguration

Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-ra-guard-08 RFC7113 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6105 RFC6106 IPv6 Router Advertisement Options for DNS Configuration J. Jeong S. Park L. Beloeil S. Madanapalli November 2010 ASCII HTML 19 DNS Service DNS Option Recursive DNS Server Address DNS Search List Stateless Autoconfiguration

This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. [STANDARDS-TRACK]

 draft-ietf-6man-dns-options-bis-08 RFC5006 RFC8106 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6106 10.17487/RFC6106 RFC6107 Procedures for Dynamically Signaled Hierarchical Label Switched Paths K. Shiomoto Editor A. Farrel Editor February 2011 ASCII HTML 30 TE links Bundled links GMPLS dynamically provisioned networks

Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks.

Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. [STANDARDS-TRACK]

 draft-ietf-ccamp-lsp-hierarchy-bis-08 RFC3477 RFC4206 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=6107 10.17487/RFC6107 RFC6108 Comcast's Web Notification System Design C. Chung A. Kasyanov J. Livingood N. Mody B. Van Lieu February 2011 ASCII HTML 24 ISP Internet Service Provider bot remediation bot notification

The objective of this document is to describe a method of providing critical end-user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP). Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection. There are other proprietary systems that can perform such notifications, but those systems utilize Deep Packet Inspection (DPI) technology. In contrast to DPI, this document describes a system that does not rely upon DPI, and is instead based in open IETF standards and open source applications. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-livingood-web-notification-09 HISTORIC INFORMATIONAL INDEPENDENT 10.17487/RFC6108 RFC6109 La Posta Elettronica Certificata - Italian Certified Electronic Mail C. Petrucci F. Gennai A. Shahin A. Vinciarelli April 2011 ASCII HTML 65 PEC Registered mail Return receipt Digitally signed email Digitally signed notification MIME SMIME

Since 1997, the Italian laws have recognized electronic delivery systems as legally usable. In 2005, after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "Posta Elettronica Certificata") were defined, giving the system legal standing.

The design of the entire system was carried out by the National Center for Informatics in the Public Administration of Italy (DigitPA), followed by efforts for the implementation and testing of the service. The DigitPA has given the Italian National Research Council (CNR), and in particular the Institute of Information Science and Technologies at the CNR (ISTI), the task of running tests on providers of the service to guarantee the correct implementation and interoperability. This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-gennai-smime-cnipa-pec-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6109 10.17487/RFC6109 RFC6110 Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content L. Lhotka Editor February 2011 ASCII HTML 100 DSDL validation RELAX NG Schematron DSRL

This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC 19757. The following DSDL schema languages are addressed by the mapping: Regular Language for XML Next Generation (RELAX NG), Schematron, and Schematron and Document Schema Renaming Language (DSRL). The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type -- datastore content, Network Configuration Protocol (NETCONF) messages, etc. Procedures for schema-based validation of such documents are also discussed. [STANDARDS-TRACK]

 draft-ietf-netmod-dsdl-map-10 RFC7952 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6110 10.17487/RFC6110 RFC6111 Additional Kerberos Naming Constraints L. Zhu April 2011 ASCII HTML 6 principal names realm names

This document defines new naming constraints for well-known Kerberos principal names and well-known Kerberos realm names. [STANDARDS- TRACK]

 draft-ietf-krb-wg-naming-07 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6111 RFC6112 Anonymity Support for Kerberos L. Zhu P. Leach S. Hartman April 2011 ASCII HTML 16 kerberos realm

This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. [STANDARDS-TRACK]

 draft-ietf-krb-wg-anon-12 RFC8062 RFC4120 RFC4121 RFC4556 HISTORIC PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=6112 10.17487/RFC6112 RFC6113 A Generalized Framework for Kerberos Pre-Authentication S. Hartman L. Zhu April 2011 ASCII HTML 48

Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a facility called pre-authentication. Pre-authentication mechanisms can use this facility to extend the Kerberos protocol and prove the identity of a principal.

This document describes a more formal model for this facility. The model describes what state in the Kerberos request a pre-authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact.

This document also provides common tools needed by multiple pre-authentication mechanisms. One of these tools is a secure channel between the client and the key distribution center with a reply key strengthening mechanism; this secure channel can be used to protect the authentication exchange and thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. [STANDARDS-TRACK]

 draft-ietf-krb-wg-preauth-framework-17 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6113 RFC6114 The 128-Bit Blockcipher CLEFIA M. Katagi S. Moriai March 2011 ASCII HTML 33 security lightweight cryptography encryption algorithm

This document describes the specification of the blockcipher CLEFIA. CLEFIA is a 128-bit blockcipher, with key lengths of 128, 192, and 256 bits, which is compatible with the interface of the Advanced Encryption Standard (AES). The algorithm of CLEFIA was published in 2007, and its security has been scrutinized in the public community. CLEFIA is one of the new-generation lightweight blockcipher algorithms designed after AES. Among them, CLEFIA offers high performance in software and hardware as well as lightweight implementation in hardware. CLEFIA will be of benefit to the Internet, which will be connected to more distributed and constrained devices. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-katagi-clefia-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6114 RFC6115 Recommendation for a Routing Architecture T. Li Editor February 2011 ASCII HTML 73

It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. This document presents, as a recommendation of future directions for the IETF, solutions that could aid the future scalability of the Internet. To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs. This document is a product of the Routing Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-rrg-recommendation-16 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6115 RFC6116 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) S. Bradner L. Conroy K. Fujiwara March 2011 ASCII HTML 22 DNS E.164 NAPTR dynamic delegation discovery system e164.arpa

This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. [STANDARDS-TRACK]

 draft-ietf-enum-3761bis-09 RFC3761 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC6116 RFC6117 IANA Registration of Enumservices: Guide, Template, and IANA Considerations B. Hoeneisen A. Mayrhofer J. Livingood March 2011 ASCII HTML 40 domain name system

This document specifies a revision of the IANA Registration Guidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservice Specifications. [STANDARDS-TRACK]

 draft-ietf-enum-enumservices-guide-22 RFC3761 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC6117 RFC6118 Update of Legacy IANA Registrations of Enumservices B. Hoeneisen A. Mayrhofer March 2011 ASCII HTML 68 domain name system

This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761. [STANDARDS-TRACK]

 draft-ietf-enum-enumservices-transition-06 RFC3762 RFC3764 RFC3953 RFC4143 RFC4002 RFC4238 RFC4355 RFC4415 RFC4769 RFC4969 RFC4979 RFC5028 RFC5278 RFC5333 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC6118 RFC6119 IPv6 Traffic Engineering in IS-IS J. Harrison J. Berger M. Bartlett February 2011 ASCII HTML 10

This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK]

 draft-ietf-isis-ipv6-te-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6119 RFC6120 Extensible Messaging and Presence Protocol (XMPP): Core P. Saint-Andre March 2011 ASCII HTML 211 XMPP Extensible Messaging and Presence Protocol Jabber Messaging Instant Messaging Presence Extensible Markup Language XML

The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]

 draft-ietf-xmpp-3920bis-22 RFC3920 RFC7590 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp http://www.rfc-editor.org/errata_search.php?rfc=6120 10.17487/RFC6120 RFC6121 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence P. Saint-Andre March 2011 ASCII HTML 114 XMPP Extensible Messaging and Presence Protocol Jabber IM Instant Messaging Presence XML Extensible Markup Language

This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. [STANDARDS-TRACK]

 draft-ietf-xmpp-3921bis-20 RFC3921 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp http://www.rfc-editor.org/errata_search.php?rfc=6121 10.17487/RFC6121 RFC6122 Extensible Messaging and Presence Protocol (XMPP): Address Format P. Saint-Andre March 2011 ASCII HTML 23 XMPP Jabber Messaging Instant Messaging Presence Extensible Markup Language XML

This document defines the format for addresses used in the Extensible Messaging and Presence Protocol (XMPP), including support for non-ASCII characters. This document updates RFC 3920. [STANDARDS-TRACK]

 draft-ietf-xmpp-address-09 RFC7622 RFC3920 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp http://www.rfc-editor.org/errata_search.php?rfc=6122 10.17487/RFC6122 RFC6123 Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts A. Farrel February 2011 ASCII HTML 13

It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements.

The Operations Area has developed "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" (RFC 5706), and those guidelines have been adopted by the Path Computation Element (PCE) Working Group.

Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference. This document defines a Historic Document for the Internet community.

 draft-ietf-pce-manageability-requirements-11 HISTORIC HISTORIC IETF rtg pce 10.17487/RFC6123 RFC6124 An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol Y. Sheffer G. Zorn H. Tschofenig S. Fluhrer February 2011 ASCII HTML 33 password-based authentication mutual authentication password-based cryptography password authenticated key exchange weak password authentication

The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms. This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol. This method provides mutual authentication through the use of a short, easy to remember password. Compared with other common authentication methods, EAP-EKE is not susceptible to dictionary attacks. Neither does it require the availability of public-key certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-sheffer-emu-eap-eke-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6124 RFC6125 Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) P. Saint-Andre J. Hodges March 2011 ASCII HTML 57

Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]

 draft-saintandre-tls-server-id-check-14 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6125 10.17487/RFC6125 RFC6126 The Babel Routing Protocol J. Chroboczek April 2011 ASCII HTML 45

Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document defines an Experimental Protocol for the Internet community.

 draft-chroboczek-babel-routing-protocol-05 RFC8966 RFC7298 RFC7557 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6126 10.17487/RFC6126 RFC6127 IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios J. Arkko M. Townsley May 2011 ASCII HTML 20 address depletion translation NAT-PT dual-stack Softwire Behave NAT NAT444

When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition.

This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-arkko-townsley-coexistence-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6127 RFC6128 RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions A. Begen February 2011 ASCII HTML 6

The Session Description Protocol (SDP) has an attribute that allows RTP applications to specify an address and a port associated with the RTP Control Protocol (RTCP) traffic. In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description. However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the "m=" line of the media description. Deriving the RTCP port from the "m=" line imposes an unnecessary restriction. This document removes this restriction by introducing a new SDP attribute. [STANDARDS-TRACK]

 draft-ietf-avt-rtcp-port-for-ssm-04 RFC5760 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6128 RFC6129 The 'application/tei+xml' Media Type L. Romary S. Lundberg February 2011 ASCII HTML 8 Text Encoding Initiative xml text encoding text representation MIME type

This document defines the 'application/tei+xml' media type for markup languages defined in accordance with the Text Encoding and Interchange guidelines. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-lundberg-app-tei-xml-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6129 10.17487/RFC6129 RFC6130 Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) T. Clausen C. Dearlove J. Dean April 2011 ASCII HTML 88 MANET OLSRv2 packetbb Routing Protocol NHDP ad hoc network bi-directional 2-hop discovery Wireless SMF

This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). [STANDARDS-TRACK]

 draft-ietf-manet-nhdp-15 RFC7183 RFC7188 RFC7466 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=6130 10.17487/RFC6130 RFC6131 Sieve Vacation Extension: "Seconds" Parameter R. George B. Leiba July 2011 ASCII HTML 5 email filters auto-replies

This document describes a further extension to the Sieve Vacation extension, allowing multiple auto-replies to the same sender in a single day by adding a ":seconds" parameter. [STANDARDS-TRACK]

 draft-ietf-sieve-vacation-seconds-03 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6131 RFC6132 Sieve Notification Using Presence Information R. George B. Leiba July 2011 ASCII HTML 8 email filters context status

This is a further extension to the Sieve mail filtering language Notification extension, defining presence information that may be checked through the notify_method_capability feature. [STANDARDS-TRACK]

 draft-ietf-sieve-notify-presence-04 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6132 RFC6133 Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality R. George B. Leiba A. Melnikov July 2011 ASCII HTML 9

This document describes how the Sieve email filtering language, along with some extensions, can be used to create automatic replies to incoming electronic mail messages based on the address book and presence information of the recipient. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sieve-autoreply-04 INFORMATIONAL INFORMATIONAL IETF app sieve 10.17487/RFC6133 RFC6134 Sieve Extension: Externally Stored Lists A. Melnikov B. Leiba July 2011 ASCII HTML 18

The Sieve email filtering language can be used to implement email whitelisting, blacklisting, personal distribution lists, and other sorts of list matching. Currently, this requires that all members of such lists be hard-coded in the script itself. Whenever a member of a list is added or deleted, the script needs to be updated and possibly uploaded to a mail server.

This document defines a Sieve extension for accessing externally stored lists -- lists whose members are stored externally to the script, such as using the Lightweight Directory Access Protocol (LDAP), the Application Configuration Access Protocol (ACAP), vCard Extensions to WebDAV (CardDAV), or relational databases. [STANDARDS-TRACK]

 draft-ietf-sieve-external-lists-10 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6134 RFC6135 An Alternative Connection Model for the Message Session Relay Protocol (MSRP) C. Holmberg S. Blau February 2011 ASCII HTML 8 comedia comedia-tls relay SBC

This document defines an alternative connection model for Message Session Relay Protocol (MSRP) User Agents (UAs); this model uses the connection-oriented media (COMEDIA) mechanism in order to create the MSRP transport connection. The model allows MSRP UAs behind Network Address Translators (NATs) to negotiate which endpoint initiates the establishment of the Transmission Control Protocol (TCP) connection, in order for MSRP messages to traverse the NAT. [STANDARDS-TRACK]

 draft-ietf-simple-msrp-acm-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC6135 RFC6136 Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework A. Sajassi Editor D. Mohan Editor March 2011 ASCII HTML 42

This document provides framework and requirements for Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, pseudowires (PWs), and Packet Switched Network (PSN) tunnels. This document is intended to identify OAM requirements for L2VPN services, i.e., Virtual Private LAN Service (VPLS), Virtual Private Wire Service (VPWS), and IP-only LAN Service (IPLS). Furthermore, if L2VPN service OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-l2vpn-oam-req-frmk-11 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC6136 RFC6137 The Network Trouble Ticket Data Model (NTTDM) D. Zisiadis Editor S. Kopsidas Editor M. Tsavli Editor G. Cessieux Editor February 2011 ASCII HTML 46 Grid Management EGEE

Handling multiple sets of network trouble tickets (TTs) originating from different participants' inter-connected network environments poses a series of challenges for the involved institutions. A Grid is a good example of such a multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. The TT systems of the participants collect, represent, and disseminate TT information in different formats.

As a result, management of the daily workload by a central Network Operation Centre (NOC) is a challenge on its own. Normalization of TTs to a common format at the central NOC can ease presentation, storing, and handling of the TTs. In the present document, we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE (Enabling Grids for E-sciencE) project. This document defines an Experimental Protocol for the Internet community.

 draft-dzis-nwg-nttdm-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6137 10.17487/RFC6137 RFC6138 LDP IGP Synchronization for Broadcast Networks S. Kini Editor W. Lu Editor February 2011 ASCII HTML 9

RFC 5443 describes a mechanism to achieve LDP IGP synchronization to prevent black-holing traffic (e.g., VPN) when an Interior Gateway Protocol (IGP) is operational on a link but Label Distribution Protocol (LDP) is not. If this mechanism is applied to broadcast links that have more than one LDP peer, the metric increase procedure can only be applied to the link as a whole but not to an individual peer. When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network. This document describes a mechanism to address that use-case without dropping traffic. The mechanism does not introduce any protocol message changes. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-ldp-igp-sync-bcast-06 RFC5443 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6138 RFC6139 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios S. Russert Editor E. Fleischman Editor F. Templin Editor February 2011 ASCII HTML 39 Encapsulation Tunnel Architecture Scalability Mobility MANET Security IPv6 Aerospace IRON VET SEAL ISATAP

"Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)" (RFC 5720) provides an architectural framework for scalable routing and addressing. It provides an incrementally deployable approach for scalability, provider independence, mobility, multihoming, traffic engineering, and security. This document describes a series of use cases in order to showcase the architectural capabilities. It further shows how the RANGER architecture restores the network-within-network principles originally intended for the sustained growth of the Internet. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-russert-rangers-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6139 RFC6140 Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) A.B. Roach March 2011 ASCII HTML 35 Bulk Registration Implicit Registration GIN PBX SSP SIP-PBX

This document defines a mechanism by which a Session Initiation Protocol (SIP) server acting as a traditional Private Branch Exchange (PBX) can register with a SIP Service Provider (SSP) to receive phone calls for SIP User Agents (UAs). In order to function properly, this mechanism requires that each of the Addresses of Record (AORs) registered in bulk map to a unique set of contacts. This requirement is satisfied by AORs representing phone numbers regardless of the domain, since phone numbers are fully qualified and globally unique. This document therefore focuses on this use case. [STANDARDS-TRACK]

 draft-ietf-martini-gin-13 RFC3680 PROPOSED STANDARD PROPOSED STANDARD IETF rai martini http://www.rfc-editor.org/errata_search.php?rfc=6140 10.17487/RFC6140 RFC6141 Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) G. Camarillo Editor C. Holmberg Y. Gao March 2011 ASCII HTML 26 re-INVITE offer/answer rollback

The procedures for handling SIP re-INVITEs are described in RFC 3261. Implementation and deployment experience has uncovered a number of issues with the original documentation, and this document provides additional procedures that update the original specification to address those issues. In particular, this document defines in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, this document defines further details of procedures related to target-refresh requests. [STANDARDS-TRACK]

 draft-ietf-sipcore-reinvite-08 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6141 RFC6142 ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP A. Moise J. Brodkin March 2011 ASCII HTML 26 Advanced Metering Infrastructure ami application layer message

This RFC provides a framework for transporting ANSI C12.22/IEEE 1703/MC12.22 Advanced Metering Infrastructure (AMI) Application Layer Messages on an IP network.

This document is not an official submission on behalf of the ANSI C12.19 and C12.22 working groups. It was created by participants in those groups, building on knowledge of several proprietary C12.22- over-IP implementations. The content of this document is an expression of a consensus aggregation of those implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-c1222-transport-over-ip-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6142 RFC6143 The Remote Framebuffer Protocol T. Richardson J. Levine March 2011 ASCII HTML 39 vnc rfb remote framebuffer remote GUI

RFB ("remote framebuffer") is a simple protocol for remote access to graphical user interfaces that allows a client to view and control a window system on another computer. Because it works at the framebuffer level, RFB is applicable to all windowing systems and applications. This document describes the protocol used to communicate between an RFB client and RFB server. RFB is the protocol used in VNC. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-levine-rfb-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6143 10.17487/RFC6143 RFC6144 Framework for IPv4/IPv6 Translation F. Baker X. Li C. Bao K. Yin April 2011 ASCII HTML 31 stateless translation stateful translation

This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-behave-v6v4-framework-10 INFORMATIONAL INFORMATIONAL IETF tsv behave 10.17487/RFC6144 RFC6145 IP/ICMP Translation Algorithm X. Li C. Bao F. Baker April 2011 ASCII HTML 33 SIIT] internet protocol control message IPv4 IPv6 Stateless IP/ICMP Translation Algorithm,

This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 2765. [STANDARDS-TRACK]

 draft-ietf-behave-v6v4-xlate-23 RFC2765 RFC7915 RFC6791 RFC7757 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6145 10.17487/RFC6145 RFC6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers M. Bagnulo P. Matthews I. van Beijnum April 2011 ASCII HTML 45 NAT64 IPv6 draft-ietf-behave-v6v4-xlate-stateful-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6146 10.17487/RFC6146 RFC6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers M. Bagnulo A. Sullivan P. Matthews I. van Beijnum April 2011 ASCII HTML 32 AAAA

DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK]

 draft-ietf-behave-dns64-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6147 10.17487/RFC6147 RFC6148 DHCPv4 Lease Query by Relay Agent Remote ID P. Kurapati R. Desetti B. Joshi February 2011 ASCII HTML 13 dynamic host configuration protocol

Some relay agents extract lease information from the DHCP messages exchanged between the client and DHCP server. This lease information is used by relay agents for various purposes like antispoofing and prevention of flooding. RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server when this information is lost. The existing lease query mechanism is data-driven, which means that a relay agent can initiate the lease query only when it starts receiving data to and from the clients. In certain scenarios, this model is not scalable. This document first looks at issues in the existing mechanism and then proposes a new query type, query by Remote ID, to address these issues. [STANDARDS-TRACK]

 draft-ietf-dhc-leasequery-by-remote-id-09 RFC4388 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6148 RFC6149 MD2 to Historic Status S. Turner L. Chen March 2011 ASCII HTML 7 security encryption signature

This document retires MD2 and discusses the reasons for doing so. This document moves RFC 1319 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-md2-to-historic-10 RFC1319 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6149 10.17487/RFC6149 RFC6150 MD4 to Historic Status S. Turner L. Chen March 2011 ASCII HTML 10 MD4 security encryption signature

This document retires RFC 1320, which documents the MD4 algorithm, and discusses the reasons for doing so. This document moves RFC 1320 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-md4-to-historic-11 RFC1320 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6150 10.17487/RFC6150 RFC6151 Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms S. Turner L. Chen March 2011 ASCII HTML 7 signature eneryption ipsec Message Digest encryption

This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-md5-seccon-update-08 RFC1321 RFC2104 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6151 RFC6152 SMTP Service Extension for 8-bit MIME Transport J. Klensin N. Freed M. Rose D. Crocker Editor March 2011 ASCII HTML 7 simple mail transfer

This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS-TRACK]

 draft-ietf-yam-rfc1652bis-03 RFC1652 STD0071 INTERNET STANDARD INTERNET STANDARD IETF app yam http://www.rfc-editor.org/errata_search.php?rfc=6152 10.17487/RFC6152 RFC6153 DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery S. Das G. Bajko February 2011 ASCII HTML 7 Dynamic Host Configuration Protocol

This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options to enable a mobile node to discover Access Network Discovery and Selection Function (ANDSF) entities in an IP network. ANDSF is being developed in the Third Generation Partnership Project (3GPP) and provides inter-system mobility policies and access-network-specific information to the mobile nodes (MNs). [STANDARDS-TRACK]

 draft-das-mipshop-andsf-dhcp-options-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6153 RFC6154 IMAP LIST Extension for Special-Use Mailboxes B. Leiba J. Nicolson March 2011 ASCII HTML 12 IMAP email

Some IMAP message stores include special-use mailboxes, such as those used to hold draft messages or sent messages. Many mail clients allow users to specify where draft or sent messages should be put, but configuring them requires that the user know which mailboxes the server has set aside for these purposes. This extension adds new optional mailbox attributes that a server may include in IMAP LIST command responses to identify special-use mailboxes to the client, easing configuration. [STANDARDS-TRACK]

 draft-ietf-morg-list-specialuse-06 PROPOSED STANDARD PROPOSED STANDARD IETF app morg http://www.rfc-editor.org/errata_search.php?rfc=6154 10.17487/RFC6154 RFC6155 Use of Device Identity in HTTP-Enabled Location Delivery (HELD) J. Winterbottom M. Thomson H. Tschofenig R. Barnes March 2011 ASCII HTML 27

When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP-Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address.

Two additional use cases are addressed by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device.

This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted. [STANDARDS-TRACK]

 draft-ietf-geopriv-held-identity-extensions-06 RFC6915 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6155 RFC6156 Traversal Using Relays around NAT (TURN) Extension for IPv6 G. Camarillo O. Novo S. Perreault Editor April 2011 ASCII HTML 14 STUN TURN IPv6

This document adds IPv6 support to Traversal Using Relays around NAT (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED- ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). [STANDARDS-TRACK]

 draft-ietf-behave-turn-ipv6-11 RFC8656 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC6156 RFC6157 IPv6 Transition in the Session Initiation Protocol (SIP) G. Camarillo K. El Malki V. Gurbani April 2011 ASCII HTML 15

This document describes how the IPv4 Session Initiation Protocol (SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up. Both single- and dual-stack (i.e., IPv4-only and IPv4/IPv6) user agents are considered. [STANDARDS-TRACK]

 draft-ietf-sipping-v6-transition-07 RFC3264 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=6157 10.17487/RFC6157 RFC6158 RADIUS Design Guidelines A. DeKok Editor G. Weber March 2011 ASCII HTML 38

This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs). This memo documents an Internet Best Current Practice.

 draft-ietf-radext-design-19 RFC6929 RFC8044 BCP0158 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops radext 10.17487/RFC6158 RFC6159 Session-Specific Explicit Diameter Request Routing T. Tsou G. Zorn T. Taylor Editor April 2011 ASCII HTML 19 Diameter routing

This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting a Diameter session. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-tsou-diameter-explicit-routing-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6159 RFC6160 Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types S. Turner April 2011 ASCII HTML 5

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) to protect the symmetric key package content type. Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData. [STANDARDS-TRACK]

 draft-turner-cms-symmetrickeypackage-algs-00 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6160 RFC6161 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type S. Turner April 2011 ASCII HTML 3 ecdsa ecdh EnvelopedData and Elliptic Curve Digital Signature Algorithm

This document describes the conventions for using several Elliptic Curve cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman (ECDH) with EnvelopedData and Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData. This document extends RFC 6033. [STANDARDS-TRACK]

 draft-turner-ekpct-algs-update-03 RFC6033 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6161 RFC6162 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type S. Turner April 2011 ASCII HTML 4 ecdsa ecdh EnvelopedData and Elliptic Curve Digital Signature Algorithm

This document describes conventions for using Elliptic Curve cryptographic algorithms with SignedData and EnvelopedData to protect the AsymmetricKeyPackage content type. Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman (ECDH) with EnvelopedData and Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData. This document extends RFC 5959. [STANDARDS-TRACK]

 draft-turner-akf-algs-update-03 RFC5959 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6162 RFC6163 Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs) Y. Lee Editor G. Bernstein Editor W. Imajuku April 2011 ASCII HTML 51 Generalized Multi-Protocol Label Switching Routing and Wavelength Assignment RWA

This document provides a framework for applying Generalized Multi-Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of Wavelength Switched Optical Networks (WSONs). In particular, it examines Routing and Wavelength Assignment (RWA) of optical paths.

This document focuses on topological elements and path selection constraints that are common across different WSON environments; as such, it does not address optical impairments in any depth. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ccamp-rwa-wson-framework-12 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6163 RFC6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links M. Kohno B. Nitzan R. Bush Y. Matsuzaki L. Colitti T. Narten April 2011 ASCII HTML 8 addressing prefix length security

On inter-router point-to-point links, it is useful, for security and other reasons, to use 127-bit IPv6 prefixes. Such a practice parallels the use of 31-bit prefixes in IPv4. This document specifies the motivation for, and usages of, 127-bit IPv6 prefix lengths on inter-router point-to-point links. [STANDARDS-TRACK]

 draft-ietf-6man-prefixlen-p2p-01 RFC6547 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6164 10.17487/RFC6164 RFC6165 Extensions to IS-IS for Layer-2 Systems A. Banerjee D. Ward April 2011 ASCII HTML 7 Intermediate System to Intermediate System

This document specifies the Intermediate System to Intermediate System (IS-IS) extensions necessary to support link state routing for any protocols running directly over Layer-2. While supporting this concept involves several pieces, this document only describes extensions to IS-IS. Furthermore, the Type, Length, Value pairs (TLVs) described in this document are generic Layer-2 additions, and specific ones as needed are defined in the IS-IS technology-specific extensions. We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used. [STANDARDS- TRACK]

 draft-ietf-isis-layer2-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6165 RFC6166 A Registry for PIM Message Types S. Venaas April 2011 ASCII HTML 4 IANA Protocol Independent Multicast

This document provides instructions to IANA for the creation of a registry for PIM message types. It specifies the initial content of the registry, based on existing RFCs specifying PIM message types. It also specifies a procedure for registering new types.

In addition to this, one message type is reserved, and may be used for a future extension of the message type space. [STANDARDS-TRACK]

 draft-ietf-pim-registry-04 RFC8736 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6166 RFC6167 URI Scheme for Java(tm) Message Service 1.0 M. Phillips P. Adams D. Rokicki E. Johnson April 2011 ASCII HTML 22 SOAP JMS JNDI IRI

This document defines the format of Uniform Resource Identifiers (URIs) as defined in RFC 3986, for designating connections and destination addresses used in the Java(tm) Messaging Service (JMS). It was originally designed for particular uses, but applies generally wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS Destination. The syntax of this JMS URI is not compatible with previously existing, but unregistered, "jms" URI schemes. However, the expressiveness of the scheme described herein should satisfy the requirements of all existing circumstances. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-merrick-jms-uri-12 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6167 10.17487/RFC6167 RFC6168 Requirements for Management of Name Servers for the DNS W. Hardaker May 2011 ASCII HTML 17 DNS Domain Name System Management

Management of name servers for the Domain Name System (DNS) has traditionally been done using vendor-specific monitoring, configuration, and control methods. Although some service monitoring platforms can test the functionality of the DNS itself, there is not an interoperable way to manage (monitor, control, and configure) the internal aspects of a name server itself.

This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-dnsop-name-server-management-reqs-05 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6168 RFC6169 Security Concerns with IP Tunneling S. Krishnan D. Thaler J. Hoagland April 2011 ASCII HTML 20

A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK]

 draft-ietf-v6ops-tunnel-security-concerns-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6169 RFC6170 Internet X.509 Public Key Infrastructure -- Certificate Image S. Santesson R. Housley S. Bajaj L. Rosenthol May 2011 ASCII HTML 12 otherLogos

This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new "otherLogos" image type according to RFC 3709. [STANDARDS-TRACK]

 draft-ietf-pkix-certimage-11 RFC3709 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6170 RFC6171 The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control K. Zeilenga March 2011 ASCII HTML 6 x.511 dontusecopy

This document defines the Lightweight Directory Access Protocol (LDAP) Don't Use Copy control extension, which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option. [STANDARDS-TRACK]

 draft-zeilenga-ldap-dontusecopy-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6171 RFC6172 Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode D. Black D. Peterson March 2011 ASCII HTML 6 FCIP

Changes to Fibre Channel have caused the specification of the Internet Fibre Channel Protocol (iFCP) address translation mode to become incorrect. Due to the absence of usage of iFCP address translation mode, it is deprecated by this document. iFCP address transparent mode remains correctly specified.

iFCP address transparent mode has been implemented and is in current use; therefore, it is not affected by this document.

This document also records the state of Protocol Number 133, which was allocated for a pre-standard version of the Fibre Channel Internet Protocol (FCIP). [STANDARDS-TRACK]

 draft-ietf-storm-ifcp-ipn133-updates-03 RFC4172 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC6172 RFC6173 Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP) P. Venkatesen Editor March 2011 ASCII HTML 31 Management Information Base mib IFCP-MGMT-MIB

This document defines Management Information Base (MIB) objects to monitor and control the Internet Fibre Channel Protocol (iFCP) gateway instances and their associated sessions, for use with network management protocols.

This document obsoletes RFC 4369. [STANDARDS-TRACK]

 draft-ietf-storm-ifcpmib-07 RFC4369 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC6173 RFC6174 Definition of IETF Working Group Document States E. Juskevicius March 2011 ASCII HTML 25 WG I-D States I-D Availability States

The IETF Datatracker tool needs to be enhanced to make it possible for Working Group (WG) Chairs to provide IETF participants with more information about the status and progression of WG documents than is currently possible.

This document defines new states and status annotation tags that need to be added to the Datatracker to enable WG Chairs and their Delegates to track the status of Internet-Drafts (I-Ds) that are associated with their WGs. This document also describes the meaning of all previously implemented I-D states and substate annotation tags currently used by IETF Area Directors to indicate the status of I-Ds that have been sent to the IESG for evaluation and publication. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-proto-wgdocument-states-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6174 RFC6175 Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors E. Juskevicius March 2011 ASCII HTML 23 WG Document States I-D States

This document specifies requirements for new functionality to be added to the IETF Datatracker tool to make it possible for Working Group (WG) Chairs and their Delegates to input and update the status of the Internet-Drafts (I-Ds) associated with their WGs. After these requirements are implemented, WG Chairs will be able to use the Datatracker to provide everyone with more information about the status and progression of WG I-Ds than is currently possible. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-juskevicius-datatracker-wgdocstate-reqts-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6175 RFC6176 Prohibiting Secure Sockets Layer (SSL) Version 2.0 S. Turner T. Polk March 2011 ASCII HTML 4

This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0. This document updates the backward compatibility sections found in the Transport Layer Security (TLS). [STANDARDS-TRACK]

 draft-ietf-tls-ssl2-must-not-04 RFC2246 RFC4346 RFC5246 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=6176 10.17487/RFC6176 RFC6177 IPv6 Address Assignment to End Sites T. Narten G. Huston L. Roberts March 2011 ASCII HTML 9 internet architecture board engineering steering group protocol

RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.

This document obsoletes RFC 3177. [STANDARDS-TRACK]

 draft-ietf-v6ops-3177bis-end-sites-01 RFC3177 BCP0157 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC6177 RFC6178 Label Edge Router Forwarding of IPv4 Option Packets D. Smith J. Mullooly W. Jaeger T. Scholl March 2011 ASCII HTML 9 FEC MPLS LER Security DoS

This document specifies how Label Edge Routers (LERs) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options. Lack of a formal standard has resulted in different LER forwarding behaviors for IPv4 packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC). IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS- encapsulated, present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IPv4 packets with header options cannot operate in certain MPLS environments. While this newly defined LER behavior is mandatory to implement, it is optional to invoke. [STANDARDS-TRACK]

 draft-ietf-mpls-ip-options-07 RFC3031 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6178 RFC6179 The Internet Routing Overlay Network (IRON) F. Templin Editor March 2011 ASCII HTML 37 Encapsulation Tunnel Architecture Scalability Mobility MANET Security Recursion Addressing Routing IPv6 Aerospace Aeronautics Space IRON RANGER VET SEAL ISATAP

Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes an Internet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system. IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-templin-iron-17 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6179 RFC6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment J. Arkko F. Baker May 2011 ASCII HTML 20

The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-arkko-ipv6-transition-guidelines-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6180 RFC6181 Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses M. Bagnulo March 2011 ASCII HTML 17 Multipath TCP threats security MPTCP

Multipath TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mptcp-threat-08 INFORMATIONAL INFORMATIONAL IETF tsv mptcp http://www.rfc-editor.org/errata_search.php?rfc=6181 10.17487/RFC6181 RFC6182 Architectural Guidelines for Multipath TCP Development A. Ford C. Raiciu M. Handley S. Barre J. Iyengar March 2011 ASCII HTML 28 multipath tcp architecture

Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput.

This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP (MPTCP). This document lists certain high-level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mptcp-architecture-05 INFORMATIONAL INFORMATIONAL IETF tsv mptcp 10.17487/RFC6182 RFC6183 IP Flow Information Export (IPFIX) Mediation: Framework A. Kobayashi B. Claise G. Muenz K. Ishibashi April 2011 ASCII HTML 29

This document describes a framework for IP Flow Information Export (IPFIX) Mediation. This framework extends the IPFIX reference model specified in RFC 5470 by defining the IPFIX Mediator components. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ipfix-mediators-framework-09 RFC5470 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6183 10.17487/RFC6183 RFC6184 RTP Payload Format for H.264 Video Y.-K. Wang R. Even T. Kristensen R. Jesup May 2011 ASCII HTML 101 AVC H.264/AVC Advanced Video Coding

This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand.

This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in Section 14. Issues on backward compatibility to RFC 3984 are discussed in Section 15. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-rfc3984bis-12 RFC3984 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=6184 10.17487/RFC6184 RFC6185 RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video T. Kristensen P. Luthi May 2011 ASCII HTML 22 H.264 H.241 ITU-T RTP Video SDP RCDO

This document describes an RTP payload format for the Reduced- Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241. RCDO reduces the decoding cost and resource consumption of the video processing. The RCDO RTP payload format is based on the H.264 RTP payload format. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-h264-rcdo-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6185 RFC6186 Use of SRV Records for Locating Email Submission/Access Services C. Daboo March 2011 ASCII HTML 9 imap pop3 smtp dns discovery

This specification describes how SRV records can be used to locate email services. [STANDARDS-TRACK]

 draft-daboo-srv-email-05 RFC1939 RFC3501 RFC8314 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6186 RFC6187 X.509v3 Certificates for Secure Shell Authentication K. Igoe D. Stebila March 2011 ASCII HTML 16

X.509 public key certificates use a signature by a trusted certification authority to bind a given public key to a given digital identity. This document specifies how to use X.509 version 3 public key certificates in public key algorithms in the Secure Shell protocol. [STANDARDS-TRACK]

 draft-igoe-secsh-x509v3-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6187 RFC6188 The Use of AES-192 and AES-256 in Secure RTP D. McGrew March 2011 ASCII HTML 16 SRTP

This memo describes the use of the Advanced Encryption Standard (AES) with 192- and 256-bit keys within the Secure RTP (SRTP) protocol. It details counter mode encryption for SRTP and Secure Realtime Transport Control Protocol (SRTCP) and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. [STANDARDS-TRACK]

 draft-ietf-avt-srtp-big-aes-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6188 RFC6189 ZRTP: Media Path Key Agreement for Unicast Secure RTP P. Zimmermann A. Johnston Editor J. Callas April 2011 ASCII HTML 115

This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-zimmermann-avt-zrtp-22 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6189 RFC6190 RTP Payload Format for Scalable Video Coding S. Wenger Y.-K. Wang T. Schierl A. Eleftheriadis May 2011 ASCII HTML 100 SVC AVC H.264/AVC Advanced Video Coding Scalable Video Coding

This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 6184. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-svc-27 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload http://www.rfc-editor.org/errata_search.php?rfc=6190 10.17487/RFC6190 RFC6191 Reducing the TIME-WAIT State Using TCP Timestamps F. Gont April 2011 ASCII HTML 10

This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. This memo documents an Internet Best Current Practice.

 draft-ietf-tcpm-tcp-timestamps-04 BCP0159 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tcpm 10.17487/RFC6191 RFC6192 Protecting the Router Control Plane D. Dugal C. Pignataro R. Dunn March 2011 ASCII HTML 25 ACL Router Control Plane Protection Filter

This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level.

Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-opsec-protect-control-plane-06 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=6192 10.17487/RFC6192 RFC6193 Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP) M. Saito D. Wing M. Toyama April 2011 ASCII HTML 22 SIP IPsec setup VPN

This document specifies how to establish a media session that represents a virtual private network using the Session Initiation Protocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of the Session Description Protocol (SDP) so that it can negotiate use of the Internet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. It also specifies a method to boot up IKE and generate IPsec security associations using a self-signed certificate. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-saito-mmusic-sdp-ike-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6193 RFC6194 Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms T. Polk L. Chen S. Turner P. Hoffman March 2011 ASCII HTML 7

This document includes security considerations for the SHA-0 and SHA-1 message digest algorithm. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-sha0-sha1-seccon-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6194 10.17487/RFC6194 RFC6195 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd March 2011 ASCII HTML 17 RRTYPE RCODE AFSDB

This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. This memo documents an Internet Best Current Practice.

 draft-ietf-dnsext-5395bis-03 RFC5395 RFC6895 RFC1183 RFC3597 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC6195 RFC6196 Moving mailserver: URI Scheme to Historic A. Melnikov March 2011 ASCII HTML 3 mailserver URI

This document registers the mailserver: URI scheme as historic in the IANA URI registry. [STANDARDS-TRACK]

 draft-melnikov-mailserver-uri-to-historic-00 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6196 10.17487/RFC6196 RFC6197 Location-to-Service Translation (LoST) Service List Boundary Extension K. Wolf April 2011 ASCII HTML 15 listservicesbylocation

Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation> query to the LoST server. However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-ecrit-lost-servicelistboundary-05 EXPERIMENTAL EXPERIMENTAL IETF rai ecrit 10.17487/RFC6197 RFC6198 Requirements for the Graceful Shutdown of BGP Sessions B. Decraene P. Francois C. Pelsser Z. Ahmad A.J. Elizondo Armengol T. Takeda April 2011 ASCII HTML 20 routing BGP graceful shutdown connectivity loss maintenance network operation make-before-break planned

The Border Gateway Protocol (BGP) is heavily used in Service Provider networks for both Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an Autonomous System Border Router (ASBR) or BGP session breakdown on customers' or peers' traffic. However, simply taking down or even bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no longer satisfactory for new applications (e.g., voice over IP, online gaming, VPN). Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown. This document expresses requirements for such a solution. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-grow-bgp-graceful-shutdown-requirements-07 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6198 RFC6199 RFC6200 RFC6201 Device Reset Characterization R. Asati C. Pignataro F. Calabria C. Olvera March 2011 ASCII HTML 17 operation redundancy failover

An operational forwarding device may need to be restarted (automatically or manually) for a variety of reasons, an event called a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation.

This document specifies a methodology for characterizing reset (and reset time) during benchmarking of forwarding devices and provides clarity and consistency in reset test procedures beyond what is specified in RFC 2544. Therefore, it updates RFC 2544. This document also defines the benchmarking term "reset time" and, only in this, updates RFC 1242. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-bmwg-reset-06 RFC1242 RFC2544 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6201 RFC6202 Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP S. Loreto P. Saint-Andre S. Salsano G. Wilkins April 2011 ASCII HTML 19 Hypertext Transfer Protocol bidirectional HTTP HTTP long polling HTTP streaming

On today's Internet, the Hypertext Transfer Protocol (HTTP) is often used (some would say abused) to enable asynchronous, "server- initiated" communication from a server to a client as well as communication from a client to a server. This document describes known issues and best practices related to such "bidirectional HTTP" applications, focusing on the two most common mechanisms: HTTP long polling and HTTP streaming. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-loreto-http-bidirectional-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6202 RFC6203 IMAP4 Extension for Fuzzy Search T. Sirainen March 2011 ASCII HTML 7 email

This document describes an IMAP protocol extension enabling a server to perform searches with inexact matching and assigning relevancy scores for matched messages. [STANDARDS-TRACK]

 draft-ietf-morg-fuzzy-search-03 PROPOSED STANDARD PROPOSED STANDARD IETF app morg 10.17487/RFC6203 RFC6204 Basic Requirements for IPv6 Customer Edge Routers H. Singh W. Beebee C. Donley B. Stark O. Troan Editor April 2011 ASCII HTML 17 IPv6 CE requirements

This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-ipv6-cpe-router-09 RFC7084 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=6204 10.17487/RFC6204 RFC6205 Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers T. Otani Editor D. Li Editor March 2011 ASCII HTML 15 DWDM CWDM Wavelength Label LSC

Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed.

Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a range of technologies including wavelength (or lambda) switching. For this purpose, GMPLS defined a wavelength label as only having significance between two neighbors. Global wavelength semantics are not considered.

In order to facilitate interoperability in a network composed of next generation lambda-switch-capable equipment, this document defines a standard lambda label format that is compliant with the Dense Wavelength Division Multiplexing (DWDM) and Coarse Wavelength Division Multiplexing (CWDM) grids defined by the International Telecommunication Union Telecommunication Standardization Sector. The label format defined in this document can be used in GMPLS signaling and routing protocols. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-g-694-lambda-labels-11 RFC3471 RFC7699 RFC8359 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6205 RFC6206 The Trickle Algorithm P. Levis T. Clausen J. Hui O. Gnawali J. Ko March 2011 ASCII HTML 13 Consistency Eventual consistency Low-power Low power

The Trickle algorithm allows nodes in a lossy shared medium (e.g., low-power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allow Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. [STANDARDS-TRACK]

 draft-ietf-roll-trickle-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC6206 RFC6207 The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml R. Denenberg Editor April 2011 ASCII HTML 11 mods Metadata Object Description Schema MADS Metadata Authority Description Schema METS Metadata Encoding and Transmission Standard MARCXML MARC21 XML Schema SRU Search/Retrieve via URL Response Format

This document specifies media types for the following formats: MODS (Metadata Object Description Schema), MADS (Metadata Authority Description Schema), METS (Metadata Encoding and Transmission Standard), MARCXML (MARC21 XML Schema), and the SRU (Search/Retrieve via URL Response Format) protocol response XML schema. These are all XML schemas providing representations of various forms of information including metadata and search results. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-denenberg-mods-etc-media-types-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6207 RFC6208 Cloud Data Management Interface (CDMI) Media Types K. Sankar Editor A. Jones April 2011 ASCII HTML 13 snia Storage Networking Industry Association

This document describes several Internet media types defined for the Cloud Data Management Interface (CDMI) by the Storage Networking Industry Association (SNIA). The media types are:

o application/cdmi-object

o application/cdmi-container

o application/cdmi-domain

o application/cdmi-capability

o application/cdmi-queue

This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-cdmi-mediatypes-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6208 RFC6209 Addition of the ARIA Cipher Suites to Transport Layer Security (TLS) W. Kim J. Lee J. Park D. Kwon April 2011 ASCII HTML 9 aria encryption

This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol to support the ARIA encryption algorithm as a block cipher. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-nsri-tls-aria-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6209 RFC6210 Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME J. Schaad April 2011 ASCII HTML 14 example MD5-XOR Parameterized

New hash algorithms are being developed that may include parameters. Cryptographic Message Syntax (CMS) has not currently defined any hash algorithms with parameters, but anecdotal evidence suggests that defining one could cause major problems. This document defines just such an algorithm and describes how to use it so that experiments can be run to find out how bad including hash parameters will be. This document defines an Experimental Protocol for the Internet community.

 draft-schaad-smime-hash-experiment-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6210 10.17487/RFC6210 RFC6211 Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute J. Schaad April 2011 ASCII HTML 11 example s/mime SMIME

The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. [STANDARDS-TRACK]

 draft-schaad-smime-algorithm-attribute-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6211 RFC6212 Authentication-Results Registration for Vouch by Reference Results M. Kucherawy April 2011 ASCII HTML 7 VBR Reputation DKIM

This memo updates the registry of properties in Authentication- Results: message header fields to allow relaying of the results of a Vouch By Reference query. [STANDARDS-TRACK]

 draft-kucherawy-authres-vbr-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6212 RFC6213 IS-IS BFD-Enabled TLV C. Hopps L. Ginsberg April 2011 ASCII HTML 7 type-length-value Bidirectional Forwarding Detection

This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection (BFD) protocol. There exist certain scenarios in which IS-IS will not react appropriately to a BFD-detected forwarding plane failure without use of either this TLV or some other method. [STANDARDS-TRACK]

 draft-ietf-isis-bfd-tlv-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6213 RFC6214 Adaptation of RFC 1149 for IPv6 B. Carpenter R. Hinden April 1 2011 ASCII HTML 7 avian carrier april fool

This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-carpenter-6man-adapt-rfc1149-00 RFC1149 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6214 10.17487/RFC6214 RFC6215 MPLS Transport Profile User-to-Network and Network-to-Network Interfaces M. Bocci L. Levrau D. Frost April 2011 ASCII HTML 6

The framework for MPLS in transport networks (RFC 5921) provides reference models for the MPLS Transport Profile (MPLS-TP) Transport Service Interfaces, which are a User-to-Network Interface (UNI), and a Network-to-Network Interface (NNI). This document updates those reference models to show detailed reference points for these interfaces, along with further clarification of the functional architecture of MPLS-TP at a UNI and NNI.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-uni-nni-03 RFC5921 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6215 RFC6216 Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms C. Jennings K. Ono R. Sparks B. Hibbard Editor April 2011 ASCII HTML 67

This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sipcore-sec-flows-09 INFORMATIONAL INFORMATIONAL IETF rai sipcore 10.17487/RFC6216 RFC6217 Regional Broadcast Using an Atmospheric Link Layer T. Ritter April 1 2011 ASCII HTML 9

Broadcasting is a technology that has been largely discarded in favor of technologies like multicast. This document builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets destined for multiple Local Area Networks (LANs) or Metropolitan Area Networks (MANs) using an alternative link layer. It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ritter-regional-bcast-atmospheric-linklayer-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6217 RFC6218 Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material G. Zorn T. Zhang J. Walker J. Salowey April 2011 ASCII HTML 18 Security

This document defines a set of vendor-specific RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. These attributes have been allocated from the Cisco vendor-specific space and have been implemented by multiple vendors. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-zorn-radius-keywrap-18 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6218 10.17487/RFC6218 RFC6219 The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition X. Li C. Bao M. Chen H. Zhang J. Wu May 2011 ASCII HTML 22 Stateless IPv4/IPv6 translation IPv4/IPv6 Header Translation IPv4-embedded IPv6 Address IPv4/IPv6 Multicast Translation stateless NAT64

This document presents the China Education and Research Network (CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition.

The IVI is a prefix-specific and stateless address mapping mechanism for "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to an IPv6 network" scenarios. In the IVI design, subsets of the ISP's IPv4 addresses are embedded in the ISP's IPv6 addresses, and the hosts using these IPv6 addresses can therefore communicate with the global IPv6 Internet directly and can communicate with the global IPv4 Internet via stateless translators. The communications can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. The IVI is an early design deployed in the CERNET as a reference for the IETF standard documents on IPv4/IPv6 stateless translation. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-xli-behave-ivi-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6219 RFC6220 Defining the Role and Function of IETF Protocol Parameter Registry Operators D. McPherson Editor O. Kolkman Editor J. Klensin Editor G. Huston Editor Internet Architecture Board April 2011 ASCII HTML 11

Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-iana-08 RFC8722 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6220 RFC6221 Lightweight DHCPv6 Relay Agent D. Miles Editor S. Ooghe W. Dec S. Krishnan A. Kavanagh May 2011 ASCII HTML 17 ipv6 dsl

This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-ldra-03 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6221 10.17487/RFC6221 RFC6222 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) A. Begen C. Perkins D. Wing April 2011 ASCII HTML 9

The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. This memo updates those guidelines to allow endpoints to choose unique RTCP CNAMEs. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-cnames-05 RFC7022 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6222 RFC6223 Indication of Support for Keep-Alive C. Holmberg April 2011 ASCII HTML 18 SIP STUN outbound NAT traversal

This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. [STANDARDS-TRACK]

 draft-ietf-sipcore-keep-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6223 RFC6224 Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains T. Schmidt M. Waehlisch S. Krishnan April 2011 ASCII HTML 19 MLD proxy multicast routing mobility management transparent handover

This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to home agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide Multicast Listener Discovery (MLD) proxy functions. In this scenario, mobile nodes remain agnostic of multicast mobility operations. Support for mobile multicast senders is outside the scope of this document. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-multimob-pmipv6-base-solution-07 INFORMATIONAL INFORMATIONAL IETF int multimob 10.17487/RFC6224 RFC6225 Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information J. Polk M. Linsner M. Thomson B. Aboba Editor July 2011 ASCII HTML 36

This document specifies Dynamic Host Configuration Protocol options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes Latitude, Longitude, and Altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values. This document obsoletes RFC 3825. [STANDARDS-TRACK]

 draft-ietf-geopriv-rfc3825bis-17 RFC3825 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=6225 10.17487/RFC6225 RFC6226 PIM Group-to-Rendezvous-Point Mapping B. Joshi A. Kessler D. McWalter May 2011 ASCII HTML 11 auto-RP BSR hash algorithm

Each Protocol Independent Multicast - Sparse Mode (PIM-SM) router in a PIM domain that supports Any Source Multicast (ASM) maintains Group-to-RP mappings that are used to identify a Rendezvous Point (RP) for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned.

This document defines a standard algorithm to deterministically choose between several Group-to-RP mappings for a specific group. This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm. [STANDARDS-TRACK]

 draft-ietf-pim-group-rp-mapping-10 RFC4601 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6226 RFC6227 Design Goals for Scalable Internet Routing T. Li Editor May 2011 ASCII HTML 8 routing architecture addressing architecture

It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, mobility, multi-homing, and inter-domain traffic engineering. The Routing Research Group is investigating an alternate architecture to meet these challenges. This document consists of a prioritized list of design goals for the target architecture. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-rrg-design-goals-06 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6227 RFC6228 Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog C. Holmberg May 2011 ASCII HTML 14 199 Early dialog Forking Provisional response

This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. [STANDARDS-TRACK]

 draft-ietf-sipcore-199-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6228 10.17487/RFC6228 RFC6229 Test Vectors for the Stream Cipher RC4 J. Strombergson S. Josefsson May 2011 ASCII HTML 12 arcfour128 arcfour256 arcfour ARC4m Stream Cipher Test Vectors Known Answer Test arcfour ARC4 WEP WPA RFC 4345

This document contains test vectors for the stream cipher RC4. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-josefsson-rc4-test-vectors-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6229 RFC6230 Media Control Channel Framework C. Boulton T. Melanchuk S. McGlashan May 2011 ASCII HTML 49

This document describes a framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers.

The motivation for the creation of this framework is to provide an interface suitable to meet the requirements of a centralized conference system, where the conference system can be distributed, as defined by the XCON working group in the IETF. It is not, however, limited to this scope. [STANDARDS-TRACK]

 draft-ietf-mediactrl-sip-control-framework-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl 10.17487/RFC6230 RFC6231 An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework S. McGlashan T. Melanchuk C. Boulton May 2011 ASCII HTML 134

This document defines a Media Control Channel Framework Package for Interactive Voice Response (IVR) dialog interaction on media connections and conferences. The package defines dialog management request elements for preparing, starting, and terminating dialog interactions, as well as associated responses and notifications. Dialog interactions are specified in a dialog language. This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, Dual-Tone Multi-Frequency (DTMF) collection, and media recording) and allows other dialog languages to be used. The package also defines elements for auditing package capabilities and IVR dialogs. [STANDARDS-TRACK]

 draft-ietf-mediactrl-ivr-control-package-11 RFC6623 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl http://www.rfc-editor.org/errata_search.php?rfc=6231 10.17487/RFC6231 RFC6232 Purge Originator Identification TLV for IS-IS F. Wei Y. Qin Z. Li T. Li J. Dong May 2011 ASCII HTML 6 Purge Originator Identification IIH:n LSP:y SNP:n Purge:y

At present, an IS-IS purge does not contain any information identifying the Intermediate System (IS) that generates the purge. This makes it difficult to locate the source IS.

To address this issue, this document defines a TLV to be added to purges to record the system ID of the IS generating it. Since normal Link State Protocol Data Unit (LSP) flooding does not change LSP contents, this TLV should propagate with the purge.

This document updates RFC 5301, RFC 5304, and RFC 5310. [STANDARDS-TRACK]

 draft-ietf-isis-purge-tlv-05 RFC5301 RFC5304 RFC5310 RFC8918 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6232 RFC6233 IS-IS Registry Extension for Purges T. Li L. Ginsberg May 2011 ASCII HTML 4 Intermediate System to Intermediate System LSP security authentication IANA

IANA maintains the "IS-IS TLV Codepoints" registry. This registry documents which TLVs can appear in different types of IS-IS Protocol Data Units (PDUs), but does not document which TLVs can be found in zero Remaining Lifetime Link State PDUs (LSPs), a.k.a. purges. This document extends the existing registry to record the set of TLVs that are permissible in purges and updates the rules for generating and processing purges in the presence of authentication. This document updates RFC 3563, RFC 5304, and RFC 5310. [STANDARDS-TRACK]

 draft-ietf-isis-reg-purge-01 RFC3563 RFC5304 RFC5310 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6233 RFC6234 US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) D. Eastlake 3rd T. Hansen May 2011 ASCII HTML 127

Federal Information Processing Standard, FIPS

 draft-eastlake-sha2b-07 RFC4634 RFC3174 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6234 10.17487/RFC6234 RFC6235 IP Flow Anonymization Support E. Boschi B. Trammell May 2011 ASCII HTML 43 IPFIX flow information export address anonymization pseudonymization data protection privacy

This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export (IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-ipfix-anon-06 EXPERIMENTAL EXPERIMENTAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6235 10.17487/RFC6235 RFC6236 Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) I. Johansson K. Jung May 2011 ASCII HTML 23

This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a \%low-end \%hand- held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The document also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. [STANDARDS-TRACK]

 draft-ietf-mmusic-image-attributes-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=6236 10.17487/RFC6236 RFC6237 IMAP4 Multimailbox SEARCH Extension B. Leiba A. Melnikov May 2011 ASCII HTML 10 email multiple mailboxes imapext

The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-morg-multimailbox-search-07 RFC7377 RFC4466 EXPERIMENTAL EXPERIMENTAL IETF app morg 10.17487/RFC6237 RFC6238 TOTP: Time-Based One-Time Password Algorithm D. M'Raihi S. Machani M. Pei J. Rydell May 2011 ASCII HTML 16 OTP OATH HOTP two factor authentication strong authentication

This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in RFC 4226, to support the time-based moving factor. The HOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant of the OTP algorithm provides short-lived OTP values, which are desirable for enhanced security.

The proposed algorithm can be used across a wide range of network applications, from remote Virtual Private Network (VPN) access and Wi-Fi network logon to transaction-oriented Web applications. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mraihi-totp-timebased-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6238 10.17487/RFC6238 RFC6239 Suite B Cryptographic Suites for Secure Shell (SSH) K. Igoe May 2011 ASCII HTML 14

This document describes the architecture of a Suite B compliant implementation of the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol. Suite B Secure Shell makes use of the elliptic curve Diffie-Hellman (ECDH) key agreement, the elliptic curve digital signature algorithm (ECDSA), the Advanced Encryption Standard running in Galois/Counter Mode (AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and SHA-384), and X.509 certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-igoe-secsh-suiteb-06 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6239 RFC6240 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2 D. Zelig Editor R. Cohen Editor T. Nadeau Editor May 2011 ASCII HTML 67 management information base PW-CEP-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits over a Packet Switch Network (PSN). [STANDARDS-TRACK]

 draft-ietf-pwe3-cep-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6240 RFC6241 Network Configuration Protocol (NETCONF) R. Enns Editor M. Bjorklund Editor J. Schoenwaelder Editor A. Bierman Editor June 2011 ASCII HTML 113 XML Configuration Network Management Extensible Markup Language

The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]

 draft-ietf-netconf-4741bis-10 RFC4741 RFC7803 RFC8526 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6241 10.17487/RFC6241 RFC6242 Using the NETCONF Protocol over Secure Shell (SSH) M. Wasserman June 2011 ASCII HTML 11 network configuration protocol

This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]

 draft-ietf-netconf-rfc4742bis-08 RFC4742 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6242 10.17487/RFC6242 RFC6243 With-defaults Capability for NETCONF A. Bierman B. Lengyel June 2011 ASCII HTML 26 network configuration protocol

The Network Configuration Protocol (NETCONF) defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. [STANDARDS-TRACK]

 draft-ietf-netconf-with-defaults-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6243 10.17487/RFC6243 RFC6244 An Architecture for Network Management Using NETCONF and YANG P. Shafer June 2011 ASCII HTML 30 network configuration protocol

The Network Configuration Protocol (NETCONF) gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities.

This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-netmod-arch-10 INFORMATIONAL INFORMATIONAL IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6244 10.17487/RFC6244 RFC6245 Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4 P. Yegani K. Leung A. Lior K. Chowdhury J. Navali May 2011 ASCII HTML 8

The Generic Routing Encapsulation (GRE) specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field. This extension further allows the Mobility Agents to set up the necessary protocol interfaces prior to receiving the mobile node traffic. The new extension allows a Foreign Agent to request GRE tunneling without disturbing the Home Agent behavior specified for Mobile IPv4. GRE tunneling with the Key field allows the operators to have home networks that consist of multiple Virtual Private Networks (VPNs), which may have overlapping home addresses. When the tuple <Care of Address, Home Address, and Home Agent Address> is the same across multiple subscriber sessions, GRE tunneling will provide a means for the Foreign Agent and Home Agent to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other -- a significant drawback when using IP-in-IP tunneling. [STANDARDS-TRACK]

 draft-ietf-mip4-gre-key-extension-05 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC6245 RFC6246 Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges A. Sajassi Editor F. Brockners D. Mohan Editor Y. Serbest June 2011 ASCII HTML 20 ieee bridges

One of the main motivations behind Virtual Private LAN Service (VPLS) is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers.

When customer edge (CE) devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have been addressed in the IEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This document extends the provider edge (PE) model described in RFC 4664 based on IEEE 802.1ad bridge module, and it illustrates a clear demarcation between the IEEE bridge module and IETF LAN emulation module. By doing so, it shows that the majority of interoperability issues with CE bridges can be delegated to the 802.1ad bridge module, thus removing the burden on the IETF LAN emulation module within a VPLS PE. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-l2vpn-vpls-bridge-interop-06 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC6246 RFC6247 Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status L. Eggert May 2011 ASCII HTML 4

This document reclassifies several TCP extensions that have never seen widespread use to Historic status. The affected RFCs are RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-eggert-tcpm-historicize-02 RFC1072 RFC1106 RFC1110 RFC1145 RFC1146 RFC1379 RFC1644 RFC1693 RFC4614 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC6247 RFC6248 RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete A. Morton April 2011 ASCII HTML 6

This memo reclassifies RFC 4148, "IP Performance Metrics (IPPM) Metrics Registry", as Obsolete, and withdraws the IANA IPPM Metrics Registry itself from use because it is obsolete. The current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics. Despite apparent efforts to find current or even future users, no one responded to the call for interest in the RFC 4148 registry during the second half of 2010. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-morton-ippm-rfc4148-obsolete-03 RFC4148 RFC4737 RFC5560 RFC5644 RFC6049 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6248 RFC6249 Metalink/HTTP: Mirrors and Hashes A. Bryan N. McNab T. Tsujikawa P. Poeml H. Nordstrom June 2011 ASCII HTML 21 file transfer download link signature data integrity hypertext transfer protocol ftp file transfer protocol metadata torrent

This document specifies Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields. Metalink clients can use this information to make file transfers more robust and reliable. Normative requirements for Metalink/HTTP clients and servers are described here. [STANDARDS-TRACK]

 draft-bryan-metalinkhttp-22 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6249 10.17487/RFC6249 RFC6250 Evolution of the IP Model D. Thaler May 2011 ASCII HTML 25 Internet Protocol IPv4 IPv6 service model

This RFC attempts to document various aspects of the IP service model and how it has evolved over time. In particular, it attempts to document the properties of the IP layer as they are seen by upper- layer protocols and applications, especially properties that were (and, at times, still are) incorrectly perceived to exist as well as properties that would cause problems if changed. The discussion of these properties is organized around evaluating a set of claims, or misconceptions. Finally, this document provides some guidance to protocol designers and implementers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-ip-model-evolution-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6250 RFC6251 Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol S. Josefsson May 2011 ASCII HTML 8 kerberos tls starttls kdc

This document specifies how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol in order to provide additional security features. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-josefsson-kerberos5-starttls-09 INFORMATIONAL INFORMATIONAL IETF sec krb-wg 10.17487/RFC6251 RFC6252 A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization A. Dutta Editor V. Fajardo Y. Ohba K. Taniuchi H. Schulzrinne June 2011 ASCII HTML 57 Mobility Optimization Proactive handoff Link-layer security Handover taxonomy Layer 2 handoff Layer 3 handoff Network discovery Handover delay Packet loss Proactive binding update Multi-interface IP address acquisition Tunnel management

This document describes Media-independent Pre-Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile- assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol, and is most applicable to supporting optimization during inter-domain handover. MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff-related operations to take place before the mobile node has moved to the new network. We describe the details of all the associated techniques and their applicability for different scenarios involving various mobility protocols during inter-domain handover. We have implemented the MPA mechanism for various network-layer and application-layer mobility protocols, and we report a summary of experimental performance results in this document.

This document is a product of the IP Mobility Optimizations (MOBOPTS) Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-mobopts-mpa-framework-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6252 RFC6253 Host Identity Protocol Certificates T. Heer S. Varjonen May 2011 ASCII HTML 12

The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the CERT parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) and Simple Public Key Infrastructure (SPKI) certificates.

The concrete use of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, is specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter.

This document updates RFC 5201. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-cert-12 RFC8002 RFC5201 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6253 RFC6254 Request to Move RFC 2754 to Historic Status M. McFadden May 2011 ASCII HTML 3 RPS

RFC 2754 requested that each time IANA made an address assignment, it was to create appropriate inetnum and as-block objects and digitally sign them. The purpose was to distribute the IANA-held public key in software implementations of the Distributed Routing Policy System. In practice, this was never done on the public Internet. This document requests that RFC 2754 be moved to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iana-rfc2754-to-historic-02 RFC2754 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6254 RFC6255 Delay-Tolerant Networking Bundle Protocol IANA Registries M. Blanchet May 2011 ASCII HTML 9 DTN SNDV DTNRG Space networking

The Delay-Tolerant Networking (DTN) Research Group research group has defined many protocols such as the Bundle Protocol and Licklider Transmission Protocol. The specifications of these protocols contain fields that are subject to a registry. For the purpose of its research work, the group created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official custody. This document describes the actions executed by IANA. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-dtnrg-iana-bp-registries-02 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6255 RFC6256 Using Self-Delimiting Numeric Values in Protocols W. Eddy E. Davies May 2011 ASCII HTML 17 SDNV DTN

Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols. SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bitstring with minimum overhead. They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development. This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-dtnrg-sdnv-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6256 RFC6257 Bundle Security Protocol Specification S. Symington S. Farrell H. Weiss P. Lovell May 2011 ASCII HTML 60

This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol. Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options.

This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-bundle-security-19 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6257 10.17487/RFC6257 RFC6258 Delay-Tolerant Networking Metadata Extension Block S. Symington May 2011 ASCII HTML 10 DTN Delay-Tolerant Networking Distruption-Tolerant Networking

This document defines an extension block that may be used with the Delay-Tolerant Networking (DTN) Bundle Protocol. This Metadata Extension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle. The metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for carrying URIs as metadata, is defined in this document. Other metadata types may be defined in separate documents. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-bundle-metadata-block-10 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6258 RFC6259 Delay-Tolerant Networking Previous-Hop Insertion Block S. Symington May 2011 ASCII HTML 10 DTN Delay-Tolerant Networking Distruption-Tolerant Networking

This document defines an extension block for use with the Delay- Tolerant Networking (DTN) Bundle Protocol. This Previous-Hop Insertion Block (PHIB) extension block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node. Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols (e.g., flood routing). If this EID cannot be provided by the convergence layer or other means, the PHIB defines the mechanism whereby the EID can be provided with the bundle. Each PHIB is always removed from the bundle by the receiving node so that its presence within the bundle is limited to exactly one hop. This document defines the format and processing of this PHIB. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-bundle-previous-hop-block-12 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6259 RFC6260 Compressed Bundle Header Encoding (CBHE) S. Burleigh May 2011 ASCII HTML 12 DTN delay-tolerant networking BP bundle protocol IPN

This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.

Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing. Therefore, it has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.

This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-cbhe-09 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6260 RFC6261 Encrypted Signaling Transport Modes for the Host Identity Protocol A. Keranen May 2011 ASCII HTML 13

This document specifies two transport modes for Host Identity Protocol (HIP) signaling messages that allow them to be conveyed over encrypted connections initiated with the Host Identity Protocol. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-over-hip-06 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6261 RFC6262 RTP Payload Format for IP-MR Speech Codec S. Ikonin August 2011 ASCII HTML 19 ipmr vocoder multirate scalable scalability

This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per packet and introduces redundancy for robustness against packet loss and bit errors. [STANDARDS-TRACK]

 draft-ietf-avt-rtp-ipmr-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6262 RFC6263 Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows X. Marjou A. Sollaud June 2011 ASCII HTML 12 AVT SDP port

This document lists the different mechanisms that enable applications using the Real-time Transport Protocol (RTP) and the RTP Control Protocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents. [STANDARDS-TRACK]

 draft-ietf-avt-app-rtp-keepalive-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6263 RFC6264 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition S. Jiang D. Guo B. Carpenter June 2011 ASCII HTML 13

Global IPv6 deployment was slower than originally expected. As IPv4 address exhaustion approaches, IPv4 to IPv6 transition issues become more critical and less tractable. Host-based transition mechanisms used in dual-stack environments cannot meet all transition requirements. Most end users are not sufficiently expert to configure or maintain host-based transition mechanisms. Carrier-Grade NAT (CGN) devices with integrated transition mechanisms can reduce the operational changes required during the IPv4 to IPv6 migration or coexistence period.

This document proposes an incremental CGN approach for IPv6 transition. It can provide IPv6 access services for IPv6 hosts and IPv4 access services for IPv4 hosts while leaving much of a legacy ISP network unchanged during the initial stage of IPv4 to IPv6 migration. Unlike CGN alone, incremental CGN also supports and encourages smooth transition towards dual-stack or IPv6-only ISP networks. An integrated configurable CGN device and an adaptive home gateway (HG) device are described. Both are reusable during different transition phases, avoiding multiple upgrades. This enables IPv6 migration to be incrementally achieved according to real user requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-incremental-cgn-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6264 RFC6265 HTTP State Management Mechanism A. Barth April 2011 ASCII HTML 37 Cookie Set-Cookie Secure HttpOnly

This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]

 draft-ietf-httpstate-cookie-23 RFC2965 PROPOSED STANDARD PROPOSED STANDARD IETF app httpstate http://www.rfc-editor.org/errata_search.php?rfc=6265 10.17487/RFC6265 RFC6266 Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) J. Reschke June 2011 ASCII HTML 14 filename attachment inline

RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects. [STANDARDS-TRACK]

 draft-ietf-httpbis-content-disp-09 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=6266 10.17487/RFC6266 RFC6267 MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) V. Cakulev G. Sundaram June 2011 ASCII HTML 30 Identity based encryption authentication key agreement

This document describes a key management protocol variant for the Multimedia Internet KEYing (MIKEY) protocol that relies on a trusted key management service. In particular, this variant utilizes Identity-Based Authenticated Key Exchange (IBAKE) framework that allows the participating clients to perform mutual authentication and derive a session key in an asymmetric Identity-Based Encryption (IBE) framework. This protocol, in addition to providing mutual authentication, eliminates the key escrow problem that is common in standard IBE and provides perfect forward and backward secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-cakulev-mikey-ibake-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6267 RFC6268 Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX) J. Schaad S. Turner July 2011 ASCII HTML 33 ASN.1 Certficate Extensions HMAC

The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-additional-new-asn-08 RFC5911 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6268 RFC6269 Issues with IP Address Sharing M. Ford Editor M. Boucadair A. Durand P. Levis P. Roberts June 2011 ASCII HTML 29 IPv4 address exhaustion completion shared sharing issues

The completion of IPv4 address allocations from IANA and the Regional Internet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope.

Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-intarea-shared-addressing-issues-05 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC6269 RFC6270 The 'tn3270' URI Scheme M. Yevstifeyev June 2011 ASCII HTML 6 URI Telnet Telnet 3270 TN3270

This document is the specification of the 'tn3270' Uniform Resource Identifier (URI) scheme, which is used to designate the access to the resources available via Telnet 3270 mode (TN3270) and Telnet 3270 Enhanced mode (TN3270E). It updates RFC 1041 and RFC 2355, which specify these protocols, and RFC 1738, which firstly mentioned this URI scheme without defining its syntax and semantics. [STANDARDS-TRACK]

 draft-yevstifeyev-tn3270-uri-18 RFC2355 RFC1738 RFC1041 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6270 10.17487/RFC6270 RFC6271 Requirements for SIP-Based Session Peering J-F. Mule June 2011 ASCII HTML 23 IETF speermint guidelines requirements for session interconnects session peering SIP interconnects VoIP peering

This memo captures protocol requirements to enable session peering of voice, presence, instant messaging, and other types of multimedia traffic. This informational document is intended to link the various use cases described for session peering to protocol solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-speermint-requirements-11 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6271 RFC6272 Internet Protocols for the Smart Grid F. Baker D. Meyer June 2011 ASCII HTML 66

This note identifies the key infrastructure protocols of the Internet Protocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from the picture presented here. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-baker-ietf-core-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6272 RFC6273 The Secure Neighbor Discovery (SEND) Hash Threat Analysis A. Kukec S. Krishnan S. Jiang June 2011 ASCII HTML 7

This document analyzes the use of hashes in Secure Neighbor Discovery (SEND), the possible threats to these hashes and the impact of recent attacks on hash functions used by SEND. The SEND specification currently uses the SHA-1 hash algorithm and PKIX certificates and does not provide support for hash algorithm agility. This document provides an analysis of possible threats to the hash algorithms used in SEND. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-csi-hash-threat-12 INFORMATIONAL INFORMATIONAL IETF int csi 10.17487/RFC6273 RFC6274 Security Assessment of the Internet Protocol Version 4 F. Gont July 2011 ASCII HTML 75 vulnerabilities Denial of Service resiliency hardening information leakage

This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-opsec-ip-security-07 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=6274 10.17487/RFC6274 RFC6275 Mobility Support in IPv6 C. Perkins Editor D. Johnson J. Arkko July 2011 ASCII HTML 169 MIPv6 mobility IPv6 internet protocol nodes

This document specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. [STANDARDS-TRACK]

 draft-ietf-mext-rfc3775bis-13 RFC3775 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=6275 10.17487/RFC6275 RFC6276 DHCPv6 Prefix Delegation for Network Mobility (NEMO) R. Droms P. Thubert F. Dupont W. Haddad C. Bernardos July 2011 ASCII HTML 14 IPv6 mobile router home agent mobile network prefix

One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router for use on the links in the mobile network. This document specifies how DHCPv6 prefix delegation can be used for this configuration task. The mobile router plays the role of requesting router, while the home agent assumes the role of delegating router. When the mobile router is outside its home network, the mobile router also assumes the role of DHCPv6 relay agent, co-located with the requesting router function. [STANDARDS-TRACK]

 draft-ietf-mext-nemo-pd-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=6276 10.17487/RFC6276 RFC6277 Online Certificate Status Protocol Algorithm Agility S. Santesson P. Hallam-Baker June 2011 ASCII HTML 11 ocsp

The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used. This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use. This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. [STANDARDS-TRACK]

 draft-ietf-pkix-ocspagility-10 RFC6960 RFC2560 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=6277 10.17487/RFC6277 RFC6278 Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax J. Herzog R. Khazan June 2011 ASCII HTML 16 set-key group-key

This document describes how to use the 'static-static Elliptic Curve Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie- Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax. In this form of key agreement, the Diffie-Hellman values of both the sender and receiver are long-term values contained in certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-herzog-static-ecdh-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6278 RFC6279 Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement M. Liebsch Editor S. Jeong Q. Wu June 2011 ASCII HTML 14 Local Routing Route Optimization Traffic Offload

Proxy Mobile IPv6 is the IETF Standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The setup and maintenance of localized routing, which allows forwarding of data packets between two mobile nodes' Mobility Access Gateways without involvement of their Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-netext-pmip6-lr-ps-06 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC6279 RFC6280 An Architecture for Location and Location Privacy in Internet Applications R. Barnes M. Lepinski A. Cooper J. Morris H. Tschofenig H. Schulzrinne July 2011 ASCII HTML 41 geolocation geopriv

Location-based services (such as navigation applications, emergency services, and management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities. These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved. This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services. This memo documents an Internet Best Current Practice.

 draft-ietf-geopriv-arch-03 RFC3693 RFC3694 BCP0160 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai geopriv 10.17487/RFC6280 RFC6281 Understanding Apple's Back to My Mac (BTMM) Service S. Cheshire Z. Zhu R. Wakikawa L. Zhang June 2011 ASCII HTML 16

This document describes the implementation of Apple Inc.'s Back to My Mac (BTMM) service. BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road. The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery, and end-to-end connectivity in the face of Network Address Translators (NATs) and mobility of devices. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-zhu-mobileme-doc-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6281 10.17487/RFC6281 RFC6282 Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks J. Hui Editor P. Thubert September 2011 ASCII HTML 24 LLN Low Power radio 802.15.4 powerline ISA100.11a RFC 4944

This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK]

 draft-ietf-6lowpan-hc-15 RFC4944 RFC8066 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lowpan http://www.rfc-editor.org/errata_search.php?rfc=6282 10.17487/RFC6282 RFC6283 Extensible Markup Language Evidence Record Syntax (XMLERS) A. Jerman Blazic S. Saljic T. Gondrom July 2011 ASCII HTML 43 long term trust integrity long term integrity data preservation document preservation time-stamp time-stamping archive time stamp electronic archive electronic archiving trusted archiving long-term archive archive data evidence evidence record evidence record syntax hash tree ERS XML hash signature renewal algorithm cryptography

In many scenarios, users must be able to demonstrate the (time of) existence, integrity, and validity of data including signed data for long or undetermined periods of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence and integrity of data. The Extensible Markup Language Evidence Record Syntax XMLERS provides alternative syntax and processing rules to the ASN.1 (Abstract Syntax Notation One) ERS (Evidence Record Syntax) (RFC 4998) syntax by using XML. [STANDARDS-TRACK]

 draft-ietf-ltans-xmlers-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC6283 RFC6284 Port Mapping between Unicast and Multicast RTP Sessions A. Begen D. Wing T. Van Caenegem June 2011 ASCII HTML 30 Port mapping port translation RTP multicast NAT

This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. [STANDARDS-TRACK]

 draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6284 RFC6285 Unicast-Based Rapid Acquisition of Multicast RTP Sessions B. Ver Steeg A. Begen T. Van Caenegem Z. Vax June 2011 ASCII HTML 56 SSM multicast IPTV fast channel change

When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information, and the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts.

In this document, we describe a method using the existing RTP and RTP Control Protocol (RTCP) machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. [STANDARDS-TRACK]

 draft-ietf-avt-rapid-acquisition-for-rtp-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6285 RFC6286 Autonomous-System-Wide Unique BGP Identifier for BGP-4 E. Chen J. Yuan June 2011 ASCII HTML 4

To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet, unsigned, non-zero integer and relaxes the "uniqueness" requirement so that only Autonomous-System-wide (AS-wide) uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issues. This document updates RFC 4271. [STANDARDS-TRACK]

 draft-ietf-idr-bgp-identifier-14 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=6286 10.17487/RFC6286 RFC6287 OCRA: OATH Challenge-Response Algorithm D. M'Raihi J. Rydell S. Bajaj S. Machani D. Naccache June 2011 ASCII HTML 38 HOTP TOTP One-Time Password Authentication Signature

This document describes an algorithm for challenge-response authentication developed by the Initiative for Open Authentication (OATH). The specified mechanisms leverage the HMAC-based One-Time Password (HOTP) algorithm and offer one-way and mutual authentication, and electronic signature capabilities. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mraihi-mutual-oath-hotp-variants-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6287 10.17487/RFC6287 RFC6288 URN Namespace for the Defence Geospatial Information Working Group (DGIWG) C. Reed August 2011 ASCII HTML 8 Namespace Identifier nid DGIWG Registry System drs

This document describes the Namespace Identifier (NID) for Uniform Resource Name (URN) Namespace resources published by the Defence Geospatial Information Working Group (DGIWG). The DGIWG defines and manages resources that utilize this URN name model.

Management activities for these and other resource types are provided by the DGIWG Registry System (DRS). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-reed-urn-dgiwg-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6288 RFC6289 A Uniform Resource Name (URN) Namespace for CableLabs E. Cardona S. Channabasappa J-F. Mule June 2011 ASCII HTML 7 namespace identifier nid

This document describes the Namespace Identifier (NID) 'cablelabs' for Uniform Resource Names (URNs) used to identify resources published by Cable Television Laboratories, Inc. (CableLabs). CableLabs specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the CableLabs' Assigned Names and Numbers registry. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-cardona-cablelabs-urn-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6289 RFC6290 A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) Y. Nir Editor D. Wierbowski F. Detienne P. Sethi June 2011 ASCII HTML 22 QCD

This document describes an extension to the Internet Key Exchange Protocol version 2 (IKEv2) that allows for faster detection of Security Association (SA) desynchronization using a saved token.

When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text, we propose an extension to the protocol that allows for recovery immediately following the restart. [STANDARDS-TRACK]

 draft-ietf-ipsecme-failure-detection-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=6290 10.17487/RFC6290 RFC6291 Guidelines for the Use of the "OAM" Acronym in the IETF L. Andersson H. van Helvoort R. Bonica D. Romascanu S. Mansfield June 2011 ASCII HTML 9

At first glance, the acronym "OAM" seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again.

This document provides a definition of the acronym "OAM" (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. This memo documents an Internet Best Current Practice.

 draft-ietf-opsawg-mpls-tp-oam-def-10 BCP0161 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsawg 10.17487/RFC6291 RFC6292 Requirements for a Working Group Charter Tool P. Hoffman June 2011 ASCII HTML 11

The IETF intends to provide a new tool to Area Directors for the creation, re-chartering, and closing of Working Groups. The tool will also allow the IETF community to view the status of the chartering process. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-genarea-charter-tool-09 RFC6433 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6292 10.17487/RFC6292 RFC6293 Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker P. Hoffman June 2011 ASCII HTML 17

The document gives a set of requirements for extending the IETF Datatracker to give individual IETF community members, including the IETF leadership, easy methods for tracking the progress of the Internet-Drafts and RFCs of interest to them. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-genarea-datatracker-community-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6293 RFC6294 Survey of Proposed Use Cases for the IPv6 Flow Label Q. Hu B. Carpenter June 2011 ASCII HTML 18 Quality of service QoS

The IPv6 protocol includes a flow label in every packet header, but this field is not used in practice. This paper describes the flow label standard and discusses the implementation issues that it raises. It then describes various published proposals for using the flow label and shows that most of them are inconsistent with the standard. Methods to address this problem are briefly reviewed. We also question whether the standard should be revised. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-hu-flow-label-cases-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6294 RFC6295 RTP Payload Format for MIDI J. Lazzaro J. Wawrzynek June 2011 ASCII HTML 171 asc content streaming DLS 2 General MIDI MIDI MIDI file MIDI file streaming MIDI light control MIDI rendering MIDI ringtone MIDI streaming MIDI sequencer MIDI time code MIDI timecode MIDI Manufacturers Association MMA mpeg4generic MPEG 4 MPEG 4 Structured Audio MPEG 4 Synthetic Coding MTC musical notes network musical performance recovery journal Show Control sonification ringtone rtpmidi RTP RTP MIDI SMPTE time code SMPTE timecode Standard MIDI Files XMF

This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. This document obsoletes RFC 4695. [STANDARDS-TRACK]

 draft-ietf-payload-rfc4695-bis-02 RFC4695 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload http://www.rfc-editor.org/errata_search.php?rfc=6295 10.17487/RFC6295 RFC6296 IPv6-to-IPv6 Network Prefix Translation M. Wasserman F. Baker June 2011 ASCII HTML 32

This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network layer. This document defines an Experimental Protocol for the Internet community.

 draft-mrw-nat66-16 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6296 10.17487/RFC6296 RFC6297 A Survey of Lower-than-Best-Effort Transport Protocols M. Welzl D. Ros June 2011 ASCII HTML 18 Less-than-Best-Effort Congestion Control LEDBAT

This document provides a survey of transport protocols that are designed to have a smaller bandwidth and/or delay impact on standard TCP than standard TCP itself when they share a bottleneck with it. Such protocols could be used for delay-insensitive "background" traffic, as they provide what is sometimes called a "less than" (or "lower than") best-effort service. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ledbat-survey-07 INFORMATIONAL INFORMATIONAL IETF tsv ledbat 10.17487/RFC6297 RFC6298 Computing TCP's Retransmission Timer V. Paxson M. Allman J. Chu M. Sargent June 2011 ASCII HTML 11 RTO

This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988. [STANDARDS-TRACK]

 draft-paxson-tcpm-rfc2988bis-02 RFC2988 RFC1122 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6298 RFC6299 RFC6300 RFC6301 A Survey of Mobility Support in the Internet Z. Zhu R. Wakikawa L. Zhang July 2011 ASCII HTML 33

Over the last two decades, many efforts have been devoted to developing solutions for mobility support over the global Internet, resulting in a variety of proposed solutions. We conducted a systematic survey of the previous efforts to gain an overall understanding on the solution space of mobility support. This document reports our findings and identifies remaining issues in providing ubiquitous and efficient Internet mobility support on a global scale. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-zhu-mobility-survey-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6301 RFC6302 Logging Recommendations for Internet-Facing Servers A. Durand I. Gashinsky D. Lee S. Sheppard June 2011 ASCII HTML 5 port logging

In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet-facing servers log port number and accurate timestamps in addition to the incoming IP address. This memo documents an Internet Best Current Practice.

 draft-ietf-intarea-server-logging-recommendations-04 BCP0162 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int intarea 10.17487/RFC6302 RFC6303 Locally Served DNS Zones M. Andrews July 2011 ASCII HTML 10 AS112 Reverse IN-ADDR.ARPA IP6.ARPA RFC1918

Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones that all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well-known zones with similar characteristics. This memo documents an Internet Best Current Practice.

 draft-ietf-dnsop-default-local-zones-15 BCP0163 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC6303 RFC6304 AS112 Nameserver Operations J. Abley W. Maton July 2011 ASCII HTML 18 DNS RFC1918

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.

Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.

It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.

This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-dnsop-as112-ops-09 RFC7534 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6304 RFC6305 I'm Being Attacked by PRISONER.IANA.ORG! J. Abley W. Maton July 2011 ASCII HTML 8

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.

Hosts should never normally send DNS reverse-mapping queries for those addresses on the public Internet. However, such queries are frequently observed. Authoritative servers are deployed to provide authoritative answers to such queries as part of a loosely coordinated effort known as the AS112 project.

Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected. Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked.

This document provides background information and technical advice to those firewall operators. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-dnsop-as112-under-attack-help-help-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6305 RFC6306 Hierarchical IPv4 Framework P. Frejborg July 2011 ASCII HTML 65 core address space area locators alocs edge address space endpoint locators elocs

This document describes a framework for how the current IPv4 address space can be divided into two new address categories: a core address space (Area Locators, ALOCs) that is globally unique, and an edge address space (Endpoint Locators, ELOCs) that is regionally unique. In the future, the ELOC space will only be significant in a private network or in a service provider domain. Therefore, a 32x32 bit addressing scheme and a hierarchical routing architecture are achieved. The hierarchical IPv4 framework is backwards compatible with the current IPv4 Internet.

This document also discusses a method for decoupling the location and identifier functions -- future applications can make use of the separation. The framework requires extensions to the existing Domain Name System (DNS), the existing IPv4 stack of the endpoints, middleboxes, and routers in the Internet. The framework can be implemented incrementally for endpoints, DNS, middleboxes, and routers. This document defines an Experimental Protocol for the Internet community.

 draft-frejborg-hipv4-14 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6306 RFC6307 Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks D. Black Editor L. Dunbar Editor M. Roth R. Solomon April 2012 ASCII HTML 21

A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network. This enables service providers to take advantage of MPLS to offer "emulated" Fibre Channel services. This document specifies the encapsulation of Fibre Channel traffic within a pseudowire. It also specifies the common procedures for using a PW to provide a Fibre Channel service. [STANDARDS-TRACK]

 draft-ietf-pwe3-fc-encap-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6307 RFC6308 Overview of the Internet Multicast Addressing Architecture P. Savola June 2011 ASCII HTML 14 assignment allocation SSM ASM GLOP

The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mboned-addrarch-07 RFC2908 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC6308 RFC6309 IANA Rules for MIKEY (Multimedia Internet KEYing) J. Arkko A. Keranen J. Mattsson August 2011 ASCII HTML 6 short-term key message long-term key message oma bac browser and content broadcast

This document clarifies and relaxes the IANA rules for Multimedia Internet KEYing (MIKEY). This document updates RFCs 3830, 4563, 5410, and 6043; it obsoletes RFC 4909. [STANDARDS-TRACK]

 draft-arkko-mikey-iana-01 RFC4909 RFC3830 RFC4563 RFC5410 RFC6043 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6309 RFC6310 Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping M. Aissaoui P. Busschbach L. Martini M. Morrow T. Nadeau Y(J). Stein July 2011 ASCII HTML 40 interworking defect state defect indication pseudowire OAM

This document specifies the mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. It standardizes the behavior of Provider Edges (PEs) with respect to PW and AC defects. It addresses ATM, Frame Relay, Time Division Multiplexing (TDM), and Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) PW services, carried over MPLS, MPLS/IP, and Layer 2 Tunneling Protocol version 3/IP (L2TPv3/IP) Packet Switched Networks (PSNs). [STANDARDS-TRACK]

 draft-ietf-pwe3-oam-msg-map-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 http://www.rfc-editor.org/errata_search.php?rfc=6310 10.17487/RFC6310 RFC6311 Protocol Support for High Availability of IKEv2/IPsec R. Singh Editor G. Kalyani Y. Nir Y. Sheffer D. Zhang July 2011 ASCII HTML 26 IPsec high availability load sharing clustering fail-over

The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable, and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However, there are many issues in IPsec HA clustering, and in particular in Internet Key Exchange Protocol version 2 (IKEv2) clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol.

This document defines an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot standby cluster, and provides implementation advice for other issues. The main issues solved are the synchronization of IKEv2 Message ID counters, and of IPsec replay counters. [STANDARDS-TRACK]

 draft-ietf-ipsecme-ipsecha-protocol-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=6311 10.17487/RFC6311 RFC6312 Mobile Networks Considerations for IPv6 Deployment R. Koodli July 2011 ASCII HTML 17

Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-v6-in-mobile-networks-05 RFC6342 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6312 RFC6313 Export of Structured Data in IP Flow Information Export (IPFIX) B. Claise G. Dhandapani P. Aitken S. Yates July 2011 ASCII HTML 71 ipfix information model

This document specifies an extension to the IP Flow Information Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. [STANDARDS-TRACK]

 draft-ietf-ipfix-structured-data-06 RFC5102 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6313 10.17487/RFC6313 RFC6314 NAT Traversal Practices for Client-Server SIP C. Boulton J. Rosenberg G. Camarillo F. Audet July 2011 ASCII HTML 60

Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem. Currently, there are many deployment scenarios and traversal mechanisms for media traffic. This document provides concrete recommendations and a unified method for NAT traversal as well as documents corresponding flows. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sipping-nat-scenarios-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6314 RFC6315 IANA Registration for Enumservice 'iax' E. Guy K. Darilion July 2011 ASCII HTML 6 ENUM E.164 VoIP Voice over IP

This document registers an Enumservice for the Inter-Asterisk eXchange (IAX) protocol according to the guidelines given in RFC 6117. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-enum-iax-10 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC6315 RFC6316 Sockets Application Program Interface (API) for Multihoming Shim M. Komu M. Bagnulo K. Slavov S. Sugimoto Editor July 2011 ASCII HTML 44 Shim6 HIP identifier/locator split

This document specifies sockets API extensions for the multihoming shim layer. The API aims to enable interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration.

This document is based on an assumption that a multihomed host is equipped with a conceptual sub-layer (hereafter called "shim sub- layer") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are Shim6 and the Host Identity Protocol (HIP). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-shim6-multihome-shim-api-17 INFORMATIONAL INFORMATIONAL IETF int shim6 10.17487/RFC6316 RFC6317 Basic Socket Interface Extensions for the Host Identity Protocol (HIP) M. Komu T. Henderson July 2011 ASCII HTML 18 host identity tag cryptographic identity cryptographic namespace sockets API Shim6 opportunistic mode resolver HIP wildcard address ORCHID source address selection HIT prefix locator handling

This document defines extensions to the current sockets API for the Host Identity Protocol (HIP). The extensions focus on the use of public-key-based identifiers discovered via DNS resolution, but also define interfaces for manual bindings between Host Identity Tags (HITs) and locators. With the extensions, the application can also support more relaxed security models where communication can be non-HIP-based, according to local policies. The extensions in this document are experimental and provide basic tools for further experimentation with policies. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-hip-native-api-12 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6317 RFC6318 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) R. Housley J. Solinas June 2011 ASCII HTML 15

This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 5751. This document obsoletes RFC 5008. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-housley-rfc5008bis-01 RFC5008 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6318 RFC6319 Issues Associated with Designating Additional Private IPv4 Address Space M. Azinger L. Vegoda July 2011 ASCII HTML 12 private network

When a private network or internetwork grows very large, it is sometimes not possible to address all interfaces using private IPv4 address space because there are not enough addresses. This document describes the problems faced by those networks, the available options, and the issues involved in assigning a new block of private IPv4 address space.

While this informational document does not make a recommendation for action, it documents the issues surrounding the various options that have been considered. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-azinger-additional-private-ipv4-space-issues-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6319 RFC6320 Protocol for Access Node Control Mechanism in Broadband Networks S. Wadhwa J. Moisand T. Haag N. Voigt T. Taylor Editor October 2011 ASCII HTML 82 ancp

This document describes the Access Node Control Protocol (ANCP). ANCP operates between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to Quality of Service, service, and subscribers. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies.

ANCP is based on the General Switch Management Protocol version 3 (GSMPv3) described in RFC 3292, but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it. [STANDARDS-TRACK]

 draft-ietf-ancp-protocol-17 RFC7256 PROPOSED STANDARD PROPOSED STANDARD IETF int ancp 10.17487/RFC6320 RFC6321 xCal: The XML Format for iCalendar C. Daboo M. Douglass S. Lees August 2011 ASCII HTML 54 extensible markup language

This specification defines "xCal", an XML format for iCalendar data. [STANDARDS-TRACK]

 draft-daboo-et-al-icalendar-in-xml-11 RFC6868 RFC7529 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6321 10.17487/RFC6321 RFC6322 Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams P. Hoffman July 2011 ASCII HTML 11

This document describes extending the IETF Datatracker to capture and display the progression of Internet-Drafts that are intended to be published as RFCs by the IAB, IRTF, or Independent Submissions Editor. The states and annotations that are to be added to the Datatracker will be applied to Internet-Drafts as soon as any of these streams identify the Internet-Draft as a potential eventual RFC, and will continue through the lifetime of the Internet-Draft. The goal of adding this information to the Datatracker is to give the whole Internet community more information about the status of these Internet-Drafts and the streams from which they originate. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-hoffman-alt-streams-tracker-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6322 RFC6323 Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP) G. Renker G. Fairhurst July 2011 ASCII HTML 13 DCCP TFRC CCID-3 CCID-4

This document specifies an update to the round-trip time (RTT) estimation algorithm used for TFRC (TCP-Friendly Rate Control) congestion control by the Datagram Congestion Control Protocol (DCCP). It updates specifications for the CCID-3 and CCID-4 Congestion Control IDs of DCCP.

The update addresses parameter-estimation problems occurring with TFRC-based DCCP congestion control. It uses a recommendation made in the original TFRC specification to avoid the inherent problems of receiver-based RTT sampling, by utilising higher-accuracy RTT samples already available at the sender.

It is integrated into the feature set of DCCP as an end-to-end negotiable extension. [STANDARDS-TRACK]

 draft-ietf-dccp-tfrc-rtt-option-06 RFC4342 RFC5622 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC6323 RFC6324 Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations G. Nakibly F. Templin August 2011 ASCII HTML 19 Encapsulation ISATAP 6rd

This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop that can be abused as a vehicle for traffic amplification to facilitate denial- of-service (DoS) attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. It should be noted that at the time of this writing there are no known reports of malicious attacks exploiting these vulnerabilities. Nonetheless, these vulnerabilities can be activated by accidental misconfiguration. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-tunnel-loops-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6324 RFC6325 Routing Bridges (RBridges): Base Protocol Specification R. Perlman D. Eastlake 3rd D. Dutt S. Gai A. Ghanwani July 2011 ASCII HTML 99 TRILL

Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.

RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.

The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. [STANDARDS-TRACK]

 draft-ietf-trill-rbridge-protocol-16 RFC6327 RFC6439 RFC7172 RFC7177 RFC7357 RFC7179 RFC7180 RFC7455 RFC7780 RFC7783 RFC8139 RFC8249 RFC8361 RFC8377 PROPOSED STANDARD PROPOSED STANDARD IETF int trill http://www.rfc-editor.org/errata_search.php?rfc=6325 10.17487/RFC6325 RFC6326 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS D. Eastlake A. Banerjee D. Dutt R. Perlman A. Ghanwani July 2011 ASCII HTML 25 TRILL RBridge IS-IS ISIS

The IETF has standardized the Transparent Interconnection of Lots of Links (TRILL) protocol, which provides transparent Layer 2 forwarding using encapsulation with a hop count and IS-IS link state routing. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. [STANDARDS-TRACK]

 draft-ietf-isis-trill-05 RFC7176 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=6326 10.17487/RFC6326 RFC6327 Routing Bridges (RBridges): Adjacency D. Eastlake 3rd R. Perlman A. Ghanwani D. Dutt V. Manral July 2011 ASCII HTML 26 RBridge TRILL Adjacency

The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides optimal pair-wise data forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called Routing Bridges (RBridges).

TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. This document describes four aspects of the TRILL LAN Hello protocol used on such links, particularly adjacency, designated RBridge selection, and MTU (Maximum Transmission Unit) and pseudonode procedures, with state machines. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL. [STANDARDS-TRACK]

 draft-ietf-trill-adj-07 RFC7177 RFC6325 RFC7180 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC6327 RFC6328 IANA Considerations for Network Layer Protocol Identifiers D. Eastlake 3rd July 2011 ASCII HTML 9 NLPID

Some protocols being developed or extended by the IETF make use of the ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) Network Layer Protocol Identifier (NLPID). This document provides NLPID IANA considerations. This memo documents an Internet Best Current Practice.

 draft-eastlake-nlpid-iana-considerations-04 BCP0164 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6328 RFC6329 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging D. Fedyk Editor P. Ashwood-Smith Editor D. Allan A. Bragg P. Unbehagen April 2012 ASCII HTML 37 spb

802.1aq Shortest Path Bridging (SPB) has been standardized by the IEEE as the next step in the evolution of the various spanning tree and registration protocols. 802.1aq allows for true shortest path forwarding in a mesh Ethernet network context utilizing multiple equal cost paths. This permits it to support much larger Layer 2 topologies, with faster convergence, and vastly improved use of the mesh topology. Combined with this is single point provisioning for logical connectivity membership, which includes point-to-point, point-to-multipoint, and multipoint-to-multipoint variations. This memo documents the IS-IS changes required to support this IEEE protocol and provides some context and examples. [STANDARDS-TRACK]

 draft-ietf-isis-ieee-aq-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=6329 10.17487/RFC6329 RFC6330 RaptorQ Forward Error Correction Scheme for Object Delivery M. Luby A. Shokrollahi M. Watson T. Stockhammer L. Minder August 2011 ASCII HTML 69 FEC code fountain code systematic code AL FEC code Sub-blocking FEC object delivery

This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 6, for the RaptorQ FEC code and its application to reliable delivery of data objects.

RaptorQ codes are a new family of codes that provide superior flexibility, support for larger source block sizes, and better coding efficiency than Raptor codes in RFC 5053. RaptorQ is also a fountain code, i.e., as many encoding symbols as needed can be generated on the fly by the encoder from the source symbols of a source block of data. The decoder is able to recover the source block from almost any set of encoding symbols of sufficient cardinality -- in most cases, a set of cardinality equal to the number of source symbols is sufficient; in rare cases, a set of cardinality slightly more than the number of source symbols is required.

The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK]

 draft-ietf-rmt-bb-fec-raptorq-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=6330 10.17487/RFC6330 RFC6331 Moving DIGEST-MD5 to Historic A. Melnikov July 2011 ASCII HTML 6 http hypertext transfer protocol security simple layer

This memo describes problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism as specified in RFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of SASL mechanisms and moves RFC 2831 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-kitten-digest-to-historic-04 RFC2831 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC6331 RFC6332 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) A. Begen E. Friedrich July 2011 ASCII HTML 16 SSM multicast IPTV RAMS rapid acquisition fast channel change

In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one or more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases, the RTP receiver can do a simple multicast join (in other cases, it is compelled to do so). For quality reporting, monitoring, and diagnostic purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called the Multicast Acquisition (MA) report block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). [STANDARDS-TRACK]

 draft-ietf-avtext-multicast-acq-rtcp-xr-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC6332 RFC6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion A. Durand R. Droms J. Woodyatt Y. Lee August 2011 ASCII HTML 32 NAT

This document revisits the dual-stack model and introduces the Dual- Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT). [STANDARDS-TRACK]

 draft-ietf-softwire-dual-stack-lite-11 RFC7335 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=6333 10.17487/RFC6333 RFC6334 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite D. Hankins T. Mrugalski August 2011 ASCII HTML 7 Softwire DS-Lite

This document specifies a DHCPv6 option that is meant to be used by a Dual-Stack Lite Basic Bridging BroadBand (B4) element to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR). [STANDARDS-TRACK]

 draft-ietf-softwire-ds-lite-tunnel-option-11 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC6334 RFC6335 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry M. Cotton L. Eggert J. Touch M. Westerlund S. Cheshire August 2011 ASCII HTML 33 IANA transport ports port numbers allocation assignment procedures

This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.

This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice.

 draft-ietf-tsvwg-iana-ports-10 RFC2780 RFC2782 RFC3828 RFC4340 RFC4960 RFC5595 BCP0165 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6335 10.17487/RFC6335 RFC6336 IANA Registry for Interactive Connectivity Establishment (ICE) Options M. Westerlund C. Perkins July 2011 ASCII HTML 5

It has been identified that "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols" (RFC 5245) is missing a registry for ICE options. This document defines this missing IANA registry and updates RFC 5245. [STANDARDS-TRACK]

 draft-ietf-mmusic-ice-options-registry-02 RFC8839 RFC5245 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC6336 RFC6337 Session Initiation Protocol (SIP) Usage of the Offer/Answer Model S. Okumura T. Sawada P. Kyzivat August 2011 ASCII HTML 33 answer offer SDP SIP

The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sipping-sip-offeranswer-18 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6337 RFC6338 Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC) V. Giralt R. McDuff August 2011 ASCII HTML 11 TERENA tf-emc2

This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC).

The namespace described in this document is for naming persistent resources defined by the SCHAC participants internationally, their working groups, and other designated subordinates. The main use of this namespace will be for the creation of controlled vocabulary values for attributes in the SCHAC schema. These values will be associated with particular instances of persons or objects belonging to any of the SCHAC object classes. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-giralt-schac-ns-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6338 RFC6339 Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API) S. Josefsson L. Hornquist Astrand August 2011 ASCII HTML 8

This document describes three abstract Generic Security Service Application Program Interface (GSS-API) interfaces used to encapsulate/decapsulate context tokens and compare OIDs. This document also specifies C bindings for the abstract interfaces. [STANDARDS-TRACK]

 draft-josefsson-gss-capsulate-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6339 RFC6340 Textual Conventions for the Representation of Floating-Point Numbers R. Presuhn August 2011 ASCII HTML 7 Network Management IEEE 754 Floating-point MIB SMIv2 Textual Convention FLOAT-TC-MIB

This memo defines a Management Information Base (MIB) module containing textual conventions (TCs) to represent floating-point numbers. [STANDARDS-TRACK]

 draft-ietf-opsawg-mib-floats-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC6340 RFC6341 Use Cases and Requirements for SIP-Based Media Recording (SIPREC) K. Rehor Editor L. Portman Editor A. Hutton R. Jain August 2011 ASCII HTML 16

Session recording is a critical requirement in many business communications environments, such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics.

Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based Media Recording. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-siprec-req-12 INFORMATIONAL INFORMATIONAL IETF rai siprec 10.17487/RFC6341 RFC6342 Mobile Networks Considerations for IPv6 Deployment R. Koodli August 2011 ASCII HTML 17

Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-v6-in-mobile-networks-rfc6312bis RFC6312 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6342 RFC6343 Advisory Guidelines for 6to4 Deployment B. Carpenter August 2011 ASCII HTML 20 IPv6 relay

This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It is principally addressed to Internet Service Providers (ISPs), including those that do not yet support IPv6, and to Content Providers. Some advice to implementers is also included. The intention of the advice is to minimize both user dissatisfaction and help-desk calls. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-6to4-advisory-02 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6343 RFC6344 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) G. Bernstein Editor D. Caviglia R. Rabbat H. van Helvoort August 2011 ASCII HTML 21

This document describes requirements for, and the use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data plane mechanism and its companion Link Capacity Adjustment Scheme (LCAS). LCAS can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. This document updates RFC 4606 by making modifications to the procedures for supporting virtual concatenation. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-vcat-lcas-13 RFC4606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6344 RFC6345 Protocol for Carrying Authentication for Network Access (PANA) Relay Element P. Duffy S. Chakrabarti R. Cragie Y. Ohba Editor A. Yegin August 2011 ASCII HTML 12 EAP ZigBee

This document specifies Protocol for carrying Authentication for Network Access (PANA) Relay Element functionality, which enables PANA messaging between a PANA Client (PaC) and a PANA Authentication Agent (PAA) where the two nodes cannot reach each other by means of regular IP routing. [STANDARDS-TRACK]

 draft-ohba-pana-relay-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6345 10.17487/RFC6345 RFC6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage R. Bush Editor August 2011 ASCII HTML 38

We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem.

This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core. This document defines an Experimental Protocol for the Internet community.

 draft-ymbk-aplusp-10 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6346 RFC6347 Datagram Transport Layer Security Version 1.2 E. Rescorla N. Modadugu January 2012 ASCII HTML 32 dtls dtls protocol

This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]

 draft-ietf-tls-rfc4347-bis-06 RFC4347 RFC9147 RFC7507 RFC7905 RFC8996 RFC9146 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=6347 10.17487/RFC6347 RFC6348 Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol JL. Le Roux Editor T. Morin Editor September 2011 ASCII HTML 20 MPLS LDP multipoint P2MP multicast

This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multiprotocol Label Switching (MPLS) infrastructure.

This work was overtaken by the protocol solution developed by the MPLS working group, but that solution did not closely follow the requirements documented here. This document is published as a historic record of the ideas and requirements that shaped the protocol work. This document defines a Historic Document for the Internet community.

 draft-ietf-mpls-mp-ldp-reqs-08 HISTORIC HISTORIC IETF rtg mpls 10.17487/RFC6348 RFC6349 Framework for TCP Throughput Testing B. Constantine G. Forget R. Geib R. Schrage August 2011 ASCII HTML 27 metric TCP testing

This framework describes a practical methodology for measuring end- to-end TCP Throughput in a managed IP network. The goal is to provide a better indication in regard to user experience. In this framework, TCP and IP parameters are specified to optimize TCP Throughput. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ippm-tcp-throughput-tm-13 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6349 RFC6350 vCard Format Specification S. Perreault August 2011 ASCII HTML 74 vCard

This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK]

 draft-ietf-vcarddav-vcardrev-22 RFC2425 RFC2426 RFC4770 RFC2739 RFC6868 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6350 10.17487/RFC6350 RFC6351 xCard: vCard XML Representation S. Perreault August 2011 ASCII HTML 22 vCard

This document defines the XML schema of the vCard data format. [STANDARDS-TRACK]

 draft-ietf-vcarddav-vcardxml-11 RFC6868 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6351 10.17487/RFC6351 RFC6352 CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV) C. Daboo August 2011 ASCII HTML 48 address address book contact

This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. [STANDARDS-TRACK]

 draft-ietf-vcarddav-carddav-10 RFC6764 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6352 10.17487/RFC6352 RFC6353 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) W. Hardaker July 2011 ASCII HTML 65 dtls datagram transport layer security tls transport model tlstm SNMP-TLS-TM-MIB

This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of an SNMP Transport Subsystem to make this protection possible in an interoperable way.

This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.

This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]

 draft-ietf-isms-dtls-tm-rfc5953bis-00 RFC5953 RFC8996 STD0078 INTERNET STANDARD DRAFT STANDARD IETF sec isms 10.17487/RFC6353 RFC6354 Forward-Shifted RTP Redundancy Payload Support Q. Xie August 2011 ASCII HTML 13

This document defines a simple enhancement to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). [STANDARDS-TRACK]

 draft-ietf-avt-forward-shifted-red-08 RFC2198 RFC4102 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6354 RFC6355 Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) T. Narten J. Johnson August 2011 ASCII HTML 5 universally unique identifier

This document defines a new DHCPv6 Unique Identifier (DUID) type called DUID-UUID. DUID-UUIDs are derived from the already-standardized Universally Unique IDentifier (UUID) format. DUID-UUID makes it possible for devices to use UUIDs to identify themselves to DHC servers and vice versa. UUIDs are globally unique and readily available on many systems, making them convenient identifiers to leverage within DHCP. [STANDARDS-TRACK]

 draft-ietf-dhc-duid-uuid-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6355 RFC6356 Coupled Congestion Control for Multipath Transport Protocols C. Raiciu M. Handley D. Wischik October 2011 ASCII HTML 12 multipath tcp congestion control

Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP.

New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called "resource pooling" where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure.

This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-mptcp-congestion-07 EXPERIMENTAL EXPERIMENTAL IETF tsv mptcp 10.17487/RFC6356 RFC6357 Design Considerations for Session Initiation Protocol (SIP) Overload Control V. Hilt E. Noel C. Shen A. Abdelal August 2011 ASCII HTML 25 Session Initiation Protocol Overload Control Congestion Collapse

Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-soc-overload-design-08 INFORMATIONAL INFORMATIONAL IETF rai soc 10.17487/RFC6357 RFC6358 Additional Master Secret Inputs for TLS P. Hoffman January 2012 ASCII HTML 4 tls dtls datagram tls

This document describes a mechanism for using additional master secret inputs with Transport Layer Security (TLS) and Datagram TLS (DTLS). This document defines an Experimental Protocol for the Internet community.

 draft-hoffman-tls-master-secret-input-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6358 RFC6359 Datatracker Extensions to Include IANA and RFC Editor Processing Information S. Ginoza M. Cotton A. Morris September 2011 ASCII HTML 18 id-tracker backend extensions

This document captures the requirements for integrating IANA and RFC Editor state information into the Datatracker to provide the community with a unified tool to track the status of their document as it progresses from Internet-Draft (I-D) version -00 to RFC. Extending the Datatracker to hold document data from I-D version -00 to RFC allows for increased automation between the Datatracker, IANA, and RFC Editor, thus reducing manual labor, processing errors, and potential delay. Therefore, this document also describes the requirements to make such automation possible. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-genarea-datatracker-iana-rfced-extns-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6359 RFC6360 Conclusion of FYI RFC Sub-Series R. Housley August 2011 ASCII HTML 3

This document concludes the For Your Information (FYI) sub-series of RFCs, established by RFC 1150 for use by the IETF User Services Area, which no longer exists. The IESG does not intend to make any further additions to this RFC sub-series, and this document provides a record of this decision. This document also obsoletes RFC 1150 and changes the status of RFC 1150 to Historic. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iesg-rfc1150bis-01 RFC1150 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6360 RFC6361 PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol J. Carlson D. Eastlake 3rd August 2011 ASCII HTML 8 point-to-point protocol rbridges routing bridges

The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multiprotocol traffic over point-to-point links. This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. [STANDARDS-TRACK]

 draft-ietf-pppext-trill-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6361 RFC6362 Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT) K. Meadors Editor August 2011 ASCII HTML 8 EDIINT AS2 Multiple Attachments

The Electronic Data Interchange - Internet Integration (EDIINT) AS1, AS2, and AS3 messages were designed specifically for the transport of EDI documents. Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message. As adoption of EDIINT grew, other uses developed aside from single EDI document transport. Some transactions required multiple attachments to be interpreted together and stored in a single message. This Informational RFC describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDIINT transport message. The attachments are stored within the MIME multipart/related structure. A minimal list of content-types to be supported as attachments is provided. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-meadors-multiple-attachments-ediint-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6362 RFC6363 Forward Error Correction (FEC) Framework M. Watson A. Begen V. Roca October 2011 ASCII HTML 42 Reliable streaming content delivery FEC schemes

This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol. [STANDARDS-TRACK]

 draft-ietf-fecframe-framework-15 RFC8680 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6363 RFC6364 Session Description Protocol Elements for the Forward Error Correction (FEC) Framework A. Begen October 2011 ASCII HTML 18 FEC configuration FEC topologies

This document specifies the use of the Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. [STANDARDS-TRACK]

 draft-ietf-fecframe-sdp-elements-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6364 RFC6365 Terminology Used in Internationalization in the IETF P. Hoffman J. Klensin September 2011 ASCII HTML 47 i18n vocabulary terms

This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo documents an Internet Best Current Practice.

 draft-ietf-appsawg-rfc3536bis-06 RFC3536 BCP0166 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6365 10.17487/RFC6365 RFC6366 Requirements for an Internet Audio Codec J. Valin K. Vos August 2011 ASCII HTML 17

This document provides specific requirements for an Internet audio codec. These requirements address quality, sampling rate, bit-rate, and packet-loss robustness, as well as other desirable properties. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-codec-requirements-05 INFORMATIONAL INFORMATIONAL IETF rai codec 10.17487/RFC6366 RFC6367 Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) S. Kanno M. Kanda September 2011 ASCII HTML 8 TLS GCM Eliptic Curve Encryption Block Cipher psk

This document specifies forty-two cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-kanno-tls-camellia-03 RFC8996 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6367 10.17487/RFC6367 RFC6368 Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) P. Marques R. Raszuk K. Patel K. Kumaki T. Yamagata September 2011 ASCII HTML 14 l3vpn iBGP loops as-override attribute set attr_set

This document defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. [STANDARDS-TRACK]

 draft-ietf-l3vpn-ibgp-08 RFC7606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6368 10.17487/RFC6368 RFC6369 Forwarding and Control Element Separation (ForCES) Implementation Experience E. Haleplidis O. Koufopavlou S. Denazis September 2011 ASCII HTML 18

The Forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a Forwarding Element (FE). This document captures the experience of implementing the ForCES protocol and model. Its aim is to help others by providing examples and possible strategies for implementing the ForCES protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-haleplidis-forces-implementation-experience-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6369 RFC6370 MPLS Transport Profile (MPLS-TP) Identifiers M. Bocci G. Swallow E. Gray September 2011 ASCII HTML 17

This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions compatible with IP/ MPLS conventions.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-identifiers-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6370 RFC6371 Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks I. Busi Editor D. Allan Editor September 2011 ASCII HTML 62

The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures.

This document describes a framework to support a comprehensive set of Operations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-oam-framework-11 RFC6435 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6371 10.17487/RFC6371 RFC6372 MPLS Transport Profile (MPLS-TP) Survivability Framework N. Sprecher Editor A. Farrel Editor September 2011 ASCII HTML 56 Protection Restoration Recovery

Network survivability is the ability of a network to recover traffic delivery following failure or degradation of network resources. Survivability is critical for the delivery of guaranteed network services, such as those subject to strict Service Level Agreements (SLAs) that place maximum bounds on the length of time that services may be degraded or unavailable.

The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS data plane that reuses many aspects of the MPLS management and control planes.

This document comprises a framework for the provision of survivability in an MPLS-TP network; it describes recovery elements, types, methods, and topological considerations. To enable data-plane recovery, survivability may be supported by the control plane, management plane, and by Operations, Administration, and Maintenance (OAM) functions. This document describes mechanisms for recovering MPLS-TP Label Switched Paths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond the scope of this document.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet-based transport network as defined by the ITU-T.

This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-survive-fwk-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6372 RFC6373 MPLS Transport Profile (MPLS-TP) Control Plane Framework L. Andersson Editor L. Berger Editor L. Fang Editor N. Bitar Editor E. Gray Editor September 2011 ASCII HTML 57

The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS) and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning and covers control-plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the pseudowire (PW) control plane for pseudowires. Management-plane functions are out of scope of this document.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ccamp-mpls-tp-cp-framework-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6373 RFC6374 Packet Loss and Delay Measurement for MPLS Networks D. Frost S. Bryant September 2011 ASCII HTML 52

Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. [STANDARDS-TRACK]

 draft-ietf-mpls-loss-delay-04 RFC7214 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6374 10.17487/RFC6374 RFC6375 A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks D. Frost Editor S. Bryant Editor September 2011 ASCII HTML 5

Procedures and protocol mechanisms to enable efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC 6374.

The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks.

This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-loss-delay-profile-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6375 RFC6376 DomainKeys Identified Mail (DKIM) Signatures D. Crocker Editor T. Hansen Editor M. Kucherawy Editor September 2011 ASCII HTML 76 email architecture abuse verification anti-abuse identity integrity responsible author sender originator email filtering anti-phishing mail signature

DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.

This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]

 draft-ietf-dkim-rfc4871bis-15 RFC4871 RFC5672 RFC8301 RFC8463 RFC8553 RFC8616 STD0076 INTERNET STANDARD DRAFT STANDARD IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=6376 10.17487/RFC6376 RFC6377 DomainKeys Identified Mail (DKIM) and Mailing Lists M. Kucherawy September 2011 ASCII HTML 26 email architecture verification anti-abuse identity integrity responsible author sender originator

DomainKeys Identified Mail (DKIM) allows an ADministrative Management Domain (ADMD) to assume some responsibility for a message. Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs). This memo documents an Internet Best Current Practice.

 draft-ietf-dkim-mailinglists-12 BCP0167 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=6377 10.17487/RFC6377 RFC6378 MPLS Transport Profile (MPLS-TP) Linear Protection Y. Weingarten Editor S. Bryant E. Osborne N. Sprecher A. Fulignoli Editor October 2011 ASCII HTML 45 PSC Protection State Coordination Protocol,

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document addresses the functionality described in the MPLS-TP Survivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-linear-protection-09 RFC7214 RFC7271 RFC7324 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6378 RFC6379 Suite B Cryptographic Suites for IPsec L. Law J. Solinas October 2011 ASCII HTML 7 UI suites user interface suites elliptic curve ike

This document proposes four cryptographic user interface suites ("UI suites") for IP Security (IPsec), similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. This document obsoletes RFC 4869, which presented earlier versions of these suites. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-law-rfc4869bis-01 RFC4869 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6379 RFC6380 Suite B Profile for Internet Protocol Security (IPsec) K. Burgin M. Peck October 2011 ASCII HTML 10 cryptographic algorithm policy security application suite b cryptography

The United States Government has published guidelines for "NSA Suite B Cryptography" dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in IP Security (IPsec).

Since many of the Suite B algorithms are used in other environments, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, with some relevant detail repeated to aid developers who choose to support Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-burgin-ipsec-suiteb-profile-02 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6380 RFC6381 The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types R. Gellens D. Singer P. Frojdh August 2011 ASCII HTML 19 codec container audio video 3gpp 3gpp2

Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content- Type alone if the content can be rendered.

This document specifies two parameters, 'codecs' and 'profiles', that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. This document obsoletes RFC 4281; RFC 4281 defines the 'codecs' parameter, which this document retains in a backwards compatible manner with minor clarifications; the 'profiles' parameter is added by this document.

By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.).

Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies. This is an indication of the compatibility of the container format and its contents to some specification. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean. [STANDARDS-TRACK]

 draft-gellens-mime-bucket-bis-09 RFC4281 RFC3839 RFC4393 RFC4337 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6381 10.17487/RFC6381 RFC6382 Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services D. McPherson R. Donnelly F. Scalzo October 2011 ASCII HTML 10 BGP SIDR RPKI security routing operations root TLD DNS DDOS peering RIR IRR MITM

This document makes recommendations regarding the use of unique origin autonomous system numbers (ASNs) per node for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network management and monitoring techniques, or other operational mechanisms, may employ this new discriminator in whatever manner best accommodates their operating environment. This memo documents an Internet Best Current Practice.

 draft-ietf-grow-unique-origin-as-01 BCP0169 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC6382 RFC6383 Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE K. Shiomoto A. Farrel September 2011 ASCII HTML 11 RSVP-TE GMPLS MPLS-TE cross-connect data plane

The Resource Reservation Protocol (RSVP) has been extended to support Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and link to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives.

End points of an LSP need to know when it is safe to start sending data so that it is not misdelivered, and so that safety issues specific to optical data-plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to program their data planes relative to sending and receiving control-plane messages.

This document clarifies and summarizes the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidirectional and bidirectional LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that provide normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-shiomoto-ccamp-switch-programming-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6383 RFC6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation I. van Beijnum October 2011 ASCII HTML 16 FTP SIIT NAT64

The File Transfer Protocol (FTP) has a very long history, and despite the fact that today other options exist to perform file transfers, FTP is still in common use. As such, in situations where some client computers only have IPv6 connectivity while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, it is important that FTP is made to work through these translators to the best possible extent.

FTP has an active and a passive mode, both as original commands that are IPv4-specific and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch. [STANDARDS-TRACK]

 draft-ietf-behave-ftp64-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC6384 RFC6385 General Area Review Team (Gen-ART) Experiences M. Barnes A. Doria H. Alvestrand B. Carpenter October 2011 ASCII HTML 23 genart

The General Area Review Team (Gen-ART) has been doing reviews of Internet-Drafts (I-Ds) since 2004. This document discusses the experience and the lessons learned over the past 7 years of this process. The review team initially reviewed the I-Ds before each of the IESG telechats. Since late 2005, review team members have been assigned to review I-Ds during IETF Last Call, unless no IETF Last Call is necessary for the I-D. The same reviewer then reviews any updates when the I-D is placed on an IESG telechat agenda. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-doria-genart-experience-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6385 RFC6386 VP8 Data Format and Decoding Guide J. Bankoski J. Koleszar L. Quillio J. Salonen P. Wilkins Y. Xu November 2011 ASCII HTML 304

This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-bankoski-vp8-bitstream-06 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6386 10.17487/RFC6386 RFC6387 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) A. Takacs L. Berger D. Caviglia D. Fedyk J. Meuric September 2011 ASCII HTML 11 rsvp resource reservation protocol

This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The approach presented is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. This document moves the experiment documented in RFC 5467 to the standards track and obsoletes RFC 5467. [STANDARDS-TRACK]

 draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-03 RFC5467 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6387 RFC6388 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths IJ. Wijnands Editor I. Minei Editor K. Kompella B. Thomas November 2011 ASCII HTML 39

This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also referred to as multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-p2mp-15 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6388 RFC6389 MPLS Upstream Label Assignment for LDP R. Aggarwal JL. Le Roux November 2011 ASCII HTML 13

This document describes procedures for distributing upstream-assigned labels for the Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch Label Switching Router (LSR) traffic replication on a LAN for LDP point-to-multipoint (P2MP) Label Switched Paths (LSPs). [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-upstream-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6389 RFC6390 Guidelines for Considering New Performance Metric Development A. Clark B. Claise October 2011 ASCII HTML 23

This document describes a framework and a process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols. These metrics can be used to characterize traffic on live networks and services. This memo documents an Internet Best Current Practice.

 draft-ietf-pmol-metrics-framework-12 BCP0170 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops pmol 10.17487/RFC6390 RFC6391 Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network S. Bryant Editor C. Filsfils U. Drafz V. Kompella J. Regan S. Amante November 2011 ASCII HTML 19

Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal Cost Multiple Paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs.

This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. [STANDARDS-TRACK]

 draft-ietf-pwe3-fat-pw-07 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6391 RFC6392 A Survey of In-Network Storage Systems R. Alimi Editor A. Rahman Editor Y. Yang Editor October 2011 ASCII HTML 44 P2P DECADE DECoupled Application Data Enroute

This document surveys deployed and experimental in-network storage systems and describes their applicability for the DECADE (DECoupled Application Data Enroute) architecture. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-decade-survey-06 INFORMATIONAL INFORMATIONAL IETF tsv decade http://www.rfc-editor.org/errata_search.php?rfc=6392 10.17487/RFC6392 RFC6393 Moving RFC 4693 to Historic M. Yevstifeyev September 2011 ASCII HTML 3 ION historic

This document moves RFC 4693 to Historic status. It also obsoletes RFC 4693. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-yevstifeyev-ion-report-07 RFC4693 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6393 RFC6394 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE) R. Barnes October 2011 ASCII HTML 12 TLS PKIX

Many current applications use the certificate-based authentication features in Transport Layer Security (TLS) to allow clients to verify that a connected server properly represents a desired domain name. Typically, this authentication has been based on PKIX certificate chains rooted in well-known certificate authorities (CAs), but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNS Security Extensions (DNSSEC) could be used to make assertions that support the TLS authentication process. The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names. [STANDARDS-TRACK]

 draft-ietf-dane-use-cases-05 INFORMATIONAL INFORMATIONAL IETF sec dane 10.17487/RFC6394 RFC6395 An Interface Identifier (ID) Hello Option for PIM S. Gulrajani S. Venaas October 2011 ASCII HTML 6

This document defines a new PIM Hello option to advertise an Interface Identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router. [STANDARDS-TRACK]

 draft-ietf-pim-hello-intid-01 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6395 RFC6396 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format L. Blunk M. Karir C. Labovitz October 2011 ASCII HTML 33

This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents. [STANDARDS-TRACK]

 draft-ietf-grow-mrt-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=6396 10.17487/RFC6396 RFC6397 Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions T. Manderson October 2011 ASCII HTML 8 GPS Coordinates Terrestrial Coordinates BGP Speaker BGP Peer BGP Latitude BGP Longitude

This document updates the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by extending it to include optional terrestrial coordinates of a BGP collector and its BGP peers. [STANDARDS-TRACK]

 draft-ietf-grow-geomrt-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC6397 RFC6398 IP Router Alert Considerations and Usage F. Le Faucheur Editor October 2011 ASCII HTML 19

The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. The Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), the Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), and General Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option. This document discusses security aspects and usage guidelines around the use of the current IP Router Alert Option, thereby updating RFC 2113 and RFC 2711. Specifically, it provides recommendations against using the Router Alert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendations about protection approaches for service providers. Finally, it provides brief guidelines for Router Alert implementation on routers. This memo documents an Internet Best Current Practice.

 draft-ietf-intarea-router-alert-considerations-10 RFC2113 RFC2711 BCP0168 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int intarea 10.17487/RFC6398 RFC6399 RFC6400 RFC6401 RSVP Extensions for Admission Priority F. Le Faucheur J. Polk K. Carlberg October 2011 ASCII HTML 32

Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion. When supported over the Internet Protocol suite, this may be facilitated through a network-layer admission control solution that supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for prioritized sessions, or may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) that can be used to support such an admission priority capability at the network layer.

Based on current security concerns, these extensions are intended for use in a single administrative domain. [STANDARDS-TRACK]

 draft-ietf-tsvwg-emergency-rsvp-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6401 RFC6402 Certificate Management over CMS (CMC) Updates J. Schaad November 2011 ASCII HTML 37 cyrptographic message syntax

This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273, and RFC 5274.

The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject Information Access value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. [STANDARDS-TRACK]

 draft-ietf-pkix-rfc5272-bis-08 RFC5272 RFC5273 RFC5274 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=6402 10.17487/RFC6402 RFC6403 Suite B Profile of Certificate Management over CMS L. Zieglar S. Turner M. Peck November 2011 ASCII HTML 16 cmc suite b x.509 public key certificates

The United States government has published guidelines for "NSA Suite\0B Cryptography", which defines cryptographic algorithm policy for national security applications. This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing Suite B X.509 public key certificates. This profile is a refinement of RFCs 5272, 5273, and 5274. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-turner-suiteb-cmc-03 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6403 RFC6404 Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures J. Seedorf S. Niccolini E. Chen H. Scholz November 2011 ASCII HTML 22 VoIP Security Threats multimedia Threat countermeasures SIP Interconnect VoIP peering Fraud prevention Network protection SIP RTP RTCP control plane user plane

The Session PEERing for Multimedia INTerconnect (SPEERMINT) working group (WG) provides a peering framework that leverages the building blocks of existing IETF-defined protocols such as SIP and ENUM for the interconnection between SIP Service Providers (SSPs). The objective of this document is to identify and enumerate SPEERMINT- specific threat vectors and to give guidance for implementers on selecting appropriate countermeasures. Security requirements for SPEERMINT that have been derived from the threats detailed in this document can be found in RFC 6271; this document provides concrete countermeasures to meet those SPEERMINT security requirements. In this document, the different security threats related to SPEERMINT are classified into threats to the Lookup Function (LUF), the Location Routing Function (LRF), the Signaling Function (SF), and the Media Function (MF) of a specific SIP Service Provider. Various instances of the threats are briefly introduced inside the classification. Finally, existing security solutions for SIP and RTP/RTCP (Real-time Transport Control Protocol) are presented to describe countermeasures currently available for such threats. Each SSP may have connections to one or more remote SSPs through peering or transit contracts. A potentially compromised remote SSP that attacks other SSPs is out of the scope of this document; this document focuses on attacks on an SSP from outside the trust domain such an SSP may have with other SSPs. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-speermint-voipthreats-09 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6404 RFC6405 Voice over IP (VoIP) SIP Peering Use Cases A. Uzelac Editor Y. Lee Editor November 2011 ASCII HTML 23 VoIP SIP Peering

This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-speermint-voip-consolidated-usecases-18 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6405 RFC6406 Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture D. Malas Editor J. Livingood Editor November 2011 ASCII HTML 16

This document defines a peering architecture for the Session Initiation Protocol (SIP) and its functional components and interfaces. It also describes the components and the steps necessary to establish a session between two SIP Service Provider (SSP) peering domains. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-speermint-architecture-19 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6406 RFC6407 The Group Domain of Interpretation B. Weis S. Rowles T. Hardjono October 2011 ASCII HTML 64

This document describes the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. This document replaces RFC 3547. [STANDARDS-TRACK]

 draft-ietf-msec-gdoi-update-11 RFC3547 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=6407 10.17487/RFC6407 RFC6408 Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage M. Jones J. Korhonen L. Morand November 2011 ASCII HTML 14 Services Field Peer Discovery

The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanisms do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application. This document updates RFC 3588, "Diameter Base Protocol", and describes an improvement using an extended format for the Straightforward-Naming Authority Pointer (S-NAPTR) application service tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. [STANDARDS-TRACK]

 draft-ietf-dime-extended-naptr-09 RFC3588 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6408 RFC6409 Message Submission for Mail R. Gellens J. Klensin November 2011 ASCII HTML 20 Text Internationalization ASCII Unicode UTF-8

This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.

Message relay is unaffected, and continues to use SMTP over port 25.

When conforming to this document, message submission uses the protocol specified here, normally over port 587.

This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]

 draft-ietf-yam-rfc4409bis-03 RFC4409 RFC8314 STD0072 INTERNET STANDARD INTERNET STANDARD IETF app yam http://www.rfc-editor.org/errata_search.php?rfc=6409 10.17487/RFC6409 RFC6410 Reducing the Standards Track to Two Maturity Levels R. Housley D. Crocker E. Burger October 2011 ASCII HTML 6

This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice.

 draft-housley-two-maturity-levels-09 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6410 10.17487/RFC6410 RFC6411 Applicability of Keying Methods for RSVP Security M. Behringer F. Le Faucheur B. Weis October 2011 ASCII HTML 19 RSVP authentication RSVP integrity Resource reservation protocol GDOI Group domain of interpretation

The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per-neighbor or per-interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. This document also discusses applicability of encrypting RSVP messages. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-tsvwg-rsvp-security-groupkeying-11 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC6411 RFC6412 Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence S. Poretsky B. Imhoff K. Michielsen November 2011 ASCII HTML 29

This document describes the terminology for benchmarking link-state Interior Gateway Protocol (IGP) route convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The terminology can be applied to any link-state IGP, such as IS-IS and OSPF. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-bmwg-igp-dataplane-conv-term-23 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6412 RFC6413 Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence S. Poretsky B. Imhoff K. Michielsen November 2011 ASCII HTML 42 Interior Gateway Protocol

This document describes the methodology for benchmarking Link-State Interior Gateway Protocol (IGP) Route Convergence. The methodology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The methodology can be applied to any link-state IGP, such as IS-IS and OSPF. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-bmwg-igp-dataplane-conv-meth-23 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6413 RFC6414 Benchmarking Terminology for Protection Performance S. Poretsky R. Papneja J. Karthik S. Vapiwala November 2011 ASCII HTML 33

This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms. The performance benchmarks are measured at the IP layer; protection may be provided at the sub-IP layer. The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS), Virtual Router Redundancy Protocol (VRRP), Stateful High Availability (HA), and Multiprotocol Label Switching Fast Reroute (MPLS-FRR). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-bmwg-protection-term-09 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6414 RFC6415 Web Host Metadata E. Hammer-Lahav Editor B. Cook October 2011 ASCII HTML 16

This specification describes a method for locating host metadata as well as information about individual resources controlled by the host. [STANDARDS-TRACK]

 draft-hammer-hostmeta-17 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6415 10.17487/RFC6415 RFC6416 RTP Payload Format for MPEG-4 Audio/Visual Streams M. Schmidt F. de Bont S. Doehla J. Kim October 2011 ASCII HTML 35 RFC3016 RTP MPEG-4 Audio Visual Video AAC HE AAC HE AAC v2 MPEG Surround

This document describes Real-time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. This document obsoletes RFC 3016. It contains a summary of changes from RFC 3016 and discusses backward compatibility to RFC 3016. It is a necessary revision of RFC 3016 in order to correct misalignments with the 3GPP Packet- switched Streaming Service (PSS) specification regarding the RTP payload format for MPEG-4 Audio.

For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, this document provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of the Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, new system designs should utilize RFC 3640, which does not have these restrictions. Nevertheless, this revision of RFC 3016 is provided to update and complete the specification and to enable interoperable implementations. [STANDARDS-TRACK]

 draft-ietf-payload-rfc3016bis-03 RFC3016 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6416 RFC6417 How to Contribute Research Results to Internet Standardization P. Eardley L. Eggert M. Bagnulo R. Winter November 2011 ASCII HTML 14

The development of new technology is driven by scientific research. The Internet, with its roots in the ARPANET and NSFNet, is no exception. Many of the fundamental, long-term improvements to the architecture, security, end-to-end protocols and management of the Internet originate in the related academic research communities. Even shorter-term, more commercially driven extensions are oftentimes derived from academic research. When interoperability is required, the IETF standardizes such new technology. Timely and relevant standardization benefits from continuous input and review from the academic research community.

For an individual researcher, it can however be quite puzzling how to begin to most effectively participate in the IETF and arguably to a much lesser degree, the IRTF. The interactions in the IETF are much different than those in academic conferences, and effective participation follows different rules. The goal of this document is to highlight such differences and provide a rough guideline that will hopefully enable researchers new to the IETF to become successful contributors more quickly. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-weeb-research-to-internet-stds-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6417 RFC6418 Multiple Interfaces and Provisioning Domains Problem Statement M. Blanchet P. Seite November 2011 ASCII HTML 22 multi-homing MIF DNS DHCP

This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains, where some configuration objects are global to the node and others are local to the interface. Issues such as selecting the wrong interface to send traffic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simultaneous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses situations involving single-interface nodes. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mif-problem-statement-15 INFORMATIONAL INFORMATIONAL IETF int mif http://www.rfc-editor.org/errata_search.php?rfc=6418 10.17487/RFC6418 RFC6419 Current Practices for Multiple-Interface Hosts M. Wasserman P. Seite November 2011 ASCII HTML 21 current practices multi-homing MIF

An increasing number of hosts are operating in multiple-interface environments. This document summarizes current practices in this area and describes in detail how some common operating systems cope with challenges that ensue from this context. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mif-current-practices-12 INFORMATIONAL INFORMATIONAL IETF int mif 10.17487/RFC6419 RFC6420 PIM Multi-Topology ID (MT-ID) Join Attribute Y. Cai H. Ou November 2011 ASCII HTML 13

This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree. [STANDARDS-TRACK]

 draft-ietf-pim-mtid-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6420 RFC6421 Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) D. Nelson Editor November 2011 ASCII HTML 12

This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-radext-crypto-agility-requirements-07 INFORMATIONAL INFORMATIONAL IETF ops radext 10.17487/RFC6421 RFC6422 Relay-Supplied DHCP Options T. Lemon Q. Wu December 2011 ASCII HTML 8 DHCPv6 Relay DHCPv6 option

DHCPv6 relay agents cannot communicate with DHCPv6 clients directly. However, in some cases, the relay agent possesses some information that would be useful to the DHCPv6 client. This document describes a mechanism whereby the DHCPv6 relay agent can provide such information to the DHCPv6 server, which can, in turn, pass this information on to the DHCP client.

This document updates RFC 3315 (DHCPv6) by making explicit the implicit requirement that relay agents not modify the content of encapsulation payloads as they are relayed back toward clients. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-relay-supplied-options-09 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6422 RFC6423 Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP) H. Li L. Martini J. He F. Huang November 2011 ASCII HTML 5

This document describes the requirements for using the Generic Associated Channel Label (GAL) in pseudowires (PWs) in MPLS Transport Profile (MPLS-TP) networks, and provides an update to the description of GAL usage in RFC 5586 by removing the restriction that is imposed on using GAL for PWs, especially in MPLS-TP environments. [STANDARDS-TRACK]

 draft-ietf-pwe3-mpls-tp-gal-in-pw-01 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6423 RFC6424 Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels N. Bahadur K. Kompella G. Swallow November 2011 ASCII HTML 23 MPLS OAM lsp ping LSP-Ping

This document describes methods for performing LSP ping (specified in RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched MPLS Label Switched Paths (LSPs). The techniques outlined in RFC 4379 are insufficient to perform traceroute Forwarding Equivalency Class (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP. This document deprecates the Downstream Mapping TLV (defined in RFC 4379) in favor of a new TLV that, along with other procedures outlined in this document, can be used to trace such LSPs. [STANDARDS-TRACK]

 draft-ietf-mpls-lsp-ping-enhanced-dsmap-11 RFC8029 RFC4379 RFC7537 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6424 RFC6425 Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping S. Saxena Editor G. Swallow Z. Ali A. Farrel S. Yasukawa T. Nadeau November 2011 ASCII HTML 28 p2mp

Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs.

The requirement for a simple and efficient mechanism that can be used to detect data-plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP ping".

The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP ping to the MPLS P2MP environment.

This document updates RFC 4379. [STANDARDS-TRACK]

 draft-ietf-mpls-p2mp-lsp-ping-18 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6425 10.17487/RFC6425 RFC6426 MPLS On-Demand Connectivity Verification and Route Tracing E. Gray N. Bahadur S. Boutros R. Aggarwal November 2011 ASCII HTML 22 lsp ping mpls tp mpls-tp

Label Switched Path Ping (LSP ping) is an existing and widely deployed Operations, Administration, and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP ping so that LSP ping can be used for on-demand connectivity verification of MPLS Transport Profile (MPLS-TP) LSPs and pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP ping to perform connectivity verification and route tracing functions in MPLS-TP networks. Finally, this document updates RFC 4379 by adding a new address type and creating an IANA registry. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-on-demand-cv-07 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6426 10.17487/RFC6426 RFC6427 MPLS Fault Management Operations, Administration, and Maintenance (OAM) G. Swallow Editor A. Fulignoli Editor M. Vigoureux Editor S. Boutros D. Ward November 2011 ASCII HTML 17 mpls-oam

This document specifies Operations, Administration, and Maintenance (OAM) messages to indicate service disruptive conditions for MPLS-based transport network Label Switched Paths. The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point. This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-fault-07 RFC7214 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6427 RFC6428 Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile D. Allan Editor G. Swallow Editor J. Drake Editor November 2011 ASCII HTML 21 mpls-tp oam Operations Administration and Maintenance bfd bidirectional forwarding dectection

Continuity Check, Proactive Connectivity Verification, and Remote Defect Indication functionalities are required for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM).

Continuity Check monitors a Label Switched Path for any loss of continuity defect. Connectivity Verification augments Continuity Check in order to provide confirmation that the desired source is connected to the desired sink. Remote Defect Indication enables an end point to report, to its associated end point, a fault or defect condition that it detects on a pseudowire, Label Switched Path, or Section.

This document specifies specific extensions to Bidirectional Forwarding Detection (BFD) and methods for proactive Continuity Check, Continuity Verification, and Remote Defect Indication for MPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as extended by this memo. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-cc-cv-rdi-06 RFC7214 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6428 10.17487/RFC6428 RFC6429 TCP Sender Clarification for Persist Condition M. Bashyam M. Jethanandani A. Ramaiah December 2011 ASCII HTML 7 zero window probe denial of service (DoS) security vulnerability

This document clarifies the Zero Window Probes (ZWPs) described in RFC 1122 ("Requirements for Internet Hosts -- Communication Layers"). In particular, it clarifies the actions that can be taken on connections that are experiencing the ZWP condition. Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified in RFC 1122. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-tcpm-persist-07 RFC9293 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC6429 RFC6430 Email Feedback Report Type Value: not-spam K. Li B. Leiba November 2011 ASCII HTML 7 arf abuse reporting format

This document defines a new Abuse Reporting Format (ARF) feedback report type value: "not-spam". It can be used to report an email message that was mistakenly marked as spam. [STANDARDS-TRACK]

 draft-ietf-marf-not-spam-feedback-03 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6430 RFC6431 Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP) M. Boucadair P. Levis G. Bajko T. Savolainen T. Tsou November 2011 ASCII HTML 16 IPv4 Address Exhaustion IPv4 service continuity IPv6 A+P

This document defines two Huawei IPCP (IP Control Protocol) options used to convey a set of ports. These options can be used in the context of port range-based solutions or NAT-based solutions for port delegation and forwarding purposes. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-boucadair-pppext-portrange-option-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6431 RFC6432 Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses R. Jesske L. Liess November 2011 ASCII HTML 4 cause code

Although the use of the SIP (Session Initiation Protocol) Reason header field in responses is considered in general in RFC 3326, its use is not specified for any particular response code. Nonetheless, existing deployments have been using Reason header fields to carry failure-related Q.850 cause codes in SIP responses to INVITE requests that have been gatewayed to Public Switched Telephone Network (PSTN) systems. This document normatively describes the use of the Reason header field in carrying Q.850 cause codes in SIP responses. [STANDARDS-TRACK]

 draft-jesske-dispatch-update3326-reason-responses-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6432 RFC6433 Requirements for a Working Group Milestones Tool P. Hoffman November 2011 ASCII HTML 7 working group charter charter

The IETF intends to provide a new tool to Working Group chairs and Area Directors for the creation and updating of milestones for Working Group charters. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. This document updates RFC 6292. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-genarea-milestones-tool-06 RFC6292 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6433 RFC6434 IPv6 Node Requirements E. Jankiewicz J. Loughney T. Narten December 2011 ASCII HTML 30 Internet Protocol Version 6 Internet Protocol IP

This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-6man-node-req-bis-11 RFC4294 RFC8504 INFORMATIONAL INFORMATIONAL IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6434 10.17487/RFC6434 RFC6435 MPLS Transport Profile Lock Instruct and Loopback Functions S. Boutros Editor S. Sivabalan Editor R. Aggarwal Editor M. Vigoureux Editor X. Dai Editor November 2011 ASCII HTML 12 oam operations administration and maintenance

Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data.

This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks.

This document updates Sections 7.1.1 and 7.1.2 of RFC 6371. [STANDARDS-TRACK]

 draft-ietf-mpls-tp-li-lb-08 RFC6371 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6435 10.17487/RFC6435 RFC6436 Rationale for Update to the IPv6 Flow Label Specification S. Amante B. Carpenter S. Jiang November 2011 ASCII HTML 13 ECMP LAG

Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it and to introduce some additional flexibility. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-6man-flow-update-07 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC6436 RFC6437 IPv6 Flow Label Specification S. Amante B. Carpenter S. Jiang J. Rajahalme November 2011 ASCII HTML 15

This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document.

The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]

 draft-ietf-6man-flow-3697bis-07 RFC3697 RFC2205 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6437 RFC6438 Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels B. Carpenter S. Amante November 2011 ASCII HTML 9 ECMP LAG

The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. [STANDARDS-TRACK]

 draft-ietf-6man-flow-ecmp-05 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6438 RFC6439 Routing Bridges (RBridges): Appointed Forwarders R. Perlman D. Eastlake Y. Li A. Banerjee F. Hu November 2011 ASCII HTML 15 trill TRansparent Interconnection of Lots of Links

The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called "RBridges" (Routing Bridges).

TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multiple RBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called "Appointed Forwarders", with the intent that native traffic in each VLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the Appointed Forwarder mechanism; thus, it updates RFC 6325. [STANDARDS-TRACK]

 draft-ietf-trill-rbridge-af-05 RFC8139 RFC6325 RFC7180 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC6439 RFC6440 The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option G. Zorn Q. Wu Y. Wang December 2011 ASCII HTML 6 re-authentication handover LDN Discovery

In order to derive a Domain-Specific Root Key (DSRK) from the Extended Master Session Key (EMSK) generated as a side effect of an Extensible Authentication Protocol (EAP) method, the EAP peer must discover the name of the domain to which it is attached.

This document specifies a Dynamic Host Configuration Protocol Version 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients using the EAP Re-authentication Protocol (ERP) EAP method of the name of the local domain for ERP. [STANDARDS-TRACK]

 draft-ietf-hokey-ldn-discovery-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey 10.17487/RFC6440 RFC6441 Time to Remove Filters for Previously Unallocated IPv4 /8s L. Vegoda November 2011 ASCII HTML 5 bogons IPv4 martians filters

It has been common for network administrators to filter IP traffic from and BGP prefixes of unallocated IPv4 address space. Now that there are no longer any unallocated IPv4 /8s, this practise is more complicated, fragile, and expensive. Network administrators are advised to remove filters based on the registration status of the address space.

This document explains why any remaining packet and BGP prefix filters for unallocated IPv4 /8s should now be removed on border routers and documents those IPv4 unicast prefixes that should not be routed across the public Internet. This memo documents an Internet Best Current Practice.

 draft-ietf-grow-no-more-unallocated-slash8s-04 BCP0171 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC6441 RFC6442 Location Conveyance for the Session Initiation Protocol J. Polk B. Rosen J. Peterson December 2011 ASCII HTML 35 sip geographic location location target

This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. [STANDARDS-TRACK]

 draft-ietf-sipcore-location-conveyance-09 RFC8262 RFC8787 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6442 10.17487/RFC6442 RFC6443 Framework for Emergency Calling Using Internet Multimedia B. Rosen H. Schulzrinne J. Polk A. Newton December 2011 ASCII HTML 38

The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ecrit-framework-13 RFC7852 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC6443 RFC6444 Location Hiding: Problem Statement and Requirements H. Schulzrinne L. Liess H. Tschofenig B. Stark A. Kuett January 2012 ASCII HTML 9 emergency call privacy PSAP Location by Reference

The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to endpoints or Voice over IP (VoIP) service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). To determine the PSAP Uniform Resource Identifier (URI), the usage of the Location-to-Service Translation (LoST) protocol is envisioned.

This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ecrit-location-hiding-req-04 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC6444 RFC6445 Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute T. Nadeau Editor A. Koushik Editor R. Cetin Editor November 2011 ASCII HTML 53 mib frr MPLS-FRR-GENERAL-STD-MIB MPLS-FRR-ONE2ONE-STD-MIB MPLS-FRR-FACILITY-STD-MIB

This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS)-based traffic engineering (TE). The two methods are the one-to-one backup method and the facility backup method. [STANDARDS-TRACK]

 draft-ietf-mpls-fastreroute-mib-21 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6445 RFC6446 Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control A. Niemi K. Kiss S. Loreto January 2012 ASCII HTML 25 SIP events rate control

This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. This document updates RFC 3265. [STANDARDS-TRACK]

 draft-ietf-sipcore-event-rate-control-09 RFC3265 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6446 RFC6447 Filtering Location Notifications in the Session Initiation Protocol (SIP) R. Mahy B. Rosen H. Tschofenig January 2012 ASCII HTML 19 geopriv location

This document describes filters that limit asynchronous location notifications to compelling events. These filters are designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package. The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format Location Object (PIDF-LO). [STANDARDS-TRACK]

 draft-ietf-geopriv-loc-filters-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6447 RFC6448 The Unencrypted Form of Kerberos 5 KRB-CRED Message R. Yount November 2011 ASCII HTML 4 credential

The Kerberos 5 KRB-CRED message is used to transfer Kerberos credentials between applications. When used with a secure transport, the unencrypted form of the KRB-CRED message may be desirable. This document describes the unencrypted form of the KRB-CRED message. [STANDARDS-TRACK]

 draft-ietf-krb-wg-clear-text-cred-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6448 RFC6449 Complaint Feedback Loop Operational Recommendations J. Falk Editor November 2011 ASCII HTML 31 MAAWG ARF MARF feedback loop spam reporting

Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices. This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry practices.

This document is the result of cooperative efforts within the Messaging Anti-Abuse Working Group, a trade organization separate from the IETF. The original MAAWG document upon which this document is based was published in April, 2010. This document does not represent the consensus of the IETF; rather it is being published as an Informational RFC to make it widely available to the Internet community and simplify reference to this material from IETF work. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-jdfalk-maawg-cfblbcp-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6449 RFC6450 Multicast Ping Protocol S. Venaas December 2011 ASCII HTML 24 ssm asm ssmping asmping

The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast -- both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information, such as multicast tree setup time. This protocol is based on an implementation of tools called "ssmping" and "asmping". [STANDARDS-TRACK]

 draft-ietf-mboned-ssmping-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC6450 RFC6451 Location-to-Service Translation (LoST) Protocol Extensions A. Forte H. Schulzrinne December 2011 ASCII HTML 23 location-based services location GPS point of interest

An important class of location-based services answers the question, "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots), or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries of the type "N nearest", "within distance X", and "served by". This document defines an Experimental Protocol for the Internet community.

 draft-forte-lost-extensions-08 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6451 RFC6452 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0 P. Faltstrom Editor P. Hoffman Editor November 2011 ASCII HTML 4 DNS IDN

This memo documents IETF consensus for Internationalized Domain Names for Applications (IDNA) derived character properties related to the three code points, existing in Unicode 5.2, that changed property values when version 6.0 was released. The consensus is that no update is needed to RFC 5892 based on the changes made in Unicode 6.0. [STANDARDS-TRACK]

 draft-faltstrom-5892bis-05 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC6452 RFC6453 A URN Namespace for the Open Grid Forum (OGF) F. Dijkstra R. Hughes-Jones December 2011 ASCII HTML 9 identifier

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Open Grid Forum (OGF) for naming persistent resources. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-dijkstra-urn-ogf-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6453 RFC6454 The Web Origin Concept A. Barth December 2011 ASCII HTML 20 same-origin policy security cross-origin

This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK]

 draft-ietf-websec-origin-06 PROPOSED STANDARD PROPOSED STANDARD IETF app websec http://www.rfc-editor.org/errata_search.php?rfc=6454 10.17487/RFC6454 RFC6455 The WebSocket Protocol I. Fette A. Melnikov December 2011 ASCII HTML 71 HyBi Working Group HYBI websocket

The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling). [STANDARDS-TRACK]

 draft-ietf-hybi-thewebsocketprotocol-17 RFC7936 RFC8307 RFC8441 PROPOSED STANDARD PROPOSED STANDARD IETF app hybi http://www.rfc-editor.org/errata_search.php?rfc=6455 10.17487/RFC6455 RFC6456 Multi-Segment Pseudowires in Passive Optical Networks H. Li R. Zheng A. Farrel November 2011 ASCII HTML 12 MPLS PSN PON G-PON XG-PON OMCI

This document describes the application of MPLS multi-segment pseudowires (MS-PWs) in a dual-technology environment comprising a Passive Optical Network (PON) and an MPLS Packet Switched Network (PSN).

PON technology may be used in mobile backhaul networks to support the end segments closest to the aggregation devices. In these cases, there may be a very large number of pseudowire (PW) Terminating Provider Edge (T-PE) nodes. The MPLS control plane could be used to provision these end segments, but support for the necessary protocols would complicate the management of the T-PEs and would significantly increase their expense. Alternatively, static, or management plane, configuration could be used to configure the end segments, but the very large number of such segments in a PON places a very heavy burden on the network manager.

This document describes how to set up the end segment of an end-to- end MPLS PW over a Gigabit-capable Passive Optical Network (G-PON) or 10 Gigabit-capable Passive Optical Network (XG-PON) using the G-PON and XG-PON management protocol, Optical Network Termination Management and Control Interface (OMCI). This simplifies and speeds up PW provisioning compared with manual configuration.

This document also shows how an MS-PW may be constructed from an end segment supported over a PON, and switched to one or more segments supported over an MPLS PSN. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-li-pwe3-ms-pw-pon-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6456 RFC6457 PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering T. Takeda Editor A. Farrel December 2011 ASCII HTML 12 PCEP inter-layer traffic engineering MPLS GMPLS VNT

The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS).

MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements.

Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". Generic requirements for a PCE discovery protocol are presented in RFC 4674, "Requirements for Path Computation Element (PCE) Discovery".

This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pce-inter-layer-req-15 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC6457 RFC6458 Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) R. Stewart M. Tuexen K. Poon P. Lei V. Yasevich December 2011 ASCII HTML 115

This document describes a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features, and a consolidated error and event notification scheme. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-tsvwg-sctpsocket-32 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6458 10.17487/RFC6458 RFC6459 IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) J. Korhonen Editor J. Soininen B. Patil T. Savolainen G. Bajko K. Iisakkila January 2012 ASCII HTML 36 Transition Migration

The use of cellular broadband for accessing the Internet and other data services via smartphones, tablets, and notebook/netbook computers has increased rapidly as a result of high-speed packet data networks such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being deployed. Operators that have deployed networks based on 3rd Generation Partnership Project (3GPP) network architectures are facing IPv4 address shortages at the Internet registries and are feeling pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-3gpp-eps-08 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6459 RFC6460 Suite B Profile for Transport Layer Security (TLS) M. Salter R. Housley January 2012 ASCII HTML 14 cryptographic algorithm policy

The United States government has published guidelines for "NSA Suite B Cryptography" that define cryptographic algorithm policy for national security applications. This document defines a profile of Transport Layer Security (TLS) version 1.2 that is fully compliant with Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-salter-rfc5430bis-01 RFC5430 RFC8996 HISTORIC INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6460 10.17487/RFC6460 RFC6461 Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements S. Channabasappa Editor January 2012 ASCII HTML 15 registry registry provisioning registrar destination group route group

This document captures the use cases and associated requirements for interfaces that provision session establishment data into Session Initiation Protocol (SIP) Service Provider components to assist with session routing. Specifically, this document focuses on the provisioning of one such element termed the "registry". This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-drinks-usecases-requirements-06 INFORMATIONAL INFORMATIONAL IETF rai drinks 10.17487/RFC6461 RFC6462 Report from the Internet Privacy Workshop A. Cooper January 2012 ASCII HTML 23

On December 8-9, 2010, the IAB co-hosted an Internet privacy workshop with the World Wide Web Consortium (W3C), the Internet Society (ISOC), and MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL). The workshop revealed some of the fundamental challenges in designing, deploying, and analyzing privacy-protective Internet protocols and systems. Although workshop participants and the community as a whole are still far from understanding how best to systematically address privacy within Internet standards development, workshop participants identified a number of potential next steps. For the IETF, these included the creation of a privacy directorate to review Internet-Drafts, further work on documenting privacy considerations for protocol developers, and a number of exploratory efforts concerning fingerprinting and anonymized routing. Potential action items for the W3C included investigating the formation of a privacy interest group and formulating guidance about fingerprinting, referrer headers, data minimization in APIs, usability, and general considerations for non-browser-based protocols.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect the views of the IAB, W3C, ISOC, or MIT CSAIL. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-privacy-workshop-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6462 RFC6463 Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6 J. Korhonen Editor S. Gundavelli H. Yokota X. Cui February 2012 ASCII HTML 22

This document describes a runtime local mobility anchor assignment functionality and corresponding mobility options for Proxy Mobile IPv6. The runtime local mobility anchor assignment takes place during a Proxy Binding Update and a Proxy Binding Acknowledgement message exchange between a mobile access gateway and a local mobility anchor. The runtime local mobility anchor assignment functionality defined in this specification can be used, for example, for load- balancing purposes. [STANDARDS-TRACK]

 draft-ietf-netext-redirect-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6463 RFC6464 A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication J. Lennox Editor E. Ivov E. Marocco December 2011 ASCII HTML 9 ssrc-audio-level ssrc speech sound energy conference bridge

This document defines a mechanism by which packets of Real-time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox that wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. [STANDARDS-TRACK]

 draft-ietf-avtext-client-to-mixer-audio-level-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC6464 RFC6465 A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication E. Ivov Editor E. Marocco Editor J. Lennox December 2011 ASCII HTML 15 csrc-audio-level csrc speech sound energy conference bridge

This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. [STANDARDS-TRACK]

 draft-ietf-avtext-mixer-to-client-audio-level-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC6465 RFC6466 IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP) G. Salgueiro December 2011 ASCII HTML 6 t.38 media

This document describes the usage of the 'image' media type and registers it with IANA as a top-level media type for the Session Description Protocol (SDP). This media type is primarily used by SDP to negotiate and establish T.38 media streams. [STANDARDS-TRACK]

 draft-salgueiro-mmusic-image-iana-registration-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6466 RFC6467 Secure Password Framework for Internet Key Exchange Version 2 (IKEv2) T. Kivinen December 2011 ASCII HTML 10 IPsec IKE mutual authentication credentials VPN gateway

This document defines a generic way for Internet Key Exchange version 2 (IKEv2) to use any of the symmetric secure password authentication methods. Multiple methods are already specified in other documents, and this document does not add any new one. This document specifies a way to agree on which method is to be used in the current connection. This document also provides a common way to transmit, between peers, payloads that are specific to secure password authentication methods.

 draft-kivinen-ipsecme-secure-password-framework-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6467 RFC6468 Sieve Notification Mechanism: SIP MESSAGE A. Melnikov B. Leiba K. Li February 2012 ASCII HTML 10 Sieve SIP notification

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. [STANDARDS-TRACK]

 draft-ietf-sieve-notify-sip-message-08 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6468 RFC6469 RTP Payload Format for DV (IEC 61834) Video K. Kobayashi K. Mishima S. Casner C. Bormann December 2011 ASCII HTML 18 DV/RTP real-time transport protocol

This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document obsoletes RFC 3189. [STANDARDS-TRACK]

 draft-ietf-payload-rfc3189bis-03 RFC3189 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6469 RFC6470 Network Configuration Protocol (NETCONF) Base Notifications A. Bierman February 2012 ASCII HTML 15 XML

The Network Configuration Protocol (NETCONF) provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events, such as a change in NETCONF server capabilities, that may impact management applications. Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. [STANDARDS-TRACK]

 draft-ietf-netconf-system-notifications-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6470 10.17487/RFC6470 RFC6471 Overview of Best Email DNS-Based List (DNSBL) Operational Practices C. Lewis M. Sergeant January 2012 ASCII HTML 21 DNSBL policy

The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists (DNSBLs) of IP addresses or domain names intended to help guide email filtering. This memo summarizes guidelines of accepted best practice for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties. It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-asrg-bcp-blacklists-10 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6471 RFC6472 Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP W. Kumari K. Sriram December 2011 ASCII HTML 5 BGPv4 Operator RPKI Aggregation Route Origin

This document recommends against the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. This memo documents an Internet Best Current Practice.

 draft-ietf-idr-deprecate-as-sets-06 BCP0172 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC6472 RFC6473 vCard KIND:application P. Saint-Andre December 2011 ASCII HTML 5 vCard

This document defines a value of "application" for the vCard KIND property so that vCards can be used to represent software applications. [STANDARDS-TRACK]

 draft-ietf-vcarddav-kind-app-00 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav 10.17487/RFC6473 RFC6474 vCard Format Extensions: Place of Birth, Place and Date of Death K. Li B. Leiba December 2011 ASCII HTML 6 contacts address-book personal-information

The base vCard 4.0 specification defines a large number of properties, including date of birth. This specification adds three new properties to vCard 4.0: place of birth, place of death, and date of death. [STANDARDS-TRACK]

 draft-ietf-vcarddav-birth-death-extensions-02 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6474 10.17487/RFC6474 RFC6475 Proxy Mobile IPv6 Management Information Base G. Keeni K. Koide S. Gundavelli R. Wakikawa May 2012 ASCII HTML 63

This memo defines a portion of the Proxy Mobile IPv6 Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, the Proxy Mobile IPv6 MIB can be used to monitor and control the mobile access gateway (MAG) and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6 (PMIPv6) entity. [STANDARDS-TRACK]

 draft-ietf-netlmm-pmipv6-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6475 10.17487/RFC6475 RFC6476 Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS) P. Gutmann January 2012 ASCII HTML 15 authenticated data

This document specifies the conventions for using Message Authentication Code (MAC) encryption with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. This mirrors the use of a MAC combined with an encryption algorithm that's already employed in IPsec, Secure Socket Layer / Transport Layer Security (SSL/TLS) and Secure SHell (SSH), which is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community. [STANDARDS-TRACK]

 draft-gutmann-cms-hmac-enc-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6476 10.17487/RFC6476 RFC6477 Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail A. Melnikov G. Lunt January 2012 ASCII HTML 21

A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHS Elements of Service are defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2 and ACP 123. This document specifies message header fields and associated processing for RFC 5322 (Internet Message Format) to provide a comparable messaging service. In addition, this document provides for a STANAG 4406 / Internet Email Gateway that supports message conversion. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-melnikov-mmhs-header-fields-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6477 RFC6478 Pseudowire Status for Static Pseudowires L. Martini G. Swallow G. Heron M. Bocci May 2012 ASCII HTML 13

This document specifies a mechanism to signal Pseudowire (PW) status messages using a PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far-end T-PE. The mechanism allows PW Operations, Administration, and Maintenance (OAM) message mapping and PW redundancy to operate on static PWs. This document also updates RFC 5885 in the case when Bi-directional Forwarding Detection (BFD) is used to convey PW status-signaling information. [STANDARDS-TRACK]

 draft-ietf-pwe3-static-pw-status-10 RFC5885 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6478 RFC6479 IPsec Anti-Replay Algorithm without Bit Shifting X. Zhang T. Tsou January 2012 ASCII HTML 9

This document presents an alternate method to do the anti-replay checks and updates for IP Authentication Header (AH) and Encapsulating Security Protocol (ESP). The method defined in this document obviates the need for bit shifting and it reduces the number of times an anti-replay window is adjusted. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-zhang-ipsecme-anti-replay-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6479 RFC6480 An Infrastructure to Support Secure Internet Routing M. Lepinski S. Kent February 2012 ASCII HTML 24 RPKI BGP ROA

This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sidr-arch-13 INFORMATIONAL INFORMATIONAL IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6480 10.17487/RFC6480 RFC6481 A Profile for Resource Certificate Repository Structure G. Huston R. Loomans G. Michaelson February 2012 ASCII HTML 15 rpki Resource Public Key Infrastructure

This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK]

 draft-ietf-sidr-repos-struct-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6481 RFC6482 A Profile for Route Origin Authorizations (ROAs) M. Lepinski S. Kent D. Kong February 2012 ASCII HTML 9 RPKI BGP

This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. [STANDARDS-TRACK]

 draft-ietf-sidr-roa-format-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6482 10.17487/RFC6482 RFC6483 Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) G. Huston G. Michaelson February 2012 ASCII HTML 8 rpki bgp Resource Public Key Infrastructure

This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-sidr-roa-validation-10 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC6483 RFC6484 Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI) S. Kent D. Kong K. Seo R. Watro February 2012 ASCII HTML 35 Certification Practice Statement CPS

This document describes the certificate policy for a Public Key Infrastructure (PKI) used to support attestations about Internet Number Resource (INR) holdings. Each organization that distributes IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a (public key) certificate reflecting this distribution. These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources. This memo documents an Internet Best Current Practice.

 draft-ietf-sidr-cp-17 BCP0173 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC6484 RFC6485 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) G. Huston February 2012 ASCII HTML 6

This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the relying parties (RPs) that verify these digital signatures. [STANDARDS-TRACK]

 draft-ietf-sidr-rpki-algs-05 RFC7935 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6485 10.17487/RFC6485 RFC6486 Manifests for the Resource Public Key Infrastructure (RPKI) R. Austein G. Huston S. Kent M. Lepinski February 2012 ASCII HTML 19

This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. [STANDARDS-TRACK]

 draft-ietf-sidr-rpki-manifests-16 RFC9286 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6486 RFC6487 A Profile for X.509 PKIX Resource Certificates G. Huston G. Michaelson R. Loomans February 2012 ASCII HTML 32 rpki Resource Public Key Infrastructure Internet Number Resources INR

This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK]

 draft-ietf-sidr-res-certs-22 RFC7318 RFC8209 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6487 10.17487/RFC6487 RFC6488 Signed Object Template for the Resource Public Key Infrastructure (RPKI) M. Lepinski A. Chi S. Kent February 2012 ASCII HTML 13 ROA manifest GhostBusters

This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK]

 draft-ietf-sidr-signed-object-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6488 10.17487/RFC6488 RFC6489 Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) G. Huston G. Michaelson S. Kent February 2012 ASCII HTML 10 RPKI

This document describes how a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair. This document also notes the implications of this key rollover procedure for relying parties (RPs). In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs. This memo documents an Internet Best Current Practice.

 draft-ietf-sidr-keyroll-08 BCP0174 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6489 10.17487/RFC6489 RFC6490 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator G. Huston S. Weiler G. Michaelson S. Kent February 2012 ASCII HTML 7 tal

This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). [STANDARDS-TRACK]

 draft-ietf-sidr-ta-07 RFC7730 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6490 RFC6491 Resource Public Key Infrastructure (RPKI) Objects Issued by IANA T. Manderson L. Vegoda S. Kent February 2012 ASCII HTML 12 sidr rpki iana as0 as 0 roa

This document provides specific direction to IANA as to the Resource Public Key Infrastructure (RPKI) objects it should issue. [STANDARDS-TRACK]

 draft-ietf-sidr-iana-objects-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6491 RFC6492 A Protocol for Provisioning Resource Certificates G. Huston R. Loomans B. Ellacott R. Austein February 2012 ASCII HTML 32 RPKI

This document defines a framework for certificate management interactions between an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the subject, and corresponding responses from the issuer encompassing the actions of certificate issuance, certificate revocation, and certificate status information reports. This protocol is intended to be limited to the application of Internet Number Resource Certificate management and is not intended to be used as part of a more general certificate management framework. [STANDARDS-TRACK]

 draft-ietf-sidr-rescerts-provisioning-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6492 RFC6493 The Resource Public Key Infrastructure (RPKI) Ghostbusters Record R. Bush February 2012 ASCII HTML 8 RPKI Resource Certificate Human Contact vCard

In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This document describes the RPKI Ghostbusters Record containing human contact information that may be verified (indirectly) by a Certification Authority (CA) certificate. The data in the record are those of a severely profiled vCard. [STANDARDS- TRACK]

 draft-ietf-sidr-ghostbusters-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6493 10.17487/RFC6493 RFC6494 Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND) R. Gagliano S. Krishnan A. Kukec February 2012 ASCII HTML 12 RPKI ND

SEcure Neighbor Discovery (SEND) utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND based on resource certificates along with extended key usage values required for SEND. [STANDARDS-TRACK]

 draft-ietf-csi-send-cert-10 RFC3971 PROPOSED STANDARD PROPOSED STANDARD IETF int csi http://www.rfc-editor.org/errata_search.php?rfc=6494 10.17487/RFC6494 RFC6495 Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields R. Gagliano S. Krishnan A. Kukec February 2012 ASCII HTML 5

SEcure Neighbor Discovery (SEND) defines the Name Type field in the ICMPv6 Trust Anchor option. This document specifies new Name Type fields based on certificate Subject Key Identifiers (SKIs). [STANDARDS-TRACK]

 draft-ietf-csi-send-name-type-registry-06 RFC3971 PROPOSED STANDARD PROPOSED STANDARD IETF int csi 10.17487/RFC6495 RFC6496 Secure Proxy ND Support for SEcure Neighbor Discovery (SEND) S. Krishnan J. Laganier M. Bonola A. Garcia-Martinez February 2012 ASCII HTML 24 SPND CGA Mobile IPv6 MIPv6 Proxy Mobile IPv6 PMIPv6

SEcure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending an ND message is the owner of the address from which the message is sent and/or possesses a key that authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND. This document extends the current SEND specification in order to secure Proxy ND operation. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-csi-proxy-send-05 EXPERIMENTAL EXPERIMENTAL IETF int csi 10.17487/RFC6496 RFC6497 BCP 47 Extension T - Transformed Content M. Davis A. Phillips Y. Umaoka C. Falk February 2012 ASCII HTML 15 locale

This document specifies an Extension to BCP 47 that provides subtags for specifying the source language or script of transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source. It also provides for additional information used for identification. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-davis-t-langtag-ext-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6497 10.17487/RFC6497 RFC6498 Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package J. Stone R. Kumar F. Andreasen February 2012 ASCII HTML 47

This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from Voiceband Data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to defining these new packages, this document describes the use of the Media Format Parameter package and Fax package with VBD, redundancy, and FEC. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-stone-mgcp-vbd-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6498 RFC6499 RFC6500 RFC6501 Conference Information Data Model for Centralized Conferencing (XCON) O. Novo G. Camarillo D. Morgan J. Urpalainen March 2012 ASCII HTML 94

RFC 5239 defines centralized conferencing (XCON) as an association of participants with a central focus. The state of a conference is represented by a conference object. This document defines an XML- based conference information data model to be used for conference objects. A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) event package for conference State. [STANDARDS-TRACK]

 draft-ietf-xcon-common-data-model-32 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC6501 RFC6502 Conference Event Package Data Format Extension for Centralized Conferencing (XCON) G. Camarillo S. Srinivasan R. Even J. Urpalainen March 2012 ASCII HTML 14

This document specifies the notification mechanism for XCON (centralized conferencing). This mechanism reuses the SIP (Session Initiation Protocol) event package for conference state. Additionally, the notification mechanism includes support for the XCON data model and for partial notifications. [STANDARDS-TRACK]

 draft-ietf-xcon-event-package-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC6502 RFC6503 Centralized Conferencing Manipulation Protocol M. Barnes C. Boulton S. Romano H. Schulzrinne March 2012 ASCII HTML 119 conference user ad hoc conference sidebar conference scheduled conference

The Centralized Conferencing Manipulation Protocol (CCMP) allows a Centralized Conferencing (XCON) system client to create, retrieve, change, and delete objects that describe a centralized conference. CCMP is a means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details. CCMP is a stateless, XML-based, client server protocol that carries, in its request and response messages, conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema. [STANDARDS-TRACK]

 draft-ietf-xcon-ccmp-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon http://www.rfc-editor.org/errata_search.php?rfc=6503 10.17487/RFC6503 RFC6504 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples M. Barnes L. Miniero R. Presta S P. Romano March 2012 ASCII HTML 78

This document provides detailed call flows for the scenarios documented in the Framework for Centralized Conferencing (XCON) (RFC 5239) and in the XCON scenarios (RFC 4597). The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP) (RFC 6503). The objective is to provide detailed examples for reference by both protocol researchers and developers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-xcon-examples-10 INFORMATIONAL INFORMATIONAL IETF rai xcon 10.17487/RFC6504 RFC6505 A Mixer Control Package for the Media Control Channel Framework S. McGlashan T. Melanchuk C. Boulton March 2012 ASCII HTML 89 conference mixer

This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections. The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications. The package also defines elements for auditing package capabilities and mixers [STANDARDS-TRACK]

 draft-ietf-mediactrl-mixer-control-package-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl http://www.rfc-editor.org/errata_search.php?rfc=6505 10.17487/RFC6505 RFC6506 Supporting Authentication Trailer for OSPFv3 M. Bhatia V. Manral A. Lindem February 2012 ASCII HTML 20 Routing security

Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication. [STANDARDS-TRACK]

 draft-ietf-ospf-auth-trailer-ospfv3-11 RFC7166 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6506 10.17487/RFC6506 RFC6507 Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) M. Groves February 2012 ASCII HTML 17

Many signature schemes currently in use rely on certificates for authentication of identity. In Identity-based cryptography, this adds unnecessary overhead and administration. The Elliptic Curve-based Certificateless Signatures for Identity-based Encryption (ECCSI) signature scheme described in this document is certificateless. This scheme has the additional advantages of low bandwidth and low computational requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-groves-eccsi-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6507 RFC6508 Sakai-Kasahara Key Encryption (SAKKE) M. Groves February 2012 ASCII HTML 21

In this document, the Sakai-Kasahara Key Encryption (SAKKE) algorithm is described. This uses Identity-Based Encryption to exchange a shared secret from a Sender to a Receiver. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-groves-sakke-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6508 RFC6509 MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY) M. Groves February 2012 ASCII HTML 21

This document describes the Multimedia Internet KEYing-Sakai-Kasahara Key Encryption (MIKEY-SAKKE), a method of key exchange that uses Identity-based Public Key Cryptography (IDPKC) to establish a shared secret value and certificateless signatures to provide source authentication. MIKEY-SAKKE has a number of desirable features, including simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-groves-mikey-sakke-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6509 RFC6510 Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects L. Berger G. Swallow February 2012 ASCII HTML 8

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions may be signaled with a set of LSP-specific attributes. These attributes may be carried in both Path and Resv messages. This document specifies how LSP attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form and clarifies related Resv message formats. This document updates RFC 4875 and RFC 5420. [STANDARDS-TRACK]

 draft-ietf-ccamp-attribute-bnf-02 RFC4875 RFC5420 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6510 RFC6511 Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths Z. Ali G. Swallow R. Aggarwal February 2012 ASCII HTML 10

There are many deployment scenarios that require an egress Label Switching Router (LSR) to receive binding of the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some "out-of-band" (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. [STANDARDS-TRACK]

 draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6511 RFC6512 Using Multipoint LDP When the Backbone Has No Route to the Root IJ. Wijnands E. Rosen M. Napierala N. Leymann February 2012 ASCII HTML 12

The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, this is not possible if the route to the root node is a BGP route and the intermediate nodes are part of a BGP-free core. This document specifies procedures that enable an MP LSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node. [STANDARDS-TRACK]

 draft-ietf-mpls-mldp-recurs-fec-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6512 10.17487/RFC6512 RFC6513 Multicast in MPLS/BGP IP VPNs E. Rosen Editor R. Aggarwal Editor February 2012 ASCII HTML 88

In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK]

 draft-ietf-l3vpn-2547bis-mcast-10 RFC7582 RFC7900 RFC7988 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6513 10.17487/RFC6513 RFC6514 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs R. Aggarwal E. Rosen T. Morin Y. Rekhter February 2012 ASCII HTML 59

This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]

 draft-ietf-l3vpn-2547bis-mcast-bgp-08 RFC6515 RFC6625 RFC7385 RFC7441 RFC7582 RFC7899 RFC7900 RFC7902 RFC7988 RFC8534 RFC9081 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6514 10.17487/RFC6514 RFC6515 IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN R. Aggarwal E. Rosen February 2012 ASCII HTML 8 mvpn mcast-vpn multicast-vpn

To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN") BGP routes; they also originate unicast VPN routes that carry MVPN-specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider's address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses. To ensure interoperability, this document specifies that provider IPv4 addresses are always encoded in these update messages as 4-octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. This document updates RFC 6514. [STANDARDS-TRACK]

 draft-ietf-l3vpn-mvpn-infra-addrs-05 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6515 10.17487/RFC6515 RFC6516 IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages Y. Cai E. Rosen Editor I. Wijnands February 2012 ASCII HTML 6

The specification for Multicast Virtual Private Networks (MVPNs) contains an option that allows the use of PIM as the control protocol between provider edge routers. It also contains an option that allows UDP-based messages, known as Selective Provider Multicast Service Interface (S-PMSI) Join messages, to be used to bind particular customer multicast flows to particular tunnels through a service provider's network. This document extends the MVPN specification (RFC 6513) so that these options can be used when the customer multicast flows are IPv6 flows. [STANDARDS-TRACK]

 draft-ietf-l3vpn-mvpn-spmsi-joins-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC6516 RFC6517 Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution T. Morin Editor B. Niven-Jenkins Editor Y. Kamite R. Zhang N. Leymann N. Bitar February 2012 ASCII HTML 41 mpls vpn multicast l3vpn bgp pim p2mp ldp rsvp-te

More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks.

To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-l3vpn-mvpn-considerations-06 INFORMATIONAL INFORMATIONAL IETF rtg l3vpn 10.17487/RFC6517 RFC6518 Keying and Authentication for Routing Protocols (KARP) Design Guidelines G. Lebovitz M. Bhatia February 2012 ASCII HTML 30 MAC hash security securing secure authorization protection harden hardening infrastructure router crypto cryptography cryptographic roadmap guide guideline message framework key keys management protocol KMP key management protocol,

This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-karp-design-guide-10 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6518 RFC6519 RADIUS Extensions for Dual-Stack Lite R. Maglione A. Durand February 2012 ASCII HTML 11 IPv6 tunnel attribute

Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix. Dual-Stack Lite requires pre-configuration of the Dual-Stack Lite Address Family Transition Router (AFTR) tunnel information on the Basic Bridging BroadBand (B4) element. In many networks, the customer profile information may be stored in Authentication, Authorization, and Accounting (AAA) servers, while client configurations are mainly provided through the Dynamic Host Configuration Protocol (DHCP). This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Dual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used between the RADIUS server and the Network Access Server (NAS); it is not intended to be used directly between the B4 element and the RADIUS server. [STANDARDS-TRACK]

 draft-ietf-softwire-dslite-radius-ext-07 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=6519 10.17487/RFC6519 RFC6520 Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension R. Seggelmann M. Tuexen M. Williams February 2012 ASCII HTML 9 tls/dtls

This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.

The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. [STANDARDS-TRACK]

 draft-ietf-tls-dtls-heartbeat-04 RFC8447 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=6520 10.17487/RFC6520 RFC6521 Home Agent-Assisted Route Optimization between Mobile IPv4 Networks A. Makela J. Korhonen February 2012 ASCII HTML 53 mobile router mobile network prefix correspondent router

This document describes a home agent-assisted route optimization functionality for the IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single home agent; thus, the use case is route optimization within a single organization or similar entity. The functionality enables the discovery of eligible peer nodes (based on information received from the home agent) and their network prefixes, and the establishment of a direct tunnel between such nodes. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-mip4-nemo-haaro-07 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC6521 RFC6522 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages M. Kucherawy Editor January 2012 ASCII HTML 9 MIME Multipurpose Internet Mail Extensions

The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports.

This memo obsoletes "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, and marks RFC 3462 and its predecessor as "Historic". [STANDARDS-TRACK]

 draft-ietf-appsawg-rfc3462bis-04 RFC3462 RFC6533 STD0073 INTERNET STANDARD INTERNET STANDARD IETF app appsawg 10.17487/RFC6522 RFC6523 RFC6524 RFC6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration R. Stewart M. Tuexen P. Lei February 2012 ASCII HTML 34

Many applications that use the Stream Control Transmission Protocol (SCTP) want the ability to "reset" a stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed. Applications requiring this feature want it so that they can "reuse" streams for different purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected, unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transmission sequence numbers, adding additional streams, and resetting all stream sequence numbers. [STANDARDS-TRACK]

 draft-ietf-tsvwg-sctp-strrst-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6525 RFC6526 IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream B. Claise P. Aitken A. Johnson G. Muenz March 2012 ASCII HTML 23

This document specifies an extension to the specifications in RFC 5101, IP Flow Information Export (IPFIX), when using the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol).

When implemented at both the Exporting Process and Collecting Process, this method offers several advantages, such as the ability to calculate Data Record losses for PR-SCTP per Template, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting Process or Exporting Process, then normal IPFIX behavior will be seen without all of the additional benefits. [STANDARDS-TRACK]

 draft-ietf-ipfix-export-per-sctp-stream-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC6526 RFC6527 Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3) K. Tata March 2012 ASCII HTML 31 management information base

This specification defines a portion of the Management Information Base (MIB) for use with network management based on the Simple Network Management Protocol (SNMP). In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for both IPv4 and IPv6 as defined in RFC 5798. This memo obsoletes RFC 2787. [STANDARDS-TRACK]

 draft-ietf-vrrp-unified-mib-10 RFC2787 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6527 10.17487/RFC6527 RFC6528 Defending against Sequence Number Attacks F. Gont S. Bellovin February 2012 ASCII HTML 12 TCP security TCP Sequence Numbers Sequence Number Randomization obfuscation TCP vulnerabilities

This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. [STANDARDS-TRACK]

 draft-ietf-tcpm-rfc1948bis-02 RFC1948 RFC9293 RFC0793 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6528 RFC6529 Host/Host Protocol for the ARPA Network A. McKenzie S. Crocker April 2012 ASCII HTML 34

This document reproduces the Host/Host Protocol developed by the ARPA Network Working Group during 1969, 1970, and 1971. It describes a protocol used to manage communication between processes residing on independent Hosts. It addresses issues of multiplexing multiple streams of communication (including addressing, flow control, connection establishment/disestablishment, and other signaling) over a single hardware interface. It was the official protocol of the ARPA Network from January 1972 until the switch to TCP/IP in January 1983. It is offered as an RFC at this late date to help complete the historical record available through the RFC series. This document is not an Internet Standards Track specification; it is published for the historical record.

 draft-mckenzie-arpanet-host-host-protocol-01 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC6529 RFC6530 Overview and Framework for Internationalized Email J. Klensin Y. Ko February 2012 ASCII HTML 26 SMTP Email I18n Internationalization SMTPUTF8

Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. [STANDARDS-TRACK]

 draft-ietf-eai-frmwrk-4952bis-12 RFC4952 RFC5504 RFC5825 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6530 RFC6531 SMTP Extension for Internationalized Email J. Yao W. Mao February 2012 ASCII HTML 18 SMTP Email I18n Internationalization SMTPUTF8

This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. [STANDARDS-TRACK]

 draft-ietf-eai-rfc5336bis-16 RFC5336 PROPOSED STANDARD PROPOSED STANDARD IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=6531 10.17487/RFC6531 RFC6532 Internationalized Email Headers A. Yang S. Steele N. Freed February 2012 ASCII HTML 11

Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content.

This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". [STANDARDS-TRACK]

 draft-ietf-eai-rfc5335bis-13 RFC5335 RFC2045 PROPOSED STANDARD PROPOSED STANDARD IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=6532 10.17487/RFC6532 RFC6533 Internationalized Delivery Status and Disposition Notifications T. Hansen Editor C. Newman A. Melnikov February 2012 ASCII HTML 19 dsn

Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.

This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522. [STANDARDS-TRACK]

 draft-ietf-eai-rfc5337bis-dsn-06 RFC5337 RFC3461 RFC3464 RFC3798 RFC6522 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6533 RFC6534 Loss Episode Metrics for IP Performance Metrics (IPPM) N. Duffield A. Morton J. Sommers May 2012 ASCII HTML 21

The IETF has developed a one-way packet loss metric that measures the loss rate on a Poisson and Periodic probe streams between two hosts. However, the impact of packet loss on applications is, in general, sensitive not just to the average loss rate but also to the way in which packet losses are distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets). This document defines one-way packet loss episode metrics, specifically, the frequency and average duration of loss episodes and a probing methodology under which the loss episode metrics are to be measured. [STANDARDS-TRACK]

 draft-ietf-ippm-loss-episode-metrics-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC6534 RFC6535 Dual-Stack Hosts Using "Bump-in-the-Host" (BIH) B. Huang H. Deng T. Savolainen February 2012 ASCII HTML 25 NAT NAT46 DNS DNS46 translation IPv4 applications IPv6 ENR

Bump-in-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This document obsoletes RFC 2767 and RFC 3338. [STANDARDS-TRACK]

 draft-ietf-behave-v4v6-bih-09 RFC2767 RFC3338 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6535 10.17487/RFC6535 RFC6536 Network Configuration Protocol (NETCONF) Access Control Model A. Bierman M. Bjorklund March 2012 ASCII HTML 49 NETCONF YANG XML

The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. [STANDARDS-TRACK]

 draft-ietf-netconf-access-control-07 RFC8341 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6536 10.17487/RFC6536 RFC6537 Host Identity Protocol Distributed Hash Table Interface J. Ahrenholz February 2012 ASCII HTML 20 HIP Host Identity Protocol DHT DIstributed Hash Table HIT Host Identity Tag resolution service

This document specifies a common interface for using the Host Identity Protocol (HIP) with a Distributed Hash Table (DHT) service to provide a name-to-Host-Identity-Tag lookup service and a Host- Identity-Tag-to-address lookup service. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-hiprg-dht-05 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6537 RFC6538 The Host Identity Protocol (HIP) Experiment Report T. Henderson A. Gurtov March 2012 ASCII HTML 35 Security ID/locator split IPsec Research

This document is a report from the IRTF Host Identity Protocol (HIP) research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The document summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications. The perspective of a network operator, as well as a list of HIP experiments, are presented as well. Portions of this report may be relevant also to other network overlay-based architectures or to attempts to deploy alternative networking architectures. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-irtf-hip-experiment-15 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6538 RFC6539 IBAKE: Identity-Based Authenticated Key Exchange V. Cakulev G. Sundaram I. Broustis March 2012 ASCII HTML 13 ibe identity based encryption

Cryptographic protocols based on public-key methods have been traditionally based on certificates and Public Key Infrastructure (PKI) to support certificate management. The emerging field of Identity-Based Encryption (IBE) protocols allows simplification of infrastructure requirements via a Private-Key Generator (PKG) while providing the same flexibility. However, one significant limitation of IBE methods is that the PKG can end up being a de facto key escrow server, with undesirable consequences. Another observed deficiency is a lack of mutual authentication of communicating parties. This document specifies the Identity-Based Authenticated Key Exchange (IBAKE) protocol. IBAKE does not suffer from the key escrow problem and in addition provides mutual authentication as well as perfect forward and backward secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-cakulev-ibake-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6539 RFC6540 IPv6 Support Required for All IP-Capable Nodes W. George C. Donley C. Liljenstolpe L. Howard April 2012 ASCII HTML 6 IPv4 requirement

Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional. It also cautions that there are places in existing IETF documents where the term "IP" is used in a way that could be misunderstood by implementers as the term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, or IPv4-only, depending on context and application. This memo documents an Internet Best Current Practice.

 draft-ietf-intarea-ipv6-required-02 BCP0177 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int intarea 10.17487/RFC6540 RFC6541 DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures M. Kucherawy February 2012 ASCII HTML 16 Authentication Reputation

This experimental specification proposes a modification to DomainKeys Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author. This document defines an Experimental Protocol for the Internet community.

 draft-kucherawy-dkim-atps-16 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6541 RFC6542 Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility S. Emery March 2012 ASCII HTML 6

Currently, channel bindings are implemented using an MD5 hash in the Kerberos Version 5 Generic Security Service Application Programming Interface (GSS-API) mechanism (RFC 4121). This document updates RFC 4121 to allow channel bindings using algorithms negotiated based on Kerberos crypto framework as defined in RFC 3961. In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange message, extensions are defined to allow future protocol extensions. [STANDARDS-TRACK]

 draft-ietf-krb-wg-gss-cb-hash-agility-10 RFC4121 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6542 RFC6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6 S. Gundavelli May 2012 ASCII HTML 5

Proxy Mobile IPv6 (RFC 5213) requires that all mobile access gateways use a fixed link-local address and a fixed link-layer address on any of their access links that they share with mobile nodes. This requirement was intended to ensure that a mobile node does not detect any change with respect to its Layer 3 attachment, even after it roams from one mobile access gateway to another. In the absence of any reserved addresses for this use, coordination across vendors and manual configuration of these addresses on all of the mobility elements in a Proxy Mobile IPv6 domain are required. This document attempts to simplify this operational requirement by making a reservation for special addresses that can be used for this purpose. This document also updates RFC 5213. [STANDARDS-TRACK]

 draft-gundavelli-v6ops-pmipv6-address-reservations-06 RFC5213 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6543 RFC6544 TCP Candidates with Interactive Connectivity Establishment (ICE) J. Rosenberg A. Keranen B. B. Lowekamp A. B. Roach March 2012 ASCII HTML 29 ICE TCP NAT NAT traversal

Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates but only defines UDP-based media streams. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. [STANDARDS-TRACK]

 draft-ietf-mmusic-ice-tcp-16 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=6544 10.17487/RFC6544 RFC6545 Real-time Inter-network Defense (RID) K. Moriarty April 2012 ASCII HTML 84 incident response incident coordination incident handling incident communication

Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident-handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident-handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC 6045. [STANDARDS-TRACK]

 draft-ietf-mile-rfc6045-bis-11 RFC6045 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile http://www.rfc-editor.org/errata_search.php?rfc=6545 10.17487/RFC6545 RFC6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS B. Trammell April 2012 ASCII HTML 8 Coordinated Incident Response CSIRT Incident Object Description Exchange Format IODEF

The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies an application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS. [STANDARDS-TRACK]

 draft-ietf-mile-rfc6046-bis-09 RFC6046 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile http://www.rfc-editor.org/errata_search.php?rfc=6546 10.17487/RFC6546 RFC6547 RFC 3627 to Historic Status W. George February 2012 ASCII HTML 3 IPv6 /127 point-to-point address inter-router links

This document moves "Use of /127 Prefix Length Between Routers Considered Harmful" (RFC 3627) to Historic status to reflect the updated guidance contained in "Using 127-Bit IPv6 Prefixes on Inter- Router Links" (RFC 6164). A Standards Track document supersedes an informational document; therefore, guidance provided in RFC 6164 is to be followed when the two documents are in conflict. This document links the two RFCs so that the IETF's updated guidance on this topic is clearer. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-6man-3627-historic-01 RFC3627 RFC6164 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC6547 RFC6548 Independent Submission Editor Model N. Brownlee Editor IAB June 2012 ASCII HTML 5 Independent Stream Editor

This document describes the function and responsibilities of the RFC Independent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC Production Center and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF Administrative Oversight Committee (IAOC). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-ise-model-07 RFC5620 RFC8730 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6548 RFC6549 OSPFv2 Multi-Instance Extensions A. Lindem A. Roy S. Mirtorabi March 2012 ASCII HTML 9 Instance ID

OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilize such a mechanism in order to support multiple routing domains on the same subnet.

This document defines the OSPFv2 Instance ID to enable separate OSPFv2 protocol instances on the same interface. Unlike OSPFv3 where the Instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 Instance ID is reserved for identifying protocol instances.

This document updates RFC 2328. [STANDARDS-TRACK]

 draft-ietf-ospf-multi-instance-09 RFC2328 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6549 10.17487/RFC6549 RFC6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks T. Winter Editor P. Thubert Editor A. Brandt J. Hui R. Kelsey P. Levis K. Pister R. Struik JP. Vasseur R. Alexander March 2012 ASCII HTML 157 WSN for Wireless Sensor Network L3 Mesh for Layer 3 Mesh Network Routing Protocol Subnet Routing Distance Vector Objective Function DAG for Directed Acyclic Graph

Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK]

 draft-ietf-roll-rpl-19 RFC9008 RFC9010 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=6550 10.17487/RFC6550 RFC6551 Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks JP. Vasseur Editor M. Kim Editor K. Pister N. Dejean D. Barthel March 2012 ASCII HTML 30 RPL ROLL LLN Constrained based routing,

Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). [STANDARDS-TRACK]

 draft-ietf-roll-routing-metrics-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=6551 10.17487/RFC6551 RFC6552 Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) P. Thubert Editor March 2012 ASCII HTML 14 WSN for Wireless Sensor Network L3 Mesh for Layer 3 Mesh Network Routing Protocol Subnet Routing Distance Vector Objective Function DAG for Directed Acyclic Graph RPL

The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available; an OF is not an algorithm.

This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions. [STANDARDS-TRACK]

 draft-ietf-roll-of0-20 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC6552 RFC6553 The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams J. Hui JP. Vasseur March 2012 ASCII HTML 9 LLN LLNs Trickle

The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes the RPL Option for use among RPL routers to include such routing information. [STANDARDS-TRACK]

 draft-ietf-6man-rpl-option-06 RFC9008 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6553 RFC6554 An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) J. Hui JP. Vasseur D. Culler V. Manral March 2012 ASCII HTML 13 LLN LLNs

In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK]

 draft-ietf-6man-rpl-routing-header-07 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6554 RFC6555 Happy Eyeballs: Success with Dual-Stack Hosts D. Wing A. Yourtchenko April 2012 ASCII HTML 15

When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. [STANDARDS-TRACK]

 draft-ietf-v6ops-happy-eyeballs-07 RFC8305 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=6555 10.17487/RFC6555 RFC6556 Testing Eyeball Happiness F. Baker April 2012 ASCII HTML 10 test methodology IPv4 IPv6 session startup metrics

The amount of time it takes to establish a session using common transport APIs in dual-stack networks and networks with filtering such as proposed in BCP 38 is a barrier to IPv6 deployment. This note describes a test that can be used to determine whether an application can reliably establish sessions quickly in a complex environment such as dual-stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering. This test is not a test of a specific algorithm, but of the external behavior of the system as a black box. Any algorithm that has the intended external behavior will be accepted by it. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-baker-bmwg-testing-eyeball-happiness-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6556 RFC6557 Procedures for Maintaining the Time Zone Database E. Lear P. Eggert February 2012 ASCII HTML 9

Time zone information serves as a basic protocol element in protocols, such as the calendaring suite and DHCP. The Time Zone (TZ) Database specifies the indices used in various protocols, as well as their semantic meanings, for all localities throughout the world. This database has been meticulously maintained and distributed free of charge by a group of volunteers, coordinated by a single volunteer who is now planning to retire. This memo specifies procedures involved with maintenance of the TZ database and associated code, including how to submit proposed updates, how decisions for inclusion of those updates are made, and the selection of a designated expert by and for the time zone community. The intent of this memo is, to the extent possible, to document existing practice and provide a means to ease succession of the database maintainers. This memo documents an Internet Best Current Practice.

 draft-lear-iana-timezone-database-05 BCP0175 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6557 RFC6558 Sieve Extension for Converting Messages before Delivery A. Melnikov B. Leiba K. Li March 2012 ASCII HTML 8 Sieve CONVERT

This document describes how the "CONVERT" IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery. [STANDARDS-TRACK]

 draft-ietf-sieve-convert-06 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=6558 10.17487/RFC6558 RFC6559 A Reliable Transport Mechanism for PIM D. Farinacci IJ. Wijnands S. Venaas M. Napierala March 2012 ASCII HTML 29

This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-pim-port-09 EXPERIMENTAL EXPERIMENTAL IETF rtg pim 10.17487/RFC6559 RFC6560 One-Time Password (OTP) Pre-Authentication G. Richards April 2012 ASCII HTML 43

The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One-Time Password (OTP) authentication. [STANDARDS-TRACK]

 draft-ietf-krb-wg-otp-preauth-21 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6560 RFC6561 Recommendations for the Remediation of Bots in ISP Networks J. Livingood N. Mody M. O'Reirdan March 2012 ASCII HTML 29 ISP Internet Service Provider Bot Botnet Remediation malware notification

This document contains recommendations on how Internet Service Providers can use various remediation techniques to manage the effects of malicious bot infestations on computers used by their subscribers. Internet users with infected computers are exposed to risks such as loss of personal data and increased susceptibility to online fraud. Such computers can also become inadvertent participants in or components of an online crime network, spam network, and/or phishing network as well as be used as a part of a distributed denial-of-service attack. Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular Internet Service Provider's network. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-oreirdan-mody-bot-remediation-20 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6561 10.17487/RFC6561 RFC6562 Guidelines for the Use of Variable Bit Rate Audio with Secure RTP C. Perkins JM. Valin March 2012 ASCII HTML 6 vbr

This memo discusses potential security issues that arise when using variable bit rate (VBR) audio with the secure RTP profile. Guidelines to mitigate these issues are suggested. [STANDARDS-TRACK]

 draft-ietf-avtcore-srtp-vbr-audio-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6562 RFC6563 Moving A6 to Historic Status S. Jiang D. Conrad B. Carpenter March 2012 ASCII HTML 8

This document provides a summary of issues related to the use of A6 records, discusses the current status, and moves RFC 2874 to Historic status, providing clarity to implementers and operators. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-jiang-a6-to-historic-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6563 RFC6564 A Uniform Format for IPv6 Extension Headers S. Krishnan J. Woodyatt E. Kline J. Hoagland M. Bhatia April 2012 ASCII HTML 6

In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport-layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6. It also provides a common format for defining any new IPv6 extension headers, if they are needed. [STANDARDS-TRACK]

 draft-ietf-6man-exthdr-06 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6564 10.17487/RFC6564 RFC6565 OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol P. Pillay-Esnault P. Moyer J. Doyle E. Ertekin M. Lundberg June 2012 ASCII HTML 20 L3VPN BGP/MPLS VPN

Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. Support currently exists for both IPv4 and IPv6 VPNs; however, only Open Shortest Path First version 2 (OSPFv2) as PE-CE protocol is specified. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. [STANDARDS-TRACK]

 draft-ietf-l3vpn-ospfv3-pece-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC6565 RFC6566 A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments Y. Lee Editor G. Bernstein Editor D. Li G. Martinelli March 2012 ASCII HTML 31

As an optical signal progresses along its path, it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks.

This document provides a framework for applying GMPLS protocols and the Path Computation Element (PCE) architecture to support Impairment-Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this document discusses key computing constraints, scenarios, and architectural processes: routing, wavelength assignment, and impairment validation. This document does not define optical data plane aspects; impairment parameters; or measurement of, or assessment and qualification of, a route; rather, it describes the architectural and information components for protocol solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ccamp-wson-impairments-10 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6566 RFC6567 Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP A. Johnston L. Liess April 2012 ASCII HTML 11

This document introduces the transport of call control User-to-User Information (UUI) using the Session Initiation Protocol (SIP) and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the Integrated Services Digital Network (ISDN) UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-cuss-sip-uui-reqs-09 INFORMATIONAL INFORMATIONAL IETF rai cuss 10.17487/RFC6567 RFC6568 Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) E. Kim D. Kaspar JP. Vasseur April 2012 ASCII HTML 28

This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). This document provides dimensions of design space for LoWPAN applications. A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN Working Group is provided with the characteristics of each dimension. A complete list of practical use cases is not the goal of this document. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-6lowpan-usecases-10 INFORMATIONAL INFORMATIONAL IETF int 6lowpan 10.17487/RFC6568 RFC6569 Guidelines for Development of an Audio Codec within the IETF JM. Valin S. Borilin K. Vos C. Montgomery R. Chen March 2012 ASCII HTML 14 audio codec speech codec

This document provides general guidelines for work on developing and specifying an interactive audio codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-codec-guidelines-08 INFORMATIONAL INFORMATIONAL IETF rai codec 10.17487/RFC6569 RFC6570 URI Template J. Gregorio R. Fielding M. Hadley M. Nottingham D. Orchard March 2012 ASCII HTML 34 template Uniform Resource Identifier URI URI Template Internationalized Resource Identifier IRI IRI Template

A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]

 draft-gregorio-uritemplate-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6570 10.17487/RFC6570 RFC6571 Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks C. Filsfils Editor P. Francois Editor M. Shand B. Decraene J. Uttaro N. Leymann M. Horneffer June 2012 ASCII HTML 35 IP Fast Reroute Routing Convergence Network Topology IS-IS OSPF

In this document, we analyze the applicability of the Loop-Free Alternate (LFA) method of providing IP fast reroute in both the core and access parts of Service Provider networks. We consider both the link and node failure cases, and provide guidance on the applicability of LFAs to different network topologies, with special emphasis on the access parts of the network. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-rtgwg-lfa-applicability-06 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg http://www.rfc-editor.org/errata_search.php?rfc=6571 10.17487/RFC6571 RFC6572 RADIUS Support for Proxy Mobile IPv6 F. Xia B. Sarikaya J. Korhonen Editor S. Gundavelli D. Damic June 2012 ASCII HTML 36

This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses RADIUS-based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization, and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the mobile node (MN) attaches, authenticates, and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the interactions related to mobility session setup, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. [STANDARDS-TRACK]

 draft-ietf-netext-radius-pmip6-08 RFC8044 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6572 RFC6573 The Item and Collection Link Relations M. Amundsen April 2012 ASCII HTML 5

RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-amundsen-item-and-collection-link-relations-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6573 RFC6574 Report from the Smart Object Workshop H. Tschofenig J. Arkko April 2012 ASCII HTML 32 Smart Objects Internet of Things

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on 'Interconnecting Smart Objects with the Internet'. The workshop took place in Prague on 25 March 2011. The main goal of the workshop was to solicit feedback from the wider community on their experience with deploying IETF protocols in constrained environments. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-smart-object-workshop-10 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6574 RFC6575 Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs H. Shah Editor E. Rosen Editor G. Heron Editor V. Kompella Editor June 2012 ASCII HTML 28

The Virtual Private Wire Service (VPWS), detailed in RFC 4664, provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge (PE) device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet or both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "Address Resolution Protocol (ARP) Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. [STANDARDS-TRACK]

 draft-ietf-l2vpn-arp-mediation-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC6575 RFC6576 IP Performance Metrics (IPPM) Standard Advancement Testing R. Geib Editor A. Morton R. Fardid A. Steinmitz March 2012 ASCII HTML 37 inter-operability equivalence measurement compliance metric

This document specifies tests to determine if multiple independent instantiations of a performance-metric RFC have implemented the specifications in the same way. This is the performance-metric equivalent of interoperability, required to advance RFCs along the Standards Track. Results from different implementations of metric RFCs will be collected under the same underlying network conditions and compared using statistical methods. The goal is an evaluation of the metric RFC itself to determine whether its definitions are clear and unambiguous to implementors and therefore a candidate for advancement on the IETF Standards Track. This document is an Internet Best Current Practice.

 draft-ietf-ippm-metrictest-05 BCP0176 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=6576 10.17487/RFC6576 RFC6577 Authentication-Results Registration Update for Sender Policy Framework (SPF) Results M. Kucherawy March 2012 ASCII HTML 5 SPF Authentication

This memo updates the registry of authentication method results in Authentication-Results: message header fields, correcting a discontinuity between the original registry creation and the Sender Policy Framework (SPF) specification. [STANDARDS-TRACK]

 draft-kucherawy-authres-spf-erratum-02 RFC7001 RFC5451 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6577 RFC6578 Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV) C. Daboo A. Quillaud March 2012 ASCII HTML 29 sync-collection sync-token

This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) that allows efficient synchronization of the contents of a WebDAV collection. [STANDARDS-TRACK]

 draft-daboo-webdav-sync-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6578 RFC6579 The 'disclosure' Link Relation Type M. Yevstifeyev March 2012 ASCII HTML 5

This document specifies the 'disclosure' link relation type. It designates a list of IPR disclosures made with respect to the material for which such a relation type is specified. [STANDARDS-TRACK]

 draft-yevstifeyev-disclosure-relation-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6579 RFC6580 IANA Registries for the Remote Direct Data Placement (RDDP) Protocols M. Ko D. Black April 2012 ASCII HTML 10

The original RFCs that specified the Remote Direct Data Placement (RDDP) protocol suite did not create IANA registries for RDDP error codes, operation codes, and function codes. Extensions to the RDDP protocols now require these registries to be created. This memo creates the RDDP registries, populates them with values defined in the original RDDP RFCs, and provides guidance to IANA for future assignment of code points within these registries. [STANDARDS-TRACK]

 draft-ietf-storm-rddp-registries-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm http://www.rfc-editor.org/errata_search.php?rfc=6580 10.17487/RFC6580 RFC6581 Enhanced Remote Direct Memory Access (RDMA) Connection Establishment A. Kanevsky Editor C. Bestler Editor R. Sharp S. Wise April 2012 ASCII HTML 25

This document updates RFC 5043 and RFC 5044 by extending Marker Protocol Data Unit (PDU) Aligned Framing (MPA) negotiation for Remote Direct Memory Access (RDMA) connection establishment. The first enhancement extends RFC 5044, enabling peer-to-peer connection establishment over MPA / Transmission Control Protocol (TCP). The second enhancement extends both RFC 5043 and RFC 5044, by providing an option for standardized exchange of RDMA-layer connection configuration. [STANDARDS-TRACK]

 draft-ietf-storm-mpa-peer-connect-09 RFC5043 RFC5044 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC6581 RFC6582 The NewReno Modification to TCP's Fast Recovery Algorithm T. Henderson S. Floyd A. Gurtov Y. Nishida April 2012 ASCII HTML 16 congestion avoidance congestion control fast retransmit

RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as "NewReno". This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782. [STANDARDS-TRACK]

 draft-ietf-tcpm-rfc3782-bis-05 RFC3782 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=6582 10.17487/RFC6582 RFC6583 Operational Neighbor Discovery Problems I. Gashinsky J. Jaeggli W. Kumari March 2012 ASCII HTML 12

In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted.

This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks. [STANDARDS-TRACK]

 draft-ietf-v6ops-v6nd-problems-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6583 RFC6584 Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols V. Roca April 2012 ASCII HTML 30 TESLA FLUTE

This document introduces four schemes that provide per-packet authentication, integrity, and anti-replay services in the context of the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) protocols. The first scheme is based on RSA Digital Signatures. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). The third scheme relies on a Group- keyed Message Authentication Code (MAC). Finally, the fourth scheme merges the Digital Signature and group schemes. These schemes have different target use cases, and they do not all provide the same service. [STANDARDS-TRACK]

 draft-ietf-rmt-simple-auth-for-alc-norm-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC6584 RFC6585 Additional HTTP Status Codes M. Nottingham R. Fielding April 2012 ASCII HTML 10 Hypertext Transfer Protocol

This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK]

 draft-nottingham-http-new-status-04 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6585 RFC6586 Experiences from an IPv6-Only Network J. Arkko A. Keranen April 2012 ASCII HTML 21 IPv6 NAT64

This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as roadblocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-arkko-ipv6-only-experience-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6586 RFC6587 Transmission of Syslog Messages over TCP R. Gerhards C. Lonvick April 2012 ASCII HTML 11 SYSLOG SYSLOG transport TCP

There have been many implementations and deployments of legacy syslog over TCP for many years. That protocol has evolved without being standardized and has proven to be quite interoperable in practice. This memo describes how TCP has been used as a transport for syslog messages. This document defines a Historic Document for the Internet community.

 draft-gerhards-syslog-plain-tcp-14 HISTORIC HISTORIC IETF NON WORKING GROUP 10.17487/RFC6587 RFC6588 A URN Namespace for ucode C. Ishikawa April 2012 ASCII HTML 8

This document describes a Uniform Resource Name (URN) namespace for ucode, an identifier system for objects and places. ucode technology is used in many applications, and this document provides a URN namespace for ucode to enable its use in Internet-related devices and software. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ishikawa-yrpunl-ucode-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6588 10.17487/RFC6588 RFC6589 Considerations for Transitioning Content to IPv6 J. Livingood April 2012 ASCII HTML 27

This document describes considerations for the transition of end-user content on the Internet to IPv6. While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6589 RFC6590 Redaction of Potentially Sensitive Data from Mail Abuse Reports J. Falk Editor M. Kucherawy Editor April 2012 ASCII HTML 8 ARF MARF feedback loop spam reporting

Email messages often contain information that might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. [STANDARDS-TRACK]

 draft-ietf-marf-redaction-08 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6590 RFC6591 Authentication Failure Reporting Using the Abuse Reporting Format H. Fontana April 2012 ASCII HTML 16 auth auth failure dkim spf AFRF ARF

This memo registers an extension report type for the Abuse Reporting Format (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. [STANDARDS-TRACK]

 draft-ietf-marf-authfailure-report-10 RFC6692 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6591 RFC6592 The Null Packet C. Pignataro April 1 2012 ASCII HTML 6

The ever-elusive Null Packet received numerous mentions in documents in the RFC series, but it has never been explicitly defined. This memo corrects that omission. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-pignataro-the-null-packet-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6592 RFC6593 Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS) C. Pignataro J. Clarke G. Salgueiro April 1 2012 ASCII HTML 8

With the ubiquitous success of service discovery techniques, curious clients are faced with an increasing overload of service instances and options listed when they browse for services. A typical domain may contain web servers, remote desktop servers, printers, file servers, video content servers, automatons, Points of Presence using artificial intelligence, etc., all advertising their presence. Unsurprisingly, it is expected that some protocols and services will choose the comfort of anonymity and avoid discovery.

This memo describes a new experimental protocol for this purpose utilizing the Domain Pseudonym System (DPS), and discusses strategies for its successful implementation and deployment. This document defines an Experimental Protocol for the Internet community.

 draft-joegonzalocarlos-service-hide-n-seek-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6593 RFC6594 Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records O. Sury April 2012 ASCII HTML 9 DNS Domain Name System SSHFP SHA-256 Secure Shell ECDSA

This document updates the IANA registries in RFC 4255, which defines SSHFP, a DNS Resource Record (RR) that contains a standard Secure Shell (SSH) key fingerprint used to verify SSH host keys using DNS Security Extensions (DNSSEC). This document defines additional options supporting SSH public keys applying the Elliptic Curve Digital Signature Algorithm (ECDSA) and the implementation of fingerprints computed using the SHA-256 message digest algorithm in SSHFP Resource Records. [STANDARDS-TRACK]

 draft-os-ietf-sshfp-ecdsa-sha2-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6594 10.17487/RFC6594 RFC6595 A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML) K. Wierenga E. Lear S. Josefsson April 2012 ASCII HTML 22 Generic Security Service Application Program Interface SAML 2.0

The Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. The Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. [STANDARDS-TRACK]

 draft-ietf-kitten-sasl-saml-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC6595 RFC6596 The Canonical Link Relation M. Ohye J. Kupke April 2012 ASCII HTML 8

RFC 5988 specifies a way to define relationships between links on the web. This document describes a new type of such a relationship, "canonical", to designate an Internationalized Resource Identifier (IRI) as preferred over resources with duplicative content. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ohye-canonical-link-relation-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6596 RFC6597 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data J. Downs Editor J. Arbeiter Editor April 2012 ASCII HTML 13 KLV

This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE ST 336, into the Real-time Transport Protocol (RTP). [STANDARDS-TRACK]

 draft-ietf-payload-rtp-klv-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6597 RFC6598 IANA-Reserved IPv4 Prefix for Shared Address Space J. Weil V. Kuarsingh C. Donley C. Liljenstolpe M. Azinger April 2012 ASCII HTML 11 shared block CGN NAT Carrier Grade NAT private address space service provider address translation non-globally routable non-overlapping address space

This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier- Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).

Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks. However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document.

This document details the allocation of an additional special-use IPv4 address block and updates RFC 5735. This memo documents an Internet Best Current Practice.

 draft-weil-shared-transition-space-request-15 RFC5735 BCP0153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6598 RFC6599 RFC6600 RFC6601 Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks G. Ash Editor D. McDysan April 2012 ASCII HTML 34

This document presents a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one motivational example, to reject Voice over IP (VoIP) calls when additional calls would adversely affect calls already in progress. Without MPLS GCAC, connections on congested links will suffer degraded quality. The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers. MPLS GCAC interoperates between vendor equipment and across multiple service provider domains. The MPLS GCAC algorithm uses available standard mechanisms for MPLS-based networks, such as RSVP, Diffserv-aware MPLS Traffic Engineering (DS-TE), Path Computation Element (PCE), Next Steps in Signaling (NSIS), Diffserv, and OSPF. The MPLS GCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms. MPLS GCAC functions are implemented in a distributed manner to deliver the objective Quality of Service (QoS) for specified QoS constraints. The objective is that the source is able to compute a source route with high likelihood that via-elements along the selected path will in fact admit the request. In some cases (e.g., multiple Autonomous Systems (ASes)), this objective cannot always be met, but this document summarizes methods that partially meet this objective. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic. This document defines an Experimental Protocol for the Internet community.

 draft-ash-gcac-algorithm-spec-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6601 RFC6602 Bulk Binding Update Support for Proxy Mobile IPv6 F. Abinader Editor S. Gundavelli Editor K. Leung S. Krishnan D. Premec May 2012 ASCII HTML 23 Proxy Mobile IPv6 PMIPv6 bulk registrations MN group ID

For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group-specific scope, this results in a significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group-specific scope with the use of a group identifier. [STANDARDS-TRACK]

 draft-ietf-netext-bulk-re-registration-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6602 RFC6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation J. Korhonen Editor T. Savolainen S. Krishnan O. Troan May 2012 ASCII HTML 10 OPTION_PD_EXCLUDE

This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6-based prefix delegation. The new mechanism updates RFC 3633. [STANDARDS-TRACK]

 draft-ietf-dhc-pd-exclude-04 RFC3633 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6603 10.17487/RFC6603 RFC6604 xNAME RCODE and Status Bits Clarification D. Eastlake 3rd April 2012 ASCII HTML 5 DNS DNSSEC CNAME DNAME Domain Name response code canonical name

The Domain Name System (DNS) has long provided means, such as the CNAME (Canonical Name), whereby a DNS query can be redirected to a different name. A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits. This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles. [STANDARDS-TRACK]

 draft-ietf-dnsext-xnamercode-00 RFC1035 RFC2308 RFC2672 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6604 RFC6605 Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC P. Hoffman W.C.A. Wijngaards April 2012 ASCII HTML 8 dnskey algorithm ds hash algo crypto DNS key DNSKEY algorithm DS digest hash cryptography SHA-384 ECDSAP256SHA256 ECDSAP384SHA384

This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. [STANDARDS-TRACK]

 draft-ietf-dnsext-ecdsa-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6605 RFC6606 Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing E. Kim D. Kaspar C. Gomez C. Bormann May 2012 ASCII HTML 32 WSN Sensor Network Wireless Sensor Network WSN for Wireless Sensor Network L3 Mesh for Layer 3 Mesh Network Routing Protocol Subnet Routing ieee 802.15.4 LLN Low Power radio 802.15.4 powerline ISA100.11a RFC 4944

IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.

This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETF ROLL WG. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-6lowpan-routing-requirements-10 INFORMATIONAL INFORMATIONAL IETF int 6lowpan 10.17487/RFC6606 RFC6607 Virtual Subnet Selection Options for DHCPv4 and DHCPv6 K. Kinnear R. Johnson M. Stapp April 2012 ASCII HTML 26 draft-ietf-dhc-vpn-option-15 RFC3046 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6607 RFC6608 Subcodes for BGP Finite State Machine Error J. Dong M. Chen A. Suryanarayana May 2012 ASCII HTML 5

This document defines several subcodes for the BGP Finite State Machine (FSM) Error that could provide more information to help network operators in diagnosing BGP FSM issues and correlating network events. This document updates RFC 4271. [STANDARDS-TRACK]

 draft-ietf-idr-fsm-subcode-03 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC6608 RFC6609 Sieve Email Filtering: Include Extension C. Daboo A. Stone May 2012 ASCII HTML 14

The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts. Users are able to include their own personal scripts or site-wide scripts. [STANDARDS-TRACK]

 draft-ietf-sieve-include-15 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6609 RFC6610 DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6) H. Jang A. Yegin K. Chowdhury J. Choi T. Lemon May 2012 ASCII HTML 16

This document defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined that allow a mobile node to request the home agent IP address, Fully Qualified Domain Name (FQDN), or home network prefix and obtain it via the DHCP response. [STANDARDS-TRACK]

 draft-ietf-mip6-hiopt-18 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC6610 RFC6611 Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario K. Chowdhury Editor A. Yegin May 2012 ASCII HTML 12

Mobile IPv6 bootstrapping can be categorized into two primary scenarios: the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. [STANDARDS-TRACK]

 draft-ietf-mip6-bootstrapping-integrated-dhc-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC6611 RFC6612 Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues G. Giaretta Editor May 2012 ASCII HTML 18

The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the same network requires some care. This document discusses scenarios where such mixed usage is appropriate and points out the need for interaction between the two mechanisms. Solutions and recommendations to enable these scenarios are also described. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-netlmm-mip-interactions-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6612 RFC6613 RADIUS over TCP A. DeKok May 2012 ASCII HTML 16 Remote Authentication Dial-In User Server Transmission Control Protocol RADIUS/TCP

The Remote Authentication Dial-In User Server (RADIUS) protocol has, until now, required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security (RADIUS/TLS). It permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-radext-tcp-transport-09 RFC7930 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC6613 RFC6614 Transport Layer Security (TLS) Encryption for RADIUS S. Winter M. McCauley S. Venaas K. Wierenga May 2012 ASCII HTML 22 RADIUS AAA Security Reliability Remote Authentication Dial-In User Server

This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. [STANDARDS-TRACK]

 draft-ietf-radext-radsec-12 RFC8996 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC6614 RFC6615 Definitions of Managed Objects for IP Flow Information Export T. Dietz Editor A. Kobayashi B. Claise G. Muenz June 2012 ASCII HTML 65 IPFIX MIB Filtering Sampling Selection

This document defines managed objects for IP Flow Information eXport (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors, including basic configuration information. [STANDARDS-TRACK]

 draft-ietf-ipfix-rfc5815bis-03 RFC5815 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC6615 RFC6616 A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID E. Lear H. Tschofenig H. Mauldin S. Josefsson May 2012 ASCII HTML 18 web single sign-on

OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. [STANDARDS-TRACK]

 draft-ietf-kitten-sasl-openid-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten http://www.rfc-editor.org/errata_search.php?rfc=6616 10.17487/RFC6616 RFC6617 Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE) D. Harkins June 2012 ASCII HTML 24 Authenticated Key Exchange Dictionary Attack

This memo describes a secure pre-shared key (PSK) authentication method for the Internet Key Exchange Protocol (IKE). It is resistant to dictionary attack and retains security even when used with weak pre-shared keys. This document defines an Experimental Protocol for the Internet community.

 draft-harkins-ipsecme-spsk-auth-08 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6617 RFC6618 Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent J. Korhonen Editor B. Patil H. Tschofenig D. Kroeselberg May 2012 ASCII HTML 38 Mobile IPv6 Security

Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent (HA) is secured using IPsec. The security association (SA) between an MN and the HA is established using Internet Key Exchange Protocol (IKE) version 1 or 2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the Mobile IPv6 protocol component and the IKE/IPsec module of the IP stack. This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer Security for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the MN and HA. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-mext-mip6-tls-05 EXPERIMENTAL EXPERIMENTAL IETF int mext 10.17487/RFC6618 RFC6619 Scalable Operation of Address Translators with Per-Interface Bindings J. Arkko L. Eggert M. Townsley June 2012 ASCII HTML 9 NAT IPv4 IPv6

This document explains how to employ address translation in networks that serve a large number of individual customers without requiring a correspondingly large amount of private IPv4 address space. [STANDARDS-TRACK]

 draft-arkko-dual-stack-extra-lite-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6619 RFC6620 FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses E. Nordmark M. Bagnulo E. Levy-Abegnoli May 2012 ASCII HTML 35 ingress filtering BCP38

This memo describes First-Come, First-Served Source Address Validation Improvement (FCFS SAVI), a mechanism that provides source address validation for IPv6 networks using the FCFS principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing. [STANDARDS-TRACK]

 draft-ietf-savi-fcfs-14 PROPOSED STANDARD PROPOSED STANDARD IETF int savi http://www.rfc-editor.org/errata_search.php?rfc=6620 10.17487/RFC6620 RFC6621 Simplified Multicast Forwarding J. Macker Editor May 2012 ASCII HTML 55 routing flooding optimized flooding CDS connected dominating set duplicate packet detection hash-based packet detection MPR MPR-CDS E-CDS edge mobility mobile ad hoc mesh network

This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade-off. It defines techniques for multicast duplicate packet detection (DPD), to be applied in the forwarding process, for both IPv4 and IPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding. Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicast MANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-manet-smf-14 EXPERIMENTAL EXPERIMENTAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=6621 10.17487/RFC6621 RFC6622 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) U. Herberg T. Clausen May 2012 ASCII HTML 21 packetbb NHDP OLSRv2 security integrity routing

This document describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. [STANDARDS-TRACK]

 draft-ietf-manet-packetbb-sec-09 RFC7182 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC6622 RFC6623 IANA Registry for MEDIACTRL Interactive Voice Response Control Package E. Burger May 2012 ASCII HTML 6

This document creates an IANA registry for the response codes for the MEDIACTRL Interactive Voice Response Control Package, as described in RFC 6231. [STANDARDS-TRACK]

 draft-ietf-mediactrl-6231-iana-00 RFC6231 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl 10.17487/RFC6623 RFC6624 Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling K. Kompella B. Kothari R. Cherukuri May 2012 ASCII HTML 26 BGP L2VPN discovery signaling pseudowire

Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional L2VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning methodology for all services. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-kompella-l2vpn-l2vpn-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6624 RFC6625 Wildcards in Multicast VPN Auto-Discovery Routes E. Rosen Editor Y. Rekhter Editor W. Hendrickx R. Qiu May 2012 ASCII HTML 17 mvpn

In Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network. The base specifications for MVPN define BGP multicast VPN "auto-discovery routes" and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto-discovery route can refer to multiple customer flows or even to all customer flows. [STANDARDS-TRACK]

 draft-ietf-l3vpn-mvpn-wildcards-02 RFC6514 RFC7582 RFC7900 RFC8534 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6625 10.17487/RFC6625 RFC6626 Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4) G. Tsirtsis V. Park V. Narayanan K. Leung May 2012 ASCII HTML 5 mobile router

The base Network Mobility for Mobile IPv4 (NEMOv4) specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism for NEMOv4. [STANDARDS-TRACK]

 draft-ietf-mip4-nemov4-dynamic-06 RFC5177 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC6626 RFC6627 Overview of Pre-Congestion Notification Encoding G. Karagiannis K. Chan T. Moncaster M. Menth P. Eardley B. Briscoe July 2012 ASCII HTML 20

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN-domain, the overall rate of PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets that allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious \%pre-congestion.

The PCN working group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of those approaches along with an explanation of the constraints that apply to any solution. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pcn-encoding-comparison-09 INFORMATIONAL INFORMATIONAL IETF tsv pcn 10.17487/RFC6627 RFC6628 Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2 S. Shin K. Kobara June 2012 ASCII HTML 20 PAKE augmented PAKE off-line dictionary attacks resistance to server compromise

This document describes an efficient augmented password-only authentication and key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary words that allows an attacker to perform exhaustive searches (i.e., off-line dictionary attacks). The AugPAKE protocol described here is secure against passive attacks, active attacks, and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). In addition, this document describes how the AugPAKE protocol is integrated into the Internet Key Exchange Protocol version 2 (IKEv2). This document defines an Experimental Protocol for the Internet community.

 draft-shin-augmented-pake-15 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6628 RFC6629 Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6) J. Abley M. Bagnulo A. Garcia-Martinez June 2012 ASCII HTML 28 Cryptographically Generated Address CGA Hash-Based Address HBA Fault tolerance

This document discusses some considerations on the applicability of the level 3 multihoming Shim protocol for IPv6 (Shim6) and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-garcia-shim6-applicability-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6629 RFC6630 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) Z. Cao H. Deng Q. Wu G. Zorn Editor June 2012 ASCII HTML 20 ERP AAK EAP Early-authentication

The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods.

The EAP Re-authentication Protocol (ERP) specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator.

Authenticated Anticipatory Keying (AAK) is a method by which cryptographic keying material may be established upon one or more Candidate Attachment Points (CAPs) prior to handover. AAK uses the AAA infrastructure for key transport.

This document specifies the extensions necessary to enable AAK support in ERP. [STANDARDS-TRACK]

 draft-ietf-hokey-erp-aak-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey 10.17487/RFC6630 RFC6631 Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2) D. Kuegler Y. Sheffer June 2012 ASCII HTML 26 pace password authenticated connection establishment

The Internet Key Exchange protocol version 2 (IKEv2) does not allow secure peer authentication when using short credential strings, i.e., passwords. Several proposals have been made to integrate password-authentication protocols into IKE. This document provides an adaptation of Password Authenticated Connection Establishment (PACE) to the setting of IKEv2 and demonstrates the advantages of this integration. This document defines an Experimental Protocol for the Internet community.

 draft-kuegler-ipsecme-pace-ikev2-10 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6631 RFC6632 An Overview of the IETF Network Management Standards M. Ersue Editor B. Claise June 2012 ASCII HTML 85 network management data model monitoring configuration alarm notification

This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF Standards Track network management protocols and data models. The document refers to other overview documents, where they exist and classifies the standards for easy orientation. The purpose of this document is, on the one hand, to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. This document does not cover Operations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) OAM, and pseudowire as well as the corresponding management models. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-opsawg-management-stds-07 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC6632 RFC6633 Deprecation of ICMP Source Quench Messages F. Gont May 2012 ASCII HTML 8 congestion control icmp attacks tcp tcp security udp dccp sctp

This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. [STANDARDS-TRACK]

 draft-ietf-tsvwg-source-quench-06 RFC0792 RFC1122 RFC1812 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6633 RFC6634 RFC6635 RFC Editor Model (Version 2) O. Kolkman Editor J. Halpern Editor IAB June 2012 ASCII HTML 21 RFC Series Editor Independenet Series Editor RSE ISE RSOC RFC Series Oversight Committee

The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administrative Oversight Committee (IAOC) and the RSOC. This document reflects the experience gained with "RFC Editor Model (Version 1)", documented in RFC 5620, and obsoletes that document. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-rfc-editor-model-v2-05 RFC5620 RFC8728 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6635 RFC6636 Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks H. Asaeda H. Liu Q. Wu May 2012 ASCII HTML 12 Mobility PMIPv6

The Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other. This document describes ways to achieve IGMPv3 and MLDv2 protocol optimization for mobility and aims to become a guideline for the tuning of IGMPv3/MLDv2 Queries, timers, and counter values. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-multimob-igmp-mld-tuning-06 INFORMATIONAL INFORMATIONAL IETF int multimob 10.17487/RFC6636 RFC6637 Elliptic Curve Cryptography (ECC) in OpenPGP A. Jivsov June 2012 ASCII HTML 15

This document defines an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology. The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension and these Elliptic Curves. [STANDARDS-TRACK]

 draft-jivsov-openpgp-ecc-14 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6637 10.17487/RFC6637 RFC6638 Scheduling Extensions to CalDAV C. Daboo B. Desruisseaux June 2012 ASCII HTML 78 calsify calsched calsch calendar calendaring webcal ical icalendar ischedule itip imip text/calendar http

This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. [STANDARDS-TRACK]

 draft-desruisseaux-caldav-sched-12 RFC4791 RFC5546 RFC7953 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6638 RFC6639 Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview D. King Editor M. Venkatesan Editor June 2012 ASCII HTML 29

A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.

The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks.

This document describes the MIB-based architecture for MPLS-TP, indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management, and identifies areas where additional MIB modules are required. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-mib-management-overview-08 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6639 10.17487/RFC6639 RFC6640 IETF Meeting Attendees' Frequently Asked (Travel) Questions W. George June 2012 ASCII HTML 13 Meetings

This document attempts to provide a list of the frequently asked questions (FAQs) posed by IETF meeting attendees regarding travel logistics and local information. It is intended to assist those who are willing to provide local information, so that if they wish to pre-populate answers to some or all of these questions either in the IETF wiki or a meeting-specific site, they have a reasonably complete list of ideas to draw from. It is not meant as a list of required information that the host or Secretariat needs to provide; it merely serves as a guideline. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-george-travel-faq-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6640 RFC6641 Using DNS SRV to Specify a Global File Namespace with NFS Version 4 C. Everhart W. Adamson J. Zhang June 2012 ASCII HTML 11 domainroot domain root file system

The NFS version 4 (NFSv4) protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file namespace. The DNS SRV Resource Record (RR) allows a simple way for an organization to publish the root of its file system namespace, even to clients that might not be intimately associated with such an organization. The DNS SRV RR can be used to join these organization-wide file namespaces together to allow construction of a global, uniform NFS file namespace. [STANDARDS-TRACK]

 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC6641 RFC6642 RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report Q. Wu Editor F. Xia R. Even June 2012 ASCII HTML 13 Feedback Suppression NACK Retransmission

In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP Third-Party Loss Report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated Session Description Protocol (SDP) signaling is also defined. [STANDARDS-TRACK]

 draft-ietf-avtcore-feedback-supression-rtp-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6642 RFC6643 Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules J. Schoenwaelder July 2012 ASCII HTML 36 SMIv2 YANG data modeling

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the Simple Network Management Protocol (SNMP). This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF. [STANDARDS-TRACK]

 draft-ietf-netmod-smi-yang-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6643 10.17487/RFC6643 RFC6644 Rebind Capability in DHCPv6 Reconfigure Messages D. Evans R. Droms S. Jiang July 2012 ASCII HTML 10 internet protocol parameters addresses

This document updates RFC 3315 (DHCPv6) to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message. It extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. [STANDARDS-TRACK]

 draft-ietf-dhc-dhcpv6-reconfigure-rebind-10 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6644 RFC6645 IP Flow Information Accounting and Export Benchmarking Methodology J. Novak July 2012 ASCII HTML 39 Performance Flow monitoring IPFIX Netflow

This document provides a methodology and framework for quantifying the performance impact of the monitoring of IP flows on a network device and the export of this information to a Collector. It identifies the rate at which the IP flows are created, expired, and successfully exported as a new performance metric in combination with traditional throughput. The metric is only applicable to the devices compliant with RFC 5470, "Architecture for IP Flow Information Export". The methodology quantifies the impact of the IP flow monitoring process on the network equipment. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-bmwg-ipflow-meth-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6645 RFC6646 DECoupled Application Data Enroute (DECADE) Problem Statement H. Song N. Zong Y. Yang R. Alimi July 2012 ASCII HTML 12 In-network storage P2P

Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they can be complex (e.g., P2P caches need to explicitly support individual P2P application protocols), and do not allow users to manage resource usage policies for content in the cache. This document discusses the introduction of in-network storage for P2P applications and shows the need for a standard protocol for accessing this storage. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-decade-problem-statement-06 INFORMATIONAL INFORMATIONAL IETF tsv decade 10.17487/RFC6646 RFC6647 Email Greylisting: An Applicability Statement for SMTP M. Kucherawy D. Crocker June 2012 ASCII HTML 17 Email Greylisting Spam

This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism.

Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. [STANDARDS-TRACK]

 draft-ietf-appsawg-greylisting-09 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC6647 RFC6648 Deprecating the "X-" Prefix and Similar Constructs in Application Protocols P. Saint-Andre D. Crocker M. Nottingham June 2012 ASCII HTML 13

Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols. This memo documents an Internet Best Current Practice.

 draft-ietf-appsawg-xdash-05 BCP0178 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg 10.17487/RFC6648 RFC6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos L. Hornquist Astrand T. Yu July 2012 ASCII HTML 7

The Kerberos 5 network authentication protocol, originally specified in RFC 1510, can use the Data Encryption Standard (DES) for encryption. Almost 30 years after first publishing DES, the National Institute of Standards and Technology (NIST) finally withdrew the standard in 2005, reflecting a long-established consensus that DES is insufficiently secure. By 2008, commercial hardware costing less than USD 15,000 could break DES keys in less than a day on average. DES is long past its sell-by date. Accordingly, this document updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate the use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos. Because RFC 1510 (obsoleted by RFC 4120) supports only DES, this document recommends the reclassification of RFC 1510 as Historic. This memo documents an Internet Best Current Practice.

 draft-ietf-krb-wg-des-die-die-die-04 RFC1510 RFC1964 RFC4120 RFC4121 RFC4757 BCP0179 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec krb-wg 10.17487/RFC6649 RFC6650 Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) J. Falk M. Kucherawy Editor June 2012 ASCII HTML 15 marf spam reporting

RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed. [STANDARDS-TRACK]

 draft-ietf-marf-as-16 RFC5965 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6650 RFC6651 Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting M. Kucherawy June 2012 ASCII HTML 18 authentication fraud phishing spoofing

This document presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. [STANDARDS-TRACK]

 draft-ietf-marf-dkim-reporting-16 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6651 RFC6652 Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format S. Kitterman June 2012 ASCII HTML 8 fraud phishing spoofing

This memo presents extensions to the Abuse Reporting Format (ARF) and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion.

This memo updates RFC 4408 by providing an IANA registry for SPF modifiers. [STANDARDS-TRACK]

 draft-ietf-marf-spf-reporting-11 RFC4408 PROPOSED STANDARD PROPOSED STANDARD IETF app marf http://www.rfc-editor.org/errata_search.php?rfc=6652 10.17487/RFC6652 RFC6653 DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks B. Sarikaya F. Xia T. Lemon July 2012 ASCII HTML 13

As interest in IPv6 deployment in cellular networks increases, several migration issues have been being raised; IPv6 prefix management is the issue addressed in this document. Based on the idea that DHCPv6 servers can manage prefixes, we use DHCPv6 Prefix Delegation to address such prefix management issues as an access router offloading delegation of prefixes and release tasks to a DHCPv6 server. The access router first requests a prefix for an incoming mobile node from the DHCPv6 server. The access router may next do stateless or stateful address allocation to the mobile node, e.g., with a Router Advertisement or using DHCP. We also describe prefix management using Authentication, Authorization, and Accounting (AAA) servers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-sarikaya-v6ops-prefix-delegation-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6653 RFC6654 Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd) T. Tsou C. Zhou T. Taylor Q. Chen July 2012 ASCII HTML 8 IPv6 transition

This document proposes an alternative IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) deployment model to that of RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd requires support by a device (the 6rd customer edge, or 6rd-CE) on the customer site, which must also be assigned an IPv4 address. The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned Gateway collocated with the operator's IPv4 network edge rather than from customer equipment, and hence is termed "Gateway-initiated 6rd" (GI 6rd). The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. The latter point means less pressure on IPv4 addresses in a high-growth environment. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-tsou-softwire-gwinit-6rd-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6654 RFC6655 AES-CCM Cipher Suites for Transport Layer Security (TLS) D. McGrew D. Bailey July 2012 ASCII HTML 8 Authentication Encryption Advanced Encryption Standard (AES)

This memo describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message Authentication Code (CBC-MAC) Mode (CCM) of operation within Transport Layer Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. [STANDARDS-TRACK]

 draft-mcgrew-tls-aes-ccm-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6655 10.17487/RFC6655 RFC6656 Description of Cisco Systems' Subnet Allocation Option for DHCPv4 R. Johnson K. Kinnear M. Stapp July 2012 ASCII HTML 24

This memo documents a DHCPv4 option that currently exists and was previously privately defined for the operation and usage of the Cisco Systems' Subnet Allocation Option for DHCPv4. The option is passed between the DHCPv4 Client and the DHCPv4 Server to request dynamic allocation of a subnet, give specifications of the subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any preexisting usages of option numbers in the range 128-223 should be documented and that the working group will try to officially assign those numbers to those options. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-dhc-subnet-alloc-13 INFORMATIONAL INFORMATIONAL IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6656 10.17487/RFC6656 RFC6657 Update to MIME regarding "charset" Parameter Handling in Textual Media Types A. Melnikov J. Reschke July 2012 ASCII HTML 6 MIME charset text

This document changes RFC 2046 rules regarding default "charset" parameter values for "text/*" media types to better align with common usage by existing clients and servers. [STANDARDS-TRACK]

 draft-ietf-appsawg-mime-default-charset-04 RFC2046 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC6657 RFC6658 Packet Pseudowire Encapsulation over an MPLS PSN S. Bryant Editor L. Martini G. Swallow A. Malis July 2012 ASCII HTML 15

This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. [STANDARDS-TRACK]

 draft-ietf-pwe3-packet-pw-04 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC6658 RFC6659 Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method A. Begen July 2012 ASCII HTML 12 IPTV FEC retransmission

The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and the RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate. This often precedes, but may also accompany, the multicast stream itself. When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner. However, when there are two or more multicast streams to be acquired from the same or different multicast RTP sessions, care should be taken to configure each RAMS session appropriately. This document provides example scenarios and discusses how the RAMS solution could be used in such scenarios. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-avtext-rams-scenarios-05 INFORMATIONAL INFORMATIONAL IETF rai avtext 10.17487/RFC6659 RFC6660 Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP) B. Briscoe T. Moncaster M. Menth July 2012 ASCII HTML 24 Quality of Service QoS Congestion Control Congestion Notification Tunnelling Encapsulation & Decapsulation Differentiated Services Integrated Services Signalling Protocol Flow Admission Control Flow Termination

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of PCN-traffic is metered on every link in the PCN- domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to Decision Points that then decide whether to admit or block new flow requests or to terminate some already admitted flows during serious pre-congestion.

This document specifies how PCN-marks are to be encoded into the IP header by reusing the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. The PCN wire protocol for non-IP protocol headers will need to be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for MPLS in an informational appendix. The encoding for IP provides for up to three different PCN marking states using a single Diffserv codepoint (DSCP): not-marked (NM), threshold-marked (ThM), and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC 5696. [STANDARDS-TRACK]

 draft-ietf-pcn-3-in-1-encoding-11 RFC5696 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pcn 10.17487/RFC6660 RFC6661 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation A. Charny F. Huang G. Karagiannis M. Menth T. Taylor Editor July 2012 ASCII HTML 33 PCN controlled load CL boundary node behavior

Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using three PCN marking states: not- marked, threshold-marked, and excess-traffic-marked. This behavior is known informally as the Controlled Load (CL) PCN-boundary-node behavior. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-pcn-cl-edge-behaviour-14 EXPERIMENTAL EXPERIMENTAL IETF tsv pcn 10.17487/RFC6661 RFC6662 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation A. Charny J. Zhang G. Karagiannis M. Menth T. Taylor Editor July 2012 ASCII HTML 31 PCN single marking SM edge node behavior

Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using two PCN marking states: not- marked and excess-traffic-marked. This behavior is known informally as the Single Marking (SM) PCN-boundary-node behavior. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-pcn-sm-edge-behaviour-12 EXPERIMENTAL EXPERIMENTAL IETF tsv pcn 10.17487/RFC6662 RFC6663 Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain G. Karagiannis T. Taylor K. Chan M. Menth P. Eardley July 2012 ASCII HTML 7

Pre-Congestion Notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN-domain: (1) PCN-feedback-information is carried from the PCN-egress-node to the Decision Point; (2) the Decision Point may ask the PCN-ingress-node to measure, and report back, the rate of sent PCN-traffic between that PCN-ingress-node and PCN-egress-node. The Decision Point may be either collocated with the PCN-ingress-node or a centralized node (in the first case, (2) is not required). The signaling requirements pertain in particular to two edge behaviors, Controlled Load (CL) and Single Marking (SM). This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pcn-signaling-requirements-08 INFORMATIONAL INFORMATIONAL IETF tsv pcn 10.17487/RFC6663 RFC6664 S/MIME Capabilities for Public Key Definitions J. Schaad July 2012 ASCII HTML 19 OCSP CMS

This document defines a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. "Online Certificate Status Protocol Algorithm Agility" (RFC 6277) details an example of where this is used. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pkix-pubkey-caps-07 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC6664 RFC6665 SIP-Specific Event Notification A.B. Roach July 2012 ASCII HTML 53 SUBSCRIBE NOTIFY state

This document describes an extension to the Session Initiation Protocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred.

Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification.

This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. [STANDARDS-TRACK]

 draft-ietf-sipcore-rfc3265bis-09 RFC3265 RFC3261 RFC4660 RFC7621 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6665 RFC6666 A Discard Prefix for IPv6 N. Hilliard D. Freedman August 2012 ASCII HTML 6 RTBH black hole

Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates the "IPv6 Special Purpose Address Registry" by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-ipv6-discard-prefix-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6666 RFC6667 LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements K. Raza S. Boutros C. Pignataro July 2012 ASCII HTML 8

The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when requesting, withdrawing, or releasing all label bindings for a given FEC Element type is desired. However, a Typed Wildcard FEC Element must be individually defined for each FEC Element type. This specification defines the Typed Wildcard FEC Elements for the Pseudowire Identifier (PWid) (0x80) and Generalized PWid (0x81) FEC Element types. [STANDARDS-TRACK]

 draft-ietf-pwe3-pw-typed-wc-fec-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6667 RFC6668 SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol D. Bider M. Baushke July 2012 ASCII HTML 5

This memo defines algorithm names and parameters for use in some of the SHA-2 family of secure hash algorithms for data integrity verification in the Secure Shell (SSH) protocol. It also updates RFC 4253 by specifying a new RECOMMENDED data integrity algorithm. [STANDARDS-TRACK]

 draft-dbider-sha2-mac-for-ssh-06 RFC4253 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6668 RFC6669 An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks N. Sprecher L. Fang July 2012 ASCII HTML 21

This document provides an overview of the Operations, Administration, and Maintenance (OAM) toolset for MPLS-based transport networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data plane) that are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels. This overview includes a brief recap of the MPLS Transport Profile (MPLS-TP) OAM requirements and functions and the generic mechanisms created in the MPLS data plane that allow the OAM packets to run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group documents), which are referenced by this document. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mpls-tp-oam-analysis-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6669 10.17487/RFC6669 RFC6670 The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) N. Sprecher KY. Hong July 2012 ASCII HTML 33

The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS technology for use in transport network deployments. The work on MPLS-TP has extended the MPLS technology with additional architectural elements and functions that can be used in any MPLS deployment. MPLS-TP is a set of functions and features selected from the extended MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks.

During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment.

One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address the requirements for MPLS-TP OAM, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-sprecher-mpls-tp-oam-considerations-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6670 RFC6671 Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM) M. Betts November 2012 ASCII HTML 5

This document assigns a Generic Associated Channel (G-ACh) Type for carrying ITU-T MPLS Transport Profile Operations, Administration, and Management (MPLS-TP OAM) messages in the MPLS Generic Associated Channel. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-betts-itu-oam-ach-code-point-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6671 RFC6672 DNAME Redirection in the DNS S. Rose W. Wijngaards June 2012 ASCII HTML 22

The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK]

 draft-ietf-dnsext-rfc2672bis-dname-26 RFC2672 RFC3363 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=6672 10.17487/RFC6672 RFC6673 Round-Trip Packet Loss Metrics A. Morton August 2012 ASCII HTML 14 IP IPPM

Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active Measurement Protocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no round-trip packet loss metric specified according to the RFC 2330 framework.

This memo adds round-trip loss to the set of IP Performance Metrics (IPPM). [STANDARDS-TRACK]

 draft-ietf-ippm-rt-loss-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC6673 RFC6674 Gateway-Initiated Dual-Stack Lite Deployment F. Brockners S. Gundavelli S. Speicher D. Ward July 2012 ASCII HTML 15 GI-DS-Lite Gateway Initiated Dual-Stack Lite Dual-Stack Lite IPv6 Transitioning IPv6 Migration

Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual- Stack Lite (DS-Lite) applicable to certain tunnel-based access architectures. GI-DS-Lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded Context Identifier that uniquely identifies the end-system to which the tunneled packets belong. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. [STANDARDS-TRACK]

 draft-ietf-softwire-gateway-init-ds-lite-08 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC6674 RFC6675 A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP E. Blanton M. Allman L. Wang I. Jarvinen M. Kojo Y. Nishida August 2012 ASCII HTML 15 transmission control protocol retransmission congestion control

This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. This document obsoletes RFC 3517 and describes changes from it. [STANDARDS-TRACK]

 draft-ietf-tcpm-3517bis-02 RFC3517 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6675 RFC6676 Multicast Addresses for Documentation S. Venaas R. Parekh G. Van de Velde T. Chown M. Eubanks August 2012 ASCII HTML 7

This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use. Some multicast addresses are derived from AS numbers or unicast addresses. This document also explains how these can be used for documentation purposes. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mboned-mcaddrdoc-04 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC6676 RFC6677 Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods S. Hartman Editor T. Clancy K. Hoeper July 2012 ASCII HTML 31

This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the "lying Network Access Service (NAS)" problem as well as the "lying provider" problem. [STANDARDS-TRACK]

 draft-ietf-emu-chbind-16 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu 10.17487/RFC6677 RFC6678 Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method K. Hoeper S. Hanna H. Zhou J. Salowey Editor July 2012 ASCII HTML 23

This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This tunnel method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication, and the transport of additional data for other purposes. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-emu-eaptunnel-req-09 INFORMATIONAL INFORMATIONAL IETF sec emu 10.17487/RFC6678 RFC6679 Explicit Congestion Notification (ECN) for RTP over UDP M. Westerlund I. Johansson C. Perkins P. O'Hanlon K. Carlberg August 2012 ASCII HTML 58 ECN RTP UDP Congestion Control VoIP IPTV Packet Loss

This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialisation method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined. [STANDARDS-TRACK]

 draft-ietf-avtcore-ecn-for-rtp-08 RFC8311 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore http://www.rfc-editor.org/errata_search.php?rfc=6679 10.17487/RFC6679 RFC6680 Generic Security Service Application Programming Interface (GSS-API) Naming Extensions N. Williams L. Johansson S. Hartman S. Josefsson August 2012 ASCII HTML 18

The Generic Security Service Application Programming Interface (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers.

 draft-ietf-kitten-gssapi-naming-exts-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten http://www.rfc-editor.org/errata_search.php?rfc=6680 10.17487/RFC6680 RFC6681 Raptor Forward Error Correction (FEC) Schemes for FECFRAME M. Watson T. Stockhammer M. Luby August 2012 ASCII HTML 22

This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of the FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined: two for the protection of arbitrary packet flows, two that are optimized for small source blocks, and two for the protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g., UDP) or using RTP. [STANDARDS-TRACK]

 draft-ietf-fecframe-raptor-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6681 RFC6682 RTP Payload Format for Raptor Forward Error Correction (FEC) M. Watson T. Stockhammer M. Luby August 2012 ASCII HTML 18

This document specifies an RTP payload format for the Forward Error Correction (FEC) repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework that supports the transport of repair data over both UDP and RTP. This document specifies the payload format that is required for the use of RTP to carry Raptor repair flows. [STANDARDS-TRACK]

 draft-ietf-fecframe-rtp-raptor-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6682 RFC6683 Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection A. Begen T. Stockhammer August 2012 ASCII HTML 11 DVB FEC AL-FEC IPTV parity codes Raptor codes

Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical specification defines an optional Application-Layer Forward Error Correction (AL-FEC) protocol to protect the streaming media transported using RTP. The DVB-IPTV AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers good protection against both bursty and random packet losses at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-fecframe-dvb-al-fec-04 INFORMATIONAL INFORMATIONAL IETF tsv fecframe 10.17487/RFC6683 RFC6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF) B. Trammell July 2012 ASCII HTML 12 mile incident handling

This document provides guidelines for extensions to the Incident Object Description Exchange Format (IODEF) described in RFC 5070 for exchange of incident management data, and it contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-mile-template-05 INFORMATIONAL INFORMATIONAL IETF sec mile 10.17487/RFC6684 RFC6685 Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry B. Trammell July 2012 ASCII HTML 3 mile xml schema

This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to Incident Object Description Exchange Format (IODEF). [STANDARDS-TRACK]

 draft-ietf-mile-iodef-xmlreg-01 RFC7970 RFC5070 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC6685 RFC6686 Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments M. Kucherawy July 2012 ASCII HTML 12 SPF Sender ID authentication authorization email

In 2006, the IETF published a suite of protocol documents comprising the Sender Policy Framework (SPF) and Sender ID: two proposed email authentication protocols. Both of these protocols enable one to publish, via the Domain Name System, a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery.

The IESG required all of these documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) to be published as Experimental RFCs and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward.

After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-spfbis-experiment-11 INFORMATIONAL INFORMATIONAL IETF app spfbis http://www.rfc-editor.org/errata_search.php?rfc=6686 10.17487/RFC6686 RFC6687 Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) J. Tripathi Editor J. de Oliveira Editor JP. Vasseur Editor October 2012 ASCII PDF HTML 26 ROLL

This document presents a performance evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) for a small outdoor deployment of sensor nodes and for a large-scale smart meter network. Detailed simulations are carried out to produce several routing performance metrics using these real-life deployment scenarios. Please refer to the PDF version of this document, which includes several plots for the performance metrics not shown in the plain-text version. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-tripathi-roll-rpl-simulation-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6687 10.17487/RFC6687 RFC6688 Parallel NFS (pNFS) Block Disk Protection D. Black Editor J. Glasgow S. Faibish July 2012 ASCII HTML 6 NFS NFSv4 pNFS SAN GPT

Parallel NFS (pNFS) extends the Network File System version 4 (NFSv4) to enable direct client access to file data on storage devices and bypass the NFSv4 server. This can increase both performance and parallelism, but it requires additional client functionality, some of which depends upon the type of storage used. The pNFS specification for block storage (RFC 5663) describes how clients can identify the volumes used for pNFS, but this mechanism requires communication with the NFSv4 server. This document updates RFC 5663 to add a mechanism that enables identification of block storage devices used by pNFS file systems without communicating with the server. This enables clients to control access to pNFS block devices when the client initially boots, as opposed to waiting until the client can communicate with the NFSv4 server. [STANDARDS-TRACK]

 draft-ietf-nfsv4-pnfs-block-disk-protection-03 RFC5663 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC6688 RFC6689 Usage of the RSVP ASSOCIATION Object L. Berger July 2012 ASCII HTML 11 Resource Reservation Protocol

The Resource Reservation Protocol (RSVP) ASSOCIATION object is defined in the context of GMPLS-controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This document reviews how the association is to be provided in the context of GMPLS recovery. No new procedures or mechanisms are defined by this document, and it is strictly informative in nature. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ccamp-assoc-info-03 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6689 RFC6690 Constrained RESTful Environments (CoRE) Link Format Z. Shelby August 2012 ASCII HTML 22 CoRE Link Format HTTP Link Header Format Resource Discovery

This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]

 draft-ietf-core-link-format-14 PROPOSED STANDARD PROPOSED STANDARD IETF app core http://www.rfc-editor.org/errata_search.php?rfc=6690 10.17487/RFC6690 RFC6691 TCP Options and Maximum Segment Size (MSS) D. Borman July 2012 ASCII HTML 9

This memo discusses what value to use with the TCP Maximum Segment Size (MSS) option, and updates RFC 879 and RFC 2385. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-tcpm-tcpmss-05 RFC9293 RFC0879 RFC2385 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC6691 RFC6692 Source Ports in Abuse Reporting Format (ARF) Reports R. Clayton M. Kucherawy July 2012 ASCII HTML 5 ARF ports reporting feedback

This document defines an additional header field for use in Abuse Reporting Format (ARF) reports to permit the identification of the source port of the connection involved in an abuse incident.

This document updates RFC 6591. [STANDARDS-TRACK]

 draft-kucherawy-marf-source-ports-05 RFC6591 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6692 RFC6693 Probabilistic Routing Protocol for Intermittently Connected Networks A. Lindgren A. Doria E. Davies S. Grasic August 2012 ASCII HTML 113 DTN Routing PRoPHET

This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.

This document defines PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. PRoPHET is a variant of the epidemic routing protocol for intermittently connected networks that operates by pruning the epidemic distribution tree to minimize resource usage while still attempting to achieve the \%best-case routing capabilities of epidemic routing. It is intended for use in sparse mesh networks where there is no guarantee that a fully connected path between the source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as delay and disruption tolerant). The document presents an architectural overview followed by the protocol specification. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-dtnrg-prophet-10 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6693 RFC6694 The "about" URI Scheme S. Moonesamy Editor August 2012 ASCII HTML 7

This document describes the "about" URI scheme, which is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-appsawg-about-uri-scheme-07 INFORMATIONAL INFORMATIONAL IETF app appsawg 10.17487/RFC6694 RFC6695 Methods to Convey Forward Error Correction (FEC) Framework Configuration Information R. Asati August 2012 ASCII HTML 15

The Forward Error Correction (FEC) Framework document (RFC 6363) defines the FEC Framework Configuration Information necessary for the FEC Framework operation. This document describes how to use signaling protocols such as the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real Time Streaming Protocol (RTSP), etc. for determining and communicating the configuration information between sender(s) and receiver(s).

This document doesn't define any new signaling protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-fecframe-config-signaling-09 INFORMATIONAL INFORMATIONAL IETF tsv fecframe 10.17487/RFC6695 RFC6696 EAP Extensions for the EAP Re-authentication Protocol (ERP) Z. Cao B. He Y. Shi Q. Wu Editor G. Zorn Editor July 2012 ASCII HTML 47 EAP keying EMSK inter-authenticator roaming

The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to avoid repeating the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re- authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. [STANDARDS-TRACK]

 draft-ietf-hokey-rfc5296bis-07 RFC5296 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey 10.17487/RFC6696 RFC6697 Handover Keying (HOKEY) Architecture Design G. Zorn Editor Q. Wu T. Taylor Y. Nir K. Hoeper S. Decugis July 2012 ASCII HTML 20 Handover Keying Architecture Re-authentication Early authentication

The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A basic assumption is that the mobile host or "peer" is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748.

This document defines the HOKEY architecture. Specifically, it describes design objectives, the functional environment within which handover keying operates, the functions to be performed by the HOKEY architecture itself, and the assignment of those functions to architectural components. It goes on to illustrate the operation of the architecture within various deployment scenarios that are described more fully in other documents produced by the HOKEY Working Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-hokey-arch-design-11 INFORMATIONAL INFORMATIONAL IETF sec hokey 10.17487/RFC6697 RFC6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA P. Hoffman J. Schlyter August 2012 ASCII HTML 37 DNSSEC certificates public keys PKI

Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]

 draft-ietf-dane-protocol-23 RFC7218 RFC7671 RFC8749 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane http://www.rfc-editor.org/errata_search.php?rfc=6698 10.17487/RFC6698 RFC6699 RFC6700 RFC6701 Sanctions Available for Application to Violators of IETF IPR Policy A. Farrel P. Resnick August 2012 ASCII HTML 12

The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to Intellectual Property Rights (IPR) about which they might reasonably be aware.

The IETF takes conformance to these IPR policies very seriously. However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied.

This document discusses these issues and provides a suite of potential actions that can be taken within the IETF community in cases related to patents. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-farrresnickel-ipr-sanctions-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6701 RFC6702 Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules T. Polk P. Saint-Andre August 2012 ASCII HTML 16

The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-polk-ipr-disclosure-05 RFC8717 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6702 RFC6703 Reporting IP Network Performance Metrics: Different Points of View A. Morton G. Ramachandran G. Maguluri August 2012 ASCII HTML 27 Loss Delay Delay Variation Capacity TCP

Consumers of IP network performance metrics have many different uses in mind. This memo provides "long-term" reporting considerations (e.g., hours, days, weeks, or months, as opposed to 10 seconds), based on analysis of the points of view of two key audiences. It describes how these audience categories affect the selection of metric parameters and options when seeking information that serves their needs. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ippm-reporting-metrics-09 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6703 RFC6704 Forcerenew Nonce Authentication D. Miles W. Dec J. Bristow R. Maglione August 2012 ASCII HTML 12 DHCP

Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In the Forcerenew Nonce Authentication protocol, the server sends a nonce to the client in the initial DHCP ACK that is used for subsequent validation of a FORCERENEW message. This document updates RFC 3203. [STANDARDS-TRACK]

 draft-ietf-dhc-forcerenew-nonce-07 RFC3203 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6704 10.17487/RFC6704 RFC6705 Localized Routing for Proxy Mobile IPv6 S. Krishnan R. Koodli P. Loureiro Q. Wu A. Dutta September 2012 ASCII HTML 20 PMIPv6

Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs) attached to the same or different Mobile Access Gateways (MAGs) to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization, and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism. [STANDARDS-TRACK]

 draft-ietf-netext-pmip-lr-10 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6705 RFC6706 Asymmetric Extended Route Optimization (AERO) F. Templin Editor August 2012 ASCII HTML 33 route optimize optimization redirect redirection protocol routing link multi-access IPv6

Nodes attached to common multi-access link types (e.g., multicast- capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection. Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination. This redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios. This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues. This document defines an Experimental Protocol for the Internet community.

 draft-templin-aero-12 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6706 10.17487/RFC6706 RFC6707 Content Distribution Network Interconnection (CDNI) Problem Statement B. Niven-Jenkins F. Le Faucheur N. Bitar September 2012 ASCII HTML 32 Delivery CDN

Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection.

The goal of this document is to outline the problem area of CDN Interconnection for the IETF CDNI (CDN Interconnection) working group. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-cdni-problem-statement-08 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC6707 RFC6708 Application-Layer Traffic Optimization (ALTO) Requirements S. Kiesel Editor S. Previdi M. Stiemerling R. Woundy Y. Yang September 2012 ASCII HTML 20

Many Internet applications are used to access resources, such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance or Quality of Experience in the application while reducing the utilization of the underlying network infrastructure.

This document enumerates requirements for specifying, assessing, or comparing protocols and implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-alto-reqs-16 INFORMATIONAL INFORMATIONAL IETF tsv alto 10.17487/RFC6708 RFC6709 Design Considerations for Protocol Extensions B. Carpenter B. Aboba Editor S. Cheshire September 2012 ASCII HTML 42

This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-extension-recs-17 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6709 RFC6710 Simple Mail Transfer Protocol Extension for Message Transfer Priorities A. Melnikov K. Carlberg August 2012 ASCII HTML 28 SMTP priority MMHS

This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service whereby messages are given a label to indicate preferential handling, to enable mail handling nodes to take this information into account for onward processing. [STANDARDS-TRACK]

 draft-melnikov-smtp-priority-21 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6710 10.17487/RFC6710 RFC6711 An IANA Registry for Level of Assurance (LoA) Profiles L. Johansson August 2012 ASCII HTML 7 Identity Assurance

This document establishes an IANA registry for Level of Assurance (LoA) Profiles. The registry is intended to be used as an aid to discovering such LoA definitions in protocols that use an LoA concept, including Security Assertion Markup Language (SAML) 2.0 and OpenID Connect. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-johansson-loa-registry-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6711 RFC6712 Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) T. Kause M. Peylo September 2012 ASCII HTML 10 CMPtrans

This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It is the "CMPtrans" document referenced in RFC 4210; therefore, this document updates the reference given therein. [STANDARDS-TRACK]

 draft-ietf-pkix-cmp-transport-protocols-20 RFC4210 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6712 RFC6713 The 'application/zlib' and 'application/gzip' Media Types J. Levine August 2012 ASCII HTML 4 compress deflate stream compression

This document defines the 'application/gzip' and 'application/zlib' media types for compressed data using the gzip and zlib compression formats. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-levine-application-gzip-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6713 RFC6714 Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP) C. Holmberg S. Blau E. Burger August 2012 ASCII HTML 22 Middlebox IBCF SBC

This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of this extension is OPTIONAL. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed. This document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. [STANDARDS-TRACK]

 draft-ietf-simple-msrp-cema-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC6714 RFC6715 vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group D. Cauchie B. Leiba K. Li August 2012 ASCII HTML 11 expertise hobby interest

This document defines extensions to the vCard data format for representing and exchanging certain contact information. The properties covered here have been defined by the Open Mobile Alliance (OMA) Converged Address Book group, in order to synchronize, using OMA Data Synchronization, contact fields that were not already defined in the base vCard 4.0 specification. [STANDARDS-TRACK]

 draft-ietf-vcarddav-oma-cab-extensions-03 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6715 10.17487/RFC6715 RFC6716 Definition of the Opus Audio Codec JM. Valin K. Vos T. Terriberry September 2012 ASCII HTML 326 voice music lossy compression VOIP

This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK]

 draft-ietf-codec-opus-16 RFC8251 PROPOSED STANDARD PROPOSED STANDARD IETF rai codec http://www.rfc-editor.org/errata_search.php?rfc=6716 10.17487/RFC6716 RFC6717 kx509 Kerberized Certificate Issuance Protocol in Use in 2012 H. Hotz R. Allbery August 2012 ASCII HTML 13 Kerberos X.509 kx509 KCA kca-service kca_service

This document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists, then the overhead of using kx509 may be much less.

While not standardized, this protocol is already in use at several large organizations, and certificates issued with this protocol are recognized by the International Grid Trust Federation. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-hotz-kx509-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6717 RFC6718 Pseudowire Redundancy P. Muley M. Aissaoui M. Bocci August 2012 ASCII HTML 18 Active standby protection dual-homing vpls vpws

This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment PW applications or between terminating PE (T-PE) nodes in multi-segment PW applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundant set. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pwe3-redundancy-09 INFORMATIONAL INFORMATIONAL IETF rtg pwe3 10.17487/RFC6718 RFC6719 The Minimum Rank with Hysteresis Objective Function O. Gnawali P. Levis September 2012 ASCII HTML 13 Routing Protocol for Low Power and Lossy Networks RPL Low Power and Lossy Networks LLN

The Routing Protocol for Low-Power and Lossy Networks (RPL) constructs routes by using Objective Functions that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank with Hysteresis Objective Function (MRHOF), an Objective Function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with additive metrics along a route, and the metrics it uses are determined by the metrics that the RPL Destination Information Object (DIO) messages advertise. [STANDARDS-TRACK]

 draft-ietf-roll-minrank-hysteresis-of-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=6719 10.17487/RFC6719 RFC6720 The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) C. Pignataro R. Asati August 2012 ASCII HTML 8 GTSM LDP

The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router\'s IP control plane from CPU utilization-based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for the Label Distribution Protocol (LDP).

This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. [STANDARDS-TRACK]

 draft-ietf-mpls-ldp-gtsm-09 RFC5036 RFC7552 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6720 RFC6721 The Atom "deleted-entry" Element J. Snell September 2012 ASCII HTML 10 Atom Feed Entry Documents

This specification adds mechanisms to the Atom Syndication Format that publishers of Atom Feed and Entry documents can use to explicitly identify Atom entries that have been removed. [STANDARDS-TRACK]

 draft-snell-atompub-tombstones-18 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6721 RFC6722 Publishing the "Tao of the IETF" as a Web Page P. Hoffman Editor August 2012 ASCII HTML 3

This document describes how the "Tao of the IETF", which has been published as a series of RFCs in the past, is instead being published as a web page. It also contains the procedure for publishing and editing that web page. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-hoffman-tao-as-web-page-04 RFC4677 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6722 RFC6723 Update of the Pseudowire Control-Word Negotiation Mechanism L. Jin Editor R. Key Editor S. Delord T. Nadeau S. Boutros September 2012 ASCII HTML 9 control word control word negotiation control word renegotiation control word negotiation mechanism control word renegotiation mechanism

The control-word negotiation mechanism specified in RFC 4447 has a problem when a PE (Provider Edge) changes the preference for the use of the control word from NOT PREFERRED to PREFERRED. This document updates RFC 4447 and RFC 6073 by adding the Label Request message to resolve this control-word negotiation issue for single-segment and multi-segment pseudowires. [STANDARDS-TRACK]

 draft-ietf-pwe3-cbit-negotiation-05 RFC8077 RFC4447 RFC6073 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6723 RFC6724 Default Address Selection for Internet Protocol Version 6 (IPv6) D. Thaler Editor R. Draves A. Matsumoto T. Chown September 2012 ASCII HTML 32 source destination sort sorting

This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa.

Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK]

 draft-ietf-6man-rfc3484bis-06 RFC3484 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6724 10.17487/RFC6724 RFC6725 DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates S. Rose August 2012 ASCII HTML 5

The DNS Security Extensions (DNSSEC) require the use of cryptographic algorithm suites for generating digital signatures over DNS data. The algorithms specified for use with DNSSEC are reflected in an IANA-maintained registry. This document presents a set of changes for some entries of the registry. [STANDARDS-TRACK]

 draft-ietf-dnsext-dnssec-registry-update-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6725 RFC6726 FLUTE - File Delivery over Unidirectional Transport T. Paila R. Walsh M. Luby V. Roca R. Lehtonen November 2012 ASCII HTML 46 Multicast

This document defines File Delivery over Unidirectional Transport (FLUTE), a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC 3926. [STANDARDS-TRACK]

 draft-ietf-rmt-flute-revised-16 RFC3926 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=6726 10.17487/RFC6726 RFC6727 Definitions of Managed Objects for Packet Sampling T. Dietz Editor B. Claise J. Quittek October 2012 ASCII HTML 28 PSAMP IPFIX MIB Sampling Filtering Selection

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the IPFIX-SELECTOR-MIB module. For IP Flow Information eXport (IPFIX) implementations that use Packet Sampling (PSAMP) techniques, this memo defines the PSAMP- MIB module containing managed objects for providing information on applied packet selection functions and their parameters. [STANDARDS-TRACK]

 draft-ietf-ipfix-psamp-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC6727 RFC6728 Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols G. Muenz B. Claise P. Aitken October 2012 ASCII HTML 129

This document specifies a data model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) protocols. It is for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-compliant Monitoring Devices using the Network Configuration Protocol (NETCONF). The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG. The configuration data is encoded in Extensible Markup Language (XML). [STANDARDS-TRACK]

 draft-ietf-ipfix-configuration-model-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6728 10.17487/RFC6728 RFC6729 Indicating Email Handling States in Trace Fields D. Crocker M. Kucherawy September 2012 ASCII HTML 12 Quarantine Moderation

This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queuing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. [STANDARDS-TRACK]

 draft-ietf-appsawg-received-state-04 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6729 10.17487/RFC6729 RFC6730 Requirements for IETF Nominations Committee Tools S. Krishnan J. Halpern September 2012 ASCII HTML 10

This document defines the requirements for a set of tools for use by the IETF Nominations Committee. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-krishnan-nomcom-tools-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6730 RFC6731 Improved Recursive DNS Server Selection for Multi-Interfaced Nodes T. Savolainen J. Kato T. Lemon December 2012 ASCII HTML 29 DNS RDNSS interface FQDN selection

A multi-interfaced node is connected to multiple networks, some of which might be utilizing private DNS namespaces. A node commonly receives recursive DNS server configuration information from all connected networks. Some of the recursive DNS servers might have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the recursive DNS servers to use. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed recursive DNS server selection decisions. [STANDARDS-TRACK]

 draft-ietf-mif-dns-server-selection-12 PROPOSED STANDARD PROPOSED STANDARD IETF int mif 10.17487/RFC6731 RFC6732 6to4 Provider Managed Tunnels V. Kuarsingh Editor Y. Lee O. Vautrin September 2012 ASCII HTML 12 6to4-PMT

6to4 Provider Managed Tunnels (6to4-PMT) provide a framework that can help manage 6to4 tunnels operating in an anycast configuration. The 6to4-PMT framework is intended to serve as an option for operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation. 6to4-PMT supplies a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 Prefix Translation. This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non-RFC1918 address, thus breaking the return path for anycast-based 6to4 operation. 6to4-PMT has been successfully used in a production network, implemented as open source code, and implemented by a major routing vendor. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-07 RFC7526 HISTORIC INFORMATIONAL INDEPENDENT 10.17487/RFC6732 RFC6733 Diameter Base Protocol V. Fajardo Editor J. Arkko J. Loughney G. Zorn Editor October 2012 ASCII HTML 152 Diameter AAA

The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. [STANDARDS-TRACK]

 draft-ietf-dime-rfc3588bis-33 RFC3588 RFC5719 RFC7075 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=6733 10.17487/RFC6733 RFC6734 Diameter Attribute-Value Pairs for Cryptographic Key Transport G. Zorn Q. Wu V. Cakulev October 2012 ASCII HTML 7 AAA,ERP,MSK

Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. [STANDARDS-TRACK]

 draft-ietf-dime-local-keytran-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6734 RFC6735 Diameter Priority Attribute-Value Pairs K. Carlberg Editor T. Taylor October 2012 ASCII HTML 10 AVP

This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the Authentication, Authorization, and Accounting (AAA) framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. [STANDARDS-TRACK]

 draft-ietf-dime-priority-avps-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=6735 10.17487/RFC6735 RFC6736 Diameter Network Address and Port Translation Control Application F. Brockners S. Bhandari V. Singh V. Fajardo October 2012 ASCII HTML 58 NAT control NAT44 NAT66 CGN BNG

This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per-endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4 address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device -- expanding the existing Diameter-based Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a Network Address Translator and Network Address and Port Translator control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. [STANDARDS-TRACK]

 draft-ietf-dime-nat-control-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6736 RFC6737 The Diameter Capabilities Update Application K. Jiao G. Zorn October 2012 ASCII HTML 6

This document defines a new Diameter application and associated Command Codes. The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. [STANDARDS-TRACK]

 draft-ietf-dime-capablities-update-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6737 RFC6738 Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers V. Cakulev A. Lior S. Mizikovsky October 2012 ASCII HTML 17 Internet Key Exchange Protocol version 2

The Internet Key Exchange Protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec Security Associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and Shared Key (SK).

Diameter interworking for Mobile IPv6 between the Home Agent (HA), as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for SK-based authentication available with IKEv2. This document specifies the IKEv2-server-to-Diameter-server communication when the IKEv2 peer authenticates using IKEv2 with SK. [STANDARDS-TRACK]

 draft-ietf-dime-ikev2-psk-diameter-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6738 RFC6739 Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol H. Schulzrinne H. Tschofenig October 2012 ASCII HTML 25 Location

The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services.

The <mapping> element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service.

This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative <mapping> elements between two entities. Exchanging cached <mapping> elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the <mapping> element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-ecrit-lost-sync-18 RFC8996 EXPERIMENTAL EXPERIMENTAL IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=6739 10.17487/RFC6739 RFC6740 Identifier-Locator Network Protocol (ILNP) Architectural Description RJ Atkinson SN Bhatti November 2012 ASCII HTML 53

This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-arch-06 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6740 10.17487/RFC6740 RFC6741 Identifier-Locator Network Protocol (ILNP) Engineering Considerations RJ Atkinson SN Bhatti November 2012 ASCII HTML 38

This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-eng-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6741 RFC6742 DNS Resource Records for the Identifier-Locator Network Protocol (ILNP) RJ Atkinson SN Bhatti S. Rose November 2012 ASCII HTML 20

This note describes additional optional resource records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-dns-06 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6742 10.17487/RFC6742 RFC6743 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) RJ Atkinson SN Bhatti November 2012 ASCII HTML 12

This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-icmpv6-06 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6743 10.17487/RFC6743 RFC6744 IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) RJ Atkinson SN Bhatti November 2012 ASCII HTML 14

The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations. This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-noncev6-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6744 RFC6745 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) RJ Atkinson SN Bhatti November 2012 ASCII HTML 12

This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP). ILNP is an experimental, evolutionary enhancement to IP. The ICMP message defined herein is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-icmpv4-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6745 RFC6746 IPv4 Options for the Identifier-Locator Network Protocol (ILNP) RJ Atkinson SN Bhatti November 2012 ASCII HTML 11

This document defines two new IPv4 Options that are used only with the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-v4opts-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6746 RFC6747 Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) RJ Atkinson SN Bhatti November 2012 ASCII HTML 12

This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-arp-07 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6747 RFC6748 Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP) RJ Atkinson SN Bhatti November 2012 ASCII HTML 37

This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems. This document defines an Experimental Protocol for the Internet community.

 draft-irtf-rrg-ilnp-adv-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6748 RFC6749 The OAuth 2.0 Authorization Framework D. Hardt Editor October 2012 ASCII HTML 76 Client Resource Owner Authorization Server Resource Server Token Endpoint Authorization Endpoint Authorization Request Authorization Grant Protected Resource Access Token Refresh Token Authorization Code Implicit Grant Client Identifier Access Token Scope Delegation

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]

 draft-ietf-oauth-v2-31 RFC5849 RFC8252 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=6749 10.17487/RFC6749 RFC6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage M. Jones D. Hardt October 2012 ASCII HTML 18 Client Resource Owner Authorization Server Resource Server, Token Endpoint Authorization Endpoint Authorization Request, Authorization Grant Protected Resource Access Token Refresh Token Authorization Code Implicit Grant Client Identifier, Access Token Scope Bearer Authorization Header Bearer Access Token Type

This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]

 draft-ietf-oauth-v2-bearer-23 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=6750 10.17487/RFC6750 RFC6751 Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44) R. Despres Editor B. Carpenter D. Wing S. Jiang October 2012 ASCII HTML 33 Coexistence Transition Interworking Tunneling Encapsulation Mapping map-and-encap Global Addressing

In customer sites having IPv4-only Customer Premises Equipment (CPE), Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity. However, because it is designed to work without the involvement of Internet Service Providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being based on ISP cooperation, avoids these limitations. At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs (an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)). The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used. This document defines an Experimental Protocol for the Internet community.

 draft-despres-6a44-02 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6751 10.17487/RFC6751 RFC6752 Issues with Private IP Addressing in the Internet A. Kirkham September 2012 ASCII HTML 14

The purpose of this document is to provide a discussion of the potential problems of using private, RFC 1918, or non-globally routable addressing within the core of a Service Provider (SP) network. The discussion focuses on link addresses and, to a small extent, loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-grow-private-ip-sp-cores-07 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6752 RFC6753 A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD) J. Winterbottom H. Tschofenig H. Schulzrinne M. Thomson October 2012 ASCII HTML 25 HELD Dereference lbyr HTTP Location GEOPRIV

This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target. [STANDARDS-TRACK]

 draft-ietf-geopriv-deref-protocol-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6753 RFC6754 Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect Y. Cai L. Wei H. Ou V. Arya S. Jethwani October 2012 ASCII HTML 12

A Protocol Independent Multicast (PIM) router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state. When there are equal cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics. [STANDARDS-TRACK]

 draft-ietf-pim-ecmp-05 RFC8736 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6754 RFC6755 An IETF URN Sub-Namespace for OAuth B. Campbell H. Tschofenig October 2012 ASCII HTML 5 OAuth URN sub-namespace urn:ietf:params:oauth

This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-oauth-urn-sub-ns-06 INFORMATIONAL INFORMATIONAL IETF sec oauth 10.17487/RFC6755 RFC6756 Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines S. Trowbridge Editor E. Lear Editor G. Fishman Editor S. Bradner Editor September 2012 ASCII HTML 16

This document provides guidance to aid in the understanding of collaboration on standards development between the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) and the Internet Engineering Task Force (IETF) of the Internet Society (ISOC). It is an update of and obsoletes RFC 3356. The updates reflect changes in the IETF and ITU-T since RFC 3356 was written. The bulk of this document is common text with ITU-T A Series Supplement 3 (07/2012).

Note: This was approved by TSAG on 4 July 2012 as Supplement 3 to the ITU-T A-Series of Recommendations.

This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-rfc3356bis-05 RFC3356 RFC9141 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=6756 10.17487/RFC6756 RFC6757 Access Network Identifier (ANI) Option for Proxy Mobile IPv6 S. Gundavelli Editor J. Korhonen Editor M. Grayson K. Leung R. Pazhyannur October 2012 ASCII HTML 19 ANI ANI option Access Network Identifier option PMIPv6 ANI option

The local mobility anchor in a Proxy Mobile IPv6 (PMIPv6) domain is able to provide access-network- and access-operator-specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. [STANDARDS-TRACK]

 draft-ietf-netext-access-network-option-13 RFC7563 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6757 RFC6758 Tunneling of SMTP Message Transfer Priorities A. Melnikov K. Carlberg October 2012 ASCII HTML 11 Priority MMHS

This memo defines a mechanism for tunneling of SMTP (Simple Mail Transfer Protocol) Message Transfer Priority values through MTAs (Message Transfer Agents) that don't support the MT-PRIORITY SMTP extension. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-melnikov-smtp-priority-tunneling-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6758 RFC6759 Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX) B. Claise P. Aitken N. Ben-Dvora November 2012 ASCII HTML 43

This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-claise-export-application-info-in-ipfix-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6759 10.17487/RFC6759 RFC6760 Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP) S. Cheshire M. Krochmal February 2013 ASCII HTML 16

One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was to retire AppleTalk and the AppleTalk Name Binding Protocol (NBP) and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP and outlines the properties required of an IP-based replacement.

 draft-cheshire-dnsext-nbp-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6760 RFC6761 Special-Use Domain Names S. Cheshire M. Krochmal February 2013 ASCII HTML 13

This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.

 draft-cheshire-dnsext-special-names-03 RFC1918 RFC2606 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6761 10.17487/RFC6761 RFC6762 Multicast DNS S. Cheshire M. Krochmal February 2013 ASCII HTML 70

As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.

Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.

The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.

 draft-cheshire-dnsext-multicastdns-15 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6762 10.17487/RFC6762 RFC6763 DNS-Based Service Discovery S. Cheshire M. Krochmal February 2013 ASCII HTML 49

This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.

 draft-cheshire-dnsext-dns-sd-11 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6763 10.17487/RFC6763 RFC6764 Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV) C. Daboo February 2013 ASCII HTML 14 SRV iCalendar

This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locate CalDAV (Calendaring Extensions to Web Distributed Authoring and Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services.

 draft-daboo-srv-caldav-10 RFC4791 RFC6352 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6764 RFC6765 xDSL Multi-Pair Bonding (G.Bond) MIB E. Beili M. Morgenstern February 2013 ASCII HTML 73 Network Management Simple Network Management Protocol SNMP Management Information Base xDSL bonding aggregation G.998 G.998.1 G.998.2 G.998.3 TDIM IMA EFM

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendations G.998.1, G.998.2, and G.998.3. The textual conventions defining the bonding schemes are contained in a separate MIB module maintained by Internet Assigned Numbers Authority (IANA). The MIB modules specific to each bonding technology are defined in G9981-MIB, G9982-MIB, and G9983-MIB, respectively.

 draft-ietf-adslmib-gbond-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6765 10.17487/RFC6765 RFC6766 xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB E. Beili February 2013 ASCII HTML 55 Network Management Simple Network Management Protocol SNMP Management Information Base xDSL bonding aggregation G.998.3

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), as defined in ITU-T Recommendation G.998.3.

 draft-ietf-adslmib-gbond-tdim-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6766 10.17487/RFC6766 RFC6767 Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB E. Beili M. Morgenstern February 2013 ASCII HTML 53 Network Management Simple Network Management Protocol SNMP Management Information Base xDSL bonding Ethernet bonding aggregation 802.3ah G.998.2

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendation G.998.2.

 draft-ietf-adslmib-gbond-eth-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6767 10.17487/RFC6767 RFC6768 ATM-Based xDSL Bonded Interfaces MIB E. Beili February 2013 ASCII HTML 34 Network Management Simple Network Management Protocol SNMP Management Information Base bonding xDSL bonding aggregation G.Bond G.Bond/ATM G.998.1 IMA IMA+

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, as defined in ITU-T Recommendation G.998.1.

 draft-ietf-adslmib-gbond-atm-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6768 10.17487/RFC6768 RFC6769 Simple Virtual Aggregation (S-VA) R. Raszuk J. Heitz A. Lo L. Zhang X. Xu October 2012 ASCII HTML 8 BGP aggregation

All BGP routers in the Default-Free Zone (DFZ) are required to carry all routes in the Default-Free Routing Table (DFRT). This document describes a technique, Simple Virtual Aggregation (S-VA), that allows some BGP routers not to install all of those routes into the Forwarding Information Base (FIB).

Some routers in an Autonomous System (AS) announce an aggregate (the VA prefix) in addition to the routes they already announce. This enables other routers not to install the routes covered by the VA prefix into the FIB as long as those routes have the same next-hop as the VA prefix.

The VA prefixes that are announced within an AS are not announced to any other AS. The described functionality is of very low operational complexity, as it proposes a confined BGP speaker solution without any dependency on network-wide configuration or requirement for any form of intra-domain tunneling. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-grow-simple-va-12 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6769 RFC6770 Use Cases for Content Delivery Network Interconnection G. Bertrand Editor E. Stephan T. Burbridge P. Eardley K. Ma G. Watson November 2012 ASCII HTML 16 CDN CDNI

Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-cdni-use-cases-10 RFC3570 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC6770 RFC6771 Considerations for Having a Successful "Bar BOF" Side Meeting L. Eggert G. Camarillo October 2012 ASCII HTML 10

New work is typically brought to the IETF by a group of interested individuals. IETF meetings are a convenient place for such groups to hold informal get-togethers to discuss and develop their ideas. Such side meetings, which are not reflected in the IETF meeting agenda and have no official status, are often half-jokingly referred to as "bar BOF" sessions to acknowledge that some of them may eventually lead to a proposal for an official IETF BOF ("birds of a feather" session) on a given topic.

During recent IETF meetings, many such "bar BOF" get-togethers have been organized and moderated in ways that made them increasingly indistinguishable from official IETF BOFs or sometimes even IETF working group meetings.

This document argues that this recent trend is not helpful in reaching the ultimate goal of many of these get-togethers, i.e., to efficiently discuss and develop ideas for new IETF work. It encourages the organizers to consider the benefits of holding them in much less formal settings and to also consider alternative means to develop their ideas. This document also recommends that the community abandon the term "bar BOF" and instead use other terms such as "side meeting", in order to stress the unofficial nature of these get-togethers. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-eggert-successful-bar-bof-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6771 RFC6772 Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information H. Schulzrinne Editor H. Tschofenig Editor J. Cuellar J. Polk J. Morris M. Thomson January 2013 ASCII HTML 44 Authorization Policy Location Privacy

This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target.

Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information, whereas the other one applies to geodetic location information. Both algorithms come with limitations. There are circumstances where the amount of location obfuscation provided is less than what is desired. These algorithms might not be appropriate for all application domains. [STANDARDS-TRACK]

 draft-ietf-geopriv-policy-27 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6772 RFC6773 DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal T. Phelan G. Fairhurst C. Perkins November 2012 ASCII HTML 20 DCCP NAPT NAT UDP

This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates the Session Description Protocol (SDP) information for DCCP defined in RFC 5762. [STANDARDS-TRACK]

 draft-ietf-dccp-udpencap-11 RFC4340 RFC5762 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=6773 10.17487/RFC6773 RFC6774 Distribution of Diverse BGP Paths R. Raszuk Editor R. Fernando K. Patel D. McPherson K. Kumaki November 2012 ASCII HTML 22

The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today, BGP has no mechanisms to distribute alternate paths that are not considered best path between its speakers. This behavior results in a number of disadvantages for new applications and services.

The main objective of this document is to observe that by simply adding a new session between a route reflector and its client, the Nth best path can be distributed. This document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path.

This proposal does not specify any changes to the BGP protocol definition. It does not require a software upgrade of provider edge (PE) routers acting as route reflector clients. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-grow-diverse-bgp-path-dist-08 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6774 RFC6775 Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) Z. Shelby Editor S. Chakrabarti E. Nordmark C. Bormann November 2012 ASCII HTML 55

The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]

 draft-ietf-6lowpan-nd-21 RFC4944 RFC8505 RFC8929 RFC9010 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lowpan 10.17487/RFC6775 RFC6776 Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block A. Clark Q. Wu October 2012 ASCII HTML 9 RTP Control Protocol

This document defines an RTP Control Protocol (RTCP) Source Description (SDES) item and an RTCP Extended Report (XR) block carrying parameters that identify and describe a measurement period to which one or more other RTCP XR blocks may refer. [STANDARDS-TRACK]

 draft-ietf-xrblock-rtcp-xr-meas-identity-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6776 RFC6777 Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks W. Sun Editor G. Zhang Editor J. Gao G. Xie R. Papneja November 2012 ASCII HTML 29 Provisioning performance Performance measurement UNI Bandwidth on Demand performance evaluation Measurement methodologies

When setting up a Label Switched Path (LSP) in Generalized MPLS (GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the completion of the signaling process does not necessarily mean that the cross-connection along the LSP has been programmed accordingly and in a timely manner. Meanwhile, the completion of the signaling process may be used by LSP users or applications that control their use as an indication that the data path has become usable. The existence of the inconsistency between the signaling messages and cross-connection programming, and the possible failure of cross- connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the way in which LSPs are used and to make applications or tools that depend on and use LSPs more robust. This document defines a series of performance metrics to evaluate the connectivity of the data path in the signaling process. [STANDARDS-TRACK]

 draft-ietf-ccamp-dpm-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6777 RFC6778 Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching R. Sparks October 2012 ASCII HTML 8 tool

The IETF makes heavy use of email lists to conduct its work. Participants frequently need to search and browse the archives of these lists and have asked for improved search capabilities. The current archive mechanism could also be made more efficient. This memo captures the requirements for improved email list archiving and searching systems. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-sparks-genarea-mailarch-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6778 RFC6779 Definition of Managed Objects for the Neighborhood Discovery Protocol U. Herberg R. Cole I. Chakeres October 2012 ASCII HTML 67 Network Management Management Information base MIB SMIv2 Routing Neighbor Discovery MANET

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. [STANDARDS-TRACK]

 draft-ietf-manet-nhdp-mib-19 RFC7939 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC6779 RFC6780 RSVP ASSOCIATION Object Extensions L. Berger F. Le Faucheur A. Narayanan October 2012 ASCII HTML 17

The RSVP ASSOCIATION object was defined in the context of GMPLS-controlled Label Switched Paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872. [STANDARDS-TRACK]

 draft-ietf-ccamp-assoc-ext-06 RFC2205 RFC3209 RFC3473 RFC4872 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6780 RFC6781 DNSSEC Operational Practices, Version 2 O. Kolkman W. Mekking R. Gieben December 2012 ASCII HTML 71 DNSSEC operational key rollover

This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.

The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.

This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations.

 draft-ietf-dnsop-rfc4641bis-13 RFC4641 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=6781 10.17487/RFC6781 RFC6782 Wireline Incremental IPv6 V. Kuarsingh Editor L. Howard November 2012 ASCII HTML 29 transition IPv6 transition operator

Operators worldwide are in various stages of preparing for or deploying IPv6 in their networks. These operators often face difficult challenges related to IPv6 introduction, along with those related to IPv4 run-out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6-dominant environment with long transition periods varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity, utilizing well-defined and commercially available IPv6 transition technologies. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-v6ops-wireline-incremental-ipv6-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6782 RFC6783 Mailing Lists and Non-ASCII Addresses J. Levine R. Gellens November 2012 ASCII HTML 9 Mail internationalization mailing lists

This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses but does not specify protocol changes or offer implementation or deployment advice. This document is a product of the Internet Engineering Task Force (IETF).

 draft-ietf-eai-mailinglistbis-05 RFC5983 INFORMATIONAL INFORMATIONAL IETF app eai 10.17487/RFC6783 RFC6784 Kerberos Options for DHCPv6 S. Sakane M. Ishiyama November 2012 ASCII HTML 12 security dhcpv6

This document defines four new options for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). These options are used to carry configuration information for Kerberos. [STANDARDS-TRACK]

 draft-sakane-dhc-dhcpv6-kdc-option-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6784 RFC6785 Support for Internet Message Access Protocol (IMAP) Events in Sieve B. Leiba November 2012 ASCII HTML 20 email filtering

Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in IMAP where messages are created or changed, adding the option of user-defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). Because this requires future Sieve extensions to specify their interactions with this one, this document updates the base Sieve specification, RFC 5228. [STANDARDS-TRACK]

 draft-ietf-sieve-imap-sieve-09 RFC5228 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6785 RFC6786 Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs A. Yegin R. Cragie November 2012 ASCII HTML 11

This document specifies a mechanism for delivering the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs (AVPs) in encrypted form. [STANDARDS-TRACK]

 draft-yegin-pana-encr-avp-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6786 RFC6787 Media Resource Control Protocol Version 2 (MRCPv2) D. Burnett S. Shanmugham November 2012 ASCII HTML 224 mrcp speechsc asr tts speech services speech recognition speech synthesis nlsml speaker authentication speaker verification speaker identification

The Media Resource Control Protocol Version 2 (MRCPv2) allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers, and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol -- it relies on other protocols, such as the Session Initiation Protocol (SIP), to coordinate MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover, and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. [STANDARDS-TRACK]

 draft-ietf-speechsc-mrcpv2-28 PROPOSED STANDARD PROPOSED STANDARD IETF rai speechsc http://www.rfc-editor.org/errata_search.php?rfc=6787 10.17487/RFC6787 RFC6788 The Line-Identification Option S. Krishnan A. Kavanagh B. Varga S. Ooghe E. Nordmark November 2012 ASCII HTML 17

In Ethernet-based aggregation networks, several subscriber premises may be logically connected to the same interface of an Edge Router. This document proposes a method for the Edge Router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios in which multiple user ports are mapped to the same virtual interface on the Edge Router. [STANDARDS-TRACK]

 draft-ietf-6man-lineid-08 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6788 10.17487/RFC6788 RFC6789 Congestion Exposure (ConEx) Concepts and Use Cases B. Briscoe Editor R. Woundy Editor A. Cooper Editor December 2012 ASCII HTML 17 Congestion Signaling Traffic Management

This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-conex-concepts-uses-05 INFORMATIONAL INFORMATIONAL IETF tsv conex 10.17487/RFC6789 RFC6790 The Use of Entropy Labels in MPLS Forwarding K. Kompella J. Drake S. Amante W. Henderickx L. Yong November 2012 ASCII HTML 25 entropy hash ecmp load balancing

Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK]

 draft-ietf-mpls-entropy-label-06 RFC3031 RFC3107 RFC3209 RFC5036 RFC7274 RFC7447 RFC8012 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6790 10.17487/RFC6790 RFC6791 Stateless Source Address Mapping for ICMPv6 Packets X. Li C. Bao D. Wing R. Vaithianathan G. Huston November 2012 ASCII HTML 6 IP/ICMP Translation Algorithm IPv4-translatable IPv6 addresses ICMPv6 traceroute

A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non-IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. [STANDARDS-TRACK]

 draft-ietf-v6ops-ivi-icmp-address-07 RFC6145 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC6791 RFC6792 Guidelines for Use of the RTP Monitoring Framework Q. Wu Editor G. Hunt P. Arden November 2012 ASCII HTML 17 Real Time Control Protocol

This memo proposes an extensible Real-time Transport Protocol (RTP) monitoring framework for extending the RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics that attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks that cover their set of concerns. Where possible, a specific block should be designed to be reusable across more than one application, for example, for all of voice, streaming audio, and video. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-avtcore-monarch-22 INFORMATIONAL INFORMATIONAL IETF rai avtcore 10.17487/RFC6792 RFC6793 BGP Support for Four-Octet Autonomous System (AS) Number Space Q. Vohra E. Chen December 2012 ASCII HTML 12 autonomous system border gateway protocol

The Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK]

 draft-ietf-idr-rfc4893bis-07 RFC4893 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=6793 10.17487/RFC6793 RFC6794 A Framework for Session Initiation Protocol (SIP) Session Policies V. Hilt G. Camarillo J. Rosenberg December 2012 ASCII HTML 36

Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. [STANDARDS-TRACK]

 draft-ietf-sip-session-policy-framework-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC6794 RFC6795 A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies V. Hilt G. Camarillo December 2012 ASCII HTML 18

This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies. This event package enables user agents (UAs) to subscribe to session policies for a SIP session and to receive notifications if these policies change. [STANDARDS-TRACK]

 draft-ietf-sipping-policy-package-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC6795 RFC6796 A User Agent Profile Data Set for Media Policy V. Hilt G. Camarillo J. Rosenberg D. Worley December 2012 ASCII HTML 43 SIP Session Policy Data Set

This specification defines an XML document format to describe the media properties of Session Initiation Protocol (SIP) sessions. Examples for media properties are the codecs or media types used in the session. This document also defines an XML document format to describe policies that limit the media properties of SIP sessions. [STANDARDS-TRACK]

 draft-camarillo-rai-media-policy-dataset-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6796 RFC6797 HTTP Strict Transport Security (HSTS) J. Hodges C. Jackson A. Barth November 2012 ASCII HTML 46 HTTPS TLS SSL ForceHTTPS man-in-the-middle MITM certificate error certificate verification security policy secure transport IDNA-Canonicalization

This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK]

 draft-ietf-websec-strict-transport-sec-14 PROPOSED STANDARD PROPOSED STANDARD IETF app websec http://www.rfc-editor.org/errata_search.php?rfc=6797 10.17487/RFC6797 RFC6798 RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting A. Clark Q. Wu November 2012 ASCII HTML 13

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of packet delay variation metrics for a range of RTP applications. [STANDARDS-TRACK]

 draft-ietf-xrblock-rtcp-xr-pdv-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6798 RFC6799 RFC6800 RFC6801 Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework U. Kozat A. Begen November 2012 ASCII HTML 11

This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the Forward Error Correction (FEC) Framework and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-fledged protocol but to show how the defined framework and SDP elements can be combined together to implement a CDP. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-fecframe-pseudo-cdp-05 INFORMATIONAL INFORMATIONAL IETF tsv fecframe 10.17487/RFC6801 RFC6802 Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets S. Baillargeon C. Flinta A. Johnsson November 2012 ASCII HTML 15 available capacity rate train interval padding buffer test session

This memo describes an extension to the Two-Way Active Measurement Protocol (TWAMP). Specifically, it extends the TWAMP-Test protocol, which identifies and manages packet trains, in order to measure capacity metrics like the available path capacity, tight section capacity, and UDP delivery rate in the forward and reverse path directions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ippm-twamp-value-added-octets-09 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6802 RFC6803 Camellia Encryption for Kerberos 5 G. Hudson November 2012 ASCII HTML 13 Camellia Kerberos

This document specifies two encryption types and two corresponding checksum types for the Kerberos cryptosystem framework defined in RFC 3961. The new types use the Camellia block cipher in CBC mode with ciphertext stealing and the CMAC algorithm for integrity protection. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-krb-wg-camellia-cts-02 INFORMATIONAL INFORMATIONAL IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=6803 10.17487/RFC6803 RFC6804 DISCOVER: Supporting Multicast DNS Queries B. Manning November 2012 ASCII HTML 9

This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. This opcode was tested in experiments run during 1995 and 1996 for the Topology Based Domain Search (TBDS) project. This project is no longer active and there are no current plans to restart it. TBDS was the first known use of multicast transport for DNS. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result. This document defines a Historic Document for the Internet community.

 draft-manning-opcode-discover-07 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC6804 RFC6805 The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS D. King Editor A. Farrel Editor November 2012 ASCII HTML 33

Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture.

Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward-Recursive PCE-based Computation (BRPC) procedure can be used to derive an optimal path.

This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-pce-hierarchy-fwk-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC6805 RFC6806 Kerberos Principal Name Canonicalization and Cross-Realm Referrals S. Hartman Editor K. Raeburn L. Zhu November 2012 ASCII HTML 19 authentication security protocols identity

This memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm Ticket-Granting Ticket (TGT) to another realm on the referral path. The clients will use this referral information to reach the realm of the target principal and then receive the ticket. This memo also provides a mechanism for verifying that a request has not been tampered with in transit. This memo updates RFC 4120. [STANDARDS-TRACK]

 draft-ietf-krb-wg-kerberos-referrals-15 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6806 RFC6807 Population Count Extensions to Protocol Independent Multicast (PIM) D. Farinacci G. Shepherd S. Venaas Y. Cai December 2012 ASCII HTML 15

This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the Protocol Independent Multicast (PIM) protocol allow a rough approximation of tree-based data in a scalable fashion. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-pim-pop-count-07 EXPERIMENTAL EXPERIMENTAL IETF rtg pim 10.17487/RFC6807 RFC6808 Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track L. Ciavattone R. Geib A. Morton M. Wieser December 2012 ASCII HTML 29 One-way Delay IP Performance Metrics IPPM

This memo provides the supporting test plan and results to advance RFC 2679 on one-way delay metrics along the Standards Track, following the process in RFC 6576. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2679. This memo also provides direct input for development of a revision of RFC 2679. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-ippm-testplan-rfc2679-03 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6808 RFC6809 Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) C. Holmberg I. Sedlacek H. Kaplan November 2012 ASCII HTML 19 proxy feature feature tag feature-capability indicator Feature-Caps capability

This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field.

SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.

This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators. [STANDARDS-TRACK]

 draft-ietf-sipcore-proxy-feature-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6809 RFC6810 The Resource Public Key Infrastructure (RPKI) to Router Protocol R. Bush R. Austein January 2013 ASCII HTML 27

In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. [STANDARDS-TRACK]

 draft-ietf-sidr-rpki-rtr-26 RFC8210 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6810 RFC6811 BGP Prefix Origin Validation P. Mohapatra J. Scudder D. Ward R. Bush R. Austein January 2013 ASCII HTML 10 SIDR security

To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK]

 draft-ietf-sidr-pfx-validate-10 RFC8481 RFC8893 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6811 RFC6812 Cisco Service-Level Assurance Protocol M. Chiba A. Clemm S. Medley J. Salowey S. Thombare E. Yedavalli January 2013 ASCII HTML 27 Cisco's SLA Protocol

Cisco's Service-Level Assurance Protocol (Cisco's SLA Protocol) is a Performance Measurement protocol that has been widely deployed. The protocol is used to measure service-level parameters such as network latency, delay variation, and packet/frame loss. This document describes the Cisco SLA Protocol Measurement-Type UDP-Measurement, to enable vendor interoperability. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-cisco-sla-protocol-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6812 RFC6813 The Network Endpoint Assessment (NEA) Asokan Attack Analysis J. Salowey S. Hanna December 2012 ASCII HTML 8 Man-in-the-Middle MITM Security Endpoint Posture Protocol Forwarding TNC Channel Binding Cryptographic Countermeasure

The Network Endpoint Assessment (NEA) protocols are subject to a subtle forwarding attack that has become known as the NEA Asokan Attack. This document describes the attack and countermeasures that may be mounted. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-nea-asokan-02 INFORMATIONAL INFORMATIONAL IETF sec nea 10.17487/RFC6813 RFC6814 Formally Deprecating Some IPv4 Options C. Pignataro F. Gont November 2012 ASCII HTML 6

A number of IPv4 options have become obsolete in practice, but have never been formally deprecated. This document deprecates such IPv4 options, thus cleaning up the corresponding IANA registry. Additionally, it obsoletes RFCs 1385, 1393, 1475, and 1770, and requests that the RFC Editor change their status to Historic. [STANDARDS-TRACK]

 draft-gp-intarea-obsolete-ipv4-options-iana-02 RFC1385 RFC1393 RFC1475 RFC1770 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6814 RFC6815 Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful S. Bradner K. Dubray J. McQuaid A. Morton November 2012 ASCII HTML 11 testing performance

The Benchmarking Methodology Working Group (BMWG) has been developing key performance metrics and laboratory test methods since 1990, and continues this work at present. The methods described in RFC 2544 are intended to generate traffic that overloads network device resources in order to assess their capacity. Overload of shared resources would likely be harmful to user traffic performance on a production network, and there are further negative consequences identified with production application of the methods. This memo clarifies the scope of RFC 2544 and other IETF BMWG benchmarking work for isolated test environments only, and it encourages new standards activity for measurement methods applicable outside that scope. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-bmwg-2544-as-08 RFC2544 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6815 RFC6816 Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME V. Roca M. Cunche J. Lacan December 2012 ASCII HTML 24 Forward Error Correction LDPC-Staircase

This document describes a fully specified simple Forward Error Correction (FEC) scheme for Low-Density Parity Check (LDPC) Staircase codes that can be used to protect media streams along the lines defined by FECFRAME. These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases, and they also feature very high encoding and decoding throughputs. LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow or to protect globally several mid-rate flows within a single FECFRAME instance. They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum.

 draft-ietf-fecframe-ldpc-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6816 RFC6817 Low Extra Delay Background Transport (LEDBAT) S. Shalunov G. Hazel J. Iyengar M. Kuehlewind December 2012 ASCII HTML 25 Congestion control delay-based scavenger P2P

Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-ledbat-congestion-10 EXPERIMENTAL EXPERIMENTAL IETF tsv ledbat 10.17487/RFC6817 RFC6818 Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile P. Yee January 2013 ASCII HTML 8

This document updates RFC 5280, the "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. [STANDARDS-TRACK]

 draft-ietf-pkix-rfc5280-clarifications-11 RFC5280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6818 RFC6819 OAuth 2.0 Threat Model and Security Considerations T. Lodderstedt Editor M. McGloin P. Hunt January 2013 ASCII HTML 71 authorization authentication token counter-measures HTTP REST

This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-oauth-v2-threatmodel-08 INFORMATIONAL INFORMATIONAL IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=6819 10.17487/RFC6819 RFC6820 Address Resolution Problems in Large Data Center Networks T. Narten M. Karir I. Foo January 2013 ASCII HTML 17 ARMD data center ARP ND Neighbor Discovery

This document examines address resolution issues related to the scaling of data centers with a very large number of hosts. The scope of this document is relatively narrow, focusing on address resolution (the Address Resolution Protocol (ARP) in IPv4 and Neighbor Discovery (ND) in IPv6) within a data center. This document is a product of the Internet Engineering Task Force (IETF).

 draft-ietf-armd-problem-statement-04 INFORMATIONAL INFORMATIONAL IETF ops armd 10.17487/RFC6820 RFC6821 Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality E. Marocco A. Fusco I. Rimac V. Gurbani December 2012 ASCII HTML 16 cross-domain traffic bandwidth transit traffic peer-to-peer caching peer-to-peer swarm

Peer-to-peer (P2P) traffic optimization techniques that aim at improving locality in the peer selection process have attracted great interest in the research community and have been the subject of much discussion. Some of this discussion has produced controversial myths, some rooted in reality while others remain unfounded. This document evaluates the most prominent myths attributed to P2P optimization techniques by referencing the most relevant study or studies that have addressed facts pertaining to the myth. Using these studies, the authors hope to either confirm or refute each specific myth.

This document is a product of the IRTF P2PRG (Peer-to-Peer Research Group).

 draft-irtf-p2prg-mythbustering-03 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6821 RFC6822 IS-IS Multi-Instance S. Previdi Editor L. Ginsberg M. Shand A. Roy D. Ward December 2012 ASCII HTML 14 intermediate system to intermediate system

This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System to Intermediate System (IS-IS) routing protocol instances.

Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies. Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs.

 draft-ietf-isis-mi-08 RFC8202 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=6822 10.17487/RFC6822 RFC6823 Advertising Generic Information in IS-IS L. Ginsberg S. Previdi M. Shand December 2012 ASCII HTML 11 intermediate system to intermediate system

This document describes the manner in which generic application information (i.e., information not directly related to the operation of the Intermediate System to Intermediate System (IS-IS) protocol) should be advertised in IS-IS Link State Protocol Data Units (LSPs) and defines guidelines that should be used when flooding such information.

 draft-ietf-isis-genapp-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6823 RFC6824 TCP Extensions for Multipath Operation with Multiple Addresses A. Ford C. Raiciu M. Handley O. Bonaventure January 2013 ASCII HTML 64

TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.

Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-mptcp-multiaddressed-12 RFC8684 EXPERIMENTAL EXPERIMENTAL IETF tsv mptcp http://www.rfc-editor.org/errata_search.php?rfc=6824 10.17487/RFC6824 RFC6825 Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS M. Miyazawa T. Otani K. Kumaki T. Nadeau January 2013 ASCII HTML 40 TED-MIB ted mib

This memo defines the Management Information Base (MIB) objects for managing the Traffic Engineering Database (TED) information with extensions in support of the Multiprotocol Label Switching (MPLS) with Traffic Engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. [STANDARDS-TRACK]

 draft-ietf-ccamp-gmpls-ted-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6825 RFC6826 Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths IJ. Wijnands Editor T. Eckert N. Leymann M. Napierala January 2013 ASCII HTML 12

Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), that needs to pass through an MPLS domain in which Multipoint LDP (mLDP) point-to-multipoint and/or multipoint-to-multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. This document describes procedures regarding how IP multicast trees are spliced together with multipoint LSPs. [STANDARDS-TRACK]

 draft-ietf-mpls-mldp-in-band-signaling-08 RFC7438 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6826 RFC6827 Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols A. Malis Editor A. Lindem Editor D. Papadimitriou Editor January 2013 ASCII HTML 30

The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).

The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks.

The requirements for GMPLS routing to satisfy the requirements of ASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.

Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. [STANDARDS-TRACK]

 draft-ietf-ccamp-rfc5787bis-06 RFC5787 RFC5786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6827 RFC6828 Content Splicing for RTP Sessions J. Xia January 2013 ASCII HTML 17

Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and delivers the substitutive multimedia content to the receivers for a period of time. Splicing is commonly used for insertion of local advertisements by cable operators, whereby national advertisement content is replaced with a local advertisement.

This memo describes some use cases for content splicing and a set of requirements for splicing content delivered by RTP. It provides concrete guidelines for how an RTP mixer can be used to handle content splicing. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-avtext-splicing-for-rtp-12 INFORMATIONAL INFORMATIONAL IETF rai avtext 10.17487/RFC6828 RFC6829 Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 M. Chen P. Pan C. Pignataro R. Asati January 2013 ASCII HTML 8

The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data-plane failures in all MPLS LSPs, including LSPs used for each direction of an MPLS Pseudowire (PW). However, the LSP Ping and traceroute elements used for PWs are not specified for IPv6 address usage.

This document extends the PW LSP Ping and traceroute mechanisms so they can be used with PWs that are set up and maintained using IPv6 LDP sessions. This document updates RFC 4379. [STANDARDS-TRACK]

 draft-ietf-mpls-ipv6-pw-lsp-ping-04 RFC8029 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6829 RFC6830 The Locator/ID Separation Protocol (LISP) D. Farinacci V. Fuller D. Meyer D. Lewis January 2013 ASCII HTML 75

This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.

Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-lisp-24 RFC9300 RFC9301 RFC8113 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6830 RFC6831 The Locator/ID Separation Protocol (LISP) for Multicast Environments D. Farinacci D. Meyer J. Zwiebel S. Venaas January 2013 ASCII HTML 28

This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-lisp-multicast-14 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6831 RFC6832 Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites D. Lewis D. Meyer D. Farinacci V. Fuller January 2013 ASCII HTML 19

This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP. A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts. Second, this document adds Network Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-lisp-interworking-06 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6832 RFC6833 Locator/ID Separation Protocol (LISP) Map-Server Interface V. Fuller D. Farinacci January 2013 ASCII HTML 13

This document describes the Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases.

By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-lisp-ms-16 RFC9301 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6833 RFC6834 Locator/ID Separation Protocol (LISP) Map-Versioning L. Iannone D. Saucez O. Bonaventure January 2013 ASCII HTML 21

This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. This document defines an Experimental Protocol for the Internet community.

 draft-ietf-lisp-map-versioning-09 RFC9302 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6834 RFC6835 The Locator/ID Separation Protocol Internet Groper (LIG) D. Farinacci D. Meyer January 2013 ASCII HTML 12

A simple tool called the Locator/ID Separation Protocol (LISP) Internet Groper or 'lig' can be used to query the LISP mapping database. This document describes how it works. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-lisp-lig-06 INFORMATIONAL INFORMATIONAL IETF int lisp 10.17487/RFC6835 RFC6836 Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT) V. Fuller D. Farinacci D. Meyer D. Lewis January 2013 ASCII HTML 25

This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and Generic Routing Encapsulation (GRE). This document defines an Experimental Protocol for the Internet community.

 draft-ietf-lisp-alt-11 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6836 RFC6837 NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database E. Lear January 2013 ASCII HTML 31

The Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of all EID-to- RLOC mappings scales well to at least 10^8 entries. This document defines an Experimental Protocol for the Internet community.

 draft-lear-lisp-nerd-09 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6837 RFC6838 Media Type Specifications and Registration Procedures N. Freed J. Klensin T. Hansen January 2013 ASCII HTML 32

This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.

 draft-ietf-appsawg-media-type-regs-14 RFC4288 BCP0013 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg 10.17487/RFC6838 RFC6839 Additional Media Type Structured Syntax Suffixes T. Hansen A. Melnikov January 2013 ASCII HTML 14 structured syntax suffix media type

A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-appsawg-media-type-suffix-regs-08 RFC3023 RFC7303 INFORMATIONAL INFORMATIONAL IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6839 10.17487/RFC6839 RFC6840 Clarifications and Implementation Notes for DNS Security (DNSSEC) S. Weiler Editor D. Blacka Editor February 2013 ASCII HTML 21 EAP AAA reconnect

This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing.

This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification.

 draft-ietf-dnsext-dnssec-bis-updates-20 RFC4033 RFC4034 RFC4035 RFC5155 RFC8749 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=6840 10.17487/RFC6840 RFC6841 A Framework for DNSSEC Policies and DNSSEC Practice Statements F. Ljunggren AM. Eklund Lowinder T. Okubo January 2013 ASCII HTML 27 DNS DNSSEC DP DPS

This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented.

In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ietf-dnsop-dnssec-dps-framework-11 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6841 RFC6842 Client Identifier Option in DHCP Server Replies N. Swamy G. Halwasia P. Jhingran January 2013 ASCII HTML 5

This document updates RFC 2131 "Dynamic Host Configuration Protocol" by addressing the issues arising from that document's specification that the server MUST NOT return the 'client identifier' option to the client. [STANDARDS-TRACK]

 draft-ietf-dhc-client-id-07 RFC2131 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6842 RFC6843 RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting A. Clark K. Gross Q. Wu January 2013 ASCII HTML 9 Round Trip Delay End System Delay

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of delay metrics for use in a range of Real-time Transport Protocol (RTP) applications. [STANDARDS-TRACK]

 draft-ietf-xrblock-rtcp-xr-delay-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6843 RFC6844 DNS Certification Authority Authorization (CAA) Resource Record P. Hallam-Baker R. Stradling January 2013 ASCII HTML 18 DNS DNSSEC PKIX

The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. [STANDARDS-TRACK]

 draft-ietf-pkix-caa-15 RFC8659 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=6844 10.17487/RFC6844 RFC6845 OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type N. Sheth L. Wang J. Zhang January 2013 ASCII HTML 9 OSPF P2MP Broadcast Interface

This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as Link State Advertisement (LSA) database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router-LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF.

This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340). [STANDARDS-TRACK]

 draft-ietf-ospf-hybrid-bcast-and-p2mp-06 RFC2328 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC6845 RFC6846 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) G. Pelletier K. Sandlund L-E. Jonsson M. West January 2013 ASCII HTML 96

This document specifies a RObust Header Compression (ROHC) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as selective acknowledgments (SACKs) and Timestamps.

ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common.

This specification obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies other compression methods used. [STANDARDS-TRACK]

 draft-sandlund-rfc4996bis-02 RFC4996 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6846 10.17487/RFC6846 RFC6847 Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL) D. Melman T. Mizrahi D. Eastlake 3rd January 2013 ASCII HTML 13 FCoE FCRB TRILL RBridge

Fibre Channel over Ethernet (FCoE) and Transparent Interconnection of Lots of Links (TRILL) are two emerging standards in the data center environment. While these two protocols are seemingly unrelated, they have a very similar behavior in the forwarding plane, as both perform hop-by-hop forwarding over Ethernet, modifying the packet's Media Access Control (MAC) addresses at each hop. This document describes an architecture for the integrated deployment of these two protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-mme-trill-fcoe-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6847 RFC6848 Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO) J. Winterbottom M. Thomson R. Barnes B. Rosen R. George January 2013 ASCII HTML 21 Extension Local Civic Location GEOPRIV

New fields are occasionally added to civic addresses. A backward- compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Initial extensions for some new elements are also defined. The Location-to-Service Translation (LoST) protocol mechanism (defined in RFC 5222) that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process. [STANDARDS-TRACK]

 draft-ietf-geopriv-local-civic-10 RFC4776 RFC5222 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6848 RFC6849 An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback H. Kaplan Editor K. Hedayat N. Venna P. Jones N. Stratton February 2013 ASCII HTML 33 multimedia audio video RTCP diagnostic voip

The wide deployment of Voice over IP (VoIP), real-time text, and Video over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, real-time text, or Video over IP service. Today, in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new Session Description Protocol (SDP) media types and attributes that enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, real-time text, and Video over IP performance metrics.

 draft-ietf-mmusic-media-loopback-27 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC6849 RFC6850 Definitions of Managed Objects for Routing Bridges (RBridges) A. Rijhsinghani K. Zebrose January 2013 ASCII HTML 59

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a Routing Bridge (RBridge), also known as a TRILL Switch, based on the IETF TRILL (Transparent Interconnection of Lots of Links) protocol. [STANDARDS-TRACK]

 draft-ietf-trill-rbridge-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC6850 RFC6851 Internet Message Access Protocol (IMAP) - MOVE Extension A. Gulbrandsen N. Freed Editor January 2013 ASCII HTML 8 IMAP

This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. [STANDARDS-TRACK]

 draft-ietf-imapmove-command-05 PROPOSED STANDARD PROPOSED STANDARD IETF app imapmove 10.17487/RFC6851 RFC6852 Affirmation of the Modern Paradigm for Standards R. Housley S. Mills J. Jaffe B. Aboba L. St.Amour January 2013 ASCII HTML 5

On 29 August 2012, the leaders of the IEEE Standards Association, the IAB, the IETF, the Internet Society, and the W3C signed a statement affirming the importance of a jointly developed set of principles establishing a modern paradigm for global, open standards. These principles have become known as the "OpenStand" principles. This document contains the text of the affirmation that was signed. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-iab-modern-paradigm-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6852 RFC6853 DHCPv6 Redundancy Deployment Considerations J. Brzozowski J. Tremblay J. Chen T. Mrugalski February 2013 ASCII HTML 16 DHCPv6 Redundancy Deployment Considerations

This document provides information for those wishing to use DHCPv6 to support their deployment of IPv6. In particular, it discusses the provision of semi-redundant DHCPv6 services.

 draft-ietf-dhc-dhcpv6-redundancy-consider-03 BCP0180 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc 10.17487/RFC6853 RFC6854 Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields B. Leiba March 2013 ASCII HTML 9

The Internet Message Format (RFC 5322) allows "group" syntax in some email header fields, such as "To:" and "CC:", but not in "From:" or "Sender:". This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in "Resent-From:" and "Resent-Sender:", in certain situations.

 draft-leiba-5322upd-from-group-09 RFC5322 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6854 RFC6855 IMAP Support for UTF-8 P. Resnick Editor C. Newman Editor S. Shen Editor March 2013 ASCII HTML 12 IMAP IDNA

This specification extends the Internet Message Access Protocol (IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 5738.

 draft-ietf-eai-5738bis-12 RFC5738 PROPOSED STANDARD PROPOSED STANDARD IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=6855 10.17487/RFC6855 RFC6856 Post Office Protocol Version 3 (POP3) Support for UTF-8 R. Gellens C. Newman J. Yao K. Fujiwara March 2013 ASCII HTML 14 internationalized

This specification extends the Post Office Protocol version 3 (POP3) to support international strings encoded in UTF-8 in usernames, passwords, mail addresses, message headers, and protocol-level text strings.

 draft-ietf-eai-rfc5721bis-08 RFC5721 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6856 RFC6857 Post-Delivery Message Downgrading for Internationalized Email Messages K. Fujiwara March 2013 ASCII HTML 20 EAI Email Address Internationalization Downgrade MAIL

The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message. To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format. As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements.

 draft-ietf-eai-popimap-downgrade-08 PROPOSED STANDARD PROPOSED STANDARD IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=6857 10.17487/RFC6857 RFC6858 Simplified POP and IMAP Downgrading for Internationalized Email A. Gulbrandsen March 2013 ASCII HTML 6

This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement, and provides only rudimentary results.

 draft-ietf-eai-simpledowngrade-07 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6858 RFC6859 Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership B. Leiba January 2013 ASCII HTML 3 nomcom IAOC

RFC 3777 specifies that "sitting members" of the IAB and IESG "may not volunteer to serve on the nominating committee". Since the time that document was written, the IETF Administrative Oversight Committee (IAOC) was formed; that body is not covered by RFC 3777. There is also ambiguity in RFC 3777 about whether ex officio members and liaisons are included as "sitting members". This document updates RFC 3777 to clarify the rules as they apply to members of the IAB, the IESG, and the IAOC. This memo documents an Internet Best Current Practice.

 draft-leiba-3777upd-eligibility-06 RFC7437 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6859 RFC6860 Hiding Transit-Only Networks in OSPF Y. Yang A. Retana A. Roy January 2013 ASCII HTML 13

A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link State Advertisements (LSAs) but are not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and reduce vulnerability to remote attacks.

In the context of this document, 'hiding' implies that the prefixes are not installed in the routing tables on OSPF routers. In some cases, IP addresses may still be visible when using OSPFv2.

This document updates RFCs 2328 and 5340. [STANDARDS-TRACK]

 draft-ietf-ospf-prefix-hiding-07 RFC2328 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6860 10.17487/RFC6860 RFC6861 The "create-form" and "edit-form" Link Relations I. Dzmanashvili January 2013 ASCII HTML 6

RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines link relation types that may be used to express the relationships between a resource and an input form for constructing data submissions. This document is not an Internet Standards Track specification; it is published for informational purposes.

 draft-ioseb-dzmanashvili-link-relation-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6861 RFC6862 Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements G. Lebovitz M. Bhatia B. Weis March 2013 ASCII HTML 26

Different routing protocols employ different mechanisms for securing protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed. This document is a companion document to RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines"; together they form the guidance and instruction KARP design teams will use to review and overhaul routing protocol transport security.

 draft-ietf-karp-threats-reqs-07 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6862 RFC6863 Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide S. Hartman D. Zhang March 2013 ASCII HTML 11

This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518). Key components of solutions to gaps identified in this document are already underway.

 draft-ietf-karp-ospf-analysis-06 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6863 RFC6864 Updated Specification of the IPv4 ID Field J. Touch February 2013 ASCII HTML 19

The IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFCs 791, 1122, and 2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. [STANDARDS-TRACK]

 draft-ietf-intarea-ipv4-id-update-07 RFC0791 RFC1122 RFC2003 PROPOSED STANDARD PROPOSED STANDARD IETF int intarea 10.17487/RFC6864 RFC6865 Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME V. Roca M. Cunche J. Lacan A. Bouabdallah K. Matsuzono February 2013 ASCII HTML 23 Forward Error Correction Reed-Solomon

This document describes a fully-specified simple Forward Error Correction (FEC) scheme for Reed-Solomon codes over the finite field (also known as the Galois Field) GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by FECFRAME. The Reed-Solomon codes considered have attractive properties, since they offer optimal protection against packet erasures and the source symbols are part of the encoding symbols, which can greatly simplify decoding. However, the price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of the Low-Density Parity Check (LDPC) codes, for instance.

 draft-ietf-fecframe-simple-rs-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6865 RFC6866 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks B. Carpenter S. Jiang February 2013 ASCII HTML 11

This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses.

 draft-ietf-6renum-static-problem-03 INFORMATIONAL INFORMATIONAL IETF ops 6renum 10.17487/RFC6866 RFC6867 An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP) Y. Nir Q. Wu January 2013 ASCII HTML 9

This document updates the Internet Key Exchange Protocol version 2 (IKEv2) described in RFC 5996. This extension allows an IKE Security Association (SA) to be created and authenticated using the Extensible Authentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696. This document defines an Experimental Protocol for the Internet community.

 draft-nir-ipsecme-erx-11 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6867 RFC6868 Parameter Value Encoding in iCalendar and vCard C. Daboo February 2013 ASCII HTML 7 calendar contact

This specification updates the data formats for iCalendar (RFC 5545) and vCard (RFC 6350) to allow parameter values to include certain characters forbidden by the existing specifications.

 draft-daboo-ical-vcard-parameter-encoding-04 RFC5545 RFC6321 RFC6350 RFC6351 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6868 10.17487/RFC6868 RFC6869 vCard KIND:device G. Salgueiro J. Clarke P. Saint-Andre February 2013 ASCII HTML 9 vCard

This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). [STANDARDS-TRACK]

 draft-salgueiro-vcarddav-kind-device-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6869 RFC6870 Pseudowire Preferential Forwarding Status Bit P. Muley Editor M. Aissaoui Editor February 2013 ASCII HTML 35 PW redundancy active PW standby PW primary PW secondary PW PW precedence

This document describes a mechanism for signaling the active and standby status of redundant Pseudowires (PWs) between their termination points. A set of Redundant PWs is configured between Provider Edge (PE) nodes in single-segment pseudowire (SS-PW) applications or between Terminating Provider Edge (T-PE) nodes in Multi-Segment Pseudowire (MS-PW) applications.

In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is defined. This bit indicates a Preferential Forwarding status with a value of active or standby for each PW in a redundant set.

In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW.

Finally, this document updates RFC 4447 by adding details to the handling of the PW status code bits in the PW Status TLV.

 draft-ietf-pwe3-redundancy-bit-09 RFC4447 RFC7771 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 http://www.rfc-editor.org/errata_search.php?rfc=6870 10.17487/RFC6870 RFC6871 Session Description Protocol (SDP) Media Capabilities Negotiation R. Gilman R. Even F. Andreasen February 2013 ASCII HTML 55 Session Capabilities Latent Configurations Media Format Capability

Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters.

This document updates the IANA Considerations of RFC 5939.

 draft-ietf-mmusic-sdp-media-capabilities-17 RFC5939 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC6871 RFC6872 The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model V. Gurbani Editor E. Burger Editor T. Anjali H. Abdelnur O. Festor February 2013 ASCII HTML 39 logging analytics information model

Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de facto standard formats are invaluable to system administrators for troubleshooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and, as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. This document describes a framework, including requirements and analysis of existing approaches, and specifies an information model for development of a SIP common log file format that can be used uniformly by user agents, proxies, registrars, and redirect servers as well as back-to-back user agents.

 draft-ietf-sipclf-problem-statement-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipclf 10.17487/RFC6872 RFC6873 Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) G. Salgueiro V. Gurbani A. B. Roach February 2013 ASCII HTML 28 SIPCLF

The SIPCLF working group has defined a Common Log Format (CLF) framework for Session Initiation Protocol (SIP) servers. This CLF mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP CLF that retains the key advantages of a text-based format while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF information model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record.

 draft-ietf-sipclf-format-11 RFC7355 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipclf 10.17487/RFC6873 RFC6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers B. Carpenter S. Cheshire R. Hinden February 2013 ASCII HTML 10

This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly.

 draft-ietf-6man-uri-zoneid-06 RFC3986 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6874 10.17487/RFC6874 RFC6875 The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan S. Kamei T. Momose T. Inoue T. Nishitani February 2013 ASCII HTML 18 overlay network content delivery network peer-to-peer traffic engineering experiments in Japan

This document describes experiments that clarify how an approach similar to Application-Layer Traffic Optimization (ALTO) was effective in reducing network traffic. These experiments were performed in Japan by the P2P Network Experiment Council in an attempt to harmonize peer-to-peer (P2P) technology with network infrastructure. Based on what was learned from these experiments, this document provides some suggestions that might be useful for the ALTO architecture and especially for application-independent ALTO- like server operation.

 draft-kamei-p2p-experiments-japan-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6875 RFC6876 A Posture Transport Protocol over TLS (PT-TLS) P. Sangster N. Cam-Winget J. Salowey February 2013 ASCII HTML 44 Network Endpoint Assessment NEA

This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel.

 draft-ietf-nea-pt-tls-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea 10.17487/RFC6876 RFC6877 464XLAT: Combination of Stateful and Stateless Translation M. Mawatari M. Kawashima C. Byrne April 2013 ASCII HTML 14 XLAT Stateful Translation Stateless Translation

This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation.

 draft-ietf-v6ops-464xlat-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6877 RFC6878 IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field A.B. Roach March 2013 ASCII HTML 3

This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field. It updates RFC 3261.

 draft-ietf-sipcore-priority-00 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6878 10.17487/RFC6878 RFC6879 IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods S. Jiang B. Liu B. Carpenter February 2013 ASCII HTML 17

This document analyzes events that cause renumbering and describes the current renumbering methods. These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation.

 draft-ietf-6renum-enterprise-06 INFORMATIONAL INFORMATIONAL IETF ops 6renum 10.17487/RFC6879 RFC6880 An Information Model for Kerberos Version 5 L. Johansson March 2013 ASCII HTML 14 kerberos kdc LDAP schema

This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a Kerberos 5 Key Distribution Center (KDC). This document describes the services exposed by an administrative interface to a KDC.

 draft-ietf-krb-wg-kdc-model-16 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6880 RFC6881 Best Current Practice for Communications Services in Support of Emergency Calling B. Rosen J. Polk March 2013 ASCII HTML 28 SIP emergency emergency calls emergency call emergency calling 9-1-1 1-1-2 ecrit

The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls.

 draft-ietf-ecrit-phonebcp-20 RFC7840 RFC7852 BCP0181 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai ecrit 10.17487/RFC6881 RFC6882 Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs) K. Kumaki Editor T. Murai D. Cheng S. Matsushima P. Jiang March 2013 ASCII HTML 15

IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS, and a single Provider Edge (PE) node may provide access to multiple customer sites belonging to different VPNs.

The VPNs may support a number of customer services, including RSVP and Resource Reservation Protocol Traffic Engineering (RSVP-TE) traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs and labels are not used to identify VPNs between PEs.

 draft-kumaki-murai-l3vpn-rsvp-te-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6882 RFC6883 IPv6 Guidance for Internet Content Providers and Application Service Providers B. Carpenter S. Jiang March 2013 ASCII HTML 24

This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers or to any enterprise network preparing for IPv6 users.

 draft-ietf-v6ops-icp-guidance-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6883 RFC6884 RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) Z. Fang March 2013 ASCII HTML 21 EVRC-WB EVRC-B

This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as email.

 draft-ietf-avt-rtp-evrc-nw-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6884 RFC6885 Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS) M. Blanchet A. Sullivan March 2013 ASCII HTML 34

If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode code points in those strings requires they be prepared somehow. Internationalizing Domain Names in Applications (here called IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated, or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement.

 draft-ietf-precis-problem-statement-09 INFORMATIONAL INFORMATIONAL IETF app precis 10.17487/RFC6885 RFC6886 NAT Port Mapping Protocol (NAT-PMP) S. Cheshire M. Krochmal April 2013 ASCII HTML 33

This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it. From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol (PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements.

 draft-cheshire-nat-pmp-07 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6886 10.17487/RFC6886 RFC6887 Port Control Protocol (PCP) D. Wing Editor S. Cheshire M. Boucadair R. Penno P. Selkirk April 2013 ASCII HTML 88 NAT Firewall

The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.

 draft-ietf-pcp-base-29 RFC7488 RFC7652 RFC7843 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp http://www.rfc-editor.org/errata_search.php?rfc=6887 10.17487/RFC6887 RFC6888 Common Requirements for Carrier-Grade NATs (CGNs) S. Perreault Editor I. Yamagata S. Miyakawa A. Nakagawa H. Ashida April 2013 ASCII HTML 15 CGN NAT

This document defines common requirements for Carrier-Grade NATs (CGNs). It updates RFC 4787.

 draft-ietf-behave-lsn-requirements-10 RFC4787 BCP0127 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC6888 RFC6889 Analysis of Stateful 64 Translation R. Penno T. Saxena M. Boucadair S. Sivakumar April 2013 ASCII HTML 15 NAT64 DNS64 NAT-PT ALG (Application Layer Gateway) NAT traversal IPv4-IPv6 interconnection IPv4-IPv6 translation

Due to specific problems, Network Address Translation - Protocol Translation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT.

 draft-ietf-behave-64-analysis-07 INFORMATIONAL INFORMATIONAL IETF tsv behave 10.17487/RFC6889 RFC6890 Special-Purpose IP Address Registries M. Cotton L. Vegoda R. Bonica Editor B. Haberman April 2013 ASCII HTML 23 Internet Protocol space assignments

This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block.

 draft-bonica-special-purpose-07 RFC4773 RFC5156 RFC5735 RFC5736 RFC8190 BCP0153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6890 10.17487/RFC6890 RFC6891 Extension Mechanisms for DNS (EDNS(0)) J. Damas M. Graff P. Vixie April 2013 ASCII HTML 16 DNS extensions domain name system resource records opt

The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.

This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.

 draft-ietf-dnsext-rfc2671bis-edns0-10 RFC2671 RFC2673 STD0075 INTERNET STANDARD INTERNET STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=6891 10.17487/RFC6891 RFC6892 The 'describes' Link Relation Type E. Wilde March 2013 ASCII HTML 5

This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource. In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type.

 draft-wilde-describes-link-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6892 RFC6893 A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF) P. Higgs P. Szucs March 2013 ASCII HTML 8

This document describes a Uniform Resource Name (URN) namespace for the Open IPTV Forum (OIPF) for naming persistent resources defined within OIPF specifications. Example resources include technical documents and specifications, eXtensible Markup Language (XML) schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the OIPF.

 draft-higgs-oipf-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6893 RFC6894 Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection R. Papneja S. Vapiwala J. Karthik S. Poretsky S. Rao JL. Le Roux March 2013 ASCII HTML 35

This document describes the methodology for benchmarking MPLS Fast Reroute (FRR) protection mechanisms for link and node protection. This document provides test methodologies and testbed setup for measuring failover times of Fast Reroute techniques while considering factors (such as underlying links) that might impact recovery times for real-time applications bound to MPLS Traffic Engineered (MPLS-TE) tunnels.

 draft-ietf-bmwg-protection-meth-14 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6894 RFC6895 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd April 2013 ASCII HTML 19 RRTYPE RCODE AFSDB

This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.

 draft-ietf-dnsext-rfc6195bis-05 RFC6195 RFC1183 RFC2845 RFC2930 RFC3597 BCP0042 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC6895 RFC6896 SCS: KoanLogic's Secure Cookie Sessions for HTTP S. Barbato S. Dorigotti T. Fossati Editor March 2013 ASCII HTML 23 HTTP Secure Cookies

This memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin-timestamped tokens. It also describes one possible usage of such tokens via a simple protocol based on HTTP cookies.

Secure Cookie Session (SCS) use cases cover a wide spectrum of applications, ranging from distribution of authorized content via HTTP (e.g., with out-of-band signed URIs) to securing browser sessions with diskless embedded devices (e.g., Small Office, Home Office (SOHO) routers) or web servers with high availability or load- balancing requirements that may want to delegate the handling of the application state to clients instead of using shared storage or forced peering.

 draft-secure-cookie-session-protocol-09 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6896 10.17487/RFC6896 RFC6897 Multipath TCP (MPTCP) Application Interface Considerations M. Scharf A. Ford March 2013 ASCII HTML 31

Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface that is a simple extension of TCP's interface for MPTCP-aware applications.

 draft-ietf-mptcp-api-07 INFORMATIONAL INFORMATIONAL IETF tsv mptcp 10.17487/RFC6897 RFC6898 Link Management Protocol Behavior Negotiation and Configuration Modifications D. Li D. Ceccarelli L. Berger March 2013 ASCII HTML 11 LMP

The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in networks controlled by Generalized Multiprotocol Label Switching (GMPLS). This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations.

This document updates RFC 4204, RFC 4207, RFC 4209, and RFC 5818.

 draft-ietf-ccamp-lmp-behavior-negotiation-11 RFC4204 RFC4207 RFC4209 RFC5818 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6898 RFC6899 RFC6900 RFC6901 JavaScript Object Notation (JSON) Pointer P. Bryan Editor K. Zyp M. Nottingham Editor April 2013 ASCII HTML 8

JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document.

 draft-ietf-appsawg-json-pointer-09 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6901 10.17487/RFC6901 RFC6902 JavaScript Object Notation (JSON) Patch P. Bryan Editor M. Nottingham Editor April 2013 ASCII HTML 18

JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation (JSON) document; it is suitable for use with the HTTP PATCH method. The "application/json-patch+json" media type is used to identify such patch documents.

 draft-ietf-appsawg-json-patch-10 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6902 10.17487/RFC6902 RFC6903 Additional Link Relation Types J. Snell March 2013 ASCII HTML 6 http link rel

This specification defines a number of additional link relation types that can used for a range of purposes in a variety of applications types.

 draft-snell-additional-link-relations-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6903 RFC6904 Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) J. Lennox April 2013 ASCII HTML 15 real-time transport protocol rtp header extensions security

The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.

This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted.

 draft-ietf-avtcore-srtp-encrypted-header-ext-05 RFC3711 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6904 RFC6905 Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) T. Senevirathne D. Bond S. Aldrin Y. Li R. Watve March 2013 ASCII HTML 13

Operations, Administration, and Maintenance (OAM) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents OAM requirements applicable to the Transparent Interconnection of Lots of Links (TRILL).

 draft-ietf-trill-oam-req-05 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC6905 RFC6906 The 'profile' Link Relation Type E. Wilde March 2013 ASCII HTML 8 application profile profile identifier

This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms.

 draft-wilde-profile-link-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6906 RFC6907 Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties T. Manderson K. Sriram R. White March 2013 ASCII HTML 31 Prefix origin validation Routing security BGP security

This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system.

 draft-ietf-sidr-usecases-06 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC6907 RFC6908 Deployment Considerations for Dual-Stack Lite Y. Lee R. Maglione C. Williams C. Jacquenet M. Boucadair March 2013 ASCII HTML 14

This document discusses the deployment issues of and the requirements for the deployment and operation of Dual-Stack Lite (DS-Lite). This document describes the various deployment considerations and applicability of the DS-Lite architecture.

 draft-ietf-softwire-dslite-deployment-08 INFORMATIONAL INFORMATIONAL IETF int softwire 10.17487/RFC6908 RFC6909 IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 S. Gundavelli Editor X. Zhou J. Korhonen G. Feige R. Koodli April 2013 ASCII HTML 14

This specification defines a new mobility option, the IPv4 Traffic Offload Selector option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating IPv4 traffic offload policy for a mobility session. Based on the negotiated IPv4 traffic offload policy, a mobile access gateway can selectively offload some of the IPv4 traffic flows in the access network instead of tunneling back to the local mobility anchor in the home network.

 draft-ietf-netext-pmipv6-sipto-option-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6909 RFC6910 Completion of Calls for the Session Initiation Protocol (SIP) D. Worley M. Huelsemann R. Jesske D. Alexeitsev April 2013 ASCII HTML 37 call completion CC SS7 Signaling System 7 purpose header parameter m URI parameter m header parameter call-completion event package, CCBS CCNR CCNL Call-Info header field Presence Information Data Format PIDF P-Asserted-Identity header field

The "completion of calls" feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call.

For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'Automatic Redial' in "Session Initiation Protocol Service Examples" (RFC 5359).

For the realization of a more comprehensive solution with queuing, this document introduces an architecture for implementing these features in the Session Initiation Protocol where "completion of calls" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for completion of calls into a queue at the callee's endpoint; when a caller's request is ready to be serviced, re-attempt of the original, failed call is then made.

The architecture is designed to interoperate well with existing completion of calls solutions in other networks.

 draft-ietf-bliss-call-completion-19 PROPOSED STANDARD PROPOSED STANDARD IETF rai bliss 10.17487/RFC6910 RFC6911 RADIUS Attributes for IPv6 Access Networks W. Dec Editor B. Sarikaya G. Zorn Editor D. Miles B. Lourdelet April 2013 ASCII HTML 15 AAA RADIUS IPv6

This document specifies additional IPv6 RADIUS Attributes useful in residential broadband network deployments. The Attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and an IPv6 DNS server address via DHCPv6, assignment of an IPv6 route announced via router advertisement, assignment of a named IPv6 delegated prefix pool, and assignment of a named IPv6 pool for host DHCPv6 addressing.

 draft-ietf-radext-ipv6-access-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC6911 RFC6912 Principles for Unicode Code Point Inclusion in Labels in the DNS A. Sullivan D. Thaler J. Klensin O. Kolkman April 2013 ASCII HTML 12

Internationalized Domain Names in Applications (IDNA) makes available to DNS zone administrators a very wide range of Unicode code points. Most operators of zones should probably not permit registration of U-labels using the entire range. This is especially true of zones that accept registrations across organizational boundaries, such as top-level domains and, most importantly, the root. It is unfortunately not possible to generate algorithms to determine whether permitting a code point presents a low risk. This memo presents a set of principles that can be used to guide the decision of whether a Unicode code point may be wisely included in the repertoire of permissible code points in a U-label in a zone.

 draft-iab-dns-zone-codepoint-pples-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6912 RFC6913 Indicating Fax over IP Capability in the Session Initiation Protocol (SIP) D. Hanes G. Salgueiro K. Fleming March 2013 ASCII HTML 9 media feature tag

This document defines and registers with IANA the new "fax" media feature tag for use with the Session Initiation Protocol (SIP). Currently, fax calls are indistinguishable from voice calls at call initiation. Consequently, fax calls can be routed to SIP user agents that are not fax capable. A "fax" media feature tag implemented in conjunction with caller preferences allows for more accurate fax call routing.

 draft-hanes-dispatch-fax-capability-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6913 RFC6914 SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP) J. Rosenberg April 2013 ASCII HTML 15 SIP SIMPLE presence IM

The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE). This document serves as a guide to the SIMPLE suite of specifications. It categorizes the specifications, explains what each is for, and how they relate to each other.

 draft-ietf-simple-simple-09 INFORMATIONAL INFORMATIONAL IETF rai simple 10.17487/RFC6914 RFC6915 Flow Identity Extension for HTTP-Enabled Location Delivery (HELD) R. Bellis April 2013 ASCII HTML 9 HELD Flow

RFC 6155 specifies an extension for the HTTP-Enabled Location Delivery (HELD) protocol, allowing the use of an IP address and port number to request a Device location based on an individual packet flow.

However, certain kinds of NAT require that identifiers for both ends of the packet flow must be specified in order to unambiguously satisfy the location request.

This document specifies an XML Schema and a URN Sub-Namespace for a Flow Identity Extension for HELD to support this requirement.

This document updates RFC 6155 by deprecating the port number elements specified therein.

 draft-ietf-geopriv-flow-identity-02 RFC6155 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6915 RFC6916 Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI) R. Gagliano S. Kent S. Turner April 2013 ASCII HTML 20 Resource Public Key Infrastructure RPKI Algorithm Transition SIDR routing security BGP security

This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children).

 draft-ietf-sidr-algorithm-agility-12 BCP0182 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC6916 RFC6917 Media Resource Brokering C. Boulton L. Miniero G. Munson April 2013 ASCII HTML 136

The MediaCtrl working group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signaling protocol that provides many inherent capabilities for message routing. In addition to such signaling properties, a need exists for intelligent, application-level media service selection based on non-static signaling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity, which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers.

 draft-ietf-mediactrl-mrb-19 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl 10.17487/RFC6917 RFC6918 Formally Deprecating Some ICMPv4 Message Types F. Gont C. Pignataro April 2013 ASCII HTML 8 IANA IPv4 Options

A number of ICMPv4 message types have become obsolete in practice, but have never been formally deprecated. This document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry. Additionally, it updates RFC 792 and RFC 950, obsoletes RFC 1788, and requests the RFC Editor to change the status of RFC 1788 to Historic.

 draft-gp-obsolete-icmp-types-iana-01 RFC1788 RFC0792 RFC0950 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6918 RFC6919 Further Key Words for Use in RFCs to Indicate Requirement Levels R. Barnes S. Kent E. Rescorla April 1 2013 ASCII HTML 6

RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:

The key words "MUST (BUT WE KNOW YOU WON\'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.

 draft-barnes-2119bis-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6919 RFC6920 Naming Things with Hashes S. Farrell D. Kutscher C. Dannewitz B. Ohlman A. Keranen P. Hallam-Baker April 2013 ASCII HTML 23 Cryptography URI Information Centric Networking

This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.

 draft-farrell-decade-ni-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6920 10.17487/RFC6920 RFC6921 Design Considerations for Faster-Than-Light (FTL) Communication R. Hinden April 1 2013 ASCII HTML 7

We are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues.

 draft-hinden-FTL-design-considerations-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6921 10.17487/RFC6921 RFC6922 The application/sql Media Type Y. Shafranovich April 2013 ASCII HTML 5 SQL MIME

This document registers the application/sql media type to be used for the Structured Query Language (SQL).

 draft-shafranovich-mime-sql-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6922 RFC6923 MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions R. Winter E. Gray H. van Helvoort M. Betts May 2013 ASCII HTML 12

This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T).

 draft-ietf-mpls-tp-itu-t-identifiers-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6923 RFC6924 Registration of Second-Level URN Namespaces under "ietf" B. Leiba April 2013 ASCII HTML 4

RFC 2648 defines the "ietf" URN namespace and a number of sub- namespaces. RFC 3553 defines an additional sub-namespace, "params", and creates a registry to document allocations under that. But there is no registry that lists, in one place, all sub-namespaces of "ietf". This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub- namespaces of "ietf".

 draft-leiba-urnbis-ietf-namespace-02 RFC2648 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6924 RFC6925 The DHCPv4 Relay Agent Identifier Sub-Option B. Joshi R. Desetti M. Stapp April 2013 ASCII HTML 8 DHCP relay

This document defines a new Relay Agent Identifier sub-option for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information option. The sub-option carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively configured in the relay agent. The sub-option allows a DHCP relay agent to include the identifier in the DHCP messages it sends.

 draft-ietf-dhc-relay-id-suboption-13 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6925 RFC6926 DHCPv4 Bulk Leasequery K. Kinnear M. Stapp R. Desetti B. Joshi N. Russell P. Kurapati B. Volz April 2013 ASCII HTML 41

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings. This protocol is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP.

 draft-ietf-dhc-dhcpv4-bulk-leasequery-07 RFC7724 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6926 RFC6927 Variants in Second-Level Names Registered in Top-Level Domains J. Levine P. Hoffman May 2013 ASCII HTML 18 DNS variant TLDs

Internationalized Domain Names for Applications (IDNA) provides a method to map a subset of names written in Unicode into the DNS. Because of Unicode decisions, appearance, language and writing system conventions, and historical reasons, it often has been asserted that there is more than one way to write what competent readers and writers think of as the same host name; these different ways of writing are often called "variants". (The authors note that there are many conflicting definitions for the term "variant" in the IDNA community.) This document surveys the approaches that top-level domains have taken to the registration and provisioning of domain names that have variants. This document is not a product of the IETF, does not propose any method to make variants work "correctly", and is not an introduction to internationalization or IDNA.

 draft-levine-tld-variant-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6927 RFC6928 Increasing TCP's Initial Window J. Chu N. Dukkipati Y. Cheng M. Mathis April 2013 ASCII HTML 24

This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.

 draft-ietf-tcpm-initcwnd-08 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC6928 RFC6929 Remote Authentication Dial In User Service (RADIUS) Protocol Extensions A. DeKok A. Lior April 2013 ASCII HTML 68

The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems.

 draft-ietf-radext-radius-extensions-13 RFC2865 RFC3575 RFC6158 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC6929 RFC6930 RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) D. Guo S. Jiang Editor R. Despres R. Maglione April 2013 ASCII HTML 12

The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs.

 draft-ietf-softwire-6rd-radius-attrib-11 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=6930 10.17487/RFC6930 RFC6931 Additional XML Security Uniform Resource Identifiers (URIs) D. Eastlake 3rd April 2013 ASCII HTML 36

This document expands, updates, and establishes an IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051.

 draft-eastlake-additional-xmlsec-uris-10 RFC4051 RFC9231 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6931 10.17487/RFC6931 RFC6932 Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry D. Harkins Editor May 2013 ASCII HTML 12 elliptic curve Diffie-Hellman

This memo allocates code points for four new elliptic curve domain parameter sets over finite prime fields into a registry that was established by the Internet Key Exchange (IKE) but is used by other protocols.

 draft-harkins-brainpool-ike-groups-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6932 RFC6933 Entity MIB (Version 4) A. Bierman D. Romascanu J. Quittek M. Chandramouli May 2013 ASCII HTML 76 management information base snmp simple network management protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single Simple Network Management Protocol (SNMP) agent. This document specifies version 4 of the Entity MIB. This memo obsoletes version 3 of the Entity MIB module published as RFC 4133.

 draft-ietf-eman-rfc4133bis-06 RFC4133 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman http://www.rfc-editor.org/errata_search.php?rfc=6933 10.17487/RFC6933 RFC6934 Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs) N. Bitar Editor S. Wadhwa Editor T. Haag H. Li June 2013 ASCII HTML 39

The purpose of this document is to provide applicability of the Access Node Control Mechanism to broadband access based on Passive Optical Networks (PONs). The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex, composed of a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements, is described in a multi-service reference architecture in order to perform QoS-related, service-related, and subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control Mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses direct device-to-device communication and stays on net. This allows for performing access-link-related operations within those network elements to meet performance objectives.

 draft-ietf-ancp-pon-05 INFORMATIONAL INFORMATIONAL IETF int ancp 10.17487/RFC6934 RFC6935 IPv6 and UDP Checksums for Tunneled Packets M. Eubanks P. Chimento M. Westerlund April 2013 ASCII HTML 12 Tunnel Encapsulation Integrity Packet Corruption Middlebox

This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method.

 draft-ietf-6man-udpchecksums-08 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6935 10.17487/RFC6935 RFC6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums G. Fairhurst M. Westerlund April 2013 ASCII HTML 40

This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6.

 draft-ietf-6man-udpzero-12 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6936 10.17487/RFC6936 RFC6937 Proportional Rate Reduction for TCP M. Mathis N. Dukkipati Y. Cheng May 2013 ASCII HTML 16 TCP loss recovery packet conservation self clock

This document describes an experimental Proportional Rate Reduction (PRR) algorithm as an alternative to the widely deployed Fast Recovery and Rate-Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm.

 draft-ietf-tcpm-proportional-rate-reduction-04 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC6937 RFC6938 Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID J. Scudder May 2013 ASCII HTML 3 BGP

This document requests IANA to deprecate the following BGP path attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet-Draft and a Historic RFC.

 draft-ietf-idr-deprecate-dpa-etal-00 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC6938 RFC6939 Client Link-Layer Address Option in DHCPv6 G. Halwasia S. Bhandari W. Dec May 2013 ASCII HTML 7

This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option.

 draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6939 RFC6940 REsource LOcation And Discovery (RELOAD) Base Protocol C. Jennings B. Lowekamp Editor E. Rescorla S. Baset H. Schulzrinne January 2014 ASCII HTML 176 p2p dht p2psip chord peer to peer

This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the Kinds of data that need to be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.

 draft-ietf-p2psip-base-26 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip http://www.rfc-editor.org/errata_search.php?rfc=6940 10.17487/RFC6940 RFC6941 MPLS Transport Profile (MPLS-TP) Security Framework L. Fang Editor B. Niven-Jenkins Editor S. Mansfield Editor R. Graveman Editor April 2013 ASCII HTML 15 threats mitigation defensive techniques

This document provides a security framework for the MPLS Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new Operations, Administration, and Maintenance (OAM) capabilities, a transport-oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats as well as mitigation procedures related to MPLS-TP networks and to MPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC 5920 ("Security Framework for MPLS and GMPLS Networks") by providing additional security considerations that are applicable to the MPLS-TP extensions. All the security considerations from RFC 5920 are assumed to apply.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionality of a packet transport network.

 draft-ietf-mpls-tp-security-framework-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6941 RFC6942 Diameter Support for the EAP Re-authentication Protocol (ERP) J. Bournelle L. Morand S. Decugis Q. Wu G. Zorn May 2013 ASCII HTML 18

The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re-authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new Attribute-Value Pairs (AVPs) that can be used to transport the cryptographic material needed by the re-authentication server.

 draft-ietf-dime-erp-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6942 RFC6943 Issues in Identifier Comparison for Security Purposes D. Thaler Editor May 2013 ASCII HTML 26 Canonicalization Normalization Hostname URI IRI

Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols.

 draft-iab-identifier-comparison-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6943 RFC6944 Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status S. Rose April 2013 ASCII HTML 7

The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933.

 draft-ietf-dnsext-dnssec-algo-imp-status-04 RFC8624 RFC2536 RFC2539 RFC3110 RFC4034 RFC4398 RFC5155 RFC5702 RFC5933 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=6944 10.17487/RFC6944 RFC6945 Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol R. Bush B. Wijnen K. Patel M. Baer May 2013 ASCII HTML 25

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the Resource Public Key Infrastructure (RPKI) to Router Protocol.

 draft-ietf-sidr-rpki-rtr-protocol-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6945 RFC6946 Processing of IPv6 "Atomic" Fragments F. Gont May 2013 ASCII HTML 9 fragmentation attacks vulnerabilities atomic fragments

The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets are typically sent by hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by some implementations as normal "fragmented traffic" (i.e., they are "reassembled" with any other queued fragments that supposedly correspond to the same original packet). Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 "Packet Too Big" error messages, and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications. Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector.

 draft-ietf-6man-ipv6-atomic-fragments-04 RFC2460 RFC5722 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6946 10.17487/RFC6946 RFC6947 The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute M. Boucadair H. Kaplan R. Gilman S. Veikkolainen May 2013 ASCII HTML 24

This document proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the "altc" attribute, solves the backward-compatibility problem that plagued Alternative Network Address Types (ANAT) due to their syntax.

The proposed solution is applicable to scenarios where connectivity checks are not required. If connectivity checks are required, Interactive Connectivity Establishment (ICE), as specified in RFC 5245, provides such a solution.

 draft-boucadair-mmusic-altc-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6947 RFC6948 Some Measurements on World IPv6 Day from an End-User Perspective A. Keranen J. Arkko July 2013 ASCII PDF HTML 11

During World IPv6 Day on June 8, 2011, several key content providers enabled their networks to offer both IPv4 and IPv6 services. Hundreds of organizations participated in this effort, and in the months and weeks leading up to the event worked hard on preparing their networks to support this event. The event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected. For the Internet, however, there was a major change on a short timescale. This memo discusses measurements that the authors made from the perspective of an end user with good IPv4 and IPv6 connectivity. Our measurements include the number of most popular networks providing AAAA records for their service, as well as delay and connection failure statistics.

 draft-keranen-ipv6day-measurements-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6948 RFC6949 RFC Series Format Requirements and Future Development H. Flanagan N. Brownlee May 2013 ASCII HTML 14

This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. The requirements described in this document will determine what changes will be made to RFC format. This document updates RFC 2223.

 draft-iab-rfcformatreq-03 RFC2223 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6949 RFC6950 Architectural Considerations on Application Features in the DNS J. Peterson O. Kolkman H. Tschofenig B. Aboba October 2013 ASCII HTML 31

A number of Internet applications rely on the Domain Name System (DNS) to support their operations. Many applications use the DNS to locate services for a domain; some, for example, transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS. Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform. This document explores the architectural consequences of using the DNS to implement certain application features, and it provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered.

 draft-iab-dns-applications-07 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6950 RFC6951 UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication M. Tuexen R. Stewart May 2013 ASCII HTML 12

This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges.

Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document.

This document covers only end-hosts and not tunneling (egress or ingress) endpoints.

 draft-ietf-tsvwg-sctp-udp-encaps-14 RFC8899 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6951 RFC6952 Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide M. Jethanandani K. Patel L. Zheng May 2013 ASCII HTML 17 key authentication routing DoS

This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518.

 draft-ietf-karp-routing-tcp-analysis-07 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6952 RFC6953 Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements A. Mancuso Editor S. Probasco B. Patil May 2013 ASCII HTML 23

Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. This document includes the problem statement for the development of a protocol to access a database of white-space information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented.

 draft-ietf-paws-problem-stmt-usecases-rqmts-15 INFORMATIONAL INFORMATIONAL IETF app paws 10.17487/RFC6953 RFC6954 Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2) J. Merkle M. Lochter July 2013 ASCII HTML 11 IKE Elliptic Curve

This document specifies use of the Elliptic Curve Cryptography (ECC) Brainpool elliptic curve groups for key exchange in the Internet Key Exchange Protocol version 2 (IKEv2).

 draft-merkle-ikev2-ke-brainpool-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6954 RFC6955 Diffie-Hellman Proof-of-Possession Algorithms J. Schaad H. Prafullchandra May 2013 ASCII HTML 43 POP ECDH DH

This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm.

This document obsoletes RFC 2875.

 draft-schaad-pkix-rfc2875-bis-08 RFC2875 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6955 RFC6956 Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library W. Wang E. Haleplidis K. Ogawa C. Li J. Halpern June 2013 ASCII HTML 111 ForCES LFB Library

This document defines basic classes of Logical Function Blocks (LFBs) used in Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to the ForCES Forwarding Element (FE) model and ForCES protocol specifications; they are scoped to meet requirements of typical router functions and are considered the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions.

 draft-ietf-forces-lfb-lib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=6956 10.17487/RFC6956 RFC6957 Duplicate Address Detection Proxy F. Costa J-M. Combes Editor X. Pougnard H. Li June 2013 ASCII HTML 16 IPv6 SLAAC DAD SAVI

The document describes a proxy-based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g., VLAN). When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address.

 draft-ietf-6man-dad-proxy-07 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6957 RFC6958 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting A. Clark S. Zhang J. Zhao Q. Wu Editor May 2013 ASCII HTML 16 Real Time Control Protocol

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows the reporting of burst and gap loss metrics for use in a range of RTP applications.

 draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock http://www.rfc-editor.org/errata_search.php?rfc=6958 10.17487/RFC6958 RFC6959 Source Address Validation Improvement (SAVI) Threat Scope D. McPherson F. Baker J. Halpern May 2013 ASCII HTML 25

The Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work.

 draft-ietf-savi-threat-scope-08 INFORMATIONAL INFORMATIONAL IETF int savi 10.17487/RFC6959 RFC6960 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP S. Santesson M. Myers R. Ankney A. Malpani S. Galperin C. Adams June 2013 ASCII HTML 41 PKIX digital security ocsp

This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.

 draft-ietf-pkix-rfc2560bis-20 RFC2560 RFC6277 RFC5912 RFC8954 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=6960 10.17487/RFC6960 RFC6961 The Transport Layer Security (TLS) Multiple Certificate Status Request Extension Y. Pettersen June 2013 ASCII HTML 10 RFC 6066 RFC 2560 RFC 6960 RFC 5246 OCSP OCSP stapling multi-stapling certificate status checking revocation information status_request status_request_v2

This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.

 draft-ietf-tls-multiple-cert-status-extension-08 RFC8446 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=6961 10.17487/RFC6961 RFC6962 Certificate Transparency B. Laurie A. Langley E. Kasper June 2013 ASCII HTML 27 TLS certificates

This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.

Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.

 draft-laurie-pki-sunlight-12 RFC9162 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6962 10.17487/RFC6962 RFC6963 A Uniform Resource Name (URN) Namespace for Examples P. Saint-Andre May 2013 ASCII HTML 7 URN examples documentation

This document defines a Uniform Resource Name (URN) namespace identifier enabling the generation of URNs that are appropriate for use in documentation and in URN-related testing and experimentation.

 draft-saintandre-urn-example-05 BCP0183 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6963 RFC6964 Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) F. Templin May 2013 ASCII HTML 20 IPv6 IPv4 IPv6/IPv4 IPv6-in-IPv4 tunnel automatic isatap enterprise site

Many end-user sites in the Internet today still have predominantly IPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 provides satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed, however, end-user devices within such sites will increasingly require at least basic IPv6 functionality. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).

 draft-templin-v6ops-isops-19 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6964 RFC6965 MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design L. Fang Editor N. Bitar R. Zhang M. Daikoku P. Pan August 2013 ASCII HTML 16

This document describes the applicability of the MPLS Transport Profile (MPLS-TP) with use case studies and network design considerations. The use cases include Metro Ethernet access and aggregation transport, mobile backhaul, and packet optical transport.

 draft-ietf-mpls-tp-use-cases-and-design-08 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6965 RFC6966 RFC6967 Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments M. Boucadair J. Touch P. Levis R. Penno June 2013 ASCII HTML 24 NAT Host Identifier

This document is a collection of potential solutions for revealing a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort packets according to the sending host. The host identifier must be unique to each host under the same shared IP address.

This document analyzes a set of potential solutions for revealing a host identifier and does not recommend a particular solution, although it does highlight the hazards of some approaches.

 draft-ietf-intarea-nat-reveal-analysis-10 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC6967 RFC6968 FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols V. Roca B. Adamson July 2013 ASCII HTML 40

This document introduces the FCAST reliable object (e.g., file) delivery application. It is designed to operate either on top of the underlying Asynchronous Layered Coding (ALC) / Layered Coding Transport (LCT) reliable multicast transport protocol or the NACK-Oriented Reliable Multicast (NORM) transport protocol.

 draft-ietf-rmt-fcast-08 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC6968 RFC6969 OSPFv3 Instance ID Registry Update A. Retana D. Cheng July 2013 ASCII HTML 4

This document modifies the "Unassigned" number space in the IANA "OSPFv3 Instance ID Address Family Values" registry by dividing it in two halves -- one half Unassigned but managed via Standards Action, and the other Reserved for Private Use. It updates RFC 5838.

 draft-ietf-ospf-ospfv3-iid-registry-update-04 RFC5838 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6969 10.17487/RFC6969 RFC6970 Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF) M. Boucadair R. Penno D. Wing July 2013 ASCII HTML 23 UPnP pinhole PCP mapping NAT control interworking

This document specifies the behavior of the Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF). A UPnP IGD-PCP IWF is required to be embedded in Customer Premises (CP) routers to allow for transparent NAT control in environments where a UPnP IGD is used on the LAN side and PCP is used on the external side of the CP router.

 draft-ietf-pcp-upnp-igd-interworking-10 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC6970 RFC6971 Depth-First Forwarding (DFF) in Unreliable Networks U. Herberg Editor A. Cardenas T. Iwao M. Dow S. Cespedes June 2013 ASCII HTML 41 DFF Depth first forwarding IPv6 Forwarding plane Lossy networks Reliability

This document specifies the Depth-First Forwarding (DFF) protocol for IPv6 networks, a data-forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links. The protocol operates entirely on the forwarding plane but may interact with the routing plane. DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet. The routing plane may be informed of failures to deliver a packet or loops. This document specifies the DFF mechanism both for IPv6 networks (as specified in RFC 2460) and for "mesh-under" Low-Power Wireless Personal Area Networks (LoWPANs), as specified in RFC 4944. The design of DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the Next Hop or not. It is applicable for networks with little traffic and is used for unicast transmissions only.

 draft-cardenas-dff-14 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6971 10.17487/RFC6971 RFC6972 Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP) Y. Zhang N. Zong July 2013 ASCII HTML 22 P2P

Peer-to-Peer (P2P) streaming systems becoming more and more popular on the Internet, and most of them are using proprietary protocols. This document identifies problems associated with proprietary protocols; proposes the development of the Peer-to-Peer Streaming Protocol (PPSP), which includes the tracker and peer protocols; and discusses the scope, requirements, and use cases of PPSP.

 draft-ietf-ppsp-problem-statement-15 INFORMATIONAL INFORMATIONAL IETF tsv ppsp 10.17487/RFC6972 RFC6973 Privacy Considerations for Internet Protocols A. Cooper H. Tschofenig B. Aboba J. Peterson J. Morris M. Hansen R. Smith July 2013 ASCII HTML 36 Disclosure Anonymity Pseudonymity Confidentiality Identity

This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.

 draft-iab-privacy-considerations-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6973 RFC6974 Applicability of MPLS Transport Profile for Ring Topologies Y. Weingarten S. Bryant D. Ceccarelli D. Caviglia F. Fondelli M. Corsi B. Wu X. Dai July 2013 ASCII HTML 30

This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to the MPLS Transport Profile (MPLS-TP) in ring topologies. This document does not propose any new mechanisms or protocols. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372). This document discusses how most of the requirements are met by applying linear protection as defined in RFC 6378 in a ring topology.

 draft-ietf-mpls-tp-ring-protection-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6974 RFC6975 Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC) S. Crocker S. Rose July 2013 ASCII HTML 9 DNS DNSSEC EDNS

The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This document specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. The extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in a DNSSEC-signed zone.

 draft-ietf-dnsext-dnssec-algo-signal-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6975 RFC6976 Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach M. Shand S. Bryant S. Previdi C. Filsfils P. Francois O. Bonaventure July 2013 ASCII HTML 28

This document describes an illustrative framework of a mechanism for use in conjunction with link-state routing protocols that prevents the transient loops that would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers.

This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a fast reroute mechanism that converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations.

After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described.

The technology described in this document has been subject to extensive simulation using pathological convergence behavior and real network topologies and costs. However, the mechanisms described in this document are purely illustrative of the general approach and do not constitute a protocol specification. This document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.

 draft-ietf-rtgwg-ordered-fib-12 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC6976 RFC6977 Triggering DHCPv6 Reconfiguration from Relay Agents M. Boucadair X. Pougnard July 2013 ASCII HTML 13 Reconfigure-Request Reconfigure-Reply Link Address Option

This document defines two new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. The Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. The Reconfigure-Reply message is used by the server to acknowledge the receipt of the Reconfigure-Request message.

 draft-ietf-dhc-triggered-reconfigure-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6977 RFC6978 A TCP Authentication Option Extension for NAT Traversal J. Touch July 2013 ASCII HTML 6 TCP-AO

This document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through Network Address Translators and/or Network Address and Port Translators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but it does not alter TCP-AO's packet processing or key generation algorithms.

 draft-touch-tcp-ao-nat-05 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6978 RFC6979 Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) T. Pornin August 2013 ASCII HTML 79 dsa ecdsa digital signature deterministic

This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.

 draft-pornin-deterministic-dsa-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6979 10.17487/RFC6979 RFC6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery F. Gont August 2013 ASCII HTML 10 vulnerabilities evasion monitoring

This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective countermeasures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be mitigated.

 draft-ietf-6man-nd-extension-headers-05 RFC3971 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6980 RFC6981 A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses S. Bryant S. Previdi M. Shand August 2013 ASCII HTML 34 not-via

This document presents an illustrative framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described here uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics.

The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.

 draft-ietf-rtgwg-ipfrr-notvia-addresses-11 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC6981 RFC6982 Improving Awareness of Running Code: The Implementation Status Section Y. Sheffer A. Farrel July 2013 ASCII HTML 9

This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.

The process in this document is offered as an experiment. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community.

 draft-sheffer-running-code-06 RFC7942 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6982 RFC6983 Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI) R. van Brandenburg O. van Deventer F. Le Faucheur K. Leung July 2013 ASCII HTML 45 video caching HTTP content delivery

This document presents thoughts on the potential impact of supporting HTTP Adaptive Streaming (HAS) technologies in Content Distribution Network Interconnection (CDNI) scenarios. The intent is to present the authors' analysis of the CDNI-HAS problem space and discuss different options put forward by the authors (and by others during informal discussions) on how to deal with HAS in the context of CDNI. This document has been used as input information during the CDNI working group process for making a decision regarding support for HAS.

 draft-brandenburg-cdni-has-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6983 RFC6984 Interoperability Report for Forwarding and Control Element Separation (ForCES) W. Wang K. Ogawa E. Haleplidis M. Gao J. Hadi Salim August 2013 ASCII HTML 29

This document captures the results of the second Forwarding and Control Element Separation (ForCES) interoperability test that took place on February 24-25, 2011, in the Internet Technology Lab (ITL) at Zhejiang Gongshang University, China. The results of the first ForCES interoperability test were reported in RFC 6053, and this document updates RFC 6053 by providing further interoperability results.

 draft-ietf-forces-interop-09 RFC6053 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC6984 RFC6985 IMIX Genome: Specification of Variable Packet Sizes for Additional Testing A. Morton July 2013 ASCII HTML 10 Traffic Pattern Benchmarking

Benchmarking methodologies have always relied on test conditions with constant packet sizes, with the goal of understanding what network device capability has been tested. Tests with a constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, so additional tests are sometimes conducted with a mixture of packet sizes, or "IMIX" ("Internet Mix"). The mixture of sizes a networking device will encounter is highly variable and depends on many factors. An IMIX suited for one networking device and deployment will not be appropriate for another. However, the mix of sizes may be known, and the tester may be asked to augment the fixed-size tests. To address this need and the perpetual goal of specifying repeatable test conditions, this document defines a way to specify the exact repeating sequence of packet sizes from the usual set of fixed sizes and from other forms of mixed-size specification.

 draft-ietf-bmwg-imix-genome-05 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6985 RFC6986 GOST R 34.11-2012: Hash Function V. Dolmatov Editor A. Degtyarev August 2013 ASCII HTML 40

This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). This document updates RFC 5831.

 draft-dolmatov-gost34112012-01 RFC5831 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6986 RFC6987 OSPF Stub Router Advertisement A. Retana L. Nguyen A. Zinin R. White D. McPherson September 2013 ASCII HTML 7 ospf stub

This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router.

This document obsoletes RFC 3137.

 draft-ietf-ospf-rfc3137bis-04 RFC3137 RFC8770 INFORMATIONAL INFORMATIONAL IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6987 10.17487/RFC6987 RFC6988 Requirements for Energy Management J. Quittek Editor M. Chandramouli R. Winter T. Dietz B. Claise September 2013 ASCII HTML 28 monitoring functions control functions

This document defines requirements for standards specifications for Energy Management. The requirements defined in this document are concerned with monitoring functions as well as control functions. Monitoring functions include identifying energy-managed devices and their components, as well as monitoring their Power States, Power Inlets, Power Outlets, actual power, Power Attributes, received energy, provided energy, and contained batteries. Control functions include such functions as controlling power supply and Power State of energy-managed devices and their components.

This document does not specify the features that must be implemented by compliant implementations but rather lists features that must be supported by standards for Energy Management.

 draft-ietf-eman-requirements-14 INFORMATIONAL INFORMATIONAL IETF ops eman 10.17487/RFC6988 RFC6989 Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2) Y. Sheffer S. Fluhrer July 2013 ASCII HTML 10 Elliptic Curve cryptography secret key reuse recipient tests

This document adds a small number of mandatory tests required for the secure operation of the Internet Key Exchange Protocol version 2 (IKEv2) with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called Digital Signature Algorithm (DSA) groups. This document updates the IKEv2 protocol, RFC 5996.

 draft-ietf-ipsecme-dh-checks-05 RFC5996 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC6989 RFC6990 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting R. Huang Q. Wu H. Asaeda G. Zorn August 2013 ASCII HTML 11 RTCP XR MPEG2 PSI Decodability

An MPEG-2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/ multicast MPEG-2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG-2 TS decodability statistics metrics related to transmissions of MPEG-2 TS over RTP. The metrics specified in the RTCP XR block are not dependent on Program Specific Information (PSI) carried in MPEG-2 TS.

 draft-ietf-xrblock-rtcp-xr-decodability-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6990 RFC6991 Common YANG Data Types J. Schoenwaelder Editor July 2013 ASCII HTML 30 YANG data model netconf

This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.

 draft-ietf-netmod-rfc6021-bis-03 RFC6021 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6991 10.17487/RFC6991 RFC6992 Routing for IPv4-Embedded IPv6 Packets D. Cheng M. Boucadair A. Retana July 2013 ASCII HTML 15

This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on the methods described in RFCs 6145 and 6052, along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network.

 draft-ietf-ospf-ipv4-embedded-ipv6-routing-14 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC6992 RFC6993 Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) P. Saint-Andre July 2013 ASCII HTML 5 SIP Call-Info header field Instant Messaging Presence

This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP).

 draft-saintandre-impp-call-info-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6993 RFC6994 Shared Use of Experimental TCP Options J. Touch August 2013 ASCII HTML 11

This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints.

 draft-ietf-tcpm-experimental-options-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6994 RFC6995 RFC6996 Autonomous System (AS) Reservation for Private Use J. Mitchell July 2013 ASCII HTML 4 asn

This document describes the reservation of Autonomous System Numbers (ASNs) that are for Private Use only, known as Private Use ASNs, and provides operational guidance on their use. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10 of that document.

 draft-ietf-idr-as-private-reservation-05 RFC1930 BCP0006 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC6996 RFC6997 Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks M. Goyal Editor E. Baccelli M. Philipp A. Brandt J. Martocci August 2013 ASCII HTML 40 P2P Routing RPL ROLL

This document specifies a point-to-point route discovery mechanism, complementary to the Routing Protocol for Low-power and Lossy Networks (RPL) core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in a Low-power and Lossy Network (LLN) such that the discovered routes meet specified metrics constraints.

 draft-ietf-roll-p2p-rpl-17 EXPERIMENTAL EXPERIMENTAL IETF rtg roll 10.17487/RFC6997 RFC6998 A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network M. Goyal Editor E. Baccelli A. Brandt J. Martocci August 2013 ASCII HTML 29 Measurement Route Quality P2P Routes RPL ROLL

This document specifies a mechanism that enables a Routing Protocol for Low-power and Lossy Networks (RPL) router to measure the aggregated values of given routing metrics along an existing route towards another RPL router, thereby allowing the router to decide if it wants to initiate the discovery of a better route.

 draft-ietf-roll-p2p-measurement-10 EXPERIMENTAL EXPERIMENTAL IETF rtg roll 10.17487/RFC6998 RFC6999 RFC7000 RFC7001 Message Header Field for Indicating Message Authentication Status M. Kucherawy September 2013 ASCII HTML 43 DKIM DomainKeys SenderID SPF ADSP ATPS VBR Authentication Reputation

This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.

 draft-ietf-appsawg-rfc5451bis-10 RFC5451 RFC6577 RFC7601 RFC7410 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7001 10.17487/RFC7001 RFC7002 RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting A. Clark G. Zorn Q. Wu September 2013 ASCII HTML 12

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of a simple discard count metric for use in a range of RTP applications.

 draft-ietf-xrblock-rtcp-xr-discard-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7002 RFC7003 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting A. Clark R. Huang Q. Wu Editor September 2013 ASCII HTML 14 Real Time Control Protocol

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst and gap discard metrics for use in a range of RTP applications.

 draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock http://www.rfc-editor.org/errata_search.php?rfc=7003 10.17487/RFC7003 RFC7004 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting G. Zorn R. Schott Q. Wu Editor R. Huang September 2013 ASCII HTML 21 RTCP XR Summary Statistics Burst/Gap Loss Burst/Gap Discard Frame Impairment

This document defines three RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of loss, duplication, and discard summary statistics metrics in a range of RTP applications.

 draft-ietf-xrblock-rtcp-xr-summary-stat-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7004 RFC7005 RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting A. Clark V. Singh Q. Wu September 2013 ASCII HTML 14

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of de-jitter buffer metrics for a range of RTP applications.

 draft-ietf-xrblock-rtcp-xr-jb-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7005 RFC7006 Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) M. Garcia-Martin S. Veikkolainen R. Gilman September 2013 ASCII PDF HTML 22 title capability connection data capability bandwidth capability

The Session Description Protocol (SDP) has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely used SDP offer/answer procedures.

This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ("b=" line), connection data ("c=" line), and session or media titles ("i=" line for each session or media).

 draft-ietf-mmusic-sdp-miscellaneous-caps-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=7006 10.17487/RFC7006 RFC7007 Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) T. Terriberry August 2013 ASCII HTML 4

The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). This document updates RFC 3551, the RTP/AVP profile (and by extension, the profiles that build upon it), to reflect changes in audio codec usage since that document was originally published.

 draft-ietf-avtcore-avp-codecs-03 RFC3551 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7007 RFC7008 A Description of the KCipher-2 Encryption Algorithm S. Kiyomoto W. Shin August 2013 ASCII HTML 37 encryption stream cipher cipher

This document describes the KCipher-2 encryption algorithm. KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector. Since the algorithm for KCipher-2 was published in 2007, security and efficiency have been rigorously evaluated through academic and industrial studies. As of the publication of this document, no security vulnerabilities have been found. KCipher-2 offers fast encryption and decryption by means of simple operations that enable efficient implementation. KCipher-2 has been used for industrial applications, especially for mobile health monitoring and diagnostic services in Japan.

 draft-kiyomoto-kcipher2-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7008 RFC7009 OAuth 2.0 Token Revocation T. Lodderstedt Editor S. Dronia M. Scurtescu August 2013 ASCII HTML 11

This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant.

 draft-ietf-oauth-revocation-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=7009 10.17487/RFC7009 RFC7010 IPv6 Site Renumbering Gap Analysis B. Liu S. Jiang B. Carpenter S. Venaas W. George September 2013 ASCII HTML 26

This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements associated with IPv6 renumbering. The content is mainly a gap analysis that provides a basis for future works to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is organized by the main steps of a renumbering process.

 draft-ietf-6renum-gap-analysis-08 INFORMATIONAL INFORMATIONAL IETF ops 6renum 10.17487/RFC7010 RFC7011 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information B. Claise Editor B. Trammell Editor P. Aitken September 2013 ASCII HTML 76

This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101.

 draft-ietf-ipfix-protocol-rfc5101bis-10 RFC5101 STD0077 INTERNET STANDARD INTERNET STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=7011 10.17487/RFC7011 RFC7012 Information Model for IP Flow Information Export (IPFIX) B. Claise Editor B. Trammell Editor September 2013 ASCII HTML 24

This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIX Information Elements" registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102.

 draft-ietf-ipfix-information-model-rfc5102bis-10 RFC5102 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=7012 10.17487/RFC7012 RFC7013 Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements B. Trammell B. Claise September 2013 ASCII HTML 32 IE-DOCTORS IANA

This document provides guidelines for how to write definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol. It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIX Information Element registry, and provides guidelines for expert reviewers to evaluate new registrations.

 draft-ietf-ipfix-ie-doctors-07 BCP0184 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops ipfix 10.17487/RFC7013 RFC7014 Flow Selection Techniques S. D'Antonio T. Zseby C. Henke L. Peluso September 2013 ASCII HTML 33

The Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IP Flow Information Export (IPFIX) Exporter or Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported.

 draft-ietf-ipfix-flow-selection-tech-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7014 RFC7015 Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol B. Trammell A. Wagner B. Claise September 2013 ASCII HTML 49 Flow metering Flow measurement IPFIX mediator

This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals.

 draft-ietf-ipfix-a9n-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7015 RFC7016 Adobe's Secure Real-Time Media Flow Protocol M. Thornburgh November 2013 ASCII HTML 113 RTMFP

This memo describes Adobe's Secure Real-Time Media Flow Protocol (RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features that make it effective for peer-to-peer (P2P) as well as client-server communications, even when Network Address Translators (NATs) are used.

 draft-thornburgh-adobe-rtmfp-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7016 RFC7017 IMAP Access to IETF Email List Archives R. Sparks August 2013 ASCII HTML 5

The IETF makes heavy use of email lists to conduct its work. This often involves accessing the archived history of those email lists. Participants would like to have the ability to browse and search those archives using standard IMAP clients. This memo captures the requirements for providing a service that would allow such browsing and searching, and it is intended as input to a later activity for the design and development of such a service.

 draft-sparks-genarea-imaparch-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7017 RFC7018 Auto-Discovery VPN Problem Statement and Requirements V. Manral S. Hanna September 2013 ASCII HTML 12 IPsec Overlay SDN IKE

This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements for such a solution.

Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases, the IP addresses of endpoints change, or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto-Discovery VPN solution will address these requirements.

 draft-ietf-ipsecme-ad-vpn-problem-09 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC7018 RFC7019 Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD) J. Buford M. Kolberg Editor September 2013 ASCII HTML 41 application-layer multicast

We define a REsource LOcation And Discovery (RELOAD) Usage for Application-Layer Multicast (ALM) as well as a mapping to the RELOAD experimental message type to support ALM. The ALM Usage is intended to support a variety of ALM control algorithms in an overlay-independent way. Two example algorithms are defined, based on Scribe and P2PCast.

This document is a product of the Scalable Adaptive Multicast Research Group (SAM RG).

 draft-irtf-samrg-sam-baseline-protocol-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7019 RFC7020 The Internet Numbers Registry System R. Housley J. Curran G. Huston D. Conrad August 2013 ASCII HTML 9

This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers.

This document also provides information about the processes for further evolution of the Internet Numbers Registry System.

This document replaces RFC 2050.

This document does not propose any changes to the current Internet Numbers Registry System. Rather, it documents the Internet Numbers Registry System as it works today.

 draft-housley-rfc2050bis-02 RFC2050 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7020 10.17487/RFC7020 RFC7021 Assessing the Impact of Carrier-Grade NAT on Network Applications C. Donley Editor L. Howard V. Kuarsingh J. Berg J. Doshi September 2013 ASCII HTML 29 CGN NAT444 DS-Lite Dual-Stack Lite IPv4 NAT IPv6 LSN transition

NAT444 is an IPv4 extension technology being considered by Service Providers as a means to continue offering IPv4 service to customers while transitioning to IPv6. This technology adds an extra Carrier- Grade NAT (CGN) in the Service Provider network, often resulting in two NATs. CableLabs, Time Warner Cable, and Rogers Communications independently tested the impacts of NAT444 on many popular Internet services using a variety of test scenarios, network topologies, and vendor equipment. This document identifies areas where adding a second layer of NAT disrupts the communication channel for common Internet applications. This document was updated to include the Dual-Stack Lite (DS-Lite) impacts also.

 draft-donley-nat444-impacts-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7021 RFC7022 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) A. Begen C. Perkins D. Wing E. Rescorla September 2013 ASCII HTML 10

The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams.

For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222.

 draft-ietf-avtcore-6222bis-06 RFC6222 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7022 RFC7023 MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking D. Mohan Editor N. Bitar Editor A. Sajassi Editor S. DeLord P. Niger R. Qiu October 2013 ASCII HTML 23

This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet pseudowires (PWs) connected in accordance with the Pseudowire Emulation Edge-to-Edge (PWE3) architecture to realize an end-to-end emulated Ethernet service. It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects.

 draft-ietf-pwe3-mpls-eth-oam-iwk-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7023 RFC7024 Virtual Hub-and-Spoke in BGP/MPLS VPNs H. Jeng J. Uttaro L. Jalil B. Decraene Y. Rekhter R. Aggarwal October 2013 ASCII HTML 25

With BGP/MPLS Virtual Private Networks (VPNs), providing any-to-any connectivity among sites of a given VPN would require each Provider Edge (PE) router connected to one or more of these sites to hold all the routes of that VPN. The approach described in this document allows the VPN service provider to reduce the number of PE routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes.

Furthermore, when PE routers use ingress replication to carry the multicast traffic of VPN customers, the approach described in this document may, under certain circumstances, reduce bandwidth inefficiency associated with ingress replication and redistribute the replication load among PE routers.

 draft-ietf-l3vpn-virtual-hub-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC7024 RFC7025 Requirements for GMPLS Applications of PCE T. Otani K. Ogaki D. Caviglia F. Zhang C. Margaria September 2013 ASCII HTML 12 Path Computation CSPF PCC Traffic Engineering TE

The initial effort of the PCE (Path Computation Element) WG focused mainly on MPLS. As a next step, this document describes functional requirements for GMPLS applications of PCE.

 draft-ietf-pce-gmpls-aps-req-09 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC7025 RFC7026 Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel A. Farrel S. Bryant September 2013 ASCII HTML 5 ACH G-ACh Pseudowire PW MPLS-TP

The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs

No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable.

This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry.

 draft-ietf-mpls-retire-ach-tlv-03 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7026 RFC7027 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) J. Merkle M. Lochter October 2013 ASCII HTML 10 TLS Elliptic Curve Cryptography

This document specifies the use of several Elliptic Curve Cryptography (ECC) Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol.

 draft-merkle-tls-brainpool-04 RFC4492 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7027 10.17487/RFC7027 RFC7028 Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 JC. Zuniga LM. Contreras CJ. Bernardos S. Jeon Y. Kim September 2013 ASCII HTML 29 multimob PMIPv6 MTMA selector MLD IGMP

This document proposes some experimental enhancements to the base solution to support IP multicasting in a Proxy Mobile IPv6 (PMIPv6) domain. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the Mobile Access Gateway can provide access to multicast content in the local network. The goal of these enhancements is to provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployment scenarios.

 draft-ietf-multimob-pmipv6-ropt-08 EXPERIMENTAL EXPERIMENTAL IETF int multimob 10.17487/RFC7028 RFC7029 Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding S. Hartman M. Wasserman D. Zhang October 2013 ASCII HTML 19 MITM man-in-the-middle EMSK crypto binding Extended Master Session Key tunnel

As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. Cryptographic binding is a facility described in RFC 3748 that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in-the-middle attacks and recommends cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations.

 draft-ietf-emu-crypto-bind-04 INFORMATIONAL INFORMATIONAL IETF sec emu 10.17487/RFC7029 RFC7030 Enrollment over Secure Transport M. Pritikin Editor P. Yee Editor D. Harkins Editor October 2013 ASCII HTML 53 pki est

This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.

 draft-ietf-pkix-est-09 RFC8951 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=7030 10.17487/RFC7030 RFC7031 DHCPv6 Failover Requirements T. Mrugalski K. Kinnear September 2013 ASCII HTML 17 DHCPv6 Failover

The DHCPv6 protocol, defined in RFC 3315, allows for multiple servers to operate on a single network; however, it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. RFC 3315 allows for, but does not define, any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol.

 draft-ietf-dhc-dhcpv6-failover-requirements-07 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC7031 RFC7032 LDP Downstream-on-Demand in Seamless MPLS T. Beckhaus Editor B. Decraene K. Tiruveedhula M. Konstantynowicz Editor L. Martini October 2013 ASCII HTML 35

Seamless MPLS design enables a single IP/MPLS network to scale over core, metro, and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access networks including high number of devices, device position in network topology, and compute and memory constraints that limit the amount of state access devices can hold. This can be achieved with LDP Downstream-on-Demand (DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design.

In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence.

 draft-ietf-mpls-ldp-dod-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7032 RFC7033 WebFinger P. Jones G. Salgueiro M. Jones J. Smarr September 2013 ASCII HTML 28 WebFinger JRD JSON Resource Descriptor service discovery service discovery protocol information discovery information discovery protocol

This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.

 draft-ietf-appsawg-webfinger-18 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7033 RFC7034 HTTP Header Field X-Frame-Options D. Ross T. Gondrom October 2013 ASCII HTML 14 frame-options HTTP header websec

To improve the protection of web applications against clickjacking, this document describes the X-Frame-Options HTTP header field, which declares a policy, communicated from the server to the client browser, regarding whether the browser may display the transmitted content in frames that are part of other web pages.

 draft-ietf-websec-x-frame-options-12 INFORMATIONAL INFORMATIONAL IETF app websec 10.17487/RFC7034 RFC7035 Relative Location Representation M. Thomson B. Rosen D. Stanley G. Bajko A. Thomson October 2013 ASCII HTML 39 Relative location

This document defines an extension to the Presence Information Data Format Location Object (PIDF-LO) (RFC 4119) for the expression of location information that is defined relative to a reference point. The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. An alternative binary representation is described.

Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system, to allow display of the map with the reference point and the relative offset.

 draft-ietf-geopriv-relative-location-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7035 RFC7036 Object Identifier Registry for the Long-Term Archive and Notary Services (LTANS) Working Group R. Housley October 2013 ASCII HTML 7

When the Long-Term Archive and Notary Services (LTANS) working group was chartered, an object identifier arc was set aside for use by that working group. This document describes the object identifiers that were assigned, and it establishes IANA allocation policies for any future assignments within that arc.

 draft-housley-ltans-oids-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7036 RFC7037 RADIUS Option for the DHCPv6 Relay Agent L. Yeh M. Boucadair October 2013 ASCII HTML 10 DHCPv6 RADIUS

The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and DHCPv6 server. This architecture assumes that the Network Access Server (NAS) acts as both a DHCPv6 relay agent and RADIUS client. When receiving messages from the DHCPv6 clients, the NAS consults the RADIUS server and adds the RADIUS response when forwarding the DHCPv6 client's messages to the DHCPv6 server. The DHCPv6 server then uses that additional information to generate an appropriate response to the DHCPv6 client's requests.

 draft-ietf-dhc-dhcpv6-radius-opt-14 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7037 RFC7038 Use of OSPF-MDR in Single-Hop Broadcast Networks R. Ogier October 2013 ASCII HTML 7 routing mobile ad hoc network MANET designated router wireless point-to-multipoint interface

RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR (MANET Designated Router) in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor. The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks.

 draft-ietf-ospf-manet-single-hop-mdr-04 RFC5614 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC7038 RFC7039 Source Address Validation Improvement (SAVI) Framework J. Wu J. Bi M. Bagnulo F. Baker C. Vogt Editor October 2013 ASCII HTML 14 anti-spoofing BCP38 ingress filtering

Source Address Validation Improvement (SAVI) methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer-grained, standardized IP source address validation. This document is a framework document that describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents.

 draft-ietf-savi-framework-06 INFORMATIONAL INFORMATIONAL IETF int savi 10.17487/RFC7039 RFC7040 Public IPv4-over-IPv6 Access Network Y. Cui J. Wu P. Wu O. Vautrin Y. Lee November 2013 ASCII HTML 13 Public 4over6 IPv4 over IPv6 Access Network DHCPv4 over IPv6 IPv6 Tunnel IPv6 Transition

This document describes a mechanism called Public 4over6, which is designed to provide IPv4 Internet connectivity over an IPv6 access network using global IPv4 addresses. Public 4over6 was developed in the IETF and is in use in some existing deployments but is not recommended for new deployments. Future deployments of similar scenarios should use Lightweight 4over6. Public 4over6 follows the Hub and Spoke softwire model and uses an IPv4-in-IPv6 tunnel to forward IPv4 packets over an IPv6 access network. The bidirectionality of the IPv4 communication is achieved by explicitly allocating global non-shared IPv4 addresses to end users and by maintaining IPv4-IPv6 address binding on the border relay. Public 4over6 aims to provide uninterrupted IPv4 services to users, like Internet Content Providers (ICPs), etc., while an operator makes the access network transition to an IPv6-only access network.

 draft-ietf-softwire-public-4over6-10 INFORMATIONAL INFORMATIONAL IETF int softwire 10.17487/RFC7040 RFC7041 Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging F. Balus Editor A. Sajassi Editor N. Bitar Editor November 2013 ASCII HTML 15

The IEEE 802.1 Provider Backbone Bridges (PBBs) specification defines an architecture and bridge protocols for interconnection of multiple Provider Bridged Networks (PBNs). Provider backbone bridging was defined by IEEE as a connectionless technology based on multipoint VLAN tunnels. PBB can be used to attain better scalability than Provider Bridges (PBs) in terms of the number of customer Media Access Control addresses and the number of service instances that can be supported.

The Virtual Private LAN Service (VPLS) provides a framework for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running the Rapid Spanning Tree Protocol (RSTP) or the Multiple Spanning Tree Protocol (MSTP) across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks.

This document discusses extensions to the VPLS Provider Edge (PE) model required to incorporate desirable PBB components while maintaining the service provider fit of the initial model.

 draft-ietf-l2vpn-pbb-vpls-pe-model-07 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7041 RFC7042 IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters D. Eastlake 3rd J. Abley October 2013 ASCII HTML 27 Ethernet Ethertype 802 OUI EUI LSAP

Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 5342.

 draft-eastlake-rfc5342bis-05 RFC5342 RFC2153 BCP0141 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7042 RFC7043 Resource Records for EUI-48 and EUI-64 Addresses in the DNS J. Abley October 2013 ASCII HTML 8 IEEE ethernet

48-bit Extended Unique Identifier (EUI-48) and 64-bit Extended Unique Identifier (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g., Ethernet.

This document describes two new DNS resource record types, EUI48 and EUI64, for encoding Ethernet addresses in the DNS.

This document describes potentially severe privacy implications resulting from indiscriminate publication of link-layer addresses in the DNS. EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS. This document specifies an interoperable encoding of these address types for use in private DNS namespaces, where the privacy concerns can be constrained and mitigated.

 draft-jabley-dnsext-eui48-eui64-rrtypes-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7043 RFC7044 An Extension to the Session Initiation Protocol (SIP) for Request History Information M. Barnes F. Audet S. Schubert J. van Elburg C. Holmberg February 2014 ASCII HTML 36 history-info retarget enhanced services voicemail automatic call distribution

This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. This document obsoletes RFC 4244.

 draft-ietf-sipcore-rfc4244bis-12 RFC4244 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=7044 10.17487/RFC7044 RFC7045 Transmission and Processing of IPv6 Extension Headers B. Carpenter S. Jiang December 2013 ASCII HTML 10

Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780.

 draft-ietf-6man-ext-transmit-05 RFC2460 RFC2780 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7045 RFC7046 A Common API for Transparent Hybrid Multicast M. Waehlisch T. Schmidt S. Venaas December 2013 ASCII HTML 41 Peer-to-Peer (P2P) adaptive multicast multicast naming multicast addressing

Group communication services exist in a large variety of flavors and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable upper-layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay and that grants access to the different flavors of multicast. It proposes an abstract naming scheme that uses multicast URIs, and it discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, this document describes the application of this API for building gateways that interconnect current Multicast Domains throughout the Internet. It reports on an implementation of the programming Interface, including service middleware. This document is a product of the Scalable Adaptive Multicast (SAM) Research Group.

 draft-irtf-samrg-common-api-11 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7046 RFC7047 The Open vSwitch Database Management Protocol B. Pfaff B. Davie Editor December 2013 ASCII HTML 35 vswitch virtualization overlay OVS

Open vSwitch is an open-source software switch designed to be used as a vswitch (virtual switch) in virtualized server environments. A vswitch forwards traffic between different virtual machines (VMs) on the same physical host and also forwards traffic between VMs and the physical network. Open vSwitch is open to programmatic extension and control using OpenFlow and the OVSDB (Open vSwitch Database) management protocol. This document defines the OVSDB management protocol. The Open vSwitch project includes open-source OVSDB client and server implementations.

 draft-pfaff-ovsdb-proto-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7047 RFC7048 Neighbor Unreachability Detection Is Too Impatient E. Nordmark I. Gashinsky January 2014 ASCII HTML 8 6MAN IPv6 Neighbor Discovery

IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative neighbor -- for instance, when there are multiple default routers -- since it allows the host to switch to the alternative neighbor in a short time. By default, this time is 3 seconds after the node starts probing. However, if there are no alternative neighbors, this timeout behavior is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allow an implementation to choose different timeout behavior based on whether or not there are alternative neighbors. This document updates RFC 4861.

 draft-ietf-6man-impatient-nud-07 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7048 RFC7049 Concise Binary Object Representation (CBOR) C. Bormann P. Hoffman October 2013 ASCII HTML 54 parser encoder binary format data interchange format JSON

The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.

 draft-bormann-cbor-09 RFC8949 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7049 10.17487/RFC7049 RFC7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis T. Savolainen J. Korhonen D. Wing November 2013 ASCII HTML 22 NAT64 DNS64 464XLAT Pref64::/n

This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments.

 draft-ietf-behave-nat64-discovery-heuristic-17 RFC8880 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=7050 10.17487/RFC7050 RFC7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix J. Korhonen Editor T. Savolainen Editor November 2013 ASCII HTML 25 NAT64 DNS64 464XLAT Pref64::/n

Hosts and applications may benefit from learning if an IPv6 address is synthesized and if NAT64 and DNS64 are present in a network. This document analyzes all proposed solutions (known at the time of writing) for communicating whether the synthesis is taking place, what address format was used, and what IPv6 prefix was used by the NAT64 and DNS64. These solutions enable both NAT64 avoidance and local IPv6 address synthesis. The document concludes by recommending the standardization of the approach based on heuristic discovery.

 draft-ietf-behave-nat64-learn-analysis-03 INFORMATIONAL INFORMATIONAL IETF tsv behave 10.17487/RFC7051 RFC7052 Locator/ID Separation Protocol (LISP) MIB G. Schudel A. Jain V. Moreno October 2013 ASCII HTML 66

This document defines the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics.

 draft-ietf-lisp-mib-13 EXPERIMENTAL EXPERIMENTAL IETF int lisp http://www.rfc-editor.org/errata_search.php?rfc=7052 10.17487/RFC7052 RFC7053 SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol M. Tuexen I. Ruengeler R. Stewart November 2013 ASCII HTML 8

This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding Selective Acknowledgment (SACK) chunk should be sent back immediately and should not be delayed. It is done by specifying a bit in the DATA chunk header, called the (I)mmediate bit, which can get set by either the Stream Control Transmission Protocol (SCTP) implementation or the application using an SCTP stack. Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems.

 draft-ietf-tsvwg-sctp-sack-immediately-04 RFC9260 RFC4960 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC7053 RFC7054 Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs) A. Farrel H. Endo R. Winter Y. Koike M. Paul November 2013 ASCII HTML 11

The framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how the Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at incoming and outgoing interfaces.

This document elaborates on important considerations for internal MIP addressing. More precisely, it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on either incoming or outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP.

 draft-ietf-mpls-tp-mip-mep-map-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7054 RFC7055 A GSS-API Mechanism for the Extensible Authentication Protocol S. Hartman Editor J. Howlett December 2013 ASCII HTML 35

This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Extensible Authentication Protocol mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL) applications use the Extensible Authentication Protocol.

 draft-ietf-abfab-gss-eap-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7055 RFC7056 Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism S. Hartman J. Howlett December 2013 ASCII HTML 11

The naming extensions to the Generic Security Service Application Programming Interface (GSS-API) provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication, Authorization, and Accounting (AAA) peer to provide authorization attributes alongside an authentication response. It also supplies mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes how to use the Naming Extensions API to access that information.

 draft-ietf-abfab-gss-eap-naming-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7056 RFC7057 Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB) S. Winter J. Salowey December 2013 ASCII HTML 7 EAP AAA

This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC 3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture.

 draft-ietf-abfab-eapapplicability-06 RFC3748 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7057 RFC7058 Media Control Channel Framework (CFW) Call Flow Examples A. Amirante T. Castaldi L. Miniero S P. Romano November 2013 ASCII HTML 182 MediaCtrl Media Server Control Media Control Channel Framework

This document provides a list of typical Media Control Channel Framework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference document for both implementors and protocol researchers.

 draft-ietf-mediactrl-call-flows-13 INFORMATIONAL INFORMATIONAL IETF rai mediactrl 10.17487/RFC7058 RFC7059 A Comparison of IPv6-over-IPv4 Tunnel Mechanisms S. Steffann I. van Beijnum R. van Rein November 2013 ASCII HTML 41

This document provides an overview of various ways to tunnel IPv6 packets over IPv4 networks. It covers mechanisms in current use, touches on several mechanisms that are now only of historic interest, and discusses some newer tunnel mechanisms that are not widely used at the time of publication. The goal of the document is helping people with an IPv6-in-IPv4 tunneling need to select the mechanisms that may apply to them.

 draft-steffann-tunnels-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7059 RFC7060 Using LDP Multipoint Extensions on Targeted LDP Sessions M. Napierala E. Rosen IJ. Wijnands November 2013 ASCII HTML 9

Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths. However, the specification for the Multipoint Extensions to LDP presupposes that the two endpoints of an LDP session are directly connected. The LDP base specification allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a "Targeted LDP" session. This document provides the specification for using the LDP Multipoint Extensions over a Targeted LDP session.

 draft-ietf-mpls-targeted-mldp-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7060 RFC7061 eXtensible Access Control Markup Language (XACML) XML Media Type R. Sinnema E. Wilde November 2013 ASCII HTML 8

This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML).

 draft-sinnema-xacml-media-type-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7061 RFC7062 Framework for GMPLS and PCE Control of G.709 Optical Transport Networks F. Zhang Editor D. Li H. Li S. Belotti D. Ceccarelli November 2013 ASCII HTML 26

This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTNs) as specified in ITU-T Recommendation G.709 as published in 2012.

 draft-ietf-ccamp-gmpls-g709-framework-15 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7062 RFC7063 Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments L. Zheng J. Zhang R. Parekh December 2013 ASCII HTML 12

This document provides supporting documentation to advance the IETF stream's Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol from Proposed Standard to Internet Standard.

 draft-ietf-pim-rfc4601-update-survey-report-03 INFORMATIONAL INFORMATIONAL IETF rtg pim 10.17487/RFC7063 RFC7064 URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol S. Nandakumar G. Salgueiro P. Jones M. Petit-Huguenin November 2013 ASCII HTML 9

This document specifies the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol.

 draft-nandakumar-rtcweb-stun-uri-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7064 RFC7065 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers M. Petit-Huguenin S. Nandakumar G. Salgueiro P. Jones November 2013 ASCII HTML 9

This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes to provision the TURN Resolution Mechanism (RFC 5928).

 draft-petithuguenin-behave-turn-uris-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7065 RFC7066 IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts J. Korhonen Editor J. Arkko Editor T. Savolainen S. Krishnan November 2013 ASCII HTML 20

As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made the Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost, and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (hereafter collectively referred to as Third Generation Partnership Project (3GPP) networks). This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434). It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316.

 draft-ietf-v6ops-rfc3316bis-06 RFC3316 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7066 RFC7067 Directory Assistance Problem and High-Level Design Proposal L. Dunbar D. Eastlake 3rd R. Perlman I. Gashinsky November 2013 ASCII HTML 15 TRILL Orchestration Directory Push Pull RBridge ARP

Edge TRILL (Transparent Interconnection of Lots of Links) switches currently learn the mapping between MAC (Media Access Control) addresses and their egress TRILL switch by observing the data packets they ingress or egress or by the TRILL ESADI (End-Station Address Distribution Information) protocol. When an ingress TRILL switch receives a data frame for a destination address (MAC&Label) that the switch does not know, the data frame is flooded within the frame's Data Label across the TRILL campus.

This document describes the framework for using directory services to assist edge TRILL switches in reducing multi-destination frames, particularly unknown unicast frames flooding, and ARP/ND (Address Resolution Protocol / Neighbor Discovery), thus improving TRILL network scalability and security.

 draft-ietf-trill-directory-framework-07 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC7067 RFC7068 Diameter Overload Control Requirements E. McMurry B. Campbell November 2013 ASCII HTML 29

When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by advising clients to reduce traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively severe overload condition. The existing Diameter mechanisms are not sufficient for managing overload conditions. This document describes the limitations of the existing mechanisms. Requirements for new overload management mechanisms are also provided.

 draft-ietf-dime-overload-reqs-13 INFORMATIONAL INFORMATIONAL IETF ops dime 10.17487/RFC7068 RFC7069 DECoupled Application Data Enroute (DECADE) R. Alimi A. Rahman D. Kutscher Y. Yang H. Song K. Pentikousis November 2013 ASCII HTML 35 decade

Content distribution applications, such as those employing peer-to-peer (P2P) technologies, are widely used on the Internet and make up a large portion of the traffic in many networks. Often, however, content distribution applications use network resources inefficiently. One way to improve efficiency is to introduce storage capabilities within the network and enable cooperation between end-host and in-network content distribution mechanisms. This is the capability provided by a DECoupled Application Data Enroute (DECADE) system, which is introduced in this document. DECADE enables applications to take advantage of in-network storage when distributing data objects as opposed to using solely end-to-end resources. This document presents the underlying principles and key functionalities of such a system and illustrates operation through a set of examples.

 draft-alimi-decade-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7069 RFC7070 An Architecture for Reputation Reporting N. Borenstein M. Kucherawy November 2013 ASCII HTML 14 domain security messaging dkim spf authentication reputation

This document describes a general architecture for a reputation-based service, allowing one to request reputation-related data over the Internet, where "reputation" refers to predictions or expectations about an entity or an identifier such as a domain name. The document roughly follows the recommendations of RFC 4101 for describing a protocol model.

 draft-ietf-repute-model-10 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7070 RFC7071 A Media Type for Reputation Interchange N. Borenstein M. Kucherawy November 2013 ASCII HTML 17 reputation domain security messaging dkim spf authentication

This document defines the format of reputation response data ("reputons"), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets.

 draft-ietf-repute-media-type-13 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7071 RFC7072 A Reputation Query Protocol N. Borenstein M. Kucherawy November 2013 ASCII HTML 9 reputation domain security messaging dkim spf authentication

This document defines a mechanism to conduct queries for reputation information over the HyperText Transfer Protocol (HTTP) using JavaScript Object Notation (JSON) as the payload meta-format.

 draft-ietf-repute-query-http-11 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7072 RFC7073 A Reputation Response Set for Email Identifiers N. Borenstein M. Kucherawy November 2013 ASCII HTML 8 reputation domain security messaging dkim spf authentication

This document defines a response set for describing assertions a reputation service provider can make about email identifiers, for use in generating reputons.

 draft-ietf-repute-email-identifiers-10 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7073 RFC7074 Revised Definition of the GMPLS Switching Capability and Type Fields L. Berger J. Meuric November 2013 ASCII HTML 9

GMPLS provides control for multiple switching technologies and for hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate the type of switching technology. These values are carried in routing protocols via the Switching Capability field, and in signaling protocols via the Switching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates all documents that use the GMPLS Switching Capability and Types fields, in particular RFCs 3471, 4202, 4203, and 5307.

 draft-ietf-ccamp-swcaps-update-03 RFC3471 RFC4202 RFC4203 RFC5307 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7074 RFC7075 Realm-Based Redirection In Diameter T. Tsou R. Hao T. Taylor Editor November 2013 ASCII HTML 10 Diameter routing

The Diameter protocol includes a capability for message redirection, controlled by an application-independent "redirect agent". In some circumstances, an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which a Diameter server or proxy (node) can perform such a redirection when the Straightforward-Naming Authority Pointer (S-NAPTR) is not used for dynamic peer discovery. A node performing this new function is referred to as a "Realm-based Redirect Server".

This memo updates Sections 6.13 and 6.14 of RFC 6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time Attribute-Value Pairs (AVPs).

 draft-ietf-dime-realm-based-redirect-13 RFC6733 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7075 RFC7076 P6R's Secure Shell Public Key Subsystem M. Joseph J. Susoy November 2013 ASCII HTML 11 key management certificate management security

The Secure Shell (SSH) Public Key Subsystem protocol defines a key distribution protocol that is limited to provisioning an SSH server with a user's public keys. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport.

The new protocol allows the calling client to organize keys and certificates in different namespaces on a server. These namespaces can be used by the server to allow a client to configure any application running on the server (e.g., SSH, Key Management Interoperability Protocol (KMIP), Simple Network Management Protocol (SNMP)).

The new protocol provides a server-independent mechanism for clients to add public keys, remove public keys, add certificates, remove certificates, and list the current set of keys and certificates known by the server by namespace (e.g., list all public keys in the SSH namespace).

Rights to manage keys and certificates in a particular namespace are specific and limited to the authorized user and are defined as part of the server's implementation. The described protocol is backward compatible to version 2 defined by RFC 4819.

 draft-joseph-pkix-p6rsshextension-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7076 RFC7077 Update Notifications for Proxy Mobile IPv6 S. Krishnan S. Gundavelli M. Liebsch H. Yokota J. Korhonen November 2013 ASCII HTML 21 MIPv6

This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These Update Notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose.

 draft-ietf-netext-update-notifications-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7077 RFC7078 Distributing Address Selection Policy Using DHCPv6 A. Matsumoto T. Fujisaki T. Chown January 2014 ASCII HTML 12

RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. RFC 6724 allows for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus allowing the administrator to control the address selection behavior of nodes in their site.

 draft-ietf-6man-addr-select-opt-13 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7078 RFC7079 The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results N. Del Regno Editor A. Malis Editor November 2013 ASCII HTML 41 Control Word (CW) Control Channel (CC)

The IETF Pseudowire Emulation Edge-to-Edge (PWE3) working group has defined many encapsulations of various layer 1 and layer 2 service- specific PDUs and circuit data. In most of these encapsulations, use of the Pseudowire (PW) Control Word is required. However, there are several encapsulations for which the Control Word is optional, and this optionality has been seen in practice to possibly introduce interoperability concerns between multiple implementations of those encapsulations. This survey of the Pseudowire / Virtual Circuit Connectivity Verification (VCCV) user community was conducted to determine implementation trends and the possibility of always mandating the Control Word.

 draft-ietf-pwe3-vccv-impl-survey-results-03 INFORMATIONAL INFORMATIONAL IETF rtg pwe3 10.17487/RFC7079 RFC7080 Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges A. Sajassi S. Salam N. Bitar F. Balus December 2013 ASCII HTML 26 h-vpls

The scalability of Hierarchical Virtual Private LAN Service (H-VPLS) with Ethernet access networks (RFC 4762) can be improved by incorporating Provider Backbone Bridge functionality in the VPLS access. Provider Backbone Bridging has been standardized as IEEE 802.1ah-2008. It aims to improve the scalability of Media Access Control (MAC) addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used in H-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H-VPLS with existing MPLS access.

 draft-ietf-l2vpn-pbb-vpls-interop-06 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7080 RFC7081 CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) E. Ivov P. Saint-Andre E. Marocco November 2013 ASCII HTML 19 real-time communication unified communication voice video instant messaging chat presence telephony

This document suggests some strategies for the combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) both in user-oriented clients and in deployed servers. Such strategies, which mainly consist of configuration changes and minimal software modifications to existing clients and servers, aim to provide a single, full-featured, real-time communication service by using complementary subsets of features from SIP and from XMPP. Typically, such subsets consist of telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This document does not define any new protocols or syntax for either SIP or XMPP and, by intent, does not attempt to standardize "best current practices". Instead, it merely aims to provide practical guidance to those who are interested in the combined use of SIP and XMPP for real-time communication.

 draft-ivov-xmpp-cusax-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7081 RFC7082 Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP) R. Shekh-Yusef M. Barnes December 2013 ASCII HTML 10

The Centralized Conferencing Manipulation Protocol (CCMP) document (RFC 6503) defines a way for a client to discover a conference control server that supports CCMP. However, it does not define a way for a client involved in a conference to determine if the conference focus supports CCMP. This information would allow a CCMP-enabled client that joins a conference using SIP to also register for the Centralized Conferencing (XCON) conference event package and take advantage of CCMP operations on the conference.

This document describes two mechanisms, depending upon the need of the User Agent (UA), to address the above limitation. The first mechanism uses the Call-Info header field, and the second mechanism defines a new value for the "purpose" header field parameter in the <service-uris> element in the SIP conferencing event package.

 draft-yusef-dispatch-ccmp-indication-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7082 RFC7083 Modification to Default Values of SOL_MAX_RT and INF_MAX_RT R. Droms November 2013 ASCII HTML 7

This document updates RFC 3315 by redefining the default values for SOL_MAX_RT and INF_MAX_RT and defining options through which a DHCPv6 server can override the client's default value for SOL_MAX_RT and INF_MAX_RT with new values.

 draft-ietf-dhc-dhcpv6-solmaxrt-update-05 RFC8415 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7083 RFC7084 Basic Requirements for IPv6 Customer Edge Routers H. Singh W. Beebee C. Donley B. Stark November 2013 ASCII HTML 21 6rd DS-Lite

This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document. The document obsoletes RFC 6204.

 draft-ietf-v6ops-6204bis-12 RFC6204 RFC9096 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7084 RFC7085 Top-Level Domains That Are Already Dotless J. Levine P. Hoffman December 2013 ASCII HTML 6 DNS

Recent statements from the Internet Architecture Board (IAB) and the Internet Corporation of Assigned Names and Numbers (ICANN) Security and Stability Advisory Committee have focused on the problems that the DNS is likely to experience with top-level domains (TLDs) that contain address records (so-called "dotless domains"). In order to help researchers determine the extent of the issues with dotless domains, this document lists the current dotless TLDs and gives a script for finding them. This document lists data about dotless TLDs but does not address the policy and technology issues other than to point to the statements of others.

 draft-hoffine-already-dotless-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7085 RFC7086 Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) A. Keranen G. Camarillo J. Maenpaa January 2014 ASCII HTML 10 HIP overlay P2P

This document is the HIP-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP.

 draft-ietf-hip-reload-instance-10 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC7086 RFC7087 A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations H. van Helvoort Editor L. Andersson Editor N. Sprecher Editor December 2013 ASCII HTML 21

The MPLS Transport Profile (MPLS-TP) is based on a profile of the MPLS and Pseudowire (PW) procedures as specified in the MPLS Traffic Engineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW) architectures developed by the Internet Engineering Task Force (IETF). The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has specified a Transport Network architecture.

This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network Recommendations.

It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive or complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context.

 draft-ietf-mpls-tp-rosetta-stone-13 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7087 RFC7088 Session Initiation Protocol Service Example -- Music on Hold D. Worley February 2014 ASCII HTML 36 Music on hold

"Music on hold" is one of the features of telephone systems that is most desired by buyers of business telephone systems. Music on hold means that when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music on hold in a way that is fully standards-compliant. The implementation of music on hold described in this document is fully effective, is standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems that perform authentication than the music-on-hold method described in Section 2.3 of RFC 5359.

 draft-worley-service-example-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7088 RFC7089 HTTP Framework for Time-Based Access to Resource States -- Memento H. Van de Sompel M. Nelson R. Sanderson December 2013 ASCII HTML 50 HTTP content negotiation datetime negotiation resource versions archival resources Memento

The HTTP-based Memento framework bridges the present and past Web. It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.

 draft-vandesompel-memento-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7089 RFC7090 Public Safety Answering Point (PSAP) Callback H. Schulzrinne H. Tschofenig C. Holmberg M. Patel April 2014 ASCII HTML 18 PSAP callback SIP emergency VoIP

After an emergency call is completed (terminated either prematurely by the emergency caller or normally by the call taker), the call taker may feel the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current state of an accident victim. A call taker may trigger a callback to the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and, as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine.

The IETF emergency services architecture specification already offers a solution approach for allowing Public Safety Answering Point (PSAP) callbacks to bypass authorization policies in order to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than-normal call treatment behavior would be desirable. We describe a solution based on a new header field value for the SIP Priority header field, called "psap-callback", to mark PSAP callbacks.

 draft-ietf-ecrit-psap-callback-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC7090 RFC7091 GOST R 34.10-2012: Digital Signature Algorithm V. Dolmatov Editor A. Degtyarev December 2013 ASCII HTML 21

This document provides information about the Russian Federal standard for digital signatures (GOST R 34.10-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document provides information for developers and users of GOST R 34.10-2012 regarding digital signature generation and verification. This document updates RFC 5832.

 draft-dolmatov-gost34102012-00 RFC5832 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7091 RFC7092 A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents H. Kaplan V. Pascual December 2013 ASCII HTML 10 SIP B2BUA taxonomy

In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).

There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.

 draft-ietf-straw-b2bua-taxonomy-03 INFORMATIONAL INFORMATIONAL IETF rai straw 10.17487/RFC7092 RFC7093 Additional Methods for Generating Key Identifiers Values S. Turner S. Kent J. Manger December 2013 ASCII HTML 5

This document specifies additional example methods for generating Key Identifier values for use in the AKI (Authority Key Identifier) and SKI (Subject Key Identifier) certificate extensions.

 draft-turner-additional-methods-4kis-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7093 RFC7094 Architectural Considerations of IP Anycast D. McPherson D. Oran D. Thaler E. Osterweil January 2014 ASCII HTML 22 anycast architecture

This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols.

 draft-iab-anycast-arch-implications-12 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7094 RFC7095 jCard: The JSON Format for vCard P. Kewisch January 2014 ASCII HTML 29 jCard JSON vCard addressbook contacts CardDAV PIM

This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.

 draft-ietf-jcardcal-jcard-07 PROPOSED STANDARD PROPOSED STANDARD IETF app jcardcal 10.17487/RFC7095 RFC7096 Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs) S. Belotti Editor P. Grandi D. Ceccarelli Editor D. Caviglia F. Zhang D. Li January 2014 ASCII HTML 23 Routing CCAMP Working Group OSPF GMPLS G709 OTN

ITU-T recommendation G.709-2012 has introduced new fixed and flexible Optical channel Data Unit (ODU) containers in Optical Transport Networks (OTNs).

This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 OTNs.

 draft-ietf-ccamp-otn-g709-info-model-13 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7096 RFC7097 RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets J. Ott V. Singh Editor I. Curcio January 2014 ASCII HTML 11 RTP RTCP discard metrics

The RTP Control Protocol (RTCP) is used in conjunction with the Real- time Transport Protocol (RTP) in order to provide a variety of short- term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a per-packet report metric capturing individual packets discarded from the de- jitter buffer after successful reception.

 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7097 RFC7098 Using the IPv6 Flow Label for Load Balancing in Server Farms B. Carpenter S. Jiang W. Tarreau January 2014 ASCII HTML 13 ECMP

This document describes how the currently specified IPv6 flow label can be used to enhance layer 3/4 (L3/4) load distribution and balancing for large server farms.

 draft-ietf-intarea-flow-label-balancing-03 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC7098 RFC7099 RFC7100 Retirement of the "Internet Official Protocol Standards" Summary Document P. Resnick December 2013 ASCII HTML 3

This document updates RFC 2026 to no longer use STD 1 as a summary of "Internet Official Protocol Standards". It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status.

 draft-resnick-retire-std1-01 RFC5000 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7100 RFC7101 List of Internet Official Protocol Standards: Replaced by a Web Page S. Ginoza December 2013 ASCII HTML 4

At one time, the RFC Editor published snapshots of the "Internet Official Protocol Standards". These documents were known as xx00 documents, the last of which was published in May 2008. These snapshots have been replaced by a web page, so the RFC Editor will no longer be publishing these snapshots as RFCs. As a result, the RFC Editor will classify unpublished RFC xx00 numbers through 7000 as never issued. Starting with the RFC number 7100, xx00 numbers will be available for assignment.

 draft-rfced-rfcxx00-retired-06 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7101 RFC7102 Terms Used in Routing for Low-Power and Lossy Networks JP. Vasseur January 2014 ASCII HTML 8

This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration.

 draft-ietf-roll-terminology-13 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC7102 RFC7103 Advice for Safe Handling of Malformed Messages M. Kucherawy G. Shapiro N. Freed January 2014 ASCII HTML 24 MTA SMTP

Although Internet message formats have been precisely defined since the 1970s, authoring and handling software often shows only mild conformance to the specifications. The malformed messages that result are non-standard. Nonetheless, decades of experience have shown that using some tolerance in the handling of the malformations that result is often an acceptable approach and is better than rejecting the messages outright as nonconformant. This document includes a collection of the best advice available regarding a variety of common malformed mail situations; it is to be used as implementation guidance.

 draft-ietf-appsawg-malformed-mail-11 INFORMATIONAL INFORMATIONAL IETF app appsawg 10.17487/RFC7103 RFC7104 Duplication Grouping Semantics in the Session Description Protocol A. Begen Y. Cai H. Ou January 2014 ASCII HTML 10 SDP ssrc synchronization source grouping framework

Packet loss is undesirable for real-time multimedia sessions, but it can occur due to congestion or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework. Grouping semantics at the Synchronization Source (SSRC) level are also defined in this document for RTP streams using SSRC multiplexing.

 draft-ietf-mmusic-duplication-grouping-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7104 RFC7105 Using Device-Provided Location-Related Measurements in Location Configuration Protocols M. Thomson J. Winterbottom January 2014 ASCII HTML 74 HELD Location Measurements Device-based

This document describes a protocol for a Device to provide location-related measurement data to a Location Information Server (LIS) within a request for location information. Location-related measurement information provides observations concerning properties related to the position of a Device; this information could be data about network attachment or about the physical environment. A LIS is able to use the location-related measurement data to improve the accuracy of the location estimate it provides to the Device. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters.

 draft-ietf-geopriv-held-measurements-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=7105 10.17487/RFC7105 RFC7106 A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State E. Ivov January 2014 ASCII HTML 6 SIP Conference Event Package service-uris conference-uris URI purpose

This document defines and registers a value of "grouptextchat" ("Group Text Chat") for the URI <purpose> element of SIP's Conference Event Package.

 draft-ivov-grouptextchat-purpose-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7106 RFC7107 Object Identifier Registry for the S/MIME Mail Security Working Group R. Housley January 2014 ASCII HTML 18

When the S/MIME Mail Security Working Group was chartered, an object identifier arc was donated by RSA Data Security for use by that working group. This document describes the object identifiers that were assigned in that donated arc, transfers control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.

 draft-housley-smime-oids-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7107 RFC7108 A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes J. Abley T. Manderson January 2014 ASCII HTML 11

Anycast is a deployment technique commonly employed for authoritative-only servers in the Domain Name System (DNS). L-Root, one of the thirteen root servers, is deployed in this fashion.

Various techniques have been used to map deployed anycast infrastructure externally, i.e., without reference to inside knowledge about where and how such infrastructure has been deployed. Motivations for performing such measurement exercises include operational troubleshooting and infrastructure risk assessment. In the specific case of L-Root, the ability to measure and map anycast infrastructure using the techniques mentioned in this document is provided for reasons of operational transparency.

This document describes all facilities deployed at L-Root to facilitate mapping of its infrastructure and serves as documentation for L-Root as a measurable service.

 draft-jabley-dnsop-anycast-mapping-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7108 10.17487/RFC7108 RFC7109 Flow Bindings Initiated by Home Agents for Mobile IPv6 H. Yokota D. Kim B. Sarikaya F. Xia February 2014 ASCII HTML 18 MIPv6 Flow mobility

There are scenarios in which the home agent needs to trigger flow binding operations towards the mobile node, such as moving a flow from one access network to another based on network resource availability. In order for the home agent to be able to initiate interactions for flow bindings with the mobile node, this document defines new signaling messages and sub-options for Mobile IPv6. Flow bindings initiated by a home agent are supported for mobile nodes enabled by both IPv4 and IPv6.

 draft-yokota-mext-ha-init-flow-binding-11 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7109 RFC7110 Return Path Specified Label Switched Path (LSP) Ping M. Chen W. Cao S. Ning F. Jounay S. Delord January 2014 ASCII HTML 21 Tunnel Stack Reply TC

This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP ping". These extensions allow a selection of the LSP to be used for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness.

 draft-ietf-mpls-return-path-specified-lsp-ping-15 RFC7737 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7110 10.17487/RFC7110 RFC7111 URI Fragment Identifiers for the text/csv Media Type M. Hausenblas E. Wilde J. Tennison January 2014 ASCII HTML 13 mime

This memo defines URI fragment identifiers for text/csv MIME entities. These fragment identifiers make it possible to refer to parts of a text/csv MIME entity identified by row, column, or cell. Fragment identification can use single items or ranges.

 draft-hausenblas-csv-fragment-08 RFC4180 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7111 10.17487/RFC7111 RFC7112 Implications of Oversized IPv6 Header Chains F. Gont V. Manral R. Bonica January 2014 ASCII HTML 8

The IPv6 specification allows IPv6 Header Chains of an arbitrary size. The specification also allows options that can, in turn, extend each of the headers. In those scenarios in which the IPv6 Header Chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the First Fragment of a packet may fail to include the entire IPv6 Header Chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the First Fragment of a packet is required to contain the entire IPv6 Header Chain.

 draft-ietf-6man-oversized-header-chain-09 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7112 RFC7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) F. Gont February 2014 ASCII HTML 13

The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA-Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated.

 draft-ietf-v6ops-ra-guard-implementation-07 RFC6105 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7113 RFC7114 Creation of a Registry for smime-type Parameter Values B. Leiba January 2014 ASCII HTML 4

Secure/Multipurpose Internet Mail Extensions (S/MIME) defined the Content-Type parameter "smime-type". As the list of defined values for that parameter has increased, it has become clear that a registry is needed to document these values. This document creates the registry, registers the current values, and specifies the policies for registration of new values.

 draft-leiba-smime-type-registry-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7114 RFC7115 Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI) R. Bush January 2014 ASCII HTML 11

Deployment of BGP origin validation that is based on the Resource Public Key Infrastructure (RPKI) has many operational considerations. This document attempts to collect and present those that are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood.

 draft-ietf-sidr-origin-ops-23 BCP0185 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=7115 10.17487/RFC7115 RFC7116 Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries K. Scott M. Blanchet February 2014 ASCII HTML 10

The DTNRG Research Group has defined the experimental Licklider Transmission Protocol (LTP) and the Compressed Bundle Header Encoding (CBHE) mechanism for the InterPlanetary Network ('ipn' URI scheme). Moreover, RFC 5050 defines values for the Bundle Protocol administrative record type. All of these fields are subject to a registry. For the purpose of its research work, the group has created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official management. This document describes the necessary IANA actions.

 draft-dtnrg-ltp-cbhe-registries-07 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=7116 10.17487/RFC7116 RFC7117 Multicast in Virtual Private LAN Service (VPLS) R. Aggarwal Editor Y. Kamite L. Fang Y. Rekhter C. Kodeboniya February 2014 ASCII HTML 50

RFCs 4761 and 4762 describe a solution for Virtual Private LAN Service (VPLS) multicast that relies on the use of point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) for carrying multicast traffic. This solution has certain limitations for certain VPLS multicast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization when a large amount of multicast traffic is to be transported.

This document describes solutions for overcoming a subset of the limitations of the existing VPLS multicast solution. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network. The solution described in this document allows sharing of one such multicast tree among multiple VPLS instances. Furthermore, the solution described in this document allows a single multicast tree in the SP network to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLS instances.

 draft-ietf-l2vpn-vpls-mcast-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn http://www.rfc-editor.org/errata_search.php?rfc=7117 10.17487/RFC7117 RFC7118 The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) I. Baz Castillo J. Millan Villegas V. Pascual January 2014 ASCII HTML 25 SIP WebSocket

The WebSocket protocol enables two-way real-time communication between clients and servers in web-based applications. This document specifies a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use of SIP in web-oriented deployments.

 draft-ietf-sipcore-sip-websocket-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=7118 10.17487/RFC7118 RFC7119 Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators B. Claise A. Kobayashi B. Trammell February 2014 ASCII HTML 32

This document specifies the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns.

 draft-ietf-ipfix-mediation-protocol-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7119 RFC7120 Early IANA Allocation of Standards Track Code Points M. Cotton January 2014 ASCII HTML 9 early allocation policy protocol

This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents.

 draft-cotton-rfc4020bis-02 RFC4020 BCP0100 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7120 RFC7121 High Availability within a Forwarding and Control Element Separation (ForCES) Network Element K. Ogawa W. Wang E. Haleplidis J. Hadi Salim February 2014 ASCII HTML 31 ForCES HA

This document discusses Control Element (CE) High Availability (HA) within a Forwarding and Control Element Separation (ForCES) Network Element (NE). Additionally, this document updates RFC 5810 by providing new normative text for the Cold Standby High Availability mechanism.

 draft-ietf-forces-ceha-10 RFC5810 RFC7391 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=7121 10.17487/RFC7121 RFC7122 Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP) H. Kruse S. Jero S. Ostermann March 2014 ASCII HTML 11

This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams. It covers convergence layers for the Bundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed. UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control. DCCP addresses the congestion control problem, and its use is recommended whenever possible. This document is a product of the Delay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG.

 draft-irtf-dtnrg-dgram-clayer-05 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7122 RFC7123 Security Implications of IPv6 on IPv4 Networks F. Gont W. Liu February 2014 ASCII HTML 19

This document discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on "IPv4-only" networks and describes possible mitigations for the aforementioned issues.

 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC7123 RFC7124 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB E. Beili February 2014 ASCII HTML 6 EFM-CU-MIB ieee

This document updates RFC 5066. It amends that specification by informing the Internet community about the transition of the EFM-CU-MIB module from the concluded IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group.

 draft-ietf-opsawg-rfc5066bis-07 RFC5066 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC7124 RFC7125 Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element B. Trammell P. Aitken February 2014 ASCII HTML 6

This document revises the tcpControlBits IP Flow Information Export (IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793.

 draft-trammell-ipfix-tcpcontrolbits-revision-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7125 RFC7126 Recommendations on Filtering of IPv4 Packets Containing IPv4 Options F. Gont R. Atkinson C. Pignataro February 2014 ASCII HTML 36

This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain.

 draft-ietf-opsec-ip-options-filtering-07 BCP0186 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=7126 10.17487/RFC7126 RFC7127 Characterization of Proposed Standards O. Kolkman S. Bradner S. Turner January 2014 ASCII HTML 5 Guidance Standards Standards Process Advancement Proposed Standard

RFC 2026 describes the review performed by the Internet Engineering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards.

 draft-kolkman-proposed-standards-clarified-06 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7127 RFC7128 Resource Public Key Infrastructure (RPKI) Router Implementation Report R. Bush R. Austein K. Patel H. Gredler M. Waehlisch February 2014 ASCII HTML 11 routing security

This document is an implementation report for the Resource Public Key Infrastructure (RPKI) Router protocol as defined in RFC 6810. The authors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. The respondents were asked to only use the "YES" answer if the feature had at least been tested in the lab.

 draft-ietf-sidr-rpki-rtr-impl-05 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC7128 RFC7129 Authenticated Denial of Existence in the DNS R. Gieben W. Mekking February 2014 ASCII HTML 30 Internet DNSSEC Denial of Existence NSEC NSEC3

Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific resource record (RR) type you were asking for. When returning a negative DNS Security Extensions (DNSSEC) response, a name server usually includes up to two NSEC records. With NSEC version 3 (NSEC3), this amount is three.

This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses.

 draft-gieben-auth-denial-of-existence-dns-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7129 RFC7130 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces M. Bhatia Editor M. Chen Editor S. Boutros Editor M. Binderberger Editor J. Haas Editor February 2014 ASCII HTML 11

This document defines a mechanism to run Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link.

This mechanism allows the verification of member link continuity, either in combination with, or in absence of, Link Aggregation Control Protocol (LACP). It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of Layer 3 (L3) bidirectional forwarding.

 draft-ietf-bfd-on-lags-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=7130 10.17487/RFC7130 RFC7131 Session Initiation Protocol (SIP) History-Info Header Call Flow Examples M. Barnes F. Audet S. Schubert H. van Elburg C. Holmberg March 2014 ASCII HTML 52 SIP History-Info RFC4244bis Example Call Flow

This document describes use cases and documents call flows that require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details.

 draft-ietf-sipcore-rfc4244bis-callflows-08 INFORMATIONAL INFORMATIONAL IETF rai sipcore 10.17487/RFC7131 RFC7132 Threat Model for BGP Path Security S. Kent A. Chi February 2014 ASCII HTML 20 BGPSEC RPKI SIDR

This document describes a threat model for the context in which External Border Gateway Protocol (EBGP) path security mechanisms will be developed. The threat model includes an analysis of the Resource Public Key Infrastructure (RPKI) and focuses on the ability of an Autonomous System (AS) to verify the authenticity of the AS path info received in a BGP update. We use the term "PATHSEC" to refer to any BGP path security technology that makes use of the RPKI. PATHSEC will secure BGP, consistent with the inter-AS security focus of the RPKI.

The document characterizes classes of potential adversaries that are considered to be threats and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in the BGP-4 standard. It concludes with a brief discussion of residual vulnerabilities.

 draft-ietf-sidr-bgpsec-threats-09 INFORMATIONAL INFORMATIONAL IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=7132 10.17487/RFC7132 RFC7133 Information Elements for Data Link Layer Traffic Measurement S. Kashima A. Kobayashi Editor P. Aitken May 2014 ASCII HTML 41 IPFIX PSAMP Provider Bridge Provider Backbone Bridge ipfix

This document describes Information Elements related to the data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information.

 draft-ietf-ipfix-data-link-layer-monitoring-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7133 RFC7134 The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review" B. Rosen March 2014 ASCII HTML 2 Resource-Priority Namespaces Resource-Priority Priority-values

RFC 4412 defines the "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries. The management policy of these registries is "Standards Action". This document normatively updates RFC 4412 to change the management policy of these registries to "IETF Review".

 draft-rosen-rph-reg-policy-01 RFC4412 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC7134 RFC7135 Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications J. Polk May 2014 ASCII HTML 9

This document creates the new Session Initiation Protocol (SIP) Resource Priority header field namespace 'esnet' and registers this namespace with IANA. The new header field namespace allows for local emergency session establishment to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations.

 draft-polk-local-emergency-rph-namespace-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7135 RFC7136 Significance of IPv6 Interface Identifiers B. Carpenter S. Jiang February 2014 ASCII HTML 10

The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly.

 draft-ietf-6man-ug-06 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7136 RFC7137 Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks A. Retana S. Ratliff February 2014 ASCII HTML 8

This document describes the use of the OSPF-MANET interface in single-hop broadcast networks. It includes a mechanism to dynamically determine the presence of such a network and specific operational considerations due to its nature.

This document updates RFC 5820.

 draft-ietf-ospf-manet-single-hop-or-04 RFC5820 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC7137 RFC7138 Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks D. Ceccarelli Editor F. Zhang S. Belotti R. Rao J. Drake March 2014 ASCII HTML 36 OSPF GMPLS G709 OTN

This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC 4203.

 draft-ietf-ccamp-gmpls-ospf-g709v3-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7138 RFC7139 GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks F. Zhang Editor G. Zhang S. Belotti D. Ceccarelli K. Pithewan March 2014 ASCII HTML 27

ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility.

This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex.

 draft-ietf-ccamp-gmpls-signaling-g709v3-12 RFC4328 RFC7892 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=7139 10.17487/RFC7139 RFC7140 LDP Extensions for Hub and Spoke Multipoint Label Switched Path L. Jin F. Jounay IJ. Wijnands N. Leymann March 2014 ASCII HTML 15 P2MP LSP MP2MP LSP

This document introduces a hub and spoke multipoint (HSMP) Label Switched Path (LSP), which allows traffic from root to leaf through point-to-multipoint (P2MP) LSPs and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from the application/customer at the root node travels downstream to each leaf node, exactly as if it were traveling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it were unicast to the root. Direct communication among the leaf nodes is not allowed.

 draft-ietf-mpls-mldp-hsmp-06 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7140 RFC7141 Byte and Packet Congestion Notification B. Briscoe J. Manner February 2014 ASCII HTML 41 active queue management aqm availability denial of service dos quality of service qos congestion control fairness incentives architecture layering protocol

This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, including Random Early Detection (RED), BLUE, Pre- Congestion Notification (PCN), and newer schemes such as CoDel (Controlled Delay) and PIE (Proportional Integral controller Enhanced). We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte- mode packet drop variant that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms.

 draft-ietf-tsvwg-byte-pkt-congest-12 RFC2309 RFC2914 BCP0041 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=7141 10.17487/RFC7141 RFC7142 Reclassification of RFC 1142 to Historic M. Shand L. Ginsberg February 2014 ASCII HTML 3

This memo reclassifies RFC 1142, "OSI IS-IS Intra-domain Routing Protocol", to Historic status. This memo also obsoletes RFC 1142.

 draft-ietf-isis-rfc1142-to-historic-00 RFC1142 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC7142 RFC7143 Internet Small Computer System Interface (iSCSI) Protocol (Consolidated) M. Chadalapaka J. Satran K. Meth D. Black April 2014 ASCII HTML 295 iSCSI SCSI storage SAN block storage SCSI object storage devices OSD SAM disk T10

This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to the iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications as well as a few improvements and corrections to the original iSCSI protocol.

This document obsoletes RFCs 3720, 3980, 4850, and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics.

 draft-ietf-storm-iscsi-cons-10 RFC3720 RFC3980 RFC4850 RFC5048 RFC3721 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7143 RFC7144 Internet Small Computer System Interface (iSCSI) SCSI Features Update F. Knight M. Chadalapaka April 2014 ASCII HTML 25

Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in RFC 7143 (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5.

 draft-ietf-storm-iscsi-sam-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7144 RFC7145 Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification M. Ko A. Nezhinsky April 2014 ASCII HTML 91

Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol.

This document obsoletes RFC 5046.

 draft-ietf-storm-iser-15 RFC5046 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7145 RFC7146 Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3 D. Black P. Koning April 2014 ASCII HTML 18 IPsec

RFC 3723 specifies IPsec requirements for block storage protocols over IP (e.g., Internet Small Computer System Interface (iSCSI)) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., the Remote Direct Memory Access Protocol (RDMAP). This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published.

 draft-ietf-storm-ipsec-ips-update-04 RFC3720 RFC3723 RFC3821 RFC3822 RFC4018 RFC4172 RFC4173 RFC4174 RFC5040 RFC5041 RFC5042 RFC5043 RFC5044 RFC5045 RFC5046 RFC5047 RFC5048 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7146 RFC7147 Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI) M. Bakke P. Venkatesen April 2014 ASCII HTML 92 ISCSI-MIB

This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP).

This document obsoletes RFC 4544.

 draft-ietf-storm-iscsimib-04 RFC4544 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7147 RFC7148 Prefix Delegation Support for Proxy Mobile IPv6 X. Zhou J. Korhonen C. Williams S. Gundavelli CJ. Bernardos March 2014 ASCII HTML 27 Prefix Delegation Proxy Mobile IPv6 PMIPv6 Mobile Router

This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes.

 draft-ietf-netext-pd-pmip-14 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7148 RFC7149 Software-Defined Networking: A Perspective from within a Service Provider Environment M. Boucadair C. Jacquenet March 2014 ASCII HTML 20 Network Automation Policy Management Connectivity Provisioning Service Parameter Exposure Dynamic Negotiation Dynamic Service Provisioning Autonomic Programmable Networks

Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment.

It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification.

 draft-sin-sdnrg-sdn-approach-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7149 RFC7150 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol F. Zhang A. Farrel March 2014 ASCII HTML 12

The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.

This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Variable that can be carried in any existing PCEP object.

 draft-ietf-pce-vendor-constraints-11 RFC7470 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC7150 RFC7151 File Transfer Protocol HOST Command for Virtual Hosts P. Hethmon R. McMurray March 2014 ASCII HTML 24 FTP HOST

The File Transfer Protocol, as defined in RFC 959, does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server.

 draft-hethmon-mcmurray-ftpext-ftp-hosts-05 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7151 RFC7152 Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN) R. Key Editor S. DeLord F. Jounay L. Huang Z. Liu M. Paul March 2014 ASCII HTML 12 RMP Rooted-Multipoint VPLS Virtual Private LAN Service E-VPN Ethernet Virtual Private Network MPLS Multi-Protocol Label Switching CE Carrier Ethernet

This document provides functional requirements for the support of Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer 2 Virtual Private Network solutions (referred to as simply "L2VPN"). It is intended that potential solutions will use these requirements as guidelines.

 draft-ietf-l2vpn-etree-reqt-05 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7152 RFC7153 IANA Registries for BGP Extended Communities E. Rosen Y. Rekhter March 2014 ASCII HTML 16 Border Gateway Protocol

This document reorganizes the IANA registries for the type values and sub-type values of the BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. This is done in order to remove interdependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations and thus do not affect protocol implementations. The changes will, however, impact the "IANA Considerations" sections of future protocol specifications. This document updates RFC 4360 and RFC 5701.

 draft-ietf-idr-extcomm-iana-02 RFC4360 RFC5701 RFC9184 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7153 RFC7154 IETF Guidelines for Conduct S. Moonesamy Editor March 2014 ASCII HTML 7

This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work.

This document is an updated version of the guidelines for conduct originally published in RFC 3184.

 draft-moonesamy-ietf-conduct-3184bis-07 RFC3184 BCP0054 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7154 RFC7155 Diameter Network Access Server Application G. Zorn Editor April 2014 ASCII HTML 70 AAA Authentication Authorization Accounting Remote Access

This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting services in the Network Access Server (NAS) environment; it obsoletes RFC 4005. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements.

 draft-ietf-dime-rfc4005bis-14 RFC4005 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=7155 10.17487/RFC7155 RFC7156 Diameter Support for Proxy Mobile IPv6 Localized Routing G. Zorn Q. Wu J. Korhonen April 2014 ASCII HTML 11

In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized. This document specifies how to accomplish this using the Diameter protocol.

 draft-ietf-dime-pmip6-lr-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7156 RFC7157 IPv6 Multihoming without Network Address Translation O. Troan Editor D. Miles S. Matsushima T. Okimoto D. Wing March 2014 ASCII HTML 22 NPTv6

Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution. For IPv6 hosts, one approach could be the use of IPv6-to-IPv6 Network Prefix Translation (NPTv6). However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6-allocation criteria. We conclude that DHCPv6-based solutions are suitable to solve the multihoming issues described in this document, but NPTv6 may be required as an intermediate solution.

 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7157 RFC7158 The JavaScript Object Notation (JSON) Data Interchange Format T. Bray Editor March 2014 ASCII HTML 16

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.

This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.

 draft-ietf-json-rfc4627bis-10 RFC7159 PROPOSED STANDARD PROPOSED STANDARD IETF app json 10.17487/RFC7158 RFC7159 The JavaScript Object Notation (JSON) Data Interchange Format T. Bray Editor March 2014 ASCII HTML 16

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.

This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.

 draft-ietf-json-rfc4627bis-rfc7159bis RFC4627 RFC7158 RFC8259 PROPOSED STANDARD PROPOSED STANDARD IETF app json http://www.rfc-editor.org/errata_search.php?rfc=7159 10.17487/RFC7159 RFC7160 Support for Multiple Clock Rates in an RTP Session M. Petit-Huguenin G. Zorn Editor April 2014 ASCII HTML 13

This document clarifies the RTP specification regarding the use of different clock rates in an RTP session. It also provides guidance on how legacy RTP implementations that use multiple clock rates can interoperate with RTP implementations that use the algorithm described in this document. It updates RFC 3550.

 draft-ietf-avtext-multiple-clock-rates-11 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC7160 RFC7161 Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL) LM. Contreras CJ. Bernardos I. Soto March 2014 ASCII HTML 37 PMIPv6 Proxy Mobile IPv6 multicast handover SIAL

This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 (PMIPv6) to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism, called Subscription Information Acquisition through the LMA (SIAL), is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current PMIPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem. Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (acting as either multicast listener discovery proxy or multicast router).

 draft-ietf-multimob-handover-optimization-07 EXPERIMENTAL EXPERIMENTAL IETF int multimob http://www.rfc-editor.org/errata_search.php?rfc=7161 10.17487/RFC7161 RFC7162 IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC) A. Melnikov D. Cridland May 2014 ASCII HTML 52 IMAP CONDSTORE QRESYNC VANISHED EXPUNGE quick resynchronization

Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox.

Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience.

This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162.

Finally, this document also updates the line-length recommendation in Section 3.2.1.5 of RFC 2683.

 draft-ietf-qresync-rfc5162bis-10 RFC4551 RFC5162 RFC2683 PROPOSED STANDARD PROPOSED STANDARD IETF app qresync http://www.rfc-editor.org/errata_search.php?rfc=7162 10.17487/RFC7162 RFC7163 URN for Country-Specific Emergency Services C. Holmberg I. Sedlacek March 2014 ASCII HTML 4 sip emergency urn country 5031 sos

This document updates the registration guidance provided in Section 4.2 of RFC 5031, which allows the registration of service URNs with the 'sos' service type only for emergency services "that are offered widely and in different countries". This document updates those instructions to allow such registrations when, at the time of registration, those services are offered in only one country.

 draft-ietf-ecrit-country-emg-urn-03 RFC5031 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC7163 RFC7164 RTP and Leap Seconds K. Gross R. Brandenburg March 2014 ASCII HTML 9 Leap second rtp Real-time Transport Protocol ntp Network Time Protocol UTC Universal Coordinated Time tai International Atomic Time Unix time

This document discusses issues that arise when RTP sessions span Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550 by describing how RTP senders and receivers should behave in the presence of leap seconds.

 draft-ietf-avtcore-leap-second-08 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7164 RFC7165 Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) R. Barnes April 2014 ASCII HTML 25 JWS JWE JWK JWA JWT CMS S/MIME JOSE XMPP ALTO OAuth

Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer. For many years, the Cryptographic Message Syntax (CMS) has provided a binary secure object format based on ASN.1. Over time, binary object encodings such as ASN.1 have become less common than text-based encodings, such as the JavaScript Object Notation (JSON). This document defines a set of use cases and requirements for a secure object format encoded using JSON, drawn from a variety of application security mechanisms currently in development.

 draft-ietf-jose-use-cases-06 INFORMATIONAL INFORMATIONAL IETF sec jose 10.17487/RFC7165 RFC7166 Supporting Authentication Trailer for OSPFv3 M. Bhatia V. Manral A. Lindem March 2014 ASCII HTML 23

Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.

The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.

 draft-ietf-ospf-rfc6506bis-05 RFC6506 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7166 RFC7167 A Framework for Point-to-Multipoint MPLS in Transport Networks D. Frost S. Bryant M. Bocci L. Berger April 2014 ASCII HTML 12 mpls-tp mpls

The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths. This document defines the elements and functions of the MPLS-TP architecture that are applicable specifically to supporting point-to-multipoint transport paths.

 draft-ietf-mpls-tp-p2mp-framework-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7167 RFC7168 The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) I. Nazar April 1 2014 ASCII HTML 7

The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity. This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities.

 draft-nazar-htcpcp-tea-00 RFC2324 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7168 RFC7169 The NSA (No Secrecy Afforded) Certificate Extension S. Turner April 1 2014 ASCII HTML 3

This document defines the NSA (No Secrecy Afforded) certificate extension appropriate for use in certain PKIX (X.509 Pubic Key Certificates) digital certificates. Historically, clients and servers strived to maintain the privacy of their keys; however, the secrecy of their private keys cannot always be maintained. In certain circumstances, a client or a server might feel that they will be compelled in the future to share their keys with a third party. Some clients and servers also have been compelled to share their keys and wish to indicate to relying parties upon certificate renewal that their keys have in fact been shared with a third party.

 draft-turner-no-secrecy-afforded-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7169 RFC7170 Tunnel Extensible Authentication Protocol (TEAP) Version 1 H. Zhou N. Cam-Winget J. Salowey S. Hanna May 2014 ASCII HTML 101 EAP Tunnel

This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server.

 draft-ietf-emu-eap-tunnel-method-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu http://www.rfc-editor.org/errata_search.php?rfc=7170 10.17487/RFC7170 RFC7171 PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods N. Cam-Winget P. Sangster May 2014 ASCII HTML 19 NEA EAP

This document specifies PT-EAP, a Posture Transport (PT) protocol based on the Extensible Authentication Protocol (EAP) and designed to be used only inside an EAP tunnel method protected by Transport Layer Security (TLS). The document also describes the intended applicability of PT-EAP.

 draft-ietf-nea-pt-eap-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea 10.17487/RFC7171 RFC7172 Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling D. Eastlake 3rd M. Zhang P. Agarwal R. Perlman D. Dutt May 2014 ASCII HTML 27 TRILL VLAN Fine-Grained Label

The IETF has standardized Transparent Interconnection of Lots of Links (TRILL), a protocol for least-cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. The TRILL base protocol standard supports the labeling of TRILL Data packets with up to 4K IDs. However, there are applications that require a larger number of labels providing configurable isolation of data. This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this. These extensions, called fine-grained labeling, are primarily intended for use in large data centers, that is, those with more than 4K users requiring configurable data isolation from each other.

 draft-ietf-trill-fine-labeling-07 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7172 RFC7173 Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires L. Yong D. Eastlake 3rd S. Aldrin J. Hudson May 2014 ASCII HTML 11 TRILL pseudowires MPLS RBridge

This document specifies how to interconnect a pair of Transparent Interconnection of Lots of Links (TRILL) switch ports using pseudowires under existing TRILL and Pseudowire Emulation End-to-End (PWE3) standards.

 draft-ietf-trill-o-pw-06 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7173 RFC7174 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework S. Salam T. Senevirathne S. Aldrin D. Eastlake 3rd May 2014 ASCII HTML 33 RBridge CFM BFD MEP MIP MA Fault Performance Maintenance Continuity Connectivity Delay Operations Administration

This document specifies a reference framework for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) networks. The focus of the document is on the fault and performance management aspects of TRILL OAM.

 draft-ietf-trill-oam-framework-04 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC7174 RFC7175 Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support V. Manral D. Eastlake 3rd D. Ward A. Banerjee May 2014 ASCII HTML 12 RBridge Echo one-hop

This document specifies use of the Bidirectional Forwarding Detection (BFD) protocol in Routing Bridge (RBridge) campuses based on the RBridge Channel extension to the Transparent Interconnection of Lots of Links (TRILL) protocol.

BFD is a widely deployed Operations, Administration, and Maintenance (OAM) mechanism in IP and MPLS networks, using UDP and Associated Channel Header (ACH) encapsulation respectively. This document specifies the BFD encapsulation over TRILL.

 draft-ietf-trill-rbridge-bfd-07 RFC8564 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7175 RFC7176 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS D. Eastlake 3rd T. Senevirathne A. Ghanwani D. Dutt A. Banerjee May 2014 ASCII HTML 45 Affinity multicast multi-topology fine-grained VLAN

The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology; it also provides support for multipathing of both unicast and multicast traffic. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. These data formats and code points may also be used by technologies other than TRILL. This document obsoletes RFC 6326.

 draft-ietf-isis-rfc6326bis-03 RFC6326 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7176 RFC7177 Transparent Interconnection of Lots of Links (TRILL): Adjacency D. Eastlake 3rd R. Perlman A. Ghanwani H. Yang V. Manral May 2014 ASCII HTML 35 RBridge TRILL Adjacency BFD p2p point-to-point

The IETF Transparent Interconnection of Lots of Links (TRILL) protocol supports arbitrary link technologies between TRILL switches, including point-to-point links and multi-access Local Area Network (LAN) links that can have multiple TRILL switches and end stations attached. TRILL uses Intermediate System to Intermediate System (IS-IS) routing. This document specifies the establishment, reporting, and termination of IS-IS adjacencies between TRILL switches, also known as RBridges (Routing Bridges). It also concerns four other link-local aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bidirectional Forwarding Detection) session bootstrapping in connection with adjacency. State diagrams are included where appropriate. This document obsoletes RFC 6327 and updates RFC 6325.

 draft-ietf-trill-rfc6327bis-04 RFC6327 RFC6325 RFC7780 RFC8139 RFC8249 RFC8377 RFC8564 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7177 RFC7178 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support D. Eastlake 3rd V. Manral Y. Li S. Aldrin D. Ward May 2014 ASCII HTML 21 TRILL native

This document specifies a general channel mechanism for sending messages, such as Bidirectional Forwarding Detection (BFD) messages, between Routing Bridges (RBridges) and between RBridges and end stations in an RBridge campus through extensions to the Transparent Interconnection of Lots of Links (TRILL) protocol.

 draft-ietf-trill-rbridge-channel-08 RFC7978 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7178 RFC7179 Transparent Interconnection of Lots of Links (TRILL): Header Extension D. Eastlake 3rd A. Ghanwani V. Manral Y. Li C. Bestler May 2014 ASCII HTML 12 RBridge extension option

The IETF Transparent Interconnection of Lots of Links (TRILL) base protocol (RFC 6325) specifies minimal hooks to safely support TRILL Header extensions. This document specifies an initial extension providing additional flag bits and specifies some of those bits. It updates RFC 6325.

 draft-ietf-trill-rbridge-extension-05 RFC6325 RFC7780 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7179 RFC7180 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates D. Eastlake 3rd M. Zhang A. Ghanwani V. Manral A. Banerjee May 2014 ASCII HTML 24 TRILL RBridge IS-IS reachability overload MTU DEI multicast

The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology and link technology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using Intermediate System to Intermediate System (IS-IS) link-state routing and by encapsulating traffic using a header that includes a hop count. Since publication of the TRILL base protocol in July 2011, active development of TRILL has revealed errata in RFC 6325 and some cases that could use clarifications or updates.

RFCs 6327 and 6439 provide clarifications and updates with respect to adjacency and Appointed Forwarders. This document provides other known clarifications, corrections, and updates to RFCs 6325, 6327, and 6439.

 draft-ietf-trill-clear-correct-06 RFC7780 RFC6325 RFC6327 RFC6439 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7180 RFC7181 The Optimized Link State Routing Protocol Version 2 T. Clausen C. Dearlove P. Jacquet U. Herberg April 2014 ASCII HTML 115 MANET ad hoc network NHDP

This specification describes version 2 of the Optimized Link State Routing Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs).

 draft-ietf-manet-olsrv2-19 RFC7183 RFC7187 RFC7188 RFC7466 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=7181 10.17487/RFC7181 RFC7182 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) U. Herberg T. Clausen C. Dearlove April 2014 ASCII HTML 31 NHDP OLSRv2 security integrity routing

This document revises, extends, and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) and timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively.

 draft-ietf-manet-rfc6622-bis-06 RFC6622 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=7182 10.17487/RFC7182 RFC7183 Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) U. Herberg C. Dearlove T. Clausen April 2014 ASCII HTML 15 MANET OLSRv2 Security Integrity protection ICV

This document specifies integrity and replay protection for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This protection is achieved by using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a Timestamp TLV based on Portable Operating System Interface (POSIX) time.

The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444.

This document updates RFC 6130 and RFC 7181 by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2.

 draft-ietf-manet-nhdp-olsrv2-sec-05 RFC6130 RFC7181 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=7183 10.17487/RFC7183 RFC7184 Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2 U. Herberg R. Cole T. Clausen April 2014 ASCII HTML 86 Network Management Management Information Base MIB SMIv2 Routing MANET Optimized Link STate Routing Protocol version 2

This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing Protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into configuration information, state information, performance information, and notifications. This additional state and performance information is useful for troubleshooting problems and performance issues of the routing protocol. Two levels of compliance allow this MIB module to be deployed on constrained routers.

 draft-ietf-manet-olsrv2-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7184 RFC7185 Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale C. Dearlove T. Clausen P. Jacquet April 2014 ASCII HTML 25 MANET ad hoc network proactive NHDP neighborhood discovery OLSR OLSRv2 routing protocol metrics

The Optimized Link State Routing Protocol version 2 (OLSRv2) includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2.

 draft-ietf-manet-olsrv2-metrics-rationale-04 INFORMATIONAL INFORMATIONAL IETF rtg manet 10.17487/RFC7185 RFC7186 Security Threats for the Neighborhood Discovery Protocol (NHDP) J. Yi U. Herberg T. Clausen April 2014 ASCII HTML 20

This document analyzes common security threats of the Neighborhood Discovery Protocol (NHDP) and describes their potential impacts on Mobile Ad Hoc Network (MANET) routing protocols using NHDP. This document is not intended to propose solutions to the threats described.

 draft-ietf-manet-nhdp-sec-threats-06 RFC7985 INFORMATIONAL INFORMATIONAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=7186 10.17487/RFC7186 RFC7187 Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2) C. Dearlove T. Clausen April 2014 ASCII HTML 5

This specification updates the Optimized Link State Routing Protocol version 2 (OLSRv2) with an optimization to improve the selection of routing multipoint relays. The optimization retains full interoperability between implementations of OLSRv2 with and without this optimization.

 draft-ietf-manet-olsrv2-rmpr-optimization-01 RFC7181 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7187 RFC7188 Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs C. Dearlove T. Clausen April 2014 ASCII HTML 16 MANET OLSRv2 NHDP TLV

This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP) to increase their abilities to accommodate protocol extensions. This document updates RFC 7181 (OLSRv2) and RFC 6130 (NHDP).

 draft-ietf-manet-nhdp-olsrv2-tlv-extension-05 RFC6130 RFC7181 RFC7722 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7188 RFC7189 Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP) G. Mirsky March 2014 ASCII HTML 7 PW VCCV MPLS-TP CC/CV/RDI

This document specifies how signaling and selection processes for Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) are modified to ensure backward compatibility and allow use of proactive Connectivity Verification (CV), Continuity Check (CC), and Remote Defect Indication (RDI) over MPLS Transport Profile (MPLS-TP) PWs. This document introduces four new CV types and, to accommodate them, a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV is defined.

 draft-ietf-pwe3-mpls-tp-cv-adv-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7189 RFC7190 Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP) C. Villamizar March 2014 ASCII HTML 15 MPLS composite link link aggregation ECMP link bundling multipath MPLS-TP

Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly in very high-bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP Operations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations.

Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed.

 draft-ietf-mpls-multipath-use-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7190 RFC7191 Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types R. Housley April 2014 ASCII HTML 25

This document defines the syntax for two Cryptographic Message Syntax (CMS) content types: one for key package receipts and another for key package errors. The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages. The key package error content type is used to indicate an error occurred during the processing of a key package. CMS can be used to digitally sign, digest, authenticate, or encrypt these content types.

 draft-housley-ct-keypackage-receipt-n-error-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7191 RFC7192 Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types S. Turner April 2014 ASCII HTML 6 Key Package Key Package Receipt Key Package Error

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types. Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData.

 draft-turner-ct-keypackage-receipt-n-error-algs-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7192 RFC7193 The application/cms Media Type S. Turner R. Housley J. Schaad April 2014 ASCII HTML 12 Cryptographic Message Syntax

This document registers the application/cms media type for use with the corresponding CMS (Cryptographic Message Syntax) content types.

 draft-turner-application-cms-media-type-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7193 10.17487/RFC7193 RFC7194 Default Port for Internet Relay Chat (IRC) via TLS/SSL R. Hartmann August 2014 ASCII HTML 6

This document describes the commonly accepted practice of listening on TCP port 6697 for incoming Internet Relay Chat (IRC) connections encrypted via TLS/SSL.

 draft-hartmann-default-port-for-irc-via-tls-ssl-09 RFC1459 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7194 RFC7195 Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) M. Garcia-Martin S. Veikkolainen May 2014 ASCII HTML 39 PSTN

This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) offer/answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN).

 draft-ietf-mmusic-sdp-cs-23 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7195 RFC7196 Making Route Flap Damping Usable C. Pelsser R. Bush K. Patel P. Mohapatra O. Maennel May 2014 ASCII HTML 8 rfd

Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits in order to reduce the high risks with RFD. The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes' normal convergence process.

 draft-ietf-idr-rfd-usable-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=7196 10.17487/RFC7196 RFC7197 Duplication Delay Attribute in the Session Description Protocol A. Begen Y. Cai H. Ou April 2014 ASCII HTML 11 Interleaving temporal diversity temporal redundancy time shifted delayed duplication

A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as "time-shifted redundancy", "temporal redundancy", or simply "delayed duplication". This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol.

 draft-ietf-mmusic-delayed-duplication-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7197 RFC7198 Duplicating RTP Streams A. Begen C. Perkins April 2014 ASCII HTML 13 RTP duplication live/live redundancy

Packet loss is undesirable for real-time multimedia sessions but can occur due to a variety of reasons including unplanned network outages. In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration, due to the potentially large number of missing packets. In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage. For this challenge, one solution that does not incur unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules.

 draft-ietf-avtext-rtp-duplication-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC7198 RFC7199 Location Configuration Extensions for Policy Management R. Barnes M. Thomson J. Winterbottom H. Tschofenig April 2014 ASCII HTML 20 geopriv geolocation privacy policy

Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI so that the host can view or set these rules.

 draft-ietf-geopriv-policy-uri-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7199 RFC7200 A Session Initiation Protocol (SIP) Load-Control Event Package C. Shen H. Schulzrinne A. Koike April 2014 ASCII HTML 44 SIP Overload Control Server Performance

This specification defines a load-control event package for the Session Initiation Protocol (SIP). It allows SIP entities to distribute load-filtering policies to other SIP entities in the network. The load-filtering policies contain rules to throttle calls from a specific user or based on their source or destination domain, telephone number prefix. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts.

 draft-ietf-soc-load-control-event-package-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai soc 10.17487/RFC7200 RFC7201 Options for Securing RTP Sessions M. Westerlund C. Perkins April 2014 ASCII HTML 37 Secure RTP SRTP key management real-time media

The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism.

 draft-ietf-avtcore-rtp-security-options-10 INFORMATIONAL INFORMATIONAL IETF rai avtcore 10.17487/RFC7201 RFC7202 Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution C. Perkins M. Westerlund April 2014 ASCII HTML 10 SRTP RTP Profile Payload Format

This memo discusses the problem of securing real-time multimedia sessions. It also explains why the Real-time Transport Protocol (RTP) and the associated RTP Control Protocol (RTCP) do not mandate a single media security mechanism. This is relevant for designers and reviewers of future RTP extensions to ensure that appropriate security mechanisms are mandated and that any such mechanisms are specified in a manner that conforms with the RTP architecture.

 draft-ietf-avt-srtp-not-mandatory-16 INFORMATIONAL INFORMATIONAL IETF rai avtcore 10.17487/RFC7202 RFC7203 An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information T. Takahashi K. Landfield Y. Kadobayashi April 2014 ASCII HTML 28 data structure information architecture incident response response team security incident information exchange knowledge sharing security operation automation vulnerability CERT CSIRT

This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to exchange enriched cybersecurity information among security experts at organizations and facilitate their operations. It provides a well-defined pattern to consistently embed structured information, such as identifier- and XML-based information.

 draft-ietf-mile-sci-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile http://www.rfc-editor.org/errata_search.php?rfc=7203 10.17487/RFC7203 RFC7204 Requirements for Labeled NFS T. Haynes April 2014 ASCII HTML 18 NFSv4

This memo outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into the Network File System (NFS) version 4.2 (NFSv4.2). It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. The intent here is not to present the protocol changes but to describe the environment in which they reside.

 draft-ietf-nfsv4-labreqs-05 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC7204 RFC7205 Use Cases for Telepresence Multistreams A. Romanow S. Botzko M. Duckworth R. Even Editor April 2014 ASCII HTML 17

Telepresence conferencing systems seek to create an environment that gives users (or user groups) that are not co-located a feeling of co-located presence through multimedia communication that includes at least audio and video signals of high fidelity. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would enable senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference.

 draft-ietf-clue-telepresence-use-cases-09 INFORMATIONAL INFORMATIONAL IETF rai clue 10.17487/RFC7205 RFC7206 Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks P. Jones G. Salgueiro J. Polk L. Liess H. Kaplan May 2014 ASCII HTML 15

This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains.

 draft-ietf-insipid-session-id-reqts-11 INFORMATIONAL INFORMATIONAL IETF rai insipid 10.17487/RFC7206 RFC7207 A Uniform Resource Name (URN) Namespace for Eurosystem Messaging M. Ortseifen G. Dickfeld April 2014 ASCII HTML 8 URN Namespace Eurosystem TARGET2 TARGET2-Securities ESCB

This document defines and registers with IANA a Uniform Resource Name (URN) namespace for usage within messages standardized by the Eurosystem. The URN namespace is managed by Deutsche Bundesbank, which is a member of the European System of Central Banks (ESCB).

 draft-bundesbank-eurosystem-namespace-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7207 RFC7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 S. Kitterman April 2014 ASCII HTML 64 spoofing spf anti-forgery authentication

Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.

This document obsoletes RFC 4408.

 draft-ietf-spfbis-4408bis-21 RFC4408 RFC7372 RFC8553 RFC8616 PROPOSED STANDARD PROPOSED STANDARD IETF app spfbis http://www.rfc-editor.org/errata_search.php?rfc=7208 10.17487/RFC7208 RFC7209 Requirements for Ethernet VPN (EVPN) A. Sajassi R. Aggarwal J. Uttaro N. Bitar W. Henderickx A. Isaac May 2014 ASCII HTML 15 ethernet l2vpn

The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multihoming with all-active forwarding is not supported, and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution, which addresses the above issues.

 draft-ietf-l2vpn-evpn-req-07 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn http://www.rfc-editor.org/errata_search.php?rfc=7209 10.17487/RFC7209 RFC7210 Database of Long-Lived Symmetric Cryptographic Keys R. Housley T. Polk S. Hartman D. Zhang April 2014 ASCII HTML 14

This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different routing protocols for message security. The database is designed to support both manual and automated key management. In addition to describing the schema for the database, this document describes the operations that can be performed on the database as well as the requirements for the routing protocols that wish to use the database. In many typical scenarios, the protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short-lived key from a long-lived key.

 draft-ietf-karp-crypto-key-table-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg karp http://www.rfc-editor.org/errata_search.php?rfc=7210 10.17487/RFC7210 RFC7211 Operations Model for Router Keying S. Hartman D. Zhang June 2014 ASCII HTML 18

The IETF is engaged in an effort to analyze the security of routing protocol authentication according to design guidelines discussed in RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines". Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the deployability of these efforts. This document gives recommendations to operators and implementors regarding management and operation of router authentication. These recommendations will also assist protocol designers in understanding management issues they will face.

 draft-ietf-karp-ops-model-10 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC7211 RFC7212 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol D. Frost S. Bryant M. Bocci June 2014 ASCII HTML 23

The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes.

 draft-ietf-mpls-gach-adv-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7212 RFC7213 MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing D. Frost S. Bryant M. Bocci June 2014 ASCII HTML 9 MPLS

The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets.

 draft-ietf-mpls-tp-ethernet-addressing-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7213 RFC7214 Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry L. Andersson C. Pignataro May 2014 ASCII HTML 7

RFC 5586 generalized the applicability of the pseudowire Associated Channel Header (PW-ACH) into the Generic Associated Channel G-ACh. However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries. This document coalesces these into a new "Generic Associated Channel (G-ACh) Parameters" registry under the "Multiprotocol Label Switching Architecture (MPLS)" heading. This document updates RFC 5586.

This document also updates RFCs 6374, 6378, 6427, and 6428.

 draft-ietf-mpls-moving-iana-registries-04 RFC5586 RFC6374 RFC6378 RFC6427 RFC6428 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7214 RFC7215 Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations L. Jakab A. Cabellos-Aparicio F. Coras J. Domingo-Pascual D. Lewis April 2014 ASCII HTML 30 LISP deployment

This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding.

 draft-ietf-lisp-deployment-12 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC7215 RFC7216 Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS M. Thomson R. Bellis April 2014 ASCII HTML 18 HELD LIS Discovery NAT Residential Gateway

The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway.

This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device.

 draft-ietf-geopriv-res-gw-lis-discovery-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7216 RFC7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) F. Gont April 2014 ASCII HTML 19

This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).

 draft-ietf-6man-stable-privacy-addresses-17 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7217 RFC7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE) O. Gudmundsson April 2014 ASCII HTML 5 DNSSEC DANE Applications

Experience has shown that people get confused when discussing the three numeric fields of the TLSA record. This document specifies descriptive acronyms for the three numeric fields in TLSA records. This document updates the format of the IANA registry created by RFC 6698.

 draft-ietf-dane-registry-acronyms-04 RFC6698 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane 10.17487/RFC7218 RFC7219 SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI) M. Bagnulo A. Garcia-Martinez May 2014 ASCII HTML 38 IPv6 ingress filtering packet filtering Neighbor Discovery

This memo specifies SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI), a mechanism to provide source address validation using the SEND protocol. The proposed mechanism complements ingress filtering techniques to provide a finer granularity on the control of IPv6 source addresses.

 draft-ietf-savi-send-11 PROPOSED STANDARD PROPOSED STANDARD IETF int savi 10.17487/RFC7219 RFC7220 Description Option for the Port Control Protocol (PCP) M. Boucadair R. Penno D. Wing May 2014 ASCII HTML 6

This document extends the Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping. It does this by defining a new DESCRIPTION option.

 draft-ietf-pcp-description-option-05 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7220 RFC7221 Handling of Internet-Drafts by IETF Working Groups A. Farrel D. Crocker Editor April 2014 ASCII HTML 14 IETF process working group Internet-Draft adoption handling creation

The productive output of an IETF working group is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication.

 draft-crocker-id-adoption-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7221 RFC7222 Quality-of-Service Option for Proxy Mobile IPv6 M. Liebsch P. Seite H. Yokota J. Korhonen S. Gundavelli May 2014 ASCII HTML 58 QoS Quality of Service PMIP-QoS PMIPv6-QoS WiFi-QoS 3GPP-QoS

This specification defines a new mobility option, the Quality-of- Service (QoS) option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating Quality-of-Service parameters for a mobile node's IP flows. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway. Furthermore, making QoS parameters available on the mobile access gateway enables mapping of these parameters to QoS rules that are specific to the access technology and allows those rules to be enforced on the access network using access-technology-specific approaches.

 draft-ietf-netext-pmip6-qos-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7222 RFC7223 A YANG Data Model for Interface Management M. Bjorklund May 2014 ASCII HTML 39 NETCONF ietf-interfaces

This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes configuration data and state data (status information and counters for the collection of statistics).

 draft-ietf-netmod-interfaces-cfg-16 RFC8343 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7223 10.17487/RFC7223 RFC7224 IANA Interface Type YANG Module M. Bjorklund May 2014 ASCII HTML 37 yang netconf iana-if-type

This document defines the initial version of the iana-if-type YANG module.

 draft-ietf-netmod-iana-if-type-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC7224 RFC7225 Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP) M. Boucadair May 2014 ASCII HTML 17

This document defines a new Port Control Protocol (PCP) option to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This option is needed for successful communications when IPv4 addresses are used in referrals.

 draft-ietf-pcp-nat64-prefix64-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7225 RFC7226 Requirements for Advanced Multipath in MPLS Networks C. Villamizar Editor D. McDysan Editor S. Ning A. Malis L. Yong May 2014 ASCII HTML 17 MPLS Advanced Multipath composite link link aggregation ECMP link bundling delay metric

This document provides a set of requirements for Advanced Multipath in MPLS networks.

Advanced Multipath is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques.

 draft-ietf-rtgwg-cl-requirement-16 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC7226 RFC7227 Guidelines for Creating New DHCPv6 Options D. Hankins T. Mrugalski M. Siodelski S. Jiang S. Krishnan May 2014 ASCII HTML 35 DHCPv6 option guidelines option guidance option format

This document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software. It also provides guidelines for expert reviewers to evaluate new registrations. This document updates RFC 3315.

 draft-ietf-dhc-option-guidelines-17 RFC3315 BCP0187 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=7227 10.17487/RFC7227 RFC7228 Terminology for Constrained-Node Networks C. Bormann M. Ersue A. Keranen May 2014 ASCII HTML 17 IoT Internet of Things Embedded Internet Smart Object Sensor Network WSN Constrained node Constrained network LLN LoWPAN 6LoWPAN Always-on Low-power Energy efficient

The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.

 draft-ietf-lwig-terminology-07 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC7228 RFC7229 Object Identifiers for Test Certificate Policies R. Housley May 2014 ASCII HTML 4

This document provides several certificate policy identifiers for testing certificate handling software.

 draft-housley-pkix-test-oids-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7229 RFC7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing R. Fielding Editor J. Reschke Editor June 2014 ASCII HTML 89 Hyptertext Transfer Protocol HTTP HTTP message format

The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.

 draft-ietf-httpbis-p1-messaging-26 RFC2145 RFC2616 RFC9110 RFC9112 RFC2817 RFC2818 RFC8615 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7230 10.17487/RFC7230 RFC7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content R. Fielding Editor J. Reschke Editor June 2014 ASCII HTML 101 Hypertext Transfer Protocol HTTP HTTP semantics HTTP payload HTTP content HTTP method HTTP status code

The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.

 draft-ietf-httpbis-p2-semantics-26 RFC2616 RFC9110 RFC2817 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7231 10.17487/RFC7231 RFC7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests R. Fielding Editor J. Reschke Editor June 2014 ASCII HTML 28 HyperText Transfer Protocol HTTP HTTP conditional requests

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.

 draft-ietf-httpbis-p4-conditional-26 RFC2616 RFC9110 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7232 10.17487/RFC7232 RFC7233 Hypertext Transfer Protocol (HTTP/1.1): Range Requests R. Fielding Editor Y. Lafon Editor J. Reschke Editor June 2014 ASCII HTML 25

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.

 draft-ietf-httpbis-p5-range-26 RFC2616 RFC9110 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7233 10.17487/RFC7233 RFC7234 Hypertext Transfer Protocol (HTTP/1.1): Caching R. Fielding Editor M. Nottingham Editor J. Reschke Editor June 2014 ASCII HTML 43 HTTP caching HyperText Transfer Protocol HTTP

The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.

 draft-ietf-httpbis-p6-cache-26 RFC2616 RFC9111 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7234 10.17487/RFC7234 RFC7235 Hypertext Transfer Protocol (HTTP/1.1): Authentication R. Fielding Editor J. Reschke Editor June 2014 ASCII HTML 19 HTTP authentication HyperText Transfer Protocol HTTP

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.

 draft-ietf-httpbis-p7-auth-26 RFC2616 RFC2617 RFC9110 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7235 10.17487/RFC7235 RFC7236 Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations J. Reschke June 2014 ASCII HTML 3 HyperText Transfer Protocol HTTP Authentication Authentication Scheme

This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established.

 draft-ietf-httpbis-authscheme-registrations-10 INFORMATIONAL INFORMATIONAL IETF app httpbis 10.17487/RFC7236 RFC7237 Initial Hypertext Transfer Protocol (HTTP) Method Registrations J. Reschke June 2014 ASCII HTML 5 HyperText Transfer Protocol HTTP Request Method

This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP Method Registry was established.

 draft-ietf-httpbis-method-registrations-15 INFORMATIONAL INFORMATIONAL IETF app httpbis 10.17487/RFC7237 RFC7238 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) J. Reschke June 2014 ASCII HTML 6 HTTP redirect status code

This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).

 draft-reschke-http-status-308-07 RFC7538 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC7238 RFC7239 Forwarded HTTP Extension A. Petersson M. Nilsson June 2014 ASCII HTML 16 proxy x-forwarded-for x-forwarded-by x-forwarded-host x-forwarded-proto via

This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests.

This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.

 draft-ietf-appsawg-http-forwarded-10 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7239 10.17487/RFC7239 RFC7240 Prefer Header for HTTP J. Snell June 2014 ASCII HTML 17 http prefer

This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.

 draft-snell-http-prefer-18 RFC8144 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7240 10.17487/RFC7240 RFC7241 The IEEE 802/IETF Relationship S. Dawkins P. Thaler D. Romascanu B. Aboba Editor July 2014 ASCII HTML 35 snmp aaa simple network management protocol authentication authorization accounting

This document describes the standardization cooperation between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441.

Note: This document was collaboratively developed by authors from both the IEEE 802 and IETF leadership and was reviewed and approved by the IEEE 802 Executive Committee prior to publication.

 draft-iab-rfc4441rev-08 RFC4441 RFC9141 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7241 10.17487/RFC7241 RFC7242 Delay-Tolerant Networking TCP Convergence-Layer Protocol M. Demmer J. Ott S. Perreault June 2014 ASCII HTML 22

This document describes the protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN). It is the product of the IRTF's DTN Research Group (DTNRG).

 draft-irtf-dtnrg-tcp-clayer-09 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7242 RFC7243 RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric V. Singh Editor J. Ott I. Curcio May 2014 ASCII HTML 12 rtp reception statistics de-jitter buffer

The RTP Control Protocol (RTCP) is used in conjunction with the Real-time Transport Protocol (RTP) to provide a variety of short-term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a report computing the bytes discarded from the de-jitter buffer after successful reception.

 draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7243 RFC7244 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting H. Asaeda Q. Wu R. Huang May 2014 ASCII HTML 13

This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of initial synchronization delay and synchronization offset metrics for use in a range of RTP applications.

 draft-ietf-xrblock-rtcp-xr-synchronization-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7244 RFC7245 An Architecture for Media Recording Using the Session Initiation Protocol A. Hutton Editor L. Portman Editor R. Jain K. Rehor May 2014 ASCII HTML 16 sip

Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment that is based on the Session Initiation Protocol (SIP).

 draft-ietf-siprec-architecture-12 INFORMATIONAL INFORMATIONAL IETF rai siprec 10.17487/RFC7245 RFC7246 Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context IJ. Wijnands Editor P. Hitchen N. Leymann W. Henderickx A. Gulko J. Tantsura June 2014 ASCII HTML 13

An IP Multicast Distribution Tree (MDT) may traverse both label switching (i.e., Multiprotocol Label Switching, or MPLS) and non-label switching regions of a network. Typically, the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint Label Switched Path (MP-LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region. Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label Distribution Protocol (mLDP) in the MPLS region. This document extends those procedures to handle the case where the link connecting the two regions is a Virtual Routing and Forwarding (VRF) table link, as defined in the "BGP IP/MPLS VPN" specification. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN.

 draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03 RFC7438 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC7246 RFC7247 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling P. Saint-Andre A. Houri J. Hildebrand May 2014 ASCII HTML 24 XMPP SIP

As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.

 draft-ietf-stox-core-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai stox 10.17487/RFC7247 RFC7248 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence P. Saint-Andre A. Houri J. Hildebrand May 2014 ASCII HTML 30 XMPP Jabber SIP SIMPLE IM Instant Messaging Presence

This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).

 draft-ietf-stox-presence-09 RFC8048 PROPOSED STANDARD PROPOSED STANDARD IETF rai stox 10.17487/RFC7248 RFC7249 Internet Numbers Registries R. Housley May 2014 ASCII HTML 6

RFC 7020 provides information about the Internet Numbers Registry System and how it is used in the distribution of autonomous system (AS) numbers and globally unique unicast Internet Protocol (IP) address space.

This companion document identifies the IANA registries that are part of the Internet Numbers Registry System at this time.

 draft-housley-number-registries-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7249 RFC7250 Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) P. Wouters Editor H. Tschofenig Editor J. Gilmore S. Weiler T. Kivinen June 2014 ASCII HTML 18 TLS DNSSEC DANE Raw Public Key

This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.

 draft-ietf-tls-oob-pubkey-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7250 10.17487/RFC7250 RFC7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS D. McGrew D. Bailey M. Campagna R. Dugal June 2014 ASCII HTML 10

This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within Transport Layer Security (TLS) to provide confidentiality and data-origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments, while at the same time providing a high level of security. The cipher suites defined in this document use Elliptic Curve Cryptography (ECC) and are advantageous in networks with limited bandwidth.

 draft-mcgrew-tls-aes-ccm-ecc-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7251 RFC7252 The Constrained Application Protocol (CoAP) Z. Shelby K. Hartke C. Bormann June 2014 ASCII HTML 112

The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.

CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.

 draft-ietf-core-coap-18 RFC7959 RFC8613 RFC8974 RFC9175 PROPOSED STANDARD PROPOSED STANDARD IETF app core http://www.rfc-editor.org/errata_search.php?rfc=7252 10.17487/RFC7252 RFC7253 The OCB Authenticated-Encryption Algorithm T. Krovetz P. Rogaway May 2014 ASCII HTML 19 OCB AEAD authenticated-encryption

This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data. This document is a product of the Crypto Forum Research Group (CFRG).

 draft-irtf-cfrg-ocb-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7253 RFC7254 A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI) M. Montemurro Editor A. Allen D. McDonald P. Gosden May 2014 ASCII HTML 16 GSM UMTS LTE 3GPP Mobile identifier instance ID

This specification defines a Uniform Resource Name (URN) namespace for the Global System for Mobile Communications Association (GSMA) and a Namespace Specific String (NSS) for the International Mobile station Equipment Identity (IMEI), as well as an associated parameter for the International Mobile station Equipment Identity and Software Version number (IMEISV). The IMEI and IMEISV were introduced as part of the specification for the GSM and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, Universal Mobile Telecommunications System (UMTS), and 3GPP Long Term Evolution (LTE) networks. The IMEI and IMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA. URNs from this namespace almost always contain personally identifiable information and need to be treated accordingly.

 draft-montemurro-gsma-imei-urn-20 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7254 10.17487/RFC7254 RFC7255 Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID A. Allen Editor May 2014 ASCII HTML 9 GSM UMTS LTE 3GPP IMS SIP GRUU Mobile identifier instance ID

This specification defines how the Uniform Resource Name (URN) reserved for the Global System for Mobile Communications Association (GSMA) identities and its sub-namespace for the International Mobile station Equipment Identity (IMEI) can be used as an instance-id. Its purpose is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the '+sip.instance' Contact header field parameter for outbound behavior.

 draft-allen-dispatch-imei-urn-as-instanceid-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7255 RFC7256 Multicast Control Extensions for the Access Node Control Protocol (ANCP) F. Le Faucheur R. Maglione T. Taylor July 2014 ASCII HTML 99

This document specifies the extensions to the Access Node Control Protocol (ANCP) (RFC 6320) required for support of the multicast use cases defined in the Access Node Control Protocol framework document (RFC 5851) and one additional use case described in this document. These use cases are organized into the following ANCP capabilities:

o multicast replication initiated by the Network Access Server (NAS);

o conditional access and admission control with white and black lists;

o conditional access and admission control with grey lists;

o bandwidth delegation; and

o committed bandwidth reporting.

These capabilities may be combined according to the rules given in this specification.

This document updates RFC 6320 by assigning capability type 3 to a capability specified in this document and by changing the starting point for IANA allocation of result codes determined by IETF Consensus from 0x100 to 0x64.

 draft-ietf-ancp-mc-extensions-16 RFC6320 PROPOSED STANDARD PROPOSED STANDARD IETF int ancp 10.17487/RFC7256 RFC7257 Virtual Private LAN Service (VPLS) Management Information Base T. Nadeau Editor A. Kiran Koushik Editor R. Mediratta Editor July 2014 ASCII HTML 48

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Virtual Private LAN services. It needs to be used in conjunction with the Pseudowire (PW) Management Information Base (PW-STD-MIB from RFC 5601).

 draft-ietf-l2vpn-vpls-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn http://www.rfc-editor.org/errata_search.php?rfc=7257 10.17487/RFC7257 RFC7258 Pervasive Monitoring Is an Attack S. Farrell H. Tschofenig May 2014 ASCII HTML 6 pervasive monitoring

Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.

 draft-farrell-perpass-attack-06 BCP0188 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7258 RFC7259 The Jabber-ID Header Field P. Saint-Andre May 2014 ASCII HTML 7 Jabber XMPP Extensible Messaging and Presence Protocol email netnews message header field IM instant messaging

This document defines a header field that enables the author of an email or netnews message to include a Jabber ID in the message header block for the purpose of associating the author with a particular Extensible Messaging and Presence Protocol (XMPP) address.

 draft-saintandre-jabberid-13 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7259 RFC7260 GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration A. Takacs D. Fedyk J. He June 2014 ASCII HTML 24 MPLS-TP Transport Profile GELS Ethernet Label Switching PBB-TE connectivity monitoring OAM configuration

Operations, Administration, and Maintenance (OAM) is an integral part of transport connections; hence, it is required that OAM functions be activated/deactivated in sync with connection commissioning/ decommissioning, in order to avoid spurious alarms and ensure consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with Label Switched Path signaling.

 draft-ietf-ccamp-oam-configuration-fwk-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=7260 10.17487/RFC7260 RFC7261 Offer/Answer Considerations for G723 Annex A and G729 Annex B M. Perumal P. Ravindran May 2014 ASCII HTML 8 offer answer

This document provides the offer/answer considerations for the annexa parameter of G723 and the annexb parameter of G729, G729D, and G729E when the value of the annexa or annexb parameter does not match in the Session Description Protocol (SDP) offer and answer.

 draft-ietf-mmusic-sdp-g723-g729-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7261 RFC7262 Requirements for Telepresence Multistreams A. Romanow S. Botzko M. Barnes June 2014 ASCII HTML 12

This memo discusses the requirements for specifications that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE). In addition, the problem statement and related definitions are also covered herein.

 draft-ietf-clue-telepresence-requirements-07 INFORMATIONAL INFORMATIONAL IETF rai clue 10.17487/RFC7262 RFC7263 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing N. Zong X. Jiang R. Even Y. Zhang June 2014 ASCII HTML 20 P2P

This document defines an optional extension to the REsource LOcation And Discovery (RELOAD) protocol to support the direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers. This document also describes potential cases where this extension can be used.

 draft-ietf-p2psip-drr-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7263 RFC7264 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing N. Zong X. Jiang R. Even Y. Zhang June 2014 ASCII HTML 15 P2P

This document defines an optional extension to the REsource LOcation And Discovery (RELOAD) protocol to support the relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers. This document also describes potential cases where this extension can be used.

 draft-ietf-p2psip-rpr-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7264 RFC7265 jCal: The JSON Format for iCalendar P. Kewisch C. Daboo M. Douglass May 2014 ASCII HTML 31

This specification defines "jCal", a JSON format for iCalendar data. The iCalendar data format is a text format for capturing and exchanging information normally stored within a calendaring and scheduling application, for example, tasks and events. JSON is a lightweight, text-based, language-independent data interchange format commonly used in Internet applications.

 draft-ietf-jcardcal-jcal-10 RFC7529 PROPOSED STANDARD PROPOSED STANDARD IETF app jcardcal http://www.rfc-editor.org/errata_search.php?rfc=7265 10.17487/RFC7265 RFC7266 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting A. Clark Q. Wu R. Schott G. Zorn June 2014 ASCII HTML 23

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block including two new segment types and associated Session Description Protocol (SDP) parameters that allow the reporting of mean opinion score (MOS) Metrics for use in a range of RTP applications.

 draft-ietf-xrblock-rtcp-xr-qoe-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7266 RFC7267 Dynamic Placement of Multi-Segment Pseudowires L. Martini Editor M. Bocci Editor F. Balus Editor June 2014 ASCII HTML 24 pw pw switching point pe sub-tlv

RFC 5254 describes the service provider requirements for extending the reach of pseudowires (PWs) across multiple Packet Switched Network domains. A multi-segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point-to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi-segment pseudowire among a set of Provider Edge (PE) routers. This document also updates RFC 6073 by updating the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14.

 draft-ietf-pwe3-dynamic-ms-pw-22 RFC6073 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7267 RFC7268 RADIUS Attributes for IEEE 802 Networks B. Aboba J. Malinen P. Congdon J. Salowey M. Jones July 2014 ASCII HTML 29

RFC 3580 provides guidelines for the use of the Remote Authentication Dial-In User Service (RADIUS) within IEEE 802 local area networks (LANs). This document defines additional attributes for use within IEEE 802 networks and clarifies the usage of the EAP-Key-Name Attribute and the Called-Station-Id Attribute. This document updates RFCs 3580 and 4072.

 draft-ietf-radext-ieee802ext-12 RFC3580 RFC4072 RFC8044 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC7268 RFC7269 NAT64 Deployment Options and Experience G. Chen Z. Cao C. Xie D. Binet June 2014 ASCII HTML 22

This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier-Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document.

 draft-ietf-v6ops-nat64-experience-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7269 RFC7270 Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX) A. Yourtchenko P. Aitken B. Claise June 2014 ASCII HTML 21 IPFIX

This document describes some additional IP Flow Information Export (IPFIX) Information Elements in the range of 1-127, which is the range compatible with field types used by NetFlow version 9 in RFC 3954, as specified in the IPFIX Information Model in RFC 7012.

 draft-yourtchenko-cisco-ies-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7270 10.17487/RFC7270 RFC7271 MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators J. Ryoo Editor E. Gray Editor H. van Helvoort A. D'Alessandro T. Cheung E. Osborne June 2014 ASCII HTML 40 PSC mode APS mode capabilities priority non-revertive MS-W support SD support EXER support

This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks.

This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode.

This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled.

This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document.

 draft-ietf-mpls-tp-psc-itu-04 RFC6378 RFC8234 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7271 RFC7272 Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP) R. van Brandenburg H. Stokking O. van Deventer F. Boronat M. Montagud K. Gross June 2014 ASCII HTML 23 Inter-Destination Media Synchronization RTP Control Protocol RTCP

This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize.

Typical use cases in which IDMS is useful are social TV, shared service control (i.e., applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc.

 draft-ietf-avtcore-idms-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7272 RFC7273 RTP Clock Source Signalling A. Williams K. Gross R. van Brandenburg H. Stokking June 2014 ASCII HTML 30 clock source

NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies Session Description Protocol (SDP) signalling that identifies timestamp reference clock sources and SDP signalling that identifies the media clock sources in a multimedia session.

 draft-ietf-avtcore-clksrc-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore http://www.rfc-editor.org/errata_search.php?rfc=7273 10.17487/RFC7273 RFC7274 Allocating and Retiring Special-Purpose MPLS Labels K. Kompella L. Andersson A. Farrel June 2014 ASCII HTML 11

Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end; these labels are commonly called "reserved labels". They will be called "special-purpose labels" in this document.

As there are only 16 of these special-purpose labels, caution is needed in the allocation of new special-purpose labels; yet, at the same time, forward progress should be allowed when one is called for.

This memo defines new procedures for the allocation and retirement of special-purpose labels, as well as a method to extend the special-purpose label space and a description of how to handle extended special-purpose labels in the data plane. Finally, this memo renames the IANA registry for special-purpose labels to "Special-Purpose MPLS Label Values" and creates a new registry called the "Extended Special-Purpose MPLS Label Values" registry.

This document updates a number of previous RFCs that use the term "reserved label". Specifically, this document updates RFCs 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 6790.

 draft-ietf-mpls-special-purpose-labels-06 RFC3032 RFC3038 RFC3209 RFC3811 RFC4182 RFC4928 RFC5331 RFC5586 RFC5921 RFC5960 RFC6391 RFC6478 RFC6790 RFC9017 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7274 RFC7275 Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy L. Martini S. Salam A. Sajassi M. Bocci S. Matsushima T. Nadeau June 2014 ASCII HTML 83 iccp

This document specifies an Inter-Chassis Communication Protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a Redundancy Group, for the purpose of synchronizing data among the systems. It accommodates multi-chassis attachment circuit redundancy mechanisms as well as pseudowire redundancy mechanisms.

 draft-ietf-pwe3-iccp-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7275 RFC7276 An Overview of Operations, Administration, and Maintenance (OAM) Tools T. Mizrahi N. Sprecher E. Bellagamba Y. Weingarten June 2014 ASCII HTML 53

Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack.

This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links (TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document.

The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary.

 draft-ietf-opsawg-oam-overview-16 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7276 RFC7277 A YANG Data Model for IP Management M. Bjorklund June 2014 ASCII HTML 30 netmod

This document defines a YANG data model for management of IP implementations. The data model includes configuration data and state data.

 draft-ietf-netmod-ip-cfg-14 RFC8344 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC7277 RFC7278 Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link C. Byrne D. Drown A. Vizdal June 2014 ASCII HTML 10

This document describes requirements for extending an IPv6 /64 prefix from a User Equipment Third Generation Partnership Project (3GPP) radio interface to a LAN link and describes two implementation examples.

 draft-ietf-v6ops-64share-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7278 RFC7279 An Acceptable Use Policy for New ICMP Types and Codes M. Shore C. Pignataro May 2014 ASCII HTML 10 icmp icmpv4 icmpv6

In this document we provide a basic description of ICMP's role in the IP stack and some guidelines for future use.

This document is motivated by concerns about lack of clarity concerning when to add new Internet Control Message Protocol (ICMP) types and/or codes. These concerns have highlighted a need to describe policies for when adding new features to ICMP is desirable and when it is not.

 draft-shore-icmp-aup-12 BCP0189 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7279 RFC7280 IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry G. Fairhurst June 2014 ASCII HTML 7 ULE IANA

This document updates RFC 4326 to clarify and update the allocation rules for the Unidirectional Lightweight Encapsulation (ULE) Next- Header registry. This registry is used by ULE and Generic Stream Encapsulation (GSE) to record the code points of Extension Headers and protocols supported by these encapsulation protocols.

 draft-fairhurst-ipdvb-ule-iana-07 RFC4326 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7280 RFC7281 Authentication-Results Registration for S/MIME Signature Verification A. Melnikov June 2014 ASCII HTML 11 Authentication-Results S/MIME

RFC 7001 specifies the Authentication-Results header field for conveying results of message authentication checks. This document defines a new authentication method to be used in the Authentication- Results header field for S/MIME-related signature checks.

 draft-melnikov-authentication-results-smime-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7281 RFC7282 On Consensus and Humming in the IETF P. Resnick June 2014 ASCII HTML 19 accommodate agree agreement appease argue argument balloting capitulated capitulation chair choice choose coin compromise count decide decision disagree disagreement hands horse-trade horse-trading hum issue judge judging king majority member minority object objection objector president rough unaddressed vote voting working group

The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus.

Note: This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus.

 draft-resnick-on-consensus-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7282 10.17487/RFC7282 RFC7283 Handling Unknown DHCPv6 Messages Y. Cui Q. Sun T. Lemon July 2014 ASCII HTML 7 DHCPv6 Unknown Messages

DHCPv6 is not specific about handling messages with unknown types. This memo describes the problems associated with receiving DHCPv6 messages with unknown types, and defines how a DHCPv6 server, client, or relay agent should behave when receiving unknown DHCPv6 messages. This document also provides advice for authors of future documents that define new messages to be sent from DHCP servers to DHCP relay agents. This document updates RFC 3315.

 draft-ietf-dhc-dhcpv6-unknown-msg-08 RFC8415 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7283 RFC7284 The Profile URI Registry M. Lanthaler June 2014 ASCII HTML 5 profile profiles URI registry

This document defines a registry for profile URIs to be used in specifications standardizing profiles.

 draft-lanthaler-profile-registry-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7284 RFC7285 Application-Layer Traffic Optimization (ALTO) Protocol R. Alimi Editor R. Penno Editor Y. Yang Editor S. Kiesel S. Previdi W. Roome S. Shalunov R. Woundy September 2014 ASCII HTML 91 ALTO Information Resources Network Map PID Filtered Network Map Cost Map Endpoint Property Service Endpoint Cost Service

Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.

The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.

This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.

 draft-ietf-alto-protocol-27 RFC9274 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto http://www.rfc-editor.org/errata_search.php?rfc=7285 10.17487/RFC7285 RFC7286 Application-Layer Traffic Optimization (ALTO) Server Discovery S. Kiesel M. Stiemerling N. Schwan M. Scharf H. Song November 2014 ASCII HTML 15

The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers.

This document specifies a procedure for resource-consumer-initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer.

 draft-ietf-alto-server-discovery-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC7286 RFC7287 Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains T. Schmidt Editor S. Gao H. Zhang M. Waehlisch June 2014 ASCII HTML 28

Multicast communication can be enabled in Proxy Mobile IPv6 (PMIPv6) domains via the Local Mobility Anchors by deploying Multicast Listener Discovery (MLD) proxy functions at Mobile Access Gateways, by using direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes a base solution and an experimental protocol to support mobile multicast senders in PMIPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD proxies are defined. Mobile sources always remain agnostic of multicast mobility operations.

 draft-ietf-multimob-pmipv6-source-09 EXPERIMENTAL EXPERIMENTAL IETF int multimob 10.17487/RFC7287 RFC7288 Reflections on Host Firewalls D. Thaler June 2014 ASCII HTML 13 Filter Filtering

In today's Internet, the need for firewalls is generally accepted in the industry, and indeed firewalls are widely deployed in practice. Unlike traditional firewalls that protect network links, host firewalls run in end-user systems. Often the result is that software may be running and potentially consuming resources, but then communication is blocked by a host firewall. It's taken for granted that this end state is either desirable or the best that can be achieved in practice, rather than (for example) an end state where the relevant software is not running or is running in a way that would not result in unwanted communication. In this document, we explore the issues behind these assumptions and provide suggestions on improving the architecture going forward.

 draft-iab-host-firewalls-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7288 RFC7289 Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs V. Kuarsingh Editor J. Cianfarani June 2014 ASCII HTML 20 NAT444 LSN Large-Scale NAT

This document specifies a framework to integrate a Network Address Translation (NAT) layer into an operator's network to function as a Carrier-Grade NAT (also known as CGN or Large-Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber-side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near- term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model that allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IP VPNs, which allow for virtual routing separation, helping ease the CGN's impact on the network. This document does not intend to defend the merits of CGN.

 draft-ietf-opsawg-lsn-deployment-06 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7289 RFC7290 Test Plan and Results for Advancing RFC 2680 on the Standards Track L. Ciavattone R. Geib A. Morton M. Wieser July 2014 ASCII HTML 31 packet loss IPPM implementation comparison perfas+ netem IPPM comparison metric test, WIPM NetProbe

This memo provides the supporting test plan and results to advance RFC 2680, a performance metric RFC defining one-way packet loss metrics, along the Standards Track. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2680.

 draft-ietf-ippm-testplan-rfc2680-05 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7290 RFC7291 DHCP Options for the Port Control Protocol (PCP) M. Boucadair R. Penno D. Wing July 2014 ASCII HTML 11 PCP Server discovery Port Mapping Shared Address

This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios. The set of deployment scenarios to which DHCPv4 or DHCPv6 can be applied is outside the scope of this document.

 draft-ietf-pcp-dhcp-13 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7291 RFC7292 PKCS #12: Personal Information Exchange Syntax v1.1 K. Moriarty Editor M. Nystrom S. Parkinson A. Rusch M. Scott July 2014 ASCII HTML 29 PKCS#12 PKCS12v1.1 PKCS#12v1.1

PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes.

This document represents a republication of PKCS #12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF.

 draft-moriarty-pkcs12v1-1-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7292 10.17487/RFC7292 RFC7293 The Require-Recipient-Valid-Since Header Field and SMTP Service Extension W. Mills M. Kucherawy July 2014 ASCII HTML 24 Security Privacy Email Account Expiration

This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called "RRVS" to provide a method for senders to indicate to receivers a point in time when the ownership of the target mailbox was known to the sender. This can be used to detect changes of mailbox ownership and thus prevent mail from being delivered to the wrong party. This document also defines a header field called "Require-Recipient-Valid-Since" that can be used to tunnel the request through servers that do not support the extension.

The intended use of these facilities is on automatically generated messages, such as account statements or password change instructions, that might contain sensitive information, though it may also be useful in other applications.

 draft-ietf-appsawg-rrvs-header-field-11 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7293 RFC7294 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications A. Clark G. Zorn C. Bi Q. Wu July 2014 ASCII HTML 22 Real Time Control Protocol

This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of concealment metrics for audio applications of RTP.

 draft-ietf-xrblock-rtcp-xr-loss-conceal-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7294 RFC7295 Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication H. Tschofenig L. Eggert Z. Sarker July 2014 ASCII HTML 26 Congestion Control RTCWEB Workshop Real-Time Communication

This document provides a summary of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists recommendations to the Internet Engineering Task Force (IETF) community.

The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB), or the Internet Research Task Force (IRTF).

 draft-iab-cc-workshop-report-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7295 RFC7296 Internet Key Exchange Protocol Version 2 (IKEv2) C. Kaufman P. Hoffman Y. Nir P. Eronen T. Kivinen October 2014 ASCII HTML 142 IKE IPsec

This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard.

 draft-kivinen-ipsecme-ikev2-rfc5996bis-04 RFC5996 RFC7427 RFC7670 RFC8247 RFC8983 STD0079 INTERNET STANDARD INTERNET STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=7296 10.17487/RFC7296 RFC7297 IP Connectivity Provisioning Profile (CPP) M. Boucadair C. Jacquenet N. Wang July 2014 ASCII HTML 22

This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP.

Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives of Traffic Engineering functions and service management functions, and (3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs.

 draft-boucadair-connectivity-provisioning-profile-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7297 RFC7298 Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication D. Ovsienko July 2014 ASCII HTML 55 routing protocol authentication applied cryptography

This document describes a cryptographic authentication mechanism for the Babel routing protocol. This document updates RFC 6126. The mechanism allocates two new TLV types for the authentication data, uses Hashed Message Authentication Code (HMAC), and is both optional and backward compatible.

 draft-ovsienko-babel-hmac-authentication-09 RFC8967 RFC6126 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7298 RFC7299 Object Identifier Registry for the PKIX Working Group R. Housley July 2014 ASCII HTML 30 Public-Key Infrastructure using X.509

When the Public-Key Infrastructure using X.509 (PKIX) Working Group was chartered, an object identifier arc was allocated by IANA for use by that working group. This document describes the object identifiers that were assigned in that arc, returns control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.

 draft-housley-pkix-oids-03 RFC9158 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7299 RFC7300 Reservation of Last Autonomous System (AS) Numbers J. Haas J. Mitchell July 2014 ASCII HTML 5 asn last asns

This document reserves two Autonomous System Numbers (ASNs) at the end of the 16-bit and 32-bit ranges, described in this document as "Last ASNs", and provides guidance to implementers and operators on their use. This document updates Section 10 of RFC 1930.

 draft-ietf-idr-last-as-reservation-07 RFC1930 BCP0006 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC7300 RFC7301 Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension S. Friedl A. Popov A. Langley E. Stephan July 2014 ASCII HTML 9 ALPN

This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.

 draft-ietf-tls-applayerprotoneg-05 RFC8447 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7301 10.17487/RFC7301 RFC7302 Entertainment Identifier Registry (EIDR) URN Namespace Definition P. Lemieux July 2014 ASCII HTML 8 EIDR Entertainment Identifier Registry URN

Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for EIDR Identifiers.

 draft-pal-eidr-urn-03 RFC7972 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7302 RFC7303 XML Media Types H. Thompson C. Lilley July 2014 ASCII HTML 35 application/xml application/xml-external-parsed-entity application/xml-dtd text/xml text/xml-external-parsed-entity +xml

This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities.

 draft-ietf-appsawg-xml-mediatypes-10 RFC3023 RFC6839 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7303 10.17487/RFC7303 RFC7304 A Method for Mitigating Namespace Collisions W. Kumari July 2014 ASCII HTML 4

This document outlines a possible, but not recommended, method to mitigate the effect of collisions in the DNS namespace by providing a means for end users to disambiguate the conflict.

 draft-wkumari-dnsop-defense-collision-mitigate-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7304 RFC7305 Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT) E. Lear Editor July 2014 ASCII HTML 17

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Internet Technology Adoption and Transition (ITAT). The workshop was hosted by the University of Cambridge on December 4th and 5th of 2013 in Cambridge, UK. The goal of the workshop was to facilitate adoption of Internet protocols, through examination of a variety of economic models, with particular emphasis at the waist of the hourglass (e.g., the middle of the protocol stack). This report summarizes contributions and discussions. As the topics were wide ranging, there is no single set of recommendations for IETF participants to pursue at this time. Instead, in the classic sense of early research, the workshop noted areas that deserve further exploration.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 draft-iab-itat-report-04 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7305 10.17487/RFC7305 RFC7306 Remote Direct Memory Access (RDMA) Protocol Extensions H. Shah F. Marti W. Noureddine A. Eiriksson R. Sharp June 2014 ASCII HTML 34 iWARP RDMAP DDP RDMA DMA

This document specifies extensions to the IETF Remote Direct Memory Access Protocol (RDMAP) as specified in RFC 5040. RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper-Layer Protocol (ULP) Buffers without intermediate data copies. The extensions specified in this document provide the following capabilities and/or improvements: Atomic Operations and Immediate Data.

 draft-ietf-storm-rdmap-ext-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm http://www.rfc-editor.org/errata_search.php?rfc=7306 10.17487/RFC7306 RFC7307 LDP Extensions for Multi-Topology Q. Zhao K. Raza C. Zhou L. Fang L. Li D. King July 2014 ASCII HTML 20 MT Label Distribution Protocol

Multi-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks, new extensions are required.

This document describes the LDP protocol extensions required to support MT routing in an MPLS environment.

 draft-ietf-mpls-ldp-multi-topology-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7307 10.17487/RFC7307 RFC7308 Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) E. Osborne July 2014 ASCII HTML 7 colors link colors igp te extensions

MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).

This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.

 draft-ietf-mpls-extended-admin-group-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7308 RFC7309 Redundancy Mechanism for Inter-domain VPLS Service Z. Liu L. Jin R. Chen D. Cai S. Salam July 2014 ASCII HTML 12 ICCP PW

In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no Provider Edge (PE) node redundancy, or offers PE node redundancy with only a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PE node redundancy. This document describes an inter-domain VPLS solution that provides PE node redundancy across domains.

 draft-ietf-l2vpn-vpls-inter-domain-redundancy-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC7309 RFC7310 RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs J. Lindsay H. Foerster July 2014 ASCII HTML 16

This document specifies a scheme for packetizing Standard apt-X or Enhanced apt-X encoded audio data into Real-time Transport Protocol (RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP).

 draft-ietf-payload-rtp-aptx-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC7310 RFC7311 The Accumulated IGP Metric Attribute for BGP P. Mohapatra R. Fernando E. Rosen J. Uttaro August 2014 ASCII HTML 15

Routing protocols that have been designed to run within a single administrative domain (IGPs) generally do so by assigning a metric to each link and then choosing, as the installed path between two nodes, the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains (autonomous systems), does not make its path-selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so.

 draft-ietf-idr-aigp-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7311 RFC7312 Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM) J. Fabini A. Morton August 2014 ASCII HTML 17 Measurement Wireless Reactive Repeatability Continuity Actionable Conservative Spatial Composition Temporal Composition

To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo updates the IP Performance Metrics (IPPM) Framework, RFC 2330, with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them; otherwise, unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics.

 draft-ietf-ippm-2330-update-05 RFC2330 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7312 RFC7313 Enhanced Route Refresh Capability for BGP-4 K. Patel E. Chen B. Venkatachalapathy July 2014 ASCII HTML 8 Border Gateway Protocol bgp rib BGP Routing Information Base

In this document, we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP Routing Information Base (RIB) inconsistencies in a non-disruptive manner. This document updates RFC 2918.

 draft-ietf-idr-bgp-enhanced-route-refresh-10 RFC2918 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7313 RFC7314 Extension Mechanisms for DNS (EDNS) EXPIRE Option M. Andrews July 2014 ASCII HTML 4 IXFR AXFR zone transfer DNS SOA

This document specifies a method for secondary DNS servers to honour the SOA EXPIRE field as if they were always transferring from the primary, even when using other secondaries to perform indirect transfers and refresh queries.

 draft-andrews-dnsext-expire-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7314 RFC7315 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP R. Jesske K. Drage C. Holmberg July 2014 ASCII HTML 43

This document describes a set of private header (P-header) Session Initiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments. The P-header fields are used for a variety of purposes within the networks that the partners implement, including charging and information about the networks a call traverses. This document obsoletes RFC 3455.

 draft-drage-sipping-rfc3455bis-14 RFC3455 RFC7913 RFC7976 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7315 10.17487/RFC7315 RFC7316 The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header) J. van Elburg K. Drage M. Ohsugi S. Schubert K. Arai July 2014 ASCII HTML 15

This document specifies the SIP P-Private-Network-Indication P-header used by the 3GPP. The P-Private-Network-Indication indicates that the message is part of the message traffic of a private network and identifies that private network. A private network indication allows nodes to treat private network traffic according to a different set of rules than the set applicable to public network traffic.

 draft-vanelburg-dispatch-private-network-ind-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7316 RFC7317 A YANG Data Model for System Management A. Bierman M. Bjorklund August 2014 ASCII HTML 35 NETCONF

This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server. This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management.

 draft-ietf-netmod-system-mgmt-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7317 10.17487/RFC7317 RFC7318 Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates A. Newton G. Huston July 2014 ASCII HTML 5

This document updates RFC 6487 by clarifying the inclusion of policy qualifiers in the certificate policies extension of Resource Public Key Infrastructure (RPKI) resource certificates.

 draft-ietf-sidr-policy-qualifiers-02 RFC6487 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC7318 RFC7319 IANA Considerations for Connectivity Fault Management (CFM) Code Points D. Eastlake 3rd July 2014 ASCII HTML 5 CFM OAM Connectivity Continuity Fault IANA TRILL

IEEE 802.1 has specified Connectivity Fault Management (CFM) Operations, Administration, and Maintenance (OAM) facilities. CFM messages are structured with an OpCode field and have provision for the inclusion of TLV-structured information. IEEE 802.1 has allocated blocks of CFM OpCodes and TLV Types to the IETF. This document specifies the IANA considerations for the assignment of values from these blocks.

 draft-eastlake-iana-cfm-considerations-02 BCP0191 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7319 RFC7320 URI Design and Ownership M. Nottingham July 2014 ASCII HTML 9 URI structure

Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards.

 draft-ietf-appsawg-uri-get-off-my-lawn-05 RFC8820 RFC3986 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7320 10.17487/RFC7320 RFC7321 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) D. McGrew P. Hoffman August 2014 ASCII HTML 11

This document updates the Cryptographic Algorithm Implementation Requirements for the Encapsulating Security Payload (ESP) and Authentication Header (AH). It also adds usage guidance to help in the selection of these algorithms.

ESP and AH protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms.

 draft-ietf-ipsecme-esp-ah-reqts-10 RFC4835 RFC8221 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC7321 RFC7322 RFC Style Guide H. Flanagan S. Ginoza September 2014 ASCII HTML 24 editorial guidance format style manual house style

This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 2223, "Instructions to RFC Authors".

 draft-iab-styleguide-02 RFC2223 RFC7997 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7322 10.17487/RFC7322 RFC7323 TCP Extensions for High Performance D. Borman B. Braden V. Jacobson R. Scheffenegger Editor September 2014 ASCII HTML 49 Timestamps Timestamp RTT RTTM Window Scale PAWS TCP options

This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.

This document obsoletes RFC 1323 and describes changes from it.

 draft-ietf-tcpm-1323bis-21 RFC1323 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=7323 10.17487/RFC7323 RFC7324 Updates to MPLS Transport Profile Linear Protection E. Osborne July 2014 ASCII HTML 11 multiprotocol label switching mpls-tp psc protection state coordination

This document contains a number of updates to the Protection State Coordination (PSC) logic defined in RFC 6378, "MPLS Transport Profile (MPLS-TP) Linear Protection". These updates provide some rules and recommendations around the use of TLVs in PSC, address some issues raised in an ITU-T liaison statement, and clarify PSC's behavior in a case not well explained in RFC 6378.

 draft-ietf-mpls-psc-updates-06 RFC6378 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7324 RFC7325 MPLS Forwarding Compliance and Performance Requirements C. Villamizar Editor K. Kompella S. Amante A. Malis C. Pignataro August 2014 ASCII HTML 59 MPLS ECMP link bundling multipath MPLS-TP forwarding

This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements which are unstated or under emphasized or are optional for conformance to RFCs but are often considered mandatory by providers.

 draft-ietf-mpls-forwarding-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7325 RFC7326 Energy Management Framework J. Parello B. Claise B. Schoening J. Quittek September 2014 ASCII HTML 54

This document defines a framework for Energy Management (EMAN) for devices and device components within, or connected to, communication networks. The framework presents a physical reference model and information model. The information model consists of an Energy Management Domain as a set of Energy Objects. Each Energy Object can be attributed with identity, classification, and context. Energy Objects can be monitored and controlled with respect to power, Power State, energy, demand, Power Attributes, and battery. Additionally, the framework models relationships and capabilities between Energy Objects.

 draft-ietf-eman-framework-19 INFORMATIONAL INFORMATIONAL IETF ops eman 10.17487/RFC7326 RFC7327 RFC7328 Writing I-Ds and RFCs Using Pandoc and a Bit of XML R. Gieben August 2014 ASCII HTML 10

This document presents a technique for using a Markdown syntax variant, called Pandoc, and a bit of XML (as defined in RFC 2629) as a source format for documents that are Internet-Drafts (I-Ds) or RFCs.

The goal of this technique (which is called Pandoc2rfc) is to let an author of an I-D focus on the main body of text without being distracted too much by XML tags; however, it does not alleviate the need to typeset some files in XML.

 draft-gieben-pandoc2rfc-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7328 RFC7329 A Session Identifier for the Session Initiation Protocol (SIP) H. Kaplan August 2014 ASCII HTML 17

There is a need for having a globally unique session identifier for the same SIP session that can be consistently maintained across SIP Proxies, Back-to-Back User Agents (B2BUAs), and other SIP middleboxes, for the purpose of troubleshooting. This document proposes a new SIP header to carry such a value: Session-ID.

The mechanism defined in this document has been widely deployed, and is being followed in a backward-compatible fashion for a new Standards Track document produced by the INSIPID Working Group.

 draft-kaplan-insipid-session-id-04 RFC7989 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7329 RFC7330 Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management T. Nadeau Z. Ali N. Akiya August 2014 ASCII HTML 11 Network Management management Information Base MIB SMIv2 BFD

This document defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD-related MIB modules that would otherwise define their own representations.

 draft-ietf-bfd-tc-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC7330 RFC7331 Bidirectional Forwarding Detection (BFD) Management Information Base T. Nadeau Z. Ali N. Akiya August 2014 ASCII HTML 39 Network Management Management Information Base MIB SMIv2 BFD

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Bidirectional Forwarding Detection (BFD) protocol.

 draft-ietf-bfd-mib-22 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=7331 10.17487/RFC7331 RFC7332 Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) H. Kaplan V. Pascual August 2014 ASCII HTML 5

SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values. This document discusses the difficulties associated with loop detection for B2BUAs and the requirements for them to prevent infinite loops.

 draft-ietf-straw-b2bua-loop-detection-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai straw http://www.rfc-editor.org/errata_search.php?rfc=7332 10.17487/RFC7332 RFC7333 Requirements for Distributed Mobility Management H. Chan Editor D. Liu P. Seite H. Yokota J. Korhonen August 2014 ASCII HTML 24 Distributed Mobility Management Network function distribution Flat mobile network Mobile network operation and management Control and data plane separation

This document defines the requirements for Distributed Mobility Management (DMM) at the network layer. The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors. As some wireless networks are evolving away from the hierarchical structure, it can be useful to have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal route. The motivation and the problems addressed by each requirement are also described.

 draft-ietf-dmm-requirements-17 INFORMATIONAL INFORMATIONAL IETF int dmm 10.17487/RFC7333 RFC7334 PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths Q. Zhao D. Dhody D. King Z. Ali R. Casellas August 2014 ASCII HTML 25 Core-tree

The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS- and GMPLS-controlled networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs.

This document describes an experiment to provide procedures and extensions to the PCE Communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs.

 draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08 EXPERIMENTAL EXPERIMENTAL IETF rtg pce 10.17487/RFC7334 RFC7335 IPv4 Service Continuity Prefix C. Byrne August 2014 ASCII HTML 4

Dual-Stack Lite (DS-Lite), defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the Basic Bridging BroadBand (B4) element. Per this memo, IANA has generalized that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution.

 draft-ietf-v6ops-clatip-04 RFC6333 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC7335 RFC7336 Framework for Content Distribution Network Interconnection (CDNI) L. Peterson B. Davie R. van Brandenburg Editor August 2014 ASCII HTML 58 CDNI content delivery network federation cdni request routing cdni logging cdmi metadata cdni control

This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletes RFC 3466.

 draft-ietf-cdni-framework-14 RFC3466 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC7336 RFC7337 Content Distribution Network Interconnection (CDNI) Requirements K. Leung Editor Y. Lee Editor August 2014 ASCII HTML 23

Content delivery is frequently provided by specifically architected and provisioned Content Delivery Networks (CDNs). As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers (NSPs) and Enterprise Service Providers (ESPs) are also deploying their own CDNs. To deliver contents from the Content Service Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users.

The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group.

 draft-ietf-cdni-requirements-17 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC7337 RFC7338 Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks F. Jounay Editor Y. Kamite Editor G. Heron M. Bocci September 2014 ASCII HTML 18

This document presents a set of requirements and a framework for providing a point-to-multipoint pseudowire (PW) over MPLS Packet Switched Networks. The requirements identified in this document are related to architecture, signaling, and maintenance aspects of point-to-multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications, point-to-multipoint PWs can be used to optimize the support of multicast Layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service).

 draft-ietf-pwe3-p2mp-pw-requirements-10 INFORMATIONAL INFORMATIONAL IETF rtg pwe3 10.17487/RFC7338 RFC7339 Session Initiation Protocol (SIP) Overload Control V. Gurbani Editor V. Hilt H. Schulzrinne September 2014 ASCII HTML 38 SIP Overload Control

Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all the SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines the behavior of SIP servers involved in overload control and also specifies a loss-based overload scheme for SIP.

 draft-ietf-soc-overload-control-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai soc 10.17487/RFC7339 RFC7340 Secure Telephone Identity Problem Statement and Requirements J. Peterson H. Schulzrinne H. Tschofenig September 2014 ASCII HTML 25 SIP XMPP Secure Origin Identification Communication Security RTCWeb Problem Statement Real-Time Communication

Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space.

 draft-ietf-stir-problem-statement-05 INFORMATIONAL INFORMATIONAL IETF rai stir 10.17487/RFC7340 RFC7341 DHCPv4-over-DHCPv6 (DHCP 4o6) Transport Q. Sun Y. Cui M. Siodelski S. Krishnan I. Farrer August 2014 ASCII HTML 16 ipv6 transition softwire migration tunnel residual ipv4 dhcpv6 relay ipv6-only

IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose.

 draft-ietf-dhc-dhcpv4-over-dhcpv6-09 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7341 RFC7342 Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers L. Dunbar W. Kumari I. Gashinsky August 2014 ASCII HTML 14

This memo documents some operational practices that allow ARP and Neighbor Discovery (ND) to scale in data center environments.

 draft-dunbar-armd-arp-nd-scaling-practices-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7342 RFC7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) J. Laganier F. Dupont September 2014 ASCII HTML 14 HIP HIPv2 ORCHID CGA API

This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.

The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.

 draft-ietf-hip-rfc4843-bis-08 RFC4843 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC7343 RFC7344 Automating DNSSEC Delegation Trust Maintenance W. Kumari O. Gudmundsson G. Barwood September 2014 ASCII HTML 18 key roll trust anchor CDS CDNSKEY DNSSEC DNS

This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent.

 draft-ietf-dnsop-delegation-trust-maintainance-14 RFC8078 PROPOSED STANDARD INFORMATIONAL IETF ops dnsop 10.17487/RFC7344 RFC7345 UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) C. Holmberg I. Sedlacek G. Salgueiro August 2014 ASCII HTML 23 SDP SIP DTLS UDPTL fax transport

This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP).

 draft-ietf-mmusic-udptl-dtls-10 RFC8842 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7345 RFC7346 IPv6 Multicast Address Scopes R. Droms August 2014 ASCII HTML 6 IPv6 multicast address scopes

This document updates the definitions of IPv6 multicast scopes and therefore updates RFCs 4007 and 4291.

 draft-ietf-6man-multicast-scopes-07 RFC4007 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=7346 10.17487/RFC7346 RFC7347 Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP) H. van Helvoort Editor J. Ryoo Editor H. Zhang F. Huang H. Li A. D'Alessandro September 2014 ASCII PDF HTML 32

The IETF Standards Track solution for MPLS Transport Profile (MPLS-TP) Linear Protection is provided in RFCs 6378, 7271, and 7324.

This document describes the pre-standard implementation of MPLS-TP Linear Protection that has been deployed by several network operators using equipment from multiple vendors. At the time of publication, these pre-standard implementations were still in operation carrying live traffic.

The specified mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It is purely supported by the MPLS-TP data plane and can work without any control plane.

 draft-zulr-mpls-tp-linear-protection-switching-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7347 RFC7348 Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks M. Mahalingam D. Dutt K. Duda P. Agarwal L. Kreeger T. Sridhar M. Bursell C. Wright August 2014 ASCII HTML 22

This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community.

 draft-mahalingam-dutt-dcops-vxlan-09 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7348 10.17487/RFC7348 RFC7349 LDP Hello Cryptographic Authentication L. Zheng M. Chen M. Bhatia August 2014 ASCII HTML 14

This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well-known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using Hashed Message Authentication Code (HMAC) with the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms.

 draft-ietf-mpls-ldp-hello-crypto-auth-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7349 RFC7350 Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) M. Petit-Huguenin G. Salgueiro August 2014 ASCII HTML 16 Security Encryption

This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN). It provides guidance on when and how to use DTLS with the currently standardized STUN usages. It also specifies modifications to the STUN and Traversal Using Relay NAT (TURN) URIs and to the TURN resolution mechanism to facilitate the resolution of STUN and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. This document updates RFCs 5389 and 5928.

 draft-ietf-tram-stun-dtls-05 RFC5389 RFC5928 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC7350 RFC7351 A Media Type for XML Patch Operations E. Wilde August 2014 ASCII HTML 14 Media Type XML Patch Operations

The XML patch document format defines an XML document structure for expressing a sequence of patch operations to be applied to an XML document. The XML patch document format builds on the foundations defined in RFC 5261. This specification also provides the media type registration "application/xml-patch+xml", to allow the use of XML patch documents in, for example, HTTP conversations.

 draft-wilde-xml-patch-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7351 RFC7352 Sieve Email Filtering: Detecting Duplicate Deliveries S. Bosch September 2014 ASCII HTML 15 sieve duplicate deliveries

This document defines a new test command, "duplicate", for the Sieve email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header field or other parts of the message.

 draft-ietf-appsawg-sieve-duplicate-09 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7352 RFC7353 Security Requirements for BGP Path Validation S. Bellovin R. Bush D. Ward August 2014 ASCII HTML 9 Routing BGP Security AS_PATH and RPKI

This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin Autonomous System (AS) has the right to announce the prefix and to provide assurance of the AS Path of the announcement.

 draft-ietf-sidr-bgpsec-reqs-12 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC7353 RFC7354 Update to the Registrant Information for the Digital Video Broadcasting Project (DVB) Uniform Resource Name (URN) Namespace A. Adolf P. Siebert September 2014 ASCII HTML 3

RFC 5328 registered the Uniform Resource Name (URN) namespace "dvb" for the Digital Video Broadcasting Project. This document updates RFC 5328 with new registrant information.

 draft-adolf-dvb-urn-upd-01 RFC5328 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7354 RFC7355 Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF) G. Salgueiro V. Pascual A. Roman S. Garcia September 2014 ASCII HTML 9

RFC 7118 specifies a WebSocket subprotocol as a reliable real-time transport mechanism between Session Initiation Protocol (SIP) entities to enable usage of SIP in web-oriented deployments. This document updates the SIP Common Log Format (CLF), defined in RFC 6873, with a new "Transport Flag" for such SIP WebSocket transport.

 draft-salgueiro-dispatch-websocket-sipclf-02 RFC6873 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7355 RFC7356 IS-IS Flooding Scope Link State PDUs (LSPs) L. Ginsberg S. Previdi Y. Yang September 2014 ASCII HTML 23

Intermediate System to Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers; however, the current flooding scopes are limited to either area scope or domain scope. There are existing use cases where support of other flooding scopes is desirable. This document defines new Protocol Data Units (PDUs) that provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. This document also defines extended Type-Length-Values (TLVs) and sub-TLVs that are encoded using 16-bit fields for Type and Length.

The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care.

 draft-ietf-isis-fs-lsp-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7356 RFC7357 Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol H. Zhai F. Hu R. Perlman D. Eastlake 3rd O. Stokes September 2014 ASCII HTML 31 ESADI TRILL RBridge Address Learning Reachability MAC Addresses

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topologies and link technologies. TRILL supports multipathing of both unicast and multicast traffic. Devices that implement the TRILL protocol are called TRILL switches or RBridges (Routing Bridges).

ESADI (End Station Address Distribution Information) is an optional protocol by which a TRILL switch can communicate, in a Data Label (VLAN or fine-grained label) scoped way, end station address and reachability information to TRILL switches participating in ESADI for the relevant Data Label. This document updates RFC 6325, specifically the documentation of the ESADI protocol, and is not backwards compatible.

 draft-ietf-trill-esadi-09 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7357 RFC7358 Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) K. Raza S. Boutros L. Martini N. Leymann October 2014 ASCII HTML 8

The label advertising behavior of an LDP speaker for a given Forwarding Equivalence Class (FEC) is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear. It also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the label advertisement mode for all currently defined LDP FEC types.

 draft-ietf-mpls-ldp-applicability-label-adv-03 RFC3212 RFC4447 RFC5036 RFC5918 RFC6388 RFC7140 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7358 RFC7359 Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks F. Gont August 2014 ASCII HTML 12

The subtle way in which the IPv6 and IPv4 protocols coexist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leakages. That is, traffic meant to be transferred over an encrypted and integrity- protected VPN tunnel may leak out of such a tunnel and be sent in the clear on the local network towards the final destination. This document discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software. Additionally, this document offers possible mitigations for this issue.

 draft-ietf-opsec-vpn-leakages-06 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC7359 RFC7360 Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS A. DeKok September 2014 ASCII HTML 27

The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets. The protocol transports data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can coexist with current RADIUS systems.

 draft-ietf-radext-dtls-13 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC7360 RFC7361 LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS) P. Dutta F. Balus O. Stokes G. Calvignac D. Fedyk September 2014 ASCII HTML 27 MAC flush message MAC Flush TLV MAC flushing

RFC 4762 describes a mechanism to remove or unlearn Media Access Control (MAC) addresses that have been dynamically learned in a Virtual Private LAN Service (VPLS) instance for faster convergence on topology changes. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology changes. This document defines an enhancement to the MAC address withdraw procedure with an empty MAC list (RFC 4762); this enhancement enables a Provider Edge (PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to RFC 4762 MAC withdraw procedures are specified to provide an optimized MAC flushing for the Provider Backbone Bridging (PBB) VPLS specified in RFC 7041.

 draft-ietf-l2vpn-vpls-ldp-mac-opt-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn http://www.rfc-editor.org/errata_search.php?rfc=7361 10.17487/RFC7361 RFC7362 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication E. Ivov H. Kaplan D. Wing September 2014 ASCII HTML 16 VoIP firewall traversal

This document describes the behavior of signaling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other.

This document is non-normative and is only written to explain HNT in order to provide a reference to the Internet community and an informative description to manufacturers and users.

Latching, which is one of the HNT components, has a number of security issues covered here. Because of those, and unless all security considerations explained here are taken into account and solved, the IETF advises against use of the latching mechanism over the Internet and recommends other solutions, such as the Interactive Connectivity Establishment (ICE) protocol.

 draft-ietf-mmusic-latching-08 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC7362 RFC7363 Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD) J. Maenpaa G. Camarillo September 2014 ASCII HTML 22 P2PSIP P2P Chord

REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size.

 draft-ietf-p2psip-self-tuning-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7363 RFC7364 Problem Statement: Overlays for Network Virtualization T. Narten Editor E. Gray Editor D. Black L. Fang L. Kreeger M. Napierala October 2014 ASCII HTML 23

This document describes issues associated with providing multi-tenancy in large data center networks and how these issues may be addressed using an overlay-based network virtualization approach. A key multi-tenancy requirement is traffic isolation so that one tenant's traffic is not visible to any other tenant. Another requirement is address space isolation so that different tenants can use the same address space within different virtual networks. Traffic and address space isolation is achieved by assigning one or more virtual networks to each tenant, where traffic within a virtual network can only cross into another virtual network in a controlled fashion (e.g., via a configured router and/or a security gateway). Additional functionality is required to provision virtual networks, associating a virtual machine's network interface(s) with the appropriate virtual network and maintaining that association as the virtual machine is activated, migrated, and/or deactivated. Use of an overlay-based approach enables scalable deployment on large network infrastructures.

 draft-ietf-nvo3-overlay-problem-statement-04 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC7364 RFC7365 Framework for Data Center (DC) Network Virtualization M. Lasserre F. Balus T. Morin N. Bitar Y. Rekhter October 2014 ASCII HTML 26 nvo3 network virtualization over layer 3

This document provides a framework for Data Center (DC) Network Virtualization over Layer 3 (NVO3) and defines a reference model along with logical components required to design a solution.

 draft-ietf-nvo3-framework-09 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC7365 RFC7366 Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) P. Gutmann September 2014 ASCII HTML 7

This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC-then-encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years.

 draft-ietf-tls-encrypt-then-mac-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7366 10.17487/RFC7366 RFC7367 Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process R. Cole J. Macker B. Adamson October 2014 ASCII HTML 65 Network Management Management Information Base MIB SMIv2 Routing MANET Multicast

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad Hoc Networks (MANETs). The SMF-MIB module also reports state information, performance information, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems.

 draft-ietf-manet-smf-mib-13 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC7367 RFC7368 IPv6 Home Networking Architecture Principles T. Chown Editor J. Arkko A. Brandt O. Troan J. Weil October 2014 ASCII HTML 49 IPv6

This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations, and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network.

 draft-ietf-homenet-arch-17 INFORMATIONAL INFORMATIONAL IETF int homenet 10.17487/RFC7368 RFC7369 GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration A. Takacs B. Gero H. Long October 2014 ASCII HTML 18 GELS Ethernet Label Switching PBB-TE connectivity monitoring OAM configuration

The work related to GMPLS Ethernet Label Switching (GELS) extended GMPLS RSVP-TE to support the establishment of Ethernet Label Switching Paths (LSPs). IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct Operations, Administration, and Maintenance (OAM) flow to check connectivity in Ethernet networks. CFM can also be used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of the GMPLS RSVP-TE protocol to support the setup of the associated Ethernet OAM entities of Ethernet LSPs and defines the Ethernet technology-specific TLVs based on the GMPLS OAM Configuration Framework. This document supports, but does not modify, the IEEE and ITU-T OAM mechanisms.

 draft-ietf-ccamp-rsvp-te-eth-oam-ext-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7369 RFC7370 Updates to the IS-IS TLV Codepoints Registry L. Ginsberg September 2014 ASCII HTML 7 Codepoint

This document recommends some editorial changes to the IANA "IS-IS TLV Codepoints" registry to more accurately document the state of the protocol. It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry.

 draft-ietf-isis-tlv-codepoints-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7370 RFC7371 Updates to the IPv6 Multicast Addressing Architecture M. Boucadair S. Venaas September 2014 ASCII HTML 10 IPv6 Multicast Flag Bits updated unicast-prefix-based address updated Embedded-RP

This document updates the IPv6 multicast addressing architecture by redefining the reserved bits as generic flag bits. The document also provides some clarifications related to the use of these flag bits.

This document updates RFCs 3956, 3306, and 4291.

 draft-ietf-6man-multicast-addr-arch-update-08 RFC3306 RFC3956 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7371 RFC7372 Email Authentication Status Codes M. Kucherawy September 2014 ASCII HTML 8

This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected or deferred specifically because of email authentication failures.

This document updates RFC 7208, since some of the code points registered replace the ones recommended for use in that document.

 draft-ietf-appsawg-email-auth-codes-07 RFC7208 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7372 RFC7373 Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types B. Trammell September 2014 ASCII HTML 14 information element unicode

This document defines UTF-8 representations for IP Flow Information Export (IPFIX) abstract data types (ADTs) to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings.

 draft-ietf-ipfix-text-adt-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7373 RFC7374 Service Discovery Usage for REsource LOcation And Discovery (RELOAD) J. Maenpaa G. Camarillo October 2014 ASCII HTML 20 P2PSIP ReDiR P2P DHT

REsource LOcation And Discovery (RELOAD) does not define a generic service discovery mechanism as a part of the base protocol (RFC 6940). This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism can be applied to RELOAD overlays to provide a generic service discovery mechanism.

 draft-ietf-p2psip-service-discovery-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7374 RFC7375 Secure Telephone Identity Threat Model J. Peterson October 2014 ASCII HTML 13 SIP Secure Origin Identification Communication Security RTCWeb Threat Real-Time Communication

As the Internet and the telephone network have become increasingly interconnected and interdependent, attackers can impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. This document analyzes threats in the resulting system, enumerating actors, reviewing the capabilities available to and used by attackers, and describing scenarios in which attacks are launched.

 draft-ietf-stir-threats-04 INFORMATIONAL INFORMATIONAL IETF rai stir 10.17487/RFC7375 RFC7376 Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN) T. Reddy R. Ravindranath M. Perumal A. Yegin September 2014 ASCII HTML 8

This document discusses some of the security problems and practical problems with the current Session Traversal Utilities for NAT (STUN) authentication for Traversal Using Relays around NAT (TURN) messages.

 draft-ietf-tram-auth-problems-05 INFORMATIONAL INFORMATIONAL IETF tsv tram 10.17487/RFC7376 RFC7377 IMAP4 Multimailbox SEARCH Extension B. Leiba A. Melnikov October 2014 ASCII HTML 11 IMAP email search multiple mailboxes imapext

The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX, UIDVALIDITY, and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237.

 draft-ietf-appsawg-multimailbox-search-04 RFC6237 RFC4466 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7377 RFC7378 Trustworthy Location H. Tschofenig H. Schulzrinne B. Aboba Editor December 2014 ASCII HTML 31

The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance.

This document describes threats to conveying location, particularly for emergency calls, and describes techniques that improve the reliability and security of location information. It also provides guidelines for assessing the trustworthiness of location information.

 draft-ietf-ecrit-trustworthy-location-14 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC7378 RFC7379 Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge Y. Li W. Hao R. Perlman J. Hudson H. Zhai October 2014 ASCII HTML 13

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing with rapid failover for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active connection at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus. This informational document discusses the high-level problems and goals when providing active-active connection at the TRILL edge.

 draft-ietf-trill-active-active-connection-prob-07 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC7379 RFC7380 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting J. Tong C. Bi Editor R. Even Q. Wu Editor R. Huang November 2014 ASCII HTML 11 TR 101 290

An MPEG2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/multicast MPEG2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG2 TS decodability statistics metrics related to transmissions of MPEG2 TS over RTP. The metrics specified in the RTCP XR block are related to Program Specific Information (PSI) carried in MPEG TS.

 draft-ietf-xrblock-rtcp-xr-psi-decodability-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7380 RFC7381 Enterprise IPv6 Deployment Guidelines K. Chittimaneni T. Chown L. Howard V. Kuarsingh Y. Pouffary E. Vyncke October 2014 ASCII HTML 34 IPV6 migration transition enterprise

Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6 while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual-stack network environment and eventually an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies.

 draft-ietf-v6ops-enterprise-incremental-ipv6-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7381 RFC7382 Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) S. Kent D. Kong K. Seo April 2015 ASCII HTML 38

This document contains a template to be used for creating a Certification Practice Statement (CPS) for an organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP.

 draft-ietf-sidr-cps-04 BCP0173 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC7382 RFC7383 Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation V. Smyslov November 2014 ASCII HTML 20 IP fragmentation NAT firewall PMTU discovery

This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through.

 draft-ietf-ipsecme-ikev2-fragmentation-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC7383 RFC7384 Security Requirements of Time Protocols in Packet Switched Networks T. Mizrahi October 2014 ASCII HTML 36 ptp precision time protocol ntp network time protocol

As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization.

 draft-ietf-tictoc-security-requirements-12 INFORMATIONAL INFORMATIONAL IETF int tictoc 10.17487/RFC7384 RFC7385 IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points L. Andersson G. Swallow October 2014 ASCII HTML 4

RFC 6514 created a space of Tunnel Type code points for a new BGP attribute called the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute". However, the RFC did not create a corresponding IANA registry.

There now is need to make further code point allocations from this name space. This document serves to update RFC 6514 in that it creates an IANA registry for that purpose.

 draft-ietf-l3vpn-pmsi-registry-07 RFC6514 RFC8317 RFC8338 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC7385 RFC7386 JSON Merge Patch P. Hoffman J. Snell October 2014 ASCII HTML 9 http json patch merge

This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.

 draft-ietf-appsawg-json-merge-patch-07 RFC7396 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7386 10.17487/RFC7386 RFC7387 A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network R. Key Editor L. Yong Editor S. Delord F. Jounay L. Jin October 2014 ASCII HTML 13 mef etherhet lan e-lan metro ethernet forum

This document describes an Ethernet-Tree (E-Tree) solution framework for supporting the Metro Ethernet Forum (MEF) E-Tree service over a Multiprotocol Label Switching (MPLS) network. The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network.

 draft-ietf-l2vpn-etree-frwk-10 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7387 RFC7388 Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) J. Schoenwaelder A. Sehgal T. Tsou C. Zhou October 2014 ASCII HTML 27 Network Management Management Information Base MIB SMIv2

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs).

 draft-ietf-6lo-lowpan-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7388 RFC7389 Separation of Control and User Plane for Proxy Mobile IPv6 R. Wakikawa R. Pazhyannur S. Gundavelli C. Perkins October 2014 ASCII HTML 12 Control and User Plane Split Control and User Plane Separation LMA User-Plane Address Mobility Option

This document specifies a method to split the control plane (CP) and user plane (UP) for a network infrastructure based on Proxy Mobile IPv6 (PMIPv6). Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care-of Address mobility option for IPv6 or Alternate IPv4 Care-of Address option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling an LMA to provide an alternate LMA address to be used for the bidirectional user-plane traffic between the MAG and LMA. With this new option, an LMA will be able to use an IP address for its user plane that is different than the IP address used for the control plane.

 draft-ietf-netext-pmip-cp-up-separation-07 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7389 RFC7390 Group Communication for the Constrained Application Protocol (CoAP) A. Rahman Editor E. Dijk Editor October 2014 ASCII HTML 46 multicast IP multicast RESTful Internet of Things (IoT)

The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This specification defines how CoAP should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies.

 draft-ietf-core-groupcomm-25 EXPERIMENTAL EXPERIMENTAL IETF app core 10.17487/RFC7390 RFC7391 Forwarding and Control Element Separation (ForCES) Protocol Extensions J. Hadi Salim October 2014 ASCII HTML 23 ForCES Protocol Extension

Experience in implementing and deploying the Forwarding and Control Element Separation (ForCES) architecture has demonstrated the need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. The ForCES protocol is extended with a table range operation and a new extension for error handling. This document updates the semantics in RFCs 5810 and 7121 to achieve that end goal.

 draft-ietf-forces-protoextension-06 RFC5810 RFC7121 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC7391 RFC7392 Explicit Path Routing for Dynamic Multi-Segment Pseudowires P. Dutta M. Bocci L. Martini December 2014 ASCII HTML 10 Pseudowire MS-PW explicit route

When set up through an explicit path, dynamic Multi-Segment Pseudowires (MS-PWs) may be required to provide a simple solution for 1:1 protection with diverse primary and backup MS-PWs for a service, or to enable controlled signaling (strict or loose) for special MS-PWs. This document specifies the extensions and procedures required to enable dynamic MS-PWs to be established along explicit paths.

 draft-ietf-pwe3-mspw-er-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7392 RFC7393 Using the Port Control Protocol (PCP) to Update Dynamic DNS X. Deng M. Boucadair Q. Zhao J. Huang C. Zhou November 2014 ASCII HTML 14 address sharing CGN service continuity service availability user-generated content address-sharing issues DS-Lite service delivery in CGN contexts

This document focuses on the problems encountered when using dynamic DNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) and Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64)) during IPv6 transition. Both issues and possible solutions are documented in this memo.

 draft-deng-pcp-ddns-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7393 RFC7394 Definition of Time to Live TLV for LSP-Ping Mechanisms S. Boutros S. Sivabalan G. Swallow S. Saxena V. Manral S. Aldrin November 2014 ASCII HTML 8

LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment Pseudowire (MS-PW) and/or bidirectional co-routed Label Switched Path (LSP) from any node on the path of the MS-PW and/or bidirectional co-routed LSP. This document defines a TLV to address this shortcoming.

 draft-ietf-mpls-lsp-ping-ttl-tlv-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7394 10.17487/RFC7394 RFC7395 An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket L. Stout Editor J. Moffitt E. Cestari October 2014 ASCII HTML 18 WebSocket XMPP

This document defines a binding for the Extensible Messaging and Presence Protocol (XMPP) over a WebSocket transport layer. A WebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP.

 draft-ietf-xmpp-websocket-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp 10.17487/RFC7395 RFC7396 JSON Merge Patch P. Hoffman J. Snell October 2014 ASCII HTML 9 http json patch merge

This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.

 draft-ietf-rfc7386bis-00 RFC7386 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7396 RFC7397 Report from the Smart Object Security Workshop J. Gilger H. Tschofenig December 2014 ASCII HTML 23 Smart Objects Internet of Things Workshop Security

This document provides a summary of a workshop on 'Smart Object Security' that took place in Paris on March 23, 2012. The main goal of the workshop was to allow participants to share their thoughts about the ability to utilize existing and widely deployed security mechanisms for smart objects.

This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.

 draft-gilger-smart-object-security-workshop-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7397 RFC7398 A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance M. Bagnulo T. Burbridge S. Crawford P. Eardley A. Morton February 2015 ASCII HTML 17 LMAP performance metrics

This document defines a reference path for Large-scale Measurement of Broadband Access Performance (LMAP) and measurement points for commonly used performance metrics. Other similar measurement projects may also be able to use the extensions described here for measurement point location. The purpose is to create an efficient way to describe the location of the measurement point(s) used to conduct a particular measurement.

 draft-ietf-ippm-lmap-path-07 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7398 RFC7399 Unanswered Questions in the Path Computation Element Architecture A. Farrel D. King October 2014 ASCII HTML 29 SDN Software Defined Networking H-PCE Hierarchical PCE VNTM Virtual Network Topology Manager ABNO Application-Based Network Operation TE Traffic Engineering

The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805.

These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts.

This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function.

 draft-ietf-pce-questions-08 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC7399 RFC7400 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) C. Bormann November 2014 ASCII HTML 24 IoT Internet of Things Embedded Internet Sensor Network WSN Constrained node Constrained network Constrained-node network LLN LoWPAN packet encoding capability indication 6CIO LZ77 RFC 6282 RFC 4944 adaptation layer IEEE 802.15.4

RFC 6282 defines header compression in 6LoWPAN packets (where "6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal Area Network"). The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each such new header or header-like payload.

 draft-ietf-6lo-ghc-05 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7400 RFC7401 Host Identity Protocol Version 2 (HIPv2) R. Moskowitz Editor T. Heer P. Jokela T. Henderson April 2015 ASCII HTML 128 HIP IP-layer state integrity protection optional encryption

This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP.

This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201.

 draft-ietf-hip-rfc5201-bis-20 RFC5201 RFC8002 PROPOSED STANDARD PROPOSED STANDARD IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=7401 10.17487/RFC7401 RFC7402 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) P. Jokela R. Moskowitz J. Melen April 2015 ASCII HTML 40 encryption user data packets

This memo specifies an Encapsulating Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). This document obsoletes RFC 5202.

 draft-ietf-hip-rfc5202-bis-07 RFC5202 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC7402 RFC7403 A Media-Based Traceroute Function for the Session Initiation Protocol (SIP) H. Kaplan November 2014 ASCII HTML 7

SIP already provides the ability to perform hop-by-hop traceroute for SIP messages using the Max-Forwards header field to determine the reachability path of requests to a target. A mechanism for media-loopback calls has also been defined separately, which enables test calls to be generated that result in media being looped back to the originator. This document describes a means of performing hop-by-hop traceroute-style test calls using the media-loopback mechanism to test the media path when SIP sessions go through media-relaying back-to-back user agents (B2BUAs).

 draft-ietf-straw-sip-traceroute-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai straw 10.17487/RFC7403 RFC7404 Using Only Link-Local Addressing inside an IPv6 Network M. Behringer E. Vyncke November 2014 ASCII HTML 10 IPv6 security routing Link-Local Routing Protocol Security

In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network.

 draft-ietf-opsec-lla-only-11 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=7404 10.17487/RFC7404 RFC7405 Case-Sensitive String Support in ABNF P. Kyzivat December 2014 ASCII HTML 4 BNF ABNF Syntax

This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.

 draft-kyzivat-case-sensitive-abnf-02 RFC5234 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7405 10.17487/RFC7405 RFC7406 Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices H. Schulzrinne S. McCann G. Bajko H. Tschofenig D. Kroeselberg December 2014 ASCII HTML 25

This document provides a problem statement, introduces terminology, and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network.

 draft-ietf-ecrit-unauthenticated-access-10 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC7406 RFC7407 A YANG Data Model for SNMP Configuration M. Bjorklund J. Schoenwaelder December 2014 ASCII HTML 88

This document defines a collection of YANG definitions for configuring SNMP engines.

 draft-ietf-netmod-snmp-cfg-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7407 10.17487/RFC7407 RFC7408 Forwarding and Control Element Separation (ForCES) Model Extension E. Haleplidis November 2014 ASCII HTML 31 ForCES Model Extension

This memo extends the Forwarding and Control Element Separation (ForCES) model defined in RFC 5812 and updates that RFC to allow complex data types for metadata, optional default values for data types, and optional access types for structures. It also fixes an issue with Logical Functional Block (LFB) inheritance and introduces two new features: a new event condition called eventBecomesEqualTo and LFB properties. The changes introduced in this memo do not alter the protocol and retain backward compatibility with older LFB models.

 draft-ietf-forces-model-extension-05 RFC5812 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=7408 10.17487/RFC7408 RFC7409 Forwarding and Control Element Separation (ForCES) Packet Parallelization E. Haleplidis J. Halpern November 2014 ASCII HTML 27 ForCES Model Extension

Many network devices support parallel packet processing. This document describes how Forwarding and Control Element Separation (ForCES) can model a network device's parallelization datapath using constructs defined by the ForCES model (RFC 5812) and controlled via the ForCES protocol (RFC 5810).

 draft-ietf-forces-packet-parallelization-03 EXPERIMENTAL EXPERIMENTAL IETF rtg forces 10.17487/RFC7409 RFC7410 A Property Types Registry for the Authentication-Results Header Field M. Kucherawy December 2014 ASCII HTML 5 Authentication-Results Reputation

This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values.

 draft-ietf-appsawg-authres-ptypes-registry-04 RFC7601 RFC7001 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7410 RFC7411 Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers T. Schmidt Editor M. Waehlisch R. Koodli G. Fairhurst D. Liu November 2014 ASCII HTML 30 Multicast Mobility IPv6 PIM MLD Group Communication

Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication and, hence, do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay-sensitive, real-time traffic and will benefit from fast handover completion. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by management of rapid context transfer between access routers and second at the data plane by optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy Router Advertisements message format.

This document updates RFC 5568, "Mobile IPv6 Fast Handovers".

 draft-ietf-multimob-fmipv6-pfmipv6-multicast-10 RFC5568 EXPERIMENTAL EXPERIMENTAL IETF int multimob 10.17487/RFC7411 RFC7412 Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection Y. Weingarten S. Aldrin P. Pan J. Ryoo G. Mirsky December 2014 ASCII HTML 16

This document presents the basic network objectives for the behavior of Shared Mesh Protection (SMP) that are not based on control-plane support. This document provides an expansion of the basic requirements presented in RFC 5654 ("Requirements of an MPLS Transport Profile") and RFC 6372 ("MPLS Transport Profile (MPLS-TP) Survivability Framework"). This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane.

 draft-ietf-mpls-smp-requirements-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7412 RFC7413 TCP Fast Open Y. Cheng J. Chu S. Radhakrishnan A. Jain December 2014 ASCII HTML 26

This document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.

 draft-ietf-tcpm-fastopen-10 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=7413 10.17487/RFC7413 RFC7414 A Roadmap for Transmission Control Protocol (TCP) Specification Documents M. Duke R. Braden W. Eddy E. Blanton A. Zimmermann February 2015 ASCII HTML 57 TCP Roadmap

This document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.

This document obsoletes RFC 4614.

 draft-ietf-tcpm-tcp-rfc4614bis-08 RFC4614 RFC7805 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC7414 RFC7415 Session Initiation Protocol (SIP) Rate Control E. Noel P. Williams February 2015 ASCII HTML 15

The prevalent use of the Session Initiation Protocol (SIP) in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. A loss-based solution to remedy known vulnerabilities of the SIP 503 (Service Unavailable) overload control mechanism has already been proposed. Using the same signaling, this document proposes a rate-based control scheme to complement the loss-based control scheme.

 draft-ietf-soc-overload-rate-control-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai soc 10.17487/RFC7415 RFC7416 A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) T. Tsao R. Alexander M. Dohler V. Daza A. Lozano M. Richardson Editor January 2015 ASCII HTML 40 LLN ROLL security

This document presents a security threat analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements.

 draft-ietf-roll-security-threats-11 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC7416 RFC7417 Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains G. Karagiannis A. Bhargava December 2014 ASCII HTML 36 generic aggregate rsvp

This document specifies extensions to Generic Aggregate RSVP (RFC 4860) for support of the Pre-Congestion Notification (PCN) Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using PCN.

 draft-ietf-tsvwg-rsvp-pcn-11 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC7417 RFC7418 An IRTF Primer for IETF Participants S. Dawkins Editor December 2014 ASCII HTML 7 Research Group

This document provides a high-level description of things for Internet Engineering Task Force (IETF) participants to consider when bringing proposals for new research groups (RGs) into the Internet Research Task Force (IRTF). This document emphasizes differences in expectations between the two organizations.

 draft-dawkins-irtf-newrg-05 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7418 RFC7419 Common Interval Support in Bidirectional Forwarding Detection N. Akiya M. Binderberger G. Mirsky December 2014 ASCII HTML 8 BFD hardware interval timer

Bidirectional Forwarding Detection (BFD) requires that messages be transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common value for the interval to run BFD sessions.

This document updates RFC 5880 by defining a small set of interval values for BFD that we call "Common Intervals" and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common Intervals.

 draft-ietf-bfd-intervals-05 RFC5880 INFORMATIONAL INFORMATIONAL IETF rtg bfd 10.17487/RFC7419 RFC7420 Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module A. Koushik E. Stephan Q. Zhao D. King J. Hardwick December 2014 ASCII HTML 65 Network Management Management Information Base MIB SMIv2 PCE PCEP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs.

 draft-ietf-pce-pcep-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=7420 10.17487/RFC7420 RFC7421 Analysis of the 64-bit Boundary in IPv6 Addressing B. Carpenter Editor T. Chown F. Gont S. Jiang A. Petrescu A. Yourtchenko January 2015 ASCII HTML 24

The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet. Currently, the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the subnet prefix. This document describes the advantages of this fixed boundary and analyzes the issues that would be involved in treating it as a variable boundary.

 draft-ietf-6man-why64-08 INFORMATIONAL INFORMATIONAL IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=7421 10.17487/RFC7421 RFC7422 Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments C. Donley C. Grundemann V. Sarawat K. Sundaresan O. Vautrin December 2014 ASCII HTML 14

In some instances, Service Providers (SPs) have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g., for abuse response). Unfortunately, many logging solutions for Carrier-Grade NATs (CGNs) require active logging of dynamic translations. CGN port assignments are often per connection, but they could optionally use port ranges. Research indicates that per-connection logging is not scalable in many residential broadband services. This document suggests a way to manage CGN translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. IPv6 is, of course, the preferred solution. While deployment is in progress, SPs are forced by business imperatives to maintain support for IPv4. This note addresses the IPv4 part of the network when a CGN solution is in use.

 draft-donley-behave-deterministic-cgn-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7422 10.17487/RFC7422 RFC7423 Diameter Applications Design Guidelines L. Morand Editor V. Fajardo H. Tschofenig November 2014 ASCII HTML 29 AAA Authentication Authorization Accounting

The Diameter base protocol provides facilities for protocol extensibility enabling the definition of new Diameter applications or modification of existing applications. This document is a companion document to the Diameter base protocol that further explains and clarifies the rules to extend Diameter. Furthermore, this document provides guidelines to Diameter application designers reusing/ defining Diameter applications or creating generic Diameter extensions.

 draft-ietf-dime-app-design-guide-28 BCP0193 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dime 10.17487/RFC7423 RFC7424 Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks R. Krishnan L. Yong A. Ghanwani N. So B. Khasnabish January 2015 ASCII HTML 29

Demands on networking infrastructure are growing exponentially due to bandwidth-hungry applications such as rich media applications and inter-data-center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal-cost multipaths as techniques for bandwidth scaling. This document explores some of the mechanisms useful for achieving this.

 draft-ietf-opsawg-large-flow-load-balancing-15 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7424 RFC7425 Adobe's RTMFP Profile for Flash Communication M. Thornburgh December 2014 ASCII HTML 49

This memo describes how to use Adobe's Secure Real-Time Media Flow Protocol (RTMFP) to transport the video, audio, and data messages of Adobe Flash platform communications. Aspects of this application profile include cryptographic methods and data formats, flow metadata formats, and protocol details for client-server and peer-to-peer communication.

 draft-thornburgh-rtmfp-flash-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7425 RFC7426 Software-Defined Networking (SDN): Layers and Architecture Terminology E. Haleplidis Editor K. Pentikousis Editor S. Denazis J. Hadi Salim D. Meyer O. Koufopavlou January 2015 ASCII HTML 35 Software-defined Networking SDN Programmable Networks Architecture Layer Terminology

Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.

 draft-irtf-sdnrg-layer-terminology-04 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=7426 10.17487/RFC7426 RFC7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) T. Kivinen J. Snyder January 2015 ASCII HTML 18 IPsec IKE IKEv2 Signature Authentication RSA DSS DSA ECDSA SASSA-PSS PKIX

The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism and is not limited to ECDSA; it can also be used with other signature algorithms.

 draft-kivinen-ipsecme-signature-auth-07 RFC7296 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=7427 10.17487/RFC7427 RFC7428 Transmission of IPv6 Packets over ITU-T G.9959 Networks A. Brandt J. Buron February 2015 ASCII HTML 21

This document describes the frame format for transmission of IPv6 packets as well as a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.

 draft-ietf-6lo-lowpanz-08 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7428 RFC7429 Distributed Mobility Management: Current Practices and Gap Analysis D. Liu Editor JC. Zuniga Editor P. Seite H. Chan CJ. Bernardos January 2015 ASCII HTML 34 DMM Distributed Mobility Management anchor gap analysis best practices

This document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution.

 draft-ietf-dmm-best-practices-gap-analysis-09 INFORMATIONAL INFORMATIONAL IETF int dmm 10.17487/RFC7429 RFC7430 Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP) M. Bagnulo C. Paasch F. Gont O. Bonaventure C. Raiciu July 2015 ASCII HTML 19 MPTCP security threat analysis

This document analyzes the residual threats for Multipath TCP (MPTCP) and explores possible solutions to address them.

 draft-ietf-mptcp-attacks-04 INFORMATIONAL INFORMATIONAL IETF tsv mptcp http://www.rfc-editor.org/errata_search.php?rfc=7430 10.17487/RFC7430 RFC7431 Multicast-Only Fast Reroute A. Karan C. Filsfils IJ. Wijnands Editor B. Decraene August 2015 ASCII HTML 14

As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services. This document describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast-only Fast Reroute (MoFRR) works by making simple enhancements to multicast routing protocols such as Protocol Independent Multicast (PIM) and Multipoint LDP (mLDP).

 draft-ietf-rtgwg-mofrr-08 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC7431 RFC7432 BGP MPLS-Based Ethernet VPN A. Sajassi Editor R. Aggarwal N. Bitar A. Isaac J. Uttaro J. Drake W. Henderickx February 2015 ASCII HTML 56

This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".

 draft-ietf-l2vpn-evpn-11 RFC8584 RFC9161 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn http://www.rfc-editor.org/errata_search.php?rfc=7432 10.17487/RFC7432 RFC7433 A Mechanism for Transporting User-to-User Call Control Information in SIP A. Johnston J. Rafferty January 2015 ASCII HTML 19 UUI Package Content Encoding Media

There is a class of applications that benefit from using SIP to exchange User-to-User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session and utilized by an application accepting the session. The syntax and semantics for the UUI data used by a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism.

 draft-ietf-cuss-sip-uui-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai cuss 10.17487/RFC7433 RFC7434 Interworking ISDN Call Control User Information with SIP K. Drage Editor A. Johnston January 2015 ASCII HTML 17 UUS Supplementary Service

The motivation and use cases for interworking and transporting User- to-User Information (UUI) from the ITU-T Digital Subscriber Signalling System No. 1 (DSS1) User-user information element within SIP are described in RFC 6567. As networks move to SIP, it is important that applications requiring this data can continue to function in SIP networks as well as have the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package called the ISDN UUI package) of the User-to-User header field to enable interworking with this ISDN service.

This document covers interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed.

The package is identified by the new value "isdn-uui" of the "purpose" header field parameter.

 draft-ietf-cuss-sip-uui-isdn-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai cuss http://www.rfc-editor.org/errata_search.php?rfc=7434 10.17487/RFC7434 RFC7435 Opportunistic Security: Some Protection Most of the Time V. Dukhovni December 2014 ASCII HTML 11 authentication encryption

This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet.

 draft-dukhovni-opportunistic-security-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7435 RFC7436 IP-Only LAN Service (IPLS) H. Shah E. Rosen F. Le Faucheur G. Heron January 2015 ASCII HTML 32

A Virtual Private LAN Service (VPLS) is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems that are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination Media Access Control (MAC) addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in the IEEE's "Media Access Control (MAC) Bridges". This document specifies the protocol extensions and procedures for support of the IPLS service.

The original intent was to provide an alternate solution to VPLS for those Provider Edge (PE) routers that were not capable of learning MAC addresses through data plane. This became a non-issue with newer hardware. The concepts put forth by this document are still valuable and are adopted in one form or other by newer work such as Ethernet VPN in L2VPN working group and possible data center applications. At this point, no further action is planned to update this document and it is published simply as a historic record of the ideas.

 draft-ietf-l2vpn-ipls-16 HISTORIC HISTORIC IETF rtg l2vpn 10.17487/RFC7436 RFC7437 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees M. Kucherawy Editor January 2015 ASCII HTML 35 Internet Architecture Board Engineering Steering Group nomcom IAOC

The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document. This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various updates since that version was published.

 draft-kucherawy-rfc3777bis-04 RFC3777 RFC5078 RFC5633 RFC5680 RFC6859 RFC8713 RFC8318 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7437 RFC7438 Multipoint LDP (mLDP) In-Band Signaling with Wildcards IJ. Wijnands Editor E. Rosen A. Gulko U. Joorde J. Tantsura January 2015 ASCII HTML 16 mpls multicast

There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" into an MPLS Multipoint Label Switched Path (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either Source-Specific Multicast trees or Bidirectional Multicast trees) to be attached to an MPLS Multipoint Label Switched Path (MP-LSP). However, the previous documents do not specify procedures for attaching IP Any-Source Multicast trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP- LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP. Support for non-bidirectional IP Any-Source Multicast trees is subject to certain applicability restrictions that are discussed in this document. This document updates RFCs 6826 and 7246.

 draft-ietf-mpls-mldp-in-band-wildcard-encoding-03 RFC6826 RFC7246 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7438 RFC7439 Gap Analysis for Operating IPv6-Only MPLS Networks W. George Editor C. Pignataro Editor January 2015 ASCII HTML 28 MPLS LDP IPv6 RSVP L3VPN L2VPN

This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is intended to focus on gaps in the standards defining the MPLS suite, and is not intended to highlight particular vendor implementations (or lack thereof) in the context of IPv6-only MPLS functionality.

In the data plane, MPLS fully supports IPv6, and MPLS labeled packets can be carried over IPv6 packets in a variety of encapsulations. However, support for IPv6 among MPLS control-plane protocols, MPLS applications, MPLS Operations, Administration, and Maintenance (OAM), and MIB modules is mixed, with some protocols having major gaps. For most major gaps, work is in progress to upgrade the relevant protocols.

 draft-ietf-mpls-ipv6-only-gap-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7439 10.17487/RFC7439 RFC7440 TFTP Windowsize Option P. Masotta January 2015 ASCII HTML 9

The "Trivial File Transfer Protocol" (RFC 1350) is a simple, lockstep, file transfer protocol that allows a client to get or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a Local Area Network (LAN). TFTP has been used for this application because it is very simple to implement. The employment of a lockstep scheme limits throughput when used on a LAN.

This document describes a TFTP option that allows the client and server to negotiate a window size of consecutive blocks to send as an alternative for replacing the single-block lockstep schema. The TFTP option mechanism employed is described in "TFTP Option Extension" (RFC 2347).

 draft-masotta-tftpexts-windowsize-opt-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7440 RFC7441 Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes IJ. Wijnands E. Rosen U. Joorde January 2015 ASCII HTML 10

Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in their VPNs. It is also desirable to be able to support customers who have MPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multipoint LDP (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. This document updates RFC 6514.

 draft-ietf-l3vpn-mvpn-mldp-nlri-10 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7441 RFC7442 Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP) Y. Rekhter R. Aggarwal N. Leymann W. Henderickx Q. Zhao R. Li February 2015 ASCII HTML 11

When IP multicast trees created by Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths (P2MP LSPs). This document describes how to accomplish this in the case where such P2MP LSPs are established using Label Distribution Protocol (LDP) Extensions for P2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP).

 draft-ietf-mpls-pim-sm-over-mldp-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7442 RFC7443 Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages P. Patil T. Reddy G. Salgueiro M. Petit-Huguenin January 2015 ASCII HTML 5

Application-Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) usages, such as Traversal Using Relays around NAT (TURN) and NAT discovery, are defined in this document to allow an application layer to negotiate STUN usages within the Transport Layer Security (TLS) connection. ALPN protocol identifiers defined in this document apply to both TLS and Datagram Transport Layer Security (DTLS).

 draft-ietf-tram-alpn-08 INFORMATIONAL INFORMATIONAL IETF tsv tram 10.17487/RFC7443 RFC7444 Security Labels in Internet Email K. Zeilenga A. Melnikov February 2015 ASCII HTML 16 email header fields ESS Security Label Confidential Label Message Sensitivity

This document describes a header field, SIO-Label, for use in Internet email to convey the sensitivity of the message. This header field may carry a textual representation (a display marking) and/or a structural representation (a security label) of the sensitivity of the message. This document also describes a header field, SIO-Label-History, for recording changes in the message's label.

 draft-zeilenga-email-seclabel-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7444 RFC7445 Analysis of Failure Cases in IPv6 Roaming Scenarios G. Chen H. Deng D. Michaud J. Korhonen M. Boucadair March 2015 ASCII HTML 19 Mobile Network Dual Stack IPv6-only

This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios. The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks.

 draft-ietf-v6ops-ipv6-roaming-analysis-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7445 RFC7446 Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Y. Lee Editor G. Bernstein Editor D. Li W. Imajuku February 2015 ASCII HTML 23 WSON RWA

This document provides a model of information needed by the Routing and Wavelength Assignment (RWA) process in Wavelength Switched Optical Networks (WSONs). The purpose of the information described in this model is to facilitate constrained optical path computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed.

 draft-ietf-ccamp-rwa-info-24 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7446 RFC7447 Deprecation of BGP Entropy Label Capability Attribute J. Scudder K. Kompella February 2015 ASCII HTML 4

The BGP Entropy Label Capability attribute is defined in RFC 6790. Regrettably, it has a bug: although RFC 6790 mandates that routers incapable of processing Entropy Labels must remove the attribute, fulfillment of this requirement cannot be guaranteed in practice. This specification deprecates the attribute. A forthcoming document will propose a replacement.

 draft-ietf-mpls-deprecate-bgp-entropy-label-02 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7447 RFC7448 MIB Transfer from the IETF to the IEEE 802.3 WG T. Taylor Editor D. Romascanu February 2015 ASCII HTML 7 Ethernet IEEE

This document records the transfer of responsibility for the Ethernet-related MIB modules DOT3-OAM-MIB, SNMP-REPEATER-MIB, POWER-ETHERNET-MIB, DOT3-EPON-MIB, EtherLike-MIB, EFM-CU-MIB, ETHER-WIS, and MAU-MIB from the IETF to the IEEE 802.3 Working Group (WG). This document also describes the procedures associated with the transfer in a similar way to how RFC 4663 records the transfer of the IETF Bridge MIB work to the IEEE 802.1 WG.

 draft-ietf-opsawg-mibs-to-ieee80231-01 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7448 RFC7449 Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment Y. Lee Editor G. Bernstein Editor J. Martensson T. Takeda T. Tsuritani O. Gonzalez de Dios February 2015 ASCII HTML 12

This memo provides application-specific requirements for the Path Computation Element Communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSONs). Lightpath provisioning in WSONs requires a Routing and Wavelength Assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for PCEP extensions in support of optical impairments will be addressed in a separate document.

 draft-ietf-pce-wson-routing-wavelength-15 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC7449 RFC7450 Automatic Multicast Tunneling G. Bumgardner February 2015 ASCII HTML 82 AMT IGMPv2 IGMPv3 MLDv1 MLDv2 ASM SSM amt gateway amt relay multicast replication multicast encapsulation

This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.

The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure.

 draft-ietf-mboned-auto-multicast-18 RFC8777 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC7450 RFC7451 Extension Registry for the Extensible Provisioning Protocol S. Hollenbeck February 2015 ASCII HTML 12 domain host contact

The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions.

 draft-ietf-eppext-reg-10 INFORMATIONAL INFORMATIONAL IETF app eppext 10.17487/RFC7451 RFC7452 Architectural Considerations in Smart Object Networking H. Tschofenig J. Arkko D. Thaler D. McPherson March 2015 ASCII HTML 24 IAB Statement Smart Objects

The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered by Internet protocols. Many of these devices, often called "smart objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment. Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice.

This document offers guidance to engineers designing Internet- connected smart objects.

 draft-iab-smart-object-architecture-06 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7452 RFC7453 MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB) V. Mahalingam K. Sampath S. Aldrin T. Nadeau February 2015 ASCII HTML 62

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects and textual conventions for tunnels, identifiers, and Label Switching Routers to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks.

 draft-ietf-mpls-tp-te-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7453 RFC7454 BGP Operations and Security J. Durand I. Pepelnjak G. Doering February 2015 ASCII HTML 26

The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances.

This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing.

 draft-ietf-opsec-bgp-security-07 BCP0194 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsec 10.17487/RFC7454 RFC7455 Transparent Interconnection of Lots of Links (TRILL): Fault Management T. Senevirathne N. Finn S. Salam D. Kumar D. Eastlake 3rd S. Aldrin Y. Li March 2015 ASCII HTML 63 Fault Continuity Connectivity OAM CFM MEP CCM

This document specifies Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) fault management. Methods in this document follow the CFM (Connectivity Fault Management) framework defined in IEEE 802.1 and reuse OAM tools where possible. Additional messages and TLVs are defined for TRILL-specific applications or for cases where a different set of information is required other than CFM as defined in IEEE 802.1. This document updates RFC 6325.

 draft-ietf-trill-oam-fm-11 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7455 RFC7456 Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) T. Mizrahi T. Senevirathne S. Salam D. Kumar D. Eastlake 3rd March 2015 ASCII HTML 32

Performance Monitoring (PM) is a key aspect of Operations, Administration, and Maintenance (OAM). It allows network operators to verify the Service Level Agreement (SLA) provided to customers and to detect network anomalies. This document specifies mechanisms for Loss Measurement and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) networks.

 draft-ietf-trill-loss-delay-08 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7456 RFC7457 Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) Y. Sheffer R. Holz P. Saint-Andre February 2015 ASCII HTML 13 Transport Layer Security TLS Datagram TLS DTLS Secure Sockets Layer SSL security attacks

Over the last few years, there have been several serious attacks on Transport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and Datagram TLS (DTLS).

 draft-ietf-uta-tls-attacks-05 INFORMATIONAL INFORMATIONAL IETF app uta http://www.rfc-editor.org/errata_search.php?rfc=7457 10.17487/RFC7457 RFC7458 Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core R. Valmikam R. Koodli February 2015 ASCII HTML 18 Mobile Networks 3GPP EAP EPC Handover Identity APN

With Wi-Fi emerging as a crucial access network for mobile service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks.

The EAP Authentication and Key Agreement (EAP-AKA), and EAP-AKA', protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in such networks. The attributes are exchanged between a client (such as a Mobile Node (MN)) and its network counterpart (such as an Authentication, Authorization, and Accounting (AAA) server) in the service provider's infrastructure.

 draft-ietf-netext-wifi-epc-eap-attributes-16 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC7458 RFC7459 Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO) M. Thomson J. Winterbottom February 2015 ASCII HTML 39

This document defines key concepts of uncertainty and confidence as they pertain to location information. Methods for the manipulation of location estimates that include uncertainty information are outlined.

This document normatively updates the definition of location information representations defined in RFCs 4119 and 5491. It also deprecates related terminology defined in RFC 3693.

 draft-ietf-geopriv-uncertainty-04 RFC3693 RFC4119 RFC5491 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7459 RFC7460 Monitoring and Control MIB for Power and Energy M. Chandramouli B. Claise B. Schoening J. Quittek T. Dietz March 2015 ASCII HTML 69 management information base IANAPowerStateSet-MIB ENERGY-OBJECT-MIB POWER-ATTRIBUTES-MIB

This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices.

 draft-ietf-eman-energy-monitoring-mib-13 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman 10.17487/RFC7460 RFC7461 Energy Object Context MIB J. Parello B. Claise M. Chandramouli March 2015 ASCII HTML 32 management information base ENERGY-OBJECT-CONTEXT-MIB IANA-ENERGY-RELATION-MIB

This document defines a subset of a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the energy relationships between devices.

 draft-ietf-eman-energy-aware-mib-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman 10.17487/RFC7461 RFC7462 URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP) L. Liess Editor R. Jesske A. Johnston D. Worley P. Kyzivat March 2015 ASCII HTML 46

The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the User Agent (UA) as an alerting signal (e.g., a ring tone or ringback tone) when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification.

This document normatively updates RFC 3261, which defines the Session Initiation Protocol (SIP). It changes the usage of the Alert-Info header field defined in RFC 3261 by additionally allowing its use in any non-100 provisional response to INVITE. This document also permits proxies to add or remove an Alert-Info header field and to add or remove Alert-Info header field values.

 draft-ietf-salud-alert-info-urns-14 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai salud 10.17487/RFC7462 RFC7463 Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) A. Johnston Editor M. Soroushnejad Editor V. Venkataramanan March 2015 ASCII HTML 72

This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP Private Branch Exchange (IPBX) offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements, and defines extensions to implement this feature. This specification updates RFCs 3261 and 4235.

 draft-ietf-bliss-shared-appearances-15 RFC3261 RFC4235 PROPOSED STANDARD PROPOSED STANDARD IETF rai bliss http://www.rfc-editor.org/errata_search.php?rfc=7463 10.17487/RFC7463 RFC7464 JavaScript Object Notation (JSON) Text Sequences N. Williams February 2015 ASCII HTML 8 JSON sequence online streaming log file

This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A).

 draft-ietf-json-text-sequence-13 PROPOSED STANDARD PROPOSED STANDARD IETF app json http://www.rfc-editor.org/errata_search.php?rfc=7464 10.17487/RFC7464 RFC7465 Prohibiting RC4 Cipher Suites A. Popov February 2015 ASCII HTML 6 TLS transport layer security

This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions. This document updates RFCs 5246, 4346, and 2246.

 draft-ietf-tls-prohibiting-rc4-01 RFC5246 RFC4346 RFC2246 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7465 RFC7466 An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) C. Dearlove T. Clausen March 2015 ASCII HTML 9 MANET NHDP OLSRv2 link quality

The link quality mechanism of the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold while still retaining the corresponding link information as acquired from the HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently.

NHDP also collects information about symmetric 2-hop neighbors. However, it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" (as described above), then corresponding symmetric 2-hop neighbors are removed. This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment.

This specification updates RFC 6130 "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)" and RFC 7181 "The Optimized Link State Routing Protocol Version 2 (OLSRv2)" to permit, as an option, retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more "robust".

 draft-ietf-manet-nhdp-optimization-04 RFC6130 RFC7181 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7466 RFC7467 URN Namespace for the North Atlantic Treaty Organization (NATO) A. Murdock April 2015 ASCII HTML 8

This document allocates a formal Uniform Resource Name (URN) namespace for assignment by the North Atlantic Treaty Organization (NATO), as specified in RFC 3406. At this time, the URN will be used primarily to uniquely identify Extensible Markup Language (XML) artefacts that provide information about NATO message text formats and service specifications as described in various NATO standards, instructions, and publications.

 draft-murdock-nato-nid-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7467 RFC7468 Textual Encodings of PKIX, PKCS, and CMS Structures S. Josefsson S. Leonard April 2015 ASCII HTML 20

This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate.

 draft-josefsson-pkix-textual-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7468 10.17487/RFC7468 RFC7469 Public Key Pinning Extension for HTTP C. Evans C. Palmer R. Sleevi April 2015 ASCII HTML 28 pin

This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.

 draft-ietf-websec-key-pinning-21 PROPOSED STANDARD PROPOSED STANDARD IETF app websec http://www.rfc-editor.org/errata_search.php?rfc=7469 10.17487/RFC7469 RFC7470 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol F. Zhang A. Farrel March 2015 ASCII HTML 14

The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.

This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Value (TLV) that can be carried in any PCEP object that supports TLVs.

This document obsoletes RFC 7150. The only changes from that document are a clarification of the use of the new Type-Length-Value and the allocation of a different code point for the VENDOR-INFORMATION object.

 draft-ietf-pce-rfc7150bis-01 RFC7150 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC7470 RFC7471 OSPF Traffic Engineering (TE) Metric Extensions S. Giacalone D. Ward J. Drake A. Atlas S. Previdi March 2015 ASCII HTML 19

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection.

This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance.

Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document.

 draft-ietf-ospf-te-metric-extensions-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7471 RFC7472 Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme I. McDonald M. Sweet March 2015 ASCII HTML 19

This document defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, which is used to designate the access to the network location of a secure IPP print service or a network resource managed by such a service.

This document defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this document does not update or obsolete RFC 3510.

 draft-mcdonald-ipps-uri-scheme-18 RFC2910 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7472 RFC7473 Controlling State Advertisements of Non-negotiated LDP Applications K. Raza S. Boutros March 2015 ASCII HTML 15

There is no capability negotiation done for Label Distribution Protocol (LDP) applications that set up Label Switched Paths (LSPs) for IP prefixes or that signal point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or the Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise been advertised over the established LDP session.

 draft-ietf-mpls-ldp-ip-pw-capability-09 RFC8223 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7473 RFC7474 Security Extension for OSPFv2 When Using Manual Key Management M. Bhatia S. Hartman D. Zhang A. Lindem Editor April 2015 ASCII HTML 14 OSPF cryptographic authentication security replay attacks

The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.

This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.

 draft-ietf-ospf-security-extension-manual-keying-11 RFC2328 RFC5709 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7474 RFC7475 Increasing the Number of Area Directors in an IETF Area S. Dawkins March 2015 ASCII HTML 5

This document removes a limit on the number of Area Directors who manage an Area in the definition of "IETF Area". This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).

 draft-dawkins-iesg-one-or-more-05 RFC2026 RFC2418 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7475 RFC7476 Information-Centric Networking: Baseline Scenarios K. Pentikousis Editor B. Ohlman D. Corujo G. Boggia G. Tyson E. Davies A. Molinaro S. Eum March 2015 ASCII HTML 45

This document aims at establishing a common understanding about a set of scenarios that can be used as a base for the evaluation of different information-centric networking (ICN) approaches so that they can be tested and compared against each other while showcasing their own advantages. Towards this end, we review the ICN literature and document scenarios which have been considered in previous performance evaluation studies. We discuss a variety of aspects that an ICN solution can address. This includes general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficiency, energy consumption frugality, and disruption and delay tolerance. We detail ICN-specific aspects as well, such as information security and trust, persistence, availability, provenance, and location independence.

This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).

 draft-irtf-icnrg-scenarios-03 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7476 RFC7477 Child-to-Parent Synchronization in DNS W. Hardaker March 2015 ASCII HTML 15

This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy.

 draft-ietf-dnsop-child-syncronization-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7477 10.17487/RFC7477 RFC7478 Web Real-Time Communication Use Cases and Requirements C. Holmberg S. Hakansson G. Eriksson March 2015 ASCII HTML 28 webrtc browser websocket real-time

This document describes web-based real-time communication use cases. Requirements on the browser functionality are derived from the use cases.

This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WG's efforts so far. It is being published to record the early conclusions of the WG. It will not be used as a set of rigid guidelines that specifications and implementations will be held to in the future.

 draft-ietf-rtcweb-use-cases-and-requirements-16 INFORMATIONAL INFORMATIONAL IETF rai rtcweb 10.17487/RFC7478 RFC7479 Using Ed25519 in SSHFP Resource Records S. Moonesamy March 2015 ASCII HTML 4

The Ed25519 signature algorithm has been implemented in OpenSSH. This document updates the IANA "SSHFP RR Types for public key algorithms" registry by adding an algorithm number for Ed25519.

 draft-moonesamy-sshfp-ed25519-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7479 10.17487/RFC7479 RFC7480 HTTP Usage in the Registration Data Access Protocol (RDAP) A. Newton B. Ellacott N. Kong March 2015 ASCII HTML 16 Registry WHOIS

This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application.

 draft-ietf-weirds-using-http-15 STD0095 INTERNET STANDARD PROPOSED STANDARD IETF app weirds 10.17487/RFC7480 RFC7481 Security Services for the Registration Data Access Protocol (RDAP) S. Hollenbeck N. Kong March 2015 ASCII HTML 13 RDAP Security

The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP.

 draft-ietf-weirds-rdap-sec-12 STD0095 INTERNET STANDARD PROPOSED STANDARD IETF app weirds 10.17487/RFC7481 RFC7482 Registration Data Access Protocol (RDAP) Query Format A. Newton S. Hollenbeck March 2015 ASCII HTML 20 WHOIS

This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP).

 draft-ietf-weirds-rdap-query-18 RFC9082 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds http://www.rfc-editor.org/errata_search.php?rfc=7482 10.17487/RFC7482 RFC7483 JSON Responses for the Registration Data Access Protocol (RDAP) A. Newton S. Hollenbeck March 2015 ASCII HTML 78 WHOIS

This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses.

 draft-ietf-weirds-json-response-14 RFC9083 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds http://www.rfc-editor.org/errata_search.php?rfc=7483 10.17487/RFC7483 RFC7484 Finding the Authoritative Registration Data (RDAP) Service M. Blanchet March 2015 ASCII HTML 17 whois bootstrap IDN AS IPv4 IPv6 JSON

This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers.

 draft-ietf-weirds-bootstrap-11 RFC9224 RFC8521 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds http://www.rfc-editor.org/errata_search.php?rfc=7484 10.17487/RFC7484 RFC7485 Inventory and Analysis of WHOIS Registration Objects L. Zhou N. Kong S. Shen S. Sheng A. Servin March 2015 ASCII HTML 33 whois restful weirds response object inventory

WHOIS output objects from registries, including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs), were collected and analyzed. This document describes the process and results of the statistical analysis of existing WHOIS information. The purpose of this document is to build an object inventory to facilitate discussions of data objects included in Registration Data Access Protocol (RDAP) responses.

 draft-ietf-weirds-object-inventory-06 INFORMATIONAL INFORMATIONAL IETF app weirds 10.17487/RFC7485 RFC7486 HTTP Origin-Bound Authentication (HOBA) S. Farrell P. Hoffman M. Thomas March 2015 ASCII HTML 28 Network Working Group http authentication origin-bound key

HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.

 draft-ietf-httpauth-hoba-10 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth 10.17487/RFC7486 RFC7487 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE E. Bellagamba A. Takacs G. Mirsky L. Andersson P. Skoldstrom D. Ward March 2015 ASCII HTML 32 RSVP-TE GMPLS MPLS MPLS-TP OAM

This specification describes the configuration of proactive MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the GMPLS RSVP-TE protocol based on the OAM Configuration Framework for GMPLS RSVP-TE.

 draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7487 RFC7488 Port Control Protocol (PCP) Server Selection M. Boucadair R. Penno D. Wing P. Patil T. Reddy March 2015 ASCII HTML 12 PCP Server discovery Port Mapping Shared Address Multiple PCP Servers

This document specifies the behavior to be followed by a Port Control Protocol (PCP) client to contact its PCP server(s) when one or several PCP server IP addresses are configured.

This document updates RFC 6887.

 draft-ietf-pcp-server-selection-10 RFC6887 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7488 RFC7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC) M. Kucherawy Editor E. Zwicky Editor March 2015 ASCII HTML 73 domain email security messaging dkim spf authentication reporting conformance

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.

Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.

DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.

 draft-kucherawy-dmarc-base-12 RFC8553 RFC8616 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7489 10.17487/RFC7489 RFC7490 Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) S. Bryant C. Filsfils S. Previdi M. Shand N. So April 2015 ASCII HTML 29

This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.

 draft-ietf-rtgwg-remote-lfa-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC7490 RFC7491 A PCE-Based Architecture for Application-Based Network Operations D. King A. Farrel March 2015 ASCII HTML 71 Software-Defined Networking (SDN) Path Computation Element (PCE) Network management Network programming

Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to-point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations (ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements.

This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications.

 draft-farrkingel-pce-abno-architecture-16 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7491 RFC7492 Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines M. Bhatia D. Zhang M. Jethanandani March 2015 ASCII HTML 9 BFD KARP replay attacks cryptographic authentication security DoS attacks

This document analyzes the Bidirectional Forwarding Detection (BFD) protocol according to the guidelines set forth in Section 4.2 of RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines".

 draft-ietf-karp-bfd-analysis-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7492 RFC7493 The I-JSON Message Format T. Bray Editor March 2015 ASCII HTML 6 JSON Internet JSON

I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.

 draft-ietf-json-i-json-06 PROPOSED STANDARD PROPOSED STANDARD IETF app json http://www.rfc-editor.org/errata_search.php?rfc=7493 10.17487/RFC7493 RFC7494 IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) C. Shao H. Deng R. Pazhyannur F. Bari R. Zhang S. Matsushima April 2015 ASCII HTML 13 CAPWAP MAC Profile Encryption IEEE 802.11

The Control and Provisioning of Wireless Access Points (CAPWAP) protocol binding for IEEE 802.11 defines two Medium Access Control (MAC) modes for IEEE 802.11 Wireless Transmission Points (WTPs): Split and Local MAC. In the Split MAC mode, the partitioning of encryption/decryption functions is not clearly defined. In the Split MAC mode description, IEEE 802.11 encryption is specified as located in either the Access Controller (AC) or the WTP, with no clear way for the AC to inform the WTP of where the encryption functionality should be located. This leads to interoperability issues, especially when the AC and WTP come from different vendors. To prevent interoperability issues, this specification defines an IEEE 802.11 MAC Profile message element in which each profile specifies an unambiguous division of encryption functionality between the WTP and AC.

 draft-ietf-opsawg-capwap-hybridmac-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC7494 RFC7495 Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF) A. Montville D. Black March 2015 ASCII HTML 10 IODEF Incident Reference Enumeration Format

The Incident Object Description Exchange Format (IODEF) is an XML data representation framework for sharing information about computer security incidents. In IODEF, the Reference class provides references to externally specified information such as a vulnerability, Intrusion Detection System (IDS) alert, malware sample, advisory, or attack technique. In practice, these references are based on external enumeration specifications that define both the enumeration format and the specific enumeration values, but the IODEF Reference class (as specified in IODEF v1 in RFC 5070) does not indicate how to include both of these important pieces of information.

This document establishes a stand-alone data format to include both the external specification and specific enumeration identification value, and establishes an IANA registry to manage external enumeration specifications. While this document does not update IODEF v1, this enumeration reference format is used in IODEF v2 and is applicable to other formats that support this class of enumeration references.

 draft-ietf-mile-enum-reference-format-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC7495 RFC7496 Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension M. Tuexen R. Seggelmann R. Stewart S. Loreto April 2015 ASCII HTML 11

This document defines two additional policies for the Partially Reliable Stream Control Transmission Protocol (PR-SCTP) extension. These policies allow limitation of the number of retransmissions and prioritization of user messages for more efficient usage of the send buffer.

 draft-ietf-tsvwg-sctp-prpolicies-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC7496 RFC7497 Rate Measurement Test Protocol Problem Statement and Requirements A. Morton April 2015 ASCII HTML 14 Internet access Asymmetric Packet Size

This memo presents a problem statement for access rate measurement for test protocols to measure IP Performance Metrics (IPPM). Key rate measurement test protocol aspects include the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size.

 draft-ietf-ippm-rate-problem-10 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7497 RFC7498 Problem Statement for Service Function Chaining P. Quinn Editor T. Nadeau Editor April 2015 ASCII HTML 13 service function chaining steering sfc

This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term "service function chaining" is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions.

The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy.

This document also identifies several key areas that the Service Function Chaining (SFC) working group will investigate to guide its architectural and protocol work and associated documents.

 draft-ietf-sfc-problem-statement-13 INFORMATIONAL INFORMATIONAL IETF rtg sfc http://www.rfc-editor.org/errata_search.php?rfc=7498 10.17487/RFC7498 RFC7499 Support of Fragmentation of RADIUS Packets A. Perez-Mendez Editor R. Marin-Lopez F. Pereniguez-Garcia G. Lopez-Millan D. Lopez A. DeKok April 2015 ASCII HTML 38 RADIUS attribute extension fragmentation chunk

The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 bytes. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge packets. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and they are designed to be invisible to proxies and "fail-safe" to legacy RADIUS Clients and Servers.

 draft-ietf-radext-radius-fragmentation-12 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC7499 RFC7500 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries R. Housley Editor O. Kolkman Editor April 2015 ASCII HTML 7

This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.

 draft-iab-iana-principles-05 RFC8720 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7500 RFC7501 Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration C. Davids V. Gurbani S. Poretsky April 2015 ASCII HTML 20

This document provides a terminology for benchmarking the Session Initiation Protocol (SIP) performance of devices. Methodology related to benchmarking SIP devices is described in the companion methodology document (RFC 7502). Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session Border Controllers. The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages. Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements. A standard terminology and methodology will ensure that benchmarks have consistent definitions and were obtained following the same procedures.

 draft-ietf-bmwg-sip-bench-term-12 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7501 RFC7502 Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration C. Davids V. Gurbani S. Poretsky April 2015 ASCII HTML 21

This document provides a methodology for benchmarking the Session Initiation Protocol (SIP) performance of devices. Terminology related to benchmarking SIP devices is described in the companion terminology document (RFC 7501). Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session Border Controllers. The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages. Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements.

 draft-ietf-bmwg-sip-bench-meth-12 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7502 RFC7503 OSPFv3 Autoconfiguration A. Lindem J. Arkko April 2015 ASCII HTML 15

OSPFv3 is a candidate for deployments in environments where autoconfiguration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. This document updates RFC 5340 by relaxing the HelloInterval/ RouterDeadInterval checking during OSPFv3 adjacency formation and adding hysteresis to the update of self-originated Link State Advertisements (LSAs).

 draft-ietf-ospf-ospfv3-autoconfig-15 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7503 RFC7504 SMTP 521 and 556 Reply Codes J. Klensin June 2015 ASCII HTML 7 Reply code Email Server No Mail

This memo defines two Simple Mail Transfer Protocol (SMTP) reply codes, 521 and 556. The 521 code was originally described in an Experimental RFC in 1995 and is in wide use, but has not previously been formally incorporated into SMTP. The 556 code was created to support the new tests and actions specified in RFC 7505. These codes are used to indicate that an Internet host does not accept incoming mail at all. This specification is not applicable when the host sometimes accepts mail but may reject particular messages, or even all messages, under specific circumstances.

 draft-klensin-smtp-521code-07 RFC1846 RFC5321 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7504 RFC7505 A "Null MX" No Service Resource Record for Domains That Accept No Mail J. Levine M. Delany June 2015 ASCII HTML 6 DNS e-mail

Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies.

 draft-ietf-appsawg-nullmx-10 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg 10.17487/RFC7505 RFC7506 IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM) K. Raza N. Akiya C. Pignataro April 2015 ASCII HTML 6 IPv6 LSP Ping MPLS OAM

RFC 4379 defines the MPLS Label Switched Path (LSP) Ping/Traceroute mechanism in which the Router Alert Option (RAO) MUST be set in the IP header of the MPLS Echo Request messages and may conditionally be set in the IP header of the MPLS Echo Reply messages depending on the Reply Mode used. While a generic "Router shall examine packet" Option Value is used for the IPv4 RAO, there is no generic RAO value defined for IPv6 that can be used. This document allocates a new, generic IPv6 RAO value that can be used by MPLS Operations, Administration, and Maintenance (OAM) tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS in IPv6 environments. Consequently, it updates RFC 4379.

The initial motivation to request an IPv6 RAO value for MPLS OAM comes from the MPLS LSP Ping/Traceroute. However, this value is applicable to all MPLS OAM and not limited to MPLS LSP Ping/ Traceroute.

 draft-ietf-mpls-oam-ipv6-rao-03 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7506 RFC7507 TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks B. Moeller A. Langley April 2015 ASCII HTML 8

This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. It updates RFCs 2246, 4346, 4347, 5246, and 6347. Server update considerations are included.

 draft-ietf-tls-downgrade-scsv-05 RFC8996 RFC2246 RFC4346 RFC4347 RFC5246 RFC6347 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7507 RFC7508 Securing Header Fields with S/MIME L. Cailleux C. Bonatti April 2015 ASCII HTML 19 secure headers

This document describes how the S/MIME protocol can be extended in order to secure message header fields defined in RFC 5322. This technology provides security services such as data integrity, non-repudiation, and confidentiality. This extension is referred to as 'Secure Headers'.

 draft-cailleux-secure-headers-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7508 10.17487/RFC7508 RFC7509 RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics R. Huang V. Singh May 2015 ASCII HTML 11

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows reporting of a post-repair loss count metric for a range of RTP applications. In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count when needed, so that the RTP sender or a third-party entity is able to evaluate the effectiveness of the repair methods used by the system.

 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7509 RFC7510 Encapsulating MPLS in UDP X. Xu N. Sheth L. Yong R. Callon D. Black April 2015 ASCII HTML 19 MPLS UDP Tunnel Checksum encapsulation multipath ECMP

This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost Multipath) or link aggregation. The MPLS- in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6.

 draft-ietf-mpls-in-udp-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7510 10.17487/RFC7510 RFC7511 Scenic Routing for IPv6 M. Wilhelm April 1 2015 ASCII HTML 8 green it

This document specifies a new routing scheme for the current version of the Internet Protocol version 6 (IPv6) in the spirit of "Green IT", whereby packets will be routed to get as much fresh-air time as possible.

 draft-scenig-routing INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7511 10.17487/RFC7511 RFC7512 The PKCS #11 URI Scheme J. Pechanec D. Moffat April 2015 ASCII HTML 20 PKCS11 PKCS-11 PKCS#11,

This memo specifies a PKCS #11 Uniform Resource Identifier (URI) Scheme for identifying PKCS #11 objects stored in PKCS #11 tokens and also for identifying PKCS #11 tokens, slots, or libraries. The URI scheme is based on how PKCS #11 objects, tokens, slots, and libraries are identified in "PKCS #11 v2.20: Cryptographic Token Interface Standard".

 draft-pechanec-pkcs11uri-21 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7512 10.17487/RFC7512 RFC7513 Source Address Validation Improvement (SAVI) Solution for DHCP J. Bi J. Wu G. Yao F. Baker May 2015 ASCII HTML 54 SAVI-DHCP

This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source Address Validation Improvement (SAVI) device. The bindings set up by this procedure are used to filter packets with forged source IP addresses. This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation.

 draft-ietf-savi-dhcp-34 PROPOSED STANDARD PROPOSED STANDARD IETF int savi 10.17487/RFC7513 RFC7514 Really Explicit Congestion Notification (RECN) M. Luckie April 1 2015 ASCII HTML 5

This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals provided by packet loss and Explicit Congestion Notification (ECN).

 draft-luckie-recn EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7514 RFC7515 JSON Web Signature (JWS) M. Jones J. Bradley N. Sakimura May 2015 ASCII HTML 59 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.

 draft-ietf-jose-json-web-signature-41 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose http://www.rfc-editor.org/errata_search.php?rfc=7515 10.17487/RFC7515 RFC7516 JSON Web Encryption (JWE) M. Jones J. Hildebrand May 2015 ASCII HTML 51 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.

 draft-ietf-jose-json-web-encryption-40 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose http://www.rfc-editor.org/errata_search.php?rfc=7516 10.17487/RFC7516 RFC7517 JSON Web Key (JWK) M. Jones May 2015 ASCII HTML 40 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.

 draft-ietf-jose-json-web-key-41 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose http://www.rfc-editor.org/errata_search.php?rfc=7517 10.17487/RFC7517 RFC7518 JSON Web Algorithms (JWA) M. Jones May 2015 ASCII HTML 69

This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.

 draft-ietf-jose-json-web-algorithms-40 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose http://www.rfc-editor.org/errata_search.php?rfc=7518 10.17487/RFC7518 RFC7519 JSON Web Token (JWT) M. Jones J. Bradley N. Sakimura May 2015 ASCII HTML 30 Assertion Claim Security Token JavaScript Object Notation JSON JSON Web Token JWT JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.

 draft-ietf-oauth-json-web-token-32 RFC7797 RFC8725 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=7519 10.17487/RFC7519 RFC7520 Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) M. Miller May 2015 ASCII HTML 120 JSON Object Signing and Encryption JOSE JavaScript Object Notation JSON JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA Cookbook

This document contains a set of examples using JSON Object Signing and Encryption (JOSE) technology to protect data. These examples present a representative sampling of JSON Web Key (JWK) objects as well as various JSON Web Signature (JWS) and JSON Web Encryption (JWE) results given similar inputs.

 draft-ietf-jose-cookbook-08 INFORMATIONAL INFORMATIONAL IETF sec jose http://www.rfc-editor.org/errata_search.php?rfc=7520 10.17487/RFC7520 RFC7521 Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants B. Campbell C. Mortimore M. Jones Y. Goland May 2015 ASCII HTML 20 OAuth SAML JWT Assertion

This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified.

The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms.

Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations.

 draft-ietf-oauth-assertions-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7521 RFC7522 Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants B. Campbell C. Mortimore M. Jones May 2015 ASCII HTML 15 OAuth SAML Assertion

This specification defines the use of a Security Assertion Markup Language (SAML) 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for client authentication.

 draft-ietf-oauth-saml2-bearer-23 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7522 RFC7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants M. Jones B. Campbell C. Mortimore May 2015 ASCII HTML 12 OAuth JWT Assertion Token Security Token

This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication.

 draft-ietf-oauth-jwt-bearer-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7523 RFC7524 Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) Y. Rekhter E. Rosen R. Aggarwal T. Morin I. Grosclaude N. Leymann S. Saad May 2015 ASCII HTML 42

This document describes procedures for building inter-area point-to-multipoint (P2MP) segmented service label switched paths (LSPs) by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and Label Distribution Protocol (LDP). Within each IGP area, the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP multipoint LDP (mLDP). If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS.

 draft-ietf-mpls-seamless-mcast-17 RFC8534 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7524 RFC7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Y. Sheffer R. Holz P. Saint-Andre May 2015 ASCII HTML 27 Transport Layer Security TLS DTLS Secure Sockets Layer SSL

Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.

 draft-ietf-uta-tls-bcp-11 RFC9325 RFC8996 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app uta http://www.rfc-editor.org/errata_search.php?rfc=7525 10.17487/RFC7525 RFC7526 Deprecating the Anycast Prefix for 6to4 Relay Routers O. Troan B. Carpenter Editor May 2015 ASCII HTML 10

Experience with the 6to4 transition mechanism defined in RFC 3056 ("Connection of IPv6 Domains via IPv4 Clouds") has shown that the mechanism is unsuitable for widespread deployment and use in the Internet when used in its anycast mode. Therefore, this document requests that RFC 3068 ("An Anycast Prefix for 6to4 Relay Routers") and RFC 6732 ("6to4 Provider Managed Tunnels") be made obsolete and moved to Historic status. It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. This complements the guidelines in RFC 6343.

 draft-ietf-v6ops-6to4-to-historic-11 RFC3068 RFC6732 BCP0196 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC7526 RFC7527 Enhanced Duplicate Address Detection R. Asati H. Singh W. Beebee C. Pignataro E. Dart W. George April 2015 ASCII HTML 11 Automated DAD loopback detection

IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are discussed in Appendix A of RFC 4862. That specification mentions a hardware-assisted mechanism to detect looped back DAD messages. If hardware cannot suppress looped back DAD messages, a software solution is required. Several service provider communities have expressed a need for automated detection of looped back Neighbor Discovery (ND) messages used by DAD. This document includes mitigation techniques and outlines the Enhanced DAD algorithm to automate the detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks, this document automates resolving a specific duplicate address conflict. This document updates RFCs 4429, 4861, and 4862.

 draft-ietf-6man-enhanced-dad-15 RFC4429 RFC4861 RFC4862 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7527 RFC7528 A Uniform Resource Name (URN) Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association P. Higgs J. Piesing April 2015 ASCII HTML 7

This document describes a Uniform Resource Name (URN) namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association for naming persistent resources defined within HbbTV specifications. Example resources include technical documents and specifications, Extensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by HbbTV.

 draft-higgs-hbbtv-urn-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7528 RFC7529 Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) C. Daboo G. Yakushev May 2015 ASCII HTML 21 calendaring iCalendar iTIP CalDAV

This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC 5545) to support use of non-Gregorian recurrence rules. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers and clients can be extended to support these new recurrence rules.

 draft-ietf-calext-rscale-04 RFC5545 RFC6321 RFC7265 PROPOSED STANDARD PROPOSED STANDARD IETF app calext 10.17487/RFC7529 RFC7530 Network File System (NFS) Version 4 Protocol T. Haynes Editor D. Noveck Editor March 2015 ASCII HTML 323

The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.

This document, together with the companion External Data Representation (XDR) description document, RFC 7531, obsoletes RFC 3530 as the definition of the NFS version 4 protocol.

 draft-ietf-nfsv4-rfc3530bis-35 RFC3530 RFC7931 RFC8587 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=7530 10.17487/RFC7530 RFC7531 Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description T. Haynes Editor D. Noveck Editor March 2015 ASCII HTML 39

The Network File System (NFS) version 4 protocol is a distributed file system protocol that owes its heritage to NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.

RFC 7530 formally obsoletes RFC 3530. This document, together with RFC 7530, replaces RFC 3530 as the definition of the NFS version 4 protocol.

 draft-ietf-nfsv4-rfc3530bis-dot-x-24 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7531 RFC7532 Namespace Database (NSDB) Protocol for Federated File Systems J. Lentini R. Tewari C. Lever Editor March 2015 ASCII HTML 65 Federated File Systems

This document describes a file system federation protocol that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the file systems physically hosted on and exported by the constituent fileservers.

 draft-ietf-nfsv4-federated-fs-protocol-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7532 RFC7533 Administration Protocol for Federated File Systems J. Lentini R. Tewari C. Lever Editor March 2015 ASCII HTML 37 Federated File Systems

This document describes the administration protocol for a federated file system (FedFS) that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the file systems physically hosted on and exported by the constituent fileservers.

 draft-ietf-nfsv4-federated-fs-admin-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7533 RFC7534 AS112 Nameserver Operations J. Abley W. Sotomayor May 2015 ASCII HTML 24 AS112 DNS reverse DNS anycast

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.

Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.

It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the corresponding authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.

This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation.

This document obsoletes RFC 6304.

 draft-ietf-dnsop-rfc6304bis-06 RFC6304 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7534 RFC7535 AS112 Redirection Using DNAME J. Abley B. Dickson W. Kumari G. Michaelson May 2015 ASCII HTML 16 DNS root server

AS112 provides a mechanism for handling reverse lookups on IP addresses that are not unique (e.g., RFC 1918 addresses). This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily, using DNAME resource records.

This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure.

 draft-ietf-dnsop-as112-dname-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7535 RFC7536 Large-Scale Broadband Measurement Use Cases M. Linsner P. Eardley T. Burbridge F. Sorensen May 2015 ASCII HTML 17 lmap

Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well as for public policy. Understanding the various scenarios and users of measuring broadband performance is essential to development of the Large-scale Measurement of Broadband Performance (LMAP) framework, information model, and protocol. This document details two use cases that can assist in developing that framework. The details of the measurement metrics themselves are beyond the scope of this document.

 draft-ietf-lmap-use-cases-06 INFORMATIONAL INFORMATIONAL IETF ops lmap 10.17487/RFC7536 RFC7537 IANA Registries for LSP Ping Code Points B. Decraene N. Akiya C. Pignataro L. Andersson S. Aldrin May 2015 ASCII HTML 7 MPLS OAM lsp ping LSP-Ping

RFCs 4379 and 6424 created name spaces for Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping. However, those RFCs did not create the corresponding IANA registries for Downstream Mapping object Flags (DS Flags), Multipath Types, Pad TLVs, and Interface and Label Stack Address Types.

There is now a need to make further code point allocations from these name spaces. This document updates RFCs 4379 and 6424 in that it creates IANA registries for that purpose.

 draft-ietf-mpls-lsp-ping-registry-03 RFC8029 RFC4379 RFC6424 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7537 RFC7538 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) J. Reschke April 2015 ASCII HTML 6 HTTP redirect status code

This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).

 draft-ietf-httpbis-rfc7238bis-03 RFC7238 RFC9110 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis 10.17487/RFC7538 RFC7539 ChaCha20 and Poly1305 for IETF Protocols Y. Nir A. Langley May 2015 ASCII HTML 45 AEAD

This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.

This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG).

 draft-irtf-cfrg-chacha20-poly1305-10 RFC8439 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=7539 10.17487/RFC7539 RFC7540 Hypertext Transfer Protocol Version 2 (HTTP/2) M. Belshe R. Peon M. Thomson Editor May 2015 ASCII HTML 96 HTTP SPDY Web

This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.

This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.

 draft-ietf-httpbis-http2-17 RFC9113 RFC8740 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7540 10.17487/RFC7540 RFC7541 HPACK: Header Compression for HTTP/2 R. Peon H. Ruellan May 2015 ASCII HTML 55 HTTP Header

This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.

 draft-ietf-httpbis-header-compression-12 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7541 10.17487/RFC7541 RFC7542 The Network Access Identifier A. DeKok May 2015 ASCII HTML 30

In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international character sets and makes a number of other corrections to RFC 4282.

 draft-ietf-radext-nai-15 RFC4282 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=7542 10.17487/RFC7542 RFC7543 Covering Prefixes Outbound Route Filter for BGP-4 H. Jeng L. Jalil R. Bonica K. Patel L. Yong May 2015 ASCII HTML 21 ORF VPN

This document defines a new Outbound Route Filter (ORF) type, called the Covering Prefixes ORF (CP-ORF). CP-ORF is applicable in Virtual Hub-and-Spoke VPNs. It also is applicable in BGP/MPLS Ethernet VPN (EVPN) networks.

 draft-ietf-bess-orf-covering-prefixes-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess http://www.rfc-editor.org/errata_search.php?rfc=7543 10.17487/RFC7543 RFC7544 Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP) M. Mohali August 2015 ASCII HTML 30 Diversion History-Info

Although the SIP History-Info header field described in RFC 7044 is the solution adopted in IETF, the non-standard Diversion header field described, as Historic, in RFC 5806 is nevertheless already implemented and used for conveying call-diversion-related information in Session Initiation Protocol (SIP) signaling.

RFC 7044 obsoletes the original RFC 4244 and redefines the History-Info header field for capturing the history information in requests.

Since the Diversion header field is used in existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This document describes a recommended interworking guideline between the Diversion header field and the History-Info header field to handle call diversion information. This work is intended to enable the migration from non-standard implementations toward IETF specification-based implementations.

This document obsoletes RFC 6044, which describes the interworking between the Diversion header field defined in RFC 5806 and the obsoleted History-Info header field defined on RFC 4244.

 draft-mohali-rfc6044bis-02 RFC6044 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7544 10.17487/RFC7544 RFC7545 Protocol to Access White-Space (PAWS) Databases V. Chen Editor S. Das L. Zhu J. Malyar P. McCann May 2015 ASCII HTML 90 dynamic spectrum radio spectrum wireless spectrum spectrum spectrum database TV white space TVWS TVBD white space device WSD

Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "white space". Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization.

One approach to managing spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White-Space (PAWS) Databases".

 draft-ietf-paws-protocol-20 PROPOSED STANDARD PROPOSED STANDARD IETF app paws 10.17487/RFC7545 RFC7546 Structure of the Generic Security Service (GSS) Negotiation Loop B. Kaduk May 2015 ASCII HTML 21 GSS-API security authentication

This document specifies the generic structure of the negotiation loop to establish a Generic Security Service (GSS) security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application-specific behavior must be specified.

 draft-ietf-kitten-gss-loop-05 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC7546 RFC7547 Management of Networks with Constrained Devices: Problem Statement and Requirements M. Ersue Editor D. Romascanu J. Schoenwaelder U. Herberg May 2015 ASCII HTML 44 Constrained Management IoT M2M

This document provides a problem statement, deployment and management topology options, as well as requirements addressing the different use cases of the management of networks where constrained devices are involved.

 draft-ietf-opsawg-coman-probstate-reqs-05 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7547 RFC7548 Management of Networks with Constrained Devices: Use Cases M. Ersue Editor D. Romascanu J. Schoenwaelder A. Sehgal May 2015 ASCII HTML 26 Constrained Management IoT M2M

This document discusses use cases concerning the management of networks in which constrained devices are involved. A problem statement, deployment options, and the requirements on the networks with constrained devices can be found in the companion document on "Management of Networks with Constrained Devices: Problem Statement and Requirements" (RFC 7547).

 draft-ietf-opsawg-coman-use-cases-05 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7548 RFC7549 3GPP SIP URI Inter-Operator Traffic Leg Parameter C. Holmberg J. Holm R. Jesske M. Dolly May 2015 ASCII HTML 17 3GPP IMS NNI IOTL CSCF RAVEL TRF operator transit

In 3GPP networks, the signaling path between a calling user and a called user can be partitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs, e.g., in case a Back-to-Back User Agent (B2BUA) that modifies the SIP dialog identifier is located within the traffic leg.

This document defines a new SIP URI parameter, 'iotl' (an abbreviation for Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs).

 draft-holmberg-dispatch-iotl-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7549 RFC7550 Issues and Recommendations with Multiple Stateful DHCPv6 Options O. Troan B. Volz M. Siodelski May 2015 ASCII HTML 24 CPE CER CE Customer Edge Router Prefix Delegation IPv6 Address Option Session State Machine Advertise Time Timer T1 T2 Renew Rebind Confirm Decline Provision

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specification defined two stateful options, IA_NA and IA_TA, but did not anticipate the development of additional stateful options. DHCPv6 Prefix Delegation added the IA_PD option, which is stateful. Applications that use IA_NA and IA_PD together have revealed issues that need to be addressed. This document updates RFCs 3315 and 3633 to address these issues.

 draft-ietf-dhc-dhcpv6-stateful-issues-12 RFC8415 RFC3315 RFC3633 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7550 RFC7551 RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs) F. Zhang Editor R. Jing R. Gandhi Editor May 2015 ASCII HTML 20

This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case.

 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07 RFC8537 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC7551 RFC7552 Updates to LDP for IPv6 R. Asati C. Pignataro K. Raza V. Manral R. Papneja June 2015 ASCII HTML 24 Label Distribution Protocol

The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4 or IPv6 networks, or both. This document corrects and clarifies the LDP behavior when an IPv6 network is used (with or without IPv4). This document updates RFCs 5036 and 6720.

 draft-ietf-mpls-ldp-ipv6-17 RFC5036 RFC6720 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7552 RFC7553 The Uniform Resource Identifier (URI) DNS Resource Record P. Faltstrom O. Kolkman June 2015 ASCII HTML 14 Operations DNS applications

This document describes the already registered DNS resource record (RR) type, called the Uniform Resource Identifier (URI) RR, that is used for publishing mappings from hostnames to URIs.

 draft-faltstrom-uri-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7553 RFC7554 Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement T. Watteyne Editor M. Palattella L. Grieco May 2015 ASCII HTML 23 6TiSCH

This document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Access Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs). The set of goals enumerated in this document form an initial set only.

 draft-ietf-6tisch-tsch-06 INFORMATIONAL INFORMATIONAL IETF int 6tisch http://www.rfc-editor.org/errata_search.php?rfc=7554 10.17487/RFC7554 RFC7555 Proxy MPLS Echo Request G. Swallow V. Lim S. Aldrin June 2015 ASCII HTML 28

This document defines a means of remotely initiating Multiprotocol Label Switched Protocol (MPLS) Pings on Label Switched Paths. An MPLS Proxy Ping Request is sent to any Label Switching Router along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable tracing from leaf to leaf (or root).

 draft-ietf-mpls-proxy-lsp-ping-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7555 10.17487/RFC7555 RFC7556 Multiple Provisioning Domain Architecture D. Anipko Editor June 2015 ASCII HTML 25

This document is a product of the work of the Multiple Interfaces Architecture Design team. It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information. PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources. PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.

 draft-ietf-mif-mpvd-arch-11 INFORMATIONAL INFORMATIONAL IETF int mif http://www.rfc-editor.org/errata_search.php?rfc=7556 10.17487/RFC7556 RFC7557 Extension Mechanism for the Babel Routing Protocol J. Chroboczek May 2015 ASCII HTML 11 Babel routing extension TLV sub-TLV

This document defines the encoding of extensions to the Babel routing protocol, as specified in RFC 6126.

 draft-chroboczek-babel-extension-mechanism-04 RFC8966 RFC6126 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7557 RFC7558 Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions K. Lynn S. Cheshire M. Blanchet D. Migault July 2015 ASCII HTML 14

DNS-based Service Discovery (DNS-SD) over Multicast DNS (mDNS) is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements for scalable DNS-SD.

 draft-ietf-dnssd-requirements-06 INFORMATIONAL INFORMATIONAL IETF int dnssd 10.17487/RFC7558 RFC7559 Packet-Loss Resiliency for Router Solicitations S. Krishnan D. Anipko D. Thaler May 2015 ASCII HTML 6

When an interface on a host is initialized, the host transmits Router Solicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received. In certain scenarios, these Router Solicitations transmitted by the host might be lost. This document specifies a mechanism for hosts to cope with the loss of the initial Router Solicitations.

 draft-ietf-6man-resilient-rs-06 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7559 RFC7560 Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback M. Kuehlewind Editor R. Scheffenegger B. Briscoe August 2015 ASCII HTML 17 congestion control TCP

Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets, instead of dropping them, to indicate congestion to the endpoints. An ECN-capable receiver will feed this information back to the sender. ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-Trip Time (RTT). In contrast, ECN for other transport protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN feedback. Recent new TCP mechanisms (like Congestion Exposure (ConEx) or Data Center TCP (DCTCP)) need more accurate ECN feedback in the case where more than one marking is received in one RTT. This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback.

 draft-ietf-tcpm-accecn-reqs-08 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC7560 RFC7561 Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN J. Kaippallimalil R. Pazhyannur P. Yegani June 2015 ASCII HTML 23 PMIPv6 Wi-Fi QoS

This document provides guidelines for achieving end-to-end Quality of Service (QoS) in a Proxy Mobile IPv6 (PMIPv6) domain where the access network is based on IEEE 802.11. RFC 7222 describes QoS negotiation between a Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) in a PMIPv6 mobility domain. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the MAG and LMA. IEEE 802.11 and Wi-Fi Multimedia - Admission Control (WMM-AC) describe methods for QoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) and an Access Point. This document provides a mapping between the above two sets of QoS procedures and the associated QoS parameters. This document is intended to be used as a companion document to RFC 7222 to enable implementation of end-to-end QoS.

 draft-ietf-netext-pmip-qos-wifi-08 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC7561 RFC7562 Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates D. Thakore July 2015 ASCII HTML 15 Transport Layer Security TLS SupplementalData DTCP

This document specifies the use of Digital Transmission Content Protection (DTCP) certificates as an authorization data type in the authorization extension for the Transport Layer Security (TLS) protocol. This is in accordance with the guidelines for authorization extensions as specified in RFC 5878. As with other TLS extensions, this authorization data can be included in the client and server hello messages to confirm that both parties support the desired authorization data types. If supported by both the client and the server, DTCP certificates are exchanged in the supplemental data TLS handshake message as specified in RFC 4680. This authorization data type extension is in support of devices containing DTCP certificates issued by the Digital Transmission Licensing Administrator (DTLA).

 draft-dthakore-tls-authz-08 RFC8996 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7562 RFC7563 Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option R. Pazhyannur S. Speicher S. Gundavelli J. Korhonen J. Kaippallimalil June 2015 ASCII HTML 12

The Access Network Identifier (ANI) mobility option was introduced in RFC 6757, "Access Network Identifier (ANI) Option for Proxy Mobile IPv6". This enables a Mobile Access Gateway (MAG) to convey identifiers like the network identifier, geolocation, and operator identifier. This specification extends the Access Network Identifier mobility option with sub-options to carry the civic location and the MAG group identifier. This specification also defines an ANI Update-Timer sub-option that determines when and how often the ANI option will be updated.

 draft-ietf-netext-ani-location-09 RFC6757 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7563 RFC7564 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols P. Saint-Andre M. Blanchet May 2015 ASCII HTML 40 internationalization i18n Stringprep

Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 3454.

 draft-ietf-precis-framework-23 RFC3454 RFC8264 PROPOSED STANDARD PROPOSED STANDARD IETF app precis http://www.rfc-editor.org/errata_search.php?rfc=7564 10.17487/RFC7564 RFC7565 The 'acct' URI Scheme P. Saint-Andre May 2015 ASCII HTML 8 Uniform Resource Identifier URI

This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account.

 draft-ietf-appsawg-acct-uri-07 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7565 RFC7566 Enumservice Registration for 'acct' URI L. Goix K. Li June 2015 ASCII HTML 8 Reverse Phone Lookup Social Network Web

This document registers an E.164 Number Mapping (ENUM) service for 'acct' URIs (Uniform Resource Identifiers).

 draft-goix-appsawg-enum-acct-uri-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7566 RFC7567 IETF Recommendations Regarding Active Queue Management F. Baker Editor G. Fairhurst Editor July 2015 ASCII HTML 31

This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.

Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309.

 draft-ietf-aqm-recommendation-11 RFC2309 BCP0197 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv aqm http://www.rfc-editor.org/errata_search.php?rfc=7567 10.17487/RFC7567 RFC7568 Deprecating Secure Sockets Layer Version 3.0 R. Barnes M. Thomson A. Pironti A. Langley June 2015 ASCII HTML 7 SSL TLS insecure diediedie

The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, Transport Layer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols.

This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3.

 draft-ietf-tls-sslv3-diediedie-03 RFC5246 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7568 10.17487/RFC7568 RFC7569 Registry Specification for Mandatory Access Control (MAC) Security Label Formats D. Quigley J. Lu T. Haynes July 2015 ASCII HTML 10 NFSv4

In the past, Mandatory Access Control (MAC) systems have used very rigid policies that were implemented in particular protocols and platforms. As MAC systems become more widely deployed, additional flexibility in mechanism and policy will be required. While traditional trusted systems implemented Multi-Level Security (MLS) and integrity models, modern systems have expanded to include such technologies as type enforcement. Due to the wide range of policies and mechanisms that need to be accommodated, it is unlikely that the use of a single security label format and model will be viable.

To allow multiple MAC mechanisms and label formats to co-exist in a network, this document creates a registry of label format specifications. This registry contains label format identifiers and provides for the association of each such identifier with a corresponding extensive document outlining the exact syntax and use of the particular label format.

 draft-ietf-nfsv4-lfs-registry-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7569 RFC7570 Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) C. Margaria Editor G. Martinelli S. Balls B. Wright July 2015 ASCII HTML 15 RSVP-TE GMPLS

RFC 5420 extends RSVP-TE to specify or record generic attributes that apply to the whole of the path of a Label Switched Path (LSP). This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) to allow them to specify or record generic attributes that apply to a given hop.

 draft-ietf-teas-lsp-attribute-ro-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC7570 RFC7571 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback J. Dong M. Chen Z. Li D. Ceccarelli July 2015 ASCII HTML 9 OAM

This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies that use Generalized MPLS (GMPLS) for the control plane.

 draft-ietf-teas-rsvp-te-li-lb-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC7571 RFC7572 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging P. Saint-Andre A. Houri J. Hildebrand June 2015 ASCII HTML 13 XMPP Jabber SIP SIMPLE IM Instant Message

This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).

 draft-ietf-stox-im-13 PROPOSED STANDARD PROPOSED STANDARD IETF art stox 10.17487/RFC7572 RFC7573 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions P. Saint-Andre S. Loreto June 2015 ASCII HTML 20 Text Chat Instant Messaging Session Initiation Protocol SIP Message Sessions Relay Protocol MSRP Extensible Messaging and Presence Protocol XMPP

This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).

 draft-ietf-stox-chat-11 PROPOSED STANDARD PROPOSED STANDARD IETF art stox 10.17487/RFC7573 RFC7574 Peer-to-Peer Streaming Peer Protocol (PPSPP) A. Bakker R. Petrocco V. Grishchenko July 2015 ASCII HTML 85 video on demand live streaming content integrity protection

The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for disseminating the same content to a group of interested parties in a streaming fashion. PPSPP supports streaming of both prerecorded (on- demand) and live audio/video content. It is based on the peer-to- peer paradigm, where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth. It has been designed to provide short time-till-playback for the end user and to prevent disruption of the streams by malicious peers. PPSPP has also been designed to be flexible and extensible. It can use different mechanisms to optimize peer uploading, prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables). It supports multiple methods for content integrity protection and chunk addressing. Designed as a generic protocol that can run on top of various transport protocols, it currently runs on top of UDP using Low Extra Delay Background Transport (LEDBAT) for congestion control.

 draft-ietf-ppsp-peer-protocol-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ppsp http://www.rfc-editor.org/errata_search.php?rfc=7574 10.17487/RFC7574 RFC7575 Autonomic Networking: Definitions and Design Goals M. Behringer M. Pritikin S. Bjarnason A. Clemm B. Carpenter S. Jiang L. Ciavaglia June 2015 ASCII HTML 16 self-management self-chop autonomic secure by default simplification

Autonomic systems were first described in 2001. The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection. This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems. It usually implies distribution across network elements.

This document defines common language and outlines design goals (and what are not design goals) for autonomic functions. A high-level reference model illustrates how functional elements in an Autonomic Network interact. This document is a product of the IRTF's Network Management Research Group.

 draft-irtf-nmrg-autonomic-network-definitions-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7575 RFC7576 General Gap Analysis for Autonomic Networking S. Jiang B. Carpenter M. Behringer June 2015 ASCII HTML 17

This document provides a problem statement and general gap analysis for an IP-based Autonomic Network that is mainly based on distributed network devices. The document provides background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralization and human administrators. Finally, the document outlines the general features that are missing from current network abilities and are needed in the ideal Autonomic Network concept.

This document is a product of the IRTF's Network Management Research Group.

 draft-irtf-nmrg-an-gap-analysis-06 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7576 RFC7577 Definition of Managed Objects for Battery Monitoring J. Quittek R. Winter T. Dietz July 2015 ASCII HTML 40 Energy Management Battery Status Battery MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices.

 draft-ietf-eman-battery-mib-20 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman 10.17487/RFC7577 RFC7578 Returning Values from Forms: multipart/form-data L. Masinter July 2015 ASCII HTML 15 media-type multipurpose internet mail extensions

This specification defines the multipart/form-data media type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. This document obsoletes RFC 2388.

 draft-ietf-appsawg-multipart-form-data-11 RFC2388 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg http://www.rfc-editor.org/errata_search.php?rfc=7578 10.17487/RFC7578 RFC7579 General Network Element Constraint Encoding for GMPLS-Controlled Networks G. Bernstein Editor Y. Lee Editor D. Li W. Imajuku J. Han June 2015 ASCII HTML 28 WSON Optical Network Control Protocol-agnostic encoding

Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies. In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links.

This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses.

 draft-ietf-ccamp-general-constraint-encode-20 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7579 RFC7580 OSPF-TE Extensions for General Network Element Constraints F. Zhang Y. Lee J. Han G. Bernstein Y. Xu June 2015 ASCII HTML 12 WSON Optical Routing

Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies including packet switching (e.g., MPLS), time division (e.g., Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN)), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non- local label assignment, and label range limitations on links. This document describes Open Shortest Path First (OSPF) routing protocol extensions to support these kinds of constraints under the control of GMPLS.

 draft-ietf-ccamp-gmpls-general-constraints-ospf-te-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7580 RFC7581 Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks G. Bernstein Editor Y. Lee Editor D. Li W. Imajuku J. Han June 2015 ASCII HTML 37 Optical Networks GMPLS control plane Wavelength Assignment Optical LSP Optical Routing

A Wavelength Switched Optical Network (WSON) requires certain key information fields be made available to facilitate path computation and the establishment of Label Switched Paths (LSPs). The information model described in "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks" (RFC 7446) shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are specific to WSONs.

This document provides efficient, protocol-agnostic encodings for the WSON-specific information fields. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition, these encodings could be used by other mechanisms to convey this same information to a Path Computation Element (PCE).

 draft-ietf-ccamp-rwa-wson-encode-28 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7581 RFC7582 Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels E. Rosen IJ. Wijnands Y. Cai A. Boers July 2015 ASCII HTML 34

A set of prior RFCs specify procedures for supporting multicast in BGP/MPLS IP VPNs. These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels. The tunnels are advertised in certain BGP multicast auto-discovery routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel" attribute. Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs. This document updates RFCs 6513, 6514, and 6625 by specifying those procedures. In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels.

 draft-ietf-bess-mvpn-bidir-04 RFC6513 RFC6514 RFC6625 RFC8534 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7582 RFC7583 DNSSEC Key Rollover Timing Considerations S. Morris J. Ihren J. Dickinson W. Mekking October 2015 ASCII HTML 31

This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process.

 draft-ietf-dnsop-dnssec-key-timing-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7583 RFC7584 Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs) R. Ravindranath T. Reddy G. Salgueiro July 2015 ASCII HTML 14

Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) are often designed to be on the media path rather than just intercepting signaling. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. When acting on the media path, B2BUAs are likely to receive Session Traversal Utilities for NAT (STUN) packets as part of Interactive Connectivity Establishment (ICE) processing.

This document defines behavior for a B2BUA performing ICE processing. The goal of this document is to ensure that B2BUAs properly handle SIP messages that carry ICE semantics in Session Description Protocol (SDP) and STUN messages received as part of the ICE procedures for NAT and Firewall traversal of multimedia sessions.

 draft-ietf-straw-b2bua-stun-08 PROPOSED STANDARD PROPOSED STANDARD IETF art straw http://www.rfc-editor.org/errata_search.php?rfc=7584 10.17487/RFC7584 RFC7585 Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) S. Winter M. McCauley October 2015 ASCII HTML 32 RADIUS AAA Security Reliability DNS

This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS over Transport Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Security (RADIUS/DTLS).

 draft-ietf-radext-dynamic-discovery-15 EXPERIMENTAL EXPERIMENTAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=7585 10.17487/RFC7585 RFC7586 The Scalable Address Resolution Protocol (SARP) for Large Data Centers Y. Nachum L. Dunbar I. Yerushalmi T. Mizrahi June 2015 ASCII HTML 21 ARP data center proxy

This document introduces the Scalable Address Resolution Protocol (SARP), an architecture that uses proxy gateways to scale large data center networks. SARP is based on fast proxies that significantly reduce switches' Filtering Database (FDB) table sizes and reduce impact of ARP and Neighbor Discovery (ND) on network elements in an environment where hosts within one subnet (or VLAN) can spread over various locations. SARP is targeted for massive data centers with a significant number of Virtual Machines (VMs) that can move across various physical locations.

 draft-nachum-sarp-11 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7586 RFC7587 RTP Payload Format for the Opus Speech and Audio Codec J. Spittka K. Vos JM. Valin June 2015 ASCII HTML 18 audio codec

This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus-encoded speech and audio data necessary to integrate the codec in the most compatible way. It also provides an applicability statement for the use of Opus over RTP. Further, it describes media type registrations for the RTP payload format.

 draft-ietf-payload-rtp-opus-11 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC7587 RFC7588 A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem R. Bonica C. Pignataro J. Touch July 2015 ASCII HTML 12 GRE MTU Fragmentation

This memo describes how many vendors have solved the Generic Routing Encapsulation (GRE) fragmentation problem. The solution described herein is configurable. It is widely deployed on the Internet in its default configuration.

 draft-ietf-intarea-gre-mtu-05 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC7588 RFC7589 Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication M. Badra A. Luchuk J. Schoenwaelder June 2015 ASCII HTML 11 NETCONF TLS

The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange of NETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539.

 draft-ietf-netconf-rfc5539bis-10 RFC5539 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC7589 RFC7590 Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre T. Alkemade June 2015 ASCII HTML 9 Extensible Messaging and Presence Protocol XMPP Jabber Secure Sockets Layer SSL Transport Layer Security TLS instant messaging presence encryption authentication

This document provides recommendations for the use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP). This document updates RFC 6120.

 draft-ietf-uta-xmpp-07 RFC6120 PROPOSED STANDARD PROPOSED STANDARD IETF art uta 10.17487/RFC7590 RFC7591 OAuth 2.0 Dynamic Client Registration Protocol J. Richer Editor M. Jones J. Bradley M. Machulak P. Hunt July 2015 ASCII HTML 39 OpenID Connect Dynamic Client Registration OpenID Connect oidc openid user managed access uma Dynamic Registration Dynamic Client Registration

This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration.

 draft-ietf-oauth-dyn-reg-30 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7591 RFC7592 OAuth 2.0 Dynamic Client Registration Management Protocol J. Richer Editor M. Jones J. Bradley M. Machulak July 2015 ASCII HTML 18

This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods.

 draft-ietf-oauth-dyn-reg-management-15 EXPERIMENTAL EXPERIMENTAL IETF sec oauth 10.17487/RFC7592 RFC7593 The eduroam Architecture for Network Roaming K. Wierenga S. Winter T. Wolniewicz September 2015 ASCII HTML 37 Federated Authentication AAA RADIUS IEEE 802.1X roaming EAP eduroam

This document describes the architecture of the eduroam service for federated (wireless) network access in academia. The combination of IEEE 802.1X, the Extensible Authentication Protocol (EAP), and RADIUS that is used in eduroam provides a secure, scalable, and deployable service for roaming network access. The successful deployment of eduroam over the last decade in the educational sector may serve as an example for other sectors, hence this document. In particular, the initial architectural choices and selection of standards are described, along with the changes that were prompted by operational experience.

 draft-wierenga-ietf-eduroam-05 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7593 10.17487/RFC7593 RFC7594 A Framework for Large-Scale Measurement of Broadband Performance (LMAP) P. Eardley A. Morton M. Bagnulo T. Burbridge P. Aitken A. Akhter September 2015 ASCII HTML 55 Controller Collector Measurement Agent Metric Measurement Method Measurement Results Registry

Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. This document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (Large-Scale Measurement of Broadband Performance).

 draft-ietf-lmap-framework-14 INFORMATIONAL INFORMATIONAL IETF ops lmap 10.17487/RFC7594 RFC7595 Guidelines and Registration Procedures for URI Schemes D. Thaler Editor T. Hansen T. Hardie June 2015 ASCII HTML 19 URI scheme IRI Internationalized Resource Identifier Uniform Resource Identifier URI registration

This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395.

 draft-ietf-appsawg-uri-scheme-reg-06 RFC4395 RFC8615 BCP0035 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF art appsawg http://www.rfc-editor.org/errata_search.php?rfc=7595 10.17487/RFC7595 RFC7596 Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture Y. Cui Q. Sun M. Boucadair T. Tsou Y. Lee I. Farrer July 2015 ASCII HTML 22 DS-Lite address sharing address exhaustion aplusp A+P IPv4 service continuity IPv4 over IPv6 connectivity

Dual-Stack Lite (DS-Lite) (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called "Lightweight 4over6", which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs.

 draft-ietf-softwire-lw4over6-13 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC7596 RFC7597 Mapping of Address and Port with Encapsulation (MAP-E) O. Troan Editor W. Dec X. Li C. Bao S. Matsushima T. Murakami T. Taylor Editor July 2015 ASCII HTML 35

This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. It also describes a generic mechanism for mapping between IPv6 addresses and IPv4 addresses as well as transport-layer ports.

 draft-ietf-softwire-map-13 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC7597 RFC7598 DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients T. Mrugalski O. Troan I. Farrer S. Perreault W. Dec C. Bao L. Yeh X. Deng July 2015 ASCII HTML 18 MAP DHCPv6

This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address plus Port (A+P) for providing IPv4 connectivity across an IPv6 network.

 draft-ietf-softwire-map-dhcp-12 RFC8539 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=7598 10.17487/RFC7598 RFC7599 Mapping of Address and Port using Translation (MAP-T) X. Li C. Bao W. Dec Editor O. Troan S. Matsushima T. Murakami July 2015 ASCII HTML 27

This document specifies the solution architecture based on "Mapping of Address and Port" stateless IPv6-IPv4 Network Address Translation (NAT64) for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network.

 draft-ietf-softwire-map-t-08 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=7599 10.17487/RFC7599 RFC7600 IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd) R. Despres S. Jiang Editor R. Penno Y. Lee G. Chen M. Chen July 2015 ASCII HTML 45 Coexistence Transition Interworking Tunneling Stateless 4rd IPv4 IPv6 Mapping Global Addressing

This document specifies a stateless solution for service providers to progressively deploy IPv6-only network domains while still offering IPv4 service to customers. The solution's distinctive properties are that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal and that IPv4 fragmentation rules are fully preserved end to end. Each customer can be assigned one public IPv4 address, several public IPv4 addresses, or a shared address with a restricted port set.

 draft-ietf-softwire-4rd-10 EXPERIMENTAL EXPERIMENTAL IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=7600 10.17487/RFC7600 RFC7601 Message Header Field for Indicating Message Authentication Status M. Kucherawy August 2015 ASCII HTML 53 DKIM DomainKeys SenderID SPF ADSP ATPS VBR Authentication Reputation

This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.

 draft-ietf-appsawg-rfc7001bis-11 RFC7001 RFC7410 RFC8601 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg http://www.rfc-editor.org/errata_search.php?rfc=7601 10.17487/RFC7601 RFC7602 IS-IS Extended Sequence Number TLV U. Chunduri W. Lu A. Tian N. Shen July 2015 ASCII HTML 12

This document defines the Extended Sequence Number TLV to protect Intermediate System to Intermediate System (IS-IS) PDUs from replay attacks.

 draft-ietf-isis-extended-sequence-no-tlv-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7602 RFC7603 Energy Management (EMAN) Applicability Statement B. Schoening M. Chandramouli B. Nordman August 2015 ASCII HTML 28

The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN information model in a variety of scenarios with cases and target devices. These use cases are useful for identifying requirements for the framework and MIBs. Further, we describe the relationship of the EMAN framework to other relevant energy monitoring standards and architectures.

 draft-ietf-eman-applicability-statement-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman 10.17487/RFC7603 RFC7604 Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP) M. Westerlund T. Zeng September 2015 ASCII HTML 46 RTP Real-time Transport Protocol Real-time Firewall UDP

This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-Time Streaming Protocol (RTSP). Each technique includes a description of how it would be used, the security implications of using it, and any other deployment considerations it has. There are also discussions on how NAT traversal techniques relate to firewalls and how each technique can be applied in different use cases. These findings were used when selecting the NAT traversal for RTSP 2.0, which is specified in a separate document.

 draft-ietf-mmusic-rtsp-nat-evaluation-16 INFORMATIONAL INFORMATIONAL IETF art mmusic 10.17487/RFC7604 RFC7605 Recommendations on Using Assigned Transport Port Numbers J. Touch August 2015 ASCII HTML 24 tcp udp sctp dccp service iana

This document provides recommendations to designers of application and service protocols on how to use the transport protocol port number space and when to request a port assignment from IANA. It provides designer guidance to requesters or users of port numbers on how to interact with IANA using the processes defined in RFC 6335; thus, this document complements (but does not update) that document.

 draft-ietf-tsvwg-port-use-11 BCP0165 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=7605 10.17487/RFC7605 RFC7606 Revised Error Handling for BGP UPDATE Messages E. Chen Editor J. Scudder Editor P. Mohapatra K. Patel August 2015 ASCII HTML 19 BGP

According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes.

This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368.

 draft-ietf-idr-error-handling-19 RFC1997 RFC4271 RFC4360 RFC4456 RFC4760 RFC5543 RFC5701 RFC6368 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=7606 10.17487/RFC7606 RFC7607 Codification of AS 0 Processing W. Kumari R. Bush H. Schiller K. Patel August 2015 ASCII HTML 5 BGP AS 0 AS_PATH AS-PATH

This document updates RFC 4271 and proscribes the use of Autonomous System (AS) 0 in the Border Gateway Protocol (BGP) OPEN, AS_PATH, AS4_PATH, AGGREGATOR, and AS4_AGGREGATOR attributes in the BGP UPDATE message.

 draft-ietf-idr-as0-06 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=7607 10.17487/RFC7607 RFC7608 IPv6 Prefix Length Recommendation for Forwarding M. Boucadair A. Petrescu F. Baker July 2015 ASCII HTML 6 IPv6 Routing CIDR Classless Inter-Domain Routing IPv6 Addressing Architecture IPv6 Forwarding Information Base IPv6 Routing Information Base FIB RIB IPv6 Deployment

IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length.

 draft-ietf-v6ops-cidr-prefix-03 BCP0198 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC7608 RFC7609 IBM's Shared Memory Communications over RDMA (SMC-R) Protocol M. Fox C. Kassimis J. Stevens August 2015 ASCII HTML 143

This document describes IBM's Shared Memory Communications over RDMA (SMC-R) protocol. This protocol provides Remote Direct Memory Access (RDMA) communications to TCP endpoints in a manner that is transparent to socket applications. It further provides for dynamic discovery of partner RDMA capabilities and dynamic setup of RDMA connections, as well as transparent high availability and load balancing when redundant RDMA network paths are available. It maintains many of the traditional TCP/IP qualities of service such as filtering that enterprise users demand, as well as TCP socket semantics such as urgent data.

 draft-fox-tcpm-shared-memory-rdma-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7609 RFC7610 DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers F. Gont W. Liu G. Van de Velde August 2015 ASCII HTML 12

This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based on DHCPv6 packet filtering at the layer 2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'); hence, it is desirable that similar functionality be provided for IPv6 networks. This document specifies a Best Current Practice for the implementation of DHCPv6-Shield.

 draft-ietf-opsec-dhcpv6-shield-08 BCP0199 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsec 10.17487/RFC7610 RFC7611 BGP ACCEPT_OWN Community Attribute J. Uttaro P. Mohapatra D. Smith R. Raszuk J. Scudder August 2015 ASCII HTML 8 BGP VPN L3VPN Extranet Well-known Reserved

Under certain conditions, it is desirable for a Border Gateway Protocol (BGP) route reflector to be able to modify the Route Target (RT) list of a Virtual Private Network (VPN) route that the route reflector distributes, enabling the route reflector to control how a route originated within one VPN Routing and Forwarding table (VRF) is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same Provider Edge (PE) router as the VRF(s) that imports the route. However, due to the constraints of BGP, it does not work if the two are on the same PE. This document describes a modification to BGP allowing this technique to work when the VRFs are on the same PE and to be used in a standard manner throughout an autonomous system.

 draft-ietf-l3vpn-acceptown-community-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7611 RFC7612 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services P. Fleming I. McDonald June 2015 ASCII HTML 54

This document defines a schema, object classes, and attributes, for Printers and print services, for use with directories that support the Lightweight Directory Access Protocol (RFC 4510). This document is based on the Printer attributes listed in Appendix E of "Internet Printing Protocol/1.1: Model and Semantics" (RFC 2911). Additional Printer attributes are based on definitions in "Printer MIB v2" (RFC 3805), "PWG Command Set Format for IEEE 1284 Device ID v1.0" (PWG 5107.2), "IPP Job and Printer Extensions - Set 3 (JPS3)" (PWG 5100.13), and "IPP Everywhere" (PWG 5100.14).

This memo is an Independent Submission to the RFC Editor by the Internet Printing Protocol (IPP) Working Group of the IEEE-ISTO Printer Working Group (PWG), as part of their PWG "IPP Everywhere" (PWG 5100.14) project for secure mobile printing with vendor-neutral Client software.

This document obsoletes RFC 3712.

 draft-mcdonald-ldap-printer-schema-13 RFC3712 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7612 RFC7613 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords P. Saint-Andre A. Melnikov August 2015 ASCII HTML 27 Username Password Unicode Internationalization i18n Authentication SASLprep strings stringprep

This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC 3454, and this document obsoletes RFC 4013.

 draft-ietf-precis-saslprepbis-18 RFC4013 RFC8265 PROPOSED STANDARD PROPOSED STANDARD IETF art precis 10.17487/RFC7613 RFC7614 Explicit Subscriptions for the REFER Method R. Sparks August 2015 ASCII HTML 14 SIP SIP Events nosub explicitsub Refer-Events-At

The Session Initiation Protocol (SIP) REFER request, as defined by RFC 3515, triggers an implicit SIP-Specific Event Notification framework subscription. Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible and complicates avoiding SIP dialog sharing. This document defines extensions to REFER that remove the implicit subscription and, if desired, replace it with an explicit one.

 draft-ietf-sipcore-refer-explicit-subscription-03 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC7614 RFC7615 HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields J. Reschke September 2015 ASCII HTML 6 HTTP authentication

This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in Hypertext Transfer Protocol (HTTP) authentication schemes that need to return information once the client's authentication credentials have been accepted.

 draft-ietf-httpbis-auth-info-05 RFC2617 RFC9110 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC7615 RFC7616 HTTP Digest Access Authentication R. Shekh-Yusef Editor D. Ahrens S. Bremer September 2015 ASCII HTML 32 HTTP authentication scheme

The Hypertext Transfer Protocol (HTTP) provides a simple challenge- response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.

 draft-ietf-httpauth-digest-19 RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF sec httpauth http://www.rfc-editor.org/errata_search.php?rfc=7616 10.17487/RFC7616 RFC7617 The 'Basic' HTTP Authentication Scheme J. Reschke September 2015 ASCII HTML 15 HTTP authentication scheme basic authentication scheme

This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.

 draft-ietf-httpauth-basicauth-update-07 RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF sec httpauth 10.17487/RFC7617 RFC7618 Dynamic Allocation of Shared IPv4 Addresses Y. Cui Q. Sun I. Farrer Y. Lee Q. Sun M. Boucadair August 2015 ASCII HTML 15

This memo describes the dynamic allocation of shared IPv4 addresses to clients using DHCPv4. Address sharing allows a single IPv4 address to be allocated to multiple active clients simultaneously, with each client being differentiated by a unique set of transport- layer source port numbers. The necessary changes to existing DHCPv4 client and server behavior are described, and a new DHCPv4 option for provisioning clients with shared IPv4 addresses is included.

Due to the nature of IP address sharing, some limitations to its applicability are necessary. This memo describes these limitations and recommends suitable architectures and technologies where address sharing may be utilized.

 draft-ietf-dhc-dynamic-shared-v4allocation-09 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7618 RFC7619 The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) V. Smyslov P. Wouters August 2015 ASCII HTML 12 unauthenticated opportunistic security pervasive monitoring Peer Authorization Database PAD opportunistic encryption

This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for Internet Key Exchange Protocol version 2 (IKEv2). This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity.

 draft-ietf-ipsecme-ikev2-null-auth-07 RFC4301 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC7619 RFC7620 Scenarios with Host Identification Complications M. Boucadair Editor B. Chatras T. Reddy B. Williams B. Sarikaya August 2015 ASCII HTML 26 IP address sharing IPv4 service continuity host identifier de-multiplexing connections policy enforcement service delivery

This document describes a set of scenarios in which complications when identifying which policy to apply for a host are encountered. This problem is abstracted as "host identification". Describing these scenarios allows commonalities between scenarios to be identified, which is helpful during the solution design phase.

This document does not include any solution-specific discussions.

 draft-boucadair-intarea-host-identifier-scenarios-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7620 RFC7621 A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework A.B. Roach August 2015 ASCII HTML 4 session initiation protocol

Experience since the publication of the most recent SIP Events framework (in July 2012) has shown that there is room for interpretation around the use of Globally Routable User Agent URIs in that specification. This document clarifies the intended behavior.

This document updates RFC 6665.

 draft-ietf-sipcore-6665-clarification-00 RFC6665 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC7621 RFC7622 Extensible Messaging and Presence Protocol (XMPP): Address Format P. Saint-Andre September 2015 ASCII HTML 27 Extensible Messaging and Presence Protocol XMPP Jabber Messaging Instant Messaging Presence Internationalization i18n PRECIS

This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122.

 draft-ietf-xmpp-6122bis-24 RFC6122 PROPOSED STANDARD PROPOSED STANDARD IETF art xmpp http://www.rfc-editor.org/errata_search.php?rfc=7622 10.17487/RFC7622 RFC7623 Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN) A. Sajassi Editor S. Salam N. Bitar A. Isaac W. Henderickx September 2015 ASCII HTML 23

This document discusses how Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of BGP MAC Advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address, provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per-site policies, and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN.

 draft-ietf-l2vpn-pbb-evpn-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7623 RFC7624 Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement R. Barnes B. Schneier C. Jennings T. Hardie B. Trammell C. Huitema D. Borkmann August 2015 ASCII HTML 24 eavesdropping

Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks.

 draft-iab-privsec-confidentiality-threat-07 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7624 RFC7625 Architecture of an IP/MPLS Network with Hardened Pipes J. T. Hao P. Maheshwari R. Huang L. Andersson M. Chen August 2015 ASCII HTML 15

This document describes an IP/MPLS network that has an infrastructure that can be separated into two or more strata. For the implementation described in this document, the infrastructure has been separated into two strata: one for the "Hard Pipes", called the "Hard Pipe Stratum", and one for the normal IP/MPLS traffic, called the "Normal IP/MPLS Stratum".

This document introduces the concept of a Hard Pipe -- an MPLS Label Switched Path (LSP) or a pseudowire (PW) with a bandwidth that is guaranteed and can neither be exceeded nor infringed upon.

The Hard Pipe stratum does not use statistical multiplexing; for the LSPs and PWs set up within this stratum, the bandwidth is guaranteed end to end.

The document does not specify any new protocol or procedures. It does explain how the MPLS standards implementation has been deployed and operated to meet the requirements from operators that offer traditional Virtual Leased Line (VLL) services.

 draft-hao-mpls-ip-hard-pipe-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7625 RFC7626 DNS Privacy Considerations S. Bortzmeyer August 2015 ASCII HTML 17 Confidentiality Pervasive Surveillance Domain Name System

This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions.

 draft-ietf-dprive-problem-statement-06 RFC9076 INFORMATIONAL INFORMATIONAL IETF int dprive 10.17487/RFC7626 RFC7627 Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension K. Bhargavan Editor A. Delignat-Lavaud A. Pironti A. Langley M. Ray September 2015 ASCII HTML 15

The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.

 draft-ietf-tls-session-hash-06 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7627 RFC7628 A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth W. Mills T. Showalter H. Tschofenig August 2015 ASCII HTML 21

OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction or by allowing the third-party application to obtain access on its own behalf.

This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource server. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols.

Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password.

 draft-ietf-kitten-sasl-oauth-23 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC7628 RFC7629 Flow-Binding Support for Mobile IP S. Gundavelli Editor K. Leung G. Tsirtsis A. Petrescu August 2015 ASCII HTML 19 Multipath Flow Binding Hybrid Access Flow Mobility MIPv4-NEMO

This specification defines extensions to the Mobile IP protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of its network interfaces and to simultaneously establish multiple IP tunnels with its home agent. This essentially allows the mobile node to utilize all the available network interfaces and build a higher aggregated logical pipe with its home agent for its home address traffic. Furthermore, these extensions also allow the mobile node and the home agent to negotiate IP traffic flow policies for binding individual flows with the registered care-of addresses.

 draft-ietf-mip4-multiple-tunnel-support-13 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC7629 RFC7630 HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 J. Merkle Editor M. Lochter October 2015 ASCII HTML 14 Network Management SNMP USM HMAC SHA-2

This memo specifies new HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414.

 draft-ietf-opsawg-hmac-sha-2-usm-snmp-06 RFC7860 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=7630 10.17487/RFC7630 RFC7631 TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format C. Dearlove T. Clausen September 2015 ASCII HTML 15 MANET packet message address TLV

This document reorganizes the naming of already-allocated TLV (type- length-value) types and type extensions in the "Mobile Ad hoc NETwork (MANET) Parameters" registries defined by RFC 5444 to use names appropriately. It has no consequences in terms of any protocol implementation.

This document also updates the Expert Review guidelines in RFC 5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes to RFC 5444.

 draft-ietf-manet-tlv-naming-05 RFC5444 RFC7722 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7631 RFC7632 Endpoint Security Posture Assessment: Enterprise Use Cases D. Waltermire D. Harrington September 2015 ASCII HTML 23 security automation continuous monitoring endpoint posture assessment use case asset management configuration management vulnerability management content management

This memo documents a sampling of use cases for securely aggregating configuration and operational data and evaluating that data to determine an organization's security posture. From these operational use cases, we can derive common functional capabilities and requirements to guide development of vendor-neutral, interoperable standards for aggregating and evaluating data relevant to security posture.

 draft-ietf-sacm-use-cases-10 INFORMATIONAL INFORMATIONAL IETF sec sacm 10.17487/RFC7632 RFC7633 X.509v3 Transport Layer Security (TLS) Feature Extension P. Hallam-Baker October 2015 ASCII HTML 11 PKIX Transport Layer Security Cryptography Certificate

The purpose of the TLS feature extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol. In particular, the TLS feature extension may be used to mandate support for revocation checking features in the TLS protocol such as Online Certificate Status Protocol (OCSP) stapling. Informing clients that an OCSP status response will always be stapled permits an immediate failure in the case that the response is not stapled. This in turn prevents a denial-of-service attack that might otherwise be possible.

 draft-hallambaker-tlsfeature-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7633 10.17487/RFC7633 RFC7634 ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec Y. Nir August 2015 ASCII HTML 13 IKE IPsec AEAD ChaCha ChaCha20 Salsa

This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange Protocol version 2 (IKEv2) and for IPsec.

 draft-ietf-ipsecme-chacha20-poly1305-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=7634 10.17487/RFC7634 RFC7635 Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization T. Reddy P. Patil R. Ravindranath J. Uberti August 2015 ASCII HTML 24 OAuth 2.0 STUN TURN WebRTC Authentication and Authorization

This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised.

 draft-ietf-tram-turn-third-party-authz-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram http://www.rfc-editor.org/errata_search.php?rfc=7635 10.17487/RFC7635 RFC7636 Proof Key for Code Exchange by OAuth Public Clients N. Sakimura Editor J. Bradley N. Agarwal September 2015 ASCII HTML 20 smart phones apps XARA authorization custom scheme intent man-in-the-middle eavesdropping user agent swap spop pop openid connect pkce pixie

OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy").

 draft-ietf-oauth-spop-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=7636 10.17487/RFC7636 RFC7637 NVGRE: Network Virtualization Using Generic Routing Encapsulation P. Garg Editor Y. Wang Editor September 2015 ASCII HTML 17

This document describes the usage of the Generic Routing Encapsulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant data centers. Network Virtualization decouples virtual networks and addresses from physical network infrastructure, providing isolation and concurrency between multiple virtual networks on the same physical network infrastructure. This document also introduces a Network Virtualization framework to illustrate the use cases, but the focus is on specifying the data-plane aspect of NVGRE.

 draft-sridharan-virtualization-nvgre-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7637 RFC7638 JSON Web Key (JWK) Thumbprint M. Jones N. Sakimura September 2015 ASCII HTML 13 JavaScript Object Notation JSON JSON Web Key JWK ThumbprintOB Fingerprint Digest

This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint.

 draft-ietf-jose-jwk-thumbprint-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7638 RFC7639 The ALPN HTTP Header Field A. Hutton J. Uberti M. Thomson August 2015 ASCII HTML 7 HTTP CONNECT Firewall HTTP proxy

This specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field.

 draft-ietf-httpbis-tunnel-protocol-05 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC7639 RFC7640 Traffic Management Benchmarking B. Constantine R. Krishnan September 2015 ASCII HTML 51

This framework describes a practical methodology for benchmarking the traffic management capabilities of networking devices (i.e., policing, shaping, etc.). The goals are to provide a repeatable test method that objectively compares performance of the device's traffic management capabilities and to specify the means to benchmark traffic management with representative application traffic.

 draft-ietf-bmwg-traffic-management-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7640 RFC7641 Observing Resources in the Constrained Application Protocol (CoAP) K. Hartke September 2015 ASCII HTML 30 Smart Objects Internet of Things IoT REST

The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.

 draft-ietf-core-observe-16 RFC8323 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC7641 RFC7642 System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements K. LI Editor P. Hunt B. Khasnabish A. Nadalin Z. Zeltsan September 2015 ASCII HTML 19 SIM user scenarios SCIM use cases

This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes user scenarios, use cases, and requirements.

 draft-ietf-scim-use-cases-08 INFORMATIONAL INFORMATIONAL IETF art scim 10.17487/RFC7642 RFC7643 System for Cross-domain Identity Management: Core Schema P. Hunt Editor K. Grizzle E. Wahlstroem C. Mortimore September 2015 ASCII HTML 104 Identity Provisioning User Group

The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model as well as binding documents to provide patterns for exchanging this schema using HTTP.

This document provides a platform-neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers.

 draft-ietf-scim-core-schema-22 PROPOSED STANDARD PROPOSED STANDARD IETF art scim http://www.rfc-editor.org/errata_search.php?rfc=7643 10.17487/RFC7643 RFC7644 System for Cross-domain Identity Management: Protocol P. Hunt Editor K. Grizzle M. Ansari E. Wahlstroem C. Mortimore September 2015 ASCII HTML 89 SCIM

The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi-domain scenarios easier to support via a standardized service. Examples include, but are not limited to, enterprise-to-cloud service providers and inter-cloud scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document.

 draft-ietf-scim-api-19 PROPOSED STANDARD PROPOSED STANDARD IETF art scim http://www.rfc-editor.org/errata_search.php?rfc=7644 10.17487/RFC7644 RFC7645 The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis U. Chunduri A. Tian W. Lu September 2015 ASCII HTML 12

This document analyzes the current state of the Intermediate System to Intermediate System (IS-IS) protocol according to the requirements set forth in "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518) for both manual and automated key management protocols.

 draft-ietf-karp-isis-analysis-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7645 RFC7646 Definition and Use of DNSSEC Negative Trust Anchors P. Ebersman W. Kumari C. Griffiths J. Livingood R. Weber September 2015 ASCII HTML 16 NTA ISP Internet Service Provider DNS DNSSEC Negative Trust Anchors

DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes. This document defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains.

 draft-ietf-dnsop-negative-trust-anchors-13 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7646 RFC7647 Clarifications for the Use of REFER with RFC 6665 R. Sparks A.B. Roach September 2015 ASCII HTML 6

The SIP REFER method relies on the SIP-Specific Event Notification framework. That framework was revised by RFC 6665. This document highlights the implications of the requirement changes in RFC 6665, and updates the definition of the REFER method described in RFC 3515 to clarify and disambiguate the impact of those changes.

 draft-ietf-sipcore-refer-clarifications-04 RFC3515 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC7647 RFC7648 Port Control Protocol (PCP) Proxy Function S. Perreault M. Boucadair R. Penno D. Wing S. Cheshire September 2015 ASCII HTML 14 NAT firewall CGN AFTR NAT64 port forwarding pinholing port mapping external IP address discover port number running a server behind NAT NAT control NAT cascading DS-Lite incoming connection control outbound connection referral address referral ALG offload PCP client PCP server

This document specifies a new Port Control Protocol (PCP) functional element: the PCP proxy. The PCP proxy relays PCP requests received from PCP clients to upstream PCP server(s). A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that cannot be configured with the address of a PCP server located more than one hop away.

 draft-ietf-pcp-proxy-09 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7648 RFC7649 The Jabber Scribe Role at IETF Meetings P. Saint-Andre D. York September 2015 ASCII HTML 12 Jabber Scribe IETF Meetings

During IETF meetings, individual volunteers often help sessions run more smoothly by relaying information back and forth between the physical meeting room and an associated textual chatroom. Such volunteers are commonly called "Jabber scribes". This document summarizes experience with the Jabber scribe role and provides some suggestions for fulfilling the role at IETF meetings.

 draft-saintandre-jabber-scribe-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7649 RFC7650 A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD) J. Jimenez J. Lopez-Vega J. Maenpaa G. Camarillo September 2015 ASCII HTML 19 CoAP RELOAD

This document defines a Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD). The CoAP Usage provides the functionality to federate Wireless Sensor Networks (WSNs) in a peer-to-peer fashion. The CoAP Usage for RELOAD allows CoAP nodes to store resources in a RELOAD peer-to-peer overlay, provides a lookup service, and enables the use of RELOAD overlay as a cache for sensor data. This functionality is implemented in the RELOAD overlay itself, without the use of centralized servers. The RELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged.

 draft-jimenez-p2psip-coap-reload-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7650 RFC7651 3GPP IP Multimedia Subsystems (IMS) Option for the Internet Key Exchange Protocol Version 2 (IKEv2) A. Dodd-Noble S. Gundavelli J. Korhonen F. Baboescu B. Weis September 2015 ASCII HTML 10 P-CSCF P-CSCF Option for IKEv2 Proxy-Call Session Control Function IMS Option for IKEv2

This document defines two new configuration attributes for the Internet Key Exchange Protocol version 2 (IKEv2). These attributes can be used for carrying the IPv4 address and IPv6 address of the Proxy-Call Session Control Function (P-CSCF). When an IPsec gateway delivers these attributes to an IPsec client, the IPsec client can obtain the IPv4 and/or IPv6 address of the P-CSCF server located in the 3GPP network.

 draft-gundavelli-ipsecme-3gpp-ims-options-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7651 RFC7652 Port Control Protocol (PCP) Authentication Mechanism M. Cullen S. Hartman D. Zhang T. Reddy September 2015 ASCII HTML 34

An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address-mapping and port-mapping information on Network Address Translators (NATs) or firewalls to facilitate communication with remote hosts. However, the uncontrolled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases, the client may need to prove that it is authorized to modify, create, or delete PCP mappings. This document describes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices.

This document updates RFC 6887.

 draft-ietf-pcp-authentication-14 RFC6887 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp http://www.rfc-editor.org/errata_search.php?rfc=7652 10.17487/RFC7652 RFC7653 DHCPv6 Active Leasequery D. Raghuvanshi K. Kinnear D. Kukrety October 2015 ASCII HTML 30 DHCP IPv6 ACTIVELEASEQUERY DHCPv6

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv6 bindings. That mechanism is limited to queries for DHCPv6 binding data updates prior to the time the DHCPv6 server receives the Leasequery request. Continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv6 Leasequery protocol and allows for active transfer of real-time DHCPv6 binding information data via TCP. This document also updates DHCPv6 Bulk Leasequery (RFC 5460) by adding new options.

 draft-ietf-dhc-dhcpv6-active-leasequery-04 RFC5460 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7653 RFC7654 Benchmarking Methodology for In-Service Software Upgrade (ISSU) S. Banks F. Calabria G. Czirjak R. Machat October 2015 ASCII HTML 16

Modern forwarding devices attempt to minimize any control- and data-plane disruptions while performing planned software changes by implementing a technique commonly known as In-Service Software Upgrade (ISSU). This document specifies a set of common methodologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT), subject to an ISSU event.

 draft-ietf-bmwg-issu-meth-02 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7654 RFC7655 RTP Payload Format for G.711.0 M. Ramalho Editor P. Jones N. Harada M. Perumal L. Miao November 2015 ASCII HTML 32 G.711.0 G.711 G.711ZIP Lossless G.711 Compression G.711 Data Compression Algorithm

This document specifies the Real-time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format.

 draft-ietf-payload-g7110-06 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC7655 RFC7656 A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources J. Lennox K. Gross S. Nandakumar G. Salgueiro B. Burman Editor November 2015 ASCII HTML 46 Taxonomy Terminology RTP Grouping

The terminology about, and associations among, Real-time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed properties and relationships among RTP sources and defines common terminology for discussing protocol entities and their relationships.

 draft-ietf-avtext-rtp-grouping-taxonomy-08 INFORMATIONAL INFORMATIONAL IETF art avtext 10.17487/RFC7656 RFC7657 Differentiated Services (Diffserv) and Real-Time Communication D. Black Editor P. Jones November 2015 ASCII HTML 26 Diffserv DSCP RAI RTP

This memo describes the interaction between Differentiated Services (Diffserv) network quality-of-service (QoS) functionality and real- time network communication, including communication based on the Real-time Transport Protocol (RTP). Diffserv is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different Diffserv Codepoints (DSCPs). WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple. The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of these Diffserv aspects for real-time network communication, including WebRTC.

 draft-ietf-dart-dscp-rtp-10 INFORMATIONAL INFORMATIONAL IETF rai dart 10.17487/RFC7657 RFC7658 Deprecation of MIB Module NAT-MIB: Managed Objects for Network Address Translators (NATs) S. Perreault T. Tsou S. Sivakumar T. Taylor October 2015 ASCII HTML 62 NATV2-MIB management information base

This memo deprecates MIB module NAT-MIB, a portion of the Management Information Base (MIB) previously defined in RFC 4008 for devices implementing Network Address Translator (NAT) function. A companion document defines a new version, NATV2-MIB, which responds to deficiencies found in module NAT-MIB and adds new capabilities.

This document obsoletes RFC 4008. All MIB objects specified in RFC 4008 are included in this version unchanged with only the STATUS changed to deprecated.

 draft-perrault-behave-deprecate-nat-mib-v1-06 RFC4008 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7658 RFC7659 Definitions of Managed Objects for Network Address Translators (NATs) S. Perreault T. Tsou S. Sivakumar T. Taylor October 2015 ASCII HTML 84 MIB management information base NATV2-MIB NAT-MIB basic nat pooled nat carrier-grade nat CGN

This memo defines a portion of the Management Information Base (MIB) for devices implementing the Network Address Translator (NAT) function. The new MIB module defined in this document, NATV2-MIB, is intended to replace module NAT-MIB (RFC 4008). NATV2-MIB is not backwards compatible with NAT-MIB, for reasons given in the text of this document. A companion document deprecates all objects in NAT-MIB. NATV2-MIB can be used for the monitoring of NAT instances on a device capable of NAT function. Compliance levels are defined for three application scenarios: basic NAT, pooled NAT, and carrier-grade NAT (CGN).

 draft-perrault-behave-natv2-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7659 10.17487/RFC7659 RFC7660 Diameter Congestion and Filter Attributes L. Bertz S. Manning B. Hirschman October 2015 ASCII HTML 9

This document defines optional Diameter attributes that can be used to help manage networks that use Explicit Congestion Notification (ECN) or Diameter traffic filters. These new attributes allow for improved data traffic identification, support of ECN, and minimal Diameter filter administration.

RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that accommodates extensions for classification, conditions, and actions. It, however, does not support traffic identification for packets using Explicit Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by the Filter-Rule are congested.

Further, a Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g., packets) are not captured by accounting applications, leaving administrators without useful information regarding the effectiveness or appropriateness of the filter definition.

The optional attributes defined in this document are forward and backwards compatible with RFC 5777.

 draft-ietf-dime-congestion-flow-attributes-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7660 RFC7661 Updating TCP to Support Rate-Limited Traffic G. Fairhurst A. Sathiaseelan R. Secchi October 2015 ASCII HTML 21 CWV TCP

This document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP while also providing an appropriate response if congestion is experienced.

This document also evaluates the Experimental specification of TCP Congestion Window Validation (CWV) defined in RFC 2861 and concludes that RFC 2861 sought to address important issues but failed to deliver a widely used solution. This document therefore reclassifies the status of RFC 2861 from Experimental to Historic. This document obsoletes RFC 2861.

 draft-ietf-tcpm-newcwv-13 RFC2861 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC7661 RFC7662 OAuth 2.0 Token Introspection J. Richer Editor October 2015 ASCII HTML 17 token validation oauth token validation active token inactive token token metadata token status token status check

This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource.

 draft-ietf-oauth-introspection-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=7662 10.17487/RFC7662 RFC7663 Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) B. Trammell Editor M. Kuehlewind Editor October 2015 ASCII HTML 13 transport layer TCP UDP encapsulation

The Internet Architecture Board (IAB) through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute of Technology (ETH) Zurich hosted the Stack Evolution in a Middlebox Internet (SEMI) workshop in Zurich on 26-27 January 2015 to explore the ability to evolve the transport layer in the presence of middlebox- and interface-related ossification of the stack. The goal of the workshop was to produce architectural and engineering guidance on future work to break the logjam, focusing on incrementally deployable approaches with clear incentives to deployment both on the endpoints (in new transport layers and applications) as well as on middleboxes (run by network operators). This document summarizes the contributions to the workshop and provides an overview of the discussion at the workshop, as well as the outcomes and next steps identified by the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 draft-iab-semi-report-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7663 RFC7664 Dragonfly Key Exchange D. Harkins Editor November 2015 ASCII HTML 18 elliptic curve PAKE AKE dictionary attack password authentication

This document specifies a key exchange using discrete logarithm cryptography that is authenticated using a password or passphrase. It is resistant to active attack, passive attack, and offline dictionary attack. This document is a product of the Crypto Forum Research Group (CFRG).

 draft-irtf-cfrg-dragonfly-08 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=7664 10.17487/RFC7664 RFC7665 Service Function Chaining (SFC) Architecture J. Halpern Editor C. Pignataro Editor October 2015 ASCII HTML 32

This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols.

 draft-ietf-sfc-architecture-11 INFORMATIONAL INFORMATIONAL IETF rtg sfc http://www.rfc-editor.org/errata_search.php?rfc=7665 10.17487/RFC7665 RFC7666 Management Information Base for Virtual Machines Controlled by a Hypervisor H. Asai M. MacFaden J. Schoenwaelder K. Shima T. Tsou October 2015 ASCII HTML 52 MIB Hypervisor Virtual Machine VM-MIB IANA-STORAGE-MEDIA-TYPE-MIB

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this specifies objects for managing virtual machines controlled by a hypervisor (a.k.a. virtual machine monitor).

 draft-ietf-opsawg-vmm-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=7666 10.17487/RFC7666 RFC7667 RTP Topologies M. Westerlund S. Wenger November 2015 ASCII HTML 48 Real-time Multi-party Mixer Relay SFM Selective Forwarding Middlebox Translator Multicast ASM SSM

This document discusses point-to-point and multi-endpoint topologies used in environments based on the Real-time Transport Protocol (RTP). In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology.

 draft-ietf-avtcore-rtp-topologies-update-10 RFC5117 INFORMATIONAL INFORMATIONAL IETF art avtcore http://www.rfc-editor.org/errata_search.php?rfc=7667 10.17487/RFC7667 RFC7668 IPv6 over BLUETOOTH(R) Low Energy J. Nieminen T. Savolainen M. Isomaki B. Patil Z. Shelby C. Gomez October 2015 ASCII HTML 21 Bluetooth Low Energy 6lowpan IPv6 Low power

Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the Bluetooth Special Interest Group. The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets, and many other devices. The low-power version of Bluetooth is a specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. The low-power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6. This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques.

 draft-ietf-6lo-btle-17 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7668 RFC7669 Assigning Digital Object Identifiers to RFCs J. Levine October 2015 ASCII HTML 7

This document describes the way that Digital Object Identifiers (DOIs) are assigned to past and future RFCs. The DOI is a widely used system that assigns unique identifiers to digital documents that can be queried and managed in a consistent fashion.

 draft-iab-doi-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7669 RFC7670 Generic Raw Public-Key Support for IKEv2 T. Kivinen P. Wouters H. Tschofenig January 2016 ASCII HTML 10 Internet Key Exchange Version 2

The Internet Key Exchange Version 2 (IKEv2) protocol did have support for raw public keys, but it only supported RSA raw public keys. In constrained environments, it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography. This document updates RFC 7296, adding support for other types of raw public keys to IKEv2.

 draft-kivinen-ipsecme-oob-pubkey-14 RFC7296 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7670 RFC7671 The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance V. Dukhovni W. Hardaker October 2015 ASCII HTML 33 DANE TLSA

This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records.

 draft-ietf-dane-ops-16 RFC6698 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane 10.17487/RFC7671 RFC7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) V. Dukhovni W. Hardaker October 2015 ASCII HTML 34 DANE TLSA SMTP

This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS).

 draft-ietf-dane-smtp-with-dane-19 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane http://www.rfc-editor.org/errata_search.php?rfc=7672 10.17487/RFC7672 RFC7673 Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records T. Finch M. Miller P. Saint-Andre October 2015 ASCII HTML 16

The DNS-Based Authentication of Named Entities (DANE) specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its Transport Layer Security (TLS) certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers). However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain name cannot apply the rules from RFC 6698. Therefore, this document provides guidelines that enable such protocols to locate and use TLSA records.

 draft-ietf-dane-srv-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane 10.17487/RFC7673 RFC7674 Clarification of the Flowspec Redirect Extended Community J. Haas Editor October 2015 ASCII HTML 7 bgp flowspec

This document updates RFC 5575 ("Dissemination of Flow Specification Rules") to clarify the formatting of the BGP Flowspec Redirect Extended Community.

 draft-ietf-idr-flowspec-redirect-rt-bis-05 RFC8955 RFC5575 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7674 RFC7675 Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness M. Perumal D. Wing R. Ravindranath T. Reddy M. Thomson October 2015 ASCII HTML 10 WebRTC

To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints.

This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage.

 draft-ietf-rtcweb-stun-consent-freshness-16 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC7675 RFC7676 IPv6 Support for Generic Routing Encapsulation (GRE) C. Pignataro R. Bonica S. Krishnan October 2015 ASCII HTML 11 GRE IPv6

Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol. Currently, GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6.

This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol.

 draft-ietf-intarea-gre-ipv6-14 PROPOSED STANDARD PROPOSED STANDARD IETF int intarea 10.17487/RFC7676 RFC7677 SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms T. Hansen November 2015 ASCII HTML 8

This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, provides guidance for secure implementation of the original SCRAM-SHA-1-PLUS mechanism, and updates the SCRAM registration procedures of RFC 5802.

 draft-hansen-scram-sha256-04 RFC5802 RFC9266 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7677 RFC7678 Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions C. Zhou T. Taylor Q. Sun M. Boucadair October 2015 ASCII HTML 23 DS-Lite Lightweight 4over6 MAP-E IPv4 service continuity IPv6 deployment IPv4 address sharing Diameter Multicast IPv4 over IPv6

During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, Authentication, Authorization, and Accounting (AAA) support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter (RFC 6733) Attribute-Value Pairs (AVPs) to be used for that purpose.

 draft-ietf-dime-4over6-provisioning-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7678 RFC7679 A One-Way Delay Metric for IP Performance Metrics (IPPM) G. Almes S. Kalidindi M. Zekauskas A. Morton Editor January 2016 ASCII HTML 27 Performance Measurement Quality of Service (QoS)

This memo defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2679 obsolete.

 draft-ietf-ippm-2679-bis-05 RFC2679 STD0081 INTERNET STANDARD INTERNET STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=7679 10.17487/RFC7679 RFC7680 A One-Way Loss Metric for IP Performance Metrics (IPPM) G. Almes S. Kalidindi M. Zekauskas A. Morton Editor January 2016 ASCII HTML 22 Performance Measurement Quality of Service (QoS)

This memo defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2680 obsolete.

 draft-ietf-ippm-2680-bis-05 RFC2680 STD0082 INTERNET STANDARD INTERNET STANDARD IETF tsv ippm 10.17487/RFC7680 RFC7681 Email Exchange of Secondary School Transcripts J. Davin October 2015 ASCII HTML 40 Internet Applications email school transcript MIME OpenPGP

A common format simplifies exchange of secondary school academic transcripts via electronic mail. Existing standards are applied to prevent unauthorized alteration of transcript content and to deliver transcripts directly and securely from each student to his or her chosen recipients. By eliminating third-party intervention and surveillance, the defined protocol better protects student privacy and independence than does current practice.

 draft-davin-eesst-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7681 RFC7682 Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration D. McPherson S. Amante E. Osterweil L. Blunk D. Mitchell December 2015 ASCII HTML 18 Resource Certification Internet Routing Registry IRR Routing Policy Specification Language RPSL

The purpose of this document is to catalog issues that influenced the efficacy of Internet Routing Registries (IRRs) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based filtering adoption and IRR utility to this day.

 draft-ietf-grow-irr-routing-policy-considerations-06 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC7682 RFC7683 Diameter Overload Indication Conveyance J. Korhonen Editor S. Donovan Editor B. Campbell L. Morand October 2015 ASCII HTML 42 DOIC

This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance (DOIC).

 draft-ietf-dime-ovli-10 RFC8581 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=7683 10.17487/RFC7683 RFC7684 OSPFv2 Prefix/Link Attribute Advertisement P. Psenak H. Gredler R. Shakir W. Henderickx J. Tantsura A. Lindem November 2015 ASCII HTML 15 OSPF-LSA open shortest path first link state advertisement Opaque LSA

OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328. This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optional and fully backward compatible.

 draft-ietf-ospf-prefix-link-attr-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7684 RFC7685 A Transport Layer Security (TLS) ClientHello Padding Extension A. Langley October 2015 ASCII HTML 4

This memo describes a Transport Layer Security (TLS) extension that can be used to pad ClientHello messages to a desired size.

 draft-ietf-tls-padding-04 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7685 RFC7686 The ".onion" Special-Use Domain Name J. Appelbaum A. Muffett October 2015 ASCII HTML 7

This document registers the ".onion" Special-Use Domain Name.

 draft-ietf-dnsop-onion-tld-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7686 10.17487/RFC7686 RFC7687 Report from the Strengthening the Internet (STRINT) Workshop S. Farrell R. Wenning B. Bos M. Blanchet H. Tschofenig December 2015 ASCII HTML 32 IAB W3C STREWS security pervasive monitoring London

The Strengthening the Internet (STRINT) workshop assembled one hundred participants in London for two days in early 2014 to discuss how the technical community, and in particular the IETF and the W3C, should react to Pervasive Monitoring and more generally how to strengthen the Internet in the face of such attacks. The discussions covered issues of terminology, the role of user interfaces, classes of mitigation, some specific use cases, transition strategies (including opportunistic encryption), and more. The workshop ended with a few high-level recommendations, that it is believed could be implemented and could help strengthen the Internet. This is the report of that workshop.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 draft-iab-strint-report-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7687 RFC7688 GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks Y. Lee Editor G. Bernstein Editor November 2015 ASCII HTML 12

This document provides Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing enhancements to support signal compatibility constraints associated with Wavelength Switched Optical Network (WSON) elements. These routing enhancements are applicable in common optical or hybrid electro-optical networks where not all the optical signals in the network are compatible with all network elements participating in the network.

This compatibility constraint model is applicable to common optical or hybrid electro-optical systems such as optical-electronic-optical (OEO) switches, regenerators, and wavelength converters, since such systems can be limited to processing only certain types of WSON signals.

 draft-ietf-ccamp-wson-signal-compatibility-ospf-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7688 RFC7689 Signaling Extensions for Wavelength Switched Optical Networks G. Bernstein Editor S. Xu Y. Lee Editor G. Martinelli H. Harai November 2015 ASCII HTML 16

This document provides extensions to Generalized Multiprotocol Label Switching (GMPLS) signaling for control of Wavelength Switched Optical Networks (WSONs). Such extensions are applicable in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. This document provides mechanisms to support distributed wavelength assignment with a choice of distributed wavelength assignment algorithms.

 draft-ietf-ccamp-wson-signaling-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7689 RFC7690 Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)) M. Byerly M. Hite J. Jaeggli January 2016 ASCII HTML 9 IPv6 ICMP6 ICMPv6 type 2 PTB

This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination (typically the server) in ECMP load-balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failures.

 draft-ietf-v6ops-pmtud-ecmp-problem-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7690 RFC7691 Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members S. Bradner Editor November 2015 ASCII HTML 4

BCP 101 defines the start and end dates for the terms of IETF Administrative Oversight Committee (IAOC) members; these terms have proven to be impractical. This memo updates BCP 101 to direct the IAOC to establish more practical start and end dates for terms of IAOC members.

 draft-bradner-iaoc-terms-04 RFC8711 RFC4071 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7691 RFC7692 Compression Extensions for WebSocket T. Yoshino December 2015 ASCII HTML 28 DEFLATE LZ77

This document defines a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol. An extension based on this framework compresses the payload data portion of WebSocket data messages on a per-message basis using parameters negotiated during the opening handshake. This framework provides a general method for applying a compression algorithm to the contents of WebSocket messages. Each compression algorithm has to be defined in a document defining the extension by specifying the parameter negotiation and the payload transformation algorithm in detail. This document also specifies one specific compression extension using the DEFLATE algorithm.

 draft-ietf-hybi-permessage-compression-28 PROPOSED STANDARD PROPOSED STANDARD IETF art hybi http://www.rfc-editor.org/errata_search.php?rfc=7692 10.17487/RFC7692 RFC7693 The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC) M-J. Saarinen Editor J-P. Aumasson November 2015 ASCII HTML 30 BLAKE2 Cryptographic Hash

This document describes the cryptographic hash function BLAKE2 and makes the algorithm specification and C source code conveniently available to the Internet community. BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms and BLAKE2s for smaller architectures. BLAKE2 can be directly keyed, making it functionally equivalent to a Message Authentication Code (MAC).

 draft-saarinen-blake2-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7693 RFC7694 Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding J. Reschke November 2015 ASCII HTML 7 HTTP content-encoding

In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages.

Content codings can be used in request messages as well; however, discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate the content codings that are supported in requests.

 draft-ietf-httpbis-cice-03 RFC9110 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC7694 RFC7695 Distributed Prefix Assignment Algorithm P. Pfister B. Paterson J. Arkko November 2015 ASCII HTML 20 distributed prefix address assignment homenet

This document specifies a distributed algorithm for dividing a set of prefixes in a manner that allows for automatic assignment of sub-prefixes that are unique and non-overlapping. Used in conjunction with a protocol that provides flooding of information among a set of participating nodes, prefix configuration within a network may be automated.

 draft-ietf-homenet-prefix-assignment-08 PROPOSED STANDARD PROPOSED STANDARD IETF int homenet 10.17487/RFC7695 RFC7696 Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms R. Housley November 2015 ASCII HTML 19

Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.

 draft-iab-crypto-alg-agility-08 BCP0201 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7696 10.17487/RFC7696 RFC7697 MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) P. Pan S. Aldrin M. Venkatesan K. Sampath T. Nadeau S. Boutros January 2016 ASCII HTML 36 MPLS-OAM-ID-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure the Operations, Administration, and Maintenance (OAM) identifiers for Multiprotocol Label Switching (MPLS) and the MPLS-based Transport Profile (TP).

 draft-ietf-mpls-tp-oam-id-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7697 10.17487/RFC7697 RFC7698 Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks O. Gonzalez de Dios Editor R. Casellas Editor F. Zhang X. Fu D. Ceccarelli I. Hussain November 2015 ASCII HTML 42 DWDM Flexi-Grid GMPLS

To allow efficient allocation of optical spectral bandwidth for systems that have high bit-rates, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings, and the concept of the "frequency slot". In such an environment, a data-plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum, creating what is known as a flexible grid (flexi-grid).

Given the specific characteristics of flexi-grid optical networks and their associated technology, this document defines a framework and the associated control-plane requirements for the application of the existing GMPLS architecture and control-plane protocols to the control of flexi-grid DWDM networks. The actual extensions to the GMPLS protocols will be defined in companion documents.

 draft-ietf-ccamp-flexi-grid-fwk-07 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7698 RFC7699 Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers A. Farrel D. King Y. Li F. Zhang November 2015 ASCII HTML 14 GMPLS RSVP-TE

GMPLS supports the description of optical switching by identifying entries in fixed lists of switchable wavelengths (called grids) through the encoding of lambda labels. Work within the ITU-T Study Group 15 has defined a finer-granularity grid, and the facility to flexibly select different widths of spectrum from the grid. This document defines a new GMPLS lambda label format to support this flexi-grid.

This document updates RFCs 3471 and 6205 by introducing a new label format.

 draft-ietf-ccamp-flexigrid-lambda-label-05 RFC3471 RFC6205 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7699 RFC7700 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames P. Saint-Andre December 2015 ASCII HTML 11 nickname SIP SIMPLE XMPP MSRP XCON chatrooms

This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities.

 draft-ietf-precis-nickname-19 RFC8266 PROPOSED STANDARD PROPOSED STANDARD IETF art precis http://www.rfc-editor.org/errata_search.php?rfc=7700 10.17487/RFC7700 RFC7701 Multi-party Chat Using the Message Session Relay Protocol (MSRP) A. Niemi M. Garcia-Martin G. Sandbakken December 2015 ASCII HTML 42 messaging message sessions multi-party chat MSRP SIMPLE

The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages (IMs) within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP.

 draft-ietf-simple-chat-18 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC7701 RFC7702 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat P. Saint-Andre S. Ibarra S. Loreto December 2015 ASCII HTML 43 Text Chat Groupchat Instant Messaging Session Initiation Protocol SIP Message Sessions Relay Protocol MSRP Extensible Messaging and Presence Protocol XMPP

This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multi-party chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically, this document defines a mapping between the SIP-based Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat (MUC) extension.

 draft-ietf-stox-groupchat-11 PROPOSED STANDARD PROPOSED STANDARD IETF art stox 10.17487/RFC7702 RFC7703 Experience with Testing of Mapping of Address and Port Using Translation (MAP-T) E. Cordeiro R. Carnier A. Moreiras November 2015 ASCII HTML 56 template

This document describes the testing result of a network utilizing a Mapping of Address and Port using Translation (MAP-T) double translation solution; it provides an overview of user applications' behavior with a shared IPv4 address.

The MAP-T software is from CERNET Center and the test environment is on the NIC.br network with real and virtualized machines.

 draft-cordeiro-experience-mapt-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7703 RFC7704 An IETF with Much Diversity and Professional Conduct D. Crocker N. Clark November 2015 ASCII HTML 18

The process of producing today's Internet technologies through a culture of open participation and diverse collaboration has proved strikingly efficient and effective, and it is distinctive among standards organizations. During the early years of the IETF and its antecedent, participation was almost entirely composed of a small group of well-funded, American, white, male technicians, demonstrating a distinctive and challenging group dynamic, both in management and in personal interactions. In the case of the IETF, interaction style can often contain singularly aggressive behavior, often including singularly hostile tone and content. Groups with greater diversity make better decisions. Obtaining meaningful diversity requires more than generic good will and statements of principle. Many different behaviors can serve to reduce participant diversity or participation diversity. This document discusses IETF participation in terms of the nature of diversity and practical issues that can increase or decrease it. The document represents the authors' assessments and recommendations, following general discussions of the issues in the IETF.

 draft-crocker-diversity-conduct-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7704 RFC7705 Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute W. George S. Amante November 2015 ASCII HTML 16 as-migration AS-migration AS_migration AS migration IDR BGP

This document discusses some existing commonly used BGP mechanisms for Autonomous System Number (ASN) migration that are not formally part of the BGP4 protocol specification. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work.

 draft-ietf-idr-as-migration-06 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7705 RFC7706 Decreasing Access Time to Root Servers by Running One on Loopback W. Kumari P. Hoffman November 2015 ASCII HTML 12

Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1). This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator.

 draft-ietf-dnsop-root-loopback-05 RFC8806 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7706 10.17487/RFC7706 RFC7707 Network Reconnaissance in IPv6 Networks F. Gont T. Chown March 2016 ASCII HTML 38

IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore, IPv6 address-scanning attacks have been considered unfeasible. This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address-scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance.

 draft-ietf-opsec-ipv6-host-scanning-08 RFC5157 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=7707 10.17487/RFC7707 RFC7708 Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator T. Nadeau L. Martini S. Bryant November 2015 ASCII HTML 9 VCCV GAL

The Virtual Circuit Connectivity Verification (VCCV) protocol specified in RFC 5085 provides a control channel (CC) that is associated with a pseudowire (PW). This document specifies an additional VCCV control channel type to be used with pseudowires that do not use the PW Control Word and that are carried over an MPLS network. This new VCCV CC type uses the Generic Associated Channel Label defined in RFC 5586 to distinguish VCCV packets from packets carrying user data. This new VCCV CC type introduces compatibility with the method of MPLS Label Switched Path Operations, Administration, and Maintenance (OAM) identification, particularly in MPLS Transport Profile (MPLS-TP) networks (RFC 5921).

 draft-ietf-pals-vccv-for-gal-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7708 RFC7709 Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs) A. Malis Editor B. Wilson G. Clapp V. Shukla November 2015 ASCII HTML 9 generalized multiprotocol label switching OTN optical transport networks WSON TDM WDM churn on-demand wavelength rapid setup

Establishment and control of Label Switch Paths (LSPs) have become mainstream tools of commercial and government network providers. One of the elements of further evolving such networks is scaling their performance in terms of LSP bandwidth and traffic loads, LSP intensity (e.g., rate of LSP creation, deletion, and modification), LSP set up delay, quality-of-service differentiation, and different levels of resilience.

The goal of this document is to present target scaling objectives and the related protocol requirements for Generalized Multi-Protocol Label Switching (GMPLS).

 draft-ietf-teas-fast-lsps-requirements-02 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC7709 RFC7710 Captive-Portal Identification Using DHCP or Router Advertisements (RAs) W. Kumari O. Gudmundsson P. Ebersman S. Sheng December 2015 ASCII HTML 8

In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive-portal mode. This highly restricts what the customer can do until the customer has authenticated.

This document describes a DHCP option (and a Router Advertisement (RA) extension) to inform clients that they are behind some sort of captive-portal device and that they will need to authenticate to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to and interacting with the captive portal is out of scope for this document.

 draft-wkumari-dhc-capport-16 RFC8910 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7710 RFC7711 PKIX over Secure HTTP (POSH) M. Miller P. Saint-Andre November 2015 ASCII HTML 18 Extensible Messaging and Presence Protocol Jabber federation

Experience has shown that it is difficult to deploy proper PKIX certificates for Transport Layer Security (TLS) in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security. This document defines methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. Although these methods were developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols.

 draft-ietf-xmpp-posh-06 PROPOSED STANDARD PROPOSED STANDARD IETF art xmpp http://www.rfc-editor.org/errata_search.php?rfc=7711 10.17487/RFC7711 RFC7712 Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre M. Miller P. Hancke November 2015 ASCII HTML 24 XMPP Extensible Messaging and Presence Protocol Jabber federation delegation security

This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of "prooftypes". Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server hostname (e.g., hosting.example.net); this is especially important in multi-tenanted environments where the same target server hosts a large number of domains.

 draft-ietf-xmpp-dna-11 PROPOSED STANDARD PROPOSED STANDARD IETF art xmpp 10.17487/RFC7712 RFC7713 Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements M. Mathis B. Briscoe December 2015 ASCII HTML 30 Quality of Service QoS Congestion Control Signaling Protocol Encoding Audit Policing

This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by Explicit Congestion Notification (ECN) markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called Congestion Exposure, or ConEx. The companion document, "Congestion Exposure (ConEx) Concepts and Use Cases" (RFC 6789), provides the entry point to the set of ConEx documentation.

 draft-ietf-conex-abstract-mech-13 INFORMATIONAL INFORMATIONAL IETF tsv conex 10.17487/RFC7713 RFC7714 AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) D. McGrew K. Igoe December 2015 ASCII HTML 48

This document defines how the AES-GCM Authenticated Encryption with Associated Data family of algorithms can be used to provide confidentiality and data authentication in the Secure Real-time Transport Protocol (SRTP).

 draft-ietf-avtcore-srtp-aes-gcm-17 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore http://www.rfc-editor.org/errata_search.php?rfc=7714 10.17487/RFC7714 RFC7715 Multipoint LDP (mLDP) Node Protection IJ. Wijnands Editor K. Raza A. Atlas J. Tantsura Q. Zhao January 2016 ASCII HTML 19

This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (P2MP and MP2MP LSPs) that have been built by the Multipoint Label Distribution Protocol (mLDP). In order to protect a node N, the Point of Local Repair (PLR) Label Switching Router (LSR) of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing Point-to-Point (P2P) Label Switched Paths (LSPs). The pre-established LSPs originate from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N.

 draft-ietf-mpls-mldp-node-protection-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7715 RFC7716 Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures J. Zhang L. Giuliano E. Rosen Editor K. Subramanian D. Pacella December 2015 ASCII HTML 22 Multicast

RFCs 6513, 6514, and others describe protocols and procedures that a Service Provider (SP) may deploy in order to offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers. Some of these procedures use BGP to distribute VPN-specific multicast routing information across a backbone network. With a small number of relatively minor modifications, the same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN. Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as "Internet multicast". In this document, we describe the modifications that are needed to use the BGP-MVPN procedures for Global Table Multicast.

 draft-ietf-bess-mvpn-global-table-mcast-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7716 RFC7717 IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) K. Pentikousis Editor E. Zhang Y. Cui December 2015 ASCII HTML 15

The One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) security mechanisms require that both the client and server endpoints possess a shared secret. This document describes the use of keys derived from an IKEv2 security association (SA) as the shared key in OWAMP or TWAMP. If the shared key can be derived from the IKEv2 SA, OWAMP or TWAMP can support certificate-based key exchange; this would allow for more operational flexibility and efficiency. The key derivation presented in this document can also facilitate automatic key management.

 draft-ietf-ippm-ipsec-11 RFC4656 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC7717 RFC7718 Registries for the One-Way Active Measurement Protocol (OWAMP) A. Morton December 2015 ASCII HTML 7

This memo describes the registries for OWAMP -- the One-Way Active Measurement Protocol. The registries allow assignment of Mode bit positions and OWAMP Command numbers. Per this memo, IANA has established the registries for new features, called the OWAMP-Modes registry and the OWAMP Control Command Number registry. This memo updates RFC 4656.

 draft-ietf-ippm-owamp-registry-03 RFC4656 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC7718 RFC7719 DNS Terminology P. Hoffman A. Sullivan K. Fujiwara December 2015 ASCII HTML 27

The DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.

 draft-ietf-dnsop-dns-terminology-05 RFC8499 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7719 10.17487/RFC7719 RFC7720 DNS Root Name Service Protocol and Deployment Requirements M. Blanchet L-J. Liman December 2015 ASCII HTML 6

The DNS root name service is a critical part of the Internet architecture. The protocol and deployment requirements for the DNS root name service are defined in this document. Operational requirements are out of scope.

 draft-iab-2870bis-03 RFC2870 BCP0040 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC7720 RFC7721 Security and Privacy Considerations for IPv6 Address Generation Mechanisms A. Cooper F. Gont D. Thaler March 2016 ASCII HTML 18

This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.

 draft-ietf-6man-ipv6-address-generation-privacy-08 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC7721 RFC7722 Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) C. Dearlove T. Clausen December 2015 ASCII HTML 23

This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension.

This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions.

 draft-ietf-manet-olsrv2-multitopology-07 RFC7188 RFC7631 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC7722 RFC7723 Port Control Protocol (PCP) Anycast Addresses S. Kiesel R. Penno January 2016 ASCII HTML 9 Port Control Protocol anycast address anycast server discovery Port Control Protocol server discovery port mapping NAT control firewall control

The Port Control Protocol (PCP) anycast addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-path NAT, firewall, or other middlebox without having to learn the IP address of that middlebox via some external channel. This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP anycast addresses.

 draft-ietf-pcp-anycast-08 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7723 RFC7724 Active DHCPv4 Lease Query K. Kinnear M. Stapp B. Volz N. Russell December 2015 ASCII HTML 28

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv4 bindings (RFC 4388). That mechanism is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient, or even possible. In addition, continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv4 Leasequery protocol, and allows for active transfer of near real-time DHCPv4 binding information data via TCP. This document updates RFC 6926, "DHCPv4 Bulk Leasequery".

 draft-ietf-dhc-dhcpv4-active-leasequery-07 RFC6926 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7724 RFC7725 An HTTP Status Code to Report Legal Obstacles T. Bray February 2016 ASCII HTML 5 Hypertext Transfer Protocol

This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.

 draft-ietf-httpbis-legally-restricted-status-04 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=7725 10.17487/RFC7725 RFC7726 Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs) V. Govindan K. Rajaraman G. Mirsky N. Akiya S. Aldrin January 2016 ASCII HTML 7 RFC5884 MPLS LSP BFD RFC 5884

This document clarifies the procedures for establishing, maintaining, and removing multiple, concurrent BFD (Bidirectional Forwarding Detection) sessions for a given <MPLS LSP, FEC> as described in RFC 5884.

 draft-ietf-bfd-rfc5884-clarifications-04 RFC5884 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC7726 RFC7727 Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) M. Zhang H. Wen J. Hu January 2016 ASCII HTML 25

The Inter-Chassis Communication Protocol (ICCP) supports an inter-chassis redundancy mechanism that is used to support high network availability.

In this document, Provider Edge (PE) devices in a Redundancy Group (RG) running ICCP are used to offer multihomed connectivity to Spanning Tree Protocol (STP) networks to improve availability of the STP networks. The ICCP TLVs and usage for the ICCP STP application are defined.

 draft-ietf-pwe3-iccp-stp-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7727 RFC7728 RTP Stream Pause and Resume B. Burman A. Akram R. Even M. Westerlund February 2016 ASCII HTML 55 CCM RTCP Feedback Bandwidth PAUSED REFUSED TMMBR TMMBN Mixer MCU

With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using the Real-time Transport Protocol (RTP) for real- time data transport. This document extends the Codec Control Message (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCMs and adding a group of new real-time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104.

 draft-ietf-avtext-rtp-stream-pause-10 RFC5104 PROPOSED STANDARD PROPOSED STANDARD IETF art avtext http://www.rfc-editor.org/errata_search.php?rfc=7728 10.17487/RFC7728 RFC7729 Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management B. Khasnabish E. Haleplidis J. Hadi Salim Editor December 2015 ASCII HTML 20 ForCES LFB Subsidiary Management Virtualization

Deployment experience has demonstrated the value of using the Forwarding and Control Element Separation (ForCES) architecture to manage resources other than packet forwarding. In that spirit, the Forwarding Element Manager (FEM) is modeled by creating a Logical Functional Block (LFB) to represent its functionality. We refer to this LFB as the Subsidiary Mechanism (SM) LFB. A Control Element (CE) that controls a Forwarding Element's (FE) resources can also manage its configuration via the SM LFB. This document introduces the SM LFB class, an LFB class that specifies the configuration parameters of an FE. The configuration parameters include new LFB class loading and CE associations; they also provide manipulation of debug mechanisms along with a general purpose attribute definition to describe configuration information.

 draft-ietf-forces-lfb-subsidiary-management-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7729 10.17487/RFC7729 RFC7730 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator G. Huston S. Weiler G. Michaelson S. Kent January 2016 ASCII HTML 8 RPKI BGP Security

This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL.

 draft-ietf-sidr-rfc6490-bis-05 RFC6490 RFC8630 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC7730 RFC7731 Multicast Protocol for Low-Power and Lossy Networks (MPL) J. Hui R. Kelsey February 2016 ASCII HTML 29 6lowpan 802.15.4 IPv6 LLN ROLL mesh network trickle wsn wireless sensor network

This document specifies the Multicast Protocol for Low-Power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain.

MPL has two modes of operation. One mode uses the Trickle algorithm to manage control-plane and data-plane message transmissions and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, an MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency.

 draft-ietf-roll-trickle-mcast-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC7731 RFC7732 Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) P. van der Stok R. Cragie February 2016 ASCII HTML 15 routing MPL multicast policy IP networks

The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low-Power and Lossy Networks (MPL) multicast messages with Admin-Local scope in a border router.

 draft-ietf-roll-admin-local-policy-03 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC7732 RFC7733 Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control A. Brandt E. Baccelli R. Cragie P. van der Stok February 2016 ASCII HTML 38 sensor network ad hoc network routing RPL applicability building control home automation IP networks

The purpose of this document is to provide guidance in the selection and use of protocols from the Routing Protocol for Low-Power and Lossy Networks (RPL) protocol suite to implement the features required for control in building and home environments.

 draft-ietf-roll-applicability-home-building-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC7733 RFC7734 Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN) D. Allan Editor J. Tantsura D. Fedyk A. Sajassi January 2016 ASCII HTML 11 SPBM Provider Backbone Bridging Provider Edges PBB-EVPN

This document describes how Ethernet Shortest Path Bridging MAC mode (SPBM) can be combined with Ethernet VPN (EVPN) to interwork with Provider Backbone Bridging Provider Edges (PBB PEs) as described in the PBB-EVPN solution (RFC 7623). This is achieved via operational isolation of each Ethernet network attached to an EVPN core while supporting full interworking between the different variations of Ethernet networks.

 draft-ietf-bess-spbm-evpn-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7734 RFC7735 Tracking Reviews of Documents R. Sparks T. Kivinen January 2016 ASCII HTML 16 review tool requirements

Several review teams ensure specific types of review are performed on Internet-Drafts as they progress towards becoming RFCs. The tools used by these teams to assign and track reviews would benefit from tighter integration to the Datatracker. This document discusses requirements for improving those tools without disrupting current work flows.

 draft-sparks-genarea-review-tracker-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7735 RFC7736 Content Delivery Network Interconnection (CDNI) Media Type Registration K. Ma December 2015 ASCII HTML 7 CDNI CDN Interconnect CDN content delivery content delivery network

This document defines the standard media type used by the Content Delivery Network Interconnection (CDNI) protocol suite, including the registration procedure and recommended usage of the required payload- type parameter.

 draft-ietf-cdni-media-type-06 INFORMATIONAL INFORMATIONAL IETF art cdni 10.17487/RFC7736 RFC7737 Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification N. Akiya G. Swallow C. Pignataro L. Andersson M. Chen January 2016 ASCII HTML 17 MPLS LSP Ping Reply Mode

The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the procedures for the "Reply via Specified Path" Reply Mode. The value of this Reply Mode is 5. The update creates a simple way to indicate that the reverse LSP should be used as the return path. This document also adds an optional TLV that can carry an ordered list of Reply Mode values.

 draft-ietf-mpls-lsp-ping-reply-mode-simple-05 RFC7110 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7737 RFC7738 A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS) M. Blanchet A. Schiltknecht P. Shames January 2016 ASCII HTML 8

This document describes a Uniform Resource Name (URN) namespace intended for persistently and uniquely naming resources published by the Consultative Committee for Space Data Systems (CCSDS).

 draft-blanchet-ccsds-urn-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7738 RFC7739 Security Implications of Predictable Fragment Identification Values F. Gont February 2016 ASCII HTML 20 attack vulnerability Denial of Service protocol identifiers

IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field that, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host. The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated.

 draft-ietf-6man-predictable-fragment-id-10 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC7739 RFC7740 Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication Z. Zhang Y. Rekhter A. Dolganow January 2016 ASCII HTML 8 MVPN Ingress Replication Bidirectional C-flow p-tunnel

RFC 6513 ("Multicast in MPLS/BGP IP VPNs") describes a method to support bidirectional customer multicast flows using a partial mesh of Multipoint-to-Multipoint (MP2MP) tunnels. This document specifies how a partial mesh of MP2MP tunnels can be simulated using Ingress Replication. This solution enables a service provider to use Ingress Replication to offer transparent bidirectional multicast service to its VPN customers.

 draft-ietf-bess-mvpn-bidir-ingress-replication-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7740 RFC7741 RTP Payload Format for VP8 Video P. Westin H. Lundin M. Glover J. Uberti F. Galligan March 2016 ASCII HTML 27 RTP V8 WebM

This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low-bitrate peer-to-peer usage to high-bitrate video conferences.

 draft-ietf-payload-vp8-17 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC7741 RFC7742 WebRTC Video Processing and Codec Requirements A.B. Roach March 2016 ASCII HTML 10 MTI mandatory-to-implement

This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required as well as video codecs and their parameters.

 draft-ietf-rtcweb-video-06 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC7742 RFC7743 Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping J. Luo Editor L. Jin Editor T. Nadeau Editor G. Swallow Editor January 2016 ASCII HTML 18

In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 ("Label Switched Path (LSP) Ping and Traceroute"), a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded, resulting in false negatives or a complete failure of operation of the LSP Ping and Traceroute. This document describes extensions to the LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379.

 draft-ietf-mpls-lsp-ping-relay-reply-11 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7743 RFC7744 Use Cases for Authentication and Authorization in Constrained Environments L. Seitz Editor S. Gerdes Editor G. Selander M. Mani S. Kumar January 2016 ASCII HTML 30 Internet of Things IoT Smart Object Security

Constrained devices are nodes with limited processing power, storage space, and transmission capacities. In many cases, these devices do not provide user interfaces, and they are often intended to interact without human intervention.

This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the life cycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios.

Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as a communication protocol. However, most conclusions apply generally.

 draft-ietf-ace-usecases-10 INFORMATIONAL INFORMATIONAL IETF sec ace 10.17487/RFC7744 RFC7745 XML Schemas for Reverse DNS Management T. Manderson January 2016 ASCII HTML 10

This document defines an Extensible Markup Language (XML) schema for reverse DNS management in a tightly controlled Representational State Transfer (REST) environment. This document describes a schema that has been developed and deployed by ICANN in a "RESTful" system since 2011 and is being used by the registries responsible for reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through an HTTPS transaction that is mediated by an X.509 certificate.

 draft-manderson-rdns-xml-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7745 RFC7746 Label Switched Path (LSP) Self-Ping R. Bonica I. Minei M. Conn D. Pacella L. Tomotaki January 2016 ASCII HTML 12

When certain RSVP-TE optimizations are implemented, ingress Label Switching Router (LSRs) can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through a Label Switched Path (LSP) as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost.

This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes.

LSP Self-ping is a new protocol. It is not an extension of LSP Ping. Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures.

LSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs.

 draft-ietf-mpls-self-ping-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7746 RFC7747 Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence R. Papneja B. Parise S. Hares D. Lee I. Varlashkin April 2016 ASCII HTML 35 BMWG

BGP is widely deployed and used by several service providers as the default inter-AS (Autonomous System) routing protocol. It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed. This document provides the basic BGP benchmarking methodology using existing BGP convergence terminology as defined in RFC 4098.

 draft-ietf-bmwg-bgp-basic-convergence-05 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7747 RFC7748 Elliptic Curves for Security A. Langley M. Hamburg S. Turner January 2016 ASCII HTML 22 elliptic curve cryptography ecc

This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.

 draft-irtf-cfrg-curves-11 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=7748 10.17487/RFC7748 RFC7749 The "xml2rfc" Version 2 Vocabulary J. Reschke February 2016 ASCII HTML 76 XML IETF RFC Internet-Draft Vocabulary

This document defines the "xml2rfc" version 2 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts.

Version 2 represents the state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014.

This document obsoletes RFC 2629.

 draft-iab-xml2rfcv2-02 RFC2629 RFC7991 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7749 10.17487/RFC7749 RFC7750 Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP) J. Hedin G. Mirsky S. Baillargeon February 2016 ASCII HTML 11 IPPM TWAMP Type-P Descriptor

This document describes an optional extension for Two-Way Active Measurement Protocol (TWAMP) allowing the monitoring of the Differentiated Service Code Point and Explicit Congestion Notification fields with the TWAMP-Test protocol.

 draft-ietf-ippm-type-p-monitor-03 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC7750 RFC7751 Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs) S. Sorce T. Yu March 2016 ASCII HTML 10 Kerberos

This document specifies a Kerberos authorization data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained authorization data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container. This document updates RFC 4120.

 draft-ietf-kitten-cammac-04 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC7751 RFC7752 North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP H. Gredler Editor J. Medved S. Previdi A. Farrel S. Ray March 2016 ASCII HTML 48 BGP North-Bound API Link-State Topology Controller Multi-Area Multi-AS

In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.

This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.

Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).

 draft-ietf-idr-ls-distribution-13 RFC9029 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=7752 10.17487/RFC7752 RFC7753 Port Control Protocol (PCP) Extension for Port-Set Allocation Q. Sun M. Boucadair S. Sivakumar C. Zhou T. Tsou S. Perreault February 2016 ASCII HTML 19 IPv4 service continuity IPv4 address shortage A+P AplusP address plus port MAP Port range Port Range Router MAP-E port set mapping port bulk

In some use cases, e.g., Lightweight 4over6, the client may require not just one port, but a port set. This document defines an extension to the Port Control Protocol (PCP) that allows clients to manipulate a set of ports as a whole. This is accomplished using a new MAP option: PORT_SET.

 draft-ietf-pcp-port-set-13 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7753 RFC7754 Technical Considerations for Internet Service Blocking and Filtering R. Barnes A. Cooper O. Kolkman D. Thaler E. Nordmark March 2016 ASCII HTML 33 Firewall Filter Deep Packet Inspection Domain Name Seizure Web Portal Web Proxy

The Internet is structured to be an open communications medium. This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties. Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications. Recently, there has been an increasing emphasis on "blocking" and "filtering", the active prevention of such communications. This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture. When it is possible to do so, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications. We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches.

 draft-iab-filtering-considerations-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7754 RFC7755 SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments T. Anderson February 2016 ASCII HTML 24 Data Centre Data Center Dual Stack Single Stack IDC IPv4 IPv4 conservation IPv4 exhaustion IPv6-only IPv6 only IPv6 transition IPv6 transition technology XLAT

This document describes the use of the Stateless IP/ICMP Translation Algorithm (SIIT) in an IPv6 Internet Data Center (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilization of public IPv4 addresses.

The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feeling that dual stack causes undesirable operational complexity.

 draft-ietf-v6ops-siit-dc-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7755 RFC7756 Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode T. Anderson S. Steffann February 2016 ASCII HTML 17 Data Centre Data Center Dual Stack Single Stack IDC IPv4 IPv4 conservation IPv4 exhaustion IPv6-only IPv6 only IPv6 transition IPv6 transition technology XLAT

This document describes an extension of the Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC) architecture, which allows applications, protocols, or nodes that are incompatible with IPv6 and/or Network Address Translation to operate correctly with SIIT-DC. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The application and/or node is thus provided with seemingly native IPv4 connectivity that provides end-to-end address transparency.

The reader is expected to be familiar with the SIIT-DC architecture described in RFC 7755.

 draft-ietf-v6ops-siit-dc-2xlat-02 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7756 RFC7757 Explicit Address Mappings for Stateless IP/ICMP Translation T. Anderson A. Leiva Popper February 2016 ASCII HTML 19 Dual Stack Single Stack IPv4 IPv4 conservation IPv4 exhaustion IPv6-only IPv6 only IPv6 transition IPv6 transition technology XLAT

This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping (EAM) algorithm and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4.

 draft-ietf-v6ops-siit-eam-03 RFC6145 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC7757 RFC7758 Time Capability in NETCONF T. Mizrahi Y. Moses February 2016 ASCII HTML 32 NETCONF network management time clock synchronization

This document defines a capability-based extension to the Network Configuration Protocol (NETCONF) that allows time-triggered configuration and management operations. This extension allows NETCONF clients to invoke configuration updates according to scheduled times and allows NETCONF servers to attach timestamps to the data they send to NETCONF clients.

 draft-mm-netconf-time-capability-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC7758 RFC7759 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping E. Bellagamba G. Mirsky L. Andersson P. Skoldstrom D. Ward J. Drake February 2016 ASCII HTML 29 LSP-PING MPLS MPLS-TP OAM

This specification describes the configuration of proactive MPLS-TP Operations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the LSP Ping protocol.

 draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7759 RFC7760 Statement of Work for Extensions to the IETF Datatracker for Author Statistics R. Housley January 2016 ASCII HTML 8

This is the Statement of Work (SOW) for extensions to the IETF Datatracker to provide statistics about RFCs and Internet-Drafts and their authors.

 draft-housley-sow-author-statistics-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7760 RFC7761 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) B. Fenner M. Handley H. Holbrook I. Kouvelas R. Parekh Z. Zhang L. Zheng March 2016 ASCII HTML 137

This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.

This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.

 draft-ietf-pim-rfc4601bis-06 RFC4601 RFC8736 STD0083 INTERNET STANDARD INTERNET STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=7761 10.17487/RFC7761 RFC7762 Initial Assignment for the Content Security Policy Directives Registry M. West January 2016 ASCII HTML 5

This document establishes an Internet Assigned Number Authority (IANA) registry for Content Security Policy directives and populates that registry with the directives defined in the Content Security Policy Level 2 specification.

 draft-west-webappsec-csp-reg-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7762 RFC7763 The text/markdown Media Type S. Leonard March 2016 ASCII HTML 15

This document registers the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML.

 draft-ietf-appsawg-text-markdown-12 INFORMATIONAL INFORMATIONAL IETF art appsawg 10.17487/RFC7763 RFC7764 Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations S. Leonard March 2016 ASCII HTML 28 text/markdown

This document elaborates upon the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. Background information, local storage strategies, and additional syntax registrations are supplied.

 draft-ietf-appsawg-text-markdown-use-cases-07 INFORMATIONAL INFORMATIONAL IETF art appsawg 10.17487/RFC7764 RFC7765 TCP and Stream Control Transmission Protocol (SCTP) RTO Restart P. Hurtig A. Brunstrom A. Petlund M. Welzl February 2016 ASCII HTML 15 tcp retransmission timer rtor

This document describes a modified sender-side algorithm for managing the TCP and Stream Control Transmission Protocol (SCTP) retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer using a smaller timeout duration, so that the effective retransmission timeout (RTO) becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short lived or application limited.

 draft-ietf-tcpm-rtorestart-10 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC7765 RFC7766 DNS Transport over TCP - Implementation Requirements J. Dickinson S. Dickinson R. Bellis A. Mankin D. Wessels March 2016 ASCII HTML 19 DNS TCP/IP transport

This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.

 draft-ietf-dnsop-5966bis-06 RFC5966 RFC1035 RFC1123 RFC8490 RFC9103 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC7766 RFC7767 Application-Initiated Check-Pointing via the Port Control Protocol (PCP) S. Vinapamula S. Sivakumar M. Boucadair T. Reddy February 2016 ASCII HTML 12 serviceability SDN resilience robustness network programmability network API application control service-aware networking automation

This document specifies a mechanism for a host to indicate via the Port Control Protocol (PCP) which connections should be protected against network failures. These connections will then be subject to high-availability mechanisms enabled on the network side.

This approach assumes that applications and/or users have more visibility about sensitive connections than any heuristic that can be enabled on the network side to guess which connections should be check-pointed.

 draft-vinapamula-flow-ha-14 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7767 RFC7768 Port Management to Reduce Logging in Large-Scale NATs T. Tsou W. Li T. Taylor J. Huang January 2016 ASCII HTML 11

Various IPv6 transition strategies require the introduction of large- scale NATs (e.g., AFTR and NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete. There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address. One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers. It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs. This document suggests a way to achieve dynamic port sharing while keeping log volumes low.

 draft-tsou-behave-natx4-log-reduction-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7768 RFC7769 Media Access Control (MAC) Address Withdrawal over Static Pseudowire S. Sivabalan S. Boutros H. Shah S. Aldrin M. Venkatesan February 2016 ASCII HTML 10 PW ACH associated channel

This document specifies a mechanism to signal Media Access Control (MAC) address withdrawal notification using a pseudowire (PW) Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in a Virtual Private LAN Service (VPLS) or Hierarchical Virtual Private LAN Service (H-VPLS) environment.

 draft-ietf-pals-mpls-tp-mac-wd-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7769 RFC7770 Extensions to OSPF for Advertising Optional Router Capabilities A. Lindem Editor N. Shen JP. Vasseur R. Aggarwal S. Shaffer February 2016 ASCII HTML 15 ospfv2 ospfv3 open shortest path first ri router information lsa link state advertisement

It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.

 draft-ietf-ospf-rfc4970bis-07 RFC4970 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7770 RFC7771 Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires A. Malis Editor L. Andersson H. van Helvoort J. Shin L. Wang A. D'Alessandro January 2016 ASCII HTML 9 end-to-end protection linear protection

In MPLS and MPLS Transport Profile (MPLS-TP) environments, statically provisioned Single-Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection. With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures via MPLS-level and MPLS-TP-level tunnel protection. However, static MS-PWs are not protected end-to-end against failure of one of the Switching Provider Edge Routers (S-PEs) along the path of the MS-PW. This document describes how to achieve this protection via redundant MS-PWs by updating the existing procedures in RFC 6870. It also contains an optional approach based on MPLS-TP Linear Protection.

 draft-ietf-pals-ms-pw-protection-04 RFC6870 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7771 RFC7772 Reducing Energy Consumption of Router Advertisements A. Yourtchenko L. Colitti February 2016 ASCII HTML 6

Frequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact.

 draft-ietf-v6ops-reducing-ra-energy-consumption-03 BCP0202 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC7772 RFC7773 Authentication Context Certificate Extension S. Santesson March 2016 ASCII HTML 16

This document defines an extension to X.509 certificates. The extension defined in this document holds data about how the certificate subject was authenticated by the Certification Authority that issued the certificate in which this extension appears.

This document also defines one data structure for inclusion in this extension. The data structure is designed to hold information when the subject is authenticated using a Security Assertion Markup Language (SAML) assertion.

 draft-santesson-auth-context-extension-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7773 RFC7774 Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 Y. Doi M. Gillmore March 2016 ASCII HTML 10 MPL DHCPv6

This document defines a way to configure a parameter set for MPL (Multicast Protocol for Low-Power and Lossy Networks) via a DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL Forwarder in an MPL Domain. Using the MPL Parameter Configuration Option defined in this document, a network can easily be configured with a single set of MPL parameters.

 draft-ietf-roll-mpl-parameter-configuration-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=7774 10.17487/RFC7774 RFC7775 IS-IS Route Preference for Extended IP and IPv6 Reachability L. Ginsberg S. Litkowski S. Previdi February 2016 ASCII HTML 11

In existing specifications, the route preferences for IPv4/IPv6 Extended Reachability TLVs are not explicitly stated. There are also inconsistencies in the definition of how the up/down bit applies to route preference when the prefix advertisement appears in Level 2 Link State Protocol Data Units (LSPs). This document addresses these issues.

 draft-ietf-isis-route-preference-02 RFC5308 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7775 RFC7776 IETF Anti-Harassment Procedures P. Resnick A. Farrel March 2016 ASCII HTML 18 Ombudsman Ombudsperson Ombudsteam

IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy.

This document updates RFC 2418 by defining new working group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories.

 draft-farrresnickel-harassment-10 RFC2418 RFC8716 BCP0025 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7776 RFC7777 Advertising Node Administrative Tags in OSPF S. Hegde R. Shakir A. Smirnov Z. Li B. Decraene March 2016 ASCII HTML 15 open shortest path first

This document describes an extension to the OSPF protocol to add an optional operational capability that allows tagging and grouping of the nodes in an OSPF domain. This allows simplification, ease of management and control over route and path selection based on configured policies. This document describes an extension to the OSPF protocol to advertise node administrative tags. The node tags can be used to express and apply locally defined network policies, which are a very useful operational capability. Node tags may be used by either OSPF itself or other applications consuming information propagated via OSPF.

This document describes the protocol extensions to disseminate node administrative tags to the OSPFv2 and OSPFv3 protocol. It provides example use cases of administrative node tags.

 draft-ietf-ospf-node-admin-tag-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7777 RFC7778 Mobile Communication Congestion Exposure Scenario D. Kutscher F. Mir R. Winter S. Krishnan Y. Zhang CJ. Bernardos March 2016 ASCII HTML 25 congestion exposure mobile communications

This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPP Evolved Packet System (EPS). This memo provides a brief overview of the architecture of these networks (both access and core networks) and current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this discussion, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks.

 draft-ietf-conex-mobile-06 INFORMATIONAL INFORMATIONAL IETF tsv conex 10.17487/RFC7778 RFC7779 Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2) H. Rogge E. Baccelli April 2016 ASCII HTML 21 MANET metric ad hoc network routing IP networks OLSR ETT ETX Funkfeuer DAT

This document specifies a Directional Airtime (DAT) link metric for usage in Optimized Link State Routing version 2 (OLSRv2).

 draft-ietf-manet-olsrv2-dat-metric-12 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC7779 RFC7780 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates D. Eastlake 3rd M. Zhang R. Perlman A. Banerjee A. Ghanwani S. Gupta February 2016 ASCII HTML 57 TRILL RBridge IS-IS reachability overload MTU DEI multicast RPF color E-L1FS purge

Since the publication of the TRILL (Transparent Interconnection of Lots of Links) base protocol in 2011, active development and deployment of TRILL have revealed errata in RFC 6325 and areas that could use clarifications or updates. RFC 7177, RFC 7357, and an intended replacement of RFC 6439 provide clarifications and updates with respect to adjacency, the TRILL ESADI (End Station Address Distribution Information) protocol, and Appointed Forwarders, respectively. This document provides other known clarifications, corrections, and updates. It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and updates" RFC), and it updates RFCs 6325, 7177, and 7179.

 draft-ietf-trill-rfc7180bis-07 RFC7180 RFC6325 RFC7177 RFC7179 RFC8249 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7780 RFC7781 Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access H. Zhai T. Senevirathne R. Perlman M. Zhang Y. Li February 2016 ASCII HTML 35 virtual RBridge aggregation flip-flopping

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active access at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus as discussed in RFC 7379. In this document, the edge RBridge (Routing Bridge, or TRILL switch) group providing active-active access to such an end station is represented as a virtual RBridge. Based on the concept of the virtual RBridge, along with its pseudo-nickname, this document specifies a method for TRILL active-active access by such end stations.

 draft-ietf-trill-pseudonode-nickname-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7781 RFC7782 Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments M. Zhang R. Perlman H. Zhai M. Durrani S. Gupta February 2016 ASCII HTML 22 LAALP vSwitch MC-LAG DRNI

TRILL (Transparent Interconnection of Lots of Links) active-active service provides end stations with flow-level load balance and resilience against link failures at the edge of TRILL campuses, as described in RFC 7379.

This document specifies a method by which member RBridges (also referred to as Routing Bridges or TRILL switches) in an active-active edge RBridge group use their own nicknames as ingress RBridge nicknames to encapsulate frames from attached end systems. Thus, remote edge RBridges (who are not in the group) will see one host Media Access Control (MAC) address being associated with the multiple RBridges in the group. Such remote edge RBridges are required to maintain all those associations (i.e., MAC attachments) and to not flip-flop among them (as would occur prior to the implementation of this specification). The design goals of this specification are discussed herein.

 draft-ietf-trill-aa-multi-attach-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7782 RFC7783 Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL) T. Senevirathne J. Pathangi J. Hudson February 2016 ASCII HTML 16 Affinity RPF

TRILL (Transparent Interconnection of Lots of Links) facilitates loop-free connectivity to non-TRILL networks via a choice of an Appointed Forwarder for a set of VLANs. Appointed Forwarders provide VLAN-based load sharing with an active-standby model. High-performance applications require an active-active load-sharing model. The active-active load-sharing model can be accomplished by representing any given non-TRILL network with a single virtual RBridge (also referred to as a virtual Routing Bridge or virtual TRILL switch). Virtual representation of the non-TRILL network with a single RBridge poses serious challenges in multi-destination RPF (Reverse Path Forwarding) check calculations. This document specifies required enhancements to build Coordinated Multicast Trees (CMT) within the TRILL campus to solve related RPF issues. CMT, which only requires a software upgrade, provides flexibility to RBridges in selecting a desired path of association to a given TRILL multi-destination distribution tree. This document updates RFC 6325.

 draft-ietf-trill-cmt-11 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7783 RFC7784 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB D. Kumar S. Salam T. Senevirathne February 2016 ASCII HTML 50 CFM MEP MIP Fault Management

This document specifies the MIB for the OAM (Operations, Administration, and Maintenance) objects for IETF TRILL (Transparent Interconnection of Lots of Links).

 draft-ietf-trill-oam-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7784 RFC7785 Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite S. Vinapamula M. Boucadair February 2016 ASCII HTML 9 IPv4 service continuity IPv4 address exhaustion Service Availability High Availability Address sharing IPv6 Reliability IPv4 over IPv6 State migration Stability Disruption Privacy

This document discusses issues induced by the change of the Dual- Stack Lite (DS-Lite) Basic Bridging BroadBand (B4) IPv6 address and sketches a set of recommendations to solve those issues.

 draft-vinapamula-softwire-dslite-prefix-binding-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7785 RFC7786 TCP Modifications for Congestion Exposure (ConEx) M. Kuehlewind Editor R. Scheffenegger May 2016 ASCII HTML 20

Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP).

 draft-ietf-conex-tcp-modifications-10 EXPERIMENTAL EXPERIMENTAL IETF tsv conex 10.17487/RFC7786 RFC7787 Distributed Node Consensus Protocol M. Stenberg S. Barth April 2016 ASCII HTML 41 Homenet

This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol that uses the Trickle algorithm and hash trees. DNCP is an abstract protocol and must be combined with a specific profile to make a complete implementable protocol.

 draft-ietf-homenet-dncp-12 PROPOSED STANDARD PROPOSED STANDARD IETF int homenet 10.17487/RFC7787 RFC7788 Home Networking Control Protocol M. Stenberg S. Barth P. Pfister April 2016 ASCII HTML 40 IPv6 Homenet DNCP

This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol, and a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol that supports routing based on both the source and destination address.

 draft-ietf-homenet-hncp-10 RFC8375 PROPOSED STANDARD PROPOSED STANDARD IETF int homenet http://www.rfc-editor.org/errata_search.php?rfc=7788 10.17487/RFC7788 RFC7789 Impact of BGP Filtering on Inter-Domain Routing Policies C. Cardona P. Francois P. Lucente April 2016 ASCII HTML 16 More-specific prefix Less-specific prefix Autonomous systems Traffic engineering

This document describes how unexpected traffic flows can emerge across an autonomous system as the result of other autonomous systems filtering or restricting the propagation of more-specific prefixes. We provide a review of the techniques to detect the occurrence of this issue and defend against it.

 draft-ietf-grow-filtering-threats-08 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC7789 RFC7790 Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) Y. Yoneya T. Nemoto February 2016 ASCII HTML 10

The framework for the preparation, enforcement, and comparison of internationalized strings (PRECIS) defines several classes of strings for use in application protocols. Because many protocols perform case-sensitive or case-insensitive string comparison, it is necessary to define methods for case mapping. In addition, both the Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement describe mappings for internationalized strings that are not limited to case, but include width mapping and mapping of delimiters and other special characters that can be taken into consideration. This document provides guidelines for designers of PRECIS profiles and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. In particular, this document describes both locale-dependent and context-depending case mappings as well as additional mappings for delimiters and special characters.

 draft-ietf-precis-mappings-12 INFORMATIONAL INFORMATIONAL IETF art precis 10.17487/RFC7790 RFC7791 Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2) D. Migault Editor V. Smyslov March 2016 ASCII HTML 14 MIF Load balancing Load sharing MOBIKE

This document considers a VPN end user establishing an IPsec Security Association (SA) with a Security Gateway using the Internet Key Exchange Protocol version 2 (IKEv2), where at least one of the peers has multiple interfaces or where Security Gateway is a cluster with each node having its own IP address.

The protocol described allows a peer to clone an IKEv2 SA, where an additional SA is derived from an existing one. The newly created IKE SA is set without the IKEv2 authentication exchange. This IKE SA can later be assigned to another interface or moved to another cluster node.

 draft-mglt-ipsecme-clone-ike-sa-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7791 RFC7792 RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks F. Zhang X. Zhang A. Farrel O. Gonzalez de Dios D. Ceccarelli March 2016 ASCII HTML 12 Flexible-grid Flexible optical grid Optical network Optical trail Optical LSP GMPLS WDM PCE spectrum reservation flexible spectrum

This memo describes the extensions to the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid.

 draft-ietf-ccamp-flexible-grid-rsvp-te-ext-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7792 RFC7793 Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry M. Andrews May 2016 ASCII HTML 6

RFC 6598 specifies that "Reverse DNS queries for Shared Address Space addresses [100.64.0.0/10] MUST NOT be forwarded to the global DNS infrastructure."

This document formally directs IANA to add the associated zones to the "IPv4 Locally-Served DNS Zones Registry" to prevent such queries from accidentally leaking to the global DNS infrastructure.

 draft-ietf-dnsop-rfc6598-rfc6303-05 BCP0163 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC7793 RFC7794 IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability L. Ginsberg Editor B. Decraene S. Previdi X. Xu U. Chunduri March 2016 ASCII HTML 9 ISIS

This document introduces new sub-TLVs to support advertisement of IPv4 and IPv6 prefix attribute flags and the source router ID of the router that originated a prefix advertisement.

 draft-ietf-isis-prefix-attributes-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7794 RFC7795 Pseudowire Redundancy on the Switching Provider Edge (S-PE) J. Dong H. Wang February 2016 ASCII HTML 9

This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which pseudowire redundancy is provided on the Switching Provider Edge (S-PE) as defined in RFC 5659. Operations of the S-PEs that provide PW redundancy are specified in this document. Signaling of the Preferential Forwarding status as defined in RFCs 6870 and 6478 is reused. This document does not require any change to the Terminating Provider Edges (T-PEs) of MS-PW.

 draft-ietf-pals-redundancy-spe-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7795 RFC7796 Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) Y. Jiang Editor L. Yong M. Paul March 2016 ASCII HTML 26 Etree

This document specifies a generic Virtual Private LAN Service (VPLS) solution, which uses VLANs to indicate root or leaf traffic to support Ethernet-Tree (E-Tree) services. A VPLS Provider Edge (PE) model is illustrated as an example for the solution. In the solution, E-Tree VPLS PEs are interconnected by Pseudowires (PWs), which carry the VLAN indicating the E-Tree attribute. The MAC address-based Ethernet forwarding engine and the PW work in the same way as specified in RFC 4762 and RFC 4448, respectively. A signaling mechanism is described to support E-Tree capability and VLAN mapping negotiation.

 draft-ietf-l2vpn-vpls-pe-etree-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7796 RFC7797 JSON Web Signature (JWS) Unencoded Payload Option M. Jones February 2016 ASCII HTML 11 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS Digital Signature Message Authentication Code MAC Unencoded Payload

JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url- encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.

This specification updates RFC 7519 by stating that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification.

 draft-ietf-jose-jws-signing-input-options-09 RFC7519 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7797 RFC7798 RTP Payload Format for High Efficiency Video Coding (HEVC) Y.-K. Wang Y. Sanchez T. Schierl S. Wenger M. M. Hannuksela March 2016 ASCII HTML 86 H.265 : ISO/IEC 23008-2 Single NAL Unit Packet Aggregation Packet Fragmentation Unit Payload Content Information Packet Use of HEVC with Feedback Messages.

This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single stream as well as multiple RTP streams. When multiple RTP streams are used, a single transport or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.

 draft-ietf-payload-rtp-h265-15 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC7798 RFC7799 Active and Passive Metrics and Methods (with Hybrid Types In-Between) A. Morton May 2016 ASCII HTML 14 IP Performance Measurements Testing Network Characterization

This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge.

 draft-ietf-ippm-active-passive-06 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7799 RFC7800 Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) M. Jones J. Bradley H. Tschofenig April 2016 ASCII HTML 15 JSON Web Token JWT Proof-of-Possession Holder-of-Key

This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key.

 draft-ietf-oauth-proof-of-possession-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=7800 10.17487/RFC7800 RFC7801 GOST R 34.12-2015: Block Cipher "Kuznyechik" V. Dolmatov Editor March 2016 ASCII HTML 14 Kuznyechik Block Cipher

This document is intended to be a source of information about the Russian Federal standard GOST R 34.12-2015 describing the block cipher with a block length of n=128 bits and a key length of k=256 bits, which is also referred to as "Kuznyechik". This algorithm is one of the set of Russian cryptographic standard algorithms (called GOST algorithms).

 draft-dolmatov-kuznyechik-05 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7801 10.17487/RFC7801 RFC7802 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism S. Emery N. Williams March 2016 ASCII HTML 8

This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context.

This document obsoletes RFC 4402 and reclassifies that document as Historic. RFC 4402 starts the PRF+ counter at 1; however, a number of implementations start the counter at 0. As a result, the original specification would not be interoperable with existing implementations.

 draft-ietf-kitten-rfc4402bis-02 RFC4402 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC7802 RFC7803 Changing the Registration Policy for the NETCONF Capability URNs Registry B. Leiba February 2016 ASCII HTML 3

The registration policy for the "Network Configuration Protocol (NETCONF) Capability URNs" registry, set up by RFC 6241, has turned out to be unnecessarily strict. This document changes that registration policy to "IETF Review", allowing registrations from certain well-reviewed Experimental RFCs, in addition to Standards Track RFCs.

 draft-leiba-netmod-regpolicy-update-02 RFC6241 BCP0203 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7803 RFC7804 Salted Challenge Response HTTP Authentication Mechanism A. Melnikov March 2016 ASCII HTML 18 HTTPAUTH HTTP SASL SCRAM GS2 GSSAPI GSS-API

This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.

 draft-ietf-httpauth-scram-auth-15 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth http://www.rfc-editor.org/errata_search.php?rfc=7804 10.17487/RFC7804 RFC7805 Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status A. Zimmermann W. Eddy L. Eggert April 2016 ASCII HTML 8

This document reclassifies several TCP extensions and TCP-related documents that either have been superseded, have never seen widespread use, or are no longer recommended for use to "Historic" status. The affected documents are RFCs 675, 721, 761, 813, 816, 879, 896, 1078, and 6013. Additionally, this document reclassifies RFCs 700, 794, 814, 817, 872, 889, 964, and 1071 to "Informational" status.

 draft-ietf-tcpm-undeployed-03 RFC0675 RFC0721 RFC0761 RFC0813 RFC0816 RFC0879 RFC0896 RFC1078 RFC6013 RFC7414 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC7805 RFC7806 On Queuing, Marking, and Dropping F. Baker R. Pan April 2016 ASCII HTML 16

This note discusses queuing and marking/dropping algorithms. While these algorithms may be implemented in a coupled manner, this note argues that specifications, measurements, and comparisons should decouple the different algorithms and their contributions to system behavior.

 draft-ietf-aqm-fq-implementation-05 INFORMATIONAL INFORMATIONAL IETF tsv aqm 10.17487/RFC7806 RFC7807 Problem Details for HTTP APIs M. Nottingham E. Wilde March 2016 ASCII HTML 16 status HTTP error problem API JSON XML

This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.

 draft-ietf-appsawg-http-problem-03 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg http://www.rfc-editor.org/errata_search.php?rfc=7807 10.17487/RFC7807 RFC7808 Time Zone Data Distribution Service M. Douglass C. Daboo March 2016 ASCII HTML 56 time zone calendaring scheduling

This document defines a time zone data distribution service that allows reliable, secure, and fast delivery of time zone data and leap-second rules to client systems such as calendaring and scheduling applications or operating systems.

 draft-ietf-tzdist-service-11 PROPOSED STANDARD PROPOSED STANDARD IETF art tzdist 10.17487/RFC7808 RFC7809 Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference C. Daboo March 2016 ASCII HTML 13 CalDAV calendaring iCalendar time zone

This document defines an update to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) to allow clients and servers to exchange iCalendar data without the need to send full time zone data.

 draft-ietf-tzdist-caldav-timezone-ref-05 RFC4791 PROPOSED STANDARD PROPOSED STANDARD IETF art tzdist 10.17487/RFC7809 RFC7810 IS-IS Traffic Engineering (TE) Metric Extensions S. Previdi Editor S. Giacalone D. Ward J. Drake Q. Wu May 2016 ASCII HTML 18

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.

This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.

Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.

 draft-ietf-isis-te-metric-extensions-11 RFC8570 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=7810 10.17487/RFC7810 RFC7811 An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) G. Enyedi A. Csaszar A. Atlas C. Bowers A. Gopalan June 2016 ASCII HTML 118 MRT FRR LFA recovery failure routing

This document supports the solution put forth in "An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)" (RFC 7812) by defining the associated MRT Lowpoint algorithm that is used in the Default MRT Profile to compute both the necessary Maximally Redundant Trees with their associated next hops and the alternates to select for MRT-FRR.

 draft-ietf-rtgwg-mrt-frr-algorithm-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC7811 RFC7812 An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) A. Atlas C. Bowers G. Enyedi June 2016 ASCII HTML 44 MRT FRR LFA recovery failure routing

This document defines the architecture for IP and LDP Fast Reroute using Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology that gives link-protection and node-protection with 100% coverage in any network topology that is still connected after the failure.

 draft-ietf-rtgwg-mrt-frr-architecture-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC7812 RFC7813 IS-IS Path Control and Reservation J. Farkas Editor N. Bragg P. Unbehagen G. Parsons P. Ashwood-Smith C. Bowers June 2016 ASCII HTML 33 IS-IS SPB

IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest Path Bridging (SPB). IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain. This document specifies the sub-TLVs for IS-IS PCR.

 draft-ietf-isis-pcr-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7813 RFC7814 Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution X. Xu C. Jacquenet R. Raszuk T. Boyes B. Fee March 2016 ASCII HTML 15 Data Center Interconnect Data Center Network Virtual Machine (VM) migration

This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as "Virtual Subnet", which can be used for building Layer 3 network virtualization overlays within and/or between data centers.

 draft-ietf-bess-virtual-subnet-07 INFORMATIONAL INFORMATIONAL IETF rtg bess 10.17487/RFC7814 RFC7815 Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation T. Kivinen March 2016 ASCII HTML 41 IKE IPsec IoT Constrained

This document describes a minimal initiator version of the Internet Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations that can be done. The protocol described here is interoperable with a full IKEv2 implementation using shared secret authentication (IKEv2 does not require the use of certificate authentication). This minimal initiator implementation can only talk to a full IKEv2 implementation acting as the responder; thus, two minimal initiator implementations cannot talk to each other.

This document does not update or modify RFC 7296 but provides a more compact description of the minimal version of the protocol. If this document and RFC 7296 conflict, then RFC 7296 is the authoritative description.

 draft-ietf-lwig-ikev2-minimal-05 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC7815 RFC7816 DNS Query Name Minimisation to Improve Privacy S. Bortzmeyer March 2016 ASCII HTML 11

This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server.

 draft-ietf-dnsop-qname-minimisation-09 RFC9156 EXPERIMENTAL EXPERIMENTAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7816 10.17487/RFC7816 RFC7817 Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols A. Melnikov March 2016 ASCII HTML 13 SMTP Submission IMAP POP ManageSieve

This document describes the Transport Layer Security (TLS) server identity verification procedure for SMTP Submission, IMAP, POP, and ManageSieve clients. It replaces Section 2.4 (Server Identity Check) of RFC 2595 and updates Section 4.1 (Processing After the STARTTLS Command) of RFC 3207, Section 11.1 (STARTTLS Security Considerations) of RFC 3501, and Section 2.2.1 (Server Identity Check) of RFC 5804.

 draft-ietf-uta-email-tls-certs-09 RFC2595 RFC3207 RFC3501 RFC5804 PROPOSED STANDARD PROPOSED STANDARD IETF art uta 10.17487/RFC7817 RFC7818 URN Namespace for MEF Documents M. Jethanandani March 2016 ASCII HTML 5

This document describes the Namespace Identifier (NID) "mef" for Uniform Resource Names (URNs) used to identify resources published by MEF Forum (https://www.mef.net). MEF specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of the MEF Assigned Names and Numbers (MANN) registry.

 draft-mahesh-mef-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7818 RFC7819 Privacy Considerations for DHCP S. Jiang S. Krishnan T. Mrugalski April 2016 ASCII HTML 14 DHCP Privacy

DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts. This document discusses the various identifiers used by DHCP and the potential privacy issues.

 draft-ietf-dhc-dhcp-privacy-05 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC7819 RFC7820 UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) T. Mizrahi March 2016 ASCII HTML 15 Checksum UDP IPPM timestamping

The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP Checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations.

 draft-ietf-ippm-checksum-trailer-06 EXPERIMENTAL EXPERIMENTAL IETF tsv ippm 10.17487/RFC7820 RFC7821 UDP Checksum Complement in the Network Time Protocol (NTP) T. Mizrahi March 2016 ASCII HTML 14 NTP UDP Checksum timestamping

The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets of the packet rather than in the UDP Checksum field. The behavior defined in this document is interoperable with existing NTP implementations.

 draft-ietf-ntp-checksum-trailer-07 EXPERIMENTAL EXPERIMENTAL IETF int ntp 10.17487/RFC7821 RFC7822 Network Time Protocol Version 4 (NTPv4) Extension Fields T. Mizrahi D. Mayer March 2016 ASCII HTML 8 NTP extension field

The Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields. An extension field, as defined in RFC 5905, is an optional field that resides at the end of the NTP header and that can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes (MACs).

 draft-ietf-ntp-extension-field-07 RFC5905 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp 10.17487/RFC7822 RFC7823 Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions A. Atlas J. Drake S. Giacalone S. Previdi May 2016 ASCII HTML 10 Traffic Engineering Path Computation

In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE Label Switched Path (LSP). Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections.

 draft-ietf-teas-te-express-path-05 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC7823 RFC7824 Privacy Considerations for DHCPv6 S. Krishnan T. Mrugalski S. Jiang May 2016 ASCII HTML 18

DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts. This document describes the privacy issues associated with the use of DHCPv6 by Internet users. It is intended to be an analysis of the present situation and does not propose any solutions.

 draft-ietf-dhc-dhcpv6-privacy-05 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC7824 RFC7825 A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP) J. Goldberg M. Westerlund T. Zeng December 2016 ASCII HTML 33 ICE Media Delivery RTP RTCP D-ICE AVP AVPF SAVP SAVPF setup.ice-d-m rtsp-ice-d-m SDP

This document defines a solution for Network Address Translation (NAT) traversal for datagram-based media streams set up and controlled with the Real-Time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signaling channel, defining the necessary RTSP extensions and procedures.

 draft-ietf-mmusic-rtsp-nat-22 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC7825 RFC7826 Real-Time Streaming Protocol Version 2.0 H. Schulzrinne A. Rao R. Lanphier M. Westerlund M. Stiemerling Editor December 2016 ASCII HTML 318 mmusic RTSP RTSP/2.0 real-time streaming protocol

This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.

RTSP is an application-layer protocol for the setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions; provide a means for choosing delivery channels such as UDP, multicast UDP, and TCP; and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550).

 draft-ietf-mmusic-rfc2326bis-40 RFC2326 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC7826 RFC7827 The Role of the IRTF Chair L. Eggert March 2016 ASCII HTML 7

This document briefly describes the role of the Chair of the Internet Research Task Force (IRTF), discusses its duties, and outlines the skill set a candidate for the role should ideally have.

 draft-iab-irtf-chair-description-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7827 RFC7828 The edns-tcp-keepalive EDNS0 Option P. Wouters J. Abley S. Dickinson R. Bellis April 2016 ASCII HTML 11 long-lived dnssec DNS TCP/IP transport

DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds.

This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.

 draft-ietf-dnsop-edns-tcp-keepalive-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC7828 RFC7829 SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol Y. Nishida P. Natarajan A. Caro P. Amer K. Nielsen April 2016 ASCII HTML 23 SCTP Failover multipath multihoming Potentially Failed

The Stream Control Transmission Protocol (SCTP) supports multihoming. However, when the failover operation specified in RFC 4960 is followed, there can be significant delay and performance degradation in the data transfer path failover. This document specifies a quick failover algorithm and introduces the SCTP Potentially Failed (SCTP-PF) destination state in SCTP Path Management.

This document also specifies a dormant state operation of SCTP that is required to be followed by an SCTP-PF implementation, but it may equally well be applied by a standard SCTP implementation, as described in RFC 4960.

Additionally, this document introduces an alternative switchback operation mode called "Primary Path Switchover" that will be beneficial in certain situations. This mode of operation applies to both a standard SCTP implementation and an SCTP-PF implementation.

The procedures defined in the document require only minimal modifications to the specification in RFC 4960. The procedures are sender-side only and do not impact the SCTP receiver.

 draft-ietf-tsvwg-sctp-failover-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC7829 RFC7830 The EDNS(0) Padding Option A. Mayrhofer May 2016 ASCII HTML 5 Domain Name System DNS EDNS EDNS0 Security Encryption Padding

This document specifies the EDNS(0) "Padding" option, which allows DNS clients and servers to pad request and response messages by a variable number of octets.

 draft-ietf-dprive-edns0-padding-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dprive 10.17487/RFC7830 RFC7831 Application Bridging for Federated Access Beyond Web (ABFAB) Architecture J. Howlett S. Hartman H. Tschofenig J. Schaad May 2016 ASCII HTML 46 Federated Authentication AAA RADIUS Diameter GSS-API EAP SAML

Over the last decade, a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few building blocks in common.

This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non-federated access management, including the Remote Authentication Dial-In User Service (RADIUS), the Generic Security Service Application Program Interface (GSS-API), the Extensible Authentication Protocol (EAP), and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of Identity Providers, Relying Parties, and federations.

 draft-ietf-abfab-arch-13 INFORMATIONAL INFORMATIONAL IETF sec abfab 10.17487/RFC7831 RFC7832 Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases R. Smith Editor May 2016 ASCII HTML 13 Federated Authentication AAA RADIUS Diameter GSS-API EAP SASL

Federated identity is typically associated with web-based services at present, but there is growing interest in its application in non-web-based contexts. The goal of this memo is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the Application Bridging for Federated Access Beyond web (ABFAB) architecture and specifications.

 draft-ietf-abfab-usecases-05 INFORMATIONAL INFORMATIONAL IETF sec abfab 10.17487/RFC7832 RFC7833 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML) J. Howlett S. Hartman A. Perez-Mendez Editor May 2016 ASCII HTML 32 ABFAB AAA EAP RADIUS SAML

This document describes the use of the Security Assertion Markup Language (SAML) with RADIUS in the context of the Application Bridging for Federated Access Beyond web (ABFAB) architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. The RADIUS attributes permit encapsulation of SAML Assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion Query/Request, enabling a Relying Party to request authentication of, or assertions for, users or machines (clients). These clients may be named using a Network Access Identifier (NAI) name identifier format. Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. The use of the artifacts defined in this document is not exclusive to ABFAB. They can be applied in any Authentication, Authorization, and Accounting (AAA) scenario, such as network access control.

 draft-ietf-abfab-aaa-saml-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7833 RFC7834 Locator/ID Separation Protocol (LISP) Impact D. Saucez L. Iannone A. Cabellos F. Coras April 2016 ASCII HTML 18

The Locator/ID Separation Protocol (LISP) aims to improve the Internet routing scalability properties by leveraging three principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the routing infrastructure and the end user.

 draft-ietf-lisp-impact-05 INFORMATIONAL INFORMATIONAL IETF rtg lisp 10.17487/RFC7834 RFC7835 Locator/ID Separation Protocol (LISP) Threat Analysis D. Saucez L. Iannone O. Bonaventure April 2016 ASCII HTML 19

This document provides a threat analysis of the Locator/ID Separation Protocol (LISP).

 draft-ietf-lisp-threats-15 INFORMATIONAL INFORMATIONAL IETF rtg lisp 10.17487/RFC7835 RFC7836 Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012 S. Smyshlyaev Editor E. Alekseev I. Oshkin V. Popov S. Leontiev V. Podobaev D. Belyavsky March 2016 ASCII HTML 32 HMAC PRF key agreement VKO key exchange key derivation KDF key tree elliptic curve Weierstrass twisted Edwards TLS IPsec IKE IKEv2

The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standards GOST R 34.10-2012 and GOST R 34.11-2012 available to the Internet community for their implementation in the cryptographic protocols based on the accompanying algorithms.

These specifications define the pseudorandom functions, the key agreement algorithm based on the Diffie-Hellman algorithm and a hash function, the parameters of elliptic curves, the key derivation functions, and the key export functions.

 draft-smyshlyaev-gost-usage-19 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7836 10.17487/RFC7836 RFC7837 IPv6 Destination Option for Congestion Exposure (ConEx) S. Krishnan M. Kuehlewind B. Briscoe C. Ralli May 2016 ASCII HTML 13 Accountability Traffic Management Fairness Resource Sharing Congestion Control Quality of Service QoS Denial of Service

Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams.

 draft-ietf-conex-destopt-12 EXPERIMENTAL EXPERIMENTAL IETF tsv conex 10.17487/RFC7837 RFC7838 HTTP Alternative Services M. Nottingham P. McManus J. Reschke April 2016 ASCII HTML 20 HTTP ALPN Alternative Services

This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.

 draft-ietf-httpbis-alt-svc-14 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=7838 10.17487/RFC7838 RFC7839 Access-Network-Identifier Option in DHCP S. Bhandari S. Gundavelli M. Grayson B. Volz J. Korhonen June 2016 ASCII HTML 20 Operator-Realm Access-Network-Identifier Access-Technology-Type Access-Point BSSID Operator-Identifier DHCPv4 DHCPv6 Local Mobility Anchor (LMA) Proxy Mobile IPv6 (PMIPv6) Service Set Identifier (SSID)

This document specifies the format and mechanism that is to be used for encoding Access-Network Identifiers in DHCPv4 and DHCPv6 messages by defining new Access-Network-Identifier options and sub-options.

 draft-ietf-dhc-access-network-identifier-13 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=7839 10.17487/RFC7839 RFC7840 A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol J. Winterbottom H. Tschofenig L. Liess May 2016 ASCII HTML 16 Emergency Call Routing Location HELD

For cases where location servers have access to emergency routing information, they are able to return routing information with the location information if the location request includes a request for the desired routing information. This document specifies an extension to the HTTP-Enabled Location Delivery (HELD) protocol that updates RFC 5985 to support this function. Allowing location and routing information to be acquired in a single request response exchange updates RFC 6881, as current location acquisition and route determination procedures are separate operations.

 draft-ietf-ecrit-held-routing-05 RFC5985 RFC6881 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit 10.17487/RFC7840 RFC7841 RFC Streams, Headers, and Boilerplates J. Halpern Editor L. Daigle Editor O. Kolkman Editor May 2016 ASCII HTML 14

RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document obsoletes RFC 5741, moving detailed content to an IAB web page and preparing for more flexible output formats.

 draft-iab-rfc5741bis-02 RFC5741 RFC9280 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7841 10.17487/RFC7841 RFC7842 Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool R. Sparks April 2016 ASCII HTML 7

The web-based IETF email archive search tool based on the requirements captured in RFC 6778 was deployed in January 2014. This memo captures the requirements for a set of improvements that have been identified during its initial years of community use.

 draft-sparks-genarea-mailarch-improvements-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7842 RFC7843 Port Control Protocol (PCP) Third-Party ID Option A. Ripke R. Winter T. Dietz J. Quittek R. da Silva May 2016 ASCII HTML 14 PCP option third party ID

This document describes a new Port Control Protocol (PCP) option called the THIRD_PARTY_ID option. It is designed to be used together with the THIRD_PARTY option specified in RFC 6887.

The THIRD_PARTY_ID option serves to identify a third party in situations where a third party's IP address contained in the THIRD_PARTY option does not provide sufficient information to create requested mappings in a PCP-controlled device.

 draft-ietf-pcp-third-party-id-option-08 RFC6887 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7843 RFC7844 Anonymity Profiles for DHCP Clients C. Huitema T. Mrugalski S. Krishnan May 2016 ASCII HTML 26 DHCP DHCPv4 DHCPv6 pervasive monitoring fingerprinting privacy Anonymity MAC Address Randomization Privacy Surveillance

Some DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. The anonymity profiles are designed for clients that wish to remain anonymous to the visited network. The profiles provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information.

 draft-ietf-dhc-anonymity-profile-08 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7844 RFC7845 Ogg Encapsulation for the Opus Audio Codec T. Terriberry R. Lee R. Giles April 2016 ASCII HTML 35 container mapping

This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream.

 draft-ietf-codec-oggopus-14 RFC5334 RFC8486 PROPOSED STANDARD PROPOSED STANDARD IETF art codec 10.17487/RFC7845 RFC7846 Peer-to-Peer Streaming Tracker Protocol (PPSTP) R. Cruz M. Nunes J. Xia R. Huang Editor J. Taveira D. Lingli May 2016 ASCII HTML 55 structured media peer swarms control live streaming video on demand

This document specifies the base Peer-to-Peer Streaming Tracker Protocol (PPSTP) version 1, an application-layer control (signaling) protocol for the exchange of meta information between trackers and peers. The specification outlines the architecture of the protocol and its functionality; it also describes message flows, message processing instructions, message formats, formal syntax, and semantics. The PPSTP enables cooperating peers to form content-streaming overlay networks to support near real-time delivery of structured media content (audio, video, and associated timed text and metadata), such as adaptive multi-rate, layered (scalable), and multi-view (3D) videos in live, time-shifted, and on-demand modes.

 draft-ietf-ppsp-base-tracker-protocol-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ppsp 10.17487/RFC7846 RFC7847 Logical-Interface Support for IP Hosts with Multi-Access Support T. Melia Editor S. Gundavelli Editor May 2016 ASCII HTML 16 Logical-interface virtual-interface Logical interface

A logical interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. Logical-interface support is required on the mobile node attached to a Proxy Mobile IPv6 domain for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming, and flow mobility support. This document explains the operational details of the logical-interface construct and the specifics on how link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in conjunction with various mobility management features.

 draft-ietf-netext-logical-interface-support-14 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC7847 RFC7848 Mark and Signed Mark Objects Mapping G. Lozano June 2016 ASCII HTML 24 Trademark Clearinghouse Signed Mark Data Signed Mark Mark SMD

Domain Name Registries (DNRs) may operate in special modes for certain periods of time, enabling trademark holders to protect their rights during the introduction of a Top-Level Domain (TLD).

One of those special modes of operation is the Sunrise Period. The Sunrise Period allows trademark holders an advance opportunity to register domain names corresponding to their trademarks before names are generally available to the public.

This document describes the format of a mark and a digitally signed mark used by trademark holders for registering domain names during the Sunrise Period of generic Top-Level Domains (gTLDs). Three types of Mark objects are defined in this specification: registered trademarks, court-validated marks, and marks protected by statue or treaty.

 draft-ietf-eppext-tmch-smd-06 PROPOSED STANDARD PROPOSED STANDARD IETF art eppext http://www.rfc-editor.org/errata_search.php?rfc=7848 10.17487/RFC7848 RFC7849 An IPv6 Profile for 3GPP Mobile Devices D. Binet M. Boucadair A. Vizdal G. Chen N. Heatley R. Chandler D. Michaud D. Lopez W. Haeffner May 2016 ASCII HTML 22 IPv4 service continuity address shortage address depletion dual-stack IPv6-only IPv6 introduction IPv6 transition IPv6 migration cellular networks mobile networks PLMN and IPv6 configuration

This document defines a profile that is a superset of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document defines a profile that is a superset of the connections to IPv6 cellular networks defined in "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts" (RFC 7066).

Both mobile hosts and mobile devices with the capability to share their 3GPP mobile connectivity are in scope.

 draft-ietf-v6ops-mobile-device-profile-24 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7849 10.17487/RFC7849 RFC7850 Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles S. Nandakumar April 2016 ASCII HTML 7

The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods. This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', and 'TCP/TLS/RTP/AVPF'.

 draft-ietf-mmusic-proto-iana-registration-06 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC7850 RFC7851 Peer-to-Peer (P2P) Overlay Diagnostics H. Song X. Jiang R. Even D. Bryan Y. Sun May 2016 ASCII HTML 30 Real-time Applications and Infrastructure P2PSIP Working Group Diagnostics P2P P2PSIP

This document describes mechanisms for Peer-to-Peer (P2P) overlay diagnostics. It defines extensions to the REsource LOcation And Discovery (RELOAD) base protocol to collect diagnostic information and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics.

 draft-ietf-p2psip-diagnostics-22 PROPOSED STANDARD PROPOSED STANDARD IETF art p2psip 10.17487/RFC7851 RFC7852 Additional Data Related to an Emergency Call R. Gellens B. Rosen H. Tschofenig R. Marshall J. Winterbottom July 2016 ASCII HTML 113 Additional Call Data Emergency Services Call Information

When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here.

The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference.

 draft-ietf-ecrit-additional-data-38 RFC6443 RFC6881 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit http://www.rfc-editor.org/errata_search.php?rfc=7852 10.17487/RFC7852 RFC7853 A URN Namespace for Globus S. Martin S. Tuecke B. McCollam M. Lidman May 2016 ASCII HTML 7

This document describes a URN (Uniform Resource Name) namespace to be used by Globus for naming persistent resources.

 draft-martin-urn-globus-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7853 RFC7854 BGP Monitoring Protocol (BMP) J. Scudder Editor R. Fernando S. Stuart June 2016 ASCII HTML 27 IDR BGP GROW BMP

This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol.

 draft-ietf-grow-bmp-17 RFC8671 RFC9069 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=7854 10.17487/RFC7854 RFC7855 Source Packet Routing in Networking (SPRING) Problem Statement and Requirements S. Previdi Editor C. Filsfils Editor B. Decraene S. Litkowski M. Horneffer R. Shakir May 2016 ASCII HTML 19

The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols but have not seen widespread adoption. In this context, the term "source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network).

This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use cases and requirements are out of scope for this document.

 draft-ietf-spring-problem-statement-08 INFORMATIONAL INFORMATIONAL IETF rtg spring http://www.rfc-editor.org/errata_search.php?rfc=7855 10.17487/RFC7855 RFC7856 Softwire Mesh Management Information Base (MIB) Y. Cui J. Dong P. Wu M. Xu A. Yla-Jaaski May 2016 ASCII HTML 18 Management Information Base MIB SMIv2 mesh

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing a softwire mesh.

 draft-ietf-softwire-mesh-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC7856 RFC7857 Updates to Network Address Translation (NAT) Behavioral Requirements R. Penno S. Perreault M. Boucadair Editor S. Sivakumar K. Naito April 2016 ASCII HTML 14 address sharing IPv4 service continuity Carrier Grade NAT CGN LSN NAT traversal RFC4787 RFC5382 RFC5508 DS-Lite NAT64 Address depletion

This document clarifies and updates several requirements of RFCs 4787, 5382, and 5508 based on operational and development experience. The focus of this document is Network Address Translation from IPv4 to IPv4 (NAT44).

This document updates RFCs 4787, 5382, and 5508.

 draft-ietf-tsvwg-behave-requirements-update-08 RFC4787 RFC5382 RFC5508 BCP0127 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC7857 RFC7858 Specification for DNS over Transport Layer Security (TLS) Z. Hu L. Zhu J. Heidemann A. Mankin D. Wessels P. Hoffman May 2016 ASCII HTML 19 DNS encryption DNS privacy

This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.

This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.

 draft-ietf-dprive-dns-over-tls-09 RFC8310 PROPOSED STANDARD PROPOSED STANDARD IETF int dprive http://www.rfc-editor.org/errata_search.php?rfc=7858 10.17487/RFC7858 RFC7859 Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols C. Dearlove May 2016 ASCII HTML 17 Mobile Ad hoc Networking (MANET) MANET TLV OLSRv2 integrity check value ICV ECCSI elliptic curve identity-based signature IBS identity-based encryption IBE

This document extends RFC 7182, which specifies a framework for (and specific examples of) Integrity Check Values (ICVs) for packets and messages using the generalized packet/message format specified in RFC 5444. It does so by defining an additional cryptographic function that allows the creation of an ICV that is an Identity-Based Signature (IBS), defined according to the Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) algorithm specified in RFC 6507.

 draft-ietf-manet-ibs-05 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC7859 RFC7860 HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 J. Merkle Editor M. Lochter April 2016 ASCII HTML 14 SNMP USM HMAC SHA-2

This document specifies several authentication protocols based on the SHA-2 hash functions for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. It obsoletes RFC 7630, in which the MIB MODULE-IDENTITY value was incorrectly specified.

 draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-05 RFC7630 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC7860 RFC7861 Remote Procedure Call (RPC) Security Version 3 A. Adamson N. Williams November 2016 ASCII HTML 26 RPCSEC_GSS ONC RPC GSS GSS-API NFS authentication privacy confidentiality encryption mechanism context

This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS). This protocol provides support for multi-principal authentication of client hosts and user principals to a server (constructed by generic composition), security label assertions for multi-level security and type enforcement, structured privilege assertions, and channel bindings. This document updates RFC 5403.

 draft-ietf-nfsv4-rpcsec-gssv3-17 RFC5403 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7861 RFC7862 Network File System (NFS) Version 4 Minor Version 2 Protocol T. Haynes November 2016 ASCII HTML 104 NFSv4.2 pNFS Server-Side Copy Server-Side Clone Labeled NFS

This document describes NFS version 4 minor version 2; it describes the protocol extensions made from NFS version 4 minor version 1. Major extensions introduced in NFS version 4 minor version 2 include the following: Server-Side Copy, Application Input/Output (I/O) Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS.

 draft-ietf-nfsv4-minorversion2-41 RFC8178 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=7862 10.17487/RFC7862 RFC7863 Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description T. Haynes November 2016 ASCII HTML 87 NFSv4.2 XDR

This document provides the External Data Representation (XDR) description for NFS version 4 minor version 2.

 draft-ietf-nfsv4-minorversion2-dot-x-41 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7863 RFC7864 Proxy Mobile IPv6 Extensions to Support Flow Mobility CJ. Bernardos Editor May 2016 ASCII HTML 19 flow mobility NB-IFOM PMIPv6 FMI FMA

Proxy Mobile IPv6 (PMIPv6) allows a mobile node to connect to the same PMIPv6 domain through different interfaces. This document describes extensions to the PMIPv6 protocol that are required to support network-based flow mobility over multiple physical interfaces.

This document updates RFC 5213. The extensions described in this document consist of the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management.

 draft-ietf-netext-pmipv6-flowmob-18 RFC5213 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7864 RFC7865 Session Initiation Protocol (SIP) Recording Metadata R. Ravindranath P. Ravindran P. Kyzivat May 2016 ASCII HTML 34

Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by the Session Recording Server (SRS) and the recording metadata format.

 draft-ietf-siprec-metadata-22 PROPOSED STANDARD PROPOSED STANDARD IETF art siprec 10.17487/RFC7865 RFC7866 Session Recording Protocol L. Portman H. Lum Editor C. Eckel A. Johnston A. Hutton May 2016 ASCII HTML 45 siprec

This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real-time Transport Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. This document considers only active recording, where the SRC purposefully streams media to an SRS and all participating user agents (UAs) are notified of the recording. Passive recording, where a recording device detects media directly from the network (e.g., using port-mirroring techniques), is outside the scope of this document. In addition, lawful intercept is outside the scope of this document.

 draft-ietf-siprec-protocol-18 PROPOSED STANDARD PROPOSED STANDARD IETF art siprec 10.17487/RFC7866 RFC7867 RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications R. Huang July 2016 ASCII HTML 16

This document defines a new RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of loss concealment metrics for video applications of RTP.

 draft-ietf-xrblock-rtcp-xr-video-lc-06 PROPOSED STANDARD PROPOSED STANDARD IETF art xrblock 10.17487/RFC7867 RFC7868 Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP) D. Savage J. Ng S. Moore D. Slice P. Paluch R. White May 2016 ASCII HTML 80

This document describes the protocol design and architecture for Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a routing protocol based on Distance Vector technology. The specific algorithm used is called "DUAL", a Diffusing Update Algorithm as referenced in "Loop-Free Routing Using Diffusing Computations" (Garcia-Luna-Aceves 1993). The algorithm and procedures were researched, developed, and simulated by SRI International.

 draft-savage-eigrp-05 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7868 10.17487/RFC7868 RFC7869 The "vnc" URI Scheme D. Warden I. Iordanov May 2016 ASCII HTML 25 RFB Remote Framebuffer Virtual Network Computing

Virtual Network Computing (VNC) software provides remote desktop functionality. This document describes a Uniform Resource Identifier (URI) scheme enabling the launch of VNC clients from other applications. The scheme specifies parameters useful in securely connecting clients with remote hosts.

 draft-warden-appsawg-vnc-scheme-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7869 RFC7870 Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs) Y. Fu S. Jiang J. Dong Y. Chen June 2016 ASCII HTML 27 IPv6

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects for Address Family Transition Routers (AFTRs) of Dual-Stack Lite (DS-Lite).

 draft-ietf-softwire-dslite-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC7870 RFC7871 Client Subnet in DNS Queries C. Contavalli W. van der Gaast D. Lawrence W. Kumari May 2016 ASCII HTML 30 edns-client-subnet ECS DNS geolocation DNS load-balancing EDNS EDNS0 geolocation privacy

This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement.

 draft-ietf-dnsop-edns-client-subnet-08 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7871 10.17487/RFC7871 RFC7872 Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World F. Gont J. Linkova T. Chown W. Liu June 2016 ASCII HTML 15 packet drops

This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs.

 draft-ietf-v6ops-ipv6-ehs-in-real-world-02 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=7872 10.17487/RFC7872 RFC7873 Domain Name System (DNS) Cookies D. Eastlake 3rd M. Andrews May 2016 ASCII HTML 25 denial of service forgery cache poisoning off-path

DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.)

 draft-ietf-dnsop-cookies-10 RFC9018 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC7873 RFC7874 WebRTC Audio Codec and Processing Requirements JM. Valin C. Bran May 2016 ASCII HTML 7

This document outlines the audio codec and processing requirements for WebRTC endpoints.

 draft-ietf-rtcweb-audio-11 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC7874 RFC7875 Additional WebRTC Audio Codecs for Interoperability S. Proust Editor May 2016 ASCII HTML 12 WebRTC audio codec G.722 AMR AMR-WB

To ensure a baseline of interoperability between WebRTC endpoints, a minimum set of required codecs is specified. However, to maximize the possibility of establishing the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser.

This document provides some guidelines on the suitable codecs to be considered for WebRTC endpoints to address the use cases most relevant to interoperability.

 draft-ietf-rtcweb-audio-codecs-for-interop-06 INFORMATIONAL INFORMATIONAL IETF art rtcweb 10.17487/RFC7875 RFC7876 UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks S. Bryant S. Sivabalan S. Soni July 2016 ASCII HTML 10 MPLS

RFC 6374 defines a protocol for Packet Loss and Delay Measurement for MPLS networks (MPLS-PLDM). This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management Responses over an UDP/IP return path.

 draft-ietf-mpls-rfc6374-udp-return-path-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7876 RFC7877 Session Peering Provisioning Framework (SPPF) K. Cartwright V. Bhatia S. Ali D. Schwartz August 2016 ASCII HTML 57 SPPP SIP Peering SED Provisioning

This document specifies the data model and the overall structure for a framework to provision Session Establishment Data (SED) into Session Data Registries and SIP Service Provider (SSP) data stores. The framework is called the "Session Peering Provisioning Framework" (SPPF). The provisioned data is typically used by network elements for session establishment.

 draft-ietf-drinks-spp-framework-12 PROPOSED STANDARD PROPOSED STANDARD IETF art drinks 10.17487/RFC7877 RFC7878 Session Peering Provisioning (SPP) Protocol over SOAP K. Cartwright V. Bhatia J-F. Mule A. Mayrhofer August 2016 ASCII HTML 83 SPPP SIP Peering SED Provisioning

The Session Peering Provisioning Framework (SPPF) specifies the data model and the overall structure to provision Session Establishment Data (SED) into Session Data Registries and SIP Service Provider data stores. To utilize this framework, one needs a substrate protocol. Given that the Simple Object Access Protocol (SOAP) is currently widely used for messaging between elements of such provisioning systems, this document specifies the usage of SOAP (via HTTPS) as the substrate protocol for SPPF. The benefits include leveraging prevalent expertise and a higher probability that existing provisioning systems will be able to easily migrate to using an \%SPPF- based protocol.

 draft-ietf-drinks-spp-protocol-over-soap-09 PROPOSED STANDARD PROPOSED STANDARD IETF art drinks 10.17487/RFC7878 RFC7879 DTLS-SRTP Handling in SIP Back-to-Back User Agents R. Ravindranath T. Reddy G. Salgueiro V. Pascual P. Ravindran May 2016 ASCII HTML 13 Session Initiation Protocol B2BUA Secure Real-time Transport Datagram Transport Layer Security

Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) exist on the signaling and media paths between the endpoints. This document describes the behavior of B2BUAs when Secure Real-time Transport (SRTP) security context is set up with the Datagram Transport Layer Security (DTLS) protocol.

 draft-ietf-straw-b2bua-dtls-srtp-12 PROPOSED STANDARD PROPOSED STANDARD IETF art straw 10.17487/RFC7879 RFC7880 Seamless Bidirectional Forwarding Detection (S-BFD) C. Pignataro D. Ward N. Akiya M. Bhatia S. Pallagatti July 2016 ASCII HTML 24 BFD seamless BFD negotiation free segment routing IP

This document defines Seamless Bidirectional Forwarding Detection (S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.

This document updates RFC 5880.

 draft-ietf-bfd-seamless-base-11 RFC5880 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=7880 10.17487/RFC7880 RFC7881 Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS C. Pignataro D. Ward N. Akiya July 2016 ASCII HTML 8 BFD seamless BFD negotiation free label verification segment routing IP

This document defines procedures for using Seamless Bidirectional Forwarding Detection (S-BFD) in IPv4, IPv6, and MPLS environments.

 draft-ietf-bfd-seamless-ip-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC7881 RFC7882 Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases S. Aldrin C. Pignataro G. Mirsky N. Kumar July 2016 ASCII HTML 15 BFD seamless BFD negotiation free label verification segment routing IP

This document describes various use cases for Seamless Bidirectional Forwarding Detection (S-BFD) and provides requirements such that protocol mechanisms allow for simplified detection of forwarding failures.

These use cases support S-BFD, which is a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, accelerating the establishment of a BFD session. The benefits of S-BFD include quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.

 draft-ietf-bfd-seamless-use-case-08 INFORMATIONAL INFORMATIONAL IETF rtg bfd 10.17487/RFC7882 RFC7883 Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS L. Ginsberg N. Akiya M. Chen July 2016 ASCII HTML 5

This document defines a means of advertising one or more Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators using the IS-IS Router CAPABILITY TLV.

 draft-ietf-isis-sbfd-discriminator-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7883 RFC7884 OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators C. Pignataro M. Bhatia S. Aldrin T. Ranganath July 2016 ASCII HTML 7 BFD seamless BFD negotiation free label verification segment routing IP

This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood the Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator values associated with a target network identifier. This mechanism is applicable to both OSPFv2 and OSPFv3.

 draft-ietf-ospf-sbfd-discriminator-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7884 RFC7885 Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV) V. Govindan C. Pignataro July 2016 ASCII HTML 11 RFC5885 L2TPv3 VCCV S-BFD

This document defines Seamless BFD (S-BFD) for VCCV by extending the procedures and Connectivity Verification (CV) types already defined for Bidirectional Forwarding Detection (BFD) for Virtual Circuit Connectivity Verification (VCCV).

This document updates RFC 5885 by extending the CV Type values and the capability selection.

 draft-ietf-pals-seamless-vccv-03 RFC5885 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7885 RFC7886 Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3) V. Govindan C. Pignataro July 2016 ASCII HTML 6 S-BFD

This document defines a new Attribute-Value Pair (AVP) that allows L2TP Control Connection Endpoints (LCCEs) to advertise one or more Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator values using the Layer Two Tunneling Protocol version 3 (L2TPv3).

 draft-ietf-l2tpext-sbfd-discriminator-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2tpext 10.17487/RFC7886 RFC7887 Hierarchical Join/Prune Attributes S. Venaas J. Arango I. Kouvelas June 2016 ASCII HTML 8 multicast pim

This document defines a hierarchical method of encoding Join/Prune attributes that provides a more efficient encoding when the same attribute values need to be specified for multiple sources in a PIM Join/Prune message. This document updates RFC 5384 by renaming the encoding type registry specified there.

 draft-ietf-pim-hierarchicaljoinattr-08 RFC5384 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC7887 RFC7888 IMAP4 Non-synchronizing Literals A. Melnikov Editor May 2016 ASCII HTML 9 IMAP LITERAL+ LITERAL- APPENDLIMIT

The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal that does not require this network round trip.

This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. LITERAL+ allows the alternate form of literals in all IMAP commands. LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less.

This document obsoletes RFC 2088.

 draft-ietf-imapapnd-rfc2088bis-04 RFC2088 PROPOSED STANDARD PROPOSED STANDARD IETF art imapapnd 10.17487/RFC7888 RFC7889 The IMAP APPENDLIMIT Extension J. SrimushnamBoovaraghamoorthy N. Bisht May 2016 ASCII HTML 7

This document defines an extension to the IMAP service whereby a server can inform the client about maximum message upload sizes, allowing the client to avoid sending APPEND commands that will fail because the messages are too large.

 draft-ietf-imapapnd-appendlimit-extension-10 PROPOSED STANDARD PROPOSED STANDARD IETF art imapapnd http://www.rfc-editor.org/errata_search.php?rfc=7889 10.17487/RFC7889 RFC7890 Concepts and Terminology for Peer-to-Peer SIP (P2PSIP) D. Bryan P. Matthews E. Shim D. Willis S. Dawkins June 2016 ASCII HTML 19 Distributed Database P2PSIP SIP Server-less DHT

This document defines concepts and terminology for using the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message-routing functions are replaced by a distributed mechanism. These mechanisms may be implemented using a Distributed Hash Table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group, the REsource LOcation And Discovery (RELOAD) protocol, and the SIP usage document defined by the working group.

 draft-ietf-p2psip-concepts-09 INFORMATIONAL INFORMATIONAL IETF art p2psip 10.17487/RFC7890 RFC7891 Explicit Reverse Path Forwarding (RPF) Vector J. Asghar IJ. Wijnands Editor S. Krishnaswamy A. Karan V. Arya June 2016 ASCII HTML 9 Path diversity MoFRR Maximally redundant paths

The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 can be included in a PIM Join Attribute such that the RPF neighbor is selected based on the unicast reachability of the RPF Vector instead of the source or Rendezvous Point associated with the multicast tree.

This document defines a new RPF Vector Attribute type such that an explicit RPF neighbor list can be encoded in the PIM Join Attribute, thus bypassing the unicast route lookup.

 draft-ietf-pim-explicit-rpf-vector-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC7891 RFC7892 IANA Allocation Procedures for the GMPLS OTN Signal Type Registry Z. Ali A. Bonfanti M. Hartley F. Zhang May 2016 ASCII HTML 4

IANA defined the "OTN Signal Type" subregistry of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry in RFC 7139. This document updates the "OTN Signal Type" subregistry to allow registration via Specification Required.

 draft-ietf-ccamp-otn-signal-type-subregistry-05 RFC7139 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7892 RFC7893 Pseudowire Congestion Considerations Y(J) Stein D. Black B. Briscoe June 2016 ASCII PDF HTML 27 pseudowire congestion TCP friendliness

Pseudowires (PWs) have become a common mechanism for tunneling traffic and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. Thus, it is worthwhile specifying under what conditions such competition is acceptable, i.e., the PW traffic does not significantly harm other traffic or contribute more than it should to congestion. We conclude that PWs transporting responsive traffic behave as desired without the need for additional mechanisms. For inelastic PWs (such as Time Division Multiplexing (TDM) PWs), we derive a bound under which such PWs consume no more network capacity than a TCP flow. For TDM PWs, we find that the level of congestion at which the PW can no longer deliver acceptable TDM service is never significantly greater, and is typically much lower, than this bound. Therefore, as long as the PW is shut down when it can no longer deliver acceptable TDM service, it will never do significantly more harm than even a single TCP flow. If the TDM service does not automatically shut down, a mechanism to block persistently unacceptable TDM pseudowires is required.

 draft-ietf-pals-congcons-02 INFORMATIONAL INFORMATIONAL IETF rtg pals 10.17487/RFC7893 RFC7894 Alternative Challenge Password Attributes for Enrollment over Secure Transport M. Pritikin C. Wallace June 2016 ASCII HTML 10 Enrollment over Secure Transport

This document defines a set of new Certificate Signing Request attributes for use with the Enrollment over Secure Transport (EST) protocol. These attributes provide disambiguation of the existing overloaded uses for the challengePassword attribute defined in "PKCS #9: Selected Object Classes and Attribute Types Version 2.0" (RFC 2985). Uses include the original certificate revocation password, common authentication password uses, and EST-defined linking of transport security identity.

 draft-wallace-est-alt-challenge-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7894 RFC7895 YANG Module Library A. Bierman M. Bjorklund K. Watsen June 2016 ASCII HTML 13 NETCONF RESTCONF

This document describes a YANG library that provides information about all the YANG modules used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server). Simple caching mechanisms are provided to allow clients to minimize retrieval of this information.

 draft-ietf-netconf-yang-library-06 RFC8525 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC7895 RFC7896 Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP) D. Dhody June 2016 ASCII HTML 5 PCEP PCE IRO

The Path Computation Element Communication Protocol (PCEP) enables communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. RFC 5440 defines the Include Route Object (IRO) to specify network elements to be traversed in the computed path. The specification does not specify if the IRO contains an ordered or unordered list of subobjects. During recent discussions, it was determined that there was a need to define a standard representation to ensure interoperability. It was also noted that there is a benefit in the handling of an attribute of the IRO's subobject, the L bit.

This document updates RFC 5440 regarding the IRO specification.

 draft-ietf-pce-iro-update-07 RFC5440 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC7896 RFC7897 Domain Subobjects for the Path Computation Element Communication Protocol (PCEP) D. Dhody U. Palle R. Casellas June 2016 ASCII HTML 35 PCEP PCE domain subobjects

The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). This document specifies a representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by Path Computation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains. This document also defines new subobjects to be used to encode domain identifiers.

 draft-ietf-pce-pcep-domain-sequence-12 EXPERIMENTAL EXPERIMENTAL IETF rtg pce 10.17487/RFC7897 RFC7898 Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE) D. Dhody U. Palle V. Kondreddy R. Casellas June 2016 ASCII HTML 18 RSVP-TE domain subobjects

The Resource Reservation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further, Exclude Route extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup.

This document specifies new subobjects to include or exclude Autonomous Systems (ASes), which are identified by a 4-byte AS number, and Interior Gateway Protocol (IGP) areas during path setup.

 draft-ietf-teas-rsvp-te-domain-subobjects-05 EXPERIMENTAL EXPERIMENTAL IETF rtg teas 10.17487/RFC7898 RFC7899 Multicast VPN State Damping T. Morin Editor S. Litkowski K. Patel Z. Zhang R. Kebler J. Haas June 2016 ASCII HTML 18 dampening multicast vpn damping bgp pim

This document describes procedures to damp Multicast VPN (MVPN) routing state changes and control the effect of the churn due to the multicast dynamicity in customer sites. The procedures described in this document are applicable to BGP-based multicast VPN and help avoid uncontrolled control-plane load increase in the core routing infrastructure. The new procedures proposed were inspired by BGP unicast route damping principles that have been adapted to multicast.

 draft-ietf-bess-multicast-damping-06 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7899 RFC7900 Extranet Multicast in BGP/IP MPLS VPNs Y. Rekhter Editor E. Rosen Editor R. Aggarwal Y. Cai T. Morin June 2016 ASCII HTML 65 Multicast

Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service.

 draft-ietf-bess-mvpn-extranet-07 RFC6513 RFC6514 RFC6625 RFC8534 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7900 RFC7901 CHAIN Query Requests in DNS P. Wouters June 2016 ASCII HTML 16 DNSSEC EDNS0 latency

This document defines an EDNS0 extension that can be used by a security-aware validating resolver configured to use a forwarding resolver to send a single query, requesting a complete validation path along with the regular query answer. The reduction in queries potentially lowers the latency and reduces the need to send multiple queries at once. This extension mandates the use of source-IP- verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot be abused in amplification attacks.

 draft-ietf-dnsop-edns-chain-query-07 EXPERIMENTAL EXPERIMENTAL IETF ops dnsop 10.17487/RFC7901 RFC7902 Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags E. Rosen T. Morin June 2016 ASCII HTML 7

The BGP-based control procedures for Multicast Virtual Private Networks (MVPNs) make use of a BGP attribute known as the "P-Multicast Service Interface (PMSI) Tunnel" attribute. The attribute contains a one-octet "Flags" field. The purpose of this document is to establish an IANA registry for the assignment of the bits in this field. Since the "Flags" field contains only eight bits, this document also defines a new BGP Extended Community, "Additional PMSI Tunnel Attribute Flags", that can be used to carry additional flags for the "P-Multicast Service Interface (PMSI) Tunnel" attribute. This document updates RFC 6514.

 draft-ietf-bess-pta-flags-03 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7902 RFC7903 Windows Image Media Types S. Leonard September 2016 ASCII HTML 12

This document registers media types for certain image formats promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, image/emf, image/x-emf, and image/bmp for use with Windows Metafile, Enhanced Metafile, and Windows Bitmap formats. Originally designed for Microsoft Windows 2.0 and 3.0, these image files are intended to be portable between applications and devices, and they may contain both vector and raster graphics.

 draft-seantek-windows-image-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7903 RFC7904 A SIP Usage for REsource LOcation And Discovery (RELOAD) C. Jennings B. Lowekamp E. Rescorla S. Baset H. Schulzrinne T. Schmidt Editor October 2016 ASCII HTML 20 p2psip p2p sip reload peer-to-peer session initiation distributed session management overlay network SIP registrar

This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a Peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged.

 draft-ietf-p2psip-sip-21 PROPOSED STANDARD PROPOSED STANDARD IETF art p2psip 10.17487/RFC7904 RFC7905 ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) A. Langley W. Chang N. Mavrogiannopoulos J. Strombergson S. Josefsson June 2016 ASCII HTML 8 AEAD DTLS

This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.

This document updates RFCs 5246 and 6347.

 draft-ietf-tls-chacha20-poly1305-04 RFC5246 RFC6347 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7905 10.17487/RFC7905 RFC7906 NSA's Cryptographic Message Syntax (CMS) Key Management Attributes P. Timmel R. Housley S. Turner June 2016 ASCII HTML 68

This document defines key management attributes used by the National Security Agency (NSA). The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic Message Syntax (CMS) content types that subsequently envelope the key packages. Key packages described in RFCs 5958 and 6031 are examples of where these attributes can be used.

 draft-turner-km-attributes-07 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7906 10.17487/RFC7906 RFC7907 RFC7908 Problem Definition and Classification of BGP Route Leaks K. Sriram D. Montgomery D. McPherson E. Osterweil B. Dickson June 2016 ASCII HTML 11 BGP BGPSEC Route Leak Route Leak Detection Route Leak Mitigation BGP Security

A systemic vulnerability of the Border Gateway Protocol routing system, known as "route leaks", has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled route leaks, but to date a common definition of the term has been lacking. This document provides a working definition of route leaks while keeping in mind the real occurrences that have received significant attention. Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to the Internet user community as well as the network operator community.

 draft-ietf-grow-route-leak-problem-definition-06 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC7908 RFC7909 Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures R. Kisteleki B. Haberman June 2016 ASCII HTML 14

This document describes a method that allows parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications of such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have authentication (based on Routing Policy System Security) of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. This document updates RFCs 2622 and 4012 to add the signature attribute to supported RPSL objects.

 draft-ietf-sidr-rpsl-sig-12 RFC2622 RFC4012 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC7909 RFC7910 Interoperability between the Virtual Router Redundancy Protocol and PIM W. Zhou June 2016 ASCII HTML 6

This document introduces VRRP-aware PIM, a redundancy mechanism for the Protocol Independent Multicast (PIM) to interoperate with the Virtual Router Redundancy Protocol (VRRP). It allows PIM to track VRRP state and to preserve multicast traffic upon failover in a redundant network with virtual routing groups enabled. The mechanism described in this document is based on Cisco IOS software implementation.

 draft-zhou-pim-vrrp-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7910 RFC7911 Advertisement of Multiple Paths in BGP D. Walton A. Retana E. Chen J. Scudder July 2016 ASCII HTML 8 border gateway protocol

This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a Path Identifier in addition to the address prefix.

 draft-ietf-idr-add-paths-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7911 RFC7912 Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure A. Melnikov June 2016 ASCII HTML 11 MMHS S/MIME MIXER email

This document describes a procedure for when a Military Message Handling System (MMHS) message is composed by one user and is only released to the mail transfer system when one or more Authorizing Users authorize release of the message by adding the MMHS-Authorizing-Users header field. The resulting message can be optionally signed by the sender and/or reviewer, allowing recipients to verify both the original signature (if any) and the review signatures.

 draft-melnikov-mmhs-authorizing-users-14 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7912 RFC7913 P-Access-Network-Info ABNF Update C. Holmberg June 2016 ASCII HTML 4 Transport PANI ABNF P-Access-Network-Info 3GPP IMS

This document updates RFC 7315, by modifying the extension-access- info part of the P-Access-Network-Info header field Augmented Backus- Naur Form (ABNF), and by adding the following 'access-info' header field parameter values to the list of 'access-info' header field parameter values in the ABNF: 'operator-specific-GI' and 'utran-sai-3gpp'. The values are defined in the ABNF but are not included in the list.

 draft-holmberg-dispatch-pani-abnf-03 RFC7315 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7913 10.17487/RFC7913 RFC7914 The scrypt Password-Based Key Derivation Function C. Percival S. Josefsson August 2016 ASCII HTML 16 PBKDF

This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema.

 draft-josefsson-scrypt-kdf-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7914 10.17487/RFC7914 RFC7915 IP/ICMP Translation Algorithm C. Bao X. Li F. Baker T. Anderson F. Gont June 2016 ASCII HTML 34 SIIT internet protocol control message IPv4 IPv6 Stateless IP/ICMP Translation Algorithm RFC6145bis

This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 6145.

 draft-bao-v6ops-rfc6145bis-07 RFC6145 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7915 10.17487/RFC7915 RFC7916 Operational Management of Loop-Free Alternates S. Litkowski Editor B. Decraene C. Filsfils K. Raza M. Horneffer P. Sarkar July 2016 ASCII HTML 31 IGP LFA policy FRR fast reroute network planning

Loop-Free Alternates (LFAs), as defined in RFC 5286, constitute an IP Fast Reroute (IP FRR) mechanism enabling traffic protection for IP traffic (and, by extension, MPLS LDP traffic). Following early deployment experiences, this document provides operational feedback on LFAs, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications.

This proposal is also applicable to remote-LFA solutions.

 draft-ietf-rtgwg-lfa-manageability-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC7916 RFC7917 Advertising Node Administrative Tags in IS-IS P. Sarkar Editor H. Gredler S. Hegde S. Litkowski B. Decraene July 2016 ASCII HTML 11 IGP IS-IS Admin-Tag Traffic Engineering

This document describes an extension to the IS-IS routing protocol to advertise node administrative tags. This optional capability allows tagging and grouping of the nodes in an IS-IS domain. The node administrative tags can be used to express and apply locally defined network policies, thereby providing a very useful operational capability. Node administrative tags may be used by either IS-IS itself or other applications consuming information propagated via IS-IS.

 draft-ietf-isis-node-admin-tag-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7917 RFC7918 Transport Layer Security (TLS) False Start A. Langley N. Modadugu B. Moeller August 2016 ASCII HTML 11

This document specifies an optional behavior of Transport Layer Security (TLS) client implementations, dubbed "False Start". It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip.

 draft-ietf-tls-falsestart-02 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC7918 RFC7919 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) D. Gillmor August 2016 ASCII HTML 29 Diffie-Hellman Discrete Logarithm Finite Field Transport Layer Security TLS Negotiation

Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.

This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) extensions (RFC 4492).

 draft-ietf-tls-negotiated-ff-dhe-10 RFC2246 RFC4346 RFC4492 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7919 10.17487/RFC7919 RFC7920 Problem Statement for the Interface to the Routing System A. Atlas Editor T. Nadeau Editor D. Ward June 2016 ASCII HTML 12

Traditionally, routing systems have implemented routing and signaling (e.g., MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies. Requirements have emerged to more dynamically manage and program routing systems due to the advent of highly dynamic data-center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via traffic control, and a paradigm of separating policy-based decision-making from the router itself. These requirements should allow controlling routing information and traffic paths and extracting network topology information, traffic statistics, and other network analytics from routing systems.

This document proposes meeting this need via an Interface to the Routing System (I2RS).

 draft-ietf-i2rs-problem-statement-11 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC7920 RFC7921 An Architecture for the Interface to the Routing System A. Atlas J. Halpern S. Hares D. Ward T. Nadeau June 2016 ASCII HTML 40

This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the high-level architecture, the building blocks of this high-level architecture, and their interfaces, with particular focus on those to be standardized as part of the Interface to the Routing System (I2RS).

 draft-ietf-i2rs-architecture-15 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC7921 RFC7922 Interface to the Routing System (I2RS) Traceability: Framework and Information Model J. Clarke G. Salgueiro C. Pignataro June 2016 ASCII HTML 17 I2RS I2RS Traceability I2RS Traceability

This document describes a framework for traceability in the Interface to the Routing System (I2RS) and the information model for that framework. It specifies the motivation, requirements, and use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes.

 draft-ietf-i2rs-traceability-11 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC7922 RFC7923 Requirements for Subscription to YANG Datastores E. Voit A. Clemm A. Gonzalez Prieto June 2016 ASCII HTML 18 pub/sub push updates

This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e., Network Configuration Protocol (NETCONF) and RESTCONF). Such a service can be summarized as a "pub/sub" service for YANG datastore updates. Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees.

 draft-ietf-i2rs-pub-sub-requirements-09 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC7923 RFC7924 Transport Layer Security (TLS) Cached Information Extension S. Santesson H. Tschofenig July 2016 ASCII HTML 19 TLS Cached Information TLS Cached Info TLS Extension TLS Optimization

Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).

This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information.

 draft-ietf-tls-cached-info-23 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7924 RFC7925 Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things H. Tschofenig Editor T. Fossati July 2016 ASCII HTML 61 Internet of Things Security TLS Profile DTLS Profile IoT Security DTLS over SMS

A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.

This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.

 draft-ietf-dice-profile-17 PROPOSED STANDARD PROPOSED STANDARD IETF sec dice 10.17487/RFC7925 RFC7926 Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks A. Farrel Editor J. Drake N. Bitar G. Swallow D. Ceccarelli X. Zhang July 2016 ASCII HTML 67 Abstract link Abstract node Abstraction Abstraction layer Aggregation Virtual node Virtual link

In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System.

In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information.

This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability.

 draft-ietf-teas-interconnected-te-info-exchange-07 BCP0206 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg teas 10.17487/RFC7926 RFC7927 Information-Centric Networking (ICN) Research Challenges D. Kutscher Editor S. Eum K. Pentikousis I. Psaras D. Corujo D. Saucez T. Schmidt M. Waehlisch July 2016 ASCII HTML 38 Information centric networking

This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching. Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management.

This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).

 draft-irtf-icnrg-challenges-06 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7927 RFC7928 Characterization Guidelines for Active Queue Management (AQM) N. Kuhn Editor P. Natarajan Editor N. Khademi Editor D. Ros July 2016 ASCII HTML 37

Unmanaged large buffers in today's networks have given rise to a slew of performance issues. These performance issues can be addressed by some form of Active Queue Management (AQM) mechanism, optionally in combination with a packet-scheduling scheme such as fair queuing. This document describes various criteria for performing characterizations of AQM schemes that can be used in lab testing during development, prior to deployment.

 draft-ietf-aqm-eval-guidelines-13 INFORMATIONAL INFORMATIONAL IETF tsv aqm 10.17487/RFC7928 RFC7929 DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP P. Wouters August 2016 ASCII HTML 20 opportunistic security encrypted email

OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities (DANE) is a method for publishing public keys in DNS. This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS resource record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the "web of trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted.

 draft-ietf-dane-openpgpkey-12 EXPERIMENTAL EXPERIMENTAL IETF sec dane http://www.rfc-editor.org/errata_search.php?rfc=7929 10.17487/RFC7929 RFC7930 Larger Packets for RADIUS over TCP S. Hartman August 2016 ASCII HTML 10 ABFAB

The RADIUS-over-TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of a RADIUS packet proves problematic. This specification extends the RADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action that required IESG approval.

 draft-ietf-radext-bigger-packets-07 RFC6613 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC7930 RFC7931 NFSv4.0 Migration: Specification Update D. Noveck Editor P. Shivam C. Lever B. Baker July 2016 ASCII HTML 55

The migration feature of NFSv4 allows the transfer of responsibility for a single file system from one server to another without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature in NFSv4.0. This document identifies the problem areas and provides revised specification text that updates the NFSv4.0 specification in RFC 7530.

 draft-ietf-nfsv4-rfc3530-migration-update-08 RFC7530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=7931 10.17487/RFC7931 RFC7932 Brotli Compressed Data Format J. Alakuijala Z. Szabadka July 2016 ASCII HTML 128

This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.

 draft-alakuijala-brotli-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7932 10.17487/RFC7932 RFC7933 Adaptive Video Streaming over Information-Centric Networking (ICN) C. Westphal Editor S. Lederer D. Posch C. Timmerer A. Azgin W. Liu C. Mueller A. Detti D. Corujo J. Wang M. Montpetit N. Murray August 2016 ASCII HTML 40 ICN CCN NDN DASH adaptive video streaming scalable video streaming IPTV P2P DRM

This document considers the consequences of moving the underlying network architecture from the current Internet to an Information- Centric Networking (ICN) architecture on video distribution. As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms. Several important topics related to video distribution over ICN are presented. The wide range of scenarios covered includes the following: evolving Dynamic Adaptive Streaming over HTTP (DASH) to work over ICN and leverage the recent ISO/IEC Moving Picture Experts Group (MPEG) standard, layering encoding over ICN, introducing distinct requirements for video using Peer-to-Peer (P2P) mechanisms, adapting the Peer-to-Peer Streaming Protocol (PPSP) for ICN, creating more stringent requirements over ICN because of delay constraints added by Internet Protocol Television (IPTV), and managing digital rights in ICN. Finally, in addition to considering how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN-specific video streaming mechanisms.

 draft-irtf-icnrg-videostreaming-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7933 RFC7934 Host Address Availability Recommendations L. Colitti V. Cerf S. Cheshire D. Schinazi July 2016 ASCII HTML 15 IPv6 IPv4 SLAAC DHCPv6 Prefix Delegation NAT NAT64 464XLAT /64 Address Assignment Addressing

This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and it describes the benefits of and the options for doing so.

 draft-ietf-v6ops-host-addr-availability-07 BCP0204 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=7934 10.17487/RFC7934 RFC7935 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure G. Huston G. Michaelson Editor August 2016 ASCII HTML 9

This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures.

 draft-ietf-sidr-rfc6485bis-05 RFC6485 RFC8208 RFC8608 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=7935 10.17487/RFC7935 RFC7936 Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry T. Hardie July 2016 ASCII HTML 3

This document clarifies the instructions to IANA for the subprotocol registry set up for WebSockets in RFC 6455.

 draft-hardie-rfc6455-iana-clarification-03 RFC6455 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7936 RFC7937 Content Distribution Network Interconnection (CDNI) Logging Interface F. Le Faucheur Editor G. Bertrand Editor I. Oprescu Editor R. Peterkofsky August 2016 ASCII HTML 63 CDNI Logging CDN Interconnection

This memo specifies the Logging interface between a downstream Content Distribution Network (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files.

 draft-ietf-cdni-logging-27 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni 10.17487/RFC7937 RFC7938 Use of BGP for Routing in Large-Scale Data Centers P. Lapukhov A. Premji J. Mitchell Editor August 2016 ASCII HTML 35 BGP ECMP Clos

Some network operators build and operate data centers that support over one hundred thousand servers. In this document, such data centers are referred to as "large-scale" to differentiate them from smaller infrastructures. Environments of this scale have a unique set of network requirements with an emphasis on operational simplicity and network stability. This document summarizes operational experience in designing and operating large-scale data centers using BGP as the only routing protocol. The intent is to report on a proven and stable routing design that could be leveraged by others in the industry.

 draft-ietf-rtgwg-bgp-routing-large-dc-11 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg http://www.rfc-editor.org/errata_search.php?rfc=7938 10.17487/RFC7938 RFC7939 Definition of Managed Objects for the Neighborhood Discovery Protocol U. Herberg R. Cole I. Chakeres T. Clausen August 2016 ASCII HTML 72 Network Management Management Information Base MIB SMIv2 Routing Neighbor Discovery MANET NHDP-MIB

This document replaces RFC 6779; it contains revisions and extensions to the original document. It defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The extensions described in this document add objects and values to support the NHDP optimization specified in RFC 7466. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery.

 draft-ietf-manet-rfc6779bis-07 RFC6779 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7939 RFC7940 Representing Label Generation Rulesets Using XML K. Davies A. Freytag August 2016 ASCII HTML 82 IDN LGR IDN table variant table

This document describes a method of representing rules for validating identifier labels and alternate representations of those labels using Extensible Markup Language (XML). These policies, known as "Label Generation Rulesets" (LGRs), are used for the implementation of Internationalized Domain Names (IDNs), for example. The rulesets are used to implement and share that aspect of policy defining which labels and Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants.

 draft-ietf-lager-specification-13 PROPOSED STANDARD PROPOSED STANDARD IETF art lager http://www.rfc-editor.org/errata_search.php?rfc=7940 10.17487/RFC7940 RFC7941 RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items M. Westerlund B. Burman R. Even M. Zanaty August 2016 ASCII HTML 17

Source Description (SDES) items are normally transported in the RTP Control Protocol (RTCP). In some cases, it can be beneficial to speed up the delivery of these items. The main case is when a new synchronization source (SSRC) joins an RTP session and the receivers need this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items.

 draft-ietf-avtext-sdes-hdr-ext-07 RFC8843 RFC9143 PROPOSED STANDARD PROPOSED STANDARD IETF art avtext 10.17487/RFC7941 RFC7942 Improving Awareness of Running Code: The Implementation Status Section Y. Sheffer A. Farrel July 2016 ASCII HTML 8

This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.

This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

 draft-sheffer-rfc6982bis-03 RFC6982 BCP0205 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7942 RFC7943 A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) F. Gont W. Liu September 2016 ASCII HTML 10 security privacy resiliency attack scanning tracking

This document describes a method for selecting IPv6 Interface Identifiers that can be employed by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients. This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments. It is a DHCPv6 variant of the method specified in RFC 7217 for IPv6 Stateless Address Autoconfiguration.

 draft-gont-dhcpv6-stable-privacy-addresses-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7943 RFC7944 Diameter Routing Message Priority S. Donovan August 2016 ASCII HTML 18 Diameter Overload

When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information, Diameter nodes can factor that priority into routing, resource allocation, and overload abatement decisions.

 draft-ietf-dime-drmp-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7944 RFC7945 Information-Centric Networking: Evaluation and Security Considerations K. Pentikousis Editor B. Ohlman E. Davies S. Spirou G. Boggia September 2016 ASCII HTML 38

This document presents a number of considerations regarding evaluating Information-Centric Networking (ICN) and sheds some light on the impact of ICN on network security. It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics.

 draft-irtf-icnrg-evaluation-methodology-05 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=7945 10.17487/RFC7945 RFC7946 The GeoJSON Format H. Butler M. Daly A. Doyle S. Gillies S. Hagen T. Schaub August 2016 ASCII HTML 28 JSON Geospatial JavaScript Object Notation

GeoJSON is a geospatial data interchange format based on JavaScript Object Notation (JSON). It defines several types of JSON objects and the manner in which they are combined to represent data about geographic features, their properties, and their spatial extents. GeoJSON uses a geographic coordinate reference system, World Geodetic System 1984, and units of decimal degrees.

 draft-ietf-geojson-04 PROPOSED STANDARD PROPOSED STANDARD IETF art geojson http://www.rfc-editor.org/errata_search.php?rfc=7946 10.17487/RFC7946 RFC7947 Internet Exchange BGP Route Server E. Jasinska N. Hilliard R. Raszuk N. Bakker September 2016 ASCII HTML 12 IDR

This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as IXPs, to facilitate simplified interconnection among multiple Internet routers.

 draft-ietf-idr-ix-bgp-route-server-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7947 RFC7948 Internet Exchange BGP Route Server Operations N. Hilliard E. Jasinska R. Raszuk N. Bakker September 2016 ASCII HTML 15 GROW

The popularity of Internet Exchange Points (IXPs) brings new challenges to interconnecting networks. While bilateral External BGP (EBGP) sessions between exchange participants were historically the most common means of exchanging reachability information over an IXP, the overhead associated with this interconnection method causes serious operational and administrative scaling problems for IXP participants.

Multilateral interconnection using Internet route servers can dramatically reduce the administrative and operational overhead associated with connecting to IXPs; in some cases, route servers are used by IXP participants as their preferred means of exchanging routing information.

This document describes operational considerations for multilateral interconnections at IXPs.

 draft-ietf-grow-ix-bgp-route-server-operations-05 INFORMATIONAL INFORMATIONAL IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=7948 10.17487/RFC7948 RFC7949 OSPFv3 over IPv4 for IPv6 Transition I. Chen A. Lindem R. Atkinson August 2016 ASCII HTML 11 IPv4 transport OSPFv3 transition

This document defines a mechanism to use IPv4 to transport OSPFv3 packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address Family extension can simplify transition from an OSPFv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain. This document updates RFC 5838 to support virtual links in the IPv4 unicast address family when using OSPFv3 over IPv4.

 draft-ietf-ospf-transition-to-ospfv3-12 RFC5838 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7949 RFC7950 The YANG 1.1 Data Modeling Language M. Bjorklund Editor August 2016 ASCII HTML 217 NETCONF XML data modeling

YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).

 draft-ietf-netmod-rfc6020bis-14 RFC8342 RFC8526 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7950 10.17487/RFC7950 RFC7951 JSON Encoding of Data Modeled with YANG L. Lhotka August 2016 ASCII HTML 20 I-JSON RESTCONF

This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.

 draft-ietf-netmod-yang-json-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7951 10.17487/RFC7951 RFC7952 Defining and Using Metadata with YANG L. Lhotka August 2016 ASCII HTML 21 metadata annotations YANG extension

This document defines a YANG extension that allows for defining metadata annotations in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes.

 draft-ietf-netmod-yang-metadata-07 RFC6110 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC7952 RFC7953 Calendar Availability C. Daboo M. Douglass August 2016 ASCII HTML 24 availability calendaring free-busy iCalendar CalDAV

This document specifies a new iCalendar (RFC 5545) component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including the iCalendar Transport-independent Interoperability Protocol (iTIP; RFC 5546) free-busy requests, to generate repeating blocks of available or busy time with exceptions as needed.

This document also defines extensions to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) and the associated scheduling protocol (RFC 6638) to specify how this new calendar component can be used when evaluating free-busy time.

 draft-ietf-calext-availability-04 RFC4791 RFC5545 RFC6638 PROPOSED STANDARD PROPOSED STANDARD IETF art calext http://www.rfc-editor.org/errata_search.php?rfc=7953 10.17487/RFC7953 RFC7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block L. Iannone D. Lewis D. Meyer V. Fuller September 2016 ASCII HTML 12

This document directs IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as Endpoint Identifier (EID) addressing space.

 draft-ietf-lisp-eid-block-13 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC7954 RFC7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block L. Iannone R. Jorgensen D. Conrad G. Huston September 2016 ASCII HTML 10

This document proposes a framework for the management of the Locator/ ID Separation Protocol (LISP) Endpoint Identifier (EID) address block. The framework described relies on hierarchical distribution of the address space, granting temporary usage of prefixes of such space to requesting organizations.

 draft-ietf-lisp-eid-block-mgmnt-07 INFORMATIONAL INFORMATIONAL IETF rtg lisp 10.17487/RFC7955 RFC7956 Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway W. Hao Y. Li A. Qu M. Durrani P. Sivamurugan September 2016 ASCII HTML 28 tenant data center

The base TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding for Layer 2 intra-subnet traffic but not for Layer 3 inter-subnet traffic. A centralized gateway solution is typically used for Layer 3 inter-subnet traffic forwarding but has the following issues:

1. Sub-optimum forwarding paths for inter-subnet traffic.

2. A centralized gateway that may need to support a very large number of gateway interfaces in a Data Center, one per tenant per Data Label used by that tenant, to provide interconnect functionality for all the Layer 2 Virtual Networks in a TRILL campus.

3. A traffic bottleneck at the gateway.

This document specifies an optional TRILL distributed gateway solution that resolves these centralized gateway issues.

 draft-ietf-trill-irb-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7956 RFC7957 DISPATCH-Style Working Groups and the SIP Change Process B. Campbell Editor A. Cooper B. Leiba August 2016 ASCII HTML 6 dispatch RAI ART sip-change

RFC 5727 defined several processes for the former Real-time Applications and Infrastructure (RAI) area. These processes include the evolution of the Session Initiation Protocol (SIP) and related protocols, as well as the operation of the DISPATCH and SIPCORE working groups. This document updates RFC 5727 to allow flexibility for the area and working group structure, while preserving the SIP change processes. It also generalizes the DISPATCH working group processes so that they can be easily adopted by other working groups.

 draft-campbell-art-rfc5727-update-03 RFC5727 BCP0067 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7957 RFC7958 DNSSEC Trust Anchor Publication for the Root Zone J. Abley J. Schlyter G. Bailey P. Hoffman August 2016 ASCII HTML 14 DNS ICANN IANA KSK

The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC).

In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors.

 draft-jabley-dnssec-trust-anchor-16 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7958 10.17487/RFC7958 RFC7959 Block-Wise Transfers in the Constrained Application Protocol (CoAP) C. Bormann Z. Shelby Editor August 2016 ASCII HTML 37 CoAP Constrained Application Protocol REST Internet of Things IoT Smart Object Embedded Internet Constrained Node

The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.

Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.

A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.

 draft-ietf-core-block-21 RFC7252 RFC8323 PROPOSED STANDARD PROPOSED STANDARD IETF art core http://www.rfc-editor.org/errata_search.php?rfc=7959 10.17487/RFC7959 RFC7960 Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows F. Martin Editor E. Lear Editor T. Draegen Editor E. Zwicky Editor K. Andersen Editor September 2016 ASCII HTML 27 DMARC SMTP DKIM SPF

Domain-based Message Authentication, Reporting, and Conformance (DMARC) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. However, the DMARC mechanism enables potentially disruptive interoperability issues when messages do not flow directly from the author's administrative domain to the final Recipients. Collectively, these email flows are referred to as "indirect email flows". This document describes these interoperability issues and presents possible methods for addressing them.

 draft-ietf-dmarc-interoperability-18 INFORMATIONAL INFORMATIONAL IETF art dmarc 10.17487/RFC7960 RFC7961 Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV D. Eastlake 3rd L. Yizhou August 2016 ASCII HTML 24 reachability AFN template

This document specifies a TRILL (Transparent Interconnection of Lots of Links) IS-IS application sub-TLV that enables the reporting by a TRILL switch of sets of addresses. Each set of addresses reports all of the addresses that designate the same interface (port) and also reports the TRILL switch by which that interface is reachable. For example, a 48-bit MAC (Media Access Control) address, IPv4 address, and IPv6 address can be reported as all corresponding to the same interface reachable by a particular TRILL switch. Such information could be used in some cases to synthesize responses to, or bypass the need for, the Address Resolution Protocol (ARP), the IPv6 Neighbor Discovery (ND) protocol, or the flooding of unknown MAC addresses.

 draft-ietf-trill-ia-appsubtlv-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7961 RFC7962 Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures J. Saldana Editor A. Arcia-Moret B. Braem E. Pietrosemoli A. Sathiaseelan M. Zennaro August 2016 ASCII HTML 43 alternative network deployments community networks user-centric networks Wireless Internet Service Providers mainstream network gaia global access to the Internet for all

This document presents a taxonomy of a set of "Alternative Network Deployments" that emerged in the last decade with the aim of bringing Internet connectivity to people or providing a local communication infrastructure to serve various complementary needs and objectives. They employ architectures and topologies different from those of mainstream networks and rely on alternative governance and business models.

The document also surveys the technologies deployed in these networks, and their differing architectural characteristics, including a set of definitions and shared properties.

The classification considers models such as Community Networks, Wireless Internet Service Providers (WISPs), networks owned by individuals but leased out to network operators who use them as a low-cost medium to reach the underserved population, networks that provide connectivity by sharing wireless resources of the users, and rural utility cooperatives.

 draft-irtf-gaia-alternative-network-deployments-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7962 RFC7963 RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs) Z. Ali A. Bonfanti M. Hartley F. Zhang August 2016 ASCII HTML 5 GMPLS

RFCs 4328 and 7139 provide signaling extensions in Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) to control the full set of Optical Transport Network (OTN) features. However, these specifications do not cover the additional Optical channel Data Unit (ODU) containers defined in G.Sup43 (ODU1e, ODU3e1, and ODU3e2). This document defines new Signal Types for these additional containers.

 draft-ietf-ccamp-additional-signal-type-g709v3-04 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7963 RFC7964 Solutions for BGP Persistent Route Oscillation D. Walton A. Retana E. Chen J. Scudder September 2016 ASCII HTML 9 BGP churn oscillation

Routing information reduction by BGP Route Reflection or Confederation can result in persistent internal BGP route oscillations with certain routing setups and network topologies. This document specifies two sets of additional paths that can be used to eliminate these route oscillations in a network.

 draft-ietf-idr-route-oscillation-stop-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7964 RFC7965 LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels M. Chen W. Cao A. Takacs P. Pan August 2016 ASCII HTML 16

Many transport services require that user traffic, in the form of Pseudowires (PWs), be delivered via either a single co-routed bidirectional tunnel or two unidirectional tunnels that share the same routes. This document defines an optional extension to the Label Distribution Protocol (LDP) that enables the binding between PWs and the underlying Traffic Engineering (TE) tunnels. The extension applies to both single-segment and multi-segment PWs.

 draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7965 RFC7966 Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements H. Tschofenig J. Korhonen Editor G. Zorn K. Pillay September 2016 ASCII HTML 11 Diameter End-to-End Security

This specification specifies requirements for providing Diameter security at the level of individual Attribute-Value Pairs (AVPs).

 draft-ietf-dime-e2e-sec-req-05 INFORMATIONAL INFORMATIONAL IETF ops dime 10.17487/RFC7966 RFC7967 Constrained Application Protocol (CoAP) Option for No Server Response A. Bhattacharyya S. Bandyopadhyay A. Pal T. Bose August 2016 ASCII HTML 18 No-Response

There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252.

This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option.

 draft-tcs-coap-no-response-option-17 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7967 RFC7968 Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data Y. Li D. Eastlake 3rd W. Hao H. Chen S. Chatterjee August 2016 ASCII HTML 22 VLAN fine-grained label multicast

TRILL (Transparent Interconnection of Lots of Links) uses distribution trees to deliver multi-destination frames. Multiple trees can be used by an ingress Routing Bridge (RBridge) for flows, regardless of the VLAN, Fine-Grained Label (FGL), and/or multicast group of the flow. Different ingress RBridges may choose different distribution trees for TRILL Data packets in the same VLAN, FGL, and/or multicast group. To avoid unnecessary link utilization, distribution trees should be pruned based on one or more of the following: VLAN, FGL, or multicast destination address. If any VLAN, FGL, or multicast group can be sent on any tree, for typical fast-path hardware, the amount of pruning information is multiplied by the number of trees, but there is limited hardware capacity for such pruning information.

This document specifies an optional facility to restrict the TRILL Data packets sent on particular distribution trees by VLAN, FGL, and/or multicast groups, thus reducing the total amount of pruning information so that it can more easily be accommodated by fast-path hardware.

 draft-ietf-trill-tree-selection-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7968 RFC7969 Customizing DHCP Configuration on the Basis of Network Topology T. Lemon T. Mrugalski October 2016 ASCII HTML 20 dhcpv4 dhcpv6 relay-agents (relay agents) multiple subnets subnets links prefixes

DHCP servers have evolved over the years to provide significant functionality beyond that described in the DHCP base specifications. One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and explains their operation.

 draft-ietf-dhc-topo-conf-09 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC7969 RFC7970 The Incident Object Description Exchange Format Version 2 R. Danyliw November 2016 ASCII HTML 172 incident data format incident report cyber threat indicators computer security incident computer security incident response team CSIRT CERT security data sharing Computer Network Defense Service Provider CNDSP information sharing automated information sharing cyber indicators

The Incident Object Description Exchange Format (IODEF) defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning. This document describes an updated information model for the IODEF and provides an associated data model specified with the XML schema. This new information and data model obsoletes RFCs 5070 and 6685.

 draft-ietf-mile-rfc5070-bis-26 RFC5070 RFC6685 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile http://www.rfc-editor.org/errata_search.php?rfc=7970 10.17487/RFC7970 RFC7971 Application-Layer Traffic Optimization (ALTO) Deployment Considerations M. Stiemerling S. Kiesel M. Scharf H. Seidel S. Previdi October 2016 ASCII HTML 77

Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This memo discusses deployment-related issues of ALTO. It addresses different use cases of ALTO such as peer-to-peer file sharing and Content Delivery Networks (CDNs) and presents corresponding examples. The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such as recommendations on how to generate ALTO map information.

 draft-ietf-alto-deployments-16 INFORMATIONAL INFORMATIONAL IETF tsv alto 10.17487/RFC7971 RFC7972 Entertainment Identifier Registry (EIDR) URN Namespace Definition P. Lemieux September 2016 ASCII HTML 10 EIDR Entertainment Identifier Registry and URN

Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for EIDR Identifiers.

This document obsoletes RFC 7302.

 draft-pal-eidr-urn-2016-03 RFC7302 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7972 RFC7973 Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation R. Droms P. Duffy November 2016 ASCII HTML 5 6lowpan header compression ethertype

When carried over Layer 2 technologies such as Ethernet, IPv6 datagrams using Low-Power Wireless Personal Area Network (LoWPAN) encapsulation as defined in RFC 4944 must be identified so the receiver can correctly interpret the encoded IPv6 datagram. The IETF officially requested the assignment of an Ethertype for that purpose and this document reports that assignment.

 draft-ietf-6lo-ethertype-request-01 INFORMATIONAL INFORMATIONAL IETF int 6lo 10.17487/RFC7973 RFC7974 An Experimental TCP Option for Host Identification B. Williams M. Boucadair D. Wing October 2016 ASCII HTML 20 Policy enforcement Address sharing NAT Host reveal Host-ID

Recent RFCs have discussed issues with host identification in IP address-sharing systems, such as address/prefix-sharing devices and application-layer proxies. Potential solutions for revealing a host identifier in shared address deployments have also been discussed. This memo describes the design, deployment, and privacy considerations for one such solution in operational use on the Internet today that uses a TCP option to transmit a host identifier.

 draft-williams-exp-tcp-host-id-opt-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7974 RFC7975 Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection B. Niven-Jenkins Editor R. van Brandenburg Editor October 2016 ASCII HTML 35 HTTP DNS

The Request Routing interface comprises (1) the asynchronous advertisement of footprint and capabilities by a downstream Content Delivery Network (CDN) that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e., the CDNI Request Routing Redirection interface.

 draft-ietf-cdni-redirection-20 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni 10.17487/RFC7975 RFC7976 Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses C. Holmberg N. Biondic G. Salgueiro September 2016 ASCII HTML 8 P- 3GPP IMS

The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses.

This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315.

 draft-holmberg-dispatch-rfc7315-updates-09 RFC7315 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7976 10.17487/RFC7976 RFC7977 The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP) P. Dunkley G. Llewellyn V. Pascual G. Salgueiro R. Ravindranath September 2016 ASCII HTML 28 MSRP WebSocket

The WebSocket protocol enables two-way real-time communication between clients and servers in situations where direct access to TCP and UDP is not available (for example, from within JavaScript in a web browser). This document specifies a new WebSocket subprotocol as a reliable transport mechanism between Message Session Relay Protocol (MSRP) clients and relays to enable usage of MSRP in new scenarios. This document normatively updates RFCs 4975 and 4976.

 draft-pd-dispatch-msrp-websocket-15 RFC4975 RFC4976 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7977 RFC7978 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension D. Eastlake 3rd M. Umair Y. Li September 2016 ASCII HTML 25 tunnel encapsulation

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol includes an optional mechanism (specified in RFC 7178) called RBridge Channel for the transmission of typed messages between TRILL switches in the same campus and the transmission of such messages between TRILL switches and end stations on the same link. This document specifies extensions to the RBridge Channel protocol header to support two features as follows: (1) a standard method to tunnel payloads whose type can be indicated by Ethertype through encapsulation in RBridge Channel messages; and (2) a method to support security facilities for RBridge Channel messages. This document updates RFC 7178.

 draft-ietf-trill-channel-tunnel-11 RFC7178 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7978 RFC7979 Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries E. Lear Editor R. Housley Editor August 2016 ASCII HTML 37

The U.S. National Telecommunications and Information Administration (NTIA) solicited a request from the Internet Corporation for Assigned Names and Numbers (ICANN) to propose how the NTIA should end its oversight of the Internet Assigned Numbers Authority (IANA) functions. After broad consultations, ICANN in turn created the IANA Stewardship Transition Coordination Group. That group solicited proposals for the three major IANA functions: names, numbers, and protocol parameters. This document contains the IETF response to that solicitation for protocol parameters. It was included in an aggregate response to the NTIA alongside those for names and numbering resources that are being developed by their respective operational communities. A reference to that response may be found in the introduction, and additional correspondence is included in the Appendix.

 draft-ietf-ianaplan-icg-response-10 INFORMATIONAL INFORMATIONAL IETF gen ianaplan 10.17487/RFC7979 RFC7980 A Framework for Defining Network Complexity M. Behringer A. Retana R. White G. Huston October 2016 ASCII HTML 24 Complicated Fragile Self-organization Trade-off Technical Debt Dependency

Complexity is a widely used parameter in network design, yet there is no generally accepted definition of the term. Complexity metrics exist in a wide range of research papers, but most of these address only a particular aspect of a network, for example, the complexity of a graph or software. While it may be impossible to define a metric for overall network complexity, there is a desire to better understand the complexity of a network as a whole, as deployed today to provide Internet services. This document provides a framework to guide research on the topic of network complexity as well as some practical examples for trade-offs in networking.

This document summarizes the work of the IRTF's Network Complexity Research Group (NCRG) at the time of its closure. It does not present final results, but a snapshot of an ongoing activity, as a basis for future work.

 draft-behringer-ncrg-complexity-framework-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7980 RFC7981 IS-IS Extensions for Advertising Router Information L. Ginsberg S. Previdi M. Chen October 2016 ASCII HTML 10

This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. This document obsoletes RFC 4971.

 draft-ietf-isis-rfc4971bis-04 RFC4971 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7981 RFC7982 Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN) P. Martinsen T. Reddy D. Wing V. Singh September 2016 ASCII HTML 10

A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience.

This document describes a mechanism for an endpoint to measure the path characteristics fractional loss and RTT using Session Traversal Utilities for NAT (STUN) messages.

 draft-ietf-tram-stun-path-data-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC7982 RFC7983 Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) M. Petit-Huguenin G. Salgueiro September 2016 ASCII HTML 13 TLS STUN TURN TLS TURN Channel Numbers STUN Methods RFC 5764 SRTP-DTLS ZRTP

This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. It overrides the guidance from RFC 5764 ("SRTP Extension for DTLS"), which suffered from four issues described and fixed in this document.

This document updates RFC 5764.

 draft-ietf-avtcore-rfc5764-mux-fixes-11 RFC5764 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC7983 RFC7984 Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network O. Johansson G. Salgueiro V. Gurbani D. Worley Editor September 2016 ASCII HTML 10 A record address family preference AAAA record DNS getaddrinfo Happy Eyeballs IPv6 address selection SIP SRV record dual-stack IPv4 IPv6

RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying "Happy Eyeballs" principles to SIP.

 draft-ietf-sipcore-dns-dual-stack-08 RFC3263 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC7984 RFC7985 Security Threats to Simplified Multicast Forwarding (SMF) J. Yi T. Clausen U. Herberg November 2016 ASCII HTML 15 MANET

This document analyzes security threats to Simplified Multicast Forwarding (SMF), including vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described.

In addition, this document updates RFC 7186 regarding threats to the relay set selection mechanisms using the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130).

 draft-ietf-manet-smf-sec-threats-06 RFC7186 INFORMATIONAL INFORMATIONAL IETF rtg manet 10.17487/RFC7985 RFC7986 New Properties for iCalendar C. Daboo October 2016 ASCII HTML 23 alarms calendaring iCalendar

This document defines a set of new properties for iCalendar data and extends the use of some existing properties to the entire iCalendar object.

 draft-ietf-calext-extensions-05 RFC5545 PROPOSED STANDARD PROPOSED STANDARD IETF art calext http://www.rfc-editor.org/errata_search.php?rfc=7986 10.17487/RFC7986 RFC7987 IS-IS Minimum Remaining Lifetime L. Ginsberg P. Wells B. Decraene T. Przygienda H. Gredler October 2016 ASCII HTML 9

Corruption of the Remaining Lifetime field in a Link State Protocol Data Unit (LSP) can go undetected. In certain scenarios, this may cause or exacerbate flooding storms. It is also a possible denial-of-service attack vector. This document defines a backwards-compatible solution to this problem.

 draft-ietf-isis-remaining-lifetime-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7987 RFC7988 Ingress Replication Tunnels in Multicast VPN E. Rosen Editor K. Subramanian Z. Zhang October 2016 ASCII HTML 23

RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN (MVPN) service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an "Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be directly connected to its child nodes. When a parent node has to send a multicast data packet to its n child nodes, it does not use Layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels.

 draft-ietf-bess-ir-05 RFC6513 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7988 RFC7989 End-to-End Session Identification in IP-Based Multimedia Communication Networks P. Jones G. Salgueiro C. Pearce P. Giralt October 2016 ASCII HTML 45 SIP Session Initiation Protocol troubleshooting Session-ID session identifier H460.27 remote parameter UUID

This document describes an end-to-end session identifier for use in IP-based multimedia communication systems that enables endpoints, intermediary devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. While the identifier is intended to work across multiple protocols, this document describes its usage in the Session Initiation Protocol (SIP).

This document also describes a backwards-compatibility mechanism for an existing session identifier implementation (RFC 7329) that is sufficiently different from the procedures defined in this document.

This document obsoletes RFC 7329.

 draft-ietf-insipid-session-id-27 RFC7329 PROPOSED STANDARD PROPOSED STANDARD IETF art insipid 10.17487/RFC7989 RFC7990 RFC Format Framework H. Flanagan December 2016 ASCII HTML 16 Format xml2rfcv3 v3

In order to improve the readability of RFCs while supporting their archivability, the canonical format of the RFC Series will be transitioning from plain-text ASCII to XML using the xml2rfc version 3 vocabulary; different publication formats will be rendered from that base document. With these changes comes an increase in complexity for authors, consumers, and the publisher of RFCs. This document serves as the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan.

 draft-iab-rfc-framework-06 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7990 RFC7991 The "xml2rfc" Version 3 Vocabulary P. Hoffman December 2016 ASCII HTML 151 v3 xml2rfcv3 format

This document defines the "xml2rfc" version 3 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 7749.

 draft-iab-xml2rfc-04 RFC7749 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7991 10.17487/RFC7991 RFC7992 HTML Format for RFCs J. Hildebrand Editor P. Hoffman December 2016 ASCII HTML 43 html css v3 xml2rfcv3 format

In order to meet the evolving needs of the Internet community, the canonical format for RFCs is changing from a plain-text, ASCII-only format to an XML format that will, in turn, be rendered into several publication formats. This document defines the HTML format that will be rendered for an RFC or Internet-Draft.

 draft-iab-html-rfc-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7992 RFC7993 Cascading Style Sheets (CSS) Requirements for RFCs H. Flanagan December 2016 ASCII HTML 14 v3 xml2rfcv3 format html

The HTML format for RFCs assigns style guidance to a Cascading Style Sheet (CSS) specifically defined for the RFC Series. The embedded, default CSS as included by the RFC Editor is expected to take into account accessibility needs and to be built along a responsive design model. This document describes the requirements for the default CSS used by the RFC Editor. The class names are based on the classes defined in "HTML for RFCs" (RFC 7992).

 draft-iab-rfc-css-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7993 RFC7994 Requirements for Plain-Text RFCs H. Flanagan December 2016 ASCII HTML 8 RFC ASCII format plain-text plain text xml2rfcv3 v3

In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs to XML as the canonical format with more human-readable formats rendered from that XML. The high-level requirements that informed this change were defined in RFC 6949, "RFC Series Format Requirements and Future Development". Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML. This document outlines the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition.

 draft-iab-rfc-plaintext-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7994 RFC7995 PDF Format for RFCs T. Hansen Editor L. Masinter M. Hardy December 2016 ASCII HTML 22 Requests for Comment xml2rfcv3 v3 format

This document discusses options and requirements for the PDF rendering of RFCs in the RFC Series, as outlined in RFC 6949. It also discusses the use of PDF for Internet-Drafts, and available or needed software tools for producing and working with PDF.

 draft-iab-rfc-use-of-pdf-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7995 RFC7996 SVG Drawings for RFCs: SVG 1.2 RFC N. Brownlee December 2016 ASCII HTML 53 RFC v3 xml2rfcv3 format

This document specifies SVG 1.2 RFC -- an SVG profile for use in diagrams that may appear in RFCs -- and considers some of the issues concerning the creation and use of such diagrams.

 draft-iab-svg-rfc-02 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7996 10.17487/RFC7996 RFC7997 The Use of Non-ASCII Characters in RFCs H. Flanagan Editor December 2016 ASCII PDF HTML 15 RFC Series UTF-8 ASCII format non-ASCII v3 xml2rfcv3

In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs.

This document updates RFC 7322. Please view this document in PDF form to see the full text.

 draft-iab-rfc-nonascii-02 RFC7322 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7997 10.17487/RFC7997 RFC7998 "xml2rfc" Version 3 Preparation Tool Description P. Hoffman J. Hildebrand December 2016 ASCII HTML 18 xml2rfcv3 v3 format

This document describes some aspects of the "prep tool" that is expected to be created when the new xml2rfc version 3 specification is deployed.

 draft-iab-rfcv3-preptool-02 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7998 10.17487/RFC7998 RFC7999 BLACKHOLE Community T. King C. Dietzel J. Snijders G. Doering G. Hankins October 2016 ASCII HTML 9 well-known well known RTBH Remotely Triggered Blackholing

This document describes the use of a well-known Border Gateway Protocol (BGP) community for destination-based blackholing in IP networks. This well-known advisory transitive BGP community named "BLACKHOLE" allows an origin Autonomous System (AS) to specify that a neighboring network should discard any traffic destined towards the tagged IP prefix.

 draft-ietf-grow-blackholing-03 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC7999 RFC8000 Requirements for NFSv4 Multi-Domain Namespace Deployment A. Adamson N. Williams November 2016 ASCII HTML 17 multi-domain multi-domain-capable file system Federated File System FedFS

This document presents requirements for the deployment of the NFSv4 protocols for the construction of an NFSv4 file namespace in environments with multiple NFSv4 Domains. To participate in an NFSv4 multi-domain file namespace, the server must offer a multi-domain-capable file system and support RPCSEC_GSS for user authentication. In most instances, the server must also support identity-mapping services.

 draft-ietf-nfsv4-multi-domain-fs-reqs-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8000 RFC8001 RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information F. Zhang Editor O. Gonzalez de Dios Editor C. Margaria M. Hartley Z. Ali January 2017 ASCII HTML 16

This document provides extensions for Resource Reservation Protocol - Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP).

 draft-ietf-teas-rsvp-te-srlg-collect-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8001 RFC8002 Host Identity Protocol Certificates T. Heer S. Varjonen October 2016 ASCII HTML 13 Hip Certificate Extension

The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags (HITs) in X.509 version 3 (v3).

The concrete use cases of certificates, including how certificates are obtained and requested and which actions are taken upon successful or failed verification, are specific to the scenario in which the certificates are used. Hence, the definition of these scenario-specific aspects is left to the documents that use the CERT parameter.

This document updates RFC 7401 and obsoletes RFC 6253.

 draft-ietf-hip-rfc6253-bis-09 RFC6253 RFC7401 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8002 RFC8003 Host Identity Protocol (HIP) Registration Extension J. Laganier L. Eggert October 2016 ASCII HTML 16 HIP Host Identity Protocol Host Identity Payload Registration register

This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This document obsoletes RFC 5203.

 draft-ietf-hip-rfc5203-bis-11 RFC5203 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8003 RFC8004 Host Identity Protocol (HIP) Rendezvous Extension J. Laganier L. Eggert October 2016 ASCII HTML 14 HIP Host Identity Protocol Host Identity Payload Rendezvous HIP nodes HIP rendezvous server

This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP Registration Extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multihomed or mobile. This document obsoletes RFC 5204.

 draft-ietf-hip-rfc5204-bis-08 RFC5204 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8004 RFC8005 Host Identity Protocol (HIP) Domain Name System (DNS) Extension J. Laganier October 2016 ASCII HTML 18 HIP Host Identity Protocol Host Identity Payload DNS Domain Name System

This document specifies a resource record (RR) for the Domain Name System (DNS) and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI), the public component of the node public-private key pair; its Host Identity Tag (HIT), a truncated hash of its public key (PK); and the domain names of its rendezvous servers (RVSs). This document obsoletes RFC 5205.

 draft-ietf-hip-rfc5205-bis-10 RFC5205 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8005 RFC8006 Content Delivery Network Interconnection (CDNI) Metadata B. Niven-Jenkins R. Murray M. Caulfield K. Ma December 2016 ASCII HTML 66 CDN cascaded CDN cascading CDNs content acquisition content delegation request delegation acquisition protocol delivery restriction delivery policy policy enforcement delivery protocol content expiration geo-fencing geofencing geo fencing geo-blocking geoblocking geo blocking footprint cache control

The Content Delivery Network Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI Metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNI Metadata and the protocol for exchanging that metadata.

 draft-ietf-cdni-metadata-21 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni http://www.rfc-editor.org/errata_search.php?rfc=8006 10.17487/RFC8006 RFC8007 Content Delivery Network Interconnection (CDNI) Control Interface / Triggers R. Murray B. Niven-Jenkins December 2016 ASCII HTML 49 CDN pre-position invalidate purge

This document describes the part of the Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-position metadata or content or to request that it invalidate or purge metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN.

 draft-ietf-cdni-control-triggers-15 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni http://www.rfc-editor.org/errata_search.php?rfc=8007 10.17487/RFC8007 RFC8008 Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics J. Seedorf J. Peterson S. Previdi R. van Brandenburg K. Ma December 2016 ASCII HTML 31 CDNI CDN Interconnect Request Routing

This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the Content Delivery Network Interconnection (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context and what the "Footprint & Capabilities Advertisement interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future.

 draft-ietf-cdni-footprint-capabilities-semantics-20 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni 10.17487/RFC8008 RFC8009 AES Encryption with HMAC-SHA2 for Kerberos 5 M. Jenkins M. Peck K. Burgin October 2016 ASCII HTML 19

This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity.

 draft-ietf-kitten-aes-cts-hmac-sha2-11 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC8009 RFC8010 Internet Printing Protocol/1.1: Encoding and Transport M. Sweet I. McDonald January 2017 ASCII HTML 51 IPP Printer PWG Printer Working Group

The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations, attributes, and values into the Internet MIME media type called "application/ipp". It also defines the rules for transporting a message body whose Content-Type is "application/ipp" over HTTP and/or HTTPS. The IPP data model and operation semantics are described in "Internet Printing Protocol/1.1: Model and Semantics" (RFC 8011).

 draft-sweet-rfc2910bis-10 RFC2910 RFC3382 STD0092 INTERNET STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8010 RFC8011 Internet Printing Protocol/1.1: Model and Semantics M. Sweet I. McDonald January 2017 ASCII HTML 221 IPP Printer PWG Printer Working Group

The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, attributes, and operations that is independent of encoding and transport. The model consists of several objects, including Printers and Jobs. Jobs optionally support multiple Documents.

IPP semantics allow End Users and Operators to query Printer capabilities; submit Print Jobs; inquire about the status of Print Jobs and Printers; and cancel, hold, and release Print Jobs. IPP semantics also allow Operators to pause and resume Jobs and Printers.

Security, internationalization, and directory issues are also addressed by the model and semantics. The IPP message encoding and transport are described in "Internet Printing Protocol/1.1: Encoding and Transport" (RFC 8010).

This document obsoletes RFCs 2911, 3381, and 3382.

 draft-sweet-rfc2911bis-11 RFC2911 RFC3381 RFC3382 STD0092 INTERNET STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8011 10.17487/RFC8011 RFC8012 Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs) N. Akiya G. Swallow C. Pignataro A. Malis S. Aldrin November 2016 ASCII HTML 23 MPLS LSP Ping and Entropy

Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) ping and traceroute are methods used to test Equal-Cost Multipath (ECMP) paths. Ping is known as a connectivity-verification method and traceroute is known as a fault-isolation method, as described in RFC 4379. When an LSP is signaled using the Entropy Label (EL) described in RFC 6790, the ability for LSP ping and traceroute operations to discover and exercise ECMP paths is lost for scenarios where Label Switching Routers (LSRs) apply different load-balancing techniques. One such scenario is when some LSRs apply EL-based load balancing while other LSRs apply load balancing that is not EL based (e.g., IP). Another scenario is when an EL-based LSP is stitched with another LSP that can be EL based or not EL based.

This document extends the MPLS LSP ping and traceroute multipath mechanisms in RFC 6424 to allow the ability of exercising LSPs that make use of the EL. This document updates RFC 6790.

 draft-ietf-mpls-entropy-lsp-ping-05 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8012 RFC8013 Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB) D. Joachimpillai J. Hadi Salim February 2017 ASCII HTML 25 ForCES Inter-FE

This document describes how to extend the Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) topology across Forwarding Elements (FEs) by defining the inter-FE LFB class. The inter-FE LFB class provides the ability to pass data and metadata across FEs without needing any changes to the ForCES specification. The document focuses on Ethernet transport.

 draft-ietf-forces-interfelfb-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8013 10.17487/RFC8013 RFC8014 An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3) D. Black J. Hudson L. Kreeger M. Lasserre T. Narten December 2016 ASCII HTML 35

This document presents a high-level overview architecture for building data-center Network Virtualization over Layer 3 (NVO3) networks. The architecture is given at a high level, showing the major components of an overall system. An important goal is to divide the space into individual smaller components that can be implemented independently with clear inter-component interfaces and interactions. It should be possible to build and implement individual components in isolation and have them interoperate with other independently implemented components. That way, implementers have flexibility in implementing individual components and can optimize and innovate within their respective components without requiring changes to other components.

 draft-ietf-nvo3-arch-08 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC8014 RFC8015 RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics V. Singh C. Perkins A. Clark R. Huang November 2016 ASCII HTML 15 XRBLOCK

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst/gap discard metrics independently of the burst/gap loss metrics for use in a range of RTP applications.

 draft-ietf-xrblock-independent-burst-gap-discard-03 PROPOSED STANDARD PROPOSED STANDARD IETF art xrblock 10.17487/RFC8015 RFC8016 Mobility with Traversal Using Relays around NAT (TURN) T. Reddy D. Wing P. Patil P. Martinsen November 2016 ASCII HTML 13 IP Address Mobility VoIP ICE STUN RTP TUNNEL

It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so that only the local network elements are aware of the changed IP address and the remote peer is unaware of the changed IP address.

This document provides such an IP address mobility solution using Traversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes.

 draft-ietf-tram-turn-mobility-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC8016 RFC8017 PKCS #1: RSA Cryptography Specifications Version 2.2 K. Moriarty Editor B. Kaliski J. Jonsson A. Rusch November 2016 ASCII HTML 78 RSA public-key cryptosystem RSA signature scheme RSA public key RSA private key PKCS #1 v1.5 RSA-OAEP RSA-PSS Optimal Asymmetric Encryption Padding Probabilistic Signature Scheme

This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.

This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.

This document also obsoletes RFC 3447.

 draft-moriarty-pkcs1-03 RFC3447 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8017 10.17487/RFC8017 RFC8018 PKCS #5: Password-Based Cryptography Specification Version 2.1 K. Moriarty Editor B. Kaliski A. Rusch January 2017 ASCII HTML 40 password-based encryption password-based key derivation salt

This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques.

This document represents a republication of PKCS #5 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.

This document also obsoletes RFC 2898.

 draft-moriarty-pkcs5-v2dot1-04 RFC2898 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8018 10.17487/RFC8018 RFC8019 Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks Y. Nir V. Smyslov November 2016 ASCII HTML 32 puzzle dos ddos bitcoin

This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial-of-Service and Distributed Denial-of-Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that helps accomplish this task.

 draft-ietf-ipsecme-ddos-protection-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8019 RFC8020 NXDOMAIN: There Really Is Nothing Underneath S. Bortzmeyer S. Huque November 2016 ASCII HTML 10

This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist.

This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them.

 draft-ietf-dnsop-nxdomain-cut-05 RFC1034 RFC2308 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8020 10.17487/RFC8020 RFC8021 Generation of IPv6 Atomic Fragments Considered Harmful F. Gont W. Liu T. Anderson January 2017 ASCII HTML 12 attack DoS Extension Headers

This document discusses the security implications of the generation of IPv6 atomic fragments and a number of interoperability issues associated with IPv6 atomic fragments. It concludes that the aforementioned functionality is undesirable and thus documents the motivation for removing this functionality from an upcoming revision of the core IPv6 protocol specification (RFC 2460).

 draft-ietf-6man-deprecate-atomfrag-generation-08 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC8021 RFC8022 A YANG Data Model for Routing Management L. Lhotka A. Lindem November 2016 ASCII HTML 64 configuration IPv6 router advertisements NETCONF RESTCONF

This document contains a specification of three YANG modules and one submodule. Together they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.

 draft-ietf-netmod-routing-cfg-25 RFC8349 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8022 RFC8023 Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions M. Thomas A. Mankin L. Zhang November 2016 ASCII HTML 17

This document provides context and a report on the workshop on "Root Causes and Mitigation of Name Collisions", which took place in London, United Kingdom, from March 8 to 10, 2014. The main goal of the workshop was to foster a discussion on the causes and potential mitigations of domain name collisions. This report provides a small amount of background and context; then, it provides a summary of the workshop's discussions.

 draft-thomas-namecollisions-workshop-report-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8023 RFC8024 Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS Y. Jiang Editor Y. Luo E. Mallette Editor Y. Shen W. Cheng November 2016 ASCII HTML 16 PON Protection

Multiprotocol Label Switching (MPLS) is being extended to the edge of operator networks including the network access nodes. Separately, network access nodes such as Passive Optical Network (PON) Optical Line Terminations (OLTs) have evolved to support first-mile access protection, where one or more physical OLTs provide first-mile diversity to the customer edge. Multihoming support is needed on the MPLS-enabled PON OLT to provide resiliency for provided services. This document describes the Multi-Chassis PON (MC-PON) protection architecture in MPLS and also specifies the Inter-Chassis Communication Protocol (ICCP) extension to support it.

 draft-ietf-pals-mc-pon-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8024 RFC8025 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch P. Thubert Editor R. Cragie November 2016 ASCII HTML 8 LNN IOT

This specification updates RFC 4944 to introduce a new context switch mechanism for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) compression, expressed in terms of Pages and signaled by a new Paging Dispatch.

 draft-ietf-6lo-paging-dispatch-05 RFC4944 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8025 RFC8026 Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism M. Boucadair I. Farrer November 2016 ASCII HTML 11 Provisioning Softwire IPv4 over IPv6 IPv4 service continuity IPv4 address depletion MAP MAP-T MAP-E DS-Lite Lightweight 4 over 6

In IPv6-only provider networks, transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo specifies a DHCPv6 option, whereby a single instance of Customer Premises Equipment (CPE) can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4-in-IPv6 services by providing a prioritization mechanism.

 draft-ietf-softwire-unified-cpe-08 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8026 RFC8027 DNSSEC Roadblock Avoidance W. Hardaker O. Gudmundsson S. Krishnaswamy November 2016 ASCII HTML 19 DNSSEC Network Problems DNS

This document describes problems that a Validating DNS resolver, stub-resolver, or application might run into within a non-compliant infrastructure. It outlines potential detection and mitigation techniques. The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face.

 draft-ietf-dnsop-dnssec-roadblock-avoidance-05 BCP0207 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8027 10.17487/RFC8027 RFC8028 First-Hop Router Selection by Hosts in a Multi-Prefix Network F. Baker B. Carpenter November 2016 ASCII HTML 13

This document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. Host behavior in choosing a first-hop router may interact with source address selection in a given implementation. However, the selection of the source address for a packet is done before the first-hop router for that packet is chosen. Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC 4861.

 draft-ietf-6man-multi-homed-host-10 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=8028 10.17487/RFC8028 RFC8029 Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures K. Kompella G. Swallow C. Pignataro Editor N. Kumar S. Aldrin M. Chen March 2017 ASCII HTML 78 MPLS echo request MPLS echo reply

This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults.

This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122.

 draft-ietf-mpls-rfc4379bis-09 RFC4379 RFC6424 RFC6829 RFC7537 RFC1122 RFC8611 RFC9041 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=8029 10.17487/RFC8029 RFC8030 Generic Event Delivery Using HTTP Push M. Thomson E. Damaggio B. Raymor Editor December 2016 ASCII HTML 31 HTTP HTTP2 Push WebPush

This document describes a simple protocol for the delivery of real- time events to user agents. This scheme uses HTTP/2 server push.

 draft-ietf-webpush-protocol-12 PROPOSED STANDARD PROPOSED STANDARD IETF art webpush 10.17487/RFC8030 RFC8031 Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement Y. Nir S. Josefsson December 2016 ASCII HTML 8 Curve25519 Curve448 Goldilocks Diffie Hellman

This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange Protocol Version 2 (IKEv2).

 draft-ietf-ipsecme-safecurves-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=8031 10.17487/RFC8031 RFC8032 Edwards-Curve Digital Signature Algorithm (EdDSA) S. Josefsson I. Liusvaara January 2017 ASCII HTML 60 signature digital signature EdDSA

This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.

 draft-irtf-cfrg-eddsa-08 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8032 10.17487/RFC8032 RFC8033 Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem R. Pan P. Natarajan F. Baker G. White February 2017 ASCII HTML 30 active queue management AQM

Bufferbloat is a phenomenon in which excess buffers in the network cause high latency and latency variation. As more and more interactive applications (e.g., voice over IP, real-time video streaming, and financial transactions) run in the Internet, high latency and latency variation degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and latency variation, and hence provide desirable quality of service to users.

This document presents a lightweight active queue management design called "PIE" (Proportional Integral controller Enhanced) that can effectively control the average queuing latency to a target value. Simulation results, theoretical analysis, and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamps, so it incurs very little overhead and is simple enough to implement in both hardware and software.

 draft-ietf-aqm-pie-10 EXPERIMENTAL EXPERIMENTAL IETF tsv aqm http://www.rfc-editor.org/errata_search.php?rfc=8033 10.17487/RFC8033 RFC8034 Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced (PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems G. White R. Pan February 2017 ASCII HTML 17 latency access network bufferbloat

Cable modems based on Data-Over-Cable Service Interface Specifications (DOCSIS) provide broadband Internet access to over one hundred million users worldwide. In some cases, the cable modem connection is the bottleneck (lowest speed) link between the customer and the Internet. As a result, the impact of buffering and bufferbloat in the cable modem can have a significant effect on user experience. The CableLabs DOCSIS 3.1 specification introduces requirements for cable modems to support an Active Queue Management (AQM) algorithm that is intended to alleviate the impact that buffering has on latency-sensitive traffic, while preserving bulk throughput performance. In addition, the CableLabs DOCSIS 3.0 specifications have also been amended to contain similar requirements. This document describes the requirements on AQM that apply to DOCSIS equipment, including a description of the "DOCSIS-PIE" algorithm that is required on DOCSIS 3.1 cable modems.

 draft-ietf-aqm-docsis-pie-02 INFORMATIONAL INFORMATIONAL IETF tsv aqm 10.17487/RFC8034 RFC8035 Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing C. Holmberg November 2016 ASCII HTML 7 RTP RTCP multiplex rtcp-mux SDP offer answer

This document updates RFC 5761 by clarifying the SDP offer/answer negotiation of RTP and RTP Control Protocol (RTCP) multiplexing. It makes it clear that an answerer can only include an "a=rtcp-mux" attribute in a Session Description Protocol (SDP) answer if the associated SDP offer contained the attribute.

 draft-ietf-avtcore-5761-update-06 RFC5761 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8035 RFC8036 Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks N. Cam-Winget Editor J. Hui D. Popa January 2017 ASCII HTML 24 constrained environment smart meter utilities smartgrid secure smartgrid connected energy

This document discusses the applicability of the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) networks.

 draft-ietf-roll-applicability-ami-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC8036 RFC8037 CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) I. Liusvaara January 2017 ASCII HTML 14 Ed25519 Ed448 X25519 X448

This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE).

 draft-ietf-jose-cfrg-curves-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose http://www.rfc-editor.org/errata_search.php?rfc=8037 10.17487/RFC8037 RFC8038 Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol P. Aitken Editor B. Claise S. B S C. McDowall J. Schoenwaelder May 2017 ASCII HTML 85 IPFIX MIB SNMP

This document specifies a way to complement IP Flow Information Export (IPFIX) Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing MIB objects that are already fully specified.

Two IPFIX Options Templates, as well as a method for creating IPFIX Options Templates that are used to export the extra data required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX, are specified herein.

 draft-ietf-ipfix-mib-variable-export-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8038 RFC8039 Multipath Time Synchronization A. Shpiner R. Tse C. Schelp T. Mizrahi December 2016 ASCII HTML 17 NTP PTP IEEE 1588 multiple paths

Clock synchronization protocols are very widely used in IP-based networks. The Network Time Protocol (NTP) has been commonly deployed for many years, and the last few years have seen an increasingly rapid deployment of the Precision Time Protocol (PTP). As time-sensitive applications evolve, clock accuracy requirements are becoming increasingly stringent, requiring the time synchronization protocols to provide high accuracy. This memo describes a multipath approach to PTP and NTP over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks, without modifying these protocols. The multipath approach can significantly contribute to clock accuracy, security, and fault tolerance. The multipath approach that is presented in this document enables backward compatibility with nodes that do not support the multipath functionality.

 draft-ietf-tictoc-multi-path-synchronization-07 EXPERIMENTAL EXPERIMENTAL IETF int tictoc 10.17487/RFC8039 RFC8040 RESTCONF Protocol A. Bierman M. Bjorklund K. Watsen January 2017 ASCII HTML 137 YANG NETCONF REST HTTP

This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).

 draft-ietf-netconf-restconf-18 RFC8527 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=8040 10.17487/RFC8040 RFC8041 Use Cases and Operational Experience with Multipath TCP O. Bonaventure C. Paasch G. Detal January 2017 ASCII HTML 30 TCP MPTCP Middlebox Congestion Control Path Manager Scheduler Proxy Load-Balancer Datacenter Cellular/WiFi Offload Hybrid Access Networks

This document discusses both use cases and operational experience with Multipath TCP (MPTCP) in real networks. It lists several prominent use cases where Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases and suggests possible improvements.

 draft-ietf-mptcp-experience-07 INFORMATIONAL INFORMATIONAL IETF tsv mptcp 10.17487/RFC8041 RFC8042 OSPF Two-Part Metric Z. Zhang L. Wang A. Lindem December 2016 ASCII HTML 9 OSPF Broadcast Interface SPF metrics Radio Networks

This document specifies an optional OSPF protocol extension to represent router metrics in a multi-access network in two parts: the metric from the router to the network and the metric from the network to the router. For such networks, the router-to-router metric for OSPF route computation is the sum of the two parts. This document updates RFC 2328.

 draft-ietf-ospf-two-part-metric-10 RFC2328 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC8042 RFC8043 Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space B. Sarikaya M. Boucadair January 2017 ASCII HTML 16 Neighbor Discovery Duplicate Address Detection ND Relay Agent

This document presents the source-address-dependent routing (SADR) problem space from the host's perspective. Both multihomed hosts and hosts with multiple interfaces are considered. Several network architectures are presented to illustrate why source address selection and next-hop resolution are needed in view of source-address-dependent routing.

The document is scoped on identifying a set of scenarios for source-address-dependent routing from the host's perspective and analyzing a set of solutions to mitigate encountered issues. The document does not make any solution recommendations.

 draft-sarikaya-6man-sadr-overview-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8043 RFC8044 Data Types in RADIUS A. DeKok January 2017 ASCII HTML 35

RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865. We provide an IANA registry for the data types and update the "RADIUS Attribute Types" registry to include a Data Type field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268.

 draft-ietf-radext-datatypes-08 RFC2865 RFC3162 RFC4072 RFC6158 RFC6572 RFC7268 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC8044 RFC8045 RADIUS Extensions for IP Port Configuration and Reporting D. Cheng J. Korhonen M. Boucadair S. Sivakumar January 2017 ASCII HTML 43 address sharing address continuity CGN NAT IP assignment port assignment port control port accounting port set port range IP/Port Limit Provider Wi-Fi Port forwarding Internal port External port Port mapping

This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN gateway, etc. This document defines a mapping between some RADIUS attributes and IP Flow Information Export (IPFIX) Information Element identifiers.

 draft-ietf-radext-ip-port-radius-ext-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=8045 10.17487/RFC8045 RFC8046 Host Mobility with the Host Identity Protocol T. Henderson Editor C. Vogt J. Arkko February 2017 ASCII HTML 37 hip multihoming extensions mobility extensions locator

This document defines a mobility extension to the Host Identity Protocol (HIP). Specifically, this document defines a "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines how the parameter can be used to preserve communications across a change to the IP address used by one or both peer hosts. The same LOCATOR_SET parameter can also be used to support end-host multihoming (as specified in RFC 8047). This document obsoletes RFC 5206.

 draft-ietf-hip-rfc5206-bis-14 RFC5206 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8046 RFC8047 Host Multihoming with the Host Identity Protocol T. Henderson Editor C. Vogt J. Arkko February 2017 ASCII HTML 22 hip multihoming extensions mobility extensions locator

This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility.

 draft-ietf-hip-multihoming-12 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8047 RFC8048 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence P. Saint-Andre December 2016 ASCII HTML 34 Extensible Messaging and Presence Protocol XMPP Jabber Session Initiation Protocol SIP SIMPLE presence availability

This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). This document obsoletes RFC 7248.

 draft-ietf-stox-7248bis-14 RFC7248 PROPOSED STANDARD PROPOSED STANDARD IETF art stox 10.17487/RFC8048 RFC8049 YANG Data Model for L3VPN Service Delivery S. Litkowski L. Tomotaki K. Ogaki February 2017 ASCII HTML 157 YANG l3sm l3vpn service model

This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.

 draft-ietf-l3sm-l3vpn-service-model-19 RFC8299 PROPOSED STANDARD PROPOSED STANDARD IETF ops l3sm 10.17487/RFC8049 RFC8050 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions C. Petrie T. King May 2017 ASCII HTML 6

This document extends the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by supporting the advertisement of multiple paths in BGP extensions.

 draft-ietf-grow-mrt-add-paths-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC8050 RFC8051 Applicability of a Stateful Path Computation Element (PCE) X. Zhang Editor I. Minei Editor January 2017 ASCII HTML 24 Stateful PCE Applicability

A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents.

 draft-ietf-pce-stateful-pce-app-08 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC8051 RFC8052 Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services B. Weis M. Seewald H. Falk June 2017 ASCII HTML 25

The IEC 61850 power utility automation family of standards describes methods using Ethernet and IP for distributing control and data frames within and between substations. The IEC 61850-90-5 and IEC 62351-9 standards specify the use of the Group Domain of Interpretation (GDOI) protocol (RFC 6407) to distribute security transforms for some IEC 61850 security protocols. This memo defines GDOI payloads to support those security protocols.

 draft-weis-gdoi-iec62351-9-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8052 RFC8053 HTTP Authentication Extensions for Interactive Clients Y. Oiwa H. Watanabe H. Takagi K. Maeda T. Hayashi Y. Ioku January 2017 ASCII HTML 28

This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means such as HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user agents. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentication.

 draft-ietf-httpauth-extension-09 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth 10.17487/RFC8053 RFC8054 Network News Transfer Protocol (NNTP) Extension for Compression K. Murchison J. Elie January 2017 ASCII HTML 23 NNTP Usenet NetNews COMPRESS DEFLATE compression

This document defines an extension to the Network News Transport Protocol (NNTP) that allows a connection to be effectively and efficiently compressed between an NNTP client and server.

 draft-murchison-nntp-compress-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8054 RFC8055 Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm C. Holmberg Y. Jiang January 2017 ASCII HTML 13 SIP Via transit realm

This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, 'received-realm', which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received by using a network realm value associated with the adjacent network.

 draft-holmberg-dispatch-received-realm-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8055 RFC8056 Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping J. Gould January 2017 ASCII HTML 11

This document describes the mapping of the Extensible Provisioning Protocol (EPP) statuses with the statuses registered for use in the Registration Data Access Protocol (RDAP). This document identifies gaps in the mapping, and registers RDAP statuses to fill those gaps to ensure that all of the EPP statuses specified in RFCs are supported in RDAP.

 draft-ietf-regext-epp-rdap-status-mapping-04 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8056 RFC8057 Uniform Resource Name (URN) Namespaces for Broadband Forum B. Stark D. Sinicrope W. Lupton January 2017 ASCII HTML 11 URN Broadband Forum BBF

This document describes the Namespace Identifiers (NIDs) "bbf", "broadband-forum-org", and "dslforum-org" for Uniform Resource Names (URNs) used to identify resources published by Broadband Forum (BBF). BBF specifies and manages resources that utilize these three URN identification models. Management activities for these and other resource types are handled by BBF.

 draft-bbf-bbf-urn-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8057 RFC8058 Signaling One-Click Functionality for List Email Headers J. Levine T. Herkula January 2017 ASCII HTML 9 email mailing list

This document describes a method for signaling a one-click function for the List-Unsubscribe email header field. The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field.

 draft-levine-herkula-oneclick-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8058 10.17487/RFC8058 RFC8059 PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments J. Arango S. Venaas I. Kouvelas D. Farinacci January 2017 ASCII HTML 9

This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol (LISP) sites. These attributes allow the receiver site to select between unicast and multicast underlying transport and to convey the RLOC (Routing Locator) address of the receiver ETR (Egress Tunnel Router) to the control plane of the root ITR (Ingress Tunnel Router).

 draft-ietf-pim-join-attributes-for-lisp-06 EXPERIMENTAL EXPERIMENTAL IETF rtg pim 10.17487/RFC8059 RFC8060 LISP Canonical Address Format (LCAF) D. Farinacci D. Meyer J. Snijders February 2017 ASCII HTML 36 Locator/ID Separation Protocol

This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System.

 draft-ietf-lisp-lcaf-22 RFC9306 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp http://www.rfc-editor.org/errata_search.php?rfc=8060 10.17487/RFC8060 RFC8061 Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality D. Farinacci B. Weis February 2017 ASCII HTML 18 lcaf

This document describes a mechanism for encrypting traffic encapsulated using the Locator/ID Separation Protocol (LISP). The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data plane from third-party surveillance attacks.

 draft-ietf-lisp-crypto-10 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC8061 RFC8062 Anonymity Support for Kerberos L. Zhu P. Leach S. Hartman S. Emery Editor February 2017 ASCII HTML 18

This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. This document obsoletes RFC 6112 and reclassifies that document as Historic. RFC 6112 contained errors, and the protocol described in that specification is not interoperable with any known implementation. This specification describes a protocol that interoperates with multiple implementations.

 draft-ietf-kitten-rfc6112bis-03 RFC6112 RFC4120 RFC4121 RFC4556 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8062 RFC8063 Key Relay Mapping for the Extensible Provisioning Protocol H.W. Ribbers M.W. Groeneweg R. Gieben A.L.J. Verschuren February 2017 ASCII HTML 16 Extensible Provisioning Protocol

This document describes an Extensible Provisioning Protocol (EPP) mapping for a key relay object that relays DNSSEC key material between EPP clients using the poll queue defined in RFC 5730.

This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact.

 draft-ietf-eppext-keyrelay-12 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8063 RFC8064 Recommendation on Stable IPv6 Interface Identifiers F. Gont A. Cooper D. Thaler W. Liu February 2017 ASCII HTML 9

This document changes the recommended default Interface Identifier (IID) generation scheme for cases where Stateless Address Autoconfiguration (SLAAC) is used to generate a stable IPv6 address. It recommends using the mechanism specified in RFC 7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941.

 draft-ietf-6man-default-iids-16 RFC2464 RFC2467 RFC2470 RFC2491 RFC2492 RFC2497 RFC2590 RFC3146 RFC3572 RFC4291 RFC4338 RFC4391 RFC5072 RFC5121 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8064 RFC8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms D. Thaler February 2017 ASCII HTML 10

This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link-layer protocols, and it provides advice to protocol designers on how to address such threats in adaptation-layer specifications for IPv6 over such links.

 draft-ietf-6lo-privacy-considerations-04 INFORMATIONAL INFORMATIONAL IETF int 6lo 10.17487/RFC8065 RFC8066 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines S. Chakrabarti G. Montenegro R. Droms J. Woodyatt February 2017 ASCII HTML 9

RFC 4944 defines the ESC dispatch type to allow additional dispatch octets in the 6LoWPAN header. The value of the ESC dispatch type was updated by RFC 6282; however, its usage was not defined in either RFC 6282 or RFC 4944. This document updates RFC 4944 and RFC 6282 by defining the ESC extension octet code points and listing registration entries for known use cases at the time of writing of this document.

 draft-ietf-6lo-dispatch-iana-registry-07 RFC4944 RFC6282 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8066 RFC8067 Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level B. Leiba January 2017 ASCII HTML 3 downref maturity last call

RFC 3967 specifies a process for allowing normative references to documents at lower maturity levels ("downrefs"), which involves calling out the downref explicitly in the Last Call notice. That requirement has proven to be unnecessarily strict, and this document updates RFC 3967, allowing the IESG more flexibility in accepting downrefs in Standards Track documents.

 draft-leiba-3967upd-downref-03 RFC3967 BCP0097 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8067 RFC8068 Session Initiation Protocol (SIP) Recording Call Flows R. Ravindranath P. Ravindran P. Kyzivat February 2017 ASCII HTML 34 sipreq

Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer-protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document lists call flows with metadata snapshots sent from a Session Recording Client (SRC) to a Session Recording Server (SRS).

 draft-ietf-siprec-callflows-08 INFORMATIONAL INFORMATIONAL IETF art siprec 10.17487/RFC8068 RFC8069 URN Namespace for IEEE A. Thomas February 2017 ASCII HTML 6

This document describes the Namespace Identifier (NID) 'ieee' for Uniform Resource Names (URNs) used to identify resources published by the Institute of Electrical and Electronics Engineers (IEEE). IEEE specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of the IEEE Registration Authority.

 draft-ieee-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8069 RFC8070 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension M. Short Editor S. Moore P. Miller February 2017 ASCII HTML 9

This document describes how to further extend the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension (defined in RFC 4556) to exchange an opaque data blob that a Key Distribution Center (KDC) can validate to ensure that the client is currently in possession of the private key during a PKINIT Authentication Service (AS) exchange.

 draft-ietf-kitten-pkinit-freshness-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8070 RFC8071 NETCONF Call Home and RESTCONF Call Home K. Watsen February 2017 ASCII HTML 13 call-home

This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client, respectively.

 draft-ietf-netconf-call-home-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8071 RFC8072 YANG Patch Media Type A. Bierman M. Bjorklund K. Watsen February 2017 ASCII HTML 39 RESTCONF

This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language.

 draft-ietf-netconf-yang-patch-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=8072 10.17487/RFC8072 RFC8073 Coordinating Attack Response at Internet Scale (CARIS) Workshop Report K. Moriarty M. Ford March 2017 ASCII HTML 16

This report documents the discussions and conclusions from the Coordinating Attack Response at Internet Scale (CARIS) workshop that took place in Berlin, Germany on 18 June 2015. The purpose of this workshop was to improve mutual awareness, understanding, and coordination among the diverse participating organizations and their representatives.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 draft-iab-carisreport-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8073 RFC8074 Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario J. Bi G. Yao J. Halpern E. Levy-Abegnoli Editor February 2017 ASCII HTML 12 SAVI-DHCP FCFS SAVI SEND SAVI

In networks that use multiple techniques for address assignment, the spoofing of addresses assigned by each technique can be prevented using the appropriate Source Address Validation Improvement (SAVI) methods. This document reviews how multiple SAVI methods can coexist in a single SAVI device and how collisions are resolved when the same binding entry is discovered by two or more methods.

 draft-ietf-savi-mix-15 PROPOSED STANDARD PROPOSED STANDARD IETF int savi 10.17487/RFC8074 RFC8075 Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) A. Castellani S. Loreto A. Rahman T. Fossati E. Dijk February 2017 ASCII HTML 40 CoAP HTTP-CoAP mapping HTTP-CoAP translation proxy implementation

This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice.

 draft-ietf-core-http-mapping-17 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8075 RFC8076 A Usage for Shared Resources in RELOAD (ShaRe) A. Knauf T. Schmidt Editor G. Hege M. Waehlisch March 2017 ASCII HTML 22 P2PSIP SIP Conferencing Voice over IP Peer-to-Peer Access Control Group Management Rendezvous

This document defines a REsource LOcation And Discovery (RELOAD) Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name that is useful whenever peer-independent rendezvous processes are required.

 draft-ietf-p2psip-share-10 PROPOSED STANDARD PROPOSED STANDARD IETF art p2psip 10.17487/RFC8076 RFC8077 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) L. Martini Editor G. Heron Editor February 2017 ASCII HTML 35

Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents.

This document is a rewrite of RFC 4447 for publication as an Internet Standard.

 draft-ietf-pals-rfc4447bis-05 RFC4447 RFC6723 STD0084 INTERNET STANDARD INTERNET STANDARD IETF rtg pals http://www.rfc-editor.org/errata_search.php?rfc=8077 10.17487/RFC8077 RFC8078 Managing DS Records from the Parent via CDS/CDNSKEY O. Gudmundsson P. Wouters March 2017 ASCII HTML 10 dnssec trust maintenance

RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point.

Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes.

This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records).

It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record.

 draft-ietf-dnsop-maintain-ds-06 RFC7344 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8078 10.17487/RFC8078 RFC8079 Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs) L. Miniero S. Garcia Murillo V. Pascual February 2017 ASCII HTML 16

SIP Back-to-Back User Agents (B2BUAs) are often designed to also be on the media path, rather than just to intercept signalling. This means that B2BUAs often implement an RTP or RTP Control Protocol (RTCP) stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP messages get lost because of mismatches in the reported data.

This document defines the proper behaviour B2BUAs should follow when acting on both the signalling plane and media plane in order to preserve the end-to-end functionality of RTCP.

 draft-ietf-straw-b2bua-rtcp-17 PROPOSED STANDARD PROPOSED STANDARD IETF art straw 10.17487/RFC8079 RFC8080 Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC O. Sury R. Edmonds February 2017 ASCII HTML 7 DNSSEC EdDSA ed25519 ed448

This document describes how to specify Edwards-curve Digital Security Algorithm (EdDSA) keys and signatures in DNS Security (DNSSEC). It uses EdDSA with the choice of two curves: Ed25519 and Ed448.

 draft-ietf-curdle-dnskey-eddsa-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8080 10.17487/RFC8080 RFC8081 The "font" Top-Level Media Type C. Lilley February 2017 ASCII HTML 18 Internet Media Types MIME

This memo serves to register and document the "font" top-level media type, under which subtypes for representation formats for fonts may be registered. This document also serves as a registration application for a set of intended subtypes, which are representative of some existing subtypes already in use, and currently registered under the "application" tree by their separate registrations.

 draft-ietf-justfont-toplevel-06 PROPOSED STANDARD PROPOSED STANDARD IETF art justfont 10.17487/RFC8081 RFC8082 Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs S. Wenger J. Lennox B. Burman M. Westerlund March 2017 ASCII HTML 11 Layered Codec Full Intra Request FIR Decoder Refresh Point

This document updates RFC 5104 by fixing a shortcoming in the specification language of the Codec Control Message Full Intra Request (FIR) description when using it with layered codecs. In particular, a decoder refresh point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless of whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 (which was updated by RFC 5506) have also been analyzed, and no corresponding shortcomings have been found.

 draft-ietf-avtext-avpf-ccm-layered-04 RFC5104 PROPOSED STANDARD PROPOSED STANDARD IETF art avtext 10.17487/RFC8082 RFC8083 Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions C. Perkins V. Singh March 2017 ASCII HTML 25

The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows.

This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms.

 draft-ietf-avtcore-rtp-circuit-breakers-18 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8083 RFC8084 Network Transport Circuit Breakers G. Fairhurst March 2017 ASCII HTML 24 Congestion control CC UDP Tunnel Encapsulation Transport Protocol Congestion Control

This document explains what is meant by the term "network transport Circuit Breaker". It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion- controlled traffic and explains where CBs are, and are not, needed. It also defines requirements for building a CB and the expected outcomes of using a CB within the Internet.

 draft-ietf-tsvwg-circuit-breaker-15 BCP0208 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC8084 RFC8085 UDP Usage Guidelines L. Eggert G. Fairhurst G. Shepherd March 2017 ASCII HTML 55 UDP guidelines

The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.

Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.

Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.

This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.

 draft-ietf-tsvwg-rfc5405bis-19 RFC5405 RFC8899 BCP0145 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=8085 10.17487/RFC8085 RFC8086 GRE-in-UDP Encapsulation L. Yong Editor E. Crabbe X. Xu T. Herbert March 2017 ASCII HTML 27

This document specifies a method of encapsulating network protocol packets within GRE and UDP headers. This GRE-in-UDP encapsulation allows the UDP source port field to be used as an entropy field. This may be used for load-balancing of GRE traffic in transit networks using existing Equal-Cost Multipath (ECMP) mechanisms. There are two applicability scenarios for GRE-in-UDP with different requirements: (1) general Internet and (2) a traffic-managed controlled environment. The controlled environment has less restrictive requirements than the general Internet.

 draft-ietf-tsvwg-gre-in-udp-encap-19 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=8086 10.17487/RFC8086 RFC8087 The Benefits of Using Explicit Congestion Notification (ECN) G. Fairhurst M. Welzl March 2017 ASCII HTML 19 ecn aqm sctp tcp

The goal of this document is to describe the potential benefits of applications using a transport that enables Explicit Congestion Notification (ECN). The document outlines the principal gains in terms of increased throughput, reduced delay, and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms to use ECN nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers, or other network devices.

 draft-ietf-aqm-ecn-benefits-08 INFORMATIONAL INFORMATIONAL IETF tsv aqm 10.17487/RFC8087 RFC8088 How to Write an RTP Payload Format M. Westerlund May 2017 ASCII HTML 65 RTP Payload format Process

This document contains information on how best to write an RTP payload format specification. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions.

 draft-ietf-payload-rtp-howto-14 RFC2736 INFORMATIONAL INFORMATIONAL IETF art payload 10.17487/RFC8088 RFC8089 The "file" URI Scheme M. Kerwin February 2017 ASCII HTML 19 uniform resource identifier URL

This document provides a more complete specification of the "file" Uniform Resource Identifier (URI) scheme and replaces the very brief definition in Section 3.10 of RFC 1738.

It defines a common syntax that is intended to interoperate across the broad spectrum of existing usages. At the same time, it notes some other current practices around the use of file URIs.

 draft-ietf-appsawg-file-scheme-16 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg http://www.rfc-editor.org/errata_search.php?rfc=8089 10.17487/RFC8089 RFC8090 Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG) R. Housley February 2017 ASCII HTML 7

This document outlines the procedures by which the IETF makes appointments to the Community Coordination Group (CCG), which provides advice and guidance to the IETF Trust in matters related to the IANA trademarks and the IANA domain names.

 draft-iab-ccg-appoint-process-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8090 RFC8091 A Media Type Structured Syntax Suffix for JSON Text Sequences E. Wilde February 2017 ASCII HTML 5

Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+json-seq" as a structured syntax suffix for JSON text sequences.

 draft-wilde-json-seq-suffix-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8091 RFC8092 BGP Large Communities Attribute J. Heitz Editor J. Snijders Editor K. Patel I. Bagdonas N. Hilliard February 2017 ASCII HTML 8 BGP large communities four-octet

This document describes the BGP Large Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use with all Autonomous System Numbers (ASNs) including four-octet ASNs.

 draft-ietf-idr-large-community-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=8092 10.17487/RFC8092 RFC8093 Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 J. Snijders February 2017 ASCII HTML 3

This document requests IANA to mark BGP path attribute values 30, 31, 129, 241, 242, and 243 as "Deprecated".

 draft-ietf-idr-deprecate-30-31-129-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8093 RFC8094 DNS over Datagram Transport Layer Security (DTLS) T. Reddy D. Wing P. Patil February 2017 ASCII HTML 13

DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect.

This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853.

 draft-ietf-dprive-dnsodtls-15 EXPERIMENTAL EXPERIMENTAL IETF int dprive 10.17487/RFC8094 RFC8095 Services Provided by IETF Transport Protocols and Congestion Control Mechanisms G. Fairhurst Editor B. Trammell Editor M. Kuehlewind Editor March 2017 ASCII HTML 54 Transmission Control Protocol (TCP) Multipath TCP (MPTCP) Stream Control Transmission Protocol (SCTP) User Datagram Protocol (UDP) UDP-Lite Datagram Congestion Control Protocol (DCCP) Internet Control Message Protocol (ICMP) Real-Time Transport Protocol (RTP) File Delivery over Unidirectional Transport/Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast NACK-Oriented Reliable Multicast (NORM) Transport Layer Security (TLS) Datagram TLS (DTLS) Hypertext Transport Protocol (HTTP) TAPS

This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Real-Time Transport Protocol (RTP), File Delivery over Unidirectional Transport / Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK- Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport. This survey provides background for the definition of transport services within the TAPS working group.

 draft-ietf-taps-transports-14 INFORMATIONAL INFORMATIONAL IETF tsv taps http://www.rfc-editor.org/errata_search.php?rfc=8095 10.17487/RFC8095 RFC8096 The IPv6-Specific MIB Modules Are Obsolete B. Fenner April 2017 ASCII HTML 65

In 2005-2006, the IPv6 MIB update group published updated versions of the IP-MIB, UDP-MIB, TCP-MIB, and IP-FORWARD-MIB modules, which use the InetAddressType/InetAddress construct to handle IPv4 and IPv6 in the same table. This document contains versions of the obsoleted IPV6-MIB, IPV6-TC, IPV6-ICMP-MIB, IPV6-TCP-MIB, and IPV6-UDP-MIB modules for the purpose of updating MIB module repositories. This document obsoletes RFCs 2452, 2454, 2465, and 2466 (i.e., the RFCs containing these MIBs) and reclassifies them as Historic.

 draft-ietf-6man-ipv6-mibs-obsolete-02 RFC2452 RFC2454 RFC2465 RFC2466 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC8096 RFC8097 BGP Prefix Origin Validation State Extended Community P. Mohapatra K. Patel J. Scudder D. Ward R. Bush March 2017 ASCII HTML 6

This document defines a new BGP opaque extended community to carry the origination Autonomous System (AS) validation state inside an autonomous system. Internal BGP (IBGP) speakers that receive this validation state can configure local policies that allow it to influence their decision process.

 draft-ietf-sidr-origin-validation-signaling-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8097 RFC8098 Message Disposition Notification T. Hansen Editor A. Melnikov Editor February 2017 ASCII HTML 37 delivery notification mdn

This memo defines a MIME content type that may be used by a Mail User Agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content type is intended to be machine processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and are often referred to as "read receipts," "acknowledgements," or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past.

Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multiprotocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail.

This document is an Internet Standard. It obsoletes RFC 3798 and updates RFC 2046 (message/partial media type handling) and RFC 3461 (Original-Recipient header field generation requirement).

 draft-ietf-appsawg-mdn-3798bis-16 RFC3798 RFC2046 RFC3461 STD0085 INTERNET STANDARD INTERNET STANDARD IETF art appsawg 10.17487/RFC8098 RFC8099 OSPF Topology-Transparent Zone H. Chen R. Li A. Retana Y. Yang Z. Liu February 2017 ASCII HTML 27 IGP OSPF TTZ

This document presents a Topology-Transparent Zone (TTZ) in an OSPF area. A TTZ comprises a group of routers and a number of links connecting these routers. Any router outside of the zone is not aware of the zone. A TTZ hides the internal topology of the TTZ from the outside. It does not directly advertise any internal information about the TTZ to a router outside of the TTZ. The information about the links and routers such as a link down inside the TTZ is not advertised to any router outside of the TTZ.

 draft-ietf-ospf-ttz-06 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC8099 RFC8100 Diffserv-Interconnection Classes and Practice R. Geib Editor D. Black March 2017 ASCII HTML 21 Diffserv Interconnection PHB Treatment Aggregate MPLS Short Pipe

This document defines a limited common set of Diffserv Per-Hop Behaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at (inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation. Many network providers operate Multiprotocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation of Diffserv for network interconnection among providers that use MPLS and apply the Short Pipe Model. While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS.

 draft-ietf-tsvwg-diffserv-intercon-14 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC8100 RFC8101 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk Service C. Holmberg J. Axell March 2017 ASCII HTML 6 Resource-Priority namespace Resource-priorith 3GPP IMS MCPTT

This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the 3GPP-defined Mission Critical Push To Talk (MCPTT) and places these namespaces in the corresponding IANA registry.

 draft-holmberg-dispatch-mcptt-rp-namespace-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8101 RFC8102 Remote-LFA Node Protection and Manageability P. Sarkar Editor S. Hegde C. Bowers H. Gredler S. Litkowski March 2017 ASCII HTML 22 LFA Remote-LFA IGP Node Protection

The loop-free alternates (LFAs) computed following the current remote-LFA specification guarantees only link protection. The resulting remote-LFA next hops (also called "PQ-nodes") may not guarantee node protection for all destinations being protected by it.

This document describes an extension to the remote-loop-free-based IP fast reroute mechanisms that specifies procedures for determining whether or not a given PQ-node provides node protection for a specific destination. The document also shows how the same procedure can be utilized for the collection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate paths is a precursor to applying the operator-defined policy for eliminating paths not fitting the constraints.

 draft-ietf-rtgwg-rlfa-node-protection-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8102 RFC8103 Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) R. Housley February 2017 ASCII HTML 9

This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator.

 draft-ietf-curdle-cms-chacha20-poly1305-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8103 10.17487/RFC8103 RFC8104 Pseudowire (PW) Endpoint Fast Failure Protection Y. Shen R. Aggarwal W. Henderickx Y. Jiang March 2017 ASCII HTML 43 pseudowire PW protection local repair fast reroute

This document specifies a fast mechanism for protecting pseudowires (PWs) transported by IP/MPLS tunnels against egress endpoint failures, including egress attachment circuit (AC) failure, egress provider edge (PE) failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Operating on the basis of multihomed customer edge (CE), redundant PWs, upstream label assignment, and context-specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. The router can restore a PW in the order of tens of milliseconds, by rerouting traffic around the failure to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure.

 draft-ietf-pals-endpoint-fast-protection-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8104 RFC8105 Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) P. Mariager J. Petersen Editor Z. Shelby M. Van de Logt D. Barthel May 2017 ASCII HTML 22 6LoWPAN ETSI IoT and Internet of Things

Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) is a low-power air interface technology that is proposed by the DECT Forum and is defined and specified by ETSI.

The DECT air interface technology has been used worldwide in communication devices for more than 20 years. It has primarily been used to carry voice for cordless telephony but has also been deployed for data-centric services.

DECT ULE is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation, etc. As the DECT ULE interface inherits many of the capabilities from DECT, it benefits from operation that is long-range and interference-free, worldwide- reserved frequency band, low silicon prices, and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE, such as for Internet of Things applications.

This document describes how IPv6 is transported over DECT ULE using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.

 draft-ietf-6lo-dect-ule-09 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8105 RFC8106 IPv6 Router Advertisement Options for DNS Configuration J. Jeong S. Park L. Beloeil S. Madanapalli March 2017 ASCII HTML 19 DNS Service DNS Option Recursive DNS Server Address DNS Search List Stateless Autoconfiguration

This document specifies IPv6 Router Advertisement (RA) options (called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts.

This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss.

 draft-ietf-6man-rdnss-rfc6106bis-16 RFC6106 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8106 RFC8107 Advertising Digital Identifier (Ad-ID) URN Namespace Definition J. Wold March 2017 ASCII HTML 7

Advertising Digital Identifiers (Ad-IDs) are used to identify advertising assets across all media platforms. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) "adid" for Ad-IDs.

 draft-adid-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8107 RFC8108 Sending Multiple RTP Streams in a Single RTP Session J. Lennox M. Westerlund Q. Wu C. Perkins March 2017 ASCII HTML 29

This memo expands and clarifies the behavior of Real-time Transport Protocol (RTP) endpoints that use multiple synchronization sources (SSRCs). This occurs, for example, when an endpoint sends multiple RTP streams in a single RTP session. This memo updates RFC 3550 with regard to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTP Control Protocol (RTCP) behavior. It also updates RFC 4585 to change and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages.

 draft-ietf-avtcore-rtp-multi-stream-11 RFC3550 RFC4585 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8108 RFC8109 Initializing a DNS Resolver with Priming Queries P. Koch M. Larson P. Hoffman March 2017 ASCII HTML 7

This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS Resource Record Set (RRset) for the root zone and the necessary address information for reaching the root servers.

 draft-ietf-dnsop-resolver-priming-11 BCP0209 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC8109 RFC8110 Opportunistic Wireless Encryption D. Harkins Editor W. Kumari Editor March 2017 ASCII HTML 12 opportunistic encryption wireless

This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media.

 draft-harkins-owe-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8110 10.17487/RFC8110 RFC8111 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) V. Fuller D. Lewis V. Ermagan A. Jain A. Smirnov May 2017 ASCII HTML 44 LISP DDT EID Locator Mapping System Map-Server Map-Referral Referral

This document describes the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically defined distribution of the EID namespace among a set of LISP-speaking servers called "DDT nodes". Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated.

 draft-ietf-lisp-ddt-09 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC8111 RFC8112 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG) D. Farinacci A. Jain I. Kouvelas D. Lewis May 2017 ASCII HTML 11

A simple tool called the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG), also referred to in this document as "rig", can be used to query the LISP- DDT hierarchy. This document describes how the "rig" tool works.

 draft-farinacci-lisp-rig-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8112 RFC8113 Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations M. Boucadair C. Jacquenet March 2017 ASCII HTML 6 Shared Experiment Code LISP codepoints Experiment Identifier Experiment ID LISP Experimental Registry LISP Extension Extending LISP

This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. It also defines a registry for LISP Packet Type allocations, thus updating RFC 6830.

 draft-ietf-lisp-type-iana-06 RFC9304 RFC6830 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC8113 RFC8114 Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network M. Boucadair C. Qin C. Jacquenet Y. Lee Q. Wang March 2017 ASCII HTML 23 Multicast DS-Lite IPv4-IPv6 Interconnection PREFIX64 SSM ASM IPv4 service continuity Multicast service continuity IPv6-only IPv6-only multicast PIM MLD IGMP A+P MAP MAP-E address-sharing CGN NAT64 IPv4 over IPv6 IPv6 Address Synthesis Any-Source Multicast Source-Specific Multicast

This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses an IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to customers serviced by Dual-Stack Lite (DS-Lite).

 draft-ietf-softwire-dslite-multicast-18 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8114 RFC8115 DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes M. Boucadair J. Qin T. Tsou X. Deng March 2017 ASCII HTML 9 PREFIX64 SSM ASM Prefix Discovery IPv4-Converted IPv6 Addresses IPv4 service continuity IPv6 Address Synthesis Any-Source Multicast Source-Specific Multicast PIM IPv4-IPv6 interconnection IPv4 over IPv6 A+P MAP MAP-E address-sharing CGN NAT64

This document defines a Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for multicast IPv4 service continuity solutions, which is used to carry the IPv6 prefixes to be used to build unicast and multicast IPv4-embedded IPv6 addresses.

 draft-ietf-softwire-multicast-prefix-option-15 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8115 RFC8116 Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2) T. Clausen U. Herberg J. Yi May 2017 ASCII HTML 26 MANET

This document analyzes common security threats to the Optimized Link State Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It also analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2 and how the vulnerabilities are mitigated.

 draft-ietf-manet-olsrv2-sec-threats-04 INFORMATIONAL INFORMATIONAL IETF rtg manet 10.17487/RFC8116 RFC8117 Current Hostname Practice Considered Harmful C. Huitema D. Thaler R. Winter March 2017 ASCII HTML 12

Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet's equivalent of walking around with a name tag affixed to your lapel. This current practice can significantly compromise your privacy, and something should change in order to mitigate these privacy threats.

There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document describes some of the protocols that reveal hostnames today and sketches another possible remedy, which is to replace static hostnames by frequently changing randomized values.

 draft-ietf-intarea-hostname-practice-05 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC8117 RFC8118 The application/pdf Media Type M. Hardy L. Masinter D. Markovic D. Johnson M. Bailey March 2017 ASCII HTML 12 Portable Document Format MIME type

The Portable Document Format (PDF) is an ISO standard (ISO 32000-1:2008) defining a final-form document representation language in use for document exchange, including on the Internet, since 1993. This document provides an overview of the PDF format and updates the media type registration of "application/pdf". It obsoletes RFC 3778.

 draft-hardy-pdf-mime-05 RFC3778 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8118 RFC8119 SIP "cause" URI Parameter for Service Number Translation M. Mohali M. Barnes March 2017 ASCII HTML 12 Cause

RFC 4458 (regarding SIP URIs for applications) defines a "cause" URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the User Agent Server (UAS) receiving the message. This document updates RFC 4458 by creating a new predefined value for the "cause" URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number. This document also provides guidance, which was missing in RFC 4458, for using the "cause" URI parameter within the History-Info header field, since this use is mandatory in some IP networks' implementations.

 draft-mohali-dispatch-cause-for-service-number-14 RFC4458 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8119 RFC8120 Mutual Authentication Protocol for HTTP Y. Oiwa H. Watanabe H. Takagi K. Maeda T. Hayashi Y. Ioku April 2017 ASCII HTML 53 HTTP authentication

This document specifies an authentication scheme for the Hypertext Transfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password.

 draft-ietf-httpauth-mutual-11 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth 10.17487/RFC8120 RFC8121 Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3) Y. Oiwa H. Watanabe H. Takagi K. Maeda T. Hayashi Y. Ioku April 2017 ASCII HTML 17 HTTP authentication

This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hypertext Transfer Protocol (HTTP).

 draft-ietf-httpauth-mutual-algo-07 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth 10.17487/RFC8121 RFC8122 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) J. Lennox C. Holmberg March 2017 ASCII HTML 18 SDP TLS Fingerprint Offer Answer

This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.

This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints.

 draft-ietf-mmusic-4572-update-13 RFC4572 RFC8844 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic http://www.rfc-editor.org/errata_search.php?rfc=8122 10.17487/RFC8122 RFC8123 Requirements for Marking SIP Messages to be Logged P. Dawes C. Arunachalam March 2017 ASCII HTML 11 logme troubleshooting debug logging

SIP networks use signaling monitoring tools to debug customer- reported problems and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between clients and, therefore, impractical to monitor SIP signaling end-to-end.

This document describes the requirements for adding an indicator to the SIP Protocol Data Unit (PDU) or a SIP message that marks the PDU as a candidate for logging. Such a marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signaling. However, such a marking can be carried end-to-end, including the SIP terminals, even if a session originates and terminates in different networks.

 draft-ietf-insipid-logme-reqs-12 INFORMATIONAL INFORMATIONAL IETF art insipid 10.17487/RFC8123 RFC8124 The Session Description Protocol (SDP) WebSocket Connection URI Attribute R. Ravindranath G. Salgueiro March 2017 ASCII HTML 12 Secure WebSocket Uniform Resource Identifier

The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport.

 draft-ietf-bfcpbis-sdp-ws-uri-09 PROPOSED STANDARD PROPOSED STANDARD IETF art bfcpbis 10.17487/RFC8124 RFC8125 Requirements for Password-Authenticated Key Agreement (PAKE) Schemes J. Schmidt April 2017 ASCII HTML 10 Password Key Agreement Password-Authenticated Key Agreement Cryptographic Protocol

Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password. This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group (CFRG).

 draft-irtf-cfrg-pake-reqs-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8125 RFC8126 Guidelines for Writing an IANA Considerations Section in RFCs M. Cotton B. Leiba T. Narten June 2017 ASCII HTML 47 internet assigned numbers authority values implementations code point protocol constant protocol parameter codepoint

Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).

To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.

This is the third edition of this document; it obsoletes RFC 5226.

 draft-leiba-cotton-iana-5226bis-20 RFC5226 BCP0026 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8126 10.17487/RFC8126 RFC8127 Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor D. Patki S. Gundavelli J. Lee Q. Fu L. Bertz August 2017 ASCII HTML 14 Binding Refresh Heartbeat

This specification defines a new extension, LMA-Controlled-MAG-Session-Params, to Proxy Mobile IPv6. This option can be used by the local mobility anchor (LMA) in a Proxy Mobile IPv6 domain for signaling a mobile access gateway (MAG) on enforcing specific values for various configuration parameters such as heartbeat and binding refresh parameters.

 draft-ietf-dmm-lma-controlled-mag-params-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dmm 10.17487/RFC8127 RFC8128 IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee C. Morgan March 2017 ASCII HTML 5

This memo outlines the process by which the IETF makes an appointment to the ICANN Root Zone Evolution Review Committee (RZERC).

 draft-iab-rzerc-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8128 RFC8129 Authentication Indicator in Kerberos Tickets A. Jain N. Kinder N. McCallum March 2017 ASCII HTML 6

This document updates RFC 4120, as it specifies an extension in the Kerberos protocol. It defines a new authorization data type, AD-AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions.

 draft-ietf-kitten-krb-auth-indicator-07 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8129 RFC8130 RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec V. Demjanenko D. Satterlee March 2017 ASCII HTML 30 MELP MELPe MELP2400 MELP1200 MELP600 SCIP-210 SCIP210

This document describes the RTP payload format for the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's three different speech encoding rates and sample frame sizes are supported. Comfort noise procedures and packet loss concealment are described in detail.

 draft-ietf-payload-melpe-06 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC8130 RFC8131 RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing X. Zhang H. Zheng Editor R. Gandhi Editor Z. Ali P. Brzozowski March 2017 ASCII HTML 15 Association Object LSP Reversion LSP Recovery GMPLS Make-Before-Break GMPLS 1+R GMPLS 1+1+R

In non-packet transport networks, there are requirements where the Generalized Multiprotocol Label Switching (GMPLS) end-to-end recovery scheme needs to employ a restoration Label Switched Path (LSP) while keeping resources for the working and/or protecting LSPs reserved in the network after the failure occurs.

This document reviews how the LSP association is to be provided using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of a GMPLS end-to-end recovery scheme when using restoration LSP where failed LSP is not torn down. In addition, this document discusses resource sharing-based setup and teardown of LSPs as well as LSP reversion procedures. No new signaling extensions are defined by this document, and it is strictly informative in nature.

 draft-ietf-teas-gmpls-resource-sharing-proc-08 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8131 RFC8132 PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) P. van der Stok C. Bormann A. Sehgal April 2017 ASCII HTML 21 CoAP

The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources.

This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource.

 draft-ietf-core-etch-04 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8132 RFC8133 The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol S. Smyshlyaev Editor E. Alekseev I. Oshkin V. Popov March 2017 ASCII HTML 51 cryptography secure channel elliptic curve

This document describes the Security Evaluated Standardized Password- Authenticated Key Exchange (SESPAKE) protocol. The SESPAKE protocol provides password-authenticated key exchange for usage in systems for protection of sensitive information. The security proofs of the protocol were made for situations involving an active adversary in the channel, including man-in-the-middle (MitM) attacks and attacks based on the impersonation of one of the subjects.

 draft-smyshlyaev-sespake-16 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8133 RFC8134 Management Incident Lightweight Exchange (MILE) Implementation Report C. Inacio D. Miyamoto May 2017 ASCII HTML 16 IODEF RID SCI INCH MILE Implementation

This document is a collection of implementation reports from vendors, consortiums, and researchers who have implemented one or more of the standards published from the IETF INCident Handling (INCH) and Management Incident Lightweight Exchange (MILE) working groups.

 draft-ietf-mile-implementreport-10 INFORMATIONAL INFORMATIONAL IETF sec mile 10.17487/RFC8134 RFC8135 Complex Addressing in IPv6 M. Danielson M. Nilsson April 1 2017 ASCII HTML 16

The 128-bit length of IPv6 addresses (RFC 4291) allows for new and innovative address schemes that can adapt to the challenges of today's complex network world. It also allows for new and improved security measures and supports advanced cloud computing challenges.

 draft-danielson-complexaddress-latest-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8135 10.17487/RFC8135 RFC8136 Additional Transition Functionality for IPv6 B. Carpenter R. Hinden April 1 2017 ASCII HTML 7

This document proposes an additional mechanism intended to both facilitate transition from IPv4 to IPv6 and improve the latter's security and privacy.

 draft-carpenter-addtransfunc-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8136 RFC8137 IEEE 802.15.4 Information Element for the IETF T. Kivinen P. Kinney May 2017 ASCII HTML 7 IE

IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to extend 802.15.4 in an interoperable manner. The IEEE 802.15 Assigned Numbers Authority (ANA) manages the registry of the Information Elements. This document formulates a request for ANA to allocate a number from that registry for the IETF and describes how the IE is formatted to provide subtypes.

 draft-kivinen-802-15-ie-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8137 RFC8138 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header P. Thubert Editor C. Bormann L. Toutain R. Cragie April 2017 ASCII HTML 37

This specification introduces a new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of Routing Protocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications.

 draft-ietf-roll-routing-dispatch-05 RFC9008 RFC9035 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=8138 10.17487/RFC8138 RFC8139 Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders D. Eastlake 3rd Y. Li M. Umair A. Banerjee F. Hu June 2017 ASCII HTML 41 DRB VLAN mapping inhibition port shutdown trill TRansparent Interconnection of Lots of Links

TRILL (Transparent Interconnection of Lots of Links) supports multi-access LAN (Local Area Network) links where a single link can have multiple end stations and TRILL switches attached. Where multiple TRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those TRILL switches called "Appointed Forwarders" as originally specified in RFC 6325, with the intent that native traffic in each VLAN be handled by at most one TRILL switch. This document clarifies and updates the Appointed Forwarder mechanism. It updates RFCs 6325 and 7177 and obsoletes RFC 6439.

 draft-ietf-trill-rfc6439bis-05 RFC6439 RFC6325 RFC7177 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8139 RFC8140 The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character A. Farrel April 1 2017 ASCII HTML 16

Ever since Gutenberg discovered and patented ASCII and the corresponding "Courier New" font with its now-famous "ten" point size, artisans and artificers have striven to represent their views of the world in print.

Similarly, starting from Darwin's discovery of the hippogriff and his subsequent registration of the creature as an International Trade Mark, men (and some women) have struggled to catalog the fabulous variety that is called "nature".

This document supplies a number of representations of all manner of things (both elemental and hypothetical) supplied by some of our best collectors of curios and delivered in a manner that may well be reused by the cunning document author.

 draft-farrel-ascii-art-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8140 10.17487/RFC8140 RFC8141 Uniform Resource Names (URNs) P. Saint-Andre J. Klensin April 2017 ASCII HTML 40 Uniform Resource Name URN Uniform Resource Identifier URI

A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406.

 draft-ietf-urnbis-rfc2141bis-urn-22 RFC2141 RFC3406 PROPOSED STANDARD PROPOSED STANDARD IETF art urnbis 10.17487/RFC8141 RFC8142 GeoJSON Text Sequences S. Gillies April 2017 ASCII HTML 5 JSON Geospatial JavaScript Object Notation

This document describes the GeoJSON text sequence format and "application/geo+json-seq" media type. This format is based on JavaScript Object Notation (JSON) text sequences and GeoJSON, and it makes arbitrarily large geographic datasets incrementally parseable without restricting the form of GeoJSON texts within a sequence.

 draft-ietf-geojson-text-sequence-05 PROPOSED STANDARD PROPOSED STANDARD IETF art geojson 10.17487/RFC8142 RFC8143 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) J. Elie April 2017 ASCII HTML 13 NNTP Usenet NetNews TLS STARTTLS

This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport Layer Security (TLS). It modernizes the NNTP usage of TLS to be consistent with TLS best current practices. This document updates RFC 4642.

 draft-elie-nntp-tls-recommendations-05 RFC4642 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8143 RFC8144 Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV) K. Murchison April 2017 ASCII HTML 28 http prefer webav caldav

This document defines how the Prefer header field (RFC 7240) can be used by a Web Distributed Authoring and Versioning (WebDAV) client to request that certain behaviors be employed by a server while constructing a response to a request. Furthermore, it defines the new "depth-noroot" preference.

 draft-murchison-webdav-prefer-14 RFC7240 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8144 RFC8145 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) D. Wessels W. Kumari P. Hoffman April 2017 ASCII HTML 13 DNS DNSSEC Trust Anchor

The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone.

 draft-ietf-dnsop-edns-key-tag-05 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8145 RFC8146 Adding Support for Salted Password Databases to EAP-pwd D. Harkins April 2017 ASCII HTML 11 Password-Authenticated Key Exchange PAKE Dictionary Attack Authentication EAP

EAP-pwd is an Extensible Authentication Protocol (EAP) method that utilizes a shared password for authentication using a technique that is resistant to dictionary attacks. It includes support for raw keys and double hashing of a password in the style of Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2), but it does not include support for salted passwords. There are many existing databases of salted passwords, and it is desirable to allow their use with EAP-pwd.

 draft-harkins-salted-eap-pwd-08 RFC5931 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8146 10.17487/RFC8146 RFC8147 Next-Generation Pan-European eCall R. Gellens H. Tschofenig May 2017 ASCII HTML 43 emergency call calls emergency call emergency calls vehicle acn aacn automatic crash notification automatic collision notification advanced automatic crash notification advanced automatic collision notification crash vehicle-initiated

This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan-European in-vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data.

This document also registers MIME media types and an Emergency Call Data Type for the eCall vehicle data and metadata/control data, and an INFO package to enable carrying this data in SIP INFO requests.

Although this specification is designed to meet the requirements of next-generation Pan-European eCall (NG-eCall), it is specified generically such that the technology can be reused or extended to suit requirements across jurisdictions.

 draft-ietf-ecrit-ecall-27 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit 10.17487/RFC8147 RFC8148 Next-Generation Vehicle-Initiated Emergency Calls R. Gellens B. Rosen H. Tschofenig May 2017 ASCII HTML 40 emergency call calls emergency call emergency calls vehicle acn aacn automatic crash notification automatic collision notification advanced automatic crash notification advanced automatic collision notification crash vehicle-initiated ecall

This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data.

This document also registers a MIME media type and Emergency Call Data Type for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash) and an INFO package to enable carrying this and related data in SIP INFO requests. An external specification for the data format, contents, and structure is referenced in this document.

This document reuses the technical aspects of next-generation Pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems (IVSs) within Europe and other regions). However, this document specifies use of a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the IETF eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and it adds attribute values to the metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy (circuit-switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context.

 draft-ietf-ecrit-car-crash-23 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit http://www.rfc-editor.org/errata_search.php?rfc=8148 10.17487/RFC8148 RFC8149 RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) T. Saad Editor R. Gandhi Editor Z. Ali R. Venator Y. Kamite April 2017 ASCII HTML 17 RSVP fragmentation RSVP fragment identifier P2MP-TE tree reoptimization P2MP-TE tree re-evaluation Preferable P2MP-TE tree Inter-domain P2MP-TE

The reoptimization of a Point-to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) may be triggered based on the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization method, or the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method. This document discusses the application of the existing mechanisms for path reoptimization of loosely routed Point-to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them. When reoptimizing a large number of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, the S2L sub-LSP descriptor list may need to be semantically fragmented. This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list.

 draft-ietf-teas-p2mp-loose-path-reopt-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8149 RFC8150 MPLS Transport Profile Linear Protection MIB S. Kingston Smiler M. Venkatesan D. King S. Aldrin J. Ryoo April 2017 ASCII HTML 48 Network Management Management Information Base MIB SMIv2

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing Multiprotocol Label Switching - Transport Profile (MPLS-TP) linear protection.

 draft-ietf-mpls-tp-linear-protection-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8150 RFC8151 Use Cases for Data Center Network Virtualization Overlay Networks L. Yong L. Dunbar M. Toy A. Isaac V. Manral May 2017 ASCII HTML 16

This document describes Network Virtualization over Layer 3 (NVO3) use cases that can be deployed in various data centers and serve different data-center applications.

 draft-ietf-nvo3-use-case-17 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC8151 RFC8152 CBOR Object Signing and Encryption (COSE) J. Schaad July 2017 ASCII HTML 121 CoAP ECC Elliptic Curve

Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.

 draft-ietf-cose-msg-24 RFC9052 RFC9053 PROPOSED STANDARD PROPOSED STANDARD IETF sec cose http://www.rfc-editor.org/errata_search.php?rfc=8152 10.17487/RFC8152 RFC8153 Digital Preservation Considerations for the RFC Series H. Flanagan April 2017 ASCII HTML 18 archive archiving

The RFC Editor is both the publisher and the archivist for the RFC Series. This document applies specifically to the archivist role of the RFC Editor. It provides guidance on when and how to preserve RFCs and describes the tools required to view or re-create RFCs as necessary. This document also highlights gaps in the current process and suggests compromises to balance cost with best practice.

 draft-iab-rfc-preservation-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8153 RFC8154 Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout C. Hellwig May 2017 ASCII HTML 30 NFSv4

The Parallel Network File System (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The Small Computer System Interface (SCSI) layout type is defined in this document as an extension to pNFS to allow the use of SCSI-based block storage devices.

 draft-ietf-nfsv4-scsi-layout-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8154 RFC8155 Traversal Using Relays around NAT (TURN) Server Auto Discovery P. Patil T. Reddy D. Wing April 2017 ASCII HTML 16

Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto-discovery mechanisms that a TURN client could use with minimal or no configuration. This document describes three such mechanisms for TURN server discovery.

This document updates RFC 5766 to relax the requirement for mutual authentication in certain cases.

 draft-ietf-tram-turn-server-discovery-12 RFC5766 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC8155 RFC8156 DHCPv6 Failover Protocol T. Mrugalski K. Kinnear June 2017 ASCII HTML 96 DHCPv6 Failover

DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" (RFC 3315) does not offer server redundancy. This document defines a protocol implementation to provide DHCPv6 failover, a mechanism for running two servers with the capability for either server to take over clients' leases in case of server failure or network partition. It meets the requirements for DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC 7031).

 draft-ietf-dhc-dhcpv6-failover-protocol-06 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8156 RFC8157 Huawei's GRE Tunnel Bonding Protocol N. Leymann C. Heidemann M. Zhang B. Sarikaya M. Cullen May 2017 ASCII HTML 44 Hybrid Access Bandwidth Aggregation Bonding Tunnel GRE Channel Hybrid Access Aggregation Point Home Gateway

There is an emerging demand for solutions that provide redundancy and load-sharing across wired and cellular links from a single Service Provider, so that a single subscriber is provided with bonded access to heterogeneous connections at the same time.

In this document, GRE (Generic Routing Encapsulation) Tunnel Bonding is specified as an enabling approach for bonded access to a wired and a wireless network in customer premises, e.g., homes. In GRE Tunnel Bonding, two GRE tunnels, one per network connection, are set up and bonded together to form a single GRE tunnel for a subscriber. Compared with each subconnection, the bonded connections promise increased access capacity and improved reliability. The solution described in this document is currently implemented by Huawei and deployed by Deutsche Telekom AG. This document will enable other developers to build interoperable implementations.

 draft-zhang-gre-tunnel-bonding-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8157 RFC8158 IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events S. Sivakumar R. Penno December 2017 ASCII HTML 34 template

Network operators require NAT devices to log events like creation and deletion of translations and information about the resources that the NAT device is managing. In many cases, the logs are essential to identify an attacker or a host that was used to launch malicious attacks and for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices use proprietary formats; hence, it is difficult to expect consistent behavior. This lack of standardization makes it difficult to write the Collector applications that would receive this data and process it to present useful information. This document describes the formats for logging NAT events.

 draft-ietf-behave-ipfix-nat-logging-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8158 RFC8159 Keyed IPv6 Tunnel M. Konstantynowicz Editor G. Heron Editor R. Schatzmayr W. Henderickx May 2017 ASCII HTML 12 L2TPv3 pseudowire

This document describes a tunnel encapsulation for Ethernet over IPv6 with a mandatory 64-bit cookie for connecting Layer 2 (L2) Ethernet attachment circuits identified by IPv6 addresses. The encapsulation is based on the Layer 2 Tunneling Protocol Version 3 (L2TPv3) over IP and does not use the L2TPv3 control plane.

 draft-ietf-l2tpext-keyed-ipv6-tunnel-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2tpext 10.17487/RFC8159 RFC8160 IUTF8 Terminal Mode in Secure Shell (SSH) S. Tatham D. Tucker April 2017 ASCII HTML 4 Secure Shell SSH

This document specifies a new opcode in the Secure Shell terminal modes encoding. The new opcode describes the widely used IUTF8 terminal mode bit, which indicates that terminal I/O uses UTF-8 character encoding.

 draft-sgtatham-secsh-iutf8-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8160 RFC8161 Benchmarking the Neighbor Discovery Protocol W. Cerveny R. Bonica R. Thomas May 2017 ASCII HTML 17 IPv6 Scaling NDP

This document provides benchmarking procedures for the Neighbor Discovery Protocol (NDP). It also proposes metrics by which an NDP implementation's scaling capabilities can be measured.

 draft-ietf-bmwg-ipv6-nd-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8161 RFC8162 Using Secure DNS to Associate Certificates with Domain Names for S/MIME P. Hoffman J. Schlyter May 2017 ASCII HTML 11

This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS.

 draft-ietf-dane-smime-16 EXPERIMENTAL EXPERIMENTAL IETF sec dane http://www.rfc-editor.org/errata_search.php?rfc=8162 10.17487/RFC8162 RFC8163 Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks K. Lynn Editor J. Martocci C. Neilson S. Donaldson May 2017 ASCII HTML 27

Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks.

 draft-ietf-6lo-6lobac-08 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo http://www.rfc-editor.org/errata_search.php?rfc=8163 10.17487/RFC8163 RFC8164 Opportunistic Security for HTTP/2 M. Nottingham M. Thomson May 2017 ASCII HTML 10 Opportunistic Security HTTP

This document describes how "http" URIs can be accessed using Transport Layer Security (TLS) and HTTP/2 to mitigate pervasive monitoring attacks. This mechanism not a replacement for "https" URIs; it is vulnerable to active attacks.

 draft-ietf-httpbis-http2-encryption-11 HISTORIC EXPERIMENTAL IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8164 10.17487/RFC8164 RFC8165 Design Considerations for Metadata Insertion T. Hardie May 2017 ASCII HTML 7 surveillance proxy proxying middlebox

The IAB published RFC 7624 in response to several revelations of pervasive attacks on Internet communications. This document considers the implications of protocol designs that associate metadata with encrypted flows. In particular, it asserts that designs that share metadata only by explicit actions at the host are preferable to designs in which middleboxes insert metadata.

 draft-hardie-privsec-metadata-insertion-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8165 RFC8166 Remote Direct Memory Access Transport for Remote Procedure Call Version 1 C. Lever Editor W. Simpson T. Talpey June 2017 ASCII HTML 55 RPC-over-RDMA

This document specifies a protocol for conveying Remote Procedure Call (RPC) messages on physical transports capable of Remote Direct Memory Access (RDMA). This protocol is referred to as the RPC-over- RDMA version 1 protocol in this document. It requires no revision to application RPC protocols or the RPC protocol itself. This document obsoletes RFC 5666.

 draft-ietf-nfsv4-rfc5666bis-11 RFC5666 RFC8797 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=8166 10.17487/RFC8166 RFC8167 Bidirectional Remote Procedure Call on RPC-over-RDMA Transports C. Lever June 2017 ASCII HTML 13 NFS-over-RDMA RPC-over-RDMA

Minor versions of Network File System (NFS) version 4 newer than minor version 0 work best when Remote Procedure Call (RPC) transports can send RPC transactions in both directions on the same connection. This document describes how RPC transport endpoints capable of Remote Direct Memory Access (RDMA) convey RPCs in both directions on a single connection.

 draft-ietf-nfsv4-rpcrdma-bidirection-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8167 RFC8168 DHCPv6 Prefix-Length Hint Issues T. Li C. Liu Y. Cui May 2017 ASCII HTML 9 DHCPv6 Dynamic Host Configuration Protocol IPv6 Prefix Prefix Delegation Prefix Length Hint Address Allocation

DHCPv6 Prefix Delegation allows a client to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but it is unclear about how the client and server should act in different situations involving the prefix-length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the client and server could do in different situations.

 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8168 RFC8169 Residence Time Measurement in MPLS Networks G. Mirsky S. Ruffini E. Gray J. Drake S. Bryant A. Vainshtein May 2017 ASCII HTML 30 G-ACh Resident Time MPLS

This document specifies a new Generic Associated Channel (G-ACh) for Residence Time Measurement (RTM) and describes how it can be used by time synchronization protocols within an MPLS domain.

Residence time is the variable part of the propagation delay of timing and synchronization messages; knowing this delay for each message allows for a more accurate determination of the delay to be taken into account when applying the value included in a Precision Time Protocol event message.

 draft-ietf-mpls-residence-time-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8169 RFC8170 Planning for Protocol Adoption and Subsequent Transitions D. Thaler Editor May 2017 ASCII HTML 22 transition plan

Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan.

 draft-iab-protocol-transitions-08 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8170 RFC8171 Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms D. Eastlake 3rd L. Dunbar R. Perlman Y. Li June 2017 ASCII HTML 55 Push Pull ESADI ES-IS

This document describes mechanisms for providing directory service to TRILL (Transparent Interconnection of Lots of Links) edge switches. The directory information provided can be used in reducing multi-destination traffic, particularly ARP / Neighbor Discovery (ND) and unknown unicast flooding. It can also be used to detect traffic with forged source addresses.

 draft-ietf-trill-directory-assist-mechanisms-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8171 RFC8172 Considerations for Benchmarking Virtual Network Functions and Their Infrastructure A. Morton July 2017 ASCII HTML 15

The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. This memo investigates additional considerations when network functions are virtualized and performed in general-purpose hardware.

 draft-ietf-bmwg-virtual-net-05 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8172 RFC8173 Precision Time Protocol Version 2 (PTPv2) Management Information Base V. Shankarkumar L. Montini T. Frost G. Dowd June 2017 ASCII HTML 64

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in internets based on TCP or IP. In particular, it defines objects for managing networks using the Precision Time Protocol (PTP), specified in IEEE Std. 1588-2008.

This memo specifies a MIB module in a manner that is both compliant to the Structure of Management Information version 2 (SMIv2) and semantically identical to the peer SMIv1 definitions.

 draft-ietf-tictoc-ptp-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF int tictoc 10.17487/RFC8173 RFC8174 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words B. Leiba May 2017 ASCII HTML 4

RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

 draft-leiba-rfc2119-update-02 RFC2119 BCP0014 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8174 10.17487/RFC8174 RFC8175 Dynamic Link Exchange Protocol (DLEP) S. Ratliff S. Jury D. Satterwhite R. Taylor B. Berry June 2017 ASCII HTML 82

When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. This document introduces a new protocol called the Dynamic Link Exchange Protocol (DLEP), which provides a bidirectional, event-driven communication channel between the router and the modem to facilitate communication of changing link characteristics.

 draft-ietf-manet-dlep-29 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=8175 10.17487/RFC8175 RFC8176 Authentication Method Reference Values M. Jones P. Hunt A. Nadalin June 2017 ASCII HTML 15 Authentication Method Reference Authentication Method,

The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values.

 draft-ietf-oauth-amr-values-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=8176 10.17487/RFC8176 RFC8177 YANG Data Model for Key Chains A. Lindem Editor Y. Qu D. Yeung I. Chen J. Zhang June 2017 ASCII HTML 25

This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated.

 draft-ietf-rtgwg-yang-key-chain-24 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8177 RFC8178 Rules for NFSv4 Extensions and Minor Versions D. Noveck July 2017 ASCII HTML 26

This document describes the rules relating to the extension of the NFSv4 family of protocols. It covers the creation of minor versions, the addition of optional features to existing minor versions, and the correction of flaws in features already published as Proposed Standards. The rules relating to the construction of minor versions and the interaction of minor version implementations that appear in this document supersede the minor versioning rules in RFC 5661 and other RFCs defining minor versions.

 draft-ietf-nfsv4-versioning-11 RFC5661 RFC7862 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8178 RFC8179 Intellectual Property Rights in IETF Technology S. Bradner J. Contreras May 2017 ASCII HTML 26 IPR copyright

The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879.

 draft-bradner-rfc3979bis-13 RFC3979 RFC4879 RFC2026 BCP0079 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8179 10.17487/RFC8179 RFC8180 Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration X. Vilajosana Editor K. Pister T. Watteyne May 2017 ASCII HTML 28

This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. This minimal mode of operation specifies the baseline set of protocols that need to be supported and the recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time-Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrapping and defines the proper link between the IETF protocols that interface to IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH-compliant devices.

 draft-ietf-6tisch-minimal-21 BCP0210 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int 6tisch http://www.rfc-editor.org/errata_search.php?rfc=8180 10.17487/RFC8180 RFC8181 A Publication Protocol for the Resource Public Key Infrastructure (RPKI) S. Weiler A. Sonalker R. Austein July 2017 ASCII HTML 21 SIDR

This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. Even in cases where a certificate issuer runs its own publication repository, it can be useful to run the certificate engine itself on a different machine from the publication repository. This document defines a protocol which addresses these needs.

 draft-ietf-sidr-publication-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8181 RFC8182 The RPKI Repository Delta Protocol (RRDP) T. Bruijnzeels O. Muravskiy B. Weber R. Austein July 2017 ASCII HTML 24

In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files.

 draft-ietf-sidr-delta-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=8182 10.17487/RFC8182 RFC8183 An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services R. Austein July 2017 ASCII HTML 23 RPKI

This note describes a simple out-of-band protocol to ease setup of the Resource Public Key Infrastructure (RPKI) provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable means which provides acceptable data integrity and authentication.

This setup protocol is not part of the provisioning or publication protocol; rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging keying material used to authenticate those relationships.

 draft-ietf-sidr-rpki-oob-setup-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8183 RFC8184 Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires W. Cheng L. Wang H. Li S. Davari J. Dong June 2017 ASCII HTML 11 mpls mpls-tp

This document describes a framework and several scenarios for a pseudowire (PW) dual-homing local protection mechanism that avoids unnecessary switchovers and does not depend on whether a control plane is used. A Dual-Node Interconnection (DNI) PW is used to carry traffic between the dual-homing Provider Edge (PE) nodes when a failure occurs in one of the Attachment Circuits (AC) or PWs. This PW dual-homing local protection mechanism is complementary to existing PW protection mechanisms.

 draft-ietf-pals-mpls-tp-dual-homing-protection-06 INFORMATIONAL INFORMATIONAL IETF rtg pals 10.17487/RFC8184 RFC8185 Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection W. Cheng L. Wang H. Li J. Dong A. D'Alessandro June 2017 ASCII HTML 17 mpls mpls-tp

In some scenarios, MPLS Transport Profile (MPLS-TP) pseudowires (PWs) (RFC 5921) may be statically configured when a dynamic control plane is not available. A fast protection mechanism for MPLS-TP PWs is needed to protect against the failure of an Attachment Circuit (AC), the failure of a Provider Edge (PE), or a failure in the Packet Switched Network (PSN). The framework and typical scenarios of dual- homing PW local protection are described in RFC 8184. This document proposes a dual-homing coordination mechanism for MPLS-TP PWs that is used for state exchange and switchover coordination between the dual- homing PEs for dual-homing PW local protection.

 draft-ietf-pals-mpls-tp-dual-homing-coordination-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8185 RFC8186 Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP) G. Mirsky I. Meilik June 2017 ASCII HTML 8 IPPM TWAMP IEEE 1588 PTPv2

This document describes an OPTIONAL feature for active performance measurement protocols that allows use of the Precision Time Protocol timestamp format defined in IEEE 1588v2, as an alternative to the Network Time Protocol that is currently used.

 draft-ietf-ippm-twamp-time-format-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC8186 RFC8187 Indicating Character Encoding and Language for HTTP Header Field Parameters J. Reschke September 2017 ASCII HTML 13

By default, header field values in Hypertext Transfer Protocol (HTTP) messages cannot easily carry characters outside the US-ASCII coded character set. RFC 2231 defines an encoding mechanism for use in parameters inside Multipurpose Internet Mail Extensions (MIME) header field values. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a simplified profile of the encoding defined in RFC 2231.

This document obsoletes RFC 5987.

 draft-ietf-httpbis-rfc5987bis-05 RFC5987 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC8187 RFC8188 Encrypted Content-Encoding for HTTP M. Thomson June 2017 ASCII HTML 16 http content coding content encoding encryption aead

This memo introduces a content coding for HTTP that allows message payloads to be encrypted.

 draft-ietf-httpbis-encryption-encoding-09 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8188 10.17487/RFC8188 RFC8189 Multi-Cost Application-Layer Traffic Optimization (ALTO) S. Randriamasy W. Roome N. Schwan October 2017 ASCII HTML 29 ALTO Information Resources Network Map PID Filtered Network Map Endpoint Property Service Endpoint Cost Service Multi-Cost Filtered Multi-Cost Map Multi-Cost Data Format Testable Cost Types or-constraints

The Application-Layer Traffic Optimization (ALTO) protocol, specified in RFC 7285, defines several services that return various metrics describing the costs between network endpoints.

This document defines a new service that allows an ALTO Client to retrieve several cost metrics in a single request for an ALTO filtered cost map and endpoint cost map. In addition, it extends the constraints to further filter those maps by allowing an ALTO Client to specify a logical combination of tests on several cost metrics.

 draft-ietf-alto-multi-cost-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC8189 RFC8190 Updates to the Special-Purpose IP Address Registries R. Bonica M. Cotton B. Haberman L. Vegoda June 2017 ASCII HTML 6

This memo updates the IANA IPv4 and IPv6 Special-Purpose Address Registries to address issues raised by the definition of a "global" prefix. It also corrects several errors in registry entries to ensure the integrity of the IANA Special-Purpose Address Registries.

This memo updates RFC 6890.

 draft-bchv-rfc6890bis-07 RFC6890 BCP0153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8190 RFC8191 Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6) Z. Yan J. Lee X. Lee August 2017 ASCII HTML 10 PMIPv6 HNP HNP renumbering LMA handover

In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned with a Home Network Prefix (HNP) during its initial attachment, and the MN configures its Home Address (HoA) with the HNP. During the movement of the MN, the HNP remains unchanged to keep ongoing communications associated with the HoA. However, the current PMIPv6 specification does not specify related operations when HNP renumbering has occurred (e.g., due to change of service provider or site topology, etc.). In this document, a solution to support HNP renumbering is proposed, as an optional extension of the PMIPv6 specification.

 draft-ietf-dmm-hnprenum-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dmm 10.17487/RFC8191 RFC8192 Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases S. Hares D. Lopez M. Zarny C. Jacquenet R. Kumar J. Jeong July 2017 ASCII HTML 29 I2NSF

This document sets out the problem statement for Interface to Network Security Functions (I2NSF) and outlines some companion use cases.

 draft-ietf-i2nsf-problem-and-use-cases-16 INFORMATIONAL INFORMATIONAL IETF sec i2nsf 10.17487/RFC8192 RFC8193 Information Model for Large-Scale Measurement Platforms (LMAPs) T. Burbridge P. Eardley M. Bagnulo J. Schoenwaelder August 2017 ASCII HTML 53

This Information Model applies to the Measurement Agent within an LMAP framework. As such, it outlines the information that is configured or preconfigured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol- and device-independent view of the Measurement Agent that can be implemented via one or more Control and Report Protocols.

 draft-ietf-lmap-information-model-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops lmap 10.17487/RFC8193 RFC8194 A YANG Data Model for LMAP Measurement Agents J. Schoenwaelder V. Bajpai August 2017 ASCII HTML 59 LMAP YANG

This document defines a data model for Large-Scale Measurement Platforms (LMAPs). The data model is defined using the YANG data modeling language.

 draft-ietf-lmap-yang-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops lmap 10.17487/RFC8194 RFC8195 Use of BGP Large Communities J. Snijders J. Heasley M. Schmidt June 2017 ASCII HTML 15 large BGP communities

This document presents examples and inspiration for operator application of BGP Large Communities. Based on operational experience with BGP Communities, this document suggests logical categories of BGP Large Communities and demonstrates an orderly manner of organizing community values within them to achieve typical goals in routing policy. Any operator can consider using the concepts presented as the basis for their own BGP Large Communities repertoire.

 draft-ietf-grow-large-communities-usage-07 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC8195 RFC8196 IS-IS Autoconfiguration B. Liu Editor L. Ginsberg B. Decraene I. Farrer M. Abrahamsson July 2017 ASCII HTML 15 isis auto-configuration

This document specifies IS-IS autoconfiguration mechanisms. The key components are IS-IS System ID self-generation, duplication detection, and duplication resolution. These mechanisms provide limited IS-IS functions and are therefore suitable for networks where plug-and-play configuration is expected.

 draft-ietf-isis-auto-conf-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC8196 RFC8197 A SIP Response Code for Unwanted Calls H. Schulzrinne July 2017 ASCII HTML 8 SIP robocall unwanted response code

This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.

 draft-ietf-sipcore-status-unwanted-06 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8197 RFC8198 Aggressive Use of DNSSEC-Validated Cache K. Fujiwara A. Kato W. Kumari July 2017 ASCII HTML 13 Negative cache NCACHE NSEC NSEC3

The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances.

This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards.

 draft-ietf-dnsop-nsec-aggressiveuse-10 RFC4035 RFC9077 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8198 RFC8199 YANG Module Classification D. Bogdanovic B. Claise C. Moberg July 2017 ASCII HTML 11 service element standard vendor user controller orchestrator

The YANG data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards development organizations (SDOs), open-source software projects, vendors, and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules.

A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups.

This document describes a set of concepts and associated terms to support consistent classification of YANG modules.

 draft-ietf-netmod-yang-model-classification-08 INFORMATIONAL INFORMATIONAL IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8199 10.17487/RFC8199 RFC8200 Internet Protocol, Version 6 (IPv6) Specification S. Deering R. Hinden July 2017 ASCII HTML 42 IPv6 internet protocol next generation ipng flow label

This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.

 draft-ietf-6man-rfc2460bis-13 RFC2460 STD0086 INTERNET STANDARD INTERNET STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=8200 10.17487/RFC8200 RFC8201 Path MTU Discovery for IP version 6 J. McCann S. Deering J. Mogul R. Hinden Editor July 2017 ASCII HTML 19 MTU-IPv6 Internet Protocol IPv6 link MTU path MTU PMTU Path MTU Discovery

This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC 1981.

 draft-ietf-6man-rfc1981bis-08 RFC1981 STD0087 INTERNET STANDARD INTERNET STANDARD IETF int 6man 10.17487/RFC8201 RFC8202 IS-IS Multi-Instance L. Ginsberg S. Previdi W. Henderickx June 2017 ASCII HTML 16

This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System to Intermediate System (IS-IS) routing protocol instances.

Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies. Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs.

This document obsoletes RFC 6822.

 draft-ietf-isis-mi-bis-03 RFC6822 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC8202 RFC8203 BGP Administrative Shutdown Communication J. Snijders J. Heitz J. Scudder July 2017 ASCII HTML 6 BGP cease shutdown

This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486.

 draft-ietf-idr-shutdown-10 RFC9003 RFC4486 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8203 RFC8204 Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV) M. Tahhan B. O'Mahony A. Morton September 2017 ASCII HTML 24

This memo describes the contributions of the Open Platform for NFV (OPNFV) project on Virtual Switch Performance (VSPERF), particularly in the areas of test setups and configuration parameters for the system under test. This project has extended the current and completed work of the Benchmarking Methodology Working Group in the IETF and references existing literature. The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. Therefore, this memo describes the additional considerations when virtual switches are implemented on general-purpose hardware. The expanded tests and benchmarks are also influenced by the OPNFV mission to support virtualization of the "telco" infrastructure.

 draft-ietf-bmwg-vswitch-opnfv-04 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8204 RFC8205 BGPsec Protocol Specification M. Lepinski Editor K. Sriram Editor September 2017 ASCII HTML 45 BGP BGPsec BGP AS-path protection BGP Security

This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route.

 draft-ietf-sidr-bgpsec-protocol-23 RFC8206 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8205 RFC8206 BGPsec Considerations for Autonomous System (AS) Migration W. George S. Murphy September 2017 ASCII HTML 16 as-migration SIDR BGPsec AS_PATH

This document discusses considerations and methods for supporting and securing a common method for Autonomous System (AS) migration within the BGPsec protocol.

 draft-ietf-sidr-as-migration-06 RFC8205 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=8206 10.17487/RFC8206 RFC8207 BGPsec Operational Considerations R. Bush September 2017 ASCII HTML 10 BGP RPKI Routing Security

Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. Operational practices are expected to evolve as BGPsec is formalized and initially deployed.

 draft-ietf-sidr-bgpsec-ops-16 BCP0211 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC8207 RFC8208 BGPsec Algorithms, Key Formats, and Signature Formats S. Turner O. Borchert September 2017 ASCII HTML 19

This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure").

This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures.

 draft-ietf-sidr-bgpsec-algs-18 RFC8608 RFC7935 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8208 RFC8209 A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests M. Reynolds S. Turner S. Kent September 2017 ASCII HTML 15

This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end entity (EE) certificates specified by this profile are issued to routers within an AS. Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Resource extension. An EE certificate of this type asserts that the router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this document updates the RPKI Resource Certificates Profile (RFC 6487).

 draft-ietf-sidr-bgpsec-pki-profiles-21 RFC6487 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8209 RFC8210 The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 R. Bush R. Austein September 2017 ASCII HTML 35

In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them.

This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810.

 draft-ietf-sidr-rpki-rtr-rfc6810-bis-09 RFC6810 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8210 RFC8211 Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) S. Kent D. Ma September 2017 ASCII HTML 26 BGP Security

This document analyzes actions by or against a Certification Authority (CA) or an independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is done from the perspective of an affected INR holder. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository manager) and fetched by Relying Parties (RPs). The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data.

 draft-ietf-sidr-adverse-actions-04 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC8211 RFC8212 Default External BGP (EBGP) Route Propagation Behavior without Policies J. Mauch J. Snijders G. Hankins July 2017 ASCII HTML 7 reject BGP EBGP

This document updates RFC 4271 by defining the default behavior of a BGP speaker when there is no Import or Export Policy associated with an External BGP session.

 draft-ietf-grow-bgp-reject-08 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC8212 RFC8213 Security of Messages Exchanged between Servers and Relay Agents B. Volz Y. Pal August 2017 ASCII HTML 8

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents but does not require encryption. With recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay-to-relay and relay-to-server communication for DHCPv6 and relay-to-server communication for DHCPv4.

 draft-ietf-dhc-relay-server-security-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8213 RFC8214 Virtual Private Wire Service Support in Ethernet VPN S. Boutros A. Sajassi S. Salam J. Drake J. Rabadan August 2017 ASCII HTML 17

This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure.

 draft-ietf-bess-evpn-vpws-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess http://www.rfc-editor.org/errata_search.php?rfc=8214 10.17487/RFC8214 RFC8215 Local-Use IPv4/IPv6 Translation Prefix T. Anderson August 2017 ASCII HTML 7 IPv6 transition IVI MAP NAT64 SIIT SIIT-DC Transition

This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms.

 draft-ietf-v6ops-v4v6-xlat-prefix-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC8215 RFC8216 HTTP Live Streaming R. Pantos Editor W. May August 2017 ASCII HTML 60 HTML streaming media

This document describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 7 of this protocol.

 draft-pantos-http-live-streaming-23 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8216 10.17487/RFC8216 RFC8217 Clarifications for When to Use the name-addr Production in SIP Messages R. Sparks August 2017 ASCII HTML 6

RFC 3261 constrained several SIP header fields whose grammar contains the "name-addr / addr-spec" alternative to use name-addr when certain characters appear. Unfortunately, it expressed the constraints with prose copied into each header field definition, and at least one header field was missed. Further, the constraint has not been copied into documents defining extension headers whose grammar contains the alternative.

This document updates RFC 3261 to state the constraint generically and clarifies that the constraint applies to all SIP header fields where there is a choice between using name-addr or addr-spec. It also updates the RFCs that define extension SIP header fields using the alternative to clarify that the constraint applies (RFCs 3325, 3515, 3892, 4508, 5002, 5318, 5360, and 5502).

 draft-ietf-sipcore-name-addr-guidance-02 RFC3261 RFC3325 RFC3515 RFC3892 RFC4508 RFC5002 RFC5318 RFC5360 RFC5502 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8217 RFC8218 Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) J. Yi B. Parrein August 2017 ASCII HTML 26 MANET

This document specifies a multipath extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths for Mobile Ad Hoc Networks (MANETs). Considering the characteristics of MANETs, especially the dynamic network topology, using multiple paths can increase aggregated throughput and improve the reliability by avoiding single route failures. The interoperability with OLSRv2 is retained.

 draft-ietf-manet-olsrv2-multipath-15 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC8218 RFC8219 Benchmarking Methodology for IPv6 Transition Technologies M. Georgescu L. Pislaru G. Lencse August 2017 ASCII HTML 30 Single Translation Technologies Double Translation Technologies Encapsulation Technologies NAT64 DNS64 MAP-E MAP-T DSLite 464XLAT 6PE DNS Resolution Performance Overload Scalability Typical Latency Worst Case Latency PDV IPDV

Benchmarking methodologies that address the performance of network interconnect devices that are IPv4- or IPv6-capable exist, but the IPv6 transition technologies are outside of their scope. This document provides complementary guidelines for evaluating the performance of IPv6 transition technologies. More specifically, this document targets IPv6 transition technologies that employ encapsulation or translation mechanisms, as dual-stack nodes can be tested using the recommendations of RFCs 2544 and 5180. The methodology also includes a metric for benchmarking load scalability.

 draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8219 RFC8220 Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) O. Dornon J. Kotalwar V. Hemige R. Qiu Z. Zhang September 2017 ASCII HTML 43 multicast

This document describes the procedures and recommendations for Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via PIM snooping and proxying.

With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, PEs do not flood PIM Join/Prune messages but only generate their own and send them out of certain ports, based on the control states built from downstream Join/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Edge (CE) devices and is useful for reducing PIM control traffic in a VPLS domain.

This document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports and are not flooded, thereby avoiding the triggering of PIM Join suppression on CE devices.

 draft-ietf-pals-vpls-pim-snooping-06 INFORMATIONAL INFORMATIONAL IETF rtg pals 10.17487/RFC8220 RFC8221 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) P. Wouters D. Migault J. Mattsson Y. Nir T. Kivinen October 2017 ASCII HTML 15 IPsec IKE

This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable.

 draft-ietf-ipsecme-rfc7321bis-06 RFC7321 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8221 RFC8222 Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery A. Sullivan September 2017 ASCII HTML 11 DNS mDNS DNS-SD

Despite its name, DNS-Based Service Discovery (DNS-SD) can use naming systems other than DNS when looking for services. Moreover, when it uses DNS, DNS-SD uses the full capability of DNS, rather than using a subset of available octets. This is of particular relevance where some environments use DNS labels that conform to Internationalized Domain Names for Applications (IDNA), and other environments use labels containing Unicode characters (such as containing octets corresponding to characters encoded as UTF-8). In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for the selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner.

 draft-ietf-dnssd-mdns-dns-interop-04 INFORMATIONAL INFORMATIONAL IETF int dnssd 10.17487/RFC8222 RFC8223 Application-Aware Targeted LDP S. Esale R. Torvi L. Jalil U. Chunduri K. Raza August 2017 ASCII HTML 18

Recent Targeted Label Distribution Protocol (tLDP) applications, such as remote Loop-Free Alternates (LFAs) and BGP auto-discovered pseudowires, may automatically establish a tLDP session with any Label Switching Router (LSR) in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However, the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate the Targeted Application Capability (TAC) during LDP session initialization. As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications. In addition, each targeted application is mapped to LDP Forwarding Equivalence Class (FEC) elements to advertise only necessary LDP FEC label bindings over the session. This document updates RFC 7473 for enabling advertisement of LDP FEC label bindings over the session.

 draft-ietf-mpls-app-aware-tldp-09 RFC7473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=8223 10.17487/RFC8223 RFC8224 Authenticated Identity Management in the Session Initiation Protocol (SIP) J. Peterson C. Jennings E. Rescorla C. Wendt February 2018 ASCII HTML 46 SIP Secure Origin Identification Communication Security RTCWeb Certificates Real-Time Communication

The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.

This document obsoletes RFC 4474.

 draft-ietf-stir-rfc4474bis-16 RFC4474 RFC8946 PROPOSED STANDARD PROPOSED STANDARD IETF art stir http://www.rfc-editor.org/errata_search.php?rfc=8224 10.17487/RFC8224 RFC8225 PASSporT: Personal Assertion Token C. Wendt J. Peterson February 2018 ASCII HTML 25

This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship.

 draft-ietf-stir-passport-11 PROPOSED STANDARD PROPOSED STANDARD IETF art stir http://www.rfc-editor.org/errata_search.php?rfc=8225 10.17487/RFC8225 RFC8226 Secure Telephone Identity Credentials: Certificates J. Peterson S. Turner February 2018 ASCII HTML 24 TNAuthorizationList JWTClaimConstraints

In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP.

 draft-ietf-stir-certificates-17 RFC9118 PROPOSED STANDARD PROPOSED STANDARD IETF art stir http://www.rfc-editor.org/errata_search.php?rfc=8226 10.17487/RFC8226 RFC8227 MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology W. Cheng L. Wang H. Li H. van Helvoort J. Dong August 2017 ASCII HTML 56 wrapping protection short-wrapping protection steering protection ring protection shared ring protection protection switching

This document describes requirements, architecture, and solutions for MPLS-TP Shared-Ring Protection (MSRP) in a ring topology for point- to-point (P2P) services. The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654. This document defines the Ring Protection Switching (RPS) protocol that is used to coordinate the protection behavior of the nodes on an MPLS ring.

 draft-ietf-mpls-tp-shared-ring-protection-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8227 RFC8228 Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels A. Freytag August 2017 ASCII HTML 24 LGR Variant IDN

Rules for validating identifier labels and alternate representations of those labels (variants) are known as Label Generation Rulesets (LGRs); they are used for the implementation of identifier systems such as Internationalized Domain Names (IDNs). This document describes ways to design LGRs to support variant labels. In designing LGRs, it is important to ensure that the label generation rules are consistent and well behaved in the presence of variants. The design decisions can then be expressed using the XML representation of LGRs that is defined in RFC 7940.

 draft-freytag-lager-variant-rules-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8228 10.17487/RFC8228 RFC8229 TCP Encapsulation of IKE and IPsec Packets T. Pauly S. Touati R. Mantha August 2017 ASCII HTML 25 IKE IKEv2 IPsec TCP

This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP.

 draft-ietf-ipsecme-tcp-encaps-10 RFC9329 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=8229 10.17487/RFC8229 RFC8230 Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages M. Jones September 2017 ASCII HTML 12 Cryptography Digital Signature Encryption

The CBOR Object Signing and Encryption (COSE) specification defines cryptographic message encodings using Concise Binary Object Representation (CBOR). This specification defines algorithm encodings and representations enabling RSA algorithms to be used for COSE messages. Encodings are specified for the use of RSA Probabilistic Signature Scheme (RSASSA-PSS) signatures, RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) encryption, and RSA keys.

 draft-jones-cose-rsa-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8230 RFC8231 Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE E. Crabbe I. Minei J. Medved R. Varga September 2017 ASCII HTML 57 Stateful PCE

The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.

Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.

 draft-ietf-pce-stateful-pce-21 RFC8786 RFC9353 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8231 10.17487/RFC8231 RFC8232 Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE E. Crabbe I. Minei J. Medved R. Varga X. Zhang D. Dhody September 2017 ASCII HTML 26 Stateful PCE state synchronization optimization

A stateful Path Computation Element (PCE) has access to not only the information disseminated by the network's Interior Gateway Protocol (IGP) but also the set of active paths and their reserved resources for its computation. The additional Label Switched Path (LSP) state information allows the PCE to compute constrained paths while considering individual LSPs and their interactions. This requires a State Synchronization mechanism between the PCE and the network, the PCE and Path Computation Clients (PCCs), and cooperating PCEs. The basic mechanism for State Synchronization is part of the stateful PCE specification. This document presents motivations for optimizations to the base State Synchronization procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions.

 draft-ietf-pce-stateful-sync-optimizations-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8232 RFC8233 Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs) D. Dhody Q. Wu V. Manral Z. Ali K. Kumaki September 2017 ASCII HTML 31 PCE PCEP service-aware metric BU LBU LRBU

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation.

IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation.

 draft-ietf-pce-pcep-service-aware-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8233 10.17487/RFC8233 RFC8234 Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode J. Ryoo T. Cheung H. van Helvoort I. Busi G. Wen August 2017 ASCII HTML 9 APS mode initialization mpls-tp linear protection

This document contains updates to MPLS Transport Profile (MPLS-TP) linear protection in Automatic Protection Switching (APS) mode defined in RFC 7271. The updates provide rules related to the initialization of the Protection State Coordination (PSC) Control Logic (in which the state machine resides) when operating in APS mode and clarify the operation related to state transition table lookup.

 draft-ietf-mpls-tp-aps-updates-04 RFC7271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8234 RFC8235 Schnorr Non-interactive Zero-Knowledge Proof F. Hao Editor September 2017 ASCII HTML 13 Zero-Knowledge Proof Schnorr NIZK proof Identification protocol

This document describes the Schnorr non-interactive zero-knowledge (NIZK) proof, a non-interactive variant of the three-pass Schnorr identification scheme. The Schnorr NIZK proof allows one to prove the knowledge of a discrete logarithm without leaking any information about its value. It can serve as a useful building block for many cryptographic protocols to ensure that participants follow the protocol specification honestly. This document specifies the Schnorr NIZK proof in both the finite field and the elliptic curve settings.

 draft-hao-schnorr-06 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8235 10.17487/RFC8235 RFC8236 J-PAKE: Password-Authenticated Key Exchange by Juggling F. Hao Editor September 2017 ASCII HTML 15

This document specifies a Password-Authenticated Key Exchange by Juggling (J-PAKE) protocol. This protocol allows the establishment of a secure end-to-end communication channel between two remote parties over an insecure network solely based on a shared password, without requiring a Public Key Infrastructure (PKI) or any trusted third party.

 draft-hao-jpake-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8236 RFC8237 MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs L. Martini G. Swallow E. Bellagamba October 2017 ASCII HTML 20

This document describes a method for generating an aggregated pseudowire (PW) status message transmitted for a statically configured PW on a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) to indicate the status of one or more PWs carried on the LSP.

The method for transmitting the PW status information is not new; however, this protocol extension allows a Service Provider (SP) to reliably monitor the individual PW status while not overwhelming the network with multiple periodic status messages. This is achieved by sending a single cumulative summary status verification message for all the PWs grouped in the same LSP.

 draft-ietf-pals-status-reduction-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8237 RFC8238 Data Center Benchmarking Terminology L. Avramov J. Rapp August 2017 ASCII HTML 20

The purposes of this informational document are to establish definitions and describe measurement techniques for data center benchmarking, as well as to introduce new terminology applicable to performance evaluations of data center network equipment. This document establishes the important concepts for benchmarking network switches and routers in the data center and is a prerequisite for the test methodology document (RFC 8239). Many of these terms and methods may be applicable to network equipment beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere.

 draft-ietf-bmwg-dcbench-terminology-19 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8238 RFC8239 Data Center Benchmarking Methodology L. Avramov J. Rapp August 2017 ASCII HTML 19

The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center. RFC 8238 is a prerequisite for this document, as it contains terminology that is considered normative. Many of these terms and methods may be applicable beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere.

 draft-ietf-bmwg-dcbench-methodology-18 INFORMATIONAL INFORMATIONAL IETF ops bmwg http://www.rfc-editor.org/errata_search.php?rfc=8239 10.17487/RFC8239 RFC8240 Report from the Internet of Things Software Update (IoTSU) Workshop 2016 H. Tschofenig S. Farrell September 2017 ASCII HTML 27 Security Firmware Updates Software Updates Internet of Things

This document provides a summary of the Internet of Things Software Update (IoTSU) Workshop that took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges, and solutions for bringing software and firmware updates to IoT devices. This report summarizes the discussions and lists recommendations to the standards community.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 draft-iab-iotsu-workshop-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8240 RFC8241 Interface to the Routing System (I2RS) Security-Related Requirements S. Hares D. Migault J. Halpern September 2017 ASCII HTML 20

This document presents security-related requirements for the Interface to the Routing System (I2RS) protocol, which provides a new interface to the routing system described in the I2RS architecture document (RFC 7921). The I2RS protocol is implemented by reusing portions of existing IETF protocols and adding new features to them. One such reuse is of the security features of a secure transport (e.g., Transport Layer Security (TLS), Secure SHell (SSH) Protocol, Datagram TLS (DTLS)) such as encryption, message integrity, mutual peer authentication, and anti-replay protection. The new I2RS features to consider from a security perspective are as follows: a priority mechanism to handle multi-headed write transactions, an opaque secondary identifier that identifies an application using the I2RS client, and an extremely constrained read-only non-secure transport.

 draft-ietf-i2rs-protocol-security-requirements-17 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC8241 RFC8242 Interface to the Routing System (I2RS) Ephemeral State Requirements J. Haas S. Hares September 2017 ASCII HTML 12

"An Architecture for the Interface to the Routing System" (RFC 7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) that any protocol suite attempting to meet the needs of the Interface to the Routing System (I2RS) protocol has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol.

 draft-ietf-i2rs-ephemeral-state-23 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC8242 RFC8243 Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL) R. Perlman D. Eastlake 3rd M. Zhang A. Ghanwani H. Zhai September 2017 ASCII HTML 29 aggregaged nickname unique nickname

Although TRILL is based on IS-IS, which supports multilevel unicast routing, extending TRILL to multiple levels has challenges that are not addressed by the already-existing capabilities of IS-IS. One issue is with the handling of multi-destination packet distribution trees. Other issues are with TRILL switch nicknames. How are such nicknames allocated across a multilevel TRILL network? Do nicknames need to be unique across an entire multilevel TRILL network? Or can they merely be unique within each multilevel area?

This informational document enumerates and examines alternatives based on a number of factors including backward compatibility, simplicity, and scalability; it makes recommendations in some cases.

 draft-ietf-trill-rbridge-multilevel-07 INFORMATIONAL INFORMATIONAL IETF rtg trill 10.17487/RFC8243 RFC8244 Special-Use Domain Names Problem Statement T. Lemon R. Droms W. Kumari October 2017 ASCII HTML 25 SUN SUTLD RFC6761

The policy defined in RFC 6761 for IANA registrations in the "Special-Use Domain Names" registry has been shown, through experience, to present challenges that were not anticipated when RFC 6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names.

This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names.

 draft-ietf-dnsop-sutld-ps-08 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC8244 RFC8245 Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444 T. Clausen C. Dearlove U. Herberg H. Rogge October 2017 ASCII HTML 29 MANET

RFC 5444 specifies a generalized Mobile Ad Hoc Network (MANET) packet/message format and describes an intended use for multiplexed MANET routing protocol messages; this use is mandated by RFC 5498 when using the MANET port or protocol number that it specifies. This document updates RFC 5444 by providing rules and recommendations for how the multiplexer operates and how protocols can use the packet/message format. In particular, the mandatory rules prohibit a number of uses that have been suggested in various proposals and that would have led to interoperability problems, to the impediment of protocol extension development, and/or to an inability to use optional generic parsers.

 draft-ietf-manet-rfc5444-usage-07 RFC5444 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8245 RFC8246 HTTP Immutable Responses P. McManus September 2017 ASCII HTML 6

The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.

 draft-ietf-httpbis-immutable-03 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC8246 RFC8247 Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) Y. Nir T. Kivinen P. Wouters D. Migault September 2017 ASCII HTML 19 IPsec IKE internet key exchange

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulating Security Payload (ESP).

 draft-ietf-ipsecme-rfc4307bis-18 RFC4307 RFC7296 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8247 RFC8248 Security Automation and Continuous Monitoring (SACM) Requirements N. Cam-Winget L. Lorenzin September 2017 ASCII HTML 20 posture assessment posture validation software integrity network authorization software compliance

This document defines the scope and set of requirements for the Security Automation and Continuous Monitoring (SACM) architecture, data model, and transfer protocols. The requirements and scope are based on the agreed-upon use cases described in RFC 7632.

 draft-ietf-sacm-requirements-18 INFORMATIONAL INFORMATIONAL IETF sec sacm 10.17487/RFC8248 RFC8249 Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation M. Zhang X. Zhang D. Eastlake 3rd R. Perlman S. Chatterjee September 2017 ASCII HTML 15

The base IETF TRILL (Transparent Interconnection of Lots of Links) protocol has a TRILL campus-wide MTU feature, specified in RFCs 6325 and 7177, that assures that link-state changes can be successfully flooded throughout the campus while being able to take advantage of a campus-wide capability to support jumbo packets. This document specifies recommended updates to that MTU feature to take advantage, for appropriate link-local packets, of link-local MTUs that exceed the TRILL campus MTU. In addition, it specifies an efficient algorithm for local MTU testing. This document updates RFCs 6325, 7177, and 7780.

 draft-ietf-trill-mtu-negotiation-08 RFC6325 RFC7177 RFC7780 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8249 RFC8250 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option N. Elkins R. Hamilton M. Ackermann September 2017 ASCII HTML 30

To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header. The field limits, calculations, and usage in measurement of PDM are included in this document.

 draft-ietf-ippm-6man-pdm-option-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC8250 RFC8251 Updates to the Opus Audio Codec JM. Valin K. Vos October 2017 ASCII HTML 12

This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716. It updates the normative decoder implementation included in Appendix A of RFC 6716. The changes fix real and potential security-related issues, as well as minor quality-related issues.

 draft-ietf-codec-opus-update-10 RFC6716 PROPOSED STANDARD PROPOSED STANDARD IETF art codec 10.17487/RFC8251 RFC8252 OAuth 2.0 for Native Apps W. Denniss J. Bradley October 2017 ASCII HTML 21

OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice.

 draft-ietf-oauth-native-apps-12 RFC6749 BCP0212 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=8252 10.17487/RFC8252 RFC8253 PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) D. Lopez O. Gonzalez de Dios Q. Wu D. Dhody October 2017 ASCII HTML 26 PCE PCEP PCEPS security authentication encryption TLS

The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.

This document updates RFC 5440 in regards to the PCEP initialization phase procedures.

 draft-ietf-pce-pceps-18 RFC5440 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8253 10.17487/RFC8253 RFC8254 Uniform Resource Name (URN) Namespace Registration Transition J. Klensin J. Hakala October 2017 ASCII HTML 9 ISBN ISSN NBN national bibliography number

The original registration procedure for formal Uniform Resource Name (URN) namespaces required IETF Consensus. That requirement discouraged some registrations and increased the risk for problems that could occur as a result. The requirements have now been changed by RFC 8141, which adopts a different model, focusing on encouraging registration and publication of information for all appropriate namespaces. This document clarifies the status of relevant older RFCs and confirms and documents advice to IANA about selected existing registrations. This document also obsoletes RFCs 3044 and 3187 and moves them to Historic status. These RFCs describe the ISSN and ISBN namespaces, which are now outdated because the descriptions reside in registration templates.

 draft-ietf-urnbis-ns-reg-transition-08 RFC3044 RFC3187 PROPOSED STANDARD PROPOSED STANDARD IETF art urnbis 10.17487/RFC8254 RFC8255 Multiple Language Content Type N. Tomkinson N. Borenstein October 2017 ASCII HTML 19 multiple language multi lingual content type email mime

This document defines the 'multipart/multilingual' content type, which is an addition to the Multipurpose Internet Mail Extensions (MIME) standard. This content type makes it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings.

 draft-ietf-slim-multilangcontent-14 PROPOSED STANDARD PROPOSED STANDARD IETF art slim 10.17487/RFC8255 RFC8256 Requirements for Hitless MPLS Path Segment Monitoring A. D'Alessandro L. Andersson S. Ueno K. Arai Y. Koike October 2017 ASCII HTML 16 HPSM MPLS MPLS Transport Profile mpls-tp OAM monitoring Hitless Path Segment Monitoring Path Segment Monitoring HPSM

One of the most important Operations, Administration, and Maintenance (OAM) capabilities for transport-network operation is fault localization. An in-service, on-demand path segment monitoring function of a transport path is indispensable, particularly when the service monitoring function is activated only between endpoints. However, the current segment monitoring approach defined for MPLS (including the MPLS Transport Profile (MPLS-TP)) in RFC 6371 "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks" has drawbacks. This document provides an analysis of the existing MPLS-TP OAM mechanisms for the path segment monitoring and provides requirements to guide the development of new OAM tools to support Hitless Path Segment Monitoring (HPSM).

 draft-ietf-mpls-tp-temporal-hitless-psm-14 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC8256 RFC8257 Data Center TCP (DCTCP): TCP Congestion Control for Data Centers S. Bensley D. Thaler P. Balasubramanian L. Eggert G. Judd October 2017 ASCII HTML 17 TCP ECN DCTCP congestion control

This Informational RFC describes Data Center TCP (DCTCP): a TCP congestion control scheme for data-center traffic. DCTCP extends the Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high-burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, discusses the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents DCTCP as currently implemented by several major operating systems. DCTCP, as described in this specification, is applicable to deployments in controlled environments like data centers, but it must not be deployed over the public Internet without additional measures.

 draft-ietf-tcpm-dctcp-10 INFORMATIONAL INFORMATIONAL IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=8257 10.17487/RFC8257 RFC8258 Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) D. Ceccarelli L. Berger October 2017 ASCII HTML 7 OSPF-TE GMPLS

This document defines a generic information structure for information carried in routing protocol Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) fields. This "Generalized SCSI" can be used with routing protocols that define GMPLS ISCDs and any specific technology. This document does not modify any existing technology-specific formats and is defined for use in conjunction with new GMPLS Switching Capability types. The context for this document is Generalized MPLS, and the reader is expected to be familiar with the GMPLS architecture and associated protocol standards.

 draft-ietf-teas-gmpls-scsi-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8258 RFC8259 The JavaScript Object Notation (JSON) Data Interchange Format T. Bray Editor December 2017 ASCII HTML 16

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.

This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.

 draft-ietf-jsonbis-rfc7159bis-04 RFC7159 STD0090 INTERNET STANDARD INTERNET STANDARD IETF art jsonbis http://www.rfc-editor.org/errata_search.php?rfc=8259 10.17487/RFC8259 RFC8260 Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol R. Stewart M. Tuexen S. Loreto R. Seggelmann November 2017 ASCII HTML 23

The Stream Control Transmission Protocol (SCTP) is a message-oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head-of-line blocking at the sender. The interleaving of user messages is required for WebRTC data channels.

Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined in this document. A stream scheduler can choose to either implement, or not implement, user message interleaving.

 draft-ietf-tsvwg-sctp-ndata-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8260 RFC8261 Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets M. Tuexen R. Stewart R. Jesup S. Loreto November 2017 ASCII HTML 10

The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence, explicit IP addresses cannot be used in the SCTP control chunks. As a consequence, the SCTP associations carried over DTLS can only be single-homed.

 draft-ietf-tsvwg-sctp-dtls-encaps-09 RFC8899 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8261 RFC8262 Content-ID Header Field in the Session Initiation Protocol (SIP) C. Holmberg I. Sedlacek October 2017 ASCII HTML 14 SIP

This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). This document also updates RFC 5621, which only allows a Content-ID URL to reference a body part that is part of a multipart message-body. This update enables a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields.

This document updates RFC 5368 and RFC 6442 by clarifying their usage of the SIP Content-ID header field.

 draft-ietf-sipcore-content-id-10 RFC5621 RFC5368 RFC6442 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8262 RFC8263 Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message B. Weis U. Mangla T. Karl N. Maheshwari November 2017 ASCII HTML 17 multicast security

The Group Domain of Interpretation (GDOI) includes the ability of a Group Controller/Key Server (GCKS) to provide a set of current Group Member (GM) devices with additional security associations (e.g., to rekey expiring security associations). This memo adds the ability of a GCKS to request that the GM devices return an acknowledgement of receipt of its rekey message and specifies the acknowledgement method.

 draft-weis-gdoi-rekey-ack-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8263 RFC8264 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols P. Saint-Andre M. Blanchet October 2017 ASCII HTML 43 internationalization i18n Stringprep

Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 7564.

 draft-ietf-precis-7564bis-10 RFC7564 PROPOSED STANDARD PROPOSED STANDARD IETF art precis http://www.rfc-editor.org/errata_search.php?rfc=8264 10.17487/RFC8264 RFC8265 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords P. Saint-Andre A. Melnikov October 2017 ASCII HTML 26 Username Password Unicode Internationalization i18n Authentication SASLprep

This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. This document obsoletes RFC 7613.

 draft-ietf-precis-7613bis-11 RFC7613 PROPOSED STANDARD PROPOSED STANDARD IETF art precis http://www.rfc-editor.org/errata_search.php?rfc=8265 10.17487/RFC8265 RFC8266 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames P. Saint-Andre October 2017 ASCII HTML 13 nickname SIP SIMPLE XMPP MSRP XCON chatrooms

This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities. This document obsoletes RFC 7700.

 draft-ietf-precis-7700bis-10 RFC7700 PROPOSED STANDARD PROPOSED STANDARD IETF art precis 10.17487/RFC8266 RFC8267 Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1 C. Lever October 2017 ASCII HTML 21 NFS-over-RDMA

This document specifies Upper-Layer Bindings of Network File System (NFS) protocol versions to RPC-over-RDMA version 1, thus enabling the use of Direct Data Placement. This document obsoletes RFC 5667.

 draft-ietf-nfsv4-rfc5667bis-13 RFC5667 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8267 RFC8268 More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) M. Baushke December 2017 ASCII HTML 8 Public Key Private Key group14 group15 group16 group17 groupt18 2048-bit 3072-bit 4096-bit 6144-bit 8192-bit

This document defines added Modular Exponentiation (MODP) groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253 by correcting an error regarding checking the Peer's DH Public Key.

 draft-ietf-curdle-ssh-modp-dh-sha2-09 RFC4250 RFC4253 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8268 RFC8269 The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) W. Kim J. Lee J. Park D. Kwon D. Kim October 2017 ASCII HTML 19 ARIA SRTP DTLS-SRTP MIKEY

This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR and GCM) and the SRTP key derivation functions for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and Multimedia Internet KEYing (MIKEY) parameter sets for use with ARIA.

 draft-ietf-avtcore-aria-srtp-11 INFORMATIONAL INFORMATIONAL IETF art avtcore 10.17487/RFC8269 RFC8270 Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits L. Velvindron M. Baushke December 2017 ASCII HTML 5 SSH DH

The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) transport-layer protocol specifies that servers and clients should support groups with a minimum modulus group size of 1024 bits. Recent security research has shown that the minimum value of 1024 bits is insufficient to protect against state-sponsored actors and any organization with enough computing resources. This RFC updates RFC 4419, which allowed for DH moduli less than 2048 bits; now, 2048 bits is the minimum acceptable group size.

 draft-ietf-curdle-ssh-dh-group-exchange-06 RFC4419 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8270 10.17487/RFC8270 RFC8271 Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs) M. Taillon T. Saad Editor R. Gandhi Editor Z. Ali M. Bhatia October 2017 ASCII HTML 24 Co-routed LSPs Bypass assignment coordinate Restore co-routing

This document updates the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC 4090 to support Packet Switch Capable (PSC) Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs). These updates allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these updates enable the redirection of bidirectional traffic onto bypass tunnels that ensure the co-routing of data paths in the forward and reverse directions after FRR and avoid RSVP soft-state timeout in the control plane.

 draft-ietf-teas-gmpls-lsp-fastreroute-12 RFC4090 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8271 RFC8272 TinyIPFIX for Smart Meters in Constrained Networks C. Schmitt B. Stiller B. Trammell November 2017 ASCII HTML 30 TinyIPFIX Smart Meters Constrained Networks

This document specifies the TinyIPFIX protocol that is used for transmitting smart-metering data in constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN, RFC 4944). TinyIPFIX is derived from IP Flow Information Export (RFC 7011) and adopted to the needs of constrained networks. This document specifies how the TinyIPFIX Data and Template Records are transmitted in constrained networks such as 6LoWPAN and how TinyIPFIX data can be converted into data that is not TinyIPFIX in a proxy device.

 draft-schmitt-ipfix-tiny-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8272 10.17487/RFC8272 RFC8273 Unique IPv6 Prefix per Host J. Brzozowski G. Van de Velde December 2017 ASCII HTML 10

This document outlines an approach utilizing existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of using a unique IPv6 prefix over a unique service-provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments.

 draft-ietf-v6ops-unique-ipv6-prefix-per-host-13 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC8273 RFC8274 Incident Object Description Exchange Format Usage Guidance P. Kampanakis M. Suzuki November 2017 ASCII HTML 33 IODEF best practices IODEF implementation recommendations IODEF examples IODEF practical recommendations

The Incident Object Description Exchange Format (IODEF) v2 (RFC7970) defines a data representation that provides a framework for sharing information about computer security incidents commonly exchanged by Computer Security Incident Response Teams (CSIRTs) . Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for security practitioners to develop tools that leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It addresses how common security indicators can be represented in IODEF and use-cases of how IODEF is being used. This document aims to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by CSIRTs around the world.

 draft-ietf-mile-iodef-guidance-11 INFORMATIONAL INFORMATIONAL IETF sec mile 10.17487/RFC8274 RFC8275 Allowing Inheritable NFSv4 Access Control Entries to Override the Umask J. Fields A. Gruenbacher December 2017 ASCII HTML 7 NFSv4

In many environments, inheritable NFSv4 Access Control Entries (ACEs) can be rendered ineffective by the application of the per-process file mode creation mask (umask). This can be addressed by transmitting the umask and create mode as separate pieces of data, allowing the server to make more intelligent decisions about the permissions to set on new files. This document proposes a protocol extension to accomplish that.

 draft-ietf-nfsv4-umask-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=8275 10.17487/RFC8275 RFC8276 File System Extended Attributes in NFSv4 M. Naik M. Eshel December 2017 ASCII HTML 28

This document describes an optional feature extending the NFSv4 protocol. This feature allows extended attributes (hereinafter also referred to as xattrs) to be interrogated and manipulated using NFSv4 clients. Xattrs are provided by a file system to associate opaque metadata, not interpreted by the file system, with files and directories. Such support is present in many modern local file systems. New file attributes are provided to allow clients to query the server for xattr support, with that support consisting of new operations to get and set xattrs on file system objects.

 draft-ietf-nfsv4-xattrs-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=8276 10.17487/RFC8276 RFC8277 Using BGP to Bind MPLS Labels to Address Prefixes E. Rosen October 2017 ASCII HTML 23 asynchronous transfer mode AAL syntax adaption layer

This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107.

 draft-ietf-mpls-rfc3107bis-04 RFC3107 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8277 RFC8278 Mobile Access Gateway (MAG) Multipath Options P. Seite A. Yegin S. Gundavelli January 2018 ASCII HTML 15 Proxy Mobile IPv6 (PMIPv6) multihoming Multiple WAN accesses

This specification defines extensions to the Proxy Mobile IPv6 (PMIPv6) protocol that allow a mobile access gateway (MAG) to register more than one proxy care-of address (pCoA) with the local mobility anchor (LMA) and to simultaneously establish multiple IP tunnels with the LMA. This capability allows the MAG to utilize all the available access networks to route the mobile node's IP traffic. This document defines the following two new mobility header options: the MAG Multipath Binding option and the MAG Identifier option.

 draft-ietf-dmm-mag-multihoming-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dmm 10.17487/RFC8278 RFC8279 Multicast Using Bit Index Explicit Replication (BIER) IJ. Wijnands Editor E. Rosen Editor A. Dolganow T. Przygienda S. Aldrin November 2017 ASCII HTML 43 Multicast

This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification.

 draft-ietf-bier-architecture-08 PROPOSED STANDARD EXPERIMENTAL IETF rtg bier 10.17487/RFC8279 RFC8280 Research into Human Rights Protocol Considerations N. ten Oever C. Cath October 2017 ASCII HTML 81 human rights IETF protocols guidelines considerations freedom of expression

This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations (RFC 6973). The other parts of this document explain the background of the guidelines and how they were developed.

This document is the first milestone in a longer-term research effort. It has been reviewed by the Human Rights Protocol Considerations (HRPC) Research Group and also by individuals from outside the research group.

 draft-irtf-hrpc-research-14 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8280 10.17487/RFC8280 RFC8281 Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model E. Crabbe I. Minei S. Sivabalan R. Varga December 2017 ASCII HTML 20

The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.

The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.

 draft-ietf-pce-pce-initiated-lsp-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8281 10.17487/RFC8281 RFC8282 Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering E. Oki T. Takeda A. Farrel F. Zhang December 2017 ASCII HTML 22 Multi-layer Multi-domain Inter-domain Traffic Engineering

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements.

The PCE Communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering.

 draft-ietf-pce-inter-layer-ext-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8282 RFC8283 An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control A. Farrel Editor Q. Zhao Editor Z. Li C. Zhou December 2017 ASCII HTML 25 PCE SDN

The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands.

PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP).

SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.

This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it.

This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents.

 draft-ietf-teas-pce-central-control-05 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8283 RFC8284 Lightweight Directory Access Protocol (LDAP) Schema for Supporting the Extensible Messaging and Presence Protocol (XMPP) in White Pages S. Kille November 2017 ASCII HTML 6

The Extensible Messaging and Presence Protocol (XMPP) identifies users by use of Jabber IDs (JIDs). The Lightweight Directory Access Protocol (LDAP) enables provision of a white pages service with a schema relating to users and support for Internet protocols. This specification defines a schema to enable XMPP JIDs to be associated with objects in an LDAP directory so that this information can be used with white pages applications.

 draft-kille-ldap-xmpp-schema-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8284 RFC8285 A General Mechanism for RTP Header Extensions D. Singer H. Desineni R. Even Editor October 2017 ASCII HTML 25

This document provides a general mechanism to use the header extension feature of RTP (the Real-time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is decentralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC 5285.

 draft-ietf-avtcore-rfc5285-bis-14 RFC5285 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8285 RFC8286 RTP/RTCP Extension for RTP Splicing Notification J. Xia R. Even R. Huang L. Deng October 2017 ASCII HTML 22

Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and that delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing.

This memo defines two RTP/RTCP extensions to indicate the splicing-related information to the splicer: an RTP header extension that conveys the information "in band" and an RTP Control Protocol (RTCP) packet that conveys the information out of band.

 draft-ietf-avtext-splicing-notification-09 PROPOSED STANDARD PROPOSED STANDARD IETF art avtext 10.17487/RFC8286 RFC8287 Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes N. Kumar Editor C. Pignataro Editor G. Swallow N. Akiya S. Kini M. Chen December 2017 ASCII HTML 25 MPLS LSP Ping SPRING Segment Routing SR

A Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header.

The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture. This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane.

 draft-ietf-mpls-spring-lsp-ping-13 RFC8690 RFC9214 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=8287 10.17487/RFC8287 RFC8288 Web Linking M. Nottingham October 2017 ASCII HTML 24 link relation

This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types").

It also defines the serialisation of such links in HTTP headers with the Link header field.

 draft-nottingham-rfc5988bis-08 RFC5988 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8288 10.17487/RFC8288 RFC8289 Controlled Delay Active Queue Management K. Nichols V. Jacobson A. McGregor Editor J. Iyengar Editor January 2018 ASCII HTML 25 CoDel AQM Active Queue Management

This document describes CoDel (Controlled Delay) -- a general framework that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments.

 draft-ietf-aqm-codel-10 EXPERIMENTAL EXPERIMENTAL IETF tsv aqm 10.17487/RFC8289 RFC8290 The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm T. Hoeiland-Joergensen P. McKenney D. Taht J. Gettys E. Dumazet January 2018 ASCII HTML 25 bufferbloat aqm fq_codel fq-codel

This memo presents the FQ-CoDel hybrid packet scheduler and Active Queue Management (AQM) algorithm, a powerful tool for fighting bufferbloat and reducing latency.

FQ-CoDel mixes packets from multiple flows and reduces the impact of head-of-line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short, and it can be implemented in a memory- and CPU-efficient fashion across a wide range of hardware.

 draft-ietf-aqm-fq-codel-06 EXPERIMENTAL EXPERIMENTAL IETF tsv aqm 10.17487/RFC8290 RFC8291 Message Encryption for Web Push M. Thomson November 2017 ASCII HTML 13 web push notification http encryption

This document describes a message encryption scheme for the Web Push protocol. This scheme provides confidentiality and integrity for messages sent from an application server to a user agent.

 draft-ietf-webpush-encryption-09 PROPOSED STANDARD PROPOSED STANDARD IETF art webpush http://www.rfc-editor.org/errata_search.php?rfc=8291 10.17487/RFC8291 RFC8292 Voluntary Application Server Identification (VAPID) for Web Push M. Thomson P. Beverloo November 2017 ASCII HTML 14 authentication restricted restriction signature

An application server can use the Voluntary Application Server Identification (VAPID) method described in this document to voluntarily identify itself to a push service. The "vapid" authentication scheme allows a client to include its identity in a signed token with requests that it makes. The signature can be used by the push service to attribute requests that are made by the same application server to a single entity. The identification information can allow the operator of a push service to contact the operator of the application server. The signature can be used to restrict the use of a push message subscription to a single application server.

 draft-ietf-webpush-vapid-04 PROPOSED STANDARD PROPOSED STANDARD IETF art webpush 10.17487/RFC8292 RFC8293 A Framework for Multicast in Network Virtualization over Layer 3 A. Ghanwani L. Dunbar M. McBride V. Bannai R. Krishnan January 2018 ASCII HTML 17 NVO3 VXLAN Geneve NVGRE

This document provides a framework for supporting multicast traffic in a network that uses Network Virtualization over Layer 3 (NVO3). Both infrastructure multicast and application-specific multicast are discussed. It describes the various mechanisms that can be used for delivering such traffic as well as the data plane and control plane considerations for each of the mechanisms.

 draft-ietf-nvo3-mcast-framework-11 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC8293 RFC8294 Common YANG Data Types for the Routing Area X. Liu Y. Qu A. Lindem C. Hopps L. Berger December 2017 ASCII HTML 43 Network Management Routing YANG

This document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area.

 draft-ietf-rtgwg-routing-types-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg http://www.rfc-editor.org/errata_search.php?rfc=8294 10.17487/RFC8294 RFC8295 EST (Enrollment over Secure Transport) Extensions S. Turner January 2018 ASCII HTML 54 Firmware TAMP Asymmetric Keys Symmetric Keys Product Availability List

The EST (Enrollment over Secure Transport) protocol defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI (Public Key Infrastructure) services, namely certificate enrollment (e.g., /simpleenroll). This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys. This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScript Object Notation) object that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services.

 draft-turner-est-extensions-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8295 RFC8296 Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks IJ. Wijnands Editor E. Rosen Editor A. Dolganow J. Tantsura S. Aldrin I. Meilik January 2018 ASCII HTML 24 Multicast

Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network.

 draft-ietf-bier-mpls-encapsulation-12 PROPOSED STANDARD EXPERIMENTAL IETF rtg bier http://www.rfc-editor.org/errata_search.php?rfc=8296 10.17487/RFC8296 RFC8297 An HTTP Status Code for Indicating Hints K. Oku December 2017 ASCII HTML 7 push preload

This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response.

 draft-ietf-httpbis-early-hints-05 EXPERIMENTAL EXPERIMENTAL IETF art httpbis 10.17487/RFC8297 RFC8298 Self-Clocked Rate Adaptation for Multimedia I. Johansson Z. Sarker December 2017 ASCII HTML 36 Cellular Network Congestion Control RTP

This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a Long Term Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios.

 draft-ietf-rmcat-scream-cc-13 EXPERIMENTAL EXPERIMENTAL IETF tsv rmcat 10.17487/RFC8298 RFC8299 YANG Data Model for L3VPN Service Delivery Q. Wu Editor S. Litkowski L. Tomotaki K. Ogaki January 2018 ASCII HTML 188

This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.

This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text.

 draft-wu-l3sm-rfc8049bis-11 RFC8049 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8299 10.17487/RFC8299 RFC8300 Network Service Header (NSH) P. Quinn Editor U. Elzur Editor C. Pignataro Editor January 2018 ASCII HTML 40 Service Function Chaining Network Service Header SFC NSH Network Service Function

This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs). The NSH also provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining (SFC) encapsulation required to support the SFC architecture (defined in RFC 7665).

 draft-ietf-sfc-nsh-28 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sfc http://www.rfc-editor.org/errata_search.php?rfc=8300 10.17487/RFC8300 RFC8301 Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) S. Kitterman January 2018 ASCII HTML 5 email authentication

The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms.

 draft-ietf-dcrup-dkim-usage-06 RFC6376 PROPOSED STANDARD PROPOSED STANDARD IETF art dcrup 10.17487/RFC8301 RFC8302 Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization Y. Li D. Eastlake 3rd L. Dunbar R. Perlman M. Umair January 2018 ASCII HTML 18 proxy RARP duplicate address DAD DHCP flooding

This document describes mechanisms to optimize the Address Resolution Protocol (ARP) and Neighbor Discovery (ND) traffic in a Transparent Interconnection of Lots of Links (TRILL) campus. TRILL switches maintain a cache of IP / Media Access Control (MAC) address / Data Label bindings that are learned from ARP/ND requests and responses that pass through them. In many cases, this cache allows an edge Routing Bridge (RBridge) to avoid flooding an ARP/ND request by either responding to it directly or encapsulating it and unicasting it. Such optimization reduces packet flooding over a TRILL campus.

 draft-ietf-trill-arp-optimization-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8302 RFC8303 On the Usage of Transport Features Provided by IETF Transport Protocols M. Welzl M. Tuexen N. Khademi February 2018 ASCII HTML 56

This document describes how the transport protocols Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a transport services (TAPS) API.

 draft-ietf-taps-transports-usage-09 INFORMATIONAL INFORMATIONAL IETF tsv taps http://www.rfc-editor.org/errata_search.php?rfc=8303 10.17487/RFC8303 RFC8304 Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite) G. Fairhurst T. Jones February 2018 ASCII HTML 20 UDP Transport

This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. RFC 8303 documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite, and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services. This document provides input to and context for that document, as well as offers a road map to documentation that may help users of the UDP and UDP-Lite protocols.

 draft-ietf-taps-transports-usage-udp-07 INFORMATIONAL INFORMATIONAL IETF tsv taps http://www.rfc-editor.org/errata_search.php?rfc=8304 10.17487/RFC8304 RFC8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency D. Schinazi T. Pauly December 2017 ASCII HTML 15 IPv6 IPv4 TCP DNS NAT64

Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555.

 draft-ietf-v6ops-rfc6555bis-07 RFC6555 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC8305 RFC8306 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Q. Zhao D. Dhody Editor R. Palleti D. King November 2017 ASCII HTML 43

Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.

This document describes extensions to the PCE Communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs.

This document obsoletes RFC 6006.

 draft-ietf-pce-rfc6006bis-04 RFC6006 RFC9353 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8306 10.17487/RFC8306 RFC8307 Well-Known URIs for the WebSocket Protocol C. Bormann January 2018 ASCII HTML 3 URI Web metadata well-known WebSocket ws wss

RFC 5785 defines a path prefix, "/.well-known/", that can be used by well-known URIs. It was specifically defined for the "http" and "https" URI schemes. The present memo formally updates RFC 6455, which defines the URI schemes defined for the WebSocket Protocol, to extend the use of these well-known URIs to those URI schemes.

 draft-bormann-hybi-ws-wk-00 RFC6455 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8307 RFC8308 Extension Negotiation in the Secure Shell (SSH) Protocol D. Bider March 2018 ASCII HTML 14 ext-info ext-info-s ext-info-c SSH_MSG_EXT_INFO SSH_MSG_NEWCOMPRESS server-sig-algs delay-compression no-flow-control elevation delay compression delayed compression flow control elevated

This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange.

 draft-ietf-curdle-ssh-ext-info-15 RFC4251 RFC4252 RFC4253 RFC4254 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8308 RFC8309 Service Models Explained Q. Wu W. Liu A. Farrel January 2018 ASCII HTML 23 YANG NETCONF RESTCONF Data Model SDN Software Defined Network Service Orchestrator

The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions.

A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049).

This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider.

 draft-ietf-opsawg-service-model-explained-05 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC8309 RFC8310 Usage Profiles for DNS over TLS and DNS over DTLS S. Dickinson D. Gillmor T. Reddy March 2018 ASCII HTML 27 DNS transport

This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858.

 draft-ietf-dprive-dtls-and-tls-profiles-11 RFC7858 PROPOSED STANDARD PROPOSED STANDARD IETF int dprive 10.17487/RFC8310 RFC8311 Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation D. Black January 2018 ASCII HTML 20 ECN

This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint.

 draft-ietf-tsvwg-ecn-experimentation-08 RFC3168 RFC4341 RFC4342 RFC5622 RFC6679 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=8311 10.17487/RFC8311 RFC8312 CUBIC for Fast Long-Distance Networks I. Rhee L. Xu S. Ha A. Zimmermann L. Eggert R. Scheffenegger February 2018 ASCII HTML 18

CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long-distance networks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years. This document provides a specification of CUBIC to enable third-party implementations and to solicit community feedback through experimentation on the performance of CUBIC.

 draft-ietf-tcpm-cubic-07 INFORMATIONAL INFORMATIONAL IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=8312 10.17487/RFC8312 RFC8313 Use of Multicast across Inter-domain Peering Points P. Tarapore Editor R. Sayko G. Shepherd T. Eckert Editor R. Krishnan January 2018 ASCII HTML 44 multicast security multicast troubleshooting multicast routing multicast tunneling PIM PIM-SSM SSM Source Specific Multicast AMT GRE Automatic Multicast Tunneling BGP MBGP M-BGP MP-BGP exchange exchange point NNI content distribution video streaming anycast

This document examines the use of Source-Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objectives are to (1) describe the setup process for multicast-based delivery across administrative domains for these scenarios and (2) document supporting functionality to enable this process.

 draft-ietf-mboned-interdomain-peering-bcp-14 BCP0213 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC8313 RFC8314 Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access K. Moore C. Newman January 2018 ASCII HTML 26 POP IMAP SMTP MSP mail submission STARTTLS DANE TLSA

This specification outlines current recommendations for the use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server. This document updates RFCs 1939, 2595, 3501, 5068, 6186, and 6409.

 draft-ietf-uta-email-deep-12 RFC1939 RFC2595 RFC3501 RFC5068 RFC6186 RFC6409 RFC8997 PROPOSED STANDARD PROPOSED STANDARD IETF art uta http://www.rfc-editor.org/errata_search.php?rfc=8314 10.17487/RFC8314 RFC8315 Cancel-Locks in Netnews Articles M. Baeuerle February 2018 ASCII HTML 20 Usenet Netnews Cancel-Lock

This document defines an extension to the Netnews Article Format that may be used to authenticate the withdrawal of existing articles. This document updates RFC 5537.

 draft-baeuerle-netnews-cancel-lock-09 RFC5537 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8315 RFC8316 Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations J. Nobre L. Granville A. Clemm A. Gonzalez Prieto February 2018 ASCII HTML 16 Autonomic Networking SLA P2P

This document describes an experimental use case that employs autonomic networking for the monitoring of Service Level Agreements (SLAs). The use case is for detecting violations of SLAs in a distributed fashion. It strives to optimize and dynamically adapt the autonomic deployment of active measurement probes in a way that maximizes the likelihood of detecting service-level violations with a given resource budget to perform active measurements. This optimization and adaptation should be done without any outside guidance or intervention.

This document is a product of the IRTF Network Management Research Group (NMRG). It is published for informational purposes.

 draft-irtf-nmrg-autonomic-sla-violation-detection-13 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8316 RFC8317 Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) A. Sajassi Editor S. Salam J. Drake J. Uttaro S. Boutros J. Rabadan January 2018 ASCII HTML 23

The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC 7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC 7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC 7796, "Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC 7385; hence, it updates RFC 7385 accordingly.

 draft-ietf-bess-evpn-etree-14 RFC7385 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8317 RFC8318 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee S. Dawkins January 2018 ASCII HTML 9 nomcom IAOC

This specification formalizes an ad hoc practice used to provide advice to the IETF Nominating Committee (NomCom) about the operations of the IETF Administrative Oversight Committee (IAOC).

This document updates RFC 7437.

 draft-dawkins-iesg-nomcom-advisor-iaoc-03 RFC8713 RFC7437 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8318 RFC8319 Support for Adjustable Maximum Router Lifetimes per Link S. Krishnan J. Korhonen S. Chakrabarti E. Nordmark A. Yourtchenko February 2018 ASCII HTML 7

The IPv6 Neighbor Discovery protocol specifies the maximum time allowed between sending unsolicited multicast Router Advertisements (RAs) from a router interface as well as the maximum router lifetime. It also allows the limits to be overridden by documents that are specific to the link layer. This document allows for overriding these values on a per-link basis.

This document specifies updates to the IPv6 Neighbor Discovery Protocol (RFC 4861) to increase the maximum time allowed between sending unsolicited multicast RAs from a router interface as well as to increase the maximum router lifetime.

 draft-ietf-6man-maxra-04 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8319 RFC8320 LDP Extensions to Support Maximally Redundant Trees A. Atlas K. Tiruveedhula C. Bowers J. Tantsura IJ. Wijnands February 2018 ASCII HTML 21 fast-reroute MRT MRT-FRR

This document specifies extensions to the Label Distribution Protocol (LDP) to support the creation of Label Switched Paths (LSPs) for Maximally Redundant Trees (MRTs). A prime use of MRTs is for unicast and multicast IP/LDP Fast Reroute, which we will refer to as "MRT-FRR".

The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for Label Switching Routers (LSRs) and Label Edge Routers (LERs) advertising the MRT Capability.

MRT-FRR uses LDP multi-topology extensions, so three multi-topology IDs have been allocated from the MPLS MT-ID space.

 draft-ietf-mpls-ldp-mrt-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8320 RFC8321 Alternate-Marking Method for Passive and Hybrid Performance Monitoring G. Fioccola Editor A. Capello M. Cociglio L. Castaldelli M. Chen L. Zheng G. Mirsky T. Mizrahi January 2018 ASCII HTML 33 Alternate Marking Marking Method Coloring Technique

This document describes a method to perform packet loss, delay, and jitter measurements on live traffic. This method is based on an Alternate-Marking (coloring) technique. A report is provided in order to explain an example and show the method applicability. This technology can be applied in various situations, as detailed in this document, and could be considered Passive or Hybrid depending on the application.

 draft-ietf-ippm-alt-mark-14 RFC9341 EXPERIMENTAL EXPERIMENTAL IETF tsv ippm 10.17487/RFC8321 RFC8322 Resource-Oriented Lightweight Information Exchange (ROLIE) J. Field S. Banghart D. Waltermire February 2018 ASCII HTML 43 syndication atom atom publishing protocol atom syndication format rest information sharing security automation

This document defines a resource-oriented approach for security automation information publication, discovery, and sharing. Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources. Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on-demand information exchange network for restricted internal use or public access repositories. This specification extends the Atom Publishing Protocol and Atom Syndication Format to transport and share security automation resource representations.

 draft-ietf-mile-rolie-16 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC8322 RFC8323 CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets C. Bormann S. Lemay H. Tschofenig K. Hartke B. Silverajan B. Raymor Editor February 2018 ASCII HTML 54 CoAP Constrained Application Protocol REST IoT Internet of Things NAT Traversal CoAP in Browsers

The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.

Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.

 draft-ietf-core-coap-tcp-tls-11 RFC7641 RFC7959 RFC8974 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8323 RFC8324 DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look? J. Klensin February 2018 ASCII HTML 29 domain name DNS functions DNS extensions

The basic design of the Domain Name System was completed almost 30 years ago. The last half of that period has been characterized by significant changes in requirements and expectations, some of which either require changes to how the DNS is used or can be accommodated only poorly or not at all. This document asks the question of whether it is time to either redesign and replace the DNS to match contemporary requirements and expectations (rather than continuing to try to design and implement incremental patches that are not fully satisfactory) or draw some clear lines about functionality that is not really needed or that should be performed in some other way.

 draft-klensin-dns-function-considerations-05 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8324 10.17487/RFC8324 RFC8325 Mapping Diffserv to IEEE 802.11 T. Szigeti J. Henry F. Baker February 2018 ASCII HTML 37 quality of service QoS QoS classes mapping DSCP Diffserv Access Category AC User Priority UP 802.11 Wi-Fi

As Internet traffic is increasingly sourced from and destined to wireless endpoints, it is crucial that Quality of Service (QoS) be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set of mappings from Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks.

 draft-ietf-tsvwg-ieee-802-11-11 RFC8622 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8325 RFC8326 Graceful BGP Session Shutdown P. Francois Editor B. Decraene Editor C. Pelsser K. Patel C. Filsfils March 2018 ASCII HTML 12

This document standardizes a new well-known BGP community, GRACEFUL_SHUTDOWN, to signal the graceful shutdown of paths. This document also describes operational procedures that use this well-known community to reduce the amount of traffic lost when BGP peering sessions are about to be shut down deliberately, e.g., for planned maintenance.

 draft-ietf-grow-bgp-gshut-13 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=8326 10.17487/RFC8326 RFC8327 Mitigating the Negative Impact of Maintenance through BGP Session Culling W. Hargrave M. Griswold J. Snijders N. Hilliard March 2018 ASCII HTML 10 BGP culling EBGP sessions

This document outlines an approach to mitigate the negative impact on networks resulting from maintenance activities. It includes guidance for both IP networks and Internet Exchange Points (IXPs). The approach is to ensure BGP-4 sessions that will be affected by maintenance are forcefully torn down before the actual maintenance activities commence.

 draft-ietf-grow-bgp-session-culling-05 BCP0214 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=8327 10.17487/RFC8327 RFC8328 Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA) W. Liu C. Xie J. Strassner G. Karagiannis M. Klyus J. Bi Y. Cheng D. Zhang March 2018 ASCII HTML 15 Information models YANG data models Event Condition Action policy rules GPIM EPRIM declarative policy intent-based policy

The Simplified Use of Policy Abstractions (SUPA) policy-based management framework defines base YANG data models to encode policy. These models point to device-, technology-, and service-specific YANG data models developed elsewhere. Policy rules within an operator's environment can be used to express high-level, possibly network-wide, policies to a network management function (within a controller, an orchestrator, or a network element). The network management function can then control the configuration and/or monitoring of network elements and services. This document describes the SUPA basic framework, its elements, and interfaces.

 draft-liu-policy-based-management-framework-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8328 RFC8329 Framework for Interface to Network Security Functions D. Lopez E. Lopez L. Dunbar J. Strassner R. Kumar February 2018 ASCII HTML 25 security policy security capability

This document describes the framework for Interface to Network Security Functions (I2NSF) and defines a reference model (including major functional components) for I2NSF. Network Security Functions (NSFs) are packet-processing engines that inspect and optionally modify packets traversing networks, either directly or in the context of sessions to which the packet is associated.

 draft-ietf-i2nsf-framework-10 INFORMATIONAL INFORMATIONAL IETF sec i2nsf 10.17487/RFC8329 RFC8330 OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth H. Long M. Ye G. Mirsky A. D'Alessandro H. Shah February 2018 ASCII HTML 10 microwave copper Generalized SCSI-TLV

A network may contain links with variable discrete bandwidth, e.g., microwave and copper. The bandwidth of such links may change discretely in response to a changing external environment. The word "availability" is typically used to describe such links during network planning. This document defines a new type of Generalized Switching Capability-Specific Information (SCSI) TLV to extend the Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing protocol. The extension can be used for route computation in a network that contains links with variable discrete bandwidth. Note that this document only covers the mechanisms by which the availability information is distributed. The mechanisms by which availability information of a link is determined and the use of the distributed information for route computation are outside the scope of this document. It is intended that technology-specific documents will reference this document to describe specific uses.

 draft-ietf-ccamp-ospf-availability-extension-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC8330 RFC8331 RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data T. Edwards February 2018 ASCII HTML 20 SDI video captions timecode ANC

This memo describes a Real-time Transport Protocol (RTP) payload format for the Society of Motion Picture and Television Engineers (SMPTE) ancillary space (ANC) data, as defined by SMPTE ST 291-1. SMPTE ANC data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD).

 draft-ietf-payload-rtp-ancillary-14 PROPOSED STANDARD PROPOSED STANDARD IETF art payload http://www.rfc-editor.org/errata_search.php?rfc=8331 10.17487/RFC8331 RFC8332 Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol D. Bider March 2018 ASCII HTML 9 rsa-sha2-256 rsa-sha2-512 ssh-rsa publickey server-sig-algs signature authentication

This memo updates RFCs 4252 and 4253 to define new public key algorithms for use of RSA keys with SHA-256 and SHA-512 for server and client authentication in SSH connections.

 draft-ietf-curdle-rsa-sha2-12 RFC4252 RFC4253 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8332 RFC8333 Micro-loop Prevention by Introducing a Local Convergence Delay S. Litkowski B. Decraene C. Filsfils P. Francois March 2018 ASCII HTML 26

This document describes a mechanism for link-state routing protocols that prevents local transient forwarding loops in case of link failure. This mechanism proposes a two-step convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network-wide convergence.

Because this mechanism delays the IGP convergence, it may only be used for planned maintenance or when Fast Reroute (FRR) protects the traffic during the time between the link failure and the IGP convergence.

The mechanism is limited to the link-down event in order to keep the mechanism simple.

Simulations using real network topologies have been performed and show that local loops are a significant portion (>50%) of the total forwarding loops.

 draft-ietf-rtgwg-uloop-delay-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8333 RFC8334 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) J. Gould W. Tan G. Brown March 2018 ASCII HTML 58 EPP Sunrise Landrush Trademark Clearinghouse Trademark Claims domain name registry launch phase

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry.

 draft-ietf-regext-launchphase-07 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8334 RFC8335 PROBE: A Utility for Probing Interfaces R. Bonica R. Thomas J. Linkova C. Lenart M. Boucadair February 2018 ASCII HTML 19 Ping ICMP

This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884.

 draft-ietf-intarea-probe-10 RFC4884 PROPOSED STANDARD PROPOSED STANDARD IETF int intarea 10.17487/RFC8335 RFC8336 The ORIGIN HTTP/2 Frame M. Nottingham E. Nygren March 2018 ASCII HTML 11 connection coalescing HTTP

This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection.

 draft-ietf-httpbis-origin-frame-06 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8336 10.17487/RFC8336 RFC8337 Model-Based Metrics for Bulk Transport Capacity M. Mathis A. Morton March 2018 ASCII HTML 55 performance bulk capacity BTC diagnostic statistics

This document introduces a new class of Model-Based Metrics designed to assess if a complete Internet path can be expected to meet a predefined Target Transport Performance by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests can be robustly applied to critical infrastructure, such as network interconnections or even individual devices, to accurately detect if any part of the infrastructure will prevent paths traversing it from meeting the Target Transport Performance.

Model-Based Metrics rely on mathematical models to specify a Targeted IP Diagnostic Suite, a set of IP diagnostic tests designed to assess whether common transport protocols can be expected to meet a predetermined Target Transport Performance over an Internet path.

For Bulk Transport Capacity, the IP diagnostics are built using test streams and statistical criteria for evaluating the packet transfer that mimic TCP over the complete path. The temporal structure of the test stream (e.g., bursts) mimics TCP or other transport protocols carrying bulk data over a long path. However, they are constructed to be independent of the details of the subpath under test, end systems, or applications. Likewise, the success criteria evaluates the packet transfer statistics of the subpath against criteria determined by protocol performance models applied to the Target Transport Performance of the complete path. The success criteria also does not depend on the details of the subpath, end systems, or applications.

 draft-ietf-ippm-model-based-metrics-13 EXPERIMENTAL EXPERIMENTAL IETF tsv ippm 10.17487/RFC8337 RFC8338 Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP S. Boutros Editor S. Sivabalan Editor March 2018 ASCII HTML 20

This document specifies a mechanism to signal Point-to-Multipoint (P2MP) Pseudowire (PW) trees using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP or MPLS-enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. This document updates RFC 7385 by reassigning the reserved value 0xFF to be the wildcard transport tunnel type.

 draft-ietf-pals-p2mp-pw-04 RFC7385 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8338 RFC8339 Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms P. Jain Editor S. Boutros S. Aldrin March 2018 ASCII HTML 10

Label Switched Path (LSP) Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes a mechanism to verify connectivity of Point-to-Multipoint (P2MP) Pseudowires (PWs) using LSP Ping.

 draft-ietf-pals-p2mp-pw-lsp-ping-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8339 RFC8340 YANG Tree Diagrams M. Bjorklund L. Berger Editor March 2018 ASCII HTML 13

This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.

 draft-ietf-netmod-yang-tree-diagrams-06 RFC8791 BCP0215 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops netmod 10.17487/RFC8340 RFC8341 Network Configuration Access Control Model A. Bierman M. Bjorklund March 2018 ASCII HTML 58 NETCONF RESTCONF YANG XML

The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.

This document obsoletes RFC 6536.

 draft-ietf-netconf-rfc6536bis-09 RFC6536 STD0091 INTERNET STANDARD INTERNET STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=8341 10.17487/RFC8341 RFC8342 Network Management Datastore Architecture (NMDA) M. Bjorklund J. Schoenwaelder P. Shafer K. Watsen R. Wilton March 2018 ASCII HTML 44 YANG NETCONF RESTCONF Network Management

Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.

 draft-ietf-netmod-revised-datastores-10 RFC7950 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8342 10.17487/RFC8342 RFC8343 A YANG Data Model for Interface Management M. Bjorklund March 2018 ASCII HTML 49

This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).

The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

This document obsoletes RFC 7223.

 draft-ietf-netmod-rfc7223bis-03 RFC7223 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8343 RFC8344 A YANG Data Model for IP Management M. Bjorklund March 2018 ASCII HTML 34

This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state.

The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.

This document obsoletes RFC 7277.

 draft-ietf-netmod-rfc7277bis-03 RFC7277 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8344 RFC8345 A YANG Data Model for Network Topologies A. Clemm J. Medved R. Varga N. Bahadur H. Ananthakrishnan X. Liu March 2018 ASCII HTML 57 topology

This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.

 draft-ietf-i2rs-yang-network-topo-20 PROPOSED STANDARD PROPOSED STANDARD IETF rtg i2rs http://www.rfc-editor.org/errata_search.php?rfc=8345 10.17487/RFC8345 RFC8346 A YANG Data Model for Layer 3 Topologies A. Clemm J. Medved R. Varga X. Liu H. Ananthakrishnan N. Bahadur March 2018 ASCII HTML 35 topology

This document defines a YANG data model for Layer 3 network topologies.

 draft-ietf-i2rs-yang-l3-topology-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg i2rs 10.17487/RFC8346 RFC8347 A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) X. Liu Editor A. Kyparlis R. Parikh A. Lindem M. Zhang March 2018 ASCII HTML 45 Network Management Routing YANG

This document describes a data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered.

 draft-ietf-rtgwg-yang-vrrp-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8347 RFC8348 A YANG Data Model for Hardware Management A. Bierman M. Bjorklund J. Dong D. Romascanu March 2018 ASCII HTML 60 ENTITY-MIB

This document defines a YANG data model for the management of hardware on a single server.

 draft-ietf-netmod-entity-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8348 RFC8349 A YANG Data Model for Routing Management (NMDA Version) L. Lhotka A. Lindem Y. Qu March 2018 ASCII HTML 80 configuration IPv6 Router Advertisements NETCONF RESTCONF

This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.

The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022.

 draft-ietf-netmod-rfc8022bis-11 RFC8022 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8349 10.17487/RFC8349 RFC8350 Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP) R. Zhang R. Pazhyannur S. Gundavelli Z. Cao H. Deng Z. Du April 2018 ASCII HTML 29 Wi-Fi WLAN PMIP GRE

Control and Provisioning of Wireless Access Points (CAPWAP) is a protocol for encapsulating a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP Data Channel is used for tunneling. In many deployments, encapsulating data frames to an entity other than the AC (for example, to an Access Router (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and the Access Router. This document defines an extension to the CAPWAP protocol that supports this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types, such as IP-IP, IP-GRE, or CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery and join process, and the AC may select one of the supported alternate tunnel encapsulation types while configuring the WTP.

 draft-ietf-opsawg-capwap-alt-tunnel-12 EXPERIMENTAL EXPERIMENTAL IETF ops opsawg 10.17487/RFC8350 RFC8351 The PKCS #8 EncryptedPrivateKeyInfo Media Type S. Leonard June 2018 ASCII HTML 7

This document registers the application/pkcs8-encrypted media type for the EncryptedPrivateKeyInfo type of PKCS #8. An instance of this media type carries a single encrypted private key, BER-encoded as a single EncryptedPrivateKeyInfo value.

 draft-seantek-pkcs8-encrypted-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8351 RFC8352 Energy-Efficient Features of Internet of Things Protocols C. Gomez M. Kovatsch H. Tian Z. Cao Editor April 2018 ASCII HTML 24 IoT Radio Duty Cycling 6LoWPAN 6Lo CoAP RPL

This document describes the challenges for energy-efficient protocol operation on constrained devices and the current practices used to overcome those challenges. It summarizes the main link-layer techniques used for energy-efficient networking, and it highlights the impact of such techniques on the upper-layer protocols so that they can together achieve an energy-efficient behavior. The document also provides an overview of energy-efficient mechanisms available at each layer of the IETF protocol suite specified for constrained-node networks.

 draft-ietf-lwig-energy-efficient-08 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC8352 RFC8353 Generic Security Service API Version 2: Java Bindings Update M. Upadhyay S. Malkani W. Wang May 2018 ASCII HTML 96 JGSS GSS-API

The Generic Security Services Application Programming Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2: Java Bindings Update" (RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fail, it has a chance to emit an error token that can be sent to the peer for debugging or informational purpose. The stream-based GSSContext methods are also removed in this version.

The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are "The Simple Public-Key GSS-API Mechanism (SPKM)" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121).

 draft-ietf-kitten-rfc5653bis-07 RFC5653 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8353 RFC8354 Use Cases for IPv6 Source Packet Routing in Networking (SPRING) J. Brzozowski J. Leddy C. Filsfils R. Maglione Editor M. Townsley March 2018 ASCII HTML 9

The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. This document illustrates some use cases for Segment Routing in an IPv6-only environment.

 draft-ietf-spring-ipv6-use-cases-12 INFORMATIONAL INFORMATIONAL IETF rtg spring 10.17487/RFC8354 RFC8355 Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks C. Filsfils Editor S. Previdi Editor B. Decraene R. Shakir March 2018 ASCII HTML 13 SEGMENT ROUTING RESILIENCY PROTECTION CONVERGENCE

This document identifies and describes the requirements for a set of use cases related to Segment Routing network resiliency on Source Packet Routing in Networking (SPRING) networks.

 draft-ietf-spring-resiliency-use-cases-12 INFORMATIONAL INFORMATIONAL IETF rtg spring http://www.rfc-editor.org/errata_search.php?rfc=8355 10.17487/RFC8355 RFC8356 Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP) D. Dhody D. King A. Farrel March 2018 ASCII HTML 7 PCE PCEP IANA Experimental

IANA assigns values to the Path Computation Element Communication Protocol (PCEP) parameters (messages, objects, TLVs). IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object, and TLV types. The allocation policy for each of these sub-registries is IETF Review.

This document updates RFC 5440 by changing the allocation policies for these three registries to mark some of the codepoints as assigned for Experimental Use.

 draft-ietf-pce-pcep-exp-codepoints-05 RFC5440 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8356 RFC8357 Generalized UDP Source Port for DHCP Relay N. Shen E. Chen March 2018 ASCII HTML 10

This document defines an extension to the DHCP protocols that allows a relay agent to use any available source port for upstream communications. The extension also allows inclusion of a DHCP option that can be used to statelessly route responses back to the appropriate source port on downstream communications.

 draft-ietf-dhc-relay-port-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=8357 10.17487/RFC8357 RFC8358 Update to Digital Signatures on Internet-Draft Documents R. Housley March 2018 ASCII HTML 9 cms cryptographic message syntax detached signature

RFC 5485 specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.

The RFC Editor recently published the first RFC that includes non- ASCII characters in a text file. The conventions specified in RFC 7997 were followed. We assume that non-ASCII characters will soon start appearing in Internet-Drafts as well. This document updates the handling of digital signatures on Internet-Drafts that contain non-ASCII characters in a text file.

This document updates RFC 5485.

 draft-housley-id-sig-update-03 RFC5485 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8358 10.17487/RFC8358 RFC8359 Network-Assigned Upstream Label X. Zhang Editor V. Beeram Editor I. Bryskin D. Ceccarelli O. Gonzalez de Dios March 2018 ASCII HTML 10

This document discusses a Generalized Multi-Protocol Label Switching (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP-TE) mechanism that enables the network to assign an upstream label for a bidirectional Label Switched Path (LSP). This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream label on its own and needs to rely on the downstream node to pick an appropriate label. This document updates RFCs 3471, 3473, and 6205 as it defines processing for a special label value in the UPSTREAM_LABEL object.

 draft-ietf-teas-network-assigned-upstream-label-12 RFC3471 RFC3473 RFC6205 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8359 RFC8360 Resource Public Key Infrastructure (RPKI) Validation Reconsidered G. Huston G. Michaelson C. Martinez T. Bruijnzeels A. Newton D. Shaw April 2018 ASCII HTML 29

This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource Public Key Infrastructure (RPKI), while retaining essential security features.

The procedure specified in RFC 6487 requires that Resource Certificates are rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, whereas the validation process defined here allows an issuing Certification Authority (CA) to chose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate.

It should be noted that the validation process defined here considers validation under a single trust anchor (TA) only. In particular, concerns regarding overclaims where multiple configured TAs claim overlapping resources are considered out of scope for this document.

This choice is signaled by a set of alternative Object Identifiers (OIDs) per "X.509 Extensions for IP Addresses and AS Identifiers" (RFC 3779) and "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)" (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a trust anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487.

Furthermore, this document provides an alternative to Route Origin Authorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsec PKI Profiles -- publication requested) validation.

 draft-ietf-sidr-rpki-validation-reconsidered-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=8360 10.17487/RFC8360 RFC8361 Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic W. Hao Y. Li M. Durrani S. Gupta A. Qu April 2018 ASCII HTML 17 TRILL RBridge CMT LAALP

In Transparent Interconnection of Lots of Links (TRILL) active-active access, a Reverse Path Forwarding (RPF) check failure issue may occur when using the pseudo-nickname mechanism specified in RFC 7781. This document describes a solution to resolve this RPF check failure issue through centralized replication. All ingress Routing Bridges (RBridges) send Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a centralized node with unicast TRILL encapsulation. When the centralized node receives the BUM traffic, it decapsulates the packets and forwards them to their destination RBridges using a distribution tree established per the TRILL base protocol (RFC 6325). To avoid RPF check failure on an RBridge sitting between the ingress RBridge and the centralized replication node, some change in the RPF calculation algorithm is required. RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge, instead of being calculated using the actual ingress RBridge. This document updates RFC 6325.

 draft-ietf-trill-centralized-replication-13 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8361 RFC8362 OSPFv3 Link State Advertisement (LSA) Extensibility A. Lindem A. Roy D. Goethals V. Reddy Vallem F. Baker April 2018 ASCII HTML 33

OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described.

This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support.

 draft-ietf-ospf-ospfv3-lsa-extend-23 RFC5340 RFC5838 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC8362 RFC8363 GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks X. Zhang H. Zheng R. Casellas O. Gonzalez de Dios D. Ceccarelli May 2018 ASCII HTML 17 flexi-grid OSPF-TE central frequency frequency slot channel spacing

The International Telecommunication Union Telecommunication standardization sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining channel spacings, a set of nominal central frequencies, and the concept of the "frequency slot". Corresponding techniques for data-plane connections are known as "flexi-grid".

Based on the characteristics of flexi-grid defined in G.694.1 and in RFCs 7698 and 7699, this document describes the Open Shortest Path First - Traffic Engineering (OSPF-TE) extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid.

 draft-ietf-ccamp-flexible-grid-ospf-ext-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC8363 RFC8364 PIM Flooding Mechanism (PFM) and Source Discovery (SD) IJ. Wijnands S. Venaas M. Brig A. Jonasson March 2018 ASCII HTML 18 Multicast

Protocol Independent Multicast - Sparse Mode (PIM-SM) uses a Rendezvous Point (RP) and shared trees to forward multicast packets from new sources. Once Last-Hop Routers (LHRs) receive packets from a new source, they may join the Shortest Path Tree (SPT) for the source for optimal forwarding. This document defines a new mechanism that provides a way to support PIM-SM without the need for PIM registers, RPs, or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIM Flooding Mechanism (PFM). This allows LHRs to learn about new sources without receiving initial data packets.

 draft-ietf-pim-source-discovery-bsr-12 RFC8736 EXPERIMENTAL EXPERIMENTAL IETF rtg pim 10.17487/RFC8364 RFC8365 A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) A. Sajassi Editor J. Drake Editor N. Bitar R. Shekhar J. Uttaro W. Henderickx March 2018 ASCII HTML 33 EVPN Control Plane with VxLAN Encapsulation EVPN Control Plane with NvGRE Encapsulation

This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices.

 draft-ietf-bess-evpn-overlay-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess http://www.rfc-editor.org/errata_search.php?rfc=8365 10.17487/RFC8365 RFC8366 A Voucher Artifact for Bootstrapping Protocols K. Watsen M. Richardson M. Pritikin T. Eckert May 2018 ASCII HTML 23 voucher autonomic networking autonomous operation self-management

This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher".

This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)).

This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.

 draft-ietf-anima-voucher-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops anima http://www.rfc-editor.org/errata_search.php?rfc=8366 10.17487/RFC8366 RFC8367 Wrongful Termination of Internet Protocol (IP) Packets T. Mizrahi J. Yallouz April 1 2018 ASCII HTML 6

Routers and middleboxes terminate packets for various reasons. In some cases, these packets are wrongfully terminated. This memo describes some of the most common scenarios of wrongful termination of Internet Protocol (IP) packets and presents recommendations for mitigating them.

 draft-tj-wrongful-termination-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8367 RFC8368 Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) T. Eckert Editor M. Behringer May 2018 ASCII HTML 24 autonomic networking autonomous operation self-management

Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes.

Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on. Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns.

This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to the aforementioned circular dependencies.

 draft-ietf-anima-stable-connectivity-10 INFORMATIONAL INFORMATIONAL IETF ops anima 10.17487/RFC8368 RFC8369 Internationalizing IPv6 Using 128-Bit Unicode H. Kaplan April 1 2018 ASCII HTML 11

It is clear that Unicode will eventually exhaust its supply of code points, and more will be needed. Assuming ISO and the Unicode Consortium follow the practices of the IETF, the next Unicode code point size will be 128 bits. This document describes how this future 128-bit Unicode can be leveraged to improve IPv6 adoption and finally bring internationalization support to IPv6.

 draft-kaplan-unicode-ipv6-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8369 10.17487/RFC8369 RFC8370 Techniques to Improve the Scalability of RSVP-TE Deployments V. Beeram Editor I. Minei R. Shakir D. Pacella T. Saad May 2018 ASCII HTML 11 RSVP-TE Scaling RI-RSVP Per-Peer Flow Control

Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed.

This document defines two techniques, Refresh-Interval Independent RSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in Label Switching Routers (LSRs) and hence allow implementations to support larger scale deployments.

 draft-ietf-teas-rsvp-te-scaling-rec-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8370 RFC8371 Mobile Node Identifier Types for MIPv6 C. Perkins V. Devarapalli July 2018 ASCII HTML 16 Mobility IPv6 Authentication

This document defines additional identifier type numbers for use with the mobile node identifier option for Mobile IPv6 (MIPv6) as defined by RFC 4283.

 draft-ietf-dmm-4283mnids-08 PROPOSED STANDARD PROPOSED STANDARD IETF int dmm 10.17487/RFC8371 RFC8372 MPLS Flow Identification Considerations S. Bryant C. Pignataro M. Chen Z. Li G. Mirsky May 2018 ASCII HTML 11 OAM performance monitoring flow identification

This document discusses aspects to consider when developing a solution for MPLS flow identification. The key application that needs this solution is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets.

 draft-ietf-mpls-flow-ident-07 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC8372 RFC8373 Negotiating Human Language in Real-Time Communications R. Gellens May 2018 ASCII HTML 13 SDP language human language SIP SLIM

Users have various human (i.e., natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. This document defines new Session Description Protocol (SDP) media- level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (i.e., communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important for emergency calls, because it allows for a call to be handled by a call taker capable of communicating with the user or for a translator or relay operator to be bridged into the call during setup. However, this also applies to non-emergency calls (for example, calls to a company call center).

This document describes the need as well as a solution that uses new SDP media attributes.

 draft-ietf-slim-negotiating-human-language-24 RFC8865 PROPOSED STANDARD PROPOSED STANDARD IETF art slim http://www.rfc-editor.org/errata_search.php?rfc=8373 10.17487/RFC8373 RFC8374 BGPsec Design Choices and Summary of Supporting Discussions K. Sriram Editor April 2018 ASCII HTML 50 Internet Routing Security

This document captures the design rationale of the initial draft version of what became RFC 8205 (the BGPsec protocol specification). The designers needed to balance many competing factors, and this document lists the decisions that were made in favor of or against each design choice. This document also presents brief summaries of the arguments that aided the decision process. Where appropriate, this document also provides brief notes on design decisions that changed as the specification was reviewed and updated by the IETF SIDR Working Group and that resulted in RFC 8205. These notes highlight the differences and provide pointers to details and rationale regarding those design changes.

 draft-sriram-bgpsec-design-choices-16 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8374 RFC8375 Special-Use Domain 'home.arpa.' P. Pfister T. Lemon May 2018 ASCII HTML 12 Homenet TLD RFC6761 .home.arpa

This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.' and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. The Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'.

 draft-ietf-homenet-dot-14 RFC7788 PROPOSED STANDARD PROPOSED STANDARD IETF int homenet http://www.rfc-editor.org/errata_search.php?rfc=8375 10.17487/RFC8375 RFC8376 Low-Power Wide Area Network (LPWAN) Overview S. Farrell Editor May 2018 ASCII HTML 43 Low Power Wide Area Network Overview

Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs.

 draft-ietf-lpwan-overview-10 INFORMATIONAL INFORMATIONAL IETF int lpwan 10.17487/RFC8376 RFC8377 Transparent Interconnection of Lots of Links (TRILL): Multi-Topology D. Eastlake 3rd M. Zhang A. Banerjee July 2018 ASCII HTML 20

This document specifies extensions to the IETF TRILL (Transparent Interconnection of Lots of Links) protocol to support multi-topology routing of unicast and multi-destination traffic based on IS-IS (Intermediate System to Intermediate System) multi-topology specified in RFC 5120. This document updates RFCs 6325 and 7177.

 draft-ietf-trill-multi-topology-06 RFC6325 RFC7177 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8377 RFC8378 Signal-Free Locator/ID Separation Protocol (LISP) Multicast V. Moreno D. Farinacci May 2018 ASCII HTML 21 LISP deployment

When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism described in this document uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites.

 draft-ietf-lisp-signal-free-multicast-09 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC8378 RFC8379 OSPF Graceful Link Shutdown S. Hegde P. Sarkar H. Gredler M. Nanduri L. Jalil May 2018 ASCII HTML 17 MPLS IGP OSPF

When a link is being prepared to be taken out of service, the traffic needs to be diverted from both ends of the link. Increasing the metric to the highest value on one side of the link is not sufficient to divert the traffic flowing in the other direction.

It is useful for the routers in an OSPFv2 or OSPFv3 routing domain to be able to advertise a link as being in a graceful-shutdown state to indicate impending maintenance activity on the link. This information can be used by the network devices to reroute the traffic effectively.

This document describes the protocol extensions to disseminate graceful-link-shutdown information in OSPFv2 and OSPFv3.

 draft-ietf-ospf-link-overload-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC8379 RFC8380 Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation L. Dunbar D. Eastlake 3rd R. Perlman May 2018 ASCII HTML 10 Directory Nickname

This document describes how data center networks can benefit from non-RBridge nodes performing TRILL (Transparent Interconnection of Lots of Links) encapsulation with assistance from a directory service.

 draft-ietf-trill-directory-assisted-encap-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8380 RFC8381 Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol D. Eastlake 3rd Y. Li W. Hao A. Banerjee May 2018 ASCII HTML 11 OUI CID

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol is implemented by devices called TRILL switches or RBridges (Routing Bridges). TRILL includes a general mechanism, called an RBridge Channel, for the transmission of typed messages between RBridges in the same campus and between RBridges and end stations on the same link. This document specifies a method to send vendor-specific messages over the RBridge Channel facility.

 draft-ietf-trill-vendor-channel-01 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8381 RFC8382 Shared Bottleneck Detection for Coupled Congestion Control for RTP Media D. Hayes Editor S. Ferlin M. Welzl K. Hiorth June 2018 ASCII HTML 25 SBD

This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. This mechanism relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed.

 draft-ietf-rmcat-sbd-11 EXPERIMENTAL EXPERIMENTAL IETF tsv rmcat 10.17487/RFC8382 RFC8383 Transparent Interconnection of Lots of Links (TRILL): Address Flush Message W. Hao D. Eastlake 3rd Y. Li M. Umair May 2018 ASCII HTML 20 convergence VLAN data label FGL

The TRILL (Transparent Interconnection of Lots of Links) protocol, by default, learns end station addresses from observing the data plane. In particular, it learns local Media Access Control (MAC) addresses and the edge switch port of attachment from the receipt of local data frames and learns remote MAC addresses and the edge switch port of attachment from the decapsulation of remotely sourced TRILL Data packets.

This document specifies a message by which a TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the decapsulation of TRILL Data packets. This is a supplement to the TRILL automatic address forgetting (see Section 4.8.3 of RFC 6325) and can assist in achieving more rapid convergence in case of topology or configuration change.

 draft-ietf-trill-address-flush-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8383 RFC8384 Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes R. Perlman F. Hu D. Eastlake 3rd T. Liao July 2018 ASCII HTML 17 TRILL Smart Endnode

This document addresses the problem of the size and freshness of the endnode learning table in edge Routing Bridges (RBridges), by allowing endnodes to volunteer for endnode learning and encapsulation/decapsulation. Such an endnode is known as a "Smart Endnode". Only the attached edge RBridge can distinguish a "Smart Endnode" from a "normal endnode". The Smart Endnode uses the nickname of the attached edge RBridge, so this solution does not consume extra nicknames. The solution also enables endnodes that are Fine-Grained Label (FGL) aware.

 draft-ietf-trill-smart-endnodes-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8384 RFC8385 Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLS M. Umair S. Kingston Smiler D. Eastlake 3rd L. Yong June 2018 ASCII HTML 16 VPLS VPTS TIR

This document specifies methods to interconnect multiple TRILL (Transparent Interconnection of Lots of Links) sites with an intervening MPLS network using existing TRILL and VPLS (Virtual Private LAN Service) standards. This document addresses two problems: 1) providing connection between more than two TRILL sites that are separated by an MPLS provider network and 2) providing a single logical virtualized TRILL network for different tenants that are separated by an MPLS provider network.

 draft-ietf-trill-transport-over-mpls-08 INFORMATIONAL INFORMATIONAL IETF rtg trill 10.17487/RFC8385 RFC8386 Privacy Considerations for Protocols Relying on IP Broadcast or Multicast R. Winter M. Faath F. Weisshaar May 2018 ASCII HTML 13 IP broadcasts multicast privacy considerations

A number of application-layer protocols make use of IP broadcast or multicast messages for functions such as local service discovery or name resolution. Some of these functions can only be implemented efficiently using such mechanisms. When using broadcast or multicast messages, a passive observer in the same broadcast or multicast domain can trivially record these messages and analyze their content. Therefore, designers of protocols that make use of broadcast or multicast messages need to take special care when designing their protocols.

 draft-ietf-intarea-broadcast-consider-09 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC8386 RFC8387 Practical Considerations and Implementation Experiences in Securing Smart Object Networks M. Sethi J. Arkko A. Keranen H. Back May 2018 ASCII HTML 33 IoT security integrity signing ECC CoAP asymmetric cryptography

This memo describes challenges associated with securing resource- constrained smart object devices. The memo describes a possible deployment model where resource-constrained devices sign message objects, discusses the availability of cryptographic libraries for resource-constrained devices, and presents some preliminary experiences with those libraries for message signing on resource- constrained devices. Lastly, the memo discusses trade-offs involving different types of security approaches.

 draft-ietf-lwig-crypto-sensors-06 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC8387 RFC8388 Usage and Applicability of BGP MPLS-Based Ethernet VPN J. Rabadan Editor S. Palislamovic W. Henderickx A. Sajassi J. Uttaro May 2018 ASCII HTML 31 EVPN

This document discusses the usage and applicability of BGP MPLS-based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures are explained in the example scenario along with the benefits and trade-offs of each option. This document is intended to provide a simplified guide for the deployment of EVPN networks.

 draft-ietf-bess-evpn-usage-09 INFORMATIONAL INFORMATIONAL IETF rtg bess 10.17487/RFC8388 RFC8389 Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E) Y. Fu S. Jiang B. Liu J. Dong Y. Chen December 2018 ASCII HTML 16 IPv6 MAP

This memo defines a portion of the Management Information Base (MIB) for Mapping of Address and Port with Encapsulation (MAP-E) for use with network management protocols.

 draft-ietf-softwire-map-mib-13 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8389 RFC8390 RSVP-TE Path Diversity Using Exclude Route Z. Ali Editor G. Swallow Editor F. Zhang Editor D. Beller Editor July 2018 ASCII HTML 26 LSP diversity

RSVP-TE provides support for the communication of exclusion information during Label Switched Path (LSP) setup. A typical LSP diversity use case is for protection, where two LSPs should follow different paths through the network in order to avoid single points of failure, thus greatly improving service availability. This document specifies an approach that can be used for network scenarios where the full path(s) is not necessarily known by use of an abstract identifier for the path. Three types of abstract identifiers are specified: client based, Path Computation Element (PCE) based, and network based. This document specifies two new diversity subobjects for the RSVP eXclude Route Object (XRO) and the Explicit Exclusion Route Subobject (EXRS).

For the protection use case, LSPs are typically created at a slow rate and exist for a long time so that it is reasonable to assume that a given (reference) path currently existing (with a well-known identifier) will continue to exist and can be used as a reference when creating the new diverse path. Re-routing of the existing (reference) LSP, before the new path is established, is not considered.

 draft-ietf-teas-lsp-diversity-10 RFC4874 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8390 RFC8391 XMSS: eXtended Merkle Signature Scheme A. Huelsing D. Butin S. Gazdag J. Rijneveld A. Mohaisen May 2018 ASCII HTML 74 Digital signature cryptography post-quantum cryptography Hash-based signatures Merkle signatures Merkle tree hash function Winternitz Winternitz one-time signature scheme WOTS W-OTS WOTS+ W-OTS+ XMSS-MT multi-tree XMSS

This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature. This note specifies Winternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers.

 draft-irtf-cfrg-xmss-hash-based-signatures-12 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8391 10.17487/RFC8391 RFC8392 CBOR Web Token (CWT) M. Jones E. Wahlstroem S. Erdtman H. Tschofenig May 2018 ASCII HTML 25 JSON Web Token JWT Claims Concise Binary Object Representation CBOR CBOR Object Signing and Encryption COSE OAuth ACE

CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.

 draft-ietf-ace-cbor-web-token-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec ace http://www.rfc-editor.org/errata_search.php?rfc=8392 10.17487/RFC8392 RFC8393 Operating the Network Service Header (NSH) with Next Protocol "None" A. Farrel J. Drake May 2018 ASCII HTML 12 Service Function Chaining Network Service Header Metadata

This document describes a network that supports Service Function Chaining (SFC) using the Network Service Header (NSH) with no payload data and carrying only metadata. This is achieved by defining a new NSH "Next Protocol" type value of "None".

This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes. It is expected that other documents will describe specific use cases in more detail and will define the protocol mechanics for each use case.

 draft-farrel-sfc-convent-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sfc 10.17487/RFC8393 RFC8394 Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements Y. Li D. Eastlake 3rd L. Kreeger T. Narten D. Black May 2018 ASCII HTML 26 NVO3 VDP

In the Split Network Virtualization Edge (Split-NVE) architecture, the functions of the NVE are split across a server and a piece of external network equipment that is called an "External NVE". The server-resident control-plane functionality resides in control software, which may be part of hypervisor or container-management software; for simplicity, this document refers to the hypervisor as the "location" of this software.

One or more control-plane protocols between a hypervisor and its associated External NVE(s) are used by the hypervisor to distribute its virtual-machine networking state to the External NVE(s) for further handling. This document illustrates the functionality required by this type of control-plane signaling protocol and outlines the high-level requirements. Virtual-machine states as well as state transitioning are summarized to help clarify the protocol requirements.

 draft-ietf-nvo3-hpvr2nve-cp-req-17 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC8394 RFC8395 Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels K. Patel S. Boutros J. Liste B. Wen J. Rabadan June 2018 ASCII HTML 9

This document defines protocol extensions required to synchronize flow label states among Provider Edges (PEs) when using the BGP-based signaling procedures. These protocol extensions are equally applicable to point-to-point Layer 2 Virtual Private Networks (L2VPNs). This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community.

 draft-ietf-bess-fat-pw-bgp-04 RFC4761 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8395 RFC8396 Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework J. Peterson T. McGarry July 2018 ASCII HTML 23 SIP Problem Statement Real-Time Communication

The functions of the Public Switched Telephone Network (PSTN) are rapidly migrating to the Internet. This is generating new requirements for many traditional elements of the PSTN, including Telephone Numbers (TNs). TNs no longer serve simply as telephone routing addresses: they are now identifiers that may be used by Internet-based services for a variety of purposes including session establishment, identity verification, and service enablement. This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the use cases of the Internet environment and proposes a framework for Internet-based services relying on TNs.

 draft-ietf-modern-problem-framework-04 INFORMATIONAL INFORMATIONAL IETF art modern 10.17487/RFC8396 RFC8397 Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames M. Zhang D. Eastlake 3rd R. Perlman H. Zhai D. Liu May 2018 ASCII HTML 16 Aggregated Global Tree Local Tree

TRILL (Transparent Interconnection of Lots of Links) routing can be extended to support multiple levels by building on the multilevel feature of IS-IS routing. Depending on how nicknames are managed, there are two primary alternatives to realize TRILL multilevel: the unique nickname approach and the aggregated nickname approach as discussed in RFC 8243. This document specifies a unique nickname approach. This approach gives unique nicknames to all TRILL switches across the multilevel TRILL campus.

 draft-ietf-trill-multilevel-unique-nickname-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8397 RFC8398 Internationalized Email Addresses in X.509 Certificates A. Melnikov Editor W. Chuang Editor May 2018 ASCII HTML 12 EAI PKIX emal address

This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address.

This document updates RFC 5280.

 draft-ietf-lamps-eai-addresses-18 RFC5280 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps http://www.rfc-editor.org/errata_search.php?rfc=8398 10.17487/RFC8398 RFC8399 Internationalization Updates to RFC 5280 R. Housley May 2018 ASCII HTML 9

The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for internationalized email addresses in X.509 certificates.

 draft-ietf-lamps-rfc5280-i18n-update-04 RFC5280 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8399 RFC8400 Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection H. Chen A. Liu T. Saad F. Xu L. Huang June 2018 ASCII HTML 21 FRR Fast Reroute

This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP).

 draft-ietf-teas-rsvp-egress-protection-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas http://www.rfc-editor.org/errata_search.php?rfc=8400 10.17487/RFC8400 RFC8401 Bit Index Explicit Replication (BIER) Support via IS-IS L. Ginsberg Editor T. Przygienda S. Aldrin Z. Zhang June 2018 ASCII HTML 12

This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture.

 draft-ietf-bier-isis-extensions-11 RFC9272 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bier http://www.rfc-editor.org/errata_search.php?rfc=8401 10.17487/RFC8401 RFC8402 Segment Routing Architecture C. Filsfils Editor S. Previdi Editor L. Ginsberg B. Decraene S. Litkowski R. Shakir July 2018 ASCII HTML 32

Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.

SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.

SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.

 draft-ietf-spring-segment-routing-15 RFC9256 PROPOSED STANDARD PROPOSED STANDARD IETF rtg spring 10.17487/RFC8402 RFC8403 A Scalable and Topology-Aware MPLS Data-Plane Monitoring System R. Geib Editor C. Filsfils C. Pignataro Editor N. Kumar July 2018 ASCII HTML 19 Segment based Routing OAM LSP surveillance MPLS monitoring

This document describes features of an MPLS path monitoring system and related use cases. Segment-based routing enables a scalable and simple method to monitor data-plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and Label Switched Path (LSP) trace, in a very complementary way. MPLS topology awareness reduces management and control-plane involvement of Operations, Administration, and Maintenance (OAM) measurements while enabling new OAM features.

 draft-ietf-spring-oam-usecase-10 INFORMATIONAL INFORMATIONAL IETF rtg spring 10.17487/RFC8403 RFC8404 Effects of Pervasive Encryption on Operators K. Moriarty Editor A. Morton Editor July 2018 ASCII HTML 53 NETCONF RESTCONF Monitoring Management Security Management Operations

Pervasive monitoring attacks on the privacy of Internet users are of serious concern to both user and operator communities. RFC 7258 discusses the critical need to protect users' privacy when developing IETF specifications and also recognizes that making networks unmanageable to mitigate pervasive monitoring is not an acceptable outcome: an appropriate balance is needed. This document discusses current security and network operations as well as management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable and secure networks.

 draft-mm-wg-effect-encrypt-25 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8404 RFC8405 Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs B. Decraene S. Litkowski H. Gredler A. Lindem P. Francois C. Bowers June 2018 ASCII HTML 14

This document defines a standard algorithm to temporarily postpone or "back off" link-state IGP Shortest Path First (SPF) computations. This reduces the computational load and churn on IGP nodes when multiple temporally close network events trigger multiple SPF computations.

Having one standard algorithm improves interoperability by reducing the probability and/or duration of transient forwarding loops during the IGP convergence when the IGP reacts to multiple temporally close IGP events.

 draft-ietf-rtgwg-backoff-algo-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8405 RFC8406 Taxonomy of Coding Techniques for Efficient Network Communications B. Adamson C. Adjih J. Bilbao V. Firoiu F. Fitzek S. Ghanem E. Lochin A. Masucci M-J. Montpetit M. Pedersen G. Peralta V. Roca Editor P. Saxena S. Sivakumar June 2018 ASCII HTML 15 Network Coding Taxonomy

This document summarizes recommended terminology for Network Coding concepts and constructs. It provides a comprehensive set of terms in order to avoid ambiguities in future IRTF and IETF documents on Network Coding. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG), and it is in line with the terminology used by the RFCs produced by the Reliable Multicast Transport (RMT) and FEC Framework (FECFRAME) IETF working groups.

 draft-irtf-nwcrg-network-coding-taxonomy-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8406 RFC8407 Guidelines for Authors and Reviewers of Documents Containing YANG Data Models A. Bierman October 2018 ASCII HTML 63 NETMOD NETCONF RESTCONF

This memo provides guidelines for authors and reviewers of specifications containing YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 6087.

 draft-ietf-netmod-rfc6087bis-20 RFC6087 RFC8819 BCP0216 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8407 10.17487/RFC8407 RFC8408 Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages S. Sivabalan J. Tantsura I. Minei R. Varga J. Hardwick July 2018 ASCII HTML 12

A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol (PCEP) to allow support for different path setup methods over a given PCEP session.

 draft-ietf-pce-lsp-setup-type-10 RFC8664 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8408 RFC8409 The Entity Category Security Assertion Markup Language (SAML) Attribute Types I. Young Editor L. Johansson S. Cantor August 2018 ASCII HTML 12 REFEDS

This document describes two SAML entity attributes: one that can be used to assign category membership semantics to an entity and another for use in claiming interoperation with or support for entities in such categories.

This document is a product of the working group process of the Research and Education FEDerations (REFEDS) group.

 draft-young-entity-category-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8409 RFC8410 Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure S. Josefsson J. Schaad August 2018 ASCII HTML 20 Elliptic Curve Cryptography Curve25519 Curve448 Goldilocks X.509 PKIX PKI OID ASN.1 EdDSA Ed25519 Ed448 X25519 X448

This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided.

 draft-ietf-curdle-pkix-10 RFC9295 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8410 10.17487/RFC8410 RFC8411 IANA Registration for the Cryptographic Algorithm Object Identifier Range J. Schaad R. Andrews August 2018 ASCII HTML 5

When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range.

 draft-schaad-curdle-oid-registry-03 INFORMATIONAL INFORMATIONAL IETF sec curdle 10.17487/RFC8411 RFC8412 Software Inventory Message and Attributes (SWIMA) for PA-TNC C. Schmidt D. Haynes C. Coffin D. Waltermire J. Fitzgerald-McKay July 2018 ASCII HTML 101 SWID PA-TNC NEA Software inventory

This document extends "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA): Overview and Requirements" (RFC 5209).

 draft-ietf-sacm-nea-swima-patnc-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec sacm 10.17487/RFC8412 RFC8413 Framework for Scheduled Use of Resources Y. Zhuang Q. Wu H. Chen A. Farrel July 2018 ASCII HTML 22 Traffic Engineering TE Label Switched Path LSP MPLS Path Computation Element PCE Software Defined Networking SDN

Time-Scheduled (TS) reservation of Traffic Engineering (TE) resources can be used to provide resource booking for TE Label Switched Paths so as to better guarantee services for customers and to improve the efficiency of network resource usage at any moment in time, including network usage that is planned for the future. This document provides a framework that describes and discusses the architecture for supporting scheduled reservation of TE resources. This document does not describe specific protocols or protocol extensions needed to realize this service.

 draft-ietf-teas-scheduled-resources-07 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8413 RFC8414 OAuth 2.0 Authorization Server Metadata M. Jones N. Sakimura J. Bradley June 2018 ASCII HTML 23 OAuth Discovery Metadata Discovery Metadata Configuration Information Authorization Server WebFinger JavaScript Object Notation JSON JSON Web Token JWT

This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.

 draft-ietf-oauth-discovery-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC8414 RFC8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) T. Mrugalski M. Siodelski B. Volz A. Yourtchenko M. Richardson S. Jiang T. Lemon T. Winters November 2018 ASCII HTML 154 DHCPv6 IPv6 DHCP

This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).

This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.

 draft-ietf-dhc-rfc3315bis-13 RFC3315 RFC3633 RFC3736 RFC4242 RFC7083 RFC7283 RFC7550 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=8415 10.17487/RFC8415 RFC8416 Simplified Local Internet Number Resource Management with the RPKI (SLURM) D. Ma D. Mandelberg T. Bruijnzeels August 2018 ASCII HTML 17 RPKI Local Trust Anchor BGPsec

The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origin assertions. ISPs can also use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed.

 draft-ietf-sidr-slurm-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=8416 10.17487/RFC8416 RFC8417 Security Event Token (SET) P. Hunt Editor M. Jones W. Denniss M. Ansari July 2018 ASCII HTML 28 Identity Security Event Token Claims JSON JSON Web Token JWT

This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.

 draft-ietf-secevent-token-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec secevent http://www.rfc-editor.org/errata_search.php?rfc=8417 10.17487/RFC8417 RFC8418 Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) R. Housley August 2018 ASCII HTML 18

This document describes the conventions for using the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS).

 draft-ietf-curdle-cms-ecdh-new-curves-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8418 RFC8419 Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS) R. Housley August 2018 ASCII HTML 9

This document specifies the conventions for using the Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS.

 draft-ietf-curdle-cms-eddsa-signatures-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8419 10.17487/RFC8419 RFC8420 Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2) Y. Nir August 2018 ASCII HTML 5

This document describes the use of the Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2).

 draft-ietf-ipsecme-eddsa-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8420 RFC8421 Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE) P. Martinsen T. Reddy P. Patil July 2018 ASCII HTML 9

This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backward compatible with the original ICE specification (see RFC 5245).

 draft-ietf-ice-dualstack-fairness-07 BCP0217 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF art ice 10.17487/RFC8421 RFC8422 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier Y. Nir S. Josefsson M. Pegourie-Gonnard August 2018 ASCII HTML 34 ECDSA EdDSA

This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.

This document obsoletes RFC 4492.

 draft-ietf-tls-rfc4492bis-17 RFC4492 RFC8996 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=8422 10.17487/RFC8422 RFC8423 Reclassification of Suite B Documents to Historic Status R. Housley L. Zieglar July 2018 ASCII HTML 8 x.509 v3 certificates x.509 v2 certificate revocation lists crl UI suites user interface suites elliptic curve ike cryptographic algorithm policy security application suite b cryptography cmc suite b x.509 public key certificates cryptographic algorithm policy nsa

This document reclassifies the RFCs related to the United States National Security Agency (NSA) Suite B cryptographic algorithms as Historic, and it discusses the reasons for doing so. This document moves seven Informational RFCs to Historic status: RFCs 5759, 6239, 6318, 6379, 6380, 6403, and 6460. In addition, it moves three obsolete Informational RFCs to Historic status: RFCs 4869, 5008, and 5430.

 draft-housley-suite-b-to-historic-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8423 10.17487/RFC8423 RFC8424 Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection H. Chen Editor R. Torvi Editor August 2018 ASCII HTML 28 Head Protection

This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP). It extends the Fast Reroute (FRR) protection for transit nodes of an LSP to the ingress node of the LSP. The procedures described in this document are experimental.

 draft-ietf-teas-rsvp-ingress-protection-17 EXPERIMENTAL EXPERIMENTAL IETF rtg teas 10.17487/RFC8424 RFC8425 IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags O. Troan July 2018 ASCII HTML 4

The Prefix Information Option (PIO) in the IPv6 Neighbor Discovery Router Advertisement message defines an 8-bit flag field; this field has two flags defined, and the remaining 6 bits are reserved (Reserved1). RFC 6275 defines a flag from this field without creating an IANA registry or updating RFC 4861. The purpose of this document is to create an IANA registry for the PIO flags. This document updates RFC 4861.

 draft-ietf-6man-ndpioiana-04 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8425 RFC8426 Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence H. Sitaraman Editor V. Beeram I. Minei S. Sivabalan July 2018 ASCII HTML 12

Operators are looking to introduce services over Segment Routing (SR) Label Switched Paths (LSPs) in networks running Resource Reservation Protocol - Traffic Engineering (RSVP-TE) LSPs. In some instances, operators are also migrating existing services from RSVP-TE to SR LSPs. For example, there might be certain services that are well suited for SR and need to coexist with RSVP-TE in the same network. Such introduction or migration of traffic to SR might require coexistence with RSVP-TE in the same network for an extended period of time, depending on the operator's intent. The following document provides solution options for keeping the traffic engineering database consistent across the network, accounting for the different bandwidth utilization between SR and RSVP-TE.

 draft-ietf-teas-sr-rsvp-coexistence-rec-04 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8426 RFC8427 Representing DNS Messages in JSON P. Hoffman July 2018 ASCII HTML 15

Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search them without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a general format for DNS message data in JSON. Specific profiles of the format in this document can be described in other documents for specific applications and usage scenarios.

 draft-hoffman-dns-in-json-16 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8427 10.17487/RFC8427 RFC8428 Sensor Measurement Lists (SenML) C. Jennings Z. Shelby J. Arkko A. Keranen C. Bormann August 2018 ASCII HTML 54 IoT data model

This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.

 draft-ietf-core-senml-16 RFC9100 PROPOSED STANDARD PROPOSED STANDARD IETF art core http://www.rfc-editor.org/errata_search.php?rfc=8428 10.17487/RFC8428 RFC8429 Deprecate Triple-DES (3DES) and RC4 in Kerberos B. Kaduk M. Short October 2018 ASCII HTML 10 GSS-API GSS

The triple-DES (3DES) and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should begin for their use in Kerberos. Accordingly, RFC 4757 has been moved to Historic status, as none of the encryption types it specifies should be used, and RFC 3961 has been updated to note the deprecation of the triple-DES encryption types. RFC 4120 is likewise updated to remove the recommendation to implement triple-DES encryption and checksum types.

 draft-ietf-curdle-des-des-des-die-die-die-05 RFC3961 RFC4120 BCP0218 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec curdle 10.17487/RFC8429 RFC8430 RIB Information Model N. Bahadur Editor S. Kini Editor J. Medved September 2018 ASCII HTML 28 RIB info model

Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a Routing Information Base (RIB). Protocols and configurations push data into the RIB, and the RIB manager installs state into the hardware for packet forwarding. This document specifies an information model for the RIB to enable defining a standardized data model. The IETF's I2RS WG used this document to design the I2RS RIB data model. This document is being published to record the higher- level information model decisions for RIBs so that other developers of RIBs may benefit from the design concepts.

 draft-ietf-i2rs-rib-info-model-17 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC8430 RFC8431 A YANG Data Model for the Routing Information Base (RIB) L. Wang M. Chen A. Dass H. Ananthakrishnan S. Kini N. Bahadur September 2018 ASCII HTML 71

This document defines a YANG data model for the Routing Information Base (RIB) that aligns with the Interface to the Routing System (I2RS) RIB information model.

 draft-ietf-i2rs-rib-data-model-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg i2rs 10.17487/RFC8431 RFC8432 A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters J. Ahlberg Editor M. Ye Editor X. Li LM. Contreras CJ. Bernardos October 2018 ASCII HTML 20 Microwave millimeter waves YANG Model interface management

The unification of control and management of microwave radio link interfaces is a precondition for seamless multi-layer networking and automated network provisioning and operation.

This document describes the required characteristics and use cases for control and management of radio link interface parameters using a YANG data model.

The purpose is to create a framework to identify the necessary information elements and define a YANG data model for control and management of the radio link interfaces in a microwave node. Some parts of the resulting model may be generic and could also be used by other technologies, e.g., Ethernet technology.

 draft-ietf-ccamp-microwave-framework-07 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC8432 RFC8433 A Simpler Method for Resolving Alert-Info URNs D. Worley August 2018 ASCII HTML 45 Alert-Info audio signals call signaling call transfer resolution signaling signals SIP URN visual signals

The "alert" namespace of Uniform Resource Names (URNs) can be used in the Alert-Info header field of Session Initiation Protocol (SIP) requests and responses to inform a voice over IP (VoIP) telephone (user agent) of the characteristics of the call that the user agent has originated or terminated. The user agent must resolve the URNs into a signal; that is, it must select the best available signal to present to its user to indicate the characteristics of the call.

RFC 7462 describes a non-normative algorithm for signal selection. This document describes a more efficient alternative algorithm: a user agent's designer can, based on the user agent's signals and their meanings, construct a finite state machine (FSM) to process the URNs to select a signal in a way that obeys the restrictions given in the definition of the "alert" URN namespace.

 draft-worley-alert-info-fsm-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8433 RFC8434 Requirements for Parallel NFS (pNFS) Layout Types T. Haynes August 2018 ASCII HTML 17 NFSv4

This document defines the requirements that individual Parallel NFS (pNFS) layout types need to meet in order to work within the pNFS framework as defined in RFC 5661. In so doing, this document aims to clearly distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS file layout. The lack of a clear separation between the two sets of requirements has been troublesome for those specifying and evaluating new layout types. In this regard, this document updates RFC 5661.

 draft-ietf-nfsv4-layout-types-13 RFC5661 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8434 RFC8435 Parallel NFS (pNFS) Flexible File Layout B. Halevy T. Haynes August 2018 ASCII HTML 42 NFSv4

Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flexible file layout type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Client-side mirroring is also added to provide replication of files.

 draft-ietf-nfsv4-flex-files-19 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8435 RFC8436 Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry G. Fairhurst August 2018 ASCII HTML 7 Diffserv DSCP

The Differentiated Services (Diffserv) architecture specifies use of the DS field in the IPv4 and IPv6 packet headers to carry one of 64 distinct differentiated services field codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values.

This update to RFC 2474 changes the IANA registration policy for Pool 3 of the registry (i.e., DSCP values of the form xxxx01) to Standards Action, i.e., values are assigned through a Standards Track or Best Current Practice RFC. The update also removes permission for experimental and local use of the codepoints that form Pool 3 of the DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes.

 draft-ietf-tsvwg-iana-dscp-registry-08 RFC2474 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8436 RFC8437 IMAP UNAUTHENTICATE Extension for Connection Reuse C. Newman August 2018 ASCII HTML 11 IMAP unauthenticate SASL login authenticate authentication

This specification extends the Internet Message Access Protocol (IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities.

 draft-ietf-extra-imap-unauth-01 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8437 RFC8438 IMAP Extension for STATUS=SIZE S. Bosch August 2018 ASCII HTML 6 imap status size

This document adds a new capability called "STATUS=SIZE" to the Internet Message Access Protocol (IMAP). It allows retrieving the total storage size of a mailbox with a single STATUS command rather than retrieving and summing the sizes of all individual messages in that mailbox.

 draft-ietf-extra-imap-status-size-02 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8438 RFC8439 ChaCha20 and Poly1305 for IETF Protocols Y. Nir A. Langley June 2018 ASCII HTML 46 CHACHA CHACHA20 POLY1305 AEAD

This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.

RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section.

 draft-nir-cfrg-rfc7539bis-04 RFC7539 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8439 10.17487/RFC8439 RFC8440 IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST K. Murchison B. Gondwana August 2018 ASCII HTML 6 IMAP4 LIST MYRIGHTS

This document defines an extension to the Internet Message Access Protocol (IMAP) LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command.

 draft-ietf-extra-imap-list-myrights-07 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8440 RFC8441 Bootstrapping WebSockets with HTTP/2 P. McManus September 2018 ASCII HTML 8 CONNECT SETTINGS

This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection.

 draft-ietf-httpbis-h2-websockets-07 RFC6455 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8441 10.17487/RFC8441 RFC8442 ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2 J. Mattsson D. Migault September 2018 ASCII HTML 7

This document defines several new cipher suites for version 1.2 of the Transport Layer Security (TLS) protocol and version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. These cipher suites are based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides forward secrecy, and AES-GCM and AES-CCM provide encryption and integrity protection.

 draft-ietf-tls-ecdhe-psk-aead-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC8442 RFC8443 Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization R. Singh M. Dolly S. Das A. Nguyen August 2018 ASCII HTML 10 SIP Resource-Priority Resource Priority Header (rph) JSON Web Token Claim Identity header Authentication Service Assertion Verification Service

This document extends the Personal Assertion Token (PASSporT) specification defined in RFC 8225 to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) 'Resource-Priority' header field, which is used for communications resource prioritization.

 draft-ietf-stir-rph-06 PROPOSED STANDARD PROPOSED STANDARD IETF art stir 10.17487/RFC8443 RFC8444 OSPFv2 Extensions for Bit Index Explicit Replication (BIER) P. Psenak Editor N. Kumar IJ. Wijnands A. Dolganow T. Przygienda J. Zhang S. Aldrin November 2018 ASCII HTML 12

Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast-related, per- flow state. BIER also does not require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs). The BFIR adds a BIER packet header to the packet. The BIER packet header contains a BitString in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the set of bits in the BIER packet header.

This document describes the OSPF protocol extension (from RFC 2328) that is required for BIER with MPLS encapsulation (which is defined in RFC 8296). Support for other encapsulation types and the use of multiple encapsulation types are outside the scope of this document.

 draft-ietf-bier-ospf-bier-extensions-18 RFC9272 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bier 10.17487/RFC8444 RFC8445 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal A. Keranen C. Holmberg J. Rosenberg July 2018 ASCII HTML 100 NAT

This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).

This document obsoletes RFC 5245.

 draft-ietf-ice-rfc5245bis-20 RFC5245 RFC8863 PROPOSED STANDARD PROPOSED STANDARD IETF art ice 10.17487/RFC8445 RFC8446 The Transport Layer Security (TLS) Protocol Version 1.3 E. Rescorla August 2018 ASCII HTML 160 international data algorithm symmetric transport protocol layer authentication privacy

This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.

This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.

 draft-ietf-tls-tls13-28 RFC5077 RFC5246 RFC6961 RFC5705 RFC6066 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=8446 10.17487/RFC8446 RFC8447 IANA Registry Updates for TLS and DTLS J. Salowey S. Turner August 2018 ASCII HTML 20

This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.

This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.

 draft-ietf-tls-iana-registry-updates-05 RFC3749 RFC4680 RFC5077 RFC5246 RFC5705 RFC5878 RFC6520 RFC7301 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=8447 10.17487/RFC8447 RFC8448 Example Handshake Traces for TLS 1.3 M. Thomson January 2019 ASCII HTML 68

This document includes examples of TLS 1.3 handshakes. Private keys and inputs are provided so that these handshakes might be reproduced. Intermediate values, including secrets, traffic keys, and IVs, are shown so that implementations might be checked incrementally against these values.

 draft-ietf-tls-tls13-vectors-07 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=8448 10.17487/RFC8448 RFC8449 Record Size Limit Extension for TLS M. Thomson August 2018 ASCII HTML 8 TLS record IoT encryption

An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other.

This replaces the maximum fragment length extension defined in RFC 6066.

 draft-ietf-tls-record-limit-03 RFC6066 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC8449 RFC8450 RTP Payload Format for VC-2 High Quality (HQ) Profile J. Weaver October 2018 ASCII HTML 24 rtp vc-2 VC2 dirac

This memo describes an RTP payload format for the High Quality (HQ) profile of Society of Motion Picture and Television Engineers Standard ST 2042-1, known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video.

The HQ profile of VC-2 is intended for low-latency video compression (with latency potentially on the order of lines of video) at high data rates (with compression ratios on the order of 2:1 or 4:1).

 draft-ietf-payload-rtp-vc2hq-08 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC8450 RFC8451 Considerations for Selecting RTP Control Protocol (RTCP) Extended Report (XR) Metrics for the WebRTC Statistics API V. Singh R. Huang R. Even D. Romascanu L. Deng September 2018 ASCII HTML 18 Web real-time communication

This document describes monitoring features related to media streams in Web real-time communication (WebRTC). It provides a list of RTP Control Protocol (RTCP) Sender Report (SR), Receiver Report (RR), and Extended Report (XR) metrics, which may need to be supported by RTP implementations in some diverse environments. It lists a set of identifiers for the WebRTC's statistics API. These identifiers are a set of RTCP SR, RR, and XR metrics related to the transport of multimedia flows.

 draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-10 INFORMATIONAL INFORMATIONAL IETF art xrblock 10.17487/RFC8451 RFC8452 AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption S. Gueron A. Langley Y. Lindell April 2019 ASCII HTML 42 authenticated encryption aead aes gcm siv

This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated.

This document is the product of the Crypto Forum Research Group.

 draft-irtf-cfrg-gcmsiv-09 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8452 10.17487/RFC8452 RFC8453 Framework for Abstraction and Control of TE Networks (ACTN) D. Ceccarelli Editor Y. Lee Editor August 2018 ASCII HTML 42 SDN Orchestration

Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.

Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.

This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.

 draft-ietf-teas-actn-framework-15 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8453 RFC8454 Information Model for Abstraction and Control of TE Networks (ACTN) Y. Lee S. Belotti D. Dhody D. Ceccarelli B. Yoon September 2018 ASCII HTML 23

This document provides an information model for Abstraction and Control of TE Networks (ACTN).

 draft-ietf-teas-actn-info-model-10 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8454 RFC8455 Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance V. Bhuvaneswaran A. Basil M. Tassinari V. Manral S. Banks October 2018 ASCII HTML 23

This document defines terminology for benchmarking a Software-Defined Networking (SDN) controller's control-plane performance. It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN Controllers. The terms provided in this document help to benchmark an SDN Controller's performance independently of the controller's supported protocols and/or network services.

 draft-ietf-bmwg-sdn-controller-benchmark-term-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8455 RFC8456 Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance V. Bhuvaneswaran A. Basil M. Tassinari V. Manral S. Banks October 2018 ASCII HTML 64

This document defines methodologies for benchmarking the control-plane performance of Software-Defined Networking (SDN) Controllers. The SDN Controller is a core component in the SDN architecture that controls the behavior of the network. SDN Controllers have been implemented with many varying designs in order to achieve their intended network functionality. Hence, the authors of this document have taken the approach of considering an SDN Controller to be a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers. This document provides a method for measuring the performance of all controller implementations.

 draft-ietf-bmwg-sdn-controller-benchmark-meth-09 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8456 RFC8457 IMAP "$Important" Keyword and "\Important" Special-Use Attribute B. Leiba Editor September 2018 ASCII HTML 11 IMAP attributes

RFC 6154 created an IMAP special-use LIST extension and defined an initial set of attributes. This document defines a new attribute, "\Important", and establishes a new IANA registry for IMAP folder attributes, which include the attributes defined in RFCs 5258, 3501, and 6154. This document also defines a new IMAP keyword, "$Important", and registers it in the registry defined in RFC 5788.

 draft-ietf-extra-specialuse-important-04 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8457 RFC8458 Using National Bibliography Numbers as Uniform Resource Names J. Hakala October 2018 ASCII HTML 18 Network Working Group National bibliography numbers Uniform resource names

National Bibliography Numbers (NBNs) are used by national libraries and other organizations in order to identify resources in their collections. NBNs are usually applied to resources that are not catered for by established (standard) identifier systems such as International Standard Book Number (ISBN).

A Uniform Resource Name (URN) namespace for NBNs was established in 2001 in RFC 3188. Since then, a number of European national libraries have implemented URN:NBN-based systems.

This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration (version 4) compliant to RFC 8141 is included.

 draft-hakala-urn-nbn-rfc3188bis-02 RFC3188 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8458 RFC8459 Hierarchical Service Function Chaining (hSFC) D. Dolson S. Homma D. Lopez M. Boucadair September 2018 ASCII HTML 29 Scalability SFC-enabled domain multiple control domains SFC complexity Hierarchy service delivery service complications service offering differentiated services large scale network

Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration.

The goals of hSFC are to make a large-scale network easier to design, simpler to control, and supportive of independent functional groups within large network operators.

 draft-ietf-sfc-hierarchical-11 EXPERIMENTAL EXPERIMENTAL IETF rtg sfc 10.17487/RFC8459 RFC8460 SMTP TLS Reporting D. Margolis A. Brotman B. Ramakrishnan J. Jones M. Risher September 2018 ASCII HTML 34 DANE MTA-STS

A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS- Based Authentication of Named Entities (DANE) TLSA, and MTA Strict Transport Security (MTA-STS). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations.

 draft-ietf-uta-smtp-tlsrpt-23 PROPOSED STANDARD PROPOSED STANDARD IETF art uta http://www.rfc-editor.org/errata_search.php?rfc=8460 10.17487/RFC8460 RFC8461 SMTP MTA Strict Transport Security (MTA-STS) D. Margolis M. Risher B. Ramakrishnan A. Brotman J. Jones September 2018 ASCII HTML 29 SMTP STARTTLS Mail Security

SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.

 draft-ietf-uta-mta-sts-21 PROPOSED STANDARD PROPOSED STANDARD IETF art uta http://www.rfc-editor.org/errata_search.php?rfc=8461 10.17487/RFC8461 RFC8462 Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) N. Rooney S. Dawkins Editor October 2018 ASCII HTML 28 Networks

The Internet Architecture Board (IAB) and GSM Association (GSMA) held a joint workshop on Managing Radio Networks in an Encrypted World (MaRNEW), on September 24-25, 2015. This workshop aimed to discuss solutions for bandwidth optimization on mobile networks for encrypted content, as current solutions rely on unencrypted content, which is not indicative of the security needs of today's Internet users. The workshop gathered IETF attendees, IAB members, and participants from various organizations involved in the telecommunications industry including original equipment manufacturers, content providers, and mobile network operators.

The group discussed Internet encryption trends and deployment issues identified within the IETF and the privacy needs of users that should be adhered to. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed; in addition, issues experienced when using current transport-layer protocols were also discussed. Content providers and Content Delivery Networks (CDNs) gave their own views of their experiences delivering their content with mobile network operators. Finally, technical responses to regulation were discussed to help the regulated industries relay the issues of impossible-to-implement or bad-for-privacy technologies back to regulators.

A group of suggested solutions were devised, which will be discussed in various IETF groups moving forward.

 draft-iab-marnew-report-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8462 RFC8463 A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM) J. Levine September 2018 ASCII HTML 7 DKIM ed25519 cryptography

This document adds a new signing algorithm, Ed25519-SHA256, to "DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM verifiers are required to implement this algorithm.

 draft-ietf-dcrup-dkim-crypto-14 RFC6376 PROPOSED STANDARD PROPOSED STANDARD IETF art dcrup 10.17487/RFC8463 RFC8464 A URN Namespace for Device Identity and Mobile Equipment Identity (MEID) R. Atarius September 2018 ASCII HTML 10 MEID instance ID IMS

This document defines a Uniform Resource Name (URN) namespace for the Third Generation Partnership Project 2 (3GPP2) and a Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID). The structure of an MEID is 15 hexadecimal digits long and is defined in the 3GPP2 to uniquely identify each individual mobile equipment (e.g., a handset or mobile phone). The 3GPP2 has a requirement to be able to use an MEID as a URN. This document fulfills that requirement.

 draft-atarius-dispatch-meid-urn-18 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8464 RFC8465 Using the Mobile Equipment Identity (MEID) URN as an Instance ID R. Atarius Editor September 2018 ASCII HTML 8 MEID instance ID IMS

This document specifies how the Uniform Resource Name (URN) namespace reserved for the Third Generation Partnership Project 2 (3GPP2) identities and its Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID) can be used as an Instance ID. The purpose of this Instance ID is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior.

 draft-atarius-dispatch-meid-urn-as-instanceid-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8465 RFC8466 A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery B. Wen G. Fioccola Editor C. Xie L. Jalil October 2018 ASCII HTML 158 L2SM Service Model L2VPN SM L2VPN Service Model

This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.

The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624.

The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.

 draft-ietf-l2sm-l2vpn-service-model-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops l2sm http://www.rfc-editor.org/errata_search.php?rfc=8466 10.17487/RFC8466 RFC8467 Padding Policies for Extension Mechanisms for DNS (EDNS(0)) A. Mayrhofer October 2018 ASCII HTML 9 security

RFC 7830 specifies the "Padding" option for Extension Mechanisms for DNS (EDNS(0)) but does not specify the actual padding length for specific applications. This memo lists the possible options ("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option.

 draft-ietf-dprive-padding-policy-06 EXPERIMENTAL EXPERIMENTAL IETF int dprive 10.17487/RFC8467 RFC8468 IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework A. Morton J. Fabini N. Elkins M. Ackermann V. Hegde November 2018 ASCII HTML 15 Measurement Methodology Standard-Formed Packet Type-P Minimal Packet IPv6 Transition

This memo updates the IP Performance Metrics (IPPM) framework defined by RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets to include IPv6 packets, deprecates the definition of minimal IP packet, and augments distinguishing aspects, referred to as Type-P, for test packets in RFC 2330. This memo identifies that IPv4-IPv6 coexistence can challenge measurements within the scope of the IPPM framework. Example use cases include, but are not limited to, IPv4-IPv6 translation, NAT, and protocol encapsulation. IPv6 header compression and use of IPv6 over Low-Power Wireless Area Networks (6LoWPAN) are considered and excluded from the standard-formed packet evaluation.

 draft-ietf-ippm-2330-ipv6-06 RFC2330 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC8468 RFC8469 Recommendation to Use the Ethernet Control Word S. Bryant A. Malis I. Bagdonas November 2018 ASCII HTML 9 pseudowire PW CW ECMP MAC address out of order ordering

The pseudowire (PW) encapsulation of Ethernet, as defined in RFC 4448, specifies that the use of the control word (CW) is optional. In the absence of the CW, an Ethernet PW packet can be misidentified as an IP packet by a label switching router (LSR). This may lead to the selection of the wrong equal-cost multipath (ECMP) path for the packet, leading in turn to the misordering of packets. This problem has become more serious due to the deployment of equipment with Ethernet Media Access Control (MAC) addresses that start with 0x4 or 0x6. The use of the Ethernet PW CW addresses this problem. This document RECOMMENDS the use of the Ethernet PW CW in all but exceptional circumstances.

This document updates RFC 4448.

 draft-ietf-pals-ethernet-cw-07 RFC4448 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals http://www.rfc-editor.org/errata_search.php?rfc=8469 10.17487/RFC8469 RFC8470 Using Early Data in HTTP M. Thomson M. Nottingham W. Tarreau September 2018 ASCII HTML 12 HTTP TLS replay retry 0-RTT early data status code

Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.

 draft-ietf-httpbis-replay-04 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC8470 RFC8471 The Token Binding Protocol Version 1.0 A. Popov Editor M. Nystroem D. Balfanz J. Hodges October 2018 ASCII HTML 18 Token cookie TLS export replay

This document specifies version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time.

 draft-ietf-tokbind-protocol-19 PROPOSED STANDARD PROPOSED STANDARD IETF sec tokbind 10.17487/RFC8471 RFC8472 Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation A. Popov Editor M. Nystroem D. Balfanz October 2018 ASCII HTML 8 Cookie TLS export replay

This document specifies a Transport Layer Security (TLS) extension for the negotiation of Token Binding protocol version and key parameters. Negotiation of Token Binding in TLS 1.3 and later versions is beyond the scope of this document.

 draft-ietf-tokbind-negotiation-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec tokbind 10.17487/RFC8472 RFC8473 Token Binding over HTTP A. Popov M. Nystroem D. Balfanz Editor N. Harper J. Hodges October 2018 ASCII HTML 25 Cookie TLS OAuth export replay

This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections.

We describe both first-party and federated scenarios. In a first- party scenario, an HTTP server is able to cryptographically bind the security tokens that it issues to a client -- and that the client subsequently returns to the server -- to the TLS connection between the client and the server. Such bound security tokens are protected from misuse, since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections.

Federated Token Bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token.

This document is a companion document to "The Token Binding Protocol Version 1.0" (RFC 8471).

 draft-ietf-tokbind-https-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec tokbind 10.17487/RFC8473 RFC8474 IMAP Extension for Object Identifiers B. Gondwana Editor September 2018 ASCII HTML 16 IMAP email

This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server.

 draft-ietf-extra-imap-objectid-08 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8474 RFC8475 Using Conditional Router Advertisements for Enterprise Multihoming J. Linkova M. Stucchi October 2018 ASCII HTML 21 ipv6

This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution" could be applied in those scenarios. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. The aforementioned document proposes a solution to this problem by introducing a new routing functionality (Source Address Dependent Routing) to solve the uplink selection issue. It also proposes using Router Advertisements to influence the host source address selection. It focuses on solving the general problem and covering various complex use cases, and this document adopts its proposed approach to provide a solution for a limited number of common use cases. In particular, the focus of this document is on scenarios in which an enterprise network has two Internet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC 8028.

 draft-ietf-v6ops-conditional-ras-08 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC8475 RFC8476 Signaling Maximum SID Depth (MSD) Using OSPF J. Tantsura U. Chunduri S. Aldrin P. Psenak December 2018 ASCII HTML 11 BGP-LS SID MSD OSPF

This document defines a way for an Open Shortest Path First (OSPF) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. This document only refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types. Here, the term "OSPF" means both OSPFv2 and OSPFv3.

 draft-ietf-ospf-segment-routing-msd-25 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8476 RFC8477 Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016 J. Jimenez H. Tschofenig D. Thaler October 2018 ASCII HTML 18 data model

This document provides a summary of the "Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)", which took place in Santa Clara, California March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and Standards Developing Organizations (SDOs) to accomplish interoperability at the application layer. This report summarizes the discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors or the Internet Architecture Board (IAB), which organized the workshop. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 draft-iab-iotsi-workshop-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8477 RFC8478 Zstandard Compression and the application/zstd Media Type Y. Collet M. Kucherawy Editor October 2018 ASCII HTML 54 Compression

Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism. This document describes the mechanism and registers a media type and content encoding to be used when transporting zstd-compressed content via Multipurpose Internet Mail Extensions (MIME).

Despite use of the word "standard" as part of its name, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only.

 draft-kucherawy-dispatch-zstd-03 RFC8878 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8478 10.17487/RFC8478 RFC8479 Storing Validation Parameters in PKCS#8 N. Mavrogiannopoulos September 2018 ASCII HTML 8 private keys validation parameters PKCS#8

This memo describes a method of storing parameters needed for private-key validation in the Private-Key Information Syntax Specification as defined in PKCS#8 format (RFC 5208). It is equally applicable to the alternative implementation of the Private-Key Information Syntax Specification as defined in RFC 5958.

The approach described in this document encodes the parameters under a private enterprise extension and does not form part of a formal standard.

 draft-mavrogiannopoulos-pkcs8-validated-parameters-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8479 RFC8480 6TiSCH Operation Sublayer (6top) Protocol (6P) Q. Wang Editor X. Vilajosana T. Watteyne November 2018 ASCII HTML 50 schedule management distributed scheduling time synchronized channel hopping scheduling

This document defines the "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control layer. 6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document. A 6top SF decides when to add/delete cells, and it triggers 6P Transactions. The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF.

 draft-ietf-6tisch-6top-protocol-12 PROPOSED STANDARD PROPOSED STANDARD IETF int 6tisch 10.17487/RFC8480 RFC8481 Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI) R. Bush September 2018 ASCII HTML 5 security routing

Deployment of BGP origin validation based on Resource Public Key Infrastructure (RPKI) is hampered by, among other things, vendor misimplementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those misimplementations; it thus updates RFC 6811 by clarifying that all prefixes should have their validation state set and that policy must not be applied without operator configuration.

 draft-ietf-sidrops-ov-clarify-05 RFC6811 RFC9324 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC8481 RFC8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY J. Abley O. Gudmundsson M. Majkowski E. Hunt January 2019 ASCII HTML 10 DNS ANY REFUSE DDOS ABUSE

The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.

The DNS specification does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance.

This document updates RFCs 1034 and 1035.

 draft-ietf-dnsop-refuse-any-07 RFC1034 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8482 RFC8483 Yeti DNS Testbed L. Song Editor D. Liu P. Vixie A. Kato S. Kerr October 2018 ASCII HTML 39 Root Server DNSSEC IPv6

Yeti DNS is an experimental, non-production root server testbed that provides an environment where technical and operational experiments can safely be performed without risk to production root server infrastructure. This document aims solely to document the technical and operational experience of deploying a system that is similar to but different from the Root Server system (on which the Internet's Domain Name System is designed and built).

 draft-song-yeti-testbed-experience-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8483 RFC8484 DNS Queries over HTTPS (DoH) P. Hoffman P. McManus October 2018 ASCII HTML 21 DNS HTTP DoH

This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.

 draft-ietf-doh-dns-over-https-14 PROPOSED STANDARD PROPOSED STANDARD IETF art doh http://www.rfc-editor.org/errata_search.php?rfc=8484 10.17487/RFC8484 RFC8485 Vectors of Trust J. Richer Editor L. Johansson October 2018 ASCII HTML 21

This document defines a mechanism for describing and signaling several aspects of a digital identity transaction and its participants. These aspects are used to determine the amount of trust to be placed in that transaction.

 draft-richer-vectors-of-trust-15 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8485 RFC8486 Ambisonics in an Ogg Opus Container J. Skoglund M. Graczyk October 2018 ASCII HTML 10 spatial audio lossy compression

This document defines an extension to the Opus audio codec to encapsulate coded Ambisonics using the Ogg format. It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families.

 draft-ietf-codec-ambisonics-10 RFC7845 PROPOSED STANDARD PROPOSED STANDARD IETF art codec 10.17487/RFC8486 RFC8487 Mtrace Version 2: Traceroute Facility for IP Multicast H. Asaeda K. Meyer W. Lee Editor October 2018 ASCII HTML 41 multicast mtrace mtrace2 traceroute PIM

This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a Query and receives a Reply.

 draft-ietf-mboned-mtrace-v2-26 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC8487 RFC8488 RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation O. Muravskiy T. Bruijnzeels December 2018 ASCII HTML 17 RPKI validation RRDP

This document describes an approach to validating the content of the Resource Public Key Infrastructure (RPKI) certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism, which allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol (RRDP), and repositories that use a mix of both.

 draft-ietf-sidrops-rpki-tree-validation-03 INFORMATIONAL INFORMATIONAL IETF ops sidrops 10.17487/RFC8488 RFC8489 Session Traversal Utilities for NAT (STUN) M. Petit-Huguenin G. Salgueiro J. Rosenberg D. Wing R. Mahy P. Matthews February 2020 ASCII HTML 67 SIPs

Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs and does not require any special behavior from them.

STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution.

This document obsoletes RFC 5389.

 draft-ietf-tram-stunbis-21 RFC5389 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram http://www.rfc-editor.org/errata_search.php?rfc=8489 10.17487/RFC8489 RFC8490 DNS Stateful Operations R. Bellis S. Cheshire J. Dickinson S. Dickinson T. Lemon T. Pusateri March 2019 ASCII HTML 64

This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a new DNS header OPCODE that has both different message semantics and a new result code. This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts.

 draft-ietf-dnsop-session-signal-20 RFC1035 RFC7766 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8490 RFC8491 Signaling Maximum SID Depth (MSD) Using IS-IS J. Tantsura U. Chunduri S. Aldrin L. Ginsberg November 2018 ASCII HTML 10 BGP-LS SID MSD IS-IS

This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.

 draft-ietf-isis-segment-routing-msd-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8491 RFC8492 Secure Password Ciphersuites for Transport Layer Security (TLS) D. Harkins Editor February 2019 ASCII HTML 40 Password Authenticated Key Exchange Dictionary Attack Authentication TLS

This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificateless, secure authentication using only a simple, low-entropy password. The exchange is called "TLS-PWD". The ciphersuites are all based on an authentication and key exchange protocol, named "dragonfly", that is resistant to offline dictionary attacks.

 draft-harkins-tls-dragonfly-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8492 10.17487/RFC8492 RFC8493 The BagIt File Packaging Format (V1.0) J. Kunze J. Littman E. Madden J. Scancella C. Adams October 2018 ASCII HTML 25

This document describes BagIt, a set of hierarchical file layout conventions for storage and transfer of arbitrary digital content. A "bag" has just enough structure to enclose descriptive metadata "tags" and a file "payload" but does not require knowledge of the payload's internal semantics. This BagIt format is suitable for reliable storage and transfer.

 draft-kunze-bagit-17 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8493 10.17487/RFC8493 RFC8494 Multicast Email (MULE) over Allied Communications Publication (ACP) 142 D. Wilson A. Melnikov Editor November 2018 ASCII HTML 19 P_MUL

Allied Communications Publication (ACP) 142 defines P_MUL, which is a protocol for reliable multicast suitable for bandwidth-constrained and delayed acknowledgement (Emissions Control or "EMCON") environments running over UDP. This document defines MULE (Multicast Email), an application protocol for transferring Internet Mail messages (as described in RFC 5322) over P_MUL (as defined in ACP 142). MULE enables transfer between Message Transfer Agents (MTAs). It doesn't provide a service similar to SMTP Submission (as described in RFC 6409).

This document explains how MULE can be used in conjunction with SMTP (RFC 5321), including some common SMTP extensions, to provide an alternate MTA-to-MTA transfer mechanism.

This is not an IETF specification; it describes an existing implementation. It is provided in order to facilitate interoperable implementations and third-party diagnostics.

 draft-melnikov-email-over-pmul-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8494 RFC8495 Allocation Token Extension for the Extensible Provisioning Protocol (EPP) J. Gould K. Feher November 2018 ASCII HTML 17

This document describes an Extensible Provisioning Protocol (EPP) extension for including an Allocation Token in "query" and "transform" commands. The Allocation Token is used as a credential that authorizes a client to request the allocation of a specific object from the server using one of the EPP transform commands, including "create" and "transfer".

 draft-ietf-regext-allocation-token-12 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8495 RFC8496 P-Charge-Info: A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP) D. York T. Asveren October 2018 ASCII HTML 11 p-header

This text documents the current usage of P-Charge-Info, an existing Session Initiation Protocol (SIP) private header field (P-Header) used to convey billing information about the party to be charged. This P-Header is currently used in production by several equipment vendors and carriers and has been in use since at least 2007. This document details the registration of this header field with IANA.

 draft-york-p-charge-info-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8496 RFC8497 Marking SIP Messages to Be Logged P. Dawes C. Arunachalam November 2018 ASCII HTML 46 SIP logme troubleshooting debug debugging logging

SIP networks use signaling monitoring tools to diagnose user-reported problems and to perform regression testing if network or user agent (UA) software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents and therefore impractical to monitor SIP signaling end to end.

This document describes an indicator for the SIP protocol that can be used to mark signaling as being of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and is not used in normal user agent signaling. Operators of all networks on the signaling path can agree to carry such marking end to end, including the originating and terminating SIP user agents, even if a session originates and terminates in different networks.

 draft-ietf-insipid-logme-marking-13 PROPOSED STANDARD PROPOSED STANDARD IETF art insipid 10.17487/RFC8497 RFC8498 A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP) M. Mohali February 2019 ASCII HTML 15 SIP RFC5502 P- 3GPP IMS Served-User orig-cdiv

The P-Served-User header field was defined based on a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) in order to convey the identity of the served user, his/ her registration state, and the session case that applies to that particular communication session and application invocation. A session case is metadata that captures the status of the session of a served user regardless of whether or not the served user is registered or the session originates or terminates with the served user. This document updates RFC 5502 by defining a new P-Served-User header field parameter, "orig-cdiv". The parameter conveys the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services have been invoked for the served user. This document also fixes the ABNF in RFC 5502 and provides more guidance for using the P-Served-User header field in IP networks.

 draft-ietf-sipcore-originating-cdiv-parameter-08 RFC5502 INFORMATIONAL INFORMATIONAL IETF art sipcore 10.17487/RFC8498 RFC8499 DNS Terminology P. Hoffman A. Sullivan K. Fujiwara January 2019 ASCII HTML 50 vocabulary domain name system

The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.

This document obsoletes RFC 7719 and updates RFC 2308.

 draft-ietf-dnsop-terminology-bis-14 RFC7719 RFC2308 BCP0219 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC8499 RFC8500 IS-IS Routing with Reverse Metric N. Shen S. Amante M. Abrahamsson February 2019 ASCII HTML 15 IGP IS-IS Metric Reverse-Metric IIH

This document describes a mechanism to allow IS-IS routing to quickly and accurately shift traffic away from either a point-to-point or multi-access LAN interface during network maintenance or other operational events. This is accomplished by signaling adjacent IS-IS neighbors with a higher reverse metric, i.e., the metric towards the signaling IS-IS router.

 draft-ietf-isis-reverse-metric-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8500 RFC8501 Reverse DNS in IPv6 for Internet Service Providers L. Howard November 2018 ASCII HTML 15 IPv6 PTR rDNS Reverse DNS

In IPv4, Internet Service Providers (ISPs) commonly provide IN-ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches and considerations for ISPs in managing the IP6.ARPA zone.

 draft-ietf-dnsop-isp-ip6rdns-07 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC8501 RFC8502 L2L3 VPN Multicast MIB Z. Zhang H. Tsunoda December 2018 ASCII HTML 20 MVPN BGP MPLS P-tunnel PMSI Tunnel attribute SNMP monitor management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes two MIB modules that will be used by other MIB modules for monitoring and/or configuring Layer 2 and Layer 3 Virtual Private Networks that support multicast.

 draft-ietf-bess-l2l3-vpn-mcast-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8502 RFC8503 BGP/MPLS Layer 3 VPN Multicast Management Information Base H. Tsunoda December 2018 ASCII HTML 57 MVPN PE router P-tunnel PMSI MIB SNMP monitor

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multicast communication over IP Virtual Private Networks (VPNs) supported by the Multiprotocol Label Switching/Border Gateway Protocol (MPLS/BGP) on a Provider Edge (PE) router.

 draft-ietf-bess-mvpn-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8503 RFC8504 IPv6 Node Requirements T. Chown J. Loughney T. Winters January 2019 ASCII HTML 42 IPv6 Internet Protocol Version 6 Internet Protocol IP

This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.

This document obsoletes RFC 6434, and in turn RFC 4294.

 draft-ietf-6man-rfc6434-bis-09 RFC6434 BCP0220 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int 6man 10.17487/RFC8504 RFC8505 Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery P. Thubert Editor E. Nordmark S. Chakrabarti C. Perkins November 2018 ASCII HTML 47 Wi-Fi

This specification updates RFC 6775 -- the Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the Routing Registrars performing routing for host routes and/or proxy Neighbor Discovery in a low-power network.

 draft-ietf-6lo-rfc6775-update-21 RFC6775 RFC8928 RFC8929 RFC9010 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo http://www.rfc-editor.org/errata_search.php?rfc=8505 10.17487/RFC8505 RFC8506 Diameter Credit-Control Application L. Bertz Editor D. Dolson Editor Y. Lifshitz Editor March 2019 ASCII HTML 130 Diameter charging

This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end-user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. The Diameter Credit- Control application as defined in this document obsoletes RFC 4006, and it must be supported by all new Diameter Credit-Control application implementations.

 draft-ietf-dime-rfc4006bis-12 RFC4006 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC8506 RFC8507 Simple Internet Protocol (SIP) Specification S. Deering R. Hinden Editor December 2018 ASCII HTML 26 IPv6 IPng

This document is published for the historical record. The Simple Internet Protocol was the basis for one of the candidates for the IETF's Next Generation (IPng) work that became IPv6.

The publication date of the original Internet-Draft was November 10, 1992. It is presented here substantially unchanged and is neither a complete document nor intended to be implementable.

The paragraph that follows is the Abstract from the original draft.

This document specifies a new version of IP called SIP, the Simple Internet Protocol. It also describes the changes needed to ICMP, IGMP, and transport protocols such as TCP and UDP, in order to work with SIP. A companion document [SIP-ADDR] describes the addressing and routing aspects of SIP, including issues of auto-configuration, host and subnet mobility, and multicast.

 draft-historic-simple-ip-03 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC8507 RFC8508 IMAP REPLACE Extension S. Brandt January 2019 ASCII HTML 11

This document defines an IMAP extension that can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them.

 draft-ietf-extra-imap-replace-03 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8508 RFC8509 A Root Key Trust Anchor Sentinel for DNSSEC G. Huston J. Damas W. Kumari December 2018 ASCII HTML 19 DNSSEC KSK RFC5011 DNS rollover root-key-sentinel-is-ta- root-key-sentinel-not-ta- root key security

The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key.

 draft-ietf-dnsop-kskroll-sentinel-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8509 RFC8510 OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement P. Psenak Editor K. Talaulikar W. Henderickx P. Pillay-Esnault January 2019 ASCII HTML 8 IGP OSPF

Every OSPF interface is assigned an Interface ID that uniquely identifies the interface on the router. In some cases, it is useful to know the assigned Interface ID on the remote side of the adjacency (Remote Interface ID).

This document describes the extensions to OSPF link-local signaling (LLS) to advertise the Local Interface ID.

 draft-ietf-ospf-lls-interface-id-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8510 RFC8511 TCP Alternative Backoff with ECN (ABE) N. Khademi M. Welzl G. Armitage G. Fairhurst December 2018 ASCII HTML 12

Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay product (BDP) is large. The reception of a Congestion Experienced (CE) Explicit Congestion Notification (ECN) mark indicates that an AQM mechanism is used at the bottleneck, and the bottleneck network queue is therefore likely to be short. Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss. Therefore, this specification defines an experimental change to the TCP reaction specified in RFC 3168, as permitted by RFC 8311.

 draft-ietf-tcpm-alternativebackoff-ecn-12 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC8511 RFC8512 A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT) M. Boucadair Editor S. Sivakumar C. Jacquenet S. Vinapamula Q. Wu January 2019 ASCII HTML 94 address sharing address depletion IPv4 service continuity NETCONF programmability automation service automation NPTv6 SIIT NAT64 CLAT Destination NAT Port Restricted NAT Port Range

This document defines a YANG module for the Network Address Translation (NAT) function.

Network Address Translation from IPv4 to IPv4 (NAT44), Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), customer-side translator (CLAT), Stateless IP/ICMP Translation (SIIT), Explicit Address Mappings (EAM) for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination NAT are covered in this document.

 draft-ietf-opsawg-nat-yang-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC8512 RFC8513 A YANG Data Model for Dual-Stack Lite (DS-Lite) M. Boucadair C. Jacquenet S. Sivakumar January 2019 ASCII HTML 21 IPv4 service continuity IPv4 address exhaustion Service Availability Address sharing IPv6 Reliability IPv4 over IPv6

This document defines a YANG module for the Dual-Stack Lite (DS-Lite) Address Family Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements.

 draft-ietf-softwire-dslite-yang-17 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8513 RFC8514 Internet Message Access Protocol (IMAP) - SAVEDATE Extension S. Bosch January 2019 ASCII HTML 7 imap savedate

This document adds a new capability called "SAVEDATE" to the Internet Message Access Protocol (IMAP). It defines a new IMAP message attribute called "save date" that, unlike the existing "internal date" attribute, always indicates the moment at which the message was saved in its current mailbox. The SAVEDATE capability extends the FETCH command with the means to retrieve the save date attribute and extends the SEARCH command to allow using the save date attribute in searching criteria.

 draft-ietf-extra-imap-savedate-01 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8514 RFC8515 URN Namespace for ETSI Documents M. Jethanandani M.A. Reina Ortega February 2019 ASCII HTML 7 YANG NETCONF RESTCONF

This document describes the Namespace Identifier (NID) "etsi" for Uniform Resource Names (URNs) used to identify resources published by the European Telecommunications Standards Institute (http://etsi.org). ETSI specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the ETSI Protocol Naming and Numbering Service (PNNS).

 draft-mahesh-etsi-urn-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8515 RFC8516 "Too Many Requests" Response Code for the Constrained Application Protocol A. Keranen January 2019 ASCII HTML 6 CoAP

A Constrained Application Protocol (CoAP) server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle. This document defines a new CoAP response code for a server to indicate that a client should reduce the rate of requests.

 draft-ietf-core-too-many-reqs-06 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8516 RFC8517 An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective D. Dolson Editor J. Snellman M. Boucadair Editor C. Jacquenet February 2019 ASCII HTML 21 address sharing NAT firewall Service Function transport service delivery Internet architecture TCP QUIC Path Layer UDP Substrate

This document summarizes an operator's perception of the benefits that may be provided by intermediary devices that execute functions beyond normal IP forwarding. Such intermediary devices are often called "middleboxes".

RFC 3234 defines a taxonomy of middleboxes and issues in the Internet. Most of those middleboxes utilize or modify application- layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets.

 draft-dolson-transport-middlebox-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8517 RFC8518 Selection of Loop-Free Alternates for Multi-Homed Prefixes P. Sarkar Editor U. Chunduri Editor S. Hegde J. Tantsura H. Gredler March 2019 ASCII HTML 20 LFA Multi-homed Prefix IGP

Deployment experience gained from implementing algorithms to determine Loop-Free Alternates (LFAs) for multi-homed prefixes (MHPs) has revealed some avenues for potential improvement. This document provides explicit inequalities that can be used to evaluate neighbors as potential alternates for MHPs. It also provides detailed criteria for evaluating potential alternates for external prefixes advertised by OSPF ASBRs. This document updates Section 6 of RFC 5286 by expanding some of the routing aspects.

 draft-ietf-rtgwg-multihomed-prefix-lfa-09 RFC5286 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8518 RFC8519 YANG Data Model for Network Access Control Lists (ACLs) M. Jethanandani S. Agarwal L. Huang D. Blair March 2019 ASCII HTML 60 ACE ACL Firewall PBR NMDA

This document defines a data model for Access Control Lists (ACLs). An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet.

 draft-ietf-netmod-acl-model-21 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8519 10.17487/RFC8519 RFC8520 Manufacturer Usage Description Specification E. Lear R. Droms D. Romascanu March 2019 ASCII HTML 60 MUD IoT Security Access Policy

This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.

This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.

 draft-ietf-opsawg-mud-25 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=8520 10.17487/RFC8520 RFC8521 Registration Data Access Protocol (RDAP) Object Tagging S. Hollenbeck A. Newton November 2018 ASCII HTML 13 RDAP Entity Bootstrap

The Registration Data Access Protocol (RDAP) includes a method that can be used to identify the authoritative server for processing domain name, IP address, and autonomous system number queries. The method does not describe how to identify the authoritative server for processing other RDAP query types, such as entity queries. This limitation exists because the identifiers associated with these query types are typically unstructured. This document updates RFC 7484 by describing an operational practice that can be used to add structure to RDAP identifiers and that makes it possible to identify the authoritative server for additional RDAP queries.

 draft-ietf-regext-rdap-object-tag-05 RFC7484 BCP0221 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF art regext http://www.rfc-editor.org/errata_search.php?rfc=8521 10.17487/RFC8521 RFC8522 Looking Glass Command Set M. Stubbig February 2019 ASCII HTML 20 Looking Glass

This document introduces a command set standard to the web-based "Network Looking Glass" software. Its purpose is to provide application programmers uniform access to the Looking Glass service and to analyze a standardized response.

The interface is supposed to provide the same level of information as web-based interfaces, but in a computer-readable format.

 draft-mst-lgapi-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8522 RFC8523 RFC8524 RFC8525 YANG Library A. Bierman M. Bjorklund J. Schoenwaelder K. Watsen R. Wilton March 2019 ASCII HTML 32 NMDA

This document describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. This version of the YANG library supports the Network Management Datastore Architecture (NMDA) by listing all datastores supported by a network management server and the schema that is used by each of these datastores.

 draft-ietf-netconf-rfc7895bis-07 RFC7895 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=8525 10.17487/RFC8525 RFC8526 NETCONF Extensions to Support the Network Management Datastore Architecture M. Bjorklund J. Schoenwaelder P. Shafer K. Watsen R. Wilton March 2019 ASCII HTML 23 NMDA

This document extends the Network Configuration Protocol (NETCONF) defined in RFC 6241 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

This document updates RFCs 6241 and 7950. The update to RFC 6241 adds new <get-data> and <edit-data> operations and augments existing <lock>, <unlock>, and <validate> operations. The update to RFC 7950 requires the usage of the YANG library (described in RFC 8525) by NETCONF servers implementing the NMDA.

 draft-ietf-netconf-nmda-netconf-08 RFC6241 RFC7950 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8526 RFC8527 RESTCONF Extensions to Support the Network Management Datastore Architecture M. Bjorklund J. Schoenwaelder P. Shafer K. Watsen R. Wilton March 2019 ASCII HTML 9

This document extends the RESTCONF protocol defined in RFC 8040 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

This document updates RFC 8040 by introducing new datastore resources, adding a new query parameter, and requiring the usage of the YANG library (described in RFC 8525) by RESTCONF servers implementing the NMDA.

 draft-ietf-netconf-nmda-restconf-05 RFC8040 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8527 RFC8528 YANG Schema Mount M. Bjorklund L. Lhotka March 2019 ASCII HTML 28

This document defines a mechanism that adds the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in another YANG module.

 draft-ietf-netmod-schema-mount-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8528 10.17487/RFC8528 RFC8529 YANG Data Model for Network Instances L. Berger C. Hopps A. Lindem D. Bogdanovic X. Liu March 2019 ASCII HTML 44 VRF VSI VPN

This document defines a network instance module. This module can be used to manage the virtual resource partitioning that may be present on a network device. Examples of common industry terms for virtual resource partitioning are VPN Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs).

The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

 draft-ietf-rtgwg-ni-model-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8529 RFC8530 YANG Model for Logical Network Elements L. Berger C. Hopps A. Lindem D. Bogdanovic X. Liu March 2019 ASCII HTML 49 VRF VSI VPN

This document defines a logical network element (LNE) YANG module that is compliant with the Network Management Datastore Architecture (NMDA). This module can be used to manage the logical resource partitioning that may be present on a network device. Examples of common industry terms for logical resource partitioning are logical systems or logical routers. The YANG model in this document conforms with NMDA as defined in RFC 8342.

 draft-ietf-rtgwg-lne-model-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8530 RFC8531 Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols D. Kumar Q. Wu Z. Wang April 2019 ASCII HTML 54

This document presents a base YANG data model for connection-oriented Operations, Administration, and Maintenance (OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for such protocols. The model presented here can be extended to include technology-specific details. This guarantees uniformity in the management of OAM protocols and provides support for nested OAM workflows (i.e., performing OAM functions at different levels through a unified interface).

The YANG data model in this document conforms to the Network Management Datastore Architecture.

 draft-ietf-lime-yang-connection-oriented-oam-model-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops lime http://www.rfc-editor.org/errata_search.php?rfc=8531 10.17487/RFC8531 RFC8532 Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications D. Kumar Z. Wang Q. Wu Editor R. Rahman S. Raghavan April 2019 ASCII HTML 59

This document presents a base YANG Data model for the management of Operations, Administration, and Maintenance (OAM) protocols that use connectionless communications. The data model is defined using the YANG data modeling language, as specified in RFC 7950. It provides a technology-independent abstraction of key OAM constructs for OAM protocols that use connectionless communication. The base model presented here can be extended to include technology-specific details.

There are two key benefits of this approach: First, it leads to uniformity between OAM protocols. Second, it supports both nested OAM workflows (i.e., performing OAM functions at the same level or different levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at the same level through a unified interface).

 draft-ietf-lime-yang-connectionless-oam-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops lime 10.17487/RFC8532 RFC8533 A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications D. Kumar M. Wang Q. Wu Editor R. Rahman S. Raghavan April 2019 ASCII HTML 41 CL OAM Retrieval Methods

This document presents a retrieval method YANG data model for connectionless Operations, Administration, and Maintenance (OAM) protocols. It provides technology-independent RPC operations for OAM protocols that use connectionless communication. The retrieval methods model herein presented can be extended to include technology- specific details. There are two key benefits of this approach: First, it leads to uniformity between OAM protocols. Second, it supports both nested OAM workflows (i.e., performing OAM functions at different or the same levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at the same levels through a unified interface).

 draft-ietf-lime-yang-connectionless-oam-methods-13 PROPOSED STANDARD PROPOSED STANDARD IETF ops lime 10.17487/RFC8533 RFC8534 Explicit Tracking with Wildcard Routes in Multicast VPN A. Dolganow J. Kotalwar E. Rosen Editor Z. Zhang February 2019 ASCII HTML 21 Multicast MVPN

The base Multicast VPN (MVPN) specifications (RFCs 6513 and 6514) provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit-tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFCs 6514, 6625, 7524, 7582, and 7900.

 draft-ietf-bess-mvpn-expl-track-13 RFC6514 RFC6625 RFC7524 RFC7582 RFC7900 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8534 RFC8535 RFC8536 The Time Zone Information Format (TZif) A. Olson P. Eggert K. Murchison February 2019 ASCII HTML 34 time zone tzdata tzif

This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined.

 draft-murchison-tzdist-tzif-16 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8536 10.17487/RFC8536 RFC8537 Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs) R. Gandhi Editor H. Shah J. Whittaker February 2019 ASCII HTML 16 RSVP-TE LSP

Resource Reservation Protocol (RSVP) association signaling can be used to bind two unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. When an associated bidirectional LSP is co-routed, the reverse LSP follows the same path as its forward LSP. This document updates the fast reroute procedures defined in RFC 4090 to support both single-sided and double-sided provisioned associated bidirectional LSPs. This document also updates the procedure for associating two reverse LSPs defined in RFC 7551 to support co-routed bidirectional LSPs. The fast reroute procedures can ensure that, for the co-routed LSPs, traffic flows on co-routed paths in the forward and reverse directions after a failure event.

 draft-ietf-teas-assoc-corouted-bidir-frr-07 RFC4090 RFC7551 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8537 RFC8538 Notification Message Support for BGP Graceful Restart K. Patel R. Fernando J. Scudder J. Haas March 2019 ASCII HTML 10 IDR BGP

The BGP Graceful Restart mechanism defined in RFC 4724 limits the usage of BGP Graceful Restart to BGP messages other than BGP NOTIFICATION messages. This document updates RFC 4724 by defining an extension that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION message or the Hold Time expires. This document also defines a new subcode for BGP Cease NOTIFICATION messages; this new subcode requests a full session restart instead of a Graceful Restart.

 draft-ietf-idr-bgp-gr-notification-16 RFC4724 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8538 RFC8539 Softwire Provisioning Using DHCPv4 over DHCPv6 I. Farrer Q. Sun Y. Cui L. Sun March 2019 ASCII HTML 18 Provisioning Softwire DHCP 4o6 IPv4 over IPv6 IPv4 service continuity IPv4 address depletion IPv4 over IPv6 MAP Lightweight 4over6

DHCPv4 over DHCPv6 (RFC 7341) is a mechanism for dynamically configuring IPv4 for use as an over-the-top service in an IPv6-only network. Softwires are an example of such a service. For DHCPv4 over DHCPv6 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios (e.g., RFC 7596 or RFC 7597), the operator needs to know the IPv6 address that the client will use as the source of an IPv4-in-IPv6 softwire tunnel. This address, in conjunction with the client's IPv4 address, and (in some deployments) the Port Set ID are used to create a binding table entry in the operator's softwire tunnel concentrator. This memo defines a DHCPv6 option to convey IPv6 parameters for establishing the softwire tunnel and a DHCPv4 option (to be used only with DHCP 4o6) to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It is designed to work in conjunction with the IPv4 address allocation process.

"DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients" (RFC 7598) describes a deterministic DHCPv6-based mechanism for provisioning softwires. This document updates RFC 7598, allowing OPTION_S46_BR (90) to be enumerated in the DHCPv6 client's Option Request Option (ORO) request and to appear directly within subsequent messages sent by the DHCPv6 server.

 draft-ietf-dhc-dhcp4o6-saddr-opt-08 RFC7598 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8539 RFC8540 Stream Control Transmission Protocol: Errata and Issues in RFC 4960 R. Stewart M. Tuexen M. Proshin February 2019 ASCII HTML 94

This document is a compilation of issues found since the publication of RFC 4960 in September 2007, based on experience with implementing, testing, and using the Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 4960 and is organized in a time-ordered way. The issues are listed in the order in which they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the deltas, a description of each problem and the details of the solution for each are also provided.

 draft-ietf-tsvwg-rfc4960-errata-08 RFC9260 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC8540 RFC8541 Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops S. Litkowski B. Decraene M. Horneffer March 2019 ASCII HTML 15 IS-IS OSPF

A micro-loop is a packet-forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet-forwarding paradigm.

This document analyzes the impact of using different link state IGP implementations in a single network with respect to micro-loops. The analysis is focused on the Shortest Path First (SPF) delay algorithm but also mentions the impact of SPF trigger strategies.

 draft-ietf-rtgwg-spf-uloop-pb-statement-10 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC8541 RFC8542 A YANG Data Model for Fabric Topology in Data-Center Networks Y. Zhuang D. Shi R. Gu H. Ananthakrishnan March 2019 ASCII HTML 32 YANG Fabric Topology Data-Center Networks

This document defines a YANG data model for fabric topology in data- center networks and represents one possible view of the data-center fabric. This document focuses on the data model only and does not endorse any kind of network design that could be based on the abovementioned model.

 draft-ietf-i2rs-yang-dc-fabric-network-topology-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg i2rs http://www.rfc-editor.org/errata_search.php?rfc=8542 10.17487/RFC8542 RFC8543 Extensible Provisioning Protocol (EPP) Organization Mapping L. Zhou N. Kong J. Yao J. Gould G. Zhou March 2019 ASCII HTML 43 epp registry organization object mapping

This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and management of organization objects stored in a shared central repository.

 draft-ietf-regext-org-12 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8543 RFC8544 Organization Extension for the Extensible Provisioning Protocol (EPP) L. Zhou N. Kong J. Wei J. Yao J. Gould April 2019 ASCII HTML 22 epp organization mapping extension

This document describes an extension to Extensible Provisioning Protocol (EPP) object mappings that is designed to support assigning an organization to any existing object (domain, host, contact) as well as any future objects.

 draft-ietf-regext-org-ext-11 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8544 RFC8545 Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) A. Morton Editor G. Mirsky Editor March 2019 ASCII HTML 11 OWAMP TWAMP

This memo explains the motivation and describes the reassignment of well-known ports for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) for control and measurement. It also clarifies the meaning and composition of these Standards Track protocol names for the industry.

This memo updates RFCs 4656 and 5357, in terms of the UDP well-known port assignments, and it clarifies the complete OWAMP and TWAMP protocol composition for the industry.

 draft-ietf-ippm-port-twamp-test-04 RFC4656 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC8545 RFC8546 The Wire Image of a Network Protocol B. Trammell M. Kuehlewind April 2019 ASCII HTML 10

This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol. This abstraction is intended to shed light on the implications that increased encryption has for network functions that use the wire image.

 draft-iab-wire-image-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8546 RFC8547 TCP-ENO: Encryption Negotiation Option A. Bittau D. Giffin M. Handley D. Mazieres E. Smith May 2019 ASCII HTML 31 tcp encryption

Despite growing adoption of TLS, a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors. First, some legacy protocols lack a signaling mechanism (such as a STARTTLS command) by which to convey support for encryption, thus making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded and therefore require a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption.

 draft-ietf-tcpinc-tcpeno-19 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpinc 10.17487/RFC8547 RFC8548 Cryptographic Protection of TCP Streams (tcpcrypt) A. Bittau D. Giffin M. Handley D. Mazieres Q. Slack E. Smith May 2019 ASCII HTML 32 tcp encryption

This document specifies "tcpcrypt", a TCP encryption protocol designed for use in conjunction with the TCP Encryption Negotiation Option (TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and other manipulations of the TCP header. The protocol is self-contained and specifically tailored to TCP implementations, which often reside in kernels or other environments in which large external software dependencies can be undesirable. Because the size of TCP options is limited, the protocol requires one additional one-way message latency to perform key exchange before application data can be transmitted. However, the extra latency can be avoided between two hosts that have recently established a previous tcpcrypt connection.

 draft-ietf-tcpinc-tcpcrypt-15 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpinc 10.17487/RFC8548 RFC8549 Export of BGP Community Information in IP Flow Information Export (IPFIX) Z. Li R. Gu J. Dong April 2019 ASCII HTML 18 community BGP IPFIX

By introducing new Information Elements (IEs), this document extends the existing BGP-related IEs to enable IP Flow Information Export (IPFIX) to export BGP community information, including the BGP Standard Communities defined in RFC 1997, BGP Extended Communities defined in RFC 4360, and BGP Large Communities defined in RFC 8092. According to the network operator's BGP community planning, network traffic information can then be accumulated and analyzed at the BGP community granularity, which represents the traffic of different kinds of customers, services, or geographical regions. Network traffic information at the BGP community granularity is useful for network traffic analysis and engineering.

 draft-ietf-opsawg-ipfix-bgp-community-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC8549 RFC8550 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling J. Schaad B. Ramsdell S. Turner April 2019 ASCII HTML 29 S/MIME

This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280 ("Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"). S/MIME agents must meet the certificate-processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 5750.

 draft-ietf-lamps-rfc5750-bis-08 RFC5750 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8550 RFC8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification J. Schaad B. Ramsdell S. Turner April 2019 ASCII HTML 63 S/MIME

This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751.

 draft-ietf-lamps-rfc5751-bis-11 RFC5751 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8551 RFC8552 Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves D. Crocker March 2019 ASCII HTML 15 DNS Domain Name System

Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services.

 draft-ietf-dnsop-attrleaf-16 BCP0222 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8552 10.17487/RFC8552 RFC8553 DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names D. Crocker March 2019 ASCII HTML 15 DNS Domain Name System

Using an underscore for a prefix creates a space for constrained interoperation of resource records. Original uses of an underscore character as a domain node name prefix were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace. A registry for these names has now been defined by RFC 8552. However, the existing specifications that use underscored naming need to be modified in order to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model.

 draft-ietf-dnsop-attrleaf-fix-07 RFC2782 RFC3263 RFC3529 RFC3620 RFC3832 RFC3887 RFC3958 RFC4120 RFC4227 RFC4386 RFC4387 RFC4976 RFC5026 RFC5328 RFC5389 RFC5415 RFC5518 RFC5555 RFC5617 RFC5679 RFC5766 RFC5780 RFC5804 RFC5864 RFC5928 RFC6120 RFC6186 RFC6376 RFC6733 RFC6763 RFC7208 RFC7489 RFC8145 BCP0222 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC8553 RFC8554 Leighton-Micali Hash-Based Signatures D. McGrew M. Curcio S. Fluhrer April 2019 ASCII HTML 61 LMS HSS stateful

This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer.

This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them.

 draft-mcgrew-hash-sigs-15 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8554 RFC8555 Automatic Certificate Management Environment (ACME) R. Barnes J. Hoffman-Andrews D. McCarney J. Kasten March 2019 ASCII HTML 95 certificate HTTPS PKI X.509

Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.

 draft-ietf-acme-acme-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec acme http://www.rfc-editor.org/errata_search.php?rfc=8555 10.17487/RFC8555 RFC8556 Multicast VPN Using Bit Index Explicit Replication (BIER) E. Rosen Editor M. Sivakumar T. Przygienda S. Aldrin A. Dolganow April 2019 ASCII HTML 17 Multicast

The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a service provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over a service provider's backbone network.

 draft-ietf-bier-mvpn-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bier 10.17487/RFC8556 RFC8557 Deterministic Networking Problem Statement N. Finn P. Thubert May 2019 ASCII HTML 11

This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties.

 draft-ietf-detnet-problem-statement-09 INFORMATIONAL INFORMATIONAL IETF rtg detnet 10.17487/RFC8557 RFC8558 Transport Protocol Path Signals T. Hardie Editor April 2019 ASCII HTML 10

This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.

 draft-iab-path-signals-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=8558 10.17487/RFC8558 RFC8559 Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol A. DeKok J. Korhonen April 2019 ASCII HTML 21 RADIUS Change of Authorization CoA-Request Disconnect-Request

RFC 5176 defines Change-of-Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. RFC 5176 also suggests that proxying these messages is possible, but it does not provide guidance as to how that is done. This specification updates RFC 5176 to correct that omission for scenarios where networks use realm-based proxying as defined in RFC 7542. This specification also updates RFC 5580 to allow the Operator-Name attribute in CoA-Request and Disconnect-Request packets.

 draft-ietf-radext-coa-proxy-10 RFC5176 RFC5580 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC8559 RFC8560 Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents A. Sajassi Editor S. Salam N. Del Regno J. Rabadan May 2019 ASCII HTML 16 EVPN VPLS PBB-EVPN PBB-VPLS Ethernet Virtual Private Networks Virtual Private LAN Services Provider Backbone Bridging

This document specifies mechanisms for backward compatibility of Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB-EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides mechanisms for the seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this document enables service providers to introduce EVPN/PBB-EVPN Provider Edges (PEs) in their brownfield deployments of VPLS/PBB-VPLS networks. This document specifies the control-plane and forwarding behavior needed for the auto-discovery of the following: 1) a VPN instance, 2) multicast and unicast operation, and 3) a Media Access Control (MAC) mobility operation. This enables seamless integration between EVPN and VPLS PEs as well as between PBB-VPLS and PBB-EVPN PEs.

 draft-ietf-bess-evpn-vpls-seamless-integ-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8560 RFC8561 A YANG Data Model for Microwave Radio Link J. Ahlberg M. Ye X. Li D. Spreafico M. Vaupotic June 2019 ASCII HTML 53 microwaveRadioLinkTerminal microwaveCarrierTermination

This document defines a YANG data model for control and management of radio link interfaces and their connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available for other interface types as well.

 draft-ietf-ccamp-mw-yang-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=8561 10.17487/RFC8561 RFC8562 Bidirectional Forwarding Detection (BFD) for Multipoint Networks D. Katz D. Ward S. Pallagatti Editor G. Mirsky Editor April 2019 ASCII HTML 23 BFD Multipoint BFD

This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks.

This document updates RFC 5880.

 draft-ietf-bfd-multipoint-19 RFC5880 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC8562 RFC8563 Bidirectional Forwarding Detection (BFD) Multipoint Active Tails D. Katz D. Ward S. Pallagatti Editor G. Mirsky Editor April 2019 ASCII HTML 20

This document describes active tail extensions to the Bidirectional Forwarding Detection (BFD) protocol for multipoint networks.

 draft-ietf-bfd-multipoint-active-tail-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC8563 RFC8564 Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL) M. Zhang S. Pallagatti V. Govindan April 2019 ASCII HTML 8 data center network switch multicast

Point-to-multipoint (P2MP) Bidirectional Forwarding Detection (BFD) is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in Transparent Interconnection of Lots of Links (TRILL). Similar to TRILL point-to-point BFD, BFD Control packets in TRILL P2MP BFD are transmitted using RBridge Channel messages. This document updates RFCs 7175 and 7177.

 draft-ietf-trill-p2mp-bfd-09 RFC7175 RFC7177 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8564 RFC8565 Hypertext Jeopardy Protocol (HTJP/1.0) E. Fokschaner April 1 2019 ASCII HTML 11

The Hypertext Jeopardy Protocol (HTJP) inverts the request/response semantics of the Hypertext Transfer Protocol (HTTP). Using conventional HTTP, one connects to a server, asks a question, and expects a correct answer. Using HTJP, one connects to a server, sends an answer, and expects a correct question. This document specifies the semantics of HTJP.

 draft-fokschaner-htjp-latest-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8565 RFC8566 RFC8567 Customer Management DNS Resource Records E. Rye R. Beverly April 1 2019 ASCII HTML 11

Maintaining high Quality of Experience (QoE) increasingly requires end-to-end, holistic network management, including managed Customer Premises Equipment (CPE). Because customer management is a shared global responsibility, the Domain Name System (DNS) provides an ideal existing infrastructure for maintaining authoritative customer information that must be readily, reliably, and publicly accessible.

This document describes four new DNS resource record types for encoding customer information in the DNS. These records are intended to better facilitate high customer QoE via inter-provider cooperation and management of customer data.

 draft-ietf-cust-mgmt-dns-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8567 RFC8568 Network Virtualization Research Challenges CJ. Bernardos A. Rahman JC. Zuniga LM. Contreras P. Aranda P. Lynch April 2019 ASCII HTML 42

This document describes open research challenges for network virtualization. Network virtualization is following a similar path as previously taken by cloud computing. Specifically, cloud computing popularized migration of computing functions (e.g., applications) and storage from local, dedicated, physical resources to remote virtual functions accessible through the Internet. In a similar manner, network virtualization is encouraging migration of networking functions from dedicated physical hardware nodes to a virtualized pool of resources. However, network virtualization can be considered to be a more complex problem than cloud computing as it not only involves virtualization of computing and storage functions but also involves abstraction of the network itself. This document describes current research and engineering challenges in network virtualization including the guarantee of quality of service, performance improvement, support for multiple domains, network slicing, service composition, device virtualization, privacy and security, separation of control concerns, network function placement, and testing. In addition, some proposals are made for new activities in the IETF and IRTF that could address some of these challenges. This document is a product of the Network Function Virtualization Research Group (NFVRG).

 draft-irtf-nfvrg-gaps-network-virtualization-10 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8568 RFC8569 Content-Centric Networking (CCNx) Semantics M. Mosko I. Solis C. Wood July 2019 ASCII HTML 40 Content Centric Networking

This document describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding.

The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest.

This document is a product of the Information-Centric Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification.

 draft-irtf-icnrg-ccnxsemantics-10 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC8569 RFC8570 IS-IS Traffic Engineering (TE) Metric Extensions L. Ginsberg Editor S. Previdi Editor S. Giacalone D. Ward J. Drake Q. Wu March 2019 ASCII HTML 21 IGP IS-IS

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.

This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.

Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.

This document obsoletes RFC 7810.

 draft-ietf-lsr-isis-rfc7810bis-05 RFC7810 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8570 RFC8571 BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions L. Ginsberg Editor S. Previdi Q. Wu J. Tantsura C. Filsfils March 2019 ASCII HTML 10

This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols.

 draft-ietf-idr-te-pm-bgp-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8571 RFC8572 Secure Zero Touch Provisioning (SZTP) K. Watsen I. Farrer M. Abrahamsson April 2019 ASCII HTML 87 zerotouch bootstrap sztp ztp

This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems.

 draft-ietf-netconf-zerotouch-29 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=8572 10.17487/RFC8572 RFC8573 Message Authentication Code for the Network Time Protocol A. Malhotra S. Goldberg June 2019 ASCII HTML 5 NTP

The Network Time Protocol (NTP), as described in RFC 5905, states that NTP packets should be authenticated by appending NTP data to a 128-bit key and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC as described in RFC 4493 as a replacement.

 draft-ietf-ntp-mac-06 RFC5905 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp 10.17487/RFC8573 RFC8574 cite-as: A Link Relation to Convey a Preferred URI for Referencing H. Van de Sompel M. Nelson G. Bilder J. Kunze S. Warner April 2019 ASCII HTML 17 persistent identifier PID

A web resource is routinely referenced by means of the URI with which it is directly accessed. But cases exist where referencing a resource by means of a different URI is preferred. This specification defines a link relation type that can be used to convey such a preference.

 draft-vandesompel-citeas-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8574 10.17487/RFC8574 RFC8575 YANG Data Model for the Precision Time Protocol (PTP) Y. Jiang Editor X. Liu J. Xu R. Cummings Editor May 2019 ASCII HTML 30

This document defines a YANG data model for the configuration of devices and clocks using the Precision Time Protocol (PTP) as specified in IEEE Std 1588-2008. It also defines the retrieval of the configuration information, the data sets and the running states of PTP clocks. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).

 draft-ietf-tictoc-1588v2-yang-11 PROPOSED STANDARD PROPOSED STANDARD IETF int tictoc 10.17487/RFC8575 RFC8576 Internet of Things (IoT) Security: State of the Art and Challenges O. Garcia-Morchon S. Kumar M. Sethi April 2019 ASCII HTML 50 IoT Internet of Things M2M Machine-to-machine Machine-type communication MTC Security Privacy Trustworthy Lifecycle

The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specification of the Constrained Application Protocol (CoAP) secured with Datagram Transport Layer Security (DTLS). However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities. In this document, we first discuss the various stages in the lifecycle of a thing. Next, we document the security threats to a thing and the challenges that one might face to protect against these threats. Lastly, we discuss the next steps needed to facilitate the deployment of secure IoT systems. This document can be used by implementers and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations.

This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG).

 draft-irtf-t2trg-iot-seccons-16 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8576 RFC8577 Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane H. Sitaraman V. Beeram T. Parikh T. Saad April 2019 ASCII HTML 24 Segment Routed RSVP-TE tunnels TE link labels RSVP-TE shared labels

As the scale of MPLS RSVP-TE networks has grown, the number of Label Switched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in the amount of control-plane state information.

However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane.

This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control-plane scaling on that node. It introduces the notion of preinstalled 'per-TE link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding-plane state required to support a large number of LSPs. This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing (SR) MPLS forwarding plane.

 draft-ietf-mpls-rsvp-shared-labels-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=8577 10.17487/RFC8577 RFC8578 Deterministic Networking Use Cases E. Grossman Editor May 2019 ASCII HTML 97 DetNet AVB TSN SRP

This document presents use cases for diverse industries that have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time-sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet). For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable.

 draft-ietf-detnet-use-cases-20 INFORMATIONAL INFORMATIONAL IETF rtg detnet 10.17487/RFC8578 RFC8579 Sieve Email Filtering: Delivering to Special-Use Mailboxes S. Bosch May 2019 ASCII HTML 12 sieve mailbox special-use

The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes, e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into a mailbox identified solely by a special-use attribute.

 draft-ietf-extra-sieve-special-use-05 PROPOSED STANDARD PROPOSED STANDARD IETF art extra http://www.rfc-editor.org/errata_search.php?rfc=8579 10.17487/RFC8579 RFC8580 Sieve Extension: File Carbon Copy (FCC) K. Murchison B. Gondwana May 2019 ASCII HTML 12 Sieve Vacation Notify

The Sieve email filtering language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox.

This document updates RFCs 5230 and 5435 by adding a new tagged argument to the Vacation and Notify actions, respectively.

 draft-ietf-extra-sieve-fcc-09 RFC5230 RFC5435 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8580 RFC8581 Diameter Agent Overload and the Peer Overload Report S. Donovan August 2019 ASCII HTML 19 Diameter Overload

This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC), a base solution for Diameter overload defined in RFC 7683. The extension defines the Peer Overload report type. The initial use case for the peer report is the handling of occurrences of overload of a Diameter Agent.

 draft-ietf-dime-agent-overload-11 RFC7683 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC8581 RFC8582 Diameter Overload Rate Control S. Donovan Editor E. Noel August 2019 ASCII HTML 20 Diameter Overload

This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) base solution, which is defined in RFC 7683. This extension adds a new overload-control abatement algorithm. This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sends Diameter requests to the DOIC reporting node.

 draft-ietf-dime-doic-rate-control-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC8582 RFC8583 Diameter Load Information Conveyance B. Campbell S. Donovan Editor JJ. Trottin August 2019 ASCII HTML 23 Diameter load

RFC 7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The base solution defined in RFC 7683 (Diameter Overload Information Conveyance (DOIC)) describes a mechanism meeting most of the requirements but does not currently include the ability to send load information. This document defines a mechanism for the conveying of Diameter load information.

 draft-ietf-dime-load-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC8583 RFC8584 Framework for Ethernet VPN Designated Forwarder Election Extensibility J. Rabadan Editor S. Mohanty Editor A. Sajassi J. Drake K. Nagaraj S. Sathappan April 2019 ASCII HTML 32

An alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPNs (EVPNs) is defined. The DF is the Provider Edge (PE) router responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed Customer Edge (CE) device on a given VLAN on a particular Ethernet Segment (ES). In addition, the ability to influence the DF election result for a VLAN based on the state of the associated Attachment Circuit (AC) is specified. This document clarifies the DF election Finite State Machine in EVPN services. Therefore, it updates the EVPN specification (RFC 7432).

 draft-ietf-bess-evpn-df-election-framework-09 RFC7432 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess http://www.rfc-editor.org/errata_search.php?rfc=8584 10.17487/RFC8584 RFC8585 Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service J. Palet Martinez H. M.-H. Liu M. Kawashima May 2019 ASCII HTML 21 IPv6 transition CE requirements IPv4aaS

This document specifies the IPv4 service continuity requirements for IPv6 Customer Edge (CE) routers that are provided either by the service provider or by vendors who sell through the retail market.

Specifically, this document extends the basic requirements for IPv6 CE routers as described in RFC 7084 to allow the provisioning of IPv6 transition services for the support of IPv4-as-a-Service (IPv4aaS) by means of new transition mechanisms. The document only covers IPv4aaS, i.e., transition technologies for delivering IPv4 in IPv6-only access networks. IPv4aaS is necessary because there aren't sufficient IPv4 addresses available for every possible customer/ device. However, devices or applications in the customer Local Area Networks (LANs) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services on the Internet.

 draft-ietf-v6ops-transition-ipv4aas-15 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC8585 RFC8586 Loop Detection in Content Delivery Networks (CDNs) S. Ludin M. Nottingham N. Sullivan April 2019 ASCII HTML 6 CDN-Loop,

This document defines the CDN-Loop request header field for HTTP. CDN-Loop addresses an operational need that occurs when an HTTP request is intentionally forwarded between Content Delivery Networks (CDNs), but is then accidentally or maliciously re-routed back into the original CDN causing a non-terminating loop. The new header field can be used to identify the error and terminate the loop.

 draft-ietf-httpbis-cdn-loop-02 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8586 10.17487/RFC8586 RFC8587 NFS Version 4.0 Trunking Update C. Lever Editor D. Noveck May 2019 ASCII HTML 22 NFSv4.0 migration replication trunking fs_locations transparent state migration

In NFS version 4.0, the fs_locations attribute informs clients about alternate locations of file systems. An NFS version 4.0 client can use this information to handle migration and replication of server file systems. This document describes how an NFS version 4.0 client can also use this information to discover an NFS version 4.0 server's trunking capabilities. This document updates RFC 7530.

 draft-ietf-nfsv4-mv0-trunking-update-05 RFC7530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8587 RFC8588 Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) C. Wendt M. Barnes May 2019 ASCII HTML 9

This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIP Forum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network.

 draft-ietf-stir-passport-shaken-08 PROPOSED STANDARD PROPOSED STANDARD IETF art stir http://www.rfc-editor.org/errata_search.php?rfc=8588 10.17487/RFC8588 RFC8589 The 'leaptofrogans' URI Scheme A. Tamas B. Phister Editor J-E. Rodriguez May 2019 ASCII HTML 9 Frogans leaptofrogans OP3FT URI scheme

This document describes the 'leaptofrogans' Uniform Resource Identifier (URI) scheme, which enables applications to launch Frogans Player on a given Frogans site. Frogans is a medium for publishing content and services on the Internet, defined as a generic software layer on the Internet. Frogans Player is software that enables end users to browse Frogans sites.

 draft-op3ft-leaptofrogans-uri-scheme-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8589 RFC8590 Change Poll Extension for the Extensible Provisioning Protocol (EPP) J. Gould K. Feher May 2019 ASCII HTML 20

This document describes an Extensible Provisioning Protocol (EPP) extension for notifying clients of operations on client-sponsored objects that were not initiated by the client through EPP. These operations may include contractual or policy requirements including, but not limited to, regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, court-directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the postoperation object, and optionally a preoperation object, with the operation metadata of what, when, who, and why.

 draft-ietf-regext-change-poll-12 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8590 RFC8591 SIP-Based Messaging with S/MIME B. Campbell R. Housley April 2019 ASCII HTML 39 MSRP CPIM

Mobile messaging applications used with the Session Initiation Protocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP). While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection. This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet Mail Extensions (S/MIME). It updates and provides clarifications for RFCs 3261, 3428, and 4975.

 draft-campbell-sip-messaging-smime-05 RFC3261 RFC3428 RFC4975 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8591 RFC8592 Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH) R. Browne A. Chilikin T. Mizrahi May 2019 ASCII HTML 27 Timestamp Timestamping QoS service chain

This document describes methods of carrying Key Performance Indicators (KPIs) using the Network Service Header (NSH). These methods may be used, for example, to monitor latency and QoS marking to identify problems on some links or service functions.

 draft-browne-sfc-nsh-kpi-stamp-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8592 RFC8593 Video Traffic Models for RTP Congestion Control Evaluations X. Zhu S. Mena Z. Sarker May 2019 ASCII HTML 19 Multimedia Congestion Control

This document describes two reference video traffic models for evaluating RTP congestion control algorithms. The first model statistically characterizes the behavior of a live video encoder in response to changing requests on the target video rate. The second model is trace-driven and emulates the output of actual encoded video frame sizes from a high-resolution test sequence. Both models are designed to strike a balance between simplicity, repeatability, and authenticity in modeling the interactions between a live video traffic source and the congestion control module. Finally, the document describes how both approaches can be combined into a hybrid model.

 draft-ietf-rmcat-video-traffic-model-07 INFORMATIONAL INFORMATIONAL IETF tsv rmcat 10.17487/RFC8593 RFC8594 The Sunset HTTP Header Field E. Wilde May 2019 ASCII HTML 11

This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future. It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset.

 draft-wilde-sunset-header-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8594 RFC8595 An MPLS-Based Forwarding Plane for Service Function Chaining A. Farrel S. Bryant J. Drake June 2019 ASCII HTML 32 SFC MPLS Service Function Chaining NSH Network Service Header MPLS Multiprotocol Label Switching

This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. This approach does not deprecate or replace the NSH, but it acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks.

 draft-ietf-mpls-sfc-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8595 RFC8596 MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH) A. Malis S. Bryant J. Halpern W. Henderickx June 2019 ASCII HTML 9 label label stack service function forwarder (SFF)

This document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the packet original packet/ frame. This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network, and to select one of multiple SFFs in the destination MPLS node.

 draft-ietf-mpls-sfc-encapsulation-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC8596 RFC8597 Cooperating Layered Architecture for Software-Defined Networking (CLAS) LM. Contreras CJ. Bernardos D. Lopez M. Boucadair P. Iovanna May 2019 ASCII HTML 21 SDN Control Programmability Intelligence Transport Service Flexibility Cooperation

Software-Defined Networking (SDN) advocates for the separation of the control plane from the data plane in the network nodes and its logical centralization on one or a set of control entities. Most of the network and/or service intelligence is moved to these control entities. Typically, such an entity is seen as a compendium of interacting control functions in a vertical, tightly integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that rely upon transport capabilities.

This document describes an approach called Cooperating Layered Architecture for Software-Defined Networking (CLAS), wherein the control functions associated with transport are differentiated from those related to services in such a way that they can be provided and maintained independently and can follow their own evolution path.

 draft-contreras-layered-sdn-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8597 RFC8598 Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2) T. Pauly P. Wouters May 2019 ASCII HTML 16 IKEv2 DNS

This document defines two Configuration Payload Attribute Types (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key Exchange Protocol version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split- tunnel configurations.

 draft-ietf-ipsecme-split-dns-17 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8598 RFC8599 Push Notification with the Session Initiation Protocol (SIP) C. Holmberg M. Arnold May 2019 ASCII HTML 40 SIP Push Notification

This document describes how a Push Notification Service (PNS) can be used to wake a suspended Session Initiation Protocol (SIP) User Agent (UA) with push notifications, and it also describes how the UA can send binding-refresh REGISTER requests and receive incoming SIP requests in an environment in which the UA may be suspended. The document defines new SIP URI parameters to exchange PNS information between the UA and the SIP entity that will then request that push notifications be sent to the UA. It also defines the parameters to trigger such push notification requests. The document also defines new feature-capability indicators that can be used to indicate support of this mechanism.

 draft-ietf-sipcore-sip-push-29 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore http://www.rfc-editor.org/errata_search.php?rfc=8599 10.17487/RFC8599 RFC8600 Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange N. Cam-Winget Editor S. Appala S. Pope P. Saint-Andre June 2019 ASCII HTML 28 publish subscribe pubsub grid iodef xmpp-grid information sharing

This document describes how to use the Extensible Messaging and Presence Protocol (XMPP) to collect and distribute security incident reports and other security-relevant information between network- connected devices, primarily for the purpose of communication among Computer Security Incident Response Teams and associated entities. To illustrate the principles involved, this document describes such a usage for the Incident Object Description Exchange Format (IODEF).

 draft-ietf-mile-xmpp-grid-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC8600 RFC8601 Message Header Field for Indicating Message Authentication Status M. Kucherawy May 2019 ASCII HTML 54 DKIM SPF ATPS VBR Authentication Reputation

This document specifies a message header field called "Authentication-Results" for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.

This document obsoletes RFC 7601.

 draft-ietf-dmarc-rfc7601bis-06 RFC7601 PROPOSED STANDARD PROPOSED STANDARD IETF art dmarc http://www.rfc-editor.org/errata_search.php?rfc=8601 10.17487/RFC8601 RFC8602 Update to the Telephony Routing over IP (TRIP) IANA Registry Rules regarding Postal Addresses J. Arkko T. Hardie July 2019 ASCII HTML 3

This memo updates the IANA registry rules for the Telephony Routing over IP (TRIP) protocol, by no longer requiring that postal addresses be included in contact information.

This memo updates RFC 3219.

 draft-arkko-trip-registry-update-01 RFC3219 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8602 RFC8603 Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile M. Jenkins L. Zieglar May 2019 ASCII HTML 13

This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

 draft-jenkins-cnsa-cert-crl-profile-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8603 RFC8604 Interconnecting Millions of Endpoints with Segment Routing C. Filsfils Editor S. Previdi G. Dawra Editor W. Henderickx D. Cooper June 2019 ASCII HTML 11

This document describes an application of Segment Routing to scale the network to support hundreds of thousands of network nodes, and tens of millions of physical underlay endpoints. This use case can be applied to the interconnection of massive-scale Data Centers (DCs) and/or large aggregation networks. Forwarding tables of midpoint and leaf nodes only require a few tens of thousands of entries. This may be achieved by the inherently scaleable nature of Segment Routing and the design proposed in this document.

 draft-filsfils-spring-large-scale-interconnect-13 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8604 RFC8605 vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP) S. Hollenbeck R. Carney May 2019 ASCII HTML 7 RDAP vCard

This document defines extensions to the vCard data format for representing and exchanging contact information used to implement the Internet Corporation for Assigned Names and Numbers (ICANN) operational profile for the Registration Data Access Protocol (RDAP). The property and parameter defined here are used to add values to RDAP responses that are consistent with ICANN policies.

 draft-hollenbeck-vcarddav-icann-rdap-extensions-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8605 RFC8606 ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field R. Jesske June 2019 ASCII HTML 7 Reason Call Location

The SIP Reason header field is defined to carry ISUP (ISDN User Part) cause values as well as SIP response codes. Some services in SIP networks may need to know the ISUP location where the call was released in the PSTN (Public Switched Telephone Network) to correctly interpret the reason of release. This document updates RFC 3326 by adding a location parameter for this purpose.

 draft-ietf-sipcore-reason-q850-loc-07 RFC3326 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8606 RFC8607 Calendaring Extensions to WebDAV (CalDAV): Managed Attachments C. Daboo A. Quillaud K. Murchison Editor June 2019 ASCII HTML 34 CalDAV calendaring attachment ATTACH

This specification adds an extension to the Calendaring Extensions to WebDAV (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server.

This specification documents existing code deployed by multiple vendors. It is published as an Informational specification rather than Standards Track due to its noncompliance with multiple best current practices of HTTP.

 draft-ietf-calext-caldav-attachments-04 INFORMATIONAL INFORMATIONAL IETF art calext 10.17487/RFC8607 RFC8608 BGPsec Algorithms, Key Formats, and Signature Formats S. Turner O. Borchert June 2019 ASCII HTML 21 BGPsec BGPsec Algorithms Crypto Algorithms ECDSA Cryptography

This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") and obsoletes RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Documentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithms IDs to fill the complete range, and restructuring the document for better reading.

This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures.

 draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-05 RFC8208 RFC7935 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC8608 RFC8609 Content-Centric Networking (CCNx) Messages in TLV Format M. Mosko I. Solis C. Wood July 2019 ASCII HTML 46

Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.

This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification.

 draft-irtf-icnrg-ccnxmessages-09 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC8609 RFC8610 Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures H. Birkholz C. Vigano C. Bormann June 2019 ASCII HTML 64 binary format data interchange format description language schema language tree grammar

This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.

 draft-ietf-cbor-cddl-08 PROPOSED STANDARD PROPOSED STANDARD IETF art cbor http://www.rfc-editor.org/errata_search.php?rfc=8610 10.17487/RFC8610 RFC8611 Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces N. Akiya G. Swallow S. Litkowski B. Decraene J. Drake M. Chen June 2019 ASCII HTML 29 MPLS LSP Ping

This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable the determination of the capabilities supported by a Label Switching Router (LSR).

This document updates RFC 8029.

 draft-ietf-mpls-lsp-ping-lag-multipath-08 RFC8029 RFC9041 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8611 RFC8612 DDoS Open Threat Signaling (DOTS) Requirements A. Mortensen T. Reddy R. Moskowitz May 2019 ASCII HTML 22

This document defines the requirements for the Distributed Denial-of- Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.

 draft-ietf-dots-requirements-22 INFORMATIONAL INFORMATIONAL IETF sec dots 10.17487/RFC8612 RFC8613 Object Security for Constrained RESTful Environments (OSCORE) G. Selander J. Mattsson F. Palombini L. Seitz July 2019 ASCII HTML 94

This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.

Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.

 draft-ietf-core-object-security-16 RFC7252 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8613 RFC8614 Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS) R. Singh K. Kompella S. Palislamovic June 2019 ASCII HTML 9

This document updates the meaning of the Control Flags field in the "Layer2 Info Extended Community" used for BGP Virtual Private LAN Service (VPLS) Network Layer Reachability Information (NLRI) as defined in RFC 4761. This document updates RFC 4761.

 draft-ietf-bess-bgp-vpls-control-flags-08 RFC4761 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8614 RFC8615 Well-Known Uniform Resource Identifiers (URIs) M. Nottingham May 2019 ASCII HTML 12

This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.

In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.

 draft-nottingham-rfc5785bis-11 RFC5785 RFC7230 RFC7595 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8615 RFC8616 Email Authentication for Internationalized Mail J. Levine June 2019 ASCII HTML 6 email internationalization

Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail (DKIM) (RFC 6376), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner to publish email authentication and policy information in the DNS. In internationalized email, domain names can occur both as U-labels and A-labels. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications.

 draft-ietf-dmarc-eaiauth-06 RFC6376 RFC7208 RFC7489 PROPOSED STANDARD PROPOSED STANDARD IETF art dmarc 10.17487/RFC8616 RFC8617 The Authenticated Received Chain (ARC) Protocol K. Andersen B. Long Editor S. Blank Editor M. Kucherawy Editor July 2019 ASCII HTML 35 DKIM DMARC signature email domian authentication email authentication

The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling.

ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths.

ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries.

 draft-ietf-dmarc-arc-protocol-23 EXPERIMENTAL EXPERIMENTAL IETF art dmarc 10.17487/RFC8617 RFC8618 Compacted-DNS (C-DNS): A Format for DNS Packet Capture J. Dickinson J. Hague S. Dickinson T. Manderson J. Bond September 2019 ASCII HTML 79 DNS

This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata. It is intended to assist with the development of DNS traffic- monitoring applications.

 draft-ietf-dnsop-dns-capture-format-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8618 RFC8619 Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) R. Housley June 2019 ASCII HTML 6 HKDF Algorithm Identifier

RFC 5869 specifies the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm. This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions.

 draft-housley-hkdf-oids-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8619 RFC8620 The JSON Meta Application Protocol (JMAP) N. Jenkins C. Newman July 2019 ASCII HTML 90 JMAP JSON

This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download.

 draft-ietf-jmap-core-17 PROPOSED STANDARD PROPOSED STANDARD IETF art jmap http://www.rfc-editor.org/errata_search.php?rfc=8620 10.17487/RFC8620 RFC8621 The JSON Meta Application Protocol (JMAP) for Mail N. Jenkins C. Newman August 2019 ASCII HTML 108 JMAP JSON email

This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP). Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client.

 draft-ietf-jmap-mail-16 RFC5788 PROPOSED STANDARD PROPOSED STANDARD IETF art jmap 10.17487/RFC8621 RFC8622 A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services R. Bless June 2019 ASCII HTML 18 Lower Effort Per-Hop Behavior Scavenger Service

This document specifies properties and characteristics of a Lower- Effort Per-Hop Behavior (LE PHB). The primary objective of this LE PHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LE PHB.

This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification.

 draft-ietf-tsvwg-le-phb-10 RFC3662 RFC4594 RFC8325 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8622 RFC8623 Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs) U. Palle D. Dhody Y. Tanaka V. Beeram June 2019 ASCII HTML 33

The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document provides extensions required for the Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs.

 draft-ietf-pce-stateful-pce-p2mp-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8623 RFC8624 Algorithm Implementation Requirements and Usage Guidance for DNSSEC P. Wouters O. Sury June 2019 ASCII HTML 11

The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes RFC 6944.

 draft-ietf-dnsop-algorithm-update-10 RFC6944 RFC9157 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8624 10.17487/RFC8624 RFC8625 Ethernet Traffic Parameters with Availability Information H. Long M. Ye Editor G. Mirsky Editor A. D'Alessandro H. Shah August 2019 ASCII HTML 13 GMPLS RSVP-TE microwave variable bandwidth link

A packet-switching network may contain links with variable bandwidths (e.g., copper and radio). The bandwidth of such links is sensitive to the external environment (e.g., climate). Availability is typically used to describe these links when doing network planning. This document introduces an optional Bandwidth Availability TLV in RSVP-TE signaling. This extension can be used to set up a GMPLS Label Switched Path (LSP) in conjunction with the Ethernet SENDER_TSPEC object.

 draft-ietf-ccamp-rsvp-te-bandwidth-availability-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC8625 RFC8626 RFC8627 RTP Payload Format for Flexible Forward Error Correction (FEC) M. Zanaty V. Singh A. Begen G. Mandyam July 2019 ASCII HTML 41 FEC forward error correction

This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from source media encapsulated in RTP. These parity codes are systematic codes (Flexible FEC, or "FLEX FEC"), where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams. These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that carries the source packets. RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received. The non-interleaved and interleaved parity codes that are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of complexity. The RTP payload formats that are defined in this document address scalability issues experienced with the earlier specifications and offer several improvements. Due to these changes, the new payload formats are not backward compatible with earlier specifications; however, endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets.

 draft-ietf-payload-flexible-fec-scheme-20 PROPOSED STANDARD PROPOSED STANDARD IETF art payload http://www.rfc-editor.org/errata_search.php?rfc=8627 10.17487/RFC8627 RFC8628 OAuth 2.0 Device Authorization Grant W. Denniss J. Bradley M. Jones H. Tschofenig August 2019 ASCII HTML 21 Security Area OAuth Security Authorization Smart Objects IoT Internet of Things Internet of Things Security OAuth for Constrained Devices OAuth IoT Security

The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.

 draft-ietf-oauth-device-flow-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=8628 10.17487/RFC8628 RFC8629 Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension B. Cheng L. Berger Editor July 2019 ASCII HTML 10

This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables the reporting and control of multi-hop forwarding by DLEP-capable modems.

 draft-ietf-manet-dlep-multi-hop-extension-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8629 RFC8630 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator G. Huston S. Weiler G. Michaelson S. Kent T. Bruijnzeels August 2019 ASCII HTML 11

This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). The TAL allows Relying Parties in the RPKI to download the current Trust Anchor (TA) Certification Authority (CA) certificate from one or more locations and verify that the key of this self-signed certificate matches the key on the TAL. Thus, Relying Parties can be configured with TA keys but can allow these TAs to change the content of their CA certificate. In particular, it allows TAs to change the set of IP Address Delegations and/or Autonomous System Identifier Delegations included in the extension(s) (RFC 3779) of their certificate.

This document obsoletes the previous definition of the TAL as provided in RFC 7730 by adding support for Uniform Resource Identifiers (URIs) (RFC 3986) that use HTTP over TLS (HTTPS) (RFC 7230) as the scheme.

 draft-ietf-sidrops-https-tal-08 RFC7730 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC8630 RFC8631 Link Relation Types for Web Services E. Wilde July 2019 ASCII HTML 10 API Documentation Description Metadata Status

Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web services" or "Web APIs". This specification defines link relations that represent relationships from Web services or APIs to resources that provide documentation, descriptions, metadata, or status information for these resources. Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers. Metadata provides information about a service's context. This specification also defines a link relation to identify status resources that are used to represent information about service status.

 draft-wilde-service-link-rel-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8631 RFC8632 A YANG Data Model for Alarm Management S. Vallin M. Bjorklund September 2019 ASCII HTML 82 Monitoring Fault Management

This document defines a YANG module for alarm management. It includes functions for alarm-list management, alarm shelving, and notifications to inform management systems. There are also operations to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards.

 draft-ietf-ccamp-alarm-module-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=8632 10.17487/RFC8632 RFC8633 Network Time Protocol Best Current Practices D. Reilly H. Stenn D. Sibold July 2019 ASCII HTML 26 NTP

The Network Time Protocol (NTP) is one of the oldest protocols on the Internet and has been widely used since its initial publication. This document is a collection of best practices for the general operation of NTP servers and clients on the Internet. It includes recommendations for the stable, accurate, and secure operation of NTP infrastructure. This document is targeted at NTP version 4 as described in RFC 5905.

 draft-ietf-ntp-bcp-13 BCP0223 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int ntp 10.17487/RFC8633 RFC8634 BGPsec Router Certificate Rollover B. Weis R. Gagliano K. Patel August 2019 ASCII HTML 11

Certification Authorities (CAs) within the Resource Public Key Infrastructure (RPKI) manage BGPsec router certificates as well as RPKI certificates. The rollover of BGPsec router certificates must be carefully performed in order to synchronize the distribution of router public keys with BGPsec UPDATE messages verified with those router public keys. This document describes a safe rollover process, and it discusses when and why the rollover of BGPsec router certificates is necessary. When this rollover process is followed, the rollover will be performed without routing information being lost.

 draft-ietf-sidrops-bgpsec-rollover-04 BCP0224 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops sidrops 10.17487/RFC8634 RFC8635 Router Keying for BGPsec R. Bush S. Turner K. Patel August 2019 ASCII HTML 21

BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the Global Resource Public Key Infrastructure (RPKI), enabling verification of BGPsec messages. This document describes two methods of generating the public-private key pairs: router-driven and operator-driven.

 draft-ietf-sidrops-rtr-keying-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC8635 RFC8636 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility L. Hornquist Astrand L. Zhu M. Cullen G. Hudson July 2019 ASCII HTML 21

This document updates the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) standard (RFC 4556) to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable.

These changes provide preemptive protection against vulnerabilities discovered in the future in any specific cryptographic algorithm and allow incremental deployment of newer algorithms.

 draft-ietf-kitten-pkinit-alg-agility-08 RFC4556 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8636 RFC8637 Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN) D. Dhody Y. Lee D. Ceccarelli July 2019 ASCII HTML 22 PCE ACTN

Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control, and manage large-scale multidomain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service-aware connectivity and network function virtualization services.

The Path Computation Element (PCE) is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. The PCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path Computation Element Communication Protocol (PCEP).

This document examines the applicability of PCE to the ACTN framework.

 draft-ietf-pce-applicability-actn-12 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC8637 RFC8638 IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks M. Xu Y. Cui J. Wu S. Yang C. Metz September 2019 ASCII HTML 19 Multicast Mesh SSM ASM

During the transition to IPv6, there are scenarios where a backbone network internally running one IP address family (referred to as the internal IP or I-IP family) connects client networks running another IP address family (referred to as the external IP or E-IP family). In such cases, the I-IP backbone needs to offer both unicast and multicast transit services to the client E-IP networks.

This document describes a mechanism for supporting multicast across backbone networks where the I-IP and E-IP protocol families differ. The document focuses on the IPv4-over-IPv6 scenario, due to lack of real-world use cases for the IPv6-over-IPv4 scenario.

 draft-ietf-softwire-mesh-multicast-25 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8638 RFC8639 Subscription to YANG Notifications E. Voit A. Clemm A. Gonzalez Prieto E. Nilsen-Nygaard A. Tripathy September 2019 ASCII HTML 77 telemetry YANG-Push

This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information.

 draft-ietf-netconf-subscribed-notifications-26 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=8639 10.17487/RFC8639 RFC8640 Dynamic Subscription to YANG Events and Datastores over NETCONF E. Voit A. Clemm A. Gonzalez Prieto E. Nilsen-Nygaard A. Tripathy September 2019 ASCII HTML 19 telemetry

This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.

 draft-ietf-netconf-netconf-event-notifications-22 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=8640 10.17487/RFC8640 RFC8641 Subscription to YANG Notifications for Datastore Updates A. Clemm E. Voit September 2019 ASCII HTML 58 YANG-Push Streaming telemetry

This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state.

 draft-ietf-netconf-yang-push-25 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8641 RFC8642 Policy Behavior for Well-Known BGP Communities J. Borkenhagen R. Bush R. Bonica S. Bayraktar August 2019 ASCII HTML 7 Operations Inter-Provider Communication

Well-known BGP communities are manipulated differently across various current implementations, resulting in difficulties for operators. Network operators should deploy consistent community handling across their networks while taking the inconsistent behaviors from the various BGP implementations into consideration. This document recommends specific actions to limit future inconsistency: namely, BGP implementors must not create further inconsistencies from this point forward. These behavioral changes, though subtle, actually update RFC 1997.

 draft-ietf-grow-wkc-behavior-08 RFC1997 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC8642 RFC8643 An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP) A. Johnston B. Aboba A. Hutton R. Jesske T. Stach August 2019 ASCII HTML 8 srtp opportunistic security encryption best effort osrtp

Opportunistic Secure Real-time Transport Protocol (OSRTP) is an implementation of the Opportunistic Security mechanism, as defined in RFC 7435, applied to the Real-time Transport Protocol (RTP). OSRTP allows encrypted media to be used in environments where support for encryption is not known in advance and is not required. OSRTP does not require Session Description Protocol (SDP) extensions or features and is fully backwards compatible with existing implementations using encrypted and authenticated media and implementations that do not encrypt or authenticate media packets. OSRTP is not specific to any key management technique for Secure RTP (SRTP). OSRTP is a transitional approach useful for migrating existing deployments of real-time communications to a fully encrypted and authenticated state.

 draft-ietf-sipbrandy-osrtp-10 INFORMATIONAL INFORMATIONAL IETF art sipbrandy 10.17487/RFC8643 RFC8644 RFC8645 Re-keying Mechanisms for Symmetric Keys S. Smyshlyaev Editor August 2019 ASCII HTML 69 re-keying key key lifetime encryption mode mode of operation

A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called the "key lifetime". This specification describes a variety of methods for increasing the lifetime of symmetric keys. It provides two types of re-keying mechanisms based on hash functions and block ciphers that can be used with modes of operations such as CTR, GCM, CBC, CFB, and OMAC.

This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

 draft-irtf-cfrg-re-keying-17 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8645 RFC8646 RFC8647 RFC8648 RFC8649 Hash Of Root Key Certificate Extension R. Housley August 2019 ASCII HTML 10 trust anchor

This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one.

 draft-ietf-lamps-hash-of-root-key-cert-extn-07 INFORMATIONAL INFORMATIONAL IETF sec lamps 10.17487/RFC8649 RFC8650 Dynamic Subscription to YANG Events and Datastores over RESTCONF E. Voit R. Rahman E. Nilsen-Nygaard A. Clemm A. Bierman November 2019 HTML TEXT PDF XML 23 YANG-Push

This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.

 draft-ietf-netconf-restconf-notif-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=8650 10.17487/RFC8650 RFC8651 Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension B. Cheng D. Wiggins L. Berger Editor October 2019 HTML TEXT PDF XML 12 DLEP Flow control Pause

This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router.

 draft-ietf-manet-dlep-pause-extension-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8651 RFC8652 A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) X. Liu F. Guo M. Sivakumar P. McAllister A. Peter November 2019 HTML TEXT PDF XML 45 YANG IGMP MLD multicast data model ietf-igmp-mld network management routing

This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) devices.

 draft-ietf-pim-igmp-mld-yang-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC8652 RFC8653 On-Demand Mobility Management A. Yegin D. Moses S. Jeon October 2019 HTML TEXT PDF XML 12

Applications differ with respect to whether they need session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies, as described in RFC 7333. This document defines a new concept of enabling applications to influence the network's mobility services (session continuity and/or IP address reachability) on a per-socket basis, and suggests extensions to the networking stack's API to accommodate this concept.

 draft-ietf-dmm-ondemand-mobility-18 INFORMATIONAL INFORMATIONAL IETF int dmm 10.17487/RFC8653 RFC8654 Extended Message Support for BGP R. Bush K. Patel D. Ward October 2019 HTML TEXT PDF XML 7 border gateway protocol address family identifiers afi

The BGP specification (RFC 4271) mandates a maximum BGP message size of 4,096 octets. As BGP is extended to support new Address Family Identifiers (AFIs), Subsequent AFIs (SAFIs), and other features, there is a need to extend the maximum message size beyond 4,096 octets. This document updates the BGP specification by extending the maximum message size from 4,096 octets to 65,535 octets for all messages except for OPEN and KEEPALIVE messages.

 draft-ietf-idr-bgp-extended-messages-36 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8654 RFC8655 Deterministic Networking Architecture N. Finn P. Thubert B. Varga J. Farkas October 2019 HTML TEXT PDF XML 38 TSN Bounded Latency Reliable Networking Available Networking

This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.

 draft-ietf-detnet-architecture-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg detnet 10.17487/RFC8655 RFC8656 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) T. Reddy Editor A. Johnston Editor P. Matthews J. Rosenberg February 2020 HTML TEXT PDF XML 79 NAT TURN STUN ICE

If a host is located behind a NAT, it can be impossible for that host to communicate directly with other hosts (peers) in certain situations. In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called "Traversal Using Relays around NAT" (TURN), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.

The TURN protocol was designed to be used as part of the Interactive Connectivity Establishment (ICE) approach to NAT traversal, though it can also be used without ICE.

This document obsoletes RFCs 5766 and 6156.

 draft-ietf-tram-turnbis-29 RFC5766 RFC6156 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC8656 RFC8657 Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding H. Landau November 2019 HTML TEXT PDF XML 11

The Certification Authority Authorization (CAA) DNS record allows a domain to communicate an issuance policy to Certification Authorities (CAs) but only allows a domain to define a policy with CA-level granularity. However, the CAA specification (RFC 8659) also provides facilities for an extension to admit a more granular, CA-specific policy. This specification defines two such parameters: one allowing specific accounts of a CA to be identified by URIs and one allowing specific methods of domain control validation as defined by the Automatic Certificate Management Environment (ACME) protocol to be required.

 draft-ietf-acme-caa-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec acme 10.17487/RFC8657 RFC8658 RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P) S. Jiang Editor Y. Fu Editor C. Xie T. Li M. Boucadair Editor November 2019 HTML TEXT PDF XML 34 IPv6 Transition MAP-E MAP-T Lightweight 4over6 RADIUS address sharing authorization AAA provisioning

IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity services over IPv6 native networks during the IPv4/IPv6 coexistence period. DHCPv6 options have been defined to configure clients for Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), Mapping of Address and Port using Translation (MAP-T) unicast softwire mechanisms, and multicast softwires. However, in many networks, configuration information is stored in an Authentication, Authorization, and Accounting (AAA) server, which utilizes the Remote Authentication Dial In User Service (RADIUS) protocol to provide centralized management for users. When a new transition mechanism is developed, new RADIUS attributes need to be defined correspondingly.

This document defines new RADIUS attributes to carry softwire configuration parameters based on Address plus Port from a AAA server to a Broadband Network Gateway. Both unicast and multicast attributes are covered.

 draft-ietf-softwire-map-radius-26 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8658 RFC8659 DNS Certification Authority Authorization (CAA) Resource Record P. Hallam-Baker R. Stradling J. Hoffman-Andrews November 2019 HTML TEXT PDF XML 17 certificate ca pki issue issuance wildcard

The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by CAs.

This document obsoletes RFC 6844.

 draft-ietf-lamps-rfc6844bis-07 RFC6844 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps http://www.rfc-editor.org/errata_search.php?rfc=8659 10.17487/RFC8659 RFC8660 Segment Routing with the MPLS Data Plane A. Bashandy Editor C. Filsfils Editor S. Previdi B. Decraene S. Litkowski R. Shakir December 2019 HTML TEXT PDF XML 29 SR SR-MPLS

Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).

 draft-ietf-spring-segment-routing-mpls-22 PROPOSED STANDARD PROPOSED STANDARD IETF rtg spring 10.17487/RFC8660 RFC8661 Segment Routing MPLS Interworking with LDP A. Bashandy Editor C. Filsfils Editor S. Previdi B. Decraene S. Litkowski December 2019 HTML TEXT PDF XML 21 SR-MPLS

A Segment Routing (SR) node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows enforcing a flow through any topological path while maintaining per-flow state only at the ingress node to the SR domain.

The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This document describes how Segment Routing MPLS operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist.

 draft-ietf-spring-segment-routing-ldp-interop-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg spring 10.17487/RFC8661 RFC8662 Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels S. Kini K. Kompella S. Sivabalan S. Litkowski R. Shakir J. Tantsura December 2019 HTML TEXT PDF XML 22 Flow-aware load balancing ECMP (equal-cost multipath)

Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions, called segments. Segment Routing can be applied to the Multiprotocol Label Switching (MPLS) data plane. Entropy labels (ELs) are used in MPLS to improve load-balancing. This document examines and describes how ELs are to be applied to Segment Routing MPLS.

 draft-ietf-mpls-spring-entropy-label-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8662 RFC8663 MPLS Segment Routing over IP X. Xu S. Bryant A. Farrel S. Hassan W. Henderickx Z. Li December 2019 HTML TEXT PDF XML 17 SR-MPLS MPLS-in-UDP

MPLS Segment Routing (SR-MPLS) is a method of source routing a packet through an MPLS data plane by imposing a stack of MPLS labels on the packet to specify the path together with any packet-specific instructions to be executed on it. SR-MPLS can be leveraged to realize a source-routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source-routing instruction set while making no changes to SR-MPLS specifications and interworking with SR-MPLS implementations.

This document describes how SR-MPLS-capable routers and IP-only routers can seamlessly coexist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-over-UDP as defined in RFC 7510.

 draft-ietf-mpls-sr-over-ip-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8663 RFC8664 Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing S. Sivabalan C. Filsfils J. Tantsura W. Henderickx J. Hardwick December 2019 HTML TEXT PDF XML 29 SR Traffic-Engineering PCE

Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.

This document updates RFC 8408.

 draft-ietf-pce-segment-routing-16 RFC8408 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8664 10.17487/RFC8664 RFC8665 OSPF Extensions for Segment Routing P. Psenak Editor S. Previdi Editor C. Filsfils H. Gredler R. Shakir W. Henderickx J. Tantsura December 2019 HTML TEXT PDF XML 25 MPLS SID IGP OSPF Label advertisement Segment Routing

Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).

This document describes the OSPFv2 extensions required for Segment Routing.

 draft-ietf-ospf-segment-routing-extensions-27 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=8665 10.17487/RFC8665 RFC8666 OSPFv3 Extensions for Segment Routing P. Psenak Editor S. Previdi Editor December 2019 HTML TEXT PDF XML 18 MPLS SID IGP OSPF Label advertisement Segment Routing

Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).

This document describes the OSPFv3 extensions required for Segment Routing with the MPLS data plane.

 draft-ietf-ospf-ospfv3-segment-routing-extensions-23 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8666 RFC8667 IS-IS Extensions for Segment Routing S. Previdi Editor L. Ginsberg Editor C. Filsfils A. Bashandy H. Gredler B. Decraene December 2019 HTML TEXT PDF XML 28 MPLS SID IGP IS-IS Label advertisement Segment Routing

Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).

This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane.

 draft-ietf-isis-segment-routing-extensions-25 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8667 RFC8668 Advertising Layer 2 Bundle Member Link Attributes in IS-IS L. Ginsberg Editor A. Bashandy C. Filsfils M. Nanduri E. Aries December 2019 HTML TEXT PDF XML 17

There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links that comprise the Layer 2 interface bundle, link attribute information about the bundle members is required.

This document introduces the ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle Members.

 draft-ietf-isis-l2bundles-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=8668 10.17487/RFC8668 RFC8669 Segment Routing Prefix Segment Identifier Extensions for BGP S. Previdi C. Filsfils A. Lindem Editor A. Sreekantiah H. Gredler December 2019 HTML TEXT PDF XML 15 SR MPLS BGP Prefix-SID Label-Index SRGB

Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions called "segments". A segment can represent any instruction, topological or service based. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SIDs). Each SID represents a topological or service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. An "SR domain" is defined as a single administrative domain for global SID assignment.

This document defines an optional, transitive BGP attribute for announcing information about BGP Prefix Segment Identifiers (BGP Prefix-SIDs) and the specification for SR-MPLS SIDs.

 draft-ietf-idr-bgp-prefix-sid-27 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=8669 10.17487/RFC8669 RFC8670 BGP Prefix Segment in Large-Scale Data Centers C. Filsfils Editor S. Previdi G. Dawra E. Aries P. Lapukhov December 2019 HTML TEXT PDF XML 18 SR MSDC DC SRGB

This document describes the motivation for, and benefits of, applying Segment Routing (SR) in BGP-based large-scale data centers. It describes the design to deploy SR in those data centers for both the MPLS and IPv6 data planes.

 draft-ietf-spring-segment-routing-msdc-11 INFORMATIONAL INFORMATIONAL IETF rtg spring 10.17487/RFC8670 RFC8671 Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP) T. Evens S. Bayraktar P. Lucente P. Mi S. Zhuang November 2019 HTML TEXT PDF XML 9 adj-rib-out

The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Adj-RIB-Out RIBs. It also adds a new flag to the peer header to distinguish between Adj-RIB-In and Adj-RIB-Out.

 draft-ietf-grow-bmp-adj-rib-out-07 RFC7854 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC8671 RFC8672 TLS Server Identity Pinning with Tickets Y. Sheffer D. Migault October 2019 HTML TEXT PDF XML 22 transport layer security

Misissued public-key certificates can prevent TLS clients from appropriately authenticating the TLS server. Several alternatives have been proposed to detect this situation and prevent a client from establishing a TLS session with a TLS end point authenticated with an illegitimate public-key certificate. These mechanisms are either not widely deployed or limited to public web browsing.

This document proposes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity. During an initial TLS session, the server provides an original encrypted pinning ticket. In subsequent TLS session establishment, upon receipt of the pinning ticket, the server proves its ability to decrypt the pinning ticket and thus the ownership of the pinning protection key. The client can now safely conclude that the TLS session is established with the same TLS server as the original TLS session. One of the important properties of this proposal is that no manual management actions are required.

 draft-sheffer-tls-pinning-ticket-12 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC8672 RFC8673 HTTP Random Access and Live Content C. Pratt D. Thakore B. Stark November 2019 HTML TEXT PDF XML 10 http range unit live aggregation

To accommodate byte-range requests for content that has data appended over time, this document defines semantics that allow an HTTP client and a server to perform byte-range GET and HEAD requests that start at an arbitrary byte offset within the representation and end at an indeterminate offset.

 draft-ietf-httpbis-rand-access-live-04 EXPERIMENTAL EXPERIMENTAL IETF art httpbis 10.17487/RFC8673 RFC8674 The "safe" HTTP Preference M. Nottingham December 2019 HTML TEXT PDF XML 7 safe preference child-protection

This specification defines a preference for HTTP requests that expresses a desire to avoid objectionable content, according to the definition of that term by the origin server.

This specification does not define a precise semantic for "safe". Rather, the term is interpreted by the server and within the scope of each web site that chooses to act upon this information.

Support for this preference by clients and servers is optional.

 draft-nottingham-safe-hint-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8674 RFC8675 A YANG Data Model for Tunnel Interface Types M. Boucadair I. Farrer R. Asati November 2019 HTML TEXT PDF XML 16 softwire Augment tunnel tunnel management tunnel provisioning tunnel activation tunnel automation

This document specifies the initial version of a YANG module "iana-tunnel-type", which contains a collection of IANA-maintained YANG identities used as interface types for tunnel interfaces. The module reflects the "tunnelType" registry maintained by IANA. The latest revision of this YANG module can be obtained from the IANA website.

Tunnel type values are not directly added to the Tunnel Interface Types YANG module; they must instead be added to the "tunnelType" IANA registry. Once a new tunnel type registration is made by IANA for a new tunneling scheme or even an existing one that is not already listed in the current registry (e.g., LISP, NSH), IANA will update the Tunnel Interface Types YANG module accordingly.

Some of the IETF-defined tunneling techniques are not listed in the current IANA registry. It is not the intent of this document to update the existing IANA registry with a comprehensive list of tunnel technologies. Registrants must follow the IETF registration procedure for interface types whenever a new tunnel type is needed.

 draft-ietf-softwire-iftunnel-07 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8675 RFC8676 YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires I. Farrer Editor M. Boucadair Editor November 2019 HTML TEXT PDF XML 46 A+P address sharing port set Port range IPv4 service continuity NETCONF RESTCONF Programmability Dynamic provisioning automation IPv6

This document defines YANG modules for the configuration and operation of IPv4-in-IPv6 softwire Border Relays and Customer Premises Equipment for the Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), and Mapping of Address and Port using Translation (MAP-T) softwire mechanisms.

 draft-ietf-softwire-yang-16 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8676 RFC8677 Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework D. Trossen D. Purkayastha A. Rahman November 2019 HTML TEXT PDF XML 24 service function SF SFF nSFF SFC SFP NSH FQDN 5G NSSAI CCNF NSSF 3GPP

Adoption of cloud and fog technology allows operators to deploy a single "Service Function" (SF) to multiple "execution locations". The decision to steer traffic to a specific location may change frequently based on load, proximity, etc. Under the current Service Function Chaining (SFC) framework, steering traffic dynamically to the different execution endpoints requires a specific "rechaining", i.e., a change in the service function path reflecting the different IP endpoints to be used for the new execution points. This procedure may be complex and take time. In order to simplify rechaining and reduce the time to complete the procedure, we discuss separating the logical Service Function Path (SFP) from the specific execution endpoints. This can be done by identifying the SFs using a name rather than a routable IP endpoint (or Layer 2 address). This document describes the necessary extensions, additional functions, and protocol details in the Service Function Forwarder (SFF) to handle name-based relationships.

This document presents InterDigital's approach to name-based SFC. It does not represent IETF consensus and is presented here so that the SFC community may benefit from considering this mechanism and the possibility of its use in the edge data centers.

 draft-trossen-sfc-name-based-sff-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8677 RFC8678 Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions F. Baker C. Bowers J. Linkova December 2019 HTML TEXT PDF XML 43

Connecting an enterprise site to multiple ISPs over IPv6 using provider-assigned addresses is difficult without the use of some form of Network Address Translation (NAT). Much has been written on this topic over the last 10 to 15 years, but it still remains a problem without a clearly defined or widely implemented solution. Any multihoming solution without NAT requires hosts at the site to have addresses from each ISP and to select the egress ISP by selecting a source address for outgoing packets. It also requires routers at the site to take into account those source addresses when forwarding packets out towards the ISPs.

This document examines currently available mechanisms for providing a solution to this problem for a broad range of enterprise topologies. It covers the behavior of routers to forward traffic by taking into account source address, and it covers the behavior of hosts to select appropriate default source addresses. It also covers any possible role that routers might play in providing information to hosts to help them select appropriate source addresses. In the process of exploring potential solutions, this document also makes explicit requirements for how the solution would be expected to behave from the perspective of an enterprise site network administrator.

 draft-ietf-rtgwg-enterprise-pa-multihoming-12 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC8678 RFC8679 MPLS Egress Protection Framework Y. Shen M. Jeganathan B. Decraene H. Gredler C. Michel H. Chen December 2019 HTML TEXT PDF XML 25 fast reroute egress protection local repair

This document specifies a fast reroute framework for protecting IP/MPLS services and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of Point of Local Repair (PLR), protector, and backup egress router and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR and context-based forwarding on the protector. The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control-plane protocols converge on the topology changes due to the egress failure.

 draft-ietf-mpls-egress-protection-framework-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8679 RFC8680 Forward Error Correction (FEC) Framework Extension to Sliding Window Codes V. Roca A. Begen January 2020 HTML TEXT PDF XML 19 FEC FECFRAME packet loss recovery RLC Sliding Window FEC Codes

RFC 6363 describes a framework for using Forward Error Correction (FEC) codes to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. However, FECFRAME as per RFC 6363 is restricted to block FEC codes. This document updates RFC 6363 to support FEC codes based on a sliding encoding window, in addition to block FEC codes, in a backward-compatible way. During multicast/broadcast real-time content delivery, the use of sliding window codes significantly improves robustness in harsh environments, with less repair traffic and lower FEC-related added latency.

 draft-ietf-tsvwg-fecframe-ext-08 RFC6363 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8680 RFC8681 Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME V. Roca B. Teibi January 2020 HTML TEXT PDF XML 37 RLC FEC FECFRAME packet loss recovery reliability

This document describes two fully specified Forward Erasure Correction (FEC) Schemes for Sliding Window Random Linear Codes (RLC), one for RLC over the Galois Field (a.k.a., Finite Field) GF(2), a second one for RLC over the Galois Field GF(2), each time with the possibility of controlling the code density. They can protect arbitrary media streams along the lines defined by FECFRAME extended to Sliding Window FEC Codes. These Sliding Window FEC Codes rely on an encoding window that slides over the source symbols, generating new repair symbols whenever needed. Compared to block FEC codes, these Sliding Window FEC Codes offer key advantages with real-time flows in terms of reduced FEC-related latency while often providing improved packet erasure recovery capabilities.

 draft-ietf-tsvwg-rlc-fec-scheme-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8681 RFC8682 TinyMT32 Pseudorandom Number Generator (PRNG) M. Saito M. Matsumoto V. Roca Editor E. Baccelli January 2020 HTML TEXT PDF XML 12

This document describes the TinyMT32 Pseudorandom Number Generator (PRNG), which produces 32-bit pseudorandom unsigned integers and aims at having a simple-to-use and deterministic solution. This PRNG is a small-sized variant of the Mersenne Twister (MT) PRNG. The main advantage of TinyMT32 over MT is the use of a small internal state, compatible with most target platforms that include embedded devices, while keeping reasonably good randomness that represents a significant improvement compared to the Park-Miller Linear Congruential PRNG. However, neither the TinyMT nor MT PRNG is meant to be used for cryptographic applications.

 draft-ietf-tsvwg-tinymt32-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8682 RFC8683 Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks J. Palet Martinez November 2019 HTML TEXT PDF XML 38 IPv6 DNSSEC NAT64 DNS64 464XLAT CLAT NAT46 PLAT

This document describes how Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be deployed in an IPv6 network -- whether it's cellular ISP, broadband ISP, or enterprise -- and the possible optimizations. This document also discusses issues to be considered when having IPv6-only connectivity, such as: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6-compliant APIs, and c) IPv4-only hosts or applications.

 draft-ietf-v6ops-nat64-deployment-08 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC8683 RFC8684 TCP Extensions for Multipath Operation with Multiple Addresses A. Ford C. Raiciu M. Handley O. Bonaventure C. Paasch March 2020 HTML TEXT PDF XML 68 tcp extensions multipath multihomed subflow

TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure.

Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.

This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience.

 draft-ietf-mptcp-rfc6824bis-18 RFC6824 PROPOSED STANDARD PROPOSED STANDARD IETF tsv mptcp http://www.rfc-editor.org/errata_search.php?rfc=8684 10.17487/RFC8684 RFC8685 Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture F. Zhang Q. Zhao O. Gonzalez de Dios R. Casellas D. King December 2019 HTML TEXT PDF XML 27 Traffic Engineering Inter-domain Multi-domain

The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains.

This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support H-PCE procedures.

 draft-ietf-pce-hierarchy-extensions-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8685 RFC8686 Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery S. Kiesel M. Stiemerling February 2020 HTML TEXT PDF XML 34 Application-Layer Traffic Optimization (ALTO) ALTO cross-domain server discovery ALTO third-party server discovery

The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers that can provide suitable guidance.

In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be necessary to discover an ALTO server outside of the ALTO client's own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery.

Technically, the procedure specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (typically, "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the "in-addr.arpa." or "ip6.arpa." trees) and returns one or more URIs of information resources related to that IP address or prefix.

 draft-ietf-alto-xdom-disc-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC8686 RFC8687 OSPF Routing with Cross-Address Family Traffic Engineering Tunnels A. Smirnov A. Retana M. Barnes November 2019 HTML TEXT PDF XML 8 OSPF IPv4 IPv6 TE MPLS

When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network, the Multiprotocol Label Switching (MPLS) TE Label Switched Path (LSP) infrastructure may be duplicated, even if the destination IPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This issue is solved by advertising cross-address family (X-AF) OSPF TE information.

This document describes an update to RFC 5786 that allows for the easy identification of a router's local X-AF IP addresses.

 draft-ietf-ospf-xaf-te-07 RFC5786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8687 RFC8688 A Session Initiation Protocol (SIP) Response Code for Rejected Calls E.W. Burger B. Nagda December 2019 HTML TEXT PDF XML 22 STIR SIPCORE IANA

This document defines the 608 (Rejected) Session Initiation Protocol (SIP) response code. This response code enables calling parties to learn that an intermediary rejected their call attempt. No one will deliver, and thus answer, the call. As a 6xx code, the caller will be aware that future attempts to contact the same User Agent Server will likely fail. The initial use case driving the need for the 608 response code is when the intermediary is an analytics engine. In this case, the rejection is by a machine or other process. This contrasts with the 607 (Unwanted) SIP response code in which a human at the target User Agent Server indicates the user did not want the call. In some jurisdictions, this distinction is important. This document also defines the use of the Call-Info header field in 608 responses to enable rejected callers to contact entities that blocked their calls in error. This provides a remediation mechanism for legal callers that find their calls blocked.

 draft-ietf-sipcore-rejected-09 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore http://www.rfc-editor.org/errata_search.php?rfc=8688 10.17487/RFC8688 RFC8689 SMTP Require TLS Option J. Fenton November 2019 HTML TEXT PDF XML 16 SMTP

The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is, by default, prioritized over security. This document describes an SMTP service extension, REQUIRETLS, and a message header field, TLS-Required. If the REQUIRETLS option or TLS-Required message header field is used when sending a message, it asserts a request on the part of the message sender to override the default negotiation of TLS, either by requiring that TLS be negotiated when the message is relayed or by requesting that recipient-side policy mechanisms such as MTA-STS and DNS-Based Authentication of Named Entities (DANE) be ignored when relaying a message for which security is unimportant.

 draft-ietf-uta-smtp-require-tls-09 PROPOSED STANDARD PROPOSED STANDARD IETF art uta 10.17487/RFC8689 RFC8690 Clarification of Segment ID Sub-TLV Length for RFC 8287 N. Nainar C. Pignataro F. Iqbal A. Vainshtein December 2019 HTML TEXT PDF XML 7 mpls

RFC 8287 defines the extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with the MPLS data plane. RFC 8287 proposes three Target Forwarding Equivalence Class (FEC) Stack sub-TLVs. While RFC 8287 defines the format and procedure to handle those sub-TLVs, it does not sufficiently clarify how the length of the Segment ID sub-TLVs should be computed to be included in the Length field of the sub-TLVs. This ambiguity has resulted in interoperability issues.

This document updates RFC 8287 by clarifying the length of each of the Segment ID sub-TLVs defined in RFC 8287.

 draft-ietf-mpls-rfc8287-len-clarification-04 RFC8287 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8690 RFC8691 Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11 N. Benamar J. Härri J. Lee T. Ernst December 2019 HTML TEXT PDF XML 29 IPv6 over 802.11p OCB IPv6 over 802.11-OCB

This document provides methods and settings for using IPv6 to communicate among nodes within range of one another over a single IEEE 802.11-OCB link. Support for these methods and settings require minimal changes to existing stacks. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 over more complex scenarios are not covered in this specification and are a subject for future work.

 draft-ietf-ipwave-ipv6-over-80211ocb-52 PROPOSED STANDARD PROPOSED STANDARD IETF int ipwave 10.17487/RFC8691 RFC8692 Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs P. Kampanakis Q. Dang December 2019 HTML TEXT PDF XML 14 SHAKE in X.509 SHAKEs in PKIX certificates with SHAKE hashes

Digital signatures are used to sign messages, X.509 certificates, and Certificate Revocation Lists (CRLs). This document updates the "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" (RFC 3279) and describes the conventions for using the SHAKE function family in Internet X.509 certificates and revocation lists as one-way hash functions with the RSA Probabilistic signature and Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithms. The conventions for the associated subject public keys are also described.

 draft-ietf-lamps-pkix-shake-15 RFC3279 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8692 RFC8693 OAuth 2.0 Token Exchange M. Jones A. Nadalin B. Campbell Editor J. Bradley C. Mortimore January 2020 HTML TEXT PDF XML 27 JSON Web Token JWT Delegation Impersonation STS Security Token Service Exchange Token OAuth

This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.

 draft-ietf-oauth-token-exchange-19 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC8693 RFC8694 Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering D. King H. Zheng December 2019 HTML TEXT PDF XML 24

The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-Autonomous System (multi-AS) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic-Engineered (TE) networks.

This document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks.

 draft-ietf-pce-inter-area-as-applicability-08 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC8694 RFC8695 A YANG Data Model for the Routing Information Protocol (RIP) X. Liu P. Sarda V. Choudhary February 2020 HTML TEXT PDF XML 40 YANG RIP RIPng data model ietf-rip network management routing

This document describes a data model for the management of the Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. The data model includes definitions for configuration, operational state, and Remote Procedure Calls (RPCs).

The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA).

 draft-ietf-rtgwg-yang-rip-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8695 RFC8696 Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) R. Housley December 2019 HTML TEXT PDF XML 31 quantum-resistant

The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms if the existing syntax does not accommodate them. This document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key.

 draft-ietf-lamps-cms-mix-with-psk-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8696 RFC8697 Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs) I. Minei E. Crabbe S. Sivabalan H. Ananthakrishnan D. Dhody Y. Tanaka January 2020 HTML TEXT PDF XML 28 PCE PCEP Association Group

This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE.

 draft-ietf-pce-association-group-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8697 RFC8698 Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media X. Zhu R. Pan M. Ramalho S. Mena February 2020 HTML TEXT PDF XML 26 Multimedia Congestion Control

This document describes Network-Assisted Dynamic Adaptation (NADA), a novel congestion control scheme for interactive real-time media applications such as video conferencing. In the proposed scheme, the sender regulates its sending rate, based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from Explicit Congestion Notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings by reacting to queuing delays and packet losses instead.

 draft-ietf-rmcat-nada-13 EXPERIMENTAL EXPERIMENTAL IETF tsv rmcat 10.17487/RFC8698 RFC8699 Coupled Congestion Control for RTP Media S. Islam M. Welzl S. Gjessing January 2020 HTML TEXT PDF XML 20 tcp

When multiple congestion-controlled Real-time Transport Protocol (RTP) sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss, and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the number of changes needed to existing RTP applications. This document also specifies how to apply the method for the Network-Assisted Dynamic Adaptation (NADA) congestion control algorithm and provides suggestions on how to apply it to other congestion control algorithms.

 draft-ietf-rmcat-coupled-cc-09 EXPERIMENTAL EXPERIMENTAL IETF tsv rmcat 10.17487/RFC8699 RFC8700 Fifty Years of RFCs H. Flanagan Editor December 2019 HTML TEXT PDF XML 22 History RFC Series Retrospective

This RFC marks the fiftieth anniversary for the RFC Series. It includes both retrospective material from individuals involved at key inflection points as well as a review of the current state of affairs. It concludes with thoughts on possibilities for the next fifty years for the Series. This document updates the perspectives offered in RFCs 2555 and 5540.

 draft-iab-fiftyyears-01 RFC2555 RFC5540 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=8700 10.17487/RFC8700 RFC8701 Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility D. Benjamin January 2020 HTML TEXT PDF XML 12 TLS GREASE

This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values.

 draft-ietf-tls-grease-04 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC8701 RFC8702 Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS) P. Kampanakis Q. Dang January 2020 HTML TEXT PDF XML 16 SHAKEs in CMS SHAKE CMS with SHAKEs

This document updates the "Cryptographic Message Syntax (CMS) Algorithms" (RFC 3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic Signature Scheme (RSASSA-PSS) and Elliptic Curve Digital Signature Algorithm (ECDSA). The conventions for the associated signer public keys in CMS are also described.

 draft-ietf-lamps-cms-shakes-18 RFC3370 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps http://www.rfc-editor.org/errata_search.php?rfc=8702 10.17487/RFC8702 RFC8703 Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension R. Taylor S. Ratliff February 2020 HTML TEXT PDF XML 9 DLEP MANET Link-Aware Radio-Aware

The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to advertise the status of wireless links between reachable destinations to attached routers. The core specification of the protocol (RFC 8175) assumes that every modem in the radio network has an attached DLEP router and requires that the Media Access Control (MAC) address of the DLEP interface on the attached router be used to identify the destination in the network, for purposes of reporting the state and quality of the link to that destination.

This document describes a DLEP extension that allows modems that do not meet the strict requirement above to use DLEP to describe link availability and quality to one or more destinations reachable beyond a device on the Layer 2 domain.

 draft-ietf-manet-dlep-lid-extension-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8703 RFC8704 Enhanced Feasible-Path Unicast Reverse Path Forwarding K. Sriram D. Montgomery J. Haas February 2020 HTML TEXT PDF XML 17 BGP source address spoofing source address validation SAV Reverse Path Forwarding RPF unicast RPF uRPF DDoS mitigation BCP 38 BCP 84

This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704.

 draft-ietf-opsec-urpf-improvements-04 RFC3704 BCP0084 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsec 10.17487/RFC8704 RFC8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens B. Campbell J. Bradley N. Sakimura T. Lodderstedt February 2020 HTML TEXT PDF XML 24 JSON Web Token JWT MTLS Mutual TLS proof-of-possession proof-of-possession access token key confirmed access token certificate-bound access token client certificate X.509 Client Certificate Authentication key confirmation confirmation method holder-of-key OAuth

This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.

 draft-ietf-oauth-mtls-17 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC8705 RFC8706 Restart Signaling for IS-IS L. Ginsberg P. Wells February 2020 HTML TEXT PDF XML 22 IGP graceful restart

This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the DOWN state while still correctly initiating database synchronization.

This document additionally describes a mechanism for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding-plane state. This allows the neighbors to maintain their adjacencies until the router has restarted but also allows the neighbors to bring the adjacencies down in the event of other topology changes.

This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization while minimizing transient routing disruption when a router starts.

This document obsoletes RFC 5306.

 draft-ietf-lsr-isis-rfc5306bis-09 RFC5306 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8706 RFC8707 Resource Indicators for OAuth 2.0 B. Campbell J. Bradley H. Tschofenig February 2020 HTML TEXT PDF XML 11 OAuth Resource Audience

This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.

 draft-ietf-oauth-resource-indicators-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=8707 10.17487/RFC8707 RFC8708 Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) R. Housley February 2020 HTML TEXT PDF XML 14 digital signature message content

This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.

 draft-ietf-lamps-cms-hash-sig-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8708 RFC8709 Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol B. Harris L. Velvindron February 2020 HTML TEXT PDF XML 7

This document describes the use of the Ed25519 and Ed448 digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253.

 draft-ietf-curdle-ssh-ed25519-ed448-11 RFC4253 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8709 10.17487/RFC8709 RFC8710 Multipart Content-Format for the Constrained Application Protocol (CoAP) T. Fossati K. Hartke C. Bormann February 2020 HTML TEXT PDF XML 9 CoAP Multipart Content-Format

This memo defines application/multipart-core, an application-independent media type that can be used to combine representations of zero or more different media types (each with a Constrained Application Protocol (CoAP) Content-Format identifier) into a single representation, with minimal framing overhead.

 draft-ietf-core-multipart-ct-04 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8710 RFC8711 Structure of the IETF Administrative Support Activity, Version 2.0 B. Haberman J. Hall J. Livingood February 2020 HTML TEXT PDF XML 22 IASA IASA2

The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe the IETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLC Board (IETF LLC Board), the IETF Executive Director, and the Internet Society in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board.

This document obsoletes RFC 4071, RFC 4333, and RFC 7691.

 draft-ietf-iasa2-rfc4071bis-11 RFC4071 RFC4333 RFC7691 BCP0101 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen iasa2 10.17487/RFC8711 RFC8712 The IETF-ISOC Relationship G. Camarillo J. Livingood February 2020 HTML TEXT PDF XML 8 IASA

This document summarizes the Internet Engineering Task Force (IETF) - Internet Society (ISOC) relationship, following a major revision to the structure of the IETF Administrative Support Activity (IASA) in 2018. The IASA was revised under a new "IASA 2.0" structure by the IASA2 Working Group, which changed the IETF's administrative, legal, and financial structure. As a result, it also changed the relationship between the IETF and ISOC, which made it necessary to revise RFC 2031.

 draft-ietf-iasa2-rfc2031bis-08 RFC2031 INFORMATIONAL INFORMATIONAL IETF gen iasa2 10.17487/RFC8712 RFC8713 IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees M. Kucherawy Editor R. Hinden Editor J. Livingood Editor February 2020 HTML TEXT PDF XML 33 IASA IASA 2.0 IASA2

The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC (IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF Administrative Support Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.

This document obsoletes RFC 7437 and RFC 8318.

 draft-ietf-iasa2-rfc7437bis-09 RFC7437 RFC8318 BCP0010 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen iasa2 http://www.rfc-editor.org/errata_search.php?rfc=8713 10.17487/RFC8713 RFC8714 Update to the Process for Selection of Trustees for the IETF Trust J. Arkko T. Hardie February 2020 HTML TEXT PDF XML 6

This memo updates the process for selection of Trustees for the IETF Trust. Previously, the IETF Administrative Oversight Committee (IAOC) members also acted as Trustees, but the IAOC has been eliminated as part of an update to the structure of the IETF Administrative Support Activity (IASA). This memo specifies that the Trustees shall be selected separately.

This memo obsoletes RFC 4371. The changes relate only to the selection of Trustees. All other aspects of the IETF Trust remain as they are today.

 draft-ietf-iasa2-trust-update-03 RFC4371 BCP0101 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen iasa2 http://www.rfc-editor.org/errata_search.php?rfc=8714 10.17487/RFC8714 RFC8715 IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust J. Arkko February 2020 HTML TEXT PDF XML 6 IETF administration intellectual property leadership selection IASA

This document captures the rationale for the changes introduced in RFC 8714, "Update to the Process for Selection of Trustees for the IETF Trust".

At the time RFC 8714 was published, the changes to the IETF Administrative Support Activity, Version 2.0 (IASA 2.0) had an impact on the IETF Trust because members of the IETF Administrative Oversight Committee (IAOC), which was being phased out, had served as Trustees of the IETF Trust. This document provides background on the past IETF Trust arrangements, explains the effect of the rules in the founding documents during the transition to the new arrangement, and provides a rationale for the update.

 draft-ietf-iasa2-trust-rationale-03 INFORMATIONAL INFORMATIONAL IETF gen iasa2 10.17487/RFC8715 RFC8716 Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC P. Resnick A. Farrel February 2020 HTML TEXT PDF XML 7 Harassment Ombudsteam IAOC IETF Administration LLC

The IETF Anti-Harassment Procedures are described in RFC 7776.

The IETF Administrative Oversight Committee (IAOC) has been replaced by the IETF Administration LLC, and the IETF Administrative Director has been replaced by the IETF LLC Executive Director. This document updates RFC 7776 to amend these terms.

RFC 7776 contained updates to RFC 7437. RFC 8713 has incorporated those updates, so this document also updates RFC 7776 to remove those updates.

 draft-ietf-iasa2-rfc7776bis-03 RFC7776 BCP0025 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen iasa2 10.17487/RFC8716 RFC8717 IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology J. Klensin Editor February 2020 HTML TEXT PDF XML 7 IASA IASA2

In 2018, the IETF began the transition to a new administrative structure and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure. In addition to more substantive changes that are described in other documents, the transition to the 2018 IETF Administrative Support structure changes several position titles and organizational relationships that are referenced elsewhere. Rather than reissue those referencing documents individually, this specification provides updates to them and deprecates some now-obsolete documents to ensure that there is no confusion due to these changes.

 draft-ietf-iasa2-consolidated-upd-07 RFC2028 RFC2418 RFC3005 RFC3710 RFC3929 RFC4633 RFC6702 BCP0101 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen iasa2 10.17487/RFC8717 RFC8718 IETF Plenary Meeting Venue Selection Process E. Lear Editor February 2020 HTML TEXT PDF XML 10 Meeting Venues Meeting selection process IASA

The IETF Administration Support Activity (IASA) is responsible for arranging the selection and operation of the IETF plenary meeting venue. This memo specifies IETF community requirements for meeting venues, including hotels and meeting space. It also directs the IASA to make available additional process documents that describe the current meeting selection process.

 draft-ietf-mtgvenue-iaoc-venue-selection-process-16 BCP0226 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen mtgvenue 10.17487/RFC8718 RFC8719 High-Level Guidance for the Meeting Policy of the IETF S. Krishnan February 2020 HTML TEXT PDF XML 5 geographic distribution location IASA

This document describes a meeting location policy for the IETF and the various stakeholders required to realize this policy.

 draft-ietf-mtgvenue-meeting-policy-07 BCP0226 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen mtgvenue 10.17487/RFC8719 RFC8720 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries R. Housley Editor O. Kolkman Editor February 2020 HTML TEXT PDF XML 7 IASA

This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.

 draft-iab-rfc7500-bis-00 RFC7500 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8720 RFC8721 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents J. Halpern Editor February 2020 HTML TEXT PDF XML 8 IASA Trust

Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accept direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions. This document obsoletes RFC 5377 solely for the purpose of removing references to the IETF Administrative Oversight Committee (IAOC), which was part of the IETF Administrative Support Activity (IASA).

 draft-ietf-iasa2-rfc5377bis-03 RFC5377 INFORMATIONAL INFORMATIONAL IETF gen iasa2 10.17487/RFC8721 RFC8722 Defining the Role and Function of IETF Protocol Parameter Registry Operators D. McPherson Editor O. Kolkman Editor J. Klensin Editor G. Huston Editor February 2020 HTML TEXT PDF XML 11 IANA Governance

Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document obsoletes RFC 6220 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model.

 draft-ietf-iasa2-rfc6220bis-04 RFC6220 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8722 RFC8723 Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP) C. Jennings P. Jones R. Barnes A.B. Roach April 2020 HTML TEXT PDF XML 18 PERC SRTP RTP conferencing encryption

In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real-time Transport Protocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real-time Transport Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of future SRTP transforms with different properties.

 draft-ietf-perc-double-12 PROPOSED STANDARD PROPOSED STANDARD IETF art perc 10.17487/RFC8723 RFC8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation A. Minaburo L. Toutain C. Gomez D. Barthel JC. Zuniga April 2020 HTML TEXT PDF XML 71 header compression compression fragmentation static context rule-based LPWAN LPWANs low power low-power 6LoWPAN 6lo LoWPAN LoWPANs LLN LLNs LTN LTE LTE-M Sigfox LoRaWAN NB-IOT 5G IoT Internet of Things adaptation layer UDP IPv6 WSN Sensor network wireless sensor network 802.15.4 contrained network constrained node constrained-node network

This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.

SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.

This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.

The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope.

 draft-ietf-lpwan-ipv6-static-context-hc-24 PROPOSED STANDARD PROPOSED STANDARD IETF int lpwan 10.17487/RFC8724 RFC8725 JSON Web Token Best Current Practices Y. Sheffer D. Hardt M. Jones February 2020 HTML TEXT PDF XML 13 JSON Web Token JWT JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE attacks Claims Security Cryptography

JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.

 draft-ietf-oauth-jwt-bcp-07 RFC7519 BCP0225 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec oauth 10.17487/RFC8725 RFC8726 How Requests for IANA Action Will Be Handled on the Independent Stream A. Farrel November 2020 HTML TEXT PDF XML 6 IANA Independent Submissions Stream ISE

The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream.

The Independent Submission Stream is another source of documents that can be published as RFCs. This stream is under the care of the Independent Submissions Editor (ISE).

This document complements RFC 4846 by providing a description of how the ISE currently handles documents in the Independent Submission Stream that request actions from IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes.

 draft-ise-iana-policy-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8726 RFC8727 JSON Binding of the Incident Object Description Exchange Format T. Takahashi R. Danyliw M. Suzuki August 2020 HTML TEXT PDF XML 88 CBOR JSON IODEF

The Incident Object Description Exchange Format (IODEF) defined in RFC 7970 provides an information model and a corresponding XML data model for exchanging incident and indicator information. This document gives implementers and operators an alternative format to exchange the same information by defining an alternative data model implementation in JSON and its encoding in Concise Binary Object Representation (CBOR).

 draft-ietf-mile-jsoniodef-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC8727 RFC8728 RFC Editor Model (Version 2) O. Kolkman Editor J. Halpern Editor R. Hinden Editor February 2020 HTML TEXT PDF XML 19 IAB IASA RSOC RSE IASA IASA2

The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company and the RSOC. This document reflects the experience gained with "RFC Editor Model (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model.

 draft-ietf-iasa2-rfc6635bis-04 RFC6635 RFC9280 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8728 RFC8729 The RFC Series and RFC Editor R. Housley Editor L. Daigle Editor February 2020 HTML TEXT PDF XML 18 IASA IASA2 technical publisher

This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This document obsoletes RFC 4844.

 draft-ietf-iasa2-rfc4844-bis-05 RFC4844 RFC9280 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8729 RFC8730 Independent Submission Editor Model N. Brownlee Editor B. Hinden Editor February 2020 HTML TEXT PDF XML 6 ISE RSE LLC IAB IASA

This document describes the function and responsibilities of the RFC Independent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC Production Center and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF Administration Limited Liability Company (LLC).

This version obsoletes RFC 6548 to replace all references to the Internet Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 structure.

 draft-ietf-iasa2-rfc6548bis-02 RFC6548 RFC9280 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8730 RFC8731 Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448 A. Adamantiadis S. Josefsson M. Baushke February 2020 HTML TEXT PDF XML 6 Elliptic Curve Diffie Hellman ECDH

This document describes the specification for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol.

 draft-ietf-curdle-ssh-curves-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8731 RFC8732 Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2 S. Sorce H. Kario February 2020 HTML TEXT PDF XML 12 SSH

This document specifies additions and amendments to RFC 4462. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak Diffie-Hellman (DH) groups. The purpose of this specification is to modernize the cryptographic primitives used by Generic Security Service (GSS) key exchanges.

 draft-ietf-curdle-gss-keyex-sha2-10 RFC4462 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8732 RFC8733 Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE D. Dhody Editor R. Gandhi Editor U. Palle R. Singh L. Fang February 2020 HTML TEXT PDF XML 32 Bandwidth optimization PCEP Overwhelm LSP re-optimization

The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Stateful PCE extensions allow stateful control of MPLS-TE Label Switched Paths (LSPs) using PCEP.

The auto-bandwidth feature allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. This document describes PCEP extensions for auto-bandwidth adjustment when employing an active stateful PCE for both PCE-initiated and PCC-initiated LSPs.

 draft-ietf-pce-stateful-pce-auto-bandwidth-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8733 RFC8734 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3 L. Bruckert J. Merkle M. Lochter February 2020 HTML TEXT PDF XML 11 TLS Elliptic Curve Cryptography

Elliptic Curve Cryptography (ECC) Brainpool curves were an option for authentication and key exchange in the Transport Layer Security (TLS) protocol version 1.2 but were deprecated by the IETF for use with TLS version 1.3 because they had little usage. However, these curves have not been shown to have significant cryptographical weaknesses, and there is some interest in using several of these curves in TLS 1.3.

This document provides the necessary protocol mechanisms for using ECC Brainpool curves in TLS 1.3. This approach is not endorsed by the IETF.

 draft-bruckert-brainpool-for-tls13-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8734 RFC8735 Scenarios and Simulation Results of PCE in a Native IP Network A. Wang X. Huang C. Kou Z. Li P. Mi February 2020 HTML TEXT PDF XML 16 CCDR Traffic Engineering

Requirements for providing the End-to-End (E2E) performance assurance are emerging within the service provider networks. While there are various technology solutions, there is no single solution that can fulfill these requirements for a native IP network. In particular, there is a need for a universal E2E solution that can cover both intra- and inter-domain scenarios.

One feasible E2E traffic-engineering solution is the addition of central control in a native IP network. This document describes various complex scenarios and simulation results when applying the Path Computation Element (PCE) in a native IP network. This solution, referred to as Centralized Control Dynamic Routing (CCDR), integrates the advantage of using distributed protocols and the power of a centralized control technology, providing traffic engineering for native IP networks in a manner that applies equally to intra- and inter-domain scenarios.

 draft-ietf-teas-native-ip-scenarios-12 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8735 RFC8736 PIM Message Type Space Extension and Reserved Bits S. Venaas A. Retana February 2020 HTML TEXT PDF XML 8 Multicast

The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and creates a registry containing the per-message-type usage. This document also extends the PIM type space by defining three new message types. For each of the new types, four of the previously reserved bits are used to form an extended type range.

This document updates RFCs 7761 and 3973 by defining the use of the currently Reserved field in the PIM common header. This document further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and 8364, by specifying the use of the currently reserved bits for each PIM message.

This document obsoletes RFC 6166.

 draft-ietf-pim-reserved-bits-04 RFC6166 RFC3973 RFC5015 RFC5059 RFC6754 RFC7761 RFC8364 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC8736 RFC8737 Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension R.B. Shoemaker February 2020 HTML TEXT PDF XML 8 acme pki

This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol that allows for domain control validation using TLS.

 draft-ietf-acme-tls-alpn-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec acme 10.17487/RFC8737 RFC8738 Automated Certificate Management Environment (ACME) IP Identifier Validation Extension R.B. Shoemaker February 2020 HTML TEXT PDF XML 5

This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses.

 draft-ietf-acme-ip-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec acme 10.17487/RFC8738 RFC8739 Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME) Y. Sheffer D. Lopez O. Gonzalez de Dios A. Pastor Perales T. Fossati March 2020 HTML TEXT PDF XML 22 OCSP CRL revocation

Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an Automated Certificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates.

 draft-ietf-acme-star-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec acme 10.17487/RFC8739 RFC8740 Using TLS 1.3 with HTTP/2 D. Benjamin February 2020 HTML TEXT PDF XML 5 HTTP renegotiation post-handshake client authentication

This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction.

 draft-ietf-httpbis-http2-tls13-03 RFC9113 RFC7540 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC8740 RFC8741 Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP) A. Raghuram A. Goddard J. Karthik S. Sivabalan M. Negi March 2020 HTML TEXT PDF XML 11

A stateful Path Computation Element (PCE) retains information about the placement of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs). When a PCE has stateful control over LSPs, it may send indications to LSP head-ends to modify the attributes (especially the paths) of the LSPs. A Path Computation Client (PCC) that has set up LSPs under local configuration may delegate control of those LSPs to a stateful PCE.

There are use cases in which a stateful PCE may wish to obtain control of locally configured LSPs that it is aware of but have not been delegated to the PCE.

This document describes an extension to the Path Computation Element Communication Protocol (PCEP) to enable a PCE to make requests for such control.

 draft-ietf-pce-lsp-control-request-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8741 RFC8742 Concise Binary Object Representation (CBOR) Sequences C. Bormann February 2020 HTML TEXT PDF XML 10 binary format data interchange format JSON

This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence.

Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences.

 draft-ietf-cbor-sequence-02 PROPOSED STANDARD PROPOSED STANDARD IETF art cbor 10.17487/RFC8742 RFC8743 Multiple Access Management Services Multi-Access Management Services (MAMS) S. Kanugovi F. Baboescu J. Zhu S. Seo March 2020 HTML TEXT PDF XML 143 Integration Aggregation Switching MPTCP MPQUIC GMA 5G LTE Wi-Fi Ethernet Edge Proxy

In multiconnectivity scenarios, the clients can simultaneously connect to multiple networks based on different access technologies and network architectures like Wi-Fi, LTE, and DSL. Both the quality of experience of the users and the overall network utilization and efficiency may be improved through the smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions.

This document presents a unified problem statement and introduces a solution for managing multiconnectivity. The solution has been developed by the authors based on their experiences in multiple standards bodies, including the IETF and the 3GPP. However, this document is not an Internet Standards Track specification, and it does not represent the consensus opinion of the IETF.

This document describes requirements, solution principles, and the architecture of the Multi-Access Management Services (MAMS) framework. The MAMS framework aims to provide best performance while being easy to implement in a wide variety of multiconnectivity deployments. It specifies the protocol for (1) flexibly selecting the best combination of access and core network paths for the uplink and downlink, and (2) determining the user-plane treatment (e.g., tunneling, encryption) and traffic distribution over the selected links, to ensure network efficiency and the best possible application performance.

 draft-kanugovi-intarea-mams-framework-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8743 10.17487/RFC8743 RFC8744 Issues and Requirements for Server Name Identification (SNI) Encryption in TLS C. Huitema July 2020 HTML TEXT PDF XML 13

This document describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current "HTTP co-tenancy" solution, and presents requirements for future TLS-layer solutions.

In practice, it may well be that no solution can meet every requirement and that practical solutions will have to make some compromises.

 draft-ietf-tls-sni-encryption-09 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC8744 RFC8745 Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE H. Ananthakrishnan S. Sivabalan C. Barth I. Minei M. Negi March 2020 HTML TEXT PDF XML 15 PCEP

An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection.

 draft-ietf-pce-stateful-path-protection-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8745 RFC8746 Concise Binary Object Representation (CBOR) Tags for Typed Arrays C. Bormann Editor February 2020 HTML TEXT PDF XML 13 binary format data interchange format JSON

The Concise Binary Object Representation (CBOR), as defined in RFC 7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.

This document makes use of this extensibility to define a number of CBOR tags for typed arrays of numeric data, as well as additional tags for multi-dimensional and homogeneous arrays. It is intended as the reference document for the IANA registration of the CBOR tags defined.

 draft-ietf-cbor-array-tags-08 PROPOSED STANDARD PROPOSED STANDARD IETF art cbor 10.17487/RFC8746 RFC8747 Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) M. Jones L. Seitz G. Selander S. Erdtman H. Tschofenig March 2020 HTML TEXT PDF XML 14 CBOR Web Token CWT Proof-of-Possession Holder-of-Key

This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).

 draft-ietf-ace-cwt-proof-of-possession-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec ace 10.17487/RFC8747 RFC8748 Registry Fee Extension for the Extensible Provisioning Protocol (EPP) R. Carney G. Brown J. Frakes March 2020 HTML TEXT PDF XML 30

Given the expansion of the DNS namespace and the proliferation of novel business models, it is desirable to provide a method for Extensible Provisioning Protocol (EPP) clients to query EPP servers for the fees and credits associated with various billable transactions and provide expected fees and credits for certain commands and objects. This document describes an EPP extension mapping for registry fees.

 draft-ietf-regext-epp-fees-20 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8748 RFC8749 Moving DNSSEC Lookaside Validation (DLV) to Historic Status W. Mekking D. Mahoney March 2020 HTML TEXT PDF XML 6 DNS DNSSEC DLV

This document retires DNSSEC Lookaside Validation (DLV) and reclassifies RFCs 4431 and 5074 as Historic. Furthermore, this document updates RFC 6698 by excluding the DLV resource record from certificates and updates RFC 6840 by excluding the DLV registries from the trust anchor selection.

 draft-ietf-dnsop-obsolete-dlv-02 RFC6698 RFC6840 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8749 RFC8750 Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP) D. Migault T. Guggemos Y. Nir March 2020 HTML TEXT PDF XML 8 IKE IPsec GCM CCM ChaCha20

Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written. When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself and saves 8 octets per packet in the case of AES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how to do this.

 draft-ietf-ipsecme-implicit-iv-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8750 RFC8751 Hierarchical Stateful Path Computation Element (PCE) D. Dhody Y. Lee D. Ceccarelli J. Shin D. King March 2020 HTML TEXT PDF XML 21

A stateful Path Computation Element (PCE) maintains information on the current network state received from the Path Computation Clients (PCCs), including computed Label Switched Paths (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing the path for a new traffic-engineered LSP or for any associated/dependent LSPs. The path-computation response from a PCE helps the PCC to gracefully establish the computed LSP.

The Hierarchical Path Computation Element (H-PCE) architecture allows the optimum sequence of interconnected domains to be selected and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs.

Combining the capabilities of stateful PCE and the hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of stateful, but not stateless, PCEs using the hierarchical PCE architecture.

 draft-ietf-pce-stateful-hpce-15 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC8751 RFC8752 Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) M. Thomson M. Nottingham March 2020 HTML TEXT PDF XML 23 web security origin packaging bundle

The Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) Workshop was convened by the Internet Architecture Board (IAB) in July 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 draft-iab-escape-report-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8752 RFC8753 Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions J. Klensin P. Fältström April 2020 HTML TEXT PDF XML 13 IDNA2008 IDN Unicode Algorithmic Review Unicode Code Point Review IDNA Designated Expert

The standards for Internationalized Domain Names in Applications (IDNA) require a review of each new version of Unicode to determine whether incompatibilities with prior versions or other issues exist and, where appropriate, to allow the IETF to decide on the trade-offs between compatibility with prior IDNA versions and compatibility with Unicode going forward. That requirement, and its relationship to tables maintained by IANA, has caused significant confusion in the past. This document makes adjustments to the review procedure based on experience and updates IDNA, specifically RFC 5892, to reflect those changes and to clarify the various relationships involved. It also makes other minor adjustments to align that document with experience.

 draft-klensin-idna-unicode-review-05 RFC5892 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8753 RFC8754 IPv6 Segment Routing Header (SRH) C. Filsfils Editor D. Dukes Editor S. Previdi J. Leddy S. Matsushima D. Voyer March 2020 HTML TEXT PDF XML 27 SRv6 source-routing network-programming

Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.

 draft-ietf-6man-segment-routing-header-26 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=8754 10.17487/RFC8754 RFC8755 Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions M. Jenkins March 2020 HTML TEXT PDF XML 17 NSA CNSA NSS smime

The United States Government has published the National Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 8551. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

 draft-jenkins-cnsa-smime-profile-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8755 RFC8756 Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS M. Jenkins L. Zieglar March 2020 HTML TEXT PDF XML 17 NSA CNSA NSS certificate enrollment

This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government.

The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information.

The profile is made publicly available here for use by developers and operators of these and any other system deployments.

 draft-jenkins-cnsa-cmc-profile-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8756 RFC8757 Dynamic Link Exchange Protocol (DLEP) Latency Range Extension B. Cheng L. Berger Editor March 2020 HTML TEXT PDF XML 5 MANET

This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the range of latency that can be experienced on a link.

 draft-ietf-manet-dlep-latency-extension-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8757 RFC8758 Deprecating RC4 in Secure Shell (SSH) L. Velvindron April 2020 HTML TEXT PDF XML 5

This document deprecates RC4 in Secure Shell (SSH). Therefore, this document formally moves RFC 4345 to Historic status.

 draft-ietf-curdle-rc4-die-die-die-18 RFC4253 BCP0227 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec curdle 10.17487/RFC8758 RFC8759 RTP Payload for Timed Text Markup Language (TTML) J. Sandford March 2020 HTML TEXT PDF XML 15 subtitles captions imsc media streaming sdp xml

This memo describes a Real-time Transport Protocol (RTP) payload format for Timed Text Markup Language (TTML), an XML-based timed text format from W3C. This payload format is specifically targeted at streaming workflows using TTML.

 draft-ietf-payload-rtp-ttml-06 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8759 RFC8760 The Session Initiation Protocol (SIP) Digest Access Authentication Scheme R. Shekh-Yusef March 2020 HTML TEXT PDF XML 9 Digest Auth

This document updates RFC 3261 by modifying the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for more secure digest algorithms, e.g., SHA-256 and SHA-512/256, to replace the obsolete MD5 algorithm.

 draft-ietf-sipcore-digest-scheme-15 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8760 RFC8761 Video Codec Requirements and Evaluation Methodology A. Filippov A. Norkin J.R. Alvarez April 2020 HTML TEXT PDF XML 22 NETVC evaluation requirements compression performance video coding applications

This document provides requirements for a video codec designed mainly for use over the Internet. In addition, this document describes an evaluation methodology for measuring the compression efficiency to determine whether or not the stated requirements have been fulfilled.

 draft-ietf-netvc-requirements-10 INFORMATIONAL INFORMATIONAL IETF art netvc 10.17487/RFC8761 RFC8762 Simple Two-Way Active Measurement Protocol G. Mirsky G. Jun H. Nydell R. Foote March 2020 HTML TEXT PDF XML 15

This document describes the Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss.

 draft-ietf-ippm-stamp-10 RFC8972 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC8762 RFC8763 Deployment Considerations for Information-Centric Networking (ICN) A. Rahman D. Trossen D. Kutscher R. Ravindran April 2020 HTML TEXT PDF XML 30 routing Content Delivery Network (CDN) overlay underlay virtual virtualization naming NFV SDN

Information-Centric Networking (ICN) is now reaching technological maturity after many years of fundamental research and experimentation. This document provides a number of deployment considerations in the interest of helping the ICN community move forward to the next step of live deployments. First, the major deployment configurations for ICN are described, including the key overlay and underlay approaches. Then, proposed deployment migration paths are outlined to address major practical issues, such as network and application migration. Next, selected ICN trial experiences are summarized. Finally, protocol areas that require further standardization are identified to facilitate future interoperable ICN deployments. This document is a product of the Information-Centric Networking Research Group (ICNRG).

 draft-irtf-icnrg-deployment-guidelines-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8763 RFC8764 Apple's DNS Long-Lived Queries Protocol S. Cheshire M. Krochmal June 2020 HTML TEXT PDF XML 20 Async Asynchronous Change Notification Push Notification

Apple's DNS Long-Lived Queries (LLQ) is a mechanism for extending the DNS protocol to support change notification, thus allowing clients to learn about changes to DNS data without polling the server. From 2005 onwards, LLQ was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2020, the LLQ protocol was superseded by the IETF Standards Track RFC 8765, "DNS Push Notifications", which builds on experience gained with the LLQ protocol to create a superior replacement.

The existing LLQ protocol deployed and used from 2005 to 2020 is documented here to give background regarding the operational experience that informed the development of DNS Push Notifications, and to help facilitate a smooth transition from LLQ to DNS Push Notifications.

 draft-sekar-dns-llq-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8764 RFC8765 DNS Push Notifications T. Pusateri S. Cheshire June 2020 HTML TEXT PDF XML 32 dns update push notification

The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But, there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications.

 draft-ietf-dnssd-push-25 PROPOSED STANDARD PROPOSED STANDARD IETF int dnssd 10.17487/RFC8765 RFC8766 Discovery Proxy for Multicast DNS-Based Service Discovery S. Cheshire June 2020 HTML TEXT PDF XML 33 Multicast DNS DNS-Based Service Discovery

This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link.

 draft-ietf-dnssd-hybrid-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dnssd 10.17487/RFC8766 RFC8767 Serving Stale Data to Improve DNS Resiliency D. Lawrence W. Kumari P. Sood March 2020 HTML TEXT PDF XML 12 DNS DDoS Resiliency Denial-of-Service Expired

This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC 2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days.

 draft-ietf-dnsop-serve-stale-10 RFC1034 RFC1035 RFC2181 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8767 RFC8768 Constrained Application Protocol (CoAP) Hop-Limit Option M. Boucadair T. Reddy.K J. Shallow March 2020 HTML TEXT PDF XML 8 security mitigation service delivery connectivity anti-DDoS automation cooperation Resilience Filtering Security Center Mitigator Scrubbing dynamic service protection dynamic mitigation

The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option.

 draft-ietf-core-hop-limit-07 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8768 RFC8769 Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR) J. Schaad March 2020 HTML TEXT PDF XML 6

Concise Binary Object Representation (CBOR) is becoming a widely used method of doing content encoding. The Cryptographic Message Syntax (CMS) is still a widely used method of doing message-based security. This document defines a set of content types for CMS that hold CBOR content.

 draft-schaad-cbor-content-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8769 RFC8770 Host Router Support for OSPFv2 K. Patel P. Pillay-Esnault M. Bhardwaj S. Bayraktar April 2020 HTML TEXT PDF XML 8 non-transit

The Open Shortest Path First Version 2 (OSPFv2) protocol does not have a mechanism for a node to repel transit traffic if it is on the shortest path. This document defines a bit called the Host-bit (H-bit). This bit enables a router to advertise that it is a non-transit router. This document also describes the changes needed to support the H-bit in the domain. In addition, this document updates RFC 6987 to advertise Type 2 External and Not-So-Stubby Area (NSSA) Link State Advertisements (LSAs) (RFC 3101) with a high cost in order to repel traffic effectively.

 draft-ietf-ospf-ospfv2-hbit-12 RFC6987 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8770 RFC8771 The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO) A. Mayrhofer J. Hague April 1 2020 HTML TEXT PDF XML 10

Domain Names were designed for humans, IP addresses were not. But more than 30 years after the introduction of the DNS, a minority of mankind persists in invading the realm of machine-to-machine communication by reading, writing, misspelling, memorizing, permuting, and confusing IP addresses. This memo describes the Internationalized Deliberately Unreadable Network NOtation ("I-DUNNO"), a notation designed to replace current textual representations of IP addresses with something that is not only more concise but will also discourage this small, but obviously important, subset of human activity.

 draft-mayrhofer-i-dunno-02 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC8771 RFC8772 The China Mobile, Huawei, and ZTE Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP) S. Hu D. Eastlake F. Qin T. Chua D. Huang May 2020 HTML TEXT PDF XML 124 CUPS CUSP BRAS BBRAS

A Broadband Network Gateway (BNG) in a fixed wireline access network is an Ethernet-centric IP edge router and the aggregation point for subscriber traffic. Control and User Plane Separation (CUPS) for such a BNG improves flexibility and scalability but requires various communication between the User Plane (UP) and the Control Plane (CP). China Mobile, Huawei Technologies, and ZTE have developed a simple CUPS control channel protocol to support such communication: the Simple Control and User Plane Separation Protocol (S-CUSP). S-CUSP is defined in this document.

This document is not an IETF standard and does not have IETF consensus. S-CUSP is presented here to make its specification conveniently available to the Internet community to enable diagnosis and interoperability.

 draft-chz-simple-cu-separation-bng-protocol-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8772 RFC8773 TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key R. Housley March 2020 HTML TEXT PDF XML 11

This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre-shared key (PSK).

 draft-ietf-tls-tls13-cert-with-extern-psk-07 EXPERIMENTAL EXPERIMENTAL IETF sec tls 10.17487/RFC8773 RFC8774 The Quantum Bug M. Welzl April 1 2020 HTML TEXT PDF XML 6 Teleportation Entanglement 0-RTT

The age of quantum networking is upon us, and with it comes "entanglement": a procedure in which a state (i.e., a bit) can be transferred instantly, with no measurable delay between peers. This will lead to a perceived round-trip time of zero seconds on some Internet paths, a capability which was not predicted and so not included as a possibility in many protocol specifications. Worse than the millennium bug, this unexpected value is bound to cause serious Internet failures unless the specifications are fixed in time.

 draft-welzl-quantumbug-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8774 10.17487/RFC8774 RFC8775 PIM Designated Router Load Balancing Y. Cai H. Ou S. Vallepalli M. Mishra S. Venaas A. Green April 2020 HTML TEXT PDF XML 18 Multicast

On a multi-access network, one of the PIM-SM (PIM Sparse Mode) routers is elected as a Designated Router. One of the responsibilities of the Designated Router is to track local multicast listeners and forward data to these listeners if the group is operating in PIM-SM. This document specifies a modification to the PIM-SM protocol that allows more than one of the PIM-SM routers to take on this responsibility so that the forwarding load can be distributed among multiple routers.

 draft-ietf-pim-drlb-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC8775 RFC8776 Common YANG Data Types for Traffic Engineering T. Saad R. Gandhi X. Liu V. Beeram I. Bryskin June 2020 HTML TEXT PDF XML 84 TE Tunnel TE Model TE Types TE YANG TE Topology TE Interfaces TE LSP Model

This document defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities.

 draft-ietf-teas-yang-te-types-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8776 RFC8777 DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery J. Holland April 2020 HTML TEXT PDF XML 33 DRIAD DRYAD AMT IGMPv3 MLDv2 SSM amt gateway amt relay multicast multicast replication multicast encapsulation amt relay discovery amt discovery AMTRELAY

This document updates RFC 7450, "Automatic Multicast Tunneling" (or AMT), by modifying the relay discovery process. A new DNS resource record named AMTRELAY is defined for publishing AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. Other extensions and clarifications to the relay discovery process are also defined.

 draft-ietf-mboned-driad-amt-discovery-13 RFC7450 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned http://www.rfc-editor.org/errata_search.php?rfc=8777 10.17487/RFC8777 RFC8778 Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE) R. Housley April 2020 HTML TEXT PDF XML 15 digital signature HSS/LMS Hash-based Signature Algorithm

This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing and Encryption (COSE) syntax. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.

 draft-ietf-cose-hash-sig-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec cose 10.17487/RFC8778 RFC8779 Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS C. Margaria Editor O. Gonzalez de Dios Editor F. Zhang Editor July 2020 HTML TEXT PDF XML 38 RSVP-TE GMPLS PCE

A Path Computation Element (PCE) provides path computation functions for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Additional requirements for GMPLS are identified in RFC 7025.

This memo provides extensions to the Path Computation Element Communication Protocol (PCEP) for the support of the GMPLS control plane to address those requirements.

 draft-ietf-pce-gmpls-pcep-extensions-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8779 RFC8780 The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA) Y. Lee Editor R. Casellas Editor July 2020 HTML TEXT PDF XML 26 Wavelength Allocation Transparent Optical Networks Fixed DWDM Grid

This document provides Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs). Path provisioning in WSONs requires an RWA process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical path computation.

 draft-ietf-pce-wson-rwa-ext-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8780 RFC8781 Discovering PREF64 in Router Advertisements L. Colitti J. Linkova April 2020 HTML TEXT PDF XML 10

This document specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate prefixes of Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) to hosts.

 draft-ietf-6man-ra-pref64-09 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8781 RFC8782 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification T. Reddy.K Editor M. Boucadair Editor P. Patil A. Mortensen N. Teague May 2020 HTML TEXT PDF XML 100 security mitigation service delivery connectivity anti-DDoS automation cooperation resilience filtering security center mitigator scrubbing dynamic service protection dynamic mitigation cooperative networking protective networking

This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.

A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.

 draft-ietf-dots-signal-channel-41 RFC9132 PROPOSED STANDARD PROPOSED STANDARD IETF sec dots http://www.rfc-editor.org/errata_search.php?rfc=8782 10.17487/RFC8782 RFC8783 Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification M. Boucadair Editor T. Reddy.K Editor May 2020 HTML TEXT PDF XML 66 DOTS Automation Security Mitigation Scrubbing Anti-DDoS Mitigator Security Center Filtering Resilience RESTCONF

The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions.

This is a companion document to "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (RFC 8782).

 draft-ietf-dots-data-channel-31 PROPOSED STANDARD PROPOSED STANDARD IETF sec dots http://www.rfc-editor.org/errata_search.php?rfc=8783 10.17487/RFC8783 RFC8784 Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security S. Fluhrer P. Kampanakis D. McGrew V. Smyslov June 2020 HTML TEXT PDF XML 16 internet key exchange quantum computer post quantum post-quantum quantum safe quantum secure quantum resistant

The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys.

 draft-ietf-ipsecme-qr-ikev2-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8784 RFC8785 JSON Canonicalization Scheme (JCS) A. Rundgren B. Jordan S. Erdtman June 2020 HTML TEXT PDF XML 20 JSON ECMAScript Signatures Cryptography Canonicalization

Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results.

This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting.

 draft-rundgren-json-canonicalization-scheme-17 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8785 10.17487/RFC8785 RFC8786 Updated Rules for Processing Stateful PCE Request Parameters Flags A. Farrel May 2020 HTML TEXT PDF XML 6 PCEP Path Computation Element Stateful PCE Flags

Extensions to the Path Computation Element Communication Protocol (PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCE Request Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages.

This document updates RFC 8231 by defining the correct behaviors.

 draft-ietf-pce-stateful-flags-01 RFC8231 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8786 RFC8787 Location Source Parameter for the SIP Geolocation Header Field J. Winterbottom R. Jesske B. Chatras A. Hutton May 2020 HTML TEXT PDF XML 8 Emergency Call Location

There are some circumstances where a Geolocation header field may contain more than one locationValue. Knowing the identity of the node adding the locationValue allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the locationValues. This document defines the "loc-src" parameter so that the entity adding the locationValue to the Geolocation header field can identify itself using its hostname. This document updates RFC 6442.

 draft-ietf-sipcore-locparam-06 RFC6442 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8787 RFC8788 Eligibility for the 2020-2021 Nominating Committee B. Leiba May 2020 HTML TEXT PDF XML 5 nomcom

The 2020-2021 Nominating Committee (NomCom) is to be formed between the IETF 107 and IETF 108 meetings, and the issue of eligibility of who can serve on that NomCom needs clarification. This document provides a one-time interpretation of the eligibility rules that is required for the exceptional situation of the cancellation of the in-person IETF 107 meeting. This document only affects the seating of the 2020-2021 NomCom and any rules or processes that relate to NomCom eligibility before IETF 108; it does not set a precedent to be applied in the future.

 draft-iesg-nomcom-eligibility-2020-03 BCP0010 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8788 RFC8789 IETF Stream Documents Require IETF Rough Consensus J. Halpern Editor E. Rescorla Editor June 2020 HTML TEXT PDF XML 4 process publication

This document requires that the IETF never publish any IETF Stream RFCs without IETF rough consensus. This updates RFC 2026.

 draft-halpern-gendispatch-consensusinformational-04 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8789 RFC8790 FETCH and PATCH with Sensor Measurement Lists (SenML) A. Keränen M. Mohajer June 2020 HTML TEXT PDF XML 11 CoAP IoT data model

The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters. The Constrained Application Protocol (CoAP) FETCH, PATCH, and iPATCH methods enable accessing and updating parts of a resource or multiple resources with one request. This document defines new media types for the CoAP FETCH, PATCH, and iPATCH methods for resources represented using the SenML data model.

 draft-ietf-core-senml-etch-07 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8790 RFC8791 YANG Data Structure Extensions A. Bierman M. Björklund K. Watsen June 2020 HTML TEXT PDF XML 16

This document describes YANG mechanisms for defining abstract data structures with YANG.

 draft-ietf-netmod-yang-data-ext-05 RFC8340 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8791 RFC8792 Handling Long Lines in Content of Internet-Drafts and RFCs K. Watsen E. Auerswald A. Farrel Q. Wu June 2020 HTML TEXT PDF XML 28 sourcecode artwork

This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.

 draft-ietf-netmod-artwork-folding-12 INFORMATIONAL INFORMATIONAL IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8792 10.17487/RFC8792 RFC8793 Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology B. Wissingh C. Wood A. Afanasyev L. Zhang D. Oran C. Tschudin June 2020 HTML TEXT PDF XML 17 content routing content caching content distribution networks data-centric security

Information-Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content instead of sending packets to destination addresses. Named Data Networking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures. This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN. While there are other ICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document. This document is a product of the Information-Centric Networking Research Group (ICNRG).

 draft-irtf-icnrg-terminology-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8793 RFC8794 Extensible Binary Meta Language S. Lhomme D. Rice M. Bunkus July 2020 HTML TEXT PDF XML 51 cellar binary storage xml matroska webm

This document defines the Extensible Binary Meta Language (EBML) format as a binary container format designed for audio/video storage. EBML is designed as a binary equivalent to XML and uses a storage-efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document.

 draft-ietf-cellar-ebml-17 PROPOSED STANDARD PROPOSED STANDARD IETF art cellar http://www.rfc-editor.org/errata_search.php?rfc=8794 10.17487/RFC8794 RFC8795 YANG Data Model for Traffic Engineering (TE) Topologies X. Liu I. Bryskin V. Beeram T. Saad H. Shah O. Gonzalez de Dios August 2020 HTML TEXT PDF XML 170 TE topology TE topology YANG model Abstract TE topology Native TE topology Customized TE topology Underlay TE topology Overlay TE topology

This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment.

 draft-ietf-teas-yang-te-topo-22 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8795 RFC8796 RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels M. Taillon T. Saad Editor R. Gandhi A. Deshmukh M. Jork V. Beeram July 2020 HTML TEXT PDF XML 18

This document updates RFC 4090 for the Resource Reservation Protocol (RSVP) Traffic Engineering (TE) procedures defined for facility backup protection. The updates include extensions that reduce the amount of signaling and processing that occurs during Fast Reroute (FRR); as a result, scalability when undergoing FRR convergence after a link or node failure is improved. These extensions allow the RSVP message exchange between the Point of Local Repair (PLR) and the Merge Point (MP) nodes to be independent of the number of protected Label Switched Paths (LSPs) traversing between them when facility bypass FRR protection is used. The signaling extensions are fully backwards compatible with nodes that do not support them.

 draft-ietf-mpls-summary-frr-rsvpte-09 RFC4090 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8796 RFC8797 Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1 C. Lever June 2020 HTML TEXT PDF XML 12 NFS-over-RDMA

This document specifies the format of Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data exchanged between RPC-over-RDMA version 1 peers as part of establishing a connection. The addition of the Private Data payload specified in this document is an optional extension that does not alter the RPC-over-RDMA version 1 protocol. This document updates RFC 8166.

 draft-ietf-nfsv4-rpcrdma-cm-pvt-data-08 RFC8166 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8797 RFC8798 Additional Units for Sensor Measurement Lists (SenML) C. Bormann June 2020 HTML TEXT PDF XML 9 Internet of Things (IoT) data model quantities and units International System of Units (SI) International System of Quantities (ISQ)

The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry, as they are derived by linear transformation from units already in that registry.

 draft-ietf-core-senml-more-units-06 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8798 RFC8799 Limited Domains and Internet Protocols B. Carpenter B. Liu July 2020 HTML TEXT PDF XML 23

There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes.

This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus.

 draft-carpenter-limited-domains-13 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8799 RFC8800 Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling S. Litkowski S. Sivabalan C. Barth M. Negi July 2020 HTML TEXT PDF XML 21 Disjoint disjointness association

This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a Path Computation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that the LSPs in the same group need to be disjoint from each other.

 draft-ietf-pce-association-diversity-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8800 RFC8801 Discovering Provisioning Domain Names and Data P. Pfister É. Vyncke T. Pauly D. Schinazi W. Shao July 2020 HTML TEXT PDF XML 27 IPv6 Provisioning DHCP PvD

Provisioning Domains (PvDs) are defined as consistent sets of network configuration information. PvDs allows hosts to manage connections to multiple networks and interfaces simultaneously, such as when a home router provides connectivity through both a broadband and cellular network provider.

This document defines a mechanism for explicitly identifying PvDs through a Router Advertisement (RA) option. This RA option announces a PvD identifier, which hosts can compare to differentiate between PvDs. The option can directly carry some information about a PvD and can optionally point to PvD Additional Information that can be retrieved using HTTP over TLS.

 draft-ietf-intarea-provisioning-domains-11 PROPOSED STANDARD PROPOSED STANDARD IETF int intarea 10.17487/RFC8801 RFC8802 The Quality for Service (Q4S) Protocol J.J. Aranda M. Cortes J. Salvachúa M. Narganes I. Martínez-Sarriegui July 2020 HTML TEXT PDF XML 73 quality measurement measurement protocol latency jitter bandwidth packet-loss

This memo describes an application-level protocol for the communication of end-to-end QoS compliance information based on the HyperText Transfer Protocol (HTTP) and the Session Description Protocol (SDP). The Quality for Service (Q4S) protocol provides a mechanism to negotiate and monitor latency, jitter, bandwidth, and packet loss, and to alert whenever one of the negotiated conditions is violated.

Implementation details on the actions to be triggered upon reception/detection of QoS alerts exchanged by the protocol are out of scope of this document; it is either application dependent (e.g., act to increase quality or reduce bit-rate) or network dependent (e.g., change connection's quality profile).

This protocol specification is the product of research conducted over a number of years; it is presented here as a permanent record and to offer a foundation for future similar work. It does not represent a standard protocol and does not have IETF consensus.

 draft-aranda-dispatch-q4s-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8802 RFC8803 0-RTT TCP Convert Protocol O. Bonaventure Editor M. Boucadair Editor S. Gundavelli S. Seo B. Hesmans July 2020 HTML TEXT PDF XML 47 Hybrid access aggregation transport evolution future internet extension Trafic Steering ATSSS Multipath TCP

This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the 0-RTT TCP Convert Protocol (Convert).

This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels whatsoever).

This specification assumes an explicit model, where the Transport Converter is explicitly configured on hosts. As a sample applicability use case, this document specifies how the Convert Protocol applies for Multipath TCP.

 draft-ietf-tcpm-converters-19 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC8803 RFC8804 Content Delivery Network Interconnection (CDNI) Request Routing Extensions O. Finkelman S. Mishra September 2020 HTML TEXT PDF XML 17

Open Caching architecture is a use case of Content Delivery Network Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document defines extensions to the CDNI Metadata Interface (MI) and the Footprint & Capabilities Advertisement interface (FCI). These extensions are derived from requirements raised by Open Caching but are also applicable to CDNI use cases in general.

 draft-ietf-cdni-request-routing-extensions-08 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni 10.17487/RFC8804 RFC8805 A Format for Self-Published IP Geolocation Feeds E. Kline K. Duleba Z. Szamonek S. Moser W. Kumari August 2020 HTML TEXT PDF XML 23 geo-location geolocation addresses

This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location.

Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds.

This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated.

 draft-google-self-published-geofeeds-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8805 RFC8806 Running a Root Server Local to a Resolver W. Kumari P. Hoffman June 2020 HTML TEXT PDF XML 12 DNS local-root

Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round-trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator.

This document obsoletes RFC 7706.

 draft-ietf-dnsop-7706bis-12 RFC7706 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC8806 RFC8807 Login Security Extension for the Extensible Provisioning Protocol (EPP) J. Gould M. Pozun August 2020 HTML TEXT PDF XML 21

The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response.

 draft-ietf-regext-login-security-10 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8807 RFC8808 A YANG Data Model for Factory Default Settings Q. Wu B. Lengyel Y. Niu August 2020 HTML TEXT PDF XML 10

This document defines a YANG data model with the "factory-reset" RPC to allow clients to reset a server back to its factory default condition. It also defines an optional "factory-default" datastore to allow clients to read the factory default configuration for the device.

The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

 draft-ietf-netmod-factory-default-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8808 RFC8809 Registries for Web Authentication (WebAuthn) J. Hodges G. Mandyam M. Jones August 2020 HTML TEXT PDF XML 7 webauthn attestation extensions registry

This specification defines IANA registries for W3C Web Authentication (WebAuthn) attestation statement format identifiers and extension identifiers.

 draft-hodges-webauthn-registries-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8809 RFC8810 Revision to Capability Codes Registration Procedures J. Scudder August 2020 HTML TEXT PDF XML 5 IDR

This document updates RFC 5492 by making a change to the registration procedures for BGP Capability Codes. Specifically, the range formerly designated "Private Use" is divided into three new ranges: "First Come First Served", "Experimental Use", and "Reserved".

 draft-ietf-idr-capabilities-registry-change-09 RFC5492 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8810 RFC8811 DDoS Open Threat Signaling (DOTS) Architecture A. Mortensen Editor T. Reddy.K Editor F. Andreasen N. Teague R. Compton August 2020 HTML TEXT PDF XML 29

This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment.

 draft-ietf-dots-architecture-18 INFORMATIONAL INFORMATIONAL IETF sec dots 10.17487/RFC8811 RFC8812 CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms M. Jones August 2020 HTML TEXT PDF XML 10 Cryptography Digital Signature Encryption W3C World Wide Web Consortium WebAuthn Web Authentication FIDO Alliance FIDO FIDO2 CTAP CTAP2

The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms (which are used by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry.

 draft-ietf-cose-webauthn-algorithms-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec cose 10.17487/RFC8812 RFC8813 Clarifications for Elliptic Curve Cryptography Subject Public Key Information T. Ito S. Turner August 2020 HTML TEXT PDF XML 3 PKIX X.509 ECC

This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography.

 draft-ietf-lamps-5480-ku-clarifications-03 RFC5480 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8813 RFC8814 Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State J. Tantsura U. Chunduri K. Talaulikar G. Mirsky N. Triantafillis August 2020 HTML TEXT PDF XML 9 BGP-LS SID MSD SR

This document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.

Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network.

 draft-ietf-idr-bgp-ls-segment-routing-msd-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8814 RFC8815 Deprecating Any-Source Multicast (ASM) for Interdomain Multicast M. Abrahamsson T. Chown L. Giuliano T. Eckert August 2020 HTML TEXT PDF XML 14 ASM Deprecate Deprecation Interdomain Intradomain PIM-SM PIM-SSM SSM MSDP MBONE Multicast

This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast. It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications and recommends that hosts and routers in these deployments fully support SSM. The recommendations in this document do not preclude the continued use of ASM within a single organization or domain and are especially easy to adopt in existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM).

 draft-ietf-mboned-deprecate-interdomain-asm-07 BCP0229 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC8815 RFC8816 Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases E. Rescorla J. Peterson February 2021 HTML TEXT PDF XML 24 SIP

The Personal Assertion Token (PASSporT) format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identity of callers. However, not all telephone calls use Internet signaling protocols, and some calls use them for only part of their signaling path, while some cannot reliably deliver SIP header fields end-to-end. This document describes use cases that require the delivery of PASSporT objects outside of the signaling path, and defines architectures and semantics to provide this functionality.

 draft-ietf-stir-oob-07 INFORMATIONAL INFORMATIONAL IETF art stir 10.17487/RFC8816 RFC8817 RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec V. Demjanenko J. Punaro D. Satterlee August 2020 HTML TEXT PDF XML 20 MELP MELPe TSVCIS NRLVDR Naval Research Laboratory NRL NATO TSVWG Department of Defense DoD NSA MIL-STD

This document describes the RTP payload format for the Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) speech coder. TSVCIS is a scalable narrowband voice coder supporting varying encoder data rates and fallbacks. It is implemented as an augmentation to the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder by conveying additional speech coder parameters to enhance voice quality. TSVCIS augmented speech data is processed in conjunction with its temporally matched Mixed Excitation Linear Prediction (MELP) 2400 speech data. The RTP packetization of TSVCIS and MELPe speech coder data is described in detail.

 draft-ietf-payload-tsvcis-05 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8817 RFC8818 Distributed Mobility Anchoring H. Chan Editor X. Wei J. Lee S. Jeon CJ. Bernardos Editor October 2020 HTML TEXT PDF XML 18 anchor address continuity reachability continuity PMIPv6 MIPv6

This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. A network may be configured with distributed mobility anchoring functions for both network-based or host-based mobility support, depending on the network's needs. In a distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor. To start a new flow or to handle a flow not requiring IP session continuity as a mobile node moves to a new network, the flow can be started or restarted using an IP address configured from the new IP prefix anchored to the new network. If the flow needs to survive the change of network, there are solutions that can be used to enable IP address mobility. This document describes different anchoring approaches, depending on the IP mobility needs, and how this IP address mobility is handled by the network.

 draft-ietf-dmm-distributed-mobility-anchoring-15 INFORMATIONAL INFORMATIONAL IETF int dmm 10.17487/RFC8818 RFC8819 YANG Module Tags C. Hopps L. Berger D. Bogdanovic January 2021 HTML TEXT PDF XML 19 YANG tags

This document provides for the association of tags with YANG modules. The expectation is for such tags to be used to help classify and organize modules. A method for defining, reading, and writing modules tags is provided. Tags may be registered and assigned during module definition, assigned by implementations, or dynamically defined and set by users. This document also provides guidance to future model writers; as such, this document updates RFC 8407.

 draft-ietf-netmod-module-tags-10 RFC8407 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8819 RFC8820 URI Design and Ownership M. Nottingham June 2020 HTML TEXT PDF XML 8 URI structure

Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of substructure in URIs is often problematic.

This document provides guidance on the specification of URI substructure in standards.

This document obsoletes RFC 7320 and updates RFC 3986.

 draft-nottingham-rfc7320bis-03 RFC7320 RFC3986 BCP0190 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8820 RFC8821 PCE-Based Traffic Engineering (TE) in Native IP Networks A. Wang B. Khasanov Q. Zhao H. Chen April 2021 HTML TEXT PDF XML 12 Centralized Control Dynamic Routing CCDR

This document defines an architecture for providing traffic engineering in a native IP network using multiple BGP sessions and a Path Computation Element (PCE)-based central control mechanism. It defines the Centralized Control Dynamic Routing (CCDR) procedures and identifies needed extensions for the Path Computation Element Communication Protocol (PCEP).

 draft-ietf-teas-pce-native-ip-17 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8821 RFC8822 5G Wireless Wireline Convergence User Plane Encapsulation (5WE) D. Allan Editor D. Eastlake D. Woolley April 2021 HTML TEXT PDF XML 8 PPPoE W-AGF QFI RQI WWC

As part of providing wireline access to the 5G Core (5GC), deployed wireline networks carry user data between 5G residential gateways and the 5G Access Gateway Function (AGF). The encapsulation method specified in this document supports the multiplexing of traffic for multiple PDU sessions within a VLAN-delineated access circuit, permits legacy equipment in the data path to inspect certain packet fields, carries 5G QoS information associated with the packet data, and provides efficient encoding. It achieves this by specific points of similarity with the Point-to-Point Protocol over Ethernet (PPPoE) data packet encapsulation (RFC 2516).

 draft-allan-5g-fmc-encapsulation-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8822 RFC8823 Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates A. Melnikov April 2021 HTML TEXT PDF XML 12 ACME S/MIME

This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME.

 draft-ietf-acme-email-smime-14 INFORMATIONAL INFORMATIONAL IETF sec acme 10.17487/RFC8823 RFC8824 Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) A. Minaburo L. Toutain R. Andreasen June 2021 HTML TEXT PDF XML 30 header compression fragmentation IoT constrained networks LPWAN sensor network constrained node wireless sensor network core OSCORE

This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.

 draft-ietf-lpwan-coap-static-context-hc-19 PROPOSED STANDARD PROPOSED STANDARD IETF int lpwan 10.17487/RFC8824 RFC8825 Overview: Real-Time Protocols for Browser-Based Applications H. Alvestrand January 2021 HTML TEXT PDF XML 17

This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".

It intends to serve as a starting and coordination point to make sure that (1) all the parts that are needed to achieve this goal are findable and (2) the parts that belong in the Internet protocol suite are fully specified and on the right publication track.

This document is an applicability statement -- it does not itself specify any protocol, but it specifies which other specifications implementations are supposed to follow to be compliant with Web Real-Time Communication (WebRTC).

 draft-ietf-rtcweb-overview-19 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC8825 RFC8826 Security Considerations for WebRTC E. Rescorla January 2021 HTML TEXT PDF XML 21

WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model.

 draft-ietf-rtcweb-security-12 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC8826 RFC8827 WebRTC Security Architecture E. Rescorla January 2021 HTML TEXT PDF XML 35

This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".

 draft-ietf-rtcweb-security-arch-20 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC8827 RFC8828 WebRTC IP Address Handling Requirements J. Uberti G. Shieh January 2021 HTML TEXT PDF XML 9 WebRTC privacy private IP address routing proxy peer mode

This document provides information and requirements for how IP addresses should be handled by Web Real-Time Communication (WebRTC) implementations.

 draft-ietf-rtcweb-ip-handling-12 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC8828 RFC8829 JavaScript Session Establishment Protocol (JSEP) J. Uberti C. Jennings E. Rescorla Editor January 2021 HTML TEXT PDF XML 95 webrtc sdp negotiation signaling peerconnection api ice rtp offer answer

This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols.

 draft-ietf-rtcweb-jsep-26 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC8829 RFC8830 WebRTC MediaStream Identification in the Session Description Protocol H. Alvestrand January 2021 HTML TEXT PDF XML 12 MediaStreamTrack

This document specifies a Session Description Protocol (SDP) grouping mechanism for RTP media streams that can be used to specify relations between media streams.

This mechanism is used to signal the association between the SDP concept of "media description" and the Web Real-Time Communication (WebRTC) concept of MediaStream/MediaStreamTrack using SDP signaling.

 draft-ietf-mmusic-msid-17 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC8830 RFC8831 WebRTC Data Channels R. Jesup S. Loreto M. Tüxen January 2021 HTML TEXT PDF XML 14

The WebRTC framework specifies protocol support for direct, interactive, rich communication using audio, video, and data between two peers' web browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service that allows web browsers to exchange generic data from peer to peer.

 draft-ietf-rtcweb-data-channel-13 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC8831 RFC8832 WebRTC Data Channel Establishment Protocol R. Jesup S. Loreto M. Tüxen January 2021 HTML TEXT PDF XML 12

The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web browsers. This document specifies a simple protocol for establishing symmetric data channels between the peers. It uses a two-way handshake and allows sending of user data without waiting for the handshake to complete.

 draft-ietf-rtcweb-data-protocol-09 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb http://www.rfc-editor.org/errata_search.php?rfc=8832 10.17487/RFC8832 RFC8833 Application-Layer Protocol Negotiation (ALPN) for WebRTC M. Thomson January 2021 HTML TEXT PDF XML 6 ALPN Protocol Identifier

This document specifies two Application-Layer Protocol Negotiation (ALPN) labels for use with Web Real-Time Communication (WebRTC). The "webrtc" label identifies regular WebRTC: a DTLS session that is used to establish keys for the Secure Real-time Transport Protocol (SRTP) or to establish data channels using the Stream Control Transmission Protocol (SCTP) over DTLS. The "c-webrtc" label describes the same protocol, but the peers also agree to maintain the confidentiality of the media by not sharing it with other applications.

 draft-ietf-rtcweb-alpn-04 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC8833 RFC8834 Media Transport and Use of RTP in WebRTC C. Perkins M. Westerlund J. Ott January 2021 HTML TEXT PDF XML 39

The framework for Web Real-Time Communication (WebRTC) provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context and gives requirements for which RTP features, profiles, and extensions need to be supported.

 draft-ietf-rtcweb-rtp-usage-26 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC8834 RFC8835 Transports for WebRTC H. Alvestrand January 2021 HTML TEXT PDF XML 13

This document describes the data transport protocols used by Web Real-Time Communication (WebRTC), including the protocols used for interaction with intermediate boxes such as firewalls, relays, and NAT boxes.

 draft-ietf-rtcweb-transports-17 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC8835 RFC8836 Congestion Control Requirements for Interactive Real-Time Media R. Jesup Z. Sarker Editor January 2021 HTML TEXT PDF XML 10 Interactive multimedia webrtc video communication RTP/RTCP

Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g., with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled.

This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for a real-time media congestion avoidance technique.

 draft-ietf-rmcat-cc-requirements-09 INFORMATIONAL INFORMATIONAL IETF tsv rmcat 10.17487/RFC8836 RFC8837 Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS P. Jones S. Dhesikan C. Jennings D. Druta January 2021 HTML TEXT PDF XML 9 Diffserv rtcweb

Networks can provide different forwarding treatments for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of Web Real-Time Communication (WebRTC) traffic.

 draft-ietf-tsvwg-rtcweb-qos-18 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8837 RFC8838 Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol E. Ivov J. Uberti P. Saint-Andre January 2021 HTML TEXT PDF XML 22

This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to begin connectivity checks while they are still gathering candidates, by incrementally exchanging candidates over time instead of all at once. This method can considerably accelerate the process of establishing a communication session.

 draft-ietf-ice-trickle-21 RFC8863 PROPOSED STANDARD PROPOSED STANDARD IETF art ice 10.17487/RFC8838 RFC8839 Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE) M. Petit-Huguenin S. Nandakumar C. Holmberg A. Keränen R. Shpount January 2021 HTML TEXT PDF XML 38

This document describes Session Description Protocol (SDP) Offer/Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents.

This document obsoletes RFCs 5245 and 6336.

 draft-ietf-mmusic-ice-sip-sdp-39 RFC5245 RFC6336 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC8839 RFC8840 A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE) E. Ivov T. Stach E. Marocco C. Holmberg January 2021 HTML TEXT PDF XML 34 ICE trickle SIP SDP NAT

The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel.

This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). The document also defines a new SIP Info Package to support this usage together with the corresponding media type. Additionally, a new Session Description Protocol (SDP) "end-of-candidates" attribute and a new SIP option tag "trickle-ice" are defined.

 draft-ietf-mmusic-trickle-ice-sip-18 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC8840 RFC8841 Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport C. Holmberg R. Shpount S. Loreto G. Camarillo January 2021 HTML TEXT PDF XML 21 SCTP,SDP,DTLS

The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. RFC 8261 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, which is referred to as SCTP-over-DTLS.

This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values): "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". This specification also specifies how to use the new proto values with the SDP offer/answer mechanism for negotiating SCTP-over-DTLS associations.

 draft-ietf-mmusic-sctp-sdp-26 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC8841 RFC8842 Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) C. Holmberg R. Shpount January 2021 HTML TEXT PDF XML 19 SDP DTLS tls-id

This document defines the Session Description Protocol (SDP) offer/answer procedures for negotiating and establishing a Datagram Transport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFCs 5763 and 7345 by replacing common SDP offer/answer procedures with a reference to this specification.

This document defines a new SDP media-level attribute, "tls-id".

This document also defines how the "tls-id" attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFCs 4145 and 8122.

 draft-ietf-mmusic-dtls-sdp-32 RFC5763 RFC7345 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC8842 RFC8843 Negotiating Media Multiplexing Using the Session Description Protocol (SDP) C. Holmberg H. Alvestrand C. Jennings January 2021 HTML TEXT PDF XML 50 RTP SDP Bundle Multiplexing RTCWEB CLUE MMUSIC AVT WEB Browser

This specification defines a new Session Description Protocol (SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group.

This specification defines a new RTP Control Protocol (RTCP) Source Description (SDES) item and a new RTP header extension.

This specification updates RFCs 3264, 5888, and 7941.

 draft-ietf-mmusic-sdp-bundle-negotiation-54 RFC9143 RFC3264 RFC5888 RFC7941 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic http://www.rfc-editor.org/errata_search.php?rfc=8843 10.17487/RFC8843 RFC8844 Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP) M. Thomson E. Rescorla January 2021 HTML TEXT PDF XML 17 Unknown Key-Share Attack SDP DTLS-SRTP WebRTC SIP identity

This document describes unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP). Similar attacks are described on the use of DTLS-SRTP with the identity bindings used in Web Real-Time Communications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be misled about the identity of a communicating peer. This document defines mitigation techniques that implementations of RFC 8122 are encouraged to deploy.

 draft-ietf-mmusic-sdp-uks-07 RFC8122 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC8844 RFC8845 Framework for Telepresence Multi-Streams M. Duckworth Editor A. Pepperell S. Wenger January 2021 HTML TEXT PDF XML 61 Telepresence Conferencing Video-Conferencing MCU

This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting, and rendering the media streams. This protocol is used in addition to SIP signaling and Session Description Protocol (SDP) negotiation for setting up a telepresence session.

 draft-ietf-clue-framework-25 PROPOSED STANDARD PROPOSED STANDARD IETF art clue 10.17487/RFC8845 RFC8846 An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model R. Presta S P. Romano January 2021 HTML TEXT PDF XML 66 CLUE Telepresence Data Model Framework

This document provides an XML schema file for the definition of CLUE data model types. The term "CLUE" stands for "Controlling Multiple Streams for Telepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. The document defines a coherent structure for information associated with the description of a telepresence scenario.

 draft-ietf-clue-data-model-schema-17 PROPOSED STANDARD PROPOSED STANDARD IETF art clue 10.17487/RFC8846 RFC8847 Protocol for Controlling Multiple Streams for Telepresence (CLUE) R. Presta S P. Romano January 2021 HTML TEXT PDF XML 62 Telepresence Protocol Framework

The Controlling Multiple Streams for Telepresence (CLUE) protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE Working Group. A companion document, RFC 8848, delves into CLUE signaling details as well as the SIP / Session Description Protocol (SDP) session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP-over-DTLS transport. ("SCTP" stands for "Stream Control Transmission Protocol".) Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed.

 draft-ietf-clue-protocol-19 EXPERIMENTAL EXPERIMENTAL IETF art clue 10.17487/RFC8847 RFC8848 Session Signaling for Controlling Multiple Streams for Telepresence (CLUE) R. Hanton P. Kyzivat L. Xiao C. Groves January 2021 HTML TEXT PDF XML 29

This document is about Controlling Multiple Streams for Telepresence (CLUE) signaling. It specifies how the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms, such as SIP and the Session Description Protocol (SDP), to produce a telepresence call.

 draft-ietf-clue-signaling-15 EXPERIMENTAL EXPERIMENTAL IETF art clue 10.17487/RFC8848 RFC8849 Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures R. Even J. Lennox January 2021 HTML TEXT PDF XML 12

This document describes how the Real-time Transport Protocol (RTP) is used in the context of the Controlling Multiple Streams for Telepresence (CLUE) protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams, as defined in the Session Description Protocol (SDP), to CLUE Media Captures and defines a new RTP header extension (CaptureID).

 draft-ietf-clue-rtp-mapping-14 PROPOSED STANDARD PROPOSED STANDARD IETF art clue 10.17487/RFC8849 RFC8850 Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel C. Holmberg January 2021 HTML TEXT PDF XML 9 SIP SDP DTLS SCTP DATA CHANNEL DCEP DATA_CHANNEL_OPEN DATA_CHANNEL_ACK PPID TELEPRESENCE RTCWEB WEBRTC

This document defines how to use the WebRTC data channel mechanism to realize a data channel, referred to as a Controlling Multiple Streams for Telepresence (CLUE) data channel, for transporting CLUE protocol messages between two CLUE entities.

 draft-ietf-clue-datachannel-18 EXPERIMENTAL EXPERIMENTAL IETF art clue 10.17487/RFC8850 RFC8851 RTP Payload Format Restrictions A.B. Roach Editor January 2021 HTML TEXT PDF XML 26

In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol (SDP). This framework defines a new "rid" ("restriction identifier") SDP attribute to unambiguously identify the RTP streams within an RTP session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular payload types.

This specification updates RFC 4855 to give additional guidance on choice of Format Parameter (fmtp) names and their relation to the restrictions defined by this document.

 draft-ietf-mmusic-rid-15 RFC4855 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic http://www.rfc-editor.org/errata_search.php?rfc=8851 10.17487/RFC8851 RFC8852 RTP Stream Identifier Source Description (SDES) A.B. Roach S. Nandakumar P. Thatcher January 2021 HTML TEXT PDF XML 8

This document defines and registers two new Real-time Transport Control Protocol (RTCP) Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream is to be repaired using a redundancy RTP stream.

 draft-ietf-avtext-rid-09 PROPOSED STANDARD PROPOSED STANDARD IETF art avtext 10.17487/RFC8852 RFC8853 Using Simulcast in Session Description Protocol (SDP) and RTP Sessions B. Burman M. Westerlund S. Nandakumar M. Zanaty January 2021 HTML TEXT PDF XML 30

In some application scenarios, it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in the Session Description Protocol (SDP). The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source and makes an extension to SDP to indicate that those RTP streams are different simulcast formats of that media source. The SDP extension consists of a new media-level SDP attribute that expresses capability to send and/or receive simulcast RTP streams.

 draft-ietf-mmusic-sdp-simulcast-14 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC8853 RFC8854 WebRTC Forward Error Correction Requirements J. Uberti January 2021 HTML TEXT PDF XML 10 RTP FEC

This document provides information and requirements for the use of Forward Error Correction (FEC) by WebRTC implementations.

 draft-ietf-rtcweb-fec-10 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC8854 RFC8855 The Binary Floor Control Protocol (BFCP) G. Camarillo K. Drage T. Kristensen J. Ott C. Eckel January 2021 HTML TEXT PDF XML 87 floor control conference

Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.

This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.

This document obsoletes RFC 4582.

 draft-ietf-bfcpbis-rfc4582bis-16 RFC4582 PROPOSED STANDARD PROPOSED STANDARD IETF art bfcpbis 10.17487/RFC8855 RFC8856 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams G. Camarillo T. Kristensen C. Holmberg January 2021 HTML TEXT PDF XML 22 floor control BFCP SDP

This document defines the Session Description Protocol (SDP) offer/answer procedures for negotiating and establishing Binary Floor Control Protocol (BFCP) streams.

This document obsoletes RFC 4583.

 draft-ietf-bfcpbis-rfc4583bis-27 RFC4583 PROPOSED STANDARD PROPOSED STANDARD IETF art bfcpbis 10.17487/RFC8856 RFC8857 The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) V. Pascual A. Román S. Cazeaux G. Salgueiro R. Ravindranath January 2021 HTML TEXT PDF XML 12 BFCP WebSocket

The WebSocket protocol enables two-way real-time communication between clients and servers. This document specifies the use of Binary Floor Control Protocol (BFCP) as a new WebSocket subprotocol enabling a reliable transport mechanism between BFCP entities in new scenarios.

 draft-ietf-bfcpbis-bfcp-websocket-15 PROPOSED STANDARD PROPOSED STANDARD IETF art bfcpbis 10.17487/RFC8857 RFC8858 Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP) C. Holmberg January 2021 HTML TEXT PDF XML 9 RTP RTCP SDP OFFER ANSWER MUX MULTIPLEX RTCWEB WebRTC JSEP

This document defines a new Session Description Protocol (SDP) media-level attribute, 'rtcp-mux-only', that can be used by an endpoint to indicate exclusive support of RTP and RTP Control Protocol (RTCP) multiplexing. The document also updates RFC 5761 by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports.

 draft-ietf-mmusic-mux-exclusive-12 RFC5761 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC8858 RFC8859 A Framework for Session Description Protocol (SDP) Attributes When Multiplexing S. Nandakumar January 2021 HTML TEXT PDF XML 82

The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session Description Protocol (SDP) attributes when SDP is used to negotiate the usage of a single 5-tuple for sending and receiving media associated with multiple media descriptions.

This specification also categorizes the existing SDP attributes based on the framework described herein.

 draft-ietf-mmusic-sdp-mux-attributes-19 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC8859 RFC8860 Sending Multiple Types of Media in a Single RTP Session M. Westerlund C. Perkins J. Lennox January 2021 HTML TEXT PDF XML 15 Real-time Multiplexing Bundle

This document specifies how an RTP session can contain RTP streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP specifications (RFCs 3550 and 3551), and thus this document updates RFCs 3550 and 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session.

 draft-ietf-avtcore-multi-media-rtp-session-13 RFC3550 RFC3551 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8860 RFC8861 Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback J. Lennox M. Westerlund Q. Wu C. Perkins January 2021 HTML TEXT PDF XML 16 RGRP SDES XR Reporting Group

RTP allows multiple RTP streams to be sent in a single session but requires each Synchronization Source (SSRC) to send RTP Control Protocol (RTCP) reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases, most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios.

 draft-ietf-avtcore-rtp-multi-stream-optimisation-12 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8861 RFC8862 Best Practices for Securing RTP Media Signaled with SIP J. Peterson R. Barnes R. Housley January 2021 HTML TEXT PDF XML 12 SIP RTP security

Although the Session Initiation Protocol (SIP) includes a suite of security services that has been expanded by numerous specifications over the years, there is no single place that explains how to use SIP to establish confidential media sessions. Additionally, existing mechanisms have some feature gaps that need to be identified and resolved in order for them to address the pervasive monitoring threat model. This specification describes best practices for negotiating confidential media with SIP, including a comprehensive protection solution that binds the media layer to SIP layer identities.

 draft-ietf-sipbrandy-rtpsec-08 BCP0228 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF art sipbrandy 10.17487/RFC8862 RFC8863 Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC) C. Holmberg J. Uberti January 2021 HTML TEXT PDF XML 6 ICE PAC Candidate

During the process of establishing peer-to-peer connectivity, Interactive Connectivity Establishment (ICE) agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed. However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature. This document discusses when these situations can occur.

This document updates RFCs 8445 and 8838 by requiring that an ICE agent wait a minimum amount of time before declaring ICE failure, even if there are no candidate pairs left to check.

 draft-ietf-ice-pac-06 RFC8445 RFC8838 PROPOSED STANDARD PROPOSED STANDARD IETF art ice 10.17487/RFC8863 RFC8864 Negotiation Data Channels Using the Session Description Protocol (SDP) K. Drage M. Makaraju R. Ejzak J. Marcon R. Even Editor January 2021 HTML TEXT PDF XML 24

Data channel setup can be done using either the in-band Data Channel Establishment Protocol (DCEP) or some out-of-band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve an out-of-band non-DCEP negotiation for establishing a data channel.

 draft-ietf-mmusic-data-channel-sdpneg-28 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC8864 RFC8865 T.140 Real-Time Text Conversation over WebRTC Data Channels C. Holmberg G. Hellström January 2021 HTML TEXT PDF XML 18 SDP ITU-T T.140 Data Channel WebRTC real-time text

This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for real-time text using the ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140) and how the Session Description Protocol (SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as a T.140 data channel. This document updates RFC 8373 to specify its use with WebRTC data channels.

 draft-ietf-mmusic-t140-usage-data-channel-14 RFC8373 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC8865 RFC8866 SDP: Session Description Protocol A. Begen P. Kyzivat C. Perkins M. Handley January 2021 HTML TEXT PDF XML 57 Multimedia conferencing session setup signaling media SIP RTSP voip audio video streaming

This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566.

 draft-ietf-mmusic-rfc4566bis-37 RFC4566 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC8866 RFC8867 Test Cases for Evaluating Congestion Control for Interactive Real-Time Media Z. Sarker V. Singh X. Zhu M. Ramalho January 2021 HTML TEXT PDF XML 28 Multimedia Test cases Congestion Control

The Real-time Transport Protocol (RTP) is used to transmit media in multimedia telephony applications. These applications are typically required to implement congestion control. This document describes the test cases to be used in the performance evaluation of such congestion control algorithms in a controlled environment.

 draft-ietf-rmcat-eval-test-10 INFORMATIONAL INFORMATIONAL IETF tsv rmcat 10.17487/RFC8867 RFC8868 Evaluating Congestion Control for Interactive Real-Time Media V. Singh J. Ott S. Holmer January 2021 HTML TEXT PDF XML 13 RTP RTCP Congestion Control

The Real-Time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications. This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media.

 draft-ietf-rmcat-eval-criteria-14 INFORMATIONAL INFORMATIONAL IETF tsv rmcat 10.17487/RFC8868 RFC8869 Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks Z. Sarker X. Zhu J. Fu January 2021 HTML TEXT PDF XML 19 Cellular Network Wi-Fi Network Congestion Control RTP

The Real-time Transport Protocol (RTP) is a common transport choice for interactive multimedia communication applications. The performance of these applications typically depends on a well-functioning congestion control algorithm. To ensure a seamless and robust user experience, a well-designed RTP-based congestion control algorithm should work well across all access network types. This document describes test cases for evaluating performances of candidate congestion control algorithms over cellular and Wi-Fi networks.

 draft-ietf-rmcat-wireless-tests-11 INFORMATIONAL INFORMATIONAL IETF tsv rmcat 10.17487/RFC8869 RFC8870 Encrypted Key Transport for DTLS and Secure RTP C. Jennings J. Mattsson D. McGrew D. Wing F. Andreasen January 2021 HTML TEXT PDF XML 22 PERC SRTP RTP conferencing encryption

Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Transport Layer Security) and the Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints.

 draft-ietf-perc-srtp-ekt-diet-13 PROPOSED STANDARD PROPOSED STANDARD IETF art perc 10.17487/RFC8870 RFC8871 A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC) P. Jones D. Benham C. Groves January 2021 HTML TEXT PDF XML 23 PERC Private Media Framework conferencing

This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end to end within the context of a switched conferencing environment where Media Distributors are not trusted with the end-to-end media encryption keys. The solution builds upon existing security mechanisms defined for the Real-time Transport Protocol (RTP).

 draft-ietf-perc-private-media-framework-12 PROPOSED STANDARD PROPOSED STANDARD IETF art perc 10.17487/RFC8871 RFC8872 Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams M. Westerlund B. Burman C. Perkins H. Alvestrand R. Even January 2021 HTML TEXT PDF XML 36 Simulcast

The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams.

 draft-ietf-avtcore-multiplex-guidelines-12 INFORMATIONAL INFORMATIONAL IETF art avtcore 10.17487/RFC8872 RFC8873 Message Session Relay Protocol (MSRP) over Data Channels JM. Recio Editor C. Holmberg January 2021 HTML TEXT PDF XML 17 webrtc

This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for the Message Session Relay Protocol (MSRP) and how the Session Description Protocol (SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as an MSRP data channel. Two network configurations are supported: the connection of two MSRP data channel endpoints; and a gateway configuration, which connects an MSRP data channel endpoint with an MSRP endpoint that uses either TCP or TLS. This document updates RFC 4975.

 draft-ietf-mmusic-msrp-usage-data-channel-24 RFC4975 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC8873 RFC8874 Working Group GitHub Usage Guidance M. Thomson B. Stark August 2020 HTML TEXT PDF XML 20 git version control working group document editing

This document provides a set of guidelines for working groups that choose to use GitHub for their work.

 draft-ietf-git-using-github-06 INFORMATIONAL INFORMATIONAL IETF gen git 10.17487/RFC8874 RFC8875 Working Group GitHub Administration A. Cooper P. Hoffman August 2020 HTML TEXT PDF XML 6

The use of GitHub in IETF working group processes is increasing. This document describes uses and conventions for working groups that are considering starting to use GitHub. It does not mandate any processes and does not require changes to the processes used by current and future working groups not using GitHub.

 draft-ietf-git-github-wg-configuration-07 INFORMATIONAL INFORMATIONAL IETF gen git 10.17487/RFC8875 RFC8876 Non-interactive Emergency Calls B. Rosen H. Schulzrinne H. Tschofenig R. Gellens September 2020 HTML TEXT PDF XML 25 CAP Common Alerting Protocol Non-Interactive Emergency calls

Use of the Internet for emergency calling is described in RFC 6443, 'Framework for Emergency Calling Using Internet Multimedia'. In some cases of emergency calls, the transmission of application data is all that is needed, and no interactive media channel is established: a situation referred to as 'non-interactive emergency calls', where, unlike most emergency calls, there is no two-way interactive media such as voice or video or text. This document describes use of a SIP MESSAGE transaction that includes a container for the data based on the Common Alerting Protocol (CAP). That type of emergency request does not establish a session, distinguishing it from SIP INVITE, which does. Any device that needs to initiate a request for emergency services without an interactive media channel would use the mechanisms in this document.

 draft-ietf-ecrit-data-only-ea-22 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit 10.17487/RFC8876 RFC8877 Guidelines for Defining Packet Timestamps T. Mizrahi J. Fabini A. Morton September 2020 HTML TEXT PDF XML 17 Timestamps

Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as "packet timestamps" for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this document includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document.

 draft-ietf-ntp-packet-timestamps-09 INFORMATIONAL INFORMATIONAL IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=8877 10.17487/RFC8877 RFC8878 Zstandard Compression and the 'application/zstd' Media Type Y. Collet M. Kucherawy Editor February 2021 HTML TEXT PDF XML 45 compression

Zstandard, or "zstd" (pronounced "zee standard"), is a lossless data compression mechanism. This document describes the mechanism and registers a media type, content encoding, and a structured syntax suffix to be used when transporting zstd-compressed content via MIME.

Despite use of the word "standard" as part of Zstandard, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only.

This document replaces and obsoletes RFC 8478.

 draft-kucherawy-rfc8478bis-06 RFC8478 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8878 10.17487/RFC8878 RFC8879 TLS Certificate Compression A. Ghedini V. Vasiliev December 2020 HTML TEXT PDF XML 8 zlib brotli zstd

In TLS handshakes, certificate chains often take up the majority of the bytes transmitted.

This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips.

 draft-ietf-tls-certificate-compression-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC8879 RFC8880 Special Use Domain Name 'ipv4only.arpa' S. Cheshire D. Schinazi August 2020 HTML TEXT PDF XML 17 IPv6 NAT64 DNS64

NAT64 (Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) allows client devices using IPv6 to communicate with servers that have only IPv4 connectivity.

The specification for how a client discovers its local network's NAT64 prefix (RFC 7050) defines the special name 'ipv4only.arpa' for this purpose. However, in its Domain Name Reservation Considerations section (Section 8.1), that specification (RFC 7050) indicates that the name actually has no particularly special properties that would require special handling.

Consequently, despite the well-articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names registry as a name with special properties.

This document updates RFC 7050. It describes the special treatment required and formally declares the special properties of the name. It also adds similar declarations for the corresponding reverse mapping names.

 draft-cheshire-sudn-ipv4only-dot-arpa-17 RFC7050 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8880 RFC8881 Network File System (NFS) Version 4 Minor Version 1 Protocol D. Noveck Editor C. Lever August 2020 HTML TEXT PDF XML 560

This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and is considered a separate protocol.

This document obsoletes RFC 5661. It substantially revises the treatment of features relating to multi-server namespace, superseding the description of those features appearing in RFC 5661.

 draft-ietf-nfsv4-rfc5661sesqui-msns-04 RFC5661 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=8881 10.17487/RFC8881 RFC8882 DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements C. Huitema D. Kaiser September 2020 HTML TEXT PDF XML 17 Multicast DNS mDNS

DNS-SD (DNS-based Service Discovery) normally discloses information about devices offering and requesting services. This information includes hostnames, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS-based Service Discovery at a public hotspot, serious privacy problems arise. We analyze the requirements of a privacy-respecting discovery service.

 draft-ietf-dnssd-prireq-08 INFORMATIONAL INFORMATIONAL IETF int dnssd 10.17487/RFC8882 RFC8883 ICMPv6 Errors for Discarding Packets Due to Processing Limits T. Herbert September 2020 HTML TEXT PDF XML 15 extension Headers destination Options Hop-by-Hop Options

Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits. When such packets are dropped, the sender receives no indication, so it cannot take action to address the cause of discarded packets. This specification defines several new ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMPv6 error may use the information to diagnose packet loss and may modify what it sends in future packets to avoid subsequent packet discards.

 draft-ietf-6man-icmp-limits-08 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8883 RFC8884 Research Directions for Using Information-Centric Networking (ICN) in Disaster Scenarios J. Seedorf M. Arumaithurai A. Tagami K. Ramakrishnan N. Blefari-Melazzi October 2020 HTML TEXT PDF XML 17 ICN

Information-Centric Networking (ICN) is a new paradigm where the network provides users with named content instead of communication channels between hosts. This document outlines some research directions for ICN with respect to applying ICN approaches for coping with natural or human-generated, large-scale disasters. This document is a product of the Information-Centric Networking Research Group (ICNRG).

 draft-irtf-icnrg-disaster-10 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8884 RFC8885 Proxy Mobile IPv6 Extensions for Distributed Mobility Management CJ. Bernardos A. de la Oliva F. Giust JC. Zúñiga A. Mourad October 2020 HTML TEXT PDF XML 25 PMIPv6 anchor session continuity address reachability HNP CMD MAAR

Distributed Mobility Management solutions allow networks to be set up in such a way that traffic is distributed optimally and centrally deployed anchors are not relied upon to provide IP mobility support.

There are many different approaches to address Distributed Mobility Management -- for example, extending network-based mobility protocols (like Proxy Mobile IPv6) or client-based mobility protocols (like Mobile IPv6), among others. This document follows the former approach and proposes a solution based on Proxy Mobile IPv6, in which mobility sessions are anchored at the last IP hop router (called the mobility anchor and access router). The mobility anchor and access router is an enhanced access router that is also able to operate as a local mobility anchor or mobility access gateway on a per-prefix basis. The document focuses on the required extensions to effectively support the simultaneous anchoring several flows at different distributed gateways.

 draft-ietf-dmm-pmipv6-dlif-06 EXPERIMENTAL EXPERIMENTAL IETF int dmm 10.17487/RFC8885 RFC8886 Secure Device Install W. Kumari C. Doyle September 2020 HTML TEXT PDF XML 16 autoboot auto-boot autoinstall tftp install bunny

Deploying a new network device in a location where the operator has no staff of its own often requires that an employee physically travel to the location to perform the initial install and configuration, even in shared facilities with "remote-hands" (or similar) support. In many cases, this could be avoided if there were an easy way to transfer the initial configuration to a new device while still maintaining confidentiality of the configuration.

This document extends existing vendor proprietary auto-install to provide limited confidentiality to initial configuration during bootstrapping of the device.

 draft-ietf-opsawg-sdi-13 INFORMATIONAL INFORMATIONAL IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=8886 10.17487/RFC8886 RFC8887 A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket K. Murchison August 2020 HTML TEXT PDF XML 13

This document defines a binding for the JSON Meta Application Protocol (JMAP) over a WebSocket transport layer. The WebSocket binding for JMAP provides higher performance than the current HTTP binding for JMAP.

 draft-ietf-jmap-websocket-07 PROPOSED STANDARD PROPOSED STANDARD IETF art jmap 10.17487/RFC8887 RFC8888 RTP Control Protocol (RTCP) Feedback for Congestion Control Z. Sarker C. Perkins V. Singh M. Ramalho January 2021 HTML TEXT PDF XML 13 Congestion control feedback message RTP RTCP

An effective RTP congestion control algorithm requires more fine-grained feedback on packet loss, timing, and Explicit Congestion Notification (ECN) marks than is provided by the standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets. This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP feedback packets containing the information the sender needs to perform congestion control.

 draft-ietf-avtcore-cc-feedback-message-09 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8888 RFC8889 Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring G. Fioccola Editor M. Cociglio A. Sapio R. Sisto August 2020 HTML TEXT PDF XML 23 Clustered Alternate Marking Multipoint Marking Method Multipoint Coloring Technique Network Clustering

The Alternate-Marking method, as presented in RFC 8321, can only be applied to point-to-point flows, because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document generalizes and expands this methodology to measure any kind of unicast flow whose packets can follow several different paths in the network -- in wider terms, a multipoint-to-multipoint network. For this reason, the technique here described is called "Multipoint Alternate Marking".

 draft-ietf-ippm-multipoint-alt-mark-09 RFC9342 EXPERIMENTAL EXPERIMENTAL IETF tsv ippm 10.17487/RFC8889 RFC8890 The Internet is for End Users M. Nottingham August 2020 HTML TEXT PDF XML 10 stakeholder

This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users. It also explores how the IETF can more effectively achieve this.

 draft-iab-for-the-users-04 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=8890 10.17487/RFC8890 RFC8891 GOST R 34.12-2015: Block Cipher "Magma" V. Dolmatov Editor D. Baryshkov September 2020 HTML TEXT PDF XML 13 Magma Block Cipher

In addition to a new cipher with a block length of n=128 bits (referred to as "Kuznyechik" and described in RFC 7801), Russian Federal standard GOST R 34.12-2015 includes an updated version of the block cipher with a block length of n=64 bits and key length of k=256 bits, which is also referred to as "Magma". The algorithm is an updated version of an older block cipher with a block length of n=64 bits described in GOST 28147-89 (RFC 5830). This document is intended to be a source of information about the updated version of the 64-bit cipher. It may facilitate the use of the block cipher in Internet applications by providing information for developers and users of the GOST 64-bit cipher with the revised version of the cipher for encryption and decryption.

 draft-dolmatov-magma-06 RFC5830 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8891 RFC8892 Guidelines and Registration Procedures for Interface Types and Tunnel Types D. Thaler D. Romascanu August 2020 HTML TEXT PDF XML 13 ifType tunnelType Transmission Number

This document provides guidelines and procedures for those who are defining, registering, or evaluating definitions of new interface types ("ifType" values) and tunnel types. The original definition of the IANA interface type registry predated the use of IANA Considerations sections and YANG modules, so some confusion arose over time. Tunnel types were added later, with the same requirements and allocation policy as interface types. This document updates RFC 2863 and provides updated guidance for these registries.

 draft-thaler-iftype-reg-07 RFC2863 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8892 RFC8893 Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export R. Bush R. Volk J. Heitz September 2020 HTML TEXT PDF XML 5 routing security RPKI

A BGP speaker may perform Resource Public Key Infrastructure (RPKI) origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification use the 'effective origin AS' of the processed route, which may specifically be altered by the commonly available knobs, such as removing private ASes, confederation handling, and other modifications of the origin AS. This document updates RFC 6811.

 draft-ietf-sidrops-ov-egress-04 RFC6811 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC8893 RFC8894 Simple Certificate Enrolment Protocol P. Gutmann September 2020 HTML TEXT PDF XML 42

This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using Cryptographic Message Syntax (CMS, formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates.

 draft-gutmann-scep-16 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8894 10.17487/RFC8894 RFC8895 Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE) W. Roome Y. Yang November 2020 HTML TEXT PDF XML 52 ALTO

The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) provides network-related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available.

 draft-ietf-alto-incr-update-sse-22 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC8895 RFC8896 Application-Layer Traffic Optimization (ALTO) Cost Calendar S. Randriamasy R. Yang Q. Wu L. Deng N. Schwan November 2020 HTML TEXT PDF XML 35

This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO cost information service so that applications decide not only 'where' to connect but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces the ALTO Cost Calendar with which an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval. The time intervals, as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses.

 draft-ietf-alto-cost-calendar-21 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC8896 RFC8897 Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties D. Ma S. Kent September 2020 HTML TEXT PDF XML 11

This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI). It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements. Over time, this RFC will be updated to reflect changes to the requirements and guidance specified in the RFCs discussed herein.

 draft-ietf-sidrops-rp-06 INFORMATIONAL INFORMATIONAL IETF ops sidrops 10.17487/RFC8897 RFC8898 Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP) R. Shekh-Yusef C. Holmberg V. Pascual September 2020 HTML TEXT PDF XML 15 SIP OAuth 3rd party authentication Third party authentication

This document defines the "Bearer" authentication scheme for the Session Initiation Protocol (SIP) and a mechanism by which user authentication and SIP registration authorization is delegated to a third party, using the OAuth 2.0 framework and OpenID Connect Core 1.0. This document updates RFC 3261 to provide guidance on how a SIP User Agent Client (UAC) responds to a SIP 401/407 response that contains multiple WWW-Authenticate/Proxy-Authenticate header fields.

 draft-ietf-sipcore-sip-token-authnz-17 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore http://www.rfc-editor.org/errata_search.php?rfc=8898 10.17487/RFC8898 RFC8899 Packetization Layer Path MTU Discovery for Datagram Transports G. Fairhurst T. Jones M. Tüxen I. Rüngeler T. Völker September 2020 HTML TEXT PDF XML 35 UDP SCTP Transport PMTUD PLPMTUD

This document specifies Datagram Packetization Layer Path MTU Discovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole. It can also probe a network path to discover whether the maximum packet size can be increased. This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines to refer to this method for use with UDP datagrams and updates SCTP.

The document provides implementation notes for incorporating Datagram PMTUD into IETF datagram transports or applications that use datagram transports.

This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, and RFC 8261.

 draft-ietf-tsvwg-datagram-plpmtud-22 RFC4821 RFC4960 RFC6951 RFC8085 RFC8261 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8899 RFC8900 IP Fragmentation Considered Fragile R. Bonica F. Baker G. Huston R. Hinden O. Troan F. Gont September 2020 HTML TEXT PDF XML 23 IPv6 Fragmentation

This document describes IP fragmentation and explains how it introduces fragility to Internet communication.

This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators.

 draft-ietf-intarea-frag-fragile-17 BCP0230 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int intarea 10.17487/RFC8900 RFC8901 Multi-Signer DNSSEC Models S. Huque P. Aras J. Dickinson J. Vcelak D. Blacka September 2020 HTML TEXT PDF XML 13 DNSSEC Multiple Provider Signer Models

Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment may present some challenges, depending on the configuration and feature set in use. In particular, when each DNS provider independently signs zone data with their own keys, additional key-management mechanisms are necessary. This document presents deployment models that accommodate this scenario and describes these key-management requirements. These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key-management requirements on authoritative servers not involved in multi-signer configurations.

 draft-ietf-dnsop-multi-provider-dnssec-05 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC8901 RFC8902 TLS Authentication Using Intelligent Transport System (ITS) Certificates M. Msahli Editor N. Cam-Winget Editor W. Whyte Editor A. Serhrouchni H. Labiod September 2020 HTML TEXT PDF XML 13 TLS Intelligent Transport System (ITS) Certificates IEEE ETSI

The IEEE and ETSI have specified a type of end-entity certificate. This document defines an experimental change to TLS to support IEEE/ETSI certificate types to authenticate TLS entities.

 draft-msahli-ise-ieee1609-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC8902 RFC8903 Use Cases for DDoS Open Threat Signaling R. Dobbins D. Migault R. Moskowitz N. Teague L. Xia K. Nishizuka May 2021 HTML TEXT PDF XML 13

The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS Mitigation solutions. This document presents sample use cases that describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what the typical information to be exchanged is.

 draft-ietf-dots-use-cases-25 INFORMATIONAL INFORMATIONAL IETF sec dots 10.17487/RFC8903 RFC8904 DNS Whitelist (DNSWL) Email Authentication Method Extension A. Vesely September 2020 HTML TEXT PDF XML 12 DNSWL EMAIL Authentication-Results

This document describes an email authentication method compliant with RFC 8601. The method consists of looking up the sender's IP address in a DNS whitelist. This document provides information in case the method is seen in the field, suggests a useful practice, and registers the relevant keywords.

This document does not consider blacklists.

 draft-vesely-authmethod-dnswl-16 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8904 RFC8905 The 'payto' URI Scheme for Payments F. Dold C. Grothoff October 2020 HTML TEXT PDF XML 12 payments

This document defines the 'payto' Uniform Resource Identifier (URI) scheme for designating targets for payments.

A unified URI scheme for all payment target types allows applications to offer user interactions with URIs that represent payment targets, simplifying the introduction of new payment systems and applications.

 draft-dold-payto-14 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8905 RFC8906 A Common Operational Problem in DNS Servers: Failure to Communicate M. Andrews R. Bellis September 2020 HTML TEXT PDF XML 24 conformance compliance

The DNS is a query/response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long-term problems with protocol development.

This document identifies a number of common kinds of queries to which some servers either fail to respond or respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem.

The document does not look at the DNS data itself, just the structure of the responses.

 draft-ietf-dnsop-no-response-issue-23 BCP0231 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8906 10.17487/RFC8906 RFC8907 The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol T. Dahm A. Ota D.C. Medway Gash D. Carrel L. Grant September 2020 HTML TEXT PDF XML 41 TACACS+ Protocol

This document describes the Terminal Access Controller Access-Control System Plus (TACACS+) protocol, which is widely deployed today to provide Device Administration for routers, network access servers, and other networked computing devices via one or more centralized servers.

 draft-ietf-opsawg-tacacs-18 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC8907 RFC8908 Captive Portal API T. Pauly Editor D. Thakore Editor September 2020 HTML TEXT PDF XML 11

This document describes an HTTP API that allows clients to interact with a Captive Portal system. With this API, clients can discover how to get out of captivity and fetch state about their Captive Portal sessions.

 draft-ietf-capport-api-08 PROPOSED STANDARD PROPOSED STANDARD IETF art capport 10.17487/RFC8908 RFC8909 Registry Data Escrow Specification G. Lozano November 2020 HTML TEXT PDF XML 16 data escrow registry

This document specifies the format and contents of data escrow deposits targeted primarily for domain name registries. The specification is designed to be independent of the underlying objects that are being escrowed, and therefore it could also be used for purposes other than domain name registries.

 draft-ietf-regext-data-escrow-10 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8909 RFC8910 Captive-Portal Identification in DHCP and Router Advertisements (RAs) W. Kumari E. Kline September 2020 HTML TEXT PDF XML 11 Captive Portal Walled Garden Coffee-shop Hotel

In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the user can do until the user has satisfied the captive portal conditions.

This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some sort of captive portal enforcement device, and that they will need to satisfy the Captive Portal conditions to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a standardized approach for hosts to interact with such portals. While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of satisfying and interacting with the captive portal are out of scope of this document.

This document replaces RFC 7710, which used DHCP code point 160. Due to a conflict, this document specifies 114. Consequently, this document also updates RFC 3679.

 draft-ietf-capport-rfc7710bis-10 RFC7710 RFC3679 PROPOSED STANDARD PROPOSED STANDARD IETF art capport http://www.rfc-editor.org/errata_search.php?rfc=8910 10.17487/RFC8910 RFC8911 Registry for Performance Metrics M. Bagnulo B. Claise P. Eardley A. Morton A. Akhter November 2021 HTML TEXT PDF XML 35 IPPM Loss Delay

This document defines the format for the IANA Registry of Performance Metrics. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers.

 draft-ietf-ippm-metric-registry-24 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC8911 RFC8912 Initial Performance Metrics Registry Entries A. Morton M. Bagnulo P. Eardley K. D'Souza November 2021 HTML TEXT PDF XML 71

This memo defines the set of initial entries for the IANA Registry of Performance Metrics. The set includes UDP Round-Trip Latency and Loss, Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson One-Way Delay and Loss, UDP Periodic One-Way Delay and Loss, ICMP Round-Trip Latency and Loss, and TCP Round-Trip Delay and Loss.

 draft-ietf-ippm-initial-registry-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=8912 10.17487/RFC8912 RFC8913 Two-Way Active Measurement Protocol (TWAMP) YANG Data Model R. Civil A. Morton R. Rahman M. Jethanandani K. Pentikousis Editor November 2021 HTML TEXT PDF XML 60

This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP). This document defines the TWAMP data model through Unified Modeling Language (UML) class diagrams and formally specifies it using the YANG data modeling language (RFC 7950). The data model is compliant with the Network Management Datastore Architecture (NMDA).

 draft-ietf-ippm-twamp-yang-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=8913 10.17487/RFC8913 RFC8914 Extended DNS Errors W. Kumari E. Hunt R. Arends W. Hardaker D. Lawrence October 2020 HTML TEXT PDF XML 13

This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs.

 draft-ietf-dnsop-extended-error-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8914 RFC8915 Network Time Security for the Network Time Protocol D. Franke D. Sibold K. Teichel M. Dansarie R. Sundblad September 2020 HTML TEXT PDF XML 33 Integrity Authentication NTP Security

This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP).

NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTS Extension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies.

 draft-ietf-ntp-using-nts-for-ntp-28 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp 10.17487/RFC8915 RFC8916 A YANG Data Model for the Multicast Source Discovery Protocol (MSDP) X. Liu Z. Zhang Editor A. Peter M. Sivakumar F. Guo P. McAllister October 2020 HTML TEXT PDF XML 37 MSDP YANG

This document defines a YANG data model for the configuration and management of Multicast Source Discovery Protocol (MSDP) protocol operations.

 draft-ietf-pim-msdp-yang-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC8916 RFC8917 The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag R. Gellens B. Rosen October 2020 HTML TEXT PDF XML 7 location LoST emergency emergency services ecrf lvf i3

This document adds the 'LoST-Validation' service tag to the Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag IANA registry. This tag can appear in a Naming Authority Pointer (NAPTR) Domain Name System (DNS) record to assist clients of the Location-to-Service Translation (LoST) Protocol in identifying LoST servers designated for location validation. This tag and the information about its use update RFC 5222, which enables the explicit discovery of a server that supports location validation.

 draft-gellens-lost-validation-09 RFC5222 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8917 RFC8918 Invalid TLV Handling in IS-IS L. Ginsberg P. Wells T. Li T. Przygienda S. Hegde September 2020 HTML TEXT PDF XML 8 TLV IS-IS

The key to the extensibility of the Intermediate System to Intermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type-Length-Value (TLV) tuples. Although there are explicit statements in existing specifications, deployment experience has shown that there are inconsistencies in the behavior when a TLV that is disallowed in a particular Protocol Data Unit (PDU) is received.

This document discusses such cases and makes the correct behavior explicit in order to ensure that interoperability is maximized.

This document updates RFCs 5305 and 6232.

 draft-ietf-lsr-isis-invalid-tlv-03 RFC5305 RFC6232 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8918 RFC8919 IS-IS Application-Specific Link Attributes L. Ginsberg P. Psenak S. Previdi W. Henderickx J. Drake October 2020 HTML TEXT PDF XML 20

Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings.

 draft-ietf-isis-te-app-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr http://www.rfc-editor.org/errata_search.php?rfc=8919 10.17487/RFC8919 RFC8920 OSPF Application-Specific Link Attributes P. Psenak Editor L. Ginsberg W. Henderickx J. Tantsura J. Drake October 2020 HTML TEXT PDF XML 19

Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings.

 draft-ietf-ospf-te-link-attr-reuse-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr http://www.rfc-editor.org/errata_search.php?rfc=8920 10.17487/RFC8920 RFC8921 Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP) M. Boucadair Editor C. Jacquenet D. Zhang P. Georgatsos October 2020 HTML TEXT PDF XML 49 SDN Order Request Handling Automation Dynamic Provisioning CDN Interconnection Service Delivery Service Activation

This document defines the Connectivity Provisioning Negotiation Protocol (CPNP), which is designed to facilitate the dynamic negotiation of service parameters.

CPNP is a generic protocol that can be used for various negotiation purposes that include (but are not necessarily limited to) connectivity provisioning services, storage facilities, Content Delivery Networks, etc.

 draft-boucadair-connectivity-provisioning-protocol-22 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8921 RFC8922 A Survey of the Interaction between Security Protocols and Transport Services T. Enghardt T. Pauly C. Perkins K. Rose C. Wood October 2020 HTML TEXT PDF XML 19 Transport Protocols Transport Security

This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog Transport Services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a Transport Services system may need to support.

 draft-ietf-taps-transport-security-12 INFORMATIONAL INFORMATIONAL IETF tsv taps 10.17487/RFC8922 RFC8923 A Minimal Set of Transport Services for End Systems M. Welzl S. Gjessing October 2020 HTML TEXT PDF XML 44 taps transport services

This document recommends a minimal set of Transport Services offered by end systems and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303.

 draft-ietf-taps-minset-11 INFORMATIONAL INFORMATIONAL IETF tsv taps 10.17487/RFC8923 RFC8924 Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework S. Aldrin C. Pignataro Editor N. Kumar Editor R. Krishnan A. Ghanwani October 2020 HTML TEXT PDF XML 20 SFC OAM Framework

This document provides a reference framework for Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC).

 draft-ietf-sfc-oam-framework-15 INFORMATIONAL INFORMATIONAL IETF rtg sfc 10.17487/RFC8924 RFC8925 IPv6-Only Preferred Option for DHCPv4 L. Colitti J. Linkova M. Richardson T. Mrugalski October 2020 HTML TEXT PDF XML 12

This document specifies a DHCPv4 option to indicate that a host supports an IPv6-only mode and is willing to forgo obtaining an IPv4 address if the network provides IPv6 connectivity. It also updates RFC 2563 to specify DHCPv4 server behavior when the server receives a DHCPDISCOVER not containing the Auto-Configure option but containing the new option defined in this document.

 draft-ietf-dhc-v6only-08 RFC2563 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8925 RFC8926 Geneve: Generic Network Virtualization Encapsulation J. Gross Editor I. Ganga Editor T. Sridhar Editor November 2020 HTML TEXT PDF XML 34 overlay tunnel extensible variable metadata options endpoint transit

Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs.

 draft-ietf-nvo3-geneve-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg nvo3 10.17487/RFC8926 RFC8927 JSON Type Definition U. Carion November 2020 HTML TEXT PDF XML 51 data interchange format description language schema language tree grammar

This document proposes a format, called JSON Type Definition (JTD), for describing the shape of JavaScript Object Notation (JSON) messages. Its main goals are to enable code generation from schemas as well as portable validation with standardized error indicators. To this end, JTD is intentionally limited to be no more expressive than the type systems of mainstream programming languages. This intentional limitation, as well as the decision to make JTD schemas be JSON documents, makes tooling atop of JTD easier to build.

This document does not have IETF consensus and is presented here to facilitate experimentation with the concept of JTD.

 draft-ucarion-json-type-definition-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC8927 RFC8928 Address-Protected Neighbor Discovery for Low-Power and Lossy Networks P. Thubert Editor B. Sarikaya M. Sethi R. Struik November 2020 HTML TEXT PDF XML 29 Address registration Network Overlay host to router interface

This document updates the IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery (ND) protocol defined in RFCs 6775 and 8505. The new extension is called Address-Protected Neighbor Discovery (AP-ND), and it protects the owner of an address against address theft and impersonation attacks in a Low-Power and Lossy Network (LLN). Nodes supporting this extension compute a cryptographic identifier (Crypto-ID), and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with the Crypto-ID and a proof of ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation.

 draft-ietf-6lo-ap-nd-23 RFC8505 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8928 RFC8929 IPv6 Backbone Router P. Thubert Editor C.E. Perkins E. Levy-Abegnoli November 2020 HTML TEXT PDF XML 32 ND Proxy Routing Proxy Bridging Proxy proxy ND proxy-ND

This document updates RFCs 6775 and 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called "Backbone Routers". Backbone Routers are placed along the wireless edge of a backbone and federate multiple wireless links to form a single Multi-Link Subnet (MLSN).

 draft-ietf-6lo-backbone-router-20 RFC6775 RFC8505 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8929 RFC8930 On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network T. Watteyne Editor P. Thubert Editor C. Bormann November 2020 HTML TEXT PDF XML 12 6LoWPAN Fragment

This document provides generic rules to enable the forwarding of an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) fragment over a route-over network. Forwarding fragments can improve both end-to-end latency and reliability as well as reduce the buffer requirements in intermediate nodes; it may be implemented using RFC 4944 and Virtual Reassembly Buffers (VRBs).

 draft-ietf-6lo-minimal-fragment-15 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8930 RFC8931 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery P. Thubert Editor November 2020 HTML TEXT PDF XML 28 LLN Route-Over mesh IoT

This document updates RFC 4944 with a protocol that forwards individual fragments across a route-over mesh and recovers them end to end, with congestion control capabilities to protect the network.

 draft-ietf-6lo-fragment-recovery-21 RFC4944 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8931 RFC8932 Recommendations for DNS Privacy Service Operators S. Dickinson B. Overeinder R. van Rijswijk-Deij A. Mankin October 2020 HTML TEXT PDF XML 34 DNS

This document presents operational, policy, and security considerations for DNS recursive resolver operators who choose to offer DNS privacy services. With these recommendations, the operator can make deliberate decisions regarding which services to provide, as well as understanding how those decisions and the alternatives impact the privacy of users.

This document also presents a non-normative framework to assist writers of a Recursive operator Privacy Statement, analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in RFC 6841.

 draft-ietf-dprive-bcp-op-14 BCP0232 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dprive http://www.rfc-editor.org/errata_search.php?rfc=8932 10.17487/RFC8932 RFC8933 Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection R. Housley October 2020 HTML TEXT PDF XML 8 digitally sign authenticate algorithm identifier integrity

This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers in signed-data and authenticated-data content types are adequately protected.

 draft-ietf-lamps-cms-update-alg-id-protect-05 RFC5652 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8933 RFC8934 PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE H. Chen Editor Y. Zhuang Editor Q. Wu D. Ceccarelli October 2020 HTML TEXT PDF XML 23 Path Computation Element

This document defines a set of extensions to the stateful PCE Communication Protocol (PCEP) to enable Label Switched Path (LSP) path computation, activation, setup, and deletion based on scheduled time intervals for the LSP and the actual network resource usage in a centralized network environment, as stated in RFC 8413.

 draft-ietf-pce-stateful-pce-lsp-scheduling-27 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8934 RFC8935 Push-Based Security Event Token (SET) Delivery Using HTTP A. Backman Editor M. Jones Editor M. Scurtescu M. Ansari A. Nadalin November 2020 HTML TEXT PDF XML 15 JSON Web Token JWT Security Event Token SET Delivery JavaScript Object Notation JSON

This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response.

 draft-ietf-secevent-http-push-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec secevent 10.17487/RFC8935 RFC8936 Poll-Based Security Event Token (SET) Delivery Using HTTP A. Backman Editor M. Jones Editor M. Scurtescu M. Ansari A. Nadalin November 2020 HTML TEXT PDF XML 16 JSON Web Token JWT Security Event Token SET Delivery JavaScript Object Notation JSON

This specification defines how a series of Security Event Tokens (SETs) can be delivered to an intended recipient using HTTP POST over TLS initiated as a poll by the recipient. The specification also defines how delivery can be assured, subject to the SET Recipient's need for assurance.

 draft-ietf-secevent-http-poll-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec secevent 10.17487/RFC8936 RFC8937 Randomness Improvements for Security Protocols C. Cremers L. Garratt S. Smyshlyaev N. Sullivan C. Wood October 2020 HTML TEXT PDF XML 9 Security Cryptography TLS

Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable "cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs.

This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

 draft-irtf-cfrg-randomness-improvements-14 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8937 RFC8938 Deterministic Networking (DetNet) Data Plane Framework B. Varga Editor J. Farkas L. Berger A. Malis S. Bryant November 2020 HTML TEXT PDF XML 22

This document provides an overall framework for the Deterministic Networking (DetNet) data plane. It covers concepts and considerations that are generally common to any DetNet data plane specification. It describes related Controller Plane considerations as well.

 draft-ietf-detnet-data-plane-framework-06 INFORMATIONAL INFORMATIONAL IETF rtg detnet 10.17487/RFC8938 RFC8939 Deterministic Networking (DetNet) Data Plane: IP B. Varga Editor J. Farkas L. Berger D. Fedyk S. Bryant November 2020 HTML TEXT PDF XML 21 Application Endpoint Service Sub-layer Forwarding Sub-layer

This document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938).

 draft-ietf-detnet-ip-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg detnet 10.17487/RFC8939 RFC8940 Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP) A. DeKok October 2020 HTML TEXT PDF XML 7 EAP PEAP EAP-AKA EAP-SIM ERP FILS Session-ID fast reconnect TLS

RFC 5247 is updated to define and clarify EAP Session-Id derivation for multiple Extensible Authentication Protocol (EAP) methods. The derivation of Session-Id was not given for EAP Subscriber Identity Module (EAP-SIM) or EAP Authentication and Key Agreement (EAP-AKA) when using the fast reconnect exchange instead of full authentication. The derivation of Session-Id for full authentication is clarified for both EAP-SIM and EAP-AKA. The derivation of Session-Id for Protected EAP (PEAP) is also given. The definition for PEAP follows the definition for other TLS-based EAP methods.

 draft-ietf-emu-eap-session-id-07 RFC5247 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu 10.17487/RFC8940 RFC8941 Structured Field Values for HTTP M. Nottingham P-H. Kamp February 2021 HTML TEXT PDF XML 30 trailer header

This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.

 draft-ietf-httpbis-header-structure-19 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC8941 RFC8942 HTTP Client Hints I. Grigorik Y. Weiss February 2021 HTML TEXT PDF XML 10 Content Negotiation

HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers. In practice, user agents are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy.

This document defines an Accept-CH response header that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints."

 draft-ietf-httpbis-client-hints-15 EXPERIMENTAL EXPERIMENTAL IETF art httpbis 10.17487/RFC8942 RFC8943 Concise Binary Object Representation (CBOR) Tags for Date M. Jones A. Nadalin J. Richter November 2020 HTML TEXT PDF XML 6 Compact Binary Object Representation CBOR Tag Date

The Concise Binary Object Representation (CBOR), as specified in RFC 7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.

In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (date/time string as per RFC 3339) and tag 1 (POSIX "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for a date text string (as per RFC 3339) for applications needing a textual date representation within the Gregorian calendar without a time. It also defines a CBOR tag for days since the date 1970-01-01 in the Gregorian calendar for applications needing a numeric date representation without a time. This specification is the reference document for IANA registration of the CBOR tags defined.

 draft-ietf-cbor-date-tag-07 PROPOSED STANDARD PROPOSED STANDARD IETF art cbor 10.17487/RFC8943 RFC8944 A YANG Data Model for Layer 2 Network Topologies J. Dong X. Wei Q. Wu M. Boucadair A. Liu November 2020 HTML TEXT PDF XML 34

This document defines a YANG data model for Layer 2 network topologies. In particular, this data model augments the generic network and network topology data models with topology attributes that are specific to Layer 2.

 draft-ietf-i2rs-yang-l2-network-topology-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg i2rs http://www.rfc-editor.org/errata_search.php?rfc=8944 10.17487/RFC8944 RFC8945 Secret Key Transaction Authentication for DNS (TSIG) F. Dupont S. Morris P. Vixie D. Eastlake 3rd O. Gudmundsson B. Wellington November 2020 HTML TEXT PDF XML 22

This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server.

No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism.

This document obsoletes RFCs 2845 and 4635.

 draft-ietf-dnsop-rfc2845bis-09 RFC2845 RFC4635 STD0093 INTERNET STANDARD INTERNET STANDARD IETF ops dnsop 10.17487/RFC8945 RFC8946 Personal Assertion Token (PASSporT) Extension for Diverted Calls J. Peterson February 2021 HTML TEXT PDF XML 17 SIP STIR Identity

The Personal Assertion Token (PASSporT) is specified in RFC 8225 to convey cryptographically signed information about the people involved in personal communications. This document extends PASSporT to include an indication that a call has been diverted from its original destination to a new one. This information can greatly improve the decisions made by verification services in call forwarding scenarios. Also specified here is an encapsulation mechanism for nesting a PASSporT within another PASSporT that assists relying parties in some diversion scenarios.

This document updates RFC 8224.

 draft-ietf-stir-passport-divert-09 RFC8224 PROPOSED STANDARD PROPOSED STANDARD IETF art stir 10.17487/RFC8946 RFC8947 Link-Layer Address Assignment Mechanism for DHCPv6 B. Volz T. Mrugalski C. Bernardos December 2020 HTML TEXT PDF XML 18

In certain environments, e.g., large-scale virtualization deployments, new devices are created in an automated manner. Such devices may have their link-layer addresses assigned in an automated fashion. With sufficient scale, the likelihood of a collision using random assignment without duplication detection is not acceptable. Therefore, an allocation mechanism is required. This document proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments where preassigned link-layer address assignments (such as by a manufacturer) are not possible or are unnecessary.

 draft-ietf-dhc-mac-assign-09 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8947 RFC8948 Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6 CJ. Bernardos A. Mourad December 2020 HTML TEXT PDF XML 16 IEEE 802c ELI SAI AAI MAC address LLADDR

The IEEE originally structured the 48-bit Media Access Control (MAC) address space in such a way that half of it was reserved for local use. In 2017, the IEEE published a new standard (IEEE Std 802c) with a new optional Structured Local Address Plan (SLAP). It specifies different assignment approaches in four specified regions of the local MAC address space.

The IEEE is developing protocols to assign addresses (IEEE P802.1CQ). There is also work in the IETF on specifying a new mechanism that extends DHCPv6 operation to handle the local MAC address assignments.

This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server so that the server may allocate MAC addresses in the quadrant requested by the relay or client. A new DHCPv6 option (QUAD) is defined for this purpose.

 draft-ietf-dhc-slap-quadrant-12 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8948 RFC8949 Concise Binary Object Representation (CBOR) C. Bormann P. Hoffman December 2020 HTML TEXT PDF XML 66 parser decoder encoder binary format data interchange format JSON

The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.

This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.

 draft-ietf-cbor-7049bis-16 RFC7049 STD0094 INTERNET STANDARD INTERNET STANDARD IETF art cbor 10.17487/RFC8949 RFC8950 Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop S. Litkowski S. Agrawal K. Ananthamurthy K. Patel November 2020 HTML TEXT PDF XML 12 bgp mvpn vpnv4 vpnv6

Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a next-hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI.

This document specifies the extensions necessary to allow the advertising of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the next hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the next hop to determine which of the protocols the address actually belongs to, and a BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 next hop. This document obsoletes RFC 5549.

 draft-ietf-bess-rfc5549revision-06 RFC5549 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8950 RFC8951 Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1 M. Richardson T. Werner W. Pan November 2020 HTML TEXT PDF XML 13 CSRattributes BRSKI RFC7030

This document updates RFC 7030: Enrollment over Secure Transport to resolve some errata that were reported and that have proven to cause interoperability issues when RFC 7030 was extended.

This document deprecates the specification of "Content-Transfer-Encoding" headers for Enrollment over Secure Transport (EST) endpoints. This document fixes some syntactical errors in ASN.1 that were present.

 draft-ietf-lamps-rfc7030est-clarify-10 RFC7030 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8951 RFC8952 Captive Portal Architecture K. Larose D. Dolson H. Liu November 2020 HTML TEXT PDF XML 19 Captive Portal Architecture Wifi Wi-Fi Wireless Roaming Mobile API

This document describes a captive portal architecture. Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution.

 draft-ietf-capport-architecture-10 INFORMATIONAL INFORMATIONAL IETF art capport 10.17487/RFC8952 RFC8953 Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report K. Moriarty December 2020 HTML TEXT PDF XML 14 Network Management Attack Response CARIS Incident

The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop, sponsored by the Internet Society, took place on 28 February and 1 March 2019 in Cambridge, Massachusetts, USA. Participants spanned regional, national, international, and enterprise Computer Security Incident Response Teams (CSIRTs), operators, service providers, network and security operators, transport operators and researchers, incident response researchers, vendors, and participants from standards communities. This workshop continued the work started at the first CARIS workshop, with a focus on scaling incident prevention and detection as the Internet industry moves to a stronger and a more ubiquitous deployment of session encryption.

 draft-moriarty-caris2-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8953 RFC8954 Online Certificate Status Protocol (OCSP) Nonce Extension M. Sahni Editor November 2020 HTML TEXT PDF XML 6 OCSP Nonce Length OCSP Nonce Randomness

This document specifies the updated format of the Nonce extension in the Online Certificate Status Protocol (OCSP) request and response messages. OCSP is used to check the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. This document updates RFC 6960.

 draft-ietf-lamps-ocsp-nonce-05 RFC6960 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8954 RFC8955 Dissemination of Flow Specification Rules C. Loibl S. Hares R. Raszuk D. McPherson M. Bacher December 2020 HTML TEXT PDF XML 36

This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.

It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification.

This document obsoletes both RFC 5575 and RFC 7674.

 draft-ietf-idr-rfc5575bis-27 RFC5575 RFC7674 RFC8956 RFC9117 RFC9184 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8955 RFC8956 Dissemination of Flow Specification Rules for IPv6 C. Loibl Editor R. Raszuk Editor S. Hares Editor December 2020 HTML TEXT PDF XML 19 BGP Flow Specification V6

"Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets.

This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry.

 draft-ietf-idr-flow-spec-v6-22 RFC8955 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8956 RFC8957 Synonymous Flow Label Framework S. Bryant M. Chen G. Swallow S. Sivabalan G. Mirsky January 2021 HTML TEXT PDF XML 9 MPLS Flow Label

RFC 8372 ("MPLS Flow Identification Considerations") describes the requirement for introducing flow identities within the MPLS architecture. This document describes a method of accomplishing this by using a technique called "Synonymous Flow Labels" in which labels that mimic the behavior of other labels provide the identification service. These identifiers can be used to trigger per-flow operations on the packet at the receiving label switching router.

 draft-ietf-mpls-sfl-framework-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8957 RFC8958 Updated Registration Rules for URI.ARPA T. Hardie December 2020 HTML TEXT PDF XML 3

This document updates RFC 3405 by removing references to the IETF tree from the procedures for requesting that a URI scheme be inserted into the URI.ARPA zone.

 draft-hardie-dispatch-rfc3405-update-04 RFC3405 BCP0065 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8958 RFC8959 The "secret-token" URI Scheme M. Nottingham January 2021 HTML TEXT PDF XML 5 bearer token token scanning

This document registers the "secret-token" URI scheme to aid in the identification of authentication tokens.

 draft-nottingham-how-did-that-get-into-the-repo-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8959 10.17487/RFC8959 RFC8960 A YANG Data Model for MPLS Base T. Saad K. Raza R. Gandhi X. Liu V. Beeram December 2020 HTML TEXT PDF XML 29 MPLS YANG Data Model MPLS Model MPLS RIB MPLS Routing Information Base

This document contains a specification of the MPLS base YANG data model. The MPLS base YANG data model serves as a base framework for configuring and managing an MPLS switching subsystem on an MPLS-enabled router. It is expected that other MPLS YANG data models (e.g., MPLS Label Switched Path (LSP) static, LDP, or RSVP-TE YANG data models) will augment the MPLS base YANG data model.

 draft-ietf-mpls-base-yang-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=8960 10.17487/RFC8960 RFC8961 Requirements for Time-Based Loss Detection M. Allman November 2020 HTML TEXT PDF XML 12 retransmission timeout packet loss loss detection requirements

Many protocols must detect packet loss for various reasons (e.g., to ensure reliability using retransmissions or to understand the level of congestion along a network path). While many mechanisms have been designed to detect loss, ultimately, protocols can only count on the passage of time without delivery confirmation to declare a packet "lost". Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness; therefore, no implementation suits all situations. This document provides high-level requirements for time-based loss detectors appropriate for general use in unicast communication across the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation.

 draft-ietf-tcpm-rto-consider-17 BCP0233 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tcpm 10.17487/RFC8961 RFC8962 Establishing the Protocol Police G. Grover N. ten Oever C. Cath S. Sahib April 1 2021 HTML TEXT PDF XML 7

One mantra of the IETF is, "We are not the Protocol Police." However, to ensure that protocols are implemented and deployed in full compliance with the IETF's standards, it is important to set up a body that is responsible for assessing and enforcing correct protocol behavior.

This document formally establishes the Protocol Police. It defines the body and sets out what aspects of IETF protocols they will police. This document acts as a point of reference for networking engineers, law enforcement officials, government representatives, and others. It also provides advice on how to report issues to the Protocol Police.

 draft-protocolpolice-01 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8962 10.17487/RFC8962 RFC8963 Evaluation of a Sample of RFCs Produced in 2018 C. Huitema January 2021 HTML TEXT PDF XML 42

This document presents the author's effort to understand the delays involved in publishing an idea in the IETF or through the Independent Stream, from the first individual draft to the publication of the RFC. We analyze a set of randomly chosen RFCs approved in 2018, looking for history and delays. We also use two randomly chosen sets of RFCs published in 2008 and 1998 for comparing delays seen in 2018 to those observed 10 or 20 years ago. The average RFC in the 2018 sample was produced in 3 years and 4 months, of which 2 years and 10 months were spent in the working group, 3 to 4 months for IETF consensus and IESG review, and 3 to 4 months in RFC production. The main variation in RFC production delays comes from the AUTH48 phase.

We also measure the number of citations of the chosen RFC using Semantic Scholar, and compare citation counts with what we know about deployment. We show that citation counts indicate academic interest, but correlate only loosely with deployment or usage of the specifications. Counting web references could complement that.

 draft-huitema-rfc-eval-project-07 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8963 10.17487/RFC8963 RFC8964 Deterministic Networking (DetNet) Data Plane: MPLS B. Varga Editor J. Farkas L. Berger A. Malis S. Bryant J. Korhonen January 2021 HTML TEXT PDF XML 27 detnet mpls preof pref peof prf pef pof protection replication elimination

This document specifies the Deterministic Networking (DetNet) data plane when operating over an MPLS Packet Switched Network. It leverages existing pseudowire (PW) encapsulations and MPLS Traffic Engineering (MPLS-TE) encapsulations and mechanisms. This document builds on the DetNet architecture and data plane framework.

 draft-ietf-detnet-mpls-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg detnet 10.17487/RFC8964 RFC8965 Applicability of the Babel Routing Protocol J. Chroboczek January 2021 HTML TEXT PDF XML 10 distance-vector loop starvation Bellman-Ford routing routing protocol wireless mesh network IGP

Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. This document describes a number of niches where Babel has been found to be useful and that are arguably not adequately served by more mature protocols.

 draft-ietf-babel-applicability-10 INFORMATIONAL INFORMATIONAL IETF rtg babel 10.17487/RFC8965 RFC8966 The Babel Routing Protocol J. Chroboczek D. Schinazi January 2021 HTML TEXT PDF XML 54 Bellman-Ford IGP loop-avoidance mesh network

Babel is a loop-avoiding, distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol and obsoletes RFC 6126 and RFC 7557.

 draft-ietf-babel-rfc6126bis-20 RFC6126 RFC7557 PROPOSED STANDARD PROPOSED STANDARD IETF rtg babel 10.17487/RFC8966 RFC8967 MAC Authentication for the Babel Routing Protocol C. Dô W. Kolodziejak J. Chroboczek January 2021 HTML TEXT PDF XML 17 routing protocol authentication replay replay protection

This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document obsoletes RFC 7298.

 draft-ietf-babel-hmac-12 RFC7298 PROPOSED STANDARD PROPOSED STANDARD IETF rtg babel 10.17487/RFC8967 RFC8968 Babel Routing Protocol over Datagram Transport Layer Security A. Décimo D. Schinazi J. Chroboczek January 2021 HTML TEXT PDF XML 9

The Babel Routing Protocol does not contain any means to authenticate neighbours or provide integrity or confidentiality for messages sent between them. This document specifies a mechanism to ensure these properties using Datagram Transport Layer Security (DTLS).

 draft-ietf-babel-dtls-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg babel 10.17487/RFC8968 RFC8969 A Framework for Automating Service and Network Management with YANG Q. Wu Editor M. Boucadair Editor D. Lopez C. Xie L. Geng January 2021 HTML TEXT PDF XML 40 Model Driven YANG Data Model automation service delivery notification SDN

Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance.

This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF.

 draft-ietf-opsawg-model-automation-framework-10 INFORMATIONAL INFORMATIONAL IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=8969 10.17487/RFC8969 RFC8970 IMAP4 Extension: Message Preview Generation M. Slusarz December 2020 HTML TEXT PDF XML 10 IMAP4 FETCH PREVIEW

This document specifies an Internet Message Access Protocol (IMAP) protocol extension that allows a client to request a server-generated abbreviated text representation of message data that is useful as a contextual preview of the entire message.

 draft-ietf-extra-imap-fetch-preview-10 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8970 RFC8971 Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN) S. Pallagatti Editor G. Mirsky Editor S. Paragiri V. Govindan M. Mudigonda December 2020 HTML TEXT PDF XML 9 BFD BFD for VXLAN

This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Virtual eXtensible Local Area Network (VXLAN) tunnels used to form an overlay network.

 draft-ietf-bfd-vxlan-16 INFORMATIONAL INFORMATIONAL IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=8971 10.17487/RFC8971 RFC8972 Simple Two-Way Active Measurement Protocol Optional Extensions G. Mirsky X. Min H. Nydell R. Foote A. Masputra E. Ruffini January 2021 HTML TEXT PDF XML 29 IPPM Performance Measurement

This document describes optional extensions to Simple Two-way Active Measurement Protocol (STAMP) that enable measurement of performance metrics. The document also defines a STAMP Test Session Identifier and thus updates RFC 8762.

 draft-ietf-ippm-stamp-option-tlv-10 RFC8762 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC8972 RFC8973 DDoS Open Threat Signaling (DOTS) Agent Discovery M. Boucadair T. Reddy.K January 2021 HTML TEXT PDF XML 22 Automation Provisioning Configuration Location Deployment Multihoming DDoS Security

This document specifies mechanisms to configure DDoS Open Threat Signaling (DOTS) clients with their DOTS servers. The discovery procedure also covers the DOTS signal channel Call Home. It can be useful to know the appropriate DOTS server for a given location in order to engage mitigation actions. This is true even in cases where the DOTS client cannot localize the attack: cases where it only knows that some resources are under attack and that help is needed.

 draft-ietf-dots-server-discovery-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec dots 10.17487/RFC8973 RFC8974 Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) K. Hartke M. Richardson January 2021 HTML TEXT PDF XML 20 6tisch minimal-security

This document provides considerations for alleviating Constrained Application Protocol (CoAP) clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths.

This document updates RFCs 7252 and 8323 with an extended definition of the "TKL" field in the CoAP message header.

 draft-ietf-core-stateless-08 RFC7252 RFC8323 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8974 RFC8975 Network Coding for Satellite Systems N. Kuhn Editor E. Lochin Editor January 2021 HTML TEXT PDF XML 14 SATCOM coding techniques

This document is a product of the Coding for Efficient Network Communications Research Group (NWCRG). It conforms to the directions found in the NWCRG taxonomy (RFC 8406).

The objective is to contribute to a larger deployment of Network Coding techniques in and above the network layer in satellite communication systems. This document also identifies open research issues related to the deployment of Network Coding in satellite communication systems.

 draft-irtf-nwcrg-network-coding-satellites-15 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8975 RFC8976 Message Digest for DNS Zones D. Wessels P. Barber M. Weinberg W. Kumari W. Hardaker February 2021 HTML TEXT PDF XML 31 DNS DNSSEC Checksum Hash Zone Transfer

This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes.

ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets (DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications.

As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones.

 draft-ietf-dnsop-dns-zone-digest-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8976 10.17487/RFC8976 RFC8977 Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging M. Loffredo M. Martinelli S. Hollenbeck January 2021 HTML TEXT PDF XML 23 RDAP Sorting Paging

The Registration Data Access Protocol (RDAP) does not include core functionality for clients to provide sorting and paging parameters for control of large result sets. This omission can lead to unpredictable server processing of queries and client processing of responses. This unpredictability can be greatly reduced if clients can provide servers with their preferences for managing large responses. This document describes RDAP query extensions that allow clients to specify their preferences for sorting and paging result sets.

 draft-ietf-regext-rdap-sorting-and-paging-20 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8977 RFC8978 Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events F. Gont J. Žorž R. Patterson March 2021 HTML TEXT PDF XML 11

In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit and reliable signaling of that condition (such as when a Customer Edge router crashes and reboots without knowledge of the previously employed prefixes), hosts on the local network may continue using stale prefixes for an unacceptably long time (on the order of several days), thus resulting in connectivity problems. This document describes this issue and discusses operational workarounds that may help to improve network robustness. Additionally, it highlights areas where further work may be needed.

 draft-ietf-v6ops-slaac-renum-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC8978 RFC8979 Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH) B. Sarikaya D. von Hugo M. Boucadair February 2021 HTML TEXT PDF XML 11 subscriber policy policy enforcement subscriber policy quota identification implicit identification service chain service function chain sfc SFP service function path classification 5G traffic steering

This document defines the Subscriber and Performance Policy Identifier Context Headers. These Variable-Length Context Headers can be carried in the Network Service Header (NSH) and are used to inform Service Functions (SFs) of subscriber- and performance-related information for the sake of policy enforcement and appropriate Service Function Chaining (SFC) operations. The structure of each Context Header and their use and processing by NSH-aware nodes are described.

 draft-ietf-sfc-serviceid-header-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sfc 10.17487/RFC8979 RFC8980 Report from the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol Development J. Arkko T. Hardie February 2021 HTML TEXT PDF XML 16

The Design Expectations vs. Deployment Reality in Protocol Development Workshop was convened by the Internet Architecture Board (IAB) in June 2019. This report summarizes the workshop's significant points of discussion and identifies topics that may warrant further consideration.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 draft-iab-dedr-report-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8980 RFC8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 F. Gont S. Krishnan T. Narten R. Draves February 2021 HTML TEXT PDF XML 20 privacy anonymity unlinkability crypto-based address changing

This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941.

 draft-ietf-6man-rfc4941bis-12 RFC4941 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8981 RFC8982 Registration Data Access Protocol (RDAP) Partial Response M. Loffredo M. Martinelli February 2021 HTML TEXT PDF XML 12 RDAP Partial response

The Registration Data Access Protocol (RDAP) does not include capabilities to request partial responses. Servers will only return full responses that include all of the information that a client is authorized to receive. A partial response capability that limits the amount of information returned, especially in the case of search queries, could bring benefits to both clients and servers. This document describes an RDAP query extension that allows clients to specify their preference for obtaining a partial response.

 draft-ietf-regext-rdap-partial-response-16 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8982 RFC8983 Internet Key Exchange Protocol Version 2 (IKEv2) Notification Status Types for IPv4/IPv6 Coexistence M. Boucadair February 2021 HTML TEXT PDF XML 7 IPv4 service continuity VoLTE Handover Service continuity 3GPP IPv6 transition TS.24302 PDP context PDP type

This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) notification status types to better manage IPv4 and IPv6 coexistence by allowing the responder to signal to the initiator which address families are allowed.

This document updates RFC 7296.

 draft-ietf-ipsecme-ipv6-ipv4-codes-06 RFC7296 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8983 RFC8984 JSCalendar: A JSON Representation of Calendar Data N. Jenkins R. Stepanek July 2021 HTML TEXT PDF XML 73 JSON iCalendar calendar events date time

This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based on JSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate.

 draft-ietf-calext-jscalendar-32 PROPOSED STANDARD PROPOSED STANDARD IETF art calext http://www.rfc-editor.org/errata_search.php?rfc=8984 10.17487/RFC8984 RFC8985 The RACK-TLP Loss Detection Algorithm for TCP Y. Cheng N. Cardwell N. Dukkipati P. Jha February 2021 HTML TEXT PDF XML 29 TCP Loss Recovery Reordering

This document presents the RACK-TLP loss detection algorithm for TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgments (SACKs) and has two parts. Recent Acknowledgment (RACK) starts fast recovery quickly using time-based inferences derived from acknowledgment (ACK) feedback, and Tail Loss Probe (TLP) leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used duplicate acknowledgment (DupAck) threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DupAck threshold approach.

 draft-ietf-tcpm-rack-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC8985 RFC8986 Segment Routing over IPv6 (SRv6) Network Programming C. Filsfils Editor P. Camarillo Editor J. Leddy D. Voyer S. Matsushima Z. Li February 2021 HTML TEXT PDF XML 40 SRv6 Segment Routing IPv6 Segment Routing

The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.

Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.

This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.

 draft-ietf-spring-srv6-network-programming-28 PROPOSED STANDARD PROPOSED STANDARD IETF rtg spring http://www.rfc-editor.org/errata_search.php?rfc=8986 10.17487/RFC8986 RFC8987 DHCPv6 Prefix Delegating Relay Requirements I. Farrer N. Kottapalli M. Hunek R. Patterson February 2021 HTML TEXT PDF XML 11 Prefix Delegation DHCPv6 relay Delegating router Requesting router Delegating relay

This document describes operational problems that are known to occur when using DHCPv6 relays with prefix delegation. These problems can prevent successful delegation and result in routing failures. To address these problems, this document provides necessary functional requirements for operating DHCPv6 relays with prefix delegation.

It is recommended that any network operator using DHCPv6 prefix delegation with relays ensure that these requirements are followed on their networks.

 draft-ietf-dhc-dhcpv6-pd-relay-requirements-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8987 RFC8989 Additional Criteria for Nominating Committee Eligibility B. Carpenter S. Farrell February 2021 HTML TEXT PDF XML 10

This document defines a process experiment under RFC 3933 that temporarily updates the criteria for qualifying volunteers to participate in the IETF Nominating Committee. It therefore also updates the criteria for qualifying signatories to a community recall petition. The purpose is to make the criteria more flexible in view of increasing remote participation in the IETF and a reduction in face-to-face meetings. The experiment is of fixed duration and will apply to one, or at most two, consecutive Nominating Committee cycles, starting in 2021. This document temporarily varies the rules in RFC 8713.

 draft-carpenter-eligibility-expand-10 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC8989 RFC8990 GeneRic Autonomic Signaling Protocol (GRASP) C. Bormann B. Carpenter Editor B. Liu Editor May 2021 HTML TEXT PDF XML 55 autonomic networking autonomous operation self-management

This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and Autonomic Service Agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features.

 draft-ietf-anima-grasp-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops anima 10.17487/RFC8990 RFC8991 GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API) B. Carpenter B. Liu Editor W. Wang X. Gong May 2021 HTML TEXT PDF XML 29 Autonomic Networking Autonomous Operation Self-Management

This document is a conceptual outline of an Application Programming Interface (API) for the GeneRic Autonomic Signaling Protocol (GRASP). Such an API is needed for Autonomic Service Agents (ASAs) calling the GRASP protocol module to exchange Autonomic Network messages with other ASAs. Since GRASP is designed to support asynchronous operations, the API will need to be adapted according to the support for asynchronicity in various programming languages and operating systems.

 draft-ietf-anima-grasp-api-10 INFORMATIONAL INFORMATIONAL IETF ops anima 10.17487/RFC8991 RFC8992 Autonomic IPv6 Edge Prefix Management in Large-Scale Networks S. Jiang Editor Z. Du B. Carpenter Q. Sun May 2021 HTML TEXT PDF XML 19 Autonomic Networking Prefix Management

This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of this document is to use it for validation of the design of various components of the Autonomic Networking Infrastructure.

 draft-ietf-anima-prefix-management-07 INFORMATIONAL INFORMATIONAL IETF ops anima http://www.rfc-editor.org/errata_search.php?rfc=8992 10.17487/RFC8992 RFC8993 A Reference Model for Autonomic Networking M. Behringer Editor B. Carpenter T. Eckert L. Ciavaglia J. Nobre May 2021 HTML TEXT PDF XML 26 autonomic networking autonomous operation self-management infrastructure intent autonomic control plane

This document describes a reference model for Autonomic Networking for managed networks. It defines the behavior of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure.

 draft-ietf-anima-reference-model-10 INFORMATIONAL INFORMATIONAL IETF ops anima 10.17487/RFC8993 RFC8994 An Autonomic Control Plane (ACP) T. Eckert Editor M. Behringer Editor S. Bjarnason May 2021 HTML TEXT PDF XML 128 addressing-scheme ANI autonomic networking autonomous operation BRSKI certificate Data-Plane domain DTLS DULL EST GRASP IDevID inband IPsec IPv6 LDevID loopback-interface NOC OAM out-of-band registrar renewal RPL secure self-management ULA VPN VRF

Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured.

 draft-ietf-anima-autonomic-control-plane-30 PROPOSED STANDARD PROPOSED STANDARD IETF ops anima http://www.rfc-editor.org/errata_search.php?rfc=8994 10.17487/RFC8994 RFC8995 Bootstrapping Remote Secure Key Infrastructure (BRSKI) M. Pritikin M. Richardson T. Eckert M. Behringer K. Watsen May 2021 HTML TEXT PDF XML 116 Autonomic Networking Autonomous Operation Self-Management voucher-request onboarding zero-touch voucher RFC8366 voucher IoT-onboarding IoT-zero-touch network-join

This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well.

 draft-ietf-anima-bootstrapping-keyinfra-45 PROPOSED STANDARD PROPOSED STANDARD IETF ops anima http://www.rfc-editor.org/errata_search.php?rfc=8995 10.17487/RFC8995 RFC8996 Deprecating TLS 1.0 and TLS 1.1 K. Moriarty S. Farrell March 2021 HTML TEXT PDF XML 18 TLS deprecate TLSv1.0 TLSv1.1

This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance.

This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.

This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.

 draft-ietf-tls-oldversions-deprecate-12 RFC5469 RFC7507 RFC3261 RFC3329 RFC3436 RFC3470 RFC3501 RFC3552 RFC3568 RFC3656 RFC3749 RFC3767 RFC3856 RFC3871 RFC3887 RFC3903 RFC3943 RFC3983 RFC4097 RFC4111 RFC4162 RFC4168 RFC4217 RFC4235 RFC4261 RFC4279 RFC4497 RFC4513 RFC4531 RFC4540 RFC4582 RFC4616 RFC4642 RFC4680 RFC4681 RFC4712 RFC4732 RFC4743 RFC4744 RFC4785 RFC4791 RFC4823 RFC4851 RFC4964 RFC4975 RFC4976 RFC4992 RFC5018 RFC5019 RFC5023 RFC5024 RFC5049 RFC5054 RFC5091 RFC5158 RFC5216 RFC5238 RFC5263 RFC5281 RFC5364 RFC5415 RFC5422 RFC5456 RFC5734 RFC5878 RFC5953 RFC6012 RFC6042 RFC6083 RFC6084 RFC6176 RFC6347 RFC6353 RFC6367 RFC6460 RFC6614 RFC6739 RFC6749 RFC6750 RFC7030 RFC7465 RFC7525 RFC7562 RFC7568 RFC8261 RFC8422 BCP0195 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=8996 10.17487/RFC8996 RFC8997 Deprecation of TLS 1.1 for Email Submission and Access L. Velvindron S. Farrell March 2021 HTML TEXT PDF XML 6

This specification updates the current recommendation for the use of the Transport Layer Security (TLS) protocol to provide confidentiality of email between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server. This document updates RFC 8314.

 draft-ietf-uta-tls-for-email-05 RFC8314 PROPOSED STANDARD PROPOSED STANDARD IETF art uta 10.17487/RFC8997 RFC8998 ShangMi (SM) Cipher Suites for TLS 1.3 P. Yang March 2021 HTML TEXT PDF XML 13 cryptography encryption authentication network security

This document specifies how to use the ShangMi (SM) cryptographic algorithms with Transport Layer Security (TLS) protocol version 1.3.

The use of these algorithms with TLS 1.3 is not endorsed by the IETF. The SM algorithms are becoming mandatory in China, so this document provides a description of how to use the SM algorithms with TLS 1.3 and specifies a profile of TLS 1.3 so that implementers can produce interworking implementations.

 draft-yang-tls-tls13-sm-suites-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8998 RFC8999 Version-Independent Properties of QUIC M. Thomson May 2021 HTML TEXT PDF XML 9 crypto next generation protocol secure transport UDP invariants

This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol.

 draft-ietf-quic-invariants-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv quic 10.17487/RFC8999 RFC9000 QUIC: A UDP-Based Multiplexed and Secure Transport J. Iyengar Editor M. Thomson Editor May 2021 HTML TEXT PDF XML 151 multipath next generations protocol sctp++ secure smart tcp/2 tcpng transport transport-ng

This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.

 draft-ietf-quic-transport-34 PROPOSED STANDARD PROPOSED STANDARD IETF tsv quic http://www.rfc-editor.org/errata_search.php?rfc=9000 10.17487/RFC9000 RFC9001 Using TLS to Secure QUIC M. Thomson Editor S. Turner Editor May 2021 HTML TEXT PDF XML 52 crypto opportunistic encryption plaintext quic

This document describes how Transport Layer Security (TLS) is used to secure QUIC.

 draft-ietf-quic-tls-34 PROPOSED STANDARD PROPOSED STANDARD IETF tsv quic 10.17487/RFC9001 RFC9002 QUIC Loss Detection and Congestion Control J. Iyengar Editor I. Swett Editor May 2021 HTML TEXT PDF XML 42 bbr delay-sensitive congestion control fec loss-tolerant congestion control next generation

This document describes loss detection and congestion control mechanisms for QUIC.

 draft-ietf-quic-recovery-34 PROPOSED STANDARD PROPOSED STANDARD IETF tsv quic 10.17487/RFC9002 RFC9003 Extended BGP Administrative Shutdown Communication J. Snijders J. Heitz J. Scudder A. Azimov January 2021 HTML TEXT PDF XML 7 BGP cease shutdown

This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short free-form message to describe why a BGP session was shut down or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication of up to 255 octets to improve communication using multibyte character sets.

 draft-ietf-idr-rfc8203bis-08 RFC8203 RFC4486 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC9003 RFC9004 Updates for the Back-to-Back Frame Benchmark in RFC 2544 A. Morton May 2021 HTML TEXT PDF XML 13 Buffer size Buffer delay Correction Factor

Fundamental benchmarking methodologies for network interconnect devices of interest to the IETF are defined in RFC 2544. This memo updates the procedures of the test to measure the Back-to-Back Frames benchmark of RFC 2544, based on further experience.

This memo updates Section 26.4 of RFC 2544.

 draft-ietf-bmwg-b2b-frame-04 RFC2544 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC9004 RFC9005 Path Computation Element Communication Protocol (PCEP) Extension for Associating Policies and Label Switched Paths (LSPs) S. Litkowski S. Sivabalan J. Tantsura J. Hardwick C. Li March 2021 HTML TEXT PDF XML 15 Association Policy

This document introduces a simple mechanism to associate policies with a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP). The extension allows a PCEP speaker to advertise to a PCEP peer that a particular LSP belongs to a particular Policy Association Group (PAG).

 draft-ietf-pce-association-policy-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC9005 RFC9006 TCP Usage Guidance in the Internet of Things (IoT) C. Gomez J. Crowcroft M. Scharf March 2021 HTML TEXT PDF XML 24 constrained node networks CNNs HTTP CoAP MQTT 6LoWPAN 6Lo IEEE 802.15.4 Bluetooth Low Energy Contiki uIP

This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characteristic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding trade-offs. The objective is to help embedded developers with decisions on which TCP features to use.

 draft-ietf-lwig-tcp-constrained-node-networks-13 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC9006 RFC9007 Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP) R. Ouazana Editor March 2021 HTML TEXT PDF XML 13 JMAP JSON email MDN

This document specifies a data model for handling Message Disposition Notifications (MDNs) (see RFC 8098) in the JSON Meta Application Protocol (JMAP) (see RFCs 8620 and 8621).

 draft-ietf-jmap-mdn-17 PROPOSED STANDARD PROPOSED STANDARD IETF art jmap 10.17487/RFC9007 RFC9008 Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane M.I. Robles M. Richardson P. Thubert April 2021 HTML TEXT PDF XML 49 RPL Option 6LoWPAN RFC 6553

This document looks at different data flows through Low-Power and Lossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RPL Packet Information (RPI) Option Type (RFC 6553), RPL Source Route Header (RFC 6554), and IPv6-in-IPv6 encapsulation are required in the data plane. This analysis provides the basis upon which to design efficient compression of these headers. This document updates RFC 6553 by adding a change to the RPI Option Type. Additionally, this document updates RFC 6550 by defining a flag in the DODAG Information Object (DIO) Configuration option to indicate this change and updates RFC 8138 as well to consider the new Option Type when the RPL Option is decompressed.

 draft-ietf-roll-useofrplinfo-44 RFC6553 RFC6550 RFC8138 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=9008 10.17487/RFC9008 RFC9009 Efficient Route Invalidation R.A. Jadhav Editor P. Thubert R.N. Sahoo Z. Cao April 2021 HTML TEXT PDF XML 21 NPDAO DCO no-path route cleanup

This document explains the problems associated with the use of No-Path Destination Advertisement Object (NPDAO) messaging in RFC 6550 and also discusses the requirements for an optimized route invalidation messaging scheme. Further, this document specifies a new proactive route invalidation message called the "Destination Cleanup Object" (DCO), which fulfills requirements for optimized route invalidation messaging.

 draft-ietf-roll-efficient-npdao-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC9009 RFC9010 Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves P. Thubert Editor M. Richardson April 2021 HTML TEXT PDF XML 36 IPv6 ND Redistribution

This specification provides a mechanism for a host that implements a routing-agnostic interface based on IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery to obtain reachability services across a network that leverages RFC 6550 for its routing operations. It updates RFCs 6550, 6775, and 8505.

 draft-ietf-roll-unaware-leaves-30 RFC6550 RFC6775 RFC8505 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=9010 10.17487/RFC9010 RFC9011 Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN O. Gimenez Editor I. Petrov Editor April 2021 HTML TEXT PDF XML 26 header compression compression fragmentation static context rule-based LPWAN LPWANs low power low-power LoRa LoRaWAN IoT Internet of Things adaptation layer UDP IPv6 sensor network wireless sensor network 802.15.4 constrained network constrained node constrained-node network SCHC

The Static Context Header Compression and fragmentation (SCHC) specification (RFC 8724) describes generic header compression and fragmentation techniques for Low-Power Wide Area Network (LPWAN) technologies. SCHC is a generic mechanism designed for great flexibility so that it can be adapted for any of the LPWAN technologies.

This document defines a profile of SCHC (RFC 8724) for use in LoRaWAN networks and provides elements such as efficient parameterization and modes of operation.

 draft-ietf-lpwan-schc-over-lorawan-14 PROPOSED STANDARD PROPOSED STANDARD IETF int lpwan 10.17487/RFC9011 RFC9012 The BGP Tunnel Encapsulation Attribute K. Patel G. Van de Velde S. Sangli J. Scudder April 2021 HTML TEXT PDF XML 41 BGP

This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels.

This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired.

 draft-ietf-idr-tunnel-encaps-22 RFC5512 RFC5566 RFC5640 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC9012 RFC9013 OSPF Advertisement of Tunnel Encapsulations X. Xu Editor B. Decraene Editor R. Raszuk L. Contreras L. Jalil April 2021 HTML TEXT PDF XML 10 BGP

Networks use tunnels for a variety of reasons. A large variety of tunnel types are defined, and the tunnel encapsulator router needs to select a type of tunnel that is supported by the tunnel decapsulator router. This document defines how to advertise, in OSPF Router Information Link State Advertisements (LSAs), the list of tunnel encapsulations supported by the tunnel decapsulator.

 draft-ietf-ospf-encapsulation-cap-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=9013 10.17487/RFC9013 RFC9014 Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks J. Rabadan Editor S. Sathappan W. Henderickx A. Sajassi J. Drake May 2021 HTML TEXT PDF XML 24 DCI UMR Unknown MAC Route I-ES I-ESI

This document describes how Network Virtualization Overlays (NVOs) can be connected to a Wide Area Network (WAN) in order to extend the Layer 2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running Ethernet Virtual Private Networks (EVPNs) and other Layer 2 VPN (L2VPN) technologies used in the WAN, such as Virtual Private LAN Services (VPLSs), VPLS extensions for Provider Backbone Bridging (PBB-VPLS), EVPN, or PBB-EVPN. It also describes how the existing technical specifications apply to the interconnection and extends the EVPN procedures needed in some cases. In particular, this document describes how EVPN routes are processed on Gateways (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the Interconnect Ethernet Segment (I-ES), to provide multihoming. This document also describes the use of the Unknown MAC Route (UMR) to avoid issues of a Media Access Control (MAC) scale on Data Center Network Virtualization Edge (NVE) devices.

 draft-ietf-bess-dci-evpn-overlay-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC9014 RFC9015 BGP Control Plane for the Network Service Header in Service Function Chaining A. Farrel J. Drake E. Rosen J. Uttaro L. Jalil June 2021 HTML TEXT PDF XML 59 Service Function Chaining Service Function Chain Network Service Header Service Function Service Function Forwarder Service Function Path Service Function Path Route Service Function Instance Service Function Instance Route Service Function Type Control Plane

This document describes the use of BGP as a control plane for networks that support service function chaining. The document introduces a new BGP address family called the "Service Function Chain (SFC) Address Family Identifier / Subsequent Address Family Identifier" (SFC AFI/SAFI) with two Route Types. One Route Type is originated by a node to advertise that it hosts a particular instance of a specified service function. This Route Type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other Route Type is used by a controller to advertise the paths of "chains" of service functions and give a unique designator to each such path so that they can be used in conjunction with the Network Service Header (NSH) defined in RFC 8300.

This document adopts the service function chaining architecture described in RFC 7665.

 draft-ietf-bess-nsh-bgp-control-plane-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC9015 RFC9016 Flow and Service Information Model for Deterministic Networking (DetNet) B. Varga J. Farkas R. Cummings Y. Jiang D. Fedyk March 2021 HTML TEXT PDF XML 20 DetNet Flow and Service Information Model

This document describes the flow and service information model for Deterministic Networking (DetNet). These models are defined for IP and MPLS DetNet data planes.

 draft-ietf-detnet-flow-information-model-14 INFORMATIONAL INFORMATIONAL IETF rtg detnet 10.17487/RFC9016 RFC9017 Special-Purpose Label Terminology L. Andersson K. Kompella A. Farrel April 2021 HTML TEXT PDF XML 8 MPLS Extended Special-Purpose Label Base Special-Purpose Label Reserved Label Entropy Label Indicator

This document discusses and recommends terminology that may be used when MPLS Special-Purpose Labels (SPLs) are specified and documented.

This document applies that terminology change to the relevant IANA registry and also clarifies the use of the Entropy Label Indicator (7) when immediately preceded by the Extension Label (15).

This document updates RFCs 3032 and 7274.

 draft-ietf-mpls-spl-terminology-06 RFC3032 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC9017 RFC9018 Interoperable Domain Name System (DNS) Server Cookies O. Sury W. Toorop D. Eastlake 3rd M. Andrews April 2021 HTML TEXT PDF XML 16 Client Hash

DNS Cookies, as specified in RFC 7873, are a lightweight DNS transaction security mechanism that provide limited protection to DNS servers and clients against a variety of denial-of-service amplification, forgery, or cache-poisoning attacks by off-path attackers.

This document updates RFC 7873 with precise directions for creating Server Cookies so that an anycast server set including diverse implementations will interoperate with standard clients, with suggestions for constructing Client Cookies in a privacy-preserving fashion, and with suggestions on how to update a Server Secret. An IANA registry listing the methods and associated pseudorandom function suitable for creating DNS Server Cookies has been created with the method described in this document as the first and, as of the time of publication, only entry.

 draft-ietf-dnsop-server-cookies-05 RFC7873 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC9018 RFC9019 A Firmware Update Architecture for Internet of Things B. Moran H. Tschofenig D. Brown M. Meriac April 2021 HTML TEXT PDF XML 24 IoT update software firmware constrained Secure Boot

Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality.

In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates.

 draft-ietf-suit-architecture-16 INFORMATIONAL INFORMATIONAL IETF sec suit 10.17487/RFC9019 RFC9020 YANG Data Model for Segment Routing S. Litkowski Y. Qu A. Lindem P. Sarkar J. Tantsura May 2021 HTML TEXT PDF XML 39 mpls

This document defines three YANG data models. The first is for Segment Routing (SR) configuration and operation, which is to be augmented by different Segment Routing data planes. The next is a YANG data model that defines a collection of generic types and groupings for SR. The third module defines the configuration and operational states for the Segment Routing MPLS data plane.

 draft-ietf-spring-sr-yang-30 PROPOSED STANDARD PROPOSED STANDARD IETF rtg spring 10.17487/RFC9020 RFC9021 Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE) D. Atkins May 2021 HTML TEXT PDF XML 11 COSE WalnutDSA

This document specifies the conventions for using the Walnut Digital Signature Algorithm (WalnutDSA) for digital signatures with the CBOR Object Signing and Encryption (COSE) syntax. WalnutDSA is a lightweight, quantum-resistant signature scheme based on Group Theoretic Cryptography with implementation and computational efficiency of signature verification in constrained environments, even on 8- and 16-bit platforms.

The goal of this publication is to document a way to use the lightweight, quantum-resistant WalnutDSA signature algorithm in COSE in a way that would allow multiple developers to build compatible implementations. As of this publication, the security properties of WalnutDSA have not been evaluated by the IETF and its use has not been endorsed by the IETF.

WalnutDSA and the Walnut Digital Signature Algorithm are trademarks of Veridify Security Inc.

 draft-atkins-suit-cose-walnutdsa-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9021 RFC9022 Domain Name Registration Data (DNRD) Objects Mapping G. Lozano J. Gould C. Thippeswamy May 2021 HTML TEXT PDF XML 169 data escrow registry domain name domain name registration data

This document specifies the format, contents, and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry.

 draft-ietf-regext-dnrd-objects-mapping-11 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC9022 RFC9023 Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN) B. Varga Editor J. Farkas A. Malis S. Bryant June 2021 HTML TEXT PDF XML 10

This document specifies the Deterministic Networking IP data plane when operating over a Time-Sensitive Networking (TSN) sub-network. This document does not define new procedures or processes. Whenever this document makes statements or recommendations, these are taken from normative text in the referenced RFCs.

 draft-ietf-detnet-ip-over-tsn-07 INFORMATIONAL INFORMATIONAL IETF rtg detnet 10.17487/RFC9023 RFC9024 Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS B. Varga Editor J. Farkas A. Malis S. Bryant D. Fedyk June 2021 HTML TEXT PDF XML 12 interconnecting TSN networks

This document specifies the Deterministic Networking data plane when Time-Sensitive Networking (TSN) networks are interconnected over a DetNet MPLS network.

 draft-ietf-detnet-tsn-vpn-over-mpls-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg detnet 10.17487/RFC9024 RFC9025 Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP B. Varga Editor J. Farkas L. Berger A. Malis S. Bryant April 2021 HTML TEXT PDF XML 8

This document specifies the MPLS Deterministic Networking (DetNet) data plane operation and encapsulation over an IP network. The approach is based on the operation of MPLS-over-UDP technology.

 draft-ietf-detnet-mpls-over-udp-ip-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg detnet 10.17487/RFC9025 RFC9026 Multicast VPN Fast Upstream Failover T. Morin Editor R. Kebler Editor G. Mirsky Editor April 2021 HTML TEXT PDF XML 22 BFD P2MP

This document defines Multicast Virtual Private Network (VPN) extensions and procedures that allow fast failover for upstream failures by allowing downstream Provider Edges (PEs) to consider the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow. The fast failover is enabled by using "Bidirectional Forwarding Detection (BFD) for Multipoint Networks" (RFC 8562) and the new BGP Attribute, BFD Discriminator. Also, this document introduces a new BGP Community, Standby PE, extending BGP Multicast VPN (MVPN) routing so that a C-multicast route can be advertised toward a Standby Upstream PE.

 draft-ietf-bess-mvpn-fast-failover-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC9026 RFC9027 Assertion Values for Resource Priority Header and SIP Priority Header Claims in Support of Emergency Services Networks M. Dolly C. Wendt June 2021 HTML TEXT PDF XML 7 rph PASSport esnet

This document adds new assertion values for a Resource Priority Header ("rph") claim and a new SIP Priority Header ("sph") claim for protection of the "psap-callback" value as part of the "rph" Personal Assertion Token (PASSporT) extension in support of the security of emergency services networks for emergency call origination and callback.

 draft-ietf-stir-rph-emergency-services-07 PROPOSED STANDARD PROPOSED STANDARD IETF art stir 10.17487/RFC9027 RFC9028 Native NAT Traversal Mode for the Host Identity Protocol A. Keränen J. Melén M. Komu Editor July 2021 HTML TEXT PDF XML 55 HIP NAT NAT traversal

This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages instead of ICE for all NAT traversal procedures due to the kernel-space dependencies of HIP.

 draft-ietf-hip-native-nat-traversal-33 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC9028 RFC9029 Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries A. Farrel June 2021 HTML TEXT PDF XML 5 BGP-LS IANA

RFC 7752 defines the Border Gateway Protocol - Link State (BGP-LS). IANA created a registry consistent with that document called "Border Gateway Protocol - Link State (BGP-LS) Parameters" with a number of subregistries. The allocation policy applied by IANA for those registries is "Specification Required", as defined in RFC 8126.

This document updates RFC 7752 by changing the allocation policy for all of the registries to "Expert Review" and by updating the guidance to the designated experts.

 draft-ietf-idr-bgp-ls-registry-06 RFC7752 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC9029 RFC9030 An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH) P. Thubert Editor May 2021 HTML TEXT PDF XML 57 deterministic wireless radio mesh

This document describes a network architecture that provides low-latency, low-jitter, and high-reliability packet delivery. It combines a high-speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of low-power wireless deterministic applications.

 draft-ietf-6tisch-architecture-30 INFORMATIONAL INFORMATIONAL IETF int 6tisch 10.17487/RFC9030 RFC9031 Constrained Join Protocol (CoJP) for 6TiSCH M. Vučinić Editor J. Simon K. Pister M. Richardson May 2021 HTML TEXT PDF XML 41 bootstrapping onboarding oscore

This document describes the minimal framework required for a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network. The framework requires that the pledge and the JRC (Join Registrar/Coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework.

 draft-ietf-6tisch-minimal-security-15 PROPOSED STANDARD PROPOSED STANDARD IETF int 6tisch 10.17487/RFC9031 RFC9032 Encapsulation of 6TiSCH Join and Enrollment Information Elements D. Dujovne Editor M. Richardson May 2021 HTML TEXT PDF XML 10 BRSKI enroll zero-touch DODAG balancing LLN balancing

In the Time-Slotted Channel Hopping (TSCH) mode of IEEE Std 802.15.4, opportunities for broadcasts are limited to specific times and specific channels. Routers in a TSCH network transmit Enhanced Beacon (EB) frames to announce the presence of the network. This document provides a mechanism by which additional information critical for new nodes (pledges) and long-sleeping nodes may be carried within the EB in order to conserve use of broadcast opportunities.

 draft-ietf-6tisch-enrollment-enhanced-beacon-14 PROPOSED STANDARD PROPOSED STANDARD IETF int 6tisch 10.17487/RFC9032 RFC9033 6TiSCH Minimal Scheduling Function (MSF) T. Chang Editor M. Vučinić X. Vilajosana S. Duquennoy D. Dujovne May 2021 HTML TEXT PDF XML 20 TSCH communication schedule 6P

This specification defines the "IPv6 over the TSCH mode of IEEE 802.15.4" (6TiSCH) Minimal Scheduling Function (MSF). This Scheduling Function describes both the behavior of a node when joining the network and how the communication schedule is managed in a distributed fashion. MSF is built upon the 6TiSCH Operation Sublayer Protocol (6P) and the minimal security framework for 6TiSCH.

 draft-ietf-6tisch-msf-18 PROPOSED STANDARD PROPOSED STANDARD IETF int 6tisch 10.17487/RFC9033 RFC9034 Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) L. Thomas S. Anamalamudi S.V.R. Anand M. Hegde C. Perkins June 2021 HTML TEXT PDF XML 19 Routing header Timestamp

This document specifies a new type for the 6LoWPAN routing header containing the deadline time for data packets, designed for use over constrained networks. The deadline time enables forwarding and scheduling decisions for time-critical machine-to-machine (M2M) applications running on Internet-enabled devices that operate within time-synchronized networks. This document also specifies a representation for the deadline time values in such networks.

 draft-ietf-6lo-deadline-time-05 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC9034 RFC9035 A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header P. Thubert Editor L. Zhao April 2021 HTML TEXT PDF XML 9 IoT Header Compression Source Routing Header Hop-by-Hop Header RPL artifacts

This document updates RFC 8138 by defining a bit in the Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration option to indicate whether compression is used within the RPL Instance and to specify the behavior of nodes compliant with RFC 8138 when the bit is set and unset.

 draft-ietf-roll-turnon-rfc8138-18 RFC8138 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC9035 RFC9036 Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy R. Gellens June 2021 HTML TEXT PDF XML 4

This document changes the policy of the "Location-to-Service Translation (LoST) Location Profiles" IANA registry established by RFC 5222 from Standards Action to Specification Required. This allows standards development organizations (SDOs) other than the IETF to add new values.

 draft-ietf-ecrit-location-profile-registry-policy-02 RFC5222 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit 10.17487/RFC9036 RFC9037 Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN) B. Varga Editor J. Farkas A. Malis S. Bryant June 2021 HTML TEXT PDF XML 11 sub-network flow mapping

This document specifies the Deterministic Networking (DetNet) MPLS data plane when operating over an IEEE 802.1 Time-Sensitive Networking (TSN) sub-network. This document does not define new procedures or processes. Whenever this document makes statements or recommendations, they are taken from normative text in the referenced RFCs.

 draft-ietf-detnet-mpls-over-tsn-07 INFORMATIONAL INFORMATIONAL IETF rtg detnet 10.17487/RFC9037 RFC9038 Extensible Provisioning Protocol (EPP) Unhandled Namespaces J. Gould M. Casanova May 2021 HTML TEXT PDF XML 21 login greeting URI namespace response general poll object-level command-response signal signaling

The Extensible Provisioning Protocol (EPP), as defined in RFC 5730, includes a method for the client and server to determine the objects to be managed during a session and the object extensions to be used during a session. The services are identified using namespace URIs, and an "unhandled namespace" is one that is associated with a service not supported by the client. This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs and that maintains compliance with the negotiated services defined in RFC 5730.

 draft-ietf-regext-unhandled-namespaces-08 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC9038 RFC9039 Uniform Resource Names for Device Identifiers J. Arkko C. Jennings Z. Shelby June 2021 HTML TEXT PDF XML 15 URN device identifier IMEI 1-Wire MAC address EUI-48 EUI-64

This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage or in equipment inventories. A URN-based representation can be passed along in applications that need the information.

 draft-ietf-core-dev-urn-11 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC9039 RFC9040 TCP Control Block Interdependence J. Touch M. Welzl S. Islam July 2021 HTML TEXT PDF XML 29

This memo provides guidance to TCP implementers that is intended to help improve connection convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of sharing TCP state, as typically represented in TCP Control Blocks, among similar concurrent or consecutive connections.

 draft-ietf-tcpm-2140bis-11 RFC2140 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC9040 RFC9041 Updating the MPLS Label Switched Paths (LSPs) Ping Parameters IANA Registry L. Andersson M. Chen C. Pignataro T. Saad July 2021 HTML TEXT PDF XML 31

This document updates RFCs 8029 and 8611, both of which define IANA registries for MPLS Label Switched Path (LSP) Ping. In particular, the registration procedure "Private Use" (previously known as "Vendor Private Use") has been changed to "First Come First Served" for the TLV and sub-TLV registries.

It also updates the description of the procedures for the responses sent when an unknown or erroneous code point is found. The updates are to clarify and align this namespace with recent developments, e.g., aligning terminology with RFC 8126 instead of the now obsoleted RFC 5226 (both titled "Guidelines for Writing an IANA Considerations Section in RFCs").

 draft-ietf-mpls-lsp-ping-registries-update-11 RFC8029 RFC8611 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC9041 RFC9042 Sieve Email Filtering: Delivery by MAILBOXID B. Gondwana Editor June 2021 HTML TEXT PDF XML 8 sieve email

The OBJECTID capability of IMAP (RFC 8474) allows clients to identify mailboxes by a unique identifier that survives renaming.

This document extends the Sieve email filtering language (RFC 5228) to allow using that same unique identifier as a target for fileinto rules and for testing the existence of mailboxes.

 draft-ietf-extra-sieve-mailboxid-09 RFC5228 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC9042 RFC9043 FFV1 Video Coding Format Versions 0, 1, and 3 M. Niedermayer D. Rice J. Martinez August 2021 HTML TEXT PDF XML 51 video preservation storage ffmpeg lossless compression

This document defines FFV1, a lossless, intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format.

 draft-ietf-cellar-ffv1-20 INFORMATIONAL INFORMATIONAL IETF art cellar 10.17487/RFC9043 RFC9044 Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) R. Housley June 2021 HTML TEXT PDF XML 9 Authentication Message Authentication Code

This document specifies the conventions for using the AES-GMAC Message Authentication Code algorithm with the Cryptographic Message Syntax (CMS) as specified in RFC 5652.

 draft-ietf-lamps-cms-aes-gmac-alg-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC9044 RFC9045 Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) R. Housley June 2021 HTML TEXT PDF XML 9 Authentication Message Authentication Code Password-Based Message Authentication Code

This document updates the cryptographic algorithm requirements for the Password-Based Message Authentication Code in the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) specified in RFC 4211.

 draft-ietf-lamps-crmf-update-algs-07 RFC4211 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC9045 RFC9046 Babel Information Model B. Stark M. Jethanandani June 2021 HTML TEXT PDF XML 20 Babel

The Babel information model provides structured data elements for a Babel implementation reporting its current state and may allow limited configuration of some such data elements. This information model can be used as a basis for creating data models under various data modeling regimes. This information model only includes parameters and parameter values useful for managing Babel over IPv6.

 draft-ietf-babel-information-model-14 INFORMATIONAL INFORMATIONAL IETF rtg babel 10.17487/RFC9046 RFC9047 Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN) J. Rabadan Editor S. Sathappan K. Nagaraj W. Lin June 2021 HTML TEXT PDF XML 10 proxy-ARP proxy-ND proxy-ARP/ND ARP/ND extended community

This document defines an Extended Community that is advertised along with an Ethernet Virtual Private Network (EVPN) Media Access Control (MAC) / IP Advertisement route and carries information relevant to the Address Resolution Protocol (ARP) / Neighbor Discovery (ND) resolution so that an EVPN Provider Edge (PE) implementing a proxy-ARP/ND function in broadcast domains (BDs) or an ARP/ND function on Integrated Routing and Bridging (IRB) interfaces can reply to ARP Requests or Neighbor Solicitation (NS) messages with the correct information.

 draft-ietf-bess-evpn-na-flags-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC9047 RFC9048 Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') J. Arkko V. Lehtovirta V. Torvinen P. Eronen October 2021 HTML TEXT PDF XML 40 EAP AKA AKA' 3GPP

The 3GPP mobile network Authentication and Key Agreement (AKA) is an authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC 5448 (EAP-AKA') was an improved version of EAP-AKA.

This document is the most recent specification of EAP-AKA', including, for instance, details about and references related to operating EAP-AKA' in 5G networks.

EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' also updates the algorithm used in hash functions, as it employs SHA-256 / HMAC-SHA-256 instead of SHA-1 / HMAC-SHA-1, which is used in EAP-AKA.

This version of the EAP-AKA' specification defines the protocol behavior for both 4G and 5G deployments, whereas the previous version defined protocol behavior for 4G deployments only. While EAP-AKA' as defined in RFC 5448 is not obsolete, this document defines the most recent and fully backwards-compatible specification of EAP-AKA'. This document updates both RFCs 4187 and 5448.

 draft-ietf-emu-rfc5448bis-10 RFC5448 RFC4187 INFORMATIONAL INFORMATIONAL IETF sec emu 10.17487/RFC9048 RFC9049 Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken) S. Dawkins Editor June 2021 HTML TEXT PDF XML 36 PAN

This document is a product of the Path Aware Networking Research Group (PANRG). At the first meeting of the PANRG, the Research Group agreed to catalog and analyze past efforts to develop and deploy Path Aware techniques, most of which were unsuccessful or at most partially successful, in order to extract insights and lessons for Path Aware networking researchers.

This document contains that catalog and analysis.

 draft-irtf-panrg-what-not-to-do-19 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC9049 RFC9050 Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs Z. Li S. Peng M. Negi Q. Zhao C. Zhou July 2021 HTML TEXT PDF XML 33 SDN CCI Central Control

The Path Computation Element (PCE) is a core component of Software-Defined Networking (SDN) systems.

A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label-forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible.

This document specifies the procedures and Path Computation Element Communication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static LSP.

 draft-ietf-pce-pcep-extension-for-pce-controller-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC9050 RFC9051 Internet Message Access Protocol (IMAP) - Version 4rev2 A. Melnikov Editor B. Leiba Editor August 2021 HTML TEXT PDF XML 163 IMAP4rev2 imap

The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server.

IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.

IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409.

 draft-ietf-extra-imap4rev2-30 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF art extra http://www.rfc-editor.org/errata_search.php?rfc=9051 10.17487/RFC9051 RFC9052 CBOR Object Signing and Encryption (COSE): Structures and Process J. Schaad August 2022 HTML TEXT PDF XML 66 Object Security COSE Constrained Devices

Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.

This document, along with RFC 9053, obsoletes RFC 8152.

 draft-ietf-cose-rfc8152bis-struct-15 RFC8152 RFC9338 STD0096 INTERNET STANDARD INTERNET STANDARD IETF sec cose 10.17487/RFC9052 RFC9053 CBOR Object Signing and Encryption (COSE): Initial Algorithms J. Schaad August 2022 HTML TEXT PDF XML 41 Object Security COSE Constrained Devices AES AES-GCM AES-CCM ECDSA EdDSA ECC HSS-LMS AES-KW ECDH HMAC CMAC Cryptography

Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).

This document, along with RFC 9052, obsoletes RFC 8152.

 draft-ietf-cose-rfc8152bis-algs-12 RFC8152 INFORMATIONAL INFORMATIONAL IETF sec cose 10.17487/RFC9053 RFC9054 CBOR Object Signing and Encryption (COSE): Hash Algorithms J. Schaad August 2022 HTML TEXT PDF XML 9 SHA-1 Hash Algorithm SHA-2 Hash Algorithm SHAKE Algorithm

The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers.

 draft-ietf-cose-hash-algs-09 INFORMATIONAL INFORMATIONAL IETF sec cose 10.17487/RFC9054 RFC9055 Deterministic Networking (DetNet) Security Considerations E. Grossman Editor T. Mizrahi A. Hacker June 2021 HTML TEXT PDF XML 50 DetNet security

A DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates and bounded latency (including bounded latency variation, i.e., "jitter"). As a result, securing a DetNet requires that in addition to the best practice security measures taken for any mission-critical network, additional security measures may be needed to secure the intended operation of these novel service properties.

This document addresses DetNet-specific security considerations from the perspectives of both the DetNet system-level designer and component designer. System considerations include a taxonomy of relevant threats and attacks, and associations of threats versus use cases and service properties. Component-level considerations include ingress filtering and packet arrival-time violation detection.

This document also addresses security considerations specific to the IP and MPLS data plane technologies, thereby complementing the Security Considerations sections of those documents.

 draft-ietf-detnet-security-16 INFORMATIONAL INFORMATIONAL IETF rtg detnet 10.17487/RFC9055 RFC9056 Deterministic Networking (DetNet) Data Plane: IP over MPLS B. Varga Editor L. Berger D. Fedyk S. Bryant J. Korhonen October 2021 HTML TEXT PDF XML 11 sub-network subnetwork

This document specifies the Deterministic Networking data plane when encapsulating IP over an MPLS packet-switched network.

 draft-ietf-detnet-ip-over-mpls-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg detnet 10.17487/RFC9056 RFC9057 Email Author Header Field D. Crocker June 2021 HTML TEXT PDF XML 7 domain email security messaging dkim spf authentication reporting conformance author origination original from sender

Internet mail defines the From: header field to indicate the author of the message's content and the Sender: field to indicate who initially handled the message on the author's behalf. The Sender: field is optional if it has the same information as the From: field. This was not a problem until development of stringent protections on use of the From: field. It has prompted Mediators, such as mailing lists, to modify the From: field to circumvent mail rejection caused by those protections. In effect, the From: field has become dominated by its role as a handling identifier.

The current specification augments the altered use of the From: field by specifying the Author: field, which ensures identification of the original author of the message and is not subject to modification by Mediators. This document is published as an Experimental RFC to assess community interest, functional efficacy, and technical adequacy.

 draft-crocker-email-author-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC9057 RFC9058 Multilinear Galois Mode (MGM) S. Smyshlyaev Editor V. Nozdrunov V. Shishkin E. Griboedova June 2021 HTML TEXT PDF XML 25 authenticated encryption mode of operation AEAD

Multilinear Galois Mode (MGM) is an Authenticated Encryption with Associated Data (AEAD) block cipher mode based on the Encrypt-then-MAC (EtM) principle. MGM is defined for use with 64-bit and 128-bit block ciphers.

MGM has been standardized in Russia. It is used as an AEAD mode for the GOST block cipher algorithms in many protocols, e.g., TLS 1.3 and IPsec. This document provides a reference for MGM to enable review of the mechanisms in use and to make MGM available for use with any block cipher.

 draft-smyshlyaev-mgm-20 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9058 RFC9059 Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs) R. Gandhi Editor C. Barth B. Wen June 2021 HTML TEXT PDF XML 20 RSVP-TE LSP Co-routed LSP Reverse LSP

This document defines Path Computation Element Communication Protocol (PCEP) extensions for grouping two unidirectional MPLS-TE Label Switched Paths (LSPs), one in each direction in the network, into an associated bidirectional LSP. These PCEP extensions can be applied either using a stateful PCE for both PCE-initiated and PCC-initiated LSPs or using a stateless PCE. The PCEP procedures defined are applicable to the LSPs using RSVP-TE for signaling.

 draft-ietf-pce-association-bidir-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC9059 RFC9060 Secure Telephone Identity Revisited (STIR) Certificate Delegation J. Peterson September 2021 HTML TEXT PDF XML 12 SIP Secure Origin Identification Communication Security Certificates Public Key Infrastructure Real-Time Communication

The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing. This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR.

 draft-ietf-stir-cert-delegation-04 PROPOSED STANDARD PROPOSED STANDARD IETF art stir 10.17487/RFC9060 RFC9061 A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN) R. Marin-Lopez G. Lopez-Millan F. Pereniguez-Garcia July 2021 HTML TEXT PDF XML 90 NSF SDN IPsec

This document describes how to provide IPsec-based flow protection (integrity and confidentiality) by means of an Interface to Network Security Function (I2NSF) Controller. It considers two main well-known scenarios in IPsec: gateway-to-gateway and host-to-host. The service described in this document allows the configuration and monitoring of IPsec Security Associations (IPsec SAs) from an I2NSF Controller to one or several flow-based Network Security Functions (NSFs) that rely on IPsec to protect data traffic.

This document focuses on the I2NSF NSF-Facing Interface by providing YANG data models for configuring the IPsec databases, namely Security Policy Database (SPD), Security Association Database (SAD), Peer Authorization Database (PAD), and Internet Key Exchange Version 2 (IKEv2). This allows IPsec SA establishment with minimal intervention by the network administrator. This document defines three YANG modules, but it does not define any new protocol.

 draft-ietf-i2nsf-sdn-ipsec-flow-protection-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec i2nsf 10.17487/RFC9061 RFC9062 Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM) S. Salam A. Sajassi S. Aldrin J. Drake D. Eastlake 3rd June 2021 HTML TEXT PDF XML 16 PBB-EVPN fault management performance management

This document specifies the requirements and reference framework for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM). The requirements cover the OAM aspects of EVPN and Provider Backbone Bridge EVPN (PBB-EVPN). The framework defines the layered OAM model encompassing the EVPN service layer, network layer, underlying Packet Switched Network (PSN) transport layer, and link layer but focuses on the service and network layers.

 draft-ietf-bess-evpn-oam-req-frmwk-10 INFORMATIONAL INFORMATIONAL IETF rtg bess 10.17487/RFC9062 RFC9063 Host Identity Protocol Architecture R. Moskowitz Editor M. Komu July 2021 HTML TEXT PDF XML 41 cryptographic identity cryptographic namespace identifier-locator split mobility multihoming NAT traversal IPsec ESP IPv6 end-to-end security end-to-end connectivity endpoint identity leap of faith rendezvous

This memo describes the Host Identity (HI) namespace, which provides a cryptographic namespace to applications, and the associated protocol layer, the Host Identity Protocol, located between the internetworking and transport layers, that supports end-host mobility, multihoming, and NAT traversal. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a HI namespace will add completeness to them. The roles of the HI namespace in the protocols are defined.

This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. The Security Considerations section also describes measures against flooding attacks, usage of identities in access control lists, weaker types of identifiers, and trust on first use. This document incorporates lessons learned from the implementations of RFC 7401 and goes further to explain how HIP works as a secure signaling channel.

 draft-ietf-hip-rfc4423-bis-20 RFC4423 INFORMATIONAL INFORMATIONAL IETF int hip 10.17487/RFC9063 RFC9064 Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols D. Oran June 2021 HTML TEXT PDF XML 23 ICN QoS congestion control admission control

This is a position paper. It documents the author's personal views on how Quality of Service (QoS) capabilities ought to be accommodated in Information-Centric Networking (ICN) protocols like Content-Centric Networking (CCNx) or Named Data Networking (NDN), which employ flow-balanced Interest/Data exchanges and hop-by-hop forwarding state as their fundamental machinery. It argues that such protocols demand a substantially different approach to QoS from that taken in TCP/IP and proposes specific design patterns to achieve both classification and differentiated QoS treatment on both a flow and aggregate basis. It also considers the effect of caches in addition to memory, CPU, and link bandwidth as resources that should be subject to explicitly unfair resource allocation. The proposed methods are intended to operate purely at the network layer, providing the primitives needed to achieve transport- and higher-layer QoS objectives. It explicitly excludes any discussion of Quality of Experience (QoE), which can only be assessed and controlled at the application layer or above.

This document is not a product of the IRTF Information-Centric Networking Research Group (ICNRG) but has been through formal Last Call and has the support of the participants in the research group for publication as an individual submission.

 draft-oran-icnrg-qosarch-06 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC9064 RFC9065 Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols G. Fairhurst C. Perkins July 2021 HTML TEXT PDF XML 37 transport design operations and management

To protect user data and privacy, Internet transport protocols have supported payload encryption and authentication for some time. Such encryption and authentication are now also starting to be applied to the transport protocol headers. This helps avoid transport protocol ossification by middleboxes, mitigate attacks against the transport protocol, and protect metadata about the communication. Current operational practice in some networks inspect transport header information within the network, but this is no longer possible when those transport headers are encrypted.

This document discusses the possible impact when network traffic uses a protocol with an encrypted transport header. It suggests issues to consider when designing new transport protocols or features.

 draft-ietf-tsvwg-transport-encrypt-21 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC9065 RFC9066 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home T. Reddy.K M. Boucadair Editor J. Shallow December 2021 HTML TEXT PDF XML 34 Automation Anti-DDoS Automation DDoS Mitigation Collaborative Networking Protective Networking Security Scrubbing

This document specifies the Denial-of-Service Open Threat Signaling (DOTS) signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTS client and to receive attack traffic information from the Call Home DOTS client. The Call Home DOTS server in turn uses the attack traffic information to identify compromised devices launching outgoing DDoS attacks and take appropriate mitigation action(s).

The DOTS signal channel Call Home is not specific to home networks; the solution targets any deployment in which it is required to block DDoS attack traffic closer to the source(s) of a DDoS attack.

 draft-ietf-dots-signal-call-home-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec dots 10.17487/RFC9066 RFC9067 A YANG Data Model for Routing Policy Y. Qu J. Tantsura A. Lindem X. Liu October 2021 HTML TEXT PDF XML 38

This document defines a YANG data model for configuring and managing routing policies in a vendor-neutral way. The model provides a generic routing policy framework that can be extended for specific routing protocols using the YANG 'augment' mechanism.

 draft-ietf-rtgwg-policy-model-31 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg http://www.rfc-editor.org/errata_search.php?rfc=9067 10.17487/RFC9067 RFC9068 JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens V. Bertocci October 2021 HTML TEXT PDF XML 15 OAuth Resource Access token JWT

This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner.

 draft-ietf-oauth-access-token-jwt-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC9068 RFC9069 Support for Local RIB in the BGP Monitoring Protocol (BMP) T. Evens S. Bayraktar M. Bhardwaj P. Lucente February 2022 HTML TEXT PDF XML 14 BGP BMP local-rib loc-rib

The BGP Monitoring Protocol (BMP) defines access to local Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Local Routing Information Base (Loc-RIB), as defined in RFC 4271. The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process.

 draft-ietf-grow-bmp-local-rib-13 RFC7854 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC9069 RFC9070 YANG Data Model for MPLS LDP K. Raza Editor R. Asati X. Liu S. Esale X. Chen H. Shah March 2022 HTML TEXT PDF XML 79 MPLS LDP YANG

This document describes a YANG data model for the Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP). The model also serves as the base model to define the Multipoint LDP (mLDP) model.

The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA).

 draft-ietf-mpls-ldp-yang-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC9070 RFC9071 RTP-Mixer Formatting of Multiparty Real-Time Text G. Hellström July 2021 HTML TEXT PDF XML 35 conference bridge SIP

This document provides enhancements of real-time text (as specified in RFC 4103) suitable for mixing in a centralized conference model, enabling source identification and rapidly interleaved transmission of text from different sources. The intended use is for real-time text mixers and participant endpoints capable of providing an efficient presentation or other treatment of a multiparty real-time text session. The specified mechanism builds on the standard use of the Contributing Source (CSRC) list in the Real-time Transport Protocol (RTP) packet for source identification. The method makes use of the same "text/t140" and "text/red" formats as for two-party sessions.

Solutions using multiple RTP streams in the same RTP session are briefly mentioned, as they could have some benefits over the RTP-mixer model. The RTP-mixer model was selected to be used for the fully specified solution in this document because it can be applied to a wide range of existing RTP implementations.

A capability exchange is specified so that it can be verified that a mixer and a participant can handle the multiparty-coded real-time text stream using the RTP-mixer method. The capability is indicated by the use of a Session Description Protocol (SDP) (RFC 8866) media attribute, "rtt-mixer".

This document updates RFC 4103 ("RTP Payload for Text Conversation").

A specification for how a mixer can format text for the case when the endpoint is not multiparty aware is also provided.

 draft-ietf-avtcore-multi-party-rtt-mix-20 RFC4103 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC9071 RFC9072 Extended Optional Parameters Length for BGP OPEN Message E. Chen J. Scudder July 2021 HTML TEXT PDF XML 6 IDR BGP

The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concerns about this limitation.

This document updates RFC 4271 by extending, in a backward-compatible manner, the length of the Optional Parameters in a BGP OPEN message. The Parameter Length field of individual Optional Parameters is also extended.

 draft-ietf-idr-ext-opt-param-13 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC9072 RFC9073 Event Publishing Extensions to iCalendar M. Douglass August 2021 HTML TEXT PDF XML 29 iCalendar properties

This specification updates RFC 5545 by introducing a number of new iCalendar properties and components that are of particular use for event publishers and in social networking.

This specification also defines a new "STRUCTURED-DATA" property for iCalendar (RFC 5545) to allow for data that is directly pertinent to an event or task to be included with the calendar data.

 draft-ietf-calext-eventpub-extensions-19 RFC5545 PROPOSED STANDARD PROPOSED STANDARD IETF art calext http://www.rfc-editor.org/errata_search.php?rfc=9073 10.17487/RFC9073 RFC9074 "VALARM" Extensions for iCalendar C. Daboo K. Murchison Editor August 2021 HTML TEXT PDF XML 18 alarms calendaring iCalendar CalDAV

This document defines a set of extensions to the iCalendar "VALARM" component to enhance the use of alarms and improve interoperability between clients and servers.

This document updates RFC 5545.

 draft-ietf-calext-valarm-extensions-07 RFC5545 PROPOSED STANDARD PROPOSED STANDARD IETF art calext 10.17487/RFC9074 RFC9075 Report from the IAB COVID-19 Network Impacts Workshop 2020 J. Arkko S. Farrell M. Kühlewind C. Perkins July 2021 HTML TEXT PDF XML 20

The Coronavirus disease (COVID-19) pandemic caused changes in Internet user behavior, particularly during the introduction of initial quarantine and work-from-home arrangements. These behavior changes drove changes in Internet traffic.

The Internet Architecture Board (IAB) held a workshop to discuss network impacts of the pandemic on November 9-13, 2020. The workshop was held to convene interested researchers, network operators, network management experts, and Internet technologists to share their experiences. The meeting was held online given the ongoing travel and contact restrictions at that time.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 draft-iab-covid19-workshop-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC9075 RFC9076 DNS Privacy Considerations T. Wicinski Editor July 2021 HTML TEXT PDF XML 22 DNS

This document describes the privacy issues associated with the use of the DNS by Internet users. It provides general observations about typical current privacy practices. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626.

 draft-ietf-dprive-rfc7626-bis-09 RFC7626 INFORMATIONAL INFORMATIONAL IETF int dprive 10.17487/RFC9076 RFC9077 NSEC and NSEC3: TTLs and Aggressive Use P. van Dijk July 2021 HTML TEXT PDF XML 8 DNSSEC negative cache Denial of Existence

Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC and NSEC3 records may deny the existence of names far beyond the intended lifetime of a denial. This document changes the definition of the NSEC and NSEC3 TTL to correct that situation. This document updates RFCs 4034, 4035, 5155, and 8198.

 draft-ietf-dnsop-nsec-ttl-05 RFC4034 RFC4035 RFC5155 RFC8198 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC9077 RFC9078 Reaction: Indicating Summary Reaction to a Message D. Crocker R. Signes N. Freed August 2021 HTML TEXT PDF XML 9 reaction emoji social networking email affect messaging emoticon smileys like mime reply

The popularity of social media has led to user comfort with easily signaling basic reactions to an author's posting, such as with a 'thumbs up' or 'smiley' graphic. This specification permits a similar facility for Internet Mail.

 draft-crocker-inreply-react-14 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC9078 RFC9079 Source-Specific Routing in the Babel Routing Protocol M. Boutier J. Chroboczek August 2021 HTML TEXT PDF XML 13 SADR source address-dependent routing source address multihoming multihoming with multiple addresses multiple addresses source address selection multiple routes multipath disjoint routes route diversity

Source-specific routing, also known as Source Address Dependent Routing (SADR), is an extension to traditional next-hop routing where packets are forwarded according to both their destination address and their source address. This document describes an extension for source-specific routing to the Babel routing protocol.

 draft-ietf-babel-source-specific-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg babel 10.17487/RFC9079 RFC9080 Homenet Profile of the Babel Routing Protocol J. Chroboczek August 2021 HTML TEXT PDF XML 8

This document defines the exact subset of the Babel routing protocol and its extensions that is required by an implementation of the Homenet protocol suite, as well as the interactions between the Home Networking Control Protocol (HNCP) and Babel.

 draft-ietf-homenet-babel-profile-07 PROPOSED STANDARD PROPOSED STANDARD IETF int homenet 10.17487/RFC9080 RFC9081 Interoperation between Multicast Virtual Private Network (MVPN) and Multicast Source Directory Protocol (MSDP) Source-Active Routes Z. Zhang L. Giuliano July 2021 HTML TEXT PDF XML 6

This document specifies the procedures for interoperation between Multicast Virtual Private Network (MVPN) Source-Active (SA) routes and customer Multicast Source Discovery Protocol (MSDP) SA routes, which is useful for MVPN provider networks offering services to customers with an existing MSDP infrastructure. Without the procedures described in this document, VPN-specific MSDP sessions are required among the Provider Edge (PE) routers that are customer MSDP peers. This document updates RFC 6514.

 draft-ietf-bess-mvpn-msdp-sa-interoperation-08 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC9081 RFC9082 Registration Data Access Protocol (RDAP) Query Format S. Hollenbeck A. Newton June 2021 HTML TEXT PDF XML 18

This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482.

 draft-ietf-regext-rfc7482bis-03 RFC7482 STD0095 INTERNET STANDARD INTERNET STANDARD IETF art regext 10.17487/RFC9082 RFC9083 JSON Responses for the Registration Data Access Protocol (RDAP) S. Hollenbeck A. Newton June 2021 HTML TEXT PDF XML 81

This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483.

 draft-ietf-regext-rfc7483bis-05 RFC7483 STD0095 INTERNET STANDARD INTERNET STANDARD IETF art regext http://www.rfc-editor.org/errata_search.php?rfc=9083 10.17487/RFC9083 RFC9084 OSPF Prefix Originator Extensions A. Wang A. Lindem J. Dong P. Psenak K. Talaulikar Editor August 2021 HTML TEXT PDF XML 9 OSPF

This document defines OSPF extensions to include information associated with the node originating a prefix along with the prefix advertisement. These extensions do not change the core OSPF route computation functionality but provide useful information for network analysis, troubleshooting, and use cases like traffic engineering.

 draft-ietf-lsr-ospf-prefix-originator-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC9084 RFC9085 Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing S. Previdi K. Talaulikar Editor C. Filsfils H. Gredler M. Chen August 2021 HTML TEXT PDF XML 27 BGP-LS Segment Routing SID MPLS Label advertisement IS-IS OSPF OSPFv3

Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called "segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies.

This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) address family in order to carry SR information via BGP.

 draft-ietf-idr-bgp-ls-segment-routing-ext-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=9085 10.17487/RFC9085 RFC9086 Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering S. Previdi K. Talaulikar Editor C. Filsfils K. Patel S. Ray J. Dong August 2021 HTML TEXT PDF XML 15 BGP BGP-LS Segment Routing

A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A segment can represent any instruction, topological or service based. SR segments allow steering a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain.

This document describes an extension to Border Gateway Protocol - Link State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing.

 draft-ietf-idr-bgpls-segment-routing-epe-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC9086 RFC9087 Segment Routing Centralized BGP Egress Peer Engineering C. Filsfils Editor S. Previdi G. Dawra Editor E. Aries D. Afanasiev August 2021 HTML TEXT PDF XML 17

Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows for the enforcement of a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain.

The Segment Routing architecture can be directly applied to the MPLS data plane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols.

This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based BGP-EPE solution allows a centralized (Software-Defined Networking, or SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain.

 draft-ietf-spring-segment-routing-central-epe-10 INFORMATIONAL INFORMATIONAL IETF rtg spring 10.17487/RFC9087 RFC9088 Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS X. Xu S. Kini P. Psenak C. Filsfils S. Litkowski M. Bocci August 2021 HTML TEXT PDF XML 7

Multiprotocol Label Switching (MPLS) has defined a mechanism to load-balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load-balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities using IS-IS and Border Gateway Protocol - Link State (BGP-LS).

 draft-ietf-isis-mpls-elc-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC9088 RFC9089 Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF X. Xu S. Kini P. Psenak C. Filsfils S. Litkowski M. Bocci August 2021 HTML TEXT PDF XML 8

Multiprotocol Label Switching (MPLS) has defined a mechanism to load-balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load-balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities using OSPFv2 and OSPFv3, and Border Gateway Protocol - Link State (BGP-LS).

 draft-ietf-ospf-mpls-elc-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC9089 RFC9090 Concise Binary Object Representation (CBOR) Tags for Object Identifiers C. Bormann July 2021 HTML TEXT PDF XML 13 binary format data interchange format ASN.1 OID Object Identifier

The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.

This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined.

 draft-ietf-cbor-tags-oid-08 PROPOSED STANDARD PROPOSED STANDARD IETF art cbor 10.17487/RFC9090 RFC9091 Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains S. Kitterman T. Wicinski Editor July 2021 HTML TEXT PDF XML 14 DMARC email authentication TLD

Domain-based Message Authentication, Reporting, and Conformance (DMARC), defined in RFC 7489, permits a domain-controlling organization to express domain-level policies and preferences for message validation, disposition, and reporting, which a mail-receiving organization can use to improve mail handling.

DMARC distinguishes the portion of a name that is a Public Suffix Domain (PSD), below which Organizational Domain names are created. The basic DMARC capability allows Organizational Domains to specify policies that apply to their subdomains, but it does not give that capability to PSDs. This document describes an extension to DMARC to fully enable DMARC functionality for PSDs.

Some implementations of DMARC consider a PSD to be ineligible for DMARC enforcement. This specification addresses that case.

 draft-ietf-dmarc-psd-15 EXPERIMENTAL EXPERIMENTAL IETF art dmarc 10.17487/RFC9091 RFC9092 Finding and Using Geofeed Data R. Bush M. Candela W. Kumari R. Housley July 2021 HTML TEXT PDF XML 21

This document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed data comma-separated values (CSV) files and describes an optional scheme that uses the Routing Public Key Infrastructure to authenticate the geofeed data CSV files.

 draft-ietf-opsawg-finding-geofeeds-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC9092 RFC9093 A YANG Data Model for Layer 0 Types H. Zheng Y. Lee A. Guo V. Lopez D. King August 2021 HTML TEXT PDF XML 20

This document defines a collection of common data types and groupings in the YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Layer 0 optical Traffic Engineering (TE) configuration and state capabilities such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks.

 draft-ietf-ccamp-layer0-types-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC9093 RFC9094 A YANG Data Model for Wavelength Switched Optical Networks (WSONs) H. Zheng Y. Lee A. Guo V. Lopez D. King August 2021 HTML TEXT PDF XML 56

This document provides a YANG data model for the routing and wavelength assignment (RWA) TE topology in Wavelength Switched Optical Networks (WSONs). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA).

 draft-ietf-ccamp-wson-yang-28 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=9094 10.17487/RFC9094 RFC9095 Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration J. Yao L. Zhou H. Li N. Kong J. Xie July 2021 HTML TEXT PDF XML 23 IDN

This document describes an extension of Extensible Provisioning Protocol (EPP) domain name mapping for the provisioning and management of strict bundling registration of domain names. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of bundled domain names. This is a nonstandard proprietary extension.

 draft-yao-regext-bundling-registration-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9095 RFC9096 Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events F. Gont J. Žorž R. Patterson B. Volz August 2021 HTML TEXT PDF XML 11 IPv6 problem address prefix delegation DHCPv6 stale prefixes old prefixes

This document specifies improvements to Customer Edge routers that help mitigate the problems that may arise when network configuration information becomes invalid without any explicit signaling of that condition to the local nodes. This document updates RFC 7084.

 draft-ietf-v6ops-cpe-slaac-renum-08 RFC7084 BCP0234 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC9096 RFC9097 Metrics and Methods for One-Way IP Capacity A. Morton R. Geib L. Ciavattone November 2021 HTML TEXT PDF XML 33 IP Layer Performance Speed Access

This memo revisits the problem of Network Capacity Metrics first examined in RFC 5136. This memo specifies a more practical Maximum IP-Layer Capacity Metric definition catering to measurement and outlines the corresponding Methods of Measurement.

 draft-ietf-ippm-capacity-metric-method-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC9097 RFC9098 Operational Implications of IPv6 Packets with Extension Headers F. Gont N. Hilliard G. Doering W. Kumari G. Huston W. Liu September 2021 HTML TEXT PDF XML 17

This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC 8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet.

 draft-ietf-v6ops-ipv6-ehs-packet-drops-08 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=9098 10.17487/RFC9098 RFC9099 Operational Security Considerations for IPv6 Networks É. Vyncke K. Chittimaneni M. Kaeo E. Rey August 2021 HTML TEXT PDF XML 48 IPv6 Security Operational Security

Knowledge and experience on how to operate IPv4 networks securely is available, whether the operator is an Internet Service Provider (ISP) or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices.

This document analyzes the operational security issues associated with several types of networks and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise networks, service provider networks, or managed residential networks.

 draft-ietf-opsec-v6-27 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC9099 RFC9100 Sensor Measurement Lists (SenML) Features and Versions C. Bormann August 2021 HTML TEXT PDF XML 7 Internet of Things (IoT) Internet of Things IOT data model

This short document updates RFC 8428, "Sensor Measurement Lists (SenML)", by specifying the use of independently selectable "SenML Features" and mapping them to SenML version numbers.

 draft-ietf-core-senml-versions-05 RFC8428 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC9100 RFC9101 The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) N. Sakimura J. Bradley M. Jones August 2021 HTML TEXT PDF XML 25 Assertion Claim Security Token OAuth JavaScript Object Notation JSON JSON Web Token JWT JSON Web Signature JWS JSON Web Encryption JWE

The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward.

This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference.

 draft-ietf-oauth-jwsreq-34 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC9101 RFC9102 TLS DNSSEC Chain Extension V. Dukhovni S. Huque W. Toorop P. Wouters M. Shore August 2021 HTML TEXT PDF XML 43

This document describes an experimental TLS extension for the in-band transport of the complete set of records that can be validated by DNSSEC and that are needed to perform DNS-Based Authentication of Named Entities (DANE) of a TLS server. This extension obviates the need to perform separate, out-of-band DNS lookups. When the requisite DNS records do not exist, the extension conveys a denial-of-existence proof that can be validated.

This experimental extension is developed outside the IETF and is published here to guide implementation of the extension and to ensure interoperability among implementations.

 draft-dukhovni-tls-dnssec-chain-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=9102 10.17487/RFC9102 RFC9103 DNS Zone Transfer over TLS W. Toorop S. Dickinson S. Sahib P. Aras A. Mankin August 2021 HTML TEXT PDF XML 32 DNS operations privacy

DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies the use of TLS, rather than cleartext, to prevent zone content collection via passive monitoring of zone transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995 and RFC 5936 with respect to efficient use of TCP connections and RFC 7766 with respect to the recommended number of connections between a client and server for each transport.

 draft-ietf-dprive-xfr-over-tls-12 RFC1995 RFC5936 RFC7766 PROPOSED STANDARD PROPOSED STANDARD IETF int dprive 10.17487/RFC9103 RFC9104 Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS) J. Tantsura Z. Wang Q. Wu K. Talaulikar August 2021 HTML TEXT PDF XML 7 Inter-Domain Routing

Administrative groups are link attributes used for traffic engineering. This document defines an extension to the Border Gateway Protocol - Link State (BGP-LS) for advertisement of extended administrative groups (EAGs).

 draft-ietf-idr-eag-distribution-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC9104 RFC9105 A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) B. Wu Editor G. Zheng M. Wang Editor August 2021 HTML TEXT PDF XML 16

This document defines a Terminal Access Controller Access-Control System Plus (TACACS+) client YANG module that augments the System Management data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Though being a standard module, this module does not endorse the security mechanisms of the TACACS+ protocol (RFC 8907), and TACACS+ be used within a secure deployment.

The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

 draft-ietf-opsawg-tacacs-yang-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC9105 RFC9106 Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications A. Biryukov D. Dinu D. Khovratovich S. Josefsson September 2021 HTML TEXT PDF XML 21 Argon2d Argon2i Argon2id KDF Cryptocurrency Time-Space Trade-Off Attacks Security

This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer-oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

 draft-irtf-cfrg-argon2-13 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC9106 RFC9107 BGP Optimal Route Reflection (BGP ORR) R. Raszuk Editor B. Decraene Editor C. Cassar E. Åman K. Wang August 2021 HTML TEXT PDF XML 9 IDR

This document defines an extension to BGP route reflectors. On route reflectors, BGP route selection is modified in order to choose the best route from the standpoint of their clients, rather than from the standpoint of the route reflectors themselves. Depending on the scaling and precision requirements, route selection can be specific for one client, common for a set of clients, or common for all clients of a route reflector. This solution is particularly applicable in deployments using centralized route reflectors, where choosing the best route based on the route reflector's IGP location is suboptimal. This facilitates, for example, a "best exit point" policy ("hot potato routing").

The solution relies upon all route reflectors learning all paths that are eligible for consideration. BGP route selection is performed in the route reflectors based on the IGP cost from configured locations in the link-state IGP.

 draft-ietf-idr-bgp-optimal-route-reflection-28 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC9107 RFC9108 YANG Types for DNS Classes and Resource Record Types L. Lhotka P. Špaček September 2021 HTML TEXT PDF XML 14 IANA registry DNS Parameters

This document introduces the YANG module "iana-dns-class-rr-type", which contains derived types reflecting two IANA registries: DNS CLASSes and Resource Record (RR) TYPEs. These YANG types are intended as the minimum basis for future data modeling work.

 draft-ietf-dnsop-iana-class-type-yang-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC9108 RFC9109 Network Time Protocol Version 4: Port Randomization F. Gont G. Gont M. Lichvar August 2021 HTML TEXT PDF XML 9 security transport protocols

The Network Time Protocol (NTP) can operate in several modes. Some of these modes are based on the receipt of unsolicited packets and therefore require the use of a well-known port as the local port. However, in the case of NTP modes where the use of a well-known port is not required, employing such a well-known port unnecessarily facilitates the ability of attackers to perform blind/off-path attacks. This document formally updates RFC 5905, recommending the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required.

 draft-ietf-ntp-port-randomization-08 RFC5905 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp 10.17487/RFC9109 RFC9110 HTTP Semantics R. Fielding Editor M. Nottingham Editor J. Reschke Editor June 2022 HTML TEXT PDF XML 194 Hypertext Transfer Protocol HTTP HTTP semantics HTTP content HTTP method HTTP status code

The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.

This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.

 draft-ietf-httpbis-semantics-19 RFC2818 RFC7230 RFC7231 RFC7232 RFC7233 RFC7235 RFC7538 RFC7615 RFC7694 RFC3864 STD0097 INTERNET STANDARD INTERNET STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=9110 10.17487/RFC9110 RFC9111 HTTP Caching R. Fielding Editor M. Nottingham Editor J. Reschke Editor June 2022 HTML TEXT PDF XML 35 Hypertext Transfer Protocol HTTP HTTP Caching

The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.

This document obsoletes RFC 7234.

 draft-ietf-httpbis-cache-19 RFC7234 STD0098 INTERNET STANDARD INTERNET STANDARD IETF art httpbis 10.17487/RFC9111 RFC9112 HTTP/1.1 R. Fielding Editor M. Nottingham Editor J. Reschke Editor June 2022 HTML TEXT PDF XML 46 Hypertext Transfer Protocol HTTP HTTP message format

The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns.

This document obsoletes portions of RFC 7230.

 draft-ietf-httpbis-messaging-19 RFC7230 STD0099 INTERNET STANDARD INTERNET STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=9112 10.17487/RFC9112 RFC9113 HTTP/2 M. Thomson Editor C. Benfield Editor June 2022 HTML TEXT PDF XML 78 HTTP SPDY Web

This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.

This document obsoletes RFCs 7540 and 8740.

 draft-ietf-httpbis-http2bis-07 RFC7540 RFC8740 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=9113 10.17487/RFC9113 RFC9114 HTTP/3 M. Bishop Editor June 2022 HTML TEXT PDF XML 57 Transport QUIC HTTP/2 HPACK QPACK Web

The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.

 draft-ietf-quic-http-34 PROPOSED STANDARD PROPOSED STANDARD IETF tsv quic http://www.rfc-editor.org/errata_search.php?rfc=9114 10.17487/RFC9114 RFC9115 An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates Y. Sheffer D. López A. Pastor Perales T. Fossati September 2021 HTML TEXT PDF XML 42 Content Delivery Network CDN

This document defines a profile of the Automatic Certificate Management Environment (ACME) protocol by which the holder of an identifier (e.g., a domain name) can allow a third party to obtain an X.509 certificate such that the certificate subject is the delegated identifier while the certified public key corresponds to a private key controlled by the third party. A primary use case is that of a Content Delivery Network (CDN), the third party, terminating TLS sessions on behalf of a content provider (the holder of a domain name). The presented mechanism allows the holder of the identifier to retain control over the delegation and revoke it at any time. Importantly, this mechanism does not require any modification to the deployed TLS clients and servers.

 draft-ietf-acme-star-delegation-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec acme 10.17487/RFC9115 RFC9116 A File Format to Aid in Security Vulnerability Disclosure E. Foudil Y. Shafranovich April 2022 HTML TEXT PDF XML 21

When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a machine-parsable format ("security.txt") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities.

 draft-foudil-securitytxt-12 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=9116 10.17487/RFC9116 RFC9117 Revised Validation Procedure for BGP Flow Specifications J. Uttaro J. Alcaide C. Filsfils D. Smith P. Mohapatra August 2021 HTML TEXT PDF XML 12 BGP flowspec

This document describes a modification to the validation procedure defined for the dissemination of BGP Flow Specifications. The dissemination of BGP Flow Specifications as specified in RFC 8955 requires that the originator of the Flow Specification match the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. For an Internal Border Gateway Protocol (iBGP) received route, the originator is typically a border router within the same autonomous system (AS). The objective is to allow only BGP speakers within the data forwarding path to originate BGP Flow Specifications. Sometimes it is desirable to originate the BGP Flow Specification from any place within the autonomous system itself, for example, from a centralized BGP route controller. However, the validation procedure described in RFC 8955 will fail in this scenario. The modification proposed herein relaxes the validation rule to enable Flow Specifications to be originated within the same autonomous system as the BGP speaker performing the validation. Additionally, this document revises the AS_PATH validation rules so Flow Specifications received from an External Border Gateway Protocol (eBGP) peer can be validated when such a peer is a BGP route server.

This document updates the validation procedure in RFC 8955.

 draft-ietf-idr-bgp-flowspec-oid-15 RFC8955 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC9117 RFC9118 Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates R. Housley August 2021 HTML TEXT PDF XML 12 X.509 Certificate Extension

RFC 8226 specifies the use of certificates for Secure Telephone Identity Credentials; these certificates are often called "Secure Telephone Identity Revisited (STIR) Certificates". RFC 8226 provides a certificate extension to constrain the JSON Web Token (JWT) claims that can be included in the Personal Assertion Token (PASSporT), as defined in RFC 8225. If the PASSporT signer includes a JWT claim outside the constraint boundaries, then the PASSporT recipient will reject the entire PASSporT. This document updates RFC 8226; it provides all of the capabilities available in the original certificate extension as well as an additional way to constrain the allowable JWT claims. The enhanced extension can also provide a list of claims that are not allowed to be included in the PASSporT.

 draft-ietf-stir-enhance-rfc8226-05 RFC8226 PROPOSED STANDARD PROPOSED STANDARD IETF art stir 10.17487/RFC9118 RFC9119 Multicast Considerations over IEEE 802 Wireless Media C. Perkins M. McBride D. Stanley W. Kumari JC. Zúñiga October 2021 HTML TEXT PDF XML 22 Multicast IEEE 802 Wireless Multicast Broadcast BUM wifi wireless

Well-known issues with multicast have prevented the deployment of multicast in 802.11 (Wi-Fi) and other local-area wireless environments. This document describes the known limitations of wireless (primarily 802.11) Layer 2 multicast. Also described are certain multicast enhancement features that have been specified by the IETF and by IEEE 802 for wireless media, as well as some operational choices that can be made to improve the performance of the network. Finally, some recommendations are provided about the usage and combination of these features and operational choices.

 draft-ietf-mboned-ieee802-mcast-problems-15 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC9119 RFC9120 Nameservers for the Address and Routing Parameter Area ("arpa") Domain K. Davies J. Arkko October 2021 HTML TEXT PDF XML 7 root zone IANA top-level domain root nameservers DNS ARPA

This document describes revisions to operational practices to separate the function of the "arpa" top-level domain in the DNS from its historical operation alongside the DNS root zone.

 draft-iab-arpa-authoritative-servers-01 RFC3172 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC9120 RFC9124 A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices B. Moran H. Tschofenig H. Birkholz January 2022 HTML TEXT PDF XML 40 computer security smart objects

Vulnerabilities with Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism that is also suitable for constrained devices. Ensuring that devices function and remain secure over their service lifetime requires such an update mechanism to fix vulnerabilities, update configuration settings, and add new functionality.

One component of such a firmware update is a concise and machine-processable metadata document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest.

 draft-ietf-suit-information-model-13 INFORMATIONAL INFORMATIONAL IETF sec suit http://www.rfc-editor.org/errata_search.php?rfc=9124 10.17487/RFC9124 RFC9125 Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing A. Farrel J. Drake E. Rosen K. Patel L. Jalil August 2021 HTML TEXT PDF XML 12 SR GW BGP

Data centers are attached to the Internet or a backbone network by gateway routers. One data center typically has more than one gateway for commercial, load-balancing, and resiliency reasons. Other sites, such as access networks, also need to be connected across backbone networks through gateways.

This document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow data center gateway routers to advertise routes to the prefixes reachable in the site, including advertising them on behalf of other gateways at the same site. This allows segment routing to be used to identify multiple paths across the Internet or backbone network between different gateways. The paths can be selected for load-balancing, resilience, and quality purposes.

 draft-ietf-bess-datacenter-gateway-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC9125 RFC9126 OAuth 2.0 Pushed Authorization Requests T. Lodderstedt B. Campbell N. Sakimura D. Tonge F. Skokan September 2021 HTML TEXT PDF XML 18 security oauth2

This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint.

 draft-ietf-oauth-par-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=9126 10.17487/RFC9126 RFC9127 YANG Data Model for Bidirectional Forwarding Detection (BFD) R. Rahman Editor L. Zheng Editor M. Jethanandani Editor S. Pallagatti G. Mirsky October 2021 HTML TEXT PDF XML 64 Liveliness check BGP OSPF IS-IS TCP-AO MD5

This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD).

The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) (RFC 8342).

 draft-ietf-bfd-yang-17 RFC9314 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC9127 RFC9128 YANG Data Model for Protocol Independent Multicast (PIM) X. Liu P. McAllister A. Peter M. Sivakumar Y. Liu F. Hu October 2022 HTML TEXT PDF XML 92 Network Management PIM YANG

This document defines a YANG data model that can be used to configure and manage devices supporting Protocol Independent Multicast (PIM). The model covers the PIM protocol configuration, operational state, and event notifications data.

 draft-ietf-pim-yang-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC9128 RFC9129 YANG Data Model for the OSPF Protocol D. Yeung Y. Qu Z. Zhang I. Chen A. Lindem October 2022 HTML TEXT PDF XML 116

This document defines a YANG data model that can be used to configure and manage OSPF. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342.

 draft-ietf-ospf-yang-29 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC9129 RFC9130 YANG Data Model for the IS-IS Protocol S. Litkowski Editor D. Yeung A. Lindem J. Zhang L. Lhotka October 2022 HTML TEXT PDF XML 103

This document defines a YANG data model that can be used to configure and manage the IS-IS protocol on network elements.

 draft-ietf-isis-yang-isis-cfg-42 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC9130 RFC9131 Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers J. Linkova October 2021 HTML TEXT PDF XML 20 IPv6 SLAAC stateless address autoconfiguration neighbor advertisement

Neighbor Discovery (RFC 4861) is used by IPv6 nodes to determine the link-layer addresses of neighboring nodes as well as to discover and maintain reachability information. This document updates RFC 4861 to allow routers to proactively create a Neighbor Cache entry when a new IPv6 address is assigned to a node. It also updates RFC 4861 and recommends that nodes send unsolicited Neighbor Advertisements upon assigning a new IPv6 address. These changes will minimize the delay and packet loss when a node initiates connections to an off-link destination from a new IPv6 address.

 draft-ietf-6man-grand-07 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC9131 RFC9132 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification M. Boucadair Editor J. Shallow T. Reddy.K September 2021 HTML TEXT PDF XML 107 security mitigation service delivery connectivity anti-DDoS automation cooperation resilience filtering security center mitigator scrubbing dynamic service protection dynamic mitigation cooperative networking protective networking

This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.

A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.

This document obsoletes RFC 8782.

 draft-ietf-dots-rfc8782-bis-08 RFC8782 PROPOSED STANDARD PROPOSED STANDARD IETF sec dots http://www.rfc-editor.org/errata_search.php?rfc=9132 10.17487/RFC9132 RFC9133 Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel K. Nishizuka M. Boucadair T. Reddy.K T. Nagata September 2021 HTML TEXT PDF XML 26 Mitigation Automation Filtering Protective Networking Protected Networks Security Anti-DDoS Reactive Collaborative Networking Collaborative Security

This document specifies an extension to the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol so that DOTS clients can control their filtering rules when an attack mitigation is active.

Particularly, this extension allows a DOTS client to activate or deactivate existing filtering rules during a Distributed Denial-of-Service (DDoS) attack. The characterization of these filtering rules is conveyed by a DOTS client during an 'idle' time (i.e., no mitigation is active) by means of the DOTS data channel protocol.

 draft-ietf-dots-signal-filter-control-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec dots 10.17487/RFC9133 RFC9134 RTP Payload Format for ISO/IEC 21122 (JPEG XS) T. Bruylants A. Descampe C. Damman T. Richter October 2021 HTML TEXT PDF XML 27 video transport protocol joint photographic experts group real-time stream

This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting video encoded with JPEG XS (ISO/IEC 21122). JPEG XS is a low-latency, lightweight image coding system. Compared to an uncompressed video use case, it allows higher resolutions and video frame rates while offering visually lossless quality, reduced power consumption, and encoding-decoding latency confined to a fraction of a video frame.

 draft-ietf-payload-rtp-jpegxs-18 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore http://www.rfc-editor.org/errata_search.php?rfc=9134 10.17487/RFC9134 RFC9135 Integrated Routing and Bridging in Ethernet VPN (EVPN) A. Sajassi S. Salam S. Thoria J. Drake J. Rabadan October 2021 HTML TEXT PDF XML 30 IRB inter-subnet-forwarding symmetric asymmetric mobility

Ethernet VPN (EVPN) provides an extensible and flexible multihoming VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and end devices that can be physical or virtual. However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and end devices while maintaining the multihoming capabilities of EVPN. This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements.

 draft-ietf-bess-evpn-inter-subnet-forwarding-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC9135 RFC9136 IP Prefix Advertisement in Ethernet VPN (EVPN) J. Rabadan Editor W. Henderickx J. Drake W. Lin A. Sajassi October 2021 HTML TEXT PDF XML 31 RT5 RT-5 Type-5 Interface-less Interface-ful

The BGP MPLS-based Ethernet VPN (EVPN) (RFC 7432) mechanism provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or Network Virtualization Overlay (NVO) (RFC 7365) network. In some networks, there is also a need for dynamic and efficient inter-subnet connectivity across Tenant Systems and end devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP prefixes and explains some use-case examples where this new route type is used.

 draft-ietf-bess-evpn-prefix-advertisement-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC9136 RFC9137 Considerations for Cancellation of IETF Meetings M. Duke October 2021 HTML TEXT PDF XML 7 virtualize postpone move

The IETF ordinarily holds three in-person meetings per year to discuss issues and advance the Internet. However, various events can make a planned in-person meeting infeasible. This document provides criteria to aid the IETF Administration LLC (IETF LLC), the Internet Engineering Steering Group (IESG), and the Chair of the Internet Research Task Force (IRTF) in deciding to relocate, virtualize, postpone, or cancel an in-person IETF meeting.

 draft-ietf-shmoo-cancel-meeting-06 BCP0226 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen shmoo 10.17487/RFC9137 RFC9138 Design Considerations for Name Resolution Service in Information-Centric Networking (ICN) J. Hong T. You L. Dong C. Westphal B. Ohlman December 2021 HTML TEXT PDF XML 17

This document provides the functionalities and design considerations for a Name Resolution Service (NRS) in Information-Centric Networking (ICN). The purpose of an NRS in ICN is to translate an object name into some other information such as a locator, another name, etc. in order to forward the object request. This document is a product of the Information-Centric Networking Research Group (ICNRG).

 draft-irtf-icnrg-nrs-requirements-06 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC9138 RFC9139 Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs) C. Gündoğan T. Schmidt M. Wählisch C. Scherb C. Marxer C. Tschudin November 2021 HTML TEXT PDF XML 42 Content-Centric Networking (CCNx) Named Data Networking (NDN) header compression fragmentation 6LoWPAN Internet of Things (IoT)

This document defines a convergence layer for Content-Centric Networking (CCNx) and Named Data Networking (NDN) over IEEE 802.15.4 Low-Power Wireless Personal Area Networks (LoWPANs). A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by IPv6 over LoWPAN (6LoWPAN) is extended to include new dispatch types for CCNx and NDN. Additionally, the fragmentation component of the 6LoWPAN dispatching framework is applied to Information-Centric Network (ICN) chunks. In its second part, the document defines stateless and stateful compression schemes to improve efficiency on constrained links. Stateless compression reduces TLV expressions to static header fields for common use cases. Stateful compression schemes elide states local to the LoWPAN and replace names in Data packets by short local identifiers.

This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).

 draft-irtf-icnrg-icnlowpan-11 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC9139 RFC9140 Nimble Out-of-Band Authentication for EAP (EAP-NOOB) T. Aura M. Sethi A. Peltonen December 2021 HTML TEXT PDF XML 51 IoT security cybersecurity network access authorization Extensible Authentication Protocol key exchange

The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no preconfigured authentication credentials. The method makes use of a user-assisted, one-directional, out-of-band (OOB) message between the peer device and authentication server to authenticate the in-band key exchange. The device must have a nonnetwork input or output interface, such as a display, microphone, speaker, or blinking light, that can send or receive dynamically generated messages of tens of bytes in length.

 draft-ietf-emu-eap-noob-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu 10.17487/RFC9140 RFC9141 Updating References to the IETF FTP Service R. Danyliw November 2021 HTML TEXT PDF XML 18

The IETF FTP service running at ftp.ietf.org, ops.ietf.org, and ietf.org will be retired. A number of published RFCs in the IETF and IAB streams include URIs that reference this FTP service. To ensure that the materials referenced using the IETF FTP service can still be found, this document updates the FTP-based references in these affected documents with HTTPS URIs.

 draft-danyliw-replace-ftp-pointers-06 RFC2077 RFC2418 RFC2648 RFC2954 RFC2955 RFC3020 RFC3083 RFC3201 RFC3202 RFC3295 RFC3684 RFC3962 RFC3970 RFC4036 RFC4131 RFC4251 RFC4323 RFC4546 RFC4547 RFC4639 RFC4682 RFC5098 RFC5428 RFC6756 RFC7241 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC9141 RFC9142 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) M. Baushke January 2022 HTML TEXT PDF XML 19 3DES AES Advanced Encryption Standard Curve25519 Curve448 DH Diffie-Hellman Digital Encryption Standard ECC ECDH Elliptic Curve Cryptography Elliptic Curve Diffie-Hellman FFC Finite Field Cryptography IFC Integer Factorization Cryptography MODP MTI Mandatory to Implement Modular Exponential Public Key Exchange RSA SHA-2 Secure Shell Key Exchange Secure Shell Security Strength Triple-DES sha1 sha256 sha384 sha512 SHA-1 Modular Exponentiation

This document updates the recommended set of key exchange methods for use in the Secure Shell (SSH) protocol to meet evolving needs for stronger security. It updates RFCs 4250, 4253, 4432, and 4462.

 draft-ietf-curdle-ssh-kex-sha2-20 RFC4250 RFC4253 RFC4432 RFC4462 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=9142 10.17487/RFC9142 RFC9143 Negotiating Media Multiplexing Using the Session Description Protocol (SDP) C. Holmberg H. Alvestrand C. Jennings February 2022 HTML TEXT PDF XML 54 RTP SDP Bundle Multiplexing RTCWEB CLUE RTCWEB MMUSIC AVT WEB Browser

This specification defines a new Session Description Protocol (SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a "BUNDLE transport", and the media is referred to as "bundled media". The "m=" sections that use the BUNDLE transport form a BUNDLE group.

This specification defines a new RTP Control Protocol (RTCP) Source Description (SDES) item and a new RTP header extension.

This specification updates RFCs 3264, 5888, and 7941.

This specification obsoletes RFC 8843.

 draft-ietf-mmusic-rfc8843bis-09 RFC8843 RFC3264 RFC5888 RFC7941 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC9143 RFC9144 Comparison of Network Management Datastore Architecture (NMDA) Datastores A. Clemm Y. Qu J. Tantsura A. Bierman December 2021 HTML TEXT PDF XML 16 Troubleshooting YANG RPC YANG Data Model

This document defines a Remote Procedure Call (RPC) operation to compare management datastores that comply with the Network Management Datastore Architecture (NMDA).

 draft-ietf-netmod-nmda-diff-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC9144 RFC9145 Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers M. Boucadair T. Reddy.K D. Wing December 2021 HTML TEXT PDF XML 25 Security Resilience Automation Service delivery Providers Differentiated services Traffic Engineering Attack mitigation

This specification presents an optional method to add integrity protection directly to the Network Service Header (NSH) used for Service Function Chaining (SFC). Also, this specification allows for the encryption of sensitive metadata (MD) that is carried in the NSH.

 draft-ietf-sfc-nsh-integrity-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sfc 10.17487/RFC9145 RFC9146 Connection Identifier for DTLS 1.2 E. Rescorla Editor H. Tschofenig Editor T. Fossati A. Kraus March 2022 HTML TEXT PDF XML 14 NAT rebinding

This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2.

A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session, then the receiver will be unable to locate the correct security context.

The new ciphertext record format with the CID also provides content type encryption and record layer padding.

This document updates RFC 6347.

 draft-ietf-tls-dtls-connection-id-13 RFC6347 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC9146 RFC9147 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 E. Rescorla H. Tschofenig N. Modadugu April 2022 HTML TEXT PDF XML 61 Communication Security

This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.

The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.

This document obsoletes RFC 6347.

 draft-ietf-tls-dtls13-43 RFC6347 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC9147 RFC9148 EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol P. van der Stok P. Kampanakis M. Richardson S. Raza April 2022 HTML TEXT PDF XML 41

Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates.

 draft-ietf-ace-coap-est-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec ace 10.17487/RFC9148 RFC9149 TLS Ticket Requests T. Pauly D. Schinazi C.A. Wood April 2022 HTML TEXT PDF XML 8 TLS Tickets

TLS session tickets enable stateless connection resumption for clients without server-side, per-client state. Servers vend an arbitrary number of session tickets to clients, at their discretion, upon connection establishment. Clients store and use tickets when resuming future connections. This document describes a mechanism by which clients can specify the desired number of tickets needed for future connections. This extension aims to provide a means for servers to determine the number of tickets to generate in order to reduce ticket waste while simultaneously priming clients for future connection attempts.

 draft-ietf-tls-ticketrequests-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC9149 RFC9150 TLS 1.3 Authentication and Integrity-Only Cipher Suites N. Cam-Winget J. Visoky April 2022 HTML TEXT PDF XML 10 HMAC IoT constrained devices

This document defines the use of cipher suites for TLS 1.3 based on Hashed Message Authentication Code (HMAC). Using these cipher suites provides server and, optionally, mutual authentication and data authenticity, but not data confidentiality. Cipher suites with these properties are not of general applicability, but there are use cases, specifically in Internet of Things (IoT) and constrained environments, that do not require confidentiality of exchanged messages while still requiring integrity protection, server authentication, and optional client authentication. This document gives examples of such use cases, with the caveat that prior to using these integrity-only cipher suites, a threat model for the situation at hand is needed, and a threat analysis must be performed within that model to determine whether the use of integrity-only cipher suites is appropriate. The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but it is presented here to enable interoperable implementation of a reduced-security mechanism that provides authentication and message integrity without supporting confidentiality.

 draft-camwinget-tls-ts13-macciphersuites-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9150 RFC9151 Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3 D. Cooley April 2022 HTML TEXT PDF XML 14

This document defines a base profile for TLS protocol versions 1.2 and 1.3 as well as DTLS protocol versions 1.2 and 1.3 for use with the US Commercial National Security Algorithm (CNSA) Suite.

The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that use TLS or DTLS. It is also appropriate for all other US Government systems that process high-value information.

The profile is made publicly available here for use by developers and operators of these and any other system deployments.

 draft-cooley-cnsa-dtls-tls-profile-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9151 RFC9152 Secure Object Delivery Protocol (SODP) Server Interfaces: NSA's Profile for Delivery of Certificates, Certificate Revocation Lists (CRLs), and Symmetric Keys to Clients M. Jenkins S. Turner April 2022 HTML TEXT PDF XML 18 CNSA NSS

This document specifies protocol interfaces profiled by the United States National Security Agency (NSA) for National Security System (NSS) servers that provide public key certificates, Certificate Revocation Lists (CRLs), and symmetric keys to NSS clients. Servers that support these interfaces are referred to as Secure Object Delivery Protocol (SODP) servers. The intended audience for this profile comprises developers of client devices that will obtain key management services from NSA-operated SODP servers. Interfaces supported by SODP servers include Enrollment over Secure Transport (EST) and its extensions as well as Certificate Management over CMS (CMC).

This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems (SP 800-59). It is also appropriate for other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

 draft-turner-sodp-profile-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9152 RFC9153 Drone Remote Identification Protocol (DRIP) Requirements and Terminology S. Card Editor A. Wiethuechter R. Moskowitz A. Gurtov February 2022 HTML TEXT PDF XML 41 DRIP

This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) Working Group. These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy.

 draft-ietf-drip-reqs-18 INFORMATIONAL INFORMATIONAL IETF int drip 10.17487/RFC9153 RFC9154 Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer J. Gould R. Wilhelm December 2021 HTML TEXT PDF XML 22 EPP authinfo random short-lived strong storing securely

The Extensible Provisioning Protocol (EPP) (RFC 5730) defines the use of authorization information to authorize a transfer of an EPP object, such as a domain name, between clients that are referred to as "registrars". Object-specific, password-based authorization information (see RFCs 5731 and 5733) is commonly used but raises issues related to the security, complexity, storage, and lifetime of authentication information. This document defines an operational practice, using the EPP RFCs, that leverages the use of strong random authorization information values that are short lived, not stored by the client, and stored by the server using a cryptographic hash that provides for secure authorization information that can safely be used for object transfers.

 draft-ietf-regext-secure-authinfo-transfer-07 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC9154 RFC9155 Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2 L. Velvindron K. Moriarty A. Ghedini December 2021 HTML TEXT PDF XML 5 tls

The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to attack, and this document deprecates their use in TLS 1.2 and DTLS 1.2 digital signatures. However, this document does not deprecate SHA-1 with Hashed Message Authentication Code (HMAC), as used in record protection. This document updates RFC 5246.

 draft-ietf-tls-md5-sha1-deprecate-09 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC9155 RFC9156 DNS Query Name Minimisation to Improve Privacy S. Bortzmeyer R. Dolmans P. Hoffman November 2021 HTML TEXT PDF XML 11 QNAME

This document describes a technique called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server. This document obsoletes RFC 7816.

 draft-ietf-dnsop-rfc7816bis-11 RFC7816 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC9156 RFC9157 Revised IANA Considerations for DNSSEC P. Hoffman December 2021 HTML TEXT PDF XML 5

This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for Delegation Signer (DS) records and NextSECure version 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence). It also updates RFCs 5155 and 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track. The rationale for these changes is to bring the requirements for DS records and hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms.

 draft-ietf-dnsop-dnssec-iana-cons-05 RFC5155 RFC6014 RFC8624 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC9157 RFC9158 Update to the Object Identifier Registry for the PKIX Working Group R. Housley November 2021 HTML TEXT PDF XML 4 Certificate Request Message Format CRMF CRMF Registration Controls Alternate Certificate Formats

RFC 7299 describes the object identifiers that were assigned by the Public Key Infrastructure using X.509 (PKIX) Working Group in an arc that was allocated by IANA (1.3.6.1.5.5.7). A small number of object identifiers that were assigned in RFC 4212 are omitted from RFC 7299, and this document updates RFC 7299 to correct that oversight.

 draft-ietf-lamps-rfc7299-update-02 RFC7299 INFORMATIONAL INFORMATIONAL IETF sec lamps 10.17487/RFC9158 RFC9159 IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP) C. Gomez S.M. Darroudi T. Savolainen M. Spoerk December 2021 HTML TEXT PDF XML 14 Bluetooth Low Energy mesh networks 6lowpan IPv6 Low power IoT Internet of Things

RFC 7668 describes the adaptation of IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques to enable IPv6 over Bluetooth Low Energy (Bluetooth LE) networks that follow the star topology. However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth LE links established by using the Bluetooth Internet Protocol Support Profile (IPSP). This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links.

 draft-ietf-6lo-blemesh-10 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC9159 RFC9160 Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX) T. Graf December 2021 HTML TEXT PDF XML 5 control plane migration traffic monitoring traffic accounting OSPF IS-IS BGP Prefix-SID PCE PCEP SR

This document introduces new IP Flow Information Export (IPFIX) code points to identify which traffic is being forwarded based on which MPLS control plane protocol is used within a Segment Routing domain. In particular, this document defines five code points for the IPFIX mplsTopLabelType Information Element for Path Computation Element (PCE), IS-IS, OSPFv2, OSPFv3, and BGP MPLS Segment Routing extensions.

 draft-ietf-opsawg-ipfix-mpls-sr-label-type-11 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC9160 RFC9161 Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks J. Rabadan Editor S. Sathappan K. Nagaraj G. Hankins T. King January 2022 HTML TEXT PDF XML 22

This document describes the Ethernet Virtual Private Network (EVPN) Proxy ARP/ND function augmented by the capability of the ARP/ND Extended Community. From that perspective, this document updates the EVPN specification to provide more comprehensive documentation of the operation of the Proxy ARP/ND function. The EVPN Proxy ARP/ND function and the ARP/ND Extended Community help operators of Internet Exchange Points, Data Centers, and other networks deal with IPv4 and IPv6 address resolution issues associated with large Broadcast Domains by reducing and even suppressing the flooding produced by address resolution in the EVPN network.

 draft-ietf-bess-evpn-proxy-arp-nd-16 RFC7432 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC9161 RFC9162 Certificate Transparency Version 2.0 B. Laurie E. Messeri R. Stradling December 2021 HTML TEXT PDF XML 53 certificates pkix tls website webpki browsers

This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.

This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts.

Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.

 draft-ietf-trans-rfc6962-bis-42 RFC6962 EXPERIMENTAL EXPERIMENTAL IETF sec trans 10.17487/RFC9162 RFC9163 Expect-CT Extension for HTTP E. Stark June 2022 HTML TEXT PDF XML 18 Certificate Transparency Expect-CT

This document defines a new HTTP header field named "Expect-CT", which allows web host operators to instruct user agents (UAs) to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. Expect-CT allows web host operators to discover misconfigurations in their Certificate Transparency (CT) deployments. Further, web host operators can use Expect-CT to ensure that if a UA that supports Expect-CT accepts a misissued certificate, that certificate will be discoverable in Certificate Transparency logs.

 draft-ietf-httpbis-expect-ct-08 EXPERIMENTAL EXPERIMENTAL IETF art httpbis 10.17487/RFC9163 RFC9164 Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes M. Richardson C. Bormann December 2021 HTML TEXT PDF XML 10 binary format data interchange format interface address zone identifier

This specification defines two Concise Binary Object Representation (CBOR) tags for use with IPv6 and IPv4 addresses and prefixes.

 draft-ietf-cbor-network-addresses-13 PROPOSED STANDARD PROPOSED STANDARD IETF art cbor 10.17487/RFC9164 RFC9165 Additional Control Operators for the Concise Data Definition Language (CDDL) C. Bormann December 2021 HTML TEXT PDF XML 11 binary format data interchange format description language schema language tree grammar ABNF Augmented BNF feature indication

The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point.

The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed: , , and for the construction of constants; / for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and for indicating the use of a non-basic feature in an instance.

 draft-ietf-cbor-cddl-control-07 PROPOSED STANDARD PROPOSED STANDARD IETF art cbor 10.17487/RFC9165 RFC9166 A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping H. Zhao X. Liu Y. Liu A. Peter M. Sivakumar February 2022 HTML TEXT PDF XML 37 YANG IGMP Snooping MLD Snooping multicast data model ietf-igmp-mld-snooping network management routing

This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping devices. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).

 draft-ietf-pim-igmp-mld-snooping-yang-20 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC9166 RFC9167 Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP) T. Sattler R. Carney J. Kolker December 2021 HTML TEXT PDF XML 22

This document describes an Extensible Provisioning Protocol (EPP) extension called "Registry Maintenance Notification", which is used by EPP servers to notify EPP clients and allow EPP clients to query EPP servers regarding maintenance events.

 draft-ietf-regext-epp-registry-maintenance-19 PROPOSED STANDARD PROPOSED STANDARD IETF art regext http://www.rfc-editor.org/errata_search.php?rfc=9167 10.17487/RFC9167 RFC9168 Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification D. Dhody A. Farrel Z. Li January 2022 HTML TEXT PDF XML 29 PCE FlowSpec Flow Spec

The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path.

Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes.

This document specifies a set of extensions to PCEP to support dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of.

The extensions defined in this document include the creation, update, and withdrawal of Flow Specifications via PCEP and can be applied to tunnels initiated by the PCE or to tunnels where control is delegated to the PCE by the Path Computation Client (PCC). Furthermore, a PCC requesting a new path can include Flow Specifications in the request to indicate the purpose of the tunnel allowing the PCE to factor this into the path computation.

 draft-ietf-pce-pcep-flowspec-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC9168 RFC9169 New ASN.1 Modules for the Evidence Record Syntax (ERS) R. Housley C. Wallace December 2021 HTML TEXT PDF XML 11 LTANS long-term archive

The Evidence Record Syntax (ERS) and the conventions for including these evidence records in the Server-based Certificate Validation Protocol (SCVP) are expressed using ASN.1. This document offers alternative ASN.1 modules that conform to the 2002 version of ASN.1 and employ the conventions adopted in RFCs 5911, 5912, and 6268. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the ASN.1 syntax.

 draft-housley-ers-asn1-modules-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC9169 RFC9170 Long-Term Viability of Protocol Extension Mechanisms M. Thomson T. Pauly December 2021 HTML TEXT PDF XML 17 Extensions versions grease

The ability to change protocols depends on exercising the extension and version-negotiation mechanisms that support change. This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly.

 draft-iab-use-it-or-lose-it-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC9170 RFC9171 Bundle Protocol Version 7 S. Burleigh K. Fall E. Birrane, III January 2022 HTML TEXT PDF XML 53 Delay-tolerant networking disruption-tolerant networking

This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050.

 draft-ietf-dtn-bpbis-31 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dtn http://www.rfc-editor.org/errata_search.php?rfc=9171 10.17487/RFC9171 RFC9172 Bundle Protocol Security (BPSec) E. Birrane, III K. McKeever January 2022 HTML TEXT PDF XML 35 security bundle integrity confidentiality

This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP).

 draft-ietf-dtn-bpsec-27 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dtn 10.17487/RFC9172 RFC9173 Default Security Contexts for Bundle Protocol Security (BPSec) E. Birrane, III A. White S. Heiner January 2022 HTML TEXT PDF XML 51 security bundle integrity confidentiality

This document defines default integrity and confidentiality security contexts that can be used with Bundle Protocol Security (BPSec) implementations. These security contexts are intended to be used both for testing the interoperability of BPSec implementations and for providing basic security operations when no other security contexts are defined or otherwise required for a network.

 draft-ietf-dtn-bpsec-default-sc-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dtn http://www.rfc-editor.org/errata_search.php?rfc=9173 10.17487/RFC9173 RFC9174 Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4 B. Sipos M. Demmer J. Ott S. Perreault January 2022 HTML TEXT PDF XML 62

This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles. This TCPCL version also includes security and extensibility mechanisms.

 draft-ietf-dtn-tcpclv4-28 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dtn 10.17487/RFC9174 RFC9175 Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing C. Amsüss J. Preuß Mattsson G. Selander February 2022 HTML TEXT PDF XML 27 OSCORE block-wise DTLS freshness delay denial-of-service amplification Message Body Integrity Concurrent Block-Wise Request-Response Binding Token Reuse

This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and amplification mitigation (where the use of the Echo option is now recommended).

 draft-ietf-core-echo-request-tag-14 RFC7252 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC9175 RFC9176 Constrained RESTful Environments (CoRE) Resource Directory C. Amsüss Editor Z. Shelby M. Koster C. Bormann P. van der Stok April 2022 HTML TEXT PDF XML 60 CoRE Web Linking Resource Discovery Resource Directory

In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined.

 draft-ietf-core-resource-directory-28 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC9176 RFC9177 Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission M. Boucadair J. Shallow March 2022 HTML TEXT PDF XML 41 Quick-Block Robust-Block R-Block Tough-Block Resilient-Block Fast-Block Resilience Filtering Faster transmission Large amounts of data Less packet interchange Fast recovery DOTS

This document specifies alternative Constrained Application Protocol (CoAP) block-wise transfer options: Q-Block1 and Q-Block2.

These options are similar to, but distinct from, the CoAP Block1 and Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission.

 draft-ietf-core-new-block-14 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC9177 RFC9178 Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks J. Arkko A. Eriksson A. Keränen May 2022 HTML TEXT PDF XML 14 CoAP cellular networks

This memo discusses the use of the Constrained Application Protocol (CoAP) in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption.

 draft-ietf-lwig-cellular-06 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC9178 RFC9179 A YANG Grouping for Geographic Locations C. Hopps February 2022 HTML TEXT PDF XML 22 geolocation

This document defines a generic geographical location YANG grouping. The geographical location grouping is intended to be used in YANG data models for specifying a location on or in reference to Earth or any other astronomical object.

 draft-ietf-netmod-geo-location-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC9179 RFC9180 Hybrid Public Key Encryption R. Barnes K. Bhargavan B. Lipp C. Wood February 2022 HTML TEXT PDF XML 107 public-key encryption key encapsulation post-quantum public-key encryption

This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2.

This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

 draft-irtf-cfrg-hpke-12 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=9180 10.17487/RFC9180 RFC9181 A Common YANG Data Model for Layer 2 and Layer 3 VPNs S. Barguil O. Gonzalez de Dios Editor M. Boucadair Editor Q. Wu February 2022 HTML TEXT PDF XML 60 service automation network automation service delivery service provisioning Slice network slicing vitalisation Automation Network Models

This document defines a common YANG module that is meant to be reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN network models.

 draft-ietf-opsawg-vpn-common-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC9181 RFC9182 A YANG Network Data Model for Layer 3 VPNs S. Barguil O. Gonzalez de Dios Editor M. Boucadair Editor L. Munoz A. Aguado February 2022 HTML TEXT PDF XML 129 l3vpn Automation Service Provisioning Network Automation Service Orchestration Service Delivery NETCONF RESTCONF Slices network slicing

As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services.

The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator.

 draft-ietf-opsawg-l3sm-l3nm-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC9182 RFC9183 Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL) M. Zhang D. Eastlake 3rd R. Perlman M. Cullen H. Zhai February 2022 HTML TEXT PDF XML 13 aggregated

A major issue in multilevel TRILL is how to manage RBridge nicknames. In this document, area border RBridges use a single nickname in both Level 1 and Level 2. RBridges in Level 2 must obtain unique nicknames but RBridges in different Level 1 areas may have the same nicknames.

 draft-ietf-trill-multilevel-single-nickname-17 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC9183 RFC9184 BGP Extended Community Registries Update C. Loibl January 2022 HTML TEXT PDF XML 5 IANA

This document updates several BGP Extended Community registries in order to replace the "Experimental Use" registration procedure in some entries, since their use is clearly not experimental and is thus misleading.

This document updates RFCs 7153 and 8955.

 draft-ietf-idr-bgp-ext-com-registry-05 RFC7153 RFC8955 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC9184 RFC9185 DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange P. Jones P. Ellenbogen N. Ohlmeier April 2022 HTML TEXT PDF XML 18 PERC SRTP RTP DTLS DTLS-SRTP DTLS tunnel conferencing security

This document defines a protocol for tunneling DTLS traffic in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the Key Distributor. The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the Media Distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to the Media Distributor.

 draft-ietf-perc-dtls-tunnel-12 INFORMATIONAL INFORMATIONAL IETF art perc 10.17487/RFC9185 RFC9186 Fast Failover in Protocol Independent Multicast - Sparse Mode (PIM-SM) Using Bidirectional Forwarding Detection (BFD) for Multipoint Networks G. Mirsky X. Ji January 2022 HTML TEXT PDF XML 7 PIM-SM BFD

This document specifies how Bidirectional Forwarding Detection (BFD) for multipoint networks can provide sub-second failover for routers that participate in Protocol Independent Multicast - Sparse Mode (PIM-SM). An extension to the PIM Hello message used to bootstrap a point-to-multipoint BFD session is also defined in this document.

 draft-ietf-pim-bfd-p2mp-use-case-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC9186 RFC9187 Sequence Number Extension for Windowed Protocols J. Touch January 2022 HTML TEXT PDF XML 10

Sliding window protocols use finite sequence numbers to determine segment placement and order. These sequence number spaces wrap around and are reused during the operation of such protocols. This document describes a way to extend the size of these sequence numbers at the endpoints to avoid the impact of that wrap and reuse without transmitting additional information in the packet header. The resulting extended sequence numbers can be used at the endpoints in encryption and authentication algorithms to ensure input bit patterns do not repeat over the lifetime of a connection.

 draft-touch-sne-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=9187 10.17487/RFC9187 RFC9188 Generic Multi-Access (GMA) Encapsulation Protocol J. Zhu S. Kanugovi February 2022 HTML TEXT PDF XML 15

A device can be simultaneously connected to multiple networks, e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly combine the connectivity over these networks below the transport layer (L4) to improve the quality of experience for applications that do not have built-in multi-path capabilities. Such optimization requires additional control information, e.g., a sequence number, in each packet. This document presents a new lightweight and flexible encapsulation protocol for this need. The solution has been developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP. However, this document is not an Internet Standard and does not represent the consensus opinion of the IETF. This document will enable other developers to build interoperable implementations in order to experiment with the protocol.

 draft-zhu-intarea-gma-14 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC9188 RFC9189 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2 S. Smyshlyaev Editor D. Belyavsky E. Alekseev March 2022 HTML TEXT PDF XML 92 GOST cipher suite TLS

This document specifies three new cipher suites, two new signature algorithms, seven new supported groups, and two new certificate types for the Transport Layer Security (TLS) protocol version 1.2 to support the Russian cryptographic standard algorithms (called "GOST" algorithms). This document specifies a profile of TLS 1.2 with GOST algorithms so that implementers can produce interoperable implementations.

This specification facilitates implementations that aim to support the GOST algorithms. This document does not imply IETF endorsement of the cipher suites, signature algorithms, supported groups, and certificate types.

 draft-smyshlyaev-tls12-gost-suites-18 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9189 RFC9190 EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3 J. Preuß Mattsson M. Sethi February 2022 HTML TEXT PDF XML 31

The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216.

 draft-ietf-emu-eap-tls13-21 RFC5216 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu 10.17487/RFC9190 RFC9191 Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods M. Sethi J. Preuß Mattsson S. Turner February 2022 HTML TEXT PDF XML 12 EAP-TLS X.509 EAP authenticator Maximum Transmission Unit (MTU)

The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. EAP-TLS and other TLS-based EAP methods are widely deployed and used for network access authentication. Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round trips is a major deployment problem. This document looks at this problem in detail and describes the potential solutions available.

 draft-ietf-emu-eaptlscert-08 INFORMATIONAL INFORMATIONAL IETF sec emu 10.17487/RFC9191 RFC9192 Network Service Header (NSH) Fixed-Length Context Header Allocation T. Mizrahi I. Yerushalmi D. Melman R. Browne February 2022 HTML TEXT PDF XML 10 NSH Context Header timestamp

The Network Service Header (NSH) specification defines two possible methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MD Type 0x1 uses a fixed-length Context Header. The allocation of this Context Header, i.e., its structure and semantics, has not been standardized. This memo defines the Timestamp Context Header, which is an NSH fixed-length Context Header that incorporates the packet's timestamp, a sequence number, and a source interface identifier.

Although the definition of the Context Header presented in this document has not been standardized by the IETF, it has been implemented in silicon by several manufacturers and is published here to facilitate interoperability.

 draft-mymb-sfc-nsh-allocation-timestamp-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9192 RFC9193 Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format A. Keränen C. Bormann June 2022 HTML TEXT PDF XML 10 Internet of Things (IoT) Internet of Things IOT data model media type

The Sensor Measurement Lists (SenML) media types support multiple types of values, from numbers to text strings and arbitrary binary Data Values. In order to facilitate processing of binary Data Values, this document specifies a pair of new SenML fields for indicating the content format of those binary Data Values, i.e., their Internet media type, including parameters as well as any content codings applied.

 draft-ietf-core-senml-data-ct-07 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC9193 RFC9194 A YANG Module for IS-IS Reverse Metric C. Hopps October 2022 HTML TEXT PDF XML 13

This document defines a YANG module for managing the reverse metric extension to the Intermediate System to Intermediate System (IS-IS) intra-domain routing information exchange protocol.

 draft-ietf-lsr-yang-isis-reverse-metric-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC9194 RFC9195 A File Format for YANG Instance Data B. Lengyel B. Claise February 2022 HTML TEXT PDF XML 24

There is a need to document data defined in YANG models at design time, implementation time, or when a live server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models and annotates it with metadata.

 draft-ietf-netmod-yang-instance-file-format-21 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC9195 RFC9196 YANG Modules Describing Capabilities for Systems and Datastore Update Notifications B. Lengyel A. Clemm B. Claise February 2022 HTML TEXT PDF XML 22 NMDA NETCONF RESTCONF

This document defines two YANG modules, "ietf-system-capabilities" and "ietf-notification-capabilities".

The module "ietf-system-capabilities" provides a placeholder structure that can be used to discover YANG-related system capabilities for servers. The module can be used to report capability information from the server at runtime or at implementation time by making use of the YANG instance data file format.

The module "ietf-notification-capabilities" augments "ietf-system-capabilities" to specify capabilities related to "Subscription to YANG Notifications for Datastore Updates" (RFC 8641).

 draft-ietf-netconf-notification-capabilities-21 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=9196 10.17487/RFC9196 RFC9197 Data Fields for In Situ Operations, Administration, and Maintenance (IOAM) F. Brockners Editor S. Bhandari Editor T. Mizrahi Editor May 2022 HTML TEXT PDF XML 40 inband Telemetry Tracing

In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets.

 draft-ietf-ippm-ioam-data-17 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=9197 10.17487/RFC9197 RFC9198 Advanced Unidirectional Route Assessment (AURA) J. Alvarez-Hamelin A. Morton J. Fabini C. Pignataro R. Geib May 2022 HTML TEXT PDF XML 23 Performance Metrics IPPM path parallel paths

This memo introduces an advanced unidirectional route assessment (AURA) metric and associated measurement methodology based on the IP Performance Metrics (IPPM) framework (RFC 2330). This memo updates RFC 2330 in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths between a given Source and Destination pair, owing to the presence of multipath technologies.

 draft-ietf-ippm-route-10 RFC2330 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC9198 RFC9199 Considerations for Large Authoritative DNS Server Operators G. Moura W. Hardaker J. Heidemann M. Davids March 2022 HTML TEXT PDF XML 17 Routing DNS Anycast Domain Name System BGP

Recent research work has explored the deployment characteristics and configuration of the Domain Name System (DNS). This document summarizes the conclusions from these research efforts and offers specific, tangible considerations or advice to authoritative DNS server operators. Authoritative server operators may wish to follow these considerations to improve their DNS services.

It is possible that the results presented in this document could be applicable in a wider context than just the DNS protocol, as some of the results may generically apply to any stateless/short-duration anycasted service.

This document is not an IETF consensus document: it is published for informational purposes.

 draft-moura-dnsop-authoritative-recommendations-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9199 RFC9200 Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) L. Seitz G. Selander E. Wahlstroem S. Erdtman H. Tschofenig August 2022 HTML TEXT PDF XML 72 CoAP OAuth 2.0 Access Control Authorization Internet of Things

This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases.

 draft-ietf-ace-oauth-authz-46 PROPOSED STANDARD PROPOSED STANDARD IETF sec ace 10.17487/RFC9200 RFC9201 Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE) L. Seitz August 2022 HTML TEXT PDF XML 11 CoAP OAuth 2.0 Access Control Authorization Internet of Things

This specification defines new parameters and encodings for the OAuth 2.0 token and introspection endpoints when used with the framework for Authentication and Authorization for Constrained Environments (ACE). These are used to express the proof-of-possession (PoP) key the client wishes to use, the PoP key that the authorization server has selected, and the PoP key the resource server uses to authenticate to the client.

 draft-ietf-ace-oauth-params-16 PROPOSED STANDARD PROPOSED STANDARD IETF sec ace 10.17487/RFC9201 RFC9202 Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) S. Gerdes O. Bergmann C. Bormann G. Selander L. Seitz August 2022 HTML TEXT PDF XML 23 Internet of Thinks (IoT) Internet of Things IOT OAuth Access Token

This specification defines a profile of the Authentication and Authorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory.

 draft-ietf-ace-dtls-authorize-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec ace 10.17487/RFC9202 RFC9203 The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework F. Palombini L. Seitz G. Selander M. Gunnarsson August 2022 HTML TEXT PDF XML 28 CoAP OAuth 2.0 Access Control Authorization Internet of Things

This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token.

 draft-ietf-ace-oscore-profile-19 PROPOSED STANDARD PROPOSED STANDARD IETF sec ace 10.17487/RFC9203 RFC9204 QPACK: Field Compression for HTTP/3 C. Krasic M. Bishop A. Frindell Editor June 2022 HTML TEXT PDF XML 41 Transport QUIC compression HTTP/3 HPACK header field trailer

This specification defines QPACK: a compression format for efficiently representing HTTP fields that is to be used in HTTP/3. This is a variation of HPACK compression that seeks to reduce head-of-line blocking.

 draft-ietf-quic-qpack-21 PROPOSED STANDARD PROPOSED STANDARD IETF tsv quic http://www.rfc-editor.org/errata_search.php?rfc=9204 10.17487/RFC9204 RFC9205 Building Protocols with HTTP M. Nottingham June 2022 HTML TEXT PDF XML 27 HTTP API

Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations.

This document obsoletes RFC 3205.

 draft-ietf-httpbis-bcp56bis-15 RFC3205 BCP0056 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF art httpbis 10.17487/RFC9205 RFC9206 Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec) L. Corcoran M. Jenkins February 2022 HTML TEXT PDF XML 13 post quantum quantum resistant NSA

The United States Government has published the National Security Agency's Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Internet Protocol Security (IPsec). It applies to the capabilities, configuration, and operation of all components of US National Security Systems (described in NIST Special Publication 800-59) that employ IPsec. This document is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

 draft-corcoran-cnsa-ipsec-profile-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9206 RFC9207 OAuth 2.0 Authorization Server Issuer Identification K. Meyer zu Selhausen D. Fett March 2022 HTML TEXT PDF XML 9 security oauth2

This document specifies a new parameter called iss. This parameter is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. The iss parameter serves as an effective countermeasure to "mix-up attacks".

 draft-ietf-oauth-iss-auth-resp-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC9207 RFC9208 IMAP QUOTA Extension A. Melnikov March 2022 HTML TEXT PDF XML 19

This document defines a QUOTA extension of the Internet Message Access Protocol (IMAP) (see RFCs 3501 and 9051) that permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol.

This document obsoletes RFC 2087 but attempts to remain backwards compatible whenever possible.

 draft-ietf-extra-quota-10 RFC2087 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC9208 RFC9209 The Proxy-Status HTTP Response Header Field M. Nottingham P. Sikora June 2022 HTML TEXT PDF XML 22 proxy intermediary reverse proxy

This document defines the Proxy-Status HTTP response field to convey the details of an intermediary's response handling, including generated errors.

 draft-ietf-httpbis-proxy-status-08 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC9209 RFC9210 DNS Transport over TCP - Operational Requirements J. Kristoff D. Wessels March 2022 HTML TEXT PDF XML 29 DNS TCP

This document updates RFCs 1123 and 1536. This document requires the operational practice of permitting DNS messages to be carried over TCP on the Internet as a Best Current Practice. This operational requirement is aligned with the implementation requirements in RFC 7766. The use of TCP includes both DNS over unencrypted TCP as well as over an encrypted TLS session. The document also considers the consequences of this form of DNS communication and the potential operational issues that can arise when this Best Current Practice is not upheld.

 draft-ietf-dnsop-dns-tcp-requirements-15 RFC1123 RFC1536 BCP0235 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC9210 RFC9211 The Cache-Status HTTP Response Header Field M. Nottingham June 2022 HTML TEXT PDF XML 9 http cache debugging x-cache

To aid debugging, HTTP caches often append header fields to a response, explaining how they handled the request in an ad hoc manner. This specification defines a standard mechanism to do so that is aligned with HTTP's caching model.

 draft-ietf-httpbis-cache-header-10 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC9211 RFC9212 Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH) N. Gajcowski M. Jenkins March 2022 HTML TEXT PDF XML 10 NSS remote administration

The United States Government has published the National Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms with the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol. It applies to the capabilities, configuration, and operation of all components of US National Security Systems (described in NIST Special Publication 800-59) that employ Secure Shell (SSH). This document is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

 draft-gajcowski-cnsa-ssh-profile-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9212 RFC9213 Targeted HTTP Cache Control S. Ludin M. Nottingham Y. Wu June 2022 HTML TEXT PDF XML 8 CDN Content Delivery Network Caching

This specification defines a convention for HTTP response header fields that allow cache directives to be targeted at specific caches or classes of caches. It also defines one such header field, the CDN-Cache-Control response header field, which is targeted at content delivery network (CDN) caches.

 draft-ietf-httpbis-targeted-cache-control-04 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC9213 RFC9214 OSPFv3 Code Point for MPLS LSP Ping N. Nainar C. Pignataro M. Aissaoui April 2022 HTML TEXT PDF XML 6 MPLS

IANA has created "Protocol in the Segment ID Sub-TLV" and "Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV" registries under the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. RFC 8287 defines the code points for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) protocols.

This document specifies the code point to be used in the Segment ID sub-TLV and Downstream Detailed Mapping (DDMAP) TLV when the Interior Gateway Protocol (IGP) is OSPFv3. This document also updates RFC 8287 by clarifying that the existing "OSPF" code point is to be used only to indicate OSPFv2 and by defining the behavior when the Segment ID sub-TLV indicates the use of IPv6.

 draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06 RFC8287 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC9214 RFC9215 Using GOST R 34.10-2012 and GOST R 34.11-2012 Algorithms with the Internet X.509 Public Key Infrastructure D. Baryshkov Editor V. Nikolaev A. Chelpanov March 2022 HTML TEXT PDF XML 38 GOST PKI

This document describes encoding formats, identifiers, and parameter formats for the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for use in the Internet X.509 Public Key Infrastructure (PKI).

This specification is developed to facilitate implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used in this document.

 draft-deremin-rfc4491-bis-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9215 RFC9216 S/MIME Example Keys and Certificates D. K. Gillmor Editor April 2022 HTML TEXT PDF XML 32 pkix encryption security authentication S/MIME smime email mail confidentiality certificate pkcs8 pkcs12 x509 "test vector"

The S/MIME development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of X.509v3 certificates and keys for use when generating such samples.

 draft-ietf-lamps-samples-08 INFORMATIONAL INFORMATIONAL IETF sec lamps http://www.rfc-editor.org/errata_search.php?rfc=9216 10.17487/RFC9216 RFC9217 Current Open Questions in Path-Aware Networking B. Trammell March 2022 HTML TEXT PDF XML 9

In contrast to the present Internet architecture, a path-aware internetworking architecture has two important properties: it exposes the properties of available Internet paths to endpoints, and it provides for endpoints and applications to use these properties to select paths through the Internet for their traffic. While this property of "path awareness" already exists in many Internet-connected networks within single domains and via administrative interfaces to the network layer, a fully path-aware internetwork expands these concepts across layers and across the Internet.

This document poses questions in path-aware networking, open as of 2021, that must be answered in the design, development, and deployment of path-aware internetworks. It was originally written to frame discussions in the Path Aware Networking Research Group (PANRG), and has been published to snapshot current thinking in this space.

 draft-irtf-panrg-questions-12 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC9217 RFC9218 Extensible Prioritization Scheme for HTTP K. Oku L. Pardue June 2022 HTML TEXT PDF XML 21 Response priority Stream multiplexing Reprioritization Server scheduling

This document describes a scheme that allows an HTTP client to communicate its preferences for how the upstream server prioritizes responses to its requests, and also allows a server to hint to a downstream intermediary how its responses should be prioritized when they are forwarded. This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing responses. These share a common format structure that is designed to provide future extensibility.

 draft-ietf-httpbis-priority-12 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC9218 RFC9219 S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP) A. Melnikov April 2022 HTML TEXT PDF XML 10 JMAP S/MIME

This document specifies an extension to "The JSON Meta Application Protocol (JMAP) for Mail" (RFC 8621) for returning the S/MIME signature verification status.

 draft-ietf-jmap-smime-12 PROPOSED STANDARD PROPOSED STANDARD IETF art jmap 10.17487/RFC9219 RFC9220 Bootstrapping WebSockets with HTTP/3 R. Hamilton June 2022 HTML TEXT PDF XML 4 extended connect 42

The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3.

 draft-ietf-httpbis-h3-websockets-04 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC9220 RFC9221 An Unreliable Datagram Extension to QUIC T. Pauly E. Kinnear D. Schinazi March 2022 HTML TEXT PDF XML 9

This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection.

 draft-ietf-quic-datagram-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv quic 10.17487/RFC9221 RFC9222 Guidelines for Autonomic Service Agents B. E. Carpenter L. Ciavaglia S. Jiang P. Peloso March 2022 HTML TEXT PDF XML 23 GRASP autonomous autonomic function self-management

This document proposes guidelines for the design of Autonomic Service Agents for autonomic networks. Autonomic Service Agents, together with the Autonomic Network Infrastructure, the Autonomic Control Plane, and the GeneRic Autonomic Signaling Protocol, constitute base elements of an autonomic networking ecosystem.

 draft-ietf-anima-asa-guidelines-07 INFORMATIONAL INFORMATIONAL IETF ops anima 10.17487/RFC9222 RFC9223 Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE) W. Zia T. Stockhammer L. Chaponniere G. Mandyam M. Luby April 2022 HTML TEXT PDF XML 35 Multicast Broadcast FEC DASH HLS FLUTE

The Real-time Transport Object delivery over Unidirectional Transport (ROUTE) protocol is specified for robust delivery of Application Objects, including Application Objects with real-time delivery constraints, to receivers over a unidirectional transport. Application Objects consist of data that has meaning to applications that use the ROUTE protocol for delivery of data to receivers; for example, it can be a file, a Dynamic Adaptive Streaming over HTTP (DASH) or HTTP Live Streaming (HLS) segment, a WAV audio clip, etc. The ROUTE protocol also supports low-latency streaming applications.

The ROUTE protocol is suitable for unicast, broadcast, and multicast transport. Therefore, it can be run over UDP/IP, including multicast IP. The ROUTE protocol can leverage the features of the underlying protocol layer, e.g., to provide security, it can leverage IP security protocols such as IPsec.

This document specifies the ROUTE protocol such that it could be used by a variety of services for delivery of Application Objects by specifying their own profiles of this protocol (e.g., by adding or constraining some features).

This is not an IETF specification and does not have IETF consensus.

 draft-zia-route-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9223 RFC9224 Finding the Authoritative Registration Data Access Protocol (RDAP) Service M. Blanchet March 2022 HTML TEXT PDF XML 15 whois bootstrap domain IDN DNS AS IPv4 IPv6 JSON

This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers. This document obsoletes RFC 7484.

 draft-ietf-regext-rfc7484bis-06 RFC7484 STD0095 INTERNET STANDARD INTERNET STANDARD IETF art regext 10.17487/RFC9224 RFC9225 Software Defects Considered Harmful J. Snijders C. Morrow R. van Mook April 1 2022 HTML TEXT PDF XML 6 bugs

This document discourages the practice of introducing software defects in general and in network protocol implementations specifically. Software defects are one of the largest cost drivers for the networking industry. This document is intended to clarify the best current practice in this regard.

 draft-dont-write-bugs-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=9225 10.17487/RFC9225 RFC9226 Bioctal: Hexadecimal 2.0 M. Breen April 1 2022 HTML TEXT PDF XML 7

The prevailing hexadecimal system was chosen for congruence with groups of four binary digits, but its design exhibits an indifference to cognitive factors. An alternative is introduced that is designed to reduce brain cycles in cases where a hexadecimal number should be readily convertible to binary by a human being.

 draft-breen-bioctal-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC9226 RFC9227 Using GOST Ciphers in the Encapsulating Security Payload (ESP) and Internet Key Exchange Version 2 (IKEv2) Protocols V. Smyslov March 2022 HTML TEXT PDF XML 22 AEAD MGM

This document defines a set of encryption transforms for use in the Encapsulating Security Payload (ESP) and in the Internet Key Exchange version 2 (IKEv2) protocols, which are parts of the IP Security (IPsec) protocol suite. The transforms are based on the GOST R 34.12-2015 block ciphers (which are named "Magma" and "Kuznyechik") in Multilinear Galois Mode (MGM) and the external rekeying approach.

This specification was developed to facilitate implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used in this document.

 draft-smyslov-esp-gost-14 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9227 RFC9228 Delivered-To Email Header Field D. Crocker Editor April 2022 HTML TEXT PDF XML 10 handling email mhs recipient transport delivery mda mta relay header

The address to which email is delivered might be different than any of the addresses shown in any of the content header fields that were created by the email's author. For example, the address used by the email transport service is provided separately, such as through SMTP's "RCPT TO" command, and might not match any address in the To: or cc: fields. In addition, before final delivery, handling can entail a sequence of submission/delivery events, using a sequence of different destination addresses that (eventually) lead to the recipient. As well, a receiving system's delivery process can produce local address transformations.

It can be helpful for a message to have a common way to record each delivery in such a sequence, noting each address used in the sequence to that recipient, such as for (1) analyzing the path a message has taken, (2) loop detection, or (3) formulating the author's address in a reply message. This document defines a header field for this information.

Email handling information discloses details about the email infrastructure, as well as about a particular recipient; this can raise privacy concerns.

A header field such as this is not automatically assured of widespread use. Therefore, this document is being published as an Experimental RFC, looking for constituency and for operational utility. This document was produced through the Independent Submission Stream and was not subject to the IETF's approval process.

 draft-crocker-email-deliveredto-10 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC9228 RFC9229 IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol J. Chroboczek May 2022 HTML TEXT PDF XML 9 routing transition IPv6 transition double-stack dual-stack glorious IPv6-only future

This document defines an extension to the Babel routing protocol that allows announcing routes to an IPv4 prefix with an IPv6 next hop, which makes it possible for IPv4 traffic to flow through interfaces that have not been assigned an IPv4 address.

 draft-ietf-babel-v4viav6-08 EXPERIMENTAL EXPERIMENTAL IETF rtg babel 10.17487/RFC9229 RFC9230 Oblivious DNS over HTTPS E. Kinnear P. McManus T. Pauly T. Verma C.A. Wood June 2022 HTML TEXT PDF XML 19 Privacy DNS Privacy DoH ODoH HPKE

This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers.

This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation.

 draft-pauly-dprive-oblivious-doh-11 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=9230 10.17487/RFC9230 RFC9231 Additional XML Security Uniform Resource Identifiers (URIs) D. Eastlake 3rd July 2022 HTML TEXT PDF XML 47 XMLSEC XMLDSIG XMLENC DigestMethod SigntureMethod EncryptionMethod AgreementMethod KeyDerivationMethod KeyInfo

This document updates and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document also obsoletes and corrects three errata against RFC 6931.

 draft-eastlake-rfc6931bis-xmlsec-uris-27 RFC6931 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC9231 RFC9232 Network Telemetry Framework H. Song F. Qin P. Martinez-Julia L. Ciavaglia A. Wang May 2022 HTML TEXT PDF XML 33 Telemetry OAM

Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management. It encompasses various techniques for remote data generation, collection, correlation, and consumption. This document describes an architectural framework for network telemetry, motivated by challenges that are encountered as part of the operation of networks and by the requirements that ensue. This document clarifies the terminology and classifies the modules and components of a network telemetry system from different perspectives. The framework and taxonomy help to set a common ground for the collection of related work and provide guidance for related technique and standard developments.

 draft-ietf-opsawg-ntf-13 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC9232 RFC9233 Internationalized Domain Names for Applications 2008 (IDNA2008) and Unicode 12.0.0 P. Fältström March 2022 HTML TEXT PDF XML 26 IDN IDNA IDNA2008

This document describes the changes between Unicode 6.0.0 and Unicode 12.0.0 in the context of the current version of Internationalized Domain Names for Applications 2008 (IDNA2008). Some additions and changes have been made in the Unicode Standard that affect the values produced by the algorithm IDNA2008 specifies. IDNA2008 allows adding exceptions to the algorithm for backward compatibility; however, this document does not add any such exceptions. This document provides the necessary tables to IANA to make its database consistent with Unicode 12.0.0.

To improve understanding, this document describes systems that are being used as alternatives to those that conform to IDNA2008.

 draft-faltstrom-unicode12-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC9233 RFC9234 Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages A. Azimov E. Bogomazov R. Bush K. Patel K. Sriram May 2022 HTML TEXT PDF XML 12 BGP Route leak BGP Role

Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes). Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks.

 draft-ietf-idr-bgp-open-policy-24 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC9234 RFC9235 TCP Authentication Option (TCP-AO) Test Vectors J. Touch J. Kuusisaari May 2022 HTML TEXT PDF XML 25 TCP authentication option test vector

This document provides test vectors to validate implementations of the two mandatory authentication algorithms specified for the TCP Authentication Option over both IPv4 and IPv6. This includes validation of the key derivation function (KDF) based on a set of test connection parameters as well as validation of the message authentication code (MAC). Vectors are provided for both currently required pairs of KDF and MAC algorithms: KDF_HMAC_SHA1 and HMAC- SHA-1-96, and KDF_AES_128_CMAC and AES-128-CMAC-96. The vectors also validate both whole TCP segments as well as segments whose options are excluded for middlebox traversal.

 draft-ietf-tcpm-ao-test-vectors-09 INFORMATIONAL INFORMATIONAL IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=9235 10.17487/RFC9235 RFC9236 Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service J. Hong T. You V. Kafle April 2022 HTML TEXT PDF XML 11 Information-Centric Networking Name Resolution Service Name to location mapping

This document describes architectural considerations and implications related to the use of a Name Resolution Service (NRS) in Information-Centric Networking (ICN). It explains how the ICN architecture can change when an NRS is utilized and how its use influences the ICN routing system. This document is a product of the Information-Centric Networking Research Group (ICNRG).

 draft-irtf-icnrg-nrsarch-considerations-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC9236 RFC9237 An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE) C. Bormann August 2022 HTML TEXT PDF XML 14 OAuth IoT Internet of Things Access Control

Information about which entities are authorized to perform what operations on which constituents of other entities is a crucial component of producing an overall system that is secure. Conveying precise authorization information is especially critical in highly automated systems with large numbers of entities, such as the Internet of Things.

This specification provides a generic information model and format for representing such authorization information, as well as two variants of a specific instantiation of that format for use with Representational State Transfer (REST) resources identified by URI path.

 draft-ietf-ace-aif-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec ace 10.17487/RFC9237 RFC9238 Loading Manufacturer Usage Description (MUD) URLs from QR Codes M. Richardson J. Latour H. Habibi Gharakheili May 2022 HTML TEXT PDF XML 12 RLA ISOIEC189004 ANSI MH10.8.2

This informational document details a protocol to load Manufacturer Usage Description (MUD) definitions from RFC 8520 for devices that do not have them integrated.

This document is published to inform the Internet community of this mechanism to allow interoperability and to serve as a basis of other standards work if there is interest.

 draft-richardson-mud-qrcode-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9238 RFC9239 Updates to ECMAScript Media Types M. Miller M. Borins M. Bynens B. Farias May 2022 HTML TEXT PDF XML 13 JavaScript ECMAScript MIME type Content-Type modules TC39 ESM

This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This document obsoletes RFC 4329 ("Scripting Media Types)", replacing the previous registrations with information and requirements aligned with common usage and implementation experiences.

 draft-ietf-dispatch-javascript-mjs-17 RFC4329 INFORMATIONAL INFORMATIONAL IETF art dispatch 10.17487/RFC9239 RFC9240 An Extension for Application-Layer Traffic Optimization (ALTO): Entity Property Maps W. Roome S. Randriamasy Y. Yang J. Zhang K. Gao July 2022 HTML TEXT PDF XML 53 ALTO

This document specifies an extension to the base Application-Layer Traffic Optimization (ALTO) Protocol that generalizes the concept of "endpoint properties", which have been tied to IP addresses so far, to entities defined by a wide set of objects. Further, these properties are presented as maps, similar to the network and cost maps in the base ALTO Protocol. While supporting the endpoints and related Endpoint Property Service defined in RFC 7285, the ALTO Protocol is extended in two major directions. First, from endpoints restricted to IP addresses to entities covering a wider and extensible set of objects; second, from properties for specific endpoints to entire entity property maps. These extensions introduce additional features that allow entities and property values to be specific to a given information resource. This is made possible by a generic and flexible design of entity and property types.

 draft-ietf-alto-unified-props-new-24 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC9240 RFC9241 Content Delivery Network Interconnection (CDNI) Footprint and Capabilities Advertisement Using Application-Layer Traffic Optimization (ALTO) J. Seedorf Y. Yang K. Ma J. Peterson J. Zhang July 2022 HTML TEXT PDF XML 42 ALTO

The Content Delivery Networks Interconnection (CDNI) framework in RFC 6707 defines a set of protocols to interconnect CDNs to achieve multiple goals, including extending the reach of a given CDN. A CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI) is needed to achieve the goals of a CDNI. RFC 8008 defines the FCI semantics and provides guidelines on the FCI protocol, but the exact protocol is not specified. This document defines a new Application-Layer Traffic Optimization (ALTO) service, called "CDNI Advertisement Service", that provides an implementation of the FCI, following the guidelines defined in RFC 8008.

 draft-ietf-alto-cdni-request-routing-alto-22 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC9241 RFC9242 Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2) V. Smyslov May 2022 HTML TEXT PDF XML 14 IKE_INTERMEDIATE Quantum Computer resistant key exchange method Post-quantum

This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment. The Intermediate Exchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established.

 draft-ietf-ipsecme-ikev2-intermediate-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC9242 RFC9243 A YANG Data Model for DHCPv6 Configuration I. Farrer Editor June 2022 HTML TEXT PDF XML 92 YANG NETCONF REST data model DHCPv6 IPv6 configuration management lease prefix delegation address pool prefix pool

This document describes YANG data models for the configuration and management of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (RFC 8415) servers, relays, and clients.

 draft-ietf-dhc-dhcpv6-yang-25 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC9243 RFC9244 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry M. Boucadair Editor T. Reddy.K Editor E. Doron M. Chen J. Shallow June 2022 HTML TEXT PDF XML 108 automation cybersecurity DDoS Resilience Intelligence Service delivery Robustness Collaborative

This document aims to enrich the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol with various telemetry attributes, allowing for optimal Distributed Denial-of-Service (DDoS) attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator in choosing the DDoS mitigation techniques and performing optimal DDoS attack mitigation.

This document specifies two YANG modules: one for representing DOTS telemetry message types and one for sharing the attack mapping details over the DOTS data channel.

 draft-ietf-dots-telemetry-25 PROPOSED STANDARD PROPOSED STANDARD IETF sec dots 10.17487/RFC9244 RFC9245 IETF Discussion List Charter L. Eggert S. Harris June 2022 HTML TEXT PDF XML 7

The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through the general discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist. As this is the most general IETF mailing list, considerable latitude in terms of topics is allowed, but there are posts and topics that are unsuitable for this mailing list. This document defines the charter for the IETF discussion list and explains its scope.

This document obsoletes RFC 3005 and updates RFC 3683.

 draft-eggert-bcp45bis-08 RFC3005 RFC3683 BCP0045 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC9245 RFC9246 URI Signing for Content Delivery Network Interconnection (CDNI) R. van Brandenburg K. Leung P. Sorber June 2022 HTML TEXT PDF XML 37

This document describes how the concept of URI Signing supports the content access control requirements of Content Delivery Network Interconnection (CDNI) and proposes a URI Signing method as a JSON Web Token (JWT) profile.

The proposed URI Signing method specifies the information needed to be included in the URI to transmit the signed JWT, as well as the claims needed by the signed JWT to authorize a User Agent (UA). The mechanism described can be used both in CDNI and single Content Delivery Network (CDN) scenarios.

 draft-ietf-cdni-uri-signing-26 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni 10.17487/RFC9246 RFC9247 BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD) Z. Li S. Zhuang K. Talaulikar Editor S. Aldrin J. Tantsura G. Mirsky June 2022 HTML TEXT PDF XML 6 BGP-LS BFD IS-IS OSPF OSPFv3

Seamless Bidirectional Forwarding Detection (S-BFD) defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. The link-state routing protocols (IS-IS and OSPF) have been extended to advertise the S-BFD Discriminators.

This document defines extensions to the BGP - Link State (BGP-LS) address family to carry the S-BFD Discriminators' information via BGP.

 draft-ietf-idr-bgp-ls-sbfd-extensions-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC9247 RFC9248 Interoperability Profile for Relay User Equipment B. Rosen June 2022 HTML TEXT PDF XML 36 rue relay user equipment

Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a sign language speaker who is deaf, deafblind, or hard of hearing (HoH) or has a speech disability using an interpreter (i.e., a Communications Assistant (CA)) connected via a videophone to the sign language speaker and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be employed by a company or agency, termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service and subsequently to CAs and other sign language speakers. It is desirable that the videophones used by the sign language speaker conform to a standard so that any device may be used with any provider and that direct video calls between sign language speakers work. This document describes the interface between a videophone and a provider.

 draft-ietf-rum-rue-11 PROPOSED STANDARD PROPOSED STANDARD IETF art rum 10.17487/RFC9248 RFC9249 A YANG Data Model for NTP N. Wu D. Dhody Editor A. Sinha Editor A. Kumar S N Y. Zhao July 2022 HTML TEXT PDF XML 56 NTP YANG NTPv4 NTPv3

This document defines a YANG data model that can be used to configure and manage Network Time Protocol (NTP) version 4. It can also be used to configure and manage version 3. The data model includes configuration data and state data.

 draft-ietf-ntp-yang-data-model-17 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp 10.17487/RFC9249 RFC9250 DNS over Dedicated QUIC Connections C. Huitema S. Dickinson A. Mankin May 2022 HTML TEXT PDF XML 27 DNS QUIC DNS over QUIC Encrypted DNS DoQ

This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios.

 draft-ietf-dprive-dnsoquic-12 PROPOSED STANDARD PROPOSED STANDARD IETF int dprive 10.17487/RFC9250 RFC9251 Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN) A. Sajassi S. Thoria M. Mishra K. Patel J. Drake W. Lin June 2022 HTML TEXT PDF XML 30

This document describes how to support endpoints running the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) efficiently for the multicast services over an Ethernet VPN (EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPN Provider Edges (PEs).

 draft-ietf-bess-evpn-igmp-mld-proxy-21 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC9251 RFC9252 BGP Overlay Services Based on Segment Routing over IPv6 (SRv6) G. Dawra Editor K. Talaulikar Editor R. Raszuk B. Decraene S. Zhuang J. Rabadan July 2022 HTML TEXT PDF XML 29 BGP SRv6

This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432).

 draft-ietf-bess-srv6-services-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess http://www.rfc-editor.org/errata_search.php?rfc=9252 10.17487/RFC9252 RFC9253 Support for iCalendar Relationships M. Douglass August 2022 HTML TEXT PDF XML 19 iCalendar link related-to relationships

This specification updates the iCalendar RELATED-TO property defined in RFC 5545 by adding new relation types and introduces new iCalendar properties (LINK, CONCEPT, and REFID) to allow better linking and grouping of iCalendar components and related data.

 draft-ietf-calext-ical-relations-11 RFC5545 PROPOSED STANDARD PROPOSED STANDARD IETF art calext 10.17487/RFC9253 RFC9254 Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR) M. Veillette Editor I. Petrov Editor A. Pelov C. Bormann M. Richardson July 2022 HTML TEXT PDF XML 45 CBOR

YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications.

This document defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949).

 draft-ietf-core-yang-cbor-20 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC9254 RFC9255 The 'I' in RPKI Does Not Stand for Identity R. Bush R. Housley June 2022 HTML TEXT PDF XML 7 Resource Public Key Infrastructure

There is a false notion that Internet Number Resources (INRs) in the RPKI can be associated with the real-world identity of the 'holder' of an INR. This document specifies that RPKI does not associate to the INR holder.

 draft-ietf-sidrops-rpki-has-no-identity-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC9255 RFC9256 Segment Routing Policy Architecture C. Filsfils K. Talaulikar Editor D. Voyer A. Bogdanov P. Mattes July 2022 HTML TEXT PDF XML 35 Segment Routing SR Policy SR-MPLS SRv6 Traffic Engineering

Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.

This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.

 draft-ietf-spring-segment-routing-policy-22 RFC8402 PROPOSED STANDARD PROPOSED STANDARD IETF rtg spring 10.17487/RFC9256 RFC9257 Guidance for External Pre-Shared Key (PSK) Usage in TLS R. Housley J. Hoyland M. Sethi C. A. Wood July 2022 HTML TEXT PDF XML 13

This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. It lists TLS security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. This document also discusses PSK use cases and provisioning processes. Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used.

 draft-ietf-tls-external-psk-guidance-06 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC9257 RFC9258 Importing External Pre-Shared Keys (PSKs) for TLS 1.3 D. Benjamin C. A. Wood July 2022 HTML TEXT PDF XML 11

This document describes an interface for importing external Pre-Shared Keys (PSKs) into TLS 1.3.

 draft-ietf-tls-external-psk-importer-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC9258 RFC9259 Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6) Z. Ali C. Filsfils S. Matsushima D. Voyer M. Chen June 2022 HTML TEXT PDF XML 19 SRv6 Segment Routing OAM

This document describes how the existing IPv6 mechanisms for ping and traceroute can be used in a Segment Routing over IPv6 (SRv6) network. The document also specifies the OAM flag (O-flag) in the Segment Routing Header (SRH) for performing controllable and predictable flow sampling from segment endpoints. In addition, the document describes how a centralized monitoring system performs a path continuity check between any nodes within an SRv6 domain.

 draft-ietf-6man-spring-srv6-oam-13 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC9259 RFC9260 Stream Control Transmission Protocol R. Stewart M. Tüxen K. Nielsen June 2022 HTML TEXT PDF XML 133 SCTP IP internet transport packet network

This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document.

SCTP was originally designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC.

SCTP is a reliable transport protocol operating on top of a connectionless packet network, such as IP. It offers the following services to its users:

The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.

 draft-ietf-tsvwg-rfc4960-bis-19 RFC4460 RFC4960 RFC6096 RFC7053 RFC8540 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=9260 10.17487/RFC9260 RFC9261 Exported Authenticators in TLS N. Sullivan July 2022 HTML TEXT PDF XML 14

This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer.

 draft-ietf-tls-exported-authenticator-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC9261 RFC9262 Tree Engineering for Bit Index Explicit Replication (BIER-TE) T. Eckert Editor M. Menth G. Cauchie October 2022 HTML TEXT PDF XML 43 BIER BIER-TE controller ECMP forwarding traffic-engineering multicast pseudocode routing traffic-steering tree-steering

This memo describes per-packet stateless strict and loose path steered replication and forwarding for "Bit Index Explicit Replication" (BIER) packets (RFC 8279); it is called "Tree Engineering for Bit Index Explicit Replication" (BIER-TE) and is intended to be used as the path steering mechanism for Traffic Engineering with BIER.

BIER-TE introduces a new semantic for "bit positions" (BPs). These BPs indicate adjacencies of the network topology, as opposed to (non-TE) BIER in which BPs indicate "Bit-Forwarding Egress Routers" (BFERs). A BIER-TE "packets BitString" therefore indicates the edges of the (loop-free) tree across which the packets are forwarded by BIER-TE. BIER-TE can leverage BIER forwarding engines with little changes. Co-existence of BIER and BIER-TE forwarding in the same domain is possible -- for example, by using separate BIER "subdomains" (SDs). Except for the optional routed adjacencies, BIER-TE does not require a BIER routing underlay and can therefore operate without depending on a routing protocol such as the "Interior Gateway Protocol" (IGP).

 draft-ietf-bier-te-arch-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bier 10.17487/RFC9262 RFC9263 Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers Y. Wei Editor U. Elzur S. Majee C. Pignataro D. Eastlake 3rd August 2022 HTML TEXT PDF XML 15 SFC metadata

Service Function Chaining (SFC) uses the Network Service Header (NSH) (RFC 8300) to steer and provide context metadata (MD) with each packet. Such metadata can be of various types, including MD Type 2, consisting of Variable-Length Context Headers. This document specifies several such Context Headers that can be used within a Service Function Path (SFP).

 draft-ietf-sfc-nsh-tlv-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sfc 10.17487/RFC9263 RFC9264 Linkset: Media Types and a Link Relation Type for Link Sets E. Wilde H. Van de Sompel July 2022 HTML TEXT PDF XML 31 Web linking Typed links JSON HTTP

This specification defines two formats and associated media types for representing sets of links as standalone documents. One format is based on JSON, and the other is aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support the discovery of sets of links.

 draft-ietf-httpapi-linkset-10 PROPOSED STANDARD PROPOSED STANDARD IETF art httpapi 10.17487/RFC9264 RFC9265 Forward Erasure Correction (FEC) Coding and Congestion Control in Transport N. Kuhn E. Lochin F. Michel M. Welzl July 2022 HTML TEXT PDF XML 21 coding congestion

Forward Erasure Correction (FEC) is a reliability mechanism that is distinct and separate from the retransmission logic in reliable transfer protocols such as TCP. FEC coding can help deal with losses at the end of transfers or with networks having non-congestion losses. However, FEC coding mechanisms should not hide congestion signals. This memo offers a discussion of how FEC coding and congestion control can coexist. Another objective is to encourage the research community to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems.

This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG). The scope of the document is end-to-end communications; FEC coding for tunnels is out of the scope of the document.

 draft-irtf-nwcrg-coding-and-congestion-12 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC9265 RFC9266 Channel Bindings for TLS 1.3 S. Whited July 2022 HTML TEXT PDF XML 7

This document defines a channel binding type, tls-exporter, that is compatible with TLS 1.3 in accordance with RFC 5056, "On the Use of Channel Bindings to Secure Channels". Furthermore, it updates the default channel binding to the new binding for versions of TLS greater than 1.2. This document updates RFCs 5801, 5802, 5929, and 7677.

 draft-ietf-kitten-tls-channel-bindings-for-tls13-16 RFC5801 RFC5802 RFC5929 RFC7677 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC9266 RFC9267 Common Implementation Anti-Patterns Related to Domain Name System (DNS) Resource Record (RR) Processing S. Dashevskyi D. dos Santos J. Wetzels A. Amri July 2022 HTML TEXT PDF XML 16 vulnerabilities vulnerability

This memo describes common vulnerabilities related to Domain Name System (DNS) resource record (RR) processing as seen in several DNS client implementations. These vulnerabilities may lead to successful Denial-of-Service and Remote Code Execution attacks against the affected software. Where applicable, violations of RFC 1035 are mentioned.

 draft-dashevskyi-dnsrr-antipatterns-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9267 RFC9268 IPv6 Minimum Path MTU Hop-by-Hop Option R. Hinden G. Fairhurst August 2022 HTML TEXT PDF XML 20 DPLPMTUD PMTUD

This document specifies a new IPv6 Hop-by-Hop Option that is used to record the Minimum Path MTU (PMTU) along the forward path between a source host to a destination host. The recorded value can then be communicated back to the source using the return Path MTU field in the Option.

 draft-ietf-6man-mtu-option-15 EXPERIMENTAL EXPERIMENTAL IETF int 6man 10.17487/RFC9268 RFC9269 Experimental Scenarios of Information-Centric Networking (ICN) Integration in 4G Mobile Networks P. Suthar M. Stolic A. Jangam Editor D. Trossen R. Ravindran August 2022 HTML TEXT PDF XML 33 LTE ICN ICN-4G ICNoIP IPoICN HybridICN Dual Trannsport

A 4G mobile network uses IP-based transport for the control plane to establish the data session at the user plane for the actual data delivery. In the existing architecture, IP-based unicast is used for the delivery of multimedia content to a mobile terminal, where each user is receiving a separate stream from the server. From a bandwidth and routing perspective, this approach is inefficient. Evolved multimedia broadcast and multicast service (eMBMS) provides capabilities for delivering contents to multiple users simultaneously, but its deployment is very limited or at an experimental stage due to numerous challenges. The focus of this document is to list the options for using Information-Centric Networking (ICN) in 4G mobile networks and elaborate the experimental setups for its further evaluation. The experimental setups discussed provide guidance for using ICN either natively or with an existing mobility protocol stack. With further investigations based on the listed experiments, ICN with its inherent capabilities such as network-layer multicast, anchorless mobility, security, and optimized data delivery using local caching at the edge may provide a viable alternative to IP transport in 4G mobile networks.

 draft-irtf-icnrg-icn-lte-4g-12 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC9269 RFC9270 GMPLS Signaling Extensions for Shared Mesh Protection J. He I. Busi J. Ryoo B. Yoon P. Park August 2022 HTML TEXT PDF XML 13 GMPLS Shared mesh protection

ITU-T Recommendation G.808.3 defines the generic aspects of a Shared Mesh Protection (SMP) mechanism, where the difference between SMP and Shared Mesh Restoration (SMR) is also identified. ITU-T Recommendation G.873.3 defines the protection switching operation and associated protocol for SMP at the Optical Data Unit (ODU) layer. RFC 7412 provides requirements for any mechanism that would be used to implement SMP in a Multi-Protocol Label Switching - Transport Profile (MPLS-TP) network.

This document updates RFCs 4872 and 4873 to provide extensions for Generalized Multi-Protocol Label Switching (GMPLS) signaling to support the control of the SMP mechanism.

 draft-ietf-teas-gmpls-signaling-smp-12 RFC4872 RFC4873 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC9270 RFC9271 Uninterruptible Power Supply (UPS) Management Protocol -- Commands and Responses R. Price Editor August 2022 HTML TEXT PDF XML 52 Uninterruptible Power Supply UPS NUT

This document describes the command/response protocol currently used in the management of Uninterruptible Power Supply (UPS) units and other power devices often deployed in small offices and in IT installations subject to an erratic public power supply. The UPS units typically interface to an Attachment Daemon in the system they protect. This daemon is in turn polled by a Management Daemon that notifies users and system administrators of power supply incidents and automates system shutdown decisions. The commands and responses described by this document are exchanged between the UPS Attachment Daemon and the Management Daemon. The practice current when this protocol was first developed risks weak security, and this is addressed in the Security Considerations sections of this document.

 draft-rprice-ups-management-protocol-15 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9271 RFC9272 Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER) Z. Zhang T. Przygienda A. Dolganow H. Bidgoli IJ. Wijnands A. Gulko September 2022 HTML TEXT PDF XML 6

This document specifies general rules for the interaction between the BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay path calculation within the Bit Index Explicit Replication (BIER) architecture. The semantics defined in this document update RFC 8401 and RFC 8444. This document also updates the "BIER Algorithm" registry established in RFC 8401.

 draft-ietf-bier-bar-ipa-13 RFC8401 RFC8444 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bier 10.17487/RFC9272 RFC9273 Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges K. Matsuzono H. Asaeda C. Westphal August 2022 HTML TEXT PDF XML 20 ICN CCNx NDN network coding in-network cache

This document describes the current research outcomes in Network Coding (NC) for Content-Centric Networking (CCNx) / Named Data Networking (NDN) and clarifies the technical considerations and potential challenges for applying NC in CCNx/NDN. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG) and the Information-Centric Networking Research Group (ICNRG).

 draft-irtf-nwcrg-nwc-ccn-reqs-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC9273 RFC9274 A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol M. Boucadair Q. Wu July 2022 HTML TEXT PDF XML 7 Optimization service performance cost metric routing computation networks service-network interaction network programming

This document creates a new IANA registry for tracking cost modes supported by the Application-Layer Traffic Optimization (ALTO) Protocol. Also, this document relaxes a constraint that was imposed by the ALTO specification on allowed cost mode values.

This document updates RFC 7285.

 draft-ietf-alto-cost-mode-05 RFC7285 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC9274 RFC9275 An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector K. Gao Y. Lee S. Randriamasy Y. Yang J. Zhang September 2022 HTML TEXT PDF XML 54 network visibility abstract network element shared bottleneck

This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO cost map and ALTO property map services so that an application can decide to which endpoint(s) to connect based not only on numerical/ordinal cost values but also on fine-grained abstract information regarding the paths. This is useful for applications whose performance is impacted by specific components of a network on the end-to-end paths, e.g., they may infer that several paths share common links and prevent traffic bottlenecks by avoiding such paths. This extension introduces a new abstraction called the "Abstract Network Element" (ANE) to represent these components and encodes a network path as a vector of ANEs. Thus, it provides a more complete but still abstract graph representation of the underlying network(s) for informed traffic optimization among endpoints.

 draft-ietf-alto-path-vector-25 EXPERIMENTAL EXPERIMENTAL IETF tsv alto 10.17487/RFC9275 RFC9276 Guidance for NSEC3 Parameter Settings W. Hardaker V. Dukhovni August 2022 HTML TEXT PDF XML 10 DNSSEC DNS NSEC3 NSEC Denial of Existence

NSEC3 is a DNSSEC mechanism providing proof of nonexistence by asserting that there are no names that exist between two domain names within a zone. Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding domain name pairs. This document provides guidance on setting NSEC3 parameters based on recent operational deployment experience. This document updates RFC 5155 with guidance about selecting NSEC3 iteration and salt parameters.

 draft-ietf-dnsop-nsec3-guidance-10 RFC5155 BCP0236 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=9276 10.17487/RFC9276 RFC9277 On Stable Storage for Items in Concise Binary Object Representation (CBOR) M. Richardson C. Bormann August 2022 HTML TEXT PDF XML 18

This document defines a stored ("file") format for Concise Binary Object Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command.

 draft-ietf-cbor-file-magic-12 PROPOSED STANDARD PROPOSED STANDARD IETF art cbor http://www.rfc-editor.org/errata_search.php?rfc=9277 10.17487/RFC9277 RFC9278 JWK Thumbprint URI M. Jones K. Yasuda August 2022 HTML TEXT PDF XML 6 JSON Web Key JWK Thumbprint URI URN OAuth

This specification registers a kind of URI that represents a JSON Web Key (JWK) Thumbprint value. JWK Thumbprints are defined in RFC 7638. This enables JWK Thumbprints to be used, for instance, as key identifiers in contexts requiring URIs.

 draft-ietf-oauth-jwk-thumbprint-uri-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC9278 RFC9279 Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Message Extension M. Sivakumar S. Venaas Z. Zhang H. Asaeda August 2022 HTML TEXT PDF XML 12 Multicast

This document specifies a generic mechanism to extend IGMPv3 and Multicast Listener Discovery Version 2 (MLDv2) by using a list of TLVs (Type, Length, and Value).

 draft-ietf-pim-igmp-mld-extension-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC9279 RFC9280 RFC Editor Model (Version 3) P. Saint-Andre Editor June 2022 HTML TEXT PDF XML 27 editorial publication series streams

This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this document establishes the Editorial Stream for publication of future policy definition documents produced through the processes defined herein.

This document obsoletes RFC 8728. This document updates RFCs 7841, 8729, and 8730.

 draft-iab-rfcefdp-rfced-model-13 RFC8728 RFC7841 RFC8729 RFC8730 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC9280 RFC9281 Entities Involved in the IETF Standards Process R. Salz June 2022 HTML TEXT PDF XML 12 IESG RFC Editor IRTF IETF LLC ISOC registries IANA

This document describes the individuals and organizations involved in the IETF standards process, as described in BCP 9. It includes brief descriptions of the entities involved and the role they play in the standards process.

The IETF and its structure have undergone many changes since RFC 2028 was published in 1996. This document reflects the changed organizational structure of the IETF and obsoletes RFC 2028.

 draft-rsalz-2028bis-07 RFC2028 BCP0011 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC9281 RFC9282 Responsibility Change for the RFC Series B. Rosen June 2022 HTML TEXT PDF XML 3 Protocols copyrights intellectual property

In RFC 9280, responsibility for the RFC Series moved to the RFC Series Working Group and the RFC Series Approval Board. It is no longer the responsibility of the RFC Editor, and the role of the IAB in the RFC Series is altered. Accordingly, in Section 2.1 of RFC 2026, the sentence "RFC publication is the direct responsibility of the RFC Editor, under the general direction of the IAB" is deleted.

 draft-rosen-rfcefdp-update-2026-02 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC9282 RFC9283 IAB Charter Update for RFC Editor Model B. Carpenter Editor June 2022 HTML TEXT PDF XML 3

This document updates the IAB Charter (RFC 2850) to be consistent with version 3 of the RFC Editor Model (RFC 9280).

 draft-carpenter-rfced-iab-charter-09 RFC2850 BCP0039 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC9283 RFC9284 Multihoming Deployment Considerations for DDoS Open Threat Signaling (DOTS) M. Boucadair T. Reddy.K W. Pan August 2022 HTML TEXT PDF XML 14

This document discusses multihoming considerations for DDoS Open Threat Signaling (DOTS). The goal is to provide some guidance for DOTS clients and client-domain DOTS gateways when multihomed.

 draft-ietf-dots-multihoming-13 INFORMATIONAL INFORMATIONAL IETF sec dots 10.17487/RFC9284 RFC9285 The Base45 Data Encoding P. Fältström F. Ljunggren D.W. van Gulik August 2022 HTML TEXT PDF XML 8 BASE45

This document describes the Base45 encoding scheme, which is built upon the Base64, Base32, and Base16 encoding schemes.

 draft-faltstrom-base45-12 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=9285 10.17487/RFC9285 RFC9286 Manifests for the Resource Public Key Infrastructure (RPKI) R. Austein G. Huston S. Kent M. Lepinski June 2022 HTML TEXT PDF XML 16

This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects. This document obsoletes RFC 6486.

 draft-ietf-sidrops-6486bis-11 RFC6486 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops http://www.rfc-editor.org/errata_search.php?rfc=9286 10.17487/RFC9286 RFC9287 Greasing the QUIC Bit M. Thomson August 2022 HTML TEXT PDF XML 6 Header Path signal

This document describes a method for negotiating the ability to send an arbitrary value for the second-most significant bit in QUIC packets.

 draft-ietf-quic-bit-grease-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv quic 10.17487/RFC9287 RFC9288 Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers F. Gont W. Liu August 2022 HTML TEXT PDF XML 33 Denial of Service Distributed Denial of Service DoS DDoS ACL filtering policy

This document analyzes the security implications of IPv6 Extension Headers and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary.

 draft-ietf-opsec-ipv6-eh-filtering-10 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC9288 RFC9289 Towards Remote Procedure Call Encryption by Default T. Myklebust C. Lever Editor September 2022 HTML TEXT PDF XML 21 network file system remote procedure call transport layer security X.509

This document describes a mechanism that, through the use of opportunistic Transport Layer Security (TLS), enables encryption of Remote Procedure Call (RPC) transactions while they are in transit. The proposed mechanism interoperates with Open Network Computing (ONC) RPC implementations that do not support it. This document updates RFC 5531.

 draft-ietf-nfsv4-rpc-tls-11 RFC5531 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC9289 RFC9290 Concise Problem Details for Constrained Application Protocol (CoAP) APIs T. Fossati C. Bormann October 2022 HTML TEXT PDF XML 21 CoAP API Problem Details CBOR Tag Language Tag Bidi

This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807.

 draft-ietf-core-problem-details-08 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC9290 RFC9291 A YANG Network Data Model for Layer 2 VPNs M. Boucadair Editor O. Gonzalez de Dios Editor S. Barguil L. Munoz September 2022 HTML TEXT PDF XML 139 automation network model service provider service provisionning network automation service delivery

This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices.

Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types.

 draft-ietf-opsawg-l2nm-19 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=9291 10.17487/RFC9291 RFC9292 Binary Representation of HTTP Messages M. Thomson C. A. Wood August 2022 HTML TEXT PDF XML 16

This document defines a binary format for representing HTTP messages.

 draft-ietf-httpbis-binary-message-06 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC9292 RFC9293 Transmission Control Protocol (TCP) W. Eddy Editor August 2022 HTML TEXT PDF XML 98

This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.

 draft-ietf-tcpm-rfc793bis-28 RFC0793 RFC0879 RFC2873 RFC6093 RFC6429 RFC6528 RFC6691 RFC1011 RFC1122 RFC5961 STD0007 INTERNET STANDARD INTERNET STANDARD IETF tsv tcpm 10.17487/RFC9293 RFC9294 Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS) K. Talaulikar Editor P. Psenak J. Tantsura August 2022 HTML TEXT PDF XML 12 BGP-LS Segment Routing IS-IS OSPF OSPFv3

Extensions have been defined for link-state routing protocols that enable distribution of application-specific link attributes for existing as well as newer applications such as Segment Routing (SR). This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) to enable the advertisement of these application-specific attributes as a part of the topology information from the network.

 draft-ietf-idr-bgp-ls-app-specific-attr-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC9294 RFC9295 Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers S. Turner S. Josefsson D. McCarney T. Ito September 2022 HTML TEXT PDF XML 5 PKIX X.509 keyUsage Elliptic Curve Cryptography

This document updates RFC 8410 to clarify existing semantics, and specify missing semantics, for key usage bits when used in certificates that support the Ed25519, Ed448, X25519, and X448 Elliptic Curve Cryptography algorithms.

 draft-ietf-lamps-8410-ku-clarifications-02 RFC8410 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC9295 RFC9296 ifStackTable for the Point-to-Point (P2P) Interface over a LAN Type: Definition and Examples D. Liu J. Halpern C. Zhang August 2022 HTML TEXT PDF XML 9 ifType ifStack point-to-point

RFC 5309 defines the Point-to-Point (P2P) circuit type, one of the two circuit types used in the link-state routing protocols, and highlights that it is important to identify the correct circuit type when forming adjacencies, flooding link-state database packets, and monitoring the link state.

This document provides advice about the ifStack for the P2P interface over a LAN Type to facilitate operational control, maintenance, and statistics.

 draft-liu-lsr-p2poverlan-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9296 RFC9297 HTTP Datagrams and the Capsule Protocol D. Schinazi L. Pardue August 2022 HTML TEXT PDF XML 14 quic http datagram fast tunnels turtles all the way down masque http-ng

This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection.

In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections.

HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications.

 draft-ietf-masque-h3-datagram-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv masque 10.17487/RFC9297 RFC9298 Proxying UDP in HTTP D. Schinazi August 2022 HTML TEXT PDF XML 16 quic http datagram udp proxy tunnels quic in quic turtles all the way down masque http-ng

This document describes how to proxy UDP in HTTP, similar to how the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy.

 draft-ietf-masque-connect-udp-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv masque 10.17487/RFC9298 RFC9299 An Architectural Introduction to the Locator/ID Separation Protocol (LISP) A. Cabellos D. Saucez Editor October 2022 HTML TEXT PDF XML 24 LISP Architecture

This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes; more details can be found in the protocol specifications, RFCs 9300 and 9301.

 draft-ietf-lisp-introduction-15 INFORMATIONAL INFORMATIONAL IETF rtg lisp 10.17487/RFC9299 RFC9300 The Locator/ID Separation Protocol (LISP) D. Farinacci V. Fuller D. Meyer D. Lewis A. Cabellos Editor October 2022 HTML TEXT PDF XML 33 LISP data plane

This document describes the data plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifiers (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.

LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among other features.

This document obsoletes RFC 6830.

 draft-ietf-lisp-rfc6830bis-38 RFC6830 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lisp 10.17487/RFC9300 RFC9301 Locator/ID Separation Protocol (LISP) Control Plane D. Farinacci F. Maino V. Fuller A. Cabellos Editor October 2022 HTML TEXT PDF XML 42

This document describes the control plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provide a simplified "front end" for one or more Endpoint IDs (EIDs) to Routing Locator mapping databases.

By using this control plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems; this behavior facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP control plane infrastructure, connecting EID addressable nodes of a LISP site, the implementation and operational complexity of the overall cost and effort of deploying LISP is reduced.

This document obsoletes RFCs 6830 and 6833.

 draft-ietf-lisp-rfc6833bis-31 RFC6830 RFC6833 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lisp 10.17487/RFC9301 RFC9302 Locator/ID Separation Protocol (LISP) Map-Versioning L. Iannone D. Saucez O. Bonaventure October 2022 HTML TEXT PDF XML 15

This document describes the Locator/ID Separation Protocol (LISP) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. This approach is based on associating a version number to EID-to-RLOC mappings and transporting such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism.

This document obsoletes RFC 6834, which is the initial experimental specifications of the mechanisms updated by this document.

 draft-ietf-lisp-6834bis-14 RFC6834 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lisp 10.17487/RFC9302 RFC9303 Locator/ID Separation Protocol Security (LISP-SEC) F. Maino V. Ermagan A. Cabellos D. Saucez October 2022 HTML TEXT PDF XML 23 LISP deployment

This memo specifies Locator/ID Separation Protocol Security (LISP-SEC), a set of security mechanisms that provides origin authentication, integrity, and anti-replay protection to the LISP's Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization on EID-Prefix claims in Map-Reply messages.

 draft-ietf-lisp-sec-29 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lisp 10.17487/RFC9303 RFC9304 Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations M. Boucadair C. Jacquenet October 2022 HTML TEXT PDF XML 5 Shared Experiment Code LISP codepoints Experiment Identifier Experiment ID LISP Experimental Registry LISP Extension Extending LISP Exhauted LISP types LISP IANA IANA

This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP Packet Type codepoint for each extension.

This document obsoletes RFC 8113.

 draft-ietf-lisp-rfc8113bis-03 RFC8113 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lisp 10.17487/RFC9304 RFC9305 Locator/ID Separation Protocol (LISP) Generic Protocol Extension F. Maino Editor J. Lemon P. Agarwal D. Lewis M. Smith October 2022 HTML TEXT PDF XML 14 security policy

This document describes extensions to the Locator/ID Separation Protocol (LISP) data plane, via changes to the LISP header, to support multiprotocol encapsulation and allow the introduction of new protocol capabilities.

 draft-ietf-lisp-gpe-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lisp 10.17487/RFC9305 RFC9306 Vendor-Specific LISP Canonical Address Format (LCAF) A. Rodriguez-Natal V. Ermagan A. Smirnov V. Ashtaputre D. Farinacci October 2022 HTML TEXT PDF XML 5 lisp lcaf internal domain organization private

This document describes a new Locator/ID Separation Protocol (LISP) Canonical Address Format (LCAF), the Vendor-Specific LCAF. This LCAF enables organizations to have implementation-specific encodings for LCAF addresses. This document updates RFC 8060.

 draft-ietf-lisp-vendor-lcaf-12 RFC8060 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC9306 RFC9307 Report from the IAB Workshop on Analyzing IETF Data (AID) 2021 N. ten Oever C. Cath M. Kühlewind C. S. Perkins September 2022 HTML TEXT PDF XML 15 data science data analysis

The "Show me the numbers: Workshop on Analyzing IETF Data (AID)" workshop was convened by the Internet Architecture Board (IAB) from November 29 to December 2, 2021 and hosted by the IN-SIGHT.it project at the University of Amsterdam; however, it was converted to an online-only event. The workshop was organized into two discussion parts with a hackathon activity in between. This report summarizes the workshop's discussion and identifies topics that warrant future work and consideration.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 draft-iab-aid-workshop-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC9307 RFC9308 Applicability of the QUIC Transport Protocol M. Kühlewind B. Trammell September 2022 HTML TEXT PDF XML 22 application protocol mapping deployment

This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. Its intended audience is designers of application protocol mappings to QUIC and implementors of these application protocols.

 draft-ietf-quic-applicability-18 INFORMATIONAL INFORMATIONAL IETF tsv quic 10.17487/RFC9308 RFC9309 Robots Exclusion Protocol M. Koster G. Illyes H. Zeller L. Sassman September 2022 HTML TEXT PDF XML 12 robot crawler robots.txt

This document specifies and extends the "Robots Exclusion Protocol" method originally defined by Martijn Koster in 1994 for service owners to control how content served by their services may be accessed, if at all, by automatic clients known as crawlers. Specifically, it adds definition language for the protocol, instructions for handling errors, and instructions for caching.

 draft-koster-rep-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=9309 10.17487/RFC9309 RFC9310 X.509 Certificate Extension for 5G Network Function Types R. Housley S. Turner J. Preuß Mattsson D. Migault January 2023 HTML TEXT PDF XML 11 Digital Certificate

This document specifies the certificate extension for including Network Function Types (NFTypes) for the 5G System in X.509 v3 public key certificates as profiled in RFC 5280.

 draft-ietf-lamps-5g-nftypes-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC9310 RFC9311 Running an IETF Hackathon C. Eckel September 2022 HTML TEXT PDF XML 23

IETF Hackathons encourage the IETF community to collaborate on running code related to existing and evolving Internet standards. This document provides a set of practices that have been used for running IETF Hackathons. These practices apply to Hackathons in which both in-person and remote participation are possible, with adaptations for Hackathons that are online only.

 draft-ietf-shmoo-hackathon-08 INFORMATIONAL INFORMATIONAL IETF gen shmoo 10.17487/RFC9311 RFC9312 Manageability of the QUIC Transport Protocol M. Kühlewind B. Trammell September 2022 HTML TEXT PDF XML 29 network management wire image

This document discusses manageability of the QUIC transport protocol and focuses on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It is intended as a "user's manual" for the wire image to provide guidance for network operators and equipment vendors who rely on the use of transport-aware network functions.

 draft-ietf-quic-manageability-18 INFORMATIONAL INFORMATIONAL IETF tsv quic 10.17487/RFC9312 RFC9313 Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS) G. Lencse J. Palet Martinez L. Howard R. Patterson I. Farrer October 2022 HTML TEXT PDF XML 27 IPv6 Transition Technologies Comparison IPv4aaS IPv6-only 464XLAT DNS64 Dual Stack Lite Lightweight 4over6 MAP-E MAP-T

Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. These technologies have their advantages and disadvantages. Depending on existing topology, skills, strategy, and other preferences, one of these technologies may be the most appropriate solution for a network operator.

This document examines the five most prominent IPv4aaS technologies and considers a number of different aspects to provide network operators with an easy-to-use reference to assist in selecting the technology that best suits their needs.

 draft-ietf-v6ops-transition-comparison-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC9313 RFC9314 YANG Data Model for Bidirectional Forwarding Detection (BFD) M. Jethanandani Editor R. Rahman Editor L. Zheng Editor S. Pallagatti G. Mirsky September 2022 HTML TEXT PDF XML 58 Liveliness check BGP OSPF IS-IS TCP-AO MD5

This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD).

The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) (RFC 8342). This document updates "YANG Data Model for Bidirectional Forwarding Detection (BFD)" (RFC 9127).

 draft-ietf-bfd-rfc9127-bis-04 RFC9127 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC9314 RFC9315 Intent-Based Networking - Concepts and Definitions A. Clemm L. Ciavaglia L. Z. Granville J. Tantsura October 2022 HTML TEXT PDF XML 23 Autonomic networking Network management Intent-based management Intent-based management Policy-based management policy policy-based network management abstraction

Intent and Intent-Based Networking are taking the industry by storm. At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions.

This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes.

 draft-irtf-nmrg-ibn-concepts-definitions-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC9315 RFC9316 Intent Classification C. Li O. Havel A. Olariu P. Martinez-Julia J. Nobre D. Lopez October 2022 HTML TEXT PDF XML 35 intent taxonomy intent-based network intent users intent categories intent types network management network automation network intent network service network orchestration intent translation

Intent is an abstract, high-level policy used to operate a network. An intent-based management system includes an interface for users to input requests and an engine to translate the intents into the network configuration and manage their life cycle.

This document mostly discusses the concept of network intents, but other types of intents are also considered. Specifically, this document highlights stakeholder perspectives of intent, methods to classify and encode intent, and the associated intent taxonomy; it also defines relevant intent terms where necessary, provides a foundation for intent-related research, and facilitates solution development.

This document is a product of the IRTF Network Management Research Group (NMRG).

 draft-irtf-nmrg-ibn-intent-classification-08 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=9316 10.17487/RFC9316 RFC9317 Operational Considerations for Streaming Media J. Holland A. Begen S. Dawkins October 2022 HTML TEXT PDF XML 37 DASH HLS ABR adaptive streaming live streaming live latency media transport

This document provides an overview of operational networking and transport protocol issues that pertain to the quality of experience (QoE) when streaming video and other high-bitrate media over the Internet.

This document explains the characteristics of streaming media delivery that have surprised network designers or transport experts who lack specific media expertise, since streaming media highlights key differences between common assumptions in existing networking practices and observations of media delivery issues encountered when streaming media over those existing networks.

 draft-ietf-mops-streaming-opcons-12 INFORMATIONAL INFORMATIONAL IETF ops mops 10.17487/RFC9317 RFC9318 IAB Workshop Report: Measuring Network Quality for End-Users W. Hardaker O. Shapira October 2022 HTML TEXT PDF XML 31 QoE QoS Quality of Service Quality of Experience Measurement End User

The Measuring Network Quality for End-Users workshop was held virtually by the Internet Architecture Board (IAB) on September 14-16, 2021. This report summarizes the workshop, the topics discussed, and some preliminary conclusions drawn at the end of the workshop.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

 draft-iab-mnqeu-report-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC9318 RFC9319 The Use of maxLength in the Resource Public Key Infrastructure (RPKI) Y. Gilad S. Goldberg K. Sriram J. Snijders B. Maddison October 2022 HTML TEXT PDF XML 13 Secure Internet routing Resource public key infrastructure

This document recommends ways to reduce the forged-origin hijack attack surface by prudently limiting the set of IP prefixes that are included in a Route Origin Authorization (ROA). One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases. The recommendations complement and extend those in RFC 7115. This document also discusses the creation of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitigation services. Considerations related to ROAs and RPKI-based Route Origin Validation (RPKI-ROV) in the context of destination-based Remotely Triggered Discard Route (RTDR) (elsewhere referred to as "Remotely Triggered Black Hole") filtering are also highlighted.

 draft-ietf-sidrops-rpkimaxlen-15 BCP0185 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops sidrops 10.17487/RFC9319 RFC9320 Deterministic Networking (DetNet) Bounded Latency N. Finn J.-Y. Le Boudec E. Mohammadpour J. Zhang B. Varga November 2022 HTML TEXT PDF XML 26 DetNet bounded latency zero congestion loss

This document presents a timing model for sources, destinations, and Deterministic Networking (DetNet) transit nodes. Using the model, it provides a methodology to compute end-to-end latency and backlog bounds for various queuing methods. The methodology can be used by the management and control planes and by resource reservation algorithms to provide bounded latency and zero congestion loss for the DetNet service.

 draft-ietf-detnet-bounded-latency-10 INFORMATIONAL INFORMATIONAL IETF rtg detnet 10.17487/RFC9320 RFC9321 Signature Validation Token S. Santesson R. Housley October 2022 HTML TEXT PDF XML 34

Electronic signatures have a limited lifespan with respect to the time period that they can be validated and determined to be authentic. The Signature Validation Token (SVT) defined in this specification provides evidence that asserts the validity of an electronic signature. The SVT is provided by a trusted authority, which asserts that a particular signature was successfully validated according to defined procedures at a certain time. Any future validation of that electronic signature can be satisfied by validating the SVT without any need to also validate the original electronic signature or the associated digital certificates. The SVT supports electronic signatures in Cryptographic Message Syntax (CMS), XML, PDF, and JSON documents.

 draft-santesson-svt-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=9321 10.17487/RFC9321 RFC9322 In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags T. Mizrahi F. Brockners S. Bhandari B. Gafni M. Spiegel November 2022 HTML TEXT PDF XML 13 IOAM Telemetry

In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in packets while they traverse a path between two points in the network. This document defines two new flags in the IOAM Trace Option headers, specifically the Loopback and Active flags.

 draft-ietf-ippm-ioam-flags-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC9322 RFC9323 A Profile for RPKI Signed Checklists (RSCs) J. Snijders T. Harrison B. Maddison November 2022 HTML TEXT PDF XML 13 security cryptography X.509

This document defines a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry a general-purpose listing of checksums (a 'checklist'). The objective is to allow for the creation of an attestation, termed an "RPKI Signed Checklist (RSC)", which contains one or more checksums of arbitrary digital objects (files) that are signed with a specific set of Internet Number Resources. When validated, an RSC confirms that the respective Internet resource holder produced the RSC.

 draft-ietf-sidrops-rpki-rsc-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC9323 RFC9324 Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh R. Bush K. Patel P. Smith M. Tinka December 2022 HTML TEXT PDF XML 7 bgp

A BGP speaker performing policy based on the Resource Public Key Infrastructure (RPKI) should not issue route refresh to its neighbors because it has received new RPKI data. This document updates RFC 8481 by describing how to avoid doing so by either keeping a full Adj-RIB-In or saving paths dropped due to ROV (Route Origin Validation) so they may be reevaluated with respect to new RPKI data.

 draft-ietf-sidrops-rov-no-rr-08 RFC8481 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC9324 RFC9325 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Y. Sheffer P. Saint-Andre T. Fossati November 2022 HTML TEXT PDF XML 34

Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.

RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.

 draft-ietf-uta-rfc7525bis-11 RFC7525 RFC5288 RFC6066 BCP0195 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF art uta 10.17487/RFC9325 RFC9326 In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting H. Song B. Gafni F. Brockners S. Bhandari T. Mizrahi November 2022 HTML TEXT PDF XML 13 IOAM Telemetry

In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, IOAM allows telemetry data to be pushed into data packets while they traverse the network. This document introduces a new IOAM option type (denoted IOAM-Option-Type) called the "IOAM Direct Export (DEX) Option-Type". This Option-Type is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. The exporting method and format are outside the scope of this document.

 draft-ietf-ippm-ioam-direct-export-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC9326 RFC9327 Control Messages Protocol for Use with Network Time Protocol Version 4 B. Haberman Editor November 2022 HTML TEXT PDF XML 21 NTP mode 6 mode 7

This document describes the structure of the control messages that were historically used with the Network Time Protocol (NTP) before the advent of more modern control and management approaches. These control messages have been used to monitor and control the NTP application running on any IP network attached computer. The information in this document was originally described in Appendix B of RFC 1305. The goal of this document is to provide an updated description of the control messages described in RFC 1305 in order to conform with the updated NTP specification documented in RFC 5905.

The publication of this document is not meant to encourage the development and deployment of these control messages. This document is only providing a current reference for these control messages given the current status of RFC 1305.

 draft-ietf-ntp-mode-6-cmds-11 HISTORIC HISTORIC IETF int ntp 10.17487/RFC9327 RFC9328 RTP Payload Format for Versatile Video Coding (VVC) S. Zhao S. Wenger Y. Sanchez Y.-K. Wang M. M Hannuksela December 2022 HTML TEXT PDF XML 54 H.266 ISO/IEC 23090-3 MPEG-I Part 3 RTP Payload Video

This memo describes an RTP payload format for the Versatile Video Coding (VVC) specification, which was published as both ITU-T Recommendation H.266 and ISO/IEC International Standard 23090-3. VVC was developed by the Joint Video Experts Team (JVET). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications.

 draft-ietf-avtcore-rtp-vvc-18 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC9328 RFC9329 TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets T. Pauly V. Smyslov November 2022 HTML TEXT PDF XML 30 IKE IKEv2 IPsec TCP

This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association (SA) establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP.

TCP encapsulation for IKE and IPsec was defined in RFC 8229. This document clarifies the specification for TCP encapsulation by including additional clarifications obtained during implementation and deployment of this method. This documents obsoletes RFC 8229.

 draft-ietf-ipsecme-rfc8229bis-09 RFC8229 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC9329 RFC9330 Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture B. Briscoe Editor K. De Schepper M. Bagnulo G. White January 2023 HTML TEXT PDF XML 36 Performance Queuing Delay One Way Delay Round-Trip Time RTT Jitter Congestion Control Congestion Avoidance Quality of Service QoS Quality of Experience QoE Active Queue Management AQM Explicit Congestion Notification ECN Pacing Burstiness

This document describes the L4S architecture, which enables Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control. L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture, all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay and instead adopt a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput.

The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. The aim is for L4S latency and throughput to be usually much better (and rarely worse) while typically not impacting Classic performance.

 draft-ietf-tsvwg-l4s-arch-20 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC9330 RFC9331 The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S) K. De Schepper B. Briscoe Editor January 2023 HTML TEXT PDF XML 52 Burstiness Performance Queuing Delay One Way Delay Round-Trip Time RTT Jitter Congestion Control Congestion Avoidance Quality of Service QoS Quality of Experience QoE Active Queue Management AQM Explicit Congestion Notification ECN Pacing

This specification defines the protocol to be used for a new network service called Low Latency, Low Loss, and Scalable throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or 'Classic') ECN approach, except as specified within. L4S uses 'Scalable' congestion control, which induces much more frequent control signals from the network, and it responds to them with much more fine-grained adjustments so that very low (typically sub-millisecond on average) and consistently low queuing delay becomes possible for L4S traffic without compromising link utilization. Thus, even capacity-seeking (TCP-like) traffic can have high bandwidth and very low delay at the same time, even during periods of high traffic load.

The L4S identifier defined in this document distinguishes L4S from 'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can be incrementally modified to distinguish and isolate existing traffic that still follows the Classic behaviour, to prevent it from degrading the low queuing delay and low loss of L4S traffic. This Experimental specification defines the rules that L4S transports and network elements need to follow, with the intention that L4S flows neither harm each other's performance nor that of Classic traffic. It also suggests open questions to be investigated during experimentation. Examples of new Active Queue Management (AQM) marking algorithms and new transports (whether TCP-like or real time) are specified separately.

 draft-ietf-tsvwg-ecn-l4s-id-29 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC9331 RFC9332 Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S) K. De Schepper B. Briscoe Editor G. White January 2023 HTML TEXT PDF XML 52 Performance Queuing Delay One Way Delay Round-Trip Time RTT Jitter Congestion Control Congestion Avoidance Quality of Service QoS Quality of Experience QoE Active Queue Management AQM Explicit Congestion Notification ECN Pacing Burstiness

This specification defines a framework for coupling the Active Queue Management (AQM) algorithms in two queues intended for flows with different responses to congestion. This provides a way for the Internet to transition from the scaling problems of standard TCP-Reno-friendly ('Classic') congestion controls to the family of 'Scalable' congestion controls. These are designed for consistently very low queuing latency, very low congestion loss, and scaling of per-flow throughput by using Explicit Congestion Notification (ECN) in a modified way. Until the Coupled Dual Queue (DualQ), these Scalable L4S congestion controls could only be deployed where a clean-slate environment could be arranged, such as in private data centres.

This specification first explains how a Coupled DualQ works. It then gives the normative requirements that are necessary for it to work well. All this is independent of which two AQMs are used, but pseudocode examples of specific AQMs are given in appendices.

 draft-ietf-tsvwg-aqm-dualq-coupled-25 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC9332 RFC9333 Minimal IP Encapsulating Security Payload (ESP) D. Migault T. Guggemos January 2023 HTML TEXT PDF XML 13

This document describes the minimal properties that an IP Encapsulating Security Payload (ESP) implementation needs to meet to remain interoperable with the standard ESP as defined in RFC 4303. Such a minimal version of ESP is not intended to become a replacement of ESP in RFC 4303. Instead, a minimal implementation is expected to be optimized for constrained environments while remaining interoperable with implementations of ESP. In addition, this document provides some considerations for implementing minimal ESP in a constrained environment, such as limiting the number of flash writes, handling frequent wakeup and sleep states, limiting wakeup time, and reducing the use of random generation.

This document does not update or modify RFC 4303. It provides a compact description of how to implement the minimal version of that protocol. RFC 4303 remains the authoritative description.

 draft-ietf-lwig-minimal-esp-12 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC9333 RFC9334 Remote ATtestation procedureS (RATS) Architecture H. Birkholz D. Thaler M. Richardson N. Smith W. Pan January 2023 HTML TEXT PDF XML 46 evidence attestation results epoch epoch-id endorsement attestating environment reference value target environment layered attestation appraisal policy background check model passport model freshness recentness

In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.

 draft-ietf-rats-architecture-22 INFORMATIONAL INFORMATIONAL IETF sec rats http://www.rfc-editor.org/errata_search.php?rfc=9334 10.17487/RFC9334 RFC9336 X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing T. Ito T. Okubo S. Turner December 2022 HTML TEXT PDF XML 8 X.509 KeyPurposeIds Key Purpose Identifier Document Signing

RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines a general-purpose Document-Signing KeyPurposeId for inclusion in the Extended Key Usage (EKU) extension of X.509 public key certificates. Document-Signing applications may require that the EKU extension be present and that a Document-Signing KeyPurposeId be indicated in order for the certificate to be acceptable to that Document-Signing application.

 draft-ietf-lamps-documentsigning-eku-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC9336 RFC9337 Generating Password-Based Keys Using the GOST Algorithms E. Karelina Editor December 2022 HTML TEXT PDF XML 14 password-based cryptography derived key GOST algorithms pkcs5 gost

This document specifies how to use "PKCS #5: Password-Based Cryptography Specification Version 2.1" (RFC 8018) to generate a symmetric key from a password in conjunction with the Russian national standard GOST algorithms.

PKCS #5 applies a Pseudorandom Function (PRF) -- a cryptographic hash, cipher, or Hash-Based Message Authentication Code (HMAC) -- to the input password along with a salt value and repeats the process many times to produce a derived key.

This specification has been developed outside the IETF. The purpose of publication being to facilitate interoperable implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used here.

 draft-pkcs5-gost-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC9337 RFC9338 CBOR Object Signing and Encryption (COSE): Countersignatures J. Schaad December 2022 HTML TEXT PDF XML 18 digital signature

Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC 9052.

 draft-ietf-cose-countersign-10 RFC9052 STD0096 INTERNET STANDARD INTERNET STANDARD IETF sec cose 10.17487/RFC9338 RFC9339 OSPF Reverse Metric K. Talaulikar Editor P. Psenak H. Johnston December 2022 HTML TEXT PDF XML 11 IGP OSPF

This document specifies the extensions to OSPF that enable a router to use Link-Local Signaling (LLS) to signal the metric that receiving OSPF neighbor(s) should use for a link to the signaling router. When used on the link to the signaling router, the signaling of this reverse metric (RM) allows a router to influence the amount of traffic flowing towards itself. In certain use cases, this enables routers to maintain symmetric metrics on both sides of a link between them.

 draft-ietf-lsr-ospf-reverse-metric-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC9339 RFC9341 Alternate-Marking Method G. Fioccola Editor M. Cociglio G. Mirsky T. Mizrahi T. Zhou December 2022 HTML TEXT PDF XML 22

This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321.

 draft-ietf-ippm-rfc8321bis-03 RFC8321 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC9341 RFC9342 Clustered Alternate-Marking Method G. Fioccola Editor M. Cociglio A. Sapio R. Sisto T. Zhou December 2022 HTML TEXT PDF XML 24 Multipoint Cluster Performance Measurement Monitoring Passive Hybrid Loss Delay Delay Variation Hashing Closed-Loop

This document generalizes and expands the Alternate-Marking methodology to measure any kind of unicast flow whose packets can follow several different paths in the network; this can result in a multipoint-to-multipoint network. The network clustering approach is presented and, for this reason, the technique described here is called "Clustered Alternate Marking". This document obsoletes RFC 8889.

 draft-ietf-ippm-rfc8889bis-04 RFC8889 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC9342 RFC9343 IPv6 Application of the Alternate-Marking Method G. Fioccola T. Zhou M. Cociglio F. Qin R. Pang December 2022 HTML TEXT PDF XML 20 Extension Header Option Destination Hop-By-Hop Performance Measurement Monitoring Passive Hybrid Loss Delay Delay Variation Multipoint Cluster Closed-Loop

This document describes how the Alternate-Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines an Extension Header Option to encode Alternate-Marking information in both the Hop-by-Hop Options Header and Destination Options Header.

 draft-ietf-6man-ipv6-alt-mark-17 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC9343 RFC9353 IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED) D. Lopez Q. Wu D. Dhody Q. Ma D. King January 2023 HTML TEXT PDF XML 13 Path Computation Element

When a Path Computation Element (PCE) is a Label Switching Router (LSR) or a server participating in the Interior Gateway Protocol (IGP), its presence and path computation capabilities can be advertised using IGP flooding. The IGP extensions for PCE Discovery (PCED) (RFCs 5088 and 5089) define a method to advertise path computation capabilities using IGP flooding for OSPF and IS-IS, respectively. However, these specifications lack a method to advertise Path Computation Element Communication Protocol (PCEP) security (e.g., Transport Layer Security (TLS) and TCP Authentication Option (TCP-AO)) support capability.

This document defines capability flag bits for the PCE-CAP-FLAGS sub-TLV that can be announced as an attribute in the IGP advertisement to distribute PCEP security support information. In addition, this document updates RFCs 5088 and 5089 to allow advertisement of a Key ID or KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability. This document also updates RFCs 8231 and 8306.

 draft-ietf-lsr-pce-discovery-security-support-13 RFC5088 RFC5089 RFC8231 RFC8306 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC9353 RFC9354 Transmission of IPv6 Packets over Power Line Communication (PLC) Networks J. Hou B. Liu Y-G. Hong X. Tang C. Perkins January 2023 HTML TEXT PDF XML 20 6lo 6lowpan 6lo-plc 6loplc plc

Power Line Communication (PLC), namely using electric power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially smart meters for electricity. The existing electricity infrastructure facilitates the expansion of PLC deployments due to its potential advantages in terms of cost and convenience. Moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications. This document describes how IPv6 packets are transported over constrained PLC networks, such as those described in ITU-T G.9903, IEEE 1901.1, and IEEE 1901.2.

 draft-ietf-6lo-plc-11 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC9354 STD0001 [STD number 1 is retired. It was "Internet Official Protocol Standards". See BCP 9 / RFC 7100 for more information.] STD0002 [Reserved for Assigned Numbers. See RFC 1700 and RFC 3232.] STD0003 Requirements for Internet Hosts RFC1122 RFC1123 STD0004 [Reserved for Router Requirements. See RFC 1812.] STD0005 Internet Protocol RFC0791 RFC0792 RFC0919 RFC0922 RFC0950 RFC1112 STD0006 User Datagram Protocol RFC0768 STD0007 Transmission Control Protocol (TCP) RFC9293 STD0008 Telnet Protocol RFC0854 RFC0855 STD0009 File Transfer Protocol RFC0959 STD0010 Simple Mail Transfer Protocol RFC0821 RFC0974 RFC1869 RFC1870 STD0011 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES RFC0822 STD0012 [Reserved for Network Time Protocol (NTP). See RFC 1305.] STD0013 Domain Name System RFC1034 RFC1035 STD0014 [Was Mail Routing and the Domain System. Now Historic.] STD0015 [Was Simple Network Management Protocol. Now Historic.] STD0016 Structure of Management Information RFC1155 RFC1212 STD0017 Management Information Base for Network Management of TCP/IP-based internets: MIB-II RFC1213 STD0018 [Was Exterior Gateway Protocol (RFC 904). Now Historic.] STD0019 NetBIOS Service Protocols RFC1001 RFC1002 STD0020 Echo Protocol RFC0862 STD0021 Discard Protocol RFC0863 STD0022 Character Generator Protocol RFC0864 STD0023 Quote of the Day Protocol RFC0865 STD0024 Active users RFC0866 STD0025 Daytime Protocol RFC0867 STD0026 Time Protocol RFC0868 STD0027 Telnet Binary Transmission RFC0856 STD0028 Telnet Echo Option RFC0857 STD0029 Telnet Suppress Go Ahead Option RFC0858 STD0030 Telnet Status Option RFC0859 STD0031 Telnet Timing Mark Option RFC0860 STD0032 Telnet Extended Options: List Option RFC0861 STD0033 The TFTP Protocol (Revision 2) RFC1350 STD0034 [Was Routing Information Protocol (RIP). Replaced by STD 56.] STD0035 ISO Transport Service on top of the TCP Version: 3 RFC1006 STD0036 Transmission of IP and ARP over FDDI Networks RFC1390 STD0037 An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware RFC0826 STD0038 A Reverse Address Resolution Protocol RFC0903 STD0039 [Was BBN Report 1822 (IMP/Host Interface). Now Historic.] STD0040 Host Access Protocol specification RFC0907 STD0041 A Standard for the Transmission of IP Datagrams over Ethernet Networks RFC0894 STD0042 Standard for the transmission of IP datagrams over experimental Ethernet networks RFC0895 STD0043 Standard for the transmission of IP datagrams over IEEE 802 networks RFC1042 STD0044 DCN Local-Network Protocols RFC0891 STD0045 Internet Protocol on Network System's HYPERchannel: Protocol Specification RFC1044 STD0046 Transmitting IP traffic over ARCNET networks RFC1201 STD0047 Nonstandard for transmission of IP datagrams over serial lines: SLIP RFC1055 STD0048 Standard for the transmission of IP datagrams over NetBIOS networks RFC1088 STD0049 Standard for the transmission of 802.2 packets over IPX networks RFC1132 STD0050 [Reserved for Definitions of Managed Objects for the Ethernet-like Interface Types. See RFC 3638.] STD0051 The Point-to-Point Protocol (PPP) RFC1661 RFC1662 STD0052 The Transmission of IP Datagrams over the SMDS Service RFC1209 STD0053 Post Office Protocol - Version 3 RFC1939 STD0054 OSPF Version 2 RFC2328 STD0055 Multiprotocol Interconnect over Frame Relay RFC2427 STD0056 RIP Version 2 RFC2453 STD0057 RIP Version 2 Protocol Applicability Statement RFC1722 STD0058 Structure of Management Information Version 2 (SMIv2) RFC2578 RFC2579 RFC2580 STD0059 Remote Network Monitoring Management Information Base RFC2819 STD0060 SMTP Service Extension for Command Pipelining RFC2920 STD0061 A One-Time Password System RFC2289 STD0062 Simple Network Management Protocol Version 3 (SNMPv3) RFC3411 RFC3412 RFC3413 RFC3414 RFC3415 RFC3416 RFC3417 RFC3418 STD0063 UTF-8, a transformation format of ISO 10646 RFC3629 STD0064 RTP: A Transport Protocol for Real-Time Applications RFC3550 STD0065 RTP Profile for Audio and Video Conferences with Minimal Control RFC3551 STD0066 Uniform Resource Identifier (URI): Generic Syntax RFC3986 STD0067 XDR: External Data Representation Standard RFC4506 STD0068 Augmented BNF for Syntax Specifications: ABNF RFC5234 STD0069 The Extensible Provisioning Protocol (EPP) RFC5730 RFC5731 RFC5732 RFC5733 RFC5734 STD0070 Cryptographic Message Syntax (CMS) RFC5652 STD0071 SMTP Service Extension for 8-bit MIME Transport RFC6152 STD0072 Message Submission for Mail RFC6409 STD0073 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages RFC6522 STD0074 Automated Updates of DNS Security (DNSSEC) Trust Anchors RFC5011 STD0075 Extension Mechanisms for DNS (EDNS(0)) RFC6891 STD0076 DomainKeys Identified Mail (DKIM) Signatures RFC6376 STD0077 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information RFC7011 STD0078 Simple Network Management Protocol (SNMP) Security RFC5343 RFC5590 RFC5591 RFC6353 STD0079 Internet Key Exchange Protocol Version 2 (IKEv2) RFC7296 STD0080 ASCII format for network interchange RFC0020 STD0081 A One-Way Delay Metric for IP Performance Metrics (IPPM) RFC7679 STD0082 A One-Way Loss Metric for IP Performance Metrics (IPPM) RFC7680 STD0083 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) RFC7761 STD0084 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) RFC8077 STD0085 Message Disposition Notification RFC8098 STD0086 Internet Protocol, Version 6 (IPv6) Specification RFC8200 STD0087 Path MTU Discovery for IP version 6 RFC8201 STD0088 DNS Extensions to Support IP Version 6 RFC3596 STD0089 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification RFC4443 STD0090 The JavaScript Object Notation (JSON) Data Interchange Format RFC8259 STD0091 Network Configuration Access Control Model RFC8341 STD0092 Internet Printing Protocol/1.1 RFC8010 RFC8011 STD0093 Secret Key Transaction Authentication for DNS (TSIG) RFC8945 STD0094 Concise Binary Object Representation (CBOR) RFC8949 STD0095 RDAP RFC7480 RFC7481 RFC9082 RFC9083 RFC9224 STD0096 CBOR Object Signing and Encryption (COSE): Structures and Process RFC9052 RFC9338 STD0097 HTTP Semantics RFC9110 STD0098 HTTP Caching RFC9111 STD0099 HTTP/1.1 RFC9112 ./update-package.include0000644000764400076440000000636514363246644015111 0ustar iustiniustindraft-ietf-avtext-lrr-07.txt draft-ietf-trill-ecn-support-07.txt draft-ietf-mpls-rfc6374-sfl-10.txt draft-ietf-payload-vp9-16.txt draft-ietf-oauth-jwt-introspection-response-12.txt draft-ietf-babel-yang-model-13.txt draft-ietf-lsr-isis-srv6-extensions-19.txt draft-ietf-bess-evpn-bum-procedure-updates-14.txt draft-ietf-bess-evpn-optimized-ir-12.txt draft-ietf-netconf-sztp-csr-14.txt draft-ietf-ecrit-similar-location-19.txt draft-ietf-alto-performance-metrics-28.txt draft-ietf-pce-binding-label-sid-15.txt draft-ietf-ace-mqtt-tls-profile-17.txt draft-ietf-i2nsf-nsf-facing-interface-dm-29.txt draft-ietf-i2nsf-capability-data-model-32.txt draft-ietf-i2nsf-nsf-monitoring-data-model-20.txt draft-ietf-rats-yang-tpm-charra-21.txt draft-ietf-dnsop-svcb-https-11.txt draft-ietf-lamps-cmp-algorithms-15.txt draft-ietf-sidrops-8210bis-10.txt draft-ietf-lamps-cmp-updates-23.txt draft-ietf-sacm-coswid-22.txt draft-ietf-add-ddr-10.txt draft-ietf-add-dnr-13.txt draft-ietf-add-svcb-dns-07.txt draft-ietf-idr-bgp-ls-flex-algo-12.txt draft-ietf-tcpm-yang-tcp-09.txt draft-ietf-ipsecme-iptfs-19.txt draft-ietf-ipsecme-yang-iptfs-11.txt draft-ietf-avtcore-cryptex-08.txt draft-ietf-lsr-isis-rfc5316bis-07.txt draft-ietf-tls-subcerts-15.txt draft-ietf-lsr-ospf-bfd-strict-mode-10.txt draft-ietf-lsr-flex-algo-26.txt draft-ietf-lsr-ospf-l2bundles-10.txt draft-ietf-lpwan-schc-yang-data-model-21.txt draft-ietf-dots-robust-blocks-06.txt draft-ietf-cose-x509-09.txt draft-ietf-ipsecme-mib-iptfs-11.txt draft-ietf-pce-vn-association-11.txt draft-ietf-pce-lsp-extended-flags-09.txt draft-ietf-sipcore-multiple-reasons-01.txt draft-ietf-dime-group-signaling-14.txt draft-ietf-quic-v2-10.txt draft-ietf-quic-version-negotiation-14.txt draft-ietf-opsawg-yang-vpn-service-pm-15.txt draft-ietf-ippm-ioam-conf-state-10.txt draft-ietf-drip-rid-37.txt draft-ietf-ipsecme-ikev2-multiple-ke-12.txt draft-ietf-lamps-rfc3709bis-10.txt draft-ietf-lpwan-schc-over-nbiot-15.txt draft-ietf-oauth-rar-22.txt draft-ietf-ipsecme-ikev1-algo-to-historic-09.txt draft-ietf-extra-imap-partial-04.txt draft-ietf-pim-igmp-mld-proxy-yang-10.txt draft-ietf-idr-bfd-subcode-05.txt draft-ietf-jmap-blob-18.txt draft-moskowitz-ipsecme-ipseckey-eddsa-09.txt draft-ietf-i2nsf-applicability-18.txt draft-ietf-rats-tpm-based-network-device-attest-14.txt draft-ietf-dnsop-dnssec-bcp-06.txt draft-ietf-ipwave-vehicular-networking-30.txt draft-ietf-bmwg-ngfw-performance-15.txt draft-ietf-raw-ldacs-14.txt draft-ietf-v6ops-ipv6-deployment-10.txt draft-ietf-ccamp-gmpls-otn-b100g-applicability-15.txt draft-ietf-lsr-isis-flood-reflection-12.txt draft-ietf-dots-telemetry-use-cases-15.txt draft-ietf-teep-architecture-19.txt draft-ietf-rmcat-rtp-cc-feedback-12.txt draft-ietf-shmoo-online-meeting-05.txt draft-ietf-ippm-ioam-deployment-05.txt draft-pti-pen-registration-10.txt draft-davies-int-historic-05.txt draft-zern-webp-12.txt draft-irtf-cfrg-spake2-26.txt draft-irtf-cfrg-hash-to-curve-16.txt draft-irtf-qirg-principles-11.txt draft-irtf-icnrg-ccninfo-15.txt draft-irtf-cfrg-vrf-15.txt draft-irtf-pearg-numeric-ids-generation-12.txt draft-irtf-pearg-numeric-ids-history-11.txt draft-bar-cfrg-spake2plus-08.txt draft-briscoe-docsis-q-protection-06.txt draft-ietf-regext-tmch-func-spec-15.txt draft-smyshlyaev-tls13-gost-suites-08.txt draft-smyslov-ike2-gost-15.txt